范式

1nf,2nf,3nf,bcnf我觉得这些对数据库表的设计很有帮助的，可以减少删除，修改产生错误，以及减少数据的冗余。由于对这些不是很了解，所有查找网上资料并归纳总结。

1nf：第一范式，关系型数据库都要满足的要求。及可以找到主键

2nf：第二范式，在1nf基础上，满足非关键字完全依赖关键字，及部分依赖都不行！是不是有点懵比？看下网上的一个例子：

例子：(学号, 姓名, 年龄, 课程名称, 成绩, 学分)

候选键只有一个，就是(姓名，课程名称)，则主键就是(姓名，课程名称)

存在如下决定关系：

1：(学号, 课程名称) → (姓名, 年龄, 成绩, 学分)

2：(课程名称) → (学分)

3：(学号) → (姓名, 年龄)

其中，姓名、年龄、学分是部分依赖于主键的，而成绩是完全依赖于主键的，存在部分依赖关系，所以不满足第二范式。

原博客也介绍了一些概念：

(1) 数据冗余：

同一门课程由n个学生选修，"学分"就重复n-1次；同一个学生选修了m门课程，姓名和年龄就重复了m-1次。

(2) 更新异常：

若调整了某门课程的学分，数据表中所有行的"学分"值都要更新，否则会出现同一门课程学分不同的情况。

(3) 插入异常：

假设要开设一门新的课程，暂时还没有人选修。这样，由于还没有"学号"关键字，课程名称和学分也无法记录入数据 库。

(4) 删除异常：

假设一批学生已经完成课程的选修，这些选修记录就应该从数据库表中删除。但是，与此同 时，课程名称和学分信息也被删除了。很显然，这也会导致插入异常。

问题就在于存在非主属性对主键的部分依赖

3nf：第三范式，存在非关键字对其他非关键字有依赖关系。看下例子：

例子：表：(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)

该表中候选字段只有“学号”，于是“学号”做主键。由于主键是单一属性，所以不存在非主属性对主键的部分函数依赖的问题，所以必然满足第二范式。但是存在如下传递依赖

(学号) → (所在学院) → (学院地点, 学院电话)

学院地点和学院电话传递依赖于学号，而学院地点和学院电话都是非关键字段，即表中出现了“某一非关键字段可以确定出其它非关键字段”的情况，于是违反了第三范式。

bcnf：关键字中存在候选键，例子：

假设仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，且有一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：

(仓库ID, 存储物品ID) →(管理员ID, 数量)

(管理员ID, 存储物品ID) → (仓库ID, 数量)

所以，(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选关键字，表中的唯一非关键字段为数量，它是符合第三范式的。但是，由于存在如下决定关系：

(仓库ID) → (管理员ID)

(管理员ID) → (仓库ID)

仓库I是决定因素，但仓库ID不包含候选键(candidate key,也就是候选码，简称码)。

同样的，管理员ID也是决定因素，但不包含候选键。

所以该表不满足BCNF

满足第一范式后，如果不存在部分依赖，则是第二范式，再不存在传递依赖，则是第三范式