數倉建模方法之范式建模、ER實體建模、維度建模


范式建模(經典數倉----關系型數據庫)

  不多贅述,直接三范式:

  第一范式:

  保證每列的原子性。即數據庫表中的所有字段值都是不可分解的原子值。

  第二范式:

  保證一張表只描述一件事情。即除主鍵外其他字段完全依賴於主鍵。

  第三范式:

  不可傳遞依賴。即表中的字段和主鍵直接對應不依靠其他中間字段,說白了就是,決定某字段值的必須是主鍵。

 

ER實體建模:

  將事務抽象為"實體"(Entity)、"屬性"(Property)、"關系"(Relationship)來表示數據關聯和事物描述,這種對數據的抽象建模通常被稱為ER實體關系模型。

  描述一個簡單的事實:“小明開車去學校上學”。以這個業務事實為例,我們可以把“小明”,“學校”看成是一個實體, “上學”描述的是一個業務過程,我們在這里可以抽象為一個具體“事件”,而“開車去”則可以看成是事件“上學”的一個說明。

使用的抽象歸納方法其實很簡單,任何業務可以看成 3 個部分:

  1. 實體,主要指領域模型中特定的概念主體,指發生業務關系的對象
  2. 事件,主要指概念主體之間完成一次業務流程的過程,特指特定的業務過程
  3. 說明,主要是針對實體和事件的特殊說明

 

維度建模:

  好處:

  1.適配大數據的處理方式

  維度模型的非強范式的,可以更好的利用大數據處理框架的處理能力,避免范式操作的過多關聯操作,可以實現高度的並行化。數據倉庫大多數時候是比較適合使用星型模型構建底層數據Hive表,通過大量的冗余來提升查詢效率,星型模型對OLAP的分析引擎支持比較友好,這一點在Kylin中比較能體現。雪花模型在關系型數據庫中如MySQL,Oracle中非常常見,尤其像電商的數據庫表。

  2.自下而上的建設現狀
  表已經存在,業務已經開發完畢,需求直接提過來了,這幾乎是一個普遍現狀,因為很少有公司會提前成立數據部門,讓數據部門跟隨着業務從頭開始一直成長,都是當業務發展到一定的階段了,想通過數據來提高公司的運營效果

  3.簡單的模型
  這個模型相對來說是比較簡單的,簡單主要體現在兩個方面:
  (1)維度建模非常直觀,緊緊圍繞着業務模型,可以直觀的反映出業務模型中的業務問題。不需要經過特別的抽象處理,即可以完成維度建模。這一點也是維度建模的優勢。
  (2)星型結構的實現不用考慮很多正規化的因素,設計與實現都比較簡單。

  分層和建模的關系:  

  明細層的范式模型:
  明細層采用傳統的三范式關系模型。這一層次的數據模型要將業務過程描述清楚,將源數據(即業務系統)中隱含的、有歧義的概念進行清晰化,如活躍用戶、VIP用戶等。該層次的數據模型追求的目標是靈活地表達業務過程,要保證數據一致性、唯一性、正確性,以盡量少的代價與源數據保持數據同步,同時該層次的數據模型不建議開給不懂技術的業務人員直接使用,因此,采用關系型的三范式模型是最佳的選擇。

  集市層的維度模型:
