觀察數據的角度稱之為維。

決策數據市多為數據，多維數據分析是決策分析的組要內容。

OLAP是在OLTP的基礎上發展起來的，OLTP是以數據庫為基礎的，

面對的是操作人員和底層管理人員，對基本數據進行查詢和增，刪，改等處理。

OLAP是以數據倉庫為基礎的數據分析處理，它有兩個特點：

1.在線性，體現為對用戶請求的快速響應和交互式操作，它的實現是由

客戶/服務器這種體系結構來完成的；

2.多維分析，也是OLAP的核心所在。

OLAP：一種軟件技術，它使分析人員能夠迅速、一致、交互地從各個方面觀察信息，

以達到深入理解數據的目的。這些信息是從原始數據轉換過來的，按照用戶的理解，

它反應了企業真實的方方面面。

OLAP：四個特征

1.快速性（Fast）5秒內對用戶的大部分分析要求做出反應，小于30秒內。

2.可分析性（Analysis）

3.多維性（Multidimensional）包括對層次維和多重層次維的完全支持。

4.信息性（Information）

OLAP的基本概念

OLAP是針對特定問題的聯機數據進行訪問和分析。

1.變量：是一個數值度量指標。

2.維：是人們觀察數據的特定角度。

例如：企業常常關系產品銷售數據隨著時間推移而產生的變化情況，

這是從時間的角度來觀察產品的銷售，所以時間是一個維（時間維）。

企業也時常關心自己的產品在不同地區的銷售分布情況，這是從地理分布的角度來觀察

產品的銷售，所以地理分布也是一個維（地理維）。其他還有如產品維，顧客維等。

3.維的層次

人們觀察數據的某個特定角度（即某個維）還可以在細節程度不同的多個描述方面，我們

稱這多個描述方面為維的層次。一個維往往具有多個層次，例如，描述時間維時，可以從

日期，月份，季度，年等不同層次來描述，那么日期，月份，季度，年等就是時間維的層次；同樣城市，地區，國家等構成了地理維的層次。

4.維成員

維的一個取值稱為該維的一個成員。如果一個維是多層次的，那么該維的維成員是有各個

不同維層次的取值組合而成。例如，我們考慮時間維具有日期，月份，年這三個層次，分別在日期，月份，年上各取一個值組合起來，就得到了時間維的一個維成員，即“某年某月某日”。

一個維成員并不一定在每個維層次上都要取值，例如，“某年某月”，“某月某日”，“某年”等等都是時間維的維成員。

對應一個數據項來說，維成員是該數據項在某維中位置的描述。例如，對一個銷售數據來說，時間維的維成員“某年某月某日”就表示該銷售數據是“某年某月某日”的銷售數據，

“某年某月某日”是該銷售數據在時間維上位置的描述。

5.多維數組

一個多維數組可以表示為：（維1，維2，......，維n，變量）。例如，若日用品銷售數據是按時間、地區和銷售渠道組織起來的三維立方體，加上變量“銷售額”，就組成了一個多維數組（地區，時間，銷售渠道），如果在此基礎行再擴展一個產品維，就得到一個四維的結構，其多維數組維（產品，地區，時間，銷售渠道，銷售額）。

6.數據單元（單元格）

多維數組的取值稱為數據單元。當多維數組的各個維都選中一個維成員，這些維成員的組合就惟一確定了一個變量的值。那么數據單元就可以表示為：（維1維成員，維2維成員，......，維n維成員，變量的值）。例如，在產品，地區，時間和銷售渠道上各取維成員“牙膏”，“上海”，“1998年12月”和“批發”，就惟一確定了變量“銷售額”的一個值（假設為100000），則該數據單元可表示為：（牙膏，上海，1998年12月，批發，100000）。

OLAP是一項給數據分析人員以靈活，可用和及時的方式構造、處理和表示綜合數據的技術。

OLAP技術可以在數秒中（通常是5~30秒）完成分類查詢。

OLAP主要是關于如何理解聚集的大量的數據。

OLAP的目的就是分析這些數據，尋找模式，趨勢以及例外情況。

聯機分析處理特征：

1.可以存取大量的數據，比如，幾年的銷售數據，分析各個商業元素

類型之間的關系，如銷售，產品，地區，渠道。

2.要包含聚集的數據，例如，銷售量，預算金額以及消費金額。

3.按層次對比不同時間周期的聚集數據，如以月，季度或者年。

4.以不同的方式來表現數據，如以地區，或者每一地區內按不同銷售渠道，不同產品等。

