4.1 数据库系统前言

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)

4.2 数据库三级模式两级映射(常考)

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
三级模式两级映射这种设计属于层次型的架构设计,这种层次型设计为我们应用数据库提供了很多方面的便利,同时,让整个系统的可维护性和应变能力变得更好。

物理数据库:在计算机上面表现形式是一个文件。SQLServer、MySQL等。

内模式:又叫物理数据库层次,和物理层的数据库直接关联,管的是如何去存储这一系列的数据,数据要存到物理文件上面,按什么格式来存储,如何去优化;它主要的关注点是数据的存放。

概念模式:平常用数据库时,表这一级别,数据库中会有很多表,这些表对应的就是概念模式,这一级模式中将数据分成若干张表,这些表是根据我们的业务,根据我们的应用来划分出来的。表之间会有相应的关联。

外模式:它所对应的是数据库中的视图,外模式的应用让我们对数据的控制有了更进一步的手段,更加灵活的一些处置方式。如:在概念模式中用户信息表,该表包含多种用户信息,用户名,密码等,在应用过程中,如果任何一个功能模块都能直接去调用用户的所有信息,这不是很安全;并且如果概念模式中的表发生了变化,应用程序如果直接去调用这些表,那么应用程序也会跟着变。但是如果加了一层外模式之后,会将原来的数据表进行一定的处理之后形成相应的数据表。登录时候只需要用户名,密码调出来,形成一个视图,给登录模块用,在内部调用时候,只需要用户信息,不需要用户密码,则可以建一个视图,不包含密码,增加了安全性。也增加了灵活性。
以后如果是概念模式层级比如表发生了变化,将表的一些字段拆分出来成新的表,也可以通过视图将这些表整合起来,可以选择这些表中的哪些列组合成视图,也是可以的。

外模式-概念模式映射:表通过相应的操作得到视图,其实表和视图之间是有一种映射关系的,这种映射关系被称之为外模式-概念模式映射。有了这一级映射,当表发生变化,我们只需要改映射,而不需要改应用程序。

概念模式-内模式映射:主要管内部的存储形式和表的情况的一种映射关系;当存储结构进行改变时,只需调整这种映射关系,而不需要修改用户的应用程序,就能应对这种变化。

4.3 数据库设计过程说明

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
需求分析:整个系统对数据有什么样的要求,有从用户收集过来的,同时有转换的过程中产生的需求。

概念结构设计:主要表达形式就是ER模型。

4.4 ER模型

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
学生和课程是多对多的关系:一个学生记录可以对应多个课程的记录,反之,一个课程可以供多个学生来选择。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)

4.4.1 ER模型转关系模式应注意

一个实体转为一个关系模式:
1:1联系:两个实体各转成一个关系模式,中间的联系可以转成单独的一个关系模式,也可以把联系合并到与之关联的两端的任意一端的实体上。一对一联系最少转成两个关系模式。一个实体转成一个关系模式,把联系记录到任一实体上记录下来。

1:n联系:每一个实体转成单独的一个关系模式;可以将单独将联系转成一个关系模式,这种做法可以,但不是必须的。也可以把这种联系记录到n,也就是多的一端;
如:员工和部门的关系就是一对多,把这种联系只能记录在员工端,即在员工表中加上一个部门号。一对多的联系中,最少要转成两个关系模式,联系可以合并到多的一端。

m:n联系:学生和课程多对多的联系,学生表转成一个单独的实体,课程表转成一个单独的实体,选课的联系也必须转成一个单独的实体。多对多的联系,至少要转成3个关系模式。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
例题分析:A、B、C三个实体各转成一个关系模式,中间的联系转成一个,最少转成4个关系模式。

4.5 关系代数

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
:将两个集合的内容并到一起,两个集合当中都有的数据只显示一次。

:将公共部分找出来,形成新的关系。

