浅谈ORM对象关系数据库映射

ORM提供了概念性的、易于理解的模型化数据的方法
服务器君一共花费了286.464 ms进行了6次数据库查询,努力地为您提供了这个页面。
试试阅读模式?希望听取您的建议

ORM(Object/Relation Mapping) 即对象-关系数据库映射。

对象关系映射(ORM)提供了概念性的、易于理解的模型化数据的方法。ORM方法论基于三个核心原则:

  • 简单:以最基本的形式建模数据。
  • 传达性:数据库结构被任何人都能理解的语言文档化。
  • 精确性:基于数据模型创建正确标准化了的结构。

典型地,建模者通过收集来自那些熟悉应用程序但不熟练的数据建模者的人的信息开发信息模型。建模者必须能够用非技术企业专家可以理解的术语在概念层次上与数据结构进行通讯。建模者也必须能以简单的单元分析信息,对样本数据进行处理。ORM专门被设计为改进这种联系。

规则表达式

ORM把应用程序世界表示为具有角色(关系中的部分)的一组对象(实体或值)。ORM有时也称为基于事实的建模,因为它把相关数据描述为基本事实。这些事实如果分割为再小的事实就会丢失信息。

简单事实的一些例子包括:

  • 人有电话
  • 人住在某个地方
  • 人生于某个日期
  • 人在某个日期被雇佣

ORM提供的不只是描述不同对象间关系的一个简单而直接的方式。ORM还提供了灵活性。使用ORM创建的模型比使用其它方法创建的模型更有能力适应系统的变化。另外,ORM允许非技术企业专家按样本数据谈论模型,因此他们可以使用真实世界的数据验证模型。因为ORM允许重用对象,数据模型能自动映射到正确标准化的数据库结构。

ORM模型的简单性简化了数据库查询过程。使用ORM查询工具,用户可以访问期望数据,而不必理解数据库的底层结构。

对象关系映射是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术。 简单的说,ORM是通过使用描述对象和数据库之间映射的元数据,将java程序中的对象自动持久化到关系数据库中。本质上就是将数据从一种形式转换到另外一种形式。 这也同时暗示者额外的执行开销;然而,如果ORM作为一种中间件实现,则会有很多机会做优化,而这些在手写的持久层并不存在。 更重要的是用于控制转换的元数据需要提供和管理;但是同样,这些花费要比维护手写的方案要少;而且就算是遵守ODMG规范的对象数据库依然需要类级别的元数据。

对象-关系映射是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法,关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式,业务实体在内存中表现为对象,在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系,而在数据库中,关系数据无法直接表达多对多关联和继承关系。因此,对象-关系映射(ORM)系统一般以中间件的形式存在,主要实现程序对象到关系数据库数据的映射。

面向对象是从软件工程基本原则(如耦合、聚合、封装)的基础上发展起来的,而关系数据库则是从数学理论发展而来的,两套理论存在显著的区别。为了解决这个不匹配的现象,对象关系映射技术应运而生。

让我们从O/R开始。字母O起源于"对象"(Object),而R则来自于"关系"(Relational)。几乎所有的程序里面,都存在对象和关系数据库。在业务逻辑层和用户界面层中,我们是面向对象的。当对象信息发生变化的时候,我们需要把对象的信息保存在关系数据库中。

当你开发一个应用程序的时候(不使用O/R Mapping),你可能会写不少数据访问层的代码,用来从数据库保存,删除,读取对象信息,等等。你在DAL中写了很多的方法来读取对象数据,改变状态对象等等任务。而这些代码写起来总是重复的。

如果打开你最近的程序,看看DAL代码,你肯定会看到很多近似的通用的模式。我们以保存对象的方法为例,你传入一个对象,为SqlCommand对象添加SqlParameter,把所有属性和对象对应,设置SqlCommand的CommandText属性为存储过程,然后运行SqlCommand。对于每个对象都要重复的写这些代码。

除此之外,还有更好的办法吗?有,引入一个O/R Mapping。实质上,一个O/R Mapping会为你生成DAL。与其自己写DAL代码,不如用O/R Mapping。你用O/R Mapping保存,删除,读取对象,O/R Mapping负责生成SQL,你只需要关心对象就好。

对象关系映射成功运用在不同的面向对象持久层产品中,如:Torque,OJB,Hibernate,TopLink,Castor JDO, TJDO 等。

一般的ORM包括以下四部分:

  • 一个对持久类对象进行CRUD操作的API;
  • 一个语言或API用来规定与类和类属性相关的查询;
  • 一个规定mapping metadata的工具;
  • 一种技术可以让ORM的实现同事务对象一起进行dirty checking, lazy association fetching以及其他的优化操作。

目前流行的 ORM 产品

