Database Modeling & Design Fourth Edition- P8 doc

Figure 2.3 continued f Recursive binary relationship ER model constructs using the Chen notation ER model constructs using IDEF1X [Bruc92] Department Department Division Employee is- ma

Figure 2.3 (continued)

(f) Recursive binary relationship

ER model constructs using the Chen notation

ER model constructs using IDEF1X [Bruc92]

Department

Department

Division

Employee

is- managed-by

is-managed-by

is- occupied-by

is-occupied-by

works-on

works-on

1 1

1

Office

Employee

Employee 1

Project M

N

N

N

N

Employee

has

Employee

Employee

EMPLOYEE emp-id emp-name job-class

is-group-leader-of Employee

1

P

is- group-leader-of

Entity,

attribute

(no operation)

Entity Primary key

emp-id emp-name job-class (a) Entity with attributes

(b) One-to-one

(c) One-to-many, many side optional

(d) One-to-many, one side optional

(e) Many-to-many

Nonprimary key attributes

Department

2.2 Advanced ER Constructs

2.2.1 Generalization: Supertypes and Subtypes

The original ER model has been effectively used for communicating fun-damental data and relationship definitions with the end user for a long time However, using it to develop and integrate conceptual models with different end user views was severely limited until it could be extended

to include database abstraction concepts such as generalization The

gen-eralization relationship specifies that several types of entities with cer-tain common attributes can be generalized into a higher-level entity

type—a generic or superclass entity, more commonly known as a super-type entity The lower levels of entities—subsuper-types in a generalization

hier-archy—can be either disjoint or overlapping subsets of the supertype entity As an example, in Figure 2.4 the entity Employee is a higher-level

Figure 2.4 Supertypes and subtypes

supertype Employee

d

subtypes

Secretary Technician

Engineer Manager

Individual

Customer Employee

(a) Generalization with disjoint subtypes

(b) Generalization with overlapping subtypes and completeness constraint

O

abstraction of Manager, Engineer, Technician, and Secretary—all of which are disjoint types of Employee The ER model construct for the generalization abstraction is the connection of a supertype entity with its subtypes, using a circle and the subset symbol on the connecting lines from the circle to the subtype entities The circle contains a letter

specifying a disjointness constraint (see the following discussion) Spe-cialization, the reverse of generalization, is an inversion of the same

con-cept; it indicates that subtypes specialize the supertype

A supertype entity in one relationship may be a subtype entity in another relationship When a structure comprises a combination of

supertype/subtype relationships, that structure is called a supertype/sub-type hierarchy or generalization hierarchy Generalization can also be

described in terms of inheritance, which specifies that all the attributes

of a supertype are propagated down the hierarchy to entities of a lower type Generalization may occur when a generic entity, which we call the supertype entity, is partitioned by different values of a common attribute For example, in Figure 2.4 the entity Employee is a generaliza-tion of Manager, Engineer, Technician, and Secretary over the attribute

“job-title” in Employee

Generalization can be further classified by two important constraints

on the subtype entities: disjointness and completeness The disjointness

constraint requires the subtype entities to be mutually exclusive We denote this type of constraint by the letter “d” written inside the gener-alization circle (Figure 2.4a) Subtypes that are not disjoint (i.e., that overlap) are designated by using the letter “o” inside the circle As an example, the supertype entity Individual has two subtype entities, Employee and Customer; these subtypes could be described as overlap-ping, or not mutually exclusive (Figure 2.4b) Regardless of whether the subtypes are disjoint or overlapping, they may have additional special attributes in addition to the generic (inherited) attributes from the supertype

The completeness constraint requires the subtypes to be all-inclu-sive of the supertype Thus, subtypes can be defined as either total or partial coverage of the supertype For example, in a generalization hier-archy with supertype Individual and subtypes Employee and Customer, the subtypes may be described as all-inclusive or total We denote this type of constraint by a double line between the supertype entity and the circle This is indicated in Figure 2.4b, which implies that the only types of individuals to be considered in the database are employees and customers

2.2.2 Aggregation

Aggregation is a form of abstraction between a supertype and subtype entity that is significantly different from the generalization abstraction Generalization is often described in terms of an “is-a” relationship between the subtype and the supertype—for example, an Employee is an Individual Aggregation, on the other hand, is the relationship between the whole and its parts and is described as a “part-of” relationship—for example, a report and a prototype software package are both parts of a deliverable for a contract Thus, in Figure 2.5, the entity Software-prod-uct is seen to consist of component parts Program and User’s Guide The construct for aggregation is similar to generalization, in that the super-type entity is connected with the subsuper-type entities with a circle; in this case, the letter “A” is shown in the circle However, there are no subset symbols because the “part-of” relationship is not a subset Furthermore, there are no inherited attributes in aggregation; each entity has its own unique set of attributes

2.2.3 Ternary Relationships

Ternary relationships are required when binary relationships are not suf-ficient to accurately describe the semantics of an association among three entities Ternary relationships are somewhat more complex than binary relationships, however The ER notation for a ternary relationship

is shown in Figure 2.6 with three entities attached to a single relation-ship diamond, and the connectivity of each entity is designated as either

“one” or “many.” An entity in a ternary relationship is considered to be

“one” if only one instance of it can be associated with one instance of

Figure 2.5 Aggregation

Software-product

A

User’s Guide Program

each of the other two associated entities It is “many” if more than one instance of it can be associated with one instance of each of the other two associated entities In either case, it is assumed that one instance of each of the other entities is given

As an example, the relationship “manages” in Figure 2.6c associates the entities Manager, Engineer, and Project The entities Engineer and

Figure 2.6 Ternary relationships

Each employee assigned to a project works at

only one location for that project, but can be

at different locations for different projects At

a particular location, an employee works on

only one project At a particular location,

there can be many employees assigned to

a given project.

A technician uses exactly one notebook for

each project Each notebook belongs to one

technician for each project Note that a

technician may still work on many projects

and maintain different notebooks for

different projects.

Project Technician

Notebook 1

notebook

Functional dependencies

(a) One-to-one-to-one ternary relationship

emp-id, project-name notebook-no emp-id, notebook-no project-name project-name, notebook-no emp-id

→

→

→

Employee Project

Location 1

assigned-to

Functional dependencies

(b) One-to-one-to-many ternary relationship

emp-id, loc-name project-name emp-id, project-name loc-name

→

→