This is contents for advance Database Management System for BSC CSIT Tribhuvan University, Kathmandu.

1. ADBMS
By: Dabbal S. Mahara
2018

2. The Entity (Review)
 Entity Relationship (ER) Model – represents an object
 Physical – person, car
 Conceptual – school, company
 ER model is based on the perception of the real world
as a collection of objects with attributes
 Attributes – describe the entity
 Single, Multi-value
 Composite, Simple
 Derived, Stored
EER Modeling 2

3. What is an EER Model?
 Enhanced Entity Relationship (EER) – Data Modeling
 EER shows complex relationships between objects in a database
(multimedia, geographical).
 It includes all the modelling concepts of ER modeling, in addition, it
incorporates additional semantic data modeling concepts:
– Subclass/superclass
– Specialization/generalization
– Categorization
– Aggregation
 Associated with these concepts is the important mechanism of
attribute and relationship inheritance.
EER Modeling 3

4. EER Modeling 4
Why EER
 The ER modeling concepts are not sufficient for
representing new database applications, which have
more complex requirements than do the more traditional
applications.
 Additional semantic data modeling concepts must be
used to represent these requirements as accurately and
clearly as possible.

5. Subclass/Superclass
 An entity type may have additional meaningful subgroupings of its
entities that need to be represented explicitly because of their
significance to the database application.
 These subgroupings of an entity are called subclass of the entity.
 The entity itself is called the superclass.
 For example: the members of EMPLOYEE entity type may be
grouped further into SECRETARY, ENGINEER, TECHNICIAN,
MANAGER, SALARIED_EMPLOYEE, HOURLY_EMPLOYEE
and so on.
 In this example, EMPLOYEE is a superclass and other
subgroupings are subclasses.
5EER Modeling

6. EER Modeling 6
Subclasses and Superclasses
Every entity that is a member of one of these
subgroupings is also an employee
Superclasses: EMPLOYEE
Subclasses: SECRETARY, ENGINEER,
TECHNICIAN,
SALARIED_EMPLOYEE,
HOURLY_EMPLOYEE
 The relationship between a superclass and any one of its
subclasses is called a superclass/subclass or simply
class/subclass relationship.
EMPLOYEE
SECRETARY
ENGINEER
TECHNICIAN
SALARIED_EMPLOYEE
HOURLY_EMPLOYEE

7. EER Modeling 7
Subclasses vs. Superclasses
 The set of entities in each subclasses is a subset of the
entities that belong to EMPLOYEE
 Each is called a subclass of EMPLOYEE
 EMPLOYEE is the superclass for each of these
subclasses
 The relationship between a superclass and any one of its
subclass is called a superclass/subclass or
class/subclass relationship.
e.g., EMPLOYEE/SECRETARY and EMPLOYEE/TECHNICIAN are
two class/subclass relationships.

8. EER Modeling 8
Why class/subclass relationships
 Certain attributes may apply to some but not all entities
of the superclass.
– A subclass is defined in order to group the entities to which
these attributes apply.
– The members of the subclass may still share the majority of their
attributes with the other members of the superclass.
EMPLOYEE (Fname, Lname, SSN, Addr)
SECRETARY (Fname, Lname, SSN, Addr, TypingSpeed)
ENGINEER (Fname, Lname, SSN, Addr, EngType)
TECHNICIAN (Fname, Lname, SSN, Addr, TGrade)

9. EER Modeling 9
Properties of Superclasses and
Subclasses
 A member entity of the subclass represents the same
real-world entity as some member of the superclass.
 The subclass member is the same as the entity in the
superclass, but in a distinct specific role.
 When implementing a superclass/subclass
relationship, a member of the subclass may be
represented as a distinct database object – a distinct
record that is related via the key attribute to its
superclass entity.

10. EER Modeling 10
Properties of Superclasses and
Subclasses (cont.)
 An entity CANNOT exist in the DB merely by being a
member of a subclass. It must also be a member of
the superclass.
 An entity can be a member of more than one subclass.
