mysql – 识别与非识别关系(再次!!!)
作者：互联网
所以,我在stackoverflow上已经阅读了很多答案,但我仍然对它的整个概念感到困惑.具体来说,我已经阅读了这篇文章(包括它引用的所有文章),但似乎无法找到对概念的可靠掌握(或者也许是我的基数(n：m等)和身份之间的混淆)：
Still Confused About Identifying vs. Non-Identifying Relationships
我的问题是：我知道识别关系意味着子实体的主键必须包含其外键,而非识别关系则相反(这是正确的吗？).现在,这对我来说似乎有点太“前瞻性思考”了？在其中一个链接的评论中也有同样的说法.我怎样才能“退后一步”并实际看到哪些关系具有哪些特征？
例如,我有两个困境：
> job_title(父母,1)到员工(孩子,1 .. *).我是否正确地认为,因为job_title是一个查找表,它必须是一个非识别关系？或者更准确地说“没有工作标题,员工就不能存在,因此必须确定”？或者是定义该场景的关系？
>员工到employee_equipment(m：n基数之间的桥接实体)到设备.现在,我读到这必须是employee_equipment双方的识别关系.但是,如果员工不需要设备怎么办？可以有一个可选的识别关系吗？
我想我正在寻找一种方法来识别哪些身份表应该属于哪个,而不考虑主键/外键,或者任何真正技术性的东西.
任何帮助将非常感激！
解决方法:
你过分思考了选择性和身份之间的联系.直到整个事情对你来说更自然,最好将它们视为完全无关.
关于可选性,重要的是要记住可选性是方向性的.使用employee_equipment的例子：当然,员工不需要设备.从employee到employee_equipment的一对多关系是可选的.同时,从相反的角度来看,这种关系是强制性的.除非有员工将其与之关联,否则您不能在employee_equipment中拥有记录.
身份与选择性无关,除了巧合地,从孩子到父母的身份必须具有识别关系.从父母到孩子的强制性,既不是在这里,也不是在身份方面.
识别关系的原因是你必须知道你在说什么父母(以及其他一些事情)才能知道你在说什么孩子.也就是说,子项的主键必须包含父项的外键.
纯交集表(例如employee_equipment)就是很好的例子.纯交集的主键是两个父表的外键组合.请注意,有些人还可能会为这些类型的表添加代理键.如果存在多个候选键,则从身份角度来看并不重要.在确定身份时重要的是外键是否是候选键的一部分,该候选键是否恰好是主键.
另一个很好的例子就是数据库的元数据目录,其中列由它所属的表标识,就像表由它所在的模式标识一样,依此类推.知道列被称为NAME并不会告诉您它是哪一列.知道它是CUSTOMER表中的NAME列有助于. (您还必须知道CUSTOMER所处的架构,等等).
标签：entity-relationship,mysql,database-design,database,cardinality 来源： https://codeday.me/bug/20190725/1535205.html