音乐网站平台项目数据库设计

一 数据库设计步骤

        1 需求分析

 收集数据：

        为了使用数据库系统管理这些数据，需要尽可能多次地收集数据并理解企业地业务过程和数据处理流程，理解数据处理地性能需求。（主要需要根据具体地业务和功能分析出要有地实体和属性）

ps：实体指客观存在并可相互区分地事务，个人感觉这里地实体和面向对象思想可以相关理解，这里地实体可以看作面向对象思想里面由类创建出来地对象，属性即为类地属性。

解决冲突：

        包括命名冲突（同名异义，异名同义）属性冲突，结构冲突，例如：商品库存数量是否包含已经下订单但是没有出库地数量；到货数量和入库数量以哪一个为准；用户名和昵称和真实姓名如何区分；性别使用男，女，还是（0，1）表示

为数据形成标准：

        如商品编号地位数，未来是否会增加位数，每一位地含义是什么；订单编号按照什么规则形成，如何避免编号重复，编号中包含哪些信息，是否加入一些随机数防止被推测等。

        2 概念数据库地设计

对用户地需求进行综合，归纳，抽象，形成概念模型，（概念模型即绘制e-r图）

例如：

 图中由实体和属性，实体实体之间的关系。

        3 逻辑数据库的设计

即将e-r图转换为DBMS支持的数据模型（如关系模型，即整个e-r图对应几张表），在DBMS中一个关系对应一张表。

例如：上述e-r图可以转换为如下三张表

         4 物理数据库的设计

该阶段要确认数据库的存储结构，文件类型，存储引擎等，通常DBMS为了保证其独立性和可移植性，承担了大部分的任务，数据库设计人员只需要考虑硬件，操作系统的特性，为数据库选择合适的存储引擎，为字段选择合适数据类型。

        5 数据库实施

用sql语句创建数据库，数据表，编写与调试应用程序。

        6 数据库运行与维护

数据库运行和维护就是将数据库系统正式投入运行，在运行后进行一些维护操作，调整，备份，升级等工作。

二 数据库范式的设计

ps 个人感觉应该在逻辑数据库设计时考虑数据库范式（通常考虑三范式足够）

        第一范式

指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值，或不能有重复的属性。

 

 

        第二范式

满足第二范式必须先满足第一范式，第二范式要求实体属性完全依赖于主键，不能仅仅依赖于主键的一部分（对于复合主键而言）第二范式非主键字段需完全依赖于主键

        

 

        第三范式

满足第三范式必须满足第二范式，第三范式要求数据表中的每一列数据都和主键字段直接相关，而不能间接相关，简而言之第三范式就是非主键字段不能相互依赖。

ps：以上是数据库设计时可以大致参考的模型，具体还需根据经验来分析，积累，学习。第二范式和第三范式都是为了解决数据表的插入异常，删除异常，更新异常，在具体业务的时候可以直接检查设计的数据表对照业务是否有上述异常，来反向规范第二和第三范式。 

       

2 数据架构表设计

从网站的开发需求与网站设计得知，歌曲信息是整个网站最为核心的数据。

因此，设计网站的数据结构时，应以歌曲信息为核心数据，逐步向外扩展相关的数据信息。我们将歌曲信息的数据表命名为song。

2.1 歌曲信息表

表字段	字段类型	含义
id	Int类型，长度为11	主键
name	Varchar类型，长度为50	歌曲名称
singer	Varchar类型，长度为50	歌曲的演唱歌手
time	Varchar类型，长度为50	歌曲的播放时长
album	Varchar类型，长度为50	歌曲所属专辑
languages	Varchar类型，长度为50	歌曲的语种
type	Varchar类型，长度为50	歌曲的风格类型
release	Date类型	歌曲的发行时间
img	Varchar类型，长度为100	歌曲封面图片路径
lyrics	Varchar类型，长度为100	歌曲的歌词文件路径
file	Varchar类型，长度为100	歌曲的文件路径
label_id	Int类型，长度为11	外键，关联歌曲分类表

歌曲信息表记录了歌曲的基本信息，如歌名、歌手、时长、专辑等等，其中歌曲封面、歌词和歌曲文件是以文件路径的形式记录在数据库中的，一般来说如果网站中涉及文件的存储和使用，那么数据库最好记录文件的路径地址。若将文件内容以二进制的数据格式写入数据库，则会对数据库造成一定的压力，从而降低网站的响应速度。

2.2 歌曲分类表

歌曲信息表关联歌曲分类表，我们将歌曲分类表命名为label，歌曲分类表主要实现排行榜的歌曲筛选功能。

表字段	字段类型	含义
id	Int类型，长度为11	主键
name	Varchar类型，长度为10	歌曲的分类标签

2.3 歌曲动态表

项目需求涉及歌曲的动态信息，因此延申出了歌曲动态表。

歌曲动态表用于记录歌曲的播放次数、搜索次数个下载次数，并且与歌曲信息表实现一对一的数据关系，也就是一首歌曲只有一条动态信息。将歌曲动态表命名为dynamic。

表字段	字段类型	含义
id	Int类型，长度为11	主键
plays	Int类型，长度为11	歌曲的播放次数
search	Int类型，长度为11	歌曲的搜索次数
download	Int类型，长度为11	歌曲的下载次数
song_id	Int类型，长度为11	外键，关联歌曲信息表

2.4 歌曲点评表

该表主要用于歌曲点评页面。

从歌曲点评页面知道，一首歌可以有多条点评的信息，说明歌曲信息表和歌曲点评表存在一对多的数据关系。

将歌曲点评表命名为comment。

表字段	字段类型	含义
id	Int类型，长度为11	主键
text	Varchar类型，长度为500	歌曲的点评内容
user	Varchar类型，长度为20	用户名
date	Date类型	点评日期
song_id	Int类型，长度为11	外键，关联歌曲信息表

