Introduction

The fourth part of the RedBase system you will implement -- the last part of the basic project -- is the Query Language (QL) component. This component implements the language RQL (for "RedBase Query Language"). RQL's data retrieval command is a restricted version of the SQL Select statement. RQL's data modification commands are restricted versions of SQL's Insert, Delete, and Update statements. The public methods of the QL component are called by the RedBase parser, similarly to the way SM component methods were called by the parser in Part 3. The QL component will use classes and methods from the IX, RM, and SM components. We'll first specify the syntax of RQL and explain what the RQL commands should do from a user's perspective. Then we'll specify the QL interface, which includes the methods that support the commands.

Warning or special treat, depending on your preference: Significantly more creativity and design work is required to implement this component than any of the previous components. We've defined the interface precisely, but there's lots to be done underneath the interface, and there are many different ways of doing it. We suggest that you think very carefully and thoroughly about how your program will operate before beginning implementation. In addition, if you're attempting to win the RedBase Efficiency Contest, then this component is one of the most important and is also your last chance! As mentioned above, there are numerous ways of implementing the QL interface -- some ways are much more efficient than others in terms of I/O, so you'll want to think, design, and code carefully in order to execute queries efficiently and best exploit the efficiency you've already built into your previous components.

QL Interface

QL_Manager is the only class in the QL interface. It contains four public methods, corresponding to the four RQL commands described above. The QL interface also includes a QL_PrintError routine for printing messages associated with nonzero QL return codes. Before beginning work on the QL component you should run the setup script with argument "4" (for project part 4). It will copy a simple QL tester, similar to the one provided for the SM component, and it will recopy ql.h and ql_manager_stub.cc so that you have the latest versions of these files.

You should rename ql_manager_stub.cc as ql_manager.cc, then complete the implementation. As usual, all QL component public methods (except constructors and destructors) should return 0 if they complete normally and a nonzero return code otherwise. Parser handling of nonzero return codes is exactly the same as in Part 3: If the parser receives a nonzero return code it will use the value of the return code to call the appropriate component's PrintError routine. If the return code is positive, the parser will resume with the command loop; if the code is negative, the parser will terminate the command loop.

QL_Manager Class

• As always, all necessary component initialization should take place within the constructor for the QL_Manager class, and all "cleanup" should take place within its destructor.

• When implementing the public methods of the QL_Manager class, in addition to adhering to the method descriptions below, please refer to the RQL command descriptions given above.

• If you treated user-specified names as case-sensitive (respectively, case-insensitive) in the SM component, then you should probably continue to do the same in this component. As in the SM component, all user-specified names are passed from the parser exactly as they are typed by the user.

• The SM component interface from Part 3 exports the methods that implement the RedBase DDL and system utility commands, along with methods OpenDb and CloseDb. In the QL component you will almost certainly find a need to use other functionality you implemented in Part 3; surely you will at least need to obtain schema information from the system catalogs relcat and attrcat. Consequently, in order to implement Part 4, you will probably need to allow the QL component to access some classes and methods that you may have treated as private in the SM component for Part 3. (Depending on how you implemented SM, you may even find it convenient to enhance the SM component to some extent, for convenience in implementing QL methods.)

• As usual, you are free to extend the QL interface if you find it convenient, although you should not modify the existing methods since they are called by the parser as specified.

• All printing of relations (including query answers) in this component must be done through the Printer class we provided with the SM component. Please do not alter the way you print tuples or relations -- our test suite depends on conformance.

• Values passed to QL component methods are handled as follows. The parser recognizes whether it is reading an integer, a float, or a string. It converts the input to the appropriate type; then when it calls the QL component method it passes a structure that contains the type of the value along with a pointer to the value cast as (void *). The type information allows you to check that the type of the value is the type expected (based on schema information), and you will need to cast the value back from (void *) to its appropriate type.

• In attribute-constant and attribute-attribute comparisons, you are not required to perform coercion so that integers and floats can be compared, but you are welcome to do so if you wish. For strings, you should permit the case where the two values being compared are strings of different length. You can do so by null-terminating or null-padding the shorter one.

• Before specifying the interface for the QL_Manager class, we define several structures that are used in passing parameters from the parser to QL_Manager methods. These structures are defined in parser.h. The ostream operator in each of these structures is provided so that structure values can be sent to standard output for debugging purposes (i.e., by writing "cout << <object>;").

struct RelAttr {
  char *relName;     // relation name (may be NULL) 
  char *attrName;    // attribute name              
  friend ostream &operator<<(ostream &s, const RelAttr &ra);
};

struct Value {
  AttrType type;     // type of value               
  void     *data;    // value                       
  friend ostream &operator<<(ostream &s, const Value &v);
};

struct Condition {
  RelAttr lhsAttr;      // left-hand side attribute                     
  CompOp  op;           // comparison operator                          
  int     bRhsIsAttr;   // TRUE if right-hand side is an attribute
                        //   and not a value
  RelAttr rhsAttr;      // right-hand side attribute if bRhsIsAttr = TRUE
  Value   rhsValue;     // right-hand side value if bRhsIsAttr = FALSE
  friend ostream &operator<<(ostream &s, const Condition &c);
};

