数据库对象
-
2023年2月19日发(作者：)数据库⾯向对象设计
⾯向对象的关系数据库设计
⼀、概念的区分
有些⼈把⾯向对象的数据库设计(即数据库模式)思想与⾯向对象数据库管理系统(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来描述。
概念模式可以由若⼲个内部模式聚集⽽成,它是由数据库⽤户规范的⼀些表的集合。⼀般的概念模式是数据库物理模式作⽤域的边界,它能实
现数据库的物理意义、特定DBMS的特殊操作对外部应⽤程序的信息隐蔽。外部模式是从特定⽤户应⽤⾓度看待的数据库模式,从不同的应
⽤出发对同⼀概念模式可以给出多种不同的外部模式。当外部应⽤系统以对象模型进⾏抽象时,从各个应⽤出发抽象出的对象模型可以映射到
外部模型上,对此我们不妨称之为外部对象模型。但是,外部模型只是概念模型的⼦集,所以⾯向对象的数据库设计核⼼在于系统对象模型(不妨
称之为概念对象模型)向数据库概念模型的映射。
2、对象模型向数据库表的映射规则
由于RDBMS是以⼆维表为基本管理单元的,所以对象模型最终是由⼆维表及表间关系来描述的。换⾔之,对象模型向数据库概念模型的映射
就是向数据库表的变换过程。有关的变换规则简单归纳如下:
(1)⼀个对象类可以映射为⼀个以上的库表,当类间有⼀对多的关系时,⼀个表也可以对应多个类。(2)关系(⼀对⼀、⼀对多、多对多以及
三项关系)的映射可能有多种情况,但⼀般映射为⼀个表,也可以在对象类表间定义相应的外键。对于条件关系的映射,⼀个表⾄少应有3个属
性。
(3)单⼀继承的泛化关系可以对超类、⼦类分别映射表,也可以不定义⽗类表⽽让⼦类表拥有⽗类属性;反之,也可以不定义⼦类表⽽让⽗类表
拥有全部⼦类属性。
(4)对多重继承的超类和⼦类分别映射表,对多次多重继承的泛化关系也映射⼀个表。(5)对映射后的库表进⾏冗余控制调整,使其达到合
理的关系范式。3、数据库模式要⾯向应⽤系统
我们选择⾯向对象的系统设计也好,⾯向对象的数据库设计也好,根本⽬的是服务于应⽤系统的需要。
五、⾯向对象关系数据库设计效果
从某种意义上讲,是数据库设计的⾯向对象特征最终奠定了整个系统的⾯向对象性,才使⾯向对象⽅法在程序开发阶段全⾯开花。其效果归纳
如下:
1、数据库结构清晰,便于实现OOP
由于实现了应⽤模块对象对数据库对象的完全映射,数据库逻辑模型可以⾃然且直接地模拟现实世界的实体关系。⽤户所处的当前物理世界、
系统开发者所抽象的系统外部功能,与⽀持系统功能的内部数据库(数据结构)⼀⼀对应,所以⽤户、开发者和数据库维护⼈员可以⽤⼀致的语
⾔进⾏沟通。特别是对多数不了解业务的程序开发⼈员来说,这种将应⽤对象与相应的数据对象封装在对象统⼀体中的设计⽅法,⼤⼤减轻了
程序实现的难度,使他们只要知道加⼯的数据及所需的操作即可,⽽且应⽤程序⼤多雷同,可以多处继承由设计⼈员抽象出来的、预先开发好的
各种物理级超类。2、数据库对象具有独⽴性,便于维护
除了数据库表对象与应⽤模块对象⼀⼀对应外,在逻辑对象模型中我们没有设计多重继承的泛化关系,所以这样得到的数据库结构基本上是由
⽗表类和⼦表类构成的树型层次结构,表类间很少有继承以外的复杂关系,是⼀个符合局部化原则的结构,从⽽使数据库表数据破坏的影响控制
在局部范围且便于修复,给系统开通后的数据库⽇常维护⼯作带来便利。3、需求变更时程序与数据库重⽤率⾼,修改少
在映射应⽤对象时,除关系映射规范化后可能出现⼀对多的表映射外,⼤多数应⽤对象与表对象是⼀⼀对应的。我们可以把规范化处理后的、
由⼀个应⽤对象映射出来的多个表看成⼀个数据库对象。因此当部分应⽤需求变更时,⾸先,系统修改可以不涉及需求不变更的部分。其次,变
更部分的修改可以基本上只限于追加或删除程序模块或追加新库表,⽽基本上不必修改原有程序代码或原有库表定义,从⽽⼤⼤减少了⼯作量,
降低了⼯作难度。
六、最简单的就是最好的
客观世界是错综复杂的,计算机科学理论的发展也越来越⾼深、复杂。然⽽,⼈类探索理论和技术的最终⽬的是:让客观世界的复杂变简单,最简
单的就是最好的。为此我们遵循以下原则:1、慎⽤外键
RDBMS⽀持复杂关系的能⼒很强,⽆论⽤户怎么在逻辑上设定外键,它基本上都能从物理上帮⽤户实现。但是外键把许多独⽴的实体牵连在
⼀起,不仅使RDBMS维持数据⼀致性负担沉重,也使数据库应⽤复杂化,加重了程序开发负担。这样的数据库很难理解,很难实现信息隐蔽性
设计,往往把简单问题复杂化。2、适当冗余
减少数据库冗余的设计思路产⽣于70年代,它是促使DBMS进步的重要动⼒之⼀。然⽽,犹如为了节省2个字节的存储空间⽽酿成了如今全球
为之头痛的2000年问题⼀样,它是计算机硬件主导时代的产物。以今天国内计算机市场价格为例,6G服务器硬盘的价格不过2000元,⽽上海
物价局1996年颁发的⼀个⼈⽉软件开发的指导价约8000元,即⼀个⼈⽉的软件价格就可以购买20G左右的硬盘。即使有5万⾏数据的库
表,每个记录压缩40字符的冗余,单纯计算合计也不⾜2M,即节省0.6元钱的磁盘空间。
今天的世界已进⼊软件主导的计算机时代。因此,最容易理解、应⽤开发⼯作量最少、维护最简单的数据库结构才是最好的。只要数据完整
性、⼀致性不受威胁,有些冗余,不⾜为虑。换⾔之,最节省软件成本(⽽不是硬件成本)的是最好的。3、信息隐蔽
这是软件⼯程最重要的基本原则之⼀。简⾔之即信息的作⽤域越⼩越好,数据库的透明度越⼤越好,因为应⽤程序需要知道得越多就越复杂。
使数据库⿊盒化(透明度⾼)的⽅法很多,除了设计上的局部化处理外,还可以利⽤DBMS的触发器、存储过程、函数等,把数据库中⽆法简化
的复杂表关系封装到⿊盒⼦⾥,隐藏起来,特别是放到服务器端,其优越性更是多⽅⾯的。