子类型的关系数据建模
Relational data modeling for sub types
我正在学习关系模型和数据建模。
我对子类型有些困惑。
我知道数据建模是一个迭代过程，并且有许多不同的建模方法。
但是我不知道如何在不同的选项之间进行选择。
例子
假设我们要对粒子（分子、原子、质子、中子、电子...）建模。
为了简单起见，让我们忽略夸克和其他粒子。
由于同一类型的所有粒子的行为都相同，我们不打算对单个粒子建模。
换句话说，我们不会存储每个氢原子。
相反，我们将存储氢、氧和其他原子类型。
我们要建模的其实是粒子类型和它们之间的关系。
我不小心用了“type”这个词。
氢原子就是一个实例。氢是一种类型。氢也是原子的一种。
是的，涉及类型的层次结构。我们忽略了最低级别（单个粒子）。
方法
我可以想到几种方法来为它们建模。
1。每种事物（粒子类型）一个table（关系，实体）。
1.1 我想到的第一个方法
Proton (Proton)
Neutron (Neutron)
Electron (Electron)
Atom (Atom)
Atom_Proton (Atom, Proton, Quantity)
Atom_Neutron (Atom, Neutron, Quantity)
Atom_Electron (Atom, Electron, Quantity)
Molecule (Molecule)
Molecule_Atom (Molecule, Atom, Quantity)
1.2 由于只有一种proton/neutron/electron，我们可以简化一下
Atom (Atom, ProtonQuantity, NeutronQuantity, ElectronQuantity)
Molecule (Molecule)
Molecule_Atom (Molecule, Atom, Quantity)
在这个简化模型中，关于 Proton 的事实丢失了。
2。万物合一 table，关联 table 表示它们之间的关系。
2.1 每个关系一个关联table
Particle (Particle)
Atom_Proton(Particle, Particle, ProtonQuantity)
Atom_Neutron(Particle, Particle, NeutronQuantity)
Atom_Electron(Particle, Particle, ElectronQuantity)
Molecule_Atom (Particle, Particle, AtomQuantity)
2.2单联想table
Particle (Particle)
ParticleComposition (Particle, Particle, Quantity)
这种简化不会丢失任何东西。我觉得这样更好。
但是如果有特定于 Atom_Proton/Atom_Neutron/[=332 的事实=], 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,
而关于粒子组成的特殊属性则放在特殊的 tables.
中
3。使用子类型 tables.
3.1 A table 用于基本类型 Particle，以及附加的 tables 用于子类型（Atom , 分子, ...).
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_XXXQuantitytable组合起来，去掉Pronton/中子/电子.
Particle (Particle)
Atom (Particle, ProtonQuantity, NeutronQuantity, ElectronQuantity)
Molecule (Particle, other attributes)
Molecule_Atom (Particle, Particle, AtomQuantity)
它更简单，但是关于 Proton/Neutron/Electron 的信息丢失了1.2.
3.3 我们可以更改Molecule_Atom的名称，使其更通用。
Particle (Particle)
Atom (Particle, ProtonQuantity, NeutronQuantity, ElectronQuantity)
Molecule (Particle, other attributes)
ParticleComposition (Particle, Particle, Quantity)
这看起来像 2.2，子类型有额外的 tables（Atom，Molecule）。
看来2.2是3.3的特例。
3.4 我们可以结合以上所有方法得到一个通用模型。
Particle (Particle)
Proton (Particle, other attributes)
Neutron (Particle, other attributes)
Electron (Particle, other attributes)
Atom (Particle, other attributes)
Molecule (Particle, other attributes)
ParticleComposition (Particle, Particle, Quantity, other attributes)
Atom_Proton (Particle, Particle, other attributes)
Atom_Neutron (Particle, Particle, other attributes)
Atom_Electron (Particle, Particle, other attributes)
Molecule_Atom (Particle, Particle, other attributes)
好像是Atom_Proton,Atom_Neutron,Atom_Electron 和 Molecule_Atom 可以被认为是 ParticleComposition 的 子类型 .
这种方法是最复杂的一种，它包含许多 table，但每个 table 都有其作用。
问题
- 以上设计有没有违反关系模型的规则？
- 哪种方法最好？这取决于我们如何看待数据吗？这取决于要求吗？
如果要看需求的话，是不是先选择最简单的设计，然后再做通用的来适应新的需求？
尽管生成的数据模型有很多相似之处，但初始设计可能会影响 tables/columns 的 命名 ，以及 域 按键不同。
- 如果我们选择对每种类型的事物使用一个 table，我们可以为 Atom 和 Molecule[=255= 选择不兼容的键]，例如原子重量代表原子和分子名称代表分子.
- 如果我们选择使用通用方法，我们可以为所有粒子选择一个公共密钥。
更改Keys可能会对系统产生较大影响，因此从简单设计演变成通用设计可能并不容易。
你怎么看？
PS: 这可能不是一个合适的例子，解决方案可能有问题，并且可能有更多的方法变化，但你可以得到希望点。
如果您有更好的设计，请与我分享。
更新 1
要建模的数据是什么？
最初，我试图为 粒子 建模，因为
- 我认为它们之间存在子类型关系，这正是我要找的。
- 人们很容易理解它们 (?)。
- 这是人们如何理解世界的一个很好的例子。
这是我脑海中的画面。
我没有说清楚，因为我也不太清楚我要建模的是什么。
首先我认为 Atom 是 Proton/Neutron/Electron 的父级，而 Molecule 是 Atom 的父级。
然后我意识到这是关于组合，而不是关于子类型，也不是关于 Type Hierarchy。
类型
一段时间以来一直在思考类型，还有分组和分类。
引用自“SQL 和关系理论”：
So what is a type, exactly? In essence, it’s a named, finite set of values ─ all possible values of some specific kind: for example, all possible integers, or all possible character strings, or all possible supplier numbers, or all possible XML documents, or all possible relations with a certain heading (and so on).
人们创造了名称 "Integer" 来表示整数 值 的集合。
实际上，人们创造了概念和名称来识别事物，将事物分组以便我们可以 understand/model 世界。
质子是一组实质子，氢是一组氢原子，依此类推。
从这个意义上说，真正的粒子处于类型层次结构的最低层。
一开始我试图模拟所有的粒子，但后来我被卡住了，因为
- 我想不出一个合适的键来识别每个真实的粒子；
- 它们太多了，无法存储在数据库中。
所以我决定忽略真实粒子并改为对类型建模。
当我们说"a molecule is composed of atoms"时，表示"a real H2O molecule is composed of two real Hydrogen atoms and one Oxygen atom"，也表示"any (type of) molecule is composed of (some types of) atoms"。
我们可以只陈述粒子类型的事实，而不是陈述关于真实粒子的每一个事实。
这就是我们通过对事物进行分组和创造名称（类型）而获得的好处。
粒子类型层次结构
层次结构可以转换为集合定义。
二级-真实粒子以上类型：
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 ...
但是，集合是关系，元素是元组，因此如果关系中的元组不兼容，并集将不起作用。
使用子类型 table 的方法解决了问题并对子集关系建模。
但在子类型化方法中，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 }
表示Particle是Atom类型，Atom是Hydrogen类型
这样，粒子之间的关系就可以在高层次上表现出来。
新数据模型
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 |
为了比较，这是子类型 table 方法的示例数据。
Particle
| ParticleId | ParticleName |
|------------+----------------|
| H | Hydrogen |
| He | Helium |
| Li | Lithium |
| Be | Beryllium |
| H2O | Water |
| O2 | Oxygen |
| CO2 | Carbon Dioxide |
Molecule
| MoleculeId | some_attribute |
|------------+----------------|
| H2O | ... |
| O2 | ... |
| CO2 | ... |
Atom
| AtomId | ProtonQuantity | NeutronQuantity | ElectronQuantity |
|--------+----------------+-----------------+------------------|
| H | 1 | 0 | 1 |
| He | 2 | 2 | 2 |
| Li | 3 | 4 | 3 |
| Be | 4 | 5 | 4 |
ParticleComposition
| ParticleId | ComponentId | Quantity |
|------------+-------------+----------|
| H2O | H | 2 |
| H2O | O | 1 |
| CO2 | C | 1 |
| CO2 | O | 2 |
| O2 | O | 2 |
亚原子
这些粒子类型是由人们定义的，人们不断定义新概念来模拟现实的新方面。
我们可以定义 "sub-atom" 层次结构如下所示：
方法 4 可以更轻松地适应这种类型层次结构的变化。
更新 2
要记录的事实
- 世界上有不同类型的粒子：质子、中子、电子、原子、分子。
- 原子由质子、中子和电子组成。
- 分子是由原子组成的。
- 有许多不同类型的原子：氢、氧、....
- 有许多不同类型的分子：H2O、O2、....
- 一个氢原子由一个质子和一个电子组成； ...
- 一个H2O分子是由两个氢原子和一个氧原子组成的； ...
- 不同类型的粒子可能具有特殊的属性，例如原子有原子量等
- ...
我喜欢 Fowler 对 Class Table 继承和单一 Table 继承的处理。您已经在此处触及了这两种设计。它们中的每一个都有其用途和缺点。您可以将这些用作搜索词，您将获得大量阅读。其中一些是值得的。在 SO 中甚至还有几个带有这些名称的标签。
今天我不确定，但是大约 20 年前数据库 101 课程中经常省略子类型，这是每个数据库构建者 运行 一进入 "the real world"。
归根结底，数据的关系模型只有一个 "rule" : 数据库中的所有信息都必须表示为关系中元组中的属性值。
您的所有 "alternatives" 都可能符合该规则，前提是：
- 每个属性都有关联的数据类型，
- 并且数据库中每个关系中的每个元组的每个属性总是有一个值，
- 该值是与该属性关联的数据类型的成员。
编辑：您也未能提供任何详细信息，说明您想在系统中记录的事实的确切性质。
编辑 2：Walter M. 的第一条评论仍然适用。你的事实似乎在不同的层次上陈述了事情（在典型的用例中会明显不同）：
"6.一个氢原子由一个质子和一个电子组成"
经过小的重写以消除其中的 'AND' :
"6. 原子包含 "
这个看起来像是可以进入你的数据库的东西（如果你的用例是 typical/mundane 可以假设的）：
一个'H'原子包含1个质子
一个'H'原子包含1个电子
一个'H'原子含有1个中子
（请注意如何消除 'AND' 涉及将连词拆分为 "atomic" 部分（双关语）。）
从这一点开始，我们可以开始考虑如何处理 。如果您的用例是 proton/neutron/electron 的存在只是给定的，并且它永远不会改变，那么您可以简单地为它使用一个数据类型，并且对其建模只涉及识别类型，以便您的模型的读者将知道预期的值集。但是，如果您的用例是这样的，比如说，您正在尝试寻找一种全新的化学模型，其中也可能有 foobarons 和质子 [或者为了实验可以再次删除它们的存在]，那么你必须包括一个 table ，上面写着“ is part of my model of atoms”。
此外，您还必须在您的模型中包含一条规则，即任何声称是原子一部分的 必须确实是您的原子模型的一部分。在 SQLspeak 中：您需要从 ATOM_CONTAINS_PARTICLE table 到 EXISTING_PARTICLES table.
的外键
从某种意义上说，这个规则的声明就像你的
"2.原子由质子、中子和电子组成。"
但请注意，您自己的数据库中不会有 table 表示此类内容。相反，通过向系统声明 FK，将在 catalog.
中进行此特定声明
您需要正确区分直接陈述事物的陈述类型属于感兴趣的领域（最终是entities/classes/.. . 在你的概念模型中，很可能 tables 在你的数据库中）和陈述事物的陈述类型 关于 感兴趣的领域（比如你的 FK 规则）。
（在领域本身高度抽象的用例中，两者之间的界限可能非常细，甚至不存在。）
初步
好问题，对于一个学习者来说很周到。我认为您真正想要的是讨论，以获得清晰度，这是一个数据建模练习。
我了解您在 3.3 之前的进度。什么，如何获得 3.4（在 step-wise 升级到 3.3 之后）？对我来说，结合以上所有不等于通用。
与其跟随你的进展，为每一步建立一个模型，不如让我根据你的讨论用一个相关步骤的 TRD 来回应。
TRD只有Tables，通过Keys来标识，Relationships现阶段是相关的，我想你很清楚属性（如果有）以及它们将与哪些密钥一起部署。达到 stable TRD 后，就可以将其扩展为完整 DM。
建立模型后，它比上一个模型更进一步，并且经过评估，如果很明显它丢失了信息，则可以安全地丢弃它。有一个值正在考虑这样的模型，所以步骤是不正确的。但继续讨论它是一种浪费。我相信我在上一个问题中证明了这一点。
考虑这套 Table Relation Diagrams。
1.x
在我看来，A First 将是第一个值得思考的合理 TRD。
我不明白 Proton/Neutron/Electron 如何或为什么是独立的 table。它们不是独立存在的，它们的重量；等是固定的。它们仅存在于 Atom 的上下文中。
由于每个Atom至少包含一个Proton/Neutron/Electron，所以Proton/Neutron/Electron列可以部署在Atom中。未绘制。稍后.
2.x
除了一个明显的错误外，你的进度很好。
common attributes about particle composition go in ParticleComposition,
while special attributes about particle composition go in special tables.
没有。粒子的通用属性在 Particle 中。特定于关系（即不常见）的属性进入 ParticleComposition。然后就没有"special attributes about particle composition"，没有"special tables".
3.x
考虑 B 子类型。您的 [3.1] 大部分是正确的，除了：
没看出Particle怎么会有children比如Proton/Neutron/Electron。只有 Atom 才有。
我不明白粒子与其他粒子之间的关系（即那是什么？）。对于讨论的数据，分子由原子组成；一个Atom由Proton/Neutron/Electron组成；并且粒子是分子 x 或原子（独占子类型）。
如有不妥请指正
有关该主题的完整详细信息，请参阅 Subtype Document。
正如您所说，可以 C 降低 。这认为 Proton/Neutron/Electron 信息在每个 Atom 中是固定的：每个 Atom 都有一个条目。例如。每个shell/energy级不区分；零是中子的acceptable（而不是Null）。
- 我之前已经讨论过谓词的巨大价值。这里的要点是，模型识别谓词。 Predicates 验证模型；这是一个很好的反馈循环。我给出了Predicates，你可以自己评估一下，检查模型的有效性。
3.3
如果完全 D 归一化：原子总是至少有一个质子条目； Neutron 条目是可选的；每个 Shell/energy 级别都是有区别的。
注意谓词的区别。
请注意，虽然 Reduction 是一种有效的技术，但它并不等同于 Normalisation.
3.4
这似乎是所有事物的总和，平面布局或平面视图（派生关系、透视图、结果集）。这样就好了，理解一下。但是，如果您建议将其作为一组 table，那么由于各种规范化错误，它是非常不正确的。其中，如果更正，将进步到 [3.3] 和我的 [D Normalised]。
问题
Does any of the above designs break the rules of Relational Model?
除 [3.3] 外，所有这些都违反了一些规则。它们大多属于规范化错误类别。如果您要提供完整模型或 CREATE TABLE 语句，则会出现相关的识别错误。
但是，如果上下文是数据建模练习，那没关系，为了理解。如果这个练习是认真的，那么上面的段落就成立了。
本部分是根据 SO 指南提供的，具体而言：看到错误信息时请更正。我确实对主题 post 发表了评论，但它们一直在消失。所以我把它放在这里了。
Erwin Smout:
When cut down to its bare essence, the relational model of data has no more than exactly one "rule" : all information in the database must be represented as values of attributes in tuples in relations.
这是规则之一，是的，但附文显然是错误的。
首先，关系模型中有许多基本的或first-order规则。根据记忆，我会说大约四十岁。
其次，有许多second-order规则，这些规则在逻辑上被first-order规则所暗示。
有技术资质和经验的人，能理解RM，有精神和意图的人，一律遵从。
其他人可能无法识别某些 first-order 规则，或大部分隐含规则。
而且，正如书中所证明的那样，声称与 RM 有关，还有一些人积极颠覆和削弱 RM。他们无视 second-order 规则，更糟糕的是，他们使用骗子 "logic" 来破坏 first-order 规则。
在这里，Erwin，well-known 为 comp.databases.theory 和 TTM 上的 RM 所做的努力，减少了 RM 成为一个精辟的规则，从而破坏了整套规则，以及 RM 本身。特别是在回答你的问题时，如果不是我的回答，会让读者相信 RM 就是他所说的：只有一个规则，即一切，关系为以及 non-relation、"satisfies".
关系模型免费提供，您可以自己阅读。如果您想要一份副本，请告诉我。需要注意的是，术语是 out-dated，需要解释一下。
其次，即使将其归结为一条规则（不可能，过于简化）或最重要的规则（可能，但贬低），那条规则也不是。那是大约四十条 first-order 规则之一，但肯定不是排名靠前的。
但是，我同意其他人可能有不同的排名，以适应他们自己的目的。
了解RM的人讨论什么，作为[=之间的主要区别（不是规则） =182=]RM及其前身，是这样的：
它是第一个拥有完整数学定义的人（它构成了它的基础，其中的一切都源于它）。
虽然前辈使用物理记录 ID 关联记录，但 RM 要求 (a) 由数据组成的逻辑键，以及 (b) 相关那些逻辑键的行（不是记录）。
必须提到的是，这是在每个文件中以记录 ID 为特征的系统的基础，声明为 "primary key"，完全是 non-relational，回归到 pre- 1970 ISAM 记录归档系统，正是 RM 淘汰的东西。还要注意，如何使这些原始系统出现 "relational"，因为根据精神分裂症 "logic"，它们 "satisfy" 引用了一条规则。诚实的逻辑摧毁这种废话。
正是由于错误信息，此类基于记录 ID 的系统已成为行业低端的规范。因此我愿意更正它。
错误信息修正部分结束。
Which approach is the best?
正式数据建模，包括关系规范化。方法，科学，原则，而不是NF定义的碎片。
我不认为这些建议是不同的方法，而是将所有您的想法放在一个单一的建模练习中。模型开始变得严肃、可行的点是 [3.3]。
Does it depend on how we think about the data?
当然可以。你的婚姻成败取决于你对妻子的看法，因为这种看法是你所有行动的基础。该模型将根据您对数据的看法成功或失败。
关系模型 的一大优点是它教会我们如何查看（感知、思考、建模）数据，将其视为数据，且仅是数据。一方面，这形成了逻辑键概念。
Does it depend on the requirements?
第一个答案是，不应该，这不应该取决于需求。应该考虑数据，范围仅限于企业（requirement, yes, but not the functional requirement），而且只有数据。
当然，出于我在别处详述的原因，数据模型应该与现实世界相匹配，不应受限于数据的功能需求。
OO/ORM 模型失败的常见原因是它从 OO/ORM 模型的小镜头中感知数据。它无法将数据与流程分开，并且将数据仅视为 "persistence" objects 的奴隶。那个模型还有很多其他的错误，这里就不一一列举了，重点是从需求的位置出发，忽略数据
第二个答案是，项目只有在需求确定后才会被委托，如果资金充足，这就是现实 requirement-based。因此，成熟的项目负责人确保需求包含足够的理由来分析和建模数据，作为数据，与功能分开。
If it depends on the requirements, shall we choose the simplest design at first and then make it more generic to accommodate new requirements?
你可以，但那会花费很多。成熟的顺序是尽早把数据模型弄好。
如果数据模型与现实世界相匹配，当出现变化和添加时，很容易扩展。相反，如果数据模型是功能需求的最低限度，或者如果它与现实世界不匹配，那么更改将很困难且代价高昂。
Although the resulting data models share a lot of similarities, the initial design may influence the naming of the tables/columns, and the domains of the keys are different.
当然可以。
If we choose to use one table for each type of things, we could choose incompatible keys for Atom and Molecule, such as atom weight for Atom and molecule name for Molecule.
那将是一个可怕的错误。切勿将与标签不符的物品放入容器中。切勿将两种不同的东西放在一个容器（具有一个标签）中。正确的方法是使用通用标识符名称（Atom- 或 Molecule- 或 Particle-name），并使用子类型。
If we choose to use the generic approach, we may choose a common key for all particles.
只有有一个。如果没有，则表明实体不相同，无法使用通用模型。
Changing Keys may have greater impact on the system, so it may not be easy to evolve from a simple design to a generic one.
嗯，想法是选择 stable（非静态）的数据项来形成密钥。是的，关键设计是建模练习的一个重要方面。如果您遵循关系模型，键构成了数据库的逻辑结构。域非常重要（我想你意识到了这一点）。是的，改变成本很高。
这让我们回到了重点。这正是为什么必须为每个 table 及其所有 children.
正确建模和选择键的原因更新 1 和 2
我刚刚注意到你的两个更新。这不是完整的回复，目前只是一个非常简短的回复。
- 到目前为止，我把粒子理解为原子的集合加上分子的集合。这就是我在 D Normalised 中建模的内容。两者都有一个名称，一个公共密钥。它是子类型的。
但是现在，根据您的层次结构图和示例数据（谢谢），我意识到我认为您的意思和您的意思是两回事。考虑 Updated TRD & Hierarchy:
你的粒子是分子集加上原子集加上亚原子粒子集。
不正确
有一个层次结构，是的，但是到目前为止，它存在于 table 的序列中，而不是一个 table.[=24= 中的层次结构]
换句话说，两组（原子，分子）是离散的，每个都有自己的一组组件，这些组件是不同的。没有包含一切的集合（除了理论上的通用集合）。
更新后的 Table 关系模型是 E 规范化 • 更新 2。子类型与粒子一起被删除。它提供更新 2 中规定的所有要求。请注意更新的谓词。
您的层次结构图不正确。
您的错误是您将分类器的层次结构（结构、容器）与数据（分类器的实例；内容）组合在一起。你不能那样做。您需要两张单独的图表，一张用于容器，另一张用于内容。
这是OO/ORM心态的典型错误。未能遵守 将数据与过程分开 的科学原则。在上一个问题中我对 Hidders 的回应中详述了完全相同的错误。结果很复杂 objects，从未真正起作用。
所以你的层次图是非法的，它是两个完全不同的图组合成一个。
F 层次结构（分类） 描述了这一点，并且仅描述了这一点。
G 层次结构（示例数据） 说明了这一点，并且仅说明了这一点。
您描述层次结构（组织结构图）的方式与我描述它们的方式（资源管理器）在风格上有所不同。一个最终变得非常宽，另一个更紧凑。我想你能想出来
你在上一个问题的最后已经说清楚了。毒书里的Type这个新奇的概念，把你搞糊涂了。这个问题，这些问题，与Type无关。
需要多说几句，时间允许我会回复的更全面。
我正在学习关系模型和数据建模。
我对子类型有些困惑。
我知道数据建模是一个迭代过程，并且有许多不同的建模方法。
但是我不知道如何在不同的选项之间进行选择。
例子
假设我们要对粒子（分子、原子、质子、中子、电子...）建模。
为了简单起见，让我们忽略夸克和其他粒子。
由于同一类型的所有粒子的行为都相同，我们不打算对单个粒子建模。
换句话说，我们不会存储每个氢原子。
相反，我们将存储氢、氧和其他原子类型。
我们要建模的其实是粒子类型和它们之间的关系。
我不小心用了“type”这个词。
氢原子就是一个实例。氢是一种类型。氢也是原子的一种。
是的，涉及类型的层次结构。我们忽略了最低级别（单个粒子）。
方法
我可以想到几种方法来为它们建模。
1。每种事物（粒子类型）一个table（关系，实体）。
1.1 我想到的第一个方法
Proton (Proton)
Neutron (Neutron)
Electron (Electron)Atom (Atom)
Atom_Proton (Atom, Proton, Quantity)
Atom_Neutron (Atom, Neutron, Quantity)
Atom_Electron (Atom, Electron, Quantity)Molecule (Molecule)
Molecule_Atom (Molecule, Atom, Quantity)
1.2 由于只有一种proton/neutron/electron，我们可以简化一下
Atom (Atom, ProtonQuantity, NeutronQuantity, ElectronQuantity)
Molecule (Molecule)
Molecule_Atom (Molecule, Atom, Quantity)
在这个简化模型中，关于 Proton 的事实丢失了。
2。万物合一 table，关联 table 表示它们之间的关系。
2.1 每个关系一个关联table
Particle (Particle)
Atom_Proton(Particle, Particle, ProtonQuantity)
Atom_Neutron(Particle, Particle, NeutronQuantity)
Atom_Electron(Particle, Particle, ElectronQuantity)
Molecule_Atom (Particle, Particle, AtomQuantity)
2.2单联想table
Particle (Particle)
ParticleComposition (Particle, Particle, Quantity)
这种简化不会丢失任何东西。我觉得这样更好。
但是如果有特定于 Atom_Proton/Atom_Neutron/[=332 的事实=], 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,
而关于粒子组成的特殊属性则放在特殊的 tables.
3。使用子类型 tables.
3.1 A table 用于基本类型 Particle，以及附加的 tables 用于子类型（Atom , 分子, ...).
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_XXXQuantitytable组合起来，去掉Pronton/中子/电子.
Particle (Particle)
Atom (Particle, ProtonQuantity, NeutronQuantity, ElectronQuantity)
Molecule (Particle, other attributes)Molecule_Atom (Particle, Particle, AtomQuantity)
它更简单，但是关于 Proton/Neutron/Electron 的信息丢失了1.2.
3.3 我们可以更改Molecule_Atom的名称，使其更通用。
Particle (Particle)
Atom (Particle, ProtonQuantity, NeutronQuantity, ElectronQuantity)
Molecule (Particle, other attributes)ParticleComposition (Particle, Particle, Quantity)
这看起来像 2.2，子类型有额外的 tables（Atom，Molecule）。
看来2.2是3.3的特例。
3.4 我们可以结合以上所有方法得到一个通用模型。
Particle (Particle)
Proton (Particle, other attributes)
Neutron (Particle, other attributes)
Electron (Particle, other attributes)
Atom (Particle, other attributes)
Molecule (Particle, other attributes)ParticleComposition (Particle, Particle, Quantity, other attributes)
Atom_Proton (Particle, Particle, other attributes)
Atom_Neutron (Particle, Particle, other attributes)
Atom_Electron (Particle, Particle, other attributes)
Molecule_Atom (Particle, Particle, other attributes)
好像是Atom_Proton,Atom_Neutron,Atom_Electron 和 Molecule_Atom 可以被认为是 ParticleComposition 的 子类型 .
这种方法是最复杂的一种，它包含许多 table，但每个 table 都有其作用。
问题
- 以上设计有没有违反关系模型的规则？
- 哪种方法最好？这取决于我们如何看待数据吗？这取决于要求吗？
如果要看需求的话，是不是先选择最简单的设计，然后再做通用的来适应新的需求？
尽管生成的数据模型有很多相似之处，但初始设计可能会影响 tables/columns 的 命名 ，以及 域 按键不同。- 如果我们选择对每种类型的事物使用一个 table，我们可以为 Atom 和 Molecule[=255= 选择不兼容的键]，例如原子重量代表原子和分子名称代表分子.
- 如果我们选择使用通用方法，我们可以为所有粒子选择一个公共密钥。
更改Keys可能会对系统产生较大影响，因此从简单设计演变成通用设计可能并不容易。
你怎么看？
PS: 这可能不是一个合适的例子，解决方案可能有问题，并且可能有更多的方法变化，但你可以得到希望点。
如果您有更好的设计，请与我分享。
更新 1
要建模的数据是什么？
最初，我试图为 粒子 建模，因为
- 我认为它们之间存在子类型关系，这正是我要找的。
- 人们很容易理解它们 (?)。
- 这是人们如何理解世界的一个很好的例子。
这是我脑海中的画面。
我没有说清楚，因为我也不太清楚我要建模的是什么。
首先我认为 Atom 是 Proton/Neutron/Electron 的父级，而 Molecule 是 Atom 的父级。
然后我意识到这是关于组合，而不是关于子类型，也不是关于 Type Hierarchy。
类型
一段时间以来一直在思考类型，还有分组和分类。
引用自“SQL 和关系理论”：
So what is a type, exactly? In essence, it’s a named, finite set of values ─ all possible values of some specific kind: for example, all possible integers, or all possible character strings, or all possible supplier numbers, or all possible XML documents, or all possible relations with a certain heading (and so on).
人们创造了名称 "Integer" 来表示整数 值 的集合。
实际上，人们创造了概念和名称来识别事物，将事物分组以便我们可以 understand/model 世界。
质子是一组实质子，氢是一组氢原子，依此类推。
从这个意义上说，真正的粒子处于类型层次结构的最低层。
一开始我试图模拟所有的粒子，但后来我被卡住了，因为
- 我想不出一个合适的键来识别每个真实的粒子；
- 它们太多了，无法存储在数据库中。
所以我决定忽略真实粒子并改为对类型建模。
当我们说"a molecule is composed of atoms"时，表示"a real H2O molecule is composed of two real Hydrogen atoms and one Oxygen atom"，也表示"any (type of) molecule is composed of (some types of) atoms"。
我们可以只陈述粒子类型的事实，而不是陈述关于真实粒子的每一个事实。
这就是我们通过对事物进行分组和创造名称（类型）而获得的好处。
粒子类型层次结构
层次结构可以转换为集合定义。
二级-真实粒子以上类型：
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 ...
但是，集合是关系，元素是元组，因此如果关系中的元组不兼容，并集将不起作用。
使用子类型 table 的方法解决了问题并对子集关系建模。
但在子类型化方法中，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 }
表示Particle是Atom类型，Atom是Hydrogen类型
这样，粒子之间的关系就可以在高层次上表现出来。
新数据模型
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 |
为了比较，这是子类型 table 方法的示例数据。
Particle | ParticleId | ParticleName | |------------+----------------| | H | Hydrogen | | He | Helium | | Li | Lithium | | Be | Beryllium | | H2O | Water | | O2 | Oxygen | | CO2 | Carbon Dioxide | Molecule | MoleculeId | some_attribute | |------------+----------------| | H2O | ... | | O2 | ... | | CO2 | ... | Atom | AtomId | ProtonQuantity | NeutronQuantity | ElectronQuantity | |--------+----------------+-----------------+------------------| | H | 1 | 0 | 1 | | He | 2 | 2 | 2 | | Li | 3 | 4 | 3 | | Be | 4 | 5 | 4 | ParticleComposition | ParticleId | ComponentId | Quantity | |------------+-------------+----------| | H2O | H | 2 | | H2O | O | 1 | | CO2 | C | 1 | | CO2 | O | 2 | | O2 | O | 2 |
亚原子
这些粒子类型是由人们定义的，人们不断定义新概念来模拟现实的新方面。
我们可以定义 "sub-atom" 层次结构如下所示：
方法 4 可以更轻松地适应这种类型层次结构的变化。
更新 2
要记录的事实
- 世界上有不同类型的粒子：质子、中子、电子、原子、分子。
- 原子由质子、中子和电子组成。
- 分子是由原子组成的。
- 有许多不同类型的原子：氢、氧、....
- 有许多不同类型的分子：H2O、O2、....
- 一个氢原子由一个质子和一个电子组成； ...
- 一个H2O分子是由两个氢原子和一个氧原子组成的； ...
- 不同类型的粒子可能具有特殊的属性，例如原子有原子量等
- ...
我喜欢 Fowler 对 Class Table 继承和单一 Table 继承的处理。您已经在此处触及了这两种设计。它们中的每一个都有其用途和缺点。您可以将这些用作搜索词，您将获得大量阅读。其中一些是值得的。在 SO 中甚至还有几个带有这些名称的标签。
今天我不确定，但是大约 20 年前数据库 101 课程中经常省略子类型，这是每个数据库构建者 运行 一进入 "the real world"。
归根结底，数据的关系模型只有一个 "rule" : 数据库中的所有信息都必须表示为关系中元组中的属性值。
您的所有 "alternatives" 都可能符合该规则，前提是：
- 每个属性都有关联的数据类型，
- 并且数据库中每个关系中的每个元组的每个属性总是有一个值，
- 该值是与该属性关联的数据类型的成员。
编辑：您也未能提供任何详细信息，说明您想在系统中记录的事实的确切性质。
编辑 2：Walter M. 的第一条评论仍然适用。你的事实似乎在不同的层次上陈述了事情（在典型的用例中会明显不同）：
"6.一个氢原子由一个质子和一个电子组成"
经过小的重写以消除其中的 'AND' :
"6.
这个看起来像是可以进入你的数据库的东西（如果你的用例是 typical/mundane 可以假设的）：
一个'H'原子包含1个质子
一个'H'原子包含1个电子
一个'H'原子含有1个中子
（请注意如何消除 'AND' 涉及将连词拆分为 "atomic" 部分（双关语）。）
从这一点开始，我们可以开始考虑如何处理
此外，您还必须在您的模型中包含一条规则，即任何声称是原子一部分的
从某种意义上说，这个规则的声明就像你的
"2.原子由质子、中子和电子组成。"
但请注意，您自己的数据库中不会有 table 表示此类内容。相反，通过向系统声明 FK，将在 catalog.
中进行此特定声明您需要正确区分直接陈述事物的陈述类型属于感兴趣的领域（最终是entities/classes/.. . 在你的概念模型中，很可能 tables 在你的数据库中）和陈述事物的陈述类型 关于 感兴趣的领域（比如你的 FK 规则）。
（在领域本身高度抽象的用例中，两者之间的界限可能非常细，甚至不存在。）
初步
好问题，对于一个学习者来说很周到。我认为您真正想要的是讨论，以获得清晰度，这是一个数据建模练习。
我了解您在 3.3 之前的进度。什么，如何获得 3.4（在 step-wise 升级到 3.3 之后）？对我来说，结合以上所有不等于通用。
与其跟随你的进展，为每一步建立一个模型，不如让我根据你的讨论用一个相关步骤的 TRD 来回应。
TRD只有Tables，通过Keys来标识，Relationships现阶段是相关的，我想你很清楚属性（如果有）以及它们将与哪些密钥一起部署。达到 stable TRD 后，就可以将其扩展为完整 DM。
建立模型后，它比上一个模型更进一步，并且经过评估，如果很明显它丢失了信息，则可以安全地丢弃它。有一个值正在考虑这样的模型，所以步骤是不正确的。但继续讨论它是一种浪费。我相信我在上一个问题中证明了这一点。
考虑这套 Table Relation Diagrams。
1.x
在我看来，A First 将是第一个值得思考的合理 TRD。
我不明白 Proton/Neutron/Electron 如何或为什么是独立的 table。它们不是独立存在的，它们的重量；等是固定的。它们仅存在于 Atom 的上下文中。
由于每个Atom至少包含一个Proton/Neutron/Electron，所以Proton/Neutron/Electron列可以部署在Atom中。未绘制。稍后.
2.x
除了一个明显的错误外，你的进度很好。
common attributes about particle composition go in ParticleComposition, while special attributes about particle composition go in special tables.
没有。粒子的通用属性在 Particle 中。特定于关系（即不常见）的属性进入 ParticleComposition。然后就没有"special attributes about particle composition"，没有"special tables".
3.x
考虑 B 子类型。您的 [3.1] 大部分是正确的，除了：
没看出Particle怎么会有children比如Proton/Neutron/Electron。只有 Atom 才有。
我不明白粒子与其他粒子之间的关系（即那是什么？）。对于讨论的数据，分子由原子组成；一个Atom由Proton/Neutron/Electron组成；并且粒子是分子 x 或原子（独占子类型）。
如有不妥请指正
有关该主题的完整详细信息，请参阅 Subtype Document。
正如您所说，可以 C 降低 。这认为 Proton/Neutron/Electron 信息在每个 Atom 中是固定的：每个 Atom 都有一个条目。例如。每个shell/energy级不区分；零是中子的acceptable（而不是Null）。
- 我之前已经讨论过谓词的巨大价值。这里的要点是，模型识别谓词。 Predicates 验证模型；这是一个很好的反馈循环。我给出了Predicates，你可以自己评估一下，检查模型的有效性。
3.3
如果完全 D 归一化：原子总是至少有一个质子条目； Neutron 条目是可选的；每个 Shell/energy 级别都是有区别的。
注意谓词的区别。
请注意，虽然 Reduction 是一种有效的技术，但它并不等同于 Normalisation.
3.4
这似乎是所有事物的总和，平面布局或平面视图（派生关系、透视图、结果集）。这样就好了，理解一下。但是，如果您建议将其作为一组 table，那么由于各种规范化错误，它是非常不正确的。其中，如果更正，将进步到 [3.3] 和我的 [D Normalised]。
问题
Does any of the above designs break the rules of Relational Model?
除 [3.3] 外，所有这些都违反了一些规则。它们大多属于规范化错误类别。如果您要提供完整模型或 CREATE TABLE 语句，则会出现相关的识别错误。
但是，如果上下文是数据建模练习，那没关系，为了理解。如果这个练习是认真的，那么上面的段落就成立了。
本部分是根据 SO 指南提供的，具体而言：看到错误信息时请更正。我确实对主题 post 发表了评论，但它们一直在消失。所以我把它放在这里了。
Erwin Smout:
When cut down to its bare essence, the relational model of data has no more than exactly one "rule" : all information in the database must be represented as values of attributes in tuples in relations.
这是规则之一，是的，但附文显然是错误的。
首先，关系模型中有许多基本的或first-order规则。根据记忆，我会说大约四十岁。
其次，有许多second-order规则，这些规则在逻辑上被first-order规则所暗示。
有技术资质和经验的人，能理解RM，有精神和意图的人，一律遵从。
其他人可能无法识别某些 first-order 规则，或大部分隐含规则。
而且，正如书中所证明的那样，声称与 RM 有关，还有一些人积极颠覆和削弱 RM。他们无视 second-order 规则，更糟糕的是，他们使用骗子 "logic" 来破坏 first-order 规则。
在这里，Erwin，well-known 为 comp.databases.theory 和 TTM 上的 RM 所做的努力，减少了 RM 成为一个精辟的规则，从而破坏了整套规则，以及 RM 本身。特别是在回答你的问题时，如果不是我的回答，会让读者相信 RM 就是他所说的：只有一个规则，即一切，关系为以及 non-relation、"satisfies".
关系模型免费提供，您可以自己阅读。如果您想要一份副本，请告诉我。需要注意的是，术语是 out-dated，需要解释一下。
其次，即使将其归结为一条规则（不可能，过于简化）或最重要的规则（可能，但贬低），那条规则也不是。那是大约四十条 first-order 规则之一，但肯定不是排名靠前的。
但是，我同意其他人可能有不同的排名，以适应他们自己的目的。
了解RM的人讨论什么，作为[=之间的主要区别（不是规则） =182=]RM及其前身，是这样的：
它是第一个拥有完整数学定义的人（它构成了它的基础，其中的一切都源于它）。
虽然前辈使用物理记录 ID 关联记录，但 RM 要求 (a) 由数据组成的逻辑键，以及 (b) 相关那些逻辑键的行（不是记录）。
必须提到的是，这是在每个文件中以记录 ID 为特征的系统的基础，声明为 "primary key"，完全是 non-relational，回归到 pre- 1970 ISAM 记录归档系统，正是 RM 淘汰的东西。还要注意，如何使这些原始系统出现 "relational"，因为根据精神分裂症 "logic"，它们 "satisfy" 引用了一条规则。诚实的逻辑摧毁这种废话。
正是由于错误信息，此类基于记录 ID 的系统已成为行业低端的规范。因此我愿意更正它。
错误信息修正部分结束。
Which approach is the best?
正式数据建模，包括关系规范化。方法，科学，原则，而不是NF定义的碎片。
我不认为这些建议是不同的方法，而是将所有您的想法放在一个单一的建模练习中。模型开始变得严肃、可行的点是 [3.3]。
Does it depend on how we think about the data?
当然可以。你的婚姻成败取决于你对妻子的看法，因为这种看法是你所有行动的基础。该模型将根据您对数据的看法成功或失败。
关系模型 的一大优点是它教会我们如何查看（感知、思考、建模）数据，将其视为数据，且仅是数据。一方面，这形成了逻辑键概念。
Does it depend on the requirements?
第一个答案是，不应该，这不应该取决于需求。应该考虑数据，范围仅限于企业（requirement, yes, but not the functional requirement），而且只有数据。
当然，出于我在别处详述的原因，数据模型应该与现实世界相匹配，不应受限于数据的功能需求。
OO/ORM 模型失败的常见原因是它从 OO/ORM 模型的小镜头中感知数据。它无法将数据与流程分开，并且将数据仅视为 "persistence" objects 的奴隶。那个模型还有很多其他的错误，这里就不一一列举了，重点是从需求的位置出发，忽略数据
第二个答案是，项目只有在需求确定后才会被委托，如果资金充足，这就是现实 requirement-based。因此，成熟的项目负责人确保需求包含足够的理由来分析和建模数据，作为数据，与功能分开。
If it depends on the requirements, shall we choose the simplest design at first and then make it more generic to accommodate new requirements?
你可以，但那会花费很多。成熟的顺序是尽早把数据模型弄好。
如果数据模型与现实世界相匹配，当出现变化和添加时，很容易扩展。相反，如果数据模型是功能需求的最低限度，或者如果它与现实世界不匹配，那么更改将很困难且代价高昂。
Although the resulting data models share a lot of similarities, the initial design may influence the naming of the tables/columns, and the domains of the keys are different.
当然可以。
If we choose to use one table for each type of things, we could choose incompatible keys for Atom and Molecule, such as atom weight for Atom and molecule name for Molecule.
那将是一个可怕的错误。切勿将与标签不符的物品放入容器中。切勿将两种不同的东西放在一个容器（具有一个标签）中。正确的方法是使用通用标识符名称（Atom- 或 Molecule- 或 Particle-name），并使用子类型。
If we choose to use the generic approach, we may choose a common key for all particles.
只有有一个。如果没有，则表明实体不相同，无法使用通用模型。
Changing Keys may have greater impact on the system, so it may not be easy to evolve from a simple design to a generic one.
嗯，想法是选择 stable（非静态）的数据项来形成密钥。是的，关键设计是建模练习的一个重要方面。如果您遵循关系模型，键构成了数据库的逻辑结构。域非常重要（我想你意识到了这一点）。是的，改变成本很高。
这让我们回到了重点。这正是为什么必须为每个 table 及其所有 children.
正确建模和选择键的原因更新 1 和 2
我刚刚注意到你的两个更新。这不是完整的回复，目前只是一个非常简短的回复。
- 到目前为止，我把粒子理解为原子的集合加上分子的集合。这就是我在 D Normalised 中建模的内容。两者都有一个名称，一个公共密钥。它是子类型的。
但是现在，根据您的层次结构图和示例数据（谢谢），我意识到我认为您的意思和您的意思是两回事。考虑 Updated TRD & Hierarchy:
你的粒子是分子集加上原子集加上亚原子粒子集。
不正确
有一个层次结构，是的，但是到目前为止，它存在于 table 的序列中，而不是一个 table.[=24= 中的层次结构]
换句话说，两组（原子，分子）是离散的，每个都有自己的一组组件，这些组件是不同的。没有包含一切的集合（除了理论上的通用集合）。
更新后的 Table 关系模型是 E 规范化 • 更新 2。子类型与粒子一起被删除。它提供更新 2 中规定的所有要求。请注意更新的谓词。
您的层次结构图不正确。
您的错误是您将分类器的层次结构（结构、容器）与数据（分类器的实例；内容）组合在一起。你不能那样做。您需要两张单独的图表，一张用于容器，另一张用于内容。
这是OO/ORM心态的典型错误。未能遵守 将数据与过程分开 的科学原则。在上一个问题中我对 Hidders 的回应中详述了完全相同的错误。结果很复杂 objects，从未真正起作用。
所以你的层次图是非法的，它是两个完全不同的图组合成一个。
F 层次结构（分类） 描述了这一点，并且仅描述了这一点。
G 层次结构（示例数据） 说明了这一点，并且仅说明了这一点。
您描述层次结构（组织结构图）的方式与我描述它们的方式（资源管理器）在风格上有所不同。一个最终变得非常宽，另一个更紧凑。我想你能想出来
你在上一个问题的最后已经说清楚了。毒书里的Type这个新奇的概念，把你搞糊涂了。这个问题，这些问题，与Type无关。
需要多说几句，时间允许我会回复的更全面。