– Example: A salaried employee who is also an engineer belongs to the
two subclasses ENGINEER and SALARIED_EMPLOYEE
 It is not necessary that every entity in a superclass be a
member of some subclass
– Example: A technical writer is an employee but does not belong to any
subclasses.

11. EER Modeling 11
Example
EMPLOYEE
SECRETARY
TECHNICIAN

d
Fname
Lname SSN
TypingSpeed
TGrade
ENGINEER
EngType
SECRETARY
Fname, Lname, SSN, Addr TypingSpeed
TECHNICIAN
Fname, Lname, SSN, Addr, TGrade
ENGINEER
Fname, Lname, SSN, Addr, EngType
Addr EMPLOYEE
Fname, Lname, SSN, Addr

12. Model Shapes
 When you have more than one subclass based on the
same defining attribute (JobType), use
 To show class/subclass relationships, use
– Used for relationships between entity types
 To show relationship between two different entity types,
use
U
EER Modeling 12

13. EER Modeling 13
Type inheritance
 The type of an entity is defined by the attributes it
possesses and the relationship types which it
participates.
 An entity that is a member of a subclass inherits all the
attributes of the entity as a member of the superclass, as
well as all the relationships in which the superclass
participates.

14. EER Modeling 14
Example
SECRETARY
d
TECHNICIAN ENGINEER
d
SALARIED_EMP
HOURLY_EMPMANAGER

EMPLOYEE
MANAGES
PROJECT
BELONGS_TO
TRADE_UNION
WORKSDEPARTMENT
Entity Type: Relationship Type
EMPLOYEE: WORKS
SECRETARY: WORKS
TECHNICIAN: WORKS
ENGINEER: WORKS
MANAGER: WORKS, MANAGES
SALARIED_EMP: WORKS
HOURLY_EMP: WORKS, BELONGS_TO
TypingSpeed
TGrade EngType

15. EER Modeling 15
Specialization
 The process of defining a set of subclass of an entity
type is called specialization.
 The set of subclasses that form a specialization is
defined on the basis of some distinguishing
characteristics of the entities in the superclass.
 For example: {SECRETARY, ENGINEER, TECHNICIAN} is a
specialization of EMPLOYEE based on the job type of each entity.
 The same entity type may have several specializations based on
different distinguishing characteristics

16. EER Modeling 16
Example
SECRETARY
d
TECHNICIAN ENGINEER
d
SALARIED_EMP
HOURLY_EMPMANAGER

EMPLOYEE
MANAGES
PROJECT
BELONGS_TO
TRADE_UNION
WORKSDEPARTMENT
TypingSpeed
TGrade EngType
Fname
Lname SSN
Addr

17. EER Modeling 17
Specialization (cont.)
 The EMPLOYEE entity type may have two
specializations:
– Based on the methods of pay:
{SALARIED_EMPLOYEE, HOURLY_EMPLOYEE}
– Based on the type of job:
{SECRETARY, ENGINEER, TECHNICIAN}
 A subclass can participate in specific relationship type.

18. EER Modeling 18
Diagrammatically representation of
specialization in an EER diagram
Esuper
…
E1
…
E2
…
Specific attributes Specific attributes

19. EER Modeling 19
Specialization
The specialization process allows us to do the following:
 Define a set of subclass of an entity type
 Establish additional specific attributes with each
subclass
 Establish additional specific relationship types between
each subclass and other entity types or other subclasses

20. Example: Specialization
EER Modeling 20

21. Example:
 The Artist superclass is specialized into subclasses
Singer and Actor.
 Remember Actor is an artist and Singer is also an artist.
 An Artist has unique ANR and artist name.
 Singer has music style.
 An actor can play in 0 to N movies and a single movie
can have 1 to N actors.
 Movie has unique movie number and title.
EER Modeling 21

22. EER Modeling 22
Generalization
 Generalization is the reverse of specialization process.
 It defines a generalized entity type from the given entity
types.
 Specialization is top down of conceptual refinement.
 Generalization is bottom-up process of conceptual
synthesis.

