Presentation is loading. Please wait.

Presentation is loading. Please wait.

第3章 維度模型化介紹 許秉瑜.

Similar presentations


Presentation on theme: "第3章 維度模型化介紹 許秉瑜."— Presentation transcript:

1 第3章 維度模型化介紹 許秉瑜

2 現職 學歷 認證 國立中央大學(NCU)企管系 主任 國立中央大學(NCU)企管系 教授 中華企業資源規劃學會(CERPS) 秘書長
講師介紹 現職 國立中央大學(NCU)企管系 主任 國立中央大學(NCU)企管系 教授 中華企業資源規劃學會(CERPS) 秘書長 學歷 國立台灣大學(NTU)資訊工程系 美國紐約大學(NYU)資訊科學 碩士 美國加州大學洛杉磯分校 (UCLA)資訊科學 博士 認證 SAP Basis Consultant SAP BP ERP Consultant

3 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題
簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論

4 瞭解建置商業智慧系統 (BI) 時所需的維度模型之理論基礎。
學習目標 瞭解建置商業智慧系統 (BI) 時所需的維度模型之理論基礎。 瞭解為何匯流排架構 (Bus Architecture) 機制的存在是商業智慧系統 (BI) 建置過程中一個很重要且必須事先完成的工作。 瞭解維度模型中的顆粒度 (Granularity) 的重要性以及如何定義顆粒度。 瞭解在數種情境下如何建置維度模型。

5 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題
簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論

6 BI 系統的原始理想 BI系統設計理念 目前BI系統設計與使用方式 BI系統資料運作與呈現方式 簡介
所有主管都能自行製作與使用所需的決策報表(俗稱拉報表) BI系統設計理念 以直覺性的方式呈現資料 目前BI系統設計與使用方式 視覺化拖曳 (Drag & Drop) BI系統資料運作與呈現方式 欄位群組化(Group by) 加總(Sum)計算

7 圖3-1 以滑鼠拖曳方式的直覺化報表系統 回前頁

8 群組 加總 簡介 - 群組與加總的原理說明(I)
拉報表時,只要從維度資料表內挑選出來的欄位,BI 系統會針對這些欄位內容值相同者進行群組化 (Group by) 例如:由圖 3-1 下方的決策情報畫面中可看出,零售店維度資料表中的零售店區域欄位,產品維度資料表中的品牌描述欄位 加總 拉報表時,只要從事實資料表中挑選出來的欄位數值,會依群組進行加總 (Sum) 計算,並將群組與加總結果呈現到報表上 例如:由圖 3-1 下方的決策情報畫面中可看出,每日銷售事實資料表中的銷售量欄位與銷售額欄位

9 簡介 - 群組與加總的原理說明(II) 例如在圖 3-1 中的第一筆資料的第一個欄位值為北部第二個欄位值為 CF,則 BI系統會針對零售店區域值為北部且品牌描述值為 CF 的銷售量與銷售額進行加總,其彙總與計算過程等同是將圖 3-2 中的每日銷售事實資料表的第一筆與第三筆資料群組化與加總,所以最後得到北部且 CF 的銷售額為 $63 (= ),銷售量為 9 (= 4 + 5),以此類推即可以得到圖 3-1 中的所有結果。

10 圖3-2 群組與加總的基本原理 回前頁

11 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題
簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論

12 資料倉儲系統與維度模型 (Dimensional Model)
維度模型初探 資料倉儲系統與維度模型 (Dimensional Model) Dimensonal Model由Ralph Kimball在1997年提出 目前資料倉儲系統設計的主要工具

13 圖3-3 維度模型概示圖

14 維度模型初探---維度模型的特點 別稱—星狀綱要(Star Schema) 模型結構 事實資料表(Fact table)
環繞核心的光芒--維度資料表 (Dimension table) 事實資料表(Fact table) 唯一 可衡量(Measurement)數值績效統稱事實(Facts) 環繞核心的光芒--維度資料表(Dimension table) 允許數個 每一道光芒代表決策者觀察績效的角度,因此表格內所儲存的資料就是主管查看企業營運績效時所要的觀查的角度特色

15 圖3-4 維度模型範例 某企業經營績效的資料有銷售量與銷售額兩項事實。 企業主有興趣查看經營績效的角度有五個,分別為銷售時間、產品、客戶、訂單以及銷售員等五個維度資料表。

16 如何劃分維度呢? 維度模型初探 管理上的五個 W 及一個 H為分析角度 是誰 (Who)? 是什麼 (What)? 在何時 (When)?
在何地 (Where)? 為什麼 (Why)? 如何 (How)?

