中文国产黄色大片_ 報表工具->數據倉庫->商業(yè)智能

報表工具->數據倉庫->商業(yè)智能

很多國有大企業(yè)的ERP實(shí)施是伴隨著(zhù)一大堆分析報表的,如果ERP實(shí)施不考慮眾多的報表指標和報表間復雜的鉤稽關(guān)系, 而僅僅是滿(mǎn)足財務(wù)的核算, 就非?？赡苊媾R失敗, 早期的國外ERP中一般會(huì )在各模塊提供眾多的系統分析報表系統,比如信息系統或專(zhuān)業(yè)的報表分析工具, 但是這些在線(xiàn)分析報表如果和業(yè)務(wù)分析處理系統處在同一服務(wù)器,則嚴重浪費資源,于是產(chǎn)生了所謂的DW數據倉庫, 現在DW換了個(gè)新叫法BI(商業(yè)智能). 在一個(gè)大型集團,如果基礎數據不全、管理不規范,核算不標準的情況下就實(shí)施BI,成功率將非常小.

.什么是數據倉庫(Data Warehouse)?

你可能得到很多關(guān)于數據倉庫的定義,但我還是愿意引申”數據倉庫之父”的William H. Inmon 在1991年出版的“Building the Data Warehouse”一書(shū)中所提出的定義.

*http://www.inmoncif.com/home/ 是Inmon的個(gè)人主頁(yè),一看就知道是個(gè)喜歡折騰技術(shù)的人….

數據倉庫是一個(gè)面向主題的、集成的、相對穩定的、反映歷史變化的、用于支持管理決策的數據集合。

根據數據倉庫的定義,它被描述成一個(gè)用來(lái)支持符合企業(yè)發(fā)展的管理決策的綜合的解決方案.

為什么使用數據倉庫(DW)?有這么些原因

(1).企業(yè)規模龐大.

(2).業(yè)務(wù)數據龐大.

(3).各分子公司系統異構.

(4).各種類(lèi)型業(yè)務(wù)數據來(lái)源,數據需要匯總整合.

(5).ERP數據庫性能原因,生產(chǎn)系統性能的降低.

(6) ERP.數據庫通常不是為分析的目的設計的

ERP系統一般認為是OLTP系統,它不是專(zhuān)門(mén)為交叉主題分析報告而設計的.

交叉主題分析數據通常來(lái)自不同的模塊,報表公式邏輯將負責且分散.

(7).性能為體,復雜的管理層決策報表可能需要從多個(gè)模塊獲得數據,這樣的報表開(kāi)發(fā)通常因為業(yè)務(wù)數據量過(guò)多而導致運行速度極慢,如果ABAPer在程序性能優(yōu)化方面沒(méi)有經(jīng)驗,甚至報表根本就無(wú)法得出,而且會(huì )嚴重消耗R/3資源.

(8).用戶(hù)頻繁變動(dòng)需求原因,為了某種分析目的,用戶(hù)要求報表經(jīng)常增加幾個(gè)新字段那是很正常的,不同用戶(hù)甚至對于同一個(gè)報表的取數邏輯的理解不同是正常的,不同領(lǐng)導對相似報表要求的報表行項目可能是不同的,不同企業(yè)對同一業(yè)務(wù)在R/3的處理方式是不一致.

一個(gè)在線(xiàn)分析系統OLAP系統(你可認為DW系統也就是一個(gè)OLAP系統)應該有這么些系統:

(1).市場(chǎng)和銷(xiāo)售分析（Marketing and Sales analysis）

(2).基于歷史數據的營(yíng)銷(xiāo)（Database marketing）

(3).各種財務(wù)報告與合并報表（Financial reporting and consolidation）

(4).各類(lèi)成本費用分析類(lèi)的管理報告（Management reporting）

(5).利益率分析（Profitability analysis）

(6).質(zhì)量分析（Quality analysis）

(7).存貨分析(Inventory analysis)

......

一個(gè)大型ERP廠(chǎng)商應該能同時(shí)提供完善的在線(xiàn)分析系統又不影響在線(xiàn)交易系統性能.

集團企業(yè)都會(huì )尋找整合的高度集成的管理軟件，而不是簡(jiǎn)單的反應式的零散的管理產(chǎn)品.

說(shuō)到OLAP，就談下OLTP，數據處理大致可以分成兩大類(lèi)：在線(xiàn)事務(wù)處理OLTP（on-line tranSAction processing,R/3可看成一個(gè)OLTP系統）、在線(xiàn)分析處理OLAP（On-Line Analytical Processing）。OLTP是傳統的關(guān)系型數據庫的主要應用，主要是基本的、日常的事務(wù)處理。OLAP是數據倉庫系統的主要應用，支持復雜的分析操作，側重決策支持，并且提供直觀(guān)易懂的查詢(xún)結果。

摘自某網(wǎng)絡(luò )的一段描述，下表列出了OLTP與OLAP之間的比較。

OLTP

OLAP

用戶(hù)

操作人員,低層管理人員

決策人員,高級管理人員

功能

日常操作處理

分析決策

DB 設計

面向應用

面向主題

數據

當前的, 最新的細節的, 二維的分立的

歷史的, 聚集的, 多維的集成的, 統一的

存取

讀/寫(xiě)數十條記錄

讀上百萬(wàn)條記錄

工作單位

簡(jiǎn)單的事務(wù)

復雜的查詢(xún)

用戶(hù)數

上千個(gè)

上百個(gè)

DB 大小

100MB-GB

100GB-TB

OLAP產(chǎn)品和OLAP準則

最早的OLAP產(chǎn)品可以追溯到1970，但真正形成一個(gè)大的OLAP市場(chǎng)則是在90年代以后.聯(lián)機分析處理 (OLAP) 的概念最早是由關(guān)系數據庫之父E.F.Codd于1993年提出的，他同時(shí)提出了關(guān)于OLAP的12條準則，OLAP作為一類(lèi)產(chǎn)品同聯(lián)機事務(wù)處理 (OLTP) 明顯區分開(kāi)來(lái)。

Codd提出OLAP的12條準則來(lái)描述OLAP系統：

準則1 OLAP模型必須提供多維概念視圖

準則2 透明性準則

準則3 存取能力推測

準則4 穩定的報表能力

準則5 客戶(hù)/服務(wù)器體系結構

準則6 維的等同性準則

準則7 動(dòng)態(tài)的稀疏矩陣處理準則

準則8 多用戶(hù)支持能力準則

準則9 非受限的跨維操作

準則10 直觀(guān)的數據操縱

準則11 靈活的報表生成(目前BEx對中國式的格式報表顯然不靈活)

準則12 不受限的維與聚集層次(受數據庫限制一般DW提供13個(gè)自定義緯度).

DW&OLAP的關(guān)系

數據倉庫與OLAP的關(guān)系是互補的，現代OLAP系統一般以數據倉庫作為基礎，即從數據倉庫中抽取詳細數據的一個(gè)子集并經(jīng)過(guò)必要的聚集存儲到OLAP存儲器中供前端分析工具讀取

讓我們回過(guò)頭來(lái)結合某BW來(lái)理解數據倉庫的這幾個(gè)重要特征:

(1).面向主題(Subject_orient)

主題是一個(gè)針對一決策問(wèn)題而設置的分析對象,比如一個(gè)銷(xiāo)售利潤分析,如果你在SAP中寫(xiě)過(guò)類(lèi)似報表,你可能需要使用客戶(hù),物料,銷(xiāo)售訂單和客戶(hù)發(fā)票等表,

加一些數據冗余。

(2).集成的數據(Integrated)

數據倉庫中存貯的數據是從原來(lái)分散的各個(gè)子系統中提取出來(lái)的，但并不是原有數據的簡(jiǎn)單拷貝，而是經(jīng)過(guò)統一、綜合。其一，數據倉庫的數據不能直接從原有數據庫系統中得到。原有數據庫系統記錄的是每一項業(yè)務(wù)處理的流水帳，這些數據不適合于分析處理，在進(jìn)入數據倉庫之前必須經(jīng)過(guò)綜合、計算，拋棄分析處理不需要的數據項，增加一些可能涉及的外部數據,在BW中這些可以通過(guò)各種手段比如更新規則,傳輸規則實(shí)現.

其二，數據倉庫每一個(gè)主題所對應的源數據在原分散數據庫中有許多重復或不一致的地方，必須將這些數據轉換成全局統一的定義，消除不一致和錯誤的地方，以保證數據的質(zhì)量。

對源數據的集成是數據倉庫建設中最關(guān)鍵，也是最復雜的一步。

(3).數據更新性

數據倉庫的數據一般不可更新，最終用戶(hù)只能通過(guò)分析工具進(jìn)行查詢(xún)、分析，一般不允許直接修改其中存貯的數據,管理員可定期刪除歸檔一些歷史數據

(4)數據隨時(shí)間不斷變化(Time_variant)

數據倉庫中的數據隨時(shí)間變化而定期地被更新，每隔一段固定的時(shí)間間隔后，運作數據庫系統中產(chǎn)生的數據被抽取、轉換以后集成到數據倉庫中，可以采用完全和增量更新,可以根據需要自定義更新周期.

.一些常見(jiàn)BI術(shù)語(yǔ)(來(lái)自網(wǎng)絡(luò ))

商業(yè)智能（Business Intelligence），指數據倉庫相關(guān)技術(shù)與應用的通稱(chēng)。指利用各種智能技術(shù)，來(lái)提升企業(yè)的商業(yè)競爭力。

Data mart

數據集市，或者叫做"小數據倉庫"。如果說(shuō)數據倉庫是建立在企業(yè)級的數據模型之上的話(huà)。那么數據集市就是企業(yè)級數據倉庫的一個(gè)子集，他主要面向部門(mén)級業(yè)務(wù)，并且只是面向某個(gè)特定的主題。數據集市可以在一定程度上緩解訪(fǎng)問(wèn)數據倉庫的瓶頸。

數據集市:是用來(lái)分析特定業(yè)務(wù)主題或功能目標的公司數據的專(zhuān)門(mén)項目的數據收集。這些數據是粒度化的,歷史的,整體的,全體的.

數據集市面向部門(mén)級業(yè)務(wù)，并且只是面向某個(gè)特定的主題。數據集市可以在一定程度上緩解訪(fǎng)問(wèn)數據倉庫的瓶頸。

自下而上，"Think Big,Start Small".

另一種解決數據庫方案早期問(wèn)題的方法是數據集市的發(fā)展

(1)獨立的數據集市

一個(gè)獨立的數據集市是建立使用一個(gè)中央的、企業(yè)級數據庫作為數據來(lái)源的數據集市。

所特別建立的單獨的數據集市是供單個(gè)的部門(mén)使用或者是為了滿(mǎn)足面向專(zhuān)門(mén)項目的分析方案的需要，

但是大多數機構在其商務(wù)智能環(huán)境中愿意擁有多個(gè)數據集市。然而，不管在機構內有多少數據集市存在，

所有的數據集市的數據都來(lái)自EDW。

(2)非獨立的數據集市

(3)作為數據庫的數據集市

“數據集市是倉庫”,在數據庫團體中一種學(xué)院派的想法是數據倉庫是由公司中的數據集市構成的。

用這種方式，公司建立數據集市，終端用戶(hù)能夠獲取任何或者全部所需獲得的數據來(lái)完成分析。

該理論認為，數據集市建立起來(lái)更簡(jiǎn)便快捷，一旦建立，就從數據集市中獲取數據，而不用建立

和維護一個(gè)中央數據倉庫。就像在數據倉庫等技術(shù)領(lǐng)域大多數理論那樣，這個(gè)概念有一些優(yōu)點(diǎn)，

但是緊隨其后的是顯而易見(jiàn)的問(wèn)題。

一個(gè)最重要的考慮是仍然打算確保在所有這些數據集市中獲取的數據能被正確使用和整合。

在當今世界最艱巨的任務(wù)是方案的何去何從，以及執行官、經(jīng)理、員工在商務(wù)和技術(shù)兩方面何去何從等。

企業(yè)級數據倉庫(EDW，Enterprise Data

Warehouse)，對于數據集市的定位也基本形成共識，那就是數據集市應該從屬于企業(yè)級數據倉庫。

所謂EDW，基本的要求是整個(gè)企業(yè)能夠共享統一的數據存儲模型，為各級業(yè)務(wù)人員提供一致的信息視圖。

實(shí)施時(shí)可以先按照需求的輕重緩急選擇部分業(yè)務(wù)主題，然后逐步擴展到涵蓋全部業(yè)務(wù)。

BI要想大做小，從最迫切的業(yè)務(wù)入手。無(wú)論是上哪種管理軟件，幾乎都會(huì )聽(tīng)到同樣的聲音：不要貪大求全，從最迫切的業(yè)務(wù)入手，BI也不例外，它可以做成一個(gè)獨立的龐大系統，把企業(yè)中所有的業(yè)務(wù)數據全部放在一個(gè)數據倉庫里，進(jìn)行多維分析；也可以將其嵌入到各項單獨的業(yè)務(wù)數據中，進(jìn)行單獨的業(yè)務(wù)分析。咨詢(xún)顧問(wèn)的意見(jiàn)是先把最緊要的業(yè)務(wù)管理起來(lái)，以便迅速響應市場(chǎng)需求，做出最佳決策。積累了一定經(jīng)驗后，再逐漸增加BI系統繼續對其他業(yè)務(wù)進(jìn)行決策分析，這樣可以在一定程度上規避風(fēng)險，因為上BI也要進(jìn)行流程的重整，

缺少數據分析師,這些數據將從何而來(lái).Think Big , Start small.

但是我們根本都沒(méi)有think . ROLAP

基于Codd的12條準則，各個(gè)軟件開(kāi)發(fā)廠(chǎng)家見(jiàn)仁見(jiàn)智，其中一個(gè)流派，認為可以沿用關(guān)系型數據庫來(lái)存儲多維數據，于是，基于稀疏矩陣表示方法的星型結構（star schema）就出現了。后來(lái)又演化出雪花結構。為了與多維數據庫相區別，則把基于關(guān)系型數據庫的OLAP稱(chēng)為Relational OLAP，簡(jiǎn)稱(chēng)ROLAP。代表產(chǎn)品有Informix Metacube、Microsoft SQL Server OLAP Services。

MOLAP

Arbor Software嚴格遵照Codd的定義，自行建立了多維數據庫，來(lái)存放聯(lián)機分析系統數據，開(kāi)創(chuàng )了多維數據存儲的先河，后來(lái)的很多家公司紛紛采用多維數據存儲。被人們稱(chēng)為Muiltdimension OLAP，簡(jiǎn)稱(chēng)MOLAP，代表產(chǎn)品有Hyperion(原Arbor Software) Essbase、Showcase Strategy等。

1.ROLAP

ROLAP將分析用的多維數據存儲在關(guān)系數據庫中并根據應用的需要有選擇的定義一批實(shí)視圖作為表也存儲在關(guān)系數據庫中。不必要將每一個(gè)SQL查詢(xún)都作為實(shí)視圖保存，只定義那些應用頻率比較高、計算工作量比較大的查詢(xún)作為實(shí)視圖。對每個(gè)針對OLAP服務(wù)器的查詢(xún)，優(yōu)先利用已經(jīng)計算好的實(shí)視圖來(lái)生成查詢(xún)結果以提高查詢(xún)效率。同時(shí)用作ROLAP存儲器的RDBMS也針對OLAP作相應的優(yōu)化，比如并行存儲、并行查詢(xún)、并行數據管理、基于成本的查詢(xún)優(yōu)化、位圖索引、SQL的OLAP擴展(cube,rollup)等等。

2.MOLAP

MOLAP將OLAP分析所用到的多維數據物理上存儲為多維數組的形式，形成“立方體”的結構。維的屬性值被映射成多維數組的下標值或下標的范圍，而總結數據作為多維數組的值存儲在數組的單元中。由于MOLAP采用了新的存儲結構，從物理層實(shí)現起，因此又稱(chēng)為物理OLAP（PhysicalOLAP）；而ROLAP主要通過(guò)一些軟件工具或中間軟件實(shí)現，物理層仍采用關(guān)系數據庫的存儲結構，因此稱(chēng)為虛擬OLAP（VirtualOLAP）。

3.HOLAP

由于MOLAP和ROLAP有著(zhù)各自的優(yōu)點(diǎn)和缺點(diǎn)（如下表所示）,且它們的結構迥然不同，這給分析人員設計OLAP結構提出了難題。為此一個(gè)新的OLAP結構——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP兩種結構的優(yōu)點(diǎn)結合起來(lái)。迄今為止，對HOLAP還沒(méi)有一個(gè)正式的定義。但很明顯，HOLAP結構不應該是MOLAP與ROLAP結構的簡(jiǎn)單組合，而是這兩種結構技術(shù)優(yōu)點(diǎn)的有機結合，能滿(mǎn)足用戶(hù)各種復雜的分析請求。

Client OLAP

相對于Server OLAP而言。部分分析工具廠(chǎng)家建議把部分數據下載到本地，為用戶(hù)提供本地的多維分析。代表產(chǎn)品有Brio Designer，Business Object。

DSS

決策支持系統（Decision Support System），相當于基于數據倉庫的應用。決策支持就是在收集所有有關(guān)數據和信息，經(jīng)過(guò)加工整理，來(lái)為企業(yè)決策管理層提供信息，為決策者的決策提供依據。

ETL

數據抽?。‥xtract）、轉換（Transform）、清洗（Cleansing）、裝載（Load）的過(guò)程。構建數據倉庫的重要一環(huán)，用戶(hù)從數據源抽取出所需的數據，經(jīng)過(guò)數據清洗，最終按照預先定義好的數據倉庫模型，將數據加載到數據倉庫中去。

Ad hoc query

即席查詢(xún)，數據庫應用最普遍的一種查詢(xún)，利用數據倉庫技術(shù)，可以讓用戶(hù)隨時(shí)可以面對數據庫，獲取所希望的數據。

EIS

主管信息系統（Executive Information System），指為了滿(mǎn)足無(wú)法專(zhuān)注于計算機技術(shù)的領(lǐng)導人員的信息查詢(xún)需求，而特意制定的以簡(jiǎn)單的圖形界面訪(fǎng)問(wèn)數據倉庫的一種應用。

BPR

業(yè)務(wù)流程重整（Business Process Reengineering），指利用數據倉庫技術(shù)，發(fā)現并糾正企業(yè)業(yè)務(wù)流程中的弊端的一項工作，數據倉庫的重要作用之一。

Data Mining

數據挖掘，Data Mining是一種決策支持過(guò)程，它主要基于A(yíng)I、機器學(xué)習、統計學(xué)等技術(shù)，高度自動(dòng)化地分析企業(yè)原有的數據，做出歸納性的推理，從中挖掘出潛在的模式，預測客戶(hù)的行為，幫助企業(yè)的決策者調整市場(chǎng)策略，減少風(fēng)險，做出正確的決策

CRM

客戶(hù)關(guān)系管理（Customer Relationship Management），數據倉庫是以數據庫技術(shù)為基礎但又與傳統的數據庫應用有著(zhù)本質(zhì)區別的新技術(shù)，CRM就是基于數據倉庫技術(shù)的一種新應用。但是，從商業(yè)運作的角度來(lái)講，CRM其實(shí)應該算是一個(gè)古老的"應用"了。比如，酒店對客人信息的管理，如果某個(gè)客人是某酒店的老主顧，那么該酒店很自然地會(huì )知道這位客人的某些習慣和喜好，如是否喜歡靠路邊，是否吸煙，是否喜歡大床，喜歡什么樣的早餐，等等。當客人再次光臨時(shí)，不用客人自己提出來(lái)，酒店就會(huì )提供客人所喜歡的房間和服務(wù)。這就是一種CRM。

Meta Data

元數據，關(guān)于數據倉庫的數據，指在數據倉庫建設過(guò)程中所產(chǎn)生的有關(guān)數據源定義，目標定義，轉換規則等相關(guān)的關(guān)鍵數據。同時(shí)元數據還包含關(guān)于數據含義的商業(yè)信息，所有這些信息都應當妥善保存，并很好地管理。為數據倉庫的發(fā)展和使用提供方便。

Data Mart, 數據集市

也被稱(chēng)為“小數據倉庫”，DW的一個(gè)子集，主要面向部門(mén)級業(yè)務(wù)。例如在銷(xiāo)售部門(mén)的應用時(shí)，可能不需要分析某個(gè)產(chǎn)品的原材料。分析地區稅收時(shí)，不需要分析能源消耗情況。

OLAP, Online Analytical Processing, 聯(lián)機分析處理

也稱(chēng)為多維分析?；谝粋€(gè)主題“立方體”，該“立方體”若干個(gè)維，例如時(shí)間維，區域維，產(chǎn)品維等。這些維又可以進(jìn)行分層。例如時(shí)間維包含年、旬、月、周、天，甚至可以到小時(shí)這一層。在“立方體”中存儲的事實(shí)值，某些值就是合計值了，在進(jìn)行查詢(xún)時(shí)，就不需要利用SQL將所有記錄搜出來(lái)，再進(jìn)行統計運算，這樣就大大提高了最基本的查詢(xún)能力了。同時(shí)，利用一些聚類(lèi)算法等，還能發(fā)現一些“有意思的”結論，這就是DM/KDD（后面有講）。

OLAP會(huì )有另起一篇來(lái)詳細討論，主題的選擇，“立方體”的建立，維度設定，和DM怎樣結合等都是需要好好思考的。

Ad-hoc Query, 即席查詢(xún)

也就是基于前面OLAP中談到的“立方體”，因為統計值直接保存在DW中，就能大大提高查詢(xún)能力?？焖俚牟樵?xún)，也許就叫即席查詢(xún)了，^_^！

....to be continued !

已經(jīng)公開(kāi) 2007年7月11日 21:05 作者:SAP屠夫

評論

常見(jiàn)的幾種數據倉庫建模

一.直接報表型(Direct Reporting)

將數據倉庫看成是簡(jiǎn)單的報表集中器,結構簡(jiǎn)單,可多維分析.

二.獨立數據集市部門(mén)級數據倉庫(Data Mart)

認為數據倉庫就是Data Mart的集合,按照業(yè)務(wù)主題建立數據集市,

跨業(yè)務(wù)主題分析不方便.

三.企業(yè)級數據倉庫(EDW)

(1)Hub and Spoke(集線(xiàn)器與車(chē)輪狀)結構.

(2)高度統一的企業(yè)級數據倉庫結構.

這是目前比較流行的兩種主流數據倉庫建模體系,

一.集線(xiàn)器結構(Hub and Spoke)

•這種數據模型是建立一中央數據倉庫然后根據報表需求分主題建立數據集市.

類(lèi)似建立報表立方體,不能滿(mǎn)足大型的靈活性的數據倉庫.

二.統一的企業(yè)級數據倉庫

