正确答案:

题目：某公司的商品（商品号，商品名称，生产商，单价）和仓库（仓库号，地址，电话，商品号，库存量）两个实体之间的关系如表2-22和表2-23所示。商品关系的主键是（1）；仓库关系的主键是（2）；仓库关系（3），为了解决这一问题，需要将仓库关系分解为（4）。

解析：从试题中所给出的表格来看，商品关系的主键是商品号，仓库关系的主键是（仓库号，商品号）。显然，仓库关系存在冗余、修改操作的不一致，以及插入异常和删除异常。例如，仓库号为"01"的商品有3种，其地址就要重复3次，故存在冗余。为了解决仓库关系模式存在的问题，就需要进行模式分解，其中（45）空选项A存在的问题是仓库2不属于第三范式，因为存在非主属性对键的部分函数依赖，即"仓库号→电话"。选项B存在的问题是分解属于有损联接，即分解的新关系模式仓库1和仓库2无法恢复到原关系。选项C分解存在的问题与A类同。选项C分解即保持函数依赖，又是无损联接。

查看原题 查看所有试题

学习资料的答案和解析：

[单选题]在数据库设计的需求分析阶段应完成包括（）在内的文档。

数据字典和数据流图

解析：本题考查数据库设计方面的相关知识。数据库的设计主要分为：需求分析阶段、概念设计阶段、逻辑设计阶段、物理设计阶段。需求分析阶段的任务是对现实世界要处理的对象（组织、部门和企业等）进行详细调查，在了解现行系统的概况、确定新系统功能的过程中收集支持系统目标的基础数据及处理方法。需求分析是在用户调查的基础上，通过分析，逐步明确用户对系统的需求。在需求分析阶段应完成的文档是数据字典和数据流图。概念设计阶段的任务是完成用户的数据模型，这种模型是与DBMS无关的概念模型，常见的有E-R模型。逻辑设计阶段的任务是将概念模型转换成具体的关系模式。物理设计阶段的任务是将关系模式加入DBMS的特性，成为具体某个DBMS的数据库。

[单选题]（）是一种信息分析工具，能自动地找出数据仓库中的模式及关系。

数据挖掘

解析：本题考查的是数据挖掘的基本概念。

[单选题]某商场商品数据库的商品关系模式P（商品代码，商品名称，供应商，联系方式，库存量），函数依赖集F={商品代码→商品名称，（商品代码，供应商）→库存量，供应商→联系方式}。商品关系模式P达到（1）；该关系模式分解成（2）后，具有无损连接的特性，并能够保持函数依赖。

解析：本题考查数据库的规范化。要分析一个关系模式的范式，第一步应找出该关系模式的主键，接下来需要判断关系模式是否消除了非主属性对主键的部分依赖、传递依赖，这样便可得出结论。首先可采用图示法求关系模式的主键。将关系模式P，使用图示法表达，如图2-8所示。从图中可以看出，只有商品代码与供应商的组合键才能遍历全图，所以只有它们的组合能充当主键。由于（商品代码，供应商）是主键，而又有函数依赖：商品代码→商品名称，这便形成了部分依赖。所以在此关系模式中，部分依赖未消除，其范式只能达到1NF。接下来的这个问题，对于经验丰富的考生，看完这几个选项，应该是能直接判断出应选D的。因为D是最佳分拆方案，能达到的范式级别很高。如无经验，可考虑先分析是否为保持函数依赖的分解。A选项分析：P1（商品代码，联系方式）未保持任何原有的函数依赖。而P2（商品名称，供应商，库存量）也未保持任何原有的函数依赖。B选项分析：P1（商品名称，联系方式）未保持任何原有的函数依赖。P2（商品代码，供应商，库存量）只保持了函数依赖：（商品代码，供应商）→库存量。这样对整体来说，就丢失了两个函数依赖关系。C选项分析：P1（商品代码，商品名称，联系方式）保持了函数依赖：商品代码→商品名称，P2（供应商，库存量）未保持任何原有的函数依赖。这样对整体来说，就丢失了两个函数依赖关系。D选项分析：P1（商品代码，商品名称）保持了函数依赖：商品代码→商品名称，P2（商品代码，供应商，库存量）保持了函数依赖：（商品代码，供应商）→库存量，P3（供应商，联系方式）保持了函数依赖：供应商→联系方式。这样将各个分拆关系的函数依赖整合起来，能构成原关系的函数依赖，所以这个分解是保持了函数依赖的分解。

[单选题]在数据库系统中，“事务”是访问数据库并可能更新各种数据项的一个程序执行单元。为了保证数据完整性，要求数据库系统维护事务的原子性、一致性、隔离性和持久性。针对事务的这4种特性，考虑以下的架构设计场景。假设在某一个时刻只有一个活动的事务，为了保证事务的原子性，对于要执行写操作的数据项，数据库系统在磁盘上维护数据库的一个副本，所有的写操作都在数据库副本上执行，而保持原始数据库不变，如果在任一时刻操作不得不中止，系统仅需要删除副本，原数据库没有受到任何影响。这种设计策略称为（1）。事务的一致性要求在没有其他事务并发执行的情况下，事务的执行应该保证数据库的一致性。数据库系统通常采用（2）机制保证单个事务的一致性。事务的隔离性保证操作并发执行后的系统状态与这些操作以某种次序顺序执行（即可串行化执行）后的状态是等价的。两阶段锁协议是实现隔离性的常见方案，该协议（3）。持久性保证一旦事务完成，该事务对数据库所做的所有更新都是永久的，如果事务完成后系统出现故障，则需要通过恢复机制保证事务的持久性。假设在日志中记录所有对数据库的修改操作，将一个事务的所有写操作延迟到事务提交后才执行，则在日志中（4）。当系统发生故障时，如果某个事务已经开始，但没有提交，则该事务应该（5）。

