引言：理解数据库分类的基本概念

在探讨Microsoft Access是否属于面向对象数据库之前，我们需要先明确数据库管理系统（DBMS）的基本分类。数据库技术主要分为两大阵营：关系型数据库和非关系型数据库（NoSQL）。而面向对象数据库（Object-Oriented Database, OODB）是NoSQL数据库的一个重要分支。

Microsoft Access作为微软Office套件中的桌面数据库解决方案，自1992年首次发布以来，一直是小型企业和个人开发者广泛使用的数据库工具。然而，关于Access的数据库类型存在一个常见误解：由于Access支持VBA（Visual Basic for Applications）编程和表单设计，许多人误以为它是面向对象数据库。

本文将深入解析Access的关系型本质，澄清面向对象数据库的真正含义，并通过详细示例说明为什么Access本质上是关系型数据库，而非面向对象数据库。

关系型数据库的核心特征

关系模型的基础理论

关系型数据库基于Edgar F. Codd在1970年提出的关系模型理论。其核心思想是将数据组织成二维表（Relation）的形式，每个表由行（Tuple）和列（Attribute）组成。关系型数据库的四大支柱包括：

  1. 数据结构化：数据严格遵循预定义的模式（Schema）
  2. ACID特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）
  3. SQL语言：使用结构化查询语言进行数据操作
  4. 关系完整性：通过主键、外键维护数据间的关系

Access的关系型实现

Microsoft Access完全遵循关系型数据库的核心原则：

-- Access中典型的表结构定义（通过SQL视图）
CREATE TABLE Employees (
    EmployeeID AUTOINCREMENT PRIMARY KEY,
    FirstName TEXT(50) NOT NULL,
    LastName TEXT(50) NOT NULL,
    DepartmentID INTEGER,
    HireDate DATE,
    Salary CURRENCY,
    CONSTRAINT FK_Department FOREIGN KEY (DepartmentID) 
        REFERENCES Departments(DepartmentID)
);

在Access中，所有数据都存储在严格的表结构中。即使通过图形界面创建表，Access也会在后台生成相应的SQL DDL（数据定义语言）语句。这种表结构的严格性正是关系型数据库的典型特征。

面向对象数据库的真正含义

OODB的定义与特征

面向对象数据库将数据视为对象，结合了面向对象编程（OOP）的概念。真正的OODB必须满足两个基本条件：

  1. 支持对象标识（OID）：每个对象有唯一标识，独立于其属性值
  2. 支持封装：数据和操作数据的方法被封装在一起
  3. 支持继承：类之间可以继承属性和方法
  4. 支持多态：同一消息可以引发不同对象的不同行为

典型的OODB产品包括ObjectDB、db4o、Versant等，它们允许直接存储和查询复杂的对象图，而无需将其分解为关系表。

Access中的”对象”概念辨析

Access确实提供了多种”对象”，但这些对象与OODB中的对象有本质区别：

' Access VBA代码示例：创建和操作对象
Private Sub CreateEmployee()
    Dim db As DAO.Database
    Dim rs As DAO.Recordset
    
    Set db = CurrentDb
    Set rs = db.OpenRecordset("Employees")
    
    ' 添加新记录（不是创建对象，而是插入行）
    rs.AddNew
    rs!FirstName = "张"
    rs!LastName = "三"
    rs!DepartmentID = 1
    rs.Update
    
    rs.Close
    db.Close
End Sub

这段VBA代码虽然使用了”对象”（如Database和Recordset），但这些是数据访问对象，用于操作关系表中的数据，而不是OODB意义上的持久化对象。在Access中，数据最终存储在关系表中，而不是作为对象直接存储。

深入解析Access的关系型本质

数据存储机制

Access使用Jet或ACE数据库引擎（取决于版本），其数据物理存储完全基于关系模型：

  1. 页式存储：数据以4KB页为单位存储
  2. 索引结构：使用B+树索引加速查询
  3. 事务日志：维护事务的完整性
  4. 关系约束：通过引用完整性强制执行关系
-- Access中创建关系的SQL示例
ALTER TABLE Orders
ADD CONSTRAINT FK_Customers
FOREIGN KEY (CustomerID) REFERENCES Customers(CustomerID)
ON UPDATE CASCADE
ON DELETE CASCADE;

查询引擎的工作原理

Access的查询引擎完全基于关系代数。即使使用查询设计视图，Access也会生成等价的SQL语句：

-- 示例：查询每个客户的订单总数
SELECT 
    c.CustomerName,
    COUNT(o.OrderID) AS TotalOrders
FROM 
    Customers c
    INNER JOIN Orders o ON c.CustomerID = o.CustomerID
