醫生智能提醒小程序數據庫設計心得——Legends Never Die

數據庫設計心得
根據咱們小組數據庫設計的整個流程，咱們將整個數據庫設計劃分爲兩個具體的階段，在每一個階段須要進行不一樣的準備，有不一樣的注意事項，接下來咱們將結合在數據庫設計過程當中遇到的一些問題和困難，提出本身的一些觀點，但願能對你們有所啓發。若有異議，歡迎指正。
1、準備階段：
在數據庫設計前，須要準備如下幾樣東西：
1：設計工具
數據庫設計過程當中會用到一些軟件，例如powerdesigner（實際上不只僅是用於數據庫設計）。想要設計好數據庫，熟練運用軟件是必不可少的。至於如何學習使用其進行數據庫設計，主要的方法仍是利用其自帶的文檔/網上找資料。
在使用該軟件以前，最好先從E-R圖開始入手，同時數據庫的基本知識也要有，這些都是數據庫設計的基礎。
2：用例圖
用例圖可以幫助咱們理清各種用戶，以及他們所須要功能。有這些數據，咱們能夠劃分不一樣的功能模塊，而後再對每一個功能模塊設計其對應數據庫。這樣作就不會出現不知道從哪張表開始設計的狀況。不一樣功能模塊相對獨立，這樣作就能夠將設計任務分紅若干部分。至於不一樣的用戶則是這些功能模塊的全部者，並起到橋樑的做用。
以咱們的項目爲例：用戶只有兩類，醫生和患者，醫生功能有查看並處理預定，自我提醒，積分，提醒患者，上傳資料等，患者功能主要有預定而且及時查看提醒並回復。
實際設計步驟中也是按照模塊一個一個設計的。

圖1 項目總的用例

3：需求文檔
需求文檔中主要提供了對各類功能以及相關數據的詳細描述。相關數據的主要來源是咱們設計的表中的屬性。除此以外，需求文檔還能夠揭示一部分的關係，例如實體和實體之間的聯繫（一對一，一對多，多對多等）。

圖2 預定用例說明

圖2 展現的只是預定功能中一部分，咱們能夠從中知道患者預定時須要選擇（業務和時間），其中業務顯然是醫生方提供的。除此以外，不容許患者重複預定（對預定的約束）。
詳細的需求說明在設計數據庫的過程當中是十分重要的，須要弄清楚總體需求以後才能開始設計。固然，需求說明並非萬能的，有些說明中提供的數據可能不完善，或者是描述不清。此時能夠選擇和相關人員交流，或者經過參考已有案例來填充這部分。

2、設計
概念數據模型（CDM）是咱們的本次設計的重點。具體的任務有如下幾個
1：實體的創建
創建一個實體並不容易，既要考慮實體所具備的屬性，以及屬性的數據類型，屬性的默認值，一些簡單的約束，是否爲空，還要考慮主鍵，候選key（標識符）。
其中一個比較常規的作法是爲每一張表添加一個標號屬性（並不必定有用），並做爲主鍵，以此做爲惟一識別的標識符，同時也做爲多表關係中的外鍵。
固然，這麼作比聯合主鍵這類利用其餘屬性做爲主鍵的作法要簡單，可是在數據的約束上可能會有更高要求。由於原來做爲主鍵可讓其不重複，可是不做爲主鍵能夠必須使用unique約束來完成這一點。
下圖3中就是使用編號做爲主鍵，可是編號自己沒有意義，所以實際過程當中可能須要患者姓名+電話號碼或者單純的電話號碼做爲標識符。

圖3 患者基本信息實體

2：關係的肯定
關係是實體和實體之間的橋樑，不管是一對一，一對多，仍是多對多關係，都是如此。值得注意的是，一對一實際上是指在A表中的一條對應B表中的一條記錄。關係之間還有強相關，弱相關，弱相關（只對與一方來講，可能另一方是強相關）是指A表中的一條記錄不必定在B表中有對應記錄。具體能夠在關係的描述中看到。
至於帶屬性的關係其實能夠轉換成實體，這裏就再也不闡述了。
圖4中只是一種實現方式，在當前業務，帳戶和用戶是一對一的關係，即一個用戶只有一個帳號，一個帳號對應一個用戶。（至於那種相同的註冊兩個帳號，看做是兩個不一樣的人）

圖4 帳號和患者基本信息

3：PDM
PDM主要由CDM轉換而成。值得注意的是，PDM是最終參考的依據，外鍵可以顯示在PDM中，所以具備很強的參考價值。可是要注意由CDM直接生成的PDM有時候並不徹底知足咱們的要求，所以，在生成PDM以後，必需要進行檢查。
4：視圖和索引
咱們認爲視圖和索引的建立是與具體的應用相結合的，所以這兩個部分咱們還在設計之中，並無具體的實現。

3、總結：
數據庫設計有必定難度，咱們組是一邊探索一邊設計的，而且在過程當中積極討論，詢問老師獲取意見，修改了不少次纔有如今的這個版本，由於需求不是一成不變的。在此後的開發過程當中，咱們還會根據需求的變更與實際狀況對數據庫進行調整，使其更加符合項目的功能需求與生活應用，而且要積極在組內，小組之間，以及和老師，就設計中出現的問題展開討論，尋求解決方案。同時但願小組成員能在此次數據庫設計中掌握基本的設計原理與概要。
咱們在數據庫設計上花費了不少時間和精力，在後續開發過程當中咱們會充分利用咱們設計出來的數據庫。
祝各位開發順利！