章节概述

数据库模式

数据库的三级模式两级映射
程序员和用户只需关注用户视图部分(外模式)
内模式对应数据库的存储文件(数据物理存储)

关系表也称为关系模式,关系模型,简称关系

物化视图在实际应用中比较容易想到是需要大量展示统计类信息的时候(比如展示表条目数量、表数量),通过物化视图可以快速查询到对应统计结果(统计结果改变只会发生在添加数据一种情况下,因此满足 多查询少更新 的情况)
分布式数据库
分布式数据库是相对于集中式数据库来说的,像我们平时使用的 Oracle、SQLserver 都是集中式数据库,数据物理保存在同一个物理节点上


与数据库常规的三级模式相比,这里概念模式分为了全局和局部的概念模式 (外模式只有全局外模式,内模式只有局部内模式)


“透明”这里的意思是类似黑盒,用户(程序员)不需要关心其实现,数据库管理系统自行完成。


D “整体”即需要全局控制,排查AC。“逻辑结构”即概念模式(概念模型就想到ER图,ER图描述的就是联系,即逻辑结构)。
分片模式体现的是数据如何切割,分布模式体现的是数据如何放置,全局外模式体现的是用户视图(用户看到的外模式结构)

这是一道关于分布式数据库基本概念的选择题。题目询问的是哪个选项代表了“局部数据模型透明”的概念,即用户或应用程序无需知道局部场地使用的是哪种数据模型。
首先,我们来分析每个选项:
A. 分片透明:分片透明主要关注的是数据如何在不同的节点或分片之间分布,它并不直接涉及用户或应用程序对数据模型的了解。
B. 复制透明:复制透明是指系统能够自动处理数据的复制,以确保数据的一致性和可用性,但它同样不关注用户或应用程序对数据模型的具体了解。
C. 位置透明:位置透明意味着用户或应用程序无需知道数据具体存储在哪个物理位置,这虽然与数据的访问和存储有关,但并未直接说明用户无需知道数据模型。
D. 逻辑透明(在这里也可以理解为“局部数据模型透明”):这个选项直接对应了题目中的描述,即用户或应用程序无需知道局部场地使用的是哪种数据模型。这是分布式数据库设计中的一个重要目标,旨在简化数据的访问和管理,使用户或应用程序能够以统一的方式处理数据,而无需关心数据在底层的具体实现方式。
因此,答案是 D逻辑透明。
解析:在分布式数据库中,逻辑透明(或局部数据模型透明)是指用户或应用程序无需了解数据在底层是如何组织、存储和管理的,包括使用何种数据模型。这种透明性简化了数据的访问和处理过程,使得用户可以更加专注于应用程序的逻辑实现,而不是底层的数据存储细节。

这是一道关于分布式数据库两阶段提交协议的选择题。我们需要从给定的选项中选择出两阶段提交协议中正确的两个阶段。
首先,我们来分析每个选项:
A. 加锁阶段、解锁阶段:这两个阶段并不直接对应于两阶段提交协议的标准流程。在两阶段提交协议中,主要关注的是事务的提交或回滚决策,而不是简单的加锁和解锁操作。
B. 获取阶段、运行阶段:这两个阶段同样不是两阶段提交协议的标准阶段。获取阶段和运行阶段更像是事务处理过程中的一般步骤,而非特指两阶段提交协议中的阶段。
C. 表决阶段、执行阶段:这两个阶段与两阶段提交协议的标准流程相符。在两阶段提交协议中,第一阶段是准备(Prepare)阶段,也称为表决阶段,其中协调者(Coordinator)询问所有参与者(Participants)是否可以提交事务,参与者进行准备操作并响应协调者;第二阶段是提交(Commit)或回滚(Rollback)阶段,也称为执行阶段,根据第一阶段的表决结果,协调者决定是提交事务还是回滚事务,并通知所有参与者执行相应的操作。
D. 扩展阶段、收缩阶段:这两个阶段与两阶段提交协议无关,可能是对数据库操作或事务处理的某种误解或混淆。
综上所述,正确答案是C选项:“表决阶段、执行阶段”。这两个阶段准确地描述了分布式数据库两阶段提交协议中的核心流程。
数据库设计过程

站在数据库管理人员角度设计,和软件设计过程不同
需要记忆每个阶段的产物,如需求分析的产物有数据流图、数据字典需求说明书
数据库管理系统简称DBMS,即SQLserver、Oracle等

数据库设计的过程通常包括以下几个阶段:
- 需求分析:分析用户的需求,包括数据、功能和性能需求。这一阶段的目标是收集和理解用户对于数据库系统的具体要求,形成需求规格说明书。
- 概念设计:主要采用E-R(实体-关系)模型进行设计,包括画E-R图。这一阶段将用户的数据需求以概念模型的形式表示出来,与数据库的具体实现技术无关。
- 逻辑设计:通过将E-R图转换成表,实现从E-R模型到关系模型的转换,并进行关系规范化。在这一阶段,根据概念数据模型及软件的数据模型特性,按照一定的转换规则和规范化理论,把概念模型转换为逻辑数据模型,如关系模型等。关系规范化是这一阶段的重要任务之一,它旨在通过消除数据冗余和提高数据独立性来优化数据库的逻辑结构。
- 物理设计:主要是为所设计的数据库选择合适的存储结构和存储路径。物理设计阶段的任务是结合DBMS(数据库管理系统)的特性,将逻辑设计产生的关系模式转换成适合在计算机上实现的物理结构。
- 数据库的实施:包括编程、测试和试运行。在这一阶段,根据物理设计的结果,建立实际的数据库系统,并进行测试以确保其满足用户需求。
- 数据库运行和维护:系统的运行和数据库的日常维护。数据库在投入运行后,需要不断地进行维护和管理,以确保其正常运行和满足用户需求。
综上所述,关系规范化是在数据库设计的逻辑设计阶段进行的,它是数据库设计过程中优化数据库逻辑结构、提高数据库性能和质量的重要步骤。
另外该题在前面讲解PPT也可以看出来

C 对数据库设计阶段产物的考察,E-R图是概念设计阶段的产物,关系模式是逻辑设计阶段的产物,数据字典和数据流图是需求分析阶段的产物,任务书和设计方案是前期预处理的过程,不在数据库设计阶段的过程中。
概念结构设计

E-R图是实体联系图的简称

一对一(1:1)
一对多(1:n、n:1)
多对多(m:n)

同一个实体才有同名异义和异名同义,比如编号在很多实体里面都存在,但是其不属于同名异义
关系模型基本概念

层次模型就是类似树一样的结构
表的每一行称作元组,也可以称为记录

候选键:学生信息表中 学号 和 身份证号 是唯一标识元组,因此学号和身份证号是候选键(注意不是学号和身份证号的集合,因为冗余了)
在选课关系表中,学号和课程号的集合是候选键(只有2者的集合才能确认一条记录)
主键:任意一个候选键作为主键(也称为主码)
全码:所有属性组都是候选码则称之为全码

实体完整性:唯一且非空
参照完整性:外键约束
自定义完整性:比如性别只能取0、1

B

C
逻辑结构设计

概念设计的产物是关系模式

归并即合并成一张表,独立的关系模式就是创建一个联系表

上面就是我们讲到的转换规则

实体必须作为独立的关系模式,因此实体这里可以转换为3个关系模式(ABC)
联系类型可以采用归并或者独立的关系模式两种方式,但是多对多的联系无法归并,因此最少可以转换为1个关系模式
加上前面实体的3个关系模式,一共最少是4个关系模式
感觉上面解释不好理解可以看下 文心一言 给出的解析:
现在,考虑题目中的情况:
- 有三个不同的实体集。
- 这三个实体集之间存在多对多联系m:n:p。
为了将这种情况转换为关系模型,我们可以采取以下策略:
- 为每个实体集创建一个关系模式,每个关系模式包含该实体集的主键和其他属性。
- 引入一个额外的关系模式来表示这三个实体集之间的多对多联系。这个关系模式将包含三个外键,分别对应三个实体集的主键。
因此,总共需要的关系模式数为:
- 三个实体集各自对应一个关系模式,共3个。
- 一个额外的关系模式来表示多对多联系,共1个。
加起来是4个关系模式。

第一空由于供应关系有3个外键,说明其是3个实体之间的联系,排除AB。又这3个外键都是主键,说明每个外键都是关系的唯一标识,因此3个实体之间互相为多对多联系,排除C,故选D
第二三空由于项目和员工是多对多联系,而多对多联系必须转换成关系模型时是必须的(不能并入),故选CA
关系代数(☆)

并交差要求表结构一致,即所有属性都是一致的。
并集取所有值再去重,交集取重复值,差集取当前表去重后的值
S1-S2不等于S2-S1,S2-S1是以S2为主体,减去S1中的值,剩下No0008和No0021

笛卡尔积是两个集合的运算,不要求表结构一致
元组行的行数是两个集合行数的乘积,列数是两者之和(和组合类似,每一行拼接另外一个表的每一行)
投影是垂直方向的筛选,选择是水平方向上的筛选。注意区分投影和选择的符号。

自然连接是一种特殊的等值连接,其符号是2个三角形相对
右下角公式是笛卡尔积如何转换成自然连接

