ACCT3708

Auditing & Assurance Services

Week: 4
Topic: 4A: Database Normalisation

Lecturer: Dr Stuart D Taylor

E-mail: [email protected]
Consider… How can accounting data be stored in a
computer in the most efficient and
reliable manner?

2
Accounting Data
In Theory
At the most fundamental level, accounting data is
recorded as:

Debits and credits in Journal entries posted to

accounting entries in journals ledger accounts

• Sales Journal • Accounts receivable

• Payroll Journal subledger
• General Journal • Fixed assets register / PP&E
subledger
• General ledger
3
Accounting Data
Practical Computer Storage

In computerised accounting systems,

data is stored as…

Records
Consisting of multiple Fields
In Tables
Which are combined into
a Database

4
Data Input and Output
What the User Sees

The user does not directly see the

tables in the database; they see views
of the data.

Views are screens of data extracted

and combined from multiple database
tables.

If these views allow input, they will

have text boxes etc. In these cases,
they are called forms.
5
Accounting Databases
Reliable Data Storage

As the users will never see the database directly, it

can be optimised for efficiency and reliability

Data should only be stored once

• Saves space (less relevant these days)
• Avoids inconsistent data
• Easier to update when data changes

Database normalisation achieves these goals.

6
Database Normalisation
Structuring Data Effectively

Database normalisation is based on two simple ideas:

1) Data should be stored in multiple tables

• Each table should contain information about one
type of item
• Customers, orders, suppliers, cash receipts etc

2) Tables are linked together with keys

• So that we know which items are related
• Which customer (Customers Table) placed which order
(Orders Table)

7
 Customer no: Customer no:
#123456 #098765

Primary Keys
Unique Identifiers

A key is a field that uniquely identifies a record.

Name: Morgan Smith Name: Morgan Smith
A customer number uniquely identifies a customer
in the Customers table
• Autonumbering can ensure they are unique

A customer name does not, as two customers can

have the same name.

Each table must have at least one unique

identifying field
This is called a primary key.
8
Foreign Keys
Linking Tables Together

If the information is spread over many tables, how can

we tell which items are linked?

• Which customer placed which order

• Which supplier received which payment

We put the primary key of one table into the other table
• This is called a foreign key

Every foreign key is the primary key of another table

9
 Example – ABC Ltd
Suppliers, Purchases and Cash Payments
ABC Ltd stores its suppliers, purchases and cash payments records in the following tables:

PRIMARY key PRIMARY key PRIMARY key

FOREIGN key FOREIGN key

N:1 1:N

10
Example - ABC Ltd
Primary Keys

To ensure that each record in each table can be

uniquely identified, each table needs a primary key

01 – Supplier Number is the primary key of the Suppliers

Table

11 – Purchase Order Number is the primary key of the

Purchases Table

21 – Cash Payment Number is the primary key of the Cash

Payments Table

11
Example – ABC Ltd
Foreign Keys

To determine which purchase PRIMARY key PRIMARY key

was made from which FOREIGN key

supplier, we put the Supplier

Number (primary key of
Suppliers Table) in the
Purchases Table.

• Field 12 is a foreign key

12
Example – ABC Ltd
Foreign Keys

To ensure that purchases PRIMARY key PRIMARY key

can only be made from FOREIGN key

actual suppliers, a valid

code test can be used to
ensure that a number can
only be entered in Field 12
if it is already present in
Field 01.

13
Example – ABC Ltd
Foreign Keys

PRIMARY key PRIMARY key

To determine which cash payment FOREIGN

was made to which supplier, we put key

the Supplier Number (primary key of

Suppliers Table) in the Cash
Payments Table

• Field 22 is a foreign key

14
Example – ABC Ltd
Foreign Keys

PRIMARY key PRIMARY key

To ensure that cash payments can FOREIGN

only be made to actual suppliers, key

a valid code test can be used to

ensure that a number can only be
entered in Field 22 if it is already
present in Field 01

15
Example – ABC Ltd
Referential Integrity

The database can be set up to enforce

referential integrity.

Referential integrity ensures that a

number can only be entered in a
foreign key field if it already in the
primary key field

You can only enter a supplier number

in Field 12 or Field 22 if it is already in
Field 01.
16
Comparison
Referential Integrity vs Valid Code Test

Referential integrity and a valid code test do the

same thing in a different way.

A valid code test is enforced at the input form level.

• It will not prevent direct changes to data that are invalid.

Referential integrity is enforced at the database level.

• It will not give feedback to users when filling out an input
form.

Both can be defeated by deliberate tampering or

database corruption

17
Cascading Updates
Ensuring Changes are Carried Through

Cascading updates is a database setting that

ensures that:

When a primary key is changed, all foreign keys are changed to

match.

You should only change primary keys under

exceptional circumstances:

• To repair corruption or tampering with the database

• When the primary key entities have changed

18
 Example – ABC Ltd
Cascading Updates

ABC Ltd has two suppliers:

X Ltd. Y Ltd.
It has made the listed (Supplier No. 23) (Supplier No. 57)
purchases from and • Purchase Order No's. - • Purchase Order No's. - 118,
payments to them: 123, 137, 143 141, 152
• Cash Payment No's, - • Cash Payment No's, - 1037,
1056, 1089 1078, 1099

19
 Example – ABC Ltd
Cascading Updates
X Ltd. Y Ltd.
(Supplier No. 23) (Supplier No. 57)

X Ltd and Y Ltd merge to form Z Ltd. Z Ltd.

(Supplier No. 82)
Z Ltd is given the new supplier number
82.

20
Example – ABC Ltd
Cascading Updates Y Ltd.
X Ltd. (Supplier No. 57)
(Supplier No. 23)

Cascading updates will ensure that, in the

Purchases Table:

o The supplier number (field 21) for purchase

orders 123, 137 and 143 will be changed from
23 to 82
o The supplier number (field 21) for purchase Z Ltd.
orders 118, 141 and 152 will be changed (Supplier No. 82)
from 57 to 82

So that all the X Ltd and Y Ltd purchase orders are

now transferred to Z Ltd.

21
Example – ABC Ltd
Cascading Updates Y Ltd.
X Ltd. (Supplier No. 57)
(Supplier No. 23)

Cascading updates will also ensure that, in the

Cash Payments Table:

o The cash payment number (field 31) for

cash payments 1056 and 1089 will be
changed from 23 to 82
o The cash payment number (field 31) for Z Ltd.
cash payments 1037, 1078 and 1099 will (Supplier No. 82)
be changed from 57 to 82

So that all the X Ltd and Y Ltd cash payments are

now transferred to Z Ltd.

22