SKILLS MODULE 2

I M P L E M E N T I N G A D ATA B A S E
WITH MICROSOFT ACCESS

Student Learning Outcomes

1. Apply the four steps of database design through an example.

2. Use the Microsoft Access data manipulation system.

3. Learn how to create queries on a database.

4. Learn how to generate a report.

2 Skills Module 2

Introduction
In Chapter 3, we discussed the important role that databases play in an organization.
We followed that with Extended Learning Module A, in which you learned how to
design the correct structure of a relational database. That Module included four pri-
mary steps. They include:
1. Defining entity classes and primary keys
2. Defining relationships among entity classes
3. Defining information (fields) for each relation (the term relation is often used to
refer to a file while designing a database)
4. Using a data definition language to create your database
In Extended Learning Module A, you followed the process through the first three
steps above. In this Module, we’ll take you through the fourth step—using a data def-
inition language to create your database—by exploring the use of Microsoft Access,
today’s most popular personal database management system package (it comes as a
standard part of Microsoft Office XP).
We’ll also show you how to use some of Microsoft’s Access’ data manipulation
subsystem, including views, queries, and report generators.
In Figure M2.1, we’ve recreated the correct database structure we defined in
Extended Learning Module A. If it’s been awhile since you covered that Module, we
suggest you review it for the application of creating a database to track employees, to
which departments they are assigned, and which jobs they each perform.

Figure M2.1
The Database Structure We’ll Be Implementing

Coaxial Cable
or
Phone Line
Cable Modem
or Air
DSL Modem

T1
1.5Mbps

ISP Wireless
Regional Access Point
or Other Connections
National Home Router are via Ethernet
The Internet (Firewall)
Hub or
Switch

Printer Cable
 Implementing the Structure of Your Employee Database 3

Note that this is a “bonus” Module. So you won’t find the standard On Your Own
and Team Work projects integrated into the text here, nor will you find the standard
end-of-Module support consisting of Summary, Short-Answer Questions, or Assign-
ments and Exercises. We have simply provided this Module to add value to the text.

Implementing the Structure of

Your Employee Database
As we’ve discussed with respect to databases, you can’t simply start typing in infor-
mation to create a database as you can when you create a document with word pro-
cessing software or a workbook with spreadsheet software. You must first define the
correct structure of the database (Extended Learning Module A), and then you must
create the structure of the database by creating its data dictionary before entering any
information. The data dictionary contains the logical structure for the information. It
includes a description of each relation (also called a table or file) and each piece of
information in each relation.
To create a database using Microsoft Access, perform the following steps (see Fig-
ure M2.2):
1. Start Microsoft Access.
2. Select Blank Database on the right side of the screen or select File and New from
the menu and then Blank Database on the right side of the screen.
3. Select a folder for the database and enter a filename (we’ll use Employee.mdb).
4. Click on Create.
Once you’ve performed the above steps, you’ll see the left screen in Figure M2.3.
You’ve now created a blank database with the name Employee.mdb. You are now
ready to define the structure and information within each relation.
Let’s take a look at the left screen in Figure M2.3. Notice first that you can create
relations (what Microsoft Access calls “tables”) in one of three ways—in Design view,
by using a wizard, and by simply entering information. They all achieve the same
result. In this Module, we’ll create the relations using the Design view.
Notice also the tabs down the left side. They include Tables, Queries, Forms,
Reports, Pages, Macros, and Modules. To work each specifically, you must first click
its respective tab. The default is Tables, and that’s where we’ll begin. We’ll also cover
Queries and Reports, leaving Forms, Pages, Macros, and Modules up to you to
explore at a later time.
To create a relation (table) using the Design view, make sure the Tables tab is
selected and then double-click Create Table in Design View. You will then see the
screen on the right side of Figure M2.3. In that screen, you can see that Microsoft
Access expects you to enter a name, data type, and description (the last is optional)
for each field in a given relation. Once you’ve entered all that information (plus
some more) for a given relation, you save that structure and repeat the process until
you’ve created the structure for each relation in your database. We’ll do that for
Employee.mdb.
4 Skills Module 2

Figure M2.2
Creating a Blank Database

Create a blank database by

clicking on Blank Database.

Select a location and provide a database name.

 Implementing the Structure of Your Employee Database 5

Figure M2.3
The Start of Defining the Structure for Each Relation

To define the structure of

a relation, first select the
Tables tab and then double-
click on Create table in
Design view.

Enter field names and data types here.

IMPLEMENTING THE EMPLOYEE RELATION STRUCTURE

To start, let’s implement for the structure for the Employee relation within
Employee.mbd. You might first notice that you’re going to have a relation with the
same name as the overall database. That’s okay if it suits your purpose.
In Figure M2.4, you can see that we have simply entered the three fields for the
Employee relation—Employee ID, Name, and Department Num. For Employee ID, we
chose the data type as Number; for Name, we chose the data type as Text; and for
Department Num, we chose the data type as Number. You must choose a data type for
each field you enter. Once you enter a field name and press the tab key to move to the
data type column, you’ll find a pull down list of available data types. All you have to do
is select the appropriate one.
6 Skills Module 2

Figure M2.4
Implementing the Employee Relation Structure

You should also carefully note the Field Properties section across the bottom of the
screen in Figure M2.4. We currently have the cursor in the row for Employee ID, so the
Field Properties section displays the appropriate property information for that field.
Notice that the Field Size is Integer, Decimal Places is 0, Required is Yes, and Indexed
is Yes (No Duplicates). We specifically entered those properties for Employee ID. And
they all make sense. For example, Indexed must be Yes (No Duplicates) because
Employee ID is the primary key for this relation. By setting this property to Yes (No
Duplicates), Access will not allow you (or anyone else) to enter employees with dupli-
cate ID numbers. That’s an illustration of the enforcement of integrity constraints.
Finally, notice that we further identified Employee ID as the primary key by placing
a key symbol next to its field name. To do this, simply position the cursor in the line of
the primary key field and click on the key symbol in the button bar. You’ll perform this
process for each primary key in each relation you create.
Once you’ve created the structure the way you want it, you need to save it. To do
so, click on the disk icon (Save As), enter Employee as the table name, and click on
OK. You can then close the Table: Employee box.

IMPLEMENTING THE JOB RELATION STRUCTURE

To implement the structures for the remaining relations, you simply follow the process
given earlier. Let’s now implement the structure for the Job relation. To create the Job
relation using the Design view, make sure the Tables tab is selected and then double-
click on Create Table in Design View.
 Implementing the Structure of Your Employee Database 7

In Figure M2.5, you can see that we entered the field names of Job Number and Job
Name. We also specified that Job Number is the primary key by placing the key icon
beside its name in the field name list.
Let’s take a look at the Field Properties for Job Name (we placed the cursor in the
Job Name row to view the Field Properties). Since this is a text field, you have some
new Field Properties to consider. One of them is Allow Zero Length. If you leave this
at Yes, you’re essentially saying that anyone can enter a new job but not specify a name
(i.e., blank). What you have to decide in every database environment is whether or not
text fields can be blank. Of course, if they’re key fields, you don’t want to leave them
blank. If they’re not key fields, you need to think about the necessity of having some-
thing entered.
For example, you might choose to allow a person’s middle initial to be blank—after
all, some people don’t have a middle name. But, if you were creating a customer data-
base to support a customer relationship management system, you would probably not
want the Customer Address field to be blank. Again, it all depends on the application
your database will support.
To save this structure, we followed the same process as before. That is, we clicked
on the disk icon (Save As), entered Job as the table name, clicked on OK, and then
closed the box.

Figure M2.5
Implementing the Job Relation Structure
8 Skills Module 2

IMPLEMENTING THE DEPARTMENT

RELATION STRUCTURE
Let’s now implement the structure for the Department relation. To create the Depart-
ment relation using the Design view, make sure the Tables tab is selected and then
double-click on Create Table in Design View.
In Figure M2.6, you can see that we entered the field names of Department Num
and Department Name. We also specified that Department Name is the primary key by
placing the key icon beside its name in the field name list.
Let’s take a look at the Field Properties for Department Name (we placed the cur-
sor in the Department Name row to view the Field Properties). Since this is a text
field, the default size (Field Size) is 50 characters, which we changed to 35. The field
size for a text field can range from 0 to 255. Again, depending on the application your
database will support, you need to consider the size of text fields. In our case, the
known department names are Non-profit, Residential, and Commercial. Each of these
has a length much less than 35.
You should be careful here not to make text field sizes too small. If we ever wanted
to add a new department with the title “Government—Housing and Urban Develop-
ment (HUD),” 35 characters would not be sufficient. On the other hand, you don’t
want to set every text field to the maximum size limit (255)—that would be a waste of
space. Allow plenty of room when setting the size of text fields.

Figure M2.6
Implementing the Department Relation Structure
 Implementing the Structure of Your Employee Database 9

To save this structure, we followed the same process as before. That is, we clicked
on the disk icon (Save As), entered Department as the table name, clicked on OK, and
closed the dialog box.

IMPLEMENTING THE JOB ASSIGNMENT

RELATION STRUCTURE
Finally, we need to implement the structure for the Job Assignment relation. As you
can see in Figure M2.7, we’ve entered all the field names (Employee ID, Job Number,
and Hours) and their types (all are Number).
This particular relation is different from the rest because it has a composite pri-
mary key, one that consists of the primary key fields from the two intersecting rela-
tions. If you recall from Extended Learning Module A, we created the Job Assignment
relation to eliminate the many-to-many relationship that existed between the Employee
and the Job relation. The Job Assignment relation has a primary key composed to two
fields—the primary key Employee ID that originated in the Employee relation and the
primary key Job Number that originated in the Job relation. So the Job Assignment pri-
mary key is a composite primary key.
To identify two fields aggregately that create a primary key, follow these steps:
1. Define the basic structure of the relation by entering the field names and their
properties.

Figure M2.7
Implementing the Job Assignment Relation Structure
10 Skills Module 2

2. Move the pointer to the column immediately to the left of the first field of the
composite primary key (the pointer will turn to an arrow pointing to the right).
3. Click on that row and don’t unclick.
4. Drag the pointer so that the second field in the composite primary key is also
highlighted.
5. Unclick.
6. Click on the key icon.
Then the key icon will appear next to both fields signifying that the two combined
make up a composite primary key.
To save this structure, we followed the same process as before. That is, we clicked
on the disk icon (Save As), entered Job Assignment as the table name, clicked on OK,
and closed the dialog box.

Defining Relationships Within

Your Employee Database
Believe it or not, up to this point all we’ve done is define the structure for each relation
in our database. As you can see, it’s quite different from creating a word processing
document or a workbook spreadsheet. And we still can’t yet enter information into
our database. We have one final structural task to take care of—that of defining how all
the relations relate to each other.
If you recall from our discussions in Chapter 3 and Extended Learning Module A,
you create relationships among the various relations by identifying foreign keys. A
foreign key is a primary key of one file (relation) that appears in another file (rela-
tion). For our Employee database, we have the following primary keys appearing as
foreign keys:

Appears in Appears in
Primary Key Relation: Foreign Key Relation:
Employee ID Employee Employee ID Job Assignment
Department Num Department Department Num Employee
Job Number Job Job Number Job Assignment

It’s vitally important that you tell your DBMS of the existence of foreign keys. That
way, the DBMS can enforce integrity constraints. For example, when we specify that
Employee ID is a foreign key (from the Employee relation) in the Job Assignment rela-
tion, the DBMS will not allow us to enter an Employee ID in the Job Assignment rela-
tion that does not appear as a primary key in the Employee relation. This makes
business sense—you can’t have a job assignment for an employee that doesn’t exist.
To create these relationships, you click on the Relationships button in the button
bar. You’ll then see the screen shown in Figure M2.8. Notice that it lists all the rela-
tions in our database. When you first start this process, the palette in the background
is blank. To identify the relationships, you must make each relation appear on the
palette. To do this, simply highlight each relation name and click on Add, which is
what we did. We then clicked on the Close button to make the Show Table dialog box
disappear. Now we’re ready to identify how all the relations relate to each other.
To do this (and you must follow this process exactly), you click on and drag each
primary key and drop it onto its respective foreign key counterpart. Once you drop the
primary key onto its respective foreign key counterpart, you’ll see the Edit Relation-
 Defining Relationships Within Your Employee Database 11

Figure M2.8
The Start of Defining Relationships in a Database

ships dialog box. In that box, you need to click on Enforce Referential Integrity and
then Create.
When you drag and drop a primary key onto a foreign key, Microsoft Access
assumes that the relationship is one-to-many (1:M). That is, a primary key may appear
many times as a foreign key, and a foreign key must appear once and only once as a pri-
mary key. If you perform the process in reverse (dragging and dropping the foreign
key onto a primary key), the relationship will be reversed (M:1), which is not at all
what you want.
You also need to turn on the enforcement of referential integrity. By doing so, your
DBMS will enforce the fact that when you enter a foreign key in a relation it must
match one of the primary keys in the other relation. Figure M2.9 shows the Edit Rela-
tionships dialog box when we dragged and dropped Job Number from the Job relation
onto Job Number in the Job Assignment relation. It also shows that we clicked on
Enforce Referential Integrity.
In Figure M2.9, you can see that we have already created the relationships between
Department and Employee and Employee and Job Assignment. In the first instance,
Access shows a connecting line between the Department and Employee relations with
a 1 near the Department relation and an infinity symbol near the Employee relation. So
a Department Num in the Department relation can appear any number of times (infin-
ity) in the Employee relation. Likewise, a Department Num that appears in the
Employee relation can only appear once in the Department relation.
When you have completed this process, click on the disk icon to save the relation-
ships and then close the Relationships box.
12 Skills Module 2

Figure M2.9
Defining Relationships for the Employee Database

Entering Information into Your

Employee Database
Finally, we’re ready to begin entering information. We’ve defined the structure for
each relation in the Employee database and we’ve defined the relationships among the
various relations.
To enter information, you simply highlight the desired relation and click on Open
(see Figure M2.10). We’ll start by entering information in the Department relation.
Does it matter in which relation you start entering information? It certainly does. We
cannot start by entering information in either the Employee or the Job Assignment
relation. Why not? Because we chose to enforce referential integrity when we created
the various relationships. So we can’t enter information into the Employee relation
before entering information into the Department relation because we must enter a
Department Num in the Employee relation. If a Department Num that we enter in the
Employee relation doesn’t exist in the Department relation, Access will display an
error message and not allow us to continue.
So, we must first enter information into the Department relation before entering
information into the Employee relation. Likewise, we must also enter information into
the Employee and Job relations before entering information into the Job Assignment
relation. Clearly, this is very different from spreadsheet software.
In the Figure M2.10, we have entered the information in the Department relation.
After typing the appropriate information into each field, we used the Tab key to get to
 Entering Information into Your Employee Database 13

Figure M2.10
Entering Information in the Department Relation
14 Skills Module 2

Figure M2.10
Entering Information in the Department Relation (continued)

the next field or row. Once you enter all the information, click on the disk icon to save
the information and close the table (relation) box. You can then move on to entering
information in the relations.
Entering information in the Job and Employee relations is very similar to what we
just did for the Department relation. So we’ll skip showing you that and move on to
entering information in the Job Assignment relation (the composite relation).
In the first screen of Figure M2.11 you can see that we’ve entered all the informa-
tion correctly in the Job Assignment relation except for the last record. For that record,
we entered 8798 as the Employee ID, which is correct, and 8 as the Hours, which is
also correct. However, for the Job Number, we entered 22, which is not a valid Job
Number because it does not exist as a primary key in the Job relation.
An alert box appears informing us of the problem. When we click OK in that box,
there appears the alert box shown in the next screen of Figure M2.11. It simply says
that Access cannot save the record that has the error. If we choose to close the relation,
Access will save the information without that particular record. If we choose not to
close the relation, Access will give us the opportunity to correct the information.
As you can see, Access does enforce the integrity constraints (i.e., what it calls “ref-
erential integrity”). We simply cannot enter a Job Number in the Job Assignment rela-
tion that does not exist in the Job relation. This will hold true for entering any foreign
key in our database. For purposes of our presentation in this Module, we return to the
relation and enter the correct information.
We’ve finally implemented the structure of our database and entered the necessary
information. It’s now time to move on to building queries and reports. Incidentally, if you
want to view any of the database information, make changes to the information, and pos-
sibly add new records, simply highlight the appropriate relation name and click on Open.
 Entering Information into Your Employee Database 15

Figure M2.11
Encountering an Integrity Error While Entering Information
16 Skills Module 2

Creating a Simple Query Using

One Relation
The easiest way to create a query is to use a query-by-example tool. A query-by-
example (QBE) tool helps you graphically design the answer to a question. Suppose,
for example, that we wanted to see a list of all employees by Employee ID and by
Name. All of that information is located in the Employee relation, so this is a relatively
simple query requiring the use of only a single relation. Realize, of course, that our
database is small and the query doesn’t make much sense given you could easily open
the Employee relation and see the desired information. But this is good way to intro-
duce you to using a QBE tool. On the next several pages, we’ll create more compli-
cated queries.
To create a simple query using one relation, perform the following steps (see Figure
M2.12):
1. Select the Queries tab.
2. Double-click on Create Query in Design View. (You can also create a query
using a wizard—we’ll let you explore how to do that on your own.)
3. In the Show Table dialog box, select the appropriate relation name, click on
Add, and then close the Show Table dialog box.
4. Drag and drop the fields into the QBE grid that you want in the query result.
5. Click on the exclamation point icon (Run) in the button bar.
As you can see in Figure M2.12, we followed that process by selecting the Employee
relation, and dragging and dropping Employee ID and Name into the QBE grid. Once
we clicked on the exclamation point icon, Access returned a list of employees by ID
and name. Again, this is a very simple example.
At this point we could save the query using a unique name such as “Employees by
Name and ID.” Then, if we ever wanted to run the query again, we wouldn’t have to
back through the steps above. We would, instead, see the unique name within the
Queries tab and simply double-click on it to run it.
 Creating a Simple Query Using One Relation 17

Figure M2.12
Creating a Simple Query Using One Relation
18 Skills Module 2

Figure M2.12
Creating a Simple Query Using One Relation (continued)
 Creating a Simple Query Using One Relation 19

Figure M2.12
Creating a Simple Query Using One Relation (continued)

As you can see, creating a simple query using one relation is in fact simple. So, let’s
make it a bit more difficult. Let’s assume that we wanted to see all employees by ID
and name who are in the Residential department (Department Num is 43). We often
refer to this as a conditional query because it only returns results based on some con-
dition. This requires a couple of more steps than the previous query but is still very
easy to perform.
In Figure M2.13, you can see that again only selected the Employee relation since it
contains all the information we need. However, this time we also dragged and dropped
Department Num into the QBE grid. Within the QBE grid, we provided two impor-
tant pieces of query information under Department Num.
The first was to unselect the Show parameter. In doing so, we’re telling Access that
we want to use Department Num as a part of the query but that we don’t want it to
show in the query result. The second was to enter =43 in the Criteria parameter. In
doing so, we’re telling Access that we want to see only IDs and names of employees
whose Department Nums are equal to 43 (Residential). As you can see in the second
screen of Figure M2.13, Access provided information for only three employees, all of
whom work in the Residential department.
Again, if we wanted to we could have saved this query using a unique name such as
“Residential Department Employees.” It would then appear in our list within the
Queries tab. If this were a real database for a very large organization, we would rec-
ommend that you create this sort of query for each department.
20 Skills Module 2

Figure M2.13
A Conditional Query Using One Relation
 Creating an Advanced Query Using More Than One Relation 21

Creating an Advanced Query

Using More Than One Relation
Let’s move on to an even more complicated query—one that requires the use of two
relations. Suppose we wanted a list of all employees by ID, name, and the department
in which they work. However, instead of Department Num as the identifier for the
department, we would like to see Department Name. That query will require the use
of two relations because Employee ID and Name are in the Employee relation and
Department Name is in the Department relation.
To perform this query, we added both the Employee and Department relations from
the Show Table dialog box (see Figure M2.14). Next, we dragged and dropped
Employee ID and Name from the Employee relation into the QBE grid. Then we dragged
and dropped Department Name from the Department relation into the QBE grid. And,
to tell you the truth, that’s all you have to do. As you can see in the final screen of Figure
M2.14, Access provided a list of all employees by name, ID, and name of department.
Why did this work so easily? Because of the relationships we identified among the
various relations, in this case the Employee and Department relations. When executing
this query, Access took the Department Num of each employee, searched the Depart-
ment relation until it found a match, and then used the Department Name in the
matching record. As you can see, relationships via foreign keys are an integral part of
a database environment.

Figure M2.14
Creating an Advanced Query Using More Than One Relation
22 Skills Module 2

Figure M2.14
Creating an Advanced Query Using More Than One Relation (continued)
 Creating an Advanced Query Using More Than One Relation 23

As a final query example, let’s consider that we would like to see all the IDs and
names of employees who work in the Residential Department (Department Num is
43) who work more than four hours in Sales (Job Number is 23) and how many hours
they work in Sales.
To perform this query, we still need only two relations, this time Employee and Job
Assignment. As you can see in Figure M2.15, we added those from the Show Table
dialog box. We then had to drag and drop five pieces of information into the QBE grid
including:
1. Employee ID from Employee
2. Name from Employee
3. Department Num from Employee
4. Job Number from Job Assignment
5. Hours from Job Assignment
Now, let’s take some time to explore the QBE grid. Notice first that unselected the
Show parameter for Department Num and Job Number. We needed those pieces of
information in order to perform the query but we didn’t want them to show in the query
result. Second, notice that the Department Num Criteria parameter is =43, which tells
Access to find only those employees in the Residential department. Third, notice that the
Job Assignment Criteria parameter is =23, which tells Access to find only those employ-
ees who have Sales jobs. Finally, notice that the Hours Criteria parameter is >4, which
tells Access to find only those employees with more than four hours of assignment.
The result of our query is also shown in Figure M2.15. Although the query may
have seemed difficult when written in narrative form, it was still relatively easy to
implement because of the foreign key relationships we identified earlier.

Figure M2.15
A Conditional Query Using More Than One Relation
24 Skills Module 2

Figure M2.15
A Conditional Query Using More Than One Relation (continued)
 Generating a Report 25

Generating a Report
As we end our very brief tour of Microsoft Access, let’s explore how to build a report.
We’ll dispense with showing you how to build a simple report first and move instead
to a more complicated one that requires the use of two relations. Once you see how
to build a somewhat complicated report, you can easily determine how to build a
simple one.
Building a report is a simple process, even for complicated reports, but you do
have to traverse many more screens. To create a report, we’ll show you how to use a
wizard, and we’ll leave creating a report in Design view up to your exploration. In our
report, we would like to see a list of all employees by ID, name, and name of depart-
ment. Again, this will require the use of two relations, Employee and Department. To
create this report, follow these steps (see Figure M2.16):
1. Select the Reports tab (see panel A).
2. Double-click on Create Report by Using Wizard (see panel B).
3. Under Tables/Queries, select Table: Employee (see panel C).
4. Under Available Fields, select Employee ID and click on the “greater than”
sign (>) to the right; then select Name and click on the “greater than” sign (>)
to the right (see panel D).
5. Under Tables/Queries, select Table: Department (see panel E).
6. Under Available Fields, select Department Name and click on the “greater
than” sign (>) to the right (see panel E).
7. Click on Next.
8. Click on Next. (Allows you to choose ordering of information presentation.)
(See panel F.)
9. Click on Next. (Allows you to specify grouping of information.) (See panel G.)
10. Click on Next. (Allows you to specify sorting of information.) (See panel H.)
11. Click on Next. (Allows you to select layout and page orientation.) (See panel I.)
12. Click on Next. (Allows you to choose from among predefined report styles.)
(See panel I.)
13. Enter “Employee Report” for the title and click on Finish. (See panels J, K,
and L.)
What you’ll then see is a screen representation of your report. It includes only the
information we requested and in the style we chose in step 11.
Unfortunately, we can’t go in great detail concerning all the options you have for
each step. At your leisure, we recommend that back through the process and try some
of the various options.
26 Skills Module 2

Figure M2.16
Creating a Report Using More Than One Relation

B
 Generating a Report 27

D
28 Skills Module 2

F
 Generating a Report 29

H
30 Skills Module 2

J
 Generating a Report 31

L
32 Skills Module 2

Well, that ends our brief tour of Microsoft Access, a subject on which we could eas-
ily have written several hundred pages.
It’s not really a difficult package to learn. The most difficult part happens before
you ever start Access: defining the correct structure of your database. We detailed
that process in Extended Learning Module A and we would definitely recommend
you study that Module if you want to become a designer and user of database appli-
cations. “Using” is the easy part—“designing” is the challenge.

Key Terms and Concepts

composite primary key, 9 foreign key, 10
data dictionary, 3 query-by-example (QBE) tool, 16