本文详细介绍数据库从零到一的完整设计，因基于课程报告衍生，因此文章内容仅供举例参考，与商业应用有较大差距，适合学习数据库的同学参考学习使用（截至发文时笔者为大三CS学生一枚）。

前言

总览整个课程报告的实验要求，本质上在于让每位同学了解数据库系统设计的过程，包括概念的诞生、数据库的设计、数据库的优化、数据库的具体实现。由此观之，项目之间环环相扣，具有层层递进的关系。根据这一理解，在实验初期，本人大致总结出数据库设计从零到一的相关流程，并按照该流程进行整体项目的推进，展示如下图所示。

在本课程报告中，Project1要求进行概念模式设计、数据库模式设计，Project2要求进行数据库模式优化，本人在实际推进过程中，首先进行了概念模式设计，然后根据所得的概念模式（即实体关系图）进行了数据库模式的设计与优化。因此在Project1中只涉及到概念模式的设计，Project2中将数据库模式的设计与优化进行合并阐述。Project3使用Python+Flask+mysql进行了数据库模式的实现和查询功能。在此特作说明。

Project1:概念模式设计

项目背景

随着社会的发展和生活节奏的加快，越来越多的人选择在外面工作或学习，导致他们没有足够的时间去烹饪食物。因此，外卖服务在市场上变得越来越受欢迎。为了满足人们对便捷餐饮服务的需求，外卖系统应运而生。为了给外卖系统提供可靠而有效的数据信息存储保障，我们根据外卖系统的运行方式和需求进行数据库搭建，并通过规范化提升数据存储效率和查询性能。

问题分析

外卖系统中的关系错综负责，要想设计出一个逻辑清晰、性能良好的数据库，我们需要充分了解外卖系统的运作方式以及其中可能涉及到的各种主体，并列出主体之间可能存在的种种关系，根据实体和关系设计出相对应的ER图，之后再根据ER图（概念模式）转化出关系模式（数据库模式），并通过规范化设计优化数据库结构。

本项目中实现的外卖系统并非面面俱到，最终设计出的系统虽整体上能够走通外卖商品流通的流程，但是在一些细节方面还有很多不足，仍有非常多的优化空间。以下为本系统的需求描述。

需求描述

根据外卖系统的常规运行逻辑，笔者建立了如下描述的一种简单运行场景：

• 在一个外卖系统中，用户可以查询不同店铺的不同食品信息，并选择餐馆中的诸多商品进行购买，每次购买创建一个订单，用户可以选择订单的支付方式（例如银行卡支付、微信支付、支付宝支付等）。
• 每一个订单会被目标餐馆获取，且该订单会被唯一派发给一名送餐员进行配送，送餐员使用的配送小车由公司统一配备，一人一辆， 订单在整个外卖流程中的配送状态可被实时更新。
• 用户在接收到餐品后，可以对食品所属餐馆进行评论，同时也可以对送餐员的派送服务进行评论，评论包括打分、文字评价、图片描述等。
• 管理员可以管理用户、餐馆、送餐员、订单的相关信息，在必要时可对餐馆、送餐员、用户做出管理和处罚。
• 整个系统按此闭环运行。

实体分析

从以上需求描述中，笔者总结出十一个实体类型，并大致概括出每个实体可能具有的实体属性，展示如下：

关系分析

结合以上实体与需求分析，初步总结出实体之间的关系，陈列并说明如下：

• 用户与订单的1：n关系（一个用户可以创建多个订单，一个订单只属于一个用户）;
• 餐馆与订单的1：n关系（一个餐馆可以接收多个订单，一个订单只属于一个餐馆）;
• 餐馆与食品的1：n关系（一个餐馆可以提供多种食品，一个食品只能属于一个餐馆）;
• 订单与支付的1：1关系（一个订单只能对应一个支付记录，一个支付记录只能对应一个订单）;
• 订单与配送状态的n：1关系（一个订单对应一个派送状态，一个派送状态可以对应多个订单）;
• 订单与送餐员的n：1关系（一个订单只能分配给一个送餐员，一个送餐员可以接受多个订单）;
• 送餐员与配送车辆的1：1关系（一个送餐员只能有一辆配送车辆，一辆配送车辆只能配送给一位配送员）;
• 派送评论与订单的1：1关系（一个订单有一个派送评论，一个派送评论对应于一个订单）;
• 派送评论与送餐员的n：1关系（一个派送评论只属于一个送餐员，一个送餐员可以有多个派送评论）;
• 餐馆评论与订单的1：1关系（一个餐馆评论对应一个订单，一个订单只能有一个餐馆评论）;
• 餐馆评论与餐馆的n：1关系（一个餐馆评论只属于一个餐馆，一个餐馆可以有多个餐馆评论）;
• 管理员与用户的m:n关系（一个用户可以被多个管理员管理，一个管理员可以管理多个用户）;
• 管理员与餐馆的m：n关系（一个餐馆可以被多个管理员管理，一个管理员可以管理多个餐馆）;
• 管理员与送餐员的m：n关系（一个送餐员可以被多个管理员管理，一个管理员可以管理多个送餐员）;

