数据库MYSQL——表的设计

文章目录

前言
- - 三大范式：
  - 几种实体间的关系：
  - - 一对一关系：
    - 一对多关系：
    - 多对多关系：

前言

之前的博客中我们讲解的是关于数据库的增删改查与约束的基本操作，
是在已经创建数据库，表之上的操作。
在实际的项目开发过程中，表的设计是需要我们根据需求来分析设计的，
表设计的过程：
OOA面向对象分析–>OOD面向对象设计–>OOP面向对象编程。

首先：我们是从需求中获得类（与java中的对象类的概念相同），
然后类对应数据库中的实体，实体对应数据库中一张一张的表
，而类中的每一个属性对应表中的每一个字段（列）。

其次获取类与类之间的关系，类与类之间的关系（或者说实体与实体之间的关系）有
一对一，一对多，多对多三种关系。

最后进行SQL语句进行创建表。

三大范式：

在创建关系型数据库时，遵循着一些规则称为三大范式。
第一范式：即表中的每一列属性不可以再划分（即实体不可以作为属性）。
例：设计一个学生表
在这里插入图片描述
如果这样设计即是错误的，因为“学校”是一个实体，它还可以再划分：

如果“学校”换成下面三个属性，则该表的创建满足第一范式。

第二范式：
第二范式即在满足第一范式的基础上，避免非关键字段（）对任一候选键（主键，外键，唯一键）产生部分函数依赖（下面给出解释）。第二范式的本质上依然是一个表（非关联表）只能表示一个实体，一个实体只能对应一个类。
举例说明：
反例：
在这里插入图片描述
在此表中，学分不依赖于学号，而依赖于课程名字段，姓名，年龄不依赖于课程名，而是依赖于学号字段，这样在两个及以上的关键字段决定一条记录的表中，存在部分非关键字段对其中一个关键字段依赖的情况称为部分函数依赖。

正例：
在这里插入图片描述
在上图中每张表的非主键字段都强依赖于主键字段，满足第二范式。

不满足第二范式的坏处：

在查询数据时，会产生大量的数据冗余。
例如：只想要查询学生的学号，姓名信息，却会展示出课程名，学分等无用的信息。
更新异常，比如要更新课程所对应的学分，这种实体混合在一张表中的模式会导致不能够整体地更新某一个实体记录中的数据，下次插入数据时，课程对应的学分还是原来的数据，会导致数据不一致的情况出现。
插入异常：
对于课程实体我们没有单独地设置一张表，那么假如我们设置了一门新的课程，则除非插入一条学生信息，否则不能查询到此课程的信息如学分，但是插入学生信息时，必须插入此课程的考试成绩，成绩为空又没有意义。
删除异常：
如将全部的毕业学生信息都删除后，则课程的信息也全部会被删除，无法查询到课程的信息了。

第三范式：
在满足了第二范式的基础上，不存在非关键字段对任一候选键的传递依赖。本质上依然是一个表中只能实现一个类（实体）。

反例：
在这里插入图片描述