“鑽石形關係”的正式術語是什麼？

考慮以下“菱形”實體關係圖：

我試圖找到一些關於為什麼這是一個糟糕的設計的正式讀物 - 但Google搜尋“鑽石形表關係”只會出現 ERD 符號。

這種關係叫什麼？為什麼它是一個糟糕的表格設計（如果是的話）？

您必須添加烏鴉腳（或您喜歡的任何符號）才能讓我們正確理解圖表。我選擇將其解釋為自上而下的指導。

   top table
    |     |
    ^     ^
  Left   Right
     |    |
     ^    ^
     Bottom

Fig: Diamond pattern

我不記得曾經看到過明確命名的這種模式。“鑽石”似乎和任何東西一樣好。

因此，我不認為這是一個循環引用。為此，您必須能夠跟隨“許多”回到原點：

 First ---< Second
   v           |
   +-- Third >-+

Fig: Circular reference

我質疑菱形圖案是一個糟糕設計的前提。對於某些應用，它可能是完全合適的。也許它只是不適合你的。

作為一個玩具範例，考慮一個小型多租戶應用程序來跟踪共享辦公桌。我們有實體類型 Company、Employee、Desk 和 DeskAllocation。一家公司僱傭了許多員工。公司提供許多辦公桌。每個員工每天都可以坐在不同的辦公桌前。自然，僱員只能坐在雇主提供的辦公桌前。

我們可以通過公司的商業登記號或我們提供的虛構號碼來辨識公司。沒關係。我們將呼叫此 CompanyId。

公司為其員工創建員工 ID。由於每家公司都有一名員工想成為第一名員工，因此我們必須有一個複合鍵 (CompanyId, EmployeeId)。

每家公司都有自己的辦公桌標籤方案，但大多數都使用簡單的數字序列。所以 Desk 的 PK 是複合的（CompanyId，DeskId）。

那麼DeskAllocation的PK是什麼？它將是Employee的PK，Desk的PK和一個日期列。前兩個本身是複合的，每個都包含 CompanyId。這似乎是多餘的，甚至是錯誤的，但對於執行“坐在雇主的辦公桌前”規則是不可或缺的。這可以作為檢查約束來實現。

DeskAllocation 的虛擬碼將是

table DeskAllocation
(
 DeskCompanyId,
 DeskId,
 EmployeeCompanyId,
 EmployeeId,
 AllocationDate

 primary key
 (
   DeskCompanyId,
   DeskId,
   EmployeeCompanyId,
   EmployeeId,
   AllocationDate
 )

 foreign key FK_Desk
 (DeskCompanyId, DeskId) references Desk(CompanyId, DeskId),

 foreign key FK_Employee
 (EmployeeCompanyId, EmployeeId) references Employee(CompanyId, EmployeeId)

 constraint CHECK DeskCompanyId = EmployeeCompanyId
)

這似乎是人為的，但我已經在汽車定價應用程序中實現了這種模式。

地獄是正式的術語。也許嘗試使用星形模式，類似於 DB 倉庫。尋找“數據庫模式的模式和反模式”。如果您確實對鑽石進行程式，我建議您使用管理界面而不是生產數據載入界面預先填充您的值表列表。

引用自：https://dba.stackexchange.com/questions/251065