????? 最近做了一個小項目完整的數據庫設計,想總結一些設計上的所得,希望大家多多指教。

????? 有時一個項目，普通程序員一般不會去接觸數據庫設計，一般都有專業的DBA或是老程序員去設計，下面是我推測的幾點可能原因：
????? 1：新手對項目了解不深，正好這是老鳥的長處。
????? 2：新手對局部的關注往往大于整體，很難考慮的特別周全。
????? 3：數據庫設計的好壞在某種程度上直接影響項目的復雜度以及性能。

????? 第一：我們要知道什么是范式，為什么說到數據庫設計總要提到一個名詞：范式。范式：符合某一種級別的關系模式的集合。設計數據庫必須遵循一定的規則,在關系數據庫中，這種規則就是范式。

????? 第二：范式的分類。關系數據庫中的關系必須滿足一定的要求，目前關系數據庫有六種范式：第一范式、第二范式、第三范式、第四范式、第五范式和第六范式。滿足最低要求的是第一范式，其余范式以次類推。這么多的分類并不一定要求全部滿足，平時我們通常是達到第三范式就行。
?????? 第三：范式的作用？
??????? 1:優點：是將其轉化為一些表的過程，這種方法可以使從數據庫得到的結果更加明確。
??????? 2:缺點：可能使數據庫產生重復數據，從而導致創建多余的表。
??????? 3:是在識別數據庫中的數據元素、關系，以及定義所需的表和各表中的項目這些初始工作之后的一個細化的過程。
??????? 4:設計范式是數據庫設計所需要滿足的規范，滿足這些規范的數據庫是簡潔的、結構明晰的，也不會發生插入、刪除和更新操作異常。反之則給編程人員制造麻煩，可能存儲了大量不需要的冗余信息。?

????? 下面來簡單介紹下前三種范式：
?????? 一：第一范式。是對關系模式的基本要求，不滿足第一范式的數據庫就不是關系數據庫。 所謂第一范是指數據庫表的每一列都是不可分割的基本數據項，同一列中不能有多個值，即實體中的某個屬性不能有多個值或者不能有重復的屬性。如果出現重復的屬性，就可能需要定義一個新的實體，新的實體由重復的屬性構成，新實體與原實體之間為一對多關系。這個單一屬性由基本類型構成，包括整型、實數、字符型、邏輯型、日期型等。 例如有一張存儲文件的表,正確應該是這樣：可以看到這個表包含了好幾個列，如果我們把這些信息都放在一列里面那么就不滿足上面定義的1NF了。

create?table?Regulations?(
???ID???????????????????int??????????????????identity,
???Title????????????????nvarchar(200)????????null,
???FileAddress??????????varchar(255)?????????null,
???OpenDate?????????????datetime?????????????null,
???TypeID???????????????int??????????????????null,
???PostDate?????????????datetime?????????????null,
???constraint?PK_REGULATIONS?primary?key?(ID)
)

???

?????? 二：第二范式:在第一范式的基礎上建立起來的。要求數據庫表中的每個實例或行必須可以被惟一地區分。通常需要為表加上一個列，以存儲各個實例的惟一標識。這個惟一屬性列被稱為主關鍵字或主鍵、主碼。像上面的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)就行。

????? 第三：如何靈活利用一對多關系。一對多的關系非常常見，但如果加以靈活應用有時效果更佳。
????????? 例如，上面的圖中有一個了解管道的選項，它和對應的主表是一對多的關系，如果這個選項在不同的模塊中出現，我們是否需要為每個主表建立一個一對多關系呢?我選擇做一個中間關系表。我們可以把所有模塊中包含了了解管道選項的主表與這個中間關系表聯系起來，這樣就只用維護這一個關系表就行了，節約不少時間。

?

?

?

總結

以上是生活随笔為你收集整理的项目小结之数据库设计的全部內容，希望文章能夠幫你解決所遇到的問題。

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