Chapter 3

Data
Modeling

Copyright 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent of McGraw-Hill Education.
 Learning Objectives

LO#1 Understand the purpose of structure models.

LO#2 Understand and apply the building blocks for UML
Class (structure) Diagrams.
LO#3 Describe multiplicities for a UML Class Diagram.
LO#4 Understand how to implement a relational
database from a UML Class Diagram.
LO#5 Describe business rules and various forms of rules.
LO#6 Steps in Database Design
LO#7 REA Modeling

3-2
 LO# 1

Types of Business Models

3-3
 LO# 1

Structure Models
Describe the data and information structures inherent in
a business process.
Create a blueprint for the development of a relational
database to support the collection, aggregation, and
communication of process information.
In the past, hierarchical databases were used. You
needed to know information at the top of a hierarchy
prior to being able to access data at a low level.
An example of a hierarchical database is the White Pages phone
book. If you did not know the city in which the person resides,
you cannot locate the information.
Relational databases are more powerful in that they allow the
user to search on related information regardless of where in the
hierarchy you are searching.
Facilitate the use of databases after they are
implemented.
3-4
 LO# 1

Relational Databases
Relational databases are a very important tool for business and accountants.If
properly and fully implemented they can provide an integrated view of the
business.

Large Enterprise Resource Planning systems (ERP) and usually designed with a
modular structure with each module controlling the key business functions within
that business cycle.
The Financing and Controlling module (on which
the accountants rely for integrated reporting of
financial statements, and managerial
accounting information)
is at the center of these modules.

As the business performs activities, the

modules feed accounting data to the financing
and controlling module.

The vast majority of accounting entries are

system generated entries triggered by physical
transactions in the business.
5
 Standard Business Cycles
Standard business cycles include:
Revenue cycle all business transactions that
relate to customer management and sales
Expenditure cycle all business transactions that
relate to vendor management and purchasing
Production cycle all business transactions that
relate to manufacturing
HR/Payroll cycle all business transactions that
relate to human resource management
Financing cycle all business transactions that
relate to business financing and capital structure
management
6
 LO# 1

Structure Models - Purposes

Describe the entities or things in the domain of interest
What tables do we require in the database the user in creating
Describe the relationships among those things
Transaction tables vs. master data tables.
In Master Data tables the data does not change frequently
(Employees, Inventory, and Customers etc.)
In Transaction tables the data changes all the time (sales,
purchases etc.)
Specify how many instances of one entity can be
related to another (multiplicity or cardinality) (one to
one, one to many, many to many)
Identify the attributes or characteristics of the entities
and relationships
What fields do we require to represent the data the company
wants to collect about the particular entities
Columns in MS Access
3-7
 LO# 2

Unified Modeling Language (UML)

UML class diagram notation for structure models

Specifications for UML maintained by the Object
Management Group, a not-for-profit consortium of
computer industry members
UML also includes notation for several other types
of diagrams, including several structure diagrams,
behavior diagrams, and interaction diagrams
Class diagrams describe the logical structure of a
database system
The building blocks of a relational database are the tables
in which the data resides.
The UML class models define the required tables required
in a relational database.
3-8
 LO# 2

UML Class Diagram Building Blocks

Classes are separately identifiable collections of things

about which the organization wants to collect and store
information
Tables in MS Access and other Relational databases
Associations depict the relationship between two classes.
Multiplicities describe the minimum and maximum
number of times instances of one class can be associated
with instances in another class
We model in MS Access or any other relational database the
maximum cardinality

3-9
 LO# 2

UML Class Diagram - Classes

Classes can represent
organization resources (e.g., trucks, machines,
buildings, cash, investments)
persons (e.g., customers, employees)
events (e.g., sales, purchases, cash disbursements,
cash receipts), and conceptual structures (e.g.,
accounts, product categories, budgets)

3-10
 LO# 2

UML Class Diagram - Associations

Associations depict the (business) relationship
between two classes

3-11
 LO# 2

UML Class Diagram - Multiplicities

Multiplicities describe the minimum and
maximum number of times instances in one class
can be associated with instances in another class

Each Person owns a minimum of 0 and a maximum of many Autos.

Each Auto is owned by a minimum of 1 and a maximum of 1 Person

3-12
 LO# 2

A simple example

PUTTING THE PATTERN TOGETHER

3-13
 LO# 2

Business Process Pattern

R E A

Classes (also called Associations (relationships)

entities/objects)

3-14
 LO# 2

Heres a very simple business for example. The

Bear (business employee) is selling cookies
(inventory) to the Lion (customer). How does
that fit into the REA Pattern?
3-15
 LO# 2

Bear and Lion

Next, lets add multiplicities

