next up previous
Next: Future Work Up: An Object Oriented Linkbase Previous: Initial Problems

Database Design

 

The database design needed to be as flexible and open as possible, and for this purpose the object oriented approach is very convenient and supportive. For example, the design needed to allow easy inclusion of other media types.

In an open hypermedia system such as Microcosm, we can identify the following elements:

Microcosm has three type of link Generic, Local and Specific. Each anchor has a group of links associated with it.

In Microcosm, information about links is not embedded in the documents and resides in the linkbase. To map these Microcosm concepts onto an object oriented database, we created the following classes:

We can therefore summarise the object oriented model of the database by saying that a node is a class of objects that has a collection of source anchors and a collection of destination anchors. An anchor is a hierarchy of classes that have a collection of links in common. Each subclass of the anchor class has its particularities and new subclasses can easily be created to accommodate new types of anchors and new media. Finally, a link is a class that connects two documents.

As previously mentioned, in an Object Oriented linkbase, every object has a unique identity (OID), that can be referenced any number of times by other objects. Also, in our design a document is defined as an object that has a collection of all its anchors. This poses us with a problem about how to represent the generic link functionality, since it is an object that belongs to all documents that have a given source anchor, independent of the position of the anchor within the document. This gives rase to the following problems: :

We could not accept the identity problem, and also it is not efficient to look for generic links in every single document every time that a generic link is created.

In order to solve this problem, we decided to create the concept of a virtual node. The virtual node is physically an object of type document, like any ordinary node, but it actually represents the whole set of documents referenced in a linkbase. Every time that a generic link command is dispatched, we create a new entry in the set of anchors of this virtual node, with no offset, and a link which has as source node the virtual node, and as destination the node chosen by the user. So, this virtual node can be seen as representing all documents in the database that have generic anchors. It clearly facilitates all queries and simplifies enormously the model.

As we can expect, this virtual document will be requested many times, and will have many more anchors than any other document. To minimise this problem, our index was made in a way, that this document is always the first one to be checked, and the collection of anchors for this node is organised in a different way. The generic source anchors are organised in an index. Associated with each entry in the index there is an OID that points to an object of type generic anchor. It is obvious that there is no need for a collection of destination anchors for a virtual document. Experiments show that this type of organisation for collections is more effective, than the ones used for the rest of the documents, and it is something that can be further optimised in the future. Figure 1 shows an example.

   figure51
Figure 1: Internal Structure of OO Database

The virtual node (VIRTUALDOC in the figure below) contains all the generic anchors made. As we can see from figure 1, it does not mean anything to talk about destination anchors in the virtual node, since it is a virtual entity (there will be no links which have this document as their destination ). For example, suppose that the active version for the application is `1.n' and that the generic anchor "hypermedia" has as its destination the document ANYDEST.DOC (see OID of ANYDEST.DOC in the Index and in the DestOID field of the virtual node's Link Object, whose OID is OIDESTVn). The destination anchor inside ANYDEST.DOC, can easily be found by looking at the field destsel_pos in the Link Object for the virtual node (OID = OIDGENVn). In the example it is "1". So if we look at the Collection of destination anchors for the document ANYDEST.DOC, we can read the anchor object from the OID stored at the first position of this collection (OID = anchOIDD1), and find that the destination anchor is "microcosm" and is located at offset 393. All the links associated with this particular destination anchor are stored in the collection of links of this anchor. It is very easy to find the way back, since, for each link object, the OID of the source document (SourceOID) and destination document (DestOID) are stored. Note the destination link object is not represented in the figure.

But a hypermedia system, such as Microcosm, is not just a set of static concepts. It has dynamic mechanisms that in the object oriented world are mapped through methods. So for each class, methods were defined to represent the behaviour of the objects of a class. Fundamental queries for Microcosm such as Follow Link, Create Link and Find Buttons also have to be considered during the design.

As mentioned before, Exodus is simply a toolkit for building database applications, and although E, as an extension of gnu C++ has some database types available, the same features are not available for the client library. So we had to create the concept of a collection of objects, create methods inside the defined classes to insert an object inside a collection, transform the C++ volatile objects into persistent objects, etc..

A collection, in our implementation, is referenced by a unique OID. Elements of a collection always belong to a certain class and have a known size. To create a new element in a collection we used the Exodus functionality of append (which appends a certain number of bytes to an existing object). In this way the OID of a collection points to a stream of bytes. The boundary between one element and another is determined by the size of the elements. To read a given element of a collection it is necessary to know its position inside the collection, or to read all elements until the required element is found. This approach was taken in order to group all elements of a collection physically closer, since it is probable that access to a collection OID will be followed by accesses to other elements of the collection.

When this first simple design was completed and the concepts of collection and persistence were implemented, we started the codification and tests.

For compatibility purposes, we developed a program that is able to read any flat Microcosm file and store the information as objects inside our linkbase. Also for compatibility purposes, we intend to maintain flat files for all information stored in our linkbase.

During the codification phase, we also realised that although Exodus has the concept of a file as a repository of related objects, it does not offer mechanisms to list and keep track of existing files. So a new class was created to contain the collection of files in the database. In this class we included the name of the file, its description, the concept of the owner of the file, access rights for the owner, users from the owner's group and other users (user group and other user are a UNIX concept). Only the owner of the file can change the access rights. So, the access to the documents will be still controlled by UNIX, but access to links (follow, create links, and other queries) will be controlled by the database. In this way, each user can have their own collection of links, which can be shared by other users. In the world of cooperative applications this facility is crucial. Additionally, due to the design of Microcosm, authors can share more than one link file at the same time, which with the help of some queries can help a lot in cooperative authoring (comparing links to the same selections, verify redundancies, incompatibilities, etc.). As Exodus provides concurrency control mechanism, we don't have to worry about multiples attempt to write to the same information.



next up previous
Next: Future Work Up: An Object Oriented Linkbase Previous: Initial Problems



Fri Dec 8 14:32:43 GMT 1995