一、数据模型的分类
1.1、概念数据模型
1.2、结构数据模型
1.3 真题
二、三级模式
概念模式对应的是基本表,概念模式也称为模式
外模式对应的是视图,也称用户模式或者子模式
内模式对应的是数据库里面的存储文件,也称存储模式
真题
三、两级映像
内物外逻
真题
四、关系代数
并、交、差、笛卡尔积
连接(join)
连接是在笛卡尔积的基础上进行连接
自然连接会去重,标记为
theat连接
等值连接
自然连接
左外连接
右外连接
全外连接
除(不考)
除数S是C和D两列,所以被除数R就不用看C和D,然后R中A,B去除重复行就是{a,b},{b,d},{c,k},这三个在R中的C和D和S的C和D分别进行对比,能对应的上就保留,不能对应上就去除,例如{b,d}只能对应{e,f},不能对应{c,d},所以{b,d}就去除掉
真题
查询效率的时候,先进行一个选择,再进行笛卡尔积
五、SQL语言
关系代数转SQL语言
选择和投影
笛卡尔积
自然连接
自然连接后,重复列去除,重新排序
笛卡尔积和自然连接有区别。自然连接要去掉重复列再排序,笛卡尔积不用去除,是全部属性排列
六、查询语句
DDL语言(数据定义语言)
DML(数据操纵语句)
DQL数据查询语言
1、投影查询
2、选择查询
3、排序查询
4、聚合函数
5、数据分组
当条件里面有聚合函数的时候不能用where 只能用having
where后面不能跟聚合函数,having后面跟聚合函数
6、表的连接查询
内连接
外连接
7、子查询
一般子查询
相关子查询
8、查询结果的并、交、差
真题
七、SQL控制语句
1、授予权限
grant [权限] on 库.表 to 用户 [with grant option]
with grant option # 允许将权限赋予其他人
2、收回权限
3、真题
八、视图
对视图进行增删改查实际是对实际表进行增删改查
对视图进行操作不必满足 where 条件,但查出来的数据仍需满足 where 条件
create view A as
select * from table_name where dept="计算机系" # 给视图插入数据且dept不一定为计算机系
insert into A values("jiali","计算机") # ok
insert into A values("Laptoy","软件工程") # ok
*[with check option]:*对视图进行操作必须满足 where 条件
create view B as
select * from table_name where dept="计算机系"
[with check option] # 给视图插入数据时dept一定为计算机系,否则报错
insert into B values("Laptoy","计算机") # ok
insert into B values("jiali","软件工程") # no
真题
九、索引
真题
十、关系模式,函数依赖,码,属性闭包计算
1、关系模式
2、函数依赖
非平凡的函数依赖
- X->Y,学号->姓名,学号决定姓名,但是姓名不包含于学号(Y不包含于X),所以是非平凡的函数依赖
- X->Y,(学号,课程号)->成绩 ,(学号,课程号)决定成绩,但是成绩不包含于(学号,课程号),所以是一个不平凡依赖
平凡的函数依赖
- X->Y,(学号,课程号)->学号 ,(学号,课程号)决定学号,学号包含于(学号,课程号),所以是一个平凡依赖
完全函数依赖
- X->Y,并且X的任何真子集都无法决定Y,那么Y对X完全函数依赖
- (学号+课程号)->成绩,学号或课程号都无法单独决定成绩,则称为完全函数依赖
- 如果不是组合函数,那么X->Y一定是完全函数依赖
部分函数依赖
- X->Y,但X的其一真子集可以决定Y,那么Y对X部分函数依赖
- (学号+身份证号)->姓名,学号或者身份证号都可以单独确定姓名
传递依赖:
- X->Y,Y->Z,那么Z对X传递依赖,X->Z可以忽略(冗余),员工->岗位,岗位->工资
3、码
简单说就是若候选码中的部分码能决定函数,那么选择该部分码作为候选码
4、属性闭包计算( 无法被决定的键一定是候选键)
额外补充
1.关系数据库系统: 支持关系模型
2.关系:一个关系=一张二维表
关系名=表名
3.元组:表的一行
4.属性:每一列的第一行,如性别
5.域:属性的取值范围,如男女
6.关系模式:对关系的描述
由关系名和其属性集合构成
码=键
7.候选码(候选键):任一候选键的任何真子集都不能唯一标识一个记录(比如在成绩表中(学号,课程号)是一个候选键,单独的学号,课程号都不能决定一条记录)
8.主码(主键):从多个候选码中选择一个作为主键
9.主属性:包含在任何候选码中的属性,如学号
10.非主属性:不包含在所有候选码中的属性,如姓名、成绩
11.外码(外键):比如在选课表中,学号不是主键,但在学生关系中它是主键
12.全码:所有属性都是候选码
13.超码:主属性和非主属性的组合,如(学号,姓名)
真题
无法被决定的键一定是候选键,比如本题A无法被决定,那么候选键中必定有A
主属性是指候选键包含的属性那就是主属性,例如上面的AC和AB为候选键,那主属性就有ABC
本题A无法推出所有,那么
AB->ABC
AC->ABC
所以ABC都是主属性
AE无法被其他键决定,所以AE必为候选关键字
十一、范式
1、1NF 第一范式(属性原子化)
强调属性的原子性约束,要求属性具有原子性,不可再分解。存在部分函数依赖
举例:
学生表(学号、姓名、年龄、性别、地址)。因为地址可以细分为国家、省份、城市、市区、街道,那么该模式就没有达到第一范式。
第一范式存在问题:冗余度大、会引起修改操作的不一致性、数据插入异常、数据删除异常。
2、2NF 第二范式(消除部分函数依赖)
第二范式,强调记录的唯一性约束,数据表必须有一个主键,并且没有包含在主键中的列必须完全依赖于主键,而不能只依赖于主键的一部分。存在传递函数依赖
举例:
版本表(版本编码,版本名称,产品编码,产品名称),其中主键是(版本编码,产品编码),这个场景中,数据库设计并不符合第二范式,因为产品名称只依赖于产品编码。存在部分依赖。所以,为了使其满足第二范式,可以改造成两个表:版本表(版本编码,产品编码)和产品表(产品编码,产品名称)
3、3NF 第三范式(消除传递函数依赖)
第三范式,强调数据属性冗余性的约束,也就是非主键列必须直接依赖于主键。也就是消除了非主属性对码的传递函数依赖。
举例:
订单表(订单编码,顾客编码,顾客名称),其中主键是(订单编码),这个场景中,顾客编码、顾客名称都完全依赖于主键,因此符合第二范式,但顾客名称依赖于顾客编码,从而间接依赖于主键,所以不能满足第三范式。如果要满足第三范式,需要拆分为两个表:订单表(订单编码,顾客编码)和顾客表(顾客编码,顾客名称)。
说明:3NF的模式肯定满足2NF。产生冗余和异常的两个重要原因是部分依赖和传递依赖。3NF模式中不存在非主属性对码的部分函数依赖和传递函数依赖,性能较好。1NF、2NF一般不适合作为数据库模式,通常需要转换为3NF或者更高级别的范式,这种变换过程称为关系模式规范化处理
4、BCNF范式(消除主属性对候选码的部分和传递依赖)
属于修正的第三范式,是防止主键的某一列会依赖于主键的其他列。当3NF消除了主属性对码的部分函数依赖和传递函数依赖称为BCNF。
特性:
1、所有主属性对每一个码都是完全函数依赖
2、所有主属性对每一个不包含它的码,也是完全函数依赖
3、没有任何属性完全函数依赖与非码的任何一组属性
举例:
库存表(仓库名,管理员名,商品名,数量),主键为(仓库名,管理员名,商品名),这是满足前面三个范式的,但是仓库名和管理员名之间存在依赖关系,因此删除某一个仓库,会导致管理员也被删除,这样就不满足BCNF。
5、4NF 第四范式
非主属性不应该有多值。如果有多值就违反了第四范式。4NF是限制关系模式的属性间不允许有非平凡且非函数依赖的多值依赖。
举例:
用户联系方式表(用户id,固定电话,移动电话),其中用户id是主键,这个满足了BCNF,但是一个用户有可能会有多个固定电话或者多个移动电话,那么这种设计就不合理,应该改为(用户id,联系方式类型,电话号码)。
说明:如果只考虑函数依赖,关系模式规范化程度最高的范式是BCNF;如果考虑多值依赖则是4NF。
6、5NF 第五范式
第五范式属于最终范式,消除了4NF中的连接依赖,第五范式需要满足以下要求:
1、必须满足第四范式
2、表必须可以分解为较小的表,除非那些表在逻辑上拥有与原始表相同的主键。
一般实际应用中不必考虑第五范式。
6、规范化步骤
7、判断部分函数依赖技巧
8、判断传递函数依赖技巧
其实也就是若X->Y,且WY->Z,那么其实这个WY(X)->Z,相同(伪传递率)
9、真题
对于上题中第三问解析:
10、关系分解
11、无损连接和保持函数依赖
12、真题
十二、数据库设计
1、需求分析
2、E-R图
真题
3、概念设计
4、逻辑结构设计
十三、事务管理
十四、数据库备份与恢复
十五、封锁
十六、分布式数据库
十七、杂题