17 範例:如圖3-5 某製造業公司內部的訂單企業流程之維度模型
維度模型初探—5W1H範例 (I) 範例:如圖3-5 某製造業公司內部的訂單企業流程之維度模型 績效表現資料 (即事實資料) 有四個 分別為訂購數量、列項目金額、列項目折扣金額、列項目淨額 企業主有興趣觀看績效的角度 (即維度資料) 有十三個方向 其中與「是誰 (Who)」相關的維度有:下單客戶、付款客戶、收貨客戶、銷售員等維度。 與「是什麼 (What)」相關的維度是產品維度。 與「在何時 (When)」相關的維度有:需求提出日期以及訂單下單日期兩個維度。

18 維度模型初探—5W1H範例 (II) 與「在何地 (Where)」相關的維度是區域維度。 與「為什麼 (Why)」相關的維度是促銷維度。
與「如何 (How)」相關的維度有下單型態、付款方式、配送方式以及交易協議等維度。

19 圖3-5 訂單維度模型

20 維度模型的特點 維度模型初探 容易瞭解 (Understandability) 查詢快 (Query performance)
均衡的維度資料表 (Symmetric dimension tables) 可以容納非預期中的新資料 (Accommodate unexpected new data)

21 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題
簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論

22 維度模型工作的主要項目 事實資料表 辨別且擷取出可衡量 (Measurements) 的數值資料作為績效
辨別且擷取出情境化 (Context) 的文字敘述資料作為分析績效的角度

23 事實資料表 事實資料表的基本結構包含三個部分 事實資料表是一個擁有許多外來鍵的資料表,且每一個外來鍵會對應聯結到一個特定的維度資料表
第一部分 擁有一組對應聯結到維度模型中各個維度資料表的外來鍵 (Foreign Keys, FK);(例如圖 3-6 ) 第二部分 為一個或者多個數值型態的欄位用來儲存事實資料(例如圖 3-6 ) 第三部分 甚至可能包含一個或者多個退化維度 (Degenerate Dimensions, DD) 的欄位(例如圖 3-6 ) 事實資料表是一個擁有許多外來鍵的資料表,且每一個外來鍵會對應聯結到一個特定的維度資料表 在大部分狀況下,每筆事實資料表會連到每張維度資料表中的一筆資料 例如圖 3-6 中 POS 零售交易事實資料表的每筆資料都應聯結到產品維度以載明賣出的產品,同時聯結到日期維度中的某筆資料以說明銷售日期。

24 圖3-6 事實資料表的基本結構 回前頁

25 企業常見衡量績效的衡量值 (Measurements)
事實資料表 企業常見衡量績效的衡量值 (Measurements) 零售業的銷售量 倉儲業務的存貨量 採購業務的採購量 訂單管理業務的出貨量以及客戶退貨量 學校教育單位的學生缺席次數 預算業務的預算總金額 電信業的漫遊費以及長途電話費 電子商務網站的網頁點閱率以及網頁點閱停留秒數 保險業務的承保保費收入額 人力資源業務的休假天數累計

26 對於 BI 系統來說具有可加性(Additivity) 的數值才能記錄,依可加性數值資料可分三種類型:
事實資料屬性 對於 BI 系統來說具有可加性(Additivity) 的數值才能記錄,依可加性數值資料可分三種類型: 完整地可加性 (Fully additive) :例如銷售量、銷售額 半可加性 (Semi-additive) :例如金融銀行業的帳戶餘額 (Account balances)、公司倉儲業務中的存貨水準 (Inventory levels) 無可加性 (Non-additive) 的數值性資料:例如商品的單價 (Unit price)、氣象局所測到的溫度 (Temperature) 維度模型中的事實資料表應盡量只存放完整地可加性的數值資料項目,但在特殊業務需求下,也可開放存放其他項目資料。 Think

27 顆粒度 (Granularity) 是描述事實資料表中第二部分欄位的精細度,同一張表中所有衡量欄位都要有相同精細度
例如以銷售資料來說,常見的欄位有銷售量與銷售金額, 如果顆粒度是訂單中列項目 (Line item),則銷售數量與銷售金額都是指某個品項在某張訂單中的銷售數字。 相對的,如果顆粒度是訂單,則銷售金額與銷售量就是加總一整張訂單上的列項目所得的銷售量與銷售金額。 如果顆粒度是指一天的營業額則銷售量與銷售金額則是一整天訂單中的銷售量與銷售金額的加總。 Line Item Orders One day

