BI/數據倉庫/數據分析基礎入門：一些常見概念解釋

時間 2019-11-10

原文原文鏈接

Preface：本文將會講述 BI/DW/DA 領域的一些常見概念，如：事實表、維度表、建模、多維分析、cube 等，但不涉及具體實例分析。html

一、維（Dimension）

維是用於從不一樣角度描述事物特徵的，通常維都會有多層（Level：級別），每一個Level都會包含一些共有的或特有的屬性（Attribute），能夠用下圖來展現下維的結構和組成：web

以時間維爲例，時間維通常會包含年、季、月、日這幾個Level，每一個Level通常都會有ID、NAME、DESCRIPTION這幾個公共屬性，這幾個公共屬性不只適用於時間維，也一樣表如今其它各類不一樣類型的維。其中ID通常被視爲代理主鍵（Agent），它只被用於做爲惟一性標誌，而且是多維模型中關聯關係的代理者，在業務層面並不具備任何意義；NAME通常是業務主鍵（Business），在業務層面限制惟一性，通常做爲數據裝載（Load）時的關聯鍵；而DESCRIPTION則記錄了詳細描述信息，在多維展現和分析時咱們都會選擇使用DESCRIPTION來表述具體含義。數據庫

多維數據模型是爲了知足用戶從多角度多層次進行數據查詢和分析的須要而創建起來的基於事實和維的數據庫模型，其基本的應用是爲了實現OLAP（Online Analytical Processing）。
固然，經過多維數據模型的數據展現、查詢和獲取就是其做用的展示，但其真的做用的實如今於，經過數據倉庫能夠根據不一樣的數據需求創建起各種多維模型，並組成數據集市開放給不一樣的用戶羣體使用，也就是根據需求定製的各種數據商品擺放在數據集市中供不一樣的數據消費者進行採購。數據結構

二、Hierarchy 層次

由於上面這個結構的維是沒法直接應用於OLAP的，我前面的文章有介紹，其實OLAP須要基於有層級的自上而下的鑽取，或者自下而上地聚合。因此每個維必須有Hierarchy，至少有一個默認的，固然能夠有多個，見下圖：架構

有了Hierarchy，維裏面的Level就有了自上而下的樹形結構關係，也就是上層的每個成員（Member）都會包含下層的0個或多個成員，也就是樹的分支節點。這裏須要注意的是每一個Hierarchy樹的根節點通常都設置成全部成員的彙總（Total），當該維未被OLAP中使用時，默認顯示的就是該維上的彙總節點，也就是該維全部數據的聚合（或者說該維未被用於細分）。Hierarchy中的每一層都會包含若干個成員（Member），仍是以時間維，假設咱們建的是2006-2015這樣一個時間跨度的時間維，那麼最高層節點僅有一個Total的成員，包含了全部這10年的時間，而年的那層Level中包含200六、2007…2015這10個成員，每年又包含了4個季度成員，每一個季度包含3個月份成員……這樣彷佛瓜熟蒂落多了，咱們就能夠基於Hierarchy作一些OLAP操做了。數據庫設計

三、事實表

實表是用來記錄具體事件的，也就是你要關注的內容，包含了每一個事件的具體要素，以及具體發生的事情。事實表中以數字型爲主，包含了度量信息。好比用戶交易流水錶。函數

四、維表

維表則是對事實表中事件的要素的描述信息，就是你觀察該事務的角度，是從哪一個角度去觀察這個內容的。維度表常以文本類型爲主，經常被做爲事實表的「上下文」。通常用來解釋事實表中關鍵字緯度的具體內容，爲那些度量數值添加了業務意義。好比用戶屬性表。oop

五、圖解事實表與維度表

基於事實表和維表就能夠構建出多種多維模型，包括星形模型、雪花模型和星座模型。這裏再也不展開了，解釋概念真的很麻煩，並且基於個人理解的描述不必定全部人都能明白，仍是直接上實例吧：性能

這是一個最簡單的星形模型的實例。事實表裏面主要包含兩方面的信息：維和度量，維的具體描述信息記錄在維表，事實表中的維屬性只是一個關聯到維表的鍵，並不記錄具體信息；度量通常都會記錄事件的相應數值，好比這裏的產品的銷售數量、銷售額等。維表中的信息通常是能夠分層的，好比時間維的年月日、地域維的省市縣等，這類分層的信息就是爲了知足事實表中的度量能夠在不一樣的粒度上完成聚合，好比2010年商品的銷售額，來自上海市的銷售額等。
還有一點須要注意的是，維表的信息更新頻率不高或者保持相對的穩定，例如一個已經創建的十年的時間維在短時間是不須要更新的，地域維也是；可是事實表中的數據會不斷地更新或增長，由於事件一直在不斷地發生，用戶在不斷地購買商品、接受服務。測試

注：雪花模型是當有一個或多個維表沒有直接鏈接到事實表上，而是經過其餘維錶鏈接到事實表上時，其圖解就像多個雪花鏈接在一塊兒，故稱雪花模型。雪花模型是對星型模型的擴展。相比星型模型，雪花模型的特色是貼近業務，數據冗餘較少，但因爲錶鏈接的增長，致使了效率相對星型模型來的要低一些。