:我有的你没有;S1-S2,结果集是S1有但S2没有。将S1中公共部分去掉。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
笛卡尔积:笛卡尔积的符号是一个乘号,笛卡尔的结果是:前三个字段来自于S1,后三个字段来自于S2,在笛卡尔积中会把两个参与笛卡尔积操作的集合的属性一一的列出来,成为笛卡尔积最终的结果,这是包含那些数据列的问题。(笛卡尔积不会将相同的字段给去掉)
包含那些记录:记录是这样原则产生的,S1的第一条记录要跟S2的一、二、三的每一条记录要做一次组合,形成一条新的记录。S1的第二第三条记录也是依次和S2的第一、第二、第三条记录做拼接。这样就得到了笛卡尔积。
笛卡尔积结果的属性的个数是参与操作的两个属性树之和;
而记录数是两个记录数之积。

投影:对S1做投影,结果就是只有投影下来的哪几列数据了,没有投影的那部分数据就丢弃了;所以投影是选列的一种操作,选出哪些我需要的列;
如图:对S1的 Sno和Sname做了投影,所以结果集就只有Sno和Sname;

选择:选择选的记录,选的是行。对S1做选择操作,Sno=No0003,这一条记录就被选出来了,在投影和选择操作过程中,值得我们注意的一点是:在选择列也好,选择行也好,有的时候在写它的选择和投影操作的属性的时候,有时用的是属性名,有时用的是数字编码代号,以第一个投影操作来看,我们可以写出它的等价形式:π 1,2 (S1);
在选择操作中也可以有同样的写法。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
联接:一般联接操作下面会写联接的条件,如:S1.Sno = S2.Sno。

联接和笛卡尔积有啥区别:最大的区别:联接会把S1,S2都有的字段只保留一个。
有时在联接过程中没有写条件,被称为自然连接,自然连接的条件是:这两个关系当中,相同的字段做等值。在S1、S2中,相同的字段只有Sno,所以不写条件默认就是S1的
S1.Sno = S2.Sno。

细节注意:在做自然联接之后,要对某些字段做选择,只需要Sno、Sname、Age。
可以写 π Sno,Sname,Age;也可以写成 π 1,2,4。
值得特别注意的地方是:Sno我们只会保留一个。

4.6 规范化理论_函数依赖

函数:f(x) = x^2;对于确定的x的值,都有唯一的f(x)的值与之对应。
此时我们就说x能够确定f(x),这就是一种函数依赖。
如:学号能够函数确定姓名。反之则不行,因为姓名可能重名。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
部分函数依赖理论:A、B的组合键确定C,并且A确定C

主键是两个属性的组合键,主键当中的一部分可以确定某一个属性,就是部分函数依赖。
如:学号,课程号,姓名;学号和课程号的组合键可以确定姓名,于此同时,学号也可以确定姓名。

传递函数依赖:A可以确定B,B又可以确定C,这时可以得到一个推论:A确定C。
强调了一点:B不能确定A,因为如果B能够反过来确定A,说明A和B等价,就不存在传递性的讲法了。

4.7 规范化理论-价值与用途

非规范化的关系模式,肯能存在的问题包括:数据冗余、更新异常、插入异常、删除异常。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)

4.8 规范化理论-键

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
1. 超键:唯一标识元组,可以是单个属性,也可以是属性的组合。
超键和候选键的唯一区别区别:超键可能存在冗余属性,而候选键不存在冗余属性。
所以,在超键的基础上消除多余的属性,就成为了候选键,候选键也是能够唯一标识元组。

例子:加上有学号,姓名,性别属性。
在此情况下,学号可以确定性别,学号和姓名的组合键也可以确定性别。
那么学号和姓名的组合键可以称之为超键;但是不能够称之为候选键;因为有冗余属性。

2. 主键:候选键和主键的区别:候选键可以有多个,主键只能有一个。(选总统时候选人可以有多个,但是选出来的总统只能有一个)。
在数据库中,几个字段都可以设置为主键,但是只能挑选其中的一个设置为主键。

3. 外键:别的关系的主键,因为很多时候我们要对表做关联。
(比如:员工表中一般会设置部门号,部门号用来和部门表进行关联,那么部门号对于员工表就是一个外键。)
外键的提出就是关联查询的时候用到的。

