[ 软考中级 软件设计师 ] 数据库题型总结_软考中级 数据库设计

1. 基本概念与理论

例题类型:

• 选择题：“在数据库系统中，保证无论数据的存储结构如何变化，应用程序不受影响的是哪种独立性？A. 物理独立性 B. 逻辑独立性 C. 用户独立性 D. 程序独立性”

解题策略: 理解数据独立性的含义，物理独立性关乎存储结构变化不影响逻辑结构，逻辑独立性指逻辑结构变化不影响应用程序。

2. ER模型与关系模型转换

例题类型:

• 设计题：“根据给定的业务需求，设计ER图，并将其转换为关系模型。”

解题策略: 分析实体、属性、联系；绘制ER图时注意识别一对一、一对多、多对多关系；转换时遵循原则，如多对多关系需转换为一个关联表。

3. SQL语言

例题类型:

• 编写题：“编写SQL语句，从’Employees’表中查询所有薪水大于5000的员工姓名和部门名。”

解题策略: 熟练掌握SELECT、FROM、WHERE、JOIN等关键字的用法，了解子查询和联接查询的技巧。

4. 数据库设计

例题类型:

• 分析题：“分析并指出给定关系模式中存在的问题，并提出改进方案使其达到3NF。”

解题策略: 识别函数依赖，判断是否存在部分函数依赖、传递函数依赖，通过分解表消除这些问题。

5. 数据库管理与优化

例题类型:

• 应用题：“解释什么是事务的ACID特性，并给出一个实际场景说明事务的使用。”

解题策略: 记忆ACID（原子性、一致性、隔离性、持久性）的定义，结合银行转账、库存管理等实例说明。

6. 数据仓库与数据挖掘

例题类型:

• 理论题：“解释OLAP的四个操作类型（切片、切块、旋转、钻取），并说明其在商业智能中的应用。”

解题策略: 了解OLAP操作的定义及其如何帮助分析多维度数据，通过案例理解其在决策支持系统中的作用。

学习建议

• 理论与实践结合：理论学习的同时，动手操作SQL语句，使用数据库管理软件进行实践。
• 历年真题演练：通过历年真题和模拟题练习，熟悉考试题型和难度。
• 系统复习：构建知识框架，定期复习巩固，尤其是易混淆的概念和细节。
• 案例学习：研究实际案例，理解数据库设计和管理中的最佳实践。
• 技术社区交流：加入相关技术论坛或社群，交流解题思路和学习经验，可以加深理解和记忆。

通过这些方法，您可以更全面、深入地准备数据库部分的考试内容。祝您备考顺利！

数据库每一层次的详细解释：

数据库应用系统的开发过程中，开发人员需要通过视图层、逻辑层次上的抽象来对用户屏蔽系统的复杂性，简化用户 与系统的交互过程。错误的是()。

A.视图层是最高层次的抽象

B.逻辑层是比视图层更低一层的抽象

C.物理层是最低层次的抽象

D.物理层是比逻辑层更高一层的抽象

答案是D，物理层是比逻辑层更高一层的抽象。实际上，物理层是最低层次的抽象，它直接描述数据是如何在硬件上存储和访问的，而逻辑层位于物理层之上，提供了更为抽象的数据组织和处理方式。

1. 视图层（View Layer）：这是用户与系统交互的最直接层面，也是抽象层次中最高的一层。视图层关注的是用户界面（UI）的设计与实现，它的主要目的是为了让用户能够以直观、简洁的方式操作和查看数据。在这个层面上，系统的内部复杂性如数据库结构、业务逻辑等都被隐藏起来，用户不需要了解这些底层细节，仅需通过图形界面、表单、按钮等元素进行操作即可。例如，网页上的按钮、输入框以及展示的信息都是视图层的一部分。

2. 逻辑层（Logic Layer 或 Business Logic Layer）：位于视图层之下，是系统中处理业务规则、数据验证、流程控制的部分。这一层负责接收来自视图层的请求，执行必要的计算、数据处理和业务逻辑判断，然后将处理结果返回给视图层展示或进一步传递到数据访问层进行存储操作。逻辑层的存在使得系统的功能模块化、可维护性增强，同时它也为视图层提供了一定程度的解耦，使得前端界面的变化不会直接影响到后端的业务逻辑实现。

3. 物理层（Physical Layer）：这是系统抽象层次中的最底层，直接涉及到数据的物理存储结构、硬件配置、文件系统布局等。物理层描述了数据如何实际存储在硬盘上，包括数据库的表结构、索引设计、存储优化策略等。它是系统实现的基础，但对于大多数应用程序开发者和最终用户而言，这一层的细节通常是透明的，用户和上层应用程序通过逻辑层接口与数据进行交互，无需直接操作物理层。因此，物理层不是比逻辑层更高一层的抽象，而是更低一层，更接近于硬件和数据的实际存储方式。]

在理解了数据库应用系统开发的这三个基本层次（视图层、逻辑层、物理层）之后，我们可以进一步探讨它们之间的关系和各自的关键作用，以及这种分层架构如何促进软件的灵活性、可维护性和扩展性。

视图层的拓展

• 多平台适配性：随着移动设备、Web、桌面等多种平台的普及，视图层需要设计成能够跨平台展示的界面，这要求开发者采用响应式设计、多终端适配技术等，确保用户无论在哪种设备上都能获得一致的体验。
• 用户体验设计：视图层的设计不仅仅是外观的美化，更重要的是提升用户体验（UX）。这包括简化用户操作流程、提高界面的直观性、实现快速响应等，都是为了使用户能更高效、愉悦地完成任务。

逻辑层的拓展

• 微服务架构：随着系统规模的增长，单一逻辑层可能变得庞大且难以管理。微服务架构通过将逻辑层拆分成多个小型、独立的服务来解决这个问题，每个服务负责一个特定的业务功能，可以独立部署和扩展。
• API设计：逻辑层通常还涉及API（应用程序编程接口）的设计，特别是对于需要与其他系统集成或提供开放服务的应用。良好的API设计应遵循RESTful原则，确保接口的易用性、稳定性和安全性。

物理层的拓展

• 数据库选型与优化：物理层的选择直接影响到数据处理的效率和系统的性能。根据应用场景的不同，可能会选择关系型数据库（如MySQL）、非关系型数据库（NoSQL，如MongoDB）或是分布式数据库等。此外，合理的数据库索引设计、分区策略、缓存机制等都是优化物理层的重要手段。
• 云原生与容器化：随着云计算的普及，物理层的部署越来越多地采用云服务和容器技术（如Docker、Kubernetes）。这不仅提高了资源的利用效率，也使得系统更容易水平扩展，应对高并发访问。

分层架构的优势

• 模块化：每一层专注于自己的职责，便于团队分工合作，同时降低了不同部分间的耦合度。
• 可测试性：各层可以独立进行单元测试，便于发现和修复问题，提高软件质量。
• 易于维护和升级：当某一层的需求变化时，只需修改相应层的代码，不影响其他层，降低了维护成本。
• 技术栈灵活性：分层架构允许在不同层使用最适合的技术，比如前端可以采用React或Vue等现代框架，后端可以是Java、Python等语言，数据库则根据需求灵活选择。

通过这种分层架构，数据库应用系统能够更好地适应不断变化的业务需求和技术环境，为用户提供更加稳定、高效的服务。

自反律

自反律（Reflexivity）是关系数据库理论中的一个概念，属于Armstrong公理系统的一部分，用于描述函数依赖（functional dependency）的一个基本性质。具体来说，自反律表达的是这样一个规则：

自反律（Reflexivity Rule）: 如果Y是X的子集，那么X→Y。

这意味着，对于任何属性集X和它的一个子集Y（包括X本身），X函数决定Y总是成立的，这是一个平凡的函数依赖。换句话说，在任何情况下，一个属性集中的属性自然决定它自己及其任何子集。这个规则在逻辑上是显然的，因为一个集合包含的所有信息自然也包含了它的任何部分信息。

在数据库设计和规范化理论中，自反律常常被用来作为推理其他函数依赖有效性的基础之一。例如，在验证一个给定的函数依赖集是否蕴含另一个函数依赖时，自反律可以用来直接添加那些明显成立的依赖，而不需要额外的证明。

简而言之，自反律体现了这样一个直觉：一个集合中的属性总是能够确定它自身的任何一个子集，这是逻辑上最基本且无需证明的事实。在关系数据库的理论研究和实际设计过程中，这一原理帮助我们构建和验证数据模型的正确性。

