RAQUEL the Architecture

RAQUEL the Architecture

The design of the RAQUEL Database Management System (= DBMS) is aimed at meeting 2 goals :

  1. To execute all valid RAQUEL statements and return a valid response for each one, and to return relevant error responses to all invalid RAQUEL statements.
  2. To enable RAQUEL DBMS installations to have the maximum possible variety of possible configurations, so that any given installation may not only be tailored to meet the precise needs of its current users but may also evolve easily to meet their changing future requirements.

The first design goal is self evident.
The second is what motivates the design of "RAQUEL the Architecture".

The long-term aim is that the DBMS be able to support DBs that hold a variety of different kinds of data, in very varying volumes, for a variety of purposes, in a variety of situations, and meeting a variety of different performance needs. This is considered worthwhile because the usage of computers to store data is now ubiquitous. However many data stores are not held in DBs; many use DBMSs specialised for certain purposes whose speciality thereby limits the scope of usage for their DBs. Both kinds of data stores lack a general purpose DBMS that would allow their data to be fully exploited, and which a fully relational DBMS can provide.

To meet the second design aim, the RAQUEL DBMS must be very flexibly configurable. It must be the very antithesis of traditional "black box" DBMSs, which are typically aimed at meeting one of a few traditional business computing needs, such as a PC database, an ‘Enterprise’ database, or a data warehousing database. The user has limited control over the contents of their chosen box, which may be very bloated, having been expanded over many years to make it “all things to all men”.

The RAQUEL DBMS is designed to have an Open Architecture, that enables flexible installations by supporting a modular, building block construction that utilises diferent plug-ins. The installation can easily be varied by choosing different and/or additional modules. It can thereby support a variety of different kinds and volumes of data for a variety of purposes. It can easily scale between PCs, networked servers, mainframe computers, computer grids and any future computing architectures, in order to support different situations and performance requirements. From the user’s perspective, the same simple but highly functional RAQUEL notation is presented with every architecture, but the computing power beneath it can be varied to meet requirements.

An Open Architecture does not constrain the database system into a fixed ‘shape’ which might turn out to be limiting in future. It allows a particular DBMS installation to be tailored to suit the specific business requirements; and enables the installation to evolve over time. Installation software ensures that the tailoring is simple and straightforward.

The functionality of the DBMS is derived from the 2 sets of modules it contains, core modules, and plug-in modules :

Core Modules
These modules provide the bulk of the DBMS functionality. They provide the functionality expressed by the RAQUEL Logical Relational Model and the Physical Storage Model, supported by a range of DB system functionality often needed in practice, e.g. resilience, user concurrency, performance, security, etc.
Plug-In Modules
There are 2 sets of plug-in modules to supplement the core modules. One set handles the processing of the scalar values held in relations, there being one plug-in module per primitive scalar data type. The other set handles the physical storage of data, there being one plug-in module for each kind of physical storage mechanism (e.g. BTree files, Hash files).
Any particular DBMS installation would plug in the required modules from each set.

A RAQUEL DBMS installation may vary the core modules it contains in order to tailor the DBMS functionality to its needs. It may add, amend and/or delete modules. For example, it may remove functionality not needed for a single-user DB so as to improve performance, or add specialised modules to provide encryption or distributed data storage.

There is no constraint on the range of scalar data type software that can be plugged in. Although proprietary systems allow plug-ins for data types, the plug-ins are constrained by the "black box" interface and what the vendor chooses to reveal about it, whereas an open architecture has far more potential. It is the means by which any RAQUEL DBMS installation can be tailored to have just those scalar types that it needs, be they common or specially devised types.

Likewise there is no constraint on the range of physical storage methods that can be plugged in. Any kind of storage method can be used, in addition to the normal ones. For example, a special kind of file generated by an application (e.g. a spreadsheet), or another database systems (RAQUEL or non-RAQUEL); the latter also facilitates the migration of data from such systems to the RAQUEL system. In contrast the "black box" approach provides only what the vendor deems is a sufficient choice.

The Open Architecture is an extension of the Open Source philosophy in that just as Open Source facilitates software modules being re-developed as required, so Open Architecture facilitates the reconfiguration of the database system modules to most effectively meet user needs.

The Open Architecture also makes it easier for external contributions of modules to be incorporated into the RAQUEL DBMS; and for users to include specialist modules of their choice or creation within the DBMS so as to tune the DBMS to their particular needs with the minimum of effort.