实体关系图（ER图）绘制

根据以上实体和关系，初步绘制ER图的关系部分如下图所示。

（笔者使用Excalidraw完成ER图的绘制，Excalidraw是一款免费的画图Web网页，可以满足简单的绘图需求——🔗Excalidraw | Hand-drawn look & feel • Collaborative • Secure）

为什么初始只绘制ER图的关系部分？这是由于在一开始定义实体的属性时，我们并不能确定一些关系是不是能够附带属性或者表示原本在实体中的一些属性，因为最开始的设计大概率是不完备的，因此通过首先绘制出ER图的关系部分，我们可以确定出一些关系附带的属性以及可以从实体中拿出来赋给关系的属性，从而让系统更加符合逻辑。

从上图中可以看到——

• 送餐员和配送车辆之间的“拥有”关系附带了“分配时间”的属性，表示送餐员是在什么时候拥有的配送车辆; 
• 订单与送餐员之间的“分配”关系附带了“分配时间”和“限制到达时间”属性，表示该订单什么时候被送餐员接单以及送餐员应该在什么时间之前将订单配送完成；
• 餐馆和食品之间的“拥有”关系附带了“数量”属性，表示餐馆拥有某种食品的数量是多少;

需要特别说明的是，笔者在进行到实验后半程时，为了让关系的属性表现得更明显，才额外添加了送餐员和配送车辆的关系属性以及订单与送餐员的关系属性，初始时只有餐馆和食品的“拥有”关系附带了属性，所以在之后的数据库模式设计的时候，只能看到“数量”属性出现。

接下来将实体的属性添加到ER图中，获得最终的实体关系图如下。

在以上的ER图中还无法直观地看出外键关系（实际上，在ER图中本来就无法体现外键），接下来需要根据ER表中的实体和关系进行转化，获得该外卖系统的关系数据库模式，在该模式中，外键关系可以直观地体现出来。 

Project2:数据库模式设计与优化

数据库三要素描述

本实验中，我选择的数据库模式是关系数据库模式，有关关系数据库模式的三要素描述如下所示：

（1）数据结构——数据结构指的是数据库中存储数据的组织方式。在关系数据库中，数据结构主要由表（Table）来表示，每个表都包含若干列（Column），每列定义了一种数据类型，而每行（Row）则表示一个具体的数据记录。表之间的关系通过键（Key）来建立，常见的有主键（Primary Key）和外键（Foreign Key）。

（2）数据操作——数据操作指的是对数据库中数据的增删改查等操作。主要的数据操作包括：

        -插入（insert）：向表中插入新的数据记录。

        -查询（Select）： 从表中检索数据。

        -更新（Update）： 修改表中现有的数据记录。

        -删除（Delete）： 从表中删除数据记录。

        -事务（Transaction）： 一组数据库操作，要么全部执行成功，要么全部回滚到初始状态。

当然，对于关系数据库而言，其底层运算涉及到关系代数，关系代数的运算包括并、交、减、笛卡尔积、选择、投影、连接、除。

（3）数据约束——数据约束定义了对数据的限制条件，以确保数据库中的数据符合特定的规范和完整性要求。主要的数据约束有：

        -主键约束（Primary Key Constraint）： 用于唯一标识表中的每个记录。

        -外键约束（Foreign Key Constraint）： 用于定义表之间的关系，确保外键的值与另一表的主键相匹配。

        -唯一约束（Unique Constraint）： 确保特定列的值在表中是唯一的。

        -默认约束（Default Constraint）： 定义列的默认值。

        -断言约束（Check Constraint）： 断言指数据库状态必须满足的逻辑条件。对于每个更新事务，都用约束库中的断言对它进行检查。如果发现更新违反了约束，就卷回该事务。

