Relational Databases

Chapter 3
Types of Files

 Two basic types of files are used to store

data.
1 The master file, which is conceptually
similar to a ledger in a manual system.
2 The transaction file, which is
conceptually similar to a journal in a
manual system.
File Approach
 For many years, companies created new files
and programs each time an information need
arose.
 This proliferation of master files created
problems:
1 Often the same data was stored in two or
more separate files.
2 The specific data values stored in the different
files were not always consistent.
File-Oriented Approach

File 1
Fact A Sales
Fact B Program
Fact C
File 2
Fact B Shipping
Fact D Program
Fact E
File 3
Fact A Billing
Fact G Program
Fact E
Databases
 The database approach views data as an
organizational resource that should be used
by, and managed for, the entire organization,
not just the originating department or
function.
 Its focus is data integration and data sharing.
 Integration is achieved by combining master
files into larger pools of data that can be
accessed by many application programs.
Databases
 Database management system (DBMS)
is the program that manages and
controls access to the database.
 Database system is the combination of
the database, the DBMS, and the
application program that uses the
database.
 Database administrator (DBA) is the
person responsible for the database.
Database Approach

Database Sales Program

Fact A
Database
Fact B Shipping
management
Program
Fact C system
Fact D
Fact E Billing
Program
Relational Databases

 A data model is an abstract

representation of the contents of a
database.
 The relational data model represents
everything in the database as being
stored in the form of tables.
 Technically, these tables are called
relations.
Relational Databases

 Each row in a relation, called a tuple,

contains data about a specific
occurrence of the type of entity
represented by that table.
Logical and Physical
Views of Data
 A major advantage of database systems
over file-oriented systems is that the
database systems separate the logical
and physical view of data.
 What is the logical view?
 It is how the user or programmer
conceptually organizes and understands the
data.
Logical and Physical
Views of Data
 What is the physical view?
 It refers to how and where the data are
physically arranged and stored on disk,
tape, CD-ROM, or other media.
 The DBMS controls the database so that
users can access, query, or update it
without reference to how or where the
data are physically stored.
Logical and Physical
Views of Data

Logical View User A Logical View User B

Past Due Accounts October Sales by Region
Name Balance Days
Jackson 2145 48
Houston 1595 65

Database
Operating
DBMS system
Logical and Physical
Views of Data

Program-data independence is
the separation of the logical and
physical views of data.
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
Schemas

 The conceptual-level schema is an

organization-wide view of the entire
database.
 The external-level schema consists
of a set of individual user views of
portions of the database, also
referred to as a subschema.
 The internal-level schema provides a
low-level view of the database.
Schemas

Subschema A Subschema B Subschema C

r r
Jackson 210 xxxxxxx
Houston 100 xxxxxxx

Mapping external level views to conceptual level schema

Inventory Sales Customer

Cash receipt
Schemas

Inventory Sales Customer

Cash receipt
Mapping conceptual level facts to internal level descriptions

Inventory Record
Item number – integer (5), non-null, index = item x
Description – character (15)
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
 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
The Data Dictionary
 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 of all synonyms for the data elements in
a particular file
DBMS Languages

 Every DBMS must provide a means of

performing the three basic functions:
1 Creating the database
2 Changing the database
3 Querying the database
 The sets of commands used to perform
these functions are referred to as the data
definition, data manipulation, and data
query languages.
DDL Language
 The data definition language (DDL) is
used to...
– build the data dictionary.
– initialize or create the database.
– describe the logical views for each
individual user or programmer.
– specify any limitations or constraints on
security imposed on database record or
fields.
DML Language

 The data manipulation language (DML)

is used for data maintenance.
 What does it include?
– updating portions of the database
– inserting portions of the database
– deleting portions of the database
DQL Language

 The data query language (DQL) is used

to interrogate the database.
 The DQL retrieves, sorts, orders, and
presents subsets of the database in
response to user queries.
Basic Requirements of the
Relational Data Model
1. Each column in a row must be single valued.
2. Primary keys cannot be null.
3. Foreign keys, if not null, must have values
that correspond to the value of a primary key
in an other relation.
4. All non-key attributes in a table should
describe a characteristic about the object
identified by the primary key.
Anomalies That May Occur in Non-
Normalized Relational Tables
 Update Anomaly: When changes
(updates) to data values are not
correctly recorded.
 Instead of having to update once, each
record in the single table has to be updated
individually in order to avoid inconsistencies
in the database.
Anomalies That May Occur in Non-
Normalized Relational Tables
 InsertAnomaly: There is no way to
store information about one entity in
the database without it being
associated with another entity
 In the text, we would not be able to store
information on new customers without their
being associated with transactions first!
 Anomalies That May Occur in Non-
Normalized Relational Tables
 Delete Anomaly: Unintended results
arising from deleting a row of data
pertaining to one entity and resulting in
the deletion of data regarding another
entity as well.
 In the text, if a particular Inventory item were
discontinued and hence removed from the
database table, we would lose information on
the customer associated with that inventory
item as well.
Approaches to
Database Design
 Normalization
 Starts with the assumption that all data is initially
stored in a large non-normalized table.
 This table is then decomposed using a set of
normalization rules to create a set of tables in the
Third Normal Form.
 Semantic Data Modeling
 The database designer uses his/her knowledge
about the business structure to create a set of
relational tables.
Database Systems and the
Future of Accounting
 Database systems have the potential to
significantly alter the nature of external
reporting.
 Perhaps the most significant effect of
database systems will be in the way that
accounting information is used in
decision making.
Designing and Implementing a
Database System
 Six basic steps in designing and
implementing a database system:
1. Initial planning to determine the need for
and feasibility of developing a new system
(planning stage).
2. Identifying user needs (requirements
analysis stage).
3. Developing the contextual-, external-and
internal- level schemas (design stage).
Designing and Implementing a
Database System
4. Translating the internal-level schema into
the actual database structures that will be
implemented in the new system (coding
stage).
5. Transferring all data from the existing
system to the new database
(implementation stage).
6. Using and maintaining the new system
(operation and maintenance stage).
The REA Data Model

 Data modeling is the process of defining a

database so that it faithfully represents all
aspects of the organization, including its
interactions with the external environment.
 The REA (Resources, Data, Events) data
model is a conceptual modeling tool that
focuses on the business semantics underlying
an organization’s value chain activities.
The REA Data Model

Data Modeling in the database Design Process

Operation and
Planning
maintenance
Data
modelin Requirements
g occurs Implementation
analysis
here

Design Coding
The REA Data Model

 The REA data model provides

structure in two ways:
1 By identifying what entities should
be included in the AIS database
2 By prescribing how to structure
relationships among the entities in
the AIS database
Types of Entities

 An entity is any class of objects about which

data is collected.
 The REA data model classifies entities into
three distinct categories:
1 Resources acquired and used by an
organization
2 Events engaged in by the organization
3 Agents participating in these events
Types of Entities

 Resources are defined as those things

that have economic value to the
organization.
 What are some examples?
– cash
– inventory
– equipment
Types of Entities

 Events are the various business

activities about which management
wants to collect information for planning
or control purposes.
 What are some examples?
– sales events
– taking customer orders
Types of Entities
 Agents are the third type of entity in the
REA model.
 Agents are the people and organizations
that participate in events and about
whom information is desired.
 What are some examples?
– employees
– customers
Developing an REA Diagram
 Developing an REA diagram for a specific
transaction cycle consists of four steps:
1 Identify the pair of events that represent the
basic give-to-get economic duality relationship
in that cycle.
2 Identify the resources affected by each event
and the agents who participate in those
events.
Developing an REA Diagram
3. Analyze each economic exchange event
to determine whether it should be
decomposed into a combination of one or
more commitment events and an
economic exchange event. If necessary,
replace the original economic exchange
event with the resulting set of commitment
and economic exchange events.
4. Determine the cardinalities of each
relationship.
Basic REA template
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
Sample REA diagram

Inventory Stock-flow Sales Participant Salesperson

Participant

Economic
Customer
Duality

Participant

Cash
Cash Stock-flow Participant Cashier
Receipts
REA Diagram, Step 1:
Identify Economic Exchange Events

 In drawing an REA diagram for an individual

cycle, it is useful to divide the paper into three
columns, one for each type of entity.
 Left column should be used for resources.
 Middle column should be used for events.
 Right column should be used for agents.
REA Diagram, Step 1:
Identify Economic Exchange Events

 The basic economic exchange in the revenue

cycle involves the sale of goods or services
and the subsequent receipt of cash in payment
for those sales.
 The REA diagram for S&S’s revenue cycle
shows the drawing of sales and cash receipts
events entities as rectangles and the
relationship between them as a diamond.
REA Diagram, Step 2:
Identify Resources and Agents
 Once the events of interest have been
