理解維度資料倉庫——事實表、維度表、聚合表
事實表
在多維資料倉庫中,儲存度量值的詳細值或事實的表稱為“事實表”。一個按照州、產品和月份劃分的銷售量和銷售額儲存的事實表有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、維度表就是你觀察該事務的角度,是從哪個角度去觀察這個內容的。
例如,某地區商品的銷量,是從地區這個角度觀察商品銷量的。事實表就是銷量表,維度表就是地區表。
聚合表
資料是按照最詳細的格式儲存在事實表中,各種報表可以充分利用這些資料。一般的查詢語句在查詢事實表時,一次操作經常涉及成千上萬條記錄,但是通過使用匯總、平均、極值等聚合技術可以大大降低資料的查詢數量。因此,來自事實表中的底層資料應該事先經過聚合儲存在中間表中。中間表儲存了聚合資訊,所以被稱為聚合表,這種處理過程被稱為聚合過程。
相關推薦
理解維度資料倉庫——事實表、維度表、聚合表
事實表 在多維資料倉庫中,儲存度量值的詳細值或事實的表稱為“事實表”。一個按照州、產品和月份劃分的銷售量和銷售額儲存的事實表有5個列,概念上與下面的示例類似。 Sate Product Mouth Units Dollars WA Moun
《BI那點兒事—資料的藝術》理解維度資料倉庫——事實表、維度表、聚合表
事實表 在多維資料倉庫中,儲存度量值的詳細值或事實的表稱為“事實表”。一個按照州、產品和月份劃分的銷售量和銷售額儲存的事實表有5個列,概念上與下面的示例類似。 Sate Product Mouth Units Dollars
資料倉庫-事實表/維度表技術-讀書筆記三
事實表技術簡述 事實表結構 1,總是包含外來鍵,且外來鍵不能唯空。 2,事實表的設計完全依賴業務活動,不受最終報表的影響。 3,每行對應一個度量事件。 可加、半可加、半可加事實 1,可加事實:最靈活,
資料倉庫--事實表和維度表
本文主要參考如下幾篇文章: http://www.cnblogs.com/47613593/archive/2009/02/20/1394581.html http://jackwxh.blog.51cto.com/2850597/827968 1.資料倉庫與操作型資料
維度模型資料倉庫(二) —— 維度模型基礎
從圖中可以看出,每種架構中都有資料集市。資料集市就是面向終端使用者的資料庫。資料集市通常使用維度模型來建模,並根據報表和分析的需求而優化。Kimball和Inmon架構最大的區別就是是否需要一個企業級的資料倉庫(EDW)。Inmon架構中有EDW,Kimball架構中沒有。EDW本質上就是一個
數據倉庫--事實表和維度表
需要 解釋 參考 gid 新的 www 多次 主外鍵 color 本文主要參考如下幾篇文章:http://www.cnblogs.com/47613593/archive/2009/02/20/1394581.htmlhttp://jackwxh.blog.51cto.co
【資料倉庫】2.維度建模
0x00 前言 前一篇已經對常用的幾種資料模型做了簡單的介紹,本篇主要對其中最常用的維度建模做一個深入的理解。 0x01 什麼是維度建模 維度模型是資料倉庫領域另一位大師 Ralph Kimball 所倡導,他的《The DataWarehouse Toolkit-The Complet
【資料倉庫】3.緩慢變化維度(SCD)
0x00 前言 本文會分享資料倉庫中和緩慢變化維度相關的內容。在看之前建議回顧一下和維度建模相關的知識點,可參考這篇:No.12 【漫談資料倉庫】維度建模。 為什麼會分享這個聽起來很奇怪的東西?因為站在的筆者的視角中,只要是做資料倉庫的小夥伴們,在工作中基本上都會接觸和維度建模相關的內容,而
資料倉庫系列——01.拉鍊表(原理、設計以及在Hive中的實現)
0x00 前言 過了半年時間,對資料倉庫的理解又有了一些不同的認識,翻出來之前寫的關於拉鍊表的內容,稍作修改重新發出來。本篇將會談一談在資料倉庫中拉鍊表相關的內容,包括它的原理、設計、以及在我們大資料場景下的實現方式。 內容 全文由下面幾個部分組成: 先分享一下拉
漫談資料倉庫之SCD(緩慢變化維度)
0x01 什麼是SCD? SCD(Slowly Changing Dimensions),中文一般翻譯成“緩慢變化維”。 緩慢變化維的提出是因為在現實世界中,維度的屬性並不是靜態的,它會隨著時間的流失發生緩慢的變化。這種隨時間發生變化的維度我們一般稱之為緩慢變化維,並且把處
毫秒級從百億大表任意維度篩選資料,是怎麼做到的.
文章概要 1 業務背景 隨著閒魚業務的發展,使用者規模達到數億級,使用者維度的資料指標,達到上百個之多。如何從億級別的資料中,快速篩選出符合期望的使用者人群,進行精細化人群運營,是技術需要解決的問題。業界的很多方案往往需要分鐘級甚至小時級才能生成查詢結果。本文提供了一種解決大資料場景
大資料入門基礎系列之Hadoop1.X、Hadoop2.X和Hadoop3.X的多維度區別詳解(博主推薦)
不多說,直接上乾貨! 在前面的博文裡,我已經介紹了 見下面我寫的微信公眾號博文 歡迎大家,加入我的微信公眾號:大資料躺過的坑 免費給分享 同時,大家可以關注我的個人部
維度模型資料倉庫(十五) —— 多重星型模式
(五)進階技術 10. 多重星型模式 從(五)進階技術1. “增加列”開始,已經通過增加列和表擴充套件了資料倉庫,在(五)進階技術5. “快照”裡增加了第二個事實表,month_end_sales_order_fact表。這之後資料倉庫模式
資料倉庫專題(22):匯流排架構和維度建模優勢-雜項
一、匯流排架構 維度建模的資料倉庫中,有一個概念叫Bus Architecture,中文一般翻譯為“匯流排架構”。匯流排架構是Kimball的多維體系結構(MD)中的三個關鍵性概念之一,另兩個是一致性維
維度模型資料倉庫基礎物件概念一覽
一、度量、指標、指標器 度量和維度構成OLAP的主要概念,對於在事實表或者一個多維立方體裡面存放的數值型的、連續的欄位,就是度量。這符合上面的意思,有標準,一個度量欄位肯定是統一單位,例如元、戶數。如果一個度量欄位,其中的度量值可能是歐元又有可能是美元,那這個度量沒法彙總。
【大資料】資料倉庫維度建模入門
對資料分析越來越深入,越來越發現資料標準化的重要性,再高明的資料分析技術,沒有規範統一的資料倉庫,也是“巧婦難為無米之炊”。遂從頭再對資料倉庫技術進行一邊梳理。 1. 維度建模理論概要 1.1 維度設計的主要流程 1.1.1 選擇業務過程 業務過程是組織完成的操作
維度模型資料倉庫(十二) —— 多路徑和參差不齊的層次
(五)進階技術 7. 多路徑和參差不齊的層次 本篇討論多路徑層次,它是對單路徑層次的擴充套件。上一篇裡資料倉庫的月維度只有一條層次路徑,即年-季度-月這條路徑。在本篇中加一個新的級別,推廣期,並且加一個新的年-推廣期-月的層次路徑。這時月維度
資料倉庫系列-為什麼要維度建模
凡是建設資料倉庫,一定會提到維度建模方法。這一方法是Kimball最先提出的,其最簡單的描述就是,按照事實表、維度表來構建資料倉庫、資料集市。在維度建模方法體系中,維度是描述事實的角度,如日期、商品、地址等,事實是要度量的指標,如使用者數、銷售額等。按照一般書籍的介紹,維度
維度模型資料倉庫(十四) —— 雜項維度
(五)進階技術 9. 雜項維度 本篇討論雜項維度。簡單地說,雜項維度就是一種包含的資料具有很少可能值的維度。例如銷售訂單,它可能有很多離散資料(yes-no這種型別的值),如verification_ind(如果訂單已經被稽核,值為yes)c
資料倉庫專題(2)-Kimball維度建模四步驟
一、前言 四步過程維度建模由Kimball提出,可以做為業務梳理、資料梳理後進行多維資料模型設計的指導流程,但是不能作為資料倉庫系統建設的指導流程。本文就相關流程及核心問題進行解讀。 二、資料倉庫建設流程 以下流程是根據業務系統、組織結構、團隊結構現狀設定的資料倉庫系統建設流程,適合系統結構複雜,團隊協