What Is Topology in Oracle ODI?

Topology is the representation of the information system in Oracle Data Integrator and which uses the topology to connect to resources in the information system for integration processes.

It includes everything from data servers and schemas through reserved keywords in languages used by different technologies. ODI uses this topology to access the resources available in the information system to carry out integration tasks.

What Is in the ODI Topology?

All available technologies are defined in the topology. For each technology, the available data types are defined. However, you define all data servers that use the technology in your information system. For each data server, you then define the subdivisions that are known as schemas in ODI.

Next, you must define the agents that carry out the integration tasks at run time. You also set up the contexts that enable you to define an integration process at an abstract logical level, then link it to the physical data servers where it will be performed.

Languages and actions are also found in the topology. Languages specify the keywords that exist for each technology, and actions are used to generate the data definition language (DDL) scripts.

You would only need to modify these parts of the topology if you were adding a new technology to ODI.

Data Servers and Physical Schemas

The most essential things to define in your topology are your data servers and physical

schemas. These enable you to connect to your data through ODI.

What Is a Data Server?

The definition of a data server in ODI is fairly broad. A data server may not always be a traditional DBMS. Instead, any system that is capable of storing data and making that data available in the form of tables is a potential data server in ODI. In ODI topology, a data server is always attached to a specific technology, such as Oracle, Oracle Essbase, Sybase, Extensible Markup Language (XML), or Microsoft Access.

There are multiple ways of connecting a data server to ODI. Most often, Java Database Connectivity (JDBC) is used. JDBC drivers exist for a wide range of technologies. Java Naming and Directory Interface (JNDI) is another way to connect to your data server through a directory service. Additionally, new technologies can be created that enable connectivity to application-specific data sources such as Oracle’s Hyperion Essbase. Some concrete examples of data servers may be helpful. Each instance of a traditional database engine, such as Oracle or Microsoft SQL Server, is a data server. Thus, if you have two instances that are running on the same machine, ODI considers them to be separate data

servers.

A Hyperion Essbase server instance is also a data server. The ODI physical schema represents an Essbase application, and the database represents the Essbase database (cube). This is an example of an application that is capable of storing data and presenting it in the form of tables.

There are a number of simple guidelines to remember when setting up your topology in ODI.

Guideline 1 and Recommendations is that every data server in your information system should appear once in your topology. For example, if you have a machine running two instances of Oracle and one Paradox data source, you have three physical data servers.

Guideline 2 and Recommendations

For each data server in your topology, you must define a physical schema to represent each subdivision of the server that will be used. So, if a server has four technology-specific subdivisions, but you want to use only two in ODI, you must define two physical schemas for that server.

What Is a Physical Schema?

A physical schema is a subdivision of a data server whose precise definition depends on the technology involved. Physical schemas indicate the physical location of the datastores, such as tables, files, topics, and queues inside a data server. The names of physical schemas are used to prefix object names when generating code to produce their qualified names. The physical schemas that need to be accessed have to be defined under their corresponding data servers. You will now see some examples of how this works on different technologies

Physical Schemas: Properties

An ODI physical schema comprises two separate data server schemas: A data schema where the datastores for the physical schema are located and a work schema that is used by ODI to store temporary objects during integration processing. Several physical schemas can share the same work schema.

A data server schema in a data server is uniquely identified, depending on the technology, by a catalog name or a schema name, or both. The terms for the catalog name and the schema name differ depending on the technology.

For example, in Microsoft SQL Server, the catalog is called “database,” and the schema is

called the “owner.”

In Oracle, there is no catalog and a schema is called a “schema” or “user.” You will see some

examples later in this lesson.

Though a data server can have several physical schemas, it has one default physical schema that is used to select a work schema to store server-level temporary objects during certain integration processes.

Defining Topology: Example

The most essential things to define in your topology are your data servers and physical schemas. These enable you to connect to your data through ODI.

Example: Infrastructure for Two Production Sites

Here is an example that you will refer to throughout this lesson. It is a simple setup with accounting and sales information that is used to populate a data warehouse and a purchasing database.

There are two separate production sites, with the first based in London. The London production site has a Windows machine that runs SQL Server. The data warehouse for London is hosted on this machine. The SQL Server database is named db_dwh at this site and the London purchasing database, also hosted on this machine, is named db_purchase.

The example also shows a Linux machine, which, for historical reasons, has two different versions of Oracle running on the same system. One version has a schema for accounting, and the other version has a schema for sales.

A second production site is in New York. Here, the data warehouse and purchasing databases are split onto different Windows machines that run SQL Server. The data servers are labeled “MS SQL Server A” and “MS SQL Server B.” However, the accounting and sales databases run on a single Oracle server. Note that the physical schemas at this site have different names from those at the London site.

ODI Design: Physical Architecture of the Two Production Sites

Applying the previous architecture in ODI design, guidelines 1 and 2 enable you to design this physical architecture in ODI. You disregard which machines physically run which servers.

