Chpt. 4 E/R Modeling
Chapter 4: E/R Modeling
 How relationships between entities are defined and refined.
 How such relationships are incorporated into the database design
process.
 How ERD components affect database design and
implementation.
 How to interpret the modeling symbols for the four most popular
ER modeling tools.
 Real-world database design often requires you reconcile
conflicting goals.
Chapter 4: E/R Modeling .................................................................................................... 1
1 Entities ............................................................................................................................. 2
1.1 simple ........................................................................................................................ 3
1.2 composite .................................................................................................................. 3
1.3 subtype/supertype ..................................................................................................... 3
1.3.1 disjoint................................................................................................................ 3
1.3.2 overlapping ........................................................................................................ 4
1.4 weak entity ................................................................................................................ 4
1.5 strong entity .............................................................................................................. 4
2 Attributes.......................................................................................................................... 4
2.1 domains ..................................................................................................................... 5
2.2 primary key ............................................................................................................... 5
Chpt. 4 E/R Modeling
2.3 simple ........................................................................................................................ 5
2.4 composite .................................................................................................................. 5
2.5 value .......................................................................................................................... 5
2.5.1 single-valued ...................................................................................................... 5
2.5.2 multi-valued ....................................................................................................... 6
2.5.3 actual .................................................................................................................. 6
2.5.4 virtual (derived) ................................................................................................. 6
3 Relationships .................................................................................................................... 6
3.1 participants ................................................................................................................ 6
3.1.1 optional .............................................................................................................. 7
3.1.2 mandatory .......................................................................................................... 7
3.2 cardinality ................................................................................................................. 7
3.2.1 1:1 ...................................................................................................................... 8
3.2.2 1:N...................................................................................................................... 8
3.2.3 M:N .................................................................................................................... 8
3.3 degree ........................................................................................................................ 8
3.3.1 unary .................................................................................................................. 8
3.3.2 binary ................................................................................................................. 8
3.3.3 ternary ................................................................................................................ 8
3.3.4 quaternary .......................................................................................................... 9
3.4 dependence ................................................................................................................ 9
3.4.1 existence............................................................................................................. 9
3.4.2 conditional.......................................................................................................... 9
3.5 strength ...................................................................................................................... 9
3.5.1 weak ................................................................................................................... 9
3.5.2 strong................................................................................................................ 10
3.6 recursive .................................................................................................................. 10
3.6.1 loop .................................................................................................................. 10
3.6.2 cycle ................................................................................................................. 11
4 Modeling representations ............................................................................................... 11
4.1 Chen ........................................................................................................................ 11
4.2 Crow's foot .............................................................................................................. 12
4.3 Rein85 ..................................................................................................................... 12
4.4 IDEFIX ................................................................................................................... 13
4.5 CASE tools.............................................................................................................. 13
5 Developing a diagram .................................................................................................... 13
6 Resolving conflicts......................................................................................................... 14
1 Entities
 Refers to the entity set and not to a single entity occurrence
 Corresponds to a table and not to a row in the relational
environment
 In both the Chen and Crow’s Foot models, an entity is
represented by a rectangle containing the entity’s name
Chpt. 4 E/R Modeling
 Entity name, a noun, is usually written in capital letters
1.1 simple
A traditional entity. Normally has an atomic primary key. Is not a
composite (bridge) entity.
1.2 composite
A "bridge" entity that is used to handle a M:N relationship. This
entity has the characteristic of having a composite key made up of
the primary keys of both sides of the M:N relationship.
Also known as a "gerund" because it has the characteristics of
entity and relationship. The symbol is a diamond within a rectangle.
1.3 subtype/supertype
A generalization hierarchy depicting the parent- child relationship
that often occurs in complex domains.
The higher level entities are called a supertype and the lower-level
entities are called sub-types. Moving down in the hierarchy is called
specialization while moving up is called generalization.
Sub-type entities inherit attributes of the supertype entity. Subtypes also have unique attributes.
The implied relationship type in a super-type/sub- type hierarchy is
1:1.
1.3.1 disjoint
Disjoint sub-types (non-overlapping sub-types) are ones where
each row of the super-type entity set can appear in only one of the
sub-types.
In other words, the sub-types are mutually exclusive and are
logically connected by a Boolean 'OR'.
Chpt. 4 E/R Modeling
1.3.2 overlapping
Overlapping sub-types are ones where the same row from the
super-type can appear more than once. Thus, the data are stored
in a non-exclusive manner.
1.4 weak entity
An entity that meets 2 conditions:
 It is existence-dependent: that is, it cannot exist without the entity
