Facets Concepts

Facets has all of the features of a Java ODBMS, but extends some of them in ways that make it more powerful and flexible than either an ODBMS or an RDBMS which means it approaches the storage of persistent objects in a different way to that of a traditional relational database. Some systems that call themselves ODBMSs are in fact Object-Relational Databases, that is, they contain extensions to relational technology to assist them in handling object based data. This means that their approach is inherently tabular and they merely have fancy mechanisms for squishing objects into tables in some way. Facets does not do this, Facets understands objects and treats them as first class citizens.

Objects are not flattened

Often the approach taken to storing objects is that of serialization or flattening.

Serialization involves the streaming of an object, instance variable by instance variable into some sort of sequential byte container, and then storing the resultant BLOB (binary large object) either in a file or in a field in a relational database. While this appraoch works, the inherent nature of the process means that the nature of the object is lost while it is in storage, since it has been transformed from an object into a sequence of bytes.

Flattening on the other hand, involves breaking an object down into it's most primitive components and then storing these components in columns in a relational database table. Once again the inherent nature of the object has been changed during storage. It is no longer an object, but a collection of parts that make up an object spread out over a number of tables or files.

Facets neither serializes nor flattens objects, it takes them as whole objects, along with the objects they contain and moves them as whole objects onto disk and back again as required. Naturally the process is not as simple as this. When an object becomes persistent, Facets takes the object, and all objects than can be reached by following all the references to other objects contained in the primary object and it moves them into a portion of memory that can be rapidly paged to or from disk. The objects are not flattened or serialized, but merely moved around whole in memory. They still retain their fundamental identity as objects.

Figure : RDBMS versus Facets handling of Objects

This approach has considerable advantages in that

• objects do not need to be decomposed prior to storage
• objects do not need to be recomposed after storage
• moving pages of objects in and out of memory is vastly more efficient that moving objects around piecemeal
• efficiencies are gained due to referenced objects being located on the same page as the referring object
• objects retain their identity and form even while in storage

There is no need for SQL

Because Facets stores objects as objects, and it can store the most complex tree of objects as is, there is no need to write complex SQL queries to either store objects away or retrieve them. Unlike other Java persistence technologies there is no requirement to annotate classes so that the persistence mechanism can understand how to store or retrieve them. All the information required to successfully persist objects is stored in the class of the object after all, and therefore Facets makes use of this information to figure how and where to store the objects.

Not having to use SQL or annotation techniques is a huge boon to programmer productivity and to hierarchy designers. It is no longer necessary to consider how one is going fit the objects into a file or table, since Facets does not require such mechanisms but merely stores and retrieves objects as they are. This reduction in complexity and effort translates directly into increased programmer productivity and better design.

Facets does however have a query language that is based on SQL, and this can be used to query the database when name based object location and navigation is not sufficient to the programmers purpose. While this query language is available it is almost never necessary to use it.

Hierarchies no longer have to be simple

How often in the past when designing a class hierarchy have you found yourself simplifying the hiearchy or the containment relationships in your design because you were concerned about having to store the objects in a table or tables ? This sort of design compromise has become commonplace because of the limitations imposed on storing object based data in relational databases. Fortunately with Facets, there are no such limitations. This means that your designs can be as simple or as complex as necessary to solve your business problems. Facets works with you to solve your design problems, it does not add to them.

Identities and Relationships

One of the things that characterizes object based programming from other techniques is the containment of objects by other objects (such as in collections of objects) and the reference of one object by another (such as when one object uses another object to perform tasks for it). These relationships between objects are often lost when objects are persisted by non object based mechanisms such as relational databases. Often complex mechanisms using shared keys are used to store these relationships. In Facets, all containment and other types of relationships are maintained transparently by Facets, when objects are persisted. This means there is no need to give objects keys, and then remap the relationships using these keys after objects are retrieved or even during the retrieval process. Object identity is preserved automatically by Facets.