三個實體交點表「many-many-many」

我目前正在研究數據模型設計（將由RDMS支持）。它基於3個實體，涉及組織成員的福利。這些實體是福利，會員類型和提供者。我創建了一個標準的多對多交集表來關聯兩個實體，但從來沒有3.我想知道是否有人做過這樣的事情，如果有任何潛在的陷阱我應該保持。該表是這樣的：三個實體交點表「many-many-many」

create table BENEFIT_MEM_TYPE_PROVIDER 
(
    BENEFIT_ID reference BENEFITS not null, 
    MEMBERSHIP_TYPE_ID reference MEMBERSHIP_TYPES not null, 
    PROVIDER_ID reference PROVIDERS not null, 
    primary key (BENEFIT_ID, MEMBERSHIP_TYPE_ID, PROVIDER_ID) 
)

一下這關係就是不正確的坐我，所以我想我問這個聰明人的任何意見。

感謝

來源

2010-08-09 Sanjay Ginde

我們需要更多信息：規則是什麼？優惠是否與MemberShip和/或Provider相關聯，反之亦然？員工能否只有一個或兩個（現在，他不能所有字段都不爲空）。員工在哪裏適應？（EmployeeId沒有列。 – Goblin 2010-08-09 20:04:18

是的。

三元關係的使用非常廣泛，儘管不如二元關係那樣廣泛。這甚至可以擴展到第四元或一般n元關係。

您可以在數據庫設計中看到n元關係的一個地方是星型模式。星形中心的事實表是n元關係，其中n是事實表引用的維度表的數量。

標準化過程包括檢測偏離某些標準形式，並分解表格以產生更加標準化的等效。分解有時會降低n元關係的順序。

星型模式故意走另一條路。這就是爲什麼星型模式和標準化經常被看作是彼此不一致的原因。

來源

2010-08-10 09:43:07

任何人做過這樣的事情

是。

如果有任何潛在的缺陷，我應該保持。

如果Benefit-Membership，Benefit-Provider和Membership-Provider之間存在可能對此表中的數據顯示爲真的關係，但實際上不應該爲真，則可能會導致問題。

例如，成員 - 提供者 - 利益可能具有「限制」，只有當涉及特定提供者時，利益才適用於成員。這種關係可能不是真實的，但由於某種限制，它是一種特殊情況。

在這種情況下，您需要在此表中攜帶該限定條件，以確保這些特殊情況可以通過簡單的SQL查詢正確發現。

簡而言之，當您有超過1個關係時，請確保每行中的成對關係也是正確的。

來源

2010-08-09 20:02:01

您應該驗證您的表是否滿足第五範式（5NF）。如果不是的話，最好將其歸一化，以使其處於5NF。

來源

2010-08-09 22:50:32 sqlvogel

三個實體交點表「many-many-many」

回答

相關問題