第一篇：數據庫需求與ER建模

前言

        在數據庫建設過程當中，哪一步最重要？絕大多數資料會告訴你，是需求分析階段。這一步的好壞甚至直接決定數據庫項目的成敗。

        需求分析階段，也被稱爲ER建模(entity-relationship modeling)階段，也常被稱爲需求可視化，概念建模等。這一階段數據庫系統開發人員將協同需求方以ER圖的方式對業務需求進行可視化展示。

        本文將詳細介紹(陳氏)ER符號體系，並在其中穿插一些具體實例講解。

基本概念

        1. 實體(entity)

        實體表示客觀世界中的衆多概念，好比：人，地點，事件等。

        每一個實體自己包含多個實體成員，好比實體人可能包含張三，李四王五等。

        在ER圖中，實體一般用矩形表示，以下所示：

        2. 屬性(attribute)

        每一個實體都有屬性，用橢圓表示並用來描述實體各個特徵。 好比顧客的特徵可能有顧客標識符，顧客姓名，顧客性別，顧客年齡等，以下圖所示：

        此外，每一個實體至少要有一個惟一屬性，用下劃線標記，如上圖中的id字段。

        3. 聯繫(relation)

        實體與實體之間一般具備某種關聯，在ER圖中用菱形表示。好比某職員向某主管彙報，以下圖所示：

        細心的讀者相必發現了，實體間連線的兩端，寫有一些符號。這些符號被稱爲基數約束(cardinality constraint)，用來表示實體能夠有多少實例與另外一實體的實例存在聯繫。

        基數約束共有四種形態：

        此爲形態一，即強制多個對應，表示一個實體A對應多個實體B。

        此爲形態二，便可選多個對應，表示一個實體A對應0個或多個實體B。

        此爲形態三，即強制單個對應，表示一個實體A對應一個實體B。

        此爲形態四，便可選單個對應，表示一個實體A對應0個或1個實體B。

        咱們知道聯繫是雙向的，因此實際ER建模中常見的版本長這樣：

        理解這個聯繫的方法是從兩個方向進行解讀，「實體A對應0個或1個實體B，實體B對應一個或多個實體A」。

擴展概念

        使用前面介紹的這些概念，已經能完成基礎ER建模了。然而，爲了更爲細緻的刻畫出用戶需求，又有了下面這些建模規則。

        1. 複合屬性(composite attribute)

        部分屬性具備複合的特色，好比地址屬性。地址可能包含了省份，城市，街道等子屬性。

        ER圖上這類屬性的屬性名應當標記圓括號，而後擴展爲多個子屬性。可參考下面這個商店實體定義：

        2. 多值屬性(multivalued attribute)

        部分屬性具備多值的特色，好比一個職工可能有多個電話號碼。

        ER圖上這類屬性用雙層橢圓標識，可參考下面這個職工實體定義：

        3. 派生屬性(derives attribute)

        部分屬性可從其餘屬性或者其餘數據(如當前日期)派生出來，這類屬性在ER圖上用虛線橢圓標識。

        可參考下面這個士多店實體定義：

        上圖中士多店的YearsInBusiness屬性表示店鋪開張了多少年，這個屬性能夠結合當前日期與OpeningDate屬性算到，所以用虛線橢圓標識。

        4. 可選屬性(optional attribute)

        部分屬性可能有也可能沒有取值，好比說職工獎金。

        ER圖上這類屬性經過在屬性名後面添加(0)標識，可參考下面這個職工實體定義：

        5. 聯繫的進一步描述

        a. 能夠在聯繫中代表聯繫中的最大最小基數，以下圖所示：

        在上面這個例子中，每一個學生具體對應到了2-6間教室；同時每間教室對應到了5-40名學生。

        b. 也能夠在聯繫中說明聯繫中的角色。這在一元聯繫中尤其常見，以下圖所示：

        每一個人只能送給其餘人一份禮物，但能夠收到0或多份禮物。

        6. 關聯實體(associated entity)

        關聯實體示用於描述M：N聯繫的一個替代方式，用一個內部有菱形的矩形表示，它沒有惟一屬性也沒有部分惟一屬性，且一般來講沒有任何屬性。

        以下兩個圖能夠說是等價的：

        關聯實體基本都是在多元聯繫的場景下用到，後面的高級話題部分會講。

        7. 弱實體(week entity)

        一般來講，實體至少要有一個惟一屬性。由於這樣才能精肯定位到須要處理的記錄。但在ER建模這一層，也並不是老是如此。

        舉例來講，假如如今須要爲某個連鎖酒店管理系統進行ER建模。該公司在全國各地都開有酒店。如今須要記錄下各地酒店的房間使用狀況。

        能夠將房間使用相關信息做爲酒店的建模一個多值複合屬性，以下圖所示：

        這樣作算是對的，可是並無體現出部分碼地位，也就是說各RoomID在各Building的惟一性。同時，不少時候須要將房間實體化與其餘實體相聯繫。好比每一個房間對應的清潔工。

        引入弱實體機制後，即可順利解決這兩個問題。以下圖所示：

        兩個地方要注意一下，一是弱實體的「主碼」稱爲部分碼，碼名下方用虛線標記；

        再一個就是弱實體必須至少有一個屬主實體，它們之間的聯繫需用雙框菱形標識。弱實體部分碼同其屬主實體候選碼的組合能夠惟必定位到任何一個弱實體記錄。

高級話題

        1. 相同實體之間具備多個M:N關係

        某人爲一個學生選課系統進行ER建模，獲得以下結果：

        假如需求中有說明：一個同窗一門課只能選一次，那這樣的設計沒問題。但是若是需求中說明，一個同窗能夠選一門課幾回(多是掛了好幾回)，這樣的設計就有問題了。

        對此，正確的作法之一是使用有兩個屬主實體的弱實體：

        或者爲每次預約生成一個惟一的id，以下圖所示：

        2. 三元(或更多)關係

        在ER圖中，聯繫通常是將兩個實體關聯起來，又或者本身關聯本身。可是也有些時候，需求方須要同時將多個實體聯繫起來。這怎麼辦呢？要知道表示聯繫的菱形有且只有兩個接口。

        答曰：使用關聯實體。下面這個ER圖中，使用了關聯實體描述了某工廠的供貨商，生產產品，零件三方聯繫：

        但若是如今需求又變動了，須要給關聯增長某些屬性，好比說供貨商每次提供的貨物量，這個ER圖就不能用了。

        由於這樣就沒辦法區分同一家供應商爲同一產品提供等數量的同一零件的不一樣實例了。解決的辦法是把關聯實體改爲通常的實體，並增設一個惟一標識符：

其餘說明

        1. 本文實體名全大寫，屬性和關係名則用首字母大寫的駝峯法，同時儘可能保證全部命名都全局惟一；

        2. 用戶的更多個性需求應當以註釋，標籤等方式一併標記在ER圖中；

        3. 建模工具可以使用PowerDesigner，Workbench等。不過筆者在這裏推薦一款輕量級的在線數據庫建模工具，網址是https://erdplus.com/#；

小結

        需求分析，ER建模是貫穿整個數據庫生命週期的工做。這部分工做要求開發人員和業務方，數據庫的使用者，公司領導等方面協同好需求，並將需求以ER圖的模式可視化展示出來。

        只有繪製好ER圖以後，才能順利進入到接下來的關係表設計階段。這也是下篇要講解的內容。