2025系统架构师（一考就过）：选择题基础知识四_某文件系统文件存储采用文件索引节点法。假设文件索引节点中有8个地址项iaddr[0]-CSDN博客

本文链接：https://blog.csdn.net/yinweimumu/article/details/144549156

在这里插入图片描述

考点29：设计模式

设计模式主要解决的是代码层面的复用和灵活性问题，从实用的角度来看，它代表了某一类问题的最佳实践。

架构模式关注的是整个系统的结构和交互。

创建型模式：用于创建对象，将对象的创建与使用分离。

结构型模式：关注类和对象的组合

行为型模式：关注类和对象之间的通信

结构型：适桥组装外享代

创建型	定义	关键字
Acstract Factory 抽象工厂	提供一个接口，可以创建一系列相关或相互依赖的接口，而无需指定它们具体的类	抽象接口
Builder构建器	将一个复杂类的表示与其构造相分离，使得相同的构建过程能够得到不同的表示	类和构造分离
Factory Method 工厂方法	定义一个创建对象的接口，但由子类决定需要实例化哪一个类。	子类决定实例化
Prototype 原型	用原型实例指定创建对象的类型，并且通过拷贝这个原型来创建新的对象	原型实例、拷贝
Singleton 单例	保证一个类只有一个实例，并提供一个访问它的全局访问点	唯一实例

结构型	定义	关键字
Adapter 适配器	将一个类的接口转换转换成用户希望得到的另一种接口。使得原本不相容的接口得以协同工作。	转换、兼容接口
Composite 组合模式	将类的抽象和它的实现分离开来，使它们可以独立的变化	抽象和实现分离
Bridge 桥接模式	将对象组合成树型结构以表示“整体-部分”的层次结构，使得用户对单个对象和组合对象的使用具有一致性。	整体-部分、树形结构
Decorator 装饰	动态的给一个对象添加一些额外职责。	附加职责
Facade 外观	定义一个高层接口，为一组接口提供一个一致的外观。	对外统一接口
Flyweight 享元	提供支持大量细粒度对象共享的有效方法	细粒度、共享
Proxy 代理	为对象提供一种代理以控制对这个对象的访问	代理控制

行为型	定义	关键字
Chain of Responsibility 责任链	通过给多个对象处理请求的机会，减少请求的发送者与接收者之间的耦合。将接受对象链接起来，在链中传递请求	传递请求、职责链接
Command 命令模式	将一个请求封装为一个对象，用不同的请求对客户进行参数化，将请求排队或记录请求日志，支持可撤销的操作。	日志记录、可撤销
Interpreter 解释器	给定一种语言，定义它的文法表示，并定义一个解释器，该解释器用来根据文法表示来解释语言中的句子	解释器、虚拟机
Iterator迭代器	提供一种方法来顺序访问一个聚合对象中的各个元素而不暴露该对象的内部表示	顺序访问、不暴露内部
Mediator 中介者	用一个中介对象封装一系列对象交互。使得各对象不需要显式地相互调用，还可以独立改变对象间的交互	不直接引用
Memento 备忘录	在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态，从而可以在以后将该对象恢复到原先保存的状态	保存、恢复
Observer 观察者	定义对象间的一种一对多的依赖关系，当一个对象的状态发生改变时，所有依赖于它的对象都得到通知并自动更新	通知、自动更新
State 状态	允许一个对象在其内部状态改变时改变它的行为	状态编程类
Strategy 策略	定义一系列算法，把它们一个个封装起来，并且使它们之间可以互相替换。	算法替换
Template Method 模板方法	定义一个操作中的算法骨架，而将一些步骤延迟到子类中，使得子类可以不改变一个算法的结构即可重新定义算法的某些特定步骤
Visitor 访问者	表示一个作用于某对象结构中的各元素的操作，使得在不改变各元素的类的前提下定义作用于这些元素的新操作	数据和操作分离

真题1：

在这里插入图片描述

答案：A、B

在这里插入图片描述

创建型

在这里插入图片描述

Factory Method 工厂方法模式：只生产鼠标的工厂，可以生产、创造不同品牌的鼠标（对象），比如华为、小米等。子类决定实例化

Abstract Factory 抽象工厂模式：工厂概念的进一步抽象，有生产鼠标的工厂，有生产键盘的工厂，有生产屏幕的工厂等。工厂扩展后，就可以是鼠标工厂、键盘工厂、屏幕工厂。比如这里定义工厂具有 create 即生产这个行为；需要鼠标工厂，就扩展工厂为 createMouse等。抽象接口

