开发者社区> 积淀> 正文
阿里云
为了无法计算的价值
打开APP
阿里云APP内打开

数据库范式理解

简介: 基本概念 实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”,它也可以是虚拟的,比如说“老师与学校的关系”。
+关注继续查看

基本概念

实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”,它也可以是虚拟的,比如说“老师与学校的关系”。
属性:教科书上解释为:“实体所具有的某一特性”,由此可见,属性一开始是个逻辑概念,比如说,“性别”是“人”的一个属性。在关系数据库中,属性又是个物理概念,属性可以看作是“表的一列”。
元组:表中的一行就是一个元组。
分量:元组的某个属性值。在一个关系数据库中,它是一个操作原子,即关系数据库在做任何操作的时候,属性是“不可分的”。否则就不是关系数据库了。
:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。
全码:如果一个码包含了所有的属性,这个码就是全码。
主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。
非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。
外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。
函数依赖:若在一张表中,在属性(或属性组)X的值确定的情况下,必定能确定属性Y的值,那么就可以说Y函数依赖于X,写作 X → Y。
范式的主要目的:减少数据冗余,但并非越严格约好,也并非一定要完全遵守,视需求以及性能而定,可适当冗余;

第一范式(1NF):属性不可分

场景举例:

用户表(姓名,联系方式,年龄)

假设联系方式字段存放微信号、手机、QQ、邮箱等,并且从业务需求来看,这些属性表述的含义和用途并不相同,则该属性的记录的数据不是原子的,因而不符合1NF;(注意此处一定是从业务的实际需求来看,并非一定要把字段拆分到最细不可)
应该将字段拆分,以满足1NF:

用户表(姓名,微信号,手机,QQ,邮箱,年龄)

第二范式(2NF):符合1NF,并且,非主属性完全依赖于码。(注意是完全依赖不能是部分依赖,设有函数依赖W→A,若存在(X,W),有X→A成立,那么称W→A是局部依赖,否则就称W→A是完全函数依赖)

场景举例:
课程表(姓名,课程,教师,教师职称,教材,教室,上课时间)

image

存在如下函数依赖:
一个学生上一门课,一定是特定某个老师教。所以有(学生,课程)->老师;
一个学生上一门课,一定在特定某个教室。所以有(学生,课程)->教室;
一个学生上一门课,他老师的职称可以确定。所以有(学生,课程)->老师职称;
一个学生上一门课,一定是特定某个教材。所以有(学生,课程)->教材
一个学生上一门课,一定在特定时间。所以有(学生,课程)->上课时间
因此(学生,课程)是一个码。
然而,一个课程,一定指定了某个教材,一年级语文肯定用的是《小学语文1》,那么就有课程->教材。(学生,课程)是个码,课程却决定了教材,这就叫做不完全依赖,或者说部分依赖。因而不满足第二范式;

由此引入的问题:
插入异常:假如新增课程,此时学生还没有选课,(学生,课程)为码,则学生字段不能为空,此时无法插入记录;
删除异常:下学期没学生学一年级语文(上)了,学一年级语文(下)去了,那么表中将不存在一年级语文(上),也就没了《小学语文1》。这时候,校长问:一年级语文(上)用的什么教材啊?……郁闷了吧?
更新异常:校长说:一年级语文(上)换教材,换成《大学语文》。有10000个学生选了这门课,改动好大啊!改累死了……郁闷了吧?

拆分课程表,变为2张表:课程表、教材表
课程表(姓名,课程,教师,教师职称,教室,上课时间)
教材表(课程,教材)

image

第三范式(3NF):符合2NF,并且,消除传递依赖(也就是每个非主属性都不传递依赖于候选键,判断传递函数依赖,指的是如果存在"A → B → C"的决定关系,则C传递函数依赖于A。)

场景举例:
课程表(姓名,课程,教师,教师职称,教室,上课时间)
教材表(课程,教材)