以下在构造关系模式的过程中，我会在适当位置表明关系数据库三要素的相关体现。

关系数据库模式划分

在划分关系模式时，遵守的规则如下：

1. 对于1：1的关系，任取一方的主键放入另一方的属性中（如果关系有属性也一并放入）；
2. 对于1：n的关系，取1表示的一方的主键放入n表示的一方的属性中（如果关系有属性也一并放入），此时该被放入的主键为n表示的一方的外键；
3. 对于m：n的关系，首先单独表示m一方和n一方的属性，然后将关系单独成表，使用m一方的主键和n一方的主键作为共同主键，如果关系有属性，则一并放入。

根据以上规则，可以划分各表项如下（实下划线加粗表示主键，实下划线倾斜表示外键。以下结构可以初步表明关系数据模型的数据结构，即以表的形式存储，以下定义的行中的每一个元素都标识了之后在此列中存储的数据的意义；当然，除此之外，表项中表明的主键与外键也体现了关系数据模型的数据约束，之后会统一对数据约束进行说明）：

    用户（用户ID，用户名，密码，联系电话）;
    订单（订单ID，用户ID，配送状态ID，餐馆ID，送餐员工ID, 配送地址，总价，下单时间）;
    支付记录（支付记录ID，支付方式，支付时间，支付金额，订单ID）;
    配送状态（配送状态ID，状态名称）；
    就餐评论（就餐评论ID，评分，评论内容，评论时间，订单ID，餐馆ID）；
    配送评论（配送评论ID，评分，评论内容，评论时间，订单ID，送餐员工ID）；
    餐馆（餐馆ID，用户名，密码，餐馆名，地址，描述）；
    食品（食品ID，食品名，食品价格，餐馆ID，食品数量）；
    送餐员（送餐员工ID，用户名，密码，入职时间，联系电话，工作状态）；
    配送车辆（车辆ID，车牌号，车辆类型，状态，送餐员工ID）；
    管理员（管理员ID，用户名，密码）；
    管理员_用户（管理员ID，用户ID）；
    管理员_送餐员（管理员ID，送餐员工ID）；
    管理员_餐馆（管理员ID，餐馆ID）；

初步判断数据库优劣及优化

判断一个数据库设计的好坏，重点就关注两个方面——是否存在数据冗余；是否存在增删改异常。

• 数据冗余（data redundancy）——是指在数据库中存储相同信息的多个副本或重复数据的情况。这可能会导致存储空间的浪费，并增加了数据维护和更新的复杂性。冗余数据的存在还可能导致数据不一致性，因为对一个地方的修改未及时同步到其他地方。
• 插入异常（Insertion Anomaly）——当尝试插入新数据时，由于某些信息的缺失而导致插入操作失败。这通常发生在包含依赖关系的表中，如果某些关联信息缺失，插入新数据就会受到限制。
• 更新异常（Update Anomaly）——当尝试更新数据时，由于更新不到位而导致数据不一致。例如，更新了某个实体的信息，但由于某些原因，并未更新所有相关的地方，导致数据在不同地方出现不一致。
• 删除异常（Deletion Anomaly）——当尝试删除数据时，由于删除操作对其他数据产生了影响而导致数据不一致。例如，删除某个实体的信息，但由于其他表依赖于该信息，删除操作可能会影响到其他数据的完整性。

根据以上定义初步判断本人创建的若干数据库表，可以发现——每个数据表中仅包含与自身属性直接相关的信息，没有其他的冗余信息；

对于每个数据表而言，其在插入时，表项内的所有数据都是已知的，不会出现插入时某些信息未输入而导致无法插入的情况；

而对于删除情况而言，因为表项内的数据都与本表主键ID有着直接的关系，因此当该对象被删除时，表项内有关该对象的数据都不再有意义，从而不存在删除异常；

对于更新操作，本人所创建的数据表中基本上不存在数据重叠的情况，针对数据重叠的少部分项，也是构建了外键关系或者本身与表项主键是1：1关系，不存在更新后的数据不一致情况。

根据范式理论进一步判断和优化

