THE ENHANCED ENTITY–RELATIONSHIP (EER) MODEL

The ER modeling concepts discussed in Chapter 3 are sufficient for representing many database
schemas for traditional database applications, which include many data-processing applications
in business and industry. Since the late 1970s, however, designers of database applications
have tried to design more accurate database schemas that reflect the data properties and
constraints more precisely. This was particularly important for newer applications of database
technology, such as databases for engineering design and manufacturing (CAD/CAM),1
telecommunications, complex software systems, and geographic information systems (GISs),
among many other applications. These types of databases have requirements that are more
complex than the more traditional applications. This led to the development of additional
semantic data modeling concepts that were incorporated into conceptual data models such as
the ER model. Various semantic data models have been proposed in the literature. Many of
these concepts were also developed independently in related areas of computer science, such
as the knowledge representation area of artificial intelligence and the object modeling area in
software engineering.

In this chapter, we describe features that have been proposed for semantic data models and
show how the ER model can be enhanced to include these concepts, which leads to the
enhanced ER (EER) model.2 We start in Section 4.1 by incorporating the concepts of
class/subclass relationships and type inheritance into the ER model. Then, in Section 4.2, we
add the concepts of specialization and generalization. Section 4.3 discusses the various types
of constraints on specialization/generalization, and Section 4.4 shows how the UNION
construct can be modeled by including the concept of category in the EER model. Section 4.5
gives a sample UNIVERSITY database schema in the EER model and summarizes the EER
model concepts by giving formal definitions. We will use the terms object and entity
interchangeably in this chapter, because many of these concepts are commonly used in
objectoriented models.

We present the UML class diagram notation for representing specialization and generalization
in Section 4.6, and we briefly compare these with EER notation and concepts. This serves as
an example of alternative notation, and is a continuation of Section 3.8, which presented basic
UML class diagram notation that corresponds to the basic ER model. In Section 4.7, we discuss
the fundamental abstractions that are used as the basis of many semantic data models. Section
4.8 summarizes the chapter.
For a detailed introduction to conceptual modeling, Chapter 4 should be considered a
continuation of Chapter 3. However, if only a basic introduction to ER modeling is desired,
this chapter may be omitted. Alternatively, the reader may choose to skip some or all of the
later sections of this chapter (Sections 4.4 through 4.8).

4.1 SUBCLASSES, SUPERCLASSES, AND INHERITANCE

The EER model includes all the modeling concepts of the ER model that were presented in
Chapter 3. In addition, it includes the concepts of subclass and superclass and the related
concepts of specialization and generalization (see Sections 4.2 and 4.3). Another concept
included in the EER model is that of a category or union type (see Section 4.4), which is used
to represent a collection of objects (entities) that is the union of objects of different entity types.
Associated with these concepts is the important mechanism of attribute and relationship
inheritance. Unfortunately, no standard terminology exists for these concepts, so we use the
most common terminology. Alternative terminology is given in footnotes. We also describe a
diagrammatic technique for displaying these concepts when they arise in an EER schema. We
call the resulting schema diagrams enhanced ER or EER diagrams.

The first enhanced ER (EER) model concept we take up is that of a subtype or subclass of an
entity type. As we discussed in Chapter 3, the name of an entity type is used to represent both
a type of entity and the entity set or collection of entities of that type that exist in the database.
For example, the entity type employee describes the type (that is, the attributes and
relationships) of each employee entity, and also refers to the current set of employee entities in
the company database. In many cases an entity type has numerous subgroupings or subtypes
of its entities that are meaningful and need to be represented explicitly because of their
significance to the database application. For example, the entities that are members of the
employee entity type may be distinguished further into secretary, engineer, manager,
technician, salaried_employee, hourly_employee, and so on. The set or collection of entities in
each of the latter groupings is a subset of the entities that belong to the employee entity set,
meaning that every entity that is a member of one of these subgroupings is also an employee.
We call each of these subgroupings a subclass or subtype of the employee entity type, and the
employee entity type is called the superclass or supertype for each of these subclasses. Figure
4.1 shows how to represent these concepts diagramatically in EER diagrams. (The circle
notation in Figure 4.1 will be explained in Section 4.2.)
We call the relationship between a superclass and any one of its subclasses a
superclass/subclass or supertype/subtype or simply class/subclass relationship.3 In our
previous example, employee/secretary and employee/technician are two class/subclass
relationships. Notice that a member entity of the subclass represents the same real-world entity
as some member of the superclass; for example, a secretary entity ‘Joan Logano’ is also the
employee ‘Joan Logano.’ Hence, the subclass member is the same as the entity in the
superclass, but in a distinct specific role. When we implement a superclass/subclass
relationship in the database system, however, we may represent a member of the subclass as a
distinct database object—say, a distinct record that is related via the key attribute to its
superclass entity. In Section 9.2, we discuss various options for representing
superclass/subclass relationships in relational databases.

An entity cannot exist in the database merely by being a member of a subclass; it must also be
a member of the superclass. Such an entity can be included optionally as a member of any
number of subclasses. For example, a salaried employee who is also an engineer belongs to the
two subclasses engineer and salaried_employee of the employee entity type. However, it is not
necessary that every entity in a superclass is a member of some subclass.

An important concept associated with subclasses (subtypes) is that of type inheritance. Recall
that the type of an entity is defined by the attributes it possesses and the relationship types in
which it participates. Because an entity in the subclass represents the same real-world entity
from the superclass, it should possess values for its specific attributes as well as values of its
attributes as a member of the superclass. We say that an entity that is a member of a subclass
inherits all the attributes of the entity as a member of the superclass. The entity also inherits all
the relationships in which the superclass participates. Notice that a subclass, with its own
specific (or local) attributes and relationships together with all the attributes and relationships
it inherits from the superclass, can be considered an entity type in its own right.

4.2 SPECIALIZATION AND GENERALIZATION

4.2.1 Specialization

Specialization is the process of defining a set of subclasses of an entity type; this entity type is
called the superclass of the specialization. The set of subclasses that forms a specialization is
defined on the basis of some distinguishing characteristic of the entities in the superclass. For
example, the set of subclasses {secretary, engineer, technician} is a specialization of the
superclass employee that distinguishes among employee entities based on the job type of each
employee. We may have several specializations of the same entity type based on different
distinguishing characteristics. For example, another specialization of the employee entity type
may yield the set of subclasses {salaried_employee, hourly_employee}; this specialization
distinguishes among employees based on the method of pay.

Figure 4.1 shows how we represent a specialization diagrammatically in an EER diagram. The
subclasses that define a specialization are attached by lines to a circle that represents the
specialization, which is connected in turn to the superclass. The subset symbol on each line
connecting a subclass to the circle indicates the direction of the superclass/subclass
relationship.5 Attributes that apply only to entities of a particular subclass—such as
TypingSpeed of secretary—are attached to the rectangle representing that subclass. These are
called specific (or local) attributes of the subclass. Similarly, a subclass can participate in
specific relationship types, such as the hourly_employee subclass participating in the
belongs_to relationship in Figure 4.1. We will explain the d symbol in the circles in Figure 4.1
and additional EER diagram notation shortly.

Figure 4.2 shows a few entity instances that belong to subclasses of the {secretary, engineer,
technician} specialization. Again, notice that an entity that belongs to a subclass represents the
same real-world entity as the entity connected to it in the EMPLOYEE superclass, even though
the same entity is shown twice; for example, e1 is shown in both employee and secretary in
Figure 4.2. As the figure suggests, a superclass/subclass relationship such as
employee/secretary somewhat resembles a 1:1 relationship at the instance level (see Figure
3.12). The main difference is that in a 1:1 relationship two distinct entities are related, whereas
in a superclass/subclass relationship the entity in the subclass is the same real-world entity as
the entity in the superclass but is playing a specialized role—for example, an employee
specialized in the role of secretary, or an employee specialized in the role of technician.

There are two main reasons for including class/subclass relationships and specializations. The
first is that certain attributes may apply to some but not all entities of the superclass entity type.
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. For example, in Figure 4.1 the secretary subclass has the specific attribute
Typing_speed, whereas the engineer subclass has the specific attribute Eng_type, but secretary
and engineer share their other inherited attributes from the employee entity type.
The second reason for using subclasses is that some relationship types may be participated in
only by entities that are members of the subclass. For example, if only hourly_employees can
belong to a trade union, we can represent that fact by creating the subclass hourly_employee
of employee and relating the subclass to an entity type trade_union via the belongs_to
relationship type, as illustrated in Figure 4.1.

4.2.2 Generalization

We can think of a reverse process of abstraction in which we suppress the differences among
several entity types, identify their common features, and generalize them into a single
superclass of which the original entity types are special subclasses. For example, consider the
entity types car and truck shown in Figure 4.3(a). Because they have several common attributes,
they can be generalized into the entity type vehicle, as shown in Figure 4.3(b). Both car and
truck are now subclasses of the generalized superclass vehicle. We use the term generalization
to refer to the process of defining a generalized entity type from the given entity types.

Notice that the generalization process can be viewed as being functionally the inverse of the
specialization process; we can view {car, truck} as a specialization of vehicle rather than
viewing vehicle as a generalization of car and truck. A diagrammatic notation to distinguish
between generalization and specialization is used in some design methodologies. An arrow
pointing to the generalized superclass represents a generalization process, whereas arrows
pointing to the specialized subclasses represent a specialization process. We will not use this
notation because the decision as to which process was followed in a particular situation is often
subjective.

So far we have introduced the concepts of subclasses and superclass/subclass relationships, as

well as the specialization and generalization processes. In general, a superclass or subclass
represents a collection of entities of the same type and hence also describes an entity type; that
is why superclasses and subclasses are all shown in rectangles in EER diagrams, like entity
types.

4.3 CONSTRAINTS AND CHARACTERISTICS OF SPECIALIZATION AND

GENERALIZATION HIERARCHIES

First, we discuss constraints that apply to a single specialization or a single generalization. For
brevity, our discussion refers only to specialization even though it applies to both specialization
and generalization. Then, we discuss differences between specialization/generalization lattices
(multiple inheritance) and hierarchies (single inheritance), and we elaborate on the differences
between the specialization and generalization processes during conceptual database schema
design.

4.3.1 Constraints on Specialization and Generalization

In general, we may have several specializations defined on the same entity type (or superclass),
as shown in Figure 4.1. In such a case, entities may belong to subclasses in each of the
specializations. A specialization may also consist of a single subclass only, such as the
{manager} specialization in Figure 4.1; in such a case, we do not use the circle notation.

In some specializations we can determine exactly the entities that will become members of
each subclass by placing a condition on the value of some attribute of the superclass. Such
subclasses are called predicate-defined (or condition-defined) subclasses. For example, if the
employee entity type has an attribute Job_type, as shown in Figure 4.4, we can specify the
condition of membership in the secretary subclass by the condition (Job_type = ‘Secretary’),
which we call the defining predicate of the subclass. This condition is a constraint specifying
that exactly those entities of the employee entity type whose attribute value for Job_type is
‘Secretary’ belong to the subclass. We display a predicate-defined subclass by writing the
predicate condition next to the line that connects the subclass to the specialization circle.

If all subclasses in a specialization have their membership condition on the same attribute of
the superclass, the specialization itself is called an attribute-defined specialization, and the
attribute is called the defining attribute of the specialization.6 In this case, all the entities with
the same value for the attribute belong to the same subclass. We display an attribute-defined
specialization by placing the defining attribute name next to the arc from the circle to the
superclass, as shown in Figure 4.4.

When we do not have a condition for determining membership in a subclass, the subclass is
called user-defined. Membership in such a subclass is determined by the database users when
they apply the operation to add an entity to the subclass; hence, membership is specified
individually for each entity by the user, not by any condition that may be evaluated
automatically.

