数据库范式理解

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

基本概念

实体:现实世界中客观存在并可以被区别的事物。比如“一个学生”、“一本书”、“一门课”等等。值得强调的是这里所说的“事物”不仅仅是看得见摸得着的“东西”,它也可以是虚拟的,比如说“老师与学校的关系”。
属性:教科书上解释为:“实体所具有的某一特性”,由此可见,属性一开始是个逻辑概念,比如说,“性别”是“人”的一个属性。在关系数据库中,属性又是个物理概念,属性可以看作是“表的一列”。
元组:表中的一行就是一个元组。
分量:元组的某个属性值。在一个关系数据库中,它是一个操作原子,即关系数据库在做任何操作的时候,属性是“不可分的”。否则就不是关系数据库了。
:表中可以唯一确定一个元组的某个属性(或者属性组),如果这样的码有不止一个,那么大家都叫候选码,我们从候选码中挑一个出来做老大,它就叫主码。
全码:如果一个码包含了所有的属性,这个码就是全码。
主属性:一个属性只要在任何一个候选码中出现过,这个属性就是主属性。
非主属性:与上面相反,没有在任何候选码中出现过,这个属性就是非主属性。
外码:一个属性(或属性组),它不是码,但是它别的表的码,它就是外码。
函数依赖:若在一张表中,在属性(或属性组)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

目录
相关文章
|
10天前
|
存储 关系型数据库 MySQL
轻松入门MySQL:数据库设计之范式规范,优化企业管理系统效率(21)
轻松入门MySQL:数据库设计之范式规范,优化企业管理系统效率(21)
|
4月前
|
移动开发 C#
数据库系统概论期末经典大题讲解(范式提升、求闭包、求主码)
数据库系统概论期末经典大题讲解(范式提升、求闭包、求主码)
128 0
|
7月前
|
存储 大数据 关系型数据库
【数据库三大范式】让我们来聊一聊数据库的三大范式和反范式设计
数据库三大范式是指数据库设计中的规范化原则,它们分别是第一范式(1NF)第二范式(2NF)和第三范式(3NF)。第一范式(1NF)第二范式(2NF)第三范式(3NF)
|
3月前
|
数据库
数据库三范式
数据库三范式
17 0
|
3月前
|
存储 数据库
数据库设计三范式
数据库设计三范式
|
8月前
|
关系型数据库 MySQL 数据库
MySQL数据库三大范式
MySQL数据库三大范式
|
4月前
|
SQL 关系型数据库 MySQL
MySQL数据类型、运算符以及数据库范式
MySQL数据类型、运算符以及数据库范式
46 0
MySQL数据类型、运算符以及数据库范式
|
4月前
|
存储 数据库 双11
数据库的三大范式及其重要性,详细易懂
数据库的三大范式及其重要性,详细易懂
180 0
|
4月前
|
SQL 关系型数据库 MySQL
MySQL数据库范式
MySQL数据库范式