子类型的关系数据建模

Question

子类型的关系数据建模

database-designrelational-databasedata-modelingsubtyperelational-model

5

我正在学习关系模型和数据建模。
但是我对子类型有一些困惑。

我知道数据建模是一个迭代的过程，有很多不同的建模方式。
但我不知道如何在不同选项之间进行选择。

示例

假设我们要对粒子（分子、原子、质子、中子、电子等）进行建模。
为简单起见，我们忽略夸克和其他粒子。

由于同类型的所有粒子的行为相同，因此我们不会对单个粒子进行建模。
换句话说，我们不会存储每个氢原子。
相反，我们将存储氢、氧和其他原子类型。
我们要建模的实际上是粒子类型及其之间的关系。

我随意使用“类型”这个词。
氢原子是一个实例。氢是一种类型。氢也是原子的一种类型。
是的，涉及到类型层次结构。而我们忽略了最低级别（单个粒子）。

方法

我可以想到几种建模方法。

1. 为每种事物（粒子类型）创建一个表（关系，实体）。

1.1 我想到的第一种方法。

质子 (Proton)
中子 (Neutron)
电子 (Electron)

原子 (Atom)
原子_质子 (Atom, Proton, Quantity)
原子_中子 (Atom, Neutron, Quantity)
原子_电子 (Atom, Electron, Quantity)

分子 (Molecule)
分子_原子 (Molecule, Atom, Quantity)

1.2 由于只有一种质子/中子/电子，我们可以简化它。

原子 (Atom, ProtonQuantity, NeutronQuantity, ElectronQuantity)
分子 (Molecule)
分子_原子 (Molecule, Atom, Quantity)

在这个简化模型中，关于质子的事实被遗失了。

2. 将所有事物放在一个表中，并使用关联表表示它们之间的关系。

2.1 每个关系都有一个关联表

粒子 (Particle)

Atom_Proton(Particle, Particle, ProtonQuantity)
Atom_Neutron(Particle, Particle, NeutronQuantity)
Atom_Electron(Particle, Particle, ElectronQuantity)
Molecule_Atom (Particle, Particle, AtomQuantity)

2.2 单一联想表

Particle (Particle)
ParticleComposition (Particle, Particle, Quantity)

这个简化并不会丢失任何东西，我认为这样更好。
但如果存在特定于Atom_Proton/Atom_Neutron/Atom_Electron的事实，则2.1可能更好。

2.3 结合2.1和2.2

Particle (Particle)

Atom_Proton (Particle, Particle, other attributes)
Atom_Neutron (Particle, Particle, other attributes)
Atom_Electron (Particle, Particle, other attributes) Molecule_Atom (Particle, Particle, other attributes)

ParticleComposition(Particle, Particle, Quantity, other attributes)

在这种方法中，有关粒子组成的常见属性存储在ParticleComposition中，
而有关粒子组成的特殊属性存储在特殊表中。

3. 使用子类型表。

3.1 为基类型Particle创建一个表，并为子类型（Atom，Molecule等）创建其他表。

Particle (Particle)

Proton (Particle, other attributes)
Neutron (Particle, other attributes)
Electron (Particle, other attributes)
Atom (Particle, other attributes)
Molecule (Particle, other attributes)

Atom_Proton (Particle, Particle, ProtonQuantity)
Atom_Neutron (Particle, Particle, NeutronQuantity)
Atom_Electron (Particle, Particle, ElectronQuantity)
Molecule_Atom (Particle, Particle, AtomQuantity)

3.2 我们还可以将Atom中的Atom_XXXQuantity表合并并删除Pronton/Neutron/Electron。

Particle (Particle)

Atom (Particle, ProtonQuantity, NeutronQuantity, ElectronQuantity)
Molecule (Particle, other attributes)

分子_原子 (粒子, 粒子, 原子数量)

这个更简单，但是关于质子/中子/电子的信息像1.2一样丢失了。

3.3 我们可以改变分子_原子的名称使其更加通用。

粒子 (粒子)

原子 (粒子, 质子数量, 中子数量, 电子数量)
分子 (粒子, 其他属性)

粒子组成 (粒子, 粒子, 数量)

