SQL笔记——数据库系统导论（数据库的设计）

数据依赖

基础
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
如:（ｓｎｏ，ｃｎｏ） 决定  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-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-b

2. 因为 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 中 ( 联合作为主码,  单独分别作为外码)  和 本身的属性

物理结构设计

放在哪个分区( 频繁/ 非频繁) , 索引

数据库实施

创建.....建表.....

组织数据入库
试运行:  如选课系统, 三年左右

数据库运行和维护

售后: 性能检测/ 恢复.......

 
 
—————————————————————
以上就是今日博客的全部内容了
创作不易,若对您有帮助,可否点赞、关注一二呢,感谢支持.