1. 程式人生 > >數據倉庫--事實表和維度表

數據倉庫--事實表和維度表

需要 解釋 參考 gid 新的 www 多次 主外鍵 color

本文主要參考如下幾篇文章:
http://www.cnblogs.com/47613593/archive/2009/02/20/1394581.html
http://jackwxh.blog.51cto.com/2850597/827968

1.數據倉庫與操作型數據庫的區別

數據倉庫的物理模型與常見的操作型數據庫的物理模型有很大不同。最明顯的區別是:操作型數據庫主要是用來支撐即時操作,對數據庫的性能和質量要求都比較高,為了防止“garbage in,garbage out”,通常設計操作型數據庫的都要遵循幾個範式的約束,除非少數情況下為了性能進行妥協,才可能出現冗余;而數據倉庫的數據是來源於即時操作產生的數據,而不是直接來源於即時操作,所以它的數據質量是由操作型系統來保證的,而不是由幾個範式來保證的。而且為了更好的跟蹤歷史信息,以及更快的產生報表,數據倉庫的物理模型中存在著大量冗余字段。

2.事實表與維度表的基本概念

簡單的說維度表就是你觀察該事物的角度(維度);事實表就是你要關註的內容。
比如要分析產品銷售情況, 你可以選擇按產品類別來進行分析,或按時間來分析,這樣的按..分析就構成一個維度。這樣就有兩個維度:產品類別和時間。
下面是兩個維度表結構:
產品維度表:Prod_id, Product_Name, Category, Color, Size, Price
時間維度表:TimeKey, Season, Year, Month, Date

而事實表是數據聚合後依據某個維度生成的結果表,例如:

銷售事實表:Prod_id(引用產品維度表), TimeKey(引用時間維度表), SalesAmount(銷售總量,以貨幣計), Unit(銷售量)


事實數據和維度數據的識別必須依據具體的主題問題而定。“事實表”,用來存儲事實的度量(measure)及指向各個維的外鍵值。維表用來保存該維的元數據,即維的描述信息,包括維的層次及成員類別等

所產生的數據,事實數據表通常包含大量的行。事實數據表的主要特點是包含數字數據(事實),並且這些數字信息可以匯總,以提供有關單位作為歷史的數據,每個事實數據表包含一個由多個部分組成的索引,該索引包含作為外鍵的相關性緯度表的主鍵,而維度表包含事實記錄的特性。事實數據表不應該包含描述性的信息,也不應該包含除數字度量字段及使事實與緯度表中對應項的相關索引字段之外的任何數據。
包含在事實數據表中的“度量值”有兩種:一種是可以累計的度量值,另一種是非累計的度量值。最有用的度量值是可累計的度量值,其累計起來的數字是非常有意義的。用戶可以通過累計度量值獲得匯總信息,例如可以匯總具體時間段內一組商店的特定商品的銷售情況。非累計的度量值也可以用於事實數據表,單匯總結果一般是沒有意義的,例如,在一座大廈的不同位置測量溫度時,如果將大廈中所有不同位置的溫度累加是沒有意義的,但是求平均值是有意義的。
一般來說,一個事實數據表都要和一個或多個緯度表相關聯,用戶在利用事實數據表創建多維數據集時,可以使用一個或多個維度表。
維度表可以看作是用戶來分析數據的窗口,緯度表中包含事實數據表中事實記錄的特性,有些特性提供描述性信息,有些特性指定如何匯總事實數據表數據,以便為分析者提供有用的信息,維度表包含幫助匯總數據的特性的層次結構。例如,包含產品信息的維度表通常包含將產品分為食品、飲料、非消費品等若幹類的層次結構,這些產品中的每一類進一步多次細分,直到各產品達到最低級別。
在維度表中,每個表都包含獨立於其他維度表的事實特性,例如,客戶維度表包含有關客戶的數據。維度表中的列字段可以將信息分為不同層次的結構級。

3.事實表和維度表的設計原則


事實表是用來存儲主題的主幹內容的。以日常的工作量為例,工作量可能具有如下屬性:工作日期,人員,上班時長,加班時長,工作性質,是否外勤,工作內容,審核人。那麽什麽才是主幹內容?很容易看出上班時長,加班時長是主幹,也就是工作量主題的基本內容,那麽工作日期,人員,工作性質,是否外勤,工作內容是否為主幹信息呢?認真分析特征會發現,日期,人員,性質,是否外勤都是可以被分類的,例如日期有年-月-日的層次,人員也有上下級關系,外勤和正常上班也是兩類上班考勤記錄,而上班時長和加班時長則不具有此類意義。所以一般把能夠分類的屬性單獨列出來,成為維度表,在事實表中維護事實與維度的引用關系。

總的來看,和其他建立主外鍵關系的表也都一樣。但是維度表的建立是需要有層次的(雖然不是必須,但是也是典型特征),而事實表的建立是針對已經發生的事實的,是歷史數據的存檔,也就是說是不應該修改的。以測試部測試軟件的Bug為例。每個Bug都是一個事實。這個Bug的狀態在數據字典裏可能設計成新建,轉派,修復,拒絕等等。那麽在事實表中Bug表中有一個字段為Status。當測試員或者開發人員改變了這個狀態的值,事實表中該如何更新呢?是直接更新Status還是什麽其他的方式?顯然,為了能夠追蹤這個Bug的歷史信息,應該是重新插入一條新的記錄。那麽這和以往的數據庫設計有什麽區別呢?可以看出對於原始記錄和新插入的記錄,其他字段全部是相同的,也就是全部冗余的。如果以BugID作為主鍵,這時候會發現主鍵都是冗余的(當然,插入之前只能刪除主鍵)。所以可以看出,事實表一般是沒有主鍵的。數據的質量完全由業務系統來把握。

維度表一般是有主鍵的,代表該類物質的一個單一個體,其他的字段一般都是有層次關系的。例如2009年2月19日是主鍵,那麽它會有年--月--日這樣的層次,為了方便統計,年月日不會在做聚合的時候才計算出來,而是在維護記錄時已經計算出來。那麽這些字段的冗余是否值得呢?可以這樣解釋:維度表的數據一般是比較少的,這個少是指相對事實表來講的。因為事實表是與日俱增,而維度表則增長緩慢,所以絕對數字也不會太大。假如要做一個group by Year(TimeKey),那麽在事實表和維度表做連接查詢的時候,會產生與事實表一樣大的數據量;如果沒有這些維度表的分層,那麽其一是會增加計算(需要根據時間字段去取出年份),其二是由於引入了計算,索引會失效。這個代價比引入冗余字段要大的多。

維度表的主鍵一般都取整型值的標誌列類型,這樣也是為了節省事實表的存儲空間.
---------------------
作者:時時處處皆修行
來源:CSDN
原文:https://blog.csdn.net/davidwang9527/article/details/25553117
版權聲明:本文為博主原創文章,轉載請附上博文鏈接!

數據倉庫--事實表和維度表