问题标签 [identifying-relationship]

我无法完全掌握这些差异。你能描述这两个概念并使用现实世界的例子吗？

我读过这个问题：识别关系和非识别关系有什么区别？

但我还是不太确定……我有的是三张桌子。

1. 用户
2. 对象
3. 图片

用户可以拥有许多对象，也可以为每个单独的对象发布许多图片。我的直觉告诉我这是一个识别关系，因为我需要对象表中的用户 ID，我需要图片表中的对象 ID...

还是我错了？另一个主题中的解释仅限于对数据库在编码后对其进行解释的方式的理论解释，而不是对象在现实生活中的连接方式。在考虑如何构建数据库时，我有点困惑如何做出识别与非识别的决定。

因此，我一直在阅读有关在我的数据库设计中识别与非识别关系的内容，并且一些关于 SO 的答案似乎与我相矛盾。这是我正在研究的两个问题：

1. 识别关系和非识别关系有什么区别
2. 难以确定识别或非识别关系

查看每个问题的最佳答案，我似乎对什么是识别关系有两种不同的想法。

第一个问题的回答说，标识关系“描述了子表中的行的存在依赖于父表中的行的情况”。给出的一个例子是，“一个作者可以写很多书（一对n的关系），但是没有作者就不能存在一本书。” 这对我来说很有意义。

然而，当我阅读对问题二的回答时，我感到困惑，因为它说：“如果孩子识别出它的父母，那就是一种识别关系。” 答案接着给出了一些例子，例如社会安全号码（识别一个人），但地址不是（因为很多人可以住在一个地址）。对我来说，这听起来更像是主键和非主键之间的决定。

我自己的直觉（以及对其他网站的额外研究）指出了第一个问题，并且它的回答是正确的。但是，我想在继续前进之前进行验证，因为我不想在我正在努力理解数据库设计时学习错误。提前致谢。

@JoinColumn和之间的确切区别是@PrimaryKeyJoinColumn什么？

您@JoinColumn用于作为外键一部分的列。一个典型的列可能看起来像（例如在具有附加属性的连接表中）：

如果我也将列提升为 PK（也称为识别关系），会发生什么情况？由于该列现在是 PK，因此我必须将其标记为@Id：

现在的问题是：

@Id+@JoinColumn和刚才一样吗@PrimaryKeyJoinColumn？：

如果不是，那@PrimaryKeyJoinColumn有什么用？

在尝试学习数据存储的艺术时，我一直在尝试获取尽可能多的可靠信息。PerformanceDBA 在以下帖子中发布了一些非常有用的教程/示例：我的数据是否标准化？和关系表命名约定。我已经在这里问了这个模型的一个子集问题。

因此，为了确保我理解他提出的概念并且我在其他地方看到过，我想更进一步，看看我是否掌握了这些概念。因此，这篇文章的目的，希望其他人也可以从中学习。我呈现的一切对我来说都是概念性的，用于学习而不是在某些生产系统中应用它。从 PerformanceDBA 获得一些输入也很酷，因为我使用他的模型开始，但我感谢任何人提供的所有输入。

由于我是数据库新手，尤其是建模新手，我将首先承认，由于缺乏该主题的专业知识，我可能并不总是提出正确的问题、清楚地解释我的想法或使用正确的措辞。所以请记住这一点，如果我偏离轨道，请随时引导我朝着正确的方向前进。

如果对此有足够的兴趣，我想从逻辑阶段到物理阶段来展示过程的演变，并在 Stack 上分享。不过，我将保留此线程用于逻辑图，并为其他步骤启动新线程。根据我的理解，我最终将构建一个 MySQL 数据库来运行一些测试，看看我想出的东西是否真的有效。

这是我想在这个概念模型中捕捉到的东西的列表。为 V1.2 编辑

1. 这样做的目的是列出乐队、他们的成员和他们将出现的活动，以及提供音乐和其他商品待售
2. 会员将能够与朋友配对
3. 成员可以对乐队、他们的音乐和他们的活动进行评论。
   • 每个成员只能对给定项目进行一次评论，尽管他们可以编辑他们的评论并且历史记录将被保留。
   • 乐队成员将有机会就与他们关联的乐队的评论写一条评论。集体作为一个乐队，每条评论只允许发表一条评论。
   • 然后，成员可以对所有评论和评论进行评分，但每个给定实例只能评分一次
4. 会员可以选择自己喜欢的乐队、音乐、商品和活动
5. 乐队、歌曲和活动将被分类为它们所属的类型，然后在必要时进一步细分为子类型。一个乐队或活动可以分为一个以上的流派/子流派组合。
6. 活动日期、时间和地点将发布给特定乐队，成员可以表明他们将参加活动。一个活动可以由多个乐队组成，多个活动可以在同一天在一个地点举行
7. 每一方都将绑定到至少一个地址，并且应保留地址历史记录。每一方也可以一次绑定到多个地址（即账单、运输、物理地址）
8. 将存储乐队、乐队成员和普通成员的个人资料。

就是这样，可能有点涉及，但希望随着过程的发展和社区提供的输入，对许多人来说可能是一个很好的学习工具。有输入吗？

EDIT v1.1 响应 PerformanceDBA

U.3) 这意味着数据库中没有除乐队商品以外的商品。正确的 ？ 这是我最初的想法，但你让我思考。也许该网站想要出售自己的商品，甚至是乐队的其他商品。不确定要为此制作什么模组。是否需要对目录部分进行全面修改，还是只需要与乐队存在的识别关系？尝试了一个模组来销售完整的专辑或歌曲。无论哪种方式，它们都是电子格式，仅供下载。这就是为什么我将专辑列为由歌曲而不是 2 个单独的实体组成的原因。

U.5）我理解你提出的关于与收藏的循环关系的内容。我想了解这个“它要么是一个具有某种形式的差异化（FavoriteType）的实体，它可以识别它的处理方式”，但我不清楚如何去做。我在这里想念什么？

u.6） “业务规则这可能是您唯一薄弱的领域。”<br> 感谢您的诚实回应。我将重新解决这些问题，但我希望首先通过我回复给您的回复来消除我脑海中的一些困惑。

Q.1)是的，我希望接受、拒绝和阻止。我不确定您指的是如何改变逻辑模型？

Q.2)一个人不必是用户。他们只能作为乐队成员存在。这就是你要问的吗？

小问题

零个、一个或多个……哎呀，我承认我在构建模型时忘记了这一点。我按原样提交此版本，并将在未来版本中解决。我需要阅读更多关于约束检查的内容，以确保我理解了一些事情。

M.4)取决于您是否设想未来的 OrderPurchase。你能扩展一下你的意思吗？

EDIT V1.2 响应 PerformanceDBA 输入...

得到教训。

1. 我混合了识别/非识别和基数（即流派/子流派）的概念，并且不一致地这样做会使事情变得更糟。
2. 逻辑图中不需要关联表，因为可以在物理模型中描述并扩展它们的多对多关系。
3. 我在很多关系中都忽略了基数
4. 使用有效的动词短语阅读关系以确保我正在建模我想要完成的事情的重要性。

U.2) 在这个模型的概念中，只需要跟踪一个场地作为一个事件的位置。无需收集更多数据。话虽如此，活动将在给定的 EventDate 举行，并将在 Venue 举办。场地将在给定日期举办多个活动，并可能举办多个活动。在我的新模型中，我的想法是 EventDate 已经绑定到 Event 。因此，Venue 不需要与 EventDate 建立关系。您在 U.2 下列出的第 5 和第 6 个项目符号）让我质疑我的想法。我在这里错过了什么吗？

U.3)是时候将物品和乐队之间的链接移到物品和派对上了吗？就目前的设计而言，我认为不可能出售与您提出的乐队无关的商品。

U.5）我根据您的输入离开，而不是使其成为离散的超类型/子类型关系，因为我看不到这种类型的汇总有什么好处。

附加修订

AR.1)完成FavoriteItem 的练习后，我觉得Item to Review 需要一个多对多的关系，所以要指出。必要的？

好的，我们去 v1.3

我在这个版本上花了几天时间，来回研究我的设计。一旦逻辑过程完成，因为我想看看我是否走在正确的轨道上，我将深入了解我所学到的东西以及我作为初学者在这个过程中遇到的麻烦。这个版本的重点是它需要输入一些键来帮助查看我过去缺少的东西。经历做矩阵的过程也被证明是有很大帮助的。无论如何，如果不是 PerformanceDBA 提供的输入，我仍然会是一个迷失的灵魂，在黑暗中徘徊。谁知道我目前的设计可能会再次证明我仍然存在，但我学到了很多东西，所以我知道我至少手上有一个手电筒。

在这一点上，我承认我仍然对识别和非识别关系感到困惑。在我的模型中，我必须使用具有非空值的非标识关系来加入我想要建模的关系。在阅读大量有关该主题的内容时，似乎对该主题存在很多分歧和优柔寡断，因此我做了我认为代表模型中正确事物的事情。何时强制（识别）和何时自由（非识别）？有人有输入吗？

编辑 V1.4

好的，接受了 V1.3 输入并为这个 V1.4 清理了东西

目前正在开发 V1.5 以包含属性。

编辑 V1.6