集市層是按照業務主題、分主題構建出來的、面向特定部門或人員的數據集合,該層次的數據模型會開放給業務人員使用,進行數據挖掘及業務分析。由於業務員多數不懂數據庫技術,缺少將業務需求轉換為關系型數據結構的邏輯思維,更寫不出復雜的SQL語句,因此,越簡單的數據模型,越能被他們所接受,因此,這個層次所構建出來的數據模型,要按照業務過程進行組織,每個事實表代表一個獨立的業務過程,事實表之間不存在直接的依賴關系,這樣業務人員可以很容易地將分析需求對應到事實表上,利用工具或手工寫出簡單的SQL,將統計數據提取出來進行分析。

  星型和雪花模型的介紹及不同:

  星型模型和雪花模型的主要區別在於對維度表的拆分,對於雪花模型,維度表的設計更加規范,一般符合3NF;而星型模型,一般采用降維的操作,利用冗余來避免模型過於復雜,提高易用性和分析效率。

  星型模型:
  核心是一個事實表及多個非正規化描述的維度表組成,維度表之間是沒有關聯的,維度表是直接關聯到事實表上的,只有當維度表極大,存儲空間是個問題時,才考慮雪花型維度,簡而言之,最好就用星型維度即可當所有維表都直接連接到“ 事實表”上時,整個圖解就像星星一樣,故將該模型稱為星型模型。
  星型架構是一種非正規化的結構,多維數據集的每一個維度都直接與事實表相連接,不存在漸變維度,所以數據有一定的冗余,如在地域維度表中,存在國家 A 省 B 的城市 C 以及國家 A 省 B 的城市 D 兩條記錄,那么國家 A 和省 B的信息分別存儲了兩次,即存在冗余。

  雪花模型:
  星形模式中的維表相對雪花模式來說要大,而且不滿足規范化設計。雪花模型相當於將星形模式的大維表拆分成小維表,滿足了規范化設計。然而這種模式在實際應用中很少見,因為這樣做會導致開發難度增大,而數據冗余問題在數據倉庫里並不嚴重,可以認為雪花模型是星型模型的一個擴展,每個維度表可以繼續向外擴展,連接多個子維度。當有一個或多個維表沒有直接連接到事實表上,而是通過其他維表連接到事實表上時,其圖解就像多個雪花連接在一起,故稱雪花模型。

  維度建模步驟:

    1.選擇業務過程   >   2.聲明粒度   >   3.確認維度   >   4.確認事實  

  1、選擇業務過程

  維度建模是緊貼業務的,所以必須以業務為根基進行建模,那么選擇業務過程,顧名思義就是在整個業務流程中選取我們需要建模的業務,根據運營提供的需求及日后的易擴展性等進行選擇業務。比如商城,整個商城流程分為商家端,用戶端,平台端,運營需求是總訂單量,訂單人數,及用戶的購買情況等,我們選擇業務過程就選擇用戶端的數據,商家及平台端暫不考慮。業務選擇非常重要,因為后面所有的步驟都是基於此業務數據展開的。

  2、聲明粒度
  先舉個例子:對於用戶來說,一個用戶有一個身份證號,一個戶籍地址,多個手機號,多張銀行卡,那么與用戶粒度相同的粒度屬性有身份證粒度,戶籍地址粒度,比用戶粒度更細的粒度有手機號粒度,銀行卡粒度,存在一對一的關系就是相同粒度

  為什么要提相同粒度呢,因為維度建模中要求我們,在同一事實表中,必須具有相同的粒度,同一事實表中不要混用多種不同的粒度,不同的粒度數據建立不同的事實表。並且從給定的業務過程獲取數據時,強烈建議從關注原子粒度開始設計,也就是從最細粒度開始,因為原子粒度能夠承受無法預期的用戶查詢。但是上卷匯總粒度對查詢性能的提升很重要的,所以對於有明確需求的數據,我們建立針對需求的上卷匯總粒度,對需求不明朗的數據我們建立原子粒度。

  3、確認維度
  維度表是作為業務分析的入口和描述性標識,所以也被稱為數據倉庫的“靈魂”。在一堆的數據中怎么確認哪些是維度屬性呢,如果該列是對具體值的描述,是一個文本或常量,某一約束和行標識的參與者,此時該屬性往往是維度屬性,數倉工具箱中告訴我們牢牢掌握事實表的粒度,就能將所有可能存在的維度區分開,並且要確保維度表中不能出現重復數據,應使維度主鍵唯一

  4、確認事實
  事實表是用來度量的,基本上都以數量值表示,事實表中的每行對應一個度量,每行中的數據是一個特定級別的細節數據,稱為粒度。維度建模的核心原則之一是同一事實表中的所有度量必須具有相同的粒度這樣能確保不會出現重復計算度量的問題。有時候往往不能確定該列數據是事實屬性還是維度屬性。記住最實用的事實就是數值類型和可加類事實。所以可以通過分析該列是否是一種包含多個值並作為計算的參與者的度量,這種情況下該列往往是事實。

  事實表種類:

    事實表分為一下6類:

    1.事務事實表;

    2.周期快照事實表;

    3.累計快照事實表;

    4.無事實的事實表 ;

    5.聚集事實表;

    6.合並事實表。

  • 事物事實表:

  表中的一行對應空間或時間上某點的度量事件。就是一行數據中必須有度量字段,什么是度量,就是指標,比如說銷售金額,銷售數量等這些可加的或者半可加就是度量值。另一點就是事務事實表都包含一個與維度表關聯的外鍵。並且度量值必須和事務粒度保持一致。

  • 周期快照事實表:

  顧名思義,周期事實表就是每行都帶有時間值字段,代表周期,通常時間值都是標准周期,如某一天,某周,某月等。粒度是周期,而不是個體的事務,也就是說一個周期快照事實表中數據可以是多個事實,但是它們都屬於某個周期內。

  • 累計快照事實表:

  周期快照事實表是單個周期內數據,而累計快照事實表是由多個周期數據組成,每行匯總了過程開始到結束之間的度量。每行數據相當於管道或工作流,有事件的起點,過程,終點,並且每個關鍵步驟都包含日期字段。如訂單數據,累計快照事實表的一行就是一個訂單,當訂單產生時插入一行,當訂單發生變化時,這行就被修改。

  • 無事實的事實表

  我們以上討論的事實表度量都是數字化的,當然實際應用中絕大多數都是數字化的度量,但是也可能會有少量的沒有數字化的值但是還很有價值的字段,無事實的事實表就是為這種數據准備的,利用這種事實表可以分析發生了什么。

  • 聚集事實表

  聚集,就是對原子粒度的數據進行簡單的聚合操作,目的就是為了提高查詢性能。如我們需求是查詢全國所有門店的總銷售額,我們原子粒度的事實表中每行是每個分店每個商品的銷售額,聚集事實表就可以先聚合每個分店的總銷售額,這樣匯總所有門店的銷售額時計算的數據量就會小很多。

  • 合並事實表

  這種事實表遵循一個原則,就是相同粒度,數據可以來自多個過程,但是只要它們屬於相同粒度,就可以合並為一個事實表,這類事實表特別適合經常需要共同分析的多過程度量。

  維度表技術:

  • 維度表結構:

  維度表謹記一條原則,包含單一主鍵列,但有時因業務復雜,也可能出現聯合主鍵,請盡量避免,如果無法避免,也要確保必須是單一的,這很重要,如果維表主鍵不是單一,和事實表關聯時會出現數據發散,導致最后結果可能出現錯誤。維度表通常比較寬,包含大量的低粒度的文本屬性。

  • 跨表鑽取:

  跨表鑽取意思是當每個查詢的行頭都包含相同的一致性屬性時,使不同的查詢能夠針對兩個或更多的事實表進行查詢。

鑽取可以改變維的層次,變換分析的粒度。它包括上鑽/下鑽:

上鑽(roll-up):上卷是沿着維的層次向上聚集匯總數據。例如,對產品銷售數據,沿着時間維上卷,可以求出所有產品在所有地區每月(或季度或年或全部)的銷售額。

下鑽(drill-down):下鑽是上鑽的逆操作,它是沿着維的層次向下,查看更詳細的數據。

  • 維度退化:

   退化維度就是將維度退回到事實表中。因為有時維度除了主鍵沒有其他內容,雖然也是合法維度鍵,但是一般都會退回到事實表中,減少關聯次數,提高查詢性能。

  • 維度表空值屬性:

  使用 unknown 或 not applicable 替換空值。

 


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM