软考-系统架构设计师-3

简介: 数据库系统

📎3.数据库系统.pdf

1. 三级模式-两级映像

内模式:管理如何存储物理的数据,对应具体物理存储文件。

模式:又称为概念模式,就是我们通常使用的基本表,根据应用、需求将物理数据划分成一张张表。

外模式:对应数据库中的视图这个级别,将表进行一定的处理后再提供给用户使用

外模式一模式映像:是表和视图之间的映射,存在于概念级和外部级之间,若表中数据发生了修改,只需要修改此映射,而无需修改应用程序。

模式一内模式映像:是表和数据的物理存储之间的映射,存在于概念级和内部级之间,若修改了数据存储方式,只需要修改此映射,而不需要去修改应用程序。

2. 数据库设计

(1)需求分析:即分析数据存储的要求,产出物有数据字典、需求说明书。获得用户对系统的三个要求:信息要求、处理要求、系统要求。

(2)概念结构设计:就是设计E-R图,也即实体-联系图。工作步骤包括:选择局部应用、逐一设计分E-R图、E-R图合并。

分E-R图进行合并时,它们之间存在的冲突主要有以下3类

属性冲突。同一属性可能会存在于不同的分E-R图中。

命名冲突。相同意义的属性,在不同的分E-R图上有着不同的命名,或是名称相同的属性在不同的分E-R图中代表着不同的意义。

结构冲突。同一实体在不同的分E-R图中有不同的属性,同一对象在某一分E-R图中被抽象为实体而在另一分E-R图中又被抽象为属性。

(3)逻辑结构设计:将E-R图,转换成关系模式。工作步骤包括:确定数据模型、将E-R图转换成为指定的数据模型、确定完整性约束和确定用户视图。

(4)物理设计:步骤包括确定数据分布、存储结构和访问方式。

(5)数据库实施阶段。根据逻辑设计和物理设计阶段的结果建立数据库,编制与调试应用程序,组织数据入库,并进行试运行。

(6)数据库运行和维护阶段。数据库应用系统经过试运行即可投入运行,但该阶段需要不断地对系统进行评价、调整与修改。

真题

3. 数据模型

真题

真题

4. 关系代数

真题

5. 函数依赖

5.1. 键与约束

◆超键:能唯一标识此表的属性的组合。

◆候选键:超键中去掉冗余的属性,剩余的属性就是候选键。(就是主键中包含的都属于候选键)

◆主键:任选一个候选键,即可作为主键。

◆外键:其他表中的主键。

◆主属性:候选键内的属性为主属性,其他属性为非主属性。

◆实体完整性约束:即主键约束,主键值不能为空,也不能重复。

◆参照完整性约束:即外键约束,外键必须是其他表中已经存在的主键的值,或者为空。

◆用户自定义完整性约束:自定义表达式约束,如设定年龄属性的值必须在0到150之间。

5.2. 第一范式

5.3. 第二范式

简单来说,存在了部分函数依赖就不满足第二范式。

  • 只有联合主键 才会存在部分函数依赖
  • 不是联合主键,是单属性的主键的话,必定属于第二范式
  • 下面这个例子,主键是(学号,课程号),但是学号可以推出学生姓名,所以存在部分函数依赖。

5.4. 第三范式

简单来说,存在了传递依赖就不属于第三范式。

5.5. BC范式

简单来说,就是依赖的左边都必须是包含候选键的。

  • 下图所示的候选键有两种,一个是(S,T), 另一个是(S,J), 在候选键中的属性都是主属性,所以 STJ 都是主属性
  • 由于 T->J,但是在 SJ 这个候选键中, 因为依赖的左边都必须是包含候选键的,所以不满足 BC 范式

真题

  • 从未在右边出现过的属性,必然是候选键之一

6. 模式分解

◆范式之间的转换一般都是通过拆分属性,即模式分解,将具有部分函数依赖和传递依赖的属性分离出来,来达到一步步优化,一般分为以下两种:

◆保持函数依赖分解

保持函数依赖 方法一:

对于关系模式R,有依赖集F,若对R进行分解,分解出来的多个关系模式,保持原来的依赖集不变,则为保持函数依赖的分解。另外,注意要消除掉冗余依赖(如传递依赖)。

