我最近对数据建模进行了一些阅读，并对实体可能扮演的角色提出了疑问。
考虑一个简单的案例，即您拥有公司，公司可以是供应商，客户，分销商等，或者这些角色的组合。因此，X公司可能既是供应商又是客户。
在数据级别，您可能有一个CompanyS表，然后是SupplierS，CustomerS等引用Company表的表。至少我认为这是如何表现的。
好的，所以在应用程序领域的某个地方你可以获得CustomerS和SupplierS等课程。每个都由一个公司组成，然后是关于该特定类别的任何其他特殊内容。
只要我们一次只使用一个实体类，那对我来说一切正常并且有意义。如果我们想从公司开始并看看它正扮演什么角色怎么办？因此，在一个应用程序中，我可以选择一家公司，看看它是供应商和分销商。
现在我可以通过几种不同的方式来做到这一点，但我觉得因为这个问题域太老了，所以必须有一些经过验证的真实模式来建模这些概念。
因此，我在这里寻找的是在应用程序级别建模实体角色的常用策略或模式。关于这一特定主题的具体参考资料将不胜感激（无论是博客，书籍还是其他）。
答案 0 :(得分：1)
我建议仅使用继承作为最后的手段。像这样的关系并不简单，很容易通过早期优化的方式来破坏设计。 当公司既可以是供应商也可以是分销商时，您不希望创建具有供应商或分销商属性的公司。相反，想想它就像你将数据库规范化一样。您有一组概念如下
这使公司，供应商和分销商之间的耦合保持在较低水平。
另一个例子是当一个类有一个状态。很多时候，概念模型使用继承来显示类是如何为了处理不同的可能状态而具有多态儿童的类的实例。当您必须更改实例的状态并且您意识到指针将被无效和/或可能克隆受影响的实例或以其他方式收集困难或保持更新时，这会导致问题。因为您必须创建另一个类的新实例，然后将指针替换为目标公司，如果有多个副本或者实例包含在容器或列表中，则可能很难。更简单，更清晰的解决方案是让类包含一个类型为BaseClass的元素，该元素具有可能的状态作为子元素。这样，当您想要更改nobject的状态时，可以通过使用更新的具体类型简单替换status属性来处理它。
答案 1 :(得分：1)
您可能希望使用Object Role Modeling检查数据库设计。它从根本上使用您在问题陈述中使用的类型的表达式，断言对象（实体）相互之间扮演的角色。在其他功能中，它可以生成完整的关系数据库设计。
答案 2 :(得分：1)
大多数DBMS不适合这个问题，因为它们缺乏必要的灵活性。我想这就是为什么Charles Bachman在1977年通过添加角色概念来提出CODASYL network data model的扩展（参见The role data model revisited（PDF）） 。然而，在Hierachical data model的影响下，恕我直言Bachman仍然太多，从主人/成员关系集的角度思考。
从概念上讲，手头的问题对应于图表/网络。如果将实体建模为节点，则边（关系）将带有标签以指示角色。例如，Order实体将具有连接到某个其他实体的“ordered by”关系，该实体可以是Person，Company或其他。当您遵循“ordered by”关系时，您知道目标节点表示实现Orderer接口的实体。
在数学术语中，这里需要的是带标签的有向多图。你会发现在本地图形数据库中都有Neo4j（我参与的开源项目）或RDF。在RDBMS之上还有RDF实现。也许图表概念也可以给你一些关于如何从头开始实现这一点的提示。我还在我的博文Flexibility in data modeling中简要讨论了角色概念。
答案 3 :(得分：0)
原因是，建模在某种程度上是“模糊的”。我记得德国电脑杂志中有一些相似的建模问题。这是一种比赛，他们展示了他们发送的不同解决方案。解决方案完全不同，但所有这些都在某种程度上有效。我认为这也取决于手头问题的细节。有时候“精益”解决方案很漂亮......在其他情况下，必须采用“大，肥，大”的解决方案来满足项目需求......
例如，建模仍然是一项具有许多免费参数的创造性任务。
当然，有一些商定的“元模式”。例如在书中 "Design patterns"由着名的“四人帮”和其他许多人提供。但是仍然存在许多问题，其中没有商定的“最佳”解决方案。
在您的情况下，可以使用子类（这相当于专业化）。也可以使“供应商”等只是公司可能/可能不支持的接口（这可以被视为抽象实体的可选专业化）。但是也可以使用组合物来解决同样的问题。角色可以是由公司链接的对象（实体）（例如，与“has-role”关系）。