如何避免複合實體鍵和約束問題（產品，選項，選項組，特殊訂單）

Question

我正在建模一個網上商店的數據庫，並且遇到了廣告問題。基本上問題是爲了簡單起見，是否忽略數據庫規範化規則。 以下是問題之前我圖中的相關部分。 Database diagram 基本上，產品可以有選項（大小，味道，顏色），但只能從一個選項組中選擇。由於選項組可以有多個選項，並且使用它的產品可以採用子集，因此會創建ProductOption表。接下來我們有一個SpecialOffers表。接下來，一個特別優惠可以有很多產品和產品可以屬於許多特別優惠，因此關聯表SpecialOfferProducts。所有這些都可以正常工作，直到特別優惠包含具有選項的產品。這是我遇到問題的地方。我有幾個想法。

第一個想法： 在SpecialOfferProducts和ProductOptions之間創建一個關聯表。我不喜歡這個想法，因爲這兩個表都有複合主鍵，並且創建一個具有由兩個複合主鍵組成的複合主鍵的表看起來很奇怪，我從來沒有見過類似的東西。

第二個想法： 在SpecialOfferProducts和Options之間創建一個關聯表。這看起來不對，因爲選項並不直接綁定到產品。這仍然有效，主鍵會更簡單一些。

第三個想法： 這是我最喜歡的一個，但它違反了一些規則。更改SpecialOfferProducts表。使其擁有自己的主鍵，並將SpecialOffers，產品和選項作爲外鍵。只需使選項外鍵可空，並解決問題。當然，問題在於我沒有創建一個關聯表，我應該並且正在使外鍵可以爲空。這會讓我的代碼稍微複雜一些，以處理所有這些，但我仍然認爲這比其他方法簡單得多，因爲我減少了組合鍵的數量，並且在產品在特價優惠使用一個選項。

我的問題是，哪一個選項最好？有沒有更好的選擇，我沒有提到？

使用馬丁的風格符號

OptionGroups與表選項（0，n）的關係。選項與表格OptionGroups有（1,1）的關係。這些表的目的是存儲顏色，大小等信息。例如，OptionGroups條目顏色具有黑色，白色等選項條目。

產品表與表OptionGroups有（0,1）的關係。 OptionGroups與表Product有（0，n）關係。產品表與表格選項具有（o，n）關係。選項表與表格產品具有（o，n）關係。多對多關係生成關聯表ProductOptions。 ProductOptions有一個複合PK ProductID，OptionsID。這些表的目的是允許產品從某個選項組中選擇（但不必），但不需要具有該組中的所有選項。

示例1.產品沒有任何選項，因此FK Product_OptionGroups爲空。在這種情況下，產品在ProductOptions表中沒有任何條目。

示例2.產品具有選項（可以說是顏色），因此FK Product_OptionGroups不爲空（具有coresponding選項組的ID）。選項組的顏色可以有很多顏色，產品可以使用其中一種或多種顏色。產品使用的顏色是ProductOptions表中的條目。

SpecialOffer表與表產品具有（1，n）關係。 Products表與表SpecialOffer具有（0，n）關係。多對多關係創建關聯表SpecialOfferProducts。該表具有PK SpecialOfferID，ProductID。該表具有一個數量屬性，指示產品的數量。

例子。 SpecialOffer A包括產品A的一個實例和產品B的兩個實例。

可以說產品A有選項。現在SpecialOfferProducts表必須引用正確的選項（也許產品可以是藍色和紅色，特別優惠只包括紅色產品）。這是當前模式不起作用的地方，必須引入額外的表格（想法1和2）或現有表格改變（想法3）。

Answer 1

也許你有一定的關係（船）/協會不是在你的前三個方面所能表述的：

-- special offer S offers the pairing of P and option O 
SpecialOfferProductOption(S, P, O) 
-- PK (S, P, O) 
-- FK (S, P) to SpecialOfferProducts, FK (P, O) to ProductOptions 

你似乎並不瞭解使用組合鍵，CKS（候選鍵），FKS的（外鍵）&限制。約束（PK，UNIQUE，FK等）在之後出現您設計的關係（船舶）/關聯足以清楚地描述您的業務情況（以表格表示），可能出現的情況。

從ER的角度來看，您沒有正確應用參與實體（類型），實體（類型）鍵&關聯實體（類型）的概念。

你是不必要的&隱約害怕複合CKs。即使你想減少組合鍵的使用，你應該首先找到一個簡單的設計。如果您不想使用組合鍵，請將id PK與其他CK一起引入。但是請注意，當您使用ids作爲FK時，如果您已經使用了複合CK，則不會放棄正確約束它們出現的表的義務，以便在必要時與其他ids或列按照您需要的約束達成一致。

第一個想法： 在SpecialOfferProducts和ProductOptions之間創建一個關聯表。我不喜歡這個想法，因爲這兩個表都有複合主鍵，並且創建一個具有由兩個複合主鍵組成的複合主鍵的表看起來很奇怪，我從來沒有見過類似的東西。