28 事實資料表的顆粒度(II) 細 粗 儲存顆粒度設定較大或較粗,則事實資料表中資料量會變少,但是較細的資料就查詢不到
例如最細資料只儲存到部門營業額,就無法提供訂單交易的數據報表 相反的,如果儲存顆粒度設定較小或較細,雖然有較精細的報表資料可以提供查詢,但是事實資料表中的資料量會很龐大 例如連鎖超市如記錄到每個售出的品項,或者電信業者,記錄到每一通電話

29 在實務上,如果資料量不太大,建議以顆粒度最細的方式儲存資料。
事實資料表的顆粒度(III) 在實務上,如果資料量不太大,建議以顆粒度最細的方式儲存資料。 在設計多維度資料模型時,一旦將顆粒度確認下來後就不可以再更改,否則會造成查詢結果錯誤。 原則上顆粒度不同的資料不可以放在同一事實資料表中。

30 圖3-7 列項目銷售記錄狀況 假設圖 3-7 的銷售數量與銷售金額的顆粒度大小定義都來自列項目,因此該圖的顆粒度為列項目,而且第一筆與第二筆來自第一張訂單,第三筆與第四筆來自第二張訂單。如果將此四筆銷售金額資料加總即可得到此兩張訂單的總業績為 290 (= )。

31 圖3-8 顆粒度包含列項目與訂單的銷售記錄狀況
圖 3-8 為顆粒度定義不一致的狀況。銷售數量的顆粒度大小定義仍然為列項目,但銷售金額的顆粒度定義為訂單。此時如將銷售金額加總可以發現總業績卻變成 580 (= ),會產生過高的業績。

32 圖3-9 銷售訂單範例 在維度模型中顆粒度定義一旦確認後,不只影響事實資料表的欄位成員,也會影響維度模型中該放置哪些適合該顆粒度的維度資料表,適合該顆粒定義的留在維度模型中,不適合的維度資料表則剔除。原則上會造成事實資料表顆粒度變小的維度資料表就不能加入模型中。

33 圖3-9 銷售訂單範例

34 銷售訂單中有5個欄位可以成為事實資料欄位,分別為訂單總金額、總重量、訂購數量、單價金額、小計。
圖3-9 銷售訂單範例 -- 解析說明 銷售訂單中有5個欄位可以成為事實資料欄位,分別為訂單總金額、總重量、訂購數量、單價金額、小計。 如果顆粒度為整張訂單 (Entire sales orders) ,則上述的五個欄位中最後只剩下訂單總金額與總重量。 合適維度資料表有7個,分別為訂單號碼、買方編號、收貨人編號、請求交貨日期、下單日期、付款條件編號、國貿條件。 請注意:訂單明細資料中的物料編號屬於列項目 (Line items),比訂單的顆粒度小,所以被剔除。

35 交易事實資料表 (Transaction fact tables)
最常見的事實資料表,交易事實資料表內容記錄著交易 (或事務) 活動發生時候,活動內容中可以衡量的數值性的資料,如下圖所示。

36 週期快照事實資料表 (Periodic Snapshot fact tables)
有些企業流程中的活動內容所產生的可以衡量的數值性資料並不適合記錄詳細的交易內容 例如銀行的帳戶餘額 (Account balance)、財會部門的財務報表 (Financial reports)、倉儲單位的存貨水準 (Inventory levels),這些事實資料都屬於半可加性 (Semi-additive) 的可衡量的數值性資料,在維度模型中記錄詳細的半可加性事實資料的增加或減少的變動對企業主而言是比較沒有實際上幫助。 上述問題的解決方法就是每隔一段固定時間取值,猶如用照相機擷取影像的方式來記錄事實資料,換言之就是把週期的期末狀況顯示出來一樣,就好像每一個月月底所收到的各式各樣的帳單 (Bills) 內的數字一樣,此稱為週期快照 (Periodic snapshots)。

37 週期快照事實資料表 (Periodic Snapshot fact tables)
此處舉出一個範例如圖 3-10 所示,以月為單位的零售店庫存週期快照維度模型,譬如使用在庫數量 (Quantity on hand) 來表達存貨水準。

38 圖3-10 零售店庫存週期快照維度模型 回前頁

39 週期快照事實資料表 (Periodic Snapshot fact tables)
日期維度資料表記載週期終止時間 在此終止時間的當下記錄的事實資料就是這週期時間內的彙總數值 至於固定多少時間為一個週期單位必須事先決定,可以設定為每天 、每週 或每月 ,但是顆粒度一定要在照相到相同的資料層次上 建立週期快照事實資料表的目的 週期快照事實資料表中資料量會比交易事實資料表少 查詢速度較快

