Table of Contents
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.
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.
LEAP takes several command line parameters when it is started:
Where options are specified seperately:
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:
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.
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
(.rel in LEAP 1.0 and earlier)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.
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] :-) NAME ------------------------- leaprel leapattributes leaptypes relship leapscripts auction book delivery ex_auth ex_book ex_publi example goods index lc names q r s stock subject Message: Relation zzzcbx returned.To print a particular relation, for example the "book" relation, type "print book":
[stanczyk] :-) print book
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 author --------- JOYCE GREENE ORWELL LEM GOLDING KING HEMINGWAY 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:
There are two ways. Firstly, specifying each operation on a seperate line and using assignment of results:
subjcl=project (subject) (class)
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) )
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!
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:
To print the contents of a script, type:
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
project (expression) (attrib1, attrib2,
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.
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.
( [value|attribute] <,<=,=,>=,>,<>,~ [value|attribute] )
values must always be contained within quotation marks (single or double).
( attrib = "value" ) - TRUE
whenever attrib contains "value"
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.
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.
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.
add (ex_auth) (ANNAME,GERMANY,TEXTBOOKS)
To insert a blank value, specify a dash (-), eg:
add (ex_auth) (ANNAME,-,TEXTBOOKS)
The relations are removed from internal structures, and the disk. Therefore you cannot nest the delete command.
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:
And then change into the database with:
[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 NAME ------------------------------------------------------------------------------- leaprel leapattributes leaptypes relship leapscripts Message: Relation zziclt returned. [example] :-) use Valid databases are: -------------------- master user tempdb stanczyk date korth example
To review the variables, type: vars
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
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.
When padding is enabled, all attributes have their source relation added to the start.
When set to some number NN, that number is used to specify the maximum width for the attribute.
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.
! 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.
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
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.
Send e-mail to the author: Richard Leyton - email@example.com
Write to the author: Richard Leyton, c/o 3 Pelting Drove, Priddy, Wells, Somerset, BA5 3BA, England.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-announcehttp://leap.sourceforge.net
The LEAP web page has a number of additional database texts.
The book has the best relational algebra section going, to my knowledge.
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.
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.
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.
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.
Date, c.j., An introduction to database systems, 6th Edition, Addison-Wesley Publishing Company, 1995, ISBN 0-201-82458-2
This book is not available at the time
of writing the user manual, and therefore a walkthrough is not possible.
$Id: userguide,v 1.2 1998/01/29 22:25:13
rleyton Exp rleyton $
Monday, 13th August, 2001