MySQL数据库设计原则

news2024/11/14 13:45:58

0.简单的处理逻辑

一.MySQL完整性约束

主键约束

primary key

自增键约束

auto_increment

唯一键约束

unique

非空约束

not null

默认值约束

default

外键约束

foreign key

下面是一个sql语句创建一个表,可以看出来了使用了哪几个约束吗?

create table user(
id int primary key auto_increment comment '主键',
nickname varchar(20) not null comment '昵称',
age int unsigned not null default 18 comment '年龄',
sex enum('男','女') default '男' comment '性别'
);

二.关系型数据库表设计

一对一
比如用户表和用户信息表,一个用户只能对应一个用户信息
一对多
电商系统中,用户,商品和订单表,其中用户和订单是一对多的关系,一个用户可以有多个订单,但一个订单只能属于一个用户
多对多
还是电商系统,一个商品可以存在多个订单中,同时一个订单中可以有多个商品,因此他们之间存在多对多的关系

对于一对多的关系,设计数据库的时候,只需要在子表中增加一列(父表的主键)用来关联主表

那么对于一对多的关系该如何处理呢?

首先我们还是先来考虑增加主键来关联主表,这样我们就会发现会有很多冗余的数据存储.

因此对于多对多的关系,需要在父表和子表之间增加一个中间表用来存储关系

可以将表改为下面的模式(商品表主键(pid),订单表主键(orderid),订单内容表主键(orderid,pid))

三.关系型数据库范式

应用数据库范式可以带来许多好处，但是最重要的好处归结为三点：

减少数据冗余（这是最主要的好处，其他好处都是由此而附带的）
消除异常（插入异常，更新异常，删除异常）
让数据组织的更加和谐

但是数据库范式绝对不是越高越好，范式越高，意味着表越多，多表联合查询的机率就越大， SQL的效率就变低。

1.第一范式

每一列保持原子特性

列都是基本数据项，不能够再进行分割，否则设计成一对多的实体关系。例如表中的地址字段，可以再细分为省，市，区等不可再分割（即原子特性）的字段，如下：

上图的表就是把地址字段分成更详细的 city ， country ， street 三个字段，注意，不符合第一范式不能称作关系型数据库。

2.第二范式

属性完全依赖于主键 - 主要针对联合主键

非主属性完全依赖于主关键字，如果不是完全依赖主键，应该拆分成新的实体，设计成一对多的实体关系。

例如：选课关系表为 SelectCourse( 学号 , 姓名 , 年龄 , 课程名称 , 成绩 , 学分 ) ，（学号，课程名称）是联合主键，但是学分字段只和课程名称有关，和学号无关，相当于只依赖联合主键的其中一个字段，不符合第二范式。

3.第三范式

属性不依赖于其它非主属性

要求一个数据库表中不包含已在其它表中已包含的非主关键字信息。示例：学生关系表为 Student （学号，姓名，年龄，所在学院，学院地点，学院电话），学号是主键，但是学院电话只依赖于所在学院，并不依赖于主键学号，因此该设计不符合第三范式，应该把学院专门设计成一张表，学生表和学院表，两个是一对多的关系。

4.BC范式（BCNF）

每个表中只有一个候选键

简单的说， BC 范式是在第三范式的基础上的一种特殊情况，即每个表中只有一个 候选键（在一个数据库 中每行的值都不相同，则可称为候选键） ，在上面第三范式的 noNF 表（上面图 3 ）中可以看出，每一个员工的email 都是唯一的（不可能两个人用同一个 email ），则此表不符合 BC 范式，对其进行 BC 范式化后的关系图为:

5.第四范式

消除表中的多值依赖

简单来说，第四范式就是要消除表中的多值依赖，也就是说可以减少维护数据一致性的工作。比如图 4 中的noNF 表中的 skill 技能这个字段，有的人是 “java ， mysql” ，有的人描述的是 “Java ， MySQL” ，这样数据就不一致了，解决办法就是将多值属性放入一个新表，所以满足第四范式的关系图如下：