數據倉庫系列3-事實表 一. 事實表介紹 二. 事實表分類 2.1 事務事實表 三. 如何設計事實表 四. 高級事實表技術 參考:

一. 事實表介紹

1.1 事實表結構

  發生在現實世界中的操作型事件,所產生的可度量數值 ,存儲在事實表中。從最低 的粒度級別來看 ,事實錶行對應一個度量事件 ,反之亦然 。因此,事實表 的設計完全依賴 於物理活動,不受可能產生的最終報表的影響 。除數字度量外,事實表 總是包含外鍵 ,用 於關聯與之相關的維度 ,也包含可選的退化維度飽和日期/時間戳。查詢請求的主要 目標是基於事實表開展計算和聚集操作。

1.2 事實表的度量

  事實表的度量可以氛圍可加 、半可加 、不可加事實三類。
  事實表中的數據度量可劃分爲三類。最靈活、最有用的事實是完全可加,可加性度量可以按照與事實表關聯的任意維度彙總 。半可加度量可 以對某些維度彙總 ,但不能對所有 維度彙總 。差額是常見的半可加事實 ,除了時間維度外 ,它們可以跨所有維度進行加法操作。另外,一些度量是完全不可加的 ,例如 , 比率 。對非可加事實 ,一種好的方法是 ,盡 可能存儲非可加度 量的完全可加的分量 ,並在計算出最終的非可加事實前 ,將這些分 量匯 總到最終的結果集合中 。最終計算通常發生在 BI 層或 OLAP 多維數據庫層 。

以貸款業務爲例,還款事實表

  1. 還款金額爲可加
  2. 剩餘金額(應收-實收)爲半可加,統計截止本月底每個客戶的剩餘金額爲總剩餘金額,但是你把昨天的剩餘金額+今天的剩餘金額累加,這個就沒有什麼業務含義了。
  3. 還款達成的比例這個爲不可加。

1.3 事實表中的空值

  事實表中可以存在空值度量 。所有聚集函數(SUM 、COUNT 、MIN 、MAX 、AVG)均 可針對空值事實計算 。然而 ,在事實表的外鍵中不能存 在空值 ,否則會導致違反參照完 整 性的情況發生 。關聯的維度表必須用默認行(代理鍵)而不是 空值外鍵表示未知的或無法應 用的條件。

以貸款業務爲例,申請事實表
例如貸款產品的不同,有的產品要求客戶填寫月收入,用於風控決策分析,有的產品可不填。在設計事實表的時候,可以將此列設爲空,不影響分析申請某產品的客戶的平均月收入。

1.4 一致性事實

  如果某些度量出現在不同的事實表中 ,需要注意,如果需要 比較或計算不同事實表中 的事實,應保證針對事實的技術定義是相同的 。如果不同的事實表定義是 一致的 ,則這些 一致性事實應該具有相同的命名 ,如果它們不兼 容,則應該有不同的命名用於告訴業務用戶和BI應用。

以貸款業務爲例,賬戶週期快照表
有的事實表逾期金額的口徑是逾期已到期金額,有的事實表統計的口徑逾期客戶剩餘的所有金額,業務對比兩個口徑的數據的時候,就會發生異常。
在數據倉庫實時的過程中,同一個度量值由於統計口徑不同,到時數倉開發人員與業務人員反覆溝通確認數據,帶來極大的不便。所以在數據倉庫建模的過程中,對於度量值要做到統一,如出現類似的度量值,可以新增一個度量值,給事實表增加一列。

二. 事實表分類

維度建模數倉領域中的事實表大致分以下四種:

  1. 事務事實表
  2. 週期快照事實表
  3. 累計快照事實表
  4. 無事實的事實表
  5. 聚集事實表
  6. 合併事實表

稀疏表:當天只有發生了操作纔會有記錄
稠密表:當天沒有操作也會有記錄,便於下游使用

週期快照事實表的日期維度通常是記錄時間段的終止日,記錄的事實是這個時間段內一些聚集事實值。事實表的數據一旦插入即不能更改,其更新方式爲增量更新。

