Business Rules

• Statements that define or constrain some

aspect of the business
• Assert business structure
• Control/influence business behavior
• Expressed in terms familiar to end users
• Automated through DBMS software

3
 Scope of Business Rules
• We see business rules in Information
system context. What all fall inside and
what all is outside the scope.

4
 E-R Model Constructs

• Entities:
– Entity instance–person, place, object, event, concept (often
corresponds to a row in a table)
– Entity Type–collection of entities (often corresponds to a table)

• Relationships:
– Relationship instance–link between entities (corresponds to primary
key-foreign key equivalencies in related tables)
– Relationship type–category of relationship…link between entity
types

• Attribute–property or characteristic of an entity or relationship type

(often corresponds to a field in a table)

5
Basic E-R notation (Figure 3-2)

Entity
Attribute
symbols
symbols

A special entity
that is also a Relationship
relationship symbols

Relationship
degrees specify
number of
entity types Relationship
involved cardinalities
specify how
many of each
entity type is
allowed
6
What Should an Entity Be?

• SHOULD BE:
– An object that will have many instances in
the database
– An object that will be composed of multiple
attributes
– An object that we are trying to model
• SHOULD NOT BE:
– A user of the database system
– An output of the database system (e.g., a
report) 7
Figure 3-4 Example of inappropriate entities

System System
user Inappropriate output
entities

Appropriate
entities

8
 Attributes
• Attribute–property or characteristic of an
entity or relationship type
• Classifications of attributes:
– Required versus Optional Attributes
– Simple versus Composite Attribute
– Single-Valued versus Multivalued Attribute
– Stored versus Derived Attributes
– Identifier Attributes

9
 Identifiers (Keys)
• Identifier (Key)–An attribute (or
combination of attributes) that uniquely
identifies individual instances of an entity
type
• Simple versus Composite Identifier
• Candidate Identifier–an attribute that could
be a key…satisfies the requirements for
being an identifier

10
 Characteristics of Identifiers
• Will not change in value
• Will not be null
• No intelligent identifiers (e.g., containing
locations or people that might change)
• Substitute new, simple keys for long,
composite keys

11
Figure 3-7 A composite attribute

An attribute
broken into
component parts

Figure 3-8 Entity with multivalued attribute (Skill)

and derived attribute (Years_Employed)

Multivalued
an employee can have
Derived
more than one skill
from date
employed and
current date
12
Figure 3-9 Simple and composite identifier attributes

The identifier is boldfaced and underlined

13
Figure 3-19 Simple example of time-stamping

This attribute
that is both
multivalued and
composite

14
 More on Relationships

• Relationship Types vs. Relationship

Instances
– The relationship type is modeled as lines between
entity types…the instance is between specific
entity instances
• Relationships can have attributes
– These describe features pertaining to the association between the
entities in the relationship
• Two entities can have more than one type of
relationship between them (multiple
relationships)
• Associative Entity–combination of relationship
and entity 15
Figure 3-10 Relationship types and instances

a) Relationship type

b) Relationship
instances

16
 Degree of Relationships
• Degree of a relationship is the
number of entity types that
participate in it
–Unary Relationship
–Binary Relationship
–Ternary Relationship

17
Degree of relationships – from Figure 3-2

Entities of
One entity two different
related to types related
another of to each other Entities of three
the same different types
entity type related to each
other
18
 Cardinality of Relationships
• One-to-One
– Each entity in the relationship will have
exactly one related entity
• One-to-Many
– An entity on one side of the relationship can
have many related entities, but an entity on
the other side will have a maximum of one
related entity
• Many-to-Many
– Entities on both sides of the relationship can
have many related entities on the other side 19
 Cardinality Constraints
• Cardinality Constraints - the number of
instances of one entity that can or must be
associated with each instance of another
entity
• Minimum Cardinality
– If zero, then optional
– If one or more, then mandatory
• Maximum Cardinality
– The maximum number
20
Figure 3-12 Examples of relationships of different degrees

a) Unary relationships

21
Figure 3-12 Examples of relationships of different degrees (cont.)

b) Binary relationships

22
Figure 3-12 Examples of relationships of different degrees (cont.)

c) Ternary relationship

Note: a relationship can have attributes of its own

23
Figure 3-17 Examples of cardinality constraints

a) Mandatory cardinalities

A patient history is A patient must have recorded

recorded for one and at least one history, and can
only one patient have many

24
Figure 3-17 Examples of cardinality constraints (cont.)

b) One optional, one mandatory

A project must be An employee can be assigned

assigned to at least one to any number of projects, or
employee, and may be may not be assigned to any
assigned to many at all

25
Figure 3-17 Examples of cardinality constraints (cont.)

a) Optional cardinalities

A person is is
married to at most
one other person,
or may not be
married at all

26
Figure 3-21 Examples of multiple relationships

a) Employees and departments

Entities can be related to one another in more than one way

27
 Strong vs. Weak Entities, and
Identifying Relationships
• Strong entities
– exist independently of other types of entities
– has its own unique identifier
– identifier underlined with single-line
• Weak entity
– dependent on a strong entity (identifying owner)…cannot exist on its
own
– does not have a unique identifier (only a partial identifier)
– Partial identifier underlined with double-line
– Entity box has double line
• Identifying relationship
– links strong entities to weak entities

28
 SUMMARY OF ER-DIAGRAM
NOTATION FOR ER SCHEMAS

Symbol Meaning

ENTITY TYPE

WEAK ENTITY TYPE

RELATIONSHIP TYPE

IDENTIFYING RELATIONSHIP TYPE

ATTRIBUTE

KEY ATTRIBUTE

MULTIVALUED ATTRIBUTE

COMPOSITE ATTRIBUTE

DERIVED ATTRIBUTE

29
 Identifying relationship

Strong entity Weak entity

30
 Associative Entities
• An entity–has attributes

• A relationship–links entities together

• When should a relationship with attributes instead be an
associative entity ?
– All relationships for the associative entity should be many
– The associative entity could have meaning independent of the other
entities
– The associative entity may participate in other relationships other
than the entities of the associated relationship
– Ternary relationships should be converted to associative entities

31
Figure 3-11a A binary relationship with an attribute

Here, the date completed attribute pertains specifically to the

employee’s completion of a course…it is an attribute of the
relationship

32
Figure 3-11b An associative entity (CERTIFICATE)

Associative entity is like a relationship with an attribute, but it is

also considered to be an entity in its own right.

Note that the many-to-many cardinality between entities in Figure

3-11a has been replaced by two one-to-many relationships with
the associative entity.
33
 Creating an ERD from the
Investigated Facts
• Identify all the entities.
• Identify all the relationships.
• Identify cardinality and multiplicities (min
max).

34