ORM其实是在映射网络模型和关系模型,OO的关系模型无需映射,且更简单高效

O-R Mapping 从字面上理解是在 面向对象体系 与 关系数据库 之间进行映射.

不过最近为了写 TOB 的 ORK 模型资料, 更进一步研究了 Entity-Relationship 模型以及相关的 网络模型, 关系模型 和 Entity Set 模型. 然后有个惊人的发现:

  ORM 所支持的 POJO 模型本质上其实是网络模型, 而 O-R 的 Mapping 其实是在 网络模型 和 关系模型之间进行映射.

--有了这个发现, 总算对一直以来对 ORM 和 POJO 模型的一些感性的抵触有了一个理性的认识.

认定 ORM 所支持的 POJO 模型为 网络模型, 判断如下:

1. 对象之间的关联是通过 单边(Unidirectional)或者对等(Bidirectional)的引用(Reference)或者引用集合(Reference Set)建立起来的. 没有独立的 Relationship 载体.
2. 对等(Bidirectional)的引用或引用集合之间也存在不自然的单向性, 其中必有一方为 Owner, 而另一方为 Member. 这是网络模型的特有特征.

而关系模型下 实体 之间的关联是通过独立的 关系记录 代表的, 而 关系记录 上也可以有自己的属性, 很多情况下这些 关系属性 非常重要, 使关系模型能够比网络模型更接近现实世界的结构. 比如一辆汽车的组装模型, 用到某种型号的螺母, 而这种螺母的单车用量, 作为 车型 与 螺母型号 两个实体之间的 关系属性 才最为恰当.


人们一直认为 关系模型 与 面向对象体系 之间无法完美融合, 也遭遇了多方面的尝试失败, 但是以目前我的研究分析结果来看, 这其中的根本原因是大家还没有认识到这些失败的研究和尝试仅只是在用 面向对象的方法 去实现 网络模型 的持久数据管理系统.

目前成熟的面向对象数据库, 比如为 Java 和 .Net 设计的 db4o http://www.db4o.com 其实是网络数据库. 通用面向对象程序设计语言 (General Purpose Object Oriented Programming Language), 特别是广泛应用的一些, 像 C++, Java 方面, 始终没有本土的关系模型数据库出现. 而应用程序开发领域广泛采用了这些 通用面向对象程序设计语言, 并且难以割舍.

加上 Hibernate 所引领的层出不穷的 ORM 框架产品, 呈现给人一种感觉, 那就是, 面向对象 与 关系模型 水火不容, 只能 Mapping.

但是事实上, 众多传统关系数据库产品早已加入了面向对象的思想特性, 称为 Object Relational Database http://en.wikipedia.org/wiki/Object-relational_database, 像 Oracle 8 以后就是. 更有甚者比如 InterSystems 的 CACHÉ http://www.intersystems.com/cache/index.html, 自称为 Post-Relational Database, 而其实已经可以通过完全的面向对象的语言来进行数据库开发, 只不过用的是自家(Home Grown)的OO语言.

而通用OO语言一直没能融合关系模型的一个根本原因, 是大家总是拒绝向内存对象模型引入 "关系对象" 的概念, 而这是 关系模型 区别于 网络模型 的根本特征之一.

不过在传统的以磁盘为主体存储的数据库系统中, "关系对象" 所建立起来的 "关联" 自然而然的完全存在于逻辑上, 这同时也使得对 "关联" 的操作非常简单, 只有3件事:

1. 创建关系对象以建立关联
2. 删除关系对象以解除关联
3. 指定 JOIN 以引用关联

这里的 3, 限定了对关系数据的访问只能是通过 SQL, 一种不可能 OO 的语言.

目前的数据库市场仍然还是 以磁盘为主体(Disk Targeted) 的数据库产品的天下, 所以天经地义的, 关系模型与 SQL 之间, 在人们心里存在一个等号.

但是随着64位计算的日趋普及, 大内存也成为趋势, 于是现在已经出现了新的可能:
  在内存里建立关系模型的对象数据!
而基于日趋成熟的代码生成技术, 用注入的逻辑自动维护内存中关系模型下对象之间的引用关系也变为可能, 创建 和 删除 关系对象 时, 已经完全可以由数据库系统来自动修改它所连接起来的其他 持久对象 的 连接引用(Joint Reference), 从而维护整个内存中关系模型拓扑图的完整.

