數據庫模型設計連載(1～6)

        最近一直有個愿望：希望把自己所從事的數據庫模型設計方面的工作經驗和想法付諸文字，算是對此前工作的一個總結，今天終于開始了萬里長征的第一步。

        在正式開始之前，我先向大家介紹兩本書——《數據模型資源手冊卷一》、《數據模型資源手冊卷二》，國內有機械工業出版社出版的中文譯本，很多同行可能都已看過，我本人也看過。

        看過之后深受啟發，同時也感到兩點美中不足：

        1、這兩部書的成書時間較早，且原作內容是基于美國企業的業務需求而建，有些最新的行業信息及“中國特色”的東西沒有收錄。

        2、書中原作者所使用的設計符號是作者專用的，而對于目前國內數據庫模型設計的專業人員來說，ER圖或者PowerDesigner中的CDM、PDM圖更容易理解和溝通。

        所以，在今后一段時間，我希望每天能抽出2個小時，結合上面提到的兩部書的內容、PowerDesigner的PDM模型以及本人相關工作經驗，在這里做一個數據庫模型設計的連載。本連載計劃用120天的時間撰寫完畢。

        這么做的目的，一方面是將頭腦里的無形信息落實到文字上、有效避免遺忘，另一方面更加希望拋磚引玉，在與同行們溝通交流之后對我自己也是個促進和提高，對其他同行也起到各借鑒的作用。望廣大同行們不吝賜教，大家一起來推動數據庫模型設計的資源共享計劃。

連載之1

原創：胖子劉（轉載請注明出處及作者，謝謝。）

什么是模式？簡單說來，模式類似于定式，就是遇到反復出現的同一問題時所固定使用的解決方案。下圍棋的朋友可能對“定式”這個詞比較熟悉，定式包含著下棋時做遇到的各種情況下的下法、急所、手筋及死活等基本原理，例如星定式、小目定式、邊定式等等，定式懂的越多，圍棋下的越好。

那么是不是數據庫設計模式懂得越多，設計工作越完美呢？理論上是這樣，但是在我這里，各位朋友所能看到的數據庫設計模式只有四種。

為什么只有四種而不是更多？

不時有那句話嗎：“濃縮的都是精華”！

在后面的文章中，您會陸續看到浩浩蕩蕩的設計實例連篇累牘，卻都是利用這四種基本模式設計出來的?！兑讉鳌は缔o》曰：“易有太極，是生兩儀，兩儀生四象，四象生八卦?！崩献釉凇兜赖陆洝分幸舱f：“道生一，一生二，二生三，三生萬物?！?/DIV>

設計模式不必多，只要掌握其中關鍵的幾個，再結合實際的業務需求，一個完整的數據庫模型就可以推導出來。

下面讓我們來逐一介紹這四種主要設計模式——

 

（一）主擴展模式

連載之2

原創：胖子劉（轉載請注明出處及作者，謝謝。）

（一）主擴展模式

主擴展模式，通常用來將幾個相似的對象的共有屬性抽取出來，形成一個“公共屬性表”；其余屬性則分別形成“專有屬性表”，且“公共屬性表”與“專有屬性表”都是“一對一”的關系。

“專有屬性表”可以看作是對“公共屬性表”的擴展，兩者合在一起就是對一個特定對象的完整描述，故此得名“主擴展模式”。

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“主擴展模式”這個概念來使用的，請大家注意）。

假設某公司包括如下6種類型的工作人員：采購員、營銷員、庫房管理員、收銀員、財務人員和咨詢專家，采用主擴展模式進行設計，如下圖所示。

無論哪種類型的工作人員，都要訪問公司的辦公軟件，所以都有“登陸代碼”和“登錄密碼”；并且作為一般屬性，“姓名”、“性別”、“身份證號”、“入職時間”、“離職時間”等屬性，都與個人所從事的工作崗位無關，所以可以抽取出來作為公共屬性，創建“公司員工”表。

很顯然，公司委派員工采購哪些商品是“采購員”的專有屬性，這是由公司的實際業務特點決定的。換句話說，公司不可能把采購任務放到“營銷員”身上，也不可能放到“庫房管理員”身上，“采購商品”屬性就是“采購員”的專用屬性。

“采購員”表的主鍵與“公司員工”表的主鍵是相同的，包括字段名稱和字段的實際取值；“采購員”表的主鍵同時是“公司員工”表主鍵的外鍵。在PDM圖里可以看到“采購員”表中的“員工ID”字段后面有一個“<pk,fk>”標記，這個標記就說明“員工ID”字段既是“采購員”表的主鍵，同時也是該表的外鍵。

“公司員工”表是主表，“采購員”表是擴展表，二者是“一對一”的關系，兩個表的字段合起來就是對“采購員”這個對象的完整說明。同理，“公司員工”表和其他5個表之間也都分別構成了“一對一”的關系。

對于主表來說，從表既可以沒有記錄，也可以有唯一一條記錄來對主表進行擴展說明，這就是“主擴展模式”。

 

（二）主從模式

連載之3

原創：胖子劉（轉載請注明出處及作者，謝謝。）

（二）主從模式

主從模式，是數據庫設計模式中最常見、也是大家日常設計工作中用的最多的一種模式，它描述了兩個表之間的主從關系，是典型的“一對多”關系。

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“主從模式”這個概念來使用的，請大家注意）。

比如論壇程序。一個論壇通常都會有若干“板塊”，在每個板塊里面，大家可以發布很多的新帖。這時候“板塊”和“發帖”就是主從模式，主表是“板塊”，從表是“發帖”，二者是“一對多”的關系。

