1.4.3数据库的关系规范化在线视频

大家好

欢迎来到数据库技术应用在线开放课程

前面我们已经将银行自动存取款机

数据库的概念模型和数据模型都设计好了

今天的任务

是对数据库BankDB的关系进行规范化

之前我们设计好的关系模式是

用户银行卡交易信息三个关系模式

那怎么进行规范化呢

需要用到三个范式

一范式、二范式和三范式

这三个范式之间的关系

大家可以看一下这张图

从一范式是到二范式消除了部分依赖

从二范式是到三范式消除了传递以来

那说了半天这个范式

实际上它就是一种规则

我们按照这个规则

对我们的关系模式进行检查

看它是否满足规则的要求

所以本节课的目标

就是理解数据库关系规范化的意义

让大家掌握关系规范化的方法

我们来看一个例子

假设某建筑公司要设计一个数据库

公司的业务规则概括如下

公司承担多个工程项目

每一项工程都有工程号、工程名称

施工人员等

公司有多名职工

每一名职工都有职工号、

姓名、性别、职务等

职务包括工程师、技术员、

公司按照工时和小时工资率支付工资

小时工资率由职工的职务决定

例如职务员的小时工资率和工程师不同

公司制定了这样一个工资报表

大家可以看一下

根据这个工资报表

我们来写关系模式

那么大多数同学写到的都是工程

括号工程号、工程名称、职工号、

姓名、职务和小时工资率

其中小时工资率是由职务决定的

那现在要求我们对大多数同学

写好的这个关系模式进行优化

这个关系模式看起来很简单

就一个表就解决了

但是实际上它里面暗藏了很多危机

所以我们需要根据规范化的方式

进行工程的规范化设计

那首先我们来看一下一范式

一范式要求

如果每列都是不可再分的最小数据单元

也称为最小的原子单元

我们就说它满足第一范式

表示成1NF

那么按照要求

我们的工程满足一范式吗

我们来看一下工程号、工程名称、

职工号、姓名、职务以及小时工资率

这些属性有没有可以再分解的属性

我们思考了发现里面没有可以再分解的属性

所以我们说工程它是满足第一范式

那好根据这个情况

我们直接把工程在抄写一遍

它是满足一范式的

那么如果这个关系模式是这个样子

学生括号学号 姓名 性别 家庭成员

大家觉得它满足一范式吗

学号能不能分

姓名能不能分成姓什么名什么

没有必要

那是古代人的叫法

所以学号 姓名 性别都是不能再分解的

但是我们来看家庭成员

按照我们的经验

家庭成员是不是可以分成

父亲 母亲 还有有的有兄弟姐妹对吧

那这样的形式

我们家庭成员

其实就是说可以在分解的属性

所以对于这样一个学生关系模式来说

它是不满足第一范式的

那不满足怎么办

非常简单拆分

拆分怎么来拆呢

就是把一个关系模式拆成两个关系模式

那对于刚才的学生来说

我们首先拆出第一个叫学生

它里面包括学生的学号 姓名和性别

而对于第二个

我们解决一个什么问题

家庭成员给人扔掉了

那么我需要把家庭成员单独拿出来

作为一个关系模式

那它里面涉及到的属性

包括姓名 性别 电话号码以及与本人的关系

这样对于学生和家庭成员来说

它们都已经满足了一范式的要求

接下来我们来看二范式

如果一个关系满足了一范式

并且除了主键以外的其它列都完全依赖于该主键

那么我们就说这个关系是满足第二范式的

简写成2NF

刚刚我们分析过了

对于工程来说

它是满足一范式的

那接下来我们需要看一下

它的其它主键是否是完全依赖于主键的

那我首先需要考虑一下工程的主键是什么

工程实际上说了两件事情

一个是工程的事情

一个是职工的事情

所以这个工程的主键应该是

工程号和职工号的组合

是一个复合主键

那其中的姓名它只依赖于

复合主键当中的一部分职工号

所以很显然按照要求

它是不满足第二范式的

那我们刚才说过

如果不满足我们的解决方案是拆分

那这个怎么进行拆分呢

首先我们刚才说了说的是两件事情

第一件事是工程

那么工程里面包括哪些属性呢

包括工程号和工程名称

第二件事情说的是员工

那么我们再做一个员工关系模式

里面包括职工号 姓名 职务和小时工资率

那么工程和员工之间得有关系

它们俩不是孤立的

如果看成实体的话

它们俩也存在联系

那么我给它起个名叫工作

那么工作理念它所涉及到的属性

它竟然是联系我前面说过了

就是两边连的实体的主键

包括工程号 包括职工号

还有它自己的属性叫工时

这样我把一个关系模式

拆成了三个关系模式

但是这三个关系模式都满足了我们二范式的要求

接下来我们来看三范式

如果一个关系满足了二范式

并且除了主键以外的其它列

都不传递依赖于主键列

那么我们说它满足三范式的要求

那么刚才我们已经把工程

拆分成了三个关系模式

下面我们需要看一下

这三个关系模式是否满足三范式的要求

首先工程包括工程号 工程名称

主键是工程号 工程名称依赖于工程号没有问题

接下来我们来看职工

职工那有职工号 有姓名 有职务 小时工资率

而题目当中明确说了

小时工资率是直接依赖于职务的

而我们的职务又依赖于主键值工号

所以这里面出现了传递依赖

也就是说员工它是不满足三范式的要求的

那怎么办 拆分怎么拆呢

把员工拆成两部分

一个是员工单纯的来访员工号姓名和职务信息

第二个是职务

职务里面放职务和小时工资率

这样我们的职工和职务全都满足了三范式的要求

那最后把工作 工程号 职工号和工时也抄下来

那么我们现在有一个关系模式

拆分成了四个关系模式

但是这四个关系模式都满足了我们的三范式的要求

那这个问题就解决了

那接下来我们进入任务实施环节

根据前面我们做的这道例题

大家思考一下

对于我们的数据库BankDB来说

它的关系规范化后的结果是什么样子的

规范化前包括用户银行卡交易信息三个关系模式

那我们需要通过1范式 2范式 3范式这样的规则

一步一步的去看它是否满足这些规范化的要求

首先大家来看1范式是否满足

也就是说在它的这些属性当中

有没有可以再分解的属性

我们看过一遍之后

发现没有可以再分解的属性

所以对于这三个关系模式来说

它全部都满足一一范式的要求

接着二范式

存不存在部分依赖

也就是说除了主键以外的其它属性

是否完全依赖于我们的主键呢

我们来看一下

对于用户表来说

主键是用户编号

对于银行卡表来说

它的主键是银行卡号

而对于交易信息来说

它的主键是交易编号

那么这里面主键都只有一个属性

所以不可能出现部分依赖

也就是说用户银行卡和交易信息

都满足二范式的要求

那我们来看三范式

三范示不能出现传递了

这里面有没有传递依赖

我们来看用户名 身份证 联系电话 地址

它都直接依赖于用户编号

同样的道理对于密码 货币 余额等等

也都直接依赖于银行卡号

还有后面的交易日期

还有交易类型

交易金额都依赖于我们的交易编号

所以它也满足三范式的要求

规范后的关系模式其实跟规范前是一样的

之所以出现这样的结果

是因为前面我们已经严格按照

数据库设计的步骤来完成数据库的设计

所以到规范化的时候

我们减轻了很多的负担

好今天的任务是做员工管理系统

EmployeeDB的关系规范化

感谢大家的聆听