class QL_Manager {
 public:
                                              // Constructor
      QL_Manager (SM_Manager &smm, IX_Manager &ixm, RM_Manager &rmm);
      ~QL_Manager ();                         // Destructor
   RC Select (int           nSelAttrs,        // # attrs in Select clause
              const RelAttr selAttrs[],       // attrs in Select clause
              int           nRelations,       // # relations in From clause
              const char * const relations[], // relations in From clause
              int           nConditions,      // # conditions in Where clause
              const Condition conditions[]);  // conditions in Where clause
   RC Insert (const char  *relName,           // relation to insert into
              int         nValues,            // # values to insert
              const Value values[]);          // values to insert
   RC Delete (const char *relName,            // relation to delete from
              int        nConditions,         // # conditions in Where clause
              const Condition conditions[]);  // conditions in Where clause
   RC Update (const char *relName,            // relation to update
              const RelAttr &updAttr,         // attribute to update
              const int bIsValue,             // 0/1 if RHS of = is attribute/value
              const RelAttr &rhsRelAttr,      // attr on RHS of =
              const Value &rhsValue,          // value on RHS of =
              int   nConditions,              // # conditions in Where clause
              const Condition conditions[]);  // conditions in Where clause
};

RC Select (int nSelAttrs, const RelAttr selAttrs[], int nRelations, const char * const relations[], int nConditions, const Condition conditions[])

Method QL_Manager::Select contains the core of the work you will do for the QL component. The main requirement is that when the user enters a valid RQL Select command, sooner or later the correct result according to the semantics described above should print on the screen. There are many options you will need to consider when implementing this method; some design requirements and suggestions follow.

Your implementation should build a query tree, which will first serve as your logical query plan and then will be transformed into a physical plan. We strongly suggest using an iterator approach for plan execution, although you may use a temporary relation approach instead if you have valid reasons for doing so.

Regardless of other design decisions you make, we would like your query execution strategy to be able to take advantage of indexes whenever it is (relatively) straightforward to do so. In particular:

• Suppose the query includes a local selection condition of the form R.A=v, where v is a constant value. If relation R has an index on attribute A, then an IX component index scan together with calls to method RM_FileHandle::GetRec can be used to fetch the tuples of R, rather than using an RM component file scan. (Hereafter, we use "index scan" to mean an IX component condition-based scan together with tuple fetching, and "file scan" to mean an RM component scan.)

• You may use a simple nested-loop algorithm for each join or cross-product. Suppose you are joining R with S based on attribute equality, suppose S has no local selection condition, and suppose S has an index on its join attribute A. Then you can make S the inner relation of the nested-loop join and use an index scan on S instead of a file scan. (You need not, however, attempt to reorder the relations in the query in order to make such index joins possible.)

RC Insert (const char *relName, int nValues, const Value values[])

RC Delete (const char *relName, int nConditions, const Condition conditions[])

Any number of conditions is allowed. Let R be relation *relName, suppose there is a condition of the form R.A=v where v is a constant value, and suppose R has an index on attribute A. Then you can use an index scan to efficiently fetch those tuples of R satisfying R.A=v. For each fetched tuple, check the remaining conditions and, if they are all satisfied, delete the tuple. If there is no condition with an appropriate index, then a file scan should be used. Each tuple is fetched, the conditions are checked, and if satisfied the tuple is deleted. Don't forget to delete corresponding index entries when you delete a tuple.

Although the execution strategies for Delete commands generally are simpler than for Select commands, you should still build physical query plans for Delete. You will probably find that some physical operators from your implementation of Select can be reused.

To provide feedback, this method should print the deleted tuples on the screen (using the Printer class).

RC Update (const char *relName, const RelAttr &updAttr, const int bIsValue, const RelAttr &rhsRelAttr, const Value &rhsValue, int nConditions, const Condition conditions[]);

QL_PrintError

void QL_PrintError (RC rc);

Printing Query Plans

Your implementations of the RQL Select, Delete, and Update commands should ultimately build a physical query plan before actually executing the query. Query plans are not required for Insert commands. Your system should provide a way to pretty-print physical query plans for Select, Delete, and Update commands before the command is executed. You will probably want to render tree-structured plans using some form of indentation.

Query plans should be printed only when the value of special global variable bQueryPlans is 1. Two administrative commands are provided in the parser for toggling the bQueryPlans variable:

queryplans on;	Turn on the display of query plans
queryplans off;	Turn off the display of query plans

You must #include "parser.h" in ql_manager.cc, or any other files that access the bQueryPlans variable.

Documentation, Testing, Submission, Etc.

• The requirements for documentation and the method of submission are the same as for previous project parts, including citing in your ql_DOC file any assistance that you received on this component. In this submission please remember to include all updated source files and the three executables: redbase, dbcreate, and dbdestroy. All executables that you turn in must be compiled with statistics on.

• Remember to thoroughly test your system with large relations and complex queries and updates. (For example, we strongly suggest that you devise your own data in addition to the data provided in our sample files.) As usual, we will conduct tests of our own during the grading process.

• At the same time that we test each student's QL component for grading purposes, we will be benchmarking each student's complete system to determine the winners of the efficiency contest. If you prefer that we not benchmark your system for the contest, please notify the TA.