Entity Relationship

Diagram
A complete guide to design ER Diagrams

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

Contents / Agenda
Definition
Basic Components
ERD Representations
Chens Notation Symbols
Crows foot Notation Symbols
UML Notation Symbols

Type of Entities
Types of Attributes
How to solve multivalued attributes

Types of Relationships
Implementation of 1:1
Implementation of 1:M
Implementation of M:M

Connectivity and Cardinalities

Summary
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

Definition
The Relational Database Model (ERM-database
containing tables) forms on the basis of an ERD. The
ERD represents the conceptual database as viewed by
the end user.
ERDs depict the databases main components: entities,
attributes, and relationships. Because an entity
represents a real-world object, the words entity and
object are often used interchangeably. Thus, the entities
(objects) of the Tiny College database design (mostly
discussed in these slides) include students, classes,
teachers and classrooms.
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

Basic Components of ERD

Entities:
An entity is an object of interest to the end user. At the ER modeling level, an entity actually refers to the entity set
and not to a single entity occurrence. In other words, the word entity in the ERM corresponds to a tablenot to a row
in the relational environment. The ERM refers to a table row as an entity instance or entity occurrence.
In both the Chen and Crows Foot notations, an entity is represented by a rectangle containing the entitys name. The
entity name, a noun, is usually written in all capital letters.

Attributes:
Attributes are characteristics of entities. For example, the STUDENT entity includes, among many others, the attributes
STU_LNAME, STU_FNAME, and STU_INITIAL. In the original Chen notation, 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 Crows Foot notation, the attributes are written in the attribute box below the entity rectangle. Because the
Chen representation is rather space-consuming, software vendors have adopted the Crows Foot style attribute display.

Relationships:
A relationship is an association between entities. The entities that participate in a relationship are also known as
participants, and each relationship is identified by a name that describes the relationship. The relationship name is an
active or passive verb; for example, a STUDENT takes a CLASS, a PROFESSOR teaches a CLASS and an AIRCRAFT is
flown by a CREW.
Relationships between entities always operate in both directions. That is, to define the relationship between the
entities named CUSTOMER and INVOICE, you would specify that:
1. A CUSTOMER may generate many INVOICEs.
2. Each INVOICE is generated by one CUSTOMER.

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

ERD Representations
There are three main notations to represent and ERD
1. The Chen notation favors conceptual modeling.
2. The Crows Foot notation favors a more implementationoriented approach.
3. The UML notation can be used for both conceptual and
implementation modeling.

Because of its implementation emphasis, the Crows

Foot notation can represent only what could be
implemented.
We will also be using a new Short Hand notation that is
easy to understand and takes less place.
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

Chen Notation Symbols

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

Crows Foot Notation Symbols

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

UML Notation Symbols

Primary Keys are followed
by [PK]
Foreign Keys are followed
by [FK]
Relationships:
Cardinality 1 for One.
Cardinality * for Many.

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

Advantages and Usage

Advantages:
1. ERD tells us that how many tables you need and what would
be the relationship between them (you also have to do
Normalization to know finally how many tables would be in
your database but still first step is ERD).
2. ERD is simple and understandable representation of a
database. It helps a lot to understand the whole database.

Usage:
1. An ERD leads to ERM, means when ever you need to build a
database with tables, firstly, you need to create an ERD.
2. Crows foot notation is used most of all because its easy to
point of view.
19-Dec-14 understand in implementation
Mudasir Qazi - mudasirqazi00@gmail.com

Types of Entities
Existence Dependent
An entity is said to be existence-dependent if it can exist in the
database only when it is associated with another related entity
occurrence. In implementation terms, an entity is existencedependent if it has a mandatory foreign keythat is, a foreign key
attribute that cannot be null.
Existence Independent.
If an entity can exist apart from one or more related entities, it is
said to be existence-independent (Sometimes designers refer to
such an entity as a strong or regular entity). Here foreign key
attribute can be null.
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

10

Types of Attributes (1)

Required
A required attribute is an attribute that must have a value; in other words, it cannot be left
empty.

Optional
An optional attribute is an attribute that does not require a value; therefore, it can be left
empty.

Domains
Attributes have a domain, a domain is the set of possible values for a given attribute. For
example, the domain for the grade point average (GPA) attribute is written (0,4) because the
lowest possible GPA value is 0 and the highest possible value is 4. The domain for the gender
attribute consists of only two possibilities: M or F (or some other equivalent code).

