ENHENCED RELATIONSHIP MODELING SUMMURY.

WHY ENHENCED RELATIONSHIP MODELLING?

As the basic concepts of ER modelling are often insufficient to represent the requirements of
the newer, more complex applications, since the ER modelling was traditionally or
administrative based modelling system, this stimulated the need to develop additional
“semantic” modelling concepts. Many different semantic data models have been proposed
and some of the most important semantic concepts have been successfully incorporated into
the original ER model. The ER model supported with additional semantic concepts is called
the Enhanced Entity–Relationship (EER) model.
SPECIALIZATION/GENERALIZATION.
The concept of specialization/generalization is associated with special types of entities
known as superclasses and subclasses, and the process of attribute inheritance.
SUPERCLASS.
An entity type that includes one or more distinct subgroupings of its occurrences, which
must be represented in a data model.
SUBCLASS.
A distinct subgrouping of occurrences of an entity type, which must be represented in a data
model.

For example, the entities that are members of the Staff entity type may be classified as
Manager, SalesPersonnel, and Secretary. In other words, the Staff entity is referred to as
the superclass of the Manager, SalesPersonnel, and Secretary subclasses. The
relationship between a superclass and any one of its subclasses is called a
superclass/subclass relationship. For example, Staff/Manager has a superclass/subclass
relationship.
SUPERCLASS/SUBCLASS RELATIONSHIP.
Each member of a subclass is also a member of the superclass. The relationship between a
superclass and a subclass is one-to-one (1:1).
Some superclasses may contain overlapping subclasses, as illustrated by a member of staff
who is both a Manager and a member of Sales Personnel. In this example, Manager and
SalesPersonnel are overlapping subclasses of the Staff superclass. On the other hand, not
every member of a superclass is necessarily a member of a subclass; for example,
members of staff without a distinct job role such as a Manager or a member of Sales
Personnel.
We can use superclasses and subclasses to avoid describing different types of staff with
possibly different attributes within a single entity. For example, Sales Personnel may
have special attributes such as salesArea and carAllowance. If all staff attributes and those
specific to particular jobs are described by a single Staffentity, this may result in a lot of
nulls for the job-specific attributes. Clearly, Sales Personnel have common attributes with
other staff, such as staffNo, name, position, and salary. However, it is the unshared attributes
that cause problems when we try to represent all members of staff within a single entity. We
can also show relationships that are associated with only particular types of staff (sub-classes)
and not with staff, in general. For example, Sales Personnel may have distinct relationships
that are not appropriate for all staff, such as SalesPersonnelUsesCar.
If we consider an all staff table which consists off all staffs. A consequence of holding all
staff details in one relation is that while the attributes appropriate to all staff are filled
(namely, staffNo, name, position, and salary), those that are only applicable to particular job
roles are only partially filled or having nulls.

For example, the attributes associated with the Manager (mgrStartDate and bonus),
SalesPersonnel (salesArea and carAllowance), and Secretary (typingSpeed) subclasses have
values for those members in these subclasses. In other words, the attributes associated with
the Manager, SalesPersonnel, and Secretary subclasses are empty for those members of staff
not in these subclasses.There are two important reasons for introducing the concepts of
superclasses and subclasses into an ER model. First, it avoids describing similar
concepts more than once, thereby saving time for the designer and making the ER
diagram more readable. Second, it adds more semantic information to the design in a
form that is familiar to many people.

ATTRIBUTES INHERITANCE.
For example, a member of the SalesPersonnel subclass INHERITS all the attributes of the
Staff superclass, such as staffNo, name, position, and salary together with those
specifically associated with the SalesPersonnel subclass, such as salesArea and
carAllowance.
NB:
A subclass is an entity in its own right and so it may also have one or more sub-classes. An
entity and its subclasses and their subclasses, and so on, is called a type hierarchy. Type
hierarchies are known by a variety of names, including specialization hierarchy (for
example, Manager is a specialization of Staff), generalization hierarchy (for example,
Staff is a generalization of Manager), and IS-A hierarchy (for example, Manager IS-A
(member of) Staff). We describe the process of specialization and generalization in the
following sections. A subclass with more than one superclass is called a shared subclass.
In other words, a member of a shared subclass must be a member of the associated
super-classes. As a consequence, the attributes of the superclasses are inherited by the
shared subclass, which may also have its own additional attributes. This process is
referred to as multiple inheritance.
SPECIALIZATION PROCESS.
The process of maximizing the differences between members of an entity by identifying their
distinguishing characteristics.
Specialization is a top-down approach to defining a set of superclasses and their related
subclasses. The set of subclasses is defined on the basis of some distinguishing characteristics
of the entities in the superclass. When we identify a set of subclasses of an entity type, we
then associate attributes specific to each subclass (where necessary), and also identify any
relationships between each subclass and other entity types or subclasses (where necessary).
For example, consider a model where all members of staff are represented as an entity called
Staff. If we apply the process of specialization on the Staff entity, we attempt to identify
differences between members of this entity, such as members with distinctive attributes
and/or relationships. As described earlier, staff with the job roles of Manager, Sales
Personnel, and Secretary have distinctive attributes and therefore we identify Manager,
SalesPersonnel, and Secretary as subclasses of a specialized Staffsuperclass.

GENERELIZATION.
The process of minimizing the differences between entities by identifying their common
characteristics.
The process of generalization is a bottom-up approach, that results in the identification of
a generalized superclass from the original entity types. For example, consider a model where
Manager, SalesPersonnel, and Secretary are represented as distinct entity types. If we apply
the process of generalization on these entities, we attempt to identify similarities between
them, such as common attributes and relationships. As stated earlier, these entities share
attributes common to all staff, and therefore we identify Manager, SalesPersonnel, and
Secretary as subclasses of a generalized Staff superclass. As the process of
generalization can be viewed as the reverse of the specialization process, we refer to this
modeling concept as “specialization/generalization.”
consider the specialization/generalization of the Staff entity into subclasses that represent job
roles. The Staff superclass and the Manager, SalesPersonnel, and Secretary subclasses can be
represented in an EER diagram, as illustrated in Figure below. Note that the Staff superclass
and the subclasses, being entities, are represented as rectangles. The subclasses are
attached by lines to a triangle that points toward the superclass. The label below the
specialization/generalization triangle, shown as {Optional, and}, describes the constraints on
the relationship between the superclass and its subclasses.

Attributes that are specific to a given subclass are listed in the lower section of the
rectangle representing that subclass. For example, salesArea and carAllowance attributes
are associated only with the SalesPersonnel subclass, and are not applicable to the Manager
or Secretary subclasses. Similarly, we show attributes that are specific to the Manager
(mgrStartDate and bonus) and Secretary (typingSpeed) subclasses. Attributes that are
common to all subclasses are listed in the lower section of the rectangle representing the
superclass. For example, staffNo, name, position, and salary attributes are common to all
members of staff and are associated with the Staff superclass. Note that we can also show
relationships that are only applicable to specific subclasses. For example, in Figure above, the
Manager subclass is related to the Branch entity through the Manages relationship, whereas
the Staff superclass is elated to the Branch entity through the Has relationship.
For example, another specialization of the Staff entity may produce the subclasses
FullTimePermanent and PartTimeTemporary, which distinguishes between the types of
employment contract for members of staff.
As described earlier, a superclass and its subclasses and their subclasses, and so on, is
called a type hierarchy. An example of a type hierarchy is shown in Figure below, where
the job roles specialization/generalization shown in Figure above are expanded to show a
shared subclass called SalesManager and the subclass called Secretary with its own subclass
called AssistantSecretary. In other words, a member of the SalesManager shared subclass
must be a member of the SalesPersonnel and Manager subclasses as well as the Staff
superclass. As a consequence, the attributes of the Staff superclass (staffNo, name,
position, and salary), and the attributes of the subclasses SalesPersonnel (salesArea and
carAllowance) and Manager (mgrStartDate and bonus) are inherited by the
SalesManager subclass, which also has its own additional attribute called startDate.
AssistantSecretary is a subclass of Secretary, which is a subclass of Staff. This means
that a member of the AssistantSecretary subclass must be a member of the Secretary
subclass and the Staff superclass. As a consequence, the attributes of the Staff superclass
(staffNo, name, position, and salary) and the attribute of the Secretary subclass
(typingSpeed) are inherited by the AssistantSecretary subclass, which also has its own
additional attribute called startDate.

