An approach for reverse engineering of relational databases

Abstract

he rationale for reengineering is straightforward: new software is expensive to develop, but old software can be costly to maintain and adapt to new uses. The goal of reengineering is to mechanically reuse past development efforts in order to reduce maintenance expense and improve software flexibility. Reengineering is applicable to diverse software such as programming code, databases, and inference logic [2]. This article focuses on the topic of databases and, in particular, relational databases (RDBs).There are various motives for reverse engineering of databases. One may want to migrate among database paradigms: from past hierarchical, network, and relational databases to modern relational and objectoriented databases. A more mundane task would be to migrate between different implementations of a database paradigm, for example, from one vendor's RDB to another's RDB. Reverse engineering can also elucidate poorly documented existing software when the developers are no longer available for advice. We have derived substantial benefit from reverse engineering of vendor software. Reverse engineering provides an unusual source of insight.Object-oriented models provide a natural language for facilitating the reengineering process. An object-oriented model can describe the existing software, the reverse-engineered semantic intent, and the forwardengineered new system. This article adopts the object-modeling technique (OMT) notation for modeling data [7]. Graphical OMT models are intuitive, yet provide a rigorous basis for specifying software. OMT concepts are similar to those in extended entity-relationship modeling.This article makes two major contributions: 1) We propose a more robust process than advanced in the literature. We recognize generalization early in our reverse-engineering process and provide guidelines for coping with design optimizations and unfortunate implementation decisions. Our process emphasizes analysis of candidate keys rather than primary keys. We incorporate three sources for information: schema, observed patterns of data, and our semantic understanding of application intent. 2) We report our experiences with industrial examples. Typical liTipleinentation Strategies for Forward EngineeringReverse-engineering strategies must consider past practices. In our case studies we have seen some surprising design techniques. Often the model or its implementation as a schema was fundamentally flawed or violated good design practice. We found violations of most of the assumptions that are made in existing reverse-engineering methods.Classes. Each class is usually implemented as a table, with a column for each attribute. Unique indexes are usually specified on primary and candidate keys. There are several approaches to constructing a primary 42 May 1994/Vol,37, No,5 I UHICATIOHS OF THB ACM 30 s 2S 20-M

Co-expression analysis among microRNAs, long non-coding RNAs, and messenger RNAs to understand the pathogenesis and progression of diabetic kidney disease at the genetic level

“…One popular idea in numerous semantic search systems ([24–28] for example) is to expand the query keywords utilizing synonyms and other relations not originally part of the query. A second way to implement semantic search is to translate the original keyword-based search into some formal semantic queries through the adoption of domain ontologies.…”

Static Analysis of Data-Intensive Applications

“…a) Database reverse engineering: Reverse engineering databases (e.g. modeling data with OMT models [17]) can be considered as a different field, but it has some common points with data-intensive systems. Hainaut published a book on this topic [18] and Henrard wrote his PhD thesis on it [19].…”

A process for assessing data quality

“…The data volume grows much more than what was expected and the data usage turns out to be quite different than what was originally foreseen. It becomes necessary to reengineer the database [3].…”