求候选键:(常考)
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
例题:
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
例1:选A,入度:对于一个节点,指向该节点的为入度,从该节点指出的为出度。
例2:候选键是ABCD的组合键,ABCD的任何一个字母都不能遍历全图,只有将他们组合起来才能遍历全图。
例3:选B。A和B作为中间节点,都能遍历所有节点。

4.09:规范化理论-范式(必考,要求掌握)

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
范式会分为第一范式,第二范式,第三范式, BC范式以及更高级别的第四范式。
范式在级别不断提高的时候,规范化程度是越来越高了。也就更有可能去解决插入异常,删除异常,数据冗余的问题。
与此同时也带来了问题,即规范化程度越高,往往数据的粒度越小。
要将范式提高级别,基本上走的方式都是数据表的拆分,越到高级别的范式,拆分的越细。
将数据一步步拆分的细的时候,往往又带来性能方面的问题。所以一般采取比较平衡、折中的方式。即将范式做到第三范式左右即可。
要达到第二范式必先达到第一范式;以此类推,范式可以跨越。
第一范式:属性值都是不可分的原子值,所谓原子值就是该属性无法再拆分为几个属性。
第二范式:第一范式消除了非主属性对候选键的部分依赖,就到第二范式。
第三范式:第二范式消除非主属性对候选键的传递依赖,就到第三范式。
BC范式:第三范式消除主属性对候选键的传递依赖。就到BC范式。

主属性和非主属性的意思:所谓主属性,就是该属性属于候选键的一部分,(以第二范式的图为例,主属性有SNO,CNO都是主属性。而GRADE、CREDIT是非主属性)。所以判断主属性和非主属性,核心就在于那些是候选关键字。(将候选关键字列出来,在任何候选关键字中出现过的属性都是主属性)。

4.9.1 规范化理论-第一范式

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
以上关系不满足第一范式,因为该表中分为系名称和高级职称人数。而高级职称人数又可以分为教授和副教授,这就不满足第一范式的要求。
如果要改成第一范式,将高级职称人数去掉,直接就是系名称,教授,副教授。

4.9.2 规范化理论-第二范式

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
以上表SNO(学号)CNO(课程号)GRADE(成绩)CREDIT(学分)

在以上关系中主键是SNO和CNO的组合键,SNO和CNO组合起来才能确定成绩;因为一个学生可以选多门课程(S01就选了C01,C02,C03上面课程),我们仅仅用课程号或者学号都不能确定成绩,必须是两者的组合键才能确定成绩,而学分是可以通过课程号来确定的,所以我们要求这一个关系模式的主键(候选键),候选键就是SNO和CNO的组合键。

存在部分函数依赖,因为课程号就可以确定学分,而课程号只是主键的一部分,这就存在了部分函数依赖,要解决这种为题,就要拆分。

部分函数依赖带来的问题?

数据冗余:学分存了很多次,这是不必要的,因为每一门学科都有固定的学分。学分好课程号的对应关 系存一个就可以了。

更新异常:要更新学分的时候只更新了两条记录肯定不行。更新部分不更新部分导致更新异常。

插入遗产:比如有一门新的课程C08,学分是6分,现在该课程还没人选,要想先将C08,6学分的信息录入到该表中,会无法录入,因为没有学号,系统不让录入,因为学号是主键。主键必须有值,不能为空。

删除异常:比如学生毕业将他们的成绩信息全部清除,则学分信息也一并被删除掉了。(学分信息下届学生同样适用,应当予以保留)。

解决方案:
将CNO(课程号)和CREDIT(学分)两个字段提取出来,做一个新的关系模式。在原来的关系模式中将学分列去掉,注意:不能去掉课程号字段,因为数据会不完整。

4.9.3 规范化理论-第三范式

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
以上表显然已达到第二范式的要求,因为已标识出SNO是主键,知道这一点,不用再细致去分析,也知道,它已经属于第二范式了,因为它的主键只有单属性,单属性是不可能有部分函数依赖存在的,所以如果说我们求出来是单属性的关键字,那就不存在部分函数依赖的可能。
该表虽然已经达到第二范式,单仍然有数据冗余等一系列的问题(更新,插入,删除异常)。