EDW中包含一層根據3NF建立的數據清洗層,數據完整后可以根據報表需求建立數據集市或將中央數據倉庫的數據復制到專(zhuān)門(mén)的在線(xiàn)分析的用于報表目的的信息立方體中.

關(guān)于統一的EDW有很多類(lèi)似邏輯結構圖,這是主流的數據倉庫結構圖.

缺點(diǎn):

假設建立清洗ODS層,則龐大的清洗邏輯必須在BW中用ABAP編寫(xiě)更新規則.

層次太多不方便維護

2007-07-11 22:11

先收了再說(shuō)

2007-07-12 11:21

自打實(shí)施駕駛艙,這篇文章我也看了好多遍了,但數據分析不是很好做的.......太多因素.

2007-07-12 14:12

我也學(xué)過(guò)數據挖掘，但總覺(jué)得很難！想真正用起來(lái)很難！

2007-07-12 16:38

"數據分析不是很好做的",如果各系統設計的邏輯關(guān)聯(lián)不緊密,估計做數據挖掘的會(huì )含冤而死,含恨而亡.

2007-07-12 21:00

數據倉庫設計概念

元數據對象圖.

元數據（Metadata）是關(guān)于數據的數據。在數據倉庫系統中，元數據可以幫助數據倉庫管理員和數據倉庫的開(kāi)發(fā)人員非常方便地找到他們所關(guān)心的數據；元數據是描述數據倉庫內數據的結構和建立方法的數據，可將其按用途的不同分為兩類(lèi)：技術(shù)元數據（Technical Metadata）和業(yè)務(wù)元數據（Business Metadata）。

技術(shù)元數據是存儲關(guān)于數據倉庫系統技術(shù)細節的數據，是用于開(kāi)發(fā)和管理數據倉庫使用的數據.

元數據作用

在數據倉庫系統中，元數據機制主要支持以下五類(lèi)系統管理功能：（１）描述哪些數據在數據倉庫中；（２）定義要進(jìn)入數據倉庫中的數據和從數據倉庫中產(chǎn)生的數據；（３）記錄根據業(yè)務(wù)事件發(fā)生而隨之進(jìn)行的數據抽取工作時(shí)間安排；（４）記錄并檢測系統數據一致性的要求和執行情況；（５）衡量數據質(zhì)量。

元數據管理任務(wù)

元數據管理的主要任務(wù)有兩個(gè)方面：一是負責存儲和維護元數據庫中的元數據；二是負責數據倉庫建模工具、數據獲取工具、前端工具等之間的消息傳遞，協(xié)調各模塊和工具之間的工作。

你通過(guò)RSA1|RSOR查看BW元數據,

由以上幾節我們了解到元數據幾乎可以被稱(chēng)為是數據倉庫乃至商業(yè)智能（BI）系統的“靈魂”，正是由于元數據在整個(gè)數據倉庫生命周期中有著(zhù)重要的地位，各個(gè)廠(chǎng)商的數據倉庫解決方案都提到了關(guān)于對元數據的管理。但遺憾的是對于元數據的管理，各個(gè)解決方案都沒(méi)有明確提出一個(gè)完整的管理模式；它們提供的僅僅是對特定的局部元數據的管理。

KPI Vs Key Figure .

KPI (Key Performance Indicator)關(guān)鍵績(jì)效指標是一個(gè)可衡量的業(yè)務(wù)指標,Key Figure是BW的一個(gè)技術(shù)術(shù)語(yǔ),KPI從Key Figure獲得數據

信息對象,特征,關(guān)鍵指標(InfoObject, Characteristic,Key figure)

信息對象包括特征和關(guān)鍵指標,一個(gè)特征可能有自己的主數據,文本,層次或復合超級信息對象. 特征可以理解為關(guān)鍵指標的描述,典型地,客戶(hù)編碼,物料編碼都是特征,相關(guān)的時(shí)間特征,單位也是特征,特征可組成不同維度.

3.關(guān)鍵指標一般是數量,金額, 比如銷(xiāo)售單價(jià),銷(xiāo)售數量.也可是編號,日期或時(shí)間型字段.

如果熟悉PA的朋友一定對KEA5(Characteristic特征),KEA6(Value fields值字段)不陌生.

Key figure 類(lèi)似value field .

對象關(guān)系映射（Object Relational Mapping，簡(jiǎn)稱(chēng)ORM）是一種為了解決面向對象與關(guān)系數據庫存在的互不匹配的現象的技術(shù)。簡(jiǎn)單的說(shuō)，ORM是通過(guò)使用描述對象和數據庫之間映射的元數據，將java程序中的對象自動(dòng)持久化到關(guān)系數據庫中。本質(zhì)上就是將數據從一種形式轉換到另外一種形式。這也同時(shí)暗示者額外的執行開(kāi)銷(xiāo)；然而，如果ORM作為一種中間件實(shí)現，則會(huì )有很多機會(huì )做優(yōu)化，而這些在手寫(xiě)的持久層并不存在。更重要的是用于控制轉換的元數據需要提供和管理；但是同樣，這些花費要比維護手寫(xiě)的方案要少；而且就算是遵守ODMG規范的對象數據庫依然需要類(lèi)級別的元數據。

對象-關(guān)系映射（Object/Relation Mapping，簡(jiǎn)稱(chēng)ORM），是隨著(zhù)面向對象的軟件開(kāi)發(fā)方法發(fā)展而產(chǎn)生的。面向對象的開(kāi)發(fā)方法是當今企業(yè)級應用開(kāi)發(fā)環(huán)境中的主流開(kāi)發(fā)方法，關(guān)系數據庫是企業(yè)級應用環(huán)境中永久存放數據的主流數據存儲系統。對象和關(guān)系數據是業(yè)務(wù)實(shí)體的兩種表現形式，業(yè)務(wù)實(shí)體在內存中表現為對象，在數據庫中表現為關(guān)系數據。內存中的對象之間存在關(guān)聯(lián)和繼承關(guān)系，而在數據庫中，關(guān)系數據無(wú)法直接表達多對多關(guān)聯(lián)和繼承關(guān)系。因此，對象-關(guān)系映射(ORM)系統一般以中間件的形式存在，主要實(shí)現程序對象到關(guān)系數據庫數據的映射。

面向對象是從軟件工程基本原則(如耦合、聚合、封裝)的基礎上發(fā)展起來(lái)的，而關(guān)系數據庫則是從數學(xué)理論發(fā)展而來(lái)的，兩套理論存在顯著(zhù)的區別。為了解決這個(gè)不匹配的現象,對象關(guān)系映射技術(shù)應運而生。

讓我們從O/R開(kāi)始。字母O起源于"對象"(Object),而R則來(lái)自于"關(guān)系"(Relational)。幾乎所有的程序里面，都存在對象和關(guān)系數據庫。在業(yè)務(wù)邏輯層和用戶(hù)界面層中，我們是面向對象的。當對象信息發(fā)生變化的時(shí)候，我們需要把對象的信息保存在關(guān)系數據庫中。

如上圖:

1. 數據抽取工具(ETL Service)：把業(yè)務(wù)系統中的數據抽取、轉換、集成到數據倉庫中，如Ardent的DataStage、CA（原Platinum）的Decision Base和ETI的Extract等。這些工具僅提供了技術(shù)元數據，幾乎沒(méi)有提供對業(yè)務(wù)元數據的支持。

2. 前端展現工具(Presentation Service)：包括OLAP分析、報表和商業(yè)智能工具等，如MicroStrategy的DSS Agent、Cognos的PowerPlay、Business Objects的BO，以及Brio等。它們通過(guò)把關(guān)系表映射成與業(yè)務(wù)相關(guān)的事實(shí)表和維表來(lái)支持多維業(yè)務(wù)視圖，進(jìn)而對數據倉庫中的數據進(jìn)行多維分析。這些工具都提供了業(yè)務(wù)元數據與技術(shù)元數據相對應的語(yǔ)義層。

