MySQL表设计详解

范式

数据库的范式是⼀组规则。在设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式。

关系数据库有六种范式：第⼀范式（1NF）、第⼆范式（2NF）、第三范式（3NF） 、巴斯-科德范式（BCNF）、第四范式（4NF）和第五范式（5NF，⼜称完美范式），越⾼的范式数据库冗余越⼩。然⽽，普遍认为范式越⾼虽然对数据关系有更好的约束性，但也可能导致数据库IO更繁忙，因此在实际应⽤中，数据库设计通常只需满⾜第三范式即可。

第⼀范式

数据库表的每⼀列都是不可分割的原⼦数据项，⽽不能是集合，数组，对象等⾮原⼦数据。
在关系型数据库的设计中，满⾜第⼀范式是对关系模式的基本要求。不满⾜第⼀范式的数据库就不能被称为关系数据库
在关系型数据库中，每⼀列都可以⽤基本数据类型表⽰，就天然满⾜第⼀范式

反例：学校是一个对象，还可以继续拆分，不满足第一范式

正例：学校信息包含在⼀⾏中，每⼀列都不能再进⾏拆分

第二范式

在满⾜第⼀范式的基础上，不存在**⾮关键字段** 对任意候选键的部分函数依赖。存在于表中定义了复合主键的情况下。

候选键：可以唯⼀标识⼀⾏数据的列或列的组合，可以从候选键中选⼀个或多个当做表的主键

第⼆范式强调的是部分函数依赖，当⼀张表中的主键只有⼀列时，天然满⾜第⼆范式

反例：

这张表中使⽤学号+课程名定义复合主键来唯⼀标识⼀个学⽣某⻔课程的成绩，这也是这张表的主要作⽤
学⽣是通过学号来确定的，学⽣的姓名、年龄和性别和课程没有关系，即学⽣的信息只依赖学号，不依赖课程名；学分是通过课程来确定的，课程的学分与学⽣没有关系，即学分只依赖课程名，不依赖学⽣
对于使⽤复合主键的表，如果⼀⾏数据中的有些列只与复合主键中的⼀个或其中⼏个列有关系，那么就说他存在部分函数依赖，也就不满⾜第⼆范式

不满足第二范式时可能出现的问题

数据冗余
学⽣的姓名、年龄、性别和课程的学分在每⾏记录中重复出现，造成了⼤量的数据冗余。
更新异常
如果要调整MySQL的学分，那么就需要更新表中所有关于MySQL的记录，⼀旦执行中断导致某些记录更新成功，某些数据更新失败，就会造成表中同⼀⻔课程出现不同学分的情况，出现数据不⼀致问题。
插⼊异常
⽬前这样的设计，成绩与每⼀⻔课和学⽣都有对应关系，也就是说只有学⽣参加选修课程考试取得了成绩才能⽣成⼀条记录。当有⼀⻔新课还没有学⽣参加考试取得成绩之前，那么这⻔新课在数据库中是不存在的，因为成绩为空时记录没有意义。
删除异常
把毕业学⽣的考试数据全都删除，此时课程和学分的信息也会被删除掉，有可能导致⼀段时间内，数据库⾥没有某⻔课程和学分的信息。

正例：应该设计三张表，即：学⽣表、课程表和成绩表

第三范式

在满⾜第⼆范式的基础上，不存在⾮关键字段，对任⼀候选键的传递依赖。

反例

在这个表结构中，可以看出学⽣的学号、姓名、年龄、性别与主键Id强相关；学院电话、学院地址与学院强相关；在⼀个表中出现了两个强相关的关系，⽽且这两个强相关关系⼜存在传递现象，即通过学⽣Id可以找到学⽣记录，学⽣记录中包含学院名，每个学院⼜有⾃⼰的电话和地址
这种传递现象称为传递依赖，所以当前的表不满⾜第三范式

应该把学院信息拆分出来定义学院表，学⽣表与学院表做关联

设计过程

从现实业务中抽象得到概念类

