SQL Unit 6Set Operations

Kirk Scott

• 6.1 Introduction• 6.2 UNION Queries• 6.3 Queries with IN (Intersection)• 6.4 Queries with NOT IN (Set Subtraction)• 6.5 Unions, Joins, and Outer Joins

6.1 Introduction

• 1. The technical term for a table is a relation. A relation is like a set.

• The technical term for a row in a table is a tuple. • A tuple is like an element in a set. • The fundamental difference between an element

of a set and a tuple in a relation is that the tuple may be a composite.

• It may contain values for more than one different attribute.

• The similarity between sets and relations explains some of the aspects of relations.

• The order of elements in a set is immaterial; likewise, the order of tuples in a relation is immaterial.

• A set can't contain duplicate elements; likewise, a relation can't contain duplicate tuples.

• 2. Recall the logical operator OR. • This allowed you to make conditions on the

values of attributes. • There is also a set level operation, union,

which is related in meaning. • Union applies not to attribute values, but to

collections of tuples in relations.

• Given two sets, A and B, you may recall this definition of union from math class:

• = the union of A and B • = the set of elements in A or in B or in both A

and B

BA

• In this Venn diagram, both A and B and the area where they overlap are shaded, indicating that they all are included in the union.

A B

• Microsoft Access SQL has the keyword UNION, which implements the idea behind a logical union.

• 3. Here is a simple example illustrating the use of the union operator.

• Suppose that table A and table B have each been defined with the same number of fields, of the same type, in the same order.

• The names of the fields don't have to be the same.

• Then consider this query:• • SELECT *• FROM A• UNION• SELECT *• FROM B

• The results will contain the set of rows that were in A or B or both, but because the query uses a set operator, and duplicates are not allowed in sets, any row that might have occurred in both A and B will only appear once in the results.

• 4. The previous example specified that the tables in the two parts of the query had to have the same number of fields of the same type and in the same order.

• It wouldn't do to have records in the same result table which varied in the number of fields they contained.

• It also wouldn't do for numeric fields to hold non-numeric values, and vice-versa.

• Having a correspondence between fields in the two parts of the query is known as union compatibility.

• The specific requirements for this are:• A. The corresponding fields in the two parts

of the query should mean the same thing. This may be referred to as semantic equivalence.

• B. If the corresponding fields are of exactly the same type and size, there is no problem at all.

• The formal requirements are less stringent though:• • i. All numeric fields are union compatible with each

other.• ii. All text fields are union compatible with each other.• iii. All date fields are union compatible with each other.

• In cases where the types of the fields are not the same, but they are union compatible, the "larger" of the two types will be used in the results.

• Given two union compatible types, one type can always hold values of the other type.

• A text field with a large width can hold the values of a text field with a smaller width.

• A numeric type that can have decimal points can hold integer values.

• Since the one that can hold the other is used in the results, no data will be lost when a union is done.

6.2 UNION Queries

• 1. Here is a concrete example of a union query using tables and fields from the cardealership database:

• • SELECT *• FROM Car• WHERE make = 'Chevrolet'• UNION• SELECT *• FROM Car• WHERE make = 'Toyota'

• This query illustrates the relationship between the UNION operator and the OR operator.

• Because the two parts of the query are on the same table, the following query would accomplish the same thing:

• • SELECT *• FROM Car• WHERE make = 'Chevrolet'• OR make = 'Toyota'

• In this query the Car table is the "universe", and the query finds the union of two disjoint subsets of the Car table, because no car could have two different makes at the same time.

• This is the Venn diagram for the query:

make = 'Chevro-let'

make = 'Toyota'

Car

• 2. Here is another example of a union query. • The two parts of the query are based on two

different tables:• • SELECT name, addr, city, state• FROM Customer• UNION• SELECT name, addr, city, state• FROM Salesperson

• Because two tables are involved, it would not be possible to accomplish this with the OR operator.

• Notice that there is no problem with union compatibility because the corresponding fields in the two tables were defined in exactly the same way.

• The Venn diagram for this query is more typical than the previous diagram.

• The same person could be both a salesperson and a customer.

• The results of the query would include all customers, all salespeople, and anybody who fell into both categories.

Custom-ers

Sales- people

• A union can be thought of as a vertical combination of two tables:

UNION

• 3. As noted previously, the union operator eliminates duplicates from the results of a query.

• If by chance you would like to do a union and not have the duplicates eliminated, you would use the keywords UNION ALL:

• • SELECT city• FROM Customer• UNION ALL• SELECT city• FROM Salesperson

• There is a side effect related to eliminating or keeping duplicates in the results.

• When plain UNION is used, the duplicates will be eliminated and the results will typically be sorted in some order.

• The explanation is that the system uses the following approach to eliminate duplicates:

• First it sorts the records. After sorting, duplicates should be next to each other.

• Then the system finds and eliminates them.

• 4. It is possible to do unions where one part of the query doesn't have fields corresponding to the fields in the other part.

• Those fields that correspond have to be union compatible.

• For those fields without corresponding fields, nulls have to be used.

