有什么方法可以在数据仓库中实现多对多关系？

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

有什么方法可以实现维度之间或事实表与数据仓库中的维度之间的多对多关系，它们在必要的粒度和查询性能方面会造成什么折衷？

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

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

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

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

我多年来一直试图解决这个问题。最近，这就是我想到的。

数据仓库模型中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用于此数据。

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

通常，尺寸之间的多对多关系是关于尺寸的事实。客户从为许多客户提供服务的几个分支机构下订单的事实，或类似的东西。这些都是事实。它可能有一个生效日期或类似的日期，但是这种关系可能是“事实不足的”。除客户和分支机构外，关系本身可能还具有其他维度。因此，这是一个典型的星型模式，其中心有一个（可能没有事实的）事实表。这颗恒星如何与仓库中其他尺寸的恒星相关联显然取决于。每当您组合不同的星号时，都需要在业务关键点上这样做，并且必须确保您不会执行无意的交叉联接。

通常，人们对此类维度关系表的报告程度不及较大事实表的报告程度，并且当报告事实表时，它并不总是具有那么多的数据，因此不会倾向于影响性能。在上述情况下，您可能会查看一段时间内客户/分支机构的利用率，但是在订单事实表中可以找到有关实际订单数量的更好数据，该数据可能还具有客户，分支机构等的维度。大多数人会考虑多对多（尽管可以考虑使用一个订单来定义从客户到分支机构的多对多关系），因此在数据仓库环境中更为典型。如果您已将汇总信息汇总到该关系级别（即客户，分支机构，月份，

这是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文章不再具有良好的链接...

我们可以解决这一问题的一种方法是，使事实表只有两列，这两个维度中的外键具有多对多关系。