面向对象数据库系统：概念、设计与实现挑战

### 面向对象数据库系统：概念、设计与实现挑战 在数据库领域，面向对象关系数据库管理系统（ORDBMS）结合了关系数据库和面向对象编程的特性，提供了更强大的数据建模和处理能力。然而，这也带来了一系列新的问题和挑战。本文将深入探讨ORDBMS中的几个关键概念，包括对象标识符（OIDs）、引用完整性、扩展实体关系（ER）模型、嵌套集合的使用，以及ORDBMS实现过程中面临的存储、查询处理和优化等方面的挑战。 #### 1. OIDs与引用完整性 在SQL:1999中，关系某一列中出现的所有对象标识符（OIDs）都必须引用同一个目标关系。这种“作用域”机制使得对OID引用进行“引用完整性”检查成为可能，就像对外键引用进行检查一样。目前支持OIDs的ORDBMS产品尚未提供此类检查，但未来版本很可能会加入。这将大大提高OIDs使用的安全性。 使用结构化对象将对象及其引用组合在一起时，如果通常需要完整访问这些对象，那么结构化对象可能比引用类型更高效。在传统编程语言（如C或Pascal）中，也存在通过值和引用引用对象的概念区分，这与数据库设计中选择结构化类型还是引用类型类似，都需要考虑存储成本、聚类问题和更新影响。 #### 2. 对象标识与外键 使用OID引用对象类似于使用外键引用另一个关系中的元组，但并不完全相同。OID可以指向数据库中任意位置存储的对象，甚至可以在字段中；而外键引用则被限制指向特定引用关系中的对象。这种限制使得数据库管理系统（DBMS）能够为外键提供比任意OID指针更强大的引用完整性支持。 一般来说，如果在仍有OID指针指向某个对象时将其删除，DBMS最多只能通过维护引用计数来识别这种情况。如果OIDs可以自由复制，那么即使这种有限的支持也将变得不可能。因此，如果使用OIDs引用对象，避免悬空引用的责任主要落在用户身上。这一沉重的责任提示我们应谨慎使用OIDs，并尽可能使用外键。 #### 3. 扩展ER模型 传统的ER模型不足以满足ORDBMS设计的需求，需要使用扩展的ER模型。扩展的ER模型支持结构化属性（如集合、列表、数组作为属性值），区分实体是否具有对象ID，并允许对属性包含方法的实体进行建模。 以空间探测器数据为例，探测器实体集的定义有两个新特点。一是具有结构化类型属性`listof(row(time, lat, long))`，每个赋值都是一个包含三个字段的元组列表；二是具有一个名为`video`的抽象数据类型（ADT）对象属性，通过深色椭圆和深色线表示，该属性还有自己的方法。 另一种建模方式是将每个视频建模为一个名为`Videos`的实体集，并定义一个关系集来关联`Probes`和`Videos`实体。由于每个视频由一个探测器收集，且每个视频都由某个探测器收集，因此可以通过在每个`Videos`实体中存储对探测器对象的引用来维护这种关系。如果将`Videos`设为弱实体集，还可以添加引用完整性约束，使得当对应的`Probes`实体被删除时，`Videos`实体也会被删除。 此外，支持嵌套集合的设计需要对ER模型进行重大扩展。例如，如果将位置序列建模为实体，并希望定义一个包含此类实体集合的`Probes`属性，就需要扩展ER模型。 #### 4. 使用嵌套集合 嵌套集合提供了强大的建模能力，但也带来了困难的设计决策。选择合适的模式需要根据预期的工作负载来决定。 例如，对于位置序列的建模，如果重要查询需要查看特定探测器的位置序列，那么使用`Probes1(pid: integer, locseq: location seq)`可能是一个好选择；但如果查询需要查看所有位置序列，使用`Probes2(pid: integer, time: timestamp, lat: real, long: real)`可能更高效。 再如，对于课程教学信息的建模，如果`Can Teach1(cid: integer, teachers: setof(ssn: string), sal: integer)`中的元组表示“课程`cid`可以由`teachers`字段中的任何教师以成本`sal`教授”，那么可以选择使用`Can Teach2(cid: integer, teacher ssn: string, sal: integer)`；但如果表示“课程`cid`可以由团队`teachers`以总成本`sal`教授”，则需要使用单独的表来编码团队，如`Can Teach2(cid: integer, team id: oid, sal: integer)`和`Teams(tid: oid, ssn: