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 的触发器、存储过程、函数等,把数据库中无法简化的复杂表关系封装到黑盒子里,隐藏起来,特别是放到服务器端,其优越性更是多方面的。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
