一、背景
2020年的疫情影響了我們的生產生活,政府不斷加大力度聯防聯控,遏制疫情的蔓延勢頭,全國人民共同加入抗擊疫情的戰“疫”隊伍,疫情資訊發布、物資調配保障顯得尤其重要,資訊越詳細,物資保障越充分,公眾的疑慮就越少,“疫情地圖”、“實時資訊”、“口罩預約”的各種 APP、小程式和系統應運而生,不斷規范化,納入疫情發布的官方渠道,這些舉措讓公眾能全方位獲取疫情防控進展的資訊,及時、準確、全面顯得至關重要,
另外,這個小專案也是過去許久,疫情期間也有在市政官方系統預約口罩的經歷,(?,?)沒有中簽過,不過因此對它的預約系統感興趣,考慮自己可以簡單做一個web網站版本的預約管理系統,實作基本功能,也正好課程需要完成一個資料庫設計,然后做一個相對完整的應用系統,所以,這個小專案就此開始,
二、口罩預約管理系統介紹
1、功能模塊及特點
本系統主要任務是實作用戶口罩預約、市政人員(管理員)分配以及快遞員接單配送的比較完整的功能,市政人員(管理員),普通用戶,快遞員這三種用戶權限,功能明確,各自獨立,而又存在著一定的聯系,讓政府更方便地管理、更高效地分配,
具體模塊決議如下:
- 普通用戶模塊:創建賬號,登錄系統填寫預約資訊確認提交,查看訂單狀態,修改訂單預約資訊,修改個人注冊資訊,
- 市政人員(管理員)模塊:查詢已注冊用戶資訊,修改或洗掉用戶資訊,對用戶的預約訂單進行合理分配,包括審核以及分配快遞員,管理每種型別口罩,查詢庫存數量,合理分配用戶預約的口罩數量,按需求查看訂單的配送狀態,
- 快遞員模塊:查看分配到的訂單,選擇接單配送,完成配送選擇關單,按訂單狀態查看訂單,統計完成的訂單數量,
2、系統結構
系統功能結構圖:

