團隊介紹
項目名稱:基于深度學習的人體生理數據監測系統
指導老師:榮輝桂
小組名稱:代碼怎么敲都隊
小組成員:崔光博(PM)、安冠東、海日娜、劉文韜、馮秋怡
數據庫設計目標
1.涵蓋需求文檔里所有的用例
2.數據庫設計盡可能簡單且全面
3.數據庫設計能方便后期的修改和維護
數據庫設計過程
在本次的項目過程中,數據庫設計分為以下幾個階段:
1.需求分析
2.概念模型設計
3.邏輯模型設計
4.物理模型設計
5.數據庫定義
1.需求分析
在項目開展初期,我們已經完成了需求的收集與分析,并且撰寫項目前景與范圍文檔、用例文檔和需求規格說明書、圖形化的原型界面和圖解化的系統用例圖。
我們后續任務的開展都以這些資料作為參考和指南。
2.概念模型設計
概念模型設計是整個數據庫設計的關鍵,它通過對用戶需求進行綜合,歸納與抽象,形成一個獨立于具體DBMS的概念模型,即概念模型的設計與某一特定的數據庫無關,具有通用性和普遍性。
我們項目使用的概念模型是自底向上的E-R圖。
2.1 健康日志

2.2 飲食管家

2.3 醫患交流

2.4 木糖社區

2.5 我的消息

2.6 登錄日志

全局E-R圖

3.邏輯模型設計
邏輯模型設計的任務就是把概念模型設計好的基本E-R圖轉換為與指定DBMS產品所支持的數據模型相符合的邏輯結構。邏輯結構依賴于所選擇的數據庫的類型,例如:關系型、文檔型、key-value型等。
因為本項目使用的DBMS是mysql,屬于關系型數據庫,所以邏輯模型我們采用的是關系模型。例如:
用戶登錄日志(登錄id,用戶id,登錄時間)
用戶表(用戶id,用戶名,用戶郵箱,用戶頭像,……)
用戶個人消息表(消息id,用戶id,消息時間,……)
其中標注有下劃線的屬性表示為主鍵
4.物理模型設計
物理設計是為邏輯數據結構模型選取一個最適合應用環境的物理結構,包括每個模型如何存儲、每個字段如何存儲、以及每個字段存儲的類型大小等。物理模型嚴格地按照相應的ODBC(數據庫對象)進行設計,與DBMS相關聯。
物理模型的設計,我們采用的是建模工具是PowerDesigner。并且在本項目中,對應的物理環境是關系型數據庫mysql。所以在建模工具PowerDesigner中選取的ODBC(數據庫對象)為mysql。并且根據所設計的E-R圖、邏輯模型,完成系統物理模型(PDM)的設計:
5.數據庫定義
數據庫實施階段,設計人員通過特定DBMS的sql語言,根據物理設計的結果建立數據庫表和字段。
因為本項目采用了PowerDesigner設計PDM,PowerDesigner可以通過PDM自動生成相應數據庫表的創建sql語句,我們只需要在DBMS中執行即可,大大減少了數據庫設計人員的工作量。下圖是本項目中所有的數據庫表:
|
序號 |
表名 |
功能說明 |
|
1 |
t_log_login |
用戶登錄日志 |
|
2 |
t_all_user |
用戶表 |
|
3 |
t_personal_message |
用戶個人消息 |
|
4 |
t_background_administrator |
管理員表 |
|
5 |
t_community_doctorverify |
醫生資格認證表 |
|
6 |
t_diet_record |
飲食記錄表 |
|
7 |
t_community_food |
食物表 |
|
8 |
t_community_drug |
社區藥品表 |
|
9 |
t_community_relation |
社區關系表 |
|
10 |
t_community_chat |
社區消息表 |
|
11 |
t_community_post |
社區帖子表 |
|
12 |
t_community_interaction |
社區交互表 |
|
13 |
t_health_medication |
我的藥物表 |
|
14 |
t_health_record |
健康記錄表 |
|
15 |
t_health_suggest |
健康建議表 |
遇到的問題及解決
-
需求分析過程中,我們先是從單一功能頁面分析需要存儲的數據是哪些,及這些數據需要的屬性,這導致我們最開始的表比較零散,缺乏邏輯性與整體性。并且還對業務邏輯的梳理產生一些疏漏。好在老師及時發現問題提醒我們,幫助我們改正。
-
命名問題上,首先我們由中文翻譯成英文,容易造成一定偏差,其次我們的命名不夠規范,有的屬性直接用了mysql內置屬性鍵,容易造成錯誤。后來大家一起對照命名規范自查自改。還一致決定了表的命名與注釋,保證每個表、每個字段都能做到見名知意。
-
表的復雜程度應盡量與功能重要程度相對應。例如一開始我們把用戶畫像(給每個用戶提供畫像詞,顯示在主頁)單獨設置成表,后來我們覺得這個功能并不重要,把它加進了用戶信息表作為一項屬性。
心得
- 設計數據庫時可以從使用便捷性考慮,例如為減少從不同表進行重復查詢工作,可以引入外鍵,最終實現數據庫的高效訪問。
- 大文件和照片存儲在文件系統,數據庫里存URI更好。
- 使用范式與反范式設計。結合自己項目的特點,某些情況下用數據的冗余去換取操作數據時間的縮短。把數據冗余在多個表中,在查詢時可以減少或者是避免表之間的關聯查詢,從而提高查詢效率。
- 積極和老師溝通,獲得老師的專業建議,可以有效避免經驗性錯誤。團隊成員線下合作,可以及時互通有無,互相幫助鼓勵,增進團隊效率。
浙公網安備 33010602011771號