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

File

Record

Data Element

Data-sets (or Tables)

Record

Data Element

Data-base Files Data-bases

Figure 4-1

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

Field 1 Field 2 Field 3

Field 1 Field 2 Field 3

Records { File

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., customer-account 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.

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 - I

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 File-

Oriented 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 Data-

Base 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 Entity-

Relationship 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 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 file-oriented 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

Physical DFD

No lower levels

Level 2 diagrams(s), etc.

Level 1 diagram(s)

Level-0 logical DFD

Lower levels possible

Context Diagram

A Context Diagram

Customer

Cash

Receipts

Process

Bank

Payment

Deposit Dataflows

(Interfaces)

Process bubble

}Boundary (border between a

system and its environment)

Relevant Environment

comprised of External Entities

This is a flow connecting a system

with its environment

A Physical DFD

Customer Sales

Clerk

1.0

Book-

Keeper

3.0

Cashier

2.0

Bank Blue sales book

Cash Order & register tape

Verified register tape Deposit slip

& cash Sales information

Form 66W

1. Bubbles are labeled

with nouns

2. Data flows & files have

physical descriptions

A Logical DFD

Customer

1.0

Receive

Payment

2.0 Compare Cash &

Tape

4.0

Record

Sale

3.0

Prepare

Deposit

Bank Sales Journal

Payment Receipts & receipts summary

Sales record

Verified receipts summary

Sales data

Verified receipts

Deposit

1) Bubbles are labeled with

verbs that describe the activity

taking place

2) Data flows & files have logical

descriptions

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.

Accounting Information Systems:

Essential Concepts and Applications

Fourth Edition by Wilkinson, Cerullo,

Raval, and Wong-On-Wing