Builder 构建器模式：比如创建一个人物，要创建身体、脸型、发型进而组合成一个人物。通过提供创建不同身体（胖的、瘦的）、创建不同脸型（大的、小的）创建不同发型（长发、短发）等，进而组合成一个人物。类和构造分离

Prototype 原型模式：原来有个原型、对象，然后直接Copy 这个对象的代码，然后改一改变成新的对象、原型。 原型实例，拷贝。

结构型：适桥组装外享代

在这里插入图片描述

Adapter 适配器模式：转换，兼容接口。

Bridage 桥接模式：抽象和实现分离。 比如学习资料，抽象层可以分为纸质资料、电子资料；具体的载体、实现可以是文字、图片。这样就在抽象和实现之间构建了一个桥梁：

在这里插入图片描述

这样就有了纸质文字、纸质图片、电子文字、电子图片四种形式了。

抽象和实现是分开的，都可以单独扩展，比如扩展实现的增加一个视频形式等。

Composite 组合模式：整体-部分，树形结构。文件夹与文件、总公司与各地子公司。

Decorator 装饰模式：运行时、动态增加额外职责。

Facade 外观模式：对外统一接口。比如智能家居的一个家居模式，一个家居模式的接口、按钮，就可以把电视的接口、风扇的接口、电灯的接口一次唤起

Flyweight 享元模式：细粒度，共享。汉字、语音识别、输入法等，当要编写一句话的时候，不能每一句话中的每个字都单独创建一个对象，这个时候就把常见的比如2000个字创建2000个对象，当要写一句话的时候，就从共享的2000个对象中抽出从而组合成这句话，这样就永远是2000个对象。

Proxy 代理模式：代理控制，比如软件的快捷方式。

行为型：职责命令解释迭代中介

在这里插入图片描述

Chain of Responsibility 职责链模式：传递请求、职责链接。比如请假流程，对个对象处理请求等。

Command 命令模式：日志记录、可撤销。

Interperter 解释器模式：解释器、虚拟机。比如游戏中自定义游戏地图、自定义游戏难度等

Iterator 迭代器模式：顺序访问，不暴露内部。

Mediator 中介者模式：不直接引用，对象交互。中介：买方、卖方、中介。ESB（企业服务总线）就是中介者模式。

在这里插入图片描述

Memento 备忘录模式：保存、恢复。比如游戏的存档、读档。

Oserver 观察者模式：通知、自动更新。比如订阅微信公众号，公众号文章更新就会通知订阅它的人。

State 状态模式：状态变成类，比如会员模式：超级会员、普通会员等。会员等级发生改变时，对应的权限、行为也发生改变了。

Strategy 策略模式：算法替换

Template Method 模板方法模式：使用模板。

Visitor 访问者模式：数据和操作分离，比如人的、类的固有属性、数据结构是不会改变的：比如名字、身份证，但是行为是改变的：比如幼儿时是爬着的，长大了就是能走、能跑了。

考点30、自动机

在这里插入图片描述

不确定的有限自动机：NFA

上图可以这么理解：S0 输入 a 就变成了 S1，S0 输入 b 就变成了 S2

两个环（圆圈）就是结束状态。

确定的有限自动机就是：S0 输入 a 就一定变成 S1。

在这里插入图片描述

不确定的有限自动机就是：S0 输入 a 可能还是 S0，也可能输入 a 变成 S1.

NFA 和 DFA 等价转换方法：

在这里插入图片描述

ε 表示空串（即不需要任何输入），比如上图：S0 输入 0 就会变为 S1,但 S1 可以通过空串 ε 不输入也能变为 S2。

上图中的 S2 和 S3 的变换是一个循环，体现了两个点：1、S2通过 1 变为 S3, 2、S3 通过空串可以转为 S2.

所以这个循环里必须包含 1 和空串。

所以答案是 C。上图中DFA 中必须体现所有 NFA 中的输入：输入0可以变为其他、输入1也可以变为其他、通过1也有循环、起点终点输入为0

考点31：软件需求：业务、用户、系统、功能需求

软件需求分为三大类（重要）：

◆业务需求:反映企业或客户对系统高层次的目标要求通常来自项目投资人
客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。（不懂开发的人，提出的业务需求，比如提出要手机上可以使用等）

◆用户需求:描述的是**用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。**通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。