这看起来像2.2，有附加表格用于子类型(原子, 分子)。
似乎2.2是3.3的特例。

3.4 我们可以结合所有上述方法得到一个通用模型。

粒子 (粒子)

质子 (粒子, 其他属性)
中子 (粒子, 其他属性)
电子 (粒子, 其他属性)
原子 (粒子, 其他属性)
分子 (粒子, 其他属性)

粒子组成 (粒子, 粒子, 数量, 其他属性)

原子_质子 (粒子, 粒子, 其他属性)
原子_中子 (粒子, 粒子, 其他属性)
原子_电子 (粒子, 粒子, 其他属性)
分子_原子 (粒子, 粒子, 其他属性)

看起来原子_质子、原子_中子、原子_电子和分子_原子可以被视为粒子组成的子类型。

这种方法是最复杂的，它包含了许多表格，但每个表格都有其作用。

问题

以上的设计是否违反了关系模型的规则？
哪种方法最好？这是否取决于我们如何考虑数据？是否取决于需求？
如果取决于需求，那么我们应该首先选择最简单的设计，然后使其更通用以适应新需求吗？
尽管生成的数据模型有很多相似之处，但初始设计可能会影响表/列的命名以及键的域是不同的。
- 如果我们选择为每种类型的物品使用一个表，则可以选择不兼容的键来表示Atom和Molecule，例如，对于Atom选用“原子重量”，而对于Molecule选用“分子名称”。
- 如果我们选择通用方法，则可以为所有粒子选择一个公共键。
  改变键可能对系统产生更大的影响，因此从简单设计发展到通用设计可能并不容易。
  你怎么看？

PS：这可能不是一个合适的例子，解决方案也可能存在问题，并且可能存在更多变化的方法，但希望您能理解要点。
如果您有更好的设计，请与我分享。

更新1

需要建模的数据是什么？

最初，我正在尝试建模粒子，因为

我认为它们之间存在子类型关系，这正是我要寻找的。
它们被人们充分理解（？）。
这是一个很好的例子，展示了人们如何理解世界。

以下是我脑海中的图片。 Particle Hierarchy

我没有清楚地表述这一点，因为我对我要建模的内容不是很清楚。
首先，我认为Atom是Proton / Neutron / Electron的父级，而Molecule是Atom的父级。
然后我意识到，这是关于组合，而不是关于子类型，也不是关于类型层次结构。

类型

我已经想了一段时间关于类型、分组和分类的问题。

以下是《SQL与关系理论》的一句话：

那么，类型究竟是什么呢？本质上，它是一组有限的命名值─某种特定的所有可能的值的集合：例如，所有可能的整数、所有可能的字符串、所有可能的供应商编号、所有可能的XML文档、具有特定标题的所有可能关系（等等）。

人们用“整数”这个名字来表示整数值的集合。实际上，人们创造概念和名称来识别事物，将事物分组以便我们可以理解/模拟世界。

质子是一组真正的质子，氢是一组氢原子，等等。在这个意义上，真正的粒子留在类型层次结构的最低层。

我一开始试图对所有粒子进行建模，但后来遇到了以下问题： - 我想不出一个适当的键来识别每个真正的粒子； - 要将它们存储在数据库中太多了。

因此，我决定忽略真正的粒子，而是对类型进行建模。

当我们说“分子由原子组成”时，它意味着“真正的H2O分子由两个真正的氢原子和一个氧原子组成”，也意味着“任何（类型的）分子都是由（某些类型的）原子组成的”。

与其陈述有关真正粒子的每个事实，我们不如只陈述有关粒子类型的事实。这就是我们通过分组事物和命名（类型）获得的好处。

粒子类型层次结构作为集合可以被翻译为集合定义。

第二级 - 真正粒子上面的类型：

S_proton = { p | p satisfied the definition of a proton }  
S_neutron = { n | n satisfied the definition of a neutron }  
S_electron = { e | e satisfied the definition of an electron }  
S_hydrogen = { h | h satisfied the definition of a hydrogen }  
S_oxygen = { o | o satisfied the definition of an oxygen }  
S_h2o = { w | w satisfied the definition of a h2o }  
S_o2 = { o | o satisfied the definition of a o2 }

