不同表格中的冗餘數據是否違反3NF標準化？

人（ID（主鍵），姓名，職業，工作地點，SecondJob，PerHour，HoursWorked，電話，辦公電話）
工作（ID（外鍵是指人），標題，名稱，位置，工資）
SecondJob（也指人的ID（外鍵），標題名稱）
******中國（也指人的ID（外鍵），姓名，電話，辦公電話）

我得到每個attri的值弼像姓名，職務，從下面的僞書面方式Person表電話和辦公電話：

選擇（屬性名稱）從一個人其中id IN（人ID）

的，這對信息在不同的表（數據冗餘）中重複，打破3NF標準化？

或者我應該把這些值分別放入其他表中，並分別說明哪些屬性與表的主鍵相關聯？
我通過從Person獲得PerHour和HoursWorked來計算工作中的薪水，然後將它們相乘。我聽說這也是多餘的數據，因爲它可以從表中現有的數據中推導出來。

但它是否打破3NF標準化？

2016-11-19 Mikael Ascended Rusin

這在正常化方面是如此破碎。爲什麼「名稱」到處出現？爲什麼沒有將這些信息合併到人員記錄中？如果出於性能方面的考慮而故意去規範化，您是否有方法來保持這些數據同步並理解每個領域的規範來源？爲什麼PhoneNumber包含*兩個*號碼？你在這裏有很多工作來解決細節問題。 – tadman

記住在正確的數據庫設計中，你只有[Zero，One或Infinity]（http://en.wikipedia.org/wiki/Zero_one_infinity_rule），沒有兩個。這就是爲什麼'SecondJob'作爲一張表非常關注的原因。如果他們有第三份工作呢？第四？第十九？人們改變職業，升遷，轉移，預計人們會換N次。同樣，工資信息應該與工作相關聯，而不是與個人相關聯。 – tadman

對你的迴應的反饋： 1.雖然你的第二篇文章實際上有一些有效的觀點 - 指出諸如「因規範化而破碎」之類的內容，但沒有明確的原因，基本上沒有用的反饋。 2. Secondjob只是一個名稱。它是如何形成的，仍然允許幾個不同的工作來填充它 - 用ID作外鍵。 3.規範化仍然依賴於主鍵和全部識別所述鍵。有重複的數據。不過，電話部分需要修改。 –

這是否信息被重複在不同的表（數據冗餘），破防3NF正常化事實呢？

編號表值或變量是或不在給定的NF中。這是獨立於任何其他表。（我們也談到當NF中的所有表都在NF中時，數據庫處於NF狀態。）

標準化可以合理地說是消除冗餘。但是有很多冗餘不能通過規範化來解決。還有很多冗餘並不壞。重複不一定是冗餘。僅僅因爲數據重複並不意味着重複「信息」。什麼數據表示是否在表中取決於表的含義。

但你似乎認爲，僅僅是因爲在不同的表中複製數據並不違反3NF，因此它不違反其他良好設計原則。這是錯誤的。另外，5NF很重要。使用較低NF的唯一原因是SQL DBMS不能很好地支持5NF。

或者我應該只是將值放入其他表中，並分別將表中的主鍵與哪些屬性進行識別？

我猜你是想說，如果我只把值在一個表中的每個並通過涉及共享密鑰查詢重建第二個表？也就是說，如果您可以通過查詢數據庫的其餘部分來獲取列中的值，那麼您是否應避免使用該列？一般來說，是的。

你的問題假設有一個誤解。這不是「（獨家）或」這個問題。你應該兩個都做。

我通過從Person獲得PerHour和HoursWorked來計算工作中的薪水，然後將它們相乘。我聽說這也是多餘的數據，因爲它可以從表中現有的數據中推導出來。

由於您可以使用查詢來代替數據庫的其餘部分，這是多餘的。如果你不適當地限制薪水價值，那麼這就是糟糕的冗餘。即使你做了列和約束，也會使模式複雜化。

但它是否打破3NF標準化？

不，因爲表的NF是獨立於其他表的。但這並不意味着它是好的。

（如果您添加工資到人，新表就不會在3NF。但後來，SQL數據庫管理系統有計算列，使該行，通過與薪酬的非3NF表中的3NF的看法沒有它的表。）

瞭解一些數據庫設計方法以及它們如何應用優秀設計的原則。您的表格不必要地解決應用程序的重疊方面。還要了解JOIN編寫查詢的方法。

來源

2016-11-19 20:51:18 philipxy

不同表格中的冗餘數據是否違反3NF標準化？

回答

相關問題