UF Object-Relational Database Adapter (UFO-RDB)


If you have any question or suggestions please do not hestitate to contact me by email.

Claus P. Priese

Email: claus@priese-research.de or cspriese@gmx.de or priese@dbis.informatik.uni-frankfurt.de

or use the UFX-RDB contact-form to send me a message.

AIMS AND GOALS The idea of the basic UF object-relational database adapter (UFO-RDB) is to develop an advanced multipurpose
database-connectivity plattform (an object-relational wrapper-component) which can be used in various areas, application-scenarios and projects. Because of it`s practical relevance the Java-Plattform is choosen for implementation.
The UFO-RDB adapter is designed to match also more complex data-schemas.
(because trivial single-table data is not really a challenge )

To understand why such basic object-relational database-adapter makes sense a very short history of mainstream-database-systems follows:
One of the great advantages of E.F.Codd`s relational model for database management and the related software systems - called: relational database management systems - was and is the clear separation between data-content and the data content-management system. Pre-relational db-systems (i.e. Codasyl-Systems) did not make this separation and also the more recently pure object-oriented db-systems do not make this valuable separation in every case.
In older relational db's there where only simple/primitive/intrinsic datatypes available for the columns. Like Integer, Char etc ... Then for some reason the db-vendors introduced BLOBs and CLOBs to store images and textual documents in their db-management systems too. In the meanwhile the oo-programming-paradigma swapped over the world and the question arouse how to bring together the existing relational db-management systems with programming-language objects? This problem - "called impedance mismatch" - is caused by the fundamental mismatching of relational data-model and object-programming-model. The simplest way to bridge the gap is to serialize objects (create a flat bitarray) and store this serialized version as BLOB or CLOB. The problem with this approach is that you can not access parts (attributes) of the serialized object for example for queries or index-structures within the database-system because the relational DBMS is not aware of the fact that this BLOB is an serialized object.
The next step of some vendors was/is to allow the db-user to introduce their own types. In this manner the user/applicationprogrammer can tell the DBMS about new types as datatypes for the columns. For example if you have a programming-object for "adress" then you can tell some DBMS today about a new datatype "adress". This does not mean automatically that the DBMS can use(index/query) the content of this new type. Some DBMS see these new types again as pure BLOBs with an name-alias while others make steps into the direction of enabling their relational systems with "look-inside"-features(index/query). This depends on how far the relational DBMS-vendor did already progress in enabling their product with object-relational features. So you will find a lot of "object-relational enabled" products today but it always means a differend grade of enabling. depending on the vendor.
The UF Object-Relational database-adapter is a vendor-independent database-adapter bridging the impedance mismatch gap by mapping objects to relations through fully splitting the content of objects to relational attributes. Different standard mapping-alternatives are implemented in the UFO-RDB protoype. While there are special additional mechanisms for XML-data in an addition on top adapter (UFX-RDB) the target programming-plattform ist Java and the UFO-RDB prototype is completly implemented in Java.



