Database merge

1. Database merge

2. Table of contents • Please, do not remove this slide if you want to use the Create table of contents functionality. • How to use: • First finalize your presentation • When your done choose Create table of contents from the TE Tools tab • Title slide headings will get the first level bullets • Content slide headings the second level bullets • Front page and Table of contents page will not be included • If you have content slides without headings, those will not be included • Note! Table of contents will be always created on the second slide of your presentation. If you have removed the slide or used it as content slide, insert a new empty slide on that place.

3. I have 2 DB that I have to merge. Which are the different alternatives and how to solve the merging riskless, quickly and with an appropriate cost ?

5. What does this mean for IT merge scenario’s merge B to A (or A to B) prog A prog B prog B prog C prog B prog A progB prog A prog A prog A A+B merge A & B into C merge A & B to obtain (A+B) A B C A A B A B

6. SCENARIO 1 MERGE SCENARIO 1 MERGE A INTO B (or B to A) prog A prog B prog A A B A • from a technical point of view it is a simple problem of “data migration” • the data of applications A have to be moved to database B • business have to decide the “best” application (A or B) for their needs • for data migration two main problems must be solved • the compatibility between the source (A) and source (B) • the “deduplication” question A Risk & complexity

7. SCENARIO 2 MERGE SCENARIO 2 MERGE A & B INTO C prog C prog A progB C A B • business selected application C which is • a new or an existing application • a package • the database structure C is different from database A structure and database B structure • from a technical point of view it is a problem of two “data migration” • the data of applications A have to be moved to database C • the data of applications B have to be moved to database C • this scenario is the same as the previous one: the problems are same but must be solved two times A Risk & complexity

8. SCENARIO 3 MERGE SCENARIO 3 MERGE A & B TO OBTAIN (A+B) prog A prog B prog A prog B A+B A B • the database structure (A+B) is a “meta structure” integrating database A structure and database B structure the target (A+B) are obviously “compatible” with source A & B • from technical point of view it is a problem of two “application migration” • the database (A+B) have to be defined • for A application • the data have to be “moved” to (A+B) • programs must be adapted to use (A+B) • for B application • the data have to be “moved” to (A+B) • programs must be adapted to use (A+B) • for “data” only the problem of “deduplication” must be solved A Risk & complexity

9. IMPACTS OF THE 3 SCENARIO merge scenario’s prog B prog A prog A prog B prog A prog C prog A progB B A A A C B B A 1 2 3 prog A prog B A+B A Risk & complexity

10. WHAT IS THE BEST SCENARIO ? THE BEST SCENARIO IS THE ONE PRODUCING A SOLUTION COMPLIANT TO BUSINESS NEEDS Two ways to know the business needs : a classical top-down approach starting from “business needs” a bottom-up approach starting from the existing applications (A &/or B) this two approaches are complementary REVER’s technologies help the “project owner” (business) to understand, based on the semantic model, which system of the two existing application is the most appropriate to answer their needs to evaluate differences between the 2 sources . to check how far they are compatible

11. WHAT IS THE PROBLEM OF THE IS“COMPATIBILITY” two Information Systems are “compatible” if they share the same concepts at the semantic level (IS definitions) This means that for a merge of two databases it is necessary to compare concepts and definition of the two semantics schemas (semantic level) to compare the database structure implementation of the logical schemas (logical level) to compare the data value of the two databases (physical level)

12. EXAMPLES OF SEMANTIC DIFFERENCES Source 1 Source 2 example 1 : definition differences contracts : a contract can only be signed by one person contracts : a contract can be signed by one person Or by a group example 2 : relational differences contracts contracts impoverishment ? additional clauses enrichment additional clauses disasters disasters

13. EXAMPLES OF LOGICAL DIFFERENCES

14. EXAMPLES OF PHYSICAL DIFFERENCES

15. WHAT DOES REVER’s TECHNOLOGIES BRING TO A DATABASE MERGE for scenario 1 & 2 : REVER’s technologies rebuild the three level (physical, logical, semantic) models for the source and the target database allow the business to compare the two semantic models and to define the “mapping” between source and target model at semantic level based on this mapping compare automatically source and target models at logical and physical level check the data quality in the source and target databases identify where are the ‘incompatibility” between source and target databases allow to define mapping “rules” to “map” the data from source to target database generate automatically programs to move, transform and load data identify which programs present higher risks and must be tested

16. for scenario 3 : REVER’s technologies rebuild automatically the three level (physical, logical, semantic) models for the two databases build a “meta” model for the “target” database” which included all structures and relations of both databases generate automatically programs to move data from the two sources databases to the target adapt automatically programs of the two source applications to use the target database identify which programs present higher risks and must be tested this solution is very useful when the source databases are implemented in different DBMS (e.g. IMS and IDMS) and the target is a third DBMS (e.g. : relational) It is the solution of choice to have a “quick and riskless merge” giving time to think more in detail which other scenario would best fit the business needs and evolution ( rewrite the application, buy a package…) WHAT DOES REVER’s TECHNOLOGIES BRING TO A DATABASE MERGE

17. The different steps for scenario 3 SCENARIO 3 DETAILS

18. In a nutshell, where can REVER help ? Before deploying the right approach The first decision is a business decision Rever can highlight the risk linked to the chosen approach REVER can highlight the order of migration of each procedure (group) Identification of all links between procedures Technical phasing integrating programs & data During deployment of the selected approach Target DB conception Data quality control and compatibility with the new structure Automatic generation of the unload/load programs Mapping help Source/target Automatic programs transformation if needed After migration Logical dataset extraction Knowledge base available for future evolutions XML comparator

19. REVER ADDED VALUE On top of the added value induced by the MDDE: Automatic generation of the programs Documentation always available Models available after migration REVER solutions provide several added values: Choice between “soft” evolution or“Big Bang” Optimized native target base, ready for new developments Integration into the target model of new functions and/or constraints if needed Data validation before merging Consistency of the merged data Merging checks Automatic modification of the existing programs to access the new DB

20. MERGING ACTIVITIES

21. Questions & Answers