为了进一步说明所构建的数据库的强健性和稳定性，将各表的函数依赖关系推理如下：

【判断是否满足一二三范式，可以参见该篇博客🔗1NF、2NF、3NF、BCNF精讲-CSDN博客】

(1)  用户（用户ID，用户名，密码，联系电话）

--主属性为用户ID，非主属性为用户名、密码、联系电话

--函数依赖表 = { 用户ID -> 用户名；用户ID->密码；用户ID->联系电话}

--非主属性对主属性不存在部分函数依赖及传递函数依赖，且主属性不存在部分函数依赖和传递函数依赖，该表满足3NF以及BCNF

(2)  订单（订单ID，用户ID，配送状态ID，餐馆ID，送餐员工ID, 配送地址，总价，下单时间）

--主属性为订单ID，非主属性为配送地址，总价，下单时间，用户ID，配送状态ID，餐馆ID，送餐员工ID

--函数依赖表={订单ID->配送地址；订单ID->总价；订单ID->下单时间；订单ID->用户ID；订单ID->餐馆ID；订单ID->配送状态ID；订单ID->送餐员工ID}

--非主属性对主属性不存在部分函数依赖及传递函数依赖，且主属性不存在部分函数依赖和传递函数依赖，该表满足3NF以及BCNF。

(3)  支付记录（支付记录ID，支付方式，支付时间，支付金额，订单ID）

--候选键有支付记录ID、订单ID，即主属性为支付记录ID与订单ID，非主属性有支付方式、支付时间、支付金额

--函数依赖表={支付记录ID->支付方式；支付记录ID->支付时间；支付记录ID->支付金额；支付ID<->订单ID；订单ID->支付方式；订单ID->支付时间；订单ID->支付金额}

--非主属性对主属性不存在部分函数依赖及传递函数依赖，且主属性不存在部分函数依赖和传递函数依赖，该表满足3NF以及BCNF。

（4） 配送状态（配送状态ID，状态名称）

--候选键有配送状态ID和状态名称，说明主属性有配送状态ID和状态名称，没有非主属性。

--函数依赖表={配送状态ID<->状态名称}

--显然该表满足3NF，且该表也满足BCNF。

（5）就餐评论（就餐评论ID，评分，评论内容，评论时间，订单ID，餐馆ID）

--候选键有就餐评论ID，订单ID，说明主属性有就餐评论ID、订单ID，非主属性有评分、评论内容、评论时间、餐馆ID

--函数依赖表={就餐评论ID<->订单ID，就餐评论ID->评分，就餐评论ID->评论内容，就餐评论ID->评论时间，就餐评论ID->餐馆ID，订单ID->评分，订单ID->评论内容，订单ID->评论时间，订单ID->餐馆ID}

--非主属性对主属性不存在部分函数依赖及传递函数依赖，且主属性不存在部分函数依赖和传递函数依赖，该表满足3NF以及BCNF。

（6）配送评论（配送评论ID，评分，评论内容，评论时间，订单ID，送餐员工ID）

--候选键有配送评论ID，订单ID，说明主属性有配送评论ID、订单ID，非主属性有评分、评论内容、评论时间、送餐员工ID

--函数依赖表={配送评论ID<->订单ID，配送评论ID->评分，配送评论ID->评论内容，配送评论ID->评论时间，配送评论ID->送餐员工ID，订单ID->评分，订单ID->评论内容，订单ID->评论时间，订单ID->送餐员工ID}

--非主属性对主属性不存在部分函数依赖及传递函数依赖，且主属性不存在部分函数依赖和传递函数依赖，该表满足3NF以及BCNF。

（7） 餐馆（餐馆ID，用户名，密码，餐馆名，地址，描述）；

--主属性为餐馆ID，非主属性为用户名、密码、餐馆名、地址、描述

--函数依赖表={餐馆ID->用户名;餐馆ID->密码；餐馆ID->餐馆名；餐馆ID->地址；餐馆ID->描述}

--非主属性对主属性不存在部分函数依赖及传递函数依赖，且主属性不存在部分函数依赖和传递函数依赖，该表满足3NF以及BCNF。

（8） 食品（食品ID，食品名，食品价格，餐馆ID，食品数量）

--主属性为食品ID，非主属性为食品名、食品价格、餐馆ID、食品数量

--函数依赖表={食品ID->食品名；食品ID->食品价格；食品ID->食品价格；食品ID->餐馆ID；食品ID->食品数量}

--非主属性对主属性不存在部分函数依赖及传递函数依赖，且主属性不存在部分函数依赖和传递函数依赖，该表满足3NF以及BCNF。

(9)-(11)

送餐员（送餐员工ID，用户名，密码，入职时间，联系电话，工作状态）；
配送车辆（车辆ID，车牌号，车辆类型，状态，送餐员工ID）；
管理员（管理员ID，用户名，密码）；

--均同理，以上三个表的主属性均为ID，且主属性决定非主属性，非主属性没有依赖关系，京判断可得，以上三表均满足3NF以及BCNF。

(12)-(14)

管理员_用户（管理员ID，用户ID）；
管理员_送餐员（管理员ID，送餐员工ID）；
管理员_餐馆（管理员ID，餐馆ID）；

对于这三个表来说，表中均没有非主属性，因此每个表都是3NF。又因为管理员和用户、送餐员工、餐馆之间都是多对多关系，意味着均没有依赖关系，所以这三个表同时也满足BCNF。

如上分析，该关系模式已经完成规范化，整个数据库表都符合BCNF。

此时，我们可以详细定义数据库中每个表的数据类型并且更详细地说明数据约束。根据之前所创建的数据库表，进一步确定表中每个数据的数据类型并设置好主外键关系，最终使用mysql的workbench绘制ER图展示如下图。

【mysql安装与workbench绘制使用可参见博客🔗待更新】

观察图中的属性——

• 黄色图标表示主键；
• 蓝色空心菱形表示实体属性，空心表示该属性可以为NULL；
• 蓝色实心菱形也表示实体属性，实心表示该属性不可以为NULL；
• 红色菱形表示外键，其中空心表示属性可为NULL，而实心表示属性不可为NULL。

根据以上描述，我们可以初步感受到表中存在的种种数据约束，下面进行一个比较规范的整理描述：

• 表中定义主键，表示该属性可以唯一标识该行元组，若被定义为主键，则该属性不能为空且必须唯一;
• 表中定义外键，表示该属性（组）不是本关系的键，而是引用其他关系或本关系的键。定义外键则表明该属性必须与引用关系中的键对应，不能额外多出一个引用关系中不存在的键;
• 表中还可以定义默认值、非空设置、唯一设置等，分别表示当该值不存在时设置为默认值、该值不能为空、该值在整个表的该属性值中不存在重复，这些都是对数据的约束;
• 还有断言约束，即要求某一数据必须满足XX条件，负责不予进行数据操作；例如在该表中要求订单的付款金额必须为大于零，否则不予插入。

除了以上约束外，还有CHECK约束、触发子约束等等，在此不做展开。

代求关系和关系代数表达

在该部分中，笔者所列出的关系可能并非在实际应用中一定会用到的关系，以下所列的关系更多是用于笔者自身练习关系代数的写法，在之后具体实现数据库的时候笔者会根据系统中的实际需求进行实现。

(1)找出餐馆名为“家常小馆”的餐馆的所有食品和价格

(2)找出餐馆名为“川湘小厨”的餐馆的所有评价内容

(3)请找出ID为“101001234”管理的所有用户ID 

(4)请找出用户ID为“213211221”的用户给出的所有配送评价内容和评分 

(5)请找出使用车牌号为“苏A.12345”的送餐员的入职时间

(6)找出在2023年10月1日到2024年1月1日点过餐的用户

(7)找出至少在两家餐馆点过餐的用户 

(8)找出在所有餐馆中点过餐的用户

(9)找出没被送餐人员ID为“313211098”和“313215781”的送餐员送过餐的餐馆 

(10)找出至少在同一家餐馆点过两次餐的用户 

Project3:Web架构实现

在该项目中，笔者使用Python+Flask框架搭载mysql完成项目实现。

【注意，该Web项目只实现了数据库查找与内容展示（即搜索功能），并没有实现插入、删除功能，因为实验要求只涉及到搜索】

【有关使用Python+Flask框架搭载MySQL的源码与编码指导可参见博客🔗待更新】

首先在mysql中根据上述转化出的数据库模式创建数据库和数据表并插入数据，如下展示三个示例表中的数据以供参考。

