一、資料模型
以下概念在一些教科書中都會有講到，比如：《資料庫原理與應用》。這裡作了一下總結。
1.1、概念
模型，是對現實世界的抽象，資料模型，就是描述資料結構（靜态特征）、資料操作（動态特征）、資料完整性（動靜互動的限制）的概念的集合。而資料模型也是資料庫管理系統（DBMS）的核心和基礎，各種DBMS軟體的實作都是基于資料模型的。
1.2、分類
資料模型可分為兩種：概念資料模型、結構資料模型。
（1）概念資料模型，是面向現象世界的資料模型，它獨立于計算機系統和DBMS；
常用的概念模型有：E-R模型、面向對象模型等。但DBMS發展至今，主流的仍然是關系型資料庫，是以目前對于概念模型的設計依舊是使用E-R模型為主。
也許哪天面向對象型資料庫成為主流，那我們的概念模型設計就也可以采用面向對象的方法了。其實ER模型就是面向對象模型的雛形，面向對象模型一定程度上是從ER模型演變過來的。
（2）結構資料模型，是面向資料庫的資料模型，又可分為邏輯資料模型（邏輯結構）、實體資料模型（實體結構）；
邏輯資料模型：這是使用者在DBMS中看到的模型。DBMS的邏輯模型先後經曆了層狀模型（樹狀模型）、網狀模型、關系模型，以及現在發展中的面向對象模型，之是以關系型經久不衰，就是因為它簡單的邏輯結構：表，無論是設計、維護都比較容易，盡管在處理效率上略次于前兩者。面向對象模型雖然結構清晰、設計友善，但查詢功能太弱，是以在DBMS中暫還沒有取代關系模型的地位；
實體資料模型：是指資料在存儲媒體上的組織結構，它與相應的DBMS及OS相關，通常不需要手動去管理，而是通過使用者在DBMS中指定存儲的方式，由DBMS自動完成在相應OS上的存儲結構。
上面資料模型的三種分類，也正是資料從現實世界到計算機世界的具體表示所要經曆的過程，無論DBMS的發展如何，這個過程是不會改變的。
相應的，資料庫設計可分為以下三步：
（1）概念結構設計：利用概念模型對現實世界進行抽象；
（2）邏輯結構設計：将概念模型轉化為邏輯模型，也就是将對現實世界的抽象轉化為計算機上DBMS的資料結構；
（3）實體結構設計：定制邏輯模型中實作的資料結構在實體媒體的存儲結構；
至于資料庫設計在整個軟體工程生命周期中所處的位置，詳見《軟體工程 - 5、資料庫設計與開發》。
二、概念結構設計
概念結構設計的過程，就是建立E-R模型的過程。
2.1、E-R圖
E-R圖的元件有很多，但概括起來說，可分為以下四種：
矩形：表示實體
菱形：表示實體間的關系
橢圓：表示實體的屬性
線段：用于将實體、關系相連接配接
對于雙矩形、雙菱形、雙橢圓、雙線段等等一些元件，可以不用去管，通常用以上四種元件就可以表達清楚實體及實體間的關系。
2.2、建立E-R模型
以下過程為建立E-R模型的一般步驟，這裡以權限管理子產品為例：
2.2.1、辨別實體
這是權限管理中常用的基于角色的通路控制（RBAC），通常有使用者、角色這兩個實體。
2.2.2、辨別關系
使用者與角色間為多對多的互相擁有關系。
2.2.3、辨別實體、關系的屬性
不僅僅是實體有屬性，關系同樣也有屬性，這些屬性在實體間建立關系時才會存在。
有時屬性太多，無法在圖上一一列出，可以用表格，在後面的步驟中這個表格同樣會用到，如下：
| 實體 | 屬性 | 描述 | … |
| 使用者 | 性别 年齡 電話 … | 男/女 多大了 聯系方式 … | … |
2.2.4、确定屬性域
屬性域就是屬性的取值範圍。
這時，可以用表格将屬性的資料類型、資料長度、取值範圍及是否可為空、簡單/複合、單值/多值、是否為派生屬性等域資訊定義出來。
這個過程，事實上包含了邏輯結構設計中的資料類型、NULL、CHECK、DEFAULT等資訊。
| 實體 | 屬性 | 描述 | 資料類型及長度 | 是否可為空 |
| 使用者 | 性别 年齡 電話 … | 男/女 多大了 聯系方式 … | 1位元組的短整形或布爾型 1位元組的短整形 20位元組的字元型或長整形 … | NO NO YES |
2.2.5、确定鍵
鍵就是可用于辨別實體的屬性，有：主鍵、唯一鍵、外鍵。
| 實體 | 屬性 | 描述 | 鍵 |
| 使用者 | 使用者編号 性别 年齡 電話 … | 男/女 多大了 聯系方式 … | 主鍵 |
2.2.6、實體的特化/泛化
也就是面向對象模型中父類和子類的概念，這是個可選的步驟。
舉個例子，使用者中大部分人都是普通員工，但有一小部分是從事銷售的，銷售人員有個負責區域的屬性，如果将這個屬性放在使用者實體中，如下：
這時我們會發現，除了銷售人員外，其他非銷售人員這個屬性全都不存在，這就是特化的過程。可以另建一個銷售人員的實體來泛化使用者實體，如下：
這樣就完成了對使用者實體的泛化，泛化的過程也就是抽出實體間公共屬性的過程，但通常，除非特化的部分太多，才會考慮将一個實體抽象成兩個1對1關系的實體，所有這個步驟是可選的。
2.2.7、檢查模型
（1）檢查備援
首先檢查實體：1對1關系的實體中有沒有非外鍵的重複屬性，或者就是同一個實體；
其次檢查關系：有沒有通過其他關系也可以得到的重複屬性；
當然有時，需要考慮時間次元，因為有些屬性是有時效性的，也就是雖然是同一個屬性，但不同的時間表示的卻是不同的内容，這一點在後面的邏輯結構設計中會提到，這并不是真正的備援。
（2）檢查業務
檢查目前的E-R模型是否滿足目前業務的場景。可以從某個實體開始，沿着目前E-R模型的各個節點去模拟業務場景。尤其需要和《需求規格說明書》去做校驗。
到這裡，也就完成了E-R模型建立的全過程，有時，對于比較複雜的E-R模型，一張圖可能顯得太過局促，可以建立全局、局部E-R模型圖，以便于檢視和分析。