數(shù)據(jù)倉(cāng)庫(kù)和數(shù)據(jù)集市建模體系化總結(jié)
前言
數(shù)據(jù)倉(cāng)庫(kù)建模包含了幾種數(shù)據(jù)建模技術(shù)，除了ER建模和關(guān)系建模，還包括專門針對(duì)數(shù)據(jù)倉(cāng)庫(kù)的維度建模技術(shù)。
本文將詳細(xì)介紹數(shù)據(jù)倉(cāng)庫(kù)維度建模技術(shù)，并重點(diǎn)討論三種基于ER建模/關(guān)系建模/維度建模的數(shù)據(jù)倉(cāng)庫(kù)總體建模體系：規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)，維度建模數(shù)據(jù)倉(cāng)庫(kù)，以及獨(dú)立數(shù)據(jù)集市。
維度建模的基本概念
維度建模(dimensional modeling)是專門用于分析型數(shù)據(jù)庫(kù)、數(shù)據(jù)倉(cāng)庫(kù)、數(shù)據(jù)集市建模的方法。
它本身屬于一種關(guān)系建模方法，但和之前在操作型數(shù)據(jù)庫(kù)中介紹的關(guān)系建模方法相比增加了兩個(gè)概念：
1. 維度表(dimension)
表示對(duì)分析主題所屬類型的描述。比如"昨天早上張三在京東花費(fèi)200元購(gòu)買了一個(gè)皮包"。那么以購(gòu)買為主題進(jìn)行分析，可從這段信息中提取三個(gè)維度：時(shí)間維度(昨天早上)，地點(diǎn)維度(京東), 商品維度(皮包)。通常來(lái)說(shuō)維度表信息比較固定，且數(shù)據(jù)量小。
2. 事實(shí)表(fact table)
表示對(duì)分析主題的度量。比如上面那個(gè)例子中，200元就是事實(shí)信息。事實(shí)表包含了與各維度表相關(guān)聯(lián)的外碼，并通過(guò)JOIN方式與維度表關(guān)聯(lián)。事實(shí)表的度量通常是數(shù)值類型，且記錄數(shù)會(huì)不斷增加，表規(guī)模迅速增長(zhǎng)。
注：在數(shù)據(jù)倉(cāng)庫(kù)中不需要嚴(yán)格遵守規(guī)范化設(shè)計(jì)原則(具體原因請(qǐng)看上篇)。本文示例中的主碼，外碼均只表示一種對(duì)應(yīng)關(guān)系，此處特別說(shuō)明。
維度建模的三種模式
1. 星形模式
星形模式(Star Schema)是最常用的維度建模方式，下圖展示了使用星形模式進(jìn)行維度建模的關(guān)系結(jié)構(gòu)：
可以看出，星形模式的維度建模由一個(gè)事實(shí)表和一組維表成，且具有以下特點(diǎn)：
a. 維表只和事實(shí)表關(guān)聯(lián)，維表之間沒(méi)有關(guān)聯(lián)；
b. 每個(gè)維表的主碼為單列，且該主碼放置在事實(shí)表中，作為兩邊連接的外碼；
c. 以事實(shí)表為核心，維表圍繞核心呈星形分布；
2. 雪花模式
雪花模式(Snowflake Schema)是對(duì)星形模式的擴(kuò)展，每個(gè)維表可繼續(xù)向外連接多個(gè)子維表。下圖為使用雪花模式進(jìn)行維度建模的關(guān)系結(jié)構(gòu)：
星形模式中的維表相對(duì)雪花模式來(lái)說(shuō)要大，而且不滿足規(guī)范化設(shè)計(jì)。雪花模型相當(dāng)于將星形模式的大維表拆分成小維表，滿足了規(guī)范化設(shè)計(jì)。然而這種模式在實(shí)際應(yīng)用中很少見，因?yàn)檫@樣做會(huì)導(dǎo)致開發(fā)難度增大，而數(shù)據(jù)冗余問(wèn)題在數(shù)據(jù)倉(cāng)庫(kù)里并不嚴(yán)重。
3. 星座模式
星座模式(Fact Constellations Schema)也是星型模式的擴(kuò)展。基于這種思想就有了星座模式：
前面介紹的兩種維度建模方法都是多維表對(duì)應(yīng)單事實(shí)表，但在很多時(shí)候維度空間內(nèi)的事實(shí)表不止一個(gè)，而一個(gè)維表也可能被多個(gè)事實(shí)表用到。在業(yè)務(wù)發(fā)展后期，絕大部分維度建模都采用的是星座模式。
4. 三種模式對(duì)比
歸納一下，星形模式/雪花模式/星座模式的關(guān)系如下圖所示：
雪花模式是將星型模式的維表進(jìn)一步劃分，使各維表均滿足規(guī)范化設(shè)計(jì)。而星座模式則是允許星形模式中出現(xiàn)多個(gè)事實(shí)表。本文后面部分將具體講到這幾種模式的使用，請(qǐng)讀者結(jié)合實(shí)例體會(huì)。
實(shí)例：零售公司銷售主題的維度建模
在進(jìn)行維度建模前，首先要了解用戶需求。而筆者在數(shù)據(jù)庫(kù)系列的第一篇就講過(guò)，ER建模是當(dāng)前收集和可視化需求的最佳技術(shù)。因此假定和某零售公司進(jìn)行多次需求PK后，得到以下ER圖：
隨后可利用建模工具將ER圖直接映射到關(guān)系圖：
需求搜集完畢后，便可進(jìn)行維度建模了。本例采用星形模型維度建模。但不論采取何種模式，維度建模的關(guān)鍵在于明確下面四個(gè)問(wèn)題：
1. 哪些維度對(duì)主題分析有用？
本例中，根據(jù)產(chǎn)品(PRODUCT)、顧客(CUSTOMER)、商店(STORE)、日期(DATE)對(duì)銷售額進(jìn)行分析是非常有幫助的；
2. 如何使用現(xiàn)有數(shù)據(jù)生成維表？
a. 維度PRODUCT可由關(guān)系PRODUCT，關(guān)系VENDOR，關(guān)系CATEGORY連接得到；
b. 維度CUSTOMER和關(guān)系CUSTOMER相同；
c. 維度STORE可由關(guān)系STROE和關(guān)系REGION連接得到；
d. 維度CALENDAR由關(guān)系SALESTRANSACTION中的TDate列分離得到；
3. 用什么指標(biāo)來(lái)"度量"主題？
本例的主題是銷售，而銷量和銷售額這兩個(gè)指標(biāo)最能直觀反映銷售情況；
4. 如何使用現(xiàn)有數(shù)據(jù)生成事實(shí)表？
銷量和銷售額信息可以由關(guān)系SALESTRANSACTION和關(guān)系SOLDVIA，關(guān)系PRODUCT連接得到；
明確這四個(gè)問(wèn)題后，便能輕松完成維度建模：
細(xì)心的讀者會(huì)發(fā)現(xiàn)三個(gè)問(wèn)題：1. 維表不滿足規(guī)范化設(shè)計(jì)(不滿足3NF)；2. 事實(shí)表也不滿足規(guī)范化設(shè)計(jì)(1NF都不滿足)；3. 維度建模中各維度的主碼由***ID變成***Key；
對(duì)于前兩個(gè)問(wèn)題，由于當(dāng)前建模環(huán)境是數(shù)據(jù)倉(cāng)庫(kù)，而沒(méi)有更新操作，所以不需要嚴(yán)格做規(guī)范化設(shè)計(jì)來(lái)消除冗余避免更新異常。
因此雖然可以以雪花模型進(jìn)行維度建模，如下所示：
但這樣會(huì)加大查詢?nèi)藛T負(fù)擔(dān)：每次查詢都涉及到太多表了。因此在實(shí)際應(yīng)用中，雪花模型僅是一種理論上的模型。星座模型則出現(xiàn)在"維度建模數(shù)據(jù)倉(cāng)庫(kù)"中，本文后面將會(huì)講到。
對(duì)于第三個(gè)問(wèn)題，***Key這樣的字段被稱為代理碼(surrogate key)，它是一個(gè)通過(guò)自動(dòng)分配整數(shù)生成的主碼，沒(méi)有任何其他意義。使用它主要是為了能夠處理"緩慢變化的維度"，本文后面會(huì)仔細(xì)分析這個(gè)問(wèn)題，這里不糾結(jié)。
更多可能的事實(shí)屬性
除了對(duì)應(yīng)到維度的外碼和度量屬性，事實(shí)表中還常常考慮另外兩個(gè)屬性：事務(wù)標(biāo)識(shí)碼(transaction identifier)和事務(wù)時(shí)間(transaction time)。
事務(wù)標(biāo)識(shí)碼通常被命名為TID，其意義就是各種訂單號(hào)，事務(wù)編號(hào)...... 為什么將這個(gè)屬性放到事實(shí)表而不是維表中呢？一個(gè)主要原因是它的數(shù)量級(jí)太大了，這樣每次查詢都會(huì)耗費(fèi)很多資源來(lái)Join。這種將某些邏輯意義上的維度放到事實(shí)表里的做法被稱為退化維度(degenerate dimension)。
將事務(wù)時(shí)間維度放到事實(shí)表中的考慮也是出于相同考慮。然而這么設(shè)計(jì)又一次"逆規(guī)范化"了：事務(wù)標(biāo)識(shí)碼非主碼卻決定事務(wù)標(biāo)識(shí)時(shí)間，顯然違背了3NF。但現(xiàn)在我們是為數(shù)據(jù)倉(cāng)庫(kù)建模，所以這樣做是OK的。另外在分布式的數(shù)據(jù)倉(cāng)庫(kù)中，這個(gè)字段十分重要。因?yàn)槭聦?shí)表的數(shù)量級(jí)非常大，Hive或者Spark SQL這類分布式數(shù)據(jù)倉(cāng)庫(kù)工具都會(huì)對(duì)這些數(shù)據(jù)進(jìn)行分區(qū)。任何成熟的分布式計(jì)算平臺(tái)中都應(yīng)禁止開發(fā)人員建立非分區(qū)事實(shí)表，并默認(rèn)分區(qū)字段為(當(dāng)天)日期。
經(jīng)典星座模型
前文已經(jīng)講過(guò)，有多個(gè)事實(shí)表的維度模型被稱為星座模型。星座模型主要有以下兩大作用：共享維度和設(shè)置細(xì)節(jié)/聚集事實(shí)表。下面分別對(duì)這兩種情況進(jìn)行分析：
1. 共享維度
以前文提到的零售公司為例，假如該公司質(zhì)量監(jiān)管部門希望用分析銷售主題同樣的方法分析劣質(zhì)產(chǎn)品，那么此時(shí)不需要重新維度建模，只需往模型里加入一個(gè)新的劣質(zhì)產(chǎn)品事實(shí)表。之后新的數(shù)據(jù)倉(cāng)庫(kù)維度建模結(jié)果如下：
2. 細(xì)節(jié)/聚集事實(shí)表
細(xì)節(jié)事實(shí)表(detailed fact tables)中每條記錄表示單一事實(shí)，而聚集事實(shí)表(aggregated fact tables)中每條記錄則聚合了多條事實(shí)。從表的字段上看，細(xì)節(jié)事實(shí)表通常有設(shè)置TID屬性，而聚集事實(shí)表則無(wú)。
兩種事實(shí)表各有優(yōu)缺點(diǎn)，細(xì)節(jié)事實(shí)表查詢靈活但是響應(yīng)速度相對(duì)慢，而聚集事實(shí)表雖然提高了查詢速度，但使查詢功能受到一定限制。一個(gè)常見的做法是使用星座模型同時(shí)設(shè)置兩種事實(shí)表(可含多個(gè)聚集事實(shí)表)。這種設(shè)計(jì)方法中，聚集事實(shí)表使用和細(xì)節(jié)事實(shí)表細(xì)節(jié)事實(shí)表的維度。如下維度建模方法采用星座模型綜合了細(xì)節(jié)事實(shí)表和兩種聚集事實(shí)表：
緩慢變化維度問(wèn)題
雖然，維表的數(shù)據(jù)比事實(shí)表更穩(wěn)定。但不論如何維度在某些時(shí)候總會(huì)發(fā)生一些變化。在之前曾拋出一個(gè)問(wèn)題：為什么維度建模后的關(guān)系不是***ID，而是***Key了。這樣做的目的其實(shí)就是為了解決一種被稱為緩慢維度變化(slowly changing dimension)的問(wèn)題。在維度變化后，一部分歷史信息就被丟掉了。比如張三是某公司會(huì)員。
但僅僅這么做還是不夠的，代理碼需要配合時(shí)間戳，以及行標(biāo)識(shí)符使用才能解決緩慢維度變化的問(wèn)題。如下CUSTOMER表使用該方法避免緩慢維度變化：
可以看到用戶張三對(duì)應(yīng)新維度的TaxBracket狀態(tài)由Low變成了High。如果需要統(tǒng)計(jì)張三的相關(guān)行為，那么可以讓所有記錄用CustomerID字段Join事實(shí)表；如果要統(tǒng)計(jì)當(dāng)前TaxBracket為L(zhǎng)ow的用戶狀態(tài)，則可將Row Indicator字段為Current的記錄用CustomerKey字段Join事實(shí)表；如果要統(tǒng)計(jì)歷史TaxBracket狀態(tài)為L(zhǎng)ow的用戶情況，則只需要將TaxBracket屬性為L(zhǎng)ow的用戶記錄的CustomerKey屬性與事實(shí)表關(guān)聯(lián)。
數(shù)據(jù)倉(cāng)庫(kù)建模體系之規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)
所謂"數(shù)據(jù)倉(cāng)庫(kù)建模體系"，指的是數(shù)據(jù)倉(cāng)庫(kù)從無(wú)到有的一整套建模方法。最常見的三種數(shù)據(jù)倉(cāng)庫(kù)建模體系分別為：規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)，維度建模數(shù)據(jù)倉(cāng)庫(kù)，獨(dú)立數(shù)據(jù)集市。很多書將它們稱為"數(shù)據(jù)倉(cāng)庫(kù)建模方法"，但筆者認(rèn)為數(shù)據(jù)倉(cāng)庫(kù)建模體系更能準(zhǔn)確表達(dá)意思，請(qǐng)?jiān)试S我自作主張一次吧：）。下面首先來(lái)介紹規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)。
規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)(normalized data warehouse)顧名思義，其中是規(guī)范化設(shè)計(jì)的分析型數(shù)據(jù)庫(kù)，然后基于這個(gè)數(shù)據(jù)庫(kù)為各部門建立數(shù)據(jù)集市。總體架構(gòu)如下圖所示：
該建模體系首先對(duì)ETL得到的數(shù)據(jù)進(jìn)行ER建模，關(guān)系建模，得到一個(gè)規(guī)范化的數(shù)據(jù)庫(kù)模式。然后用這個(gè)中心數(shù)據(jù)庫(kù)為公司各部門建立基于維度建模的數(shù)據(jù)集市。各部門開發(fā)人員大都從這些數(shù)據(jù)集市提數(shù)，通常來(lái)說(shuō)不允許直接訪問(wèn)中心數(shù)據(jù)庫(kù)。
數(shù)據(jù)倉(cāng)庫(kù)建模體系之維度建模數(shù)據(jù)倉(cāng)庫(kù)
非維度建模數(shù)據(jù)倉(cāng)庫(kù)(dimensionally modeled data warehouse)是一種使用交錯(cuò)維度進(jìn)行建模的數(shù)據(jù)倉(cāng)庫(kù)，其總體架構(gòu)如下圖所示：
該建模體系首先設(shè)計(jì)一組常用的度集合(conformed dimension)，然后創(chuàng)建一個(gè)大星座模型表示所有分析型數(shù)據(jù)。如果這種一致維度不滿足某些數(shù)據(jù)分析要求，自然也可在數(shù)據(jù)倉(cāng)庫(kù)之上繼續(xù)構(gòu)建新的數(shù)據(jù)集市。
數(shù)據(jù)倉(cāng)庫(kù)建模體系之獨(dú)立數(shù)據(jù)集市
獨(dú)立數(shù)據(jù)集市的建模體系是讓公司的各個(gè)組織自己創(chuàng)建并完成ETL，自己維護(hù)自己的數(shù)據(jù)集市。其總體架構(gòu)如下圖所示：
從技術(shù)上來(lái)講這是一種很不值得推崇的方式，因?yàn)閷⑹剐畔⒎稚ⅲ绊懥似髽I(yè)全局范圍內(nèi)數(shù)據(jù)分析的效率。此外，各組織之間的ETL架構(gòu)相互獨(dú)立無(wú)法復(fù)用，也浪費(fèi)了企業(yè)的開發(fā)資源。然而出于某些公司制度及預(yù)算方面的考慮，有時(shí)也會(huì)使用到這種建模體系。
三種數(shù)據(jù)倉(cāng)庫(kù)建模體系對(duì)比
規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)和維度建模數(shù)據(jù)倉(cāng)庫(kù)分別是Bill Inmon和Ralph Kimball提出的方法。關(guān)于哪種方法更好，哪種方法更優(yōu)秀的爭(zhēng)論已經(jīng)由來(lái)已久。但隨著這兩種數(shù)據(jù)倉(cāng)庫(kù)應(yīng)用越來(lái)越多，人們也逐漸了解到兩種數(shù)據(jù)倉(cāng)庫(kù)的優(yōu)劣之處，如下表所示：
產(chǎn)生這些區(qū)別的根本之處在于規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)需要對(duì)企業(yè)全局進(jìn)行規(guī)范化建模，這將導(dǎo)致較大的工作量。但這一步必須完成好，才能繼續(xù)往上建設(shè)數(shù)據(jù)集市。因此也就導(dǎo)致規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)需要一定時(shí)間才能投入使用，敏捷性相對(duì)后者來(lái)說(shuō)略差。但是規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)一旦建立好了，則以后數(shù)據(jù)就更易于管理。而且由于開發(fā)人員不能直接使用其中心數(shù)據(jù)庫(kù)，更加確保了數(shù)據(jù)質(zhì)量。還有由于中心數(shù)據(jù)庫(kù)是采用規(guī)范化設(shè)計(jì)的，冗余情況也會(huì)更少。
然而另一方面維度建模數(shù)據(jù)倉(cāng)庫(kù)除了敏捷性更強(qiáng)，而且適用于業(yè)務(wù)變化比較頻繁的情況，對(duì)開發(fā)人員的要求也沒(méi)有規(guī)范化數(shù)據(jù)倉(cāng)庫(kù)那么高。總之各有利弊，具體實(shí)施時(shí)需要仔細(xì)的權(quán)衡。
小結(jié)
數(shù)據(jù)倉(cāng)庫(kù)建模是一個(gè)綜合性技術(shù)，需要使用到ER建模、關(guān)系建模、維度建模等技術(shù)。而且當(dāng)企業(yè)業(yè)務(wù)復(fù)雜的時(shí)候，這部分工作更是需要專門團(tuán)隊(duì)與業(yè)務(wù)方共同合作來(lái)完成。因此一個(gè)優(yōu)秀的數(shù)據(jù)倉(cāng)庫(kù)建模團(tuán)隊(duì)既要有堅(jiān)實(shí)的數(shù)據(jù)倉(cāng)庫(kù)建模技術(shù)，還要有對(duì)現(xiàn)實(shí)業(yè)務(wù)清晰、透徹的理解。
推薦閱讀：
數(shù)據(jù)倉(cāng)庫(kù)系統(tǒng)的實(shí)現(xiàn)和使用(含OLAP重點(diǎn)講解)