DBMS ConteXt.

Architecture

Structure of database

The fundamental unit of information storage of ConteXt is a CLASS. The term CLASS in ConteXt database corresponds with the term TABLE in relational databases, as well as an OBJECT corresponds with the term RECORD. Class contants METHODS and a collection of Objects. Object conains FIELDS and PROPERTY. The field may be composite, in this case the field contains SUBFIELDs etc. The property is a set of fields that belongs to particular Object. In other words, Fields are permanent part but property is a variable part of the Object. The header of the Class stores the SCHEMA of Object. The Schema represents the description of the internal structure of the Object, which includes the description of each field, such as their type and name.

Types of fields

An ConteXt database comprises three main data types: REGULAR, VIRTUAL and REFERENCE. A regular (local) field can be ATOMIC or COMPOSITE. The atomic field has no inner structure. In contrast, a composite field may have a complex structure. The composite fields are divided into STATIC and DYNAMIC. The type of a static composite field is stored in the Schema of Class and is permanent. Description of the type of a dynamic composite field is stored within the OBJECT and can vary from Object to Object.

Like a NETWORK database, apart from the fields containing the information directly, ConteXt has fields storing a place where this information can be found, i.e. POINTER (link, reference) which can point to an Object in this or other Class. Because main addressed unit of ConteXt is an Object, the link is made to an Object of Class instead of to a field of this Object. The pointers are divided on STATIC and DYNAMIC. The same field in different Objects that belong to a particular static pointer type point to the same Class (subClass). In this case, the subClass name is an integral part of the that pointer type. A dynamic pointer type describes pointers that may refer to different Classes in different Objects. The Class, which may be linked through a pointer, can reside on the same or any other computer on the local area network. There is no hierarchy between Classes and the pointer can link to any Class, including its own (albeit, possibly, to different Objects).

A ConteXt database that does not have composite or pointer fields is essentially RELATIONAL. With static composite and pointer fields, ConteXt database become OBJECT-ORIENTED. With dynamic composite fields, a ConteXt database becomes what is now known as a SEMISTRUCTURED database. In contrast to Object-oriented databases, ConteXt doesn't support methods directly. Instead, method invocation is partially supported through the concept of VIRTUAL fields.

A VIRTUAL field is like a regular field: it can be read or written into. However, this field is not physically stored in the Class, and in it does not have a type described in the Schema. A read operation on a virtual field is intercepted by the DBMS, which invokes a METHOD of Class associated with the field and the result produced by that method is returned. If no method is defined for the virtual field, the field will be blank. The METHODS is a subroutines written in C++ by an application programmer. Such a subroutine can access to any other fields included virtuals. Similarly, a write operation on a virtual field invokes an appropriate method, which can change the value of the field. The current value of virtual fields is maintained by a run-time process; it is not preserved between sessions.

Queries and other operations (such as sorting) create ARRAY of POINTERS to OBJECTS. This differs from relational DBMSs in which such operations would result in creation of a new TABLE, but this is similar to object-oriented databases, in which queries return COLLECTION of OBJECTS.

Structure of DBMS

The DBMS ConteXt consists of the DATA STORAGE, DATABASE ENGINE and DATABASE BROWSER (DB-browser). The database engine and DB-browser can be used separately. Both the database engine and DB-browser have a direct access to the information stored on the hard drive. If the requested information is stored on another computer the request will be routed to a remote database server.

The DATABASE BROWSER utility is an important part of DBMS ConteXt. The DB-browser fulfills functions of an individual database engine, serving one user and providing an interface to the database. Database engine is used only to process remote requests or for serving of stand-alone applications. Development of applications directly interacting with the database engine is not required. The DB browser is highly capable and is able to support many applications without the use of programming. Every new session creates a new copy of the DB-browser and opens up a window that allows to access the database. Access to the DB-browser is possible from any computer on the Internet as long as that computer has a WEB-browser with Java support. Having a universal database browser allows to significantly reduce the development time for database applications.

Questions or comments? Send a letter to info@unixspace.com

DBMS ConteXt: Front Page