1

我对 OLTP 数据库进行非规范化以在 DWH 中使用。目前我正在对学习组进行非规范化。

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

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

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

4

1 回答 1

1

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

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

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

作为这一理念的一部分：

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

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

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

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

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

于 2019-05-09T08:41:51.937 回答