Chapter 2

Business Rules
©2017 Cengage Learning®. May not be scanned, copied or duplicated, or posted to a publicly accessible website, in whole or in part, except for use as permitted in a license distributed with a certain
product or service or otherwise on a password-protected website or school-approved learning management system for classroom use.
.
 Entities, attributes, relationships
and cardinalities
• https://youtu.be/xNJZYX6tpWU
 Business Rules
• What are business rules?
• What is their source?
• Why are they crucial?
• How business rules influence database
design?
 What are business rules?
Business rules are precisely written and
unambiguous statements that are derived from a
detailed description of an organization's
operations.
When written properly, business rules define one
or more of the following modeling components:
– entities
– relationships
– attributes
– connectivities
– cardinalities – See Topic 2
 Business Rules
• Data don’t explain business, business rules do
• Descriptions of policies, procedures, or principles
within a specific organization
– Apply to any organization that stores and uses data to
generate information
– A pilot should not fly more than 14 hours a day
• Description of operations to create/enforce actions
within an organization’s environment
– Must be in writing and kept up to date
– Must be easy to understand and widely disseminated
• Describe characteristics of data as viewed by the
company
 Business Rules
Brief, precise, and unambiguous description of a
policy, procedure, or principle

Enable defining the basic building blocks

Describe main and distinguishing characteristics

of the data

6
 Discovering Business Rules
• Sources of business rules:
– Company managers
– Policy makers
– Department managers
– Direct interviews with end users
– Written documentation
• Procedures
• Standards
• Operations manuals
 Sources of Business Rules

Company Department
Policy makers
managers managers

Direct
Written
interviews with
documentation
end users

8
 Reasons for Identifying and
Documenting Business Rules
• Standardize company’s view of data
• Communications tool between users and
designers
• Allow designers to
– understand the nature, role, and scope of data
– understand business processes
– develop appropriate relationship participation
rules and constraints
– create an accurate data model
 Translating Business Rules into
Data Model Components
• Generally, nouns translate into entities
• Verbs translate into relationships among
entities
• Relationships are bidirectional
• Two questions to identify the relationship type:
– How many instances of B are related to one
instance of A?
– How many instances of A are related to one
instance of B?
 Naming Conventions
• Naming occurs during translation of business
rules to data model components
• Names should make the entity unique and
distinguishable from other entities
 Naming Conventions
• Entity names - Required to:
– Be descriptive of the objects in the business
environment
– Use terminology that is familiar to the users
• Attribute name - Required to be descriptive
of the data represented by the attribute
• Proper naming:
– Facilitates communication between parties
– Promotes self-documentation
12
 Entities
• An Entity is the thing being modelled.
• It is something that we wish to store information
about.
• It usually is labelled with a noun
• Some examples are Invoice, Order, Transaction,
Customer and Order-line.
• An Entity is identified by placing the name of the entity
inside a box. For example:
 Relationships
This is the relationship between entities. They are shown
by a line linking the two entities. The name of the
relationship is then placed on, or above, the line. For
example, a Customer can place an Order. The relationship
between Customer and Order is shown:

The relationship is not just a one way street from Customer to Order. It can also be
read as Orders are placed by Customers. You need to look at both sides of a
relationship.
Types of relationships
 Cardinality of the relationship
• Cardinality is the numbering of each side of the
relationship that you are drawing. So in this
instance you could ask:
– Can a customer place one or many orders? You may well
decide, based on the business rules, that a customer
could place none, one or many different orders.
• Then you need to ask the question from the other
side of the relationship:
– Can an order be placed by one or many customers?
Again, you may decide that orders could be placed by
many customers.
Cardinality of the relationship
 Optionality
• We use Optionality to determine whether a
relationship can have zero occurrences or
whether an occurrence must exist.

a staff member must belong to one department

each department must have at least one staff member.
Optionality
 Activity 1
A patient staying in a hospital receives medications
that have been ordered by a particular doctor.
Because the patient often receives several
medications per day, there is a 1:M relationship
between PATIENT and ORDER. Similarly, each order
can include several medications, creating a 1:M
relationship between ORDER and MEDICATION.
• Write the business rules for PATIENT, ORDER, and
MEDICATION.
• Create a Crow's Foot ERD that captures these
business rules.
 Activity 2
United Broke Artists (UBA) is a broker for not-so-famous
painters. UBA maintains a small network database to track
painters, paintings, and galleries. A painting is painted by a
particular artist, and that painting is exhibited in a
particular gallery. A gallery can exhibit many paintings, but
each painting can be exhibited in only one gallery.
Similarly, a painting is painted by a single painter, but each
painter can paint many paintings. Using PAINTER,
PAINTING, and GALLERY, in terms of a relational database:
• Write all the business rules
• Create a Crow's Foot ERD that captures these
business rules
 Activity 3

• Using this ERD write all the business rules

Activity 4