数据库和表的设计

一、数据完整性
作用： 保证用户输入的数据保存到数据库中是正确的

设置数据完整性： 在创建表时给表中添加约束

数据完整性分类：

实体完整性
域完整性
引用/参照完整性
二、实体完整性
1、实体完整性
实体： 表中的一行(一条记录)代表一个实体（entity）

作用： 标识每一行数据不重复，行级约束

2、主键约束（primary key）
特点：

每个表中要有一个主键
数据唯一，且不能为null

3、唯一约束(unique)
特点：

指定列的数据不能重复
可以为null
特点：

指定列的数据自动增长
数据删除，序号不会删除，还是从删除的序号继续往下

三、域完整性
1、域完整性
域代表当前单元格
限制此单元格的数据正确，不对照此列的其它单元格比较

2、域完整性约束
数据类型约束 ： 数值类型、日期类型、字符串类型

非空约束（not null）
默认值约束(default)
四、参照完整性
1、参照完整性
是指表与表之间的一种对应关系
通常情况下可以通过设置两表之间的主键、外键关系，或者编写两表的触发器来实现
有对应参照完整性的两张表格，在对他们进行数据插入、更新、删除的过程中，系统都会将被修改表格与另一张对应表格进行对照，从而阻止一些不正确的数据的操作

2、主键和外键
数据库的主键和外键类型一定要一致
两个表必须得要是InnoDB类型
设置参照完整性后 ，外键当中的内值，必须得是主键当中的内容
一个表设置当中的字段设置为主键，设置主键的为主表
主键：PRIMARY KEY，外键：REFERENCES

数据库规范化过程

关系数据库的规范化说的通俗一些就是对表的规范化。

规范化的必要性：

根据项目的需求，我们会创建相应的数据库表格来完成项目中的数据的存储。这已经成为做项目的固定流程了，但是在真正的开始处理业务需求的时候，就会意识到自己的表格设置的不合理，导致数据的重复存储，插入异常，删除异常，更新异常等问题，这时就需要来重新的规划表格，既浪费时间，又消耗人力财力，十分不划算，因此规范化是十分有必要的，所以今天就在这里教给大家规范表的方法。

在教规范化数据库方法之前，先给大家介绍知识:

关键知识点函数依赖

函数依赖的定义：

设R(U)是属性集上的一个子集，X和Y是U的子集，若对于R(U)上的任意一个可能的关系r,如果r中不可能存在两个元组，它们在X上的属性值相等，而在Y上的属性值不相等，则称X函数决定于Y或Y函数依赖与X,记作X->Y。

定义可能有些难以理解，我在这里简单的解释一下：函数依赖描述的是两个集合之间的一种映射关系，这种映射关系与函数是一样的，例如 y = x^2，在这里对于x来说，一个x就对应一个y值，但是不存在，一个x对应多种y值的情况，所以就可以说y函数依赖于x,然而对于y来说，存在一个y值对应多个x值的情况，所以说x并不函数依赖于y。这就是函数依赖。

接下来我们介绍几种特殊的函数依赖：

完全函数依赖

定义：

如果X->Y，并且对于任意一个X的真子集X’都不存在,X’->Y，那么我们就说 X->Y这种函数依赖属于完全函数依赖。

简单的解释一下： 函数z = x + y，对于z来说：z函数依赖于x和y，但是z并不单独依赖于x或单独依赖于y，这就说明z函数依赖于x和y的这种依赖就是完全函数依赖。

部分函数依赖：

定义：

如果X->Y，但是Y不完全依赖于X，则称这种依赖为部分完全依赖。 也就是说：函数z = x + 0y 是可以看成 ,也就是说z函数依赖于x和y，但是z又单独依赖于x，那么这就是部分函数依赖。

传递函数依赖：

定义：

如果X->Y, Y -> Z ,并且不成立，Y->X也不成立。则称Z传递函数依赖于X。

这个比较简单，函数组z = x^2, x = 2y可以化简为z = 4y ^2，很容易看出：z是函数依赖于x，x依赖于y，并且z->x不成立，这就是传递函数依赖。

关键知识点之二-----键

候选键：一个属性（字段）或一个属性组（多个字段）能够完全决定于关系模式（表）中的其他属性（字段）。也就是说其他属性（字段）完全依赖于该属性（字段）或属性组（多个字段）。

主键：如果候选键多于一个，则选择其中一个作为主键。被选做主键的属性或属性组在该关系模式（表）中的每一个元祖（行）中的值是不允许重复和取值为null的。

主属性：报完在任何一个候选键中的属性，称为主属性。如果候选键是由多个属性共同组成的，那么这些属性组中每一个属性都是主属性。

非主属性：不包含在任何键中的属性称为非主属性。

外键：某属性或属性组在当前关系模式（表）中不是主键，但是另一个关系模式（表）中充当主键的身份，则称该属性或属性组为外键。

在介绍完了上述的基本知识点之后，我们来开始学习数据库表的规范过程：

想要规范表，就首先需要一个标准，来衡量表是否已经规范。这个标准就是----范式。

范式一共有六种：第一范式（1NF），第二范式(2NF)，第三范式(3NF)，BC范式(BCNF)，第四范式(4NF)，第五范式(5NF)。

在上面六中范式中，在一般的情况下我们需要将表规范到BCNF就已经十分完美了，在真正的项目中其实只需要达到3NF就足够了。

接下来重点介绍前4中范式：

第一范式：关系模式R中的所有属性都是不可分的数据项。

简单来说就是只要你能把表建出来，这个表就已经满足了第一范式了。例如student表（student_id, course_id, student_name, age, sex, grade, sdept, sdept_director），在这个表中很明显grade这一项是受student_id, course_id,共同决定的，所以应该让这两项联合做为主键。

第二范式：在满足第一范式的基础上，满足非主属性都完全依赖于R的主键。

这就需要用到前面讲的内容了，要判断非主属性是否完全依赖于主键。如果不满足就重 更改表的结构。例如student表（student_id, course_id, student_name, age, sex, grade, sdept_id, sdept_director)因为student_id, course_id两项联合做为主键，但是对于其他的字段name, age, sex这些 属性来说，它们是完全依 赖于student_id这一属性的，所以它们对于student_id, course_id共同作为主键是部分 依赖的。这就不满足第二范式的定义了，所以应该把 grade拿出来，将这一个大表拆成 两份小表:student(student_id, name, age, sex, sdept_id, sdept_director)， student_score(student_id, course_id, grade);

第三范式：在满足第二范式的情况下去除传递依赖。

例如：student表（student_id, student_name, age, sex, sdept, sdept_director）,很明显每一个专业决定一个专业主任,所以sdept_director传递依赖于student_id，所以应该再拆分一个表student（student_id, student_name, age, sex）和sdept(sdept_id, sdept_name, sdept_director),这样就满足了第三范式。

BC范式：在满足第三范式的情况下，再满足一下三点：

1、所有的主属性完全依赖于其他不包含自己的候选键；
2、所有的非主属性完全依赖于每一个候选键；
3、没有任何属性完全函数依赖于任何一组非主属性。