基於物件導向（OO）的資料庫設計模式探討，第 2 部分

xjg95發表於2012-01-06
物件資料庫設計模式
簡介： 現在大型的管理系統有幾千甚至上萬張表，但幾乎沒有誰能搞清楚所有的資料結構，如何建立清晰明瞭的資料結構？如何讓其他人對資料結構更加容易理解，本文以 “基於物件導向（OO）的資料庫設計模式探討”為基礎進一步對彙總表進行分析，透過建立指標矩陣模型，“模式”化資料庫建模，建立清晰可讀的彙總資料模型。

本文的標籤： oo, 體系架構, 關於產品, 建模, 資料庫, 管理, 設計, 設計模式, 物件導向

標記本文！

釋出日期： 2011 年 6 月 07 日
級別： 初級
訪問情況 ： 1655 次瀏覽
評論： 0 (檢視 | 新增評論 - 登入)
平均分 0 星 共 0 個評分 平均分 (0個評分)
為本文評分

免費下載：IBM® InfoSphere Data Architect V7.5.2 試用版
下載更多的 IBM 軟體試用版，並加入 IBM 軟體下載與技術交流群組，參與線上交流。

前言

軟體開發中面臨的問題

在軟體開發過程中，幾乎沒有幾個程式設計師喜歡報表開發，報表多、雜，需求多變，特別是給人感覺沒有什麼技術含量，大家對報表都是退避三舍。如果採用 BI 工具開發，又會因為 BI 工具五花八門，不同專案 BI 工具不同，需要開發不同的程式，增加了專案開發成本，除非是固定一種報表工具，但是不同的客戶需求不同，不得已需要不停的變化展現工具；不用 BI 工具，自己開發應用，如果採用多維資料庫，則需要程式設計師熟悉多維資料庫的 SQL 語法，增加了開發的難度；基於關係型資料，採用通用的查詢工具又往往面臨著查詢效能問題，報表的開發似乎成了一個死結。重複勞動、產品通用性差、查詢效能差等問題是當前所面臨的一個重要的課題，特別是對於大型的管理系統，多變的查詢需求和海量資料處理，往往成為專案遲遲不能驗收的一個最重要因素。

本文參照資料倉儲建模的思路，解決查詢效能問題，採用關係型資料結構，使用和業務系統通用的 Java 開發，給出了一個建立簡單清晰的資料模型的方法。

資料倉儲的建模思路

在資料倉儲建模中經常會採用空間換效能的方法，需要彙總的資料不是臨時彙總而是提前彙總好，比如銷量指標，其年累計、同期、上期、計劃、實際、增長比例等提前彙總計算好，提高查詢速度，在此簡單介紹幾個基本的資料倉儲概念：

星型模式：（也稱為星形連線的模式，資料立方體，或多維模式 ）是最簡單的樣式資料倉儲架構 。星型模式由一個或多個事實表中引用任何數量的維表

維表：維度表可以看作是使用者來分析資料的視窗，維度表中包含事實資料表中事實記錄的特性，有些特性提供描述性資訊，有些特性指定如何彙總事實資料表資料，以便為分析者提供有用的資訊，維度表包含幫助彙總資料的特性的層次結構。

事實表：事實資料表可能包含業務銷售資料，如銷售所產生的資料，事實資料表通常包含大量的行。事實資料表的主要特點是包含數字資料（事實），並且這些數字資訊可以彙總，以提供有關單位作為歷史的資料，每個事實資料表包含一個由多個部分組成的索引，該索引包含作為外來鍵的相關性維度表的主鍵，而維度表包含事實記錄的特性，在本文中稱為彙總表。

本文采用的示例資料模型

為了更好的理解本專案的思路，以下以客戶關係管理資料模型為例，按照物件關係模型建模，主要的業務物件包含供應商、商品；客戶、客戶經理、客戶業態；銷售訂單、採購訂單等基本業務物件，主要的彙總表包含客戶商品日帳（即客戶每天每個商品的銷售彙總）等，如下圖所示：

圖 1. 資料物件模型示例（檢視大圖）
圖 1. 資料物件模型示例

另外在本文中提到幾個指標：銷量，是在一段時間內客戶購買的數量；上櫃率，是指一個月內購買某一個商品的客戶數佔所有有效客戶數的比率。即上櫃率 = 本月購買本商品的客戶數 / 有效客戶總數。

回頁首

指標矩陣模型

