推 trueQoo:push,我在學校時也是先學 ER方法論,正規化是檢查沒錯 03/11 22:22
推 trueQoo:不想回文了,但確實用ERD設計,就不會一開始有複合主鍵情況 03/11 22:27
推 trueQoo:我也是學方法論,一開始就設計複合鍵當主鍵說真的會被笑... 03/11 22:35
※ 引述《bobju (寶貝豬)》之銘言：
: 第一正規化不允許'重複的'記錄, 包括兩種情況:
: 1. 單一屬性多值.
: 2. 重複的記錄.
: 為了要能夠確定沒有重複記錄, 所以要有足以'識別'每一筆記錄的設計, 也就是主鍵.
: 主鍵可以是由單一屬性構成, 也可以由多個屬性複合而成, 甚至把全部屬性都拿來
: 複合在一起當主鍵亦可.
: 我找到的wiki, 縮址如下:
: http://tinyurl.com/aurwxf
基本上來說,正規化是一種 "檢查",而不是設計資料庫時
"以設計正規化為主"
以複合鍵能當成主鍵的角度而言,以下也可以設定複合主鍵當主鍵,但資料庫設計中
若以實體關聯為設計方式時(ER方法論)
以下都是 ER方法論,和正規化無關
要先在實體中找到一個屬性當作主鍵,它就是代表實體,如果找不到,可以用代替鍵
所以在設計時有 "天然鍵" 與 "代替鍵" 兩種主鍵的設定方式
主鍵的特性要 "短" , "易取得"
像病人實體就不會以身份證字號當主鍵,而會以 "病人編號" (代替鍵) 當主鍵
避免人昏迷不醒時,沒有身份證字號而無法輸入資料
如果用複合鍵當主鍵,並非不行,但如此一來,學生資料的設計如下:
姓名 生日 性別 地址
假設純以正規化來看,自然 (姓名,生日,性別,地址) 四屬性可以成為不重複的複合主鍵
你能找到一個同名同姓,同性別,又一樣地址的,只有你,沒有別人
但也代表你輸入資料時,這四個值都要輸入才能新增一筆記錄
故,會有 "學號" 這個代替鍵代表學生實體,它不會重複
-------------------------------------------------------------
其實我的觀點很簡單,就是設計資料庫會先找一個方法論設計,像用 ER方法論設計
設計完後,用正規化原理檢查是否還要再分出實體
而非用正規化來設計資料庫
換言之,我們 ER方法論一開始就開宗名義,實體屬性,用屬性描述實體
在實體的眾多屬性中,找一個屬性為主鍵代表實體
--
Information ╳
▕ .
▕ 在世界中心呼喊愛........錢 .
▕ ＿＿＿＿＿＿ .
▕ ▏ 確定 ▏ .
▕ ▔▔▔▔▔▔
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 60.250.147.242