首先，我们来分析给定的关系模式R(U,F)，其中U={A,B,C,D}是属性集合，F={AB-C, CD→B}是函数依赖集。

1. 函数依赖AB-C表示当A和B的值确定时，可以唯一确定C的值。
2. 函数依赖CD→B表示当C和D的值确定时，可以唯一确定B的值。

为了确定候选键，我们需要找到能够唯一标识每个记录的属性集合。根据上述依赖：

• 由于AB-C，我们知道(A, B)联合可以决定C，但不能直接决定D，因此(A, B)不是候选键。
• CD→B表明(C, D)可以决定B，但没有直接信息显示它如何直接或间接决定A，所以(C, D)也不是候选键。
• 然而，结合两个依赖，我们可以看到(A, C)联合起来能够通过AB-C决定B（因为已知A可以确定AB-C中的B），同时(A, C)也能通过CD→B决定D（因为已知C可以确定D）。因此，(A, C)是一个候选键。
• 同样地，考虑(B, D)，通过CD→B，B和D可以决定B（这虽然是重复的，但说明了BD组合的信息完整性），但我们没有直接的方式从BD推导出A或C，因此(B, D)单独不是候选键，但它与我们的分析确认过程有关联。

基于以上分析，正确的选项应能反映至少一个候选键的存在。根据我们的推理，(A, C)是一个明显的候选键，因为它可以唯一决定R中的所有其他属性。没有直接证据表明存在第二个独立的候选键，因此选项应该指出有一个候选键，并描述其主属性和非主属性的数量。

选项A指出“只有一个候选关键字ACB”，这里虽然提到了一个候选键且包含A和C，但错误地将B包括在内，而实际上B不是决定其他属性所必需的。正确的表述应只包括A和C作为候选键的一部分，且由于题目中未明确指出哪些是主属性哪些是非主属性，基于(A, C)为候选键的理解，如果我们假设A和C为决定其他属性的主属性，则U中剩下的是非主属性，即主属性2个，非主属性也是2个。

数据库基本操作