◆系统需求:从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

1)功能需求:也称为行为需求，规定了**开发人员必须在系统中实现的软件功能，**用户利用这些功能来完成任务，满足业务需要。

2)非功能需求:指系统必须具备的属性或品质，又可以细分为软件质量属性
(如可维护性、可靠性、效率等)和其他非功能需求。

3)设计约束:也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

质量功能部署（QFD）是一种将用户要求转换成软件需求的技术。QFD将软件需求分为三类：

（1）常规需求：用户认为系统应该做到的功能或性能，实现越多用户越满意。

（2）期望需求：用户想当然认为系统应该具备的功能或性能，但很难正确描述出来或没有写在需求说明书里、合同里的自己想要得到的这些功能或性能需求，比如它可能是常规性、常识性的东西，比如系统里要有复制粘贴功能等。比如它也可能是很高级、很难描述，但想要有的东西。如果期望需求没有得到实现，会让用户感到不满意。

（3）意外需求。意外需求也称之为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不识实现也不影响其购买的决策。

在这里插入图片描述

答案：

1、B、用户需求（非常具体、细节，第一句和第三句是对应的。）

2、C、功能需求

3、A、业务需求（相对抽象，只说了能纠正，但没说怎么做）

考点32：计算：一级索引、二级索引

真题1：某文件系统采用多级索引结构，若磁盘块的大小为1KB，每个块号需占3B，那么采用二级索引时的文件最大长度为（11628）KB。

解析：

块号：1024/3 = 341（取整）

一级：341 * 1KB = 341KB

二级：341 * 341 * 1KB = 116281KB

某文件系统文件存储采用文件索引节点法。假设文件索引节点中有8个地址项iaddr[0]~iaddr[7]，每个地址项大小为4字节，其中地址项 iaddr[0]~iaddr[4]为直接地址索引，iaddr[5]、iaddr[6]是一级间接地址索引，iaddr[7]是二级间接地址索引，磁盘索引块和磁盘数据块大小均为1KB，若要访问iclsClient.dll文件的逻辑块号分别为1、518，则系统应分别采用（ )。

A：直接地址索引、直接地址索引

B：直接地址索引、一级间接地址索引

C：直接地址索引、二级间接地址索引

D：一级间接地址索引、二级间接地址索引

答案：C

解析：

注意从0开始编号。0-4直接地址索引表示逻辑块号0-4,一个一级间接地址索引可表示 1KB/4B=256个直接盘块，因此5，6两个一级索引表示逻辑块号5-516，因此518处于二级间接地址范围。

4字节 = 4B，1B=8bit

在这里插入图片描述

8个地址项，5个未直接索引，所以是 0 - 4 为直接索引，2个一级间接，1个二级间接

所以磁盘索引块：

直接索引：0~4

一级间接：5~(1KB/4B) * 2 + 5 - 1 = 5 ~ 516

二级间接：517~(1KB/4B) * (1KB*4B) + 517 - 1 = 517 ~ 256 * 256 + 517 - 1

上式中的 1KB为磁盘索引块的大小，因为这里计算的是逻辑块号的编号。

单个文件的最大长度则需要计算磁盘数据块的大小了（也为1KB）：

直接索引大小：（4 - 0 + 1）* 1KB = 5KB

一级间接：（516 - 5 + 1）* 1KB = 512KB

二级间接：（256 * 256 + 517 - 1 - 517 + 1） = 256 * 256 KB = 65536KB

总共大小：5 + 512 + 65536 = 66053KB

考点33：配置管理

真题1：配置管理包括（软件配置标识、变更管理、版本控制、系统建立、配置审核和配置状态报告）。

（）的常见功能包括版本控制、变更管理、配置状态管理、访问控制和安全控制等。

A：软件测试工具

B：版本控制工具

C：软件维护工具

D：软件配置管理工具

答案：D

产品配置是指一个产品在其生命周期各个阶段所产生的各种形式(机器可读成人工可读)和各种版本的( 软件全生命周期文档、程序、产品等)的集合。

配置项的定义，软件全生命周期文档、程序、产品等。

◆以下内容都可以作为配置项进行管理:外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。
◆典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例,运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。
◆每个配置项的主要属性有:名称、标识符、文件状态、版本、作者、日期等
◆配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等;非基线配置项可能包括项目的各类计划和报告等。
◆所有配置项的操作权限应由CMO(配置管理员)严格管理，基本原则是:基线配置项向开发人员开放读取的权限;非基线配置项向PM、CCB及相关人员开放。

