近期在做一個業務系統的分析和數據模型設計，工作這幾年也做過好幾個項目的數據庫模型的設計，期間也算是積累了一定的經驗吧，這次有機會就寫寫我的數據庫模型設計過程與方法。
在 數據庫設計中，設計的目標就是要建立E-R圖（實體-關係圖），在PowerDesigner中就是要建立概念模型或者邏輯模型。既然是實體-關係圖，所 以整個建模的核心就是圍繞建立“實體”對象和找到實體之間的“關係”。實體分爲兩部分：標識（主鍵）和屬性。標識是實體的一個或多個屬性的組合，用於唯一 的表標識出實體中的每一個數據。在確認一個實體的過程中，首先就是要確認實體的主鍵，只要找到了實體的主鍵，那麼剩下的就是實體的屬性。
1.確認核心實體
在 建模過程中，首先需要對業務進行分析，知道我們的模型要表示怎麼樣的一個事情，從而確定我們模型的核心實體，找到了核心實體和其主鍵，那麼剩下的工作就是 以核心實體爲中心進行實體關聯的擴展和實體屬性的抽象。一個數據庫模型中一般會有1~2個實體作爲整個模型的核心實體，核心實體一般都是一個名詞，在整個 業務過程中作爲主語和賓語。所以總的來說，我們用一個主謂賓的句子來描述我們這個模型，那麼基本就可以肯定，這句話中的主語和賓語就是核心實體，而通常謂 語也是一個很核心的對象，該對象可能會產生一個實體來表示，也可能只是一個關聯（Association）。通常數據庫中數據量最大的表就是謂語對應的 表。
以上說法可能比較抽象，用一兩個簡單的例子來說明。假設我們需要設計一個學生選課系統的數據庫模型，那麼首先就是要分析，我們這個 系統是做什麼的，記錄什麼的？“學生選課”！雖然只有4個字，但是已經完整的表達整個系統，從這樣一個主謂賓的句子中，我們可以得出，整個模型的核心是 “學生”（主語）和“課程安排”（賓語），謂詞“選”表名了兩個實體之間的核心關係。確定了核心的實體“學生”和“課程安排”，那麼接下來就是要確定實體 的主鍵和屬性。“學生”實體的主鍵很容易確定，只要找到能夠唯一標識每個學生的一個字段即可，所以我們可以使用“學號”來作爲學生實體的主鍵，一個學校中 每個學生的學號肯定是唯一的。“課程安排”這個實體的主鍵並沒有那麼明顯的屬性能夠表示，對於無法找到明顯的實體屬性作爲主鍵的情況下，我們需要創建一個 專門的標識列（ID）用來標識實體中的每個實例。在數據庫中最常見的ID就是自增列。這裏我們可以設計“課程安排ID”作爲課程實體的主鍵，每在數據庫中 增加一門課程，系統會自動爲該課程分配一個自增的唯一整數來標識。
再 比如一個要設計一個電子商務系統的數據庫模型，首先一句話總結該系統就是“用戶在網上購買商品”，所以這個系統的核心實體就是“用戶”和“商品”。用戶實 體的主鍵是什麼？用戶的登錄名是唯一的、郵箱是唯一的，都可以作爲該實體的主鍵。但是在真實的電子商務系統中很少使用登錄名或郵箱來作爲主鍵，因爲其中一 個很重要的原因是登錄名和郵箱都太長，而且長度不確定，所以在數據庫中一般會設計一個自增的“用戶ID”來作爲用戶的主鍵。商品實體的主鍵可以用商品的條 形碼來作爲主鍵，確實可以這麼做，但是同樣的原因，條形碼太長了，所以一般會用一個Int型的自增列“商品ID”作爲商品的主鍵。
2.確認相關實體
在找到了核心實體後，接下來就是以核心實體爲中心，找到相關的實體。相關實體一般來說就是和核心實體存在直接聯繫的實體，當然也有些相關實體是要經過另一個相關實體與核心實體關聯。相關實體一般情況下都是名詞。
以選課系統爲例，與學生相關的實體是什麼？班級、專業方向、院系等，與課程安排相關的實體是什麼？課程、課程的詳細安排、安排的教師等，所以我們可以將這些要關聯到的實體都建立。
再看看前面說到的電子商務平臺，核心實體是用戶和商品，圍繞用戶，我們需要建立用戶的“訂單”（包括訂單的明細）、用戶的“代金券”等實體，圍繞商品，我們需要建立商品的分類，商品的供應商等相關實體。於是我們的電子商務數據庫模型變爲：
這一步並沒有完成，一個實體可以沒有屬性，但是卻不能沒有主鍵，所以需要給所有相關實體添加主鍵，我們可以以簡短的可以唯一標識實體的屬性來作爲主鍵，也可以使用自增的ID作爲主鍵，在數據庫中出於性能、快捷等方面的考慮，大部分實體都是以ID作爲主鍵。
3.確認關聯和關係
關聯（Association）也是一種實體間的連接，在Merise模型方法學理論中，Association是一種用於連接分別代表明確定義的對象的不同實體，這種連接僅僅通過另一個實體不能很明確地表達，而通過“事件（Event）”連接來表示。
也就是說，實體和實體之間存在着關係（多對多），但是這種關係還存在其他的屬性，這些屬性如果如果作爲一個明確的實體的實體來表示又不是很合適，所以就使用了Association來表達，這種關係之間一般是一個“事件”虛實體，也就是說是一個動詞對應的實體。
以選課系統爲例，“選課”這個動詞就是需要用關聯來表示，一個學生可以選擇多個課程安排，一個課程安排會有多個學生來選，所以學生和課程安排之間是多對多的關係，但是學生選課時還需要記錄學生的時間、選課是否成功等信息，所以需要使用關聯來表示選課這個動作。
前面說到的多對多是實體之間的一種關係，兩個實體之間存在4種關係：一對一、一對多、多對一和多對多。根據核心實體和相關實體之間的關係建立實體之間的關係，於是我們的選課系統數據庫模型如圖所示：
對 於一個電子商務系統，分析其中的實體之間的關係，也可以得到類似的關係圖。要表示用戶對商品的收藏，也就用戶和商品兩個實體直接的直接關係，一個用戶可以 收藏多件商品，一個商品可以被多個用戶收藏，所以用戶和商品之間是多對多的關係。另外，商品分類和自身是一個一對多的關係，因爲分類存在大分類和小分類， 是一種層級關係，一個父級分類下面有多個小分類，一個小分類只會有一個父級分類，所以分類自身一對多。
4.確認屬性
前 面幾步工作時最重要最核心的工作，接下來的工作就是要完善模型。首先需要的就是要將實體的屬性補齊，實體的屬性可以根據日常生活常識、用戶提交的表單、用 戶需求調研等來確定。比如學生表，根據常識我們知道，學生會具有姓名、性別、生日等屬性；課程會具有課程名、學分等屬性；課程的詳細安排會安排具體的時 間、上課的地點等屬性……在實際的企業應用中，大部分實體的屬性時不可能通過常識來得到的，必須進行需求的調研，結合業務上的需求和實際中的表單、數據流 等找到實體的屬性。比如對於供應商這個實體，我們只知道供應商有編號，有名字，還有其他什麼屬性就必須得調研了。調研時我們知道企業新增加一個供應商時會 填寫一個新增供應商表，那麼我們就可以拿到該表，更加表單的內容來設計供應商實體的屬性。
5.範式化
在 前面設計選課系統的數據模型時，對於選課的詳細信息實體，會存在上課的時間、上課的地點等屬性，但是仔細一考慮，這些屬性如果直接放在該實體中，必然會形 成數據重複，導致數據維護困難，不符合3範式的設計原則，所以應該將這些屬性提出，作爲單獨的實體，於是，我們的選課系統的數據庫模型就變爲如圖所示：
再說下電子商務系統的模型，裏面最重要的一個實體“商品”會包含很多屬性，比如大小、顏色、重量、賣價……，這其中，大小、顏色本身也可以作爲實體抽取出來，以便於進行維護，所以我們的電子商務系統的模型便爲：
6.細節調整
現 在整個模型已經基本上完成了，但是仍然有幾個地方需要進一步的確認和調整：屬性的數據類型和實體之間的關係。現在數據庫模型中，所有的屬性的數據類型都是 Undefined，需要根據系統要求、業務需求和調研來確定每個屬性的數據類型。但一般來說還是具有一定的規則可循：
- 自增ID用Integer型，如果數據量會特別特別大的話，可以使用長整型。
- 涉及到金額的用Money類型。
- 涉及字符串的確定該屬性中是否有可能出現中文，如果有中文出現的，用variable multibyte，沒有中文出現那就用Characters或者variable Characters。
- 如果是枚舉類型的，用Byte。
- 日期和時間類型的，確定是要用日期還是用時間，或者兩者都需要記錄。
- 具有小數的用float類型。
按 照實際情況將模型中的每個屬性的數據類型進行修改。另外就是實體之間的關係，在默認情況下，添加的實體關係是一對多的關係，另外也可能存在一對一或者多對 多的關係，除了這些關係外，另外還需要確定對應的關係實體是否是必須的。一對多中，一這部分就存在0,1 和1,1兩種情況；多的部分存在0,n和1,n兩種情況。最常見的情況是1,1:0,n，也就是說多的一端肯定會對應一個一的實體，而一的一端可以對應0 到多個實體。
再比如電子商務系統，確定該數據庫模型中每個實體屬性的數據類型，然後修改實體之間的關係，將必須存在值對應的地方修改爲1,1或者1,n即可。
通過以上幾步操作，我們可以建立完整的數據庫概念模型，主要應該關注在實體的建立（核心就是要找到實體的主鍵）和實體關係的建立（核心就是找到實體直接是一對多還是多對多或者一對一），只要把這兩點做好，那麼整個模型的框架就搭建好了。