问在数据仓库中实现多到多关系的一些方法是什么？

EN

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

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

相反，对于“-to-多”连接的每个级别，它都需要额外的表。这是硬编码的，很难针对模式更新进行维护。

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

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

数据仓库模型

中M:M关系的一些场景

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

场景1: M:M维放在事实表

上

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

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

如果您的M:M关系基于特定于事实行的实体(例如，汽车上的驱动程序)，这可能也适用于ROLAP工具，提供您的ROLAP工具支持M:M关系(例如在Business中使用上下文)。

选项2-虚拟“组合”维度表--如果您正在将一个公共代码列表映射到事实表(即链接实体并不是事实行特有的)，那么您可以采取另一种减少数据量的方法。这类场景的一个例子是住院时的ICD代码。每次住院治疗都会列出一个或多个ICD诊断和/或程序。ICD代码是全球性的。

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

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

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

• 略简单的概念模型

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

• 您可以通过在“组合”维度上以人类可读的格式将这些组合表示为代码来模拟1:M关系。对于缺乏对M:M关系的支持的dumber报告工具来说，这可能更有用。

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

很难想到用例，但是可以用ICD代码再一次设想出医疗保健之外的东西。在成本分析系统中，住院治疗可能成为一个维度，并且在访问(或NHS语言中的顾问-插曲)与编码之间存在M:M关系。

在这种情况下，您可以设置M:M关系，并可能在基本维度上对它们进行人类可读的呈现。这些关系可以通过直接的M:M链接表或桥接的‘组合’表来完成，就像以前一样。可以通过业务对象或更高质量的ROLAP工具正确查询此数据结构。

在我的头上，我无法看到SSAS能够在不直接将关系降到事实表的情况下使用它，因此您需要提供编码和事实表行之间M:M关系的视图，以便在这些数据中使用SSAS。

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

通常，维度之间的多到多关系是关于维度的事实.事实上，一个客户从多个分支机构订购服务于许多客户，或者诸如此类的事情。每一个都是事实。它会有一个有效的日期或诸如此类的东西，但关系可能是“没有事实”。这种关系本身可能有其他方面，除了客户和分支机构。因此，这是一个典型的星型模式，中心有一个(可能没有事实的)事实表。这颗恒星如何与仓库中的其他维度恒星相关联，显然将取决于。任何时候，当您组合不同的星星时，您都会在业务键上这样做，并且必须确保您不会在无意中执行交叉连接。

通常情况下，人们并不像更大的事实表那样以同样的程度报告这种维度关系表，当它们这样做时，数据并不总是那么多，所以它不会影响性能。在上述情况下，您可能会看到随着时间的推移，客户/分支的使用情况，但订单事实表中将提供更好的实际订单数量数据，该表可能也有客户、分支等的维度。这些不是大多数人认为的多到多(虽然订单可以定义客户到分支之间的多到多关系)，因此在数据仓库环境中更为典型。如果你已经将汇总信息汇总到这个关系级别，即客户、分支、月份、总销售额--一个看起来更像是一个事实的汇总事实表--多维度模型--现在它有了数字数据，那么你只能在许多到多个模型上进行数值汇总。