Transcript Accounting Information Systems: Essential Concepts

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 Bhattacharya, Ph.D.
Florida Atlantic University
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 firm’s 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
File
Record
Data Element
Figure 4-1
Data-base
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., end-of-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 user’s
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
item’s 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, objectoriented)
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 other’s
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 Data-Flow
Diagrams
The Hierarchy of Data Flow Diagrams
Context Diagram
Physical DFD
No lower levels
Level-0 logical DFD
Lower levels possible
Level 1 diagram(s)
Level 2 diagrams(s), etc.
A Context Diagram
Process bubble
Customer
Payment
Dataflows
(Interfaces)
This is a flow connecting a system
with its environment
Relevant Environment
comprised of External Entities
Cash
(border between a
Receipts }Boundary
system and its environment)
Process
Deposit
Bank
A Physical DFD
Customer
Cash
Sales
Clerk
1.0
Form 66W
Sales
information
BookKeeper
3.0
1. Bubbles are labeled
with nouns
2. Data flows & files have
physical descriptions
Order &
register
tape
Cashier
2.0
Verified
register tape
Deposit slip
& cash
Blue sales book
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
Verified receipts
4.0
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.