Two other constraints may apply to a specialization. The first is the disjointness constraint,
which specifies that the subclasses of the specialization must be disjoint sets. This means that
an entity can be a member of at most one of the subclasses of the specialization. A
specialization that is attribute-defined implies the disjointness constraint (if the attribute used
to define the membership predicate is single- valued). Figure 4.4 illustrates this case, where the
d in the circle stands for disjoint. The d notation also applies to user-defined subclasses of a
specialization that must be disjoint, as illustrated by the specialization {hourly_employee,
salaried_employee} in Figure 4.1. If the subclasses are not constrained to be disjoint, their sets
of entities may be overlapping; that is, the same (real-world) entity may be a member of more
than one subclass of the specialization. This case, which is the default, is displayed by placing
an o in the circle, as shown in Figure 4.5.

The second constraint on specialization is called the completeness (or totalness) constraint,
which may be total or partial. A total specialization constraint specifies that every entity in the
superclass must be a member of at least one subclass in the specialization. For example, if
every employee must be either an hourly_employee or a salaried_employee, then the
specialization {hourly_employee, salaried_employee} in figure 4.1 is a total specialization of
employee. This is shown in EER diagrams by using a double line to connect the superclass to
the circle. A single line is used to display a partial specialization, which allows an entity not to
belong to any of the subclasses. For example, if some employee entities do not belong to any
of the subclasses {secretary, engineer, technician} in Figures 4.1 and 4.4, then that
specialization is partial.

Notice that the disjointness and completeness constraints are independent. Hence, we have the
following four possible constraints on a specialization:

■ Disjoint, total

■ Disjoint, partial

■ Overlapping, total

■ Overlapping, partial

Of course, the correct constraint is determined from the real-world meaning that applies to each
specialization. In general, a superclass that was identified through the generalization process
usually is total, because the superclass is derived from the subclasses and hence contains only
the entities that are in the subclasses.

Certain insertion and deletion rules apply to specialization (and generalization) as a

consequence of the constraints specified earlier. Some of these rules are as follows:
■ 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
predicate-defined (or attribute-defined) subclasses for which the entity satisfies the defining
predicate.

■ 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.

The reader is encouraged to make a complete list of rules for insertions and deletions for the
various types of specializations.

4.3.2 Specialization and Generalization Hierarchies and Lattices

A subclass itself may have further subclasses specified on it, forming a hierarchy or a lattice of
specializations. For example, in Figure 4.6 engineer is a subclass of employee and is also a
superclass of engineering_manager; this represents the real-world constraint that every
engineering manager is required to be an engineer. 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 parent, which results in a tree structure or strict hierarchy. In
contrast, for a specialization lattice, a subclass can be a subclass in more than one
class/subclass relationship. Hence, Figure 4.6 is a lattice.

Figure 4.7 shows another specialization lattice of more than one level. This may be part of a
conceptual schema for a university database. Notice that this arrangement would have been a
hierarchy except for the student_assistant subclass, which is a subclass in two distinct
class/subclass relationships.

The requirements for the part of the UNIVERSITY database shown in Figure 4.7 are the
following:

1. The database keeps track of three types of persons: employees, alumni, and students. A
person can belong to one, two, or all three of these types. Each person has a name, SSN, sex,
address, and birth date.

2. Every employee has a salary, and there are three types of employees: faculty, staff, and
student assistants. Each employee belongs to exactly one of these types. For each alumnus, a
record of the degree or degrees that he or she earned at the university is kept, including the
name of the degree, the year granted, and the major department. Each student has a major
department.

3. Each faculty has a rank, whereas each staff member has a staff position. Student assistants
are classified further as either research assistants or teaching assistants, and the percent of time
that they work is recorded in the database. Research assistants have their research project
stored, whereas teaching assistants have the current course they work on.

4. Students are further classified as either graduate or undergraduate, with the specific
attributes degree program (M.S., Ph.D., M.B.A., and so on) for graduate students and class
(freshman, sophomore, and so on) for undergraduates.

In Figure 4.7, all person entities represented in the database are members of the person entity
type, which is specialized into the subclasses {employee, alumnus, student}. This
specialization is overlapping; for example, an alumnus may also be an employee and a student
pursuing an advanced degree. The subclass student is the superclass for the specialization
{graduate_student, undergraduate_student}, whereas employee is the superclass for the
specialization {student_assistant, faculty, staff}. Notice that student_assistant is also a subclass
of student. Finally, student_assistant is the superclass for the specialization into
{research_assistant, teaching_assistant}.

In such a specialization lattice or hierarchy, a subclass inherits the attributes not only of its
direct superclass, but also of all its predecessor superclasses all the way to the root of the
hierarchy or lattice if necessary. For example, an entity in graduate_student inherits all the
attributes of that entity as a student and as a person. Notice that an entity may exist in several
leaf nodes of the hierarchy, where a leaf node is a class that has no subclasses of its own. For
example, a member of graduate_student may also be a member of research_assistant.

A subclass with more than one superclass is called a shared subclass, such as
engineering_manager in Figure 4.6. This leads to the concept known as multiple inheritance,
where the shared subclass engineering_manager directly inherits attributes and relationships
from multiple superclasses. Notice that the existence of at least one shared subclass leads to a
lattice (and hence to multiple inheritance); if no shared subclasses existed, we would have a
hierarchy rather than a lattice and only single inheritance would exist. An important rule related
to multiple inheritance can be illustrated by the example of the shared subclass
student_assistant in Figure 4.7, which inherits attributes from both employee and student. Here,
both employee and student inherit the same attributes from person. The rule states that if an
attribute (or relationship) originating in the same superclass (person) is inherited more than
once via different paths (employee and student) in the lattice, then it should be included only
once in the shared subclass (student_assistant). Hence, the attributes of person are inherited
only once in the student_assistant subclass in Figure 4.7.

It is important to note here that some models and languages are limited to single inheritance
and do not allow multiple inheritance (shared subclasses). It is also important to note that some
models do not allow an entity to have multiple types, and hence an entity can be a member of
only one leaf class.8 In such a model, it is necessary to create additional subclasses as leaf
nodes to cover all possible combinations of classes that may have some entity that belongs to
all these classes simultaneously. For example, in the overlapping specialization of person into
{employee, alumnus, student} (or {E, A, S} for short), it would be necessary to create seven
subclasses of person in order to cover all possible types of entities: E, A, S, E_A, E_S, A_S,
and E_A_S. Obviously, this can lead to extra complexity.

Although we have used specialization to illustrate our discussion, similar concepts apply
equally to generalization, as we mentioned at the beginning of this section. Hence, we can also
speak of generalization hierarchies and generalization lattices.

4.3.3 Utilizing Specialization and Generalization in Refining Conceptual Schemas

Now we elaborate on the differences between the specialization and generalization processes
and how they are used to refine conceptual schemas during conceptual database design. In the
specialization process, the database designers typically start with an entity type and then define
subclasses of the entity type by successive specialization; that is, they repeatedly define more
specific groupings of the entity type. For example, when designing the specialization lattice in
figure 4.7, we may first specify an entity type person for a university database. Then we
discover that three types of persons will be represented in the database: university employees,
alumni, and students and we create the specialization {employee, alumnus, student}. The
overlapping constraint is chosen because a person may belong to more than one of the
subclasses. We specialize employee further into {staff, faculty, student_assistant}, and
specialize student into {graduate_student, undergraduate_student}. Finally, we specialize
student_assistant into {research_assistant, teaching_assistant}. This process is called top-down
conceptual refinement. So far, we have a hierarchy; then we realize that student_assistant is a
shared subclass, since it is also a subclass of student, leading to the lattice.
It is possible to arrive at the same hierarchy or lattice from the other direction. In such a case,
the process involves generalization rather than specialization and corresponds to a bottom-up
conceptual synthesis. For example, the database designers may first discover entity types such
as staff, faculty, alumnus, graduate_student, undergraduate_student, research_assistant,
teaching_assistant, and so on; then they generalize {graduate_student, undergraduate_student}
into student; then {research_assistant, teaching_assistant} into student_assistant; then {staff,
faculty, student_assistant} into employee; and finally {employee, alumnus, student} into
person.

The final design of hierarchies or lattices resulting from either process may be identical; the
only difference relates to the manner or order in which the schema superclasses and subclasses
were created during the design process. In practice, it is likely that a combination of the two
processes is employed. Notice that the notion of representing data and knowledge by using
superclass/subclass hierarchies and lattices is quite common in knowledge-based systems and
expert systems, which combine database technology with artificial intelligence techniques. For
example, frame-based knowledge representation schemes closely resemble class hierarchies.
Specialization is also common in software engineering design methodologies that are based on
the object-oriented paradigm.

4.4 MODELING OF UNION TYPES USING CATEGORIES

It is sometimes necessary to represent a collection of entities from different entity types. In this
case, a subclass will represent a collection of entities that is a subset of the union of entities
from distinct entity types; we call such a subclass a union type or a category.

For example, suppose that we have three entity types: person, bank, and company. In a
database for motor vehicle registration, an owner of a vehicle can be a person, a bank (holding
a lien on a vehicle), or a company. We need to create a class (collection of entities) that includes
entities of all three types to play the role of vehicle owner. A category (union type) owner that
is a subclass of the union of the three entity sets of company, bank, and person can be created
for this purpose. We display categories in an eer diagram as shown in figure 4.8. The
superclasses company, bank, and person are connected to the circle with the ∪ symbol, which
stands for the set union operation. An arc with the subset symbol connects the circle to the
(subclass) owner category. In figure 4.8 we have two categories: owner, which is a subclass
(subset) of the union of person, bank, and company; and registered_vehicle, which is a subclass
(subset) of the union of car and truck.
A category has two or more superclasses that may represent collections of entities from distinct
entity types, whereas other superclass/subclass relationships always have a single superclass.
To better understand the difference, we can compare a category, such as owner in figure 4.8,
with the engineering_manager shared subclass in figure 4.6. The latter is a subclass of each of
the three superclasses engineer, manager, and salaried_employee, so an entity that is a member
of engineering_manager must exist in all three collections. This represents the constraint that
an engineering manager must be an engineer, a manager, and a salaried_employee; that is, the
engineering_manager entity set is a subset of the intersection of the three entity sets. On the
other hand, a category is a subset of the union of its superclasses. Hence, an entity that is a
member of owner must exist in only one of the superclasses. This represents the constraint that
an owner may be a company, a bank, or a person in figure 4.8.
MODEL PENINGKATAN-HUBUNGAN (EER)

Konsep pemodelan ER yang dibahas dalam Bab 3 cukup untuk mewakili banyak skema basis
data untuk aplikasi basis data tradisional, yang mencakup banyak aplikasi pemrosesan data
dalam bisnis dan industri. Namun, sejak akhir 1970-an, perancang aplikasi database telah
mencoba merancang skema database yang lebih akurat yang mencerminkan properti data dan
kendala dengan lebih tepat. Ini sangat penting untuk aplikasi teknologi database yang lebih
baru, seperti database untuk desain dan manufaktur teknik (CAD / CAM) , 1 telekomunikasi,
sistem perangkat lunak yang kompleks, dan sistem informasi geografis (SIG), di antara banyak
aplikasi lainnya. Database jenis ini memiliki persyaratan yang lebih kompleks daripada
aplikasi yang lebih tradisional. Ini mengarah pada pengembangan konsep pemodelan data
semantik tambahan yang dimasukkan ke dalam model data konseptual seperti model
ER. Berbagai model data semantik telah diusulkan dalam literatur. Banyak dari konsep ini juga
dikembangkan secara independen di bidang terkait ilmu komputer, seperti bidang representasi
pengetahuan kecerdasan buatan dan area pemodelan objek dalam rekayasa perangkat lunak.

