首页 > 数据库 >数据库设计心得-4班-代码怎么敲都队

数据库设计心得-4班-代码怎么敲都队

时间:2022-11-04 19:33:40浏览次数:34  
标签:概念模型 数据库 用户 community 模型 设计 心得 代码

团队介绍

项目名称:基于深度学习的人体生理数据监测系统

指导老师:荣辉桂

小组名称:代码怎么敲都队

小组成员:崔光博(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

健康建议表

 

遇到的问题及解决

  1. 需求分析过程中,我们先是从单一功能页面分析需要存储的数据是哪些,及这些数据需要的属性,这导致我们最开始的表比较零散,缺乏逻辑性与整体性。并且还对业务逻辑的梳理产生一些疏漏。好在老师及时发现问题提醒我们,帮助我们改正。

  2. 命名问题上,首先我们由中文翻译成英文,容易造成一定偏差,其次我们的命名不够规范,有的属性直接用了mysql内置属性键,容易造成错误。后来大家一起对照命名规范自查自改。还一致决定了表的命名与注释,保证每个表、每个字段都能做到见名知意。

  3. 表的复杂程度应尽量与功能重要程度相对应。例如一开始我们把用户画像(给每个用户提供画像词,显示在主页)单独设置成表,后来我们觉得这个功能并不重要,把它加进了用户信息表作为一项属性。

 

心得

  1. 设计数据库时可以从使用便捷性考虑,例如为减少从不同表进行重复查询工作,可以引入外键,最终实现数据库的高效访问。
  2. 大文件和照片存储在文件系统,数据库里存URI更好。
  3. 使用范式与反范式设计。结合自己项目的特点,某些情况下用数据的冗余去换取操作数据时间的缩短。把数据冗余在多个表中,在查询时可以减少或者是避免表之间的关联查询,从而提高查询效率。
  4. 积极和老师沟通,获得老师的专业建议,可以有效避免经验性错误。团队成员线下合作,可以及时互通有无,互相帮助鼓励,增进团队效率。

标签:概念模型,数据库,用户,community,模型,设计,心得,代码
From: https://www.cnblogs.com/JCKeep/p/16858905.html

相关文章