«OBJECT DATABASES AND THE SEMANTIC WEB A THESIS SUBMITTED IN FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF DOCTOR OF PHILOSOPHY. ING. JAKUB ...»
Structured Object types predefined by the ODMG specification correspond to the INCITS SQL standard. They are Date, Time, Interval and Timestamp, including operations on them.
Subtyping and Inheritance. In subtyping hierarchies, all instances of a type also have the type of all its supertypes. Subtypes share the supertypes’ state and behavior signatures, and can be used in their place. Behavior and state of a subtype can be added or specialized (overloading and late binding are supported). The subtyping relationship is transitive.
There are two kinds of subtyping relationships in ODMG — inheritance and extension. Multiple inheritance is supported for sharing abstract behavior of interfaces, while only single extension relationship for a given object type allows to share both abstract behavior and state (see Figure 3.2).
Figure 3.3 The full ODMG built-in type hierarchy (abstract classes italicized) Literals.
Literals do not have unique identifiers, therefore they cannot be referenced and have to be embedded in objects. ODMG supports atomic, collection and structured literal types with characteristics similar to object types. Atomic literal types include types like numbers and characters, and an enumeration type generator enum. New structured literal types can be defined Semantic Web as an Object-oriented Database 10 using the struct generator. They contain a fixed number of variables with either a literal value or an object, and can be freely composed. For an overview of specific types, see the type hierarchy in Figure 3.3).
Comparison of Literals. Literals cannot be compared on the basis of identity using the same_as() operation; instead, the equals() operation compares them by value and type.
Extents and keys. Extent is the set of all instances of a given type (and its subtypes). The database designer decides which types should have extents and which extents should be indexed.
The value of a key is unique within an extent. Simple key corresponds to a single property, while a compound key is a set of properties.
Metadata. The ODL Schema Repository stores persistent objects that define the schema of an ODMS. The ODMG metadata model describes the class assignments for this data — types like TypeDefinition, Property and Interface.
PROPERTIES AND OPERATIONSAttributes. The two kinds of properties defined by ODMG are attributes and relationships.
Every attribute has a name and type and its value is either a literal or an OID. Attribute definitions in interfaces only define abstract behavior and a class can implement such interface either by a data member or by a pair of accessor methods.
Relationships are always defined between two object types using two inverse traversal paths — either simple or collection ones. This allows the creation of 1:1, 1:N and M:N relationships like in the below example of a child owning toys. The ODMS is responsible for maintaining referential integrity of relationships, but not object-valued attributes. Relationship definitions in interfaces are purely procedural.
Operations specify behavior of a single type using signatures with typed arguments and returned value, and any exceptions the operation may raise. ODMG does not define formal semantics of operations and it assumes their sequential execution. Operations may have side effects.
OBJECTSObject Creation. Objects are created by invoking the new() operation on an ObjectFactory interface. Every object must implement methods for copying, deleting, equality comparison and locking. All creation, access, modification, and deletion of persistent objects must be done within the scope of a transaction.
Semantic Web as an Object-oriented Database 11 Object Identifiers (OIDs) are automatically assigned to all objects, are unique within the scope of a given ODMS1, and are immutable. They keep object identity through updates and connect objects in relationships.
Object Names have the role of global OODB variables — any object can get a name for direct access to its data. Name definitions are independent of type interfaces. Named objects are identical with the notion of “root objects” or “entry points” in the database.
Object Lifetimes. Objects can be either persistent or transient. Transient objects are managed by programming language runtime system and they only exist for the duration of a procedure, a thread or a process. Persistent objects are managed by ODMS runtime environment and they survive the termination of the process that created them. Object lifetime is orthogonal to its type — some instances of a type may be transient and others persistent.
This overview of the ODMG object model does not include the exception system, locking and concurrency control, transaction services and operations for managing the whole database.
3.2.3 STATE OF THE ART AND IMPLEMENTATIONSThe ODMG standard started with version 1.0 in 1993, evolved in four releases to its final version 3.0 of 1999, and in 2001, the activity of ODMG was suspended. Some of its critics pointed out that the standard was designed by several object database vendors without regard to implementations on top of relational databases; others claim that it was not flexible enough (for example, it lacked support for multiple inheritance). ODMG also did not provide a test suite to verify implementation correctness, so differences in behavior of ODMG-compliant products became quite common. Not many OODB products came close to implementing the full specification, but some that strove to accomplish this were FastObjects, Poet, Jasmine, GemStone, Objectivity, and Versant.
3.2.4 SOURCES The official site of the former ODMG activity is at http://www.odmg.org/. A book that contains the latest ODMG standard is [CB00], and an overview ODMG shortcomings and its comparison with JDO can be found at http://www.jdocentral.com/JDO_Commentary_DavidJordan_4.html.
3.3 JAVA DATA OBJECTS — JDO
WHY WAS IT CHOSENJDO supersedes the ODMG standard in the Java world. It was shaped by a community process and it takes into account many recent advances in the field of IT (like three-tier applications, component architectures, or ubiquitous computing). It has gained wide acceptance and is being implemented and used in a wide range of solutions, including a number of object-oriented and object-relational databases.
Object Data Management System Semantic Web as an Object-oriented Database 12
INTRODUCTIONThe Java programming language has had two standard means of persisting objects — object serialization and JDBC (Java Database Connectivity). However, serialization is a simple mechanism that does not support transactions and queries, and JDBC is only useful with relational databases that support SQL.
In 1999, a task force was formed within the Java Community Process to specify a Java-centric model of persistent information. The Specification Request (JSR12) was approved in July 1999, official JDO
1.0 standard followed in March 2002, and the current release is JDO 1.0.1 from March 2003.
The two major objectives of the JDO architecture are:
First, to provide application programmers with a transparent, Java-centric view of persistent information, including both enterprise and locally stored data Second, to allow pluggable implementations of datastores into application servers. Data from these datastores is presented in the Java Virtual Machine as instances of persistent classes.
JDO defines interfaces and classes for application programmers when using objects that are to be stored in persistent storage, and specifies the contracts between suppliers of persistence-capable (P-C) classes and the runtime environment (which is part of the JDO Implementation).
JDO also defines a query language JDOQL (JDO Query Language) that is similar to OQL, but simpler.
It allows the execution of database queries in the form of simple function calls that specify the set of queried objects and a boolean condition (filter). These queries are internally translated to datastore query languages (like SQL). JDOQL is allowed to violate encapsulation and query private object state because no method calls (including calls to accessor functions) are allowed in queries.
JDO can run in a variety of environments ranging from three-tier application server architectures (EJB) and two-tier client-server environments to limited capability devices like cellular phones.
3.3.2 USING JDO The JDO persistent object model of an application is determined by a set of Java classes and an XML metadata file. The XML metadata file contains modeling directives that either override the default semantics of the Java language or provide additional semantics not expressible in Java, thus augmenting it to get a full object DDL (data definition language).
Every P-C application class must be listed in the metadata file. Every P-C class must also be enhanced for processing by JDO – the most common approach is to use an enhancer that generates enhanced class files. One of the changes made to these classes is that they implement the PersistenceCapable interface. Most classes can be made persistent, except ones whose state depends on remote objects or is not accessible to Java (like classes that use Java Native Interface or most system-defined classes).
Every JDO datastore then provides the programmer with a PersistenceManagerFactory object that instantiates a PersistenceManager. This interface embodies the database connection, manages the object cache and acts as a factory for other JDO classes like Transaction and Query.
Object types. JDO supports the persistence of these types of fields: Class types include any P-C user-defined classes or interfaces. Atomic types correspond to Java ones, including Date, Locale and String. Collection types include arrays of values or references, plus standard Java collection interfaces and classes (maps, sets, lists, arrays, vectors, hashes, and trees). However, only HashMap is mandatory for all JDO implementations since some relational databases do not support richer schema semantics.
Inheritance. In standard Java (single) inheritance hierarchies, any class can be made transient or persistent, but in the latter case, its immediate superclass must be explicitly mentioned in the XML metadata file. By default, all classes are transient.
Objects and Literals. JDO has two types of persistent objects — First Class Objects (FCO) and Second Class Objects (SCO). Every FCO has a unique JDO identifier — it can be referenced by all other persistent instances. In contrast, a SCO has no identity and is either embedded in each of its “parent” objects at commit time, or is unowned and lost at commit time. SCO are defined in the metadata file for fields that reference objects, not for whole classes, which can result in some instances of a class being FCO and others SCO.
Extents. Every P-C class can optionally have an extent that contains a collection of all its persistent instances. A class that uses the makePersistent method must have an extent.
Metadata. The underlying Java object model supplies the programmer with a reflection mechanism — metamodel information and tools for its manipulation.
Attributes and Relationships. In OODB terminology, FCO correspond to objects and SCO to literals. If the field references an FCO, a relationship is created, while for an SCO, the whole attribute is embedded. Arrays are always SCO and facilitate the creation of 1:N relationships.
Treatment of null values depends on XML metadata information:
None means that null fields are saved as null fields, unless the database has no support for them;
in such case, an exception is thrown.
Exception specifies that an exception be thrown each time a null field appears at transaction commit time.
Default value of the attribute leaves the treatment of null fields to the database – they are converted to whatever default value the database uses for null values of the given type.
Operations. JDO only works with the state of P-C class instances, not their behavior. The behavior has to be implemented in business classes that manipulate and query persistent JDO instances.