第1章 電商業務與資料結構簡介
1.1 電商業務流程
電商業務流程
1.2 電商常識（SKU、SPU）
- SKU=Stock Keeping Unit（庫存量基本機關）。現在已經被引申為産品統一編号的簡稱，每種産品均對應有唯一的SKU号。
- SPU(Standard Product Unit)：是商品資訊聚合的最小機關，是一組可複用、易檢索的标準化資訊集合。
比如，咱們購買一台iPhoneX手機，iPhoneX手機就是一個SPU，但是你購買的時候，不可能是以iPhoneX手機為機關買的，商家也不可能以iPhoneX為機關記錄庫存SKU。必須要以什麼顔色什麼版本的iPhoneX為機關。比如，你購買的是一台銀色、128G記憶體的、支援聯通網絡的iPhoneX，商家也會以這個機關來記錄庫存數。那這個更細緻的機關就叫庫存單元（SKU）。
那SPU又是幹什麼的呢？
SPU
SPU表示一類商品。好處就是：可以共用商品圖檔，海報、銷售屬性等。
1.3 電商表結構
電商表結構
1.3.1 訂單表（order_info）
訂單表
1.3.2 訂單詳情表（order_detail）
訂單詳情表
1.3.3 商品表
商品表
1.3.4 使用者表
使用者表
1.3.5 商品一級分類表
商品一級分類表
1.3.6 商品二級分類表
商品二級分類表
1.3.7 商品三級分類表
商品三級分類表
1.3.8 支付流水表
支付流水表
第2章 數倉理論（面試重點）
2.1 表的分類
2.1.1 實體表
實體表，一般是指一個現實存在的業務對象，比如使用者，商品，商家，銷售員等等。
使用者表：
實體表
2.1.2 次元表
次元表，一般是指對應一些業務狀态，編号的解釋表。也可以稱之為碼表。
比如地區表，訂單狀态，支付方式，審批狀态，商品分類等等。
次元表
2.1.3 事務型事實表
事務型事實表，一般指随着業務發生不斷産生資料。特點是一旦發生不會再變化。
一般比如，交易流水，記錄檔，出庫入庫記錄等等。
事務型事實表
2.1.4 周期型事實表
周期型事實表，一般指随着業務發生不斷産生變化(更新, 新增)的資料。
與事務型不同的是，資料會随着業務周期性的推進而變化。
比如訂單，其中訂單狀态會周期性變化。再比如，請假、貸款申請，随着批複狀态在周期性變化。
訂單表：
周期型事實表
2.2 同步政策
資料同步政策的類型包括：全量表、增量表、新增及變化表、拉連結清單
- 全量表：存儲完整的資料。
- 增量表：存儲新增加的資料。
- 新增及變化表：存儲新增加的資料和變化的資料。
- 拉連結清單：對新增及變化表做定期合并。
2.2.1 實體表同步政策
實體表：比如使用者，商品，商家，銷售員等
實體表資料量比較小：通常可以做每日全量，就是每天存一份完整資料。即每日全量。
2.2.2 次元表同步政策
次元表：比如訂單狀态，審批狀态，商品分類
次元表資料量比較小：通常可以做每日全量，就是每天存一份完整資料。即每日全量。
說明：
1）針對可能會有變化的狀态資料可以存儲每日全量。
2）沒變化的客觀世界的次元（比如性别，地區，民族，政治成分，鞋子尺碼）可以隻存一份固定值。
2.2.3 事務型事實表同步政策
事務型事實表：比如，交易流水，記錄檔，出庫入庫記錄等。
因為資料不會變化，而且資料量巨大，是以每天隻同步新增資料即可，是以可以做成每日增量表，即每日建立一個分區存儲。
2.2.4 周期型事實表同步政策
周期型事實表：比如，訂單、請假、貸款申請等
這類表從資料量的角度，存每日全量的話，資料量太大，備援也太大。如果用每日增量的話無法反應資料變化。
每日新增及變化量，包括了當日的新增和修改。一般來說這個表，足夠計算大部分當日資料的。但是這種依然無法解決能夠得到某一個曆史時間點（時間切片）的切片資料。
是以要用利用每日新增和變化表，制作一張拉連結清單，以友善的取到某個時間切片的快照資料。是以我們需要得到每日新增及變化量。
拉連結清單
2.3 範式理論
2.3.1 範式概念
關系型資料庫設計時，遵照一定的規範要求，目的在于降低資料的備援性，目前業界範式有：第一範式(1NF)、第二範式(2NF)、第三範式(3NF)、巴斯-科德範式(BCNF)、第四範式(4NF)、第五範式(5NF)。
範式可以了解為設計一張資料表的表結構，符合的标準級别。
使用範式的根本目的是：
1）減少資料備援，盡量讓每個資料隻出現一次。
2）保證資料一緻性
缺點是擷取資料時，需要通過Join拼接出最後的資料。
2.3.2 函數依賴
函數依賴
2.3.3 三範式區分
三範式區分
二範式區分
三範式區分
未完待續