我真的很努力規範化客戶會議表格。規範化表格
的詳情如下
CLIENT_NAME,Client_phone(標準化)
日期,時間,地點,Person_met,位置,key_notes,工作人員(重複的組)
在1 NF,我知道Client_Name(給定一個client_ID鍵)將是重複組中的外鍵,但我不知道哪個屬性是主鍵。
日期和時間會標識會議嗎?不確定您是否可以擁有兩個主鍵?
任何幫助將不勝感激。
我真的很努力規範化客戶會議表格。規範化表格
的詳情如下
CLIENT_NAME,Client_phone(標準化)
日期,時間,地點,Person_met,位置,key_notes,工作人員(重複的組)
在1 NF,我知道Client_Name(給定一個client_ID鍵)將是重複組中的外鍵,但我不知道哪個屬性是主鍵。
日期和時間會標識會議嗎?不確定您是否可以擁有兩個主鍵?
任何幫助將不勝感激。
我認爲日期,時間和地點應該是複合主鍵(您可能可以同時有多個會議..)。
雖然我不確定「重複組」的含義。
謝謝你,這是有道理的。關於重複組,我的意思是刪除一個屬性表中可能多於一個條目的數據。即在存儲客戶會議的表格中,作爲表格,會有不止一次的日期,地點,人員會見等。 – jamiesmith25 2010-10-14 18:15:11
個人我不喜歡組合鍵,除非有物理原因(例如:它將用於跳轉層次結構)。我會建議一個代理鍵。 PKs應該是一種自然發生的,獨特的,強制性的,並且最好是穩定的(即沒有改變)。 由於這種情況很少發生,通常使用替代關鍵字(通常由RDBMS分配一個遞增數字的列)。
在你的例子中,日期和時間不應該是PK,因爲可以想象有兩次會議具有確切的日期和時間(儘可能不如此,仍然是......)。 如果你必須有一個複合鍵,那麼日期,時間和客戶端名稱將是必要的PT使其獨特,因爲同一客戶端不能參加兩次會議在同一時刻(對吧?) 另外,我注意到位置是在那裏兩次。可能需要成爲一個位置標識,位置在每個第三NF的單獨查找表中。
規範化實際上與關係系統以及關係表模式的擴展有關。規範化理論實際上不適用於形式。 – 2010-10-14 20:22:40
您的一組重複組中有兩個位置字段。這兩個不同的地點,或只是一個地點(意外輸入兩次)?另外,工作人員代表什麼? – 2010-10-15 10:13:06