那些遇到过的问题

子类型的关系数据建模

dzh*_*zhu 4 database-design data-modeling relational-database relational-model subtype

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

我知道数据建模是一个迭代过程,有许多不同的方法可以对事物进行建模.
但我不知道如何选择不同的选项.

例

假设我们想要模拟粒子(分子,原子,质子,中子,电子......).
为简单起见,让我们忽略夸克和其他粒子.

由于所有相同类型的粒子表现相同,我们不打算对单个粒子进行建模.
换句话说,我们不会存储每个氢原子.
相反,我们将储存氢,氧和其他原子类型.
我们要建模的实际上是粒子类型和它们之间的关系.

我不小心使用" 类型 " 这个词.
氢原子是一个实例.氢是一种类型.氢也是一种原子.
是的,涉及的类型层次结构.我们忽略了最低级别(单个粒子).

途径

我可以想到几种模拟它们的方法.

1.每种类型的事物(粒子类型)的一个表(关系,实体).

1.1我想到的第一种方法.

质子(质子)
中子(中子)
电子(电子)

原子(Atom)
Atom_Proton(原子,质子,数量)
Atom_Neutron(原子,中子,数量)
Atom_Electron(原子,电子,数量)

分子(分子)
Molecule_Atom(Molecule,Atom,Quantity)

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

原子(原子,质子数量,中子数量,电子量子)
分子(分子)
分子 _ 原子(分子,原子,数量)

在这个简化的模型中,关于质子的事实已经丢失.

2.一个表中的所有内容,其中关联表表示它们之间的关系.

2.1每个关系的一个关联表

粒子(粒子)

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

2.2单关联表

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

这种简化不会丢失任何东西.我认为这更好.
但如果存在特定于Atom_Proton/Atom_Neutron/Atom_Electron的事实,2.1可能会更好.

2.3结合2.1和2.2

粒子(粒子)

Atom_Proton(粒子,粒子,其他属性)
Atom_Neutron(粒子,粒子,其他属性)
Atom_Electron(粒子,粒子,其他属性) Molecule_Atom(粒子,粒子,其他属性)

ParticleComposition(粒子,粒子,数量,其他属性)

在这种方法中,关于粒子组成的常见属性在ParticleComposition中,
而关于粒子组成的特殊属性在特殊表中.

3.使用子类型表.

3.1基本类型粒子表和子类型的附加表(Atom,Molecule,...).

粒子(粒子)

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

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.

粒子(粒子)

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

Molecule_Atom(粒子,粒子,原子量)

它更简单,但关于质子/中子/电子的信息在1.2中丢失了.

3.3我们可以更改Molecule_Atom的名称,使其更通用.

粒子(粒子)

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

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

这看起来像2.2,附加了子类型表(Atom,Molecule).
似乎2.2是3.3的特例.

3.4我们可以结合上述所有方法并获得通用模型.

粒子(粒子)

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

ParticleComposition(粒子,粒子,数量,其他属性)

Atom_Proton(粒子,粒子,其他属性)
Atom_Neutron(粒子,粒子,其他属性)
Atom_Electron(粒子,粒子,其他属性)
Molecule_Atom(粒子,粒子,其他属性)

Atom_Proton,Atom_Neutron,Atom_Electron和Molecule_Atom似乎可以被认为是ParticleComposition的子类型.

这种方法是最复杂的方法,它包含许多表,但每个表都有自己的作用.

问题

  1. 上述任何设计是否违反了关系模型的规则？
  2. 哪种方法最好？这取决于我们对数据的看法吗？它取决于要求吗？

  3. 如果它取决于要求,我们首先应选择最简单的设计,然后使其更通用以适应新的要求吗？
    虽然生成的数据模型有许多相似之处,但初始设计可能会影响表/列的命名,并且键的域也不同.

    • 如果我们选择使用一个表为每种类型的东西,我们可以选择不兼容的按键原子和分子,如原子的重量为原子和分子的名字的分子.
    • 如果我们选择使用通用方法,我们可以为所有粒子选择公共密钥.
      更改密钥可能会对系统产生更大的影响,因此从简单设计演变为通用设计可能并不容易.
      你怎么看？

PS:这可能不是一个合适的例子,并且解决方案可能存在问题,并且可能会有更多的方法变化,但您可以有希望得到这一点.
如果您有更好的设计,请与我分享.

更新1

要建模的数据是什么？

最初,我试图模拟粒子,因为

  • 我认为它们之间存在子类型关系,这正是我正在寻找的.
  • 它们被人们所熟知(？).
  • 这是人们如何理解世界的一个很好的例子.