5.要包含數據元素之間的復雜的計算，如在某一地區的每一銷售渠道的期望利潤與銷售收入之間的分析。

6.能夠快速地響應用戶的查詢，以便用戶的分析思考過程不受系統影響。

基本的多維數據分析概念包括切片，切塊，旋轉等。

1.切片和切塊（Slice and Dice）

選定多維數組的一個二維子集的操作叫做切片，即選定多維數組（維1，維2，......,維n,變量）中的兩個維，如維i和維j，稱這個二維子集為多維數組在維i和維j上的一個切片，表示為（維i，維j，變量）

切片就是在某兩個維上取一定區間的維成員或全部維成員，而在其余的維上選定一個維成員的操作。

維是觀察數據的角度，那么切片的作用或結果就是舍棄一些觀察角度，使人們能在兩個維

上集中觀察數據。人的空間想象能力有限，一般很難想象思維四維以上的空間結構。所以，對于維數較多的多維數據空間，數據切片市十分有意義的。

切塊可以看成是切片的基礎上，進一步確定各個維成員的區間得到的片段體，即是由多個切片疊合起來。

對于時間維的切片（時間取一個確定值），如果將時間維上的取值設定為一個區間（例如，取“1990年~1999年”），而非單一的維成員時，就得到一個數據切塊，它可以看成時有1990年~1999年10個切片疊合而成的。

2.鉆取（Drill）

鉆取有向下鉆取（Drill Down）和向上賺取（Drill Up）操作。

向下鉆取是使用戶在多層數據中能通過導航信息而獲得更多的細節性數據，而向上鉆取是獲取概括性的數據。

Drill的深度與維所劃分的層次相對應。

3.旋轉（Pivoting）

通過旋轉可以得到不同視角的數據。旋轉操作相當于平面數據將坐標軸旋轉。

例如，旋轉可能包含了交換行和列，或是把某一行維移到列維中去，或是把頁面顯示中的一個維和頁面外的維進行交換（令其成為新的行或列中的一個）。

廣義OLAP

1.基本代理操作

“代理”是一些智能性代理，當系統處于某種特殊狀態時提醒分析員。

（1）示警報告

定義一些條件，一旦條件滿足，系統會提醒分析員去做分析，如每日報告完成或月定貨完成后通知分析員作分析。

（2）時間報告

按日歷和時鐘提醒分析員。

（3）異常報告

當超出邊界條件時提醒分析員，如銷售情況已超出定義閾值的上限或下限時提醒分析員。

OLAP工具評價指標

特征和功能

OLAP是一種分析處理技術，它通過計算公式和轉換規則從現有的數據中生存新的信息，并

予以顯示。OLAP服務器和工具應能完成一下功能：

支持多維和維中的層次；

沿單個維或沿一組所選維來聚集、概括、預計算和導出數據；

相對一個維或一組選中的維提供計算邏輯、公式和分析例程；

支持分析模型的概念：分析模型是一組選中的維及維的元素，計算邏輯，公式，分析例程、聚集數據，概況數據、導出數據等。

提供豐富的庫函數；

提供強大的計算和比較分析能力，例如：分級，比較，歸類百分比，極大值，極小值，平均值，按時期的比較等。

進行跨維計算，例如，在面向電子表格的應用程序中進行進行行級別的計算等；

提供時間相關的智能，例如：按日期劃分的年，跨域給定時間段的日歷，當前時期、財政的和內部的日歷等；

從一個維到另一個維進行轉換，它在合并或獲取數據后特別有用；

導航并分析，它采用沿單個或多個維的軸以及交叉表等來進行細剖和統攬的方法。

這些操作應滿足用戶分析是的要求，分析過程應是平滑的，連貫的。

--------------------------------------------------------------

數據倉庫工具箱-筆記

1.數據倉庫必須使組織機構的信息變得容易存取。

數據倉庫的內容必定使容易理解的，數據對于業務人員也必定使直觀的、明顯的，而

不能僅僅對開發人員來說是這樣。

容易理解意味著容易閱讀，而數據內容在標識方面應該是見名知義的。

數據倉庫存取工具必須簡單易用，并以最短的延遲時間將查詢結果返回給用戶。

2.數據倉庫必須一致地展示組織機構的信息。

數據倉庫中的數據必須是可信的。

它必須通過機構的各種渠道收集得到并精心組織起來，必須經過整理，具有質量保證并且

在量上滿足了用戶需求的情況下才進行發布。

3.數據倉庫必須具有廣泛的適應性和便于修改。

