Architectural Overview

The Rel server is constructed from several major components:

A running Rel server listens on a communications channel (implemented as a socket) for incoming requests for connections from clients. Each new client connection establishes a new session inside the Rel engine. Each session is an independent entity, sharing only relvars with other running sessions.

The simple DBrowser client bundled with Rel permits immediate evaluation of expressions on a Rel server. For example:

3 + 4

Produces the following result:

7

Responses generated by the Rel engine are presented using Tutorial D syntax where appropriate. For example, entering the following literal relation:

RELATION {TUPLE {x 1, y "fish"}, TUPLE {x 2, y "zap"}}

Produces the following response:

RELATION {x INTEGER, y CHAR} {
	TUPLE {x 1, y "fish"},
	TUPLE {x 2, y "zap"}}

Similarly, executing a relational expression:

RELATION {TUPLE {x 1}} UNION RELATION {TUPLE {x 2}}

Produces the following response:

RELATION {x INTEGER} {
	TUPLE {x 1},
	TUPLE {x 2}}

The use of Tutorial D syntax in responses is consistent and intuitive, and it means sophisticated clients may employ a parser based on a subset of the Tutorial D server grammar, rather than having to design and implement a separate result parser. In the future, this approach will be used to develop a client API that conforms to a JDBC (Java Data Base Connectivity) standard. This will allow Rel to be used by any Java application that supports JDBC, as long as the application does not require SQL syntax. Obviously, this may be extended to ODBC (Open Data Base Connectivity) as well.

The use of the same syntax for data input and results also has value in an educational or development setting, as raw output from the server may be fed as input back into the server.

Rel recognises Tutorial D constructs as specified in The Third Manifesto, plus alternative syntax shown in Date's "An Introduction to Database Systems," except for syntax features that are not yet implemented and which are noted under "Current Limitations and Work in Progress," below. For example, a real relvar may be defined either as:

VAR myRelVar REAL RELATION ...

...or...

VAR myRelVar BASE RELATION ...

The former is The Third Manifesto syntax, the latter is "An Introduction to Database Systems" syntax.

Rel is implemented as a Java application, and should run on any host that supports a J2SE 7.x platform. It has been extensively tested on Linux, Mac OS X and various versions of Microsoft Windows including Windows 8.1.

Java was chosen for two reasons:

  1. It is cross platform, obviating the need to recompile for various platforms and environments.
  2. Java's automated memory management allows development effort to focus on the problem domain without having to deal with hazardous materials, jagged edges, and unsafe working conditions such as memory leaks, pointers to deleted or freed objects, references vs. pointers, and object ownership issues -- at least not to the same degree required with (for example) C and C++.

The provided software distribution consists of two Java applications: a Rel database server and the interactive client called DBrowser. The DBrowser client sends user-entered Tutoral D code and expressions to the Rel server, which in turn parses and executes them and returns the results to DBrowser for display. Rel is multi-user, and will service multiple DBrowser sessions on the local host and other hosts via a network. For convenience, if there is no Rel server running when DBrowser is started, it will automatically start up a local Rel server. This eliminates the need to explicitly load a server before using the client.