Supertype/subtype ERD 的表示法
Supertype/subtype Notation for ERD
这更像是一种符号和 'proper procedure' 类型的问题。
请看下面我的增强型 ERD 逻辑模型中一些关系的图像。患者可以是 OUTPATIENT 或 RESIDENT，但没有特定于 OUTPATIENTS 或 RESIDENTS 的属性。但是，存在特定于子类型的关系，因为只有 OUTPATIENTS 可以与就诊相关联，只有 RESIDENTS 可以与床位相关联。
我正在将其转换为物理数据模型。显然，没有 OUTPATIENT 或 RESIDENT table 并且只有一个包含患者类型鉴别符的 PATIENT table 是有意义的。
- 但是建模的正确方法是什么？
- 我现在如何对 VISITS 和 BEDS 的关系建模，同时仍然保持鉴别器必须具有特定值才能符合这些关系的约束条件？
- 我是否忘记在物理数据模型中表示此约束并确保在创建 table 时在代码中实现它？
- 或者是否有表示此类约束的物理数据模型的符号？
扩展 ERD 中的 CareCenter 架构部分
我已经进行了大量搜索，但似乎找不到任何相关信息。我发现的所有 material 都在谈论创建子类型以隔离特定于子类型的属性而不是特定于子类型的关系。
- 非常感谢您发现我无法提供的建议或参考数据！
（如果您真的想理解我的 EERD 部分，了解 PATIENT 是 PERSON 超类型的子类型可能会有所帮助。）
1 建模和符号
1.1 ERD
是 pre-Relational，1960 年代。它不能处理关系键，这意味着它对关系数据建模没有希望。在关系范式中，关系键（复合的）是核心，因此不能在 ERD 中分析、建模或定义每个实体的身份。
ERD中没有对Independent/Dependenttable或Identifying/Non-Identifying关系的Relational概念进行定义，因为没有Relational Key是没有意义的，这会导致很多混淆在扩展 ERD 并尝试添加这些时。此外，正如您所发现的，它没有 Domain/Datatype 的符号；亚型；等等
ERD 从来都不是标准。由于它不可用，每个试图将它用于 SQL 实现的人都必须“扩展”ERD，这会导致一百万个符号，所有这些符号都是不同且不完整的。并且必须向 reader 解释。而标准不需要解释，因为它是完整的并记录在案，一次。
从技术上讲，ERD 不是模型（这意味着数学、逻辑基础）。语义是原始的，远未完成。事实上，即使对于关系归档系统之前的建模，它也是无望的。
1.2 IDEF1X
是关系数据建模标准，自 1980 年代以来可用，自 1993 年以来就是一个标准。因此它是完整的，而扩展的 ERD 永远不会完整，无论您扩展多少。
“教科书”的学者和作者是一无所知：事实证明，他们落后于行业 50 年（定义）和 40 年（SQL 平台上的实施）。他们被困在 1960 年代的记录归档系统中，这是物理的，以 RecordID 为特征，并且他们将其作为“关系”进行营销。
而 Codd's Relational Model 是完全合乎逻辑的，具有数学基础，并且提供了更多的完整性；力量;和速度。
要完全使用 ERD，您必须像您所做的那样使用一些私有符号来扩展它。与其逐步痛苦地朝着 IDEF1X 的方向前进，我建议您直接切换到它，并获得全部好处。您可能会发现此 IDEF1X Introduction 有用。
1.3 逻辑与物理数据模型
关于区别写了一大堆废话
逻辑模型在迭代中简单地进展到 stable，然后它是物理模型，可以在具体 SQL 平台。也就是说，没有“转换”过程。
在好的数据建模工具中，例如 ERwin，它是一个文件，而不是两个或三个，逻辑与物理只是该文件的不同视图。例如。逻辑中的 Domain 是物理中的 DataType。物理当然特定于目标平台，例如。一个中的 BOOLEAN 是另一个中的 BIT。如果您没有使用数据建模工具，或者使用的工具很差，当然，您将拥有单独的文件，并且必须处理随之而来的同步问题。
But what is the proper way to model this? How do I now model the relationships to visits and beds while still maintaining the constraint that the discriminator must be of a certain value to qualify for those relationships?
在这方面，问题不是关于逻辑 DM 还是物理 DM，问题的所有方面都在两者中实现。
是的，这是关于符号的。 IDEF1X 中没有符号问题或差异（逻辑与物理），因为它是完整的。
Do I just forget about representing this constraint in the physical data model
不是，两者都是画出来的，都是在DDL中实现的。
and make sure its implemented in the code when the tables are created?
如果您使用数据建模工具，它会喷出特定于目标平台的 SQL。否则，当然，您必须编写自己的 DDL 并确保它是正确的。无论如何，SQL 是相同的（不计算 SQL 口味的差异）。
- 警告。假装 SQLs（所有免费软件“sqls”和 Oracle）不符合 SQL，他们对术语的使用不正确。它们无法实现普通的 SQL 特性，例如子类型约束或 ACID 事务；等等
Or is there a notation for physical data models which represents this type of constraint?
不，IDFE1X 中的符号没有区别。您的问题似乎是由于您对 ERD 的扩展。首先，ERD 不可用于关系数据建模，也无法处理关系键或子类型。其次，您的扩展，尽管它们可能很好，但没有 IDEF1X 拥有的普通关系符号。同样，只需切换到 IDEF1X。
2 Codd 的关系模型
与学术界和教科书中所写的各种原始废话不同，它们被误导为“关系”。
2.1 子类型
I have done much searching and cannot seem to find anything about this. All of the material I have found talks about creating subtypes for the purpose of isolating attributes specific to a subtype and not relationships specific to a subtype.
没有属性的子类型完全没有问题，就像没有属性的行完全没有问题一样。请记住，每个实体都是一个 事实（一个地方的一个事实），事实由关系键建立，属性是次要的（正确理解 Codd 的 3NF）。因此 Resident 和 OutPatient 是离散的事实，无论每个子类型是否具有属性；事实是否存在支持外键，是一个单独的问题。
Advice or reference to data you have found that I was not able to is greatly appreciated
您可能会发现此 Subtype 文档很有用。例如，转到我的个人资料，查找您感兴趣的任何答案。
If you require even further detail, there is a long discourse regarding Subtypes and notation, that I had with the single academic who is trying to cross the great chasm between academia and reality in this field, who recently "found" IDEF1X from my data models. I use a corrected form of IDEF1X (it was written by an academic), using the pre-existing IEEE notation when it is more precise. The discourse goes into the whys and wherefores of the original IDEF1X vs the corrected form. It is long at 70 posts, and there is a document that summarises it. Just ask.
Obviously it makes sense to not have OUTPATIENT or RESIDENT tables and only a PATIENT table which contains a discriminator for the type of patient.
没有。在逻辑模型（第一个）和物理模型（最后一个）和 DDL 中，每个子类型都是一个单独的 table。物理只是逻辑的实现级别，你不应该在物理中有任何不在逻辑中的东西（你不想实现一个不合逻辑的东西，不是语义的；不是关系的（这是绝对合乎逻辑的，并且不受限制）。
- 考虑到以后数据库可能会扩充，你可能在Subtypes里面有属性。
- 如果群集是独占的，则基本类型 table 必须具有鉴别器。
- 如果它是非排他性的，则没有鉴别器。
- 超类型的意思完全不同，学术界对术语的使用不严谨且不正确。例如。 Superkey 的概念是歇斯底里的，反关系的。
2.2 数据模型
这是 IDEF1X 表示法中的逻辑模型，显示的是属性，而不是域。
我更正了一些错误：鉴于您展示的建模水平，我认为它们不需要完整的解释。
Person 子类型是非排他性的（无鉴别器）
Patient 子类型是独占的（需要鉴别器）
那就是要在你的代码中使用来确定子类型，否则JOIN到子类型
由于Resident::Bed是1::1，所以属性（Bed FK）可以位于Resident。
这种处理确保 Bed 可以分配给 Patient，存在。
考虑：
- 当一个
OutPatient 访问 CareCenter 时，不就是为了获得某种必须记录的待遇吗？
- 不是在
Physician’s控制下得到的治疗，难道不应该记录治疗细节吗？
因此OutPatient得到Treatment，与Resident相同，在Basetype中很常见。
Visit可以消除
（同样，治疗是由 Resident 还是 OutPatient 接受的关于子类型）。
PDF.
中的数据模型
2.3 谓词
谓词可以直接从图形模型读取，这样的评估为建模过程提供了一个极好的反馈循环。请阅读并验证。
- 例如。 Predicate
Each Bed accommodates 0-to-n Residents 会引起可以避免的争吵。
同样，学者和作者不了解关系模型，因此他们对谓词一无所知。有关详细介绍，请参阅顶部的 Relational Table Naming Convention、Relationship、Verb Phrase 部分和末尾的 Predicate 部分.
2.4 空
关系数据库中的空值是规范化错误的明确指示。我已经删除了它们。
3 优秀
The academics and authors understand only 1960's physical Record Filing Systems (placed in an SQL container for convenience), thus they understand only Referential Integrity. They do not understand Codd's Relational Model, thus they cannot understand, and they cannot teach, Relational Integrity, which is logical, and provides far more data integrity than 50-year-obsolete filing systems.
您的模型允许任何 Physician 处理任何 Patient，如果您遵循文献，这对于 RFS 来说是典型的，但对于关系来说是次正常的。
- 我怀疑这就是您想要的数据库。我想你只想治疗
Physician，ProviderNo 治疗 Patient。
随着模型的发展，您可能希望确保 Bed 仅分配给一个 Resident。我没有建模，因为我需要被告知：入院和分配床位是两个管理步骤还是一个？
您不需要查找 Speciality 和 TreatmentName 的 table 吗？
数据建模是一种迭代练习：只有在建立模型并进行深思熟虑后，问题才会暴露出来，从而导致下一次迭代。
这更像是一种符号和 'proper procedure' 类型的问题。
请看下面我的增强型 ERD 逻辑模型中一些关系的图像。患者可以是 OUTPATIENT 或 RESIDENT，但没有特定于 OUTPATIENTS 或 RESIDENTS 的属性。但是，存在特定于子类型的关系，因为只有 OUTPATIENTS 可以与就诊相关联，只有 RESIDENTS 可以与床位相关联。
我正在将其转换为物理数据模型。显然，没有 OUTPATIENT 或 RESIDENT table 并且只有一个包含患者类型鉴别符的 PATIENT table 是有意义的。
- 但是建模的正确方法是什么？
- 我现在如何对 VISITS 和 BEDS 的关系建模，同时仍然保持鉴别器必须具有特定值才能符合这些关系的约束条件？
- 我是否忘记在物理数据模型中表示此约束并确保在创建 table 时在代码中实现它？
- 或者是否有表示此类约束的物理数据模型的符号？
扩展 ERD 中的 CareCenter 架构部分
我已经进行了大量搜索，但似乎找不到任何相关信息。我发现的所有 material 都在谈论创建子类型以隔离特定于子类型的属性而不是特定于子类型的关系。
- 非常感谢您发现我无法提供的建议或参考数据！
（如果您真的想理解我的 EERD 部分，了解 PATIENT 是 PERSON 超类型的子类型可能会有所帮助。）
1 建模和符号
1.1 ERD
是 pre-Relational，1960 年代。它不能处理关系键，这意味着它对关系数据建模没有希望。在关系范式中，关系键（复合的）是核心，因此不能在 ERD 中分析、建模或定义每个实体的身份。
ERD中没有对Independent/Dependenttable或Identifying/Non-Identifying关系的Relational概念进行定义，因为没有Relational Key是没有意义的，这会导致很多混淆在扩展 ERD 并尝试添加这些时。此外，正如您所发现的，它没有 Domain/Datatype 的符号；亚型；等等
ERD 从来都不是标准。由于它不可用，每个试图将它用于 SQL 实现的人都必须“扩展”ERD，这会导致一百万个符号，所有这些符号都是不同且不完整的。并且必须向 reader 解释。而标准不需要解释，因为它是完整的并记录在案，一次。
从技术上讲，ERD 不是模型（这意味着数学、逻辑基础）。语义是原始的，远未完成。事实上，即使对于关系归档系统之前的建模，它也是无望的。
1.2 IDEF1X
是关系数据建模标准，自 1980 年代以来可用，自 1993 年以来就是一个标准。因此它是完整的，而扩展的 ERD 永远不会完整，无论您扩展多少。
“教科书”的学者和作者是一无所知：事实证明，他们落后于行业 50 年（定义）和 40 年（SQL 平台上的实施）。他们被困在 1960 年代的记录归档系统中，这是物理的，以 RecordID 为特征，并且他们将其作为“关系”进行营销。
而 Codd's Relational Model 是完全合乎逻辑的，具有数学基础，并且提供了更多的完整性；力量;和速度。
要完全使用 ERD，您必须像您所做的那样使用一些私有符号来扩展它。与其逐步痛苦地朝着 IDEF1X 的方向前进，我建议您直接切换到它，并获得全部好处。您可能会发现此 IDEF1X Introduction 有用。
1.3 逻辑与物理数据模型
关于区别写了一大堆废话
逻辑模型在迭代中简单地进展到 stable，然后它是物理模型，可以在具体 SQL 平台。也就是说，没有“转换”过程。
在好的数据建模工具中，例如 ERwin，它是一个文件，而不是两个或三个，逻辑与物理只是该文件的不同视图。例如。逻辑中的 Domain 是物理中的 DataType。物理当然特定于目标平台，例如。一个中的 BOOLEAN 是另一个中的 BIT。如果您没有使用数据建模工具，或者使用的工具很差，当然，您将拥有单独的文件，并且必须处理随之而来的同步问题。
But what is the proper way to model this? How do I now model the relationships to visits and beds while still maintaining the constraint that the discriminator must be of a certain value to qualify for those relationships?
在这方面，问题不是关于逻辑 DM 还是物理 DM，问题的所有方面都在两者中实现。
是的，这是关于符号的。 IDEF1X 中没有符号问题或差异（逻辑与物理），因为它是完整的。
Do I just forget about representing this constraint in the physical data model
不是，两者都是画出来的，都是在DDL中实现的。
and make sure its implemented in the code when the tables are created?
如果您使用数据建模工具，它会喷出特定于目标平台的 SQL。否则，当然，您必须编写自己的 DDL 并确保它是正确的。无论如何，SQL 是相同的（不计算 SQL 口味的差异）。
- 警告。假装 SQLs（所有免费软件“sqls”和 Oracle）不符合 SQL，他们对术语的使用不正确。它们无法实现普通的 SQL 特性，例如子类型约束或 ACID 事务；等等
Or is there a notation for physical data models which represents this type of constraint?
不，IDFE1X 中的符号没有区别。您的问题似乎是由于您对 ERD 的扩展。首先，ERD 不可用于关系数据建模，也无法处理关系键或子类型。其次，您的扩展，尽管它们可能很好，但没有 IDEF1X 拥有的普通关系符号。同样，只需切换到 IDEF1X。
2 Codd 的关系模型
与学术界和教科书中所写的各种原始废话不同，它们被误导为“关系”。
2.1 子类型
I have done much searching and cannot seem to find anything about this. All of the material I have found talks about creating subtypes for the purpose of isolating attributes specific to a subtype and not relationships specific to a subtype.
没有属性的子类型完全没有问题，就像没有属性的行完全没有问题一样。请记住，每个实体都是一个 事实（一个地方的一个事实），事实由关系键建立，属性是次要的（正确理解 Codd 的 3NF）。因此 Resident 和 OutPatient 是离散的事实，无论每个子类型是否具有属性；事实是否存在支持外键，是一个单独的问题。
Advice or reference to data you have found that I was not able to is greatly appreciated
您可能会发现此 Subtype 文档很有用。例如，转到我的个人资料，查找您感兴趣的任何答案。
If you require even further detail, there is a long discourse regarding Subtypes and notation, that I had with the single academic who is trying to cross the great chasm between academia and reality in this field, who recently "found" IDEF1X from my data models. I use a corrected form of IDEF1X (it was written by an academic), using the pre-existing IEEE notation when it is more precise. The discourse goes into the whys and wherefores of the original IDEF1X vs the corrected form. It is long at 70 posts, and there is a document that summarises it. Just ask.
Obviously it makes sense to not have OUTPATIENT or RESIDENT tables and only a PATIENT table which contains a discriminator for the type of patient.
没有。在逻辑模型（第一个）和物理模型（最后一个）和 DDL 中，每个子类型都是一个单独的 table。物理只是逻辑的实现级别，你不应该在物理中有任何不在逻辑中的东西（你不想实现一个不合逻辑的东西，不是语义的；不是关系的（这是绝对合乎逻辑的，并且不受限制）。
- 考虑到以后数据库可能会扩充，你可能在Subtypes里面有属性。 - 如果群集是独占的，则基本类型 table 必须具有鉴别器。 - 如果它是非排他性的，则没有鉴别器。
- 超类型的意思完全不同，学术界对术语的使用不严谨且不正确。例如。 Superkey 的概念是歇斯底里的，反关系的。
2.2 数据模型
这是 IDEF1X 表示法中的逻辑模型，显示的是属性，而不是域。
我更正了一些错误：鉴于您展示的建模水平，我认为它们不需要完整的解释。
Person子类型是非排他性的（无鉴别器）Patient子类型是独占的（需要鉴别器）
那就是要在你的代码中使用来确定子类型，否则JOIN到子类型由于
Resident::Bed是1::1，所以属性（BedFK）可以位于Resident。 这种处理确保Bed可以分配给Patient，存在。考虑：
- 当一个
OutPatient访问CareCenter时，不就是为了获得某种必须记录的待遇吗？ - 不是在
Physician’s控制下得到的治疗，难道不应该记录治疗细节吗？
因此
OutPatient得到Treatment，与Resident相同，在Basetype中很常见。Visit可以消除 （同样，治疗是由Resident还是OutPatient接受的关于子类型）。
- 当一个
PDF.
中的数据模型2.3 谓词
谓词可以直接从图形模型读取，这样的评估为建模过程提供了一个极好的反馈循环。请阅读并验证。
- 例如。 Predicate
Each Bed accommodates 0-to-n Residents会引起可以避免的争吵。
同样，学者和作者不了解关系模型，因此他们对谓词一无所知。有关详细介绍，请参阅顶部的 Relational Table Naming Convention、Relationship、Verb Phrase 部分和末尾的 Predicate 部分.
2.4 空
关系数据库中的空值是规范化错误的明确指示。我已经删除了它们。
3 优秀
The academics and authors understand only 1960's physical Record Filing Systems (placed in an SQL container for convenience), thus they understand only Referential Integrity. They do not understand Codd's Relational Model, thus they cannot understand, and they cannot teach, Relational Integrity, which is logical, and provides far more data integrity than 50-year-obsolete filing systems.
您的模型允许任何
Physician处理任何Patient，如果您遵循文献，这对于 RFS 来说是典型的，但对于关系来说是次正常的。- 我怀疑这就是您想要的数据库。我想你只想治疗
Physician，ProviderNo治疗Patient。
- 我怀疑这就是您想要的数据库。我想你只想治疗
随着模型的发展，您可能希望确保
Bed仅分配给一个Resident。我没有建模，因为我需要被告知：入院和分配床位是两个管理步骤还是一个？您不需要查找
Speciality和TreatmentName的 table 吗？数据建模是一种迭代练习：只有在建立模型并进行深思熟虑后，问题才会暴露出来，从而导致下一次迭代。