这是我脑海中的画面. 粒子层次结构

我没有明确说明这一点,因为我不清楚我要模拟的是什么.
首先我认为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 }
Run Code Online (Sandbox Code Playgroud)

更高级别

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

我首先想到我们可以将Atom类型定义为: 

S_atom = S_hydrogen union S_oxygen union ...
Run Code Online (Sandbox Code Playgroud)

但是,集合是关系,元素是元组,因此如果关系中的元组不兼容,则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 }
Run Code Online (Sandbox Code Playgroud)

这意味着粒子是原子的类型,而原子是氢的类型.

这样,粒子之间的关系可以高水平表示.

新的数据模型

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 |

为了比较,这是子类型表方法的样本数据.


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 |

子原子

这些粒子类型由人和人们定义,不断定义新概念以模拟现实的新方面.
我们可以定义"子原子",层次结构将如下所示:

具有子原子的粒子类型层次结构

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

更新2

要记录的事实

  1. 世界上有不同类型的粒子:质子,中子,电子,原子,分子.
  2. 原子由质子,中子和电子组成.
  3. 分子由原子组成.
  4. 有许多不同类型的原子:氢,氧,......
  5. 有许多不同类型的分子:H2O,O2,....
  6. 氢原子由一个质子和一个电子组成; ...
  7. H2O分子由两个氢原子和一个氧原子组成; ...
  8. 不同类型的颗粒可能具有特殊性质,例如原子具有原子重量等.
  9. ...

Per*_*DBA 5

初步

好问题,对学习者来说非常周到.我认为你真正追求的是一个讨论,为了获得清晰,这是一个数据建模练习.

  • 我了解你的进展,包括3.3.什么,怎么样,你得到3.4(逐步升级到3.3之后)？对我来说,结合以上所有不等于Generic.

  • 根据您的讨论,让我根据TRD回答相关步骤,而不是跟进您的进展,并为每个步骤建立模型.

  • TRD只有由Key和Relationships标识的表在这个阶段是相关的,我认为你很清楚属性,如果有的话,以及它们将被部署的密钥.在获得稳定的TRD后,您可以将其扩展为完整的DM.

  • 在建立模型之后,从之前的模型开始,并且在评估之后,如果显然它丢失了信息,则可以安全地丢弃它.有一个值正在考虑这样的模型,所以步骤不正确.但是继续讨论它是一种浪费.我相信我在上一个问题中证明了这一点.

考虑这组表关系图.

1.x中

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

  • 我不知道Proton/Neutron/Electron是如何或为何是独立的表.它们不是自己存在的,它们的重量; 等等是固定的.它们仅存在于Atom的上下文中.

  • 由于每个Atom包含至少一个质子/中子/电子,质子/中子/电子列可以部署在Atom中.没画.后来.

2.X

你的进展很好,除了一个明显的错误.

关于粒子组成的常见属性在ParticleComposition中,而关于粒子组成的特殊属性在特殊表中.

不.粒子的常见属性在粒子中.特定于关系的属性(即不常见的)属于ParticleComposition.然后没有"关于粒子组成的特殊属性",没有"特殊表格".

3.X

考虑B子类型.你的[3.1]大多是正确的,除了:

  • 我不知道粒子是如何拥有像Proton/Neutron/Electron这样的孩子.只有Atom才有.

  • 我没有看到粒子是如何与其他粒子相关的(即那是什么？).对于所讨论的数据,分子由Atoms组成; 原子由质子/中子/电子组成; 粒子是分子x或原子(独有子类型).

  • 如果不正确,请纠正我.

  • 有关该主题的完整详细信息,请参阅子类型文档.

正如你所说,这可以是C Reduced.这就是每个Atom固定Proton/Neutron/Electron信息的概念:每个都有一个条目.例如.每个壳/能级没有区别; 中子可以接受零(而不是空).

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

3.3

如果它完全被D标准化:Atom总是至少有一个Proton条目; Neutron条目是可选的; 每个壳牌/能源水平都有所区别.

  • 注意Predicates中的差异.

  • 请注意,虽然Redu是一种有效的技术,但它并不等同于Normalization.

3.4

这似乎是所有内容的总和,平面布局或平面视图(派生关系,透视图,结果集).因此,理解这一点很好.但是如果你把它作为一组表提出,那么由于各种规范化错误,它是非常不正确的.如果纠正,将进展到[3.3]和我的[D标准化].

题

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