第6题
(第1空)如果将Students表的插入权限赋予用户User1,并允许其将该权限授予他人，那么正确的SQL语句如下：GRANT
(TABLE Students TO User1().
A.INSERT
B.INSERT ON
C.UPDATE
D.UPDATE ON
第9章数据库技术基础
正确答案：B

数据库的基本操作广泛涉及数据库的创建、配置、数据的增删改查以及数据库本身的维护管理。以下是一些核心操作的概述：

1. 创建数据库:

   • 通过DDL（数据定义语言）命令，如CREATE DATABASE语句，可以创建一个新的数据库，并可以指定数据库的名称、存储文件的逻辑与物理名称、初始大小、最大大小、文件增长方式等。

2. 查看数据库:

   • 使用命令如SHOW DATABASES;来列出所有数据库。
   • 使用SHOW CREATE DATABASE <database_name>;查看特定数据库的创建语句及配置。

3. 修改数据库:

   • 利用ALTER DATABASE命令调整数据库的属性，比如字符集、排序规则等。

4. 删除数据库:

   • 使用DROP DATABASE命令删除不再需要的数据库。请注意，此操作不可逆，数据将永久丢失。

5. 使用数据库:

   • USE <database_name>;命令用于切换到指定的数据库，以便在其上执行后续操作。

6. 数据表操作:

   • 创建表: CREATE TABLE语句用于定义新的数据表结构，包括列名、数据类型、主键、外键等。
   • 查看表: SHOW TABLES;显示当前数据库中的所有表；DESCRIBE <table_name>;或DESC <table_name>;查看表结构。
   • 修改表: ALTER TABLE用于修改表结构，比如添加列、删除列、修改列定义等。
   • 删除表: DROP TABLE命令用于删除数据表。

7. 数据操作（增删改查）:

   • 插入数据: INSERT INTO语句用于向表中插入新记录。
   • 更新数据: UPDATE语句用于修改现有记录。
   • 删除数据: DELETE FROM语句用于删除表中的记录。
   • 查询数据: SELECT是最常用的语句，用于检索数据，可结合WHERE、ORDER BY、GROUP BY等子句进行复杂查询。

8. 事务处理:

   • 在执行数据的插入、删除、修改操作时，通常需要考虑事务管理，确保数据的一致性。事务可以通过BEGIN TRANSACTION、COMMIT和ROLLBACK等命令来控制，成功则提交事务，失败则回滚事务，避免数据处于不一致状态。

9. 索引管理:

   • 创建、修改或删除索引以优化查询性能。

10. 权限管理:

    • 设置用户访问权限，如GRANT和REVOKE命令来控制谁能访问数据库或执行特定操作。

正确答案是C。

查找运算概念

解析如下：

A选项：“哈希表可以动态创建”是正确的。哈希表是一种数据结构，可以在运行时根据需要动态地创建和调整大小。

B选项：“二叉排序树属于动态查找表”也是正确的。动态查找表是在运行时可以进行插入、删除和查找操作的数据结构，二叉排序树（又称二叉查找树、二叉搜索树）完美符合这一定义，因为它们允许这些动态操作并保持特定的排序性质。

C选项：“二分查找要求查找表采用顺序存储结构或循环链表结构”是错误的。二分查找要求数据是有序的，并且通常应用于顺序存储结构（如数组）中，因为它依赖于快速访问中间元素的特性。二分查找不适用于链表结构，包括循环链表，因为链表访问中间元素的时间复杂度不是常数级的，无法直接定位到中间位置。

D选项：“顺序查找方法既适用于顺序存储结构，也适用于链表结构”是正确的。顺序查找（线性查找）是最简单的查找方法，它通过遍历序列，逐个比较每个元素直到找到目标值或遍历完序列。这种查找方式不限于特定的数据结构，既可以在数组（顺序存储结构）中使用，也可以在链表（包括单向链表和双向链表）中实施。

因此，根据上述分析，错误的叙述是C选项。

数据库关系模式设计

科室与职工的所属联系类型为一对多（1:N），因为每个科室有若干名职工，但一名职工只属于一个科室。

病患与医生的就诊联系类型为多对多（M:N），因为一个医生可以为多个病患看病，同时一个病患也可以由多个医生多次诊治。

对于就诊联系最合理的设计是引入一个新的关系模式，称为“就诊记录”（或类似命名），该关系模式包含病患的病历号、职工的职工号以及就诊时间等信息，因为就诊行为是发生在特定时间的，所以就诊时间是这个关系中的一个关键属性。

就诊关系的主键应该是能够唯一标识每一次就诊记录的属性组合。考虑到一个病患可以由同一个医生在不同时间就诊多次，因此病历号和职工号不足以唯一确定一次就诊记录，必须加入就诊时间。所以，就诊关系的主键是病历号、职工号和就诊时间，选项B正确。

数据库关系模式设计是数据库设计中的一个重要阶段，它主要关注如何将现实世界中的实体及其关系转化为数据库中的一系列表（关系）及其关联。这一过程遵循数据库设计的基本原则，如范式化（1NF, 2NF, 3NF, BCNF等）以减少数据冗余和异常，确保数据的一致性和完整性。以下是进行关系模式设计时的一些基本步骤和考虑因素：

1. 需求分析：首先，明确系统的目标、功能需求以及涉及的所有实体和它们之间的关系。这一步通常通过与领域专家的交流和分析业务流程来完成。

2. 实体识别：从需求分析中识别出所有的实体，即需要存储和管理的信息对象。例如，在上述题目中，实体包括“科室”、“病患”和“职工”。

3. 属性定义：为每个实体定义其属性，即描述实体特征的数据项。例如，“科室”的属性可能有“科室号”、“科室名”、“负责人”和“电话”。

4. 确定关系类型：分析实体之间的关系，如一对一、一对多或多对多，并据此设计关联表或在表中添加外键以表示这些关系。例如，“科室”与“职工”之间是一对多关系，“病患”与“医生”之间是多对多关系，需要通过就诊记录表来体现这种复杂关系。

5. 选择合适的数据模型：根据应用需求选择合适的数据模型，如关系模型、对象关系模型或NoSQL模型等。大多数传统数据库系统使用关系模型。

6. 范式化设计：将初始设计转化为满足一定范式的关系模式，以优化数据结构，减少数据冗余，提高数据一致性。一般至少达到3NF（第三范式），以消除传递依赖。

7. 优化与调整：审查并优化设计，考虑查询性能、数据完整性约束、安全性等因素，可能需要调整表结构、索引设计或数据分布策略等。

8. 物理设计：最后，根据选定的DBMS特性和硬件环境，进行物理设计，包括数据存储结构、访问路径选择、数据分布等，以实现高效的数据存储和访问。

在实际操作中，关系模式设计是一个迭代的过程，可能需要根据实际情况反复调整，直至达到既满足业务需求又具有良好性能的设计方案。

E-R关系模式关键字

正确答案应该是B，三个实体的关键字。在E-R模型向关系模型转换时，处理多对多关系通常会创建一个新的关系表来表示这个关联，而这个新表的主键（即关键字）由参与多对多关系的所有实体的关键字组合构成。这样可以确保每个组合唯一标识一个特定的关系实例，同时维护数据的完整性。因此，选项B是正确的描述。

解析：要判断哪个选项的分解保持了原关系模式R的所有函数依赖，我们需要检查每个选项中的子模式是否能够重新推导出F中的所有函数依赖。

原函数依赖集F={A→B, A→C, C→D, AE→G}。

A. R1(A,B,C) 和 R2(D,E,G)
这个分解不保持函数依赖，因为AE→G的依赖中A和E被分在了不同表中，无法在单个表中保持。

B. R1(A,B,C,D) 和 R2(A,E,G)
这个分解保持了所有函数依赖。具体分析：

• A→B 和 A→C 可以直接在R1中保持。
• C→D 也可以在R1中保持，因为C和D在同一表中。
• AE→G 可以在R2中保持，因为A和E同时存在于R2中。
  所以，这个分解满足条件。

C. R1(B,C,D) 和 R2(A,E,G)
这个分解不保持函数依赖，因为A→B和A→C的依赖在没有A的表R1中无法保持。

D. R1(B,C,D,E) 和 R2(A,E,G)
这个分解也不保持函数依赖，虽然AE→G可以在R2中保持，但是A→B和A→C的依赖因为A不在R1中而无法保持。

因此，正确答案是B。

关系模式候选关键字

在关系模式R(U,F)中，要找到候选关键字，我们需要识别决定其他所有属性的最小属性集合。根据给定的函数依赖集F={A→B,A→C,C→D,AE→H}，我们可以分析如下：

• A决定B和C，即A→{B,C}
• 由于C还能决定D，即C→D，结合A→C，可以推出A→{B,C,D}
• AE一起决定H，即AE→H

从上述依赖中，可以看到A单独就能决定B、C、D，但不能决定H，因此A不是完整的候选键。而AE一起能决定H，同时因为A已经能决定B和C，加上E又能决定H，这意味着AE一起能够决定整个集合{A,B,C,D,E,H}中的所有属性（注意，虽然A能决定B和C，但我们关注的是最小集合，且没有依赖表明B或C能决定其他属性使其成为候选键的一部分）。

因此，候选关键字是AE。

选项C（AE）是正确答案。

继续深入讨论候选关键字的相关概念及其在数据库设计中的应用，我们可以探讨以下几个方面：

候选关键字的选择

在存在多个候选关键字的情况下，选择哪一个作为主键，需要考虑以下几个因素：

• 易用性与含义：选择具有实际意义、易于理解且使用的属性作为主键更为合适。例如，在员工信息表中，使用员工ID而非社会保险号作为主键，因为员工ID更直接且不涉及隐私问题。
• 稳定性：主键应选择不易随时间改变的属性。比如，比起电话号码或住址，个人身份证号作为主键更加稳定。
• 空间效率：如果候选关键字中有较短的属性组合也能唯一标识记录，选择这样的组合可以节省存储空间。

部分函数依赖与传递函数依赖

理解候选关键字时，还需要考虑部分函数依赖和传递函数依赖，因为它们影响到关系模式的规范化程度：

• 部分函数依赖：若X→Y，且X中存在一个真子集X’，使得X’→Y，那么Y对X存在部分函数依赖。消除部分函数依赖有助于发现或精简候选关键字。
• 传递函数依赖：若X→Y，Y↛X，且Y→Z，则称Z对X存在传递函数依赖。第三范式（3NF）要求消除非主属性对候选关键字的传递函数依赖，以减少数据冗余和更新异常。

复合键

当单个属性不能唯一标识记录时，需要使用多个属性的组合，这称为复合键（Composite Key）。复合键也是候选关键字的一种，它由两个或更多的属性构成，共同满足唯一性和最小性条件。

数据库规范化

候选关键字在数据库规范化过程中扮演着核心角色。第一范式（1NF）要求表中的每个列都是不可分割的基本数据项，而第二范式（2NF）要求表中的每个非主属性完全依赖于任何候选关键字，而非部分依赖。进一步地，第三范式（3NF）要求除了候选关键字之外的属性之间不存在传递依赖。这些规范化过程帮助我们设计出结构良好、减少数据冗余的数据库。

总结

候选关键字是数据库设计的基础之一，它不仅关乎数据的唯一标识，还直接影响到数据库的性能、一致性和扩展性。合理选择和管理候选关键字，遵循数据库规范化原则，对于构建高效、可靠的数据管理系统至关重要。

如果关系R(H,L,M,P)的主键为全码（All-key），这意味着唯一能唯一标识表中每一行的属性集合是所有属性的组合，即(HLMP)。因此，关系R的主键应该是全部四个属性的组合，选项A正确。全码情况下，不可能从单个属性或者任意较少数量的属性组合中保证唯一性，故B、C、D选项均不符合全码的定义。

基于上述解释，理解关系模式中的全码（All-key）概念，我们可以进一步探讨它在数据库设计实践中的几个重要方面：

全码与数据完整性

使用全码作为主键的一个主要优势在于它能确保数据的绝对唯一性，避免了因选择较小主键而导致的潜在重复问题。这对于那些单个或部分属性组合难以唯一标识实体的情况特别适用，比如某些特殊的数据集合或高度复杂的业务场景。

全码与性能考量

尽管全码提供了最强的数据唯一性保证，但同时也可能带来一些性能上的挑战：

• 存储开销：全码主键通常意味着更大的索引大小，因为索引需要包含所有组成主键的字段，这可能导致更多的存储空间需求。
• 查询性能：在进行查询操作时，特别是涉及到主键的联接或索引查找，较大的主键可能会减慢查询速度。
• 插入和更新成本：每次插入新记录或更新含有全码字段的记录时，都需要计算和验证整个主键的唯一性，这可能增加处理时间。

全码与规范化

在数据库规范化过程中，全码的使用并不常见，尤其是在较低级别的规范化形式中（如1NF、2NF）。全码更多地出现在高度去冗余化的高级规范化级别（如BCNF、4NF、5NF），特别是在解决多值依赖和连接依赖的问题时。

实践中的权衡

在实际数据库设计中，设计师通常会权衡全码的利弊，考虑是否真的需要全码来维护数据完整性，还是可以通过业务规则、辅助唯一性约束或其他设计策略来达到相同目的，同时优化性能。

总结

全码作为主键在特定情境下提供了一种确保数据完整性的有效手段，但其使用需谨慎评估，综合考虑数据模型的复杂性、性能需求以及存储成本等因素。在许多情况下，通过精心选择较小的候选键组合或引入人工生成的主键（如自增ID），可以在保持数据完整性的同时，提升系统的整体效率和可维护性。

关系模式

解析：要判断给定的分解是否无损联接且是否保持函数依赖，我们可以通过检查两个关键点：

1. 无损联接性：检查原关系R中的每一个可能的元组，在经过分解后，能否通过自然连接重新组合回原来的元组，而不会有信息丢失。这通常通过检查左边的属性集是否能唯一确定右边的属性集来判断，或者使用一种更正式的方法——计算候选键和分解后的模式的闭包来判断。

2. 保持函数依赖性：检查所有在F中的函数依赖在分解后的模式上是否仍然成立。

对于题目中的分解{（A1,A2), (A1,A3)}：

