代码之家 › 专栏 › 技术社区 › Boden

实体关系建模:如何实现实体角色?

oop entity-relationship data-modeling

Boden · 技术社区 · 16 年前

我最近读了一些关于数据建模的文章,有一个关于实体可能扮演的角色的问题。

考虑一个简单的例子,你有一个公司,一个公司可以是一个供应商,客户,分销商等等,或者这些角色的组合。所以X公司可能既是供应商又是客户。

在数据级别,您可能有一个公司表,然后是供应商、客户等的表,它们引用了公司表。至少我认为这就是它的表现方式。

好吧,在申请表的某个地方,你有客户和供应商的课程等等。每一个都是由一个公司组成的,然后是关于这个特定类的任何其他特殊的东西。

只要我们一次只处理一个实体类,这一切都没问题,对我来说也是有意义的。如果我们想从一家公司开始,看看它在扮演什么角色呢?所以在一个应用程序中,我可能会拉一个公司,看看它是供应商和分销商。

现在有几种不同的方法我可以想到这样做,但我觉得,因为这个问题域太老了,必须有一些尝试和真实的模式来建模这些概念。

因此,我在这里寻找的是在应用程序级别上建模实体角色的常见策略或模式。关于这一特定主题的具体参考资料将非常感谢(无论是博客或书籍或其他)。

4 回复 | 直到 16 年前

Kelly S. French 16 年前

我建议把继承作为最后手段。像这样的关系并不简单,很容易通过一种早期优化的形式破坏设计。当一个公司既可以是供应商也可以是经销商,你不想创建一个具有供应商或分销商属性的公司。相反,把它想象成规范化数据库。你有一套概念如下

公司 (公司ID,名称,属性1,属性2)
供应商 它们是公司(SupplierID、CompanyID[外键]、Attrib1、Attrib2)
分销商 (DistributorID,CompanyID,Attrib1,Attrib2)也是公司
买卖关系 (RelationshipID、SupplierID、DistributorID、Attrib1、Attrib2)如果需要跟踪供应商和分销商之间连接的详细信息

这使得公司、供应商和分销商之间的耦合度很低。

另一个例子是当一个类有一个状态时。为了处理不同的可能状态,概念模型多次使用继承来显示类是一个具有多形子类的类的实例。当您必须更改实例的状态,并且您意识到指针将失效和/或受影响的实例可能被克隆或位于集合中时,这将导致问题,而这些集合将很难或保持更新。因为您必须创建另一个类的新实例,然后替换指向目标公司的指针,如果有许多副本,或者实例包含在容器或列表中,则这可能很困难。更简单、更干净的解决方案是,类包含一个基类类型的元素,基类的可能状态为子类。这样,当您想要更改nobject的状态时,可以通过使用更新的具体类型简单地替换status属性来处理它。

dkretz 16 年前

您可能希望使用 Object Role Modeling . 它基本上使用问题陈述中使用的类型的表达式,断言对象(实体)相互之间所扮演的角色。在其他能力中,它可以生成完整的关系数据库设计。

这里是 another reference .

nawroth 16 年前

大多数 DBMS s不适合这个问题,因为它们缺乏所需的灵活性。我想这就是为什么 Charles Bachman 提出了一个 CODASYL network data model 早在1977年,通过添加角色概念(另见 The role data model revisited ( PDF )然而,巴赫曼仍然受到太多的影响。 Hierachical data model ,根据所有者/成员关系集进行思考。

在概念上,手头的问题对应于一个图/网络。如果将实体建模为节点,则边(关系)将带有指示角色的标签。例如,一个订单实体将有一个“按订单”关系连接到另一个实体,这个实体可以是一个人、一家公司或其他什么东西。当遵循“ordered by”关系时,您知道目标节点表示实现order接口的实体。

在数学术语中,这里需要的是一个有标记的有向多重图。在本机图形数据库中,您会发现 Neo4j (我参与的开源项目)或 RDF . 在 RDBMS 也许图形概念还可以给你一些关于如何从头开始实现这一点的提示。我也在我的博客文章中简要讨论了角色概念 Flexibility in data modeling 。

Juergen 16 年前

我担心,我不能给出“共同模式”如何处理这个问题。但我也认为,根本不存在“唯一”模式。

原因是,这个模型有点“模糊”。我记得德国一家电脑杂志上有一个类似的模型问题。这是一场竞赛,他们展示了不同的解决方案。完全不同的解决方案,但它们都是有效的。我认为这还取决于手头问题的细节。有时一个“精益”的解决方案是美丽的…在其他情况下,必须做“大,胖,大”的解决方案,以满足项目的需要…

例如,建模仍然是一项具有许多自由参数的创造性任务。

当然也有一些“元模式”是一致同意的。例如在书中 "Design patterns" 由著名的“四人帮”和许多其他可用。但仍然存在许多问题,没有商定的“最佳”解决办法。

在您的情况下,可以使用子分类(这相当于专门化)。也可以使“供应商”等仅仅是一个公司可能/可能不支持的接口(这可以看作是抽象实体的可选专门化)。但同样的问题也可以用构图。角色可以是由公司链接的对象(实体)(例如,与关系“has role”)。