关系模型向对象关系模型的演进

Source: Dev.to

引言

数据库的历史在很大程度上是平衡数学严谨性、计算效率和软件开发实际需求的历史。当 Edgar F. Codd 在 1970 年代初提出关系模型时，他为当时占主导地位的层次模型和网络模型提供了一种结构化且正式的替代方案。关系模型引入了一种基于集合论和谓词逻辑的简单而强大的表格数据组织方式。SQL 作为标准语言的巩固，使得关系数据库管理系统（RDBMS）成为企业系统数十年的脊梁。

然而，随着随后几十年面向对象编程的普及，尤其是 Java 和 C++ 等语言的兴起，出现了一种结构性挑战，改变了数据工程的走向：关系模型与面向对象模型之间的不兼容。这一现象被称为 Impedance Mismatch，它是面向对象数据库以及随后出现的对象‑关系系统的主要催化剂。

理解这一转变对于弄清为何像 PostgreSQL 这样的现代系统被归类为对象‑关系型，以及为何这种方法是对原始模型的演进而非断裂，至关重要。

阻抗不匹配的问题

所谓 Impedance Mismatch 描述的是两个截然不同范式之间的概念摩擦。

• 关系模型 – 将信息组织为由行和列组成的表格，数据通过基于关系代数的声明式操作进行处理。
• 面向对象范式 – 围绕类、对象、继承、封装和自身标识来构建系统。

冲突产生于对象并不自然地适配表格。在面向对象语言中，每个实例都有独立于其内部值的标识。而在关系模型中，标识由主键表示。此外，对象可以包含嵌套结构、集合、方法以及直接引用的关系，而关系数据库则使用标量类型和通过外键以及连接操作建模的关系。

这种结构差异迫使开发者创建中间层，将对象转换为记录，反之亦然。虽然这种映射过程可行，却引入了：

• 额外的复杂性
• 增加的代码量
• 潜在的性能问题

对这种负担的沮丧促成了 OODBMS（面向对象数据库管理系统）的出现，这类系统旨在原生存储对象，保留其结构特性而无需转换。

面向对象数据库试图彻底消除阻抗不匹配的问题。在这些系统中，对象以自身标识、继承和直接关系进行持久化。对于使用大量层次或图形结构的复杂应用，建模变得更加自然。然而，尽管概念上优雅，这些系统在实践中遇到了困难：

• 缺乏等同于 SQL 的通用标准
• 查询优化机制的成熟度较低
• 对特定语言的高度依赖

已经在关系基础设施上大量投入的企业市场，对放弃已成熟生态系统持抵触态度。因此，行业并未选择完全取代关系模型，而是寻求对其进行扩展。

综合：ORDBMS 的出现

答案不是拒绝关系模型，而是对其进行演进。于是 ORDBMS（对象‑关系数据库管理系统）应运而生，这类对象‑关系系统保留了 SQL 与传统关系的基础，同时在此之上加入了面向对象的特性。

它们加入了受面向对象启发的可扩展机制。

这种方法使得数据库仍然以表格和声明式查询组织，但现在支持：

• 用户自定义类型
• 复合结构
• 数组
• 半结构化数据（JSON、XML）
• 自定义函数

ORDBMS 并没有去除 SQL，而是对其进行了扩展。

PostgreSQL 成为这一理念最具表现力的例子之一。虽然它完整保留了关系模型，但提供了对复杂类型、表继承、自定义运算符以及大幅扩展其功能的扩展的支持。这种关系稳定性与结构灵活性的结合正是面向对象‑关系特性的本质。

RDBMS、OODBMS 与 ORDBMS 的比较

PostgreSQL 的架构与 “Catalogue‑Driven” 概念

PostgreSQL 最显著的特性之一是被描述为 catalogue‑driven（目录驱动）系统。该表达意味着几乎所有数据库内部组件都通过存储在系统本身的元数据表（目录）来描述。

• 数据类型、操作符、函数、索引 和 扩展 都在目录中定义并登记。

• 这种做法带来两个重要优势：

  1. 可扩展性 – 新的类型、函数或操作符只需向目录插入记录或创建相应的扩展即可自动加入。
  2. 内部一致性 – 查询优化器和执行器都会查询同样的目录以获取类型、成本和策略信息，从而保证行为可预期。

总之，“catalogue‑driven”模型使 PostgreSQL 能以模块化方式演进，同时保持传统关系数据库系统所具备的一致性与稳健性。

PostgreSQL 的内部可扩展性

这意味着数据库使用自身的关系模型来描述内部结构。它不依赖于硬编码在源代码中的刚性定义，而是通过查询自己的目录来理解如何解释类型、操作符和结构。

这一架构决策意义深远。它允许开发者在无需重新编译数据库的情况下创建新数据类型和新函数，只需在相应的目录中注册定义即可。系统随后会把这些新元素视为环境的组成部分。

这种可扩展性使得以下领域的特定域可以轻松实现：

• 地理处理
• 科学分析
• 半结构化数据处理

诸如 PostGIS 的扩展正是这种能力的典型示例：它在不修改核心代码的前提下，为空间高级操作提供完整支持。数据库本身保持不变，但其功能通过内部目录的记录得以扩展。

这种方式进一步强调 PostgreSQL 不仅因提供复合类型而称为对象‑关系型数据库，更因为其设计之初就把可扩展性作为核心原则。系统不只是一个数据仓库；它是一个可适配的平台。

结论

关系模型向面向对象‑关系模型的演进不应被解读为一次突兀的替代，而是一个技术成熟的渐进过程。关系模型提供了坚实的理论基础和标准化语言，彻底改变了数据管理。面向对象则改变了应用的构建方式，暴露了两种范式之间集成的局限性。

OODBMS 的出现是试图通过消除关系模型来解决冲突。然而，ORDBMS 的混合方式被证明更具可持续性。它们在保留 SQL 和表格结构的同时，允许扩展和复杂类型，从而实现了稳定性与灵活性的结合。

PostgreSQL 明确地展示了这种综合。其基于目录的架构以及无需重新编译的扩展能力表明，完全可以在不抛弃已确立基础的前提下实现演进。历史上的转变因此不是一次断裂，而是思想的逐步融合，反映了软件工程本身的演进以及对更具表现力、可适应性且符合现代开发实践的数据系统日益增长的需求。