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