一、數據庫設計規范簡介

1、數據庫設計規范化的要求

A、表中應該避免可為空的列
B、表不應該有重復的值或者列
C、表中記錄應該有一個唯一的標識符
D、數據庫對象要有統一的前綴名
E、盡量只存儲單一實體類型的數據

2、數據庫設計規范化的目的

A、消滅重復數據。

B、避免編寫不必要的，用來使重復數據同步的代碼。

C、保持表的瘦身，以及減從一張表中讀取數據時需要進行的讀操作數量。

D、最大化聚集索引的使用，從而可以進行更優化的數據訪問和聯結。

E、減少每張表使用的索引數量，因為維護索引的成本很高。

二、數據庫表設計規范

1、規范化與反規范化

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

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

2、數據表分類說明

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

基本數據表：描述業務實體的基本信息。例如，人員基本信息、單位基本信息等。

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

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

系統信息表：存放與系統操作、業務控制有關的參數。例如，用戶信息、權限、用戶配置信息等。

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

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

其他類型表：存放應用層的日志、消息記錄等。

3、字段設計規范

（1）一般來說，應該使用能正確存儲和表示數據的最小類型。如果不確定需要什么數據類型，則選擇不會超出范圍的最小類型。

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

（3）盡可能把字段定義為NOT NULL。對于字段能否NULL，應該在SQL建表腳本中明確指明，不應使用缺省。

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

（5）數據庫中所有布爾型中數值0表示為假；數值1表示為真

（6）當字段定義為字符串類型時使用VARCHAR2而不用NVARCHAR

（7）字段盡可能有默認值，字符型的默認值為一個空字符值串，數字型的默認值為數值0。

4、鍵設計規范

（1）為關聯字段創建外鍵。

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

（3）盡可能避免使用復合鍵。

（4）外鍵總是關聯唯一的鍵字段。

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

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

（7）一個表中組合主鍵的字段個數盡可能少。

5、索引設計規范

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

（2）要索引外鍵

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

（4）對于索引選擇性低的列使用位圖索引

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

（6）不要索引大型字段（有很多字符的字段）

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

6、LOB設計規范

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

三、完整性設計規范

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

1、主鍵約束

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

2、外鍵約束

（1）對于關聯兩個表的字段，一般應該分別建立主鍵、外鍵。實際是否建立外鍵，根據對數據完整性的要求決定。

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

父表中刪除數據：級聯刪除；受限刪除；置空值。

父表中插入數據：受限插入；遞歸插入。

父表中更新數據：級聯更新；受限更新；置空值。

3、NULL值

由于NULL值在參加任何運算時，結果均為NULL，所以必須利用NVL()函數把可能為NULL值得字段或變量轉換為非NULL的默認值。

4、CHECK條件

對于字段有檢查性約束，要求指定CHECK規則。

5、觸發器

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

6、視圖

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

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

提高數據的安全性，只將需要查看的數據信息顯示給權限有限的人員。

視圖中如果嵌套使用視圖，級數不要超過3級。

由于視圖中只能固定條件或沒有條件，所以對于數據量較大或隨時間的推移逐漸增多的表，不宜使用視圖，可以采用實體化視圖代替。

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

視圖中盡量避免出現數據排序的SQL語句。

四、安全性設計規范規范

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語句的編寫，變量盡量使用“?”綁定變量。

六、數據庫設計命名規范

1、數據庫命名基本原則

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

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

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

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

（5）對象名盡量短。

2、數據庫對象命名規范

數據庫對象包括表、視圖（查詢）、存儲過程（參數查詢）、函數、約束。對象名字由前綴和實際名字組成，長度不超過30。

前綴：使用小寫字母加下劃線

表??????? tb_?
視圖??????? view_
存儲過程??? sp _
函數??????? fn_

觸發器 trig_

局部變量 l_?

全局變量 g_

3、表命名規范

約定：表名由前綴和實際名字組成。

前綴：使用小寫字母tb_，代表表。實際名字中，一個系統盡量采取同一單詞，多個后面加_來連接區分。

因此，合法的表名類似如下。

tb_Member

tb_MemberInfo

tb_ForumBoard

表

表名如Order/UserAccout

符合以下規范：

(1)統一采用單數形式，反對Orders

(2)首字母大寫，多個單詞的話，單詞首字母大寫，反對order/Useraccout/ORDER

(3)避免中文拼音，反對AgentBaoCi

(4)避免下劃線連接，反對User_Accout（下劃線適用Oracle數據庫）

(5)避免名稱過長，反對WebsiteInfomationModifyRecord

(6)多對多關系表，以Mapping結尾，如UserRoleMapping

(7)避免保留字

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

主鍵:PK_<表名>?

外鍵:FK_<表名>_<主表名>_<外鍵字段名>

索引:IDX_<表名>_<構成索引的字段名>

如果復合索引的構成字段較多，則只包含第一個字段，并添加序號。

4、字段命名規范

字段由表的簡稱，實際名字組組成。如果此字段關聯另外的字段，那么加下劃線_連接關聯表字段的字段名。

因此，合法的字段名類似如下。

UserID_MeID
UserName
UserRegDate

字段

字段名如userID/userName/userType

符合以下規范：

(1)首個字母小寫，多個單詞的話，單詞首字母大寫，反對UserID/Userid

(2)必須有一主鍵，主鍵不直接用ID，而是表名+ID，如userID/orderID

(3)常用的字段name，不直接用name，而是表名+Name，如userName/orderName

(4)常用的字段desc，不直接用desc，而是表名+Desc，如userDesc/orderDesc

(5)大寫字母前必須包含至少兩個小寫的字母，反對uID/oID

(6)避免中文拼音

(7)避免下劃線連接

(8)避免名稱過長

(9)避免保留字?

對象

(1)存儲過程以SP_為前綴

(2)觸發器以TR_為前綴

(3)函數以FN_為前綴

(4)主鍵以PK_為前綴

(5)索引以IX_為前綴

(6)前綴后的首字母大寫，多個單詞的話，單詞首字母大寫，如SP_CountFee

(7)所有的關鍵字的所有字母必須大寫，如SELECT userID,username FROM User

采用有意義的字段名，應該是易于理解，能表達字段功能的英文單詞或單詞縮寫，一般不超過三個英文單詞。

系統中所有屬于內碼的字段（僅用于表示唯一性和程序內部用到的標識性字段），名稱取為：ID。

系統中屬于是業務范圍內的編號的字段，其代表一定的業務信息，字段建議命名為CODE，其數據類型為VARCHAR，該字段需加唯一索引。

字段名不要與表名重復

不要在列的名稱中包含數據類型。

5、視圖命名規范

字段由前綴和實際名字組成，中間用下劃線連接。

前綴：使用小寫字母view，表示視圖。

因此，合法的視圖名類似如下。

view_User
view_UserInfo

6、存儲過程命名規范

約定：字段由前綴和實際名字加操作名字組成，中間用下劃線連接。

前綴：使用小寫字母sp，表示存儲過程。

操作名字：Insert|Delelte|Update|Caculate|Confirm

例如：

sp_User_Insert

7、SQL語句命名規范

約定：所有SQL關鍵詞全部大寫。

總結

以上是生活随笔為你收集整理的数据库设计（三）——数据库设计规范的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。