数据库集成：自底向上设计与模式匹配

### 数据库集成：自底向上设计与模式匹配 在当今的信息系统中，数据库集成是一个至关重要的问题。随着新的分布式应用不断涌现，对数据源的访问提出了新的要求，同时“遗留系统”的数据管理和重用也变得愈发重要。本文将详细探讨数据库集成的相关内容，特别是自底向上的设计方法和模式匹配技术。 #### 数据库集成概述 数据库集成可分为物理集成和逻辑集成两种方式。物理集成会将源数据库进行整合，并将集成后的数据库物化，这种方式形成的数据仓库常用于决策支持应用，也就是在线分析处理（OLAP）。与之相对，OLTP 应用如航空公司预订或银行系统，是高吞吐量的面向事务的系统，需要广泛的数据控制和可用性、高多用户吞吐量以及可预测的快速响应时间。而 OLAP 应用如趋势分析或预测，需要分析来自多个运营数据库的历史、汇总数据，使用复杂查询处理可能非常大的表。由于 OLAP 应用的战略性质，响应时间很重要，且大多数 OLAP 应用不需要最新版本的数据，因此数据仓库会从多个运营数据库收集数据并进行物化，当运营数据库发生更新时，这些更新会传播到数据仓库。 逻辑数据集成则是虚拟的，没有物化的全局数据库。数据仍然存储在运营数据库中，全局概念模式（GCS）为查询这些数据库提供虚拟集成。用户查询在全局模式上提出，然后分解并发送到本地运营数据库进行处理。不过，由于底层运营数据库管理系统的自主性，支持全局更新非常困难，因此这类系统主要是只读的。 #### 自底向上设计方法 自底向上设计的目标是将参与数据库的信息（物理或逻辑）集成到一个统一的多数据库中。有两种可选方法：一种是先定义全局概念模式，然后将本地概念模式（LCS）映射到该模式；另一种是将 GCS 定义为 LCS 部分的集成，此时需要同时生成 GCS 并将各个 LCS 映射到该 GCS。 如果 GCS 预先定义，它与 LCS 之间的关系有两种基本类型：本地视图（LAV）和全局视图（GAV）。在 LAV 系统中，GCS 定义存在，每个 LCS 被视为其上的视图定义；在 GAV 系统中，GCS 被定义为 LCS 上的一组视图。此外，还有一种结合了这两种方法的全局 - 本地视图（GLAV）。 自底向上设计一般分为两个步骤：模式翻译和模式生成。 - **模式翻译**：将组件数据库模式转换为通用的中间规范表示（InS1, InS2, ..., InSn）。选择合适的规范模型很重要，它应能充分表达所有待集成数据库中的概念。常见的规范模型包括实体 - 关系模型、面向对象模型、图（可简化为树）等。在本文中，我们使用关系模型作为规范数据模型。 - **模式生成**：使用中间模式生成 GCS。在某些方法中，考虑使用本地外部（或导出）模式进行集成，以反映本地系统可能只愿意贡献部分数据的情况。模式生成过程包括以下步骤： 1. **模式匹配**：确定翻译后的 LCS 元素之间或单个 LCS 元素与预定义 GCS 元素之间的语法和语义对应关系。 2. **模式集成**：如果尚未定义 GCS，则将公共模式元素集成到全局概念（中介）模式中。 3. **模式映射**：确定如何将每个 LCS 的元素映射到 GCS 的其他元素。模式映射步骤可能分为映射约束生成和转换生成两个阶段。 下面通过一个示例来说明上述过程。假设有两个组织，分别有自己的数据库定义。一个是关系型工程数据库，另一个是根据实体 - 关系（E - R）数据模型定义的数据库。通过将 E - R 模型映射到关系模型，可以更好地展示数据库集成的过程。 #### 模式匹配 模式匹配的任务是确定一个模式中的哪些概念与另一个模式中的概念匹配。如果 GCS 已经定义，通常是将每个 LCS 与 GCS 进行匹配；否则，在两个 LCS 之间进行匹