2.5 用户表

还有网站的用户管理功能需要实现。

由用户表提供用户信息。用户表由Django内置模型User扩展而成。

表字段	字段类型	含义
id	Int类型，长度为11	主键
password	Varchar类型，长度为128	用户密码
last_login	Datetime类型，长度为6	上次登录的时间
is_superuser	Tinyint类型，长度为1	超级用户
username	Varchar类型，长度为150	用户名
first_name	Varchar类型，长度为30	用户的名字
last_name	Varchar类型，长度为150	用户的姓氏
email	Varchar类型，长度为254	邮箱地址
is_staff	Tinyint类型，长度为1	登录Admin权限
is_active	Tinyint类型，长度为1	用户的激活状态
date_joined	Datetime类型，长度为6	用户创建的时间
qq	Varchar类型，长度为20	用户的QQ号码
weChat	Varchar类型，长度为20	用户的微信号码
mobile	Varchar类型，长度为11	用户的手机号码

  2.6 E-R图

        

 

2.7 表关系分析

        index_song 表为每一首歌曲的基本信息，一首歌对应一条歌曲动态信息，一首歌对应一条评论信息，反之一条歌曲动态信息对应一首歌曲，一条评论对应一首歌曲，则index_song和index_comment和index_dynamic为一对一的关系分别给index_comment和index_dynamic添加关于表index_song的外键，来表示一对一关系。（在一对一关系中外键可以设置在两表中的任意一方，且一张表可以有多个外键）

        index_label为歌曲分类，每一首歌对应可以对应一种歌曲分类，每一种分类可对应很多首歌曲，两者为一对多关系（此时多个歌曲对应一种歌曲分类，为一对多关系，外键只能设置在“多”的关系一方）

2.8 外键补充

        Django里面的外键设置语法为例如：

class ForeignKey(to, on_delete, **options)

前两个参数为必须参数第三个为备选参数可以不填

其中to参数为要关联的表的名字，当填self时为管理自己

on_delete为外键约束选项：

• models.CASCADE：级联删除。当外键关联的对象被删除时，自动删除包含该外键的所有对象。
• models.PROTECT：保护。当外键关联的对象被删除时，抛出 ProtectedError 异常，防止对象被误删。
• models.SET_NULL：设为 NULL。设置关联的外键内容为null。只有设置了null=True时可用。当数据被删除时，被关联的外键内容被设置为null。
• models.SET_DEFAULT：设为默认值。当外键关联的对象被删除时，将外键字段设为默认值，所以定义外键的时候注意加上一个默认值
• models.SET()：设为指定值。将SET()设置的值作为外键的值 ，如果传递了callable，则调用它的结果，set里面可以传递一个函数的引用，调用时返回函数的返回值。

2.9 相关字段解释补充

FileField(Field)    - 字符串，路径保存在数据库，文件上传到指定目录
    - 参数：
        upload_to = ""      上传文件的保存路径
        storage = None      存储组件，默认django.core.files.storage.FileSystemStorage
ImageField(FileField)    - 字符串，路径保存在数据库，文件上传到指定目录
    - 参数：
        upload_to = ""      上传文件的保存路径
        storage = None      存储组件，默认django.core.files.storage.FileSystemStorage
        width_field=None,   上传图片的高度保存的数据库字段名（字符串）

AutoField(Field) - int自增列，必须填入参数 primary_key=True,或者设置unique=true,当插入将该值设置为null，或者0时会自动加一，设置其他数字则使用插入的数字

DateTimeField(DateField)    - 日期+时间格式 YYYY-MM-DD HH:MM[:ss[.uuuuuu]][TZ]
DateField(DateTimeCheckMixin, Field)    - 日期格式      YYYY-MM-DD
TimeField(DateTimeCheckMixin, Field)    - 时间格式      HH:MM[:ss[.uuuuuu]]

• auto_now：每次保存该对象时，自动将该字段设为当前日期。若设为 True，则不能手动设置该字段的值。
• auto_now_add：当对象第一次被创建时，自动将该字段设为当前日期。若设为 True，则不能手动设置该字段的值。
• default：默认值。可以指定该字段的默认值，如 default=datetime.date.today 。
• null：是否允许为空值。若设为 True，则该字段可以为 NULL 。反之，则不能为空。
• blank：是否允许为空字符串。若设为 True，则该字段可以为空字符串。反之，则不能为空字符串。
• verbose_name：人类可读的名称。该字段表示该模型的一个属性，用于展示该字段的名称。如 verbose_name = '生日' 。

2.10 Meta内部类设置

 class Meta:
            # 数据库中生成的表名称 默认 app名称 + 下划线 + 类名
            db_table = "table_name"
            # 联合索引
            index_together = [
                ("pub_date", "deadline"),
            ]
 
            # 联合唯一索引
            unique_together = (("driver", "restaurant"),)
 
            # admin中显示的表名称
            verbose_name
 
            # verbose_name加s
            verbose_name_plural

verbose_name指定在admin管理界面中显示中文；verbose_name表示单数形式的显示，verbose_name_plural表示复数形式的显示；中文的单数和复数一般不作区别，Django后台可能用到数据表的单数名字和复数名字，不指定时复数直接在名字加s。

2.11 用Django内置的用户类编写用户表

        

在 Django 中，可以通过继承 AbstractUser 模型类来实现用户认证和管理系统。AbstractUser 是 Django 默认的用户模型类，它存储了一些通用的用户数据，如用户名、密码、邮箱等，并提供了一些方法用于验证、登录、注销等操作。在使用 AbstractUser 模型类时，需要先配置 AUTH_USER_MODEL 参数，以便 Django 使用自定义的用户模型类。