GROUP BY 
    c.CustomerName;

这个查询使用了关系代数的选择（σ）、投影（π）、连接（⋈）和分组（γ）操作，完全符合关系型数据库的查询模式。

常见误解的来源与澄清

误解1：表单和报表是”对象”

Access提供了强大的表单（Form）和报表（Report）设计功能，这些确实可以被视为”对象”，但它们：

  • 不存储数据：仅作为数据展示和操作界面
  • 依赖于表：必须基于一个或多个表/查询
  • 无继承机制：无法从一个表单继承创建另一个表单
' 表单事件处理示例
Private Sub Form_BeforeUpdate(Cancel As Integer)
    ' 验证数据
    If Me.Salary < 0 Then
        MsgBox "工资不能为负数"
        Cancel = True
    End If
End Sub

这段代码展示了表单的事件驱动特性，但表单本身只是关系数据的视图，不是独立的对象存储。

误解2：VBA编程意味着面向对象

Access的VBA支持确实允许编写面向对象风格的代码：

' VBA类模块示例
' 在Access中创建类模块：clsEmployee
Option Explicit

Private pFirstName As String
Private pLastName As String
Private pSalary As Currency

Public Property Get FirstName() As String
    FirstName = pFirstName
End Property

Public Property Let FirstName(Value As String)
    pFirstName = Value
End Property

' 方法
Public Sub GiveRaise(Percentage As Double)
    pSalary = pSalary * (1 + Percentage / 100)
End Sub

然而，这些VBA类仅在运行时存在，不会被持久化到数据库文件中。关闭Access后，这些对象实例就会消失。真正的OODB会将对象及其状态保存到磁盘。

误解3：支持复杂数据类型

Access确实支持一些复杂类型，如：

  • 多值字段：使用”多值字段”功能
  • 附件字段：可以存储文件
  • 查阅向导：创建下拉列表

但这些特性都是在关系模型框架内的扩展，而非真正的对象嵌套：

-- Access中多值字段的实现方式（内部表）
-- 实际上，Access会创建隐藏的内部表来实现多值字段
-- 这仍然是关系模型，只是对用户透明

Access与真正OODB的对比分析

功能对比表

特性 Access (关系型) 真正的OODB
数据存储 关系表 对象图
查询语言 SQL OQL或对象方法
持久化 表中的行 对象实例
继承 不支持 支持类继承
多态 不支持 支持
封装 不支持（数据与操作分离） 支持
事务 ACID ACID或扩展

实际应用场景对比

Access适用场景：

  • 小型企业数据管理
  • 个人项目
  • 快速原型开发
  • 需要复杂报表和表单的应用

OODB适用场景：

  • 复杂对象模型（如CAD/CAM）
  • 科学计算数据
  • 多媒体内容管理
  • 需要深度嵌套对象的应用

为什么Access坚持关系型架构？

优势分析

  1. 标准化：SQL是行业标准，易于学习和迁移
  2. 工具生态：丰富的第三方工具支持
  3. 数据完整性：ACID保证数据可靠性
  4. 性能优化：成熟的查询优化器

商业考量

微软选择关系型架构是因为：

  • 目标用户是普通办公人员，SQL比OQL更易掌握
  • 与SQL Server等企业级产品保持技术一致
  • 庞大的关系型数据库市场

正确理解Access的”对象”概念

Access对象模型层次

Access的对象模型是分层的，但这种层次是容器关系而非继承关系：

Application
├── Databases
│   ├── Tables
│   ├── Queries
│   ├── Forms
│   ├── Reports
│   └── Modules
└── ...

这种结构允许程序化访问，但不提供OODB的继承和多态。

正确使用Access的方法

  1. 专注于关系设计：规范化表结构
  2. 使用SQL：编写高效的查询
  3. VBA辅助：用于业务逻辑和界面交互
  4. 理解局限性：不适合超大规模或复杂对象模型

结论：Access是关系型数据库的桌面典范

Microsoft Access是关系型数据库，而非面向对象数据库。它成功地将关系型数据库的强大功能与桌面应用的易用性结合，创造了独特的价值。虽然它提供了VBA编程、表单设计等”对象式”功能，但这些都建立在严格的关系模型基础之上。

理解这一点有助于开发者：

  • 正确设计数据库结构
  • 有效利用Access的功能
  • 在需要时选择合适的数据库技术
  • 避免概念混淆导致的错误设计

对于需要真正面向对象数据库的应用，应考虑专门的OODB产品或现代的对象-关系映射（ORM）技术，而不是试图将Access改造成它不擅长的用途。