修改是不可回避的。

數據倉庫在設計上要能夠處理這種不可避免的變化。

4.數據倉庫必須發揮安全堡壘作用以保護信息資產。

5.數據倉庫必須在推進有效決策方面承擔最基本的角色。

數據倉庫必須維決策的定制提供正確的數據支持，數據倉庫有且僅有一個正確的輸出--由

數據倉庫提供的依據而制定的決策。

6.數據倉庫為業務群體所接受的前提是被認定是成功的。

維度模型是為數據倉庫用戶提交數據的最可行的技術手段。

維度建模相對以往那種著力構造簡單而可理解的數據庫的技術手段而言，是一個新名稱。

將業務設想成一個將分別標記為產品、市場與時間的數據立方體，顯得比較直觀。

能夠想象得出，沿各個維度方向對立方體進行切割所得到的結果：立方體中的點對應于一個產品、市場和時間組合的度量值。

建模時一種以消除數據冗余為追求目標的設計技術，在這里，數據被劃分成許多離散的實體，而每個實體形成關系數據庫中的一個表。

數據倉庫總線的基礎：所有數據中心必須采用共同的維度和事實來建造，即要求它們時一致的。

使用總線結構是構造分布式數據倉庫系統的秘訣。

數據倉庫可查詢展示環節的數據必須是維度的、原子的和依附數據倉庫總線結構的。

如果展示環節是建立在關系數據庫的基礎之上的，則這些按維度形式建立起來的表格被稱做星型圖。

如果建立在維度數據庫或者在線分析處理（OLAP,Online Analystic Processing）技術基礎之上，則數據就存儲在立方體中。

維度建模既可以用于關系數據庫，有可以用于維度數據庫。兩者在可辯別的維度方面具有共同的邏輯設計，但在物理實現方面是不同的。

元數據指的是數據倉庫環境中除去數據本身之外的所有信息，它是數據倉庫的百科全書的同義詞。

操作數據的存儲（ODS,Operational Data Store）

由于沒有ODS的統一定義，屬于那個部分與否由具體情況而定。

ODS經常需要更新，并在某種意義上講就是操作數據的復制集成，其更新頻率與集成程度隨特定要求而不同。無論如何，這里的“O”都可以看成是“操作”字眼的同義詞。

事實表

事實表是維度模型的基本表，其中存放由大量的業務性能度量值。

用術語“事實”代表一個業務度量值。

例子：

站在市場中觀察產品的銷售情況，并記錄下每個商店每種產品每天的的銷售數量和銷售額。在各維度值（日期，產品，商店）的交點處就可以得到一個度量值。

維度值的列表給出了事實表的粒度定義并確定出度量值的取值范圍是什么。

事實表的一行對應一個度量值，一個度量值就是事實表的一行。事實表的所有度量值必須有相同的粒度。

最有用的事實是諸如銷售額這樣的數字類型與可做加法的事實。

事實表中最有用的事實是數字類型與可加型事實。

將事實描述成是可連續取值的主要目的在于，作為一個指南幫助設計者區分出相對于維度屬性來說的事實的實質。

銷售額是連續取值的，在于它實際上可以取得一個很寬范圍內的任何值。

作為觀測人員，必須在得到確切的取值之前老老實實地站在市場上等待度量值。

度量事實在理論上將可以是文本形式的，不過這種情況很少見。

在大多數情況下，文本度量值可以是某種事物的描述并且取自某個離散列表的值。

設計者應該盡各種努力將文本度量值轉換成維度，原因在于維度你能夠與其它文本維度屬性更有效地關聯起來，并且消耗少得多的空間。不能將冗余的文本信息存放在事實表內。

除非文本對于事實表的每行來說都是惟一的，否則它應該歸屬到維度表中。

事實表傾向于具有更多的行和更少的列。

事實表粒度都歸屬于三類之一：事務，周期快照與累積快照。

所有事實表有兩個或者兩個以上的外關鍵字，外關鍵字用于連接到維度表的主關鍵字。

事實表要通過與之相連的維度表進行存取。

事實表本身通常也由外關鍵字子集組成的自己的主關鍵字，這個關鍵字通常稱作復合或者連接關鍵字。

維度模型中每個事實表都有一個符合關鍵字，反過來，具有一個復合關鍵字的表也是一個事實表。

在維度模型中每個表示多對多關系的表都事實表，而所有其他的表都是維度表。

在維度模型中，事實表表示維度間多對多的關系。

