我读过这样一个问题: 什么是识别和非识别关系之间的区别?
但我还是不太清楚......我已经是三个表。
- 用户
- 对象
- 图片
用户可以拥有许多对象,也可以张贴每个单独的对象多张图片。 我的直觉告诉我,这是一个确定的关系,因为我需要在对象表中的用户ID和我需要在图片表中的objectID ...
还是我错了? 其他主题中的解释限制自己的数据库,其解释它已经被编码后,没怎么物体被连接在现实生活中这样的理论解释。 我有点困惑,如何使识别与决定非识别思考如何我要建立数据库时。
我读过这样一个问题: 什么是识别和非识别关系之间的区别?
但我还是不太清楚......我已经是三个表。
用户可以拥有许多对象,也可以张贴每个单独的对象多张图片。 我的直觉告诉我,这是一个确定的关系,因为我需要在对象表中的用户ID和我需要在图片表中的objectID ...
还是我错了? 其他主题中的解释限制自己的数据库,其解释它已经被编码后,没怎么物体被连接在现实生活中这样的理论解释。 我有点困惑,如何使识别与决定非识别思考如何我要建立数据库时。
这两个听起来像识别的关系给我。 如果您听说过的条款一到一对一或一对多,和许多一对多, 一对一关系 确定的关系 ,和许多一对多的关系 非标识关系 。
如果孩子识别其母公司,它是这样的识别关系。 在链接你给了,如果你有一个电话号码,你知道它属于谁(它只属于一个)。
如果孩子没有标识其母公司,它是一个非标识关系。 在链接,它提到的状态。 一个国家看作一个表中表示心情一行。 “开心”不识别特定的人,但很多人。
编辑 :其他现实生活中的例子:
我认为,想象它的一个更简单的方法就是问自己,如果没有家长可以有子记录。 例如,一个订单项目需要一个订单表头存在。 因此,一个订单项必须具有订单头标识符作为其关键的部分,因此,这是一个识别关系的一个例子。
在另一方面,可能存在没有一个人拥有的电话号码,但一个人可以有多个电话号码。 在这种情况下,谁拥有的电话号码的人是因为可以存在的电话号码,而不管所有者人(的因此,在电话号码所有者的人可以为空非键或非识别关系而在订单项示例,订单表头标识符不能为空。
NickC所述:一对一关系识别的关系,以及多到多的关系是非识别关系
解释似乎完全错误的我。 你可以有:
想象一下,你有如下表: customer
, products
和feedback
。 所有这些都是基于customer_id
其存在于cutomer
表。 因此,通过NickC定义,不应该有任何存在许多种对多确定关系的,但是在我的例子,你可以清楚地看到: 只有在相关的产品存在,并且由客户已经买了反馈可以存在,所以客户,产品及信息反馈应确定 。
你可以看看MySQL手册 ,解释如何添加外键在MySQL工作台为好。
马赫迪,你的直觉是正确的。 这是一个重复的问题,这件事,投票的答案是不正确或不完整的。 看看这里的顶部两个答案: 识别之间的差异不识别
识别与非识别无关与身份。 简单地问自己能子记录无父存在吗? 如果答案是肯定的,它是不识别。
最核心的问题孩子的主键是否包含父的外键。 在非识别关系孩子的主键(PK)不能包括外键(FK)。
如果孩子可以在没有父存在,那么关系是非识别。 (谢谢你MontrealDevOne为更清楚地说明它)
社会安全号码很好地适应于这一类。 让我们想象一下,例如,社会安全号码不能存在了一个人(或许他们可以在现实中,而是在我们的数据库中没有)的为person_id将是人表PK,包括如名称和地址列。 (让我们保持简单)。 该social_security_number表将包括SSN列和为person_id列作为外键。 由于该FK可以用作PK为social_security_number表它是这样的识别的关系。
在一个大办公室复杂的,你可能有一个办事处表包括由地面和建筑物数量房间号码与PK,和一个单独的员工表。 雇员表(孩子)有一个FK这是从办公室桌子PK的office_id列。 虽然每个雇员仅具有一个办公室并且此(例如)每一个办公室只有一个雇员,这是因为如果没有员工可以存在办事处非识别的关系,和雇员可以在现场改变办公室或工作。
一个一对多的关系可以很容易地被问同样的问题进行分类。
许多一对多的关系总是确定的关系。 这似乎违反直觉,但我承担。 以两个表libary和书籍 ,每个库有许多书籍,并在许多图书馆存在的每本书的副本。
这里是什么使得它和标识关系:为了实现这一点,你需要有两列,它们分别表的主键一个链接表。 称他们为library_id列和ISBN列。 这种新的链接表没有单独的主键,但等待! 外键成为链接表,因为在链接表中重复的记录将是毫无意义的一个多列主键。 这些链接不能让那些家长存在; 因此,这是一个识别的关系。 我知道,难吃吧?
所有这一切说,平时你不用担心,你有。 只需指定适当的主键和外键的每个表和关系会发现自己。
编辑: NicoleC ,我读了答案您链接它必须和我的同意。 我把他的观点关于SSN,并同意这是一个坏榜样。 我会尽力想出另一个更清晰的例子在那里。 但是,如果我们开始在定义数据库的关系类比总是打破使用真实世界的类比。 重要的不是,一个SSN是否标识一个人,它的事项无论你使用它作为一个外键。