(轉)分析與設計數據庫模型的簡單過程

近期在作一個業務系統的分析和數據模型設計，工做這幾年也作過好幾個項目的數據庫模型的設計，期間也算是積累了必定的經驗吧，此次有機會就寫寫個人數據庫模型設計過程與方法。

在數據庫設計中，設計的目標就是要創建E-R圖（實體-關係圖），在PowerDesigner中就是要創建概念模型或者邏輯模型。既然是實體-關係圖，因此整個建模的核心就是圍繞創建「實體」對象和找到實體之間的「關係」。實體分爲兩部分：標識（主鍵）和屬性。標識是實體的一個或多個屬性的組合，用於惟一的表標識出實體中的每個數據。在確認一個實體的過程當中，首先就是要確認實體的主鍵，只要找到了實體的主鍵，那麼剩下的就是實體的屬性。

1.確認核心實體

在建模過程當中，首先須要對業務進行分析，知道咱們的模型要表示怎麼樣的一個事情，從而肯定咱們模型的核心實體，找到了核心實體和其主鍵，那麼剩下的工做就是以核心實體爲中心進行實體關聯的擴展和實體屬性的抽象。一個數據庫模型中通常會有1~2個實體做爲整個模型的核心實體，核心實體通常都是一個名詞，在整個業務過程當中做爲主語和賓語。因此總的來講，咱們用一個主謂賓的句子來描述咱們這個模型，那麼基本就能夠確定，這句話中的主語和賓語就是核心實體，而一般謂語也是一個很核心的對象，該對象可能會產生一個實體來表示，也可能只是一個關聯（Association）。一般數據庫中數據量最大的表就是謂語對應的表。

以上說法可能比較抽象，用一兩個簡單的例子來講明。假設咱們須要設計一個學生選課系統的數據庫模型，那麼首先就是要分析，咱們這個系統是作什麼的，記錄什麼的？「學生選課」！雖然只有4個字，可是已經完整的表達整個系統，從這樣一個主謂賓的句子中，咱們能夠得出，整個模型的核心是「學生」（主語）和「課程安排」（賓語），謂詞「選」表名了兩個實體之間的核心關係。肯定了核心的實體「學生」和「課程安排」，那麼接下來就是要肯定實體的主鍵和屬性。「學生」實體的主鍵很容易肯定，只要找到可以惟一標識每一個學生的一個字段便可，因此咱們可使用「學號」來做爲學生實體的主鍵，一個學校中每一個學生的學號確定是惟一的。「課程安排」這個實體的主鍵並無那麼明顯的屬性可以表示，對於沒法找到明顯的實體屬性做爲主鍵的狀況下，咱們須要建立一個專門的標識列（ID）用來標識實體中的每一個實例。在數據庫中最多見的ID就是自增列。這裏咱們能夠設計「課程安排ID」做爲課程實體的主鍵，每在數據庫中增長一門課程，系統會自動爲該課程分配一個自增的惟一整數來標識。

再好比一個要設計一個電子商務系統的數據庫模型，首先一句話總結該系統就是「用戶在網上購買商品」，因此這個系統的核心實體就是「用戶」和「商品」。用戶實體的主鍵是什麼？用戶的登陸名是惟一的、郵箱是惟一的，均可以做爲該實體的主鍵。可是在真實的電子商務系統中不多使用登陸名或郵箱來做爲主鍵，由於其中一個很重要的緣由是登陸名和郵箱都太長，並且長度不肯定，因此在數據庫中通常會設計一個自增的「用戶ID」來做爲用戶的主鍵。商品實體的主鍵能夠用商品的條形碼來做爲主鍵，確實能夠這麼作，可是一樣的緣由，條形碼太長了，因此通常會用一個Int型的自增列「商品ID」做爲商品的主鍵。

2.確認相關實體

在找到了核心實體後，接下來就是以核心實體爲中心，找到相關的實體。相關實體通常來講就是和核心實體存在直接聯繫的實體，固然也有些相關實體是要通過另外一個相關實體與核心實體關聯。相關實體通常狀況下都是名詞。

以選課系統爲例，與學生相關的實體是什麼？班級、專業方向、院系等，與課程安排相關的實體是什麼？課程、課程的詳細安排、安排的教師等，因此咱們能夠將這些要關聯到的實體都創建。

再看看前面說到的電子商務平臺，核心實體是用戶和商品，圍繞用戶，咱們須要創建用戶的「訂單」（包括訂單的明細）、用戶的「代金券」等實體，圍繞商品，咱們須要創建商品的分類，商品的供應商等相關實體。因而咱們的電子商務數據庫模型變爲：

這一步並無完成，一個實體能夠沒有屬性，可是卻不能沒有主鍵，因此須要給全部相關實體添加主鍵，咱們能夠以簡短的能夠惟一標識實體的屬性來做爲主鍵，也可使用自增的ID做爲主鍵，在數據庫中出於性能、快捷等方面的考慮，大部分實體都是以ID做爲主鍵。

3.確認關聯和關係

關聯（Association）也是一種實體間的鏈接，在Merise模型方法學理論中，Association是一種用於鏈接分別表明明肯定義的對象的不一樣實體，這種鏈接僅僅經過另外一個實體不能很明確地表達，而經過「事件（Event）」鏈接來表示。

也就是說，實體和實體之間存在着關係（多對多），可是這種關係還存在其餘的屬性，這些屬性若是若是做爲一個明確的實體的實體來表示又不是很合適，因此就使用了Association來表達，這種關係之間通常是一個「事件」虛實體，也就是說是一個動詞對應的實體。

以選課系統爲例，「選課」這個動詞就是須要用關聯來表示，一個學生能夠選擇多個課程安排，一個課程安排會有多個學生來選，因此學生和課程安排之間是多對多的關係，可是學生選課時還須要記錄學生的時間、選課是否成功等信息，因此須要使用關聯來表示選課這個動做。

前面說到的多對可能是實體之間的一種關係，兩個實體之間存在4種關係：一對1、一對多、多對一和多對多。根據核心實體和相關實體之間的關係創建實體之間的關係，因而咱們的選課系統數據庫模型如圖所示：

對於一個電子商務系統，分析其中的實體之間的關係，也能夠獲得相似的關係圖。要表示用戶對商品的收藏，也就用戶和商品兩個實體直接的直接關係，一個用戶能夠收藏多件商品，一個商品能夠被多個用戶收藏，因此用戶和商品之間是多對多的關係。另外，商品分類和自身是一個一對多的關係，由於分類存在大分類和小分類，是一種層級關係，一個父級分類下面有多個小分類，一個小分類只會有一個父級分類，因此分類自身一對多。

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便可。

經過以上幾步操做，咱們能夠創建完整的數據庫概念模型，主要應該關注在實體的創建（核心就是要找到實體的主鍵）和實體關係的創建（核心就是找到實體直接是一對多仍是多對多或者一對一），只要把這兩點作好，那麼整個模型的框架就搭建好了。

【本文章出自博客園深藍居，轉載請註明做者出處,若是您以爲博主的文章對您有很大幫助，歡迎支付寶（studyzy@163.com）對博主進行打賞。】