Button 0Button 1Button 2Button 3Button 4Button 5Button 6

Table of Contents

Back to main page.


Welcome to LEAP. This file contains documentation on the functionality that is available in version 1.2 (or higher) of LEAP. Consult the README file in the src directory for information on compiling LEAP, it is assumed you have a working, compiled version. A list of frequently asked questions, (and answers!) is available in the LEAP FAQ, which is included in the standard distribution, and at: http://leap.sourceforge.net/faq.html

Installing LEAP for the first time.

LEAP 1.2 can be installed in one of two ways:
  • A complete installation, which involves compiling your own copy
  • A small installation, which involves setting up your own copy of the database. A complete installation will probably have been made by a systems administrator or course tutor.
To create a complete installation you should consult the file INSTALL in the LEAP directory, and src/README for quick start instructions.

For a small installation, you will have been provided with a source directory in which LEAP has been built. You will also have been provided with brief instructions.


Copyright (C) 1997,1998 Richard Leyton

This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.

Starting LEAP

The LEAP program will reside in either the src or bin directory, and will be called 'leap'.

LEAP takes several command line parameters when it is started:

leap [options]

Where options are specified seperately:
Option Description
--activity-file file (-a) Write screen activitity to file. 
--configure script Configure (install) LEAP with file as source. ('make install' is *far* more preferable). 
--database db Database to open 
--debug Debug information. In combination with the trace information option, writes trace messages to the error file. 
--directory dir (-d) LEAP directory (The default is ~/leap) 
--help (-h) Display brief summary of the options. 
--timing Includes information about operator execution time. 
--time-logging Disable time information in log messages (This can marginally speed up the execution of LEAP) 
--long-commands Enables long commands (commands can spread over multiple lines)
--merge-stderr Output both stderr and stdout to the stdout output stream (For WinLEAP)
--padding  Pad relation names onto attributes in join/product
--productjoin Product join. If no condition is specified in a join, then perform a product. 
--quiet Quiet mode. Marginally reduces the amount of information displayed as LEAP runs.
--status Displays status messages
--tracing Tracing information. Displays additional information regarding LEAP's progress, such as parse tree info. To place trace information  in the log file, specify -d as well. 
--version (-v) LEAP version information. 
--warranty Displays the warranty and conditions of use information.
For example, to run LEAP from /user_home/myid/myleap, with trace info.

/user_home/myid/myleap/bin/leap -d /user_home/myid/myleap --tracing

In addition, you may specify the LEAP_DIR environment variable, rather than -d directory.

The configuration file (configs/vars) is also used for setting certain options which are always read and used unless overridden by the command line. Environment vars are also overridden by command line options.

The configuration file takes the format:

option on/off

If you specify anything other than on/off, off is used. There are exceptions, such as width, which can have auto/tab/nn for automatic tabulation, tabs as tabulations, or a fixed number nn.

Change options as you like, but do not remove any items in the first or second sections. Change values in the second section, and add variables/settings in the third section as you like.

Problems on startup

Several problems may occur at start up. Check the following:
  • You are specifying a valid directory!
  • You have the correct directory structure, and all files exist:
All directories that are present in the LEAP distribution are listed below:

leap/bin (*)
leap/doc (*)
leap/help (*)
leap/errors (+)
leap/scripts (**)
leap/src (**)
leap/src/include (**)
leap/src/parse (**)

Directories marked with a single asterix (*) may be a symbolic link to a central installation; Directories marked with a double asterix (**) may be excluded from a user's installation. Files marked with a plus (+) are required in LEAP 1.0 and earlier. Note that LEAP is distributed under the GNU General Public License. You are therefore entitled to a copy of the source code.

The important files necessary at startup are:
Directory/File Description
configs/vars Variable definitions and startup vallues
errors/errors Definitions of error messages (LEAP 1.0 and earlier, only)
report/report.txt Report/Log file (LEAP 1.0 and earlier, only)
help/helppgs Online help pages.
And the following relational files:


