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