更高级别

使用集合论的术语，如果 A 是 B 的子集，则类型 A 是类型 B 的子类型。

我最初认为我们可以将Atom类型定义为：

S_atom = S_hydrogen union S_oxygen union ...

然而，集合是关系，元素是元组，因此如果关系中的元组不兼容，则并集无法运行。

使用子类型表的方法解决了这个问题并建立了子集关系模型。

但在子类型方法中，Atom仍处于第二层。

高级类型定义为集合的集合。

S_atom = { S_hydrogen, S_oxygen, ... }
S_molecule = { S_h2o, S_o2, ... }
S_particle = { S_proton, S_neutron, S_electron, S_atom, S_molecule }

这意味着粒子是原子的一种类型，而氢是原子的一种类型。这样，粒子之间的关系可以在高层次上表示。

新的数据模型

4. 将类型视为类型层次结构

ParticleType (ParticleType, Name) ParticleTypeHierarchy (ParticleType, ParentType) ParticleComposition (PartileType, SubParticleType, Quantity)

示例数据：

ParticleType | ParticleType | Name | |--------------+----------| | Particle | Particle | | Proton | Proton | | Neutron | Neutron | | Electron | Electron | | Atom | Atom | | Molecule | Molecule | | H | Hydrogen | | O | Oxygen | | H2O | Water | | O2 | Oxygen |

ParticleTypeHierarchy | ParticleType | ParentType | |--------------+------------| | Proton | Particle | | Neutron | Particle | | Electron | Particle | | Atom | Particle | | Molecule | Particle | | Hydrogen | Atom | | Oxygen | Atom | | H2O | Molecule | | O2 | Molecule |

ParticleComposition | PartileType | SubParticleType | Quantity | |-------------+-----------------+----------| | H | Proton | 1 | | H | Electron | 1 | | He | Proton | 2 | | He | Neutron | 2 | | He | Electron | 2 | | H2O | H | 2 | | H2O | H | 2 | | H2O | O | 1 | | CO2 | C | 1 | | CO2 | O | 2 |

相比之下，这是子类型表方法的示例数据。

粒子

| ParticleId | ParticleName   |
|------------+----------------|
| H          | 氢             |
| He         | 氦             |
| Li         | 锂             |
| Be         | 铍             |
| H2O        | 水             |
| O2         | 氧气           |
| CO2        | 二氧化碳       |
分子

| MoleculeId | some_attribute |
|------------+----------------|
| H2O        | ...            |
| O2         | ...            |
| CO2        | ...            |
原子

| AtomId | ProtonQuantity | NeutronQuantity | ElectronQuantity |
|--------+----------------+-----------------+------------------|
| H      |              1 |               0 |                1 |
| He     |              2 |               2 |                2 |
| Li     |              3 |               4 |                3 |
| Be     |              4 |               5 |                4 |
粒子组成

| ParticleId | ComponentId | Quantity |
|------------+-------------+----------|
| H2O        | H           |        2 |
| H2O        | O           |        1 |
| CO2        | C           |        1 |
| CO2        | O           |        2 |
| O2         | O           |        2 |

亚原子

这些粒子类型是由人定义的，并且人们不断定义新概念以模拟现实的新方面。

我们可以定义“亚原子”，层次结构将如下所示：



方法4可以更容易地适应这种类型层次结构的更改。



更新2

需要记录的事实


世界上有不同类型的粒子：质子、中子、电子、原子、分子。
原子由质子、中子和电子组成。
分子由原子组成。
有许多不同类型的原子：氢、氧等。
有许多不同类型的分子：H2O、O2等。
氢原子由一个质子和一个电子组成；...
H2O分子由两个氢原子和一个氧原子组成；...
不同类型的粒子可能具有特殊属性，例如原子重量等。
...

- dzhu

从这个例子中不清楚质子、中子和电子是不同类型还是“亚原子粒子”的不同实例。这取决于您需要存储关于它们的哪些数据。 - Walter Mitty

1

