Download Data Entities

Accounting Information Systems
Chapter 4: Data Management
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
1
Data Models
Data-base
Files
Data bases
-
File
Record
Data Element
Data-sets (or Tables)
Record
Data Element
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
{
File
Field 1 Field 2 Field 3 Records
Field 1 Field 2 Field 3
2
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)
3
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.
4
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
5
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
6
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
7
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
8
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
9
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
10
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.
11
A Context Diagram
Process bubble
Relevant Environment
comprised of External Entities
Customer
Payment
Cash
}Boundary (border between a
Receipts system
and its environment)
Process
Dataflows
(Interfaces)
Deposit
Bank
This is a flow connecting a system
with its environment
A Physical DFD
Customer
Sales
Clerk
1.0
Cash
Order &
register
tape
Form 66W
1. Bubbles are labeled
with nouns
2. Data flows & files have
physical descriptions
Cashier
2.0
Verified
Sales
information
Book- register tape
Keeper
3.0
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
12
Thanks.
13