解决方案:将DNO,DNAME,LOCATION独立出来,成为一个关系模式。这样就打破现有的这种传递依赖了,原来的关系模式就只剩下前三个字段了(SNO、SName、DNO)。

4.6.4 规范化理论-BC范式

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
SJ是一个候选键,ST也是一个候选键(因为ST中T可确定J)。
STJ都是主属性,在这个关系模式中没有非主属性。既然没有非主属性,所以肯定满足第二范式和第三范式的。因为第二范式是消除非主属性对候选键的部分函数依赖,而第三范式是消除非主属性对候选键的传递依赖。现在连非主属性都没有了,自然这些依赖也就不存在了。

任何判断是否是BC范式?
R属于BCNF当且仅当其F中每个依赖的决定因素必定包含R的某个候选码、(通俗讲就是:我们将所有的函数依赖写出来,函数依赖的左边部分必须是候选键,因为函数依赖里面,左边部分,就是它所谓的决定因素)。
上图有哪些函数依赖,函数依赖包括 “SJ确定T”,还有“T确定J”,对于第一个函数依赖,明显左边部分是一个候选键,而对于第二个函数依赖左边部分不是一个候选键,所以我们判断,这不是BCNF,或者说该关系模式还没有达到BCNF的级别要求。

4.10 规范化理论——范式练习题

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
分析:考查范式的判断,同时考察到了ER模型转关系模式时候涉及到的关系模式之间的关联问题。

第一空:消除部分依赖必须主键是多个属性的组合键,而在部门关系中,部门号是可以充当主键的,所以有了这一条,部分函数依赖已然消除。部分函数依赖消除之后,只剩下传递函数依赖了,所以这时候应该是消除了部分函数依赖而没有消除传递函数依赖,因为如果说消除了传递函数依赖,他就满足了第三范式了,现在不属于第三范式,显然没有消除传递函数依赖(至于有些同学思考的,具体函数依赖传递在那一块,这个我们可以不去考虑,因为该题在这个方面设计不严谨。所以选择题 ,选就近的答案就行,别太纠结题目的严谨性等方面)。

第二空:备选答案。改表1,表2,表3中的任一个,增加职工号或者部门号。
要结解决的问题显而易见,就是部门号和职工号之间没有关联,我们无法看出哪些职工属于哪个部门,而职工和部门之间是一种多对一的关系,应该把这一种联系保存在多这一端,也就是职工表里面加上部门号,所以应当在表3当中加部门号,就能建立起部门和职工之间的关系。

第三空:要增加一个关系模式,先看看表4当中到底有一些什么内容,那些内容是目前3个表无法表达的,首先,销售这样一个表,职工号是肯定是有的,ABCD选项都有职工号,不必考虑,有了职工号,有必要加上部门号吗?没有必要,因为在第二空的时候,已经对职工号和部门号建立了关联。B选线的商品名称是没有必要的,因为有商品号,从商品号可以查到商品名,商品名称属于冗余信息,可以去掉。

4.11 规范化理论-模式分解

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
在之前讲范式的过程中,当范式级别不够时候,是将模式进行拆分,拆分下来后级别就上去了,在拆分过程中,需要考虑到一些因素,拆分时有不同的拆分的机制,原则需要注意,模式的分解拆分,主要讲两个方面。

4.10.1 保持函数依赖分解

分解之前有哪些函数依赖,分解之后这些函数依赖仍然存在。

例子:有一个关系模式,总共有A、B、C三个属性,R(A、B、C),然后有函数依赖,A确定B,B确定C,将其分成两个关系模式,R1(A、B),R2(B、C),这种分发就保持了函数依赖。因为,A和B都在R1中,所以R1保持了A到B的函数依赖,R2有B和C两个属性,所以B到C的函数依赖,被R2保存下来,所以两个函数依赖都被保存下来了,这就代表保持了函数依赖。
假设将其拆分成R1(A、B)和R3(A、C),就没有保持函依赖,因为A确定B保存下来了,B确定C没有保存下来,所以这种形式没有保持函数依赖。

