编辑

目录

什么是范式

第一范式（1NF）

第二范式（2NF）

第三范式（3NF）

BC范式（BCNF）

数据库的事务性

事务处理

事务ACID属性

Hello，小伙伴们大家好！我是灰小猿，一个超会写bug的程序猿！

在进行比较正规的项目开发的时候，通常会根据需求设计相应的数据库，而这些数据库则通常需要考虑数据库的冗余性和简洁性，数据库三大范式就是对关系数据库设计结构的一个规定。

什么是范式?

当一个关系中的所有分类都是不可再分的数据项时，该关系是规范化的。不可再分的数据项，即不存在组合数据项和多项数据项。一个低一级的关系模式，通过模式分解可以转换为若干高一级范式的关系模式的集合，这个过程就叫规范化。二维数据表可以分为5级范式为1NF、2NF、3NF、4NF、5NF。第一范式满足最低的要求条件，第五范式满足最高要求的条件。并且在数据库设计中我们要秉承以更高范式设计标准的原则设计和开发数据库。

那么接下来我和小伙伴们简单介绍一下数据库中常用的三大范式：

第一范式（1NF）

概念：数据库中所有元素都是不可再分的，确保元素的原子性

从概念上我们其实也很好理解，第一范式所说的就是每一列中的属性值都是不可再分的。打个比方如下表：

人数列中的属性是可以再次分割成男生和女生人数的，这就不满足了数据库设计的第一范式中的“每一列的属性值都是不可再分的”。

那么对于这样的设计，如何使非规范式设计转换为规则的第一范式呢？

其实很简单，只需要将可再分的子属性单独拿出成列即可。

如上表变成第一范式设计：

第二范式（2NF）

概念：在第一范式的基础上，所有非主属性都完全依赖于主码。

换句话说就是：在满足第一范式的前提下，确保每一个实例或者每一行都可以被唯一的标识，

但是值得注意的是：符合第二范式的关系模型可能还存在数据冗余、更新异常等问题。同时这也是第二范式所存在的一些缺陷和问题。

那么什么样的数据表才是属于满足第一范式而不满足第二范式的呢？

比如这个数据表：

如表所示：姓名由职工号唯一确定（职工号—>姓名）、职称由职工号唯一确定（职工号—>职称）、但是项目名由项目号唯一确定（项目号—>项目名），这样在该表中，项目名就不能由职工号唯一推出，这样就不满足了第二范式的“所有非主属性完全依赖于主码”

对于这样的数据表，想要将其转换成满足第二范式，需要将不能够被唯一标识出的属性单独成表，对于上表，就是将项目信息单独成表，员工信息单独成表。

第三范式（3NF）

概念：关系模型满足第二范式，所有非主属性对任何候选关键字都不存在传递依赖。

也可以说是：属性不依赖于其他非主属性，属性直接依赖于主键

即每个属性都跟主键有直接关系而不是间接关系，像：a-->b-->c。

例如下表所示结构：

如上表这样一个表结构，就存在上述关系。 学号--> 所在院校 --> (院校地址，院校电话)。我们应该拆开来，如下：

（学号，姓名，年龄，性别，所在院校）--（所在院校，院校地址，院校电话）

所以就满足了属性直接依赖于主键

BC范式（BCNF）

在概念上：BC范式又叫做修改后的第三范式，是在3NF的基础上消除主属性对于码的部分与传递函数依赖

为什么叫修改后的第三范式，由此就可以说明第三范式在某种情况下同样也是存在一定的缺陷的。那么到底存在怎样的缺陷并且如何修改呢？

我们以一个实际的数据表实例来说明：

对于一个仓库管理系统，现有若干个仓库， 每个仓库只能有一名管理员，一名管理员只能在一个仓库中工作；一个仓库中可以存放多种物品，一种物品也可以存放在不同的仓库中。每种物品在每个仓库中都有对应的数量。

那么关系模式 仓库（仓库名，管理员，物品名，数量） 属于哪一级范式？

我们来对它分析一下：

已知函数依赖集：仓库名 → 管理员，管理员 → 仓库名，（仓库名，物品名）→ 数量

码：（管理员，物品名），（仓库名，物品名）

主属性：仓库名、管理员、物品名

非主属性：数量

由于不存在非主属性对码的部分函数依赖和传递函数依赖。所以此关系模式属于3NF。

现在我们对上述数据表进行一些操作：

1、在一号仓添加一个新的物品“平板”，

那么我们需要输入的数据是（仓库名、管理员名、物品名、数量），这个时候大家会不会有一个发现，我在仓库中存放数据，我只需要知道把该物品放到了哪一个仓库就行了，为什么还要输入管理员名呢？这样是不是就显得有些麻烦了。

2、给二号仓换一个管理员“王五”，

这个时候我们要做的应该是将每一条二号仓的数据中的管理员名这个属性，都要修改成“王五”，这样是不是就很麻烦了。

造成此问题的原因：存在着主属性对于码的部分函数依赖与传递函数依赖。（在此例中就是存在主属性【仓库名】对于码【（管理员，物品名）】的部分函数依赖。

解决办法就是要在 3NF 的基础上消除主属性对于码的部分与传递函数依赖。

即将上表拆分成两个表，一个仓库物品表、一个仓库管理员表

仓库物品表

仓库管理员表

这样在对上述操作时，就很好的避免了问题的出现，这样的数据库设计规则就属于BC范式

数据库的事务性

除了数据库设计三大范式之外，事务处理也是保证数据完整性的重要手段。事务是单独的工作单元，该单元可以包含多个操作以完成一个完整的任务。锁是在多用户环境中对数据访问的限制。事务和锁确保了数据的完整性。

事务处理

提交commit，当所有的操作步骤都被完整执行后，称该事务被提交。

回滚rollback，由于某一操作步骤执行失败，导致所有步骤都没有被提交，则事务必须回滚，即回到事务执行前的状态。

事务ACID属性

事务处理的特性，每一个事务都有他们所共有的特性，叫做ACID特性，分别是原子性（atomicity），一致性（consistency）、隔离性（Isolation），持久性（Durability）。

原子性：事务的原子性表示事务执行过程中，把事务作为一个工作单元处理，一个工作单元可能包括若干个操作步骤，每个操作步骤都必须完成才算完成，若因任何原因导致其中的一个步骤操作失败，则所有步骤操作失败，前面的步骤必须回滚。

一致性：事务的一致性保证数据处于一致状态。如果事务开始时系统处于一致状态，则事务结束时系统也应处于一致状态，不管事务成功还是失败。

隔离性：事务的隔离性保证事务访问的任何数据不会受到其他事务所做的任何改变的影响，直到该事务完成。

持久性：事务的持久性保证加入事务执行成功，则它在系统中产生的结果应该是持久的。

好了，关于数据库设计的三大范式以及数据库的事务性的讲解就先和大家分享到这里，其中有不足和需要更正的地方还希望各位大佬指正。

觉得不错记得点赞关注哟！

灰小猿陪你一起进步！

编辑