3. 分析建模工具：為非技術(shù)人員準備的業(yè)務(wù)建模工具，這些工具可以提供更高層的與特定業(yè)務(wù)相關(guān)的語(yǔ)義。如CA的ERwin、Sysbase的PowerDesigner以及Rational的Rose等。

4. 數據存儲工具：元數據通常存儲在專(zhuān)用的數據庫中，該數據庫就如同一個(gè)“黑盒子”，外部無(wú)法知道這些工具所用到和產(chǎn)生的元數據是如何存儲的。還有一類(lèi)被稱(chēng)為元數據知識庫（Metadata Repository）的工具，它們獨立于其它工具，為元數據提供一個(gè)集中的存儲空間. 業(yè)務(wù)數據則以ODS或InfoCube保存在數據倉庫服務(wù)器.

數據倉庫領(lǐng)域中兩個(gè)最主要的元數據標準：

MDC的OIM標準和OMG的CWM標準。

4.1 MDC的OIM存儲模型

MDC成立于1995年，是一個(gè)致力于建立與廠(chǎng)商無(wú)關(guān)的、不依賴(lài)于具體技術(shù)的企業(yè)元數據管理標準的非贏(yíng)利技術(shù)聯(lián)盟，該聯(lián)盟有150多個(gè)會(huì )員，其中包括微軟和IBM等著(zhù)名軟件廠(chǎng)商。1999年7月MDC接受了微軟的建議，將OIM作為元數據標準。

OIM的目的是通過(guò)公共的元數據信息來(lái)支持不同工具和系統之間數據的共享和重用。它涉及了信息系統（從設計到發(fā)布）的各個(gè)階段，通過(guò)對元數據類(lèi)型的標準描述來(lái)達到工具和知識庫之間的數據共享。OIM所聲明的元數據類(lèi)型都采用統一建模語(yǔ)言UML（Universal Modeling Language）進(jìn)行描述，并被組織成易于使用、易于擴展的多個(gè)主題范圍（Subject Areas），這些主題范圍包括：

分析與設計（Analysis and Design）：主要用于軟件分析、設計和建模。該主題范圍又進(jìn)一步劃分為：UML包（Package）、UML擴展包、通用元素（Generic Elements）包、公共數據類(lèi)型（Common Data Types）包和實(shí)體關(guān)系建模（Entity Relationship Modeling）包等。

對象與組件（Object and? Component）：涉及面向對象開(kāi)發(fā)技術(shù)的方方面面。該主題范圍只包含組件描述建模（Component Description Modeling）包。

數據庫與數據倉庫（Database and Warehousing）：為數據庫模式管理、復用和建立數據倉庫提供元數據概念支持。該主題范圍進(jìn)一步劃分為：關(guān)系數據庫模式（Relational Database Schema）包、OLAP模式（OLAP Schema）包、數據轉換（Data Transformations）包、面向記錄的數據庫模式（Record-Oriented Database Schema）包、XML模式（XML Schema）包和報表定義（Report Definitions）包等。

業(yè)務(wù)工程（Business? Engineering）：為企業(yè)運作提供一個(gè)藍圖。該主題范圍進(jìn)一步劃分為：業(yè)務(wù)目標（Business Goal）包、組織元素（Organizational Elements）包、業(yè)務(wù)規則（Business Rules）包、商業(yè)流程（Business Processes）包等。

知識管理（Knowledge? Management）：涉及企業(yè)的信息結構。該主題范圍進(jìn)一步劃分為：知識描述（Knowledge Descriptions）包和語(yǔ)義定義（Semantic Definitions）包。

上述主題范圍中的包都是采用UML定義的，可以說(shuō)UML語(yǔ)言是整個(gè)OIM標準的基礎。雖然OIM標準并不是專(zhuān)門(mén)針對數據倉庫的，但數據倉庫是它的主要應用領(lǐng)域之一。目前市場(chǎng)上基于該標準的元數據管理工具已經(jīng)比較成熟，例如微軟的Repositry和CA的Repositry均采用了OIM標準。

4.2 OMG組織的CWM模型

OMG是一個(gè)擁有500多會(huì )員的國際標準化組織，著(zhù)名的CORBA標準即出自該組織。公共倉庫元模型（Common Warehouse Metamodel）的主要目的是在異構環(huán)境下，幫助不同的數據倉庫工具、平臺和元數據知識庫進(jìn)行元數據交換。2001年3月，OMG頒布了CWM 1.0標準。CWM模型既包括元數據存儲，也包括元數據交換，它是基于以下三個(gè)工業(yè)標準制定的：

(1) UML：它對CWM模型進(jìn)行建模。

(2) MOF（元對象設施）：它是OMG元模型和元數據的存儲標準，提供在異構環(huán)境下對元數據知識庫的訪(fǎng)問(wèn)接口。

(3) XMI（XML元數據交換）：它可以使元數據以XML文件流的方式進(jìn)行交換。

OMG元數據知識庫體系結構如圖3所示。

CWM為數據倉庫和商業(yè)智能（BI）工具之間共享元數據，制定了一整套關(guān)于語(yǔ)法和語(yǔ)義的規范。它主要包含以下四個(gè)方面的規范：

(1) CWM元模型（Metamodel）：描述數據倉庫系統的模型；

(2) CWM XML：CWM元模型的XML表示；

(3) CWM DTD：DW/BI共享元數據的交換格式

(4) CWM IDL：DW/BI共享元數據的應用程序訪(fǎng)問(wèn)接口（API）

下面重點(diǎn)討論CWM元模型的組成，它與OIM規范一樣，也是由很多包組成的。組成CWM元模型的包結構如圖4所示。

(1) 元模型（MetaModel）包：構造和描述其它CWM包中的元模型類(lèi)的基礎。它是UML的一個(gè)子集，由以下四個(gè)子包組成：

a) 核心（Core）包：它的類(lèi)和關(guān)聯(lián)是該模型的核心，其它所有的包都以它為基礎。

b) 行為（Behavioral）包：包括描述CWM對象行為的類(lèi)與關(guān)聯(lián)，并且它為描述所定義的行為提供了基礎。

c) 關(guān)系（Relationships）包：包括描述CWM對象之間關(guān)系的類(lèi)與關(guān)聯(lián)。

d) 實(shí)例（Instance）包：包括表示CWM分類(lèi)器（Classfier）的類(lèi)與關(guān)聯(lián)。

(2) 基礎包（Foundation）：它包括表示CWM概念和結構的模型元素，這些模型元素又可被其他CWM包所共享，它由以下六個(gè)子包組成：

a) 業(yè)務(wù)信息（Business Information）包：包括表示模型元素業(yè)務(wù)信息的類(lèi)與關(guān)聯(lián)。

b) 數據類(lèi)型（Data Types）包：包括表示建模者可以用來(lái)創(chuàng )建所需數據類(lèi)型的結構的類(lèi)與關(guān)聯(lián)。

c) 表達式（Expressions）包：包括表示表達式樹(shù)的類(lèi)與關(guān)聯(lián)。

d) 關(guān)鍵字和索引（Keys and Indexes）包：包括表示鍵和索引的類(lèi)與關(guān)聯(lián)。

e) 軟件發(fā)布（Software Deployment）包：包括軟件如何在數據倉庫中發(fā)布的類(lèi)與關(guān)聯(lián)。

f) 類(lèi)型映射（Type Mapping）包：包括表示不同系統之間數據類(lèi)型映射的類(lèi)與關(guān)聯(lián)。

(3) 資源包（Resource）：用于描述數據資源的包，它包括以下四個(gè)子包：