能够将原关系模式当中的所有函数依赖关系,都将它写到新的拆分出来的这些关系当中来,
代表函数一来就保持下来了。如果有缺失就不行。(对于冗余性质的函数依赖不要求保留。)
假设R1(A、B),R2(B、C),R3(A、C),R3就是冗余的函数依赖,因为R1、R2的分解保持了函数依赖,因为A确定B,B确定C,就已经能将A确定C推导出来了。

4.10.2 无损分解

有损:不能还原。
将原关系模式R拆分之后,无法再还原成为R。
无损:可以还原。
如果可以通过链接操作将拆分后的关系模式,又可以组合起来,链接起来形成原来的关系模式,就是无损。

4.10.3 规范化理论-模式分解-例题讲解

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
以上分解便是无损分解,因为我们可以通过联接操作还原原始表。
分析如下:
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
表格法:
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
第一行中写的是在原关系当中拥有的一系列的属性,包括学号、姓名、课程号、课程名、分数,有的字段全部列出来,第一列是你要拆分的关系模式)(即将要拆分成哪几张表),a代表当前的关系模式会真正拥有当前的属性,a1的位置就是第一列,对应的属性是学号,对应的子关系是成绩,拆分后的成绩关系模式拥有成绩这个字段;
b代表的说明当前的关系模式没有包含该字段(b12即成绩关系没有包含姓名)。

根据每一个函数依赖,对表进行更新,因为有学号确定姓名,所以我们可以在原始表中,而在第二行学生表中,既有学号,也有姓名,所以,将这里标出来,标出来之后如果说我们发现在这个表中有其他行学号位置是a,姓名位置是b,则可以把姓名位置填成a(比如第一行第二列可以天成a2),这样做其实就是讲成绩和学生两个表做关联操作,然后把姓名属性放到成绩表当中来,(写表格的优势,它可以一次性给的把所有的更这个函数依赖相关的这些子表全部进行统一的处理)。
接下来课程号到课程名,它的完整依赖在课程表中(a3到a4),然后在成绩表中,它的左部分就是决定因素,所以右边部分可以通过关联查询得到。

进行完所有的处理,假设有一行全部是a,那就是无损分解。全部是a说明将原来的原始表已经还原了。如下图。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
判断无损分级的第二种方法:
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
第二种方法,局限性比较强,因为这种方法只适合于一分为二,即R关系模式,可以拆分成两个R1、R2。
一分为二判断它是否是无损分解,将分解出来的两个关系模式求交集,然后把这两个分别做R1-R2和R2-R1的操作,如果说结果集有一个,与交集有这种函数依赖关系,就属于无损分解。
例如上题:结果集中有一个(结果集即B和C),与交集(即A),有这种(即题目给出的F={A->B})函数依赖关系,就属于无损分解。

4.12 数据库并发控制

4.12.1 并发控制——基本概念

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
事务:将多个操作封装起来,把它看做一个整体来进行操作(要么全做,要么全不做)。
为什么要有事务机制呢?
因为很多的操作有关联性,本身就是一个整体,如果不一次性执行完,会产生一系列的问题。
事务的几大特性
原子性:要么全做,要么全不做。事务操作是一个原子性操作,即不可再拆分来做。
一致性:指事务在执行之前,数据是保持一致的状态,执行之后也是一致的状态。
如:银行转账前后两个账号的钱的总和始终是一致的(类比能量守恒的状态)。
隔离性:事务之间是独立进行的,隔离的,互不影响。
持续性:事务执行之后,它的结果影响是持续的。

4.12.2 并发控制——存在的问题实例

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
丢失更新:T1、T2两个事务,各司其职的运行,T1读取A并进行自减5写回的操作。T2读取A自减8写回操作。逻辑上来讲,T1、T2都执行完,A应该减13,但真正的结果是只减掉了8,即A=2,因为T2写回时会把T1的结果覆盖掉,即丢失更新。
不可重复读:T1在读A、B求和,并二次求和做验算,但是在T1第二次求和过程中,T2对A进行了更新,导致T1的两次运算结果不同,验算不对。即重复读第二次时候,值以及不一样了——不可重复读。
读“脏”数据:不是真正的数据,只是一个临时值,T1读取了A的值20,加50写回70,此时T2读取了A=70的值去进行它自己的操作,但是T1最后进行ROLLBACK操作(回滚,之间的所有操作将被复原),A的值回复为20。此时T2读到的A的值就是一个“脏”数据。