结论是: 对象技术其实不必借助 Mapping 就能实现和利用 关系模型, 现有的 ORM 其实只是在进行 OO语言编写的网络模型 到 关系模型 的映射.

面向对象的关系模型已经不是凭空的设想, 而是已经有可以实际应用的数据库产品, 就是我已经开发完成的 Ableverse The Object Base http://tob.ableverse.org, 它也不仅只是一个研究产品, 从开源的 WoW http://www.webofweb.net 产品表现, 可以看到它的商业质量.

不过 TOB 目前公开发行的还是版本 5, 开发时编译步骤还相对复杂.
计划元旦以后发布版本 6, 这个版本只需JDK6的javac, 没有任何多余步骤, 只需按平常开发Java程序的方法就可以编写基于TOB的持久应用, 通过Apache Ant, 也可以和流行Java IDE很好的集成.

基于TOB的持久应用, 全部源码只需Java类代码, 并且相对于 直接JDBC操作关系数据库, 或通过ORM方式, 数据库性能有几倍到几千倍的提升, 是关系数据库后台存储上的内存数据库性能.

评论

20 楼 mowendi 2007-01-05  

你的工作成果非常漂亮！
在应用上，是否考虑过这两个方面：
（1）在电信、银行核心资源的管理上
（2）IBM的通用存储数据跟你的工作成果是否有类比性

19 楼 歆渊 2007-01-01  

ceder 写道

看了半天，满篇都是高深的术语，除了广告，基本没看懂，惭愧。

特别不理解的是：“在内存里建立关系模型的对象数据!”，这和使用hibernate等ORM到底有什么区别？数据持久层难道是放在磁盘上运行的么？而且，我们所说的内存，一般都是指RAM，在里边保存的数据，迟早是要放到磁盘等能够持久保存数据的介质上的，难道这也能成为OO和关系型数据库的本质区别么？

总觉得，要解决这个问题，还是要从数学理论入手，在数学理论没突破以前，ORM是绕不开的。

从实践入手，恐怕，真不如号召现有的数据库提供厂商都自己实现hibernate，把hibernate作为数据库的lib，让hsql成为面向java程序员的sql。

包括 Hibernate, EJB3 JPA, JDO 在内, 当物理存储是传统关系数据库时, 它们都是使用 ORM 概念和技术, 而无一例外的是实际支持 网络模型 的应用程序 POJO 对象, 所以现在的 ORM = OO的网络模型

而实际上之所以关系数据库在整体上胜过网络模型的对象数据库很多, 关系模型 是非常大的重点, 更贴近自然世界的信息结构, 也有更大优越性. 所以基于 网络模型 的现行 ORM 方案有很多 关系模型 既已解决的问题, 不脱离目前的 ORM, 就没法完满的解决这些问题.

但是关系数据库一直不能很好的和面向对象语言无缝衔接, 现实情况并不像90年代初人们所总结的那样是对象技术和关系模型之间存在 "阻抗失配", 而罪魁祸首其实是 SQL. SQL 只能体现和利用 关系模型 的一部分, 而并非整体. 这个情况在 第三宣言 里分析得比较透彻了.

现在的情况并不是数学理论缺乏突破, 关系模型早在 1970 年就提出成型的数据管理应用方法了. 只是做对象开发的领域, 特别是对 ORM 来说, 大家一直没有意识到自己其实一直局限在 网络模型 上, 也没有怎么感觉到关系模型在 SQL 以外的应用方式.

我从实践里摸索出来的是一种 以内存关系对象模型为主, SQL为辅 的面向对象的关系数据库和应用开发框架, 比如 WoW 中的权限校验处理, 它能在 1ms 内处理相当于上百条 SQL 语句的逻辑判断. 相同的问题用纯 SQL 操作当然不现实, 如果用 ORM 的缓存来提高效率, 也还是会慢几倍, 因为 TOB 应用所访问的是直接关系模型的对象拓扑图, 根本不用复杂的缓存设计和开销. 另外如果解决复杂的现实问题, 比如用在 ERP, PDM/PLM 领域, 网络模型的 ORM 或者 POJO 有很多不自然, 平添复杂性的方面, 而关系模型就非常合适. 但是如果还是通过 SQL 定义和访问 关系数据, 那就很难面向对象的设计和开发, 这种场合是非常好的 内存关系对象模型 的用武之地. 我原来是搞 PDM 的, 可以负责任的说, 最成熟的产品都是将 SQL关系数据库 进行面向对象的关系模型封装, 只不过封装层大多是用 C 实现的, 封装出来的 OO界面 也是自家语言或者OO思想的非OO API集合. 而我现在搞出来的这个产品, 是可以用Java这种通用OO语言进行基于 关系模型 的持久应用 分析, 设计 和 开发.

