有些人把面向对象的数据库设计(即数据库模式)思想与面向对象数据库管理系统(OODBMS)理论混为一谈。其实前者是数据库用户定义数据库模式的思路,后者是数据库管理程序的思路。用户使用面向对象方法学可以定义任何一种DBMS数据库,即网络型、层次型、关系型、面向对象型均可,甚至文件系统设计也照样可以遵照面向对象的思路。 面向对象的思路或称规范可以用于系统分析、系统设计、程序设计,也可以用于数据 结构设计、数据库设计。OOSE自上至下、自始至终地贯彻面向对象思路,是一个一气呵成 的统一体。面向对象的数据库设计只是 OOSE 的一个环节。

　　二、数据库设计的重要性

　　普通数据库设计方法有两种,即属性主导型和实体主导型。属性主导型从归纳数据库使用的属性出发,在归并属性集合(实体)时维持属性间的函数依赖关系。实体主导型则先 从寻觅对数据库使用有意义的实体入手,然后通过定义属性来定义实体。普通理想世界的 实体数在属性数 1/10 以下时,宜使用实体主导型设计方法。面向对象的数据库设计是从对象模型出发的,属于实体主导型设计。 普通数据库使用系统都遵照以下相关开发步骤:

1设计使用系统结构;

2 选择便于将应
　　 用程序与DBMS结合的DBMS体系结构,如RDBMS;

3 依据使用程序使用的环境平台,选择适宜的DBMS(如Oracle)和开发工具(如PB);

4 设计数据库,编写定义数据库模式的SQL程序;

5 编写确保数据正确录入数据库的用户接口使用程序;

6 录入数据库数据;

7 运转各种与 数据库相关的使用程序,以确认和修负数据库的内容。

　　对以上各步骤,有几点需求说明:

(1) 这不是瀑布模型,每一步都可以有反馈。
　　在公路局系统中,以上各步不只要反馈、有反复,还有并行处理。比如一些库表在数 据录入时,另一些库表设计还在修正。这与我们的递增式开发方法有关,也与面向对象的 特征有关。

(2) 上述顺序不是绝对的,大多数场合是从第三步开始的。

(3) 对大多数数据库使用系统来说,上述各步中最重要、最困难的不是使用系统设计而是数据库设计。

　　三、DBMS的支持和数据库设计

　　多数据库使用系统开发者不注重数据库设计的缘由是:他们太迷信DBMS,认为购入一个功用强大的DBMS后数据库设计就不困难、不重要了。一些国内外的数据库教材常常 是在为DBMS的开发厂商做宣传,而很少站在数据库用户角度,从数据库使用系统出发引见数据库设计方法。结果往往使读者搞不清书中引见的是数据库管理程序的设计思想,还是 使用这种 DBMS 进行数据库设计的思想。 其实,DBMS只是给用户为已采用的数据库提供一个舞台,而能否使用这个舞台上的道具以及唱什么戏,则完全取决于用户的戏剧脚本和导演(开发者)的安排。例如,公路局系统所使用的数据库管理系统,是以二维表为基本管理单元、支持所有关系代数操作、支持 实体完整性与实体间参照完整性的全关系型RDBMS,而我们要在这个舞台上利用上述"道具"设计一个面向对象的关系数据库。

　　四、使用对象模型与RDBMS模型的映射

　　数据库设计(模式)能否支持使用系统的对象模型,这是判断能否是面向对象数据库系统的基本出发点。由于使用系统设计在前,数据库设计随后,所以使用系统对象模型向 数据库模式的映射是面向对象数据库设计的关键。

　　1. 三层数据库模式面向对象模型的扩展

　　普通数据库设计多参照ANSL/SPARC关于数据库模式的3层标准结构提案。最接近物理数据库的内部模式由DBMS提供的SQL来描述。概念模式可以由若干个内部模式聚集而成 ,它是由数据库用户规范的一些表的集合。例如,公路局计划处数据库模式、机务处数据 库模式等,它们是逻辑数据库,常常通过库表ID来界定库边界。普通的概念模式是数据库 物理模式作用域的边界,它能实现数据库的物理意义、特定DBMS 的特殊操作对外部使用 程序的信息隐蔽。外部模式是从特定用户使用角度看待的数据库模式,从不同的使用出发对同一概念模式可以给出多种不同的外部模式。例如:公路绿化情况查询使用看到的数据 库是公路上的树木品种、数量、分布比率等, 梁隧道情况查询使用看到的是公路上的桥 梁、隧道长度、个数、路段等,但是它们可能访问的是同一个库表的不同子集。 当外部使用系统以对象模型进行笼统时,从各个使用出发笼统出的对象模型可以映射 到外部模型上,对此我们不妨称之为外部对象模型。但是,外部模型只是概念模型的子集 ,所以面向对象的数据库设计核心在于系统对象模型(不妨称之为概念对象模型) 向数据 库概念模型的映射(参见图1) 。