三、資料庫設計
在口罩預約管理系統初期階段,我們需要設計好系統存取資料資訊的一個資料庫,資料庫設計也是一個重點難點,完整的資料庫基本滿足設計基本要求,包括資料庫關系模式分析,處理好函式依賴問題,還有關系模式至少滿足第三范式等,學過資料庫系統概論會基本了解這些知識以及它的重要性和難度,
以目前個人能力,這個系統資料庫的建立暫時滿足最基本的要求,初步進行了函式依賴分析,另外根據所需功能,關系模式不是很復雜,第三范式的滿足只存在于部分關系模式中,
我使用的是MySQL資料庫,前期建立資料字典,然后以此進一步建立資料庫及資料表,確定口罩預約管理資料庫關系模式,分析關系模式的函式依賴和范式要求,接下來將具體介紹資料字典、資料模型和概念模型(E-R 圖),
1、資料字典
根據系統功能需求,系統資料庫包含了8個資料表,詳細內容(欄位、資料型別、碼)如下資料字典:
1、admin表
| 屬性名 | 資料描述 | 資料型別 | 是否為空 | 備注 |
| work_id | 管理員賬號 | varchar(32) | 不允許 | 主碼 |
| ad_name | 管理員名 | varchar(32) | 不允許 |
|
| pwd | 密碼 | varchar(32) | 不允許 |
|
| phone | 電話 | varchar(32) |
|
|
2、users表
| 屬性名 | 資料描述 | 資料型別 | 是否為空 | 備注 |
| user_id | 用戶賬號 | varchar(32) | 不允許 | 主碼 |
| user_name | 姓名 | varchar(32) | 不允許 |
|
| ID | 身份證號 | varchar(32) | 不允許 |
|
| pwd | 密碼 | varchar(32) | 不允許 |
|
| register_date | 注冊時間 | datetime |
|
|
3、deliver表
| 屬性名 | 資料描述 | 資料型別 | 是否為空 | 備注 |
| deliver_id | 賬號 | varchar(32) | 不允許 | 主碼 |
| deliver_name | 姓名 | varchar(32) | 不允許 |
|
| phone | 聯系方式 | varchar(32) |
|
|
| pwd | 密碼 | varchar(32) | 不允許 |
|
4、mask表
| 屬性名 | 資料描述 | 資料型別 | 是否為空 | 備注 |
| mask_type | 型別號 | varchar(32) | 不允許 | 主碼 |
| m_name | 名稱 | varchar(32) | 不允許 |
|
| remain_num | 庫存量 | int(11) | 不允許 |
|
| price | 價格 | int(11) |
|
|
5、info表
| 屬性名 | 資料描述 | 資料型別 | 是否為空 | 備注 |
| order_id | 訂單號 | varchar(32) | 不允許 | 主碼 |
| user_id | 用戶賬號 | varchar(32) | 不允許 | 外碼,參照users |
| user_name | 用戶姓名 | varchar(32) | 不允許 |
|
| allocate_num | 分配數量 | int(11) | 不允許 |
|
| phone | 聯系方式 | varchar(32) | 不允許 |
|
| address | 配送地址 | varchar(32) | 不允許 |
|
| status | 訂單狀態 | varchar(32) | 不允許 |
|
| re_date | 下單日期 | datetime |
|
|
6、reserve表
| 屬性名 | 資料描述 | 資料型別 | 是否為空 | 備注 |
| user_id | 預約賬號 | varchar(32) | 不允許 | 主碼,參照users |
| re_date | 下單日期 | datetime | 不允許 | 主碼 |
| mask_type | 型別 | varchar(32) | 不允許 | 外碼,參照mask |
| ID | 身份證號 | varchar(32) | 不允許 |
|
| r_num | 預約數量 | int(11) | 不允許 |
|
| ex_date | 期望到貨日 | date |
|
|
| phone | 聯系方式 | varchar(32) |
|
|
| address | 地址 | varchar(32) |
|
|
7、allocate表
| 屬性名 | 資料描述 | 資料型別 | 是否為空 | 備注 |
| work_id | 分配人 | varchar(32) | 不允許 | 主碼,參照admin |
| order_id | 訂單號 | varchar(32) | 不允許 | 主碼,參照order |
| allocate_time | 分配日期 | datetime |
|
|
| deliver_id | 快遞員 | varchar(32) | 不允許 | 主碼,參照deliver |
8、take表
| 屬性名 | 資料描述 | 資料型別 | 是否為空 | 備注 |
| deliver_id | 快遞員賬號 | varchar(32) | 不允許 | 主碼,參照deliver |
| order_id | 訂單號 | varchar(32) | 不允許 | 主碼,參照order |
| take_date | 接單日期 | datetime |
|
|
| finish_date | 關單日期 | datetime |
|
|
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));
- users資料表(用戶表)
create table admin(work_id varchar(32) primary key not null,
pwd varchar(32) not null,
ad_name varchar(32),
phone varchar(32));
- delivers資料表(快遞員表)
create table delivers(deliver_id varchar(32) primary key not null,
pwd varchar(32) not null,
deliver_name varchar(32) not null,
phone varchar(32));
- reserve資料表(用戶預約表)
create table reserve(user_id varchar(32) not null,
re_date datetime not null,
foreign key (user_id) references users(user_id),
primary key(user_id,re_date),
ID varchar(32) not null,
r_num int not null,
ex_date date not null,
phone varchar(32) not null,
address varchar(32) not null);
- mask資料表(口罩資訊表)
create table mask(mask_type varchar(32) primary key not null,
store varchar(32) not null,
remain_num int not null,
price int not null);
- info資料表(訂單表)
create table info(order_id varchar(32) primary key not null,
user_id varchar(32) not null,
foreign key (user_id) references users(user_id),
user_name varchar(32) not null,
allocate_num int not null,
statue varchar(32) not null,
re_date datetime not null,
phone varchar(32) not null,
address varchar(32) not null );
- allocate資料表(管理員分配表)
create table allocate(work_id varchar(32) not null,
order_id varchar(32) not null,
deliver_id varchar(32) not null,
allocate_time datetime not null,
primary key (work_id,order_id),
foreign key (work_id) references admin(work_id),
foreign key (order_id) references info(order_id) );
- take資料表(快遞員接關單表)
create table take(deliver_id varchar(32) not null,
order_id varchar(32) not null,
deliver_name varchar(32) not null,
take_time datetime not null,
finish_time datetime not null,
primary key (deliver_id,order_id),
foreign key (deliver_id) references delivers(deliver_id),
foreign key (order_id) references info(order_id) );
- deli_order視圖(快遞員查看訂單表)
create view deli_order as
select order_id,mask_type,allocate_num,phone,addresss,statue,re_date
from info;
五、資料庫設計總結
在系統開發之前,資料庫的設計是首要并且關鍵的一個步驟,對于此系統的資料表,上面介紹的是最后確定的資料表,資料庫設計并不能一蹴而就,這里總結一下我不斷修改的想法程序,
第一次根據系統所需要的資料建立關系模式,在保證函式依賴和無損連接的情況下,將屬性phone、address放入reserve表中,users表和reserve的關系模式滿足了第三范式的要求,起初設計表時候考慮是否將reserve和info合并,后來發現在物理設計和實際場景下,訂單資訊表info由用戶預約后的reserve表生成,并且加入特有的屬性訂單狀態status、口罩分配數量allocate_num和訂單號order_id,
至此從reserve表脫離出來,后期用戶、管理員、快遞員對訂單的查詢的操作,實作了模塊化的處理,不僅減少了表的連接,而且物理操作(前后端編程)更加容易,因為資料庫設計中也要符合物理上的要求,所以關系模式分解為兩個表,雖然增加了部分資料上的冗余,但是保證資訊的模塊化和實際應用的合理性,
在口罩預約管理系統資料庫設計中遇到了這些問題,后來經過了理論上的分析和實際運用,解決了設計上的問題,認識到了資料模型建立的關鍵性,目前該資料庫還可以進一步完善,
這一篇主要講的是口罩預約管理系統定位的功能模塊以及資料庫設計的具體程序,這也是完成這個系統第一階段的完整部分,下一篇將介紹系統前后端的搭建以及資料庫連接,使用到的知識包括前端(HTML+CSS+Javascript)、后端(PHP)和MySQL資料庫的操作,目的是建立簡潔、包含基本功能的(口罩預約管理)應用系統,
本篇的口罩預約管理系統資料庫maskOrder.txt已上傳,可直接匯入本地MySQL資料庫,
我的CSDN博客:https://blog.csdn.net/Charzous/article/details/108576174
轉載請註明出處,本文鏈接:https://www.uj5u.com/qita/46693.html
標籤:其他
