1

Chapter Four

Relational Database, Data

Modeling and Database System
 Introduction
2
 You have already been introduced to the first two
components of information systems: hardware and
software. However, those two components by themselves
do not make a computer useful.
 Imagine if you turned on a computer, started the word

processor, but could not save a document.

 Imagine if you opened a music player but there was no

music to play.
 Imagine opening a web browser but there were no web

pages.
 Without data, hardware and software are not very useful!
 Data is the third component of an information system.
 Data, Information, and Knowledge
3

 Data are the raw bits and pieces of information with no

context. If I told you, “15, 23, 14, 85,” you would not have
learned anything. But I would have given you data.
 Data can be quantitative or qualitative.
 Quantitative data is numeric, the result of a measurement,
count, or some other mathematical calculation.
 Qualitative data is descriptive, the color of the sky, is an
example of qualitative data.
 A number can be qualitative too: if I tell you my favorite
number is 5, that is qualitative data because it is descriptive,
not the result of a measurement or mathematical calculation.
 Data, Information, and Knowledge
4

By itself, data is not that useful. To be useful, it needs to

be given context.
 Data, Information, and Knowledge
5

 Once we have put our data into context, aggregated and

analyzed it, we can use it to make decisions for our
organization. We can say that this consumption of information
produces knowledge. This knowledge can be used to make
decisions, set policies, and even spark innovation.
 The final step up the information ladder is the step from
knowledge (knowing a lot about a topic) to wisdom. We can
say that someone has wisdom when they can combine their
knowledge and experience to produce a deeper understanding
of a topic. It often takes many years to develop wisdom on a
particular topic, and requires patience.
 Database
6

Creating a database can be like

creating a universe, only more
complicated. At least when the
universe was created, there was no
one around to complain.
Michael J. Hernandez
Database Design for
Mere Mortals
 Database
7

 It is a set of inter-related, centrally coordinated files.

 A database management system (DBMS) serves as
the interface between the database and the various
application programs.
 The combination of the database, DBMS, and the
application programs that access the database is
referred to as the database system.
 Database technology provides the following benefits:
 Data integration: combining master files into

larger pools of data accessible by many programs.

 Data sharing: easier to share data that’s integrated
 Cont’d………
8

 Reporting flexibility: Reports can be revised

easily and generated as needed.
 Minimal data redundancy and inconsistencies:
data items are usually stored only once.
 Data independence: Data items are independent
of the programs that use them.
 Central management of data: Data management
is efficient b/c database administrator is
responsible for coordinating, controlling and
managing data.
 Cross-functional analysis: Relationships can be
explicitly defined and used in the preparation of
 Databases
9

 The goal of many information systems is to transform data into information in order to
generate knowledge that can be used for decision making. In order to do this, the
system must be able to take data, put the data into context, and provide tools for
aggregation and analysis. A database is designed for just such a purpose.
 A database is an organized collection of related information. It is an organized
collection, because in a database, all data is described and associated with other data.
All information in a database should be related as well; separate databases should be
created to manage unrelated information. For example, a database that contains
information about students should not also hold information about company stock
prices. Databases are not always digital – a filing cabinet, for instance, might be
considered a form of database. For the purposes of this course, we will only consider
digital databases.
 Relational Databases
10

 Databases can be organized in many different ways, and thus take

many forms. The most popular form of database today is the relational
database. Popular examples of relational databases are Microsoft
Access, MySQL, and Oracle.
 A relational database is one in which data is organized into one or
more tables.
 Each table has a set of fields, which define the nature of the data stored in
the table.
 A record is one instance of a set of fields in a table.
 To visualize this, think of the records as the rows of the table and the fields as the
columns of the table.
 Relational Databases
11

 Relational databases underlie (basis) most modern

integrated AISs.
 They are the most popular type of database used for
transaction processing.
 Logical and Physical Views of Data
12

 Database systems separate the logical and physical

views of data.
 Logical view of data refers to how the user or
programmer conceptually organize and understand
the data.
 Example, a sales manager may conceptualize all

information about customers as being stored in the

form of a table.
 Physical view of data refers to how and where the
data are physically arranged and stored on disk, tape,
CD ROM, or other media.
 Schemas
13

 Schema (diagram) describes the logical structure of a

database.
 There are three levels of schemas:
 Conceptual level schema,
 External level schema, and
 Internal level schema

 The conceptual level schema is the organization-wide

