基於物件導向（OO）的資料庫設計模式探討

xjg95發表於2012-01-06
物件資料庫設計模式


簡介： 物件導向（OO）和三正規化（3NF）都是成熟的設計方法，本文基於物件導向設計思想和三正規化資料庫設計方法，提出一種實體物件分層建模的思路，其目的是設計簡單明瞭、標準化的資料庫結構，同時能夠更好的支援模型驅動模型（MDA）的程式碼自動生成和程式碼複用，減少程式碼編寫工作量。

本文的標籤： fff, oo, 體系架構, 關於產品, 建模, 資料庫, 資料訪問, 設計

物件導向的資料庫設計

本模型探討的一個資料庫建模的方法，其意義主要是為《面向服務體系架構（SOA）和資料倉儲（DW）的思考》（以下簡稱 《 SOA 和 DW 》）所述的共享庫提供方法論支援，建立一個簡單明瞭、易於理解的標準化的資料結構，共享庫的主要目的是為了共享資料，需要建立一個簡單明瞭，標準化的資料結構。同時為基於模型驅動 (Model Driven Architecture，MDA) 的設計方法提供一個簡化的資料結構，更加容易根據資料結構自動生成程式碼。

本文采用 InfoSphere Data Architect 作為工具支援，主要針對需要持久化的業務物件（Business Object，BO)）進行實體物件（Entity Object 或者稱持久化物件 Persistant Object，PO）的邏輯資料模型 (Logical Data Model) 設計。本文中業務物件設計不再詳細論述，假設是已經做了業務物件分析，然後基於業務物件模型生成實體物件模型，並根據實體物件分層模型進一步完善業務物件模型。

物件導向（OO）

物件導向方法 (Object-Oriented Method，OO 方法 ) 是一種把物件導向的思想應用於軟體開發過程中，指導開發活動的系統方法，是建立在“物件”概念基礎上的方法學。物件導向包含物件導向的分析（Object Oriented Analysis，OOA），物件導向的設計（Object Oriented Design，OOD）、物件導向的程式設計實現（Object Oriented Programming，OOP）等，物件導向的分析（OOA）方法是本模型的基本方法。物件導向的方法，當前有成熟的基於 UML（Unified Modeling Language）建模方法論，本文不再詳述。

正規化理論（NF）

第一正規化（1NF）無重複的列，實體中的屬性不能有多個值或者不能有重複的屬性。第二正規化（2NF）要求資料庫表中的每個例項或行必須可以被唯一地區分，不能存在僅依賴主關鍵字一部分的屬性。 第三正規化（3NF）要求一個資料庫表中不包含已在其它表中已包含的非主關鍵字資訊。在本模型中，如果出現重複的屬性，就需要增加一個實體物件，並根據新增物件和原物件的主鍵關係確定其物件關係。從效能角度考慮，在資料表中增加了冗餘外來鍵對應關係，即並非完全滿足 3NF 的要求。

維度建模（DM）

維度建模（Dimensional Modeling，DM）是資料倉儲建設中的一種資料建模方法。按照事實表，維表來構建資料倉儲，資料集市。在本模型中，物件彙總關係部分採用了維度建模的思想，但是沒有深入的探討維度建模方法論，關於維度建模可以參考相關的資料。

模型驅動架構（MDA）

模型驅動架構 (Model Driven Architecture，MDA) 是由 OMG 定義的一個軟體開發框架。它是一種基於 UML 以及其他工業標準的框架，支援軟體設計和模型的視覺化、儲存和交換。和 UML 相比，MDA 能夠建立出機器可讀和高度抽象的模型，這些模型獨立於實現技術，以標準化的方式儲存。本模型的第二個目標就是為建立更高效率的自動生成程式碼提供一個資料基礎。。

IBM InfoSphere Data Architect

IBM InfoSphere Data Architect（以下簡稱 IDA） 是一種協作式的資料設計解決方案，能用於發現、建模、關聯和標準化各異的分散式資料資產。如圖 1 所示，是實體物件分層模型最終完成之後的介面，IDA 能夠很好的支援分層的建模，可以到 IBM 網站下載 IDA 試用版。

圖 1. InfoSphere Data Architect 介面
圖 1. InfoSphere Data Architect 介面

示例模型說明

為了更好的描述物件模型 , 將以銷售管理系統為例進行介紹 , 包含系統管理和銷售管理兩個部分 , 銷售管理主要實現貨物的採購和銷售管理，包含組織機構、人員、倉庫、商品批號、供應商、客戶；銷售訂單、採購訂單、出入庫單等業務單據。其整體模型如圖 2 所示：

圖 2. 本文示例主要物件關係圖
圖 2. 本文示例主要物件關係圖

以下以物件導向設計為基礎，按照三正規化建模方式，採用 IDA 7 工具，從最簡單的實體物件物件模型入手，逐步細化模型，其基本框架模型下找出所有物件之間的關係，並模式化。

回頁首

物件關係模型