根據當前所面臨的問題，參考資料倉儲建模理念，從以分析指標入手，建立指標模型，然後根據彙總維度建立維度矩陣模型，最終結合指標模型和緯度矩陣模型建立指標矩陣模型。

指標模型

在考慮建立那些彙總表之前，首先確定那些指標是原始指標，即已經存在的指標，不再需要進行逐級彙總，可以直接使用的指標，這些指標屬於原始指標，可以直接作為彙總表的原始資料。然後把不能彙總的指標儘量分解為可以彙總或者可以計數的指標，以便於進行資料彙總和查詢（這一點對於簡化模型很重要，可以把大部分指標分解為可以進行彙總計算的指標）。整理好所有的指標之後，透過指標進行分類，建立元指標和擴充套件指標，最終建立指標樹模型：

1. 原始指標，從其他系統獲取或者採集的原始資料，為原始指標，原始指標是其他指標彙總指標的基礎。

有些指標是不可以彙總，但是也無法分解，因為每個級別之間不是彙總關係，一般是單獨設定的。比如計劃，並不是逐級彙總上去的。因此每一級的指標都是原始指標。有些指標是從外部引入的，因此並不一定從最基礎的地方開始彙總，比如系統外的資料，GPD、人口指標，可能直接從一個某一個級別開始統計，更細節的資料沒有或者沒有必要。因此原始指標並不一定就是從最細粒度開始彙總的。

以上兩種情況，需要把指標設定為原始指標，即從從其他系統獲取或者採集的指標。

2. 計算指標，將不可以彙總、計數的指標分解到可以彙總的指標，比如上櫃率，可以分解為客戶總數和購買本商品的客戶數，在最細粒度資料客戶方面可以分解為是否上櫃（可以計數），比如毛利率可以分解為毛利和金額。這一點很重要，只有進行類分解之後，後續的彙總和查詢才可以大大簡化。被分解的指標稱之為計算指標。

3. 元指標：首先根據業務報表需要，對所有的指標進行分類，找出元指標，元指標是不含有任何維度資訊的，比如銷量、金額、毛利、上櫃率等。一個企業可能有上百個指標，為了便於管理，可以對指標進行分類管理，如銷售類、財務類、人力資源類等。

4. 擴充套件指標，元指標是基本的指標，但實際應用中，根據指標在不同的時間維度、或者某種演算法，可以“模式化”很多擴充套件的指標，如：

a) 年累計、年實際···

b) 月實際、同期、上期、同期增長、環比增長、月累計···

擴充套件指標是某元指標的一個“模式化”擴充套件，適用於所有相關的指標。比如銷量，可以有年累計銷量、年計劃銷量、年實際銷量、月實際銷量、同期銷量、上期銷量、銷量同期增長、銷量環比增長、月累計銷量等。這種模式化，透過分析會發現基本上可以適應到大部分指標（如金額、毛利），透過擴充套件指標，可以建立一個矩陣，大大簡化指標體系的複雜度。

表 1. 基於時間維度的彙總表
序號 指標 年累計 同期 同比 上期 環比 ···
1 銷量 有 有 有 有 有
2 金額 有 有 有 有 有
3 毛利 有 有 有 有 有
4 毛利率 無 有 有 有 有
···

維度矩陣模型

5. 基礎維度表，基於物件關係模型（詳見 “基於物件導向（OO）的資料庫設計模式探討”），建立基礎維度，以及基於基礎維度的原始事實表。基礎維度包含日期（日）、資料擁有者（所有者，客戶、人員、部門）、商品等（如圖 1 所示）。其中日期維度是必須的，因為彙總表都是基於日期維度進行彙總的，沒有日期的表是基礎維度表。所有者也是是必須的，因為每個資料一定是某一個所有者所擁有。除此之外的維度是可選的，比如商品，可以有不含商品維度的客戶月彙總表，包含商品維度的客戶商品月彙總表兩個。

根據星型模式建模理論，基礎維度應該可以獲取所有相關資訊，不需要在關聯其他的維度，如客戶維度表，裡面應該有客戶經理、銷售部門、客戶類別等所有相關的資訊，便於提高查詢效率。

注意，要把日期看成一種普通的維度，如月份，實際上也是一種“分類”，如 201001，代表 2010年 1月，但是還可以直接用 01代表一月，這樣後期報表處理就會簡化。