目前众多厂商和开源社区都提供了持久层框架的实现,常见的有:

  • Apache OJB (http://db.apache.org/ojb/)
  • Cayenne (http://objectstyle.org/cayenne/)
  • Jaxor (http://jaxor.sourceforge.net)
  • Hibernate (http://www.hibernate.org)
  • iBatis (http://www.ibatis.com)
  • jRelationalFramework (http://ijf.sourceforge.net)
  • mirage (http://itor.cq2.org/en/oss/mirage/toon)
  • SMYLE (http://www.drjava.de/smyle)
  • TopLink (http://otn.oracle.com/products/ias/toplink/index.html)

其中 TopLink 是 Oracle 的商业产品,其他均为开源项目。

其中 Hibernate 的轻量级 ORM 模型逐步确立了在 Java ORM 架构中领导地位,甚至取代复杂而又繁琐的 EJB 模型而成为事实上的 Java ORM 工业标准。而且其中的许多设计均被 J2EE 标准组织吸纳而成为最新 EJB 3.0 规范的标准,这也是开源项目影响工业领域标准的有力见证。

对象-关系映射模式

从《公共仓库元模型:开发指南》一书第8章CWM元仓库中摘录出来的内容,实现了公共仓库元模型(CWM)的UML图到Microsoft SQL Server数据库的映射,是一种将对象层次结构映射成关系型结构的方法。个人认为可以作为将本体(Ontology)文件存储到关系型数据库中的一种可借鉴方法。

基本情况:公共仓库元模型(CWM)是对象管理组织(OMG)的一种和数据仓库相关的元模型标准,采用UML表示的对象层次结构,在保存到数据库中时由于面向对象的数据库技术的不完善(理论研究和商业应用都不是主流),所以该书的作者倾向于使用成熟的关系型数据库来保存-这也是存储本体时所遇到的问题。

采用方法:将UML模型中的各种元素通过转换,保存为数据库模式。由于CWM是一种元模型,因此模型的实例也是一种模型,将这种实例以数据库数据的形式保存。使用数据库中比较成熟的存储过程技术提高开发和执行效率。

数据类型映射模式

  • 简单数据类型模式:建立UML和关系型数据库中简单数据类型的映射表以指导映射。
  • 枚举数据类型模式:每种枚举类型对应一个表,只有一个列(_EnumLiteral)表示枚举值。
  • 基于类的数据类型模式:使用外键约束,将基础列与基于类的类型实例相关联。

类映射模型

每个类对应一个表。单值属性、多值属性、继承关系可以用下述方法映射,而引用属性将在关联映射模式中提到。

  • 单值属性模式:是cardinality的上界为1的属性,映射到类所对应的表的列上。若其下界也为1(必须有的属性),列属性为NOT NULL。
  • 多值属性模式:每个多值属性映射成一个独立的表,使用外键连接到类所对应的表上。
  • 继承模式:每加入一个类的实例时,根据其继承关系自顶向下生成每个类的对象,这些对象具有相同的ID(根对象对应记录的主键)。删除对象实例时,自底向上删除数据。遇到从中间删的情况怎么办?多重继承怎么处理?

关联映射模式

  • 一对一关联模式:在关联两端各加一列。
  • 一对多关联模式:和3.1一样。如果多这端是有序的,还需加入一列表示序号。
  • 多对多关联模式:将关联单独作一个表。
  • 组合关联模式:注意级联式删除。
  • 反演关联模式:关联两端指向相关的类型,和普通关联一样。
  • 成对关联模式:关联记录两个类间的关系,用交集类表示关联,表示成一个单独的表,每个关联对应一个表,用外键表示它们间的关系。
  • 关联上的OCL需要分析成对应的存储过程代码。
  • 保证关联的cardinality也需要分析成对应的存储过程代码。

本文地址:http://www.nowamagic.net/librarys/veda/detail/677,欢迎访问原出处。

不打个分吗?

转载随意,但请带上本文地址:

http://www.nowamagic.net/librarys/veda/detail/677

如果你认为这篇文章值得更多人阅读,欢迎使用下面的分享功能。
小提示:您可以按快捷键 Ctrl + D,或点此 加入收藏

大家都在看

阅读一百本计算机著作吧,少年

很多人觉得自己技术进步很慢,学习效率低,我觉得一个重要原因是看的书少了。多少是多呢?起码得看3、4、5、6米吧。给个具体的数量,那就100本书吧。很多人知识结构不好而且不系统,因为在特定领域有一个足够量的知识量+足够良好的知识结构,系统化以后就足以应对大量未曾遇到过的问题。

奉劝自学者:构建特定领域的知识结构体系的路径中再也没有比学习该专业的专业课程更好的了。如果我的知识结构体系足以囊括面试官的大部分甚至吞并他的知识结构体系的话,读到他言语中的一个词我们就已经知道他要表达什么,我们可以让他坐“上位”毕竟他是面试官,但是在知识结构体系以及心理上我们就居高临下。

所以,阅读一百本计算机著作吧,少年!

《重构:改善既有代码的设计》 福勒(Martin Fowler) (作者), 熊节 (译者)

《重构:改善既有代码的设计》清晰地揭示了重构的过程,解释了重构的原理和最佳实践方式,并给出了何时以及何地应该开始挖掘代码以求改善。书中给出了70多个可行的重构,每个重构都介绍了一种经过验证的代码变换手法的动机和技术。《重构:改善既有代码的设计》提出的重构准则将帮助你一次一小步地修改你的代码,从而减少了开发过程中的风险。

更多计算机宝库...