四、数据库系统

数据库系统(Database System),是由数据库及其管理软件组成的系统。数据库系统是为适应数据处理的需要而发展起来的一种较为理想的数据处理系统,也是一个为实际可运行的存储、维护和应用系统提供数据的软件系统,是存储介质 、处理对象和管理系统的集合体。

(一)内容提要

四、数据库系统_第1张图片

(二)数据库模式

1.三级模式-两级映射

数据库系统采用三级模式结构,这是数据库管理系统内部的系统结构。数据库系统设计员可在视图层、逻辑层物理层对数据抽象,通过外模式、概念模式内模式来描述不同层次上的数据特性。

  1. 数据库的三级模式
  • 外模式(External Schema)/用户子模式(Subschema):也称用户子模式(Subschema)或用户模式,是数据库用户(包括应用程序员和最终用户)能够看见和使用的局部数据的逻辑结构和特征的描述,是数据库用户的数据视图,是与某一应用有关的数据的逻辑表示。理解如下:

    • 一个数据库可以有多个外模式;

    • 外模式就是用户视图;

    • 外模式是保证数据安全性的一个有力措施。

  • **模式(Schema)/**概念模式:也称逻辑模式,是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。理解如下:

    • 一个数据库只有一个模式;

    • 是数据库数据在逻辑级上的视图;

    • 数据库模式以某一种数据模型为基础;

    • 定义模式时不仅要定义数据的逻辑结构(如数据记录由哪些数据项构成,数据项的名字、类型、取值范围等),而且要定义与数据有关的安全性、完整性要求,定义这些数据之间的联系。

  • 内模式(Internal Schema):也称存储模式(Storage Schema),它是数据物理结构和存储方式的描述,是数据在数据库内部的表示方式(例如,记录的存储方式是顺序存储、按照B树结构存储还是按hash方法存储;索引按照什么方式组织;数据是否压缩存储,是否加密;数据的存储记录结构有何规定)。理解如下:

    • 一个数据库只有一个内模式;

    • 一个表可能由多个文件组成,如:数据文件、索引文件。  它是数据库管理系统(DBMS)对数据库中数据进行有效组织和管理的方法  其目的有:

      • 为了减少数据冗余,实现数据共享;

      • 为了提高存取效率,改善性能。

  1. 数据库的两级映射
  • 外模式-概念模式映射:实现外模式到概念模式之间的相互转换

  • 概念模式-内模式映射:实现概念模式到内模式之间的相互转换

四、数据库系统_第2张图片

2.数据库设计过程

数据库设计过程为:需求分析、概念结构设计、逻辑结构设计、物理设计。下图所示,列出了每个阶段的主要特点及产出物。

四、数据库系统_第3张图片

(三)ER 模型

在 ER 模型中,椭圆表示属性,矩形框表示实体,菱形表示联系。

四、数据库系统_第4张图片

四、数据库系统_第5张图片

在下图中的例题中,ER 图中有 3 个实体,所以要转成 3 个关系模式,然后由于 3 个实体之间是多对多的关系,所以这个关系也要转成 1 个关系模式,所以最少可转换为 4 个关系模式。

四、数据库系统_第6张图片

(四)关系代数

数据库的关系代数有:

  • 并:结果为二者元组之和去除重复行。

  • 交:结果为二者重复行。

  • 差:前者去除二者重复行。

  • 笛卡尔积:又称为等值连接。对两个关系R和S进行操作,产生的关系中元组个数为两个关系中元组个数之积。不会将重复的列去掉。

  • 投影:关系R上的投影是从R中选择出若干属性列组成新的关系。

  • 选择:在关系R中选择满足给定条件的诸元组。

  • 连接:。

四、数据库系统_第7张图片

四、数据库系统_第8张图片

(五)规范化理论

1.函数依赖

对函数依赖的理解:对于函数 f(x) = x2,将其写成 y=x2,给定 x=1 时,就能确定 y=1,此时可以讲 x 能够确定 y(函数确定),即 y 依赖于 x(写成 x —> y),这就是函数依赖。**注意:**该函数不能写 y 确定 x,即不能写成 y —> x。因为 y=1 时,x 可以等于 1 也可以等于 -1,即 y 的一个值对应 x 的两个值,所以 y 不能确定 x。

部分函数依赖:假如 A 是学号,B 是课程,C 是姓名,可以看出学号+课程(组合主键)是可以确定姓名的,同时学号也能确定姓名,即主键的一部分也能确定属性,这就是部分函数依赖。**注意:**单属性主键不可能出现部分函数依赖。

传递函数依赖:A 可以确定 B(B 不可以确定 A),B 可以确定 C,则 A 可以确定 C。

四、数据库系统_第9张图片

2.价值与用途

规范化理论的价值与用途,主要是消除数据冗余、更新异常、插入异常、删除异常等问题。

四、数据库系统_第10张图片

3.键

  • 超键(Super Key):在关系中能唯一标识元组的属性集称为关系模式的超键。一个属性可以作为一个超键,多个属性组合在一起也可以作为一个超键。超键包含候选键和主键。超键可能会有多余(冗余)属性,如对于学号+课程确定姓名来说,主键是学号+课程,但是去掉课程后,学号也可以作为主键,所以课程是多余属性。

  • 候选键(Candidate Key):不含有多余属性的超键称为候选键。

  • 主键(Primary Key):用户选作元组标识的一个候选键。程序主键,一个数据列只能有一个主键,且主键的取值不能缺失,即不能为空值(Null)。

  • 外键(Forrign Key): 在一个表中存在的另一个表的主键称此表的外键。外键主要是用来描述两个表的关系。

四、数据库系统_第11张图片

四、数据库系统_第12张图片

下图中,例 1 的答案是 A1,例 2 的答案是 ABCD,例 3 的答案是 A 和 B(不能写成 AB,因为 AB 是一个组合)。

四、数据库系统_第13张图片

4.范式

范式在提高的过程中,规范化程度越来越高了,但是粒度越来越小了,就会影响性能,所以一般最高到第三范式(3NF)就可以了。要达到第二范式(2NF)必先达到第一范式(1NF),要达到第三范式必先达到第二范式。

主属性:该属性是候选键的一部分,在任何候选键(关键字)里面出现过的属性都是主属性。

非主属性:不属于候选键的一部分的属性。

四、数据库系统_第14张图片

4.1 第一范式

下图中的例题中关系 R 不满足 1NF,因为对于高级职称人数这一列,其可以再细分为教授、副教授。将高级职称人数拆分成教授、副教授两列,即可达到 2NF。

四、数据库系统_第15张图片

4.2 第二范式

下图中的思考题,主键是 SNO(学号)+CNO(课程号) 的组合。SNO+CNO 可以唯一确定 GRADE(成绩)、CREDIT(学分),同时 CNO 也可以唯一确定 CREDIT,所以存在部份依赖,不满足第二范式。关系 R 中有四行中都出现了一样的 CNO、CREDIT(C01、4),两行中都出现了一样的 CNO、CREDIT(C02、2),所以有数据冗余。当更新 C01 的 CREDIT 时,如果只更新了两条记录,剩余的 2 条记录没有更新,就会导致更新异常。如果有 CNO=C08,CREDIT=6 想要录入关系 R 中,由于没有 SNO(SNO 也是主键,不能为 Null),所以无法录入,就会导致插入异常。如果本届学生已经毕业了,需要删除学生的 SNO 信息,就会导致 CNO、CREDIT 都会被删除,所以有删除异常解决方案:将 CNO、CREDIT 两个字段提取出来构成一个新的的关系模式,去掉关系 R 中的 CREDIT,不能去掉关系 R 中的 CNO,因为关系 R 中的 CNO 是外键。

**注意:**单属性主键不可能出现部分函数依赖,所以单属性主键必然满足第二范式。

四、数据库系统_第16张图片

4.3 第三范式

可以根据第二范式的思考题来分析下图中的思考题,解决办法:将 DNO、DNAME、LOCATION 提取出来构成一个新的关系,旧的关系中删除 DNAME、LOCATION 字段。

四、数据库系统_第17张图片

4.4 BC 范式

在下图的例题中,SJ、ST 两个组合都是候选键,因为两个都可以遍历完 STJ。所以 S、T、J 都是主属性,该例题中没有非主属性,所以该关系肯定满足第二范式、第三范式。

四、数据库系统_第18张图片

下图的例题中,候选键为:SJ、ST,函数依赖有:SJ—>T、T—>J,所有函数依赖的左边部分有:SJ、T,由于 T 不是候选键,所以该关系不是 BC 范式。

四、数据库系统_第19张图片

5 例题

在下图的例题中,对于空格(1),部门关系不属于第三范式的原因可能有两种:不属于第二范式、属于第二范式但不属于第三范式。在部门表中,部门号是可以作为主键的,由于单属性主键不存在部份依赖,所以部份表满足第二范式,不满足第三范式的原因就是没有消除传递函数依赖。观察空格(2)的答案选项,发现要么改职工表,要么改部门表,意味着要解决部门和职工之间的关联,目前是无法知道哪些职工属于哪个部门,而职工与部门是多对一的关系,所以要这种多对一关系保存在多的这一端,即保存在职工表中,所以要在职工表增加增加一个部门号,就可以建立起职工与部门之间的联系。如果要得到表 4,观察空格(3)的选项中都有职工号,由于之前已经在职工表中增加了部门号的字段,所以不需要部门号,排除 C、D。由于根据商品号就可以查到商品名称,所以不需要商品名称(商品名称一旦出现,就是冗余信息),排除 B,得出最后的答案是 A。

6.模式分解

根据以上类别可知,当范式较低时,可以对关系模式进行拆分,拆分后关系模式的范式级别就能得到提升。

四、数据库系统_第20张图片

6.1 保持函数依赖分解

对于关系模式 R(A,B,C),其中有 A—>B,B—>C 两个函数依赖,将关系模式 R 拆分成 R1(A,B)和 R2(B,C)后保持了函数依赖,因为保持了A—>B,B—>C 这两个函数依赖,即保持了原关系模式 R 所有的函数依赖。若拆分成 R1(A,B)和 R3(A,C),则没有保持函数依赖,因为只保持了A—>B,而没有保持B—>C。

对于关系模式 R(A,B,C),其中有 A—>B,B—>C,A—>C 三个函数依赖,将关系模式 R 拆分成 R1(A,B)和 R2(B,C)后同样保持了函数依赖, 虽然只保持了 A—>B,B—>C 这两个函数依赖,但是由于 A—>C 是冗余的函数依赖,可以从A—>B,B—>C 推导出A—>C,所以不保持也没关系。

6.2 无损分解

**有损:**不能还原。**无损:**可以还原。

**无损分解:**指将一个关系模式分解成若干个关系模式后,通过自然联接和投影等运算仍能还原到原来的关系模式。

四、数据库系统_第21张图片

四、数据库系统_第22张图片

7.并发控制

7.1 基本概念

四、数据库系统_第23张图片

7.2 存在的问题示例

四、数据库系统_第24张图片

7.3 封锁协议

四、数据库系统_第25张图片

8.数据库完整性约束

数据库完整性约束是为了保证数据库中数据的质量而设立的限制条件。它通过定义表或表的列中数据的限制条件来自动保持数据库的完整性。常见的数据库完整性约束有以下几种分类:

  • 实体完整性约束:确保每个记录都有一个唯一的主键,可以通过主键约束来实现。

  • 参照完整性约束:确保主表和从表之间的数据一致性,即在输入或删除记录时,主表和从表中的相关数据应该一致。可以通过外键约束来实现。

  • 域完整性约束:确保数据在指定的范围内有效,可以通过定义数据类型、长度、格式等约束条件来实现。

  • 用户自定义完整性约束:根据特定需求,自定义约束条件,以保证数据的完整性。比如限制年龄的值在 0 到 150 之间。

四、数据库系统_第26张图片

9.数据库安全

四、数据库系统_第27张图片

10.数据库备份与恢复

10.1 数据库备份

10.2 数据库故障与恢复

四、数据库系统_第28张图片

11.数据仓库与数据挖掘

数据仓库是面向主题的,而普通的数据库是面向业务的。

四、数据库系统_第29张图片

四、数据库系统_第30张图片

12.反规范化技术

四、数据库系统_第31张图片

13.大数据

四、数据库系统_第32张图片

四、数据库系统_第33张图片

(六)数据库的故障

数据库的故障分为 4 类:① 事务内部故障,如运算溢出、并发事务发生死锁等;② 系统故障也称软故障,它是指造成系统停止运行的任何事件;③ 介质故障也称为硬故障,如磁盘损坏、磁头碰撞和瞬时强磁干扰等;④ 计算机病毒。(2022 年下半年选择题)

你可能感兴趣的:(软件设计师,数据库,oracle)