view of the entire database.
 It lists all data elements and the relationships

between them.
 Cont’d……….
14

 The external level schema consists of a set of

individual user views of portions of the database,
each of which is also referred to as a sub-schema.
 The internal level schema provides a low-level view
of the database.
 It describes how the data are actually stored and

accessed, including information about: Pointers,

Indexes, Record lengths, and so forth.
 Data Dictionary
15
 A key component of a DBMS is the data directory,
contains information about 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.
 One of the first applications of a newly implemented
database system.
 Inputs to the data directory include records of new

or deleted data elements, changes in names,

descriptions, or uses of existing data elements.
 Outputs include a variety of reports useful to

programmers, database designers, and users of IS.

 DBMS Languages
16

 Every DBMS must provide a means of performing

the three basic functions:
 Creating,
 Changing, and
 Querying the database

 The set of commands used to perform these functions

are;
 Data definition,
 Data manipulation, and
 Data query languages respectively.
 Cont’d………
17

 Data definition language (DDL) uses to:

 Build the data directory
 Initialize or create the database
 Describe the logical views for each user or

programmer
 Specify any limitations or constraints on security

imposed on database records or fields

 Data manipulation language (DML) uses for:
 Data maintenance such as updating, inserting and

deleting portions of the database.

 Cont’d………
18

 Data query language (DQL):

 Used to interrogate (examine/question) the
database.
 Retrieves, sorts, orders, and presents subsets of the

database in response to user queries.

 Contain powerful, but easy to use, set of

commands that enables users to satisfy their

information needs, without the programmer's
assistance.
 Many DBMSs also include a report writer, which

is a language that simplifies report creation.

 Cont’d………
19

 The report writer then searches the database,

extracts the specified data items, and prints them
out according to the user specified format.
 All users generally have access to both the DQL
and the report writer.
 Access to the DDL and DML, however, should be
restricted to those employees with administrative and
programming responsibilities.
 Cont’d………
20

 Relational database tables have three types of attributes

(elements/characteristics):
 Primary key
 Foreign key
 Other non-key attributes

 Primary key is the attribute or combination of

attributes that uniquely identifies a specific row in a
table.
 Often, the primary key is a single attribute.
 In some tables however, two or more attributes

jointly form the primary key.

 Cont’d……..
21

 Foreign key is an attribute appearing in one table that is a

primary key in another table.
 Foreign keys are used to link tables.

 Customer number and salesperson number are

foreign keys in the sales table; both are used to link
the data about a sales transaction with information
about the sales person & the customer
 Other non-key attributes - in each table store important
information about that entity.
 Example, in the inventory table, quantity on hand,

description and list price are non-key attributes.

 Cont’d………
22

Sample Inventory Table

Item Number Description Quantity List price

2014 19" Monitor 32 Br 1,890

2015 21" Monitor 9 Br 2,890

3054 Color 25 Br 3,900

Printer
 Cont’d………
23

Basic Requirements of the Relational Data Model

 Every column in a row must be single valued - there

shall be one and only one value in each cell.

 Primary keys cannot be null - A non-null value for

primary key indicates that a specific object exists and

can be identified by reference to its primary key
value, referred to as the entity integrity rule.
 Foreign keys must have values that correspond to the value

of the primary key in another relation referred to as the

referential integrity rule.
 All non-key attributes in a table should describe a

characteristic about the job identified by the primary key.

 Cont’d………
24

Problems associated with storing all Data in one

table
 It creates data redundancy.

 It makes file maintenance unnecessarily time

consuming and error prone.

 Three specific types of problems can occur:

 Update anomaly (inconsistency): since updates or

changes to data values are not correctly recorded.

 For example, changing a customer's address
requires searching the entire table and changing
every occurrence of that customer's address.
 Cont’d……….
25
 Insert anomaly:
 Example: There is no way to store information
about prospective customers until they actually
make the purchase and the sales invoice number
column would be blank. However, the invoice
number is the primary key and it cannot be
blank.
 Delete anomaly: involves unintended results that
arise when deleting a row in that table.
 Example: If a customer has made only one
purchase, consisting of a single item, deleting
that row from the table would result in the loss of
 Cont’d……….
26

The Solution: A set of tables

 The problem associated with trying to store all the

data in one table can be avoided by creating a set of

tables- one table for each entity of interest.
 Redundancy is greatly reduced
 Avoids the insert anomaly and
 Avoids the deletion of information.
 Database Design Approaches
