我最近对数据建模进行了一些阅读，并对实体可能扮演的角色提出了疑问。实体关系建模：如何实现实体“角色”？
考虑一个简单的情况下，你已经有了一个公司，并且公司可以是供应商，客户，分销商等，或这些角色的组合。所以X公司可能既是供应商又是客户。
下在数据层面，你可能对公司的再表对供应商，客户等引用该公司表的表。至少我认为这是如何表示的。
好了，最多的地方在申请土地，你已经有了类客户和供应商等。每个人都会由一个公司组成，然后对这个特定的班级做任何其他特殊的事情。
这就是全部确定，对我来说很有意义，只要我们只用一个实体类在同一时间工作。如果我们想从一家公司开始，看看它在扮演什么角色呢？所以在一个应用程序中，我可能会拉起一个公司，看看它是一个供应商还是一个分销商。
现在有几种不同的方式我能想到的要做到这一点，但我觉得，因为这个问题域太旧，必须有用于建模这些概念的一些尝试和真正的模式。
因此，我在这里搜索的是用于在应用程序级建模实体角色的常用策略或模式。关于这个特定主题的具体参考材料将不胜感激（无论是博客或书籍或其他）。
我害怕，我不能给“常见模式”如何处理这个问题。但我也认为，根本不存在“唯一”的模式。
原因是，建模是某种“模糊”。我记得德国电脑杂志中的一些非常相似的造型问题。这是一种比赛，他们展示了他们获得的不同解决方案。解决方案完全不同，但所有这些解决方案都是有效的。我认为这也取决于手头问题的细节。有时，一个“瘦”的解决方案是美丽的......在其他情况下，“大，脂肪，盛大的”解决方案必须要做，以满足项目的需求...
比如，造型依旧是许多创造性的任务自由参数。
当然，有一些“元模式”，这是“商定的”。例如在着名的“四人帮” "Design patterns"和其他许多可用的书中。但仍然存在很多问题，没有达成一致的“最佳”解决方案。
就你而言，可以使用子分类（这相当于专业化）。也可以将“供应商”等作为一个可能/可能不被公司支持的接口（这可以被视为来自抽象实体的可选专业化）。但也可以使用合成物来解决同样的问题。角色可以是由公司链接的对象（实体）（例如，具有关系“has-role”）。
我会推荐使用继承作为最后的手段。像这样的关系不是直截了当的，而且很容易通过早期优化的形式弄坏设计。 当公司既可以是供应商也可以是分销商时，您不希望创建具有供应商或分销商属性的公司。相反，想想它会像正常化数据库一样。你有一组概念如下
这会使公司，供应商和分销商之间的耦合保持较低水平。
另一个例子是当一个类有一个状态。很多时候，概念模型使用继承来展示类是如何为了处理不同的可能状态而具有多态的子类的类的实例。当你必须改变实例的状态并且你意识到你的指针会失效和/或受影响的实例可能被克隆，或者在集合中很难或保持更新时，这会导致问题。因为您必须创建另一个类的新实例，然后将指针替换为目标公司，如果有多个副本或实例包含在容器或列表中，则该指针可能会很困难。更简单更干净的解决方案是让类包含一个类型为BaseClass的元素，它具有可能的子状态。这样，当您想要更改nobject的状态时，可以通过简单地用更新的具体类型替换status属性来处理它。
您可能想使用Object Role Modeling查看数据库设计。它从根本上使用您在问题陈述中使用的表达式类型，断言对象（实体）相互关联的角色。除其他功能外，它还可以生成完整的关系数据库设计。
大多数DBMS s不适合这个问题，因为他们缺乏所需的灵活性。我想这就是为什么Charles Bachman在1977年通过添加角色概念延伸了CODASYLnetwork data model（另请参阅The role data model revisited（PDF））。然而，恕我直言巴赫曼仍然受Hierachical data model影响太大，从业主/成员关系角度来看。
从概念上讲，手头的问题对应于图形/网络。如果将实体建模为节点，则边（关系）将携带标签来指示角色。例如，一个订单实体可能有一个“有序”关系连接到其他实体，可能是一个人，一个公司或其他实体。当您遵循“按顺序排列”的关系时，您知道目标节点代表实现Orderer接口的实体。
在数学语言中，这里需要的是一个带标签的定向多图。你会发现在像Neo4j（我参与的开源项目）或RDF这样的本地图形数据库中都是如此。在RDBMS之上还有RDF实现。也许图的概念也可以给你一些关于如何从头开始实现的提示。我还在我的博文Flexibility in data modeling中简要讨论角色概念。
我在这里谈论更多关于“面向对象的建模”，而不是关于“ER建模”。我希望它仍能提供一些见解，因为对我而言，它们之间并没有太大的区别。 – Juergen 2009-06-17 22:18:19