聲明：本文轉載至Davor Gornik

對數據倉庫進行數據建模

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

在日常生活中，我們要使用大量的應用程序來生成新的數據、變更數據、刪除數據，當然在大多數的情況下我們還要查閱和分析數據。就來想象一個收發 email 的簡單應用程序吧。我們已經存儲了地址信息，可能還存儲了一些文檔。我們可以決定是否存儲已經發送過的郵件，但是也可能隔一段時間后將其刪除，或者刪除已經發送過的所有郵件。那么我們該如何處理一段時間以前刪除或者修改過的地址呢？我們再也不會看到它們了。

Email 程序大部分都屬于不是很復雜的數據庫，但是完全可以將其看作一個在單用戶環境下的 OLTP（在線事務處理系統）簡單示例。它使用了所有的所謂訪問數據的操作 CRUD（創建、讀取、更新、刪除）。當數據存儲達到一定量的時候，規模就會幾乎保持不變，因為可以從存儲中刪除過期數據。

數據倉庫就完全是一種不同種類的應用程序。它并不是用來運行當前的操作，例如發送郵件。它是用來分析數據并且從現有數據中發現新的價值，主要是用來預測未來的情況。數據倉庫并不是解決所有問題的通用結構。它必須集中于某一問題領域，例如航空服務、顧客收益等。

數據倉庫也有有趣的一面，那就是數據庫本身是穩定增長的。數據沒有被刪除，也不發生變更。我們不需要將冗余數據置于數據庫之外（因為加入倉庫中的數據經過了數據凈化的過程，該過程檢查了數據的正確性）來減少復雜性同時增強讀取操作的性能。

為了能夠對數據倉庫中的數據進行分析，數據存儲于一個多維結構中，叫做星型模式。如果將星型模式擴展，就會得到雪花模式。本白皮書將會闡述如何使用IBM Rational Rose進行星型模式建模和雪花模式建模。

飛行服務數據集市的例子

為了更好地解釋如何對數據倉庫建模，本白皮書將使用一個簡單數據集市的的例子（即一個數據倉庫或者數據倉庫的一部分），來分析旅客乘坐航班 Happy Flying and Landing(愉快飛行平安降落)的行為和滿意程度。

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

?

數據倉庫術語表

數據倉庫引入了新的術語，擴展了數據建模的術語表。為使本文的闡述能夠完備，下面我介紹一下最常用的術語。

數據倉庫

數據倉庫是一個支持管理決策的數據集合。數據是面向主題的、集成的、不易丟失的并且是時間變量。

數據倉庫是所有操作環境和外部數據源的快照集合。它并不需要非常精確，因為它必須在特定的時間基礎上從操作環境中提取出來。

數據集市

數據倉庫只限于單個主題的區域，例如顧客、部門、地點等。數據集市在從數據倉庫獲取數據時可以依賴于數據倉庫，或者當它們從操作系統中獲取數據時就不依賴于數據倉庫。

事實

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

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

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

在某些情況下，當所有的必要信息都存儲于維度中時，單純的事實出現就是對于數據倉庫足夠的信息。我們稍后討論有關缺無事實的情況。

維度

維度是綁定由坐標系定義的空間的坐標系的軸線。數據倉庫中的坐標系定義了數據單元，其中包含事實。

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

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

數據挖掘

在數據倉庫的數據中發現新信息的過程被稱為數據挖掘，這些新信息不會從操作系統中獲得。

分析空間

分析空間是數據倉庫中一定量的數據，用于進行數據挖掘以發現新信息同時支持管理決策。

切片

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

切塊

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

星型模式

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

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

雪花模式

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

?

使用 IBM Rational Rose 進行星型模式建模

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

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

多維分析空間

幾何學中的方塊是指一個三維空間，其中每個維度的尺寸都相同。想象一個立方體，每個維度都有三個單元，我們即得到相同結構的33＝27個單元。

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

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

• 維度不僅限于 3 維。不過，處理很多維度的立方體也不是件輕松的事情，這會導致大多數的實現被限制于 6 或者 7 維。不要期盼使用圖形可以很好地表示超過 4 的維度--如果您有幸能發現一種方法，別忘了告訴我一下。
• 維度并不具有相同的規模和單元。規模從幾個單元到幾百萬個單元，差別巨大。單元可以是一天、一位顧客、部門等。
• 單元，相當于子方塊（1×1×1等），包含事實。

圖2 一個三維數據立方體

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

這就是為什么使用關系數據庫和星型模式的原因。使用它們能夠優化存儲并且保持數據結構的靈活性。

星型模式

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

圖3 一個星型模式

在圖3中，星型模式使用事實 Flight 表示了一個 4 維方塊（Passenger、Menu、Flight Schedulet 和 Time）。基本上，事實必須指定一個維度，以將其放入立方體的單元中。

我們的例子中的維度是：

• Passenger，描述了飛行航程中的每位乘客，由經常飛行號（frequent flyer number）指定。不是經常乘坐飛機的乘客不是數據倉庫的一部分。
• Flight Schedule，是指所有常規飛行的日程。
• Menu，是用于飛行的菜單。只有對菜單進行基本的分類才會對數據挖掘有重要意義。
• Time，是指飛行的時間。

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

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