• 无损联接性：考虑到A1A3->A2的存在，分解后(A1,A2)和(A1,A3)两个表可以通过A1联接，但是因为A2->A3的函数依赖，我们知道在原表中A2可以决定A3。然而，分解后A2不再与A3在同一张表中，这意味着如果我们只知道A1和A3（从(A1,A3)表），没有A2的信息，我们无法直接得到A2的值来确定A3，这可能导致信息的不一致或丢失，特别是在存在A2的不同值对应不同A3值的情况下。因此，这个分解是有损联接的。

• 保持函数依赖性：考虑函数依赖A1A3->A2，在分解后显然不保持，因为(A1,A3)表中并不包含A2，无法直接体现此依赖。同时，A2->A3的依赖在分解后也不能直接保持，因为A2和A3被分到了不同的表中，无法直接通过表结构体现这一依赖关系。因此，分解也不保持函数依赖。

所以，根据以上分析，正确答案是D. 有损联接且不保持函数依赖。你的选择C是不正确的。

关系模式

第42题
在数据库逻辑设计阶段，若实体中存在多值属性，那么将E-R图转换为关系模式时，()，得到的关系模式属于4NF。
个。将所有多值属性组成一个关系模式
B.使多值属性不在关系模式中出现
C将实体的码分别和每个多值属性独立构成一个关系模式
D.将多值属性和其它属性一起构成该实体对应的关系模式
第9章数据库技术基础
正确答案：C你的答案：D

