2023年對數據倉庫進行數據建模

對數據倉庫進行數據建模-----IBM

2007-11-1615:00

OLTP與數據倉庫一有何差異？

在日常生活中，我們要使用大量的應用程序來生成新的數據、變更數據、刪除數

據，當然在大多數的情況下我們還要查閱和分析數據。就來想象一個收發(fā)email

的簡單應用程序吧。我們已經存儲了地址信息，可能還存儲了一些文檔。我們可

以決定是否存儲已經發(fā)送過的郵件，但是也可能隔一段時間后將其刪除，或者刪

除已經發(fā)送過的所有郵件。那么我們該如何處理一段時間以前刪除或者修改過的

地址呢？我們再也不會看到它們了。

Email程序大部分都屬于不是很復雜的數據庫，但是完全可以將其看作一個在單

用戶環(huán)境下的OLTP（在線事務處理系統）簡單示例。它使用了所有的所謂訪問

數據的操作CRUD（創(chuàng)建、讀取、更新、刪除）。當數據存儲達到一定量的時候,

規(guī)模就會幾乎保持不變，因為可以從存儲中刪除過期數據。

數據倉庫就完全是一種不同種類的應用程序。它并不是用來運行當前的操作，例

如發(fā)送郵件。它是用來分析數據并且從現有數據中發(fā)現新的價值，主要是用來預

測未來的情況。數據倉庫并不是解決所有問題的通用結構。它必須集中于某一問

題領域，例如航空服務、顧客收益等。

數據倉庫也有有趣的一面，那就是數據庫本身是穩(wěn)定增長的。數據沒有被刪除，

也不發(fā)生變更。我們不需要將冗余數據置于數據庫之外（因為加入倉庫中的數據

經過了數據凈化的過程，該過程檢查了數據的正確性）來減少復雜性同時增強讀

取操作的性能。

為了能夠對數據倉庫中的數據進行分析，數據存儲于一個多維結構中，叫做星型

模式。如果將星型模式擴展，就會得到雪花模式。本白皮書將會闡述如何使用

IBMRationalRose進行星型模式建模和雪花模式建模。

飛行服務數據集市的例子

為了更好地解釋如何對數據倉庫建模，本白皮書將使用一個簡單數據集市的的例

子（即一個數據倉庫或者數據倉庫的一部分），來分析旅客乘坐航班Happy

FlyingandLanding（愉快飛行平安降落）的行為和滿意程度。

我們將存儲乘客信息和每個航班的的相關數據、選擇的菜單以及乘客對飛行的滿

意程度。

數據倉庫術語表

數據倉庫引入了新的術語，擴展了數據建模的術語表。為使本文的闡述能夠完備,

下面我介紹一下最常用的術語。

數據倉庫

數據倉庫是一個支持管理決策的數據集合。數據是面向主題的、集成的、不易丟

失的并且是時間變量。

數據倉庫是所有操作環(huán)境和外部數據源的快照集合。它并不需要非常精確，因為

它必須在特定的時間基礎上從操作環(huán)境中提取出來。

數據集市

數據倉庫只限于單個主題的區(qū)域，例如顧客、部門、地點等。數據集市在從數據

倉庫獲取數據時可以依賴于數據倉庫，或者當它們從操作系統中獲取數據時就不

依賴于數據倉庫。

事實

事實是數據倉庫中的信息單元，也是多維空間中的一個單元,受分析單元的限制。

事實存儲于一張表中（當使用關系數據庫時）或者是多維數據庫中的一個單元。

每個事實包括關于事實（收入、價值、滿意記錄等）的基本信息，并且與維度相

關。

在某些情況下，當所有的必要信息都存儲于維度中時，單純的事實出現就是對于

數據倉庫足夠的信息。我們稍后討論有關缺無事實的情況。

維度

維度是綁定由坐標系定義的空間的坐標系的軸線。數據倉庫中的坐標系定義了數

據單元，其中包含事實。

坐標系的一個例子就是帶有X維度和y維度的Cartesian（笛卡爾）坐標系。

在數據倉庫中，時間總是維度之一。

數據挖掘

在數據倉庫的數據中發(fā)現新信息的過程被稱為數據挖掘，這些新信息不會從操作

系統中獲得。

分析空間

