C

Course Title :
Accounting Information
System

Chapter 4 AIS

Relational Databases
© 2008 Prentice Hall Business Publishing Accounting
AccountingInformation
InformationSystems,
Systems,11/e
11/e Romney/Steinbart
Romney/Steinbart
 INTRODUCTION
• Questions to be addressed in this chapter:
– How are databases different than file-based legacy sys-
tems?
– Why are databases important and what is their advantage?
– What is the difference between logical and physical views
of a database?
– What are the fundamental concepts of database systems
such as DBMS, schemas, the data dictionary, and DBMS
languages?
– What is a relational database, and how does it organize
data?
– How are tables structured to properly store data in a rela-
tional database?

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 INTRODUCTION
• Relational databases underlie most modern
integrated AISs.
– They are the most popular type of database used
for transaction processing.
– In this chapter, we’ll define the concept of a data-
base.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
• Let’s examine some basic principles about how data are
stored in computer systems.
– An entity is anything about which the organization wishes to store
data. At your college or university, one entity would be the student.

STUDENTS

Student ID Last Name First Name Phone Number Birth Date

333-33-3333 Simpson Alice 333-3333 10/11/84

111-11-1111 Sanders Ned 444-4444 11/24/86

123-45-6789 Moore Artie 555-5555 04/20/85

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
– Information about the attributes of an entity (e.g., the
student’s ID number and birth date) are stored in fields.

STUDENTS

Student ID Last Name First Name Phone Number Birth Date

333-33-3333 Simpson Alice 333-3333 10/11/84

111-11-1111 Sanders Ned 444-4444 11/24/86

123-45-6789 Moore Artie 555-5555 04/20/85

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
– All the fields containing data about one entity (e.g., one
student) form a record.
– The example below shows the record for Artie Moore.

STUDENTS

Student ID Last Name First Name Phone Number Birth Date

333-33-3333 Simpson Alice 333-3333 10/11/84

111-11-1111 Sanders Ned 444-4444 11/24/86

123-45-6789 Moore Artie 555-5555 04/20/85

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
– A set of all related records forms a file (e.g., the student
file).
– If this university only had three students and five fields for
each student, then the entire file would be depicted be-
low.

STUDENTS

Student ID Last Name First Name Phone Number Birth Date

333-33-3333 Simpson Alice 333-3333 10/11/84

111-11-1111 Sanders Ned 444-4444 11/24/86

123-45-6789 Moore Artie 555-5555 04/20/85

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
– A set of interrelated, centrally coordinated files forms a
database.

Student Class
File File

Advisor
File
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
• Database systems were developed to address
the problems associated with the propagation
of master files.
– For years, each time a new information need
arose, companies created new files and programs.
– The result: a significant increase in the number of
master files.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
• This proliferation of master files
Master File 1
Fact A
Enrollment created problems:
Program – Often the same information was
Fact B
Fact C stored in multiple master files.
– Made it more difficult to effectively
integrate data and obtain an organi-
zation-wide view of the data.
Master File 2
Financial Aid – Also, the same information may not
Fact A
Fact D Program have been consistent between files.
Fact F • If a student changed his phone
number, it may have been up-
dated in one master file but not
another.
Master File 1 Grades
Fact A Program
Fact B
Fact F

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
Database
• A database is a set of
Fact A Fact B
Fact C Fact D inter-related, cen-
Fact E Fact F
trally coordinated
files.
Database
Management
System

Enrollment Financial Aid Grades

