非规范化时要走多远答案

【问题标题】：How deep to go when denormalising非规范化时要走多远
【发布时间】：2019-09-27 00:11:42
【问题描述】：

我对用于 DWH 的 OLTP 数据库进行了非规范化处理。目前我正在对学习组进行非规范化。

每个研究组都有一个指向 1 个项目的关键点。
每个项目都有一个指向 1 个部门的关键点。
每个系都有一个指向 1 所大学的重点。
每所大学都有一个指向 1 个城市的键。

现在我知道你应该对你的 OLTP 进行非规范化处理，但在这个 dwh 部门中，它本身就是一个维度。这也适用于大学。从研究组中添加一个指向部门的键是否就足够了，还是尽可能地去规范化并将该部门的所有属性及其M：1相关表中的所有属性添加到维度研究组中？甚至当系和大学将自己成为维度？

换句话说：反规范化时你走了多远/多深？

【问题讨论】：

标签： data-warehouse olap denormalization dimensional-modeling oltp

【解决方案1】：

维度模型背后的关键概念是：

将事实表保持在 3NF（第三范式）；
将维度反规范化为 2NF（第二范式）

因此，理想情况下，您的模型中应该有的唯一连接是事实表和相关维度之间的连接。

作为这一理念的一部分：

避免“雪花”设计，其中维度包含其他维度的键。在不违反 3NF/2NF 规则的情况下，总是可以提出一个允许与雪花具有相同功能的数据模型；
永远不要在两个独立的维度（即部门和研究组）之间直接进行任何直接连接。维度之间的所有关系都必须通过事实表来解决；
永远不要在 2 个单独的事实表之间进行任何直接连接。事实表之间的任何关系都必须通过共享维度来解决。

最后，考虑到维度设计，除了优化查询数据之外，还有第二个重要目的：它是业务的语义模型（或它所代表的任何其他内容）。因此，在决定将数据元素组合成维度和事实时，请考虑它们的“逻辑相似性”——它们应该对最终用户具有直观意义。如果您很难向 BI 分析师解释您的维度或事实表的含义，那么您很可能犯了一个建模错误。

例如，在您的情况下，您应该考虑大学、部门、研究小组等之间的逻辑关系。大学/部门很可能形成一个自然层次结构。如果是这样，它们应该属于同一维度。另一方面，研究小组可能不会——让我们假设，可以跨多所大学和/或多个部门组建研究小组。这样的Many:Many关系清楚地表明它们应该通过事实表来解决。此外，大学和院系之间的关系是稳定的（很少发生变化），而研究小组的形成和解散非常频繁，因此应该单独建模。

一般来说，如果您看到维度元素之间的 1:1 或 1:M 关系，这通常表明它们应该被非规范化到同一个表中（同样，只有当它们的组合合乎逻辑时）。如果关系是 M:M，则很可能它们属于不同的表（您可以将它们强制放入同一个表中，但这些表通常看起来像科学怪人的生物）。

通过使您的问题更具体，您可以获得更好的帮助 - 绘制您的维度模型，发布它，然后询问您遇到的具体问题/挑战。对于一般概念，Kimball 和 Inmon 的书籍是你最好的朋友。

【讨论】：

很好的答案。我熟悉 Kimball 和 Inmon。然而，每次去规范化时我都会问自己：我应该走多远？别人怎么看？你的回答证实了我的怀疑。维度应该独立存在，并且不包含对其他维度的引用。没有尺寸相互参考实际上决定了问题。
一个关键点是你的项目很可能是一个事件，也应该有一个相关的事实记录。这可能是退化维度的一个例子，因为研究组也引用了该项目。