a) 關(guān)系（Relational）包：包括表示關(guān)系型數據資源的元數據的類(lèi)與關(guān)聯(lián)。

b) 記錄（Record）包：包括表示記錄型數據資源的元數據的類(lèi)與關(guān)聯(lián)。

c) 多維（Multidimensional）包：包括表示多維數據資源的元數據的類(lèi)與關(guān)聯(lián)。

d) XML包：包括表示XML數據資源的元數據的類(lèi)與關(guān)聯(lián)。

(4) 分析（Analysis）包：它由以下五個(gè)子包組成：

a) 轉換（Transformation）包：包括表示數據抽取和轉換工具的元數據的類(lèi)與關(guān)聯(lián)。

b) OLAP包：包括表示OLAP工具的元數據的類(lèi)與關(guān)聯(lián)。

c) 數據挖掘（Data Mining）包：包括表示數據挖掘工具的元數據的類(lèi)與關(guān)聯(lián)。

d) 信息可視化（Information Visualization）包：包括表示信息可視化工具的元數據的類(lèi)與關(guān)聯(lián)。

e) 業(yè)務(wù)術(shù)語(yǔ)（Business Nomenclature）包：包括表示分類(lèi)業(yè)務(wù)的元數據的類(lèi)與關(guān)聯(lián)。

(5) 管理（Management）包：用于描述數據倉庫管理的包，它包括以下兩個(gè)子包：

a) 倉庫過(guò)程（Warehouse Process）包：包括表示倉庫過(guò)程的元數據的類(lèi)與關(guān)聯(lián)。

b) 倉庫操作（Warehouse Operation）包：包括表示倉庫操作結果的元數據的類(lèi)與關(guān)聯(lián)。

在數據抽取過(guò)程中，數據從各個(gè)業(yè)務(wù)系統中被統一轉換存儲到中央數據倉庫中。CWM中的轉換模型定義了數據在源和目的之間移動(dòng)的過(guò)程，其中不僅包括源和目標之間的參數，還包括轉換中的業(yè)務(wù)邏輯。這些業(yè)務(wù)邏輯可能包括一些商業(yè)規則、類(lèi)庫甚至是用戶(hù)腳本。數據倉庫如果有一個(gè)規范的轉換模型將給工具軟件廠(chǎng)商和專(zhuān)業(yè)服務(wù)提供商帶來(lái)極大的好處，例如，按照統一的規范廠(chǎng)商可以設計一個(gè)通用的模型從標準ERP包中抽取數據。工具廠(chǎng)商甚至可以隨軟件提供成熟的模型，集成商也可以將一個(gè)模型應用到多個(gè)項目中。

最終用戶(hù)同樣也能從CWM中受益，在使用商業(yè)智能分析軟件進(jìn)行多維分析的時(shí)候，用戶(hù)往往會(huì )對數據的含義和來(lái)源產(chǎn)生疑問(wèn)。CWM能夠提供這些信息，用戶(hù)可以清楚地看到數據來(lái)自哪個(gè)系統，并且是如何組成的。

4.3 CWM與OIM之間的關(guān)系

上兩節分別介紹了與數據倉庫相關(guān)的兩個(gè)主要標準，CWM實(shí)際上是專(zhuān)門(mén)為數據倉庫元數據而制定的一套標準，而OIM并不是針對數據倉庫元數據的。OIM所關(guān)注的元數據的范圍比CWM要廣，CWM只限定于數據倉庫領(lǐng)域，而OIM模型包括有：分析與設計模型、對象與組件、數據庫與數據倉庫、商業(yè)工程、知識管理等五個(gè)領(lǐng)域。OIM與CWM在建模語(yǔ)言的選擇（都選擇UML當做自己的描述語(yǔ)言）、數據庫模型的支持、OLAP分析模型的支持、數據轉換模型的支持方面都比較一致；但是OIM并不是基于元對象設施（MOF）的，這意味著(zhù)用OIM所描述的元數據需要通過(guò)其它的接口才能訪(fǎng)問(wèn)，而CWM所描述的元數據可以通過(guò)CORBA IDL來(lái)訪(fǎng)問(wèn)；在數據交換方面，OIM必須通過(guò)特定的轉換形成XML文件來(lái)交換元數據，而CWM可以用XMI來(lái)進(jìn)行交換。盡管如此，由于OMG與MDC兩個(gè)組織的合并，CWM也會(huì )與OIM相互兼容以保護廠(chǎng)商已有的投資。

需要說(shuō)明的是，MDC與OMG組織已經(jīng)合并，今后所有的工具都將遵循統一的CWM標準，不過(guò)支持CWM的工具才剛剛出現，而支持OIM標準的工具已經(jīng)相對成熟。

5. 元數據管理的相關(guān)研究工作

目前元數據的研究集中在：數據和數據庫管理[11,12,13]、元數據模型[14,15,16]、數據集成[17,18]、元數據工具[19]。在各研究領(lǐng)域中都存在一些問(wèn)題。

在數據倉庫的研究課題當中，有許多是針對元數據的研究。文獻〔5〕描述了一個(gè)在數據倉庫環(huán)境中，基于微軟的Repositry的、元數據驅動(dòng)的數據轉換方法，它包含了技術(shù)元數據與業(yè)務(wù)元數據；文獻〔6〕中描述了一個(gè)基于元數據的數據倉庫安全的解決方法，它只限定在技術(shù)元數據級別；更有名的一個(gè)研究項目是數據倉庫質(zhì)量項目（Data Warehouse Quality），這個(gè)項目的核心是通過(guò)元數據模型來(lái)衡量整個(gè)數據倉庫中的數據質(zhì)量。它是基于一個(gè)演繹數據庫CONCEPTBASE的，并且使用該數據庫特定的邏輯語(yǔ)言進(jìn)行描述，目前該項目距離實(shí)用的階段還比較遠。

2007-07-12 21:22

數據倉庫設計概念

元數據對象圖.

技術(shù)元數據是存儲關(guān)于數據倉庫系統技術(shù)細節的數據，是用于開(kāi)發(fā)和管理數據倉庫使用的數據.

元數據作用

元數據管理任務(wù)

你通過(guò)RSA1|RSOR查看BW元數據,

KPI Vs Key Figure .

KPI (Key Performance Indicator)關(guān)鍵績(jì)效指標是一個(gè)可衡量的業(yè)務(wù)指標,Key Figure是BW的一個(gè)技術(shù)術(shù)語(yǔ),KPI從Key Figure獲得數據

信息對象,特征,關(guān)鍵指標(InfoObject, Characteristic,Key figure)

3.關(guān)鍵指標一般是數量,金額, 比如銷(xiāo)售單價(jià),銷(xiāo)售數量.也可是編號,日期或時(shí)間型字段.

如果熟悉PA的朋友一定對KEA5(Characteristic特征),KEA6(Value fields值字段)不陌生.

Key figure 類(lèi)似value field .

如上圖:

數據倉庫領(lǐng)域中兩個(gè)最主要的元數據標準：

MDC的OIM標準和OMG的CWM標準。

4.1 MDC的OIM存儲模型

對象與組件（Object and? Component）：涉及面向對象開(kāi)發(fā)技術(shù)的方方面面。該主題范圍只包含組件描述建模（Component Description Modeling）包。

4.2 OMG組織的CWM模型

(1) UML：它對CWM模型進(jìn)行建模。

(2) MOF（元對象設施）：它是OMG元模型和元數據的存儲標準，提供在異構環(huán)境下對元數據知識庫的訪(fǎng)問(wèn)接口。

(3) XMI（XML元數據交換）：它可以使元數據以XML文件流的方式進(jìn)行交換。

OMG元數據知識庫體系結構如圖3所示。

