Zero_or_One vs One_or_only_One 实体关系仅用于最初允许的 Null 字段
Zero_or_One vs One_or_only_One entity relation just for initially allowable Null field
我对以下场景的 步骤 4 中的 Zero_or_One 与 One_and_only_One 实体关系感到困惑。场景是：
有两个实体：School和Teacher。
没有定义基数，ERD 是：
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] | --------------------
| Headmaster_ID [FK] |----------------| ID [PK] |
---------------------- --------------------
一名教师可以担任零所或一所学校的校长，但不能超过一所学校。所以 ERD 变成：
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] | --------------------
| Headmaster_ID [FK] | 0|-------------| ID [PK] |
---------------------- --------------------
一个学校通常只有一个校长。但是如果Headmaster_ID被限制为Not_Null，那么新学校的校长（也是老师）必须在新学校插入之前插入Teacher table School table。我不想在数据库中有这个限制。那么对于给定的场景，哪一个是正确的？
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] | --------------------
| Headmaster_ID [FK] | 0|----------|0 | ID [PK] |
---------------------- --------------------
VS
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] | --------------------
| Headmaster_ID [FK] | 0|----------|| | ID [PK] |
---------------------- --------------------
所以我的问题是：使用 Zero_or_One 而不是 One_and_only_One 是否可以，因为一个字段最初可以 Null 短时间 ？或者在这种情况下应该做些什么？我想要从一般意义上更好地解释这个问题。
TL;DR
"normal"校长在场与"short time"不在场相比，重要的是它是否发生在学校的申请领域 ，教师和校长 vs 仅在您的特定实施中。 "normal" 和 "short" 无关。 ER 图记录了 每个 situation/state 的真实事实，可以 ever 在 application/database 中出现 associations/tables ].
无论申请领域是否总是有校长，您提出的解决方案都不（非常）合适。
如果你只想要校长直到学校有校长，那么你必须使用特定于 DBMS 的安全措施and/or 非声明性代码来获得你能得到的保证。
基本图
您的第 2 步不合理地假定 FK。基本情况如下：
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] |Headmastered_by --------------------
| | -------------------- | ID [PK] |
---------------------- Headmaster_of--------------------
既然您已经决定了哪些实体参与 关系并根据实体顺序选择名称，您可以澄清你指的是什么关系。然后你可以观察它的基数（每个实体和顺序）。然后你可以决定如何表示它。
如果学校总是有校长
（从一个盒子沿着一条线读到一个基数和另一个盒子:)
一所学校是 Headmastered_by 1 位老师。 （每个学校都参加。）
老师是 Headmaster_of 一所 0 或 1 所学校。
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] |Headmastered_by --------------------
| | |0----------------|| | ID [PK] |
---------------------- Headmaster_of--------------------
Headmastered_by 不是 0 或多对 1，因此它不是由对 TEACHER 的 SCHOOL NOT NULL（关系）FK 表示的。它不是 0-or-many 到 0-or-1，所以它不是由 SCHOOL NULLable (SQL) FK to TEACHER 表示的。同样，在另一个方向上也没有 FK。但是，您可以用 SCHOOL NOT NULL FK 向 TEACHER 表示 Headmastered_by，这也是 UNIQUE NOT NULL（candidate/alternate 键）。那么学校和校长就是1:1而有些老师可能不是校长（未引用）
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] |Headmastered_by --------------------
| TEACHER_ID NOT NULL| |0----------------|| | ID [PK] |
| [UNIQUE] [FK] | Headmaster_of--------------------
----------------------
...但是 "no restriction" 在 "insert into Teacher"
如果您希望一所学校在应用程序域中只有一位校长，那么您 "do not want this restriction in the database" 和 "headmaster (also a teacher) for a new school must be inserted into Teacher table before the new school is inserted into School." 有点奇怪，那么您要么希望用户遵循协议，要么使用DBMS 安全措施 and/or 非过程代码强制在同一事务中进行两种更改，或者至少让用户尽量避免这样做。
如果一个学校可以有时没有校长
一个学校是 Headmastered_by 0 或 1 位老师。
老师是 Headmaster_of 一所 0 或 1 所学校。
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] |Headmastered_by --------------------
| | |0----------------0| | ID [PK] |
---------------------- Headmaster_of--------------------
您可以在一个 table 中使用 NULLable FK 以两种镜像方式表示它，该 FK 是 UNIQUE NULLable。 （如果您的 DBMS 支持 SQL 标准在 UNIQUE NULLable 列中的多个 NULL。）
______________________
| ONE | ____________________
---------------------- | OTHER |
| ID [PK] |Headmaster_one --------------------
| OTHER_ID NULLable | |0----------------0| | ID [PK] |
| [UNIQUE][FK] | Headmaster_other--------------------
----------------------
您可以通过向 SCHOOL 添加一个 NULLable FK 来表示它，该 FK 也是 UNIQUE NULLable。那么学校和校长就是1:1，而有些学校可能没有校长（NULL），有些老师可能不是校长（未引用）。
您可以通过向 TEACHER 添加一个 NULLable FK 来表示它，它也是 UNIQUE NULLable。那么校长和学校是1:1，而有些老师可能不是校长（NULL），有些学校可能没有校长（未引用）。
但是您可以通过添加具有 UNIQUE NOT NULL CKs (SCHOOL_ID) 和 (TEACHER_ID) 的 Headmaster table 以及 NOT NULL FKs 来对称地表示这种对称情况 table秒。这两个 CK 约束对校长学校和校长实施 1:1。但是可以有无校长学校（未引用）和非校长教师（未引用）。
____________________________________________
| SCHOOL | TEACHER | Headmaster
--------------------------------------------
| SCHOOL_ID NOT NULL | TEACHER_ID NOT NULL |
| [UNIQUE] [FK] | [UNIQUE] [FK] |
--------------------------------------------
应用程序关系的明显和自然的初始表示就是这样一个显式 table。如果你开始，那么当有适当的特殊情况时，你可以用 FKs 等重新排列到不对称模式。请注意，在非对称版本中，必须从 ostensibly/supposedly/called 和 实体 table 中提取 Headmaster_is/Headmaster_of 关系实例 ] 但实际上是 关系 table。 （FK 被不恰当地称为 "relationship"。）
(IDEF1X 方法在其 ER 图中记录了 NULLable 与 NOT NULL FK 的使用，而不是允许实现者选择方法。这是一个好主意，因为属性的 NULLability 对用户可见并影响 relationships/tables 的含义。）（当然，这也是不正式使用 ER 和 specify directly by relational schemas 的一个很好的论据。）
...但只是最初
关于强制（在应用程序域中）一所学校只有在有校长之前才能没有校长：在典型的 SQL DBMS 中，您不能以声明方式限制这一点。您可以编写触发器和存储过程来限制 UPDATE when IS NOT NULL 或 UPDATing/DELETing 行，但用户可以绕过这些。您可以添加一个显示最后一个值的列，或者它是否为 NULL，或者为此添加一个 table，以限制用户对您的 table 的更新，但您不能限制用户访问该 attribute/table。所以这归结为您的 DBMS 提供的安全措施。
我对以下场景的 步骤 4 中的 Zero_or_One 与 One_and_only_One 实体关系感到困惑。场景是：
有两个实体：
School和Teacher。没有定义基数，ERD 是：
______________________ | SCHOOL | ____________________ ---------------------- | TEACHER | | ID [PK] | -------------------- | Headmaster_ID [FK] |----------------| ID [PK] | ---------------------- --------------------一名教师可以担任零所或一所学校的校长，但不能超过一所学校。所以 ERD 变成：
______________________ | SCHOOL | ____________________ ---------------------- | TEACHER | | ID [PK] | -------------------- | Headmaster_ID [FK] | 0|-------------| ID [PK] | ---------------------- --------------------一个学校通常只有一个校长。但是如果
Headmaster_ID被限制为Not_Null，那么新学校的校长（也是老师）必须在新学校插入之前插入TeachertableSchooltable。我不想在数据库中有这个限制。那么对于给定的场景，哪一个是正确的？______________________ | SCHOOL | ____________________ ---------------------- | TEACHER | | ID [PK] | -------------------- | Headmaster_ID [FK] | 0|----------|0 | ID [PK] | ---------------------- --------------------VS
______________________ | SCHOOL | ____________________ ---------------------- | TEACHER | | ID [PK] | -------------------- | Headmaster_ID [FK] | 0|----------|| | ID [PK] | ---------------------- --------------------
所以我的问题是：使用 Zero_or_One 而不是 One_and_only_One 是否可以，因为一个字段最初可以 Null 短时间 ？或者在这种情况下应该做些什么？我想要从一般意义上更好地解释这个问题。
TL;DR
"normal"校长在场与"short time"不在场相比，重要的是它是否发生在学校的申请领域 ，教师和校长 vs 仅在您的特定实施中。 "normal" 和 "short" 无关。 ER 图记录了 每个 situation/state 的真实事实，可以 ever 在 application/database 中出现 associations/tables ].
无论申请领域是否总是有校长，您提出的解决方案都不（非常）合适。
如果你只想要校长直到学校有校长，那么你必须使用特定于 DBMS 的安全措施and/or 非声明性代码来获得你能得到的保证。
基本图
您的第 2 步不合理地假定 FK。基本情况如下：
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] |Headmastered_by --------------------
| | -------------------- | ID [PK] |
---------------------- Headmaster_of--------------------
既然您已经决定了哪些实体参与 关系并根据实体顺序选择名称，您可以澄清你指的是什么关系。然后你可以观察它的基数（每个实体和顺序）。然后你可以决定如何表示它。
如果学校总是有校长
（从一个盒子沿着一条线读到一个基数和另一个盒子:)
一所学校是 Headmastered_by 1 位老师。 （每个学校都参加。）
老师是 Headmaster_of 一所 0 或 1 所学校。
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] |Headmastered_by --------------------
| | |0----------------|| | ID [PK] |
---------------------- Headmaster_of--------------------
Headmastered_by 不是 0 或多对 1，因此它不是由对 TEACHER 的 SCHOOL NOT NULL（关系）FK 表示的。它不是 0-or-many 到 0-or-1，所以它不是由 SCHOOL NULLable (SQL) FK to TEACHER 表示的。同样，在另一个方向上也没有 FK。但是，您可以用 SCHOOL NOT NULL FK 向 TEACHER 表示 Headmastered_by，这也是 UNIQUE NOT NULL（candidate/alternate 键）。那么学校和校长就是1:1而有些老师可能不是校长（未引用）
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] |Headmastered_by --------------------
| TEACHER_ID NOT NULL| |0----------------|| | ID [PK] |
| [UNIQUE] [FK] | Headmaster_of--------------------
----------------------
...但是 "no restriction" 在 "insert into Teacher"
如果您希望一所学校在应用程序域中只有一位校长，那么您 "do not want this restriction in the database" 和 "headmaster (also a teacher) for a new school must be inserted into Teacher table before the new school is inserted into School." 有点奇怪，那么您要么希望用户遵循协议，要么使用DBMS 安全措施 and/or 非过程代码强制在同一事务中进行两种更改，或者至少让用户尽量避免这样做。
如果一个学校可以有时没有校长
一个学校是 Headmastered_by 0 或 1 位老师。
老师是 Headmaster_of 一所 0 或 1 所学校。
______________________
| SCHOOL | ____________________
---------------------- | TEACHER |
| ID [PK] |Headmastered_by --------------------
| | |0----------------0| | ID [PK] |
---------------------- Headmaster_of--------------------
您可以在一个 table 中使用 NULLable FK 以两种镜像方式表示它，该 FK 是 UNIQUE NULLable。 （如果您的 DBMS 支持 SQL 标准在 UNIQUE NULLable 列中的多个 NULL。）
______________________
| ONE | ____________________
---------------------- | OTHER |
| ID [PK] |Headmaster_one --------------------
| OTHER_ID NULLable | |0----------------0| | ID [PK] |
| [UNIQUE][FK] | Headmaster_other--------------------
----------------------
您可以通过向 SCHOOL 添加一个 NULLable FK 来表示它，该 FK 也是 UNIQUE NULLable。那么学校和校长就是1:1，而有些学校可能没有校长（NULL），有些老师可能不是校长（未引用）。
您可以通过向 TEACHER 添加一个 NULLable FK 来表示它，它也是 UNIQUE NULLable。那么校长和学校是1:1，而有些老师可能不是校长（NULL），有些学校可能没有校长（未引用）。
但是您可以通过添加具有 UNIQUE NOT NULL CKs (SCHOOL_ID) 和 (TEACHER_ID) 的 Headmaster table 以及 NOT NULL FKs 来对称地表示这种对称情况 table秒。这两个 CK 约束对校长学校和校长实施 1:1。但是可以有无校长学校（未引用）和非校长教师（未引用）。
____________________________________________
| SCHOOL | TEACHER | Headmaster
--------------------------------------------
| SCHOOL_ID NOT NULL | TEACHER_ID NOT NULL |
| [UNIQUE] [FK] | [UNIQUE] [FK] |
--------------------------------------------
应用程序关系的明显和自然的初始表示就是这样一个显式 table。如果你开始，那么当有适当的特殊情况时，你可以用 FKs 等重新排列到不对称模式。请注意，在非对称版本中，必须从 ostensibly/supposedly/called 和 实体 table 中提取 Headmaster_is/Headmaster_of 关系实例 ] 但实际上是 关系 table。 （FK 被不恰当地称为 "relationship"。）
(IDEF1X 方法在其 ER 图中记录了 NULLable 与 NOT NULL FK 的使用，而不是允许实现者选择方法。这是一个好主意，因为属性的 NULLability 对用户可见并影响 relationships/tables 的含义。）（当然，这也是不正式使用 ER 和 specify directly by relational schemas 的一个很好的论据。）
...但只是最初
关于强制（在应用程序域中）一所学校只有在有校长之前才能没有校长：在典型的 SQL DBMS 中，您不能以声明方式限制这一点。您可以编写触发器和存储过程来限制 UPDATE when IS NOT NULL 或 UPDATing/DELETing 行，但用户可以绕过这些。您可以添加一个显示最后一个值的列，或者它是否为 NULL，或者为此添加一个 table，以限制用户对您的 table 的更新，但您不能限制用户访问该 attribute/table。所以这归结为您的 DBMS 提供的安全措施。