对象关系模型数据库.doc

面向对象数据库系统（Object Oriented Data Base System，简称OODBS）是数据库技术与面向对象程序设计方法相结合的产物。 对于OO数据模型和面向对象数据库系统的研究主要体现在：研究以关系数据库和SQL为基础的扩展关系模型；以面向对象的程序设计语言为基础，研究持久的程序设计语言，支持OO模型；建立新的面向对象数据库系统，支持OO数据模型。 面向对象程序设计方法是一种支持模块化设计和软件重用的实际可行的编程方法。它把程序设计的主要活动集中在建立对象和对象之间的联系（或通信）上，从而完成所需要的计算。一个面向对象的程序就是相互联系（或通信）的对象集合。面向对象程序设计的基本思想是封装和可扩展性。 面向对象数据库系统支持面向对象数据模型（以下简称OO模型）。即面向对象数据库系统是一个持久的、可共享的对象库的存储和管理者；而一个对象库是由一个OO模型所定义的对象的集合体。 一个OO模型是用面向对象观点来描述现实世界实体（对象）的逻辑组织、对象间限制、联系等的模型。一系列面向对象核心概念构成了OO模型的基础。概括起来，OO模型的核心概念有如下一些: （1）对象（Object）与对象标识OID（Object IDentifier） 现实世界的任一实体都被统一地模型化为一个对象，每个对象有一个唯一的标识，称为对象标识（OID）。 （2）封装（Encapsulation） 每一个对象是其状态与行为的封装，其中状态是该对象一系列属性（Attribute）值的集合，而行为是在对象状态上操作的集合，操作也称为方法（Method）。 （3）类（C1ass） 共享同样属性和方法集的所有对象构成了一个对象类（简称类），一个对象是某一类的一个实例（instance）。 （4）类层次（结构） 在一个面向对象数据库模式中，可以定义一个类（如C1）的子类（如C2），类Cl称为类C2的超类（或父类）。子类（如C2）还可以再定义子类（如C3）。这样，面向对象数据库模式的一组类形成一个有限的层次结构，称为类层次。 （5）消息（Message） 由于对象是封装的，对象与外部的通信一般只能通过显式的消息传递，即消息从外部传送给对象，存取和调用对象中的属性和方法，在内部执行所要求的操作，操作的结果仍以消息的形式返回。 OODB语言用于描述面向对象数据库模式，说明并操纵类定义与对象实例。OODB语言主要包括对象定义语言（ODL）和对象操纵语言（OML），对象操纵语言中一个重要子集是对象查询语言（OQL）。OODB语言一般应具备下述功能： （1）类的定义与操纵 面向对象数据库语言可以操纵类，包括定义、生成、存取、修改与撤销类。其中类的定义包括定义类的属性、操作特征、继承性与约束等。 （2）操作/方法的定义 面向对象数据库语言可用于对象操作/方法的定义与实现。在操作实现中，语言的命令可用于操作对象的局部数据结构。对象模型中的封装性允许操作/方法由不同程序设计语言来实现，并且隐藏不同程序设计语言实现的事实。 （3）对象的操纵 面向对象数据库语言可以用于操纵（即生成、存取。修改与删除）实例对象。 目前，还没有像SQL那样的关于面向对象数据库语言的标准，因此不同的OODBMS其具体的数据库语言各不相同。 对象-关系数据库系统就是将关系数据库系统与面向对象数据库系统两方面的特征相结合。 对象-关系数据库系统除了具有原来关系数据库的各种特点外，还应该提供以下特点： （1）扩充数据类型，例如可以定义数组、向量、矩阵、集合等数据类型以及这些数据类型上的操作。 （2）支持复杂对象，即由多种基本数据类型或用户自定义的数据类型构成的对象。 （3）支持继承的概念 （4）提供通用的规则系统，大大增强对象-关系数据库的功能，使之具有主动数据库和知识库的特性。对象数据库 VS 关系数据库我们将对象数据库管理系统（ODBMS）定义为一个集成了数据库能力与面向对象编程语言能力的数据库管理系统（DBMS），ODBMS使数据库对象看起来像是已有的一个或多个程序设计语言中的程序设计语言以象。Rick Cattell，OMG-93委员会主席。ODBMS在多用户客户机/服务器环境中提供了持久性存储器。ODBMS可以处理对象的并行访问，提供锁定和事务保护，保护对象存储器免遭各种类型的威胁，照管像备份和恢复之类传统任务。ODBMS这所以与关系数据库不同，是因为ODBMS存储的是对象，而不是表格。对象的引用通过持久性标识（PID）进行，PID可以独一无二地识别各个对象，可以用来在对象之间建立标记和容器关系。ODBMS还加强了封装，支持继承。ODBMS结合了对象属性和传统的DBMS功能，如锁定、保护、事务处理、查询、版式本、并发和持久性。ODBMS不是利用分离的语言（如SQL）定义、检索和处理数据，而是利用类定义和传统的面向对象的程序语言（通常是C+、SmallTalk和Java语言）构造来定义和访问数据。ODBMS只来过是存储器内语言数据结构的多用户、持久性扩展。换句话说，客户就是C+或是Java程序，服务器就是ODBMS-没有像SQL和RPC这样的可视中间对象。ODBMS将数据库能力直接集成进语言。ODBMS的价值。很显然，最好是以自然的形式存储那些对象，而不是将数据修饰得光光滑滑或撕得七零八落之后放进关系表格中。对于那些数据复杂难以在表格里简单排列的用户来说，ODBMS特别适合。ODBMS曾经长期是学者和OO研究人员极为感兴趣的领域。最早的商品化ODBMS出现在1986年，是Servio公司（现在的GemStone公司）和Ontos公司推出的。后来（九十年代）Object Design（ODI）、Versant、Objectivity、O2 Technology、Poet、Ibex、UniSQL和ADB MATISSE等公司也加入了这个开拓行列。这些ODBMS厂商首先瞄准了那些复杂数据结构和长命期事务处理的应用程序包括计算机辅助设计、CASE和智能办公室等。随着多媒体、群件、公布式对象和万维网技术的出现，ODBMS与那些深奥难懂的特性现在变成了客户机/服务器系统的主流要求。ODBMS技术填补关系数据库最弱的那些空隙复杂数据、版式本和长生命期事务、持久性对象存储、继承和用户定义的数据类型等等。以下是ODBMS厂商开拓的各个特性：n 自由创建新的信息类型n 快速存取n 组合结构的灵活视图n 与面向对象的程序语言紧密集成n 利用多继承支持可定制的信息结构n 支持版本事务、嵌套事务和长生命期事务n 分布式对象储库n 支持复合对象的生命期管理对象狂已经掌握了整个行业。面向对象技术支持者正在宣告，对象关系数据库和ODBMS将成为医治关系技术的所谓弱点的良药。这纯属胡说在数据库上直接地和不加区分地就应用面向对象技术，将再次引入关系数据库花了二十年才克服的那些问题。在用户中间，很少有人会怀疑ODBMS最终将成为RDBMS的后继技术。在诗人William Blake的比喻中，年轻的革命上帝Orc已经开始衰老，变成冷冰冰的暴君Urizen戒律和标准的守护人。我们可以两者兼得。要点是将这两项技术结合起来，而不是相互扔泥块。对二十多处踏踏实实的关系数据库研究的开发熟视无睹，不加以利用，就不太应该了。Date和Pascal都承认目前的SQL数据库实现有缺点；但他们两人都有觉得关系模型本身能够处理ODBMS将解决的那些问题，ODBMS有能力，可以利用嵌套关系、域（或用户定义的数据封装类型）以及一种比SQL更强大的面向集合语言在关系技术世界里近似。这些特性完成这项工作，无需追逐对象指针或操纵低级的专用语言记录结构。没有必要减轻关系理论的联合能力。开发者没有必要退回到用手工方法去最佳化或重新优化应用程序的性能将时钟倒拔回去了。Date认为域和对象是同一回事，解决办法是由关系技术厂商扩展其系统，以包括“适当的域支持”。StoneBraker注意到纯粹的ODBMS还缺乏复杂搜索、查询优化器和服务器可扩展性等领域的功能。而且，许多ODBMS在用户编程的同一个地址空间里运行其产品。这意味着在客户应用程序和ODBMS之间没有任何屏蔽。此外，与关系DBMS相比，ODBMS的市场突破还极小。最后，对象/关系和SQL数据类型扩展器正在RDBMS语言政治协商环境内满足某些对象要求。支持ODBMS的人们觉得，除了仅仅扩展关系模型之外，还有更多的方法。事实上，他们已经拒绝了SQL3，理由是不足（正在达成休战协定）。ODBMS顽固分子认为他们正在为一个新创世界创造更好的管道系统，在这个世界里信息系统完全建产在对象基础之上。在一个由ORB、对象服务、面向对象的程序设计语言和Object Web组成的管道里，关系数据库成了阻碍。所需要的正是一个纯粹的ODBMS。为什么要坚持用BLOB、存储过程和用户定义类型来扩展一个像SQL这样的旧基础呢？他们宁愿自始至终坚持用对象技术，有时从SQL借来某些东西（比如查询）。他们还在创建一个多用户、坚实的基础、包括锁定、事物处理、恢复和各种工具。当然我们这里谈论的是David和Goliath。SQL数据库是目前的山中之王，它们拥有巨额的开发经费，在从MIS商店到客户机/服务器低端市场里有着极好的市场接受度。是不是因为ODBMS能与更好地处理对象，这个山中之王就会被黜？这还有待进一步地观察。不过，正如Esther Dyson表达的，“利用表格存储对象，就象是将汽车开回家，然后拆成零碎件放进车库里，早晨可以再把汽车装配起来。但是人们不禁要问：这是不是泊车的最有效的方法呢对象关系数据库模型对象关系数据库模型，一个很有意思的领域。今天了解一下。呵呵。重要的是一种思想，个人认为。 嵌套关系模型是其中的一种，它的意思是我们的属性可以不是原子的。也就是说这个数据库还不能满足我们的第一范式。它是关系模型的一个扩展，它的域可以为原子的也可以赋值为关系。这样元组在一个属性上的取值可以是关系，于是这样关系可以存在于关系中。这样一个复杂的对象就可以用嵌套关系的一个元组来表示。下面来一个例子说明一下嵌套关系的存在的可能性。 假设每一本书存储下面这些信息：书名，作者，出版商，关键字集合。对于上面的关系，可以存在非元子的有：作者（一本书可能有多个作者，我们通常只是对域元素“作者”的一部分感兴趣），关键字（一本书存储了多个关键字，我们希望能找到在关键字集合中包含某个关键字的所有的书。）。当然我们可以用1NF对它进行表达，但可能会有很大程度上的重复。当然可以通过分解来达到消除这些弊端。主要是其中存在的多值依赖。这时我们可以设计一个无嵌套的复杂的关系视图来免除用户在它们的查询中编写麻烦的连接操作的需要。不过我们可以设计一个复杂的对象作为多值集合的存储对象，这样就可以免除关系数据库的一系列的问题。复杂类型嵌套关系只是对基本关系模型的扩展。面向对象数据库模型已经导致了对于诸如对象的继承和引用之类特征的需求。有了复杂的对象系统和面向对象，我们能够直接表达ER模型的一些概念，如多值属性，实体标识，一般化，特殊化等，而不需要麻烦的转化。集合体和大对象类型属性可以是集合，这样可以直接表达多值属性。集合是集合体类型的一个实例，其它的集合体类型还有数组和多重集合。不过数组是SQL：1999中唯一支持的集合体类型，它还不支持如无序集合和多重集合。对于一些大型的数据类型如一张照片等，当要被存在数据库中时，应该使用新的数据类型：CLOB（新字符型数据大对象数据类型），BLOB（二进制数据大对象数据类型）。其中的LOB代表的是“Large object”。大对象一般用于外部的应用，通过SQL对他们进行检索是没有意义的。一般程序是通过定位器定位到大对象，然后对其进行操作。 结构类型在SQL：1999中可以使用结构申明，如： create type Publisher as (name varchar(20), branch varchar(20) -声明了一个类型为Publisher，它包括两个部分，名字和分支机构。 create type Book as (titile varchar(20), author