6. 原始事實表，對應著物件關係模型中的流水實體物件，流水實體物件按照時間進行彙總之後的為事實表，如：客戶商品日表；供應商商品日表，倉庫商品日表、考慮到行政區劃資訊比較穩定，如 GDP 等，直接按照年表建立，即行政區劃年表，作為最原始事實表，當然根據需要，也可以建月表。

理論上，所有的原始事實表建立之後，所有的彙總資料都可以直接查詢出來了，但是考到效能問題，透過空間換時間的方式，按照維度的不同方向進行彙總。

7. 維度矩陣模型，基於原始事實表，根據基礎維度，在基礎維度的不同彙總方向上建立維度彙總關係模型，如客戶商品日表的彙總模型可以在不同維度方向上進行彙總，

首先是在日期維度

a) 日 - 月 - 年

b) 日 - 月 - 季度 - 年

c) 日 - 周 - 年

如下圖所示，可以分別建立不同的彙總表，其中常見的是日、月、年等。

圖 2. 基於時間維度的彙總表（檢視大圖）
圖 2. 基於時間維度的彙總表

在客戶維度：

d) 客戶 - 客戶經理 - 部門經理 - 公司

e) 客戶 - 客戶業態

如下圖所示，通常按照組織機構建立彙總表。

圖 3. 基於時間、客戶維度的彙總表（檢視大圖）
圖 3. 基於時間、客戶維度的彙總表

在產品維度

f) 商品 - 品牌 - 供應商 - 省份

g) 商品 - 品類

h) 商品 - 大類

圖 4. 基於時間、客戶、商品維度的彙總表（檢視大圖）
圖 4. 基於時間、客戶、商品維度的彙總表

維度矩陣模型，實際上是維表在不同的可以彙總的方向上的笛卡爾乘積，其中有些是不需要的，如上圖所示，根據這個模型，可以列出所有需要的彙總表。

維表的建設，可以參考當前比較成熟的建模方法，比如經常見到的資料高階建模，一般分為參與者、地點、產品、交易等，本文不再詳述。

指標矩陣模型

8. 指標矩陣模型，分析每一個元指標及擴充套件指標在維度矩陣模型中是否存在，並根據指標進一步完善維度矩陣模型。有些指標並不是在所有的彙總表中存在的，比如上櫃率是月度指標，所以在所有的年表、日表中是不存在的；比如日表中不需要同期、上期，但是年累計、月累計等指標可能是需要的。

同維度矩陣模型一樣，指標矩陣模型是在維度矩陣基礎上的笛卡爾積的笛卡爾積矩陣，資料是很龐大的（這也是為什麼建立這個模型的原因，透過這個模型，可以建立更加容易理解的資料模型），但是並不是每一個指標在不同的矩陣中都是存在的，需要根據這個模型來分析哪些指標是存在的，哪些指標是不存在的。

在最終確定的模型中，有些資料表可能因為資料量很小，不存在效能問題，但是考慮到統一風格，統一處理方便性，全部按照一個思路，即一個“模式”，這樣程式開發就會簡單。

9. 對於指標靈活多變的，建立基於指標的彙總表，將每個指標的值存放在列上，指標可以靈活增加。詳見物件關係模型中不定屬性物件的描述。

透過以上方式，即可建立一個彙總表模型，但是在實際建模過程中會出現一些特殊情況，如過於個性化的指標，不好計算，則作為原始指標來看待，單獨進行彙總處理。有些指標因為維度值的變化不同，比如客戶經理因為人員的更換以及客戶所屬客戶經理更換，同期銷量，實際上可以有兩個值，一個是所管理的當前客戶的同期，一個是本人同期管理的客戶的實際值，因此需要根據需要，看看取哪一個指標。

根據“模式化”的思路，可以進一步把指標矩陣模型進一步進行擴充套件，有彙總資料，一般會對應著有一個計劃資料，結合以上思路，可以進一步建立一個計劃、彙總模型的“模式化”框架，本文不再詳述。

回頁首

模型在實際環境中的應用

為了更好的讓指標矩陣模型發揮作用，以下分別從儲存設計、效能角度及實際開發過程中的應用功能來看本模型的應用。

模型表結構設計

根據查詢頻次，在不同的維度方向上確定是否需要建立彙總表進行物理儲存，對於不經常用的資料，可以採用實時彙總的方式，實時彙總基於最近的維度彙總表進行彙總的方式，比如查詢客戶商品季度彙總，可以直接客戶商品月彙總表中彙總資料；查詢公司客戶業態月彙總資料直接從公司客戶商品月彙總表中獲取資料。