業務物件（BO）包含複雜的邏輯關係，透過對業務物件及實體物件之間的關係的分析，將物件的關係簡化為物件基本關係、物件變更關係、物件彙總關係、類別物件關係等，針對物件資料不確定的物件，建立屬性不確定物件關係。除了物件之間的關係外，本模型增加了一個附加物件層，包含樹裝結構、時間結構等，用於處理一個特殊的業務需求。

在本模型中，實體物件基本關係是核心，確定了基本關係，也就把資料庫的整體框架搭建起來了，其他模型可以看作僅僅是一個正規化，在設計資料庫的時候選擇一個正規化即可。本文雖然是以實體物件進行建模，但是其和業務物件是對應的，所以其關係模型也適應於業務物件。

物件基本關係模型

根據實體物件之間的關係，將實體物件分成標準元實體物件、元實體物件和關聯實體物件三類。這三類實體物件構成了實體物件關係的基本框架。如圖 3 所示：

圖 3. 物件基本關係圖
圖 3. 物件基本關係圖

標準元實體物件：實體物件完全獨立，不依賴於任何其他的實體物件，典型標準元實體物件如組織機構、國家等內容。標準元實體物件完全獨立，有標準的編碼體系（一般都有企業標準、國標或者國際標準），不會因為在不同的系統不同有不同編碼體系。標準元實體物件只有一個主鍵。
元實體物件：獨立的實體物件，和標準元實體物件不同，一般沒有一個唯一的識別符號，需要增加一個唯一識別符號（比如單位編碼，需要制定一個編碼規則，主要目的在於未來資料合併的時候不會因為多個系統合併而使得資料重複），然後才能唯一標示物件。元實體物件是建模中最基本、最核心的物件。如客戶，訂單、流程等，是業務邏輯、對外介面的核心實體物件。標準元實體物件是有標準編碼體系特殊的元實體物件。
根據元實體物件數量增長的快慢，可以把元實體物件分成基礎元實體物件和流水元實體物件，前者實體物件一般變化緩慢，如客戶資料（比較重要的基礎元實體物件一般對應著的是主資料），後者變化快，如訂單資料等。
關聯實體物件：標準元實體物件、元實體物件之間的關聯物件，有些僅僅是簡單的關聯，有些關聯物件中含有其他的業務資訊。前者僅僅是對應關係，後者包含對應關係的其他屬性。如具體一個公司的商品價格資訊，是實體物件－商品和組織機構關聯之後的資訊。關聯物件本身也是一個特殊的實體物件。關聯實體物件主鍵一般是兩個或者兩個以上，一般來說，應該儘量減少關聯物件的主鍵數量。

除了以上基本關係之外，還有一些特殊的實體物件關係，包含附屬關聯實體物件、主從關聯實體物件等

附屬關聯實體物件：實體物件的附屬資訊，和實體物件是一對一或者一對多關係。一對一關係一般是為了把一個屬性太多的物件分解成多個（在 IDA 中可以用繼承來描述）；一對多關係採用增加序號的方式，增加多條資訊。如人員的學歷、工作經歷等。不同於關聯物件，其只是簡單的序號的增加。訂單可以以客戶編碼和流水號作為主鍵，但是這種有流水號主鍵的一般是可以將幾個主鍵合併為一個主鍵，如果能合併為一個主鍵，則合併為一個主鍵，從而簡化模型的層次。附屬關係一般是為了解決簡單一對多的附屬資訊，如果附屬物件需要複雜的業務邏輯，需要將多個主鍵合併為一個主鍵。
主從關聯實體物件：關聯實體物件的一種特殊情況，關聯的兩個物件之間有強烈的主從關係，如訂單和訂單項等。主從管理實體物件一般從物件內容有限，在軟體實現中一般以單據方式進行展示。

除了基本的關聯關係之外，物件和物件之間還有外來鍵關係，外來鍵關係不象關聯關係那樣是主鍵關係，外來鍵關係是外來鍵關聯。如圖 4 所示：

圖 4. 物件外來鍵關係圖
圖 4. 物件外來鍵關係圖

在本模型中，比較一個關鍵的一點是要儘量多的建立元實體物件，特別是標準元實體物件，儘量減少關聯實體物件。比如訂單，是元實體物件不是關聯實體物件，即客戶和訂單的關係不是主鍵關係而是外來鍵關係。外來鍵有多種，如一對一、一對多關係等，詳見 IDA 中的設定。一個簡單的原則可以來判斷，如果關聯實體物件除了關聯的實體物件的主鍵之外還需要一個獨立的主鍵，就應該考慮看作是一個元實體物件（附屬關聯實體物件除外）。

物件基本關係模型構成了物件關係模型的主要框架，除此之外，還有一些其他的關係模型，包括物件變更模型、物件彙總模型、類別物件關係模型、附加物件關係模型、不定屬性物件關係模型。對於設計者來說，需要關注的僅僅是基本關係模型，其他模型的設計可以看作是固化了的設計正規化，只需要設定正規化即可。

