進行過了基礎三層思想的薰陶，馬上就進入了個人機房重構的階段，感覺自己這隻菜鳥中的菜鳥,任重而道遠。要想建造高樓大廈，必須有水泥、磚瓦。資料庫是管理資料資源的容器，下面是我自己建表的過程，如果有不妥的地方，還請大家指正！

一、“三正規化”瞭然於胸

好處：關聯式資料庫的規範，為了減少資料冗餘。滿足三正規化，說明資料庫比較健全，資料冗餘少，後期維護方便。

詳細內容：

第一正規化（1NF）：資料庫表中的欄位都是單一屬性，不可再分，確保了每列的原子性。

例如：住址 就要拆成  省份 城市，直到不能拆了為止。

第二正規化（2NF）：第一正規化的升級版~目標是確保表中的每列都和主鍵相關。

例如：比如要設計一個學生考試成績表（表1），聯合主鍵是學號和課程。學號作為主鍵，學分僅僅跟課程相關。這樣就違背了第二正規化的設計原則。

所以，遇到這樣的情況，我們就應該把這個表進行拆分，把學生資訊分離到一個表（表2.0），課程資訊分離到另一個表（2.2）.

        如果不拆分，會出現什麼問題？

資料冗餘：如果1個同學選修n門課程，那麼學生資訊就會被重複n-1次（表3的1區是資料冗餘的地方），n個同學選修1門課程，課程和學分也會被重複n-1次。

更新異常：如果需要更新一門課程的學分，表中所有的學分都要更新，否則會出現同課不同學分的情況。

如果增加課程，暫時沒有學生選修，沒有主鍵：學號，就不能再資料庫中存入課程資訊。

刪除異常：如果一批學生畢業，要刪除成績記錄，課程名稱、學分都會被刪除，難不成還要等開學了，進來一批新的學生再填進去？？？

第三正規化（3NF) ：在第二正規化的基礎上更進一層。確保每列都和主鍵列直接相關，而不是間接相關。

例如：一個學生資訊的表（表4），存在決定關係：學號——>姓名、年齡、性別，還存在下面的決定關係

學號——>卡號——>餘額、狀態，存著餘額、狀態對學號的傳遞依賴，是間接相關的。違反了第三正規化的原則。

因此把它拆分成表5和表6就很完美啦！

當然第三正規化也會出現資料冗餘、更新異常、刪除異常，詳情與第二正規化的類似。

二、“E-R圖”分析利器

    　E-R（Enitity Relationship diagram） :提供了表示實體、聯絡、屬性的方法，用來描述巨集觀世界的概念模型。

　　下圖這是我畫的E-R圖。畫圖的過程是理清思路的過程。當初對充值、退卡等表只是會用，知道確定一個表裡面有卡號、操作者的ＩＤ等資訊。當時還覺得ＩＤ挺多餘的，不過現在發現它和卡號組成了聯合主鍵，起的作用還不小～

                                                                                                                                                            

三、”SQL建表“落到實處

四、總結