數據庫設計是指對一個給定的應用環境，構造最優的數據庫模式，建立數據庫及其他應用系統，使之能有效地存儲數據，滿足各種用戶的需求。數據庫設計過程中命名規范很是重要，命名規范合理的設計能夠省去開發人員很多時間去區別數據庫實體。

最近也因為工作需要所以整理出了這個Word文檔，望大家指正。

數據庫規劃→需求分析→數據庫設計→應用程序設計→實現→測試→運行于維護

定義數據庫應用系統的主要目標，定義系統特定任務，包括工作量的估計、使用資源、和需求經費，定義系統的范圍以及邊界。

涉及人員：用戶和分析人員

任務：對現實世界要處理的對象進行詳細的調查，收集基礎數據及處理方法，在用戶調查的基礎上通過分析，逐步明確用戶對系統的需求，包括信息的要求及處理的要求。

方法與步驟：1.通過與用戶的調查，對用戶的信息需求進行收集。

2.在收集數據的同時，設計人員要對其進行加工和整理，以數據字典和數據流圖的形式描述出來，并以設計人員的角度向用戶講述信息，根據用戶的反饋加以修改并確定（該過程是反復的過程）

成果：數據流圖，數據字典，各種說明性表格，統計輸出表以及系統功能結構圖。

外部實體：存在于軟件系統之外的人員或組織（正方形或立方體表示）。

加工：數據處理，表示輸入數據在此進行變換，產生輸出數據（圓角巨型或圓形表示）。

數據流：表示流動著的數據（箭頭線表示）。

數據存儲：用來表示要存儲的數據（開門矩形或兩條平行橫線表示）。

訂單處理系統頂層流程圖：

0層數據流圖：

• 對事務加以抽象以E-R圖的形式描述出來
• E-R圖（實體聯系圖）：包括實體，聯系，屬性

實體：現實中的事物例如，學生，老師

聯系：兩個實體之間的關系，1:1、1：N、M:N三種關系

屬性：實體所具有的屬性，例如 學生的學號、姓名、性別等

例如：一個學生屬于一個班級，一個班級擁有多名學生，E-R圖如下

網上購物系統E-R圖，該系統數據之間存在下列約束

1. 一個客戶（編號唯一）可以擁有多個訂單，每個訂單僅屬于一個客戶。
2. 一個訂單（編號唯一）可以包含多個訂購細目，每個訂購細目只屬于一個訂單。
3. 一個商品可以出現多個訂購細目中，一個訂購細目只包含多個商品。
4. 一個商品類別可以包含多種商品，一種商品只屬于一個商品類別。

圖2.2

• 將E-R圖轉換成關系模式

將每個實體轉換成一個關系模式，實體的屬性即關系模式的屬性，實體的標識即關系模式的鍵。

• 根據規則合并E-R圖中的1:1,1:N,M:N之間的聯系

1. 若實體的聯系是(1:1)，則可以將兩個實體轉換成兩個關系模式，任意一個關系模式的屬性中加入另一個關系模式的主鍵（作為外鍵）和聯系自身的屬性
2. 若實體間的聯系是一對多（1：n），則將n端的實體類型轉換成關系模式中加入1端實體類型的主鍵（作為外鍵）和聯系類型的屬性。
3. 若實體間的聯系是多對多（m:n），則將聯系類型也轉換成關系模式，其屬性為2實體類型的主鍵（作為外鍵）加上聯系類型自身的屬性，而該關系模式的主鍵為2端實體主鍵的組合。
4. 若關系模式是1：1：1的關系，轉換原則同1：1
5. 若關系模式是1：1：n的聯系，轉換原則同1：n
6. 若關系模式是1：n：m的聯系，則可以將聯系類型也轉換成關系模式，其屬性為m端和n端實體類型的主鍵（作為外鍵）加上聯系類型自身的屬性，而關系模式的主鍵為n和m端實體主鍵的組合
7. 若關系模式是n:m:p的聯系，轉換規則同m:n

根據E-R圖實體之間的聯系可以轉換成以下關系模式：

客戶（客戶編號，姓名，電話，E-mail）。關系的主鍵：客戶編號；外鍵：無

訂單（訂單編號，訂購時間，客戶編號）。關系的主鍵：訂單編號；外鍵：客戶編號

訂購細目（訂購明細編號，訂購數量，支付金額，訂單編號）。關系主鍵：訂購明細編號；外鍵：訂單編號。

出現（訂購明細編號，商品編號，類型）。關系的主鍵：訂購明細編號，商品編號；外鍵：訂購明細編號，商品編號。

商品：（商品編號，商品名稱，單價，生產日期，商品類別號，商品類別名）。關系的主鍵：商品編號；外鍵：無

在關系模式設計中可能會出現以下幾個問題：數據冗余、數據修改不一致、數據插入異常、數據刪除異常，所以提出范式的要求，目的就是最低限度地冗余，避免插入、刪除、修改異常。

主屬性：包含鍵的所有屬性。

• 關系模式要求達到4NF （減少冗余，消除操作異常）

第一范式（1NF）：若關系模式R的每一個分量是不可分的數據項，則關系模式屬于第一范式。即每個屬性都是不可拆分的.

第二范式(2NF)：R屬于1NF,且每一個非主屬性完全依賴于鍵（沒有部分依賴），則R屬于2NF

例如：選課關系(學號，課程號，成績，學分)

該關系的主鍵是（學號，課程號），但是課程號→學分，所以學分屬性部分依賴于主鍵，即關系部滿足第二范式，可以拆分為（學號，課程號，成績），（課程號，學分）兩個關系

第三范式(3NF)：R屬于2NF,且每個非主屬性即不部分依賴于碼，也不傳遞依賴于碼

例如：學生關系（學號，姓名，所屬系，系地址）

該關系的主鍵是:學號

學號→所屬系，所屬系→學號，所屬系→系地址；根據函數的依賴公理，系地址傳遞函數依賴于學號，即關系不滿足第三范式，可以拆分關系為（學號，姓名，所屬系），（所屬系，系地址）

如果不拆分會存在數據修改異常，比如該學生的換了系，修改了所屬系，但是系地址沒有修改，這樣就造成了修改異常

BCNF：R屬于3NF,且不存在主屬性對碼的部分和傳遞函數依賴

例如：關系R（零件號，零件名，廠商名），如果設定每種零件號只有一個零件名，但不同的的零件號可以有相同的零件名，每種零件可以有多個廠商生產，但每家廠商生產的零件應有不同的零件名。這樣可以得到：

零件號→零件名，（廠商名，零件名）→零件號

所以主屬性包括（零件號，廠商名，零件名），但是“零件名”傳遞依賴于碼“廠商名，零件名”，所以關系R不滿足BCNF，當一個零件由多個生產廠商生產時，由于零件號只有一個而零件名根據廠商不同而又多個，零件名與零件號之間的聯系將多次重復，帶來數據冗余和操作異?，F象

可以將關系分解為（零件號，廠商名），（零件號，零件名）

4NF：關系模式R屬于1NF,若對于R的每個非平凡多值依賴X→→Y且Y不包含于X時，X必含碼，則R屬于4NF

5NF:對關系進行投影，消除關系中不是由候選碼所蘊含的連接依賴

對于上面的商品關系，由于關系的主鍵是商品編號，而商品類別號→商品類別名

所以商品關系部滿足第三范式，非主屬性商品類別名傳遞依賴于商品編號，會存在數據冗余，數據修改異常問題。將商品關系分解為：

商品（商品編號，商品名稱，單價，生產日期，商品類別號）

商品類別（商品類別號，商品類別名）

為一個給定的邏輯數據模型設計一個最合適應用要求的物理結構的過程

• 數據庫的建立
• 數據表的建立
• 索引的建立
• 視圖的建立
• 觸發器的建立
• 存儲過程設計
• 用戶自定義函數設計
• 對關系模式的數據項加以約束，如檢查約束、主鍵約束、參照完整性約束以保證數據正確性

