V1.0
在对数据进行组织和规范化时，关系数据库和SQL（专为它们而设计）的性能要好得多。就性能和关系能力而言，一个大表是未规范化的，并且已经瘫痪了。
您的需求需要一个普通的表的Supertype-Subtype集群。不幸的是，像这样的普通关系结构并不“常见”。
标准子类型符号是半圆。
Supertype :: Subtype的基数始终为1 :: 0–1。
子类型主键是超类型主键。它也是超类型的外键。
有两种类型：
排他性，每个超类型行只有一个子类型，用半圆X表示。
非排他性，每个超类型行中有一个以上子类型
您的专属。此类型需要一个鉴别器，以标识超级类型行中哪个子类型处于活动状态。如果子类型的数量少，则可以使用指标；否则，需要分类表。
请注意，所有这些，结构，规则，约束，支持它以及提供数据完整性所需的信息都可以在普通的IEC / ISO / ANSI SQL中获得。（非SQL不符合SQL要求）。
数据
命名非常重要。建议我们按行命名表格，而不要按内容，含义或动作命名。您说的是活动，但我只能看阅读。
这些阅读或事件必须有上下文。我看不到EventId如何悬空。我假设阅读材料是针对特定患者的。请指教，我将更改其型号。
复合键或复合键是正常的。SQL非常有能力（非SQL没有）。
PatientId
已经作为FK存在于中Reading
，并用于形成其PK。不需要 额外的ReadingId
列和 额外的索引 ，这将是100％冗余的。SQL还具有处理许多表的能力（我正在处理的数据库目前超过500个表），关系数据库的本质是大量较小的表。
这是纯第五范式（没有重复的列；没有更新异常）。
可以将其进一步归一化为第六范式，从而可以获得进一步的好处；并且可以优化6NF等。但这里并不需要所有这些。
有些表恰好在6NF中，但这是结果，而不是意图，因此不能这样声明。
。
如果您提供有关您所关注的限制和替代的信息，我可以提供解决这些问题的模型。
由于对数据 进行了 建模，因此已经将其设置为非常快速的比较（生成警报等）。
