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方式, 數據庫性能有幾倍到幾千倍的提升, 是關係數據庫後臺存儲上的內存數據庫性能.
