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