2025年数据库管理工程师职业考试试卷及答案

2025年数据库管理工程师职业考试及答案一、单项选择题（每题2分，共30分）1.以下关于关系模型中候选键的描述，正确的是（）。A.候选键是能唯一标识元组的最小属性集合B.候选键必须包含所有属性C.一个关系模式只能有一个候选键D.候选键不可以是复合属性答案：A解析：候选键是关系中能唯一标识元组的最小属性集，可能有多个（如学生表中“学号”和“身份证号”均可作为候选键），可以是单个或复合属性，因此B、C、D错误。2.在数据库设计中，将E-R模型转换为关系模式时，多对多联系（M:N）的处理方式是（）。A.将其中一个实体的主键加入另一个实体的关系模式B.创建一个新的关系模式，包含两个实体的主键和联系的属性C.直接合并两个实体的关系模式D.忽略联系，仅保留实体属性答案：B解析：M:N联系无法直接转换为实体的属性，需新建关系模式，主键为两个实体主键的组合（如“学生-课程”联系需创建“选课”表，包含学号、课程号和成绩）。3.事务的原子性（Atomicity）主要通过（）实现。A.日志（Redo/UndoLog）B.索引优化C.并发控制D.备份策略答案：A解析：原子性要求事务要么全做要么全不做，通过日志记录事务操作，异常时通过Undo（撤销未完成操作）和Redo（重做已提交但未持久化的操作）保证。4.某数据库表T包含字段（ID,Name,Age,Salary），其中ID为主键。若频繁执行查询“SELECTNameFROMTWHEREAge=25ANDSalary>10000”，最适合建立的索引是（）。A.对Age字段的单列索引B.对Salary字段的单列索引C.对（Age,Salary）的复合索引D.对（Salary,Age）的复合索引答案：C解析：查询条件为Age=25且Salary>10000，复合索引（Age,Salary）可先按Age快速定位，再在Age=25的范围内按Salary过滤，比单列索引更高效。若顺序为（Salary,Age），则Salary>10000是范围查询，无法有效利用Age的等值条件。5.以下关于数据库并发控制中“三级封锁协议”的描述，错误的是（）。A.一级封锁协议可防止“丢失修改”B.二级封锁协议可防止“读脏数据”C.三级封锁协议可防止“不可重复读”D.三级封锁协议要求事务在提交后释放所有锁答案：D解析：三级封锁协议要求事务在整个生命周期内持有锁（直到事务结束才释放），而二级封锁协议在读取数据后即可释放共享锁。因此D错误。6.某数据库采用RAID-5技术，若有5块磁盘，其中1块损坏，此时（）。A.数据完全丢失，无法恢复B.可利用校验盘和剩余数据盘恢复损坏数据C.必须更换损坏磁盘并重新初始化D.只能恢复部分关键数据答案：B解析：RAID-5将数据和校验信息分布在所有磁盘上，任意一块磁盘损坏时，可通过剩余磁盘的校验信息重建数据。7.在数据库备份策略中，“差异备份”的特点是（）。A.每次备份所有自上一次完全备份以来变化的数据B.每次备份所有自上一次任意类型备份以来变化的数据C.仅备份数据库结构，不备份数据D.备份速度最快，但恢复时间最长答案：A解析：差异备份基于最近一次完全备份，备份所有修改过的数据；增量备份基于最近一次任意备份（包括增量或差异）。因此A正确。8.以下不属于数据仓库典型特征的是（）。A.面向主题（Subject-Oriented）B.实时性（Real-Time）C.集成性（Integrated）D.时变性（Time-Variant）答案：B解析：数据仓库用于分析决策，数据是历史的、集成的，不要求实时更新；实时性是OLTP系统的特征。9.某关系模式R（A,B,C,D），函数依赖集F={AB→C,C→D,D→A}，则R的主码是（）。A.ABB.BCC.CDD.BD答案：D解析：主码是能唯一确定所有属性的最小属性集。BD的闭包：BD+=BD（初始）→BDC（AB→C，但AB不在BD中？需重新计算：-已知D→A，因此BD→BDA；-AB→C（A已由D→A得到），因此BDA→BDAC；-C→D（D已存在），因此BD+=BDACD=ABCD。故BD是主码。10.关于数据库安全的“强制访问控制（MAC）”，以下描述正确的是（）。A.用户可自主设置数据的访问权限B.基于用户角色分配权限C.系统根据数据和用户的安全级别进行访问控制D.仅允许数据库管理员修改权限答案：C解析：MAC是系统强制的，根据主体（用户）和客体（数据）的安全级别（如绝密、机密、秘密）决定访问权限，用户无法自主修改。11.在MongoDB中，以下关于集合（Collection）和文档（Document）的描述，错误的是（）。A.集合是文档的无序集合B.文档使用JSON格式存储C.集合中的文档必须具有相同的结构D.集合无需显式创建，插入文档时自动生成答案：C解析：MongoDB是模式自由（Schema-less）的，同一集合中的文档可以有不同字段，因此C错误。12.某SQL查询语句为“SELECTFROMOrdersWHEREOrderDateBETWEEN'2024-01-01'AND'2024-12-31'”，若OrderDate字段未建立索引，数据库最可能采用（）执行该查询。A.全表扫描（FullTableScan）B.索引扫描（IndexScan）C.嵌套循环连接（NestedLoopJoin）D.哈希连接（HashJoin）答案：A解析：无索引时，数据库只能逐行扫描表数据，即全表扫描。13.以下关于数据库容灾的描述，正确的是（）。A.本地备份属于容灾范畴B.热备中心可实现秒级恢复C.容灾等级越高，成本越低D.容灾仅需考虑硬件故障答案：B解析：热备中心与主中心实时同步数据，故障时可快速切换（秒级）；本地备份无法应对区域性灾难（如地震），不属于容灾；容灾等级越高（如数据实时同步），成本越高；容灾需考虑硬件、软件、人为错误等多因素。14.在HBase中，RowKey的设计原则不包括（）。A.散列性（避免热点）B.长度越短越好C.顺序性（支持范围查询）D.与业务无关性答案：D解析：RowKey需与业务需求结合（如时间戳、用户ID），以支持高效的范围查询或随机访问，因此“与业务无关”错误。15.数据库性能调优中，“执行计划（ExecutionPlan）”的作用是（）。A.展示查询语句的逻辑结构B.记录数据库的操作日志C.描述数据库管理系统执行查询的具体步骤（如索引使用、连接方式）D.统计数据库的访问频率答案：C解析：执行计划是数据库优化器生成的查询执行步骤，包括使用的索引、连接算法、扫描方式等，用于分析查询效率。二、填空题（每题2分，共20分）1.数据库系统的三级模式结构包括外模式、模式和__________。答案：内模式2.关系数据库中，消除非主属性对候选键的部分函数依赖可达到__________范式（填具体级别）。答案：第二（2NF）3.事务的隔离级别中，“可重复读（RepeatableRead）”会导致__________问题（填一种并发异常）。答案：幻读（PhantomRead）4.索引按存储结构可分为B+树索引、哈希索引和__________索引（列举一种）。答案：位图（或全文、R树等）5.数据库备份中，__________备份需要先关闭数据库，确保数据一致性。答案：冷（脱机）6.数据仓库的ETL过程包括抽取（Extract）、转换（Transform）和__________（Load）。答案：加载7.在MySQL中，InnoDB存储引擎的默认事务隔离级别是__________。答案：可重复读（RepeatableRead）8.分布式数据库中，__________算法用于解决多个节点间的一致性问题（如ZooKeeper）。答案：Paxos（或Raft）9.数据库安全性控制中，__________是指防止未授权用户访问数据（填核心目标）。答案：数据保密（或访问控制）10.在Redis中，__________数据结构可用于存储有序的字符串集合，支持按分数排序。答案：有序集合（SortedSet）三、简答题（每题8分，共40分）1.简述数据库设计中“概念设计”到“逻辑设计”的转换步骤，并举例说明E-R模型中“弱实体”的处理方法。答案：转换步骤：（1）将E-R模型中的实体转换为关系模式，实体属性对应关系的字段，实体主键对应关系主键；（2）处理实体间的联系：1:1联系可将任一实体的主键加入另一实体；1:N联系将“1”方主键加入“N”方；M:N联系新建关系模式，包含双方主键和联系属性；（3）处理特殊属性（如多值属性、派生属性）：多值属性需拆分为独立关系，派生属性通常不存储。弱实体处理：弱实体依赖于强实体存在（如“订单明细”依赖“订单”），其主键需包含强实体的主键。例如，订单（订单ID，客户ID）是强实体，订单明细（行号，订单ID，商品ID，数量）是弱实体，主键为（订单ID，行号），其中订单ID来自强实体。2.分析数据库死锁产生的原因，并说明死锁检测与死锁预防的区别。答案：死锁原因：多个事务因争夺资源（如锁）而形成循环等待。例如，事务T1持有资源A并请求资源B，事务T2持有资源B并请求资源A，导致循环等待。区别：（1）死锁预防：通过限制事务的加锁顺序、一次性申请所有资源等策略，从根本上避免死锁发生；（2）死锁检测：允许死锁发生，通过定期检查事务等待图（检测是否存在循环）发现死锁，然后终止其中一个事务（牺牲品）以解除死锁。预防策略更主动，但可能降低并发性能；检测策略更灵活，但需额外的检测开销。3.某电商数据库中，订单表（OrderID,UserID,OrderTime,Amount）数据量达1亿条，常见查询为“按UserID查询近一年的订单，按OrderTime排序”。请提出索引优化方案，并说明理由。答案：优化方案：创建复合索引（UserID,OrderTimeDESC）。理由：（1）查询条件为UserID（等值查询）和OrderTime（范围查询，近一年），复合索引可先按UserID快速定位用户的所有订单，再在该用户范围内按OrderTime排序，避免全表扫描；（2）OrderTime采用降序索引（DESC）与查询的排序需求（按OrderTime排序）一致，可直接利用索引排序，无需额外的文件排序（Filesort）操作；（3）若仅创建UserID单列索引，虽然能快速定位用户，但需对该用户的所有订单按OrderTime扫描过滤，效率低于复合索引。4.比较“物理备份”与“逻辑备份”的优缺点，并说明各自适用场景。答案：物理备份：直接复制数据库的物理文件（如数据文件、日志文件）。优点：备份/恢复速度快（无需解析数据），适合大规模数据库；缺点：与数据库引擎绑定（如MySQL的物理备份无法直接恢复到PostgreSQL），无法选择性恢复单个表。逻辑备份：通过SQL语句导出数据（如mysqldump生成INSERT语句）。优点：格式通用（文本形式），可跨平台恢复，支持单表恢复；缺点：备份/恢复速度慢（需解析执行SQL），大规模数据库时效率低。适用场景：物理备份适用于生产环境的高可用部署（如主从复制）；逻辑备份适用于小数据量迁移或需要跨版本恢复的场景。5.说明NoSQL数据库（如Cassandra）与关系数据库在数据模型和适用场景上的主要差异。答案：数据模型差异：（1）关系数据库：基于二维表，严格遵循关系模型，支持ACID特性；（2）NoSQL（如Cassandra）：采用灵活的数据模型（如宽列存储、键值对），不强制模式一致性，支持最终一致性。适用场景差异：（1）关系数据库：适用于事务性强、数据结构固定的场景（如银行交易、订单管理）；（2）Cassandra：适用于高并发、海量数据、读写性能要求高的场景（如日志存储、实时统计），尤其擅长处理分布式环境下的扩展性问题。四、综合应用题（每题15分，共30分）问题1：某医院需设计电子病历数据库，核心需求如下：-患者信息：姓名、性别、出生日期、身份证号（唯一）；-病历信息：就诊时间、主诉、诊断结果、主治医生（医生有姓名、科室、执业编号）；-支持按患者身份证号查询其所有病历，按就诊时间倒序排列；-需保证医生修改已提交病历的操作可追溯（记录修改人、修改时间）。（1）绘制核心E-R图（实体、属性、联系，无需严格图形，用文字描述）；（2）设计关系模式，标注主键和外键；（3）提出索引优化方案；（4）设计病历修改的可追溯实现方案。答案：（1）E-R图描述：-实体1：患者（患者ID，姓名，性别，出生日期，身份证号），主键：身份证号（唯一）；-实体2：医生（医生ID，姓名，科室，执业编号），主键：执业编号（唯一）；-实体3：病历（病历ID，就诊时间，主诉，诊断结果，患者身份证号，医生执业编号），主键：病历ID；-联系：患者与病历是1:N（一个患者有多个病历），联系属性：无；医生与病历是1:N（一个医生可写多个病历），联系属性：无；-附加实体：病历修改日志（日志ID，病历ID，修改前内容，修改后内容，修改人（医生执业编号），修改时间），主键：日志ID，外键：病历ID→病历.病历ID，医生执业编号→医生.执业编号。（2）关系模式：-患者（身份证号PK，姓名，性别，出生日期）；-医生（执业编号PK，姓名，科室）；-病历（病历IDPK，就诊时间，主诉，诊断结果，患者身份证号FK（患者.身份证号），医生执业编号FK（医生.执业编号））；-病历修改日志（日志IDPK，病历IDFK（病历.病历ID），修改前内容，修改后内容，修改人FK（医生.执业编号），修改时间）。（3）索引优化：-在病历表的（患者身份证号，就诊时间DESC）上建立复合索引，支持“按身份证号查询所有病历并按就诊时间倒序”的需求，避免全表扫描和额外排序；-在病历修改日志表的（病历ID，修改时间）上建立索引，便于追溯某病历的修改历史。（4）可追溯方案：-当医生修改病历时，系统自动触发触发器或应用层逻辑，记录修改前的主诉、诊断结果到“修改前内容”字段，修改后的内容到“修改后内容”字段；-记录修改人的执业编号（通过当前登录医生的会话获取）和修改时间（数据库服务器时间）；-限制直接修改病历表的原始数据，所有修改必须通过应用层接口，确保日志被强制记录；-对病历表设置“只读”权限（除特定管理账户外），防止恶意篡改。问题2：某电商数据库出现慢查询，SQL语句如下（表结构：订单表Orders（OrderIDPK,UserID,Status,CreateTime,TotalAmount），用户表Users（UserIDPK,Username,Level））：```sqlSELECTu.Username,o.TotalAmount,o.CreateTimeFROMOrdersoLEFTJOINUsersuONo.UserID=u.UserIDWHEREo.Status='已支付'ANDo.CreateTime>'2024-01-01'ORDERBYo.CreateTimeDESCLIMIT100;```执行计划显示：Orders表使用全表扫描，Users表使用全表扫描，且排序操作消耗大量时间。（1）分析慢查询的可能原因；（2）提出优化措施（包括索引优化、查询重写、其他可能的调整）；（3）说明优化后预期的性能提升。答案：（1）慢查询原因：-Orders表无针对（Status,CreateTime）的索引，导致全表扫描过滤“Status='已支付'且CreateTime>'2024-01-01'”的记录；-Users表通过UserID关联，但未建立UserID索引（虽然UserID是主键，通常已有索引，但可能因统计信息过时导致优化器未选择）；-排序操作（ORDERBYCreateTimeDESC）在大量数据上执行，未利用索引排序；-LEFTJOIN可能返回大量中间结果，增加处理时间。（2）优化措施：①索引优化：-在Orders表创建复合索引（Status,CreateTimeDESC,UserID,TotalAmount）：-Status='已支付'是等值条件，CreateTime>'2024-01-01'是范围条件，复合索引可快速定位目标记录；-包含UserID（用于JOIN）和TotalAmount（查询需要）