1|Page

CHAPTER FOUR

RELATIONAL DATABASES

Information about the attributes of customer, such as name and address, are
stored in fields. All the fields containing data about one entity (e.g., one
customer) form a record. A set of related records, such as all customer
records, forms a file (e.g., the customer file). A set of interrelated, centrally
coordinated data Files that are stored with as little data redundancy as
possible forms a database. A database
Consolidates records previously stored in separate files into a common pool
and serves a variety of users and data processing applications.
The Advantages of Database Systems
Databases provide organizations with the following benefits:
● Data integration. Master files are combined into large “pools” of data
that many application programs access. An example is an employee
database that consolidates payroll, personnel, and job skills master files.
● Data sharing. Integrated data are more easily shared with authorized
users. Databases are easily browsed to research a problem or obtain detailed
information underlying a report. The FBI, which does a good job of collecting
data but a poor job of sharing it, is spending 8 years and $400 million to
integrate data from their different systems.
● Minimal data redundancy and data inconsistencies. Because data
items are usually stored only once, data redundancy and data
inconsistencies are minimized.
● Data independence. Because data and the programs that use them are
independent of each other, each can be changed without changing the other.
This facilitates programming and simplifies data management.
● Cross-functional analysis. In a database system, relationships, such as
the association between selling costs and promotional campaigns, can be
explicitly defined and used in the preparation of management reports.

1|Page
2|Page

4.1 Files vs. Databases

In this subunit you will study about the difference between files and databases and how
are they related.
In addition you will learn about the types of files and database systems and schemas.
A schema describes the logical structure of a database.
To have a clear picture of the power of databases, it is crucial to understand the basic
principles of how data are stored in computer systems.
The following picture shows the basic elements of what is commonly called the data
hierarchy.
Information about the attributes of an entity, such as suppliers name and address, are
stored in the fields. All the fields containing data about one entity (e.g. one supplier) form
a record.
A set of related records, such as all supplier records, forms a file (e.g. the supplier file).
A set of interrelated, centrally coordinated file forms a database.

2|Page
3|Page

Types of Files

Files: A file is a container in a computer system for storing information.

 Files used in computers are similar in features to that of paper documents used in library
and office files.
 There are different types of files such as text files, data files, directory files, binary and
graphic files, and these different types of files store different types of information.
 In a computer operating system, files can be stored on optical drives, hard drives or
other types of storage
Two basic types of files are used to store data.

3|Page
4|Page

A. The master file - The master file is conceptually similar to a ledger in manual
AIS. Master files store cumulative information about an organization's resources
and the agents with whom-it interacts.
Master files are permanent; they exist across fiscal periods. Individual records
within a master file, however, are frequently changed.
B. the transaction file: are not permanent, but are usually only maintained on-
line for one fiscal period. Examples are, a transaction file containing records of
sales events and another transaction file containing records of customers’
payments.
Both of these files would be used to update individual customer account balances
in the customer master file.

Databases

Database systems were developed to address the problems associated with the
proliferation of master files.
A database is a set of interrelated, centrally coordinated files
The database approach treats data as an organizational resource.
The focus is a data integration and data sharing with all authorized users.
The Figure shows that this is accomplished by using a program called a database
management system (DBMS), which acts as an interface between the database and the
various application programs.
The combination of the database, the DBMS, and the application programs that access
the database through the DBMS is referred to as the database system.

4|Page
5|Page

Data Base Systems

Logical and physical views of Data

 Database systems separate the logical and physical views of data.

 The logical view: is how the user or programmer conceptually organizes and understands
the data, For example, a sales manager may conceptualize all information about
customers as being stored in the form of a table.
 The physical view: refers to how and where the data are physically arranged and stored
on disk Tape, CD-ROM. or other media.
 Likewise, the database administrator can change the physical storage of the data to
improve system performance, without affecting users or application programs.

Schemas

 A schema describes the logical structure of a database.

There are three levels of schemas:

1. Conceptual-level schema
2. External-level schema
3. Internal-level schema

5|Page
6|Page

1. The conceptual-level schema: is an organization-wide view of the entire database.

 It lists all data elements and the relationships between them.
2. The external-level schema: consists of a set of individual user views of portions of
the database, also referred to as a subschema.
3. The internal-level schema: provides a low-level view of the database.

The Data Dictionary

 A key component of a DBMS is the data dictionary.

 The data dictionary contains information about the structure of the database.
 For each data element stored in the database, such as the customer number, there is a
corresponding record in the data dictionary describing it.
 The data dictionary is often one of the first applications of a newly implemented database
system.

What are some inputs to the data dictionary?

– Records of any new or deleted data elements

– Changes in names, descriptions, or uses of existing data elements

What are some outputs of the data dictionary?

– Reports useful to programmers, database designers, and users of the information system

What are some sample reports?

– Lists of programs in which a data item is used

– Lists xxazzzzzzzzzzzzzzzz m,of all synonyms for the data elements in a

particular file

6|Page
7|Page

4.2 Relational database

 A relational database is a database that conforms to the relational model and refers to a
database's data and schema (the database's structure of how that data is arranged).
 Common usage of the term "Relational Database Management System" technically refers
to the software used to create a relational database, but sometimes mistakenly refers to a
relational database.
 A Relational Database Management System (RDBMS) is a system that manages data
using the relational model.

What is the structure of a relational database model?

 A Relational Model of Data for Large institutions proposed shifting from storing
data in hierarchical or navigational structures to organizing data in tables
containing rows and columns.
 Each table, sometimes called a relation, in a relational database contains one or
more data categories in columns or attributes.
 Each row, also called a record or tuple, contains a unique instance of data --
or key -- for the categories defined by the columns.
 Each table has a unique primary key that identifies the information in a table.
 The relationship between tables can be set via the use of foreign keys -- a field in a
table that links to the primary key of another table.

7|Page
8|Page

Basic Terms

An understanding of relational databases requires an understanding of some of the basic terms.

• Data are the values stored in the database. On its own, data means very little. "43156" is an
example.

• Information is data that is processed to have a meaning. For example, "43156" is the
population of the town of Littlewood.

• A database is a collection of tables.

• Each table contains records, which are the horizontal rows in the table. These are also called
tuples.

• Each record contains fields, which are the vertical columns of the table. These are also called
attributes. An example would be a product record.

• A key: is a logical way to access a record in a table. For example, in the product table, the
product_id field could allow us to uniquely identify a record.

 A key that uniquely identifies a record is called a primary key.

 An index: is a physical mechanism that improves the performance of a database. Indexes
are often confused with keys.

8|Page
9|Page

 However, strictly speaking they are part of the physical structure, while keys are part of the
logical structure.

Double Entry Accounting in a Relational Database

 Many computer systems utilizing a relational database contain some sort of accounting
information.
 In the initial design and development stages there is often a debate about what type of
accounting strategy should be used by the software to record this information.
 The decision is usually between a simple and cheap ‘single entry’ accounting system and
a more complex ‘double entry’ accounting system.
 A ‘single entry’ system: is one where the numerical values being stored are only
recorded once.
 In a ‘double entry’ system: each value is stored twice, once as a credit (a positive
value), once as a debit (a negative value). There are a number of rules that control these
values. The main rules are as follows:

1. Every entry into the system must balance – i.e. the sum of any transaction must be zero.
2. The sum of all the values in the system at any one time must be zero (the ‘trial balance’).
3. No values can ever be amended or deleted. They must be negated with an opposing entry (a
‘contra’) and re-entered (‘re-booked). This provides a completely secure audit trail.
APPLICABILITY OF DOUBLE ENTRY ACCOUNTING

 At the outset of a project, the cost of a simple accounting system is always appealing.
 The complexity and effort of a full blown ‘double entry’ system often seems difficult to
justify.
 In reality going for a simple ‘single entry’ system is usually a false economy.
 If the accounting information is just mirroring a paper system outside the database, then
a single entry system might be acceptable, however, if any of the following apply then a
full ‘double entry’ mechanism ought to be implemented from the outset:

1. If the information will ever need to be audited by an accountant

2. If the information held is the sole record of ownership

9|Page
10 | P a g e

3. If the information held represents high-value assets.

4. If the system is likely to expand and grow in the future.

A DOUBLE ENTRY EXAMPLE

 The key factor of a double entry system is the presence of a ‘cash book’ account.
 This account contains the entries made when assets (e.g. money) are taken into or released
from the accounting system.
 As such the total value of this account always matches the total value of the assets in the
system.
 Using accountant’s ‘T charts’ to represent this we use the following example that uses two
accounts only.
 The ‘cash book’ and an account in the name of ‘Smith’.

(a) £300 is entered into this system to be allocated to the Smith account. The £300 is credited to

the Smith account (credits are on the right, debits on the left). To match this a debit of £300 is

allocated to the Cash Book.

(b) If £50 is taken out of the system from the Smith account, £50 is debited from the Smith

account and credited to the Cash Book.

10 | P a g e
11 | P a g e

(c) If another account is added in the name of Patel and £100 is transferred from Smith to Patel

then £100 is debited from Smith and £100 credited to Patel.

(d) To complete the picture £60 is taken out of the system from the Patel account with a debt from

Patel and a credit to the Cash book.

At the end of this the Smith account balance is £150, the Pattel account is £40 and the Cash Book

is £-190, the negative sum of the other accounts. On this simple basis very complex asset tracking

systems can be built

11 | P a g e
12 | P a g e

THE ACCOUNTING DATA MODEL

 A simple data model that can be used to represent this information is illustrated below:

 The POSTING table contains the actual accounting double entries.

 Keeping the figures in one table simplifies the mathematics dramatically.

 The primary key or part of the primary key of the POSTING table should be a system-

generated sequence number.

 It should also be generated in such a way that no gaps can appear in the sequence (through

a transaction rolling back, for example).

 This is part of ensuring that no entries are ever deleted.

12 | P a g e
13 | P a g e

 The BATCH and JOURNAL tables are used to control the input of the double entries to

this POSTING table.

 A JOURNAL entry is the data representation of any business transaction that will

produce double entries — it represents a complete unit of work. I.e. all POSTING entries

associated with the JOURNAL entry must be successfully completed or none must be

completed.

 The numerical sum of all POSTING entries associated with a JOURNAL entry must also

equal zero (the only way the total value contained in the system can be amended is though

the Cash Book).

 Each transaction described in the example above would be represented by one JOURNAL

entry.

 A BATCH entry reflects the more physical aspects of accounting data entry.

 It is used to group together JOURNAL entries into handy ‘chunks’, for example, a

collection of cheques to be entered into the system, a collection of information from an

Electronic Data Interface (EDI) or a global business process like the payment of interest to

all accounts.

 The ACCOUNT table represents the owner of the assets in the system.

 The ASSET TYPE table contains the list of asset types being held in the system.

 By making the asset type part of the POSTING primary key the system becomes a multi-

asset (e.g multi-currency) system.

 The above example is shown below as entries in this data model (the column list is kept as

simple as possible for clarity).

13 | P a g e
14 | P a g e

 The balance of the POSTING Amount column always being zero after every complete

JOURNAL transaction (and the software must not allow an incomplete one).

 From the above the total in the Cash Book adds up to –190 which is the negative sum of

the 150 belonging to Smith and the 40 belonging to Patel.

 To expand this system into a multi-currency system a new asset type is added and used. If

Mr Smith wished to change £20 into dollars at a rate of £1 to $1.5 the transaction is made

though the Cash Book as follows (the required POSTING entries):

ACCOUNTING PERIODS

 Our accounting model so far is perfectly sound but could creak under high volumes as we
can never delete anything.

14 | P a g e
15 | P a g e

 Most accounting requirements include the concept of an accounting period, maybe

monthly, three monthly or yearly, for example.
 Whilst there is no need to constrain the logical requirement for an accounting period by
tying it too closely to the physical model it provides a useful indication as to where to
break flow of the data.
 The year end is often a convenient point, either the calendar year end or the financial
year end.
 By adding a period indicator column to the POSTING table (and also to its primary key)
