Star Schema設計思路是本文我們主要要介紹的內容，在實際工作中，遇到的數據通常是很不規則的，類似于xml，有很多一對多的關系。例如一個商品，可以有很多種稅，有幾個累加的折扣，每個折扣又有一些信息，例如折扣的原因，折扣率之類。在《Star Schema The Complete Reference》中提到了兩種經典的做法來解決一對多的關系。

1.簡單方法

用稅來舉例子，如果稅的類型數是固定的，例如一個商品最多6種稅。就把這六種稅在fact table中放置6個外鍵，指向稅的dimension table。其實如果是column database，加屬性應是很快的，所以即使稅的種類不定，應該也可以處理。這種方法的問題很明顯，就是導致fact table的屬性過多。

2. bridge方法

做一個中間表，即bridge表，只有兩個屬性：groupid和taxid, 一個groupid對應fact table中的一個item, 一個 taxid對應一個group中一種稅。taxid對應到tax dimension table的表中的一行。如果需要加稅的種類，直接在 tax dimension table里加就可以了。這樣就可以應用到tax 種類數量不清楚的情況。

但bridge方法在join fact table和 tax dimension table時可能會出多次計算的錯誤。

現實中的情況和書本中總是有區別的，早上和老板討論，對于海量數據而言，bridge table可能非常大，使得join 性能很低，所以bridge對于海量數據而言可用性不大。

對于實際應用中raw data 轉化為數據倉庫中的Star Schema，可能遇到很多書本中沒有的問題。其實Peter提出的flatten table方法可以最直觀，最完整，最方便的展現數據的信息。但是對數據庫的NULL值優化處理要求很高。一著是對NULL的存儲壓縮，二者是對數據的索引優化時對NULL的處理，三者是查詢性能。

而當面對很多一對N的多層關系時，N是否是定值或者是有最大值尤其重要，在行式數據庫中，只有N有限制或為定值才能使用上述簡單方法，而對于bridge，性能和查詢的正確性又是問題。這是一個取舍的難題。

關于Star Schema設計思路與總結就介紹到這里了，希望本次的介紹能夠對您有所收獲！

【編輯推薦】

1. Oracle 10g正則表達式REGEXP_LIKE簡介
2. Oracle 10g監聽listener不能啟動的解決方案總結
3. Oracle 10g Shrink Table和Shrink Space使用詳解
4. Oracle 10g利用utlsampl.sql創建scott用戶及樣本數據
5. Oracle 10g透明網關訪問SQL Server 2000之配置監聽