REVER

Written By:
Published:
Content Copyright © 2008 Bloor. All Rights Reserved.

REVER, which is French for dream (as in reverie), is a Belgian company that has taken research originally undertaken at Namur University and commercialised it. Put simply, the company provides both model-driven engineering and model-driven reverse engineering. And when I say “model-driven” I do not mean that loosely but specifically based on a model-driven architecture. That is, with conceptual (UML, Entity/relationship and so on), logical (relational, XML, network and so forth) and physical (DB2, Oracle, Sybase …) models.

The company’s products are DB-Main, which the company refers to as a modelling tool and it has various programming language analysers which I will come back to. Now, without even describing DB-Main it should be obvious that it could be used for a variety of purposes, starting with new developments, but in this article I want to concentrate on its use for data migration because, in this respect, as far as I know, REVER is unique. Moreover, it represents a very interesting alternative approach to data migration compared to that traditionally espoused by data integration vendors.

The actual processes you go through will depend on the environment, both in terms of source/target environment and whether you are running a big bang type migration or an incremental one. However, to take a simple example, suppose you are migrating from an Oracle database to SQL Server: then you reverse engineer your existing database schema to create a physical model, next you transform that into a logical model and finally you then map to a physical model for SQL Server. Once that is complete the software will generate appropriate data extraction programs for you automatically and then load the data. Cool or what?

To go a bit further, if you want to migrate from IDMS to Oracle, say, then you have to do a bit more work because these databases do not share a common logical (relational) model so, after creating the logical model you have to transform this to a conceptual model where the relational and hierarchical/network do share common characteristics and then back down through a logical (relational) model to the physical Oracle schema. A similar approach would apply if you wanted to migrate between XML and relational sources.

However, this isn’t the end of the story. Remember those programming language analysers I mentioned? They have two functions. The first one is to analyse any source programs that embed data dependencies that are not in the database schema. This is necessary because legacy database management systems (such as IDMS) could not express all the necessary constraints (such as foreign keys) within the database and so programmers typically implemented what was necessary within their programs rather than asking to the DBA to change the structure of the database. And, as an aside, I’ve known developers to embed data rules in applications even when they were working with a relational database, so this isn’t just applicable to legacy environments. Anyway, after the program analysers have done their job, you should have a complete model (including all the constraints not implemented in the database but in programs).

The second use for the language analysers is to transform source programs from the old environment to the new one by replacing all source database calls by calls to the target database. For example, they can replace IDMS verbs by calls to wrappers that simulate legacy data access on top of the new database, say, MySQL. Moreover, these analysers aren’t one-off products: they themselves are generated, using REVER tools, from a formal definition of the language to be analysed. The company tells me that it has yet to find a language that it could not generate an analyser for.

However, there is bad news in case you are getting all excited about this: REVER only markets to systems integrators & vendors, not end users, either on a project basis or as a black box or via technology transfer. Further, it is only active in Belgium, France, Luxembourg and the Netherlands (via a partner) though the company is currently in the process of negotiating contracts with large integrators, to cover the whole of Europe. Its third party partners include Bearing Point, CSC and Unisys amongst others but, in any case, you can always make them an offer they can’t refuse: it could be worth it.