蓝旭后端暑期第五次培训课

蓝旭后端暑期第五次培训课

一、需求分析

好的设计应该针对需求来做。

问：需求分析，分析谁的需求？
答：分析用户的需求。
用户需求，就是用户对产品功能的需求，例如：
用户可以删除评论；
商家可以自己设置推荐商品；
用户可以点赞商店；
…
而互联网产品正是由一个个用户所需要的产品功能组合而成。

显性需求：也叫基本需求，是用户自己明确感受并可以用语言描述的。当用户的显性需求被满足时，用户一般不会兴奋或惊喜，而不被满足时，用户则会产生抱怨；
隐性需求：也叫兴奋需求，是用户不能完全清晰感受和用语言描述的。用户的隐性需求被满足时，用户一般会兴奋或惊喜，而不被满足时，用户也不会产生抱怨。隐性需求可以增加用户粘性。

我们以“今日头条”这款产品为例：最初用户的需求可能只是“浏览新闻和资讯”，但在用户不断深入的过程中，用户却产生了更多的需求——从单纯的“想要获知信息”慢慢地对这个平台产生依赖。当一款新闻产品慢慢被赋予“打发时间”、“消磨时间”的娱乐性质后，用户黏性自然就提高了。

所以，为了设计一个项目，我们需要分析用户的需求，分析出项目应该实现的功能点。
例如：对于“用户可以管理自己发布的评论”这个功能，我们可以得到项目应该实现以下功能点：
用户可以查看自己发布过的评论；
用户可以修改评论；
用户可以删除评论；

二、简单的项目概要设计

这里只讲几个关键的方面。

技术选型。
一般技术选型是在用户需求分析之后才做的，可以理解为先分析要做什么，再分析怎么做。咱们当前阶段还不需要进行技术选型，后期大家学习到了更多的技术后再结合实际情况进行技术选型

1.根据用户需求，分析出不同角色行为，形成角色行为规约。

点餐系统（在店铺点餐）：

用户分为：店家（管理员），顾客用户作为店家的行为：
新增 / 修改 / 删除菜品
管理顾客订单
修改折扣优惠用户作为顾客的行为：
查看菜品
创建 / 删除 / 修改订单
订单支付
发布 / 删除评论

2.将系统划分为几个功能模块，如果可以的话，画出系统的功能结构图。

用户端:
登录
查看菜品（分页）：
查看菜品列表：按照主食、配菜、饮料等等分类查看
查看菜品详情：名称、价格、图片，评论创建 / 修改订单：
可以在订单新增菜品，修改菜品数量，填写备注订单支付：
选择微信、支付宝支付----------------------------------------（店家）管理员端
管理菜品（分页）：
修改、删除、增加菜品信息（名称、图片，价格，描述等）管理订单：
查看订单列表：按照时间、餐位、订单价格分类查看
查看订单详情：查看创建时间，餐位序号、菜品列表，备注
删除订单修改折扣优惠：
修改折扣条件（例如，客户总消费次数>10 or 订单价格>500）
修改折扣额度
修改折扣有效时间

3.后端对角色行为规约进行扩展，并对原型部分不合理的部分前后端进行商榷。分析系统中的不同对象之间的关系，形成实体，进一步组织成数据库文档。（见第三部分）
4.分析前后端交互的功能，编写接口文档。（见第四部分）

三、数据库设计

1.需求分析设计

现在我们想要设计一个山寨版的B站。
1.总体需求
用户分为3个角色：游客、用户、管理员
根据角色进行任务分类：
1.游客可以不登陆，正常浏览视频，文章，搜索用户、文章、视频
2.用户除了拥有游客的权限以外，还可以投币作品；发布、管理自己发布的作品
3.管理员可以审核作品，板块以及对用户审核，可以封禁\解封作品、用户、板块。
2.系统功能设想

2. 概念结构设计

1.实体定义
实体有：用户，管理员，作品、板块
实体间联系：
板块 - 作品：多对多，一个板块可以有多个作品，一个作品也可以属于多个板块
用户 - 作品：一对多，一个用户主可以拥有多个作品，但是一个作品不可以被多个用户拥有

3. 数据库ER模型

实体属性图

实体联系图

3. 逻辑结构设计

1.关系模型

用户（主键id，用户名，密码，性别，硬币数量，用户状态码）
作品（主键id，题目，内容，发布时间，用户外键，硬币数量，简介，作品状态码）
板块（主键id，名称，简介，创建时间，板块状态码）
归属（主键id，作品外键，板块外键）

2. 数据库关联关系

1. 外键约束1（用户 - 作品）tb_article表中的user_id对tb_user中的id进行参照，形成两表的关联，表示用户和作品一对多的关系
2. 外键约束2（用户 - 作品）tb_article_plate表中的article_id对tb_article中的id进行参照，tb_article_plate表中的plate_id对tb_plate中的id进行参照，两个外键约束形成了作品和板块的多对多的关系

3.数据表逻辑设计

1.用户表逻辑设计

2.作品表逻辑设计

3.板块表逻辑设计

4.归属表逻辑设计

4.物理结构设计

1.确定数据库的物理结构

1. 确定数据库管理系统及其宿主语言
   数据库管理系统使用的是MySQL8.0
   宿主语言使用的是结构化查询语言SQL

2. 定义数据库、表及字段的命名规范
   1.数据库命名全小写
   2.表命名全小写，以tb_开头，以下划线分割单词
   3.字段全小写，以下划线来分割单词

3. 选择合适的存储引擎
   鉴于InnoDB 存储引擎以下几个优点：
   1.在事务上具有优势，即支持具有提交、回滚和崩溃恢复能力
   2.InnoDB 存储引擎可以有效地降低由于删除和更新导致的锁定
   3.可以确保事务的完整提交（Commit）和回滚（Rollback）
   4.支持外键、Hash索引和B+树索引
   并且考虑到该系统以下的几个特点：
   每一张表都涉及增删改查操作
   对数据一致性和事务一致性要求较高
   因此，采用InnoDB作为存储引擎
   4. 为表中的字段选择合适的数据类型
   选取原则：
   1.当一个列可以选择多种数据类型时，应该优先考虑数字类型，其次是日期和二进制类型，最后是字符类型
   2.对于相同级别的数据类型，应该优先选择占用空间小的数据类型
   例：

数字类型：

日期类型：

字符串类型：

5. 建立数据库物理结构

• 用户信息表tb_user

• 作品表tb_article

• 板块表tb_plate

• 归属表（作品板块关系表）tb_article_plate

2.对物理结构的解释

字段数据类型的选择原因：

1. 主键均采用int类型，并且为自增的。原因是为了防止聚簇索引B+树结构的大规模重构，避免不必要的性能损耗。
2. 状态码均采用tinyint类型，状态码通常就是使用数字来表示状态的，不需要占用不必要的存储空间，一个字节无符号的存储足够了
3. 金钱采用decimal类型，涉及到金钱的存储要使用decimal类型，这种类型精度较高，不能采用double类型，会有精度损失
4. 密码采用char类型，因为char类型对于定长的数据存储检索速度更快，密码使用MD5进行加密存储
5. 除内容和密码其他需要使用字符串类型进行存储的都使用varchar类型，varchar存储的是可变字符串，除了可节省存储空间外，存取硬盘时也会较有效率。
6. 发布时间使用的是timestamp类型，timestamp会根据元组更新自动更新时间，适合记录数据修改的时间，而datetime不会随着该元组信息修改而进行更新，更加适合记录数据的初始创建时间，因此不采用datetime，而使用timestamp类型

5. 数据库实施

使用navicat

四、接口文档

一、什么是接口文档？
在项目开发中，web项目的前后端分离开发，APP开发，需要由前后端工程师共同定义接口，编写接口文档，之后大家都根据这个接口文档进行开发，到项目结束前都要一直维护。

二、为什么要写接口文档？
1、项目开发过程中前后端工程师有一个统一的文件进行沟通交流开发
2、项目维护中或者项目人员更迭，方便后期人员查看、维护
三、接口文档设计

五、natapp使用 及 项目部署

natapp
注册natapp账号后，跟着官方教程配置NATAPP1分钟快速新手图文教程
注意：买vip-1型隧道