Selection of reverse engineering methods for relational databases

Data & knowledge engineering, 1993

This paper describes an algorithmic method for transforming a Relational database schema to a Binary-Relationship one. The source schema may consist of relations that are at any level of normalization, and the designer may add semantic information on the source schema, such as the definition of candidate keys, foreign keys, functional dependencies of various types, multi-valued dependencies, many-to-many constraints, inclusion dependencies, and others. Based on this information, the multi-stage transformation algorithm applies mapping rules to generate object-types, binary-relationships and constraints in the target conceptual schema. The method is implemented as a PC-based tool, utilizing Ingres, SQL and C, and is part of a comprehensive database design tool for both forward and reverse engineering.

Reverse engineering applied to databases permits to extract a conceptual schema that represents, at a higher level of abstraction, the database implementation. This resulting conceptual schema may be used to facilitate, among others, system maintenance, evolution and reuse. In the last years, the use of object-relational constructs was incorporated into database development. However, reverse engineering techniques for these specific constructs have not been yet provided. In this sense, the main goal of this paper is to present a method that considers these new constructs in the reverse engineering of an existing object-relational database. As a result of the process, our method returns an equivalent conceptual schema specified in UML (extended with a set of OCL integrity constraints) that represents, at a conceptual level, the database schema. We provide a prototype tool that implements our method for the Oracle9i database management system. context Checkpoint inv: Checkpoint.allInstances->isUnique(id) context Person inv: self.age > 10 context Person inv: Person.allInstances->isUnique(name) context Address inv: self.floor->size()<=10 self.town->size() <= 30 context Address inv: self.floor->size() <= 10 context Address inv: self.street->size() <= 40 3 Obtained CS

Information & Software Technology, 1995

This paper describes the steps of a reverse engineering process for translating a hierarchical data schema into a conceptual description in the extended entity-relationship model. The methodology presented is composed of well-defined tasks which, due to the good level of automation, forecast the possibility of a profitable use of CASE tools. However, the final production of a semantically richer conceptual schema requires the involvement of the designer, whose experience could be implemented with artificial intelligent techniques. The forward process is also analysed to determine all useful decisions which could be applied in the reverse methodology. In addition, an example is presented which illustrates the real applicability of the proposed approach.

Electronic Notes in Theoretical Computer Science, 2003

This paper presents a solution and a methodology to recover legacy databases of most DBMS using formal-method based techniques. These formal methods (terms rewriting systems) are applied during the data reverse engineering process and allow for an automatic approach. This automatic approach reduces the time invested and the number of people involved in the data reverse engineering and data migration

Conference on Software Maintenance and Reengineering, 2001

Database reverse engineering (DBRE) attempts to recover the technical and semantic specifications of the persistent data of information systems. Dependencies between records (data dependency) form a major class that need to be recovered. Since most of these dependencies are not supported by the DBMS, (foreign keys are the main exception, at least in modern relational DBMS), they have not been

Proceedings Seventh Working Conference on Reverse Engineering, 2000

Data reverse engineering is a rapidly growing field which is sometimes misunderstood. In our effort to promote the realization that data reverse engineering is a valuable and essential part of reverse engineering and is now finding its place in software engineering, we present a summary of the history of data reverse engineering. In this paper, a definition of data reverse engineering, a summary of the history of what has been done and published, a statement about the state-of-theart today, and a comment on the future of DRE is presented.

Data & Knowledge Engineering, 1994

A methodology for extracting an extended Entity-Relationship (EER) model from a relational database is presented. Through a combination of data schema and data instance analysis, an EER model is derived which is semantically richer and more comprehensible for maintenance and design purposes than the original database. Classification schemes for relations and attributes necessary for the EER model extraction are derived and justified. These have been demonstrated to be implementable in a knowledge-based system; a working prototype system which does so is briefly discussed. In addition, cases in which human input is required are also clearly identified. This research also illustrates that the database reverse engineering process can be implemented at a high level of automation.

Working Conference on Reverse Engineering, 1995

This paper proposes a general architecture for Information systems (or data-centered applications) reverse engineering CASE environments. Recovering the specifications of such applications requires recovering first those of their data, i.e. database reverse engineering (DBRE). First, the paper describes a generic DMS-independent DBRE methodology, then it analyses the main characteristics of DBRE activities in order to collect a set of minimum

1999

Database reverse engineering (DBRE) methods recover conceptual data models from physical databases. The bottom-up nature of these methods imposes two major limitations. First, they do not provide an initial high level abstract schema suitable for use as a basis for reasoning about the application domain: a single detailed schema is only produced at the very end of the project. Second, they provide no support for a divide-and-conquer approach: the entire database schema must be analysed and processed as a unit, and cannot be divided into smaller database schemas. We present a simple solution to overcome both limitations. In our proposal, relations are grouped based on their primary keys. Each group can be perceived in two ways as a relational schema that can be reversed engineered as a standalone DBRE project; and as an element, either an entity or a relationship, of a high-level abstract schema that provides initial insight about the application domain. We also present examples from actual large database systems

Proceedings of the Twelfth International Conference on Data Engineering

This paper describes a method to cope with denormalized relational schemas in a database reverse engineering process. W e propose two main steps to irnprove the understanding of data semantics. Firstly we extract inclusion dependencies by analyzing the equijoin queries embedded in application progranis and hy querying the database extension. Secondly we show how to discover only functional dependencies uhicli in-the database extension, the application programs, but especially expert users. * Expressing the extracted semantics with a high level data model This task consists in a schema translation activity and gives rise to several difficulties since the concepts of the original model do not overlap those of the target model. fluence the way attributes should be restructured. The method is interactive since an expert user has to validate the presumptions on the elicited dependencies. Moreover, a restructuring phase leads to a relational schema an third normal form provided with key constraints and referential integrity constraints. Finally, we sketch how an Entity-Relationship schema can be derived from such information.