每個維度根據一個對象進行描述，對象可以用類表示，這些類就是有關業務主題的名稱。這一點對于成功建立數據倉庫來說是很重要的，因為倉庫的用戶（經理、分析員、市場）對于信息技術的術語并不是很熟悉。

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

事實指每個維度。事實與維度的關聯常常是一對任意，這也就意味著每個事實都與單個維度的一個單元準確對應，而維度的每個單元（每個Passenger、Time等）可以與任意數量的事實發生關聯（包括0個事實）。

使用 Rational Rose 將對象模型轉換為數據模型即完成了星型模式的實現。這里我們可以看到轉換后的結果。

圖4 使用Rational Rose實現星型模式

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

星型模式的維度是獨立的表。當對象模型轉換為數據模型時，Rational Rose 可以生成維度的主鍵。

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

在星型模式中切片和切塊是對維度的限制（選擇）。這是一個運行時問題，而不是建模問題，但是模型必須分辨其需要。

雪花模式

基本的星型模式并不能滿足數據挖掘的所有需要。我們需要更復雜的維度，例如時間。分析員希望根據周、月、季度等識別模式。

維度必須進行規范化。我們不需要冗余的維度表，這只會使數據切片變得更加復雜。這種過程中我們得到的模式被稱為雪花模式。

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

圖5 規范化的 Time 維度

我們希望能夠使用附加的規范化維度將立方體切片：周、月和季度。在本例中，我們假定季度是月的平行層次，這也就意味著我們不能將季度假定為若干月的聚合。由于這個原因，我們將使用一張范化表（是對 OLAP 查詢的一項簡單附加）預先選擇時間維度。

最終雪花模式添加了規范化維度。

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

當然，所有的維度都可以像時間例子那樣進行規范化，這就導致了比較復雜的數據集市模式的出現。

由 Rational Rose 從雪花模式中開發的實現模式（數據模型）是完善的。

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

創建的約束在圖中也沒有顯示。

雪花模式中可以存在切片，不僅僅在基本的 Time 維度上，也可以在規范化的 Week、Month 和 Quarter 維度上。

多對多關系

在一次飛行中，我們不僅僅只吃一頓飯。在長途飛行中可能要多次用餐。在這種情況下，我們認為事實 Flight 和 Menu 維度不是一對多的關聯。我們必須使用多對多關聯。不過，這種關聯不可能在星型模式中實現。

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

首先，我們將模型變更為事實和維度間的多對多關聯。使用 Rational Rose，這只是關聯基數的變更。

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

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

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

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

Rational Rose 生成了附加的維度表 FlightMenu，它是指 Menu 維度和 Flight 事實。

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

對于雪花模式的架構師來說，最重要的一點就是識別多對多關系。簡單對象視圖可能會使設計員理解概念，而生成的數據視圖有助于進一步深入有關實現的問題。

層次

數據挖掘可以從隱藏在操作系統表面下的數據中發現信息。我們想了解的一個問題就是選定菜單與乘客統計資料之間的依賴關系。

乘客統計資料數據可以在 Passenger 維度的層次上構建。乘客可以根據郵政編碼分組，然后再按國家進行分組。

圖10 乘客的層次

層次通過使用聚合來指定。聚合定義了所包括的內容。Country 包含了 ZIP 編碼，ZIP 編碼包含了多名 Passenger 信息。

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

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

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

使用聚合，維度可以在任何定義的級別上使用。分析空間可以通過 Passenger、ZIP Code或者 Country 進行切片。

一致的維度

隨著數據倉庫架構師不斷地添加細節內容，雪花模式變得越來越復雜。因此設計過程必須在到達某種程度后停止以保持數據倉庫運行良好。

星型或者雪花模式仍然僅僅關注于一個事實--在本例中就是Flight。那么復雜關系又是什么情況呢？

對于每個事實我們都必須設計其各自的模式。如果我們想要進行復雜查詢的話，它們就必須具有共同的維度--我們稱其為一致的維度。

讓我們使用 Pilot 作為一個維度，PilotFlight 作為一個事實來定義第二個星型模式。我們還要使用附加的 Flight Schedule 維度和 Time 維度。

圖12 Pilot 星型模式

第二個模式可以單獨使用或者與 Passenger 模式結合使用，從而根據使用一致維度的飛行員維度來查詢 Passenger 的滿意程度。

圖13 一致維度Time 和 Flight Schedule

即使在使用一致維度的數據倉庫的簡單結構中，Pilot 與 Passenger 之間的關系也是簡單的。

在開發數據模型時，數據倉庫將大量小型星型模式與雪花模式相結合形成了大型的數據倉庫模式。

事實與維度的數據

我們想要評估乘客對于飛行的滿意率。可以使用不滿意到很滿意幾個級別進行評定。評定記錄存放在事實表 Flight 中作為一個屬性（列）。

如果我們想要得出一個平均記錄，那么就必須為記錄定義值以進行計算。我們可以將記錄分為 0 到 10 級。這樣就可以得到一個平均記錄。平均值應該存儲在維度表中，以用于簡單的切片，其中我們只想進行一維切片。

轉載于:https://www.cnblogs.com/i-blog/p/4025699.html

總結

以上是生活随笔為你收集整理的数据仓库/集市 星形/雪花形 事实/维度表的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。