因为把dll看成ddl而急死——概要设计和数据库设计

因为把dll看成ddl而急死 2025-10-20 16:05:36

这个作业属于哪个课程	2501_CS_SE_FZU
这个作业要求在哪里	团队作业——概要设计和数据库设计
团队名称	因为把dll看成ddl而急死
这个作业的目标	概要设计和数据库设计
其他参考文献	《构建之法》、《数据库设计说明书》、《概要设计说明书》

GitCode相关链接
一、系统和数据库设计
1.1 体系结构设计
1.2 功能模块层次图
1.3 数据库ER分析
1.4 数据库表结构设计
二、类图、系统安全和权限设计
2.1 类图设计
2.2 系统安全和权限设计
三、改进分析
四、团队绩效
4.1 工作流程
4.2 组员分工及献度比例

一、系统和数据库设计

1.1 体系结构设计

体系结构设计思路：

系统采用分层架构设计，各组件协同工作，共同支撑《知音》App的完整功能。
客户端层为用户提供多样化的访问入口，包括基于Flutter框架开发的iOS App和Android App，以及功能完善的Web管理后台，满足不同用户群体的使用需求。
网关层作为系统的统一入口，承担着关键的流量管控职责。负载均衡器确保请求在多个服务实例间合理分配，提高系统可用性；API网关则负责请求路由、认证授权、限流熔断等核心功能，为后端服务提供安全可靠的访问控制。
服务层是系统的核心业务逻辑层，包含八个独立的微服务模块。用户服务负责处理账户相关的注册、登录和个人资料管理功能；内容服务专注于视频、文档等媒体内容的上传、存储和管理；推荐服务基于用户行为数据实现个性化内容推荐；社交服务支持关注、点赞、评论等用户互动功能；消息服务处理系统通知和用户私信；搜索服务提供强大的内容检索能力；支付服务支持付费内容的交易处理；通知服务负责各类消息推送功能。
中间件层为系统提供各种基础服务支持，确保各服务间的高效协同。Redis作为高速缓存存储热点数据和用户会话信息，提升系统响应速度；Kafka处理用户行为日志和系统通知等异步消息，保证数据的可靠传输；Elasticsearch提供全文搜索和推荐数据处理能力，增强用户体验；RabbitMQ处理其他类型的异步任务，进一步解耦系统组件。
数据存储层负责系统的数据持久化，采用多种存储方案满足不同数据类型的需求。MySQL数据库存储用户信息、内容元数据等结构化数据，通过主从复制机制保证高可用性；分布式文件存储系统专门用于存储视频、图片等大文件资源，确保媒体内容的高效存取。
基础设施层提供系统运行的基础环境，保障系统的稳定性和可维护性。Docker实现应用的容器化部署，提高部署效率和环境一致性；Kubernetes负责容器编排管理，确保服务的高可用性；Prometheus持续收集系统监控数据，Grafana提供直观的监控数据可视化展示，为系统运维提供全面的数据支持。

1.2 功能模块层次图

功能模块设计思路：

核心创作模块
FR-C-01: 视频导入:
用户故事: 作为内容创作者，我希望能够灵活地导入视频，以便创作出高质量的内容。
功能描述: 系统应支持从本地相册导入视频，支持MP4、MOV等主流格式，并提供多种清晰度选项（720p, 1080p, 4K）。
FR-C-02: 文档创作:
用户故事: 作为内容创作者，我希望能够创建配套的文档内容，以便为用户提供更深入的知识学习体验。
功能描述: 系统需提供一个富文本编辑器，支持文本格式化、图片/代码块/数学公式插入、版本管理和协作编辑。
FR-C-03: 混合发布流程:
用户故事: 作为内容创作者，我希望能够将视频和文档组合发布，以便为用户提供完整的学习体验。
功能描述: 系统应支持视频+文档的组合发布，允许添加标题、描述、话题、封面，并提供隐私设置、定时发布等功能。

内容消费与推荐模块
FR-F-01: 沉浸式视频Feed流:
用户故事: 作为内容消费者，我希望能够以沉浸式的方式浏览视频内容，以便获得更好的观看体验。
功能描述: 系统应提供全屏、上下滑动的视频浏览方式，支持自动播放、手势控制和基础互动（点赞、评论）。
FR-F-02: 混合浏览模式:
用户故事: 作为内容消费者，我希望能够在视频和文档之间无缝切换，以便获得完整的学习体验。
功能描述: 系统需支持在观看内容时一键切换视频和文档视图，并提供学习进度跟踪、笔记、收藏等功能。
FR-F-03: 推荐算法:
用户故事: 作为内容消费者，我希望系统能根据我的兴趣推荐相关内容。
功能描述: 推荐系统需基于用户行为（点赞、评论、完播率等）和内容标签，通过协同过滤等算法进行个性化推荐，并支持用户反馈以调整策略。

