CHAPTER 12 USING INNER JOINS IN A QUERY
Some programs, generally called file managers, are limited to manipulating and extracting data from
only one table at a time. However, most commercial database management systems (DBMS) can have
many tables ‘open’ at the same time and can combine information from them to provide answers to
our questions. As we saw in the previous chapters, we can “relate” information from one table to
another by the use foreign key fields, setting up one-to-one and one-to-many relationships.
Thus far we have learned to use queries to sort records, filter data, aggregate information, and to
perform arithmetic calculations on fields. In this chapter we will learn to do these tasks using
information from two or more tables of data.
THE JOINING PROCESS
The queries presented in Chapter 11 used data from only one object (table or query). Queries become
much more powerful when information from two or more objects can be combined. The join
operation combines records from two tables. In order to properly employ this tool, it is necessary
to understand, at least in part, the process the computer carries out for a join operation. This chapter
will explore the default Inner Join operation.
AN EXAMPLE
Consider the Members and Donations tables from the sample database. The Members table contains 7
records and the Donations table contains 6 records. As previously discussed, the records of these
tables can be related by matching the foreign key ID#. So how does Access create the dynaset from a
query listing by transaction the member name, donations? This query will require the transaction
information from the Donation table and the corresponding member name from the Members table.
When creating an inner join in Access, the computer first generates a “master list” of all combinations
of the records from both tables. All the elements of each record are treated as a single unit regardless
of the number of fields in that record. The entire record from the first table is matched to each
complete record of the second table. The resulting master list will contain 42 (7*6) different
combinations. The master list resulting from the join of these two tables is shown in Figure 1. What
does each of these master records represent?
In Figure 1, notice that many of these combinations generated have very little practical meaning.
Records are put together that don’t make sense; the name of one member is matched with the dues
paid of another. However, consider the master records that have been created where the foreign key
field ID# values match (highlighted records) as seen in this example.
If the objects specified in a query have no foreign key relationship defined, the resulting dynaset will
simply be this master list with both meaningful and meaningless combined records. However, if a
foreign key relationship is specified, Access will continue the join process by selecting only those
records with matching foreign key values, as highlighted in Figure 2. This then provides us with only
related information.
Page 1
Figure 1
Figure 2
When an inner join is performed on a specific field the computer will use only those records
from the master list where the join on fields match. There are 6 records with matching
values in the join field creating a joined record set, as seen in Figure 2. This record set does not
include any members who did not make a donation nor would it include any donations associated
with a member ID# not on the Members table (this would only happen if Referential Data Integrity is
violated). Hence, an inner join will only include those records on one table that have
matching records on the other table.
Once the combined record set is determined, the additional parameters of the query will be applied; if
the query also contains select criteria, sorting instructions, aggregate functions or calculated fields,
these will then be applied based on the combined record set only.
Page 2
DESIGNING QBE GRIDS FOR QUERIES WITH A SINGLE JOIN
Now consider some examples of writing queries that join two tables. The techniques/limitations of
joining three or more tables will be discussed in a subsequent section.
Query 1: List the last name and donation amount for every donation that was greater
than $25.
First plan this query:

What fields will be shown? Member’s last name (Members table), donation (Donations table).

What fields will have criteria that are not shown? there are none.

What criteria are needed? The donations field must be >25.

What tables will we need?
Donations table.
Fields identified reside on either the Members table or on the
Join on: Both tables required, Members and Donations, contain an ID# field, where ID# represents a
member’s unique identification number. This field is primary on the Members table. Thus, a direct
relationship (valid foreign key) can be established. Notice that the join field (ID#) is not listed on the
QBE grid. It will only need to be listed if the ID# field is displayed or contains a criterion.
The resulting query grid and dynaset are displayed in Figure 3.
Figure 3
The resulting dynaset consists of only five records, one for each donation of greater than $25. Also
notice that even though the join on field is ID#, this field is not required on the QBE grid. It is only
necessary to list this field if it is shown or contains a criterion.
Page 3
Query 2: Write a query that will list the first and last name, and position of each officer
who has served the club.
First plan this query:

What fields will be shown? Only the member’s name (Members table ) is required

What fields will have criteria that are not shown? No criteria is listed

What criteria are needed? None

What tables will we need? Since only a field from the Members table is shown, this table must be
displayed. Now the tricky part: How can the dynaset be limited to only the names of officers?
Officers is not a field that a criterion can be placed on, but a separate table. Since only records for
those who have served as an officer are desired, joining the Officer table to the Members table will
limit the selected records to those who are listed on both tables.

Join on: These tables can be joined by ID#.
The query grid and resulting dynaset are displayed in Figure 4.
Figure 4
What would happen if a member was listed several times on the Officers table (e.g., having served
several different years in different positions)? The dynaset would list this person multiple times.
Page 4
Query 3: Write a query to list active members only. Include their last name, and the
total donations made to date.
The query grid will require both the Members and Donations tables joined by ID#. The fields Last
Name from Members, Donation from Donations, and Active from Members are also needed on the
grid. To aggregate by member use the Total line and place a Group by in the Last Name field and then
Sum in the Donations field. Since only Active members are to be listed, include the Active field on the
grid but uncheck the show box. Also place the keyword where on the Total line, indicating a criteria
field during the aggregation process. Figure 5 details the required query grid and resulting dynaset.
Figure 5
Notice that inactive members do not appear on the list, even if they have made donations. What
would happen in this query if two members had the same exact last name? Their donations would be
combined. A better technique would be to list and summarize by the primary key field, member ID#,
so that each member is uniquely identified.
Page 5
DESIGNING QUERIES WITH MULTIPLE TABLES--A MANY-TO ONE-TO MANY RELATIONSHIP
Query 4: Write a query to list by member the totals dues paid and total donations made.
Can dues paid and donations be combined in one query? The tables Donations and Dues cannot be
directly joined as there is no valid foreign key relationship; ID# is not a primary key on either table.
Can the Donations table be joined to the Members table and then Members table joined to Dues
directly in one query, mimicking the relationship diagram? To answer this question we need to
understand how multiple joins are executed in a relational database. We also need to understand the
type of relationships between our tables.
In this particular case a many-to-one-to-many relationship exists between the three tables.
Each member may be associated with more than one donation transaction and more than one dues
payment transaction. A specific dues transaction does not correspond to any specific donations
transaction.
MS Access executes multiple joins sequentially. First two of
the objects (tables, queries etc.) are combined together into
a “joined record set” using the process described earlier in
this chapter. This “joined record set” object is then joined
with the third object creating another record set. If there
are additional joins, this process continues until all of the
joins have been executed and a final record set obtained. As
an example follow the join of the Dues, Members, and
Donations tables.
1. First join the Donations and Members Tables.
When joining the Donations and Members tables the
following master list is generated. This list is created by
combining each of the 4 records in the Members table with
each of 3 records in the Donations table. 12 combinations
exist, of which only some have common foreign key fields.
The results are illustrated in Figure 6.
By joining on the foreign key ID#, the combined record set
will have only those records with the same
values in the foreign key fields. There are six
records with common ID#s, as seen in Figure 7.
Figure 6 – Master List 1
Note that since there were no donations made
by members 002, 635, or 903 they do not
appear in the combined record set for an inner join.
Figure 7 – Combined Record Set
Page 6
2. Next this joined record set in Figure 6 is joined with the Dues table. The record set in Figure 6 has
6 records and the Dues table has 8 records, so the master list will have 48 records, only some of
which will have matching foreign keys field values. This master list is given in Figure 8.
Figure 7
Figure 8 – Master List 2
Page 7
3. Since the join was again performed on the foreign key field ID#, only those records where these
two values match will be included in the inner joined record set. Four separate records meet this
criterion. Thus the combined record set is as follows:
Figure 9 – Combined Record Set
4. Finally, Aggregate functions & expressions are applied which produce the dynaset shown in Figure
10.
There are two major problems that exist in this dynaset.
Problem 1: The final dynaset is not an accurate reflection of each member’s transactions.

Notice that even though member #047 made a donation, since he did not make a dues payment he
is not listed on the combined record set.

Similarly, member #635 has made a dues payment but no donation, and he too is not listed on the
combined record set.
As you recall, an inner join is the default join type when creating queries and an inner join will only
display matching records from both tables. We will address this issue in the next chapter.
Problem 2: Thus, the resulting dataset is not an accurate reflection of each member’s transactions.
Recall that Mr. Anderson made two separate donations, one for $100 and another for $25, totaling
$125. He also made 1 $100 payment towards his membership dues. Summarizing the dataset
resulting from this 3-way join, shows that Mr. Anderson had made a total of $125 in donations and
$200 in dues payments, which is incorrect.
Figure 10 – Final Dynaset
Page 8
Look at the relationships between Dues, Members, and Donations diagram in Figure 10 and consider
the foreign key relationships more closely. There is a one-to-many relationship between the Members
Table and both the Donations and Dues tables. So the three-way join can be described as a manyto-one-to-many relationship. In such cases a single record from one many side cannot be
matched to one single record from the other many side; in this case a specific donation does not
correspond to a specific dues payment. In a case of a many-to-one-to-many relationship a multiple
join does not result in a valid record set. While Access will let you physically combine these
three tables in a query, the resulting dataset will be not be valid.
Dues
Primary Key: none
∞
1
Members
Primary key: ID#
1
∞
Donations
Primary Key: none
Figure 11
Page 9
SOLVING THE PROBLEM-QUERY WITH A MANY-TO ONE-TO MANY RELATIONSHIP
Having already concluded that it is not possible to simply combine the three tables together in one
step, how can we create a query that correctly lists by member the totals dues paid and total donations
made?
The recommended technique is to create multiple queries, where each query summarizes the data
between two tables and then a final query is created to merge the resulting values. The technique is as
follows:
1. Write a query to create list each member’s total dues. The resulting dynaset will display one record
for each member who made a dues payment, and the total sum of these dues. The QBE grid and
resulting dynaset is shown in figure 12.
Figure 12 – Dues Paid (query name)
2. Write a query to create list each member’s total donations. The resulting dynaset will display one
record for each member who made a donation, and the total sum of these donations. The QBE
grid and resulting dynaset is shown in figure 13.
Figure 13 – Donations Made (query name)
3. Finally, write a query that combines both queries to create a list of each member’s total dues paid
and total donations made. The resulting dynaset will display one record for each member who
made a donation, and the total sum of these donations. The QBE grid and resulting dynaset is
shown in figure 14. (Note: This dynaset still does not include all the records in the corresponding
tables. We will discuss how to remedy this in the next chapter.)
Figure 14 – Final Query
Page 10
DESIGNING QUERIES WITH MULTIPLE TABLES-A ONE-MANY-ONE RELATIONSHIP
We have established that three tables cannot be directly joined if they contain a many-one-many
relationship. Now we will explore the case of multiple joins for a one to many to one relationship.
Query 5: Write a query to list by member each donation and the event in which the
donation was made.
The relationships between these three tables are described in Figure 15.
Events
Primary Key: EventType
1
∞
Donations
Figure
Primary
Key:10none
∞
1
Members
Primary key: ID#
Figure 15
In this particular case a one-to-many-to-one relationship exists between the three tables. Each
member may be associated with more than one Donations record, but each Donations record can only
be associated with one Events record. For example, Martin Aston made one unsolicited donation of
$100 the first donation ($100) listed contains the value 345 in the ID# field and the value M4 in the
eventType field. The ID#345 corresponds to a single member (Martin Aston) and the eventType M4
corresponds to a single event (Unsolicited). So, joining these tables makes sense. But can these
objects be correctly joined in a query? Let’s apply the join process to the data and take a look at the
resulting record.
Page 11
First combine the Members table with
the Donations table, creating the
master list (Figure 16) and then the
joined record set (Figure 17). The
master list generated from a join of 7
records and 6 records contains the 42
possible combinations, as seen in
Figure 11. Using an inner join on the
type foreign key, results in a dynaset
that will contain 6 records with
matching values in the foreign key field
as shown in Figure 17.
Figure 10
Figure 16
Figure 17
Page 12
In the next step, the resulting
record set in Figure 13 will be
joined with the Types table.
Unlike the previous example,
these records will be joined on
a
second
foreign
key:
EventType. The master list
will contain 6*4 records for a
total of twenty four records
(Figure 18). Of these, six
contain matching member
ID# and matching types
(Figure 19).
Figure 18
Figure 19
The final record set created in Access matches each dues payment to its appropriate member and
payment type. Thus a valid record set is obtained when performing multiple inner joins
on objects with a one-to-many-one relationship. Using a similar technique it can also be
shown that joins on objects with relationships such as one to one to many or a many to one to
one will also result in valid record sets. Indeed, we can even create three or more joins in a similar
manner, as long as there are no many-to-one–to-many relationships.
Page 13