UNF 到 3NF 這種關係可行嗎？
我繼承了一個包含大約 200 萬條記錄的平面數據表。看看它已經在 1NF 中的數據，我想把它變成 3NF。
數據是澳大利亞的，因此郊區無法確定州，因為郊區名稱存在於多個州，而且一個郵政編碼通常覆蓋多個郊區。意思是郊區，州，郵政編碼應該是一個超級鍵？
不同站點有多家公司，一些公司有相同的電話號碼（免費電話 1300 或 1800），而另一些公司有不同的電話號碼，每條記錄都有一個傳真號碼，大多數都有一個電話號碼。ContactName 大部分為空白，因此電話和傳真號碼與公司相關，而不是聯繫人。
使用者對記錄的選擇通常是在欄位 BusinessTypeDescription 上加上地理條件的 RLIKE，這當然意味著對每個查詢進行全表掃描，因此結果非常慢。
3NF 下面建議的表結構是否實用？
EXISTING TABLE ----------------------- ID (PK) CompanyName Address Suburb State Region Postcode Country ContactName (this field is mostly empty) Phone Fax Mobile Email (this field is mostly empty) Website (this field is mostly empty) PremiseType BusinessTypeDescription ANZSICCode ANZSICDescription RecordSource這是建議的結構…
COMPANY --------------- ID (PK) CompanyName Address LocationID (FK) PhoneID (FK) FaxID (FK) MobileID (FK) ContactName PremiseType BusinessTypeID (FK) ANZSICCode (FK) Email Website RecordSource LOCATION COUNTRY REGION -------------- -------------- ------------ ID (PK) ID (PK) ID (PK) Suburb Country Region State Postcode RegionID (FK) CountryID (FK) PHONES ------------ ID Phone MOBILES ------------ ID Mobile FAXES ------------ ID Fax BUSINESSTYPE ---------------------- ID BusinessTypeDescription ANZSICS ---------------------- ANZSICCode ANZSICDescription
您需要了解重複和冗餘之間的區別。有時，一個欄位值會巧合地重複。這種重複無法正常化。
規範化是關於研究關鍵和非關鍵元素之間的功能依賴關係。這不是將可能出現兩次的所有內容都放入帶有代理鍵的表中。
例如，您說一個電話號碼可能被多家公司使用，並將電話號碼建模為一個獨立的表。如果當一家公司更改其編號時，使用該編號的所有其他公司同時以相同方式更改其編號，這將防止更新異常。這些真的有商業意義嗎？對我來說不是。
此外，將地理規範化為層次結構是一個值得商榷的命題。但是，您甚至還沒有標準化為層次結構。地區ID不是由國家ID決定的嗎？如果是這樣，您的 LOCATION 表不是 3NF。同樣，是否有連接州的郵政編碼？我不太了解澳大利亞的系統，但我知道在加拿大、美國和英國這不會發生。
你設計的一切都像它的星形模式和公司是事實。星型模式中的事實通常是事務，而不是靜態實體。交易不會改變它們的屬性，因為它們通常代表實際發生的事情，而且通常不會及時回溯來改變歷史。靜態實體在您的數據中存在很長時間（可能永遠存在）並且經常更改它們的屬性。對於此類數據，星型模式不是一個好的、高效的模型。
您應該做的是對每列的頻率分佈以及您認為可能是鍵的列與您知道不是鍵的列的組合執行查詢。這將幫助您測試您對哪些列真正能夠充當鍵的假設。然後，您應該用一些常識來緩和這些發現，這些發現可能會在更改列值方面對您的數據造成什麼影響。一旦你知道你在數據中發現的實際函式依賴關係，然後按照相對機械的過程將你的關係轉移到 3NF。