正确答案是C，将实体的码分别和每个多值属性独立构成一个关系模式。这样的做法可以确保每个关系模式描述的是实体的一个方面，且每个非主属性都完全依赖于码，没有非平凡且非函数依赖的多值依赖，因此满足第四范式（4NF）的要求。

当我们谈论数据库的独立性时，主要关注的是两个层面：物理独立性和逻辑独立性。这是数据库设计中的重要概念，旨在确保数据库的结构变化不会对用户的应用程序造成不必要的影响，从而提高了系统的灵活性和可维护性。

物理独立性

定义： 物理独立性是指数据库的物理存储结构（如数据的实际存放位置、存储方式、存储设备等）的变化不会影响到数据库的逻辑结构，也不会影响到用户的逻辑视图和应用程序。

实现方式： 这一特性是通过**模式（Schema）与内模式（Internal Schema）之间的映像（Mapping）**来实现的。模式描述了数据库的逻辑结构，包括表、列、数据类型等；而内模式描述了数据在物理存储介质上的组织方式和存储结构。当数据库的物理存储需要调整时（比如从磁盘迁移到SSD，或者索引策略的改变），只要修改这个映像，保持模式定义不变，用户的逻辑视图和应用程序就可以不受影响。

逻辑独立性

定义： 逻辑独立性是指数据库的逻辑结构（如表结构、字段定义）发生变化时，例如增加新的表、修改表结构等，不会影响到基于数据库的应用程序，即不需要修改应用程序也能适应数据库的这些变化。

