數據庫設計心得

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

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

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

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

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

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

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

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

噪聲收集系統——數據庫設計心得