软件设计师备考笔记（四）数据库系统（重点）

林三的计算机

已于 2023-02-13 23:12:22 修改

阅读量202

点赞数 2

分类专栏：软件设计师备考笔记文章标签：数据库数据仓库软件工程

于 2023-02-12 20:45:03 首次发布

本文链接：https://blog.csdn.net/weixin_45975667/article/details/128999491

版权

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

18 篇文章 3 订阅

订阅专栏

文章详细阐述了数据库设计的不同阶段，包括ER模型在需求分析和概念结构设计中的作用，关系代数的操作，依赖关系的类型，以及规范化理论的重要性。同时，提到了数据库的模式，如物理模式、内模式、概念模式和外模式，强调了它们在数据库管理和安全性中的角色。此外，还讨论了并发控制中的事务特性和封锁协议，以及数据库的完整性约束和数据仓库的基本概念。

摘要由CSDN通过智能技术生成

数据库模式

三种模式的关系

物理数据库：表现形式就是一个文件，如sqlserver的mdf文件是数据库文件；
内模式：直接关联物理数据库，管理如何存储数据，什么格式，如何优化
概念模式：数据库中，表这一个级别。
外模式：数据库里面的视图(select等)，对数据控制有了更进一步的手段，更灵活的处置方式
- 平时使用的sqlserver2008等就是管理物理数据库的软件，是内模式、概念模式、外模式的总和；

三种模式之间的联系

外模式-概念模式映射： 表和视图的关系； 将概念模式（表）进行处理后再发送出来；外模式（视图）看到的往往不是数据库内部的表；
- 作用：
  - 安全性：概念模式中，有用户信息，包含账号密码等，如果任何一个模块都能调用用户的所有信息，可能不是很安全。
  - 拓展封闭原则：（应用程序直接调用表的情况下）如果不适用映射那么概念模式的表发生了变化那么应用程序也要跟着变（前端布局等都需要改变）；
- 实例：
  - 加了外模式则能对表处理完后再返回给应用（登录时只给账号密码的视图，查询信息时不给账号密码等关键信息）
  - 概念模式把一张表分成很多分，通过外模式也能返回成一张表的视图。
概念模式-内模式映射：表和存储形式的映射关系；
- 作用：
  - 存储结构改变时（算法优化等情况），调整映射关系就行，不用修改用户的应用程序和表等东西就能应对这样的变化。

ER模型

数据库设计过程

不同阶段的产物与作用

需求分析：数据流图、数据字典、需求说明书
概念结构设计：ER模型
- 数据库设计其实是从概念结构设计开始的。
- ER模型：和数据库管理系统无关，可以转换成不同数据库；如sqlserver、mysql
逻辑结构设计产出物：关系模式
- 将ER图转换为文字表达的一个一个表的形式；涉及规范化理论
物理设计：结合DBMS（数据库管理系统）建立实体数据库；

ER模型的使用方法

矩形表示实体
菱形表示两个实体之间的联系
- 即使是1对1的两个实体之间也写明联系
椭圆表示实体属性

设计时，往往时分析每一个局部怎么绘制，然后局部合成成全局

ER模型的集成方法

一个系统中往往有多个模块，不同模块有不同的实体；实体之间关系复杂；
逐步集成：简单，不容易出错，耗时。
一次集成：可能有些问题无法发现，开发时引起问题

ER图集成常见问题

属性冲突：两个局部系统都涉及到老师，优点系统设置性别为男女，有些为01；
命名冲突：
- 同名异义：名字相同表达的意思不同
- 异名同义：老师在学生表中写为教师，在职工表中写为职工；
结构冲突：不同抽象级别，老师既是一个表也是另一个表的一个字段；

例题

答案：4个

注意事项

一对多时放在多
一对一时随便放
三个实体多对多联系时可以使用一个关系模式表示。
- 即，三个实体间的联系可以使用一张表来表达

关系代数

S1在前S2在后的公式下；

并：S1和S2相加
交：S1和S2都有的
差：S1有S2没有的
笛卡尔积：S1的每一行都和S2的每一行相联接；
- 例：S1有a行n列，S2有b行m列；
  - 则形成的笛卡尔积表为；a*b行，m+n列
  - 重复列名时不忽视重复列名
投影：筛选出表中的哪些列；（单表处理代数）
- π 1,2(S1)表示选出S1表的第一列和第二列
- π Sno,Sname(S1)表示选出S1表的Sno列和Sname列
选择：筛选出表中的哪些行；（单表处理代数）
- δ1=No001(S1)选出S1表中第一列No001的行
- δSno=No001(S1)选出S1表中Sno列为Bo001的行
联接：将两个表根据条件行和行联接起来
- |><| (S1.Sno=S2.Sno)，表示将S1和S2联接，联接条件为Sno相等
  - 条件应该写在下方
  - |><|实际上是两个角连在一起的三角形
