面向对象的数据库设计

流水的流啊

很多数据库应用系统开发者不重视数据库设计的原因是:他们太迷信DBMS,认为购入
一个功能强大的 DBMS后数据库设计就不困难、不重要了。一些国内外的数据库教材常常
是在为DBMS的开发厂商做宣传,而很少站在数据库用户角度,从数据库应用系统出发介绍
数据库设计方法。结果往往使读者搞不清书中介绍的是数据库管理程序的设计思想,还是
应用这种 DBMS 进行数据库设计的思想。
其实,DBMS只是给用户为已采用的数据库提供一个舞台,而是否使用这个舞台上的道
具以及唱什么戏,则完全取决于用户的戏剧脚本和导演(开发者)的安排。例如,公路局系
统所使用的数据库管理系统,是以二维表为基本管理单元、支持所有关系代数操作、支持
实体完整性与实体间参照完整性的全关系型 RDBMS,而我们要在这个舞台上利用上述"道
具"设计一个面向对象的关系数据库。
四、应用对象模型与RDBMS模型的映射
数据库设计(模式)是否支持应用系统的对象模型,这是判断是否是面向对象数据库
系统的基本出发点。由于应用系统设计在前,数据库设计随后,所以应用系统对象模型向
数据库模式的映射是面向对象数据库设计的关键。
1. 3层数据库模式面向对象模型的扩展
一般数据库设计多参照ANSL/SPARC关于数据库模式的3层标准结构提案。最接近物理
数据库的内部模式由 DBMS 提供的SQL来描述。概念模式可以由若干个内部模式聚集而成
,它是由数据库用户规范的一些表的集合。例如,公路局计划处数据库模式、机务处数据
库模式等,它们是逻辑数据库,常常通过库表ID来界定库边界。一般的概念模式是数据库
物理模式作用域的边界,它能实现数据库的物理意义、特定DBMS 的特殊操作对外部应用
程序的信息隐蔽。外部模式是从特定用户应用角度看待的数据库模式,从不同的应用出发
对同一概念模式可以给出多种不同的外部模式。例如:公路绿化情况查询应用看到的数据
库是公路上的树木种类、数量、分布比率等,桥梁隧道状况查询应用看到的是公路上的桥
梁、隧道长度、个数、路段等,但是它们可能访问的是同一个库表的不同子集。
当外部应用系统以对象模型进行抽象时,从各个应用出发抽象出的对象模型可以映射
到外部模型上,对此我们不妨称之为外部对象模型。但是,外部模型只是概念模型的子集
,所以面向对象的数据库设计核心在于系统对象模型(不妨称之为概念对象模型) 向数据
库概念模型的映射(参见图1) 。
2. 对象模型向数据库表的映射规则
由于 RDBMS 是以二维表为基本管理单元的,所以对象模型最终是由二维表及表间关
系来描述的。换言之,对象模型向数据库概念模型的映射就是向数据库表的变换过程。有
关的变换规则简单归纳如下:
(1) 一个对象类可以映射为一个以上的库表,当类间有一对多的关系时,一个表也可
以对应多个类。
@@0564200.JPG;图1 3层数据库模式面向对象模型的扩展@@
(2) 关系(一对一、一对多、多对多以及三项关系)的映射可能有多种情况,但一般映
射为一个表,也可以在对象类表间定义相应的外键。对于条件关系的映射,一个表至少应
有3个属性。
(3) 单一继承的泛化关系可以对超类、子类分别映射表,也可以不定义父类表而让子
类表拥有父类属性;反之,也可以不定义子类表而让父类表拥有全部子类属性。
(4) 对多重继承的超类和子类分别映射表,对多次多重继承的泛化关系也映射一个表
。
(5) 对映射后的库表进行冗余控制调整,使其达到合理的关系范式。
3. 数据库模式要面向应用系统
我们选择面向对象的系统设计也好,面向对象的数据库设计也好,根本目的是服务于
应用系统的需要。
以公路局计划处子系统为例。计划处的最大工作量就是处理成堆的报表,因此如何有
效地存取这些报表是计划处数据库设计的关键。考虑到每月上交的报表是同构的,我们可
以创建一张库表去存储同一种报表,例如公路工程月报表。但是又产生另一个问题,当用
户想查询某个月的公路工程月报表时,如何从库表中取出数据呢?按照数据库的思想应该
有一个主键来标识这张报表。在公路局的报表里,区别月报表靠上报时间和上报单位,但
如果为每条记录都加上这两个字段,无疑会加大库表冗余,增加查询时间,降低效率。更何
况每张报表都有单位负责人、填表人的属性,那么怎样解决这个问题呢?我们设计了超类
对象 X3 表和流水号表。X3 表和流水号表的表结构如下。
@@0564201.JPG;表1 X3表和流水号表的表结构:@@
将它们加入由应用对象模型映射出的数据库概念模型后,得到图2所示的结构。
每一个应用模块对象对应建立一张流水号表,同一类的报表属同一流水号表,由流水
号表统一管理。流水号表对各分局、处室提交和建立的每一张报表分配一个流水号,该流
水号在整个数据库中是唯一的,因此在库中存放任何一张报表都是明确的。流水号的数据
类型为 Char(10),前4位为表号,后6位为序列号,其中序列号取自 X3表中最大序列号。也
就是说,流水号就是对象标识符,报表是一个对象,一个对象标识符唯一决定一个对象。流
水号一旦被分配出去后,在这张报表的生存期内就具有了永久不变性。无论报表的内容及
结构怎么变化,它都不变,直到报表被删除,流水号才会消失。流水号表是父类,报表是子
类,流水号表之间的联系只能通过 X3 表。5个应用模块对象完全映射到数据库概念模型
中,形成应用对象与数据库对象的一一对应,保持了5个应用对象在目标系统设计中原有的
独立性,具有很好的封装性和信息隐蔽性。尽管流水号表会有一些冗余,但它是值得的。
@@0564202.JPG;图2 超类对象间关系示意图@@
五、面向对象关系数据库设计效果
在公路局系统设计中,从某种意义上讲,是数据库设计的面向对象特征最终奠定了整
个系统的面向对象性,才使面向对象方法在程序开发阶段全面开花。其效果归纳如下:
1. 数据库结构清晰,便于实现 OOP
由于实现了应用模块对象对数据库对象的完全映射,数据库逻辑模型可以自然且直接
地模拟现实世界的实体关系。公路局用户所处的当前物理世界、系统开发者所抽象的系
统外部功能,与支持系统功能的内部数据库 (数据结构)一一对应,所以用户、开发者和数
据库维护人员可以用一致的语言进行沟通。
特别是对多数不了解公路局业务的程序开发人员来说,这种将应用对象与相应的数据
对象封装在对象统一体中的设计方法,大大减轻了程序实现的难度,使他们只要知道加工
的数据及所需的操作即可,而且应用程序大多雷同,可以多处继承由设计人员抽象出来的
、预先开发好的各种物理级超类。
2. 数据库对象具有独立性,便于维护
除了数据库表对象与应用模块对象一一对应外,在逻辑对象模型中我们没有设计多重
继承的泛化关系,所以这样得到的数据库结构基本上是由父表类和子表类构成的树型层次
结构,表类间很少有继承以外的复杂关系,是一个符合局部化原则的结构,从而使数据库表
数据破坏的影响控制在局部范围且便于修复,给公路局系统开通后的数据库日常维护工作
带来便利。
3. 需求变更时程序与数据库重用率高,修改少
在映射应用对象时,除关系映射规范化后可能出现一对多的表映射外,大多数应用对
象与表对象是一一对应的。我们可以把规范化处理后的、由一个应用对象映射出来的多
个表看成一个数据库对象。因此当部分应用需求变更时,首先,系统修改可以不涉及需求
不变更的部分。其次,变更部分的修改可以基本上只限于追加或删除程序模块或追加新库
表,而基本上不必修改原有程序代码或原有库表定义,从而大大减少了工作量,降低了工作
难度。
六、最简单的就是最好的
客观世界是错综复杂的,计算机科学理论的发展也越来越高深、复杂。然而,人类探
索理论和技术的最终目的是:让客观世界的复杂变简单,最简单的就是最好的。为此我们
给出以下几点忠告:
1. 慎用外键
RDBMS 支持复杂关系的能力很强,无论用户怎么在逻辑上设定外键,它基本上都能从
物理上帮用户实现。但是外键把许多独立的实体牵连在一起,不仅使 RDBMS 维持数据一
致性负担沉重,也使数据库应用复杂化,加重了程序开发负担。这样的数据库很难理解,很
难实现信息隐蔽性设计,往往把简单问题复杂化。
2. 适当冗余
减少数据库冗余的设计思路产生于70年代,它是促使 DBMS 进步的重要动力之一。然
而,犹如为了节省2个字节的存储空间而酿成了如今全球为之头痛的2000年问题一样,它是
计算机硬件主导时代的产物。以今天国内计算机市场价格为例,6G服务器硬盘的价格不过
2000元,而上海物价局 1996 年颁发的一个人月软件开发的指导价约8000元,即一个人月
的软件价格就可以购买20G左右的硬盘。即使有5万行数据的库表,每个记录压缩40字符的
冗余,单纯计算合计也不足2M,即节省0.6元钱的磁盘空间。
今天的世界已进入软件主导的计算机时代。因此,最容易理解、应用开发工作量最少
、维护最简单的数据库结构才是最好的。只要数据完整性、一致性不受威胁,有些冗余,
不足为虑。换言之,最节省软件成本 (而不是硬件成本) 的是最好的。
3. 信息隐蔽
这是软件工程最重要的基本原则之一。简言之即信息的作用域越小越好,数据库的透
明度越大越好,因为应用程序需要知道得越多就越复杂。使数据库黑盒化 (透明度高) 的
方法很多,除了设计上的局部化处理外,还可以利用 DBMS 的触发器、存储过程、函数等
,把数据库中无法简化的复杂表关系封装到黑盒子里,隐藏起来,特别是放到服务器端,其
优越性更是多方面的。