我还不能完全理解这些差异。你能描述这两个概念并使用真实世界的例子吗?
当前回答
两个强大的实体之间存在着识别关系。非识别关系不一定是强实体和弱实体之间的关系。可能存在这样的情况:子实体本身具有主键,但其实体的存在可能取决于其父实体。
例如:卖家和一本书之间的关系,其中一本书正由卖家出售,卖家可能有自己的主键,但其实体仅在出售一本书时创建
基于Bill Karwin的参考
其他回答
现实世界还有另一种解释:
一本书属于所有者,所有者可以拥有多本书。但是,这本书也可以在没有所有者的情况下存在,它的所有权可以从一个所有者变为另一个所有者。书籍和所有者之间的关系是一种不可识别的关系。
然而,一本书是由一位作者写的,而且作者可能已经写了多本书。但是,这本书需要作者来写——没有作者,它就不可能存在。因此,这本书与作者之间的关系是一种认同关系。
user287724的回答给出了以下书籍与作者关系的示例:
然而,一本书是由一位作者写的,而且作者可能已经写了多本书。但这本书需要作者来写,没有作者就不可能存在。因此,这本书和作者之间的关系是一种识别关系。
这是一个非常令人困惑的例子,绝对不是识别关系的有效例子。
是的,如果没有至少一位作者,一本书就无法写作,但这本书的作者(是外键)无法在图书表中识别这本书!
您可以从书本行中删除作者(FK),并且仍然可以通过其他字段(ISBN、ID等)来识别书本行,但不能识别书本的作者!!
我认为识别关系的一个有效示例是(产品表)和(特定产品详细信息表)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被视为FK引用products.ID表,同时也是printers_dedetails表中的PK,这是一种标识关系,因为printers表中的Product _ID(FK)正在标识子表中的行,我们无法从子表中删除product_id,因为我们无法再标识该行,因为我们丢失了它的主键
如果要将其分为两行:
识别关系是FK在当仍然引用父表
另一个例子可能是在某个国家/地区的进出口数据库中有3个表(进口-产品-国家)
导入表是具有这些字段的子表(product_id(FK)、country_id(FK)、导入数量、价格、导入单位、运输方式(空运、海运))我们可以使用(product_id,thecountryid`)来标识导入的每一行“如果它们都在同一年”,这里这两列可以一起组成子表(imports)中的主键,也可以引用父表。
拜托,我很高兴我终于理解了认同关系和非认同关系的概念,所以请不要告诉我,我对一个完全无效的例子的所有投票都错了
是的,从逻辑上讲,一本书没有作者是写不出来的,但是一本书如果没有作者是可以被识别的,事实上,它不能被识别为作者!
您可以从书本行中100%删除作者,并且仍然可以识别书本!。
标识关系是指子表中的行是否存在取决于父表中的某一行。这可能会让人困惑,因为现在通常的做法是为子表创建一个伪密钥,但不将外键作为子表主键的父部分。从形式上讲,这样做的“正确”方法是让外键成为孩子的主键的一部分。但逻辑关系是,没有父母,孩子就不可能存在。示例:一个人有一个或多个电话号码。如果他们只有一个电话号码,我们可以简单地将其存储在Person列中。因为我们希望支持多个电话号码,所以我们创建了第二个表PhoneNumbers,其主键包括引用person表的person_id。我们可能会认为电话号码属于一个人,尽管它们被建模为单独表格的属性。这是一个很好的线索,表明这是一种识别关系(即使我们没有在PhoneNumbers的主键中包含person_id)。非标识关系是指父级的主键属性不能成为子级的主键。一个很好的例子是查找表,例如Person.state上的外键引用States.state的主键。Person是与States相关的子表。但是Person中的一行不通过其state属性标识。即状态不是Person主键的一部分。非标识关系可以是可选的或强制性的,这意味着外键列分别允许NULL或不允许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
非识别关系
非识别关系意味着孩子与父母有亲属关系,但可以单独识别。
PERSON ACCOUNT
====== =======
pk(id) pk(id)
name fk(person_id)
balance
ACCOUNT和PERSON之间的关系无法识别。
确定关系
认同关系意味着需要父母给予孩子身份。孩子只因父母而存在。
这意味着外键也是主键。
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之间的关系。
推荐文章
- 使用{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数据库键的优缺点
- “防止保存需要重新创建表的更改”的负面影响