Database - Entity Relationship Diagram (ERD)

Entity Relationship Diagram
A complete guide to design ER Diagrams
19-Dec-14 Mudasir Qazi - mudasirqazi00@gmail.com 1

Contents / Agenda
• Definition
• Basic Components
• ERD Representations
• Chen’s Notation Symbols
• Crow’s 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

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 database’s 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.

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 table—not 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 Crow’s Foot notations, an entity is represented by a rectangle containing the entity’s 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 Crow’s 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 Crow’s 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.

ERD Representations
• There are three main notations to represent and ERD
1. The Chen notation favors conceptual modeling.
2. The Crow’s Foot notation favors a more implementation-oriented approach.
3. The UML notation can be used for both conceptual and implementation
modeling.
• Because of its implementation emphasis, the Crow’s 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.

Chen Notation Symbols

Crow’s Foot Notation Symbols

UML Notation Symbols
Primary Keys are followed by [PK]
Foreign Keys are followed by [FK]
Relationships:
Cardinality 1 for ‘One’.
Cardinality * for ‘Many’.

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. Crow’s foot notation is used most of all because its easy to understand in
implementation point of view.

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 existence-dependent if it has a
mandatory foreign key—that 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.

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.

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 part’s serial number, such as SE-08-02-189935, is single-valued, 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 car’s 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
employee’s age, EMP_AGE, may be found by computing the integer value of the difference between the current date and
the EMP_DOB.

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 attribute’s components. For example, the CAR entity’s 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 attribute’s 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).

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.

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

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.

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).

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.

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).

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).”

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 don’t implement the M:N relation by just
giving FKs to each other and the reason is we don’t 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).

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.

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 Ternary Relation Solved into binary relations

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:
minimum cardinality or optionality.
Picture says, one PROFESSOR can teach one (min 1)
or more (max 4) CLASSes but each single (min 1)
CLASS can be taught by one (max 1) PROFESSOR at
time.

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.

Database - Entity Relationship Diagram (ERD)

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (10)

Similaire à Database - Entity Relationship Diagram (ERD)

Similaire à Database - Entity Relationship Diagram (ERD) (20)

Plus de Mudasir Qazi

Plus de Mudasir Qazi (14)

Dernier

Dernier (20)

Database - Entity Relationship Diagram (ERD)