一個數據字段到底應該作為事實還是維度屬性看待：

通常可以這樣做出決定：

看字段是一個含有許多的取值并參與運算的度量值（當事實看待），還是

一個多少變化不多并參與作為約束條件的離散取值的描述（當維屬性看待）。

維度表時常描述業務中的層次關系。

維度表一般是很不規范化的，通常也非常小（少于所需數據存儲總容量的10%）。

事實與維度的融合

維度屬性提供了生成報表標簽的內容，而事實表則提供了報表的數字型取值。

展示環節的數據應該是維度形式的。

維度模型與規范化模型之間存在著一種自然的關系。單個規范化ER圖通常分解為多個維度方案。

-----------------------------------------------------------------------------

零售營銷

理解維度建模原理的最佳途徑，是通過一系列切實的例子去進行實踐。

四步維度設計過程

（1）選取要建模的業務處理過程。

業務處理過程是機構中進行的一般都由源數據收集系統提供支持的自然業務活動。

聽取用戶的意見是選取業務處理過程的效率最高的方式。

數據倉庫中進行分析的性能度量值是從業務評測處理過程得來的。

典型的業務處理過程包括原材料購買、定貨、運輸、開票、庫存與賬目管理等。

業務處理過程并不是指業務部門或者職能。

通過將注意力集中放在業務處理過程方面，而不是業務部門方面，就能在機構范圍內更加經濟地提交一致的數據。

（2）定一業務處理的粒度。 事實表實際代表的內容

粒度定義意味著對各事實表實際代表的內容給出明確的說明。

粒度傳遞了同事實表度量值相聯系的細節所達到的程度方面的信息。它給出了后面這個問題的答案：如何描述事實表的單個行？

典型的粒度定義包括：

顧客購物券上掃描設備一次拾取的分列項內容

醫生開出的單據項目內容

個人登機通行證內容

倉庫中每種產品庫存水平的日快照

每個銀行賬號的月快照

（3）選定用于每個事實表行的維度。

維度所引出的問題是，"業務人員將如何描述從業務處理過程得到的數據？"

應該用一組在每個度量上下文中取單一值而代表了所有可能情況的豐富描述，將事實表裝扮起來。如果對粒度方面的內容很清楚，那么維度的確定一般是非常容易的。通過維度的選定，可以列出那些使每個維度豐滿起來的離散的文本屬性。

常見維度了例子包括：日期、產品、顧客、事務類型和狀況等。

（4）確定用于形成每個事實表行的數字型事實。

事實的確定可以通過回答“要對什么內容進行測評”這個問題來進行。

業務用戶在這些業務處理性能度量值的分析方面具有濃厚的興趣。設計中所有供選取的信息必須滿足在第2步中定義的粒度要求。明顯屬于不同粒度的事實必須放在單獨的事實表中。典型的事實是諸如訂貨量或者支出額這樣的可加性數字數據。

千萬要克服只看看源數據文件就對數據進行建模的偏向。

業務需求

維度模型

1.業務處理

2.粒度

3.維度

4.事實 （數據實際）

首先對業務進行描述，以使建立的維度與事實表更容易理解。

在對業務實例研究進行描述之后，現在就可以開始維度建模的設計工作了。

第一步:選取業務處理

設計工作的第一步使，通過將對業務需求的理解與對可用數據的理解組合起來而確定

建模的業務處理內容。

建立的第一個維度模型應該是一個最有影響的模型--它應該對最緊迫的業務問題做出回答，并且對數據的抽取來說使容易訪問的。

第二部：定義粒度

一旦將業務處理確定下來，數據倉庫團隊下一個就面臨關于粒度確定的顏色課題。

應優先考慮為業務處理獲取最有原子性的信息而開發維度模型。原子型數據是所收集的最詳細的信息，這樣的數據不能再做更進一步的細分。

原子型數據是高度維結構化。事實度量值越細微并具有原子性，就越能夠確切地知道更多的事情，所有那些確切知道的事情都轉換為維度。在這點上，原子型數據可以說是維度方法的一個極佳匹配。

原子型數據可為分析方面提供最大限度的靈活性，因為它可以接受任何可能形式的約束，并可以以任何可能的形式出現。

維度模型的細節性數據是安如泰山的，并隨時準備接受業務用戶的特殊攻擊。

可以總是結合業務處理定義較高層面的粒度，這種粒度表示最具有原子性的數據的聚集。

不過，只要選取較高層面的粒度就意味著將自己限制到更少或者細節性可能更小的維度上了。具有較少粒度性的模型容易直接遭到深入到細節內容的不可預見的用戶請求的攻擊。如果不讓用戶存取原子型數據，則他將不可避免地在分析方面撞上南墻。

聚集概要性數據作為調整性能的一種手段起著非常重要的作用，但它絕對不能作為用戶存取最底層面的細節內容的替代品。

數據倉庫幾乎總是要求在每個維度可能得到的最低粒度上對數據進行表示的原因，并不是因為查詢想看到每個底層面的行，而是因為查詢希望以很精確的方式對細節知識進行抽取。

第三步：選定維度

一旦事實表的粒度被選定，則時期、產品與商店方面的維度就應該隨之被確定下來。

在基本維度框架范圍內，可能需要知道其他諸如針對某種產品的促銷這樣的維度是否可以分配數據。這個內容可表示為另外一個設計原則。

一個經過仔細考慮的粒度定義確定了事實表的基本維度特征。同時，經常也可能向事實表的基本粒度加入更多的維度，而這些附加的維度會在基本維度的每個組合值方面自然地取得惟一的值。

如果附加的維度因為導致生產另外的事實行而違背了這個基本的粒度定義，那么必須對粒度定義進行修改以適應這個維度的情形。

第四步：確定事實

設計過程的第四步同時也是最后一步，在于仔細確定哪些事實要在事實表中出現。粒度定義在這里再次成為考慮問題的支點。只是需要支出，事實對于粒度必須是真實的。

當考慮潛在的事實時，可能會再次發現，對早先的粒度設想或者維度選取做出調整是非常必要的。

單價也是非加型事實。試圖在任何維度范圍內對單價進行求和，都會導致出現一些毫無意義的甚至顯得荒謬的數值結果。

要針對一系列商店或者一個時間跨度分析某種產品的平均售價，就必須在用銷售總量取除銷售總額之前，將相關銷售額與銷售量加起來。雖然數據倉庫市場方面的報表生成器或者查詢工具都應該自動地正確完成這個功能，但是很遺憾，其中一部分工具仍舊布恩那個很圓滿地做到這一點。

在設計的早期階段，經常對可能需要的最大表即最大事實表的行數做出估計是很有益處的。

維度表屬性

用豐富的屬性將他們填充起來。

日期維度

日期維度是幾乎每個數據中心都必須提供的一個維度，因為實際上，每個數據中心都是時間系列的。事實上，日期通常是數據進行潛在分類排序的首選維度，這樣做的目的是，是按時間間隔連續加載的數據能夠順次放到磁盤上的空白存儲區中。

日期維度指稱按日期進行粒度定義的維度表。這有助于對時期維度和每天的時間維度進行區分。

與其它多數維度不一樣，日期維度表可以事先建立。這樣的表可存放以日期表示的5到10年的歷史數據行。

日期維度表的每列由行所代表的特定日期進行定義。

維度表屬性是做報表標記之用。

建議：

將日期關鍵字指定為整數類型而不是任何形式的日期數據。

一個基于SQL的日期關鍵字在典型情況下是8字節的，因而事實表各行的每個日期關鍵字要浪費4個字節。

數據倉庫總需要一個明確的維度表。有許多日期屬性不能由SQL函數提供支持，這包括財務盤點，時令，節假日與周末等。與企圖在查詢中給定這些非標準日歷運算的做法不同，而更應該在一個日期維度表中去檢索它們。

產品維度

產品維度描述每個產品信息。

產品維度幾乎總是起源于操作型產品主文件。

在數據中心進行的向下探查操作不過是通過維度表添加一些標題，而向上探查就是刪除行標題。可以通過來自多個顯式體系的屬性而進行向上或者向下探查操作，也可以按非體系部分的屬性進行同樣的操作。

產品維度是幾乎每個數據中心都擁有的兩到三個基本維度之一。

用盡可能多的描述屬性對這個維度進行填充時，應特別小心。一組豐富而完整的維度屬性會轉化為豐富而完整的用戶數據分析能力。

商場維度

商場維度描述雜貨連鎖店的每個商場。

在維度表中表示多個體系是不常見的。在理想情況下，屬性名與值在跨多個體系的范圍應該是惟一的。

必須避免在事實表中出現空關鍵字，在這方面顯得比較合適的設計是在對應的維度表中包括一行來標識該維度對度量值的不可用。

非事實型事實表

維度表幾乎總是比事實表的幾何尺寸要小。

為節省磁盤空間而投入精力去規范化產品維度表，只不過是在浪費時間。