物件變更關係模型

實體物件例項在業務活動過程中不斷髮生變化，根據業務的需要，需要記錄實體物件例項的變化資訊（不同於流水元實體物件，是多個物件例項，比如訂單，隨著業務的變化，訂單不斷增加）。包括物件屬性變更、物件整體變更、物件快照等。另外從業務上考慮，為了實現操作痕跡化，需要對操作過程進行記錄。如圖 5 所示

圖 5. 物件變更關係圖
圖 5. 物件變更關係圖

實體物件屬性變更，對屬性變化的歷史進行記錄。根據記錄的先後順序可以分成兩種：採用申請單的方式，先記錄變化的資訊，然後更改實體物件；監控物件變化，變化之後記錄變化之後的屬性。對於不重要的屬性可以選擇不記錄變更情況。
實體物件整體變更，對實體物件的變更情況整體記錄，記錄更改後的完整資訊，一般適合於流水元實體物件，用於記錄流水物件的變化情況。
實體物件快照，為了便於記錄歷史資訊，可以完整的還原當時的場景，記錄當時所有實體物件的資訊，作為實體物件的快照進行管理。
實體物件操作痕跡化管理，對於一些關鍵業務資料，業務上需要保留操作痕跡，比如訂單數量修改和刪除需要記錄相應的資訊。採用兩種方式來解決，一個是不允許刪除實體物件，只做實體物件除刪除標記，適用於整條記錄刪除的情況；對於記錄變更的情況，採用增加一個廢棄實體物件，記錄實體物件的修改記錄。

物件彙總關係模型

實體物件發生連續變化之後，需要對變化資訊的彙總成為彙總物件，包含彙總和計數，和實體物件的關係為物件彙總關係，包括按照年、月、日、周、季等彙總，分別形成年、月、日、周、季的彙總表。根據彙總物件和原始物件之間的關係，可以分成簡單彙總關係和分組彙總關係，後者根據原始物件的外來鍵關係進行分組彙總。分組彙總關係又可以分成歷史分組彙總和當前分組彙總。彙總物件屬性可能來源於多個原始實體物件，為了統一模式可以先分別彙總，然後再進行合併。如圖 6 所示：

圖 6. 物件彙總關係圖
圖 6. 物件彙總關係圖

簡單彙總關係，直接基於原始物件按照時間進行彙總。
分組彙總關係，基於原始物件的外來鍵關係進行分組彙總，比如客戶渠道、客戶組織機構等，根據外來鍵物件是否變化可以分成歷史分組彙總和當前分組彙總。前者按照原始實體物件歷史上的狀態進行彙總，當前分組彙總根據當前的分類情況進行彙總，其資料是動態的，需要根據最新的分組彙總情況進行重新彙總。

由於彙總物件是對應的實體物件的按照年、月、日的彙總，因此其主鍵為原實體物件加年 ID、月 ID 或日 ID。是和日期物件的一種特殊的關聯實體物件。

彙總物件更多的承擔著報表查詢的功能，為了提高查詢效能，可以在彙總物件增加額外的外來鍵對應關係甚至把屬性進行冗餘儲存。（彙總物件建模需要參考星形建模，詳見關於資料倉儲建模）

類別物件關係模型

為了減少儲存空間和便於統計，將主實體物件（包含元實體物件和關聯實體物件）的屬性進行分類管理，以編碼替代文字描述，成為類別物件，類別物件和主實體物件的關係式外來鍵關聯關係。如圖 7 所示：

圖 7. 類別物件關係圖
圖 7. 類別物件關係圖

類別物件：實體物件的屬性描述資訊，和元物件的差別是，類別物件僅僅是一個標識和描述，沒有具體的業務屬性資訊，一般不作為主鍵。根據類別物件是否獨立可以將類別物件分成獨立類別物件和依附類別物件，前者跟其他的實體物件沒有任何關係，後者需要根據關聯的實體物件確定對應關係。
合併的類別物件：對於簡單的屬性，可以彙總為一個物件，透過分類進行管理，如圖 8 所示。


圖 8. 類別物件合併儲存
圖 8. 類別物件合併儲存

由於是物件合併的，所以合併之後的物件需要增加一個主鍵，作為標識。需要注意的是物件基本關係模型中涉及的標準元實體物件、元實體物件和關聯實體物件，除了前兩者有一個獨立的主鍵之外，關聯實體物件，除了附屬關聯實體物件外一般都是對應著一組關聯物件的主鍵，關聯物件一般沒有自己的主鍵（附屬關聯物件比較特殊）

附加物件關係模型

附加物件一般不是一個獨立的物件，需要附加於其他物件，但是其具有本身的一些特點，包含樹、圖、修改日誌等附加物件。如圖 9 所示：

圖 9. 樹附加物件關係圖
圖 9. 樹附加物件關係圖

樹附加物件，根據實體物件是否可以有多個樹，可以將樹附加物件分成獨立樹物件和內嵌樹附加物件

相關文章