数据库课程设计报告——音乐管理系统
目录
省流版word文档
包含了设计报告与相关数据库sql,各位可自取
链接:连接
提取码:2333
需求分析
系统目标
音乐管理系统是一个为用户提供方便、快捷、高效的音乐平台,可以让用户可以随时随地享受音乐,发现新的音乐,分享自己的音乐喜好,增强音乐的社交属性。
业务需求及处理流程
用户管理:用户可以注册、登录、修改个人信息、注销账号等;
-
歌单管理:用户可以创建、编辑、删除自己的歌单,可以将音乐添加到歌单中,可以查看、收藏其他用户的歌单,可以分享自己的歌单到社交媒体等;
-
收藏管理:用户可以收藏自己喜欢的音乐、歌单、歌手等,可以查看、取消收藏、管理自己的收藏夹;
-
音乐管理:系统可以存储音乐的各种信息,包括歌曲、专辑、歌手、流派,歌词等。可以查询音乐的歌词,播放地址等;
-
评论管理:用户可以评论别人的歌曲,歌单,可以查看自己的评论,删除自己的评论。
处理流程: -
用户相关流程:
-
歌单相关流程:
-
收藏相关流程:
-
音乐相关流程:
功能需求及数据需求分析
- 用户模块:实现用户的注册、登录、修改个人信息、注销账号等功能,以及用户的身份验证、权限控制、个性化设置等功能。用户模块的数据需求包括用户的基本信息(用户名、密码、邮箱、手机号、昵称、头像、性别、年龄、地区);
- 歌单模块:实现歌单的创建、编辑、删除等功能,歌单模块的数据需求包括歌单的基本信息(歌单名、创建者、创建时间、描述、封面)、歌单的内容信息(包含的音乐、音乐的顺序、音乐的数量)、歌单的统计信息(收藏量、播放量、评分、评论数);
- 收藏模块:实现收藏的添加、取消、查看、管理等功能,收藏模块的数据需求包括收藏的基本信息(收藏的类型、收藏的对象、收藏的时间)、收藏的统计信息(收藏的数量、收藏的评分);
- 音乐模块:实现音乐的存储、展示、播放、下载等功能,音乐模块的数据需求包括音乐的基本信息(如歌曲名、歌手名、专辑名、时长、大小、格式、封面、歌词等)、音乐的统计信息(如播放量、下载量、收藏量、评分、评论数等)等;
- 评论模块:实现用户在不同音乐,歌单下进行评论评论模块的数据需求包括评论的基本信息(如评论的用户,评论的时间,评论的内容等)、评论的统计信息(如点赞量,转发量,回复量等)。
业务规则分析
- 用户规则:用户必须注册并登录才能使用系统的功能,用户可以修改自己的个人信息,可以注销自己的账号,但不能恢复已注销的账号,用户可以给系统提供反馈信息,系统会根据用户的反馈信息改进服务质量;
- 歌单规则:歌单必须有一个唯一的id,系统不会存储或展示重复的歌单,歌单必须有一个创建者,系统会记录歌单的创建者和创建时间,歌单必须有一个描述,系统会展示歌单的描述,系统会展示歌单的内容和音乐的顺序;
- 收藏规则:收藏必须有一个唯一的id,系统不会存储或展示重复的收藏,收藏必须有一个对象,系统会记录收藏的对象和收藏的时间,收藏除了id与收藏名其他都可以为空;
- 音乐规则:每首音乐都有1个唯一的id,系统不会存储或展示重复的音乐,系统会记录音乐的播放地址、歌手、歌曲名称、歌词信息等;
- 评论规则:每个评论都会有1个唯一的id,系统不会存储id重复的评论,评论只限于歌曲与歌单。
概念设计
命名规范
- 实体集的名称应该是单数名词,且首字母大写,例如:User、Music、Playlist等。
- 属性的名称应该是小写字母,且用下划线分隔单词,例如:user_id、song_name、playlist_id等。
- 联系集的名称应该是两个相关实体集的名称用下划线连接,例如:User_PlayList、PlayList_Music、User_Favor等。
- 主键属性的名称应该是实体集的名称加上_id,例如:user_id、playlist_id、song_id等。
- 外键属性的名称应该是参照实体集的主键属性的名称,例如:creator_id、song_id、object_id等。
实体集及属性
- 用户(User):用户是系统的基本使用者,用户可以注册、登录、修改个人信息、注销账号等。用户实体集的属性有:
- user_id:用户的唯一标识,主键,char类型,非空。
- user_name:用户的用户名,用于登录,唯一,字符串类型,非空,长度不超过255个字符。
- user_password:用户的密码,用于登录,字符串类型,非空,长度不超过20个字符。
- email:用户的邮箱,用于验证和找回密码,唯一,字符串类型,非空,长度不超过50个字符。
- phone:用户的手机号,用于验证和找回密码,唯一,字符串类型,非空,长度为11个字符。
- nickname:用户的昵称,用于展示,字符串类型,非空,长度不超过20个字符。
- gender:用户的性别,用于展示,字符串类型,非空,长度为1个字符,只能是’男’或’女’。
- age:用户的年龄,用于展示,整数类型,非空,范围在0到120之间。
- 音乐(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。
- 歌单(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个字符。
- 收藏(Collect):收藏是系统的基本交互形式,收藏可以被添加、取消、查看、管理等。收藏实体集的属性有:
- collect_id:收藏的唯一标识,主键,整数类型,非空,自增。
- collect_type:收藏的类型,用于分类,字符串类型,非空,长度为2个字符,只能是’歌曲’或’歌单’,分别表示收藏的对象是音乐或歌单。
- user_id:收藏的用户,用于展示,外键,引用 User实体集的外键。
- collect_time:收藏的创建时间,用于展示,日期时间类型,非空,格式为’YYYY-MM-DD HH:MM:SS’。
- description:收藏的描述,用于展示,字符串类型,非空,长度不超过500个字符。
- 评论(Comment):评论是系统的基本内容,评论可以被存储、展示等。评论实体集的属性有:
- con_id:评论的唯一标识,主键,char类型,非空。
- user_id:用户的唯一标识,char类型,非空。
- content:评论的内容,char类型,非空。
- item_id:被评论对象的唯一标识,char类型,非空。
- item_type:被评论对象的类型,代表着歌单或歌曲,enum类型,非空。
联系集及属性
- 用户_歌单(User_Playlist):用户和歌单之间的联系集,表示用户可以创建、编辑、删除自己的歌单;
- 歌单_音乐(Playlist_Music):歌单和音乐之间的联系集,表示歌单可以包含一个或多个音乐,音乐可以属于一个或多个歌单,歌单的创建者可以将音乐添加到歌单中,也可以从歌单中移除音乐,歌单的内容和音乐的顺序可以被编辑;
- 用户_收藏(User_Collect):用户和收藏之间的联系集,表示用户可以收藏自己喜欢的音乐、歌单、歌手等,也可以查看、取消收藏、管理自己的收藏夹 ;
- 收藏_音乐(Collect_Music):收藏和音乐的联系集,表示一首歌可以被一个或多收藏夹收藏,一个收藏夹可以收藏一个或多个音乐,用户可以向收藏夹中增添、删除音乐;
- 收藏_歌单(Collect_Playlist):收藏和歌单的联系集,表示一个歌单可以被一个或多收藏夹收藏,一个收藏夹可以收藏一个或多个歌单,用户可以向收藏夹中增添、删除歌单;
- 评论_音乐(Comment_Music):评论音乐的联系集,表示一首歌可以拥有多个评论,但同一个评论只能属于一首歌,用户可以自己添加、删除评论;
- 评论_歌单(Comment_Playlist):评论歌单的联系集,表示一个歌单可以拥有多个评论,但同一个评论只能属于一歌单,用户可以自己添加、删除评论。
系统总ER图
-
User:
-
Playlist:
-
Collect:
-
Music:
-
Comment:
-
总E-R图:
逻辑设计
关系的设计
经过以上E-R图设计,再对相关表结构优化后得到如下设计:
- User(user_id、user_name、user_password、email、phone、nickname、gender、age)
- Music(music_id、music_name、art_id、art_name、album、cover_url、lyric_url、type_id、type_name、play_count、collect_count、play_url)
- Playlist(playlist_id、playlist_name、user_id、create_time、description、cover_url、tag_id、tag_name)
- PlaylistDetails(playlist_id、music_id)
- Collect(collect_id、user_id、collect_time、collect_name)
- CollectDetailsMusic(collect_id、item_id)
- CollectDetailsPlaylist(collect_id、item_id)
- Comment(con_id、user_id、content、item_id、tiem_type)
关系的优化
此数据库是满足第二范式(2NF)的:
这个数据库满足第一范式(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
经过修改后得到以下数据表:
- User(user_id、user_name、user_password、email、phone、nickname、gender、age)
- Music(music_id、music_name、art_id、album、cover_url、lyric_url、type_id、play_count、collect_count、play_url)
- Playlist(playlist_id、playlist_name、user_id、create_time、description、cover_url、tag_id)
- PlaylistDetails(playlist_id、music_id)
- Collect(collect_id、user_id、collect_time、collect_name)
- CollectDetails(collect_id、item_id、item_type)
- Comment(con_id、user_id、content、item_id、item_type)
- MusicType(type_id、type_name)
- PlaylistType(tag_id、tag_name)
- Artist(art_id,art_name)
这个数据库满足第三范式(3NF),因为每个表中的非主属性都不传递函数依赖于主键,也就是说,不存在非主属性之间的依赖关系。例如,Music表中的type_id属性不依赖于music_name属性,而只依赖于主键user_id。
数据库基本表设计
- User:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
user_id | char | 10 | √ | √ | 用户唯一标识 |
user_name | varchar | 50 | √ | 用户的用户名 | |
user_password | varchar | 20 | √ | 用户的密码 | |
varchar | 50 | √ | 用户的邮箱 | ||
phone | char | 11 | √ | 用户的手机号 | |
nickname | varchar | 50 | √ | 用户的昵称 | |
gender | enum | 用户的性别 | |||
age | int | 50 | 用户的年龄 |
- Music:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
music_id | char | 10 | √ | √ | 音乐的唯一标识 |
music_name | varchar | 50 | √ | 音乐的名称 | |
art_id | char | 10 | √ | 音乐的歌手的id | |
album | varchar | 50 | 音乐的专辑名称 | ||
cover_url | varchar | 100 | √ | 音乐的封面 | |
lyric_url | varchar | 100 | 音乐的歌词 | ||
type_id | char | 5 | √ | 音乐风格的唯一标识 | |
play_count | bigint | 音乐的播放量 | |||
collect_count | bigint | 音乐的收藏量 | |||
play_url | varchar | 100 | √ | 音乐的播放地址 |
- Playlist:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
playlist_id | char | 10 | √ | √ | 歌单的唯一标识 |
playlist_name | varchar | 50 | √ | 歌单的名称 | |
user_id | char | 10 | √ | 歌单的创建者 | |
create_time | date | √ | 歌单的创建时间 | ||
description | text | 歌单的描述 | |||
cover_url | varchar | 100 | √ | 歌单的封面 | |
tag_id | char | 5 | √ | 歌单标签的唯一标识 |
- PlaylistType:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
tag_id | char | 5 | √ | √ | 歌单标签的唯一标识 |
tag_name | varchar | 10 | √ | 歌单标签 |
- PlaylistDetails:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
playlist_id | char | 10 | √ | √ | 歌单的唯一标识 |
music_id | char | 10 | √ | √ | 音乐的唯一标识 |
- Collect:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
collect_id | char | 10 | √ | √ | 收藏的唯一标识 |
user_id | char | 10 | √ | 收藏的用户 | |
collect_time | date | √ | 收藏的创建时间 | ||
collect_name | varchar | 20 | 收藏的名字 |
- CollectDetails:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
collect_id | char | 10 | √ | √ | 收藏的唯一标识 |
list_id | char | 10 | √ | √ | 收藏项目的唯一标识 |
item_type | enum | √ | √ | 收藏项目的类型 |
- MusicType:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
type_id | char | 5 | √ | √ | 音乐风格的唯一标识 |
type_name | varchar | 50 | √ | 音乐风格 |
- Comment:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
con_id | char | 10 | √ | √ | 评论的唯一标识 |
user_id | char | 10 | √ | 评论用户的唯一标识 | |
content | text | √ | 评论的内容 | ||
item_id | char | 10 | √ | 被评论对象的id | |
item_type | enum | √ | 被评论对象的类型 |
- Artist:
字段名 | 数据类型 | 长度 | 主键 | 非空 | 描述 |
---|---|---|---|---|---|
art_id | char | 10 | √ | √ | 歌手的唯一标识 |
art_name | varchar | 50 | √ | 歌手姓名 |
物理设计
表名 | 索引名 | 索引列 | 索引类型 |
---|---|---|---|
User | User_PrimaryKey | user_id | 主键索引 |
User | User_Unique_email | 唯一性索引 | |
User | User_Unique_phone | phone | 唯一性索引 |
Music | Music_PrimaryKey | music_id | 主键索引 |
Playlist | Playlist_PrimaryKey | playlist_id | 主键索引 |
PlaylistDetails | PlaylistDetails_PrimaryKey | playlist_id music_id | 主键索引 |
Collect | Collect_PrimaryKey | collect_id | 主键索引 |
CollectDetails | CollectDetails_PrimaryKey | collect_id item_id item_type | 主键索引 |
Comment | Comment_PrimaryKey | con_id | 主键索引 |
MusicType | MusicType_PrimaryKey | type_id | 主键索引 |
PlaylistType | PlaylistType_PrimaryKey | tag_id | 主键索引 |
Artist | Artist_PrimaryKey | art_id | 主键索引 |
关系模式存取方式选择
数据库的存储结构
综上所述:
本数据库一共设计了10张表,User表用来存储用户数据、Music表用来存储音乐数据、Artist表用来存储作者数据、Playlist表用来存储歌单的定义数据、PlaylistDetails表用来存储歌单中具体歌曲列表数据、Collect表用来存储收藏的定义数据、CollectDetails表用来存储收藏的具体项目数据、Comment表用来存储评论数据、MusicType表用来存储音乐的风格数据、PlaylistType表用来存储歌单的类型数据;
本数据库一共定义了12个索引,其中10个索引均为主键索引,在定义主键时会自动生成,2个唯一索引,分别是User表中的phone和email字段。
数据库应用设计
数据库脚本
- 建库建表:
CREATE DATABASE MusicManager;
USE MusicManager;
CREATE TABLE User (
user_id CHAR ( 10 ) PRIMARY KEY,
user_name VARCHAR ( 50 ) NOT NULL,
user_password VARCHAR ( 20 ) NOT NULL,
email VARCHAR ( 50 ) NOT NULL UNIQUE,
phone CHAR ( 11 ) NOT NULL UNIQUE,
nickname VARCHAR ( 50 ) NOT NULL,
gender ENUM ( '男', '女' ,'未知') DEFAULT '未知' ,
age INT DEFAULT 18
);
CREATE TABLE Music (
music_id CHAR ( 10 ) PRIMARY KEY,
music_name VARCHAR ( 50 ) NOT NULL,
art_id CHAR ( 10 ) NOT NULL,
album VARCHAR ( 50 ),
cover_url VARCHAR ( 100 ) NOT NULL,
lyric_url VARCHAR ( 100 ),
type_id CHAR ( 5 ) NOT NULL,
play_count BIGINT DEFAULT 0,
collect_count BIGINT DEFAULT 0,
play_url VARCHAR ( 100 ) NOT NULL
);
CREATE TABLE Playlist (
playlist_id CHAR ( 10 ) PRIMARY KEY,
playlist_name VARCHAR ( 50 ) NOT NULL,
user_id CHAR ( 10 ) NOT NULL,
create_time DATE NOT NULL,
description TEXT,
cover_url VARCHAR ( 100 ) NOT NULL,
tag_id CHAR ( 5 ) NOT NULL
);
CREATE TABLE PlaylistType (
tag_id CHAR ( 5 ) PRIMARY KEY,
tag_name VARCHAR ( 10 ) NOT NULL
);
CREATE TABLE PlaylistDetails (
playlist_id CHAR ( 10 ) NOT NULL,
music_id CHAR ( 10 ) NOT NULL,
PRIMARY KEY ( playlist_id, music_id )
);
CREATE TABLE Collect (
collect_id CHAR ( 10 ) PRIMARY KEY,
user_id CHAR ( 10 ) NOT NULL,
collect_time DATE NOT NULL,
collect_name VARCHAR ( 20 )
);
CREATE TABLE CollectDetails (
collect_id CHAR ( 10 ) NOT NULL,
list_id CHAR ( 10 ) NOT NULL,
item_type ENUM ( '歌单', '歌曲' ) NOT NULL,
PRIMARY KEY ( collect_id, list_id, item_type )
);
CREATE TABLE MusicType (
type_id CHAR ( 5 ) PRIMARY KEY,
type_name VARCHAR ( 50 ) NOT NULL
);
CREATE TABLE Comment (
con_id CHAR ( 10 ) PRIMARY KEY,
user_id CHAR ( 10 ) NOT NULL,
content TEXT NOT NULL,
item_id CHAR ( 10 ) NOT NULL,
item_type ENUM ( '歌曲', '歌单' ) NOT NULL
);
CREATE TABLE Artist (
art_id CHAR ( 10 ) PRIMARY KEY,
art_name VARCHAR ( 50 ) NOT NULL
);
ALTER TABLE Music
ADD FOREIGN KEY ( type_id )
REFERENCES MusicType ( type_id ),
ADD FOREIGN KEY ( art_id )
REFERENCES Artist ( art_id );
ALTER TABLE Playlist
ADD FOREIGN KEY ( user_id )
REFERENCES User ( user_id ),
ADD FOREIGN KEY ( tag_id )
REFERENCES PlaylistType ( tag_id );
ALTER TABLE PlaylistDetails
ADD FOREIGN KEY ( playlist_id )
REFERENCES Playlist ( playlist_id ),
ADD FOREIGN KEY ( music_id )
REFERENCES Music ( music_id );
ALTER TABLE Collect
ADD FOREIGN KEY ( user_id )
REFERENCES USER ( user_id );
ALTER TABLE CollectDetails
ADD FOREIGN KEY ( collect_id )
REFERENCES Collect ( collect_id );
ALTER TABLE Comment
ADD FOREIGN KEY ( user_id )
REFERENCES User ( User_id );
- 插入数据:(因为数据过多所以只展示其中一部分)
Artist:
PlaylistType:
MusicType:
User:
Collect:
PlaylistDetails:
数据库完整性设计
- 每个表都应有一个主键,用于唯一标识表中的每一行;
- 如果一个表的某列包含另一个表的主键,则该列应被设置为外键;
- 当向Music表中修改数据时CollectDetails与PlaylistDetails与Comment表需同时修改;
- 当修改User表数据时需同时修改Collect与Comment与Playlist表;
- 当修改Artist表数据时需同时修改Music表里的数据。
数据库安全性设计
用户想要修改相关数据表必须拥有相关数据表权限
存储过程和触发器设计
- 这个触发器会在向 CollectDetails 表插入数据之前检查 item_id 是否合法。如果 item_type 的值为 “歌单”,则 item_id 需要在 Playlist 表的 Playlist_id 字段内;如果 item_type 值为 “歌曲”,则 item_id 需要在 Music 表的 music_id 字段内。如果不匹配,触发器会抛出一个错误,错误内容为 “数据不匹配,请重新输入”。
- 这个存储过程接受两个 music_id 作为输入,比较这两个 music_id 对应的 play_count。如果第一个 music_id 的 play_count 大于或等于第二个 music_id 的 play_count,则输出 0;否则,输出 1。
- 这个存储函数接受一个 playlist_id 作为输入,返回这个 playlist_id 对应的歌单中的歌曲总数。
- 这个触发器会在向 Comment 表插入数据之前检查 item_id 是否合法。如果 item_type 的值为 “歌单”,则 item_id 需要在 Playlist 表的 Playlist_id 字段内;如果 item_type 值为 “歌曲”,则 item_id 需要在 Music 表的 music_id 字段内。如果不匹配,触发器会抛出一个错误,错误内容为 “数据不匹配,请重新输入”。
- 这个触发器会在 User 表的 user_id 被修改后,自动更新 Collect、Comment 和 Playlist 表中的对应 user_id。
- 这个触发器会在 MusicType 表的 type_id 被修改后,自动更新 Music 表中的对应 type_id。
- 这个触发器会在 Artist 表的 art_id 被修改后,自动更新 Music 表中的对应 art_id。
总结
音乐管理系统是一个完善的数据库系统。系统的业务需求包括用户管理、歌单管理、收藏管理、音乐管理和评论管理。系统的功能需求及数据需求分析包括用户模块、歌单模块、收藏模块、音乐模块和评论模块。系统的业务规则分析包括用户规则、歌单规则、收藏规则、音乐规则和评论规则。系统中一共包含了10个表,以及对应的主键与相应的外键。创建的数个存储过程、函数与触发器保障了数据库的完整性与安全性;在撰写这次大作业的过程中,我学到很多,如如何分析业务需求和数据需求,如何设计数据库表,如何确保数据库的完整性和安全性;明白了如何分析业务需求,如何更好的理解业务,如将业务转化成文字与图表与代码,最终实现业务的流程,我也明白了团队合作的重要性,很多事光凭一个人的力量很难进行下去,唯有进行团队合作,合理分工才能顺利推进;在完成这次作业过程中我也遇到了很多问题与困难,如对于业务的不理解,导致走了很多弯路,前期方案一直改了删删了改,浪费了很多时间。如对于数据库的一些理论知识也遗忘了很多,如关系转换,er图,第几范式等。解决方案也很简单,第一就是不断熟悉业务,多想想具体的应用场景,其次对于数据库的基础知识,也需要对其进行专门的复习与记忆,并不断在项目中实践,这将是一个长期的过程,需要不断进行。综上所述,在完成这次作业的过程中我学到了很多,虽然也遇到了很多困难,但有这些困难得到的经验与教训是十分宝贵的。我在以后的学习和工作中,也将不断总结经验,不断提高自己的能力,取得更好的成果。
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。 如若内容造成侵权/违法违规/事实不符,请联系我的编程经验分享网邮箱:veading@qq.com进行投诉反馈,一经查实,立即删除!