好久沒有碰資料庫分析設計了。今天突然要做一個數據庫分析，很是費解，所謂好記性不如爛筆頭，個人覺得還是要記一下的。用一個例子來說：
你想要設計的一個產品表可能是這樣的：

產品表：產品ID， 產品名稱， 產品型別

 產品ID   產品名稱        產品型別
  1        敵敵畏          農藥
  2        加多寶          飲料  
  3        可樂           飲料

那麼，接下來我們把這個產品表拆分開來（實際開發中），因為在資料庫設計中除了外來鍵以外其他欄位是不可以重複的（產生冗餘），因為不可能你一個介面就設計一張表，你需要分析這樣一對多的關係，便於管理維護：
產品表：產品ID，產品名稱，產品型別ID
產品型別表：產品型別ID，產品型別名稱

產品ID  產品名稱  產品型別ID
  1     敵敵畏     1
  2     加多寶     2
  3     可樂       2

產品型別ID   產品型別名稱
   1           農藥
   2           飲料

相信大家對於這樣的拆分是可以理解的，因為一個產品型別對應多個產品，是一對多的關係，所以我們把這個產品型別表的主鍵放到產品表中做外來鍵，形成主外來鍵的關聯，那麼產品表相當於繼承了產品型別表的東西，繼承，那麼大家可以聯想到的就是兒子繼承父親的東西，所以產品表是子表，產品型別表是父表。也有一種說法是主表和從表的說法。

還有一種比較棘手的資料庫設計模式就是多對多的關係：

學生表：學生ID，學生名稱。。。

選課表：課程ID，課程名稱。。。

學生_選課表：學生選課ID，學生ID，選課ID。。。

上面的例子中可以這麼理解，一個學生對應多個課程，而一個課程也可以對應多個課程，兩個一對多的關係，加外來鍵也是搞不定了。所以這個時候我們就可以引入一箇中間表（關係表），學生_選課表進行邏輯的處理，而且不破壞學生表和選課表的結構關係。這樣，我們如果想要查出一個學生的所有選課，或者一個選課的所有學生，就可以通過聯表查詢查出想要的結果了。奧耶

比較常用的有遞迴表：

可能你想要的是這種效果，但是對於地區名稱這個欄位中還可以細分，因為廣東屬於中國，廣州屬於廣東，存在這樣的關係。。。。

地區表：地區ID，地區名稱
         1     中國
         2     廣東
         3     廣州

我們引入一個地區ID_f就是地區ID的父親，建立遞迴關係。

地區表：地區ID，地區名稱，地區ID_f
         1     中國     0
         2     廣東     1
         3     廣州     2
         4     浙江     0

個人覺得你在資料庫表的設計上如果碰到類似這樣的表結構，我們還可以引入屬性表的概念：

顏色表：顏色ID，顏色

尺寸表：尺寸ID，尺寸

地區表：地區ID，地區名稱

等等

大家看，這些表的結構是不是相識，只有一個ID外加一個欄位。

那麼，我們可以引入屬性集合表和屬性集合明細表的概念來優化

屬性集合表：屬性集合ID,屬性集合名稱
             1        顏色
             2        尺寸
             3        地區


屬性集合明細表：屬性集合明細ID，屬性集合ID，屬性集合明細名稱
               1            1           紅色
               2            1           綠色
               3            2           大
               4            3           中國
               5            3           美國

需要注意的是，我們需要記住屬性集合的ID，這樣比較方便，我們在使用前可以對屬性集合ID進行一個判斷，如果是1，則判斷顏色。

如果大家還有比較經典的資料庫設計方法，歡迎補充