with which it has a relationship (e.g., hotel room and building)
 It has a primary key that is partially or totally derived from the
parent entity in the relationship.
The existence of a strong relationship between a parent entity and
its related entity is associated with weak entities.
1.5 strong entity
Existence-independence: when an entity can exist apart from its
related entities.
This is the normal case in most E/R diagrams.
2 Attributes
 Characteristics of entities
 In Chen model, attributes are represented by ovals and are
connected to the entity rectangle with a line
 Each oval contains the name of the attribute it represents
Chpt. 4 E/R Modeling
 In the Crow’s Foot model, the attributes are simply written in the
attribute box below the entity rectangle
2.1 domains
The set of possible values that an attribute is allowed to take on.
2.2 primary key
Underlined in the ER diagram
Key attributes are also underlined in frequently used Relational
Notation shorthand
Ideally composed of only a single attribute; however, it is possible to
use a composite key made up of more than one attribute
2.3 simple
An attribute that cannot be divided. The classic "atomic" attribute.
The smallest named unit in the database.
2.4 composite
An aggregate attribute. One that is composed of other atomic and
possibly composite attributes. So, it can be sub- divided into
smaller named pieces that have meaning.
For example, address would have a city, state, and zip component.
Likewise, name could have a last name, first name, and middle
initial attribute component.
2.5 value
Every attribute can take on a value as long as it is within the
attributes domain.
2.5.1 single-valued
The basic attribute value that is not multi- valued.
Chpt. 4 E/R Modeling
Standard "legal" case.
2.5.2 multi-valued
A situation where an attribute holds more than one value.
Not handled in the relational model due to "single value cell" rule.
Solution is to either:
 create multiple attributes in the entity to hold all the values
or
 create a new entity type with the possible value
combinations and link to that table.
2.5.3 actual
Where data are actually stored on the disk drive. In other words,
not virtual (derived) data.
2.5.4 virtual (derived)
Attribute whose value may be calculated (derived) from other
attributes
Does not need to be physically stored within the database
Normally derived using an algorithm
3 Relationships
 A relationship is an association between entity classes.
 The entities that are involved in the relationship are also known as
participants.
 Relationships are named and the name is generally a verb.
 Relationships work in both directions, so the 1:N between
departments and employees could also be thought of as a N:1
between employees and departments.
3.1 participants
The notion of relationship participation deals with the requirement
that entity occurrences be involved in the relationship.
There are two possibilities: optional and mandatory.
Chpt. 4 E/R Modeling
3.1.1 optional
Optional participation occurs if one entity occurrence does not
require a corresponding entity occurrence in a particular
relationship.
That is, it is "optional" that a relationship exist for a specific side of
the relationship.
This is the same concept as the lower- limit of 0 placed on a
relationship.
For example, in the case of COURSE and CLASS relationship, the
relationship is optional for COURSE because there is no
requirement that all courses generate classes. The reverse is not
true.
3.1.2 mandatory
Mandatory participation exists if one entity occurrence requires a
corresponding entity occurrence in a particular relationship.
This is the same concept as existence dependency where a
minimum cardinality of 1 is specified.
As an example, a CLASS requires an INSTRUCTOR be present
for the relationship to exist.
3.2 cardinality
Cardinality is the specific number of entity occurrences that are
allowed to participate in the relationship.
Cardinalities often have upper and lower limits for each side.
The term connectivity is closely associated with cardinality.
Connectivity is used to categorize the type of relationship. The 3
choices are 1:1, 1:N, and M:N. Cardinalities allow more semantic
information to be included.
Business rules and the domain context are used to establish
cardinalities and connectivity.
Chpt. 4 E/R Modeling
3.2.1 1:1
3.2.2 1:N
3.2.3 M:N
3.3 degree
A relationship's degree indicates the number of associated entity
classes involved in the relationship.
3.3.1 unary
A single entity is involved. Implies a recursive relationship.
3.3.2 binary
2 entity classes are involved. The normal case.
3.3.3 ternary
Three entity classes are involved in the relationship.
Chpt. 4 E/R Modeling
3.3.4 quaternary
Four entity classes are involved.
Note, these are note merely 2 sets of a binary relationship.
Instead, they represent a situation where all four entity classes
must simultaneously be present. This degree (and higher) should
be avoided due to potential normalization problems.
3.4 dependence
3.4.1 existence
Existence-dependent: when an entities existence depends on the
existence of one or more other entities.
For example, EMPLOYEE and DEPENDENT share this type of
relationship.
3.4.2 conditional
Conditional existence (also called existence- independence):
when an entity can exist apart from its related entities (also called
a strong entity)
3.5 strength
Strength of a relationship is different from entity strength. This can
be confusing especially when one considers that strong
relationships are generally associated with weak entities.
Generally speaking, a relationship is strong if components of the
primary key are found in the other entity. Conversely, they are
weak when primary key components are not present.
There are 2 types: strong (identifying) and weak (non-identifying).
 Weak (non-identifying) relationships
 One entity is not existence-independent on another entity
 Strong (Identifying) Relationships
 Related entities are existence-dependent