specified, the resources that are affected
by those events need to be identified.
 The sales event involves the disposal of
inventory.
 The cash receipts event involves the
acquisition of cash.
REA Diagram, Step 2:
Identify Resources and Agents
 After specifying the resources affected
by each event, the next step is to identify
the agents who participate in those
events.
 There will always be at least one internal
agent (employee) and, in most cases, an
external agent (customer).
REA Diagram, Step 3:
Include Commitment Events
 The third step in drawing an REA diagram is
analyzing each economic exchange event to
determine whether it can be decomposed into
a combination of one or more commitment
exchange events.
 Example: The sales event may be
decomposed into the “take order” commitment
event and the “deliver order” economic
exchange event
Decomposing Sales into Orders and Sales

Customer
Inventory- (1,N) (1,1) Participant (0,N) Customer
Orders
Orders

(0,N) (1,1)

(0,1) Participant

(0,N)
Inventory- Leads to
Inventory (0,N) Salesperson
Sales (0,N)

(0,1)
(1,N)
Participant

(1,1)
Sales

(1,1) Participant (0,N) Customer

REA Diagram, Step 4: Determine Cardinalities

 Cardinalities indicate how many

instances of one entity can be linked to
one specific instance of another entity.
 Cardinalities are often expressed as a
pair of numbers.
 The first number is the minimum, and the
second number is the maximum.
Continued…

 The minimum cardinality of a relationship

indicates whether each row in that entity MUST
be linked to a row in the entity on the other side
of the relationship.
 Minimum cardinalities can be either 0 or 1.
 A minimum cardinality of zero means that a new
row can be added to that table without being
linked to any rows in the other table.
 A minimum cardinality of 1 means that each row
in that table MUST be linked to at least one row
in the other table
Continued…

 The minimum cardinality of zero in the

(0, N) cardinality pair to the left of the
customer entity in the customer-sales
relationship indicates that a new
customer may be added to the database
without being linked to any sales events.

(0, N)
Sales Made to Customer
Continued…

 The minimum cardinality of 1 in the

(1, 1) cardinality pair to the right of the
sales entity in the customer-sales
relationship indicates that a new sales
transaction CAN ONLY be added if it is
linked to a customer.

(1,1) (0, N)
Sales Made to Customer
Continued…

 The maximum cardinality of a relationship

indicates whether each row in that entity CAN be
linked to more than one row in the entity on the
other side of the relationship.
 Maximum cardinalities can be either 1 or N.
 A minimum cardinality of 1 means that each row
in that table can be linked to at most only 1 row
in the other table.
 A maximum cardinality of N means that each row
in that table MAY be linked to more than one row
in the other table.
Continued…

 The maximum cardinality of N in the (0,

N) cardinality pair to the left of the
customer entity in the customer-sales
relationship indicates that a given
customer MAY be linked to many sales
events.

(0, N)
Sales Made to Customer
Continued…

 The maximum cardinality of 1 in the

(1, 1) cardinality pair to the right of the
sales entity in the customer-sales
relationship indicates that a given sales
transaction can only be linked to one
customer.

(1,1) (0, N)
Sales Made to Customer
Continued…

 Cardinalities are not arbitrarily chosen by

the database designer.
 They reflect facts about the organization
being modeled and its business
practices obtained during the
requirements analysis stage of the
database design process.
Relationships between Entities

 Three basic types of relationships

between entities are possible, depending
on the maximum cardinality associated
with each entity. They are:
1. A one-to-one relationship (1:1)
2. A one-to-many relationship (1:N)
3. A many-to-many relationship (M:N)
Different types of relationships

Panel A: One-to-One (1:1) Relationship

Cash
Sales (0,1) (1,1)
Receipts
Different types of relationships

Panel B: One-to-Many (1:N) Relationship

Cash
Sales (0,N) (1,1)
Receipts
Different types of relationships

Panel C: One-to-Many (1:N) Relationship

Cash
Sales (0,1) (1,N)
Receipts
Different types of relationships

Panel D: Many-to-Many (M:N) Relationship

Cash
Sales (0,N) (1,N)
Receipts
Entity-Relationship Diagram
 An Entity-Relationship (E-R) diagram is one
method for portraying a database schema.
 It is called an E-R diagram because it shows
the various entities being modeled and the
important relationships among them.
 In an E-R diagram, entities appear as
rectangles, and relationships between entities
are represented as diamonds.
Sample E-R Diagrams

Managed
Employers By
Supervisors

Part of
Manages

Departments

