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

• derivingacorrespondingrelationalrecordkeyforeachnetworkrecordtype,
confirmed with the users then
• addingthesederivedrecordidentifiersassecondaryindices to the network
schema
To implement these entity keys in the network schema, we must modify the existing
network schema by adding the derived record identifiers as secondary indices to
each record type so that each record type can act as a relational table. The modified
schema can still be used by the network database program, because the additional
secondary indices will not affect its operation. Since the translated schema is a net-
work schema as well as a “Relational-like” schema to the user, we call it an “open”
schema.
Preprocess step 2. Add the derived secondary indices into the network database.
We perform the data conversion at the logical level of data representation us-
ing an unload-and-upload technique. This technique converts the existing network
database into an open database that embeds the derived secondary indices into each
record. The conversion first unloads the data from each network database record
type into a sequential file, adding the derived record identifier. Then it uploads each
sequential file into the network database according to the modified “Relational-
like” schema with secondary indices composed of the derived record identifiers.
Step 1. Translate SQL to network DML.
The main process of interface creation begins with program translation. To effect
the translation process, we must define the algorithm and syntax for translating the
relational DML (e.g., SQL) to the network DML (e.g., IDMS). After we complete
the schema translation and create an open database by adding secondary indices to
the internal schema, each SQL statement can be mapped to a series of IDMS state-
ments.
The completed program translation will have a one-to-one mapping between
each record type of the nonrelational database and each relation in the relational da-
tabase, which ensures that the output of both DMLs will be the same. The following
sections show the detail of the actual translation algorithms.
The user can now apply SQL statements to access the nonrelational database.
Each SQL (the DML of relational database) statement is translated at the run time
into the lower level DML of network database. The following are the major SQL
statements for the Join, Select, Update, Insert, and Delete operations and their
translation into the equivalent DML language of IDMS, a network DBMS (CA
1992b ).
Relational Operation Project
The general algorithm for projection translation follows, in which all attributes in a
relation R, which corresponds to a record type N, are projected.
Algorithm Projection