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

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

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

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

　　(4) 对多重继承的超类和子类分别映射表,对多次多重继承的泛化关系也映射一个表 。

　　(5) 对映射后的库表进行冗余控制调整,使其达到合理的关系范式。

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

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

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

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

　　其效果归纳如下:

　　1. 数据库结构清晰

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

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