浅析数据库设计三范式

在学习数据设计的时候,N种专业术语，看的头疼。但又不能不学，所以只好把它们整理整理出来，好让自己对它们有一个更深的理解。特别是对三范式（Normal Formal）的理解。

三范式指的是第一（1NF)、第二(2NF)和第三范式(3NF),其作用：解决数据冗余，为数据有效性检查，提高存储效率考虑。

在了解三范式之前，我们先来弄清楚这几个概念（键、函数依赖以及其类型）：

一、关键码（键）：由一个或多个属性组成，在实际使用中，有下列几种：

超键：在关系中能唯一标识元组的属性集称为关系模式的超键。注意:（属性集，说明可以是多个）
候选键：不含有多余属性的超键
主键：用户选作记录标识的候选键

这三个的关系，用数学关系可以做如下表示：

举例：一张学生信息表

问：超键是？

答曰：学号唯一，是超键；姓名唯一，是超键；（学号，年龄）唯一，是超键；（学号、姓名、年龄）唯一，也是超键。

——从这里我们就可以看出，超键的组合是唯一的，但不可能是最小唯一的。

问：候选键是？

答曰：学号，唯一且没有多余的属性；姓名，唯一且没有多余的属性。

问：主键是？

答曰：既可以选择学号，也可以选择姓名（前提是规定没有重名的）作为主键，所以主键是选中的一个候选键。

数据库设计的目的主要是为了解决数据冗余，对数据进行有效的管理。那么引起数据冗余的主要原因是什么呢？答曰：数据依赖。什么是数据依赖？数据依赖是指在一个关系模式之间的依赖关系。其最典型的例子就是函数依赖。

二、函数依赖：若对于R(U)的任意两个可能的关系r1、r2，若r1[x]=r2[x],则r1[y]=r2[y]，或者若r1[x]不等于r2[x],则r1[y]不等于r2[y]，称X决定Y，或者Y依赖X。

通俗的说：就是我们知道一个之后可以推导出另外一个。

我们都知道，在数据库中，属性之间都是会发生联系。例如，每个学生只有一个姓名，每门课程只有一个任课教师，每个学生学一门课程只能有一个总评成绩。等等，这类联系，我们都可以将其称为函数依赖（FD），所以没必要把这概念弄的那么玄乎。

函数依赖包括以下三种类型：

1.平凡与非平凡依赖：

a.平凡依赖

b.非平凡依赖

2.局部依赖与完全依赖：

a局部依赖

b.完全依赖

图上中：对于W—>A ,如果在X存在与W中，有X—>A成立，那么称W—>A是局部依赖，否则称W—>A是完全依赖。

3.传递依赖：

如图： X—>Y,Y—>A,且Y／>X和A不属于Y，那么称X—>A是传递依赖。

最后、三范式的理解：

第一范式：要求每个关系的属性为原子性，不可再分。（能分就分，分到不能再分为止！）

例如：R（学号，姓名，性别）

第二范式：主要是消除局部依赖

违反第二范式的局部依赖示意图：

例如：有关系模式为：R（学号、课程编号、成绩、教师号、教师职称）等。

R上有两个FD：（学号，课程号）—>(教师号，教师职称）和课程编号—>(教师工号，教师职称）。由此，可得出前面一个是局部依赖。所以R关系模式不是第二范式模式。此时R的关系就会出现冗余和异常现象。例如，如果一门课程有10个学生选修，那么在关系中就存有10条记录，教师工号和职称也会重复10次。

解决方案：将R分解成R1（课程编号，教师号，教师职称）和R2（学号，课程号，成绩）。此时，R1和R2都是第二范式模式。

第三范式：主要是消除传递依赖

(1)

(2)

(3)

违反3NF的三种传递依赖情示意图

例如：R（课程编号，教师工号，教师职称）关系模式中，如果课程编号—>教师工号，教师工号—>教师职称，那么课程编号—>教师职称就是一个传递依赖。所以不是第三范式。此时R就会出现冗余和异常操作。例如，一个教师开设五门课程，那么关系中就会出现五条记录，教师职称就会重复五次。

解决方案：把R分解为R1（教师工号，教师职称）和R2（课程编号，教师工号）

我们在学习的过程当中，第一次可能只是懵懵懂懂，这很正常。所以不要觉得有什么？放宽心态，踏实的往下学就可以了。随着再往后的学习中，我们会对前面的学习进行一个不断反复的过程，但那时候我们可以在前面的基础上，对他们进行深入的研究。

浅析数据库设计三范式相关推荐

[数据库03]-约束（唯一性-主键-外键/存储引擎/事务/索引/视图/DBA命令/数据库设计三范式
[数据库03]-约束(唯一性-主键-外键)/存储引擎/事务/索引/视图/DBA命令/数据库设计三范式一.约束 1.1 唯一性约束(unique) 1.2 主键约束 1.3 外键约束二.存储引擎 2 ...
MySQL之数据库设计三范式
目录一.简介第一范式第二范式第三范式结语学习计划: 一.简介我们数据库表设计的时候需要尽可能的遵循三范式,具体是第一范式(1NF): 强调的是列的原子性,即列不能够再分成其他几列, ...
MySQL面试题数据库设计三范式
第一范式属性(字段)的原子性约束,要求属性具有原子性,不可再分割: 比如个人信息,个人信息不能作为一个字段,它可以再分为姓名.name.age等: 第二范式记录的惟一性约束,要求记录有惟一标识,每 ...
深入浅出数据库设计三范式
设计良好结构的数据库,可以有效减小数据冗余,减少增删改中出现的问题.深入理解数据库设计的三范式,对于设计"健壮的数据库"十分有必要.数据库三范式是设计数据库时参考的准则,接下来我 ...
数据库设计三范式（3NF）
问:当时你数据库是如何设计的? 答:当时是按照三范式规范设计的: 第一范式: 1:数据库的原子性,即保证数据库表的每一列都不可分割的第二范式: 1:原子性,即保证数据库表的每一列都不可分割 2:表中 ...
数据库设计三范式的举例及四大特性说明
更多免费教学文章请关注这里前言数据库课本上都把范式写到五范式了,但是实际应用中,满足三范式已经足够了,五范式太多余了. 三种范式是条件递增的联系(即后一个范式是在前一个条件满足的情况下引入新的条件 ...
【数据库】数据库设计三范式
数据库设计的三大范式为了建立冗余较小.结构合理的数据库,设计数据库时必须遵循一定的规则.在关系型数据库中这种规则就称为范式.范式是符合某一种设计要求的总结.要想设计一个结构合理的关系型数据库,必须满 ...
数据库设计三范式详细介绍--数据库设计规范之数据库设计三范式
为什么需要数据库设计 1. 我们在设计数据表的时候要考虑很多问题问题,比如: 用户都需要什么数据?需要在数据表中保存哪些数据? 如果保证数据表中数据的正确性,当插入.删除.更新的时候该进行怎么样的约束 ...
MySQL——数据库设计三范式
0.数据库设计范式设计范式是数据库表的设计依据,如何进行数据库表的设计. 设计数据库表时按照三范式进行,可以避免表中数据的冗余,空间的浪费. 1.第一范式要求任何一张表必须有主键,每一个字段原子性 ...

浅析数据库设计三范式

浅析数据库设计三范式相关推荐

最新文章

热门文章