• Recall that the schemas for Customer and Salesperson look like this:

• • Customer(custno pk, name, addr, city, state,

phone)• Salesperson(spno pk, name, addr, city, state,

phone, bossno, commrate)

• Here is an example of a union query where all of the fields of the Customer table are matched with the explicitly listed corresponding fields of the Salesperson table:

• • SELECT *• FROM Customer• UNION• SELECT spno, name, addr, city, state, phone• FROM Salesperson

• If you would like to keep all of the fields from the Salesperson table while also including all of the records from the Customer table in the results, you could do this:

• • SELECT *, NULL, NULL• FROM Customer• UNION• SELECT *• FROM Salesperson

6.3 Queries with IN (Intersection)

• 1. Among the concepts of set theory, along with union, there is intersection and there is the idea of set containment.

• Given two sets, A and B, here is the definition of union again, along with the definitions of intersection and containment:

• = the union of A and B = the set of elements in A or in B or in both A and B

BA

• = the intersection of A and B = the set of elements that A and B have in common

BA

• = A is contained in B; as a proposition this is either true or false, either the elements of A are also in B, or they're not

BA

• In this Venn diagram, the area where A and B overlap is crosshatched, indicating that this is the area in the intersection.

A B

• This Venn diagram signifies that A is contained in B:

A

B

• Microsoft Access SQL does not have keywords for intersection or containment, but it does have this operator:

• • IN• • Using IN it is possible to write expressions that check

whether or not a given set of tuples is included in another set.

• This makes it possible to find the intersection of two sets.

• 2. It is possible to specify a set of values in SQL by enclosing the values in parentheses (not curly braces) and separating them with commas.

• This first example of the use of the keyword IN involves such a set:

• • SELECT *• FROM Car• WHERE make IN ('Chevrolet', 'Toyota')

• This query is equivalent in results to the following query already seen above:

• • SELECT *• FROM Car• WHERE make = 'Chevrolet'• OR make = 'Toyota'• • The results of the query are the union of two sets.

• 3. The more general use of the keyword IN occurs when a set of values in a query is defined by a subquery rather than a set listed in parentheses.

• An example is shown below. • Notice that its structure is similar to the

foregoing examples.

• The outer query selects from a table where some field value is in or is not in the set specified by the subquery:

• • SELECT name• FROM Salesperson• WHERE spno IN• (SELECT spno• FROM Carsale)

• This query illustrates the ideas of intersection and containment.

• You're selecting the names of salespeople whose spno's appear in the Carsale table.

• Because of referential integrity, every spno in the Carsale table has to appear in the Salesperson table.

• That means that the set of spno's from the Carsale table is a subset of the spno's in the Salesperson table.

• Not every salesperson has to have sold a car, so not necessarily every spno in Salesperson appears in the Carsale table.

• When you find the intersection between the two, it is simply the set of spno's from Carsale.

• This is a Venn diagram of the situation:

Carsale spno's

Salesperson spno's— get the names from this table

• The query finds the names of salespeople who sold cars.

• Notice that because of the way this query is structured as a set query, a salesperson's name will appear only once in the results, even if that salesperson sold more than one car.

• In other words, a given spno may occur more than once in the Carsale table.

• However, in the outer query, when checking whether a given spno is in the set defined by the subquery, the answer is either yes or no.

• If the answer is yes, then the spno is valid in the outer query, but it only appears there once.

• The "IN" can be read as "squeezing out" duplicate occurrences of spno.

• Then in the outer query, for each distinct spno, the one corresponding name is shown.

• 4. Here is another example of an IN query with a subquery.

• It shows the stickerprices of cars that sold.• • SELECT stickerprice• FROM Car• WHERE vin IN• (SELECT vin• FROM Carsale)

• This is the Venn diagram for this query. • Since not all cars have sold, the Carsale vin's

will be a subset of the Car vin's:

Carsale vin's

Car vin's— get the stickerprices from this table

• The previous example illustrated how the use of IN can remove duplicates.

• IN has that effect on the results of the subquery, but duplicates can still arise in the overall results.

• In this example, among the cars that sold, there are two of them with a stickerprice of 18,000.

• 18,000 will show up twice in the results of the query.

• The explanation for this is that in the Carsale table as given, cars can only be sold once, so their vin's show up there only once.

• The use of IN would check to see whether a car had been sold more than once and eliminate any duplicates if it had, but that would have no effect in this example because there are no duplicate car sales.

• However, once execution reaches the outer query, for whatever set of vin's the inner query found, you select the stickerprice.

• If two different vin's have the same stickerprice, that stickerprice will be shown twice in the overall results of the query.

• 5. In the previous two example queries, one table is opened in the inner query and another is opened in the outer query.

• In order to do an IN query, the inner query has to select exactly one field, and there has to be a field which corresponds to it in the table of the outer query.

• In the examples given, the names of the corresponding fields, vin and spno, were the same in the inner and outer queries.

• There was no need to fully qualify the field names because the parentheses serve as a barrier between the inner and outer queries.

• Inside the parentheses the field name belongs to the table of the inner query.

