关系型数据库范式约束

猛然感觉自己范式方面的知识忘得差不多了，从网上找了一些资料，主要是结合一些(反面)实例，权当备份。

先写入自己的一些理解吧。关系数据库是建立在严谨的关系逻辑运算上的，1970年 E.F.Codd首先提出了完整的理论，因此获得1981年图灵奖。

对于高并发读写+海量数据高效存储+高扩展性和可用性的需求（源自SNS），ACID的基础特性制约了生产力的发展，所以

才有NOSQL（CAP、BASE理论）的火热。虽然范式致力于减少冗余，防止更新、删除、插入导致的数据不一致性（Inconsistency），但是可用性（Availability）和分容忍性（Partition Toleratce）的要求，不得不在一定程度上放弃一致性(Consistency)，获取可用性。

三选二的证明，中文翻译

回归正题，涉及到的一些诸如：码、主属性、完全函数依赖之类的概念不就熬述了。

1NF

所谓第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，即实体中的某个属性不能有多个值或者不能有重复的属性。

在任何一个关系数据库中，第一范式（1NF）是对关系模式的基本要求，不满足第一范式（1NF）的数据库就不是关系数据库。

e.g. 下表是不符合1NF的：

字段1	字段2	字段3		字段4
		字段3.1	字段3.2

2NF

第二范式（2NF）基于1NF，它要求数据库表中的每个实例或行必须可以被惟一地区分。引入主属性或主键、主码。

e.g. 选课关系表为SelectCourse(学号, 姓名, 年龄, 课程名称, 成绩, 学分)，关键字为组合关键字(学号, 课程名称)，因为存在如下决定关系：

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

这个数据库表不满足2NF，因为存在如下决定关系：

(课程名称) → (学分)

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

即存在组合关键字中的部分字段决定非关键字的情况，或者说非主属性部分函数依赖于主属性。

3NF

第三范式（3NF）基于2NF，它要求任何非主属性都不传递依赖于候选键。

e.g. 学生关系表为Student(学号, 姓名, 年龄, 所在学院, 学院地点, 学院电话)，关键字为单一关键字"学号"，因为存在如下决定关系：

(学号) → (姓名, 年龄, 所在学院, 学院地点, 学院电话)

这个数据库是符合2NF的，但是不符合3NF，因为存在如下决定关系：

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

即存在非关键字段"学院地点"、"学院电话"对关键字段"学号"的传递函数依赖。

BCNF

BCFC 基于3NF，它要求任何属性都不传递依赖于候选键。

注意：BCNF和3NF，加粗部分的区别！

e.g. 仓库管理关系表为StorehouseManage(仓库ID, 存储物品ID, 管理员ID, 数量)，

其中一个管理员只在一个仓库工作；一个仓库可以存储多种物品。这个数据库表中存在如下决定关系：

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

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

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

但是，由于存在如下决定关系：

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

即存在关键字段决定关键字段的情况，所以其不符合BCNF范式。

四种范式之间存在如下关系：

  

              

注：文章大部分内容来自这里

进一步的例子可以参考这里，貌似这个例子取自百度的一个面试题，还有个背景信息

“论坛每天访问量300W，帖子更新量10W”

下一步研究一下主从模式/读写分离；sharding/分区