資料倉儲專題(7) 維度建模10大基本原則

2021-09-06 22:55:59 字數 2523 閱讀 7555

一、前言

特別宣告:本文整理自網際網路。

遵循這些原則進行維度建模可以保證資料粒度合理,模型靈活,能夠適應未來的資訊資源,違反這些原則你將會把使用者弄糊塗,並且會遇到資料倉儲障礙。

二、正文

原則1、載入詳細的原子資料到維度結構中

維度建模應該使用最基礎的原子資料進行填充,以支援不可預知的來自使用者查詢的過濾和分組請求,使用者通常不希望每次只看到乙個單一的記錄,但是你無法** 使用者想要掩蓋哪些資料,想要顯示哪些資料,如果只有彙總資料,那麼你已經設定了資料的使用模式,當使用者想要深入挖掘資料時他們就會遇到障礙。當然,原子數 據也可以通過概要維度建模進行補充,但企業使用者無法只在彙總資料上工作,他們需要原始資料回答不斷變化的問題。

原則2、圍繞業務流程構建維度模型

業務流程是組織執行的活動,它們代表可測量的事件,如下乙個訂單或做一次結算,業務流程通常會捕獲或生成唯一的與某個事件相關的效能指標,這些資料轉換 成事實後,每個業務流程都用乙個原子事實表表示,除了單個流程事實表外,有時會從多個流程事實表合併成乙個事實表,而且合併事實表是對單一流程事實表的一 個很好的補充,並不能代替它們。

原則3、確保每個事實表都有乙個與之關聯的日期維度表

原則2中描述的可測量事件總有乙個日期戳資訊,每個事實表至少都有乙個外來鍵,關聯到乙個日期維度表,它的粒度就是一天,使用日曆屬性和非標準的關於測量事件日期的特性,如財務月和公司假日指示符,有時乙個事實表中有多個日期外來鍵。

原則4、確保每個事實表中的事實具有相同的粒度或同級的詳細程度

在組織事實表時粒度上有三個基本原則:事務,週期快照或累加快照。無論粒度型別如何,事實表中的度量單位都必須達到相同水平的詳細程度,如果事實表中的事實表現的粒度不一樣,企業使用者會被搞暈,bi應用程式會很脆弱,或者返回的結果根本就不對。

原則5、解決事實表中的多對多關係

由於事實表儲存的 是業務流程事件的結果,因此在它們的外來鍵之間存在多對多(m:m)的關係,如多個倉庫中的多個產品在多天銷售,這些外來鍵字段不能為空,有時乙個維度可以為 單個測量事件賦予多個值,如乙個保健對應多個診斷,或多個客戶有乙個銀行賬號,在這些情況下,它的不合理直接解決了事實表中多值維度,這可能違反了測量事 件的天然粒度,因此我們使用多對多,雙鍵橋接表連線事實表。

原則6、解決維度表中多對一的關係

屬性之間分層的、多對一(m:1)的關係通常未規範化,或者被收縮到扁平型維度表中,如果你曾經有過為事務型系統設計實體關係模型的經歷,那你一定要抵抗住舊有的思維模式,要將其規範化或將m:1關係拆分成更小的子維度,維度反向規範化是維度建模中常用的詞彙。

在單個維度表中多對一(m:1)的關係非常常見,一對一的關係,如乙個產品描述對應乙個產品**,也可以在維度表中處理,在事實表中偶爾也有多對一關係,如詳細當維度表中有上百萬條記錄時,它推出的屬性又經常發生變化。不管怎樣,在事實表中要慎用m:1關係。

原則7、儲存報告標記和過濾維度表中的範圍值

更重要的是,編碼和關聯的解碼及用於標記和查詢過濾的描述符應該**獲到維度表中,避免在事實表中儲存神秘的編碼欄位或龐大的描述符字段,同樣,不要只 在維度表中儲存編碼,假定使用者不需要描述性的解碼,或它們將在bi應用程式中得到解決。如果它是乙個行/列標記或下拉列表過濾器,那麼它應該當作乙個維度 屬性處理。

儘管我們在原則5中已經陳述過,事實表外來鍵不應該為空,同時在維度表的屬性欄位中使用「na」或另乙個預設值替換空值來避免空值也是明智的,這樣可以減少使用者的困惑。

原則8、確定維度表使用了**鍵

按順序分配**鍵(除了日期維度)可以獲得一系列的操作優勢,包括更小的事實表、索引以及效能改善,如果你正在跟蹤維度屬性的變化,為每個變化使用乙個 新的維度記錄,那麼確實需要**鍵,即使你的商業使用者沒有初始化跟蹤屬性改變的設想值,使用**也會使下游策略變化更寬鬆,**也允許你使用多個業務鍵映 射到乙個普通的配置檔案,有利於你緩衝意想不到的業務活動,如廢棄產品編號的**或收購另一家公司的編碼方案。

原則9、建立一致的維度整合整個企業的資料

對於企業資料倉儲一致的維度(也叫做通用維度、標準或參考維度)是最基本的原則,在etl系統中管理一次,然後在所有事實表中都可以重用,一致的維度在 整個維度模型中可以獲得一致的描述屬性,可以支援從多個業務流程中整合資料,企業資料倉儲匯流排矩陣是最關鍵的架構藍圖,它展現了組織的核心業務流程和關聯 的維度,重用一致的維度可以縮短產品的上市時間,也消除了冗餘設計和開發過程,但一致的維度需要在資料管理和治理方面有較大的投入。

原則10、不斷平衡需求和現實,提供使用者可接受的並能夠支援他們決策的dw/bi解決方案

維度建模需要不斷在使用者需求和資料來源事實之間進行平衡,才能夠提交可執行性好的設計,更重要的是,要符合業務的需要,需求和事實之間的平衡是dw/bi 從業人員必須面對的事實,無論是你集中在維度建模,還是專案策略、技術/etl/bi架構或開發/維護規劃都要面對這一事實。

三、未完待續

10 維度建模10大基本原則

一 前言 特別宣告 本文整理自網際網路。遵循這些原則進行維度建模可以保證資料粒度合理,模型靈活,能夠適應未來的資訊資源,違反這些原則你將會把使用者弄糊塗,並且會遇到資料倉儲障礙。二 正文 原則1 載入詳細的原子資料到維度結構中 維度建模應該使用最基礎的原子資料進行填充,以支援不可預知的來自使用者查詢...

維度模型資料倉儲(二) 維度模型基礎

一 維度模型基礎 既然維度模型是資料倉儲建設中的一種資料建模方法,那不妨先看一下幾種主流的資料倉儲架構。1.kimball的dw bi架構 圖 一 1 2.inmon企業資訊工廠架構 圖 一 2 3.混合型架構 圖 一 3 從圖中可以看出,每種架構中都有資料集市。資料集市就是面向終端使用者的資料庫。...

資料倉儲專題(22) 匯流排架構和維度建模優勢 雜項

一 匯流排架構 維度建模的資料倉儲中,有乙個概念叫bus architecture,中文一般翻譯為 匯流排架構 匯流排架構是kimball的多維體系結構 md 中的三個關鍵性概念之一,另兩個是一致性維度 conformed dimension 和一致性事實 conformed fact 在多維體系結...