◆实例:设原关系模式R(A,B,C),依赖集F(A->B,B->C,A->C),将其分解为两个关系模式R1(A,B)和R2(B,C),此时R1中保持依赖A->B,R2保持依赖B->C,说明分解后的R1和R2是保持函数依赖的分解,因为A->C这个函数依赖实际是一个冗余依赖,可以由前两个依赖传递得到,因此不需要管。

◆无损分解:分解后的关系模式能够还原出原关系模式,就是无损分解,不能还原就是有损。

◆当分解为两个关系模式,可以通过以下定理判断是否无损分解:

是否无损分解 方法一:

定理:如果R的分解为p={R1,R2},F为R所满足的函数依赖集合,分解p具有无损连接性的充分必要条件是R1∩R2->(R1-R2)或者R1∩R2->(R2-R1)。

是否无损分解 方法二:

◆当分解为三个及以上关系模式时,可以通过表格法求解,如下:

真题

是否无损分解 方法一 :

R1∩R2 = C

R1-R2 = ABE

R2-R1 = D

然后从他原来个的关系模式中,看能不能 C 推出ABE,C 能不能推出 D,好像不行,所以有损分解。

是否无损分解 方法二:

表如下图,由于题目给出的 F关系中,无法退出 D,所以表格不能被填满,即是有损连接

A

B

C

D

E

R1

✔️

✔️

✔️

✖️

✔️

R2

✖️

✖️

✔️

✖️

✔️

是否函数依赖 方法一:

分解成了 R1 和 R2,在 R1 和 R2 中存在的属性是 ABCE,CD,那么在原来 F 属性中,只要是在一起的就可以,即 B->A (R1 中),A->E (R1 中),AC->B (R1 中) 都满足,但是无法得出 D->A,R2 中也一样。所以不保持函数依赖。 (如果无法判断,则选不保持函数依赖,真题中大多数都是不保持函数依赖。)

7. 并发控制

◆事务:由一系列操作组成,这些操作,要么全做,要么全不做,拥有四种特性,详解如下:

  • (操作)原子性:要么全做,要么全不做。
  • (数据)一致性:事务发生后数据是一致的,例如银行转账,不会存在A账户转出,但是B账户没收到的情况。
  • (执行)隔离性:任一事务的更新操作直到其成功提交的整个过程对其他事务都是不可见的,不同事务之间是隔离的,互不干涉。
  • (改变)持续性:事务操作的结果是持续性的。

◆事务是并发控制的前提条件,并发控制就是控制不同的事务并发执行,提高系统效率,但是并发控制中存在下面三个问题:

  • 丢失更新:事务1对数据A进行了修改并写回,事务2也对A进行了修改并写回,此时事务2写回的数据会覆盖事务1写回的数据,就丢失了事务1对A的更新。即对数据A的更新会被覆盖。
  • 不可重复读:事务2读A,而后事务1对数据A进行了修改并写回,此时若事务2再读A,发现数据不对。即一个事务重复读A两次,会发现数据A有误。
  • 读脏数据:事务1对数据A进行了修改后,事务2读数据A,而后事务1回滚,数据A恢复了原来的值,那么事务2对数据A做的事是无效的,读到了脏数据。

7.1. 封锁协议

X锁是排它锁(写锁)。若事务T对数据对象A加上X锁,则只允许T读取和修改

A,其他事务都不能再对A加任何类型的锁,直到T释放A上的锁。

S锁是共享锁(读锁)。若事务T对数据对象A加上S锁,则只允许T读取A,但不能修改A,其他事务只能再对A加S锁(也即能读不能修改),直到T释放A上的S锁。

共分为三级封锁协议,如下:

一级封锁协议:事务在修改数据R之前必须先对其加X锁,直到事务结束才释放。可解决丢失更新问题。

二级封锁协议:一级封锁协议的基础上加上事务T在读数据R之前必须先对其加S锁,读完后即可释放S锁。可解决丢失更新、读脏数据问题。

三级封锁协议:一级封锁协议加上事务T在读取数据R之前先对其加S锁,直到事务结束才释放。可解决丢失更新、读脏数据、数据重复读问题。

