数据管理系统 - 软件架构课程第21讲
讲师：David Garlan, Carnegie Mellon University 课程：Software Architectures, Lecture 21: Data Management Systems
一、数据中心架构风格总览
在架构风格家族中，数据中心/共享数据风格有两大代表：
- 数据库（Database） — 本讲重点
- 黑板（Blackboard） — 另讲
共享信息系统（Shared Information Systems）
核心结构：数据仓库（Data Repository）居中，数据生产者、消费者、修改者围绕其交互。
优点：
- 易于添加新的数据生产者和消费者（松耦合）
问题/挑战：
- 同步（Synchronization）
- 配置与模式管理（Configuration and schema management）
- 原子性（Atomicity）
- 一致性（Consistency）
- 持久性（Persistence）
- 性能（Performance）
二、早期文件访问时代
2.1 批处理顺序系统
- 最早期：平面文件访问（Flat file I/O）
- 介质：磁带 → 磁鼓 → 磁盘驱动器
- 代码需要手动定位介质、读取数据、执行”清理”操作
- 架构上意义不大，但对底层程序员来说是硬核挑战
2.2 文件系统的演进
OS 的进步聚焦于设备抽象，外部数据需求推动文件系统发展：
| 阶段 | 特点 |
|---|---|
| 平面文件系统 | 单层目录，只含文件 |
| 层次文件系统 | 目录可包含文件和子目录 |
| 语言与 OS 支持 | 多种文件类型和访问方式 |
2.3 文件访问的三大问题域
1. 物理数据组织
- 块（block）、扇区（sector）、流文件表示
- 概念迁移：块和记录从磁带/卡片来，扇区从磁鼓→磁盘→文件
- 各 OS 实现差异大
2. 文件类型、访问、格式
- 二进制或文本，各 OS 不同
- 如 VAX/VMS 有约 12 种文件类型（定长/变长/未定义/成块/未成块…）
- 随机或顺序访问
- 成块与缓冲 I/O
3. 文件内数据组织
- 策略由多种因素决定：数据类型、到达速率、检索速度、数据量、OS 特性、排序需求
- 文件设计曾是热门话题，出现了设计规则、指导方法、通用词汇
- 形式化方法辅助开发（如最优分块因子公式）
2.4 数据管理的实现细节时期
- 数据管理被视为实现细节，由数据结构领域解决
- 多任务和并发处理增加了文件访问复杂性
- 信号量、队列、临界区等机制开始出现在 OS 和语言中
- 核心问题：有效数据管理受限于底层 OS 和语言机制，应用严重依赖硬件和 OS
当时常见的数据管理问题：
- 创建数据文件
- 搜索和查找数据项
- 读写修改数据项
- 排序数据项
- 修改数据文件结构
- 协调并发访问
这些重复性问题推动了数据管理抽象的出现：工具包、API 库、应用系统。
三、数据库技术
3.1 数据库技术的利弊
优点：
- 更好的空间管理
- 数据与应用更好地解耦
- 减少冗余
- 可构建更复杂的应用
缺点（规模增长后）：
- 成本增加
- 受制于数据库供应商
- 安装、操作、恢复通常更复杂
3.2 三种主要技术路线
| 路线 | 代表 | 特点 |
|---|---|---|
| 数据管理语言 | COBOL, DBaseX | 语言原生调用，封装索引等底层机制 |
| API 数据管理抽象 | HDF (Hierarchical Data Format) | 传统编程语言 + 数据管理库，适合特定领域 |
| 数据库管理系统 (DBMS) | DB2, Oracle, Sybase, Informix, Access | 独立应用系统，含数据管理/文件访问/同步/UI |
| 组合方式 | Java (JDBC) | 原生语言 + 数据库扩展，兼顾灵活性与数据管理能力 |
四、数据库技术演进详解
4.1 数据管理语言
- 语言原生调用即可创建外部文件并操作（增删改查排序）
- 内置同步管理机制
- 高级特性支持交互式应用（文本显示、格式化输出）
- 开发者仍需关注某些问题（如同步）
- 索引等”难题”已被封装
- 底层系统访问受限
- 适合：数据管理应用
- 不适合：性能敏感、嵌入式等领域
架构视角：开发者看到的是简单的”程序 ↔ 数据文件”模型，但底层封装了互斥锁、媒体控制、支持文件等复杂机制。
4.2 API 数据管理抽象
- 开发者使用原生语言 + 封装好的数据管理库 API
- 增删改查 + 同步机制
- 适合：需要数据管理功能的特定领域（嵌入式、高性能）
- 依赖：API 供应商（更新、缺陷、性能、可靠性…）
架构视角：在程序和 OS 文件访问之间插入了一层 Data Management API，既保留了底层语言能力，又获得了数据管理抽象。
4.3 DBMS（数据库管理系统）
- 提供独立应用供用户创建和访问数据文件
- 简单应用无需编码（模板、向导、表单）
- 复杂 DBMS 应用需要：编码经验 + DBMS 专业经验 + 数据管理设计规则 + 系统设计经验
催生的新领域：
- 数据库设计与数据建模
- SQL（结构化查询语言）
- 数据库解决方案供应商
- 数据库管理员（DBA）
- 工具构建与支持（性能调优、安全、事务管理、系统/数据恢复）
问题：
- 大型企业的数据管理应用庞大且昂贵
- 类似大型机的”成长痛”：难以迁移到新技术/新 OS/新版本
- 历史上在 GUI、分布式处理、Web 等新技术上都经历过阵痛
- 依赖应用供应商
- 适合：数据管理应用
- 不适合：性能敏感、嵌入式、内存受限应用
架构视角：DBMS 将文件、同步、媒体控制等全部抽象掉，用户只看到”用户应用 → DBMS → 数据宇宙”。
4.4 组合模式（Java + JDBC 为例）
- Java 内置数据库管理扩展（JDBC）
- 需要配合独立的 DBMS 使用
- 解决了前三种范式各自的许多问题
- 两大驱动力：Web（分布式数据需求）+ DBMS 开发与维护的巨大成本
五、数据组织方式
| 方式 | 结构 | 说明 |
|---|---|---|
| 网状数据组织 | 图结构 | 记录类型之间的关联以图表示 |
| 层次数据组织 | 树结构 | 按关联组织为树，含根记录及其后代记录 |
| 关系数据库 | 表（相关集合） | 数据组织为相关联的表集合 |
| 对象关系数据库 | 对象集合 | 面向对象数据模型，对象的行为/状态/关系按 OO 定义；支持在对象和查询中嵌入方法（如 Informix datablades）；对象组织为相关集合 |
六、数据挖掘（Data Mining）——数据管理的未来
6.1 数据库的问题
- DBMS 只提供数据访问，不做数据分析
- 有意义的分析由领域专家完成
- 用户不懂应用，数据库程序员不懂分析
- 数据量指数级增长
- 隐含的、潜在有用的信息通常隐藏在各种分布式存储库中
6.2 数据挖掘的定义
“从现有多个数据仓库中提取隐含的、先前未知的、且潜在有用的信息” — 又称 KDD（Knowledge Discovery in Databases，数据库中的知识发现）
核心：将多个数据源完全封装，提供足够简单的工具，让分析师能直接访问数据并执行分析。
6.3 DBMS vs 数据挖掘
| 维度 | DBMS（管理数据） | 数据挖掘（推断知识） |
|---|---|---|
| 操作 | 读、写、排序数据 | 访问多个分布式仓库 |
| 功能 | 构建查询 | 定位并评估潜在有用数据的适用性 |
| 示例 | ”上月各产品销售额是多少？" | "为什么产品 A 比其他产品利润高？” |
“谁能找到信息并利用它，谁就赢。” — Don McKeough，可口可乐前总裁
6.4 数据挖掘架构
从底到顶的层次：
- 仓库抽象层（Repository Abstractions）
- 选择层（Selection Layer）
- 规则层（挖掘）（Rule Layer / Mining）
- 表示层（Presentation Layer）
数据挖掘流程：可用数据源 → 访问机制 → 预处理/选择 → 鉴别机制 → 分析机制 → 挖掘 → 结果解释 → 表示机制
6.5 应用领域与技术
应用领域：
- 医学：疾病诊断、药物副作用…
- 金融：股票预测、投资者趋势…
- 营销：购买模式、销售预测…
- 工程：产品/质量分析、故障检测…
挖掘技术：
- 决策树
- 命题规则
- 数据规则
- 关联规则
- 概率规则
- 统计学
- 聚类
七、数据管理演进时间线
1960年代 1980年代 1990年代 今天
数据收集 → 数据访问 → 数据查询 → 数据挖掘
单用户 高度集中 高度分布式
单用户
关键洞见
- 数据管理是架构风格演进的典型案例：从底层文件访问 → 语言封装 → API 库 → DBMS → 数据挖掘，抽象层次不断提升
- 每一步抽象都在解决特定问题，但也引入新的代价（供应商锁定、成本、性能损失）
- 架构选择取决于应用需求：嵌入式/高性能场景可能仍需底层 API，企业级应用则适合 DBMS
- 数据与应用的解耦是核心线索：从完全耦合（文件访问）到部分解耦（API）再到完全解耦（DBMS）
- 数据挖掘是 DBMS 的自然延伸：从”管理数据”到”发现知识”，反映了数据规模增长后价值重心的转移