数据库关系模型(数据库关系模型的概念)

前沿拓展：

数据库关系模型

关系模型数据库的优点：

1、关系模型和格式化模型不同，它是简次数据模型提供了良好的完整性支持。

层次数据库的缺点：

1、现实世界中很多联系都是非层次性的。

2、对插入和产出**作的限制比较多，因此应用程序的编写比较复杂、

3、由于结构严密，层次命令趋于程序化。

参考资料：百度百科-关系型数据库

参考资料：百度百科-层次型数据库

作者：郑龙飞范式定义

百度百科:设计关系数据库时，遵从不同的规范要求，设计出合理的关系型数据库，这些不同的规范要求被称为不同的范式，各种范式呈递次规范，越高的范式数据库冗余越小。

人类语言: 范式可以理解为设计一张数据表的表结构，符合的标准级别、规范和要求。

而通常我们用的最多的就是第一范式（1NF）、第二范式（2NF）、第三范式（3NF），也就是本文要讲的“三大范式”。

目前业界范式有：第一范式(1NF)、第二范式(2NF)、第三范式(3NF)、巴斯-科德范式(BCNF)、第四范式(4NF)、第五范式(5NF)。

什么是函数依赖？

百度百科:函数依赖简单点说就是：某个属性集决定另一个属性集时，称另一属性集依赖于该属性集。

人类语言:以下面表格为例，通俗易懂的解释，什么是函数依赖。

学号

姓名

系名

系主任

科名

分数

001

张三

计算机系

李雷

高等数学

001

张三

计算机系

李雷

大学英语

001

张三

计算机系

李雷

数据库设计

002

李四

计算机系

李雷

高等数学

002

李四

计算机系

李雷

java程序设计

002

李四

计算机系

李雷

大学英语

003

王五

财务系

韩梅梅

高等数学

003

王五

财务系

韩梅梅

财务基础

完全函数依赖

官方定义:设X，Y是关系R的两个属性**，X’是X的真子集，存在X→Y，但对每一个X’都有X’!→Y，则称Y完全函数依赖于X。

人类语言:比如通过，(学号，课程) 推出分数，但是单独用学号推断不出来分数，那么就可以说：分数完全依赖于(学号，课程) 。

小编综合来说:即：通过A B能得出C，但是A B单独得不出C，那么说C完全依赖于AB。

部分函数依赖

官方定义:假如 Y函数依赖于 X，但同时 Y 并不完全函数依赖于 X，那么我们就称 Y 部分函数依赖于 X。

人类语言:比如通过，(学号，课程) 推出姓名，因为其实直接可以通过，学号推出姓名，所以：姓名部分依赖于 (学号，课程)。

小编综合来说:通过AB能得出C，通过A也能得出C，或者通过B也能得出C，那么说C部分依赖于AB。

传递函数依赖

官方定义:传递函数依赖：设X，Y，Z是关系R中互不相同的属性**，存在X→Y(Y !→X),Y→Z，则称Z传递函数依赖于X。

人类语言:比如：学号推出系名，系名推出系主任，但是，系主任推不出学号，系主任主要依赖于系名。这种情况可以说：系主任传递依赖于学号。

小编综合来说:即：通过A得到B，通过B得到C，但是C得不到A，那么说C传递依赖于A。

三范式的区别第一范式

第一范式1NF核心原则：属性不可切割。

举例说明:

学号

姓名

系名

系主任

科名

分数

学籍信息

001

张三

计算机系

李雷

高等数学

本科，大二

002

李四

计算机系

李雷

大学英语

研究生,研三

很明显上面表格设计是不符合第一范式的，学籍信息列中的数据不是原子数据项，是可以进行分割的，因此对表格进行修改，让表格符合第一范式的要求，修改结果如下图所示：

学号

姓名

系名

系主任

科名

分数

学历

所在年级

001

张三

计算机系

李雷

高等数学

本科

大二

002

李四

计算机系

李雷

大学英语

研究生

研三

实际上，1NF是所有关系型数据库的最基本要求 ,你在关系型数据库管理系统（RDBMS），例如SQL Server，Oracle，MySQL中创建数据表的时候，如果数据表的设计不符合这个最基本的要求，那么**作一定是不能成功的。也就是说，只要在RDBMS中已经存在的数据表，一定是符合1NF的。

第二范式

第二范式2NF核心原则：不能存在“部分函数依赖”。

举例说明:

学号

姓名

系名

系主任

科名

分数

001

张三

计算机系

李雷

高等数学

001

张三

计算机系

李雷

大学英语

001

张三

计算机系

李雷

数据库设计

002

李四

计算机系

李雷

高等数学

002

李四

计算机系

李雷

java程序设计

002

李四

计算机系

李雷

大学英语

003

王五

财务系

韩梅梅

高等数学

003

王五

财务系

韩梅梅

财务基础

以上表格明显存在，部分依赖。比如，这张表的主键是 (学号，课名），分数确实完全依赖于(学号，课名），但是姓名并不完全依赖于(学号，课名）,让表格符合第二范式的要求，修改结果如下图所示：

学号

科名

分数

001

高等数学

001

大学英语

001

数据库设计

002

高等数学

002

java程序设计

002

大学英语

003

高等数学

003

财务基础

学号

姓名

系名

系主任

001

张三

计算机系

李雷

002

李四

计算机系

李雷

003

王五

财务系

韩梅梅

以上符合第二范式，去掉部分函数依赖依赖。

第三范式

第三范式 3NF核心原则：不能存在传递函数依赖。

举例说明:

学号

姓名

系名

系主任

001

张三

计算机系

李雷

002

李四

计算机系

李雷

003

王五

财务系

韩梅梅

在上面这张表中，存在传递函数依赖：学号->系名->系主任，但是系主任推不出学号。

上面表需要再次拆解：

学号

姓名

系名

001

张三

计算机系

002

李四

计算机系

003

王五

财务系

系名

系主任

计算机系

李雷

计算机系

李雷

财务系

韩梅梅

反三范式

没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，减少了查询时的关联，提高查询效率，因为在数据库的**作中查询的比例要远远大于DML的比例。但是反范式化一定要适度，并且在原本已满足三范式的基础上再做调整的。

小编综合来说

引用知乎大佬对范式的理解:

数据库设计应该也是分为三个境界的：

第一个境界，刚入门数据库设计，范式的重要性还未深刻理解。这时候出现的反范式设计，一般会出问题。

第二个境界，随着遇到问题解决问题，渐渐了解到范式的真正好处，从而能快速设计出低冗余、高效率的数据库。

第三个境界，再经过N年的锻炼，是一定会发觉范式的局限性的。此时再去打破范式，设计更合理的反范式部分。

拓展知识：

原创文章，作者：九贤生活小编，如若转载，请注明出处：http://www.wangguangwei.com/30186.html

数据库关系模型(数据库关系模型的概念)

前沿拓展：

数据库关系模型

拓展知识：

相关推荐