(.rel in LEAP 1.0 and earlier)

Using LEAP


LEAP is designed as an interpreter for the relational algebra. It is assumed that you are familiar with, or are learning about these concepts. This manual will not cover in much details the specific details of this aspect of relational theory, that is left to the experts (if appropriate, your lecturer/teacher). See the books list on the LEAP web page for a list of such titles.

In a nutshell, you can run LEAP, and type in various expressions from the various texts (and your class handouts), and see the results on screen.

There is, of course, more to it than that, and this is what this guide will hopefully cover - How to learn and use LEAP with the minimum hassle, so you can get on with what is important: learning the concepts.

LEAP concepts, and a few simple examples.

To start off with, a simple example. Note that all of the examples within this guide are included in the standard distribution of LEAP, and you are encouraged to execute them yourself to make sure you fully understand the example.

For your information, many of the examples included are taken from STA90 - A book that covers all of the theory of relational databases in simple terms. If you are after a good book on the subject of databases, it comes highly recommended. For a full list of books, see the section at the end of this manual which lists some other books.

After starting LEAP, you will be presented with the something like the following:

LEAP 1.2.5 - An extensible and free RDBMS
Copyright (C) 1997-1998 Richard Leyton.

LEAP comes with ABSOLUTELY NO WARRANTY; for details type "warranty".
This is free software, and you are welcome to redistribute it
under certain conditions; type "copying" for details.

[NON-FATAL] #2 - Error opening file [./configs/vars].
Message: No variables set!
Message: Directory specified [./] not valid. Trying [../]
Message: Debug level set to: 0
Message: Minimum debug level set to: 0
Message: Variables are now set.
Message: Applying command line options...
Message: Completed application of command line options...
Message: LEAP is starting...
Message: Opening [tempdb] database...
Message: Creating hash table for [zzfxrh].
Message: Opening [master] database...
Message: Opening [user] database...
Message: Startup sequence initiated.
Message: Sourcing startup.src in master
Message: Readline library available for command history/editing

Message: Sourcing open.src in user

[user] :-)

This screen tells you what you're running, which options have been set, and so on. Right at the end, you are given a brief welcome message, and some reminders on items of use.

Within LEAP, the various relations are divided into seperate databases. A database is defined as a collection of logically related relations, which in this case are relations from a particular db text.

To get us started, we will be using a table from the stanczyk database, so type "use stanczyk" to change to the database:

[user] :-) use stanczyk
Updating Hash Tables: leapattributes leaprel leapscripts leaptypes relship 
Message: Disposing relations
Message: Opening [stanczyk] database...
> This is the Stanczyk database. Examples are taken from
> 'Theory and Practice of relational databases'.
> This database has a number of useful examples that
> clearly demonstrate the relational algebra.

We are now in the stanczyk database. Within the database, there are a number of relations, which can be listed by typing "list":

[stanczyk] :-)
Message: Relation zzzcbx returned.

To print a particular relation, for example the "book" relation, type "print book":

[stanczyk] :-) print book
reference author    title
--------- --------- ------------------------------
R003      JOYCE     ULYSSES
R004      JOYCE     ULYSSES
R033      LEM       ROBOTS TALES
Message: Relation book returned.

Simple so far. Now for an example of the relational operators within LEAP. A list of all authors of books available. The project operator is the appropriate operator for this sort of query. Therefore, type the command "project (book) (author)".

When the command completes, the name of the relation that is produced during the execution, is displayed. Printing this relation shows the result.

[stanczyk] :-) project (book) (author)
Message: Relation zzqqil returned.
[stanczyk] :-) print zzqqil
Message: Relation zzqqil returned.
Tip: Rather than typing the name of the random relation each time, use the LEAP variable "@last" for the name of the last relation returned. LEAP resolves the name, and saves the hassle of dealing with the random names.

[stanczyk] :-) print @last
Message: Relation zzqqil returned.