除了[3.3]之外的所有这些都违反了许多规则.大多数情况下,它们属于规范化错误.如果您要提供完整模型或CREATE TABLE语句,则会出现相关的标识错误.

但是,如果上下文是数据建模练习,那么无关紧要.如果这项工作很严重,那么上面的段落就是这样.

本部分按照SO指南进行介绍,具体来说:无论何时看到错误信息,都要正确.我对主题帖做了评论,但它们一直在消失.因此我把它放在这里.

Erwin Smout:
当归结为其本质时,数据的关系模型只有一个"规则":数据库中的所有信息都必须表示为关系中元组中属性的值.

这是规则之一,是的,但附带声明显然是错误的.

首先,关系模型中有许多基本或一阶规则.从记忆中,我会说大概四十岁.

其次,有许多二阶规则,这些规则在逻辑上隐含在一阶规则中.

  • 拥有技术资格和经验,能够理解RM,并遵循精神和意图的人,遵循所有这些.

  • 其他人可能无法识别一些一阶规则或大多数隐含规则.

  • 从书中可以看出有关RM的证据,还有其他人,那些积极颠覆和削弱RM的人.他们忽略了二阶规则,更糟糕的是,他们使用法利赛"逻辑"来破坏一阶规则.

  • 在这里,欧文,谁是众所周知的,他就努力RM上comp.databases.theory和TTM,降低了RM到一个精辟的规则,从而破坏了全套的规则,以及RM本身.特别是回答你的问题,如果不是我的回答,会引导读者相信RM是他所做的:只有一条规则,一切,关系以及非关系,"满足".

  • 在关系模型是免费的,你可以自己读.如果您想要副本,请告诉我.需要注意的是,术语已过时,需要加以解释.

其次,即使将其归结为一个规则(不可能,过于简化)或最重要的规则(可能,但是贬低),该规则也不会如此.这是四十个左右的一阶规则之一,但肯定没有排在顶部.

  • 但是,我允许其他人可能有不同的排名,以满足他们自己的目的.

  • 知道RM的人 确实讨论过,因为RM与其前辈之间的主要区别(不是规则)是:

    • 它是第一个拥有完整数学定义的(它构成了它的基础,并且其中的所有内容都来自于此).

    • 虽然前任使用物理记录ID来记录相关记录,但RM要求(a)由数据组成的逻辑密钥,以及(b)通过这些逻辑密钥关联行(而不是记录).

必须提到的是,这是在每个文件中被称为"主键"的记录ID特征的系统完全非关系的基础,回归到1970年以前的ISAM记录文件系统,该RM变得过时.另请注意,这些原始系统如何显示为"关系",因为通过精神分裂的"逻辑",它们"满足"一个引用的规则.诚实的逻辑破坏了这种无稽之谈.

正是由于错误的信息,这种基于记录ID的系统已经成为行业低端的noram.因此我愿意纠正它.

结束错误信息修正部分.

哪种方法最好？

正式数据建模,包括关系规范化.方法,科学,原理,而不是NF定义的片段.

我不认为这些提议是不同的方法,而是在一个单一的建模练习中列出你所有的想法.而模型开始采取严肃,可行的形状的点是[3.3].

这取决于我们对数据的看法吗？

当然.根据你对妻子的看法,你的婚姻会成功或失败,因为这种看法是你所有行为的所在.根据您对数据的感知,模型将成功或失败.

关系模型的一大优点是它教会我们查看(感知,思考,建模)数据,作为数据,而不是数据.首先,这形成了逻辑键概念.

它取决于要求吗？

第一个答案是,不,它不应该依赖于要求.它应该考虑数据,其范围仅限于企业(要求,是,但不是功能要求),只有数据.

当然,由于我在其他地方详述的原因,数据模型应该与现实世界相匹配,不应该限制数据的功能需求.

OO/ORM模型失败的大错误,常见原因是,它从OO/ORM模型的微小镜头中感知数据.它无法将数据与进程分开,它将数据视为对象的"持久性"从属.该模型中还有许多其他错误,我在此不会列举,重点是,它们从需求的位置开始,并忽略数据.

第二个答案是,在设定要求之前,项目不会受到委托,如果资金是基于需求的,则是现实.因此,成熟的项目负责人确保需求包含足够的理由来分析和建模数据,作为数据,与功能分开.

如果它取决于要求,我们首先应选择最简单的设计,然后使其更通用以适应新的要求吗？

你可以,但这将花费很多.成熟的序列是尽早获得正确的数据模型.

如果数据模型与现实世界匹配,当更改和添加出现时,很容易扩展.相反,如果数据模型是功能需求的最小值,或者它与现实世界不匹配,那么更改将是困难且成本高昂的.

