Sql 关系数据库中面向对象分析模式的实现

我最近开始阅读Martin Fowler的“分析模式”，试图提高我的数据建模技能，我发现这本书对于面向对象方法来说非常有趣和有启发性。然而，尽管我认为我了解大多数模式将如何转换为关系数据库模式，但我看不到如何以现实的方式实现它们

例如，在（非对象）关系数据库中实现“度量”模式（第3.4章）需要：

• 1张桌子，用于存放人员
• 1个用于存储个人测量值的表（N-1关系）
• 1个用于存储测量数量的表（1-1关系）
• 1个表，用于存储可能表征测量的现象类型（1-N关系）

在RDBMS中，所有这些都相当于实现连接的几个排序操作，以及需要连接的大量记录，特别是如果我们为每个人存储了大量人员和大量测量数据。我怀疑它不会表现得很好

我想，问题在于我的“怀疑”是否正确，以及是否有人可以根据讨论在关系数据库中实现此类分析模式的书籍或其他来源为我指出正确的方向

事先非常感谢，

---

尼科我不知道你提到的那本书。因此，我不明白“量”与“量”的分别。我假设“测量”与测量行为相关，即。E包含测量的日期和时间，“数量”是测量的值，如180表示人的身高（厘米）

---

对于使用关系数据库进行分析，a是一种常见的方法：您将有一个包含数量的中心事实表，以及维度表的外键，如

日期

，

现象

，和

人

，这并不复杂。从实体关系建模的角度来看，您将描述听起来像4个实体的内容：

• 人
• 测量
• 数量
• 现象类型

以及它们之间的一些关系：

• 每个人都有零到多个测量值；每次测量仅测量一个人
• 每次测量只有一个数量；每个数量只有一个测量值
• 每个测量描述一种且仅一种现象类型；每种现象类型都有零到多个测量值

所以…数据库中有4个表和3个关系

尽管如此，这样描述的模型可能是不正确的：假设测量和数量之间的1:1关系是强制性的——每个测量都有一个数量；每一个数量描述了一个单一的测量-是一种气味

具有1:1基数的关系通常（通常？）表示所涉及的两个实体实际上是同一底层逻辑实体的局部视图。模型应该重构为一个包含所有属性的实体。进行重构会使您减少到3个表和2个关系。但是，请注意，对于可选的一元关系（0:1），这并不一定是正确的

无论哪种方式，只要实现逻辑实体模型的物理数据库设计具有适当的覆盖索引，这都算不了什么

---

正确规范化模型的问题是，通常有许多窄表：窄表意味着每个数据页有更多行，因此搜索速度更快。如果由于数据库设计而存在实际的性能问题，则始终可以进行非规范化。如果你从一个非规范化模型开始，一旦你有了一个包含千兆字节数据的实时数据库，将其转换成适当的形式将变得困难和耗时。

作者对特定模式进行了大量阐述，因此很遗憾，很难详细描述，但你做得有些正确。“测量”代表测量行为，它有一个基本上是测量值的“数量”（包含值和单位），以及一个作为测量类型的“现象类型”（例如，可以是“身高”、“体重”、“血型”等）。许多oo分析模型必须进入数据库，而且最初的型号也不是普通的友好型。OOA启发法通常表示您不是在设计数据库模式，而是在为现实世界的问题建模。我喜欢这个答案，因为它告诉我，在将这些关系放到表中之前，只需对它们应用规范化技术。但是，不要更改分析模式。