【高效学数据库】第一范式、第二范式、BCNF范式、第三范式、第四范式概念及举例
本专栏将从基础开始,循序渐进的讲解数据库的基本概念以及使用,希望大家都能够从中有所收获,也请大家多多支持。
专栏地址: 数据库必知必会
如果文章知识点有错误的地方,请指正!大家一起学习,一起进步。
如果感觉博主的文章还不错的话,还请关注、点赞、收藏三连支持一下博主哦
文章目录
- 1NF
- 关系数据库设计中易犯的错误
- Armstrong公理
- 正则覆盖
- 2NF
- BCNF
- 3NF(常用)
- 多值依赖
- 4NF(不常用)
1NF
如果某个域中元素被认为是不可分的,则这个域称为是原子的。
非原子域的例子如下:
― 复合属性:名字(first-name second-name)
― 多值属性:电话号码
― 复杂数据类型:面向对象的
如果关系模式R的所有属性的域都是原子的,则R称为属于第一范式 (1NF)
关系数据库设计中易犯的错误
关系数据库设计要求我们找到一个“好的”关系模式集合。一个坏的 设计可能导致
- 数据冗余
- 插入、删除、修改异常
假设,我们用以下模式代替instructor模式和department模式: inst_dept(ID, name, salary, dept_name, building, budget),如下图所示:
可以看出每个系的dept_name,building,budget数据都要重复一次,这样做浪费空间,并且可能导致数据不一致,更新也较复杂,例如修改dept_name,很多相关元组都要进行修改。
模式分解
可以将关系模式(A,B,C,D)分解为:(A,B)和(B,C,D),或(A,C,D)和 (A,B,D),或(A,B,C)和(C,D),或(A,B)、(B,C)和(C,D),或 (A,D)和 (B,C,D) 。
例,将关系模式inst_dept分解为:
― instructor(ID,name,dept_name,salary)
― department(dept_name,building,budget)
原模式(R )的所有属性都必须出现在分解后的(R1, R2)中:R=R1∪R2R = R_1 \cup R_2R=R1∪R2
如果R1R_1R1和$ R_2全外连接等于全外连接等于全外连接等于R$,则是一个无损连接分解。
例:
函数依赖
例:
Armstrong公理
Armstrong公理是用来找到闭包的一个理论,先介绍一下什么是函数依赖集的闭包:给定函数依赖集F,存在其他函数依赖被F′F^{\prime}F′逻辑蕴含
(例:如果A→B且B→C,则可推出逻辑蕴涵A→C),被F′F^{\prime}F′逻辑蕴含的全体函数依赖的集合称为F的闭包,用F+F^+F+表示F的闭包。
我们可以利用Armstrong公理找出F+F^+F+:
- 若β⊆α\beta\subseteq\alphaβ⊆α,则α→β\alpha→\betaα→β(自反律)
- 若α→β\alpha→\betaα→β,则γα→γβ\gamma\alpha→\gamma\betaγα→γβ(增补率)
- 若α→β\alpha→\betaα→β且β→γ\beta→\gammaβ→γ,则α→γ\alpha→\gammaα→γ(传递率)
- 若α→β\alpha→\betaα→β与α→γ\alpha→\gammaα→γ成立,则α→βγ\alpha→\beta\gammaα→βγ成立(合并率)
- 若α→βγ\alpha→\beta\gammaα→βγ 成立,则α→β\alpha→\betaα→β与α→γ\alpha→\gammaα→γ成立(分解率)
- 若α→β\alpha→\betaα→β与成γβ→δ\gamma\beta→\deltaγβ→δ立,则αγ→δ\alpha\gamma→\deltaαγ→δ成立(伪传递率)
例:
与此对应的还有属性集的闭包,属性集的闭包为某一些属性能推导出的所有属性形成的集合,例:
属性闭包有多种用途:
正则覆盖
F的正则覆盖(记做FcF_cFc)是指与F等价的“极小的”函数依赖集合:
- FcF_cFc中任何函数依赖都不包含无关属性
- FcF_cFc中函数依赖的左半部都是唯一的
例:α1→β1,α1→β2\alpha_1 → \beta_1,\alpha_1 → \beta_2α1→β1,α1→β2,=>α1→β1β2\alpha_1 → \beta_1\beta_2α1→β1β2
计算正则覆盖的方式如下:
2NF
在满足第一范式后,第二范式要求表中所有的列都必须依赖于主键,且不能只依赖主键的一部分。简而言之,第二范式就是非主属性非部分依赖于主键。
不符合第二范式的例子:
货物类型 | 货物ID | 货物名称 | 注意事项 |
---|---|---|---|
瓷碗 | 1 | 白色瓷碗 | 易碎品 |
瓷碗 | 2 | 青花瓷碗 | 易碎品 |
瓷碗 | 3 | 雕花瓷碗 | 易碎品 |
三合板 | 1 | 普通三合板 | 易燃物品,注意防火 |
在该表中主键为(货物类型,货物ID),货物名称字段完全依赖于这个主键,换句话说,货物的名称完全是取决于这个主键的值的。但“注意事项”这一列,仅依赖于一个主键中”货物类型“这一个属性。根据第二范式规定,既然表中存在一个对主键不是完全依赖的字段,那么我们就可以确定,该表不符合第二范式。
BCNF
通俗点说就是在一个数据库R的关系中,如果关系α\alphaα能推导出β\betaβ,则要么β\betaβ是α\alphaα的子集,要么α\alphaα是R的超码。
BCNF分解算法
- 找出关系中的函数依赖关系,例如A→B
- 如果A不是超码或者B不是A的子集,则创建新的关系(A,B),并将B从原表中删除
- 直到找不出违反BCNF范式的表
例:
将class (course_id, title, dept_name, credits, sec_id, semester, year, building, room_number, capacity, time_slot_id)分解为BCNF范式,函数依赖关系如下:
- course_id → title, dept_name, credits
- building, room_number → capacity
- course_id, sec_id, semester
- year → building, room_number, time_slot_id
候选码如下:
{course_id, sec_id, semester, year}
BCNF分解如下:
course_id → title, dept_name, credits,但是course_id 不是超码,我们将class 分解为:
― course(course_id, title, dept_name, credits)
― class-1 (course_id, sec_id, semester, year, building, room_number, capacity, time_slot_id )
course是BCNF,在class-1中,存在依赖building, room_number → capacity ,但是 {building, room_number}不是class-1的超码,将class-1分解为:
― classroom (building, room_number, capacity)
― section (course_id, sec_id, semester, year, building, room_number, time_slot_id)
此时classroom和section是BCNF范式。
但是,BCNF分解不总是保持依赖的,例:
因此,我们并不总能满足这三个设计目标:
- 无损连接
- BCNF
- 保持依赖
3NF(常用)
因为BCNF不保持依赖,所以需要定义一种较弱的范式,称为第三范式(3NF),一般来说,数据库只需满足第三范式(3NF)就行了。
第三范式在BCNF范式上多了一个可选择的条件,下列条件中至少一个成立,就属于第三范式:
超码: 一个或多个属性的集合,这些属性可以让我们在一个实体集中唯一地标识一个实体
候选码:一个或多个属性的集合,能够唯一标识一个元组,且它的真子集不能唯一标识元组。
主码(主键):从所有候选码中选择一个,作为主码。例如:学生关系(学号,身份证号,姓名,院系,专业,性别 ,生日),有两个候选码:【学号】和【身份证号】,我们可以选择学号为主码,也可以选择身份证号为主码(当然,一般还是选择学号为主码)。
属性:上例中:学号、身份证号、姓名。。。都是学生的属性。
主属性:主属性指的是候选码中的属性。上例中的学号、身份证号都可以称为主属性。选课(学号,课程号),此关系的候选码只有一个,为:【学号、课程号】,故主属性有:学号、课程号。
以上三个规则通俗点说就是:在一个数据库R的关系中,如果关系α\alphaα能推导出β\betaβ,则要么β\betaβ是α\alphaα的子集,要么α\alphaα是R的超码,要么从关系α\alphaα中推导出的属性是主属性(包含在候选码中)。
例:
3NF分解算法:
求出所有依赖的正则覆盖
将所有的α\alphaα→β\betaβ组成新的关系Ri=(α,β)R_i=(\alpha,\beta)Ri=(α,β)
遍历所有的关系RiR_iRi
2.1 如果RiR_iRi不包含候选码,则添加随意一个候选码;
2.2 如果RiR_iRi是其他模式的子集,将其删除
3NF示例:
关系模式:cust_banker_branch = (customer_id, employee_id, branch_name, type )
函数依赖:
- customer_id, employee_id → branch_name, type
- employee_id → branch_name
- customer_id, branch_name → employee_id
候选码为(customer_id, employee_id)
- 计算正则覆盖:
branch_name 在第一个函数依赖中是多余的,没有其他的多余属性,因此,我们得到
FC =― customer_id, employee_id → type ― employee_id→branch_name― customer_id, branch_name → employee_id
- 通过for循环,我们得到以下子关系模式:
- (customer_id, employee_id, type)
- (employee_id, branch_name)
- (customer_id, branch_name, employee_id)
- 由于每个关系都包含原关系模式的候选码,分解到此为止
- 在循环结束后,检查并删除模式。如(employee_id, branch_name)是其他模式的子集,应该删除。
- 最后,得到3NF分解的子关系模式:
(customer_id, employee_id, type)
(customer_id, branch_name, employee_id)
虽然平时开发中满足第三范式就行了,但是我们还是需要了解一下第三范式的不足:
多值依赖
4NF(不常用)
有时属于BCNF的模式仍然未充分规范化,考虑数据库 classes(course, teacher, book) 定义(c,t,b)∈\in∈classes,意思是教师t 可以教课程c,而b是需用于课程c 的教材,数据库将为每门课程列出能讲授该课程的教师的集合,以及需用的书的集合(不管谁讲授该课),course: teacher =1:n,course: book = 1:n,teacher和book是多值属性 , 并且teacher和book相互独立,如下图所示:
该表中(course, teacher, book)是唯一的键,因此该关系模式属于BCNF,但是该表存在冗余,例如Sara是能教数据库的新教师,必须插入两条元组
(database, Sara, DB Concepts)
(database, Sara, Ullman)
因此,最好将classes 分解成:
在前面的例子中:
course→→teacher (→→表示多值决定)
course→→book
对于多值决定的通俗解释就是:给定Y (course)的特定值,则有一个Z (teacher)值的集合和一个W (book)值的集合与之相关联,而这两个集合在某种意义上是相互独立的。
关系模式R关于函数依赖及多值依赖集合D属于4NF当且仅当有形如α→→β\alpha→→\betaα→→β的多值依赖,下列至少一个成立:
- β⊆α\beta\subseteq\alphaβ⊆α或β∪α=R\beta\cup\alpha=Rβ∪α=R
- α\alphaα是模式R的超码
4NF的通俗解释是:在一个数据库R的关系中,如果关系α\alphaα多值决定β\betaβ,则要么β\betaβ是α\alphaα的子集,要么α\alphaα是R的超码。
4NF的分解算法如下:
- 找出关系中的多值决定,例如A→→B
- 如果A不是超码或者B不是A的子集,则创建新的关系(A,B),并将B从原表中删除
- 直到找不出违反以上两个规则的表
例:
候选码为(A,B,C,G)。R不属于4NF,因为A→→B,A不是R的超码
将R分解为:
R2R_2R2中,CG→→H,而CG不是超码,将R2R_2R2分解为:
至此,完成了4NF的分解。
【高效学数据库】第一范式、第二范式、BCNF范式、第三范式、第四范式概念及举例相关推荐
- mysql中bcnf_请问数据库设计中BCNF范式是什么意思?
展开全部 BCNF范式在3NF基础上消除对主码子集的62616964757a686964616fe78988e69d8331333431373230依赖. 以仓库管理关系表为例:仓库号,存储物品号,管 ...
- 第一范式、第二范式、第三范式、巴斯-科德范式、第四范式、主码、候选码、码详解
目录 数据库逻辑设计 主码.候选码.码 第一范式 第二范式 第三范式 巴斯-科德范式 第四范式 数据库逻辑设计 前面我们讲了第二范式,我们知道还有第三范式,那么第三范式的特点到底是什么呢?下面我们来一 ...
- 数据库 部分函数依赖 完全函数依赖 传递函数依赖 第一范式、第二范式、第三范式、BCNF范式区别
数据库 部分函数依赖 完全函数依赖 传递函数依赖 第一范式.第二范式.第三范式.BCNF范式区别 在理解函数依赖之前,先来看一下函数依赖分析: 在关系中,包括在任何候选码中的属性称为主属性:不包括 ...
- 数据库第一范式、第二范式、第三范式、BCNF范式
文章目录 什么是"范式(NF)" 1. 第一范式(1NF) 2. 第二范式(2NF) 2.1 函数依赖 2.1.1完全函数依赖 2.1.2 部分函数依赖 2.2 码 2.3 非主属 ...
- 数据库|第一范式、第二范式、第三范式、BC范式、第四范式简单理解
数据库|第一范式.第二范式.第三范式.BC范式.第四范式简单理解 在设计数据库的时候,虽说将我们要的数据正确完整导入数据库是很关键的,但是对于数据库的设计者来说,如何将大量数据合理有效正确地导入数据库 ...
- 第一范式,第二范式,第三范式,BCNF范式理解
基础知识 实体:现实世界中客观存在并可以被区别的事物.比如"一个学生"."一本书"."一门课"等等.值得强调的是这里所说的"事物& ...
- MySQL (4) 第一范式 第二范式 第三范式 BC范式
第一范式 第一范式:所有属性都是不可分割的原子值. 也就是每个属性都是不可再分的. 例如下图就不符合第一范式的要求 实际上,1NF是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RDBMS) ...
- 数据库第一范式1NF,第二范式2NF,第三范式3NF详解
文章目录 一,超码.主码.候选码之间的定义与联系 二,函数依赖. 三,三大范式 第一范式(1NF): 第二范式(2NF): 第三范式(3NF): BCNF 一,超码.主码.候选码之间的定义与联系 码是 ...
- 第一范式 第二范式 第三范式 BC范式
第一范式 第一范式:所有属性都是不可分割的原子值. 也就是每个属性都是不可再分的. 例如下图就不符合第一范式的要求 实际上,1NF是所有关系型数据库的最基本要求,你在关系型数据库管理系统(RD ...
- 数据库第一范式,第二范式,第三范式详解
数据库第一范式,第二范式,第三范式详解 基础知识 实体:现实世界中客观存在并可以被区别的事物.比如"一个学生"."一本书"."一门课"等等. ...
最新文章
- GDCM:gdcm::DirectionCosines的测试程序
- (61)UART外设驱动接收驱动(六)(第13天)
- Docker学习文档之一 安装软件-Windows环境
- MySQL迁移安装_mysql数据库安装路径迁移
- 关于static继承的问题
- 世人都晓AI好 AI芯片知多少?
- 谁说漂亮女程序猿就不能拿大厂Offer了?
- 拓端tecdat|R语言基于线性回归的资本资产定价模型(CAPM)
- 敏感词库php数组,PHP 实现敏感词 / 停止词 过滤(附敏感词库),敏感类词语大全...
- CLIP还能做分割任务?哥廷根大学提出一个使用文本和图像prompt,能同时作三个分割任务的模型CLIPSeg,榨干CLIP能力...
- 倒,chinaitlab.com也放木马
- (附源码)Python音乐分类系统 毕业设计 250858
- Python的print输出对齐
- 关于联想Thinkpad E450 系列笔记本电脑独立显卡不能工作的解决方案(蓝屏/卡顿/掉帧)
- vmstate内存事件详解
- matlab %,Matlab
- python 在 win cmd 环境中形如 '\xhh' 输出的转化
- vue中this.$nextTick()使用解析
- cmd连续ping记录断流情况
- 四金计算器Tech Support
热门文章
- 《洞见》罗伯特·赖特
- 简述BSD协议和GPL协议的区别
- win11连接共享打印机错误0x00000709
- 浅谈文字编码和Unicode(下)
- mbedtls学习3.mbedtls_API分析
- 计算机网络系统工程监理,GB-T 19668.4-2007 信息化工程监理规范 第4部分:计算机网络系统工程监理规范.pdf...
- 爬虫爬取图片并保存到电脑
- 微信小程序标签样式的优先级
- App 抓包工具一(Charles)
- 浅谈计算机教学论文,浅谈计算机教学(论文)