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

DBMS Module1 Part2

The document discusses the Entity Relationship model and its key concepts including entities, attributes, relationships, keys, and constraints. It describes different types of entities, attributes, relationships and cardinalities. It also covers strong and weak entities and their representations.

Uploaded by

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

DBMS Module1 Part2

The document discusses the Entity Relationship model and its key concepts including entities, attributes, relationships, keys, and constraints. It describes different types of entities, attributes, relationships and cardinalities. It also covers strong and weak entities and their representations.

Uploaded by

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

Entity-Relationship

Model

Module – 1(Part 2)
ENTITY RELATIONSHIP MODEL

• High level conceptual data model.

• Use concepts such as entities, attributes, and


relationships.
• The diagrammatic notation associated with the ER model
is known as ER Diagram.

2
ENTITIES & ATTRIBUTES

• An entity represents a real-world object. Eg: e1 in the


below figure.
• The entity type is a collection of the entity having similar
attributes. Eg: Employee, company, car, etc.

• Each entity has attributes, properties that describes it.


Eg: name, salary, address etc.
• A particular entity will have a value for each of its
attributes.

3
Types of Attributes
1. Composite vs Simple (Atomic) Attributes
2. Single-valued vs Multivalued Attributes
3. Stored vs Derived Attributes
4. NULL value Attributes
5. Complex Attributes – Composite Multivalued Attributes
1) Composite vs Simple (Atomic) Attributes
• Composite attributes can be divided into smaller
subparts.
• Attributes that are not divisible are called simple or
atomic attributes.

4
• Address attribute can be subdivided into StreetAddress,
City, State, and Zip. StreetAddress can be further
subdivided into three simple attributes: Number, Street,
and ApartmentNumber.
• The value of a composite attribute is the concatenation
of the values of its constituent simple attributes.

5
1) Composite vs Simple (Atomic) Attributes

6
2) Single-Valued vs Multivalued Attributes
• Most attributes have a single value for a particular entity;
such attributes are called single-valued.
• For example, Age is a single-valued attribute of a person.
• In some cases, an attribute can have a set of values for the
same entity. Such attributes are called multivalued.
• For example, one person may not have a college degree,
another person may have one, and a third person may have
two or more degrees; therefore, different persons can have
different numbers of values for the CollegeDegrees attribute.

7
2) Single-Valued vs Multivalued Attributes

8
3) Stored vs Derived Attributes

• In some cases, two (or more) attribute values are


related-for example, the Age and BirthDate attributes of
a person.
• For a particular person entity, the value of Age can be
determined from the current (today's) date and the value
of that person's BirthDate.
• The Age attribute is hence called a derived attribute and
is said to be derivable from the BirthDate attribute, which
is called a stored attribute.

9
3) Stored vs Derived Attributes

10
4) NULL Values

• In some cases a particular entity may not have an


applicable value for an attribute.
• For example, the ApartmentNumber attribute of an
address applies only to addresses that are in apartment
buildings and not to other types of residences, such as
single-family homes.
• For such situations, a special value called null is
created.
• Null can be used if the value of an attribute is not
applicable or is unknown.

11
ENTITY TYPES, ENTITY SETS, KEYS & VALUE SETS

• An entity type defines a collection of entities that have


the same attributes.
• The collection of all entities of a particular entity type in
the database at any point in time is called an entity set.

12
13
KEY ATTRIBUTES OF AN ENTITY TYPE

• Key attributes will be having a unique value for each


entity of that attribute.
• It identifies every entity in the entity set.
• Key attribute will never be a null valued attribute.

• Any composite attribute can also be a key attribute.


• There could be more than one key attributes for an entity
type.

• Example: roll_no, enrollment _no

14
DOMAIN OF VALUE SET OF AN ATTRIBUTE

• Domain of an attribute is the allowed set of values of that


attribute.
• Example: if attribute is ‘grade’, then its allowed values
are A,B,C,F.

• Grade ={A, B, C, F}

15
RELATIONSHIP

• Relates two or more entities with a specific meaning.

• It is an association between two or more entities of


same or different entity set
• For example, EMPLOYEE John works on P1 PROJECT
or
• EMPLOYEE Franklin manages the Research
DEPARTMENT.
• Each relationship has a name, degree and cardinality
ratio.

16
RELATIONSHIP

