原文地址:https://blog.csdn.net/u013614451/article/details/42552995
維度表示你要對數據進行分析時所用的一個量, 比如你要分析產品銷售情況, 你可以選擇按類別來進行分析,或按區域來分析. 這樣的按..分析就構成一個維度。前面的示例就可以有兩個維度:類型和區域。另外每個維度還可以有子維度(稱為屬性),例如類別可以有子類型,產品名等屬性。
下面是兩個常見的維度表結構:
產品維度表:Prod_id, Product_Name, Category, Color, Size, Price
時間維度表:TimeKey, Season, Year, Month, Date
而事實表是數據聚合后依據某個維度生成的結果表。它的結構示例如下:
銷售事實表:Prod_id(引用產品維度表), TimeKey(引用時間維度表), SalesAmount(銷售總量,以貨幣計), Unit(銷售量)
上面的這些表就是存在於數據倉庫中的。從這里可以看出它有幾個特點:
1. 維度表的冗余很大,主要是因為維度一般不大(相對於事實表來說的),而維度表的冗余可以使事實表節省很多空間。
2. 事實表一般都很大,如果以普通方式查詢的話,得到結果一般發的時間都不是我們可以接受的。所以它一般要進行一些特殊處理。如SQL Server 2005就會對事實表進行如預生成處理等。
3. 維度表的主鍵一般都取整型值的標志列類型,這樣也是為了節省事實表的存儲空間。
事實表和維度表的分界線
事實表是用來存儲主題的主干內容的。以日常的工作量為例,工作量可能具有如下屬性:工作日期,人員,上班時長,加班時長,工作性質,是否外勤,工作內容,審核人。那么什么才是主干內容?很容易看出上班時長,加班時長是主干,也就是工作量主題的基本內容,那么工作日期,人員,工作性質,是否外勤,工作內容是否為主干信息呢?認真分析特征會發現,日期,人員,性質,是否外勤都是可以被分類的,例如日期有年-月-日的層次,人員也有上下級關系,外勤和正常上班也是兩類上班考勤記錄,而上班時長和加班時長則不具有此類意義。所以一般把能夠分類的屬性單獨列出來,成為維度表,在事實表中維護事實與維度的引用關系。
在上述例子中,事實表可以設計成如下
WorkDate EmployeeID,WorkTypeID,Islegwork,Content,
而時間,員工,工作類型,是否外勤則歸為維度表。
總的來看,和其他建立主外鍵關系的表也都一樣。但是維度表的建立是需要有層次的(雖然不是必須,但是也是典型特征),而事實表的建立是針對已經發生的事實的,是歷史數據的存檔,也就是說是不應該修改的。以測試部測試軟件的Bug為例。每個Bug都是一個事實。這個Bug的狀態在數據字典里可能設計成新建,轉派,修復,拒絕等等。那么在事實表中Bug表中有一個字段為Status。當測試員或者開發人員改變了這個狀態的值,事實表中該如何更新呢?是直接更新Status還是什么其他的方式?顯然,為了能夠追蹤這個Bug的歷史信息,應該是重新插入一條新的記錄。那么這和以往的數據庫設計有什么區別呢?可以看出對於原始記錄和新插入的記錄,其他字段全部是相同的,也就是全部冗余的。如果以BugID作為主鍵,這時候會發現主鍵都是冗余的(當然,插入之前只能刪除主鍵)。所以可以看出,事實表一般是沒有主鍵的。數據的質量完全由業務系統來把握。
總的說來,事實表的設計是以能夠正確記錄歷史信息為准則,維度表的設計是以能夠以合適的角度來聚合主題內容為准則。
維是分析問題的角度,每一維代表一個統一的訪問數據倉庫中信息的路徑。
在實際問題中,有些維包含多個層次。
事實是各個維度的交點,是對某個特定事件的度量,只有當特定維值的組合沒有造成空穴時,一個事實才會存在。事實的數量屬性稱為度量。
事實數據和維度數據的識別必須依據具體的主題問題而定。“事實表”,用來存儲事實的度量(measure)及指向各個維的外鍵值。維表用來保存該維的元數據,即維的描述信息,包括維的層次及成員類別等
再舉個實際的例子。銀行對存款記賬,A表中存放實際數據,包括賬號、所屬機構號、存款金額等,B表存放機構號和機構名稱的對應關系。則A是事實表,B是維表。
1、事實表就是你要關注的內容;
2、維表就是你觀察該事務的角度,是從哪個角度去觀察這個內容的。
例如,某地區商品的銷量,是從地區這個角度觀察商品銷量的。事實表就是銷量表,維表就是地區表。