深度社交模块
FR-S-01: 基础互动:
用户故事: 作为用户，我希望能对内容进行点赞、评论、分享和收藏，以表达我的看法。
功能描述: 系统需提供点赞、评论（支持楼中楼）、转发分享、收藏（支持收藏夹）等基础互动功能。
FR-S-02: 私信:
用户故事: 作为用户，我希望能与其他用户进行私密交流。
功能描述: 系统需提供私信功能，支持发送文字、语音、图片等消息，并支持群聊。
FR-S-03: 个人主页:
用户故事: 作为用户，我希望能查看他人或编辑自己的个人主页，以展示信息。
功能描述: 个人主页需展示用户的基本信息、作品列表、社交数据（粉丝、关注），并支持用户自定义编辑。

用户系统模块
FR-U-01: 注册与登录:
用户故事: 作为新用户，我希望能快速注册和登录。
功能描述: 系统需支持通过手机号+验证码的方式进行注册和登录，并提供密码找回功能。
FR-U-02: 个人资料管理:
用户故事: 作为用户，我希望能管理我的个人资料。
功能描述: 用户可以编辑自己的头像、昵称、简介、兴趣标签，并进行隐私设置。
FR-U-03: 通知中心:
用户故事: 作为用户，我希望能及时收到与我相关的通知。
功能描述: 系统需提供通知中心，聚合点赞、评论、@、新增粉丝等各类消息，并支持分类查看和推送设置。

1.3 数据库ER分析

总体ER图

用户模块ER图

视频模块ER图

社交互动ER图

笔记模块ER图

数据库ER设计思路：

需求分析
视频平台的主要业务流程涉及：

1.用户注册与管理。
2.视频的上传、评论、点赞等操作。
3.动态发布、互动（评论、点赞等）。
4.用户间的私信功能。
5.举报、审核等功能，用于维护平台内容的合法性。
6.为了支持上述功能，我们将数据库设计为多个表，分别存储用户、视频、评论、动态、举报、点赞等数据。我们也需考虑扩展性、安全性和效率优化，通过索引、关联关系、时间戳及软删除等设计，保证数据查询与更新的效率。

ER（实体关系）分析
以下为主要实体及其关系：

1.用户：代表平台用户，管理用户信息。
2.视频：代表用户上传的视频内容。
3.评论：用户对视频的评论，支持二级评论。
4.笔记：代表用户记录的笔记内容
5.标签：管理标签及其关联关系。
6.视频标签：管理视频标签及其关联关系。

1.4 数据库表结构设计

核心表结构：

用户表 (users): 存储用户ID、认证信息、个人资料等。
视频表 (videos): 存储视频元数据、存储路径、作者ID等。
文档表 (documents): 存储文档内容、版本信息、作者ID等。
混合内容表 (mixed_contents): 关联视频和文档，形成一个独立的发布单元。
评论表 (comments): 存储对内容的评论、回复关系、用户ID等。
关注表 (follows): 存储用户间的关注关系。
点赞表 (likes): 存储用户对内容的点赞记录。
学习记录表 (learning_records): 存储用户的学习进度、笔记等。

数据库表结构设计思路：

用户管理 (User)

• 用户表是系统的核心，存储用户的基本信息，包括用户名、加密密码、邮箱、头像链接、个人简介等。created_at 字段记录用户的注册时间，用于跟踪用户账户的创建时间点。用户ID作为主键，唯一标识每个用户，确保数据的唯一性和完整性。该表支持用户认证、个人资料管理和个性化设置，是系统所有功能的基础。

内容发布 (Video, Note)

• 视频表存储用户上传的视频内容，包括视频链接、描述、可见性设置（如公开或私有）等。每个视频通过 user_id 外键关联到用户表，明确视频的上传者，实现用户与内容的所有权关系。created_at 字段记录视频上传时间，便于内容管理。

• 笔记表允许用户对特定视频添加个人笔记或注释，存储笔记的文本内容。笔记通过 user_id 和 video_id 外键分别关联用户表和视频表，表示笔记的作者和所属视频，增强了视频内容的可扩展性和用户个性化体验。created_at 字段记录笔记创建时间。

内容分类 (Tag, VideoTag)

• 标签表存储系统预定义或用户生成的标签名称，用于对视频进行分类、标记和搜索，提升内容的可发现性和组织性。标签ID作为主键，确保唯一性。

• 视频标签表作为关联表，管理视频和标签之间的多对多关系。通过 video_id 和 tag_id 组合主键（同时作为外键），实现一个视频可关联多个标签、一个标签可应用于多个视频的灵活分类机制，支持高效的内容筛选和推荐。

