


LEAP B0.10.1



A Relational Algebra Processor and RDBMS



User Manual











See also:
http://www.brookes.ac.uk/~e0190404/leap.html 
or
http://www.brookes.ac.uk/cms/students/richard_leyton/leap.html










 Richard Leyton, 1994, 1996


1. Contents
1. CONTENTS	3
2. COPYRIGHT, WARRANTY, AND DISTRIBUTION OF LEAP	5
3. INTRODUCTION	6
4. DEVELOPMENT	6
5. STARTING LEAP	6
6. THE LEAP ENVIRONMENT	8
6.1 MULTIPLE DATABASES	8
6.2 ACCESSING DATABASES	8
6.3 CREATING DATABASES	8
7. QUERIES	9
7.1 THE LEAP RELATIONAL ALGEBRA.	9
7.2 PROJECT (P)	10
7.3 SELECT/RESTRICT (S)	11
7.4 UNION ()	12
7.5 INTERSECT ()	12
7.6 PRODUCT ()	13
7.7 DIFFERENCE (\)	13
7.8 JOIN ( |><| )	14
7.9 DIVIDE ()	14
8. USING LEAP	15
8.1 INTRODUCTION	15
8.2 RELATIONS	15
8.3 COMMAND SCRIPTS	16
8.4 FEATURES	17
8.4.1 Introduction	17
8.4.2 Output copy	17
8.4.3 Operation Timing	17
8.4.4 Display Parse Tree	18
8.4.5 Nesting expressions	20
8.4.6 Data Dictionary	20
8.4.7 Data Cache	20
8.4.8 Debug Information	20
8.4.9 Case Sensitivity	21
8.4.10 Adding messages to the report file	21
8.5 ONLINE HELP	22
8.5.1 Help Index	22
8.6 EXAMPLE DATABASES	22
8.6.1 stanczyk	23
8.6.2 Date	24
9. CHANGES IN LEAP B0.10	26
9.1 A FORM FOR FEEDBACK IS INCLUDED IN THE DISTRIBUTION.	26
9.2 INFIX EXPRESSIONS ARE THE DEFAULT FORMAT. PREFIX ARE STILL SUPPORTED	26
9.3 IMPLEMENTED A "DUPLICATE" OPERATOR.	26
9.4 MULTIPLE DATA TYPES SUPPORTED.	26
9.5 DUPLICATE TUPLES ARE NOT PERMITTED, AND THIS IS ENFORCED INTERNALLY.	26
9.6 HASH TABLES MAINTAINED BETWEEN RUNS, AND FOR ALL RELATIONS.	26
9.7 AN ITERATIVE TWO STAGE PARSER	26
9.8 CHARACTER DELIMITED TEXT FILES, WITH SUPPORT FOR OLD FORMAT	26
9.9 A SMALL DATA DICTIONARY IS USED	27
9.10 DUPLICATE ATTRIBUTES ARE HANDLED CONSISTENTLY.	27
9.11 FAR FEWER FILE HANDLES REQUIRED.	27
10. FEEDBACK FORM	28


2. Copyright, Warranty, and Distribution of LEAP
LEAP - An extensible relational algebra processor/RDBMS (v0.10.1)
Copyright (C) 1996 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.

The following is an extract (sections 11 and 12) from the GNU General Public License. Please refer to this 
for full and complete details.

NO WARRANTY

  11. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY 
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN 
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES 
PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED 
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF 
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO 
THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE 
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, 
REPAIR OR CORRECTION.

  12. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING 
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR 
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR  DAMAGES, 
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES 
ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT 
LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES 
SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE 
WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN 
ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

3. Introduction
LEAP is a relational database management system that aims to provide the relational model in 
its true form. This is an objective that is at odds with issues such as performance, applicability 
and compatibility that are at the core of the commercial relational offerings from Sybase, Oracle, 
Microsoft et al.
Whilst these systems offer performance tools that are powerful, they can make learning the 
practical theory behind the relational model difficult, by blurring the clear definitions present in 
the relational model.
Because LEAP was initially developed as a final year university project, and proved to be of 
great use in teaching Databases, it is distributed freely and without charge.
4. Development
LEAP was initially a final year university project, but work has continued as time permits since 
then. This version of LEAP plugs a lot of the gaps that were previously present. It is hoped that 
this (beta) version will prove to be the last beta version before version 1. Once version 1 is 
"released", then work will start on version 2, which will plug the last big gap in LEAP functionality 
- The integrity component of the relational model, clearly the most complex part.
LEAP was originally written for MS-DOS, as this was the most appropriate environment at the 
time. However, as work has progressed, it is intended to develop a UNIX version. This is a more 
appropriate environment for University courses, where UNIX is very popular. MS-DOS will still be 
supported, as will (hopefully) Windows versions.
5. Starting LEAP
LEAP is relatively straightforward to start up. You simply needs access to a machine capable of 
supporting MS-DOS applications. This includes Windows 3.1, and Windows 95. Recent 
development of LEAP has been on a Windows 95 machine, and it works just fine.
If you downloaded LEAP from one of the Internet ftp sites, then the program is likely to be in 
compressed form. The program must first be uncompressed, which will require a copy of 
PKUnzip. Assuming this program is available, and either in the current working directory, or 
present in one of the directories specified in the PATH environment variable, type:
pkunzip -d LEAP
The archive file, LEAP.zip is then uncompressed. The -d parameter recreates the necessary 
directory structure. If this parameter is missed off, the program will not operate correctly, if at all.
Having successfully uncompressed the program, LEAP may then be started. This simply 
involves executing the main binary, with the necessary parameters specified.
LEAP offers a number of options, some of which may also be set from within the program. These 
are:
Parameter
Operation
Default
DIR
Specifies the directory in which the LEAP files 
are stored.
c:\LEAP
DEBUG

Specifies whether additional debug information 
should be written to the report file
n
INFIX
Specifies whether LEAP should process infix 
expressions, as opposed to prefix. Version 1 of 
LEAP will default to infix expressions.