CWM為數據倉庫和商業(yè)智能（BI）工具之間共享元數據，制定了一整套關(guān)于語(yǔ)法和語(yǔ)義的規范。它主要包含以下四個(gè)方面的規范：

(1) CWM元模型（Metamodel）：描述數據倉庫系統的模型；

(2) CWM XML：CWM元模型的XML表示；

(3) CWM DTD：DW/BI共享元數據的交換格式

(4) CWM IDL：DW/BI共享元數據的應用程序訪(fǎng)問(wèn)接口（API）

下面重點(diǎn)討論CWM元模型的組成，它與OIM規范一樣，也是由很多包組成的。組成CWM元模型的包結構如圖4所示。

(1) 元模型（MetaModel）包：構造和描述其它CWM包中的元模型類(lèi)的基礎。它是UML的一個(gè)子集，由以下四個(gè)子包組成：

a) 核心（Core）包：它的類(lèi)和關(guān)聯(lián)是該模型的核心，其它所有的包都以它為基礎。

b) 行為（Behavioral）包：包括描述CWM對象行為的類(lèi)與關(guān)聯(lián)，并且它為描述所定義的行為提供了基礎。

c) 關(guān)系（Relationships）包：包括描述CWM對象之間關(guān)系的類(lèi)與關(guān)聯(lián)。

d) 實(shí)例（Instance）包：包括表示CWM分類(lèi)器（Classfier）的類(lèi)與關(guān)聯(lián)。

(2) 基礎包（Foundation）：它包括表示CWM概念和結構的模型元素，這些模型元素又可被其他CWM包所共享，它由以下六個(gè)子包組成：

a) 業(yè)務(wù)信息（Business Information）包：包括表示模型元素業(yè)務(wù)信息的類(lèi)與關(guān)聯(lián)。

b) 數據類(lèi)型（Data Types）包：包括表示建模者可以用來(lái)創(chuàng )建所需數據類(lèi)型的結構的類(lèi)與關(guān)聯(lián)。

c) 表達式（Expressions）包：包括表示表達式樹(shù)的類(lèi)與關(guān)聯(lián)。

d) 關(guān)鍵字和索引（Keys and Indexes）包：包括表示鍵和索引的類(lèi)與關(guān)聯(lián)。

e) 軟件發(fā)布（Software Deployment）包：包括軟件如何在數據倉庫中發(fā)布的類(lèi)與關(guān)聯(lián)。

f) 類(lèi)型映射（Type Mapping）包：包括表示不同系統之間數據類(lèi)型映射的類(lèi)與關(guān)聯(lián)。

(3) 資源包（Resource）：用于描述數據資源的包，它包括以下四個(gè)子包：

a) 關(guān)系（Relational）包：包括表示關(guān)系型數據資源的元數據的類(lèi)與關(guān)聯(lián)。

b) 記錄（Record）包：包括表示記錄型數據資源的元數據的類(lèi)與關(guān)聯(lián)。

c) 多維（Multidimensional）包：包括表示多維數據資源的元數據的類(lèi)與關(guān)聯(lián)。

d) XML包：包括表示XML數據資源的元數據的類(lèi)與關(guān)聯(lián)。

(4) 分析（Analysis）包：它由以下五個(gè)子包組成：

a) 轉換（Transformation）包：包括表示數據抽取和轉換工具的元數據的類(lèi)與關(guān)聯(lián)。

b) OLAP包：包括表示OLAP工具的元數據的類(lèi)與關(guān)聯(lián)。

c) 數據挖掘（Data Mining）包：包括表示數據挖掘工具的元數據的類(lèi)與關(guān)聯(lián)。

d) 信息可視化（Information Visualization）包：包括表示信息可視化工具的元數據的類(lèi)與關(guān)聯(lián)。

e) 業(yè)務(wù)術(shù)語(yǔ)（Business Nomenclature）包：包括表示分類(lèi)業(yè)務(wù)的元數據的類(lèi)與關(guān)聯(lián)。

(5) 管理（Management）包：用于描述數據倉庫管理的包，它包括以下兩個(gè)子包：

a) 倉庫過(guò)程（Warehouse Process）包：包括表示倉庫過(guò)程的元數據的類(lèi)與關(guān)聯(lián)。

b) 倉庫操作（Warehouse Operation）包：包括表示倉庫操作結果的元數據的類(lèi)與關(guān)聯(lián)。

4.3 CWM與OIM之間的關(guān)系

5. 元數據管理的相關(guān)研究工作

2007-07-12 21:22

簡(jiǎn)單介紹一下BI的大概設計思路及其它和ERP的關(guān)系,首先熟悉下面幾個(gè)概念,如下圖:

1.源系統(Source System)

源系統可以是ERP System 或non-ERP的桌面文件和第三方數據庫,源系統告訴數據倉庫到什么地方和如何抽取數據.

2.信息源和數據源(InfoSource Vs DataSource)

你簡(jiǎn)單理解信息就是高效組織的有用的數據,數據倉庫(Data Warehouse)的任務(wù)不僅僅是數據存儲(Data Storage),而是要將收集的各種數據變成有用的信息提供決策支持,所以你就很容易理解為什么ERP邊叫數據源,而數據倉庫這邊稱(chēng)信息源.

數據源頭抽取結構的字段叫字段,信息源這邊則叫做信息對象,如果要說(shuō)區別,信息對象顯然不僅僅是一個(gè)簡(jiǎn)單字段這樣,前面我們已經(jīng)知道特征和關(guān)鍵指標都成為信息對象,比如會(huì )計科目特征,它對應到會(huì )計科目字段,但是會(huì )計科目這個(gè)特征還有相關(guān)屬性,文本和層次.

信息源和數據源的關(guān)系前面已經(jīng)提及是一對多的關(guān)系,我們還知道一個(gè)源系統的數據源還必須Replicate后才能在DW中生成結構從而分配給信息源.

數據源

常用的四種數據源類(lèi)型:

1.業(yè)務(wù)數據類(lèi)型,通過(guò)它傳輸R/3業(yè)務(wù)交易數據.

2.屬特類(lèi)型,特征屬性就是特征的主數據.

3.文本類(lèi)型,特征的文本.

4.特征的層次節點(diǎn)類(lèi)型(目前BW版本層次只能使用Direct update).

信息源包括這么幾個(gè)主要部件:(1)通信結構(2)傳輸結構(3)傳輸規則(4)傳輸方法

3.通信結構(Communication Structure)

通信結構是數據從信息源傳輸到數據目標的通道

4.傳輸結構(Transfer Structure)

傳輸結構將R/3或非R/3數據源的字段映射到信息源的信息對象.

注意兩個(gè)東西:數據源->信息源字段->信息對象

5.抽取結構

R/3將各模塊保存在的數據庫表的數據抽取后暫時(shí)存放的一個(gè)結構,

你簡(jiǎn)單理解為數據源包括兩個(gè)部分:1.抽取結構 2.傳輸結構和相關(guān)傳輸程序

6.傳輸規則(Transfer rule)

在設計數據倉庫時(shí),盡量注意避免讓用戶(hù)自己編寫(xiě)代碼, 一個(gè)成熟的產(chǎn)品應該是讓用戶(hù)脫離技術(shù)只注重業(yè)務(wù)實(shí)現.

簡(jiǎn)單地說(shuō),數據源在ERP邊充當數據通道的角色,真正的源數據(Data Source)當然就是ERP的業(yè)務(wù)交易表格, 而信息源(Infosource)則在DW/BI系統充當數據通道角色, 最后數據保存到數據倉庫的存儲裝置,通常是ODS或Infocube .

實(shí)際上ERP系統設計同樣,本人做ERP開(kāi)發(fā)多年,到現在尚且厭煩開(kāi)發(fā),ERP實(shí)施過(guò)程中的開(kāi)發(fā)和快速實(shí)施實(shí)際上是嚴重矛盾的...

