1 建模和表示法
1.1 ERD
是 1960 年代的前关系型。它无法处理关系键，这意味着它对关系数据建模毫无希望。在关系范式中，关系键（复合的）是核心，因此每个实体的身份无法在 ERD 中进行分析、建模或定义。
ERD 中没有定义独立/从属表或标识/非标识关系的关系概念，因为没有关系键是没有意义的，这在扩展 ERD 并尝试添加这些时会导致很多混乱。此外，正如您所发现的，它没有域/数据类型的符号；亚型；等等
ERD 从来都不是标准。由于它不可用，每个试图将它用于 SQL 实现的人都必须“扩展” ERD，这会产生一百万个符号，所有这些符号都是不同的且不完整的。并且必须向读者解释。而标准不需要解释，因为它是完整的和记录的，一次。
从技术上讲，ERD 不是一个模型（这意味着一个数学、逻辑基础）。语义是原始的，远不完整。事实上，它对于建模、周期，甚至对于前关系文件系统来说都是没有希望的。
1.2 IDEF1X
是关系数据建模的标准，自 1980 年代起可用，自 1993 年起成为标准。因此它是完整的，而扩展的 ERD 永远不会完整，无论您扩展多少。
“教科书”的学者和作者一无所知：事实证明，他们落后于行业 50 年（定义）和 40 年（SQL 平台上的实施）。他们被困在 1960 年代的记录归档系统中，这是物理的，以RecordID 为特征，并且他们将其作为“关系”进行营销。
而 Codd's Relational Model 是完全合乎逻辑的，具有数学基础，并且提供了更多的完整性；力量;和速度。
要完全使用 ERD，您必须使用一些私有符号来扩展它，就像您所做的那样。与其在IDEF1X 的方向上逐步而痛苦地移动，我建议您直接切换到它，并获得全部收益。您可能会发现这个 IDEF1X Introduction 很有用。
1.3 逻辑与物理数据模型
关于区别写了很多废话。
Logical 模型在迭代中简单地发展到稳定的地步，然后它是Physical，可以在特定的 SQL 平台上实现。也就是说，没有“转换”过程。
在良好的数据建模工具中，例如ERwin，它是一个文件，而不是两个或三个，逻辑与物理只是该文件的不同视图。例如。逻辑中的Domain 是物理中的DataType。物理当然是特定于目标平台的，例如。 BOOLEAN 在一个是BIT 在另一个。如果您没有使用数据建模工具，或者使用的工具很差，当然，您将拥有单独的文件，并且您必须处理随之而来的同步问题。
但是，对此进行建模的正确方法是什么？我现在如何对访问和床位的关系进行建模，同时仍然保持鉴别器必须具有特定值才能符合这些关系的约束条件？
在这方面，问题不在于逻辑与物理 DM，问题的所有方面都在两者中实现。
是的，它是关于符号的。 IDEF1X 中没有符号问题或区别（逻辑与物理），因为它是完整的。
我是不是忘了在物理数据模型中表示这个约束
不，它们都是在两者中绘制的，它们是在 DDL 中实现的。
并确保在创建表时在代码中实现它？
如果您使用数据建模工具，它会输出特定于目标平台的 SQL。否则，当然，您必须编写自己的 DDL 并确保它是正确的。在任何情况下，SQL 都是相同的（不包括 SQL 风格的差异）。
- 警告。假装的 SQL（所有免费软件“sql”和 Oracle）不兼容 SQL，他们对该术语的使用不正确。它们无法实现普通的 SQL 特性，例如 Constraints for Subtypes 或 ACID Transactions；等
或者是否有表示这种类型约束的物理数据模型的符号？
不，IDFE1X 中的符号没有区别。您的问题似乎是由于您对 ERD 的扩展。首先，ERD 不能用于关系数据建模，并且不能处理关系键或子类型。其次，您的扩展，尽管它们可能很好，但没有 IDEF1X 所具有的普通关系表示法。同样，只需切换到 IDEF1X。
2 Codd 的关系模型
与学术界和教科书中的各种原始废话不同，它们被误导为“关系”。
2.1 子类型
我进行了很多搜索，但似乎找不到任何关于此的内容。我发现的所有材料都谈到了创建子类型以隔离特定于子类型的属性而不是特定于子类型的关系。
没有属性的子类型完全没有问题，就像没有属性的行完全没有问题一样。请记住，每个实体都是一个事实（一个事实在一个地方），而事实是由关系键建立的，属性是次要的（Codd's 3NF 正确理解）。因此Resident 和OutPatient 是离散的Facts，无论每个Subtype 是否具有属性；是否存在支持外键的事实是一个单独的问题。
非常感谢您发现我无法提供的数据的建议或参考
您可能会发现此 Subtype 文档很有用。例如，转到我的个人资料，查找您感兴趣的任何答案。
如果您需要更详细的信息，我与一位试图跨越该领域学术界与现实之间巨大鸿沟的学者进行了很长的关于子类型和符号的讨论，他最近从我的数据模型中“找到”了 IDEF1X。我使用了 IDEF1X 的更正形式（它是由一位学者编写的），当它更精确时使用预先存在的 IEEE 表示法。论述进入 原始 IDEF1X 与 更正 形式的原因和原因。 70个帖子很长，有文档总结。随便问问。
显然，没有 OUTPATIENT 或 RESIDENT 表，而只有一个包含患者类型鉴别器的 PATIENT 表是有意义的。
没有。每个子类型都是一个单独的表，在逻辑模型（第一个）和物理模型（最后一个）以及 DDL 中。物理只是逻辑的实现级别，物理中不应该有任何不在逻辑中的东西（你不想实现一个不合逻辑、不语义的东西；不是关系（这绝对是逻辑的，和无限）。
- 考虑到将来可能会扩展数据库，并且您可能在 Subtypes 中有属性。
- 如果集群是独占的，则 Basetype 表必须有一个 Discriminator。
- 如果是非排他性的，则没有鉴别器。
- 超类型的含义完全不同，学者们使用术语松散且不正确。例如。 Superkey 的概念是歇斯底里的和反关系的。
2.2 数据模型
这是 IDEF1X 表示法的逻辑模型，显示的是属性，而不是域。
我已经纠正了一些错误：鉴于您展示的建模水平，我认为它们不需要完整的解释。
-
Person 子类型是非排他性的（没有鉴别器）
-
Patient 子类型是独占的（需要鉴别器）
那将在您的代码中用于确定子类型，否则JOIN 为子类型
-
由于Resident::Bed 是1::1，属性（Bed FK）可以位于Resident。
这种处理可确保Patient 可能分配给的Bed 存在。
-
考虑：
-
OutPatient 访问CareCenter 时，不就是为了获得某种待遇，必须记录吗？
- 治疗不是在
Physician’s控制下获得的，治疗细节不应该记录吗？
因此OutPatient 获得Treatment，与Resident 相同，在 Basetype 中很常见。
-
Visit 可以消除
（同样，Resident 或 OutPatient 是否接受处理与子类型有关）。
PDF 中的数据模型。
2.3 谓词
谓词可以直接从图形模型中读取，这样的评估为建模过程提供了一个极好的反馈循环。请阅读并验证。
- 例如。谓词
Each Bed accommodates 0-to-n Residents 会引起可以避免的争吵。
同样，学者和作者不了解关系模型，因此他们对谓词一无所知。要获得良好的介绍，请参阅Relational Table Naming Convention，顶部的关系、动词短语部分和末尾的谓词部分。
2.4 空
关系数据库中的空值是规范化错误的明确指示。我已经删除了它们。
3 优秀
学者和作者只了解 1960 年的物理记录归档系统（为了方便而放置在 SQL 容器中），因此他们只了解 参照完整性。 他们不了解 Codd 的关系模型，因此他们无法理解，也无法教授， 关系完整性，这是合乎逻辑的，并且提供比 50 年过时的归档系统更高的数据完整性。
-
您的模型允许任何 Physician 处理任何 Patient，如果您遵循文献，这对于 RFS 来说是典型的，但对于关系而言则不正常。
- 我怀疑这就是你想要的数据库。我想你只想要治疗
Physician，ProviderNo 治疗Patient。
-
随着模型的进展，您可能希望确保 Bed 仅分配给一个 Resident。我没有对其建模，因为我需要被告知：入院和床位分配是两个管理步骤还是一个？
-
您不需要Speciality 和TreatmentName 的查找表吗？
-
数据建模是一种迭代练习：只有在建立并考虑模型时，问题才会暴露出来，从而导致下一次迭代。