建站
咨詢
售后
建站咨詢
新聞中心
Star Schema設(shè)計(jì)思路是本文我們主要要介紹的內(nèi)容，在實(shí)際工作中，遇到的數(shù)據(jù)通常是很不規(guī)則的，類(lèi)似于xml，有很多一對(duì)多的關(guān)系。例如一個(gè)商品，可以有很多種稅，有幾個(gè)累加的折扣，每個(gè)折扣又有一些信息，例如折扣的原因，折扣率之類(lèi)。在《Star Schema The Complete Reference》中提到了兩種經(jīng)典的做法來(lái)解決一對(duì)多的關(guān)系。
1.簡(jiǎn)單方法
用稅來(lái)舉例子，如果稅的類(lèi)型數(shù)是固定的，例如一個(gè)商品最多6種稅。就把這六種稅在fact table中放置6個(gè)外鍵，指向稅的dimension table。其實(shí)如果是column database，加屬性應(yīng)是很快的，所以即使稅的種類(lèi)不定，應(yīng)該也可以處理。這種方法的問(wèn)題很明顯，就是導(dǎo)致fact table的屬性過(guò)多。
2. bridge方法
做一個(gè)中間表，即bridge表，只有兩個(gè)屬性：groupid和taxid, 一個(gè)groupid對(duì)應(yīng)fact table中的一個(gè)item, 一個(gè) taxid對(duì)應(yīng)一個(gè)group中一種稅。taxid對(duì)應(yīng)到tax dimension table的表中的一行。如果需要加稅的種類(lèi)，直接在 tax dimension table里加就可以了。這樣就可以應(yīng)用到tax 種類(lèi)數(shù)量不清楚的情況。
但bridge方法在join fact table和 tax dimension table時(shí)可能會(huì)出多次計(jì)算的錯(cuò)誤。
現(xiàn)實(shí)中的情況和書(shū)本中總是有區(qū)別的，早上和老板討論，對(duì)于海量數(shù)據(jù)而言，bridge table可能非常大，使得join 性能很低，所以bridge對(duì)于海量數(shù)據(jù)而言可用性不大。
對(duì)于實(shí)際應(yīng)用中raw data 轉(zhuǎn)化為數(shù)據(jù)倉(cāng)庫(kù)中的Star Schema，可能遇到很多書(shū)本中沒(méi)有的問(wèn)題。其實(shí)Peter提出的flatten table方法可以最直觀，最完整，最方便的展現(xiàn)數(shù)據(jù)的信息。但是對(duì)數(shù)據(jù)庫(kù)的NULL值優(yōu)化處理要求很高。一著是對(duì)NULL的存儲(chǔ)壓縮，二者是對(duì)數(shù)據(jù)的索引優(yōu)化時(shí)對(duì)NULL的處理，三者是查詢性能。
而當(dāng)面對(duì)很多一對(duì)N的多層關(guān)系時(shí)，N是否是定值或者是有最大值尤其重要，在行式數(shù)據(jù)庫(kù)中，只有N有限制或?yàn)槎ㄖ挡拍苁褂蒙鲜龊?jiǎn)單方法，而對(duì)于bridge，性能和查詢的正確性又是問(wèn)題。這是一個(gè)取舍的難題。
關(guān)于Star Schema設(shè)計(jì)思路與總結(jié)就介紹到這里了，希望本次的介紹能夠?qū)δ兴斋@！
分享題目：StarSchema的設(shè)計(jì)思路與總結(jié)
網(wǎng)頁(yè)路徑：http://m.fisionsoft.com.cn/article/cosgiog.html