　　2. 对象模型向数据库表的映射规则

　　由于RDBMS是以二维表为基本管理单元的,所以对象模型最终是由二维表及表间关系来描述的。换言之,对象模型向数据库概念模型的映射就是向数据库表的变换过程。有关的变换规则简单归纳如下:

(1) 一个对象类可以映射为一个以上的库表,当类间有一对多的关系时,一个表也可 以对应多个类。

(2) 关系(一对一、一对多、多对多以及三项关系)的映射可能有多种情况,但普通映 射为一个表,也可以在对象类表间定义相应的外键。对于条件关系的映射,一个表至少应 有3个属性。

(3) 单一承继的泛化关系可以对超类、子类分别映射表,也可以不定义父类表而让子 类表拥有父类属性;反之,也可以不定义子类表而让父类表拥有全部子类属性。

(4) 对多重承继的超类和子类分别映射表,对多次多重承继的泛化关系也映射一个表 。 (5) 对映射后的库表进行冗余控制调整,使其达到合理的关系范式。

　　3. 数据库模式要面向使用系统

　　我们选择面向对象的系统设计也好,面向对象的数据库设计也好,基本目的是服务于使用系统的需求。 以公路局计划处子系统为例。计划处的最大任务量就是处理成堆的报表,因此如何有 效地存取这些报表是计划处数据库设计的关键。考虑到每月上交的报表是同构的,我们可 以创建一张库表去存储同一种报表,例如公路工程月报表。但是又产生另一个问题,当用户想查询某个月的公路工程月报表时,如何从库表中取出数据呢?按照数据库的思想应该 有一个主键来标识这张报表。在公路局的报表里,区别月报表靠上报时间和上报单位,但 如果为每条记录都加上这两个字段,无疑会加大库表冗余,添加查询时间,降低效率。更何 况每张报表都有单位担任人、填表人的属性,那么怎样处理这个问题呢?我们设计了超类 对象 X3 表和流水号表。
　　将它们加入由使用对象模型映射出的数据库概念模型后,得到图2所示的结构。
　　每一个使用模块对象对应建立一张流水号表,同一类的报表属同一流水号表,由流水号表统一管理。流水号表对各分局、处室提交和建立的每一张报表分配一个流水号,该流 水号在整个数据库中是独一的,因此在库中存放任何一张报表都是明确的。流水号的数据类型为 Char(10),前4位为表号,后6位为序列号,其中序列号取自X3表中最大序列号。也 就是说,流水号就是对象标识符,报表是一个对象,一个对象标识符独一决定一个对象。流 水号一旦被分配出去后,在这张报表的生存期内就具有了永世不变性。无论报表的内容及 结构怎样变化,它都不变,直到报表被删除,流水号才会消逝。流水号表是父类,报表是子类,流水号表之间的联系只能通过 X3 表。5个使用模块对象完全映射到数据库概念模型中,构成使用对象与数据库对象的逐一对应,保持了5个使用对象在目标系统设计中原有的 独立性,具有很好的封装性和信息隐蔽性。虽然流水号表会有一些冗余,但它是值得的。

　　五、面向对象关系数据库设计效果

　　在公路局系统设计中,从某种意义上讲,是数据库设计的面向对象特征最终奠定了整个系统的面向对象性,才使面向对象方法在程序开发阶段全面开花。其效果归纳如下:

　　1. 数据库结构清晰
　　便于实现OOP由于实现了使用模块对象对数据库对象的完全映射,数据库逻辑模型可以自然且直接 地模仿理想世界的实体关系。公路局用户所处的当前物理世界、系统开发者所笼统的系 统外部功用,与支持系统功用的内部数据库 (数据结构)逐一对应,所以用户、开发者和数 据库维护人员可以用分歧的言语进行沟通。 特别是对多数不了解公路局业务的程序开发人员来说,这种将使用对象与相应的数据 对象封装在对象统一体中的设计方法,大大减轻了程序实现的难度,使他们只需知道加工的数据及所需的操作即可,而且使用程序大多雷同,可以多处承继由设计人员笼统出来的 、事后开发好的各种物理级超类。

　　2. 数据库对象具有独立性,便于维护
　　除了数据库表对象与使用模块对象逐一对应外,在逻辑对象模型中我们没有设计多重 承继的泛化关系,所以这样得到的数据库结构基本上是由父表类和子表类构成的树型层次 结构,表类间很少有承继以外的复杂关系,是一个符合局部化准绳的结构,从而使数据库表 数据破坏的影响控制在局部范围且便于修复,给公路局系统开通后的数据库日常维护任务带来便利。

　　3. 需求变更时程序与数据库重用率高,修正少
　　在映射使用对象时,除关系映射规范化