以貸款業務爲例,假設我有一個申請事實表,某一個日期沒有客戶申請,那麼申請事實表沒有該天的數據,而週期快照事實表,累計事實表有截止當天的快照數據。所以事務事實表可以是稠密的,也可以是稀疏的,週期快照事實表,累計快照事實表是稠密的,快照事實表的數據量是大於等於事務事實表。

2.1 事務事實表

  事務事實表的一行對應空間或時間上某點的度 量事件 。原子事務粒度事實表是維度化 及可表達的事實表 ,這類健壯的維度確保對事務數據的最大化分片和分塊 。事務事實表可 以是稠密的,也可以是稀疏的 ,因爲僅當存在度量時纔會建 立行。這些事實表總是包含 一 個與維度表關聯的外鍵 ,也可能包含精確的時間戳和退化維度鍵 。度量數字事實必須與 事 務粒度保持一致 。

以貸款業務爲例
申請事實表、還款事實表等都是事務事實表,而且事務事實表是事實表的基礎,快照表(週期快照和累計快照)都是基於事務實時表加工而來。

2.2 週期快照事實表

  週期快照事實表中的每行彙總了發生在某 一標準週期 ,如某一天 、某周 、某月的多個 度量事件 。粒度是週期性的 ,而不是個體的事務 。週期快照事實表通常包含許多事實 ,因 爲任何與事實表粒度 一致的度量事件都是被允許存在的 。這些事實表其外鍵的密度是均勻 的,因爲即使週期內沒有活動發 生 ,也會在事實表中爲每個 事實插入包含 0 或空值的行 。

以貸款業務爲例
因爲業務系統的數據是實時變化的,客戶還款數據的變化,會影響在庫和逾期的數據。而數據分析經常會統計截止某個時間點的靜態結算數據,例如賬戶的貸款餘額,所以會經常使用到週期快照事實表。

2.3 累積快照事實表

  累積快照事實表的行彙總了發生在過程開始和結束之間可預測步驟內的度 量事件 。管 道或工作流過程(例如 ,履行訂單或索賠過程)具有定義的開始 點,標準中間過程 ,定義的 結束點 ,它們在此類事實表中都可以被建模 。通常在事實表中針對過程中的關鍵步驟都包 含日期外鍵 。累積快照事實表中的 一行,對應某一具體的訂單 ,當訂單產生時會插入 一行。 當管道過程發生時 ,累積事實錶行被訪問並修改 。這種對累積快照事實錶行的 一致性修改 在三種類型事實表中具有特性 ,除了日期外鍵與每個關鍵過程步驟關聯外 ,累積快照事實 表包含其他維度和可選退化維度的外鍵 。通常包含數字化的與粒度保持 一致的 ,符合里程碑完成計數的滯後 性度量。

週期快照事實表記錄的是重複的可預測到的時間間隔的事實,例如帳戶月結餘事實表,用來記錄每個月末的帳戶結餘信息。一般週期快照的數據會按報表需要的週期進行記錄,比較適合週期長一些的情況。

而累計快照適用於較短週期,有着明確的開始和結束狀態的過程,如一個訂單執行的過程,並記錄過程中每個步驟的執行時間,使分析人員對執行的過程有整體的把握。週期快照事實表記錄上每個步驟的執行時間是逐步建立的,隨着執行的過程逐步更新的事實表中。

以貸款業務爲例
週期快照適用於貸後的賬戶,保存週期性的應還、實還、在庫餘額等信息。
累積快照適用於申請事實表,因爲截止某個週期,會存在很多在途(還未審批完成的訂單)的訂單,截止某個週期的數據要走到最終完結(例如審批通過或拒絕)才便於進行分析。

2.4 無事實的事實表

  儘管多數度量事件獲取的結果是數字化的 ,但也存在某些事件僅僅記錄 一系列某一時 刻發生的多維實體。例如 ,在給定的某 一天中發生的學生參加課程的事件,可能沒有可記 錄的數字化事實 ,但該事實行帶有 一個包含日曆天 、學生、教師、地點 、課程等定義良好 的外鍵 。同樣,客戶交際也是 一種事件,但沒有相關的度量 。利用無事實的事實表也可以 分析發生了什麼 。這類查詢總是包含兩 個部分 :包含所有可能事件的無事實覆蓋表 ,包含實際發生的事件的活動表 。當活動從覆蓋表中減除時,其結果是尚未發生的事件。

以貸款業務爲例
客戶註冊了APP,但是未提交貸款申請,此時註冊這個業務過程 有客戶的維度、時間維度、地域維度等,均可以用來分析客戶註冊這個業務場景,但是此時沒有可以度量的值,可以理解爲一個無事實的事實表。

2.5 聚集事實表或 OLAP 多維數據庫

  聚集事實表是對原子粒度事實表數據進行簡單的數字化上卷操作,目的是爲了提高查 詢性能。這些聚集事實表 以及原子事實表可以同時被 BI 層使用 ,這樣 BI 工具在查詢時可 以平滑地選擇適當的聚集層次 。這一被稱爲聚集導航的過程是開放的 ,以便報表製作者、 查詢工具 、BI 應用都能夠獲得同樣的性 能優勢。適當設計的聚集集合應該類似數據庫索引 , 能夠提高查詢性能 ,但不需要直接面對 BI 應用或商業用戶 。聚集事實表包含外鍵以縮小 一 致性維度 ,聚集事實的構建是通過對來自多 個原子事實表的度量的彙總而獲得的。最後 , 使用匯總而度量 聚集 OLAP 多維數據庫一般與關係類型的聚集方法類似 ,但是 OLAP 多維 數據庫可 以被商業用戶直接訪問 。

以貸款業務爲例
申請事實表是以申請單爲粒度,現在數據分析部門需要分析每個產品的批覈效率,此時我們可以根據申請單的產品進行彙總,將度量數據進行sum彙總,這樣會方便我們進行查詢。

2.6 合併事實表

  通常將來自多個過程的,以相同粒度表示的事實合併爲一個單一的合併事實表 ,這樣做能夠帶來方便 。例如 ,現貨銷售可以與銷售預測合併爲 一張事實表 ,與針對多個不同的 非實表採用下鑽應用 比較,這樣做可使對現貨及預測任務的分 析工作變得簡單快捷 。合併事實表會增加 ETL 處理過程的負擔 ,但降低了 BI 應用的分析代價 。合併事實表特 別適合 那些經常需要共同分析的多過程度量 。

三. 如何設計事實表

3.1 確定數據域

可以將數據域理解爲一個數據主題,比如門店、訂單、客戶等等,每一個主題下包含屬於該主題的業務過程,比如訂單主題下包含訂單的創建、無效等等業務過程。

3.2 選擇業務過程

業務過程通常用行爲動詞表示
業務過程通常由某個操作系統支撐,如賬單系統或者購買系統。
一系列業務過程產生一系列事實表
在設計事實表的時候,首先得知道這張事實表要記錄什麼事實,也就是說,對應的業務過程是什麼,是關於下單這個業務過程,還是支付或者購買之類的業務過程。

3.3 確定粒度

業務過程選定以後,就要針對每個業務過程確定一個粒度,即確定事務事實表每一行所表達的細節層次。(以“組織結構”爲例,比如一個層級結構式:總公司,分公司,部門,科室。這就是不同的粒度。)

確定粒度也可以理解爲你想設計的事實表中,每一行應該代表什麼。

如果選擇的業務過程是下單,並且我想觀察每個訂單的詳細情況,那麼粒度可以選擇爲訂單粒度,在下單業務過程中,最細的粒度應該就是訂單粒度。

對於事務表,一般都是從最細粒度構建。同時,上卷彙總粒度對性能調整來說非常重要。不同的事實表粒度,需要建立不同的事實表,比如訂單粒度和店鋪粒度的數據,不要在一張事實表中,在同一事實表中不要混用多種不同的粒度。

