Information Systems Reengineering, Integration and Normalization

The primary goal of electronic data processing (EDP) in the 1960s and 1970s was the automation of existing business operations in organizations. However, except for the quick availability of more accurate management reporting information, such operations were automated without fundamental changes. During these two decades, data was stored in flat file formats that could be classified into two different forms, namely batch files and online files.

The hierarchical data model is a logical schema and can be viewed as a subset of a network model because it imposes a further restriction on the relationship types in the form of an inverted tree structure. The linkage between record types is in an automatic fixed set membership. The database access path of a hierarchical database follows the hierarchical path from a parent to child record. The default path is a hierarchical sequence of top-to-bottom, left-to-right, and front-to-back.

A database system consists of three components: schemas, data, and programs. Database reengineering starts with the schema, which defines the meaning of data and their relationship in different models. Only after a schema has been redefined can data and programs be reengineered into a new database system, which makes use of the translated schema. Schema translation is the process of changing a schema expressed in one data model into an equivalent schema expressed in a different data model.

The objective of data conversion is to convert between database systems without any loss of information. The data conversion process must transform the data from one data structure to another whilst preserving its semantics. Data conversion uses the data structure of the schema that results from schema 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 performance. Throughout the 1980s, the performance of relational databases improved and gained wider industry acceptance. This created a need to convert existing databases 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.

As database technologies evolve from hierarchical and network (nonrelational) databases to relational and object-oriented models, and as relational databases grow in power and popularity, developers face pressure to convert legacy databases to this newer model. In this chapter, as a part of database reengineering, the problem of reusing a nonrelational database system is explored. Direct database systems conversion from nonrelational to relational is not feasible due to the nature of reverse engineering, i.e., translating from low-level procedural data manipulation language (DML) of a nonrelational database to an equivalent but higher abstract level nonprocedural DML of a relational database. The approach of adding a relational interface to a nonrelational database is preferred. The relational interface is constructed by mapping a nonrelational schema to an equivalent relational schema. Secondary indices are added to the nonrelational schema and database so that relational DML does not require database navigation to access nonrelational database. The modified schema and database can be accessed by both nonrelational and relational database programs. Such capability can help companies to extend the life of their nonrelational DBMSs by making them “Relational-like” DBMSs. The nonrelational database programs can be phased out or rewritten to use embedded SQL. After all of the nonrelational database programs are eliminated, then we can complete the database conversion process by converting the data of the nonrelational database to a relational database replacing the nonrelational DBMS (i.e., a “Relational-like” DBMS with a relational interface) by a relational DBMS.

Over the last two decades, a number of database systems have come into the market by using predominant data models: hierarchical, network, relational, object-oriented (OO), and XML. As the performance of the relational database (RDB) is improved, it has been accepted by the industry and created the need of converting companies’ hierarchical or network database to RDB and XML. To meet users’ requirements, there is a need to support various data models in a single platform. However, due to the implied constraints of the various data models, it is difficult for organizations to support heterogeneous database systems.

System reengineering is broadly defined as the use of engineering knowledge or artifacts from existing systems to build new ones and is a technology for improving system quality and productivity. Traditionally this work has focused on reusing existing software systems (i.e., software programs, files, and databases). However, knowledge-based systems have also been developed within these organizations and are growing in popularity. It will soon be necessary for us not only to reuse existing databases, but also to reuse the existing expert systems to create new expert systems and expert database systems.

Database normalization aims to remove irregularity (abnormality) of update. The correctness of database after update is difficult to maintain in the unnormalized database, whereas the normalized database is more user friendly for update. On the other hand, the denormalization is the reverse of normalization. It transforms the normalized database design into unnormalized form (UNF). As a result, the denormalized database is difficult to update. Nevertheless, the denormalized database can perform faster than normalized database because it requires less joint operations for query. Also, data normalization eliminates redundant data for better space utilization and user friendliness in database update.

As computer technologies evolve, it becomes a necessity for companies to upgrade their information systems. The objective of reengineering is to protect their huge investments and to maintain their competitive edge. However, information systems reengineering is a complicated task that requires much expertise and knowledge. It needs users’ input to recover lost semantics inside the existing database system and/or the existing expert system. It also requires technical expertise to replace the obsolete information systems with newer systems. Very often, due to lack of methodologies and expertise, companies choose to redevelop rather than reengineer when upgrading their information systems. The purpose of this book is to convince these companies that reengineering is a more cost-effective and feasible solution.