在数据仓库中实现多对多关系的方法有哪些？

Question

数据仓库建模的主要拓扑（星形、雪花）在设计时考虑了一对多关系。当面临这些建模方案中的多对多关系时，查询可读性、性能和结构会严重下降。

有哪些方法可以在数据仓库中实现维度之间或事实表与维度之间的多对多关系？它们对必要的粒度和查询性能造成了哪些影响？

Answer 1

根据我的经验，递归层次结构是解决这个问题的最实用的方法。它具有以下优点：

1. 无限深度。
2. 紧凑。
3. 灵活性。
4. 速度。

相比之下，“对多”连接的每个级别都需要一个额外的表。这是硬编码的并且难以针对架构更新进行维护。

通过使用过滤索引，大型分层连接表可以以比专用表更快的速度执行。原因是与“将表连接到数据表”相比，每个连接只是“父子”。后者有更多的索引需要处理和存储。

多年来，我一直在努力解决这个问题。最近，这就是我想出来的。

Answer 2

数据仓库模型中 M:M 关系的一些场景

大多数 OLAP 服务器和 ROLAP 系统现在都有处理 M:M 数据结构的方法，但是您需要注意一些关于此的警告。如果您确实实施了 M:M 关系，您将需要密切关注您的报告层以及您想要支持的工具。

场景 1：M:M 维度到事实表

这方面的一个例子可能是一个电机政策上的多个驱动程序。如果您添加或删除驱动程序，则策略调整事务可能与随调整而更改的驱动程序列表有关。

选项 1 - M:M 驱动程序-事实桥接表 这将具有相当大的数据量，因为它具有给定策略的驱动程序 x 事务行。SSAS可以直接使用这个数据结构，但是通过ROLAP工具查询会比较慢。

如果您的 M:M 关系基于特定于事实行的实体（例如汽车上的司机），这可能也适用于 ROLAP 工具，前提是您的 ROLAP 工具支持 M:M 关系（例如使用业务中的上下文）对象）。

选项 2 - 虚拟“组合”维度表 如果您将公共代码列表映射到事实表（即链接实体不是事实行所特有的），那么您可以采用另一种方法来减少数据量。这种情况的一个例子是住院时的 ICD 代码。每次住院访问都会列出一个或多个 ICD 诊断和/或程序。ICD 代码是全球性的。

在这种情况下，您可以为每个案例创建一个不同的代码组合列表。为每个不同的组合制作一个包含一行的维度表，并在组合和 ICD 代码本身的参考表之间建立一个链接表。

事实表可以有一个“组合”维度的维度键，维度行有一个对实际 ICD 代码的引用列表。大多数 ROLAP 工具都可以使用这种数据结构。如果您的工具仅适用于实际的 M:M 关系，那么您可以创建一个视图来模拟事实和编码参考表之间的 M:M 关系。这将是 SSAS 的首选方法。

选项 1 的优点： - 适当索引，基于通过 M:M 表选择具有特定关系的事实表行的查询可以合理高效。

• 稍微简单的概念模型

选项 2 的优点： - 数据存储更紧凑

• 您可以通过将组合以人类可读的格式显示为“组合”维度上的代码来模拟直接的 1:M 关系。这对于不支持 M:M 关系的笨拙报告工具可能更有用。

场景2：维度之间的M:M关系：

很难想出一个用例，但人们可以再次使用 ICD 代码设想医疗保健之外的一些东西。在成本分析系统中，住院访问可能成为一个维度，并且在访问（或 NHS 中的顾问集）和编码之间具有 M:M 关系。

在这种情况下，您可以设置 M:M 关系，并可能在基本维度上编写人类可读的渲染。关系可以通过直接的 M:M 链接表或像以前一样通过桥接“组合”表来完成。可以通过 Business Objects 或质量更好的 ROLAP 工具正确查询此数据结构。

在我的头顶上，我看不到 SSAS 能够在不将关系直接归入事实表的情况下使用它，因此您需要展示编码和事实表之间的 M:M 关系视图行以将 SSAS 用于此数据。

Answer 3

我想确切地知道您在模型中考虑了什么样的多对多关系，无论是在事务系统中还是当前处于的任何数据模型中。

通常，维度之间的多对多关系是关于维度的事实。客户从为许多客户提供服务的几个分支机构订购的事实，或类似的事情。每一个都是事实。它会有一个有效日期或类似的东西，但这种关系可能是“无事实的”。除了客户和分支机构之外，关系本身可能还有其他维度。所以它是一个典型的星型模式，中心有一个（可能没有事实的）事实表。这颗星与仓库中其他维度星的关系显然取决于。任何时候您组合不同的星号时，您都会对业务键进行组合，并且必须确保您不会执行无意的交叉连接。

通常情况下，此类维度关系表的报告程度与较大的事实表不同，当它们报告时，数据并不总是那么多，因此不会影响性能。在上述情况下，您可能会随着时间的推移查看客户/分公司的利用率，但您的订单事实表中将提供有关实际订单数量的更好数据，该表可能还有客户、分公司等的维度。这些不是什么大多数人会考虑多对多（尽管可以认为订单定义了从客户到分支机构的多对多关系），因此在数据仓库环境中更为典型。如果您将汇总信息汇总到该关系级别（即客户、分支机构、月份、

Answer 4

以下是来自 Kimball 和其他人的一些相关文章，它们可能适用于对给定的提议多对多关系进行建模。请注意，多对多关系只是问题域/逻辑模型中的一个概念。在规范化的 OLTP 模型中，它仍然会使用链接表来处理，当然，每个方式都是一对多的。在非规范化的 Kimball 数据仓库模型中，有多种方法可以做到这一点，其中一种方法基本上将链接表视为位于星形中心的事实。另一个是作为标志列的数组。

最终，选择将取决于您正在建模的对象、它的变化方式以及您希望如何对其进行报告。这就是维度建模和数据仓库与规范化模型大相径庭的地方。规范化模型专注于数据中的逻辑和理论关系，数据仓库始终关注现实用例并进行非规范化以使其发挥作用。

使用桥接表对替代层次结构进行建模：

http://www.kimballgroup.com/wp-content/uploads/2012/05/DT62Alternative.pdf

多对多关系的三个选项（与数字份额分配相关 - 请参阅评论以了解一些有趣的来回）

http://www.pythian.com/news/364/implementing-many-to-many-relationships-in-data-warehousing/

不幸的是，很多 Kimball 的 Information Week/DBMS mag 文章不再有好的链接......