As well as typing in commands on there own, as above, the result of an expression can be assigned to a specific relation, eg: typing "r1=project (book) (author)" assigns the result to the new relation r1. Note that the relation specified must NOT already exist. The @last variable can still then be used.

Several things should be noted on entering expressions:

  • Every relation, or algebraic expression, should be enclosed in brackets.
  • Lists of attributes should be seperated by commas.

Combining expressions

Once you have assigned the result of an expression to a relation, then you can add additional operations to work on the result. eg. imagine we want to "find out the subjects that are not represented in the library".

There are two ways. Firstly, specifying each operation on a seperate line and using assignment of results:

subjcl=project (subject) (class)
indcla=project (index) (class)
result=difference (subjcl) (indcla)
print result 

Secondly, using the principle of relational closure. Relation closure is the principle that every operator returns a relation as a result. The result of an expression is passed to the higher level expression, which is then evaluated:

(project(subject) (class)) difference (project (index) (class) )
print @last

Try the above examples, and compare the results.

It is probably clear that nesting expressions can result in rather confusing large expressions, however relational closure is an important principle to experiment with. LEAP supports it, the only limit is the length of the expression!

Prepared expressions

It is probably likely that you will want to work on a complex expression, and you just can't get it to do what you want. Rather than have to type in expressions over and over again, you can store the expression in a seperate file, and execute it. To list all of the availble source scripts, type:


A script is fixed to particular database, ie. you cannot execute a script in the date database, which is located in the korth database.

To execute a script, type:

@ <scriptname>

To print the contents of a script, type:

l <scriptname>

For example, the previous example for nesting relations, is contained in the stanczyk database:

[stanczyk] :-) l ex41b
Source File: ex41b
# This example is taken from STA90 and is given in the infix form
# Example 4.1 (b)
r2=(project (subject) (class)) difference (project (index) (class))
print r2

[stanczyk] :-) @ ex41b
[stanczyk] :-) 
[stanczyk] :-) 
[stanczyk] :-) r2=(project (subject) (class)) difference (project (index) (class))
Message: Relation r2 returned.
[stanczyk] :-) print r2
Message: Relation r2 returned.


Relational operators

Rather than explain what the individual operators do, a simple overview of the way they are expressed in LEAP is given here. The online help includes a brief description as well.

project (expression) (attrib1, attrib2, ..., attribN)
(expression) union (expression)
(expression) intersect (expression)
(expression) difference (expression)
(expression) product (expression)
select (expression) ((condition) {[and|or] (condition)} )
join (relation) (relation) ((condition) {[and|or] (condition)})
natjoin (relation) (relation)

difference can be replaced with minus, and select with restrict, depending on your preference.

See the special section on natjoin for additional information.

Note that with union, intersect, difference and product, you may place the operator at any point in the expression, eg. union (expression) (expression) is valid, as is (expression) (expression) operator.

Updating and deleting tuples

LEAP also now allows existing tuples to be easily updated and deleted.

Deleting tuples takes the form: delete (relation) (condition)

This will search the relation specified for any tuples that match the specified condition. On encountering such a tuple, the tuple is marked as deleted. The condition takes the form of a condition you'd use in the select or join operator, and can refer to attributes in the relation, or to always true (or false) statements if required.

Updating tuples takes the form: update (relation) (condition) (update_statements)

The first three components of the update command are identical to the delete operator. The last component is new - This is where the attributes to be updated are specified, along with the values to update them with, eg.

update (r) (a='4') (a='5')

The relation 'r' is updated, where attribute 'a' equals '4', and where this condition is true, set the attribute to '5'.

Its' possible to specify multiple updates, by seperating the statements with commas, eg.

update (r) (a='4') (b='1',c='2')

Current restrictions with the update operator are that you can only set values to explicit values - it's not currently possible to set it to values elsewhere in the updated tuple; It's also not possible to update it based on a condition or value crossing relations (as you can do in SQL). These shortcomings will be addressed in a later release.


Conditions take the form:

