Accounting Information Systems:

Essential Concepts and Applications

Fourth Edition by Wilkinson, Cerullo, Raval,

and Wong-On-Wing

Chapter 4: Data Management

Slides Authored by Somnath

Florida Atlantic University

Bhattacharya, Ph.D.

Data
Data may be defined broadly
to include two interrelated components:
Data Models that provide structure to data
File Orientation
Data-base Orientation

Data values

A firms data resource involves four major

functions:
Record & Repository Creation
Repository Maintenance through additions and
updates
Data Retrieval
Data Archival and Removal

Entities
An Entity is an object, person, or event about which a
firm wants to collect and maintain data
Characteristics of Entities are Attributes
Each attribute stored in the system is a Data Element
There is usually a one-to-one correspondence between attributes
and data elements
A broadly defined attribute may have several specific attributes
and therefore data elements. e.g., Shipping Address

Street Address
City
State
Zip Code
Country

Data Models
Files

Data-base

File
Record
Data Element

Figure 4-1

Data bases
-

Data-sets (or
Tables)
Record
Data Element

Data Elements
Every recorded attribute of an entity is a data
element
Field Length: This is the number of contiguous
positions required to store a data element
Data Type:

Character
Numeric
Date
Raw

Data Value

Some Specifics
Field 1 Field 2 Field 3

File

Field 1 Field 2 Field 3 Records

Field 1 Field 2 Field 3

File Classifications (Master

Files)
Master files: These contain (semi) permanent
data (records) pertaining to entities (people,
places, and things). Accounting related examples
include:
General and Subsidiary ledgers

General ledger master file

Customer/Accounts Receivable master file
Vendor/Accounts Payable master file
Inventory master file
Employee/Payroll master file
Open WIP master file
Standard cost master file

File Classification
(Transaction Files - I)
Transaction files: These contain records
pertaining to events currently being
processed, such as sales, receipts of goods,
etc.
Transaction files capture detailed transaction
data. They are counterparts to general and
special journals in manual systems
Transaction data are periodically posted to
related master file(s) and are then either
purged or archived

File Classification
(Transaction Files - II)
Accounting related transaction files include:
General/Special journal file (General ledger)
Sales/Cash receipts file (Accounts receivable)
Receiving/Purchases file, Cash disbursements
file (Inventory, Accounts payable)
Inventory issuance file/shipment file/sales
file/adjustments file (Inventory)
Payroll/Cash disbursements (Payroll)

Other File Classifications - I

Reference files: These contain tables or lists of data needed
for making calculations or for checking the accuracy of
input data. e.g., product price tables, customer lists, etc.
History files: These are also called archive files since they
contain records pertaining to completed transactions such
as past sales
Open files: These record incomplete transactions. Whereas
transaction files are purged or archived at the end of a
given period, open files remain indefinitely open. Only
individual records from Open files get purged as the
transaction actually occurs or does not. e.g., Open sales
order file
Sales transaction file

Other File Classifications - II

Report files: These are derived from records
within master or transaction files. e.g., data
may be periodically extracted from the
Accounts Receivable master file to construct
an aging schedule
Backup file: This is a copy of a current file
generated so that the original file can be
recreated from it
Suspense file: This is a collection of those
records of a transaction file that appear to
contain erroneous or questionable data

Record-Key
Record keys: These are data elements within
records that serve as sort keys. e.g., customeraccount number
Two types of keys often used in master and
transaction file records are a primary key and one
or more secondary keys
A Primary key (also called a record key) is the attribute
that uniquely identifies a specific record. They are
usually of numeric or alphanumeric modes, e.g.,
customer number
A Secondary key is an attribute other than the primary
key and represents an alternative way to sort or access
records in a file, e.g., customer last name

Flags
Flags that are symbols or characters
used for control purposes, e.g., endof-batch flag.
Flags are not visible to the end-user.
It is a system-managed field that is
transparent to the user.

Logical View Versus Physical

Storage of Records - I
File structure pertains either to logical file
structures or to physical file structures
The logical file structure defines the users
perspective of a file. For example, each logical
record in a computerized customer master file
pertains to a particular customer
Data contained in logical records must necessarily
be physically mapped onto storage media
File organization refers to the methods by which
data in logical records are stored on physical
storage media

