数据库模型设计，第一范式、第二范式、第三范式_t13外部数据主题

一、第一范式

1NF是对属性的原子性，要求属性具有原子性，不可再分解；

表：字段1、 字段2(字段2.1、字段2.2)、字段3 ......

如学生（学号，姓名，性别，出生年月日），如果认为最后一列还可以再分成（出生年，出生月，出生日），它就不是一范式了，否则就是；

二、第二范式

2NF是对记录的唯一性，要求记录有唯一标识，即实体的唯一性，即不存在部分依赖；

表：学号、课程号、姓名、学分;

这个表明显说明了两个事务:学生信息, 课程信息;由于非主键字段必须依赖主键，这里学分依赖课程号，姓名依赖与学号，所以不符合二范式。

可能会存在问题：

• 数据冗余:，每条记录都含有相同信息；
• 删除异常：删除所有学生成绩，就把课程信息全删除了；
• 插入异常：学生未选课，无法记录进数据库；
• 更新异常：调整课程学分，所有行都调整。

正确做法:
学生：Student(学号, 姓名)；
课程：Course(课程号, 学分)；
选课关系：StudentCourse(学号, 课程号, 成绩)。

三、第三范式

3NF是对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖；

表: 学号, 姓名, 年龄, 学院名称, 学院电话

因为存在依赖传递: (学号) → (学生)→(所在学院) → (学院电话) 。

可能会存在问题：

• 数据冗余:有重复值；
• 更新异常：有重复的冗余信息，修改时需要同时修改多条记录，否则会出现数据不一致的情况 。

正确做法：

学生：(学号, 姓名, 年龄, 所在学院)；

学院：(学院, 电话)。

区别

一、含义不同：

第二范式（2NF）：关系模式R属于第一范式，且每个非主属性都完全函数依赖于键码。

第三范式（3NF）：关系模式R属于第一范式，且每个非主属性都不伟递领带于键码。

二、内容不同：

第二范式（2NF）：首先是 1NF，另外包含两部分内容，一是表必须有一个主键；二是没有包含在主键中的列必须完全依赖于主键，而不能只依赖于主键的一部分。

第三范式（3NF）：首先是 2NF，另外非主键列必须直接依赖于主键，不能存在传递依赖。即不能存在：非主键列 A 依赖于非主键列 B，非主键列 B 依赖于主键的情况。

四、反范式化

一般说来，数据库只需满足第三范式（3NF）就行了。

没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余，达到以空间换时间的目的。

〖例〗：如订单表，“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。

在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。

一、范式

范式的英文名称是Normal Form，它是英国人E.F.Codd（关系数据库的老祖宗）在上个世纪70年代提出关系数据库模型后总结出来的。范式是关系数据库理论的基础，也是我们在设计数据库结构过程中所要遵循的规则和指导方法。目前有迹可寻的共有8种范式，依次是：1NF，2NF，3NF，BCNF，4NF，5NF，DKNF，6NF。通常所用到的只是前三个范式，即：第一范式（1NF），第二范式（2NF），第三范式（3NF）。

第一范式（1NF）

第一范式其实是关系型数据库的基础，即任何关系型数据库都是符合第一范式的。简单的将第一范式就是每一行的各个数据都是不可分割的，同一列中不能有多个值，如果出现重复的属性就需要定义一个新的尸实体。
下面数据库便不符合第一范式：

1 2 3 4 5 6

+------------+-------------------+ | workername | company      | +------------+-------------------+ | John    | ByteDance,Tencent | | Mike    | Tencent      | +------------+-------------------+

上面描述的数据所表达的意思是，Mike在Tencent工作，而John同时在ByteDance和Tencent工作（假设这是可能的）。但是这种表达方式并不符合第一范式，即列的数据必须是不可分的，要满足第一范式，必须是下面的这种形式：

1 2 3 4 5 6 7

+------------+-----------+ | workername | company  | +------------+-----------+ | Mike    | Tencent  | | John    | ByteDance | | John    | Tencent  | +------------+-----------+

第二范式（2NF）

首先，一个数据库要满足第二范式必须要先满足第一范式。
我们先看一个表格：

1 2 3 4 5 6 7 8

+----------+-------------+-------+ | employee | department | head | +----------+-------------+-------+ | Jones  | Accountint | Jones | | Smith  | Engineering | Smith | | Brown  | Accounting | Jones | | Green  | Engineering | Smith | +----------+-------------+-------+

这个表描述了被雇佣者，工作部门和领导的关系。这个表所表示的关系在现实生活中是完全可能存在的，现在让我们考虑一个问题，如果Brown接任Accounting部门的领导，我们需要怎样对表进行修改？这个问题将会变得非常麻烦，因为我们会发现数据都耦合在一起了，你很难找到一个很好的能唯一确定每一行的判断条件来执行你的UPDATE语句。而我们把能够唯一表示数据库中表的一行的数据成为这个表的主键。 因此，没有主键的表是不符合第二范式的，也就是说符合第二范式的表需要规定主键。

因此我们为了使上面的表符合第二范式，需要将它拆分为两个表：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

+----------+-------------+ | employee | department | +----------+-------------+ | Brown  | Accounting | | Green  | Engineering | | Jones  | Accounting | | Smith  | Engineering | +----------+-------------+ +-------------+-------+ | department | head | +-------------+-------+ | Accounting | Jones | | Engineering | Smith | +-------------+-------+

在这两个表中，第一个表的主键为employee，第二个表的主键为department。在这种情况下，完成上面的问题就显得非常简单了。

第三范式（3NF）

一个关系型数据库要满足第三范式必须要先满足第二范式。
将第三范式前，我们同样先看两个表：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

+-----------+-------------+---------+-------+ | studentid | studentname | subject | score | +-----------+-------------+---------+-------+ | 1     | Mike    | Math  | 96  | | 2     | John    | Chinese | 85  | | 3     | Kate    | History | 100  | +-----------+-------------+---------+-------+ +-----------+-----------+-------+ | subjectid | studentid | score | +-----------+-----------+-------+ | 101    | 1     | 96  | | 111    | 3     | 100  | | 201    | 2     | 85  | +-----------+-----------+-------+

上面的两个表格的主键分别为studentid和subjectid，很显然两个表都符合第二范式。

但是我们会发现这两个表有重复冗余的数据score。因此第三范式就是要消除冗余的数据，具体到上面的情况，就是两个表只有一个能够存在score这一列数据。那么怎么将这两个表联系起来呢，这里就出现了外键。如果两个表中有冗余重复的列，而且这个表中的一个非主键列在另一个表中是主键，那么我们为了消除冗余列可以把这个非主键列作为联系两个表的桥梁，也就是外键。 通过观察可以发现，studentid在第一个表中是主键，在第二个表中是非主键，所以他就是第二个表的外键。因此上述情况我们有了以下符合第三范式的写法：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

+-----------+-------------+---------+ | studentid | studentname | subject | +-----------+-------------+---------+ | 1     | Mike    | Math  | | 2     | John    | Chinese | | 3     | Kate    | History | +-----------+-------------+---------+ +-----------+-----------+-------+ | subjectid | studentid | score | +-----------+-----------+-------+ | 101    | 1     | 96  | | 111    | 3     | 100  | | 201    | 2     | 85  | +-----------+-----------+-------+

可以发现在设定了外键之后，第一个表即使删除了score列，也可以通过studentid在第二个表中查找到相应的score的值，这样即消除了数据的冗余，又不会影响查找，满足第三范式。

二、范式的优点和缺点

范式的优点

• 范式化的更新操作通常要比反范式化要快。
• 当数据较好地范式化时，就只有很少或者没有重复的数据，所以只需要修改更少的数据。
• 范式化的表通常都比较小，可以更好的放在内存中，所以执行操作会更快。
• 很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句。

范式的缺点

• 范式化的缺点就是通常需要关联。稍微复杂一些的查询语句在符合范式的数据库上都可能需要至少一次关联，也许更多，这不但代价昂贵，也可能使一些索引策略无效。