( [value|attribute] <,<=,=,>=,>,<>,~ [value|attribute] )

values must always be contained within quotation marks (single or double).


( attrib = "value" )  - TRUE whenever attrib contains "value"
( "value" = "value" ) - Always TRUE
( attrib = attrib )   - TRUE whenever the values in the attributes match
( attrib > "10")   - TRUE whenever attrib is greater than 10.
( attrib

The appropriate comparison (string/integer/boolean) is made only if the data type of the attribute is defined accordingly, ie. integer comparison will only occur if the attribute is defined as an integer. The default is a string comparison.

Nesting of conditions is not currently supported. There can be up to 20 conditions in one set.

Creating a relation

Creating a relation is very straight forward. The syntax is:

relation (name) ((attribute1, type1, length1), (a2,t2,l2), ..., (aN,tN,lN))

The type may be one of: string, integer or boolean.

The length is the amount of data that is stored in the attribute. LEAP will truncate data that exceeds this value.

A relation may have a name up to 25 characters (Unix), or 8 characters in DOS.

An attribute name may be up to 25 characters. The maximum number of attributes in a relation is 20.

Adding data to a relation

Add data using the following format:

add (relation) (value1, value2, ..., valueN)

Type checking is not performed - So you could add a string to an integer attribute. This will be addressed in a later release.

If insufficent data is provided, LEAP will insert blank data. Too much data, and the additional values are ignored.



To insert a blank value, specify a dash (-), eg:

add (ex_auth) (ANNAME,-,TEXTBOOKS)

Deleting relations

Relations can be removed quite easily:

delrel (relation)

The relations are removed from internal structures, and the disk. Therefore you cannot nest the delete command.


Relations are grouped into seperate databases. The relations within a database are usually related to one another, for example a company might might have a payroll database, a commissions databases, and so on.

LEAP's databases aren't quite that complex... They are grouped into by different text books, from which examples are taken.

Two databases are special: master and user. Master contains the data dictionary. User is the default database to connect to.

In addition, the standard LEAP distribution contains three additional databases: date, stanczyk and korth - Which contain examples from three database text books.

To change to a particular database, type "use <db>". To list the available databases, simply type "use".

Creating a new database is a matter of typing:

create dbname

And then change into the database with:

use dbname


[stanczyk] :-) create example
Message: Updating Hash Tables:
leapattributes leaprel leapscripts leaptypes relship 
Message: Disposing relations
Message: Opening [example] database...
Message: Creating hash table for [leapscripts].
[stanczyk] :-) use example
Message: Updating Hash Tables:
auction book delivery ex_auth ex_book ex_publi example goods index lc leapattributes leaprel leapscripts leaptypes names q r r2* relship s stock subject 
Message: Disposing relations
Message: Opening [example] database...
[example] :-) 
[example] :-) 
[example] :-) list
Message: Relation zziclt returned.
[example] :-) use
Valid databases are:


LEAP allows various internal settings to be changed by the user. In addition, the user can use some of these settings themselves. The use of variables will increase in subsequent versions of LEAP.

To review the variables, type: vars

program                  :LEAP
version                  :1.2
last                     :r2
currentdb                :stanczyk
daemon                   :off
trace                    :off
debug                    :off
debuglevel               :0
mindebuglevel            :0
timing                   :off
case                     :off
quiet                    :off
temporary                :on
timelog                  :on
long                     :off
padding                  :off
width                    :auto
tempdb                   :on
productjoin              :off
merge-stderr             :off
The first two variables, program and version, are mererly informative.


This variable contains the last relation returned by an operation. Rather than typing the relation name, which might be randomly created, type @last - LEAP will resolve the variable, and display the correct relation.

trace {on|off}

This variable can either be on or off. When on, LEAP will display a lot of information, such as parse tree information, hash table info, and so on. It is very useful for examining how LEAP progresses, and for debugging expressions.

To send the trace information to the log file, enable debug information as well.

