口罩預約管理系統——資料庫設計(前端+PHP+MySQL)
目錄
一、背景
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資料庫。
系列文章:
(一)口罩預約管理系統——資料庫設計(前端+PHP+MySQL)
(二)口罩預約管理系統——系統網站實現(前端+PHP+MySQL)
我的部落格園://www.cnblogs.com/chenzhenhong/p/13677690.html
我的CSDN部落格://blog.csdn.net/Charzous/article/details/108576174