N
USTIME
Specifies whether timing should be displayed in US 
(mm/dd/yyyy) or European (dd/mm/yyyy) time 
formatting. By default, Europe formatting is used.
n
COPY
Specifies whether the screen output should be 
duplicated in the temporary directory
y
COLOUR
Specifies whether colour should be used (COLOR can 
also be specified on the command line)
Y
CACHE
Specifies whether to utilise LEAPs internal tuple 
cache
N
IOON
Specifies whether to disable extra information, 
such as hash table creation reports etc.
N
TRACE
Display program trace information. This is very 
noisy!
N
ITERATIVE
Use the iterative parser (Y) or the recursive 
parser(N(
Y
PARSE
Display the expression parse tree before execution
N
?
Display a command line option summary

 
Parameters can be expressed in any order, for example:
LEAP dir=d:\apps\LEAP timing=y
If a parameter is not specified, the default is taken.
The path specified with the directory parameter must be absolute, rather than relative. The 
complete path, if it is not displayed in the command line prompt, can be retrieved by typing CD at 
the prompt.
LEAP should now execute. Possible problems that might occur at this stage are:
  LEAP cannot find the necessary files, check:
  The directory specified is correct and absolute (The directory specified should contain the 
five directories: database; errors; help; html; docs and reports.)
  The directory structure was created when LEAP was extracted.
  All files exist (Look in the file doc\files.txt for a list of all files. Of particular 
importance is LEAPPATH\errors\errors.txt and 
LEAPPATH\database\master\help\helppg.txt
  The environment variable TEMP is set incorrectly (i.e. to an invalid path). Either remove it, or 
set it correctly.

6. The LEAP Environment
LEAP is a small system, but it does have a lot of functionality. This section aims at providing an 
overview of the environment and features offered by LEAP, with particular focus on features that 
are significantly different from older versions of LEAP.
6.1 Multiple Databases
Principal in this version of LEAP is the provision of multiple databases. A database is conceived 
as being a collection of relations that have some logical relationship. In a large commercial 
RDBMS, there might be an accounts database, a payroll database, and so forth.
Whilst LEAP does not quite have the capacity for such databases, it allows a separation of the 
databases. In the standard distribution there are a number of example databases for each of the 
main texts. For example, there is a "date" database, containing examples from dat95, a 
"stanczyk" database, containing examples from sta90.
Grouped within each database is not only the relations, but also the scripts which apply to the 
relations. Each of the scripts, which usually relates to a particular example in a particular text will 
perform some operations that result in a number of new relations.
There is a special database, which houses the data dictionary. The "master" database contains a 
relation called "LEAPdata". This relation contains a cross-reference between the database name, 
and the directory in which the database is located. The data dictionary will be expanded as LEAP 
becomes more advanced, and incorporates more features, and as its functionality expands. User 
relations are not permitted in this database, and are deleted when the database is accessed.
6.2 Accessing databases
How is a database actually accessed? A new command in LEAP allows a database to be 
opened. The "use" command. e.g.
use stanczyk
Will firstly close the current database (defaults to the user database), and then open the 
"stanczyk" database. Trying to open a database that is already open results in an error!
To list all of the known databases, either perform a select on the LEAPdata relation in the master 
database, or enter "use" on its own, without a database name.
6.3 Creating databases
In order to create your own database, the "create" operator has been modified. The new operator 
bears a resemblance to the SQL standard "create" i.e.:
create database example An example database
Will create a database named "example", with an information description of "An example 
database". Any text after the first three tokens is used as the information text. There is a file in 
the database directory called "info.msg", which can be modified for a more detailed 
explanation of the database.
This is particular useful for creating example databases, which can draw the users attention to 
particular scripts and relations. For example, if a database course contains some specific 
examples which students have expressed questions about, then "The xyz script demonstrates 
the principles of select/project migration in lecture 4" might be a useful comment.
In addition, a script called "open" in each database is executed at the opening of the database. 
Lines beginning with a ">" (in the file) are displayed in highlight (without the symbol).
7. Queries
Queries are the embodiment of the behavioural component of the relational model. The user is 
able to extract data from the relations that form the database to answer questions. "Who is the 
sales representative for customer x?". Without the behavioural component, the relations and 
integrity components of the model are effectively meaningless.
The most well known implementation of the behavioural component of the relational model is the 
structured query language, or SQL. ANSI has defined a number of successive standards for 
SQL, and this is supported by the majority of leading commercial database vendors.
The relational model demands that an implementation of a behavioural component of the 
relational model be "at least as powerful as the relational algebra". The relational algebra is a 
bare core of operators that allows the most important queries to be formulated.
As the relational model is based solidly in mathematical theory, the relational algebra bears clear 
similarities to the operators in set theory, for example, union, and intersection. Whilst SQL is far 
more powerful than the relational algebra cited in texts, it does blur away the original operators. 
For example, there is no explicit "join" operator in SQL, it is combined into the select operation. 
In order to help students fully appreciate the relational algebra, the query language of LEAP is 
based upon the published algebraic languages in popular database texts. This allows a user to 
enter a query in its raw form, to manually define the join clause, select the data. Operator 
equivalence can be proven, and execution time measured.
The operators are as follows:
union - combines two comparable (termed 'union compatible') relations, discarding duplicate 
tuples
intersect - produces a relation containing tuples that appear in both relations
difference - produces a relation that contains all tuples in the first relation that are not found in 
the second.
project - Extracts only the specified attributes from a relation, removing duplicate tuples from 
the result.
product - produces the Cartesian product of two relations such that every combination of tuples 
from both relations appears in the result.
select - produces a relation containing only those tuples from a relation which match a given 
condition.
join - product two relations, containing only tuples which match a specific condition.
divide - Whilst relatively unimportant, it produces a relation which is ...
Of the eight operators, only five are primitive. That is, the remaining three may be implemented 
in terms of the others. It is an interesting exercise which is left to the reader to prove (or look in 
any popular database book!).
7.1 The LEAP relational algebra.
The LEAP query language has behind it a BNF (Backus Naur Form) definition which will perhaps 
be interesting for the mathematically minded:
<command> ::= [<relation name> = ] <relational-exp>
<relation-exp> ::= <unary-term>|<binary-term>|relation-name
<unary-term> ::= project (<relational-exp>) (<attribute-list>) |
select (<relational-exp>)(<qualification>)
<attribute-list> ::= <attribute-name> [,<attribute-name>]*
<qualification> ::= <attribute-comp> [{and|or} (<attribute-comp>)]*
<binary-term> ::= (<relational-exp>) <operator> (<relational-exp>) |
join (<relational-exp>) (<relational-exp>) (<qualification>)
<operator> ::= union | difference | intersect | product
<attribute-comp>::= <attribute-name> <comparator> {attrib-name|value}
<comparator> ::= { < | > | <= | >= | = | <> }
This mathematical definition is the basis for the implementation, and the query parsers (there is 
more than one in LEAP) that process the query. However, this doesn't necessarily help in the 
introduction that this document is supposed to provide. Let the BNF definition given here serve 
as a reference on how relational algebra queries may be formulated within LEAP. For more 
information on BNF, books on computing theory will provide more information. WIR76 is a well 
known example.
In order to introduce how expressions can be formulated, each of the operators will be discussed 
and examples will be taken from the popular texts. This will allow, to use an expression, two 
birds to be killed with one stone: Introduce the relational algebra as provided by LEAP, and 
demonstrate how queries presented in a text to be easily converted to the LEAP format.
7.2 project (p)
Project is a simple operator once its seen in practice. It takes a relation, and extracts all 
information that is held under the given attributes. In the stanczyk database (which contains a 
number of relations containing library book information), there is no "author" relation. Lets say we 
have a need to find out all the authors that have written books in our library.
We can't look at the author relation, so the next place to look at is the "book" relation, which 
contains a number of attributes:
>describe book
REFERENCE   (STRING)
AUTHOR   (STRING)
TITLE   (STRING)

Lets take a look at the "book" relation:
>print book
Relation: BOOK
REFERENCE                 AUTHOR                    TITLE
---------------------------------------------------------------------------
R003                      JOYCE                     ULYSSES
R004                      JOYCE                     ULYSSES
R023                      GREENE                    SHORT STORIES
R025                      ORWELL                    ANIMAL FARM
R033                      LEM                       ROBOTS TALES
R034                      LEM                       RETURN FROM STARS
R036                      GOLDING                   LORD OF THE FLIES
R028                      KING                      STRENGTH TO LOVE
R143                      HEMINGWAY                 DEATH IN THE AFTERNOON
R149                      HEMINGWAY                 TO HAVE AND HAVE NOT

The "author" attribute is the one we want. In order to get the authors we use project as follows:
authors=project (book) (author)
It can be read as follows "Create a relation 'authors', which is the projection from relation 'book' 
of attribute 'author'", or "project from relation 'book', attribute 'author', and assign the result to 
relation 'authors'":
>authors=project (book) (author)
AUTHORS Returned.

>print authors
Relation: AUTHORS
AUTHOR
-------------------------
JOYCE
GREENE
ORWELL
LEM
GOLDING
KING
HEMINGWAY

Compare the results to the original relation, all of the authors have been extracted from the 
"books" relation, and placed into the resulting relation. No duplicates are permitted within a 
relation, and the result relation demonstrates this (there were two books by joyce, lem and 
hemingway).
Project is often written using the greek symbol p, most published examples can simply be 
executed simply by replacing the symbol with "project". Be careful to specify the relation name 
(or expression) first, followed by the attributes.
7.3 select/restrict (s)
The select operator is sometimes referred to as restrict. Select is perhaps a better term to 
describe what actually goes on: All tuples matching a given condition are selected from a 
specified relation. For example, in the "books" relation in the stanczyk database, we might want 
to list all books written by a specific author.
For example:
>lembook=select (book) (author='lem')
LEMBOOK Returned.

>print lembook
Relation: LEMBOOK
REFERENCE                 AUTHOR                    TITLE
---------------------------------------------------------------------------
R033                      LEM                       ROBOTS TALES
R034                      LEM                       RETURN FROM STARS

The format is "select from relation 'book' all tuples which match the condition 'author='lem''". The 
condition does not necessarily have to be a simple equals. Now that we know which books we 
have by Lem, we might want to find out those not written by him:
>notlem=select (book) (author<>'lem')
NOTLEM Returned.

>print notlem
Relation: NOTLEM
REFERENCE                 AUTHOR                    TITLE
---------------------------------------------------------------------------
R003                      JOYCE                     ULYSSES
R004                      JOYCE                     ULYSSES
R023                      GREENE                    SHORT STORIES
R025                      ORWELL                    ANIMAL FARM
R036                      GOLDING                   LORD OF THE FLIES
R028                      KING                      STRENGTH TO LOVE
R143                      HEMINGWAY                 DEATH IN THE AFTERNOON
R149                      HEMINGWAY                 TO HAVE AND HAVE NOT

All of the usual comparitor operations can be used: <, <=, =, >=, >, <>
Its also possible to combine conditions, i.e.. "all books by orwell and king":
oandk=select (book) ((author='king') or (author='orwell'))
>oandk=select (book) ((author='king') or (author='orwell'))
OANDK Returned.
>print oandk
Relation: OANDK
REFERENCE                 AUTHOR                    TITLE
---------------------------------------------------------------------------
R025                      ORWELL                    ANIMAL FARM
R028                      KING                      STRENGTH TO LOVE

Be careful about the brackets, as an incorrect bracket may either result in failure to execute, or 
worse still, the wrong result!
7.4 union ()
The union operator is the same as its equivalent in set theory - it combines two relations. There 
is a condition - the relations must be union compatible - they  must have the same attributes 
drawn on the same domains. Within LEAP it suffices that they have the same name and same 
data type.
In the date database, the relations "a" and "b" are union compatible:
>print a
Relation: A
S                         SNAME                     STATUS                    CITY
--------------------------------------------------------------------------------------
S1                        SMITH                     20                        LONDON
S4                        CLARK                     20                        LONDON

>print b
Relation: B
S                         SNAME                     STATUS                    CITY
--------------------------------------------------------------------------------------
S1                        SMITH                     20                        LONDON
S2                        JONES                     10                        PARIS

If we execute the command:
(a)	union (b)

The relations will be combined, and any duplicates removed. For example "smith" exists in both 
relations.
>unionex=(a) union (b)
UNIONEX Returned.

>print unionex
Relation: UNIONEX
S                         SNAME                     STATUS                    CITY
--------------------------------------------------------------------------------------
S1                        SMITH                     20                        LONDON
S4                        CLARK                     20                        LONDON
S2                        JONES                     10                        PARIS

7.5 intersect ()
The intersect operator performs the opposite of union. Again it requires that both of the relations 
are union-compatible. In the date database again, intersecting "a" and "b" will produce the tuples 
that exist in both, which is "smith":
>inext=(a) intersect (b)
INEXT Returned.

>print inext
Relation: INEXT
S                         SNAME                     STATUS                    CITY
--------------------------------------------------------------------------------------
S1                        SMITH                     20                        LONDON

7.6 product ()
As with intersect and union, product is again the same as the set theory Cartesian product. Two 
source relations are specified, and a relation is produced which contains all of the attributes of 
these source relations. The tuples of the resulting relation consist of every possible combination 
of the source relation tuples. An example:
>print simple
Relation: SIMPLE
NAME                      ADDRESS
--------------------------------------------------
JOE                       SCOTLAND
FRED                      WALES
PIERE                     FRANCE

>print simple2
Relation: SIMPLE2
NAME                      ADDRESS
--------------------------------------------------
PADDY                     IRELAND
CHARLES                   ENGLAND
PIERE                     FRANCE

>prd=(simple) product (simple2)
PRD Returned.

>print prd
Relation: PRD
NAME                      ADDRESS                   SIMPLE2.NAME       SIMPLE2.ADDRESS
--------------------------------------------------------------------------------------
JOE                       SCOTLAND                  PADDY              IRELAND
JOE                       SCOTLAND                  CHARLES            ENGLAND
JOE                       SCOTLAND                  PIERE              FRANCE
FRED                      WALES                     PADDY              IRELAND
FRED                      WALES                     CHARLES            ENGLAND
FRED                      WALES                     PIERE              FRANCE
PIERE                     FRANCE                    PADDY              IRELAND
PIERE                     FRANCE                    CHARLES            ENGLAND
PIERE                     FRANCE                    PIERE              FRANCE

7.7 Difference (\)
The difference operator contains all tuples in one relation that are not held in another relation. 
Both source relations must be union compatible. Therefore its possible to use this in order to 
delete tuples from a relation.
>print a
Relation: A
S                         SNAME                     STATUS                    CITY
--------------------------------------------------------------------------------------
S1                        SMITH                     20                        LONDON
S4                        CLARK                     20                        LONDON

>print b
Relation: B
S                         SNAME                     STATUS                    CITY
--------------------------------------------------------------------------------------
S1                        SMITH                     20                        LONDON
S2                        JONES                     10                        PARIS

>diff=(a) difference (b)
DIFF Returned.

>print diff
Relation: DIFF
S                         SNAME                     STATUS                    CITY
--------------------------------------------------------------------------------------
S4                        CLARK                     20                        LONDON
7.8 Join ( |><| )
A conventional (equi-join) Join is identical to performing first a product, and then a select, on two 
relations. The arguments are two relations, and a condition which determines which tuples from 
the source relations are used.
>print r
Relation: R
A                         B                         C                         D
---------------------------------------------------------------------------------
4                         AB                        15                        20
2                         AA                        18                        25
8                         AC                        9                         10

>print s
Relation: S
X                         Y                         Z
---------------------------------------------------------------------------
AB                        20                        PQ
AC                        25                        PR

>rxs=join  (s) (r.b=s.x)
RXS Returned.

>print rxs
Relation: RXS
A       B        C          D	    X		Y		Z
-------------------------------------------------------------------------------
4 	 AB	   15		 20	    AB		20		PQ
8       AC       9		 10	    AC		25		PR

7.9 Divide ()
Divide is widely considered unnecessary. It can be implemented in terms of other relational 
operators, as the example below demonstrates. An example is the best demonstration of the 
divide operator.
>print lc
Relation: LC
LECTURER                  COURSE                    
--------------------------------------------------
BROWN                     COMPILERS
BROWN                     DATABASES
GREEN                     PROLOG
GREEN                     DATABASES
LEWIS                     PROLOG
SMITH                     DATABASES

>print q
Relation: Q
SUBJECT                   
-------------------------
PROLOG

The division of relation lc, by relation q, results in all lecturers in lc, who teach the subject 
specified in q.
>@ divide
>>a1=(lc) product (q)
A1 Returned.
>>a2=project (a1) (lecturer,subject)
A2 Returned.
>>rename (a2.subject) (course)
A2 Returned.

Note that the rename is necessary to ensure that the relations a2 and lc are union compatible 
within LEAP, as domains are not currently supported.
>>a3=(a2) intersect (lc)
A3 Returned.
>>a4=project (a3)(lecturer)
A4 Returned.
>>print a4
Relation: A4

LECTURER                  
GREEN
LEWIS
8. Using LEAP
8.1 Introduction
This section documents the features that are available within LEAP to make its use easier. The 
Features section documents the more advanced features.
8.2 Relations
The relations which exist within a database can be displayed with the list command.
>list
Name        Temporary?
AUCTION         X
BOOK            X
BORROW          X
BRANCH          X
CLIENT          X
CUSTOMER        X
DELIVERY        X
EXAMPLE         X
EX_AUTH         X
EX_BOOK         X
EX_PUBLI        X
GOODS           X
INDEX           X
LC              X
NAMES           X
P3              
P4              
Q               X
R               X
S               X
STOCK           X
SUBJECT         X

Relations can be either temporary or permanent. Temporary relations (such as P3 and P4 
above) are deleted from the disk when the database is closed, either when changing databases, 
or when LEAP is shut down.
To change the temporary status of a relation, use the change command:
>change p3
>list
Name        Temporary?
AUCTION         X
BOOK            X
BORROW          X
BRANCH          X
CLIENT          X
CUSTOMER        X
DELIVERY        X
EXAMPLE         X
EX_AUTH         X
EX_BOOK         X
EX_PUBLI        X
GOODS           X
INDEX           X
LC              X
NAMES           X
P3              X
P4              
Q               X
R               X
S               X
STOCK           X
SUBJECT         X

To delete a relation, use the delete command. Temporary relations will be physically deleted at 
that point. Permanent relations will be removed from LEAP's internal structures, so referencing 
the relation after 'deleting' it will result in an error, as if the relation had been deleted. Deleted 
permanent relations reappear when the database from which the relations was 'deleted' is closed 
and reopened.
The create a relation, use the create relation command. For each attribute, specify an 
attribute, which is either a string or a number. Not specifying an attribute data type will result in 
an error being displayed, and the data type defaulting to the string type.
Information about the data types within relations can be displayed by using the describe 
command, and the contents of a relation can be displayed using the print command:
>create relation crel attribute1 number attribute2 string attribute3 integer
CREL Returned.
>describe crel
ATTRIBUTE1   (NUMBER)
ATTRIBUTE2   (STRING)
ATTRIBUTE3   (NUMBER)

Use the add command to insert data into the relation.
>add crel
Enter data for field ATTRIBUTE1: 1
Enter data for field ATTRIBUTE2: 2
Enter data for field ATTRIBUTE3: 3
Again? (Y/N): n

>print crel
Relation: CREL
ATTRIBUTE1                ATTRIBUTE2                ATTRIBUTE3
---------------------------------------------------------------------------
1                         2                         3

8.3 Command scripts
Entire algebraic expressions can be stored within a command script. Each of the example 
databases within the distribution contain scripts which replicate the examples in the texts. A 
script file is simply a text file with commands. The files should have a .src extension, and can 
be run using the @ symbol, followed by the name of the script.  Available scripts can be listed by 
the "sources" command.
>sources
DISP_EX
EX4_1_A
EX4_1_B
EX41A
EX41B
EX42
EX43
EX45
Q4_3_3
Q4_3_4
Q4_3_5
Q431
Q432
Q433
DIVIDE
OPEN
EX44

>@ q433
>>infix y
Infix operators is on.
>>p3=select (stock) ((branch='L1')and(date_out='INSTOCK'))
P3 Returned.
>>p4=project (p3) (sell_price,cost_price)
P4 Returned.
>>print p4
Relation: P4
SELL_PRICE                COST_PRICE
--------------------------------------------------
15.50                     9.25
>>@

Each script file can contain comments, which are lines beginning with a # - Comments are not 
displayed when the script is executed. In addition to comments, lines beginning with a > are 
displayed, and can be used to explain a scripts operation.
Script files can be reviewed with the l command:
>l q433
Listing C:\LEAP\DATABASE\STANCZYK\SOURCE\Q433.SRC
-------------------------------------------------
# This example is taken from STA90, and uses infix expressions.
# Query 4.3.3 (Page 80)
# "Find sell-price and cost-price of all goods delivered to branch L1
# still in stock."
p3=select (stock) ((branch='L1')and(date_out='INSTOCK'))
p4=project (p3) (sell_price,cost_price)
print p4
@
# LEAP source file - Richard Leyton, 05/06/1995
8.4 Features
8.4.1 Introduction
This section documents the features that are supported by LEAP in order to aid the investigation 
of relational theory topics, both at the relational level, and at the database system level.
8.4.2 Output copy
A copy of all the output that appears on the screen is, by default, stored in the directory specified 
by the TEMP environment variable. The file, LEAP.txt - is written to constantly whilst LEAP is 
running, and should only be reviewed (and especially, altered), only once LEAP has been shut 
down. To disable this option, specify the copy=n command line option.
8.4.3 Operation Timing
LEAP has a rudimentary operation timing option which allows information about operation 
execution time to be gathered. Setting timing on will ensure that for each step of a correct query, 
the time it took, plus the number of read/write operations that took place, will be displayed on the 
screen.
For example, given the query:
project(join (project( select (ex_book) (pname='mit press'))(aname) ) (ex_auth) 
(aname=ex_auth.aname)) (specialism)
Timing information takes the following form:
>timing y
Accuracy is affected in multi-tasking environments.
Operation Timing is on.

>project(join (project( select (ex_book) (pname='mit press'))(aname) ) (ex_auth
) (aname=ex_auth.aname)) (specialism)
Monday, 19/02/1996 - 21:28:05.16 EX_BOOK
Monday, 19/02/1996 - 21:28:05.16 Read 0 tuples.
Monday, 19/02/1996 - 21:28:05.16 Wrote 0 tuples.
Monday, 19/02/1996 - 21:28:05.33  SELECT (EX_BOOK) (PNAME='MIT PRESS')
Monday, 19/02/1996 - 21:28:05.33 Read 6 tuples.
Monday, 19/02/1996 - 21:28:05.33 Wrote 2 tuples.
Monday, 19/02/1996 - 21:28:05.38 PROJECT( SELECT (EX_BOOK) (PNAME='MIT PRESS'))
(ANAME)
Monday, 19/02/1996 - 21:28:05.38 Read 2 tuples.
Monday, 19/02/1996 - 21:28:05.38 Wrote 2 tuples.
Monday, 19/02/1996 - 21:28:05.38 EX_AUTH
Monday, 19/02/1996 - 21:28:05.38 Read 0 tuples.
Monday, 19/02/1996 - 21:28:05.38 Wrote 0 tuples.
Monday, 19/02/1996 - 21:28:05.55 JOIN (PROJECT( SELECT (EX_BOOK) (PNAME='MIT PR
ESS'))(ANAME) ) (EX_AUTH) (ANAME=EX_AUTH.ANAME)
Monday, 19/02/1996 - 21:28:05.55 Read 12 tuples.
Monday, 19/02/1996 - 21:28:05.55 Wrote 2 tuples.
Monday, 19/02/1996 - 21:28:05.60 PROJECT(JOIN (PROJECT( SELECT (EX_BOOK) (PNAME
='MIT PRESS'))(ANAME) ) (EX_AUTH) (ANAME=EX_AUTH.ANAME)) (SPECIALISM)
Monday, 19/02/1996 - 21:28:05.60 Read 2 tuples.
Monday, 19/02/1996 - 21:28:05.60 Wrote 2 tuples.
LEPCHE Returned.

Note the warning when enabling operation timing - If you are running under a multi-
tasking environment such as Windows, LEAP may be stopped by the operating system for 
a short period whilst some essential operation is carried out. This will lead to small and 
large lags, it will also make comparison of runs difficult.
8.4.4 Display Parse Tree
LEAP now contains a two stage parser. Previously LEAP used a recursive parser, but this proved 
slow, inflexible and heavy on memory. The two stage parser has the following steps:
  Build parse tree
  Process parse tree

The first step essentially processes the given expression, and builds an internal representation of 
it. The internal representation will determine how the query is to be executed, and in what order. 
Therefore it may be of interest to see the order in which the expression will be executed.
Displaying the parse tree allows this. For the query given in the operation timing section, the 
following parse tree is displayed:
>parse y
Display Parse Tree is on.

>project(join (project( select (ex_book) (pname='mit press'))(aname) ) (ex_auth) 
(aname=ex_auth.aname)) (specialism)
ROOT NODE
Depth: 0
Expression: PROJECT(JOIN (PROJECT( SELECT (EX_BOOK) (PNAME='MIT PRESS'))(ANAME) ) 
(EX_AUTH) (ANAME=EX_AUTH.ANAME)) (SPECIALISM)
result: <NOT KNOWN>
lresult: <NOT KNOWN>
rresult: <NOT KNOWN>

LEFT NODE
Depth: 1
Expression: JOIN (PROJECT( SELECT (EX_BOOK) (PNAME='MIT PRESS'))(ANAME) ) (EX_AUTH) 
(ANAME=EX_AUTH.ANAME)
result: <NOT KNOWN>
lresult: <NOT KNOWN>
rresult: <NOT KNOWN>

LEFT NODE
Depth: 2
Expression: PROJECT( SELECT (EX_BOOK) (PNAME='MIT PRESS'))(ANAME) 
result: <NOT KNOWN>
lresult: <NOT KNOWN>
rresult: <NOT KNOWN>

LEFT NODE
Depth: 3
Expression:  SELECT (EX_BOOK) (PNAME='MIT PRESS')
result: <NOT KNOWN>
lresult: <NOT KNOWN>
rresult: <NOT KNOWN>

LEFT NODE
Depth: 4
Expression: EX_BOOK
result: <NOT KNOWN>
lresult: <NOT KNOWN>
rresult: <NOT KNOWN>
Returned to Depth: 3 Expression:  SELECT (EX_BOOK) (PNAME='MIT PRESS')
Returned to Depth: 2 Expression: PROJECT( SELECT (EX_BOOK) (PNAME='MIT PRESS'))(ANAME) 
Returned to Depth: 1 Expression: JOIN (PROJECT( SELECT (EX_BOOK) (PNAME='MIT 
PRESS'))(ANAME) ) (EX_AUTH) (ANAME=EX_AUTH.ANAME)
RIGHT NODE
Depth: 2
Expression: EX_AUTH
result: <NOT KNOWN>
lresult: <NOT KNOWN>
rresult: <NOT KNOWN>
Returned to Depth: 1 Expression: JOIN (PROJECT( SELECT (EX_BOOK) (PNAME='MIT 
PRESS'))(ANAME) ) (EX_AUTH) (ANAME=EX_AUTH.ANAME)
Returned to Depth: 0 Expression: PROJECT(JOIN (PROJECT( SELECT (EX_BOOK) (PNAME='MIT 
PRESS'))(ANAME) ) (EX_AUTH) (ANAME=EX_AUTH.ANAME)) (SPECIALISM)
LYOBYG Returned.
This information can be helpful in determining where a query is failing. In order to understand the 
information, the display parse tree operation starts at the root node, and moves to the left most 
node, moving up a level, to the right (if such a branch exists), and then to the left most node. 
This is repeated until the entire tree is exhausted. At each level moved down to, the node is 
displayed:
LEFT/RIGHT
Depth: [level]
Expression: entire relational algebra expression for sub-tree
result: relation name of result of evaluating complete expression
lresult: relation name of the left sub-tree
rresult: relation name of the right sub-tree

Once the entire sub-tree has been displayed, the level to which the display operation has 
returned to is displayed. The last line will be a return to depth 0, and the complete expression 
about to be parsed.
In a later version of LEAP, the processed parse tree will be able to be displayed, such that 
the resulting relations at each step may be inspected. Complete the comment form in 
comment.txt for further features you'd like to see associated with the new two stage parse 
tree.
8.4.5 Nesting expressions
Reviewing the BNF definition of the LEAP language, note that the a relational expression is 
either a relation name, a unary term or a binary term. Therefore, a further expression may be 
specified in place of a specific relation. Examples given in earlier sections have demonstrated 
this, this section explains this in specific detail.
This is the principle of relational closure. Each and every (valid) expression should return a 
relation as a result. For example:
project(join (project( select (ex_book) (pname='mit press'))(aname) ) (ex_auth) 
(aname=ex_auth.aname)) (specialism)
This could be broken down into several self contained expressions:
ab=select (ex_book) (pname='mit press')
cd=project (ab) (aname)
ef=join (cd) (ex_auth) (aname=ex_auth.aname)
gh=project (ef) (specialism)

Where and when to break an expression into component parts is at your discretion. It is certainly 
easier to review and inspect expressions that have been broken down.
8.4.6 Data Dictionary
A data dictionary is described as containing information about information. LEAP's data 
dictionary is, by any measure, small. Its implementation within LEAP B0.10 is as an experiment, 
and its use, if successful, will be expanded in later versions.
The "master" database contains a "LEAPdata" relation, and there are two attributes "name" and 
"dir". When a database name is specified in a "use" command, to change databases, this table is 
read, and two things are determined
  Whether the database name is valid
  Which directory the database is contained in

In the long term this will be extended to allow more complex database names, but for now the 
name is identical to the directory name, and limited to eight characters.
8.4.7 Data Cache
New to LEAP B0.10 is a small data cache feature. It can be enabled as a command line option 
(cache=y) and is disabled by default. This is because at the time of release, the cache only 
operated correctly for small (cardinality 20 or smaller). Larger relations will not be displayed 
correctly. It is not recommended that this be used for anything other than experimentation on 
small relations.
In order to improve performance of LEAP, which can be atrocious when a large number of 
relations are processed, an operating system disk cache (such as smartdrv) will demonstrate 
significant performance gains.
8.4.8 Debug Information
When writing relational expressions and queries, sometimes it won't quite work in the way that 
was planned. Enabling debug information will provide more information in the report file than 
normally. 
For considerably more information (and an idea about how LEAP approaches some database 
design issues), the trace command line operation can be enabled. Be aware that trace 
information varies from subsection to subsection, and that in some cases the noise level is 
extremely high. In order to put trace information into the report file, you must enable debug as 
well.
8.4.9 Case Sensitivity
LEAP B0.10 contains case sensitivity. By default this is disabled, but may be enabled through a 
command line option or at the LEAP prompt. When enabled, expressions are evaluated and 
case features as an additional rule. The following example best demonstrates.
>case y
Case Sensitivity is on.

>print lc
Relation: LC
LECTURER                  COURSE
--------------------------------------------------
BROWN                     COMPILERS
BROWN                     DATABASES
GREEN                     PROLOG
GREEN                     DATABASES
LEWIS                     PROLOG
SMITH                     DATABASES

>select (lc) (course='prolog')
LDBICZRN Returned.

>print ldbiczrn
Relation: LDBICZRN
LECTURER                  COURSE
--------------------------------------------------

>select (lc) (course='PROLOG')
LDBKBBCG Returned.

>print ldbkbbcg
Relation: LDBKBBCG
LECTURER                  COURSE
--------------------------------------------------
GREEN                     PROLOG
LEWIS                     PROLOG

8.4.10 Adding messages to the report file
User messages may be added to the report file by using the report command:
>report About to execute the divide script
Reported: ABOUT TO EXECUTE THE DIVIDE SCRIPT

>@ divide
>>a1=(lc) product (q)
A1 Returned.
>>a2=project (a1) (lecturer,subject)
A2 Returned.
>>rename (a2.subject) (course)
A2 Returned.
>>a3=(a2) intersect (lc)
A3 Returned.
>>a4=project (a3)(lecturer)
A4 Returned.
>>print a4
Relation: A4
LECTURER
-------------------------
GREEN
LEWIS
>>@

Results in the following additions to the report file:
Saturday, 24/02/1996 - 17:07:26.67 : User Report: ABOUT TO EXECUTE THE DIVIDE SCRIPT
Saturday, 24/02/1996 - 17:07:30.46 : Relation A1 Returned.
Saturday, 24/02/1996 - 17:07:30.57 : Relation A2 Returned.
Saturday, 24/02/1996 - 17:07:30.62 : Relation A2 Returned.
Saturday, 24/02/1996 - 17:07:30.79 : Relation A3 Returned.
Saturday, 24/02/1996 - 17:07:30.84 : Relation A4 Returned.
8.5 Online Help
LEAP has online help, and provides immediate access to information about all of the LEAP 
commands. A summary of the help topics available can be displayed by typing:
help index
A three page help summary is available by typing
help
Information on a specific topic is displayed by typing
help [topic]
Where topic is a topic listed in the help summary above.
8.5.1 Help Index
Here is the complete help index:
>help index
Help subjects within the help file:
HELP                      PROMPT                    ATTRIBUTE
PROJECT                   ALGEBRA                   ASSIGNMENT
RESTRICT                  SELECT                    CONDITION
JOIN                      UNION                     UNION COMPATIBILITY
DISPLAY                   INTERSECT                 MINUS
DIFFERENCE                PRODUCT                   LIST
SOURCES                   L                         @
PRINT                     DELETE                    TEMPORARY
PERMANENT                 CHANGE                    DESCRIBE
DATA TYPE                 MEM                       NORMAL
HIGH                      STATUS                    NESTING
INFIX                     PREFIX                    EXPRESSION
INFO                      QUIT                      DEBUG
TIMING                    COMMAND LINE              CREATE
COPY                      COLOUR                    COLOR
USTIME                    CACHE                     INDICIES
USE                       DATA DICTIONARY           RENAME
DUPLICATE                 ITERATIVE                 PARSE
TRACE                     COMPATIBILITY             ABOUT
BOOKS                     CONTACTS                  LEAP VERSION NUMBERS
HELP VERSION HISTORY
===============================================================================

LEAP - An Extendable Relational Algebra Processor. Beta Version #0.10.0d
Copyright  Richard Leyton 1994,1996. Ver.Date 19th February 1996

8.6 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 
warmly encouraged.
There is no recommendation in this text for one database book over another, but the examples 
have been chosen out of preference and the extent of the examples. This section will briefly 
summarise the examples, and provide a rough summary of the book contents.
8.6.1 stanczyk
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 
(Please correct me if I'm wrong).
8.6.1.1 Walkthrough
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 does not 
distinguish between "equi", and "natural" joins, and therefore a project operation is used which 
produces the same result. The results can be directly compared.
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 actually incorrect!
8.6.1.2 Summary
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.
Stanczyk, S. Theory and Practice of Relational Databases, Pitman, 1990, ISBN 0-273-03049-3
8.6.2 Date
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. It
8.6.2.1 Walkthrough
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.
Join, as noted in the discussion on the stanczyk database, is implemented as an equi join, rather 
than a natural join. Natural joins can be 'kludged' by projecting all but one of the common 
attributes into another relation. The njoin script contains an the example in figure 6.7
Theta-joins can be implemented directly in LEAP, the example from fig 6.8 - In fact, its 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.
8.6.2.2 Summary
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

9. Changes in LEAP B0.10
LEAP B0.10 contains a number of changes, which are explained here in more detail than the 
changes.txt file:
9.1 Release under GNU General Public License
LEAP is now distributed under the GNU General public license, a copy of which (in the file 
copying) is included in the LEAP distribution. Please refer to this for full details.
9.2 A form for feedback is included in the distribution.
User comment is the best source of information for determining how and where to improve 
LEAP. Please take the time to complete this form, and add any comments you might have. (See 
section 10 on page 28)
9.3 Infix expressions are the default format. Prefix are still supported
Previously LEAP required expressions to be specified in a prefix form (operator (rel) (rel)), and 
some of the expressions were rather ugly and hard to get to grips with. In order to preserve 
compatibility with older versions of LEAP, prefix expressions were the default. 
9.4 Implemented a "duplicate" operator.
Its sometimes necessary to make an exact duplicate of a relation. You can now do this without 
messing around with the operating system.
9.5 Multiple data types supported.
In earlier versions of LEAP, only strings were supported as a data type. With B0.10, numeric 
data types are supported. Support for other data types will be implemented in later versions.
9.6 Duplicate tuples are not permitted, and this is enforced internally.
Earlier versions of LEAP did not enforce this critical rule. Now all relations may not contain 
duplicates under any circumstances.
9.7 Hash tables maintained between runs, and for all relations.
Previous versions of LEAP did store hash table information between runs of LEAP. Infact the 
hash table was built at each invocation of a relational operator on a specific table. Hash tables 
are now created for every table, and permanent relations' hash tables are written to disk between 
runs.
9.8 An iterative two stage parser
Until now, a recursive operator has been used to process a relational algebra expression within 
LEAP. When porting to Windows, this caused severe problems. As such, the planned two stage 
parser was implemented earlier than intended to reduce these problems. This feature will enable 
a query optimiser to be implemented at a later stage if desired.
9.9 Character delimited text files, with support for old format
The old format used for storing relations was inefficient and inflexible. LEAP B0.10 uses 
character delimiters to use disk space more effectively. The old format is supported.
9.10 A small data dictionary is used
And it really is small. LEAP has a small data dictionary for validating database names. Over 
time, the data dictionary will be expanded to encompass more operations within LEAP.
9.11 Duplicate attributes are handled consistently.
Previous versions of LEAP would not handle attribute names in a reliable format when a 
duplicate was detected. Therefore it became possible to create a relation which had two 
identically named attributes. LEAP now prefixes the source relation name to the attribute name if 
an identical attribute is already present.
9.12 Far fewer file handles required.
A bug was discovered which led to an inordinate number of file handles being required, 
especially when lots of relations existed. In fixing the bug, fewer file handles are necessary, and 
multiple databases further reduces the required number of file handles needed at any one time.

10. Feedback form
This version of LEAP has a considerable number of changes to earlier versions. It is therefore 
possible that it contains bugs. LEAP is also far from complete, and there are bound to be areas 
in which it can be improved and extended.

This file contains a series of questions which it is hoped, you will find the time to complete, and 
return. Your comments are valuable as you are actually using LEAP, and know what you want
better than anybody else. Please feel free to answer as many or as few questions as you like, 
and add any further comments at the end.

Send the completed form via e-mail, or via conventional mail, to the address at the base of the 
letter. 

Your comments (however many, few, complimentary or critical) are valuable!

Which version of LEAP are you using?
	 B0.9
	 B0.10
	 Other : __________________

What OS/environment are you using to run LEAP?
	 MS-DOS
	 Windows
	 Linux
	 Other : __________________

Where did you find out about LEAP?
	 Usenet/Netnews
 	 WWW link (URL appreciated): http://_____________________
	 College lecture
	 CD-Rom (Vendor appreciated): ___________________________
	 Magazine cover disc (Magazine appreciated): ____________
	 Public domain library: _________________________________
	 FTP site: ftp://________________________________________
	 Other: _________________________________________________

If you're a student, where is it that you study?


What course is it that you're enrolled upon?
	

What is the recommended reading for your course?


Does your college have a WWW home page?
	http://


Where are you running LEAP?
	 Personal computer
	 College computer
	 College network
	 Other: _________________________________________________


What problems have you experienced with LEAP?



Lack of functionality:



Crashing:
What error was reported (if any):


Does it occur randomly, or is it reproducible?


Does it stop your use of LEAP?


How serious would your rate the error (1 not at all serious, 5 extremely serious):


How would you rate the following aspects of LEAP:
1 - Excellent, 2 - Good, 3 - OK, 4 - Poor, 5 - Very poor
(Leave blank any questions you don't have an opinion about)

Category
Rating
Use as an educational tool

Documentation

Ease of use

User interface

Supported OS

Installation Instructions

Online Help

Internet Information

Available ftp sites

Available shareware/pd archives/libraries

Other:

Other:


How would you rate the importance of the following features, which are planned for future 
releases (Please add any comments you might have about the suggested list, or add your own 
suggestions/priority):

1 - Definitely required; 2 - Needed feature; 3 - "Nice to have", but not really necessary; 4 - Not 
really necessary; 5 - Totally unnecessary

Category
Rating (1-5)
Query Optimizer

Delete operation

Primary/Candidate Keys

Foreign Keys

Implementation of divide, summarize and
extend, and other additional algebraic
operators

More examples from other texts

Integrity constraints

Domains

Different languages for documentation

Freely available source code

Support for more OS

More extensive Data Dictionary

More trace information

More timing information

More accurate timing information

Views

Document discussing LEAP internals



The following questions are deliberately open ended. Please feel free to say as much, or as little, 
as you like.

What do you like about LEAP?



What don't you like about LEAP?



What would you like to see in LEAP that currently isn't present?



What would you like to see removed from LEAP?



What additional information would you like to see in LEAP?




Do you think more information/documentation on relational database theory might be 
useful?



Is there any information you feel is superfluous?



Are there any sites/companies/colleges you think would benefit from receiving a copy of 
LEAP? Please give contact details.



If you've read the WWW pages (whether live on the internet, or in the LEAP distribution), 
what are your thoughts?

Please do not feel obliged to complete the following information. If you don't wish your e-
mail address to be known to me, please make use of an anonymous remailer, such as 
help@anon.penit.fi

What! is your name?

What! is your favorite colour?

What! is the airspeed velocity of an un-laden swallow?

Preferred e-mail address:


Address:

Age:


Do you mind being contacted about the comments contained in here?
	> Yes - Don't send me a damn thing.
	> No - Don't mind one bit, old chap.
 
If you don't mind being contacted, how would you prefer being contacted?
	> E-Mail 
	> Conventional Mail

Before you go, please remember that LEAP is a freely distributable program, and that you are 
encouraged to distribute it to others. All I ask is that the distribution is the standard distribution 
that is available on the Internet. Feel free to add new databases, so long as it is not distributed as 
the complete version, but as a modified version of the original. See the file distrib.txt for more 
information.

Thankyou for taking the time to complete this form. Your comments are very much appreciated, 
for better or for worse! Please send them via e-mail or conventional mail to one of the following
addresses:

E-Mail: mailto://richard_leyton@mail.amsinc.com
Mail: Richard Leyton, 3 Pelting Drove, Priddy, Wells, Somerset, BA5 3BA, England
WWW pages: http://www.brookes.ac.uk/cms/students/richard_leyton/LEAP.html

LEAP User Manual

LEAP User Manual

26

31


