Dbms

You might also like

Download as ppt, pdf, or txt
Download as ppt, pdf, or txt
You are on page 1of 45

ENTITY

RELATIONSHIP
DIAGRAM

An entity relationship diagram is a graphical


representation of an organisation's data
storage requirements
E-R-D are used to:
Identify the data that must be captured,
stored and retrieved in order to support
the business
Activities performed by an organisation
Identify the data required to derive and
report on the performance measures, that
an organisation should be monitoring

Entity relationship diagrams have three


different components:

ENTITIES
ATTRIBUTES
RELATIONSHIPS

Entity

Entities are the people, places, things,


events and concepts of interest to an
organisation.
Represented as Rectangle
Book
Project
Publisher
Job
Company
File

Attribute
Properties or characteristics possessed by

an entity are called as attributes


Represented as ellipse.
Attributes of EMPLOYEE entity set :
Name
Age
Employee_id
Salary

Domain
The set of possible values for an attribute is
called the domain of the attribute.
The domain of attribute marital status is
just the four values: single, married,
divorced, widowed.
The domain of the attribute month is the
twelve values ranging from January to
December.

Simple v/s Composite attribute


Simple attribute: An attribute that cannot
be divided into simpler components
e.g. age of an employee, pub-id of a book,
title of a book.
Composite attribute: An attribute that can
be split into components e.g. Date of
joining of the employee can be split into
day, month and year

Single v/s Multi-valued Attribute


Single valued : Attributes that can take on
only a single value for each entity instance.
e.g. age of employee, pubid of a publisher
Multi-valued: Attributes that can take many
values for each entity instance.
e.g. skill set of employee

Stored v/s Derived attribute


Stored Attribute: Attribute that need to be
stored permanently.
e.g. : Name of an employee
Derived Attribute: Attribute that can be
calculated based on other attributes.
e.g. : Years of service of employee can be
calculated from date of joining and current
date

Attributes
F lo o r
C o m p o s ite
A ttr ib u te

S tre e t
B u ild in g

D O B

A d d re ss
D e r iv e d
A ttr ib u te
A ge

N am e

E #

K e y A ttr ib u te

E m p lo y e e

S k ills

M u lti V a lu e d
A ttr ib u te

Relationship
Defines the set of all associations between
two entity types.
Represented as Rhombus
Example:
EMPLOYEEs work in a DEPARTMENT
LAWYERs advise CLIENTs
EQUIPMENT is allocated to PROJECTs
TRUCK is a type of VEHICLE

Degree of a Relationship
The number of entities associated with the
relationship.
One Unary
employee - manager-of - employee
Two Binary
employee - works-for department
Three Ternary
customer purchase- item

Unary Relationship

E m p lo y e e

M anages

Binary Relationship

E m p lo y e e

W o r k s fo r

D e p a r tm e n t

Ternary Relationship
M e d ic in e

D o c to r

P re s c rip tio n

P a tie n t

Cardinality and Connectivity


The cardinality of a relationship is the
actual number of related occurrences for
each of the two entities
one-to-one (1:1)
one-to-many (1:N)
many-to- one (M:1)
many-to-many (M:N)

one-to-one (1:1)
when at most one instance of a entity A is
associated with one instance of entity B
E 1

C 1

E 2

C 2

E 3

C 3

E 4

C 4

E M P LO YE E

C H A IR

one-to-many (1:N)
when for one instance of entity A, there are zero, one, or
many instances of entity B, but for one instance of entity
B, there is only one instance of entity A
E 1
O 1
O 2
O 3

E 2
E 3
E 4
E 5

O R G A N IZ A T IO N

E M P LO YE E

many-to- One (M:1)


When for zero, one or many instances of entity A, there
is only one instance of entity B , but for one instance of
entity B, there is only one instance of entity A
E1
E2
E3
E4

D 1
D 2
D 3

E5
EM PLO YEE

D E PA R T M E N T

many-to-many (M:N)
when for one instance of entity A, there are zero, one, or
many instances of entity B and for one instance of entity
B there are zero, one, or many instances of entity A

E 1

P1

E2

P2

E 3

P3

E4

P4

EM PO LYEE