实现方式： 这一特性是通过外模式（External Schema）与模式（Schema）之间的映像来实现的。外模式是用户看到的数据视图，它可能只是数据库逻辑结构的一个子集或经过变换的视图。当数据库的逻辑结构发生变化时，通过调整外模式到模式的映像，使得外模式保持相对稳定，从而保护了应用程序不受影响，用户仍然可以通过原来的接口访问数据。

总结

• 物理独立性关注的是底层物理存储的变动不影响高层逻辑结构，通过修改模式-内模式映像实现。
• 逻辑独立性关注的是逻辑结构的变动不影响应用程序，通过修改外模式-模式映像实现。

因此，正确答案D（模式与内模式之间的映像、外模式与模式之间的映像）准确地反映了物理独立性和逻辑独立性的实现机制。

三级结构/两级映像

第49题
采用三级结构/两级映像的数据库体系结构，如果对数据库的一张表创建聚簇索引，改变的是数据库的()。
A.用户模式
B.外模式
C模式
D.内模式
第9章数据库技术基础
正确答案：D你的答案：A

正确答案确实是D，内模式。

解析：在数据库的三级结构（外模式、模式、内模式）中，内模式描述了数据的物理存储结构和存储方式。聚簇索引直接影响数据的物理存储顺序，因此创建聚簇索引会改变数据库的内模式。而外模式是用户视图，模式是全局逻辑结构，用户模式通常指用户所见的数据库结构，这些都不会因为创建聚簇索引而直接改变。

第50题
在基于Web的电子商务应用中，访问存储于数据库中的业务对象的常用方式之一是()。
一个。京东银行
B.XML格式
c.cG芯片
D.COM