23. EER Modeling 23
Generalization (cont.)
CAR
LicensePlateNo
Price
MaxSpeed
VehicleID
NoOfPassengers
TRUCK
LicensePlateNo
Price
Tonnage
VehicleID
NoOfAxies
VEHICLE
LicensePlateNoPriceVehicleID
d
CAR
MaxSpeed
NoOfPassengers
TRUCK Tonnage
NoOfAxies

24. EER Modeling 24
Generalization (cont.)
 We can view {CAR, TRUCK} as a specialization of
VEHICLE
 Alternatively, we can view VEHICLE as a generalization
of CAR and TRUCK

25. EER Modeling 25
Generalization (cont.)
 Generalization suppresses the difference among several
entity types, identifying their common features, and
generalize them into a single superclass of which the
original types are special subclasses.
 The decision as to which process, generalization or
specialization, is more appropriate in a particular
situation is often subjective.

26. EER Modeling 26
Constraints on
Specialization/Generalization
Constraints on which entities can be members of a given
lower level entity set.
 Condition defined constraint
 Disjointness vs. Overlap Constraints
 A total specialization vs. a partial specialization

27. EER Modeling 27
Condition Defined Constraint
 If we can determine exactly those entities that will become members
of each subclass by a condition, the subclasses are called
predicate-defined (or condition-defined) subclasses. Here, condition
is a constraint that determines subclass members.
 For example, if the EMPLOYEE entity type has an attribute
JobType, we can specify the condition of membership in the
SECRETRY subclass by a condition (JobType=“secretary”), which
we call defining predicate of the subclass.
 We display predicate-defined subclass by writing the predicate
condition next to the line that connects the subclass to the
specialization circle.
 If all subclasses have membership condition on the same attribute of
the superclass, it is called an attribute defined-subclass. And, the
attribute is called the defining attribute.

28. EER Modeling 28
Example
EMPLOYEE
SECRETARY
TECHNICIAN

d
Fname
Lname SSN
TypingSpeed
TGrade
ENGINEER
EngType
JobType
JobType
“Secretary”
“Technician”
“Engineer”

29. EER Modeling 29
Disjointness Constraint
 Disjointness(d) constraint specifies that the
subclasses of the specialization must be disjointed (an
entity can be a member of at most one of the subclasses
of the specialization)
 In EER diagram, d in the circle stands for disjoint.

30. EER Modeling 30
Example
EMPLOYEE
Name SSN BirthDate Address
SECRETARY
d
TypeSpeed
TECHNICIAN
TGrade
ENGINEER
EngType
d
SALARIED_EMP
Salary
HOURLY_EMP
PayScale
Disjoint subclasses Disjoint subclasses

31. EER Modeling 31
Overlap Constraint
 Overlap(o) specifies that the subclasses are not
constrained to be disjoint, i.e., the same (real-world)
entity may be a member of more than one subclass of
the specialization.
 Overlap is the default constraint and displayed by
placing an o in the circle.

32. EER Modeling 32
Completeness constraint
Completeness constraint may be total or partial.
 A total specialization constraint specifies that every
entity in the superclass must be a member of some
subclass in the specialization.
 Represented by a double line connecting the
superclass to the circle.

33. Example: Disjoint and Total
Specialization
33
• According to our model, the specialization is total because A person is
either professor or student.
• The specializations is disjoint because a student cannot be professor at a
time.
EER Modeling

34. EER Modeling 34
Completeness constraint (cont.)
 A partial specialization allows an entity not to belong to
any of the subclasses, using a single line in EER.
e.g., if some EMPLOYEE entities, for example, sales
representatives, do not belong to any of the subclasses
{SECRETARY, ENGINEER, TECHNICIAN}, then the specialization
is partial.
 Represented by a single line connecting the superclass
to the circle.

35. Example: Partial and Overlap constraint
on specialization
EER Modeling 35
• The specialization is partial because not all artists are singer and actors,
some may be Painter as well.
• It is overlapped because some singers may be actors.

36. EER Modeling 36
Four Possible Constraints
 The disjointness and completeness constraints are
independent.
 There are four possible constraints on specialization:
– Disjoint, total
– Disjoint, partial
– Overlapping, total
– Overlapping, partial

