（2）抽取並標識實體
設計人員分析系統需求規格說明書，從中抽取資料需求物件，並將它們標識為實體。
實體是對現實世界中描述事物資料物件的抽象概念。實體可以是人、物品、機構等等，凡是包含資料特徵的物件均可被定義為實體。
在e-r模型圖中，實體通常用兩層矩形方框方式，並在頂層方框內註明實體的名稱。
針對乙個圖書銷售管理系統資料需求，我們可以抽取出「圖書」「商店」「銷售」「折扣」「作者」「出版社」實體，並將它們在e-r模型圖中標識出來，如圖4-17所示。
（3）定義實體的屬性。
每個實體都有自己的一組資料特徵，這些描述實體的資料特徵稱為實體的屬性。
在e-r模型實體符號的兩欄矩形框中，上欄區域顯示實體名稱，下欄區域顯示實體屬性。
在實體中能夠唯一標識不同實體例項的屬性或屬性集稱為識別符號。
「客戶編號」屬性值可以唯一標識不同客戶例項，它可以作為客戶實體的識別符號。如果實體中找不到任何單個屬性可以做識別符號，就必須選取多個屬性的組合作為識別符號，此時該識別符號被稱為復合識別符號。例如，「訂單明細」實體需要使用「訂單編號」和「商品編號」屬性作為復合識別符號。
在圖形表示上，作為識別符號的屬性需加上下畫線。如果是復合識別符號，則構成該復合識別符號的所有屬性都需加上下畫線，如圖4-5所示。
客人：姓名、性別、手機號碼、證件號碼、證件型別（身份證、駕駛證、通行證等等）…
房間：房號、房間型別（單人房、雙人房、豪華房等等）、入住時間、離開時間、房間狀態（已入住、未入住）…
（4）實體間的聯絡
可以使用聯絡（relationship）表示乙個或多個實體之間的關聯關係。現實世界的事物總是存在著這樣或那樣的聯絡，這種聯絡必然要在資訊世界中得到反映。聯絡是實體之間的一種行為，一般用動詞來命名關係，如「管理」「檢視」「訂購」等。
e-r模型圖中，實體之間的聯絡有1:1，1:n，m:n。
按照實體之間的語義關係，可以將實體分為弱實體和強實體。在現實世界中，某些實體對另一些實體有邏輯上的依賴聯絡，即乙個實體的存在必須以另乙個實體的存在為前提，前者就被稱為弱實體，而被依賴的實體被稱為強實體。例如，「銷售」實體必須依賴於「圖書」、「商店」實體而存在。
1:1實體聯絡的實體分別轉換為關係表，我們可將其中乙個表的主鍵放入另乙個表中作為外來鍵。
在1:n實體聯絡中，如果存在識別符號依賴弱實體，在從e-r模型轉換關係模型時，我們需要將1端關係表的主鍵放入n端關係表中，作為外來鍵。
對 m:n實體聯絡，關聯的兩個實體的例項在另乙個實體中都有多個實體例項與之相對應。當將e-r模型轉換到關係模型時，除了關聯的實體均轉換為對應的關係表外，我們還增加乙個關係表，作為關聯表與實體的關係表建立參照約束。
（5）繪製e-r圖
定義好實體之後，接下來我們應該根據實體以及實體之間的關係繪製出e-r圖。比如：
長方形代表實體，橢圓形代表實體的屬性，菱形代表實體之間的關係。
（6）把e-r圖轉換成模型
繪製出e-r圖之後，我們需要根據它來構建物理模型。構建物理模型可以使用一些工具，比如目前比較流行的powerdesigner。
（7）檢查模型
資料庫三大正規化：1、每列不可分割，2、有主鍵，非主鍵列依賴主鍵，3、非主鍵列不能依賴其他非主鍵列。
完成模型設計後，我們還要檢查模型是否滿足第三正規化的要求。如果不滿足就需要重新對模型進行修正，直到滿足第三正規化的要求為止。
比如說，上面的模型並沒有滿足第三正規化的要求。因為customer和room這兩個表都存在一些與該錶沒有直接關係的字段。如果要滿足第三正規化要求，就需要把模型修改為：
上面模型增加了三個表，分別是identity_type（證件型別表）、register（入住登記表）、room_type（房間型別表），經過對模型的修正後，已經滿足第三正規化的要求。
（8）根據模型定義資料庫
#建立資料庫
create database 資料庫名;
#刪除資料庫
drop database 資料庫名;
#查詢資料庫
show databases;
#選定資料庫
use 資料庫名;
#建立表
create table 表名 (
列名 資料型別 [primary key] [auto_increment],
列名 資料型別 [not null] [unique] [default '預設值'] [comment '字段說明'],
列名 資料型別 [not null] [unique] [default '預設值'] [comment '字段說明'],
...[constraint 外鍵名 foreign key(外來鍵列) references 表名(主鍵列) [on update|delete cascade]]
)；#刪除表
drop table 表名;
資料庫設計其實並不難，本人覺得比較難的地方在於開始的分析階段。就是如何根據客戶需求把資料庫裡面的實體，以及實體之間的關係分析出來。所以，在資料庫設計階段，我們應該把重點放在業務需求的分析上，準確把握客戶的需求，這樣才能夠設計出一套比較好的資料庫。
資料庫設計三大正規化資料庫設計三大正規化
為了建立冗餘較小 結構合理的資料庫，設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計乙個結構合理的關係型資料庫，必須滿足一定的正規化。在實際開發中最為常見的設計正規化有三個 1 第一正規化 確保每列保持原子性 第一正規化是最基本的正規化...
資料庫設計三大正規化
為了建立冗餘較小 結構合理的資料庫，設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計乙個結構合理的關係型資料庫，必須滿足一定的正規化。在實際開發中最為常見的設計正規化有三個 1 第一正規化 確保每列保持原子性 第一正規化是最基本的正規化...
資料庫設計三大正規化
為了建立冗餘較小 結構合理的資料庫，設計資料庫時必須遵循一定的規則。在關係型資料庫中這種規則就稱為正規化。正規化是符合某一種設計要求的總結。要想設計乙個結構合理的關係型資料庫，必須滿足一定的正規化。在實際開發中最為常見的設計正規化有三個 1 第一正規化 確保每列保持原子性 第一正規化是最基本的正規化...