Growing light——数据库设计和系统设计
作业基本信息
| 这个作业属于哪个课程 | 2021春软件工程实践|W班 |
|---|---|
| 这个作业要求在哪里 | 团队作业四——数据库设计和系统设计 |
| 团队 | Growing light |
| 这个作业的目标 | 完成数据库和系统设计 制作《数据库设计说明书》和《系统设计说明书》 团队项目的预期开发计划时间安排和分工 |
| 其他参考文献 | 《系统设计说明书》《数据库设计说明书》国标规范文本 和《构建之法》 |
团队项目的预期开发计划时间安排
| 时间 | 活动产出 | 里程碑 |
|---|---|---|
| 第一周 (4.18~4.24） 数据库和系统设计 |
系统设计说明书 数据库设计说明书 系统设计和数据库设计答辩PPT 项目预期开发计划安排和分工 |
数据库和系统设计完成 |
| 第二周 (4.24~5.1) Alpha第一周 |
用户模块 讨论模块 首页 登录注册模块 测试模块功能 |
|
| 第三周 (5.1~5.7) Alpha第二周 |
后台模块 捐赠模块 个人中心模块 测试模块功能 |
Alpaha版本完成 |
| 第四周 (5.8~5.15) 软件评测 |
进行软件评测 | |
| 第五周 (5.15~5.21) 软件评测 |
完成软件评测 准备答辩相关 |
软件评测完成 |
| 第六周 (5.22~5.29) Beta第一周 |
Alpha版本功能完善 完善个人中心模块细节 测试模块功能 进行前后端整合 |
|
| 第七周 (5.29~6.6) Beta第二周 |
前后端整合后前端测试 添加全局检索功能 添加视频播放功能 测试以上功能 |
|
| 第八周 (6.6~6.13) Beta第三周 |
添加视频推荐算法 继续完善功能 测试功能 |
|
| 第九周 (6.13~6.18) Beta第四周 |
测试 优化 后期维护 |
Beta版本完成 |
团队项目的预期开发计划分工安排
| 学号 | 姓名 | 前后端 | 分工 |
|---|---|---|---|
| 221801424 | 苏杰阳 | 前端 | 前端登录注册模块、首页、个人中心模块、视频推荐算法模块 |
| 221801428 | 杨朕炫 | 后端 | 后端用户模块、视频播放功能 |
| 221801133 | 杨思雨 | 前端 | 前端捐赠模块及附属组件 |
| 221801423 | 陈起 | 后端 | 后端讨论模块 |
| 221801435 | 齐易捷 | 后端 | 后端捐赠模块、视频推荐算法 |
| 221801405 | 潘增滢 | 前端 | 前端登录注册模块、首页、个人中心模块 |
| 221801415 | 张富源 | 前端 | 前端讨论模块及附属组件、后台模块及附属组件 |
| 221801204 | 黄伟源 | 后端 | 后端后台模块 |
| 221801412 | 刘晓君 | 前端 | 前端讨论模块及附属组件、后台模块及附属组件 |
| 221801426 | 林泽坤 | 前端 | 团队博客、前端个人中心模块 |
相关设计图
体系结构图
思路：用户首先与View层进行交互，View层由Vue框架实现，其中一个页面包含多个Component，即Component组件为页面组织的最小单元；用户点击页面之后，系统发送请求到Controller层，该层主要负责具体业务模块流程的控制，此层要调用到Service层的接口去完成业务，针对不同的业务流程有不同的控制器；Service层主要负责某个具体业务的逻辑设计，我们调用service接口进行业务处理，service调用到已经定义的Mapper层的接口，该层的封装有利于提高通用业务逻辑的独立性和重复利用性；Mapper层负责数据的持续化存储，mapper层直接与数据库打交道（执行SQL语句），将数据库中的记录组装成Model对象，并将对象返回给Service层；Model层即为系统中的实体类，其属性和数据库中的字段基本保持一致。
各层的交互：
功能模块层次图
（根据业务和功能，将系统的逻辑结构划分为平台功能模块和后台功能模块）
类图
总览（可以右键打开图片放大看）
CourseVideo视频课程类
该类描述一个用户上传的视频，主要属性包括了视频id、视频标题title、视频简介info、上传视频的用户id、视频上传时间、视频地址url（url为数组，代表用户分p上传视频，即一次上传多个子视频）、视频播放数量played_num、视频状态status（枚举值，包括未审核、审核未通过、审核通过）、视频收藏数量liked_num、视频封面地址、视频类型Type（启蒙、初中、小学等，一个视频类型包含多个标签Tag，例如语文、数学、英语等）。
VideoComment视频评论类
p.s. 这里需要说明一下id、to_comment、below_comment的区别。Id是每条评论的唯一标识符，也就是评论表的主键。to_comment和below_comment都是评论表的外键，指向另外一条评论的id，也就是说这两个外键指向评论表本身。
to_comment的设计主要考虑到以下情况：
评论1：XXXXXX
评论2 回复 评论1： XXXXX
这里评论2的to_comment就是评论1的id。
而below_comment的设计主要考虑到以下情况：
评论1: XXXXX
评论2: XXXXX
评论3：XXXXX
评论4：XXXXX
即考虑到评论呈现一种树形结构，那么这里的评论2的below_comment就是评论1的id，评论4的below_comment就是评论3的id。
CourseWare课件类
该类描述了每个课件所需要的信息，主要的属性有：课件id、课件下载url、课件的名字name、课件所属的视频id。视频和课件是一对多的关系，一个视频对应多个课件。
Post帖子类
该类描述了每个帖子所需要的信息，主要的属性有：帖子id、帖子标题title、 帖 子简介content、帖子创建的时间createTime、发布帖子的用户id fromUser、帖子的 类别、帖子的历史浏览人数view、帖子评论数量commentNum、帖子封面地址face。
帖子与视频类共用一个Type类型。
VideoPostRecord帖子视频关联类
该类为CourseVideo视频和Post帖子的关联类，主要用于在每个视频的旁边推荐相 关帖子。该类有两个属性，分别对应帖子的id和视频的id。
User用户类
该类描述了系统中每个用户所需要的信息，主要的属性有：用户id、用户名字 user_name、 登录密码password、用户简介introduction、用户头像地址avatar_url、 用户年龄age、用户性别gender、用户手机号mobile、用户邮箱email、以及用户在系 统中所扮演的角色roles。
Permission权限类和Role角色类
本系统使用RABC权限控制，RBAC（Role-Based Access Control，基于角色的访问 控制），就是用户通过角色与权限进行关联。简单地说，一个用户拥有若干角色，每一 个角色拥有若干权限。这样，就构造成“用户-角色-权限”的授权模型。在这种模型中， 用户与角色之间，角色与权限之间，一般者是多对多的关系。图中User类为用户类，User 类拥有多个Role类的实例，而一个Role类又拥有多个Permission类的实例。
CollectionRecord用户收藏记录类
该类记录了用户收藏的视频，拥有属性有：用户id和视频id。
VoluntaryActivity捐赠志愿活动类
该类描述了一个捐赠活动所需要的信息，主要属性有：活动的id、活动名称name、 活动简介introduction、发起人id、开始时间start_time、结束时间end_time、活动 地点location、活动的类型、捐赠总数、活动的状态、活动封面的地址、以及该活动所 拥有的参加记录（ActivityRecord数组）。
ActivityRecord活动记录类
该类作为VoluntaryActivity和User的中间类，记录每个用户所参加的活动，主要 属性包括用户id、活动的id、捐赠数量、捐赠时间。
视频推荐算法
16年的时候，谷歌公开了YouTube的推荐算法，Deep Neural Networks for YouTube Recommendation，论文地址：https://www.sci-hub.ren/10.1145/2959100.2959190。 该论文采用了深度学习算法，在效果上超越了最常用的矩阵分解算法。整个推荐架构分为两部分，召回和排序。
召回算法（candidate generation，候选产生），从视频物料库中筛选出几百个视频。因为计算量大，所以召回算法不可能也没必要采用所有特征，因此召回算法只采用了用户行为和场景特征。
排序算法使用了更多的特征，给每个候选视频计算一个分数，并且按照分数从高到低排序，从几百个视频里边再筛选和排序出几十个视频推荐给用户。
召回算法
召回算法模型架构如下图
召回阶段（candidate generation）利用用户的历史观看视频信息、历史搜索信息、用户特征信息和视频存在时间等训练神经网络，得到一个权重矩阵，该权重矩阵与视频信息向量做内积，得到每个视频的推荐分数，选最大的N个进行召回。（具体请参考设计文档）
排序算法
排序算法架构如下图
排序模型和召回模型结构上非常类似，但在训练目标和输入上稍有不同。输入是用户特征信息以及单个视频的特征，预测目标为期望观看时间，训练方式采用加权逻辑回归，负样本的label为0，正样本的label为根据用户观看时间设置权重weight，当观看时长较长时则label值更大，这样就区分了样本的优劣。rank模型在预测时直接输出的e(wx+b), 即期望观看时间，再根据期望观看时间确定推荐顺序。
ER分析
（可以右键打开图片放大看）
表结构设计
用户表Users
课程表Course
讨论表Posts
类型表type
操作日志表operation_logs
评论表post_comment与course_comment
（因两张表结构类似，故以post_comment表为例）
tag表
course_tag关联表
permission表
post_course表
post_tag表
role表
role_perm表
user_collection关联表
user_role关联表
user_donate关联表
donate_activity表
donate_record表
comment_message表
course_material表
系统安全和权限设计
1、数据加密
对保存的密码等数据进行MD5不可逆加密，确保用户数据不会被泄漏。
2、用户权限判断
后端会根据用户角色开放相应权限的接口，确保不让用户跨权限调用接口，不合法修改数据库，确保数据库每次修改或存储都是正确的操作。
3、SQL防注入
后端数据库交互框架会使用SQL预编译的方式，防止恶意用户输入非法sql语句对数据库数据造成损坏。
4、确保数据有效
前端会对用户输入的数据进行校验，确保数据数据有效，符合规定。同时，后端接口会再一次判断数据是否有效，防止有些用户绕过前端用户界面控制，使用第三方网络请求工具，如Postman，RestTemplate等上传不正确的数据，造成数据存储错误。
5、事务控制
后端接口在所有涉及数据库存储，修改的控制器方法中都加入了事务控制，防止因为接口发生错误，导致数据库操作无法回滚，造成不必要的麻烦。事务传播方式采用REQUIRED方式，若该操作不处于事务中则创建一个事务，确保所有数据操作都处于事务控制中。
上次作业的Q&A及改进
Q&A
1、如何将活动记录聚合到志愿活动当中？
作为属性已添加。
2、能否添加一个课程，对一系列的视频进行统一管理？
由于再添加课程类太过于复杂（还需要实现配套的课程管理功能），所以这里采用简单处理，即将视频类的url设置为数组，即允许对视频进行分P（分成子视频），以此达到对于系列视频的管理效果，这里课程的简介，相当于CourseVideo里的info属性。
3、关于用户类中包含了对于收藏记录的操作的问题。
已将操作移至收藏记录类，作为其静态方法，保证了封装性。
改进
将评论类改成用组合设计模式
评论类为何要使用组合模式？
因为评论是一个树形结构，一个评论下面可能包含多个评论，用组合设计结构可以方便对于评论树的操作.
本次工作流程、组员分工、组员贡献度比例
流程图
本次分工及贡献度
| 学号 | 工作内容 | 贡献度 |
|---|---|---|
| 221801424 | 系统设计说明书接口设计，引言，整合 | 11 |
| 221801428 | 数据库设计说明书设计，整合 | 11 |
| 221801133 | 系统设计说明书模块设计 | 11 |
| 221801423 | 数据库设计说明书ER图，ppt编写 | 11 |
| 221801435 | 系统设计说明书类图设计，体系结构 | 11 |
| 221801405 | 系统设计说明书整合，修订 | 8 |
| 221801415 | 系统设计说明书概述，模块设计 | 8 |
| 221801204 | 数据库设计说明书结构图 | 8 |
| 221801412 | ppt编写，答辩 | 12 |
| 221801426 | 博客编写 | 9 |