37. EER Modeling 37
Some insertion and deletion rules
applied to specialization/generalization
 Deleting an entity from a superclass implies that it is
automatically deleted from all the subclasses to which it
belongs
 Inserting an entity in a superclass implies that the entity
is mandatorily inserted in all applicable subclasses.
 Inserting an entity in a superclass of a total
specialization implies that the entity is mandatorily
inserted in at least one of the subclasses of the
specialization.

38. EER Modeling 38
Specialization and Generalization
Hierarchies and Lattices
 A subclass itself may have further subclasses specified on it,
forming a hierarchy or lattice of specializations. For example,
ENGINEERING_MANAGER can be a subclass of ENGINEER
that can be a subclass of EMPLOYEE.
 A specialization hierarchy has the constraint that every subclass
participates as a subclass in only one class/subclass relationship;
that is, each subclass has only one superclass, which results in a
tree structure.
 A specialization lattice, a subclass (also called a shared
subclass) can be a subclass in more than one class/subclass
relationship. This leads to the concept known as multiple
inheritance. That is, a subclass can have multiple superclasses.

39. Example: Specialization Lattice
39
• Trike is a shared subclass of superclasses MOTORCYCLE and
CAR and inherits attributes and relationships from both.
• Similarly, Amphibian is shared subclass off CAR and BOAT and
inherits the attributes and relationships from both.
EER Modeling

40. EER Modeling 40
The differences between the
specialization and generalization
 The specialization process corresponds to a top-down
conceptual refinement process during conceptual
schema design.
– we typically start with an entity type and then define subclasses
of the entity type by successive specialization;
 The generalization process corresponds to a bottom-up
conceptual synthesis.
– we typically start with an entity type of subclasses and then
define superclasses of the entity type by successive
generalization.

41. EER Modeling 41
Categories or Union Types
 It is possible that single superclass/subclass relationship has more
than one superclasses representing different entity types.
 A category is a subclass that has several possible superclasses.
 Each superclass represents different entity types.
 In this case, the subclass will represent a collection of objects that is
a subset of the UNION of the superclasses; we call such a subclass
a union type or a category.
 A category has two or more superclasses that may represent distinct
entity types, whereas non-categorty superclass/subclass
relationships always have a single superclass.

42. Categorization
 Inheritance in case of categorization corresponds to an
entity inheriting attributes and relationships of that
superclass it is a member of (selective inheritance).
 Example:
42EER Modeling

43. Example:
43
 In above example, super classes company and person
categorized into Account_holder subclass.
 In other words, the account_holder entities are the subset of
union of person and company entities.
 If the category is total then it implies that all persons in the
company are account holders. In this case we can model this as
specialization with Account_holder as a superclass and person
and company as subclasses.
 If the category would be partial, it could not be modeled as
specialization.
 Selective inheritance implies that some account holders inherit
their attributes from person entity while rest of entities inherit from
company entity.
EER Modeling

44. EER Modeling 44
Modeling of UNION Types Using Categories
(cont.)
OWNER
U
PERSON
Address
Name
SSN
DriverLicenseNo
BANK
BAddressBName
COMPANY
CAddressCName
U
OWNS
REGISTERED_VEHICLE
CYear
PurchaseDate
U
U
CAR TRUCK
LienOrRegular
CModel
CMake
CStyle
VehicelId
TMake TYear
TModel
Tonnage
VehicleId
M
N

45. EER Modeling 45
Modeling of UNION Types Using
Categories (cont.)
 Two categories in car registration database.
– OWNER is a subclass of the union of PERSON, BANK, and
COMPANY
– REGISTRERED_VEHICLE is a subclass of the union of CAR
and TRUCK
 An entity that is a member of OWNER must exist in only
one of the superclass.
 Attribute inheritance works more selectively in the case
of categories.
e.g., each OWNER entity inherits the attributes of a COMPANY, a
PERSON, or a BANK, depending on the superclass to which the
entity belongs.

46. EER Modeling 46
Partial vs. Total Categories
 A category can be total or partial
