小小飞鹰

     中国人缺少的是步骤,太急。练太极!
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

映射原理

Posted on 2007-02-13 14:48  小小飞鹰  阅读(1934)  评论(0编辑  收藏  举报

 

 

 

映射原理

 

 

 

 

 

一方面,面向对象技术是应用于新软件系统开发的最常见的环境。另一方面,关系数据库仍然是许多人都青睐的持久信息存储方法,并且在较长时间内这种情况不太会改变。对象模型基于软件工程的一些原理,例如抽象、封装、继承、聚合和多态,而关系数据模型则基于数学原理,特别是集合论的原理。两种不同的理论基础导致各自有不同的优缺点。而且,对象模型侧重于从包含数据和行为的对象中构建应用程序,而关系数据模型则主要针对数据的存储。对象模型和关系模型之间的这种失配称为“阻抗不匹配”。当为数据访问寻找一种合适的方法时,“阻抗不匹配”就成了主要矛盾:使用对象模型,你是通过它们的关系来访问对象,而使用关系数据模型,则通过冗余数据来联接表中的行。

由于面向对象的模型和关系数据模型的“阻抗不匹配”需要存储在关系数据库中时,需要进行对象/关系的映射当应用系统中的对象。对象/关系的映射(Object/Relational Mapping)是指这样的一种操作:它试图将对象的状态映射到关系数据库的数据上,以便提供透明的持久性。

 

ANSI三层数据库模型已经推出二十年了,但它至今还象过去一样广泛使用。一般关系型数据库设计大多参照这种模型。最接近物理数据库的内部模式也称存储模式,它是数据物理结构和存储方式的描述,是数据在数据库内部的表示方式,一个数据库只有一个内部模式,由DBMS提供的SQL来描述。处于数据库模式结构中间层的是模式,也称逻辑模式,逻辑模式由内部模式聚集而成,它是由数据库用户规范的一些表的集合。一般的逻辑模式是数据库物理模式作用域的边界,它能实现数据库的物理意义、特定DBMS的特殊操作对外部应用程序的信息隐蔽。逻辑模式是数据库中全体数据的逻辑结构和特征的描述,是所有用户的公共数据视图。逻辑模式既不涉及数据的物理存储细节和硬件环境,也与具体的应用程序,与所使用的应用开发工具就程序设计语言无关。外部模式是从特定用户应用角度看待的数据库模式,它是数据库用户能够看见和使用的局部数据的逻辑结构和特征的描述,是数据库用户的数据视图,从不同的应用出发对同一逻辑 模式可以给出多种不同的外部模式。当外部应用系统以对象模型进行抽象时,从各个应用出发抽象出的对象模型可以映射到关系型数据库的外部模式上,对此可称之为外部对象模型。但是,外部模型只是概念模型的子集,所以面向对象的关系数据库设计核心在于系统对象模型(不妨称之为概念对象模型)向数据库逻辑模式的映射,即O/R Mapping(对象/关系的映射)。而O/R Mapping同时也是一个采用关系数据库的面向对象软件系统成功的决定性因素之一。

O/R Mapping解决方案一般把每个对象映射到数据库表的单个行上,这一行通常来自一个表,但有时由一个表的连接操作产生。如果RDBMS支持可更新视图,使用一个视图来简化映射或许是可能的。一般来说,O/R Mapping解决方案允许这种映射不用自定义代码就能进行,从而向编程人员隐藏低级数据存储细节。映射通常被保存在那些己映射类外部的元数据中。

O/R Mapping在通常情况下工作得很好,可以达到提高开发效率、降低开发成本及问题复杂度的目的,但有时可能就并非是最好的解决方案。O/R Mapping是面向对象软件系统访问关系数据库最好的解决方案的假设是有疑问的。O/R Mapping既有优点,也有缺点,也就是说在使用它之前应该仔细考虑。

O/R Mapping的重要作用是它消除了开发人员编写低级数据访问代码的需要,这在某些应用中能够极大地提高工作效率,从而保证应用代码专心地处理对象,以及能够导致创建一个可以支持多个用例的域对象模型。

但是存在这样一种危险:O/R Mapping降低总复杂性的程度不象把它用到别处所降低的程度那么大,即在某些应用中O/R Mapping可能对降低总复杂性的作用不大,而且O/R Mapping本身也带来了新的复杂性。以J2EE的容器管理持久性实体组件(Container Managed Persistence EntityBean)为例,结果可能是复杂的部署描述符,而且透明数据访问的代价是对这种访问的控制力度变弱。

O/R Mapping的效率也是有疑问的。O/R Mapping解决方案一般假设RDBMS打算在单行和单列上操作。这是一种误解:RDBMS在元组集上操作最佳。例如,用单个SQL操作更新多个行比分别地更新每个行要快得多。如果把数据高速缓存在对象层是可行的,O/R Mapping解决方案就会提供杰出的性能:如果这是不可能的,或者在聚集更新被需要时,通常会显著增加系统开销。

真正高级的O/R Mapping解决方案能使我们充分享受它的好处,同时又没有这些缺点中的一部分。所以不应假设O/R Mapping是所有使用关系数据库的面向对象软件应用的最佳解决方案。它在某些情况中工作得很好,但有时没有一点好处。下面是一个O/R Mapping解决方案没有起到帮助作用的标志。在对象驱动建模的情况中,它导致一个不自然的RDBMS模式,其中该模式限制了性能,并且对其它过程是无用的。一个不自然的RDBMS模式的标志包括常见数据操作中需要复杂的连接,RDBMS不能实施参照完整性,以及在一个较好的模式已经允许使用一个集合操作的地方却需要发布许多个别更新。

  1) 在数据库驱动建模的情况中,它产生一个对象层,其中对象与RDBMS中的表有一个一对一的关系。除非这些表从对象模型中产生,否则这些表可能不是真正的对象,而且处理它们可能是不自然的和低效率的。如果RDBMS模式发生变化,处理这些对象的所有代码也将需要变化。

  2) 它导致低效率的查询和更新。

  3) 在关系数据库内可以使用关系操作轻松而有效地执行的一些任务在软件应用中可能需要实质的编程来完成,或者可能导致许多对象的多余创建。

在一个采用关系数据库的面向对象软件系统中实施O/R Mapping通常包含如下三个步骤:

1) 映射:选择有效的映射策略(即如何映射对象模型到关系模型)将对象模型向数据库关系模型映射,这就是类向数据库表的变换过程。需要映射的除了对象的属性外还包括对象之间的关系和对象类之间的继承结构。

2) 实现映射:选择适当的映射框架或技术、工具在软件系统中实现上一步中的映射,通常可以设计一个位于业务逻辑层和关系数据库之间的O/R Mapping层来完成对象和数据库间的转换。

3) 性能调整:为提供整体性能而对数据模型、O/R Mapping及其实现、对象模型等系统各方面进行适当的调整。


 

非有希望才坚持,坚持才会有希望