示例一：用户（用户ID，用户名，密码，联系电话）

 示例二：订单（订单ID，用户ID，配送状态ID，餐馆ID，送餐员工ID, 配送地址，总价，下单时间）

因整体表格过宽，故部分数据在表格中未完全显示。

示例三： 支付记录（支付记录ID，支付方式，支付时间，支付金额，订单ID）

完成数据插入后，接下来使用Python搭建Flask框架，实现一个简单的外卖系统的搜索功能。框架结构如下图所示。其中img是用于页面背景插图，templates中是定义好的若干页面，主函数在main.py中运行，其中包含了页面跳转路由以及数据库操作。

登陆界面 

运行main函数，并进入到用户界面后，初始界面如下图所示。首先是一个登陆界面，用户可以输入自己的用户名和密码完成登录。在本系统中设置了四种身份登录，分别是用户、商家、骑手、管理员。交互者输入自己的用户名和密码后，系统会自动判断该账号是否存在以及该账号的身份是什么，并进而跳转到相应的界面。

在这里，笔者提供了四种示例登陆账号供查看，陈列如下：

• 用户身份——用户名：测试用户，密码：1234567
• 商家身份——用户名：测试餐馆，密码：7654321
• 骑手身份——用户名：测试员工，密码：1357246
• 管理员身份——用户名：admin1，密码：adminPass1

用户界面

首先测试用户界面。输入用户账号登录之后，可以看到用户界面提供三种搜索操作以及退出操作，分别是

（1）餐馆列表——可用于查看所有的餐馆信息，如下图

（2）我的订单——可用于查看该用户的所有订单，如下图

（3）支付记录——可用于查看该用户对于所有订单的支付记录，如下图

（4）退出——返回登陆界面

商家界面

接下来测试商家界面。输入商家账号登录之后，可以看到商家界面提供三种搜索操作以及退出操作，分别是

（1）餐馆食物——可用于查看餐馆中所有出售的食物，如下图

（2）餐馆订单——可用于查看商家接到的所有订单，如下图

（3）餐馆评论——可用于查看商家收到的所有评论，如下图

（4）退出——返回登陆界面

骑手界面

接下来测试骑手界面。输入骑手账号登录之后，可以看到骑手界面提供三种搜索操作以及退出操作，分别是

（1）我的接单——可用于查看该骑手接收到的所有订单，如下图

（2）客户评论——可用于查看该骑手收到的所有评论，如下图

（3）我的信息——可用于查看骑手查看自己的个人信息，包括注册信息以及车辆信息，如下图

（4）退出——返回登陆界面

管理员界面

最后测试管理员界面。输入管理员账号登录之后，可以看到管理员界面提供四种搜索操作以及退出操作，分别是

（1）用户列表——可用于查看系统中的所有用户信息，如下图

（2）餐馆列表——可用于查看系统中的所有餐馆信息，如下图

（3）骑手列表——可用于查看系统中的所有骑手信息，如下图

（4）订单列表——可用于查看系统中的所有订单信息，如下图

（5）退出——返回登陆界面

源码

SQL语句示例展示

以上涉及到数据库实际搜索功能的实现，底层使用Python与SQL语言实现，在此简单举两个示例来介绍底层SQL语言使用。

（1）管理员搜索所有订单信息，包括订餐人姓名、订单状态、餐馆名称、骑手名称

SELECT order_ID, delivery_address, order_price, order_time, user_name, status_name, restaurant_name, delivery_man_username 
FROM  order ,  user ,  distribution_status ,  restaurant ,  delivery_man  
WHERE order.user_ID = user.user_ID AND delivery_status_ID = status_ID AND order.restaurant_ID = restaurant.restaurant_ID AND deliveryman_ID = delivery_man_ID 
ORDER BY order_ID DESC

（2）商家筛选出属于自家餐馆的所有评论

SELECT * 
FROM `dining_review` 
WHERE restaurant_ID = %s

总结

以上为整个大作业的核心内容，所有内容均为笔者根据自己的实验报告整理所得，基本上也可以视作一份比较完整的实验报告，里面涉及到的一些额外的知识点笔者也会慢慢更新，希望对读者的数据库学习有所帮助~

整个Web页面的源代码，笔者已随本文附带，感兴趣的同学可下载参考。

完结撒花❀！