O猪狗鲤鱼王O——数据库设计心得

发布时间 2023-11-10 18:40:41作者: FY王(各种版

前言

  在大二下学期学习的数据库原理课程中,我们学会了mysql数据库相关的sql语句,以及数据库的基本原理。在本门课程软件工程导论上,我们学会了如何根据业务需求来进行数据库的设计。最终完成数据库的设计与搭建。并使用PowerDesigner工具帮助我们完成了图的绘画,导出了相关的sql语句。接下来是我们在设计数据库中的一些心得体会。

 

团队介绍

项目名称:管道直饮水智能物联网管理系统

指导老师:肖雄仁

小组名称:O猪狗鲤鱼王O

小组成员:何梁雨(PM)、王晓婧、朱俊文、苟怀炜、李义、林楚朋

 

项目简介

  本项目研究的目的是开发一种“管道直饮水智能物联网管理系统”。这一系统将结合建筑单元管道直饮水系统的专业生产厂家的技术和经验,利用物联网技术和先进的通信协议,以及多种传感器设备,实现了对管道直饮水系统的实时监测、运维和用户查询。一共有一个Web端(后台)和两个APP端(用户端,维修人员端)

 

逻辑模型设计

  本项目使用的DBMS是mysql关系型数据库,所以逻辑模型我们采用的是关系模型。根据业务需求又划分成用户、设备、地区、工单、日志这几个模块,如下:

用户模块 

1)

实体名称:管理员

属性:管理员id,管理员电话,管理员姓名,管理员密码

约束:主键:管理员id;唯一:管理员电话

 

2)

实体名称:用户

属性:用户id,用户电话,用户姓名,用户密码

约束:主键:用户id;唯一:用户电话

 

3)

实体名称:维护人员

属性:维护人员id,片区id,维护人员电话,维护人员,姓名维护人员密码,

约束:主键:维护人员id;外键:片区id;唯一:维护人员电话

 

4)

实体名称:工资

属性:工资编号,维修人员编号,月份,工资金额,

约束:外键:维修人员编号,候选键:(维修人员编号,月份)

 

5)

实体名称:通知

属性:通知编号,标题,内容,片区id,发布时间,发布人员。

约束:主键:通知id;外键:片区id

 

设备模块 

1)

实体名称:制水机

属性:小区id,制水机id,TDS1值,TDS2值,TDS3值,滤芯1安装时间,滤芯2安装时间,滤芯3安装时间,滤芯4安装时间,滤芯5安装时间,滤芯6安装时间,滤芯7安装时间,滤芯8安装时间,滤芯9安装时间,低压开关检测情况,制水机位置,安装时间,设备状态

约束:主键:制水机id;外键:小区id

 

2)

实体名称:供水机

属性:供水机id,制水机id,水位信息,供水机位置,供水机安装时间,供水机设备状态

约束:主键:供水机id;外键:制水机id

 

3)

实体名称:水表

属性;水表编号,水表位置,安装时间,供水机id

约束:主键:水表编号;外键:供水机id

 

4)

实体名称:用户水表信息

属性:用户水表id,用户id,水表编号 

约束:主键:用户水表id;外键:用户id,水表编号

 

5)

实体名称:正常值

属性:正常值id,正常值

约束:主键:正常值id

 

地区模块

1)

实体名称:行政划分

属性:上级id,id,名称

约束:主键:id

 

2)

实体名称:小区

属性: 小区id,片区id,小区位置,小区名称

约束:主键:小区id;外键:片区id

 

3)

实体名称:片区

属性:片区id,id,片区名称

约束:主键:片区id;外键:id

 

工单模块

9)

实体名称:工单

属性:工单编号,工单状态,维护人员编号,工单状态,报修类型,用户编号,工单价格,告警项目,设备位置,报单时间,完成时间,故障图片,故障描述

约束:主键:工单编号;外键:维护人员编号,用户编号

 

10)

 实体名称:工单维修图片

属性:工单编号,图片id,维修图片

约束:主键:图片id;外键:工单编号

 

11)

实体名称:工单维修项目

属性:工单维修项目编号,工单编号,维修项目编号

约束:主键:工单维修项目编号,外键:维修项目编号,工单编号,

 

12)

实体名称:维修项目

属性:维修项目编号,维修项目名称,价格

约束:候选键:维修项目名称

 

日志模块

1) 

实体名称:告警日志

属性:日志id,告警设备id,日志时间,告警信息

约束:主键:日志id

 

2)

实体名称:水位日志表

属性:水位日志id,供水机id,历史水位信息,水位日志时间 

约束:主键:水位日志id;外键:供水机id 

 

物理模型设计

采用的是建模工具是PowerDesigner,设计ER图

 

过程中出现的问题

1.对于行政区域,我们在犹豫是将“市”“区”都单独做成一个一个表,还是将其整合成一个表,又或者是不设计数据库表,直接将其写定在后端代码中。后来去询问了指导老师,老师建议我们去网上查看“中国地图”的数据库设计,吸取借鉴,最终形成了“行政划分表”。

 

2.原先的数据库设计中并没有“小区”这一个实体,指导老师向我们提出了这一问题,我们进行了增加,试数据库设计更符合实际的业务需求。

 

3.原先“水表”与“用户”之间是直接联系的,指导老师提出,在实际的业务需求中,用户并不一定是水表所有人,用户与水表之间的关系应该是,用户经过一定的验证绑定水表。

 

总结心得

1.需求分析:在开始设计数据库之前,要确保团队对项目的需求有清晰的理解。理解用户的使用场景和数据需求。不然就会出现缺少/冗余实体或属性之类的情况,当前后端已经正式开始开发时,再进行修改就有一定的困难,增加工作量。

 

2.规范化:数据库规范化是一个非常重要的步骤,它可以帮助避免数据冗余、更新异常和插入异常。在设计中尽量遵循范式,并随着项目的进展不断调整。这里我们课程的要求是符合第三范式,也就是属性不能传递依赖于主属性(属性不依赖于其它非主键属性)。第三范式(3NF)是在第二范式(2NF)的基础上建立起来的,即满足第三范式(3NF)必须先满足第二范式(2NF)。如果某一属性依赖于其他非主键属性,而其他非主键属性又依赖于主键,那么这个属性就是间接依赖于主键,这被称作传递依赖于主属性。

 

3.数据类型选择:选择正确的数据类型对于数据库设计至关重要。这不仅可以提高数据质量,还可以提高查询性能。

 

4.文档记录:良好的文档记录可以帮助团队成员更好地理解数据库结构,也有助于在之后进行维护和优化。因此我们按照课程要求认真的编写了数据库设计文档,保证了团队成员对数据库的统一性。

 

5.团队协作:团队中的每个人都应该对数据库设计有所了解,并且及时进行有效的沟通。在整个数据库设计的过程中,团队通过开会还有线上交流,查漏补缺,最终形成了现在的这个数据库,因此团队协作是很重要的,每个人都参与数据库的设计,一定程度上为之后的开发打下了良好基础。成员们会清楚每一步是调用数据库的哪一个实体和属性,要进行什么操作。

 

6.与老师沟通:在数据库设计上,老师比我们这些初次接触项目的学生要更为敏感,他能够给我们很多有建设性意义的意见,帮助我们更好的设计数据库。