虽然生成的数据模型有许多相似之处,但初始设计可能会影响表/列的命名,并且键的域也不同.

当然.

如果我们选择对每种类型的东西使用一个表,我们可以为Atom和Molecule选择不兼容的键,例如Atom的原子重量和Molecule的分子名称.

那将是一个可怕的错误.切勿将东西放在与标签不匹配的容器中.切勿在一个容器(有一个标签)中放置两个不同的东西.正确的方法是使用公共标识符Name(Atom-或Molecule-或Particle-name),并使用Subtypes.

如果我们选择使用通用方法,我们可以为所有粒子选择公共密钥.

只有有一个.如果没有,那表示实体不相同,则不能使用通用模型.

更改密钥可能会对系统产生更大的影响,因此从简单设计演变为通用设计可能并不容易.

好吧,我们的想法是选择稳定(非静态)的数据项来形成密钥.是的,关键设计是建模练习的一个重要方面.如果遵循关系模型,则键构成数据库的逻辑结构.域非常重要(我想你意识到了这一点).是的,改变成本很高.

这让我们回到了主要观点.这正是必须为每个表及其所有子表正确建模和选择键的原因.

更新1和2

我刚刚注意到你的两个更新.这不是一个完整的回应,现在只是一个很短的回应.

  • 到目前为止,我理解粒子是原子的集合加上分子的集合.这就是我在D Normalized中建模的内容.两者都有一个名字,一个共同的钥匙.它是亚型的.

但是现在,鉴于你的层次结构图和样本数据(谢谢),我意识到我认为你的意思和你的意思是两回事.考虑更新的TRD和层次结构:

  1. 你的粒子是一组分子加上一组原子加上一组亚原子粒子.

    • 那是不对的

    • 有一个层次结构,是的,但到目前为止,它存在于表的序列中,而不是作为一个表中的层次结构.

    • 换句话说,两组(原子,分子)是离散的,每组都有它们自己的一组组件,它们是不同的.没有包含所有内容的集合(理论通用集除外).

    更新的表关系模型为E规范化•更新2.子类型已与粒子一起被删除.它提供了Update 2中所述的所有要求.请注意更新的Predicates.

  2. 您的层次结构图不正确.

    • 您的错误是,您已将分类器(结构,容器)的层次结构与数据(分类器的实例;内容)相结合.你不能这样做.您需要两个单独的图表,一个用于容器,另一个用于内容.

    • 这是OO/ORM思维模式的典型错误.未遵守科学原则将数据与过程分开.在上一个问题中我对Hidders的回复中详述的完全相同的错误.结果是复杂的对象,从来没有真正起作用.

    • 因此,您的层次结构图是非法的,它是两个完全不同的图组合成一个.

    F层次结构(分类)描述了这一点,而且只是那个.

    G层次结构(示例数据)说明了这一点.

    您描绘层次结构的方式(组织结构图)与我描述层次结构的方式(资源管理器)之间存在差异.一个最终非常宽,另一个更紧凑.我想你可以搞清楚

  3. 在上一个问题的结尾处你有一些清晰度.的新概念,类型在有毒的书已经得到了你完全糊涂了.这个问题,这些问题与Type无关.

需要更多的话,我会在时间允许的情况下更充分地回应.

归档时间：

查看次数：

985 次

最近记录：

10 年，6 月 前
相关归档
避免在Web应用程序源中暴露主键？ 22
为什么可空的rowversion列在语义上等同于varbinary(8)？ 6
Jsonb vs 复合类型 vs 数十亿行的完全规范化 6
MySQL中的唯一约束 5
有没有办法在MySQL中影响用户定义的数据类型？ 5
SQL - 1 个包含许多 NULL 值或许多小表的大表 4
数据库设计 - 如何跟踪信息并查询表中的最新数据？ 2
Cassandra - 数据建模时间序列 - 避免"热点"？ 2
帮助数据库设计 0
可以在mysql中创建的数据库的最大限制？ 0
难疑归档
最终C++书籍指南和列表 4246
如何使用JavaScript复制到剪贴板？ 3131
使用Java创建内存泄漏 3076
var关键字的目的是什么？我何时应该使用它(或省略它)？ 1508
在C++中将int转换为字符串的最简单方法 1488
为什么Java有瞬态字段？ 1406
循环遍历Bash中的文件内容 1242
\ d效率低于[0-9] 1214
哪个MySQL数据类型用于存储布尔值 1168
自定义HTTP标头:命名约定 1051