采用桥接表有利有弊，桥接表增加了误用模式的可能性，可能会大致不准确的结果，而拒绝桥接表则严重影响了维度解决方案应有的分析能力。所以只有了解它，才能在各种情况下为平衡能力与风险做出正确的抉择。
标准的一对多关系：
多值维度：
如果每个订单有多个销售人员。
面对多值维度，有两个基本选择：位置设计或桥接表设计。
1、事实表中多个键值，位置设计是指预留空值字段用于新增字段，缺点是难以扩展，很快就会发现表的列用光了，要增加新列很困难。仅支持数量有限的关系。
2、利用桥接表消除无法扩展和存在大量空值的情况，但是生成的表。 可能会导致双重或多重计算。
3、为了解决查询复杂的情况，有时不需要新建桥接表，直接将多个维度用字符串分割，然后存储解决。如存|Ann|Henry|
区域是销售salesrep表的字段。
是关系型数据库的问题。在设计大数据数仓时可以考虑其他这种方式规避。
问题解决：
1、不提倡
2、增加分配因子。不提倡
多数情况下，分配因子不存在，可用性较低。
3、使用主成员补充桥接表，桥接表不直接对外。不能最终解决问题。不提倡。
4、缓慢变化维的问题。
5、交叉，同样是对一些关系型分析工具的妥协。不提倡
多值属性
理解上，是利用支架表和桥接表，解决方式和问题与多值维度雷同。
参考：
star schema完全参考手册
https://blog.csdn.net/u012073449/article/list/3?t=1
http://book.51cto.com/art/201207/346044.htm
多对多维度或多值维度
维度表和事实表之间的标准关系是一对多关系，这意味着维度表中的一行记录会连接事实表中的多行记录，但是事实表中的一行记录在维度表中只关联一行记录。这种关系很重要，因为它防止了重复计数。幸运的是，在大多数情况下都是这种一对多关系。
在现实世界中还存在比一对多关系更复杂的两种常见情况：
事实表和维度表之间的多对多关系。
维度表之间的多对多关系。
这两种情况本质是相同的，但事实表和维度表之间的多对多关系少了唯一描述事实和维度组的中间维度。对于这两种情况，我们介绍一种称为桥接表的中间表，以支持更复杂的多对多关系。
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系统中通过它们自身的事实表来跟踪。然而，这些关系和它们产生的变化对分析业务来说是相当重要的。我们在维度模型中把它们包含为渐变维度，在一些情况下包含为桥接表。