好问题，对于一个学习者来说非常有思考性。我理解到包括3.3在内的所有内容。但是，在逐步进行到3.3之后，你如何获得3.4呢？将所有上述内容结合起来并不等同于通用。 - PerformanceDBA

@PerformanceDBA 您说得对，3.4版本并没有从3.3版本中进步。我只是发现所有的表都有一定的意义，因此3.4可能是一个有效的方法。在这个例子中，两个子类型关系层次确实有些过度设计了。 - dzhu

3个回答

3

当将关系数据模型简化到其精髓时，它没有多余的“规则”：数据库中的所有信息都必须表示为关系中元组的属性值。

所有“替代方案”潜在地符合该规则，前提是： - 每个属性都有一个关联的数据类型， - 数据库中每个关系中的每个元组将始终具有其属性的每个值， - 并且该值是与该属性关联的数据类型的成员。

编辑：您还未提供任何有关要在系统中记录的事实的详细信息。

编辑2：Walter M. 的第一条评论仍然适用。您的事实似乎以不同的级别陈述（在典型用例中将明显不同）：

“6. 氢原子由一个质子和一个电子组成”

通过进行小幅重写以消除其中的“AND”：

“6. <atom_id>原子含有<qty><subatomicparticletype>”

这个看起来像是会进入您的数据库的内容（如果您的用例就像可能被假定的那样典型/平凡）：

一个“H”原子包含1个质子一个“H”原子包含1个电子一个“H”原子包含1个中子

（注意，消除“AND”涉及将连词分成“原子”部分（双关语））

从这个例子中，我们可以开始思考如何处理<subatomicparticletype>。如果您的用例是这样的，即质子/中子/电子的存在只是一个给定的事实，并且它永远不会改变，那么您可以简单地使用数据类型来表示它，并且建模不需要更多，只需确定类型，以便您的模型读者将知道预期的值集。但是，如果您的用例是这样的，例如，您正在尝试找到一种完全新的化学模型，在其中可能还有质子旁边的foobarons [或者出于实验目的可能会再次删除它们]，则必须包括一个表，该表声明“<subatomicparticletype>是我的原子模型的一部分”。

此外，您还必须在模型中包含一个规则，即声称是原子的任何<subatomicparticletype>都必须确实是您原子模型的一部分。在SQLspeak中：您需要将ATOM_CONTAINS_PARTICLE表从EXISTING_PARTICLES表链接到FK。

在某种意义上，声明此规则就像您的

“2. 原子由质子，中子和电子组成。”

但请注意，您自己的数据库中没有一个表来说明这种情况。相反，通过向系统声明FK，将在目录中进行此特定声明。

你需要正确区分直接陈述感兴趣领域内的事物的语句类型（这些最终成为你概念模型中的实体/类等，很可能是数据库中的表），以及陈述感兴趣领域相关事物的语句类型（例如你的FK规则）。（在领域本身非常抽象的用例中，两者之间的界限可能非常薄弱甚至不存在。）

- Erwin Smout

我没有考虑到区分“领域内的事物”和“关于领域的事物”，谢谢你指出来。对于表格与前者匹配，而目录（外键规则等）与后者匹配这一点很有道理。a) 如果“关于领域的事物”也是“领域内的事物”，那么你在上句中所说的就是这个意思吗？b) 我们可以在表格中同时记录两者吗？ - dzhu

关于你最后一个问题，是的，那就是我上一句话的意思。而且，你确实可以在表格中记录两者，但是对其中信息的操作将会变得更加棘手和难以正确处理。原因在于“关于”这种信息本身更加动态/可变，无法被“硬编码”到最终的操作系统中。这也是为什么这种方法通常被强烈反对的原因。只有在真的避免不了的情况下才应该采用。 - Erwin Smout

讲解得很清楚，谢谢。因此，不同设计的选择取决于“业务问题”。在一个理念数据库中，领域内的事物（数据）存储在表格中，关于该领域的事物（有关数据完整性的规则）由非表结构强制执行。在数据库投入使用后，数据会不断出现和消失，而模式/结构保持不变，并且数据完整性得到维护。 - dzhu

1

