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 [url]http://www.db4o.com[/url] 其实是网络数据库. 通用面向对象程序设计语言 (General Purpose Object Oriented Programming Language), 特别是广泛应用的一些, 像 C++, Java 方面, 始终没有本土的关系模型数据库出现. 而应用程序开发领域广泛采用了这些 通用面向对象程序设计语言, 并且难以割舍.
加上 Hibernate 所引领的层出不穷的 ORM 框架产品, 呈现给人一种感觉, 那就是, 面向对象 与 关系模型 水火不容, 只能 Mapping.
但是事实上, 众多传统关系数据库产品早已加入了面向对象的思想特性, 称为 Object Relational Database [url]http://en.wikipedia.org/wiki/Object-relational_database[/url], 像 Oracle 8 以后就是. 更有甚者比如 InterSystems 的 CACHÉ [url]http://www.intersystems.com/cache/index.html[/url], 自称为 Post-Relational Database, 而其实已经可以通过完全的面向对象的语言来进行数据库开发, 只不过用的是自家(Home Grown)的OO语言.
而通用OO语言一直没能融合关系模型的一个根本原因, 是大家总是拒绝向内存对象模型引入 "关系对象" 的概念, 而这是 关系模型 区别于 网络模型 的根本特征之一.
不过在传统的以磁盘为主体存储的数据库系统中, "关系对象" 所建立起来的 "关联" 自然而然的完全存在于逻辑上, 这同时也使得对 "关联" 的操作非常简单, 只有3件事:
1. 创建关系对象以建立关联
2. 删除关系对象以解除关联
3. 指定 JOIN 以引用关联
这里的 3, 限定了对关系数据的访问只能是通过 SQL, 一种不可能 OO 的语言.
目前的数据库市场仍然还是 以磁盘为主体(Disk Targeted) 的数据库产品的天下, 所以天经地义的, 关系模型与 SQL 之间, 在人们心里存在一个等号.
但是随着64位计算的日趋普及, 大内存也成为趋势, 于是现在已经出现了新的可能:
[b]在内存里建立关系模型的对象数据![/b]
而基于日趋成熟的代码生成技术, 用注入的逻辑自动维护内存中关系模型下对象之间的引用关系也变为可能, 创建 和 删除 关系对象 时, 已经完全可以由数据库系统来自动修改它所连接起来的其他 持久对象 的 连接引用(Joint Reference), 从而维护整个内存中关系模型拓扑图的完整.
结论是: 对象技术其实不必借助 Mapping 就能实现和利用 关系模型, 现有的 ORM 其实只是在进行 OO语言编写的网络模型 到 关系模型 的映射.
面向对象的关系模型已经不是凭空的设想, 而是已经有可以实际应用的数据库产品, 就是我已经开发完成的 Ableverse The Object Base [url]http://tob.ableverse.org[/url], 它也不仅只是一个研究产品, 从开源的 WoW [url]http://www.webofweb.net[/url] 产品表现, 可以看到它的商业质量.
不过 TOB 目前公开发行的还是版本 5, 开发时编译步骤还相对复杂.
计划元旦以后发布版本 6, 这个版本只需JDK6的javac, 没有任何多余步骤, 只需按平常开发Java程序的方法就可以编写基于TOB的持久应用, 通过Apache Ant, 也可以和流行Java IDE很好的集成.
基于TOB的持久应用, 全部源码只需Java类代码, 并且相对于 直接JDBC操作关系数据库, 或通过ORM方式, 数据库性能有几倍到几千倍的提升, 是关系数据库后台存储上的内存数据库性能.
不过最近为了写 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 [url]http://www.db4o.com[/url] 其实是网络数据库. 通用面向对象程序设计语言 (General Purpose Object Oriented Programming Language), 特别是广泛应用的一些, 像 C++, Java 方面, 始终没有本土的关系模型数据库出现. 而应用程序开发领域广泛采用了这些 通用面向对象程序设计语言, 并且难以割舍.
加上 Hibernate 所引领的层出不穷的 ORM 框架产品, 呈现给人一种感觉, 那就是, 面向对象 与 关系模型 水火不容, 只能 Mapping.
但是事实上, 众多传统关系数据库产品早已加入了面向对象的思想特性, 称为 Object Relational Database [url]http://en.wikipedia.org/wiki/Object-relational_database[/url], 像 Oracle 8 以后就是. 更有甚者比如 InterSystems 的 CACHÉ [url]http://www.intersystems.com/cache/index.html[/url], 自称为 Post-Relational Database, 而其实已经可以通过完全的面向对象的语言来进行数据库开发, 只不过用的是自家(Home Grown)的OO语言.
而通用OO语言一直没能融合关系模型的一个根本原因, 是大家总是拒绝向内存对象模型引入 "关系对象" 的概念, 而这是 关系模型 区别于 网络模型 的根本特征之一.
不过在传统的以磁盘为主体存储的数据库系统中, "关系对象" 所建立起来的 "关联" 自然而然的完全存在于逻辑上, 这同时也使得对 "关联" 的操作非常简单, 只有3件事:
1. 创建关系对象以建立关联
2. 删除关系对象以解除关联
3. 指定 JOIN 以引用关联
这里的 3, 限定了对关系数据的访问只能是通过 SQL, 一种不可能 OO 的语言.
目前的数据库市场仍然还是 以磁盘为主体(Disk Targeted) 的数据库产品的天下, 所以天经地义的, 关系模型与 SQL 之间, 在人们心里存在一个等号.
但是随着64位计算的日趋普及, 大内存也成为趋势, 于是现在已经出现了新的可能:
[b]在内存里建立关系模型的对象数据![/b]
而基于日趋成熟的代码生成技术, 用注入的逻辑自动维护内存中关系模型下对象之间的引用关系也变为可能, 创建 和 删除 关系对象 时, 已经完全可以由数据库系统来自动修改它所连接起来的其他 持久对象 的 连接引用(Joint Reference), 从而维护整个内存中关系模型拓扑图的完整.
结论是: 对象技术其实不必借助 Mapping 就能实现和利用 关系模型, 现有的 ORM 其实只是在进行 OO语言编写的网络模型 到 关系模型 的映射.
面向对象的关系模型已经不是凭空的设想, 而是已经有可以实际应用的数据库产品, 就是我已经开发完成的 Ableverse The Object Base [url]http://tob.ableverse.org[/url], 它也不仅只是一个研究产品, 从开源的 WoW [url]http://www.webofweb.net[/url] 产品表现, 可以看到它的商业质量.
不过 TOB 目前公开发行的还是版本 5, 开发时编译步骤还相对复杂.
计划元旦以后发布版本 6, 这个版本只需JDK6的javac, 没有任何多余步骤, 只需按平常开发Java程序的方法就可以编写基于TOB的持久应用, 通过Apache Ant, 也可以和流行Java IDE很好的集成.
基于TOB的持久应用, 全部源码只需Java类代码, 并且相对于 直接JDBC操作关系数据库, 或通过ORM方式, 数据库性能有几倍到几千倍的提升, 是关系数据库后台存储上的内存数据库性能.