image

上面的“课程表,教材表”符合2NF,但不符合3NF,一个老师一定能确定一个老师职称,则存在传递依赖:
(学生,课程)->老师->职称

由此引入的问题:
修改异常:老师升级了,变教授了,要改数据库,表中有N条,改了N次……
删除异常:没人选这个老师的课了,老师的职称也没了记录……
插入异常:新来一个老师,还没分配教什么课,他的职称记到哪?……

继续拆分课程表,分为2张表:课程表、教师表
课程表(姓名,课程,教师,教室,上课时间)
教师表(教师,职称)
教材表(课程,教材)

image

BC范式(BCNF):符合3NF,并且,主属性不依赖于主属性(也就是不存在任何属性对任一候选码的传递函数依赖)

BC范式既检查非主属性,又检查主属性。当只检查非主属性时,就成了第三范式。满足BC范式的关系都必然满足第三范式。
若一个关系达到了第三范式,并且它只有一个候选码,或者它的每个候选码都是单属性,则该关系自然达到BC范式。

场景举例:
仓库管理表 (仓库ID, 存储物品ID, 管理员ID, 数量)
假设一个管理员只在一个仓库工作;一个仓库可以存储多种物品,则存在如下依赖关系:
(仓库ID, 存储物品ID) →(管理员ID, 数量)
(管理员ID, 存储物品ID) → (仓库ID, 数量)
所以,(仓库ID, 存储物品ID)和(管理员ID, 存储物品ID)都是StorehouseManage的候选码,表中的唯一非主属性为数量,它是符合第三范式的。但是,由于存在如下决定关系,即存在主属性之间的函数依赖,不符合BCNF范式:
(仓库ID) → (管理员ID)
(管理员ID) → (仓库ID)

引入问题:
删除异常:当仓库被清空后,所有"存储物品ID"和"数量"信息被删除的同时,"仓库ID"和"管理员ID"信息也被删除了。
插入异常:当仓库没有存储任何物品时,无法给仓库分配管理员。
更新异常:如果仓库换了管理员,则表中所有行的管理员ID都要修改。

拆分仓库管理表为2张表:仓库表、管理员表;
仓库表(仓库ID,存储物品ID)
管理员表(仓库ID,管理员ID)

数据库范式之间存在递进关系,更高一级的范式需要满足前面的所有范式,数据库设计通常符合3NF或BCNF就可以了。在BC范式以上还有第四范式、第五范式。

第四范式(4NF):要求把同一表内的多对多关系删除。

第五范式(5NF):从最终结构重新建立原始结构。

参考:https://www.cnblogs.com/lca1826/p/6601395.html

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

相关文章
啥是数据库范式
关于数据库范式,时常有听说过,一直没有详细去了解。一般数据库书籍或数据库课程会介绍范式相关内容,范式也经常出现在数据库考试题目中。不清楚你是否对范式有比较清晰的了解呢?本篇文章我们一起来学习下数据库范式吧。
0 0
函数依赖与数据库范式
什么是完全与部分函数依赖? 解释:完全和部分,是针对于某个集体而言的。这个集体,指的是主键是多个属性的组合,而不是单个属性的主键。理解了上面的函数依赖,那么这里的完全与部分就不用过多的解释了。 例如:常见的选课表([学号,课程号],成绩)[]里面是主键。
1954 0
数据库范式
数据库范式
0 0
090615 T 数据库范式
帮助记忆五级范式:    一级范式:        消除每个表格中重复的组。        为每套相关的数据建立一个独立的表格。        使用一个主键来标识每套相关的数据。    二级范式:        为应用在多条记录的字段建立独立的表格。
573 0
+关注
文章
问答
文章排行榜
最热
最新
相关电子书
更多
面向应用的反范式化数据建模
立即下载
低代码开发师(初级)实战教程
立即下载
阿里巴巴DevOps 最佳实践手册
立即下载