RELATIONSHIPS AND THE

RELATIONSHIPS TOOL
• The Relationships Tool is used to define relationships between
tables based on common fields.
• Consider the University database we have been using that
contains a Department table and a Course table. These two
tables have the deptCode field in common:
– In the Department table, deptCode is the primary key and
is used to identify a specific department.
– In the Course table, the deptCode field is a part of the
primary key and indicates the department to which the
course belongs.
 RELATIONSHIPS AND THE
RELATIONSHIPS TOOL
• To ensure that a row in Course is related to an existing row in
Department we can use the Relationships Tool to define a
relationship between these two tables based on this common
field.

• In this situation we say that deptCode in Course is a foreign

key referencing the deptCode field in Department.
 Relationships and the relationships tool
• Consider the Library database:
– The Loan table has a callNo field and so does the Book
table; the callNo field identifies a specific book.
– The Loan table has an id field and so does the Member
table; the id field identifies an individual member.
• So we can establish a relationship between Loan and Book
based on the callNo field, and a second relationship between
Loan and Member based on the id field.
• The Loan table has two foreign keys, callNo and id: The callNo
field in Loan references the primary key (callNo) in Book. The
id field in Loan references the primary key (id) in Member
 Relationships: Integrity
• Primary Key: Recall that a table’s PK is a field (possibly
composite) that has unique values – each row has a PK value
different from any other row in the table. Such a field is a
unique identifier – if a query were designed to retrieve a row
of that table based on a value of the PK, then at most one row
of the table will be retrieved.
• Foreign Key: A foreign key is a field (or combination of fields)
in a table B that is associated with a PK in a table A through a
relationship (A and B can be the same table).
• Entity Integrity : When we define a PK for a table we are
enforcing entity integrity. Entity integrity means that each row
in the table is identifiable through its primary key. MS Access
requires a value for a PK in a newly added row, and MS Access
enforces uniqueness of those values.
 Relationships: Integrity
• Referential Integrity: Suppose we have two tables, A and B,
where a relationship is defined between the primary key of
table A and a foreign key in table B. We say RI exists for this
relationship if for each row in B either:
– the FK has no value at all (i.e. it is null), or
– the FK has a value that exists as a PK value in some row of
A.
 Relationships
• Two tables can be related through one-to-one, one-to-many,
or many-to-many relationships. If you open the Relationships
Tool for the University database you will see the following
diagram showing two tables and one relationship:

• There are two labels on the line which inform us the

relationship is one-to-many for which there are two rules that
are in place:
– for each department there will be zero or more courses for
that department, and,
– each course is for exactly one department.
 Relationships
To create a relationship in MS Access you must:
• open the Relationships Tool
• add the pertinent tables to the diagram if they are
not there already
• click, hold, and drag a field (normally this is the PK) of
one table to the related field (to become a FK) in the
other table.
• You will be asked whether or not Referential Integrity
is to be enforced. As a general rule-ofthumb, you
should select Yes – there must be some exceptional
circumstance that makes you select No.
 Relationships
One-to-many:
• If you drag the PK field of one table to the other
table, and if the FK does not have unique values, then
you are creating a one-to-many relationship.
• For each row in the referenced table there can be
several related rows in the other table; that is, for a
PK value there can be many rows in the other table
with that value stored in the FK.
 Relationships
One-to-many: Example in the University
Database
• Department and Course are related
through the deptCode field.
• delete the existing relationships line
(click the line, press delete, and follow
through with the dialog to delete the
relationship).
• Now, click and drag the deptCode field
in Department and drop it on top of
the deptCode field in Course. On
releasing the mouse MS Access will
present the following dialogue box:
 Relationships
One-to-many: Example in the University Database
• At this point MS Access is requesting the user to confirm the
proper fields are being related, and for the user to make a
choice regarding Referential Integrity and on some ‘Cascade’
options You should choose Enforce Referential Integrity in
almost all cases as this helps reduce the chance of corrupting
data.
• click Create, MS Access shows the relationships line with 1 on
the one side and an infinity symbol on the many side of the
relationship
 Relationships
One-to-one:
• If you drag a PK field of one table to another table,
and if the FK has unique values (a unique index exists
for it) then you are creating a one-to-one
relationship.
• For each row in the first table there can be at most
one related row in the other table; a row in the
referenced table has a PK value that equals the FK
value in at most one row of the referencing table.
 Relationships
Many-to-many:
• If you create a relationship in MS access where both
fields you associated (via the click, hold, and drag
sequence) do not have unique values (i.e. neither
have unique indexes) then MS Access creates an
‘indeterminant’ relationship.
• In this situation a row in one table, A, may be related
to multiple rows in the other table, B, and where a
row in table B may be related to multiple rows in the
table A.
• This is not done very often and corresponds to a
many-to-many relationship.
 Relationships
Many-to-many:
• Most database designers would avoid this in
their database designs. If a database designer
is faced with two tables, A and B, that are
related via a many-to-many relationship, the
designer would likely introduce a third table,
say C, where A and C will be related via a one-
to-many relationship and similarly, B and C will
be related via a one-to-many relationship.
 Activities
• For these activities use the Company database which does not
have any relationships defined. The first few rows of Employee
and Department are:
 Activities
1. Consider the Employee and Department tables. Note the
Employee table has a field dept which indicates the
department where the employee works. The relationship can
be stated:
– Each department has zero or more employees, and,
– Each employee works in at most one department.
Create a one-to-many “works in” relationship between
Employee and Department.
 Activities
2. The Department table has a field manager which indicates the
employee who is the head of the department. The relationship is
stated:
– each department has one employee who manages that
department, and
– an employee may manage at most one department.
There is a unique index defined for the manager field and so you can
create a one-to-one relationship “has manager” between Department
and Employee. If you do this exercise after activity1 has been
completed, then you need to read the dialog boxes carefully when you
create this second relationship between these tables. You must respond
No to the following dialogue window.
 Activities
3. Consider the empId and the supervisor fields of Employee.
Most employees report to someone – someone who is their
supervisor. Only employee 1 does not report to anyone else.
The supervises relationship can be stated:
– an employee may supervise many other employees, and,
– an employee reports to at most one other employee.
a) Create the supervises relationship.
If you are doing this exercise after activity 2 then your
relationship diagram has 2 copies of the Employee table. If you
are not doing this after activity 2, then you must add Employee to
the diagram twice so there are 2 copies of Employee on the
diagram. Drag the PK, empId, from one copy of Employee to the
supervisor field of the other copy. Note how MS Access draws
this diagram.
 Activities
3. b) The supervisor field is an implementation of a hierarchical
reporting structure for our company. Use a piece of paper and
draw the reporting structure for the company (for the data given
at the start of these activities). We have started this exercise
showing the reporting structure for the first 4 employees:
 Activities
The following activities depend on the relationships diagram from
the above activities. When developing a query you will see that
MS Access will include relationships when you include tables in
the relationships area of a query. Do consider them closely to
ensure they are the relationships and joins you need.

4. Create a query to list for each department, the name of the

department and the name of its manager.

5. Create a query to list for each department, the name of the

department and the names of its employees (the people who
work in the department). Sequence your results by department
name.
 Activities
6. Create a query to list for each department, the name of the
department head and the names of the department’s employees.
Your query must list on each row of the result set the department
name, the head’s last name, and the last name of each employee.
Sequence your results by department name, and within
department by employee last name.

7. Create a query that lists each supervisor and the employees

he/she is supervising. Your query must list, on each row of the
result set, the last name of the supervisor and the last name of
the supervised employee. Sequence the results by supervisor and
within supervisor by employee.