我还不能完全理解这些差异。你能描述这两个概念并使用真实世界的例子吗?
当前回答
如果您认为在删除父项时应删除子项,则这是一种识别关系。
如果即使父项已删除,子项仍应保留,则它是一个不可识别的关系。
例如,我有一个包含学员、培训、文凭和培训课程的培训数据库:
学员与培训课程有明确的关系培训与培训课程有明确的关系但学员与文凭的关系并不明确
如果删除了相关的学员、培训或文凭,则只应删除培训课程。
其他回答
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%删除作者,并且仍然可以识别书本!。
如果您认为在删除父项时应删除子项,则这是一种识别关系。
如果即使父项已删除,子项仍应保留,则它是一个不可识别的关系。
例如,我有一个包含学员、培训、文凭和培训课程的培训数据库:
学员与培训课程有明确的关系培训与培训课程有明确的关系但学员与文凭的关系并不明确
如果删除了相关的学员、培训或文凭,则只应删除培训课程。
对Daniel Dinnyes回答的补充:
在非标识关系中,不能使用相同的值两次使用相同的主键列(例如,“ID”)。
但是,使用identifynig关系,可以为“ID”列显示两次相同的值,只要它具有不同的“otherColumn_ID”外键值,因为主键是两列的组合。
请注意,FK是否为“非空”并不重要!;-)
假设我们有这些桌子:
user
--------
id
name
comments
------------
comment_id
user_id
text
这两个表之间的关系将确定关系。因为,评论只能属于其所有者,而不能属于其他用户。例如每个用户都有自己的评论,当用户被删除时,该用户的评论也应被删除。
从父级迁移到子级的属性是否有助于识别子级?
如果是:标识依赖性存在,则关系是标识的,子实体是“弱”的。如果不存在:标识依赖不存在,则关系是非标识的,子实体“强”。
注意,身份依赖意味着存在依赖,但并非相反。每一个非NULL FK都意味着没有父级就不能存在子级,但这并不能使关系确定。
有关这方面的更多信息(以及一些示例),请参阅ERwin方法指南的“确定关系”部分。
补充:我意识到我参加聚会(非常)晚了,但我觉得其他答案要么不完全准确(用存在依赖而不是身份依赖来定义它),要么有些曲折。希望这个答案更清晰。。。
1孩子的FK是孩子的PRIMARY KEY或(非NULL)UNIQUE约束的一部分。
推荐文章
- 不可重复读和幻影读的区别是什么?
- 外键约束:何时使用ON UPDATE和ON DELETE
- 连接查询vs多个查询
- MySQL:在同一个MySQL实例上克隆MySQL数据库
- 优化PostgreSQL进行快速测试
- 表被标记为崩溃,应该修复
- 在Android SQLite中处理日期的最佳方法
- 使用{merge: true}设置的Firestore与更新之间的差异
- mysql_connect():[2002]没有这样的文件或目录(试图通过unix:///tmp/mysql.sock连接)在
- 使用电子邮件地址为主键?
- MongoDB在v4之前不兼容ACID意味着什么?
- 在日历应用程序中建模重复事件的最佳方法是什么?
- 第一次设计数据库:我是否过度设计了?
- 我应该在SQL varchar(长度)中考虑电话的最长的全球电话号码是什么
- MySQL查询转储