Identifiers
The ERM uses identifiers, that is, one or more attributes that uniquely identify each entity
instance. In the relational model, such identifiers are mapped to primary keys (PKs) in tables.
There are Simple(Primary Key) and Composite (Composite Key) identifiers.
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

11

Types of Attributes (2)

Composite
A composite attribute, not to be confused with a composite key, is an attribute that can be further subdivided to yield
additional attributes. For example, the attribute ADDRESS can be subdivided into street, city, state, and zip code.

Simple
A simple attribute is an attribute that cannot be subdivided. For example, age, sex, and marital status would be
classified as simple attributes.

Single-Valued
A single-valued attribute is an attribute that can have only a single value. For example, a person can have only one
Social Security number, and a manufactured part can have only one serial number. Keep in mind that a single-valued
attribute is not necessarily a simple attribute. For instance, a parts serial number, such as SE-08-02-189935, is singlevalued, but it is a composite attribute because it can be subdivided into the region in which the part was produced
(SE), the plant within that region (08), the shift within the plant (02), and the part number (189935).

Multi-Valued
Multivalued attributes are attributes that can have many values. For instance, a person may have several college
degrees, and a household may have several different phones, each with its own number. Similarly, a cars color may
be subdivided into many colors (that is, colors for the roof, body, and trim).

Derived
A derived attribute is an attribute whose value is calculated (derived) from other attributes. The derived attribute
need not be physically stored within the database; instead, it can be derived by using an algorithm. For
example, an employees age, EMP_AGE, may be found by computing the integer value of the difference between the
current date and the EMP_DOB.

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

12

How to Solve Multi-Valued attributes

(1)
Although the conceptual model can handle M:N relationships and
multivalued attributes, you should not implement them in the RDBMS.
Because in the relational table, each column/row intersection represents a
single data value. So if multivalued attributes exist, the designer must
decide on one of two possible courses of action:
1. Within the original entity, create several new attributes, one for each of the
original multivalued attributes components. For example, the CAR entitys
attribute CAR_COLOR can be split to create the new attributes CAR_TOPCOLOR,
CAR_BODYCOLOR, and CAR_TRIMCOLOR, which are then assigned to the CAR
entity. (Not good).
2. Create a new entity composed of the original multivalued attributes components.
The new (independent) CAR_COLOR entity is then related to the original CAR
entity in a 1:M relationship. Note that such a change allows the designer to define
color for different sections of the car like top, body, interior etc. (Best solution).
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

13

How to Solve Multi-Valued attributes

(2)
Entity CAR contains a
multivalued attribute
CAR_COLOR.
Solution 1: (Not good)
Solution to Multi-Valued
attribute by adding new
attributes to CAR entity.

Solution 2: (Best)
Solution to Multi-Valued
attribute by adding new
entity with 1:M relation to
CAR entity.
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

14

Relationships
Ways of Classifying Relationships Types
A relationship type can be classified by thenumber of entity types involved, and by
thedegreeof the relationship type.
Following is a brief picture showing all types of relationships.

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

15

Types of Relationships (1)

One-to-One
When both participants can have only one instance of each other. (less used but
stable).
For Example, HUSBAND can have only one WIFE and WIFE can have only one
HUSBAND. This is 1:1 relationship between HUSBAND and WIFE participants.

One-to-Many
When one participant can have multiple instances of other participants but other
participant can have only one instance of first participants. (mostly used and stable).
For Example, CUSTOMER may generate many ORDERs but each ORDER is generated
by one CUSTOMER. This is 1:M relation between CUSTOMER and ORDER.

Many-to-Many
When both participants can have multiple instances of each other. (not practice).
For Example, STUDENT can be enrolled in many SUBJECTs and one SUBJECT can be
chosen by many STUDENTs. This is M:M relation between STUDENT and SUBJECT.
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

16

Types of Relationships (2)

Weak relationship
Also known as a non-identifying relationship, exists if the PK of the related entity does not
contain a PK component of the parent entity. By default, relationships are established by
having the PK of the parent entity appear as an FK on the related entity (implemented in
right picture).

Strong relationship
Also known as an identifying relationship, exists when the PK of the related entity
contains a PK component of the parent entity (implemented in left picture).

Recursive relationship
A recursive relationship is one in which a relationship can exist between occurrences of
the same entity set (Naturally, such a condition is found within a unary relationship).

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

