在實際工作中，遇到的資料通常是很不規則的，類似於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，效能和查詢的正確性又是問題。這是乙個取捨的難題。
學習與總結
私有構造方法的類,不可被繼承.1.靜態工廠方法取代構造方法,組合取代繼承.優點 有名稱,不用每次呼叫建立乙個物件,可以返回原型別的子型別,引數型別例項更簡潔 2.n個必選引數 多個可選構造引數存在的情況下 建議使用 構造器模式 一般情況使用重疊構造器模式,但是可選引數超過4個就比較繁瑣 重疊構造如下...
計畫與總結
管理工作不能沒有計畫和總結。計畫是管理的重要職能，任何管理活動首先都是從計畫工作開始的。計畫是指對未來組織活動的目標 方案和步驟的設計。計畫的內容十分豐富，主要包括 決策 實施。人們想有效地進行各類管理活動，達到管理目標，就必須對 事物的發展，明確階段性的目標，選擇實現目標的行動方案，並制定工作步驟...
回顧與總結
簡介 俗話說，學會享受生活，不要只是一味的趕路而忽略了沿途的風景，到現在，我驀然發現，這句話說得是太好了 太對了。在這一段時間以來，感覺真的是很忙碌，但是有的時候又不知道自己在忙些什麼，只是 瞎忙 感覺只是在 忙 但是卻不知道自己究竟忙了些什麼？記得在兩三個月以前開始準備自考的時候，那個時候真的感覺...