4.12.3 并发控制——封锁协议

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
为了解决以上问题,提出了封锁协议:
S 锁是读锁,X锁是写锁。读锁加上之后,别人还可以对这个数据加读锁,但是不能加写锁,而写锁加上之后不能在之上加任何的锁。
三级封锁协议和二级封锁协议,释放时间不一样,二级封锁协议,读完后即可释放,三级封锁协议是直到事务结束才释放。三级封锁协议以上三种情况都可应对。
两段锁协议:
死锁问题:

4.13 数据库完整性约束

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
数据库的完整性约束主要有三种:
实体完整性约束:使用数据库的时候通过给数据表定义主键。实体完整性约束,约束的是主键,它的值不能为空,不能重复。
参照完整性约束:外键的完整性约束。
比如:我们设置了一个员工表,表中有一个字段名叫做部门号,部门号设置了参照完整性约束,参照到了部门,做了该设置之后,我们会发现,填部门号时候,不能随便填写,否则系统会提示报错。因为有参照完整性的约束,参照完整性的约束要求,填入的数据必须是对应表里面的主键的内容,否则出错。考虑到员工可能还没有分配部门,所以允许为空。也允许正确的部门号,但是部门号不能输错。
用户自定义完整性约束:用户可以设置该属性值的情况要求;比如:输入的是年龄,就不允许输入负数,也不允许输入200以上的值。就可以设置自定义完整性约束。

以上三种完整性约束都是一种提高数据可靠性的一种机制,数据有问题,就不应该让它录入进数据库。
但这三种完整性约束都只能应对简单的情况,复杂情况不能应对,所以此时又有一种新的机制——触发器:触发器可以写脚本来约束数据库数据的一些要求。所以更加复杂的要求使用触发器来完成的。

4.14 数据库安全

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)

4.15 数据库备份与恢复

4.15.1 数据备份

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
备份的另外一种分类方式:依据数据备份的量来进行区分的。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
制定一个备份策略:
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
周一的增量备份针对周日的完全备份的版本,在完全版本的基础上删除了哪些东西,增加了哪些东西,修改了什么东西等都在增量备份中体现。
假设周一备份完发生故障,恢复数据先恢复周日的完全版,再在周日完全版的基础上恢复周一的增量版。
同理:周二的增量是针对周一的,周三的增量是针对周二的……
周三数据出故障:先恢复周日,在恢复周一,在恢复周二,最后恢复周三的。
周四的差量备份是直接针对周日的完全备份来记录的。这种变化量跨度大,恢复时候方便。
增量和差量有机的结合,是有利用备份和恢复的。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
转储就是备份:海量指所有数据,增量指上一次转储之后的。 静态就是不运行状态,动态是运行状态。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
在做插入,增加,删除数据之前,会先去写日志。一般是将SQL语句记录下来,再来写数据文件。一旦写数据文件时或者以后出故障,要恢复到原来的状态时,可以将日志找出来看做了什么操作,我们再重新做这些操作,就相当于恢复到故障时间点了。

4.15.2 数据库故障与恢复

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)

4.16 数据仓库与数据挖掘

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
数据库和数据仓库的差异:
数据库是根据业务的需求看需要记录那些数据,就将其记录下来。(面向应用)
数据仓库:
数据集市:部门级的数据仓库。

4.16.1 数据挖掘方法分类

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)

4.17 反规范化技术

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
反规范化的技术手段:就是规范化的逆过程,以牺牲空间和规范化程度来换取时间。
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)

4.18 大数据基本概念

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
大数据技术:对海量数据进行处理的相关技术;
这些数据具备什么特点?
数据量极大,要求处理的速度极快,数据具有多样性,并且数据具备一定的价值。

大数据

软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
软件设计师【软考中级】复习笔记 —— 第四章(数据库系统)
现在大数据往往和云计算,虚拟化等技术结合起来来分析;云计算可以将一些闲置资源利用起来,成本较低。

相关文章: