Introduction to Transaction Processing

PAPER
Prepared to meet the task
Accounting Information System courses supervised by Mr. Eko Ganis

BY
Nadia Dayanti (0910233046)
Satrio Mangkunegoro (0910233138 )

UNIVERSITY BRAWIJAYA OF MALANG

FACULTY OF ECONOMICS
INTERNATIONAL ACCOUNTING DEPARTMENT
March 2011
Introduction to Transaction Processing

ABSTRACT

Transaction processing systems have been

available since the 1970s, and nearly all businesses use
them. The advent of the Internet has seen a boom in
transaction processing systems and software. Over the
years, the cost of buying and implementing the
necessary software has dropped so much that most
businesses can apply it profitably. Banking from home,
booking a holiday on the net, shopping and working
from home are all now readily available and less time
consuming. Transaction processing is a computer-based
group of logical operations. In order for transaction
processing to work, all the operations must succeed or
fail as a group. A simple example of transaction
processing is paying a utility bill from your bank
account. The process of paying a bill from your account
consists of debiting your account by say, 100 US
dollars (USD), and crediting your utility provider’s
account. Systems capable of transaction processing
must pass tests for atomicity, consistency, isolation and
durability, otherwise known as the ACID test.

Key word : Transaction, processing, system, account

Introduction to Transaction Processing

INTRODUCTION

Most of the events which occur in a business can be sorted into just a few
groups: acquisition of materials, labor, and capital assets and the subsequent
disbursement of payment; conversion of materials into goods and services using labor
and assets; and sales of goods and/or services and the subsequent receipt of payment.
Understanding what must happen in each of these cycles and what recordkeeping
must be done will greatly enhance your understanding of what must occur within an
accounting system.
The chapter opens with an overview of transaction processing. Although you are
familiar with the terms source documents, journals, and ledgers, you will find the
second part of the chapter enlightening. Because we need ways to represent (and
therefore visualize) accounting systems, this chapter presents some system
documentation techniques. The last section of the chapter introduces the basic ways
in which an information system can use computer technology.
The objectives of this chapter are:
1. To understand the broad objectives of transactions cycles;
2. To recognize the types of transactions processed by each of the three
transactioncycles;
3. To know the basic accounting records used in transaction processing systems;
4. To to understand the relationship between traditional accounting records and
their magnetic equivalents found in computer-based systems;
5. To be familiar with the documentation techniques used for representing
manual and computer-based systems; and
6. To understand the characteristic differences between batch and real-time
processing and the impact of these technologies on transaction processing.
CONTENTS

TRANSACTION PROCESSING
Financial transactions are dealt with by the transaction processing system
(TPS) which is organized to handle like transactions in a like manner.

A. Transaction Cycles
Three transaction cycles handle the three basic types of transactions: those
related to the acquisition of materials, labor, and capital assets and the subsequent
disbursement of payment (the expenditure cycle); the conversion of materials into
goods and services using labor and assets (the conversion cycle); and the sale of
goods and/or services and the subsequent receipt of payment (the revenue cycle).

B. The Expenditure C ycle

The start of business activity is reflected in the expenditure cycle S the acq
uisition of the inputs to production: materials, labor, and fixed assets. Since most
business transactions are conducted on a credit basis, your text distinguishes between
the physical part of the transaction and the financial part. T his is an artificial split
and is used for clarity only. Considerably more effort is required when transactions
are not conducted on a cash basis. Four subsystems make up the expenditure cycle:
1. Purchases/accounts payable involves the ordering of materials and recognizing the
related liability;
2. Cash disbursements handles the payment on those liabilities;
3. Payroll handles both tasks for the purchase of labor; and
4. Fixed assets deals with the acquisition, maintenance and disposal of property,
plant, and equipment.
C. The Conversion Cycle
Conversion implies changing the form of something to make it different. The
conversion cycle handles the activities which occur in a business to combine and
convert raw materials to produce a product.
There are two subsystems.
1. Production includes all of the activities related to the physical creation of the
product, including planning, scheduling, and controlling the product.
2. Cost accounting handles the flow of costs through the system, the financial effort.

D. The Revenue Cycle

Businesses exchange their goods and services with customers through the
revenue cycle. This may involve both cash sales and credit sales. As with the
expenditure cycle, physical and financial parts of the transaction must be recognized.
There are two fundamental subsystems.
1. Sales order processing involves order preparation, credit granting, shipping,
billing, and recording.
2. Cash receipts takes cash receipts all the way to the bank.

II. ACCOUNTING RECORD

A. Manual Systems
Manual accounting systems are paper based. All of the information entered
and organized in the system is written manually. We call the standard bookkeeping
system a double-entry system because of the way it works.
This part of the chapter presents good discussion and examples of these paper
records. For some of you this may be a review. If not, study it carefully.
1. Documents are paper forms used to collect information. There are several basic
types of documents.
a. Source documents capture the information needed by the system
b. Product documents are produced by the system
c. Turnaround documents start life as product documents and later turn around and
become source documents to another part of the same system. (Recall the part of your
credit card statement that you return with your payment.)
2. Journals are called “books of original entry” because a journal is the first place
that information is entered into the accounting system. T he term comes from the
Latin word for day. A journal is sometimes called a “day-book” to emphasize the fact
that it is a chronological list of events. All significant information about an economic
event, or transaction, appears together in one of the journals. There are several types.
a. Special journals are created to handle like transactions that occur in large numbers.
Work is reduced by entries taking only one line with columns for the normal accounts
used. Many organizations have sales, purchases, cash receipts, and cash
disbursements journals.
b. Registers are a subgroup of special journals that serve as logs of activities such as
payroll or receiving.
c. A general journal is used to initially record transactions for which there is no
special journal. These are typically nonrecurring or infrequent transactions.
As its name implies, it is general. Any number of accounts can be listed, one to a
line.

3. Ledgers serve as the filing/sorting mechanism of the system. Extracting

information from the journals would be very time consuming and probably very
inaccurate. The pieces of information in the parts of a journal entry are sorted, or
posted, to a second place that collects information about specific accounts. These
filing systems are the ledgers.
By using the ledger accounts to collect this information, a balance of an
account can be obtained without going through the entire journal. There are two basic
types of ledgers.
a. The general ledger collects information about the basic types of
accounts.
b. Subsidiary ledgers collect information about individual accounts of a similar type.
Each credit customer has an account in the accounts receivable subsidiary
ledger. The total of all customer accounts appears in the general
ledger in a control account. The control account and the subsidiary ledger must be
reconciled regularly.
This serves to double-check both the control account and the subledger.
B. The Audit Trail
The accounting records described previously provide an audit trail for tracing
transactions from source documents to the financial statements. Of the many
purposes of the audit trail, most important to accountants is the year-end audit. While
the study of financial auditing falls outside the scope of this text, the following
thumbnail sketch of the audit process will demonstrate the importance of the audit
trail.
The external auditor periodically evaluates the financial statements of publicly
held business organizations on behalf of its stockholders and other interested parties.
The auditor’s responsibility involves, in part, the review of selected accounts and
transactions to determine their validity, accuracy, and completeness. Let’s assume an
auditor wishes to verify the accuracy of a client’s accounts receivable (AR) as
published in its annual financial statements. The auditor can trace the AR figure on
the balance sheet to the general ledger AR control account. This balance can then be
reconciled with the total for the AR subsidiary ledger. Rather than examining every
transaction that affected the AR account, the auditor will use a sampling technique to
examine a representative subset of transactions. Following this approach, the auditor
can select a number of accounts from the AR subsidiary ledger and trace these back
to the sales journal. From the sales journal, the auditor can identify the specific source
documents that initiated the transactions and pull them from the files to verify their
validity and accuracy.
The audit of AR often includes a procedure called confirmation. This involves
contacting selected customers to determine if the transactions recorded in the
accounts actually took place and that customers agree with the recorded balance.
Information contained in source documents and subsidiary accounts enables the
auditor to identify and locate customers chosen for confirmation. The results from
reconciling the AR subsidiary ledger with the control account and from confirming
customers’ accounts help the auditor form an opinion about the accuracy of accounts
receivable as reported on the balance sheet. The auditor performs similar tests on all
of the client firm’s major accounts and transactions to arrive at an overall opinion
about the fair presentation of the financial statement. The audit trail plays an
important role in this process.
Because financial information
is communicated to interested parties
Audit Trail
outside the organization, it is
Source General Financial
J ournal
Document Ledger Statements important that such parties trust the
information that is reported. One
thing that creates confidence in
Financial General Source
J ournal
Statements Ledger Do cument financial reports, especially annual
financial statements, is the opinion of
Accountants should be able to trace in both directions.
Sampling and confirmation are two common techniques. an independent, unbiased
professional that the statements are,
indeed, a fair presentation of the performance and financial state of the firm. In order
to arrive at a judgment, an “audit” is conducted–an extensive examination of the
accounting system and the inform ation in it–to yield an audit opinion. This audit
opinion is not conferred casually. A great deal of work is done examining the
financial system. The ability to trace an item on a financial statement all the way back
to the original entry in a jo urnal and further, to the source document, is referred to as
the audit trail. This is assisted in manual systems by the information recorded in the
“Post. Ref.” columns of journals and registers. The existence of an audit trail in an
automated system should not be assumed. It must be designed into the
system.
C. Computer-Based Systems
In this part of the chapter you are introduced to some basic file types used in a
computer-based system. These types refer to the nature of the information in the file,
not to the physical form the file takes. Study the different types. Their meanings may
become clearer as you study the material.
1. master file, which contains account data (e.g., the general ledger)
2. transaction file, which contains data on transactions which will update the master
file (e.g., a sales journal)
3. reference file, (a price list)
4. archive file, the record of past transactions (e.g., prior payroll period).
represents the relationship between the magnetic files in an audit trail. Use the
narrative to improve your understand ing of the way in which information can be
traced.

III. DOCUMENTATION TECHNIQUE

Any individuals who need to know how a system functions can be helped to
visualize the operation, by what are called documentation techniques. Your book
describes five of these. We will have a lot of immediate use for the first three, less for
the latter two, although they are used extensively in business. Often, your accounting
courses do not give students a good feel for the movement of data in the system.

A. Data Flow Diagrams

a sample of a data flow diagram (DFD) created using the symbols . This type
of diagram is very simple. Only four symbols are used. Only the flow of data is
shown, not the movement of paper, not the organizational unit(s) involved, and not
how the data is processed. DFDs are very good as a starting point for understanding
inform ation movement. They will provide an overview of the procedures that occur
in each of the subsystems of the transaction cycles to be discussed in later chap ters.
B. Entity-Relationship Diagrams
The representation of entities (which can be resources, events, and agents as
introduced in Chapter 1's discussion of the REA model), and the relationships
between them, is very important. the symbol set used in entity
relationship diagrams (ERDs). This figure also serves as a sample ERD for a sales
example. Read this material carefully. Recognize that the numbers at the nds of the
connecting lines indicate the nature of the relationship, one-to-one, one-to-many, or
many-tomany. The examples given in the book are very clear. Study them well. ERDs
will be used extensively later in the bo ok.

C. Flowcharts
The remaining three document types are all forms of flowcharts. Three flowcharts are
presented here: document, system, and program. Document and system flowcharts
have several characteristics in common. They use standard symbols [although each
type has its own set], are divided vertically according to organizational unit [we will
see later that this helps verify separation of duties–a key control technique], and use
special connector symbols to jump between points on a single page and from page to
page. These are used to minimize the mess that can result if flowlines cross each
other.
• As the name implies, document flow charts show the flow of documents, or
paper, through the system or part. In the example, a flowchart of a sales order
processing system is created. One concept that is introduced here is that of batch
processing. When a business has large groups of similar transactions, processing
them in batches is more efficient and more controllable than handling the transactions
individually. Think of how most people do laundry.
• System flowcharts are used to show the relationships between parts of a
system, namely inputs, processes, and outputs. Although typically used for computer-
based systems, they can be used to represent manual systems also. Several of these
represent the storage medium involved. This section walks through the process of
describing symbolically what happens in the sales order department.
 • Each program shown in a system flowchart would be supported by a
program flowchart which shows the detail of processing.

IV. COMPUTER-BASED ACCOUNTING SYSTEMS

This last part of Chapter 2 introduces computer-based accounting systems,
beginning with the differences between the two basic types: batch systems and real-
time systems.
Batch processing permits the efficient management of a large volume of
transactions.A batch is a group of similar transactions (such as sales orders) that are
accumulated over time and then processed together. There are two general advantages
to batch processing. First, organizations improve efficiency by grouping together
large numbers of transactions into batches rather than processing each event
separately. Thus a business can achieve an efficient allocation of its processing
resources by employing specialized, cost-effective procedures to deal with these
batches. Batch processing is an economical method of high-volume transaction
processing.
Second, batch processing provides control over the transaction process. The
accuracy of the process can be established by periodically reconciling the batch
against the control figure. For example, assume that the total value of a batch of sales
orders is $100,000. This number can be recorded when the batch is first assembled
and then recalculated at various points during its processing. If an error occurs during
processing (for example, a sales order is lost), then the recalculated batch total will
not equal the original batch total and the problem will be detected.
Both of these advantages have implications for designing batch systems. The
first is that economies are derived from having batches that are as large as possible.
The cost of processing each transaction is reduced when the fixed costs of data
processing are allocated across a large number of transactions.
The second implication is that finding an error in a very large batch may prove
difficult. When a batch is small, error identification is much easier. In designing a
batch system, the accountant should seek a balance between the economic advantage
of large batches and the troubleshooting advantage of small batches. There is no
magic number for the size of a batch. This decision is based on a number of
operational, business, and economic factors. Among these are the volume of
transactions, the competitiveness of the industry, the normal frequency of errors, the
financial implications of an undetected error, and the costs of processing. Depending
on these factors, a system might process small batches (50 to 100 items) several times
a day or an entire day’s activity as a single batch.

A. Differences Between Batch and Real-time Systems

Real-time and batch processing

There are a number of differences between real-time and batch processing. These
are outlined below:

a. Each transaction in real-time processing is unique. It is not part of a

group of transactions, even though those transactions are processed in
the same manner. Transactions in real-time processing are stand-alone
both in the entry to the system and also in the handling of output.
b. Real-time processing requires the master file to be available more
often for updating and reference than batch processing. The database is
not accessible all of the time for batch processing.
c. Real-time processing has fewer errors than batch processing, as
transaction data is validated and entered immediately. With batch
processing, the data is organised and stored before the master file is
updated. Errors can occur during these steps.
d. Infrequent errors may occur in real-time processing; however, they are
often tolerated. It is not practical to shut down the system for
infrequent errors.
e. More computer operators are required in real-time processing, as the
operations are not centralised. It is more difficult to maintain a real-
time processing system than a batch processing system.
 f. When decisions must be made between the two types of systems (later
chapters) we will consider two characteristics: response time (a
measure of the lag) and activity ratio (proportion of a file that is
processed each time the file is updated). These will help answer the
efficiency v. effectiveness issue.

B. Alternative Data Processing Approaches

Despite the availability of very modern information systems, many
organizations continue to use older systems. Early legacy systems were mainframe
based, batch oriented using flat-files. Newer legacy systems use databases. More
modern systems are network based and process data in real time. It is important
that accountants have an understanding of older system because they are still in use.
Section B of the chapter appendix provides a great discussion of legacy systems
including data structures and processing modes.
An excellent example is presented on updating master files from transactions
in the sales order system, which
shows sequential record structures for the hypothetical system. The labels (PK)
and (SK). (PK) refers to the primary key for the record–the piece of information that
uniquely identifies a record, e.g., your social security number is used by the
university to uniquely identify your records, not your name or anything else that
might have a duplicate. Try to follow the logic of the processing and not get lost in
the details. Anyone who uses a PC has experienced the loss ofdata when the “save”
command is given for a file that has changed. The new file replaces the old–which is
gone!
C. Batch Processing Using Real-Time Data Collection
One hybrid using the best of both worlds is to capture data in real-time and
process it in batches.This will walk through a sales order system. Follow the narrative
carefully. We will see much more about this and other parts of a system in later
chapters.
D. Real-Time Data Processing
What many people think of when computer processing is mentioned is a
situation in which data is captured live and processed immediately–in realtime.
This section of the chapter introduces the concepts of distributed processing and
network

CHARACTERISTICS OF VALUABLE INFORMATION.

In order for information to be valuable it must have the following characteristics, as

adapted from Ralph M. Stair's book, Principles of Information Systems:

1. Accurate. Accurate information is free from error.

2. Complete. Complete information contains all of the important facts.
3. Economical. Information should be relatively inexpensive to produce.
4. Flexible. Flexible information can be used for a variety of purposes, not just
one.
5. Reliable. Reliable information is dependable information.
6. Relevant. Relevant information is important to the decision-maker.
7. Simple. Information should be simple to find and understand.
8. Timely. Timely information is readily available when needed.
9. Verifiable. Verifiable information can be checked to make sure it is accurate.

Data processing folks like to talk about the "ACID test" when deciding
whether or not a database management system is adequate for handling transactions.
An adequate system has the following properties:
Atomicity
Results of a transaction's execution are either all committed or all rolled back.
All changes take effect, or none do. That means, for Joe User's money transfer, that
both his savings and checking balances are adjusted or neither are. For a Web content
management example, suppose that a user is editing a comment. A Web script tells
the database to "copy the old comment value to an audit table and update the live
table with the new text". If the hard drive fills up after the copy but before the update,
the audit table insertion will be rolled back.
Consistency
The database is transformed from one valid state to another valid state. This
defines a transaction as legal only if it obeys user-defined integrity constraints. Illegal
transactions aren't allowed and, if an integrity constraint can't be satisfied then the
transaction is rolled back. For example, suppose that you define a rule that postings in
a discussion forum table must be tied to a valid user ID. Then you hire Joe Novice to
write some admin pages. Joe writes a delete-user page that doesn't bother to check
whether or not the deletion will result in an orphaned discussion forum posting. The
DBMS will check, though, and abort any transaction that would result in you having a
discussion forum posting by a deleted user.
Isolation
The results of a transaction are invisible to other transactions until the
transaction is complete. For example, if you are running an accounting report at the
same time that Joe is transferring money, the accounting report program will either
see the balances before Joe transferred the money or after, but never the intermediate
state where checking has been credited but savings not yet debited.
Durability
Once committed (completed), the results of a transaction are permanent and
survive future system and media failures. If the airline reservation system computer
gives you seat 22A and crashes a millisecond later, it won't have forgotten that you
are sitting in 22A and also give it to someone else. Furthermore, if a programmer
spills coffee into a disk drive, it will be possible to install a new disk and recover the
transactions up to the coffee spill, showing that you had seat 22A.
Database design and the creation of an entity relationship diagram (also
known as an "ERD" or data model) is an important yet sometimes overlooked part of
the application development lifecycle. An accurate and up-to-date data model can
serve as an important reference tool for DBAs, developers, and other members of a
JAD (joint application development) team. The process of creating a data model helps
the team uncover additional questions to ask of end users. Effective database design
also allows the team to develop applications that perform well from the beginning. By
building quality into the project, the team reduces the overall time it takes to complete
the project, which in turn reduces project development costs. The central theme
behind database design is to "measure twice, cut once".
Effective database designers will keep in mind the principles of normalization
while they design a database. Normalization is a database design approach that seeks
the following four objectives:

1. minimization of data redundancy,

2. minimization of data restructuring,
3. minimization of I/O by reduction of transaction sizes, and
4. enforcement of referential integrity.

The following concepts and techniques are important to keep in mind when designing
an effective database:

1. An entity is a logical collection of things that are relevant to your database.

The physical counterpart of an entity is a database table. Name your entities in
singular form and in ALL CAPS. For example, an entity that contains data
about your company's employees would be named EMPLOYEE.

2. An attribute is a descriptive or quantitative characteristic of an entity. The

physical counterpart of an attribute is a database column (or field). Name your
attributes in singular form with either Initial Capital Letters or in all lower
case. For example, some attribute names for your EMPLOYEE entity might
be: EmployeeId (or employee_id) and BirthDate (or birthdate).

3. A primary key is an attribute (or combination of attributes) that uniquely

identify each instance of an entity. A primary key cannot be null and the value
assigned to a primary key should not change over time. A primary key also
needs to be efficient. For example, a primary key that is associated with an
 INTEGER datatype will be more efficient than one that is associated with a
CHAR datatype. Primary keys should also be non-intelligent; that is, their
values should be assigned arbitrarily without any hidden meaning. Sometimes
none of the attributes of an entity are sufficient to meet the criteria of an
effective primary key. In this case the database designer is best served by
creating an "artificial" primary key.

4. A relationship is a logical link between two entities. A relationship represents

a business rule and can be expressed as a verb phrase. Most relationships
between entities are of the "one-to-many" type in which one instance of the
parent entity relates to many instances of the child entity. For example, the
relationship between EMPLOYEE and STORE_LOCATION would be
represented as: one STORE_LOCATION (parent entity) employs many
EMPLOYEEs (child entity).

5. The second type of relationship is the "many-to-many" relationship. In a

"many-to-many" relationship, many instances of one entity relate to many
instances of the other entity. "Many-to-many" relationships need to be
resolved in order to avoid data redundancy. "Many-to-many" relationships
may be resolved by creating an intermediate entity known as a cross-reference
(or XREF) entity. The XREF entity is made up of the primary keys from both
of the two original entities. Both of the two original entities become parent
entities of the XREF entity. Thus, the "many-to-many" relationship becomes
resolved as two "one-to-many" relationships. For example, the "many-to-
many" relationship of (many) EMPLOYEEs are assigned (many) TASKs can
be resolved by creating a new entity named EMPLOYEE_TASK. This
resolves the "many-to-many" relationship by creating two separate "one-to-
many" relationships. The two "one-to-many" relationships are EMPLOYEE
(parent entity) is assigned EMPLOYEE_TASK (child entity) and TASK
(parent entity) is assigned to EMPLOYEE_TASK (child entity).
 6. A "foreign key" exists when the primary key of a parent entity exists in a child
entity. A foreign key requires that values must be present in the parent entity
before like values may be inserted in the child entity. The concept of
maintaining foreign keys is known as "referential integrity".

7. Relationships between two entities may be classified as being either

"identifying" or "non-identifying". Identifying relationships exist when the
primary key of the parent entity is included in the primary key of the child
entity. On the other hand, a non-identifying relationship exists when the
primary key of the parent entity is included in the child entity but not as part
of the child entity's primary key. In addition, non-identifying relationships
may be further classified as being either "mandatory" or "non-mandatory". A
mandatory non-identifying relationship exists when the value in the child table
cannot be null. On the other hand, a non-mandatory non-identifying
relationship exists when the value in the child table can be null.

8. Cardinality helps us further understand the nature of the relationship between

the child entity and the parent entity. The cardinality of a relationship may be
determined by asking the following question: "How many instances of the
child entity relate to each instance of the parent entity?". There are four types
of cardinality: (1.) One to zero or more (common cardinality), (2.) One to one
or more (P cardinality), (3.) One to zero or one (Z cardinality), and (4.) One to
exactly N (N cardinality)

Effective database design can help the development team reduce overall
development time and costs. Undertaking the process of database design and creating
a data model helps the team better understand the user's requirements and thus
enables them to build a system that is more reflective of the user's requirements and
business rules.
V. CONCLUSION
Database Systems and the Future of Accounting
o Database systems may affect the fundamental nature of accounting as follows:
Database systems may lead to the abandonment of the double-entry accounting
model.
o The basic rationale for the double-entry model is that the redundancy of
recording the amount of a transaction twice provides a check on the accuracy of
data processing.
o Data redundancy is the antithesis of the database concept.
o If the amounts associated with a transaction are entered into a database system
correctly, then it is necessary to store them only once, not twice. Database
systems also have the potential to significantly alter the nature of external
reporting. For example, a company can make a copy of its financial database
and make it available to external users.
o External users would then be free to manipulate and analyze the raw data in
whatever manner they see fit. The most significant effect of database systems
will be in the way accounting information is used in decision making.
o For example, relational databases provide query languages that are powerful
and easy to use.
o Thus managers can concentrate solely on specifying what information they
want.
o As a result, financial reports can be easily prepared to cover whatever time
periods managers want to examine, not just the time frames accountants
traditionally use. Finally, relational DBMSs provide the capability of integrating
financial and operational data.
o For example, data about customer satisfaction should be stored in the same
database used to store information about current balances and credit limits.
o In this case managers would have access to a case, richer set of data for
making tactical and strategic decisions
Accountants must become knowledgeable about database systems so that they can
participate in designing the accounting information systems of the future.

References

Hall, James., Introduction to Transaction Processing, USA: Accounting Information

System, 6e., 2008

http://en.wikipedia.org/wiki/Transaction_processing_system

http://philip.greenspun.com/sql/introduction.html accessed on March 4th 2011

http://www.aisintl.com/case/library/R-Theory_vs_ER/r-theory_vs_er6.html accessed
on March 4th 2011

http://www.referenceforbusiness.com/management/Comp-De/Data-Processing-and-
Data-Management.html#ixzz1FaNegoLu accessed on March 5th 2011