社交互动 (Comment)

• 评论表存储用户对视频的评论内容，是用户之间互动的重要方式。评论通过 user_id 和 video_id 外键关联用户表和视频表，标识评论的作者和所属视频。content 字段存储评论文本，created_at 字段记录评论时间，支持实时互动和内容讨论。该表增强了社区的活跃度，为用户提供反馈和交流渠道。

说明

• 本设计基于提供的表结构，重点关注用户管理、内容发布、分类和互动功能。消息通信、用户反馈（如举报）和内容审核等模块在当前表中未体现，可根据未来需求扩展。所有表均包含时间戳字段（如 created_at），便于跟踪数据生命周期，确保系统的可维护性和可扩展性。

二、类图、系统安全和权限设计

2.1 类图设计

类图设计思路：

用户中心的设计:
用户(User)是中心实体，几乎所有功能都是围绕用户设计的。
用户可以进行常见的社交活动，如上传视频、发表评论、记录笔记、关注其他用户、发送私信等。

内容创作和分享:
视频(Video)类是内容创作的核心，用户可以上传视频，这是平台的主要功能之一。
视频类与用户类和笔记类关联，表明每个视频都有一个上传者和其对应的笔记内容。
视频类还与评论(Comment)和标签(Tag)关联，表明视频可以被评论和分类。
笔记（Note）类同样也是创作模块的核心，用户可以记录笔记以及查看其他人的笔记。
笔记类与视频类和用户类关联，表明每个笔记都有其对应的视频内容和创作者。

社交互动:
评论(Comment)类允许用户对视频进行反馈，增加了用户间的互动。
关注(Follows)类体现了社交网络的特性，用户可以关注其他用户，形成社交关系网。

消息存储:
学习记录 (Learning_records): 存储用户的学习进度、笔记等。

用户反馈和参与:
动态(Post)类允许用户发布非视频内容，如状态更新或图片，增加了平台的互动性。
点赞表(Likes)类为视频、动态和评论提供了点赞功能，这是用户参与和内容推广的重要机制。

2.2 系统安全和权限设计

1. 数据泄露风险：用户密码、学习记录等核心数据若未加密，可能导致信息泄露。应对措施：采用SHA-256加盐哈希存储密码，手机号、等敏感信息传输时使用TLS 1.3加密，符合需求文档中“所有敏感数据（如密码、手机号）在传输和存储时必须加密”的要求；同时，对用户表、学习记录表等核心数据表设置字段级权限，限制非授权访问。
2. 账号盗用风险（可选）：仅依赖手机号+验证码登录，可能面临短信劫持导致的账号被盗问题。应对措施：增加异常登录检测功能，当系统检测到陌生设备、异地IP登录时，触发二次验证（如安全问题+验证码），并实时推送登录提醒至用户预留邮箱，符合“用户安全需包含异常登录检测”的需求。
3. 内容违规风险（可选）：用户上传的视频、文档可能包含违规信息，违反合规约束。应对措施：搭建“AI初审+人工复审”机制，AI自动识别违规内容（如敏感词、违规画面），人工对疑似违规内容进行复核；同时开放用户举报入口，支持对违规内容标记，审核通过后立即下架，满足“所有内容需符合国家相关法律法规，需建立内容审核机制”的要求。
4. API攻击风险：未授权的API调用或恶意请求（如DDoS、SQL注入）可能导致系统瘫痪。应对措施：所有RESTful API接口需携带JWT令牌进行身份验证，令牌有效期设为2小时；对接口请求频率限流（单用户单接口每秒最多5次请求），采用预编译SQL语句防范SQL注入，配置WAF（Web应用防火墙）拦截异常请求，落实“所有API接口必须进行身份验证和权限控制，系统需具备防范常见网络攻击的能力”的需求。
5. 服务容错机制：采用Sentinel实现微服务的限流、熔断与降级。当推荐服务因高并发出现响应延迟时，触发限流策略，限制每秒请求量不超过服务最大处理能力；当服务出现异常（如返回错误码500）次数超过阈值时，自动熔断（熔断时长5分钟），期间请求导向降级接口（如返回热门视频列表而非个性化推荐）；视频存储服务异常时，降级为仅展示已缓存的视频缩略图，避免整个Feed流功能不可用，保障核心体验。
6. 数据容错设计：数据库采用MySQL主从复制架构，主库负责写操作，从库负责读操作，当主库故障时，通过MGR（MySQL Group Replication）自动切换至从库，切换时间不超过30秒；视频、文档文件存储于MinIO分布式对象存储，默认配置3副本，当单个存储节点故障时，其他副本可正常提供服务，避免文件丢失；用户提交的笔记内容实时保存至本地缓存，若网络中断，待网络恢复后自动同步至服务器，防止数据丢失。
7. 异常处理规范：统一前后端异常处理流程，服务端定义标准化错误码（参考需求文档中“40001表示参数错误，50001表示数据库错误”的规范），返回包含“code+message+data+timestamp”的JSON格式响应；客户端接收异常后，根据错误码展示友好提示（如参数错误提示“请输入正确的视频标题”，数据库错误提示“系统暂时异常，请稍后重试”），同时记录异常日志至本地，便于问题排查，避免App闪退。

三、改进分析

改进前的类图

改进后的类图

1. 从“继承”到“组合”：更优雅的内容模型设计
这是最核心的改进。
原先的类图： 使用了类继承（VideoPost和ArticlePost继承自Post）。这在实际开发中会带来“继承泛滥”的问题——如果未来要增加“图片帖子”、“投票帖子”等新类型，就需要不断地创建新的子类，导致类体系非常臃肿，且难以维护。
改进后的类图： 彻底摒弃了继承，采用了更灵活的组合思想。它只有一个Video（视频）核心实体。所有视频的附加信息，如文字描述（description）、分类标签（通过Tag和VideoTag）、用户笔记（Note）等，都作为独立的模块与视频关联。这种设计使得系统扩展新内容类型或功能时，只需增加新的关联即可，无需改动核心结构，符合“组合优于继承”的设计原则。
2. 数据模型与业务逻辑分离，职责更清晰
原先的类图：类中既包含了数据属性（如id, content），又包含了业务方法（如addComment(), incrementLikes()）。这是一个典型的面向对象设计，但在现代应用架构中，数据持久化层（数据库模型）和业务逻辑层通常是解耦的。
改进后的类图： 类图纯粹地描述了数据模型（实体关系图），只包含属性（对应数据库表的字段）和实体间的关系。它将业务逻辑（如点赞、评论、发布）完全剥离，交给了后端的服务层（Service Layer）或应用层去处理。这使得数据模型非常干净、职责单一，更符合领域驱动设计（DDD）或清晰架构的思想。
3. 关系设计更精确、更完整
原先的类图： 关系描述比较模糊，例如User和Post之间只是简单的“has”和“writes”关系，多重性（一对一、一对多）不明确。User和UserProfile是强耦合的“拥有”关系。
改进后的类图：
明确的多重性：所有关系都清晰地标明了多重性，如User和Video是明确的1对多关系（一个用户可拥有多个视频）。
显式的关联实体：引入了关联表来解决多对多关系。例如VideoTag表，专门用于记录Video和Tag之间的多对多关联，这是关系型数据库设计中处理多对多关系的标准且最优做法。
实体关系更合理：将“笔记”（Note）设计为一个独立的实体，并通过user_id和video_id同时关联到用户和视频，清晰地表达了“一个用户对某个视频做的笔记”这一复杂关系，这比简单的文本属性强大得多。

四、团队绩效

4.1 工作流程

总体安排：
• 10.16-10.17（周四）分配任务
• 10.17-10.20（周日）完成两个小组主要任务
• 10.21-10.22（周二）ppt制作，工作成果审核，GitCode上传，总结整理团队协作，博客撰写，答辩准备，评审表制作
具体情况：

使用飞书进行协同工作

4.2 组员分工及献度比例

姓名	学号	工作内容	贡献度
叶达	102300229	协调善后、进度管控、帮助“系统功能模块”、“数据库索引设计”、“应用设计”的编写，数据库建立测试	11
张钰婷	102300206	帮助制作数据流图，类图......补充图表，阐述安全性、健壮性与可扩展性	12.5
郑天浩	102300109	《系统设计说明书》——“总体设计”、“权限设计”，《数据库设计说明书》——“概念结构设计”、“逻辑结构设计”	7
陈彦哲	032201218	《系统设计说明书》——“系统功能模块”、“数据流”部分	9
李严	102300127	《系统设计说明书》——“接口设计”	6
苏峻	102300221	《数据库设计说明书》“应用设计”的编写	10
朱添驰	032201109	帮助制作数据流图，类图......补充图表，《系统设计说明书》——“安全性、健壮性与可扩展性 ”部分内容编写	7
陈雨昕	102300214	博客内容的编写，《系统设计和数据库设计评审表》，完成《系统设计说明书》——“安全性、健壮性与可扩展性 ”部分内容编写	11.5
陈雨桐	102300202	文档初建、文档格式统一、质量把控，帮助ppt制作	11
吴嘉鑫	102300225	ppt制作、答辩准备和现场展示	15