多對多維度或多值維度
維度表和事實表之間的標準關係是一對多關係，這意味着維度表中的一行記錄會連接事實表中的多行記錄，但是事實表中的一行記錄在維度表中只關聯一行記錄。這種關係很重要，因爲它防止了重複計數。幸運的是，在大多數情況下都是這種一對多關係。
在現實世界中還存在比一對多關係更復雜的兩種常見情況：
事實表和維度表之間的多對多關係。
維度表之間的多對多關係。
這兩種情況本質是相同的，但事實表和維度表之間的多對多關係少了唯一描述事實和維度組的中間維度。
對於這兩種情況，我們介紹一種稱爲橋接表的中間表，以支持更復雜的多對多關係。
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系統中通過它們自身的事實表來跟蹤。然而，這些關係和它們產生的變化對分析業務來說是相當重要的。我們在維度模型中把它們包含爲漸變維度，在一些情況下包含爲橋接表。