Overview¶

With the feature Import Model you can import models created with the following modeling tools, into Virtual DataPort.

• ER/Studio Data Architect

• ERwin Data Modeler

• IBM InfoSphere Data Architect

• SAP PowerDesigner

• Sparx Systems Enterprise Architect

• Models that that follow these Semantic Web Standard: RDF Schema (RDFS) and Web Ontology Language (OWL)

The import model tool transforms these data models into Virtual DataPort models. That is, it extracts the entities, attributes and relationships, and creates the equivalent interface views and associations in Virtual DataPort.

Given the iterative nature of data models, the import model tool can either perform full or incremental synchronizations with Virtual DataPort models.

Data Modeling¶

Modeling tools are used to design physical and logical data models. These models illustrate the specific entities, attributes and relationships involved in a business function.

Modeling tools help to enforce modeling and business data policies: mandatory fields, required formats, etc. When these models are implemented by Data Virtualization (DV) developers, everyone has to follow these policies.

Integration between a Data Virtualization solution, like Virtual DataPort, and modeling tools can go in both directions:

1. From Virtual DataPort to the modeling tool:

   Virtual DataPort exposes metadata through standard interfaces such as JDBC/ODBC that can be used by most modeling tools to import Denodo data models. Metadata exposed by Virtual DataPort includes views and relationships between those views; associations between views appear as primary key - foreign key relationships.

2. From the modeling tool to Virtual DataPort:

   Virtual DataPort allows creating views and associations either graphically or via VQL. The import model tool automates this process creating interface views and associations from the models generated by modeling tools. Referential Constraints will be registered for those associations that meet the conditions to do so in Denodo Virtual DataPort.

Interfaces are a special type of views that consist only of a definition of fields and a reference to another view: the implementation view. You can use them to do top-down design where you first define the fields of the interface and at a later stage, associate it with its implementation view.

When designing data services in Virtual DataPort following a top-down design, being able to define and publish canonical models via interface views, before implementing the access and integration logic to populate them, decouples the work of Data Virtualization developers from that of Client Application developers, who build informational/operational solutions on top of the data services.

Usage¶

To open this tool, click the menu Tools > Import model. Then, the following parameters have to be filled:

• The file that contains the model created with the modeling tool.

• The type of model to import.

• The Virtual DataPort database where the comparison and the creation of the elements is going to be performed.

• The target folder where the elements will be created. This is an optional parameter.

The import model tool currently supports the following file types:

• IDERA ER/Studio Data Architect: .dm1 files with logical or physical models.

• ERwin Data Modeler: .xml files with logical or physical models.

• IBM InfoSphere Data Architect: .ldm files with logical or physical models.

• SAP PowerDesigner: .ldm files with logical or physical models.

• Sparx Systems Enterprise Architect: .xml files.

• RDFS and OWL ontologies: .owl and .rdf / .rdfs.

Once this parameters are filled and the Analyze Model button is pressed, the import model tool parses the entities, attributes and relationships and shows information about them. In any case, there could be repeated names among the entities, this is not allowed in Virtual DataPort, and for this reason the import model tool will rename the entity by adding “_x” to the name where x is a number. The tool now displays:

• The modeling tool used to create the model.

And for each element it shows:

• Status of the element with respect to the Virtual DataPort server: New, Updated or In sync.

• Name of the element.

• Type of the element. There are two possible values: Interface or Association.

• Date of the last modification in Virtual DataPort only if the element already exists in the Virtual DataPort server.

• Button to see the element details.

After pressing the inspect button of a certain element in the table, the tool displays:

• If the element inspected is of type interface, a list of the associations of that interface. If the element is an association, it shows the relationship between the selected element and the other element as well as the multiplicity.

• VQL needed to create the element in Virtual DataPort.

• The changes between the element in the analyzed file and the one in Virtual DataPort, in case the status of the element is Updated. Possible changes are: Added, Updated or Deleted.

Whenever the Refresh button is clicked the import model tool will search for the displayed elements in the Virtual DataPort catalog and it will show the information mentioned above.

Then, it is possible to select the elements as you want using the element check boxes of the table or via the interfaces/association check boxes.

Click Update server to update the selected elements:

• If the element is new, it creates the element.

• If it exists, it modifies the element according to the new definition.

The update process offers us to Create dummy interface implementations. When selected, the import model tool will create a view with a single row of null values that will be used as the implementation for each interface in the model.

The image below shows the result of the update process for the model used in this manual as an example. In the importedModels folder there are three interfaces and two associations, with the corresponding dummy implementation for the interfaces.

Limitations¶

Primary keys

The primary keys of the model are not be reflected because interface views do not have a primary key. At runtime, the primary key of an interface is “inherited” automatically from it implementation view.

Not-null constraints

As with primary keys, interface views do not allow the definition of other types of constraints on columns, such as not-null constraints. So these are ignored when importing the model. database.

No forced synchronization operation

The current version of the tool does not allow forcing the synchronization of elements that the tool already considers in “OK” state.

STRUCT and ARRAY types

The types of BIG SQL, STRUCT and ARRAY, are converted to TEXT when you import the model from IBM InfoSphere Data Architect.

Logical Models with associations many to many

It is not possible to translate an association many to many from a logical model to Virtual DataPort, it does not support this kind of association. For instance a logical model from IBM InfoSphere Data Architect could contain an association many to many and it would not be syncable with Virtual DataPort, and in the status of the interface would appear as unsyncable.

Associations without mappings

If there is an association that does not have a condition mapping, this association is not syncable with a Virtual DataPort server, and the status of the interface would appear as unsyncable.

Synchronization Referential Constraints

The current version cannot detect if in an association of Virtual DataPort the property Referential constraint is checked. So, this property is ignored to obtain the status of the associations with regard to Virtual DataPort.

Data Types in RDFS/OWL

All attribute data types in OWL classes are translated to Virtual DataPort as type text.

Dimensional models in ER/Studio Dimensional models are not supported by the import model tool, only relational ones are supported.

Tags Supported by the Import Model Tool¶

This is a table with the tags supported by the import model tool and their contexts. Every tag has to be within its context to be transformed to Virtual DataPort structures.