CA2097604A1 - Method and apparatus for engineering for a data model - Google Patents

Abstract

A computer implemented system and apparatus (10) for transforming objects in a first data model (52), source design objects, to objects in a second data model (62), target design objects, and synchronizing the two data models. The result of the transformation is that at least one of the target design objects (62) is associated with a corresponding source design object (52). The system (10) associates a unique identifier with each of the target designing objects (62) and source design objects (52), the unique identifier being associated with each map (M1, M2, M3, M4, M5) associated with each design object (62).

Description

20~7~0 1 METHOD AND APPARATUS FOR ENGINEERING FOR A DATA MODEL

5 BACK~RO~NP

The present in~ention r~lates to a computer system for manipulating data models, more particularly the invention relates to a computer lO system for translating objects in one data model to objects in a second data model.

Information data models are used by inormation management personnel to model business ~~` 15 environments and assure~efficiency of operations.
The computer systems involved in modeling-such environments necessarily involve comples computer-level manipulations, since the environment that is being modeled consists of many complex and 20 interrelated objects. Suth information systems exploit database management technology to promote effici~nt design, enhance file maintenance and ; modification, eliminate data file redundancy, and provide substantial documentation regarding data file 25 structure.

The implementation of an information management system utilizing database management technology involves the concept of dual data 30 representation: i.e., logical representation; and physical representation. Logical representation relat~s to the form in which the data records are presented to and interact with the system user.
Physical representation relates to the form in which 35 individual data rscords are stored and how the . ., : - , , , . - , , : . . .

wos2/oss61 -2- Pcr/us9l/o8974 2 ~ 4 records are manipulate~ by the computer system. The physical representation of the data is generally of little or no concern to the end-user, since the task of manipulatin~ data storage areas is a unction of 5 the system, and as established by systems designers.

Of most concern to the system end-user, however, is the logical representation of the data, since the user's ability to store, retrieve, and 10 modify aggregations of data items, data records, and data rslationships is dependent upon the form in which the data base management system presents data to the user.

Information management systems operate in comple~ environments often consisting of hundreds or thousands of elements, or objects, and relationships, permitting users to manipulate and employ data in many ways. Representation of such elements and 20 relationships to a user presents a set of problems not encountered, and certainly not resolved, by present data base management systems. Instead of being organized into application-oriented files, which are always addressed in the same way, as in 25 database systems, the information may b organized so that it can be addressed in a variety of different ways, and can be used to answer a diversity of queries. Object-oriented systems currently offer the most effective means for handling such information.
Information management systems enable generation and manipulation of data models. In the past few years, different data models have evolved to represent the complex objects and relationships of , ~ . ~, ~. .. .. , ,,: :., : . :

~2/09961 - ~ 0 9 7 fi ~ ~ PCT/US91/08974 objects for a given environment by different representations. In one object-oriented system, the Bachman Analyst~ system, available from the assignee of the current application, Sachman Information 5 Systems, Inc., Burlington, Massachusetts, the objects of a data model are represented by entities and associated attributes. In that system, the : relationships among entities and attributes may be diagramma~ically shown in a type of 10 network-structure, Entity-Relationship (E-R) diagram. This type of data model is referred to as an e2tended entity data model, to describe the representation of objects in the model as entities .. _ . . . . ... . .
and attributes. In another system, DB2~ system 15 available from IBM Corporation, Armonk, New York, the ; objects are represented by tables and associated columns. This type of data model is referred to as a relational data model, reflecting the fact that the objects are defined by their relationship to other ` 20 objects in the model.