在資料查詢的時候建議透過檢視獲取資料，一方面可以解決計算指標的問題，透過檢視，把計算指標直接封裝，二是可以透過檢視實現部分物理儲存，如客戶業態商品彙總表，可以透過檢視的方式進行彙總，而實際上並沒有進行物理儲存，適應於不是很常用的一些彙總、資料量比較少的彙總表，這些彙總可以透過設定查詢一次存在快取中的方式，進一步最佳化。

如果欄位比較多，可以按照業務主題，分成多個表，在查詢的時候透過多個表分別獲取資料。按照以上模型建立的彙總表，同樣級別的資料可能會存放在不同的表中，比如客戶的銷量資訊和客戶的上櫃率可能是存放在不同的表中，如果在一個報表中同時查詢這兩個資訊，就需要同時查詢兩個表，可能會存在效能問題，解決這個的辦法是在查詢的時候需要考慮如何最佳化查詢效能，比如在考慮從多個彙總表表獲取資料，然後合併為一個，可以先建立幾個臨時表，分別把需要的資料從各個地方獲取存放在臨時表中，然後在從臨時表中獲取資料，同時寫入到一個表中，而不是先寫一列，然後在修改，這樣效能會比較差。

是否建立彙總表，可以透過在這個維度上是否有大量的減少， 比如客戶經理對客戶來說，一下子就減少了 200 倍的資料，所以彙總時值得的。如果是 10 倍，可以不彙總，這需要根據實際資料來分析。10000 萬的資料和 1000 萬，效能還是會差別很大的。

模型查詢效能最佳化

透過前文所提到的表結構方面的最佳化，從查詢效能角度來看，本模型主要從幾個層面，採用空間換時間的思路，進行了最佳化：

基於星型模式的最佳化：建立簡單星型模式，設定了維表，透過維表的冗餘存放，減少的維表之間的關聯，取消了雪花模型帶來的效能問題。

基於指標的最佳化：建立指標擴充套件模型，同時查詢的資料存放在表的一行中，可以一次獲取，減少查詢的次數，如同時獲取同期、上期資料，避免資料的多次查詢。

基於索引的最佳化：直接在事實表中建立外來鍵，分類彙總不需要關聯更多的維表中，可以直接進行查詢。同時直接在事實表中建立外來鍵之後，可以保留歷史痕跡，完整的反應當時的資料情況，如客戶的客戶業態更換之後，還可以按照客戶當時所屬的客戶客戶業態進行統計。

基於彙總表的最佳化：根據維表的不同彙總方向，建立多級彙總表，彙總的資料直接在彙總表中查詢，實現資料的最佳化。

靈活查詢系統建設過程

基於彙總表體系，建立靈活查詢系統，是本模型的目標之一，按照元件化的方式，可以將靈活查詢系統分成查詢元件、資料獲取元件、資料展示元件、資料彙總元件、後設資料元件。資料庫層面還需要完善的內容包含資料許可權、後設資料兩個部分，資料許可權用與限定使用者看到的資料範圍，後設資料用與描述本模型，如下圖所示：

圖 5. 靈活查詢系統元件模型
圖 5. 靈活查詢系統元件模型

靈活查詢系統建立之後，可以實現自動的資料彙總，自定義查詢條件和查詢顯示結果，如果完全實現靈活查詢系統，需要一個漫長的過程，而且很可能因為工期太長，系統過於複雜，最終導致系統開發會失敗，可以分步建設，逐步實現：

首先建立基於指標矩陣模型的資料庫，基於本資料庫進行查詢，具體的查詢可以採用原來的查詢方式和報表展示，資料彙總可以透過直接寫程式或者手工彙總。

建立後設資料管理，對資料模型進行管理，基於後設資料管理建立獨立查詢模組，實現定義各種查詢條件，輸出結果為一個標準化之後的查詢的 XML，然後根據查詢 XML 生成查詢結果。查詢模組可以進一步完善，如儲存查詢條件等。

建立資料獲取模組，資料獲取模輸入條件為標準化之後的查詢的 XML，輸出也是標準化的 XML，進一步將資料獲取模組進行分離，只要輸入一個查詢的 XML，就可以獲取一個查詢結果，並以 XML 方式輸出。

建立資料展示模組，根據 XML 格式自動展示，最終實現自定義資料展示。

建立資料彙總模組，基於後設資料，實現自動彙總。

相關文章