概念类是从现实世界中抽象出来的，在需求分析阶段就需要确定下来
- 类对应了数据库设计中的实体，实体对应了数据库中的表
- 类中的属性对应实体中的属性，实体的属性对应了表中的列
确定实体与实体之间的关系，并画出E-R画，⽅便项⽬参与⼈员理解与沟通
根据E-R图完成SQL语句的编号并创建数据库

实体-关系图

实体-关系图（Entity-Relationship Diagram）简称E-R图，也称作实体联系模型、实体关系模型，是⼀种⽤于描述数据模型的概念图，主要⽤于数据库设计阶段。

E-R图的基本组成

E-R图包含了以下三种基本成分： •

实体：即数据对象，⽤矩形框表⽰，⽐如⽤⼾、学⽣、班级等。
属性：实体的特性，⽤椭圆形或圆⻆矩形表⽰，如学⽣的姓名、年龄等。
关系：实体之间的联系，⽤菱形框表⽰，并标明关系的类型，并⽤直线将相关实体与关系连接起来。

⼀对⼀关系

⽤⼾实体与账⼾实体是⼀对⼀的关系

sql 复制代码

-- 在⽤⼾实体中添加对账⼾实体的关联
drop table if exists users;
create table users (
 id bigint primary key auto_increment,
 name varchar(20) not null, 
 nickname varchar(20),
 phone_num varchar(11), 
 email varchar(50),
 gender tinyint(1),
 account_id bigint
);
drop table if exists account;
create table account (
 id bigint primary key auto_increment,
 username varchar(20) not null,
 password varchar(32) not null
);

-- 在账⼾实体中添加对⽤⼾实体的关联
drop table if exists users;
create table users (
 id bigint primary key auto_increment,
 name varchar(20) not null, 
 nickname varchar(20),
 phone_num varchar(11), 
 email varchar(50),
 gender tinyint(1)
);
drop table if exists account;
create table account (
 id bigint primary key auto_increment,
 username varchar(20) not null,
 password varchar(32) not null,
 users_id bigint
);

⼀对多关系

⼀个班级中有多个学⽣，所以班级实体与学⽣实体是⼀对多的关系

sql 复制代码

-- 班级表
drop table if exists class;
create table class (
 id bigint primary key auto_increment,
 name varchar(20)
);
-- 学⽣表
drop table if exists student;
create table student (
 id bigint primary key auto_increment,
 name varchar(20) not null, 
 sno varchar(10) not null,
 age int default 18,
 gender tinyint(1), 
 enroll_date date,
 class_id bigint
);

多对多关系

⼀个学⽣可以选修改多⻔课程，⼀⻔课程也可以被多名学⽣选修改，所以学⽣与课程之间是多对多关系

sql 复制代码

-- 学⽣表
drop table if exists student;
create table student (
 id bigint primary key auto_increment,
 name varchar(20) not null, 
 sno varchar(10) not null,
 age int default 18,
 gender tinyint(1), 
 enroll_date date,
 class_id bigint,
 foreign key (class_id) references class(id)
);
-- 课程表
drop table if exists course;
create table course (
 id bigint primary key auto_increment,
 name varchar(20)
);
-- 分数表
drop table if exists score;
create table score (
 id bigint primary key auto_increment,
 score float,
 student_id bigint,
 course_id bigint,
 foreign key (student_id) references student(id),
 foreign key (course_id) references course(id)
);

总结

设计数据库时的三大范式

第一范式，一行数据中每一列不可再分

关系型数据库必须要满足第一范式，设计表的时候，如果每一列都可以用 SQL 规定的数据类型描述，就天然满足第一范式
第二范式，在第一范式的基础上，消除了部分函数依赖

一个表中存在复合主键，当有一列只依赖复合主键中的某一个键，那就这种设计就不满足第二范式

不满足第二范式时会出现一些问题：数据冗余，更新异常，插入异常，删除异常

如果一个表中的键只有一列时，那么这种设计就天然满足第二范式
第三范式，在第二范式的基础上，消除了传递依赖

数据库的关系模型

一对一关系
一对多关系
多对多关系
没有关系

设计表的过程

通过需求找出实体
确定实体之间的关系
根据不同的关系按照固定的方法去创建表