Dalam bab ini, kami menjelaskan fitur yang telah diusulkan untuk model data semantik dan
menunjukkan bagaimana model ER dapat ditingkatkan untuk memasukkan konsep-konsep ini,
yang mengarah ke model ER (EER) yang disempurnakan.2 Kita mulai di Bagian 4.1 dengan
memasukkan konsep-konsep hubungan kelas / subkelas dan ketik pewarisan ke dalam model
ER. Kemudian, di Bagian 4.2, kami menambahkan konsep spesialisasi dan
generalisasi. Bagian 4.3 membahas berbagai jenis kendala pada spesialisasi / generalisasi, dan
Bagian 4.4 menunjukkan bagaimana konstruksi UNION dapat dimodelkan dengan
memasukkan konsep kategori dalam model EER. Bagian 4.5 memberikan contoh skema
database UNIVERSITY dalam model EER dan merangkum konsep-konsep model EER
dengan memberikan definisi formal. Kita akan menggunakan istilah objek dan entitas secara
bergantian dalam bab ini, karena banyak dari konsep ini umumnya digunakan dalam model
yang berorientasi objek .

Kami menyajikan notasi diagram kelas UML untuk mewakili spesialisasi dan generalisasi di
Bagian 4.6, dan kami membandingkannya secara singkat dengan notasi dan konsep EER. Ini
berfungsi sebagai contoh notasi alternatif, dan merupakan kelanjutan dari Bagian 3.8, yang
menyajikan notasi diagram kelas UML dasar yang sesuai dengan model ER dasar. Dalam
Bagian 4.7, kami membahas abstraksi mendasar yang digunakan sebagai dasar dari banyak
model data semantik. Bagian 4.8 merangkum bab ini.

Untuk pengantar rinci untuk pemodelan konseptual, Bab 4 harus dianggap sebagai kelanjutan
dari Bab 3. Namun, jika hanya pengantar dasar untuk pemodelan ER yang diinginkan, bab ini
dapat dihilangkan. Atau, pembaca dapat memilih untuk melewati beberapa atau semua bagian
selanjutnya dari bab ini (Bagian 4.4 hingga 4.8).
4.1 SUBCLASS, SUPERCLASS, DAN Warisan

Model EER mencakup semua konsep pemodelan model ER yang disajikan pada Bab 3. Selain
itu, mencakup konsep subkelas dan superclass dan konsep terkait spesialisasi dan generalisasi
(lihat Bagian 4.2 dan 4.3). Konsep lain yang termasuk dalam model EER adalah bahwa dari
kategori atau tipe gabungan (lihat Bagian 4.4), yang digunakan untuk mewakili kumpulan
objek (entitas) yang merupakan gabungan objek dari berbagai tipe entitas. Terkait dengan
konsep-konsep ini adalah mekanisme penting atribut dan hubungan warisan. Sayangnya, tidak
ada terminologi standar untuk konsep-konsep ini, jadi kami menggunakan terminologi yang
paling umum. Terminologi alternatif diberikan dalam catatan kaki. Kami juga menjelaskan
teknik diagram untuk menampilkan konsep-konsep ini ketika mereka muncul dalam skema
EER. Kami menyebut diagram skema yang dihasilkan diagram ER atau EER yang
ditingkatkan.

Konsep model ER yang disempurnakan pertama yang kita ambil adalah subtipe atau
subkelas dari tipe entitas. Seperti yang kita bahas di Bab 3, nama jenis entitas digunakan untuk
mewakili kedua jenis entitas dan kumpulan entitas atau kumpulan entitas jenis itu yang ada
dalam database. Sebagai contoh, karyawan tipe entitas menggambarkan tipe (yaitu, atribut dan
hubungan) dari masing-masing entitas karyawan, dan juga merujuk ke set entitas karyawan
saat ini dalam database perusahaan. Dalam banyak kasus, tipe entitas memiliki banyak
subkelompok atau subtipe entitasnya yang bermakna dan perlu diwakili secara eksplisit karena
signifikansinya terhadap aplikasi basis data. Sebagai contoh, entitas yang merupakan anggota
dari karyawan tipe entitas dapat dibedakan lebih lanjut menjadi sekretaris, insinyur, manajer,
teknisi, salaried_employee, hourly_employee, dan sebagainya. Himpunan atau kumpulan
entitas dalam setiap pengelompokan yang terakhir adalah himpunan bagian dari entitas yang
dimiliki oleh kumpulan entitas karyawan, artinya setiap entitas yang merupakan anggota dari
salah satu sub pengelompokan ini juga merupakan karyawan. W e memanggil masing-masing
pengelompokan ini sebuah subkelas atau subtipe dari tipe entitas karyawan, dan tipe entitas
karyawan disebut superclass atau supertype untuk masing-masing subkelas ini.Gambar 4.1
menunjukkan bagaimana merepresentasikan konsep-konsep ini secara diagram dalam diagram
EER. (Notasi lingkaran pada Gambar 4.1 akan dijelaskan pada Bagian 4.2.)

Kami menyebut hubungan antara superclass dan salah satu dari subkelasnya sebagai
superclass / subclass atau supertype / subtype atau hanya hubungan kelas / subclass.3 Dalam
contoh kami sebelumnya, karyawan / sekretaris dan karyawan / teknisi adalah dua hubungan
kelas / subkelas. Perhatikan bahwa entitas anggota subclass mewakili entitas dunia nyata yang
sama dengan beberapa anggota superclass; misalnya, entitas sekretaris 'Joan Logano ' juga
merupakan karyawan 'Joan Logano .' Oleh karena itu, anggota subclass sama dengan entitas
dalam superclass, tetapi dalam peran spesifik yang berbeda.Ketika kita menerapkan hubungan
superclass / subclass dalam sistem basis data, kita dapat mewakili anggota subclass sebagai
objek basis data yang berbeda — katakanlah, catatan berbeda yang terkait melalui atribut kunci
ke entitas superclassnya. Dalam Bagian 9.2, kami membahas berbagai opsi untuk mewakili
hubungan superclass / subclass dalam database relasional.

Entitas tidak bisa ada dalam database hanya dengan menjadi anggota subkelas; itu juga harus
menjadi anggota superclass. Entitas semacam itu dapat dimasukkan secara opsional sebagai
anggota dari sejumlah subclass. Sebagai contoh, seorang karyawan bergaji yang juga seorang
insinyur termasuk dalam dua subkelas insinyur dan karyawan yang digaji dari jenis entitas
karyawan. Namun, tidak perlu bahwa setiap entitas dalam superclass adalah anggota dari
beberapa subclass.

Konsep penting yang terkait dengan subclass (subtipe) adalah bahwa jenis warisan . Ingatlah
bahwa tipe entitas didefinisikan oleh atribut yang dimilikinya dan tipe hubungan yang
diikutinya. Karena entitas dalam subkelas mewakili entitas dunia nyata yang sama dari
superclass, entitas harus memiliki nilai untuk atribut spesifiknya serta nilai atributnya sebagai
anggota superclass. Kami mengatakan bahwa entitas yang merupakan anggota subkelas
mewarisi semua atribut entitas sebagai anggota dari superclass. Entitas juga mewarisi semua
hubungan di mana superclass berpartisipasi. Perhatikan bahwa subclass, dengan atribut dan
hubungan spesifik (atau lokal) sendiri bersama dengan semua atribut dan hubungan yang
diwarisi dari superclass, dapat dianggap sebagai tipe entitas dalam haknya sendiri .

4.2 SPESIALISASI DAN GENERALISASI

4.2.1 Spesialisasi

Spesialisasi adalah proses pendefinisian sekumpulan subkelas dari tipe entitas; tipe entitas ini
disebut superclass dari spesialisasi. Himpunan subclass yang membentuk spesialisasi
didefinisikan berdasarkan beberapa karakteristik yang membedakan entitas dalam
superclass. Sebagai contoh, himpunan subclass{sekretaris, insinyur, teknisi } adalah
spesialisasi karyawan superclass yang membedakan antara entitas karyawan berdasarkan jenis
pekerjaan masing-masing karyawan. Kami mungkin memiliki beberapa spesialisasi dengan
jenis entitas yang sama berdasarkan karakteristik pembeda yang berbeda.Misalnya, spesialisasi
lain of jenis entitas karyawan dapat menghasilkan
himpunan subclass {salaried_employee, hourly_employee}; spesialisasi ini membedakan
antara karyawan berdasarkan metode pembayaran.

Gambar 4.1 menunjukkan bagaimana kami menghadirkan spesialisasi secara diagram dalam
diagram EER. Subkelas yang menentukan spesialisasi dilampirkan oleh garis ke lingkaran
yang mewakili spesialisasi, yang terhubung pada gilirannya ke superclass. Simbol subset pada
setiap baris yang menghubungkan subclass ke lingkaran menunjukkan arah hubungan
superclass / subclass.5 Atribut yang hanya berlaku untuk entitas subclass tertentu —
seperti TypingSpeed of secretary — melekat pada persegi panjang yang mewakili subclass
itu. Ini disebut atribut subclass spesifik (atau lokal). Demikian pula, subkelas dapat
berpartisipasi dalam tipe hubungan tertentu, seperti subkelas hourly_employee
yang berpartisipasi dalam milik_to hubungan pada Gambar 4.1. Kami akan menjelaskan
simbol d di lingkaran pada Gambar 4.1 dan notasi diagram EER tambahan segera.

Gambar 4.2 menunjukkan beberapa instance entitas yang termasuk subclass dari spesialisasi
{sekretaris, insinyur, teknisi}. Sekali lagi, perhatikan bahwa entitas yang dimiliki oleh subclass
mewakili entitas dunia nyata yang sama dengan entitas yang terhubung dengannya dalam
superclass EMPLOYEE, meskipun entitas yang sama ditampilkan dua kali; misalnya, e1
ditunjukkan pada karyawan dan sekretaris pada Gambar 4.2. Seperti yang ditunjukkan oleh
gambar, hubungan superclass / subclass seperti karyawan / sekretaris agak menyerupai
hubungan 1: 1 pada tingkat instance (lihat Gambar 3.12).Perbedaan utama adalah bahwa dalam
hubungan 1: 1 dua entitas yang berbeda saling terkait, sedangkan dalam hubungan superclass
/ subclass entitas dalam subclass adalah entitas dunia nyata yang sama dengan entitas dalam
superclass tetapi memainkan peran khusus — untuk misalnya, seorang karyawan yang
berspesialisasi dalam peran sekretaris, atau seorang karyawan yang berspesialisasi dalam peran
teknisi.

Ada dua alasan utama untuk menyertakan hubungan kelas dan subkelas dan spesialisasi. Yang
pertama adalah bahwa atribut tertentu dapat berlaku untuk beberapa tetapi tidak semua
entitas tipe entitas superclass. Subclass didefinisikan untuk mengelompokkan entitas yang
menerapkan atribut ini. Anggota subclass mungkin masih berbagi sebagian besar atribut
mereka dengan anggota superclass lainnya. Sebagai contoh, pada Gambar 4.1 sekretaris
subclass memiliki atribut spesifik Typing_speed , sedangkan subkelas insinyur memiliki
atribut spesifik Eng_type , tetapi sekretaris dan insinyur berbagi atribut warisan lainnya dari
jenis entitas karyawan.

