Configuring the data model
Information associated with a data model
To view and edit the owner and documentation of your data model, select 'Information' from the data model 'Actions' menu for your data model in the navigation pane.
Note
This area is available only to authorized users in the 'Advanced perspective'.
Unique name | The unique name of the data model. This name cannot be modified once the data model has been created. |
Owner | Specifies the data model owner, who will have permission to edit the data model's information and define its permissions. |
Localized documentation | Localized labels and descriptions for the data model. |
Permissions
To define the user permissions on your data model, select 'Permissions' from the data model 'Actions' menu for your data model in the navigation pane.
The configuration of the permissions of a data model are identical to the options for the permissions of a dataset, as explained in Permissions.
Data model properties
In the navigation pane, under Configuration > Data model properties, you can access the following technical properties:
Module name | Defines the module that contains the resources that will be used by this data model. This is also the target module used by the data model publication if publishing to a module. |
Module path | Physical location of the module on the server's file system. |
Sources locations | The source paths used when configuring Java components in the 'Component library'. If a path is relative, it will be resolved using the 'Module path' as the base path. |
Publication mode | Whether to publish the data model as an XML Schema Document within a module or as a publication completely embedded in the TIBCO EBX® repository. Embedded data models offer additional functionality such as versioning and rollback of publications. See Publication modes for more information. Model path in module: Defines the target file for the data model generation. It must start with '/'. |
Dataset inheritance | Specifies whether dataset inheritance is enabled for this data model. Dataset inheritance is disabled by default. See Dataset inheritance for more information. |
Documentation | Documentation of the data model defined by a Java class. This Java class can programmatically specify labels and descriptions for the elements of the data model. The labels and descriptions defined in this Java class are displayed in associated datasets in preference to the ones defined locally on an element. See Dynamic labels and descriptions for more information. |
Special extensions | Access permissions defined by programmatic rules in a Java class. |
Disable auto-increment checks | Specifies whether to disable if the check of an auto-incremented field value in associated datasets regarding to the "max value" found in the table being updated. See Auto-incremented values for more information. |
Enable user services (old API) | Specifies if user services using the API available before release 5.8.0 can be declared. If 'No', the section 'Configuration > User services' is not displayed (except if at least service has been already declared in this section). From release 5.8.0, it is advised to use the new UserService Java API (these services are directly registered through the Java API, hence no declaration is required in the data model assistant). See |
Included data models
You can use data types in the current model that are defined in another data model by adding an entry for the other data model in the table under Configuration > Included data models.
When you access the record of an included model in this table, you will find technical information about the model under the Information tab. As an included data model could eventually have validation errors, for example, due to deleted Java resources, this view will provide information regarding those issues.
It is only possible to include data models that have no validation errors and have been defined and published as an embedded data model or packaged in a module.
The names of data types must be unique across both locally defined and included type definitions. That is, included data types must not have names that coincide with those of data types defined in the current data model or other included data models.
See also
Data services
It is possible to refer to tables in Data Service operations using unique names instead of their paths by defining suffixes for WSDL operations. A WSDL suffix is the association between a table path and a name.
To define a WSDL suffix through the user interface, create a new record in the 'Data services' table under the data model configuration in the navigation pane. A record of this table defines the following properties:
Table path | Specifies the path of the table in the current data model that is to be referred by the WSDL operation suffix. |
WSDL operation suffix | This name is used to suffix all the operation names of the concerned table. If undefined for a given table, the last element of the table path is used instead. This name must be unique in the context of this data model. |
See also
Replication of data to relational tables
In any data model, it is possible to define replication units for data in the repository to be mirrored to dedicated relational tables. These relational tables then enable direct access to the data by SQL requests and views.
To define a replication unit through the user interface, create a new record in the 'Replications' table under the data model configuration in the navigation pane. Each replication unit record is associated with a particular dataset in a given dataspace. A single replication unit can cover multiple tables, as long as they are in the same dataset. A replication unit defines the following information:
Name | Name of the replication unit. This name identifies a replication unit in the current data model. It must be unique. |
Dataspace | Specifies the dataspace relevant to this replication unit. It cannot be a snapshot or a relational dataspace. |
Dataset | Specifies the dataset relevant to this replication unit. |
Refresh policy | Specifies the data synchronization policy. The possible policies are:
|
Tables | Specifies the tables in the data model to be replicated in the database. Table path: Specifies the path of the table in the current data model that is to be replicated to the database. Table name in database: Specifies the name of the table in the database to which the data will be replicated. This name must be unique amongst all replications units. |
Aggregated lists | Specifies the properties of the aggregated lists in the table that are replicated in the database. Path: Specifies the path of the aggregated list in the table that is to be replicated to the database. Table name in database: Specifies the name of the table in the database to which the data of the aggregated list will be replicated. This name must be unique amongst all replications units. |
See also
Add-ons used by the data model
On any data model, it is possible to specify the add-ons used by the current data model. These add-ons will have the capacity to enrich the current data model after the publication by adding properties and constraints to the data model elements.
To define an add-on to be used by the data model through the user interface, create a new record in the 'Add-ons' table under the data model configuration in the navigation pane. A record of this table defines the following properties:
Name | Add-on public name. |
Version | Add-on version. |
Activated | Indicates if the add-on is activated. The add-on must be activated in order to be used. |
User guide table of contents