6、立方體 Cube

這裏所說的立方其實就是多維模型中間的事實表（Fact Table），它會引用全部相關維的維主鍵做爲自身的聯合主鍵，加上度量（Measure）和計算度量（Calculated Measure）就組成了立方的結構：

度量是用於描述事件的數字尺度，好比網站的瀏覽量（Pageviews）、訪問量（Visits），再如電子商務的訂單量、銷售額等。度量是實際儲存於物理表中的，而計算度量則沒有，計算度量是經過度量計算獲得的，好比同比（如去年同期的月利潤）、環比（如上個月的利潤）、利率（如環比利潤增加率）、份額（如該月中某類產品利潤所佔比例）、累計（如從年初到當前的累加利潤）、移動平均（如最近7天的平均利潤額）等，這些計算度量在Oracle中均可以藉助分析函數直接計算獲得，相信大部分的OLAP組件都會提供相似在時間序列上的分析功能。而這些計算度量每每對於分析而言更具意義，立方中藉助與各個維的關聯關係從不一樣的角度和層面來展示這些度量。

cube 通常是通過大量聚類運算好的而加以用特定方式存貯的多維報表，多拉幾個維度構成的報表雖然也有分析功能，可是它是死的，而cube能夠進行任意維度角度組合去看待數據，分析的味道更濃一些。對於cube, 你能夠把它想像成一個魔方的客觀形態(其實cube的維數通常比魔方的三維要多);而數據OLAP就是要從中抽取數據; 一個cube基於一個主題, 而且分爲幾個維, 維是圍繞主題的;
舉例：基於銷售的方體(cube) 主題是銷售，維是city; item; day; buyer; 等等，基於 cube，咱們能夠快速抽取和計算數據。

七、數據模型與數據建模

模型是對現實世界的抽象，設計數據庫系統時，通常會事先用抽象的圖表（ER圖）反映數據彼此之間的關係，稱爲創建數據模型。數據模型是數據庫管理系統用來表示實體與實體間聯繫的方法。在設計數據庫時，對業務進行分析、抽象、並從中找出內在聯繫，進而肯定數據庫的結構，這一過程就稱爲數據建模。

數據模型與數據建模的過程就是用標準來定義、規範數據。合理的業務模型設計對ETL相當重要。數據倉庫是企業唯1、真實、可靠的綜合數據平臺。數據倉庫的設計建模通常都依照三範式、星型模型、雪花模型，不管哪一種設計思想，都應該最大化地涵蓋關鍵業務數據，把運營環境中雜亂無序的數據結構統一成爲合理的、關聯的、分析型的新結構，而ETL則會依照模型的定義去提取數據源，進行轉換、清洗，並最終加載到目標數據倉庫中。
模型的重要之處在於對數據作標準化定義，實現統一的編碼、統一的分類和組織。標準化定義的內容包括：標準代碼統1、業務術語統一。ETL依照模型進行初始加載、增量加載、緩慢增加維、慢速變化維、事實表加載等數據集成，並根據業務需求制定相應的加載策略、刷新策略、彙總策略、維護策略。

八、數據模型的定義

數據模型按不一樣的應用層次分紅三種類型：分別是概念數據模型、邏輯數據模型、物理數據模型。概念數據模型（Conceptual Data Model）簡稱概念模型，是面向數據庫用戶的實現世界的模型，主要用來描述世界的概念化結構，它使數據庫的設計人員在設計的初始階段，擺脫計算機系統及DBMS的具體技術問題，集中精力分析數據以及數據之間的聯繫等，與具體的數據管理系統（Database Management System，簡稱DBMS）無關。概念數據模型必須換成邏輯數據模型，才能在DBMS中實現。邏輯數據模型是業務抽象到DBMS中，物理數據模型是邏輯數據模型的具體實現。

數據倉庫的物理模型較常見的操做型數據庫的物理模型有很大不一樣。最明顯的區別是：操做型數據庫主要是用來支撐即時操做，對數據庫的性能和質量要求都比較高，爲了防止「garbage in，garbage out」，一般設計操做型數據庫的都要遵循幾個範式的約束，除非少數狀況下爲了性能進行妥協，纔可能出現冗餘。而數據倉庫的創建並不上爲了支撐即時操做，或者說，數據倉庫的數據是來源於即時操做產生的數據，而不是直接來源於即時操做。因此它的數據質量是由操做性系統來保證的，而不是由幾個範式來保證的。並且爲了更好的跟蹤歷史信息，以及更快的產生報表，數據倉庫的物理模型中存在着大量冗餘字段。
數據倉庫的物理模型分爲星型和雪花型兩種。所謂星型，就是將模型中只有一個主題，其餘的表中存儲的都是主題的一些特徵。好比貨物銷量的主題倉庫中，每次出售記錄是事實表，而時間，售貨員，商品是維度，都和事實表有聯繫，組織起來就是星型。而若是更細化來看，商品是有種類，產地，價格等特徵的，從這個角度來看，有兩個主題，一個是商品出售，一個是商品自己。組織起來就是雪花型。實際項目中，因爲操做型系統業務的複雜性致使自己產生了大量的數據，因此，組織起來也以雪花型居多。

