DBMS ConteXt

Introduction

Most of the DBMS currently in use were developed in 1970-ies and 1980-ies. They are mostly oriented towards financial applications, typically employing relational data model and client-server architecture. Generally, they execute transactions, i.e. operations initiated by user and performed automatically by application software. Consequently, all user actions are restricted by rigid interface imposed by the particular application. Database structure and data processing techniques are similar to those of pre-computer era. This may be quite suitable for most financial applications as well as for storing various text documents, although it is not necessarily convenient for the application programmers. Normally the latter have to use an intermediate data manipulation language, such as SQL. To make things even more complicated, data type restrictions cause a lot of data type conversion needed to accommodate for different data representations in databases and application software. As another result of that, users cannot directly work with the database and have to be limited by the application system (users who can talk SQL are very rare to take them into account).

Another approach appeared about 10 years ago, when object-oriented programming languages came into fashion. Object-oriented databases allow programmers to define any needed data types. They store objects and methods rather than records and fields. They make life much easier for the application programmers since no intermediate data manipulation language is necessary. From the other hand, object-oriented databases themselves are even more difficult to work with for the end users that pay the money after all. To make them happy, application programmers have to work even harder on the user interface. Consequently, the development time increases.


Features

The ConteXt DBMS is built on a slightly different set of ideas. ConteXt was developed in mid-nineties for small to medium size companies, not banks or other large financial organizations. The objective was to facilitate user's interaction with the database rather than transaction processing. In other words, operations like data input, search and visualization were given high priority. To cut the user interface development efforts, ConteXt has a universal database browser, similar to a Web browser. The database browser displays data in a set of forms, each form resembling a Web page. Like Web browsers, the database browser has some inherent functionality. It also can invoke specific external programs to perform calculations and operations needed for the particular application. Forms are flexible in a sense that they can be different for each record and even change depending on the record information.
See also: Architecture of DBMS ConteXt

Application developers know that enterprise databases tend to include a significant amount of overlapping data. A typical relational solution of this problem would involve yet another table creation, together with primary key and corresponding indexing mechanism, so that other tables could refer to that data using secondary keys. In ConteXt, a decision has been made to implement a reference (POINTER) data type instead. A reference field contains a record number from another file (table). That renders unnecessary both key creation and potentially time-consuming search in order to get the related info from the sub-table. This is achieved because the reference data points exactly where the data we are looking for are located. Sub-table does not even "know" about those references. The only integrity constraint is that deleting records from a sub-table can ruin somebody's references. This is similar to pointers in C programming language. ConteXt references are one-way pointers, so it is easy to develop complex evolutionary tables bottom up. Obviously, database hierarchy is relative in a sense that each table can contain references to itself, down and up all the way to the top table.

Another ConteXt idea, complex fields or structures, has been borrowed from C as well. Typically, most information stored in a database is inherently hierarchical. For example, a business day of a convenience store consists of three shifts, and each shift has its own data on income, expenditures and taxes. Taxes, for Canada, consists of GST and PST etc. In ConteXt, this kind of hierarchical structure is built in the field itself - no multiple tables needed. Users does not need to know about that, but for the application programmer this data model can be much easier to work with. Since data are stored in the database directly in their binary representation, application software gets all it needs in a complete and easy to digest form right after reading the upper level structure. This may be not an object in a classical sense of the word, but something very much similar.

With time, ConteXt evolved to include non-static references and fields. Non-static reference (VARIANT) can point from different records to different tables, whereas non-static field (COMPLEX) structure can depend on other fields values. Non-static fields can be completely controlled by the application developer, quite in object-oriented style. This makes some people say that ConteXt is an object-oriented database, although others objects that it is not - depending on how strict their definition of object-oriented database is. Strictly speaking, ConteXt has elements of hierarchical, network and relational data model, but differs from either of them. Apparently, it is object-oriented after all.

The completed description of the data types you can find here: Data Types.


Implementation

At present, ConteXt is used in two typical ways. First, information systems for small and medium-sized businesses. The advantage of ready-to-use database browser and rapid application development are major factors here, since both contribute to overall low system cost. Second, complex datawarehouses. This kind of systems benefits from ConteXt flexible data model and reference mechanism, which make it easy to create complex data structures. ConteXt can be also recommended for multiuser systems with remote (e.g. Internet) access, for systems which require ad-hoc requests and visualization etc. The most significant advantages of the DBMS are open network data structure, object data types and the Internet-ready database browser.

DBMS ConteXt front page: DBMS ConteXt

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