Alasan kedua untuk menggunakan subclass adalah bahwa beberapa tipe hubungan dapat
berpartisipasi hanya oleh entitas yang merupakan anggota subclass. Misalnya, jika
hanya hourly_employees dapat menjadi milik serikat pekerja, kita dapat mewakili kenyataan
bahwa dengan menciptakanhourly_employee subclass dari karyawan dan berkaitan subclass
untuk entitas jenis trade_union melalui belongs_to jenis hubungan, seperti digambarkan pada
Gambar 4.1.

4.2.2 Generalisasi

Kita dapat memikirkan proses abstraksi terbalik di mana kita menekan perbedaan di antara
beberapa jenis entitas, mengidentifikasi fitur-fitur umum mereka, dan menggeneralisasikannya
menjadi sebuah superclass tunggal yang jenis entitas aslinya adalah subclass khusus. Sebagai
contoh, perhatikanjenis entitas mobil dan truk yang ditunjukkan pada Gambar 4.3 (a). Karena
mereka memiliki beberapa atribut umum, mereka dapat digeneralisasikan ke
dalam kendaraan jenis entitas , seperti yang ditunjukkan pada Gambar 4.3 (b). Baik mobil dan
truk sekarang menjadi subclass dari kendaraan superclass umum. Kami menggunakan istilah
generalisasi untuk merujuk pada proses mendefinisikan jenis entitas umum dari jenis entitas
yang diberikan.

Perhatikan bahwa proses generalisasi dapat dipandang sebagai kebalikan dari proses
spesialisasi secara fungsional; kita dapat melihat {mobil, truk} sebagai spesialisasi kendaraan
daripada memandang kendaraan sebagai geografi mobil dan truk. Sebuah notasi diagram untuk
membedakan antara generalisasi dan spesialisasi digunakan di beberapa metodologi
desain. Panah yang menunjuk ke superclass yang digeneralisasi mewakili proses generalisasi,
sedangkan panah yang menunjuk ke subclass khusus mewakili proses spesialisasi. Kami tidak
akan menggunakan notasi ini karena keputusan mengenai proses mana yang diikuti dalam
situasi tertentu seringkali subyektif.

Sejauh ini kami telah memperkenalkan konsep subclass dan hubungan superclass / subclass,
serta proses spesialisasi dan generalisasi. Secara umum, superclass atau subclass mewakili
kumpulan entitas dengan tipe yang sama dan karenanya juga menjelaskan tipe entitas; itu
sebabnya superclasses dan subclass semuanya ditampilkan dalam persegi panjang dalam
diagram EER, seperti jenis entitas.

4.3. KENDALA DAN KARAKTERISTIK SPESIALISASI DAN GENERALISASI

Pertama, kami membahas kendala yang berlaku untuk spesialisasi tunggal atau generalisasi
tunggal. Untuk singkatnya, diskusi kami hanya mengacu pada spesialisasi meskipun berlaku
untuk spesialisasi dan generalisasi. Kemudian, kami membahas perbedaan antara spesialisasi /
generalisasi kisi (multiple inheritance) dan hierarki (single inheritance), dan kami menguraikan
perbedaan antara proses spesialisasi dan generalisasi selama desain skema database konseptual.

4.3.1 Kendala pada Spesialisasi dan Generalisasi

Secara umum, kami mungkin memiliki beberapa spesialisasi yang didefinisikan pada tipe
entitas yang sama (atau superclass), seperti yang ditunjukkan pada Gambar 4.1. Dalam kasus
seperti itu, entitas dapat menjadi bagian dari subclass di masing-masing
spesialisasi. Spesialisasi juga dapat terdiri dari satu subkelas saja, seperti spesialisasi
{manager} pada Gambar 4.1; dalam kasus seperti itu, kami tidak menggunakan notasi
lingkaran.

Dalam beberapa spesialisasi kita dapat menentukan dengan tepat entitas yang akan menjadi
anggota dari setiap subclass dengan menempatkan suatu kondisi pada nilai beberapa atribut
dari superclass. Subclass tersebut disebut subclass yang ditentukan oleh predikat (atau yang
ditentukan oleh kondisi).Sebagai contoh, jika tipe entitas karyawan memiliki atribut Job_type ,
seperti yang ditunjukkan pada Gambar 4.4, kita dapat menentukan kondisi keanggotaan
dalam subkelas sekretaris berdasarkan kondisi ( Job_type = 'Sekretaris'), yang kami sebut
predikat pendefinisian subclass . Kondisi ini merupakan batasan yang menentukan bahwa
entitas-entitas dari tipe entitas karyawan yang memiliki nilai atribut untuk Job_type adalah
'Sekretaris' milik subclass. Kami menampilkan subclass yang ditentukan oleh predikat dengan
menulis kondisi predikat di sebelah garis yang menghubungkan subclass ke lingkaran
spesialisasi.

Jika semua subclass dalam spesialisasi memiliki kondisi keanggotaan mereka pada atribut yang
sama dari superclass, spesialisasi itu sendiri disebut spesialisasi yang ditentukan atribut, dan
atribut tersebut disebut atribut pendefinisian spesialisasi. Dalam hal ini, semua entitas dengan
nilai yang sama untuk atribut milik subclass yang sama. Kami menampilkan spesialisasi
atribut-didefinisikan dengan menempatkan nama atribut yang menentukan di sebelah busur
dari lingkaran ke superclass, seperti yang ditunjukkan pada Gambar 4.4.

Ketika kita tidak memiliki ketentuan untuk menentukan keanggotaan dalam subkelas, maka
subkelas tersebut disebut pengguna-ditentukan. Keanggotaan dalam subkelas tersebut
ditentukan oleh pengguna basis data ketika mereka menerapkan operasi untuk menambahkan
entitas ke dalam subkelas;karenanya, keanggotaan ditentukan secara individual untuk setiap
entitas oleh pengguna, bukan oleh kondisi apa pun yang dapat dievaluasi secara otomatis.

Dua kendala lain mungkin berlaku untuk spesialisasi. Yang pertama

adalah kendala disjointness , yang menentukan bahwa subclass spesialisasi harus set
disjoint. Ini berarti bahwa suatu entitas dapat menjadi anggota paling banyak dari salah satu
subclass spesialisasi. Sebuah spesialisasi yang atribut-didefinisikan
menyiratkan kendala disjointness (jika atribut digunakan untuk mendefinisikan predikat
keanggotaan single dihargai). Gambar 4.4 mengilustrasikan kasus ini, di mana huruf d dalam
lingkaran berarti disjoint. D notasi juga berlaku untuk subclass ditetapkan pengguna dari
spesialisasi yang harus menguraikan, seperti yang digambarkan oleh
spesialisasi {hourly_employee, salaried_employee} pada Gambar 4.1. Jika subclass tidak
dibatasi untuk dipisahkan, set entitasnya mungkin tumpang tindih; yaitu, entitas (dunia nyata)
yang sama dapat menjadi anggota lebih dari satu subkelas spesialisasi. Kasing ini, yang
merupakan bawaan, ditampilkan dengan menempatkan o dalam lingkaran, seperti yang
ditunjukkan pada Gambar 4.5.

Batasan kedua pada spesialisasi disebut batasan kelengkapan (atau totalitas ), yang mungkin
total atau parsial. Batasan spesialisasi total menentukan bahwa setiap entitas dalam superclass
harus menjadi anggota setidaknya satu subkelas dalam spesialisasi. Misalnya, jika setiap
karyawan harus berupajam _employee o ra salaried_employee, maka spesialisasi {hourly_em
ployee, salaried_employee} pada gambar 4.1 adalah spesialisasi total karyawan. Ini
ditunjukkan dalam diagram EER dengan menggunakan garis ganda untuk menghubungkan
superclass ke lingkaran. Satu baris digunakan untuk menampilkan spesialisasi parsial, yang
memungkinkan suatu entitas tidak menjadi bagian dari subkelas. Sebagai contoh, jika beberapa
entitas karyawan bukan milik subclass {sekretaris, insinyur, teknisi } dalam Gambar 4.1 dan
4.4, maka spesialisasi itu adalah bagian l.

Perhatikan bahwa kendala ketidakjelasan dan kelengkapan bersifat independen. Oleh karena
itu, kami memiliki empat batasan yang mungkin terjadi pada spesialisasi:

■ Terpisah , total

■ Terpisah, parsial

■ Tumpang tindih, total

■ Tumpang tindih , sebagian

Tentu saja, batasan yang benar ditentukan dari makna dunia nyata yang berlaku untuk masing-
masing spesialisasi. Secara umum, superclass yang diidentifikasi melalui proses generalisasi
biasanya total, karena superclass berasal dari subclass dan karenanya hanya berisi entitas yang
ada di dalam subclass.

Aturan penyisipan dan penghapusan tertentu berlaku untuk spesialisasi (dan generalisasi)
sebagai konsekuensi dari kendala yang ditentukan sebelumnya.Beberapa aturan ini adalah
sebagai berikut:

■ Menghapus entitas dari superclass menyiratkan bahwa entitas itu secara otomatis dihapus
dari semua subclass yang menjadi miliknya.

■ Memasukkan entitas dalam superclass menyiratkan bahwa entitas dimasukkan secara wajib
dalam semua subkelas yang ditentukan oleh predikat (atau yang ditentukan oleh atribut) di
mana entitas tersebut memenuhi predikat yang ditentukan.

■ Memasukkan entitas dalam superclass dari spesialisasi total menyiratkan bahwa entitas
wajib dimasukkan ke dalam setidaknya satu dari subclass spesialisasi.

Pembaca didorong untuk membuat daftar aturan lengkap untuk penyisipan dan penghapusan
untuk berbagai jenis spesialisasi.

4.3.2 Hierarki dan Kisi Spesialisasi dan Generalisasi

Subclass itu sendiri mungkin memiliki subclass lebih lanjut yang ditentukan di atasnya,
membentuk hierarki atau kisi spesialisasi. Sebagai contoh, pada Gambar 4.6 insinyur adalah
subkelas karyawan dan juga merupakan superclass of engineering_manager ; ini merupakan
kendala dunia nyata yang harus dimiliki oleh setiap manajer teknik untuk menjadi
insinyur. Hirarki spesialisasi memiliki batasan bahwa setiap subclass berpartisipasi sebagai
subclass hanya dalam satu hubungan kelas / subclass; yaitu, setiap subkelas hanya memiliki
satu induk, yang menghasilkan struktur pohon atau hierarki yang ketat.Sebaliknya,
untuk kisi spesialisasi , subkelas dapat menjadi subkelas di lebih dari satu hubungan kelas /
subkelas. Oleh karena itu, Gambar 4.6 adalah sebuah kisi.

Gambar 4.7 menunjukkan kisi spesialisasi lain lebih dari satu level. Ini mungkin bagian dari
skema konseptual untuk database universitas. Perhatikan bahwa pengaturan ini akan menjadi
hierarki kecuali untuk subclass student_assistant , yang merupakan subclass dalam dua
hubungan kelas / subclass yang berbeda.

Persyaratan untuk bagian dari database UNIVERSITY yang ditunjukkan pada Gambar 4.7
adalah sebagai berikut:

1. Basis data melacak tiga jenis orang: karyawan, alumni, dan mahasiswa. Seseorang dapat
memiliki satu, dua, atau ketiga tipe ini. Setiap orang memiliki nama, SSN, jenis kelamin,
alamat, dan tanggal lahir.

2. Setiap karyawan memiliki gaji, dan ada tiga jenis karyawan: staf pengajar, staf, dan asisten
mahasiswa. Setiap karyawan memiliki salah satu dari jenis-jenis ini. Untuk setiap alumnus,
catatan gelar atau gelar yang dia dapatkan di universitas disimpan, termasuk nama gelar, tahun
yang diberikan, dan departemen utama. Setiap siswa memiliki jurusan utama.

