Introduction

In this last part of the assignment you will complete the query language you have been building in programs 3 and 4. In this assignment you should build on the code you have been completing. In the routine evaluate_query you should set up a mechanism to output the result of each type of query.

The Query Language

Queries come in four basic forms:

1. [ RelationName RelationVariable ] - this is the most basic form. This type of query simply establishes a connection between a named relation and a corresponding relation variable. This type of query should mostly appear as a part of a more complex query (see below). It should establish a connection to that particular relation through the relation variable. If this query is used at the top level the resulting relation should simply be printed in full in a nice form.
2. PROJECT ( RelVar1.AttrName1 , RelVar2.AttrName2, ... ) ( QueryItem ) - a project should take a subquery item QueryItem (the result of a project, select or join query or a connection to a relation (1) above) and project down to these fields (note that duplicates need not be eliminated). The fields to be projected to should appear as a list. Each attribute is indicated using relation variables (from QueryItem) and corresponding attribute names separated by a period.
3. SELECT ( Condition ) ( QueryItem ) - a select has a similar syntax to the previous DELETE item, except that rather than deleting the matching tuples, the matching tuples should simply be shown in a nice table.
4. JOIN ( Condition ) ( QueryItem1 ) ( QueryItem2 ) - a join is applied to all pairings of tuples from the tuples generated by query items QueryItem1 and QueryItem2. A pair should appear in the output when the condition Condition is true about the tuples being considered from QueryItem1 and QueryItem2. Note that the join condition may mention relation variables from both QueryItem1 and QueryItem2.

What To Add

You should complete the code you worked on in program 4. The basic pieces for the queries are already attached to the code. You will likely want to add evaluation routines to the nodes corresponding to PROJECT, SELECT and JOIN queries.

NOTE NOTE:In order to make this project easier and because it is coming at the end of the semester, you will only be responsible for implementing each operation indenpendently. You do not need to implement operators such that they can be composed. For example, you will need to implement code to work on queries like this:

  PROJECT (S.sid, S.sname) ([Sailors S]);
  SELECT (S.sid == 5) ([Sailors S]);
  JOIN (S.sid == R.sid) ([Sailors S]) ([Reserves R]);

but not for a query like this:

  PROJECT (S.sname) (SELECT (S.sid == 5) ([Sailors S]));

You are only responsible for implementing queries that have one PROJECT, SELECT or JOIN operation.

Implementation Requirements

There are no special implementation requirements. You may implement any access method you like for resolving project and select queries and any join mechanism.

Extra Credit

This program will include a number of opportunities for extra credit. You may complete any of the following (note that extra credit points will not be considered when assigning grade breakpoints, but will be used in final grade assignment).

• Use the index for tuple access where appropriate (5 points) - when the query accesses tuples from a relation, if part of the condition for selecting or joining the tuples matches the index for that relation, index scanning rather than full scanning is used. In addition, implementing an index nested loop join mechanism is worth an additional 5 points.
• Full projection including eliminating duplicates (10 points) - this would require the implemenation of an external sorting method and then scanning the sorted results for duplicate tuples.
• Implementing a block nested loop join method (10 points) - this would require determining an appropriate number of pages to use for the relation held in memory (must be careful about this if you implement full query evaluation, see next).
• Full (nested) query evaluation (30 points) - implemented queries within queries.

What to Turn In, and When

Print out your versions of all the code you add. You should test your code by showing examples of the various query commands. Note that you should test your code extensively considering many possible combinations of commands. You should hand in copies of all of your tests. Next, write up a team report of how your code is implemented. This report should give an overview of how you completed the various sections of this project. It should also discuss the algorithms you used to solve the problem. This report should be at least two pages long but no longer than four pages. Each team member should also write up an individual report (at least half a page but no more than a page) discussing their contributions to the coding process and how the overall team interaction went.

You must also submit your code electronically (but only once for each team). To do this go to the link https://webapps.d.umn.edu/service/webdrop/rmaclin/cs4611-1-s2004/uploa d.cgi and follow the directions for uploading a file.

To make your code easier to check and grade please use the following procedure for collecting the code before uploading it:

• Store all of the code in a subdirectory named prog05 under a subdirectory named for your login. For example, if your login is rmaclin, all of the code should be stored in the directory

  rmaclin/prog05

  Note that the suffix of all C++ code files (not .h files) should be ".C". Only code files (only rules files, .c, .C, and .h files) should be stored in this directory.
• Tar the contents of this file using the command:

  tar cf prog05.tar login/prog05

• Upload the resulting file (named prog05.tar) to the web site as discussed above.