• Outside of the parentheses the field name belongs to the table of the outer query.

6.4 Queries with NOT IN (Set Subtraction)

• 1. Among the concepts of set theory, along with union, intersection, and containment, there are two more concepts to consider:

• complement or negation; • and set subtraction. • Given two sets, A and B, here are the

definitions of complement and subtraction:

• A' = the complement of A = the set of elements not in A

• A – B = the difference between A and B = the set of elements which are in A but not in B

• This Venn diagram shows the complement of A:

A'

A

• This Venn diagram shows A – B:

A - B B

• Microsoft Access SQL does not have separate operators for complement or set subtraction.

• However, it does have this operator:• • NOT This is negation or complement• • Using NOT, you can negate expressions and

effectively find a complement. • Using NOT IN, you can accomplish set subtraction.

• 2. It is possible to negate the initial query of the previous section.

• This gives a straightforward example of the use of NOT IN:

• • SELECT *• FROM Car• WHERE make NOT IN ('Chevrolet', 'Toyota')

• The results of this query are the complement of the results of the plain IN query of the previous section.

• This is the Venn diagram for the negated query, where once again, it is the shaded area which is included in the results:

Car

make = 'Toyota'

make = 'Chevro-let'

• 3. The non-negated version of the query, which simply used IN, could be interpreted as an OR query.

• The negated version of the query under discussion here, which uses NOT, can be regarded as the negation of an OR query.

• Once you start negating logical expressions, you need to be careful in interpreting what the results might be.

• The following query is approximately logically equivalent to the NOT IN query:

• • SELECT *• FROM Car• WHERE make <> 'Chevrolet'• AND make <> 'Toyota'

• If you negate something that can be regarded as an OR, you get the AND of the two parts negated separately.

• Likewise, if you negate something that can be regarded as an AND, you get the OR of the two parts negated separately.

• The following two rules are DeMorgan's Laws for sets.

• They give the general result described here:

'')'( BABA

'')'( BABA

• The reason why the AND query is only approximately equivalent to the NOT IN query has to do with null values.

• The query with AND will return records where make is null.

• The NOT IN query will not return records where make is null.

• To understand why, look at the NOT IN query again:

• • SELECT *• FROM Car• WHERE make NOT IN ('Chevrolet', 'Toyota')

• The logic of this is that a null is not a value at all.

• Null could never be an element of a set. • When you use the set operator NOT IN, the

system will only return actual values that occur in the set of values for make.

• It will not return null as a value.

• 4. Here is a more general NOT IN query, where the set is defined by a subquery:

• • SELECT stickerprice• FROM Car• WHERE vin NOT IN• (SELECT vin• FROM Carsale)

• Here is the Venn diagram for this query:

Car vin's— get the stickerprices from here

Carsale vin's

• The meaning of this is straightforward. • It finds the stickerprices of cars that haven't

sold. • There are no surprises because the field in

question, vin, is the primary key of both the Car and Carsale tables, so it will never be null.

6.5 Unions, Joins, and Outer Joins

• 1. Part of the relationship between unions and outer joins was brought up in a previous unit:

• A join can be thought of as a horizontal combination of two tables:

JOIN

• A union can be thought of as a vertical combination of two tables:

UNION

• A full outer join can be found with the union of a left join and a right join on the same two tables:

• • …LEFT JOIN…• UNION• …RIGHT JOIN…

• 2. It is also possible to do an outer join with the help of set operators.

• To get started on this topic, here is a review of what an outer join is.

• A left or right outer join is a join that includes all of the records from both tables that match on the joining field, plus it includes all of the records from one of the tables, either left or right, that don't have a match on the joining field.

• For those that don't have a match, it supplies NULL as the value for the fields that come from the other table.

• This is a left join on the Car and Carsale tables:• • SELECT *• FROM Car LEFT JOIN Carsale• ON Car.vin = Carsale.vin

• This will give a result table containing records for all cars, both those sold and unsold.

• For those that sold, there will be values for the fields vin (from the Carsale table), spno, custno, salesdate, and salesprice.

• For cars that didn't sell, those fields will be null.

• 3. It's not important to be able to do an outer join using UNION, NOT, and IN.

• The outer join syntax is easier. • However, writing an outer join query with the

set operators gives an additional chance to see them used to accomplish a desired result.

• The first part of the problem is simple.

• This plain join will give all of the records which have matches:

• • SELECT *• FROM Car, Carsale• WHERE Car.vin = Carsale.vin

• This nested query with NOT IN will find the records of all of the cars that didn't sell, and it will put the value NULL into unspecified fields in the result table that will correspond to the five fields of the Carsale table:

• • SELECT *, NULL, NULL, NULL, NULL, NULL• FROM Car• WHERE vin NOT IN• (SELECT vin• FROM Carsale)

• The left join is completed by finding the UNION of the two previous results:

• • SELECT *• FROM Car, Carsale• WHERE Car.vin = Carsale.vin• UNION• SELECT *, NULL, NULL, NULL, NULL, NULL• WHERE vin NOT IN• (SELECT vin• FROM Carsale)

The End