在基于Web的电子商务应用中，访问存储于数据库中的业务对象的常用方式之一是通过网页表单提交数据，然后服务器端使用诸如Java EE、ASP.NET等技术来处理这些数据，进而与数据库进行交互。但就选项来看，没有直接对应完美的答案。不过，从技术相关性角度推测，这里的意图可能是询问某种技术或标准用于数据交换或对象访问。

A. 京东银行 - 这是一个具体的公司名称，与问题无关。
B. XML格式 - 在Web服务和数据交换中，XML（可扩展标记语言）是一种常用的格式，可以用来结构化数据并实现不同系统间的数据交换。因此，从这个角度来看，B选项较为接近正确答案，因为它可以用来表示和传递业务对象的数据。
C. cG芯片 - 这似乎是一个打字错误或者不相关的技术名词，与Web电子商务数据访问方式无关。
D. COM - Component Object Model（组件对象模型），是微软的一种软件组件对象技术，主要用于Windows系统中程序间的交互。虽然COM可以用于对象访问，但它不是Web环境中访问数据库中业务对象的典型方式，特别是在跨平台的Web应用中。

正确答案是 B. XML格式。

在基于Web的电子商务应用中，访问存储于数据库中的业务对象的一个常用方式是通过XML（Extensible Markup Language，可扩展标记语言）格式。XML 提供了一种平台无关性和语言无关性的数据交换格式，使得不同系统之间能够方便地共享数据。因此，在Web服务和数据库交互中，XML常被用于封装和传递数据，便于客户端或者不同系统之间的数据解析和处理。

Armstrong公理系统是一套用于推理函数依赖的规则。根据这些规则，我们可以判断哪个选项正确描述了伪传递律。

A. 这是合并规则（也称合成规则），表示如果X→Y和X→Z，那么可以推出X→YZ。

B. 这是正确的选项，描述的是伪传递律。伪传递律指出，如果X→Y，并且WY→Z，那么可以推出XW→Z。这里，“伪”是因为中间项WY并不是原函数依赖直接蕴含的，而是通过X→Y和WY→Z结合推导出来的。

C. 这是传递规则，表示如果X→Y且Y→Z，则可以推出X→Z。

D. 这是增广规则，表示如果X→Y，那么对于任何Z⊆U，都有XZ→YZ。

因此，正确答案是B。

第53题
某集团公司下属有多个超市，每个超市的所有销售数据最终要存入公司的数据仓库中。假设该公司高管需要从时间、地
区和商品种类三个维度来分析某家电商品的销售数据，那么最适合采用()来完成。
A.DATA EXTRACTION
B.OLAP
C.OLTP
D.ETL
第9章数据库技术基础
正确答案：B你的答案：C

正确的答案是 C.WITH GRANT OPTION。

这个选项允许用户Ming不仅拥有对Dept表中name列的更新权限，而且还能够将这个权限进一步授予其他用户。这就是题干中“并允许Ming将该权限授予他人”的意思。

WITH CHECK OPTION是用于视图的创建或者授权，用来限制对视图的更新操作，确保更新后的数据仍然满足视图定义中的条件，与本题的权限授予情境不符。

因此，根据题目要求，正确答案是C。

三级模式结构

第68题
采用三级模式结构的数据库系统中，如果对一个表创建聚簇索引，那么改变的是数据库的()。
A.外模式
B.模式
C.内模式
D.用户模式
第9章数据库技术基础

正确答案：C.内模式

在数据库的三级模式结构中：

• 外模式（External Schema）：也称为子模式或用户模式，是数据库用户（包括应用程序员和最终用户）能够看见和使用的局部数据的逻辑结构和特征的描述，是与某一应用有关的数据的逻辑表示。
• 模式（Schema）：是数据库中全体数据的逻辑结构和特性的描述，是所有用户的公共数据视图。模式描述的是数据的全局逻辑结构。
• 内模式（Internal Schema）：也称为存储模式，是数据在数据库内部的表示方式，即对数据的物理结构和存储方式的描述。

创建聚簇索引会改变数据的物理存储方式，使得表中的数据按照索引列的值进行物理排序和存储，从而影响数据的存储方式和访问效率，这属于对数据库内层存储结构的改动，因此改变的是内模式。