多对多维度或多值维度-桥接表
多对多维度或多值维度
维度表和事实表之间的标准关系是一对多关系，这意味着维度表中的一行记录会连接事实表中的多行记录，但是事实表中的一行记录在维度表中只关联一行记录。这种关系很重要，因为它防止了重复计数。幸运的是，在大多数情况下都是这种一对多关系。
在现实世界中还存在比一对多关系更复杂的两种常见情况：
事实表和维度表之间的多对多关系。
维度表之间的多对多关系。
这两种情况本质是相同的，但事实表和维度表之间的多对多关系少了唯一描述事实和维度组的中间维度。
对于这两种情况，我们介绍一种称为桥接表的中间表，以支持更复杂的多对多关系。
1. 事实表和维度表之间的多对多关系
在多个维度表的值可以赋给单个事实事务时，事实表和维度表之间通常是多对多关系。一个常见的示例是多个销售代表可以参与给定的销售事务，这种情形经常发生在涉及大宗交易的复杂销售事件中(例如计算机系统)。精确地处理这种情况需要创建一个桥接表，将销售代表组合成一个组。SalesRepGroup桥接表如图2-4所示。
ETL过程需要针对每条引入的事实表记录中的销售代表组合，在桥接表中查找相应的销售代表组键。如果该销售代表组键不存在，就添加一个新的销售代表组。注意图2-4所示的桥接表有重复计数的风险。如果按照销售代表累加销售量，那么每个销售代表都会对总销售量做出贡献。对某些分析而言结果是正确的，但对于其他情况仍会有重复计数的问题。要解决这个问题，可以向桥接表中添加加权因子列。加权因子是一个分数值，所有的销售代表组的加权因子累加起来为1。将加权因子和累加事实相乘，以按照每个销售代表在分组中的比重分配事实。
注意可能需要在Orders和SalesRepGroup之间添加一个SalesRepGroupKey表，以支持真正的主键-外键关系。这会把这个事实-维度实例变成维度-维度实例。
2．维度之间的多对多关系
从分析的角度来看，维度之间的多对多关系是一个很重要的概念，大多数维度都不是完全相互独立的。维度之间的独立性是连续的，而不是有或没有这两种截然不同的状态。例如在连续的一端，零售店这条链状关系的库存维度和产品维度是相对独立的，而不是绝对独立的。一些库存方式不适合某些产品。其他维度之间的关系则紧密得多，但是由于存在多对多关系，因此很难将其组合成单个维度。例如在银行系统中，账户和顾客之间有直接关系，但不是一对一的关系。一个账户可以有一个或多个签名确认的顾客，一个顾客也可有多个账户。银行通常从账户的角度来处理数据；MonthAccountSnapshot(月账快照)是金融机构中常见的一种事实表。因为账户和顾客之间存在的多对多关系，这种更多关注账户的系统就很难按照顾客来查看账户。一种方法是创建CustomerGroup桥接表来连接事实表，例如前面多对多示例中的SalesRepGroup表。较好的方法是利用账户和顾客之间的关系，如图2-5所示。
账户和顾客维度之间的AccountToCustomer桥接表可以捕获多对多关系，并且有几个显著的优点。首先，源系统中的关系是已知的，因此创建桥接表比手动构建SalesRepGroup维度表更容易。其次，账户-顾客关系自身就非常有趣。AccountToCustomer桥接表可以回答诸如"每个顾客的平均账户数量是多少？"这样的问题，而无须连接任何事实表。
桥接表经常是底层业务过程的标志，特别是在需要跟踪桥接表随时间而产生的变化(即关系本身是类型2变化)时。对顾客和账户来说，业务过程可能称为账户维护，其中一项事务可能称作"添加签名人"。如果3个顾客与同一个账户关联，在源系统中该账户就会有3个"Add(添加)"事务。通常这些事务和它们表示的业务过程还不是很重要，不需要在DW/BI系统中通过它们自身的事实表来跟踪。然而，这些关系和它们产生的变化对分析业务来说是相当重要的。我们在维度模型中把它们包含为渐变维度，在一些情况下包含为桥接表。
注意：
Analysis Services的功能支持多对多关系的维度。Analysis
Services希望处理与本节所述相同的结构。它将桥接表称为中间事实表，其实是同一个概念。
资源：
下面是多对多关系的一些补充资料：
The Data Warehouse Toolkit，Second Edition(Wiley,
2002)中的第262到265页介绍了事实和维度之间的多对多关系，第205和206页介绍了维度之间的多对多关系。
转自：http://book.51cto.com/art/201207/346074.htm