架構設計：異構類型（不同目標）的一對一外部關係，但角色相同

我一直在努力構建一個更抽象的模式，其中有幾個表建模非常相似的關係，我只想建模「本質」。由於我正在使用的環境（Drupal 7），我無法改變問題的性質：相同基本類型的關係可以爲一個角色中的對象引用兩個不同表中的一個。讓我們引入一些示例來澄清（這不是我的實際問題域，而是一個類似的問題）。這裏是要求：架構設計：異構類型（不同目標）的一對一外部關係，但角色相同

首先，如果你不熟悉Drupal，這裏的要點是：一個表中的用戶，一個第二表中的所有其他實體（總泛化，但足夠）。假設我們想要爲「爲...工作」關係建模，並且讓給定的是「公司」是「實體」類型，「主管」是「用戶」類型（並且是「類型」I這意味着這是數據庫中他們的元組所在的表）。下面是簡化的要求：

用戶可以爲公司
公司可以攜手爲一家公司
這些「作品」的關係應該是在同一個表。

我有兩個想法，兩者都不完全適合我目前對模式質量的傾向，這是我想要的一些見解。

一個外鍵列有「類型」列
兩個外鍵列，總是在最一個利用配對（益！）

如果你是一個視覺的思想家，這裏是代表用戶123和632，以及實體123的實體435的所有工作的事實，兩個選項：在選項1

Option 1 
+---------------+-------------+---------------+-------------+ 
| employment_id | employee_id | employee_type | employer_id | 
+---------------+-------------+---------------+-------------+ 
|    1 |   123 |   user |   435 | 
+---------------+-------------+---------------+-------------+ 
|    2 |   123 |  entity |   435 | 
+---------------+-------------+---------------+-------------+ 
|    3 |   632 |   user |   435 | 
+---------------+-------------+---------------+-------------+ 

    Option 2 
+---------------+------------------+--------------------+-------------+ 
| employment_id | employee_user_id | employee_entity_id | employer_id | 
+---------------+------------------+--------------------+-------------+ 
|    1 |    123 |    <NULL> |   435 | 
+---------------+------------------+--------------------+-------------+ 
|    2 |   <NULL> |    123 |   435 | 
+---------------+------------------+--------------------+-------------+ 
|    3 |    632 |    <NULL> |   435 | 
+---------------+------------------+--------------------+-------------+

思考：我喜歡EMPLOYEE_ID列有具體角色，但我鄙視它有模棱兩可的目標。選項2具有模糊的角色（哪一列是員工？），但對於任何給定FK具體的目標，所以我認爲它是這樣的：

+-----------+-----------+----------+ 
|   |   ROLE   | 
|   | ambiguous | concrete | 
+-----------+-----------+----------+ 
| T   |   |   | 
| A ambig. |   |  1 | 
| R   |   |   | 
| G -------+-----------+----------+ 
| E   |   |   | 
| T concr. |  2  |  ? | 
|   |   |   | 
+-----------+-----------+----------+

方案二有非常務實的好處爲我的項目，但我對這麼多的空值感覺不舒服（你甚至可能稱之爲1NF！）

所以這裏是我的問題癥結所在：我怎麼可以改進選項1，否則我可能會有哪些知識缺口這讓我不安？雖然我無法想起它違反的具體的規則，但設計顯然不符合規範化的意圖（需要兩列來唯一標識關係並沒有幫助我防止異常）。

我不明白，理想的解決辦法是重新設計用戶實體是相同正如我一直在呼籲「實體」在這裏，但請考慮跑題/間接（或至少讓我們在這個問題的正確的地方繪製實用的線）。

同樣，基本問題：在規範化方面，模式選項1有什麼問題，以及如何在不將「用戶」重構爲「實體」的情況下對這種關係進行建模？

注：對於這一點，我不是一個務實的解決方案

來源

2012-08-31 Chris Trahey

什麼是錯的選項1（和選項2）更熱衷於理論純潔性的是，它是一個多值的依賴，並作爲例如，違反第四種正常形式。但是，在你給出的約束條件下，你可以做的事情不多。

如果您可以用視圖替換worksfor表，那麼可以將用戶 - 公司和公司 - 公司關係分開。

在您的兩種選擇中，選項2的優勢在於，根據您的平臺，執行參照完整性可能更容易。

一個潛在的問題是，如果你現在的約束條件不好，實用的解決方案可能會給公司正面的ID和用戶負面的ID，從而消除了選項2的空欄，並將選項1的類型欄變成暗示，但我覺得骯髒甚至暗示它。

同樣，如果您並不需要知道什麼類型的實體，只要你可以通過加入，然後使用的GUID將其確定爲標識將消除對type列

來源

2012-08-31 06:09:23 podiluska

需要你目前的解決方案@podiluska說，違反了第四種正常形式。如果將其重新寫入下面的表格中，那麼解決方案將消除這種困難，並且處於5NF（甚至6NF？）的範圍內。

對sub/super類型採用其中一種模式。這使用下面列出的關係定義，加上超級/子類型約束。這個約束是超類型關係中的每個元組必須完全對應一個子類型元組。換句話說，子類型必須形成一個不相交的覆蓋超類型的集合。

我懷疑這在現實情況下的性能可能需要一些重調整：

Table: Employment 
    +---------------+-------------+ 
    | employee_id | employer_id | 
    +---------------+-------------+ 
    |    1 |   435 | 
    +---------------+-------------+ 
    |    2 |   435 | 
    +---------------+-------------+ 
    |    3 |   435 | 
    +---------------+-------------+ 
    Table: Employee (SuperType) 
    +---------------+ 
    | employee_id | 
    +---------------+ 
    |    1 | 
    +---------------+ 
    |    2 | 
    +---------------+ 
    |    3 | 
    +---------------+ 
    Table: User employee (SubType) 
    +---------------+-------------+ 
    | employee_id | user_id  | 
    +---------------+-------------+ 
    |    1 |   123 | 
    +---------------+-------------+ 
    |    3 |   632 | 
    +---------------+-------------+ 
    Table: Entity employee (SubType) 
    +---------------+-------------+ 
    | employee_id | entity_id | 
    +---------------+-------------+ 
    |    2 |   123 | 
    +---------------+-------------+

來源

2012-08-31 09:01:48

架構設計：異構類型（不同目標）的一對一外部關係，但角色相同

回答

相關問題