資料倉庫基礎術語名詞一覽

冰山查詢――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