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

Question

我正在审查数据库模型。我需要部分模型帮助。在此阶段，我只关心逻辑模型，而不是实现。我想采用最佳做法。

问题总结


该数据库由管理律师事务所法律案件的应用程序使用。
每个案例都有多个当事人。 （通过聚会，我的意思是在现实世界中与案件有关系的一些法律实体。）
大约有40种不同类型的聚会。
这些类型中的2个可以是一个人，一个组织，也可以是任意组合在一起的多个人和/或组织。
其他38种类型可以是一个人或一个组织。
每个案件始终有2个复杂类型的当事人（即可能是个人和组织的组合）。
通常，每个案例中总共有5至10个政党。


选件


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


案例<-CasePartyAssignment->当事人
当所有各方都有可能是个人和组织的组合时：
派对<-派对人员分配->人物
派对<-派对组织分配->组织

另外，我使用3种不同类型的CasePartyAssignment表对此进行建模。

第一个与上面的1相同，其中涉及复杂的场景：


案例<- CaseComplexPartyAssignment -> ComplexParty

另外，我为简单的场景添加了特定的表：
Case <- CasePersonAssignment -> Person
Case <- CaseOrgAssignment ->组织



从我的角度来看，两种选择都有其优点和缺点。例如，在选项1中，我创建了一种存储数据的单一方法，由于一致性，它本身很简单。但这意味着我还使用PartyPersonAssignment设计了一个我知道是简单Person的政党，该政党旨在为复杂的政党建模。

有人对这些选项有任何建议/意见吗？

Answer 1

我认为选项1更灵活。使用选项1，您可以通过从多对多表中添加或删除记录来从一个方中添加或删除个人或组织，而对于选项2，如果您以一个简单的单个人或单个组织开始设置，将其修改为ComplexParty会比较麻烦。我想我更喜欢将极端案例排除在数据模型之外，而尝试仅使用一种灵活的模型来处理极端案例，就像处理更复杂的案例一样。

我认为将单个实体案例表示为一个缔约方并不算太坏，即使在这种情况下不需要该缔约方也是如此。