[news.eclipse.modeling.gmt.modisco] Re: RelationalWare 2 ModelWare

[Jean-Marie Favre <Jean-Marie.Favre@xxxxxxx>]

Thanks mikael for your detailled analysis of the issue!
This is quite close to what I was thinking, but one never
know everything ;-)

1) AD-HOC MODEL HANDLER FOR DB
> It may be a bit though because you have to analyze the DB schema to 
Yes, this analysis is the funny part. Fortunately there have been quite
some work in the reverse community about that.

2) GENERIC DATABASE -> MODELWARE, then SPECIFIC MODEL TRANSFORMATION
> 2) You can develop a discoverer like the one available in the MoDisco 
> tool box 
> (http://www.eclipse.org/gmt/modisco/toolBox/RelationalDBInformation/). 
> It can be tough too.
Yes, but at least this is in ATL not in Java.

3) DATABASE -> TEXT -> TCS -> MODEL
> 3) Using some RDBMS-specific tools to extract data and schema from the 
> database in a concrete representation (XML, textual...). It is not a 
> very generic and not very smart, I agree with you. Then, you can develop 
> injectors for these concrete representations and finally define model 
> transformations like in the last step of (2).
In fact we something similar to that for some other data source. The
benefit is to have a clear view of the intermediate step. This could be
useful with text based processing tools.


> It can be very difficult to transform the 
> database content model in another model because of the big semantic gap. 
Yes, this is why it is funny. This is also why we should rely on large
body of work done in the DB reverse engineering community.

> It can be solved by keeping a record of the links between this model and 
> the schema model (those links could be kept in a Weaving model for 
> instance :)). Those links would represent the "type" of tuples and 
> tuples' elements. It really is the mu relationship of the RDBM Technical 
> Space that is injected into the modeling world !! 

Indeed, the weaving solution is the part I had to explore
(but before that I wanted to know if this was already solved).
I didn't read yet Marco's phd, so... I will study more closely
what you say.


============================================================
MODEL -> DATAWARE

> 1) You can use Teneo 
> (http://www.eclipse.org/modeling/emft/?project=teneo) or something 
> similar that create automatically a mapping between your models and a 
> relational database. It is a technical solution to your question, but it 
> works :) It may have some drawbacks, but more investigation are needed.
Ok. I will check. In fact, in some of my usecase the database schema
already exist, so this change quite a bit. I know mapping tools such as
Castor for XML-Java, and I guess that just like these tools Teneo can
handle various scenario. Thanks for the info. (They are so many
things going on on this planet, that it is hard to follow!)

> 2) You can store your models in a Object Database (like DB4O 
> http://db4o.com/). As almost every metametamodel implementation use 
> object oriented paradigm, it should be very easy to make it work. Same 
> as before, more investigation are needed.
I used this solution in the past for my tool GSEE. And this is actually
very easy because there is almost nothing to do ;-) I've just made a
generic wrapper for the connection to the Objectstore database (the
one I used at that time), and then everything was working just fine.
At that time I had a metametamodel more or less like EMF or MOF, but
proprietary (this was in 2000...). I made bridges for various stuff,
but now I have to start again with standard technologies.