前言
在資料庫建設過程中，哪一步最重要？絕大多數資料會告訴你，是需求分析階段。這一步的好壞甚至直接決定資料庫專案的成敗。
需求分析階段，也被稱為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圖之後，才能順利進入到接下來的關係表設計階段。這也是下篇要講解的內容。