To appear in: 1996 International Conferene on Software Maintenane (ICSM 96); IEEE Computer Soiety, 1996 A Design Environment for Migrating Relational to Objet Oriented Database Systems Jens Jahnke, Wilhelm Shäfer, and Albert Zündorf AG-Softwaretehnik, Fahbereih 17, GH-Paderborn, Warburger Str. 10, D-33098 Paderborn, Germany; e-mail: [jahnke wilhelm zuendorf]@uni-paderborn.de WWW: http://www.uni-paderborn.de/fahbereih/ag/shaefer/index_dt.html Abstrat Objet-oriented tehnology has beome mature enough to satisfy many new requirements oming from areas like omputer-aided design (CAD), omputer-integrated manufaturing (CIM), or software engineering (SE). However, a ompetetive information management infrastruture often demands to merge data from CAD-, CIM-, or SE-systems with business data stored in a relational system. In addition, omplex dependenies between those data stored in the different systems might exist and should be maintained. One approah for seamless integration of objet-oriented and relational systems is to migrate the data (and the orresponding shema) from a relational to an objet-oriented system. In this paper we desribe an integrated design environment that supports the migration proess and overomes major drawbaks of omparable approahes. 1 Motivation Objet-oriented tehnology has beome mature enough to satisfy many new requirements oming from areas like omputer-aided design (CAD), omputer-integrated manufaturing (CIM), or software engineering (SE). Those new requirements are not fulfilled by relational tehnology [LS88, Mai89]. However, a ompetetive information management infrastruture often demands to merge data from CAD-, CIM-, or SE-systems with business data stored in a relational system. In addition, omplex dependenies between those data stored in the different systems might exist and should be maintained. One approah for seamless integration of objet-oriented and relational systems is to migrate the data (and the orresponding shema) from a relational to an objet-oriented system. The main advantage of this approah is that it is always feasible beause the objet-oriented data model is a superset of the relational model. In more detail, suh a migration proess onsists of three steps whih are (1) the shema migration proess whih s a relational shema to an equivalent 1 objet oriented shema, (2) the data migration proess whih onverts extensions of the relational shema to equivalent 2 extensions of the objet oriented shema and (3) the appliation migration proess whih reates a new appliation program using the objet oriented database for every appliation program that uses the legay database suh that the input/output behaviours of the orresponding appliation programs are idential for equivalent database extensions. Existing approahes supporting shema migration basially argue for a waterfall-like transformation proess, in many ases even without any user interation [NA87, DA87, SK90, JK90, MM90, And94, FV95]. These approahes suffer from one of the following two drawbaks. Either the struture of the resulting objet oriented shema still looks rather "relational" or non-realisti assumptions about the existing relational shema were made. Examples for suh non-realisti assumptions are that the relational shema has been developed rigorously using a ertain database design method or the relational shema inludes no optimization strutures. Other examples for non-realisti assumptions an be found in [HEH + 93]. In any ase, the result of suh an antisemanti transformation is a bad objet-oriented database shema. Other approahes like [PB94] overome these shortomings by proposing a more robust interative reengineering 1. In this paper a relational database shema and an objet oriented database shema are onsidered to be equivalent iff they represent exatly the same universe of fats. A formal desription of this notion of shema equivalene is beyond the sope of this paper. 2. Two database extensions are onsidered to be equivalent iff they represent exatly the same fats.
proess using a set of loosly oupled tools like AWK sripts, simple programs and editor maros. However, loosely oupled tools do not offer enough support for data migration after the shema transformation has been finished. We argue that the usually omplex and thus error prone task of data migration should be arried out automatially. Indeed, our approah in ontrast to loosely oupled tools makes this feasible by establishing and maintaining the neessary dependenies between a relational and an objet-oriented shema. The next setion will sketh a simple user senario with our migration environment to illustrate the reasons for and benefits of an interative shema transformation proess. Setion 3 explains how the dependenies between the relational and objet-oriented shema respetively whih define orresponding syntatial onstruts in the two shemes are formally speified, established and maintained during editing of an objet-oriented shema. Our approah even supports to edit an objet-oriented shema in suh a way that established dependenies get lost (for a while) and are re-established later on again (semi-)automatially. Setion 4 gives an overview about the urrent status of the migration environment and skethes some further plans for its utilization. 2 The Migration Environment: An Example Senario Figure 1 shows an example sreen dump of the migration environment. The left window shows an editor for the relational shema supporting SQL (with additonal semanti annotations) while the right window shows an editor for the objet-oriented shema aording to the ODMG-93 standard 3 [Cat93]. In migrating a database system the first step is to analyse the legay relational system. For this purpose, the shema extration and analysis tool offers ommands within the "Extrat" submenu of the SQL-shema window that inspet existing relational database systems and extrat as muh shema information as possible in order to build up an (initial) SQL-shema. The shema extration tool first will query the relational database system for its shema. This will reveal at least the existing tables together with their ibutes. In more sophistiated database management systems we may gain information on primary keys, foreign keys, referential integrity onstraints, and additional dependenies. By inspeting the ode of database system appliations, stored proedures, and event handling proedures and by inspeting the data 3. Due to layout reasons we use a simplified syntax for the definition of the objet-oriented database shema. itself we may get even more information about e.g. the ardinality of relationships and higher level abstration mehanisms like aggregation and inheritane strutures. A detailed disription on how these informations an be exstrated is beyond the sope of this paper and an be found in other ontributions [And94, FV95, PB94, PKBT94, SLGC94]. As stated in the introdution, a fully automati shema extration normally will fail to detat all relevant information and to reover the higher level design onepts of a shema. Thus, the user, e.g. a database system administrator or an appliation programmer, may add his speifi design and appliation knowledge to the relational shema initially onstruted by the shema extration tool. Let us assume that in Figure 1 the automati shema extration tool was not able to identify the p_hair ibute of table Conf_Info_Addr as foreign-key ibute referening the name ibute of table Person and/or the uniqueness of this ibute. The user ould easily add this information within the SQL-shema window. Another example is the "HINT:" omment that table Conf_Info_-Addr is a kind of subrelation of table Conferene whih suggests an aggregation relationship between these two tables. Sine the user is allowed to annotate the SQL shema manually, he/she may erroneously introdue inonsistenies with the given shema of the desribed relational database system. In order to gain maximal onsisteny, the shema extration tool offers additional ommands that are used to ompare the edited shema with the shema of the legay system (f. ommand "Compare with database" in the popup menu in Figure 1) and e.g. to validate the orretness of ardinality onstraints by inspeting the atual data of the legay system (f. ommand "Validate Constraints"). Suh shema enhanements should be performed by a database system administrator or appliation programmer who is familar with the legay relational system in order to exploit their appliation knowledge within this step. In order to failitate this task for these peoples it is important that they an do this work within the SQL notation they use in their every day work. So these people not neessarilary have to beome experts in the ODMG data definition language and objet oriented design onepts first. A further step in shema migration is the transformation of the SQL shema reahed so far into an equivalent ODMG shema. This transformation must exploit all semanti information ontained in the annotated SQL shema and has to employ the additional expressive power of the objet oriented data model as far as possible. Due to the semanti gap between the two data models this shema transformation an not be done fully-automatially but again user interation is neessary in order to yield a high quality resulting ODMG shema. The shema transformation or ping tool of the proposed migration environment is based on an adaptable set of
SQL - Editor X ODMG - Editor X File Edit Extrat Mapping Options File Edit Mapping Redesign Options reate sheme ConfereneOrganisation; reate table Conferene ( onf_id int not null, title varhar(15) not null, start date, end date, primary key ( onf_id )) reate table Conf_Info_Addr ( onf_id int not null, p_hair varhar(15), mail_addr varhar(30), primary key (onf_id), foreign key (onf_id) referenes Conferene(onf_id) on delete asade, unique foreign key (p_hair) referenes Person(name) on delete set null) (* HINT: subrel of Conferene *) reate table Person ( name varhar(15) not null, address varhar (50), title varhar (15), primary key (name) sheme ConfereneOrganisation ( lass Conferene title : string; start : Date; end : Date; p_hair : Ref <Person>; mail_addr : string; lass Person name : string; address : Ref <Address>; lass Address street : string; ity : string; Commands Delete Current Insert New Class Append New Class Compare with database Validate Constraints Map Table to Own Class Merge Into Conferene Aggregation in Conferene Figure 1: User Interfae of the SQL/ODMG Editor/Mapper shema ping rules. Eah ping rule defines how a speifi onstrut or situation in a SQL shema is ped to an equivalent onstrut or situation within the ODMG shema. However, in general there are several alternatives to define the shema ping. For example, within Figure 1 the urrently seleted table Conf_Info_Addr has been ped to a group of ibutes of lass Conferene using the ping rule "Merge into lass of father relation". This was possible sine the additional shema information indiates that for every Conferene tuple/objet there exists exatly one Conf_Info_Addr tuple. Thus, the ibutes of Conf_Info_Addr an be inorporated into lass Conferene without loosing any information. Alternatively, the table Conf_Info_Addr ould have been ped to a omplex (aggregation/tuple) ibute of lass Conferene using the ping rule "Aggregation in lass of father relation". Third, the table Conf_Info_Addr ould have been ped to its own lass Conf_Info_Addr in ombination with a referene Attribute within lass Conferene using the rule "Map Table to Own Class". Within our migration environment first an initial ping from the SQL shema to the ODMG shema is omputed based on (user defined) priorities for alternative ping rules. Sine these general priorities will not fit for all atual situations, the user may inspet the resulting pings and interatively selet more appropriate ping alternatives, f. Figure 1. To provide maximum flexibility the rule set of our migration environment is designed to be easily extended, enhaned or exhanged. This allows to improve the ping tool later on and to deal with SQL shemata belonging to different "design styles/shools". The ping proess desribed so far is based on the information ontained in the SQL shema definition. But, due to the simpliity of the relational data model it ontains no or only little information about the higher level design onepts like aggregation and inheritane strutures. Thus
the ODMG shema derived so far an still be enhaned by employing these higher level onepts. Therefore, the migration environment offers a set of equivalene preserving design transformations within its "Redesign" menu. Examples for suh redesign operations are renaming of any element of the ODMG shema, or the ombination of a group of ibutes of a lass to a new omplex aggregation ibute, or the replaement of a group of ibutes by a referene to a newly introdued lass ontaining these ibutes, or the extration of a group of ommon ibutes from several lasses and their reorganisation as a new ommon super lass. All these design transformations will not violate the dependeny between the SQL shema and the ODMG shema, respetively. In addition the database designer has the possibility to edit (any parts of) the ODMG shema freely. He may add new ibutes and/or lasses and drop existing shema parts. Thereby, the designer is allowed to define parts of (or even the whole) ODMG shema anew aording to different design rationals or to new system requirements. Clearly, during free editing dependenies with the SQL shema is lost. Within the migration environment suh unped shema elements will be marked using a speial olour in both windows, the SQL shema window and the ODMG shema window. Using the ping rules dependeies are reestablished automatially or semi-automatially, i.e. in many ases no user interation is neessary to reestablish the orrespondene between the two shemas, in some ases the environment may need advie to identify orresponding syntatial onstruts, and in some ases the user may have to onfirm expliitly the insertion or deletion of syntatial onstruts in the ODMG-shema. During the enhanement of the ODMG shema we oasionally will fae the situation that the ping engineer or the ODMG shema designer will find parts of the shema where some semanti information is missing in the SQL shema. At this point further investigation within the relational database system may reveal additional informations that now an be added to the SQL shema desription. This additional shema information may enable new ping alternatives (perhaps of higher priority) for this shema parts or may even falsifiate old pings. In this situation again the dependenies of the two shemata are reestablished semi-automatially using the ping tool. It is even possible to start with a part of the shema of the legay relational system and to this part first and to extend this partial shema migration by the remaining parts later on. 3 Implementation Conepts Within our migration environment we employ struture oriented editors for the representation and manipulation of the SQL and the ODMG shema. These struture oriented editors internally store an abstrat syntax tree representation of the edited shemas. Figure 2 shows a simplified utout of the internal data strutures of our migration environment for the example szenario shown in Figure 1. The left side of Figure 2 shows the representation of the SQL shema and the right side shows the representation of the ODMG shema. The root of the SQL shema is represented by a node/an objet of type SQLShema arrying the name "Conf.Org." 4 of the example shema as (one of its) ibute(s). The SQL shema node has three outgoing edges/referenes of type leading to the ontained table definitions. A table definition is represented by a node of type table with outgoing edges leading to the ontained ibute definitions. The editors offer struture oriented editing ommands that diretly manipulate the underlying abstrat syntax tree. 5 Additional semanti information like identifier bindings, type information and results of the shema extration tool is represented by additional ibutes and edges. For example, the edge labeled foreign_key leading from node "onf_id" of table "C.Inf.Adr" 6 to the orresponding node of table "Confer." represents a foreign key ondition. Note also the subrel edge relating table "Confer." and table "C.Inf.Adr", f. hint in Figure 1. The struture oriented editors of our migration environments are easily generated from a speifiation of the syntati struture of the orresponding shema language (f. [Emm95]). Besides supporting struture-oriented editing this graphbased approah has an additional advantage in the ontext of database reengineering. The graph-struture is extended by additional nodes and edges whih establish the dependenies between the relational and the objet oriented shema respetively. The formal definition of these dependenies as well as the preservation of these dependenies during editing the ODMG or the SQL definition is given by a triple graph grammar [Lef94, Lef95, Sh94] whih we explain now. The top of Figure 3 shows as an example the tripple graph grammar rule MapTableToClass. Basially, a tripple graph grammar rule, in the following alled a ping rule, 4. Abbreviated due to layout reasons. Stands for "ConfereneOrganisation". 5. The editors are hybrid struture oriented/textual editors. The user may edit any syntati part of the shema in normal text oriented mode. Then a multiple entry parser analysis the edited text and (re)builds the orresponding abstrat syntax subtree. 6. Abbreviation for "Conf_Info_Addr".
SQL-Shema Mapping-Desription ODMG-Shema SQLShema Conf.Org Mapping Conf.Org ODMG-Sh. Conf.Org table Confer. MapTo- Own lass Conf. onf_id dep title sub_rel table C.Inf.Adr foreign key MergeTo- FatherRel p_hair mail onf_id p_hair mail table Person foreign key MapTo- Own lass Person type name address dep name address MapTo- Aggreg lass Address type Figure 2: Cut-Out of the Internal Representaion of Douments
ping MapTableToClass = 11 : SQLSheme 21 : Mapping 31 : ODMGSheme 20 : MapToOwn 30 : lass ondition 10.Ident = 20.SQLIdent; 20.ODMGIdent = 30.Ident; ping MapMergeToFatherRel = 11 : table 21 : MAP 31 : lass subrel dep 20 : MergeToFatherRel ping MapAggregateInOther = 11 : table 21 : MAP 31 : lass subrel dep 10 : AttrGroup 20 : AggregateInOther 30 : CompAttr Figure 3: Trippel Graph Grammar Rules for tables is a speially notated graph rewriting rule (see [HE95] for an overview on graph grammars). Within a ping rule the solid parts (like the nodes 11, 21, and 31 and the onneting edges) desribe the so alled left hand side. The dashed parts (like node 10, 20, and 30 and the attahed edges) desribe the so alled addition part. A ping rule is exeuted by searhing for an isomorphi image of its left hand side and extending the found image by an isomorphi image of its addition part. The example ping rule MapTableToClass searhes for a node 11 of type SQLShema (the root of the SQL shema) and a node 31 of type ODMG Shema (the root of the ODMG shema) that are onneted to a node 21 of type Mapping (the indiator of a orrespondeny between the two shemata) by two edges. The rule adds a new table 10 to the SQL shema and simultaneously a new lass 30 to the ODMG shema and a ping indiator 20 of type MapToOwn to the urrent data struture. Figure 3 shows two additional rules for SQL tables. Rule MapMergeToFatherRel desribes that a table 10 that is known to be a subrel of another table 11 that already has been ped 7 to lass 31 an be ped to the same lass 31 as its father relation. Rule MapAggregateInOther desribes that in the same situation table 10 also an be
forward rule MapTableToClass = 11 : SQLShema 21 : Mapping 31 : ODMGShema 20 : MapToOwn 30 : lass transfer 20.SQLIdent := 10.Ident; 20.ODMGIdent := 10.Ident; 30.Ident := 10.Ident; relating rule MapTableToClass = 11 : SQLShema 21 : Mapping 31 : ODMGShema 20 : MapToOwn 30 : lass transfer 20.SQLIdent := 10.Ident; 20.ODMGIdent := 30.Ident; bakward rule MapTableToClass = 11 : SQLShema 21 : Mapping 31 : ODMGShema 20 : MapToOwn 30 : lass transfer 20.SQLIdent := 30.Ident; 20.ODMGIdent := 30.Ident; 10.Ident := 30.Ident; Figure 4: Graph Grammar Rules derived from MapTableToClass ped to a omplex ibute (of reord or tuple type) of the lass 31 that orresponds to its father relation/table 11. Additional ping rules are used to define the ping of ibutes and ibute types. Formally, a set of suh ping rules (together with an appropriate start graph) builds a (tripple graph) grammar with the set of all pairs of SQL and ODMG shemata as its language that we onsider to be equivalent or to depend on eah other. 8 7. The ping indiator 21 of super lass MAP an be mathed to ping indiators of any of its sublasses, like MapTableToClass, MapMergeToFatherRel, or MapAggregateInOther in our example. 8. The prove that exatly the set of all equivalent shema pairs is defined by a set of ping rules is still a topi of urrent researh. From the ping engineers point of view, eah ping rule defines for a given element/substruture of a SQL shema one possible translation into an element/a substruture of an ODMG shema that he/she onsiders to be equivalent. The ping tool utilizes this equivalene definition by deriving three different operations/graph rewriting rules from every ping rule, a forward transformation rule, a relating rule and a bakward transformation rule. Figure 4 shows the forward transformation, relating, and bakward transformation rules derived from the ping rule MapTableToClass shown in Figure 3. A forward transformation rule is derived from the orresponding ping rule by hanging the dashed SQL parts
of the ping rule to beome solid parts. For rule MapTableToClass these parts are node 10 and the attahed edge omming from node 11. The resulting forward transformation rule searhes for a table 9 in the SQLShema and reates an appropriate lass within the orresponding ODMG- Shema (and a ping indiator MapToOwn desribing the orrespondeny of the translated elements). The relating rule is derived from the ping rule by hanging the dashed SQL and the dashed ODMG parts to beome solid. The resulting rule is used to reestablish orrespondeny information that was lost due to editing of the ODMG shema or that had beome invalid due to new shema information added to the SQL shema, e.g. by the shema extration tool. The bakward transformation rule is derived by making the ODMG parts solid. Suh rules an be used to translate an objet oriented oneptual database shema into a logial SQL database shema. 4 Current and Future Work A prototype of the migration environment is available and demonstrates the feasibility of the approah. This prototype is now developed further by a one-year projetinluding 15 graduate students and a number of MS-thesises. In ooperation with loal industry and the Paderborn C- lab (former CADLAB) the resulting environment shall beome part of a design environment for federated data base systems. Through its OpenDM-system (Open Data Base Middleware) C-lab provides the possibility to exeute queries to a federated system whose shema is defined as an ODMG shema, in suh a way that the appropriate loal data base(s) of the federation are queried. The neessary information to translate the result of suh a query bak into the ODMG-model, if the loal system is a relational one, is provided by the migration environment as skethed in this paper. Based on our approah to shema migration our urrent researh fouses on the remaining two migration phases: data migration and appliation migration. Referenes [And94] M. Andersson. Extrating an Entity Relationship Shema from a Relational Database through Reverse Engineering. In Pro. of the 13th Int. Conferene of the Entity Relationship Approah, Manhester, pages 403 419. Springer, 1994. [Cat93] R. Cattell, editor. The Objet Database Standard: ODMG-93. Morgan Kaufman, 1993. 9. We employ additional onditions to ensure that the regarded table is not yet transformed. [CEER96] J. Cuny, H. Ehrig, G. Engels, and G. Rozenberg (Eds.). Pro. 5th Int. Workshop on Graph Grammars and Their Appliation to Computer Siene. LNCS 1073. Springer-Verlag, 1996. [DA87] K. H. Davis and A. K. Arora. Converting a Relational Database Model into an Entity-Relationship Model. In Pro. of the 6th Int. Conferene of the Entity Relationship Approah, New York, pages 271 285. North-Holland, November 1987. [Emm95] W. Emmerih. Tool Constrution for Proess-Centered Software Development Environments based on Objet Database Systems. PhD thesis, University of Paderborn, 1995. [FV95] C. Fahrner and G. Vossen. Transforming Relational Database Shemas into Objet-Oriented Shemas aording to ODMG-93. In Pro. of the 4th Int. Conf. of on Dedutive and Objet-Oriented Databases 1995, 1995. [HEH + 93] J-L. Hainaut, V. Englebert, J. Henrard, J-M. Hik, and D. Roland. Requirements for information system reverse engineering support. Tehnial Report RP-95-13, University of Namur, Belgium, 1993. [JK90] P. Johannesson and K. Kalman. A method for translating relational shemas into oneptual shemas. In F. H. Lohovsky, editor, Entity-Relationship Approah to Database Design and Querying. ERI, 1990. [Lef94] Martin Lefering. Development of inremental integration tools using formal speifiations. Tehnial report, RWTH Aahen, 1994. [Lef95] Martin Lefering. Integrationswerkzeuge in einer Softwareentwiklungsumgebung. Informatik. Verlag Shaker, 1995. [LS88] C. Lewerentz and A. Shürr. GRAS, a management system for graph-like douments. In Pro. of the 3 rd Int. Conf. on Data and Knowledge Bases. Morgan Kaufmann, 1988. [Mai89] D. Maier. Making database systems fast enough for CAD appliations. In W. Kim and F. H. Lohovsky, editors, Objet-Oriented Conepts, Databases and Appliations, pages 573 582. Addison-Wesley, 1989. [MM90] V. M. Markowitz and J. A. Makowsky. Identifying extended entity-relationship objet strutures in relational shemas. IEEE Transations on Software Engineering, 16(8):777 790, August 1990. [NA87] S. B. Navathe and A. M. Awong. Abstrating Relational and Hierarhial Data with a Semanti Data Model. In Pro. of the 6th Int. Conferene of the Entity Relationship Approah, New York, pages 305 333. North-Holland, November 1987. [PB94] W. J. Premerlani and M. R. Blaha. An approah for reverse engineering of relational databases. Communiations of the ACM, 37(5):42 49, May 1994. [PKBT94] J-M. Petit, J. Kouloumdjian, J-F. Bouliaut, and F. Toumani. Using queries to improve database reverse engineering. In Pro. of 13th Int. Conferene of ERA, Manhester, pages 369 386. Springer, 1994. [Sh94] Andreas Shürr. Speifiation of graph translators with triple graph grammars. Tehnial report, RWTH Aahen, 1994. [SK90] F. N. Springsteel and C. Kou. Reverse Data Engineering of E-R Designed Relational Shemas. In Pro. of Databases, Parallel Arhitetures and their Appliations, pages 438 440. Springer, Marh 1990. [SLGC94] O. Signore, M. Loffredo, M. Gregori, and M. Cima. Reonstrution of er shema from database appliations: a ognitive approah. In Pro. of 13th Int. Conferene of ERA, Manhester, pages 387 402. Springer, 1994.