分析空間是數據倉庫中一定量的數據，用于進行數據挖掘以發(fā)現新信息同時支持

管理決策。

切片

一種用來在數據倉庫中將一個維度中的分析空間限制為數據子集的技術。

切塊

一種用來在數據倉庫中將多個維度中的分析空間限制為數據子集的技術。

星型模式

一種使用關系數據庫實現多維分析空間的模式，稱為星型模式。

星型模式將在本白皮書中稍后進行進一步討論。

雪花模式

不管什么原因，當星型模式的維度需要進行規(guī)范化時，星型模式就演進為雪花模

式。

使用IBMRationalRose進行星型模式建模

星型模式的基本形式必須實現多維空間（常常被稱為方塊），以使用關系數據庫

的基本功能。

首先，我們需要理解多維空間。

多維分析空間

幾何學中的方塊是指一個三維空間，其中每個維度的尺寸都相同。想象一個立方

體，每個維度都有三個單元，我們即得到相同結構的33=27個單元。

圖1一個具有x、v、z維度的方塊

1

多維分析空間（或者數據倉庫方塊）與幾何空間中的方塊僅僅存在細節(jié)上的差異。

?維度不僅限于3維。不過，處理很多維度的立方體也不是件輕松的事情，

這會導致大多數的實現被限制于6或者7維。不要期盼使用圖形可以很

好地表示超過4的維度一如果您有幸能發(fā)現一種方法，別忘了告訴我一

下。

?維度并不具有相同的規(guī)模和單元。規(guī)模從幾個單元到幾百萬個單元，差別

巨大。單元可以是一天、一位顧客、部門等。

?單元，相當于子方塊（1X1X1等），包含事實。

圖2一個三維數據立方體

數據立方體需要很大的內存以存儲所有事實。無論是否包含事實，都必須要預留

單元。

這就是為什么使用關系數據庫和星型模式的原因。使用它們能夠優(yōu)化存儲并且保

持數據結構的靈活性。

星型模式

星型模式的基本思想就是保持立方體的多維功能，同時也增加了小規(guī)模數據存儲

的靈活性。

圖3一個星型模式

在圖3中，星型模式使用事實Flight表示了一個4維方塊（Passenger、Menu、

FlightSchedulet和Time）?；旧?，事實必須指定一個維度，以將其放入立

方體的單元中。

我們的例子中的維度是：

?Passenger,描述了飛行航程中的每位乘客，由經常飛行號（frequent

flyernumber）指定。不是經常乘坐飛機的乘客不是數據倉庫的一部分。

?FlightSchedule,是指所有常規(guī)飛行的日程。

?Menu,是用于飛行的菜單。只有對菜單進行基本的分類才會對數據挖掘有

重要意義。

?Time,是指飛行的時間。

事實Flight描述了乘客在唯一的Time的單程飛行上選擇Menu0

分析空間可以是完整的方塊，或者我們可以根據維度將分析空間分割成小片。

每個維度根據一個對象進行描述，對象可以用類表示，這些類就是有關業(yè)務主題

的名稱。這一點對于成功建立數據倉庫來說是很重要的，因為倉庫的用戶（經理、

分析員、市場）對于信息技術的術語并不是很熟悉。

事實本身就是商業(yè)智能的另一個對象，仍然通過類進行表示。

事實指每個維度。事實與維度的關聯常常是一對任意，這也就意味著每個事實都

與單個維度的一個單元準確對應，而維度的每個單元（每個Passenger、Time

等）可以與任意數量的事實發(fā)生關聯（包括0個事實）。

使用RationalRose將對象模型轉換為數據模型即完成了星型模式的實現。這

里我們可以看到轉換后的結果。

圖4使用RationalRose實現星型模式

在圖4中，沒有顯示自動創(chuàng)建的主鍵和外鍵約束。

星型模式的維度是獨立的表。當對象模型轉換為數據模型時，RationalRose可

以生成維度的主鍵。

事實表指從維度表中使用鍵遷移的維度，當生成數據模型時RationalRose可

以生成外鍵。

在星型模式中切片和切塊是對維度的限制（選擇）。這是一個運行時問題，而不

是建模問題，但是模型必須分辨其需要。

雪花模式