The UFO-RDB database adapter ist based on several basic ideas. A few ideas have been published already

  • Object-Relational-Schema-Approach. The new and innovative idea of an "object-relational scheme" was published first in [PRI2000c] and [PRI2002a].
  • different mapping/splitting alternatives with related used algorithms (three standard algoriths are already implemented in the prototype) and related performance-issues (benchmark-results)
  • simple query support
  • the PersistentStore-concept and primitive type mapping from SQL-type to basic java types and related HOWTO
  • BLOB and CLOB support
  • support for persistent object-oriented basic-utility types like Collection, Set, Map etc.
  • automatic primitive type transformation capability through extension-classes (transformation)
  • description of GUI tools for Modelling POModeler, PSAssistant etc
  • contained examples
  • API-Documentation
  • general FAQ
  • system/software architecture with more details on Vitual-Table-Concept
  • Cross-Vendor OR-Schema-Migration by opening a schema from one PS and store it in an arbitrary other vendor. (Only testest with MySQL and DB2 until now)
  • ...

  • SOFTWARE NOTE: The software-copy downloadable here is for noncommercial evaluation-use only.
    By using the software contained in the distribution packages you agree to a non-commercial evaluation-licence. This non-commercial evaluation-licence grants everybody interested the right to use this software but WITHOUT ANY WARRANTY "AS IS" for non-commercial purpose only.
    Any commercial use, redistribution or bundling with other software is prohibited without explicit permission.

    The development of this software package is/will be continued and additional functionality will be added to widen application-areas and make it easier to use.
    version comment
    0.1.08 next milestone, not yet public, in work, not released yet
    0.1.07 class-analyser+enhancer and additional light JDO interconnection (backward-compatible)
    0.1.06 some modularity-enhancements
    0.1.05 persistent utility types: collection, map
    0.1.04 Blob and Clob support, simple query
    0.1.03 pobj deletion
    0.1.02 minor fix
    0.1.01 DB2-enabled
    0.1.0 first public version

    The UFORDB-Protoype is tested with:

    • MySQL : very good compatibility
    • DB2v7.1 : yes works with, but less intensive testing
    • Access and Cloudscape tried but not recommended actually
    • Oracle, MSSQL, Informix not tested yet
    use the UFO-RDB contact-form to manifest your interest and send me a message.


    EDUCATIONAL CONTENT   Summaries on interesting topics written/created by me:
    • Java Data Objects (JDO)

      JDO seems to be inspired by the ObjectDatabaseManagementGroup`s (ODMG) Object Database Standard3.0 with specialized Java-binding. The Java Data Objects specification [JDO02] standardize a pure object-oriented database access mechanism and it`s embedding in the Java-Programming-Environment. The JDO specification does contain several parts describing neccessary aspects of an object-oriented database integration into Java. This short text summarizes the fundamental aspects of the JDO specification required for understanding the corresponding parts of the database adapter.

      Object Model, JDO Identity and Object States

      The JDO specification distinguishes transient java programming language objects from persistent capable objects. The used object model split the set of persistent capable objects into two subsets. First Class Objects (FCS) and Second Class Objects (SCO). The main difference is, that first class objects possess a persistent object identity (POID), while second class objects does not. SCO`s doesn`t have own POID`s because they are always part of another FCS as attributes or in the inheritance-hierarcy. Persistent object identity differs from the in memory volatile object instance identity which is assigned from the Java Virtual Machine at runtime. JDO specifies three alternatives for persistent object identity (POID): application identity, data store identity and nondurable identity. The default object identity mechanism used in the UFO-RDB adapter corrensponds to JDO data store identity. Which means, the POID is managed by the used data store without being tied to any field values of a JDO persistent capable object instance. Persistent capable objects can be in one of the following states, according to their actual livecycle-phasis. Required states are transient, persistent-new, persistent-dirty, hollow, persistent-clean, persistent-deleted and persistent-new-deleted. Optional are the states nontransactional, persistent-nontransactional, transient-transactional, transient-clean, and transient-dirty. A detailed description of the meaning of this states is given in the JDO specification [JDO02] section 5.5 to 5.8 .

      Class Enhancer

      Before being able to store instances of java classes in a persistent storage the JDO specification requires that the classes are enhanced. Enhancement means adding of attributes and code to enable the persistency mechanism to correctly manage the instances and it`s data content. There is (intentional) nothing said in the JDO specification about how this enhancement has to be done. Therefore all possiblilities are available: source code extension, java-bytecode modification or perhaps a sophisticated on the fly modification of instances at runtime whenever needed. While the first alternative would be the most trivial to implement it isn`t an elegant choice because of it`s code-intrusion visible also for the application programmer. Therefore the second approach of a java bytecode enhancer is choosen in the UFO-RDB adapter.

      Interfaces and their interconnection

      An important part of the JDO specification is the introduction of a set of application programming interfaces accompanied with a description of their meaning. The interface PersistenceCapable is the one which java classes, whose object instances are intended to be stored in a persistent data store, needs to implement. The implementation for this interface is added to java classes usually by the class enhancer and consists mainly of fields and generic methods for data content management. The interface StateManager is "the other end" during runtime. This means an implementation of StateManager interacts with persistent capable object instances during runtime through the specified interface methods to manage the data content and object state correctly. Before being able to manage a persistence capable object instance at runtime it has to be created or read into memory from the underlying persistency mechanism. This is the task of an implementation of interface PersistenceManager. A PersistenceManager encapsulates the details of connection(s) to the used underlying enterprise information system (EIS), which can be directly a database management system or an even more complex persistent storage mechanism. To fulfill this tasks a PersistentManager implementation uses a vendor specific so called ResourceAdapter to create, store, retrieve, update or delete data objects in the underlying EIS. After doing this the PersitenceManager-implementation passes the further handling of created JDO`s to StateManagers for runtime management. PersistenceManager`s itself are created from implementations of the interface PersistenceManagerFactory. These factories contain, reads in from local configuration files or retrieve from other resources, informations about framework details like exact hosts and ports to use and which additional librarys to use etc. Other interfaces found in the JDO specification are omitted here because of it`s weaker importance for an summarizing overview / understanding.

    LINKS/RESOURCES LINKS: SPECIFICATIONS LITERATURE (this list can never be complete ;-)):
        • [HUW2000] Garcia-Molina, Hector; Ullman, Jeffrey D.; Widom, Jennifer : Database System Implementation Prentice Hall 2000, ISBN 0-13-040264-8
        • [SQJ98] SQLJ Standardized by ANSI as X3.135.10-1998
        • [Cod90] E.F. Codd. The relational model for database management : version 2. Addison-Wesley Pub. Inc, 1990
        • [AtM95] M.P.Atkinson and R. Morrison. Orthogonally Persistent Object Systems. VLDB Journal, 4(3), pp319-401, 1995
        • [JoA98] M. Jordan and M. Atkinson. Orthogonal Persistence for Java - A Mid-term Report. Proceedings of the Third International Workshop on Persistence and Java, 1998
        • [ODM00] R.G.G. Cattel et. al. The Object Database Standard ODMG3.0. Morgan Kaufmann Publishers, Inc., San Fancisco, CA, USA, 2000
        • [ODM97] R.G.G. Cattel et. al. The Object Database Standard ODMG2.0. Morgan Kaufmann Publishers, Inc., San Fancisco, CA, USA, 1997
        • [Eic95] André Eickler, Carsten A. Gerlhof and Donald Kossmann. A Performance Evaluation of OID Mapping Techniques. In Proceedings of 21. Intl. Conference on Very Large Data Bases, 1995
        • [StB99] Michael Stonebraker, Paul Brown. Object-Relational DBMSs. Morgan Kaufmann Publ. Inc., San Francisco, CA, USA, 1999
        • C. J. Date, Hugh Darwen Foundation for Future Database Systems: The Third Manifesto, Addison-Wesley 2000 A comparison between the ODMG an the Relational Model
        • Object-Relational Benchmarks
          • S.H. Lee, Kim S.J., Kim W. : The BORD Benchmark for Object-Relational Databases In Proceedings of 11. Intl. Conference on Database and Expert Systems Application (DEXA) 2000, pp. 6-21. in Lecture Notes in Computer Science LNCS 1873, Springer-Verlag, Berlin/Heidelberg 2000, ISBN 3-540-67978-2 (< A HREF="http://dblab.ssu.ac.kr/Publication/00-CS .pdf">00-CS.pdf)
        • Others
          • The Benchmark-Handbook
          • D. Florescu and D. Kossmann (1999) A performance evaluation of alternative mapping schemes for storing XML data in a Relational database. Technical Report No. 3680, INRIA, Le Chesnay Cedex, France, May 1999. (ftp:RR-3680.ps.gz, ftp:RR-3680.pdf)
          • D. Florescu and D. Kossmann (1999) Storing and querying XML data using an RDBMS. IEEE Data Engineering Bulletin. Vol. 22, No. 3, pp. 27-34. (99SEP-CD.pdf)
          • R. Schindler, G. Specht and A. Schmatloch (2001) Performanz von XML-datenbanksystemen. Proceedings of Net.ObjectDays 2001, Erfurt, Germany, 2001 (in German) (specht_schindler_mik2001.pdf)
          • F. Tian, D.J. DeWitt, J. Chen and C. Zhang (????) The design and performance evaluation of alternative XML storage strategies. Submitted for publication. (xmlstore.pdf)
          • B.Y. Zhao (2000) The XSet XML search engine and XBench XML query benchmark. Master's Thesis, Computer Science Division, University of California at Berkeley, May 2000. (msreport.ps.gz, msreport.pdf)
          • B.Y. Zhao and A. Joseph (2000) The XSet XML search engine and XBench XML query benchmark. Technical Report No. UCB/CSD-00-1112, Computer Science Division, University of California at Berkeley, September 2000. CSD-00-1112.ps.gz,
      • Birbeck, Mark et. al.: Professional XML, 2nd Edt., WROX-Press 2001, Birmingham, ISBN 1861005059
      • [Boo94] Grady Booch. Object-Oriented Analysis and Design. 2nd ed. Addison-Wesley Publ., Menlo Park, 1994
      • [Kue97] Ralf Kuenel. Die Java Fibel. Addison Wesley Longman Verlag GmbH, Bonn, 1997
      • [Gam95] Erich Gamma et. al. Design Patterns. Addison-Wesley Pub. Inc., Reading, 1995

    Basis for UF WPI,  Process Mgmgt-Data
    EMarketplaces, ECommerce, EBusiness

    Advanced Analysis/Mining-Query Mechanisms

    REFERENCES use of the UFO-RDB-Modelling-Toolset and runtime-module in:
    • the administration of student-data for the PI1-Excercises at UNI-F
    • the Portal-User-Profil-Implementation of Mr. Markus Ernst`s masterthesis
    • the implementation of the UFX-RDB Datastorage-Adapter


    all rights reserved, CPP, 1998-2009