U
PERSON BANK
ACCOUNT_
HOLDER
U
HAS_
ACCT
BANK
C1 C2
U
BUILDING LOT
PROPERTY
U
Partial
category
Total
category

47. EER Modeling 47
A category Or A Specialization
 The superclass of a category may have different key attributes.
 If a category is total (not partial), it may be represented alternatively
as a specialization, and the choice of which representation to use is
subjective.
U
BUILDING LOT
PROPERTY
U
d
BUILDING LOT
PROPERTY
Category Specialization

48. EER Modeling 48
A category Or A Specialization (cont.)
 If the two classes represent the same type of entities and
share numerous attributes, including the same key
attributes, specialization/generalization is preferred;
otherwise, categorization is more appropriate.

49. Aggregation
 Aggregation is an abstraction through which relationship
sets are treated as high-level entity sets and can
participate in relationship sets.
 This means that the entities that are related by particular
relationship type can be combined into a higher-level
aggregate entity types.
 Can be useful when aggregate entity type has its own
attribute types and/ or relationship types.
49EER Modeling

50. Example: Aggregation
50EER Modeling

51. Example: Aggregation
 A consultant works on 0 to N projects.
 A project is worked upon by 1 to M consultants.
 Both entity types and relationship types can be aggregated to an
aggregate concept participation. This aggregate has its own attribute
date which represents the date a consultant start work on a project.
 The aggregate also participates in a relationship type with contract.
 The participation should lead minimum 1 and maximum 1 contracts.
 The contract can be based upon minimum 1 and maximum M
participation of consultants in projects.
51EER Modeling

52. Procedure to design EER Model
 Identify the entity types.
 Identify the relationship types and assert their degree.
 Assert cardinality ratios and participation constraints.
 Identify attributes and assert whether they are simple/composite;
single/multivalued
 Link each attribute type with an entity type and a relationship types.
 Denote the key entity types of each entity type
 Identify weak entity types and their partial keys.
 Apply abstractions and generalizations, categorization/aggregation.
 Assert the characteristics of abstraction: disjoint/overlapping,
total/partial
 Document the semantics that cannot be represented in EER
schema as separate business rules.
52EER Modeling

53. Limitations of EER Model
 Temporal aspects cannot be modeled.
 Consistency among multiple relationship types
cannot be enforced.
 Integrity rules or behavior cannot be specified.
53EER Modeling

54. Step 8: Options for Mapping Specialization or
Generalization
 Convert each specialization with m subclasses {S1, S2, ..., Sm} and
(generalized) superclass C, where the attributes of C are {k, a1,
...an} and k is the (primary) key, into relation schemas using one of
the following options:
Option 8A: Multiple relations—superclass and subclasses
 Create a relation L for C with attributes Attrs(L) = {k, a1, ..., an} and
PK(L) = k.
 Create a relation Li for each subclass Si, 1 ≤ i ≤ m, with the
attributes Attrs(Li) = {k} ∪ {attributes of Si} and PK(Li) = k.
 This option works for any specialization (total or partial, disjoint or
overlapping).
54

55. Example: 8A
55

56. Option 8B: Multiple relations—subclass relations only
 Create a relation Li for each subclass Si, 1 ≤ i ≤ m, with the
attributes Attrs(Li) = {attributes of Si} ∪ {k, a1, ..., an} and PK(Li) = k.
 This option only works for a specialization whose subclasses are
total (every entity in the superclass must belong to (at least) one of
the subclasses).
 Additionally, it is only recommended if the specialization has the
disjointedness constraint.
 If the specialization is overlapping, the same entity may be
duplicated in several relations.
56
Step 8: Options for Mapping Specialization or
Generalization

57. Example: 8B
57

58. Option 8C: Single relation with one type attribute
 Create a single relation L with attributes Attrs(L) = {k, a1,
..., an} ∪ {attributes of S1} ∪ ... ∪ { attributes of Sm} ∪ {t}
and PK(L) = k.
 The attribute t is called a type (or discriminating)
attribute whose value indicates the subclass to which
each tuple belongs, if any.
 This option works only for a specialization whose
subclasses are disjoint, and has the potential for
generating many NULL values if many specific attributes
exist in the subclasses.
58
Step 8: Options for Mapping Specialization or
Generalization

59. Example: 8C
59

60. Option 8D: Single relation with multiple type attributes
 Create a single relation schema L with attributes Attrs(L)
= {k, a1, ..., an} ∪ {attributes of S1} ∪ ... ∪ {attributes of
Sm} ∪ {t1, t2, ..., tm} and PK(L) = k.
 Each ti, 1 ≤ i ≤ m, is a Boolean type attribute indicating
whether a tuple belongs to subclass Si.
 This option is used for a specialization whose
subclasses are overlapping (but will also work for a
disjoint specialization).
60
Step 8: Options for Mapping Specialization or
Generalization

61. Example: 8D
61

62. Step 9: Mapping of Shared Subclasses (Multiple
Inheritance)
 A shared subclass is a subclass of several superclasses,
indicating multiple inheritance.
 These classes must all have the same key attribute;
otherwise, the shared subclass would be modeled as a
category.
 We can apply any of the options discussed in step 8 to a
shared subclass, subject to the restrictions discussed in
step 8 of the mapping algorithm.
62

63. Figure specialization Lattice
63

64. Mapping of Specialization hierarchy or
Lattice
 When we have a multilevel specialization (or generalization)
hierarchy or lattice, we do not have to follow the same mapping
option for all the specializations.
 Instead, we can use one mapping option for part of the hierarchy or
lattice and other options for other parts.
 Here the option 8A for
PERSON/{EMPLOYEE, ALUMNUS, STUDENT}
 Option 8C for
EMPLOYEE/{STAFF, FACULTY, STUDENT_ASSISTANT} by
including the type attribute Employee_type
64

65. And option 8D for : STUDENT_ASSISTANT/ {
RESEARCH_ASSISTANT , TEACHING_ ASSISTANT} by including
the type attributes Ta_flag and Ra_flag in EMPLOYEE,
STUDENT/STUDENT_ASSISTANT by including the type
attributes Student_assist_flag in STUDENT,
And STUDENT/{GRADUATE_STUDENT,
UNDERGRADUATE_STUDENT} by including the type
attributes Grad_flag and Undergrad_flag in STUDENT.
EER Modeling 65
Mapping of Specialization hierarchy or
Lattice

66. Relation Schema for above
Lattice
66

67. Step 10: Mapping of Categories (Union Types)
 A category (or union type) is a subclass of the union of two or more
superclasses that can have different keys because they can be of
different entity types.
 For mapping a category whose defining superclasses 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.
 The keys of the defining classes are different, so we cannot use any
one of them exclusively to identify all entities in the category.
67

68. 68
Figure a

69.  In our example in Figure a we create a
relation OWNER to correspond to the
OWNER category, as illustrated in Figure b,
and include any attributes of the category in
this relation.
 The primary key of the OWNER relation is
the surrogate key, which we called
Owner_id.
 We also include the surrogate key attribute
Owner_id as foreign key in each relation
corresponding to a superclass of the
category, to specify the correspondence in 69
Step 10: Mapping of Categories (Union Types)

70. 70
‣ For a category whose superclasses have the same key, such
as VEHICLE in Figure a, there is no need for a surrogate key.
‣ The mapping of the REGISTERED_VEHICLE category,
which illustrates this case, is also shown in Figure b.
Step 10: Mapping of Categories (Union Types)

71. 71
Figure b

72. Assignment #1
Deadline: March 19, 2018
72
See next three slides

73. 1. Map the BANK ER schema of following figure into a relational
schema. Specify all primary keys and foreign keys.
73

74. 2. Following figure shows an ER schema for a database that can be used to keep track of
transport ships and their locations for maritime authorities. Map this
schema into a relational schema and specify all primary keys and foreign
keys.
74

75. 3. Following figure shows an example of an EER diagram for a small
private airport database that is used to keep track of airplanes, their
owners, airport employees, and pilots. Map following ER-Model to
Relational schema
75

76. Thank you !
76