JBoss.orgCommunity Documentation

Chapter 1. Introduction

1.1. What is Teiid Designer?
1.2. Why Use Teiid Designer?
1.3. Metadata Overview
1.3.1. What is Metadata
1.3.2. Editing Metadata vs. Editing Data
1.3.3. Metadata Models
1.3.4. Business and Technical Metadata
1.3.5. Design-Time and Runtime Metadata
1.3.6. Source and View Metadata
1.4. It's all in the Modeling...

The Teiid Designer User's Guide provides detailed descriptions of Teiid Designer features and functionality.

Teiid Designer is an Eclipse-based graphical modeling tool for modeling, analyzing, integrating and testing multiple data sources to produce Relational, XML and Web Service Views that expose your business data.

Teiid Designer is a visual tool that enables rapid, model-driven definition, integration and testing of data services without programming. With Teiid Designer , not only do you map from data sources to target formats using a visual tool, but you can also:

This allows you to abstract the structure of the information you expose to and use in your applications from the underlying physical data structures. With Teiid Designer, data services are defined quickly, the resulting artifacts are easy to maintain and reuse, and all the valuable work and related metadata are saved for later reference.

You can use Teiid Designer to integrate multiple sources, and access them using the common data access standards:

Teiid Designer is an integral part of the Teiid Designer enterprise-class system for providing data services for service-oriented architectures.

Metadata is data about data. A piece of metadata, called a meta object in the Teiid Designer, contains information about a specific information structure, irrespective of whatever individual data fields that may comprise that structure.

Let’s use the example of a very basic database, an address book. Within your address book you certainly have a field or column for the ZIP code (or postal code number). Assuming that the address book services addresses within the United States, you can surmise the following about the column or field for the ZIP code:

This definition represents metadata about the ZIP code data in the address book database. It abstracts information from the database itself and becomes useful to describe the content of your enterprise information systems and to determine how a column in one enterprise information source relates to another, and how those two columns could be used together for a new purpose

You can think of this metadata in several contexts:

Metadata can include different types of information about a piece of data.

Note that the terms technical and business metadata, refer to the content of the metadata, namely what type of information is contained in the metadata. Don’t confuse these with the terms “physical” and “view” metadata that indicate what the metadata represents. For more information, (see Section 1.3.6, “Source and View Metadata”).

Teiid Designer software distinguishes between design-time metadata and run-time metadata. This distinction becomes important if you use the Teiid Designer Server. Design-time data is laden with details and representations that help the user understand and efficiently organize metadata. Much of that detail is unnecessary to the underlying system that runs the Virtual Database that you will create. Any information that is not absolutely necessary to running the Virtual Database is stripped out of the run-time metadata to ensure maximum system performance.

In addition to the distinction between business and technical metadata, you should know the difference between Source Metadata and View Metadata.

Source and View metadata refer to what the metadata represents, not its content.

Source Metadata directly represents metadata for an enterprise information system and captures exactly where and how the data is maintained. Source Metadata sounds similar to technical metadata, but Source Metadata can contain both technical and business metadata. When you model Source Metadata, you are modeling the data that your enterprise information systems contain.

View Metadata, on the other hand, represent tailored views that transform the Source Metadata into the terminology and domain of different applications. View Metadata, too, can contain both technical and business metadata. When you model View Metadata, you’re modeling the data as your applications (and your enterprise) ultimately use it.

When you create View Metadata, you are not describing the nature of your physical data storage. Instead, you describe the way your enterprise uses the information in its day-to-day operations.

View Metadata derives its classes and attributes from other metadata. You can derive View Metadata from Source Metadata that describes the ultimate sources for the metadata or even from other View Metadata. However, when you model View Metadata, you create special “views” on your existing enterprise information systems that you can tailor to your business use or application expectations. This View Metadata offers many benefits:

Our example enterprise information sources, the address book database, and the vendor-supplied comma-delimited text file, reside in two different native storage formats and therefore have two Source Metadata models. However, they can represent one business need: a pool of addresses for a mass mailing.

By creating a View Metadata model, we could accurately show that this single View Table, the AddressPool, contains information from the two enterprise information systems. The View Metadata model not only shows from where it gets the information, but also the SQL operations it performs to select its information from its source models.

This View Metadata can not only reflect and describe how your organization uses that information, but, if your enterprise uses the Teiid Designer Server, your applications can use the View Metadata to resolve queries.

To create this View Metadata, you create a view and define a transformation for that view, a special query that enables you to select information from the source (or even other view) metadata models. For more information, see “Section 4.2.1, “Transformation Editor”.”

