我还不能完全理解这些差异。你能描述这两个概念并使用真实世界的例子吗?
当前回答
正如下面的链接中很好地解释的,识别关系有点像ER概念模型中的父实体的弱实体类型关系。用于数据建模的UML风格CAD不使用ER符号或概念,并且关系类型为:识别、非识别和非特定。
识别关系是父/子关系,其中子实体是一种弱实体(即使在传统的ER模型中称为识别关系),其自身属性没有真正的主键,因此无法通过自身属性唯一识别。在物理模型上,对子表的每一次访问都将依赖于(包括语义上的)父级主键,该主键会变成子级主键的一部分或全部(也是外键),通常会在子级生成一个复合键。子项本身的最终现有键仅是伪键或部分键,不足以识别该类型实体或实体集的任何实例,而不需要父项的PK。
非标识关系是完全独立的实体集的普通关系(部分或全部),其实例不依赖于彼此的主键来唯一标识,尽管它们可能需要外键用于部分或全部关系,但不作为子实体的主键。孩子有自己的主键。父幂等。两者都是独立的。根据关系的基数,其中一个的PK作为FK传递到另一个(N侧),如果是部分,则可以为空,如果是总计,则必须不为空。但是,在这样的关系中,FK永远也不会是孩子的PK,就像在确定关系时一样。
http://docwiki.embarcadero.com/ERStudioDA/XE7/en/Creating_and_Editing_Relationships
其他回答
对Daniel Dinnyes回答的补充:
在非标识关系中,不能使用相同的值两次使用相同的主键列(例如,“ID”)。
但是,使用identifynig关系,可以为“ID”列显示两次相同的值,只要它具有不同的“otherColumn_ID”外键值,因为主键是两列的组合。
请注意,FK是否为“非空”并不重要!;-)
订单处理就是一个很好的例子。来自客户的订单通常有一个用于标识订单的订单号、每个订单出现一次的一些数据(如订单日期和客户ID)以及一系列行项目。每个行项目包含一个项目编号,用于标识订单中的行项目、订购的产品、该产品的数量、产品的价格以及行项目的金额,可以通过将数量乘以价格来计算。
标识行项目的编号仅在单个订单的上下文中标识行项目。每个订单中的第一行项目是项目编号“1”。行项目的完整标识是项目编号及其所属的订单编号。
因此,订单和行项目之间的父子关系是一种识别关系。ER建模中一个密切相关的概念叫做“子实体”,其中行项目是订单的子实体。通常,子实体与其从属实体具有强制的子-父标识关系。
在经典的数据库设计中,LineItems表的主键是(OrderNumber,ItemNumber)。今天的一些设计者会给一个项目一个单独的ItemID,它作为主键,并由DBMS自动递增。在这种情况下,我推荐经典设计。
标识关系是指子表中的行是否存在取决于父表中的某一行。这可能会让人困惑,因为现在通常的做法是为子表创建一个伪密钥,但不将外键作为子表主键的父部分。从形式上讲,这样做的“正确”方法是让外键成为孩子的主键的一部分。但逻辑关系是,没有父母,孩子就不可能存在。示例:一个人有一个或多个电话号码。如果他们只有一个电话号码,我们可以简单地将其存储在Person列中。因为我们希望支持多个电话号码,所以我们创建了第二个表PhoneNumbers,其主键包括引用person表的person_id。我们可能会认为电话号码属于一个人,尽管它们被建模为单独表格的属性。这是一个很好的线索,表明这是一种识别关系(即使我们没有在PhoneNumbers的主键中包含person_id)。非标识关系是指父级的主键属性不能成为子级的主键。一个很好的例子是查找表,例如Person.state上的外键引用States.state的主键。Person是与States相关的子表。但是Person中的一行不通过其state属性标识。即状态不是Person主键的一部分。非标识关系可以是可选的或强制性的,这意味着外键列分别允许NULL或不允许NULL。
另请参阅我对“仍然困惑于确定与不确定关系”的回答
假设我们有这些桌子:
user
--------
id
name
comments
------------
comment_id
user_id
text
这两个表之间的关系将确定关系。因为,评论只能属于其所有者,而不能属于其他用户。例如每个用户都有自己的评论,当用户被删除时,该用户的评论也应被删除。
这里有一个很好的描述:
两个实体之间的关系可分为“识别”或“非识别”。当父实体的主键包含在子实体的主键中时,存在识别关系。另一方面,当父实体的主键包含在子实体中但不作为子实体主键的一部分时,存在非标识关系。此外,不可识别的关系可进一步分类为“强制性”或“非强制性”。当子表中的值不能为空时,存在强制的非标识关系。另一方面,当子表中的值可以为空时,存在非强制的非标识关系。
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
推荐文章
- 使用{merge: true}设置的Firestore与更新之间的差异
- mysql_connect():[2002]没有这样的文件或目录(试图通过unix:///tmp/mysql.sock连接)在
- 使用电子邮件地址为主键?
- MongoDB在v4之前不兼容ACID意味着什么?
- 在日历应用程序中建模重复事件的最佳方法是什么?
- 第一次设计数据库:我是否过度设计了?
- 我应该在SQL varchar(长度)中考虑电话的最长的全球电话号码是什么
- MySQL查询转储
- phpMyAdmin错误>格式参数错误?
- 在PostgreSQL表已经创建后,我可以添加UNIQUE约束吗?
- 如何在MVC应用程序中缓存数据
- 在Laravel安全地移除迁移
- 使用MySQL Workbench创建一个新数据库
- GUID / UUID数据库键的优缺点
- “防止保存需要重新创建表的更改”的负面影响