- 注意事项
  - 连接不写条件时：默认就是两表的相同字段等值连接
  - 但连接后，做投影时，还是要算有两个相同字段，即想要sno Sname age三个字段时，是125而不是124，因为Age前实际上还是有Sno只是被隐藏了
- 和笛卡尔积区别：
  - 联接时都有的字段（列）只保留一个
  - 笛卡尔积没有条件，所有两边表的行互相联接；而联接是只有在条件满足的行才联接；

依赖关系

函数依赖

前置知识

属性集：系统将涉及到的所有事物抽象出它们各自的属性；所有事物的所有属性的集合就是属性集；
- 属性集能转换为关系模式，进而转换为物理设计；
关系模式：对属性集里的所有属性进行归类和并添加对象之间的联系，从而形成的能表达数据库表间关系及表内属性关系的文字描述；
- 例子：下面四行是一个关系模式中的四个关系；
  - 学生(学号，姓名，性别，班级，出生日期)
  - 班级（班级号，班级名）
  - 选课（学生编号、选课编号、课程编号）
  - 课程（课程名称、课程编号）
关系：关系模式中的一个表的文字描述；
元组：一行数据，表示一个具体人或事的抽象；

辅助理解

X和Y是子集表示，X和Y可能是一个字段，也可能是多个字段的集合；
x能确定唯一y时不能说y确定x
- 例：学号能确定唯一姓名，姓名不能确定唯一学号；
U是一个属性集合，而不是属性、ppt表达错误；
R(U)表示的是U形成的关系模式；
X和Y表示两个字段；
r表示为一张表；
u、v表示一行数据；

依赖关系解析

只要有u[X]=v[X]，就有u[Y]=v[Y]
- 即：只要学号相同，那么名字一定相同；
一个具体对象的部分抽象属性集（A）能推该对象的另一部分抽象属性集（B）
- 则称B依赖于A
- A决定B
依赖关系时属性集（X和Y）之间的关系
- 但是使用具体对象的属性（u[X]、v[X]、u[Y]、v[Y]）来判断是否满足依赖关系
Y依赖于X时，X不依赖于Y；
- 学号可以退出唯一的姓名，但姓名不一定能退出唯一的学号；

部分函数依赖

前提：只要有u[X]=v[X]，就有u[Y]=v[Y]
- 即：两个属性集合之间有依赖关系
含义：设Z是X属性集的任意子集，若存在u[Z]=v[Z]时，就有u[Y]=v[Y]则称Y部分依赖于X
例子：
- 虽然（学号，课程号） -->姓名
- 但是学号 -->姓名也是成立的，即只用学号也能推出姓名
- 则姓名部分依赖于（学号，课程号）

传递函数依赖

概念：当A–>B，且 B–>C 时能得到A–>C的结论；
注意事项： A<–>B 不能AB互推，否则称AB为等价，等价时不存在传递性的说法

规范化理论

知识引入

价值和用途

解决数据冗余、更新异常、插入异常、删除异常等非规范话关系模式中常见的问题；

解决的问题

前提：DNO和DNAME、DNAME和LOCATION具有一一对应的关系
- 即：一个系必定只在具体的一栋楼
数据冗余
- 计算机系和一号楼重复出现了多次，其实有计算机系就一定能知道是1号楼；
- D01和计算机系页重复出现了多次，有D01就一定知道是计算机系
更新异常：给计算机系改名是，必须改所有计算机系，不然就会异常；
插入异常：新开一个学院，该学院还没有学生，那么无法开设新学院；
删除异常：学生全部删除后该系和该楼也消失；

反规范化

设计时，往往提升一项指标就会降低另一项指标
- 如：如提升安全性往往意味着降低性能；
规范化理论：降低冗余异常
反规范化理论：增加冗余

超键、候选键、主键、外键

都是在关系（表）层面上的
超键：能唯一表示一个元组的一个属性集，该集合可能存在冗余属性（部分依赖）；（知道是啥就行，不考）
- 元组：表中的一个对象（一行数据）
候选键：没有属性冗余的超键；
- 例子：学号姓名性别中学号是候选键但是(学号、姓名)只是超键
主键：候选键中选一个当成主键；
- 一张表只有一个主键
外键：别的关系的主键（表明两个对象的联系）

求候选键

有向图法