Section on Modeling transformations.

What Are Models?

A model is a representation of a set of information constructs. A familiar model is the relational model, which defines tables composed of columns and containing records of data. Another familiar model is the XML model, which defines hierarchical data sets.

In Teiid Designer, models are used to define the entities, and relationships between those entities, required to fully define the integration of information sets so that they may be accessed in a uniform manner, using a single API and access protocol. The file extension used for these models is .xmi ( Example: NorthwindOracle.xmi ) which adheres to the XMI syntax defined by the OMG.

Below is an example of the partial contents of a model file.

Model files should never be modified "by hand". While it is possible to do so, there is the possibility that you may corrupt the file such that it cannot be used within the Teiid Designer system.

The fundamental models in Teiid Designer define the structural and data characteristics of the information contained in data sources. These are referred to as source models (represented by ). Teiid Designer uses the information in source models to federate the information in multiple sources, so that from a user's viewpoint these all appear to be in a single source.

In addition to source models, Teiid Designer provides the ability to define a variety of view models(represented by ). These can be used to define a layer of abstraction above the physical (or source) layer, so that information can be presented to end users and consuming applications in business terms rather than as it is physically stored. Views are mapped to sources using transformations between models. These business views can be in a variety of forms:

  • Relational Tables and Views

  • XML

  • Web services

  • Functions

For full list of supported model types see Chapter 2, New Model Wizards

A third model type, logical, provides the ability to define models from a logical or structural perspective.

How is a Model Defined?

Models are defined using Teiid Designer in various ways:

Model Classes and Types

Teiid Designer can be used to model a variety of classes of models. Each of these represent a conceptually different classification of models.

  • Relational - Model data that can be represented in table – columns and records – form. Relational models can represent structures found in relational databases, spreadsheets, text files, or simple Web services.

  • XML - Model that represents the basic structures of XML documents. These can be “backed” by XML Schemas. XML models represent nested structures, including recursive hierarchies.

  • XML Schema - W3C standard for formally defining the structure and constraints of XML documents, as well as the datatypes defining permissible values in XML documents.

  • Web Services - which define Web service interfaces, operations, and operation input and output parameters (in the form of XML Schemas).

  • Model Extensions - for defining property name/value extensions to other model classes.

  • Function - The Function metamodel supports the capability to provide user-defined functions, including binary source jars, to use in custom transformation SQL statements.

Models and VDBs

Models used for data integration are packaged into a virtual database (VDB). The models must be in a complete and consistent state when used for data integration. That is, the VDB must contain all the models and all resources they depend upon. VDB's are the transport mechanism to expose both the metadata to query against on a server and the corresponding references to the data sources and connections required to perform the actual DB queries. (See the Section 10.3.2, “VDB Editor” section)

Models and Connection Profiles

A connection profile provides the connectivity to a data source and is defined by the DTP framework. Designer utilizes this framework from withing it's JDBC Importer.

Model Validation

Models must be in a valid state in order to be used for data access. Validation of a single model means that it must be in a self-consistent and complete state, meaning that there are no "missing pieces" and no references to non-existent entities. Validation of multiple models checks that all inter-model dependencies are present and resolvable.

Models must always be validated when they are deployed in a VDB for data access purposes.

Teiid Designer will automatically validate your models whenever the user Saves ( Note: the "Models > Validate Automatically" option must be checked). When editing models, the editor tabs will display a "*" to indicate that the model has unsaved changes.

Testing Your Models

Designing and working with data is often much easier when you can see the information you're working with. The Teiid Designer's Preview Data feature makes this possible and allows you to instantly preview the information described by any object, whether it's a physical table or a virtual view. In other words, you can test the views with actual data by simply selecting the table, view, procedure or XML document. The preview functionality insures that data access behavior in the Teiid Designer will reliably match when the VDB is deployed to the Server. Previewing information is a fast and easy way to sample the data. Of course, to run more complicated queries like what your application likely uses, simply execute the VDB in the Teiid Designer and type in any query or SQL statement.

After creating your models, you can test them by using the Preview Data action . By selecting a desired table object and executing the action, the results of a simple query will be displayed in the Data Tools SQL Results view. This action is accessible throughout the Teiid Designer in various view toolbars and context menus.

Previewable objects include:

  • Relational table or view, including tables involving access patterns.

  • Relational procedure.

  • Web Service operation.

  • XML Document staging table.


If attempting to preview a relational access pattern, a web service operation or a relational procedure with input parameters, a dialog will request values for required parameters.