Customer Part of Cash

Orders
Sales Part of
Receipts

Players Part of Teams Part of League

Sample E-R Diagram based on REA model
Inventory Inventory- Buyer
(0,N) (1,N) Purchases (1,1) Participant (0,N)
Purchases (Purchasing Agent)

(0,N) (1,1)
Participant

(0,N)
Purchases-
Cash Vendor
Disbursements

Participant (0,N)

(1,N) (1,1)

Cash
Cash (0,N) Stockflow (1,1) (1,1) Participant (0,N) Cashier
Disbursement
Implementing an REA Diagram in a Relational
Database

 An REA diagram can be used to design a

well-structured relational database.
 A well-structured relational database is
one that is not subject to update, insert,
and delete anomaly problems.
Implementing an REA Diagram in a
Relational Database
Implementing an REA diagram in a
relational database is a three-step
process:
1. Create a table for each distinct entity and for each
many-to many relationship
2. Assign attributes to appropriate tables
3. Use foreign keys to implement one-to-one and
one-to-many relationships
Implementing an REA model

Inventory Inventory- Buyer

(0,N) (1,N) Purchases (1,1) Participant (0,N)
Purchases (Purchasing Agent)

(0,N) (1,1)
Participant

(0,N)
Purchases-
Cash Vendor
Disbursements

Participant (0,N)

(1,N) (1,1)

Cash
Cash (0,N) Stockflow (1,1) (1,1) Participant (0,N) Cashier
Disbursement
Create Tables
From the previously discussed REA diagram, nine
tables would be created: one for each of the seven
entities and one for each of the many-to-many
relationships.

1. Inventory 6. Cash
disbursements
2. Purchases
7. Cash
3. Employees
8. Purchases-
4. Vendors inventory
5. Cashier 9. Purchases-cash
disbursements
Assign Attributes for Each Table

 Primary keys: Usually, the primary key of

a table representing an entity is a single
attribute.
 Other Attributes: Additional attributes are
included in each table to satisfy
transaction processing requirements.
Implement One-to-One and One-to-
Many Relationships
 One-to-One Relationships: In a relational
database, one-to-one relationships
between entities can be implemented by
including the primary key of one entity as
a foreign key in the table representing
the other entity.
 No examples of 1:1 relationships in the
sample diagram
Implement One-to-One and
One-to-Many Relationships
 One-to-Many Relationships: In a relational
database, one-to-many relationships can be
also implemented in relation to databases by
means of foreign keys.
 The primary key of the entity with the maximum
cardinality of N becomes a foreign key in the
entity with a maximum cardinality of 1
 Examples: Employee number and vendor
number are foreign keys in the purchases
event and in the cash disbursement event
Documentation of Business Practices

 REA diagrams are especially useful for

documenting an advanced AIS built
using databases.
 REA diagrams provide information about
the organization’s business practices
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
Documentation of Business Practices

 The one minimum for the cash receipts

event indicates that cash is not received
prior to delivering the merchandise
 The N maximum for the cash receipts
event means that customers may pay for
several sales with one check

Cash Sales-
(1, N) Cash Receipts (0, N) Sales
Receipts
Extracting Information From the AIS

 A complete REA diagram serves as a

useful guide for querying an AIS
database.
 Queries can be used to generate
journals and ledgers from a relational
database built on the REA model.
Extracting Information From the AIS

(0, 1) (1, N) Cash

Sales collections
 Each sales transaction is paid in full by a cash
collection event.
 Each customer payment may be for more than
one sale.
 What is the query logic?
 Total accounts receivable is the sum of all sales
for which there is no remittance number.
Extracting Information
From the AIS

(0, N) (1, 1) Cash

Sales collections
 Each sales transaction can be paid in
installments.
 Each customer payment is for just one sale.
 What is the query logic?
 (1) sum all sales; (2) sum cash collections;
then A/R = (1)-(2)
Extracting Information
From the AIS

(0, 1) (1, 1) Cash

Sales collections
 Each sales transaction is paid in full by a cash
collection event.
 Each customer payment is for one sale.
 What is the query logic?
 Total accounts receivable is the sum of all
sales for which there is no remittance number.
Extracting Information
From the AIS

(0, N) (1, N) Cash

Sales collections
 Each sales transaction may be paid for in
installments.
 Each customer payment may be for more than
one sale.
 What is the query logic?
 (1) Sum all sales; (2) Sum all cash collections;
Then A/R = (1)-(2)
End of Chapter 3