17

Relationships (1:1) Implementation

(1)
An example of a one-one relationship type is a person and his or her birth

certificate. We assume that everyone has one and that a certificate registers the
birth of one person only.
Where there is a one-one relationship type we have the option of merging the
two entity types. The birth certificate attributes may be considered as attributes
of the person and placed in the person entity type. The birth certificate entity
type would then be removed.
There are two reasons for not merging them:
1. The majority of processing involving PERSON records might not involve any or many of
the BIRTH_CERTIFICATE attributes. The BIRTH_CERTIFICATE attributes might only be
subject to very specific processes which are rarely executed.
2. the BIRTH_CERTIFICATE entity type has relationship types to other entity types that the
PERSON entity type does not have. The two entity types have different relationship types
to other entity types.

Merging is not very harmful practically. so, its just a matter of choice which
implementation you want.
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

18

Relationships (1:1) Implementation

(2)
Following is implementations for 1:1 relationship.
One table has PK and other table must have same PK
as well as FK.
Department Table has Department_ID as
PK.
And Manager Table must have
Department_ID as PK as well as FK (You
can change the name of column but it
should have same data).

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

19

Relationships (1:M) Implementation

The common column is DEPARTMENT_ID (which is the
primary key in the DEPARTMENT table) should be as a
foreign key in the EMPLOYEE table. One individual
DEPARTMENT_ID can relate to many rows in the
EMPLOYEE table.
Business Rule for this is:
one department can relate to
one or many employees (or
even no employees) and that an
employee is associated with
only one department (or, in
some cases, no department).

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

20

Relationships (M:N)
Implementation (1)
Consider the EMPLOYEE and PROJECT tables. The business rule is as
follows: One employee can be assigned to multiple projects, and one
project can be supported by multiple employees. Therefore, it is
necessary to create an M:M relationship to link these two tables.
In the relational database we dont implement the M:N relation by just
giving FKs to each other and the reason is we dont want two sided
links (circles). So, we create a new entity called Bridge Entity and its
PK is a composite key made up with PKs of both tables. It may or may
not have any other attributes but composite key is must.
After doing this, there becomes two 1:M relations.
1. One between Bridge and EMPLOYEE table (1:M).
2. One between Bridge and PROJECT table (1:M).
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

21

Relationships (M:N)
Implementation (2)
In this example we made Bridge
Table under name
EMPLOYEE_PROJECT containing
PKs of both above tables. It has
one more attribute for some
extra information.
Now, it becomes like this and
we have three tables now.

19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

22

Removing Ternary and Hire order

relations
It is advantageous (but not necessary) to remove ternary and higher order
relationship types. One reason is that it might be considered more `natural' to
think of entity types having attributes than relationship types having them. It
is in fact always possible to remove these high-order relationship types and
replace them with an entity type. A ternary relationship type is then replaced
by an entity type and three binary relationship types linking it to the entity
types which were originally linked by the ternary. A quaternary relationship
type would be replaced by an entity type and four relationship types and so
on.

Ternary
Relation
19-Dec-14

Ternary Relation Solved into binary

relations
Mudasir Qazi - mudasirqazi00@gmail.com

23

Connectivity and Cardinalities

Connectivity:
The term connectivity is used to describe the relationship classification. Just
to show the relation existence and type of relation between entities.

Cardinalities:
Cardinality expresses the minimum and maximum number of entity
occurrences associated with one occurrence of the related entity. In the ERD,
cardinality is indicated by placing the appropriate numbers beside the
entities, using the format (min , max).
1. Cardinality / mandatory:
maximum cardinality.
2. Modality / optional:
Picture says, one PROFESSOR can teach
minimum cardinality or optionality.
one (min 1) or more (max 4) CLASSes but
each single (min 1) CLASS can be taught
by one (max 1) PROFESSOR at time.
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

24

Summary
Following are main steps to create an ERD
1. Decide what are the entitles in your database.
2. Decide attributes for each entity.
3. Describe relationships between entities.
1. If there is any M:N relation, solve it into 1:M relationships.

Note: ERD will not output a complete blue print to your

database until you do its Normalization. But, ERD +
Normalization will give you complete set of tables,
attributes and relationships you need in your database.
19-Dec-14

Mudasir Qazi - mudasirqazi00@gmail.com

25