口罩預約管理系統——資料庫設計（前端+PHP+MySQL）

Charzueus發表於2020-09-16

一、背景

　　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資料庫的操作，目的是建立簡潔、包含基本功能的（口罩預約管理）應用系統。