3. Setiap fakultas memiliki peringkat, sedangkan setiap anggota staf memiliki posisi
staf. Asisten siswa diklasifikasikan lebih lanjut sebagai asisten penelitian atau asisten pengajar,
dan persentase waktu mereka bekerja dicatat dalam database. Asisten penelitian menyimpan
proyek penelitiannya, sedangkan asisten pengajar memiliki program studi saat ini.

4. Siswa selanjutnya diklasifikasikan sebagai lulusan atau sarjana, dengan program gelar atribut
khusus (MS, Ph.D., MBA, dan sebagainya) untuk mahasiswa pascasarjana dan kelas
(mahasiswa baru, mahasiswa kedua, dan sebagainya) untuk mahasiswa sarjana.

Pada Gambar 4.7, semua entitas orang yang diwakili dalam database adalah anggota dari tipe
entitas orang , yang dikhususkan ke dalam subkelas{karyawan, alumnus, siswa }. Spesialisasi
ini tumpang tindih; misalnya, seorang alumni juga dapat menjadi karyawan dan siswa yang
mengejar gelar lanjutan. Siswa subclass adalah superclass untuk spesialisasi
{ graduate_student , undergraduate_student }, sedangkan karyawan adalah superclass untuk
spesialisasi { student_assistant , fakultas, staf}. Perhatikan bahwa siswa _assistant juga
merupakan subkelas siswa. Akhirnya, student_assistant adalah superclass untuk spesialisasi ke
{ research_assistan t , mengajar _assistant }.

Dalam kisi atau hierarki spesialisasi seperti itu, subkelas mewarisi atribut tidak hanya dari
superclass langsungnya, tetapi juga dari semua superclassespendahulunya sampai ke akar
hierarki atau kisi jika perlu. Sebagai contoh, sebuah entitas dalam _student lulusan mewarisi
semua atribut dari entitas yang sebagai mahasiswa dan sebagai pribadi. Perhatikan bahwa
entitas mungkin ada di beberapa node daun dari hierarki, di mana node daun adalah kelas yang
tidak memiliki subclass sendiri. Sebagai contoh, seorang anggota graduate_student juga dapat
menjadi anggota research_assistant .

Subclass dengan lebih dari satu superclass disebut subclass bersama,

seperti engineering_manager pada Gambar 4.6. Ini mengarah pada konsep yang dikenal
sebagai multiple inheritance, di mana subclass engineering_manager yang dibagikan secara
langsung mewarisi atribut dan hubungan dari beberapa superclasses . Perhatikan bahwa
keberadaan setidaknya satu subclass bersama mengarah ke kisi (dan karenanya ke banyak
pewarisan); jika tidak ada subclass bersama ada, kita akan memiliki hierarki daripada kisi dan
hanya warisan tunggal yang ada. Aturan penting yang terkait dengan multiple inheritance dapat
diilustrasikan dengan contoh dari student_assistant subclass bersama pada Gambar 4.7, yang
mewarisi atribut dari karyawan dan siswa.Di sini, baik karyawan dan siswa mewarisi atribut
yang sama dari orang. Aturan menyatakan bahwa jika atribut (atau hubungan) yang berasal
dari superclass yang sama (orang) diwarisi lebih dari sekali melalui jalur yang berbeda
(karyawan dan siswa) dalam kisi, maka itu harus dimasukkan hanya sekali dalam subkelas
bersama ( student_assistant ) . Oleh karena itu, atribut orang hanya diwarisi satu kali
dalam subclass student_assistant pada Gambar 4.7.

Penting untuk dicatat di sini bahwa beberapa model dan bahasa terbatas pada pewarisan tunggal
dan tidak memungkinkan pewarisan berganda (subclass bersama). Penting juga untuk dicatat
bahwa beberapa model tidak memungkinkan suatu entitas memiliki banyak tipe, dan karenanya
suatu entitas dapat menjadi anggota dari hanya satu kelas daun.8 Dalam model seperti itu, perlu
untuk membuat subkelas tambahan sebagai simpul daun untuk tutupi semuakemungkinan
kombinasi kelas yang mungkin memiliki beberapa entitas yang dimiliki oleh semua kelas ini
secara bersamaan. Misalnya, dalam spesialisasi orang yang tumpang tindih menjadi
{karyawan, alumnus, siswa} (atau {E, A, S} singkatnya), akan diperlukan untuk membuat
tujuh subkelas orang untuk mencakup semua jenis entitas yang mungkin: E, A, S, E_A, E_S,
A_S, dan E_A_S. Jelas, ini dapat menyebabkan kompleksitas tambahan.

Meskipun kami telah menggunakan spesialisasi untuk menggambarkan diskusi kami, konsep
yang sama berlaku untuk generalisasi, seperti yang kami sebutkan di awal bagian ini. Oleh
karena itu, kita juga dapat berbicara tentang hierarki generalisasi dan kisi generalisasi.

4.3.3 Memanfaatkan Spesialisasi dan Generalisasi dalam Menyempurnakan Skema

Konseptual

Sekarang kami menguraikan perbedaan antara proses spesialisasi dan generalisasi dan
bagaimana mereka digunakan untuk memperbaiki skema konseptual selama desain database
konseptual. Dalam proses spesialisasi, perancang basis data biasanya mulai dengan tipe entitas
dan kemudian menentukan subclass dari tipe entitas dengan spesialisasi berturut-turut; yaitu,
mereka berulang kali mendefinisikan pengelompokan yang lebih spesifikdari tipe
entitas. F atau contoh, ketika merancang kisi spesialisasi dalam gambar 4.7, kita mungkin
pertama menentukan orang entitas tipe untuk database universitas. Kemudian kami
menemukan bahwa tiga tipe orang akan terwakili dalam database: karyawan universitas,
alumni, dan mahasiswa dan kami menciptakan spesialisasi {karyawan,
alumnus, mahasiswa }. Batasan yang tumpang tindih dipilih karena seseorang
dapat memiliki lebih dari satu subkelas. Kami mengkhususkan karyawan lebih lanjut ke
{ staff, fakultas, student_assistant }, dan mengkhususkan siswa ke
{ graduate_student ,undergraduate_student }. Akhirnya, kami
menspesialisasikan student_assistant ke dalam
{ research_assistant , teaching_assistant }. Proses ini disebut penyempurnaan konseptual top-
down. Sejauh ini, kami memiliki hierarki; kemudian kami menyadari
bahwa student_assistant adalah subclass bersama, karena itu juga merupakan subclass dari
siswa, yang mengarah ke kisi.

Dimungkinkan untuk sampai pada hierarki atau kisi yang sama dari arah lain. Dalam kasus
seperti itu, proses melibatkan generalisasi daripada spesialisasi dan sesuai dengan sintesis
konseptual bottom-up. Sebagai contoh, perancang basis data pertama-tama dapat menemukan
jenis entitas seperti staf, staf pengajar,
alumni, lulusan_pelajar , sarjana_pelajar , peneliti_pelindung , pengajar_pelindung , dan
sebagainya; kemudian mereka menggeneralisasi {graduate_student , undergraduate_student }
menjadi mahasiswa; kemudian { research_assistant , teaching_assistant }
ke student_as sistant ; kemudian {staff, fakultas, student_assistant } menjadi karyawan; dan
akhirnya {karyawan, alumni, mahasiswa} menjadi pribadi.

Desain akhir hierarki atau kisi yang dihasilkan dari kedua proses tersebut mungkin
identik; satu-satunya perbedaan berkaitan dengan cara atau urutan di mana
skema superclasses dan subclass dibuat selama proses desain. Dalam praktiknya, ada
kemungkinan bahwa kombinasi dari kedua proses tersebut digunakan. Perhatikan
bahwa Gagasan untuk merepresentasikan data dan pengetahuan dengan menggunakan hierarki
dan kisi superclass / subclass cukup umum dalam sistem berbasis pengetahuan dan sistem
pakar, yang menggabungkan teknologi basis data dengan teknik kecerdasan buatan. Misalnya,
skema representasi pengetahuan berbasis bingkai sangat mirip dengan hierarki
kelas. Spesialisasi juga umum dalam metodologi desain rekayasa perangkat lunak yang
didasarkan pada paradigma berorientasi objek.

4.4 PEMODELAN JENIS-JENIS UNI MENGGUNAKAN KATEGORI

Kadang-kadang diperlukan untuk mewakili kumpulan entitas dari jenis entitas yang
berbeda. Dalam hal ini, subclass akan mewakili kumpulan entitas yang merupakan subset dari
gabungan entitas dari tipe entitas yang berbeda; kami menyebut subclass semacam itu sebagai
jenis serikat atau kategori .

Misalnya, anggaplah kita memiliki tiga jenis entitas: orang, bank, dan perusahaan . Dalam
database untuk pendaftaran kendaraan bermotor, pemilik kendaraan dapat berupa orang, bank
(memegang gadai pada kendaraan), atau perusahaan. Kita perlu membuat kelas (kumpulan
entitas) yang mencakup entitas dari ketiga jenis untuk memainkan peran pemilik
kendaraan. Pemilik kategori (tipe serikat) yang merupakan subkelas dari gabungan tiga set
entitas perusahaan, bank, dan orang dapat dibuat untuk tujuan ini. Kami menampilkan kategori
dalam diagram eer seperti yang ditunjukkan pada gambar
4.8.Superclasses perusahaan, perbankan, dan orang yang terhubung ke lingkaran
dengan ∪ simbol, yang merupakan singkatan dari operasi set serikat. Sebuah busur dengan
simbol subset menghubungkan lingkaran ke kategori pemilik (subclass). Pada Gambar 4.8
kami memiliki dua kategori: pemilik, yang merupakan subkelas (subset) dari persatuan orang,
bank, dan perusahaan; dan Registered_vehicle , yang merupakan subclass (subset) dari
penyatuan mobil dan truk.

