什么是数据库
数据库是按照数据结构来组织，存储和管理数据的仓库，我们用关系型数据库（RDBMS）来存储和管理大数据量。
关系数据库是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。
- 数据库：一些关联表的集合；
- 数据表：表是数据的矩阵，一个数据库中的表像是一个表格。
- 冗余：存储两倍的数据，降低了性能，但提高了数据的安全性。
- 主键：唯一的，一个数据表只能包含一个主键。
- 外键：用于关联两个表
关系数据库设计理论
函数依赖
（1）函数依赖：
在一张表中，，在属性（或属性组）X的值确定的情况下，必定能确定属性Y的值，那么就可以说Y函数依赖于X，写作 X → Y。
例如在学生管理系统中，我们找不到一条学号相同而对应的姓名不同。所以我们可以说姓名函数依赖于学号，写作 学号 → 姓名。
（2）码与非主属性
设 K 为某表中的一个属性或属性组，若除 K 之外的所有属性都完全函数依赖于 K，那么我们称 K 为候选码，简称为码。一张表中可以有超过一个码。（实际应用中为了方便，通常选择其中的一个码作为主码）。
不包含在任何一个候选码中的属性称为非主属性。
（3）数据依赖的三个重要函数依赖:
1. 完全函数依赖
比如在学生课程(学号,课程号,成绩)关系中,"学号,课程号"是主码,只有学号不能确定成绩,只有课程号也不能确定成绩,因此"成绩"完全函数依赖与(学号,课程号)
2. 部分函数依赖
比如在学生课程(学号,课程号,学生姓名,成绩)关系中,"学号,课程号"是主码,只有学号是可以确定学生姓名的,因此存在部分依赖。
3. 传递函数依赖
在学生关系(学号,姓名,性别,所在系,系主任)中,学号可以确定所在系,所在系可以确定系主任,因此学号可以确定系主任,这就是传递函数依赖。
异常
以下的学生课程关系的函数依赖为 {Sno, Cname} -> {Sname, Sdept, Mname, Grade}，键码为 {Sno, Cname}。也就是说，确定学生和课程之后，就能确定其它信息。
| Sno | Sname | Sdept | Mname | Cname | Grade |
|---|---|---|---|---|---|
| 1 | 学生-1 | 学院-1 | 院长-1 | 课程-1 | 90 |
| 2 | 学生-2 | 学院-2 | 院长-2 | 课程-2 | 80 |
| 2 | 学生-2 | 学院-2 | 院长-2 | 课程-1 | 100 |
| 3 | 学生-3 | 学院-2 | 院长-2 | 课程-2 | 95 |
不符合范式的关系，会产生很多异常，主要有以下四种异常：
- 冗余数据：例如
学生-2出现了两次。 - 修改异常：想更新一条数据,结果工作量大,还容易出错。例如修改了一个记录中的信息，但是另一个记录中相同的信息却没有被修改。
- 删除异常：删除一个信息，那么也会丢失其它信息。例如删除了
课程-1需要删除第一行和第三行，那么学生-1的信息就会丢失。 - 插入异常：想要插入数据,结构因为表设计的问题,导致不能成功插入。例如想要插入一个学生的信息，如果这个学生还没选课，那么就无法插入。
范式
为了消除表中一些不必要的依赖关系,则就需要对关系模式进行规范化，对于不同的规范化程度呢,我们可用范式来衡量。同样，我们也可以理解为一张数据表的表结构所符合的某种设计标准级别。
数据库范式分为1NF，2NF，3NF，BCNF，4NF，5NF。一般在我们设计关系型数据库的时候，最多考虑到BCNF就够。符合高一级范式的设计，必定符合低一级范式，例如符合2NF的关系模式，必定符合1NF。
第一范式
符合1NF的关系中的每个属性都不可再分。下表所示的情况，就不符合1NF的要求。
1NF是所有关系型数据库的最基本要求，我们应设计为下图所示
若仅仅符合1NF的设计，则仍存在数据冗余过大，插入异常，删除异常，修改异常的问题，例如对于下表中的设计：
- 每一个学生的学号，姓名，系名，系主任这些数据重复多次。每个系与对应的系主任的数据也重复多次——数据冗余过大
- 假设学校新建了一个系，但是暂时还没有招收任何学生，那么是无法将系名与系主任的数据单独地添加到数据表中去的 ——插入异常
- 假如将某个系中所有学生相关的记录都删除，那么所有系与系主任的数据也就随之消失了（一个系所有学生都没有了，并不表示这个系就没有了）。——删除异常
- 假如李小明转系到法律系，那么为了保证数据库中数据的一致性，需要修改三条记录中系与系主任的数据。——修改异常。
第二范式
2NF在1NF的基础之上，消除了非主属性对于码的部分函数依赖。即：每个非主属性完全函数依赖于键码。
以上表为例，列出所有函数依赖关系：
-
对于（学号，课名） → 姓名，有 学号 → 姓名，存在非主属性 姓名 对码（学号，课名）的部分函数依赖。
-
对于（学号，课名） → 系名，有 学号 → 系名，存在非主属性 系名 对码（学号，课名）的部分函数依赖。
-
对于（学号，课名） → 系主任，有 学号 → 系主任，存在非主属性 对码（学号，课名）的部分函数依赖。
因此上表存在非主属性对于码的部分函数依赖，最高只符合1NF的要求。
为了让表3符合2NF的要求，我们必须消除这些部分函数依赖，只有一个办法，就是将大数据表拆分成两个或者更多个更小的数据表
下图为分解后的函数依赖关系和数据表：
现在看一下1NF存在的问题是否解决：
- 李小明转系到法律系
只需要修改一次李小明对应的系的值即可。——有改进 - 数据冗余是否减少了？
学生的姓名、系名与系主任，不再像之前一样重复那么多次了。——有改进 - 删除某个系中所有的学生记录
该系的信息仍然全部丢失。——无改进 - 插入一个尚无学生的新系的信息。
因为学生表的码是学号，不能为空，所以此操作不被允许。——无改进
出现问题的原因，在于仍然存在非主属性系主任对于码学号的传递函数依赖。
第三范式
3NF在2NF的基础之上，消除了非主属性对于码的传递函数依赖。
同样以上表为例，我们可以构建新的函数依赖关系和数据表
同样我们也改进了2NF存在的问题。
BCNF
以仓库管理系统为例：
- 某公司有若干个仓库；
- 每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；
- 一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。
已知函数依赖集：
- 仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量
- 码：（管理员，物品名），（仓库名，物品名）
- 主属性：仓库名、管理员、物品名
- 非主属性：数量
由上可得该关系模式为3NF。我们来看下以下几种：
- 先新增加一个仓库，但尚未存放任何物品，是否可以为该仓库指派管理员？——不可以，因为物品名也是主属性，根据实体完整性的要求，主属性不能为空。
- 某仓库被清空后，需要删除所有与这个仓库相关的物品存放记录，会带来什么问题？——仓库本身与管理员的信息也被随之删除了。
- 如果某仓库更换了管理员，会带来什么问题？——这个仓库有几条物品存放记录，就要修改多少次管理员信息。
由此可得 ：在某些特殊情况下，即使关系模式符合 3NF 的要求，仍然存在着插入异常，修改异常与删除异常的问题。
造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。
解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖：
- 仓库（仓库名，管理员）
- 库存（仓库名，物品名，数量）
参考博客