LOGO
Chapter 5
UNDERSTANDING AND
DESIGNING
ACCOUNTING DATA
King Saud University
Noura Al.Madi
1
Contents
Introduction
Identifying and Documenting files
Attributes and Relationships
Developing UML Class Diagram
2
Introduction
• Relational database: database in which data are
represented as a set of two-dimensional tables with
columns representing attributes and rows representing
records
• Attributes: The smallest units of data that can have
meaning to a user. The columns in a relational
database that are equivalent to fields in a file.
Attribute
(Filed)
Row (record)
Equipment #
Rental-Date
Customer #
1235
05/11/2003
5501
1530
05/17/2003
5502
3
Identifying and Documenting Files
Transaction files:
Used to record information about events in a
business process.
Attributes include:
– Transaction date
– Agents associated with transaction
– Description of products/services associated with
event
4
Identifying and Documenting Files
Master files:
• Store reference data
• Store summary data
Events and transaction files:
• First, identify the events in the business process
• Then, identify the need for transaction files in the AIS
5
Identifying and Documenting Files
UML class diagram:
1. Shows relationships between
transaction and master files
2. Each box represents a file
3. Connecting lines between files
indicate file relationships
4. Can be used to document:
– Tables in an AIS
– Relationships between tables
– Attributes of tables
Table (File)
Name
Order
Order
Order_Date
1
m
Attributes
(fields)
Relationship
shipment
Invoice
Cash
collection
6
Identifying and Documenting Files
Guidelines for identifying need for transaction tables:
1: Determine the events in the process
2: Exclude events that do not need to be recorded in
the computer system
3: Exclude query and reporting events because they
involve using data that have already been recorded
in the AIS
4: Exclude maintenance events
7
Identifying and Documenting Files
Events and master tables:
• Typical master tables:
– Products/services - master tables
• Describe products/services offered
• Identify costs and/or prices of products/services
– Agents - master tables describe
• External agents
• Internal agents
8
Identifying and Documenting Files
(continued)
– Cash - master file
describes where cash is stored
– General ledger master file - needed if general
ledger system is
• Automated and
• Integrated with the revenue or acquisition cycle.
Generally, master tables are used to store relatively
permanent data about an entity
9
Identifying and Documenting Files
Benefits of master tables:
• Save data entry time
• Save storage space
• Simplify making changes to data
• Simplify deleting transaction records
10
Identifying and Documenting Files
Structure UML class Diagram (example)
General
Ledger
Goods/
Service
Events
Agents
Order
Inventory
General
Ledger
Shipment
Customer
Invoice
Cash
Collection
11
Identifying and Documenting Files
Guidelines
- Agent associated with events on the right side of events.
- Goods/service associated with the event on the left side
of the event.
- If required Cash Master File, it would be included in the
table in the same column as the inventory.
- General Ledger master table to the left of goods/services.
- Arranging the transaction tables according to the
sequence of events make it easier to read the diagram.
12
Attributes And Relationships
Three important concepts:
1. Primary keys
2. Linking attributes (foreign keys)
3. Relationship cardinalities
13
Attributes And Relationships
This tables applies concepts:
Customer Table
Primary key
Customer #
Name
Address
Contact_
Person
3450
Brownsville C.C
Brownsville, TX
Smith
956-555-0531
3451
Educate, Inc.
Fairhaven, MA
Costa
508-888-4531
3452
Bunker Hill C.C
Bunker Hill, MA
Lanfranc
617-888-8510
Telephone #
Order Table
Primary key
Order #
Order_Data
Customer #
0100011
05/11/2003
3451
0100012
05/15/2003
3451
0100013
05/15/2003
3450
Foreign key
14
Attributes And Relationships
1. Primary key:
Attribute(s) that uniquely identifies a record in a table
2. Foreign key:
A field in a table that is the primary key in some other
table
– Used to link one table to another
– Link event records to master records
– Link two events that occur in a sequence
15
Attributes And Relationships
3. Cardinality of the relationship:
Cardinality is an expression of the relationship
between common fields (attributes) in two tables.
• Important in designing a database
• Represents how many occurrences of one type of
entity are associated with another type of entity
• This relationship can be one-to-one (1,1), one-tomany (1,m), or many-to-many (m,m).
16
Attributes And Relationships
(continued)
 One-to-one relationships (1,1) - not nearly as common
as one-to-many relationships
Shipment
1
1
1 shipment
per invoice
Invoice
1 invoice per
shipment
 One-to-many relationships (1,m) - common in
accounting systems
Order
many orders per
customer over time
m
1
Customer
1 customer
per order
17
Attributes And Relationships
(continued)
 Many-to-many relationships (m,m) - can be converted
