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

Chapter 5
Database Program Translation
The concept of a relational database was first proposed by E.F. Codd in 1970. It was
almost instantaneously recognized as a more user friendly model than the previous
nonrelational (e.g., hierarchical or network model) database model. However, it
was not adopted by the industry until the early 1980s because of its poor perfor-
mance. Throughout the 1980s, the performance of relational databases improved
and gained wider industry acceptance. This created a need to convert existing data-
bases into a relational structure. Yet database conversion is both a costly and time
consuming process. The majority of time spent in such conversion projects is spent
on the process of program translation.
To translate a program it is necessary to determine the functions and semantics
of the program. Programmers often make assumptions about the state and order-
ing of the data in the database without stating these assumptions explicitly in their
programs. Therefore, it will usually be necessary to provide more information about
the semantics of the program than can be extracted from the program text and its
documentation alone. Also needed in the program conversion process is informa-
tion about the data structure of the program before translation, the new structure of
the program after translation, and how the two are related.
In general, there are five basic approaches in program translation: emulation,
software interface (bridge program), decompiling, coexistence, and rewriting. We
develop a relational interface as the software interface for our proposed method-
ology. We have improved the performance by implementing an internal schema
that let both relational and nonrelational database programs access a common data
structure without database navigation. Database navigation is not user friendly
because the users can only access a record by following through its access path. It is
also inefficient because each database access may take several I/Os.
The five basic approaches and our “enhanced interface” approach are described
in the following sections.