0% found this document useful (0 votes)
64 views

Entity-Relationship Model: UCS310:DBMS 1

The document provides an overview of the entity-relationship (ER) model for database design. It describes the key components of the ER model including entities, relationships, attributes, and ER diagram notation. Entities represent real-world objects, relationships define associations between entities, and attributes describe properties of entities. The document also covers ER modeling concepts such as cardinality, connectivity, weak/strong entities, generalization, and specialization. The ER model is a conceptual modeling technique that is useful for database design.

Uploaded by

Tania CE
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
64 views

Entity-Relationship Model: UCS310:DBMS 1

The document provides an overview of the entity-relationship (ER) model for database design. It describes the key components of the ER model including entities, relationships, attributes, and ER diagram notation. Entities represent real-world objects, relationships define associations between entities, and attributes describe properties of entities. The document also covers ER modeling concepts such as cardinality, connectivity, weak/strong entities, generalization, and specialization. The ER model is a conceptual modeling technique that is useful for database design.

Uploaded by

Tania CE
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 32

Entity-Relationship

Model

UCS310:DBMS 1
How to design the
database?
There are two approaches
 E-R Modeling: Identifying entity and
relations
 Normalization: Refinement of database
designing

UCS310:DBMS 2
Entity-Relationship Model

UCS310:DBMS 3
E-R Model
 The Entity-Relationship (ER) model was
originally proposed by Peter in 1976
 The ER model is a conceptual data model
that views the real world as entities and
relationships.
 A basic component of the model is the
Entity-Relationship diagram, which is used
to visually represent data objects.

UCS310:DBMS 4
Basic Constructs of E-
R Modeling
 Entities
 Entities are the principal data object about which
information is to be collected. Entities are usually
recognizable concepts, either concrete or
abstract, such as person, places, things, or
events, which have relevance to the database.
Some specific examples of entities are
EMPLOYEES, PROJECTS, and INVOICES. An
entity is analogous to a table in the relational
model.

UCS310:DBMS 5
Relationships

A Relationship represents an association between two or more


entities. Relationships are classified in terms of degree,
connectivity, cardinality, and existence. An example of a
relationship would be:
¨ Employees are assigned to projects
¨ Projects have subtasks
¨ Departments manage one or more projects

UCS310:DBMS 6
Attributes
Attributes describe the properties of the entity of which they are
associated. A particular instance of an attribute is a value. For
example, "Ram" is one value of the attribute Name. The domain
of an attribute is the collection of all possible values an
attribute can have.
We can classify attributes as following:
¨ Simple
¨ Composite
¨ Single-values
¨ Multi-values
¨ Derived

UCS310:DBMS 7
Attributes
1. Simple Attributes : A simple attribute is an attribute
composed of a single component with an independent
existence. Simple attributes cannot be further
subdivided. Examples: Age, Salary etc.

2. Composite Attributes: An attribute composed of multiple


components, each with an independent existence is called a
composite attribute. Some attributes can be further divided
to yield smaller component with an independent existence
of their own. For example, the name as an attribute can be
further sub-divided into first_name, middle_name,
last_name. Similarly, the address attribute can be further
into street, city, state, postal code etc.

UCS310:DBMS 8
Attributes
3. Single-valued Attribute: A single-valued attribute is
one that holds a single value for a single entity. The
majority of attributes are single-valued for a particular
entity. For example, the classroom entity has a single
value for the room_number attribute and therefore, the
room_number attribute is referred to be as being single-
valued.
4. Multi-valued Attribute: A multi-valued attribute is
one that holds multiple values for a single entity. For
example, a student entity can have multiple values for
the Hobby attribute – reading, music, movies and so on.
This attribute may have set of numbers with upper and
lower limits. For example, a student can have minimum
1 hobby and maximum 5 hobbies.
UCS310:DBMS 9
Attribute
Derived Attribute: A derived attribute is one that represents a
value that is derivable from the value of a related attribute or
set of attributes, not necessary in the same entity. Some
attributes may be related to a particular entity. For example,
the Age attribute can be derived from date-of-birth attribute
and therefore they are related. We refer the age attribute as a
derived attribute.

UCS310:DBMS 10
Degree of a Relationship

The degree of a relationship is the number of entities associated


with the relationship. The n-ary relationship is the general form
for degree n. Special cases are the binary, and ternary, where the
degree is 2, and 3, respectively. Binary relationships, the
association between two entities are the most common type in
the real world. A recursive binary relationship occurs when an
entity is related to itself. An example might be "some employees
are married to other employees". A ternary relationship involves
three entities and is used when a binary relationship is
inadequate. Many modeling approaches recognize only binary
relationships. Ternary or n-ary relationships are decomposed into
two or more binary relationships.

UCS310:DBMS 11
Connectivity and Cardinality

The connectivity of a relationship describes the mapping of


associated entityinstances in the relationship.
The values of connectivity are "one" or
"many". The cardinality of a relationship is the actual
number of related occurrences for each of the two entities.
The basic types of connectivity for relations are:
¨ One to One (1:1)
¨ One to Many (1:M)
¨ Many to One (M:1)
¨ Many to Many (M:M)

UCS310:DBMS 12
Direction

The direction of a relationship indicates the originating entity of a


relationship. The entity from which a relationship originates is
the parent entity; the entity where the relationship terminates is
the child entity.
The type of the relation is determined by the direction of line
connecting relationship component and the entity. To distinguish
different types of relation, we draw either a directed line or an
undirected line between the relationship set and the entity set.
Directed line is used to indicate one occurrence and undirected
line is used to indicate many occurrences in a relation as shown
in next case.

UCS310:DBMS 13
UCS310:DBMS 14
UCS310:DBMS 15
Simplified Approach To DBMS: Parteek Bhatia

UCS310:DBMS 16
E-R Notation

¨ Entities are represented by labeled rectangles. The label is the name of the
entity. Entity names should be singular nouns.

¨ Attributes are represented by Ellipses.


¨ A solid line connecting two entities represents relationships. The name of
the relationship is written above the line. Relationship names should be verbs
and diamonds sign is used to represent relationship sets.
¨ Attributes, when included, are listed inside the entity rectangle. Attributes,
which are identifiers, are underlined. Attribute names should be singular
nouns.
¨ Multi-valued attributes are represented by double ellipses.
¨ Directed line is used to indicate one occurrence and undirected line is used
to indicate many occurrences in a relation.

UCS310:DBMS 17
Simplified Approach To DBMS: Parteek Bhatia

UCS310:DBMS 18
Simplified Approach To DBMS: Parteek Bhatia

UCS310:DBMS 19
UCS310:DBMS 20
UCS310:DBMS 21
UCS310:DBMS 22
Consider the following
database:
S (S#, SSNAME, STATUS, CITY)

P (P#, PNAME, COLOR, WEIGHT, CITY)

J ( J#, JNAME, CITY)

SPJ( S#, P#, J#, QTY)


Here S indicates information of suppliers, P Parts, J Projects
and SPJ indicates the supplied quantity details.

UCS310:DBMS 23
Simplified Approach To DBMS: Parteek Bhatia

UCS310:DBMS 24
Strong and Weak Entity
Sets
The entity set which does not has sufficient attributes to form a primary
key is called as weak entity set. An entity set that has a primary key is
called as Strong entity set. Consider an entity set Payment which has
three attributes: payment_number, payment_date and payment_amount.
Although each payment entity is distinct but payment for different loans
may share the same payment number. Thus, this entity set does not have
a primary key and it is a weak entity set. Each weak set must be a part of
one-to-many relationship set.
A member of a strong entity set is called dominant entity and member
of weak entity set is called as subordinate entity. A weak entity set
does not have a primary key but we need a means of distinguishing
among all those entries in the entity set that depend on one particular
strong entity set. The discriminator of a weak entity set is a set of
attributes that allows this distinction to be made. For example,
payment_number is acts as discriminator for payment entity set. It is
also called as the Partial key of the entity set.

UCS310:DBMS 25
Simplified Approach To DBMS: Parteek Bhatia

UCS310:DBMS 26
Generalization

A generalization hierarchy is a form of abstraction that specifies


that two or more entities that share common attributes can be
generalized into a higher-level entity type called a supertype or
generic entity. The lower level of entities becomes the subtype,
or categories, to the super type. Subtypes are dependent entities.
Generalization is used to emphasize the similarities among
lower-level entity sets and to hide differences. It makes ER
diagram simpler because shared attributes are not repeated.
Generalization is denoted through a triangle component
labeled ‘IS A”,

UCS310:DBMS 27
UCS310:DBMS 28
Specialization
Specialization is the process of taking subsets of a higher-level
entity set to form lower level entity sets. It is a process of
defining a set of subclasses of an entity type, which is called as
superclas of the specialization. The process of defining subclass
is based on the basis of some distinguish characteristics of
the entities in the super class.
For example, specialization of the Employee entity type
may yield the set of subclasses namely Salaried_Employee
and Hourly_Employee on the method of pay

UCS310:DBMS 29
Simplified Approach To DBMS: Parteek Bhatia

UCS310:DBMS 30
Difference between Specialization and Generalization

Specialization is the process of taking subsets of a higher-level


entity set to form lower level entity sets. Specialization
emphasizes differences among entities within the set by creating
distinct lower-level entity sets. These lower-level entity sets may
have attributes, or may participate in relationships, that do not
apply to all entities in the higher-level entity set.
Generalization proceeds from the recognition that a number of
entities set share some common features, which are described by
the same, attributes and participate in the same relationship sets.
Generalization is used to emphasize the similarities among lower-
level entity sets and to hide differences.

UCS310:DBMS 31
END

UCS310:DBMS 32

You might also like