項目小結之數據庫設計

項目小結之數據庫設計

      最近作了一個小項目完整的數據庫設計,想總結一些設計上的所得,但願你們多多指教。

      有時一個項目，普通程序員通常不會去接觸數據庫設計，通常都有專業的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)就行。

      第三：如何靈活利用一對多關係。一對多的關係很是常見，但若是加以靈活應用有時效果更佳。
          例如，上面的圖中有一個瞭解管道的選項，它和對應的主表是一對多的關係，若是這個選項在不一樣的模塊中出現，咱們是否須要爲每一個主表創建一個一對多關係呢?我選擇作一箇中間關係表。咱們能夠把全部模塊中包含了瞭解管道選項的主表與這個中間關係表聯繫起來，這樣就只用維護這一個關係表就好了，節約很多時間。