转载:关系型数据库与面向对象

几乎所有的企业应用都需要持久化数据,没有数据持久化需求的企业应用在现在的市场环境下几乎是不可能出现的。由于关系型数据的普及,通常我们提到数据持久化时,一般指的是将数据持久化到关系型数据库中。关系型数据是一种结构化的数据管理方式,开发者只能通过 SQL 来操作数据库。

  Java 语言天生就是一门面向对象的编程语言,在 Java 的世界中,被处理的内容都被组织成一个一个的对象,对象和对象之间存在着继承、引用关系,这样的关系无法通过简单的方式直接反应到关系型数据库中。因此在关系型数据库与面向对象之间便存在着阻抗失谐(impedance mismatch)。

  我们通过一个简单的例子来说明这种阻抗失谐给企业应用开发者带来的困难。假设在企业应用中存在三个 Java 类:Animal、Fish 和 Dog,其中 Fish、Dog 都是 Animal 的子类。在 Java 世界中,Fish、Dog 都可以被作为 Animal 对象处理。但是如果我们换到关系型数据库中,这三个对象通常都保存在各自对应的表中,假设分别对应 Animal 表、Fish 表和 Dog 表,如果要维护 Animal 和 Fish 的继承关系,我们就需要使用 SQL 的联合查询语句查出 Animal 的所有属性和 Fish 的所有属性,并且使用某种外键进行关联:

1 Select animal.*,fish.* form animal,fish where animal.id = fish.id

  从这个简单的例子中我们就可以看出,一个企业应用开发者需要同时掌握面向对象和关系型数据库的两种思想,而且还必须保证它们之间的映射是正确的,否则无法保证企业应用的正确性,这对于企业应用开发者是个挑战,因此 Java 社区一直在寻求如何将面向对象和关系型数据库思想简单的统一起来的途径,这方面的努力促进了持久化技术的发展。

  发展中的持久化技术

  持久化是企业应用开发的核心需求之一,最近几年以来,它也成为 Java 社区中最热门的话题之一,在 Java 社区努力解决持久化数据管理的过程中,曾经涌现出了非常多的技术方案试图解决这个问题,从最早的序列化,到 JDBC、JDO、ORM、对象数据库、EJB 2.X,然而这些技术都存在着各种各样的局限,影响他们成为最好的选择。下面我们简单的回顾一下 Java 社区中那些曾经试图为持久化数据管理提供完整解决方案的技术。

  序列化

  序列化是最早出现的、管理持久化数据的实现方案,也是 Java 语言中内置的数据持久化解决方案。它的工作原理是将对象转化为字节流,生成的字节流能够通过网络传输或者保存在文件中。序列化非常易于使用,但是局限性也非常大,由于序列化必须一次将所有对象全部取出,这限制了它在处理大量数据情形下的应用,同时它也无法在更新失败的情况下撤销对对象的修改,这使它无法用于对数据一致性要求严格的应用中。多线程或者多个应用不能同时并发地、互不冲突地读写同一个序列化数据,也不能提供查询功能。

  JDBC

  很多企业应用的开发者选择使用 JDBC 管理关系型数据库中的数据。相对序列化而言,JDBC 克服了很多缺点:它支持处理大量的数据,能够保证数据的一致性,支持信息的并发访问,提供 SQL 查询语言查找数据。不幸的是,JDBC 没有提供序列化所具有的易用性。JDBC 所使用的关系模型不是为保存对象而设计的,因此迫使开发者选择在处理持久数据时放弃面向对象编程,或者自己去开发将面向对象特性(比如:类之间的继承)和关系型数据库进行映射的专有解决方案。

  关系对象映射(Object Relational Mapping,ORM)

  ORM 是目前完成对象和关系数据表之间的映射最好的一种技术, 这些 ORM 框架处理对象和关系数据库之间的协调工作,将开发者从这部分工作中解脱出来,集中精力处理对象模型。阻碍 ORM 发展的问题是,现有的每一种 ORM 产品都有自己特有的 API,开发者只能将自己的代码绑定到某一个框架提供商的接口上,这种状况形成了厂商锁定,意味着一旦该框架提供商无法解决系统中出现的严重错误,或者因为其它的原因转而采用其它的框架,将会给开发者的企业应用带来极大的困难,唯一的解决办法是重写所有的持久化代码。

  对象数据库(Object DataBase)

  已经有一些软件公司选择了开发为保存对象而特别设计的对象数据库,而不是选择将对象映射到关系型数据库上。这种解决方案通常比使用对象/关系映射更加易于使用。和 ORM 相同的问题是,对象数据库的访问接口并没有标准化,因此非常容易形成厂商锁定的局面。与此同时,放弃已经成熟的关系数据库而转向未知的对象数据库让非常多的企业决策者犹豫不决。而且目前为对象数据库而设计的分析工具太少,无法满足企业的需求。而且现实情况下,每一个企业基本上都有大量的已有数据保存在关系数据库中,要从关系数据库转向对象数据库对企业而言也需要大量工作。

  EJB 2.X

  EJB 2.X 实体 Bean 是管理持久化数据的组件框架,和 ORM 解决方案一样,EJB 2.X 实体 Bean 提供持久化数据的面向对象视图。和 ORM 解决方案不一样的是,EJB 2.X 实体 Bean 不仅仅局限于数据库,它展示的信息可能来自于 EIS(Enterprise Information System)或者其他持久化设备。EJB 2.X 实体 Bean 最大的局限是规定了太过于严格的标准,这些标准保证了企业应用能够在不同的 EJB 容器之间可以移植,但是也让 EJB2.X 实体 Bean 规范变得非常复杂并难于使用。而且 EJB 2.X 标准在面向对象特性处理方面的支持非常有限,无法支持继承、多态和复杂关系等面向对象的高级特性。EJB 2.X 实体 Bean 只能在重量级的、价格昂贵的 EJB 容器中运行,这对应用 EJB 2.X 实体 Bean 开发企业应用提出了更高的要求,加重了企业的经济压力。

  Java 数据对象(Java Data Object,JDO)

  JDO 是 Java EE 标准中另外一个支持管理持久化数据的规范,JDO 规范使用和 JPA 非常类似的 API,只是通常是通过 JCA 技术集成到应用服务器上。但是 JDO 是针对轻量级容器而设计的,不能够支持容器级别的声明式安全、事务特性,也无法对远程方法调用提供支持。

  EJB 3.0 规范

  2006 年 5 月 2 日,EJB 3.0 规范最终版由 JCP(Java Community Process) 正式公布,标准号为 JSR(Java Specification Request)220。EJB 3.0 规范的发布为企业应用开发者提供了一种全新的、简化的 API。制定这组 API 的目标是让开发变得更加容易,相对于以前版本的 EJB 规范,这组 API 也更加简单。Java Persistence API 是 EJB 3.0 中负责处理持久化数据管理的部分,目标是为开发者处理持久化数据库管理提供标准支持,也成为 Java EE 容器提供商必须遵守的标准。

  EJB 3.0 规范由三部分组成:EJB3.0 Simplified API、EJB 核心规范(EJB Core Contracts and Requirements)和 JPA(Java Persistence API)。

  Simplified API

  Simplified API 部分主要规定了基于 EJB 3.0 标准开发企业应用时所需要遵守的 Bean 类和接口要求、这些 API 的使用方式以及容器支持等多方面的内容。还详细的规定了 EJB3.0 中除 Java Persistence API 部分之外的 EJB 实现所支持的注释(Annotation)。规范中还有专门章节讲解 EJB 3.0 和此前的 EJB 规范如何同时工作,以及如何将此前已经开发好的企业应用移植到 EJB 3.0 容器中。其中的 Persistence 的内容放在了 JPA 规范中。

  EJB 核心规范

  EJB 核心规范中首先描述了 EJB 在企业应用中的角色、EJB 规范的体系结构,确定了支持 EJB 标准的容器应该遵守的准则和要求。随后从多个角度详细的介绍了 EJB 体系中各部分的功能需求和实现要求,包括 Session Bean、消息驱动 Bean(Message-Driven Bean)、事务、安全管理、部署描述符等。其中的 Persistence 的内容放在了 JPA 规范中。由于 EJB 3.0 规范并不排斥之前的 EJB 规范,因此 EJB 2.X 和 EJB 1.X 中的内容也保留在了 EJB 核心规范中。

  Java Persistence API(JPA)

  EJB 2.X 和 EJB 1.X 规范中的实体 Bean(EntityBean)部分都难以使用,使持久化成为 EJB 规范的一个软肋,影响了 EJB 标准发挥更大的作用,自然而然的,JPA 成为了 EJB3.0 规范中被关注最多的部分。JPA 规范部分详细的介绍了 JPA 中实体 Bean 新的定义,并介绍了实体 Bean 支持的注释、全新的查询语言、实体管理接口、容器实现规范等内容。

  JPA 标准中引入了新的实体概念,每一个实体都是一个普通的 Java 类,不需要继承任何其他的接口或者扩展某个指定类,这个 Java 类必须使用 javax.persistence.Entity 进行注释。JPA 标准中还提供了包括 javax.persistence.Table、javax.persistence.Id 等在内的多个注释,用于完成实体和数据库之前的映射。JPA 中引入了新的查询语言 JPQL(Java Persistence Query Language),JPQL 允许开发者采用面向对象的查询语言来查找实体,这些实体持久化在关系型的数据库中,”select a from Animal a where a.name=’a’”是一个 JPQL 的例子。其中的 Animal 是一个 Java 类,而不是关系型数据库中的一个表或者视图。除了简单的查询功能之外,JPQL 中还能够支持 Group、Order 等通常只有 SQL 才能提供的高级功能。JPA 标准中还规定了在 Java EE 环境中和非 Java EE 环境中使用 JPA 时的差异,以及 Java EE 环境中容器的职责等。

时间: 2024-10-28 10:18:25

转载:关系型数据库与面向对象的相关文章

关系型和非关系型数据库的区别--转载

