資料庫，是一個專案的靈魂，資料庫設計得合理，接下來的開發工作也會變得簡捷有序。而說到資料庫的設計，說它難吧，可不就是設計一張張表嘛，可說它簡單吧，每一張表裡面放一些什麼東西？表與表之間的聯絡又該是怎麼樣？這些都是要考慮的東西，每一個改動都決定著後面工作的難易。於是，我們的第一個專案的資料庫，就是在這樣一種大致一想不就這麼回事，可真正做起來又覺得事情好像沒那麼簡單的每時每刻都充滿著工作激情的討（si）論（bi）環境下誕生了。

　　嗯，沒吃過豬肉，還沒見過豬跑麼，作戰一開始，我們就制定了“討論需求->確定實體->寫資料字典->概念模型->物理模型->建庫”的嚴謹科學

　　抱著我們的需求文件，我們進行了一個晚上的激烈討論，在一些問題上始終沒有統一意見，於是我們決定

　　告老師！

　　不得不說，在實戰經驗缺乏的時候，和指導老師交流是一件很重要的事，又經過了一個晚上的激烈討論，我們最終決定了以三個代表為核心，呸，以

　　以上實體為核心的關係型資料庫

　　表確定之後，資料字典的討論就顯得核平多了（嗯，一如既往的核平），在此基礎上，概念模型也快速完成

　　很複雜是不是，是就對啦，直至今天開啟這張圖還是頭皮發麻，然後，我們就可以愉快地自動生成物理模型啦

　　關於概念模型，有幾點心得想說一下：

　　1.對於用組合主鍵的表，可以建立一個自增id來作為一個唯一主鍵，也不是說組合主鍵不好，有的時候反而是組合主鍵這樣有實際意義的做法更好，但我就是不喜歡

　　2.概念模型的資料型別裡面，好像麻油bit或者bool型？不過pdm裡面就有

　　3.有的時候，明明拉了一對多關係，但是在pdm裡面父表的主鍵並沒有在字表裡作為外來鍵，這時我們可以在pdm裡面，點選關係的那條線，然後點選join，強行改正

　　4.在cdm，一對多的多是有爪子那邊，而在pdm裡，多是沒有箭頭那邊，別暈了（別問我是怎麼知道的）

　　最後，我們用物理模型匯出SQL，再匯入navicat，設計的第一個資料庫就算是建好了

　　第一次設計資料庫，有很多自己不太懂的地方，pd工具也用得不是很熟練，從cdm到pdm，以及從pdm匯出建庫，都不是完全沒有出錯的，有在pdm裡面直接改關係改主鍵改資料型別，也有在navicat建好的資料庫裡面改欄位改外來鍵，但好在往裡面加資料，還有用jdbc連線並使用的時候，都沒有發生什麼錯誤，也沒有出現不能很好滿足需求而去修改表結構的事發生，對於這個初學的成果，不說特別滿意，但還是有一般滿意的，但經過了資料庫系統實驗的專案訓練，有了很多新的認識和想法，在下次再接觸資料庫設計的時候，希望自己可以利用專業知識，再做得科學嚴謹一些，設計出更簡明合理的結構。