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