3.4 確定維度

維度一般用來解決如何描述事實表中每一行數據的問題。

維度信息一般是時間,地區,客戶等等,具體還要看對應的使用場景,當度量和維度進行關聯的時候,一條事實表的紀錄只能和對應的維度進行關聯,應該是1:1的關係。

3.5 確定事實

事實,也叫做度量或者指標,作爲事實表的核心,事實表應該包含與其描述過程有關的所有事實。

不同的業務過程擁有不同的事實,一個業務過程中,可能也有不同的度量,比如在下單業務過程中, 需要包含下單金額、下單數量、下單分攤金額等等;

屬於不同粒度的事實應該放在不同的事實表中。

3.6 冗餘維度

在確定維度時,我們確定了一些維度,但是Kimball維度建模理論建議在事實表中只保存這些維表的外鍵,一般我們會把一些維度退化、冗餘到事實表中,方便在事實表中進行統計,也爲下游使用這張事實表的時候不用再去關聯別的維度表,是一種以存儲空間換效率的做法。

四. 高級事實表技術

本節討論 的這些技術涉及不太 常見的事實表模式 。

4.1 事實表代理鍵

  代理鍵可用作所有維度表的主鍵 。此外 ,可使用單列代理事實鍵 ,儘管不太需要 。事實表代理鍵可用於:
①作爲事實表的唯一主鍵列;
②在ETL中,用作事實錶行的直接標識符 ,不必查詢多個維度 :
③允許將事實表更新操作分解爲風險更小的插入和刪除操作。

4.2 蜈蚣事實表

  一些設計者爲多對一層次的每層建立不同的規範化維度 ,例如 ,日期維度、月份維度 、 季度維度和年維度等 ,並將所有外鍵包含在 一個事實表中 。這將產生娛蛤事實表 ,包含與 維度相關的多個維度 。應該避免使用娛蛤事實表 。所有這些固定深度的 、多對一層次化關 聯的維度都應該回到它們最細節的粒度上 ,例如 ,上例中提到的日期 。當設計者將多個外 鍵嵌入到單一低粒度維度表中 ,而不是建立雜項維度時 ,也會產生娛蛤事實表 。

4.3 屬性或事實的數字值

  設計者有時會遇到一些數字值 ,難 以確定將這些數字值分類到維度表或是事實表的情況。典型的實例是產品的標準價格。如果該數字值主要用於計算目的,則可能屬於事實表 。 如果該數字值主要用於確定分組或過濾 ,則應將其定義爲維度屬性 ,離散數字值用值範圍屬性進行補充(例如 ,$0 50) 。某些情況下 ,將數字值既建模爲維度又建模爲屬性是非常有益的,例如,定量準時交貨度量 以及定性文本描述符 。

4.4 日誌/持續時間事實

  累積快照事實表獲取多個過程里程碑 ,每個都包含日期外鍵並可能包含日期/時間戳。 商業用戶通常希望分析這些里程碑之間的滯後及延遲時間 。有時這些延遲僅僅是日期上的差異,但某些情況下,延遲可能基於更復雜的業務規則 。如果流水線包含大量的步驟,則可能存在上百個延遲 。與其要求用戶查詢通過日期/時間戳或者日期維度外鍵計算每個可能存在的延遲,不如根據過程的開始時間點爲每個度量步驟存儲一個時間延遲 。這樣做可以方便地通過利用存儲在事實表中的兩個延遲,簡單地用減法計算任 何兩個步驟間可能存在 的延遲。

4.5 頭/行事實表

  操作型交易系統通常包括事務頭指針行 ,頭指針行與 多個事務行關聯 。採用頭/行模式(也稱爲父/子模式),所有頭指針級別維度外鍵與退化 維度應該被包含在行級別事實表 。

4.6 分配的事實

  頭指針/行事務數據與對應的 事實具有不同粒度這樣的情況經常發生 ,例如,頭表示貨運費用 。應該儘量分配頭指針事實 ,使其基於業務所提供的規則劃分爲行級別 ,分配的事 實可以按照所有維度進行分片井上鑽操作 。多數情況下,可避免建立頭指針級別的 事實表 , 除非這樣的聚集能夠獲得查詢性能的改善 。