@dzhu 基本表格断言是将其行中的命题替换为其谓词和不在其中的行的否定的AND。断言命题的谓词不需要基本表格（始终具有一个没有列的行）。但是，将其编写为基本表格谓词和/或值（约束谓词）可以让DBMS拒绝更新尝试并给出错误/空结果。例如 ∀ a [∃ m n [Molecule(m,a,n)] → Atom(a)]，即 (SELECT a FROM Molecule) = Atom，即 FK Molecule (a) REFERENCES Atom (a)。因此：只需找到足够的谓词来描述和检查您的情况即可。 - philipxy

@dzhu 每个表值（子）表达式都有一个谓词。表值是使谓词为真的元组。对于一个基本表名的表达式，该名称具有给定的谓词和值。JOIN 的谓词是它们的谓词的 AND；UNION 是 OR；MINUS/EXCEPT 是 AND NOT；PROJECT/SELECT 删除 X 具有输入表的 EXISTS X 谓词的谓词。ON 和 WHERE 会贡献它们条件的 AND。（在我的答案中搜索“语句”和“谓词”。） - philipxy

显示剩余5条评论

1

我喜欢Fowler对类表继承和单表继承的处理方式。你在这里提到了这两种设计。它们各有其用途和缺点。您可以将它们用作搜索词，然后会得到很多阅读材料。其中一些是有价值的。甚至在SO中还有几个带有这些名称的标签。

我不确定今天情况如何，但20年前，在数据库101课程中通常省略了子类型，而且这是每个数据库构建者在进入“现实世界”时都会遇到的问题。

- Walter Mitty

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- PerformanceDBA · Accepted Answer

初步

很好的问题，对于一个学习者来说非常有思想性。我认为你真正想要的是一次讨论，以便获得清晰度，这是一个数据建模练习。

我理解你的进展，包括3.3。你如何得到3.4（在向3.3的逐步进展之后）？对我来说，“组合以上所有内容”并不等于“通用”。
与其按照你的进展建立每个步骤的模型，不如让我根据你的讨论针对相关步骤回应一个TRD。
TRD 只有表格，由键和关系标识，在此阶段是相关的，我认为你非常了解属性（如果有），以及它们将与哪些键部署。在你实现稳定的TRD之后，你可以将其扩展为完整的DM。
在建立模型之后，如果清楚地发现它丢失了信息，那么它可以被安全地丢弃。考虑这样的模型的价值，因此这一步是不正确的。但继续讨论它是浪费时间的。我相信我在上一个问题中已经证明了这一点。

考虑这组表格关系图。

1.x

从我的角度来看，A First 将是第一个值得思考的合理TRD。

我不明白为什么质子/中子/电子是独立的表格。它们并不存在于自己之中，它们的重量等是固定的。它们只存在于原子的上下文中。
由于每个原子至少包含一个质子/中子/电子，因此可以在Atom中部署质子/中子/电子列。未绘制。稍后再说。

2.x

你的进展很好，除了一个明显的错误。

有关粒子组成的共同属性放在ParticleComposition中，而有关粒子组成的特殊属性放在特殊表格中。

不是这样的。有关粒子的共同属性放在Particle中。与关系有关的属性（即不常见的属性）放在ParticleComposition中。然后就没有“有关粒子组成的特殊属性”，也没有“特殊表格”。

3.x

考虑B Subtype。你的[3.1]大部分是正确的，除了：

我不明白粒子如质子/中子/电子是如何拥有孩子节点的，只有原子才有孩子节点。
我不明白粒子与其他粒子的关系（即什么是那个？）。对于所讨论的数据，分子由原子组成；原子由质子/中子/电子组成；而粒子要么是一个分子，要么是一个原子（互斥子类型）。
如果上述内容不正确，请纠正我。
有关此主题的完整详细信息，请参见子类型文档。

这可以被简化为C。因为您已经确定了每个原子的质子/中子/电子信息是固定的：每个都有一个条目。例如，每个壳层/能级没有区别；对于中子，零是可接受的（而不是空值）。

我之前讨论过谓词的巨大价值。这里的主要观点是，模型识别谓词。谓词验证模型；这是一个很好的反馈循环。我已经给出了谓词，以便您自己评估它们，并检查模型的有效性。

