Entity Relationship Modeling

Process of Database Design

1. Data Gathering and Analysis Phase – form of a written document containing customer
requirements, mock reports, and screen drawing to indicate the requirements which the
final system is to have. Data must come from variety of internal sources to the company
and analyzed to see if the requirements are necessary, correct, and efficient
o Input: All data gathered from different sources (interviews, records, files)
o Output: Document of collected database requirements (users’ requirements)

2. Conceptual Database Design Phase – takes the requirements and produces a high-level
data model of the database structure. ER modeling is used to represent data models, and it
is independent of the final DBMS in which the database will be installed
o Input: Collated database requirements
o Output: ERD

3. Logical Database Design Phase – the conceptual design phase takes the high-level data
model and converts it into a conceptual schema which is specific to a particular DBMS
class (relational). The ERD in the previous phase is mapped into relational tables for a
relational system. An appropriate conceptual schema would be relations (tables).
o Input: ERD
o Output: Relations

4. Physical Database Design Phase – the conceptual schema is converted into database
internal structure which is specific to a particular DBMS product.
o Input: Relations
o Output: Database

ERM (Entity-Relationship Model)

- Conceptual model that represents the information structure of a problem domain in terms
of entities and relationships
- Developed by Dr. Peter Pin-Shan Chen in 1976
- Used in database modeling and design, systems analysis, and design methodologies, and
computer-aided software engineering
- Result of modeling using the ERM is graphically represented as an entity-relationship
diagram (ERD).

ERD (Entity Relationship Diagram)

- A type of structural diagram for use in database design which contains different symbols
and connectors that visualizes two important information: The major entities within the
system scope, and the inter-relationships among these entities.
- Provides a global quick reference to an organization’s data structures which translates
different views of data among managers, users, and programmers to fit into a common
framework.
Three Elements of Entity-Relationship Diagram

1. Entity
- A person, place, object, event, or concept about which the organization wishes to
maintain data.
- Examples of entities are employee, customer, order, item, student, building,
equipment, account, or course.
- Entity type vs. Entity instance
o Entity type represents a collection of entities that share common
properties or characteristics and described once in the database using meta
data definition. For example, the EMPLOYEE entity type. A single meta
item representing all the instances of the same object.
o Entity instance is a single occurrence of an entity type. For example:
Mary, John, Tom, are 3 instances of the EMPLOYEE entity type.
- When determining entities, think of them as nouns
- What should NOT be an Entity:
o A user/owner of the database system
o An output of the database system (report)

2. Attributes
- Properties or characteristics of an entity. Each entity type has a set of attributes
associated with it.

3. Relationship
- Relationship Types vs. Relationship Instance
o Relationship Type is a meaningful association between or among entity
types.
o Relationship Instance is the association between specific entity instances
- When determining relationships, think of them as verbs or verb phrases.
ERD Notations

- Modeling notation is a set of graphical elements (instructions how to use them)

that help represent the structure of the data set.
- ERD is created using some notation to represent graphically the list of
requirements and business rules of data organizational structure.

1. Chen Notation
- Introduced by Peter Chen and was one of the pioneers in software and
information system modeling and design.
- Is still used and considered to present a more detailed way of representing entities
and relationships

2. Crow’s Feet Notation

- Used in Barker’s Notation, SSADM and Information Engineering.
- Represent entities as boxes and relationships as lines between the boxes.
- Different shapes at the ends of these lines represent the cardinality of the
relationship
- Used due to its simplicity

Chen Notation for Entity

- Represented by a rectangle that contains the entity’s name. The name is singular
rather than plural.

Types of Entities

1. Entity / Strong Entity – all entities are considered strong entities unless specified as
weak.

2. Weak Entity – cannot be uniquely identified by its attributes alone and its existence is
dependent upon another strong entity called the owner entity. The weak entity’s identifier
is a combination of the identifier of the owner entity and the partial key of the weak
entity.
 3. Associative Entity – used in a many-to-many relationship (represents an extra table in a
relational database). All relationships for the associative entity should be in “many” form.

Crow’s Foot Notation for Entity

- Represented by a rectangle, with its name on the top and the name is singular
rather than plural.

Chen Notation and Crow’s Foot Notation for Attributes

- In Chen Notation, each attribute is represented by an oval containing the

attribute’s name and are linked to the entity with straight lines.
- In Crow’s Foot notation, attributes are written in the attribute box below the entity
rectangle.

Types of Attributes

1. Key Attribute
- Uniquely identifies a particular entity and the name of a key attribute is
underlined.
- In Crow’s Foot Notation, it is indicated with PF or FK depending on, if the key
attribute is a primary key or foreign key
2. Partial Key Attribute (discriminator)
- Attribute of the weak entity that when combined with the key attribute of the
parent entity, provides a unique identification for the weak entity.
- Chen Notation underlines the discriminator with a dashed line
- Crow’s Foot Notation, the key attribute of the weak entity becomes composite,
constituting the key attributes of the parent’s and the child’s

3. Multivalued Attribute
- Attribute that can have many values (college degrees, different phones, hobby)
- In Chen Notation, it is depicted by a dual oval
- In Crow’s Foot Notation, a new entity is created in a one-to-many relationship
with the original entity and is composed of the composite key attributes
(parent+child key attributes) and supposed multivalued attribute components
4. Derived Attribute (computed attribute)
- Value is calculated (derived) from other attributes
- May or may not be physically stored in the database
- In Chen Notation, it is represented by a dashed oval.

5. Composite Attribute
- Attribute that can be further divided into smaller parts
Relationships

- In Chen Notation, it is represented by a diamond (rhombus) containing the

relationship’s name

Types of Relationships

1. Strong Relationship – relationship where the entity is strong and independent of other
entities and the Primary Key of child entry does not contain the PK component of the
parent entity and represented by a single rhombus
2. Weak Relationship / Identifying Relationship – child entity is existence-dependent on
the parent entity, and PK of Child Entity contains PK component of Parent Entity and
represented by a double rhombus.

- In Crow’s Foot Notation, relationship types are presented as a straight line and
each relationship has a name, expressed as a verb, or verb phrase
Types of Cardinal Relationships

1. One-to-One Relationship – each entity instance in one side of the relationship will have
exactly one related entity instance on the other side of the relationship

2. One-to-Many Relationship – maximum of one entity instance on one side and more
than one related entity instances on the other side.

3. Many-to-One Relationship – more than one entity instances on one side and a
maximum of one entity instance on the other side

4. Many-to-Many Relationship – entities on both side can have more than one related
entity
Relationship Participation

1. Optional Participation – one entity occurrence does not require a corresponding entity
occurrence in a particular relationship
2. Mandatory Participation – one entity occurrence requires a corresponding entity
occurrence in a particular relationship

Cardinality Constraints

-
States the limit of the number of entity occurrences/participations that are
associated in a relationship.
1. Minimum Cardinality
o If zero, then relationship participation is optional
o If one or more, then relationship participation is mandatory
2. Maximum Cardinality
o The maximum number of participations of entity instances in a relationship

Degree of Relationship – number of entity types that participated in the relationship

1. Unary Relationship
- Recursive relationship. The same entity participates more than once in different
roles.
 2. Binary Relationship
- Two entities are associated in a relationship
- Most common type of relationship
- Most higher-order (ternary and higher) relationships are decomposed into
appropriate equivalent binary relationships whenever possible.

3. Ternary Relationship
- Higher-order relationships allow the designer some latitude regarding the
semantics of a problem
- Implies an association among three different entities

Steps to Create an ERD

1. Entity Identification

2. Relationship Identification
 3. Cardinality Identification

4. Attributes Identification

5. You Created your ERD

Sample ERD