复试篇--数据库学习

最新推荐文章于 2022-09-06 10:57:13 发布

KK的任意门

最新推荐文章于 2022-09-06 10:57:13 发布

阅读量626

点赞数 2

分类专栏：复试

本文链接：https://blog.csdn.net/kwb2015130086/article/details/105582178

版权

复试专栏收录该内容

12 篇文章 4 订阅

订阅专栏

关系数据库：

由表的集合构成，每一张表都有一个固定的名称
表中的每一列是一个属性，每一行代表这种类型的一个实体的信息

基本术语：
关系：代表一张表、
元组用来指代行、
属性指代表中的列
域：每一个属性的可能集合

码：

超码：一个或多个属性的组合，这些属性的组合可以使我们在一个关系中唯一标识一个元组。

候选码：超码中可能含有无关紧要的属性。若超码中的任意真子集都不能称为超码，这样的最小超码就叫做候选码

主码：被数据库设计者选中的候选码

外码：一个关系模式（r1）中包含另外一个关系模式（r2）的主码，则称这个属性是在r1上参照r2的外码

关系代数：

选择：选择满足特定条件的元组
投影：对所有行输出指定的属性，并去掉重复的
自然连接：从两个输入关系上输出元组对，元组队需要满足—属性名字相同的时候，内容也要相同
笛卡尔积：跟自然连接的区别是不管属性值是否一样

完整性约束：
SQL禁止破坏完整性约束的任何数据库更新

order by 默认使用升序，order by … desc/asc，desc表示降序，asc表示升序

字符串运算：
like ‘ab%cd%’ escape ‘’
escape 后面所加的字符作为转义字符

集合运算：
并运算：Union
交运算：intersect
差运算：except

空值的处理：
sql将涉及空值的任何比较运算的结果视为unknown

聚集函数：
平均值：avg
最小值：min
最大值：max
总和：sum
计数：count

分组聚集：将一些相同属性的元组划分成一个分组，如果没有使用group by，则整一个关系当做成一个分组
group by
使用规则：保证出现在select语句中但是没有被聚集（基本聚集）的属性只能是出现在group by子句的属性

eg:
select dept_name,id,avg(salary) from ** group by dept_name;
这样是错的，因为select 选择中含有id，但是只按照dept_name来分组，则一个分组中会含有不同的id，输出的时候不知道输出哪一个**(每个分组只输出一个元组)**

having:对分组进行筛选

eg:group by dept_name having avg(salary) > 42000

外连接：解决连接中，一个关系的属性在另外一个关系中完全没有出现的时候造成元组丢失的问题

视图：为了安全起见，只给用户提供视图，而不是数据的逻辑层面(视图在定义的时候才被创建)，也可以隐藏不必要的信息

eg:create view a as select id、name、dept_name from instruct

事务：sql标准规定，一条sql语句被执行，就隐式地开始了一个事务

commit work:事务提交
rollback work:事务回滚，即撤销该事物所有sql语句中对数据库的更新
事务回滚可以保持对数据库的操作的原子性

完整性约束：保证数据库的一致性

参照完整性：保证某个关系中的属性的值在另外一个关系中一定存在（利用外码的定义，但是不同于外码的是，不要求属性为另外一个关系的主码）

创建索引：
在关系的属性上创建的索引是一种数据结构，它允许系统高效地找到关系中那么在索引属性上取出给定值的元组，而不用扫描关系中的所有元组。
eg: create index student_id on student(id);

授权：SQL标准包括select、insert、update、delete权限

关系数据库设计：

第一范式：属性的域是原子的，不可分的（1NF）

函数依赖：如果存在关系（dept_name,budget）,则dept_name可以做为主码，这条规则可以被定义为函数依赖，记做：dept_name -> budget

BCNF:
函数依赖至少满足以下条件之一：
（1）a->b是平凡的函数依赖，即b是a的子集
（2）a是超码
eg:对于模式department(dept_name,building,budget)
这里的依赖dept_name ->(building buget)是一个非平凡函数依赖，因为（building,buget）不一定是这栋公寓的，不是dept_name的子集。但是dept_name是超码，所以也是属于BCNF范式。
ps:平凡的函数依赖要求b是a的子集