关系型数据库和非关系型数据库 关系数据库和非关系数据库的区别是,关系数据库只有“表”这一种数据结构:而非关系数据库系统还有其他数据结构,对这些数据结构还有其他操作. 随着网络的不断发展,单纯关系数据库面临挑战. 关系与非关系型数据库的特点 1.关系型数据库 关系型数据库,是指采用了关系模型来组织数据的数据库. 简单来说,关系模型指的就是二维表格模型,而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织. 关系模型中常用的概念: 关系:可以理解为一张二维表,每个关系都具有一个关系名,就

[转载]从关系型数据库到非关系型数据库

1. 关系型数据库 关系型数据库,是指采用了关系模型来组织数据的数据库. 关系模型是在1970年由IBM的研究员E.F.Codd博士首先提出的,在之后的几十年中,关系模型的概念得到了充分的发展并逐渐成为主流数据库结构的主流模型. 简单来说,关系模型指的就是二维表格模型,而一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织. 关系模型中常用的概念: 关系:可以理解为一张二维表,每个关系都具有一个关系名,就是通常说的表名 元组:可以理解为二维表中的一行,在数据库中经常被称为记录 属性:可

【转载】关系型数据库设计范式

为了建立冗余较小.结构合理的关系数据库,设计关系数据库时必须遵循一定的规则, 即关系数据库的设计范式. 第一范式(First Normal Form, 1NF) 关系型数据库的第一范式要求: 所有字段都是不可分割的 举例来说,客户数据表中包含客户名和地址,地址由城市和街道组成.应用经常需要分别访问城市或街道字段. 数据表customers(name,city, street)是符合第一范式的,而数据表customers(name,address)则不满足第一范式的要求. 定义一个满足第一范式的数

形象了解关系型数据库三大范式

接下来就对每一级范式进行一下解释,首先是第一范式(1NF).符合1NF的关系(你可以理解为数据表."关系"和"关系模式"的区别,类似于面向对象程序设计中"类"与"对象"的区别."关系"是"关系模式"的一个实例,你可以把"关系"理解为一张带数据的表,而"关系模式"是这张数据表的表结构.1NF的定义为:符合1NF的关系中的每个属性都不可再分.表1所示的

关系型数据库与非关系型数据库

关系型数据库与非关系型数据库 自1970年,埃德加·科德提出关系模型之后,关系数据库便开始出现,经过了40多年的演化,如今的关系型数据库具备了强大的存储.维护.查询数据的能力.但在关系数据库日益强大的时候,人们发现,在这个信息爆炸的"大数据"时代,关系型数据库遇到了性能方面的瓶颈,面对一个表中上亿条的数据,SQL语句在大数据的查询方面效率欠佳.我们应该知道,往往添加了越多的约束的技术,在一定程度上定会拖延其效率. 在1998年,Carlo Strozzi提出NOSQL的概念,指的是他开

关系型数据库学习笔记

关系型数据库 一.关系型数据库管理 1.数据库概述 (1)数据库概念: 所谓数据库,就是在计算机上集中存放数据的地方.将所需数据和信息保存在计算机数据库中,对数据进行集中控制. (2)优点: 降低存储数据的冗余度--减少数据的重复 具有更高的数据一致性--避免出现不一致的数据 存储的数据可以共享--可以随时访问不断更新的公用信息 可以建立数据库所遵循的标准--建立了一个标准,所有存入的数据的名字,都会以相同的格式表示 便于维护数据完整性--保证数据库中数据准确性 能够实现数据的安全性 2.数据库

关系型数据库设计范式

范式: 设计关系数据库时,遵从不同的规范要求,设计出合理的关系型数据库,这些不同的规范要求被称为不同的范式,各种范式呈递次规范,越高的范式数据库冗余越小. 首先要明白”范式(NF)”是什么意思.按照教材中的定义,范式是“符合某一种级别的关系模式的集合,表示一个关系内部各属性之间的联系的合理化程度”.很晦涩吧?实际上你可以把它粗略地理解为一张数据表的表结构所符合的某种设计标准的级别. 就像家里装修买建材,最环保的是E0级,其次是E1级,还有E2级等等.数据库范式也分为1NF,2NF,3NF,BCN

转载-Android数据库高手秘籍(一)——SQLite命令

原文地址: http://blog.csdn.net/guolin_blog/article/details/38461239 Android数据库高手秘籍(一)——SQLite命令 分类: Android数据库高手秘籍2014-09-04 09:10 7310人阅读 评论(42) 收藏 举报 Android数据库SQLite高手秘籍LitePal 转载请注明出处:http://blog.csdn.net/guolin_blog/article/details/38461239 要想熟练地操作任

MongoDB 与传统关系型数据库mysql比较

与关系型数据库相比,MongoDB的优点: 转载自  http://blog.sina.com.cn/s/blog_966e430001019s8v.html①弱一致性(最终一致),更能保证用户的访问速度:举例来说,在传统的关系型数据库中,一个COUNT类型的操作会锁定数据集,这样可以保证得到“当前”情况下的精确值.这在某些情况下,例 如通过ATM查看账户信息的时候很重要,但对于Wordnik来说,数据是不断更新和增长的,这种“精确”的保证几乎没有任何意义,反而会产生很大的延 迟.他们需要的是一