基本的星型模式并不能滿足數據挖掘的所有需要。我們需要更復雜的維度，例如

時間。分析員希望根據周、月、季度等識別模式。

維度必須進行規(guī)范化。我們不需要冗余的維度表，這只會使數據切片變得更加復

雜。這種過程中我們得到的模式被稱為雪花模式。

我們來看一個簡單的雪花模式例子。我們將時間維度規(guī)范化為周、月和季度。

圖5規(guī)范化的Time維度

我們希望能夠使用附加的規(guī)范化維度將立方體切片：周、月和季度。在本例中，

我們假定季度是月的平行層次，這也就意味著我們不能將季度假定為若干月的聚

合。由于這個原因，我們將使用一張范化表（是對OLAP查詢的一項簡單附加）

預先選擇時間維度。

最終雪花模式添加了規(guī)范化維度o

圖6帶有范化維度的Time和事實Flight的雪花模式

當然，所有的維度都可以像時間例子那樣進行規(guī)范化，這就導致了比較復雜的數

據集市模式的出現。

由RationalRose從雪花模式中開發(fā)的實現模式（數據模型）是完善的。

圖7帶有范化Time維度的雪花模式的數據模型

創(chuàng)建的約束在圖中也沒有顯示。

雪花模式中可以存在切片，不僅僅在基本的Time維度上，也可以在規(guī)范化的

Week>Month和Quarter維度上。

多對多關系

在一次飛行中，我們不僅僅只吃一頓飯。在長途飛行中可能要多次用餐。在這種

情況下，我們認為事實Flight和Menu維度不是一對多的關聯。我們必須使用

多對多關聯。不過，這種關聯不可能在星型模式中實現。

雪花模式的一種特殊形式是使用一種必要的數據結構以滿足這項要求。

首先，我們將模型變更為事實和維度間的多對多關聯。使用RationalRose,這

只是關聯基數的變更。

圖8Menu的多對多維度的星型模式

我們無法在關系數據庫中實現多對多關聯。實現多對多關聯需要使用另一種雪花

模式。

在下圖中，我們關注一下已經開發(fā)的雪花模式的一部分，該部分處理多對多維度。

圖9雪花模式解決了Menu的多維度

RationalRose生成了附加的維度表FlightMenu,它是指Menu維度和Flight

事實。

確定關系用于解決多對多關聯。

對于雪花模式的架構師來說，最重要的一點就是識別多對多關系。簡單對象視圖

可能會使設計員理解概念，而生成的數據視圖有助于進一步深入有關實現的問

題。

層次

數據挖掘可以從隱藏在操作系統表面下的數據中發(fā)現信息。我們想了解的一個問

題就是選定菜單與乘客統計資料之間的依賴關系。

乘客統計資料數據可以在Passenger維度的層次上構建。乘客可以根據郵政編

碼分組，然后再按國家進行分組。

圖10乘客的層次

層次通過使用聚合來指定。聚合定義了所包括的內容。Country包含了ZIP編

碼，ZIP編碼包含了多名Passenger信息。

最終通過使用外鍵實現了聚合。

圖11雪花模式實現了Passenger維度的聚合

生成的約束仍然沒有在圖中表示出來。

使用聚合，維度可以在任何定義的級別上使用。分析空間可以通過Passenger.

ZIPCode或者Country進行切片。

一致的維度

隨著數據倉庫架構師不斷地添加細節(jié)內容，雪花模式變得越來越復雜。因此設計

過程必須在到達某種程度后停止以保持數據倉庫運行良好。

星型或者雪花模式仍然僅僅關注于一個事實一在本例中就是Flight.,那么復雜

關系又是什么情況呢？

對于每個事實我們都必須設計其各自的模式。如果我們想要進行復雜查詢的話，

它們就必須具有共同的維度一我們稱其為一致的維度。

讓我們使用Pilot作為一個維度，PilotFlight作為一個事實來定義第二個星

型模式。我們還要使用附加的FlightSchedule維度和Time維度。

圖12Pilot星型模式

第二個模式可以單獨使用或者與Passenger模式結合使用，從而根據使用一致

維度的飛行員維度來查詢Passenger的滿意程度。

圖13一致維度Time和FlightSchedule

即使在使用一致維度的數據倉庫的簡單結構中，Pilot與