Database Program Translation - Information Systems Reengineering, Integration and Normalization - page 186

language. Rewriting is very costly due to the number of bridge program(s) needed
for each application program. Coexistence requires companies maintain two dif-
ferent DBMSs at the same time, which requires much manpower. As a result, the
relational interface approach is the preferred option.
Our approach applies a preprocess to map a network schema to an information-
capacity-equivalent relational schema. This open schema includes derivation of
primary and foreign keys in the transformed relational tables. Our objective is to
implement the mapped relational schema over existing network schema to form an
open internal schema that can be used concurrently by both relational and network
database programs.
Before program conversion, we must translate the network schema to a rela-
tional schema without loss of information. Translation from network to relational
schema involves a one-to-one mapping between the record type and the relation.
The set structure of the network schema is translated into the referential relationship
between child and parent relations. For example, Zaniolo ( 1979 ) designed a set of
relations that recast the network schema in terms of a relational model. In this struc-
ture, each network record type is mapped to a relation on a one-to-one basis. The
record key of network schema is mapped to a primary key in the relational table.
However, if the existing network record key is not unique, then we must concat-
enate it with its owner record key to create the primary key. The owner record key
is also mapped as a foreign key in the relational table to link the parent and child
records. If the set membership in the network schema is manual, then the record
key of the member record will be mapped as a candidate key in the relational table.
Our approach enhances this schema translation by putting the translated rela-
tional record keys into secondary indices. The implementation of such secondary
indices in each nonrelational record forms an open schema so that the access path
of each record type takes only one I/O, same as in the relational database primary
indices. Secondary indices are composed of the record identifier that were derived
from the primary keys of the owner records. The target of the secondary indices is
each record type of the network database.
Basically, there are three types of record identifiers: fully internally identified,
partially internally identified, and internally unidentified as described in Chap. 3.
The record identifier is derived from the semantics of the existing network database.
However, once a real-world situation has been modeled in a network schema, some
of the semantics are irretrievable. We thus need user input to distinguish each type
of record identifier so that we can recover its semantics. Figure 5.5 shows that such
record identifiers are stored in the secondary indices in an existing nonrelational
database (where F = fully internally identified, P = partially internally identified, I
= internally unidentified, and IX = secondary indices).
In Fig. 5.6 , we show a system flow diagram for an embedded-SQL program that
accesses the existing network database as an open database. Open in this context
means that a network database with secondary indices can be accessed by both net-
work and relational database programs.
The overall procedure for creating this relational interface involves the following
steps: