偶尔我会遇到以下所有条件都适用于两个高度相似但不完全相同的实体或对象的情况。这使我很难决定如何在数据库端或对象建模方面对它们进行建模。我将尝试详细说明问题和我的问题，因为我发现这是一个非常难以定义的建模问题。我试图用这些实体进行数据和对象建模，所以我会稍微松散地使用这两个学科的术语。
1）两个实体共享许多相同的属性，但有一些在另一个中找不到的唯一属性。
2）一个不是另一个的超类型或子类型。
3）重叠不是由于对象继承造成的。
4）对象在同一个域中用于不同的目的，但通常在任何工作流程中都非常接近。这经常导致具有中等领域知识的人混淆实体。另一方面，这种精细分离的目的导致相关对象的方法之间的差异大于它们的属性。
5）在某些情况下，可以在数据库端创建桥接表以表示实体之间的M2M关系。然而，它们有许多共同的属性（或数据库方面的列），将它们存储在同一个表中可能是有意义的。
我遇到的一些案例包括： 1）＆＃34;产品与项目混淆＆＃34; - 特别是在软件营销中，产品和项目共享许多相同的属性。通常情况下，产品会有多个与之相关的项目，但是在多个产品中使用项目也是不寻常的。
2）软件开发中功能和组件之间的细微差别。从客户的角度来看，功能是以开发人员为中心的一种提供好处的方法，而组件是在开发人员方面实现功能的一种方式。这是一个非常微妙的区别，但仍然很重要。有关进一步讨论，请参阅Rod Maupin在http://www.installationdeveloper.com/347/features-and-components-101/
的帖子3）许多不同问题域中的模板与类型。例如，当通过TypeID列识别吉他类型时，它引用的TypeTable可能具有与颜色，字符串大小，体形等相对应的列。另一方面，模板是您构建的内容一把吉他，所以它有不同的类型的方法，可能与一个＆＃34;应用模板＆＃34;或＆＃34;从模板制作项目＆＃34;菜单命令。然而，它将具有许多与类型相同的列或属性，例如颜色，形状，字符串大小等。这种区别在许多问题域中引发了数千种不同对象类型和模板，而不仅仅是这个狭窄的例子。更复杂的是，在某些情况下，将多个模板与特定类型相关联可能会有所帮助，反之亦然。反之亦然。
我经常遇到这个重叠实体的问题，但是当它确实发生时，它就成了一个真正的瓶颈，并导致大量浪费时间重构数据和对象模型。我已经阅读了有关这两个主题的书籍，并对数据/对象建模网页进行了大量关于该问题的搜索，但还没有看到它的讨论。唯一的点击＆＃34;重叠＆＃34;和＆＃34;数据模型＆＃34;我可以在StackOverflow上找到区分一个表或实体中的类似列，而不是跨表或实体。我的问题是：
1）这个问题是否有正式名称？
2）当后期识别使重构成为一个问题时，是否有一个简单的快捷方式或交易技巧可以在建模过程开始时识别出这些重叠的实体，而不是更深层次？
3）如何处理这些重叠的实体？我假设在OOP方面，它们应该有单独的对象，因为它们的方法往往不同。尽管如此，从另一个继承一个会很尴尬。一个更难的问题是在数据库端使用单独的表是否有意义。组合它们可能需要一系列复杂的视图加上废物存储空间，当它们没有共同的属性/列保持为空时。如果公共属性可以存储在单个列中，那么将它们存储在单独的表中也可能是浪费的。
甚至认识到这一点很棘手，更不用说处理了。我对数据/对象建模只有一定的经验，所以真正了解他们正在做什么的人的输入会有所帮助。谢谢:)）
答案 0 :(得分：1)
您的问题涉及面向对象（编程）建模方面的数据库建模方面。让我们从抽象的角度出发。
你说：
1）两个实体共享许多相同的属性，但有一些在另一个中找不到的唯一属性。
2）一个不是另一个的超类型或子类型。
和
3）重叠不是由于对象继承造成的。
但请注意，继承不应与子类型混淆，即使很多次它们被捆绑在一起！请参阅维基百科中的Inheritance (object-oriented programming)，其中两个引文[1，2]支持此声明。
换句话说，即使A不是B的子类型，而B不是A的子类型，也可以找到A和B都继承属性的C。
所以，你可以认为这个C是A和B的“抽象超类型”;但无论如何，至少从数据库的角度来看，将其视为共同的祖先是很方便的，因此将“公共”属性分解为“超级”。
然后，从面向对象的编程方面，您可以将A或B视为C的子类型或简单视为两个不同的东西，具体取决于对象关系映射工具的特征，手头的问题等。
当然，这种建模方式并不禁止A和B，除了继承自C之外，它们之间有一个或多个关系，如您所做的示例产品 - 项目。
所以，这是我对你最后四个问题的回答：
1）是的，它被称为继承。
2）您可以检查两个实体是否具有大量公共属性。
3）您可以使用公共表在数据库中对它们进行建模，这可能具有一些常见属性，如完整性约束，以及两个具有外键的表。当然，这条规则不能盲目应用，但可以像所有人类规则一样例外。另一方面，从编程的角度来看，您可以决定是否使用超类型对它们进行建模。这取决于许多因素，应根据具体情况决定。