這並不清楚你的意思。也許你的意思是上面的（好）設計。也許你的意思是有重複的產品專欄;但這不是什麼好設計所暗示的。

從ER角度來看：您可能會將此視爲特殊訂單&產品上的關係（船）/關聯。但是，那麼實體密鑰不會是複合的，他們將識別特殊訂單&產品，並且選項也會參與。或者，我們可以使用關係（船舶）/關聯的ER概念SpecialOfferProducts & Product對於兩個參與者的關聯實體。這將使用複合鍵。 （如果選項不被視爲實體，則ER將這稱爲弱關係（船舶）/關聯實體，並將特殊訂單&產品作爲標識實體。）無論如何，特殊訂單&產品必須就選項達成一致，如果不強制通過FKs，那麼它仍然需要約束。

如果您已經閱讀了一些關於信息建模&數據庫設計的已發佈文本（您應該如此），您將會看到複合鍵的許多用途。

第二個想法： 在SpecialOfferProducts和Options之間創建一個關聯表。這看起來不對，因爲選項並不直接綁定到產品。這仍然有效，主鍵會更簡單一些。

目前尚不清楚「直接綁定」，「看起來」或「錯誤」的含義。

關係表關係（船）s /關聯屬於值之間，其某些子行可能標識某些實體。只需使用相關列&就可以聲明相關約束條件。

從ER觀點：考慮到你似乎混淆了參與者的實體（特價VS SpecialOfferProduct），也許這是沒有實際意義，但：也許如果你試圖表達自己只能用技術術語&而不混亂，那麼你會試圖說這種設計需要產品 - 選項對出現在ProductOptions中的一個約束，並且這個約束涉及關聯實體ProductOption不是參與實體之一的關係（ship）/關聯很麻煩。我同意，但這樣的設計不是「錯誤的」。

第三個想法： 這是我最喜歡的一個，但它違反了一些規則。更改SpecialOfferProducts表。使其擁有自己的主鍵，並將SpecialOffers，產品和選項作爲外鍵。只需使選項外鍵可空，並解決問題。

除了只是不必要的複雜，這種設計是不好的。它涉及一個複雜的表，意思是&複雜的約束。當設置表值時，您需要決定何時使用&不使用空值。閱讀時，你需要根據它是否爲null來確定行的含義。引入一個id或nulls，可能在刪除列的同時，並沒有刪除限制剩餘列的義務，如果這不是由剩餘的FK限制處理的話。通常情況下，我們組合了表格，同時在不屬於每個CK的列中引入空值- 不是您的情況。在這裏，您的添加ID甚至不會排除將產品對和非空選項列值限制在ProductOptions中的需要。當有一個NULL選項列值時，在ProductOptions中應該仍然存在特定的行，有時在SpecialOfferProducts中不是特定的行。此外，這種設計必須用於處理NULL存在的複雜查詢。 （你說的是哪一個。）把這個理解爲一個ER設計同樣是有問題的。

PS 1請說明您的業務關係（船）s的比基本無意義的通用術語少/協會「有」，「有」，「中」，「用途」，&「屬於」 - 作爲你會與客戶購買你的產品&特別優惠。他們參考關係（船）s /協會&集，但他們沒有解釋他們。 （同樣，基數是關係（船舶）/協會的屬性，但不能解釋/描述它們。）有關設計

PS 2 ER推理涉及什麼（可能是關聯的）實體參與的關係，而在關係模型視圖表只是捕捉n元關係（船）對任意n S /協會。因此，ER視圖增加了不必要的區別。這就是爲什麼ER-based information modeling & database design approaches are not as effective as fact-based approaches：

這導致正常化和約束不充分，從而導致冗餘和完整性損失。或者，當這些步驟被充分完成時，它會導致E-R圖實際上不描述應用程序，實際上由關係數據庫謂詞，表和約束來描述。然後，E-R圖模糊不清，多餘和錯誤。

PS 3如果持有其中「特價小號提供P和一些選項的配對」，因爲它是select S, P from SpecialOfferProductOption行我們不需要SpecialOfferProducts。 （這似乎是這種情況，因爲您的選項3涉及只有一個表，您稱爲SpecialOfferProducts，但是就像這張表中添加了一個ID）。但是，如果它保留行說'特價商品S提供產品P'，並且可以所以當不是所有S的產品選項對都被記錄下來的時候，你就需要它。 （類似的東西出現重當事情是一個實體，例如當應該有一個表「S是一個特殊選項」決定。）

PS 4

似乎很奇怪，我從來沒有見過類似的東西

這是生活的故事。但是在技術方面，如果我們學習和應用明確界定的基本定義，規則程序，那麼我們「看到」更多，更清楚。 （不要模糊地認爲我們隱約看到那些不存在的東西）。「奇怪」是一種罕見的情況，我們可以明確證明我們的工具不適用。