40 累積快照事實資料表 (Accumulating snapshot fact tables)
企業流程是由許多串連活動的執行而組成,執行中的一個活動或是一個步驟是被認定為可以獨立建立一個維度模型的最適當的基本單位 譬如訂單生產 (Make-to-order) 型態的製造業其核心流程為訂單管理流程 (Ordermanagement process) 或稱為訂單履行流程 (Order fulfillment process),如圖 3-11 所示會經過 6 個企業活動,分別為 客戶下訂單 (Customer order) 未完成訂單處理 (Order backlog) 製令發放 (Manufacturing release) 成品庫存(Finished goods inventory) 裝載出貨 (Shipping) 開立發票 (Invoicing)

41 圖3-11 訂單履行流程與累積快照事實資料表 如上圖中所示有 6 個記錄時間的欄位,為了解說方便以真實日期資料填入,但系統實作時是以數值型態的代理鍵填入,累積快照事實資料表的適用時機為不確定時間間距的企業活動,但是會清楚定義企業流程的開端活動與結束活動 例如訂單履行流程的開端活動為客戶下單,結束活動為開立發票。

42 累積快照事實資料表 (Accumulating snapshot fact tables)
整個訂單管理流程中的每一個步驟都可以建立一個專屬的維度模型提供企業主管使用 即可以為每一個活動步驟建立一個維度模型 但是公司的銷售主管或負責訂單的專案經理人 (Project manager, PM) 需要有一種可以記錄整個企業流程步驟的事實資料表, 以便時時可以注意到跨步驟或跨活動資訊來掌握全面性資訊, 這樣的事實資料表稱為累積快照事實資料表 (Accumulating snapshot fact tables)。 累積 (Accumulating) 一詞的意思就是指這些事情 (活動、步驟、事件) 不會在同一時間完成,因此必須透過許多記錄時間的欄位。

43 儲存在事實資料表中的可衡量事件可區分成三種基本型態
事實資料表內的顆粒的基本型態 儲存在事實資料表中的可衡量事件可區分成三種基本型態 交易事實資料表 (Transaction fact tables) 週期快照事實資料表 (Periodic Snapshot fact tables) 累積快照事實資料表 (Accumulating snapshot fact tables)

44 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題
簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論

45 基本結構包含三個部分 維度資料表 第一部分 第二部分 第三部分
系統給定的代理鍵 (Surrogate keys, SK)(如圖 3-12 中的零售店序號) 第二部分 自然鍵 (Natural keys, NK) 欄位,這些號碼主要是幫助作業人員容易辨識但因常含有文字類型資料,因此會造成資料查詢速度變慢(如圖 3-12 中的零售店代號) 第三部分 一個或多個描述性欄位 (Descriptive fields),主要以文字型態呈現資料(例如業務員名稱、客戶名稱、產品名稱) ,但有時也有離散型的數值型態的資料(例如訂單編號、出貨單號、採購單號)

46 圖3-12 維度資料表的基本結構 回前頁

47 通常維度資料表中的欄位數會比事實資料表中的欄位數多
維度資料表中各個欄位存在的目的 主要是輔助說明事實表中各列衡量值 通常維度資料表中的欄位數會比事實資料表中的欄位數多 維度資料表的各個欄位內的資料相對於事實資料表中的事實資料是屬於比較不常改變或即便改變其變化的頻率屬於比較慢,就是偶爾才發生改變的資料,此稱為靜態性的資料。

48 描述性欄位(Descriptive fields)
維度資料表內這些欄位存在的主要目的有兩個 當作查詢的限制或篩選條件 (Query constraining/filtering) 方便縮小範圍查詢 當作查詢結果標示標籤 (Query result set labeling) 協助說明 圖 3-1 資料如只限制北部就會如圖 3-13 所示。

49 圖3-1 以滑鼠拖曳方式的直覺化報表系統 到下一頁

50 圖3-13 維度資料表欄位的作用

51 維度資料表中的欄位具有下列幾個特性: 描述性欄位 欄位名稱具詳盡性 (Verbose) 欄位值具描述性 (Descriptive)
欄位名稱盡量不厭其煩的用全文命名(中英文皆適用),且盡量要與所描述的事情內容一致 欄位值具描述性 (Descriptive) 欄位內容都是以文字化方式來描述企業流程上的 5 個 W 與 1 個 H 資料具完整性 (Complete) 如果欄位值有缺失,會造成該筆資料無法被查詢到,而使查詢結果產生誤差

52 圖3-14 發生缺失值而未修改的情形 回前頁

53 圖3-15 有缺失值加總錯誤的情形 回前頁