WORKS
WORKS
EMPLOYEE
EMPLOYEE PROJECT
ON
ON

MANAGES DEPARTMENT

17
RELATIONSHIP TYPE

• A set of similar types of relationship.

• A relationship set is a set of relationships of the same


type.

18
WORKS
EMPLOYEE DEPARTMENT
FOR

• Relationship Type: WORKS_FOR


• Relationship Set: {r1, r2, r3, r4, r5, r6, r7}
• Relationship instance: r1

19
Degree of a Relationship Type

• The degree of a relationship type is the number of


participating entity types.
1. Unary relationships – Relationship type of degree 1.
2. Binary relationships – Degree 2

3. Ternary relationships – Degree 3

20
Degree of a Relationship Type

PERSON MARRIED TO

WORKS
EMPLOYEE DEPARTMENT
FOR

TEACHER TEACHES STUDENT

COURSE

21
Degree of a Relationship Type

22
CONSTRAINTS

• Relationship types usually have certain constraints. Two


main types of relationship constraints:
1. Cardinality ratio
2. Participation Constraints

• Cardinality ratio specifies the maximum number of


relationship instances that an entity can participate in.
• Participation constraint specifies the minimum number of
relationship instances that each entity can participate in.

23
Cardinality

• It tells how many instances of an entity type is related to


one instance of the other entity.
1. one-to-one (1-1)
2. one-to-many (1-N)

3. many-to-one (M-1)
4. many-to-many (M-N)

24
Cardinality
1

PERSON MARRIED TO

M 1
WORKS
EMPLOYEE DEPARTMENT
FOR

M N
TEACHER TEACHES STUDENT

25
Role Name

Husband

PERSON MARRIED TO

Wife

Worker Employer
WORKS
EMPLOYEE DEPARTMENT
FOR

Subordinate

EMPLOYEE MANAGES

Manager
Recursive Relationships - When there is a relationship between two entities
of the same type.

26
Participation Constraint

• There are 2 types of participation constraint:

1) Total participation:

• Every entity in the entity type participates in at least one


relationship in the relationship type.
• Represented by double lines.
2) Partial participation:

• Some entities may not participate in any relationship in


the relationship type.
• Represented by single line.

27
Participation Constraint

28
STRONG & WEAK ENTITY TYPES

1) Strong entity types:

• Entity types that have at least one key attribute.

• A strong entity will always have a primary key.


• A strong entity is not dependent of any other entity in the
schema.
• Strong entities are represented by a single rectangle.

• The relationship of two strong entities is represented by


a single diamond.

29
STRONG & WEAK ENTITY TYPES
2) Weak entity types:
• Entity type that does not have any key attribute.
• A weak entity is dependent on a strong entity to ensure its
existence.
• Unlike a strong entity, a weak entity does not have any
primary key.
• It instead has a partial discriminator key.

• A weak entity is represented by a double rectangle.

• The relation between one strong and one weak entity is


represented by a double diamond - Identifying Relationship.

30
STRONG & WEAK ENTITY TYPES

31
STRONG & WEAK ENTITY TYPES

32
DESIGN CHOICES

• An attribute that exists in several entity types may be


promoted to an independent entity type.
• Inverse of the above case – If an entity type exists with a
single attribute & is related to only one other entity type,
it may be demoted to an attribute of the other entity type.

33
ER DIAGRAM NOTATIONS

34
Ternary Relationship
Three binary Relationship
Question
Construct an ER Diagram for Company having following details:
• Company organized into DEPARTMENT. Each department has unique
name and a particular employee who manages the department. Start date
for the manager is recorded. Department may have several locations.
• A department controls a number of PROJECT. Projects have a unique
name, number and a single location.
• Company’s EMPLOYEE name, ssno, address, salary, sex and birth date are
recorded. An employee is assigned to one department, but may work for
several projects (not necessarily controlled by her dept). Number of
hours/week an employee works on each project is recorded. Every
employee has an immediate supervisor. All employees should be part of
some project.
• Employee’s DEPENDENT are tracked for health insurance purposes
(dependent name, birthdate, relationship to employee).
Min-Max Notation
• (min,max)
• The numbers mean that for each entity e in E, e must
participate in at least min and at most max.
• max relationship instances in R at any point in time. In
this method, min = 0 implies partial participation,
whereas min > 0 implies total participation.

You might also like