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.

3-2
 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
• Facilitate the use of databases after they are
implemented

3-3
 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
3-4
 LO# 2

UML Class Diagram – Building Blocks

• Classes are separately identifiable collections of

things about which the organization wants to
collect and store information
• 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
3-5
 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-6
 LO# 2

UML Class Diagram - Associations

• Associations depict the (business) relationship between two
classes

3-7
 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

Example of Association with Multiplicities Options for Multiplicities

Indicator Meaning
1..1 0..* 0..1 Zero or one
Person owns Auto 1..1 One only
0..* 0 or more
1..* 1 or more
Multiplicities (Cardinalities)

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-8
 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-9
 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-10
 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-11
 LO# 2

Table Listing - Example

Customers [Customer_Number (PK), Customer_Name, Customer_City, Customer_State,

Customer_Zip, Customer_Phone]

Orders [Order_Number (PK), Order_Date, Delivery_Date, Order_Amount, Shipping_Cost,

Customer_Number (FK)]

Order_Items [Order_Number + Product_Number (PK), Quantity_Ordered, Price]

Inventory [Product_Number (PK), Product_Description, Quantity_on_Hand (QOH), Unit_of_Issue,

Current_List_Price, Standard_Cost]

3-12
 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-13
 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
5. Implement relationships among tables
following the class diagram
3-14
 LO# 4

1. Map Classes to Tables

3-15
 LO# 4

2. Map Class Attributes to Table Fields and Assign Primary Keys

3-16
 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-17
 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-18
 LO# 3

5. Implement Relationships Among Tables

3-19
 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-20
 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-21