BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模目目錄1.如何構建BI數據倉庫設計中的幾個重要概念維度操作型數據

如：某商場1瓶價格為88元的葡萄酒在被購買的過程中，收銀員實際收到100元，找零12元。特點：細節化，分散化關鍵概念2.操作型數據關鍵概念2.關鍵概念決策型數據如：該商場在1月9日上午一共賣出了多少瓶葡萄酒?該商場的所有葡萄酒總銷量在一年中什么時候最高和最低?

特點：綜合化，集成化3.關鍵概念決策型數據3.企業對應用集成的需求我要了解企業目前的運轉情況！（實時監控）我要知道某地區近5年內的銷售情況以制定未來的發展策略！（決策支持）我要知道哪些是值得發展的優質的顧客！（預測）4.企業對應用集成的需求我要了解企業目前的運轉情況！（實時監控）BI應用帶來的關鍵效益洞察力獲得對業務績效，流程和客戶的可見性和洞察力更好的進行決策和執行決策，以快速應對機會和挑戰協同一致橫跨多個業務和數據源，獲得唯一的、一致的企業信息在各業務層面中協同戰略和執行5.BI應用帶來的關鍵效益洞察力5.BI應用帶來的關鍵效益中層管理分析:專注點是

績效的戰術應用與目標相比，我做的如何?問題在哪里高層領導分析:專注點是計劃戰略&目標制定業務發展得如何，我們下一步該往哪里走通過集成實時與歷史數據，將分析轉換為執行力一線分析:專注點是執行有效性與行動我每天要做哪3-5件事情哪些信息能讓我更有效地執行這些行動?回答問題:我現在該做哪些事情?6.BI應用帶來的關鍵效益中層管理分析:專注點是績效的戰術應數據倉庫的概念數據倉庫（DataWarehouse）是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支撐管理決策。7.數據倉庫的概念數據倉庫（DataWarehouse）是一個

BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模目目錄8.如何構建BI數據倉庫設計中的幾個重要概念維度

BI應用架構

BI應用9.

BI應用架構

BI應用9.

BI系統架構

Microsoft

OfficeBIServerBIPresentationServer交互式信息板即席查詢報表分析預警提醒商務智能應用前端展示層商務智能服務層前端展示層應用服務層數據庫層ERP系統其他應用系統財務平臺ExcelXML業務流程數據源層商務智能應用模型架構：

財務、銷售、訂單、

服務、市場、供應鏈、

人力ETL商務智能應用數據

存儲星型模型DWCube10.

BI系統架構

Microsoft

OfficeBISe構建BI涉及的開發工具查詢工具

與

電子制表

ETL與元數據管理報表與文檔管理OLAP

多維分析Data

Mining

數據挖掘Portal

門戶網站

主流產品：ETL：Informatica、Datastage、Kettle、SSIS……前端展現：OracleBIEE、BusinessObject、MicroStregy、

Cognos、OracleEssbase、SmartBI……整體解決方案：OracleBIApps11.構建BI涉及的開發工具查詢工具

與

電子制表

ETL與元數數據倉庫設計中的幾個重要概念ETLETL是將業務系統的數據經過抽取（Extract）、清洗轉換（Transform）之后加載（Load）到數據倉庫的過程，目的是將企業中的分散、零亂、標準不統一的數據整合到一起，為企業的決策提供分析依據。ETL是BI項目重要的一個環節。通常情況下，在BI項目中ETL會花掉整個項目的1/3的時間,ETL設計的好壞直接關接到BI項目的成敗。

ETL的實現有多種方法，常用的有三種。一種是借助ETL工具實現，一種是SQL方式實現，另外一種是ETL工具和SQL相結合。前兩種方法各有各的優缺點，借助工具可以快速的建立起ETL工程，屏蔽了復雜的編碼任務，提高了速度，降低了難度，但是缺少靈活性。SQL的方法優點是靈活，提高ETL運行效率，但是編碼復雜，對技術要求比較高。第三種是綜合了前面二種的優點，會極大地提高ETL的開發速度和效率。12.數據倉庫設計中的幾個重要概念ETL12.數據倉庫設計中的幾個重要概念數據集市（Datamart）也叫做“小數據倉庫”。如果說數據倉庫是建立在企業級的數據模型之上的話，那么數據集市就是企業級數據倉庫的一個子集，他主要面向部門級業務，并且只面向某個特定的主題。數據集市可以在一定程度上緩解訪問數據倉庫的瓶頸。

即席查詢（Adhocqueries）是指那些用戶在使用系統時，根據自己當時的需求定義的查詢。即席查詢生成的方式很多，最常見的就是使用即席查詢工具。一般的BI展現工具都會提供即席查詢的功能。通常的方式是，將數據倉庫中的維度表和事實表映射到語義層，用戶可以通過語義層選擇表，建立表間的關聯，最終生成SQL語句。即席查詢與通常查詢從SQL語句上來說，并沒有本質的差別。它們之間的差別在于，通常的查詢在系統設計和實施時是已知的，所有我們可以在系統實施時通過建立索引、分區等技術來優化這些查詢，使這些查詢的效率很高。而即席查詢是用戶在使用時臨時生產的，系統無法預先優化這些查詢，所以即席查詢也是評估數據倉庫的一個重要指標。

13.數據倉庫設計中的幾個重要概念數據集市（Datamart）1數據倉庫設計中的幾個重要概念ODS（

OperationalDataStore,操作數據存儲）

ODS在通常的數據倉庫架構中都是一個可選的部件，它和數據倉庫起到互相補充的作用。最早給ODS下定義的是數據倉庫之父Inmon。他的定義是，操作數據存儲（ODS）是面向主題的、集成的、可變的、反映當前數據值的和詳細的數據的集合，用來滿足企業綜合的、集成的以及操作型的處理需求。

Inmon的這個定義與他對數據倉庫的定義很像。其中前兩個特性和數據倉庫是一樣的，即都是面向主題的和集成的，而后三個特性和數據倉庫相差較大。

ODS中的數據是可以變化的：這一點是Inmon相對與他的CIF（企業信息工廠）中的數據倉庫來說的，在CIF中，數據倉庫中的數據是不進行更新的，對于錯誤的處理通常是采用新的快照來進行保存。而ODS是可以按常規方法進行更新的。14.數據倉庫設計中的幾個重要概念ODS（Operational數據倉庫設計中的幾個重要概念ODS（

