Information Systems Reengineering, Integration and Normalization - Information Systems Reengineering, Integration and Normalization - page 11

users. The main reasons are that information systems are complex systems that
require multiple environments to deal with different situations. In general, there are
four different situations that system developers will meet when designing an EDS.

• Case1:BuildinganewEDS.Thesystemdevelopermustcreatenewdatabase(s)
and expert system(s) for the EDS. No usable systems exist.
• Case2:Reusingexpertsystem(s).Thesystemdeveloperreusesexistingexpert
system(s) and builds new database(s) for the EDS.
• Case3:Reusingdatabase(s).Thesystemdeveloperreusesexistingdatabase(s)
and builds new expert system(s) for the EDS.
• Case4:Reusingbothdatabase(s)andexpertsystem(s).Thesystemdeveloper
reuses both existing database(s) and expert system(s) in the EDS.

The last three cases use the concept of reengineering to save the cost of implemen-
tation. A recent EDS empirical survey conducted in the UK has shown that a large
number (59 %) of the respondents thought that enhancing existing systems to couple
both technologies is the most feasible approach. The main reason behind this result
is the concept of reengineering.

1.3 The Problems

Database system reengineering is not an easy task. The acquisition and running of a
new system is both a long-term commitment and a long-term investment for an or-
ganization. This being the case, it is important that the top management understand
the objectives of committing to a new environment, as well as some of the problems
that may lead to the collapse of such a project.
The following are the major strategic issues that must be considered in the early
stage of the reengineering process.

1.3.1 Selecting a Database Model

Advocates of network and hierarchical models argue that the two models corre-
spond more closely to the real world, and that there is less redundancy of data. Since
the connections among the data are built into the database structure, access time is
shorter, therefore making the two systems very suitable for fairly stable databases
with uses that can be precisely predetermined.
Supporters of the relational model argue that the relational concept is simple
and that the model can provide flexibility and data independence. Since an orga-
nization's need for information changes over time, and because having a database
encourages new uses, this flexibility is highly desirable.
One might wonder with these comparative advantages why all databases are not
relational in nature. The answer is that for many applications the relational model is