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.
ARCHITECTURE /
FEATURES
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)
in L'Objet Scientific Journal Vol.6 no.3 ISSN 1262-1137,
November 2000, Hermes Science Publishing, Paris and Oxford
(PortableDocumentFormat(125kb))
by Priese, Claus Peter note1: because of publication restrictions only a pre-final version of the paper can be provided here for download
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.
[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
RELATIONAL
[Cod90] E.F. Codd. The relational model for database management : version 2. Addison-Wesley Pub. Inc, 1990
PURE OBJECT-ORIENTED
[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
OBJECT-RELATIONAL
[StB99] Michael Stonebraker, Paul Brown. Object-Relational DBMSs. Morgan Kaufmann Publ. Inc., San Francisco, CA, USA, 1999
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)
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,
CSD-00-1112.pdf)
XML-AREA:
Birbeck, Mark et. al.: Professional XML, 2nd Edt., WROX-Press 2001, Birmingham, ISBN 1861005059
VARIOUS AREAS:
[Boo94] Grady Booch. Object-Oriented Analysis and Design. 2nd ed. Addison-Wesley Publ., Menlo Park, 1994