18 楼 ceder 2007-01-01  

看了半天，满篇都是高深的术语，除了广告，基本没看懂，惭愧。

特别不理解的是：“在内存里建立关系模型的对象数据!”，这和使用hibernate等ORM到底有什么区别？数据持久层难道是放在磁盘上运行的么？而且，我们所说的内存，一般都是指RAM，在里边保存的数据，迟早是要放到磁盘等能够持久保存数据的介质上的，难道这也能成为OO和关系型数据库的本质区别么？

总觉得，要解决这个问题，还是要从数学理论入手，在数学理论没突破以前，ORM是绕不开的。

从实践入手，恐怕，真不如号召现有的数据库提供厂商都自己实现hibernate，把hibernate作为数据库的lib，让hsql成为面向java程序员的sql。

17 楼 歆渊 2007-01-01  

这两天找资料又有新发现, 原来发现 对象-关系阻抗失配 的问题出在 SQL 而不是 关系模型 的不止是我自己.

C. J. Date 和 Hugh Darwen 提出的 The Third Manifesto http://thethirdmanifesto.com (第三宣言?) 分别在 1998 年和 2000 年发表了两版真正关系模型数据库管理系统的基础分析, 并且提出了同时兼顾关系模型与面向对象的 D 语言.

不过他们选的途径是很长远的, 走的是定义新的计算机语言的路. 兼顾 关系模型 和 面向对象 的计算机语言其任重道远, 从两人目前还仅只是定义出 Tutorial D, 一个面向研究教学的 D语言 子集, 而对工业化的 D语言 前景还只能揣测和观望的情况上, 可见一斑.

相比之下我走的是实践摸索的路子, 是从现有通用工业化的Java语言入手, 并且先构架开发出一个能稳定支持大型持久应用的数据库产品, 再总结其中的原理, 开辟一条给 已有通用的面向对象设计语言 加入 关系模型 优越性的途径.

16 楼 Godlikeme 2006-12-28  

不是计算机模型和自然界模型的问题，
主要的问题是在数据的集合操作上，
关系型数据库有完备的数学基础来解决集合操作问题。
网络型数据库没有，数据之间的关联性体现在类的关系上，对超出类关系外的数据关系很难处理，或者说能处理，但性能非常差。这些还都是处于探索阶段。

15 楼 歆渊 2006-12-28  

嗯, 网络模型是计算机世界的天然模型, 用来解决计算问题最恰当.
关系模型是自然世界的天然模型, 用来建模解决现实世界的问题最恰当.

但是人们一直认为 关系模型 和 对象技术 有冲突, 也很少意识到大家其实仅只是在 网络模型 上应用对象技术.

而实际上, 用 OO 方法完全可以实现关系模型, 根本不必映射.

只是对象关系模型更依赖于大内存(也能更有效的利用大内存), 64位寻址空间的普及和内存条的成本降低让它成为更优的选择.

14 楼 Godlikeme 2006-12-28  

6年前学习数据库的时候就是网络模型的面向对象数据库，概念上的进展并不大，这个概念的出现应该有几十年了。
它的强项：在对象的增删改查，级联操作上。
弱点在于：关联操作，集合处理，缺乏数学模型的支持， 还不够成熟。

基于成熟的关系型数据库，mapping，应该还算一个不错的折衷选择。

13 楼 歆渊 2006-12-28  

ken1984 写道

当你数据库大于1G时，你的内存是不是至少也得512M？当然如果你能保证1G的数据内只有%10或者较少的活动数据那无话可说。当性能是个问题的时候你才想起要做些额外的工作让这些事情效率提高，比如增加缓存机制或写时拷贝等技术。

目前性价比比较差的 单条2G服务器ECC内存, 报价不超过4000RMB, 可以用几年.
雇用一个中等程序员这个只够一个月的工资, 还不算四金补贴等等的开销.

12 楼 歆渊 2006-12-28  

partech 写道

还有一个继承的问题

together 写道

postgresql是支持表的继承的。

