一，数据库设计范式（MySQL为例）

目前数据库设计中存在着五中设计范式：第一范式（1NF），第二范式（2NF），第三范式（3NF），巴斯.科德范式（BCNF），第四范式（4NF），第五范式（5NF）。数据库设计的最低要求是要满足第一范式，在此基础上再满足上一级范式。范式的级别越高，数据设计的就是越合理。通常数据库的设计满足第三范式就可以了。

第一范式

第一范式（1NF）是指在关系模型中，对域添加的一个规范要求，所有的域都应该是原子性的，即数据库表的每一列都是不可分割的原子数据项，而不能是集合，数组，记录等非原子数据项。即实体中的某个属性有多个值时，必须拆分为不同的属性。第一范式要求数据库中的表都是二维表。

USE sampledb;
CREATE TABLE student(
    学号 VARCHAR(64),
    学生姓名 VARCHAR(100),
    年龄 INT(64),
    性别 VARCHAR(20),
    地址 VARCHAR(100)
);

修改后满足第一范式

CREATE TABLE student_1NF(
    学号 VARCHAR(64),
    学生姓名 VARCHAR(100),
    年龄 INT(64),
    性别 VARCHAR(20),
    省 VARCHAR(20),
    市 VARCHAR(20),
    区 VARCHAR(20),
    详细地址 VARCHAR(50)
);

第二范式

第二范式（2NF）是在第一范式（1NF）的基础上建立起来的，即满足第二范式（2NF）必须先满足第一范式（1NF）。
第二范式（2NF）要求实体的属性完全依赖于主关键字。所谓完全依赖是指不能存在仅依赖主关键字一部分的属性，如果存在，那么这个属性和主关键字的这一部分应该分离出来形成一个新的实体，新实体与原实体之间是一对多的关系。为实现区分通常需要为表加上一个列，以存储各个实例的唯一标识。简而言之，第二范式就是在第一范式的基础上属性完全依赖于主键。
存在以下表，采用双主键（学号, 课程名称）

存在依赖(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)
问题分析
数据冗余：同一门课程由n个学生选修，”学分”就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。
更新异常：
1）若调整了某门课程的学分，数据表中所有行的”学分”值都要更新，否则会出现同一门课程学分不同的情况。
2）假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有”学号”关键字，课程名称和学分也无法记录入数据库。
删除异常 ：假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。
问题解决
把选课关系表SelectCourse改为如下三个表：
学生：Student（学号，姓名，年龄，性别，系别，系办地址、系办电话）；
课程：Course（课程名称,学分）；
选课关系：SelectCourse（学号，课程名称，成绩）。

第三范式（在2NF基础上消除传递依赖）

第三范式（3NF）是第二范式（2NF）的一个子集，即满足第三范式（3NF）必须满足第二范式（2NF）。第三范式（3NF）要求一个关系中不包含已在其它关系已包含的非主关键字信息。
接着看上面的学生表Student（学号，姓名，年龄，性别，系别，系办地址、系办电话），关键字为单一关键字”学号”，因为存在如下决定关系：
（学号）→ （姓名，年龄，性别，系别，系办地址、系办电话）
但是还存在下面的决定关系：
（学号） → (系别）→（系办地点，系办电话）
即存在非关键字段”系办地点”、”系办电话”对关键字段”学号”的传递函数依赖。
它也会存在数据冗余、更新异常、插入异常和删除异常的情况。
根据第三范式把学生关系表分为如下两个表就可以满足第三范式了：
学生：（学号，姓名，年龄，性别，系别）；
系别：（系别，系办地址、系办电话）。

BC范式

在第三范式的基础上，数据库表中如果不存在任何字段对任一候选关键字段的传递依赖则符合BC范式。也就是说如果是符合关键字，则复合关键字之间也不能存在函数依赖关系。

供应商	商品ID	供应商联系人	商品数量
饮料一厂	1	张三	10
饮料一厂	2	李四	20
饮料二厂	1	王五	10

存在下列关系因此不符合BCNF要求：
（供应商）–>（供应商联系人）
（供应商联系人）–>（供应商）
并且存在数据操作异常及数据冗余。
解决方式将一张表拆成两张表：

供应商	商品ID	商品数量
饮料一厂	1	10
饮料一厂	2	20
饮料二厂	1	10

供应商	供应商联系人
饮料一厂	张三
饮料一厂	李四
饮料二厂	王五