在DW/BI系統中,還有幾個(gè)重要概念:ODS/DSO/Infocube....

2007-07-12 22:05

ETL的設計

數據抽取工具的設計無(wú)意是件非常困難的事情.如何設計一個(gè)好的ETTL,Kimball老兄提供了如下一些經(jīng)驗:

Something ETL Designer must know:

Analysis

1. What is a logical data mapping and what does it mean to the ETL team?

2. What are the primary goals of the data discovery phase of the data warehouse project?

3. How is the system-of-record determined?

Architecture

4. What are the four basic Data Flow steps of an ETL process?

5. What are the permissible data structures for the data staging area? Briefly describe the pros

and cons of each.

6. When should data be set to disk for safekeeping during the ETL?

Extract

7. Describe techniques for extracting from heterogeneous data sources.

8. What is the best approach for handling ERP source data?

9. Explain the pros and cons of communicating with databases natively versus ODBC.

10. Describe three change data capture (CDC) practices and the pros and cons of each.

Data Quality

11. What are the four broad categories of data quality checks? Provide an implementation

technique for each.

12. At which stage of the ETL should data be profiled?

13. What are the essential deliverables of the data quality portion of ETL?

14. How can data quality be quantified in the data warehouse?

Building mappings

15. What are surrogate keys? Explain how the surrogate key pipeline works.

16. Why do dates require special treatment during the ETL process?

17. Explain the three basic delivery steps for conformed dimensions.

18. Name the three fundamental fact grains and describe an ETL approach for each.

19. How are bridge tables delivered to classify groups of dimension records associated to a single

fact?

20. How does late arriving data affect dimensions and facts? Share techniques for handling each.

Metadata

21. Describe the different types of ETL metadata and provide examples of each.

22. Share acceptable mechanisms for capturing operational metadata.

23. Offer techniques for sharing business and technical metadata.

Optimization/Operations

24. State the primary types of tables found in a data warehouse and the order which they must be

loaded to enforce referential integrity.

25. What are the characteristics of the four levels of the ETL support model?

26. What steps do you take to determine the bottleneck of a slow running ETL process?

27. Describe how to estimate the load time of a large ETL job.

Real Time ETL

28. Describe the architecture options for implementing real-time ETL.

29. Explain the different real-time approaches and how they can be applied in different business

scenarios.

30. Outline some challenges faced by real-time ETL and describe how to overcome them.

From <<ETL Toolkit>>--- Written By Kimball

轉換和加載 (ETL, Extract, Transform, Load) 是構建數據倉庫過(guò)程中最復雜也是至關(guān)重要的一個(gè)步驟，我們通常用兩種辦法來(lái)處理ETL流程: 一種是異步(Asynchronous) ETL方式, 也稱(chēng)為文本文件(Flat file)方式。另外一種是同步(Synchronous) ETL方式，也稱(chēng)為直接傳輸 (Direct transfer) 方式。根據項目的各自特點(diǎn)，合理選擇恰當的數據抽取流程，確定抽取過(guò)程中的監督核查機制，對于DW項目的成功可以起到事半功倍的作用。

同步并不等于實(shí)時(shí)，ERP系統是一個(gè)7×24小時(shí)都有新數據插入的系統，如何解決同步呢？一種解決辦法是設置一個(gè)時(shí)間區間，定義每次抽取的開(kāi)始和結束時(shí)間值，數據抽取可采用增量抽取的方式，系統記錄最近上一次的數據抽取時(shí)間。

2007-07-12 22:12

操作數據存儲ODS和信息立方體比較

聯(lián)系:

1.都是數據目標

2.都是數據存儲裝置(Storage Services)

3.都可建立查詢(xún),ODS選上允許查詢(xún)

4.目前的BW版本已經(jīng)支持連接ODS和信息立方體成為多立方體.

多立方體只是一個(gè)結構,建立多立方體必須注意數據重復,

如果你熟悉多表Select就很容易明白此點(diǎn).

ODS特點(diǎn):

1.ODS寫(xiě)數據可能更快,信息立方體肯定速度要慢.

2.ODS是簡(jiǎn)單的扁平的關(guān)系性表

3.數據裝載必須通過(guò)PSA.

4.默認的更新規則是覆蓋方式

5.ODS成為數據建模的一個(gè)中間層,除非必要,不建立中間ODS,但是業(yè)務(wù)往往都是需要的

InfoCube特點(diǎn):

1.基于星型結構,事實(shí)表在中央.

2.周?chē)蔷S度表便于多維分析

3.維度的建立是有講究的,比如同一維度表的數據不要出現多對多.

4.可以使用聚集

5.默認的更新方式是添加.

DS層，一般大家都能夠認同它是一種操作型比較強的、未保留歷史或者保留近期歷史的數據。所謂操作型，是相對分析型而言的。后者多是匯總的、便于分析統計的結構。操作型的另一個(gè)特點(diǎn)就是經(jīng)常會(huì )被更新，而分析型數據很少如此。然而，對于ODS的認識，也有不同。

常見(jiàn)的爭議包括： ODS是否應該被最終用戶(hù)訪(fǎng)問(wèn)？ODS存在的目的是僅僅供DW層獲取經(jīng)過(guò)清洗的數據，還是能夠讓用戶(hù)從中得到統計報表？關(guān)于前一個(gè)問(wèn)題，在筆者以前做經(jīng)營(yíng)分析的時(shí)候，就曾遇到這樣的爭議；關(guān)于后一個(gè)問(wèn)題，如果讓它僅僅具備前一項功能，倒是結構清晰、易于管理，是一種好的設計風(fēng)格，但恐怕不能滿(mǎn)足用戶(hù)靈活的需求。而如果可以讓用戶(hù)查詢(xún)統計，可能造成它統計的數據和DW統計的數據不一致。

對于DW層，一般大家都會(huì )認同，這是保留歷史數據的地方。但它是按照第三范式還是維度建模呢？當然，最大的不同就是：是需要一個(gè)中心DW，還是一個(gè)由若干數據集市組成的“虛擬”的DW。至于DM層，對此基本有一致的認同，這是面向最終用戶(hù)分析統計的，采用維度建模再好不過(guò)。

可因為對DW層建模方法的不同觀(guān)點(diǎn)，因此也就出來(lái)了所謂CDW的提法。想想，如果DW是按照第三范式建模，而DM是按照維度建模的話(huà)，那么它們之間該如何過(guò)渡？看上去，CDW確實(shí)也有存在的必要，在這個(gè)區域，需要形成滿(mǎn)足總線(xiàn)架構所需的一致性維度（Confirmed Dimension）和一致性事實(shí)（Confirmed Fact）。

但問(wèn)題是，第三范式和維度建模難道就真得水火不相容？筆者更相信一個(gè)道理—架構中沒(méi)有絕對的設計原則。所謂第三范式，只是指出一種理想的ER（實(shí)體-關(guān)系模型）設計模式，但實(shí)際做設計時(shí)，設計師大多會(huì )去做一些平衡，他們也許會(huì )說(shuō)，“為了性能、應用方便，會(huì )考慮適當的冗余。”可這適當冗余不也就破壞了第三范式嗎？而且這個(gè)“適當”誰(shuí)也說(shuō)不準是多少。因此，可以理解EDW并不是絕對的第三范式，而所謂維度建模又能夠和第三范式有多少沖突呢？在其本身概念里面，星型模式是一種不太符合第三范式的ER結構，但只是不“太”，如果改成雪花模式，是不是也就是第三范式了呢？

本站僅提供存儲服務(wù)，所有內容均由用戶(hù)發(fā)布，如發(fā)現有害或侵權內容，請點(diǎn)擊舉報。

欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久