Suatu kategori memiliki dua atau lebih superclass yang dapat mewakili koleksi entitas dari tipe
entitas yang berbeda, sedangkan hubungan superclass / subclass lainnya selalu memiliki
superclass tunggal. Untuk lebih memahami perbedaannya , kita dapat membandingkan
kategori, seperti pemilik pada gambar 4.8, dengan subclass yang
dibagikan engineering_manager pada gambar 4.6. Yang terakhir adalah subkelas dari masing-
masing dari tigasuperclasses engineer, manager, dan salar ied_employee , sehingga entitas
yang merupakan anggota dari engineering_manager harus ada di ketiga koleksi. Ini mewakili
kendala bahwa seorang manajer teknik harus seorang insinyur, manajer, dan
seorang karyawan yang digaji ; yaitu, rekayasa_manager himpunan entitas adalah bagian dari
persimpangan tiga set entitas. Di sisi lain, kategori adalah bagian dari gabungan
dari superclasses -nya .Oleh karena itu, entitas yang merupakan anggota pemilik harus ada
hanya di salah satu superclasses . Ini mewakili kendala bahwa pemilik dapat berupa
perusahaan, bank, atau orang dalam Gambar 4.8.
Gambar 4.8 Dua kategori (tipe gabungan): PEMILIK dan REGISTERED_VEHICLE.
Atribut turunan bekerja lebih selektif dalam hal kategori. Sebagai contoh, pada Gambar 4.8,
setiap entitas PEMILIK mewarisi atribut-atribut PERUSAHAAN, ORANG, atau BANK,
tergantung pada superclass tempat entitas tersebut berada. Di sisi lain, subclass bersama seperti
ENGINEERING_MANAGER (Gambar 4.6) mewarisi semua atribut dari superclasses
SALARIED_EMPLOYEE, ENGINEER, dan MANAGER.
Sangat menarik untuk mencatat perbedaan antara kategori REGISTERED_VEHICLE
(Gambar 4.8) dan VEHICLE superclass umum (Gambar 4.3 (b)). Pada Gambar 4.3 (b), setiap
mobil dan setiap truk adalah KENDARAAN; tetapi pada Gambar 4.8, kategori
REGISTERED_VEHICLE mencakup beberapa mobil dan beberapa truk tetapi belum tentu
semuanya (misalnya, beberapa mobil atau truk mungkin tidak terdaftar). Secara umum,
spesialisasi atau generalisasi seperti pada Gambar 4.3 (b), jika parsial, tidak akan menghalangi
KENDARAAN dari mengandung jenis entitas lain, seperti sepeda motor. Namun, kategori
seperti REGISTERED_VEHICLE pada Gambar 4.8 menyiratkan bahwa hanya mobil dan truk,
tetapi bukan jenis entitas lainnya, yang dapat menjadi anggota REGISTERED_VEHICLE.
Kategori dapat total atau sebagian. Kategori total memegang persatuan semua entitas dalam
superclasses, sedangkan kategori parsial dapat menampung subset dari persatuan. Kategori
total direpresentasikan secara diagram dengan garis ganda yang menghubungkan kategori dan
lingkaran, sedangkan kategori parsial ditunjukkan oleh satu garis.
Superclasses dari kategori mungkin memiliki atribut kunci yang berbeda, seperti yang
ditunjukkan oleh kategori PEMILIK pada Gambar 4.8, atau mereka mungkin memiliki atribut
kunci yang sama, seperti yang ditunjukkan oleh kategori REGISTERED_VEHICLE.
Perhatikan bahwa jika suatu kategori adalah total (bukan parsial), ia dapat direpresentasikan
sebagai alternatif total spesialisasi (atau total generalisasi). Dalam hal ini, pilihan representasi
yang digunakan adalah subyektif. Jika dua kelas mewakili tipe entitas yang sama dan berbagi
banyak atribut, termasuk atribut kunci yang sama, spesialisasi / generalisasi lebih disukai; jika
tidak, kategorisasi (jenis serikat) lebih tepat.
Penting untuk dicatat bahwa beberapa metodologi pemodelan tidak memiliki tipe gabungan.
Dalam model-model ini, jenis serikat pekerja harus diwakili secara tidak langsung (lihat Bagian
9.2).

4.5 Contoh Skema EER UNIVERSITAS, Pilihan Desain, dan Definisi

Formal
Pada bagian ini, pertama-tama kita memberikan contoh skema database dalam model EER
untuk menggambarkan penggunaan berbagai konsep yang dibahas di sini dan di Bab 3.
Kemudian, kita membahas pilihan desain untuk skema konseptual, dan akhirnya kita
merangkum konsep model EER dan mendefinisikannya secara formal dengan cara yang sama
di mana kami secara formal mendefinisikan konsep model ER dasar pada Bab 3.
4.5.1 Contoh Basis Data UNIVERSITAS yang Berbeda
Pertimbangkan database UNIVERSITY yang memiliki persyaratan berbeda dari database
UNIVERSITY yang disajikan dalam Bagian 3.10. Basis data ini melacak siswa dan jurusan,
transkrip, dan pendaftaran serta penawaran program universitas. Basis data juga melacak
proyek-proyek penelitian yang disponsori dari fakultas dan mahasiswa pascasarjana. Skema ini
ditunjukkan pada Gambar 4.9. Diskusi tentang persyaratan yang menyebabkan skema ini
berikut.
Untuk setiap orang, basis data menyimpan informasi tentang Nama [Nama] orang tersebut,
nomor Jaminan Sosial [Ssn], alamat [Alamat], jenis kelamin [Jenis Kelamin], dan tanggal lahir
[Tanggal]. Dua subclass dari tipe entitas PERSON diidentifikasi: FAKULTAS dan SISWA.
Atribut khusus FACULTY adalah peringkat [Peringkat] (asisten, rekan, tambahan, penelitian,
kunjungan, dan sebagainya), kantor [Kantor], telepon kantor [Telepon], dan gaji [Gaji]. Semua
anggota fakultas terkait dengan departemen akademik (s) yang mereka berafiliasi [BELONGS]
(anggota fakultas dapat dikaitkan dengan beberapa departemen, sehingga hubungannya adalah
M: N). Atribut khusus SISWA adalah [Kelas] (mahasiswa baru = 1, mahasiswa kedua = 2, ...,
siswa MS = 5, mahasiswa PhD = 6). Setiap SISWA juga terkait dengan departemen utama dan
kecilnya (jika diketahui) [UTAMA] dan [MINOR], dengan bagian kursus yang sedang ia hadiri
[TERDAFTAR], dan dengan kursus yang diselesaikan [TRANSCRIPT]. Setiap instance
TRANSCRIPT termasuk kelas yang diterima siswa [Kelas] di bagian kursus.
GRAD_STUDENT adalah subkelas dari STUDENT, dengan predikat yang menentukan (Kelas
= 5 ATAU Kelas = 6). Untuk setiap mahasiswa pascasarjana, kami menyimpan daftar gelar
sebelumnya dalam atribut [derajat] komposit multinilai. Kami juga menghubungkan
mahasiswa pascasarjana dengan penasihat fakultas [ADVISOR] dan ke komite tesis
[KOMITE], jika ada.
Departemen akademik memiliki nama atribut [Nama], telepon [Telepon], dan nomor kantor
[Kantor] dan terkait dengan anggota fakultas yang adalah ketua [KURSI] dan ke perguruan
tinggi tempat [CD] miliknya. Setiap perguruan tinggi memiliki atribut nama perguruan tinggi
[Cname], nomor kantor [Coffice], dan nama dekannya [Dekan].
Kursus memiliki atribut nomor kursus [C #], nama kursus [Cname], dan deskripsi kursus
[Cdesc]. Beberapa bagian dari setiap kursus ditawarkan, dengan masing-masing bagian
memiliki nomor bagian atribut [Bagian #] dan tahun dan kuartal di mana bagian itu ditawarkan
([Tahun] dan [Qtr]). Nomor bagian mengidentifikasi secara unik setiap bagian. Bagian yang
ditawarkan selama kuartal saat ini berada dalam subkelas CURRENT_SECTION dari
SECTION, dengan predikat yang menentukan Qtr = Current_qtr dan Tahun = Current_year.
Setiap bagian terkait dengan instruktur yang mengajar atau mengajarkannya ([MENGAJAR]),
jika instruktur itu ada di database.
Kategori INSTRUCTOR_RESEARCHER adalah bagian dari persatuan FACULTY dan
GRAD_STUDENT dan mencakup semua fakultas, serta mahasiswa pascasarjana yang
didukung oleh pengajaran atau penelitian. Akhirnya, tipe entitas GRANT melacak hibah
penelitian dan kontrak yang diberikan kepada universitas. Setiap hibah memiliki atribut judul
hibah [Judul], nomor hibah [Tidak], agensi pemberi [Agensi], dan tanggal mulai [St_date].
Hibah terkait dengan satu penyelidik utama [PI] dan untuk semua peneliti itu mendukung
[DUKUNGAN]. Setiap instance dukungan memiliki atribut tanggal mulai dukungan [Mulai],
tanggal berakhirnya dukungan (jika diketahui) [Akhir], dan persentase waktu yang dihabiskan
untuk proyek [Waktu] oleh peneliti yang didukung.
4.5.2 Pilihan Desain untuk Spesialisasi / Generalisasi
Tidak selalu mudah untuk memilih desain konseptual yang paling tepat untuk aplikasi database.
Dalam Bagian 3.7.3, kami menyajikan beberapa masalah khas yang dihadapi perancang basis
data ketika memilih di antara konsep tipe entitas, tipe hubungan, dan atribut untuk mewakili
situasi miniworld tertentu sebagai skema ER. Pada bagian ini, kami membahas pedoman desain
dan pilihan untuk konsep EER tentang spesialisasi / generalisasi dan kategori (tipe serikat
pekerja).
Seperti yang kami sebutkan di Bagian 3.7.3, desain basis data konseptual harus dianggap
sebagai proses perbaikan berulang sampai desain yang paling cocok tercapai. Panduan berikut
dapat membantu memandu proses desain untuk konsep EER:
■ Secara umum, banyak spesialisasi dan subclass dapat didefinisikan untuk membuat model
konseptual akurat. Namun, kekurangannya adalah desainnya menjadi sangat berantakan.
Penting untuk hanya mewakili subkelas yang dianggap perlu untuk menghindari kekacauan
ekstrem skema konseptual.
■ Jika subkelas memiliki beberapa atribut spesifik (lokal) dan tidak ada hubungan khusus, ia
dapat digabungkan ke dalam superclass. Atribut spesifik akan menyimpan nilai NULL untuk
entitas yang bukan anggota subkelas. Atribut type dapat menentukan apakah suatu entitas
adalah anggota dari subclass.
■ Demikian pula, jika semua subclass dari spesialisasi / generalisasi memiliki beberapa atribut
spesifik dan tidak ada hubungan spesifik, mereka dapat digabungkan ke dalam superclass dan
diganti dengan satu atau lebih tipe atribut yang menentukan subclass atau subclass yang
dimiliki masing-masing entitas (lihat Bagian 9.2 untuk bagaimana kriteria ini berlaku untuk
basis data relasional).
■ Jenis dan kategori serikat pekerja pada umumnya harus dihindari kecuali situasinya secara
pasti menjamin jenis konstruksi ini, yang memang terjadi dalam beberapa situasi praktis. Jika
memungkinkan, kami mencoba memodelkan menggunakan spesialisasi / generalisasi seperti
yang dibahas pada akhir Bagian 4.4.
■ Pilihan batasan disjoint / overlapping dan total / parsial pada spesialisasi / generalisasi
didorong oleh aturan dalam miniworld yang dimodelkan. Jika persyaratan tidak menunjukkan
kendala tertentu, standarnya umumnya akan tumpang tindih dan parsial, karena ini tidak
menentukan pembatasan keanggotaan subclass.
Sebagai contoh penerapan pedoman ini, pertimbangkan Gambar 4.6, di mana tidak ada atribut
spesifik (lokal) yang ditampilkan. Kami dapat menggabungkan semua subclass ke dalam tipe
entitas EMPLOYEE dan menambahkan atribut berikut ke EMPLOYEE:
■ Atribut Job_type yang nilainya ditetapkan {‘Sekretaris’, ‘Insinyur’, ‘Teknisi’} akan
menunjukkan subclass mana dalam spesialisasi pertama yang dimiliki oleh setiap karyawan.
■ Atribut Pay_method yang nilainya ditetapkan {‘Digaji’, ‘Setiap Jam’) akan menunjukkan
subkelas mana dalam spesialisasi kedua yang dimiliki masing-masing karyawan.
■ Atribut Is_a_manager yang nilainya ditetapkan {‘Ya’, ‘Tidak’) akan menunjukkan apakah
entitas karyawan individu adalah manajer atau tidak.
4.5.3 Definisi Resmi untuk Konsep Model EER
Kami sekarang merangkum konsep model EER dan memberikan definisi formal. Kelas
mendefinisikan jenis entitas dan mewakili satu set atau koleksi entitas jenis itu; ini termasuk
salah satu konstruksi skema EER yang sesuai dengan koleksi entitas, seperti jenis entitas,
subkelas, superclasses, dan kategori. Subclass S adalah kelas yang entitasnya harus selalu
menjadi subset dari entitas di kelas lain, yang disebut superclass C dari hubungan superclass /
subclass (atau IS-A). Kami menyatakan hubungan seperti itu dengan C / S. Untuk hubungan
superclass / subclass seperti itu, kita harus selalu memilikinya
S⊆C
Spesialisasi Z = {S1, S2, … , Sn} adalah seperangkat subclass yang memiliki superclass G yang
sama; yaitu, G / Si adalah hubungan superclass / subclass untuk i = 1, 2, … , n. G disebut tipe
entitas umum (atau superclass dari spesialisasi, atau generalisasi dari subclass { S1, S2, … ,
Sn }). Z dikatakan total jika kita selalu (kapan saja) memilikinya
n

⋃ Si=G
i =1

Kalau tidak, Z dikatakan parsial. Z dikatakan terpisah jika kita selalu punya
Si ∩ Sj = ∅ (empty set) 𝑢𝑛𝑡𝑢𝑘 i ≠ j

Kalau tidak, Z dikatakan tumpang tindih.

Subclass S of C dikatakan predikat-ditentukan jika p predikat pada atribut C digunakan untuk
menentukan entitas mana di C yang merupakan anggota S; yaitu, S = C [p], di mana C [p]
adalah himpunan entitas dalam C yang memenuhi p. Subclass yang tidak didefinisikan oleh
predikat disebut user-defined.
Spesialisasi Z (atau generalisasi G) dikatakan atribut-didefinisikan jika predikat (A = cT =
(D1[p1] ∪ D2[p2] ... ∪ Dn[pn])
), di mana A adalah atribut G dan ci adalah nilai konstan dari domain A, digunakan untuk
menentukan keanggotaan di setiap subkelas Si dalam Z. Perhatikan bahwa jika Ci ≠ Cj untuk i
≠ j, dan A adalah atribut bernilai tunggal, maka spesialisasi akan terpisah.
Kategori T adalah kelas yang merupakan bagian dari gabungan dari n mendefinisikan kacamata
super D1, D2, ..., Dn, n> 1 dan secara resmi ditentukan sebagai berikut:
T ⊆ (D1 ∪ D2 ... ∪ Dn)
Pi predikat pada atribut Di dapat digunakan untuk menentukan anggota masing-masing Di yang
merupakan anggota T. Jika predikat ditentukan pada setiap Di, kita dapatkan
T = (D1[p1] ∪ D2[p2] ... ∪ Dn[pn])
Kita sekarang harus memperluas definisi tipe hubungan yang diberikan dalam Bab 3 dengan
mengizinkan kelas apa pun — tidak hanya tipe entitas apa pun — untuk berpartisipasi dalam
suatu hubungan. Oleh karena itu, kita harus mengganti jenis kata entitas dengan kelas dalam
definisi itu. Notasi grafis EER konsisten dengan ER karena semua kelas diwakili oleh persegi
panjang.

4.6 Contoh Notasi Lain: Mewakili Spesialisasi dan Generalisasi dalam

Diagram Kelas UML
Kami sekarang membahas notasi UML untuk generalisasi / spesialisasi dan pewarisan. Kami
sudah menyajikan notasi diagram diagram kelas UML dan terminologi di Bagian 3.8. Gambar
4.10 mengilustrasikan diagram kelas UML yang mungkin sesuai dengan diagram EER pada
Gambar 4.7. Notasi dasar untuk spesialisasi / generalisasi (lihat Gambar 4.10) adalah untuk
menghubungkan subkelas dengan garis vertikal ke garis horizontal, yang memiliki segitiga
yang menghubungkan garis horizontal melalui garis vertikal lain ke superclass. Segitiga
kosong menunjukkan spesialisasi / generalisasi dengan kendala disjoint, dan segitiga diisi
menunjukkan kendala yang tumpang tindih. Superclass root disebut kelas dasar, dan subclass
(daun node) disebut kelas daun.
Diskusi sebelumnya dan contoh pada Gambar 4.10, serta presentasi di Bagian 3.8, memberikan
gambaran singkat tentang diagram dan terminologi kelas UML. Kami fokus pada konsep-
konsep yang relevan dengan pemodelan basis data ER dan EER daripada konsep-konsep yang
lebih relevan untuk rekayasa perangkat lunak. Dalam UML, ada banyak detail yang belum
kami diskusikan karena mereka berada di luar cakupan teks ini dan terutama relevan dengan
rekayasa perangkat lunak. Sebagai contoh, kelas dapat terdiri dari berbagai jenis:
■ Kelas abstrak mendefinisikan atribut dan operasi tetapi tidak memiliki objek yang sesuai
dengan kelas tersebut. Ini terutama digunakan untuk menentukan satu set atribut dan operasi
yang dapat diwarisi.
■ Kelas beton dapat memiliki objek (entitas) instantiated untuk menjadi milik kelas.
■ Kelas templat menentukan templat yang dapat digunakan lebih lanjut untuk mendefinisikan
kelas lain.
Dalam desain database, kami terutama berkaitan dengan menentukan kelas beton yang koleksi
objeknya secara permanen (atau terus-menerus) disimpan dalam database. Catatan bibliografi
pada akhir bab ini memberikan beberapa referensi ke buku-buku yang menggambarkan detail
lengkap UML.

4.7 Abstraksi Data, Representasi Pengetahuan, dan Konsep Ontologi

Pada bagian ini, kami membahas secara umum beberapa konsep pemodelan yang kami jelaskan
secara khusus dalam presentasi kami tentang model ER dan EER dalam Bab 3 dan sebelumnya
dalam bab ini. Terminologi ini tidak hanya digunakan dalam pemodelan data konseptual tetapi
juga dalam literatur kecerdasan buatan ketika membahas representasi pengetahuan (KR).
Bagian ini membahas persamaan dan perbedaan antara pemodelan konseptual dan representasi
pengetahuan, dan memperkenalkan beberapa terminologi alternatif dan beberapa konsep
tambahan.
Tujuan dari teknik KR adalah untuk mengembangkan konsep untuk memodelkan secara akurat
beberapa domain pengetahuan dengan menciptakan ontologi yang menggambarkan konsep-
konsep domain dan bagaimana konsep-konsep ini saling terkait. Ontologi digunakan untuk
menyimpan dan memanipulasi pengetahuan untuk menggambar kesimpulan, membuat
keputusan, atau menjawab pertanyaan. Tujuan KR serupa dengan model data semantik, tetapi
ada beberapa persamaan dan perbedaan penting antara kedua disiplin:
■ Kedua disiplin ilmu menggunakan proses abstraksi untuk mengidentifikasi sifat-sifat umum
dan aspek-aspek penting dari objek dalam dunia mini (juga dikenal sebagai domain wacana
dalam KR) sambil menekan perbedaan yang tidak signifikan dan perincian yang tidak penting.
■ Kedua disiplin menyediakan konsep, hubungan, kendala, operasi, dan bahasa untuk
mendefinisikan data dan mewakili pengetahuan.
■ KR umumnya memiliki cakupan yang lebih luas daripada model data semantik. Berbagai
bentuk pengetahuan, seperti aturan (digunakan dalam inferensi, deduksi, dan pencarian),
pengetahuan tidak lengkap dan standar, dan pengetahuan temporal dan spasial, diwakili dalam
skema KR. Model database sedang dikembangkan untuk memasukkan beberapa konsep ini
(lihat Bab 26).
■ Skema KR mencakup mekanisme penalaran yang menyimpulkan fakta tambahan dari fakta
yang disimpan dalam database. Oleh karena itu, sedangkan sebagian besar sistem database saat
ini terbatas untuk menjawab pertanyaan langsung, sistem berbasis pengetahuan menggunakan
skema KR dapat menjawab pertanyaan yang melibatkan kesimpulan atas data yang disimpan.
Teknologi basis data sedang diperluas dengan mekanisme inferensi (lihat Bagian 26.5).
■ Meskipun sebagian besar model data berkonsentrasi pada representasi skema basis data, atau
meta-pengetahuan, skema KR sering menggabungkan skema dengan instance itu sendiri untuk
memberikan fleksibilitas dalam mewakili pengecualian. Hal ini sering mengakibatkan
inefisiensi ketika skema KR ini diterapkan, terutama bila dibandingkan dengan database dan
ketika sejumlah besar data terstruktur (fakta) perlu disimpan.
Kita sekarang membahas empat konsep abstraksi yang digunakan dalam model data semantik,
seperti model EER, serta dalam skema KR: (1) klasifikasi dan contoh, (2) identifikasi, (3)
spesialisasi dan generalisasi, dan (4) agregasi dan asosiasi. Konsep pasangan klasifikasi dan
instantiasi adalah kebalikan dari satu sama lain, seperti generalisasi dan spesialisasi. Konsep
agregasi dan asosiasi juga terkait. Kami membahas konsep-konsep abstrak ini dan
hubungannya dengan representasi konkret yang digunakan dalam model EER untuk
memperjelas proses abstraksi data dan untuk meningkatkan pemahaman kami tentang proses
terkait desain skema konseptual. Kami menutup bagian dengan diskusi singkat tentang
ontologi, yang sedang digunakan secara luas dalam penelitian representasi pengetahuan baru-
baru ini.
4.7.1 Klasifikasi dan Instansiasi
Proses klasifikasi melibatkan secara sistematis menetapkan objek / entitas yang serupa ke kelas
objek / tipe entitas. Kita sekarang dapat menggambarkan (dalam DB) atau alasan tentang
(dalam KR) kelas daripada objek individu. Koleksi objek yang memiliki tipe atribut, hubungan,
dan batasan yang sama diklasifikasikan ke dalam kelas untuk menyederhanakan proses
menemukan propertinya. Instansiasi adalah kebalikan dari klasifikasi dan mengacu pada
generasi dan pemeriksaan khusus objek yang berbeda dari suatu kelas. Sebuah instance objek
terkait dengan kelas objeknya oleh hubungan IS-AN-INSTANCE-OF atau IS-A-MEMBER-
OF. Meskipun diagram EER tidak menampilkan instance, diagram UML memungkinkan
bentuk instantiasi dengan mengizinkan tampilan objek individual. Kami tidak menjelaskan
fitur ini dalam pengantar kami untuk diagram kelas UML.
Secara umum, objek kelas harus memiliki struktur tipe yang serupa. Namun, beberapa objek
dapat menampilkan properti yang berbeda dalam beberapa hal dari objek lain di kelas; objek
pengecualian ini juga perlu dimodelkan, dan skema KR memungkinkan pengecualian yang
lebih bervariasi daripada model database. Selain itu, properti tertentu berlaku untuk kelas
secara keseluruhan dan bukan untuk objek individu; Skema KR memungkinkan properti kelas
tersebut. Diagram UML juga memungkinkan spesifikasi properti kelas.
Dalam model EER, entitas diklasifikasikan ke dalam tipe entitas sesuai dengan atribut dan
hubungan dasarnya. Entitas selanjutnya diklasifikasikan ke dalam subclass dan kategori
berdasarkan persamaan dan perbedaan tambahan (pengecualian) di antara mereka. Contoh
hubungan diklasifikasikan ke dalam jenis hubungan. Oleh karena itu, tipe entitas, subclass,
kategori, dan tipe hubungan adalah konsep berbeda yang digunakan untuk klasifikasi dalam
model EER. Model EER tidak menyediakan secara eksplisit untuk properti kelas, tetapi
mungkin diperluas untuk melakukannya. Dalam UML, objek diklasifikasikan ke dalam kelas,
dan dimungkinkan untuk menampilkan properti kelas dan objek individual.
Model representasi pengetahuan memungkinkan beberapa skema klasifikasi di mana satu kelas
adalah turunan dari kelas lain (disebut kelas meta). Perhatikan bahwa ini tidak dapat diwakili
secara langsung dalam model EER, karena kami hanya memiliki dua kelas dan instance tingkat.
Satu-satunya hubungan antara kelas dalam model EER adalah hubungan superclass / subclass,
sedangkan dalam beberapa skema KR hubungan kelas / instance tambahan dapat diwakili
secara langsung dalam hierarki kelas. Sebuah instance sendiri dapat berupa kelas lain, yang
memungkinkan skema klasifikasi multi-level.
4.7.2 Identifikasi
Identifikasi adalah proses abstraksi di mana kelas dan objek dibuat diidentifikasi secara unik
melalui beberapa pengidentifikasi. Misalnya, nama kelas secara unik mengidentifikasi seluruh
kelas dalam suatu skema. Mekanisme tambahan diperlukan untuk membedakan instance objek
yang berbeda dengan menggunakan pengidentifikasi objek. Selain itu, perlu untuk
mengidentifikasi banyak manifestasi dalam database dari objek dunia nyata yang sama.
Misalnya, kita mungkin memiliki tuple <'Matthew Clarke', '610618', '376-9821'> dalam relasi
PERSON dan tuple lain <'301-54-0836', 'CS', 3,8> dalam relasi SISWA yang kebetulan
mewakili entitas dunia nyata yang sama. Tidak ada cara untuk mengidentifikasi fakta bahwa
dua objek basis data ini (tuple) mewakili entitas dunia nyata yang sama kecuali jika kita
membuat ketentuan pada waktu desain untuk referensi silang yang sesuai untuk memasok
identifikasi ini. Karenanya, identifikasi diperlukan pada dua tingkat:
■ Untuk membedakan antara objek dan kelas basis data
■ Untuk mengidentifikasi objek basis data dan menghubungkannya dengan mitra dunia nyata
mereka
Dalam model EER, identifikasi konstruksi skema didasarkan pada sistem nama unik untuk
konstruksi dalam skema. Misalnya, setiap kelas dalam skema EER — apakah itu tipe entitas,
subkelas, kategori, atau tipe hubungan — harus memiliki nama yang berbeda. Nama-nama
atribut dari kelas tertentu juga harus berbeda. Diperlukan juga aturan untuk mengidentifikasi
referensi nama atribut dalam kisi atau hierarki spesialisasi atau generalisasi.
Pada tingkat objek, nilai-nilai atribut kunci digunakan untuk membedakan antara entitas dari
tipe entitas tertentu. Untuk tipe entitas yang lemah, entitas diidentifikasi dengan kombinasi
nilai kunci parsial mereka sendiri dan entitas yang terkait dengan jenis entitas pemilik. Contoh
hubungan diidentifikasi oleh beberapa kombinasi entitas yang terkait, tergantung pada rasio
kardinalitas yang ditentukan.
4.7.3 Spesialisasi dan Generalisasi
Spesialisasi adalah proses mengklasifikasikan kelas objek ke dalam subclass yang lebih
khusus. Generalisasi adalah proses kebalikan dari menggeneralisasi beberapa kelas menjadi
kelas abstrak tingkat yang lebih tinggi yang mencakup objek di semua kelas ini. Spesialisasi
adalah penyempurnaan konseptual, sedangkan generalisasi adalah sintesis konseptual.
Subclass digunakan dalam model EER untuk mewakili spesialisasi dan generalisasi. Kami
menyebut hubungan antara subclass dan superclass-nya sebagai hubungan IS-A SUBCLASS-
OF, atau hanya hubungan IS-A. Ini sama dengan hubungan IS-A yang dibahas sebelumnya
pada Bagian 4.5.3.
4.7.4 Agregasi dan Asosiasi
Agregasi adalah konsep abstraksi untuk membangun objek komposit dari objek komponennya.
Ada tiga kasus di mana konsep ini dapat dikaitkan dengan model EER. Kasus pertama adalah
situasi di mana kita menggabungkan nilai atribut suatu objek untuk membentuk keseluruhan
objek. Kasus kedua adalah ketika kita merepresentasikan hubungan agregasi sebagai hubungan
biasa. Kasus ketiga, yang tidak disediakan oleh model EER secara eksplisit, melibatkan
kemungkinan menggabungkan objek yang terkait dengan instance hubungan tertentu menjadi
objek agregat level yang lebih tinggi. Ini terkadang berguna ketika objek agregat level lebih
tinggi itu sendiri terkait dengan objek lain. Kami menyebut hubungan antara objek primitif dan
objek agregatnya IS-A-PART-OF; kebalikannya disebut IS-A-COMPONENT-OF. UML
menyediakan untuk ketiga jenis agregasi.
Abstraksi asosiasi digunakan untuk mengasosiasikan objek dari beberapa kelas independen.
Karenanya, ini agak mirip dengan penggunaan agregasi yang kedua. Itu diwakili dalam model
EER oleh tipe hubungan, dan di UML oleh asosiasi. Hubungan abstrak ini disebut IS-
ASSOCIATED-WITH.
Untuk memahami perbedaan penggunaan agregasi dengan lebih baik, pertimbangkan skema
ER yang ditunjukkan pada Gambar 4.11 (a), yang menyimpan informasi tentang wawancara
oleh pelamar pekerjaan ke berbagai perusahaan. Kelas PERUSAHAAN adalah agregasi atribut
(atau objek komponen) Cname (nama perusahaan) dan Caddress (alamat perusahaan),
sedangkan JOB_APPLICANT adalah agregat Ssn, Nama, Alamat, dan Telepon. Atribut
hubungan Contact_name dan Contact_phone mewakili nama dan nomor telepon orang di
perusahaan yang bertanggung jawab untuk wawancara. Misalkan beberapa wawancara
menghasilkan tawaran pekerjaan, sedangkan yang lain tidak. Kami ingin memperlakukan
WAWANCARA sebagai kelas untuk mengaitkannya dengan JOB_OFFER. Skema yang
ditunjukkan pada Gambar 4.11 (b) tidak benar karena mengharuskan setiap contoh hubungan
wawancara untuk memiliki tawaran pekerjaan. Skema yang ditunjukkan pada Gambar 4.11 (c)
tidak diperbolehkan karena model ER tidak memungkinkan hubungan antar hubungan.
Salah satu cara untuk mewakili situasi ini adalah dengan membuat kelas agregat tingkat lebih
tinggi yang terdiri dari PERUSAHAAN, JOB_APPLICANT, dan WAWANCARA dan
menghubungkan kelas ini ke JOB_OFFER, seperti yang ditunjukkan pada Gambar 4.11 (d).
Meskipun model EER seperti yang dijelaskan dalam buku ini tidak memiliki fasilitas ini,
beberapa model data semantik memungkinkan dan menyebut objek yang dihasilkan sebagai
objek komposit atau molekul. Model lain memperlakukan tipe entitas dan tipe hubungan secara
seragam dan karenanya memungkinkan hubungan antar hubungan, seperti yang diilustrasikan
pada Gambar 4.11 (c).
Untuk merepresentasikan situasi ini dengan benar dalam model ER seperti yang dijelaskan di
sini, kita perlu membuat tipe entitas lemah yang baru WAWANCARA, seperti yang
ditunjukkan pada Gambar 4.11 (e), dan menghubungkannya dengan JOB_OFFER. Oleh karena
itu, kita selalu dapat mewakili situasi ini dengan benar dalam model ER dengan menciptakan
jenis entitas tambahan, meskipun mungkin secara konseptual lebih diinginkan untuk
memungkinkan representasi langsung agregasi, seperti pada Gambar 4.11 (d), atau untuk
memungkinkan hubungan di antara hubungan, seperti pada Gambar 4.11 (c).
Perbedaan struktural utama antara agregasi dan asosiasi adalah bahwa ketika instance asosiasi
dihapus, objek yang berpartisipasi dapat terus ada. Namun, jika kami mendukung gagasan
tentang objek agregat — misalnya, CAR yang terdiri dari objek ENGINE, CHASSIS, dan BAN
— maka menghapus jumlah objek CAR agregat untuk menghapus semua objek komponennya.
4.7.5 Ontologi dan Web Semantik
Dalam beberapa tahun terakhir, jumlah data dan informasi yang terkomputerisasi yang tersedia
di Web telah lepas kendali. Banyak model dan format yang berbeda digunakan. Selain model
database yang kami sajikan dalam teks ini, banyak informasi disimpan dalam bentuk dokumen,
yang memiliki struktur jauh lebih sedikit daripada informasi database. Salah satu proyek yang
sedang berlangsung yang berusaha untuk memungkinkan pertukaran informasi antara
komputer di Web disebut Web Semantik, yang berupaya untuk membuat model representasi
pengetahuan yang cukup umum untuk memungkinkan pertukaran informasi yang bermakna
dan mencari di antara mesin. Konsep ontologi dianggap sebagai dasar paling menjanjikan
untuk mencapai tujuan Web Semantik dan terkait erat dengan representasi pengetahuan. Di
bagian ini, kami memberikan pengantar singkat tentang apa itu ontologi dan bagaimana ia
dapat digunakan sebagai dasar untuk mengotomatiskan pemahaman, pencarian, dan pertukaran
informasi.
Studi tentang ontologi berusaha untuk menggambarkan konsep dan hubungan yang mungkin
dalam kenyataan melalui beberapa kosa kata umum; oleh karena itu, dapat dianggap sebagai
cara untuk menggambarkan pengetahuan komunitas tertentu tentang realitas. Ontologi berasal
dari bidang filsafat dan metafisika. Salah satu definisi ontologi yang umum digunakan adalah
spesifikasi konseptualisasi.
Dalam definisi ini, konseptualisasi adalah serangkaian konsep dan hubungan yang digunakan
untuk mewakili bagian dari realitas atau pengetahuan yang menarik bagi komunitas pengguna.
Spesifikasi mengacu pada istilah bahasa dan kosakata yang digunakan untuk menentukan
konseptualisasi. Ontologi mencakup spesifikasi dan konseptualisasi. Sebagai contoh,
konseptualisasi yang sama dapat ditentukan dalam dua bahasa yang berbeda, memberikan dua
ontologi yang terpisah. Berdasarkan definisi umum ini, tidak ada konsensus tentang apa
sebenarnya ontologi itu. Beberapa cara yang mungkin untuk menggambarkan ontologi adalah
sebagai berikut:
■ Tesaurus (atau bahkan kamus atau daftar istilah) menjelaskan hubungan antara kata-kata
(kosakata) yang mewakili berbagai konsep.
■ Taksonomi menggambarkan bagaimana konsep bidang pengetahuan tertentu dihubungkan
dengan menggunakan struktur yang mirip dengan yang digunakan dalam spesialisasi atau
generalisasi.
■ Skema basis data terperinci dianggap oleh beberapa pihak sebagai ontologi yang
menggambarkan konsep (entitas dan atribut) dan hubungan dunia mini dari kenyataan.
■ Teori logis menggunakan konsep dari logika matematika untuk mencoba mendefinisikan
konsep dan keterkaitannya.
Biasanya konsep yang digunakan untuk menggambarkan ontologi mirip dengan konsep yang
kita bahas dalam pemodelan konseptual, seperti entitas, atribut, hubungan, spesialisasi, dan
sebagainya. Perbedaan utama antara ontologi dan, katakanlah, skema database, adalah bahwa
skema tersebut biasanya terbatas pada menggambarkan subset kecil dari dunia mini dari
kenyataan untuk menyimpan dan mengelola data. Ontologi biasanya dianggap lebih umum
karena mencoba menggambarkan bagian dari realitas atau domain yang diminati (misalnya,
istilah medis, aplikasi perdagangan elektronik, olahraga, dan sebagainya) selengkap mungkin.