X-Music音乐平台
X-Music音乐平台
附加X-Music音乐平台
一、概述
1.1 项目背景
现如今，互联网技术在迅速发展的过程中体现了其快速准确便捷的特点，人们对在线音乐网站的需求也在日益增加。为了更好的提高对音乐信息管理的高效性，为了更好的跟随时代信息的高效性，一个在线音乐网站的建立是必要的。在网站上可以实现对音乐相关信息的管理，建立数据库后将一系列信息存储到数据库中，实现用户对相应音乐的搜索和实现管理员对音乐相关信息的管理，对于管理员和用户来讲都是具有极大的帮助的，在线音乐就是在这个基础上设计的。
根据上面的分析，在图书馆和网站上搜集有关的资料，也可以通过线下发传单或以电子形式进行调查问表的填写，依据这些信息了解到现实实际中用户对在线音乐网站有哪些需求，希望网站上都有什么功能，如此在系统实现后能够被广大的用户所接受和推广[2]。
1.2 系统名称
本次数据库设计大作业开发的系统名称为：X-Music音乐平台。
1.3 开发环境
本次数据库设计的环境为：
JDK： Java8
mysql：MySQL8.0
node：v14.17.3
redis：5.0.8
IDE：IntelliJ IDEA2020 / VSCode
二、需求分析
从用户方面：用户可以创建账户并登录系统。可以对个人信息进行管理，用户可以修改个人资料，包括昵称、头像、性别、年龄、地区等。用户可以浏览公共歌单，创建并且编辑和删除自己的歌单。用户可以在线播放和下载音乐。收藏管理：可以收藏音乐和歌单，并管理自己的收藏列表。评论互动：用户可以在音乐或歌单下发表评论，并对评论进行点赞、转发和回复。个性化推荐：系统根据用户行为和偏好提供个性化的音乐和歌单推荐[3]。
从管理员方面：管理员可以查看、审核用户信息，处理用户问题。歌单管理：管理员可以审核歌单内容，管理违规歌单。音乐库管理：管理员可以上传、更新、删除音乐库中的音乐。评论监管：管理员可以监控、审核用户评论，处理不当言论。管理员可以配置系统设置，如权限分配、功能开关等。可以生成系统使用情况的统计报告。管理员可以设置安全策略，管理用户权限。
从系统设计方面应考虑：系统反应度：多个人同时在线的时候对一个事件的反应时间要足够短。界面效果：系统界面一目了然、功能划分明确，能够快速找到需要的功能并操作。储存性能高：在线音乐网站需要存储大量的歌曲信息和相对应的歌手的信息，以及用户注册信息来满足用户的需求，所以要求数据库要有较高的存储量。简单操作：因为音乐没有年龄之分，所以该系统的受用群体可以是所有的用户，所以为了方便用户操作和提高系统的使用度，要求系统功能一目了然，方便用户进行音乐的搜索播放等操作。
三、系统的基础数据流图
(1)用户管理：用户可以注册、登录、修改个人信息、注销账号等；
(2)歌单管理：用户可以创建、编辑、删除自己的歌单，可以将音乐添加到歌单中，可以查看、收藏其他用户的歌单，可以分享自己的歌单到社交媒体等；
(3)收藏管理：用户可以收藏自己喜欢的音乐、歌单、歌手等，可以查看、取消收藏、管理自己的收藏夹；
(4)音乐管理：系统可以存储音乐的各种信息，包括歌曲、专辑、歌手、流派，歌词等。可以查询音乐的歌词，播放地址等；
(5)评论管理：用户可以评论别人的歌曲，歌单，可以查看自己的评论，删除自己的评论。
四、功能分析
4.1 功能需求及数据需求分析
(1)用户模块：实现用户的注册、登录、修改个人信息、注销账号等功能，以及用户的身份验证、权限控制、个性化设置等功能。用户模块的数据需求包括用户的基本信息（用户名、密码、邮箱、手机号、昵称、头像、性别、年龄、地区）；
(2)歌单模块：实现歌单的创建、编辑、删除等功能，歌单模块的数据需求包括歌单的基本信息（歌单名、创建者、创建时间、描述、封面）、歌单的内容信息（包含的音乐、音乐的顺序、音乐的数量）、歌单的统计信息（收藏量、播放量、评分、评论数）；
(3)收藏模块：实现收藏的添加、取消、查看、管理等功能，收藏模块的数据需求包括收藏的基本信息（收藏的类型、收藏的对象、收藏的时间）、收藏的统计信息（收藏的数量、收藏的评分）；
(4)音乐模块：实现音乐的存储、展示、播放、下载等功能，音乐模块的数据需求包括音乐的基本信息（如歌曲名、歌手名、专辑名、时长、大小、格式、封面、歌词等）、音乐的统计信息（如播放量、下载量、收藏量、评分、评论数等）等；
(5)评论模块：实现用户在不同音乐，歌单下进行评论评论模块的数据需求包括评论的基本信息（如评论的用户，评论的时间，评论的内容等）、评论的统计信息（如点赞量，转发量，回复量等）。
4.2 业务规则分析
(1)用户规则：用户必须注册并登录才能使用系统的功能，用户可以修改自己的个人信息，可以注销自己的账号，但不能恢复已注销的账号，用户可以给系统提供反馈信息，系统会根据用户的反馈信息改进服务质量；
(2)歌单规则：歌单必须有一个唯一的id，系统不会存储或展示重复的歌单，歌单必须有一个创建者，系统会记录歌单的创建者和创建时间，歌单必须有一个描述，系统会展示歌单的描述，系统会展示歌单的内容和音乐的顺序；
(3)收藏规则：收藏必须有一个唯一的id，系统不会存储或展示重复的收藏，收藏必须有一个对象，系统会记录收藏的对象和收藏的时间，收藏除了id与收藏名其他都可以为空；
(4)音乐规则：每首音乐都有1个唯一的id，系统不会存储或展示重复的音乐，系统会记录音乐的播放地址、歌手、歌曲名称、歌词信息等；
(5)评论规则：每个评论都会有1个唯一的id，系统不会存储id重复的评论，评论只限于歌曲与歌单。
X-Music音乐平台的数据库功能模块结构设计如图所示。
五、数据库系统设计—概念设计
5.1 概念结构设计
概念结构设计是数据库设计的关键阶段之一。它的定义可以概括为：通过对用户需求进行综合、归纳与抽象，将现实世界中的客观事物及其相互联系转化为一种独立于具体数据库管理系统的概念模型的过程。
概念结构设计具体来说就是运用各种概念数据模型的表示方法，如 E-R 图（实体-联系图）等[4]，来描述数据库所需要表示和存储的信息结构，包括实体、实体的属性以及实体之间的关系。这个阶段主要关注的是对业务领域的理解和建模，而不涉及具体的数据库实现细节，如数据类型、存储方式等。它为后续的逻辑结构设计提供了清晰的蓝图和指导，确保数据库能够准确、有效地反映业务需求和数据关系[5]。
5.2 概念结构的特点和设计方法
概念结构具有抽象性，综合性，稳定性和可理解性四大特性。常见的概念结构设计方法有自顶向下，自底向上，逐步扩张和混合策略等。
5.2.1 命名规范
(1)实体集的名称应该是单数名词，且首字母大写，例如：User、Music、Playlist等。
(2)属性的名称应该是小写字母，且用下划线分隔单词，例如：user_id、song_name、playlist_id等。
(3)联系集的名称应该是两个相关实体集的名称用下划线连接，例如：User_PlayList、PlayList_Music、User_Favor等。
(4)主键属性的名称应该是实体集的名称加上_id，例如：user_id、playlist_id、song_id等。
(5)外键属性的名称应该是参照实体集的主键属性的名称，例如：creator_id、song_id、object_id等。
5.2.2 实体集及属性
(1)用户（User）：用户是系统的基本使用者，用户可以注册、登录、修改个人信息、注销账号等。用户实体集的属性有：
user_id：用户的唯一标识，主键，char类型，非空。
user_name：用户的用户名，用于登录，唯一，字符串类型，非空，长度不超过255个字符。
user_password：用户的密码，用于登录，字符串类型，非空，长度不超过20个字符。
email：用户的邮箱，用于验证和找回密码，唯一，字符串类型，非空，长度不超过50个字符。
phone：用户的手机号，用于验证和找回密码，唯一，字符串类型，非空，长度为11个字符。
nickname：用户的昵称，用于展示，字符串类型，非空，长度不超过20个字符。
gender：用户的性别，用于展示，字符串类型，非空，长度为1个字符，只能是’男’或’女’。
age：用户的年龄，用于展示，整数类型，非空，范围在0到120之间。
(2)音乐（Music）：音乐是系统的基本内容，音乐可以被存储、展示、播放、下载等。音乐实体集的属性有：
music_id：音乐的唯一标识，主键，char类型，非空。
music_name：音乐的名称，用于展示，字符串类型，非空，长度不超过50个字符。
art_id：音乐的歌手的id，用于展示，字符串类型，非空，长度10个字符。
album：音乐的专辑名称，用于展示，字符串类型，非空，长度不超过50个字符。
cover_url：音乐的封面，用于展示，字符串类型，非空，长度不超过100个字符，存储图片的URL。
lyric_url：音乐的歌词，用于展示，字符串类型，非空，长度不超过100个字符，存储歌词的URL。
type_id：音乐的风格，用于分类，字符串类型，非空，长度不超过20个字符。
play_count：音乐的播放量，用于统计，整数类型，非空，范围在0到1000000000之间，初始值为0。
collect_count：音乐的收藏量，用于统计，整数类型，非空，范围在0到1000000000之间，初始值为0。
play_url：音乐的播放地址，字符串类型，非空，长度不超过100个字符，存储歌曲的URL。
(3)歌单（Playlist）：歌单是系统的基本组织形式，歌单可以被创建、编辑、删除等。歌单实体集的属性有：
playlist_id：歌单的唯一标识，主键，整数类型，非空，自增。
playlist_name：歌单的名称，用于展示，字符串类型，非空，长度不超过50个字符。
user_id：歌单的创建者，用于展示，外键，引用用户实体集的user_id属性，整数类型，非空。
create_time：歌单的创建时间，用于展示，日期时间类型，非空，格式为’YYYY-MM-DD HH:MM:SS’。
description：歌单的描述，用于展示，字符串类型，非空，长度不超过500个字符。
cover：歌单的封面，用于展示，字符串类型，非空，长度不超过100个字符，存储图片的URL。
tag_id：歌单的标签，用于分类，字符串类型，非空，长度不超过10个字符。
(4)收藏（Collect）：收藏是系统的基本交互形式，收藏可以被添加、取消、查看、管理等。收藏实体集的属性有：
collect_id：收藏的唯一标识，主键，整数类型，非空，自增。
collect_type：收藏的类型，用于分类，字符串类型，非空，长度为2个字符，只能是’歌曲’或’歌单’，分别表示收藏的对象是音乐或歌单。
user_id：收藏的用户，用于展示，外键，引用 User实体集的外键。
collect_time：收藏的创建时间，用于展示，日期时间类型，非空，格式为’YYYY-MM-DD HH:MM:SS’。
description：收藏的描述，用于展示，字符串类型，非空，长度不超过500个字符。
(5)评论（Comment）：评论是系统的基本内容，评论可以被存储、展示等。评论实体集的属性有：
con_id：评论的唯一标识，主键，char类型，非空。
user_id：用户的唯一标识，char类型，非空。
content：评论的内容，char类型，非空。
item_id：被评论对象的唯一标识，char类型，非空。
item_type：被评论对象的类型，代表着歌单或歌曲，enum类型，非空。
5.3 系统的E-R图
5.3.1 实体—联系方法(Entity-Relationship)
根据实际需求得出，各实体之间的联系如下：
(1)用户_歌单（User_Playlist）：用户和歌单之间的联系集，表示用户可以创建、编辑、删除自己的歌单；
(2)歌单_音乐（Playlist_Music）：歌单和音乐之间的联系集，表示歌单可以包含一个或多个音乐，音乐可以属于一个或多个歌单，歌单的创建者可以将音乐添加到歌单中，也可以从歌单中移除音乐，歌单的内容和音乐的顺序可以被编辑；
(3)用户_收藏（User_Collect）：用户和收藏之间的联系集，表示用户可以收藏自己喜欢的音乐、歌单、歌手等，也可以查看、取消收藏、管理自己的收藏夹 ；
(4)收藏_音乐（Collect_Music）：收藏和音乐的联系集，表示一首歌可以被一个或多收藏夹收藏，一个收藏夹可以收藏一个或多个音乐，用户可以向收藏夹中增添、删除音乐；
(5)收藏_歌单（Collect_Playlist）：收藏和歌单的联系集，表示一个歌单可以被一个或多收藏夹收藏，一个收藏夹可以收藏一个或多个歌单，用户可以向收藏夹中增添、删除歌单；
(6)评论_音乐（Comment_Music）：评论音乐的联系集，表示一首歌可以拥有多个评论，但同一个评论只能属于一首歌，用户可以自己添加、删除评论；
(7)评论_歌单（Comment_Playlist）：评论歌单的联系集，表示一个歌单可以拥有多个评论，但同一个评论只能属于一歌单，用户可以自己添加、删除评论。
5.3.2 E-R图设计
六、数据库系统设计—逻辑结构设计
6.1 关系数据库的基本概念
由实体间的联系导出关系模型，关系模型在关系数据库中即为一个二维表。
(1)记录：二维表中的一行，表示一个实体。
(2)字段：二维表的列，表示实体的属性、特征。
(3)主键：列或列的组合，能唯一地标识一行。表中只有一个主键，主键不允许NULL或重复。
(4)外键：表中某一字段与另一表中的主键相对应，则该字段称为表的外键。
外键表示了两个表之间的联系。
主键所在的表称为主表，外键所在的表为从表。
关系模型即二维表，要满足数据完整性的要求。
数据完整性：指数据的正确性和可靠性。
实体完整性：保证表中所有行具有唯一性。
域完整性：保证给定字段的数据有效性。
参照完整性：也称引用完整性，确保相关联的表之间数据的一致性。
用户自定义完整性：用户根据实际系统要求，定义的约束条件，涉及到的数据必须满足语义要求。
6.2 E-R图向关系模型转换的原则
(1)如果两个关系是1:1的联系，可以在两个实体类型转换成的两个关系模式中任意一个关系模式中加入另一个关系模式的码和联系类型的属性[6]。
(2)如果两个关系是1:m的联系，则在n端实体类型转换成的关系模式中加入1端实体类型的码和联系类型的属性。
(3)如果两个关系是m:n的联系，则将联系类型也转换成关系模式，其属性为两端实体类型的码加上联系类型的属性，而码为两端实体码的组合。
6.3 关系模式
经过以上E-R图设计，再对相关表结构优化后得到如下设计：
(1)User（user_id、user_name、user_password、email、phone、nickname、gender、age）
(2)Music（music_id、music_name、art_id、art_name、album、cover_url、lyric_url、type_id、type_name、play_count、collect_count、play_url）
(3)Playlist（playlist_id、playlist_name、user_id、create_time、description、cover_url、tag_id、tag_name）
(4)PlaylistDetails（playlist_id、music_id）
(5)Collect（collect_id、user_id、collect_time、collect_name）
(6)CollectDetailsMusic（collect_id、item_id）
(7)CollectDetailsPlaylist（collect_id、item_id）
(8)Comment（con_id、user_id、content、item_id、tiem_type）
6.3.1 将联系转换成关系模式
(1)用户_歌单（user_id、user_name、user_password、email、phone、nickname、gender、age、playlist_id）
(2)歌单_音乐（playlist_id、music_id）
(3)用户_收藏（user_id、user_name、user_password、email、phone、nickname、gender、age、collect_id）
(4)收藏_音乐（collect_id、music_id）
(5)收藏_歌单（collect_id、playlist_id）
(6)评论_音乐（music_id、music_name、art_id、art_name、album、cover_url、lyric_url、type_id、type_name、play_count、collect_count、play_url、con_id）
(7)评论_歌单（playlist_id、playlist_name、user_id、create_time、description、cover_url、tag_id、tag_name、con_id）
6.3.2 对关系模式进行规范化
这个数据库满足第一范式（1NF），因为每个表中的所有属性都是不可再分的原子值。
这个数据库满足第二范式（2NF），因为每个表中的非主属性都完全函数依赖于主键，没有部分函数依赖的情况。例如，Music表中的所有非主属性都完全函数依赖于主键music_id，而不是部分依赖于music_name或art_name等。
这个数据库不满足第三范式（3NF）：
因为type_name和tag_name字段并不能由music_id和playlist_id得出，因此得出存在相关传递依赖：
type_id→type_name
tag_id→tag_name
art_id→art_name
另外因为另外CollectDetailsMusic表和CollectDetailsPlaylist表中的数据有着很多重合，外加上表数量很多后期难以维护，所以我将这两个合并成一张CollectDetails表，再加上一个字段item_type用以区分item_id是Music_id还是Playlist_id
经过修改后得到以下数据表：
(1)User（user_id、user_name、user_password、email、phone、nickname、gender、age）
(2)Music（music_id、music_name、art_id、album、cover_url、lyric_url、type_id、play_count、collect_count、play_url）
(3)Playlist（playlist_id、playlist_name、user_id、create_time、description、cover_url、tag_id）
(4)PlaylistDetails（playlist_id、music_id）
(5)Collect（collect_id、user_id、collect_time、collect_name）
(6)CollectDetails（collect_id、item_id、item_type）
(7)Comment（con_id、user_id、content、item_id、item_type）
(8)MusicType（type_id、type_name）
(9)PlaylistType（tag_id、tag_name）
(10)Artist（art_id，art_name）
这个数据库满足第三范式（3NF）[7]，因为每个表中的非主属性都不传递函数依赖于主键，也就是说，不存在非主属性之间的依赖关系。例如，Music表中的type_id属性不依赖于music_name属性，而只依赖于主键user_id。
经过以上规范化处理后，关系模式更加简洁、清晰，并且减少了数据冗余和不一致性。同时，也提高了数据库的性能和可维护性[8]。
七、数据库系统设计—物理结构设计
本数据库一共设计了10张表，User表用来存储用户数据、Music表用来存储音乐数据、Artist表用来存储作者数据、Playlist表用来存储歌单的定义数据、PlaylistDetails表用来存储歌单中具体歌曲列表数据、Collect表用来存储收藏的定义数据、CollectDetails表用来存储收藏的具体项目数据、Comment表用来存储评论数据、MusicType表用来存储音乐的风格数据、PlaylistType表用来存储歌单的类型数据；
本数据库一共定义了12个索引，其中10个索引均为主键索引，在定义主键时会自动生成，2个唯一索引，分别是User表中的phone和email字段。
表结构如图所示，以下用三线表进行表的物理结构设计展示。
7.1 系统包含表的物理结构设计
(1)User表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 |
|---|---|---|---|---|
| 1 | user_id | char(10) | 主键/NOT NULL | id |
| 2 | user_name | varchar(50) | NOT NULL | 用户名 |
| 3 | user_password | varchar(20) | NOT NULL | 密码 |
| 4 | varchar(50) | NOT NULL | 邮箱 | |
| 5 | phone | char(11) | NOT NULL | 手机号 |
| 6 | nickname | varchar(50) | NOT NULL | 昵称 |
| 7 | gender | enum | NULL | 性别 |
| 8 | age | int | NULL | 年龄 |
(2)Music表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 |
|---|---|---|---|---|
| 1 | music_id | char(10) | 主键/NOT NULL | id |
| 2 | music_name | varchar（50） | NOT NULL | 名称 |
| 3 | art_id | char(10) | NOT NULL | 歌手id |
| 4 | album | varchar（50） | NULL | 专辑名称 |
| 5 | cover_url | varchar（100） | NOT NULL | 封面 |
| 6 | lyric_url | varchar（100） | NULL | 歌词 |
| 7 | type_id | char(5) | NOT NULL | 风格 |
| 8 | play_count | bigint | NULL | 播放量 |
| 9 | collect_count | bigint | NULL | 收藏量 |
| 10 | play_url | varchar（100） | NOT NULL | 播放地址 |
(3)Playlist表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 |
|---|---|---|---|---|
| 1 | playlist_id | char(10) | 主键/NOT NULL | id |
| 2 | playlist_name | Varchar（50） | NOT NULL | 名称 |
| 3 | user_id | char(10) | NOT NULL | 创建者 |
| 4 | create_time | date | NOT NULL | 创建时间 |
| 5 | decription | text | NULL | 描述 |
| 6 | cover_url | varchar（100） | NOT NULL | 封面 |
| 7 | tag_id | char(5) | NOT NULL | 标签 |
(4)PlaylistType表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 |
|---|---|---|---|---|
| 1 | tag_id | char(5) | 主键/NOT NULL | id |
| 2 | tag_name | varchar(10) | NOT NULL | 标签 |
(5)PlaylistDetails表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 |
|---|---|---|---|---|
| 1 | playlist_id | char(10) | 主键/NOT NULL | 歌单id |
| 2 | music_id | char(10) | 主键/NOT NULL | 音乐id |
(6)Collect表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 |
|---|---|---|---|---|
| 1 | collect_id | char(10) | 主键/NOT NULL | id |
| 2 | user_id | char(10) | NOT NULL | 用户 |
| 3 | collect_time | date | NOT NULL | 创建时间 |
| 4 | collect_name | varchar(20) | NULL | 名称 |
(7)CollectDetails表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 |
|---|---|---|---|---|
| 1 | collect_id | char(10) | 主键/NOT NULL | 收藏id |
| 2 | list_id | char(10) | 主键/NOT NULL | 收藏项目id |
| 3 | item_type | enum | 主键/NOT NULL | 收藏类型 |
(8)MusicType表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 | |
|---|---|---|---|---|---|
| 1 | type_id | char(5) | 主键/NONULL | id | |
| 2 | type_name | Varchar（50） | NOT NULL | 音乐风格 | |
(9)Comment表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 |
|---|---|---|---|---|
| 1 | con_id | char(10) | 主键/NOT NULL | id |
| 2 | user_id | char(10) | NOT NULL | 评论用户id |
| 3 | content | text | NOT NULL | 内容 |
| 4 | item_id | char(10) | NOT NULL | 被评论id |
| 5 | item_type | enum | NOT NULL | 被评论类型 |
(10)Artist表
| 列序号 | 列名 | 类型 | 取值说明 | 列含义 |
|---|---|---|---|---|
| 1 | art_id | char(10) | 主键/NOT NULL | id |
| 2 | art_name | varchar(50) | NOT NULL | 姓名 |
八、存储过程和触发器设计
(1)这个触发器[9]会在向 CollectDetails 表插入数据之前检查 item_id 是否合法。如果 item_type 的值为 “歌单”，则 item_id 需要在 Playlist 表的 Playlist_id 字段内；如果 item_type 值为 “歌曲”，则 item_id 需要在 Music 表的 music_id 字段内。如果不匹配，触发器会抛出一个错误，错误内容为 “数据不匹配，请重新输入”。
(2)这个存储过程接受两个 music_id 作为输入，比较这两个 music_id 对应的 play_count。如果第一个 music_id 的 play_count 大于或等于第二个 music_id 的 play_count，则输出 0；否则，输出 1。
(3)这个存储函数接受一个 playlist_id 作为输入，返回这个 playlist_id 对应的歌单中的歌曲总数。
(4)这个触发器会在向 Comment 表插入数据之前检查 item_id 是否合法。如果 item_type 的值为 “歌单”，则 item_id 需要在 Playlist 表的 Playlist_id 字段内；如果 item_type 值为 “歌曲”，则 item_id 需要在 Music 表的 music_id 字段内。如果不匹配，触发器会抛出一个错误，错误内容为 “数据不匹配，请重新输入”。
(5)这个触发器会在 User 表的 user_id 被修改后，自动更新 Collect、Comment 和 Playlist 表中的对应 user_id。
(6)这个触发器会在 MusicType 表的 type_id 被修改后，自动更新 Music 表中的对应 type_id。
(7)这个触发器会在 Artist 表的 art_id 被修改后，自动更新 Music 表中的对应 art_id。
九、运行界面展示
9.1用户系统
(1)运行系统，在浏览器输入localhost:8080即可跳转到账号登录界面，账号登录界面如图所示。
(2)首页展示轮播图和歌单资讯。轮播图可以用于展示系统快捷指令或者系统活动信息；并且展示各类热门歌单供用户选择。首页界面如图所示。
(3)歌单列表用于展示系统所有的歌单，个性化推荐给用户喜欢的歌单，歌单列表界面如图所示。
(4)歌手列表用于展示系统中所有的歌手，点击歌手可跳转到歌手的详细信息页面，歌手列表界面如图所示。
(5)点击音乐列表，可以进入对应音乐的详情界面，展示音乐图片、歌手、歌词、评论等信息，音乐详情界面如图所示。
(6)用户登录后，可以进入个人资料界面设置个人资料、修改密码等操作，个人资料界面如图所示。
9.2管理系统
(1)后台管理首页展示统计的系统信息，比如用户数量、歌曲总数、歌手数量、用户性别比例等信息，后台管理首页界面如图所示。
(2)管理员可对用户进行管理，可批量删除用户，用户管理界面如图所示。
(3)管理员可对歌手进行管理，可以添加、修改、删除歌手，也可对歌手的歌曲进行管理，歌手管理界面如图所示。
(4)管理员可对歌单进行管理，可以添加、编辑、删除歌单，也可对歌单评论进行管理，歌单管理界面如图所示。
十、测试和维护
软件在基本完成开发后，不是立刻就会应用到市场上去。每一个软件在正式应用之前都要经过数次的测试与修改，这样才能保证上线后能够以该软件拥有足够的稳定性、能够快速上手操作、有着可以满足用户需求的功能、优美的页面留住用户，吸引用户继续使用该软件，最后实现项目的圆满完成[10]。
对系统的测试主要是将系统全部的功能运行操作一遍或几遍以上，查看是否出错的一个操作。对系统的测试包含着功能测试和数据测试两部分。其中功能测试是检验本在线音乐网站功能是否可以正常的操作。
表11-1 用户登录模块测试用例
| 用例编号 | 测试用例描述 | 操作过程及数据 | 预期结果 | 测试结果 |
|---|---|---|---|---|
| N1 | 输入正确的用户名密码 | 遵循系统既定规则填写用户名密码后点击确定开始登录系统 | 成功登录系统后，跳转到系统主页 | 通过 |
| N2 | 输入错误的用户名密码 | 遵循系统既定规则填写用户名密码后点击确定开始登录系统 | 系统提示登录失败，并进入错误提示 | 通过 |
| N3 | 空用户名密码 | 遵循系统既定规则填写用户名密码后点击确定开始登录系统 | 系统提示登录失败，并进入错误提示 | 通过 |
表11-2 用户管理模块测试用例
| 用例编号 | 测试用例描述 | 操作过程及数据 | 预期结果 | 测试结果 |
|---|---|---|---|---|
| F1 | 录入用户信息 | 点击添加按钮，填写用户信息，点击确定按钮 | 提示录入成功 | 通过 |
| F2 | 修改用户信息 | 点击列表操作栏中的修改链接，改动信息后点击确定按钮 | 提示修改成功，用户信息变化 | 通过 |
| F3 | 删除用户信息 | 点击列表操作栏中的删除链接 | 提示删除成功，列表刷新 | 通过 |
表11-3密码修改模块测试用例
| 用例编号 | 测试用例描述 | 操作过程及数据 | 预期结果 | 测试结果 |
|---|---|---|---|---|
| T1 | 点击修改密码，输入正确的密码 | 按照系统流程填写密码信息后点击确定 | 系统提示保存成功，密码保存到数据库 | 通过 |
| T2 | 点击修改密码，输入错误的密码 | 按照系统流程填写错误密码信息后点击确定 | 系统报错，跳转到保存失败界面 | 通过 |
| T3 | 点击修改密码，空用户名密码 | 按照系统流程点击修改密码后，不填写直接点击确定 | 系统报错，跳转到保存失败界面 | 通过 |
测试结论，本在线音乐系统可以基本实现管理员对用户注册信息的查看、对音乐和歌手等信息的管理，用户可以根据登录名和密码登录页面，对音乐进行搜索、播放、评价等操作，数据会在修改和添加时进行同步，使得用户和管理员能够看到的信息是统一的，有效的[11]。
总结
音乐管理系统是一个完善的数据库系统。系统的业务需求包括用户管理、歌单管理、收藏管理、音乐管理和评论管理。系统的功能需求及数据需求分析包括用户模块、歌单模块、收藏模块、音乐模块和评论模块。系统的业务规则分析包括用户规则、歌单规则、收藏规则、音乐规则和评论规则。系统中一共包含了10个表，以及对应的主键与相应的外键。创建的数个存储过程、函数与触发器保障了数据库的完整性与安全性；在撰写这次大作业的过程中，我学到很多，如如何分析业务需求和数据需求，如何设计数据库表，如何确保数据库的完整性和安全性；明白了如何分析业务需求，如何更好的理解业务，如将业务转化成文字与图表与代码，最终实现业务的流程；在完成这次作业过程中我也遇到了很多问题与困难，如对于业务的不理解，导致走了很多弯路，前期方案一直改了删删了改，浪费了很多时间。如对于数据库的一些理论知识也遗忘了很多，如关系转换，ER图，第几范式等。解决方案也很简单，第一就是不断熟悉业务，多想想具体的应用场景，其次对于数据库的基础知识，也需要对其进行专门的复习与记忆，并不断在项目中实践，这将是一个长期的过程，需要不断进行。综上所述，在完成这次作业的过程中我学到了很多，虽然也遇到了很多困难，但有这些困难得到的经验与教训是十分宝贵的。我在以后的学习和工作中，也将不断总结经验，不断提高自己的能力，取得更好的成果。
参考文献
[1] 曾遂今.音乐网络传播与当代人的音乐观[J].中国音乐,2006(4):27-3441
[2] 王梦雪.互联网音乐盈利模式新探索[J].当代经济,2016,33(7):38-39
[3] 田洁.网络音乐传播的传播特性与现状研究[J].科技与创新,2020(10):42-44
[4] 王珊，萨师煊，数据库系统概论（第5版），高等教育出版社，2014年。
[5] 郑阿奇主编，MySQL实用教程（第3版），电子工业出版社
[6] 洪学杭, 戴金波, 方权宇, 王轩宇, 刘骐嘉, 刘梦泉. 基于MySQL数据库的戒烟App的设计与研究[J].电脑编程技巧与维护, 2024, (05): 96-99+153.
[7] 刘文远.基于逆向超图的从关系模式到“改进的第三范式”的分解[J].计算机工程与科学,1999,21(6):45-48
[8] 贾玲.关系数据库规范化设计理论探析[J].武警学院学报,2007,23(12):87-89
[9] 唐扬,熊伟,陈宏盛,景宁.数据库触发器机制的设计与实现[J].电子技术应用,2005,31(2):16-18
[10] 王瑶茜,马林虹.浅析软件开发测试体系核心模块组成[J].电子制作,2012,20(10X):110-110
[11] 宋婷玲.关于计算机软件开发中的数据库测试技术研究[J].信息记录材料,2024,25(3):118-120
