RELATIONAL QUERY LANGUAGES

Transcription

1 RELATIONAL QUERY LANGUAGES These comments we make on the relational data model are a short introduction to the types of query languages which can be used against a relational database. Before we start we need to clear up a little notation. A table consists of a collection of user data presented in tabular form. A table has rows, one row for each individual real-world thing the table models as a group and columns, one column for each piece of information about the real-world things modeled by the table. We refer to the table schema as the list of column headers. A table schema is an empty table. as for naming conventions we use a capital letter to start a table name, Cardholder, lower-case letters for column names, b-name, and underlined table names to represent table schemas, Cardholder. For much of these notes we will use Venn Diagrams as a modeling tool for building our queries. We ll see that viewing tables as sets is no handicap in understanding either relational algebra or SQL. In a Venn Diagram we represent a set as a circle. The label beside a circle indicates what elements belong to the set. The area outside a circle is understood to be another set called the compliment which contains all elements not in the set. In both A AND B A B In neither A nor B In A and not B In B and NOT A In theory, query languages divide themselves into two groups - relational algebra-type languages and relational calculus-type languages. In practice, most query languages are a combination of the two. Relational Algebra The identifying feature of a relational algebra-type query language is that it treats a table like a set. Therefore, the operations it uses are operations against sets (tables) whose results are other sets (tables). These operations are: SELECTION PROJECTION CARTESIAN-PRODUCT UNION 1

2 INTERSECT SET-DIFFERENCE JOIN QUOTIENT We will see examples of these operations before looking at a particular query language. SELECTION We can think of SELECTION as taking a (horizontal) subset of the rows of a table. Only those rows where the where condition is satisfied are selected. SELECT <table_name> WHERE <condition> /* this condition is satisfied by each row in the answer */ Find the Cardholders from Modena. SELECT Cardholder WHERE b-address = Modena The answer consists of all rows in the Cardholder table where the b-address column has the value Modena. borrower# b-name b-address b-status 2653 mike Modena senior NOTE: Selection works on one table at a time. If you need data from several tables in your answer you need to combine these tables before you select any rows from the combined tables. PROJECTION Just as SELECTION creates what looks like a horizontal subset of the rows of a table, PROJECTION creates a vertical subset in the sense that certain of the columns are suppressed and duplicate rows in the answer table are also suppressed. PROJECT <table_name> OVER <column_list> /* mention the columns you want to keep */ Find the addresses of all Cardholders. PROJECT Cardholder OVER b-address 2