54 代理鍵與自然鍵的差別

55 代理鍵與自然鍵的差別 自然鍵通常來自來源系統 (Source system)
自然鍵在這些系統上常常要配合人類識別方便會加上英文或中文字母,而代理鍵則由 BI 系統產生並完全以數字代表 代理鍵才是維度資料表的主鍵 使用代理鍵在實務上有很多利益 查詢效率 (Performance) 整合不同來源系統的自然鍵 提供穩定的鍵值 鍵值不可是虛值 (Null values) 如圖 3-16 所示 可以追蹤維度屬性值的變動 (Track changes in dimension attribute values) 維度資料也可能會緩慢地變動 覆蓋方式會喪失歷史資料,而有可能產生查詢錯誤 後續 節變動緩慢維度議題中的第二種型態設計方法中會說明

56 圖3-16 維度資料表的主鍵特性—代理鍵 (SK) vs.自然鍵 (NK)
回前頁

57 一致的維度 在 BI 系統中,通常會建立不同的維度模型來表達不同的企業流程,但在模型化的過程中,不同的維度模型可能會使用到相同的維度資料表,圖 3-17 所示 為三個企業流程分別建置三個維度模型,會有三個事實資料表,而這三個事實資料表剛好都需要聯結產品維度資料表,因此這三個維度模型所使用到的產品維度資料表「內容都相同」 「內容都相同」指的是要有 相同的主鍵欄位 (Keys)、 相同的欄位名稱 (Attribute/Field names)、 相同的欄位定義 (Attribute/Field definitions)、 相同的值域 (Domain values) 內容, 如果上述項目都確認過沒問題,則稱這三個維度模型的產品維度資料表是一致的 (Conformed)

58 圖3-17 已經確認過的維度資料表(Conformed dimensions tables)的概念
回前頁

59 如圖 3-18 所示,產品維度資料表 2 中多了一個欄位,與產品維度資料表就不是一致的資料表。
一致的維度 一致的維度有兩層含意 欄位相同 資料也都相同 如圖 3-18 所示,產品維度資料表 2 中多了一個欄位,與產品維度資料表就不是一致的資料表。

60 圖3-18 無法成為一致的維度資料表的原因 回前頁

61 維度資料表間除了可以有的一致性的關係外,還可有縮減的一致性關係(Conformed shrunken dimension)
一致的維度 -- 縮減的關係 維度資料表間除了可以有的一致性的關係外,還可有縮減的一致性關係(Conformed shrunken dimension) 原來的維度資料表有時會因用在顆粒度較大的模型中而產生欄位縮減的情形。 這縮減過後的維度資料表與原資料表間有縮減的一致性 如圖 3-19 所示,原來的維度模型的顆粒定在產品層次上,所以產品維度資料表有 9 個適合的欄位,但是如果將顆粒度設定在品牌層次上,則可發現產品序號、SKU 代號、顏色以及尺寸等 4 個屬性欄位因為顆粒度不在品牌層次上,所以不會在品牌維度資料表中出現,等同縮減了 4 個屬性欄位,如圖 3-20 所示。圖中的品牌維度資料表與圖 3-19 的產品維度資料表有縮減後的一致性關係。

62 圖3-19 顆粒度為產品層次的產品維度資料表 vs. 圖3-20品牌維度資料表與產品維度資料表有縮減後的一致性
Grain:產品 shrunken Grain:品牌 回前頁

63 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題
簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論

64 Kimball’s Architecture
Data Staging Area Data Presentation Area Data Access Tools Operational Source Systems Load Access Query Tools Data mart #1 Service Report Writers Extract Analytic App. DW Bus Data Store Conformed facts & dimensions Modeling: Forecasting Scoring Data Mining Load Access Processing Data mart #2 回前頁

65 無法整合的最大原因為各部門用的模型中會有資料同名異義 (Polysemy) 與異名同義 (Synonymy) 的問題。
建立資料倉儲匯流排架構(I) 無法整合的最大原因為各部門用的模型中會有資料同名異義 (Polysemy) 與異名同義 (Synonymy) 的問題。 例如兩個不同部門的維度模型都使用庫存量來代表企業的庫存,但其中 A 部門的庫存量包含在途量,另 B 部門的庫存量並未包含在途量,因此就會造成同樣名稱的事實欄位卻在報表上有不同的數字。如果這兩個部門的報表被拿來相互比較就會出現令人非常困惑的狀況。 另一種情況如果 X 部門用訂單量來代表銷售量,而另一個 Y 部門用銷售量,則這兩部門的報表如放在一起被討論會產生另一種困惑—如果兩個欄位意義一樣為何不能只用一個名字,如果意義不同為何數字都一樣。

