資料庫設計名

㈠ 資料庫三大範式

資料庫 的設計範式是資料庫 設計所需要滿足的規范，滿足這些規范的資料庫 是簡潔的、結構明晰的，同時，不會發生插入（insert）、刪除（delete）和更新（update）操作異常。反之則是亂七八糟，不僅給資料庫 的編程 人員製造麻煩，而且面目可憎，可能存儲了大量不需要的冗餘信息。

設計範式是不是很難懂呢？非也，大學教材上給我們一堆數學公式我們當然看不懂，也記不住。所以我們很多人就根本不按照範式來設計資料庫 。

實質上，設計範式用很形象、很簡潔的話語就能說清楚，道明白。本文將對範式進行通俗地說明，並以筆者曾經設計的一個簡單論壇的資料庫 為例來講解怎樣將這些範式應用於實際工程。

範式說明

第一範式（1NF）：資料庫 表中的欄位都是單一屬性的，不可再分。這個單一屬性由基本類型構成，包括整型、實數、字元型、邏輯型、日期型等。

例如，如下的資料庫 表是符合第一範式的：
欄位1 欄位2 欄位3 欄位4
而這樣的資料庫 表是不符合第一範式的：

欄位1 欄位2 欄位3 欄位4 欄位3.1欄位3.2
很顯然，在當前的任何關系資料庫 管理系統（DBMS）中，傻瓜也不可能做出不符合第一範式的資料庫 ，因為這些DBMS不允許你把資料庫 表的一列再分成二列或多列。因此，你想在現有的DBMS中設計出不符合第一範式的資料庫 都是不可能的。

第二範式（2NF）：資料庫 表中不存在非關鍵欄位對任一候選關鍵欄位的部分函數依賴（部分函數依賴指的是存在組合關鍵字中的某些欄位決定非關鍵欄位的情況），也即所有非關鍵欄位都完全依賴於任意一組候選關鍵字。

假定選課關系表為SelectCourse(學號, 姓名, 年齡, 課程名稱, 成績, 學分)，關鍵字為組合關鍵字(學號, 課程名稱)，因為存在如下決定關系：

(學號, 課程名稱) → (姓名, 年齡, 成績, 學分)

這個資料庫 表不滿足第二範式，因為存在如下決定關系：

(課程名稱) → (學分)

(學號) → (姓名, 年齡)

即存在組合關鍵字中的欄位決定非關鍵字的情況。

由於不符合2NF，這個選課關系表會存在如下問題：

(1) 數據冗餘：

同一門課程由n個學生選修，"學分"就重復n-1次；同一個學生選修了m門課程，姓名和年齡就重復了m-1次。

(2) 更新異常：

若調整了某門課程的學分，數據表中所有行的"學分"值都要更新，否則會出現同一門課程學分不同的情況。

(3) 插入異常：

假設要開設一門新的課程，暫時還沒有人選修。這樣，由於還沒有"學號"關鍵字，課程名稱和學分也無法記錄入資料庫 。

(4) 刪除異常：

假設一批學生已經完成課程的選修，這些選修記錄就應該從資料庫 表中刪除。但是，與此同時，課程名稱和學分信息也被刪除了。很顯然，這也會導致插入異常。

把選課關系表SelectCourse改為如下三個表：

學生：Student(學號, 姓名, 年齡)；

課程：Course(課程名稱, 學分)；

選課關系：SelectCourse(學號, 課程名稱, 成績)。

這樣的資料庫 表是符合第二範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。

另外，所有單關鍵字的資料庫 表都符合第二範式，因為不可能存在組合關鍵字。

第三範式（3NF）：在第二範式的基礎上，數據表中如果不存在非關鍵欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。所謂傳遞函數依賴，指的是如果存在"A → B → C"的決定關系，則C傳遞函數依賴於A。因此，滿足第三範式的資料庫 表應該不存在如下依賴關系：

關鍵欄位 → 非關鍵欄位x → 非關鍵欄位y

假定學生關系表為Student(學號, 姓名, 年齡, 所在學院, 學院地點, 學院電話)，關鍵字為單一關鍵字"學號"，因為存在如下決定關系：

(學號) → (姓名, 年齡, 所在學院, 學院地點, 學院電話)這個資料庫 是符合2NF的，但是不符合3NF，因為存在如下決定關系：

(學號) → (所在學院) → (學院地點, 學院電話)

即存在非關鍵欄位"學院地點"、"學院電話"對關鍵欄位"學號"的傳遞函數依賴。

它也會存在數據冗餘、更新異常、插入異常和刪除異常的情況，讀者可自行分析得知。

把學生關系表分為如下兩個表：

學生：(學號, 姓名, 年齡, 所在學院)；

學院：(學院, 地點, 電話)。

