(MEERA) Dapodi Call Girls Just Call 7001035870 [ Cash on Delivery ] Pune Escorts
Module 1 session 5
1. DEPARTMENT OF COMPUTER SCIENCE AND
ENGINEERING
COURSE CODE : 18CS401
TITLE : DATABASE MANAGEMENT SYSTEMS
STAFF NAME : Ms. G. Sandhya
18CS401 DBMS 1
MODULE 1 SESSION 5
2. MODULE 1 SESSION 5
17CS307 DBMS
218CS401 DBMS 2
SESSION 1 Introduction, characteristics of Databases, File systems
vs Database systems
SESSION 2 Evolution of DBMS, Users of Database Systems, Three
Level DBMS Architecture and Data Abstraction
SESSION 3 Database System Architecture, Designing an enterprise
database system
SESSION 4 Introductions to data models, Benefits of data model,
Phases of data modelling
SESSION 5 Entity–Relationship model, E-R Diagrams, Extended E-R
Diagram, Evaluating data model quality
SESSION 6 The relational Model, Schema, Keys
SESSION 7 Relational Algebra, Domain Relational Calculus, Tuple
Relational Calculus, Fundamental operations.
MODULE 1
Introduction & Data Modelling
4. • To understand about Entity–Relationship model
• To know about E-R Diagrams
• To discuss about Extended E-R Diagram
• To evaluate data model quality
LEARNING OBJECTIVES
18CS401 DBMS 4
MODULE 1 SESSION 5
5. • Design Process
• Modeling
• Constraints
• E-R Diagram
• Design Issues
• Weak Entity Sets
• Extended E-R Features
• Design of the Bank Database
OUTLINE
18CS401 DBMS 5
MODULE 1 SESSION 5
6. • Widely used DB modelling technique
• Communication between database manager and user
• Represents an Abstract global view
• Proposed in 1976 by Peter Chan
• Consist of people, objects and facilities
• All things of interest to the enterprise are called Entities and
interactions are called relationships
E-R MODEL
18CS401 DBMS 6
MODULE 1 SESSION 5
7. • The initial phase of database design is to characterize fully the data
needs of the prospective database users.
• Next, the designer chooses a data model and, by applying the
concepts of the chosen data model, translates these requirements into
a conceptual schema of the database.
• A fully developed conceptual schema also indicates the functional
requirements of the enterprise.
• In a “specification of functional requirements”, users describe the
kinds of operations (or transactions) that will be performed on the data.
DESIGN PHASES
18CS401 DBMS 7
MODULE 1 SESSION 5
8. • The process of moving from an abstract data model to the
implementation of the database proceeds in two final design phases.
• LOGICAL DESIGN - Deciding on the database schema. Database
design requires that we find a “good” collection of relation schemas.
Business decision – What attributes should we record in the
database?
Computer Science decision – What relation schemas should we
have and how should the attributes be distributed among the
various relation schemas?
• PHYSICAL DESIGN - Deciding on the physical layout of the database
(form of file organization)
DESIGN PHASES
18CS401 DBMS 8
MODULE 1 SESSION 5
9. • Entity Relationship Model-Models an enterprise as a collection of
entities and relationships
Entity: a “thing” or “object” in the enterprise that is
distinguishable from other objects
Described by a set of attributes
Relationship: an association among several entities
Represented diagrammatically by an entity-relationship
diagram
• Normalization Theory
Formalize what designs are bad, and test for them
DESIGN APPROACHES
18CS401 DBMS 9
MODULE 1 SESSION 5
10. • Developed to facilitate database design by allowing specification of an
enterprise schema that represents the overall logical structure of a
database.
• The ER model is very useful in mapping the meanings and interactions
of real-world enterprises onto a conceptual schema.
• The ER data model employs three basic concepts:
entity sets,
relationship sets,
attributes.
• The ER model also has an associated diagrammatic representation, the
ER diagram, which can express the overall logical structure of a
database graphically.
ER MODEL - DATABASE MODELING
18CS401 DBMS 10
MODULE 1 SESSION 5
11. • An entity is an object that exists and is distinguishable from other
objects.
• Entity is a real or abstract object (depends on requirement)
• Maybe Person, Place or Building – identifier
• Model reflect the perspective of a certain application.
• Part of an enterprise that is of interest Universe of Disclosure (UoD)
Example: specific person, company, event, plant
• An entity set is a set of entities of the same type that share the same
properties.
Example: set of all persons, companies, trees, holidays
ENTITY SETS
18CS401 DBMS 11
MODULE 1 SESSION 5
12. • An entity is represented by a set of attributes; i.e., descriptive
properties possessed by all members of an entity set.
Example: instructor = (ID, name, street, city, salary )
course= (course_id, title, credits)
• A subset of the attributes form a primary key of the entity set; i.e.,
uniquely identifiying each member of the set.
ENTITY SETS
18CS401 DBMS 12
MODULE 1 SESSION 5
14. • A relationship is an association among several entities.
Example: 44553 (Peltier) advisor 22222 (Einstein) student entity
relationship set instructor entity
• A relationship set is a mathematical relation among n 2 entities, each
taken from entity sets {(e1, e2, … en) | e1 E1, e2 E2, …, en En}
where (e1, e2, …, en) is a relationship
Example: (44553,22222) advisor
RELATIONSHIP SETS
18CS401 DBMS 14
MODULE 1 SESSION 5
16. • An attribute can also be associated with a relationship set.
• For instance, the advisor relationship set between entity sets instructor
and student may have the attribute date which tracks when the student
started being associated with the advisor.
RELATIONSHIP SETS
18CS401 DBMS 16
MODULE 1 SESSION 5
17. ENTITIES AND ENTITY SETS
18CS401 DBMS 17
MODULE 1 SESSION 5
Eg: Sachin has playerid : ID890001
Each entity identified with its own properties.
Entities are Classified into entity sets (entity types).
Entity set is a set of objects called entity instances (occurrences).
An entity instance is an individual object of a given entity type.
Sachin
Tendulkar
Best batsmen
Instance
Abstraction
Ricky Ponting
Instance
18. RELATIONSHIP
18CS401 DBMS 18
MODULE 1 SESSION 5
Associations or connections that exist between entities and may be
looked at as mappings between two or more entity sets.
A relationship set is a set of relation instances of the same type.
Although we allow relationships among any number of entity sets, the
most common cases are binary relationships between two entity sets.
Mapping two or more entity sets. Eg: Player and Match
There are three types of relationship
Binary Relationship
Recursive Relationship
Ternary Relationship
19. MAPPING CARDINALITY CONSTRAINTS
18CS401 DBMS 19
MODULE 1 SESSION 5
Express the number of entities to which another entity can be
associated via a relationship set.
Most useful in describing binary relationship sets.
For a binary relationship set the mapping cardinality must be one of the
following types:
One to one
One to many
Many to one
Many to many
20. MAPPING CARDINALITIES
18CS401 DBMS 20
MODULE 1 SESSION 5
One to one
One to many
• An entity in A is associated with
at most one entity in B, and an
entity in B is associated with at
most one entity in A.
• Note: Some elements in A and B
may not be mapped to any
elements in the other set.
• An entity in A is associated
with any number (zero or
more) of entities in B.
• An entity in B, however, can
be associated with at most
one entity in A.
21. MAPPING CARDINALITIES
18CS401 DBMS 14
MODULE 1 SESSION 5
• An entity in A is associated with
atmost one entity in B.
• An entity in B, however, can be
associated with zero or more
entities in A.
• An entity in A is associated
with any number (zero or
more) of entities in B, and an
entity in B is associated with
any number (zero or more) of
entities in A.
Many to one Many to many
22. COMPLEX ATTRIBUTES
18CS401 DBMS 14
MODULE 1 SESSION 5
Attribute types
Simple or composite attributes.
Single-valued or multivalued attributes
Example: multivalued attribute: phone_numbers
Derived attributes: Can be computed from other attributes
Example: age, given date_of_birth
Stored or Derived
Required or Optional
Domain – the set of permitted values for each attribute
23. COMPOSITE ATTRIBUTES
18CS401 DBMS 14
MODULE 1 SESSION 5
Simple : attributes not sub divided Eg: country, place of birth
Composite : attributes that are sub divided Eg: dob, Name
24. 18CS401 DBMS 14
MODULE 1 SESSION 5
SINGLE OR MULTI-VALUED
Many attributes have a single value
Multi valued : Eg: umpire – TV,refree,reserve umpire
STORED OR DERIVED
Attribute values that are related Eg: players career –batting average
DERIVED
Eg- number of run scored
REQUIRED OR OPTIONAL
It may or maynot be necessary Eg:match ID
Value Sets – set of legal values Eg: age between 15 and 45
25. REDUNDANT ATTRIBUTES
18CS401 DBMS 14
MODULE 1 SESSION 5
Suppose we have entity sets:
instructor, with attributes: ID, name, dept_name, salary
department, with attributes: dept_name, building, budget
We model the fact that each instructor has an associated department
using a relationship set inst_dept
The attribute dept_name appears in both entity sets. Since it is the
primary key for the entity set department, it replicates information
present in the relationship and is therefore redundant in the entity set
instructor and needs to be removed.
BUT: when converting back to tables, in some cases the attribute gets
reintroduced.
26. WEAK ENTITY SETS
18CS401 DBMS 14
MODULE 1 SESSION 5
Consider a section entity, which is uniquely identified by a course_id,
semester, year, and sec_id.
Clearly, section entities are related to course entities. Suppose we
create a relationship set sec_course between entity sets section and
course.
Note that the information in sec_course is redundant, since section
already has an attribute course_id, which identifies the course with
which the section is related.
One option to deal with this redundancy is to get rid of the relationship
sec_course; however, by doing so the relationship between section
and course becomes implicit in an attribute, which is not desirable.
27. WEAK ENTITY SETS
18CS401 DBMS 14
MODULE 1 SESSION 5
An alternative way to deal with this redundancy is to not store the
attribute course_id in the section entity and to only store the remaining
attributes section_id, year, and semester. However, the entity set
section then does not have enough attributes to identify a particular
section entity uniquely; although each section entity is distinct,
sections for different courses may share the same section_id, year,
and semester.
To deal with this problem, we treat the relationship sec_course as a
special relationship that provides extra information, in this case, the
course_id, required to identify section entities uniquely.
An entity set that is not a weak entity set is termed a strong entity set.
28. WEAK ENTITY SETS
18CS401 DBMS 14
MODULE 1 SESSION 5
The notion of weak entity set formalizes the above intuition. A weak
entity set is one whose existence is dependent on another entity, called
its identifying entity; instead of associating a primary key with a weak
entity, we use the identifying entity, along with extra attributes called
discriminator to uniquely identify a weak entity.
Every weak entity must be associated with an identifying entity; that is,
the weak entity set is said to be existence dependent on the identifying
entity set. The identifying entity set is said to own the weak entity set
that it identifies. The relationship associating the weak entity set with
the identifying entity set is called the identifying relationship.
Note that the relational schema we create from the entity set section
does have the attribute course_id, for reasons that will become clear
later, even though the attribute course_id is dropped from the entity set.
29. EXPRESSING WEAK ENTITY SETS
18CS401 DBMS 14
MODULE 1 SESSION 5
In E-R diagrams, a weak entity set is depicted via a double rectangle.
We underline the discriminator of a weak entity set with a dashed line.
The relationship set connecting the weak entity set to the identifying
strong entity set is depicted by a double diamond.
Primary key for section – (course_id, sec_id, semester, year)
30. E-R DIAGRAM FOR A UNIVERSITY ENTERPRISE
18CS401 DBMS 14
MODULE 1 SESSION 5
31. CARDINALITY RATIO
18CS401 DBMS 14
MODULE 1 SESSION 5
Maximum number of relationship instances that an entity can
participate in.
Eg: Employee and Office
32. NAMING CONVENTIONS
18CS401 DBMS 14
ENTITIES
• Each entity name should come from the entity description
• Each entity name should be a noun
• The first letter should be a uppercase
• Underscores should join the words
• Names of the entities should be meaningful and should not conflict with
other entity names
MODULE 1 SESSION 5
33. NAMING CONVENTIONS
18CS401 DBMS 14
MODULE 1 SESSION 5
RELATIONSHIPS
• Each relationship name should be a verb that fits the sentence
structure
• Can use underscores to join the words
ATTRIBUTES
• An attribute name should be a noun
• Can use underscores to join the words
• Must be unique
34. RELATIONSHIP SETS
18CS401 DBMS 14
MODULE 1 SESSION 5
• A relationship is an association among several entities.
• For example, we can define a relationship that associates customer
Hayes with loan L-15. This relationship specifies that Hayes is a
customer with loan number L-15.
• A relationship set is a set of relationships of the same type. Formally, it
is a mathematical relation on n ≥ 2 (possibly nondistinct) entity sets. If
E1, E2, . . .,En are entity sets, then a relationship set R is a subset of
{(e1, e2, . . . , en) | e1 ∈ E1, e2 ∈ E2, . . . , en ∈ En}
• where (e1, e2, . . . , en) is a relationship.
36. REPRESENTING ENTITIES AND RELATIONSHIPS
18CS401 DBMS 14
Since Entity set can have many entity instances, it is essential to
uniquely identify each entity instance in every entity set.
A group of attributes used for identifying each entity in an entity set is
called an entity Key.(Eg. EmpId)
Primary Key
Foreign Key
Super Key
Candidate key
Composite Key
MODULE 1 SESSION 5
37. ENTITY KEY
18CS401 DBMS 14
A group of attributes (possibly one) used for identifying each entity in
an entity set is called an entity key.
Primary key – is an attribute or a set of attributes that uniquely
identifies a specific instance of an entity.
Every entity in an ER model must have a primary key.
MODULE 1 SESSION 5
38. FOREIGN KEY
18CS401 DBMS 14
Foreign key are those keys which is used to define relationship
between two tables.
Foreign key is used to implement relationship between two tables. It is
also known as referential integrity.
More than one foreign key can be used for a single table.
Foreign key is generally a primary key from one table
MODULE 1 SESSION 5
39. CANDIDATE KEY
18CS401 DBMS 14
When an entity has more than one attribute that serve as a primary key,
each of such keys is called a candidate key.
" Customer-id is candidate key of customer
" account-number is candidate key of account
One and only one of the candidate keys is chosen as the primary key
for the entity
Similarly, the combination of customer-name and customer-id is a
superkey for the entity set customer.
It is possible that several distinct sets of attributes could serve as a
candidate key.
MODULE 1 SESSION 5
40. CANDIDATE KEY
18CS401 DBMS 14
Suppose that a combination of customer-name and customer-street is
sufficient to distinguish among members of the customer entity set.
Then, both {customer-id} and {customer-name, customer-street} are
candidate keys.
Although the attributes customerid and customer-name together can
distinguish customer entities, their combination does not form a
candidate key, since the attribute customer-id alone is a candidate key.
Alternate Key : The candidate key other than primary key is called as
alternate key
MODULE 1 SESSION 5
41. SUPER KEY AND ALTERNATE KEY
18CS401 DBMS 14
• The set of attributes which can uniquely identify a tuple is known as
Super Key.
• Adding zero or more attributes to candidate key generates super key.
• The combination of primary keys of the participating entity sets forms a
super key of a relationship set.
"(customer-id, account-number) is the super key of depositor”
NOTE: this means a pair of entity sets can have at most one
relationship in a particular relationship set.
• A candidate key is a super key but vice versa is not true.
MODULE 1 SESSION 5
42. WEAK ENTITY SETS
18CS401 DBMS 14
An entity set that does not have a primary key is referred to as a weak
entity set.
The existence of a weak entity set depends on the existence of a
identifying entity set.
It must relate to the identifying entity set via a total, one-to-many
relationship set from the identifying to the weak entity set
Identifying relationship depicted using a double diamond.
The discriminator (or partial key) of a weak entity set is the set of
attributes that distinguishes among all the entities of a weak entity set.
The primary key of a weak entity set is formed by the primary key of the
strong entity set on which the weak entity set is existence dependent,
plus the weak entity set’s discriminator.
MODULE 1 SESSION 5
43. THE ENTITY - RELATIONSHIP (ER) MODEL
18CS401 DBMS 14
The entity-relationship (E-R) data model perceives the real world as
consisting of basic objects, called entities, and relationships among
these objects.
Represents the overall logical structure of a database.
MODULE 1 SESSION 5
45. 18CS401 DBMS 14
• Only one entity set which
has a relationship with
itself.
A SIMPLE UNARY RELATIONSHIP BINARY RELATIONSHIP
• A Simple relationship between
two entity types.
MODULE 1 SESSION 5
46. 18CS401 DBMS 14
• Simple relationship among three entity sets.
TWO BINARY RELATIONSHIP BETWEEN SAME ENTITIES
MODULE 1 SESSION 5
47. 18CS401 DBMS 14
• Most relationship sets are binary
• There are occasions when it is more convenient to represent
relationships as non-binary.
• E-R Diagram with a Ternary Relationship
NON-BINARY RELATIONSHIP SETS
MODULE 1 SESSION 5
48. 18CS401 DBMS 14
• We allow at most one arrow out of a ternary (or greater degree)
relationship to indicate a cardinality constraint
• Ex:, an arrow from proj_guide to instructor indicates each student has
at most one guide for a project
• If there is more than one arrow, there are two ways of defining the
meaning.
• Ex:, a ternary relationship R between A, B and C with arrows to B and
C could mean.
Each A entity is associated with a unique entity from B and C or
Each pair of entities from (A, B) is associated with a unique C entity,
and each pair (A, C) is associated with a unique B
• Each alternative has been used in different formalisms
• To avoid confusion we outlaw more than one arrow
CARDINALITY CONSTRAINTS ON TERNARY RELATIONSHIP
MODULE 1 SESSION 5
49. 18CS401 DBMS 14
• one-to-many relationship between an instructor and a student
• an instructor is associated with several (including 0) students via
advisor
• a student is associated with at most one instructor via advisor,
ONE-TO-MANY RELATIONSHIP
MODULE 1 SESSION 5
50. 18CS401 DBMS 14
• In a many-to-one relationship between an instructor and a student,
• an instructor is associated with at most one student via advisor, and
• a student is associated with several (including 0) instructors via
advisor
MANY-TO-ONE RELATIONSHIP
MODULE 1 SESSION 5
51. 18CS401 DBMS 14
• An instructor is associated with several (possibly 0) students via
advisor
• A student is associated with several (possibly 0) instructors via
advisor
MANY-TO-MANY RELATIONSHIP
MODULE 1 SESSION 5
52. 18CS401 DBMS 14
• Total participation (indicated by double line): every entity in the entity
set participates in at least one relationship in the relationship set
participation of student in advisor relation is total
every student must have an associated instructor
• Partial participation: some entities may not participate in any
relationship in the relationship set
Example: participation of instructor in advisor is partial
TOTAL AND PARTIAL PARTICIPATION
MODULE 1 SESSION 5
53. 18CS401 DBMS 14
• A line may have an associated minimum and maximum cardinality,
shown in the form l..h, where l is the minimum and h the maximum
cardinality.
• A minimum value of 1 indicates total participation.
• A maximum value of 1 indicates that the entity participates in at most
one relationship
• A maximum value of * indicates no limit.
• Instructor can advise 0 or more students.
• student must have 1 advisor; cannot have multiple advisors.
NOTATION FOR EXPRESSING MORE COMPLEX
CONSTRAINTS
MODULE 1 SESSION 5
55. 18CS401 DBMS 14
• In E-R diagrams, a weak entity set is depicted via a double rectangle.
• We underline the discriminator of a weak entity set with a dashed
line.
• The relationship set connecting the weak entity set to the identifying
strong entity set is depicted by a double diamond.
• Primary key for section – (course_id, sec_id, semester, year).
EXPRESSING WEAK ENTITY SETS
MODULE 1 SESSION 5
58. 18CS401 DBMS 14
• Top-down design process; we designate sub-groupings within an
entity set that are distinctive from other entities in the set.
• These sub-groupings become lower-level entity sets that have
attributes or participate in relationships that do not apply to the
higher-level entity set.
• Depicted by a triangle component labeled ISA (e.g., instructor “is a”
person).
• Attribute inheritance – a lower-level entity set inherits all the attributes
and relationship participation of the higher-level entity set to which it
is linked.
SPECIALIZATION
MODULE 1 SESSION 5
60. 18CS401 DBMS 14
METHOD 1
• Form a schema for the higher-level entity
• Form a schema for each lower-level entity set, include primary key
of higher-level entity set and local attributes
• Drawback: getting information about, an employee requires
accessing two relations, the one corresponding to the low-level
schema and the one corresponding to the high-level schema
REPRESENTING SPECIALIZATION VIA SCHEMAS
MODULE 1 SESSION 5
61. 18CS401 DBMS 14
METHOD 2
• Form a schema for each entity set with all local and inherited
attributes
• Drawback: name, street and city may be stored redundantly for
people who are both students and employees
REPRESENTING SPECIALIZATION VIA SCHEMAS
MODULE 1 SESSION 5
62. 18CS401 DBMS 14
• A bottom-up design process – combine a number of entity sets that
share the same features into a higher-level entity set.
• Specialization and generalization are simple inversions of each other;
they are represented in an E-R diagram in the same way.
• The terms specialization and generalization are used interchangeably.
CONSTRAINTS ON GENERALIZATION
Condition defined or user defined
Disjoint and overlapping
Completeness constraint
GENERALIZATION
MODULE 1 SESSION 5
63. 18CS401 DBMS 14
CONDITION-DEFINED
• In condition-defined lower-level entity sets, membership is evaluated
on the basis of whether or not an entity satisfies an explicit condition
or predicate.
• For example, assume that the higher-level entity set student has the
attribute student type.
• All student entities are evaluated on the defining student type
attribute.
CONDITION-DEFINED & USER-DEFINED
MODULE 1 SESSION 5
64. 18CS401 DBMS 14
USER-DEFINED
• User-defined lower-level entity sets are not constrained by a
membership condition; rather, the database user assigns entities to a
given entity set.
• For instance, let us assume that, after 3 months of employment,
university employees are assigned to one of four work teams.
• A given employee is not assigned to a specific team entity
automatically on the basis of an explicit defining condition.
CONDITION-DEFINED & USER-DEFINED
MODULE 1 SESSION 5
65. 18CS401 DBMS 14
DISJOINT
• A disjointness constraint requires that an entity belong to no more
than one lower-level entity set.
• In our example, student entity can satisfy only one condition for the
student type attribute; an entity can be either a graduate student or an
undergraduate student, but cannot be both.
OVERLAPPING
• In overlapping generalizations, the same entity may belong to more
than one lower-level entity set within a single generalization.
• Employee work-team example, and assume that certain employees
participate in more than onework team.
DISJOINT AND OVERLAPPING
MODULE 1 SESSION 5
66. 18CS401 DBMS 14
COMPLETENESS CONSTRAINT
• specifies whether or not an entity in the higher-level entity set must
belong to at least one of the lower-level entity sets within a
generalization.
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
DESIGN CONSTRAINTS ON A
SPECIALIZATION/GENERALIZATION
MODULE 1 SESSION 5
67. 18CS401 DBMS 14
• Partial generalization is the default.
• We can specify total generalization in an ER diagram by adding the
keyword total in the diagram and drawing a dashed line from the
keyword
• The student generalization is total and disjoint: All student entities
must be either graduate or undergraduate.
• Employee generalization is partial and overlapping
MODULE 1 SESSION 5
68. 18CS401 DBMS 14
• Consider the ternary relationship proj_guide, which we saw earlier
• Suppose we want to record evaluations of a student by a guide on a
project
AGGREGATION
MODULE 1 SESSION 5
69. 18CS401 DBMS 14
• Relationship sets eval_for and proj_guide represent overlapping
information
Every eval_for relationship corresponds to a proj_guide
relationship
However, some proj_guide relationships may not correspond to
any eval_for relationships
So we can’t discard the proj_guide relationship
• Eliminate this redundancy via aggregation
Treat relationship as an abstract entity
Allows relationships between relationships
Abstraction of relationship into new entity
AGGREGATION
MODULE 1 SESSION 5
70. 18CS401 DBMS 14
• Eliminate this redundancy via aggregation without introducing
redundancy, the following diagram represents:
• A student is guided by a particular instructor on a particular
project
• A student, instructor, project combination may have an associated
evaluation
AGGREGATION
MODULE 1 SESSION 5
71. 18CS401 DBMS 14
• To represent aggregation, create a schema containing
Primary key of the aggregated relationship,
The primary key of the associated entity set
Any descriptive attributes
• In our example:
The schema eval_for is:
eval_for (s_ID, project_id, i_ID, evaluation_id)
The schema proj_guide is redundant.
REPRESENTING AGGREGATION VIA SCHEMAS
MODULE 1 SESSION 5
72. 18CS401 DBMS 14
• Apply specialization repeatedly to refine a design scheme.
• Top-down design process; we designate subgroupings within an
entity set that are distinctive from other entities in the set.
• A subset of entities within an entity set may have attributes that are
not shared by all the entities in the entity set .
• These sub groupings become lower-level entity sets that have
attributes or participate in relationships that do not apply to the
higher-level entity set.
• Depicted by a triangle component labeled ISA (E.g. customer “is a”
person).
• Attribute inheritance – a lower-level entity set inherits all the
attributes and relationship participation of the higher-level entity set
to which it is linked.
SPECIALIZATION
MODULE 1 SESSION 5
74. 18CS401 DBMS 14
• A bottom-up design process – combine a number of entity sets that
share the same features into a higher-level entity set.
• Specialization and generalization are simple inversions of each other;
they are represented in an E-R diagram in the same way.
• The terms specialization and generalization are used
interchangeably.
GENERALIZATION
MODULE 1 SESSION 5
75. 18CS401 DBMS 14
• Use of entity sets vs. attributes.
• Use of phone as an entity allows extra information about phone
numbers (plus multiple phone numbers).
ENTITIES VS. ATTRIBUTES
MODULE 1 SESSION 5
76. 18CS401 DBMS 14
USE OF ENTITY SETS VS. RELATIONSHIP SETS
• Possible guideline is to designate a relationship set to describe an
action that occurs between entities
PLACEMENT OF RELATIONSHIP ATTRIBUTES
• For example, attribute date as attribute of advisor or as attribute of
student
ENTITIES VS. RELATIONSHIP SETS
MODULE 1 SESSION 5
77. 18CS401 DBMS 14
• Although it is possible to replace any non-binary (n-ary, for n > 2)
relationship set by a number of distinct binary relationship sets, a n-
ary relationship set shows more clearly that several entities
participate in a single relationship.
• Some relationships that appear to be non-binary may be better
represented using binary relationships
• For example, a ternary relationship parents, relating a child to his/her
father and mother, is best replaced by two binary relationships, father
and mother
• Using two binary relationships allows partial information (e.g., only
mother being known)
• But there are some relationships that are naturally non-binary
• Example: proj_guide
BINARY VS. NON-BINARY RELATIONSHIPS
MODULE 1 SESSION 5
78. 18CS401 DBMS 14
• In general, any non-binary relationship can be represented using
binary relationships by creating an artificial entity set.
• Replace R between entity sets A, B and C by an entity set E, and three
relationship sets:
RA, relating E and A
RB, relating E and B
RC, relating E and C
• Create an identifying attribute for E and add any attributes of R to E
• For each relationship (ai , bi , ci) in R, create
a new entity ei in the entity set E
add (ei , ai ) to RA
add (ei , bi ) to RB
add (ei , ci ) to RC
CONVERTING NON-BINARY RELATIONSHIPS TO BINARY FORM
MODULE 1 SESSION 5
79. 18CS401 DBMS 14
• Also need to translate constraints
Translating all constraints may not be possible
There may be instances in the translated schema that
cannot correspond to any instance of R
Exercise: add constraints to the relationships RA, RB and RC to ensure
that a newly created entity corresponds to exactly one entity in each
of entity sets A, B and C
• We can avoid creating an identifying attribute by making E a weak
entity set (described shortly) identified by the three relationship sets
CONVERTING NON-BINARY RELATIONSHIPS TO BINARY
FORM
MODULE 1 SESSION 5
80. 18CS401 DBMS 14
• The use of an attribute or entity set to represent an object.
• Whether a real-world concept is best expressed by an entity set or a
relationship set.
• The use of a ternary relationship versus a pair of binary relationships.
• The use of a strong or weak entity set.
• The use of specialization/generalization – contributes to modularity in
the design.
• The use of aggregation – can treat the aggregate entity set as a single
unit without concern for the details of its internal structure.
E-R DESIGN DECISIONS
MODULE 1 SESSION 5
90. 1. A car-insurance company whose customers own one or more cars
each. Each car has associated with it zero to any number of recorded
accidents.
2. Consider the E-R diagram in Figure, which models an online
bookstore.
a. List the entity sets and their primary keys.
b. Suppose the bookstore adds Blu-ray discs and downloadable video to
its collection. The same item may be present in one or both formats, with
differing prices. Extend the E-R diagram to model this addition, ignoring
the effect on shopping baskets.
c. Now extend the E-R diagram, using generalization, to model the case
where a shopping basket may contain any combination of books, Blu-
ray discs, or downloadable video.
EXPECTED QUESTIONS
18CS401 DBMS 16
MODULE 1 SESSION 5
91. • Explain the distinctions among the terms primary key, candidate key,
and superkey.
• Explain the difference between a weak and a strong entity set.
• We can convert any weak entity set to a strong entity set by simply
adding appropriate attributes. Why, then, do we have weak entity
sets?
• Construct an E-R diagram for a hospital with a set of patients and a
set of medical doctors. Associate with each patient a log of the
various tests and examinations conducted..
• Explain the distinction between total and partial constraints
EXPECTED QUESTIONS
18CS401 DBMS 16
MODULE 1 SESSION 5
92. • Design a generalization–specialization hierarchy for a motor vehicle
sales company. The company sells motorcycles, passenger cars,
vans, and buses. Justify your placement of attributes at each level of
the hierarchy. Explain why they should not be placed at a higher or
lower level.
• Explain the distinction between condition-defined and user-defined
constraints.
• Which of these constraints can the system check automatically?
Explain your answer.
• Explain the distinction between disjoint and overlapping constraints.
EXPECTED QUESTIONS
18CS401 DBMS 16
MODULE 1 SESSION 5
