主密鑰的列數

Question

螺母和螺栓的樣本數據Thread Series。我試圖確定這個數據集的主鍵。以下是一些有效組合的示例。

size  form  tpi 
1/4  UNC  20 
1/4  UNF  28 
1/4  UNEF  32 
5/16  UNC  18 
5/16  UN  20 
5/16  UNF  24 
5/16  UN  28 
5/16  UNEF  32 
3/8  UNC  16 
3/8  UN  20 
3/4  UNC  10 

最終我試圖建立拉下的web應用程序，它允許用戶選擇一個有效的螺栓菜單，如3/4-10UNC-2A HEX Head.一個3/4-6UNC-2A HEX Head是無效的，因爲他們不製造3/4" 螺栓每英寸6個線程（它不會被加載在這個表中）

第一個下拉選擇螺栓類型，第二個下拉提供基於螺栓類型可用的螺栓尺寸（在另一個數據庫中定義表）

第三次下拉將提供螺栓定義的最後部分，所以如果用戶選擇HE X Head，然後是5/16「，他們會看到UNC-18，UN-20，UNF-24，UN-28和UNEF-32的選擇。

我對PK（S）的選擇可能是：

• 替代和創造獨特的約束。
• 使用大小和形狀爲複合PK，它確定TPI
• 使用大小和TPI作爲複合PK，它確定形式
• 使用形式和TPI作爲PK，它確定尺寸
• 所有三個字段作爲PK（大概是錯的！）

看起來好像沒什麼關係，我選擇關於查詢的PK選項，因爲我會根據螺栓直徑來查詢其他兩個值。我遺漏的一點是與另一個表中的UN表單有關的2A值，以及需要進一步限制哪些ThreadSeries可以與螺栓類型一起使用的「doozey」。

我在Java EE中這樣做，使用JSF和JPA實體，如果該事項

Answer 1

使用大小和形狀爲複合PK，它確定TPI
使用大小和TPI作爲複合PK，它確定形式
使用形式和TPI作爲PK，它確定尺寸

所有這些都是錯誤的假設。隨着數據庫的發展，沒有任何東西可以阻止其中一個假設被假冒。例如。一個1/4 UNC 28被添加到股票。

• 因此，如果您已經創建了一個PK，那麼會破壞數據庫，您將不得不更改依賴於此PK的整個表集。

您無法通過FD確定密鑰（除了作爲理論課堂練習，使用a和b以及cs）。這不是教室。列是真實的，它們有意義（a和b和c沒有意義）。你很正確地描述了問題，意思。

關鍵確定是一個直接的邏輯練習，是數據建模的重要組成部分。

您的每個示例行都​​是事實。必須存儲。這一定是獨一無二的。

所有三個領域PK（可能是錯的！）

這是唯一正確的PK。這是提供行唯一性的唯一組合，以確保表中沒有重複的行。

代孕並創造獨特的約束。

既然你無法迴避，讓行獨特的PK，這將是多餘的，額外的製造列加上索引，什麼也不做。

代理不提供在關係模型（它們提供物理記錄ID唯一性）中要求的邏輯行唯一性。

如果你不明白我在說什麼，請閱讀this Answer，從頂部假教師

東西我離開是2A值，這涉及到另一個聯合國窗體表和一個「doozey」的要求，進一步限制哪些ThreadSeries可以與螺栓類型一起使用。

的關係模型是基於一階謂詞演算，通常被稱爲一階邏輯（FOL）。在FOL中沒有什麼不能說明的。因此，沒有什麼東西不能在關係數據庫中建模。

• 的「理論家*誰寫的書，聲稱要對關係模型或關係型數據庫，不明白這些fundaments，他們寫各種各樣的事情不能做;他們使用替代物（抗關係）爲所有的表，這會導致備案制度，以無關係完好的（區別於參照完整性），關係數據庫的功率或速度。

開復的「doozey」一個新的問題和ping我

Answer 2

您的問題不符合鍵值的。你正在做的是「向下鑽取」以找到三列中唯一的值組合。該過程不使用密鑰。

但是，我會提出一個建議。您的主要分組字段是form。它是一個非任意的，固定的已知值列表。出於這個原因，您可以爲每種形式的表單輸入一個表格：UN，UNC，UNF等。form字段將被定義爲該表的外鍵。

這將提供兩個好處。

1. 數據完整性：沒有價值可能在還沒有在Forms表預先定義的form領域存在的。
2. 性能：Forms表格將提供第一個下拉框的簡單來源。您可以執行select form from Forms而不是執行select distinct form from ThreadSeries。每個表單都有且只有一個條目，不需要使用distinct - 任何發生在ThreadSeries字段中的表單（例如，如果沒有其他原因創建新表單）仍會顯示。

至於主鍵，你有兩種選擇。一個是代理鍵。這具有能夠使用唯一值唯一地識別行的好處。缺點是這個值對你的用戶沒有任何意義。當他們正在尋找3/4-10UNC-2A HEX Head時，他們知道如何指定。他們可能不知道（並且會非常反對學習）該特定螺絲的價值是9383934747甚至117.這些值（根據定義）是毫無意義的。你可以通過隱藏它來防止任何用戶混淆和/或反感PK。這是常見的做法。

另一種是使用三個字段作爲複合PK。這具有用戶能夠基於他們正在查找的內容來構建PK值或者當他們正在瀏覽時向下鑽取的優點。當然，缺點是用三個領域而不是一個領域。但是，如果三個字段的內容是您通常可以使用的值，那麼這不是一個缺點。但是，這是重要的，這三個字段定義了一個自然鍵，而不管你是否明確地將它們定義爲主鍵。因此，即使您決定使用代理鍵，這些字段也必須定義爲鍵：每個單獨的字段都定義了NOT NULL，並且使用所有三個鍵構建了唯一的索引 - unique(form, size, tpi)。

這不是一個綜合分析。雙方都有其他優點和缺點，但它們很小，通常取決於各種因素，因此可能適用於您的情況，也可能不適用於您的情況，此外，我並沒有在這裏寫書。