Tuesday, June 26, 2012

There is a way to represent the schema of a database in text. Of course a diagram is very helpful in visualing the relationships, but you can also write out the schema if you have to. Suppose we have the following from the Access Relationship Designer. It is a diagram of one of the simple databases we use in class. The purpose of the database is to record hours worked by employees in a factory on various work orders.

We can represent this in text with a few conventions: bold for a required field, italic for foreign key and underline for primary key. List the table name and then the field names in parentheses.This yields the text schema below.

Employees(empno, fname, lname, rate, mgrno)
Labor(empno, wono, start, end, hours)

Note the composite primary key in the labor table. Each column is also a foreign key.

You might find this technique useful if dashing off a quick Email or you are without your favorite drawing tools.

Thursday, June 14, 2012

Left Outer Join with Partial Match
There are some subleties to outer joins involving partial matches. We have looked at joins where we want to show all the rows from the one side of a relationship. Or conversely the rows from the one side that have no matches on the many side. But what if we want to see all the rows from the one side and only a subset from the many side? For eaxmple show all my customers along with their orders for last year. Our first pass at this might be something like the query below.

But this will not work since the filter for 1999 orders effectively masks out the effect of the outer join. We don't want to filter out customers, just orders. The missing values should be replaced by nulls as is normal for outer joins.

The solution to the above is to prefilter the orders and then join the results of that to the customers using an outer join. We can prefilter the orders in a derived table or inline view using the following syntax.


select columns
from table1
left join
(select statement) derived table alias
on table1 key = derived table key

Sample Code
Here is the actual code using the bookstore database (download from Box.net).


Here is an extract of the results of running the above query, Emily Jones and Mary Collins did not place any orders in 1999 but were still listed.

Follow Up
We will expand on this concept in future additions to this post. Hopefully this post will have shown you how to work with outer joins that partially match. It also provided a look at inline views or derived tables which we will cover in more detail in other posts.

Tuesday, June 5, 2012

Left Outer Join

This post shows how to create a left outer join. Outer joins are often used in reporting. It also shows how to modify the outer join to create a "find unmatched" query.

Outer Joins
When you join two tables in SOL the default join type is an inner join. This means that only rows with matching key values from each table are retrieved. For example if I join customers with their orders I will not see customer names with no orders. But it is common in reporting that you want to see all rows from the "one" side of the relationship even if there is no match. In the above example I might want to see all my customer names even if they have not placed an order yet. This is accomplished with an outer join. They come in three flavors: left, right and full.
  • Left - all matched rows plus unmatched from the "left" table. Note that left refers to reading order. It means the first table mentioned in the query, the one to the "left".
  • Right - all unmatched plus unmatched from the right table. The unmatched from the right table would imply they are orphan records since their foreign key did not refer to an existing parent record.
  • Full- not often seen. Adds unmatched from both left and right tables. 
We will present an example of the left outer join, which is the most common, below. This example uses the bookstore database which can be downloaded from box.net.

Left Outer Join Syntax
Here is the basic syntax for a left outer join. We will assume the "one" side is the left table. Note the word outer is optional.

Select columnlist
from table1
left [outer] join table2
on table1.primarykey = table2.foreignkey;

Below is an example using the bookstore database.

Below is a section of the result set. Note that when there is no match the missing values are filled in as nulls by SOL. In the results below the Browns have not placed any orders.

Unmatched (Negative) Left Outer Join
Suppose you want to list all customers who have not placed an order. You can do this by creating a left outer join from the customers table to the orders table. As we have seen this will produce a list of all customers along with their orders. The list will include customers that have not placed any orders since a left join includes all rows from the left table. You can restrict the result set to only those who have not placed orders. Do this by adding a where clause to test for null order numbers. The order number is the primary key in the orders table and wouldn't be in the result set as a null unless it was generated by the left join. This is a common query to test for missing information or missing records.

select columnlist
from table1
left [outer] join table2
on table1.primarykey = table2.foreignkey
where table2.primarykey is null;

Below are the results using the bookstore sample database. (In reality you might not want to show the order columns).

More to follow...
There is another type of unmatched join where there is a partial match. For example: list all customers and the titles of books they bought that were written by a certain author. Include all customers even if they did not buy any books from the given author. We will cover this in a subsequent post and in our Intermediate SOL course (SQL302 & 312).

Saturday, June 2, 2012

Calculated Fields

It is a simple matter to perform calculations in a query. The result of the expression is placed in a new column in the result set. You can give the calculated field a name, too. These calculated fields are sometines called computed columns. Don't confuse them with aggregate functions which do calculations in a sense but don't create a new column in the result set.

Here is a simple example from the bookstore database. (Remember that the use bookstore statement only applies to SQL Server and MySQL. Oracle and Access don't use it.)