66 企業須成立一個單位掌控整體性的 BI 系統的資料架構來達成資訊傳遞的一致性
建立資料倉儲匯流排架構(II) 為了解決資料同名異義與異名同義,Kimball 建議需要事先建立資料倉儲匯流排架構 (Data warehouse bus architecture)。 企業須成立一個單位掌控整體性的 BI 系統的資料架構來達成資訊傳遞的一致性

67 如圖 3-21 所示,所有可用的維度資料表與事實欄位都在匯流排中占有一條渠道,而各部門所需的維度模型就在排線上根據所需擷取資料
建立資料倉儲匯流排架構(III) 如圖 3-21 所示,所有可用的維度資料表與事實欄位都在匯流排中占有一條渠道,而各部門所需的維度模型就在排線上根據所需擷取資料 圖 3-21 上有三個維度模型在匯流排架構上,以採購訂單維度模型為例,它的接角插在採購量、日期、產品、倉儲、採購商與訂貨商上,因此它會與零售店庫存維度模型分享日期與產品兩個維度資料表 經由使用同一匯流排,就可使各部門分享相同的資料欄位與資料表而避免同名異義 匯流排上所有事實資料與維度資料表的設計如都透過一個單位掌控,就可進一步避免異名同義的問題 採用此法各維度模型中的同名維度資料表有一致 (Conformed) 的關係 在模型設計過程,除了維度資料表要一致外,事實欄位也要一致,而運用資料倉儲匯流排架構可達到此目標。

68 圖3-21 BI系統的匯流排架構 回前頁

69 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題
簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論

70 日期或時間是每一個維度模型都會有的維度資料表 詳細的日期與時間資料對於人類來說是一件非常錯綜複雜的事情
日期與時間的設計(I) 日期或時間是每一個維度模型都會有的維度資料表 詳細的日期與時間資料對於人類來說是一件非常錯綜複雜的事情 在記錄詳細的日期與時間資料時,一個比較完整的描述方式是「年/月/日 時:分:秒」 譬如 2009/10/2913:15:40, 2009/10/29 稱為日期 (Date) 資料,13:15:40 則稱為時間(Time) 資料 此外,還有許多其他記錄日期與時間資料的表示方式 譬如農曆日期、會計年度日期、今天是今年第幾天、今天是第幾旬、今天的氣候、今天的節氣、是否為例假日等

71 有些系統必須儲存到秒 (Sceond) 的資料,例如捷運控制系統、人造衛星系統、網管系統等
日期與時間的設計(II) 有些系統必須儲存到秒 (Sceond) 的資料,例如捷運控制系統、人造衛星系統、網管系統等 有些系統需要儲存到分 (Minute) 的資料,例如銀行 ATM 提款系統 另外,有些系統甚至將日期與時間資料當作可以加總的數值資料處理,例如生產排程系統中記錄工作站每件完成所花費的時間 詳細的日期與時間資料可以當作維度資料,也可以當作事實資料,因此分成兩個重點部份來描述 日期維度資料 (Date dimensions) 時間資料 (Time of day)

72 日期維度資料 (Date dimensions)
每一個維度模型中,日期維度資料表是維度模型中一定會有的一個資料表 如圖 3-22 所示,因為事實資料表中的每一筆資料都必須記錄下可衡量資料所發生的日期。 每一個事實資料表通常都會對應到一個或多個日期維度資料表

73 圖3-22 日期維度資料表 回前頁

74 時間資料指的是事件發生時精準的時刻,可能須精準到秒
時間資料 (Time of day) 時間資料指的是事件發生時精準的時刻,可能須精準到秒 以出貨業務來說,一般只記錄到出貨日期,但如果沒儲存當天時間資料,則無法分析白天與晚上出貨狀況有何差別 因此如果有需要,日期資料以及時間資料都可被記錄保留下來。 但是如果放在同一張維度資料表中,會產生太多筆的資料

75 時間資料 (Time of day) 在此介紹兩種設計方式可以達到同樣效果但又不需儲存大量筆數的資料。
日期與時間維度資料表各自獨立,直接與事實資料表連接,如圖 3-23 所示。 將時間資料存在事實資料表中,將時間資料轉換成數值資料如圖 3-24 所示。 第二個方法的應用大部分都是在記錄某一個工作任務的開始時間與結束時間之間的間隔,因此這一個額外在事實資料表中的數值時間資料是可以被相減的,但是不能相加,因此只能算是無可加性欄位。 另外,如果將時間當作事實資料看待,例如完成一件工作或任務所花費的時間間隔 (Time interval)就可以將間隔放入事實資料表 通常時間間隔會等於(完成時間 − 開工時間)

