Chapter 4 :

Entity Relationship Modeling

 Forms the basis of an entity relationship diagram (ERD)
 Conceptual database as viewed by end user.
 Database's main components
⁃ Entities
⁃ Attributes
⁃ Relationships

Lucidchart for Crow's Foot Notation (alternatively, use MS Visio or

MySQL Workbench)
ERDplus for Chen's Notation

Entity
 Object of interest to the end user
⁃ Refers to the entity set and not to a single entity
occurrence.
 ERM corresponds to a table-not to a row—in the relational
environment
⁃ ERM refers to a table row as an entity instance or entity
occurrence
 In Chen, Crow's Foot, and UML notations, an entity is
represented by a rectangle that contains the entity's name.
⁃ The entity name, a noun, is usually written in all capital
letters

Characteristics of entities
 Required attribute: must have a value and cannot be left empty
 Optional attribute: does not require a value and can be left
empty
 Domain: set of possible values for a given attribute
 Identifier: one or more attributes that uniquely identify each
entity instance (aka key)
 Composite identifier: primary key composed of more than one
attribute (aka composite key)
  In ER model, In Crow’s foot model required attributes are
highlighted in bold letters. Where are the normal letters are
optional attributes.
 Composite attribute: attribute that can be subdivided to yield
additional attributes
 Simple attribute: attribute that cannot be subdivided
 Single-valued attribute: attribute that has only a single value
⁃ Is a single-valued attribute always a simple attribute? - No
 Multivalued attributes: attributes that have many values

Relational Schema - The organization of a relational database as

described by the database administrator.

Relational Schema: (Alternative 1)

CLASS (CLASS_CODE, CRS _CODE, CLASS_SECTION,
CLASS_TIME, ROOM CODE, PROF_NUM)

Relational Schema: (Alternative 2 - if CLASS_CODE were to be

deleted)
CLASS (CRS_CODE, CLASS_ SECTION, CLASS_TIME,
ROOM_CODE, PROF_NUM)

Requirements of multivalued attributes: Attributes that have many

values and require creating: Eg(car colour)
 Several new attributes, one for each component of the original
multivalued attribute OR
 A new entity composed of the original multivalued attribute's
components

Derived attribute: attribute whose value is calculated from other

attributes. An attribute that does not physically exist within the entity
and is derived via an algorithm. For example, the Age attribute might
be derived by subtracting the birth date from the current date
 Derived using an algorithm
 There is no separate notation in Crow’s foot model to indicate
derived attribute.
 Relationships - Association between entities that always
operate in both directions
 Participants: entities that participate in a relationship.
 Connectivity: describes the relationship classification
⁃ Include 1:1, 1:M, and M:N
 Cardinality: expresses the minimum and maximum number of
entity occurrences associated with one occurrence of related
entity. A property that assigns a specific value to connectivity
and expresses the range of allowed entity occurrences associated
with a single occurrence of the related entity.
⁃ In the ERD, cardinality is indicated by placing the
appropriate numbers beside the entities, using the format
(x, y)s eg: (1,4) or (1,1)

 Existence dependence - Entity exists in the database only when

it is associated with another related entity occurrence.
A property of an entity whose existence depends on one or
more other entities. In such an environment, the existence-
independent table must be created and loaded first because
 the existence-dependent key cannot reference a table that
does not yet exist.
- It should have a mandatory foreign key

 Existence independence – Entity exists apart from all of its

related entities. Referred to as strong entity or regular entity.
Such a table must be created first when referencing an
existence-dependent table.
⁃ It may have a non-mandatory foreign key
 strong entity or regular entity - An entity that is existence-
independent, that is, it can exist apart from all of its related
entities.
⁃ For strong relationship Primary key of the related entity
contains a primary key component of the parent entity

Relationship Strength
 Weak (non-identifying) relationship
⁃ Primary key of the related entity does not contain a
primary key component of the parent entity
⁃ Crow's Foot notation with a dashed relationship line
between entities indicate weak relationship between the
entities.
⁃ Conditions of a weak entity
o Existence-dependent
o Has a primary key that is partially or totally derived
from parent entity in the relationship
o It has foreign key.
o Whenever you have strong relationship the child
entity that has foreign key becomes weak entity.
Foreign key cannot be null.
⁃ Database designer determines whether an entity is weak
based on business rules.
⁃ A strong (identifying) relationship indicates that the related
entity is weak. Such a relationship means that both of the
conditions of weak entity have been met for the weak entity
definition
 Strong relationships or identifying relationship.
  A relationship that occurs when two entities are existence-
