一、度量、指標、指標器
度量和維度構成OLAP的主要概念，對於在事實表或者一個多維立方體裏面存放的數值型的、連續的字段，就是度量。這符合上面的意思，有標準，一個度量字段肯定是統一單位，例如元、戶數。如果一個度量字段，其中的度量值可能是歐元又有可能是美元，那這個度量沒法彙總。在OLAP中還有計算度量的說法，用一個總費用除以用戶數，得到每戶平均費用。但這究竟還算不算度量了呢？這已經不是原本意義上的度量了，只是爲了稱呼方便而已。這就得說到指標，英文的Metric。在績效管理軟件裏面，通常是有這個概念的。其定義可表述爲"它是表示某種相對程度的值"。區別於度量概念，那是一種絕對值，尺子量出來的結果，彙總出來的數量等。而指標至少需要兩個度量之間的計算才能得到，例如ARPU，用收入比上用戶數，例如收入增長率，用本月收入比上上月收入。當然可能指標的計算還需要兩個以上的度量。而Indicator的字面意思爲指示器，在KPI中，最後一個I就是它，但是用中文稱呼它的時候，總是叫"關鍵績效指標"，而沒有叫做"指標器"，也就造成一些混亂。我們身邊充當指示器的有：紅綠燈，提醒行人車輛是否等待或通行；監控室裏的警報燈，提醒哪兒出現異常；汽車儀表盤，提醒駕駛員油是否足夠，速度如何。它們起到的作用是傳遞一種宏觀的信息，促使人的下一步行動。紅燈停綠燈行；看到警報亮起要趕緊派人查看。目前常見的企業績效管理軟件中，儀表盤（有的地方稱作駕駛艙）的展示界面也是必不可少，正是用這種直觀而比較有象徵性的指示器反映企業運營狀況。可以設想提出KPI的初衷，是希望企業通過一些粗略（非細節）的信息（而非數據）來爲下一步的決策作出依據。導致不同的決策行爲必定是離散的輸入，最簡單的就是一個開關，是或不是（例如警報燈）。如果說度量和指標是定量話，指示器就是一種定性的。然而，這些系統中的KPI並非完全上面提到的指示器，很多系統建設稱爲度量系統或是指標系統。而對一個企業，哪些指標能夠充分反映經營活動，這也是需要精心制定的，而不是讓技術部門提出一堆似是而非的指標名稱，諸如在網用戶數、收入之類，這不是KPI。
三者區別的說明：
"度量"是絕對的定量值；
"指標"是基於兩個或更多度量計算得出的相對值；
"指示器"是基於度量或指標，並依據某個基準值得到的定性結果。
二、維度中層與級的區別
在OLAP中定義維度時，層（Hierarchy）與級（Level）是比較讓人迷惑的兩個概念。簡單的說，層就是一種維度成員的分類方式，級就是維度成員之間或維度成員屬性之間的包含關係。一個維度至少要包含一個層。以[產品]維度爲例，可以創建一個[產地]層，可以創建一個[廠商]層，也可以創建一個[分類]層。在SSAS中，可以不定義層，此時維度的默認層爲AllMembers層。在Mondrian的Schema定義工具中，則要求全部手工定義。一個層至少要包含一個級，以[產品]維度爲例，[產地]層可以包含省-市-縣三個級別，[分類]層可以包含日用品-洗滌用品-洗衣粉三個級別。級別的定義有2種方式，一種是在一個維度成員的屬性之間定義，例如[產品]維度的每個成員都有產品系列、大類、小類三個屬性，這樣定義[分類]層的級別時，直接利用這三個屬性即可，即：每個級別都是一個成員的一個屬性。另一種是在維度成員之間進行，例如HR中的上下級關係，每個級別都是一個具體的維度成員，即：每個級別都是一個或多個維度成員，每個級都包含多個屬性。後一種級別在數據庫中往往是以遞歸的方式進行保存的。
三、數據倉庫相關術語
1、數據倉庫：數據倉庫是一個支持管理決策的數據集合。數據是面向主題的、集成的、不易丟失的並且是時變的。數據倉庫是所有操作環境和外部數據源的快照集合。它並不需要非常精確，因爲它必須在特定的時間基礎上從操作環境中提取出來。
2、數據集市：數據倉庫只限於單個主題的區域，例如顧客、部門、地點等。數據集市在從數據倉庫獲取數據時可以依賴於數據倉庫，或者當它們從操作系統中獲取數據時就不依賴於數據倉庫。
3、事實：事實是數據倉庫中的信息單元，也是多維空間中的一個單元，受分析單元的限制。事實存儲於一張表中（當使用關係數據庫時）或者是多維數據庫中的一個單元。每個事實包括關於事實（銷售額，銷售量，成本，毛利，毛利率等）的基本信息，並且與維度相關。在某些情況下，當所有的必要信息都存儲於維度中時，單純的事實出現就是對於數據倉庫足夠的信息。
4、維度：維度是用來反映業務的一類屬性，這類屬性的集合構成一個維度。例如，某個地理維度可能包括國家、地區、省以及城市的級別。一個時間維度可能包括年、季、月、周、日的級別。
5、級別：維度層次結構的一個元素。級別描述了數據的層次結構，從數據的最高（彙總程度最大）級別直到最低（最詳細）級別（如大分類-中分類-小分類-細分類）。級別僅存在於維度內。級別基於維度表中的列或維度中的成員屬性。
6、數據清洗：對數據倉庫系統無用的或者不符合數據格式規範的數據稱之爲髒數據。清洗的過程就是清除髒數據的過程。
7、數據採集：數據倉庫系統中後端處理的一部分。數據採集過程是指從業務系統中收集與數據倉庫各指標有關的數據。
8、數據轉換：解釋業務數據並修改其內容，使之符合數據倉庫數據格式規範，並放入數據倉庫的數據存儲介質中。數據轉換包括數據存儲格式的轉換以及數據表示符的轉換（如產品代碼到產品名稱的轉換）。
9、聯機分析處理(OLAP Online Analytical Processing)：OLAP是一種多維分析技術，用來滿足決策用戶在大量的業務數據中，從多角度探索業務活動的規律性、市場的運作趨勢的分析需求，並輔助他們進行戰略發展決策的制定。按照數據的存儲方式分OLAP又分爲ROLAP、MOLAP和HOLAP。在客戶信息數據倉庫CCDW的數據環境下，OLAP提供上鑽、下鑽、切片、旋轉等在線分析機制。完成的功能包括多角度實時查詢、簡單的數據分析，並輔之於各種圖形展示分析結果。
10、數據挖掘：在數據倉庫的數據中發現新信息的過程被稱爲數據挖掘，這些新信息不會從操作系統中獲得。
11、切片：一種用來在數據倉庫中將一個維度中的分析空間限制爲數據子集的技術
12、切塊：一種用來在數據倉庫中將多個維度中的分析空間限制爲數據子集的技術。
13、星型模式：是數據倉庫應用程序的最佳設計模式。它的命名是因其在物理上表現爲中心實體，典型內容包括指標數據、輻射數據，通常是有助於瀏覽和聚集指標數據的維度。星形圖模型得到的結果常常是查詢式數據結構，能夠爲快速響應用戶的查詢要求提供最優的數據結構。星形圖還常常產生一種包含維度數據和指標數據的兩層模型。
14、雪花模式：指一種擴展的星形圖。星形圖通常生成一個兩層結構，即只有維度和指標，雪花圖生成了附加層。實際數據倉庫系統建設過程中，通常只擴展三層：維度（維度實體）、指標（指標實體）和相關的描述數據（類目細節實體）；超過三層的雪花圖模型在數據倉庫系統中應該避免。因爲它們開始像更傾向於支持OLTP應用程序的規格化結構，而不是爲數據倉庫和OLAP應用程序而優化的非格式化結構。
15、粒度：粒度將直接決定所構建倉庫系統能夠提供決策支持的細節級別。粒度越高表示倉庫中的數據較粗，反之，較細。粒度是與具體指標相關的，具體表現在描述此指標的某些可分層次維的維值上。例如，時間維度，時間可以分成年、季、月、周、日等。數據倉庫模型中所存儲的數據的粒度將對信息系統的多方面產生影響。事實表中以各種維度的什麼層次作爲最細粒度，將決定存儲的數據能否滿足信息分析的功能需求，而粒度的層次劃分、以及聚合表中粒度的選擇將直接影響查詢的響應時間。
16、度量值：在多維數據集中，度量值是一組值，這些值基於多維數據集的事實數據表中的一列，而且通常爲數字。此外，度量值是所分析的多維數據集的中心值。即，度量值是最終用戶瀏覽多維數據集時重點查看的數字數據（如銷售、毛利、成本）
17、冰山查詢--iceberg query
在數據倉庫領域有一個概念叫Iceberg query，中文一般翻譯爲“冰山查詢”。冰山查詢在一個屬性或屬性集上計算一個聚集函數，以找出大於某個指定閾值的聚集值。以銷售數據爲例，你想產生這樣的一個顧客－商品對的列表，這些顧客購買商品的數量達到3件或更多。這可以用下面的冰山查詢表示：
Select P.cust_ID, P.item_ID, SUM(P.qty)
From Purchase P
Group by P.cust_ID, P.item_ID
Having SUM(P.qty)>=3
這種在給出大量輸入數據元組的情況下，使用having字句中的閾值來進行過濾的查詢方法就叫做冰山查詢。輸出結果可以看作“冰山頂”，而“冰山”是輸入數據。這種冰山查詢在數據倉庫的數據概況分析階段、數據質量檢查階段和數據挖掘的購物籃分析中都經常使用。而且，冰山查詢也是面試中出現頻率非常高的一道題，經常用來檢測SQL能力。
18、操作集市--oper mart
在數據倉庫領域有一個概念叫Oper Mart，中文一般翻譯爲“操作集市”。操作集市是爲了企業戰術性的分析提供支持，它的數據來源是操作數據存儲（ODS）。它是ODS在分析功能上的擴展，使用戶可以對操作型數據進行多維分析。
一個操作集市應該有如下特徵：
①操作集市是ODS的子集，數據來源於ODS，用於戰略分析和報表。
②操作集市中的數據和ODS中的數據同步更新。
③操作集市以多維技術進行建模，即星型結構。
④操作集市是一個臨時的結構，當不在需要時會清掉所有數據，即不保存歷史數據。
操作集市和數據集市很相似，但是它不能用來取代用於戰略性分析的數據集市。由於操作集市的數據來源於ODS，所以它的數據比數據集市的數據要新。但是出於容量的考慮，操作集市中不保存歷史數據，是一個臨時的結構。
19、操作數據存儲--operational data store
Kimball對操作數據存儲的定義是，面向主題的、集成的、經常更新的細節數據存儲，用集成的數據來支持事務系統。Kimball也認可Inmon對ODS的分類，但是他認爲ODS應該以星型結構來進行建模。雖然Kimball對操作數據存儲（ODS）的定義和Inmon基本上一樣，但是他對操作數據存儲的理解、作用與實現和Inmon有着較大的不同。Kimball認爲ODS在兩種情況下是需要的：
第一種情況是提供操作型報表，這些報表需要提供面向主題的、集成的數據，所以操作型的源系統無法提供；這些報表和數據倉庫中的報表也不相同，因爲它們可以是一些定製好的，寫死在程序中的報表。
第二種情況是需要提供實時的信息時，由於數據倉庫的更新頻率一般都是24小時，而用戶會有更急切的需求來了解數據源的信息，這時，建立操作數據存儲是很有必要的。對於ODS是保存最細粒度數據的地方的說法，Kimball認爲對於最細粒度數據，即原子數據層，應該保存在數據倉庫中，而且應該置於維度框架和總線架構中。
20、代理關鍵字--surrogate key
代理關鍵字一般是指維度表中使用順序分配的整數值作爲主鍵，也稱爲“代理鍵”。代理關鍵字用於維度表和事實表的連接。代理關鍵字的稱呼有surrogate keys，meaningless keys，integer keys，nonnatural keys，artificial keys，synthetic keys等。與之相對的自然關鍵字的稱呼有natural keys，samat keys等。在Kimball的維度建模領域裏，是強烈推薦使用代理關鍵字的。在維度表和事實表的每一個聯接中都應該使用代理關鍵字，而不應該使用自然關鍵字或者智能關鍵字（Smart Keys）。數據倉庫中的主鍵不應該是智能的，也就是說，要避免通過主鍵的值就可以瞭解一些業務信息。當然，退化維度作爲事實表的複合主鍵之一時例外。
使用代理關鍵字，有很多優點：
①使用代理關鍵字能夠使數據倉庫環境對操作型環境的變化進行緩衝。也就是說，當數據倉庫需要對來在多個
操作型系統的數據進行整合時，這些系統中的數據有可能缺乏一致的關鍵字編碼，即有可能出現重複，這時代
理關鍵字可以解決這個問題。
②使用代理關鍵字可以帶來性能上的優勢。和自然關鍵字相比，代理關鍵字很小，是整型的，可以減小事實表
中記錄的長度。這樣，同樣的IO就可以讀取更多的事實表記錄。另外，整型字段作爲外鍵聯接的效率也很高。
③使用代理關鍵字可以建立一些不存在的維度記錄，例如“不在促銷之列”，“日期待定”，“日期不可用”等
維度記錄。
④使用代理關鍵字可以用來處理緩慢變化維。維度表數據的歷史變化信息的保存是數據倉庫設計的實施中非常重
要的一部分。Kimball的緩慢變化維處理策略的核心就是使用代理關鍵字。
使用代理關鍵字，當然也有缺點：
代理關鍵字的使用使數據加載變得非常複雜。有關使用代理關鍵字的維度表和事實表的加載方法在ETL Toolkit
中有詳細的描述。使用代理關鍵字是一個從長遠考慮的策略。
21、多值維度--multivalue dimension
多值維度有兩種情況：
第一種情況是指維度表中的某個屬性字段同時有多個值。舉例來說，一個帳戶維度表中，帳戶持有人姓名，可能會有多個顧客。這樣，一個帳戶對應多個顧客姓名，一個顧客也可以有多個帳戶，它們之間是多對多的關係。正因爲一個帳戶可能會有多個對應的顧客，所以不能直接將顧客ID放入帳戶維度表中。而帳戶維度表中的這種情況就叫做多值維度。
第二種情況是事實表在某個維度表中有多條對應記錄。舉例來說，對於一個健康護理單分列項事實表來說，它的粒度是一個健康護理單，但是該護理單卻有可能有多次診斷，即該事實表與診斷維度的是一對多的關係。這個與事實表粒度不匹配的診斷維度也稱之爲多值維度。處理多值維度最好的辦法是降低事實表的粒度。如第二種情況中，將健康護理單分列項事實表的粒度降低到具體的診斷粒度上，這樣就避免了多值維度的出現。這種處理方式也是維度建模的一個原則，即事實表應該建立在最細粒度上。這樣的處理，需要對事實表的事實進行分攤。但是有些時候，事實表的粒度是不能降低的，多值維度的出現是無法避免的。如第一種情況中，事實表是月帳戶快照事實表，這張事實表與顧客維度沒有直接的關係，不能將數據粒度進行細分，即使細分的話帳戶餘額也很難分攤。這時，可以採用橋接表技術進行處理。在帳戶維度表和顧客維度表之間建立個帳戶-顧客橋接表。這個橋接表可以解決掉帳戶維度和顧客維度之間的多對多關係，也解決掉的帳戶維度表的多值維度問題。總之，多值維度是應該儘量避免的，它給數據處理帶來了很大的麻煩。如果多值維度不能避免的話，應該建立橋接表來進行處理。
22、非事實型事實表--factless fact table
在事實表中，通常會保存十個左右的維度外鍵和多個度量事實，度量事實是事實表的關鍵所在。在非事實型事實表中沒有這些度量事實，只有多個維度外鍵。非事實型事實表通常用來跟蹤一些事件或者說明某些活動的範圍。下面舉例來進行說明。第一類非事實型事實表是用來跟蹤事件的事實表：學生註冊事件，學校需要對學生按學期進行跟蹤。維度表包括學期維度、課程維度、系維度、學生維度、註冊專業維度和取得學分維度，而事實表是由這些維度的主鍵組成，事實只有註冊數，並且恆爲1。這樣的事實表可以回答大量關於大學開課註冊方面的問題，主要是回答各種情況下的註冊數。
第二類非事實型事實表是用來說明某些活動範圍的事實表：
促銷範圍事實表。通常銷售事實表可以回答如促銷商品的銷售情況，但是對於那些沒有銷售出去的促銷商品沒法回答。這時，通過建立促銷範圍事實表，將商場需要促銷的商品單獨建立事實表保存。然後，通過這個促銷範圍事實表和銷售事實表即可得出哪些促銷商品沒有銷售出去。這樣的促銷範圍事實表只是用來說明促銷活動的範圍，其中沒有任何事實度量。
23、合併事實表--consolidated
合併事實表是將不同事實表的事實合併到同一張事實表的建模方法，合併的事實要保證在相同的粒度。這種建模方法通常被用來橫跨多個業務主題域來建立數據集市，Kimball將這樣的數據集市稱爲第二級的數據集市。使用合併事實表技術，☆可以避免性能較差的交叉探察操作☆。但是，這種合併事實表和使用交叉探察操作還有着細微的不同，在一些基礎表中沒有記錄的時候，合併事實表中可能會存儲一條記錄，字段值保存爲零。合併事實表可以給數據倉庫帶來很大的性能提升，提供的跨主題的事實數據也給用戶帶來了很大的方便。但是，合併事實表給ETL工作帶來了較大的麻煩。對於合併事實表中涉及到的維度，需要在數據準備區保證它們是一致性維度。
24、緩慢變化維--slowly changing dimension
緩慢變化維，經常被簡寫爲SCD。緩慢變化維的提出是因爲在現實世界中，維度的屬性並不是靜態的，它會隨着時間的流失發生緩慢的變化。這種隨時間發生變化的維度我們一般稱之爲緩慢變化維，並且把處理維度錶的歷史變化信息的問題稱爲處理緩慢變化維的問題，有時也簡稱爲處理SCD的問題。處理緩慢變化維的方法通常分爲三種方式：
①直接覆蓋原值。這樣處理，最容易實現，但是沒有保留歷史數據，無法分析歷史變化信息。第一種方式通常簡
稱爲“TYPE 1”。
②添加維度行。這樣處理，需要代理鍵的支持。實現方式是當有維度屬性發生變化時，生成一條新的維度記錄，
主鍵是新分配的代理鍵，通過自然鍵可以和原維度記錄保持關聯。第二種方式通常簡稱爲“TYPE 2”。
③添加屬性列。這種處理的實現方式是對於需要分析歷史信息的屬性添加一列，來記錄該屬性變化前的值，而本
屬性字段使用TYPE 1來直接覆蓋。這種方式的優點是可以同時分析當前及前一次變化的屬性值，缺點是隻保留了
最後一次變化信息。第三種方式通常簡稱爲“TYPE 3”。
在實際建模中，我們可以聯合使用三種方式，也可以對一個維度表中的不同屬性使用不同的方式，這些，都需要
根據實際情況來決定，但目的都是一樣的，就是能夠支持方便的分析歷史變化情況。
25、即席查詢--ad hoc queries
即席查詢是指那些用戶在使用系統時，根據自己當時的需求定義的查詢。即席查詢生成的方式很多，最常見的就是使用即席查詢工具。一般的數據展現工具都會提供即席查詢的功能。通常的方式是，將數據倉庫中的維度表和事實表映射到語義層，用戶可以通過語義層選擇表，建立表間的關聯，最終生成SQL語句。即席查詢與通常查詢從SQL語句上來說，並沒有本質的差別。它們之間的差別在於，通常的查詢在系統設計和實施時是已知的，所有我們可以在系統實施時通過建立索引、分區等技術來優化這些查詢，使這些查詢的效率很高。而即席查詢是用戶在使用時臨時生產的，系統無法預先優化這些查詢，所以即席查詢也是評估數據倉庫的一個重要指標。在一個數據倉庫系統中，即席查詢使用的越多，對數據倉庫的要求就越高，對數據模型的對稱性的要求也越高。對稱性的數據模型對所有的查詢都是相同的，這也是維度建模的一個優點。
26、交叉探察--drill across
在基於總線架構（Bus Architecture）的維度建模中，大部分的維度表是由事實表共有的。比如“營銷事務事實表”和“庫存快照事實表”就會有相同的維度表，“日期維度”、“產品維度”和“商場維度”。這時，如果有個需求是想按共有維度來對比查看銷售和庫存的事實，這時就需要發出兩個SQL，分別查出按維度統計出的銷售數據和庫存數據。然後再基於共有的維度進行外連接，將數據合併。這種發出多路SQL再進行合併的操作就是交叉探查。當這種交叉探查的需求很常用時，有一種建模方法可以避免交叉探查，就是合併事實表（Consolidated Fact Table）。合併事實表是指將位於不同事實表中處於相同粒度的事實進行組合的一種建模方法。即新建立一個事實表，它的維度是兩個或多個事實表的相同維度的集合，事實是幾個事實表中感興趣的事實。這個事實表的數據和其他事實表的數據一樣來自Staging Area。合併事實表在性能和易用性上都比交叉探查要好，但是被組合的事實表必須處於相同的粒度和維度層次上。
27、角色模仿維度--role-playing dimensions
角色模仿維度是爲了處理一個維度在一個事實表中同時出現多次而使用的一種技術處理手段。在建立了角色模仿維度以後，在底層只有一個物理表存在，但是針對這個物理表會建立多個角色提供給數據訪問工具，而且對數據訪問工具來說這多個角色是不同的。例如對與累計快照事實表中會出現多個日期字段聯接到日期維度。這時就可以針對日期維度建立多個角色模仿維度。角色模仿維度的建立方法通常是使用視圖來完成。例如訂單日期維度表如下所示：CREATE VIEW order_date(order_date_key, order_day_of_week, order_month, … )AS SELECT data_key, day_of_week, month, … FROM DATA使用同樣的方式還可以建立多個不同日期的角色模仿維度。聚集事實表--aggregated fact table、累計快照事實表--accumulating snapshot fact table橋接表--bridge table
28、切片事實表--sliced fact table
切片事實表中的字段結構和相應的基礎表完全相同，差別在於存儲的記錄的範圍。切片事實表中保存記錄的是相應基礎表中記錄的子集，記錄數通常與某個維度記錄數相同。這種建模方法一般用來滿足特殊需要，如需要分析某些特殊問題時，可以將與之相關的數據切片出來。相反，這種方法也常用於合併存儲在不同地區的數據，即各個地區都保存自己地區的數據，總部和所有地區的表結構都相同，然後總部將所有地區的數據合併在一起。切片事實表的結構與相對應的基礎表相同，數據來源於相對應的基礎表。切片事實表由於縮小了表中數據的記錄數，所以查詢的效率得到了很大的提高。
29、事實表--fact table
在維度建模的數據倉庫中，事實表是指其中保存了大量業務度量數據的表。事實表中的度量值一般稱爲事實。在事實表中最有用的事實就是數字類型的事實和可加類型的事實。事實表的粒度決定了數據倉庫中數據的詳細程度。以粒度作爲化分依據，主要有三種事實表，分別是事務粒度事實表（Transaction Grain Fact Table），週期快照粒度事實表（Periodic Snapshot Grain Fact Table）和累積快照粒度事實表（Accumulating Snapshot Grain Fact Table）。事務粒度事實表中的一條記錄代表了業務系統中的一個事件。事務出現以後，就會在事實中出現一條記錄。事務粒度事實表也稱爲原子粒度。典型的例子是銷售單分列項事實表。週期快照粒度事實表用來記錄有規律的，可預見時間間隔的業務累計數據。通常的時間間隔可以是每天、每週或者每月。典型的例子是庫存日快照事實表。累積快照事實表一般用來涵蓋一個事務的生命週期內的不確定的時間跨度。典型的例子是KDT#2中描述的具有多個日期字段的發貨事實表。通常來說，事務和快照是建模中的兩個非常重要的特點，將兩者相結合可以使模型建立的更完整。從用途的不同來說，事實表可以分爲三類，分別是原子事實表，聚集事實表和合並事實表：
①原子事實表（Atom Fact Table）是保存最細粒度數據的事實表，也是數據倉庫中保存原子信息的場所。
②聚集事實表（Aggregated Fact Table）是原子事實表上的彙總數據，也稱爲彙總事實表。即新建立一個事實表，它的維度表是比原維度表要少，或者某些維度表是原維度表的子集，如用月份維度表代替日期維度表；事實數據是相應事實的彙總，即求和或求平均值等。在做數據遷移時，當相關的維度數據和事實數據發生變化時，聚集事實表需要做相應的刷新。物化視圖是實現聚集事實表的一種有效方式，可以設定刷新方式，具體功能由DBMS來實現。
③合併事實表（Consolidated Fact Table）是指將位於不同事實表中處於相同粒度的事實進行組合建模而成的一種事實表。即新建立一個事實表，它的維度是兩個或多個事實表的相同維度的集合；事實是幾個事實表中感興趣的事實。在Kimball的總線架構中，由合併事實表爲主組成的合併數據集市稱爲二級數據集市。合併事實表的粒度可以是原子粒度也可以是聚集粒度。在做數據遷移時，當相關的原子事實表的數據有改變時，合併事實表的數據需要重新刷新。合併事實表和交叉探察是兩個互補的操作。聚集事實表和合並事實表的主要差別是合併事實表一般是從多個事實表合併而來。但是它們的差別不是絕對的，一個事實表既是聚集事實表又是合併事實表是很有可能的。因爲一般合併事實表需要按相同的維度合併，所以很可能在做合併的同時需要進行聚集，即粒度變粗。
30、數據世系--data lineage
數據世系描述的是從源系統抽取數據開始，經過數據轉換到最終的數據加載的整個過程中各種信息。數據世系信息需要留下詳細的文檔記載。數據世系包括源系統的數據庫中數據定義以及該數據在數據倉庫中的最終位置等信息。
數據世系是數據倉庫的元數據中最重要的一部分。這部分元數據的產生位置是在ETL的處理過程中。如果在ETL的處理過程中使用的ETL工具的話，ETL工具可以記錄下元數據的一部分，但是這部分一般都是數據的屬性描述，而不是完全的數據世系。換一句說，完全依靠ETL工具來維護元數據是不夠的。
31、退化維度--degenerate dimension
退化維度一般都是事務的編號，如訂單編號、發票編號等。這類編號需要保存到事實表中，但是不需要對應的維度表，所以稱爲退化維度。退化維度是維度建模領域中的一個非常重要的概念，它對理解維度建模有着非常重要的作用，尤其是對維度建模的入門者。退化維度經常會和其他一些維度一起組合成事實表的主鍵。在Kimball提出的維度建模中，事實表應該保存最細粒度的數據。所以對於象銷售單這樣的事實表來說，需要銷售單編號和產品來共同作爲主鍵，而不能用銷售日期、商場、產品等用來分析的維度共同作爲主鍵。退化維度在分析中可以用來做分組使用。它可以將同一個事務中銷售的產品集中在一起。
32、微型維度--minidimension
微型維度的提出主要是爲了解決快變超大維度（rapidly changing monster dimension）。以客戶維度舉例來說，如果維度表中有數百萬行記錄或者還要多，而且這些記錄中的字段又經常變化，這樣的維度表一般稱之爲快變超大維度。對於快變超大維度，設計人員一般不會使用TYPE 2的緩慢變化維處理方法，因爲大家都不願意向本來就
有幾百萬行的維度表中添加更多的行。這時，有一項技術可以解決這個問題。解決的方法是，將分析頻率比較高或者變化頻率比較大的字段提取出來，建立一個單獨的維度表。這個單獨的維度表就是微型維度表。微型維度表有自己的關鍵字，這個關鍵字和原客戶維度表的關鍵字一起進入事實表。有時爲了分析的方便，可以把微型維度的關鍵字的最新值作爲外關鍵字進入客戶維度表。這時一定要注意，這個外關鍵字必須做TYPE 1型處理。在微型維度表中如果有像收入這樣分佈範圍較廣的屬性時，應該將它分段處理。比如，存儲￥31257.98這樣過於分散的數值就不如存儲￥30000－￥34999這樣的範圍。這樣可以極大的減少微型維度中的記錄數目，也給分析帶來方便。
33、蜈蚣事實表--centipede fact table
蜈蚣事實表是指那些一張事實表中有太多維度的事實表。連接在事實表兩邊的維度表過多，看起來就像蜈蚣一樣，所以稱爲“蜈蚣事實表”。通常來說，蜈蚣事實表的出現是由於建模師對事實表和維度表逆規範化過了頭。不單將產品主鍵放入事實表中，對於產品層級結構中的每一層的主鍵都放入事實表中，這樣事實表中與產品相關的就會有產品ID、商標ID、子類ID、類別ID等多個外鍵。同樣，也有建模師將日期相關的日期ID、月ID、年ID都放入事實表中。這些都將產生蜈蚣事實表，使自己落入維度過多的陷阱。蜈蚣事實表雖然使查詢效率有所提高，但是伴之而來的是存儲空間的大量增長。在維度建模的數據倉庫中，維度表的字段個數可以儘可能的增加，但是事實表的字段要儘量減少，因爲相比而言，事實表的記錄數要遠遠大於維度表的記錄數。一般來說，事實表相關的維度在15個以下爲正常，如果維度個數超過25個，就出現了維度過多的蜈蚣事實表。這時，需要做的事情是自己覈查，將相關的維度進行合併，減少維度的個數。
34、旋轉事實表--pivoted fact table
旋轉事實表是將一條記錄中的多個事實字段轉化爲多條記錄，其中每條記錄保存一個事實字段的一種建模方法。或者反過來，也可以由多條記錄轉化爲一條記錄。旋轉事實表建模方法的使用通常是爲了簡化前端數據展現的查詢。它通過改變後端的事實記錄存儲方式，使相應的查詢需求的性能得到的極大的提高。如果在SQL或者查詢工具中進行這種轉換會非常麻煩，效率也很差。和合並事實表類似，有時當基礎表中沒有記錄時，旋轉事實表也要存儲一些零值在裏面。
35、一致性事實--comformed fact
一致性事實是Kimball的多維體系結構（MD）中的三個關鍵性概念之一，另兩個是總線架構（Bus Architecture）和一致性維度（Conformed Dimension）。在建立多個數據集市時，完成一致性維度的工作就已經完成了一致性的80%－90%的工作量。餘下的工作就是建立一致性事實。一致性事實和一致性維度有些不同，一致性維度是由專人維護在後臺（Back Room），發生修改時同步複製到每個數據集市，而事實表一般不會在多個數據集市間複製。需要查詢多個數據集市中的事實時，一般通過交叉探查（drill across）來實現。爲了能在多個數據集市間進行交叉探查，一致性事實主要需要保證兩點。第一個是KPI的定義及計算方法要一致，第二個是事實的單位要一致性。如果業務要求或事實上就不能保持一致的話，建議不同單位的事實分開建立字段保存。一致性維度將多個數據集市結合在一起，一致性事實保證不同數據集市間的事實數據可以交叉探查，一個分佈式的數據倉庫就建成了。
36、一致性維度--comformed dimension
在多維體系結構中，沒有物理上的數據倉庫，由物理上的數據集市組合成邏輯上的數據倉庫。而且數據集市的建立是可以逐步完成的，最終組合在一起，成爲一個數據倉庫。如果分步建立數據集市的過程出現了問題，數據集市就會變成孤立的集市，不能組合成數據倉庫，而一致性維度的提出正式爲了解決這個問題。一致性維度的範圍是總線架構中的維度，即可能會在多個數據集市中都存在的維度，這個範圍的選取需要架構師來決定。一致性維度的內容和普通維度並沒有本質上區別，都是經過數據清洗和整合後的結果。一致性維度建立的地點是多維體系結構的後臺（Back Room），即數據準備區。在多維體系結構的數據倉庫項目組內需要有專門的維度設計師，他的職責就是建立維度和維護維度的一致性。在後臺建立好的維度同步複製到各個數據集市。這樣所有數據集市的這部分維度都是完全相同的。建立新的數據集市時，需要在後臺進行一致性維度處理，根據情況來決定是否新增和修改一致性維度，然後同步複製到各個數據集市。這是不同數據集市維度保持一致的要點。在同一個集市內，一致性維度的意思是兩個維度如果有關係，要麼就是完全一樣的，要麼就是一個維度在數學意義上是另一個維度的子集。例如，如果建立月維度話，月維度的各種描述必須與日期維度中的完全一致，最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集，在後續鑽取等操作時可以保持一致。如果維度表中的數據量較大，出於效率的考慮，應該建立物化視圖或者實際的物理表。維度保持一致後，事實就可以保存在各個數據集市中。雖然在物理上是獨立的，但在邏輯上由一致性維度使所有的數據集市是聯繫在一起，隨時可以進行交叉探察等操作，也就組成了數據倉庫。☆☆☆☆
37、預連接聚集表--pre-joined aggregate table
預連接聚集表是通過對事實表和維度表的聯合查詢而生成的一類彙總表。在預連接聚集表中，保存有維度表中的描述信息和事實表的事實值。通過預連接，可以避免在用戶查詢時RDBMS的連接操作，所以預連接聚集表的查詢效率要高很多。典型的預連接聚集表如下例所示的銷售事實表：
產品名稱、商標名稱、年份、月份、銷售人員名稱、銷售量、銷售金額在這個銷售事實表，前五個字段都來自於維度表的描述字段，後兩個字段來自於事實表的事實字段。這樣在用戶提交查詢後，RDBMS就不需要連接維度表和事實表了，只需直接在該表中查詢即可。預連接聚集表有一個很大的缺點，它需要佔用大量的存儲空間。預連接事實表的記錄和事實表一樣多，每條記錄的長度和維度表一樣長，所以對存儲空間的需求是非常大的。除非情況特殊，或者該表是高度彙總的，否則不建議建立預連接聚集表。在建立預連接聚集表時需要平衡效率和存儲空間的矛盾。預連接聚集表的生成方式較爲簡單，直接使用SQL查詢即可生成。如果聚集導航器的功能很強大的話，也可以處理預連接聚集表。否則，需要用戶理解預連接聚集表，並在SQL中直接使用該表。預連接聚集表在數據倉庫領域有着很重要的作用，是彙總表的一種。它的優點和缺點都很明顯，在使用時需要綜合考慮。
38、雜項維度--junk dimension
雜項維度是由操作系統中的指示符或者標誌字段組合而成，一般不在一致性維度之列。在操作系統中，我們定義好各種維度後，通常還會剩下一些在小範圍內取離散值的。