76 圖3-23 日期與時間維度資料表的第一種建置方法
回前頁

77 圖3-24 日期與時間維度資料表的第二種建置方法
回前頁

78 交易控制文件 (Transaction control document)
例如訂單 (Order)、發票 (Invoice)、提貨單 (Bill of lading)、機票 (Airline ticket) 這些控制文件相當於一筆交易,而交易內容可能包含單一品項或者多個列項目,可參考圖 3-9 中的範例。 模型化過程很容易就將該類文件中的各項資料分類好並且歸納到適當的維度資料表中,除了一個相當尷尬的訂單維度資料表,這表中除了訂單編號欄位之外別無其他欄位,如圖3-25所示

79 圖3-9 銷售訂單範例 回前頁

80 圖3-25 訂單事實資料表 回前頁

81 圖3-25的維度模型中,這樣的維度資料表並沒有邏輯上的錯誤,只是資料有點少。
退化維度(II) 圖3-25的維度模型中,這樣的維度資料表並沒有邏輯上的錯誤,只是資料有點少。 解決方法 可將訂單編號直接納入事實資料表中,原來的訂單維度資料表則不再需要,訂單維度資料表因為被收到事實資料表中因此稱為退化維度 (Degenerate Dimensions, DD),如圖3-26所示 雖然此欄位在事實資料表中無可加總性,但可用以篩檢同一筆訂單的交易資料

82 圖3-26 涵蓋退化維度 (DD) 資料的維度模型 回前頁

83 變動緩慢的維度資料表記錄方式 對 BI 系統特性的定義中曾提到資料的不可修改性 (Non-volatile)
在實務上,企業經營的真實狀況一定多多少少會隨著時間而需要改變維度資料,只是改變速度比較緩慢一點 譬如:客戶的就業狀況可能三年一變、客戶的薪資等級可能會半年一變、客戶也可能會搬離現址…等 假如很嚴格地限制載入到 BI 系統中的資料就不可以變更,則 BI 系統紀錄的資料會與事實脫節 為了守住Inmon的原則,要求客戶不可以變更地址或不准客戶搬家!! 為了讓整個維度模型不要有太多的更動,Kimball 提出三種對應的處理方法,又因為這些資料並不是經常性在變更,所以稱這類更動頻率不是很高的維度資料為變動緩慢維度 (Slowly changing dimensions, SCD)

84 在此舉一個客戶維度資料表中客戶之搬家的範例,如圖 3-27 所示,
變動緩慢的維度資料表記錄方式 緩慢改變的維度資料表處理方式 直接改寫維度屬性資料 (Type I) 新增加一筆維度資料 (Type II) 新增加一個維度屬性 (Type III) 在此舉一個客戶維度資料表中客戶之搬家的範例,如圖 3-27 所示, 原先在客戶維度資料表中有三個客戶,C1 客戶張三的地址為四維路 12 號,後來張三搬家了,新的地址為大同路 5 號,該如何處理呢?接下來針對前述三種不同處理方法做說明。

85 圖3-27 客戶資料尚未處理變動的客戶維度資料表
回前頁

86 圖3-28 直接改寫後的客戶維度資料表 回前頁

87 圖3-29 新增一筆資料後的客戶維度資料表 回前頁

88 圖3-31 新增一個欄位後的客戶維度資料表 回前頁

89 當維度資料有更動時,在理論上第二型技術的方法最好,但是此技術卻不適合使用在龐大且經常變動的維度資料表中。
新增資料到大維度資料表 當維度資料有更動時,在理論上第二型技術的方法最好,但是此技術卻不適合使用在龐大且經常變動的維度資料表中。 所謂的大型維度資料表是指維度資料表中欄位數目很多,通常超過 150 且維度資料表中的筆數也很多,通常是數以百萬計,如圖 3-32 所示。 在變動快速龐大型維度資料表環境下使用第二型技術來追蹤過去維度資料所有的歷史資料會造成資料筆數大量增加,而使原來資料筆數就很多的大維度資料表的情況雪上加霜。 解決方法就是分離 (Break off) 原來維度資料表中經常改變維度屬性值的欄位

90 圖3-32 變動快速龐大型維度資料表 回前頁