3.3

如果完全D规范化：原子始终至少具有一个质子条目；中子条目是可选的；并且每个壳层/能级都有区别。

注意谓词之间的差异。
请注意，尽管缩减是一种有效的技术，但它并不等同于规范化。

3.4

那似乎是所有内容的总和，展示为平面视图（派生关系、角度、结果集）。因此，对于理解来说非常好。但是，如果您将其提出作为一组表，那么由于各种规范化错误，它将是极其不正确的。如果更正，则会进展到[3.3]和我的[D规范化]。

问题

上述设计是否违反了关系模型的规则？

除了[3.3]之外，它们全部违反了许多规则。它们大多属于规范化错误类别。如果您提供了完整的模型或CREATE TABLE语句，则会出现相关的标识错误。

但是，如果上下文是数据建模练习以便于理解，那么这并不重要。如果此练习很严肃，那么上面的段落成立。

^{本节按照SO准则呈现，特别是：每当你看到错误信息时都要更正它。我确实在主题帖中发表了评论，但它们总是消失。因此，我把它放在这里。}

Erwin Smout：
当剥离关系数据模型的核心要素时，最多只有一个“规则”：数据库中的所有信息必须表示为关系元组中属性的值。

是的，这是其中之一的规则，但包含语句显然是错误的。

首先，在关系模型中有许多基本或一级规则。从记忆中，我会说大约有四十个。

其次，还有许多二级规则，这些规则通过逻辑推导来隐含地存在。

那些拥有技术资格和经验、能够理解RM并遵循其精神和意图的人会遵循所有规则。
其他人可能无法识别一些一级规则或大多数暗示规则。
而根据自称涉及RM的书籍所显示的情况，还有其他人员，他们积极破坏和削弱RM。他们忽略二级规则，并更糟糕的是，使用法利赛式的“逻辑”来破坏一级规则。
这里，Erwin在comp.databases.theory和TTM上为关系模型所做的努力众所周知，他把RM简化为一个简洁的规则，从而破坏了所有规则和RM本身。特别是针对您的问题，如果没有我的回应，读者会认为RM就是他所描述的：只有一个规则，即所有事物（关系和非关系）都“满足”的规则。
关系模型是免费提供的，您可以自行阅读。告诉我您需要一份副本。但要注意的是，术语已经过时，需要解释。

其次，即使将它归纳为一条规则（不可能，太简单化）或最重要的规则（可能，但有失尊严），该规则也不是它。那是四十个左右的一级规则之一，但肯定不排名靠前。

然而，我承认其他人可能会有不同的排名，以适应他们自己的目的。
理解关系模型的人们讨论的主要区别（而不是规则）是：
- 它是第一个拥有完整数学定义的（这形成了它的基础，其中一切都源于此）。
- 而前任则使用物理记录ID来关联记录，关系模型则要求（a）由数据组成的逻辑键和（b）通过这些逻辑键将行（而不是记录）相关联。

必须提到的是，这就是那些在每个文件中以“主键”声明为特征的系统的基础，这些系统完全不具备关系性，是回归到了1970年之前的ISAM记录文件系统，正是关系模型所废弃的东西。请注意，这样的原始系统可以被制造成“关系型”，因为通过分裂的“逻辑”，它们“满足”了被引用的规则。诚实的逻辑摧毁了这种无稽之谈。

这样的记录ID系统已经成为该行业低端的常态，确切地说是由于错误信息而导致的。因此，我愿意纠正它。

^{终止错误信息更正部分。}

哪种方法是最好的？

正式的数据建模，包括关系规范化。这是方法、科学和原则，而不仅仅是NF定义的碎片。

我并不认为这些提议是不同的方法，而是在一个单一的建模过程中展示了你所有的想法。当模型开始变得严谨且可行时，就到了[3.3]这个点。

它是否取决于我们如何思考数据？

当然。你的婚姻成功或失败取决于你对妻子的看法，因为这种看法是你所有行动的根源。模型的成功或失败取决于你对数据的看法。

关系模型的一大优点是，它教会我们将数据视为数据，而不只是数据的某个方面。这首先形成了逻辑键概念。