第一空自然连接的列数等于两个表列数相加减去重复的列数,因此为 4 + 2 - 2 = 4,故选D(元组个数找出满足 R.C=S.C AND R.D=S.D 的元组个数为3)
第二空先给每一列标上数字分别是1,2,3,4,5,6,根据题意3=6即R.C=S.D,排除ABD

该题感觉比较难,在考场不一定可以一下子看出来可以考虑放弃
该题一眼上来看笛卡尔积的效率肯定是低于自然连接的,感觉应该是选E1或者E2,但是其实这里各个选项不是等价的,E4比起其他来说只有
E1表达式
这个表达式看起来是在进行某种连接操作(可能是自然连接
≈),但它同时包含了条件OA2< 2018和A4= 95,并且这些条件可能不是以最高效的方式组合。此外,自然连接可能会产生额外的处理开销,因为它要求两个关系在所有共同属性上都有匹配的值。E2表达式
这个表达式使用了笛卡尔积(
×),这通常是一个代价高昂的操作,因为它会生成所有可能的行组合,然后再过滤出满足条件的行。OA2< 2018和OA4= 95作为过滤条件,但在笛卡尔积之后进行过滤可能不是最高效的方法。E3表达式
由于没有给出具体表达式,我们无法直接分析。但一般来说,如果E3也涉及了复杂的连接或笛卡尔积操作而没有适当的索引或优化策略,那么它的查询效率也可能不高。
E4表达式
这个表达式首先在一个较小的子集中对R进行过滤(
A2< 2018),然后在S上进行另一个过滤(OA4=/ 95,这里=/可能是打印错误,通常应为!=),之后基于A3属性进行连接。这种做法可以减少参与连接操作的数据量,因为连接操作是在过滤后的结果集上进行的。这种策略通常比先执行连接再过滤(如E1和E2)或在未过滤的数据集上进行笛卡尔积(如可能的E3)更有效。综上所述,如果严格按照表达式运算顺序执行,并且假设所有其他条件(如索引、数据分布等)相同,则查询效率最高的是E4表达式,因为它通过先过滤后连接的方式减少了处理的数据量。

第一空投影12467标出数字后即可得到答案,选B(DFG没有同名,因此不加表名也是可以的)
第二空 根据 1<6,标出数字后代表 R.A<S.F,即排除BD,由于自然连接应该满足 R.A=S.A AND R.B=S.B AND R.C=S.C,排除A,故选C
规范化理论
非规范化存在的问题

基本概念
函数依赖

谁决定谁,谁依赖于谁



例1:A 找到入度为0的节点A,以该属性为起点可以正常遍历图中所有结点,故该属性集为关系模式的候选键
例2:ABCD 先找入度为0的节点,根据给出的依赖关系式(不要直接看图比较乱),可以排除 EGFJIH,另外要遍历所有结点,ABD必须是一个集合才能遍历到E,但是ABD遍历不到J和I,故需要加上C,因此候选码是一个ABCD的集合
例3:B 这里结点数不多,用排除法也可以快速得到答案。主要说下这里如果先找入度为0的结点会发现没有,因此只需要找可以遍历所有结点的情况。C没有出度,因此不可能决定任何东西,故先排除CD选项。这里很容易直接选了A,因为AB可以遍历所有结点,但是发现单独A和B也可以遍历所有结点,故答案是B选项
函数依赖

Armstrong公理

自反律:较大范围可以决定较小范围,如根据你的身份证号和学号可以知道你的学号
增广律:X决定Y,则XZ决定YZ,如根据你的身份证号可以知道你的姓名,那么你的身份证号+学号可以知道你的姓名+学号
传递律:不解释
推到过程如下:


A是传递律,B是自反律,C是合并规则,D是分解规则
范式判断(☆)

BCNF只需要掌握判断,不需要掌握解决方式

复合属性:可以进一步划分的属性,比如姓名可以分成姓和名
多值属性:可以记录多个值的属性,比如记录电话号码可以记录多个,通过逗号分隔
派生属性:通过其他属性可以推导出来的属性,比如年龄可以通过出生年月推导得知
上面例题中高级职称人数可以拆分成教授和副教授,因此不满足第一范式(要求必须是一个二维表)。解决方法是拆分复合属性。

候选键:(学号、课程号)
主属性:学号、课程号
非主属性:成绩、学分
上面例题中 非主属性部分依赖于候选键(课程号),因此不满足第二范式(第二范式都发生在候选键是组合键的情况)。
解决方案是拆表,将课程号和学分对应关系新建表进行记录。拆分后该表只剩下学号、课程号、成绩 3个属性,满足第二范式。