into two one-to-many relationships by adding a
“junction table”
m
Inventory
m
Order
many product
per order
many orders per
product over time
Inventory
1
Order
1
m
1 product per detail
record; many detail
record per product
Order Detail
m
many detail record
per order; 1 order per
detail record
18
Attributes And Relationships
Significance of concepts for database applications:
1. Implementing documents and reports
2. Implementing input forms
– Input forms are used to make data entry more
accurate/efficient
– Form designs rely on primary and foreign keys
and relationships between tables
19
Attributes And Relationships
(continued)
3. Controlling AIS data – referential integrity
– For one-to-many relationships we can specify if we
want referential integrity enforced on relationship
– Control most effective with two other controls:
• Segregation of duties and
• Access controls
20
Developing A UML Class Diagram
Example:
Fairhaven convenience Store sells gasoline and other
products. Customer select product and bring them to
the manager. The manager scan the selected products,
and the total amount due is displayed on the cash
register. The customer give cash to the manager who
puts it in the cash register. He gives change (if any) to
the customer. Four managers work at the gas station,
but only one manager is in the station at any one
time. The manager who is in the third shift places the
cash in an envelope and drops it in a deposit slot at
the bank.
21
Developing A UML Class Diagram
Four basic steps in Developing A UML Class Diagram
Step 1: Place the required transaction tables (files) on
the UML class diagram.
A. Identify events in a business process.
B. Decide which events will need transaction tables.
Event
Is a transaction tables needed?
Make sale
Yes, The sale and cash collection data should be
record in the AIS.
Deposit cash
Possibly. The company could record the data of the
deposit, the amount, and the manager who made
the deposit.
22
Developing A UML Class Diagram
(continue step 1)
C. Start the UML class diagram by showing a box for
each event requiring transaction tables
sale
Deposit
23
Developing A UML Class Diagram
Step 2: Place required master tables (files) on UML
class diagram
A.For each event on the diagram (from Step 1),
determine related goods, services, or agent
entities
Event
Product/Service Internal Agent External Agent
Make sale
Inventory
Manager
Customer
Deposit cash
Cash
Manager
Bank Teller
24
Developing A UML Class Diagram
(continue step 2)
B. Determine which identified entities require
master tables.
Two master table are needed:
Inventory Master Table
Manager Master Table
Not create master table for:
Customer: Customers names and address are not needed because the
company will not bill customer since they must pay cash and no
advertising will be sent to them.
Bank teller: There is no need to identify the bank teller to whom a
deposit is made.
25
Developing A UML Class Diagram
(continue step 2)
C. Consider using master tables to track location of
cash and effect of events on account balances in
the general ledger
The store does not need a master table for cash since all cash
collections are deposited at the same bank.
Currently, the general ledger system is not automated, so no
General_Ledger master table will be needed in the system.
26
Developing A UML Class Diagram
(continue step 2)
D. Add required master tables to appropriate side of
the UML class diagram
Inventory
Sale
Manager
Deposit
27
Developing A UML Class Diagram
Step 3: Determine required relationship between tables
A.For each connecting lines, determine cardinality of the
relationship between tables
B.Write cardinalities next to line between entities
Inventory
m,m
Sale
m,1
m,1
Deposit
m,1
Manager
28
Developing A UML Class Diagram
(continue step 3)
C. If there are any many-to-many relationships, convert
them to one-to-many relationships by adding junction
table (The junction table must include the primary
keys of each of the tables in the many-to-many
relationship)
Inventory
Sale
m,1
1,m
Sales Detail
m,1
m,1
Deposit
m,1
Manager
29
Developing A UML Class Diagram
Step 4: Determine required attributes by:
A.Assigning a primary key to each tables
B.Linking related tables by adding a foreign key to one
of the pair in the relationship (Linking depends on
cardinality of the relationship.
Inventory
Sale
(m,1)
Product #
(1,m)
Sales Detail
Sale #
Product #
Sale #
SSN
(m,1)
Manager
SSN
(m,1)
(m,1)
Deposit
Deposit #
SSN
30
Developing A UML Class Diagram
(continue step 4)
C. Assign other attributes as needed for providing
information content
Table
Information attributes needed
Primary
Key
Foreign
Key
Manager
Last_Name, First_Name, Address,
Fill stats (tax filing status),
Exemptions
SSN
Inventory
Description, supplier,
Reorder_Point, Quantity_on_hand
Product #
Sale
Date, Sales_Tax
Sale #
SSN
Sale
Detail
Quantity_Sold, Price
Sale #/
Product #
Sale #/
Product #
31
Developing A UML Class Diagram
Other Consideration in data design:
Simplifying the data design:
1. One master table instead of two
If different tables have similar purposes and similar
or identical structure
Server
Take Order
Customer
Prepare
Meal
Cook
32
Developing A UML Class Diagram
(continued)
2. Eliminate redundant relationships
Delete a line indicating a relationship between two
tables if the relationship can be determined from others
that occurred earlier.
Order
Customer
Shipment
33
Developing A UML Class Diagram
(continued)
3. One event table instead of two
If there is a one-to-one relationship between events in
a sequence, the designer has the option
• Option A: Two records in two tables
Rentals Table (used to record rentals only)
Rental_Transaction # Videotape # Data_Rented Customer #
1035
5220
05/14/2003
3201
Return Table (used to record return only)
Return_Transaction #
1035
Videotape # Data_Rented
5220
05/14/2003
34
Developing A UML Class Diagram
(continued)
• Option B: One record in one table
Rentals and Return Table
Rental_Transaction # Videotape # Data_Rented
1035
5220
05/14/2003
Date_Returned
05/17/2003
4. Recording agent data in event tables
35
Developing A UML Class Diagram
Communicating the data design:
Guidelines in preparing documentation:
1. Be consistent in naming entities
2. Name boxes so can easily correlate UML diagram
with preceding documentation
3. Help reader understand how each part of the
documentation relates to other parts
36
Developing A UML Class Diagram
Proper layout can also enhance readability
1. Start each part on a separate page
2. Clearly label each part
3. Write a brief explanation of the information
obtainable by reviewing diagram
4. Use bulleted lists to explain linkages between
diagrams
5. Use same style throughout
37
LOGO
38