它是否取决于需求？

第一个答案是，不，它不应该取决于需求。它应该考虑到数据，其范围仅限于企业（要求是，但不是功能要求），只考虑数据本身。

当然，出于我在其他地方详细介绍的原因，数据模型应该与实际世界相匹配，而不应该局限于对数据的功能需求。

OO/ORM模型中的一个普遍错误是它只从OO/ORM模型的小镜头中理解数据。它未能区分数据与过程，并将数据视为对象的“持久化”从属。在该模型中存在许多其他错误，我不会在此列举，但要点是，它们从需求的角度出发，而忽略了数据。

其次，项目不会启动，直到需求确定，实际上资金是基于需求的。因此，成熟的项目负责人确保需求包含足够的理由来分析和建模数据，作为独立于功能的数据。

如果依赖于需求，你可以先选择最简单的设计，然后使其更通用以适应新的需求，但这样会花费大量资金。成熟的做法是尽早正确地获取数据模型。

如果数据模型与现实世界匹配，则当进行更改和添加时，很容易扩展它。相反，如果数据模型仅满足功能需求的最低要求，或者与现实世界不匹配，则更改将变得困难且代价高昂。

当然，虽然结果数据模型有很多共同之处，但初始设计可能会影响表/列的命名以及键的域不同。

如果我们选择每种事物使用一个表，我们可能会为Atom和Molecule选择不兼容的键，例如Atom重量和Molecule名称。这将是一个可怕的错误。永远不要将不符合标签的东西放入容器中。永远不要将两个不同的事物放在一个容器中（只有一个标签）。正确的方法是使用公共标识符Name（它是Atom-或Molecule-或Particle-name），并使用子类型。

如果我们选择使用通用方法，我们可能会为所有粒子选择一个公共键，但前提是它们是相同的实体，可以使用通用模型。

更改键可能对系统产生更大的影响，因此从简单设计演变为通用设计可能并不容易。好的设计思想是选择稳定（而非静态）的数据项来形成键。键设计是建模练习的一个重要方面。如果遵循关系模型，键构成数据库的逻辑结构。域非常重要，并且正确选择键很重要，对于每个表以及其所有子项。

这就带我们回到主要观点，这正是为什么必须为每个表以及其所有子项正确地建模和选择键的原因。

更新1和2

我刚刚注意到您的两个更新。这不是完整的回复，目前只是一个非常简短的回复。

到目前为止，我理解粒子是由原子集合和分子集合组成的。这就是我在D Normalised中建模的内容。它们都有一个名称和一个共同的键。它被子类型化。

但现在，根据您的层次结构图和示例数据（谢谢），我意识到我所理解的和您所理解的是两回事。请参考更新后的TRD和层次结构：

您的粒子是分子集合加上原子集合再加上亚原子粒子集合。

- 这是不正确的。 - 是的，有一种层次结构，但到目前为止，它存在于表序列中，而不是一个表内部的等级制度。 - 换句话说，这两个集合（原子，分子）是离散的，每个都有自己的组件集，它们是不同的。除了理论上的全集外，没有包括所有内容的集合。 - 更新的表格关系模型是E标准化 •更新2。子类型已被删除，以及粒子。它提供了Update 2中规定的所有要求。请注意更新后的谓词。

您的层次结构图不正确。

- 您的错误是将分类器的层次结构（结构、容器）与数据（分类器的实例；内容）相结合。您不能这样做。您需要两个单独的图表，一个用于容器，另一个用于内容。 - 这是OO / ORM思维方式的典型错误。未能遵守科学原则，分离数据与过程。在前一个问题中对Hidders的回答中详细说明的完全相同的错误。结果是复杂的对象，从未真正工作过。 - 因此，您的层次结构图是非法的，它是两个完全不同的图表合并成一个。 - F层次结构（分类）描述了，仅此而已。 - G层次结构（示例数据）说明了，仅此而已。 - 您在上一个问题的结尾有些清晰。那本有毒的书中关于“类型”的新概念已经使您完全混淆了。这个问题与类型无关。

需要更多文字，我会尽可能详细地回答。