U U N IT

4
Introduction to Databases

Source: http://tinyurl.com/o77ysht

Overview

Managers need access to appropriate, relevant and timely information to support

decision making at the operational, tactical and strategic levels. Earlier units introduced
you to Spreadsheets and gave you an opportunity to explore using Spreadsheet software
to organise business data and produce information to support the management
decision making process. While the plethora of features and functions offered by
Spreadsheet software enhances a manager’s ability to store, organise, manage and
analyse business data, its limitations must also be recognised. Spreadsheets provide
users with a range of useful automated features and functions for storing, organising
and managing simple business data and records; enabling basic data processing and
analysis involving sorting, filtering and the application of mathematical, statistical
and logical operations; and producing summaries, charts and other forms of useful
information. Many of these features and functions are relatively accessible to persons
with limited technical experience.

Despite all of these merits Spreadsheets are not a suitable solution for all situations
involving the management of business data. Spreadsheets are not the most effective
tool for situations requiring the capture, storage, organisation and management
of complex sets of business data and records, especially those records that may be
interrelated in some way. Further, Spreadsheets do not naturally offer simultaneous

MGMT2005 Computer Applications for Business – UNIT 4  139

 access to multiple users: only one user may typically access a single Spreadsheet
at a given instant. Though multiple copies of a Spreadsheet file may be made and
distributed amongst multiple users, it is important to note that each individual copy
will still only be accessible to one person at a time. The effect of this is that changes
made to data within any one of these copies will not persist across all other copies.
For example, suppose both the Sales Manager and Customer Services Manager of a
company each kept a copy of a Spreadsheet file containing customer details. Were
the Customer Service Manager to update the contact details of a single customer
these updated details would only exist in the Customer Services department’s copy
of the Spreadsheet. The Sales department’s copy would now be outdated. Decisions
made using information extracted from such outdated data may not be appropriate.
Spreadsheets are therefore not the most appropriate option should many business
stakeholders need to simultaneously interact with, update and use shared business
data and information.

Further, Spreadsheets do not offer a robust platform for the capture, organisation and
management of complex business data and records. They do not offer sufficiently
thorough mechanisms for ensuring that data is captured and added to the software
in a secure way that preserves the integrity of the data being entered. Spreadsheets
also do not offer significant granular mechanisms for restricting or allowing users to
view, interact with, interrogate and use portions of the data available. For situations
requiring such features the more appropriate option would be a Database.

This unit aims to introduce you to Database concepts, Database design practices
and the potential use of Database solutions in addressing a range of business needs.
Additionally, this unit will introduce you to one of the most accessible implementations
of a Database environment, Microsoft Access. Leveraging these database concepts,
practices and software features will allow you to design and develop Database solutions
suitable for addressing long term business management needs. Throughout the unit
you will be expected to participate in a series of tutorials and hands-on exercises
covering the application of database concepts, practices and software features within
a business context.

Unit 4 Learning Objectives

By the end of this unit you will be able to:

1. Explain various database concepts and terms;

2. Analyse a business case;

3. Create an accurate problem/opportunity statement;

4. Conceptualise database solutions best suited to meet the needs of an audience;

5. Simulate real world data and business situations in database models;

6. Apply good design techniques when developing database models;

140  MGMT2005 Computer Applications for Business – UNIT 4

 7. Create databases and tables;

8. Use database tools to solve a problem or satisfy a business need.

This unit comprises three sessions as follows:

Session 4.1: Introduction to Database Concepts

Session 4.2: Evaluating and Managing Relationships among Business Data

Session 4.3: Creating and Using Relational Databases to Solve Business Problems
and Enhance Decision Making

Readings and Resources

Required Resources

Miller, Lisa. (2008). MIS Cases: Decision making with application software (3rd
Edition). Pearson Education Inc., Upper Saddle River, New Jersey

Higly Recommeded Resources

Benson, D. V., & Davis, K. (2008). Business information management. Retrieved

from http://tinyurl.com/gpme8v9

Benson, D. V., & Davis, K. (2013). Business information management: Exercises -

Solutions to hands on exercises. Retrieved from http://tinyurl.com/j4ebas7

Bourgeois, D. (2014).  Information systems for business and beyond.  Retrieved

from http://open.umn.edu/opentextbooks/BookDetail.aspx?bookId=189

GCF Global. (2016). Access 2013. GCFLearnFree.org. Retrieved from:

http://www.gcflearnfree.org/office2013/access2013

Gallaugher, J. (2015).  Information systems: A manager’s guide to harnessing

technology. Retrieved from http://open.umn.edu/opentextbooks/BookDetail.
aspx?bookId=16

Additional Resources

Donalds, C. and Henry, J., Solving managerial problems with spreadsheets and
databases, 2011.

Manzo, J. (2012). How to use Microsoft® Excel® The careers in practice

series. Retrieved fromhttp://open.umn.edu/opentextbooks/BookDetail.
aspx?bookId=70

MGMT2005 Computer Applications for Business – UNIT 4  141

 SSession 4.1

Introduction to Database Concepts

Introduction
To be able to design, develop and use databases to solve business problems or
satisfy business needs one must understand basic Database concepts and terms. This
session will introduce you to Database concepts, terminology and associated design
considerations and practices. Throughout the activities and exercises found within the
session you will learn to use such concepts and practices to analyse business cases and
apply good design techniques when developing database models.

Database
First, what does the term Database mean? A Database is an organised collection of data,
facts or information about places, people, events, transactions, things and concepts. A
Database can be a manual paper-based system (for example an address book or library
card catalogue) or a computer-based software system (for example Microsoft Access).
In paper-based implementations this collection of data or facts is organised as records
stored within a filing system, folder, book, card collection or some other recording and
organisation system. Within software systems like Microsoft Access, this collection of
data or facts is organised as records within tables. You may recall from unit 2 that a
record is simply a collection of individual pieces of related data items. Consider an
address book containing the first name, last name, date-of-birth, address and contact
number of an individual.

First Name: Julia

Last Name: Hanson

Date of Birth: February 2, 1985

Address: 123 Home Street, Dream City

Contact Number: 62-(781)586-1793

Figure 4.1: Example of Paper-Based Records

142  MGMT2005 Computer Applications for Business – UNIT 4

 Each of these data items is related as they capture some specific information about
Julia Hanson. Collectively they form a single record. In Database terminology each
data item depicted here is referred to as a field. In simple terms, a record is a collection
of fields.

Knowledge Check

How many fields are in the example record above?

Answer to Knowledge Check

There are five fields in this example record.

Regardless of the form, manual or computer based, it is important to note that the
records found within a single database should be related in some way. For example,
a single database would not likely be used to store the patient medical history
information for a doctor’s office as well as the customer account information for a
public utility company (for example, electricity, telecommunications or water). These
sets of data are wholly unrelated and should be kept in separate databases.

Complete Learning Activity 4.1 to learn more about relevant database concepts.

ACTIVITY 4.1
Database Concepts (30 minutes)
Instructions:
Task A: Read Chapter 4, Data and Databases in the text at the link below:
Bourgeois, D. (2014). Information systems for Business and Beyond.
Retrieved from

uu http://open.umn.edu/opentextbooks/BookDetail.aspx?bookId=189
While reading, pay particular attention to the sections on Relational
Databases, Primary Keys, Designing a Database and Data Types.
Task B:
In the unit forum, post your thoughts on how databases may prove useful
in the context of your business or job role. Feel free to post questions for
any of the database concepts found within the chapter on which you need
clarification.

MGMT2005 Computer Applications for Business – UNIT 4  143

 Database Design
A well-designed Database is more likely to address the needs of a given business
than a poorly-designed one. The first step in designing a Database usually involves
identifying why you, or your business stakeholders, would want one.

The following are a few of the many questions that you may wish to ask during this
step:

• What are the reasons for wanting to have and use the proposed Database?

• What is its intended purpose?

• What business need or problem will the Database solve or address?

• How will the proposed Database help to achieve business goals?

Having a clear idea of the reason or reasons and the purpose will allow you to design
a Database that is more likely to satisfy the needs of business stakeholders. Consider,
for example, that a business may wish to maintain a list of inventory, distribution
and supplier information for the purposes of managing stock, producing reports on
inventory levels and facilitating the supplier engagement and ordering/reordering
process. This wish may have originated from a problem previously noted by the
business. For example, a business may have experienced lost sales as a result of not
having a given item in stock. In addition to lost income this would likely result in
customer dissatisfaction and may conclude with the customer purchasing the item
from a competitor.

The wish to have a Database may have also arisen from a need derived from a business
strategy or target. For example, a business may have set a goal to surpass last year’s
Mother’s day and Father’s day sales by a minimum of 20%. To do this, the business
may want a facility to extract details of the most popular items from the sales records
from previous periods. Knowing the goal of a Database will help you determine the
type and form of the information the Database must be able to produce as output.
Understanding the information a Database must be able to produce will help you to
determine what pieces of data the Database needs to capture, manage and process in
order to produce the expected output. Such knowledge will also inform other design
and development decisions.

144  MGMT2005 Computer Applications for Business – UNIT 4

 ACTIVITY 4.2
Intended Purpose (20 minutes)
Instructions:
Task A:
Proceed to the Database Tutorial section of your course text (see below):
Miller, Lisa. (2008). MIS Cases: Decision making with application software
(3rd. Edition). Pearson Education Inc., Upper Saddle River, New Jersey
Read the tutorial introduction, background and scenario - Timeka’s Tanning
Salon Inc. on pages 248-249 and post responses to the following in the
Unit forum:

1. List the business problems and/or needs identified.

2. Write a statement describing the intended purpose of the Database

to be developed.

3. Review and comment on the problems and statements posted by

your peers.

Record/Table Design Basics

Once we have determined the purpose and goals of our database the next step is
usually figuring out what sets of information need to be stored, determining how
to best organise this information into records and then designing tables within our
database to organise and store these records.

At the very basic level, record and table design involves a few simple tasks:

1. Determining the records/tables required to store the information about an entity

and assigning these with an appropriate name.

2. Designing the structure of the record/tables by identifying and naming the fields/
columns.

3. Selecting the data type for each of the fields/columns.

4. Determining configuration properties for each field/column.

MGMT2005 Computer Applications for Business – UNIT 4  145

 Records and Tables
A record is a collection of related data items or fields. Records store information about
a “thing” of interest, something a business wants to maintain information about. In
database terminology this “thing” is known as an entity. Records contain details
about entities. Examples of an entity include a person, place, event, transaction or
some other thing of interest.

The examples below show sample records for the Customer – Julia Hanson, the
Customer – Fred Johnson, the Stock item – ABC Brand 8.5 X 11 Inch Printer Paper and
the Payment of $525.00 made on December 3, 2015.

Customer Record
CustomerID: 79019
FirstName: Julia
LastName: Hanson
DateOfBirth: February 2, 1985
Address: 123 Home Street, Dream City
ContactNumber: 62-(781)586-1793
Email: [email protected]

Customer Record
CustomerID: 79020
FirstName: Fred
LastName: Johnson
DateOfBirth: April 15, 1991
Address: 56 Seventh Street, Home City
ContactNumber: 71-(345)531-1357
Email: [email protected]

Stock Record
ItemID: 1234
ItemName: ABC Brand 8.5 X 11 Inch Printer Paper
ItemDescription: 1 Ream (500 sheets) Multipurpose Paper
QuantityInStock: 13
ReorderLevel: 8
MinReorderAmt: 10

Payment Record
PaymentID: 82194
Type: Cash
Amount: $525.00
Date: December 3, 2015
Figure 4.2: Example of Records

146  MGMT2005 Computer Applications for Business – UNIT 4

 From the example above it should be clear that the entities or “things” that we are
interested in maintaining information about include the Customer, Stock and Payment
entities respectively. Since this is what we want to store information about we now
need to design a table to store the records for each entity. Recall that in Microsoft
Access these records are arranged as tables. An alternative way of thinking about it
is that a Microsoft Access table stores the records about an entity or thing of interest.

Record/Table Design
A table stores all of the records about an entity. Once you have identified what entity
you want to maintain information about the next step is to design a table for each.
Table design begins with selecting an appropriate table name. Tables are usually
named after the entity that it is storing information about. Since the information being
stored relates to a thing of interest, the name of the table or record is often based on a
noun. Note that this is not a mandatory requirement but a common practice.

We have seen earlier examples of records for different entities, such as Customer, Stock
and Payment. In Microsoft Access the convention is to either name tables using the
name of the entity the information relates to OR name tables by using the entity name
appended to a prefix or suffix tbl. This allows you to indicate to any user that you are
referring to a table (as opposed to another Microsoft Access component).

A Customer table may be typically referred to in Microsoft Access as Customer,

tblCustomer, Customer_tbl; an Inventory or Stock table may be typically referred to in
Microsoft Access as Inventory, tblInventory, Inventory_tbl, Stock, tblStock, Stock_tbl.

Once you have identified your required tables you should then identify the individual
pieces of data that should be stored within each table. This could be an easy task if you
are simply translating a paper-based record into a Microsoft Access table. The fields of
your paper-based record become the columns of your table. Figure 4.3 and Figure 4.4
below demonstrate such a straightforward table design. Note that in Microsoft Access
the terms field and column are often used interchangeably.

Customer Record
CustomerID: 79019
FirstName: Julia
LastName: Hanson
DateOfBirth: February 2, 1985
Address: 123 Home Street, Dream City
ContactNumber: 62-(781)586-1793
Email: [email protected]
Figure 4.3: Example of paper-based Customer record with fields CustomerID,
FirstName etc.

MGMT2005 Computer Applications for Business – UNIT 4  147

 Customer
CustomerID FirstName LastName DateOfBirth Address ContactNumber Email

Figure 4.4: Basic design of a table to store the Customer records

Some situations are not this straightforward. Sometimes a business has no pre-existing
records about an entity. This requires you to design your records/tables from scratch.
At other times there may be pre-existing records but these records may be in a form
that is not fully suitable for mapping directly into an Access table form.

In performing this design step it is important that you consider any additional data
items or fields that should be captured and maintained. At the very least you should
always ensure that your design includes a field/column that uniquely identifies and
distinguishes each record. In the example above it is possible that two customers may
possess the same name. As such, another field would be needed to uniquely distinguish
one customer from another. In this case that field is CustomerID. You would have had
to add this field if the company did not already maintain this information within their
paper-based records.

In addition to ensuring that an ID field is present there may be situations requiring

you to include other fields. For example, consider a paper-based record-keeping
environment in which a company chooses to store active customer records in one
filing cabinet and dormant customer records in another. Note that this information is
not captured on the face of the record and as such will be lost if all you do is create a
table column for every field. When translating to an Access table you may choose to
instead represent this by including an additional field/column called status.

Field/Column Names
A field stores a single item of data about an entity. First name, last name, date-of-birth
are each examples of a single item of data about a Customer entity that a business
may want to track. These are the fields of a Customer record. In database design
terminology a field may also be referred to as an attribute of an entity. Very simply
a field is a part of a record. In Microsoft Access these are represented as columns
within a table. Do not let all of these terms confuse you. They all mean the same thing
but arise from different points of view. See the chart below to clarify the names used
for each perspective. In Microsoft Access the terms field and column are often used
interchangeably.

148  MGMT2005 Computer Applications for Business – UNIT 4

 Perspective > During high- When referring Within referring
level conceptual to paper-based or to records stored
or design electronic records within a Microsoft
discussions Access Database

Name used attribute of an = field = Column

entity

In Microsoft Access the convention is to give a field or column a name that describes
the data that is being stored. So a Customer’s first name may be typically referred to in
Microsoft Access as First Name, FirstName, fName or simply as First. You will notice
in the example records depicted in Figure 4.2 and 4.3 and the table design depicted in
Figure 4.4 above that all field and column names were descriptive and contained no
spaces. This is a common and recommended practice.

Naming Guidelines and Rules

When naming tables, fields and other Microsoft Access elements keep the following
in mind:

• Use short, simple yet meaningful and descriptive names. Table, 1, Table2, Field8
and Field9 are not descriptive names.

• Names can be up to 64 characters long.

• Names cannot begin with a space.
• Names can include any combination of letters, numbers, spaces, and special
characters EXCEPT a period (.), an exclamation point (!), an accent grave (`),
brackets ([ ]), and double quotation marks (“).

• While names can include special characters, it is common practice to use only
alphanumeric characters when naming your fields.

• While names can include a space, this is discouraged. Use the underscore character
(“_”) instead of a space when necessary.

• Tables and fields should always be consistently named. For example in a given
Database one should not find one table named tblCustomer and another table
named Supplier_tbl. In a given table one should not find a field named First and
another named lastName. Consistency includes details of the name and the letter
case (uppercase and lowercase).

• Capitalise the first letter of every word used within a name.

MGMT2005 Computer Applications for Business – UNIT 4  149

 Data Types
After you have identified and named your fields the next step is to indicate what type
of data is being stored in this space. For Microsoft Access to be able to prepare to store
the data it must be told what form the data will take. To do this you must specify the
data type. At the time of this writing there are ten different data types in Access. These
are described in the table below.
AutoNumber These are numbers that are automatically generated by the system for
each record. This is the data type typically used should you wish the
system to generate and maintain unique numeric IDs for each record.
Number Any numeric values, such as quantities and distances. You can store
both whole numbers and fractional/decimal values. This data type is
not typically used for monetary values as Microsoft Access provides a
better option for such data.
Text This data type accommodates relatively short textual or alphanumeric
values up to a maximum of 255 characters. First name, product name,
street address, department name are examples of fields that may use
the text data type.
Currency This type is used to store monetary values.
Date/Time Dates and times.
Memo Long blocks of text and text that uses text formatting. A typical use of
a Memo field would be a detailed product description.
Hyperlink To store hyperlinks, such as urls and e-mail addresses.
Yes/No This is a logical data type that may be used to store any value that
may be represented in one of two states. For example Yes/No are two
states. May also be used when representing True/False.
OLE Object Object Linking Embedding (OLE) objects, such as Word documents.
This is proprietary technology developed by Microsoft that allows
files and other objects created within one software application to be
embedded within another. In this instance a file or object could be
embedded as part of a record.
Table 4.1: Data Types in Microsoft Access

Field/Column Configuration Properties

After you have named your fields and determined the most appropriate data type
for each, the next step is to indicate any specific field properties. Every field within a
Microsoft Access table has a number of properties that may be configured. Properties
allow you to indicate to the Database environment the expected characteristics and
behaviour of a field. We have already discussed how to select the most important
property for a field, its data type. As discussed within the previous section, a field’s
data type determines what kind of data it can store. Once a data type has been selected
you should consider the rules of the business and the needs of the stakeholders to
determine the required characteristics and behaviour of each given field. For example,

150  MGMT2005 Computer Applications for Business – UNIT 4

 a business may have indicated an interest in storing the email address for a customer
and identified a field to accommodate this. To ensure that the email address data is
stored in an appropriate manner the business may wish to specify field characteristics
and behaviours.

One important Field property is the field size property. Note that the value of this
property differs for some types of data. For Text data types this field allows you to
indicate the maximum number of characters that will be allowed/stored within this
space when implemented as a Database software table. This allows you to reduce
hard disk storage requirements by limiting the allocated space to what you think you
would realistically need to represent that real world data within the Database. For an
email address 25-30 characters would most likely be sufficient. Allocating more than
30 characters would result in space being allocated unnecessarily.

There are a number of field properties that you may choose to configure. Field Size,
Format, Input Mask, Caption and Default Value are all examples of field properties.
This topic will be explored in further detail in upcoming units.

MGMT2005 Computer Applications for Business – UNIT 4  151

 ACTIVITY 4.3
Record/Table Design (20 minutes)
Instructions:
Task A:
Revisit the Database Tutorial section of your course text (see below):

Miller, Lisa. (2008). MIS Cases: Decision making with application software
(3rd. Edition). Pearson Education Inc., Upper Saddle River, New Jersey

Review the tutorial introduction, background and scenario (Timeka’s

Tanning Salon Inc) from Learning Activity 4.2 (pages 248-249). Once
you have reviewed these sections, create a draft of a Record/Table
design suitable for the presented case study. Be sure to adhere to the
guidelines and rules provided and to indicate which field is the Primary
Key. Your design should capture the proposed design details for each of
the tables required in the following format.
Table Name
Field/Column Data Field/Column Field/
Name Type Description Column Size
When you have completed your attempt read pages 250-252 to review
how well your design matches the recommended design for this case.
A partially complete example of a proposed design has been provided
below.

Table Name: Customer

Field/Column Name Data Type Field/Column Field/Column Size
Description
CustomerId Autonumber Serves as Long Integer
the unique
identifier of
each customer
(Primary key)
LastName Text Stores the 50
customer’s last
name
FirstName

152  MGMT2005 Computer Applications for Business – UNIT 4

 Database Design – Next Steps
In addition to the aforementioned database design steps there are a number of
other database design considerations recommended for designing Microsoft Access
Database solutions. The creators of the Access Database software, the Microsoft
Corporation, have provided a number of articles detailing such recommendations
within the software’s help facility.

ACTIVITY 4.4
Database Design (30 minutes)
Instructions:
Task A: Using the help facility of your Microsoft Access software (or any
related online help facility provided by the Microsoft Corporation), locate
and review the guidance provided on database design basics.
Task B:
Proceed to the LE and in the appropriate forum post your thoughts on
how databases may prove useful in the context of your business or job
role. Feel free to post questions on any of the database concepts and
database design recommendations found within the help article that you
need clarified.

Session 4.1 Summary

In Session 4.1 we explored the basic database concepts and reviewed a number of design
and development practices, conventions and steps. In the next session, we will expand
our examination of database concepts by looking at more complex data management
and organisation requirements, specifically using relationships to capture and model
real world data.

MGMT2005 Computer Applications for Business – UNIT 4  153

 SSession 4.2

Evaluating and Managing Relationships

Among Business Data

Introduction
Designing a Database to meet the needs of real world data and business situations is
often a challenging endeavour. This is partially due to the fact that business data is
rarely found to be in a simple standalone form. More often than not such data is messy,
complex and interrelated. In this session you will learn to recognise relationships in
real world data and apply good design techniques when developing database models
for such complex and interrelated real world data and business situations.

Identifying and Evaluating Relationships

The records and tables examined so far have been depicted in a simple standalone way.
This is not necessarily an accurate representation of a real world business situation.
Real records are often interrelated. Within Database implementations the tables storing
these records are usually linked together in a web of relationships. Designing and
developing Databases and tables requires that you consider the business situation and
business data and 1) identify where potential relationships exist and 2) identify the
nature of those relationships (one-to-one, one-to-many, many-to-many). You may recall
these terms from Session 1, Activity 4.4 where you reviewed the help article provided
by the Microsoft Corporation on database design basics. Within the article you were
introduced to the three types of database relationships, the one-to-one relationship,
the one-to-many relationship and the many-to-many relationship. The nature of a
relationship between tables, one-to-one relationship, the one-to-many relationship
and the many-to-many, is also referred to as the cardinality of the relationship. Please
feel free to review the article if necessary.

Now suppose you intend to design and develop a Database for an online retailer to
manage customer, order, payment and stock details. Examination of the business
processes would undoubtedly lead you to create tables for Customer, Order, Payment
and Product Records. Let us consider a purchase made by Customer Julia Hanson and
take a closer look at two of the records and tables that would have been involved in
the purchase, Customer and Payment. These are depicted within Figure 4.5 and Figure
4.6 below.

154  MGMT2005 Computer Applications for Business – UNIT 4

 Customer Record
CustomerID: 79019
FirstName: Julia
LastName: Hanson
DateOfBirth: February 2, 1985
Address: 123 Home Street, Dream City
ContactNumber: 62-(781)586-1793
Email: [email protected]

Customer
CustomerID FirstName LastName DateOfBirth Address ContactNumber Email

Figure 4.5: Example Customer Record and Customer Table

Payment Record
PaymentID: 82194
Type: Cash
Amount: $525.00
Date: December 3, 2015

Payment
PaymentID Type Amount Date

Figure 4.6: Example Payment Record and Payment Table

This Payment Record captures the payment made by Julia to the business. This is an
example of a relationship that may exist between records and tables. This is Julia’s
payment. The record of Julia’s payment should naturally be associated with Julia’s
customer record, otherwise how will the business know who paid what?

MGMT2005 Computer Applications for Business – UNIT 4  155

 Knowledge Check
What is the nature of the relationship between the Customer table and the
Payment table? Is it a one-to-one relationship, a one-to-many relationship or
a many-to-many relationship? Be sure to justify your answer.

Answer to Knowledge Check

Let us consider the business context. In most online businesses a given customer
may want to make a payment on an order. Later on that same customer may
place another order and complete the transaction by making another payment.
If we assume 1) that a payment can only be made by one customer at a time
(i.e. two or more customers cannot contribute to the same payment at one
time) AND 2) that any customer may make multiple payments over time, then
this is an example of a one-to-many relationship. The payment depicted in
the record has been made by the customer Julia alone. However Julia may
want to make many other payments throughout her life as a customer of this
company. The company would definitely want Julia to make many purchases
and payments over time. The database must accommodate this possibility.
The relationship between Customer and Payment must be a one-to-many to
accommodate this requirement.

Accommodating Relationships within the Table Design

The current design of the records and tables for this Database do not yet capture this
relationship. As it is an extremely important piece of data we need to ensure that our
table design can accommodate it.

156  MGMT2005 Computer Applications for Business – UNIT 4

 ACTIVITY 4.5
Defining Relationship (14 - 25 minutes)
Instructions:

Task A:
Watch the video tutorial on Defining table relationships at the link below.
Allardice, S. (2013). Database programming tutorial: Defining table
relationships. Lynda.com [Video file]. Retrieved from:

uu http://www.youtube.com/watch?v=V5DyvUfsboA - Approx. 6 mins.

Task B:
Using the example provided in the video, adjust the design of the records
and tables depicted in Figure 4.6 and Figure 4.7 to properly accommodate
the relationship between the Customer table and the Payment table.

Optional Task C:
For information on a formal Table design process watch the video tutorial
on Entity Relationship Diagrams (ERD).
Baldazzi, G. (2013). Entity Relationship Diagram (ERD) Training Video.
Retrieved from:

uu https://www.youtube.com/watch?v=-fQ-bRllhXc - Approx. 15 mins.

Accommodating One-to-Many Relationships within the Table Design

To adjust the design of the records and tables depicted in Figure 4.6 and Figure
4.7 to properly accommodate the relationship we need to add a new column to the
many side of the relationship (the Payment table). This new column will allow us to
record the customer who made this payment. As such, it must contain the unique ID
of the customer, the CustomerID. CustomerID is therefore a Primary key within the
Customer table and a Foreign key within the Payment table. A relationship has now
been established between these two tables. See the diagram below for details.

MGMT2005 Computer Applications for Business – UNIT 4  157

 Other one-to-many relationships exist in this scenario. Let us consider the Order table
depicted below and its relationship with the Customer table.

Order
OrderID OrderDate

Again, we have a one-to-many as one customer can place many orders. Two customers
cannot place the same order. Though the order may contain the same products each
order is clearly uniquely identified by an OrderID. Since one customer can place many
orders we can accommodate this relationship by again adding a new column to the
many side of the relationship (the Order table). We can indicate that it is a one to
many by annotating our diagram with the characters, 1 and M. Note that this is an
extremely simple way of depicting such relationships. What we are representing with
this annotation is referred to as the cardinality of the relationship.

158  MGMT2005 Computer Applications for Business – UNIT 4

 Knowledge Check
Based on the tables below how many orders has Fred placed? What are the
IDs of these orders?

Customer
CustomerID FirstName LastName
79019 Julia Hanson
81234 Fred Doe
91234 Zoe Zee

Order
OrderID OrderDate CustomerID
012 09/01/2016 81234
123 22/02/2016 79019
245 26/02/2016 81234
567 14/03/2016 91234

MGMT2005 Computer Applications for Business – UNIT 4  159

 Answer to Knowledge Check

Fred has placed two orders, with OrderID of 012 and OrderID of 245.

Knowledge Check
What is the nature of the relationship between the Order entity and the
Product entity? Is it a one-to-one relationship, a one-to-many relationship or
a many-to-many relationship? Feel free to consider real world examples to
help you figure out the answer.

Answer to Knowledge Check

Let us consider the possible business situations that may occur during the
ordering process.

A given order may contain one product. For example a customer, Julia, may
order ABC Brand 8.5 X 11 Inch Printer Paper. One given order may contain
many products. Julia may order both a ream of ABC Brand 8.5 X 11 Inch
Printer Paper AND a Cartridge of black ink for her Printer.

So far, so good. We have considered situations involving: one order containing

one product (one-to-one), one order containing many products (one-to-many).

Let us consider all remaining situations.

Many different orders may contain the same product. For example customers
Julia, Fred and Zoe may each place orders for a ream of ABC Brand 8.5 X 11
Inch Printer Paper. This is a situation involving many orders containing one
specific product.

Many different orders may contain the many products.

For example:

Julia may have placed an order for a ream of ABC Brand 8.5 X 11 Inch Printer
Paper AND a Cartridge of black ink for her Printer.

Fred may have placed an order for a ream of ABC Brand 8.5 X 11 Inch Printer
Paper, a Cartridge of black ink for his Printer AND a headset for his computer.

Zoe may have placed an order for a computer Monitor, a Textbook on MIS
Cases and a desk lamp.

This is therefore an example of a many-to-many relationship.

160  MGMT2005 Computer Applications for Business – UNIT 4

 Accommodating Many-to-Many Relationships within the
Table Design
Many-to-Many relationships cannot be readily accommodated within an Access
Database. To represent these situations within a table design we must first take our
many-to-many relationship and transform it into a series of one-to-many relationships.
We do this by creating another table, sometimes referred to as a bridging table
(Alternative names are: cross-reference table, junction table, intermediary table,
linking table). Consider the diagram below depicting a partial view of the Customer,
Order and Product tables. Note: some of the columns have been deliberately omitted
to simplify the example.

Customer Product
CustomerID FirstName LastName ProductID Name Price
79019 Julia Hanson 1 ABC Brand 8.5 $35.99
81234 Fred Doe X 11 Inch Printer
91234 Zoe Zee Paper
2 Cartridge of black $120.00
ink
3 Computer Head- $100.25
Order
set
OrderID OrderDate CustomerID
4 Computer Moni- $500.12
012 09/01/2016 81234
tor
123 22/02/2016 79019
5 Textbook on MIS $10.99
245 26/02/2016 81234
Cases
567 14/03/2016 91234
6 Desk lamp $44.23

To accommodate a many-to-many relationship between the Order table and the Product
table we create another table. Typically, the name of this table will be a combination
of the names of the tables that possess the many-to-many relationship; in this case we
will call the new table OrderProduct. Though this table MUST include a number of
fields/columns it MUST contain the Primary key of both tables.

MGMT2005 Computer Applications for Business – UNIT 4  161

 In the modified design there is now a one-to-many relationship between Order
and OrderProduct and another one-to-many relationship between Product and
OrderProduct. Alternatively we could say that there is a many-to-one relationship
between OrderProduct and Product. Again, we can annotate our diagram to depict
these relationships. Note that this is an extremely simple way of depicting such
relationships.

In this new table you can choose to have a compound key as the primary key. A
compound key is a key that consists of two or more keys combined; collectively this
combination uniquely identifies a record. Alternatively you could create another
column called OrderProductID and assign that to be the primary key.

162  MGMT2005 Computer Applications for Business – UNIT 4

 Knowledge Check

Based on the example provided above what items did Zoe order?

Answer to Knowledge Check

Zoe ordered a Cartridge of black ink and a desk lamp.

Accommodating One-to-One Relationships within the Table

Design
Now that the more complex situations have been addressed, let us consider how to
accommodate one-to-one relationships. In a one-to-one relationship, each row in one
table is linked to 1 and only 1 other row in another table. For example, a customer will
be expected to have only one username and password for the online store. This data
may be stored in a table called UserAccount.

Customer UserAccount
CustomerID FirstName LastName UserAccountID UsernameName Password
79019 Julia Hanson 1 Superj Password
81234 Fred Doe 2 FredD Pass1234
91234 Zoe Zee 3 Zz ZZ1234

To associate a customer within our design we again need a reference to the Customer.
Since the Customer is the main Entity we are interested in, referred to as the Parent,
the typical approach would be to create another column within the UserAccount table
to store the primary key of the more important Entity. In this case the UserAccount is
referred to as the Child. A rule of thumb is that the child is the entity that cannot exist
without the Parent. In this example we can assume that without a Customer there can
be no UserAccount. This new column added to the UserAccount table will allow us to
record the Customer who owns this UserAccount. As such, it must contain the unique
ID of the customer, the CustomerID.

MGMT2005 Computer Applications for Business – UNIT 4  163

 Designing Tables for the Real World
The examples above describe typical real world situations in a simplified way.
You should research designing database tables, relationships and the concept of
normalisation (introduced in Learning Activity 4.4) in further detail when attempting
to create your own design to model real world business data using a Database.

ACTIVITY 4.6
Table Design (15 minutes)
Instructions:
Revisit the Database Tutorial section of your course text (see below):

Miller, Lisa. (2008). MIS Cases: Decision making with application software
(3rd. Edition). Pearson Education Inc., Upper Saddle River, New Jersey
Review the tutorial introduction, background and scenario (Timeka’s
Tanning Salon Inc) from Learning Activity 4.2 (pages 248-249).
Once you have reviewed these sections, consider the table relationships
required for the scenario. When you are ready go to the Storage
Specification section of the tutorial (pages 250) and read the discussion
provided by the author detailing the required relationships and how they
will be implemented.

Session 4.2 Summary

In Session 4.2 we explored examples of related business data, the concept of cardinality
and relationship types and learnt how to model such situations within a table design.
In the next session, we will begin to apply the concepts and practices discussed so far
within this unit and build a database using Microsoft Access.

164  MGMT2005 Computer Applications for Business – UNIT 4

 SSession 4.3

Creating and Using Relational Databases

to Solve Business Problems and Enhance
Decision Making

Introduction
Now that you are familiar with database concepts, terminology and good database
design practices it is time to examine how such may be applied in the real world.
In this session you will learn to simulate real world data and business situations in
database models by using Databases to create and edit tables and relationships. This
session will first quickly recap some of the important topics from Session 1 and 2. It will
then introduce you to the Microsoft Access Interface and give you the opportunity to
review a case study and examine how the author of the study has applied the concepts
and practices to satisfy a business need. Your review of the author’s narrative should
reinforce in your mind the concepts discussed and hopefully assist you in integrating
and applying this knowledge in future exercises. Completing the case study will
enable you to develop your skill in using the Microsoft Access software.

Database Terminology and an Introduction to the Parts of an

Access Database

MGMT2005 Computer Applications for Business – UNIT 4  165

 ACTIVITY 4.7
Database Terminology Recap and Introduction to the Parts of
an Access Database (14 minutes)
Instructions:
Task A: Click on the links to access the video tutorial for your version of
the Microsoft Access software. Review the video tutorial to recap Database
Terminology and concepts and learn about the components of an Access
Database.

For Microsoft Access 2010 users:

Post, R. (2011). PC Learning Zone - Computer Training: Microsoft Access
2010 Tutorial Part 01 of 12 – Database Terminology. Retrieved from:

uu http://www.youtube.com/watch?v=pHiOXZEbK-4 - Approx. 12 mins.

For Microsoft Access 2013 users:
Post, R. (2013). PC Learning Zone - Computer Training: Microsoft Access
2013 Tutorial Part 01 of 12 – Database Terminology. Retrieved from

uu http://www.youtube.com/watch?v=jM_O-JopORM - Approx. 14 mins.

Knowledge Check
Based on the video, what are the six parts of a Microsoft Access Database?
Note: These parts may also be referred to as the Microsoft Access Database
objects.

Answer to Knowledge Check

Tables, Queries, Forms, Reports, Macros and Modules

Knowledge Check
Which Access Database object allows you to build a user friendly interface
to add records to a table and view and change records found within an
Access Table?

166  MGMT2005 Computer Applications for Business – UNIT 4

 Answer to Knowledge Check

Forms

Planning your Database

ACTIVITY 4.8
Planning Your Database (14 minutes)
Instructions:

Task A: Using the links provided to the video tutorial for your version
of the Microsoft Access software, review the video tutorial to recap some
of the important considerations when planning and designing an Access
Database.

For Microsoft Access 2010 users:

Post, R. (2011). PC Learning Zone - Computer Training: Microsoft Access
2010 Tutorial Part 02 of 12 – Planning Your Database. Retrieved from

uu http://www.youtube.com/watch?v=u1Yy83BHGbg - Approx. 9 mins.

For Microsoft Access 2013 users:
Post, R. (2013). PC Learning Zone - Computer Training: Microsoft Access
2013 Tutorial Part 02 of 12 – Planning Your Database. Retrieved from

uu http://www.youtube.com/watch?v=cHRLNT4MdI4 - Approx. 12 mins.

Knowledge Check
Based on your recollection of database design discussion from Session
1 and the video provided in Learning Activity 4.8, list the first that you
should do when designing and planning a database?

Answer to Knowledge Check

Plan the database on paper. Figure out the purpose of the database, the
features you would like included in the database and determine what
information you would like to store within the database. Design the tables,
relationships and identify the fields/columns of the tables.

MGMT2005 Computer Applications for Business – UNIT 4  167

 The Access Interface

ACTIVITY 4.9
The Access Interface (10 minutes)
Instructions:

Task A:
Using the links provided for your version of the Microsoft Access software,
watch the video introducing you to the Access Database Interface to
familiarise yourself with the environment.

For Microsoft Access 2010 users:

Post, R. (2011). PC Learning Zone - Computer Training: Microsoft Access
2010 Tutorial Part 03 of 12 - The Access Interface.Retrieved from

uu http://www.youtube.com/watch?v=5pBDhwfM1Tc - Approx. 11 mins.

For Microsoft Access 2013 users:
Post, R. (2013). PC Learning Zone - Computer Training: Microsoft Access
2013 Tutorial Part 03 of 12 - The Access Interface. Retrieved from

uu http://www.youtube.com/watch?v=EvY2xqU0L_s - Approx. 13 mins.

Now that you are familiar with the Microsoft Access Database let us practise what we
have learnt by attempting to build a basic database in Learning Activity 4.10.

168  MGMT2005 Computer Applications for Business – UNIT 4

 ACTIVITY 4.10
Timeka’s Tanning Solon, Inc. Case Study Section (30 minutes)
Instructions:

Task A:
Proceed to the Database Tutorial section of your course text (see below):

Miller, Lisa. (2008). MIS Cases: Decision making with application software
(3 rd. Edition). Pearson Education Inc., Upper Saddle River, New Jersey
Read the Timeka’s Tanning Solon, Inc. case study (pg. 248-255) and
complete Activity 1 of the Database Tutorial (pg. 255-265) using Microsoft
Access.
The steps have been provided for you within the Database Tutorial (pg.
255-265).

(Optional) Task B:
Complete Activity 2 of the Database Tutorial (pg. 265-278).

Session 4.3 Summary

In Session 4.3 we examined a case study and performed the steps needed to develop a
relational database in response to the stated business problems and business needs of
the fictitious company depicted within the case study. Though this session provided
just a basic introduction to developing Microsoft Access databases, the exercise would
have shown you the practical application of the concepts and practices discussed
in Session 1 and 2. Collectively the knowledge and skill developed in this unit will
support the future application of database concepts and practices in designing and
developing more complex and robust Database solutions involving other Microsoft
Access objects including Forms, Queries and Reports.

MGMT2005 Computer Applications for Business – UNIT 4  169

 Unit 4 Summary

In this unit we were exposed to a number of Database concepts, terms, design and
development practices and we had the opportunity to design, create and use Database
solutions to solve business problems or satisfy a business need. Being able to effectively
design tables and manage table relationships is an important skill when attempting
to accurately model real world data within a computer system. This foundation
knowledge should enable you to design and build effective Database solutions that
will be able to produce the information needed to support operational, tactical and
strategic decisions. In the upcoming unit you will review and expand upon table and
relationship design, development and configuration and will be shown how to add
and edit database records.

170  MGMT2005 Computer Applications for Business – UNIT 4

 References
Allardice, S. (2013). Database programming tutorial: Defining table
relationships. Lynda.com. Retrieved from: http://www.youtube.com/
watch?v=V5DyvUfsboA

Baldazzi, G. (2013). Entity Relationship Diagram (ERD) Training Video. Retrieved

from: http://www.youtube.com/watch?v=V5DyvUfsboA

Gallaugher, J. (2015). Information systems: A manager’s guide to harnessing

technology. Retrieved from: http://open.umn.edu/opentextbooks/
BookDetail.aspx?bookId=16

Miller, Lisa. (2008). MIS Cases: Decision making with application software (3rd
Edition). Pearson Education Inc., Upper Saddle River, New Jersey

Post, R. (2011). PC Learning Zone - Computer Training: Microsoft Access 2010

Tutorial Part 03 of 12 - The Access Interface. Retrieved from: http://www.
youtube.com/watch?v=5pBDhwfM1Tc

Post, R. (2013). PC Learning Zone - Computer Training: Microsoft Access 2013

Tutorial Part 03 of 12 - The Access Interface. Retrieved from: http://www.
youtube.com/watch?v=EvY2xqU0L_s

MGMT2005 Computer Applications for Business – UNIT 4  171