候选键:学号
主属性:学号
非主属性:姓名、系号、系名、系位置
其中,学号->姓名、学号->系号、系号->系名、系号->系位置,故 学号->系号、系号->系名 这里就是一个非主属性传递依赖于码(候选键),因此不满足第三范式。
解决方案是依旧是拆表,分成2张表记录,分别是(学号、姓名、系号)和(系号、系名、系位置),此时不存在传递依赖因此满足第三范式

候选键:(S, J)和(S, T)
主属性:S, J, T
非主属性:无(空集合)
这里关系模式不可再分,因此满足第一范式(其实可以用字母表示了也基本代表不可再分)
没有非主属性因此满足第二三范式(没有非主属性就没有其对候选码的部分函数依赖和传递函数依赖)
例题中,依赖集可以通过下面表示 F = { T -> J, SJ -> T},其中 T 并没有包含在候选码(候选键)中,因此不满足BC范式。
在这里并没有解决方案,因为已经拆分的很细了,如果继续拆分就无法保持函数依赖。像上面的第三范式划分的例子中,划分后其实就是满足第三范式。在平时数据库设计中,只要达到第三范式即可,范式程度越高,连表查询的次数也就越多可能导致速度减慢(因此有反规范化的概念)。

找候选码先找入度为0的结点,在函数依赖集中表现为 L 集,也就是左侧的节点,因此 A2、A3、A4、A6 都不可能是候选码,以此排除法得到C(注意如果有一个结点没有入度也没有出度,孤零零的存在一定是候选码)
存在非主属性对码的部分函数依赖,因此不满足第二范式。由于 关系模式属性都不可再分,因此满足第一范式,选A
模式分解(是否保持函数依赖&是否无损)


例1,将R1和R2的函数依赖合并之后与原始函数依赖F一致,因此保持函数依赖
例2,R1保留了函数依赖集合{A->B},R2保留了函数依赖集合{B->C},与F相比缺少了{A->C},但是由于合并之后可以通过递归{A->B->C}推导出{A->C},因此与原始函数依赖F一致,保持函数依赖

例3,R1保留了函数依赖集合{A->B},R2保留了函数依赖集合{A->C},与F相比缺少了{B->C},因此不保持函数依赖
例4,R1保留了函数依赖集合{A->B},R2保留了函数依赖集合{D->E},与原始函数依赖F一致,因此保持函数依赖


还原后与原关系一样因此是无损分解

表格法: 通用

公式法 只能运用在2个关系模式的情况

例题中第一个满足交集可以决定差集,第二个不满足交集可以决定差集,因此第一个是无损分解,第二个不是
这里也可以使用表格法,如下,找出同名属性列后发现第二个同名属性列B在模式F中不能推导任何内容


DA,这里分解后出现2个关系模式,可以使用公式法,交集决定任意一个差集。函数依赖则看原函数依赖集F在分解后的关系模式下是否依旧保持,这里U1保留了A->BC,U2保留了B->D和D->E,因此保持函数依赖。

AD
第一范式:属性不可再分
第二范式:不存在非主属性对候选键的部分函数依赖
第三范式:不存在非主属性对候选键的传递函数依赖
BC范式:不存在某个属性部分依赖或传递依赖于候选键(所有属性都完全依赖于候选键)
并发控制

一致性这里我的理解是前后的约束规则都可以满足,主要应该是业务层面上的一致(符合逻辑,比如银行转账前后的总金额不变,转账前后需要检查)


S锁是读锁,可共享
X锁是写锁,独占/排他
两段锁协议了解即可

上面不是很理解,T1不是减了5,为什么T2读的还是10,这样子更新不是已丢失了?


数据库的安全性

存取控制可以认为是权限控制

视图有安全性也可以保证关系模式不被第三方获取,但是视图并不能进行数据更新
索引是方便查找,提高查找性能
触发器是监听变化,一般用于检查数据完整性,并不是直接调用而是自动触发
因此这里排除法也可以选出答案,选C
数据库备份与恢复技术

冷备份这里其实就是转储,把数据库的sql文件复制到另外一个地方

先写日志,再写数据库(日志文件)

如果周六数据库发生故障,则只需要还原上一次全备+最近一次差备+最近一次差备后面的增备
即周日备份+周五备份+周六备份


转储正在运行的数据,因此是“动态”(静态是停止运行的数据库)
转储全部数据,因此是“全局”(增量是对上一次的备份的数据)
故选B
数据库的性能优化

对性能的优化都是先找瓶颈
本文链接: http://www.ionluo.cn/blog/posts/d0470d33.html
版权声明: 本作品采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。转载请注明出处!