Program Program Program

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
• The database approach
Database treats data as an organiza-
Fact A Fact B
Fact C Fact D
tional resource that should
Fact E Fact F be used by and managed for
the entire organization, not
just a particular department.
• A database management
Database
Management
system (DBMS) serves as the
System
interface between the data-
base and the various appli-
cation programs.
Enrollment Financial Aid Grades
Program Program Program

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
Database
• The combination of
Fact A Fact B
Fact C Fact D the database, the
Fact E Fact F
DBMS, and the appli-
cation programs that
Database
Management
access the database
System is referred to as the
database system.
Enrollment Financial Aid Grades
Program Program Program

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 FILE VS. DATABASES
• The person responsible
Database
Fact A Fact B for the database is the
Fact C Fact D
Fact E Fact F database administrator.
•
•Hewlett-Packard
As technology is replac-
improves,
ing 784 databases with a
manycompany-wide
single, large companies
Database are developing very
database.
Management
System large databases called
data warehouses.
Enrollment Financial Aid Grades
Program Program Program

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• Database technology is everywhere.
– Most new AISs implement a database approach.
– Virtually all mainframe computer sites use data-
base technology.
– Use of databases with PCs is growing also.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• As accountants, you are likely to audit or work for
companies that use database technology to store,
process, and report accounting transactions.
– Many accountants work directly with databases and will
enter, process, and query databases.
– Some will develop and evaluate internal controls necessary
to ensure database integrity.
– Others will be involved in the design and management of
databases.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• Database technology provides the following
benefits to organizations:
– Data integration • Achieved by combining
master files into larger
pools of data accessible
by many programs.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• Database technology provides the following
benefits to organizations:
– Data integration
– Data sharing
• It’s easier to share data that’s integrated—
the FBI is planning an 8 year, $400 million
database project to make data more avail-
able to agency users.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• Database technology provides the following
benefits to organizations:
– Data integration
– Data sharing
– Reporting flexibility
• Reports can be revised easily and gen-
erated as needed.
• The database can easily be browsed to
research problems or obtain detailed in-
formation.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• Database technology provides the following
benefits to organizations:
– Data integration
– Data sharing
– Reporting flexibility
– Minimal data redundancy and inconsistencies
• Because data items are
usually stored only once.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• Database technology provides the following
benefits to organizations:
– Data integration
• Data items are independent of the programs that
use them.
– Data sharing
• Consequently, a data item can be changed with-
– Reporting flexibility
out changing the program and vice versa.
• Makes programming easier and simplifies data
– Minimal data redundancy and inconsistencies
management.
– Data independence

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• Database technology provides the following
benefits to organizations:
– Data integration
– Data sharing
– Reporting flexibility
• Data management is more efficient be-
– Minimal data redundancy and inconsistencies
cause the database administrator is re-
sponsible for coordinating, controlling,
– Data independenceand managing data.
– Central management of data

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• Database technology provides the following
benefits to organizations:
– Data integration
– Data sharing
– Reporting flexibility
• Relationships can be explicitly defined and
– Minimal data used
redundancy and inconsistencies
in the preparation of management re-
– Data independence
ports.
• EXAMPLE: Relationship between selling
– Central management
costs andof data
promotional campaigns.
– Cross-functional analysis

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 IMPORTANCE AND ADVANTAGES OF DATABASE
SYSTEMS
• The importance of good data:
– Bad data leads to:
• Bad decisions
• Embarrassment
• Angry users

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Logical and physical views of data
– In file-oriented systems, programmers must know
the physical location and layout of records used by
a program.
• They must reference the location, length, and format of
every field they utilize.
• When data is used from several files, this process be-
comes more complex.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Database systems overcome this problem by
separating the storage and use of data ele-
ments.
– Two separate views of the data are provided:
• Logical view
 How the user or programmer conceptually
organizes and understands the data.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Database systems overcome this problem by
separating the storage and use of data ele-
ments.
– Two separate views of the data are provided:
• Logical view
• Physical view
 How and where the data are physically ar-
ranged and stored.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Database systems overcome this problem by
separating the storage and use of data ele-
ments.
– Two separate views of the data are provided:
• Logical view
• Physical view
– Separating these views facilitates application de-
velopment, because programmers can focus on
coding the logic and not be concerned with stor-
age details.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 Logical View—User A Logical View—User B
Scholarship Distribution
Enrollment by Class Fr.
5%
Sr. Soph.
33% 24%

Jr.
38%

The DBMS translates

DBMS users’ logical views
into instructions as to
which data should be
Operating retrieved from the
System database.

Database

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 Logical View—User A Logical View—User B
Scholarship Distribution
Enrollment by Class Fr.
5%
Sr. Soph.
33% 24%

Jr.
38%

DBMS
The operating system
Operating translates DBMS re-
System quests into instruc-
tions to physically re-
trieve data from vari-
ous disks.
Database

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• The DBMS handles the link between the phys-
ical and logical views of the data.
– Allows the user to access, query, and update data
without reference to how or where it is physically
stored.
– The user only needs to define the logical data re-
quirements.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Separating the logical and physical views of data also
means- users can change their conceptualizations of
the data relationships without making changes in the
physical storage.
• The database administrator can also change the
physical storage of the data without affecting users
or application programs.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Schemas
– A schema describes the logical structure of a
database.
– There are three levels of schema.
• Conceptual level
• The organization-wide view of the entire
database—i.e., the big picture.
• Lists all data elements and the relationships
between them.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 Subschema--User A Subschema--User B Subschema--User C
Smith . . . A
Jones . . . B
Arnold . . .D

Mapping external-level views to conceptual-level schema

Classes Enroll Student

Cash
Receipt

Mapping conceptual-level items to internal-level descriptions

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Schemas
– A schema describes the logical structure of a
database.
– There are three levels of schema.
• Conceptual level
• External level
• A set of individual user views of portions of
the database, i.e., how each user sees the
portion of the system with which he inter-
acts.
• These individual views are referred to as
subschema.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 Subschema--User A Subschema--User B Subschema--User C
Smith . . . A
Jones . . . B
Arnold . . .D

Mapping external-level views to conceptual-level schema

Classes Enroll Student

Cash
Receipt

Mapping conceptual-level items to internal-level descriptions

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Schemas
– A schema describes the logical structure of a
database.
– There are three levels of schema.
• Conceptual level • A low-level view of the database.
• External level • It describes how the data are actually
stored and accessed including:
• Internal level
– Record layouts
– Definitions
– Addresses
– Indexes

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 Subschema--User A Subschema--User B Subschema--User C
Smith . . . A
Jones . . . B
Arnold . . .D

Mapping external-level views to conceptual-level schema

Classes Enroll Student

Cash
Receipt

Mapping conceptual-level items to internal-level descriptions

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 Subschema--User A Subschema--User B Subschema--User C
Smith . . . A
Jones . . . B
Arnold . . .D

Mapping external-level views to conceptual-level schema

The bidirec-
Classes Enroll Student tional arrows
represent
mappings be-
tween the
Cash
schema.
Receipt

Mapping conceptual-level items to internal-level descriptions

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• The DBMS uses the mappings to translate a
request by a user or program for data (ex-
pressed in logical names and relationships)
into the indexes and addresses needed to
physically access the data.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Accountants are frequently involved in devel-
oping conceptual- and external-level schema.
• An employee’s access to data should be lim-
ited to the subschema of data that is relevant
to the performance of his job.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• The data dictionary
– A key component of a DBMS is the data dictionary.
• Contains information about the structure of the data-
base.
• For each data element, there is a corresponding record
in the data dictionary describing that element.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Information provided for each element includes:
– A description or explanation of the element.
– The records in which it is contained.
– Its source.
– The length and type of the field in which it is stored.
– The programs in which it is used.
– The outputs in which it is contained.
– The authorized users of the element.
– Other names for the element.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
 Accountants should participate in the development
of the data dictionary because they have a good un-
derstanding of the data elements in a business orga-
nization, as well as where those elements originate
and how they are used.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• The DBMS usually maintains the data dictionary.
– It is often one of the first applications of a newly imple-
mented database system.
– Inputs to the dictionary include:
• Records of new or deleted data elements.
• Changes in names, descriptions, or uses of existing elements.
– Outputs include:
• Reports that are useful to programmers, database designers, and
IS users in:
– Designing and implementing the system.
– Documenting the system.
– Creating an audit trail.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• DBMS Languages
– Every DBMS must provide a means of per-
forming the three basic functions of:
• Creating a database
• Changing a database
• Querying a database

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Creating a database:
– The set of commands used to create the database
is known as data definition language (DDL). DDL
is used to:
• Build the data dictionary
• Initialize or create the database
• Describe the logical views for each individual user or
programmer
• Specify any limitations or constraints on security im-
posed on database records or fields

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Changing a database
– The set of commands used to change the data-
base is known as data manipulation language
(DML). DML is used for maintaining the data in-
cluding:
• Updating data
• Inserting data
• Deleting portions of the database

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Querying a database:
– The set of commands used to query the database is known
as data query language (DQL). DQL is used to interrogate
the database, including:
• Retrieving records
• Sorting records
• Ordering records
• Presenting subsets of the database
– The DQL usually contains easy-to-use, powerful commands
that enable users to satisfy their own information needs.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Report Writer
– Many DBMS packages also include a report writer, a lan-
guage that simplifies the creation of reports.
– Users typically specify:
• What elements they want printed
• How the report should be formatted
– The report writer then:
• Searches the database
• Extracts specified data
• Prints them out according to specified format

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS
• Users typically have access to both DQL and report
writer.
• Access to DQL and DML are typically restricted to
employees with administrative and programming re-
sponsibilities.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• A DBMS is characterized by the type of logical
data model on which it is based.
– A data model is an abstract representation of the
contents of a database.
– Most new DBMSs are called relational databases
because they use the relational model developed
by E. F. Codd in 1970.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• The relational data model represents every-
thing in the database as being stored in the
forms of tables (aka, relations).

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS
Last First Phone
Student ID Name Name No.
333-33-3333 Simpson Alice 333-3333
Relation
111-11-1111 Sanders Ned 444-4444
123-45-6789 Moore Artie 555-5555

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30

STUDENT x COURSE
SCID Student ID Course
333333333-1234 333-33-3333 1234
333333333-1236 333-33-3333 1236
111111111-1235 111-11-1111 1235
111111111-1236 111-11-1111 1235
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• This model only describes how the data ap-
pear in the conceptual- and external-level
schemas.
• The data are physically stored according to the
description in the internal-level schema.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS Each row is
Last First Phone called a tuple,
Student ID Name Name No. which rhymes
333-33-3333 Simpson Alice 333-3333 with “couple.”
111-11-1111 Sanders Ned 444-4444
123-45-6789 Moore Artie 555-5555

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30
STUDENT x COURSE
SCID
333333333-1234
333333333-1236
111111111-1235
111111111-1236
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 Each row con-
STUDENTS
tains data about
Last First Phone
a specific occur-
Student ID Name Name No.
rence of the type
333-33-3333 Simpson Alice 333-3333
of entity in the
111-11-1111 Sanders Ned 444-4444
table.
123-45-6789 Moore Artie 555-5555

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30
STUDENT x COURSE
SCID
333333333-1234
333333333-1236
111111111-1235
111111111-1236
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS Each column in
Last First Phone a table contains
Student ID Name Name No. information
333-33-3333 Simpson Alice 333-3333 about a specific
111-11-1111 Sanders Ned 444-4444 attribute of the
123-45-6789 Moore Artie 555-5555 entity.

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30
STUDENT x COURSE
SCID
333333333-1234
333333333-1236
111111111-1235
111111111-1236
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS
Last First Phone
Student ID Name Name No.
333-33-3333 Simpson Alice 333-3333
111-11-1111 Sanders Ned 444-4444
123-45-6789 Moore Artie 555-5555

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30
STUDENT x COURSE
A primary key is the at-
SCID
tribute or combination of
333333333-1234 attributes that uniquely
333333333-1236 identifies a specific row
111111111-1235 in a table.
111111111-1236
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS
Last First Phone
Student ID Name Name No.
333-33-3333 Simpson Alice 333-3333
111-11-1111 Sanders Ned 444-4444
123-45-6789 Moore Artie 555-5555

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30
STUDENT x COURSE
SCID
333333333-1234 In some tables, two or more attributes
333333333-1236 may be joined to form the primary key.
111111111-1235
111111111-1236
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS

Student ID Last Name First Name Phone No. Advisor No.

333-33-3333 Simpson Alice 333-3333 1418
111-11-1111 Sanders Ned 444-4444 1418
123-45-6789 Moore Artie 555-5555 1503

ADVISORS
Advisor No. Last Name First Name Office No.
1418 Howard Glen 420
1419 Melton Amy 316
1503 Zhang Xi 202
1506 Radowski J.D. 203

A foreign key is an attribute in one table that is a primary key in

another table.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS

Student ID Last Name First Name Phone No. Advisor No.

333-33-3333 Simpson Alice 333-3333 1418
111-11-1111 Sanders Ned 444-4444 1418
123-45-6789 Moore Artie 555-5555 1503

ADVISORS
Advisor No. Last Name First Name Office No.
1418 Howard Glen 420
1419 Melton Amy 316
1503 Zhang Xi 202
1506 Radowski J.D. 203

Foreign keys are used to link tables together.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS

Student ID Last Name First Name Phone No. Advisor No.

333-33-3333 Simpson Alice 333-3333 1418
111-11-1111 Sanders Ned 444-4444 1418
123-45-6789 Moore Artie 555-5555 1503

ADVISORS
Advisor No. Last Name First Name Office No.
1418 Howard Glen 420
1419 Melton Amy 316
1503 Zhang Xi 202
1506 Radowski J.D. 203

Other non-key attributes in each table store important

information about the entity.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Alternatives for storing data
– One possible alternate approach would be to store
all data in one uniform table.
– For example, instead of separate tables for stu-
dents and classes, we could store all data in one
table and have a separate line for each student x
class combination.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 First
Student ID Last Name Name Phone No. Course No. Section Day Time
333-33-3333 Simpson Alice 333-3333 ACCT-3603 1 M 9:00 AM
333-33-3333 Simpson Alice 333-3333 FIN-3213 3 Th 11:00 AM
333-33-3333 Simpson Alice 333-3333 MGMT-3021 11 Th 12:00 PM
111-11-1111 Sanders Ned 444-4444 ACCT-3433 2 T 10:00 AM
111-11-1111 Sanders Ned 444-4444 MGMT-3021 5 W 8:00 AM
111-11-1111 Sanders Ned 444-4444 ANSI-1422 7 F 9:00 AM
123-45-6789 Moore Artie 555-5555 ACCT-3433 2 T 10:00 AM
123-45-6789 Moore Artie 555-5555 FIN-3213 3 Th 11:00 AM

• Using the suggested approach, a student taking three classes

would need three rows in the table.
• In the above, simplified example, a number of problems arise.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 First
Student ID Last Name Name Phone No. Course No. Section Day Time
333-33-3333 Simpson Alice 333-3333 ACCT-3603 1 M 9:00 AM
333-33-3333 Simpson Alice 333-3333 FIN-3213 3 Th 11:00 AM
333-33-3333 Simpson Alice 333-3333 MGMT-3021 11 Th 12:00 PM
111-11-1111 Sanders Ned 444-4444 ACCT-3433 2 T 10:00 AM
111-11-1111 Sanders Ned 444-4444 MGMT-3021 5 W 8:00 AM
111-11-1111 Sanders Ned 444-4444 ANSI-1422 7 F 9:00 AM
123-45-6789 Moore Artie 555-5555 ACCT-3433 2 T 10:00 AM
123-45-6789 Moore Artie 555-5555 FIN-3213 3 Th 11:00 AM

• Suppose Alice Simpson changes her phone number. You need to

make the change in three places. If you fail to change it in all three
places or change it incorrectly in one place, then the records for
Alice will be inconsistent.
• This problem is referred to as an update anomaly.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 First
Student ID Last Name Name Phone No. Course No. Section Day Time
333-33-3333 Simpson Alice 333-3333 ACCT-3603 1 M 9:00 AM
333-33-3333 Simpson Alice 333-3333 FIN-3213 3 Th 11:00 AM
333-33-3333 Simpson Alice 333-3333 MGMT-3021 11 Th 12:00 PM
111-11-1111 Sanders Ned 444-4444 ACCT-3433 2 T 10:00 AM
111-11-1111 Sanders Ned 444-4444 MGMT-3021 5 W 8:00 AM
111-11-1111 Sanders Ned 444-4444 ANSI-1422 7 F 9:00 AM
123-45-6789 Moore Artie 555-5555 ACCT-3433 2 T 10:00 AM
123-45-6789 Moore Artie 555-5555 FIN-3213 3 Th 11:00 AM

• What happens if you have a new student to add, but he hasn’t

signed up for any courses yet?
• Or what if there is a new class to add, but there are no students
enrolled in it yet? In either case, the record will be partially blank.
• This problem is referred to as an insert anomaly.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 First
Student ID Last Name Name Phone No. Course No. Section Day Time
333-33-3333 Simpson Alice 333-3333 ACCT-3603 1 M 9:00 AM
333-33-3333 Simpson Alice 333-3333 FIN-3213 3 Th 11:00 AM
333-33-3333 Simpson Alice 333-3333 MGMT-3021 11 Th 12:00 PM
111-11-1111 Sanders Ned 444-4444 ACCT-3433 2 T 10:00 AM
111-11-1111 Sanders Ned 444-4444 MGMT-3021 5 W 8:00 AM
111-11-1111 Sanders Ned 444-4444 ANSI-1422 7 F 9:00 AM
123-45-6789 Moore Artie 555-5555 ACCT-3433 2 T 10:00 AM
123-45-6789 Moore Artie 555-5555 FIN-3213 3 Th 11:00 AM

• If Ned withdraws from all his classes and you eliminate all three of
his rows from the table, then you will no longer have a record of
Ned. If Ned is planning to take classes next semester, then you
probably didn’t really want to delete all records of him.
• This problem is referred to as a delete anomaly.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Alternatives for storing data
– Another possible approach would be to store each
student in one row of the table and create multi-
ple columns to accommodate each class that he is
taking.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 First
Student ID Last Name Name Phone No. Class 1 Class 2 Class 3 Class 4

333-33-3333 Simpson Alice 333-3333 ACCT-3603 FIN-3213 MGMT-3021  

111-11-1111 Sanders Ned 444-4444 ACCT-3433 MGMT-3021 ANSI-1422  

123-45-6789 Moore Artie 555-5555 ACCT-3433 FIN-3213    

• This approach is also fraught with problems:

– How many classes should you allow in building the table?
– The above table is quite simplified. In reality, you might need to
allow for 20 or more classes (assuming a student could take
many 1-hour classes). Also, more information than just the
course number would be stored for each class. There would be
a great deal of wasted space for all the students taking fewer
than the maximum possible number of classes.
– Also, if you wanted a list of every student taking MGMT-3021,
notice that you would have to search multiple attributes.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS
Last First Phone
Student ID Name Name No.
333-33-3333 Simpson Alice 333-3333
111-11-1111 Sanders Ned 444-4444
123-45-6789 Moore Artie 555-5555

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30
STUDENT x COURSE • The solution to the preceding problems
SCID is to use a set of tables in a relational
333333333-1234 database.
333333333-1236 • Each entity is stored in a separate table,
111111111-1235 and separate tables or foreign keys can
111111111-1236 be used to link the entities together.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Basic requirements of a relational database
– Every column in a row must be single valued.
• In other words, every cell can have one and only one
value.
• In the student table, you couldn’t have an attribute
named “Phone Number” if a student could have multi-
ple phone numbers.
• There might be an attribute named “local phone num-
ber” and an attribute named “permanent phone num-
ber.”
• You could not have an attribute named “Class” in the
student table, because a student could take multiple
classes.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Basic requirements of a relational database
– The primary key cannot be null.
• The primary key uniquely identifies a specific row in the
table, so it cannot be null, and it must be unique for
every record.
• This rule is referred to as the entity integrity rule.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS
Last First Phone
Student ID Name Name No.
333-33-3333 Simpson Alice 333-3333
111-11-1111 Sanders Ned 444-4444
123-45-6789 Moore Artie 555-5555

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30
STUDENT x COURSE
SCID • Note that within each table, there are no
333333333-1234 duplicate primary keys and no null pri-
333333333-1236 mary keys.
111111111-1235 • Consistent with the entity integrity rule.
111111111-1236
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Basic requirements of a relational database
– A foreign key must either be null or correspond to
the value of a primary key in another table.
• This rule is referred to as the referential integrity rule.
• The rule is necessary because foreign keys are used to
link rows in one table to rows in another table.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS

Student ID Last Name First Name Phone No. Advisor No.

333-33-3333 Simpson Alice 333-3333 1418
111-11-1111 Sanders Ned 444-4444 1418
123-45-6789 Moore Artie 555-5555 1503

ADVISORS
Advisor No. Last Name First Name Office No.
1418 Howard Glen 420
1419 Melton Amy 316
1503 Zhang Xi 202
1506 Radowski J.D. 203

Advisor No. is a foreign key in the STUDENTS table. Every inci-

dent of Advisor No. in the STUDENTS table either matches an
instance of the primary key in the ADVISORS table or is null.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Basic requirements of a relational database
– All non-key attributes in a table should describe a
characteristic of the object identified by the pri-
mary key.
• Could nationality be a non-key attribute in the student
table?
• Could advisor’s nationality be a non-key attribute in
the student table?

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• The preceding four constraints produce a well-struc-
tured (normalized) database in which:
– Data are consistent.
– Redundancy is minimized and controlled.
• In a normalized database, attributes appear multiple
times only when they function as foreign keys.
• The referential integrity rule ensures there will be no
update anomaly problem with foreign keys.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• An important feature is that data about various things of in-
terest (entities) are stored in separate tables.
– Makes it easier to add new data to the system.
• You add a new student by adding a row to the student table.
• You add a new course by adding a row to the course table.
• Means you can add a student even if he hasn’t signed up for
any courses.
• And you can add a class even if no students are yet enrolled
in it.
– Makes it easy to avoid the insert anomaly.
• Space is also used more efficiently than in the other schemes.
There should be no blank rows or attributes.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 • Add a stu-
STUDENTS
dent here.
Last First Phone
• Leaves no
Student ID Name Name No.
333-33-3333 Simpson Alice 333-3333 blank spa-
111-11-1111 Sanders Ned 444-4444 ces.
123-45-6789 Moore Artie 555-5555

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30
STUDENT x COURSE
• Add a course here.
SCID
• Leaves no blank spaces.
333333333-1234
333333333-1236
111111111-1235 • When a particular student enrolls for a
111111111-1236 particular course, add that info here.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Deletion of a class for a student would cause
the elimination of one record in the student x
class table.
– The student still exists in the student table.
– The class still exists in the class table.
– Avoids the delete anomaly.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 STUDENTS
Last First Phone • Ned still
Student ID Name Name No. exists in
333-33-3333 Simpson Alice 333-3333 the stu-
111-11-1111 Sanders Ned 444-4444 dent table.
123-45-6789 Moore Artie 555-5555

COURSES
Course ID Course Section Day Time
1234 ACCT-3603 1 MWF 8:30
1235 ACCT-3603 2 TR 9:30
1236 MGMT-2103 1 MW 8:30
STUDENT x COURSE
• Even if Ned was the only student in
SCID
the class, ACCT-3603 still exists in
333333333-1234
the course table.
333333333-1236
111111111-1235 • If Ned Sanders drops ACCT-3603, re-
111111111-1236 move Ned’s class from this table.
© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• There are two basic ways to design well-struc-
tured relational databases.
– Normalization
– Semantic data modeling

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Normalization
– Starts with the assumption that everything is ini-
tially stored in one large table.
– A set of rules is followed to decompose that initial
table into a set of normalized tables.
– Objective is to produce a set of tables in third-
normal form (3NF) because such tables are free of
update, insert, and delete anomalies.
– Approach is beyond the scope of this book but can
be found in any database textbook.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Semantic data modeling:
– Database designer uses knowledge about how
business processes typically work and the infor-
mation needs associated with transaction process-
ing to draw a graphical picture of what should be
included in the database.
– The resulting graphic is used to create a set of re-
lational tables that are in 3NF.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Advantages over simply following normaliza-
tion rules:
– Semantic data modeling uses the designer’s
knowledge about business processes and prac-
tices; it therefore facilitates efficient design of
transaction processing databases.
– The resulting graphical model explicitly represents
information about the organization’s business pro-
cesses and policies and facilitates communication
with intended users.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 RELATIONAL DATABASES
• Creating relational database queries
– Databases store data for people and organizations.
– To retrieve the data, you query the database and
its tables.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS AND THE FUTURE OF AC-
COUNTING
• Database systems may profoundly affect the
fundamental nature of accounting:
– May lead to abandonment of double-entry ac-
counting, because the redundancy of the double
entry is not necessary in computer data process-
ing.
– May also alter the nature of external reporting.
• EXAMPLE: External users could have access to the
company’s database and manipulate the data to meet
their own reporting needs.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS AND THE FUTURE OF AC-
COUNTING
• The use of accounting information in decision
making will be enhanced by:
– Powerful querying capabilities that accompany
database packages.
– The ability to accommodate multiple views of the
same underlying phenomenon.
– The ability to integrate financial and operational
data.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 DATABASE SYSTEMS AND THE FUTURE OF AC-
COUNTING
• Accountants must become knowledgeable
about databases so they can participate in de-
veloping the AIS of the future.
• They must help ensure that adequate controls
are included to safeguard the data and assure
its reliability.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart
 SUMMARY
• You’ve learned how databases differ from file-based legacy
systems.
• You’ve learned why databases are important and what advan-
tages they offer.
• You’ve learned how the logical and physical views of a data-
base differ.
• You’ve learned about fundamental concepts of database sys-
tems such as DBMS, schemas, the data dictionary, and DBMS
languages.
• You’ve learned what a relational database is and how it orga-
nizes data.
• You’ve learned how tables are structured to properly store
data in a relational database.

© 2008 Prentice Hall Business Publishing Accounting Information Systems, 11/e Romney/Steinbart