3 The answer consists of all rows in the Cardholder table where only the b-address column shows. If more than one cardholder lives at the same address we don t show this as two distinct rows in the answer table. b-address New Paltz Rosendale Modena Kingston Tilson NOTE: Just like SELECTION, PROJECTION works on only one table at a time. It automatically eliminates duplicate rows in the answer table. This is usually the last operation performed in a relational-algebra query since it produces just the columns we are after in our answer. CARTESIAN-PRODUCT This operation comes straight from mathematics. The CARTESIAN-PRODUCT of two sets consists of a set of ordered pairs (called tuples, the first element in an ordered pair coming from the first set and the second from the second. Cartesian products can involve sets whose elements are themselves tuples. In this case the elements of the cartesian product are tuples formed by combining the original tuples into one long tuple. <table_name> x <table_name> Cartesian-products are usually uninteresting because they combine everything with everything. Suppose we construct the following tables. NAMES = PROJECT Cardholder OVER b-name and ADDRESSES = PROJECT Cardholder OVER b-address Now suppose we form the cartesian-product of these two small tables. NAMES x ADDRESSES At first glance the resulting table would not seem to be very interesting because it holds every cardholder name matched against every cardholder address. Hence this table, by itself, can t help us determine who lives where. I divide the rows of this table into two groups - information and noise. The information rows are those which correspond to the real-world. The noise rows are those which do not correspond to the real world. The cartesian product consists of just two kinds of rows, information and noise. One of the beauties of relational-algebra (and SQL, for that matter) is that we have operations in both 3

4 languages capable of building the information part of a table if we can identify the noisy part. By the way, the mathematical definition of a relation is that it is a subset of a cartesian product. The name Relational Database comes from the fact that all tables in a well-defined and well-maintained relational database are just the silent subsets of some rather noisy cartesian products. UNION The UNION of two tables works by treating the two tables as sets and trying to combine the two sets of rows into a single table. For rows from different tables to fit into the same table we would need, as an a priori condition, that the two original tables look alike. That is to say, they must have the same schema. Otherwise the union operation can not be applied to the tables. Once we know that two tables have the same schema we can perform the union. The resulting table holds all the rows from either of the tables with no dupicate rows. <table_name_1> UNION <table_name_2> Find the borrower numbers of all cardholders who have borrowed OR reserved a book on December 8. Dec8Reserves = SELECT Reserves WHERE r-date = Dec 8 Dec8Borrows = SELECT Borrows WHERE l-date = Dec 8 Reservers = PROJECT Dec8Reserves OVER borrower# Borrowers = PROJECT Dec8Borrows OVER borrower# Answer = Reservers UNION Borrowers Reservers Borrowers Reservers or Borrowers INTERSECT INTERSECT works under much the same constraints as UNION. We treat the two tables as sets and try to combine elements of the two sets of rows into a single table. For rows from different tables to fit into the same table we would need, as an a priori condition, that the two original tables look alike. That is to say, they must have the same schema. Otherwise the intersection operation can not be applied to the tables. Once we know that two tables have the same 4

5 schema we can perform the intersection. The resulting table holds all the rows found in both of the tables with no dupicate rows. <table_name_1> INTERSECT <table_name_2> Find the borrower numbers of all cardholders who have borrowed AND reserved a book on December 8. Dec8Reserves = SELECT Reserves WHERE r-date = Dec 8 Dec8Borrows = SELECT Borrows WHERE l-date = Dec 8 Reservers = PROJECT Dec8Reserves OVER borrower# Borrowers = PROJECT Dec8Borrows OVER borrower# Answer = Reservers INTERSECT Borrowers Reservers Borrowers Reservers and Borrowers SET-DIFFERENCE SET-DIFFERENCE works under much the same constraints as UNION and INTERSECT. We treat the two tables as sets and try to select rows from one table and not the other into a single table. For rows from different tables to be at all comparable we would need, as an a priori condition, that the two original tables look alike. That is to say, they must have the same schema. Otherwise the set difference operation should not be applied to the tables. Once we know that two tables have the same schema we can perform the operation. The resulting table holds all the rows found in just one of the tables. <table_name_1> MINUS <table_name_2> Find the borrower numbers of all cardholders who have reserved BUT NOT borrowed a book on December 8. Dec8Reserves = SELECT Reserves WHERE r-date = Dec 8 Dec8Borrows = SELECT Borrows WHERE l-date = Dec 8 Reservers = PROJECT Dec8Reserves OVER borrower# Borrowers = PROJECT Dec8Borrows OVER borrower# 5

6 Answer = Reservers MINUS Borrowers Reservers Borrowers Reservers but not Borrowers JOIN JOIN is the first relational algebra operation which is substantially new to people familiar with set theory. The idea behind join is to combine tables using their common columns as the joining factor. Since these common columns are usually primary and secondary keys this operation is quite natural. Join is really a combination of three other relational algebra operations - CARTESIAN PRODUCT, SELECT and PROJECT. First you CARTESIAN PRODUCT the two tables concerned. Next you choose the rows in the CARTESIAN PROD- UCT which have the common columns having the same values. Finally you PROJECT out one of the common columns since the row values are identical. JOIN (<table_name_1>, <table_name_2>) [OVER <column_name_list>] or JOIN (<table_name_1>, <table_name_2>) WHERE table_name_1.column_name # table_name_2.column_name NOTE: # means any one of the operators =, <, >,!=, *= or =*. Find the cardholders who have borrowed a book on December 8. Temp = JOIN (Cardholder, Borrows) Answer = SELECT Temp WHERE l-date = Dec 8 This query gives a flavour of relational algebra. Unlike SQL where all operations are bunched into a single command, in relational algebra you do things one step at a time - procedurally!! Join itself is really the composite of three simpler operations. Temp = JOIN (Cardholder, Borrows) can be written Temp1 = Cardholder x Borrows Temp2 = SELECT Temp1 WHERE Cardholder.borrower# = Borrows.borrower# Answer = PROJECT Temp2 OVER Cardholder.borrower#, b-name, b-address, b-status, accession#, l-date 6

7 In other words, a JOIN is just a CARTESIAN PRODUCT followed by a SE- LECT and finished off with a PROJECT. EXERCISE: Show that if R S = then JOIN(R,S) = R S. EXERCISE: Show that if R = S then JOIN(R,S) = R * S. QUOTIENT As a query, QUOTIENT is probably the most counter intuitive. However it comes from a very simple concept in integer arithmetic. Suppose n is an integer and d is another integer we wish to divide into n. Asking the question How many times does d divide into n? is just another way of asking What is the quotient q = n/d? An appropriate definition of integer quotient is the following: DEFINITION 1: The quotient of n by d is the largest integer q such that q d n. Now switch our thoughts to tables. Suppose we have two tables, N and D. Suppose further that we define the following: DEFINITION 2: Let N and D be tables. The quotient table of N by D (written N/D) is the largest table Q such that Q D N. To make sense out of this definition we need to know what it means to multiple two tables and what it means for one table to be less than or equal to another table. If we view tables as sets of rows then the natural cognate of less than or equal to is subset of. The only product we ve seen with respect to tables is the cartesian product. Hence we could rewrite Definition 2 as DEFINITION 2 : Let N and D be tables. The quotient table of N by D (written N/D) is the largest table Q such that Q D N where means cartesian product. Just as with INTERSECT and UNION there are consequences of this definition regarding schemas. Since Q D N as sets, they must, as tables, have the same schemas. Hence Q D = N. In other words, the columns in N consist of precisely the columns in D together with the columns in the Q. Moreover, since a row in the cartesian product, Q D, involves combining all the entries of Q and D there can t be any duplicate columns in Q and D. Hence Q D =. Next, by saying that Q is the largest table such that Q D N we are saying two things: 1. any row of Q concatenated with every row of D is a row in the original table N and, 2. since Q is the largest table with this property no rows that are not in Q satisfy this property. An example is the best way to see QUOTIENT. Find all those cardholders (name and address) who have reserved 7

8 every book published by Prentice-Hall (PH). PHBooks = SELECT Book WHERE pub-name = PH PHISBN = PROJECT PHBooks OVER ISBN /* identifiers of all PH books */ AllReservations = PROJECT Reserves OVER borrower#, ISBN /* all reservations; no dates */ Ans1 = AllReservations / PHISBN Ans2 = JOIN (Ans1, Cardholder) Answer = PROJECT Ans2 OVER b-name, b-address How does QUOTIENT find all cardholders who have reserved all PH books? The key to understanding QUOTIENT is to see what allows a value to belong to the quotient table. First, since AllReservations = {borrower#, ISBN} and PHISBN = {ISBN} it is clear that if Ans1 P HISBN AllReservations that Ans1 = {borrower#}. So at least Ans1 holds the right kind of values. Secondly, for a borrower# to belong to Ans1, it must already belong to AllReservations combined with every PH book. In other words, the corresponding cardholder must have already reserved every PH book. Since Ans1 is the largest table whose CARTESIAN PRODUCT with PHISBN lies inside AllReservations, Ans1 must contain the borrower# of every cardholder who has reserved every PH book. This example should tell us something about QUOTIENT and any query which contains the word all in the condition. Neither of these is trivial and they go together. In general, query complexity can be measured by the presence of words such as all, only, not, none and combinations of these words. Notation Name Symbol Meaning Table R, S, T a collection of rows headed by column headers Table Schema R a list of column names of a table Column A, B, C the name atthe top of a table column Row r, s,t an entry in a table Set of Columns X, Y, Z a subset of a Table Schema Domain Dom(A) the set of possible values of a column Column Value r[a] the value in row r and column A Column List Value r[x] the values in row r for the columns in X Def n: A key to a table is a subset, X, of its schema such that any two rows which agree on X are identical. In symbols this is stated: X is a key if r[x] = s[x] implies r = s where r and s are rows of the table in question.. Def n: A superkey to a table is any subset, X, of the table schema which contains a key. In symbols: if X is a key to R and X Y R then Y is a 8

9 superkey of R. Def n: A candidate key is a key which does not contain a proper subset which is also a key. In symbols: X is a candidate key of a table R if X R, X is a key of R and there does not exist Y X such that Y is a key of R. Def n: A primary key of a table is any chosen candidate key. 9

10 The Library Database Cardholder borrower# b-name b-address b-status 1234 john New Paltz senior 1345 albert Rosendale senior 1325 jo-ann New Paltz junior 2653 mike Modena senior 7635 john Kingston junior 9823 diana Tilson senior 5342 susan Walkill senior Book ISBN title author pub-date c-price pub-name 1-23 DB Ullman CSP 2-34 Netw T baum PH 3-56 Queue K rock Wiley 4-76 SysD J son PH 1-52 DB Date AW 6-99 MMM Br kes AW 7-45 Arch Baer CSP Status b-status loan-limit junior 2 senior 4 Reserves ISBN borrower# r-date Dec Dec Dec Dec Dec Dec Dec Dec 10 10

11 Copy accession# p-price ISBN qt-76.4c qt-78.2c qt-78.2c qs-77.3c qs-77.3c qs-77.3c qs-77.3c qs-77.3c qs-77.3c qp-91.2c qt-76.5c qt-76.5c qt-76.5c qt-75.5c qt-75.3c qt-75.3c Borrows accession# borrower# l-date qt-76.4c Dec 1 qs-77.3c Dec 14 qt-76.5c Nov 30 qt-75.5c Dec 8 qt-78.2c Dec 4 qt-75.3c Dec 4 qt-76.5c Dec 9 qt-76.5c Dec 12 qt-75.3c Dec 1 qt-78.2c Nov 28 11