Logical View Versus Physical

Storage of Records - II
Files stored on physical media are seen as a
collection of physical records
Sometimes there may be a one-to-one
correspondence between logical and physical
records (unusual)
Sometimes a logical record may occupy more
than one physical record - typically on magnetic
disks
Sometimes two or more logical records may
occupy one physical record - typically on
magnetic tape

Design Considerations for

Records & Files - I
Managing files and records requires
the answering of questions such as:
How should the records be structured
What type of file organization and
access method (e.g., sequential,
indexed sequential, random) should be
used
How long should records be retained

Design Considerations for

Records & Files - II
The answers to the above questions
also depend in part on the requirements
of the application being designed
These requirements, in turn, are affected
by issues such as:
storage requirements
efficiency in file maintenance
accessibility of stored data

Establishing Record
Structures - I
The structure of a record is defined by its:

content
arrangement
modes of data fields
lengths of data fields
keys

Generally the primary keys are placed to

occupy the first fields of the records
Generally balance amounts or amounts of
transactions are placed in the last fields

Establishing Record
Structures - II
Transaction records are usually arranged
somewhat in accordance with the placement of
the elements on the source documents (e.g.,
sales invoices)
The modes and lengths of the fields depend on
the nature of data placed therein, while the
keys are expressed as codes
An important design issue is the extent to
which records should be consolidated. This
issue is especially important in relational
database normalizations and table designs

File-Oriented Approach
to Data Storage
In the file-oriented approach to data
storage computer applications
maintain their own set of files
This traditional approach focuses
on individual applications,
each
of which have a
limited number
of users,
who view the data as
being owned by them

Deficiencies of the FileOriented Approach

Files and data elements used in more than one application
must be duplicated, which results in data redundancy
As a result of redundancy, the characteristics of data
elements and their values are likely to be inconsistent
Outputs usually consist of preprogrammed reports instead
of ad-hoc queries provided upon request. This results in
inaccessibility of data
Changes to current file-oriented applications cannot be
made easily, nor can new developments be quickly
realized, which results in inflexibility
It is difficult to represent complex objects using file
processing systems.

The Database Approach

to Data Storage
A database is a set of computer files that
minimizes data redundancy and is accessed by one
or more application programs for data processing
The database approach to data storage applies
whenever a database is established to serve two
or more applications, organizational units, or types
of users
A database management system (DBMS) is a
computer program that enables users to create,
modify, and utilize database information efficiently

Documenting Data in DataBase Systems

The Conceptual Data Model is the
logical grouping of data on entities
Two common Conceptual Data
Modeling techniques are:
The Data Dictionary
Entity-Relationship Diagrams

Data Dictionary
A data dictionary is a computer file that maintains
descriptive information about the items in a
database
Each computer record of the data dictionary
contains information about a single data item used
in an AIS
Examples of information that might be stored in a
data dictionary are source document(s) used to create
the data item, programs that update the data item
and classification information about the items length
and data type

Data Modeling Via the EntityRelationship Diagram - I

The Entity-Relationship Model is a high level
conceptual data model that specifies the
data base structure independent of any
specific DBMS (hierarchical, network,
relational, object-oriented)
It is only after completing the E-R model that
a particular DBMS is selected. Then the high
level model is mapped into schemas using
the DDL provided by a given DBMS

Entity-Relationship Diagram - II

In order to arrive at a specific E-R model, one must select the entities
first, and then define the relationship between them (cardinalities:
one-to-one, one-to-many, many-to-many)
Rectangle=Entity
Diamond=Relationship
Line=Links:

attribute to entity
entity to relationship
attribute to relationship

Sometimes we use ellipses to represent specific attributes of

entities, e.g., customer_#, student_last_name, etc.
To go from the ER model to a specific conceptual data model
(hierarchical, network, relational, object-oriented), we typically
assign attributes to the entities and relationships so as to obtain
fully specified pointers (hierarchical & network), and normalized
tables (relational)

Advantages of the
Database Approach
Efficient use of computerized storage space
Each subsystem has access to the others
information
All application programs utilize the same
computer file, thereby simplifying
operations
Fewer backup files for security purposes
Relieves some users from data-gathering
responsibilities in situations where these
users previously gathered their own
data

