Download REVISING JOE`S DATABASE

Access 2002
Chapter 6
Getting Started
`DEFINING TABLE RELATIONSHIPS
REVIEW OF CONCEPTS AND WORK DONE PREVIOUSLY
Throughout our efforts in developing Joes’s Fruit Stand database, we have had much emphasis
on table relationships. As you remember, Joe had developed a database using just a single table.
In this table he tried to do everything and soon ran into problems. You have divided this table,
first into two parts and finally into three tables. You found that three tables were needed because
the database involved many to many relationships. You saw that only two tables were necessary
to represent the major topics of the database—Vendors and Fruit. However, since vendors could
supply many types of fruit, and fruit could be supplied by many vendors, a third table was
needed to connect the other two. This type of table is called a junction table.
Junction tables have special properties. The primary key for a junction table consists of foreign
keys to each of the parent. FruitID is a foreign key to the Fruit table and VendorID to the Vendor
table. These two fields combine together to form the primary key of the Fruit-Vendor table.
The major reason for changing Joe’s database from a one table database to a two table database
and finally to three tables was to improve the integrity of the data. If data has integrity, it can be
trusted to be correct or at least consistent.
Joe’s original design failed because of redundant data. Redundant data works against data
integrity because the same values are stored multiple times. Redundancy means that extra
physical storage is required, and that effort is required to enter and maintain the data. More
important, however, is the fact that the data may easily become unreliable. Keying errors may
cause differing values to be entered in different records. When a data value changes the data
entry process might miss some copy of the data. By storing data values in only one database
Arthur R. Buss
Access 2002
AC GS 6.1
<Au 1st draft>
5/13/2017
Access 2002
Chapter 6
Getting Started
location, all of these problems can be eliminated. On the other hand, if the wrong value is entered
in that one location all of the results are wrong.
Even though the use of multiple tables can reduce data redundancy, it introduces a new potential
problem—the lack of referential integrity. Referential integrity means that the tables are
correctly linked to each other.
We have seen that relationships rely on foreign keys to maintain links between the tables.
Another way of saying this is that the foreign key refers to a specific record in another table. A
database can be said to have referential integrity when we can be assured that each foreign key
field refers to a record that actually exists in the database.
Let’s see how this could be a problem. Suppose Joe has been getting his kumquats from a vendor
called the Fruit Depot. Due to some dispute with the vendor, Joe decides no longer to deal with
the Fruit Depot and deletes this Vendor record from the database.
Later on Joe needs to order some more kumquats. Without referential integrity safeguards in
place, Joe will find that the Fruit Depot is still listed as a vendor for kumquats. However, if Joe
attempted to place an order the database would not be able to create the order since the Fruit
Depot record has been deleted. You may have had a similar experience if you ever went to a
library and looked up a book in the catalog, but when you went to the indicated location, the
book wasn’t there. References that don’t point to anything are not of much use. Fortunately,
Access provides ways to assure referential integrity.
UNDERSTANDING THE USE OF JOINS IN THE CREATION OF QUERIES
In this session you will be developing queries that involve the use of joins. One of the strengths
of a relational database is its flexibility in creating queries. While relationships are very
important in the design of a database, it is possible to combine data from multiple tables even if
Arthur R. Buss
Access 2002
AC GS 6.2
<Au 1st draft>
5/13/2017
Access 2002
Chapter 6
Getting Started
relationships have not been established. This process is called a join. Joins can combine any two
tables as long as they have a common field. The common field does not have to be a foreign key
but can be any field that exists in both tables. In fact, tables can be combined even if there is no
common field. A third table can serve as a link if it has a field that is common the first table and
another field common to the second.
What is the difference between a relationship and a join? Relationships represent the structure of
the database. They are the way data will be processed most of the time. A join is the process of
combining tables to produce a new result. Multi-table queries in Access involve some type of
join whether we specify it or not.
Another difference between joins and queries is the use of indexes. An index is much like the
library catalog mentioned above. Indexes are special files maintained by the DBMS to allow it to
quickly find particular records without having to search through an entire table. When a
relationship is defined Access creates an index. Joins do not have indexes per se, but a join may
take advantage of indexes that already exist.
The basic join is called an inner join. An inner join requires that a field in one table equals a
field in a second table. Inner joins are not the only way to specify the query, but when it is
presented in the QBE (or design) grid, Access generally uses the inner join process.
In addition to the inner join, Access may also do outer joins. Outer joins allow the user to see not
only the records that are matched but those that are unmatched.
The value of an outer join may not be immediately obvious, but you may be able to see that if
you want to find any orphan records. That is, any records from one table that does not have a
match in a related table. Orphan records can be a sign of data integrity problems. For example,
Arthur R. Buss
Access 2002
AC GS 6.3
<Au 1st draft>
5/13/2017
Access 2002
Chapter 6
Getting Started
some records may have been deleted, links between records not established, or duplicate records
with spelling differences in key fields were entered.
EXERCISE
Joe’s New Requirements
Joe has realized that his database not only can be a way of keeping track of the fruit that he has
on hand, but also can assist him in making decisions as to placing new orders. In other words,
Joe doesn’t just need to know about the current inventory of fruit, he also wants to know when to
place new orders and with whom to place them.
In order for Joe to know when to reorder he needs to have some sort of trigger to tell him when
he is getting low on inventory. Joe normally reorders on Mondays, after the heavy sales of the
weekend. His suppliers generally take three days from when the order is placed to deliver the
fruit. Three day delivery means that shipments should arrive on Thursday, just in time for the
next weekend.
Joe over the years has developed a good sense of the minimum amount he needs to have on hand
for each type of fruit. When the amount on hand falls below this reorder point, he needs to order
more fruit. Joe wants to incorporate this information into the database so that one of his
employees can do the reordering and Joe can have an occasional Monday off and maybe even go
on a vacation.
The second part of the problem is for Joe, or his assistant, to determine which vendor to order
from. In the real world, there are many factors that might go into this decision such as quality of
fruit, time of delivery, and payment terms. At this point, we will look at only one—vendor price.
The vendor price for the fruit is different from the cost of fruit in the Fruit-Vendor table. The
data in the Fruit-Vendor table represents the fruit that is on hand and does not necessarily
Arthur R. Buss
Access 2002
AC GS 6.4
<Au 1st draft>
5/13/2017
Access 2002
Chapter 6
Getting Started
represent what vendors are currently charging for the fruit. Joe needs to know which vendor will
give the best price this week.
Things to Think About
Here we are going to let you think about how you might respond to these needs and the changes
you might make to the database to solve Joe’s ordering needs. Think about the following
questions?
1. Can the database meet these needs without modifying the current tables? In other words,
can queries supply the necessary information from the data already in the database?
2. If the current data is not sufficient for the needs, what additional fields need to be added?
3. Can any additional data fields be added to the existing tables? If so, where?
4. If not, is an entirely new table(s) necessary? What is the primary key of any new table?
5. What relationships exist between any new table and the existing tables?
These questions are important to the success of the database and it will take some serious
thinking to determine the answer. We will have you work through a possible solution in the
What We Have Learned Session.
Arthur R. Buss
Access 2002
AC GS 6.5
<Au 1st draft>
5/13/2017