7.22 Logical Schema Editor

Use to define the logical schema.

A logical schema is an alias that allows a unique name to be given to all the physical schemas containing the same datastore structures.

  • The aim of the logical schema is to ensure the portability of the procedures and models on the different physical schemas. In this way, all developments in Designer are carried out exclusively on logical schemas.

  • A logical schema can have one or more physical implementations on separate physical schemas, but they must be based on data servers of the same technology. A logical schema is always directly linked to a technology.

  • To be usable, a logical schema must be declared in a context. Declaring a logical schema in a context consists of indicating which physical schema corresponds to the alias - logical schema - for this context.

For example:

  • The logical schema LEDGER is the set of Sybase tables required for the functioning of the accounting application. These tables are stored in a physical schema for each installation of the accounting application. The application was installed once in Boston and twice in Seattle (in production and in test).

  • Work in Designer or Operator is always done on the logical schema LEDGER. Only the context allows the physical schema on which the operations are actually done to be determined. Thus, the user can switch from one physical environment to another in a single action.

The following table illustrates this example.

Name of the logical schema Context Physical Schema
LEDGER Boston Sybase Boston LDG
LEDGER Seattle Production Sybase SEATTLE PROD LDG
LEDGER Seattle Test Sybase SEATTLE TEST LDG

The Logical Schema Editor is made up of the following tabs:

7.22.1 Definition

Properties Description
Name Name of the logical schema. It is recommended to give a name that suggests the functional content of the schema (program or application name). For example, LEDGER, CRM, ACCOUNTING.

Caution: This name is used as ID code by the objects contained in the work repositories accessed by other Oracle Data Integrator Navigators. Uncontrolled modification of this name may cause a manual readjustment of the references from the user interfaces.

Context List of the contexts declared in Oracle Data Integrator.
Process Type Type of the process that performs Changed Data Capture in Oracle GoldenGate.
  • Capture: Reads the changes from database log files and writes them to trail files, a common Oracle GoldenGate format. This process is database dependent, it needs to understand the format of log files corresponding to the database. One process per database. A capture process can extract from any number of tables the single access details in the configuration.

  • Delivery: Reads the content from a common trail file and populates the target database. This process can be database dependent or common. A delivery process can update only one database, but it can update multiple tables accessed through the same account.

Target DB Logical Schema Database schema where the selected process type writes content to.
Physical Schema Shows the physical schema that corresponds to the logical schema in this context. An undefined value shows that the logical schema does not exist in the context.

"Creating a Logical Schema" in the "Setting Up a Topology" chapter in Oracle Fusion Middleware Administering Oracle Data Integrator