(计算机软件与理论专业论文)基于对象关系映射技术的研究与应用.pdf_第1页
(计算机软件与理论专业论文)基于对象关系映射技术的研究与应用.pdf_第2页
(计算机软件与理论专业论文)基于对象关系映射技术的研究与应用.pdf_第3页
(计算机软件与理论专业论文)基于对象关系映射技术的研究与应用.pdf_第4页
(计算机软件与理论专业论文)基于对象关系映射技术的研究与应用.pdf_第5页
已阅读5页,还剩57页未读 继续免费阅读

(计算机软件与理论专业论文)基于对象关系映射技术的研究与应用.pdf.pdf 免费下载

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

基于对象关系映射技术的研究与应用 摘要 基于关系数据库的面向对象软件开发都会涉及对象模型与关系模型之间的 交互,由于面向对象模型和关系模型的阻抗不匹配,当系统中的对象访问关系 数据库时,将需要进行对象与关系的映射。对象关系映射技术将业务层与实际 数据存储分开,实现程序对象到关系数据库的映射,因此能够较好地完成对象 模型与数据模型之间的相互转换。 本文针对o r m 技术展开分析和研究,并将其应用于试验数据集成系统 开发中。论文主要包括以下方面的内容: ( 1 )对o r m 技术和相关理论进行了介绍,深入讨论了o r m 的四种映射模 式,包括实体映射、关联映射、继承关系映射和递归关系映射。 ( 2 )基于对象关系映射理论,讨论了o r m 技术相关的映射工具,着重对 n h i b e r n a t e 在实际中的应用进行了研究,阐述了n h i b e r n a t e 的开发步骤。 ( 3 )针对映射继承关系方法的多样性,运用层次分析法进行建模,解决了系 统中继承关系映射的方法选择决策问题。 ( 4 )对试验数据集成系统软件开发进行了需求分析和系统设计,将对象 关系映射方法较好地应用于该系统中,大大缩短了系统开发周期,降低了开发 人员的工作量,提高了软件质量。 试验数据集成系统现已开发完成,投入企业使用已有半年,至今为止 运行正常,数据访问性能良好,取得了较好的应用效果。 关键词:o r m ,n h i b e r n a t e ,层次分析法,映射模式,数据库 r e s e a r c ha n da p p l i c a t i o nb a s e do no r mt e c h n o l o g y a b s t r a c t i n t e r a c t i v ev i s i tb e t w e e no b j e c tm o d e la n dr e l a t i o n a lm o d e lm u s tb ei n v o l v e d i nt h eo b je c t o r i e n t e ds o f t w a r ed e v e l o p m e n tb a s e do nr e l a t i o n a ld a t a b a s e ,b e c a u s e o f ”i m p e d a n c em i s m a t c h ”b e t w e e no b je c tm o d e la n dr e l a t i o n a lm o d e l ,m a p p i n g o b j e c tm o d e l st or e l a t i o n a lm o d e l ss h o u l db en e e d e dw h e no b j e c tv i s i tr e l a t i o n a l d a t a b a s ei ns y s t e m b ys e p a r a t i n gt h es e r v i c el e v e lf r o mt h ea c t u a ld a t al e v e l , o b j e c tr e l a t i o n a lm a p p i n gi m p l e m e n tm a p p i n gp r o c e d u r eo b j e c t t or e l a t i o n a l d a t a b a s e ,a n dt h e na c c o m p l i s hi n t e r c o n v e r s i o nb e t w e e no b j e c tm o d e la n dd a t a m o d e ls u c c e s s f u l l y t h eo r mt e c h n o l o g yi sa n a l y z e da n dr e s e a r c h e di nt h i st h e s i s ,a n di sa p p l i e d i nt h ed e v e l o p m e n to f “t e s td a t ai n t e g r a t i v es y s t e m ”t h em a i nc o n t e n t sa r ea s f o l l o w s : ( 1 ) t h eo r mt e c h n o l o g y a n dt h ec o r r e l a t i o nt h e o r i e sh a v e b e e ni n t r o d u c e d , i n c l u d i n gf o u rm a p p i n gs c h e m a so fo r m ,s u c ha se n t i t ym a p p i n g ,c o n n e c t i o n m a p p i n g ,i n h e r i t a n c er e l a t i o nm a p p i n ga n dr e c u r s i o nr e l a t i o nm a p p i n g ( 2 ) b a s e do n t h eo b j e c tr e l a t i o n a lm a p p i n gt h e o r y ,w ed i s c u s sr e l a t e do r m t e c h n o l o g yt o o l ,d or e s e a r c h o nn h i b e r n a t ei n p r a c t i c a la p p l i c a t i o n ,a n d e l a b o r a t et h ed e v e l o p m e n ts t e po fn h i b e r n a t e ( 3 ) i nv i e wo ft h em u l t i p l em e t h o d so fm a p p i n gi n h e r i t a n c er e l a t i o n s ,w es o l v e c h o i c ed e c i s i o n m a k i n gq u e s t i o ni ni n h e r i t a n c er e l a t i o n sm a p p i n gb yu s i n gt h e a n a l y t i ch i e r a r c h yp r o c e s si ns y s t e m ( 4 ) r e q u i r e m e n t sa n a l y s i sa n ds y s t e md e s i g no f “t e s td a t ai n t e g r a t i v es y s t e m ” h a v eb e e nc a r r i e do n ,a n do r mt e c h n o l o g yh a sb e e na p p l i e di nt h es y s t e m , w h i c hr e d u c ed e v e l o p m e n tc y c l eo ft h es y s t e m ,r e d u c et h ed e v e l o p e r s w o r k l o a d , a n di m p r o v et h eq u a l i t yo fs o f t w a r e t e s td a t ai n t e g r a t i v es y s t e m h a sb e e nd e v e l o p e ds u c c e s s f u l l ya n dh a sb e e n u s e df o rah a l fy e a r o w e i n gt ot r o u b l e - f r e eo p e r a t i o na n dg o o dd a t aa c c e s s i n g p e r f o r m a n c eu n t i ln o w ,t h es y s t e mm a k eg o o da p p l i c a t i o ne f f e c t k e y w o r d s :o b j e c tr e l a t i o n a lm a p p i n g ,n h i b e r n a t e ,a n a l y t i ch i e r a r c h yp r o c e s s , m a p p i n gs c h e m a ,d a t a b a s e 插图清单 图1 1 三层系统结构一2 图2 1b s 三层模式图5 图2 2 数据表e r 图1 2 图2 3 继承关系1 3 图2 4 递归关系1 5 图3 1n h i b e r n a t e 体系结构图1 8 图3 2n h i b e r n a t e 详细结构图1 9 图3 3 对象的状态转换图2 0 图3 4 层次分析法层次结构2 7 图4 1 系统一级菜单3 1 图4 2 用户管理数据流图31 图4 3 系统结构管理模块数据流图3 2 图4 4 项目管理模块数据流图3 2 图4 5 车辆及配件管理模块数据流图3 3 图4 6 试验管理模块数据流图3 3 图4 7 数据录入模块数据流图3 4 图4 8 用户管理结构设计3 5 图4 9 项目管理结构设计3 6 图4 1 0 层次结构模型图3 9 图4 1 1 添加n h i b e r n a t e 操作4 1 图4 1 2 将类体系映射成一个表4 4 图5 1 登陆界面4 6 图5 2 车辆信息管理4 7 图5 3 配件属性管理4 7 图5 4 配件信息4 8 图5 5 试验信息4 8 图5 6 试验选择4 8 图5 7 试验数据录入4 9 图5 8 试验数据图一4 9 图5 9 故障反馈信息5 0 图5 1 0 项目计划及试验信息维护5 0 i i i 表格清单衣怡清早 表2 1 继承关系映射方法比较1 4 表3 1h q l 查询语句与s q l 语句的比较2 3 表4 1 用户详细信息表3 5 表4 2 发动机试验3 6 表4 3 配件水平属性表3 7 表4 4 配件垂直属性表3 8 表4 5 试验属性测量结果表3 8 表4 6 措施层在模型复杂度准则的评价值4 0 表4 7 措施层在查询性能准则的评价值4 0 表4 8 措施层在可维护性准则的评价值4 0 表4 9 措施层在多态关联准则的评价值4 0 表4 1 0 措施层在符合常规设计准则的评价值4 0 表4 1 1 层次总排序4 0 表4 12 数据库表v e h i c l e 4 1 表4 1 3t b l c a t c g o r y 数据表4 4 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作及取得的研究成果。 据我所知,除了文中特别加以标志和致谢的地方外,论文中不包含其他人已经发表或撰 写过的研究成果,也不包含为获得合肥工业大学 或其他教育机构的学位或证书而使 用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在论文中作了明确的说 明并表示谢意。 学位论文作者签字:i 弓镙签字日期:2 | 鼠学年3 月髟日 学位论文版权使用授权书 本学位论文作者完全了解合肥工业大学有关保留、使用学位论文的规定,有权 保留并向国家有关部门或机构送交论文的复印件和磁盘,允许论文被查阅或借阅。本人 授权合肥工业大学可以将学位论文的全部或部分论文内容编入有关数据库进行检 索,可以采用影印、缩印或扫描等复制手段保存、汇编学位论文。 ( 保密的学位论文在解密后适用本授权书) 学位论文者签名: 两谒、 签字日期:2 卯8 年弓月2 6 日 学位论文作者毕业后去向: 工作单位: 通讯地址: 新躲同嘶 签字日期纩年乡月多日 电话: 邮编: 致谢 转眼研究生生活即将结束,在这里遇到了可敬的老师和可爱的同学们,和 你们的交流使我学到了很多,也留下了许多美好的回忆。 值此论文完成之际,我首先要衷心的感谢我的导师周国祥教授。在我整个 研究生学习期间,周老师在学习和生活上都给予我了无微不至的关怀和帮助。 在论文的开题和撰写过程中,周老师提出了不少宝贵意见,给予了很多的指导。 周老师渊博的知识、严谨的治学态度、敏锐的学术思想和诲人不倦的敬业精神, 都对我产生了潜移默化的影响,始终是我学习的典范! 他在工作上一丝不苟、 治学严谨,是我以后学习和工作的楷模。还要感谢实验室的石雷老师,石老师 在学习上给予了很大的鼓励和指导,他忘我的敬业精神和平易近人的性格令我 铭记在心。 同时还要感谢和我朝夕相处的同学王悦、洪伟、王春艳、常安云、张 令意,他们在我学习上给了我许多帮助和启迪,与他们的讨论使我获益匪浅。 感谢江淮车辆集团产品试验部的全体人员在项目进行期间与我的论文实践期间 给予的大力协助与支持。使我能在短时间内对车辆试验有较深的认识,减少了 我的领域学习时间。 衷心感谢我的父母,他们以无私的奉献和真诚的鼓励支持我顺利完成学业, 谨以此文报答他们二十多年的养育之恩! 感谢母校合肥工业大学的培养和教育,感谢计算机与信息学院的老师们。 最后,感谢在我的人生路上曾经支持、鼓励、帮助过我的人,对此我充满 深深的感激之情,再次谢谢你们! 作者:方璨 2 0 0 8 年3 月 第一章绪论 1 1 课题背景及目的 软件开发过程中不可避免要使用到内存数据的持久化,使各种数据能够长 时间保存并持续使用。就现阶段而言,关系数据库是大多数软件系统数据存储 的首要选择。关系数据库的理论非常完善,并且得到了数十年的实践考验,不 论从性能还是数据完备性的角度,关系数据库都有着无可比拟的优势。另一方 面,面向对象技术目前是新软件系统开发的最常见的环境,面向对象的开发方 法己成为了软件开发的主流。随着软件复杂度和规模的增加和扩大,出于软件 的可重用性和可维护性的考虑,各种面向对象的持久化方法也随之产生。 对象模型是基于软件工程的一些原理,例如抽象,封装,继承和多态,而 关系数据模型则基于数学原理,特别是集合论的原理。两种不同的理论基础导 致各自有不同的优缺点。对象模型侧重于从包含数据和行为的对象中构造应用 程序,而关系模型则主要针对数据的存储构造应用程序。对象模型和关系模型 之间的这种失配叫做阻抗不匹配。使用对象模型,就是通过对象间的关系来访 问对象;而使用关系模型,则通过冗余数据来连接表中的行。基于关系数据库 的面向对象软件项目开发都必定要涉及对象模型与关系模型之间的交互,由于 面向对象模型和关系模型的阻抗不匹配,当系统中的对象存储访问关系数据库 中时,就需要进行对象与关系的映射。对象关系映射( o b j e c tr e l a t i o n a lm a p p i n g , o r m ) 技术是一种对象和关系之间的映射技术,它能够较好的实现对象模型和 数据模型之间的相互转换。o r m 成为涉及数据库面向对象开发中的主流开发模 式。 o r m 能够非常好地满足面向对象的需求。据统计,采用o r m 可将软件开发 时间和成本缩短4 0 ,并且由于很方便地将业务层与实际的数据存储分开,业 务层可以直接获取或存储对象,中间的转换过程就交给o r m 框架处理,因此极 大的提高数据读写性,简化了代码的调优与测试,也可以避免数据库结构或类 中任何一方发生变化时对系统的大幅修改。在开发试验数据集成系统时便 引入了o r m 技术,采用该技术来解决数据层的访问问题。 1 2o r m 应用现状 在引入对象关系映射技术之前,软件开发过程中实现数据访问层( d a t a a c c e s sl a y e r ,d a l ) 的方式主要有两种: 一种是将结构化查询语言( s t r u c t u r eq u e r yl a n g u a g e ,s q l ) 嵌入到业务实现 类中,即在以c + + 等为主语言实现类的代码中,当需要使用数据库时通过一定 的接口将s q l 语句嵌入,编译时与主语言实现代码一起编译。比如早期c + + 中的a c t i v e x 数据对象( a c t i v e xd a t ao b j e c t s ,a d o ) 和早期的o r a c l e 调用接口 ( o r a c l ec a l li n t e r f a c e ,o c i ) 等。这种实现d a l 方法的优点是可以实现快速 编码,且对小型应用和简单原型的开发比较适用。缺点就是会造成应用类与关 系数据库的祸合度很高,这意味着数据库很小的改动( 如属性值的重新命名) 都会造成整个原码的重新编写【l 】,这显然是有悖于o o 方法的封装原则的。 另一种实现d a l 的方法是将对数据库的操作单独封装在一个或多个“数据 类 ( d a t ac l a s s e s ,d c ) 中,业务实现类通过对d c 的调用来实现d a l 的操作。 比如o r a c l e 和s q l s e r v e r 等数据库系统中的存储过程( s t o r ep r o c e d u r e ,s p ) 中, 业务实现类将需要数据存取的与数据库表的属性所对应的参数传入存储过程, 由存储过程实现d a l 的操作。还有采用j d b c 连接的e j b ( e n t e r p r i s ej a v a b e a n ) 中实体类的实现也是采用数据类的方式。这种方式目前仍在一定范围内广泛应 用,它能很好地满足业务类结构不太复杂的简单企业级应用的要求,并且由于 d a t ac l a s s e s 封装了对数据库的操作,也能很好地体现o o 的思想。但与第一种 方式一样,当数据库发生变化时,难免要对d a t ac l a s s e s 进行重新编译。 上述两种方式中,不管是嵌入式s q l 还是d a t ac l a s s e s 中,数据访问代码 都难免有大量的类似与重复,这种在每个项目中都重复且具备相同模式的代码 明显是一种资源与人力的浪费。在这种情况下o r m 技术应运而生,o r m 2 】的 核心思想是引入持久层( p e r s i s t e n tl a y e r ,p l ) 的概念( 如图1 1 所示) ,它在关 系型数据库和对象之间产生一个自动映射,这样在具体的操作数据库操作中就 不需要再与复杂的s q l 语句打交道。 表述层 l 业务逻辑层 1r f 黼刁 表述层 工 业务逻辑层 工 持久层 0 o 、- 一 数据层 图1 1 三层系统结构 目前,存在多种o r m 或类似o r m 的软件设计架构。比如,1 9 9 2 年m i c r o s o f t 和s y b a s e ,d i g i t a l 共同制定了o d b c 标准接口,以单一的o d b ca p i 来存取各种 不同的数据库。随后o d b c 3 】便获得了许多数据库厂商和第三方的支持而逐渐 成为c + + 领域标准的数据存取技术。1 9 9 3 年m i c r o s o f t 使用对象连接与嵌入技术 ( o b j e c tl i n k i n ga n de m b e d d i n g ,o l e ) 封装了存取a c c e s s 数据库的引擎,实现了 数据访问对象( d a t aa c c e s so b j e c t ,d a o ) 4 1 。由于d a o 在结合o d b c 存取关系数 据库时效果并不好,因此在1 9 9 5 年m i c r o s o f t 同样以o l ea u t o m a t i o n 技术直接封 装o d b ca p i ,让程序员能够存取关系数据库,这种数据存取技术便称为远程 数据对象( r e m o t ed a t ao b j e c t ,r d o ) 。d a o 与r d o 相结合的后继产物就是目前 2 仍在广泛使用的a c t i v e x 数据对象( a c t i v e xd a t ao b j e c t ,a d o ) ,后来m i c r o s o f t 将a d o 引入到n e t 框架中成为a d o n e t ,它在原来a d 0 2 0 的基础上提供平台 互用和可收缩的数据访问功能。 从o d b c 到d a o 再到a d o ,特别是在a d o n e t 支持建立实体对象类访问数 据库,并且,一些开源的n e to r m 架构比如将h i b e r n a t e 移植到n e t 5 】平台的 n h i b e r n a t e 和o r m n e t 等都实现了o r m 或类似o r m 的架构。 当然,从j 2 e e 的标准与规范制定及不断完善的发展历程来看,它是从j a v a 领域发展起来的,在基于j a v a 的数据访问方式的发展过程中,在发展初期是 落后于微软的,所以j d b c 、基于j a v a 的d a o 、j d o ( j a v ad a t ao b j e c t ) 都或 多或少地借鉴或继承了o d b c 、d a o 和r d o a d o ,而随着e j b 在j 2 e e 中的 深入应用、s t r u t s s p r i n g 等m v c 软件架构的兴起及h i b e r n a t e 6 】等一系列基于 j a v a 的开源o r m 架构的推出和完善,可以说在j 2 e e 的开发中基于j a v a 的 这些架构是领先的起跑者。 h i b e r n a t e 是一个优秀的开放源代码的j a v a 对象持久层轻量级封装框架, 它既可以用来在j a v a 应用程序中取代大部分j d b c 代码,也可以整合到j 2 e e 系统中作为持久层框架。它可以直接映射大部分的j a v a b e a n 而不需要对它们作 任何修改;可以将一个用户定义的多个类的实例映射到一张表的同一行;还可 以利用代理模式来简化载入类的过程。h i b e r n a t e 不需要任何容器,提供简单易 用并符合o d m g 3 s t y l e 的a p i ,也解决了j d o 的很多缺陷。 n h i b e m a t e 是h i b e r n a t e 的n e t 移植版本,它由c 编写。n h i b e r n a t e 使用 硬编码实体类来定义好类结构,但是只使用一种x m l 文件来描述数据库表结 构和实体类结构的对应关系,以及实体类结构之间的r e l a t i o n s 。n h i b e r n a t e 也 可以支持非常丰富的r e l a t i o n s ,包括o n e t o o n e 、o n e t o - m a n y 、m a n y t o - m a n y 等。n h i b e r n a t e 查询用的是完全面向对象的语言一一一h q l 语言进行查询。 1 3 论文研究内容 论文深入分析研究对象关系映射技术,着重讨论在汽车产品试验数据集成 系统的开发过程中引入o r m 技术实现其数据层的访问,论文主要内容包括以 下几个方面: ( 1 ) 对o r m 技术和相关理论进行介绍,深入讨论o r m 的几种映射模式( 实 体映射、关联映射、继承关系映射和递归关系映射) 。 ( 2 ) 基于对象关系映射理论,讨论了o r m 技术相关的映射工具,着重对 n h i b e r n a t e 在实际中的应用进行了研究,阐述了n h i b e r n a t e 的开发步骤。 ( 3 ) 由于映射继承关系方法的多样性,采用层次分析法建模,解决本系统中 继承关系映射的方法选择决策问题。 ( 4 ) 对试验数据集成系统软件开发进行了相关需求分析和系统设计,并 将o r m 技术较好的应用于系统中。 3 1 4 论文的章节安排 论文共分六部分,内容组织如下: 第一章 绪论。介绍课题的研究背景和研究状况,引出问题。 第二章o r m 技术。本章分析了分层信息系统架构的特点。比较了对象 关系映射技术与面向对象数据库技术的优缺点,给出本课题使用的o r m 技术 的理由;在介绍了o r m 技术的基础上介绍了对象关系映射的映射模式,详细 说明了实体映射、关联映射( 一对一关系,一对多关系,对对多关系) 、继承 关系映射以及递归关系映射。 第三章o r m 应用研究。本章对江淮汽车产品试验数据集成系统中所使 用的o r m 工具n h i b e r n a t e 进行了深入的介绍及分析,并说明了其具体的设计 与实现方法。对于继承关系映射的方法选择,引入了决策分析中的层次分析方 法来解决这个问题。在本章的最后,对层次分析法的建模进行了详细介绍。 第四章o r m 在试验数据集成系统中的应用。本章首先通过分析用户对 系统功能的需求,确定系统要完成的实际功能,接着分模块介绍了系统功能结 构和数据存储设计。另外详细介绍了采用n h i b e r n a t e 工具实现o r m 映射的操 作。最后针对具体问题采用层次分析法建模分析,介绍了o r m 技术的具体应 用。 第五章原型系统。本章详细介绍了汽车产品试验数据集成系统的功能结 构。 第六章总结与展望。总结本论文所完成的工作,并提出在未来可进一步 开展的工作。 4 第二章o r m 技术 2 1 分层信息系统架构 2 1 1 分层的信息系统架构设计方式 分层信息系统架构包括数据层、业务处理层以及应用层,图2 1 展示了这 三个层次之间的关系。在分层系统中,数据层负责信息系统与底层数据库系统 间的数据交换( 如:数据的插入、删除、修改等) ;业务层在数据层的支持下 完成系统中的业务逻辑( 如:查询一张表单所有的数据) ;应用层则调用业务 层提供的功能实现具体的功能。为了满足数据访问的安全性、一致性及系统响 应时间对访问速度的要求,目前分层信息系统主要采用关系型数据库系统软件 实现数据层的存储,业务层与应用层则通过统一的面向对象建模方法设计、实 现。 试验数据集成系统采用基于b s 的三层架构模式【7 1 ,即通过表示层,业务 层和数据层这三个层次来构建整个系统,其结构图如下图所示。 图2 1b s 二层模式图 ( 1 ) 数据访问层:主要是对原始数据( 数据库或者文本文件等存放数据的形式) 的操作层,由业务实体类和数据访问组件组成。业务实体类是经过抽象了的一 些跟具体业务( 如:一次试验,一次测试的具体数据) 直接打交道的类,大到 一个完整的试验项目,小到具体的一个试验结果数据。数据访问组件主要完成 所有业务实体类跟数据库的c r u d ( 即:c r e a t e ,r e t r i e v e ,u p d a t e ,d e l e t e ) 操作,即直接跟数据库打交道的工作【8 1 。 ( 2 ) 业务逻辑层:主要是针对具体的问题的操作,也可以理解成对数据层的操 作,对数据业务逻辑处理,如果说数据层是积木,那逻辑层就是对这些积木的 搭建。可以看成是对一些数据层的操作进行组合。 ( 3 ) 表示层:主要对用户的请求接受,以及数据的返回,为客户端提供应用程 序的访问。它是面向客户的接口,即主要的界面。客户们通过表现层实现的功 能对数据库实现需要的操作,在这一层,所有的数据、业务层是透明的。客户 将不会感觉到这两层的存在。 恰当地为软件分层,将会提高软件的以下特性: 伸缩性:指应用程序能否支持更多的用户; 可维护性:指当发生需求变化时只需修改软件的一部分,不会影响其他部分 的代码; 可扩展性:指在现有系统中增加新功能的难易程度; 可重用性:指程序代码没有冗余,同一个程序能满足多种需求; 可管理性:指的是软件管理的难易程度。 当然,软件分层越多对设计人员的要求就越高,此外,软件层次越多调试 也会越困难。 2 1 2 各层架构设计的特点 通常应用层与业务层的设计过程一般是先将系统的各部分抽象为多个部 件,再设计各部件内部的逻辑实体及关系。如目前流行的u m l 架构建模就采 用了这种思路。 在进行分层信息系统的数据层设计时,通常数据组织的物理实现都由关系 数据库完成。目前,关系型数据库系统( r d b m s ) 已经相当成熟。可是随着应 用复杂程度的提高,关系数据库已经越来越难以满足现实的需要:这主要表现 在它的效率性能、可扩展性、使用的简洁性以及和当今开发技术的适应性【9 】。 表格结构虽然可以支持强大的查询语言( s q l ) ,但由于它不属于面向对象领 域,现实世界的数据很难分解为这种简单的行列结构。 在采用关系型数据库设计信息系统的数据层时,人们主要沿用了实体关系 建模( 即e r 图) 的办法。可是这种建模思想显然跟不上当前快速发展的面向对 象建模技术,特别在信息系统进行整体u m l 建模设计时,常出现应用层,业务 层以及数据层之间的协调问题,甚至在系统已经成功构建后,由于某种原因需 要对系统业务层做出一些改动时,会出现由于数据层与业务层之间的变化太大 而导致整个系统不得不重新设计。这就是所谓“阻抗失谐【l o 】( i m p e d a n c e m i s m a t c h ) 【lj j 问题,于是人们开始寻求新途经来解决数据层设计中的问题。 为了解决这种匹配问题,目前已经提出了多种解决方案,比如c m p 1 2 】、j d o 1 3 】、 o r m 等等。其中o r m 作为目前比较流行的持久化解决方案。 6 2 2o r m 技术介绍 2 2 1o r m 技术 对象关系映射是随着面向对象的软件开发方法发展而产生的。面向对象的 开发方法是当今企业级应用开发环境中的主流开发方法,关系数据库是企业级 应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的 两种表现形式,业务实体在内存中表现为对象,在数据库中表现为关系数据。 内存中的对象之间存在关联和继承关系,而在数据库中,关系数据无法直接表 达多对多关联和继承关系。因此,对象关系映射系统一般以中间件的形式存在, 主要实现程序对象到关系数据库数据的映射。 o r m 的方法论基于三个核心原则: 简单。以最基本的形式建模数据: 传达性。数据库结构被任何人都能理解的语言文档化; 精确性。基于数据模型创建正确标准化了的结构。 对象关系映射【1 4 】实质就是将关系数据( 库) 中的业务数据用对象的形式表 示出来,并通过面向对象( o b j e c t o r i e n t e d ) 的方式将这些对象组织起来,实 现系统业务逻辑的过程。在o r m 过程中最重要的概念是映射( m a p p i n g ) ,通 过这种映射可以使业务对象与数据库分离【l5 1 。从面向对象来说,数据库不应该 和业务逻辑绑定到一起,o r m 则起到这样的分离作用,使数据库层透明,开发 人员真正的面向对象。图1 1 简单说明了o r m 在多层系统架构中的作用。 在使用关系型数据库实现业务数据存储的过程中,常常有一些业务逻辑需 要直接用写s q l 语句实现,但这样开发的结果是:遍地布满s q l 语句。这些 高耦合的s q l 语句给系统的改造和升级带来很多无法预计的障碍。为了提高项 目的灵活性,特别是快速开发,o r m 是一个不错的选择。举个简单的例子:在 使用o r m 的系统中,当数据库模型改变时,不再需要理会逻辑代码和s q l 语 句中涉及到该模型的所有改动,只需要将该模型映射的对象稍作改动,甚至不 做改动就可以满足要求。 o r m 框架涉及的技术主要有: ( 1 ) 透明的持久对象层( t r a n s p a r e n tp e r s i s t e n tl a y e r ) 采用o r m 方法要求在软件设计中首先要分析问题域,找出所有问题域中 相关事物,从中抽象出对象;然后从抽象出的对象中找出所有的持久对象( p o , p e r s i s t e n t0 b j e c t ) ,所谓持久对象就是由数据库管理系统负责管理的,可以永久 保留,将来可被提取的对象,将这些持久对象以“一类一表格 的原则映射到 数据库中,通过数据库管理系统建立表格:然后定义持久对象,所有持久对象 均采用“双构造函数”的方法在程序中进行构造,其中,一个构造函数参数为 所有初始化该持久对象的值,封装数据模块中“存 操作,另一个构造函数的 参数为唯一标识该持久对象的值,封装数据模块中“取”操作。其它数据库操 7 作由持久对象相应方法封装,所有与数据库层发生交互的动作,均放在专门的 数据模块中,由中间层持久对象相应方法封装,做到数据与界面的分离。最后 就是定义其它非持久对象,具体软件功能由相应对象协同实现。 ( 2 ) 客户端应用对象空间与数据库服务器端元组空间的映射 o o 方法涉及到对象空间的概念,所谓对象空间( o b j e c ts p a c e ) 是指所有基于 一定模式的对象的集合,理想的对象空间是相互独立而没有关联的,每个应用 程序可以包括所属对象空间所有对象且相互独立。但在c s 或b s 模式中,真 正的对象空间位于服务器中,如果仍然要求每个应用客户程序独占对象空间就 会造成在一个应用程序访问服务器时与其它应用程序只能互斥进行。通常的解 决办法是每个客户端应用程序所占有的对象空间作为服务器对象空间的副本, 而整个客户端应用对象空间的集合即构成整个或部分的服务器对象空间。 ( 3 ) 引用完整性 在o o 模型中对象可以仅仅看作是类的简单实例,但在规范化的数据库模 式中问题就远没有那么简单。这是因为对象间存在着复杂的关系,这些关系包 括关联,聚集和组成。利用o o 模型可以简单建立的这些关系,在关系数据库 中就需要耗费大量的时间和精力来维护,并带来了极大的复杂性。例如,在对 象模型中简单的多对多关系在关系数据库中就可能需要复杂的外键管理策略。 在j a v a 运行时系统中,只要至少有一个对象引用,j a v a 对象就会存在,这就是 我们熟悉的j a v a 垃圾收集。然而,持久性对象通常是显式的删除。关系数据库 长期以来有自己的机制,避免外键引用不存在的主键。将这2 种观点组合起来 就是o r m 需要解决的问题,通过显式支持关系引用完整性限制,并在需要的 时候执行正确的语句顺序,或者通过支持级联删除选项,可以解决这个问题。 ( 4 ) 唯一性鉴别 o o 模型中的对象都必须有自己的唯一的对象标识符以区别于其他对象。 以j a v a 对象为例,在某个j a v a 虚拟机中的j a v a 对象是通过在某确定时刻该对 象的引用来区别于其他对象。两个对象可以拥有相同的状态,但他们必须具有 不同的对象标识符。同样的,关系数据库中的行之间必须可以相互区分,而这 种区分是通过每个数据库表中的行必须具有的唯一不重复且不为空的主键来进 行的。我们面临的问题是如何在关系数据库中表示对象的唯一性,即如何在数 据库表的主键与对象标识符之间建立映射。 在实际应用程序中,一般不要用任何与业务相关的对象属性作为数据库中 的主键,因为这样只会带来麻烦。主键值应该是一个对象独一无二、不可变更 的身份标识,而那些业务相关的身份标志都是可能变更的,只是目前的业务或 许不允许它变更而已。比如,如果一个居民登记系统用身份证号码作为主键, 当身份证号码从1 5 位升级到1 8 位时,将会带来很大的麻烦。所以,当要实现 对象关系映射时,应该使用代理主键,即没有业务含义的主键。代理主键更加 容易处理,并且可以产生更好的性能,以及不受业务规则变化的影响。 主键的生成是我们面临的另一个问题,用于主键生成的策略通常有如下两 种: 在程序语言中生成一个唯一的i d 在这种方法中,代理主键的生成完全是在数据库外部进行的。可以使用这 样一个算法:它保证每当一个键生成时,这个键都是唯一的。这样的算法通常 都基于一个随机数、系统时间和服务器的i p 地址的一种组合。在程序语言中生 成一个唯一i d 由于与数据库无关所以是快速和可移植的。但是,它有一些缺 点: ( a ) 它生成很长的键,无论该表将保存多少行; ( b ) 键是字符串,不是数,因而可能会使数据库中的索引变得复杂; ( c ) 键不是顺序的。这种方法忽略了数据库的能力,并硬要在程序语言能力 弱的地方使用它,是复杂、低效率的方法。 使用一个生成主键的存储过程或其他数据库特有手段生成唯一i d 在这种方法中,代理主键的生成通过自增列或其他数据库特有方法来解决。 由于主键的创建是一个根本的数据库问题,所以每个数据库都提供了一种在多 个用户创建行时最大限度地减少争用的快速方法。这种方法充分利用了数据库 的能力,从而消除了程序语言中生成唯一i d 所固有的缺点,是简单、高效、 低消耗的方法。它的缺点是:由于利用了数据库特有手段而不具有好的可移植 性。但是可以通过在软件应用中精心的设计来提供在不同数据库间的移植性。 2 2 2o r m 优缺点 ( 1 ) 使用o r m 带来以下几点好处【1 6 】 提高系统性能,通过c a c h e 的实现,能够对性能进行调优,实现了o r m 区隔了实际数据存储层和业务逻辑层之间的关系,能够对每一层进行单独跟踪, 增加了性能优化的可能。 使业务层能够以面向对象的方式操纵数据,可以直接处理业务对象。这 样,业务层中的代码编写不用操心s q l 语句以及底层存储方式,极大地简化了 代码,提高了开发效率,对于日后的维护以及扩展都带来极大的便利。 隔离数据源,可以很方便地转换数据库由于o r m 将业务层与数据库层 分开,程序员不用关心实际存储的方式,如果我们需要把后台数据库由s q l s e i v e i 数据库换为o r a c l e 数据库,按照传统方式需要做大规模的修改,而使 用o r m 则只需要修改相应的配置文件而不需要修改程序。 ( 2 ) 使用o r m 需要注意的为问题 屏蔽了底层使得我们无法针对具体数据源做优化。关系数据库有着三十 年的发展经验,其对数据源的优化远不是o r m 能够相比的,因此,o r m 简化 了数据库访问的同时,使得我们不能像优化s q l 一样来优化o r m ,这样在性 9 能方面会受到影响,尤其是在应用规模逐渐膨胀的情况下。 缓存策略存在缺陷条件查询的时候,如果查询关键字已经存在于缓存, 那么不需要再查询数据库。但是,如果有任何一条记录发生变化,那么缓存中 所有和该表相关的查询关键字都会失效。 2 2 3 系统的建模步骤 由于o r m 能够在解决“阻抗失谐 的同时又能兼顾到r d b m s 的优点, 本系统采用o r m 的设计思想。其操作步骤如下: ( 1 ) 子系统划分:根据需求分析以及决策支持系统n 库结构设计思想,确 定出本系统所包含的几个主要的子系统,这些子系统用包( p a c k a g e ) 来表示; 并为各子系统的命名空间确定名称。 ( 2 ) 子系统结构设计:分别划分各子系统命名空间中的应用层、业务层以 及数据层,并采用面向对象的建模方式设计出各层对象间的关系。 ( 3 ) 数据库映射:根据第( 2 ) 步中对数据层对象的设计,最终把这些对 象向数据库映射,最终生成关系数据库中的关系,整个过程采用o r m 工具实 现。 2 3o r m 的映射模式 对象和关系数据库之间的映射是用一个x m l 文档( x m ld o c u m e n t ) 来定义 的。这个映射文档被设计为易读的,并且可以手工修改。映射语言是以n e t 为 中心的,意味着映射是按照持久化类的定义来创建,而非表的定义。所有的x m l 映射都需要使用n h i b e r n a t e m a p p i n g - 2 0s c h e m a 。 h i b e r n a t e m a p p i n g 这个元素包括四个可选的属性。s c h e m a 属性,指明了这 个映射所引用的

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论