數倉理論【範式】【次元模組化】

數倉理論

1 範式理論

1.1 範式概念

資料模組化要遵循一定的規則，在關系模組化中，這種規則就是範式

采用範式結構，可以有效的降低資料的備援性

範式在擷取資料時，需要通過join拼接出資料

範式有第一範式(1NF)，第二範式(2NF)，第三範式(3NF)，巴斯-科德範式(BCNF)，第四範式(4NF)，第五範式(5NF)

一般隻遵循到第三範式

1.2 函數依賴

1.2.1 完全函數依賴

通過(學号，課程)可以推斷出分數，但是單獨用學号或者課程都不能推斷出分數，這時可以說分數完全依賴于(學号，課程)

即AB能推斷出C，但是A和B單獨不能推斷出C，這時C完全依賴于AB

1.2.2 部分函數依賴

通過(學号，課程)可以推斷出姓名，但是隻通過學号就能推斷出姓名，這時可以說姓名部分依賴于(學号，課程)

即AB能得出C，A或B單獨也能得出C，這時C部分依賴于AB

1.2.3 傳遞函數依賴

學号可以推斷出學院名，學院名可以推斷出院長，但是院長推斷不出來學号，這時可以說院長傳遞依賴于學号

即A得出B，B得出C，但是C得不到A，這時C傳遞依賴于A

1.3三範式的區分

1.3.1 第一範式

1NF的核心原則為：屬性不可切割

比如下面的表格，商品列中的資料可以分割成 3台 和 電腦 ，是以下面的表格不遵循1NF

商品ID	商品	商家ID	使用者ID
001	3台電腦	001	001

修改成遵循1NF的表格為

商品ID	商品	商家ID	使用者ID	數量
001	電腦	001	001	3

1NF時關系型資料庫的最基本的要求，在RDBMS中建立表時，如果不符合1NF的要求，操作是不會成功的

1.3.2 第二範式

2NF的原則為：不存在部分函數依賴

比如下面的表格，屬性不可切割，滿足第一範式，但是課名不完全依賴于(學号，姓名)，是以不滿足2NF的要求

這時将表拆分成以下兩個，這時就滿足了2NF

1.3.3 第三範式

3NF的原則為：不存在傳遞函數依賴

拿上面滿足2NF的第二章表來說，系主任傳遞依賴于學号，是以需要進行進一步的拆解

拆分之後的如下兩張表滿足3NF

2 關系模組化和次元模組化

2.2 關系模組化

關系模組化将資料抽象成兩個概念：實體和關系，使用規範化的方式表示出來，如圖所示，關系模組化較為松散。

關系模組化遵循三範式，資料備援性低，但是查詢相對複雜，join操作比較多導緻MR較多，查詢效率較低

2.3 次元模組化

次元模組化以資料分析為出發點，不遵循三範式，存在一些資料備援

面向業務，将業務用事實表和次元表的方式表現出來

查詢效率較高

3 次元表和事實表

3.1 次元表

次元表一般是對事實的描述資訊，比如：使用者、商品、日期等

次元表很寬，具有多個屬性，列多

與事實表相比，行數相對較小

内容相對固定

• 比如：時間次元表

日期ID	day of week	day of year	季度
2023-2-15	3	46	1
2023-2-16	4	47	1

3.2 事實表

事實表中每行資料代表了一個業務事件(下單，支付等)

實時表示的是實踐的路徑成本(次數，個數，金額等)

比如：2023年2月15日，jx在京東花了40元買了一本書

次元表存儲：時間、使用者、商家、商品等

實時表存儲：數量、價錢(40元，一本)

一個事實表的行包括：路徑成本、與次元表相連的外鍵(通常有多個外鍵)

事實表非常大,相對較窄，列數較少，主要存儲的是外鍵id和路徑成本

經常會發生變化，會産生很多的新增資料

3.2.1 事務型事實表

以單個事務或時間為機關

比如：一筆支付記錄、一個訂單記錄

事實表中的一行資料，一旦事務被送出，資料被插入，就不能在進行更改

更新方式為增量同步

3.2.2 周期型快照事實表

不會保留所有的資料，隻保留固定時間間隔的資料

比如：每天的營業額、每月的賬戶餘額等

再比如：購物車随時都有可能增減商品，但是隻關心每天結束時購物車的情況

3.2.3 累積型快照事實表

用于跟蹤業務事實的變化

比如：要累積訂單從下單開始，到訂單商品打包、運輸、簽收的各個業務階段的資料來追蹤進展情況

這個業務進行時，事實表的記錄也要不斷更新

4 次元模型的分類

4.1 模型的介紹

次元模型分為三種：星型模型、雪花模型、星座模型

• 星型模型

标準的星型模型隻有一層

• 雪花模型

  

雪花模型和星型模型的差別主要在于次元的層級

雪花模型較為靠近3NF，但是無法完全遵守

• 星座模型

  

星座模型包含多個事實表，多個事實表共享次元表

多個星型模型或者雪花模型會形成星座模型

4.2 模型的選擇

星座模型不用進行原則，多個事實表共享次元表是正常的，是資料倉庫的常态

選擇星型模型還是雪花模型，取決于是性能優先還是靈活優先，在實際的開發中不會隻選擇一種，需要根據情況靈活組合

星型模型次元更少，可以減少join，進而減少shuffle