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

时间:2009-08-25 06:12:16

标签: database-design

我正在审核数据库模型。我需要一些模型的帮助。在这个阶段,我只关心逻辑模型,而不是实现。我想采用最佳做法。

问题摘要

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

  • 每个案件都有多方。 (通过聚会,我的意思是现实世界中的一些法律实体与案件有利害关系。)

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

  • 这些类型中的2种可以是单个人,单个组织,或以任何组合连接在一起的多个人和/或组织。

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

  • 每个案件总共有2个复杂类型的政党(即可能是个人和组织的组合)。

  • 通常每个案件共有5到10个派对。

选项

  1. 每一方都被建模为可能是任意数量的人和组织的组合。表格如下所示:

    • 案例< - CasePartyAssignment - >
      如果所有各方都可能是个人和组织的组合:
    • 派对<- PartyPersonAssignment ->
    • 派对<- PartyOrgAssignment ->组织
  2. 或者,我使用3种不同类型的CasePartyAssignment表对其进行建模。

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

    • 案例<- CaseComplexPartyAssignment -> ComplexParty

      此外,我还为简单的场景添加了特定的表格:

    • 案例<- CasePersonAssignment ->

    • 案例<- CaseOrgAssignment ->组织
  3. 我认为,两种选择都有优点和缺点。例如,在选项1中,我创建了一种存储数据的方法,由于一致性,这本身就很简单。但这意味着我还使用PartyPersonAssignment模拟复杂派对来模拟我认识的派对。

    有没有人对这些选项有任何意见/看法?

2 个答案:

答案 0 :(得分:1)

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

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

答案 1 :(得分:0)

我会以不同的方式对其进行建模:

  • 组织
  • PerOrg:超级类型的人/组织,即LegalEntity
  • 派对:复杂派对或简单派对
  • PerOrgPartyAssignment:PerOrg与Party之间的关系,每个派对可以有一个或多个PerOrgs(但至少有一个)
  • 案例:这里你只有PlantiffParty和DefendentParty

PerOrg概念(又名“任何人”/“法律实体”/“派对”......)对于涉及商业关系的任何数据模型都是一个非常强大的概念。我已经多次使用它,当看似复杂的关系时,它总是最终简化数据模型。