好的，我已经有一段时间没有在这里发帖了，但这个项目的工作仍在进行中。我现在发布 V1.6，其中包括与上次发布 V1.4 相比的一些更改。这个版本展示了 Keys 的进一步发展。它仍然不包括属性或任何 AK 或 IE。我已经开始研究物理模型，并用它来帮助处理属性并尝试阐明我在定义 AK 和 IE 时遇到的问题。逻辑模型的下一篇文章将包括这些键和属性。

我有一个奇怪的数据库设计问题，我不确定我是否做对了。由于我当前的设计非常复杂，因此我在下图中简化了它，并使用房屋和居住者（不是我的实际实体）进行了比较。

因此，这是数据库设计的部分内容：

标准条件：

• 多间房屋
• 每栋房屋多层
• 每层有多个卧室

非标准条件：

• 每个住户可以住在多个房子里
• 每个住户可以拥有多间卧室
• 每个住户每层每栋房子只能有一间卧室（这是棘手的部分）例如，他们可以在 1 楼拥有一间卧室，在 2 楼拥有一间卧室，在 3 楼拥有一间卧室，但不能在同一间卧室拥有两间卧室地面

因此，我想要完成的就是这个。在应用程序设计中，我知道house，我知道floor，我知道occupant。bedroom我需要在没有用户指定的情况下使用这些信息找出occupant基于这 3 个标准的内容。有两种解决方案。首先是在occupants_has_bedrooms表中，我将主键设为occupants_id,bedrooms_floors_id和bedrooms_floors_houses_id. 但是，当我bedrooms_id从主键中取出时，该表不再是与父级的识别关系（bedrooms）。这是一种识别关系，因为没有父母就无法存在。因此，有些事情告诉我我需要将所有四个 id 作为主键。我的第二个选项是这三个值之间的唯一索引，但是这是我认为我可能正在接近这个错误的时候。

我该如何做到这一点？

好吧，我最初在 StackExchange 上为数据库管理员发布了这个问题： https ://dba.stackexchange.com/questions/28356/should-this-be-an-identifying-relationship-or-not

但我猜它似乎缺乏用户。那么有人可以帮我解决这个问题吗？

编辑：好的，我选择了非识别关系，这样用户可以是 Patient、SpiProfessional 或两者兼而有之。似乎工作得更好，即使在编写查询时工作量更大。感谢大家的回答，他们都有助于我对数据库的理解。

我收到以下 InvalidOperationException：

对数据库的更改已成功提交，但在更新对象上下文时出错。ObjectContext 可能处于不一致的状态。内部异常消息：发生引用完整性约束冲突：定义引用约束的属性值在关系中的主体对象和依赖对象之间不一致。

当我运行以下代码时会发生这种情况（注意我在 ShipDates 集合上调用 Clear() 的位置，然后添加新实例）：

以下是参与识别关系的两个类的相关部分：

和：

如果我有一个正在修改的现有 OrderPage，则会在 SaveChanges() 处发生错误。我希望 OrderPage 删除 ShipDates 集合中的所有现有 OrderPageShipDates 并重新添加到新实例中。

你能帮我解决这个问题吗？提前致谢。

哦，请回复下面的回复 - 我在 GetOrder() 调用中明确加载发货日期。这是代码：

我现在面临着一个巨大的挑战。我正在设计一个数据库，当我有一个强实体“CLIENT”和一个弱实体“AFFILIATE”，它的主键与父主键相结合。两者之间的识别关系必须是“一对多” ”的关系，并有完全的参与。但我的问题是，在 SQL 中，由于 AFFILIATE 的主键必须由其鉴别器和父主键定义，一对多关系将效率低下，例如在 AFFILIATE 中可能有一个 id_affiliate 与许多 id_client。请帮我。

我有一张表product(id, name)，其中包含几组不同型号的产品。即{motor10，motor20，motor30，pipe10，pipe20，pipe30，wrench12，wrench20等}。

我选择创建一个名为product category仅包含类别的新表，例如 {motor, pipe, wrench, uncategorized}

问题

出于应用程序的实际目的（而不是出于理论目的，例如建模 ER 图），我应该使用识别关系还是非识别关系？

我的用例 在我的例子中，我可以定义它，这样一个产品就不能没有类别而存在。但是，如果产品尚未分类，则它uncategorized在类别中具有价值。类别可以包含尚未分配任何产品的条目。

类别是一个虚构的概念，我真的不必使用，但它可以帮助我对我目前拥有的产品集进行分类。我认为因为它是一个虚构的概念，我不确定我想如何使用它，这就是我在这个问题上苦苦挣扎的原因。又名.. 我根本不需要桌子，product_category但它肯定会帮助我进行各种产品分组。

使这成为一种识别关系将需要我修改和重写一些代码，并且我想确保在我开始编写大量代码之前我确实希望使这种识别关系成为一种识别关系。

...也就是说，是否存在我不会将其作为识别关系的情况？