理解維度資料倉儲——事實表、維度表、聚合表
事實表
在多維資料倉儲中,儲存度量值的詳細值或事實的表稱為“事實表”。一個按照州、產品和月份劃分的銷售量和銷售額儲存的事實表有5個列,概念上與下面的示例類似。
Sate |
Product |
Mouth |
Units |
Dollars |
WA |
Mountain-100 |
January |
3 |
7.95 |
WA |
Cable Lock |
January |
4 |
7.32 |
OR |
Mountain-100 |
January |
3 |
7.95 |
OR |
Cable Lock |
January |
4 |
7.32 |
WA |
Mountain-100 |
February |
16 |
42.40 |
在這些事實表的示例資料行中,前3個列——州、產品和月份——為鍵值列。剩下的兩個列——銷售額和銷售量——為度量值。事實表中的每個列通常要麼是鍵值列,要麼是度量值列,但也可能包含其他參考目的的列——例如採購訂單號或者發票號。
事實表中,每個度量值都有一個列。不同事實表將有不同的度量值。一個銷售資料倉儲可能含有這兩個度量值列:銷售額和銷售量。一個現場資訊資料倉儲可能包含3個度量值列:總量、分鐘數和瑕疵數。建立報表時,可以認為度量值形成了一個額外的維度。即可以把銷售額和銷售量作為並列的列標題,或者也可以把它們作為行標題。然而在事實表中,每個度量值都作為一個單獨的列顯示。
事實表資料行中包含了您想從中獲取度量值資訊的最底層級別的明細。換句話說,事實表中對每個維度的最詳細的專案成員都有資料行。如果有使用其他維度的度量,只要為那些度量和維度建立另一個事實表即可。資料倉儲中可能包含擁有不同度量值和維度的不同事實表。
前面表格中的示例資料行顯示了事實表的概念佈局。事實是事實表幾乎總會使用一個整數值來表示(維度)成員,而不使用描述性的名稱。因為事實表往往會包含數量多得無法想象的資料行——在一箇中等大小的資料倉儲中,事實表動輒包含上百萬行資料——使用整數鍵值可以有效地減小事實表的大小。事實表真正的佈局如下所示。
STATE_ID |
PROD_ID |
Month |
Sales_Units |
Sales_Dollars |
1 |
347 |
1 |
3 |
7.95 |
1 |
447 |
1 |
4 |
7.32 |
2 |
347 |
1 |
3 |
7.95 |
2 |
447 |
1 |
4 |
7.32 |
1 |
347 |
2 |
16 |
42.40 |
在事實表中使用整數鍵值時,維度成員的名稱需要放到另一種表中——也就是維度表。通常,事實表中的每個維度都有一個維度表。
事實表字首為Fact。
歸納:
每個資料倉儲都包含一個或者多個事實資料表。事實資料表可能包含業務銷售資料,如現金登記事務。
所產生的資料,事實資料表通常包含大量的行。事實資料表的主要特點是包含數字資料(事實),並且這些數字資訊可以彙總,以提供有關單位作為歷史的資料,每個事實資料表包含一個由多個部分組成的索引,該索引包含作為外來鍵的相關性緯度表的主鍵,而維度表包含事實記錄的特性。事實資料表不應該包含描述性的資訊,也不應該包含除數字度量欄位及使事實與緯度表中對應項的相關索引欄位之外的任何資料。
包含在事實資料表中的“度量值”有兩中:一種是可以累計的度量值,另一種是非累計的度量值。最有用的度量值是可累計的度量值,其累計起來的數字是非常有意義的。使用者可以通過累計度量值獲得彙總資訊,例如。可以彙總具體時間段內一組商店的特定商品的銷售情況。非累計的度量值也可以用於事實資料表,單彙總結果一般是沒有意義的,例如,在一座大廈的不同位置測量溫度時,如果將大廈中所有不同位置的溫度累加是沒有意義的,但是求平均值是有意義的。
一般來說,一個事實資料表都要和一個或多個緯度表相關聯,使用者在利用事實資料表建立多維資料集時,可以使用一個或多個維度表。
維度表
維度表包含了維度的每個成員的特定名稱。維度成員的名稱稱為“屬性”(Attribute)。假設Product維度中有3種產品,那麼維度表將如下所示。
PROD_ID |
Product_Name |
347 |
Mountain-100 |
339 |
Road-650 |
447 |
Cable Lock |
產品名稱是產品成員的一個屬性。因為維度表中的Product ID與事實表中的Product ID相匹配,稱為“鍵屬性”。因為每個Product ID只有一個Product Name,顯示時用名稱來替代整數值,所以它仍然被認為是鍵屬性的一部分。
在資料倉儲中,維度表中的鍵屬性必須為維度的每個成員包含一個對應的唯一值。用關係型資料庫術語描述就是,鍵屬性稱為主鍵列。每個維度表中的主鍵值都與任何相關的事實表中的鍵值相關。在維度表中出現一次的每個鍵值都會在事實表中出現多次。例如Mountain-100的Product ID 347只在一個維度表資料行中出現,但它會出現在多個事實表資料行中。這稱為一對多關係。在事實表中,鍵值列(它是一對多關係的“多”的一方)稱為外來鍵列。關係型資料庫使用匹配的主鍵列(在維度表中)和外來鍵列(在事實表中)值來聯接維度表到事實表。
把維度資訊移動到一個單獨的表中,除了使得事實表更小外,還有額外的優點——可以為每個維度成員新增額外的資訊。例如,維度表可能為每個產品新增種類(Category)資訊,如下所示。
PROD_ID |
Product_Name |
Category |
347 |
Mountain-100 |
Bikes |
339 |
Road-650 |
Bikes |
447 |
Cable Lock |
Accessories |
現在種類是產品的另一個屬性。如果知道Product ID,不但可以推斷出Product Name,而且可以推斷出Category。鍵屬性的名稱可能是唯一的——因為每個鍵只有一個名稱,但其他屬性不需要是唯一的,例如Category屬性可能會出現好幾次。這樣一來,便可以建立按照產品和類別對事實表資訊進行分組的報表。
除了名稱外,維度表可以包含許多其他的屬性。本質上,每個屬性都對應於維度表中的一個列。下面是帶有其他額外屬性的只有3個成員的Product維度表的示例。
PROD_ID |
Product_Name |
Category |
Color |
Size |
Price |
347 |
Mountain-100 |
Bikes |
Black |
44 |
782.99 |
339 |
Road-650 |
Bikes |
Silver |
48 |
3399.99 |
447 |
Cable Lock |
Accessories |
NA |
NA |
25.00 |
維度屬性可以是可分組的,也可以是不可分組的。換句話就是,您是否見過按照哪個屬性來分組度量值的報表?在我們的示例中,Category、Size和Color全都是可分組的屬性。由此自然會聯想到可能在某個報表中按照顏色、大小或種類來分組銷售額。但Price看起來不像是可分組的屬性——至少它本身不是。在報表中可能會有一個更有意義的其他屬性——例如Price Group,但價格本身變化太大,導致在報表上分組意義不大。同樣地,按照Product Description屬性在報表上進行分組意義也不大。在一個Customer維度中,City、Country、Gender和Marital Status都是可以在報表上按照它們進行有意義分組的屬性,但Street Address或Nickname都應當是不可分組的。不可分組的屬性通常稱為成員屬性(member property)。
某些可分組的屬性可以組合起來建立一個自然層次結構(natural hierarchy)。例如假設Product有Category和Subcategory屬性,在多數情況下,單個產品只會屬於單個Subcategory,並且單個Subcategory只會屬於單個Category。這將形成一個自然層次結構。在報表中,可能會顯示Categories,然後允許使用者從某個Category鑽取到Subcategories,以及最終鑽取到Products。
層次結構——或者說鑽取路徑——不一定要是自然的(例如,每個低層次的成員會決定下一個高層次的成員)。例如,您可能會建立一個按照Color分組產品的報表,但允許使用者根據每個Color鑽取到每個不同的Size。因為報表的鑽取能力,Color和Size形成了一個層次結構,但是根據Size卻沒有任何資訊可以用來斷定產品的Color將是什麼。這是一個層次結構,但不是一個自然層次結構——但也不是說它是個非自然層次結構。Color和Size形成一個層次結構並沒有什麼不對,它只是這樣一個簡單的事實:相同的Size可以出現在多個Color中。
維度表字首為Dim。
歸納:
維度表可以看作是使用者來分析資料的視窗,緯度表中包含事實資料表中事實記錄的特性,有些特性提供描述性資訊,有些特性指定如何彙總事實資料表資料,以便為分析者提供有用的資訊,維度表包含幫助彙總資料的特性的層次結構。例如,包含產品資訊的維度表通常包含將產品分為食品、飲料、非消費品等若干類的層次結構,這些產品中的每一類進一步多次細分,直到各產品達到最低階別。
在維度表中,每個表都包含獨立於其他維度表的事實 特性,例如,客戶維度表包含有關客戶的資料。維度表中的列欄位可以將資訊分為不同層次的結構級。
結論:
1、事實表就是你要關注的內容;
2、維度表就是你觀察該事務的角度,是從哪個角度去觀察這個內容的。
例如,某地區商品的銷量,是從地區這個角度觀察商品銷量的。事實表就是銷量表,維度表就是地區表。
聚合表
資料是按照最詳細的格式儲存在事實表中,各種報表可以充分利用這些資料。一般的查詢語句在查詢事實表時,一次操作經常涉及成千上萬條記錄,但是通過使用匯總、平均、極值等聚合技術可以大大降低資料的查詢數量。因此,來自事實表中的底層資料應該事先經過聚合儲存在中間表中。中間表儲存了聚合資訊,所以被稱為聚合表,這種處理過程被稱為聚合過程。
相關文章
- 資料倉儲(8)數倉事實表和維度表技術
- 【資料倉儲】全量表、快照表、增量表、拉鍊表、維度表、實體表、事實表
- 【資料倉儲】|3 維度建模之維度表設計
- 【資料倉儲】|4 維度建模之事實表設計
- BI中事實表和維度表的定義(轉載)
- 【資料倉儲】|5 維度建模設計和實施過程
- 電商行業資料包表調研的三個維度行業
- 維度處理-資料倉儲-讀書筆記(四)筆記
- 資料倉儲之拉鍊表
- Oracle日曆表維護實踐:建表、準備資料Oracle
- 製作多維度分組交叉銷售統計表
- 10.Flink實時專案之訂單維度表關聯
- 毫秒級從百億大表任意維度篩選資料,是怎麼做到的...
- 資料倉儲之拉鍊表設計
- 《Cris Tales》的奧祕:巧妙的時空維度表達方式
- flink維表關聯絡列之Redis維表關聯:實時查詢Redis
- 暑假進度表
- 資料分析-基礎維度
- 生成mysql日期維表MySql
- Flink 自定義維表
- 測試進度表
- 快速入門pandas進行資料探勘資料分析[多維度排序、資料篩選、分組計算、透視表](一)排序
- MySQL入門--表維護MySql
- 實現報表資料分庫儲存
- 資料倉儲工具箱-維度建模權威指南(第三版)讀書筆記筆記
- torch 維度
- 維度建模
- Databricks 第6篇:Spark SQL 維護資料庫和表SparkSQL資料庫
- 2021年人們對重大體育賽事的興趣度(附原資料表)
- 面對高維度的優勢,低維度的數量優勢無濟於事
- 報表資料分庫儲存
- ABAP 動態備份自建表資料到新表(自建表有資料的情況下要改欄位長度或者其他)
- 資料庫選型其實技術維度不太重要資料庫
- 如何將EXCEL資料表裡面的資料逆時針旋轉90度Excel
- Oracle分割槽表基礎運維-04列表分割槽Oracle運維
- 《資料儲存》之《分庫,分表》
- oracle表查詢的並行度Oracle並行
- oracle 修改表欄位的長度Oracle
- 表單限制字串輸入長度字串