Schema Translation - Information Systems Reengineering, Integration and Normalization - page 96

primary key for all the mapped relations. The “subclass predicate” attributes (one
for each subclass entity) will be mapped as attributes of the “generalized” relation.
As an example, the overlap generalization of Fig. 3.11 can be mapped to the fol-
lowing relations:

5HODWLRQV
3HUVRQ 1DPH $GGUHVV3KRQH$JH6H[(PSOR\HHIODJ
$OXPQXVIODJ6WXGHQWIODJ
(PSOR\HH 1DPH 6WDUWGDWH6DODU\
$OXPQXV 1DPH *UDGXDWLRQGDWHGHJUHH
6WXGHQW 1DPH 6XSHUYLVRUGHSDUWPHQW

where Employee-flag, Alumnus-flag, and Student-flag are used to indicate the
membership of a person who can be an employee and an alumnus and a student.

3.3.1 Case Study of Mapping a Network Schema to a Relational

Schema

Figure 3.22 is a network schema for a university enrollment application in which
departments offer courses in sections that are taught by instructors. Students enroll
for sections of courses. Each course has one prerequisite. Each department has in-
structors who teach sections of courses. Students obtain grades for the sections they
take. The following steps illustrate the different stages in the translation process.
Preprocess step 1 (implied relationship), preprocess step 2 (alternative paths),
step 1 (derive unary relationship), and step 3 (derive n-ary relationship) are not
applied since there are no implied relationships (i.e., no duplicate key fields), no
multiple access paths (i.e., no alternative paths), no unary relationships (i.e., no
member records consisting of pointers only and referring back to its owner record
occurrences), and no n-ary relationships (i.e., more than two owners or member
record types linked to each other through sets).
Step 2—Derive binary relationships.
The user specifies a 1:1 relationship between Course and Prerequisite. The rela-
tionships between the entities are shown in Fig. 3.22 .
Step 4—Derive aggregation entities.
The m:n relationship derived in step 2 is in aggregation because its relationship
relation Section also relates to the entity Student in another m:n relationship as
shown in Fig. 3.23 .
Step 5—Derive entities keys.
Entities are partially internally identified by default. In this case, the identifier
type of record Prerequisite has been changed from partially internally identified to
fully internally identified through user interogation. Thus, we have its key changed
as follows: