The document discusses various concepts for modeling entity-relationship diagrams and mapping them to relational database schemas. It covers modeling entities, relationships, attributes, keys, and converting specialized and generalized entity types. Specifically, it describes four approaches to mapping specialized entity types to relational schemas: (1) separate relations for supertype and subtypes, (2) separate relations only for subtypes, (3) a single relation with a type attribute, and (4) a single relation with multiple type attributes. It also discusses mapping categories and handling cases where supertypes have different keys.

2. The schema for database application displayed by
graphical notation . It mainly comprises :
• Entity and its attributes
• Relationship, which is association among entities
Ideas ER Design Relational Schema
Relational DBMS
Implementation

3. Entity types represent collection of entities that
have same attributes and are pictured by
rectangular nodes. Basically the relation name.
Weak – Entity
Types

4. A Relationship type R among entities types
defines a set of associations.
Relationship types associate entity types. They
are pictured by Diamond nodes.

9. • Create a new relation.
• Include the simple attributes
• Include the simple components of the composite
attributes
• Identify the primary keys. If the chosen key is
composite, the set of simple attributes that form
it will together form the primary key.
• Don’t include: non-simple components of
composite attributes, foreign keys, derived
attributes.

11. • Create a new relation.
• Include simple attributes
• Add the owner’s primary key attributes, as
foreign key attributes
• Declare into a primary key the partial keys of the
weak entity type combined with those imported
from the owner

13. There are Three possible approaches:
1) Foreign key approach
2) Merged relation option
3) Cross-reference or relationship relation
option

14. 1) Foreign Key approach
• Identify the relations S and T that correspond to
the entity types participating in R.
• Include as foreign keys, in the relation of one
entity type, the primary keys of the other entity
type
• The entity having total participation must have
the foreign key of the other entity.
• Include also the simple attributes of the
relationship type

15. DEPARTMENT has total participation. Therefore,
DEPARTMENT contains the foreign key, the
primary key of EMPLOYEE.
Example :

17. 2) Merged relation option:
• Merge the two entity types and the relationship
into a single relation.
• This may be appropriate when both
participations are total.

18. 3)Cross-reference or relationship
relation option:
• Create a third relation R for the purpose of
cross-referencing the primary keys of the two
relations S and T representing the entity types.

20. • Add as foreign keys, to the relation of the entity
type at the N side, the primary keys of the entity
type at the 1 side (don’t duplicate records!)
• Include also the simple attributes of the
relationship type

22. • Create a new relation.
• Add as foreign keys the primary keys of the
participating entity types to the relationship
type(their combination will form the primary
key)
• Include the simple attributes of the relationship
type

24. • Create a new relation
• Include the given attribute
• Include as foreign keys the primary attributes of
the entity/relationship type owning the
multivalued attribute.
• The primary key is combination of the attribute
as well as the foreign key.
• If the multivalued attribute is composite, we
include its simple components.

25. Example:
• The relation DEPT_LOCATIONS is created.
• The attribute DLOCATION represents the
multivalued attribute.
• LOCATIONS of DEPARTMENT, while
DNUMBER-as foreign key-represents the primary
key of the DEPARTMENT relation.
• The primary key is the combination of
{DNUMBER,DLOCATION}.

27.  Includes all modeling concepts of basic ER
 Additional concepts: subclasses/superclasses,
specialization/generalization, categories,
attribute inheritance
 The resulting model is called the enhanced-
ER or Extended ER (E2R or EER) model
 It is used to model applications more
completely and accurately if needed
 It includes some object-oriented concepts,
such as inheritance

28. An entity type may have additional meaningful
subgroupings of its entities
Example: EMPLOYEE may be further grouped into
SECRETARY, ENGINEER, MANAGER, TECHNICIAN,
SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
 Each of these groupings is a subset of EMPLOYEE
entities
 Each is called a subclass of EMPLOYEE
 EMPLOYEE is the superclass for each of these
subclasses
These are called superclass/subclass relationships.

29. Example
An entity that is
member of a
subclass
represents the
same real-world
entity as some
member of the
superclass

30.  An entity that is member of a subclass inherits
all attributes of the entity as a member of the
superclass
 It also inherits all relationships

31. • Is the process of defining a set of subclasses of a
superclass
• May have several specializations of the same superclass
Example :
{SECRETARY, ENGINEER, TECHNICIAN} is a
specialization of EMPLOYEE based upon job type.
Another specialization of EMPLOYEE based in method of
pay is {SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
• Attributes of a subclass are called specific attributes

32. The subset symbol
on each line
connecting a
subclass to the
circle indicates
direction of the
superclass/subclass
relationship.
Example of Specialization

33.  The reverse of the specialization process
 Several classes with common features are
generalized into a superclass; original classes
become its subclasses
Example: CAR, TRUCK generalized into
VEHICLE; both CAR, TRUCK become subclasses
of the superclass VEHICLE.
 Both Specializations and Generalizations are shown in
rectangles in EER diagrams (as are entity types)

34. a) Predicate-defined - The subclass is defined
through a predicate on the attributes of the
superclass
Defining
predicate of
the Sub class
EMPLOYEE
d
Salaried
employee
Hourly_employee
Salary > 30000Hours<6

35. b) Attribute-defined - The subclasses in the
specialization are all defined by the same attribute
of the superclass
c) User-defined – Membership determined
during insertion
Defining
attribute of the
Super class

36. Disjoint (d)
The subclasses must have disjoint sets of entities
Overlap (o)
The subclasses may have overlapping sets of entities
Partial - An entity may not belong to any of the
subclasses. Represented by
Total - Every entity in the superclass must be a member
of some subclass. Represented by
Disjointness and completeness constraints are independent

37. Note: Generalization usually is total because the
superclass is derived from the subclasses

38.  Every subclass participates as a subclass in only one
class/subclass relationship
 Single Inheritance
 Results in a tree structure or strict hierarchy
PURCHASED
d
WHOLESALERETAIL
COOKIE
HOME-MADE
d

39. Subclass can be a subclass in more than one class/subclass
relationship
 Multiple Inheritance
 Also called Shared subclasses
In a lattice or
hierarchy, a
subclass inherits
attributes not
only of its direct
superclass, but
also of all its
predecessor
superclasses

40.  Subclass related to a collection of superclasses
 Each instance of subclass belongs to one, not
all of the superclasses
 Superclasses form a union
 Category can be total or partial
 Subclass is called a category or UNION TYPE
Note: The difference from shared subclass is that the
member must exist in all of its superclasses).

41. Example of
Partial Union

42. U
Example of
Total Union

43. To Convert each Specialization and Generalized Superclass into
a relational schema :
a. Multiple relations-Superclass and subclasses
b. Multiple relations-Subclass relations only
c. Single relation with one type attribute
d. Single relation with multiple type attributes
NOTATION :
Super class : C Primary Key : K Attributes : A(i)
Sub class : S
Relation : L

45. a.Multiple relations-Superclass and
subclasses
 Create a relation L for C with attributes
Attrs(L) = {K, A1, A2, …, An} and PK(L) = K.
 Create a relation Li for each subclass Si, 1 < i < m,
with the attributes
ATTRS(Li) = {K} U {attributes of Si} and
PK(Li) = K.
 This option works for any constraints: disjoint or
overlapping; total or partial.

47. b. Multiple relations-Subclass relations
only
 Create a relation Li for each subclass Si, 1 < i < m, with
ATTRS(Li) = {attributes of Si} U {K, A1, A 2, …, An }
PK(Li) = K
 This option works well only for disjoint and total
constraints.
 If the specialization is overlapping, the same entity may be
duplicated in several relations.
 If not total, entity not belonging to any sub-class is lost.

48. d
Tonnage

49. c. Single relation with one type attribute
 Create a single relation L with attributes Attrs(L) = {K,
A1, …, A n} U {attributes of S1} U… U {attributes of S
m} U {T} and PK(L)=K
 This option is for specialization whose subclasses are
DISJOINT, and T is a type/discriminating attribute
that indicates the subclass to which each tuple belongs,
if any. This option may generate a large number of null
values.
 Not recommended if many specific attributes are
defined in subclasses (will result in many null values!)

50. Attribute-
defined
specialization
on Jobtype

51. d. Single relation with multiple type
attributes
 Create a single relation schema L with attributes
Attrs(L) = {K, A1, …, A n} U {attributes of S1} U…
U {attributes of Sm} U {T1, …, T n} and PK(L)=K
 This option is for specialization whose subclasses
are overlapping, and each Ti, 1 < i < m, is a
Boolean attribute indicating whether a tuple
belongs to subclass Si.

52. o

53. Approach Pre-conditions Considerations Trade-off
A(Super and Sub
relations)
None Most flexible but
incurs a join cost
B(Sub relations) Specialization
must be total
Specialization
must be disjoint
In order to query
all entities of the
supertype one
must OUTER
UNION the
subtype relations
(and project to
Attr(C),
technically)
C (One relation,
one type)
Specialization
must be disjoint
If one table is
desirable
Potential for a
large NULL cost
D (One relation,
Multiple type)
None One table is
desired but
specialization is
overlapping
Also very flexible
but incurs a NULL
cost

54.  All the Superclasses and the subclass must have
the same primary key. Otherwise model as a
Category
 Apply any of the options discussed in
Generalization/Specialization mapping(former
topic)

55.  For mapping a category whose defining superclass have
different keys, it is customary to specify a new key
attribute, called a surrogate key, when creating a relation
to correspond to the category.
 Let C₁,C₂,…,Cm be the entity types participating in the
union and S be the union type. Create a relation for S and
surrogate key ks so that PK(S)=ks, and also add ks to
each Attr(Ci) as a foreign key into S. If all the Cis have the
same primary key type, use that as PK(S) instead.

58. Websites :
• http://web.cse.ohiostate.edu/~gurari/course/cs
e670/
• http://home.iitj.ac.in/~ramana/ch7-
mappingER-EER-relations.pdf
• http://jcsites.juniata.edu/faculty/rhodes/dbms/
eermodel.htm
• http://www.cs.montana.edu/~halla/csci440/n9
/n9.html