將具有相同主鍵的兩個表規格化爲3NF

Question

我有兩個表格當前具有相同的主鍵，我可以讓這兩個表具有相同的主鍵嗎？

也都在第三範式

Ticket:     
------------------- 
Ticket_id* PK 
Flight_name* FK 
Names* 
Price 
Tax 
Number_bags 

Travel class: 
------------------- 
Ticket id * PK 
Customer_5star 
Customer_normal 
Customer_2star 
Airmiles 
Lounge_discount 
ticket_economy 
ticket_business 
ticket_first 
food allowance 
drink allowance 

在數據庫中的表的其餘部分中的所有表都低於

乘客：

名稱* PK Credit_card_number Credit_card_issue TICKET_ID * 地址

航班：

Flight_name * PK FLIGHT_DATE Source_airport_id * FK Dest_airport_id * FK 來源 目標 Plane_id *

機場：

Source_airport_id * PK Dest_airport_id * PK Source_airport_country Dest_airport_country

飛行員：

Pilot_name * PK 平面標識* FK Pilot_grade 月 飛行小時 率

飛機：

Plane_id * PK Pilot_name * FK

Answer 1

有兩個表使用相同的密鑰去反對在正常化中消除冗餘的想法。

除此之外，這些表格在1NF和2NF？

根據Names字段判斷，我建議table1不是。如果多個名稱可以屬於一張票，那麼您需要一張新表，最有可能使用組合鍵ticket_id,name。

Answer 2

這並不意味着作爲一個答案，但它變得太長評論...

不健全的苛刻，但你的模型有一些嚴重的缺陷，你應該把它回到繪圖板。

考慮如果乘客購買第二張票時會發生什麼情況。乘客表不應該持有任何票據的參考。也許一個乘客可以擁有多個信用卡？信用卡不應該放在自己的桌子上嗎？這同樣適用於地址。

機場表爲什麼會保存真正關於目的地（或路徑/旅程）的信息？您已經在Flights表中記錄了行程信息。在我看來，機場表應該擁有與特定機場有關的信息（如姓名，地點？，國際航空運輸協會代碼等等）。

飛行員能與一個單一的飛機相關嗎？聽起來不太可能。飛行員表不應該保存有關飛機的信息。

飛機表不應該持有飛行員的信息，因爲飛機肯定可以連接到多個飛行員。

等等......還有很多其他問題，但這些指針應該給你一些想法。

對我來說，這種看起來不錯的表格是Ticket and Flight。

Answer 3

重新相同的主鍵：

具有相同主鍵是可以有多個表。原則上和良好的做法。我們聲明一個主要的或其他唯一的列，說這些列（和它們的超集）在表中是唯一的。如果是這種情況，請聲明這樣的列集。這事兒常常發生。例如：典型的合理情況是「子類型」/「子表」，其中由一個表的候選鍵標識的類型的實體總是或有時也是由另一個表中的相同值標識的類型。 （如果總是那麼一個表的候選鍵值也在另一個表中，那麼我們將聲明一個外鍵到另一個表，我們可以說一個表的類型實體是另一個表的一個子類型）。另一方面有時一個表使用兩種屬性，一種屬性不適用於一種不使用。 （即通過空或標籤指示種類）。

是否你應該有相同的主鍵的情況取決於良好的設計適用於您的特定情況的其他標準。你需要學習包括規範化在內的設計。例如：所有簡單鍵和3NF意味着5NF，所以如果你的兩個表具有相同的一組值，只有在每個狀態下只有&簡單主鍵，並且它們都在3NF中，那麼它們的連接包含與它們完全相同的信息分開做。不過，也許你會爲了設計的清晰度，改變的可能性或基於使用的性能而將它們分開。你沒有提供這些信息。

回覆正常形式：

正常形式適用於表。表的最高標準形式是獨立於任何其他表的屬性。 （雖然你可能會根據&表格的種類來選擇表格）

爲了規格化或確定表格的最高標準形式，需要知道（通常）所有函數依賴關係。 （對於BCNF上面的正常形式，也加入依賴關係。）你沒有給他們。它們由表格的含義決定（即，如何確定在特定情況下哪些行進入）以及可能出現的情況。你沒有給他們。我們可以告訴你關於表格所處的正常表格而不提供這些信息的期望表明你不瞭解標準化並需要對此進行教育。

正確的設計也需要這些信息以及一般情況下可能出現的所有有效狀態。即給定表格之間的約束。你沒有給他們。