1.三层数据库模式面向对象模型的扩展
一般数据库设计多参照ANSL/SPARC关于数据库模式的3层标准结构提案。最接近物理数据库的内部模式由 DBMS 提供的SQL来描述。概念模式可以由若干个内部模式聚集而成，它是由数据库用户规范的一些表的集合。例如，公路局计划处数据库模式、机务处数据库模式等，它们是逻辑数据库，常常通过库表 ID来界定库边界。一般的概念模式是数据库物理模式作用域的边界，它能实现数据库的物理意义、特定DBMS 的特殊操作对外部应用程序的信息隐蔽。外部模式是从特定用户应用角度看待的数据库模式，从不同的应用出发对同一概念模式可以给出多种不同的外部模式。例如：公路绿化情况查询应用看到的数据库是公路上的树木种类、数量、分布比率等，桥梁隧道状况查询应用看到的是公路上的桥梁、隧道长度、个数、路段等，但是它们可能访问的是同一个库表的不同子集。
当外部应用系统以对象模型进行抽象时，从各个应用出发抽象出的对象模型可以映射到外部模型上，对此我们不妨称之为外部对象模型。但是，外部模型只是概念模型的子集，所以面向对象的数据库设计核心在于系统对象模型(不妨称之为概念对象模型) 向数据库概念模型的映射(参见图1) 。
2.对象模型向数据库表的映射规则
由于 RDBMS 是以二维表为基本管理单元的，所以对象模型最终是由二维表及表间关系来描述的。换言之，对象模型向数据库概念模型的映射就是向数据库表的变换过程。有关的变换规则简单归纳如下：
（1）一个对象类可以映射为一个以上的库表，当类间有一对多的关系时，一个表也可以对应多个类。
图1 三层数据库模式面向对象模型的扩展
（2）关系(一对一、一对多、多对多以及三项关系)的映射可能有多种情况，但一般映射为一个表，也可以在对象类表间定义相应的外键。对于条件关系的映射，一个表至少应有3个属性。
（3）单一继承的泛化关系可以对超类、子类分别映射表，也可以不定义父类表而让子类表拥有父类属性；反之，也可以不定义子类表而让父类表拥有全部子类属性。
（4）对多重继承的超类和子类分别映射表，对多次多重继承的泛化关系也映射一个表。
（5）对映射后的库表进行冗余控制调整，使其达到合理的关系范式。
3.数据库模式要面向应用系统
我们选择面向对象的系统设计也好，面向对象的数据库设计也好，根本目的是服务于应用系统的需要。
以公路局计划处子系统为例。计划处的最大工作量就是处理成堆的报表，因此如何有效地存取这些报表是计划处数据库设计的关键。考虑到每月上交的报表是同构的，我们可以创建一张库表去存储同一种报表，例如公路工程月报表。但是又产生另一个问题，当用户想查询某个月的公路工程月报表时，如何从库表中取出数据呢?按照数据库的思想应该有一个主键来标识这张报表。在公路局的报表里，区别月报表靠上报时间和上报单位，但如果为每条记录都加上这两个字段，无疑会加大库表冗余，增加查询时间，降低效率。更何况每张报表都有单位负责人、填表人的属性，那么怎样解决这个问题呢？我们设计了超类对象 X3 表和流水号表。X3 表和流水号表的表结构如下。
表1 X3表和流水号表的表结构：
将它们加入由应用对象模型映射出的数据库概念模型后，得到图2所示的结构。
每一个应用模块对象对应建立一张流水号表，同一类的报表属同一流水号表，由流水号表统一管理。流水号表对各分局、处室提交和建立的每一张报表分配一个流水号，该流水号在整个数据库中是唯一的，因此在库中存放任何一张报表都是明确的。流水号的数据类型为 Char(10)，前4位为表号，后6位为序列号，其中序列号取自 X3表中最大序列号。也就是说，流水号就是对象标识符，报表是一个对象，一个对象标识符唯一决定一个对象。流水号一旦被分配出去后，在这张报表的生存期内就具有了永久不变性。无论报表的内容及结构怎么变化，它都不变，直到报表被删除，流水号才会消失。流水号表是父类，报表是子类，流水号表之间的联系只能通过 X3 表。5个应用模块对象完全映射到数据库概念模型中，形成应用对象与数据库对象的一一对应，保持了5个应用对象在目标系统设计中原有的独立性，具有很好的封装性和信息隐蔽性。尽管流水号表会有一些冗余，但它是值得的。
图2 超类对象间关系示意图
文章来源于领测软件测试网 https://www.ltesting.net/
