資料庫設計（Database Design)是指對於一個給定的應用環境，構造最優的資料庫模式，建立資料庫及其應用系統，使之能夠有效地儲存資料，滿足各種使用者的應用需求（資訊要求和處理要求）。

一、資料庫設計的原則

1.      表設計原則

（1）規範化與反規範化

規範化的優點是減少了資料冗餘，節約了儲存空間，相應邏輯和物理的I/O次數減少，同時加快了增、刪、改的速度。但是一個完全規範化的設計並不總能生成最優的效能，因為對資料庫查詢通常需要更多的連線操作，從而影響到查詢的速度，而且正規化越高效能就會越差。出於效能和方便管理的考慮，原則上表設計應滿足第三正規化。有時為了提高某些查詢或應用的效能而可以破壞規範規則，即反規範化。

資料應當按兩種類別進行組織：頻繁訪問的資料和頻繁修改的資料。對於頻繁訪問但是不頻繁修改的資料，內部設計應當物理不規範化。對於頻繁修改但並不頻繁訪問的資料，內部設計應當物理規範化。比較複雜的方法是將規範化的表作為邏輯資料庫設計的基礎，然後再根據整個應用系統的需要，物理地非規範化資料。

（2）資料表分類說明

    根據應用的實際需要和特點，可以將資料表進行如下分類：

l        基本資料表：描述業務實體的基本資訊。例如，人員基本資訊、單位基本資訊等。

l        標準編碼表：描述屬性的列表值。例如，職稱、民族、狀態等。

l        業務資料表：記錄業務發生的過程和結果。例如，人員調動登記、變更通知單等。

l        系統資訊表：存放與系統操作、業務控制有關的引數。例如，使用者資訊、許可權、使用者配置資訊等。

l        統計資料表：存放業務資料統計值。例如，通知單統計、人員類別統計等。

l        臨時處理表：存放業務處理過程中的中間結果。

l        其他型別表：存放應用層的日誌、訊息記錄等。

2.      欄位設計原則

（1）一般來說，應該使用能正確儲存和表示資料的最小型別。如果不確定需要什麼資料型別，則選擇不會超出範圍的最小型別。

（2）選擇更簡單的資料型別。例如，比較整數的代價小於比較字元，因為字符集和排序規則使字元比較更復雜。

（3）儘可能把欄位定義為 NOT NULL。對於欄位能否NULL，應該在SQL建表指令碼中明確指明，不應使用預設。

（4）一個表中的欄位不要太多，理論上不要超過80個。

（5）資料庫中所有布林型中數值0表示為假；數值1表示為真

（6）當欄位定義為字串型別時使用VARCHAR2而不用NVARCHAR

（7）欄位儘可能有預設值，字元型的預設值為一個空字元值串，數字型的預設值為數值0。

3.      鍵設計原則

（1）為關聯欄位建立外來鍵。

（2）所有的鍵都必須唯一。

（3）儘可能避免使用複合鍵。

（4）外來鍵總是關聯唯一的鍵欄位。

（5）儘可能使用系統生成（如序列SEQUENCE產生）的主鍵。

（6）可選鍵有時可做主鍵。

（7）一個表中組合主鍵的欄位個數儘可能少。

4.      索引設計原則

（1）如果一列出現在表示式或函式中，不會使用該列上的索引

（2）要索引外來鍵

（3）對於索引選擇性高的列使用B-Tree索引

（4）對於索引選擇性低的列使用點陣圖索引

（5）HASH索引只適用於相等比較

（6）不要索引大型欄位（有很多字元的欄位）

（7）不要索引常用的小型表

5.      LOB設計原則

如無特別需要，避免使用大欄位（BLOB、CLOB、LONG等）。如使用時必須使用BLOB或CLOB型別。

二、完整性設計

採用資料庫系統實現資料的完整性。這不但包括通過標準化實現的完整性而且還包括資料的功能性。在寫資料的時候還可以增加觸發器來保證資料的正確性。不要依賴於應用程式保證資料完整性，它不能保證表之間（外來鍵）的完整性。

1．主鍵約束

每個表要求有主健，主健欄位或組合欄位必須滿足非空屬性和唯一性要求。

2．外來鍵約束

（1）對於關聯兩個表的欄位，一般應該分別建立主鍵、外來鍵。實際是否建立外來鍵，根據對資料完整性的要求決定。

（2）根據需要適當設定父表資料修改時對子表的影響：

l        父表中刪除資料：級聯刪除；受限刪除；置空值。

l        父表中插入資料：受限插入；遞迴插入。

l        父表中更新資料：級聯更新；受限更新；置空值。

3．NULL值

由於NULL值在參加任何運算時，結果均為NULL，所以必須利用NVL()函式把可能為NULL值得欄位或變數轉換為非NULL的預設值。

4．CHECK條件

對於欄位有檢查性約束，要求指定CHECK規則。

5．觸發器

觸發器是一種特殊的儲存過程，通過對錶的DML操作而觸發執行，是為確保資料的完整性和一致性不被破壞而建立，實現資料的完整約束。選擇觸發器的BEFORE或AFTER事務屬性的時候，對錶操作的事務屬性必須與應用程式事務屬性保持一致，以避免死鎖發生。在大量修改資料時，儘量避免使用觸發器。

6．檢視

為了在資料庫和應用程式之間提供另一層抽象，可以為應用程式建立專門的檢視而不必非要應用程式直接訪問表。這樣做還在處理資料庫變更時提供了更多的自由。檢視是虛擬的資料庫表，在使用時要遵循以下原則：

l        為簡化查詢，將複雜的檢索或子查詢通過檢視實現。

l        提高資料的安全性，只將需要檢視的資料資訊顯示給許可權有限的人員。

l        檢視中如果巢狀使用檢視，級數不要超過3級。

l        由於檢視中只能固定條件或沒有條件，所以對於資料量較大或隨時間的推移逐漸增多的表，不宜使用檢視，可以採用實體化檢視代替。

l        除特殊需要，避免類似SELECT * FROM [TableName] 而沒有檢索條件的檢視。

l        檢視中儘量避免出現數據排序的SQL語句。

三、命名規範

1．總則

（1）所有命名採用26個英文大小寫字母和0－9這十個自然數，加上下劃線_組成。不能出現其他字元（註釋除外）。

（2）長度不超過30個字元。

（3）實際名字儘量描述實體的內容，由英文單詞、單詞組合或單詞縮寫組成，不以數字和_開頭。

（4）命名中禁止使用SQL關鍵字。

（5）物件名儘量短。

2．表

表以單數形式名詞或名詞短語命名。如果表名僅有一個單詞，那麼建議不使用縮寫，而是用完整的單詞。

資料表     t_inf_<系統標識>_<表標識>

編碼表     t_cod_<系統標識>_<表標識>

系統表    t_sys_<系統標識>_<表標識>

統計表     t_sta_<系統標識>_<表標識>

臨時表     t_tmp_<系統標識>_<表標識>

日誌表     t_log_<系統標識>_<表標識>

3．欄位

l        採用有意義的欄位名，應該是易於理解，能表達欄位功能的英文單詞或單詞縮寫，一般不超過三個英文單詞。

l        系統中所有屬於內碼的欄位（僅用於表示唯一性和程式內部用到的標識性欄位），名稱取為：ID。

l        系統中屬於是業務範圍內的編號的欄位，其代表一定的業務資訊，這樣的欄位建議命名為CODE，其資料型別為VARCHAR，該欄位需加唯一索引。

l        欄位名不要與表名重複

l        不要在列的名稱中包含資料型別。

4．主鍵

PK_<表名>

5．外來鍵

FK_<表名>_<主表名>_<外來鍵欄位名>

6．索引

IDX_<表名>_<構成索引的欄位名>

如果複合索引的構成欄位較多，則只包含第一個欄位，並新增序號。

7．檢視

V_<系統標識>_<檢視標識>

8．儲存過程

SP_<系統標識>_<儲存過程標識>

9．函式

F_<系統標識>_<函式標識>

10．            觸發器

TR_<表名>_<i、u、d的任意組合>

11．            使用者定義資料型別

UD_<自定義資料型別標識>

12．            序列

SEQ_<序列標識>

13．            區域性變數

L_<變數標識>

14．            全域性變數

G_<變數標識>

15．            遊標變數

L_CUR_<變數標識>或G_CUR_<變數標識>

16．            儲存過程或函式定義中的引數

IN型引數：P_<引數標識>

OUT型引數：R_<引數標識>

函式返回值：R_<變數標識>

四、安全性設計

1．管理預設使用者

在生產環境中，必須嚴格管理SYS和SYSTEM使用者，必須修改其預設密碼，禁止用該使用者建立應用資料庫物件。刪除或鎖定SCOTT等預設安裝但不使用的使用者。

2．資料庫級使用者許可權設計

必須按照應用需求，設計不同的使用者訪問許可權。包括應用系統管理使用者，普通使用者等，按照業務需求建立不同的應用角色。使用者訪問另外的使用者物件時，應該通過建立同義詞物件SYNONYM進行訪問。