OperationalDataStore,操作數據存儲）ODS反映當前數據值：這一點是指ODS中不會長期的保留數據，通常ODS保留的數據的時限最長到一個月或三個月。而數據倉庫可以保留五年、十年或更長的數據。ODS中保留詳細數據：這一點是說ODS中只保留原子數據，而不保留匯總數據。而在數據倉庫中原子數據和匯總數據都會進行保留。這和ODS可更新的特性相關，因為隨時可能將操作型系統的數據變化更新到ODS中，并且數據的遷移時間間隔會很短，這都使匯總數據在ODS中的意義不大。15.數據倉庫設計中的幾個重要概念ODS（Operational數據倉庫設計中的幾個重要概念ExternalDataODSCentralDataWarehouseDataMartDataMartDataMartDataMartCentralDataWarehouseExternalDataODSpartpartpartpartpartpart1.建造企業數據倉庫建設中心數據模型一次性的完成數據的重構工作最小化數據冗余度和不一致性存儲詳細的歷史數據2.從企業數據倉庫中建造數據集市得到大部分的集成數據直接依賴于數據倉庫的可用性1.創建部門的數據集市范圍局限于一個主題區域快速的ROI--局部的商業需求得到滿足本部門自治--設計上具有靈活性對其他部門數據集市是一個好的指導容易復制到其他部門需要為每個部門做數據重建有一定級別的冗余和不一致性2.擴大到企業數據倉庫創建EDB作為一個長期的目標投資效益的時間?

建設中心數據模型的必要性和可能性?

初始費用?自上而下VS自下而上數據集市的數據都是可用的嗎?

能生成數據模型嗎?

