（计算机应用技术专业论文）基于j2ee的数据持久模型的设计与应用.pdf

东南大学硕士学位论文 基于j 2 e e 的数据持久模型设计与应用 摘要： 在r r 技术飞速发展的今天，面向对象技术已经成为企业软件开发的主流技术，利用 对象模型，能够很好地描述和设计复杂的软件系统。在软件系统中，有些对象是需要永 久保存的，而实现对象的存储( 数据持久) 大多使用的是技术成熟的关系数据库技术。 本文针对面向对象技术和关系数据库这一企业应用开发的通用环境，研究了数据的持久 解决方案并实现了数据持久模型。 由于面向对象和关系数据库在处理方式上的差异，导致了关系对象阻抗的不匹配， 使得对象设计者花费大量的时问实现对象在关系数据库中的持久。本文讨论了解决数据 持久问题的各种技术，利用在对象和关系数据库之间建立映射的机制，来消除面向对象 和关系数据类型的不匹配。根据上述映射的机制建立了持久层的实现模型，并就模型的 设计策略、模型框架、实现关键技术详细进行了讨论。本文使用代理模式进行持久化管 理，将底层的数据访问独立封装起来，根据业务请求和映射信息文件动态的生成s q l 代码，从而使得对象模型与关系数据库之间具有无关性。基于对象一关系映射，本文实 现了一个基于j 2 e e 架构的功能完备的持久层。 相关问题实际应用表明，运用该模型实现的企业应用系统功能能够满足实际需求， 开发方便快捷，运行性能稳定可靠。此外，本文所使用的代理和缓冲机制等技术也在一 定程度上提高了性能。 关键词：对象，关系数据库，j 2 e e ，映射，数据持久 东南大学硕士学位论文 d e s i g na n dr e a l i z a t i o nd a t ap e r s i s t e n c el a y e rm o d e l b a s e do nj 2 e e a b s t r a c t ： i n f o r m a t i o nt e c h o l o g yi sar a p i dd e v e l o p m e n ta r e a o b j e c t o r i e n t e dt e c h n i c a lh a sp l a y e d av e r yi m p o r t a n tr o l ei nt h ee n t e r p r i s es o f td e v e l o p m e n t t h ec o m p l e xs o f t w a r es y s t e mc 姐b e w e l ld e s c r i b e da n dd e s i d a e db yo b j e c t o r i e n t e dm o d e l i ns o f t w a r es y s t e ms o m eo b j e c t ss h o u l d b es t r o e df o rf u t u r eu s e a n dw eu s et h em a t u r er e l a t i o nd a t a b a s es y s t e mt os t o r eao b j e c ta t m a n yl i m e s t h i sa r t i c l ea p p l i e st h ed e v e l o p m e n ti no b j e c t o r i e n t e dt e c h n i c a la n dr e l a t i o n a l d a t a b a s et h eg e n e r a le n t e r p r i s ee n v i r o n m e n t ，r e s e a r c hal e v e ls o l u t i o ni nd a t ap e r s i s t e n c e b e c a u s et h ed i f f e r e n c eb e t w e e no b j e c t - o r i e n t e da n dt h er e l a t i o n a ld a t a b a s e t h ed e s i g n e r m u s ts p e n dm o r et i m eo nr e s o l v et h ed a t ap e r s i s t e n c e w jd i s c u s st e c h o l o g i e st h a tr e s l o v et h e d a t ap e r s i t e n c e f o rr e s o l v i n gt h ep r o b l e mm e n t i o n e dd a t ap e r s i s t e n c e ，t h ep a p e ru s em a p p i n g m e c h a n i s m st oe l i m i n a t ei m p e d a n c em i s m a t c h a c c o r d i n gt h em a p p i n gm e c h a n i s m sw e g i v e t h ed a t ap e r s i s t e n c em o d e l w eu s ep o x ym o d e lt om a n a g e rd a t ap e r s i s t e n c e ，w e c o m p l e t e l ym a k et h eb o t t o md a t aa c c e s se n c a p s u l a t e di n d e p e n d e n c y a c c o r d i n gt h eq u e r yo f o p e r a t i o na n dm a p p i n gi n f o r m a t i o nb u i l d i n gs q lc o d ed y n a m i c l y , a n dt h ei n d e p e n d e n c y b e t w e e no b j e c t - o r i e n t e da n dr e l a t i o n a ld a t a b a s ei si m p l a n t e d t h i sa r t i c l eh a sr e a l i z e da f u n c t i o nc o m p l e t ep e r s i s t e n c el a y e rm o d e lb a s e do nt h ej 2 e ef r a m ea n dt h eo b j e c t - r e l a t i o n a l m a p p i n g t h ep r a c t i c a lo ft h e a p p l i c a t i o n i n d i c a t e dt h a t ，u t i l i z e st h i sm o d e lr e a l i z a t i o nt h e e n t e r p r i s ea p p l i c a t i o ns y s t e mf u n c t i o nt ob ea b l et om e e tt h ea c t u a ln e e d ，t h ed e v e l o p m e n ti s c o n v e n i e n c ea n dq u i c k , t h ep e r f o r m a n c ec h a r a c t e r i s t i cs t a b l ea n dr e l i a b l e a l s ow er e s e a r c h s o m et e c h n o l o g i e ss u c ha sp r o x ya n db u f f e rt oi m p r o v et h ep e r f m a n c e k e y w o r d s ：o b j e c t ，r e l a t i o n a ld a t a b a s e ，j 2 e e ，m a p p i n g ，d a t ap e r s i s t e n c e i i 东南大学学位论文独创性声明 本人声明所呈交的学位论文是我个人在导师指导下进行的研究工作及取得的研究成 果。尽我所知，除了文中特别加以标注和致谢的地方外，论文中不包含其他人已经发表 或撰写过的研究成果，也不包含为获得东南大学或其它教育机构的学位或证书而使用过 的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说明并 表示了谢意。 研究生签名：j ! 交 日期：2 ：苎幺止f 孑 东南大学学位论文使用授权声明 东南大学、中国科学技术信息研究所、国家图书馆有权保留本人所送交学位论文的 复印件和电子文档，可以采用影印、缩印或其他复制手段保存论文。本人电子文档的内 容和纸质论文的内容相一致。除在保密期内的保密论文外，允许论文被查阅和借阅，可 以公布( 包括刊登) 论文的全部或部分内容。论文的公布( 包括刊登) 授权东南大学研 究生院办理。 研究生签名： 型! i 呈 导师签名日期：少多，二p 第一章引言 1 1 研究背景 第一章引言 数据是构成企业信息系统的最主要元素之一。企业应用一般会涉及到持久化即需要长期保存的 数据。事实上企业数据甚至比相关应用系统软件和硬件的生命周期还要长，因为即使企业有了新的 应用软件和硬件，原有的数据也常常需要被移植到新的系统中去，而企业的应用软件必须有效的组 织和使用这些关键的数据。因此，业务应用程序中的数据访问功能对于企业应用软件的质量和可用 性起着举足轻重的作用。开发人员必须花费很大的精力设计有效的数据访问代码，否则整个应用程 序就可能存在缺陷或者达不到理想的运行速度。 将数据持久化( 即长期保存) 可以有多种方案，早期的系统多使用文件索引系统，如i b m 的 v s a m 和i s a m 。从2 0 世纪6 0 年代末开始。数据库技术经历了层次数据库、网状数据库和关系数据 库而进入数据库管理系统。而自2 0 世纪8 0 年代以来，关系数据库成为应用的主流，几乎所有新推 出的d b m s 产品都是关系型的。关系型数据库在计算机数据管理的发展史上是一个重要的里程碑， 这种数据库具有数据结构化，最低冗余度、较高的程序与数据独立性、易于扩充、易于编制应用程 序等优点，目前企业的信息系统基本上都是建立在关系型数据库设计之上的。 另一方面，在软件开发领域，从8 0 年代开始的面向对象技术被认为一种有效的软件开发技术。 面向对象的软件，以数据为中心设计，对象类既具有模块的封装性和类属等特性，也还具有继承特 性极大地提高了类的可扩充性和可重用能力。面向对象技术目前已经以其优势得到了广泛的应用， 成为了企业应用系统开发的主流技术。在面向对象开发的规范中。当今比较流行的j 2 e e 架构提供了 一个企业级的应用模型及可用于开发和部署多层体系结构的运行环境。它通过提供企业应用环境所 必需的各种服务，使得部署在j 2 e e 平台上的多层应用可以实现高可用性、安全性、可扩展性和可靠 性。它的优越性在于：应用平台支持j a v a 语言，使用基于j 2 e e 标准开发应用可以跨平台移植：j a v a 语言非常安全、严格，这使开发者可以编写出可靠性很高的代码；j 2 e e 提供了企业计算中所需要的 服务，且更加易用；j 2 e e 中多数标准定义了接口，例如j n d i 、j d b c 、j a v a m a i l 等，因此可以和许 多厂商的产品进行配合，容易得到广泛的支持：j 2 e e 树立了一个广泛而通用的标准，大大简化了应 用开发和移植过程。 由此可见，j 2 e e 技术已经成为我们现在企业主流的软件开发技术，同时，后台我们系统大多数 采用的是技术成熟的关系数据库进行数据持久化的。但是使用关系数据库的面向对象系统开发人员 通常要花费大量的时间来将对象持久化，这是因为在两种技术间存在一个基本的阻抗不匹配。为什 么会产生对象- 关系阻抗不匹配。主要有以下几个原因： 表1 1 产生对象关系阻抗不匹配的原因 面向对象技术关系数据库技术 原理 基于软件工程的一些原理，例如耦合、聚 基于数学原理，特别是集合论 合和封装的原理 针对问题侧重于使用包含数据和行为的对象构建数据的存储 应用程序 东南大学硕士学位论文 使用方法通过对象之间的关系来访问对象通过复制数据来联接表中的行 类表 基本单位 对象实例 行 属性列 关系数据库和对象系统数据类型之间的阻抗不匹配。数据库表的字段和对象属性之间存在不同 的数据类型，不同数据类型的值需要转换。 对象关系和关系数据库的阻抗不匹配。对象之间有四种类型的关系：继承、关联、聚合和合成， 对象关系和关系数据库之间需要转换。 对象和数据库表之问的关系的阻抗不匹配。数据库表之间有三种关系：一对一、一对多和多对 多，数据库表之间的关系和对象系统之间需要转换。 因此，如果要使用关系数据库来存储对象，那么就必须在对象与关系数据库之间进行必要的转 换。 1 2 研究的现实意义 在系统开发的过程中，使用关系数据库的面向对象系统开发人员在处理对象持久化时，甚至不 得不去了解s q l 代码，从而整个的开发过程被数据库所限制，一旦将系统使用的数据库发生改变， 系统就会有大量的更改维护工作要做，甚至为对象增加很多变量，所以需要将领域知识从对象是如 何存储的知识中分离开。使得开发人员不会为这些变化所困。 在我们所开发的数字化校园系统中，不同子系统的后台数据访问都是类似的。如果纯粹的用 j d b c 实现，显然工作量比较大，而且代码冗余多，并且，后期维护也比较困难。使用实体b e a n ， 容器管理复杂，实现起来资源消耗大。由此设想设计一个数据持久模型，将它作为数据访问层的框 架，隐藏数据访问的细节，提供统一的接口，实现共通的操作。通过这个数据持久模型，可以快速 的开发数字化校园中的各个子系统，同时，如果业务领域发生变更或后台数据库发生变更，都不会 造成设计人员的大量的修改，便于维护。 通过此课题的研究，可以使开发者可以从繁杂的数据持久化工作中解放出来，将更大的精力放 在业务逻辑的获取和实现上。而且考虑效率问题，考虑了为数据持久模型设计一个运行时的环境， 保证数据访问的效率。因此，数据持久模型对于快速开发企业级应用程序具有现实的指导意义。 1 3 国内外研究现状 j a w 开始涉及数据库应用后s u n 公司就极力制定j a v a 的数据库规范，j d b c a p i 就是其中的一个典 型。该公司此后又发布e j b ( e n t e r p r i s ej a v a b e a n ) 规范，以及为了解决e j b 中实体b e a n 对数据重量级 封装j i ) o ( j a v ad a t ao b j e c t ) 规范，而且完成了不少j d o 的实现，如t o p l i n k ，o j b ，l i b e r a s t o rj d o , c a s t o r j d o ，t r i a c t i v ej d o 等等。此外，又有一些像h i b e r n a t e 这样的开源对象关系映射工具。但是，这些先 进的技术几乎都掌握在国外，国内虽然也有不少学者、工程师在研究数据持久化技术，但很少开发 出独立的持久化工具，使开发者从繁杂的数据持久化工作中解放出来，绝大多数企业都是直接使用 j d b ca p i ，或者使用e j b 实体b e a n ，或者购买第三方的持久化技术，或者使用像h i b e r n a t e ，c a s t o rj d o 这样的免费、开源的持久化工具。 2 第一章引言 上文中所提到的“数据持久”是指把数据存放在永久性存储空问中，而在j a v a 环境下一般有以 下几种技术技术来解决数据持久问题。 j a v a 对象序列化 对象序列化是最简单的j a v a 持久性策略。当操作j a v a 对象时，在很多情况下想要获得正在操作 的对象的状态，并存放到一个永久存储空间中，我们可以利用j a v a 的对象序列化技术做到这一点。 对象序列化是一个将对象图平面化为一个字节的线性序列的过程。对象图是作为对象继承、关联和 聚合的结果而实现的一些关系式。当序列化一个对象图时，就是将它转换为一个字节流。然后就可 以对这个字节流做任何人们想要做的处理，比如通过网络发送这些数据，或者将这个字节流存放到 一个存储空间中，例如文件系统，数据库。例如，假定我们想要存放l 万个学生信息对象到一个文件 系统中。我们可以将这些对象转换为位块形式，然后存放到磁盘中。再假定我们想要获取所有年龄 超过2 0 岁的学生信息。我们使用序列化来做到这一点，首先，从磁盘上加载每个学生信息序列化位 块，创建相应的对象，然后对这个对象执行一个查询方法，以判断年龄是不大于2 0 岁。 然而，对于复杂的持久化，对象序列化在很多方面存在缺陷。对象序列化必须要立即存取对象 的特征，同时在序列化的过程中，需要将对象图从内存具体化到持久存储中，这就涉及到大量的f o 开销。而且，它没有提供一个从序列化对象图中检索获取数据的查询语句，对大规模的应用，提交 基于商务数据的查询是绝对必要的。而且，在更改一个对象的属性时如果有错误发生它无法实现“回 滚”，因此不适于应用程序对数据完整性的要求，而且用户不能共享使用数据。这使得简单的对象序 列化不适合大多数持久化存储要求。虽然对象序列化有自己的用途，它最好用在有限的一些领域中， 比如网络通信和对持久化要求不高等领域。 j d b c 存储j a v a 对象的另一个常用方法是使用传统的关系数据库。这种方法并不将每一个对象序列化， 而是将每个对象分解为若干组成一个部分，并分开存储。当您使用关系数据库来存储j a v a 对象时， 您会利用j d b c 去映射对象数据到关系型数据库中，当从数据库中读回对象时，您会首先实例化访 对象，并利用j d b c 从数据库中读取数据到对象实例中，然后，将读入的数据复制到对象实例相应 的字段( 如图1 ) 。 擘生宙 。s t r in gs t u d e n t i d s t r in gs t u d e n t n a m e in t a g e s tr ln gg e n d e r s t r t n gp l ae e o f b i r t h ，一、 l 、。竺，j l ( i ) 掌生信息寰 关系型数据库 图1 1 对象关系映射 与简单的对象序列化相比，j d b c 是一种复杂的持久对象的技术。通过分解j a v a 对象为关系型数 据，您能对信息执行任意的查询。但是j d b c 需要用户手工建立这种对象关系型数据的映射，所以 东南大学硕士学位论文 开发和维护这样一个数据持久层所花费的代价是很庞大的，与实体b e a n 相比，j d b c 大大增加了开发 的周期和成本。 1 d b c 可以说是j a v a 环境中访问持久层最原始、最直接的方法。是j a v a 中一切数据库操作的基础， 并且获得所有数据库厂商的支持。类似o d b c ，对数据库访问提供底层协议的最基本的包装，然后 形成一套统一的数据访问接口，如数据库连接、s q l 语句句柄、结果集等。这种方式的优点是运行 效率最高，缺点是实现复杂，编码量大开发效率低，大项目难以维护。但无论如何，使用j d b c 来直 接访问持久数据层仍是当今企业级应用开发中使用最广泛的。 e j b 中的实体b e a n 实体b e a n 是e n t e r p r i s e j a v a b e a n ( e j b ) 中的持久数据组件，实体b e a n 代表使用持久化数据的 业务过程，它是处理底层持久性数据的组件模型。实体b e a n 具有如下特征： 一个在内存中的持久数据的j a v a 表现形式。 能够知道如何从一个存储空间中读取它自己并用这些存储的数据组合成它的域。 一个可以在内存中即时被修改的对象并且改变数据的值。 可持久化，所以它可以再次被保存到存储空间中，从而更新了数据库中的数据。 由于实体b e a n 简化了代码开发以及能够快速应用开发，所以实体b e a n 的前景十分吸引人。如 果告诉e 】_ b 容器一些关于b e a n 的信息，则容器管理的持久化能够完成所有的数据访问代码，这就 大大减少了b e a n 的代码长度，在b e a n 中没有j d b c ，从而减少了整个应用的开发时间，这也使得 代码更容易读懂或者维护。 但是，由于实体b e a n 本身的实现机制导制了它在性能上的缺陷，我们首先来看一着实体b e a n 的生存周期及其运行机制( 见图2 ) 。从图中可以看出，容器决定生成和销毁实体b e a n 实例。最初 实体b e a n 实例在实体b e a n 实例池中被集中共享，这时的实体b e a n 实例并没有把数据库中的数据加 载进来。当程序需要使用代表数据库中某条记录的实体b e a n 实例时，容器才对数据库执行s e l e c t 操作，激活某个实体b e a n 实例并把数据加载到这个实例中去；当程序使用完某个实体b e a n 实例后， 容器先对这个实例执行钝化操作，然后再把这个实例所包含的数据写回到数据库中去，即使在使用 这个实体b e a n 实例时只进行了读数据的操作，这是为了使实体b e a n 能够与底层数据库的数据保持 一致。 商业方法 图1 2 实体b e a n 生存周期及运行机制 4 第一章弓l 言 从上面实体b e a n 的生存周期及其运行机制就可以看出，实体b e a n 适用于一次处理数据库的一 个逻辑行，但是在数据库的批量操作中会引发很多额外开销，比如，一个返回1 0 0 行记录的实体b e a n 的查找器方法需要执行1 0 0 次数据库的s e l e c t 操作，导致性能急剧下降。此外，如果程序仅仅只是 对这1 0 0 行记录进行了读操作，但容器还是会对数据库做1 0 0 次写操作，这也会引起性能的下降。 同时，对于持久数据的查询，实体b e a n 采用了e j b 查询语言，而不是大多数程序员都很熟悉 的s o l 语言，这样采用e j b 开发应用的开发组织需要培训自己的开发人员，增加了开发成本。 j d o 前面两种规范由于一些固有的缺点都不是完美的解决方案。j d o 技术的出现似乎使数据持久化 的工作有了一些改观，为了解决数据从业务对象层向数据存储层之间的转换工作，j d o 提供了相应 的开发规范及a p i ，解决了由j a v a 对象直接存储为数据库相应表的底层处理过程。但是j d o 没有好的开 源免费产品，无论是从操作方式上还是其功能上对于j a v a 开发员来说似乎还不够成熟，人们仍停留 在用它来学习的阶段，这种情况有待j d o 的成熟来解决。 对象关系映射工具 除了以上标准的技术外，还有很多开源的或商业化的工具可以实现对象和关系数据库之间的映 射。这些对象关系映射工具可以使用户专注于对象模型的设计而不必关心面向对象和关系数据库之 间的匹配。但是每一种对象关系映射工具都有一套它自己实现的a p i ，没有统一标准，不同产品间 移植性差。这类框架的典型代表有t c 毗j n k ，c o e o b a s e ，c a s t o r 及h i b e r n a t e 自从2 皑纪9 0 年代对象关系 的映射概念出现，十年来该技术在广度和深度上不断发展、成熟。由于使用对象关系的映射可以弥 补对象模型和关系模型间的不匹配，该技术己经逐渐被大家接受。但由于始终缺少一种在成熟性、 性能、移植性、简单性、资源耗用等方面都较好的映射技术，所以在实际应用中还存在很多问题。 通过上面的比较分析，各种持久化技术都有各自的优缺点，对于企业信息系统中的数据持久这 个重要的问题，需要选择良好的持久技术来进行数据存储，数据持久的效率直接影响到应用系统的 运行效率。企业级应用系统对运行效率都有严格的要求。如何快速的开发出运行效率高的数据持久 层应用程序，是当前迫切需要解决的一个问题。 1 4 研究内容和论文的组织结构 1 4 1 论文的相关研究工作 本论文基于j 2 e e 平台和对象一关系映射理论，设计了一个有较高应用价值的一个数据持久模型， 在业务逻辑类与关系数据库之间增加了一个持久层( p e r s i s t e n e e l a y e r ) 。持久层是负责业务逻辑类与 关系数据库之间的通信的一组类；它解决了对象模型与关系数据库之间的不匹配；它使业务逻辑类 与关系数据库具有无关性。在这个持久层中有一个数据字典( x m l 文件) ，在数据字典中存放了对 象与表( 关系数据库中的表) 之间的对应关系；当业务逻辑类的对象需要持久化时，它发出一个消 息给持久层，持久层就从数据字典中读出该类对应的表，生成该类的s q l 代码，从而实现对象的存 取。业务逻辑类层与持久层相互传递的是对象，而持久层与关系数据库相互传递的是记录。这样业 务逻辑类在存取对象时，就能够达到在对象数据库中进行存取一样的效果。该方法使得应用程序开 发者不需要了解关系数据库模式( 甚至不需要知道对象是否保存在关系数据库中) 就能够进行数据 持久。另一方面，当关系数据库模式发生改变时，这种改变并不影响面向对象代码，因为持久层会 通过修改数据字典中的对应关系来自动跟踪这种改动，这样就使得开发人员更加专注于业务流程、 5 东南大学硕士学位论文 面向业务对象等较高层次的应用。本文作者将该模型应用于实际的校园数字化系统中，得到了较好 的开发效率和运行效率。 1 4 2 论文的组织结构 本文的组织结构如下： 第一章介绍了研究的背景和意义以及国内外发展现状，综述了本文的相关研究工作并给出论文 的组织结构。 第二章讨论了本文研究理论基础对象关系理论，包括数据同步问题、对象间关联映射问题、对 象继承关系的映射问题、映射关系的表达和使用问题、数据查询问题。阐明了模型的理论基础。 第三章讨论t j 2 e e 中实现数据持久化的几种方法，以及在第二章所述理论的基础上提出了数据 持久的实现模型。 第四章介绍了数据持久模型实现的核心部分。并对一些实现时可能存在的系统瓶颈进行考量， 给出具体的实现。着重介绍t e n f i t y 和p e r s i s t e n c em a n a g e r 。 第五章对本文进行总结，并根据技术的最新发展提出下一步目标。 1 5 本章小结 本章介绍了当前企业开发的通用环境；关系数据库的普遍应用。面向对象技术在开发技术中拥 有主流地位，提出了如何设计高效的数据访问持久层在企业应用中是一个重要的问题，给出了j 2 e e 中几种持久化的方式，以及国内外的研究现状。结合当今企业的需求，提出了本文研究持久模型及 理论基础。 6 第二章对象一映射关系理论 第二章对象一关系映射理论 使用关系数据库的面向对象系统开发人员通常要花费大量的时间来将对象持久化，这是因为在 两种技术间存在一个基本的阻抗不匹配。对象由数据和行为组成，通常可以继承，而关系数据库包 括表、关系和基本的谓词计算函数，这个函数用以返回想要的值。 2 1 1 为避免对象和关系之间的阻抗不匹配，一种方法是使用一个面向对象的数据。然而，在实际的 应用开发过程中，系统通常需要将对象存入一个关系型数据库，有的因为一个系统需要关系型理论 或关系型数据库的成熟性，有的因为公司策略就是使用关系型数据库而非面向对象数据库。无论是 什么原因，一个将对象存入关系型数据库的系统需要提供一个减少这个阻抗不匹配的设计。 2 1 对象- 关系阻抗不匹配问题( t h eo b j e c t - r e l a t i o n a li m p e d a n c e m i s m a t c h ) 第一章中我们说明了对象关系不匹配理论，要解决对象关系不匹配的问题，可以将问题进行拆 分，使其变成多个可以容易解决的小问题，最终转化成切实可行的步骤。 首先，内存中对象保存数据与关系数据库中的持久数据存在同步问题，也就是说需要一种机制 维护数据的一致性，防止读取了无效数据或者覆写了有效数据。 其次，j a v a 对象之间可以使用引用来表示对象之间的关联关系，如使用数组可以表达一对多的 关系，而在数据库里面则使用外键方式表示表和表之间的关系，因此对象一关系映射还要解决数据 对象之问的关联关系。 第三，对象可以继承( 在j a v a 语言里只能单继承) ，而关系数据库没有继承概念，这是关系对 象阻抗不匹配存在的一个重要原因，需要一种机制在关系数据库里映射互相继承的对象。 第四，需要把对象与表的映射记录下来，运行环境还需要能利用这个记录。 本文将针对以上问题一一描述其在对象一关系映射理论中的解决模式。 2 2 数据同步问题 在对象。关系映射中，一个关键的问题就是如何让各种对象从数据库中读取出来以及保存到数据 库中去，如果加载对象到内存中并且进行了修改，就必须跟踪每个对象实例，并在适当的时候写回 数据库而且随着加载的数据对象越来越多，如何管理这些数据对象将变得非常困难。如果某一属 性对应于数据库表的主键，则不论新建、修改、删除都需要一个妥善的解决方案。 由于要读取对象并有可能修改他们，这就牵扯到数据一致性的问题。如果读取了某些数据记录 并保存在内存的数据对象中，就必须保证读取是独占的，也就是说没有其它进程在读取的同时对这 些对象进行修改。否则，就可能在对象中得到不一致或者无效的数据。 从数据库中存取数据时，记录所修改的内容时至关重要的。否则，那些被改变的数据将不会被 写回到数据库中。同样，还有插入创建的新对象和删除已经移除的对象，也必须被记录。 虽然在每次修改对象模型时可以对数据库进行相应的修改，但这样会产生大量规模很小的数据 库调用，从而影响数据库访问性能。而且这样的设计还要有一个对整个交互过程都开放的事务，如 果存在一个跨越多个业务的事务这样的设计通常是不恰当的。 ， 东南丈学硕士学位论文 为了满足以上的需求，可以使用对象关系映射理论中的工作单元模式来处理。工作单元能够记 录了创建新对象、对象更新，删除对象的变化。一旦这些对数据库有影响的操作开始发生时，就通 知工作单元。 工作单元的关键是对象在提交的时候，它打开一个事务，做所有的并发检查( 使用悲观锬或者 乐观锁) 并向数据库写入所做的更改。于是开发人员不必显式的调用数据库更新方法，这样他们就 不必在应用逻辑中记录所修改的内容或者不必担心引用完整性如何影响他们的操作顺序。 使用调用者注册( c a l l e rr e g i s t r a t i o n ) 的方式( 如图2 1 ) 用户如果改变了某个对象则必须将它 注册到工作单元。任何没有注册的对象提交时都不会引起数据库的变动。这样的设计为内存中的对 象使用带来灵活，即允许人们在内存中改变对象而又不将它写入数据库。 图2 1 调用者注册图 使用对象注册( o b j e c tr e g i s t r a t i o n ) 的方式( 如图2 2 ) ，调用者不再负责注册，这里常用的技巧 是把注册方法设置到对象中。从数据库加载的对象注册为“干净”的，s e t 方法设置属性将会使对象 注册为“脏”的。为了实现这种设计工作对象要么作为参数传递给对象，要么使用s i n g l e t o n 模式放 在公共的地方。 即使使用对象注册方法，开发者也必须牢记在适当的时候调用注册代码，否则同样会造成数据 不同步的问题。 8 第二章对象一映射关系理论 图2 2 对象者注册顺序图 另一种方式是使用工作单元控制器( u n i t o f w o r k c o n t r o l l e r ) ( 如图2 3 ) ，o r a c l e 公司的对象一关 系映射产品t o p l i n k 使用的就是工作单元控制器。在这里，工作单元控制所有的数据库的读操作， 一但对象被读取，就将它注册为干净的对象，工作单元在读操作时产生一个拷贝，在提交时比较当 前对象和拷贝对象，看对象是否发生了变化。虽然这加重了提交过程的调用负担，但是使得只对那 些真正改变了的域进行有选择的更新；也可以避免在对象域内执行注册调用。还有一个折中的方法 是只拷贝改变的对象。但由于这种方式支持有选择的更新，因此当读操作大大超过写操作时，它会 极大的降低拷贝操作的负担。 图2 3 工作单元控制器顺序图 9 东南大学硕士学位论文 工作单元解决的基本问题是记录操作过的各种对象，以便知道内存中的数据和数据库的数据是 否需要同步。把每个改变的对象加上“脏”标志比把对象直接保存到数据库好，可以避免多重数据 库调用。在事务处理完成之后，需要找出所有加了“脏”标志的对象并把它们写入数据库。 工作单元的优点是把所有信息保存在一个地方。一旦使用了工作单元，就不必记录所做的修改。 而且，工作单元还可以作为更复杂情况下的固定处理平台。 2 3 对象之间关联映射问题 对象可以通过对象引用来互相直接访问。要把这些对象保存到一个数据库中，保存这些引用关 系非常重要。然而，这些数据对于特定的运行程序来说是特定的，所以保存的时候不能仅仅保存原 始数据，还要将他们的相互关系保存下来。如果草率的将对象的多值域直接保存，会违反关系数据 库第一范式。【9 1 0 1 1 】 保存引用关系的方法主要有外键映射、关联表映射，依赖映射等几种映射方式。 2 3 1 外键映射( f o r e i g nk e ym a p p i n g ) 外键映射是把对象引用映射到数据库的外键。 每一个对象都包含来自相应数据库表的数据库键。如果两个对象用一个关联关系连在一起，则 这种关联关系可以由数据库中的一个外键来代替。 以图书和作者的关系为例，数据库中有两个表：b o o k 、a u t h o r 。若两表一一对应，当你保存一本 书的相关信息到数据库时，你需要把作者的a u t h o r l d 保存到有关该书的记录中去。 上述是最简单映射的情况。如果表之间有一对多的关系，例如一本书可以有多个作者( 如图2 - 4 ) 。 若仍是使用外键映射的方法解决关联问题，则当a u t h o r 对象发生更改时( 记做a i 状态变化为a 2 状 态) ，则我们可能往b o o k 表中插入a u t h o r 记录，也可能删除a u t h o r 记录。至于到底数据库需要什么 样的改变，则有三种选择( 1 ) 删除和插入；( 2 ) 指针；( 3 ) 区分对象集。 b o o k i k 慢l 一皿i n t 、 书 1 7 巴：。妇 一t i t l e ：v a r e h a r 一“t h o r i d ：i n t i 图2 4 一对多关系的外键映射解决方案 如果是删除和插入，就要删除数据库中b o o k 表中与a l 状态a u t h o r 对象相关联的所有记录，然 后往b o o k 表中插入与a 2 状态a u t h o r 对象所关联的记录。 也可以通过区分对象集来区分。有两种情况：要么通过数据库当前状态，要么通过第一次读取 的数据来区分。通过数据库当前状态来区分则是重新读取数据库的记录生成a u t h o r 对象( 记做a 2 ) ， 然后在b o o k 表中删除所有不在a 2 状态的记录，添加a 2 状态新有的记录。通过第一次读取的数据 来区分，就是说要保存读取的数据，这样做的好处是不需要再次进行数据库读取。 外键映射适用于类间几乎所有关联。最常见的不适用情况是多对多的关联。因为外键是单值的， 1 0 翌三兰翌墨二鳖壁鲞墨里堡 第一范式的限制意味着一个单值域不能保存多个外键。在这种情况下需要使用f 面介绍的关联表映 射。 2 3 2 关联表映射( a s s o c i a t i o nt a b l em a p p i n g ) 把关联保存成一个表，带有指向( 由关联所连接的) 表的外键。 目昏目 图2 ，5 多对多关系的关联表解决方案 对象通过使用集合( j a v a 中的数组、m a p 、s c t 等) 傲域值来表示多个引用，可以很容易的处理多 值域。关系数据库并没有这种特性。它受到约束，必须只有单值域。当你映射一个一对多关联时， 可以使用外键映射来处理这个问题，实际上是为关联关系的单值端使用了一个外键。但一个多对多 的关联就不能这么傲，因为对于多对多的关系，已经没有单值端可以保持外键了。 解决两个襄多对多关联的方案已经在关系数据库上应用多年了：创建一个额外的表来记录这种 关系。然后使用关联表映射来把多值域映射到这个链接表中。这个链接表保存多对多的关联关系， 仅仅包含两个关联表的外键，对于每一对相关联的对象都有一个数据行与之对应。 采用链接表的方式，每次从数据库加载数据就需要两次查询。例如给名为b 0 0 k 的记录添加作者 情况，要分两阶段操作：查询b o o k _ a u t h o r 表获得对应b o o k i d 的所有a u t h o r l d ，然后在a u t h o r 表 中查询相应的a u t h o r 记录。 如果所有信息都已经放入内存，这个设计就会工作的很好。如果没有，则在查询方面的开销会 非常大，因为需要为链接表中的每个a u t h o r i d 进行一次查询。我们可以通过把a u t h o r 表连接到链接 表的方法避免多次访问，一次访问即可返回所有数据。不过这样处理是以映射关系更加复杂为代价 的。 更新链接数据包含许多更新多值域的问题。我们可以通过下面所讲的依赖映射处理链表。 2 3 3 依赖映射( d e p e n d e n tm a p p i n g ) 在实际的应用中，有些对象很自然的在其它相关联的对象的上下文中出现。如图书和作者的例 子，图书对象被加载或保存时，对应的作者信息也一同被加载或保存。如果他们没有被数据库的任 何其它表所关联，那么就可以通过使用b o o k 的映射器来管理a u t h o r ，使得操作b o o k 对象同时操作 关联的a u t h o r 对象。 东南大学硕士学位论文 图2 6 依赖映射 依赖映射的基本思想是在数据库持久化时。数据库中的某个类( 依赖者) 依赖于其它类( 所有 者) 。每个依赖者有且只有一个所有者。 依赖者类并不包含任何数据库映射代码它的映射代码都包含在所有者类中。在大多数情况下， 每次加载一个所有者，同时也会加载那些依赖者。如果依赖者加载耗费很大而且不常用，就可以考 虑使用延迟加载的方法，等到真正需要的时候再加载他们， 一个依赖者也可能是另外一个依赖者的所有者。在这个情况下，第一个依赖者的所有者也负责 第二个依赖者的数据保持。我们可以得到一整个由一个主所有者控制的依赖者层次结构。 除了被依赖的表以外，其它表都不应该拥有依赖者表的外键，除非该对象拥有同一个所有者。 因此，内存对象中只有所有者或者它的依赖者拥有指向依赖者的引用。严格地说，如果只提供引用 但不保存到数据库中，规则可以放松，不过拥有不持久化的对象引用本身可能会引起混淆。 使用依赖映射使得对所有者是否变化进行跟踪的过程变得复杂。任何对依赖者的改变都要在改 变的时候标记所有者，这样所有者就会把变化输出到数据库。让依赖者恒定不变可以大大简化这个 过程，则有任何对依赖者的改变都需要把它移除，然后插入一个新的依赖者。这样简化了数据库映 射。当使用数据映射器时，理论上内存和数据库映射应该是独立的。 2 4 对象之间继承关系的映射问题 上面讨论的情况是内存中的对象均在同一层次。对于复杂的业务逻辑，如果使用了有继承关系 的数据，事情就变得复杂了，因为关系数据库中没有有关继承的概念，s q l 中没有相应的处理方法。 我们必须针对继承关系再建映射以满足不同情况的需要。对于任何继承结构一般有三种处理方案可 以选择；单表继承、具体表缝承、类表继承。下面具体介绍这三种方案； 2 4 1 单表继承( s i n g l et a b l ei n h e r i t a n c e s ) 图2 7 单表继承 关系数据库不支持继承，因此把对象映射到数据库的时候必须考虑如何用关系数据库来表现继 1 2 第二章对象一映射关系理论 承关系。当映射到关系数据库的时候，我们要努力减少连接操作的数量，在多个表中处理继承结构 会使操作的数量迅速上升。单表继承把一个继承结构中所有类的所有属性都映射到一个单表中。每 个类负责把与之相关的数据保存在表的一行中。数据库中其它不相干的列则留空。将类的继承层次 表示为一个单表，表中的各列代表不同类的所有属性，这种映射模式就是单表继承。( 如图2 7 ) 在往内存中加载一个对象时，必须知道实例化哪个类来创建这个对象。为此数据库表中有一个 域来指示应该使用哪个类。它可能是类的名字，也可能是代码域。如果是代码域则需要在内存中进 行翻译，转换为要映射的类。当有新的继承关系加入到继承层次中时这些代码就需要扩展。如果把 类名嵌入到表里，那么就可以直接使用这个类名来实例化。 单表继承的优点是： 在数据库中只需要关注一个表； 获取数据时不必进行连接操作； 任何时候对继承层次进行重构都不需要修改数据库； 单表继承的缺点是： 数据库表的字段不和对象属性一一对应，会造成开发人员的疑惑； 会造成大量的空间浪费，这与关系数据库特性有关； 单表可能会很庞大，进而导致访问效率问题低下； 基于以上的分析，我们可以考虑将若干项是相似的类映射成一张表，使用单表继承的映射模式。 2 4 1 类表继承( c l a s st a b l ei n h e r i t a n c e s ) 圜固 l n m ell c t 。m 口d l 幽 i 竺竺翌竺j 圜 【e 岬l 嘴锄i l s a l a r yj l 。_ 孵谴 a l 蛀o z i d c o m p a r f y n a m e b j x t h d a y d i 量。o u a t 图2 8 类表继承 就一般而言，对象关系不匹配的一个主要原因是关系数据库不支持继承。我们想让数据库结构 能很清楚的映射到对象，并且允许在继承结构的任何地方建立链接。而类表继承通过给继承结构中 的每一个类建表支持这一点。( 一些i b