Disadvantages of the
Database Approach
Databases can be expensive to implement
because of hardware and software costs.
Additional software, storage, and network
resources must be used
A DBMS can only run in certain operating
environments,which makes some unsuitable
for certain alternate
hardware/operating system configurations
Because it is radically different from the fileoriented approach, the database approach may
cause initial inertia, or complications and
resistance

Data-Flow Diagrams
A data-flow diagram shows the
physical and logical flows of data
through a transaction processing system
without regard to the time period when
each occurs
Physical devices that transform data are
not used in the logical diagrams
Because of the simplified focus, only
four symbols are needed

Symbols used in Data Flow

Diagrams
A square represents an external data source or
data destination. The latter is also called a sink
A circle (or bubble) indicates an entity or a process
that changes or transforms data
A bubble can either be an internal entity in a physical DFD or a
process in a logical DFD

An open-ended rectangle or a set of parallel lines

represents a store or repository of data
The file may represent a view or a portion of a larger entity-wide
data base

A line with an arrow indicates the

direction of the flow of data

Physical DFDs
A Physical DFD documents the physical
structure of an existing system. It answers
questions such as Where an entity works,
How an entity works, the work is done by Whom,
etc.
Given the very physical focus of a
physical DFD, it changes whenever the entities,
technology used to implement the system, etc.
changes
Physical DFDs have no lower levels
This limitation makes physical DFDs
cumbersome to work with, and usually of
limited value

Logical DFDs - I
Logical Data flow diagrams are
usually drawn in levels that include
increasing amounts of detail
A top level (or high-level) DFD that provides
an overall picture of an application or
system is called a context diagram
A context diagram is then decomposed,
or broken down, into successively lower
levels of detail

Logical DFDs - II
Logical Data flow diagrams
document the processes in an existing
or proposed system (What tasks)
Because the logic of a system changes
infrequently, relative to its physical nature,
a logical DFD will remain relatively
constant over time
Logical Data flow diagrams typically have
levels below the level-0 diagram

The Hierarchy of DataFlow Diagrams

T h e H ie r a r c h y o f D a t a F lo w D ia g r a m s
C o n t e x t D ia g r a m
P h y s ic a l D F D
N o lo w e r le v e ls

L e v e l- 0 lo g ic a l D F D
L o w e r le v e ls p o s s ib le
L e v e l 1 d ia g r a m ( s )
L e v e l 2 d ia g r a m s ( s ) , e t c .

A Context Diagram
Process bubble
Customer
Payment

Dataflows
(Interfaces)
This is a flow connecting a system
with its environment

Relevant Environment
comprised of External
Cash Entities
(border between a
Receipts }Boundary
system and its environment)
Process
Deposit

Bank

A Physical DFD

Customer

Cash

Sales
Clerk
1.0

1. Bubbles are labeled

with nouns
2. Data flows & files have
physical descriptions

Order &
register
tape
Cashier

Form 66W
Sales
information

Blue sales book

BookKeeper
3.0

2.0
Verified
register tape

Deposit slip
& cash

Bank

A Logical DFD

1.0
Customer Payment Receive
Payment

1) Bubbles are labeled with

verbs that describe the activity
taking place
2) Data flows & files have logical
Receipts &
descriptions
receipts summary
Verified receipts

Sales record

Sales data

Sales Journal

2.0
Compare
Cash &
Tape

4.0
Verified receipts
Record summary
Sale

3.0
Prepare
Deposit
Deposit

Bank

Accounting Information Systems:

Essential Concepts and Applications
Fourth Edition by Wilkinson, Cerullo,
Raval, and Wong-On-Wing

Copyright 2000 John Wiley & Sons, Inc. All rights reserved.
Reproduction or translation of this work beyond that permitted in
Section 117 of the 1976 United States Copyright Act without the express
written permission of the copyright owner is unlawful. Request for
further information should be addressed to the Permissions Department,
John Wiley & Sons, Inc. The purchaser may make back-up copies for
his/her own use only and not for distribution or resale. The publisher
assumes no responsibility for errors, omissions, or damages, caused by
the use of these programs or from the use of the information contained
herein.