建立模型應該考慮的幾個問題
數 據倉庫建模質量直接影響數據倉庫項目的質量，甚至成敗。在進行建模之前，要對數據倉庫的規模、組成及模型不同部分的功能定位有明確的定義。影響數據倉庫建 模的因素眾多，且根據不同項目的具體情況而變化口下面的幾個問題是較為通用和常見的，遠遠不是建立模型應該考慮的全部問題。
數據倉庫的業務特點對建模的要求
1 數據倉庫的數據組織是面向主題的，而不是面向報表的
數據倉庫是面向業務分析的主要主題領域的，進行形成數據模型的定義。典型的主題領域主要包括:
· ·顧客購買行為
· ·產品銷售情況
· ·企業生產事務
· ·原料采購
· ·合作伙伴關系
· ·會計科目余額
要 對現有的報表需求進行細致的分類、分析和調整，不能為了實現單個報表而進行大量的建模工作。要根據分析的不同內容和主題對報表進行分類，明確報表中每一個 數據的定義、統計口徑及不同數據之間的關系，建立在整個數據倉庫內統一的數據指標的定義，將數據指標按分析主題及分析維度進行歸集，從而形成面向主題的數 據模型。
例如：我們的利潤表報表，當業務部門發我們一個利潤表 的報表，作為需求時，我們應該進行細致的分析，最終我們確定我們面向的主題不是利潤表，而是比利潤表更大的一個層次的所有科目業務量的主題，這樣我們在做 別的報表，例如資產負債表，現金流量表等報表時，就不用重復建模的工作了，做到了軟件工程中的可重用規則。
2. 數據倉庫要實現對數據的集成與數據的同構性
3. 數據倉庫數據的相對穩定與為實現應用而進行的實時讀寫操作
往數據倉庫里實時寫數據就是不可避免的， SAP BI 也提供支持這種處理的數據對象，如實時信息立方體、匯總級別等，並提供相應的管理機制保證數據的一致性。在建模的時候要好好考慮只讀的對象與可寫入的對象之間的關系。
4. 數據倉庫反映歷史變化與及時准確的數據處理能力
數據倉庫的數據庫設計原則的要求
1. 星形結構，實現簡明的數據設計模式
2. 數據參照完整性，保證數據的一致性
3. 利用索引，提高查詢的處理速度
4. 先去索引、后加索引，提高數據裝載效率
5. 自動校驗，保證數據的高質量
SAP 商務智能項目實戰過程和方法
收集客戶需求信息
1. 組織結構
2. 客戶最需要分析的數據指標
3. 數據指標的數據來源
4. 對數據指標的多維分析對象
5. 數據指標的優先級
6. 權限要求
收集客戶需求的方法
1. 面談
2. 問卷調查
3. 報表樣例分析法
分析客戶需求，形成多維分析模型（邏輯建模）
· 實體-關系模型
· KPI與分析維度
一 般情況下主題和屬性之間的關系是一對多的關系，通過諸多屬性的描述，可以得到客戶等對象的最詳細的信息。但是有些情況下，也有存在多對多的情況，如一個產 品有多個顏色等，這種情況下，我們設計時，要把他們作為獨立的兩個特征同時出現在維度表中，也是視實際的關系采用組合屬性，時間相關的屬性等方法。如例子 中的一個人在不同的時期屬於不同的地區，這就是多對多的關系，所以采用了時間相關的屬性。
將邏輯模型變成物理模型
利用業務內容（bi content）加快建模進程。
直接從系統中現有的模型來建模和擴展。
多層邏輯模型與BI中的建模技巧
對於大型的數據倉庫系統，簡單的數據獲取、存儲及展現的架構是遠遠不能滿足需求的。
大型數據倉庫項目的建設，需要對將數據倉庫中不同數據的功能與定位進行細分，根據其功能不同，分別采取各種建模方面和技術方面的性能優化措施。
企業數據倉庫與數據集市
在企業級的數據創建建設方法上，存在着兩種不同的建設思路。其實這兩種建設思路並不是絕對對立的，利用SAP商務智能的配置功能，可以構建更為靈活的多層次的數據倉庫結構。
1.兩種建設數據倉庫的不同思路
一 種是有Inmon提出的企業級數據倉庫模型。主張采用第三范式（3NF），先建立企業級數據倉庫，再在其上開發具體的應用。其優點是采用了第三范式，數據 存儲冗余度低、數據組織結構型好；同時反映的業務主體能力強，具有較好的業務擴展性等。這種建設思路不足的地方時數據表是數據表之間的聯系比較多，也比較 復雜，跨表操作多，查詢效率較低。由於數據模式復雜，不容易理解，不利於維護。系統建設過程長，周期長，難度大，風險大，容易失敗。
另 一種思路是有Kimball提出的多維模型。他主張降低范式化，以分析主體為基本框架來組織數據。其優點是以多維模型開發分析主題，查詢速度快，做報表也 快，同時可以實現快速實施，迅速獲得投資回報。再在各個分析主題的基礎上循序漸進，逐步建成企業級數據倉庫。這種主張融合了自下而上和自上而下兩種設計方 法的思想，但是需要對數據進行大量的預處理，建模過程相對來說就比較慢。由於數據是按業務主體組織的，當業務問題發生變化，維的比搬動復雜、耗時，而且信 息不夠全面、系統欠靈活、數據冗余多。
這兩種思路的區別是建設企業數據倉庫與數據集市先后次序的區別。這種區別說明了數據倉庫不同部分的構成是需要進行功能划分的，建立具有不同的分層的數據倉庫系統是大勢所趨。
2.具有多層結構的數據倉庫系統
從 技術上來說，SAP BI支持建立具有多個層次的數據倉庫系統。在軟件方面，它提供了技術性能各異的多種數據對象，可以構建不同的邏輯層次；在硬件方面，支持應用服務器與數據 庫服務器的動態擴展及根據性能需要進行不同的參數設置。SAP BI 支持建立多個邏輯數據層次，這有助於提高模型設計的靈活性、可以利用同一套數據實現和管理多個不同的需求。BI 的多層建模及在各個模型層次的一些建模技巧，如圖。
從數據的存儲邏輯上看，圖中包含5個邏輯層。
數據抽取准備區
這 是原始明細數據層，這是保存源系統明細數據的存儲層，可以使用BI的PSA構建這個層次；每一個PSA表對應着源系統中抽取數據的一個數據源，PSA的表 結構和數據源的結構一一對應，這一層次的數據通過SAP或非SAP的工具實現上傳，基本上是各個源系統的副本，沒有過多的修改和篩選，為數據的抽取和進一 步的轉換作准備。
（2）運營數據存儲
這一層次的存在主要是為了滿足從BI中出具運營層面的報表。運營報表查看的數據一般是比較明細的數據，對時效性的要求也比較高，所以這一層次的數據相對來說更新頻繁，數據比較不穩定。可以使用BI的DSO來構建這一數據層。
（3）企業數據倉庫層
這 是面向主題的儲存的明細數據層。這一層次的數據主要保存歷史的、穩定的、明細的、整合的數據，可以使用DSO來構建這個層次；數據從PSA層向這一層次根 據不同的業務主題進行歸集。每個DSO集成了來自不同的源系統的同一業務主題的相關數據。在這一層次上，對不同來源的數據進行整合，對源系統間的數據進行 校驗和統一，形成全系統內數據的一個統一的平台。
（4）數據集市層
這是一個面向應用的、具有多級匯總特性的多維分析層，他主要面向業務部門、數據時經過聚集和整合的，可以使用BI的信息立方體及多種虛擬對象來創建。這一層次的數據是根據應用的要求進行不同級別的匯總的。處於應用的需要，還需要在各種匯總級別上搭建跨主題的聯合查詢。
（5）信息的發布和訪問層
這一層包括分析、報表、合並、計划等應用，是提供給各個業務部門使用的，通常使用數據集市或DSO對象來實現。
總體而言，為了定義數據對象之間更明確的邏輯關系，數據的流向是從下至上，在多個層次間流動的。但在技術上並沒有限制，各個對象之間的數據流動是可以靈活定義的。SAP BI為多層數據倉庫模型的構建提供了相應技術以及構建這些數據層次的各種數據對象。
3.各個邏輯層共享主數據
正如前面提到的，信息對象是SAP BI中的基本單位，上述的所有數據層都是使用信息對象構建的。所以在整個系統建模中要通過信息對象共享性，保證不同數據存儲模型的數據水平方向一致性，減少數據冗余。
（1）使用業務內容
應該盡量采用SAP預定義的業務內容來構架數據模型。急於SAP BI的業務內容提供的數據模型進行整體設計。
SAP 預定義的業務內容涵蓋了所有的SAP產品中的所有主數據、數據模型、抽取程序、報表等定義，可以加快整個項目實施的進程。業務內容是基於SAP所有的產品 模塊進行整體設計的，所以在整個設計中保證了設計的繼承性和產品的延續性。業務內容不僅包括SAP的產品的，還囊括了一些非SAP得產品， 如：Oracle的財務系統、Siebel的CRM系統等。
（2）統一主數據設計
統一的主數據信息對象的設計，以保證所有R3系統和非R3系統數據的一致性。
在 SAP預定義的業務內容中，已經定義了豐富的信息對象，但是，在實際的實施中，還是會發現已有的SAP預定義的信息對象不一定能夠覆蓋整個企業的應用需 求。如果SAP預定義的信息對象的特征無法完整地描述用戶所需要的信息，建議對信息對象進行有效地擴充，以滿足用戶的分析需求。如果需要的信息對象不在 SAP預定義的業務內容范圍內，建議對非SAP得應用系統應該進行一個統一的，全局的規划和設計。
（3）保證設計的靈活性
主 數據整合是一個漸進的過程，在設計中應保證足夠的靈活性。並不是所有的主數據都需要整合，而且主數據的整合過程也是一個漸進的過程，所以，應該在設計初始 階段采用靈活的方法，以支持主數據整合漸進的過程。一種常見的方式就是先把主數據上傳到DSO，再將上傳到信息對象進行整合。
下面將就各個邏輯層次的建模特點及技巧做進一步的探討。
數據集市層的設計技巧與實例
數據集市層往往是基於一定的范圍或某個業務部門的應用需求，要求模型能支持多維的分析，能夠對歷史數據進行有效分析，同時要保證數據的一致性、有效地控制數據冗余。這些多是設計數據集市時要考慮的關鍵點。
使用虛擬信息提供者
可以利用BI中的各種虛擬的信息提供者來把不同的數據對象，如DSO或信息立方體的數據融合在一個虛擬的信息提供者中。在信息立方體中存放基於關鍵指標的聚集數據，在數據存儲對象中存放詳細的業務數據。通過追溯的功能，可以瀏覽不同階級的聚集或明細的數據，如圖所示。
這 樣設計可以保證匯總數據與詳細數據的一致性，提高了數據的訪問的效率，降低了數據的冗余，在新的項目或創建洗新的應用時，對已有的成果進行回顧和評價分 析，以便在以前的項目成果上進行設計和構架（如通過多信息提供者），以滿足新的需求，而避免出現為了一個報表而設計一個信息立方體的情況。這樣做在減少數 據的冗余，減少重復設計的冗余的同時，也降低了數據集市和報表的管理難度。
大數據量時盡量對信息立方體的使用物理分區
物理分區就是將數據庫表分成幾個小區存儲，在邏輯上還是一個數據庫表，對用戶來說是透明的。
適用數據庫
物理分區時給予數據庫特性使用的，適用於如下數據庫。
范圍分區：oracle Informix，IBM DB2
哈希分區：IBMDB2
啟用分區
BI充分考慮並使用了數據庫物理的特征，用於提高存儲性能。在BI中物理分區有一部分是有系統自動優化的，也有一部分需要有模型設計着進行手動配置。
自動分區。以范圍分區為例，系統在下列情況下自動對物理表進行分區：
信��立方基本事實表：系統自動按照請求，即對上傳的數據包進行分區。
PSA表：同上。
DSO的更新記錄：同上。
用戶自定義分區：用戶也可以自定義分區。比如對於信息立方體的聚集事實表，用戶可以指定分區方法。
點擊跳到：
在這個窗口中可以按照時間特征進行分區。
使用物理分區可以明顯地提高數據存儲與訪問的性能，有利於系統實現並行處理分區，每次查詢只讀取較小的數據集，在進行數據刪除時可以快速刪除分區。
大數據量時盡量通過多信息提供者，實現邏輯分區。
邏輯分區實現示例
通 過多信息提供者把大數據分割成小的數據分區，可以按照不同的年份，計划/實際，區域，業務區域等進行數據分區。如圖所示為一個常見的例子，可以按照不同的 地區將數據存儲在3個結構相同的信息立方體中。如果需要進行全局的查詢，再使用多信息提供者將3個分信息立方體聯合起來。
邏輯分區的優缺點
這樣設計的思路和物理分區有異曲同工之處，如果邏輯分區得當，可以實現以下優點：
查詢的執行分布在不同的信息提供者，減少了運行時間。
下層的單個信息提供者比一個大的信息提供者在設計上更簡單。
不需要付出額外的數據存儲空間。
可以對單個信息提供者實現同步進行數據上傳。
對於報表設計來說是透明的。
可以對單個信息者進行歸檔比較容易。
當然，這樣設計也是有代價的。比如，由於多信息提供者本身不存儲數據，所以無法對多信息提供者使用聚集。此外，雖然這一方案不會增加數據存儲空間，但是有額外的I/O開支。
適時地使用行項目維度和“基數高度”標志
行項目維度
我們知道，在一般情況下，信息立方體的維度表存放的是維度ID和多個特征的SID的對應關系，工作SID再連接到主數據。這種設計提高了模型的靈活性。但是在某個別情況下，這種設計不是最優。
如果維度表，和事實表之間有着多對多的關系，那么連接結構如圖：
SID表和事實表之間是多對多的關系，因為一個維度中包含很多特征。
如果出現這種情況，就意味着，維度表和數據表幾乎一樣大，這時候不能在使用星型連接技術連接這些大表了，因為出現了三個大表的多重連接。BI提供了“行項目的選項”，就是說，將維度表示為行項目維度，並且該維度表僅分配一個信息對象，即行項目信息對象。
激 活立方體時，系統不會對行項目維度創建新的維度表，而是將信息對象的SID直接 保存到信息立方體的事實表中，該字段直接指向信息對象的主數據標識符表。換句話說，系統忽略了使用維度表的路線。原來信息塊à維度à信息對象，變成了行項 目維度中的信息塊à信息對象的鏈接方式。信息立方體的事實表直接與主數據表的SID關聯，而沒有維度表，在該行項目維度中只有一個特性。
這樣的設計使得在報表運行中，無需大數量的join處理，在數據上傳時，也無需通過我維度表來確定維度ID。
“基數高度”選項
這是另一個維度可以設置的屬性，當一個維度包含很多條目，或者說具有很高的基數高度時，設置這一標識可以提高性能。一般而言，維度的記錄數至少是事實表的記錄的20%時，可以設置這一標識。
設置這一標識，系統會自動調整表的物理格式，選擇合適的索引類型（根據特定的數據庫不同），從而保證在讀取維度中的記錄時具有良好的性能。
系統實現示例
點擊屬性
專家建議：事實表和緯度表的大小的比例應該在10：1到20：1之間是比較合適的。
盡量使用聚集，以提高報表性能
聚集的工作原理
聚集是數據倉庫經常使用的一個方法。是對信息立方體的數據按照指定的一個子集進行數據匯總，匯總的數據存放在不同的獨立事實表中，根據常用的查詢種類，一個基本事實表可以設置多個聚集事實表。
在報表運行中，系統自動根據報表的查詢維度找到最合適，也就是數據量最少的聚集事實表中讀取數據。由於數據量的減少，降低了報表的運行時間。也就是說，聚集的設置對最終用戶是透明的，用戶沒有必要關系是否找到了合適的聚集，系統會自動找出相應聚集表。
聚集的系統實現
聚集是在基本的事實表上設置的。可以按照特征建立，可以按照導航屬性建立，也可以按照層次建立。
具體操作現場錄屏。。
正確划分特征與關鍵值，提高模型效率
在大部分情況下，主數據和交易數據，或者說維度和關鍵值是顯而易見的，但是主數據也會變化，主數據和划分並不是絕對的，這不僅體現在信息立方體建模上，也體現在特征的建模上。
一個最常見的例子就是商品價格的建模問題，價格是商品的一個屬性呢還是一個關鍵值呢？
將價格作為特征中的屬性：
如果商品價格較少變動，而且主要是為了出具報表使用，可以把價格設置成一個導航屬性。由於價格只是偶爾變動，一個時間相關的導航屬性應該是可以接受的。如果價格用於分析，可以考慮使用一個特征維度或者分類維度（層級）。
如果在報表中葯使用商品的價格進行簡單計算，可以再查詢設計器中使用一個公式變量。
將價格作為關鍵值：
如果價格經常變動或者需要運用這個來進行大量計算，還是建議設置成關鍵值。
利用關鍵值的屬性和設置，采用正確的方法以滿足數據計算的不同需求
使用參照值的多種匯總方式
如要計算日均收入等計算，不用專門的計算，使用關鍵值的屬性設置就可以了。
由於數據集市層直接面對着復雜多變的業務變化和需求，因而它的設計也最為復雜多變，既要考慮到存儲和報表的功能，也要充分滿足業務的需要。
企業數據倉庫層的設計技巧
企業數據倉庫層是面向主題的存儲的明細數據層。這一層的數據主要保存歷史的，穩定的，明細的，整合的數據。作為數據倉庫層，對於不同來源的數據進行整合，對於源系統間的數據進行校驗和統一，形成全系統內數據的一個統一平台。這一層有着明顯不同於數據集市層記得建模目標。
企業數據倉庫層的建模目標
實現“真相的唯一性”，所有的數據必須經過數據倉庫層，才能進步數據集市層，進入具體的各種應用，這樣可以保證所有應用的數據都是一致的。
保 證數據的完整性，基於數據倉庫層的數據是明細數據，重要的數據往往具有很強的分析意義，在從業務系統向BI系統進行數據更新時，不應該對重要信息進行覆 蓋，從而應該增加新的數據版本，從而保存不同的時間點的數據。這樣一旦出現新的應用，可以保證數據倉庫層可以滿足其數據要求，而不再從原系統進行數據抽 取。
實現有效地控制數據的抽取和准備。比如：實現一次抽取多處使用，避免數據冗余。
可重用性和靈活性。
實現數據集成性。
企業數據倉庫等的主數據建模
重要主數據
對 於重要的主數據，盡可能的保存歷史數據以便數據的靈活分析。來自不同業務系統的重要主數據，應該先通過DSO再進入相應的主數據信息對象。例如：有個 特征在業務系統中曾於2007年4月30日將屬性從x修改成y，為了保存完整修改的記錄，在數據倉庫中可以通過DSO對象保存不同時期的數據版本，再通過 DSO對象更新BI中的信息對象。
非重要數據
對於非重要數據可以直接從原系統上傳到主數據信息對象中，不保存中間的修改版本。
企業數據倉庫的業務數據建模
數據存儲對象的划分
首先是DSO的划分問題，划分幾個DSO？如何划分？
一般情況下，可以按不同的業務主體划分DSO。
數據粒度的選擇
選擇合適的數據對象類型
在企業數據倉庫層，使用較多的是數據存儲對象DSO。
1.4運營數據存儲層的設計技巧
運營數據存儲層是比較特別的一個數據層，它的存在主要是為了滿足從BI系統中出具運營報表。
運營數據存儲層的建模目標
運營數據報表不同於一般的分析報表，具有自己的特點：
需要明細的數據展現；
數據時更新覆蓋的；
面向操作人員的；
頻繁地數據上載；
從 上述特點中我們不難發現，運營數據存儲層與BI的企業級數據倉庫上存在較大的差異。同樣是明細的數據，但是數據倉庫層的數據主要保存歷史的，穩定的數據， 而運營數據報表需要的數據時近實時的，要頻繁的更新的。一般而言，運營數據層的數據時經過加工的數據，並且是基於具體的項目需求而設計的。
信息立方體的優化：
SAP BW的各信息提供者中可以說最重要的就是信息立方體，因為它是分析報表最主要的基礎。而對於信息立方體模型，最重要的莫過於維度的設計，它不只決定着查詢 的性能，而且會影響到數據上傳的時間。一個好的設計方案，不只能提高查詢的訪問速度，而且可以大大降低把數據更新到信息立方體的時間。
在信息立方體的設計中，如果能夠遵循下面的這些基本的原則，那么你就可以構建一個相對高效的信息立方體模型：
1 不要把查詢用不到的CHARACTERISTIC放到信息立方體中。
如 果一個CHARACTERRISTIC不會被查詢用到，而且你也不能確定它一定會在以后的查詢中用到，那么就不要把它放到信息立方體中。因為信息立方體中 每多包含一個特征，它的查詢性能和數據上傳性能就會降低一分。對於一個多層的數據倉庫架構來說，我們常常把這種特征放到中間層的DSO中。這樣一方面不會 影響到信息立方體的性能，另一方面，當后續開發的查詢用到這個特征的時候，我們可以重新把它加入到信息立方體中，然后從DSO上傳數據到信息立方體。由於 它的信息已經存在於DSO中了，我們不需要重新從源系統抽取數據，避免影響到業務系統。
2 對於NAVIGATIONAL屬性和特征，前者有利於數據上傳性能，而后者有利於報表性能。
這 個很好理解。但是它們還代表了不同的歷史事實性。對於特征來說，它代表的是業務發生時候的歷史事實。而NAVIGATIONAL屬性代表的是當前事實或者 某個指定時間的歷史事實。比如如果你把物料甲的物料組建模為一個特征，那么基於它的報表顯示的是業務發生時候的物料組。不管物料甲的物料組在這筆業務后有 沒有被修改過，報表數據都是基於這筆業務產生時候的物料組顯示的。如果你把物料組建模為屬性，那么非時效屬性對應的是當前的物料組分派，也就是說不管物料 甲在一筆業務發生時候的物料組分配是什么，報表數據都是基於當前分配的物料組的。而時效屬性則對應於某個指定時間的物料組分配。
3> 盡量減小維度表。
對於普通的維度，它的索引類型是BIT-MAP索引，降低維度表的大小可以大大提高BIT-MAP索引的性能，進而大大提高報表性能。另外合理的維度設計可以大大減少數據上傳過程中維度ID的生成次數，提高數據上傳性能。
04> 減少維度數，但是減小維度表更重要。特別是當兩者沖突的時候。
5> 對於高CARDINALITY的特征來說，比如銷售訂單號，我們應該使用LINE ITEM維度。
[0 普通的維度是一個擴展了的星形結構，中間是事實表，事實表首先關聯到維度表，然后經過維度表關聯到主數據表。而對於LINE ITEM維度來說，它沒有中間層的維度表，事實表直接和主數據表關聯。這樣執行SQL的時候，可以減少一個JOIN。
6> 對於高CARDINALITY的維度來說，我們應該使用B-TREE索引.
普通維度的默認索引時BIT-MAP，如果一個維度表太大，那么BIT-MAP索引的性能會大大降低。 這時候我們應該選擇使用B-TREE索引，也就是將一個普通維度改為HIGH-CARDINALITY 維度。
07> 如果一個信息立方體的特征數小於等於13， 那么你可以去掉推薦架構中的維度表這一層。將所有的特征建模為一個LINE ITEM維度。