Chapter

3 Data Modeling
 Learning Objectives
LO 3-1 Understand the purpose of structure models.
LO 3-2 Understand and apply the building blocks for UML Class (structure) Diagrams.
LO 3-3 Describe multiplicities for a UML Class Diagram.
LO 3-4 Understand how to implement a relational database from a UML Class Diagram.
LO 3-5 Understand process decisions requirements and how business rules support
process decisions.
LO 3-6 Describe decision tables and business rules.

3-2
© McGraw Hill
 LO 1

Types of Business Models

There are two major types of business process models: Activity Models and Structure Models. Activity models are
introduced in Chapter 2. Structure models (or data models) describe the information structure of the process. Both
types of models implement business rules.
3-3
© McGraw Hill
 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-4
© McGraw Hill
 LO 1

Structure Models – Purposes

• Describe the entities or things in the domain of interest.

• Describe the relationships among those things.
• Specify how many instances of one entity can be related to another.
• Identify the attributes or characteristics of the entities and relationships.

3-5
© McGraw Hill
 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-6
© McGraw Hill
 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-7
© McGraw Hill
 LO 2

UML Class Diagram - Classes

Classes can represent:
• Organization resources (such as
trucks, machines, buildings, cash,
investments).
• Persons (such as customers,
employees).
• Events (such as sales, purchases,
cash disbursements, cash receipts),
and conceptual structures (accounts, Class symbol used in this
textbook
product categories, budgets, etc.).

3-8
© McGraw Hill
 LO 2

UML Class Diagram - Associations

• Associations depict the (business) relationship between two classes.

3-9
© McGraw Hill
 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-10
© McGraw Hill
 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, that is, 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-11
© McGraw Hill
 LO 2

Primary Keys 1

• 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-12
© McGraw Hill
 LO 2

Primary Keys 2

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 people’s names as primary keys?
• No, since names are not unique.

Should you use phone numbers as primary keys?

• No, since a person’s 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-13
© McGraw Hill
 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.

1..1 0..*
Person owns Auto

3-14
© McGraw Hill
 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 (P K), Quantity_Order, Price]

Inventory [Product_Number (PK), Product_Description, Quantity_on_Hand (Q QH), Unit_of_Issue,

Current_List_Price, Standard_Cost]

3-15
© McGraw Hill
 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-16
© McGraw Hill
 LO 2

Generalization Relationships

Generalization relationships allow grouping of things that share common characteristics. It can reduce redundancy
since the shared characteristics are in the grouped class. For example, general auto characteristics would be in the
Auto class/table and specific characteristics of sports cars, for example, would be in the Sports Car class/table.

3-17
© McGraw Hill
 LO 2

Aggregation and Composition Relationships

Aggregation relationships describe

classes that are usually connected, such
as players on a team. However, players
could exist separately.

Composition relationships describe

classes that are connected, such as
chapters in a book. In this case, chapters
could not exist separately.

3-18
© McGraw Hill
 LO 2

Other Notation

3-19
© McGraw Hill
 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-20
© McGraw Hill
 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-21
© McGraw Hill
 LO 4

1. Map Classes to Tables

3-22
© McGraw Hill
 LO 4

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

© McGraw Hill
 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-24
© McGraw Hill
 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-25
© McGraw Hill
 LO 3

5. Implement Relationships Among Tables

3-26
© McGraw Hill
 LO 5

Decision Requirements

• To understand processes, analysts must recognize decision-making

requirements within the process and establish the business rules that support
those requirements.
• Four steps in understanding the decision-making requirements:
1. Identify decisions required in the process.
2. Describe and document these decisions and how they impact the business objectives
for the process.
3. Specify decision requirements in terms of the information and knowledge required to
make the decision.
4. Decompose and refine the requirements, determining where existing business rules
apply and where new business rules need to be developed.

3-27
© McGraw Hill
 LO 5

Decision Categories
• Eligibility or approval – is this individual or organization eligible for this product or
service?
• Validation – is this claim valid for processing?
• Calculation – what is the correct discount for this product/service for this customer?
• Risk – what is the risk of relying on this supplier’s promised delivery date?
• Fraud – how likely is this claim to be fraudulent?
• Opportunity – which of these options is the best opportunity?
• Assignment – who should this issue be assigned to?
• Targeting – how should we respond to this person?

3-28
© McGraw Hill
 LO 6

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-29
© McGraw Hill
 LO 6

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-30
© McGraw Hill
 LO 6

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-31
© McGraw Hill
 LO 6

Decision Tables
Combine multiple business rules to support decisions.
Decision tables consist of:
• Name.
• Set of inputs.
• Set of outputs.
• Set of rules.

3-32
© McGraw Hill
 LO 3

Decision Table Example

3-33
© McGraw Hill
End of Chapter 3