是的, 其实妨害继承应用的不是关系模型, 而是通过 SQL 的关系数据访问方式, 而 SQL 的不可替代性是由于内存一直不够大, 所以数据库/持久应用的设计都是面向磁盘为主体存储的. 随着内存越来越大, 内存中的关系模型数据可以主要通过遍历来访问了, 实现继承就更没什么障碍了.

其实目前的主流数据库都有一定的面向对象特征了, 如果可以打开wikipedia的 Object-Relation Database 条目, 可以看到Oracle, Postgres等等都从某些版本开始已经支持这些特性了. 特别是 InterSystems Cache, 它的成功说明在关系模型上应用对象技术确实有现实的可行性.

11 楼 歆渊 2006-12-28  

Allen 写道

主流数据库所应用的关系模型确实和面向对象理念存在不协调和不对称性，所以有了ORM这样的技术来辅助我们跨越这条“鸿沟”。

楼主的想法和实现个人觉得也是桥接这两者的一个优良的提案，可能也是楼主针对如今ORM存在的问题而给出的解决方案……
如今的计算机性能确实越来越多的依靠着内存来发挥，个人也比较认同“在内存里建立关系模型的对象数据!”这个手段。
只是不知道将来有没有好的机遇能够发展强大起来……

个人才疏学浅，没有和楼主具体探讨的实力，不过很期待你所展示的一些前景，同时也敬佩你的勇气和创造力。

谢谢! 做所有这些事情都是有一个过程的, 大家一起加油!

10 楼 歆渊 2006-12-28  

together 写道

只要还是“以磁盘为主体(Disk Targeted) 的数据库产品的天下”，ORM就有继续存在和发展的理由。

面向对象数据库，还处于摸索发展的阶段吧。我的感觉，面向对象本身就不容易与现实完全对应，所以还是关系型数据库来得简单实在。

TOB开辟的是一条 面向对象的内存关系数据库 之路, 不仅自己是应用面向对象的内存关系模型, 物理数据也可以存储在传统关系数据库中(目前这还是唯一的选择), 因为模型一致, 表结构也没有文化壁垒.

9 楼 歆渊 2006-12-28  

jianfeng008cn 写道

有没有中文版的？俺国家四级也过了的，可看英文还是累的

zrweng 写道

啥时候有中文reference呀

TOB相关的中文内容我会首先发在 JavaEye, http://www.iteye.com/subject/TheObjectBase 专栏下, 如果感兴趣的话请继续关注.

8 楼 chenxianlv 2006-12-28  

两点：
1、TOB给人以耳目一新的感觉，它抛弃掉了因为Java版本所带来的包袱，直接拥抱Mustang，新的技术平台给人新的自由；
2、让TOB平民化，可尝试从非技术角度，去推广。

7 楼 ken1984 2006-12-28  

当你数据库大于1G时，你的内存是不是至少也得512M？当然如果你能保证1G的数据内只有%10或者较少的活动数据那无话可说。当性能是个问题的时候你才想起要做些额外的工作让这些事情效率提高，比如增加缓存机制或写时拷贝等技术。

6 楼 together 2006-12-28  

postgresql是支持表的继承的。

5 楼 partech 2006-12-28  

还有一个继承的问题

4 楼 Allen 2006-12-28  

主流数据库所应用的关系模型确实和面向对象理念存在不协调和不对称性，所以有了ORM这样的技术来辅助我们跨越这条“鸿沟”。

楼主的想法和实现个人觉得也是桥接这两者的一个优良的提案，可能也是楼主针对如今ORM存在的问题而给出的解决方案……
如今的计算机性能确实越来越多的依靠着内存来发挥，个人也比较认同“在内存里建立关系模型的对象数据!”这个手段。
只是不知道将来有没有好的机遇能够发展强大起来……

个人才疏学浅，没有和楼主具体探讨的实力，不过很期待你所展示的一些前景，同时也敬佩你的勇气和创造力。

3 楼 zrweng 2006-12-28  

啥时候有中文reference呀

2 楼 together 2006-12-28  

只要还是“以磁盘为主体(Disk Targeted) 的数据库产品的天下”，ORM就有继续存在和发展的理由。

面向对象数据库，还处于摸索发展的阶段吧。我的感觉，面向对象本身就不容易与现实完全对应，所以还是关系型数据库来得简单实在。

1 楼 jianfeng008cn 2006-12-28  

有没有中文版的？俺国家四级也过了的，可看英文还是累的