E/R Modeling
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.
1 Entities ....................................................................................................................................................... 3
1.1 simple .................................................................................................................................................. 3
1.2 composite............................................................................................................................................ 3
1.3 subtype/supertype.............................................................................................................................. 3
1.3.1 disjoint.......................................................................................................................................... 4
1.3.2 overlapping .................................................................................................................................. 4
1.4 weak entity.......................................................................................................................................... 4
1
E/R Modeling
1.5 strong entity ........................................................................................................................................ 5
2 Attributes ................................................................................................................................................... 5
2.1 domains............................................................................................................................................... 6
2.2 primary key ......................................................................................................................................... 6
2.3 simple .................................................................................................................................................. 6
2.4 composite............................................................................................................................................ 6
2.5 value .................................................................................................................................................... 6
2.5.1 single-valued ................................................................................................................................ 6
2.5.2 multi-valued ................................................................................................................................. 6
2.5.3 actual............................................................................................................................................ 7
2.5.4 virtual (derived)............................................................................................................................ 7
3 Relationships .............................................................................................................................................. 7
3.1 participants ......................................................................................................................................... 7
3.1.1 optional ........................................................................................................................................ 7
3.1.2 mandatory .................................................................................................................................... 8
3.2 cardinality............................................................................................................................................ 8
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 ............................................................................................................................................ 9
3.3.2 binary ........................................................................................................................................... 9
3.3.3 ternary.......................................................................................................................................... 9
3.3.4 quaternary.................................................................................................................................... 9
3.4 dependence ...................................................................................................................................... 10
3.4.1 existence .................................................................................................................................... 10
3.4.2 conditional ................................................................................................................................. 10
3.5 strength ............................................................................................................................................. 10
3.5.1 weak ........................................................................................................................................... 10
3.5.2 strong ......................................................................................................................................... 11
3.6 recursive ............................................................................................................................................ 11
3.6.1 loop ............................................................................................................................................ 11
2
E/R Modeling
3.6.2 cycle ........................................................................................................................................... 11
4 Modeling representations ....................................................................................................................... 12
4.1 Chen .................................................................................................................................................. 12
4.2 Crow's foot ........................................................................................................................................ 13
4.3 Rein85 ............................................................................................................................................... 13
4.4 IDEFIX ................................................................................................................................................ 14
4.5 CASE tools ......................................................................................................................................... 14
5 Developing a diagram .............................................................................................................................. 14
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
 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.
3
E/R Modeling
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. Sub-types 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'.
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.
4
E/R Modeling
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
 In the Crow’s Foot model, the attributes are simply written in the attribute
box below the entity rectangle
5
E/R Modeling
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.
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:
6
E/R Modeling
 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.
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.
7
E/R Modeling
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.
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.
8
E/R Modeling
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.
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.
9
E/R Modeling
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 existencedependent) on another, then the relationship is 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.
10
E/R Modeling
3.5.2 strong
A strong relationship exists when the related entities are existencedependent.
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.
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.
11
E/R Modeling
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.
12
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.
13
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

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
14
E/R Modeling

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:
1. Different cardinalities
2. Different keys
3. Reverse subset relationships
15