In a work environment utilizing an information system having such data models, it is often desirable to enable users to work with either, 25 or both, of two different data models representing the same information. There is a need for a system which enables a user to work an more than one data model environment, or design ~pace, and to translate data models developed in one environment into another 30 environment. The process of translation from one data model to ano~her, is referred to~as ~engineering.~ In the ield, it is known to assign a directionality for translations between two data models, so that translation is said to occur through ,. . . . , . ~ . . .
' . , , . ' . !
''' ' '. ~ ' '. . , , , ' ''' ' ' '' ' ' ' ' ' ', ''': :,., . ' ' '' ~, :', ' ' " ', i WO92/09961 h ~ 97 ~ ~ 4 PCT/US91/08974 _ Uforward~ or ~reverse~ enyineering. In forward engineering, a term primarily used with respe~t to the DBA editor of the Bachman Analyst system, objects are translated $rom an e~tended-entity data model to 5 a relational data model. In a slmilar fashion, reverse engineering refers to translating from a relational data model to an e~tended-entity data model. In such da~a models, the e~tended-entity data model is relatively compact while the r~lational data lO model is not. As a result, a user may define a model in Analyst design space using a highly e~ficient methodology, and then may forward engine~r that model to the DB2 design space where the model may be fully espressed with great-detail. Thus,-the advantage of 15 forward engineering from the Analyst design to the DB2 design spaces is that it enables the representation o~ a relatively large amount of in~ormation by user input of a rela~ively small amount of information. Alternatively, a user could 20 specify a model, or portion of a model, in great - detail in the DB2 design space, and then, through reverse engineering, obtain a compact, efficient representation o~ that model in the Analyst de~ign space.
However, in the prior art, enabling a user to work in two environme~ts, o~ design spaces, introduces potential inconsisten~ies and conflicts between the resulting two data models. For esample, 30 if a user creates a data model using an e~tended entity data model, and wants to view the model in a relational data model construct, forward engineering may be performed on the objects. To be effective, the translation, or engineering time must be ... .. , , : . ;; ...... ; , ~ ,. ,, ,,, ,, " , j , -, .. , . ,,.; , . ~ . , WO 92/Og~61 -5- PCr/US91/U8~7~
20~76~
relatively short, a~d the user must be able to continue working on the e~tended entity model. If the relational model is static during changes made to the extended entity model, the changes reflected in S the e~tended entity model will not be reflected in the relational model. As a result of such situations, there is a need for periodic synchronization between the two data models. This synchronization process has not been effectively 10 accomplished in the prior art, so that users can work independently in the two data spaces.

One way prior art sy~tems have approached translation between data models is by-associating- ~
15 objects across the design spaces by obje,,t name as the object is created. Thus, when an object with an associated name ~CUSTOMERW is created in one environment, the name ~CUSTOMER" is unique to the named object. During the translation of the object 20 to the other énvironment, a new object name ~CUSTOMæR.~EW~ is created which is related to ~CUSTOMER~ via the object name. However, one problem encountered by that prior art system is that if, for e~ample, the user changes the name from ~CUSTO~E~" to 25 ~CUSTOMER2h in the first environment, a different identifier then becomes associated with the newly named object. Thereafter, when the system looks to find the previously translated ~CUSTOMER.NEW" and its related object in the first environment, it 30 determines that the object no longer e~ists.

While on an object-by-object basis this poses a technisal problem that perhaps could be successfully addressed, in a comples multi-object : ;

WO 92/09961 9rl ~ 4 PCI/US91/08974 information system environment the problem is compounded. In such an environment, each object has uniquely associated properties, constraints and rules. Some of the constraints are generated 5 automatically upon creation o~ the named object. ~or e~ample, in a relational model, when a Table is created called ~TABLENAMEU, it may have a constraint ~length = 11 characters~, or a rule that the contents are alphanumeric. During, for example, reverse 10 engineering from a relational model to an e~tended entity model, most of the constraints and properties are carried over to the translated object. Thus, if the object in one environment is renamed such that a - new identifier~is created, the translation and 15 necessary synchronization will be ineffective.

A similar situation arises when an object in either design space is modified. In prior art systems, modification of an object in one design 20 space, whether by name, property or constraint, results in the need for a new translation of that object into the second design space. This effectively precludes a user, or multiple ussrs, from working in two data model design spaces.
In addition, ~he manager of a comple~
multi-object information system implementin~
particular data models must be able to retain some control over the naming of objects in both models.
30 For esample, if one user names certain objects in the e~tended entity model ~CUSTOMER~, and another user names those same objects in the relational model ~NAMES", any subsequent translation between the two models may result in duplicate objects and improper :

.

W~92/09961 2 0 3 7 fi O ~ PCT/US91/08974 trans~orma~ions. Thus, there is also a need for a naming standard which is invoked by the computer system to assure naming control over the two data models.

Accordingly, it is an object of the present invention to provide an improved computer system for translating or transforming objects from one data model to another data model.

It is another object to provide a computer system which synchronizes two data models.

~ It is yet another object of the invention to 15 provide a computer system having a naming standardization system to assure naming control over multiple data model environments, such that named objects in a ~ata ~odel of one enYironment will correspond to named objects in a data model of 20 another environmen~. .

Other objects, features, and advantages of the invention will be apparent from the following figures, description of the preferred embodiments 25 thereof, and from the claims.

, , .. , :. ~, , ; ............. ... . . . ...... . . .. . .. . . . . . . .. . .

W092/09961 -8- PCT/US91/08974 _.

-~ $UMMA~R~ QF T~E INVENTION
.
Briefly, the current invention is a computer implemented system for transforming objects in a 5 first data model to objects in a second data model.
Generally, the first dat~ model consis~s of source design objects (SDO) in a source design space, and the second data model consists of target design objects ~TDO) in a target design spac~. The result 10 of the transformation is that at least one of the TDO's is associated with a corresponding SDO. In accordance wi~h anoth~r aspect of the invention, the sys~em further synchronizes the ~irst and second data ~~-~~~~~~~- ~ ~ models. In addition to SDb's and TDO's, each data 15 model may also be treated as a aesign object, herein referred to as a model object, in accordance with the invention.

The system associates a unique identifier 20 with each of the S~O~s and TDO's. Each object in the two design spaces has an associated map, containing map objects. The map objects generally are parameters for implementing a ~et of rules. At least one of such rules drives the transformation. The 25 system converts an SDO and its associated map into at least one conversion object (CO) and associated conversion map, in accordance with SDO transformation rules. The system then merges the CO, together with its associa~ed map into at least one corresponding 30 TDO, creating a merged object and associated merged map. The end result is a target design space, including merged objects or target objects, each object havîng an associated unique identi~ier which , :: . , , , ~, . . ~. . ..

2~97~01 is related to the unique identiier of the originating source design object.

In the preferred embodiment of the 5 invention, the irst data model is an extended entity data model, and the second data model is a relational data model (with the transformation being referred to below as "forward engineering~). Alternatively, the system may transform objects from a relational data 10 model to an e~tended entity data model treferred to below for the preferred embodiment as ~reverse engineering").

In one form of the invention, each objec~ in .. . ... ..
15 the two design spaces may have an associated system map and a user map, where the system map (containing the unique identifier for the object) is immutable by a user, and the user map is selectively modifiable by a user.
Alternati~ely, in another embodiment of the invention, there may be a composite map related to each pair of associated objects in the two design spacss. Inl this form, a single unique identifier is 25 associated with the composite ma~, and a unique relationship is established betwesn each source design object and its correspondinr target design object.

To achieve synchronization following periods of independent operations on models in each of two desiyn spaces, the objects in the source design space are each transformed to merged objects in accordance with the system of the invention prior to further .. . . , ., . .. .

,: ~.:: .. .. .... ;. :: .:

WO92/09961 ~Q9~ 6~ -lo- PCT/US~ 8974 independent processing. Pre~erably, each source object is identified as a particular classtype in the design space. In one embodiment of the invention, trans~ormation of the SDO ' s into merged obj ects 5 occurs not only over all objects in a design space, but is performed per class, in a preestablished hierarchy of processing order, Thus, all SDO's of one classtype are processed before SDO's of another classtyp~.

During the ~onversion step, the system identifies instances where there are zero, one, or more TDO's in the target design space. For those -~~-~ -~instances where there are no identified TDO's, the 15 system initiates an appropriate action in response to that instance. Appropriate actions include deletiny the source object map, rebuilding a user map, and creating a null map for the source design object in the target design space.
The system further may generate a naming template to enable standardized naming, or name ,. control, in the respective data model environments.
The naming template facilitates naming objects in the 25 source design space so that the resultant names will correspond to names in the target design space and vice versa. The template provides a electively predetermined object identifier and a selectively modifiable object variable. The name of the design 30 object thus consists of a user-selected portion and a predetermined portion, enabling a single user to independently name objects, while reserving to the system manager name control across the data models.

..
,, ,: . . , , , :,:, ~::. :, .: . ,., ,, .;, , ,:~ . i . .
,- . . , : ~ ; .,, . . . : . .
, ,.: : :: , ,.: ... ... .
. . . . . ..

.

WO92/09961 ~ PCT/US91/08974 2097~0~
Once each C0 and related TDO has an associated name, derived from the naming process, the system further effects merging. The action taken by the system during mesging is dependent upon th~
5 condition of the TDO and~or target design space.

To identi~y the condition of the TDO or target design space, the system implements several merging steps. One step may include identifying 1~ instances when both the name and map associated with a CO matches both the name and map of one of the target design objects. In that instance, the system fuses the CO with that TDO, and then overwrites the ~ properties of the CO ~o-~that TDO. ~~-~ :
Another merge step may include identifying instances when the name of a CO matches the name of one of the TDO's, but the conversion map does not match the tar~et desig~ map. In that instance, a 20 signal is generated to ~dvise the user of the conflict, asking the user to initiate an appropriate action. An appropriate action includes appending the conversion map to the tar~et map, renaming the conversion objl_ct, or appending the conversion map to 25 the target object map followed by over-writing the propertie~ of the conversion object to the target design object.

Yet another mer~e step may include 30 identifying instances when the conve2sion map matches the target design map, ~ut the names do not match.
Again, in that instance a signal is generated to advise the user of the conflict, asking the user to initiate an appropriate action. An appropriate ., . ~ , .: ......................... . .
,.. ,. ~ , . . . ~ .. " .; .;
~ ~ , " ,: . :
. ; , .. . .

WO 92tO9961 ~ 12- PCl/US91/089kl action in that instanee includes appending the target map to the SDO associated with the Co, then building the CO into the target design space and over-writing the properties of the CO to the TDO. Alternatively, 5 the action may include removing the target map, then building the ~O into the target design space.
Another appropriate action may include replacing the source design map with the target map, then over-writing properties of the SDO to the TDO.
A fourth merge step may include identi~ying instancPs when there is neither a map match nor a name match between a CO and a TDO. In that instance, ~ the-system may initiate addition of the-CO-to the 15 target design space.

The system of the invention may also implement the comparison of a merged object with a predetermined set of rules, identifying instances 20 when the merged map is inconsistent with one or more of the rules, and generating a signal representative of each instance. In the preferred embodiment, the portion of the system that performs this function is referred to as an ~dvisor. The Advisor signal may 25 include error messayes to the user, or may include gueries or prompts to the user to resolve the conflicts or inconsistencies. Following a user response to the signal, the system then resolves these identified inconsistencies.
Following transformation of the SDO's to merged objects in the target design space, then during a target processing ("verfic3tion~ phase, a conf;rmation is made that the SDO's referenced in the . , , . .. , ;

:. ~ , .................. , ..... , -, ' ':, :: : , ' :' ' ,, ' ~, .

WO92/09961 _~3_ PCT/US91/08974 2~76~

maps of the merged objects in the target design space (i.e., the modified TDO's) are in fact referenced ~o valid and corresponding SDO's. When this target processing phrase is complete, then the two data 5 models are said to be ~ynchronized. After that point, the user may again independently a~cess and modify the models of either or both design spaces.

The TDO's of the system may further ;nclude 10 referenees to zero, one, or more SDO's. The target maps may also contain such reerences. The system may implement the step of id0ntifying instances when the TDO reference is to zero of the SDO's, generally .
defined as a null referen~e. For each of these 15 instances, the system selectively modi~ies the TDO, for e~ample by removing the TDO from the target design space, defined as delete propagatP.

The system may further implement the 20 identif i~ation of instances when the target map re~erence is to zero of the SDO' s. For each of these instan~es, the system may selectively modify the TDO
and its associated map iln accordan~e with a pre~etermined action. This action may implement the 25 substeps of delete propagate, nulli~y target, or delete map. The nullify target substep removes the target map reference from the tar~et map, whereas the delete map step deletes the target map containing ~he ref erence .
In the system of the invention, each of the TDO's are selectively modifiable by a user. Thus, the system of the invention further may maintain the uniqus target identifier (in the system map) . . .. .... . ..
,, ,. ~, ..
. . . .. . . ... .... . . .
:, , " ,. " . : ,:
~,:, ,: .
' : , , ,. . , ',"., -, ......... ~ .

, . , ~ . , WO92/09961 -14- PCT/US91/0897q 9~
associated with a target map for each modified TDO.
By so doing, new identifiers are not created each time a TDO is modified.

: . , . . ~, . ........ - . :', : :, , : ~:. ,:: ~ .:... .. .

WO92/09961 -15- PCT/US~ 8974 209760~
~RIEF DES~RIPTION ~F THE pRAWINGS

FIGURE lA shows in block diagram form a system embodying the invention.

FIGURE lB shows in functional modl~le block diagram form the system of FIGURE lA.

FIGURE lC shows B graphic representation of 10 the design spac~s of the system of FIGURE lA.

FIGURE lD illustrates the operation of the system of FIGURE lA.

FIGURE 2 is a structure chart of an embodiment of the ~ystem of the invention.

FIGURES 3A and 3B show alt~rnative map configurations for objects in the design spaces of 20 the system of FIGURE lA.

FIGURE 4 shows a block diagram o a system map and a user map of the cur~ent invention.

FIGURE 5A shows a Table Form displaying maps to the Entity "LOCATION" in an e~emplary D82 data model named ~O~EONEn.

FIGURE 5B shows a blank Table Form in an 30 e~emplary Analyst data model.

FIGURE 6 shows an e~tended entity diagram, and a relational diagram of the invention, showing a one-to-many relationship.

W092/09~6} ~ -16- PCT/US~ 8~74 FIGURE 7 shows an extended entity diagram, and a relational diagram, showing a one-to-one relationship.

FIGURE 8 shows an e~tended entity diagram, and a relational diagram, showing a many-to-many relationship with two Foreign Keys.

Like reference characters in the respective drawn f igures indicate corresponding parts.

; "

WO92/09961 -17- PCT ~
2097~iO~
DESCRIPTION OF THE PREFERRED EMBODIMENT
.

A system 10 embodying the invention is shown in general form in FIGURE lA. The system 10 includes 5 a Central Processing Unit (CPU) 26 and at least one memory device 24. The CPU is accessed by an end-user via a display device 12 and a data entry device 22.
System 10 is in communication with mainframe computer 26.
1~ ~
In the preferred embodiment of the invention disclosed herein, a system 10 operates using a programmed I~M-compatible 80386 personal computer, having an OS~2 operating sys~em. Other computer 15 hardware and operating systems, su~h as UNIX or DOS, may be used, with some modifica~ions to the software. Although the preferred embodiment uses C
as its programming language, other programming languages may be used to implement the current 20 invention. The software product known as D82, available from IBM Corporation, Armonk, New York, resides on mainframe computer 26.

Bachman Analyst~ (release 3.10) software 25 product resides in system 10, together with a patch (as set forth in obj~ct code in Appendix A) and Bachman D~A for DB2 (DBA/DB2~ software product (as set forth in object code in Appendix B).

The system 10 assists data analysts and systems analysts in designing models for a work environment, enabling dynamic interaction between the system user and the data models. The data bases ,; :. .

' W092/09961 ~ G~ -18- PCT/US91/08974 based on such models may be established and maintained in the mainframe computer 26.

The system lO is illustrated in functional 5 module block diagram form in FIGURE lB. As shown in FIGU~E lB, the system lO includes a machine (or processor)/operating system 18 coupled to a display device 12 and a data entry device 22. The Bachman Analyst system overlays the machine/operating system 10 18 and includes a Data Manipulation Language (DML~
workstation manager 20, an Analyst Meta system 24 and associated Analyst Designer (14A), Analyst Editor (14B), and ~nalyst Forms ~l4C) modul s. In - accordance with the cu-rrent invention, the sy9tem lO
15 includes the DBA/DB2 system, which includes a DBA/DB2 Meta system 22 and DBA/DB2 Editor (l4H), DBA/DB2 Desiqner (l~ G ), and DBA/DB2 Fo rms ~ 14 F ) . 'The DBA~DB2 : system further includes Reverse Engineering/Advisor (14E), Forward En~ineerin~/Advisor (14D), and 20 Capture/Generate (14I) modules, and Desk Top module 28. Analyst and DBA/DB2 design spaces are identified ; in EIGURE lB by reference numerals 50 and 60, ; respectively, whereas the design models are identified by reference numerals 52 and 62, 25 xespectively.
.
The Bachman Analyst system includes Analyst Forms 14C, Analyst Editor 14B, and Analyst Designer 14A functional modules, Analyst Meta 24, DML 20, 30 Analyst Design 52, as well as Analyst Designer 14A, Analyst Editor 14B, and A~alyst Forms 14C.

As illustrated in FIGURE lB, the interaction ~etween user and machine 18 occurs via a visual ;, , , :- , . .
,. , ,, ., ., , ., .:. . , -, ., , . :: , . ~ :, , ,:, ...

- .. . , . . -.
: , : , , , "
- . , -, . - . . . . . . . . .

WO92/09~61 -19- PCT/US91/08~74 display device 12, such as a computer monitor, operating in concert with a data entry device 22, such as a keyboard. Communications between system 10 and mainframe computer 26 are established via SQL
5 file 16.

The data models ~reated in the system 10 are generated into SQL file 16 and sent, via a communications link to a capture file 44, for e~ample 10 SPUFI~ systPm available from International Business Machines, Inc.~ Armonk, New York, which file is located in the mainf rame 26 . SPUFI ~ystem then enables the model to be in communication with a DB2 `~~~ `` catalog of the DB2 product 46. In this manner,~`~~~~
15 models created in the modeling environment of the system 10 may be used in the database residing in conjunction with the mainframe computer 26.

Data definition information from the DB2 20 database 46 may be transferred to SQL 16 via an interface 48. In the preferred embodiment, the interface 48 is Bachman Catalog Estract for DB2, available from Bachman Information Systems, In~., Burlington, MA. The information is captured by the 25 system 10 from the in~erfa~e 48 Yia the Capture/Generate module 14I.

The workstation mana~er ~0, includes a Data Manipulation Language (DML) and not only serves as an 30 inter~ace between the machine 18 and the meta systems 22, 24, but also pro~ides the environment for the creation and manipulation of data m9dels in the two design spaces 50 and 60. As illustrated, th~se design spaces may b~ used to establish, for ~ample, , ,~ -, - , ,; i ..

WO92/09961 ~ 20~ pcr/us91/o8974 an Analyst design 52 and a Ds2 design 62. The meta systems 22, 24 are the object services component of the system 10, and interface with th~ functional modules 14A-14H of the two data models. The meta 5 systems 22, 24 contain object definitions for the respective models.

The two distinct logical design spaces established by system lO are represented, along a 10 time (t) axis, in FIGURE lC, including a first design space 50 for a first data model 52, and a second design space 60 for a second data model 62. In the preferred embodiment, by way of example, the first - design space 50 is established~by the~8achman 15 Analyst, and the second design space 60 is established by the Bachman DBA for DB2~ software product.

Upon the establishment by a user of a data 20 model in one design space, it may be desired to establish a data model in the other design space which corresponds to the same information. Also, after the establishment ofitwo data models in separate design spaces corresponding to the same 25 information, a user interaction with one or both of the data models virtually always modifies the respective models so that they no lonyer correspond to a common information set. In both of these circumstances, it is desirable to transform, or 30 translate, a resultant model in its space to the other model in the other space.

The process of translating or transforming one data model in one design space to another data . . .

",. .
.- . . ~ , .

WO92/09961 ~21- PCT/US91/08974 2~9760~
model in another design space is referred to as ~engineering~. Engineering may be driven in either direction, i.e., from one design model to another.
Once a hierarchy is assigned to each of the 5 respective design spaces, the directionality of engineering may be specified as being either ~forward~ or ~reverse~. That is, in a system, if an e~tended entity model desi~n space is assigned priority over a relational model design space, 10 "forward~ will be defined as a processing direction from the e2te~ded entity model to the relational model. In that system, processing direction from the relational model to the estended entity model is ~~defined as ~reverse~. The preferred embodiment 15 described herein has that e~emplary hierarchy, although other hierarchies could be used in other embodiments.

An important aspect o the invention is to 20 achieve synchronization of two designs in their respective design spaces (that is, to establish that both models correspond fully to the same information set). Either model may be ~synchronized~ to the other. The current invention achieves 25 synchronization, in part, by performing a target processing, or verificatio~ phase. Thus, for purposes of the following description of the invention, the phrase ~forward engineering" is used to include both forward transformation and 30 verification phases, to achieYe synchronization.
Similarly, the phrase ~reverse en~ineering~ includes both reverse transformation and verification phases to achieve synchronization. As mentioned above, the direction ., , , . .: , .

'~ . . ~: ' ' .

W092/~996l 9~o~ 2- PCI/U591/~8!)74 o~ engineering i~ driven by the priority assigned to each design space.

For e~ample, referring to the Analyst/DB2 5 models of ~he preferred embodiment, during forward engineering, thus defined, the DB2 model 62 is synchronized to match the Analyst msdel 52, including - forward transformation and verification. Conversely, during reverse engineering, the Analyst model 52 is 10 synchronized to mat~h the D~2 model 62, including reverse transformation and verification. Each phase of the engineering, i.e., forward/reverse transformation and verification, are discussed in urther detail below.
The overall op~ration of system 10, including user modification and synchronization of the data models, is illustrated in FIGURE lD. In that figure, the Analyst desiqn space 50 is shown 20 separated from the DB2 design space 60 by a double broken line. The design spaces S0 and 60 are shown along a time (t~ a~is. During time periods denoted Tl in FIGURE lD, the data models 52 and 62 in the respective design spaces may be modified by user 25 interaction, as indicated by arrows 52' and 62', respectively. Following the end of the Tl periods, the respective models are synchronized during the periods denoted T2. During the T2 periods, the users may not modify the respective models. In the 30 illustraked embodiment for DBZ-to-Anal~st synchronization (forward engineerin~), there is a forward transformation followed by verification denoted by arrows 100 and 102, respectively. At the end of the Tz periods, the models 52 and 62 are .

- , , ,; - , , :.

.: : :: :.. , :", :,.j, :.. , : , 2 09 7 GO~

synchronized (denoted by arrows S), and Tl periods commence during which users may again intPract with the respective data models until the next T2 period begins .

EN~INEERI~Ç

In general, it is a design goal of the eurrent invention to generate, modify, and maintain 10 parallel data models in each of the two design spa~es, for example, an Analyst design in the first design space and a DB2 design in the second design space, where th~ two designs correspond to the same data, or information in a synchronized manner. To 15 maintain flexibility for the user, the system of the invention permits modifications of the two designs by allowing a user to independ ntly modify one or both of the designs during predetermined time intervals, and then ollowing each such interval, æynchronize 20 the resultant divergent designs, so that they again ~orrespond to the same data.

As described above, FIGUR lD illustrates engineering o~ the data models in design spaces 50 25 and 60 on a time axis t. The time a~is indicates first time periods Tl, followed by second time periods, T2. During ~1 periods, a user may independently generate or modify obje~ts in one or ` both of data models 52 and 62 in the respective 30 design spaces 50 and 60, resulting in divergence in the two data models. Duri~g T2 periods, the system synchronizes those model~ by means of transformation 100 and verification 102 So that the two models 52, ; 62 are synchronized at times S.

~ " . , . ,;, . ,: ,. ..
,. ,, , . , . ................ . , :, ~ .

;. : .: : , .~ - : :

W092/09961 ~24- Pcrluss1/os~

In general, the design spac~s are either source design space or target design space. A source design space is that space containing the model 5 objects to be transformed into another (i.e. the ~target~) design space. A target design space ~ontains objects which have been transformed rom a source design space. The designation of source or target design space is a result of assigning a 10 priority or hierarchy to each space. In the illustrated esample of FIGURE lD, th~ source d~sign space is designated as 50, having data model 52, which is forward transformed 100 to target design space 60, having data model 62. Once the 15 transformation 100 is complete, the obje~ts in the target space are verified 102, and the design spaces ~cleaned up~ to remove residual or unrelated objects or artifacts. In the preferred embodiment, design space 50 includes an Analyst data model, which is 20 assigned a hierarchy over the DB2 data model in design space 60.

The current invention establishes a synchronization operation using a synchronization 25 subsystem 30 whvse operation is depicted in the ; preferred form in FIG~RE 2. In the descriptio~ of the operation of subsystem 30 below, for a T2 synchronization interval in FIGUR lD, it is initially assumed that only the source data model has 30 changed since the last synchroniza~ion interval, although the invention is also similarly operative for the situation when both data models have changed or only the target data model has changed.
;

.. .. , , , ~ .. - .. ,, , .. - ... . .
. . ~, j, .
"
: ,; ~

W092/09961 -25- PCT/US91tO8974 20~76~ ~
In general, on an object-by-object basis, each object in the source design space is first forward transform2d to the target design space.
Then, during a verification, or target processing 5 phase, the objects in the target design space are checked against the objects in the Source design space for consistency. FIGURE 2 shows a st~ucture chart representing the operation of the synchronization subsystem 30. The subsystem 30 10 opera~es in a series of phases or steps which enable tran~lation of data objects ~rom one data model to another data model. Generally, and as shown in FIGURE 2, the process for subsystem 30 includes a Source Process Phase 32 and a Target Process 15 (V~rification) Phase 42. The Source Process Phase includes an order processing step 34, a precondition step 36, a Conversion step 38, and a mer~e step 40, and a Target Process Phase ~2. Each of these phases and steps are discussed separately below.
In the preferred embodiment, nforward engineering" effects the forward transformation and verification of an Analyst design to a DB2 design.
Maps, described in detail below, contain parameters 25 used by rules to drive the transformation. All Analyst and DB2 desiyn objects are related across designs by such maps. However, engineerin~ may be used to transform a DB2 desi~n to an Analyst designO
Rules reside in the engineering process and are 30 well-known to those skilled in the art. In addition, the enginePring transformation rules of the current invention are available in the Bachman Analyst release version 3.10.

,, . . .. . ;~ .
; , , ` ' ',. ., ' I

:; : . . . ~ . ; .
. .
. . , ,' ' , ~, W092tO9961 PCT/US91/D8974 ~9~ 26-As described above, the directionality of engineering is driven by the hierarchy or priority assigned to each design space. The design that is being procesxed is called the source design, and 5 includes source design objects ~SDO's). In the ~nalyst estended entity data model, these objects include Entities and Attributes. The design in the second design space which results from forward engineering is the target design. The target design 10 contains transformed source design objects, which are referred to as target design objects (TDO~s). In ~he relational data model of the DB2 design space, these objects include Tables and Columns.

In the preferred embodiment, the Analyst data model includes partnership constructs, as described generally in U.S. Patent ~o. 4,631,.664 (8achman), and U.S. Patent Application Serial No.
516,248 (BI~-117). These partnerships are 20 representative of objects in ~he source design space, and are represented by Foreign Keys in the relational data model. In general, partnership translations are performed after other objects are translated.
.
Engineering may effect translation of source design objects to target design objects on a one-to-one, cne-to-many, or many-to-many basis. This is true ~or both the simple relationships and the partnerships. Further, engineering may be performed 30 on a subset (or n~lassr) of objects in a design space. The objects contained in the subset to be engineered and thus synchronized may either be determined by the user, or predetermined by the system.

.. . . . .
' ` -~' ", ,' ' ~', ' ", , ' ' ' '' ' ; . . , . :

'., ' :' ' ; '.

: / ~

wos2/oss6l pcT/uss1/o8974 -~7-2Q9760~

MAPS AND IDENTIFIERS

An important aspect of the current invenkion 5 is the inclusiQn of maps in association with objects in the source and target design spaces. Maps serve three functions: 1) to enable the user to drive engineering, either forward or reverse; 2) to enable the user to view the relationships between design 10 objects in the different design spaces; and 3) to synchronize the two data models. All design objects in the two data models are related across the designs ~` by maps. The maps include-system maps and user maps-and are associated with SDO's as source maps, and 15 TDO's as target maps. The respective maps generally include data pointing to related objects in the respective design spaces, but may be empty maps ~having no such data) or may be null maps (which point to only one object).
FIGURES 3A and 3B illustrate alternative map configurations for SDO's and TDO's in the design spaces 50 and 60 (during Tl periods in which the respective models 52 and 62 are divergent), showing 25 the maps associates with those objects.
Corresponding SDO's and TDO's and their associated : maps (M) are denoted with common subscripts. Each M
map includes a system map (S ~AP) and a user map (U
-MAP)o In FIGURE 3A, SDOl and SD02 each have 30 corresponding objects (TD01 and TD02, respectively) in the target space, while SD03 has no such corresponding object, and TD04 has no corresponding object in the source design space. The maps ~1 and M2 each include a unique identifier ~I~) in its S MAP

, .. ,. . .... ,~, ...... .

W092/09961 PCT/~S91/08~74 99~ 2B-and include pointers to each other ~PTR~ and to their respective associated objects (PTR'~. The map M3 includes a unigue identifier (ID) and only a pointer (PTR') to SDO3 and no PTR, since that map is an empty 5 map. Similarly, the map M4 includes a unique identifier ~ID) and only a pointer PTR' to TD04 and no PTR, since ~hat map too is an empty map. Map M5 includes unique identifier (ID), pointer (PTR') to its object and also pointer (PTR) to an object in the lO other design space that does not e~ist. Map M5 is a null map.
... . . ...
FIGURE 3B shows a map configuration for the same objects as FIGURE 3A, but where instead of l~ separate maps in the respe~tive design space, the related objects have a common composite map which spans the two design spaces, and each system map contains a souce pointer (S PTR) and a target pointer (T PTR) which correspond to the PTR's of FIGURE 3A~
20 The system lO may establish the maps in any convenient memory location.

In system lO, the respective maps are generally implemented in the form of objects in the 25 respective design ~paces. System maps are mapping specifications generated by engineeriny. As shown in FIGURE 4 for design space 52 in the partnership set notation, an e~emplary system map 200 is implemented ; by these objects: ~ameTable 202; System Junction 204;
30 and, Esternal Desi~n Table 206. These objects are related by specified relationships to each other as well as to a design object 300. The system maps cannot be directly edited by the user, thus they are effectively immutable. However, they may be : ... . .
' . '' . !, ' .
, ., ,, , ,.: :, :, ., .. ', :
: ~,: . , , -. ' : ; , ,:, , '':

:' .: ,' wos2/oss6l PCr/US91/0897~
209~60i-1 indirectly edited through the use of user maps, As shown, a design object 300 may have many associated user maps 400 and/or many system maps 200. These objects contain parameters which are used by system 5 rules to drive the transformation process. In the preferred embodiment, NameTable object 202 contains at least parameters of object name and object type, and E~ternal Design Table object 206 contains at least parameters of design name and design type. The 10 System Junction object 204 serve~ as a junction point for the two other objects, to link all the informa~ion contained in the three objects (i.e., in~luding other i~formation contained in the System -^
Junction object 204).
r For design space 60, the objects for thP
system maps are implemented as other objects in DB2 (i.e., as-tables and columns~.

In the preferred embodiment, the NameTable 202 includes ~he name of the Entity to which it maps, ' and a system-~enerated idenkifier, or Surrogate Key.
It is important to note that a model object does not include a ~ameTable in its map, but has only a System 25 Junction and External Design Table, with the design name residing in the E~ternal Design Table.

It is the Surroqate Key, and not the object name, which is a unique identifier (ID) that relates 30 objects across desi~ns, i.e. from one design space to another. For e~ample, in the preferred embodiment, the NameTable for an Analyst design contains related D32 design object names. The names in NameTable are updated when engineerin~ occurs. However, Surrogate ; , : . .
.. , ~- ..
.. , . ~ .-,. .; : . . :, , :

: .. , , ., , . :
.: .,.. - ' , . : . , :

W092/~9961 PCT/US91/~8974 ~9q~ 30_ ^

Keys are generated by the system of the inventlon and are not chang~able by either the user or, once generated, by the system.

The System Mapping Table (SMT) 204 contains a Surrogate Key associated with the overall design, i.e., the data model object, as compared with the Surrogate Key associated with the desi~n object. For e~ample, in the preferred embodiment, the SMT for an lO Analyst design has references to related DB2 design objects, and a DB2 design has references to related Analyst design objects.

By maintaining the two tables and associated 15 Surrogate Keys, each design obj8ct, as well as each design space, has an associated Surrogate Key. The E~ternal Design Table (EDT) 206 contains inormation regarding the design type for each design, i.e., whether ~he design is an e~tended entity design, a 20 relational design, or some other appropriate design type. In total, a System Map consists of at least one object name, object type, object Surrogate Key, design name, design type, and design Surrogate Key.
However, for model objects, the System Map does not 25 contain an object name or object type.

Using the Sys~em maps described above, a user mapping a Column to the Attribute of an En~ity will result in a Surrogate ~ey being associated to 30 both the Attribute and the Entit~.

User maps are specification entered by a user to effect engineering. User maps reflect the uæer's wishes, but they may not be reality, since ,:: :. : ~: . . . :,:- . ,.

.,. , , , . ! :
i ' ' ' " ' , ' ' ' . . .

WO92/09961 PCT/US~1/08974 ~09760 1 information contained in System m~ps may override the information en~ered into User maps. User maps relate design objects using user-viewable names. User maps have a life cycle starting at the time the user 5 enters them into the system and ending when they are transformed in sngineering, at which point their in~ormation is incorporated into system maps, as appropriate.

As shown in FIGURE 5A, a User map may be specified by a user using a form 500 in a DB2 data model, and, as shown in FIGURE 5B, by a form 502 in an analyst data model. However, unlike System maps, User maps do not contain Surrogate Keys. Thus, a 15 user may not affect the unique identifier associated with each object or design, enabling the system to maintain control over the design spaees.

FORWA~iREVERSE TRANSFORMATIQN
Reerring ~ow to FIGURE 2, during the SOURCE
PROCESS phase 32, system lO retrieves and processes any source design objects (SDO's) related to the target design. An SDO is related to a target design 25 if it does not have a Null map referrinq to the target design. The SOU~CE PROCESS phase is broken down into a number of phases, each phase performing specific fun~tions. These phases include "ORDER
PROCESSING" 34, ~PRE-CONDITIONU 36, ~CONYERSION" 38, 30 and ~MERGE~ 40.

ORDER PROCESSING 34 iterates ovPr the SDO's in a predetermined manner, based on a designated classtype of each SDO. The object is then passed to ,, ., . ,. : , , r WO92/09961 ~ PCT/US~1/08~7~ .
~9~ 32-PRE-CO~DITION 36 for further processing in accordance with its thre~ functions. The first function is veriication that a TDO, related to an SDO by a System Map, e~ists in the target design. If this 5 state is not ~TRUE~, ~he user is informed of the conflict through an appropriate Advisor. Once the user receives an Advisor, an action may be selected from a predetermined list of actions. In the preferred embodiment, these actions include: DELETE
10 MAP, EXPLICITLY REBUILD MAP, IMPLICITLY REBUILD MAP, or NULLIFY. The following Table I outlines the factors that determine the possible actions and the default action (in bold) for a given e~ample of the preferred embodiment:
TABLE I
SDO refers to SDO does not TDO re~er to TDO
_ __ ______________ ; TDO Delete ~ap; ~ull;fy;
deleted or Esplicitly E~plicitly Rebuild remoYed Rebuild Map; . Map;
Implicitly I~plicitly Rebuild Rebuild Map; Map;
. Advisor Advisor __ ______________ DELETE MAP action deletes the System Map in 30 question from the source design space. EXPLICI~LY
REBUILD MAP action makes engineering use ~he System Map specification to rebuild a User Map. The effect of this is the generation of or connecting to the object specified by the System Map. IMPLICITLY
35 REBUILD ~AP action causes creation of a User Map, an~
the ~eneration of or connecting to the object specified by the Empty Map Rule. NU~LIFY action entirely removes the reference to the target design - - - ,. : ,.:;: . ...... .. .
; , , ,, . , .. . .. , . , .:.-. . ... . .
... .: - , :.,, , , , , :

. - . . ..

: . ~ . . . . . . . . . .

WO 92/099~1 PCl/US~1/0897~
2 ~ 6 ~ ~

by creating a Null map ~or the SDo. The effect of this action is that the SDO will ~ot be related to the target design. For all of these actions, no .. A~
changes are made to any non-map properties of the SDO.
The second function of PRE-CONDITION
assurance that the System and User maps of the design object do not conflict. If there is a conflict with he maps, the user will be asked to select frorn 10 predetermined actions. In the preferred embodiment, these actions include REMOVE SYSTEM MAPS, and REMOVE
USER MAPS. The following Table II outlines the factors and actions available, with default actions ; in bold print, for an example of the preferred 15 embodiment:

TABLE II
NULL NOT NULL DON'T EXIST
-- -------- --_________~________________________ ~ULL No Conflict Remove System ~uild System Map(s3 Map for NULL
, Remove User : ~5 Map(s) . Advisor ______________________________________________________ NOT Remove 30 NULL Syste~ Map No Conflict No Conflict RemoYe User : Map(s) Ad~isor -______ The third function of PRE-CONDITION
synchronization o4 the NameTable wi~h respect to any referenced name for a TDO in the System map.

- . . ..... . .
, - ~ ', , ;; ' , , : : :, ' .

. . .

~ 34-CONVERSION 38 transforms an SDO in~o a conversion objec~ (CO) as if there were no other objects in the target design space. For e~ample, in the current embodiment converting from Analyst design 5 space to DB2 design space, an Entity iS converted to a Table. CONVERSION also i~terprets and acts upon either System maps or User maps that may e~ist for an SDO. These maps are guaranteed to be valid because of prior actions during PRE-CONDITIO~. A conversion lO object is a TDO that also has the name, and Surrogate Key of the related SDO. For e~ample, i~ the preferred embodiment! the CO is a DB2 object, which has the name of the related Analyst object.

MERGE 40 integrates newly created CO's, located in the target design space, into the target design. There are four different ins~ances which determine how a CO is merged with the rest of the target design. The first instance is when the CO has 20 a corresponding object of the same class level and name in the target design space. In the preferred embodiment, this is referred to as NAMEMATCH. The class of an object includes, for e~ample, whether the object is a Table, Column, Entity, or Attribute.
The second instance occurs when there is NAMEMATCH, and the TDO has a map which matches thç
map corresponding to the conversion object. In the preferred embodiment, this instance is referred to as 30 MAPMATCH. The third instance is when there is no NAMEMATCH, yet there is MAPMATCH between the CO and any object in the target design of the same class as the conversion object. In this instance, the system checks for an SDO having a corresponding system map , : ., " ~ ,. , . ", .: , , , . ,, -, : .. ,. , , , WO9~/09961 PCT/US91/08974 ~0~6(~

which refers to this identified object. In the fourth instance, there is naither NAMEMATCH nor MAP~ATC~.

In response to the first instance, i.e., NAMEMATCH, the appropriate a~tion is to FU~E the two design objects. Fusin~ forces the properties of the SDO to over-write properties of the target design obje~t. The us~r ma~ intervene in the fusion action, -. 10 in whiCh case the system will perform the ~ user-prompted action.
.. ... . . . . .. . . . ..
In response to the second in5tance, i.e., ~AMEMAT H and M~PMATCH, the user is required to 15 resolve the con1ict between the target and source by selectinq a sub-actio~. In the preferr~d embodiment, this main action is MERGE/CONFLIC~ TARGET, having the three sub-actions: APPEND; BUILD; or, APPEND/BUILD.
If the user selects APPEND, the map a~sociated with 20 the CO is appended to the map associated with the TDO
and the objects are fused. If the user selects BUILD, the user is reqested to uniquely rename the CO, which is then added to the target design. If the user selects APPE~D/BUILD, the map associated with 25 the CO is appended to the map associated with the TDO
and the objects are fused. Th~ user is then asked to uniquely rename the CO and it is added to the target aesign. If the TDO in question maps to a non-e2isti~g SjO, the APPEND action is the default 30 action. The default action is determined by looking at the ~pecification used for the creation of the CO
and how the TDO maps to the other source design object. For example, if the CO creation is specified by an Empty map, the TDO maps to an SDO by the BUILD

". .. ~ . , .. . , .......... : . . :,.,.. ~,, . . .: . .. . , :
: i : ..: :: :::. ;' : -... . .
: .. . .

WO 92/09961 PCI'/US91/08!~74 ~,~9~ 6 --3 6-- . r action~ If the CO creation is specified by either aSystem map or a User map, the TDO maps to an SDO by an APPEND action.

The action elicited by the third instance, i.e., MAPMATC~ but no NAMEMATCH, is MERGE/CONFLICT
SOURCE. This action forces the user to resolve a conflict between the source desi~n and a set of targets by selecting an appropriate sub-action. In 10 the preferred embodime~t there are three such sub-actions: APPEND SOURCE; REMOVE REFERENCE; or, _ REPLACE SOURCE. If the user selects APPEND SOURCE, the map in guestion is appended to the SDO, the CO is built into ~he target design, and the object referred 15 to by the APPEND map is fused. If the user sele~ts REMOVE REFERENCE, the map associated with the TDO is removed and the CO is built into the target design.
If the user selects REPLACE, the map in question is replaced on the SDO and the TDO referred to by the 20 APPEND map is fused. The CO is not built into the target design. The default action is determined by looking at the specification used for the creation of the CO, and at how the TDO maps to the SDO. For example, when the CO creation is specified by Empty 25 map, the TDO maps to an SDO by REPLACE ~OURCE. If the CO creation is specified by either a System map or a U~er map, the TDO maps ~o an SDO by APPEND
SOURCE.

In the fourth instance, i.e., neither a NAMEMATCH nor a MAPMATCH, the appropriate action is to build a CO into the target design space without any user interaction. The following Table III
outlines the possible ins~ances and the appropriate 35 ac~ions available for each instance:

:, 20~76a~

TABLE III
NAMEMATCH NAMEMATCH MAPMATCH NO MAP-MAPMATCH NO MAP- NO NAME- MATCH
MATCH MATCH ~O NAME-MATCH
____________ __ ___________________ __________________ FUSE MERGE/ ~ERGE/ BUILD
OBJECT CONFLICT CO~FLICT :
TARGET; SOURCE;
ADVISO~ ADVISOR
15 --- ----~-_________ _ ____________. ._ ________. .~_______ - No~e in the--above Table III, that in the ~~~ ~~;
first ~wo instances, a CO is compared against a TDO.
Thus, the FUSE, and MERGE/CO~FLICT T~RGET actions are 20 directed to affecting the target design object. In t~.e second two instanees, the CO is compared against the target design space. Thus, the MERGE/CO~FLICT
SOURCE, and BUILD affe~t the tarqet design space, not just a specific identiied TDO within that space.
25 FollowIng implementation of these processing steps, a TDO e~ists in the target design space.

~ In the preferred embodiment, all Analyst Entities are translated into DB2 Tables during 30 forward engineering. Each such Table has a name, an identifier of the cr2ator or author ("AuthidU), and design statistics. The name of the resulting Table is derived from thP name o the source Entity, in accordance with the naming standards discussed 35 below. The Authid for the new Table is determined by the default Authid specified in the design profile of the target DB2 desi~n. Yolume information of the WO g2/09961 PC'rlU~g1/0897~ , i 9~6~ ~3~-source Entity is translated as design statistics for the Table.
:; :
In the preferred embodiment, all Analyst S Attributes are translated into DB2 Columns during engineering. Generally, the Table in which a Column resides is determined by the System maps of the ;~
Entity associated with that source Attribute. Fo~
example, if the Entity ~CUST~ is translated into the 10 Table "CUSTLIST~, then all of the Attributes ~or the Entity ~CUSTY are translated into Columns in the Table ~CUSTLIST~. Attributes do not have data types . .
of their own, generally only Attribute names and Nulls are translated to Columns. If the Table in 15 which a Column is to be contained does not exist in the target designt the user is noti~ieid ~ia an Advisor, and an appropriate aetion may follow. The resulting Table in which the new Column eventually resides is also determined by the map specified for 20 the Attribute.

When an Attribute is engineered into a Column, all of the data type information for that Column is derived from the domain for that 25 Attribute. The following is a table o~ e~emplary forward transformations of domain data types in the preferred embodiment:

-- . . . - ... ., ;. ;.;. , ; .. ;; :.. ~. . . .
i . ,. "",., "" ;,,,;: ,,~, , , :~", ~ ~, , .-, ,, , ,, , " " ", ", "", ~: , : ,, ~,~, ; ',.; ' :: ~ : " ,i~ ":,.,.,, " . ,,, ,.., :;",, " ;"" .

, ,,, . ~: , : :: , , : ,, ;. , . . . :

20~76~i~

TAB~E IV
Data Type of 5 Domain Translates Into _______~______________________________________________ Alphanumeric and alphabetic, CHARACTER
when e~pected l~ngth (mas. length) l0 = ma~. length Alphanumeric and alphabetic, VARCHAR
when expected length not equal (ma~. length) to ma~. length and expected l5 or max. length =c254 Alphanumeric and alphabetic, LONG VARCHAR
when eæpected length not equal~
to mas. length and e~pected or 20 max. length > 2S4 Integer INTEGER
~eal ~fi~ed-precision) DECI~AL
(precision, scale) Real (variablP-precision) ~EAL
Boolean CHARACTER
Date dimension DATE
Time dimension TIME
35 None UNK~OWN
__________________________________ ___________________ A System map for an Attribute maintains a 40 record of what domain helps in the generation of an . associated Column. The System map associated with that Column also maintains a r~cord of this informatio~. There are special rules for data type reconciliation. The default action is to overwrite 45 all values in the target Column with values derived from the source Attribute. When the Advisor ', ,:, !

-.:: : '',; :' , '' , , ',', '. '; ':' '' ,; , '' ' " , ':

9~
: interaction level is set at ma~imum, the useriis prompted via a specific Advisor, e.g., Changing Value Advisor, to confirm any value that may be overwritten.
When the user engineers both into and from the same target design, the system reconciles the data type of the SDO with that of its corresponding object in the target design. E2ce~t ~or some 10 predetermined instan~es, the system always overwrikes the target data type with the default for that data type.

For e~ample, and as shown in Table IV above, 15 Attributes of type Variable-precision Real~ i.e., values e~pressed in scientific notation~ are by default forward engineered into Columns of type REAL. If the data type of that Column is mod fied from REAL to FLOAT or DOUBLE PRECISION and th~n 20 reverse engineered, the system translates the data type back into REAL. In the preerred embodiment, Attributes of data type ALPHABETIC or ALP~ANUMERIC
are by default engineered into columns of type CHAR, YARCHA~, or ~ONG ~ARCHAR, depending on the length of 25 the Column and whether the expected length is equal to or not equal to the ma~imum length. If the data type of that Column is then modified from CHAR to YARCHAR or LONG VARC~AR, or vice versa and then engineered, the system translates the data type back 30 into ALPHA8ETIC or A~PHAN~MERIC, depending on what it originally was in the information model. For each of these Attributes, the ne~t time the user engineers, the system retains the user's previous choi~e for that Column.

- . . : , . :.: ....

:, .. , . , : : :, .
.,: . : ,:,: : ; : :
:: . .. ,: . . .

W092/09961 PCT/US91tO8974 20~7g~'~

Like partnerships, discussed above, partnership sets (PSETS) may be processed as objects, and are essentially the relationships between 5 Entities. The partnership and the two PSETS
associated with it constitute the processing unit.
All pairs of PSETS are either translated into a Foreign Key, two Foreign Keys, or a Reference Table and two Foreign Keys and a Primary Key. The 10 translation depends on the type o partnership, i.e., one-to-one, one-to-many, many-to-many. A one-to-one partnership is only translated into Foreign Keys on - the-corresponding Tables of the--owni~g-Entities of the PSETS. When a PSET iS mandatory, it must have a 15 Fore~gn gey on the corresponding Table of the owning Entity of the Mandatory PSET. A one-to-many relationship is only translated into a Foreign Key owned by the corresponding Table of the owning Entity : of the PSE~ on the one side. A manyrto-many 20 relationship is only translated into a Reference Table.

The Columns that constitute Foreign Keys are derived from the Primary Key of an Entity hat is the 25 PARENT.of the relationship e~pressed b~ the two PSETS. To determine which Entity is the PARENT
Entity, engineering determines what kind of : relationship is being translated into a Foreign Key a~d how that relationship is representèd by a Foreign 30 Xey. When a one-to-many relatio~ship is specified by two PSETS, the PAREN~ Entity is the Entity that resides on the ~one~ ~ide of the relationship, .

., .. ., ,, :~
:. ,: : .. ,.. : . 1. . I :
. : ~ . : . : : : ., , . ~ .: : , WO92/09961 PCT/U~91/0897~
9~ ~42-FIGURE 6 illustrates this process in a split screen ~ormat, with the left side 50 of FIGURE 6 representing the e~tended entity model (Analyst) and the right side 60 representing the rPlational model 5 ~DB2). The PARENT Entity 152 shown in FIGURE 6 in the e~tended entity model is "CLASS~. The CHILD
entity 154 is "STUDE~Tn. Those entities 152 and 154 are shown in the relational model as Table ~CLASS"
162 and Table "STUDENT~ 164 When a one-to-one relationship con~ains only one Mandatory PSET, the PARENT Entity is the owning Entity of-the~~other PSET. In FIGURE 7, the PARENT ~:
Entity 152 is "CUSTOMER" and the CHILD entity 154 is 15 "LOCATION~. Those entities are represented in the relational model by corresponding tables 162 and 164.

As shown in FIGURE 8, in the ~ase where both the PSETS are mandat.ory or optional, the one-to-one 20 relationship is represented by two Foreign Xeys where each Table owns one of Foreign Reys 166 and 168 and the PARENT Entity 152 is on the opposite end.

In a one-to many relationship, if the PSET
25 that is on the ~many" side of the relationship is mandatory, the resulting Foreign Key has a Primary Key Delete Rule of nRESTRICT~ as a default setting.
I~ the same PSET is optional, then the Primary Key Delete Rule is ~SET NULL~. The Foreign Xey Unique 30 ~alue ~or ~he new Foreign Key is ~NO~. On a one-to-one relationship, if the PSET corresponding to Foreign Key is optional, the Foreign Key Unique value is also ~NOn, and the irimary Xey Delete Rule is also set to SET NULL~. In a many-to-many relationship, , , , ;, ' . : :. ~ : : , ',',, ~ . . :,, ' , .'.

: :~ . ~ :: . . .:

WO 92tO996I PCr/lJS91/1)8974 --~3--20 9~ 6~;~
~wo Foreign Keys have a Primary Xey Delete Rule o~
"RESTRICTn. The design statistics information for the resulting Reference Table is derived by multiplying the volume information from one of the 5 Entiti~s and the PSET it owns. The result of the multiplication i~ the value for the ~Initial Number of Rows".

NAME ~ENERATION AND ~O~TROL
To provide more control over naming newly created objects, setting default names, and ~ontroiling name translations during engineering, a naming standard is included in the system of the 15 invention. Sub-proeesses of the naming standards allow users to specify a naming standard to be enforced in one or both design spaces. By using a naming standard, or tem~late, objects created in one design spa~e are re~dily tra~eable in another design 20 sp~ce. In the preferred embodiment, it also specifies how Analyst design object names are translated into DB2 names. Thisiis achieved through two sub-pro~ess: Object Name Specification; and Engineering Translation.
An Object Name Specification ~ONS) allows a user to spec;fy how the name of an object is constructed in the source design space. This sub-process handles all the information necessary to 30 derive default names for newly ~reated obje~ts, provide naming templates for forms input, detect namin~ standards violations, and assist users transform names of objects so that they conform to naming standards. An ONS is used to establish a : :.. ' ~ ' '';,, '". ', :
.: ., ~ - , . - :
:: : : " , .

WO92t09961 PCr/US91/08974 ~ 4~_ unique component of the name of an object. For e~ample, an ONS may use the eighteen character portion o~ a Table name as the unique component, - independent of which user created and~or subsequently 5 changed that Table. In this manner, the ONS
maintains a unique component of an object name through all modifications to that object. This unique component is unique for naming purposes, and is not necessarily involved in establishing the l0 unique identifier for that object, as discussed above.

In the preferred embodiment, objects are grouped in classes,~~where the ONS's are related for each object of a class. Each ONS includes three 15 components: a Sequence Base Number (SBN); a Sequence Increment Value (SIY); and a sroup of Position Control Specifications (PCS'~). The SB~ of an O~S
enumerates ~he class of all newly created objects.
For e~amplei in the preferred embodiment, every class 20 of DB2 objects has an SBN associated with only that class. Within a class, the SI~ determines a unique offset (or increment) associated with the SBN for that object. The magnitude of increment used when a new object is created within a class is specified by 25 the SIV of the ONS. Tha incremental S8N for an object is its ~Sequence Number. n The Sequence Number for an object has a value corresponding to the Sequence Number for the ne~t previously created object of that class, as modified b~ the SIV. For 30 e~ample, in the preferred embodiment, if the SIV is 1 for the class of objects ~tablespacesn, then every new Tablespace object created will have a Seguence Number that is l higher than the incremental SBN ~or the next previously created Tablespace object.

, . , . . , . . . : : , .:

. - , ,:J : :,:: , , - ,, ,,:
, . , ,.,:: ~, :, :, . .

WO 92/09961 PCl~/US91/08974 2~7~

The PCS determines the type of value that can be entered in a ~iven position of the name of an object, as well as any default values and how those 5 default values are derived. The group of PCS's that are included in the name of an object determines how the name looks to the user, and how naming standards will be enforced. For example, a Table would have eighteen PCS's, one for each character of a Table 10 name, and these PCS's as a group provide the template for a Table naming standard.

~ PCS consists of three attributes: .
Control Identifier ~CI); Value; and Derived Object lS Position. Only the CI is required for all PCS
definitions. The CI determi~es the type of values that may be used in any given position of a name of an object. It also defines how a default value will be derived. In the preferred embodiment, valid CI
20 values include: Constant Value (C); Numeric Value (N); Alphabetic Value (A); Alphanumeric Value (AN);
Seguencing Position (SEQ~; and Object Derived (OD).

A Constant Value must always be supplied 25 in the position specified. When a position CI is a ; Constant Value, a value must also be supplied as part of the PCS This valu~ may be any valid character for the specified position, e.g~, a numeric value could not be specified for position 1.
When the Numeric Value CI is used, only numeric values may be used i~ this position. When the Alphabetic Value CI is used, only alphabetic characters may be suppliéd as values in this . :. .. , . ,: " ,,; , ;: , . :: , . ~
: , . .
: . . : :, . . . .
. ,-- : . :: :, , . : ., : .:

WO 92/09961 PCr/US91/08974 ~ ~9~1&~ -46-position. When the AlphanumeriC Value CI is used, only alphanumeric characters may be supplied as values in this position. No value need be specified for a position with either an N, A, or AN PCS.
When the Sequence Position CI is used, the position will be used to assign default sequence numbers to newly created objects. For e~ample, if position 8 of Tablespace ONS had a PCS of SE~, every 10 new Tablespace created will increment a sequence number and the number would be placed in position 8 of the Tablespace name. If only position 8 were used ~ as the SEQ pos~tion of the Tablespace name, then the number of new Tablespace objects that could be 15 created with unique sequence numbers would be ten.
This may not be a desirable condition for all objects, and so in the preferred embodiment, every object class that allows Segue~ce Positions in the ONS allows at least two consecutive positions. For 20 ~ample, if position 7 and 8 of the Tablespace name specification had SEQ defined as the control speci~icati~on then the number of new Tablespaces that could be created with unique SEQ numbers would be one hundred. In other embodiments, a different number of 25 Sequence Positions may be used in a similar manner.

Finally, an Object Derived CI allows portions of the name to be derived from other objects in the design where the objects have a hierarchical 30 ranking. A user may want to derive portions of a table name from the Table's Tablespace, or a Tablespace name for a Database name. Objects can only have their names derived from objects o~ a superior rank. Whenever an OD CI is ~sed, a PCS

WO92/09961 PCr/US91/08l)74 -~7-2Q~76,~i~
value must be supplied. For esample, if a Tabl0space has an OD CI for position 5, then the only valid value that may be supplied for the PCS value is DB.
A Derived O~ject Position must also be specified when 5 an OD CI is used. The Derived Object Position indicates which position in the superior object's name is used. For e~ample, in the above e~ample, if the CI is OD, and the PCS value is DB, then the Derived O~ject Position could be a value from 1 to 8, 10 indi~ating that any of the eight characters used in the Database name may be used in that position.

In the preferred embodiment, when an object name is derived from anokher object, and ~he 15 name of that object has fewer characters than specified by the ONS, then by default the ~EQ
position is shifted to the left until the gap between the end of an allowable name length and the actual name length is closed.
The other major component of the naming standard sub-process is Engineering Translation. The basic function of this sub-process is to allow a user to control the names generated during forward~reverse 25 engineering. Names specified by maps are always respected during an engineering process, i.e., no naming standard specification takes precedence over the map name specification.

The Engineering Translation sub-process includes two components, Engineering Name Specification (ENS) and Token Substitution (TS), which drive the suh-prccess. The E~S is essentially the same as the ONS, escept it will only support - , . .... . . . . ... .

, : ,: , ~ , , : : , . :
:. " , . . ': ' ~ ~ . . . ; , . , ,,, .. . ~ ,, , - ~ :. . . . . ... .

wo92~o9s61 PCT/US91/08974 ~ -48-9~6~

Table, Column(s), and Foreign xey(s). In the preferred embodiment, Primary Key naming is not an issue, since all Primary Key objects are assigned a predetermined name: PRIMARY. ENS's are essentially 5 special case ;nstances of ONS's and are processed using substantially the same sub-process. Every ENS
consists of a group of PCS's, as in the ONS, but does not have a separate Sequence Base Number or Sequence Incremen~ Value.
When the name of an object must be reduced to fit into a specified number o characters, the ~~~~~~ ~ Token Substitution (TS) sub-process generates meaningful abbreviations. Token Substitution 15 translates ausiness ~erms to abbreviations during forward engineering, and abbrevia~ions to Business Terms during reverse en~ineering. In operation, the name of an object is first ~token-ized" to determine substitutions which must occur. A name that is being 20 reduced is the sour~e name string. A source name strinq is reduced to one or more tokens before substitution. For example, the source name str~ng ~Account-author~ results in two to~ens, ~Account" and ~Author~. These two tokens are substituted with the 25 abbreviations ~ACCT~ and "AUTH~. The result of this substitution is the shorter name string, ~ACCT
AUT~n. In the preferred embodiment, the charact~r ~-~ is replaced by the character ~_ n ~ since DB2 does not allow the use of a ~-~ character.
When Token Substitution is complete, and the reduced string is still too long to fit into the specified number of characters, vowels are stripped from the reduced string starting from the right.

.. , . ~ : - . . -,:
.: ~ , : :,, : . . ..
,, ~ , . - ,, ~ .
:, , : " ,.: . : ,, .. -, ,; , ; ., . , .. : : , . :
: ' : . - , ,,: , . .:, W092tO9961 PCT/US91/08974 ~49-2~7~0'1 However, a vowel at the beginning of a token is not stripped. Thus, if the reduced string had to be 8 characters long, in the e~ample above, the resulting string would be ~ACCT_AUTH~. When all vowel 5 stripping and truncation does not yield a unique name string duriny engineering, then a SEQ number is used in the last position of the object name. In the preferred embodiment, the last position of Column and Table names are used to make a string unique if 10 reduction of a string does not work. The system makes the sequence number as large as it has to be to makP the name unique even if it violates the def ined . . . ~ . . .
specification.

Default object names are generally derived from Object Name Specifications in all cases. Some classes of objects have more than one ONS. For e~ample, Tablespace has two ONS's, as does Foreign Key, since it is desirable to deriYe a default 20 Tablespace ~ame from the Table name when the name is known.

V~I~ICATION

Following the transformation phase of engineering, the nest phase of the system involves verifica~ion that the tWQ data models map to each othe~. In FIGURE 2, this is referred to as TARGET
PROCESSING 42. This phase is responsible for looking 30 at objects contained in the target design space having System maps which refer to objects in the source design space. The phase also verifies that the two designs, or data models, are still in sync before completing engineering. TARGET PROCESSING 42 :: , . , , .. . :

W092/099~1 ~ PCT/USg1/08974 ~ 50-is also responsible for placing a ~ULL map on any object not touched by engineering to this point in the system. This phase is activated after SOURCE
PROCESSING 32 is completed.

TARGET PROCESSING 42 or verification includes identification of instances when the target design space is inconSistent with the source design space. It identi~i~s insta~ces when a r~lated SDO
10 has been deleted or removed from the source design space, and when a related SDO has a new Null map associated with a target design space. In each instance, the user is notified by an appropriate Advisor.
In the preferred embodiment, there are three possible actions by TARGET PROCESSING 42, responsive to the condition of the design spaces.
One a~tion is "nullify target~, which removes the TDO
20 reference to the source design. Another action is "delete propa~ate~, which removes the object in question from the target design space. The third action is ~elete map~, which deletes the map associated with the TDO-in question. The following 25 Table V illustrates e3emplary actions in the preferred embodiment of the system, in relation to the design space conditions ~defaul actions in bold typ~):

.
, ; ~
; . . ,.. . " "
-. .. . .

, , . . . . ,; . . . .. . ...

~97C~
TABLE v TDO Maps Refer to TDO Maps Do Not Other Objects in RefPr to Other Source Design Obj ects in Source - Design __ _________________ ________________________________ ~ource Rullify 10 Obje~t Delete Map Delete Propagate Deleted Advisor ______________________________________________________ Source ~ullify Objec~ Delete Map Delete Map 15 Nulled Delete Propagate . Advisor _______________ ______________________________________ The specification, or outcome, of the ~0 system described above, may be conYerted into code a~d implemented to produce a working application sy~tem. That conversion may be accomplished manually, or under the co~trol of a programmed diqital computer.
- The invention may be embodied in other specific forms without departing from the spirit or essential characteristics thereof. The current embodiments are therefore to be considered in all 3d respects as illustrative and not restrictive, the scope of the in~ention being indicated by the appended claims rather than by the $oregoing de~cription, and all changes which come within the meaning and range of equivalenc~ of the claims are 35 therefore intended to be embraced therein.

What is claimed is:

. . , ~ . -,. . ........... . . . ... .

.. . :. . ,, ;; :.

Claims (98)

1. A digital computer implemented method for transforming objects in a first data model, said first data model having source design objects in a source design space, to objects in a second data model, said second data model having target design objects in a target design space, at least one of said target design objects being associated with a corresponding one of said source design objects, and for synchronizing said first data model and said second data model, comprising the steps of:

A. associating a unique source identifier with each of said source design objects;

B. associating at least one selectively modifiable source map with at least one of said source design objects, each of said source maps having source map objects and being associated with said unique source identifier for said ones of said source design objects, at least one of said source map objects being representative of source parameters for use in implementing a predetermined set of rules in a source design space, said rules including source design object transformation rules;

C. associating a unique target identifier with each of said target design objects;

D. associating at least one selectively modifiable target map with at least one of said target design objects, each of said target maps having target map objects and being associated with said unique target identifier for said ones of said target design objects, at least one of said target map objects being representative of target parameters for use in implementing said predetermined set of rules in a target design space;

E. converting at least one of said source design objects into at least one conversion object in said target design space in accordance with said source design object transformation rules, said conversion objects each having an associated conversion map; and F. merging at least one of said conversion objects and said associated conversion maps into at least one of said corresponding target design objects and said associated target maps to establish a merged object and associated merged map, whereby said ones of said target design objects have their associated unique target identifier related to said unique source identifier associated with said ones of said source design objects.

2. The method according to claim 1 wherein said first data model is an extended entity data model, and said second data model is a relational model.

3. The method according to claim 2 wherein steps (A) through (F) are sequentially performed for each source design object in said source design space.

4. The method according to claim 3 wherein said source design space includes at least one classtype of source design objects, and wherein steps (A) through (F) are further sequentially performed for each source design object of a similar classtype.

5. The method according to claim 4 wherein each of said classtypes includes an associated hierarchy value, and wherein said steps (A) through (F) are further sequentially performed in accordance with said hierarchy values.

6. The method according to claim 2 wherein step (B) includes associating at least one system map and at least one user map with ones of said source design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

7. The method according to claim 6 wherein step (D) includes associating at least one system map and at least one user map with ones of said target design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

8. The method according to claim 7 further comprising the step, prior to said converting step (E) for a source design object, of:

identifying zero, one, or more target design objects in said target design space, as being said corresponding target design object associated with said source design object, said association being represented by map objects in said system maps.

9. The method according to claim 8 wherein said identifying step further comprises the substeps of:

A. identifying instances when zero target design objects are identified; and B. initiating an action in response to said identified instance, said action including one from the set consisting of delete source object map, rebuild a user map, and create a null map for said source design object in said target design space.

10. The method according to claim 8 wherein steps (A) through (F) are sequentially performed for each of said source design objects in said source design space.

11. The method according to claim 2 wherein step (D) includes associating at least one system map and at least one user map with ones of said target design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

12. The method according to claim 2 further comprising the step of generating a template for naming each object in said source design space and said target design space, said template including a selectively predetermined object identifier, and a selectively modifiable object variable.

13. The method according to claim 2 wherein each of said conversion objects includes an associated name, and each of said target design objects includes an associated name, and wherein said merging step (F) further comprises the substeps of:

A. identifying instances when said conversion object name matches one of said target design objects name and said conversion map associated with said conversion object matches said target map associated with said one identified target design object; and B. fusing said conversion object with said one identified target design object, including the further substep of over-writing properties of said conversion object to said one identified target design object for ones of said identified instances.

14. The method according to claim 2 wherein each of said conversion objects includes an associated name, and each of said target design objects includes an associated name, and wherein said merging step (F) further comprises the steps of:

A. identifying instances when said name associated with one of said conversion objects matches said name of one of said target design objects, and said conversion map associated with said one identified conversion object does not match said target map of said one identified target design object;

B. generating a signal representative of each of said instances; and C. initiating an action in response to external input, said external input being responsive to said signal, said action including one from the set consisting of:

i. append said conversion object map to said target map of said one identified target design object;

ii. rename said conversion object;
and, iii. append said conversion object map to said one identified target object map, then over-write properties of said conversion object to said one identified target design object.

15. The method according to claim 2 wherein each of said conversion objects in said target design space includes an associated name, and each of said target design objects in said target design space includes an associated name, and wherein said merging step (F) further comprises the steps of:

A. identifying instances when said conversion map associated with ones of said conversion objects matches said target map associated with one of said target design objects, and said name associated with said one identified conversion object does not match said name associated with said one identified target design object;

B. generating a signal representative of each of said instances; and C. initiating an action in response to external input, said external input being responsive to said signal, said action including one from the set consisting of:

i. append said target map to said source design object associated with said one identified conversion object, build said one identified conversion object into said target design space, then over-write properties of said conversion object to said one identified target design object;

ii. remove said target map associated with said one identified target design object, and build said one identified conversion object into said target design space; and, iii. replace said source design map with said target map associated with said one identified target design object, then over-write properties of said source design object to said one identified target design object.

16. The method according to claim 12 wherein each of said conversion objects in said target design space includes an associated name, and each of said target design objects in said target design space includes an associated name, and wherein said merging step (F) further comprises the steps of:

A. identifying instances when said conversion map associated with ones of said conversion objects does not match said target map associated with one of said target design objects, and said name associated with said one identified conversion object does not match said name associated with said one identified target design object; and B. initiating addition of said one identified conversion object to said target design space for ones of said identified instances.

17. The method according to claim 2 wherein said merging step (F) further comprises the substeps of:

A. comparing said merged object with said predetermined set of rules;

B. identifying instances when said merged map is inconsistent with ones of said rules; and C. generating a signal representative of each of said instances.

18. The method according to claim 17 further comprising the substep of resolving, following said generated signal, said instances when said merged map is inconsistent with ones of said rules in response to external input.

19. The method according to claim 2 wherein each of said target design objects includes a reference to zero, one, or more of said source design objects, said method further comprising the steps of:

A. for at least one of said target design objects, identifying instances when said reference is to zero of said source design objects, said instances being representative of a null reference; and B. responsive to identification of said null reference, selectively modifying said ones of said target design object in accordance with a predetermined action.

20. The method according to claim 19 wherein said predetermined action is a delete propagate action, including the substep of removing said target design object from said target design space.

21. The method according to claim 2 wherein each of said target maps includes a reference to zero, one, or more of said source design objects, said method further comprising the steps of:

A. for at least one of said target design objects, identifying instances when said reference in its associated target map is to zero of said source design objects, said instances being representative of a null reference; and B. responsive to identification of said null reference, selectively modifying said ones of said target design object and said associated target map in accordance with a predetermined action.

22. The method according to claim 21 wherein said predetermined action is a nullify target action, including the substep of removing said reference from said associated target map.

23. The method according to claim 21 wherein said predetermined action is a delete map action, including the substep of deleting said associated target map.

24. The method according to claim 21 wherein said predetermined action is a delete propagate action, including the substep of removing said target design object from said target design space.

25. The method according to claim 2, wherein each of said target design objects are selectively modifiable by a user, said method further comprising the step of maintaining said unique target identifier associated with said target map for each modified target design object.

26. The method according to claim 1 wherein said first data model is a relational data model, and said second data model is an extended entity data model.

27. The method according to claim 1 wherein said source design map and said target design map define a single composite map in a distinct design space, the method further comprising the steps of:

A. associating a unique composite map identifier with said composite map;

B. establishing a unique relationship between said composite map identifier and said source design object; and C. establishing a unique relationship between said composite map identifier and said target design object.

28. The method according to claim 27 wherein steps (A) through (F) are sequentially performed for each source design object in said source design space.

29. The method according to claim 28 wherein said source design space includes at least one classtype of source design objects, and wherein steps (A) through (F) are further sequentially performed for each source design object of a similar classtype.

30. The method according to claim 29 wherein each of said classtypes includes an associated hierarchy value, and wherein said steps (A) through (F) are further sequentially performed in accordance with said hierarchy values.

31. The method according to claim 27 wherein step (B) includes associating at least one system map and at least one user map with ones of said source design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

32. The method according to claim 31 wherein step (D) includes associating at least one system map and at least one user map with ones of said target design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

33. The method according to claim 32 further comprising the step, prior to said converting step (E) for a source design object, of:

identifying zero, one, or more target design objects in said target design space, as being said corresponding target design object associated with said source design object, said association being represented by map objects in said system maps.

34. The method according to claim 33 wherein said identifying step further comprises the substeps of:

A. identifying instances when zero target design objects are identified; and B. initiating an action in response to said identified instance, said action including one from the set consisting of delete source object map, rebuild a user map, and create a null map for said source design object in said target design space.

35. The method according to claim 33 wherein steps (A) through (F) are sequentially performed for each of said source design objects in said source design space.

36. The method according to claim 27 wherein step (D) includes associating at least one system map and at least one user map with ones of said target design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

37. The method according to claim 27 further comprising the step of generating a template for naming each object in said source design space and said target design space, said template including a selectively predetermined object identifier, and a selectively modifiable object variable.

38. The method according to claim 27 wherein each of said conversion objects includes an associated name, and each of said target design objects includes an associated name, and wherein said merging step (F) further comprises the substeps of:

A. identifying instances when said conversion object name matches one of said target design objects name and said conversion map associated with said conversion object matches said target map associated with said one identified target design object; and B. fusing said conversion object with said one identified target design object, including the further substep of over-writing properties of said conversion object to said one identified target design object for ones of said identified instances.

39. The method according to claim 27 wherein each of said conversion objects includes an associated name, and each of said target design objects includes an associated name, and wherein said merging step (F) further comprises the steps of:

A. identifying instances when said name associated with one of said conversion objects matches said name of one of said target design objects, and said conversion map associated with said one identified conversion object does not match said target map of said one identified target design object;

B. generating a signal representative of each of said instances; and C. initiating an action in response to external input, said external input being responsive to said signal, said action including one from the set consisting of:

i. append said conversion object map to said target map of said one identified target design object;

ii. rename said conversion object;
and, iii. append said conversion object map to said one identified target object map, then over-write properties of said conversion object to said one identified target design object.

40. The method according to claim 27 wherein each of said conversion objects in said target design space includes an associated name, and each of said target design objects in said target design space includes an associated name, and wherein said merging step (F) further comprises the steps of:

A. identifying instances when said conversion map associated with ones of said conversion objects matches said target map associated with one of said target design objects, and said name associated with said one identified conversion object does not match said name associated with said one identified target design object;

B. generating a signal representative of each of said instances; and C. initiating an action in response to external input, said external input being responsive to said signal, said action including one from the set consisting of:

i. append said target map to said source design object associated with said one identified conversion object, build said one identified conversion object into said target design space, then over-write properties of said conversion object to said one identified target design object;

ii. remove said target map associated with said one identified target design object, and build said one identified conversion object into said target design space; and, iii. replace said source design map with said target map associated with said one identified target design object, then over-write properties of said source design object to said one identified target design object.

41. The method according to claim 37 wherein each of said conversion objects in said target design space includes an associated name, and each of said target design objects in said target design space includes an associated name, and wherein said merging step (F) further comprises the steps of:

A. identifying instances when said conversion map associated with ones of said conversion objects does not match said target map associated with one of said target design objects, and said name associated with said one identified conversion object does not match said name associated with said one identified target design object; and B. initiating addition of said one identified conversion object to said target design space for ones of said identified instances.

42. The method according to claim 27 wherein said merging step (F) further comprises the substeps of:

A. comparing said merged object with said predetermined set of rules;

B. identifying instances when said merged map is inconsistent with ones of said rules; and C. generating a signal representative of each of said instances.

43. The method according to claim 42 further comprising the substep of resolving, following said generated signal, said instances when said merged map is inconsistent with ones of said rules in response to external input.

44. The method according to claim 27 wherein each of said target design objects includes a reference to zero, one, or more of said source design objects, said method further comprising the steps of:

A. for at least one of said target design objects, identifying instances when said reference is to zero of said source design objects, said instances being representative of a null reference; and B. responsive to identification of said null reference, selectively modifying said ones of said target design object in accordance with a predetermined action.

45. The method according to claim 44 wherein said predetermined action is a delete propagate action, including the substep of removing said target design object from said target design space.

46. The method according to claim 27 wherein each of said target maps includes a reference to zero, one, or more of said source design objects, said method further comprising the steps of:

A. for at least one of said target design objects, identifying instances when said reference in its associated target map is to zero of said source design objects, said instances being representative of a null reference; and B. responsive to identification of said null reference, selectively modifying said ones of said target design object and said associated target map in accordance with a predetermined action.

47. The method according to claim 46 wherein said predetermined action is a nullify target action, including the substep of removing said reference from said associated target map.

48. The method according to claim 46 wherein said predetermined action is a delete map action, including the substep of deleting said associated target map.

49. The method according to claim 46 wherein said predetermined action is a delete propagate action, including the substep of removing said target design object from said target design space.

50. The method according to claim 27 wherein each of said target design objects are selectively modifiable by a user, said method further comprising the step of maintaining said unique target identifier associated with said target map for each modified target design object.

51. The method according to claim l wherein steps (A) through (F) are sequentially performed for each source design object in said source design space.

52. The method according to claim 51 wherein said source design space includes at least one classtype of source design objects, and wherein steps (A) through (F) are further sequentially performed for each source design object of a similar classtype.

53. The method according to claim 52 wherein each of said classtypes includes an associated hierarchy value, and wherein said steps (A) through (F) are further sequentially performed in accordance with said hierarchy values.

54. The method according to claim 1 wherein step (B) includes associating at least one system map and at least one user map with ones of said source design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

55. The method according to claim 54 wherein step (D) includes associating at least one system map and at least one user map with ones of said target design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

56. The method according to claim 55 further comprising the step, prior to said converting step (E) for a source design object, of:

identifying zero, one, or more target design objects in said target design space, as being said corresponding target design object associated with said source design object, said association being represented by map objects in said system maps.

57. The method according to claim 56 wherein said identifying step further comprises the substeps of:

A. identifying instances when zero target design objects are identified; and B. initiating an action in response to said identified instance, said action including one from the set consisting of delete source object map, rebuild a user map, and create a null map for said source design object in said target design space.

58. The method according to claim 56 wherein steps (A) through (F) are sequentially performed for each of said source design objects in said source design space.

59. The method according to claim 1 wherein step (D) includes associating at least one system map and at least one user map with ones of said target design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

60. The method according to claim 1 further comprising the step of generating a template for naming each object in said source design space and said target design space, said template including a selectively predetermined object identifier, and a selectively modifiable object variable.

61. The method according to claim 1 wherein each of said conversion objects includes an associated name, and each of said target design objects includes an associated name, and wherein said merging step (F) further comprises the substeps of:

A. identifying instances when said conversion object name matches one of said target design objects name and said conversion map associated with said conversion object matches said target map associated with said one identified target design object; and B. fusing said conversion object with said one identified target design object, including the further substep of over-writing properties of said conversion object to said one identified target design object for ones of said identified instances.

62. The method according to claim 1 wherein each of said conversion objects includes an associated name, and each of said target design objects includes an associated name, and wherein said merging step (F) further comprises the steps of:

A. identifying instances when said name associated with one of said conversion objects matches said name of one of said target design objects, and said conversion map associated with said one identified conversion object does not match said target map of said one identified target design object;

B. generating a signal representative of each of said instances; and C. initiating an action in response to external input, said external input being responsive to said signal, said action including one from the set consisting of:
i. append said conversion object map to said target map of said one identified target design object;

ii. rename said conversion object;
and, iii. append said conversion object map to said one identified target object map, then over-write properties of said conversion object to said one identified target design object.

63. The method according to claim 1 wherein each of said conversion objects in said target design space includes an associated name, and each of said target design objects in said target design space includes an associated name, and wherein said merging step (F) further comprises the steps of:

A. identifying instances when said conversion map associated with ones of said conversion objects matches said target map associated with one of said target design objects, and said name associated with said one identified conversion object does not match said name associated with said one identified target design object;

B. generating a signal representative of each of said instances; and C. initiating an action in response to external input, said external input being responsive to said signal, said action including one from the set consisting of:

i. append said target map to said source design object associated with said one identified conversion object, build said one identified conversion object into said target design space, then over-write properties of said conversion object to said one identified target design object;

ii. remove said target map associated with said one identified target design object, and build said one identified conversion object into said target design space; and, iii. replace said source design map with said target map associated with said one identified target design object, then over-write properties of said source design object to said one identified target design object.

64. The method according to claim 60 wherein each of said conversion objects in said target design space includes an associated name, and each of said target design objects in said target design space includes an associated name, and wherein said merging step (F) further comprises the steps of:

A. identifying instances when said conversion map associated with ones of said conversion objects does not match said target map associated with one of said target design objects, and said name associated with said one identified conversion object does not match said name associated with said one identified target design object; and B. initiating addition of said one identified conversion object to said target design space for ones of said identified instances.

65. The method according to claim 1 wherein said merging step (F) further comprises the substeps of:

A. comparing said merged object with said predetermined set of rules;

B. identifying instances when said merged map is inconsistent with ones of said rules; and C. generating a signal representative of each of said instances.

66. The method according to claim 65 further comprising the substep of resolving, following said generated signal, said instances when said merged map is inconsistent with ones of said rules in response to external input.

67. The method according to claim 1 wherein each of said target design objects includes a reference to zero, one, or more of said source design objects, said method further comprising the steps of:

A. for at least one of said target design objects, identifying instances when said reference is to zero of said source design objects, said instances being representative of a null reference; and B. responsive to identification of said null reference, selectively modifying said ones of said target design object in accordance with a predetermined action.

68. The method according to claim 67 wherein said predetermined action is a delete propagate action, including the substep of removing said target design object from said target design space.

69. The method according to claim 1 wherein each of said target maps includes a reference to zero, one, or more of said source design objects, said method further comprising the steps of:

A. for at least one of said target design objects, identifying instances when said reference in its associated target map is to zero of said source design objects, said instances being representative of a null reference; and B. responsive to identification of said null reference, selectively modifying said ones of said target design object and said associated target map an accordance with a predetermined action.

70. The method according to claim 69 wherein said predetermined action is a nullify target action, including the substep of removing said reference from said associated target map.

71. The method according to claim 69 wherein said predetermined action is a delete map action, including the substep of deleting said associated target map.

72. The method according to claim 69 wherein said predetermined action is a delete propagate action, including the substep of removing said target design object from said target design space.

73. The method according to claim 1 wherein each of said target design objects are selectively modifiable by a user, said method further comprising the step of maintaining said unique target identifier associated with said target map for each modified target design object.

74. An apparatus for transforming objects in a first data model, said first data model having source design objects in a source design space, to objects in a second data model, said second data model having target design objects in a target design space, at least one of said target design objects being associated with a corresponding one of said source design objects, and for synchronizing said first data model and said second data model, comprising:

A. means for associating a unique source identifier with each of said source design objects;

B. source map means for associating at least one selectively modifiable source map with at least one of said source design objects, each of said source maps having source map objects and being associated with said unique source identifier for said ones of said source design objects, at least one of said source map objects being representative of source parameters for use in implementing a predetermined set of rules in a source design space, said rules including source design object transformation rules;

C. means for associating a unique target identifier with each of said target design objects;

D. target map means for associating at least one selectively modifiable target map with at least one of said target design objects, each of said target maps having target map objects and being associated with said unique target identifier for said ones of said target design objects, at least one of said target map objects being representative of, target parameters for use in implementing said predetermined set of rules in a target design space;

E. conversion means for converting at least one of said source design objects into at least one conversion object in said target design space in accordance with said source design object transformation rules, said conversion objects each having an associated conversion map; and F. merging means for merging at least one of said conversion objects and said associated conversion maps into at least one of said corresponding target design objects and said associated target maps to establish a merged object and associated merged map, whereby said ones of said target design objects have their associated unique target identifier related to said unique source identifier associated with said ones of said source design objects.

75. Apparatus according to claim 74 wherein said first data model is an extended entity data model, and said second data model is a relational model.

76. Apparatus according to claim 74 further comprising controller means for controlling operations of said means (A) through (F) to be sequentially operative in a predetermined order for each source design object in said source design space.

77. Apparatus according to claim 76 wherein said source design space includes at least one classtype of source design objects, said controller means operating said means (A) through (F) to be sequentially operative in a predetermined order for each source design object of a similar classtype.

78. Apparatus according to claim 77 wherein each of said classtypes includes an associated hierarchy value, and wherein said predetermined order is in accordance with said hierarchy values.

79. Apparatus according to claim 74 wherein said source map means includes means for associating at least one system map and at least one user map with ones of said source design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

80. Apparatus according to claim 79 wherein said target map means includes means for associating at least one system map and at least one user map with ones of said target design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

81. Apparatus according to claim 80 further comprising ID means for identifying zero, one, or more target design objects in said target design space, as being said corresponding target design object associated with said source design object, said association being represented by map objects in said system maps.

82. Apparatus according to claim 81 wherein said ID means further comprises:

A. means for identifying instances when zero target design objects are identified; and B. response means for acting in response to said identified instance, said response means including one from the set consisting of: means for deleting a source object map; means for rebuilding a user map; and, means for creating a null map for said source design object in said target design space.

83. Apparatus according to claim 81 further comprising controller means for controlling said means (A) through (F) to be sequentially operative in a predetermined order for each source design object in said source design space.

84. Apparatus according to claim 74 wherein said target map means includes means for associating at least one system map and at least one user map with ones of said target design objects, said system map being immutable by a user and said user map being selectively modifiable by said user.

85. Apparatus according to claim 74 further comprising naming means for generating a template for naming each object in said source design space and said target design space, said template including a selectively predetermined object identifier, and a selectively modifiable object variable.

86. Apparatus according to claim 74 wherein each of said conversion objects includes an associated name, and each of said target design objects includes an associated name, and wherein said merging means further comprises:

A. means for identifying instances when said conversion object name matches one of said target design objects same and said conversion map associated with said conversion object matches said target map associated with said one identified target design object; and 8. fusing means for fusing said conversion object with said one identified target design object, including means for over-writing properties of said conversion object to said one identified target design object for ones of said identified instances.

87. Apparatus according to claim 74 wherein each of said conversion objects includes an associated name, and each of said target design objects includes an associated name, wherein said merging means further comprises:

A. means for identifying instances when said name associated with one of said conversion objects matches said name of one of said target design objects, and said conversion map associated with said one identified conversion object does not match said target map of said one identified target design object;

B. signal means for generating a signal representative of each of said instances; and C. response means for responding to external input, said external input being responsive to said signal, said response means including one from the set consisting of:

i. means for appending said conversion object map to said target map of said one identified target design object;

ii. means for renaming said conversion object; and, iii. means for appending said conversion object map to said one identified target object map, and means for over-writing properties of said conversion object to said one identified target design object.

88. Apparatus according to claim 74 wherein each of said conversion objects in said target design space includes an associated name, and each of said target design objects in said target design space includes an associated name, wherein said merging means further comprises:

A. means for identifying instances when said conversion map associated with ones of said conversion objects matches said target map associated with one of said target design objects, and said name associated with said one identified conversion object does not match said name associated with said one identified target design object;

B. signal means for generating a signal representative of each of said instances: and C. response means for responding to external input, said external input being responsive to said signal, said response means including one from the set consisting of:

i. means for appending said target map to said source design object associated with said one identified conversion object, means for building said one identified conversion object into said target design space, and means for over-writing properties of said conversion object to said one identified target design object;

ii. means for removing said target map associated with said one identified target design object, and means for building said one identified conversion object into said target design space; and, iii. means for replacing said source design map with said target map associated with said one identified target design object, and means for over-writing properties of said source design object to said one identified target design object.

89. Apparatus according to claim 74 wherein each of said conversion objects in said target design space includes an associated name, and each of said target design objects in said target design space includes an associated name, wherein said merging means further comprises:

A. means for identifying instances when said conversion map associated with ones of said conversion objects does not match said target map associated with one of said target design objects, and said name associated with said one identified conversion object does not match said name associated with said one identified target design object; and B. means for initiating addition of said one identified conversion object to said target design space for ones of said identified instances.

90. Apparatus according to claim 74 wherein said merging means further comprises:

A. means for comparing said merged object with said predetermined set of rules;

B. means for identifying instances when said merged map is inconsistent with ones of said rules; and C. means for generating a signal representative of each of said instances.

91. Apparatus according to claim 90 further comprising means for resolving, following said generated signal, said instances when said merged map is inconsistent with ones of said rules in response to external input.

92. Apparatus according to claim 74 wherein each of said target design objects includes a reference to zero, one, or more of said source design objects, said apparatus further comprising:

A. for at least one of said target design objects, means for identifying instances when said reference is to zero of said source design objects, said instances being representative of a null reference; and B. means, responsive to identification of said null reference, for selectively modifying said ones of said target design object in accordance with a predetermined action.

93. Apparatus according to claim 92 wherein said predetermined action is a delete propagate action, including means for removing said target design object from said target design space.

94. Apparatus according to claim 74 wherein each of said target maps includes a reference to zero, one, or more of said source design objects, said apparatus further comprising:

A. for at least one of said target design objects, means for identifying instances when said reference in its associated target map is to zero of said source design objects, said instances being representative of a null reference; and B. means, responsive to identification of said null reference, for selectively modifying said ones of said target design object and said associated target map in accordance with a predetermined action.

95. Apparatus according to claim 94 wherein said predetermined action is a nullify target action, including means for removing said reference from said associated target map.

96. Apparatus according to claim 94 wherein said predetermined action is a delete map action, including means for deleting said associated target map.

97. Apparatus according to claim 94 wherein said predetermined action is a delete propagate action, including means for removing said target design object from said target design space.

98. Apparatus according to claim 74, wherein each of said target design objects are selectively modifiable by a user, said method further comprising the step of maintaining said unique target identifier associated with said target map for each modified target design object.