Advanced Database Concepts



Advanced Database Concepts

Introduction

Software reengineering is the modification of the functionalities or structures of a software system in order to improve the quality of the software. Software reengineering includes two parts: reverse engineering and forward engineering, i.e., traditional software engineering. Reverse engineering analyzes the implementation of a legacy system, and then abstracts such information into high-level design representations in order to obtain the design specification of the original system. With the specification, the meaning of the source code can be comprehended, and the future maintenance or replacement work may be performed much easier. Most reverse engineering works focus on uncovering programming logic and functions of application software. Data reverse engineering, on the other hand, concentrates on data model recovery of legacy systems(Elmasri and Navathe, 2008).

In the given case, the major goal of data reverse engineering efforts is to reconstruct the data model of a database system in the form of an entity relationship diagram (ERD) or extended ERD . Therefore, they are also called database reverse engineering (DBRE). Although the focus is on database, to recover a data model may require analyzing source code, program control language and data description language (Dav 96). The domain knowledge of the database system is also important to formulate a general data reverse engineering methodology .

Current DBRE researches presume that the information regarding semantics of attributes, primary keys, and foreign keys in database tables is complete. They claim that such information may not be well documented, but they can be derived directly from the database tables. For example, the name of an attribute could provide the semantics of the data items in the attribute.

However, this may not be the case. In a recent DBRE effort to derive a data model from a table-based database system, we find the data content of many attributes are not related to their names at all. To make things worse, the designer of the database cannot be consulted to resolve these mysterious attributes (Elmasri and Navathe, 2008). Certain schemes need to be developed to solve this problem. Hence, the aim of this paper is to present our DBRE experience and techniques for solving the aforementioned difficulty. The general DBRE process is described in Section 2. The techniques that we adopt are detailed in Section 3. Section 4 covers the overall DBRE case study. Some related work is discussed in Section 5, and finally the conclusion is given.

The above figure shows the general business process of Happy Homes Ltd. As from the case study, we can see that the management at Happy Homes is engaged in developing homes for its clients, the above diagram exactly reflects the overall structure that reflects how the management at Happy Homes meet its operating activities. The first part is the analysis of clients needs, then plan and proposal is made which is followed by contract and collection. The approval of client is taken after visiting the site.

The above diagram shows the logical map for Happy ...