Software Re-Engineering - Method

Re-engineering Methodology

Re-engineering Services

Database Re-engineering/Migration

In today's new economy, information is the most valuable asset of a business. The information rendered by data residing in the databases of an organization is the key element that drives faster processes, better communications, quicker response and premier service. The ability to manage and utilize data to make better business decisions, respond to new and rapidly changing business processes and compete more effectively depends on a reliable, flexible and cost-effective database system capable of accommodating the business needs in today's new economy.

The following steps are performed in the area of database re-engineering/migration:

Planning:

Defining the scope of the project and developing a business plan to identify the resources required for the project. This usually constitutes between 5% and 10% of the total effort depending on the size of the project. It is key to implementing a successful re-engineering.

Data Modelling and Migration (DMM):

Designing the new data model and generating the new data migration scripts. Two types of data model transformations are available:

Data Model Replication: The new data model is a normalized replication of the source data model.

Data Model Re-engineering: The new data model reflects significant changes to integrate new tables, new fields, field data type changes, and/or field size changes.

· Perform DDL conversion. Convert the source database physical schema into the target database equivalent and generate all the DDL statements to support that physical schema. Review the new physical design for performance considerations (including indexes, primary and foreign key placement, key selection, and data set placement).

· Migrate the data. Data can be migrated as soon as the target database is installed and the target application schema is created. Unload the source database data to transition data sets and then load to target database from those sets. Watch carefully for data type translation errors or data truncation caused by errors in the unload/load scripts, and for data type mismatches between your source database and target database.

· Convert stored procedures. Source database stored procedure modules usually translate one for one. However, the source language probably will have to be converted to a target database-compliant stored procedure language, then tested and tuned for performance.

· Convert triggers. You may also need to move your source database triggers over to target database to enforce declarative referential integrity. You can modify and tune the new database triggers for optimal performance in the target database environment.

· Convert application code. Take your existing application code, which accesses the source DBMS engine, and replace the database calls with equivalent target database SQL calls to the new database schema. Non-relational sources can be more challenging: Non-relational databases may physically traverse the DBMS structure before calling the data, but a relational database is devoid of such structural DBMS navigation concepts.

Testing:

Linking the test requirements back to the business requirements and securing the project resources needed for testing. This process includes the following different types of testing:

· Unit testing

· System testing

· Integration testing

· User acceptance testing

· Functional testing

· Performance testing

Language Migration

Back to the LinksMultiple eBay Auction | eBay Shopping home page