Current Prototype

Current Prototype

This section of the website documents the development of the RAQUEL DBMS as it evolves from a prototype towards a usable product.

The RAQUEL DBMS always needs a so-called 'Driver Application' to give it statements to execute and to receive the results of executing the statements. Therefore the current prototype is provided with a RAQUEL GUI / Teaching Tool as a Driver Application. It may be downloaded from SourceForge along with the DBMS. See the menu option "Home Page / Demonstration Prototype" for details of downloading, and menu option "Applications" for details of the Teaching Tool application.

The two main menu options "RAQUEL the Language" and "RAQUEL the Architecture" describe the specification and design, together with proposed future developments, of the RAQUEL notation and RAQUEL DBMS architecture respectively. However much of this is not yet reflected in the prototype. Hence the need to cover the development of the prototype as it evolves towards meeting these requirements, i.e. it covers implementation concerns.

Descriptions of the DBMS implementation of architectural aspects will be provided in this section, with links to the relevant items of the "Raquel the Architecture" menu where appropriate. Descriptions of low-level aspects of the implementation will be held on the SourceForge website, with links between the 2 sets of descriptions. Of course some low-level aspects will be described in comment statements in the program code.

The current prototype DBMS is still essentially the 'Proof of Concept' prototype, due to the considerable amount of work carried out since its creation to develop the specification and design of the DBMS and the RAQUEL notation it executes. Further development of the DBMS implementation is currently in progress. A revised and modernised set of GNU Autotool files has been developed and is now provided to make it easy to download and install the DBMS (& also the Teaching Tool) on a variety of Unix/Linux computer systems.

The 'Proof of Concept' Prototype

In producing a truly relational database management system (= DBMS), the RAQUEL project has two aims : that the DBMS execute the RAQUEL notation, and that the DBMS have an Open Architecture.

The Proof of Concept prototype attempts to illustrate both these aspects. The tight constraints imposed by being a prototype, especially considering that a fully fledged DBMS is a large software product, resulted in the prototype being more successful in demonstrating the execution of RAQUEL than in demonstrating an Open Architecture. Given that the architecture of the prototype is less obvious to a user than the language it executes, this was a good balance to strike. Note that inevitably the purpose of the prototype is to illustrate ideas – it is not a working DBMS.

A strength of the prototype is that it expresses an interesting subset of RAQUEL, in particular a complete range of 12 join operators. Between them, the 12 provide all the different kinds of joins found in relational theory. As far as is known, no other relational system explicitly provides all 12 (although workarounds may provide them indirectly). Cartesian Product is additionally provided by applying a join operator appropriately.
A small set of other relational operators and assignments are also provided. See the menu option "Home Page / Demonstration Prototype" for details.

The sub-menu option "Proof of Concept Prototype" provides implementation information.

Development of the Specification & Design

The implementation of the prototype showed that there was insufficient specification and design of both the RAQUEL notation and the DBMS, at the more detailed level and in terms of the principles to be applied. Given the relatively large size of a DBMS, additional documentation would be needed to ensure that the software developers would be given the necessary clarity to implement the DBMS effectively.

