这些天用kant studio 建模工具做了一个网站的模型，当我要做数据库的时候，发现好难将sql 2005 中的表与uml中的类对应起来，通过冥思苦想，然后再上网搜索，得到了一些启示，能够将数据库建立为对象数据库最好，若希望继续使用关系数据库，那么，需要做如下转换，下面是我上网找到的一篇帖子，作者做了一些比较和转换的方法……
关系持久性建模面向对象是伟大的技术。关系数据库是伟大的技术。如果这两种技术相互隔绝，那将是人类生活的一次灾难，更是我们的巨大悲哀。幸运的是，这种假设没有成为现实。上述两种伟大的技术得到了人们的重视，同样应该受到重视的还有如何将它们调和在一起。
并不是世界上所有的东西都能够轻而易举地结合起来。关系数据库和面向对象就是这样。可是造物弄人，偏偏是这样背景不同特性迥异的两个东西却有着一个无法抗拒的理由把它们联系到一块。同时使用关系数据库和面向对象技术可以使我们编写出能够管理大量数据的复杂的应用程序。正是基于此，才使我们有如此大的冲动，想要认真探究一下关系数据库与面向对象之间究竟有哪些异同。
首先让我们来了解一下关系数据库系统所具有地特点∶
数据以二维表格形式表达；
表中数据之间的关系以存储在表中的值来表达；
使用SQL，可以动态地创建数据之间的关系；
具体的某些数据实体之间的关系在数据库最初设计时，不一定要定义或可观察。
在来看一下面向对象系统地特点∶
应用程序由一组对象组成，对象当然包括属性和操作；
对象是由开发者定义的数据类型；
对象之间可能具有很复杂的关系，如继承、关联、聚合和组合；
类，准确地说是数据类型，之间的关系不容易修改，也不容易在系统建成之后动态创建；
持久对象应该可以存储到外存储器上。
基于他们各自的这些特点，关系数据库和面向对象之间存在以下不同∶
类型系统不同；
语言不同；
范例不同；
基本数据实体不同。
不同的类型系统
关系数据库类型系统比较简单。关系数据库数据类型用来定义数据库表中的字段。存储在字段里的数据必须符合该列的类型。每一行每一列的数据类型必须是原子的。对象模型则比较复杂。每个对象都可以包含众多属性和操作。所以对象显然不是原子性的。我们根本无法在表中存储对象。对象的特性是封装、继承和多态性。而关系数据库里谈这些都是废话。
不同的语言
关系数据库里我们使用SQL完成所有的事情。但是SQL没有处理对象的能力，不可能支持封装、继承、多态。SQL最基本的目的就是存取数据库表里面的数据，这是它唯一能做的。而面向对象的语言则可爱得多。支持封装、继承、多态。我们可以随心所欲创建复杂的数据类型。但是当我们必须把大量持久对象写在硬盘上并且时不时进行查询时就会发现，这些语言在这方面的能力实在蹩脚。SQL可以存储并查询大量数据，但没有对象处理能力。面向对象语言能够处理复杂的对象，但对象持久化方面的能力非常弱。
不同的范例
使用关系模型必须让数据适应模型，而面向对象则需要尽力使模型适应真实世界。
不同的基本数据实体
对象模型到关系模型的映射，是类到关系表之间的映射。类对应着表，对象对应着记录，属性对应字段。困难在于，面向对象语言的基本数据实体是类，而关系模型的基本数据实体是字段。
以上的四点不同最终导致了我们在设计阶段的困难。对于我们这些笃信面向对象的家伙来说，灾难往往发生在设计阶段接近尾声，编码工作即将来临之际。当我们费尽九牛二虎之力，在用况图上画出一堆又一堆达芬其的鸡蛋，完成了充满律动的顺序图，制作了严肃规整的类图并且在上面布满各式各样的小箭头之后，突然发现，我们真正需要的是一个能够方便存储大量数据的关系数据库，借助它才是把那些活跃的小对象们安顿到硬盘上的最好方式。但是我们如何才能得到这个急需的关系数据库呢？难道我们就应该回到最初的需求文档，按照传统的方式，从头再来一遍吗？当然不是。这并非是单纯的怕麻烦，更重要的是，我们需要进行持久化的是对象，而不是传统意义上的"数据"，毕竟我们要打造的系统是一个面向对象的系统。按照传统方法绘制E-R图未必能够设计出真正符合系统需要的数据库。既然如此，我们就完全有理由按照面向对象的思路继续走下去。此时的我们真正需要做的是绘制一个持久模型，借助它我们完全可以把对象映射到关系数据库。
要把对象映射到关系数据库其实很简单，我们只需要一些基本的技巧，简单的说，有如下几项∶
把属性映射到列；
把类映射到表；
在关系数据库中"实现继承"；
映射关联、聚合和组合。
把属性映射到列
类的一个属性可以映射到一列，也可能需要映射到多个列，当然也可能需要把多个属性映射到表的一列。但是通常都只需要把一个属性映射到一个列。另外，并非所有的属性都需要持久化。比如，有一些属性完全可以当成计算列来处理。
把类映射到表
把类映射到表。这句话看起来比较容易理解，但是却容易让人产生误解。有些人可能会误以为一个类就应该映射到一张表。但是这并不总是正确的。实际上这种一一对应并不是总那么灵验。有些时候一个类也需要映射成多个表，而另一些时候多个类却也可以映射成一张表。这需要一些经验，需要具体问题具体分析。
在关系数据库中"实现继承"
这当然是不可能的。前面已经反复提到过，关系数据库不可能支持继承。这个问题的本质是，当把类映射到表的时候，如何解决那些存在泛化关系的类。我们有三个方法应对这种问题，都不复杂。三种方法各有忧略，没有哪一种是十全十美的。我们不妨通过实例来理解这些方法。
首先，我们看到这样一张类图：
图1：三个要映射到关系模型的类
人类显然是一个抽象类，类名是斜体字。它有两个子类，学生和教授。学生类只有一个属性，成绩。同样教授类也只有一个属性，工资。我们忽略掉方法，因为和我们要讨论的问题无关。我们要把这样一个类层次映射到关系数据库有三种方法可以选择。
方法一：对整个类层次使用一个数据实体
说得明白点就是把三个类影射到同一张数据表里面去，三个类的所有属性都映射成同一张表里的列。就像图二这样。
图2：对整个类层次使用同一个数据实体（这不是类图，尽管看起来很像）
这个方法很简单。这个表用起来也很方便。但是，我不说大家也知道。简单的东西往往都有一些小缺憾。浪费空间是显而易见的，即使我们只有三个类。但是设想一下如果我们有五个十个甚至更多的类，它们之间存在继承关系，的时候，这样作会怎么样。那样对空间的浪费真的是可怕的。另外，如果某一个类增加了一个属性，那么表就要增加一个属性，这样实际上影响了三个类的对象。如果增加单个属性时发生了错误，会影响整个层次中的所有类。这种错误一旦在程序运行过程中发作，你可能根本摸不到头脑，它们真的非常隐蔽，令人难以察觉。
方法二：每个具体类都使用一个数据体
每个具体类都会被映射到一张表。所谓具体类，在本例中，是指"学生"和"教授"类，当然不包括抽象类"人"。每个表代表着一个类，它包含那个类的所有必须的属性，更重要的是它包含了那个类的继承属性。如图3所示。
图3：每个具体类都使用一个数据体（这不是类图，尽管看起来很像）
这种方法同样有一个显著的缺点，如果需要修改一个类，那就必须修改它的表和所有子表。另外，如果有一个人即是学生又是教授的时候就比较麻烦了。这样需要在两个表里面分别存储同一个人的记录。而且这个人会有一个学生编号和一个教授编号。有一些时候，可能这是无法容忍的。
方法三：每个类使用一个数据实体
为每一个类创建一张表。子类的表的主键同时作为外键。如下图：
图4：每个类使用一个数据实体（这不是类图，尽管看起来很像）
我最喜欢这种方式，因为这样最符合面向对象的概念。某一个类发生变化时，也很容易修改相应的表。但是，缺点是数据库里面会有很多表。读写数据的效率可能会有一些慢。另外，采用这种方法还要注意灵活使用视图。正如前面所说的那样，没有任何一个方法是十全十美的。究竟选择哪种方法，需要在实践过程中具体问题具体分析，择其善者而从之。
映射关联、聚合和组合
仅仅把类映射到表，属性映射到列，这样显然是不够的。与此同时还必须把类之间的关系映射到关系数据库里面。类之间的关系无非就是继承、关联、聚合、组合。继承刚才已经单独讨论，现在就来看关联、聚合和组合是如何映射到关系模型中去的。
使用外键在关系数据库实现类之间关联
可以使用外键在关系数据库中实现关联。比如，存在这样一种关联关系，"一个雇员工作在一个岗位上"。类图显然应该如下图所示：
图5：一个雇员工作在一个岗位上
在关系数据库里，可以在雇员表上添加一个外键，像下图这样。
图6：在雇员表上添加一个外键（不是类图，尽管看起来很像）
通过关联表在关系数据库实现类之间的多对多关联
假设存在这样一种常见的关联，"一个骑士可以骑多匹马，每匹马也可以由多名骑士来骑"。类图如下：
图7：一个骑士可以骑多匹马，每匹马也可以由多名骑士来骑
在关系数据库上加一个关联表来表示两个类之间多对多的关联关系。
图8：使用关联表表示类之间多对多关联关系
使用以上介绍的技巧，完全可以把持久对象有效映射到关系数据库里面。根据我自己的尝试，这的确是一个有效的方法。如果大家感兴趣不妨在实践中尝试一下。
全面分析:对象数据库系统VS 关系数据库--转自csdn
2006.12.15 [收藏到我的网摘]
对象-关系数据库系统就是将关系数据库系统与面向对象数据库系统两方面的特征相结合。对象数据库 VS 关系数据库我们将对象数据库管理系统（ODBMS）定义为一个集成了数据库能力与面向对象编程语言能力的数据库管理系统
面向对象数据库系统（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表达的，"利用表格存储对象，就象是将汽车开回家，然后拆成零碎件放进车库里，早晨可以再把汽车装配起来。但是人们不禁要问：这是不是泊车的最有效的方法呢"
面向对象的关系数据库设计 |
| 作者：不祥 来源不祥 http://www.csai.cn 2004年12月20日 |
| 一、概念的区分 有些人把面向对象的数据库设计(即数据库模式)思想与面向对象数据库管理系统(OODBMS) 理论混为一谈。其实前者是数据库用户定义数据库模式的思路,后者是数据库管理程序的思路。用户使用面向对象方法学可以定义任何一种DBMS数据库,即网络型、层次型、关系型、面向对象型均可,甚至文件系统设计也照样可以遵循面向对象的思路。 面向对象的思路或称规范可以用于系统分析、系统设计、程序设计,也可以用于数据结构设计、数据库设计。OOSE自上至下、自始至终地贯彻面向对象思路,是一个一气呵成的统一体。面向对象的数据库设计只是 OOSE 的一个环节。 二、数据库设计的重要性 一般数据库设计方法有两种,即属性主导型和实体主导型。属性主导型从归纳数据库应用的属性出发,在归并属性集合(实体)时维持属性间的函数依赖关系。实体主导型则先从寻找对数据库应用有意义的实体入手,然后通过定义属性来定义实体。一般现实世界的实体数在属性数 1/10 以下时,宜使用实体主导型设计方法。面向对象的数据库设计是从对象模型出发的,属于实体主导型设计。 一般数据库应用系统都遵循以下相关开发步骤: 1 设计应用系统结构; 2 选择便于将应用程序与 DBMS 结合的DBMS体系结构,如RDBMS; 3 根据应用程序使用的环境平台,选择适宜的DBMS(如Oracle)和开发工具(如PB); 4 设计数据库,编写定义数据库模式的SQL程序; 5 编写确保数据正确录入数据库的用户接口应用程序; 6 录入数据库数据;7 运行各种与数据库相关的应用程序,以确认和修正数据库的内容。 对以上各步骤,有几点需要说明: (1) 这不是瀑布模型,每一步都可以有反馈。以上各步不仅有反馈、有反复,还有并行处理。比如一些库表在数据录入时,另一些库表设计还在修改。这与我们的递增式开发方法有关,也与面向对象的特征有关。 (2) 上述顺序不是绝对的,大多数场合是从第三步开始的。 (3) 对大多数数据库应用系统来说,上述各步中最重要、最困难的不是应用系统设计而是数据库设计。 三、DBMS的支持和数据库设计 很多数据库应用系统开发者不重视数据库设计的原因是:他们太迷信DBMS,认为购入一个功能强大的 DBMS后数据库设计就不困难、不重要了。一些国内外的数据库教材常常是在为DBMS的开发厂商做宣传,而很少站在数据库用户角度,从数据库应用系统出发介绍数据库设计方法。结果往往使读者搞不清书中介绍的是数据库管理程序的设计思想,还是应用这种 DBMS 进行数据库设计的思想。 其实,DBMS只是给用户为已采用的数据库提供一个舞台,而是否使用这个舞台上的道具以及唱什么戏,则完全取决于用户的戏剧脚本和导演(开发者)的安排。例如,公路局系统所使用的数据库管理系统,是以二维表为基本管理单元、支持所有关系代数操作、支持实体完整性与实体间参照完整性的全关系型 RDBMS,而我们要在这个舞台上利用上述"道具"设计一个面向对象的关系数据库。 四、应用对象模型与RDBMS模型的映射 数据库设计(模式)是否支持应用系统的对象模型,这是判断是否是面向对象数据库系统的基本出发点。由于应用系统设计在前,数据库设计随后,所以应用系统对象模型向数据库模式的映射是面向对象数据库设计的关键。 1. 3层数据库模式面向对象模型的扩展 一般数据库设计多参照ANSL/SPARC关于数据库模式的3层标准结构提案。最接近物理数据库的内部模式由 DBMS 提供的SQL来描述。概念模式可以由若干个内部模式聚集而成,它是由数据库用户规范的一些表的集合。一般的概念模式是数据库物理模式作用域的边界,它能实现数据库的物理意义、特定DBMS 的特殊操作对外部应用程序的信息隐蔽。外部模式是从特定用户应用角度看待的数据库模式,从不同的应用出发对同一概念模式可以给出多种不同的外部模式。当外部应用系统以对象模型进行抽象时,从各个应用出发抽象出的对象模型可以映射到外部模型上,对此我们不妨称之为外部对象模型。但是,外部模型只是概念模型的子集,所以面向对象的数据库设计核心在于系统对象模型(不妨称之为概念对象模型) 向数据库概念模型的映射 。 2. 对象模型向数据库表的映射规则 由于 RDBMS 是以二维表为基本管理单元的,所以对象模型最终是由二维表及表间关系来描述的。换言之,对象模型向数据库概念模型的映射就是向数据库表的变换过程。有关的变换规则简单归纳如下: (1) 一个对象类可以映射为一个以上的库表,当类间有一对多的关系时,一个表也可以对应多个类。 (2) 关系(一对一、一对多、多对多以及三项关系)的映射可能有多种情况,但一般映射为一个表,也可以在对象类表间定义相应的外键。对于条件关系的映射,一个表至少应有3个属性。 (3) 单一继承的泛化关系可以对超类、子类分别映射表,也可以不定义父类表而让子类表拥有父类属性;反之,也可以不定义子类表而让父类表拥有全部子类属性。 (4) 对多重继承的超类和子类分别映射表,对多次多重继承的泛化关系也映射一个表。 (5) 对映射后的库表进行冗余控制调整,使其达到合理的关系范式。 3. 数据库模式要面向应用系统 我们选择面向对象的系统设计也好,面向对象的数据库设计也好,根本目的是服务于应用系统的需要。 五、面向对象关系数据库设计效果 从某种意义上讲,是数据库设计的面向对象特征最终奠定了整个系统的面向对象性,才使面向对象方法在程序开发阶段全面开花。其效果归纳如下: 1. 数据库结构清晰,便于实现 OOP 由于实现了应用模块对象对数据库对象的完全映射,数据库逻辑模型可以自然且直接地模拟现实世界的实体关系。用户所处的当前物理世界、系统开发者所抽象的系统外部功能,与支持系统功能的内部数据库 (数据结构)一一对应,所以用户、开发者和数据库维护人员可以用一致的语言进行沟通。特别是对多数不了解业务的程序开发人员来说,这种将应用对象与相应的数据对象封装在对象统一体中的设计方法,大大减轻了程序实现的难度,使他们只要知道加工的数据及所需的操作即可,而且应用程序大多雷同,可以多处继承由设计人员抽象出来的、预先开发好的各种物理级超类。 2. 数据库对象具有独立性,便于维护 除了数据库表对象与应用模块对象一一对应外,在逻辑对象模型中我们没有设计多重继承的泛化关系,所以这样得到的数据库结构基本上是由父表类和子表类构成的树型层次结构,表类间很少有继承以外的复杂关系,是一个符合局部化原则的结构,从而使数据库表数据破坏的影响控制在局部范围且便于修复,给系统开通后的数据库日常维护工作带来便利。 3. 需求变更时程序与数据库重用率高,修改少 在映射应用对象时,除关系映射规范化后可能出现一对多的表映射外,大多数应用对象与表对象是一一对应的。我们可以把规范化处理后的、由一个应用对象映射出来的多个表看成一个数据库对象。因此当部分应用需求变更时,首先,系统修改可以不涉及需求不变更的部分。其次,变更部分的修改可以基本上只限于追加或删除程序模块或追加新库表,而基本上不必修改原有程序代码或原有库表定义,从而大大减少了工作量,降低了工作难度。 六、最简单的就是最好的 客观世界是错综复杂的,计算机科学理论的发展也越来越高深、复杂。然而,人类探索理论和技术的最终目的是:让客观世界的复杂变简单,最简单的就是最好的。为此给出以下几点忠告: 1. 慎用外键 RDBMS 支持复杂关系的能力很强,无论用户怎么在逻辑上设定外键,它基本上都能从物理上帮用户实现。但是外键把许多独立的实体牵连在一起,不仅使 RDBMS 维持数据一致性负担沉重,也使数据库应用复杂化,加重了程序开发负担。这样的数据库很难理解,很难实现信息隐蔽性设计,往往把简单问题复杂化。 2. 适当冗余 减少数据库冗余的设计思路产生于70年代,它是促使 DBMS 进步的重要动力之一。然而,犹如为了节省2个字节的存储空间而酿成了如今全球为之头痛的2000年问题一样,它是计算机硬件主导时代的产物。以今天国内计算机市场价格为例,6G服务器硬盘的价格不过2000元,而上海物价局 1996 年颁发的一个人月软件开发的指导价约8000元,即一个人月的软件价格就可以购买20G左右的硬盘。即使有5万行数据的库表,每个记录压缩40字符的冗余,单纯计算合计也不足2M,即节省0.6元钱的磁盘空间。 今天的世界已进入软件主导的计算机时代。因此,最容易理解、应用开发工作量最少、维护最简单的数据库结构才是最好的。只要数据完整性、一致性不受威胁,有些冗余,不足为虑。换言之,最节省软件成本 (而不是硬件成本) 的是最好的。 3. 信息隐蔽 这是软件工程最重要的基本原则之一。简言之即信息的作用域越小越好,数据库的透明度越大越好,因为应用程序需要知道得越多就越复杂。使数据库黑盒化 (透明度高) 的方法很多,除了设计上的局部化处理外,还可以利用 DBMS 的触发器、存储过程、函数等,把数据库中无法简化的复杂表关系封装到黑盒子里,隐藏起来,特别是放到服务器端,其优越性更是多方面的。 |
| 对象数据库与关系数据库利弊谈 | |
| 来源：IT专家网 时间：2006年12月22日 |
|
在20世纪60年代后期引入的面向对象技术引起了一场革命。到20世纪80年代后，面向对象的技术已经成为了行业的主流，其原因多种多样：面向对象不仅简化了界面的开发，而且也提供了一种更加灵活、简单数据处理方法，这种方法从根本上改变了应用程序的构建方法。不再像关系型数据库一样用死板的二维表格来表示数据，对象技术使用类对数据进行描述。一个对象是一个类的实例，就像一颗特定的橡树是橡树类的实例一样。 在20世纪60年代后期引入的面向对象技术引起了一场革命。到20世纪80年代后，面向对象的技术已经成为了行业的主流，其原因多种多样：面向对象不仅简化了界面的开发，而且也提供了一种更加灵活、简单数据处理方法，这种方法从根本上改变了应用程序的构建方法。不再像关系型数据库一样用死板的二维表格来表示数据，对象技术使用类对数据进行描述。一个对象是一个类的实例，就像一颗特定的橡树是橡树类的实例一样。 对象技术使用继承方案，使得类是按等级设计的。"橡树"类能够从更加普遍的类"树"继承数据结构和数据行为。 对象技术能够更好地描述我们所见的世界，面向对象的语言已经被证实在大多数编程领域更加通用。他们使得编程语言更加接近自然语言和多数软件开发领域的主流思想。面向对象是一个新的典范，它的影响将持久而深远。 面向对象的特性很快被添加到各种成熟的语言中，并因此成就了一些语言，如C++。新的面向对象的开发环境出现了，包括Visual Basic，Visual C++，PowerBuilder，Delphi，以及Caché。尽管面向对象的技术在高级开发环境下受到了广泛支持，它还是需要花一定的时间形成正规的课程。而且还需要花更长的时间来构建一个真正的基于对象的世界--我们目前还没有到达这样一个阶段。 万维网上对象技术的发展 随着万维网(World Wide Web)转变为交换各种信息的手段，面向对象的编程语言Java成为Web开发者的最爱。基于C++，Java能够用来创建可以在浏览器执行的小程序(Java applets)。 Sun为了促进Java的发展免费提供Java环境。在短短几年内，成百上万的Java环境被复制下载，Java渗透到世界的每一个角落。同时Java引发了更多的面向对象语言，如JavaScript，C#以及Jscript。Internet的发展也培育了一些新的面向对象语言像Perl和PHP。现在的开发者使用面向对象的技术已经是理所当然的了。 对象的崛起 对象技术影响了软件开发的各个方面。对象建模已经占领了应用建模的市场，标准UML建模方法独占鳌头。 20世纪90年代，面向对象中间件产品的出现为面向对象的应用提供了安全交流服务。当1998年JMS(Java Messaging Serivce)的出现，使得中间件市场向前跨越了一大步。JMS定义了一整套消息传递的应用编程接口(APIs)，使得经认证的J2EE应用必须引入JMS服务器。这进一步强化了标准化进程，大大降低了中间件的费用，提供了编写企业范围基于对象的应用程序平台。 XML和Web服务 1998年，HTML，专门用于网页设计的标识语言，经过进一步发展并标准化，创造出了XML(扩展的标识语言)。XML提供了一整套语法，能够用于创建与存储在数据库中定义相似的自定义数据格式，可以。有了XML，程序能够把定义附加在数据上，能够交换数据和数据含义。XML能够使得有特定标准的数据模型(如发票或者购买订单)的定义能够在公司内部或者公司之间进行数据交换。XML引发了Web服务的兴起--在不需要客户定制的情况下，程序能够与其他程序立即交互。现在出现了两种Web服务环境--J2EE和.NET。像SQL一样，XML为程序员提供了获取数据的标准，但XML同时还提供了一种在对象层定义数据的标准语言。XML和对象技术一样迅速成长。结果，数据对象的新标准和基于XML的新的开发产品出现了。 对象数据库--缺失的一环 与软件开发各个环节中对象技术的快速应用形成鲜明对比，对象数据库直到现在才开始逐渐被人们所接受。对象数据的迟缓行动原因有很多。 早期的对象语言没有考虑数据存储。程序在内存数据上工作，数据作为文件存储，当程序下次运行时数据也作为文件被读取。这种方法使得应用程序之间不可能共享数据，数据的恢复、管理、扩展几乎不可能。 目前在市场上已经有大量的面向对象数据库产品：Versant，Objectivity，ObjectStore，GemStone等等。他们为面向对象的开发环境提供了相应的数据存储。这些产品满足了最初的热情，甚至这些产品被期望能够打造一个新的数据库市场--甚至可能成为市场的领袖。 但不幸的是，这些对象数据库出现时，关系型数据库供应商已经积聚了巨大的动力，并占领了大量市场份额。在标准的SQL接口下，访问关系型数据库的面向对象程序很容易写。相反，多数早期的对象数据完全不提供SQL接口，不适合任何查询应用程序。结果，对象数据库在商业上没有建立坚实的基础。他们在应用领域只创建了一个小市场来管理和存储复杂对象如CAD/CAM，电信业、多媒体、人工智能，模拟金融设备、病人诊治跟踪系统以及科学应用。 数据库市场从未特别关注过对象数据库，直到对象定义语言XML出现，这种情况才有所改变，促进了对象数据库的再次呈现，因为他们管理XML定义的数据是最合适的。使用XML，必然会提高存储复杂数据的需求，将进一步引发对象数据库的复苏。 03年9月份InfoWorld公布了一项开发员调查，其中有一个惊奇的结果，89.2%的被调查者说他们使用关系型数据库，52%的被调查者说他们使用面向对象或者XML数据库。当问及有关存储数据的类型时，40.2%的人说他们存储持久的对象，58.9%的人说他们存储XML数据，89%的人说他们存储关系型数据。Baroudi Bloor相信对象数据库比我们想象的用的更加广泛，随着需求的激增，将进一步扩大市场份额。 InfoWorld的调查还显示了面向对象的语言是新应用开发的主流选择。我们相信这些统计数字反映了当今开发员面临的困境。他们需要与他们一直使用的面向对象语言有更好协调性的数据库，但他们有需要关系型数据库所提供的查询能力。 关系型数据库--另一半是如何存在的 只要有程序，就会有数据。IT行业最早具有商业价值之一的就是数据管理。自动的数据管理意味着业务能够扩展、具有竞争力，没有它就不可能。所以毫无疑问机智的商业技术员很早把目光聚集在数据管理市场。在对象数据库产生之前的20年，E.F Codd博士提出的关系型理论找到了出路，开发出商业的关系型数据库产品。在80年中期，在IT领域有一个宗教式的信仰，认为数据的所有理论问题都已经解决，实践的问题也会随之解决。然而，很明显，事实并不是这样。 关系型数据库把数据存储在简单的两维表中，这是一种表达大量数据的有效方法，而且程序员也易于理解。关系型数据库使用SQL建立了一种标准的数据访问语言。关系型数据库有一个逻辑和物理形式清楚的结构，这种结构使得应用程序对数据结构是透明的，而且在很多商业应用程序中工作的很好。 然而，关系理论的基础之一是数据和使用数据的程序能够而且应该是相互独立的。这与对象技术的整个理念是不一致的。对象技术鼓励设计者使用对象而不是表来思考数据。对象和使用对象的方法是不可能彼此分开的。 如果把汽车作为一个复杂的对象来考虑。当你使用汽车时，你使用一辆完整的汽车，作为一个东西--一个对象来使用。与汽车相联系的有很多动作(也就是面向对象术语中的方法)。你驾驶汽车，进行换档，发信号，开车灯，等等。如果汽车是一个对象，这些动作就是对象的方法，他们对汽车而言是基础性的。这些动作独立于汽车的想法是荒唐的。当你把你的车停在车库，你把它作为一个东西来存储。而不是分别在车库中的某些地方存放方向盘，转换器，信号器，车灯。数据和它相对应的处理过程也不能而且也不应该被隔离开来。在对象数据库中他们是不分开的。 事实上，这两种观点各有优缺点。有些处理过程确实是独立于数据的。尤其是访问大量数据的查询操作。简单的查询就是根据一些标准来选取数据，而不关心数据是什么，也不用关心数据是如何被组织的，只要它能快速的被取出就可以了。查询是独立于数据的，但对象方法则不是。 关系型数据库的局限性 关系型数据库有比我们想的更多的局限性。存储和表示一些相当普通的数据结构也是非常困难的。试想一条公交线路--简单，有序的一组站点。关系型数据库以无序的方式存放表，只有创建一个特殊的索引，才能提取有序的数据。对象数据库就没有这个问题，它有有序的数组，不需要索引--这种索引是因为关系数据结构的局限性而要求创建的人工索引。 另一个简单的例子是产品用料单--在制造系统中记录一个产品和它的组件。组件自身也许还有组件，组件的组件还有组件，以此类推。一个关系型数据表不能表达这种部件与部件的部件之间的关系。而这些关系却是重要的数据。查询一个产品数据库，它的所有组件应该是一目了然的。关系型数据库结构使得开发员花费很多的工作来回答这种简单的查询，非常的复杂、困难。与这个例子类似的例子：地图和它的路、河、路标;网站和它的页面、链接以及图像。实际上，搜集的信息越复杂，等级层次和交叉层次就越多，在简单二维表的关系型数据库就越不可能表达清楚。对象数据库没有这样的限制，事实上，他们就是为了解决这个问题而设计的。 虽然关系型数据库发展成熟，在这十年中发展也非常迅猛，但我们还听到一些项目因为所使用的关系数据的性能不是很好而导致失败。通常，是因为关系型数据库物理上存储数据的方法导致的。对开发员而言，为了集合他们所需的数据，他们常常不得不进行这个表与另一个表联接，再与另外的表联接，然后再与另一个表联接。为了提取数据，数据库运行优化程序来判断提取数据的最好方法，然后再提取数据。这样的处理常常要花费很长的时间，结果就大大影响了性能。尽管关系型数据库优化器已经改善了运行时间，但他们还需要比对象数据库更多的处理时间。 关系型数据库和"阻抗不匹配"障碍 关系型数据的一个问题是他们所使用的基本数据结构是一种二维形式的表。在关系理论中，数据应该被组织成规范的表--也就是数据应该按唯一的方式组织，使得程序员能够消除冗余，确保数据变化的一致性。这种设计技术的引入确保了关系表中的数据是一组独立的、通过键相关的数据。这种技术来自集合论的数学理论，但问题是集合论不能表达数据之间所有的关系和结构。 以规范的方式存储数据常常要求程序员在存入数据库之前分解对象，并且重新组织数据，但要使用它是，在使用SQL查询(多重连接)。就像在车库中存储车时，你把它的门、椅子、轮子等等分别卸下来存放。这是非常耗时的，而是也是没有任何意义的。 但面向对象的语言占主导地位时，问题就越发明显了。这个问题通常被称为对象-关系不匹配障碍。这个问题是由于面向对象语言和关系型数据库使用语言的方法不同导致的，结果这个问题只能有程序员自己来解决。事实上，大多数关系型数据库在使用的时候并不是完全规范的，但即使是这样，不匹配问题还是发生，对编程人员的工作造成了很大的困难。我们可以估计使用关系型数据库的面向对象开发员25%到40%的时间用于编写代码来解决对象与关系表的匹配问题。 也许这个根本性困难产生了对对象数据的强烈需求，但多数对象数据库也有一个很大的问题：他们对SQL的支持很少。而许多软件工具需要SQL接口，尤其是商业智能应用。甚至有SQL接口的对象数据库也不能创建用于管理商业智能应用所产生的这类查询机制。 对象-关系数据库 关系型数据库的供应商并没有忽视对象的出现。显然，规范复杂数据是没有意义的。举个极端的例子，如果你要规范一个位图形式的图像--是一系列的象素表示的--你最终要得出一个表，这个表的行是象素，并且主键的属性反映他们的顺序。很明显最好是把这个数据作为一个对象来存储。 他们提出了"对象-关系"数据库的创意，这个创意中保留了关系型数据库的结构，但允许关系表中的列含有一个复杂的对象。这些对象能够捆绑处理复杂数据的处理过程(一种存储过程)。并且SQL能够允许调用与关系型等同的"对象方法"。 这种方法是对数据关系理论的一种嘲弄，事实上，它完全忽略了这个理论，但又允许复杂数据(地图，矢量图，图表，甚至整个表格)被定义为一个项目存放在关系结构中。因此，这些功能被实现并商品化。Informix称它的嵌入过程为DateBlades，Oracle称之为Cartridges。 对象-关系数据库成为存储数据时对象数据库的一种替代方案，但根本的问题它并没有解决。对象-关系数据库还是受不匹配障碍的困扰。 对象数据库与关系型数据库 实践中，对象数据库相对于关系数据库有显著的优势。 他们能更快的运行事务处理程序 他们能够更有效的处理对象 他们能够提供更好的开发效率 他们能够管理更容易 在一些例子中，因为是性能方面的原因，用对象数据库能够替代关系型数据库。在不能存储复杂对象的大规模的业务处理程序中确实是这样的--也许有些人会认为这个必然是关系型数据库的领地。 对象数据库最大的性能优势是他们不必像关系型数据库一样在数据使用之前先连接数据。他们就以使用数据的方式存储数据，这就大大提高了性能。对象数据库能够使用缓存技术，这样就使得在请求数据时数据就已经存放在内存中了。对象数据库在抽取数据时几乎不需要进行优化。 但开发一个新的系统，处理复杂数据如文档、复杂图表、网页、多媒体等的需求不断增长时，这些需求对象数据库可以很好的满足。 当今面向对象的前景 在软件开发的各个方面使用对象技术的人群都在不停地增长。甚至在最后一个领域--数据库--尽管对象数据库还没有取代关系型数据库，这种增长也是十分显著的。InfoWorld报告说52%的开发员在使用对象数据库或者XML数据库(通常也是一种对象数据库)。还有一些选择混合形式的数据库，这种数据库能比较容易地使用对象结构。随着新应用程序开发过程中Web接口成为一个必不可少地部分，Web服务成为应用系统交互地一种可行的机制，构建一个面向对象的世界似乎是当今的现实。 03年9月的InfoWorld调查也显示了使用面向对象语言的程序员几乎无处不在。事实上，尽管有些人宣称使用C语言，但是面向对象的语言还是成为当今90%的程序员的选择。调查也显示了程序员比较喜欢基于Web的应用，易用的对象编程和脚本语言。随着越来越多的有着正规培训的软件工程师进入市场，面向对象技术将成为新应用开发的唯一选择。 结论 也许关系型数据库将继续领导数据库市场，而对象数据库在市场上只占有一席之地。也许对象数据库将进一步提升市场份额，因为他们能够处理当今使用的复杂的数据。然而，我们认为还有其他的可能：数据库技术可能发展出一种真正的混合型产品，这种产品能提供关系接口和对象接口双重优势。我们知道这是有可能的。事实上，至少有一种产品，来自InterSystems的Caché，就是这样一个产品。(Caché数据库，描述他自己时，既不是说是关系型的，也不是说是对象的，而是后关系型数据库)。数据库供应商--不管他们的产品是属于关系型还是对象型--都会朝着这个方向前进的。 这种混合产品的方法包括给数据库提供一个映射层，程序员通过映射层访问数据库。映射层应该基于开发的标准以解决不匹配障碍问题。数据库的调用能够用SQL完成，也可以直接请求对象类或者类的集合。映射层能够把这些调用转换为对数据库的物理数据请求以抽取数据。这种方法将消除不匹配的障碍。 改变任何一种数据类型都是非常大的挑战。对象数据库需要快速索引能力，以从庞大的数据集中抽取数据。在这方面做得比较好的关系型数据库使用位图索引技术，但数据一旦更新，这些索引就需要重新建立。因为这个原因，很少有对象数据有这个功能。对关系数据库而言，他们需要提供更加灵活的物理数据结构。在发展过程中，关系型数据库倾向于在物理层使用表。他们需要放弃这种不灵活的限制，允许存储多种数据结构。数据库使用者将获得最大的收益。试想把对象数据库的优势和关系型数据库的优势整合在一起： 好的处理性能 复杂数据管理 管理简便 快速开发 灵活的查询功能 标准的数据访问接口 更好地适用于商业智能应用 这种混合产品使使用一个数据库引擎成为可能，并且所有应用只有一个数据定义集。Baroudi Bloor相信企业界需要混合式的数据库产品。供应商们必须放弃他们对关系数据库宗教式的倾向，转向更具优势的混合式的数据库，否则的话他们将陷于COBOL以及打孔卡片的深渊而不能自拨。 |
浙公网安备 33010602011771号