Each Oracle and SQL Server instance is represented as a data server in the ODI topology.

Similarly, each Oracle schema or SQL Server database is represented as a physical schema

Logical Schemas and Contexts

You learned about the physical architecture, which describes how ODI physically accesses data. Now, you look at the logical architecture, which is a more general view that takes into account the similarities between the physical schemas in different environments.

What Is a Logical Schema?

The essential concept to understand in the logical architecture is the logical schema. A logical schema is a single alias for different physical schemas. These schemas should have similar or identical data structures, and must be based on the same technology. The logical schema thus brings together different physical schemas representing the same kind of data in different contexts.

If two similar data schemas are stored in two different data servers, but they have the same data structures, you declare the two data schemas as physical schemas in ODI, according to guideline 2. However, you create a single logical schema that represents the pair of schemas. The context determines the physical schema that will be used at any given time.

A good example of a logical schema is found in the information system example. In London, the accounting database is stored in a schema called ACCOUNTING. In New York, the schema is called ACCT. Both of them have the same data structure; they contain all tables for an accounting application. In the ODI topology, you consider them as one logical schema: Accounting.

Important Guideline 3

You should define one logical schema each time that you have a group of physical schemas containing similar data structures. In this example, Accounting represents the ACCOUNTING Oracle schema on the Windows machine in New York, the ACCOUNTING schema on the Oracle 10g server running on Linux in London, and the ACCT schema running on Linux in New York.

Note: A simple way to understand guideline 3 is to remember that one logical schema corresponds to the data structure for one application, implemented in several places called physical schemas.

Logical Versus Physical Architecture

This distinction can be generalized into the logical architecture as distinct from the physical architecture.

The physical architecture tells ODI about physical resources, such as connections to data servers and agents that will be covered later in the lesson. The physical architecture describes the locations of servers that exist in your information system and the schemas that you want to use on them. For example, you may logically have one data schema representing your accounting application. But, if this schema exists in different places, you should declare these as separate physical schemas.

The logical architecture, on the other hand, gives a more abstract view of these resources. In this example, your accounting application schema is defined only once in the logical architecture. It is a single schema implemented in several different contexts.

What Is a Context?

A context represents a “situation” where you see the same group of resources. From a technical perspective, a context maps individual logical resources onto individual physical resources. So, given a context and a logical resource, ODI can determine the unique physical resource that is appropriate. In terms of topology, the logical architecture is mapped onto the physical architecture through a context. In your example, London, New York, and Development are contexts representing different geographical sites. However, it can also represent situations for different purposes, such as development, test, or production sites.

A Context Maps a Logical to a Physical Schema

A logical schema can have multiple physical schemas resolved per context. In this example, for the Development context, the ORACLE_ORCL_LOCAL_SALES logical schema maps to the

ORACLE_ORCL_LOCAL.SALES_DEV physical schema

Defining Contexts

Guideline 4: If you have similar groups of resources in different situations, you should define one context for each situation.

If you apply guideline 4 to the example, each site clearly represents the same collection of four different resources. Therefore, you have three contexts: Development, London, and New York.

Dev Site: MumbaiProd Site: London

Production Site: New York

Mapping Logical and Physical Resources

You now illustrate the meaning of a context graphically by using the infrastructure example.

You know about the data warehouses in New York, New York, and London that have different names but share similar data structures. At the logical architecture level, you have a single logical schema called Data warehouse. However, you have three contexts. In the “Development” context, this logical schema is mapped onto the physical schema db_dwh at the New York site. In the “New York” context, it is mapped onto the physical schema dwh at the New York site. In the London context, the logical schema is mapped onto the physical schema db_dwh at the London site.

Mapping Logical and Physical Resources (continued)

You may wonder what would happen if you had a large number of logical resources and a large number of contexts. Would you have to map every single logical resource in every context?

The answer is no. You can leave logical resources unmapped in any context. However, when executing an object in that context, unmapped logical resources cannot be reached. In addition, one single physical resource may be useful in several contexts. For example, you may want to retrieve information from the company Web server in various contexts. This does

not pose a problem. You simply map it to a logical resource in each context. There is a restriction regarding contexts and mapping logical and physical resources. In a given context, a logical resource can be mapped to one physical resource at the most. That is, in a certain context, the data warehouse logical schema cannot be mapped to the data warehouses in London and New York simultaneously. This means that when you ask for one logical resource in one context, you will always have

access to one physical resource if the logical resource is mapped in the context.

Planning the Topology

To plan your topology:

1. Identify the physical architecture that you have in place. All physical data servers and schemas need to be defined in ODI.

2. Similarly, consider the agents you would need and the machines on which they would be located.

3. Identify the different contexts you have by looking for similar data schemas and agents in different situations.

4. Provide names for those similarities to create a logical architecture. Provide a name for each logical schema and Logical agent.

5. Finally, write a matrix of the mappings from your logical architecture to your physical architecture (Use pen and paper.).

.

Sunil Khatri

Add comment