To achieve this, the documents written covered 4 key topics (in addition to several minor topics) :

  1. It was realised that the implementation had to incorporate not only the Relational Model (as defined in "The Third Manifesto") but also a DB Model.
    The DB Model specified was the traditional ANSI-SPARC 3-layer model, but extended with further layers and schemas to expand Physical Data Independence to include :
            • Configuration Independence - the relational values physically stored may be those of fragments and/or merges of DB relvars.
            • Location Independence - relational values may be stored in a variety of locations, including multiple locations.
            • The traditional Physical Independence - relational values storable using a variety of different physical storage mechanisms and methods.
    To support this, the RAQUEL notation was expanded to include a set of DB Schema assignments and operators that would support a DB built on the extended ANSI-SPARC architecture.
            See the menu option "Raquel the Language / The ANSI-SPARC Database Architecture" for details.
  1. The concepts embodied in RAQUEL should maximise the ratio of functionality provided to the user compared to the conceptual complexity to be learnt by the user. Maximising the ratio was achieved by designing the language to :
            • employ the minimum number of concepts,
            • ensure the concepts are straightforward,
            • generalise the concepts so that they have no exceptions,
            • make the concepts orthogonal to each other so that they can be applied in combination.
    As a consequence, the RAQUEL notation consists only of operator expressions and assignment expressions, and these apply uniformly at the relational, scalar, and DB Schema levels. Also the language syntax presents similar concepts in similar ways, and different concepts in different ways.
            See the menu option "Raquel the Language / A Description of RAQUEL" for details.
  1. To ensure the relational model was fully and precisely defined, a mathematical specification of relational values and variables, relational operators, and relational assignments was produced. The operators and assignments are specified in terms of pre and post conditions. The overall style of the specifications was derived from that of Z Schema Calculus, although to make them easier to read, the Schema Calculus per se is omitted; the specification restricts itself to the use of predicate calculus.
            In the course of this work, it was realised that the Generalised Divide operator could be considered as a form of Join operator, viz. a Join whose relational operands are partitioned into sets of relational sub-values, which then undergo a Cartesian Product of set comparisons (c.f. a Cartesian Product of scalar comparisons in a traditional Natural or Generalised Join). The set comparison to be applied would be given as a parameter, and the comparison would apply to the projection of the common attributes of the relational sub-values (c.f. the scalar comparison of the common attribute values in a Natural Join). Thus the Divide operator may be seen as a Set-Join operator.
            The Set-Join was then generalised to include Semi Join and Outer Join versions in just the same way that the traditional Natural Join and Generalised Join operators may be so generalised.
            For details, go the menu option "Raquel the Language / A Description of RAQUEL / The Semantics of RAQUEL" and look at the documentation for "The Relational Level of Abstraction", in particular section "2(b). Relational Operators".
  1. Because of the scale of a DBMS product, it was deemed important to maximise the simplicity of its implementation. Therefore it was decided to adopt 2 approaches in developing the prototype :
            1. Try to implement the ideas put forward in the paper "Out of the Tar Pit" by Ben Moseley & Peter Marks. In essence they aim to minimise the number of possible states that the system can be in by using 3 approaches to implementation :
                    • Implement as much as possible of the system as functions, since functions avoid states and side effects.
                    • Use OO classes to provide Data Types.
                  • Do not design for performance but make the design as logically simple as possible. If performance-enhancing code is needed, try to keep the 'essential' code (inherent to the nature of the product) separate from the 'accidental' code (needed to enhance performance). The terms 'essence' and 'accident' stem from Aristotle's philosophical approach as originally applied in Fred Brooks' paper "No Silver Bullet - Essence & Accident in Software Engineering".
            2. Given the above emphasis on the use of functions, and the fact that the RAQUEL notation only uses operators (which are mathematical functions) and assignments (which can be composed together like operators), try to implement the DBMS in a way that reflects the conceptual approach of the RAQUEL notation.
                If the RAQUEL notation and its implementation both reflect the same body of ideas and philosophy, it simplifies the translation of conceptual thinking when moving between them, thereby minimising confusion and errors and maximising productivity.
                Thus as far as possible, code wiil be in the form of functions, assignments, and data types (in the most general sense). In practice 'sandbox' code (i.e. code that provides a safe environment in which the other forms of code execute) is also likely to be necessary.
                For details, go the menu option "Raquel the Architecture / Architecture / Physical Architecture" and look at sections "3. Out of the Tar Pit" and "4. Conclusion : the Design of the Functional Modules".

Developing the Prototype

The strategy for for developing the prototype is significantly different from that used to create the prototype, because the latter used pure Object-Oriented programming.

The prototype will need extensive re-factoring to change its architecture to that proposed. However such re-factoring would take considerable time without adding any functionality. Increases in functionality are thought to be more attractive than re-factoring to those potentially interested in the project. Therefore it has been decided to re-factor and extend the prototype in a sequence of small increments. Each increment should re-factor a small part of the DBMS, and then extend it to increase its functionality.

As the current prototype lacks the functionality to create and remove relvars from a DB, and since this is a very basic requirement (!), the next 'increment' is to provide the means to do this.
RAQUEL provides the flexibility to create a real (or base) relvar by assigning a Relational Type, a set of Candidate Keys, or one or more 'Ad Hoc' Constraints to the name of the new relvar. These properties may be assigned in any order, and relational values assigned to the relvar as soon as a requisite set of properties has been assigned to make this logically possible. Since it would not be easy to provide the DBMS with the means to apply 'Ad Hoc' Constraints, the intent is only to allow relvars to be created by assigning a Relational Type or a set of Candidate Keys to them. This still provides sufficient flexibility to make the 'increment' interesting.
By contrast, there is no requirement for flexibility when relvars are removed.
Therefore in terms of the RAQUEL notation, the 'increment' requires the implementation of the <==Attribute, <==Key and <--Remove assignments.