P R O JE C T

Cardinality
We express cardinality constraints by
drawing either a directed line (),
signifying one, or an undirected line (),
signifying many, between the relationship
set and the entity set.

One-to-One Relationship
A customer is associated with at most one
loan via the relationship borrower
A loan is associated with at most one
customer via borrower

One-To-Many Relationship
In the one-to-many relationship a loan is
associated with at most one customer via
borrower, a customer is associated with
several loans via borrower

Many-To-One Relationships
In a many-to-one relationship a loan is
associated with several customers via
borrower, a customer is associated with at
most one loan via borrower

Many-To-Many Relationship
A customer is associated with several
loans via borrower
A loan is associated with several
customers via borrower

Participation of an Entity Set in


a Relationship Set
Total participation (indicated by double line): every entity in the entity set

participates in at least one relationship in the relationship set


E.g. participation of loan in borrower is total

every loan must have a customer associated to it via borrower


Partial participation: some entities may not participate in any relationship in

the relationship set

E.g. participation of customer in borrower is partial

Case Study ER Model For a


college DB
Assumptions :

A college contains many departments


Each department can offer any number of courses
Many instructors can work in a department
An instructor can work only in one department
For each department there is a Head
An instructor can be head of only one department
Each instructor can take any number of courses
A course can be taken by only one instructor
A student can enroll for any number of courses
Each course can have any number of students

Steps in ER Modeling
Step 1: Identify the Entities
Step 2: Find the relationships
Step 3: Identify the key attributes
Step 4: Identify other relevant attributes
Step 5: Draw complete E-R diagram
with all attributes including Primary
Key

Case Study
Banking Business Scenario
Assumptions :
There are multiple banks and each bank
has many branches. Each branch has
multiple customers
Customers have various types of accounts
Some Customers also had taken different
types of loans from these bank branches
One customer can have multiple accounts
and Loans

Step 1: Identify the Entities


DEPARTMENT
STUDENT
COURSE
INSTRUCTOR

Step 2: Find the relationships


One course is enrolled by multiple students and one student enrolls for multiple
courses, hence the cardinality between course and student is Many to Many.
M

COURSE

ENROLLED BY

STUDENT

The department offers many courses and each course belongs to only one
department, hence the cardinality between department and course is One to
Many.
1
DEPARTMENT

M
COURSE

OFFERS

One department has multiple instructors and one instructor belongs to one and
only one department , hence the cardinality between department and instructor
is one to Many.

DEPARTMENT

HAS

INSTRUCTOR

Step 2: Find the relationships(Cont..)


Each department there is a Head of department and one instructor is
Head of department ,hence the cardinality is one to one .
1
DEPARTMENT

1
INSTRUCTOR

HEADED BY

One course is taught by only one instructor, but the instructor teaches
many courses, hence the cardinality between course and instructor is
many to one.
COURSE

32

INSTRUCTOR

OFFERS

Step 3: Identify the key attributes


Deptname is the key attribute for the Entity Department, as it
identifies the Department uniquely.
Course# (CourseId) is the key attribute for Course Entity.
Student# (Student Number) is the key attribute for Student
Entity.
Instructor Name is the key attribute for Instructor Entity.

Step 4: Identify other relevant attributes


For the department entity, the relevant attribute is location
For course entity, course name, duration,prerequisite
For instructor entity, room#, telephone#
For student entity, student name, date of birth

33

Draw ERD
ER Diagram for the University

Reduction of an E-R Schema


to Tables
Converting relationships
Unary 1:1 The primary key field
itself will become the foreign key in
the table

Converting relationships
Binary 1: 1: The primary key
of either of the entities can
become a foreign key in the
other.

Converting relationships
Binary 1: N: The primary key of the
1 side of the relationship
becomes a foreign key in the
relation on the N side

Converting relationships
Binary M: NA new table is created to represent
relationship
Contains two foreign keys one from
each of participating entities
The primary key of new table is the
combination of two foreign keys

Converting relationships

Converting relationships
Ternary relationship:
A new table is created to represent
relationship
The new table contains three foreign keysone from each of the participating entities
The primary key of new table is the
combination of all three foreign keys

THANK YOU

You might also like