數據庫 - 試圖鞏固對規範化的理解，這是如何規範化的？

how normalized is this table?數據庫 - 試圖鞏固對規範化的理解，這是如何規範化的？

所以我知道的話題和規範化本身的定義已經非常好討論的，但我希望我能得到我的正常化理解一些澄清。一個例子就是我真正快速地從Access中抽出的一張圖表，我認爲這些關係和表格本身都符合3NF標準。有一個項目表，其中包含以下字段ProjNumber（PK），ProjName和ProjDesc。然後是一個Assignments表，其中包含一個與EmpID/ProjNumber一致的複合鍵，並帶有HourlyBillingRate，NumOfHours和TeamNum字段。最後是Teams表，它由字段TeamNum（PK），TeamName，ProjNumber組成。

來自Assignments和Teams的ProjNumber都是與項目表相關的外鍵，Assignments中的TeamNum字段是一個與外部表主鍵相關的外鍵。如果我有ProjNumber外鍵，因爲該項目會有關聯的TeamNum，我不太確定是否有必要直接關聯到團隊表。

這些表的背景是有一個項目必須完成，一個團隊與執行該團隊相關聯，然後是該團隊中的那些支付該項目的小時計費率的員工他們正在工作。

我使用複合鍵的原因是我想回答「什麼是員工在多個項目上工作？」的問題，所以我不能讓EmpID成爲唯一的主鍵，因此我選擇了使它成爲一個複合鍵，因爲即使員工在多個項目上工作，兩者的組合也將始終是唯一的。我相信每個領域都必須與各自的主鍵完全相關。

想法？它實際上是否符合3NF標準？

來源

2016-09-17 uanaka

@RyanVincent對此，很抱歉，這當時更像是一個思考實驗，以確保我擁有正確的概念。我花了一點時間創建表，但這裏是我的sqlfiddle鏈接：http://sqlfiddle.com/#！9/8aba27我現在認識到，如果所有字段都不在被引用的表中，複合主鍵不起作用，因此，我添加了一個任意的「AssignID」字段，這只是爲了自動增加值的主鍵。 – uanaka

@RyanVincent嗯，我已經建立了表格，從概念上說，我相信它能夠滿足標準，因爲它能夠處理我投擲的一些數據，而且我沒有真正看到任何異常和錯誤流行向上。但表上的任何想法本身雖然？這些表本身只是我正在構建的數據庫的骨架結構，但我只是想確保在發現一些關鍵概念之前有一個堅實的基礎。 – uanaka

這取決於。您的圖表和討論似乎假定主鍵是每個表中唯一的候選鍵。這似乎並非如此。

在Assignments表中，它看起來好像EmpID和TeamNumber是另一個候選鍵，前提是TeamNumber可能不是NULL。

如果我們用EmpId，TeamNumber作爲關鍵字查看此表，那麼它不在2NF中。 ProjNumber由TeamNumber決定，不是整個關鍵。

因此，現在您的問題的答案是關於FD是否針對所有候選鍵進行分析，還是僅針對已聲明的prmary鍵進行分析。我已經看到了關於規範化的教程。我遵循考慮所有候選鍵的那個，所以表格不在2NF中。

除非我誤解了你的案例中的FD，或Assigment.TeamNumber可以爲NULL。

但是，您的SQL小提琴演示文稿是不同的。現在，如果一個項目上有幾個團隊，並且一個員工被分配到一個項目幾個小時，那麼就沒有辦法告訴員工在哪個團隊中。 SQL提琴示例中的FD和我從圖中提取的含義不一樣。

來源

2016-09-18 12:28:04

數據庫 - 試圖鞏固對規範化的理解，這是如何規範化的？

回答

相關問題