27

 Two basic approaches to design a well structured

relational database:
 Normalization - starts with the assumption that
everything is initially stored in one large table.
 A set of rules is then followed to decompose that

initial table into a set of normalized tables.

 The objective is to produce a set of tables what are

called third normal form (3NF), because such

tables are free of the types of update, insert and
delete anomalies.
 Cont’d………
28
 Semantic - uses knowledge about how business
processes work and the information needs associated
with transaction processing to draw a database.
 The resulting figure can then be directly used to

create a set of relational tables that are in 3NF.

 Semantic has two advantages over normalization.
 Facilitates the efficient design of transaction

processing databases through the use of designer's

knowledge about business processes and practices.
 Facilitates communicating with the intended users

of the system b/c the model represents information

about the company's business processes and
 Database Systems and Future of Accounting
29

 Database systems may profoundly affect the

fundamental nature of accounting.
 May lead to the abandonment of the double entry

accounting model.
 Have the potential to significantly alter the nature

of external reporting.
 May change the way that accounting information is

used in decision making.

 Accommodate multiple views of the same

underlying phenomenon.
 Provide the capability of integrating financial and

operational data.
 Database Design Process
30
 There are six basic steps in database design:
 Planning Sage - involves the initial planning to
determine the need for and feasibility of developing
the new system.
 Requirements Analysis Stage - involves identifying
user information needs, defining the proposed new
system scope, and transaction volumes to make
decisions about hardware and software requirements.
 Design Stage - involves developing the different
schemas for the new system; at the conceptual,
external, and internal levels.
 Cont’d……..
31

 Coding - involves translating the internal level

schema into the actual database structures that will be
implemented in the new system.
 Implementation - involves transferring data from
existing systems to the new database, testing the new
system, and training employees how to use it.
 Operation and Maintenance - involves using and
maintaining the system including carefully
monitoring system performance and user satisfaction
to determine the need for making system
enhancements and modifications.
 Cont’d………..
32
 Data modeling is the process of defining a database
so that it faithfully represents all aspects of the
organization, including its transactions.

Data Modeling in the database Design Process

Operation and
Planning
maintenance

Requirements
Data Implementation
modeling analysis
occurs
here
Design Coding
©2003 Prentice Hall Business Publishing, 5-13
Accounting Information Systems, 9/e, Romney/Steinbart
 Cont’d………
33

 Data modeling occurs during both the

requirements analysis and design stages of
the database design process.
 The Two important tools of data modeling;
 Entity relationships diagramming and
 REA data model
 Entity Relationship Diagrams
34

 An entity relationship (E-R) diagram is a graphical

technique for portraying a database schema.
 Shows the various entities being modeled and

relationships among them.

 Entities appear as rectangles and relationships

between entities are represented as diamonds.

 E-R diagrams can be used to design databases,
document and understand existing databases, and
reengineer business processes.
 An important step in database design is deciding
which entities need to be modeled.
 REA data model is useful for making that decision.
 REA Data Model
35

 A conceptual modeling tool that focuses on the

business semantics underlying a value chain
activities.
 Provides guidance for database design by identifying
what entities should be included in the database and
structure of relationships among them.
 REA model classifies entities into three categories:
 Resources - the organization acquires to use,
 Events (business activities) - which the
organization engages on, and
 Agents participating in the events.
 REA Data Model Cont’d……..
36

 The events in REA data model fall into one of the

two categories:
 Economic exchanges or
 Commitments
 Economic exchanges - value chain activities that
directly affect the resources.
 E.g. Sales event decreases the inventory and the

cash receipts event increases the amount of cash.

 Commitments - promises to engage in future
economic exchanges.
 E.g. Customer orders are commitments that lead to

future sales.
 REA Data Model Cont’d………
37

 Events such as the sales that change the quantity of a

resource is called a stock flow relationship.
 Other events such as taking a customer order that
represent future commitments are linked to resources
called reserve relationships.
 Each event is linked to two agent entities.
 Internal agent is the employee who is responsible

for the resource affected by the event.

 External agent is the outside party to the

transaction.
 Each economic exchange event is linked in a give to
get duality relationship with another economic
 REA Data Model Cont’d………
38

 The Economic duality relationships reflect the basic

business principle that organizations typically engage
in activities that use-up resources only in hopes of
acquiring some other resource in exchange.
 For example, the sales event, which requires giving