This option can be enabled from the command line with -t

debug {on|off}

This variable can be either on or off. When on, trace information is sent to the log file. In addition, a number of debug items which are unlikely to be of interest, are also displayed.

timing {on|off}

This variable is extremely useful. When enabled, it displays the amount of time taken to perform a particular operation, and the number of read/writes. Use it in conjunction with the trace option to ensure that the output is more understandable.

Timing information is summed up, so  that the total amount of information displayed at the end is the amount of time spent by each component operation of a single expression.

Timing information is not summed between seperate expressions.

case {on|off}

Case sensitivity - This is partially available. When enabled, the condition values are evaluated without regard to case. Note that all other items, variables/attributes/commands are still case sensitive. This will be resolved in a later version of LEAP.

quiet {on|off}

Quiet mode - When enabled, LEAP displays minimal data on screen. In due course this will be used for processing of LEAP where output other than relations is not necessary, ie. in Unix where output is piped into another process.

temporary {on|off}

Relations created when evaluating expressions are normally created as temporary relations, which are deleted when LEAP shuts down. When temporary is set to off, all relations created are permanent. Note that this does NOT apply to the master database, where all user-created relations are temporary.

timelog {on|off}

When enabled, this option writes a timestamp with each message written to the LEAP log/report file. Disabling this will marginally improve performance when running LEAP, but not significantly.

long {on|off}

When this option is enabled, long commands may be entered into LEAP. Long commands can span multiple lines. Terminate a command with a semi-colon on a line of its own:

select (arelation)

merge-stderr {on|off}

Introduced for WinLEAP, this option puts stdout and stderr output streams to the stdout stream. Specify this option on the command line to WinLEAP, and a single output pane is created, rather than the default two.

padding {on|off}

The relation produced from a join/product takes the attributes from the source relations. When padding is off, only duplicate attributes have the name of the source relation prepended to the attribute name.

When padding is enabled, all attributes have their source relation added to the start.

width {auto|tab|NN}

When creating a relation, one of the necessary options is the display size of the attribute. This value is used when width is set to auto (default). Sometimes this can be too small, or too large. When width is set to tab, it will use a tab character.

When set to some number NN, that number is used to specify the maximum width for the attribute.

productjoin {on|off}

When enabled, a join operation without a specified condition will produce the equivalent of a product. A join is, after all, a product followed by a select. It is disabled by default.

Online Help

LEAP contains full online help. The help pages can all be accessed by typing "help" for a brief summary.

An index of help pages can be displayed by typing "help index".

A particular help page can be displayed by typing "help <page>". If no data is displayed, no such help page exists.

Miscellaneous features and functionality

Operating System commands

At some point you may wish to execute a command in the operating system. You can do this through LEAP by typing the command after an exclamation mark, eg.

! ls -l /dev/rdsk

The result is displayed on screen. No processing is made of the return code, nor can the output of a command be fed into LEAP.

This feature is not available in the Windows version of LEAP.

Natural Join

The format of the natural join operator is identical to that of join, only without a condition, as this is provided by reference to the "relship" data dictionary relation, which is found in every database.

In order to use natural joins, the relationship must be defined. Look at the relship relation, and review the attributes:

frelation, prelation, fkey1, fkey2, fkey3, pkey1, pkey2, pkey3
Key Description
frelation The relation containing the foreign key 
prelation The referenced relation.
fkeyn Foreign key from foreign relation
pkeyn Primary key from referenced relation

Entries are read, reviewed, and conditions built automatically. Set trace on to display the generated qualification.

Natural join can be called specifically (natjoin operator) or implicitly by missing the condition from the join operator.