91 新增資料到大維度資料表 分離 (Break off)技術 從原來的龐大型維度資料表中找出值較常改變的欄位,並將其安排到另一個維度資料表,並將此表直接與事實資料表相聯結 這一個被分離開且規模較小的維度資料表稱為迷你維度資料表 (Mini-dimension table) ,如圖3-33所示。 迷你維度資料表技術可以很容易在快速龐大型維度資料表環境中追蹤歷史變動的資料,但是分離技術的過程中如何讓迷你維度資料表技術更有效率,則需要有配套措施。相關主要配套措施有三種方式 帶狀值 (Banded values) 嚴格限制成長 (Restricted growth) 分離核心維度 (Separation from core dimension)

92 圖3-33 迷你維度資料表 回前頁

93 帶狀值 (Banded values) 新增資料到大維度資料表
例如圖 3-32中客戶年收入本來為一數值,且變動很快,如果將年收入改成三個等級,等級 A 為 210,000~400,000,等級B 為 410,000~600,000,等級 C 為 610,000~800,000,高中低如此帶狀式的級距化轉換可以讓經常變動的年收入狀況穩定下來 範例中的 7 個人口統計資料欄位,假設每一個欄位有 5 種可能值,則迷你維度資料表中僅會產生 57 (=78125) 筆資料,與龐大維度資料表中數百萬筆的資料量相較之下可看出資料量小很多。

94 嚴格限制成長 (Restricted growth)
新增資料到大維度資料表 嚴格限制成長 (Restricted growth) 當第一次分離出一個迷你維度資料表時,如果迷你維度資料表的資料量還是成長很快,則需要進行第二次分離,另外成立第二個迷你維度資料表(Second mini-dimension table) 例如客戶人口統計維度資料表中可以將消費與信用人口統計欄位再次分離出來,如圖 3-34 所示,如此可以再次降低維度資料變動所產生的資料量。

95 圖3-34 兩次分離的迷你維度資料表 回前頁

96 分離核心維度 (Separation from core dimension)
新增資料到大維度資料表 分離核心維度 (Separation from core dimension) 隨著時間改變,客戶人口統計資料也會在迷你維度資料表中緩慢地增加,由於客戶維度資料分別儲存在不同的兩個維度資料表中,如此會造成查詢的複雜度,因此可在客戶維度資料表中複製一份最新的人口統計資料,如圖 3-35 所示,可以增加查詢效率。

97 圖3-35 最新客戶人口統計資料儲存兩份 回前頁

98 迷你維度資料表可能無法與原來的維度資料相連
新增資料到大維度資料表 迷你維度資料表可能無法與原來的維度資料相連 即兩個維度資料表必須經由事實資料表才能聯結,而原來合在同一維度資料表上時並無這問題。 客戶的人口統計資料只有在產生消費後才能與客戶產生關聯。 建議新增空的交易資料來處理。

99 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題
簡報大綱 學習目標 3.1 簡介 3.2 維度模型初探 3.3 事實資料表 3.4 維度資料表 3.5 匯流排架構 3.6 維度模型的其他特殊議題 3.7 結論

100 本章主要介紹建置 BI 系統所需使用到的資料模型理論基礎
Dimensional Model 事實資料與維度資料表 確定每一個維度模型的顆粒度,不同顆粒度的事實資料要放在不同維度模型中 如建多部門資料超市,則需建構一致的維度 (Conformed dimensions) 資料與事實 (Conformed facts) 資料

101 結論(II) 規劃維度資料表時盡量使用代理鍵 (Surrogate key) 機制當主鍵,避免後續不必要的更動
時間維度可獨立儲存或縮減成數值儲存到事實資料表 變動緩慢的維度邏輯上以第二型處理最好

102 整合產官學研資源,協助華人地區推動以ERP為基礎的企業e化。
   ERP學會簡介 本會於91年1月26日成立。 使命:  整合產官學研資源,協助華人地區推動以ERP為基礎的企業e化。 目標:藉由統合與發展知識 協助廠商提高e化效率 協助軟體公司發展適合華人e化軟體 協助台灣成為華人地區最佳e化顧問供應地

103 企業面臨狀況 需有單位培養龐大且優質的人力資源 認證起緣 眾多的企業、軟體與顧問公司無法找到有企業e化核心知識的管理人才
台灣有獨步華人地區的製造業管理與運籌知識, 但利用此知識創造的服務產業還有很大成長空間 需有單位培養龐大且優質的人力資源

104 BI檢定考試結構 規劃師與應用師為企業內種子人員

105 中大ERP中心網站:www.erp.ncu.edu.tw 學會網站:www.cerps.org.tw
聯絡資訊 中大ERP中心網站: 學會網站:


Download ppt "第3章 維度模型化介紹 許秉瑜."

Similar presentations


Ads by Google