4.7 利用分配建立利潤與損失事實表

  事實表揭示利潤等價方程是企業 DW/BI 應用能夠發佈的最強大的結果 。利潤方程是 :收入- 開銷 = 利潤。理想地實現利潤方程的事實表應爲原子收入事務粒度幷包含許多開銷項 。

  因爲這些表處於原子粒度 ,才能實現數字化的上卷 ,包括客戶利潤 ,產品利潤,促銷利潤 , 渠道利潤等 。然而 ,建立這些事實表存在一定難度 ,因爲開銷項必須從其原始來源劃分到 事實表粒度 。這一分配步驟通常由 ETL 子系統完成,這一過程是一個與業務相關的步驟 , 需要高層經理 的支持。出於以上原因 ,利潤與損失事實表通常在 DW/BI 程序的早期實現階 段不會被處理。

4.8 多種貨幣事實

  以多種貨幣單位記錄財務事務的事實錶行應該包含一對列 。其中一列包含以真實幣種表示的事實 ,另外列包含同樣的 ,但以整個事實表統一的單一標準幣種表示的事實 。標準幣種值在 ETL 過程中按照規定的貨幣轉換 規則建立。該事實表也必須有一個貨幣維度用 於區分事務的真正貨幣 。

4.9 多種度量事實單位

  某些業務過程需要事實 同時以多種度量單位表示 。例如 ,按照業務用戶的觀點 ,供應 鏈可能需要對相同事實 以平臺 、船運 、零售 以及單個掃描單元構建報表 。如果事實表包含 大量事實 ,而每個事實都必須以所有度 量單位表示 ,此時較好的方法是將 事實以公認的標 準度量單位存儲 ,同時存儲標準度量與其他度量的轉換系數 。這種事實表可按照不同用戶 的觀點部署 ,使用適當選擇的轉換系數 。轉換系數必須存儲在事實錶行中以確保計算簡單 正確,並儘量降低查詢複雜性 。

4.10 年-日事實

  商業用戶在事實表 中通常需要年-日(year-to-date, YTD)值 。很難反對單個請求 ,但是 YTD 請求很容易變 換爲 “ 財務週期結束時的 YTD ” 或者 “ 財務週期日”。一種更可靠 、可 擴展的處理這些請求 的方法是在 BI 應用或 OLAP 多維數據庫中計算 YTD 矩陣 ,而不是在 事實表 巾查出 YTD 事實。

4.11 多遍 SQL 以避免事實表間的連接

  BI 應用絕不應該跨事實表 的外鍵處理兩個事實表 的連接操作 。在關係數據庫中 ,控制 此類連接操作的回答集的基數是不可能 的,將會產生 不正確的結果 。例如 ,如果兩個 事實 表包含客戶產品 出貨和返回,則這兩個表不 能按照客戶和產品外鍵 直接連接 。要採用跨鑽 方式使用兩個事實表 ,井對結果按 照公共行頭指針屬性值 ,進行排序 融合操作以產生正確 結果。

4.12 針對事實表的時間跟蹤

  存在三種基本事實表粒度 :事務 級別、週期快照和累積快照。個別情況下 ,在事實表中增加行有效時期 、行截止日期和當前行標識是非常有用的 ,與採用類型 2 緩慢變化維度, 在事實行有效時獲取時間的方式類似。儘管不太常用 ,但該模型能夠解決諸如緩慢變化庫存平衡的場景,其中頻繁週期快照可以在每個快照上 加載同一行。

4.13 遲到的事實

  遲到事實是指如果用於新事實行的多數當前維度內容無法匹配輸入行的情況。這通常發生在當事實行延遲產生時 。在此情況下,當遲到度量事件出現時 ,必須搜索相關維度以發現有效的維度鍵 。

參考:

  1. 《數據倉庫工具箱 維度建模權威指南》第三版
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章