真题

8. 数据库安全

◆静态转储:即冷备份,指在转储期间不允许对数据库进行任何存取、修改操作;优点是非常快速的备份方法、容易归档(直接物理复制操作);

缺点是只能提供到某一时间点上的恢复,不能做其他工作,不能按表或按用户恢复。

◆动态转储:即热备份,在转储期间允许对数据库进行存取、修改操作,因此,转储和用户事务可并发执行;

优点是可在表空间或数据库文件级备份,数据库扔可使用,可达到秒级恢复;缺点是不能出错,否则后果严重,若热备份不成功,所得结果几乎全部无效。

◆完全备份:备份所有数据。

◆差量备份:仅备份上一次完全备份之后变化的数据。

◆增量备份:备份上一次备份之后变化的数据。

◆日志文件:在事务处理过程中,DBMS把事务开始、事务结束以及对数据库的插入、删除和修改的每一次操作写入日志文件。一旦发生故障,DBMS的恢复子系统利用日志文件撤销事务对数据库的改变,回退到事务的初始状态。

9. 分布式数据库

分片透明性: 用户或应用程序不需要知道逻辑上访问的表具体是如何分块存储的。

位置透明性: 应用程序不关心数据存储物理位置的改变

逻辑透明性: 用户或应用程序无需知道局部使用的是哪种数据模型

复制透明性: 用户或应用程序不关心复制的数据从何而来。

10. 数据仓库

数据仓库是一个面向主题的、集成的、非易失的、且随时间变化的数据集合,用于支持管理决策。

面向主题:按照一定的主题域进行组织的。

集成的:数据仓库中的数据是在对原有分散的数据库数据抽取、清理的基础上经过系统加工、汇总和整理得到的,必须消除源数据中的不一致性,以保证数据仓库内的信息是关于整个企业的一致的全局信息。

相对稳定的:数据仓库的数据主要供企业决策分析之用,所涉及的数据操作主要是数据查询,一旦某个数据进入数据仓库以后,一般情况下将被长期保留,也就是数据仓库中一般有大量的查询操作,但修改和删除操作很少,通常只需要定期的加载、刷新。

反映历史变化:数据仓库中的数据通常包含历史信息,系统记录了企业从过去某一时点(如开始应用数据仓库的时点)到目前的各个阶段的信息,通过这些信息,可以对企业的发展历程和未来趋势做出定量分析和预测。

10.1. 数据仓库技术

10.2. 商业智能

10.3. 反规划化技术

10.4. 大数据

真题

11. SQL

真题