◆配置项的状态可分为**“草稿”“正式”和“修改”三种。配置项刚建立时其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。**如图所示：

◆配置项版本号：0 开头就是草稿，X.Y 为正式状态，X.YZ 为修改状态。
(1)处于**“草稿"状态的配置项的版本号格式为0.YZ**,YZ的数字范围为01~99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。

(2)处于**“正式"状态的配置项的版本号格式为X.Y**，X为主版本号，取值范围为1一9。Y为次版本号，取值范围为0~9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0,1.1…。当附件的变动积累到一定程度时，配置项的值可适量增加，Y值增加一定程度时,X值将适量增加。当配置项升级幅度比较大时，才允许直接增大x值。

(3)处于**“修改"状态的配置项的版本号格式为X.YZ**。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项修改完毕，状态成为“正式”时，将Z值设置为0,增加X.Y值。参见上述规则(2)。

◆配置项版本管理:在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本“好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

◆基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线(Release)，内部开发使用的基线一般称为构造基线(Build)

◆一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。

◆产品的一个测试版本(可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等)是基线的一个例子。

◆建立基线还可以有如下好处:
(1)基线为开发工作提供了一个定点和快照。
(2)新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目(在主要分支上)所进行的变更进行隔离。

(3)当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法

(4)可以利用基线重新建立基于某个特定发布版本的配置，以重现已报告的错误。

◆配置库存放配置项并记录与配置项相关的所有信息，是配置管理的有力工具。主要作用:

◆使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。

考点34：数据库之外模式、模式、内模式、SQL语言

真题：采用三级结构/两级映像的数据库体系结构，如果对数据库的一张表创建聚簇索引，改变的是数据库的（内模式）

创建聚簇索引意味着中心确定表中数据的物理顺序。

在这里插入图片描述

1、三级模式-两级映像（考点）

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

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

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

**外模式-模式映像（逻辑上）：**是视图和和之间的映射，存在于概念级和外部级之间，若表中数据发生了修改，只需要修改此映射，而无需修改应用程序。

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

表：是行列组成，比如

年龄	性别	学历
22	女	本科
25	男	硕士
27	女	博士

视图：是业务需要的通过 SQL 语句筛选、查询出来的表的数据的一部分，这部分正是业务需要的。即视图是表的一部分，比如业务需要知道表中女性员工的信息，于是得到：

年龄	性别	学历
22	女	本科
27	女	博士

视图是一张假表，筛选、查询出来的临时表，修改此临时表，不会影响数据库中的表。

模式映像的目的是数据库数据修改后，业务/应用层数据不需要修改。即无论数据库数据怎么变，业务层的代码、SQL语句不需要变。因为数据库中的数据是频繁变动的。

2、事务

在这里插入图片描述

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

（操作）原子性：要么全做，要么全不做。比如做了查询等，突然断电了，则已经做的就全都撤销。

（数据）一致性：事务发生后数据是一致的，例如银行转账，不会存在A账户转出，但是B账户没收到的情况。

（执行）隔离性：任一事务的更新操作直到其成功提交的整个过程对其他事务都是不可见的，不同事务之间是隔离的，互不干涉。

（改变）持续性：事务操作的结果是持续性的。

3、SQL语句

真题：

在这里插入图片描述

答案：A、D、C

SQL 语法关键字：

创建表：create table；

指定主键 primary key()；

指定外键 foreign key();

修改表 alter table;

删除表 drop table；

在这里插入图片描述

下图需要掌握：(考点)

在这里插入图片描述

GROUP BY 是跟 SELECT 中的内容对应的，比如 SELECT 零件号，ADV(库存量) as 平均库存量，则后面的 GROUP BY 后面的一定是零件号，即 SELECT 中可用于分组的内容。

在这里插入图片描述

SELECT 中有 AVG、MAX、MIN 等，则后面一定是 GROUP BY，而不会是 ORDER BY。

在这里插入图片描述

考点35：共享锁、排它锁

加了排它锁（也叫写锁，也叫X锁），则不能再加任何锁；

加了共享锁（也叫读锁，也叫S锁），则可以继续加读锁。

考点36：模式分解：有损、无损分解、范式、候选关键字、主属性

主键和全码

