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