如何在数据库中连接实体

Question

我正在尝试设计数据库。检查图像

如您在图片中所见，我拥有公司，信托，合伙企业和一些类似的法人实体。 一个公司可以有一个或多个公司董事（一个董事可以是信托，合伙企业甚至是另一家公司） 信托可以有一个或多个信托受益人（受益人可以是公司，合伙企业甚至另一信托） 合伙企业可以有一个或多个合伙人（合伙人可以是公司，信托，甚至可以是另一个合伙人）

微型世界的描述是，用户将输入有关法人实体的数据，然后他们将在它们之间建立关系

有许多报告需要制作。最常用的是他们需要查看法人实体及其结构的人员，例如一家拥有董事的公司，并查看每位董事的详细信息。此处存在一个递归树，因为一个公司可以拥有另一个公司的董事

LegalEntity表在Company，Trust，Partnership和其他任何新实体（我大约还有20个）中都有FK。基于上述情况，我将获得LegalEntityId并将其提供给LegalEntityType。例如，如果LegalEntityType是Trust，则必须查询Trust表以获取更多详细信息。每次我需要检索某些内容时都使用switch语句并不是我认为的最简单和最佳方法。

Answer 1

链接它们的方法是通过外键。

但是在深入研究之前，我觉得您是在尝试先不了解逻辑数据模型的情况下处理物理数据模型的；您曾经去过这个resource吗？

公司董事，信托受益人和合伙人是一般案件联系的特殊案件；但是为此，您必须在联系人表中排除所有表明联系人是自然人的字段（成员）（例如Gender，DOB，我所没有看到的所有内容）。

因此，只需在CompanyDirector，TrustBeneficiary和PartnershipPartner中添加fk_contact字段；然后，将条件条件1：N关系中的id联系人字段作为主键链接到所有这些外键字段。

这样，您将在Partneship-Contact，Trust-Contact，Company-Contact之间建立N：N链接；中间的表是表示为表的关联实体。

当然，这取决于您实际使用哪种数据库来实现它。

并且，真诚的，我认为这个问题的表述不是那么糟糕……

编辑1 -基于分散的注释：

  

实体表在公司，信托，合伙企业和任何   其他新实体

这就是为什么Entity不是一个好的描述性名称的原因...从理论上讲，所有Actor / Object都可以映射到某个Entity ...

  

每次我想检索时都有一个switch语句   我认为这不是最简单，最好的方法

这就是为什么我们必须分离逻辑模型和物理模型的原因……即使在逻辑层次上正确的东西，我们也可能会根据访问某个属性/字段的数量以物理方式进行建模。有时我们对一个表进行非规范化，包括一些逻辑上属于子表的属性，只是不必支付磁盘或网络访问的费用...

如果您可以发布以下2条基本信息，将会更加容易：

1. 您的案例（即小世界）的纯英文无伪代码描述是什么？
2. 您需要生成哪些报告，即您必须回答哪些问题？

编辑2：此处，由于我的疑虑太多，请不要评论：

@codejunkie，在我看来，您的模型中的LegalEntity只是其他参与者/类的属性：Trust，Company和Partnership表具有相同的字段。

仅在“ Partnership / PartnershipPartner”表中关注：

该记录是否可能？与元组有关

PartnershipPartner.PartnershipId = Partnership.Id 

PartnershipPartner.LegalEntityId <> Partnership.LegalEntityId

如果没有，我认为一种更好且更具代表性的方式是：

一个大表LegalEntity，具有Trust，Company和Partnership的所有共同属性；附件表中的1-0..1具有排他性。

与TrustBeneficiary，PartnershipPartner和CompanyDirector的结构类似，它们共享的可能是之前模式中的Contacts表。

将执行递归，这与“人是人之父”的经典案例相同；该角色将成为关联实体。

编辑3：-基于评论@ 2019年2月1日

我没有问过或没有注意到的一件关键事情：这些表是否已经填充了真实数据，并且您正在尝试找出如何链接它们？如果是这样，这将改变很多事情。

但是，如果不是这样的话：

  

信任，公司和合作伙伴只有共同的名称，国家/地区   属性和电话。它们还有许多其他特性……它们都不是常见的。

了解但这并不否认它们是通用实体的专业化；现在我正在大声思考，试图整理我的零散物品：

1. 在我看来，LegalEntity是通用实体类型/类或超类型实体；信托，公司和合伙企业缩小了范围，从生物学上来说，“范围”缩小了范围；

2. 即使冒着谈论非常基本的问题的风险-让我知道是否是这种情况-在我看来，这是一个与您的情况类似的简单示例：考虑一个普通实体医师及其专业实体-心脏病专家，住院医生，内科医师等；医师通常是“人”或“联系”的专业案例；患者也是Person或Contact的专业案例；医生甚至可能成为患者！ 在这里，我们谈论的是现实世界中的角色。

3. 您看到的事实称为“信任”，“公司”和“伙伴关系”的抽象具有一些中心的公共属性和许多不同的属性，但并没有告诉我们是否应该将其封装在通用类/实体中，因为我如图所示，趋向于或相反。您的“报告需求”，您需要表示和保留的属性和关系是理想逻辑设计的指南。

4. 仅在我们必须或可以将注意力转移到物理设计之后。

5. 但是，您的问题似乎全都错了。根据评论，这可能会导致投票失败。

返回评论：

  

PartnershipPartner.PartnershipId = Partnership.Id，您是正确的。

好

但是有一个不好的事实：

PartnershipPartner.LegalEntityId <> Partnership.LegalEntityId you are again correct. 

我不明白：是否可以（通过LegalEntity表）将所有LegalEntityType实例（来自同一表名）应用于所有表？我明白 Trust，Partnership和Company接收相同的LegalEntityType属性，但是，如果TrustBeneficiary，PartnershipPartner和CompanyDirector在执行其他角色时可以接收相同的LegalEntityType实例，则不会。如果是这种情况，即使不是;），最好编辑您的帖子并添加一些Report示例和/或一些表/表格示例，如果使用非规范化记录则更好。

编辑4： 根据2019年2月2日之后的评论：

我认为这是对您所需要的更接近的表示：