Use to create and configure your data models in Oracle Data Integrator.
A model is a set of datastores corresponding to data structures contained in a physical schema. Models can be organized into model folders.
The Model Editor toolbar has the following items:
Reverse-Engineer: Click to launch the reverse-engineering process.
Check Model: Click to perform a static check on the model.
Generate and Deploy: Click to deploy this datastore as a data service.
The Model Editor has the following tabs:
| Properties | Description |
|---|---|
| Name | Name of the model used in the user interface. |
| Code | Unique code for this model. |
| Technology | Technology of the data model.
As a data model is linked to a single technology, it is a physical data model whose datatypes are native to this technology. |
| Logical schema | Logical schema of the topology to which this model is attached. |
| Action Group | Action group used to generate DDL scripts for this model. If no action group is selected, the <Generic Action> group is used. More |
| Default Folder | Default project folder into which DDL scripts for this model is generated. More
Click Search, to search for the project folder or click Clear Folder Selection to remove the folder specified in this field. |
| Display the Metadata changes in the Model tree | Changes in the database since the last reverse-engineering operation. If this option is selected, all elements of the model that have been deleted or changed in the database since the last reverse-engineering operation are flagged in the tree.
Notes:
|
| Description | Detailed description of the model. |
Note: If you duplicate a model, the Technology field changed to read-only in both models.
Use to reverse-engineer.
Reverse-engineering consists in recovering the metadata (the description of the data structure) of an application from the dictionary of the technology that stores this information, and storing it in the Oracle Data Integrator repository.
| Properties | Description |
|---|---|
| Type of Reverse |
|
| Context | Context in which the reverse is executed.
The combination of the context and the logical schema allows Oracle Data Integrator to connect to the required data server to access the metadata. |
| Logical Agent | Agent used in customized reverse-engineering mode. |
| Types of objects to reverse-engineer | Types of the objects that should be taken into account by the reverse-engineering process.
This list may include tables, views, queues, system tables, table aliases, and synonyms. |
| Mask | Mask which selects the objects to reverse.
This mask uses the SQL LIKE syntax. The percent (%) symbol means zero or more characters, and the underscore (_) symbol means one character. |
| Characters to remove for the Table Alias | Characters to delete in order to derive the alias.
Each datastore has an alias to be used in transformation, filter, and check expressions. This is a short name made up, by default, of the first three characters of the datastore name. For applications that contain many tables beginning with the same prefix, you can ignore the prefix by completing the section "Characters to delete". For example, the value 'DWG_' allows you to derive the aliases PRO, CUS, ITE for the tables named DWG_PROD, DWG_CUS, DW_ITEM. Note: If the datastores already exist, the characters specified here are not removed from the table alias. Updating a datastore is not applied to the table alias. |
| Knowledge Module | This field is only displayed for Customized reverse-engineering.
The Reverse-engineering Knowledge Module (RKM) used to extract the metadata for a specific type of application, and to store it in the Repository. It is possible to select either a global RKM or a RKM imported into the project. Note that only for this technology appropriate KMs are displayed here. |
| Table Alias maximum length | Maximum length of a generated alias for this model.
Characters exceeding this length are truncated. |
Use to select the datastores to reverse from a list.
This list takes into account the mask and the type of object to reverse that have been defined on the Reverse Engineer tab.
This functionality is only available for Standard reverse-engineering.
| Properties | Description |
|---|---|
| Selective Reverse | Specifies that the next reverse-engineering operation will be selective. That is, it will use the parameters on this tab. |
| New Datastores | Specifies that you want to reverse-engineer datastores that are not present in the current model. |
| Existing Datastores | Specifies that you want to re-reverse-engineer datastores already present in the selected model. The metadata for these objects is updated in the repository. Any changes are noted in the execution log. |
| Objects to Reverse | Allows you to individually specify which datastores to reverse-engineer. The list displayed takes into account the mask and parameters. You can reduce this list by deselecting the objects you do not wish to reverse-engineer. This list is not available in Custom mode. |
Use to perform a static control.
The static control (also known as the data quality audit) determines if all the data in a model meets the integrity constraints defined on the datastores. These constraints include references, primary keys, alternate keys, conditions, and mandatory columns. Specifying the appropriate Check Knowledge Module (CKM) is mandatory in order to perform the control.
| Properties | Description |
|---|---|
| Check Knowledge Module | Strategy used for data quality control. Only a CKM valid for the technology of the model can be selected. Only global KMs and KMs imported into at least one project are displayed. |
| Option | Parameters specified by the CKM. You can change the default values of the parameters. You can see a description for each parameter by selecting the parameter in the table. |
| Description | Detailed description of the CKM and its parameters. |
| Execute | Starts a session to perform the data quality check. You must select an agent and a context. |
Use to track data changes (Insert/Delete/Update) in the datastores of a model.
This tab allows you to define and configure the journalizing method used for this model.
| Properties | Description |
|---|---|
| Journalizing Mode | Mode used for journalizing this model. More |
| Journalizing KM | Strategy used for data journalizing. Only a Journalizing Knowledge Module (JKM) that is valid for the technology of the model can be selected. Only global KMs and KMs imported into at least one project are displayed. |
| Options | Parameters specified by the JKM. The default values of the parameters can be changed. You can see the description of each parameter at the bottom of the table when the parameter is selected. |
| Description | Detailed description of the JKM and its parameters. |
| Subscriber List | List of the subscribers currently tracking changes in this model. |
| Properties | Description |
|---|---|
| Capture Process | Name of the Oracle GoldenGate capture process. Lists logical capture process instances available for selection. |
| Delivery Process | Name of the Oracle GoldenGate delivery process. |
| Initial Load Capture Process | Name of the Oracle GoldenGate initial load capture process. Lists logical capture process instances available for selection.
|
| Initial Load Delivery Process | Name of the Oracle GoldenGate initial load delivery process. Lists logical delivery process instances available for selection.
|
Create Capture Process Properties
Click Create on the Capture Process to modify its properties.
| Properties | Description |
|---|---|
| JAgent | Available JAgent instances created under a physical architecture. |
| Context | Available contexts. Based on the context selection, mapping between logical schemas to the physical object happens. |
| Process Name | Name of the Oracle GoldenGate capture process. |
| Logical Process Name | Name of the logical schema object for the capture process. |
Create Delivery Process Properties
Click Create on the Delivery Process to modify its properties.
| Properties | Description |
|---|---|
| JAgent | Available JAgent instances created under a physical architecture. |
| Context | Available contexts. Based on the context selection, mapping between logical schemas to the physical object happens. |
| Process Name | Name of the Oracle GoldenGate delivery process. |
| Logical Process Name | Logical name of the delivery process. |
| Target DB Logical Schema | Name of the logical schema object for the delivery process. |
Use to list the datastores from the model included in the Changed Data Capture (CDC).
This table allows you organize the datastores in the CDC set. More
| Properties | Description |
|---|---|
| Order | Position of the journalized datastore within the CDC set. This order usually depends on the foreign key relationships. A referenced table should have a lower order number than all its referencing tables. |
| Table Name | Name of the journalized datastore. |
Use to configure the generation and the deployment options of data services for this model. More
| Properties | Description |
|---|---|
| Application server | Logical schema corresponding to the application server (web services container) into which the generated web services are deployed. |
| Namespace | Namespace for your web services. It is used to generate the Web Services Description Language (WSDL). |
| Package name | Name of the Java Package generated to contain all the web services. Generally, this is of the form com.<company name>.<project name>. |
| Name of the data source | Name of the data source that you defined in the application server, and that corresponds to the server containing your model's data. This name should be prefixed with java:/comp/env/ if your J2EE application uses a standard JNDI namespace. |
| Name of the data service | Name of the data service that is providing the (CDC related) features at model level. |
| Service KM | Service Knowledge Module used to generate the web service. Only global KMs and KMs imported into at least one project are displayed. |
| Deployed datastores | List of datastores that are deployed as data services. For each datastore, you can give a data service name and the name of the published entity. |
"Creating and Using Data Models and Datastores" in Oracle Fusion Middleware Developing Integration Projects with Oracle Data Integrator
"Configuring the Model" in the "Setting Up Data Services" chapter in Oracle Fusion Middleware Administering Oracle Data Integrator