是可选性（强制性，可选性）和参与性（总体，部分）是否相同？
据我所知，select性意味着关系的最小基数，表示为可选的，可选的，强制性的，可选的，强制性的强制性的。
参与表示为粗线和正常线。
在互联网中，有些人把参与作为实体对这种关系的依赖关系，这种关系也看起来像是识别和非识别关系。
有些则称之为最低基数
什么是这些关系的正确定义，有什么区别。
让我们从每个概念的定义和例子开始：
全部和部分参与：
全部参与（由双重或厚实的关联线表示）意味着实体集合中的所有实体都必须参与这种关系。 部分参与（用单个细线表示）意味着实体集合中可能存在不参与关系的实体。
Medicine完全参与Produce关系，这意味着Medicine不能存在，除非由Laboratory Produced 。 相比之下，一个Laboratory可以存在没有Producing Medicine – Laboratory参与部分Produce关系。
强制性和可选angular色：
在一段关系中，angular色可以是可选的或强制的。 这会影响关系实例是否可以在给定angular色中没有实体的情况下存在。 强制angular色用固定的关联线表示，可选angular色用虚线表示。
数据库教程中不经常谈论angular色，但是它们是一个重要的概念。 考虑婚姻 – 与由同一个实体组合填充的两个强制angular色的关系。 在大多数关系中，实体集也定义了angular色，但是当一个实体集在单一关系中出现多次时，我们将它们区分为不同的angular色。
在上面的例子中， Patient可以Purchase有或没有Prescription Medicine 。 如果没有Patient和Medicine ， Purchase就不可能存在，但Prescription是可选的（总的来说，虽然在特定情况下可能需要）。
识别关系/弱实体：
一个弱实体是一个不能被自己的属性识别的实体，因此有另一个实体的密钥作为自己的一部分。 识别关系是一个弱势实体和其母公司之间的关系。 识别关系和弱实体都用双边框表示。 弱实体集合必须完全参与其识别关系。
在这个例子中， Prescription包含由Prescription的键和行号标识的LineItems 。 换句话说， LineItems表将有一个组合键(Prescription_ID, Line_Number) 。
有关非标识关系的示例，请参阅前面的示例。 虽然Medicine完全参与Produce关系，但它有自己的身份（例如代理键，但我没有指出）。 请注意，代理键总是暗含常规实体。
强制/可选与全部/部分参与
强制性或可选angular色指示是否需要某个angular色（及其关联的实体集）才能存在关系。 全部或部分参与表明一个实体是否需要某种关系。
强制性部分参与：见上文： Laboratory可以存在而不生产任何药物，但没有Laboratory就不能生产药物。
强制性总参与：见上文： Medicine不能没有Produced就存在， Laboratory不能Produce不明确的东西。
可选的部分参与：见上文： Prescription可以存在而不被Purchased ，并且Purchase可以没有Prescription而存在。
这就让我们select了全面的参与，我不得不考虑一些例子：
有些Patients Die一个不明Cause ，但是如果没有Patient Dying ，死亡是不可能存在的。
全部/部分参与vs识别/非识别关系
正如我之前所说的那样，弱的实体集总是完全参与他们的识别关系。 见上面：一个LineItem必须Contained在一个Prescription ，它的身份和存在取决于。 部分参与识别关系是不可能的。
全面参与并不意味着一个确定的关系 – Medicine不能存在没有Laboratory Produced ，但Medicine是由自己的属性确定。
部分参与非识别关系是非常普遍的。 例如， Medicine可以不被Purchased而存在，而Medicine则是通过自己的属性来识别的。
强制/可选与识别/非识别关系
一个关系less于两个强制性angular色是不寻常的。 识别关系是二元关系，所以父子angular色将是强制性的 – Prescription和LineItem之间的Contain关系不能在没有两个实体的情况下存在。
可选的angular色通常只能在三元以上的关系中find（虽然看到病人死因的例子），并且不参与识别。 可选angular色的替代方法是关系关系：
通过将Purchase转化为关联实体，我们可以让它参与与Prescription的Fill关系。 为了保持与上面相同的语义，我指定了Purchase只能Fill一个Prescription 。
物理build模
如果我们从概念模型转换到物理模型（跳过逻辑build模/进一步标准化），为每个实体和关系创build单独的表格，事情看起来非常相似，尽pipe您必须知道如何读取外键行上的基数标志来恢复ER语义。
然而，通常使用相同的主键对表进行非规范化，这意味着一对多关系与许多方面的实体表相结合：
关系在物理上表示为表中的两个或多个实体关键字。 在这种情况下，实体键 – patient_id和cause_of_death_id都可以在Patient表中find。 很多人认为外键线代表了这种关系，但这是由于将实体 – 关系模型与旧的networking数据模型混淆起来的。
这是至关重要的一点 – 为了理解不同types的关系和约束关系，了解什么样的关系是第一位的，这是至关重要的。 ER中的关系是键之间的关联，而不是表之间的关联。 关系可以具有不同实体集合的任意数量的angular色，而外键约束强制实现一个实体集合的两列之间的子集约束。 现在，用这些知识武装起来，再次阅读我的整个答案。 ;）
我希望这有帮助。 随意问的问题。
