資料庫設計心得

在需求分析階段，其實資料庫的設計就已經初具雛形，組內初步分析了需要哪些表來存放哪類資料，並探討了各個表中的關鍵欄位。但在需求分析階段的資料庫設計並不完整，只描述了部分實體，表中的屬性也不能完全描述需求，資料庫表間的關係沒有體現，這就需要進入詳細的資料庫設計階段來完善。

在資料庫設計的第一階段，還是圍繞使用者需求來展開工作。使用者的需求在設計過程中扮演著中心角色，如果一開始對需求的分析就出現偏差，那資料庫設計就很容易出現問題，好在需求分析階段結束後我們的需求是十分明確的，專案組內根據專案的需求刻畫了使用者的各種資料需求。

接下來，就進入將這些資料需求轉化成資料模型的概念設計階段。採用實體-聯絡的模型，我先列出了實體集並儘可能找出了這些實體集之間的關係，使用POWERDESIGNER工具畫出了E-R圖，當然這和最後的設計有所偏差，要知道，大部分事情一開始都不是最好的，甚至是不正確的，所以我們仍需要對這個模型進行改善。實體設計中，我最初本著在能實現的需求的前提下，將實體集的屬性設計的儘量精簡，表現在對於很多實體的主碼上，我不希望新增ID欄位，而是使用能唯一標識實體的屬性組合。例如所用的噪聲資料實體集，我將實體主屬性設計為<時間+地點>，省去了ID欄位，在資料庫審查過程中，還是被邊老師建議新增ID欄位，我在修改資料庫時思考得出的結論是，應該新增ID欄位，原因有二，在區分不同實體時，使用ID更為清晰，另一個原因在於，在引入外來鍵時，使用ID更為簡便。在資料庫設計過程中，我時刻注意資料的完整性和冗餘發生的可能性，但是，過分的追求精簡也會帶來問題，資料庫的設計還是為了方便資料的儲存和操作。

ID的新增是可選的，是否使用ID是一種決策，應該說，資料庫設計不是一般的選擇題，沒有一個標準答案，有時候兩種設計方案都能夠滿足資料庫設計的需求，這時設計者就會面臨各種各樣的決策。舉幾個我所面臨的資料庫設計決策的例子，使用者需求中有一項是獲取自己上傳噪聲記錄的歷史。一個方法是在噪聲資料實體中新增關於該噪聲資料上傳的資訊，如上傳的時間，上傳的使用者等。這一設計的一個問題是，某個使用者可能某一次上傳中，上傳了多條資料，結果造成了在噪聲資料表中，這些同時上傳的資料在上傳時間和上傳使用者等欄位上是相同的，並不是一個很好的設計。另一個實現的方法是建立一個使用者實體和噪聲資料實體之間的上傳記錄關係集，上傳記錄關係集聯絡了某個使用者和該使用者所上傳的噪聲資料關係，添加了上傳的時間和協議等資訊，一個使用者可以上傳多條噪聲資料，所以關係的對映是一對多的。這個設計已經較為合格了，但還面臨另一個決策，那就是是否可以將上傳記錄作為一個新的實體，得到一個使用者-上傳記錄-噪聲資料的實體-聯絡區域性。最後我們採取了這樣的設計方式，在一次上傳中，單個的上傳記錄實體聯絡了多個噪聲資料實體，這樣這些噪聲資料就不存在資料上的重複，並且，也很容易分條得到使用者的上傳記錄歷史，雖然不如前一種方法緊湊，但是這一方案使得資料庫得組織更為得體，也更易於擴充套件。

另一個面臨的決策是關於噪聲資料組織成噪聲地圖的，噪聲地圖實際上是由噪聲資料統計得出的。最初腦海中有三種方案，一個是將噪聲地圖作為噪聲資料的弱實體集，一種是將噪聲地圖作為噪聲資料的檢視，還有一種是將噪聲地圖作為一個單獨的實體集，最後得出的方案是將噪聲地圖單獨出來。這樣設計的原因是，噪聲資料都是歷史性的，不會改變，而在某一特定時段過後，噪聲地圖的資料就應該生成了，在這一時段的噪聲地圖不再變動，單獨的實體也更容易在之後的地圖演算法中對資料進行操作。在某些設計決策中，需要考慮到資料的某些特性，如這裡資料的歷史時間特性，以及資料和程式互動的方式，以得到更適合程式的資料庫設計。

還有很多設計問題以及改進是在資料庫審查時解決的。印象較為深刻的是，使用者表中需要對使用者是否啟用設立一個欄位，這是我在之前的設計中完全沒有想到的。我畢竟還是一個年輕的程式設計師，也是第一次進行資料庫設計，在很多類似這樣的資料庫設計細節，我們顯然不如邊老師這樣有經驗的大牛，還需要虛心學習，多吸取這方面的經驗。

資料庫設計中關於資料操作和約束的部分，並沒有太大的收穫，因為專案需求中對這兩個部分沒有實際的需求，我也沒有想到什麼嚴格的約束。希望以後有機會在其他專案中，對這些部分的設計發起挑戰。

這就是資料庫設計的全部心得了，目前已經在開發了，希望一切順利，世界和平。