【问题标题】:Identifying Vs Non-Identifying relationships in SQL [duplicate]SQL中识别与非识别关系[重复]
【发布时间】:2017-06-21 23:15:53
【问题描述】:

我最近开始使用 MySQL Workbench 来管理 EER 图。到目前为止,我一直在使用 phpmyadmin,但从未遇到过识别和非识别关系这两个术语。

我已经在网上查找了差异并阅读了一些关于该主题的 Stack Overflow 答案,但我仍然一无所知。

据我了解,我将在我的数据库中给出一个场景示例,并提出正确的解决方案。

所以在我的数据库中,我有一个 users 表和一个 contact 表,其中包含联系用户的各种方法(例如电子邮件和电话号码)。由于没有与用户相关的联系人记录就无法存在,因此这应该是一种标识关系。

这是我的表格的样子:

+-------+    +-------+
| users |    |contact|
+-------+    +-------+
| id    |    |id     |
+-------+    |userid |
             |contact| // contains email or phone
             |type   | // specifies if email or phone
             +-------+

但是,当我在两个表之间创建 identifying 关系时,它会使 userId 成为复合键的一部分。我知道该表可以具有由useridcontact 组成的复合主键,但是希望在整个数据库中保持一致的结构,其中每个表都有自己的代理键。 (我多次看到使用代理键而不是复合键是更好的做法。)

那么在这种情况下,执行此操作的实际正确方法是什么?我应该使用复合键并废弃代理键(我真的不想这样做)吗?还是在这种情况下我应该使用非识别性关系?

请准确解释这两种关系之间的区别以及为什么识别关系需要指向作为复合键一部分的字段。

【问题讨论】:

  • 你在用什么自动为你创建密钥?
  • @Barmar "我最近开始使用 MySQL Workbench 来管理 EER 图"
  • 我将不得不删除我的答案并对其进行编辑。必须使非 vs 识别用法正确。它会回来的。 “识别关系的技术定义是子项的外键是其主键的一部分。”

标签: mysql sql mysql-workbench primary-key composite-key


【解决方案1】:

听起来你有一个非识别关系,其中父项的主键存在于子项中,但不是子项主键的一部分 - 假设子实体 (contact) 有自己的生成主键。

识别关系意​​味着父实体的主键是自然键的一部分(假设是复合的,除非实体是 1:1 的),并且现在通常不流行。

就数据库设计而言,识别与非识别在现实世界中是非常罕见的区别。我遇到或设计的大多数数据模型在每个实体上都有一个主键,对于引用它的任何对象,都有一个来自其他实体的外键到该主键。我或我认识的任何其他数据建模者偶尔会通过使用数据库约束在自然键级别强制执行唯一性。

【讨论】:

  • 所以你是说在我的情况下我应该使用非识别关系,因为每个实体都有自己的 ID?
  • 是的——如果孩子的主键是代理——就会违反“识别关系”的定义
猜你喜欢
  • 2012-04-02
  • 2010-10-20
  • 1970-01-01
  • 2013-12-18
  • 2011-02-18
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多