Chapter 4
Relational Databases
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
Databases differ in the type of data model they are designed with
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 =
itemx 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.
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 in the database Design Process
Operation and
Planning
maintenance
Data Requirements
modeling Implementation
analysis
occurs
here
Design Coding
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
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
Four steps (continued):
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.
REA Diagram, Step 4:
Determine Cardinalities
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
REA Diagram, Step 4:
Determine Cardinalities
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
REA Diagram, Step 4:
Determine Cardinalities
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
REA Diagram, Step 4:
Determine Cardinalities
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.
REA Diagram, Step 4:
Determine Cardinalities
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
REA Diagram, Step 4:
Determine Cardinalities
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
REA Diagram, Step 4:
Determine Cardinalities
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
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
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-
inventory
4. Vendors
9. Purchases-cash
5. Cashier 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
End of Chapter 4
