首页 文章

识别和非识别关系之间有什么区别？

提问于
浏览 次
730

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

database database-design data-modeling

14 回答

  • 970
    • identifying relationship 是子表中存在行取决于父表中的行的时间 . 这可能会让人感到困惑，因为现在通常的做法是为子表创建一个伪代码，但是不要将外键设置为子代的父键部分.782969的主键 . 但逻辑关系是，没有父母，孩子就不能存在 .

    示例： Person 有一个或多个电话号码 . 如果他们只有一个电话号码，我们可以将其存储在 Person 列中 . 由于我们想要支持多个电话号码，我们制作第二个表 PhoneNumbers ，其主键包括引用 Person 表的 person_id .

    我们可能会将电话号码视为属于某个人，即使它们被建模为单独表格的属性 . 这是一个强有力的线索，这是一种识别关系（即使我们在 PhoneNumbers 的主键中不包含 person_id ） .

    • A non-identifying relationship 是父项的主键属性不能成为子项的主键属性的时间 . 一个很好的例子是查找表，例如引用 States.state 主键的 Person.state 上的外键 . Person 是关于 States 的子表 . 但 Person 中的一行未被 state 属性标识 . 即 state 不是 Person 的主键的一部分 .

    非标识关系可以是 optional 或 mandatory ，这意味着外键列分别允许NULL或不允许NULL .

    另见我对Still Confused About Identifying vs. Non-Identifying Relationships的回答

    回复于
  • 7

    现实世界还有另一种解释：

    一本书属于所有者，所有者可以拥有多本书 . 但是，这本书也可以在没有所有者的情况下存在，并且它的所有权可以从一个所有者变为另一个 . 书与所有者之间的关系是一种非识别关系 .

    然而，一本书是由作者撰写的，作者可以写出多本书 . 但是，这本书需要由作者撰写 - 没有作者就不可能存在 . 因此，书与作者之间的关系是一种识别关系 .

    回复于
  • 1

    标识关系指定在没有父对象的情况下子对象不能存在

    非标识关系指定对象之间的常规关联，1：1或1：n基数 .

    非标识关系可以指定为不需要父级的可选关系，或者通过设置父表基数来指定父级是必需的...

    回复于
  • 3

    Bill's answer是正确的，但令人震惊的是，在所有其他答案中，没有人指出最重要的方面 .

    一遍又一遍地说，如果没有父母，孩子就不能存在和识别关系 . （例如user287724） . 这是事实，但完全忽略了这一点 . 只要外键足够非空，就可以实现这一点 . 它不需要是主键的一部分 .

    So here is the real reason:

    识别关系的目的是 the foreign key can NEVER CHANGE ，因为它是主键的一部分...... therefore识别!!!

    回复于
  • 16

    这是一个很好的描述：

    两个实体之间的关系可以被分类为“识别”或“非识别” . 当父实体的主键包含在子实体的主键中时，存在标识关系 . 另一方面，当父实体的主键包含在子实体中但不作为子实体的主键的一部分时，存在非标识关系 . 此外，非识别关系可以进一步分类为“强制性”或“非强制性” . 当子表中的值不能为空时，存在强制的非标识关系 . 另一方面，当子表中的值可以为null时，存在非强制性非标识关系 .

    http://www.sqlteam.com/article/database-design-and-modeling-fundamentals

    这是一个识别关系的简单示例：

    Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (PK, FK to Parent.ID) -- notice PK
Name

    这是一个相应的非识别关系：

    Parent
------
ID (PK)
Name

