Database design 复杂实体的数据模式-哪种方法更简单

我正在检查一个数据库模型。我需要一些关于模型一部分的帮助。在这个阶段，我只关心逻辑模型，而不是实现。我想采用一种最佳做法

问题摘要

• 该数据库由一个为律师事务所管理法律案件的应用程序使用

• 每个案件都有多个当事人。（所谓当事人，我指的是现实世界中与本案有利害关系的某个法律实体。）

• 大约有40种不同类型的派对

• 其中2种类型可以是一个人、一个组织或以任何组合结合在一起的多个人和/或组织

• 其他38种类型可以是一个人或一个组织

• 每个案例总是有两个复杂类型的当事人（即可能是个人和组织的组合）

• 通常每个案件总共有5到10个当事人

选项

每一方都被建模为任意数量的个人和组织的潜在组合。这些表如下所示：

• 案例
  当事人
  如果各方可能是个人和组织的组合：
• 当事人
  人
• 党组织

或者，我用3种不同类型的CasePartyAssignment表对此进行建模

第一个与上面的1相同，它涵盖了复杂的场景：

• 案例
  ComplexParty
  此外，我还为简单场景添加了特定的表：

• 案例
  人

• 案例
  组织

在我看来，这两种选择都有优点和缺点。例如，在选项1中，我创建了一种存储数据的单一方法，由于一致性，这种方法本身很简单。但这意味着我还可以用PartyPerSonaAssignment来模拟一个我知道是一个简单的人的政党，PartyPerSonaAssignment是用来模拟复杂政党的

---

有人对这些选项有什么意见吗？

我认为选项1更灵活。使用选项1，您可以通过从多对多表中添加或删除记录来添加或删除参与方中的人员或组织，而使用选项2，如果您从简单的单人或单组织设置开始，将其修改为复杂参与方会有点笨拙。我想我更喜欢将角落案例排除在数据模型之外，并尝试使用一个灵活的模型，该模型可以以与更复杂的案例相同的方式处理角落案例

---

我认为将单个实体案例表示为一方并不太糟糕，即使在这种情况下该方是不必要的。

我会对其进行稍微不同的建模：

• 人
• 组织机构
• PerOrg：超级类型的个人/组织，即法律性
• 政党：复杂政党或简单政党
• PerorgPartySignment：PerOrg和Party之间的关系，每个Party可以有一个或多个PerOrg（但至少一个）
• 案例：这里只有PlantifParty和DefendentParty

---

PerOrg概念（又名“任何人”/“法人实体”/“当事人”…）对于任何涉及商业关系的数据模型来说都是一个非常强大的概念。我已经多次使用它，当存在看似复杂的关系时，它总是会简化数据模型。

在这个模型中，我不确定PerOrg super类型的细节。如果您的意思是PerOrgId将是个人和组织表上的非强制性FK，那么这在我们的情况下不起作用，因为我们需要一个人或组织潜在地加入到这些超级类型中的多个。或者你是说PerOrg有PerOrgId，PersonId，OrgId专栏？后者接近选项1，但我不确定这样做有什么好处。不，佩罗，这是一种超级类型。超类型意味着PerOrgID是PK，而不是FK。有关子类型和超级类型的示例，请参见。我会选择第一种。