3-16
 LO# 3

Multiplicities
Cookies (inventory items) can be
sold in a minimum of 0 sales and a
maximum of many sales.

The Lion can

participate in a
minimum of 0 sales
and a maximum of
many sales.
3-17
End of
example

DESCRIBING THE TABLES

3-18
 LO# 2

Attributes
Attributes are data elements that describe the
characteristics of instances in a class (or rows in a
table)
The full specification of attributes, i.e., a data
dictionary, would also include data type, default value
(if any), constraints on the value (such as minimum
and maximum possible values), and other descriptive
information
Attributes include the primary keys that uniquely
define instances of the class, foreign keys that
support the links between classes shown in the
associations, and other data elements for each class
Attributes will be specified in a table listing that
accompanies each class diagram

3-19
 LO# 2

Primary Keys

An attribute or combination of attributes that uniquely

identifies each instance in a class or row in a table
A primary key cannot be NULL (blank)
A primary key should be controlled by the organization
that assigns it so it will not change over time

3-20
 LO# 2

Primary Keys
Should you use social security numbers as
primary keys?
No, since there are legal restrictions and not
everyone has a social security number (so the
primary key might by NULL)
Should you use peoples names as primary keys?
No, since names are not unique
Should you use phone numbers as primary keys?
No, since a persons phone number may change
over time
Should you assign primary keys using sequential
numbers?
Yes, since it is easier to identify gaps and you
control the number
3-21
 LO# 2

Foreign Keys
An attribute or combination of attributes that
allows tables to be linked together
Implements the link between classes (and
resulting tables) shown by the associations
In the following model, the primary key of the
PERSON class would become a foreign key in the
AUTO class to implement the association

3-22
 LO# 2

Table Listing - Example

3-23
 LO# 2

Other UML Relationship Notation

UML provides special notation to support other

types of relationships:
Generalization
Aggregation
Composition
This special notation is a form of short-hand, but
each can also be modeled using the basic
notation described earlier

3-24
 LO# 2

Relationship Special Notation

3-25
 LO# 2

Other Notation

3-26
 LO# 2

Best Practices in Preparing Class Diagrams

Use common terminology in the organization for

class names
Link classes on the diagram only when there is a
clear business purpose for the relationship.
Avoid crossing lines where possible
Use consistently sized class rectangles
Avoid running association lines close together
Opt for simplicity
Focus first on the accuracy of the content, then
address appearance.
Use notes to explain more complex situations.

3-27
 LO# 4

Implementing a Database from a

Class Diagram
1. Map classes to tables
2. Map class attributes to table fields and assign
primary keys
3. Map associations to foreign keys
4. Create new tables to implement many-to-many
relationships (junction table)
5. Implement relationships among tables following the
class diagram

3-28
 LO# 4

1. Map Classes to Tables

3-29
 LO# 4

2. Map Class Attributes to Table

Fields and Assign Primary Keys

3-30
 LO# 3

3. Map one-to-many associations

to foreign keys

One-to-many associations are defined by the maximum multiplicity

on each end of the association. The rule of thumb is to go toward the
* to post the foreign key. So, in the model above, the primary key of
STATE would be a foreign key in AUTO; the primary key of PERSON
would be also be a foreign key in AUTO. See Table 1 in Chapter 3 for a
listing of posting rules based on multiplicities.
3-31
 LO# 3

4. Create New Tables to Implement

Many-to-Many Relationships

Many-to-many associations require the creation of a new, linking

table to implement the association. So, in the model above, the
association between DEALERS and AUTO would be implemented with
a new table DEALER-AUTO with a primary key formed as the
combination of primary keys from the two classes.
3-32
 LO# 3

5. Implement Relationships Among Tables

3-33
 LO# 4

Business Rules

Succinct statement of constraints on a business

process.
Typically written in text not modeled; however, they
influence the structure and flow of models.
Establish multiplicities in class models and set criteria
for branching in activity models.
Stated in short sentences.
The Object Management Group maintains standards
for Semantics of Business Vocabulary and Business
Rules (SBVR) since 2008.
Make modeling business process easier since they
limit the number of options allowed by business policy.

3-34
 LO# 5

Types of Business Rules

Obligatory. This rule form states what should

occur: payment should be made in U. S. dollars.
Prohibited: This rule form states what should not
occur: no payments by check.
Allowed: This rule form says what is allowed
under what conditions: credit card payments are
allowed if the card is American Express.

3-35
 LO# 5

Business Rules Enforcement

Rules must be enforceable

Enforcement levels are:
Strict enforcement no violations allowed
Pre-override violations allowed if authorized in
advance
Post-override violations allowed if authorized after
the violation
Guidelines rules are followed but not enforced

3-36