目录
- 数据依赖
- 范式
- 第一范式1NF
- 第二范式2NF
- 第三范式3NF
- BC范式
- 数据依赖的公理系统
- 闭包
- 最小依赖集
- 候选码
- 设计
- 需求分析
- 概念结构设计
- E-R图的概念模型
- E-R模型转换为关系模型(指出转换结果中每个关系模式的主码和外码)
- 逻辑结构设计
- 物理结构设计
- 数据库实施
- 数据库运行和维护
数据依赖
基础
FD(functional dependency),数据库系统函数依赖。
码
K为 R<U,F> 中属性或属性的组合
K(Full完全依赖)U, 则K为R的候选码 (特殊的超码)/ 超码
单个属性是码全码: 整个属性组是码,称为全码外码
码 用下划线标出
主属性: 包含在任何一个候选码中的属性
非主属性: 不包含在任何候选码中的属性超码
如果属性集合X能够唯一确定Y,而且X的任何真子集都不能唯一确定Y,那么X就是关系R的超码。
举个例子,假设有一个关系模式R(ABCDE),如果属性集合{AB}能够唯一确定C,而且A和B的任何真子集都不能唯一确定C,那么{AB}就是R的一个超码。
确定FD
R(U,F) ,X,Y
R关系模式名,如学生表student
U 属性名的集合, X为U中一个属性区间, Y同样也是,如U={ sno, sname ,ssex} , X={sno,sname}
F 属性间依赖关系集y=f(x) : x值确定, 则y值确定数据库中:
x:决定因素 , y函数依赖x
sno 学号确定姓名, sname 姓名依赖于学号
平凡函数依赖
判断
x 完全决定于 y ,无需其他属性参与
y包含在x中当一个属性集合X的函数依赖于属性集合Y时,如果Y是X的子集,那么这个函数依赖被称为平凡函数依赖。简单来说,平凡函数依赖指的是一组属性完全决定了另一组属性,没有任何其他附加条件。举例说明:假设有一个关系模型R,属性集合为{A, B, C},其中A是关系模型中的候选键。如果函数依赖A -> B 存在于R中,那么这是一个平凡函数依赖。因为A本身已经能够完全决定B的值,没有其他附加条件。
非平凡函数依赖
判断
x 部分决定于 yz , 需要其他属性参与才可完全决定yz
yz 不包含在x中确定候选键:首先需要识别出关系中的所有候选键。
检查函数依赖:查看关系中的所有函数依赖,特别是非平凡函数依赖。
验证左侧蕴含:对于每一个非平凡函数依赖,检查其左侧是否可以独立地确定右侧的属性。
验证左侧为候选键的一部分:对于每一个非平凡函数依赖,检查其左侧是否至少是候选键的一部分,或者能够推出候选键。非平凡函数依赖:当一个属性集合X的函数依赖于属性集合Y时,如果Y不是X的子集,那么这个函数依赖被称为非平凡函数依赖。简单来说,非平凡函数依赖指的是一组属性可以部分决定另一组属性,但不能完全决定,需要其他属性的参与。举例说明:假设有一个关系模型R,属性集合为{A, B, C, D},其中A是关系模型中的候选键。如果函数依赖A -> BCD 存在于R中,那么这是一个非平凡函数依赖。因为A本身无法完全决定B、C、D的值,还需要其他属性的参与。非平凡, X,Y之间有包含关系x 决定 y, y不包含x
如:(sno,cno) 决定 grade
函数依赖
完全函数依赖
ab---c, 但a 不能决定 c (sno,cno) 完全函数依赖full 成绩grade
单独一个学号不能确定 成绩 grade
定义: X 决定Y, 且x'(x中的一个真子集) 不能决定 Y
举例: 通过AB能得出C,但是A, B单独得不出C,那么说C完全依赖于AB.
比如(学号,课名)->成绩,而单独的学号或者课名都不能确定成绩,这就叫完全函数依赖
总结: 只能由某个属性A或属性组决定另一个属性B,此外其他的所有属性都不可决定另一个属性B
部分函数依赖(2nf)
ab--c, 且a--c,b---c (sno,cno) 部分函数依赖 系别sdept
y部分函数依赖 x, 则x必定是组合属性
x决定Y, Y不完全函数依赖于X
举例: 通过AB能得出C,通过A也能得出C,通过B也能得出C,那么说C部分依赖于AB。
比如(学号,课名) 决定 姓名,而单单的 学号 也可以决定姓名, 这样的依赖就叫部分函数依赖。
总结: 可以有多个属性决定 另一个属性B,
传递函数依赖(3NF)
x--y (y不能决定x) , 且 y ---z, 则: x---z
x 确定 y, y确定 z , 且 y不能确定x , 则 x 传递函数 z 或
通过A得到B,通过B得到C,但是C得不到B,B得不到A,那么成C传递依赖于A
比如学号->系名,系名->系主任,并且(系名不能决定学号),所以系主任传递函数依赖学号
范式
对关系模式判定的条件, 关系必须满足一定的要求
范式间的关系
5NF最为严格(关系模式好), 1NF最宽松(关系模式不好)
关系的规范化
规范化: 一个低一级范式的关系模式,通过模式分解可以转换为若干个高一级范式的关系模式的集合,这种过程就叫规范化
低范式到高范式的分解
取其精华,弃其糟粕
第一范式1NF
判断:
属性不可再分,原子性; 确保每个单元格中只有一个值例如
属性电话号码, 若包含多个电话号码的字段,那么这个表就不符合第一范式
只能是一个电话号码 对应 一个 记录如Excel表,单元格合并拆分, 不符合1NF
第二范式2NF
判断
非主键列必须完全依赖于整个主键 ,不存在部分函数依赖 ;
ab---c ; a / b 不能决定c 满足2nf的条件
每一个非主属性都完全函数依赖于R的码
1nf 到2nf :
1NF 到 2NF: 消除非主属性对码的部分函数依赖slc(sno,cno,sdept,sloc住处,grade) 关系模式
部分/完全 函数依赖
full: (sno,cno) f grade
part:
sno- sdepte, (sno,cno) p sdept (不符合2nf)
sno- sloc, (sno,cno) p sloc
分解到2nf
投影分解法:
完全函数依赖 / 部分函数依赖单独拉出来使其规范到2nf
完全函数依赖的,单独投影出来
sc(sno,cno,grade)
部分函数依赖,拉出来:
sl(sdepte,sloc), 通过sno建立联系,最终为 : sl(sno, sdepte,sloc)存在的问题:
IS系学生全部毕业: sdepte,sno,sloc全部删除,异常
第三范式3NF
判断条件
所有非主属性都不传递依赖于主属性
a-b b- c ; 但a不能决定c传递函数依赖2NF 到 3NF : 消除非主属性对码的传递函数依赖
若R 属于 3NF,则每一个非主属性既不部分依赖于码也不传递依赖于码不存在非主属性对主属性的传递函数依赖
sl(sno,sdept,sloc) (不属于3NF)
例如:2NF sl(sno, sdept, sloc)
函数依赖为: sno - sdept, sdepte不- sno, sdept- sloc , 可得: sno 传递- sloc ,存在非主属性对码的传递函数依赖
分解到3nf:
投影分解使其消除传递函数依赖:
SD(sno,sdepte) ,码为sno
DL(sdept,sloc) , 码为 sdepte
此时不存在传递依赖
BC范式
判断
不存在 非平凡(部分函数) 依赖每一个函数依赖的左边都包含了关系的候选键3NF 到 BCNF 消除主属性对码的部分和传递函数依赖特: BC范式属于3NF, 其他不是为改善的第三范式stj(s,t,j) : s学生,t教师,j课程
自动满足3NF,但也有插入删除异常
第四范式
第五范式
数据依赖的公理系统
逻辑蕴含
armstrong 公理系统
自反律: ab-- a ; ab ; b (自身)
增广律: x-y ; 则 xz-yz (同乘以z) ; (扩展)
传递律: x-y ,y-z , 则 x-z (传递)
举例(根据自反律与增广律得到: ab 决定-c, 则a-b,b-c )
推理规则
合并规则: x-y,x-z , 有 x-yz (合并到右,左不变)
分解规则: x-yz, 得 x-y, x-z ( 右边分解,左不变)
伪传递规则: x-y, wy-z , 有xw-z (消除掉了Y )
复合律
过x- y 和 w-z 在r 上成立, 则xw-yz 在r上也成立(左边乘右边)
闭包
总结:
求属性BD的闭包,求该属性F函数依赖的全体, 记为(BD)F+
计算方法:
在函数依赖集合中,在左边(决定属性)中查找仅包含B/D/BD的式子
设x(0), 找到相对应的右边的属性, 并合并左边的属性一起作为下次循环的决定属性; 循环重复, 最终得到的属性不可重复即可定义: 在关系模式R<U,F>中为F所逻辑蕴含的函数依赖的全体叫作F的闭包(closure),记为F+
作用:
计算过程 类似 for循环
求ab属性的闭包,记为: (ab)f+
设 x(0)= ab
求a,b, 所有组合的元素的式子
a,b,ab
注意: 左边的包含ab,不能有其他的
ab-c, b-d
把右边的属性并到原有的x中: x(0) =abcd
循环
x(1)= abcd
求a,b,c,d所有组合的元素的式子
c-e, ac-b
继续并 得到: x(1) =abcde
当x(1)=U时, 结束运算, 得到(ab) f+ 闭包
最小依赖集
步骤:
1. 分解右部属性,使之称为单个属性
2. 消除冗余函数依赖 (通过求各自B包, 假设该依赖冗余, 此时依赖集中去除该依赖,求b包; 若推不出右边属性或求出的B包中没有右边的属性,则保留; 反之,则删除)
3. 接上步, 删除后得到此时的F; 消除此时剩下的左边为双属性, 删除左边的一个属性,对另一个属性求B包. 若, 推不出右边属性 或求出的B包中没有右边的属性,则保留; 反之,则删除 ( 删除后则其中一个属性就被删除了, 但保留的属性还在 ,就变为单属性了)
注意: 若进行到第3步, 则需要重新执行第 2步要求:
这时需要分解
最后 保留的依赖集, 不能由其他函数推导出
最小依赖集求解的方法与步骤:
(1)应用分解规则,使F中每一个依赖的右部属性单一化
(②)去掉多余的依赖。
(③)去掉各依赖左部多余的属性。
计算:
f中的最小依赖集
f{ a-bc , b-c, a-b, ab-c, }
1. 找到右边双属性的
a-bc ,分解得到:
a-b, a-c
去重复, 两个a-b2. 因为 a-b,b-c, 推导出a-c, 则a-c可删除3. ab-c, 由 a-b,b-c推出, ab-c可删除
候选码
候选码计算方法:
在函数依赖F中
1 找到函数依赖集的左边L / 右边R / 既在左边又在右边LR 出现的 属性, 一 一分组列出
2 计算仅在函数依赖左边出现的属性的闭包+ , 若等于U中全部的属性,则是候选码; 结束
3 不等于U中全部属性则需要考虑 既在左边又在右边LR出现的 属性:
在LR中取一个属性A,求(A)F+ ,若它包含了U中全部属性,则为候选码成员;
在LR中取出另一个属性 循环进行这一过程,直到试完所有LR中的属性
4 然后在LR中依次取剩余属性中两个属性、三个属性....., 求它们的属性集的闭包,直到其R的全部属性被取完 结束准则1:如果某个属性A只在F中各个函数依赖的箭头左边出现,则A必是候选码中的属性。
准则2:如果某个属性A只在F中各个函数依赖的箭头右边出现,则A必不是候选码中的属性。
准则3:如果某个属性A既在F中某个函数依赖的箭头右边出现,又在其他函数依赖的箭头左边也出现,则A有可能是候选码中的属性。
准则4:如果某个属性A不在F的各个函数依赖中出现,则A必是候选码中的属性
根据这些准则,确定候选码的步骤是:
根据准则1,确定码中必有的属性(设为M)
先根据准则2,把不在F的各个函数依赖中出现的属性去掉;
根据准测3,去掉码中肯定没有的属性集;
确定余下的属性集(设为W)
从属性集M开始,令K=M,如果K+=U,K就是候选码。否则从
W中选择属性加入到K中,直至K+=U,K就是候选码。
注意可能有多个候选码。
模式分解
关系模式R(U,F)中,F是最小函数依赖集。
准则1:如果属性A只在F中各个函数依赖的左部出现,则A必是码中的属性;
准则2:如果属性A不在F中各个函数依赖中出现,则A必是码中的属性;
准则3:如果属性A只在F中各个函数依赖的右部出现,则A必不是码中的属性。属性只在左边出现, 为码中属性,主属性
属性只在右边出现, 非主属性根据这些准则,确定候选码的步骤是:
1. 先根据准则2,把不在F的各个函数依赖中出现的属性去掉;
2. 根据准则1,确定码中必有的属性(设为M)。
3. 根据准则3,去掉码中肯定没有的属性集;
4.确定余下的属性集(设为W)。
5.从属性集M开始,令K=M,如果K+=U,K就是候选码。否则从W中选择属性加入到K中,直至K+=U,K就是候选码。
6. 注意可能有多个候选码·kf+=U, k就是候选码
可能有多个候选码计算步骤:
fmin{ b-d, b-g, c-d, c-a, ce-b}
只在左边出现的 ce
只在右边出先的: 啊,的,g
余下属性: b
r候选码可能是:
例题1(码) :
解:
例题2 (闭包/最小依赖集):
解:
例题3(最小依赖集):
例题4(最小依赖集/候选码):
解:
闭包:
习题:
设计
需求分析
调研/调查
概念结构设计
设计E-R图
长方形: 实体
菱形: 联系名
椭圆: 属性(不可再分 , 不可与其他实体集 有联系 )
属性冲突( 学号 与 学生编号, 同一个属性,不同人命名不同 )无向边: -------确定: 实体 / 属性 / 联系( 供应商 供应 零件 )消除冲突冗余
联系:
m: n
问题
E-R图的概念模型
步骤
确定实体
画出该实体对应的属性,中间属性 及键(下划线标出)
确定各个实体对应的 联系 m:n
确定中间属性的联系
例题:
某企业集团有若干工厂,每个工厂生产多种产品,且每一种产品可以在多个工厂生产,每个工厂按照固定的计划数量生产产品;每个工厂聘用多名职工,且每名职工只能在一个工厂工作,工厂聘用职工有聘期和工资。工厂的属性有工厂编号、厂名、地址,产品的属性有产品编号、产品名、规格,职工的属性有职工号、姓名。
(1)根据上述语义画出E-R图;
(2)将该E-R模型转换为关系模型,指出转换结果中每个关系模式的主码和外码 (要求:1:1和1:n的联系进行合并)
E-R模型转换为关系模型(指出转换结果中每个关系模式的主码和外码)
(1)实体到关系模式的转换
1 实体型的转换:一个实体型转换为一个关系模式(带括号的形式)
根据联系间的某个实体 / 联系进行转换 ,转换为实体( 主码,属性 ... 另一个属性的外码 ) ; 另一个实体名( 主码, 属性....... ) / 联系( 实体主码, 另一个实体主码)
注意:m:n联系中, 对联系中的外键为 两个实体主码的组合关系模式的属性:实体的属性
关系模式的码:实体的码转换为
学生(学号,姓名,出生日期,所在系,年级,平均成绩)
1:1联系
1:n联系
m:n联系
(2)联系到关系模式的转换
逻辑结构设计
步骤:
将实体转换为关系模式
将联系转换为关系模式
去掉冗余
标出主外键( 主码下划线, 文字注明外码)数据模型
关系/非关系1:1 转换 关系模式
添加码到另一个关系的 实体中1:n
添加(合并)码 到 n关系的 实体中
特殊: 职工( ........ 领导 )m:n
取中
将联系做成一个独立的关系模式, 属性来自 m 和 n 中 ( 联合作为主码, 单独分别作为外码) 和 本身的属性
物理结构设计
放在哪个分区( 频繁/ 非频繁) , 索引
数据库实施
创建.....建表.....组织数据入库
试运行: 如选课系统, 三年左右
数据库运行和维护
售后: 性能检测/ 恢复.......
—————————————————————
以上就是今日博客的全部内容了
创作不易,若对您有帮助,可否点赞、关注一二呢,感谢支持.