【软考笔记——软件设计师】（四）数据库 (上午题 + 下午题试题二)

CptHimself

已于 2022-10-16 17:50:22 修改

阅读量2.4k

点赞数 5

分类专栏：软考笔记——软件设计师文章标签：数据库 mysql sql

于 2022-09-22 10:35:46 首次发布

本文链接：https://blog.csdn.net/weixin_49486457/article/details/126859120

版权

软考笔记——软件设计师专栏收录该内容

15 篇文章

订阅专栏

文章目录

下午题做题总结
- 问题一
- 问题二
- 问题三
- 问题四
概念数据模型 (看看就行)
- 关系模型 (主要)
三级模式结构
两级映像
关系模型的基本术语
完整性约束
- 关系代数符
- 集合运算符
- 连接 Join
- 逻辑运算符
关系代数转SQL语句
- 投影状SQL语句
- 选择转SQL语句
- 笛卡尔积转SQL语句
- 自然连接转SQL语句
SQL语句
- SQL语句的分类
- 数据定义语句（DDL）
- 数据操纵语言（DML）
- 数据查询语言（DQL）
- 数据控制语言（DCL）
- 视图
- - 视图的创建与删除
索引
- 关系模式
关系数据库的规范化
- 函数依赖
- 码和推理规则
- 属性的闭包运算 (求主键）
范式
- 第一范式
- 第二范式
- 第三范式
- 总结
- 做题技巧
- - 例题
- 关系分解
数据库设计
- 需求分析
- E-R图 (实体 - 联系 - 属性)
- 习题
- 逻辑结构设计
控制功能
- 事务管理
- 数据库的备份与恢复
- 并发控制技术
- 分布式数据库

**备考软件设计师中级ing, 范式那个部分是真的绕 QAQ
**

下午题做题总结

问题一

问题一就是补全图中缺失的部分
看题目描述那种一个对多个 or 多对多 or 一对一（一：用数字1 写在线上即可多：* 这个符号写线上，中间的菱形写动作的名字如果题目有改写为联系1 or 联系2 则写联系x）

问题二

就是写缺失的候选码：找信息里面的补上，再看该实体是否与其他实体有联系，则要加上另外一个实体的主键作为该实体的外键约束
主键和外键的区别：
主键看原文 + 看题目描述如果出现xx和xx唯一识别xxx 则这多个主键和另外的外键需要一起(xx,xx,xx) 作为主键否则就只有一个主键
外键就是相对于主键的其他外键

问题三

题目要求补上缺失的“弱实体” 则要去图中画上实体以及联系，修改"实体"的关系模式：就是在实体的候选码中增添码，并且修改为主键约束 or 外键约束（主键约束是______ 外键约束是 _ _ _ _ _ ）

问题四

多背那些错误冗余什么的

概念数据模型 (看看就行)

在这里插入图片描述

层次模型：树结构
网状模型：图结构

关系模型 (主要)

在这里插入图片描述

三级模式结构

外模式 （也称子模式or用户模式）对应外部视图
概念模式（也称模式）对应对应DMBS(数据库管理系统)中的基本表
内模式 （也称存储模式）对应数据库里面的 存储文件

两级映像

在这里插入图片描述

关系模型的基本术语

码 == 键
这个主属性的描述有问题，其实说白了就是所有候选键都是主属性，其他都是非主属性
元组就是表中一行数据，属性就是表中的列表名称

完整性约束

在这里插入图片描述

关系代数符

在这里插入图片描述

集合运算符

在这里插入图片描述

投影和选择的符号别搞混淆
投影默认第i列下标映射为数值i
选择就是选中符合条件的指定的行然后把它们拼在一起组成新的关系
表示查找的值需要用单引号括起来，如果是数字的话就表示行的关系
加上其他符号 or and …

连接 Join

符号

θ连接西塔

在这里插入图片描述

连接其实就是在两个关系的笛卡尔积中选择符合条件的行**，而上面这种连接其实就是用比较运算符来进行比较**

这上面的字母比较是比较26字母先后顺序

等值连接

等值连接就是笛卡尔积中某一列和另外一列相等就符合要求，然后选择出来就行了

自然连接

在这里插入图片描述

自然连接的条件是看有哪些公共的属性（其实就是列名一样），像上图明显A和C是两个关系中都有的公共属性，所以就是在笛卡尔积中找R.A=S.A并且R.C=S.C（也就是两个关系职中A和C必须同时相等才是符合要求的，如果有三个公共属性，那么这三个公共属性要求在两个关系中都相同，以此类推），符合这个条件的就找出来

左外连接

在这里插入图片描述

右外连接

在这里插入图片描述

全外连接

全外连接是自然连接的结果加左右外连接的结果

逻辑运算符

这里与和或是用来连接上面选择或者投影的条件的连接词，与就是and，或就是or，或只要两边条件有一方满足就可以了

关系代数转SQL语句

投影状SQL语句

在这里插入图片描述

选择转SQL语句

在这里插入图片描述

笛卡尔积转SQL语句

在这里插入图片描述

自然连接转SQL语句

先把它的关系代数变形为上面等价的笛卡尔积表达式，然后在转SQL

SQL语句

SQL语句的分类

在这里插入图片描述

数据定义语句（DDL）

1、建立数据库

create datebase 数据库名

2、建立基本表

3、修改基本表结构

alter table test modify f3 float ;

修改不是指的修改列的表名，而是指的修改列的类型，一般用上面modify来进行修改
primary key是主键约束（功能和not null unique 一样）
foreign key是外键约束（上面的外键约束语句意思是对sid设置外键约束并且参照S表中的sid）
check 是用户自定义完整性约束（上面语句意思是检查成绩是否在0-100范围内，也就是在表中插入数据的时候成绩这一列会有一个自动检查成绩范围的约束，不在这个范围就会报错）

数据操纵语言（DML）

在这里插入图片描述

数据查询语言（DQL）

在这里插入图片描述

投影查询

在这里插入图片描述

选择查询

在这里插入图片描述

排序查询

在这里插入图片描述

注意上面红色画出来的语句不是说课程号和分数都是降序排列，这里课程号没有指明是什么排序，那就是默认的升序，分数指明了是降序排序，但是这里是多条件排序，所以是先按课程号进行升序排序，如果课程号相同，那就按分数降序排序

聚合函数查询（注意聚合函数只会返回一个结果值）

在这里插入图片描述

上面这句是验证分数的平均值，也就是AVG集合函数
- 指的一提的是上面这样写是没问题的，可以进行加减乘除运算（这是我的知识漏洞）
  同时要注意count（*）和count（列表名）的区别，区别就是count（*）会把null也算作一个值，会把null这条记录进行统计，而count（列表名）就直接忽视null的记录，不会把这条记录进行统计。

在这里插入图片描述

这是查询课程号的数量并且去重
数据分组

分组后
所谓的分组就是把属性值相同的分为一组，例如上面是按课程号分组的，那么课程号中相同的值就会被分作一组，分组主要用于聚合函数查询只能返回一个值，如果想看具体的情况就使用分组
这里要注意having和where的使用区别，区别就是如果拼接的条件里用到了聚合函数，那就只能用 having ，不能用where！

内连接

在这里插入图片描述

非等值连接

在这里插入图片描述

自连接

在这里插入图片描述

外连接

在这里插入图片描述

子查询（先子查询再主查询）

在这里插入图片描述

数据控制语言（DCL）

SQL访问控制

视图

视图的创建与删除

在这里插入图片描述

如果插入的不满足条件的话，那么就会插入失败不显示。
with check option 就是用来判断是否操作成功的，如果去修改原视图的判断(where) 语句的内容就会报错， 如果加了with check option的话就意味着这个视图的增改删操作必须要满足where 后面的条件才可以进行操作，不然就会报错

索引

在这里插入图片描述

关系模式

因为通过单个关系是没办法确定一个元组 , 因为内容不唯一性。
这里的箭头可以理解为决定的意思，例如学号—>姓名，可以理解为学号决定姓名

关系数据库的规范化

函数依赖

真子集

完整函数依赖就是一个组合里的任何真子集不能够决定依赖关系，例如（学号，课程号）----->成绩这是一个组合关系的函数依赖，表示学号和课程号两个一起决定成绩，这其中任何子集不能单独来确定这个依赖关系，例如学号不能单独决定成绩，课程号也是不能单独决定成绩，这就是完整函数依赖，如果不是一个组合，就是一一对应的函数依赖关系那一定是完整函数依赖，例如学号---->姓名这样的就是完整函数依赖，它不是一个组合，（学号，课程号）----->成绩这样的才是一个组合，这里还要理解真子集的含义，例如（A，B，C）的真子集有（A）,（B）,©,(A,B),(A,C),(B,C)跟数学里的概念是一样的部分函数依赖就是一个组合里任意真子集能够决定依赖关系，例如（学号,课程号）---->姓名这个组合关系的函数依赖中，单一个学号就能够决定姓名了，也跟就不需要课程号，所以这就是部分函数依赖。

码和推理规则

如果只有一个候选键那就是主键，有多个候选键那就挑一个做主键

属性的闭包运算 (求主键）

如果包含 u 里面的全部元素，则为闭包
技巧直接看 F中箭头右边所有存在的字母一般不存在的就为主键然后就是各种尝试
做题技巧：但凡出现在箭头右边的都不可能是候选键，例如上面这题箭头右边有B和C，那直接排除，剩下一个A，也就是这个A一定是候选键或者候选键中一定要有A，然后发现A不能单独推出U，所以就试一下AC和AB能不能推出
然后主属性是指候选键包含的属性那就是主属性，例如上面的AC和AB为候选键，那主属性就有ABC
上图蓝色就为主键 红色为推出来的内容

范式

在这里插入图片描述

第一范式

在这里插入图片描述
上面这个是不符合第一范式，因为它的工资可以再进行细分，要符合第一范式那就变成下面这样就可以了

第一范式说白了就是看属性列表能不能在继续分，能继续分那就不符合第一范式
然后第一范式会有数据冗余和更新异常（包括修改，删除，插入异常）这些问题并存在部分函数依赖
数据冗余容易理解，例如上图画出来的可以看出是内容是一样的，那就重复了很多次这就是数据冗余
更新异常中的修改异常，好比修改红色框中的张三为张四，那就必须把所有的张三都改成张四，如果只改一条就会出现问题，查询学号为001的数据的时候那姓名可能是张三也可能是张四，这就是修改异常
更新异常中的删除异常，好比删除高等数学这个课程名，但是上面这个表中要删除高等数学这个课程名那整一条数据都会被删除掉，也就是孙七这条记录都删除了，而我只是想删除这个课程，这就是删除异常
更新异常中的插入异常，好比我只是想要插入一个学生的信息是插入不成功的，因为上面这个表中主键是学号和课程号，由于主键的完整性约束，不能为空或部分为空，无论是单独插入学生信息还是单独插入课表信息都是插入失败，必须两个都插入才能成功，这就是插入异常

第二范式

在这里插入图片描述

在这里插入图片描述
第二范式是在第一范式的基础上解决了部分函数依赖的问题得来的，第二范式要求每个非主属性都完全依赖于候选键，上面的例子中候选键是学号和课程号，所以学号和课程号都是主属性，其他的都是非主属性，例如姓名是非主属性，由于姓名是由学号决定的，跟课程号毫无关系，所以姓名只是部分依赖于候选键，因此不符合第二范式的要求，但是符合第一范式。在这里插入图片描述

在这里插入图片描述

前面说的那个例子符合第一范式不符合第二范式，只要消除了部分函数依赖就能够转为第二范式，往往都是通过分解关系来实现消除部分函数依赖的，例如上面的把前面的关系分解成三个关系后就都满足于完全函数依赖（也就是把一个表分解为三个表），所以它是符合第二范式的.
在这里插入图片描述

第二范式只是解决了第一范式的部分函数依赖问题，但是数据冗余和更新异常没有完全解决，因为存在传递函数依赖，例如上面的学号–>学院，学院–>院长，得出学号–>院长

第三范式

**第三范式是在第二范式的基础上，并且消除了非主属性的传递依赖问题得到的，**原来学号–>学院，学院–>院长，得出学号–>院长这是传递依赖，一般把后面的那个关系直接给拿出来单独作为一个关系，例如这个传递依赖中把后面的学院–>院长从原来的关系中抽离出来作为一个新的关系就可以解决传递依赖这个问题了（把学院设置为主键） 第三范式只是解决了第二范式的传递函数依赖问题，但是数据冗余和更新异常没有完全解决，因为存在主属性对候选码的部分依赖和传递依赖
例如上图就是存在主属性对候选码的部分依赖这个问题，在F函数关系依赖中，红色画出的就是存在主属性对候选码的部分依赖的问题，因为候选码是（书店和图书）。而它书店就能够推出店长，跟图书没啥关系，所以存在部分依赖

总结

在这里插入图片描述

2、判断非主属性是否对候选键存在部分函数依赖，说白了就是看非主属性能不能只靠候选键的一部分就可以推理出来（靠候选键组合中任意一个主属性就可以推出那个非主属性的就不是第二范式，但是如果是组合中其中一个和其他非主属性组合在一起推出非主属性的那就没问题）
3、看有没有传递依赖，存在传递依赖不符合第三范式
4、看主属性对候选码有没有传递依赖或部分依赖，也就是主属性可以由候选码中任意一个就推出来那就不符合BCNF范式
5、看有没有多值依赖，并且多值依赖的左边是码，例如A->B,A->C,并且A是码，那就符合第四范式