“钻石形关系”正式术语是什么？

Question

考虑以下“菱形”实体关系图：

我试图找到一些正式的解读，为什么这是一个糟糕的设计-但谷歌“钻石形表关系”只会出现ERD的符号。

这段关系叫什么？为什么它是一个糟糕的表设计(如果是)？

Answer 1

您必须添加乌鸦脚(或任何您喜欢的符号)，我们才能正确地理解图表。我选择把它解释为自上而下的指导。

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

Fig: Diamond pattern

我不记得曾见过这种模式显式命名。“钻石”似乎和其他的一样好。

因此，我不认为这是一个循环引用。要做到这一点，你必须能够跟随“许多”回到原点：

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

Fig: Circular reference

我怀疑钻石图案是一个糟糕的设计的前提。对于某些应用程序，这可能是完全合适的。也许这对你不合适。

作为一个玩具的例子，考虑一个小型的多租户应用程序来跟踪热腾腾。我们有实体类型的公司，员工，办公桌和DeskAllocation。A公司雇用许多雇员。本公司提供许多办公桌。每个员工每天都可以坐在不同的办公桌上。当然，雇员只能坐在雇主提供的办公桌旁。

我们可以根据我们提供的商业登记号码或虚构的号码来确定公司的身份.无所谓。我们称之为CompanyId。

公司为员工创建员工ID。因为每一家公司都有一名希望被雇佣的员工，所以我们必须有一个(CompanyId，EmployeeId)的复合密钥。

每家公司都有自己的办公桌标签方案，但大多数都使用一个简单的数字序列。因此桌子的PK是复合的(CompanyId，DeskId)。

那么DeskAllocation的PK是什么呢？它将是员工的PK，办公桌的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
)

这似乎是人为的，但我已经在汽车定价的应用程序中实现了这个模式。

Answer 2

地狱是正式术语。也许尝试使用星型，类似于DB仓库。查找“数据库模式的模式和反模式”。如果您确实编程钻石，我建议预先填充您的价值表列表的管理界面，而不是您的生产数据加载接口。