前提
- 入度：有向图中的一个结点被箭头指向的数量
- 初读：有向图中从该结点指出去的数量
将关系中所有属性画成有向图；
- 有向图中的箭头表示依赖关系；
- 要分清楚依赖关系中是集合还是单一属性的依赖
找到入度为0的属性，以该属性为结点遍历有向图
- 若能遍历所有结点，则该属性即为关系模式的候选键
- 若不能遍历所有结点，则尝试添加其他结点（有入度也有出度的结点）并入入度为0的属性集合；
  - 再次遍历，若能遍历成功则为候选键，
  - 否则重复添加和遍历的过程，直到能遍历所有结点；

例题

列题1

答案：A1

例题2

答案：ABCD

例题3

答案：A和B

范式

每个范式都是在前一个范式的基础上形成的；
规范化越高，数据的粒度越小；粒度小的时候性能差

范式的分类

第一范式：属性值都是不可分的原子值；
第二范式：消除非主属性对候选键的部分依赖；
- 主属性：包含在任一候选码中的属性称主属性。简单来说，主属性是候选码所有属性的并集
- 如何消除部份依赖？
  - 将该非主属性和其依赖的主属性才分为一个新关系；
  - 原关系中仍保留被拆分出去的主属性
第三范式：消除非主属性对候选键的传递依赖；
- 如何消除传递依赖？
  - 若存在一个关系（A、B、C），且A–>B；B–>C；此时A为主键且存在非主属性对候选键的传递依赖；
    - 此时将B和C拆分为一张新表；A和B拆分为一张表可以满足第三范式；
BC范式：消除主属性对候选键的传递依赖

如何判断是否满足该范式？

第一范式

不满足：高级职称人数字段可拆分；
将高级职称人数这个表头删除即可满足；
- 即：以教授和副教授来做字段，而不是高级职称人数；

第二范式

前提：CREDIT（学分）指的是该课程的学分，而不是该学生得到的分数；
不满足：
- 学号和课程才能确定成绩，所以（学号，课程）是主键
- 但学分只需要知道课程就能知道，所以有部分函数依赖
导致的问题：
- 数据冗余，更新异常（全部记录要一起更新），
- 插入异常（无法开设新课程，没人选的课程无法保存）
- 删除异常（学生毕业后，删除学生则课程也消失）
解决方法：课程号和学分拆出来当一张新表；

第三范式

单属性主键一定是第二范式（不可能有部分依赖）
不满足第三范式：
- 学号能推出专业号，专业号能推出系别和楼号；
- 存在传递依赖；
问题：数据冗余（计算机系和1号楼）、更新异常、插入异常、删除异常
解决方法：
- 把dno dname location拆成一张新表出来

BC范式

前提：依靠消除主属性对于候选码的依赖来判断是否达到BC范式其实不好判断；
- 所以改为根据概念分析；
概念：一个关系里面，所有依赖关系的左边部分都是是候选键。
STJ是否满足第三范式？
- 找候选键
  - 入度为0的只有S，但S推不出T，所以SJ是一个候选键；
  - S和T也能推出J，所以ST也是候选键；
- 找出主属性
  - STJ都是
- 是否满足1、2、3范式？
  - 第二范式是消除非主属性对候选键的部分依赖，第三范式是消除非主属性对候选码的传递依赖
  - 但是根本没有非主属性，因此满足第三范式；
- 找出所有依赖关系
  - ST–>J;
  - SJ–>T;
  - t–>J;
- 判断是否所有依赖关系的左边都是候选码，从而判断是否是BC范式
  - T–>J的左边不是候选码
  - 所以该关系模式不满足BC范式

例题

模式分解

例子

R(A、B、C)其中，A–>B;B–>C
若将R分解为，R1(A、B)、R2（B、C）
- 则两个函数依赖都保存了，是无损分解
若将R分解为，R1(A、B)、R3(A、C)
- 则丢失了B–>C这一函数依赖，是有损分解；

模式分解的题型及其解决方法

是无损分解；

表格法

表格含义
- 列出来的二维表实际上就是将拆分的后表尝试进行联接还原的过程
- 左列为关系模式的名字；上方表头为字段
- 每个格子表示的是，该关系模式是否包含该字段；
  - 若有则用a表示，后面接该字段所在的位子（学号1、姓名2、课程号3……）
  - 没有则用b表示，后街该各自所在的坐标
计算方法
- 设A行有一对相连的a1，a2，且B行有a1，b(ij) 相连时；
  - 那么可以把B行的b(ij)换为a2
- 从第一个字段开始，直到最后一个字段，按照上面步骤处理
- 若有某行的全为a则证明这是无损分解；