3．角色與許可權

確定每個角色對資料庫表的操作許可權，如建立、檢索、更新、刪除等。每個角色擁有剛好能夠完成任務的許可權，不多也不少。在應用時再為使用者分配角色，則每個使用者的許可權等於他所兼角色的許可權之和。

4．應用級使用者設計

應用級的使用者帳號密碼不能與資料庫相同，防止使用者直接操作資料庫。使用者只能用帳號登入到應用軟體，通過應用軟體訪問資料庫，而沒有其它途徑操作資料庫。

5．使用者密碼管理

使用者帳號的密碼必須進行加密處理，確保在任何地方查詢都不會出現密碼的明文。

五、SQL語句編寫

1．字元型別資料

SQL中的字元型別資料應該統一使用單引號。特別對純數字的字串，必須用單引號，否則會導致內部轉換而引起效能問題或索引失效問題。利用TRIM(),LOWER()等函式格式化匹配條件。

2．複雜SQL

對於非常複雜的SQL（特別是有多層巢狀，帶子句或相關子查詢的），應該先考慮是否設計不當引起的。對於一些複雜SQL可以考慮使用程式實現。

3．避免IN子句

使用 IN 或 NOT IN 子句時，特別是當子句中有多個值且表資料較多時，速度會明顯下降。可以採用連線查詢或外連線查詢來提高效能。

4．避免使用SELECT * 語句

如果不必要取出所有資料，不要用 * 來代替，應給出欄位列表。

5．避免不必要的排序

不必要的資料排序大大的降低系統性能。

6．INSERT語句

使用INSERT語句一定要給出插入值的欄位列表，這樣即使表加了欄位也不會影響現有系統的執行。

7．多表連線

做多表操作時，應該給每個表取一個別名，每個表字段都應該標明其所屬哪個表。

8．引數的傳遞

SQL語句的編寫，變數儘量使用“?”繫結變數。

9．儲存過程、函式中的註釋，示例如下：

/*

目的：

作者：

建立日期：

*/

/*

修改順序號：

修改者：

修改日期：

修改原因：（具體原因詳細描述）

*/

六、建模管理方法

1．建模工具

統一使用PowerDesigner軟體建模。推薦版本PowerDesigner 15中文版。

2．建模步驟

（1）邏輯建模

根據資料庫設計和命名規範先在PowerDesigner中建立邏輯模型(LDM)檔案。要求每個表和欄位都要有註釋說明；Check Model不能出現錯誤。

（2）根據邏輯模型檔案建立對應資料庫的物理模型檔案。

（3）生成資料庫結構及其相應的SQL指令碼。

3．模型維護

（1）所有關於資料庫的表、欄位及關係、說明等均以物理模型檔案為準。

（2）由開發人員將變更需求提交專案負責人審批。

（3）專案負責人同意變更後由相應開發人員負責編寫變更指令碼提交DBA。

（4）DBA更新資料庫及其相關文件，並維護所有部分的一致性。

七、其他設計技巧

1．避免使用觸發器

觸發器的功能通常可以用其他方式實現。在除錯程式時觸發器可能成為干擾。假如確實需要採用觸發器，最好集中對它文件化。

2．儲存常用資訊

讓一個表專門存放一般資料庫資訊非常有用。在這個表裡存放資料庫當前版本、最近檢查/修復、關聯設計文件的名稱、客戶等資訊。這樣可以實現一種簡單機制跟蹤資料庫。

3．包含版本機制

在資料庫中引入版本控制機制來確定使用中的資料庫的版本。時間一長，使用者的需求總是會改變的。最終可能會要求修改資料庫結構。把版本資訊直接存放到資料庫中更為方便。

4．編制文件

對所有的命名規範、限制、資料字典、儲存過程、函式都要編制文件。採用給表、列、觸發器等加註釋的資料庫工具。對開發、支援和跟蹤修改非常有用。對資料庫文件化也會大大減少犯錯的機會。

5．測試、測試、反覆測試

建立或者修訂資料庫之後，必須用使用者新輸入的資料測試修改的欄位。最重要的是，讓使用者進行測試並且同用戶一起保證選擇的資料型別滿足要求。測試需要在把新資料庫投入實際服務之前完成。

6．檢查設計

在開發期間檢查資料庫設計的常用技術是通過其所支援的應用程式原型檢查資料庫。換句話說，針對每一種最終表達資料的原型應用，保證檢查了資料模型並且檢視如何取出資料。