up (decreasing) inventory is related to the cash

receipts event which requires getting (increasing)
the amount of cash.
 Basic REA template
39

Resource A GET
Inflow Participant Internal Agent
Resource A

Participant External Agent

Economic
Duality

Participant External Agent

GIVE
Resource B Outflow Participant Internal Agent
Resource B
 REA Data Model Cont’d……….
40

 Developing REA diagram for a specific transaction

cycle consists of four steps:
 Identify the pair of economic exchange events

 Identify the resources affected by each event and

the agents who participate.

 Analyze each economic exchange event

 Determine the cardinalities of each relationship.

Step 1: Identify Economic Exchange Events

 The basic REA template consists of a pair of events;

 One increases some resource and

 One decreases some resource.

 REA Data Model Cont’d……..
41

 The events are drawn as rectangles and the economic

duality relationship between them as a diamond.
 In drawing REA model, the paper is divided into
three columns-one for each type of entity:
 The left column is used for resources,

 The center column for events, and

 The right column for agents.

 The event entities are drawn from top to bottom

corresponding to the sequence in which they occur.
 REA Data Model Cont’d……….
42

Step 2: Identify Resources and Agents

 Resources affected by the events need to be

identified
 The sales event is translated to giving inventory to

customers and the cash receipts event is translated

to receiving cash from customers.
 Hence, the inventory and cash entities are added
in the resource column.
 A/R is not modeled as a separate entity because it

is not an independent object but simply represents

a timing difference between sales and cash
 REA Data Model Cont’d……..
43

 Identify the agents who participate in the events.

 There will always be at least one internal agent

(employee) and external agent (customer or

vendor) who participate in each event.
 For example,
 Customers and salespersons participate in the
sale event, and
 Customers and cashiers participate in the cash
collection event.
 The REA data model requires that each event be
linked to at least one resource and two agents.
 Sample REA diagram
44

Inventory Stock-flow Sales Participant Salesperson

Participant

Economic
Customer
Duality

Participant

Cash
Cash Stock-flow Participant Cashier
Receipts
 REA Data Model Cont’d……….
45

Step 3: Include Commitment Events

 Analyze each economic exchange event to determine

whether it can be decomposed into a combination of

one or more commitment and exchange events.
 It is important for management to
 Get up to date information about various orders to

reorder various inventory items.

 Know which orders have been shipped and when.
 Example; the economic exchange event labeled
sales may be replaced with a combination of a
commitment event labeled customer orders and
the economic exchange event labeled sales.
 REA Data Model Cont’d………
46

 The cash receipts economic exchange event will

not be decomposed because whether payment is
received immediately or later by mail, what shall
be tracked is actual receipts from customers.
 Billing as an event is not modeled because it is
neither an economic exchange nor a
commitment.
 Printing an invoice and mailing it to customer
doesn't increase or decrease any resource.
 It is an information processing event that

merely retrieves information from the

database about previous customer orders
 Cont’d………
47

Step 4: Determine the Cardinalities of Relationships

 The nature of relationships b/n the various entities.

 Indicate how many instances of one entity can be

linked to one specific instance of another entity.

 For example, how many sales transactions can be

linked to each individual customer and, conversely,

how many customers can be linked to each
individual sales transaction.
 Cardinalities are represented as pairs of numbers next

to each entity.
 The first number is the minimum cardinality.
 Cont’d……….
48

 It indicates whether a row in the table must be

linked to at least one row in the table on the
opposite side of that relationship.
 A minimum cardinality of 0 means that a new
row can be added to that table without being
linked to any specific rows in the table on the
other side of the relationship.
 The second number in each cardinality pair is the
maximum cardinality.
 It indicates whether one row in a table can be
linked to more than one row in the other table.
 Cont’d………
49
 A maximum cardinality of 1 means that each row
in that table can be linked to at most only one
row in another table.
Documentation of
Business Practices

 The zero minimum for the sales event indicates

that credit sales are made
 The N maximum for the sales event means that
customers may make installment payments

Cash Sales-
(1, N) Cash Receipts (0, N)
Sales
Receipts
 Cont’d……….
50
 Cont’d………
51
 Three basic types of relationships between entities
are possible depending on the maximum cardinality.
 A one to one (1:1) relationship exists when the

maximum cardinality for each entity in that

relationship is one.
 A one to many (1:N) relationship exists when the

maximum cardinality of one entity in that

relationship is 1 and the maximum cardinality of
the other entity in that relationship is N
 Many to many (M:N) relationship exists when a

maximum cardinality for both entities in the

relationship is N.
 Cont’d…………
52
Rules for Specifying Cardinalities
 Cardinalities don’t select arbitrarily.
 Cardinalities reflect facts about the organization

being modeled and its business practices.

Cardinality Rules for Agent-Event Relationship
 The minimum and maximum cardinalities associated

with the event entity in every agent-event relationship

will be both 1.
 The minimum cardinality is 1 because there must

be an agent who participates in that event.

 The maximum cardinality is 1 because the

organization wants to be able to hold some specific

agent responsible for that event.
 Cont’d………
53

 The cardinalities associated with each agent entity in

the agent-event relationship all have zero minimums
and N maximums.
 The maximum cardinality associated with internal

agent entities is almost always N, because

organizations expect their employees will
participate in numerous events.
 It is also usually N for external agents, because

organizations often engage in repeat transactions

with the same suppliers and customers.
 Cont’d……….
54

 There are two reasons why the minimum

cardinality associated with agent entities in the
agent-event relationship is usually zero:
 Organizations want to be able to add
information about potential customers and
suppliers even though those agents may not
have participated yet in the business
 Cont’d……….
55

Cardinality Rules for Resource-Event Relationships

 The minimum and maximum cardinalities associated

with each resource in resource-event relationship are

zero and N, respectively.
 The minimum cardinality associated with event

entities in resource-event relationship is usually 1.

 For example, each sale event must include at least

one row in the inventory table and each payment

received from a customer must be deposited into
some cash account.
 Cont’d………
56

Cardinality Rules for Event-Event Relationships

 Any kind of cardinality pair is possible for each

event entity in event-event relationships.

 The organization's business practices and policies

must be understood to decide which possibility is

correct.
 For example, collections from customers may be at

once (1:1) or in installments (1: N).

 The general principle applies to event-event r/ships is

that for two temporally ordered events, the minimum

cardinality for the first event is 0, because at the time
 Cont’d………
57

 Implementing an REA diagram in a relational

database is a three-step process:
 Create a table for each distinct entity and for each

many to many relationships

 Assign attributes to appropriate tables
 Use foreign keys to implement one to one and one

to many relationships.
Create Tables for Each Entity & M:N Relationships
 A properly designed relational database has a table

for each distinct entity and for each many to many

relationships in REA diagram.
 Cont’d……….
58
 The expected M:N relationships include customer
order-inventory, sales-inventory, and sales-cash
receipts.
Assign Attributes to Each Table
 During the data modeling process, users and

management will have identified facts that they want

to collect.
 Example, for inventory items the attributes may

include item number, description, cost & selling

price
 Assign primary keys
 Cont’d………
59
Use Foreign Keys to Implement 1:1 and 1: N
Relationships
 One to one Relationships - can be implemented by

including the primary key of one entity as a foreign

key in the table representing the other entity.
 For example, in the 1:1 relationship between sales

and customer payments,

 One to many relationships - 1:N relationships can be

implemented with foreign keys.

 Place the primary key of the entity with the

maximum cardinality of N as a foreign key in the

entity that has maximum cardinality of 1.
 REA Diagram for Documenting Business Processes
60

 REA diagrams are useful for documenting advanced

AIS, because the cardinalities in REA diagrams
provide information about the organization's business
practices and the nature of its economic exchanges.
 Correctly interpreting what the cardinalities in an
REA diagram mean requires understanding exactly
what the occurrence of each entity represents.
 Every organization will have its own unique REA
diagram because business practices and relationship
cardinalities differ across companies.
 Extracting Information from the AIS
61

 A completed REA diagram also serves as a useful guide

for querying an AIS database.
 Elements such as journals, ledgers and information
about receivables as well as payables may seem missing
in a database.
 Extracting Information from the AIS
 Producing journals and ledgers-
 Providing other financial statement information-
 Preparing managerial reports-
 Study Questions

62

 What is the difference between data, information, and

knowledge?
 What is the difference between quantitative data and
qualitative data? In what situations could the number 42
be considered qualitative data?
 What are the characteristics of a relational database?
 Describe what the term normalization means.
 Describe Semantic approach of database design.
 Name a database you interact with frequently. What
would some of the field names be?
63

Questions?

Thank you!