目录
相关文章
|
1天前
|
存储 边缘计算 Cloud Native
“论模型驱动架构设计方法及其应用”写作框架,软考高级,系统架构设计师
模型驱动架构设计是一种用于应用系统开发的软件设计方法,以模型构造、模型转换和精化为核心,提供了一套软件设计的指导规范。在模型驱动架构环境下,通过创建出机器可读和高度抽象的模型实现对不同问题域的描述,这些模型独立于实现技术,以标准化的方式储存,利用模型转换策略来驱动包括分析、设计和实现等在内的整个软件开发过程。
|
7天前
|
存储 数据采集 数据挖掘
“湖仓一体架构及其应用”写作框架,系统架构设计师
随着5G、大数据、人工智能、物联网等技术的不断成熟,各行各业的业务场景日益复杂,企业数据呈现出大规模、多样性的特点,特别是非结构化数据呈现出爆发式增长趋势。在这一背景下,企业数据管理不再局限于传统的结构化OLTP(On-Line Transaction Processing)数据交易过程,而是提出了多样化、异质性数据的实时处理要求。传统的数据湖(Data Lake)在事务一致性及实时处理方面有所欠缺,而数据仓库(Data Warehouse)也无法应对高并发、多数据类型的处理。因此,支持事务一致性、提供高并发实时处理及分析能力的湖仓一体(Lake House)架构应运而生。湖仓一体架构在成本、
|
3天前
|
存储 消息中间件 API
“论微服务架构及其应用”写作框架,软考高级,系统架构设计师
论微服务架构及其应用近年来,随着互联网行业的迅猛发展,公司或组织业务的不断扩张,需求的快速变化以及用户量的不断增加,传统的单块(Monolithic)软件架构面临着越来越多的挑战,已逐渐无法适应互联网时代对软件的要求。在这一背景下,微服务架构模式(MicroserviceArchitecturePattern)逐渐流行,它强调将单一业务功能开发成微服务的形式,每个微服务运行在一个进程中;采用HTTP等通用协议和轻量级API实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同数据存储技术,能够通过自动化部署工具独立发布,并保持最低限制的集中式管理。
|
4天前
|
Java 数据库连接 API
“论数据访问层设计技术及其应用”写作框架,系统架构设计师
在信息系统的开发与建设中,分层设计是一种常见的架构设计方法,区分层次的目的是为了实现“高内聚低耦合”的思想。分层设计能有效简化系统复杂性,使设计结构清晰,便于提高复用能力和产品维护能力。一种常见的层次划分模型是将信息系统分为表现层、业务逻辑层和数据访问层。信息系统一般以数据为中心,数据访问层的设计是系统设计中的重要内容。数据访问层需要针对需求,提供对数据源读写的访问接口;在保障性能的前提下,数据访问层应具有良好的封装性、可移植性,以及数据库无关性。
“论数据访问层设计技术及其应用”写作框架,系统架构设计师
|
7天前
|
负载均衡 算法 架构师
系统架构设计师-软件水平考试(高级)-论文-可靠性设计
系统架构设计师-软件水平考试(高级)-论文-可靠性设计
|
12天前
|
NoSQL 架构师 Java
2024软考架构师考试---分布式锁的实现方式有那些以及优缺点
【6月更文挑战第16天】在分布式系统中,分布式锁是一种用于控制对共享资源访问的机制,以确保多进程、多线程环境下的数据一致性。分布式锁有多种实现方式,本文将介绍几种常见的分布式锁及其优缺点。
44 1
|
3天前
|
边缘计算 Cloud Native IDE
“论SOA在企业集成架构设计中的应用”写作框架,系统架构设计师
企业应用集成(Enterprise Application Integration, EAI)是每个企业都必须要面对的实际问题。面向服务的企业应用集成是一种基于面向服务体系结构(Service-OrientedArchitecture,SOA)的新型企业应用集成技术,强调将企业和组织内部的资源和业务功能暴露为服务,实现资源共享和系统之间的互操作性,并支持快速地将新的应用以服务的形式加入到已有的集成环境中,增强企业IT环境的灵活性。
|
3天前
|
运维 监控 Cloud Native
“论云原生架构及其应用”写作框架,系统架构设计师
近年来,随着数字化转型不断深入,科技创新与业务发展不断融合,各行各业正在从大工业时代的固化范式进化成面向创新型组织与灵活型业务的崭新模式。在这一背景下,以容器和微服务架构为代表的云原生技术作为云计算服务的新模式,已经逐渐成为企业持续发展的主流选择。云原生架构是基于云原生技术的一组架构原则和设计模式的集合,旨在将云应用中的非业务代码部分进行最大化剥离,从而让云设施接管应用中原有的大量非功能特性(如弹性、韧性、安全、可观测性、灰度等),使业务不再有非功能性业务中断困扰的同时,具备轻量、敏捷、高度自动化的特点。云原生架构有利于各组织在公有云、私有云和混合云等新型动态环境中,构建和运行可弹性扩展的应用
|
3天前
|
缓存 运维 监控
探索微服务架构中的API网关模式
在微服务架构的海洋中,API网关是连接客户端与众多微服务群岛之间的桥梁。本文将深入探讨API网关的设计原则、核心功能以及在现代软件架构中的关键作用,同时分析其在实际应用中的效益和面临的挑战。
|
2天前
|
存储 监控 负载均衡
深入理解微服务架构中的服务发现机制
【6月更文挑战第25天】在微服务架构中,服务发现是确保各独立服务组件能够高效、可靠通信的关键环节。本文将探讨服务发现的基本原理、核心组件以及在现代云原生应用中的最佳实践,旨在为读者提供一套系统化理解和实现服务发现机制的指导思路。

热门文章

最新文章