1、范式简介

在关系型数据库中，关于数据表设计的基本原则、规则就称为范式。

1.1键和相关属性的概念

超键:能唯一标识元组的属性集叫做超键。
候选键:如果超键不包括多余的属性，那么这个超键就是候选键
主键:用户可以从候选键中选择一个作为主键。
外键:如果数据表 R1 中的某属性集不是 R1 的主键，而是另一个数据表 R2 的主键，那么这个属性集就是数据表 R1 的外键。
主属性:包含在任一候选键中的属性称为主属性。
非主属性:与主属性相对，指的是不包含在任何一个候选键中的属性。
举例说明：
球员表(player):球员编号|姓名|身份证号|年龄|球队编号
球队表(team):球队编号|主教练|球队所在地
超键: 对于球员表来说，超键就是包括球员编号或者身份证号的任意组合，比如(球员编号)(球员编号,姓名)(身份证号,年龄)等。
候选键:就是最小的超键，对于球员表来说，候选键就是(球员编号)或者(身份证号)。
主键:我们自己选定，也就是从候选键中选择一个，比如(球员编号)。
外键:球员表中的球队编号。
主属性、非主属性:在球员表中，主属性是(球员编号)(身份证号)，其他的属性(姓名)(年龄)(球队编号)都是非主属性。

1.2 第-范式(1st NF)

第一范式主要是确保数据表中每个字段的值必须具有 原子性，也就是说数据表中每个字段的值为 不可再次拆分 的最小数据单元。
举例1:*假设一家公司要存储员工的姓名和联系方式。它创建一个如下表:

1.3 第二范式(2nd NF)

第二范式要求，在满足第一范式的基础上，还要满足数据表里的每一条数据记录，都是可唯一标识的。而且所有非主键字段，都必须完全依赖主键，不能只依赖主键的一部分。
举例1:
成绩表(学号，课程号，成绩)关系中，(学号，课程号)可以决定成绩，但是学号不能决定成绩，课程号也不能决定成绩，所以“(学号，课程号)一成绩”就是 完全依赖关系。
举例2、
比赛表 player_game ，里面包含球员编号、姓名、年龄、比赛编号、比赛时间和比赛场地等属性，这里候选键和主键都为(球员编号，比赛编号)，我们可以通过候选键(或主键)来决定如下的关系:
(球员编号，比赛编号)一(姓名，年龄，比赛时间，比赛场地，得分)
但是这个数据表不满足第二范式，因为数据表中的字段之间还存在着如下的对应关系
(球员编号)→(姓名，年龄)
(比赛编号)→(比赛时间，比赛场地)

1.3、第三范式(3rd NF)

要求数据表中的所有非主键字段不能依赖于其他非主键字段，只能有一个依赖。
举例1:
部门信息表:每个部门有部门编号(dept_id)、部门名称、部门简介等信息。
员工信息表:每个员工有员工编号、姓名、部门编号。列出部门编号后就不能再将部门名称、部门简介等与部门有关的信息再加入员工信息表中。
如果不存在部门信息表，则根据第三范式(3NF)也应该构建它，否则就会有大量的数据冗余。如果列出部门名称，部门名称既可以依赖部门编号又可以依赖员工编号。

1.4.反范式化

有的时候不能简单按照规范要求设计数据表，因为有的数据看似冗余，其实对业务来说十分重要。这个时候，我们就要遵循 业务优先 的原则，首先满足业务需求，再尽量减少冗余。
1、增加冗余字段的建议
①这个冗字段 不需要经常进行修改;
②这个几余字段 查询的时候不可或缺
2、历史快照、历史数据的需要
①在现实生活中，我们经常需要一些冗余信息，比如订单中的收货人信息，包括姓名、电话和地址等。每次发生的订单收货信息，都属于历史快照。
②反范式优化也常用在 数据仓库 的设计中，因为数据仓库通常 存储历史数据

1.5 BCNF(巴斯范式）

它在 3NF 的基础上消除了主属性对候选键的部分依赖或者传递依赖关系。

数量依赖（仓库名、物品名）、 管理员依赖（仓库名）部分依赖

2、ER模型

设计概念模型、物理模型用Powerdesigner专业工具很有必要，以前没有把工具发挥最大用处。