This chapter is from the book
This chapter is from the book
This chapter is from the book
Creating Other Types of Joins
So far you've worked only with inner joins, which is as it should be because inner joins are by far the most common, particularly in a business environment. However, the three other types of joins—outer, self, and theta—can also come in handy and are discussed in the next three sections.
Creating Outer Joins
An outer join is one where all the records in one table are included in the dynaset regardless of whether there are matching records in the other table. For example, suppose you're dealing with Northwind's Customers and Orders tables, which are related on the common CustomerID field. An inner join between these tables shows only those customers who have placed orders. By contrast, an outer join on the Customers table displays all the records from that table, even customers who have never placed an order.
There are two types of outer joins:
Left outer join—This join displays all the records from the "left" table. For example, in tables with a one-to-many relationship, the left outer join displays all the records from the "one" table.
Right outer join—This join displays all the records from the "right" table. For example, in tables with a one-to-many relationship, the left outer join displays all the records from the "many" table.
To set the type of outer join, follow these steps:
-
Add the tables to the query design window.
-
Create the relationship between the tables, if one doesn't exist.
-
Choose View, Join Properties. Access displays the Join Properties dialog box, shown in Figure 3.12.
-
Option 1 creates an inner join. To change to an outer join, click either 2 (for a left outer join) or 3 (for a right outer join).
-
Click OK.
)
Figure 3.12
Use the Join Properties dialog box to select the type of join you want.
Using Outer Joins to Find Records Without Matching Records in a Related Table
The most common use for outer joins is to look for records in one table that don't have a matching record in some related table. For example, you can look for records in the Customers table that have no corresponding records in the Orders table; this tells you which customers have not yet placed orders. Similarly, you can look for records in the Products table that have no corresponding records in the Categories table; this tells you that you have a data entry problem because all products should have a category.
As a general rule, to see only those records without matching records in a related table, do one of the following:
-
To see records in the parent table without matching records in the child table, create a left outer join and filter the dynaset by adding Is Null as the criteria for the common field in the child table.
-
To see orphan records in the child table (that is, records in the child table without any corresponding records in the parent table), create a right outer join and filter the dynaset by adding Is Null as the criteria for the common field in the parent table.
The next two sections take you through examples of these techniques.
Finding Customers Without Matching Orders
For example, suppose you want to see a list of customers who haven't yet placed an order. This means you want to join the Customers table and the Order table, which are related on the CustomerID field. You start by displaying all the Customers. This means, because Customers is the parent of Orders, you need to create a left outer join. Figure 3.13 shows the query setup, including the fact that option 2 (left outer join) is chosen in the Join Properties dialog box. Figure 3.14 shows the resulting dynaset.
)
Figure 3.13
A query set up for a left outer join between the Customers and Orders tables.
In Figure 3.14, notice that the first two records in the Custom field is blank. This tells you that these are the records in Customers that have no matching records in Orders, meaning they haven't yet placed any orders. Therefore, rather than displaying all the records, filter the dynaset to show only those where the CustomerID field of the Orders table is equal to Null. Figure 3.15 shows the revised query that adds this criterion.
)
Figure 3.14
The dynaset created by the query in Figure 3.13.
){kind=small}
Figure 3.15
To see only those customer without matching orders, add the expression Is Null to the Orders.CustomerID field.
Finding Products Without an Assigned Category
In the Products table, each record should have been assigned an item from the Categories table. To make sure, you can build a query that looks for those Products without a matching category. This requires joining the Products table and the Categories table, which are related via the CategoryID field. Because Products is a child of Categories, you need to create a right outer join. You then add the CategoryID field from the Categories table and filter it using the Is Null criterion, as shown in Figure 3.16.
){kind=small}
Figure 3.16
To find those products without an assigned category, create a right outer join and filter the Categories.CategoryID field using the Is Null expression.
Creating Self-Joins
Database tables are sometimes self-referential, which means they contain a field with data that points to another field in the same table. A good example is the Northwind Employees table, which includes an EmployeeID field, the primary key that contains the employee identification numbers. Employees also contains the ReportsTo field, which contains the identification number of the person each employee reports to. In other words, each value in the ReportsTo field will have a corresponding value in the EmployeeID field.
If you want to know, for example, which employees have people reporting to them, you need to create a self-join—a table joined to itself—on the Employees table. Creating a self-join involves the following steps:
-
Start a new query and add the table (Employees in this case) twice.
-
Create a temporary join by clicking and dragging the field that contains the data (EmployeeID) to the field that contains the subset of the data (ReportsTo).
-
Add the fields you want to use for the query to the design grid and then set up your criteria, sorting, and other query elements.
-
For a self-join to work properly, you need to tell Access to return only unique values in the query. To do this, click an empty spot inside the query design window and then choose View, Properties (or press Alt+Enter). In the Query Properties window, click Yes in the Unique Values list and then close the window.
For more about the Unique Values property, see "Creating a Unique Values Query."
Figure 3.17 shows a self-join on the Employees table, and Figure 3.18 shows the resulting dynaset, which displays the employees who have people reporting to them.
){kind=small}
Figure 3.17
A query set up for a self-join on the Employees table.
){kind=small}
Figure 3.18
The dynaset created by the query in Figure 3.17.
Creating Theta Joins
The joins you've seen so far have all worked on the premise that the join is based on the equality between two fields. In an inner join, for example, you only see records where the joined fields from both tables are equal; similarly, in an outer join, you see all the records from one table, but only those records from the second table where the joined fields are equal.
In business, however, it's sometimes the case that you need a join that's based on fields that are unequal. For example, Northwind's Customers table has a CompanyName field, and its Orders table has a ShipName field. In most cases, these values should be the same; that is, if a customer places an order, that order should be sent to that company. If the shipping name isn't the same as the customer name, it might mean either that the order was sent to the wrong company or that the company name is wrong in one table or the other. (It's also possible that the order is correct and that the customer asked for the shipment to be sent to a different ship address.)
To check into this type of scenario, you need a not-equal join that joins two tables and shows only those records where the joined fields from both tables are not equal; for example, joining the Customers and Orders tables based on whether the CompanyName and ShipName fields are not equal.
Here's the procedure to follow to create a not-equal join:
-
Start a new query and add the tables you want to work with (such as Customers and Orders).
-
If no relation exists between the tables, create a temporary join by clicking and dragging the appropriate field from one table and dropping it on the related field in the other table.
-
Add the fields you want to use for the query to the design grid and then set up your criteria, sorting, and other query elements. Be sure to include the fields on which the not-equal join will be based (such as CompanyName from the Customers table and ShipName from the Orders table).
-
In the Criteria cell of the field for which you want to check for not-equal values (such as the Orders table's ShipName field), enter a comparison formula using the following general form:
Here, RelatedTable is the name of the other table in the query, and JoinedField is the field from the other table that is joined to the current field. Here's an example for the Orders.ShipName field:
Figure 3.19 shows a not-equal join between the Customers table and the Orders table, with the not-equal criterion added for the Orders.ShipName field. Figure 3.20 shows the resulting dynaset, which displays the orders where the shipping name is different from the customer name. Notice that query has caught two subtle errors:
-
For the customer "Galeria del gastrónomo," the accent is in the wrong place in the ShipName field ("Galeria del gastronómo").
-
For the customer "Wolski Zajazd," the CompanyName field has two spaces between "Wolski" and "Zajazd."
){kind=small}
Figure 3.19
A query set up for a not-equal join on the Customers and Orders table to look for orders where the ShipName is not equal to the CompanyName.
)
Figure 3.20
The dynaset created by the query in Figure 3.19.