九、事實表和維度表的分界線

事實表是用來存儲主題的主幹內容的。以平常的工做量爲例，工做量可能具備以下屬性：工做日期，人員，上班時長，加班時長，工做性質，是否外勤，工做內容，審覈人。那麼什麼纔是主幹內容？很容易看出上班時長，加班時長是主幹，也就是工做量主題的基本內容，那麼工做日期，人員，工做性質，是否外勤，工做內容是否爲主幹信息呢？認真分析特徵會發現，日期，人員，性質，是否外勤都是能夠被分類的，例如日期有年-月-日的層次，人員也有上下級關係，外勤和正常上班也是兩類上班考勤記錄，而上班時長和加班時長則不具備此類意義。因此通常把可以分類的屬性單獨列出來，成爲維度表，在事實表中維護事實與維度的引用關係。
在上述例子中，事實表能夠設計成以下
WorkDate EmployeeID，WorkTypeID，Islegwork，Content，
而時間，員工，工做類型，是否外勤則歸爲維度表。
總的來看，和其餘創建主外鍵關係的表也都同樣。可是維度表的創建是須要有層次的（雖然不是必須，可是也是典型特徵），而事實表的創建是針對已經發生的事實的，是歷史數據的存檔，也就是說是不該該修改的。以測試部測試軟件的Bug爲例。每一個Bug都是一個事實。這個Bug的狀態在數據字典裏可能設計成新建，轉派，修復，拒絕等等。那麼在事實表中Bug表中有一個字段爲Status。當測試員或者開發人員改變了這個狀態的值，事實表中該如何更新呢？是直接更新Status仍是什麼其餘的方式？顯然，爲了可以追蹤這個Bug的歷史信息，應該是從新插入一條新的記錄（這裏能夠參考歷史拉鍊表的etl刷新策略）。那麼這和以往的數據庫設計有什麼區別呢？能夠看出對於原始記錄和新插入的記錄，其餘字段所有是相同的，也就是所有冗餘的。若是以BugID做爲主鍵，這時候會發現主鍵都是冗餘的（固然，插入以前只能刪除主鍵）。因此能夠看出，事實表通常是沒有主鍵的。數據的質量徹底由業務系統來把握。
總的說來，事實表的設計是以可以正確記錄歷史信息爲準則，維度表的設計是以可以以合適的角度來聚合主題內容爲準則。

十、鑽取

鑽取是改變維的層次，變換分析的粒度。它包括向上鑽取（roll up）和向下鑽取（drill down）。roll up是在某一維上將低層次的細節數據歸納到高層次的彙總數據，或者減小維數；是指自動生成彙總行的分析方法。經過嚮導的方式，用戶能夠定義分析因素的彙總行，例如對於各地區各年度的銷售狀況，能夠生成地區與年度的合計行，也能夠生成地區或者年度的合計行。
而drill down則相反，它從彙總數據深刻到細節數據進行觀察或增長新維。例如，用戶分析「各地區、城市的銷售狀況」時，能夠對某一個城市的銷售額細分爲各個年度的銷售額，對某一年度的銷售額，能夠繼續細分爲各個季度的銷售額。經過鑽取的功能，使用戶對數據能更深刻了解，更容易發現問題，作出正確的決策。
鑽取容許你駕御一個報表內的不一樣層次的信息。在你的商業模式中，咱們定義不一樣層次的信息，這些定義方式也表明着你的商業構建方法。
你可以從一個信息層到有細節的更低層或更高層進行提取。例如，假如你的數據是被區域、市場、和商店所組織的，而且你可以運行一個顯示區域銷售的報表，那麼你就能夠從一個區域層鑽取數據以便顯示組成該區域的市場的銷售。反之，你能從從商店中鑽取數據去瀏覽商店所屬的市場情況。

十一、交叉分析

交叉分析是指對數據在不一樣維度進行交叉展示，進行多角度結合分析的方法，彌補了獨立維度進行分析無法發現的一些問題。交叉分析以多維模型和數據立方爲基礎，也能夠認爲是一種特殊的細分方式，但跟細分的概念有點差別，若是有興趣能夠先閱讀下以前的文章——數據立方體與OLAP。細分的方法更多的是基於同一維度的縱深展開，也就是OLAP中的鑽取（Drill-down），好比從月彙總的數據細分來看天天的數據，就是在時間維度上的細分，或者從省份的數據細分查看省份中各城市的數據，是基於地域維的下鑽。交叉分析再也不侷限於一個維度，就像數據立方體與OLAP文章中的立方體，是基於不一樣維度的交叉，時間維、地域維和產品維交叉在一塊兒分析每一個小立方的數據表現，能夠經過OLAP的切片（Slice）和切塊（Dice）操做查看例如上海市在3月份的電子產品的銷售狀況，這會幫助咱們發現不少在單個維度中沒法發現的問題。因此，交叉分析是基於不一樣維度橫向地組合交叉，而不是細分在同一維度的縱向展開。大致大樣式以下：

通常以表格呈現：