dependent; from a database design perspective, this relationship
exists whenever the primary key of the related entity contains
the primary key of the parent entity.
⁃ Primary key of the related entity contains a primary key
component of the parent entity
⁃ Crow's Foot notation with a solid relationship line between
entities represents strong relationship between the entities.

Relationship Participation

 Optional Participation - One entity occurrence does not

require a corresponding entity occurrence in a particular
relationship.
- What is the minimum number of entities that needs to be
present in the relationship ? if it is 0 then it is optional if it
is at least 1 then it is mandatory participation.
 Mandatory Participation - One entity occurrence requires a
corresponding entity occurrence in a particular relationship.

Here (1,1) is (min,max)

(0,N) is (min,max)
| before | in left side indicate 1 required participation
O before multiple relationship on the right indicate 0 required
participation or the participation is optional.
Here | before | in left side indicate 1 required participation
| before multiple relationship on the right indicate 1 required
participation or mandatory participation.

Relationship Strength vs Relationship Participation

 The relationship strength depends on how the PK of the related

entity is formulated
⁃ For example, the relationship between EMPLOYEE and
DEPENDENT is clearly a strong one, but DEPENDENT
is clearly optional to EMPLOYEE
 The relationship participation depends on how the business rule
is written
⁃ For example, the business rules "Each part must be
supplied by a vendor" and "A part may or may not be
 supplied by a vendor" create different optionalities for the
same entities.

Relationship Degree - Indicates the number of entities or participants

associated with a relationship. A relationship degree can be unary,
binary, ternary, or higher.
 Unary relationship: association is maintained within a single
entity
⁃ Recursive relationship: relationship exists between
occurrences of the same entity set. A relationship found
within a single entity type
 Binary relationship: two entities are associated
 Ternary relationship: three entities are associated

Recursive Relationships
 Relationship can exist between occurrences of the same
entity
⁃ Naturally, such a condition is found within a unary
relationship
⁃ Common in manufacturing industries
 One common pitfall when working with unary relationships is to
confuse participation with referential integrity.
⁃ Similar because they are both implemented through
constraints on the same set of attributes

Associative (Composite) Entities or bridge entity

 Used to represent an M:N relationship between two or more
entities
 Has a 1:M relationship with the parent entities
⁃ Composed of the primary key attributes of each parent
entity
 May also contain additional attributes that play no role in
connective process
 Converting M:N relationship into 1:M relationship.

Activities involved in building and ERD

  Create a detailed narrative of the organization's description of
operations
 Identify business rules based on the descriptions
 Identify main entities and relationships from the business rules
 Develop the initial ERD
 Identify the attributes and primary keys that adequately describe
entities
 Revise and review ERD

Database Design Challenges: Conflicting Goals

 Database designers must often make design compromises that are
triggered by conflicting goals
 Database design must conform to design standards
 Need for high processing speed may limit the number and
complexity of logically desirable relationships.
 Need for maximum information generation may lead to loss of
clean design structures and high transaction speed.

ER Modeling

By default all the relationship are considered weak relationships

and all entities are considered strong entities.

Single -valued attribute - An attribute that can have only one value.

Building An ERD involves

Each school is administered by a dean who is a professor. Each
professor can be the dean of only one school, and the professor is not
required to be the dean of any school
1:1 relationship exists between Professor and the School.
Cardinality of Professor is (1,1) and school is (0,1)

Each school has several departments. The smallest number of

departments operated by the school is 1, and largest is N. Each
department belongs to only one school.

Each department may offer many courses, college may have some
department that is classified as research only then it does not offer any
course. The course entity will be Optional to the department.
The relationship of PROFESSOR table to the CLASS table is
Mandatory.
Mandatory (1, N)
Optional (0, N)
Contains only primary key pk – strong entity
Contains pk,fk1 – weak entity
Relationship between strong and weak is strong relationship
Relationship between strong and strong is weak relationship

Minimum cordinality value of zero means that participation of the

related entity is Optional.
Minimum cordinality value 1 means that participation of the related
entity is Mandatory.