多個潛水員也可以對感興趣的同一份發帖進行回復，以表達各自的意見，這時候，一個“發帖”就有了多份“回復”，又構成了一個“主從模式”。

 

（三）名值模式

連載之4

原創：胖子劉（轉載請注明出處及作者，謝謝。）

（三）名值模式

名值模式，通常用來描述在系統設計階段不能完全確定屬性的對象，這些對象的屬性在系統運行時會有很大的變更，或者是多個對象之間的屬性存在很大的差異。

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“名值模式”這個概念來使用的，請大家注意）。

1.       使用名值模式進行設計時，如果對“其他屬性”僅作瀏覽保存、不作其它任何特殊處理，則通常會設計一個“屬性模板”表，該表的數據記錄在系統運行時動態維護。

系統運行時，如需維護“產品其他屬性”，可先從“屬性模板”中選擇一個屬性名稱，然后填寫“屬性值”保存，系統會將對應的產品ID、屬性模板ID及剛剛填寫的“屬性值”一起保存在“產品其他屬性”里，這樣就完成了相關設置。無論產品的其他屬性需求發生怎樣的變化、怎樣增刪改屬性，都可以在運行時實現，而不必修改數據庫設計和程序代碼。（見下圖）

2.       使用名值模式進行設計時，如果對“其他屬性”有特殊處理，比如統計匯總，那么這個屬性名稱需要在程序代碼中作“硬編碼”，即該屬性名稱需要在程序代碼中有所體現，此時可以在“產品其他屬性”表中直接記錄“屬性名稱”，不再需要“屬性模板”表。

系統運行時，如需維護“產品其他屬性”，程序直接列出“屬性名稱”，然后填寫“屬性值”保存，系統會將對應的產品ID、屬性名稱及剛剛填寫的“屬性值”一起保存在“產品其他屬性”里，這樣就完成了相關設置。以后如果需求發生變更，則只需修改相應的程序代碼即可，不必修改數據庫設計。（見下圖）

 

 

（四）多對多模式

連載之5

原創：胖子劉（轉載請注明出處及作者，謝謝。）

（四）多對多模式

多對多模式，也是比較常見的一種數據庫設計模式，它所描述的兩個對象不分主次、地位對等、互為一對多的關系。對于A表來說，一條記錄對應著B表的多條記錄，反過來對于B表來說，一條記錄也對應著A表的多條記錄，這種情況就是“多對多模式”。

“多對多模式”需要在A表和B表之間有一個關聯表，這個關聯表也是“多對多模式”的核心所在。根據關聯表是否有獨立的業務處理需求，可將其劃分為兩種細分情況。

1.       關聯表有獨立的業務處理需求。

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“多對多模式”這個概念來使用的，請大家注意）。

比如網上書店，通常都會有“書目信息”和“批發單”。一條“書目信息”面對不同的購買客戶、可以存在多張“批發單”，反過來，一張“批發單”也可以批發多條書目，這就是多對多模式。中間的“批發單明細”表就是兩者的關聯表，具備獨立的業務處理需求，是一個業務實體對象，因此它具備一些特有的屬性，比如針對每一條明細記錄而言的“累計退貨次數”、“累計退貨數量”、“累計結算次數”、“累計結算數量”；由于批發單明細在數據產生后已經打印出紙質清單提供給客戶，因此在“批發單明細”表里對紙質清單中打印的書目信息屬性作了冗余（逆標準化），這樣在將來即使修改了“書目信息”表中的屬性，也不會影響跟客戶核對批發單明細，不會影響未來的財務結算業務。

2.       關聯表沒有獨立的業務處理需求

舉例如下（注：這個例子已經作了相當程度的簡化，僅僅是用來幫助大家理解“多對多模式”這個概念來使用的，請大家注意）。

比如用戶與角色之間的關系，一般系統在做權限控制方面的程序時都會涉及到“系統用戶表”和“系統角色表”。一個用戶可以從屬于多個角色，反過來一個角色里面也可以包含多個用戶，兩者也是典型的“多對多關系”。其中的關聯表“用戶角色關聯表”在絕大多數情況下都是僅僅用作表示用戶與角色之間的關聯關系，本身不具備獨立的業務處理需求，所以也就沒有什么特殊的屬性。

 

（五）使用上述四種模式的一般原則

連載之6

原創：胖子劉（轉載請注明出處及作者，謝謝。）

（五）使用上述四種模式的一般原則

1.       什么時候用“主擴展模式”？

對象的個數不多；各個對象之間的屬性有一定差別；各個對象的屬性在數據庫設計階段能夠完全確定；各個擴展對象有獨立的、相對比較復雜的業務處理需求，此時用“主擴展模式”。將各個對象的共有屬性抽取出來設計為“主表”，將各個對象的剩余屬性分別設計為相應的“擴展表”，“主表”與各個“擴展表”分別建立一對一的關系。

 

2.       什么時候用“主從模式”？

對象的個數較多且不固定；各個對象之間的屬性幾乎沒有差異；對象的屬性在數據庫設計階段能夠完全確定；各個對象沒有獨立的業務處理需求，此時用“主從模式”。將各個對象設計為“從表”的記錄，與“主表”對象建立一對多的關系。

 

3.       什么時候用“名值模式”？

對象的個數極多；各個對象之間的屬性有較大差異；對象屬性在數據庫設計階段不能確定，或者在系統運行時有較大變更；各個對象沒有相互獨立的業務處理需求，此時用“名值模式”。

 

4.       什么時候用“多對多模式”？

兩個對象之間互為一對多關系，則使用“多對多模式”。

原文轉自：http://www.anti-gravitydesign.com