口罩预约管理系统——数据库设计！满满的干货！

一、背景

2020年的疫情影响了我们的生产生活，政府不断加大力度联防联控，遏制疫情的蔓延势头，全国人民共同加入抗击疫情的战“疫”队伍。疫情信息发布、物资调配保障显得尤其重要，信息越详细，物资保障越充分，公众的疑虑就越少。“疫情地图”、“实时信息”、“口罩预约”的各种 APP、小程序和系统应运而生，不断规范化，纳入疫情发布的官方渠道。这些举措让公众能全方位获取疫情防控进展的信息，及时、准确、全面显得至关重要。

另外，这个小项目也是过去许久，疫情期间也有在市政官方系统预约口罩的经历，(・。・)没有中签过。不过因此对它的预约系统感兴趣，考虑自己可以简单做一个web网站版本的预约管理系统，实现基本功能，也正好课程需要完成一个数据库设计，然后做一个相对完整的应用系统，所以，这个小项目就此开始。

二、口罩预约管理系统介绍

1、功能模块及特点

本系统主要任务是实现用户口罩预约、市政人员（管理员）分配以及快递员接单配送的比较完整的功能。市政人员（管理员），普通用户，快递员这三种用户权限，功能明确，各自独立，而又存在着一定的联系，让政府更方便地管理、更高效地分配。

具体模块解析如下：

1. 普通用户模块：创建账号，登录系统填写预约信息确认提交，查看订单状态，修改订单预约信息，修改个人注册信息。
2. 市政人员（管理员）模块：查询已注册用户信息，修改或删除用户信息，对用户的预约订单进行合理分配，包括审核以及分配快递员。管理每种类型口罩，查询库存数量，合理分配用户预约的口罩数量，按需求查看订单的配送状态。
3. 快递员模块：查看分配到的订单，选择接单配送，完成配送选择关单，按订单状态查看订单，统计完成的订单数量。

2、系统结构

系统功能结构图：

三、数据库设计

在口罩预约管理系统初期阶段，我们需要设计好系统存取数据信息的一个数据库，数据库设计也是一个重点难点，完整的数据库基本满足设计基本要求，包括数据库关系模式分析，处理好函数依赖问题，还有关系模式至少满足第三范式等。学过数据库系统概论会基本了解这些知识以及它的重要性和难度。

以目前个人能力，这个系统数据库的建立暂时满足最基本的要求，初步进行了函数依赖分析，另外根据所需功能，关系模式不是很复杂，第三范式的满足只存在于部分关系模式中。

我使用的是MySQL数据库，前期建立数据字典，然后以此进一步建立数据库及数据表，确定口罩预约管理数据库关系模式，分析关系模式的函数依赖和范式要求。接下来将具体介绍数据字典、数据模型和概念模型（E-R 图）。

1、数据字典

根据系统功能需求，系统数据库包含了8个数据表，详细内容（字段、数据类型、码）如下数据字典：

1、admin表

 

 

 

 

2、口罩预约数据库关系模式（数据模型）

各个数据表包含属性，红色表示该关系模式的主码。

管理员 (管理员账号, 密码, 管理员姓名, 电话)

用户   (用户账号, 密码, 用户姓名, 身份证号)

快递员 (快递员账号, 密码, 快递员姓名, 电话, 地址)

口罩   (口罩类型, 仓库, 存货量, 单位价格)

订单信息 (订单号, 用户账号, 用户姓名，口罩类型, 已分配数量, 联系方式, 配 送地址, 订单状态, 预约时间)

预约 (用户帐号, 口罩类型, 预约时间, 期望到货日期, 预约数量, 电话, 地址)

分配 (管理员账号, 订单号, 快递员账号, 分配日期)

接关单 (快递员账号, 订单号, 快递员姓名, 接单时间, 关单时间)

3、E-R图（概念模型）

E-R图能够更加直观的展示数据关系模式之间的联系，下面则是自己画的：

这个是建立数据库后系统生成的：

四、MySQL创建数据库以及数据表

这个步骤开始对设计好的关系模式在MySQL上部署数据库以及建立各个数据表。建表代码如下：

• 建立数据库

create database maskorder;

• admin数据表(管理员表)

create table admin(work_id varchar(32) primary key not null,                     pwd varchar(32) not null,                     ad_name varchar(32),                     phone varchar(32));

 

 

 

 

 

 

 

五、数据库设计总结

在系统开发之前，数据库的设计是首要并且关键的一个步骤，对于此系统的数据表，上面介绍的是最后确定的数据表。数据库设计并不能一蹴而就，这里总结一下我不断修改的想法过程。

第一次根据系统所需要的数据建立关系模式，在保证函数依赖和无损连接的情况下，将属性phone、address放入reserve表中，users表和reserve的关系模式满足了第三范式的要求。起初设计表时候考虑是否将reserve和info合并，后来发现在物理设计和实际场景下，订单信息表info由用户预约后的reserve表生成，并且加入特有的属性订单状态status、口罩分配数量allocate_num和订单号order_id。

至此从reserve表脱离出来，后期用户、管理员、快递员对订单的查询的操作，实现了模块化的处理，不仅减少了表的连接，而且物理操作（前后端编程）更加容易，因为数据库设计中也要符合物理上的要求，所以关系模式分解为两个表，虽然增加了部分数据上的冗余，但是保证信息的模块化和实际应用的合理性。

在口罩预约管理系统数据库设计中遇到了这些问题，后来经过了理论上的分析和实际运用，解决了设计上的问题，认识到了数据模型建立的关键性。目前该数据库还可以进一步完善。

这一篇主要讲的是口罩预约管理系统定位的功能模块以及数据库设计的具体过程，这也是完成这个系统第一阶段的完整部分，下一篇将介绍系统前后端的搭建以及数据库连接，使用到的知识包括前端（HTML+CSS+Javascript）、后端（PHP）和MySQL数据库的操作，目的是建立简洁、包含基本功能的（口罩预约管理）应用系统。

 

此文转载文，著作权归作者所有，如有侵权联系小编删除！

原文地址：https://blog.csdn.net/Charzous/article/details/108576174

源码地址点这