1.3] Third Normal Form(3NF)
3NF 要求所有的属性都直接依赖于 primary key。3NF 和 2NF 最大的不同之处是，2NF 有依赖传递性,而 3NF 不准许。
例如,有一个符合 2NF 的表：
错误方式：
+———————+———–+—————-+———–+———-+——————
..some属性s | 用户号 | 用户发表文章数 | 用户登录数| 用户积分 | other 列 …
+———————+———–+—————-+———–+—————————–
…… | ID_001 | 4 | 20 | 13 | ……
+———————+———–+—————-+———–+———-+——————
用户积分规则：用户发表文章数 x 2 + 用户登录数 /4
在 3NF 中是不符合的。因为‘用户积分’是通过‘用户发表文章数’和‘用户登录数’，用公式计算得来的。也就是说，‘用户积分’依赖于‘用户发表文章数’和‘用户登录数’。
3NF 符合的划分方式是：
正确方式：
+———————+———–+—————-+———–+——————-
..some属性s | 用户号 | 用户发表文章数 | 用户登录数| other 列 …
+———————+———–+—————-+———–+——————-
…… | ID_001 | 4 | 20 | ……
+———————+———–+—————-+———–+——————-
正确方式：
+———————+———–+———–+——————–
..some属性s | 用户号 | 用户积分 | other 列 …
+———————+———–+———–+——————–
…… | ID_001 | 13 | ……
+———————+———–+———–+——————–
用户积分规则不变
需要注意的是，虽然 3NF 更加清楚地将用户资料和用户积分这两个关系表示了出来。但是在需要联合查询用户资料和积分的情况下，在大多数 RDBMS 如 MySQL 中，会造成性能消耗严重的情况。进一步讨论在 1.4 中进行。
1.3.1] Joining 关系
关系之间相互关联的方式有两种：INNER JOIN 和 OUTER JOIN
INNER JOIN 查询会返回两个关系完全匹配的情况，MYSQL 默认的匹配方式为 INNER JOIN 。
如果你希望查询的结果即使没有匹配也会被查询出来，那么就要使用 OUTER JOIN 的连接方式。OUTER JOIN 又细分为三种：LEFT OUTER JOIN, RIGHT OUTER JOIN 和 FULL OUTER JOIN 。
LEFT OUTER JOIN 是将左边的查询关系作为主关系，如果右面的关系有相匹配的 tuple , 那么处理方式和 INNER JOIN 一样；如果右面的关系没有与左边的关系相匹配，那么属性就会列出一个 NULL 的值。
RIGHT OUTER JOIN 的处理方式与 LEFT OUTER JOIN 类似，只不过是以右面的关系为主 关系。
FULL OUTER JOIN 与 INNER JOIN 的显示结果相同。
1.3.2] BCNF
修正的第三范式(BCNF) 全称 Boyce-Codd normal form 。是 3NF 的一个拓展，所以 BCNF 的前提和 3NF 是一样的：关系 必须符合 2NF ，并且有 KEY 可以用来相互关联。并不是所有符合 2NF 的关系都可以划分为 BCNF。
BCNF 简单来说，就是所有的 tuple 都依赖于 candidate key 或者这个 tuple 是 superkey 。因此所有的 tuple 都依赖于 key，从而避免了传递依赖问题。
1.4] NF 设计与性能消耗
NF 理论在设计之初，主要是为了应付数据冗余与存储重复而出的。当越来越庞大的数据库应用出现时，高度设计的 NF 带来的好处与性能所带来的坏处相互抵消了。因为通常，越高层次的 NF 会划分越多的 关系，从而查询出所需要的数据就需要更多的 join 操作。虽然 view 在一定程度上可以解决这个问题，但是视图本身也是一个不小的性能消耗。
如果一个 MySQL 执行的多是 SQL-Transaction 的话，那么使用高层次的 NF 设计就显得尤为必要，因为书写 transaction 的 SQL 语言通常都不适于做复杂的过程处理，而高层次的 NF 设计可以在逻辑上更清楚的划分关系，从而较少的操作关系之间的关系处理，较多的操作关系之间的数据。
而如果一个 MySQL 在应用中 ，更多的是扮演数据存储与统计的操作，那么高层次的 NF 设计就没有必要。因为此类应用中，通常都搭配使用高级编程语言，而高级编程语言灵活多样，在逻辑、过程与数据的处理过程中，都要比 SQL 更加的强壮。
1.5] NF 与 SQL 的关系
SQL 语言是为了结构化的查询数据而发明的一种机器查询语言。主要的功能是查询，兼顾数据定义与控制的功能。
SQL 大致可以分为三类：
1.5.1] Data Manipulation Language (DML)
DML 主要用来 查/删/改/插关系的 tuple 。他们共同的特点是都需要指定作用的关系和关系之间的关系。
1.5.1.1] Select
Select 用来查询关系中的 tuple 包括:
Select : 后面跟属性,作用是控制查询的输出。
From : 后面跟关系与 joins ,作用是控制与关联关系之间的关系。
Where : 后面跟属性的限制语句，主要是用来划分查询的区域。
Group By : 后面跟属性,主要用来将相似的属性分成单一的结果集。
Having : 与 Where 作用相同，作用域为 Group By 控制的结果集。
Order By: 用来将最后筛选出来的结果集，通过某一 tuple 来进行排序。
具体作用详见：1.2.1]
1.5.1.2] Insert
Insert 用来插入 tuple。具体作用详见：1.2.2]
1.5.1.3] Update
Update 用来更新 tuple 。具体作用详见：1.2.3]
1.5.1.4] Delete
Delete 用来删除 tuple 。作用域与 Select 类似，但是不返回查询的 tuple。
1.5.2] Data Definition Language (DDL)
DDL 的作用是创建关系与定义关系中的属性。主要包括三大部分：
1.5.2.1] CREATE
创建语句,可以用来创建 Database、关系、transaction(祥见 1.2.4) 等。根据需要创建的类型不同，语句稍有差别。
1.5.2.2] DROP
删除语句，与 CREATE 语句相反。
1.5.2.3] ALTER
修改关系和 Transaction 。
1.5.3] Data Control Language (DCL)
DCL 的作用是用来控制关系和属性的权限。主要有两部分：
1.5.3.1] GRANT
用来创建访问关系与属性的权限
1.5.3.2] REVOKE
用来删除访问关系与属性的权限
原文作者：韩述 杜工稍作修改。
