23

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

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

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

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

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

4

4 回答 4

54

两者听起来都像是在识别我的关系。如果您听说过术语一对一或一对多和多对多,那么一对关系就是识别关系,而多对多关系是非识别关系

  • 如果子标识其父,则它是标识关系。在您提供的链接中,如果您有电话号码,您就知道它属于谁(它只属于一个)。

  • 如果孩子不识别其父母,则它是非识别关系。在链接中,它提到了状态。将状态想象为代表情绪的表格中的一行。“开心”不是指某个特定的人,而是指很多人。

编辑:其他现实生活中的例子:

  • 物理地址是一种非识别关系,因为许多人可能居住在一个地址。另一方面,电子邮件地址(通常被认为是)一种识别关系。
  • 社会安全号码是一种识别关系,因为它只属于一个人
  • 对 Youtube 视频的评论是在识别关系,因为它们只属于一个视频。
  • 一幅画的原件只有一个所有者(识别),而许多人可能拥有这幅画的再版(非识别)。
于 2009-08-01T15:44:29.830 回答
9

我认为将其可视化的更简单方法是问自己是否可以在没有父母的情况下存在子记录。例如,订单行项目需要存在订单标题。因此,订单行项目必须将订单标题标识符作为其键的一部分,因此,这是标识关系的一个示例。
另一方面,电话号码可以在没有个人所有权的情况下存在,尽管一个人可能有多个电话号码。在这种情况下,拥有电话号码的人是非关键或非识别关系,因为电话号码可以存在而与所有者无关(因此,电话号码所有者可以为空,而在订单行项目示例中,订单头标识不能为空。

于 2010-11-07T03:43:48.580 回答
6

NickC 说:一对多关系是识别关系,多对多关系是非识别关系

这个解释对我来说似乎完全错误。你可以有:

  • 一对一的非识别关系
  • 一对多非识别关系
  • 一对一识别关系
  • 一对多识别关系
  • 多对多识别关系

假设您有以下表格customerproductsfeedback。所有这些都是基于表上customer_id存在的cutomer。因此,根据NickC的定义,不应该存在任何类型的多对多识别关系,但是在我的示例中,您可以清楚地看到:只有当相关产品存在并且已被客户购买时,反馈才能存在,所以客户、产品和反馈应该是识别的。

您可以查看MySQL Manual,解释如何在 MySQL Workbench 上添加外键。

于 2013-02-13T12:52:54.647 回答
3

马赫迪,你的直觉是正确的。这是一个重复的问题,这个投票赞成的答案不正确或不完整。在此处查看前两个答案: 识别非识别性之间的区别

识别与非识别与身份无关。简单地问自己,没有父母的孩子记录可以存在吗?如果答案是肯定的,则它是不可识别的。

子的主键是否包含父的外键的核心问题。在非标识关系中,孩子的主键 (PK) 不能包括外键 (FK)。

问自己这个问题

  • 没有父记录,子记录可以存在吗?

如果孩子可以在没有父母的情况下存在,那么这种关系是不可识别的。(感谢MontrealDevOne更清楚地说明)

一对一识别关系

社会安全号码非常适合这一类。例如,假设没有人,社会安全号码就不能存在(也许他们实际上可以,但在我们的数据库中不存在)person_id将是person表的 PK,包括nameaddress等列。(让我们保持简单)。social_security_number表将包括ssn列和person_id列作为外键由于此 FK 可用作social_security_number表的 PK,因此它是一种识别关系。

一对一的非识别关系

在大型办公综合体中,您可能有一张办公桌,其中包括按楼层和建筑物编号的房间号以及 PK,以及一个单独的员工表。员工表(子表)有一个 FK,它是office表 PK中的office_id列。虽然每个员工只有一个办公室,并且(在此示例中)每个办公室只有一个员工,但这是一种非识别关系,因为办公室可以在没有员工的情况下存在,员工可以更换办公室或在外地工作。

一对多关系

一对多的关系可以很容易地通过问同样的问题来分类。

多对多关系

多对多关系总是在识别关系。这似乎违反直觉,但请耐心等待。以libarybooks两个表为例,每个图书馆都有很多书,并且每本书的副本存在于许多图书馆中。

以下是它的原因和识别关系: 为了实现这一点,您需要一个包含两列的链接表,这些列是每个表的主键。称它们为library_id列和ISBN列。这个新的链接表没有单独的主键,但是等等!外键成为链接表的多列主键,因为链接表中的重复记录将毫无意义。没有父母,链接就无法存在;因此,这是一种识别关系。我知道,呸呸呸呸?

大多数时候,关系的类型并不重要。

综上所述,通常您不必担心您拥有哪个。只需为每个表分配正确的主键和外键,关系就会自行发现。

编辑:NicoleC,我阅读了您链接的答案,并且确实同意我的观点。我同意他关于 SSN 的观点,并同意这是一个不好的例子。我会尝试在那里想出另一个更清晰的例子。但是,如果我们开始使用现实世界的类比来定义数据库关系,类比总是会失效。SSN 是否识别一个人并不重要,重要的是您是否将其用作外键。

于 2014-01-08T18:12:49.843 回答