資料庫表的設計原則 #

建立資料庫裡最基本的應該就是建表，建索引、存儲過程等一系列操作了。談到表就不得不談到實體。

1. 資料實體

   什麼是實體，客觀存在并且可以互相差別的事物稱為實體。這裡我們就簡單的把它了解為一個表吧，描述實體的特性，我們就把他們稱為了屬性。也可以說當我們把一個資料庫表當作一個實體，那麼它裡面的所有字段是不是就是一個屬性了呢？結果是肯定的。

2. 實體間的聯系

我想說的是，很簡單，資料庫裡表跟表間的關系莫過于三種：一對一；多對多；一對多。

一對一其實就是說我們建的主表跟相關聯的表之間是一一對應的，比如說，我建了一個學生基本資訊表：t_student,然後我又建了一個成績表，裡面有個外鍵，studentID，學生基本資訊表裡的字段studentID和成績表裡的studentID就是一對一。

一對多，也是類似，我另外建一個班級表，而每個班級有多個學生，每個學生就對應一個班級，對班級來說當然就是一對多了。

多對多，我還舉這個例子，我建個選課表，可能有許多科目，每個科目有很多學生選，而每個學生又可以選擇多個科目。這就是多對多了。

1. 基本表的完整性

(1) 原子性。基本表中的字段是不可再分解的。

(2) 原始性。基本表中的記錄是原始資料（基礎資料）的記錄。

(3) 演繹性。由基本表與代碼表中的資料，可以派生出所有的輸出資料。

(4) 穩定性。基本表的結構是相對穩定的，表中的記錄是要長期儲存的。

這是基本表的完整性，也是它特有的。這裡我想說的是，在資料庫裡還有幾種表也是常用的那就是中間表和臨時表。

• 中間表

  中間表是針對多對多關系的，就比如做公交查詢系統。裡面有兩個表，分别是車站表、線路表。這裡我們起個名字叫：t_busstation 、t_road，根據常識我們也知道，一個站有多個線路經過，而每個線路又有多個車站，怎麼才能将兩個表聯系起來呢，如果是一對一，一對多，我們一個表，兩個表就可以将他們實作了，但是多對多呢，這樣我們就必須借助中間表用來連接配接兩個表。一般中間表都是有一個本表的自增主鍵，還有另外兩個表的主鍵。中間表是沒有屬性的因為它不是一個基本表。

• 臨時表

在本次項目中，我們就要用到臨時表，首先來看看什麼是臨時表吧。這是我從網上書上查到的。因為我們用的是MS SQL Server 2000資料庫，而在這個資料庫裡是支援臨時表的。

臨時表：其實就是那些以#号開頭為名字的資料表，它主要是用來存放臨時資料的，當使用者斷開連接配接但沒有出去臨時表裡的資料時，系統會自動把臨時表裡的資料清空。這裡要說一點，臨時表是放在系統資料庫 tempdb中的，而不是目前資料庫。

臨時表總共是分兩種：本地臨時表和全局臨時表。

（1）這裡我們需要了解的就是，在資料庫中本地臨時表是以一個#開頭的，這種臨時表隻對目前的資料庫使用者可見，而其他的使用者是不可見的。當資料庫執行個體斷開後當然也就丢失了資料了，不管是顯式清空還是系統回收。

（2）還有一個就是全局臨時表。它是以“##”開頭的，而且是對于所有的使用者都是可見的，當你斷開資料庫執行個體連接配接時，隻要還有别的系統項目在引用它，連着資料庫，那麼資料就存在，隻有當别的系統也斷開連接配接時，系統才會清除全局臨時表的資料。

下面是建立臨時表的語句:

本地臨時表：

create table #student(

studentID int ,

studentName nvarchar (40),

classID int

)；

全局臨時表：

create table ##student(

studentID int ,

studentName nvarchar (40).

classID int

)；

這裡我們也可以用SQL語句完成：

select * from employee into #student

三大範式

現在就來看看三大範式。

第一範式：如果每列(或者每個屬性)都是不可再分的最小資料單元(也稱為最小的原子單元),則滿足第一範式.比如一個勞工的基本資訊表，裡面有勞工的工号，性别，年齡，這些屬性都是不可分割的，是以這個表就符合了第一範式。

第二範式： 就是在第一範式的基礎上延伸，使之表裡的每個字段都與主鍵發生關系。假如一個關系滿足第一範式,并且除了主鍵以外的其它字段,都依賴于該主鍵,則滿足第二範式.

例如:訂單表(訂單編号、産品編号、定購日期、價格、……)，”訂單編号”為主鍵，”産品編号”和主鍵列沒有直接的關系，即”産品編号”列不依賴于主鍵列，這個列我們就可以把它删除。

第三範式：在第二範式的基礎上更進一步，也就是為了實作表裡的列都與主鍵列直接相關，不是間接相關。這個我們可以用“Armstrong 公理”中的傳遞規則來推理。

我們來看一下它的定義：

設U是關系模式R 的屬性集，F 是R 上成立的隻涉及U 中屬性的函數依賴集。若X→Y 和 Y→Z在R 上成立，則X →Z 在R 上成立。是以我們就來看在網上搜尋到的例子：例如:訂單表(訂單編号，定購日期，顧客編号，顧客姓名，……)，初看該表沒有問題，滿足第二範式，每列都和主鍵列”訂單編号”相關，再細看你會發現”顧客姓名”和”顧客編号”相關，”顧客編号”和”訂單編号”又相關，最後經過傳遞依賴，”顧客姓名”也和”訂單編号”相關。為了滿足第三範式，應去掉”顧客姓名”列，放入客戶表中。

這裡其實就是為了說明資料庫的表裡步要出現備援，在顧客表裡已經有了”顧客姓名”了，而在訂單表裡就别出現了，而直接根據顧客編号相關聯就可以，否則造成資源浪費。

以上就是三大範式。

延伸：我們來看這三大範式：

第一範式：1NF是對屬性的原子性限制，要求屬性具有原子性，不可再分解；

第二範式：2NF是對記錄的惟一性限制，要求記錄有惟一辨別，即實體的惟一性；

第三範式：3NF是對字段備援性的限制，即任何字段不能由其他字段派生出來，它要求字段沒有備援。

其實在設計資料庫的時候我們最多的要遵循的就是第三範式，但是并不是越滿足第三範式資料庫就設計的越完美，這種錯誤是錯誤的。有時候增加點備援相反的會提高通路速率，是以在實際的設計過程中應降低對範式的要求。

以前對資料備援并不是很了解，在百度知道裡的定義是這樣的：在一個資料集合中重複的資料稱為資料備援. 但是不是說我們表的主鍵在其他表裡重複出現就是備援，這不是，而是為了連接配接兩個表。隻有非鍵字段就是既不是主鍵外鍵等限制的鍵如果重複出現，就會形成資料備援。資料備援也包括重複性備援和派生備援。比如勞工表裡有”基本工資”，”獎金”兩列，然後還有一個”總工資”的列，這個總工資就是派生備援。低級的重複性備援一定要避免，杜絕，但是像派生備援還是提倡的因為它能提高通路的效率。