二：第二范式:在第一范式的基礎上建立起來的。要求數據庫表中的每個實例或行必須可以被惟一地區分。通常需要為表加上一個列，以存儲各個實例的惟一標識。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。像上面的Regulations的ID列就是一個身份標識列(identity)。
三：第三范式:要求一個數據庫表中不包含已在其它表中已包含的非主關鍵字信息。例如：上面有了一個文件表 Regulations,如果這個表是存儲的主文件，它相應的還有n個附件信息的話，我們就需要創建另外一張附件表來存儲附件。兩表如何聯系起來呢，我們可以把主文件表的主鍵隨同附件信息做為一條記錄插入到附件表中，這里插入的主文件表信息中只包含了主鍵ID，并沒有插入其它信息，這種關系就滿足了第三范式要求。
create table Attachment (
ID int identity,
FileID int null,//主文件主鍵ID
Address varchar(255) null,
Title nvarchar(200) null,
constraint PK_ATTACHMENT primary key (ID)
)
最后來總結了我這個項目中的具體應用：
第一：啟用數據字典理念來提高開發效率。什么是數據字典這里我不多說，大家不知道的可以網上搜索下。在一個項目中有時會遇到非常多的選項，就是供表單選擇某些小數據項的內容，請看下面的圖：
每一個模塊在插入記錄時都或多或少有這樣的選項，如果每一張表都建一個對應的選項表的話，維護進來工作量相當大，所有可以把這些小數據量的選項存儲到一張表，數據字典表如下：
下面是數據字典的數據展示圖:
第二：對數據庫表字段數據類型的設置有了進一步認識。
1:SQL有一種特殊的數據類型;Unicode 數據類型,包括 Nchar,Nvarchar 和Ntext 傳統的非 Unicode 數據類型允許使用由特定字符集定義的字符。使用 Unicode 數據類型，列中可以存儲任何由Unicode 標準定義的字符。在 Unicode 標準中，包括了以各種字符集定義的全部字符。使用Unicode數據類型，所占用的空間是使用非 Unicode 數據類型的兩倍。當列的長度變化時，應該使用Nvarchar 字符類型。當列的長度固定不變時，應該使用 Nchar 字符類型。我們在表單驗證時，用戶有時會輸入英文和中文混合文字，為了驗證方便，可以將這種情況時的字段設置成Unicode 。
2:對于非Unicode 數據,盡量選擇相對應的類型,例如手機號碼一般都是數字組成，且長度基本固定，設置成char(15)就行,email設置成varchar(100)就行。
第三：如何靈活利用一對多關系。一對多的關系非常常見，但如果加以靈活應用有時效果更佳。
例如，上面的圖中有一個了解管道的選項，它和對應的主表是一對多的關系，如果這個選項在不同的模塊中出現，我們是否需要為每個主表建立一個一對多關系呢?我選擇做一個中間關系表。我們可以把所有模塊中包含了了解管道選項的主表與這個中間關系表聯系起來，這樣就只用維護這一個關系表就行了，節約不少時間。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
