Chapter 5 – Database

Management Systems

Accounting Information Systems 7e

Ulric J. Gelinas and Richard Dull

Copyright © 2008 Thomson Southwestern, a part of The Thomson Corporation. Thomson, the Star logo, and
South-Western are trademarks used herein under license.

1
 Learning Objectives
• Describe the limitations of traditional application
approaches to managing data
• Analyze the advantages gained by using the database
approach to managing data
• Create normalized tables in a relational database
• Know how entity relationship diagrams are used in
database design and implementation
• Explain the importance of advanced database
applications in decision support and knowledge
management
 Introduction to Databases
• The enterprise database is at the heart of Accounting
Information Systems
• The chapter discusses the major types of databases that
are available and how organizations undertake database
design for accounting information systems.
• Larger organizations store information in data warehouses
in ways that let managers analyze it to gain important
insights.
• Many companies combine their data resources with
decision support systems, executive information systems,
group decision systems, and other advanced technology-
based systems to improve decision making and operations.

3
 Two Approaches To Business Event
Processing
Applications Approach
• Concentrates on the process being
performed
• Data support the role of the programs
that run in each application system
• Each application collects and
manages its own data in separate,
distinguishable files
• Data redundancy can cause
inconsistencies among the same data
in different files.
• This increases storage costs because
the system must store and maintain
multiple versions of the same data in
different files.
• Data residing in separate files are not
shareable among applications.
• Redundant data stored in multiple files
can become inconsistent when
information is updated in one file and
not in other files
Database Approach
• Facts about events are stored in
relational database tables instead of
separate files
• This solves many of the problems
caused by data redundancy.
• The use of databases has improved the
efficiency of processing business event
data by eliminating data redundancies
and improving data integrity.
• Makes it possible for the creation of
integrated business information
systems that include data about all of a
company’s operations in one massive
collection of relational tables
• Multiple users from throughout the
organization can view and aggregate
event data in a manner most conducive
to their needs.
4
Two Approaches To Event Processing

5
Record Layouts under the Applications
Approach to Business Event
Processing

6
 Problems with Applications
Approach
• Data redundancy—files stored may
include redundant information
increasing storage requirements and
risk of inconsistency
• Data in files is not shareable across
applications because applications
depend on a fixed record layout in data
files
7
 Record Layout – Applications
Approach
• Each application stores all the data
required for analysis
• Shows many redundancies across
applications/files
• Data lacks integrity when the data
stored by one application is inconsistent
with data stored by another application

8
 Database Management
Systems
• DBM is a set of integrated programs designed to simplify
the tasks of creating, accessing, and managing data.
• DBM systems integrate a collection of files that are
independent of application programs and are available to
satisfy a number of different processing needs.
• The database contains data related to all the
organization’s applications in one place
• The DBM system supports normal data processing needs
and enhances the organization’s management activities
by providing data useful to managers.
• The data is independent of the application that created
the data (i.e., can be changed/used by other applications)
• We will use the term enterprise database synonymously
with database management system or DBMS.

9
 Relational Database Tables
• The next slide shows a database with data stored in a
relational structure
• This is most common type of database structure used in
businesses today.
• The data from three files are now stored in four tables:
– CUSTOMERS (instead of the customer master data file)
– INVENTORY_ITEMS (instead of the inventory master data file)
– SALES_ORDERS
– SALES_LINES (the two tables replace the sales order master data file)
• The logical database view is how the data appear to the user
to be stored.
– This view represents the structure that the user must use to extract
data from the database.

10
Relational
Database
Tables

11
Formulating a query in SQL
• Users can access the data in the
tables by:
1. Formulating a query.
2. Preparing a report using a report
writer.
3. Including a request for data within an
application program.

12
 SQL – Query Example
A query that uses the SQL SELECT command can return to the
customers assigned to salesperson Garcia.
• SELECT Cust_Code Cust_Name Cust_City
• FROM CUSTOMERS
• WHERE Salesperson = ‘Garcia’
You can see that there are two customers, STANS and WHEEL,
who are assigned to salesperson Garcia.

13
 Disadvantages of DBMS
1. Expensive to implement
2. If the DBMS fails, all of the organization’s information processing halts.
3. Database recovery and contingency planning are more important than
in the applications approach
4. When more than one user attempts to access data at the same time,
the database can face “contention” or “concurrency” problems.
– Record locking can help mitigate such problems but are beyond the scope
of this course
5. Territorial disputes over who “owns” the data, such as who is
responsible for data maintenance (additions/deletions/changes) to
customer data.
– Sales department might think it should own those data
– Credit department or AR might argue with that contention.
• To cope with these and other problems, most companies that have
adopted the database approach have found it necessary to create a
database administrator function

14
 Logical Database Models
• Hierarchical databases
– Child records may only have one parent
record
– Cannot sustain complex data structures
• Network databases
– Overcame problems of hierarchical
– Child record can have more than one parent
– But eclipsed by relational databases

15
 Logical Database Models
• Relational databases
– Data logically organized into two dimensional tables
– Vast improvement over hierarchical or network database
models
– Able to handle complex queries
– Allows only text and numerical data to be stored
– Does not allow the inclusion of complex object types such as
graphics, audio, video, or geographic information.
• Object oriented databases
– Overcomes the limitations of relational databases.
– Allow the storage of complex objects, e.g., video clips
– An object can store attributes and instructions for actions
that can be performed on the object or its attributes.
16
Elements/Parts of a Relational
Database
• Tables—place to store data
• Queries—retrieve data
• Forms—on-screen presentations of
data collected by queries
• Reports—printed lists and data
summaries collected by queries

17
 Comparison of Database and
Spreadsheet
• Database • Spreadsheet
– Cell can contain only – Cell can contain text,
one data type numbers, formula or
– Each row in the graphic
database must be – Rows need not be
unique and include a unique
unique identifier – Columns often store
(primary key or dissimilar attributes
composite key)
– Columns store one
attribute

18
Classifying and Coding Data
• Types of coding
1. Sequential
2. Block
3. Significant digit
4. Hierarchical
5. Mnemonic
• Discussed in the following slides

19
 Sequential Coding
• Assigns numbers in chronological sequence
• Limited flexibility
– Additions can be made only at the end of a sequence
– Deletions result in unused numbers unless the numbers are
recycled
– Codes tell nothing about the object’s attributes
• Examples include
– Student ID numbers
– “Wait” ticket at Post Office
• Example based on employee ID codes:
001 - 1st hired
002 - 2nd hired

20
 Block Coding
• Groups of numbers are dedicated to particular
characteristics of the objects being identified
• Universal product code example:
73805 80248
Mfg Product
Code Code

• Employee ID code example:

001-100 fabrication department
101-200 assembly department
 Within the department block, codes are assigned to
individual employees
21
 Significant Digit Coding
• Assigns meanings to specific digits
• Significant digit coding works well for
inventory items
• Also works well for employee ID codes
• The following slide shows examples
using inventory and employee ID codes

22
 Significant Digit Coding
Example based on an Inventory item

16 2 17 4389
Product Part or Warehouse Unique item
group subassembly identifier

Example based on employee ID codes

2 0 4 623
Work Exempt or Pay rate Unique
center nonexempt code employee
identifier
23
 Hierarchical Data Coding
• Like significant digit codes, hierarchical codes
also attach specific meaning to particular
character positions
• Items are ordered in descending order where
each successive rank order is a subset of the
rank above it
• Reading from left to right in a hierarchical
code, each digit is a subcategory of the digit
to its left
• A 5 digit postal code is an example of
hierarchical data coding

24
 Hierarchical Data Coding
Example based on Postal zip code
0 18 90
Section of Region within Locality (town
country section within region)

Example based on employee ID codes

01 3 9 623
Company Plant Department Unique
division employer ID
25
 Mnemonic Data Coding
College course numbering:
AC340 - Accounting Information Systems

EN101 - English Composition

Example Based on Employee ID Codes:

F M C 623

Female Married Caucasian Unique

employee ID
26
 Database Normalization
• Rules for database normalization based on set
theory—failure to normalize results in
anomalies/errors that otherwise might occur
when adding, changing, or deleting data stored in
the database
– There are 6 normal forms, but the first 3 are generally
considered sufficient
– To function properly, a database should obtain the 3rd
normal form
– Normal forms are inclusive, which means that each
higher normal form includes all lower normal forms.
– That is, a table in 3NF is in 1NF and in 2NF

27
 Unnormalized
Table/Relation
• Table contains repeating groups
– Sales order line items repeat

28
 Functional Dependence and Primary Keys
• An attribute (a column in a table) is functionally
dependent on a second attribute (or a collection of other
attributes), if a value for the first attribute determines a
single value for the second attribute at any time.
– If functional dependence exists, one would say that “the first
attribute determines the second attribute.”
• A primary key contains a value that uniquely identifies a
specific row in a table
– A candidate attribute (a column or collection of columns) in a table
is that table’s primary key if:
• 1. All attributes in the table are functionally dependent on the
candidate attribute.
• 2. No collection of other columns in the table, taken together,
has the first property.

29
 Table/Relation in First Normal
• A table is in first normal form Form
(1NF) if it doesn’t contain repeating groups.
• Rows are now key dependent, uniquely identified by a primary key
• The primary key for the table is a combination of SO_Number and
Item_Number.
• A primary key formed by the combination of two or more columns is
called a composite primary key.

30
 Problems with first normal form
(1NF)
• Includes the following functional dependencies:
1. Item_Number functionally determines Item_Name.
Therefore, item names, such as “26 in. Bicycle,” are
repeated several times. This data redundancy should
be eliminated.
2. Cust_Code functionally determines Cust_Name.
3. The combination of SO_Number and Item_Number
together functionally determine Item_Name,
Qty_Ordered, Cust_Code, and Cust_Name.
• These functional dependencies cause several
problems called update anomalies

31
 Update Anomalies
1. Update. Updating an item name requires updating multiple records.
Each row in which any item, such as the 26, in Bicycle, appears
must be changed if the description is updated.
2. Inconsistent data. An item can have several different names in
different rows of the table.
3. Additions. Adding a new inventory item to the database is
impossible because a sales order number is required before an
item can be inventoried. This is an impossible requirement for a
business, which wants information about inventory in its database
before accepting sales orders.
4. Deletions. Deleting an inventory item from the database (by
deleting its row) could cause the table to lose sales order
information.
• Because we have an attribute, Item_Name that is dependent on a
portion of the primary key, Item_Number, not on the entire key. We
have a problem called a partial dependency.
• Second normal form eliminates partial dependencies

32
 Two steps to get from 1NF to 2NF
1. Create a new table for each subset of the table that is
partially dependent on a part of the composite primary key
– One table for SO_Number and another for Item_Number
– We now have two new tables, one with SO_Number as its primary
key (a SALES_ORDERS table) and another with Item_Number as
its primary key (an INVENTORY_ITEMS table).
2. Place each of the non-key attributes that are dependent on
a part of the composite primary key into the table that now
has a primary key that is the field on which the non-key
attribute is partially dependent.
– For example, the Item_Name field is partially dependent on the
Item_Number field portion of the composite primary key, so it
would be moved into the new INVENTORY_ITEMS table.
– This transformation yields the three tables shown in the next slide

33
 Second Normal Form
• To obtain second normal form, partial dependencies must be
eliminated by creating new tables

34
 Third Normal Form
• To obtain the 3rd normal form, transitive
dependencies must be eliminated
– A transitive dependency exists when a non-key
field depends on another non-key field which in
turn depends on the key (C depends on B which
depends on A)
– E.g., Customer name depends on customer code
which depends on sales order number
– A table is in third normal form if it is in second
normal form and transitive dependencies are
eliminated

35
 Transitive Dependencies
• Some customer names—are repeated several times. This
transitive dependency causes update anomalies:
1. Update. Changing any customer name could require multiple
changes. The user would have to change each row in which
any customer appears. Changing Wheelaway’s name would
require changing three rows in the SALES_ORDERS table.
2. Inconsistent data. Nothing in this design prevents users from
entering several different names for a single customer.
3. Additions. A new customer can’t be added unless the
customer already has a sales order. Internal control dictates
that an authorized customer should exist before a sales order
can be created for that customer.
4. Deletions. If a user deletes a sales order, the name of a
customer might be erased from the database.
36
Third Normal Form

Customer information
moved to customer table

37
 Entity-Relationship Models
(REA)
• Popular data modeling approach
• Entities and relationships are
determined through systems analysis
• Common accounting entities include:
– Resources—thing the company owns
– Events—occurrences related to resources
– Agents—people or organizations that
participate in events

38
Entity-relationship diagram

39
 REA
• Identify Entities
– Categories of entities
• Resources
• Events
• Agents
• Locations
• Identify relationships that connect the entities
– shown in the E-R diagram as connecting lines with
diamonds that describe the nature of the relationship.
• Create tables and relationships
– the analyst continues the data modeling process
transforming the data model into a logical design for the
database.

40
 Characteristics of
Relationships
• Relationships between entities are
determined by analyzing the system
• The cardinality is the degree to which
each entity participates in the
relationship, e.g., 1:N, pronounced one-
to-many.

41
 Create the E-R Diagram in 5
Steps
• Create a logical model of the database
1. Create tables for each entity
2. Determine primary keys
3. Determine attributes
4. Implement relationships through primary
keys and relationships
5. Define relationship tables
• Implement the database using an
available DBMS
42
Relationa
l
Database

43
 Specify Logical DB Design
• Select Logical DB model
• Transform Data Model using a Logical
DB model
• Select DBMS
• Implement DBMS

44
 Decision Support Systems:
DSS
• Information systems that assist managers
with unstructured decisions by retrieving data
and generating information
• Possesses interactive capabilities
• Can answer ad-hoc inquires
• Provide data modeling facilities such as
spreadsheets
• Supports non-recurring, relatively
unstructured decision making

45
 Executive information system:
ESS
• Information systems often
considered a subset of DSS, that
combine information from the
organization and the environment
• Organize and analyze the information
• In a form suitable for managers to
make decisions

46
 Group Support Systems:
GSS
• Computer based systems that support
collaborative intellectual work such as
– Idea generation
– Elaboration
– Analysis
– Synthesis
– Decision making
• GSS use technology to solve the time and place
dimension problems associated with group work
• Also known as GDSS or Group Decision Support
Systems

47
 Expert Systems: ES
• An information system that emulates
the problem solving techniques of
human experts

48