CONSTRAINTS ON GENERALIZATION/SPECIALIZATION.
1.Participation constraint.
2.Disjoint constraint.

1.PARTICIPTION CONSTRAINT.
Determines whether every member in the superclass must participate as a member of a
subclass.
A participation constraint may be mandatory or optional. A superclass/subclass
relationship with mandatory participation specifies that every member in the superclass
must also be a member of a subclass. To represent mandatory participation,
“Mandatory” is placed in curly brackets below the triangle that points towards the
superclass. For example, in the contract of employment specialization/generalization is
mandatory participation, which means that every member of staff must have a contract of
employment.
A superclass/subclass relationship with optional participation specifies that a member of a
superclass need not belong to any of its subclasses. To represent optional participation,
“Optional” is placed in curly brackets below the triangle that points towards the
superclass. For example, in the job role specialization/generalization has optional
participation, which means that a member of staff need not have an additional job role such
as a Manager, Sales Personnel, or Secretary.

2.DISJOINT CONSTRAINT.
Describes the relationship between members of the subclasses and indicates whether it is
possible for a member of a superclass to be a member of one, or more than one, subclass.
The disjoint constraint only applies when a superclass has more than one subclass.If the
subclasses are disjoint, then an entity occurrence can be a member of only one of the
subclasses. To represent a disjoint superclass/subclass relationship, “Or” is placed next to
the participation constraint within the curly brackets. For example, in the subclasses of
the contract of employment specialization/ generalization is disjoint, which means that a
member of staff must have a full-time permanent or a part-time temporary contract,
but not both.
If subclasses of a specialization/generalization are not disjoint (called nondisjoint), then an
entity occurrence may be a member of more than one subclass. To represent a nondisjoint
superclass/subclass relationship, “And” is placed next to the participation constraint
within the curly brackets. For example, in the job role specialization/generalization is
nondisjoint, which means that an entity occurrence can be a member of both the Manager,
SalesPersonnel, and Secretary subclasses. This is confirmed by the presence of the shared
subclass called SalesManager. Note that it is not necessary to include the disjoint
constraint for hierarchies that have a single subclass at a given level and for this reason
only the participation constraint is shown for the SalesManager and AssistantSecretary
subclasses.
The disjoint and participation constraints of specialization and generalization are distinct,
giving rise to four categories: “mandatory and disjoint,” “optional and disjoint,”
“mandatory and nondisjoint,” and “optional and nondisjoint.”

AGGREGATION.
Represents a “has-a” or “is-part-of” relationship between entity types, where one represents
the “whole” and the other the “part.”
Sometimes we want to model a “has-a” or “is-part-of” relationship, in which one entity
represents a larger entity (the “whole”), consisting of smaller entities (the “parts”). This
special kind of relationship is called an aggregation. Aggregation does not change the
meaning of navigation across the relationship between the whole and its parts, or link
the lifetimes of the whole and its parts. An example of an aggregation is the Has
relationship, which relates the Branch entity (the “whole”) to the Staff entity (the
“part”).
This EER diagram displays two examples of aggregation, namely Branch Staff and Branch
Offers PropertyForRent. In both relationships, the Branch entity represents the “whole” and
therefore the open diamond shape is placed beside this entity.
COMPOSITION.
A specific form of aggregation that represents an association between entities, where there is
a strong ownership and coincidental lifetime between the “whole” and the “part.”
However, there is a variation of aggregation called composition that represents a strong
ownership and coincidental lifetime between the “whole” and the “part”. In a composite, the
“whole” is responsible for the disposition of the “parts,” which means that the composition
must manage the creation and destruction of its “parts.” In other words, an object may be part
of only one composite at a time.
NB:
Aggregation and composition should be used only when there is a requirement to emphasize
special relationships between entity types such as “has-a” or “is-part-of,” which has
implications on the creation, update, and deletion of these closely related entities.