数据仓库建模的主要拓扑（星形、雪花形）在设计时考虑了一对多关系。当面对这些建模方案中的多对多关系时，查询的可读性、性能和结构会严重下降。
有哪些方法可以在数据仓库中实现维度之间或事实表与维度之间的多对多关系，以及它们在必要的粒度和查询性能方面造成了哪些妥协？
AskOverflow.Dev
数据仓库建模的主要拓扑（星形、雪花形）在设计时考虑了一对多关系。当面对这些建模方案中的多对多关系时，查询的可读性、性能和结构会严重下降。
有哪些方法可以在数据仓库中实现维度之间或事实表与维度之间的多对多关系，以及它们在必要的粒度和查询性能方面造成了哪些妥协？
以我的经验，递归层次结构是解决这个问题的最实用的方法。它具有以下优点：
相比之下，每个级别的“多对多”连接都需要一个额外的表。这是硬编码的，很难针对模式更新进行维护。
通过使用过滤索引，分层连接的大型表可以以比专用表更快的速度执行。原因是与“将表连接到数据表”相比，每个连接都只是“父子”。后者有更多的索引来处理和存储。
多年来，我一直在努力解决这个问题。最近，这是我想出的。
数据仓库模型中 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 的优点： - 数据存储更紧凑
场景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 文章不再有很好的链接......
我们可以解决这个问题的一种方法是让 Fact 表只有 2 列，来自 2 个维度的外键具有多对多关系。