An error (#5 - Attribute not found) will occur if a natural join is requested on a pair of relations that have not had their relationship defined.


If you have any comments, suggestions, questions or bugs to report there are several avenues to follow.

Send e-mail to the author: Richard Leyton - leap@leyton.org

Write to the author: Richard Leyton, c/o 3 Pelting Drove, Priddy, Wells, Somerset, BA5 3BA, England.

Staying informed

There is now a mailing list for users of LEAP. Principally it is for announcements regarding the development of LEAP, but feel free to use it for other purposes, such as sending bug fixes, solving problems, and so asking questions.

To join, visit http://lists.sourceforge.net/lists/listinfo/leap-announce

LEAP Home page


Example Databases

The standard distribution of LEAP contains examples taken from three database texts. It is a simple process for new databases to be created and added to suit the needs of the user. The books have been chosen from personal preference, but suggestions for new texts examples are encouraged.

 The LEAP web page has a number of additional database texts.


Taken from "Theory and Practice of Relational Databases", by Stefan Stanczyk, the reason for its inclusion is that this book was the recommended text on the courses at Oxford Brookes University (where Dr Stanczyk lectures), and was the original basis for the LEAP relational algebra notation.

The book has the best relational algebra section going, to my knowledge.


The stanczyk database is based around the Relational Algebra chapter (pg. 59), and each of the relations mentioned in the examples within the chapter are implemented. In some cases the content of the relations has been defined, as only a schematic definition of the relation is given in the text.

The chapter starts by providing an overview of the relational algebra, and why it is necessary within the relational model. The distinction between unary and binary operators is made graphically, and relational closure explained. Then the chapter moves into explaining the "primitive retrieval operations": union, difference, intersect, product, project, select/restrict, join & divide. A mathematical definition is provided for each, and a graphical example to illustrate the operation.

Note that when implemented in LEAP, some transformation of the expression is made to make it compatible with the LEAP notation. You'll agree (I hope), that the notation is not much different, and in some cases, clearer and more consistent, than the published expressions.

Example 4.1 is implemented in LEAP as ex41a (simple project) and ex41b (two projects and a difference). The resultant relation from LEAP can be directly compared to the published relations in the example.

Example 4.2 is implemented in leap as ex42 (restriction), and the resulting relation from LEAP can be compared to the published relation.

Example 4.3 is implemented in LEAP as ex43 (select with multiple conditions), and again the result can be compared to the published relation.

Example 4.4 is implemented in LEAP as ex44 (different joins), but note that LEAP currently can only have one specific relationship between a pair of relations, and only the first is show.

Example 4.5 is directly implemented, with results being assigned to relations as given in the text. This leads to the problem of re-running the query a number of times, but the change/delete operation can be used (or simply change databases, and reopen the database).

The divide operation as implemented to LEAP (divide script) solves one of the questions given in the text, to demonstrate how the divide operation can be implemented. The result can be compared to that given in example 4.7. Note that the way LEAP determines if a relation is union compatible is by attribute names, and therefore a rename operation occurs to ensure that the two relations are "union compatible" by LEAP's definition. When domains are implemented in LEAP, this will change!

Many examples are provided in the section on Database interrogation (section 4.3), and each of the queries given in the text is directly implemented in LEAP.
Query LEAP Script
4.3.1 q431
4.3.2 q432
4.3.3 q433
4.3.4 q4_3_4
4.3.5 q4_3_5
The exercises given in the text are partially implemented in the LEAP scripts, partly to further demonstrate LEAP's functionality, but also to ensure the you remain with something to do!

Exercise 4.1 is implemented as far as question b, and uses three relations that have been created and populated following the definition given in the text. Note that the data entered was chosen to ensure that some of the questions would return a result, and will not extend to the entire exercise. You'll have to create some of your own relations.

Question a and b have been implemented twice, once as a series of sequential operations, and once as a nested expression. The nested expressions (particularly of question b) produce quite complex parse trees, and are a great place to review the parse tree defined by LEAP.

Exercise 4.4 is answered by the divide script, but the interested student can try to demonstrate it themselves. Note that the published answer is incorrect.


This book really is rich with examples and questions. Its a great start for learning about databases, and covers all areas of databases, without entering into implementation concerns. Its more practical than others, with sections on SQL, Relational Calculus, and Data modelling, plus others. Its also much slimmer than others, proving that reams of pages aren't necessary to cover the essential components.

Second Edition now available: Theory and Practice of Relational Databases, 2nd Edition, by Stefan Stanczyk, Bob Champion, and Richard Leyton may be ordered from the publishers website, or from Amazon.


Taken from "An introduction to database systems" (5th & 6th Editions), by C.J.Date, the reason for its inclusion is this book is widely regarded as the bible of database systems.


The chapter on relational algebra starts by providing a explanation for the need, and then an overview of each operator (including a superb graphical representation of each operator), as well as the concept of relational closure. Note that the notation given for the relational algebra is slightly different from the LEAP notation, but comparison of the examples given,
to the LEAP implementation should demonstrate that conversion between the two is not difficult.

The discussion on relational closure includes a script which joins the supplier (s) and product (p) relations, where the weight of the product is greater than 18. Note that LEAP does not allow a join without a condition, and that the number is included in quotes. Note that LEAP algebra supports the attribute name inheritance discussed here, with the exception of relations which contain duplicate attribute names, whereby the "clashing" attribute is renamed to incorporate the source relation name. Because this treatment is consistent, you can predict the way a name will be treated.

Date discusses a rename operator. LEAP also has such an operator, with a little more functionality to prevent too many operators. The rename operator discussed by Date allows attributes to be renamed, LEAP allows this using the notation:

rename (s.city) (scity)

Which will determine that the subject of the rename is relation s, and that the target attribute is city. The new name is then specified as scity. Whilst on the topic of renaming, note that it is not currently possible to perform multiple renames as described by Date on the next couple of pages.

Date moves on in section 6.4 to discuss the traditional set operators. The term "type-compatible" is used (for valid reasons) in place of the term "union-compatible", and the definition of type compatible is similar to the approach taken by LEAP, with the exception that the compatibility is determined by the attribute names, and not by the domain/data type.

The following examples draw on a very small pair of relations. Relations A and B are type-compatible, and have been implemented in LEAP.

The union example has been implemented as datu1, the intersection example as dati1. The two difference examples have been implemented as datd1 (a minus b) and datd2 (b minus a). For the purposes of clarity, difference/minus are the same operator.

The product example has been implemented slightly differently from published. Rather than using new relations, the existing relations a and b are used, and the result is smaller, but can still be seen.

Proving that the operators are associative/commutative is an exercise that is left to the user to prove. Just remember the slightly different notation for LEAP to that given in Date's discussion.

Restrict/Select is demonstrated in the select script for each of the examples in figure 6.5.

Project is demonstrated in the project script. Each of the operations in figure 6.6 is implemented and displayed in turn.

The njoin script contains the example in figure 6.7

Theta-joins can be implemented directly in LEAP, the example from fig 6.8 - In fact, it's clearer than the date notation!  The division operator is not implemented directly by LEAP, but an example is given of how it can be done.

Some of the examples give in section 6.6 are implemented in scripts ex661 and ex662. The examples then get quite complex, and therefore it is left as an exercise for the reader to implement.

Note that the extend and summarise operations are not implemented, as they are not part of the core relational algebra. They may be implemented at a later stage to extend the functionality of LEAP.


This books is rightly regarded by many as the bible of database systems, and it should be read by (or at least, available to) anybody who studies or works with databases. It covers everything from data modelling, through to new technologies, such as object oriented databases, distributed databases and client/server systems. Yet its written in an excellent manner, and proves to be a reliable source of information at all levels of study.

Date, c.j., An introduction to database systems, 6th Edition, Addison-Wesley Publishing Company, 1995, ISBN 0-201-82458-2


Korth, h.f; Silberschatz, A; "Database System Concepts", 2nd Edition, McGraw-Hill Inc., 1991, ISBN 0-07-044754-3

This book is not available at the time of writing the user manual, and therefore a walkthrough is not possible.

© 1995-2005 Richard Leyton Contact