候选码：能够唯一标识一条记录的最小属性集
主码：某个能够唯一标识一条记录的最小属性集（是从候选码里人为挑选的一条）
外码：如果一个关系中的一个属性是另外一个关系中的主码则这个属性为外码
全码：当所有的属性共同构成一个候选码时，这时该候选码为全码。（教师，课程，学生）假如一个教师可以讲授多门课程，某门课程可以有多个教师讲授，学生可以听不同教师讲授的不同课程，那么，要区分关系中的每一个元组，这个关系模式]R的候选码应为全部属性构成（教师、课程、学生），即主码。
主属性：包含在任一候选码中的属性称主属性。简单来说，主属性是候选码所有属性的并集。
非主属性不包含在候选码中的属性称为非主属性。非主属性是相对于主属性来定义的。

传递依赖

员工号->岗位，岗位->基本工资；根据 Armstrong 公理系统的传递律规则，员工号->基本工资。

在这里插入图片描述

答案：A

在这里插入图片描述

第一范式：不可分，原子属性

第二范式：非主属性完全依赖于任何一个候选码（而不是部分依赖于，即候选码完全决定非主属性）

第三范式：没有传递依赖（非主属性对码）

BCNF范式：主属性对于码没有部分函数依赖和传递依赖，即依赖关系的左边都包含候选键。

在这里插入图片描述

候选关键字的求法：

根据依赖集，找出从未在右边出现过的属性，必然是候选键之一（候选键可以唯一标识），以该属性为基础，根据依赖集依次扩展，看能否遍历所有属性，将无法遍历的加入候选键中。

1、找出从未在右边出现过的属性：

AB->C,CD->B，右侧中 A、D 都未在右侧出现过，所以 A、D必是候选键之一。

2、看1得出的候选键能否推出其他所有属性：

得知 AB 才能推出 C，CD 才能推出 B，所以A、D 不能推出其他。所以还需要加关键字。

3、添加关键字：

比如这里加 B，则 AB 可以推出 C，已经得到所有了，所以 A、D、B 为候选关键字。

比如这里加 C，则 CD 可以推出B，已经得到所有了，所以 A、D、C 为候选关键字。

所以答案为：有2个候选关键字 ACD 和 ABD

候选关键字中的所有属性都是主属性：所以 A、B、C、D都是主属性，所以有 0个非主属性和4个主属性。

第二题：

所以要先算出候选键：

1、右边未出现过的：E、M

2、E、M 可以推出所有键，且只有（E，M）可以推出，所以候选键为（E、M）

3、N完全依赖于E，但候选键为（E,M）所以部分依赖于（E,M），Q完全依赖于 EM，L 完全依赖于 M,但候选键为（E,M）所以部分依赖于（E,M）。所以没有达到第二范式。

4、所以只达到了第一范式，没有达到第二范式。

所以关系模式达到了第一范式，需要进行分解，因为存在冗余、修改操作的不一致性、插入和删除异常。

解题关键：

第二范式：没有部分依赖

第三范式：没有传递依赖

BCNF范式：左侧决定因素都在候选码之中

在这里插入图片描述

答案：D、D

给定关系模式R（U，F），其中U为属性集，F是U上的一组函数依赖，那么函数依赖的公理系统（Armstrong 公理系统）中的分解规则是指（）为F所蕴涵。

A：若X→Y，Y→Z，则X→Z

B：若Y⊆X⊆U，则X→Y

C：若X→Y，Z⊆Y，则X→Z

D：若X→Y，Y→Z，则X→YZ

答案：C

解析：Armstrong公理系统设关系模式R<U，F>，其中U为属性集，F是U上的一组函数依赖，那么有如下推理规则:

① 自反性:若Y⊆X⊆U，则X→Y为F所蕴含;

② 增广性:若X→Y为F所蕴含，且Z⊆U，则 XZ→YZ为F所蕴含;

③ 传递性:若X→Y，Y→Z为F所蕴含，则X→Z为F所蕴含。

根据上面三条推理规则，又可推出下面三条推理规则:

④ 合并规则:若X→Y，X→Z，则X→YZ为F所蕴含;

⑤ 伪传递规则:若X→Y，WY→Z，则XW→Z为 F所蕴含;

⑥ 分解规则:若X→Y，Z⊆Y，则X→Z为F所蕴含。

了解Armstrong公理系统后，即可知选C。

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

保持函数依赖分解：

对于关系模式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这个函数依赖实际是一个冗余依赖，可以由前两个依赖传递得到，因此不需要管。

在这里插入图片描述