the data can be split into discreet time chunks that can be validated independently.
 If in the above example the next set of entries fell into the next accounting period the
balances outstanding are brought forward as summary entries in the next period first
(leaving out the currency exchange example for simplicity).

Firstly the balances for the previous period are cleared down.

After an appropriate period of time the previous YEAR 1 period can be archived and deleted
from the system.

AGGREGATING TRANSACTIONS

 There are some activities that occur within accounting systems that are large scale
changes that affect many or all of the accounts. For example, payment of interest to all
accounts as a percentage of their current balance or a global cut of quota by a certain
percentage.
 End-of-year ear example above also falls into this category.
 The end-of-year entries should all be done under the same JOURNAL (although it could
be argued that separate currencies/assets could be done under separate journals) but it is
quite acceptable to aggregate the entries to the Cash Book.

15 | P a g e
16 | P a g e

 The accounting rule requirements will still be met but it will simplify the work and
volumes involved by up to 50%.
 The POSTING entries in the above end of year example then become

BATCH ENTRY

 A batching mechanism is often used to facilitate data entry to this accounting system.
 In its historic form this is what has happened for the processing of cheques.
 An account clerk would be given a pile of ten cheques, a batch number and the total value
of the cheques.
 An entry screen would then be used by the clerk to record the cheques as ‘unauthorized’
entries.
 At the BATCH level the number of cheques and their total value is recorded and only
when the number of items entered and their totals match these figures is the user allowed
to commit the batch.
 Once this activity is complete the batch is passed to another member of staff who checks
the contents of the batch (either on-screen or with the aid of a report) and then
‘authorizes’ the batch if it is correct.
 This process is generally referred to as ‘maker/checker’ and can be adapted for the
manual entry of any primary asset data.
 The concept of a Batch is also useful for electronic data transfer as it provides a method
of aggregation for audit trail and correction processing.
 As a rule it is sensible to keep the details of ‘unauthorized’ entries in separate tables from
those ‘pucker’ double entries made by the ‘authorization’ process into the POSTING
table.
 If this is done it is also possible to simplify the programming effort by creating tables
more appropriate to the business function in hand. For example, in the above cheque
entry process the clerk will only have to identify one account.
 The other account, the Cash Book, is implicit as the movement of money will always be
from the Cash Book to the owners account.

16 | P a g e
17 | P a g e

 A CHEQUE table would only require one Account column where as a hypothetical
FUND TRANSFER table would need two, a ‘From Account’ column and a ‘To Account’
column.

CODE DESIGN

 The modules required to support a double entry accounting system are best designed
using a tiered, Object Oriented (OO), approach. The tiers used are as follows

1. Interface processing (user and electronic)

2. Business processing
3. Database processing
 A full design is dependent of the type of system required but the following hypothetical
modules could exist in each layer.

Post Entry: A module to make a basic POSTING entry is required at the database layer.

This will insert a record adding timestamps and sequenced identifiers automatically.
It cannot delete or update records and no other module will be allowed to update, insert
or delete records apart from an archiving module to do deletions. The POSTING table is
read-only for all other purposes.
Make Deposit, Make Withdrawal, and Make Transfer: Modules to perform basic business
process will exist at the Business layer. They will call Post Entry in the appropriate
manner.

THE TRIAL BALANCE

 The ‘trial balance’ is the main method of ‘proving’ the integrity of any accounting
system.
 If all the entries made into the system have been made in accordance to the double entry
rules and are not corrupt in any way than the sum of all these entries will always equal
zero.
 The chance of an equal and opposite, matching, error occurring is so small that it can be
completely discounted.

17 | P a g e
18 | P a g e

 The best way to run a trial balance is to start at the highest level and only break the
figures down if a problem occurs.
 Using the above table structure the parameters for these queries are as follows:

1st Sum the values in the POSTING. Amount column.

Then if that fails

2nd Sum the values in the POSTING. Amount column but broken down by Asset Type and
Account Period.

 This should indicate where the problem lies.

 The fact that the sum of every JOURNAL should also equal zero can then be used to
track down the POSTING entries that are in error.

18 | P a g e