如何解決不一致性?16.數據倉庫設計中的幾個重要概念ExternalODSCentr目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程17.目錄BI的價值17.基礎術語事實表是指其中保存了大量業務度量數據的表。事實表中的度量值一般稱為事實。在事實表中最有用的事實就是數字類型的事實和可加類型的事實。事實表的粒度決定了數據倉庫中數據的詳細程度。一般事實表中只存放數字或者一些Flag用來統計(Count)，如收益、數量、支出等銷售事實收益數量支出毛利…事實表（FactTable）18.基礎術語事實表是指其中保存了大量業務度量數據的表。事實表中的基礎術語維度表可以看作是用戶分析數據的窗口，維度表中包含事實數據表中事實記錄的特性，有些特性提供描述性信息，有些特性指定如何匯總事實數據表數據，以便為分析者提供有用的信息。客戶維時間維商場維產品維銷售事實時間ID客戶ID產品ID商場ID收益數量支出毛利…維度表（DimensionTable）19.基礎術語維度表可以看作是用戶分析數據的窗口，維度表中包含事實基礎術語粒度是指數據倉庫中數據的細化或綜合程度的級別，也就是數據的詳細程度。細節程度越高，粒度級就越低，反之亦然。我可以用很多的數據，但同樣我也可以只用必需的數據。而這起決于存儲器。如果有很大的硬盤，那就沒有我們不能存的事情。設計粒度是設計數據倉庫中的一個重要前提粒度（Grain）高細化低細化每月200個記錄每月40,000個字節每月一個記錄每月200個字節通過檢索可以回答無細節無法回答詢問某一電話的細節20.基礎術語粒度是指數據倉庫中數據的細化或綜合程度的級別，也就是基礎術語粒度是指數據倉庫中數據的細化或綜合程度的級別，也就是數據的詳細程度。細節程度越高，粒度級就越低，反之亦然。我可以用很多的數據，但同樣我也可以只用必需的數據。而這起決于存儲器。如果有很大的硬盤，那就沒有我們不能存的事情。設計粒度是設計數據倉庫中的一個重要前提粒度（Grain）高度綜合級輕度綜合級(數據集市)銷售細節級2000-2001操作型轉換每月銷售1994-2001每周銷售1994-2001當前細節級21.基礎術語粒度是指數據倉庫中數據的細化或綜合程度的級別，也就是目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程22.目錄BI的價值22.建模中的三種模型星形模型(StarSchema)雪花模型(SnowflakeSchema)多維模型(Multi-dimensionSchema)23.建模中的三種模型星形模型(StarSchema)23.建模中的三種模型事實表被維度所包圍，維表和事實表通過主關鍵字和外關鍵字聯系在一起，且維度沒有被新的表連接客戶維時間維商場維產品維銷售事實時間ID客戶ID產品ID商場ID收益數量支出毛利…星形模型（StarSchema）24.建模中的三種模型事實表被維度所包圍，維表和事實表通過主關鍵字建模中的三種模型事實表被多個維表或一個或多個層次所包圍，雪花模型一般在處理大的且相對靜態的層次的時候使用雪花模型（SnowflakeSchema）客戶維時間維商場維產品維銷售事實時間ID客戶ID產品ID商場ID收益數量支出毛利…聯系人維區域維25.建模中的三種模型事實表被多個維表或一個或多個層次所包圍，雪花目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程26.目錄BI的價值26.維度的類型緩慢變化維(SlowlyChangingDimension)快速變化維(RapidlyChangingDimension)大維(HugeDimension)和微型維(Mini-Dimension)退化維(DegenerateDimension)27.維度的類型緩慢變化維(SlowlyChangingDim維度的類型緩慢變化維（SlowlyChangingDimensions,簡稱SCD）

緩慢變化維的提出是因為在現實世界中，維度的屬性并不是靜態的，它會隨著時間的流失發生緩慢的變化（如：組織結構的調整、客戶更改了他的名稱或地址）。這種隨時間發生變化的維度我們一般稱之為緩慢變化維，并且把處理維度表的歷史變化信息的問題稱為處理緩慢變化維的問題，有時也簡稱為處理SCD的問題。處理緩慢變化維的方法通常有三種方式：第一種方式是直接覆蓋原值，通常簡稱為“TYPE1”。這樣處理，最容易實現，但是沒有保留歷史數據，無法分析歷史變化信息。第二種方式是添加維度行，通常簡稱為“TYPE2”。這樣處理，需要代理鍵的支持。實現方式是當有維度屬性發生變化時，生成一條新的維度記錄，主鍵是新分配的代理鍵，通過自然鍵可以和原維度記錄保持關聯。第三種方式是添加屬性列，通常簡稱為“TYPE3”。這種處理的實現方式是對于需要分析歷史信息的屬性添加一列，來記錄該屬性變化前的值，而本屬性字段使用TYPE1來直接覆蓋。這種方式的優點是可以同時分析當前及前一次變化的屬性值，缺點是只保留了最后一次變化信息。28.維度的類型緩慢變化維（SlowlyChangingDim維度的類型客戶Simmy將自己的地址由原先的Addr1改為Addr2。這時我們需要將這個記錄了客戶Simmy的記錄中Address從Addr1更新為Addr2，且不記錄歷史ID:111Name:SimmyAddress:Addr1ID:111Name:SimmyAddress:Addr2OLD記錄ID為111的客戶Simmy的信息的記錄中地址直接更改為Addr2，不保存歷史Addr1緩慢變化維Type1e.g.NEW29.維度的類型客戶Simmy將自己的地址由原先的Addr1改為A維度的類型客戶Simmy將自己的地址由原先的Addr1改為Addr2。這時我們需要將這個記錄了客戶Simmy的記錄中的有效截止日期改為現在，并重新添加一條有效截止日期為現在的和一個新的版本號且Address為Addr2的記錄ID:111Version:1Name:SimmyAddress:Addr1EffectiveStartDate:2007-4-21EffectiveEndDate:NowID:111Version:2Name:SimmyAddress:Addr2EffectiveStartDate:NowEffectiveEndDate:NullID:111Version:1Name:SimmyAddress:Addr1EffectiveStartDate:2007-4-21EffectiveEndDate:Null更新為添加新的記錄緩慢變化維Type2e.g.30.維度的類型客戶Simmy將自己的地址由原先的Addr1改為A維度的類型客戶Simmy將自己的地址由原先的Addr1改為Addr2。這時我們需要將這個記錄了客戶Simmy的記錄中的現在使用的Address變為Addr2，將Addr1放入原始的字段中ID:111Name:SimmyCurrentAddress:Addr1OldAddress:NullID:111Name:SimmyCurrentAddress:Addr2OldAddress:Addr1緩慢變化維Type3e.g.31.維度的類型客戶Simmy將自己的地址由原先的Addr1改為A維度的類型快速變化維(RapidlyChangingDimension,RCD)當某個維度的變化是非常快的時候，我們認定他為快速變化維(具體要看實際的變化頻率)，比如：客戶的地址、聯系電話等。數據倉庫中最有意思的維度是一些非常大的維度，比如客戶，產品等等。一個大的企業客戶維度往往有上百萬記錄，每條記錄又有上百個字段。而大的個人客戶維度則會超過千萬條記錄，這些個人客戶維度有時也會有十多個字段，但大多數時候比較少見的維度也只有不多的幾個屬性。大維(HugeDimension)32.維度的類型快速變化維(RapidlyChangingDi維度的類型微型維(MiniDimension)

以客戶維度舉例來說，如果維度表中有數百萬行記錄或者還要多，而且這些記錄中的字段又經常變化，這樣的維度表一般稱之為快變超大維度。對于快變超大維度，設計人員一般不會使用TYPE2的緩慢變化維處理方法，因為大家都不愿意向本來就有幾百萬行的維度表中添加更多的行。這時，有一項技術可以解決這個問題。解決的方法是，將分析頻率比較高或者變化頻率比較大的字段提取出來，建立一個單獨的維度表。這個單獨的維度表就是微型維度表。微型維度表有自己的關鍵字，這個關鍵字和原客戶維度表的關鍵字一起進入事實表。有時為了分析的方便，可以把微型維度的關鍵字的最新值作為外關鍵字進入客戶維度表。這時一定要注意，這個外關鍵字必須做TYPE1型處理。在微型維度表中如果有像收入這樣分布范圍較廣的屬性時，應該將它分段處理。比如，存儲￥31257.98這樣過于分散的數值就不如存儲￥30000－￥34999這樣的范圍。這樣可以極大的減少微型維度中的記錄數目，也給分析帶來方便。33.維度的類型微型維(MiniDimension)維度的類型退化維(DegenerateDimension)

退化維度一般都是事務的編號，如訂單編號、發票編號等。這類編號需要保存到事實表中，但是不需要對應的維度表，所以稱為退化維度。退化維度經常會和其他一些維度一起組合成事實表的主鍵。在Kimball提出的維度建模中，事實表應該保存最細粒度的數據。所以對于象銷售單這樣的事實表來說，需要銷售單編號和產品來共同作為主鍵，而不能用銷售日期、商場、產品等用來分析的維度共同作為主鍵。

34.維度的類型退化維(DegenerateDimension)目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程35.目錄BI的價值35.常用的事實表類型聚集事實表（AggregatedFactTable）合并事實表（ConsolidatedFactTable）旋轉事實表（PivotedFactTable）預連接聚集表（Pre-JoinedAggregagteTable）非事實型事實表（FactlessFactTable）切片事實表（SlicedFactTable）36.常用的事實表類型聚集事實表（AggregatedFact常用的事實表類型聚集事實表（AggregatedFactTable）是原子事實表上的匯總數據，也稱為匯總事實表。即新建立一個事實表，它的維度表是比原維度表要少，或者某些維度表是原維度表的子集，如用月份維度表代替日期維度表；事實數據是相應事實的匯總，即求和或求平均值等。在做數據遷移時，當相關的維度數據和事實數據發生變化時，聚集事實表需要做相應的刷新。物化視圖是實現聚集事實表的一種有效方式，可以設定刷新方式，具體功能由DBMS來實現。37.常用的事實表類型聚集事實表（AggregatedFact常用的事實表類型合并事實表（ConsolidatedFactTable）是指將位于不同事實表中處于相同粒度的事實進行組合建模而成的一種事實表。即新建立一個事實表，它的維度是兩個或多個事實表的相同維度的集合；事實是幾個事實表中感興趣的事實。在Kimball的總線架構中，由合并事實表為主組成的合并數據集市稱為二級數據集市。合并事實表的粒度可以是原子粒度也可以是聚集粒度。在做數據遷移時，當相關的原子事實表的數據有改變時，合并事實表的數據需要重新刷新。合并事實表和交叉探察是兩個互補的操作。聚集事實表和合并事實表的主要差別是合并事實表一般是從多個事實表合并而來。但是它們的差別不是絕對的，一個事實表既是聚集事實表又是合并事實表是很有可能的。因為一般合并事實表需要按相同的維度合并，所以很可能在做合并的同時需要進行聚集，即粒度變粗。比如“營銷事務事實表”和“庫存快照事實表”就會有相同的維度表，“日期維度”、“產品維度”和“商場維度”。這時，如果有個需求是想按共有維度來對比查看銷售和庫存的事實，這時就需要發出兩個SQL，分別查出按維度統計出的銷售數據和庫存數據。然后再基于共有的維度進行外連接，將數據合并。這種發出多路SQL再進行合并的操作就是交叉探查。38.常用的事實表類型合并事實表（ConsolidatedFac常用的事實表類型旋轉事實表（PivotedFactTable）是將一條記錄中的多個事實字段轉化為多條記錄，其中每條記錄保存一個事實字段的一種建模方法。或者反過來，也可以由多條記錄轉化為一條記錄。旋轉事實表建模方法的使用通常是為了簡化前端數據展現的查詢。它通過改變后端的事實記錄存儲方式，使相應的查詢需求的性能得到的極大的提高。如果在SQL或者查詢工具中進行這種轉換會非常麻煩，效率也很差。和合并事實表類似，有時當基礎表中沒有記錄時，旋轉事實表也要存儲一些零值在里面。39.常用的事實表類型旋轉事實表（PivotedFactTab常用的事實表類型預連接聚集表（Pre-JoinedAggregagteTable）是通過對事實表和維度表的聯合查詢而生成的一類匯總表。在預連接聚集表中，保存有維度表中的描述信息和事實表的事實值。通過預連接，可以避免在用戶查詢時RDBMS的連接操作，所以預連接聚集表的查詢效率要高很多。在這個銷售事實表，前五個字段都來自于維度表的描述字段，后兩個字段來自于事實表的事實字段。這樣在用戶提交查詢后，RDBMS就不需要連接維度表和事實表了，只需直接在該表中查詢即可。產品名稱商標名稱年份月份銷售人員名稱銷售量銷售金額銷售事實表40.常用的事實表類型預連接聚集表（Pre-JoinedAggr常用的事實表類型預連接聚集表（Pre-JoinedAggregagteTable）預連接聚集表有一個很大的缺點，它需要占用大量的存儲空間。預連接事實表的記錄和事實表一樣多，每條記錄的長度和維度表一樣長，所以對存儲空間的需求是非常大的。除非情況特殊，或者該表是高度匯總的，否則不建議建立預連接聚集表。在建立預連接聚集表時需要平衡效率和存儲空間的矛盾。預連接聚集表的生成方式較為簡單，直接使用SQL查詢即可生成。如果聚集導航器的功能很強大的話，也可以處理預連接聚集表。否則，需要用戶理解預連接聚集表，并在SQL中直接使用該表。預連接聚集表在數據倉庫領域有著很重要的作用，是匯總表的一種。它的優點和缺點都很明顯，在使用時需要綜合考慮。41.常用的事實表類型預連接聚集表（Pre-JoinedAggr常用的事實表類型非事實型事實表（FactlessFactTable）事實表通常會保存十個左右的維度外鍵和多個度量事實，度量事實是事實表的關鍵所在。在非事實型事實表中沒有這些度量事實，只有多個維度外鍵。非事實型事實表通常用來跟蹤一些事件或者說明某些活動的范圍。下面舉例來進行說明：第一類非事實型事實表是用來跟蹤事件的事實表。例如：學生注冊事件，學校需要對學生按學期進行跟蹤。維度表包括學期維度、課程維度、系維度、學生維度、注冊專業維度和取得學分維度，而事實表是由這些維度的主鍵組成，事實只有注冊數，并且恒為1。這樣的事實表可以回答大量關于大學開課注冊方面的問題，主要是回答各種情況下的注冊數。第二類非事實型事實表是用來說明某些活動范圍的事實表。例如：促銷范圍事實表。通常銷售事實表可以回答如促銷商品的銷售情況，但是對于那些沒有銷售出去的促銷商品沒法回答。這時，通過建立促銷范圍事實表，將商場需要促銷的商品單獨建立事實表保存。然后，通過這個促銷范圍事實表和銷售事實表即可得出哪些促銷商品沒有銷售出去。這樣的促銷范圍事實表只是用來說明促銷活動的范圍，其中沒有任何事實度量。42.常用的事實表類型非事實型事實表（FactlessFact常用的事實表類型切片事實表（SlicedFactTable）切片事實表中的字段結構和相應的基礎表完全相同，差別在于存儲的記錄的范圍。切片事實表中保存記錄的是相應基礎表中記錄的子集，記錄數通常與某個維度記錄數相同。這種建模方法一般用來滿足特殊需要，如需要分析某些特殊問題時，可以將與之相關的數據切片出來。相反，這種方法也常用于合并存儲在不同地區的數據，即各個地區都保存自己地區的數據，總部和所有地區的表結構都相同，然后總部將所有地區的數據合并在一起。切片事實表的結構與相對應的基礎表相同，數據來源于相對應的基礎表。切片事實表由于縮小了表中數據的記錄數，所以查詢的效率得到了很大的提高。43.常用的事實表類型切片事實表（SlicedFactTabl目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程44.目錄BI的價值44.建模的一般過程確定詳細數據的粒度級別此過程必須是在建模之前最需要考慮的問題比較典型的粒度指的是單獨的，基于時間的或聚集在一個常用的維度的事務1、確定每個事實表的粒度45.建模的一般過程確定詳細數據的粒度級別1、確定每個事實表的粒度建模的一般過程確定是否需要同時存儲編號和描述，或者只是編號，或者只是描述的信息確定哪些字段的值需要被篩選掉或者需要存在2、確定維度的屬性46.建模的一般過程確定是否需要同時存儲編號和描述，或者只是編號，建模的一般過程對于時間維度，我們需要確定的是年，季度，月，周，日等不同的層次對于產品維度，我們需要確定的是產品大類，產品小類，產品等不同的層次需要注意的是比如在銷售中，地理位置的層次可能和真正的地理位置的層次會有不同3、確定維度的層次47.建模的一般過程對于時間維度，我們需要確定的是年，季度，月，周建模的一般過程通常的維度包括時間，產品，投保人，代理人，和地理等常見對象請注意，創建的維度需要和與其連接的事實的粒度保持一致4、確定每個事實所需要關聯的維度48.建模的一般過程通常的維度包括時間，產品，投保人，代理人，和地建模的一般過程需要根據具體業務來確定事實及其量度對于每個聚合事實需要在應用(ETL)過程中進行計算5、確定事實及度量(包括預先計算的事實)49.建模的一般過程需要根據具體業務來確定事實及其量度5、確定事實建模的一般過程根據需求，對緩慢變化維進行相應的處理比如：對于一個需求為不保留歷史的客戶維度，我們使用第一種類型的緩慢變化維來處理；對于一個需求為需要保留歷史的產品維度，我們需要使用第二種類型的緩慢變化維來處理6、確定緩慢變化維50.建模的一般過程根據需求，對緩慢變化維進行相應的處理6、確定緩一個實例步驟1：選定某一業務過程，如：庫存管理業務安全政策瓦斯監測設備檢測設備報修工作面防護巷道管理水文檢測……地區管理銷售銷售管理客戶關系合同管理成本庫存運輸方式定貨發運……物資計劃物資采購成套設備管理設備維修設備租賃庫存管理……市場分析產品考察銷售預測人事計劃招聘人員福利政策新礦投產舊礦整改環境保護……財務計劃資本獲取資金管理借方貸方流動資金工資成本會計預算計劃利潤分析……煤種分類煤種定價規格說明生產能力計劃生產調度工序安排設備控制煤炭加工……51.一個實例步驟1：選定某一業務過程，如：庫存管理業務安全政策地對庫存管理業務建模步驟2：根據各用戶的需求（關注的主題），定義該業務處理的粒度。例如：－主題1及其粒度：礦廠中每種產品庫存水平的日快照－主題2及其粒度：每種特定產品的倉庫庫存事務每日情況－主題3及其粒度：每種特定產品每日的入庫裝運情況52.對庫存管理業務建模步驟2：根據各用戶的需求（關注的主題），定對庫存管理業務建模步驟3：選定每個事實表的維度例如：－主題1事實表維度：日期、礦廠、產品－主題2事實表維度：日期、倉庫、產品、供應商、事務類型－主題3事實表維度：到貨日期、檢測日期、入庫日期、銷售批準日期、分揀日期、裝箱日期、裝運日期、最近回收日期、產品、供應商、倉庫53.對庫存管理業務建模步驟3：選定每個事實表的維度53.對庫存管理業務建模步驟4：確定每個事實表的數字型事實例如：－主題1事實表數字型事實：現有數量－主題2事實表數字型事實：倉庫庫存事務金額－主題3事實表數字型事實：到貨量、檢測量、退貨量、入庫量、批準銷售量、分揀量、裝箱量、裝運量、回收量、顧客退貨量。。。。54.對庫存管理業務建模步驟4：確定每個事實表的數字型事實54.完成后的模型主題1：礦廠中每種產品庫存水平的日快照日期關鍵字產品關鍵字礦廠關鍵字現有數量礦廠庫存快照事實日期關鍵字日期屬性

。。。日期維度礦廠關鍵字礦廠屬性

。。。礦廠維度產品關鍵字產品屬性

。。。產品維度55.完成后的模型主題1：礦廠中每種產品庫存水平的日快照礦廠庫存快完成后的模型主題2：每種特定產品的倉庫庫存事務每日情況

產品接收產品送檢合格產品分發次品退貨產品入柜產品銷售審批產品出柜產品包裝發貨回收從庫存中刪除56.完成后的模型主題2：每種特定產品的倉庫庫存事務每日情況

產品完成后的模型日期關鍵字產品關鍵字倉庫關鍵字供應商關鍵字庫存事務類型關鍵字庫存事務金額倉庫關鍵字倉庫名稱倉庫地址倉庫所在城市倉庫所在省倉庫所在地區倉庫郵政編碼倉庫總面積

。。。倉庫維度庫存事務類型關鍵字庫存事務類型描述庫存事務類型組。。。庫存事務類型維度倉庫庫存事務事實產品維度供應商維度日期維度主題2：每種特定產品的倉庫庫存事務每日情況57.完成后的模型倉庫維度庫存事務類型維度倉庫庫存事務事實產品維度完成后的模型主題3：每種特定產品每日的入庫裝運情況到貨日期關鍵字檢測日期關鍵字入庫日期關鍵字。。。到貨量檢測量入庫量。。。倉庫庫存累積事實到貨日期維度檢測日期維度入庫日期維度。。。58.完成后的模型主題3：每種特定產品每日的入庫裝運情況到貨日期關數據質量管理為什么我的問題

還沒有解決？客戶投訴我不是我的錯！兩個系統的報表怎么不一致？目標完成沒有？未來趨勢怎樣？客戶客戶經理管理者領導實際發生的損失資金的流失客戶的流失生產效率的影響提升的障礙客戶服務質量提升市場的擴展利潤的增長不同的系統數據不一致不知道數據應該以誰為準數據的混亂狀況處于發散狀態。。。數據的重要性不亞于業務功能！！59.數據質量管理為什么我的問題

還沒有解決？客戶投訴我不是我的錯數據質量管理數據質量問題分析60.數據質量管理數據質量問題分析60.數據質量管理思路方法：質量問題的發現、評估、清洗與改進，是一個循環、長期持續的過程，而不是一次性工作。要讓數據質量管理成為一項日常工作，就像訂單受理系統每天受理訂單一樣。（執行）架構：像功能系統規劃一樣來規劃數據，確定數據的整體架構，確定數據的歸屬劃分，確定數據交互與共享規則，制定數據質量評價規則，建立完整的數據管理體系。（基礎、根本）組織：有專門的組織負責數據質量管理工作（管理）流程：建立閉環的數據質量管理機制：發現、分析、規則、執行、修正、考核（系統加管理手段）

數據質量在各個環節都可能不斷被放大、增加，處于發散的狀態，通過閉環管理確保數據質量處于收斂的狀態才能控制數據質量問題61.數據質量管理思路方法：質量問題的發現、評估、清洗與改進，是一Q&A交流與討論62.Q&A交流與討論62.

BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模目目錄63.如何構建BI數據倉庫設計中的幾個重要概念維度操作型數據

如：某商場1瓶價格為88元的葡萄酒在被購買的過程中，收銀員實際收到100元，找零12元。特點：細節化，分散化關鍵概念64.操作型數據關鍵概念2.關鍵概念決策型數據如：該商場在1月9日上午一共賣出了多少瓶葡萄酒?該商場的所有葡萄酒總銷量在一年中什么時候最高和最低?

特點：綜合化，集成化65.關鍵概念決策型數據3.企業對應用集成的需求我要了解企業目前的運轉情況！（實時監控）我要知道某地區近5年內的銷售情況以制定未來的發展策略！（決策支持）我要知道哪些是值得發展的優質的顧客！（預測）66.企業對應用集成的需求我要了解企業目前的運轉情況！（實時監控）BI應用帶來的關鍵效益洞察力獲得對業務績效，流程和客戶的可見性和洞察力更好的進行決策和執行決策，以快速應對機會和挑戰協同一致橫跨多個業務和數據源，獲得唯一的、一致的企業信息在各業務層面中協同戰略和執行67.BI應用帶來的關鍵效益洞察力5.BI應用帶來的關鍵效益中層管理分析:專注點是

績效的戰術應用與目標相比，我做的如何?問題在哪里高層領導分析:專注點是計劃戰略&目標制定業務發展得如何，我們下一步該往哪里走通過集成實時與歷史數據，將分析轉換為執行力一線分析:專注點是執行有效性與行動我每天要做哪3-5件事情哪些信息能讓我更有效地執行這些行動?回答問題:我現在該做哪些事情?68.BI應用帶來的關鍵效益中層管理分析:專注點是績效的戰術應數據倉庫的概念數據倉庫（DataWarehouse）是一個面向主題的、集成的、相對穩定的、反映歷史變化的數據集合，用于支撐管理決策。69.數據倉庫的概念數據倉庫（DataWarehouse）是一個

BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模目目錄70.如何構建BI數據倉庫設計中的幾個重要概念維度

BI應用架構

BI應用71.

BI應用架構

BI應用9.

BI系統架構

Microsoft

OfficeBIServerBIPresentationServer交互式信息板即席查詢報表分析預警提醒商務智能應用前端展示層商務智能服務層前端展示層應用服務層數據庫層ERP系統其他應用系統財務平臺ExcelXML業務流程數據源層商務智能應用模型架構：

財務、銷售、訂單、

服務、市場、供應鏈、

人力ETL商務智能應用數據

存儲星型模型DWCube72.

BI系統架構

Microsoft

OfficeBISe構建BI涉及的開發工具查詢工具

與

電子制表

ETL與元數據管理報表與文檔管理OLAP

多維分析Data

Mining

數據挖掘Portal

門戶網站

主流產品：ETL：Informatica、Datastage、Kettle、SSIS……前端展現：OracleBIEE、BusinessObject、MicroStregy、

Cognos、OracleEssbase、SmartBI……整體解決方案：OracleBIApps73.構建BI涉及的開發工具查詢工具

與

電子制表

ETL與元數數據倉庫設計中的幾個重要概念ETLETL是將業務系統的數據經過抽取（Extract）、清洗轉換（Transform）之后加載（Load）到數據倉庫的過程，目的是將企業中的分散、零亂、標準不統一的數據整合到一起，為企業的決策提供分析依據。ETL是BI項目重要的一個環節。通常情況下，在BI項目中ETL會花掉整個項目的1/3的時間,ETL設計的好壞直接關接到BI項目的成敗。

ETL的實現有多種方法，常用的有三種。一種是借助ETL工具實現，一種是SQL方式實現，另外一種是ETL工具和SQL相結合。前兩種方法各有各的優缺點，借助工具可以快速的建立起ETL工程，屏蔽了復雜的編碼任務，提高了速度，降低了難度，但是缺少靈活性。SQL的方法優點是靈活，提高ETL運行效率，但是編碼復雜，對技術要求比較高。第三種是綜合了前面二種的優點，會極大地提高ETL的開發速度和效率。74.數據倉庫設計中的幾個重要概念ETL12.數據倉庫設計中的幾個重要概念數據集市（Datamart）也叫做“小數據倉庫”。如果說數據倉庫是建立在企業級的數據模型之上的話，那么數據集市就是企業級數據倉庫的一個子集，他主要面向部門級業務，并且只面向某個特定的主題。數據集市可以在一定程度上緩解訪問數據倉庫的瓶頸。

即席查詢（Adhocqueries）是指那些用戶在使用系統時，根據自己當時的需求定義的查詢。即席查詢生成的方式很多，最常見的就是使用即席查詢工具。一般的BI展現工具都會提供即席查詢的功能。通常的方式是，將數據倉庫中的維度表和事實表映射到語義層，用戶可以通過語義層選擇表，建立表間的關聯，最終生成SQL語句。即席查詢與通常查詢從SQL語句上來說，并沒有本質的差別。它們之間的差別在于，通常的查詢在系統設計和實施時是已知的，所有我們可以在系統實施時通過建立索引、分區等技術來優化這些查詢，使這些查詢的效率很高。而即席查詢是用戶在使用時臨時生產的，系統無法預先優化這些查詢，所以即席查詢也是評估數據倉庫的一個重要指標。

75.數據倉庫設計中的幾個重要概念數據集市（Datamart）1數據倉庫設計中的幾個重要概念ODS（

OperationalDataStore,操作數據存儲）

ODS在通常的數據倉庫架構中都是一個可選的部件，它和數據倉庫起到互相補充的作用。最早給ODS下定義的是數據倉庫之父Inmon。他的定義是，操作數據存儲（ODS）是面向主題的、集成的、可變的、反映當前數據值的和詳細的數據的集合，用來滿足企業綜合的、集成的以及操作型的處理需求。

Inmon的這個定義與他對數據倉庫的定義很像。其中前兩個特性和數據倉庫是一樣的，即都是面向主題的和集成的，而后三個特性和數據倉庫相差較大。

ODS中的數據是可以變化的：這一點是Inmon相對與他的CIF（企業信息工廠）中的數據倉庫來說的，在CIF中，數據倉庫中的數據是不進行更新的，對于錯誤的處理通常是采用新的快照來進行保存。而ODS是可以按常規方法進行更新的。76.數據倉庫設計中的幾個重要概念ODS（Operational數據倉庫設計中的幾個重要概念ODS（

OperationalDataStore,操作數據存儲）ODS反映當前數據值：這一點是指ODS中不會長期的保留數據，通常ODS保留的數據的時限最長到一個月或三個月。而數據倉庫可以保留五年、十年或更長的數據。ODS中保留詳細數據：這一點是說ODS中只保留原子數據，而不保留匯總數據。而在數據倉庫中原子數據和匯總數據都會進行保留。這和ODS可更新的特性相關，因為隨時可能將操作型系統的數據變化更新到ODS中，并且數據的遷移時間間隔會很短，這都使匯總數據在ODS中的意義不大。77.數據倉庫設計中的幾個重要概念ODS（Operational數據倉庫設計中的幾個重要概念ExternalDataODSCentralDataWarehouseDataMartDataMartDataMartDataMartCentralDataWarehouseExternalDataODSpartpartpartpartpartpart1.建造企業數據倉庫建設中心數據模型一次性的完成數據的重構工作最小化數據冗余度和不一致性存儲詳細的歷史數據2.從企業數據倉庫中建造數據集市得到大部分的集成數據直接依賴于數據倉庫的可用性1.創建部門的數據集市范圍局限于一個主題區域快速的ROI--局部的商業需求得到滿足本部門自治--設計上具有靈活性對其他部門數據集市是一個好的指導容易復制到其他部門需要為每個部門做數據重建有一定級別的冗余和不一致性2.擴大到企業數據倉庫創建EDB作為一個長期的目標投資效益的時間?

建設中心數據模型的必要性和可能性?

初始費用?自上而下VS自下而上數據集市的數據都是可用的嗎?

能生成數據模型嗎?

如何解決不一致性?78.數據倉庫設計中的幾個重要概念ExternalODSCentr目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程79.目錄BI的價值17.基礎術語事實表是指其中保存了大量業務度量數據的表。事實表中的度量值一般稱為事實。在事實表中最有用的事實就是數字類型的事實和可加類型的事實。事實表的粒度決定了數據倉庫中數據的詳細程度。一般事實表中只存放數字或者一些Flag用來統計(Count)，如收益、數量、支出等銷售事實收益數量支出毛利…事實表（FactTable）80.基礎術語事實表是指其中保存了大量業務度量數據的表。事實表中的基礎術語維度表可以看作是用戶分析數據的窗口，維度表中包含事實數據表中事實記錄的特性，有些特性提供描述性信息，有些特性指定如何匯總事實數據表數據，以便為分析者提供有用的信息。客戶維時間維商場維產品維銷售事實時間ID客戶ID產品ID商場ID收益數量支出毛利…維度表（DimensionTable）81.基礎術語維度表可以看作是用戶分析數據的窗口，維度表中包含事實基礎術語粒度是指數據倉庫中數據的細化或綜合程度的級別，也就是數據的詳細程度。細節程度越高，粒度級就越低，反之亦然。我可以用很多的數據，但同樣我也可以只用必需的數據。而這起決于存儲器。如果有很大的硬盤，那就沒有我們不能存的事情。設計粒度是設計數據倉庫中的一個重要前提粒度（Grain）高細化低細化每月200個記錄每月40,000個字節每月一個記錄每月200個字節通過檢索可以回答無細節無法回答詢問某一電話的細節82.基礎術語粒度是指數據倉庫中數據的細化或綜合程度的級別，也就是基礎術語粒度是指數據倉庫中數據的細化或綜合程度的級別，也就是數據的詳細程度。細節程度越高，粒度級就越低，反之亦然。我可以用很多的數據，但同樣我也可以只用必需的數據。而這起決于存儲器。如果有很大的硬盤，那就沒有我們不能存的事情。設計粒度是設計數據倉庫中的一個重要前提粒度（Grain）高度綜合級輕度綜合級(數據集市)銷售細節級2000-2001操作型轉換每月銷售1994-2001每周銷售1994-2001當前細節級83.基礎術語粒度是指數據倉庫中數據的細化或綜合程度的級別，也就是目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程84.目錄BI的價值22.建模中的三種模型星形模型(StarSchema)雪花模型(SnowflakeSchema)多維模型(Multi-dimensionSchema)85.建模中的三種模型星形模型(StarSchema)23.建模中的三種模型事實表被維度所包圍，維表和事實表通過主關鍵字和外關鍵字聯系在一起，且維度沒有被新的表連接客戶維時間維商場維產品維銷售事實時間ID客戶ID產品ID商場ID收益數量支出毛利…星形模型（StarSchema）86.建模中的三種模型事實表被維度所包圍，維表和事實表通過主關鍵字建模中的三種模型事實表被多個維表或一個或多個層次所包圍，雪花模型一般在處理大的且相對靜態的層次的時候使用雪花模型（SnowflakeSchema）客戶維時間維商場維產品維銷售事實時間ID客戶ID產品ID商場ID收益數量支出毛利…聯系人維區域維87.建模中的三種模型事實表被多個維表或一個或多個層次所包圍，雪花目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程88.目錄BI的價值26.維度的類型緩慢變化維(SlowlyChangingDimension)快速變化維(RapidlyChangingDimension)大維(HugeDimension)和微型維(Mini-Dimension)退化維(DegenerateDimension)89.維度的類型緩慢變化維(SlowlyChangingDim維度的類型緩慢變化維（SlowlyChangingDimensions,簡稱SCD）

緩慢變化維的提出是因為在現實世界中，維度的屬性并不是靜態的，它會隨著時間的流失發生緩慢的變化（如：組織結構的調整、客戶更改了他的名稱或地址）。這種隨時間發生變化的維度我們一般稱之為緩慢變化維，并且把處理維度表的歷史變化信息的問題稱為處理緩慢變化維的問題，有時也簡稱為處理SCD的問題。處理緩慢變化維的方法通常有三種方式：第一種方式是直接覆蓋原值，通常簡稱為“TYPE1”。這樣處理，最容易實現，但是沒有保留歷史數據，無法分析歷史變化信息。第二種方式是添加維度行，通常簡稱為“TYPE2”。這樣處理，需要代理鍵的支持。實現方式是當有維度屬性發生變化時，生成一條新的維度記錄，主鍵是新分配的代理鍵，通過自然鍵可以和原維度記錄保持關聯。第三種方式是添加屬性列，通常簡稱為“TYPE3”。這種處理的實現方式是對于需要分析歷史信息的屬性添加一列，來記錄該屬性變化前的值，而本屬性字段使用TYPE1來直接覆蓋。這種方式的優點是可以同時分析當前及前一次變化的屬性值，缺點是只保留了最后一次變化信息。90.維度的類型緩慢變化維（SlowlyChangingDim維度的類型客戶Simmy將自己的地址由原先的Addr1改為Addr2。這時我們需要將這個記錄了客戶Simmy的記錄中Address從Addr1更新為Addr2，且不記錄歷史ID:111Name:SimmyAddress:Addr1ID:111Name:SimmyAddress:Addr2OLD記錄ID為111的客戶Simmy的信息的記錄中地址直接更改為Addr2，不保存歷史Addr1緩慢變化維Type1e.g.NEW91.維度的類型客戶Simmy將自己的地址由原先的Addr1改為A維度的類型客戶Simmy將自己的地址由原先的Addr1改為Addr2。這時我們需要將這個記錄了客戶Simmy的記錄中的有效截止日期改為現在，并重新添加一條有效截止日期為現在的和一個新的版本號且Address為Addr2的記錄ID:111Version:1Name:SimmyAddress:Addr1EffectiveStartDate:2007-4-21EffectiveEndDate:NowID:111Version:2Name:SimmyAddress:Addr2EffectiveStartDate:NowEffectiveEndDate:NullID:111Version:1Name:SimmyAddress:Addr1EffectiveStartDate:2007-4-21EffectiveEndDate:Null更新為添加新的記錄緩慢變化維Type2e.g.92.維度的類型客戶Simmy將自己的地址由原先的Addr1改為A維度的類型客戶Simmy將自己的地址由原先的Addr1改為Addr2。這時我們需要將這個記錄了客戶Simmy的記錄中的現在使用的Address變為Addr2，將Addr1放入原始的字段中ID:111Name:SimmyCurrentAddress:Addr1OldAddress:NullID:111Name:SimmyCurrentAddress:Addr2OldAddress:Addr1緩慢變化維Type3e.g.93.維度的類型客戶Simmy將自己的地址由原先的Addr1改為A維度的類型快速變化維(RapidlyChangingDimension,RCD)當某個維度的變化是非常快的時候，我們認定他為快速變化維(具體要看實際的變化頻率)，比如：客戶的地址、聯系電話等。數據倉庫中最有意思的維度是一些非常大的維度，比如客戶，產品等等。一個大的企業客戶維度往往有上百萬記錄，每條記錄又有上百個字段。而大的個人客戶維度則會超過千萬條記錄，這些個人客戶維度有時也會有十多個字段，但大多數時候比較少見的維度也只有不多的幾個屬性。大維(HugeDimension)94.維度的類型快速變化維(RapidlyChangingDi維度的類型微型維(MiniDimension)

以客戶維度舉例來說，如果維度表中有數百萬行記錄或者還要多，而且這些記錄中的字段又經常變化，這樣的維度表一般稱之為快變超大維度。對于快變超大維度，設計人員一般不會使用TYPE2的緩慢變化維處理方法，因為大家都不愿意向本來就有幾百萬行的維度表中添加更多的行。這時，有一項技術可以解決這個問題。解決的方法是，將分析頻率比較高或者變化頻率比較大的字段提取出來，建立一個單獨的維度表。這個單獨的維度表就是微型維度表。微型維度表有自己的關鍵字，這個關鍵字和原客戶維度表的關鍵字一起進入事實表。有時為了分析的方便，可以把微型維度的關鍵字的最新值作為外關鍵字進入客戶維度表。這時一定要注意，這個外關鍵字必須做TYPE1型處理。在微型維度表中如果有像收入這樣分布范圍較廣的屬性時，應該將它分段處理。比如，存儲￥31257.98這樣過于分散的數值就不如存儲￥30000－￥34999這樣的范圍。這樣可以極大的減少微型維度中的記錄數目，也給分析帶來方便。95.維度的類型微型維(MiniDimension)維度的類型退化維(DegenerateDimension)

退化維度一般都是事務的編號，如訂單編號、發票編號等。這類編號需要保存到事實表中，但是不需要對應的維度表，所以稱為退化維度。退化維度經常會和其他一些維度一起組合成事實表的主鍵。在Kimball提出的維度建模中，事實表應該保存最細粒度的數據。所以對于象銷售單這樣的事實表來說，需要銷售單編號和產品來共同作為主鍵，而不能用銷售日期、商場、產品等用來分析的維度共同作為主鍵。

96.維度的類型退化維(DegenerateDimension)目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程97.目錄BI的價值35.常用的事實表類型聚集事實表（AggregatedFactTable）合并事實表（ConsolidatedFactTable）旋轉事實表（PivotedFactTable）預連接聚集表（Pre-JoinedAggregagteTable）非事實型事實表（FactlessFactTable）切片事實表（SlicedFactTable）98.常用的事實表類型聚集事實表（AggregatedFact常用的事實表類型聚集事實表（AggregatedFactTable）是原子事實表上的匯總數據，也稱為匯總事實表。即新建立一個事實表，它的維度表是比原維度表要少，或者某些維度表是原維度表的子集，如用月份維度表代替日期維度表；事實數據是相應事實的匯總，即求和或求平均值等。在做數據遷移時，當相關的維度數據和事實數據發生變化時，聚集事實表需要做相應的刷新。物化視圖是實現聚集事實表的一種有效方式，可以設定刷新方式，具體功能由DBMS來實現。99.常用的事實表類型聚集事實表（AggregatedFact常用的事實表類型合并事實表（ConsolidatedFactTable）是指將位于不同事實表中處于相同粒度的事實進行組合建模而成的一種事實表。即新建立一個事實表，它的維度是兩個或多個事實表的相同維度的集合；事實是幾個事實表中感興趣的事實。在Kimball的總線架構中，由合并事實表為主組成的合并數據集市稱為二級數據集市。合并事實表的粒度可以是原子粒度也可以是聚集粒度。在做數據遷移時，當相關的原子事實表的數據有改變時，合并事實表的數據需要重新刷新。合并事實表和交叉探察是兩個互補的操作。聚集事實表和合并事實表的主要差別是合并事實表一般是從多個事實表合并而來。但是它們的差別不是絕對的，一個事實表既是聚集事實表又是合并事實表是很有可能的。因為一般合并事實表需要按相同的維度合并，所以很可能在做合并的同時需要進行聚集，即粒度變粗。比如“營銷事務事實表”和“庫存快照事實表”就會有相同的維度表，“日期維度”、“產品維度”和“商場維度”。這時，如果有個需求是想按共有維度來對比查看銷售和庫存的事實，這時就需要發出兩個SQL，分別查出按維度統計出的銷售數據和庫存數據。然后再基于共有的維度進行外連接，將數據合并。這種發出多路SQL再進行合并的操作就是交叉探查。100.常用的事實表類型合并事實表（ConsolidatedFac常用的事實表類型旋轉事實表（PivotedFactTable）是將一條記錄中的多個事實字段轉化為多條記錄，其中每條記錄保存一個事實字段的一種建模方法。或者反過來，也可以由多條記錄轉化為一條記錄。旋轉事實表建模方法的使用通常是為了簡化前端數據展現的查詢。它通過改變后端的事實記錄存儲方式，使相應的查詢需求的性能得到的極大的提高。如果在SQL或者查詢工具中進行這種轉換會非常麻煩，效率也很差。和合并事實表類似，有時當基礎表中沒有記錄時，旋轉事實表也要存儲一些零值在里面。101.常用的事實表類型旋轉事實表（PivotedFactTab常用的事實表類型預連接聚集表（Pre-JoinedAggregagteTable）是通過對事實表和維度表的聯合查詢而生成的一類匯總表。在預連接聚集表中，保存有維度表中的描述信息和事實表的事實值。通過預連接，可以避免在用戶查詢時RDBMS的連接操作，所以預連接聚集表的查詢效率要高很多。在這個銷售事實表，前五個字段都來自于維度表的描述字段，后兩個字段來自于事實表的事實字段。這樣在用戶提交查詢后，RDBMS就不需要連接維度表和事實表了，只需直接在該表中查詢即可。產品名稱商標名稱年份月份銷售人員名稱銷售量銷售金額銷售事實表102.常用的事實表類型預連接聚集表（Pre-JoinedAggr常用的事實表類型預連接聚集表（Pre-JoinedAggregagteTable）預連接聚集表有一個很大的缺點，它需要占用大量的存儲空間。預連接事實表的記錄和事實表一樣多，每條記錄的長度和維度表一樣長，所以對存儲空間的需求是非常大的。除非情況特殊，或者該表是高度匯總的，否則不建議建立預連接聚集表。在建立預連接聚集表時需要平衡效率和存儲空間的矛盾。預連接聚集表的生成方式較為簡單，直接使用SQL查詢即可生成。如果聚集導航器的功能很強大的話，也可以處理預連接聚集表。否則，需要用戶理解預連接聚集表，并在SQL中直接使用該表。預連接聚集表在數據倉庫領域有著很重要的作用，是匯總表的一種。它的優點和缺點都很明顯，在使用時需要綜合考慮。103.常用的事實表類型預連接聚集表（Pre-JoinedAggr常用的事實表類型非事實型事實表（FactlessFactTable）事實表通常會保存十個左右的維度外鍵和多個度量事實，度量事實是事實表的關鍵所在。在非事實型事實表中沒有這些度量事實，只有多個維度外鍵。非事實型事實表通常用來跟蹤一些事件或者說明某些活動的范圍。下面舉例來進行說明：第一類非事實型事實表是用來跟蹤事件的事實表。例如：學生注冊事件，學校需要對學生按學期進行跟蹤。維度表包括學期維度、課程維度、系維度、學生維度、注冊專業維度和取得學分維度，而事實表是由這些維度的主鍵組成，事實只有注冊數，并且恒為1。這樣的事實表可以回答大量關于大學開課注冊方面的問題，主要是回答各種情況下的注冊數。第二類非事實型事實表是用來說明某些活動范圍的事實表。例如：促銷范圍事實表。通常銷售事實表可以回答如促銷商品的銷售情況，但是對于那些沒有銷售出去的促銷商品沒法回答。這時，通過建立促銷范圍事實表，將商場需要促銷的商品單獨建立事實表保存。然后，通過這個促銷范圍事實表和銷售事實表即可得出哪些促銷商品沒有銷售出去。這樣的促銷范圍事實表只是用來說明促銷活動的范圍，其中沒有任何事實度量。104.常用的事實表類型非事實型事實表（FactlessFact常用的事實表類型切片事實表（SlicedFactTable）切片事實表中的字段結構和相應的基礎表完全相同，差別在于存儲的記錄的范圍。切片事實表中保存記錄的是相應基礎表中記錄的子集，記錄數通常與某個維度記錄數相同。這種建模方法一般用來滿足特殊需要，如需要分析某些特殊問題時，可以將與之相關的數據切片出來。相反，這種方法也常用于合并存儲在不同地區的數據，即各個地區都保存自己地區的數據，總部和所有地區的表結構都相同，然后總部將所有地區的數據合并在一起。切片事實表的結構與相對應的基礎表相同，數據來源于相對應的基礎表。切片事實表由于縮小了表中數據的記錄數，所以查詢的效率得到了很大的提高。105.常用的事實表類型切片事實表（SlicedFactTabl目錄BI的價值如何構建BI數據倉庫設計中的幾個重要概念維度建模基礎術語建模中的三種模型維度的類型常用的事實表類型建模的一般過程106.目錄BI的價值44.建模的一般過程確定詳細數據的粒度級別此過程必須是在建模之前最需要考慮的問題比較典型的粒度指的是單獨的，基于時