Child
-----
ID (PK)
ParentID (FK to Parent.ID) -- notice no PK
Name
    回复于
  • 0

    user287724第二个回答这本书和作者关系的例子如何得到 576 投票？!!! ，正如它所说：

    然而，一本书是由作者撰写的，作者可以写出多本书 . 但这本书需要由作者撰写，如果没有作者就不能存在 . 因此，书与作者之间的关系是一种识别关系 .

    这是一个非常令人困惑的例子，绝对不是 identifying relationship 的有效示例 .

    我终于理解了两种关系之间的区别:(（所以请不要把我与这个投票数量混淆!!

    是的，没有至少一位作者就不能写一本书，但书的作者（它的外键）是 NOT IDENTIFYING 书中的书！

    您可以从书行中删除作者（FK），仍然可以通过其他字段（ISBN，ID，...等）识别书籍行， BUT NOT the author of the book!!

    我认为 identifying relationship 的有效示例是（产品表）和（特定产品详细信息表）之间的关系 1:1

    products table
+------+---------------+-------+--------+
|id(PK)|Name           |type   |amount  |
+------+---------------+-------+--------+
|0     |hp-laser-510   |printer|1000    |
+------+---------------+-------+--------+
|1     |viewsonic-10   |screen |900     |
+------+---------------+-------+--------+
|2     |canon-laser-100|printer|200     |
+------+---------------+-------+--------+

printers_details table
+--------------+------------+---------+---------+------+
|Product_ID(FK)|manufacturer|cartridge|color    |papers|
+--------------+------------+---------+---------+------+
|0             |hp          |CE210    |BLACK    |300   |
+--------------+------------+---------+---------+------+
|2             |canon       |MKJ5     |COLOR    |900   |
+--------------+------------+---------+---------+------+
* please note this is not real data

    在这个例子中 printers_details 表中的 Product_ID 被认为是 products.id 表中的 Product_ID 和 ALSO a PK 表中的 ALSO a PK ，这是一个识别关系，因为打印机表 IS IDENTIFYING 中的Product_ID（FK）是子表内的行，我们可以't remove the product_id from the child table because we can'因为我们丢失了它的主键，所以不再识别该行

    如果你想把它分成两行：

    标识关系是子表中的FK被视为子表中的PK（或标识符）同时仍引用父表时的关系

    another example 可能是某些国家/地区数据库的导入和导出中有3个表（导入 - 产品 - 国家/地区）

    import 表是具有这些字段的子项 (the product_id(FK), the country_id(FK) , the amount of the imports , the price , the units imported , the way of transport(air, sea) ) 我们可以使用（product_id，country_id）来标识导入的每一行"if they all in the same year"这里两列可以组合子表中的主键（导入）并在那里引用父表 .

    拜托，我很高兴我终于理解了 identifying relationship 和 non identifying relationship :(( 的概念，所以请尽快't tell me I'错误地将所有这些投票放到 completely invalid example

    是的，逻辑上一本书没有作者就无法写出，但是一本书可以在没有作者的情况下被识别，实际上它无法与作者一致认同！

    you can 100% remove the author from the book row and still can identify the book !!! ，请不要告诉我，我误解了这个概念:(

    回复于
  • 837

    Non-identifying relationship

    非识别关系意味着孩子与父母有关，但可以由自己识别 .

    PERSON    ACCOUNT
======    =======
pk(id)    pk(id)
name      fk(person_id)
          balance

    ACCOUNT和PERSON之间的关系是不可识别的 .

    Identifying relationship

    识别关系意味着父母需要为孩子提供身份 . 孩子完全是因为父母而存在 .

    这意味着外键也是主键 .

    ITEM      LANGUAGE    ITEM_LANG
====      ========    =========
pk(id)    pk(id)      pk(fk(item_id))
name      name        pk(fk(lang_id))
                      name

    ITEM_LANG和ITEM之间的关系正在确定 . 在ITEM_LANG和LANGUAGE之间也是如此 .

    回复于
  • 2

    识别关系意味着子实体完全依赖于父实体的存在 . 示例帐户表人员表和personaccount . 人员帐户表仅由帐户和人员表的存在来标识 .

    非标识关系意味着子表没有通过父表的存在来识别，例如，表存在帐户类型，而account.accounttype表没有用帐户表的存在来标识 .

    回复于
  • 8

    如果您认为在删除父项时应删除子项，则它是一种标识关系 .

    如果即使父母被删除也应该保留子项，那么这是一个非识别关系 .

    例如，我有一个培训数据库，包括学员，培训，文凭和培训课程：

    • 受训人员与培训课程有明确的关系

    • 培训与培训课程有明确的关系

    • 但受训人员与文凭之间存在不确定关系

    如果删除了相关的培训生，培训或文凭，则只能删除培训课程 .

    回复于
  • 20

    从父母迁移到孩子的属性帮助 identify1 孩子？

    • 如果 yes ：存在标识依赖关系，则关系正在识别，并且子实体是"weak" .

    • 如果 not ：识别依赖不存在，则该关系是非识别的，并且子实体"strong" .

    请注意，识别依赖意味着存在依赖性，而不是相反 . 每个非NULL FK意味着没有父项就不能存在子项，但仅此一项不会使关系识别 .

    有关此内容的更多信息（以及一些示例），请查看ERwin Methods Guide的"Identifying Relationships"部分 .

    附：我意识到我（非常）迟到了派对，但我觉得其他答案要么不完全准确（用存在依赖而不是识别依赖来定义），要么有些蜿蜒 . 希望这个答案更清晰......

    1子's FK is a part of child'的PRIMARY KEY或（非NULL）UNIQUE约束 .

    回复于
  • 0

    订单处理就是一个很好的例子 . 来自客户的订单通常具有标识订单的订单号，每个订单发生一次的一些数据，例如订单日期和客户ID，以及一系列订单项 . 每个订单项都包含一个项目编号，用于标识订单中的订单项，订购的产品，产品的数量，产品的价格以及订单项的金额，可以通过将数量乘以价钱 .

    标识订单项的数字仅在单个订单的上下文中标识它 . 第一个项目每个订单都是项目编号“1” . 订单项的完整标识是商品编号以及作为其一部分的订单编号 .

    因此，订单和订单项之间的父子关系是一种识别关系 . ER建模中一个密切相关的概念是名称“subentity”，其中行项目是订单的子实体 . 通常，子实体与其从属的实体具有强制的子父级身份关系 .

    在经典数据库设计中，LineItems表的主键是（OrderNumber，ItemNumber） . 今天的一些设计师会给项目一个单独的ItemID作为主键，并由DBMS自动增加 . 在这种情况下，我推荐经典设计 .

    回复于
  • 0

    假设我们有这些表格：

    user
--------
id
name


comments
------------
comment_id
user_id
text

    这两个表之间的关系将确定关系 . 因为，评论只能属于其所有者，而不属于其他用户 . 例如 . 每个用户都有自己的评论，当用户被删除时，也应该删除该用户的评论 .

    回复于
  • 13

    如下面的链接中所解释的那样，识别关系有点像ER概念模型中与其父类的弱实体类型关系 . 用于数据建模的UML样式CAD不使用ER符号或概念，并且关系的类型是：识别，非识别和非特定 .

    识别那些是父/子的关系，其中孩子是弱实体（即使在传统的ER模型中称为识别关系），其自身属性没有真正的主键，因此无法通过其自身唯一识别 . 在物理模型上对子表的每次访问都将依赖于父语言的主键（包括语义），该主键变为子键的主键（也是外键）的一部分或全部，通常会导致复合键在孩子身边 . 子级本身的最终现有密钥只是伪密钥或部分密钥，不足以在没有父级PK的情况下识别该类型的实体或实体集的任何实例 .

    非标识关系是完全独立的实体集的普通关系（部分或全部），其实例不依赖于彼此的主键被唯一标识，尽管它们可能需要外键用于部分或全部关系，但不是作为孩子的主要钥匙 . 孩子有自己的主键 . 父母同意 . 都是独立的 . 根据关系的基数，一个的PK作为FK到另一个（N侧），如果是部分，则可以为null，如果是total，则必须不为空 . 但是，在这样的关系中，FK永远不会成为孩子的PK，就像识别关系的情况一样 .

    http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships

    回复于
  • 3

    识别关系在两个强实体之间 . 非识别关系可能并不总是强实体和弱实体之间的关系 . 可能存在子项本身具有主键但其实体的存在可能依赖于其父实体的情况 .

    例如：卖方可能拥有自己的主键，但只有在出售书籍时才创建实体，卖方和卖方出售书籍的书籍之间可能存在关系 .

    参考基于Bill Karwin

    回复于

相关问题