3.5.1 weak
When one entity is not existence-independent (that is, when one is
existence-dependent) on another, then the relationship is
Chpt. 4 E/R Modeling
described as a weak relationship (aka, non-identifying
relationship).
A weak relationship exists when the primary key of the related
entity does not contain any component of the primary key of the
parent entity. For example, COURSE and CLASS can be defined
in this way.
3.5.2 strong
A strong relationship exists when the related entities are
existence-dependent.
A strong relationship exists between two entities whenever the
primary key of the related entity contains a component of the
primary key of the parent entity.
3.6 recursive
A unary relationship is recursive by definition.
It implies that one occurrence of the entity class is directly (or
indirectly) associated with another occurrence of the same entity
class.
3.6.1 loop
A situation where one occurrence of an entity class is directly
related to another occurrence of the same entity class.
Chpt. 4 E/R Modeling
3.6.2 cycle
A type of recursive relationship where one occurrence of an entity
class is indirectly related to another occurrence of the same entity
class.
Indirectly means that one or more other entity classes are in the
path back to the original entity class.
4 Modeling representations
Several variations of E/R modeling diagrams have been developed.
Each has its own advantages and disadvantages.
4.1 Chen
The original Chen notation was developed in 1976. It was very
popular thru the 80's and into the 90's because it provided a simple
graphical way to represent entities and their relationships.
Later extensions to this model have added functionality.
Chpt. 4 E/R Modeling
4.2 Crow's foot
The Crows foot model initially merely removed the diamond
associated with relationships and modified the cardinality notation.
Later, the text filled box notation shown below because popular
because of CASE tools and other drawing packages that
incorporated this capability.
4.3 Rein85
Developed in 1985 by D. Reiner. Similar to Crow's Foot
conventions, but used different symbols. Does not recognize
cardinalities explicitly. Instead, relies on connectivities to
communication cardinality.
Chpt. 4 E/R Modeling
4.4 IDEFIX
Initially developed by Hughes Aircraft for the Air Force. Used as a
general manufacturing data- modeling tool. Has fewer symbols
than other models and hence provides less semantic detail.
4.5 CASE tools
5 Developing a diagram

Database design is an iterative rather than a linear or sequential
process

Iterative process

Starts with limited initial model

Increases complexity (and accuracy) with subsequent
refinements
Chpt. 4 E/R Modeling


Continually updated
Sequential process

Completes initial step

Moves on to next step. Completes each step along the way

No steps are skipped and each must be finished before the
next can happen.
6 Resolving conflicts

Database design must conform to design standards

High processing speeds are often a top priority in database
design
 Quest for timely information might be the focus of database design
 3 Areas of potential conflict:
 Different perspectives - same construct, different
perspective. Resolution solution is to pick a common name
and merge.
 Equivalent constructs - not identical, but one is a sub-set of
the other. Resolve synonyms and hononyms. Merge to
biggest of the two. Change names to match.
 Incompatible constructs - views that are not compatible
(cannot both be correct). Need to find out from source which
is correct and go with that one. Typical examples are:
 Different cardinalities
 Different keys
 Reverse subset relationships