解析：本题主要考查数据库系统架构设计知识。在数据库系统中，“事务”是访问并可能更新各种数据项的一个程序执行单元。为了保证数据完整性，要求数据库系统维护事务的原子性、一致性、隔离性和持久性。题干中第1个架构设计场景描述了数据库设计中为了实现原子性和持久性的最为简单的策略：“影子拷贝”。该策略假设在某一个时刻只有一个活动的事务，首先对数据库做副本（称为影子副本），并在磁盘上维护一个dp_pointer指针，指向数据库的当前副本。对于要执行写操作的数据项，数据库系统在磁盘上维护数据库的一个副本，所有的写操作都在数据库副本上执行，而保持原始数据库不变，如果在任一时刻操作不得不中止，系统仅需要删除新副本，原数据库副本没有受到任何影响。题干中的第2个架构设计场景主要考查考生对事务一致性实现机制的理解。事务的一致性要求在没有其他事务并发执行的情况下，事务的执行应该保证数据库的一致性。数据库系统通常采用完整性约束检查机制保证单个事务的一致性。题干中的第3个架构设计场景主要考查数据库的锁协议。两阶段锁协议是实现事务隔离性的常见方案，该协议通过定义锁的增长和收缩两个阶段约束事务的加锁和解锁过程，能够保证事务的串行化执行，但由于事务不能一次得到所有需要的锁，因此该协议可能会导致死锁。题干中的第4个架构设计场景主要考查数据库的恢复机制，主要描述了基于日志的延迟修改技术（Deferred-ModificationTechruque）的设计与恢复过程。该技术通过在日志中记录所有对数据库的修改操作，将一个事务的所有写操作延迟到事务提交后才执行，日志中需要记录“事务开始”和“事务提交”时间，还需要记录数据项被事务修改后的新值，无须记录数据项被事务修改前的原始值。当系统发生故障时，如果某个事务已经开始，但没有提交，则该事务对数据项的修改尚未体现在数据库中，因此无须做任何恢复动作。

[单选题]在数据库系统中，“事务”是访问数据库并可能更新各种数据项的一个程序执行单元。为了保证数据完整性，要求数据库系统维护事务的原子性、一致性、隔离性和持久性。针对事务的这4种特性，考虑以下的架构设计场景。假设在某一个时刻只有一个活动的事务，为了保证事务的原子性，对于要执行写操作的数据项，数据库系统在磁盘上维护数据库的一个副本，所有的写操作都在数据库副本上执行，而保持原始数据库不变，如果在任一时刻操作不得不中止，系统仅需要删除副本，原数据库没有受到任何影响。这种设计策略称为（1）。事务的一致性要求在没有其他事务并发执行的情况下，事务的执行应该保证数据库的一致性。数据库系统通常采用（2）机制保证单个事务的一致性。事务的隔离性保证操作并发执行后的系统状态与这些操作以某种次序顺序执行（即可串行化执行）后的状态是等价的。两阶段锁协议是实现隔离性的常见方案，该协议（3）。持久性保证一旦事务完成，该事务对数据库所做的所有更新都是永久的，如果事务完成后系统出现故障，则需要通过恢复机制保证事务的持久性。假设在日志中记录所有对数据库的修改操作，将一个事务的所有写操作延迟到事务提交后才执行，则在日志中（4）。当系统发生故障时，如果某个事务已经开始，但没有提交，则该事务应该（5）。

解析：本题主要考查数据库系统架构设计知识。在数据库系统中，“事务”是访问并可能更新各种数据项的一个程序执行单元。为了保证数据完整性，要求数据库系统维护事务的原子性、一致性、隔离性和持久性。题干中第1个架构设计场景描述了数据库设计中为了实现原子性和持久性的最为简单的策略：“影子拷贝”。该策略假设在某一个时刻只有一个活动的事务，首先对数据库做副本（称为影子副本），并在磁盘上维护一个dp_pointer指针，指向数据库的当前副本。对于要执行写操作的数据项，数据库系统在磁盘上维护数据库的一个副本，所有的写操作都在数据库副本上执行，而保持原始数据库不变，如果在任一时刻操作不得不中止，系统仅需要删除新副本，原数据库副本没有受到任何影响。题干中的第2个架构设计场景主要考查考生对事务一致性实现机制的理解。事务的一致性要求在没有其他事务并发执行的情况下，事务的执行应该保证数据库的一致性。数据库系统通常采用完整性约束检查机制保证单个事务的一致性。题干中的第3个架构设计场景主要考查数据库的锁协议。两阶段锁协议是实现事务隔离性的常见方案，该协议通过定义锁的增长和收缩两个阶段约束事务的加锁和解锁过程，能够保证事务的串行化执行，但由于事务不能一次得到所有需要的锁，因此该协议可能会导致死锁。题干中的第4个架构设计场景主要考查数据库的恢复机制，主要描述了基于日志的延迟修改技术（Deferred-ModificationTechruque）的设计与恢复过程。该技术通过在日志中记录所有对数据库的修改操作，将一个事务的所有写操作延迟到事务提交后才执行，日志中需要记录“事务开始”和“事务提交”时间，还需要记录数据项被事务修改后的新值，无须记录数据项被事务修改前的原始值。当系统发生故障时，如果某个事务已经开始，但没有提交，则该事务对数据项的修改尚未体现在数据库中，因此无须做任何恢复动作。