mysql 数据库设计-数据库设计三大范式

在设计关系数据库的时候，一般来说我们都是需要遵从不同的规范要求来设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

范式分为：三大范式，以及BC范式，第四范式还有第五范式，一共六大范式；通常来说满足与三大范式就基本足够。

注意：项目的数据库设计并不一定要完全满足于三大范式，有些时候我们会适量的冗余让 Query 尽量减少 Join 。

误区：不是范式越高就越好    好=>结构清晰

早期：希望数据可以足够的小，数据量不是问题主要分问题。

现在：希望查询速度越快越好，同时操作越简单越好。

一、第一范式（1NF）

简单的说，第一范式要求关系中的属性必须是原子性，即不可再分的基本类型，集合、数组和结构不能作为某一属性出现，严禁关系中出现 “表中有表” 的情况在任何一个关系数据库系统中，第一范式是关系模式的一个最起码的要求。不满足第一范式的数据库模式不能称为关系数据库。

原始表中，其中 “工程地址” 列还可以细分为省份，城市等。在国外，更多的程序把 “姓名” 列也分为 2 列，即 “姓” 和 “名”。

虽然第一范式要求各列要保存原子性，不能再分，但是这种要求和我们的需求是相关联的，如下表中我们对 “工程地址” 没有省份，城市这样方面的查询和应用需求，则不需要拆分，“姓名” 列也是同样如此。

原始表：

工程号	工程名称	工程地址	员工编号	员工名称	薪资待遇	职务
P001	港珠澳大桥	广东海珠	E0001	Jack	6000/月	工人
P001	港珠澳大桥	广东海珠	E0002	Join	7800/月	工人
P001	港珠澳大桥	广东海珠	E0003	Apple	8000/月	高级技工
P002	南海航天	海南三亚	E0001	Jack	6000/月	工人

二、第二范式（2NF）

第二范式（2NF）是在第一范式（1NF）的基础建立起来的，既满足第二范式（2NF）就必须要满足第一范式（1NF）。第二范式（2NF）要求实体的属性完全依赖于主键字。

第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成应该新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。

例如：原始表中描述了工程信息，员工信息等。这样就造成了大量数据的重复。按照第二范式，我们可以将原始表分为工程表与员工信息表

工程信息表：

工程编号	工程名称	工程地址
P001	港珠澳大桥	广东珠海
P002	南海航天	南海三亚

员工信息表：

员工编号	员工姓名	职务	薪资水平
E001	Jack	工人	6000/月
E002	Join	工人	7800/月
E003	Apple	高级技工	8000/月

三、第三范式（3NF）

第三范式（3NF）是第二范式的子集，既满足第三范式就必须满足第二范式。意思是不存在非关键字段对任意候选关键字段的传递函数依赖。

例如：现在我们来看看在第二范式的讲解中，我们将表 1-1 拆分成了两张表。这两个表是否符合第三范式呢。在员工信息表中包含：“员工编号”、“员工名称”、“职务”、“薪资水平”，而我们知道，薪资水平是由职务决定，这里 “薪资水平” 通过 “职务” 与员工相关，则不符合第三范式。我们需要将员工信息表进一步拆分；如下：

员工信息表：

员工编号	员工姓名	职务编号
E0001	Jack	1
E002	Join	1
E003	Apple	2

工程信息表：

工程编号	工程名称	工程地址
P001	港珠澳大桥	广东海珠
P002	南海航天	海南三亚

职务表：

职务编号	职工名称	工资待遇
1	工人	6000/月
2	高级技工	8000/月

工程参与人员记录表：

编号	工程编号	人员编号
1	P001	E0001
2	P001	E0002
3	P002	E0003

通过对比我们发现，表多了，关系复杂了，查询数据变得麻烦了，编程中的难度也提高了，但是各个表中内容更清晰了，重复的数据少了，更新和维护变得更容易了。