這樣的資料庫 表是符合第三範式的，消除了數據冗餘、更新異常、插入異常和刪除異常。

鮑依斯-科得範式（BCNF）：在第三範式的基礎上，資料庫 表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函數依賴則符合第三範式。

假設倉庫管理關系表為StorehouseManage(倉庫ID, 存儲物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以存儲多種物品。這個資料庫 表中存在如下決定關系：

(倉庫ID, 存儲物品ID) →(管理員ID, 數量)

(管理員ID, 存儲物品ID) → (倉庫ID, 數量)

所以，(倉庫ID, 存儲物品ID)和(管理員ID, 存儲物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵欄位為數量，它是符合第三範式的。但是，由於存在如下決定關系：

(倉庫ID) → (管理員ID)

(管理員ID) → (倉庫ID)

即存在關鍵欄位決定關鍵欄位的情況，所以其不符合BCNF範式。它會出現如下異常情況：

(1) 刪除異常：

當倉庫被清空後，所有"存儲物品ID"和"數量"信息被刪除的同時，"倉庫ID"和"管理員ID"信息也被刪除了。

(2) 插入異常：

當倉庫沒有存儲任何物品時，無法給倉庫分配管理員。

(3) 更新異常：

如果倉庫換了管理員，則表中所有行的管理員ID都要修改。

把倉庫管理關系表分解為二個關系表：

倉庫管理：StorehouseManage(倉庫ID, 管理員ID)；

倉庫：Storehouse(倉庫ID, 存儲物品ID, 數量)。

這樣的資料庫 表是符合BCNF範式的，消除了刪除異常、插入異常和更新異常。
範式應用

我們來逐步搞定一個論壇的資料庫 ，有如下信息：

（1） 用戶：用戶名，email，主頁，電話，聯系地址

（2） 帖子：發帖標題，發帖內容，回復標題，回復內容

第一次我們將資料庫 設計為僅僅存在表：
用戶名 email 主頁電話聯系地址發帖標題發帖內容回復標題回復內容
這個資料庫 表符合第一範式，但是沒有任何一組候選關鍵字能決定資料庫 表的整行，唯一的關鍵欄位用戶名也不能完全決定整個元組。我們需要增加"發帖ID"、"回復ID"欄位，即將表修改為：

用戶名email主頁電話聯系地址發帖ID發帖標題發帖內容回復ID回復標題回復內容
這樣數據表中的關鍵字(用戶名，發帖ID，回復ID)能決定整行：

(用戶名,發帖ID,回復ID) → (email,主頁,電話,聯系地址,發帖標題,發帖內容,回復標題,回復內容)

但是，這樣的設計不符合第二範式，因為存在如下決定關系：

(用戶名) → (email,主頁,電話,聯系地址)

(發帖ID) → (發帖標題,發帖內容)

(回復ID) → (回復標題,回復內容)

即非關鍵欄位部分函數依賴於候選關鍵欄位，很明顯，這個設計會導致大量的數據冗餘和操作異常。

我們將資料庫 表分解為（帶下劃線的為關鍵字）：

（1） 用戶信息：用戶名，email，主頁，電話，聯系地址

（2） 帖子信息：發帖ID，標題，內容

（3） 回復信息：回復ID，標題，內容

（4） 發貼：用戶名，發帖ID

（5） 回復：發帖ID，回復ID

這樣的設計是滿足第1、2、3範式和BCNF範式要求的，但是這樣的設計是不是最好的呢？

不一定。

觀察可知，第4項"發帖"中的"用戶名"和"發帖ID"之間是1：N的關系，因此我們可以把"發帖"合並到第2項的"帖子信息"中；第5項"回復"中的"發帖ID"和"回復ID"之間也是1：N的關系，因此我們可以把"回復"合並到第3項的"回復信息"中。這樣可以一定量地減少數據冗餘，新的設計為：（1） 用戶信息：用戶名，email，主頁，電話，聯系地址

（2） 帖子信息：用戶名，發帖ID，標題，內容

（3） 回復信息：發帖ID，回復ID，標題，內容

資料庫 表1顯然滿足所有範式的要求；

資料庫 表2中存在非關鍵欄位"標題"、"內容"對關鍵欄位"發帖ID"的部分函數依賴，即不滿足第二範式的要求，但是這一設計並不會導致數據冗餘和操作異常；

資料庫 表3中也存在非關鍵欄位"標題"、"內容"對關鍵欄位"回復ID"的部分函數依賴，也不滿足第二範式的要求，但是與資料庫 表2相似，這一設計也不會導致數據冗餘和操作異常。

由此可以看出，並不一定要強行滿足範式的要求，對於1：N關系，當1的一邊合並到N的那邊後，N的那邊就不再滿足第二範式了，但是這種設計反而比較好！

對於M：N的關系，不能將M一邊或N一邊合並到另一邊去，這樣會導致不符合範式要求，同時導致操作異常和數據冗餘。
對於1：1的關系，我們可以將左邊的1或者右邊的1合並到另一邊去，設計導致不符合範式要求，但是並不會導致操作異常和數據冗餘。

㈡ 那位有完整的資料庫命名規范給一份,跪等

資料庫設計過程中命名規范很是重要，命名規范合理的設計能夠省去開發人員很多時間去區別資料庫實體。

資料庫物理設計包括：表設計，視圖設計，存儲過程設計，用戶自定義函數設計等等。

1、 表設計命名規范：表使用t開頭最好能將表根據屬性分類並作好編號。

如：編碼表可寫為tBM001Something t為表開頭，BM為業務類型，001為該類別中的第幾個表something是表的名稱注釋。

2、 視圖設計命名規范：視圖設計過程中使用v開頭，視圖命名以製作視圖的主表為准或是以視圖的實現功能為准。

如：上述tBM001Something 為主表製作的視圖 可取名vBM001Something

或者vGetSomeThingInfo等。

3、存儲過程命名規范：用戶自定義存儲過程使用p開頭以其實現功能命名,

如：pGetSomethingInfo

4、

存儲過程命名規范：用戶自定義存儲過程使用f開頭以其實現功能命名,

如：fGetSomethingInfo

此外在製作視圖存儲過程用戶自定義函數過程中，注意寫好注釋。

還有
一．實體和屬性的命名

1． 常用單詞已經進行了縮寫，在命名過程當中，根據語義拼湊縮寫即可。注意，由於ORCAL資料庫會將欄位名稱統一成大寫或者小寫中的一種，所以要求加上下劃線
舉例：
定義的縮寫 Sales: Sal 銷售；
Order: Ord 訂單；
Detail: Dtl 明細；
則銷售訂單名細表命名為：Sal_Ord_Dtl;

2． 如果表或者是欄位的名稱僅有一個單詞，那麼建議不使用縮寫，而是用完整的單詞。
舉例：
定義的縮寫 Material Ma 物品；
物品表名為：Material, 而不是 Ma.
但是欄位物品編碼則是：Ma_ID;而不是Material_ID

3． 所有的存儲值列表的表前面加上前綴Z
目的是將這些值列表類排序在資料庫最後。

4． 所有的冗餘類的命名(主要是累計表)前面加上前綴X
冗餘類是為了提高資料庫效率，非規范化資料庫的時候加入的欄位。或者表

5． 關聯類通過用下劃線連接兩個基本類之後，再加前綴R的方式命名,後面按照字母順序羅列兩個表名或者表名的縮寫。
關聯表用於保存多對多關系。
如果被關聯的表名大於10個字母，必須將原來的表名的進行縮寫。如果沒有其他原因，建議都使用縮寫。
舉例：表Object與自身存在多對多的關系,則保存多對多關系的表命名為：R_Object；
表 Depart和Employee;存在多對多的關系；則關聯表命名為R_Dept_Emp

6． 每一個表都將有一個自動ID作為主健,邏輯上的主健作為第一組候選主健來定義,如果是資料庫自動生成的編碼，統一命名為：ID;如果是自定義的邏輯上的編碼則用縮寫加「ID」的方法命名。
舉例：銷售訂單的編號欄位命名：Sal_Ord_ID；如果還存在一個資料庫生成的自動編號，則命名為：ID。

7． 所有的屬性加上有關類型的後綴，類型後綴的縮寫定義見文件《類型後綴縮寫定義》，注意，如果還需要其它的後綴，都放在類型後綴之前。

二．關系的命名
關系的命名基本上按照;如有特殊情況,可以靈活處理．
[must/may/can/should][verb/verb+prep][a/many/exatly num][or a/many]的結構命名

三．域的命名

四．觸發器的命名

五．有關於默認的幾點說明
1． 嚴格依賴關系的主細表，主表的後綴Main可以不寫。
2． 數據類型是文本的欄位，類型後綴TX可以不寫。
3． 有些類型比較明顯的欄位，可以不寫類型後綴。
4． 非常明顯的關系,可以不寫。

㈢ 資料庫設計中姓名性別學號班級等的數據類型

這要看你存儲的數據的總體情況來看，一般
姓名：varchar（50）考慮少數民族人的名字特別長
性別：char（2）如果寫中文男或者女，一個漢字是兩個字元，所以長度為2，如果是英文F（female）M（male）表示那麼用char（1）就夠了，如果用全稱那就要用varchar（6）了
學號：要看你要錄入的學號具體有多長，比如有的學校的學號是2007111222333444，那就要要char（16），班級也一樣
總的來說就要看你實際存儲的數據要多長才能知道要什麼數據類型