0% found this document useful (0 votes)
40 views74 pages

DBMS Er

This document provides an overview of entity relationship (ER) modeling techniques. It defines key ER modeling concepts such as entities, attributes, relationships, and cardinality. Entities represent real-world objects like people, places, things. Attributes are properties that describe entities. Relationships define associations between entities. Cardinality specifies the minimum and maximum number of relationships between entities. The document discusses ER modeling approaches like top-down and bottom-up. It also covers advanced ER concepts including generalization, specialization, and different degrees of relationships.

Uploaded by

Shantanu Dash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
40 views74 pages

DBMS Er

This document provides an overview of entity relationship (ER) modeling techniques. It defines key ER modeling concepts such as entities, attributes, relationships, and cardinality. Entities represent real-world objects like people, places, things. Attributes are properties that describe entities. Relationships define associations between entities. Cardinality specifies the minimum and maximum number of relationships between entities. The document discusses ER modeling approaches like top-down and bottom-up. It also covers advanced ER concepts including generalization, specialization, and different degrees of relationships.

Uploaded by

Shantanu Dash
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 74

Unit 2

ER Modeling
Database Design Techniques
Top down Approach
Top down starts by defining the data sets and then define the
data elements within those sets. As a result of this method,
you generally end up with redundant information in one or more
tables.

Some references call this Entity - Relationship modeling.

Bottom Up approach
Bottom up starts by defining the required attributes and then
grouping them to form the entities. Another term used for this
method is normalization from functional dependencies.

2
ER Modeling
Top down Approach

3
ER modeling
• ER modeling: A graphical technique for understanding
and organizing the data independent of the actual
database implementation.
• Entity: Any thing that may have an independent
existence and about which we intend to collect data.
Also known as Entity type. E.g.: Trainee
• Relationships: Associations between entities. E.g.:
Trainee belongs to a Batch
• Attributes: Properties/characteristics that describe
entities.eg: Trainee Name, BatchName, DOB, Address,
etc.

4
Association
between the
instances of one or
more entity types

EntityName Verb Phrase AttributeName

Person, place, object, event named property or


or concept about which data characteristic of an
is to be maintained entity

Represents a set or collection of


objects in the real world that
share the same properties
An Example
Entities
• An entity is a thing in a real-world with independent
existence. An entity can exist independently and is
distinguishable from other objects.
• An Entity is an object of Entity Type and set of all
entities is called as entity set. e.g.; E1 is an entity
having Entity Type Student and set of all students is
called Entity Set.
• Examples of entities:
• Person: EMPLOYEE, STUDENT, PATIENT
• Place: STORE, WAREHOUSE
• Object: MACHINE, PRODUCT, CAR
• Event: SALE,REGISTRATION, RENEWAL
• Concept: ACCOUNT, COURSE
Entity Types

• Regular Entity : Entity that has its own key attribute


(s). Strong entity

E.g.: Employee, student ,customer, policy holder etc.

• Weak entity: Entity that depends on other entity for its


existence and doesn’t have key attribute (s) of its own

E.g. : Kids of employee

8
Attributes
• The set of possible values for an attribute is called the domain
of the attribute
Example:
• The domain of attribute marital status is having four values: single,
married, divorced or widowed.

• The domain of the attribute month is having twelve values ranging


from January to December.

• Key attribute: The attribute (or combination of attributes)


that is unique for every entity instance
• E.g.: the account number of an account, the employee id of an
employee etc.
9
Attribute Type
Types of Attributes Definition Example
Simple attribute Cannot be divided into simpler Gender of the
components employee
Composite attribute Can be split into components Date of joining of the
employee
Single valued Can take on only a single value for Age of the employee
each entity instance

Multi-valued Can take up many values Skill set of the


employee
Stored Attribute Attribute that need to be stored Date of joining of the
permanently employee

Derived Attribute Attribute that can be calculated Years of service of the


based on other attributes. employee

10
Degree of a Relationship
• Degree: the number of entity types involved
• One Unary
• Two Binary
• Three Ternary

E.g.: employee manager-of employee is unary


employee works-for department is binary
customer purchase item, shop keeper is a ternary
relationship

11
Cardinality Ratios
• In ER model, a relationship is an association among entities
(records) of one or more entity sets. Cardinality ratio or
mapping cardinalities is a concept that describes binary
relationship set (a relationship that connects two entity
sets) and its types.
• It is about the maximum number of entities of one entity
set that are associated with the maximum number of
entities of the other entity set.

compiled by Dr Vijay Singh CSE, Graphic Era


12
Deemed to be University, Dehradun
Cardinality
• Relationships can have different connectivity
• one-to-one (1:1)
• one-to-many (1:N)
• many-to- One (M:1)
• many-to-many (M:N)

E.g.:
Employee head-of department (1:1)
Lecturer offers course (1:N) assuming a course is taught by
a single lecturer
Student enrolls course (M:N)
The minimum and maximum values of this connectivity is called the cardinality of the
relationship
13
compiled by Dr Vijay Singh CSE, Graphic Era
14
Deemed to be University, Dehradun
compiled by Dr Vijay Singh CSE, Graphic Era
15
Deemed to be University, Dehradun
Participation constraints in DBMS
This constraint specifies the number of
instances of an entity that are participating
in the relationship type.

There are two types of Participation


constraint: 
• Total participation 
• Partial participation

compiled by Dr Vijay Singh CSE, Graphic Era


16
Deemed to be University, Dehradun
Total participation
constraint
It specifies that each entity present in the entity set
must mandatorily participate in at least one
relationship instance of that relationship set,for this
reason, it is also called as mandatory participation.
It is represented using a double line between the
entity set and relationship set.
Example of total participation constraint 
• It specifies that each student must be enrolled in at
least one course where the “student” is the entity set
and relationship “enrolled in”  signifies total
participation 
• It means that every student must have enrolled at
least in one course

compiled by Dr Vijay Singh CSE, Graphic Era


17
Deemed to be University, Dehradun
Example of total participation constraint

compiled by Dr Vijay Singh CSE, Graphic Era


18
Deemed to be University, Dehradun
Partial participation 
• It specifies that each entity in the entity set may or
may not participate in the relationship instance of
the relationship set, is also called as optional
participation 
• It is represented using a single line between the
entity set and relationship set in the ER diagram 

• Example of partial participation


• A single line between the entities i.e courses and
enrolled in a relationship signifies the partial
participation,which means there might be some
courses where enrollments are not made i.e
enrollments are optional in that case

compiled by Dr Vijay Singh CSE, Graphic Era


19
Deemed to be University, Dehradun
Example of partial participation

compiled by Dr Vijay Singh CSE, Graphic Era


20
Deemed to be University, Dehradun
compiled by Dr Vijay Singh CSE, Graphic Era
21
Deemed to be University, Dehradun
Generalization

compiled by Dr Vijay Singh CSE, Graphic Era


22
Deemed to be University, Dehradun
Specialization

compiled by Dr Vijay Singh CSE, Graphic Era


23
Deemed to be University, Dehradun
Degree of Relationship
Degree of relationship refers to the number of
participating entities in a relationship. If there are
two entities involved in relationship, then it is
referred to as binary relationship. If there are
three entities involved, then it is called as ternary
relationship and so on.
Following are the degrees of Relationships.
1. Single Entity - Unary
2. Double Entities - Binary
3. Triple Entities - Ternary
4. N Entities - N- ary

compiled by Dr Vijay Singh CSE, Graphic Era


24
Deemed to be University, Dehradun
Unary

compiled by Dr Vijay Singh CSE, Graphic Era


25
Deemed to be University, Dehradun
compiled by Dr Vijay Singh CSE, Graphic Era
26
Deemed to be University, Dehradun
Ternary

compiled by Dr Vijay Singh CSE, Graphic Era


27
Deemed to be University, Dehradun
ER Modeling - Notations
ER Modeling -Notations
Entity An Entity is an object or concept about
which business user wants to store
information.
A weak Entity is dependent on another Entity to
Entity
exist. Example Order Item depends upon Order
Number for its existence. Without Order Number
it is impossible to identify Order Item uniquely.

Attribute Attributes are the properties or characteristics


of an Entity

A key attribute is the unique, distinguishing


Attribute
characteristic of the Entity

A multi-valued attribute can have more than


Attribute one value. For example, an employee Entity
can have multiple skill values.

29
ER Modeling -Notations
A derived attribute is based on another attribute. For
Attribute
example, an employee's monthly salary is based on the
employee's basic salary and House rent allowance.

Relationships illustrate how two entities share


Relationship
information in the database structure.

To connect a weak Entity with others, you should


Relationship
Relationship
use a weak relationship notation.

30
ER Modeling -Notations
Customer Cardinality specifies how many instances of an Entity
relate to one instance of another Entity. M,N both
1
represent ‘MANY’ and 1 represents ‘ONE’
Cardinality

1 M
Account Transaction

In some cases, entities can be self-linked.


For example, employees can supervise
other employees

Employee

31
Composite attribute

floor building

DOB
Name Address

E# Designation
Employee

Represented by an ellipse from which other ellipses emanate


and represent the component attributes. E.g Address
32
Unary Relationship

Manages
Employee

•A unary relationship is represented as a diamond which connects


one entity to itself as a loop.
•The relationship above means, some instances of employee
manage other instances of Employee.

33
Role names

• Role names may be added to make the meaning


more explicit subordinate

Manages
Employee

Manager

34
Binary Relationship

Employee Works Department


for

35
Ternary Relationship

Medicine

Doctor Prescription Patient

36
Relationship participation
1 head 1
Employee department
of

partia
l otal
T

• All instances of the entity type Employee don’t participate in the


relationship, Head-of.
• Every employee doesn’t head a department. So, employee entity
type is said to partially participate in the relationship.
• But, every department would be headed by some employee.
• So, all instances of the entity type Department participate in this
relationship. So, we say that it is total participation from the
department side.
since
name dname
ssn lot did budget

Employees 1 1 Departments
Manages

M
Works_In 1

since
Attributes of a Relationship

Medicine

Number of days

dosage

Doctor Prescription Patient

These attributes best describe the relationship prescription rather than


any individual entity Doctor, Patient or Medicine.
39
Weak entity

E# Id name
----

1 has N dependant
Employee

The dependant entity is represented by a double lined rectangle


and the identifying relationship by a double lined diamond

40
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
41
Steps in ER Modeling
• Identify the Entities

• Find relationships

• Identify the key attributes for every Entity

• Identify other relevant attributes

• Draw complete E-R diagram with all attributes including Primary Key

• Review your results with your Business users

Visit the following link for more information


10 Easy Steps to Create an ER Diagram in VISIO 2000 42
Steps in ER Modeling

Step 1: Identify the Entities

• DEPARTMENT

• STUDENT

• COURSE

• INSTRUCTOR

43
Steps in ER Modeling

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.
• The department offers many courses and each course belongs to only
one department, hence the cardinality between department and course
is One to Many.
• 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.
• Each department there is a “Head of department” and one instructor
is “Head of department “,hence the cardinality is one to one .
• 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.

44
Steps in ER Modeling
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

45
Entities
DEPARTMENT LOCATION
NAME

DEPARTMENT

STUDENT

STUDENT DATE OF
STUDENT#
NAME BIRTH
COURSE

PRE COURSE
COURSE# DURATION
REQUISITE NAME

INSTRUCTOR

INSTRUCTOR
TELEPHONE# ROOM#
NAME
48
49
50
Specialization
• A lower-level entity set inherits all the attributes
and relationship participation of the higher-level
entity set to which it is linked.
• A lower-level entity set may have additional
attributes and participate in additional relationships
Specification
• Disjoint/Overlapping
• Completeness constraint
(use double lines)
• total : an entity must
belong to one of the
lower-level entity sets
• partial: an entity need
not belong to one of the
lower-level entity sets
Category owner is the subclass of the set union of entity types person, company and bank
Aggregation
 Consider the ternary relationship works-on, which we saw earlier
 Suppose we want to record managers for tasks performed by an
employee at a branch
E-R Diagram With Aggregation
Design Considerations
• Use of entity sets vs. attributes
• Whether we want to keep additional information
• Use of entity sets vs. relationship sets
• Actions among entities are usually represented by
relationships
• Binary versus n-ary relationship sets
• N-nary relationships are usually more natural for actions
among entity sets
• Weak entity set vs. strong entity set
• Generalization
Notations
Notations
COMPANY ER Schema Diagram
using (min, max) notation
Designing an ER Diagram
Consider the following set of requirements for a University database. Design an ER
diagram for this application:
• The university keeps track of each student's name, student number, social security
number, current address and phone number, permanent address and phone number,
birthdate, sex, class (freshman, graduate), major department, minor department (if
any), degree program (B.A., B.S., ... Ph.D.).  Some user applications need to refer to
the city, state, and zip code of the student's permanent address and to the student's
last name.  Both social security number and student number are unique for each
student. All students will have at least a major department.
• Each department is described by a name, department code, office number, office
phone, and college.  Both the name and code have unique values for each department.
• Each course has a course name, description, course number, number of credits, level
and offering department.  The course number is unique for each course.
• Each section has an instructor, semester, year, course, and section number.  The
section number distinguishes sections of the same course that are taught during the
same semester/year; its value is an integer (1, 2, 3, ... up to the number of sections
taught during each semester).
• A grade report must be generated for each student that lists the section, letter
grade, and numeric grade (0,1,2,3, or 4) for each student and calculates his or her
average GPA.
University ER Diagram
Degree DName DCode OfficeNumber
Name StudentID SSN
Major In
Birth date
OfficePhone
Department
Sex Student
College
Class Minor In

Address

City State Zip


Offer

CName

Grade_Report
CourseDesc
Letter Grade Instructor Year Course
CNumber
GPA
Credits
Numeric Grade Section Belong_To

SectionNumber Semester
ER DIAGRAM FOR A BANK
DATABASE
An ER diagram for an AIRLINE database schema.
Enhanced ER Model
Superclass/Subclass
• Subclasses
• Subgroupings of the entities of an entity type
• An entity type as a superclass of subclasses
• Examples
• EMPLOYEE {SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE}
• PATIENT {OUTPATIENT, INPATIENT}
• STUDENT {FULL-TIME, PART-TIME}
Superclass/Subclass
• “IS-A” relationship
• Members of a subclass must be members of the
superclass
• A FULL-TIME STUDENT ISA STUDENT
• Not every entity in a superclass be a member of
a subclass
• Subclasses
• Should have meaningful subgroupings
• Should be related to database applications
Entity Type Inheritance
• Type Inheritance among Classes
• Inherited Attributes
• a subclass inherits the attributes of the
superclass
• HOURLY_EMPLOYEE (Name, SSN, Address)
• Local (Specific) Attributes
• a subclass may have its own attributes
• HOURLY_EMPLOYEE (Hourly_rate)
• SALARIED_EMPLOYEE (Annual_salary)
EER Example

Entity Type Inheritance


Specialization & Generalization
• superclass-subclass relationship
• Specialization: a means of identifying sub-groups
within an entity set which have attributes which are
not shared by all the entities (top-down)
• Generalization: Multiple entity sets are synthesized
into a higher level entity set based on common
features (bottom-up)
• E-R Symbol:
ISA
Specialization
Generalization
Inheritance
• A lower-level entity set inherits all the attributes of
the higher level entity sets
• A subclass (lower level entity) also inherits
participation in the relationship sets in which its
superclass (higher-level entity) participates.
• The outcome of specialization and generalization is
the same: hierarchy of entity sets.

You might also like