unary/recursive 关系是 strong/identifying 还是 weak/non-identifying？
Is a unary/recursive relationship strong/identifying or weak/non-identifying?
首先，一些定义确保我使用的术语清晰：
强实体和弱实体以及strong/identifying和weak/non-identifying关系：在ERD中，weak/non-identifying关系是一个连接两个强大的实体，并用虚线表示。 strong/identifying 关系是将强实体连接到弱实体（即，包含其相关实体的主键 [PK] 作为其自身的组件的实体 component主键），并用实线表示。
例如，考虑这张图（借自 another post）：
课程（强实体）和Class（弱实体）之间的关系是强关系（实线），因为Class包含课程的PK（*CID）作为其自身PK的一部分（*CID，*日期）。相反，Room（强实体）和 Class（即使它是弱实体）之间的关系很弱，因为 Room 的 PK (*RID) 不是 Class 的 PK 的一部分。
- Unary/recursive 关系： 大多数关系都是二元的，因为它们连接两个独立的实体。例如，Course 和 Class 之间的关系以及 Room 和 Class 之间的关系是二元关系。当一个实体与其自身有关系时，您很少会拥有一元（也称为递归）关系。在图中，唯一的一元关系是与 Employee 实体的关系。它应该被标记为“管理”，因为它代表一个 Employee 可能管理 0 到许多 Employees 的事实；每个员工都由 1 名且只有 1 名员工管理。 Employee的PK是*EmpID，链接关系的外键(FK)是Manager。
那么，我的问题是：一元关系是 strong/identifying 还是 weak/non-identifying？一侧的 PK（Employee，*EmpID）不仅是多侧 PK（再次，Employee，*EmpID）的一部分，而且是其全部组成部分。因此，这表明它应该是一种强关系，带有一条实线，与示例图中描述的相反。谁能帮我澄清一下？
我不完全确定你对"strong" vs. "weak"的定义来自哪里（这可能是语言问题），但据我所知可以想到像这样：如果另一个实体不复存在或失去关系，这两个相关实体是否继续存在。在您的示例中，当 Course 被废弃时，Class 不存在。这可以通过一个table的PK包含其他的来表达，但不一定如此。 Class 可以（出于完全不同的原因）拥有自己的 id 作为 PK，并仅使用 CID 作为 FK。这不会改变这两个实体的事实关系。
另一方面，如果你有 Cars 和 Drivers 之类的东西，它们的 link 就会很弱。一个删除（死）driver不会突然导致他们的车消失。同样，被盗的汽车通常不会立即导致 driver 心脏病发作。这是一个"weak"link。两个东西一个没了还能继续存在
在您的 Employees 案例中，即使他们失去关系或另一个实体不在了，这两个人仍将继续存在。因此它是一个弱link。此外，为了坚持基于什么是 PK 的定义，Manager 是 Employee 的 FK，通常 不同于 其 PK，因为很少有人在公司等级制度中找到自己的经理。
Weak/Strong 关系： strong 关系只是意味着依赖实体不能脱离关系而存在。以Class，课程和房间为例。想象一下下面的对话：
"I think I'll teach a class this September."
"Good. What course will you teach?"
"I haven't decided yet."
好吧，在这位讲师决定课程之前，真的不可能 class。由于必须在创建 class 之前指定课程，因此关系很强。此外，在考虑选择哪个 class 时，"Bead Rendering" 中的 class 和 "Cybercrafting" 中的 class 是两个完全不同的事物，即使它们可能在 "Bead Rendering" 中相遇在同一时间同一房间（只是在不同的日子）。每个 class 的身份都不可避免地与课程绑定在一起。所以这个关系也是有辨识度的。
"I think I'll reach Discretionary Logic this September."
"Good. What room will it be in?"
"I haven't decided yet."
即使没有分配房间，class 仍然可以存在。是的，开学前必须分配房间，但目前我们仍然可以创建class，将"TBD"放入目录并允许学生注册。 class 可以没有空间存在（无论如何有一段时间）所以关系很弱。此外，"Discretionary Logic" 中的两个 class 在功能上是等价的，即使它们在不同的房间教授。与房间的关系与class的类型无关。关系是非识别的。
所以如果17号房间报名参加Bead Rendering的同学被通知换到12号房间，他们就不会想，"This is a completely different class!"不，class是一样的，只是位置不同。但是，如果他们被告知 class 现在是 "Second-hand Carnival Staffing"，那么他们就是对的。这是现在完全不同的class。这就是识别关系和非识别关系的区别。
Unary/Recursive 关系： 重要的是要认识到所有关系都至少由两个实体组成。通过这种方式，数据库关系类似于人际关系——Tango 需要两个人。 "unary" 只是表示关系的两边都由同一个逻辑实体填充。
很容易看出 Class 实体和 Room 实体之间的 "meets in" 关系不能在两个 Class 实体或两个 Room 实体之间满足。但是，"is managed by" 关系需要双方都有一个 Employee 实体。同样显而易见的是，员工并不需要这种关系才能存在。也许该员工是新员工，尚未分配经理。也许该员工是这个特定组织中的领头羊，没有其他员工配得上该法案。
或者如果由Carol管理的Pete现在由Sarah管理，Pete的本性没有改变。去问问他就好了。
所以这个一元关系是weak/non-identifying。它也是递归的，因为 Pete 可能由 Carol 管理，而 Carol 由 Sam 管理，而 Sam 是......好吧，你明白了。
一元关系往往也是递归的，尽管这更多是设计的结果，而不是关系的要求。例如，关系 "is married to" 是一元的，但不是递归的。如果以可能进行递归的方式实施，则必须注意防止它发生——否则在工作人员中可能会出现一些尴尬的时刻。
注意我没有在任何地方提到 "primary key" 或 "foreign key"。这些是实现细节，而不是关系类型的特征。人们可以完全理解关系的概念，而无需使用甚至不考虑这些术语。
说了这么多，应该指出的是 Identifying 和 Non-Identifying，即使不是完全主观的术语，也是敏感的上下文。例如，一所大学在同一学期安排多门 class 同一课程是完全合理的。因此，3 号房间可能有一个 "Algebra 2" class，7 号房间可能有一个 "Algebra 2" class，12 号房间可能还有一个。这大大加强了 [=68] 之间的关系=] 和房间。现在 "I am taking Algebra 2" 的信息不足以确定您注册了三个 class 中的哪一个。
除此之外，第四次 "Algebra 2" class 也可以与其他人在同一房间举行，只是时间或日期不同。
因此，使用弱关系的初始设计在某些情况下可能工作得很好（小学校在一个学期内只开设一门 class 任何课程），但必须在不同的背景（较大的学校在同一学期提供或可能提供同一课程的多个 classes）。所以这不是实体类型所固有的。光看ER图是无法提前确定的。
根据我对这个问题的重新思考，尤其是@TommCatt 的回答，我的困惑似乎源于我对 strong/identifying 关系的错误定义：
"A strong/identifying relationship is one that connects a strong entity to a weak entity (that is, an entity that contains the primary key [PK] of its related entity as a component of its own primary key), and is indicated by a solid line."
定义的错误部分是"an entity that contains the primary key [PK] of its related entity as a component of its own component"。更准确地说，我应该说 "an entity that contains the foreign key [FK] from its related entity as a component of its own primary key [PK]".
从这个角度来看，那么一元关系不强的原因就很清楚了：一元关系的FK不是PK的一部分；因此，关系很弱，用虚线表示。
首先，一些定义确保我使用的术语清晰：
强实体和弱实体以及strong/identifying和weak/non-identifying关系：在ERD中，weak/non-identifying关系是一个连接两个强大的实体，并用虚线表示。 strong/identifying 关系是将强实体连接到弱实体（即，包含其相关实体的主键 [PK] 作为其自身的组件的实体
component主键），并用实线表示。例如，考虑这张图（借自 another post）：
课程（强实体）和Class（弱实体）之间的关系是强关系（实线），因为Class包含课程的PK（*CID）作为其自身PK的一部分（*CID，*日期）。相反，Room（强实体）和 Class（即使它是弱实体）之间的关系很弱，因为 Room 的 PK (*RID) 不是 Class 的 PK 的一部分。
- Unary/recursive 关系： 大多数关系都是二元的，因为它们连接两个独立的实体。例如，Course 和 Class 之间的关系以及 Room 和 Class 之间的关系是二元关系。当一个实体与其自身有关系时，您很少会拥有一元（也称为递归）关系。在图中，唯一的一元关系是与 Employee 实体的关系。它应该被标记为“管理”，因为它代表一个 Employee 可能管理 0 到许多 Employees 的事实；每个员工都由 1 名且只有 1 名员工管理。 Employee的PK是*EmpID，链接关系的外键(FK)是Manager。
那么，我的问题是：一元关系是 strong/identifying 还是 weak/non-identifying？一侧的 PK（Employee，*EmpID）不仅是多侧 PK（再次，Employee，*EmpID）的一部分，而且是其全部组成部分。因此，这表明它应该是一种强关系，带有一条实线，与示例图中描述的相反。谁能帮我澄清一下？
我不完全确定你对"strong" vs. "weak"的定义来自哪里（这可能是语言问题），但据我所知可以想到像这样：如果另一个实体不复存在或失去关系，这两个相关实体是否继续存在。在您的示例中，当 Course 被废弃时，Class 不存在。这可以通过一个table的PK包含其他的来表达，但不一定如此。 Class 可以（出于完全不同的原因）拥有自己的 id 作为 PK，并仅使用 CID 作为 FK。这不会改变这两个实体的事实关系。
另一方面，如果你有 Cars 和 Drivers 之类的东西，它们的 link 就会很弱。一个删除（死）driver不会突然导致他们的车消失。同样，被盗的汽车通常不会立即导致 driver 心脏病发作。这是一个"weak"link。两个东西一个没了还能继续存在
在您的 Employees 案例中，即使他们失去关系或另一个实体不在了，这两个人仍将继续存在。因此它是一个弱link。此外，为了坚持基于什么是 PK 的定义，Manager 是 Employee 的 FK，通常 不同于 其 PK，因为很少有人在公司等级制度中找到自己的经理。
Weak/Strong 关系： strong 关系只是意味着依赖实体不能脱离关系而存在。以Class，课程和房间为例。想象一下下面的对话：
"I think I'll teach a class this September."
"Good. What course will you teach?"
"I haven't decided yet."
好吧，在这位讲师决定课程之前，真的不可能 class。由于必须在创建 class 之前指定课程，因此关系很强。此外，在考虑选择哪个 class 时，"Bead Rendering" 中的 class 和 "Cybercrafting" 中的 class 是两个完全不同的事物，即使它们可能在 "Bead Rendering" 中相遇在同一时间同一房间（只是在不同的日子）。每个 class 的身份都不可避免地与课程绑定在一起。所以这个关系也是有辨识度的。
"I think I'll reach Discretionary Logic this September."
"Good. What room will it be in?"
"I haven't decided yet."
即使没有分配房间，class 仍然可以存在。是的，开学前必须分配房间，但目前我们仍然可以创建class，将"TBD"放入目录并允许学生注册。 class 可以没有空间存在（无论如何有一段时间）所以关系很弱。此外，"Discretionary Logic" 中的两个 class 在功能上是等价的，即使它们在不同的房间教授。与房间的关系与class的类型无关。关系是非识别的。
所以如果17号房间报名参加Bead Rendering的同学被通知换到12号房间，他们就不会想，"This is a completely different class!"不，class是一样的，只是位置不同。但是，如果他们被告知 class 现在是 "Second-hand Carnival Staffing"，那么他们就是对的。这是现在完全不同的class。这就是识别关系和非识别关系的区别。
Unary/Recursive 关系： 重要的是要认识到所有关系都至少由两个实体组成。通过这种方式，数据库关系类似于人际关系——Tango 需要两个人。 "unary" 只是表示关系的两边都由同一个逻辑实体填充。
很容易看出 Class 实体和 Room 实体之间的 "meets in" 关系不能在两个 Class 实体或两个 Room 实体之间满足。但是，"is managed by" 关系需要双方都有一个 Employee 实体。同样显而易见的是，员工并不需要这种关系才能存在。也许该员工是新员工，尚未分配经理。也许该员工是这个特定组织中的领头羊，没有其他员工配得上该法案。
或者如果由Carol管理的Pete现在由Sarah管理，Pete的本性没有改变。去问问他就好了。
所以这个一元关系是weak/non-identifying。它也是递归的，因为 Pete 可能由 Carol 管理，而 Carol 由 Sam 管理，而 Sam 是......好吧，你明白了。
一元关系往往也是递归的，尽管这更多是设计的结果，而不是关系的要求。例如，关系 "is married to" 是一元的，但不是递归的。如果以可能进行递归的方式实施，则必须注意防止它发生——否则在工作人员中可能会出现一些尴尬的时刻。
注意我没有在任何地方提到 "primary key" 或 "foreign key"。这些是实现细节，而不是关系类型的特征。人们可以完全理解关系的概念，而无需使用甚至不考虑这些术语。
说了这么多，应该指出的是 Identifying 和 Non-Identifying，即使不是完全主观的术语，也是敏感的上下文。例如，一所大学在同一学期安排多门 class 同一课程是完全合理的。因此，3 号房间可能有一个 "Algebra 2" class，7 号房间可能有一个 "Algebra 2" class，12 号房间可能还有一个。这大大加强了 [=68] 之间的关系=] 和房间。现在 "I am taking Algebra 2" 的信息不足以确定您注册了三个 class 中的哪一个。
除此之外，第四次 "Algebra 2" class 也可以与其他人在同一房间举行，只是时间或日期不同。
因此，使用弱关系的初始设计在某些情况下可能工作得很好（小学校在一个学期内只开设一门 class 任何课程），但必须在不同的背景（较大的学校在同一学期提供或可能提供同一课程的多个 classes）。所以这不是实体类型所固有的。光看ER图是无法提前确定的。
根据我对这个问题的重新思考，尤其是@TommCatt 的回答，我的困惑似乎源于我对 strong/identifying 关系的错误定义： "A strong/identifying relationship is one that connects a strong entity to a weak entity (that is, an entity that contains the primary key [PK] of its related entity as a component of its own primary key), and is indicated by a solid line."
定义的错误部分是"an entity that contains the primary key [PK] of its related entity as a component of its own component"。更准确地说，我应该说 "an entity that contains the foreign key [FK] from its related entity as a component of its own primary key [PK]".
从这个角度来看，那么一元关系不强的原因就很清楚了：一元关系的FK不是PK的一部分；因此，关系很弱，用虚线表示。