第三范式：比BCNF若一点的范式
条件：所有的函数依赖至少满足以下任一个条件
（1）与BCNF相同
（2）与BCNF相同
（3）b - a的每个属性都包含在R的其中一个候选码中

第四范式：多值依赖

通俗理解：

第一范式：就是原子性，属性不可再分。
解决办法：将属性再细分。

第二范式：消除非主属性对主码的部分函数依赖。
如果一个关系的主码是（A,B），C -> A、B , 称C是对主属性的完全函数依赖，D->A，则称D是对主码的部分函数依赖。
解决方法，将这个关系划分为两个关系，D和A独立作为一个关系

BCNF范式：
在3NF的基础上，加上消除主属性对主码的传递依赖关系（或者依赖关系）。3NF只检查非主属性对主码的传递函数依赖

总结：第一范式保证原子性、第二范式消除部分函数依赖、第三范式消除传递函数依赖，BCNF是更加严格的第三范式（规定了主属性的传递函数依赖）

参考链接：https://www.cnblogs.com/lca1826/p/6601395.html

事务:

引入事务的作用：
（1）提供数据库保持一致性的方法（数据库执行失败的时候可以回滚）
（2）当多个应用程序并发访问数据库时，可以提供对这些应用程序进程隔离的方法。

事务的特性：
（1）原子性：要么全部执行，要么都不执行
（2）一致性：满足完整性约束
（3）隔离性：一个事务不影响其他事务的执行
（4）持久性：一个事务一旦被提交，它对数据库的修改将永久保存在数据库中

索引和散列：

索引：是帮助引擎高效获取数据库数据的数据结构，因此。索引本质上是一种数据结构

索引项：
由一个搜索码和指向该搜索码值的一条或者多条记录的指针构成。指向记录的指针保罗磁盘的标识和磁盘块内的偏移量

稠密索引和稀疏索引：稠密索引为每一个记录都建立索引项，稀疏索引只为一部分（例如块）来建立索引项

解决索引文件过大的问题而造成只能将索引文件放到外存造成访问速度过低的方法：多级索引，将外层索引放到内存，内层索引放到外存。

B+树：
引入原因：随着文件的增大，索引顺序文件的查招性能会降低，虽然这种降低可以用文件重组来弥补，但是一般不希望进行频繁的文件重组。B+树索引结构会增加文件的插入和删除的性能开销，同时会增加空间的开销。

补充知识：
二叉查找树：左键值比跟键值要小，跟键值比右键值要小
平衡二叉树：
任何一个节点的两个子树的最大高度不超过一
平衡二叉树的查找速度很快，但是维护成本很高

平衡二叉树的查找速度是logN，但是为什么不用来作为索引的数据结构，而是用B树

答：平衡二叉树在物理结构上是用数组来存储的，逻辑上相邻的节点在物理上离的比较远。又因为索引结构一般是在磁盘中，所以这种结构的磁盘预读会读到很多不需要的数据，不符合局部性原理，造成磁盘读取的次数多，耗时长。
而B树的每个节点可以存储多个关键字，它将节点大小设置为磁盘页的大小，充分利用了磁盘预读的功能。每次读取磁盘页时就会读取一整个节点。也正因每个节点存储着非常多个关键字，树的深度就会非常的小。进而要执行的磁盘读取操作次数就会非常少，更多的是在内存中对读取进来的数据进行查找。
因此B数更加适合作为索引的数据结构。

B+数比B数更加适合来做索引的数据结构
B树：有序数组+平衡多叉树；
B+树：有序数组链表+平衡多叉树；

B+树的关键字全部存放在叶子节点中，非叶子节点用来做索引，而叶子节点中有一个指针指向一下个叶子节点。做这个优化的目的是为了提高区间访问的性能。（有利于扫库）而正是这个特性决定了B+树更适合用来存储外部数据。

数据库索引采用B+树的主要原因是B树在提高了磁盘IO性能的同时并没有解决元素遍历的效率低下的问题。正是为了解决这个问题，B+树应运而生。B+树只要遍历叶子节点就可以实现整棵树的遍历。而且在数据库中基于范围的查询是非常频繁的，而B树不支持这样的操作（或者说效率太低）。