0

表 - 人{ID,姓名,年齡,行1,城市,州,郵編}數據庫函數依賴分解

FD設置

1)ID - >每隔一個的屬性,因爲它是PK

2)我不能確定,因爲

zip -> {Line1, City, State} or.. 

{Line1, City, State} -> zip? 

[both of these are candidate keys I guess] 

在任一情況下,是否變得傳遞依賴ID - > Zip - >其他地址(或ID - >地址相關 - > Zip)。

它違反了3NF(傳遞依賴)。

請你解釋一下如何分解給定的關係,以及包含地址相關的其他關係中的PK是什麼。

+0

對於課程你通常會被賦予功能依賴。但是,如果您正在尋找真實世界的依賴關係,郵政編碼不會確定城市或州。 (有跨越州,甚至國家邊界的城市。)郵政編碼與郵政運輸商如何驅動送貨路線有關,而不是地理位置。 –

+0

感謝您的建議。在課程中,「國家」被排除(或錯過)。它給了我一個機會,讓我直接假設所有的地址都屬於一個國家,這使得zip-> {city,state}爲真;) – Firefox

+0

無論如何,在現實世界中,不鼓勵正確的3NF分解,至少在'地址'表導致屬於多個關係的一些奇怪的屬性組合。 – Firefox

回答

1

假設{行1,城市,州} - > {郵編}和{郵編} - > {城市,州},那麼以下分解是在3NF:

Person {ID, Name, Age, Line1, Zip} (key= {ID}) 
Address {City, State, Zip} (keys = {City, State} and {Zip]) 

在實踐中這可能不是很有用因爲實際的地址數據通常不一致或缺少部分。真正的問題是你實際想要在你的數據庫中執行哪些依賴關係。這就是爲什麼只依靠屬性名稱列表來標識依賴關係的練習非常主觀。給出明確答案的唯一方法是從您希望模式滿足的一組依賴關係開始。

+0

謝謝..瞭解它是如何完成的! – Firefox

1

如果您知道(Line1,City,State),您可以確定zip。所以,

{Line1, City, State} -> zip 

不是相反。因爲相同的郵編可能包含同一城市和州的多個Line1值(例如,同一條街上的不同門牌號)。

對於3NF的關係可以

  • 人{ID,姓名,年齡,一號線,城市,州}
  • 地址{1號線,市,省,郵編}

從實用性似乎是冗餘的,浪費數據庫表中的空間。

+0

絕對同意。謝謝您的幫助。(1)爲什麼我們不應該這樣做=> 人{ID,姓名,年齡};爲什麼我們不應該這樣做=> 地址{Line1,City,State,Zip,ID} [我認爲PK應該是所有屬性的組合。] (2)Zip - > {City,State} ..因此,我們的分解仍然違反3NF .. 我很嚴格,因爲這是課程。 – Firefox