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
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.
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:
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.
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.
RDFS and OWL Ontologies¶
OWL represents data structure with classes, object properties and datatype properties. The import model tool has to transform OWL metadata to an Entity-Relationship model, but it does not support all the (very complex) semantics of OWL. The following is an explanation of which concepts of OWL the import model tool is able to transform to Virtual DataPort and how.
OWL classes are transformed into interfaces in Virtual DataPort. Classes can be organized into a hierarchy using the subclass of tag, but in Virtual DataPort this concept of inheritance does not exist, so all subclasses are created separately with their own attributes and associations, adding the attributes and associations of their superclasses to each of the resulting interface views.
Datatype Properties are translated into columns of an interface view, the type of these columns is always translated as text.
Object Properties will define associations between views in Virtual DataPort. Cardinality is restricted by upper and lower bounds. In absence of explicit cardinality boundaries, 1:n cardinality is adopted. If the two sides of the relation express 1:n cardinality, this association would be unsyncable in Virtual DataPort, because Virtual DataPort does not support modeling associations n:m directly (i.e without a relationship view).
In OWL there are Object Properties that have their inverse (that’s its way to define bidirectional relationships). In Virtual DataPort there are only bidirectional associations, so even if there is no inverse defined at the OWL side, Virtual DataPort associations will always be bidirectional. The Classes that take part in an association are extracted from the range and domain tags of an Object Property or from a restriction of a subclass, if the object property does not have range and domain. But the inverse side only can be extracted from the Object Property and not from the restrictions. The application supports the union of entities within an Object Property, if this union is in the restriction, creating an association for every entity of the union in Virtual DataPort.
OWL does not have the concept of primary keys, so in all interfaces an attribute called “self_uri” is created, which is used in the mapping of the associations. In addition, another attribute is created with the name of the Object Property at the other side of the 1:n. This attribute is used at the other side of the association in the condition of the mapping.
At the end of this document, in Tags Supported by the Import Model Tool, the OWL syntax supported by the import model tool is further detailed.
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.
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.
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.
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.