數據庫正常化問題

我剛開始學習關於數據庫正常化的問題，並對我的一個表格有疑問。我的數據庫現在的結構非常糟糕，其中一個原因是因爲我有一張看起來像這樣的表。數據庫正常化問題

客戶表

ID | Date_Entered | First_Name | Middle_Name | Last_Name | Maiden_Name

...

Address__street_dmv | Address_city_dmv | Address_state_dmv | Address_zip_dmv

...

Address__street_source2 | Address_state_source2 | Address_city_source2 | etc

。

由於我的公司從多個來源獲取地址數據，所以地址在繼續。但是，當然，這些地址中的一些對於我們的一些客戶而言將是空的。所以我想我需要一個單獨的地址表，像這樣連接到Customers表。

。

地址

ID | Number | Street | State | Zip | Source (drop down menu)

但後來我想源將冗餘數據。那麼，我需要一個單獨的源表嗎？

來源

Source_ID | Source

並更改地址表中也是這樣嗎？

ID | Number | Street | State | Zip | Source _ID (drop down)

它似乎不正確，因爲現在Source_ID是多餘的...請幫助。如果

紅利點，你能告訴我是否我應該包括，因爲這些客戶表少女和中東的名字也可能被空（如果沒有，如何將新表結構？）

對不起作爲一個noob。

來源

2011-08-25 jerry

嘿，你走在正確的軌道上，不會感覺不好。我們在這裏幫助（特別是措辭很好，具體問題如此）。雖然我認爲，從我一直聽說Access的東西，有些人會推薦一個不同的數據庫產品......（從來沒有用過它，所以不能真正說）。 –

數據庫規範化旨在使您的數據更可靠，更易於使用，並且您的結構更易於理解。你應該絕對規範你的數據來實現這三個目標。但是，很可能會過度規範化數據庫。如果爲了可靠性而爲一條信息創建另一個表並不是必要的，並且只是在常見查詢中強制另一個聯接，那麼不要這樣做。處女/中間名是其中的一種情況，只要將它放在主表中即可。 – Banjoe

您需要複製像Source_ID這樣的字段，以便它可以允許您加入兩個不同表的記錄。這是對數據進行復制的例外，這是關係數據庫的工作原理。 – JeffO

我會去的東西像

客戶

ID | Date_Entered | First_Name | Middle_Name | Last_Name | Maiden_Name

地址

ID | Number | Street | State_ID | Zip

Customers_Address

ID | Customer_ID | Address_ID | Source_ID

這使您可以從多個來源獲得相同的地址。您可能還需要有單獨的表街道，可能像

Table_Street (ID | State_ID | Name)

然後在Addresses表你只會有Street_ID，而不是兩個Street和State_ID。這也使您可以在用戶選擇狀態時顯示街道選擇列表。

我想說，即使很少使用客戶表中的少女和中間名，也可以。

來源

2011-08-25 21:50:40 ain

我和你在一起，儘管OP可能不需要多源/多客戶地址優化（儘管這可能是個好主意）。 'Maiden_Name'可能是同一個客戶的不同名稱（以前的名字，這是一個不同的姓氏），這取決於用例。 –

我不是SQL專家，但這是我想你想描述的。

客戶是一個獨特的實體有一個當前的地址，並可以有很多其他地址，如果這是正確的是你應該分開額外的地址到他們自己的表。

其次，您發現客戶擁有x個地址的方式是，您可以爲每個客戶獲得不同公司的這些信息，如果是這種情況，我會爲公司制定一個單獨的表並按照您的計劃進行記錄，是的，你會有重複的source_id行，但這將是這種情況，因爲他們提供有關許多不同客戶的信息。

關於首要和中間名，這些是您的商業規則所要求的，如果在需要時存儲它們的話。

再一次，我的SQL開發只是真正的學生水平，但從我理解的這是我將如何去做。

希望這會有所幫助，如果任何人都可以提供更多的專家信息，請使用它。

來源

2011-08-25 21:48:36 Graham

你的問題的一部分與標準化有關，而其中的一部分不是。這並不意味着你的問題的一部分並不重要。這只是意味着它與正常化無關的原因很重要。

從某種意義上說，您的地址基本上是一個重複組。所以從客戶中刪除它們確實有意義。（這與標準化有關;重複組違反1NF。）

「源」不是冗餘數據，並且決定是否替換文本的ID號與標準化無關。

將表格從較低標準形式移動到較高標準形式時，原始表格以較少的列結束。用ID號代替文字不會改變列的數量。

而您在其中用文本替換無意義的ID號碼的每一列都需要連接才能獲得有意義的文本。遵循相同的邏輯，您也可以用街道，州和郵編替換無意義的ID號碼，但這需要四次聯接才能獲得有意義的數據。

來源

2011-08-25 22:45:15

感謝Catcall，這實際上很有意義。 – jerry

你也可以試試下面的辦法：

客戶

客戶ID（PK）| Date_Entered | First_Name | Middle_Name | Last_Name | Maiden_Name

地址

客戶ID（PK）（FK）| SourceID（PK）| Number |街道|國家|郵編

這假定客戶和地址之間的一對多關係。它還完全消除了Customer_Address表，有利於使用兩個表（Customer和Addresses），並將Addresses表的複合主鍵定義爲CustomerId和SourceID。在這個模型中，CustomerId和SourceId唯一確定數字，街道，州和郵編。它還通過確保每個客戶只能從每個來源獲得一個地址來實施數據完整性。讓我知道這是否有幫助，或者如果我遠離基地。我還在學習！

來源

2011-08-28 13:17:17 TelJanini

數據庫正常化問題

回答

相關問題