采用高級語言以結構化設計方法或面向對象方法進行設計

1. 盡可能地減少多表查詢或建立物化視圖
2. 只檢索需要的列
3. 用帶IN的條件字句等級替換or字句
4. 經常提交COMMIT，以盡早釋放鎖

1.如果頻繁地訪問涉及的是對兩個相關的表進行連接操作，則考慮將其合并

2.如果頻繁地訪問只是在表中的某一部分字段上進行，則考慮分解表，將該部分單獨作為一個表

3.對于很少更新的表，引入物化視圖

4. 當系統中有一些少量的，重復出現的值時，使用字典表來節約存儲空間和優化查詢。如地區、系統中用戶類型的代號等。這類值不會在程序的運行期變化，但是需要存儲在數據庫中。

就地區而言，如果我們要查詢某個地區的記錄，則數據庫需要通過字符串匹配的方式來查詢；如果將地區改為一個地區的代號保存在表中，查詢時通過地區的代號來查詢，則查詢的效率將大大提高。

程序中宜大量的使用字典表來表示這類值。字典表中保存這類值的代號和實體的集合，以外鍵的方式關聯到使用這類值的表中。然而，在編碼階段，程序員并不使用字典表，因為首先查詢字典表中實體的代號，違背了提高查詢效率的初衷。程序員在數據字典的幫助下，直接使用代號來代表實體，從而提高效率。

雖然字典表在實際上并不使用，但是仍應該保留在數據庫中（起碼是在開發期內保留）。字典表作為另一種形式上的“數據字典文檔”出現，以說明數據庫中哪些表的哪些字段是使用了字典表的。

為了提高數據庫的數據完整性，在開發階段可以保留完整的字典表和普通表的外鍵約束。但是在數據庫的運行階段，應該將普通表和字典表的外鍵刪除，以提高運行效率，特別是某些表使用了很多字典表的情況。

案例：某數據庫中有百萬條用戶信息，應用系統中常常需要按照地區要查詢用戶的信息。用戶信息表以前是按照具體的地區名稱來保存的，現在將具體的名稱改為字典表中的地區代號，查詢效率大大提高。

1. 如果查詢是瓶頸，則在關系上建立適當的索引；通常，作為查詢條件的屬性上建立索引可以提高查詢效率。
2. 如果更新是瓶頸，因為每次更新都會重建表上的索引，引起效率降低，則考慮刪除某些索引。
3. 選擇適當索引，如果經常使用范圍查詢，則B樹索引比散列索引更高效
4. 將有利于大多數查詢和更新的索引設為聚集性索引。

1. 索引文件和數據文件分開存儲，事務日志文件存儲在高速設備上
2. 經常修改數據文件和索引文件的頁面大小
3. 定期對數據進行排序
4. 增加必要的索引項

數據庫對象采用26個英文字母（區分大小寫）和0－9這十個自然數，加上下劃線_組成，共63個字符。不能出現其他字符（注釋除外）。

同一個數據庫中這些對象名都是不能重復

C CHECK_CONSTRAINT

D DEFAULT_CONSTRAINT

F FOREIGN_KEY_CONSTRAINT

IT INTERNAL_TABLE

P SQL_STORED_PROCEDURE

PK PRIMARY_KEY_CONSTRAINT

S SYSTEM_TABLE

SQ SERVICE_QUEUE

TR SQL_TRIGGER

U USER_TABLE

UQ UNIQUE_CONSTRAINT

V VIEW

1.表名使用單數名

例如：對存儲客人信息的表（Customer）不使用Customers

2.避免無謂的表格后綴

1、 表是用來存儲數據信息的,表是行的集合。那么如果表名已經能夠很好地說明其包含的數據信息，就不需要再添加體現上面兩點的后綴了。

2、 GuestInfo(存儲客戶信息)應寫成Guest，FlightList（存儲航班信息的表）應寫成Flight

3.所有表示時間的字段，統一以 Date 來作