冰山查詢――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能力。
操作集市――oper mart
在數據倉庫領域有一個概念叫Oper Mart，中文一般翻譯爲“操作集市”。操作集市是爲了企業戰術性的分析提供支持，它的數據來源是操作數據存儲（ODS）。它是ODS在分析功能上的擴展，使用戶可以對操作型數據進行多維分析。
一個操作集市應該有如下特徵：
1．操作集市是ODS的子集，數據來源於ODS，用於戰略分析和報表。
2．操作集市中的數據和ODS中的數據同步更新。
3．操作集市以多維技術進行建模，即星型結構。
4．操作集市是一個臨時的結構，當不在需要時會清掉所有數據，即不保存歷史數據。
操作集市和數據集市很相似，但是它不能用來取代用於戰略性分析的數據集市。由於操作集市的數據來源於ODS，所以它的數據比數據集市的數據要新。但是出於容量的考慮，操作集市中不保存歷史數據，是一個臨時的結構。
操作數據存儲――operational data store
Kimball對操作數據存儲的定義是，面向主題的、集成的、經常更新的細節數據存儲，用集成的數據來支持事務系統。Kimball也認可Inmon對ODS的分類，但是他認爲ODS應該以星型結構來進行建模。
雖然Kimball對操作數據存儲（ODS）的定義和Inmon基本上一樣，但是他對操作數據存儲的理解、作用與實現和Inmon有着較大的不同。
Kimball認爲ODS在兩種情況下是需要的：第一種情況是提供操作型報表，這些報表需要提供面向主題的、集成的數據，所以操作型的源系統無法提供；這些報表和數據倉庫中的報表也不相同，因爲它們可以是一些定製好的，寫死在程序中的報表。第二種情況是需要提供實時的信息時，由於數據倉庫的更新頻率一般都是24小時，而用戶會有更急切的需求來了解數據源的信息，這時，建立操作數據存儲是很有必要的。
對於ODS是保存最細粒度數據的地方的說法，Kimball認爲對於最細粒度數據，即原子數據層，應該保存在數據倉庫中，而且應該置於維度框架和總線架構中。
代理關鍵字－－surrogate key
在數據倉庫領域有一個概念叫Surrogate key，中文一般翻譯爲“代理關鍵字”。代理關鍵字一般是指維度表中使用順序分配的整數值作爲主鍵，也稱爲“代理鍵”。代理關鍵字用於維度表和事實表的連接。
代理關鍵字的稱呼有surrogate keys，meaningless keys，integer keys，nonnatural keys，artificial keys，synthetic keys等。與之相對的自然關鍵字的稱呼有natural keys，samat keys等。
在Kimball的維度建模領域裏，是強烈推薦使用代理關鍵字的。在維度表和事實表的每一個聯接中都應該使用代理關鍵字，而不應該使用自然關鍵字或者智能關鍵字（Smart Keys）。數據倉庫中的主鍵不應該是智能的，也就是說，要避免通過主鍵的值就可以瞭解一些業務信息。當然，退化維度作爲事實表的複合主鍵之一時例外。
使用代理關鍵字，有很多優點。
1．使用代理關鍵字能夠使數據倉庫環境對操作型環境的變化進行緩衝。也就是說，當數據倉庫需要對來在多個操作型系統的數據進行整合時，這些系統中的數據有可能缺乏一致的關鍵字編碼，即有可能出現重複，這時代理關鍵字可以解決這個問題。
2．使用代理關鍵字可以帶來性能上的優勢。和自然關鍵字相比，代理關鍵字很小，是整型的，可以減小事實表中記錄的長度。這樣，同樣的IO就可以讀取更多的事實表記錄。另外，整型字段作爲外鍵聯接的效率也很高。
3．使用代理關鍵字可以建立一些不存在的維度記錄，例如“不在促銷之列”，“日期待定”，“日期不可用”等維度記錄。
4．使用代理關鍵字可以用來處理緩慢變化維。維度表數據的歷史變化信息的保存是數據倉庫設計的實施中非常重要的一部分。Kimball的緩慢變化維處理策略的核心就是使用代理關鍵字。
當然，使用代理關鍵字也有它的缺點，代理關鍵字的使用使數據加載變得非常複雜。有關使用代理關鍵字的維度表和事實表的加載方法在ETL Toolkit中有詳細的描述。使用代理關鍵字是一個從長遠考慮的策略。
多值維度――multivalue dimension
在維度建模的數據倉庫中，有一種維度表叫multivalue dimension，中文一般翻譯爲“多值維度”。
多值維度有兩種情況，第一種情況是指維度表中的某個屬性字段同時有多個值。舉例來說，一個帳戶維度表中，帳戶持有人姓名，可能會有多個顧客。這樣，一個帳戶對應多個顧客姓名，一個顧客也可以有多個帳戶，它們之間是多對多的關係。正因爲一個帳戶可能會有多個對應的顧客，所以不能直接將顧客ID放入帳戶維度表中。而帳戶維度表中的這種情況就叫做多值維度。
多值維度的第二種情況是事實表在某個維度表中有多條對應記錄。舉例來說，對於一個健康護理單分列項事實表來說，它的粒度是一個健康護理單，但是該護理單卻有可能有多次診斷，即該事實表與診斷維度的是一對多的關係。這個與事實表粒度不匹配的診斷維度也稱之爲多值維度。
處理多值維度最好的辦法是降低事實表的粒度。如第二種情況中，將健康護理單分列項事實表的粒度降低到具體的診斷粒度上，這樣就避免了多值維度的出現。這種處理方式也是維度建模的一個原則，即事實表應該建立在最細粒度上。這樣的處理，需要對事實表的事實進行分攤。
但是有些時候，事實表的粒度是不能降低的，多值維度的出現是無法避免的。如第一種情況中，事實表是月帳戶快照事實表，這張事實表與顧客維度沒有直接的關係，不能將數據粒度進行細分，即使細分的話帳戶餘額也很難分攤。這時，可以採用橋接表技術進行處理。在帳戶維度表和顧客維度表之間建立個帳戶-顧客橋接表。這個橋接表可以解決掉帳戶維度和顧客維度之間的多對多關係，也解決掉的帳戶維度表的多值維度問題。
總之，多值維度是應該儘量避免的，它給數據處理帶來了很大的麻煩。如果多值維度不能避免的話，應該建立橋接表來進行處理。
非事實型事實表――factless fact table
在維度建模的數據倉庫中，有一種事實表叫Factless Fact Table，中文一般翻譯爲“非事實型事實表”。在事實表中，通常會保存十個左右的維度外鍵和多個度量事實，度量事實是事實表的關鍵所在。在非事實型事實表中沒有這些度量事實，只有多個維度外鍵。非事實型事實表通常用來跟蹤一些事件或者說明某些活動的範圍。下面舉例來進行說明。
第一類非事實型事實表是用來跟蹤事件的事實表。例如：學生註冊事件，學校需要對學生按學期進行跟蹤。維度表包括學期維度、課程維度、系維度、學生維度、註冊專業維度和取得學分維度，而事實表是由這些維度的主鍵組成，事實只有註冊數，並且恆爲1。這樣的事實表可以回答大量關於大學開課註冊方面的問題，主要是回答各種情況下的註冊數。
第二類非事實型事實表是用來說明某些活動範圍的事實表。例如：促銷範圍事實表。通常銷售事實表可以回答如促銷商品的銷售情況，但是對於那些沒有銷售出去的促銷商品沒法回答。這時，通過建立促銷範圍事實表，將商場需要促銷的商品單獨建立事實表保存。然後，通過這個促銷範圍事實表和銷售事實表即可得出哪些促銷商品沒有銷售出去。這樣的促銷範圍事實表只是用來說明促銷活動的範圍，其中沒有任何事實度量。
合併事實表－－consolidated/ merged fact table
在數據倉庫領域有一個概念叫merged fact table，或者consolidated fact table，中文一般都翻譯爲“合併事實表”。合併事實表是將不同事實表的事實合併到同一張事實表的建模方法，合併的事實要保證在相同的粒度。
這種建模方法通常被用來橫跨多個業務主題域來建立數據集市，Kimball將這樣的數據集市稱爲第二級的數據集市。使用合併事實表技術，可以避免性能較差的交叉探察操作。
但是，這種合併事實表和使用交叉探察操作還有着細微的不同，在一些基礎表中沒有記錄的時候，合併事實表中可能會存儲一條記錄，字段值保存爲零。
合併事實表可以給數據倉庫帶來很大的性能提升，提供的跨主題的事實數據也給用戶帶來了很大的方便。但是，合併事實表給ETL工作帶來了較大的麻煩。對於合併事實表中涉及到的維度，需要在數據準備區保證它們是一致性維度。
緩慢變化維――slowly changing dimension
維度建模的數據倉庫中，有一個概念叫Slowly Changing Dimensions，中文一般翻譯成“緩慢變化維”，經常被簡寫爲SCD。緩慢變化維的提出是因爲在現實世界中，維度的屬性並不是靜態的，它會隨着時間的流失發生緩慢的變化。這種隨時間發生變化的維度我們一般稱之爲緩慢變化維，並且把處理維度錶的歷史變化信息的問題稱爲處理緩慢變化維的問題，有時也簡稱爲處理SCD的問題。
處理緩慢變化維的方法通常分爲三種方式。
第一種方式是直接覆蓋原值。這樣處理，最容易實現，但是沒有保留歷史數據，無法分析歷史變化信息。第一種方式通常簡稱爲“TYPE 1”。
第二種方式是添加維度行。這樣處理，需要代理鍵的支持。實現方式是當有維度屬性發生變化時，生成一條新的維度記錄，主鍵是新分配的代理鍵，通過自然鍵可以和原維度記錄保持關聯。第二種方式通常簡稱爲“TYPE 2”。
第三種方式是添加屬性列。這種處理的實現方式是對於需要分析歷史信息的屬性添加一列，來記錄該屬性變化前的值，而本屬性字段使用TYPE 1來直接覆蓋。這種方式的優點是可以同時分析當前及前一次變化的屬性值，缺點是隻保留了最後一次變化信息。第三種方式通常簡稱爲“TYPE 3”。
在實際建模中，我們可以聯合使用三種方式，也可以對一個維度表中的不同屬性使用不同的方式，這些，都需要根據實際情況來決定，但目的都是一樣的，就是能夠支持方便的分析歷史變化情況。
即席查詢――ad hoc queries
在數據倉庫領域有一個概念叫Ad hoc queries，中文一般翻譯爲“即席查詢”。即席查詢是指那些用戶在使用系統時，根據自己當時的需求定義的查詢。
即席查詢生成的方式很多，最常見的就是使用即席查詢工具。一般的數據展現工具都會提供即席查詢的功能。通常的方式是，將數據倉庫中的維度表和事實表映射到語義層，用戶可以通過語義層選擇表，建立表間的關聯，最終生成SQL語句。
即席查詢與通常查詢從SQL語句上來說，並沒有本質的差別。它們之間的差別在於，通常的查詢在系統設計和實施時是已知的，所有我們可以在系統實施時通過建立索引、分區等技術來優化這些查詢，使這些查詢的效率很高。而即席查詢是用戶在使用時臨時生產的，系統無法預先優化這些查詢，所以即席查詢也是評估數據倉庫的一個重要指標。
即席查詢的位置通常是在關係型的數據倉庫中，即在EDW或者ROLAP中。多維數據庫有自己的存儲方式，對即席查詢和通常查詢沒有區別。
在一個數據倉庫系統中，即席查詢使用的越多，對數據倉庫的要求就越高，對數據模型的對稱性的要求也越高。對稱性的數據模型對所有的查詢都是相同的，這也是維度建模的一個優點。
交叉探察――drill across
在維度建模的數據倉庫中，有一種操作叫Drill Across ，中文一般翻譯爲“交叉探查”。
在基於總線架構（Bus Architecture）的維度建模中，大部分的維度表是由事實表共有的。比如“營銷事務事實表”和“庫存快照事實表”就會有相同的維度表，“日期維度”、“產品維度”和“商場維度”。這時，如果有個需求是想按共有維度來對比查看銷售和庫存的事實，這時就需要發出兩個SQL，分別查出按維度統計出的銷售數據和庫存數據。然後再基於共有的維度進行外連接，將數據合併。這種發出多路SQL再進行合併的操作就是交叉探查。
當這種交叉探查的需求很常用時，有一種建模方法可以避免交叉探查，就是合併事實表（Consolidated Fact Table）。合併事實表是指將位於不同事實表中處於相同粒度的事實進行組合的一種建模方法。即新建立一個事實表，它的維度是兩個或多個事實表的相同維度的集合，事實是幾個事實表中感興趣的事實。這個事實表的數據和其他事實表的數據一樣來自Staging Area。
合併事實表在性能和易用性上都比交叉探查要好，但是被組合的事實表必須處於相同的粒度和維度層次上。
角色模仿維度－－role-playing dimensions
在數據倉庫領域有一個概念叫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
切片事實表－－sliced fact table
在數據倉庫領域有一個概念叫sliced fact table，中文一般翻譯爲“切片事實表”。切片事實表中的字段結構和相應的基礎表完全相同，差別在於存儲的記錄的範圍。切片事實表中保存記錄的是相應基礎表中記錄的子集，記錄數通常與某個維度記錄數相同。
這種建模方法一般用來滿足特殊需要，如需要分析某些特殊問題時，可以將與之相關的數據切片出來。相反，這種方法也常用於合併存儲在不同地區的數據，即各個地區都保存自己地區的數據，總部和所有地區的表結構都相同，然後總部將所有地區的數據合併在一起。
切片事實表的結構與相對應的基礎表相同，數據來源於相對應的基礎表。切片事實表由於縮小了表中數據的記錄數，所以查詢的效率得到了很大的提高。
事實表――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的總線架構中，由合併事實表爲主組成的合併數據集市稱爲二級數據集市。合併事實表的粒度可以是原子粒度也可以是聚集粒度。在做數據遷移時，當相關的原子事實表的數據有改變時，合併事實表的數據需要重新刷新。合併事實表和交叉探察是兩個互補的操作。
聚集事實表和合並事實表的主要差別是合併事實表一般是從多個事實表合併而來。但是它們的差別不是絕對的，一個事實表既是聚集事實表又是合併事實表是很有可能的。因爲一般合併事實表需要按相同的維度合併，所以很可能在做合併的同時需要進行聚集，即粒度變粗。
事實維度－－fact dimension
事務事實表－－transaction fact table
審計維度－－audit dimension
數據世系――data lineage
數據倉庫中有一個概念叫做Data Lineage，中文一般翻譯爲“數據世系”。數據世系描述的是從源系統抽取數據開始，經過數據轉換到最終的數據加載的整個過程中各種信息。
數據世系信息需要留下詳細的文檔記載。數據世系包括源系統的數據庫中數據定義以及該數據在數據倉庫中的最終位置等信息。
數據世系是數據倉庫的元數據中最重要的一部分。這部分元數據的產生位置是在ETL的處理過程中。
如果在ETL的處理過程中使用的ETL工具的話，ETL工具可以記錄下元數據的一部分，但是這部分一般都是數據的屬性描述，而不是完全的數據世系。換一句說，完全依靠ETL工具來維護元數據是不夠的。
雙桶連接－－double-barreled joins
退化維度――degenerate dimension
在維度建模的數據倉庫中，有一種維度叫Degenerate Dimension，中文一般翻譯爲“退化維度”。這種退化維度一般都是事務的編號，如訂單編號、發票編號等。這類編號需要保存到事實表中，但是不需要對應的維度表，所以稱爲退化維度。
退化維度是維度建模領域中的一個非常重要的概念，它對理解維度建模有着非常重要的作用，尤其是對維度建模的入門者。
退化維度經常會和其他一些維度一起組合成事實表的主鍵。在Kimball提出的維度建模中，事實表應該保存最細粒度的數據。所以對於象銷售單這樣的事實表來說，需要銷售單編號和產品來共同作爲主鍵，而不能用銷售日期、商場、產品等用來分析的維度共同作爲主鍵。
退化維度在分析中可以用來做分組使用。它可以將同一個事務中銷售的產品集中在一起。
微型維度――minidimension
維度建模的數據倉庫中，有一種維度叫minidimension，中文一般翻譯成“微型維度”。微型維度的提出主要是爲了解決快變超大維度（rapidly changing monster dimension）。
以客戶維度舉例來說，如果維度表中有數百萬行記錄或者還要多，而且這些記錄中的字段又經常變化，這樣的維度表一般稱之爲快變超大維度。對於快變超大維度，設計人員一般不會使用TYPE 2的緩慢變化維處理方法，因爲大家都不願意向本來就有幾百萬行的維度表中添加更多的行。
這時，有一項技術可以解決這個問題。解決的方法是，將分析頻率比較高或者變化頻率比較大的字段提取出來，建立一個單獨的維度表。這個單獨的維度表就是微型維度表。
微型維度表有自己的關鍵字，這個關鍵字和原客戶維度表的關鍵字一起進入事實表。有時爲了分析的方便，可以把微型維度的關鍵字的最新值作爲外關鍵字進入客戶維度表。這時一定要注意，這個外關鍵字必須做TYPE 1型處理。
在微型維度表中如果有像收入這樣分佈範圍較廣的屬性時，應該將它分段處理。比如，存儲￥31257.98這樣過於分散的數值就不如存儲￥30000－￥34999這樣的範圍。這樣可以極大的減少微型維度中的記錄數目，也給分析帶來方便。
蜈蚣事實表――centipede fact table
在數據倉庫領域有一個概念叫Centipede fact table，中文一般翻譯爲“蜈蚣事實表”。蜈蚣事實表是指那些一張事實表中有太多維度的事實表。連接在事實表兩邊的維度表過多，看起來就像蜈蚣一樣，所以稱爲“蜈蚣事實表”。
通常來說，蜈蚣事實表的出現是由於建模師對事實表和維度表逆規範化過了頭。例如，不單將產品主鍵放入事實表中，對於產品層級結構中的每一層的主鍵都放入事實表中，這樣事實表中與產品相關的就會有產品ID、商標ID、子類ID、類別ID等多個外鍵。同樣，也有建模師將日期相關的日期ID、月ID、年ID都放入事實表中。這些都將產生蜈蚣事實表，使自己落入維度過多的陷阱。
蜈蚣事實表雖然使查詢效率有所提高，但是伴之而來的是存儲空間的大量增長。在維度建模的數據倉庫中，維度表的字段個數可以儘可能的增加，但是事實表的字段要儘量減少，因爲相比而言，事實表的記錄數要遠遠大於維度表的記錄數。
一般來說，事實表相關的維度在15個以下爲正常，如果維度個數超過25個，就出現了維度過多的蜈蚣事實表。這時，需要做的事情是自己覈查，將相關的維度進行合併，減少維度的個數。
稀疏事實表－－sparse facts
旋轉事實表－－pivoted fact table
在數據倉庫領域有一個概念叫pivoted fact table，中文一般翻譯爲“旋轉事實表”。旋轉事實表是將一條記錄中的多個事實字段轉化爲多條記錄，其中每條記錄保存一個事實字段的一種建模方法。或者反過來，也可以由多條記錄轉化爲一條記錄。
旋轉事實表建模方法的使用通常是爲了簡化前端數據展現的查詢。它通過改變後端的事實記錄存儲方式，使相應的查詢需求的性能得到的極大的提高。如果在SQL或者查詢工具中進行這種轉換會非常麻煩，效率也很差。
和合並事實表類似，有時當基礎表中沒有記錄時，旋轉事實表也要存儲一些零值在裏面。
一致性事實――comformed fact
維度建模的數據倉庫中，有一個概念叫Conformed Fact，中文一般翻譯爲“一致性事實”。一致性事實是Kimball的多維體系結構（MD）中的三個關鍵性概念之一，另兩個是總線架構（Bus Architecture）和一致性維度（Conformed Dimension）。
在建立多個數據集市時，完成一致性維度的工作就已經完成了一致性的80%－90%的工作量。餘下的工作就是建立一致性事實。
一致性事實和一致性維度有些不同，一致性維度是由專人維護在後臺（Back Room），發生修改時同步複製到每個數據集市，而事實表一般不會在多個數據集市間複製。需要查詢多個數據集市中的事實時，一般通過交叉探查（drill across）來實現。
爲了能在多個數據集市間進行交叉探查，一致性事實主要需要保證兩點。第一個是KPI的定義及計算方法要一致，第二個是事實的單位要一致性。如果業務要求或事實上就不能保持一致的話，建議不同單位的事實分開建立字段保存。
這樣，一致性維度將多個數據集市結合在一起，一致性事實保證不同數據集市間的事實數據可以交叉探查，一個分佈式的數據倉庫就建成了。
一致性維度――comformed dimension
維度建模的數據倉庫中，有一個概念叫Conformed Dimension，中文一般翻譯爲“一致性維度”。一致性維度是Kimball的多維體系結構（MD）中的三個關鍵性概念之一，另兩個是總線架構（Bus Architecture）和一致性事實（Conformed Fact）。
在多維體系結構中，沒有物理上的數據倉庫，由物理上的數據集市組合成邏輯上的數據倉庫。而且數據集市的建立是可以逐步完成的，最終組合在一起，成爲一個數據倉庫。如果分步建立數據集市的過程出現了問題，數據集市就會變成孤立的集市，不能組合成數據倉庫，而一致性維度的提出正式爲了解決這個問題。
一致性維度的範圍是總線架構中的維度，即可能會在多個數據集市中都存在的維度，這個範圍的選取需要架構師來決定。一致性維度的內容和普通維度並沒有本質上區別，都是經過數據清洗和整合後的結果。
一致性維度建立的地點是多維體系結構的後臺（Back Room），即數據準備區。在多維體系結構的數據倉庫項目組內需要有專門的維度設計師，他的職責就是建立維度和維護維度的一致性。在後臺建立好的維度同步複製到各個數據集市。這樣所有數據集市的這部分維度都是完全相同的。建立新的數據集市時，需要在後臺進行一致性維度處理，根據情況來決定是否新增和修改一致性維度，然後同步複製到各個數據集市。這是不同數據集市維度保持一致的要點。
在同一個集市內，一致性維度的意思是兩個維度如果有關係，要麼就是完全一樣的，要麼就是一個維度在數學意義上是另一個維度的子集。例如，如果建立月維度話，月維度的各種描述必須與日期維度中的完全一致，最常用的做法就是在日期維度上建立視圖生成月維度。這樣月維度就可以是日期維度的子集，在後續鑽取等操作時可以保持一致。如果維度表中的數據量較大，出於效率的考慮，應該建立物化視圖或者實際的物理表。
這樣，維度保持一致後，事實就可以保存在各個數據集市中。雖然在物理上是獨立的，但在邏輯上由一致性維度使所有的數據集市是聯繫在一起，隨時可以進行交叉探察等操作，也就組成了數據倉庫。
因果維度－－casual dimension
預連接聚集表――pre-joined aggregate table
在數據倉庫領域有一個概念叫pre-joined aggregagte table，中文一般翻譯爲“預連接聚集表”。預連接聚集表是通過對事實表和維度表的聯合查詢而生成的一類彙總表。在預連接聚集表中，保存有維度表中的描述信息和事實表的事實值。
通過預連接，可以避免在用戶查詢時RDBMS的連接操作，所以預連接聚集表的查詢效率要高很多。
典型的預連接聚集表如下例所示的銷售事實表，
產品名稱
商標名稱
年份
月份
銷售人員名稱
銷售量
銷售金額
在這個銷售事實表，前五個字段都來自於維度表的描述字段，後兩個字段來自於事實表的事實字段。這樣在用戶提交查詢後，RDBMS就不需要連接維度表和事實表了，只需直接在該表中查詢即可。
預連接聚集表有一個很大的缺點，它需要佔用大量的存儲空間。預連接事實表的記錄和事實表一樣多，每條記錄的長度和維度表一樣長，所以對存儲空間的需求是非常大的。除非情況特殊，或者該表是高度彙總的，否則不建議建立預連接聚集表。在建立預連接聚集表時需要平衡效率和存儲空間的矛盾。
預連接聚集表的生成方式較爲簡單，直接使用SQL查詢即可生成。
如果聚集導航器的功能很強大的話，也可以處理預連接聚集表。否則，需要用戶理解預連接聚集表，並在SQL中直接使用該表。
預連接聚集表在數據倉庫領域有着很重要的作用，是彙總表的一種。它的優點和缺點都很明顯，在使用時需要綜合考慮。
原子事實表－－atom fact table
雜項維度――junk dimension
在維度建模的數據倉庫中，有一種維度叫Junk Dimension，中文一般翻譯爲“雜項維度”。雜項維度是由操作系統中的指示符或者標誌字段組合而成，一般不在一致性維度之列。
在操作系統中，我們定義好各種維度後，通常還會剩下一些在小範圍內取離散值的指示符或者標誌字段。例如：支付類型字段，包括現金和信用卡兩種類型，在源系統中它們可能是維護在類型表中，也可能直接保存在交易表中。
一張事實表中可能會存在好幾個類似的字段，如果作爲事實存放在事實表中，會導致事實表佔用空間過大；如果單獨建立維度表，外鍵關聯到事實表，會出現維度過多的情況；如果將這些字段刪除，會有人不同意。
這時，我們通常的解決方案就是建立雜項維度，將這些字段建立到一個維度表中，在事實表中只需保存一個外鍵。幾個字段的不同取值組成一條記錄，生成代理鍵，存入維度表，並將該代理鍵保存入相應的事實表字段。建議不要直接使用所有的組合生成完整的雜項維度表，在抽取時遇到新的組合時生成相應記錄即可。雜項維度的ETL過程比一般的維度略爲複雜。
總線架構――bus architecture
維度建模的數據倉庫中，有一個概念叫Bus Architecture，中文一般翻譯爲“總線架構”。總線架構是Kimball的多維體系結構（MD）中的三個關鍵性概念之一，另兩個是一致性維度（Conformed Dimension）和一致性事實（Conformed Fact）。
在多維體系結構（MD）的數據倉庫架構中，主導思想是分步建立數據倉庫，由數據集市組合成企業的數據倉庫。但是，在建立第一個數據集市前，架構師首先要做的就是設計出在整個企業內具有統一解釋的標準化的維度和事實，即一致性維度和一致性事實。而開發團隊必須嚴格的按照這個體系結構來進行數據集市的迭代開發。
一致性維度就好比企業範圍內的一組總線，不同數據集市的事實的就好比插在這組總線上的元件。這也是稱之爲總線架構的原因。
實際設計過程中，我們通常把總線架構列表成矩陣的形式，其中列爲一致性維度，行爲不同的業務處理過程，即事實，在交叉點上打上標記表示該業務處理過程與該維度相關。這個矩陣也稱爲總線矩陣（Bus Matrix）。
總線架構和一致性維度、一致性事實共同組成了Kimball的多維體系結構的基礎，也建立了一套可以逐步建立數據倉庫的方法論。由於總線架構是多維體系結構的核心，所以我們有時就把多維體系結構直接稱爲總線架構。
支架維度－－outrigger dimension
週期快照事實表－－periodic snapshot fact table