ODI Tutorial

February 17

2012 Uso da ferramenta Oracle Data Integrator (ODI) para a construção de processos ETL (Extract, Transform and Load). Nesta série de tutoriais, utilizaremos o ODI para integrar dados de diferentes origens (bancos de dados diferentes e arquivos texto) para uma base de destino Oracle.

Topologia

Configurando as Topologias

Neste tutorial vamos definir e parametrizar a arquitetura física e lógica do nosso

projeto de ETL. No ODI o módulo responsável por organizar, armazenar e disponibilizar

as bases e objetos de origem e destino é o Topology. As origens e destinos podem ser

definidas por Tecnologia, ou seja, podemos definir desde servidores de arquivo texto,

Oracle, MySQL, Jython e etc.

Para o nosso tutorial, a principio, iremos configurar somente topologias de origem e

destino para trabalhar com banco de dados Oracle.

Na figura acima, podemos ver os componentes do módulo Topology, no tutorial

passado trabalhamos com o componente Repositories onde definimos o repositório

de trabalho do nosso projeto. Neste tutorial iremos trabalhar com os componentes

Physical Architecture, Logical Architecture e Context.

Physical Architecture (Arquitetura Física)

A arquitetura física define quais são os parâmetros de acesso ao ambiente físico de

dados origem ou destino que estamos utilizando. Como por exemplo, armazenamento

de informações do sistema, características de usuários, tipo do banco de dados

(Oracle, DB2, SQL Server,etc), formato de arquivo (XML, File), tipo de conexão e etc.

Em resumo a arquitetura física, armazena as informações reais dos servidores de

dados assim como suas características de acesso.

Logical Architecture (Arquitetura Lógica)

A arquitetura lógica é utilizada para fazer os agrupamentos dos esquemas físicos. No

processo de desenvolvimento a referência aos bancos de dados se dá através do

esquema lógico e não através do esquema físico. Isso nos permite uma grande

flexibilidade de parametrização.

Contexts (Contextos)

O contexto é o responsável por fazer a união entre o esquema físico e o esquema

lógico.

O conceito aqui exposto é muito importante para a continuidade e para as boas

práticas de utilização do ODI, portanto para que fique bem claro o conceito dos

elementos, vamos imaginar um cenário onde temos o seguinte desenho de ambientes:

Desenvolvimento, Testes, Homologação e Produção.

Para cada ambiente devemos criar um banco de dados físico, pois cada um possui

estrutura, processamento, usuários de conexão e etc distintos. Por consequência

teremos quatro arquiteturas físicas para representar nosso cenário.

Seguindo neste exemplo, iremos precisar de apenas uma arquitetura lógica para fazer

a ligação com os esquemas físicos.

Veja a representação na tabela abaixo de como ficaria o desenho desta solução:

Arquitetura Lógica Contexto Arquitetura Física

ORCL_ORIGEM Desenvolvimento ORCL_DESENV

ORCL_ORIGEM Teste ORCL_TESTE

ORCL_ORIGEM Homologação ORCL_HOMOL

ORCL_ORIGEM Produção ORCL_PROD

Como podemos observar, temos quatro contextos, para quatro esquemas físicos

distintos, e apenas um esquema lógico. Com isso, o desenvolvimento do nosso projeto

irá utilizar uma determinada arquitetura lógica parametrizada para acessar as

informações de um determinado banco de dados físico dependendo do contexto

utilizado.

Quando for fazer o processamento de uma carga e o contexto for selecionado, o ODI

automaticamente irá buscas as informações necessárias no esquema correspondente.

Por exemplo: a interface de dados está sendo executada com o contexto de

Homologação, os dados serão capturados do esquema físico ORCL_HOMOL.

Outra vantagem e uma importante característica do ODI é a fácil reestruturação de sua

plataforma de desenvolvimento. Ainda seguindo o exemplo dado acima, vamos

imaginar que o banco de dados de testes teve que mudar de servidor e trocaram o

nome de identificação, vamos chamar de ORCL_TST. As alterações que precisam ser

feitas estão relacionadas à criação de uma nova arquitetura física, depois fazer a troca

do parâmetro da arquitetura lógica ORCL_ORIGEM no contexto de Teste para esta

nova arquitetura física. Com esta flexibilidade não é preciso nenhuma modificação nas

estruturas já desenvolvidas, estamos apenas redefinindo os parâmetros das novas

arquiteturas físicas a uma arquitetura lógica e não a um banco de dados ou recurso

físico.

Criando a arquitetura Física

Relembrando: Quando criamos uma arquitetura física estamos direcionando um

ponteiro de conexão para um banco de dados físico, para o nosso projeto devemos

criar os esquemas físicos para as informações de origem e destino.

No módulo Topology como já havia falado anteriormente possui diversas tecnologias

para definir os servidores de dados, no nosso projeto iremos utilizar a tecnologia

ORACLE.

Antes de iniciar a parametrização da arquitetura física garanta que os usuários de

banco de dados “schemas/users” que serão utilizados possua os grants necessários

para visualizar as tabelas, as visões, e etc. Os “schemas/users” que iremos utilizar são

os mesmos criados no tutorial anterior. Para relembrar segue a relação na tabela

abaixo:

SCHEMA/USER PASSWORD

DW_ORIGEM DW_ORIGEM

DW_DESTINO DW_DESTINO

DW_TEMP DW_TEMP

Neste projeto vamos trabalhar com três repositórios físicos, um representando o

esquema de origem dos dados, um representando o esquema de destino, esse

desenho nos mostra um repositório tipo DW (origem) e um repositório tipo DM

(destino). Ainda temos mais um repositório o DW_TEMP, quando estamos definindo a

arquitetura física, devemos parametrizar dois banco de dados físicos que são

chamados de Schema(Schema) e Schema(Work Schema) vamos traduzir como

Esquema Principal e Esquema de Trabalho.

O Esquema Principal nos informa qual será o esquema no banco de dados que

conterá as tabelas que iremos fazer “consultas” ou “gravar” dados, ou seja, as tabelas

envolvidas diretamente no processo de ETL.

O Esquema de Trabalho indica o banco de dados que o ODI irá utilizar para criar os

objetos temporários durante o processo de integração (objetos com prefixos I$, C$,

etc).

Configurando o Esquema Físico

Para inserir um servidor de dados acesse o módulo Topology. Procure a aba Physical

Architecture, clique na pasta Technology, irá abrir várias opções de tecnologia,

encontre e selecione a tecnologia ORACLE, neste instantes será apresentada uma

opção identica a figura abaixo:

Agora pressione o botão direito do mouse e escolha a opção “Insert Data Server”,

conforme a figura abaixo.

Uma nova janela será aberta, nesta etapa teremos duas atividades importantes por

fazer. A primeira delas é configurar os acessos, identificar o servidor, colocar usuário e

senha de acesso ao banco de dados que será o repositório e a segunda atividade é

configurar a forma de acesso, no nosso caso através de JDBC. Vamos ver como fazer a

primeira tarefa:

Data Server Parâmetro

Name DW_ORIGEM

Technology Oracle

Instance / dblink (Data Server) Xe

User dw_origem

Password dw_origem

O próximo passo é fazer a configuração do JDBC, para tanto, selecione a aba JDBC

dentro desta mesma janela de configuração, lembre-se que se você clicar em qualquer

botão de validação irá produzir erro, pois o JDBC ainda não está parametrizado.

Quando abrir a janela do JDBC você deve ver a seguinte figura:

JDBC Parâmetro

JDBC Driver oracle.jdbc.driver.OracleDriver

JDBC Url jdbc:oracle:thin:@localhost:1521:xe

Após fazer essas duas parametrizações, teste a conexão. Clique no botão teste, deverá

aparecer as próximas duas janelas, na primeira janela selecione o agent, deixe como

Local e pressione o botão Test.

Se o teste for bem sucedido aparecerá a figura abaixo:

Até esse instante só definimos o repositório mestre para os servidores de origem e a

forma de conexão, ainda falta fazer a parametrização mais importante, que é definir a

área de trabalho e a área temporária. Clique em OK para seguir a configuração. Agora

devemos clicar no botão Apply, neste momento uma nova janela irá abrir. Nesta janela

iremos parametrizar o Esquema Físico, veja na figura abaixo:

Nesta figura temos muitas informações importante. A primeira coisa que devemos

fazer é parametrizar os campos Schema (Schema) e Schema (Work Schema). O

parâmetro Schema (Schema) representa o local físico onde as tabelas do DW irão ser

armazenadas, o parâmetro Schema (Work Schema) representa a área temporária que

será utilizada pelo ODI para gerar tabelas temporárias no processo de integração.

Adotando o critério de melhores práticas sempre parametrize com schemas distintos,

pois o ODI possui a característica E-LT, ou seja, a transformação pode ocorrer tanto na

origem, quando no destino, sem a necessidade de um hardware proprietário fazendo

as transformações no meio do processo.

Nesta mesma janela podemos ver informações sobre os prefixos das tabelas

temporarias (Work Tables) e também das tabelas de jornalização (Journalizing

elements). Você deve estar se perguntando para que serve esses dois conceitos ?

A jornalização é o conceito de manutenção de registros diários, o propósito da mesma

é garantir a integridade dos metadados.

As tabelas temporárias são criadas como espelho, de acordo com a necessidade do

processo de integração. Todas as tabelas (trabalho e jornalização) são criadas

automaticamente durante o processo de integração dentro do schema/user definido

como esquema de trabalho (Work Schema). No ODI existe o conceito de “Stagging

Area”, que é responsável pela criação e armazenamento dos objetos temporários do

ETL, este conceito será revisto e abordado profundamente no momento em que

estivermos construíndo as interfaces de integração.

O que significa as extensões ? Abaixo segue uma breve explicação de cada prefixo:

E$: quando utilizamos tratamento de erros no ODI, os erros gerados são

gravados nesta tabela que é criada por default como

E$_<NOME_DA_TABELA>;

C$: criada quando estamos buscando os dados de um banco diferente do

destino. O ODI cria esta tabela, popula com as informações da origem e depois

utiliza a mesma no processo de ETL. Criada por default como

C$_<NOME_DA_TABELA>;

I$: criada durante o processo de ETL. Nesta tabela são resolvidos todos os

relacionamentos entre as tabelas envolvidas no processo, e depois de pronta é

utilizada para popular a tabela de destino. Criada por default como

I$_<NOME_DA_TABELA>;

J$, JV$ e T$: são tabelas criadas quando se está trabalhando com o conceito

de jornalização.

Neste instante terminamos a parametrização do Esquema Físico de origem, repita todo

esse processo para o Esquema Físico de destino, alterando o parâmetro Schema

(Schema) para DW_DESTINO mas, mantendo o Schema (Work Schema) com

DW_TEMP, iremos utilizar o mesmo repositório temporário utilizado nos parâmetros do

Esquema Físico de origem, fazemos isso por praticidade e segurança, sabendo que

todos os objetos temporários envolvidos no projeto serão criados no mesmo

repositório. Esse tipo de decisão deve ser adotada de projeto para projeto, arquitetura

de banco de dados para arquitetura.

Data Server:DW_ORIGEM Parâmetro

Name DW_ORIGEM.DW_ORIGEM

Schema (Schema) DW_ORIGEM

Schema (Work Schema) DW_TEMP

Data Server:DW_DESTINO Parâmetro

Name DW_DESTINO.DW_DESTINO

Schema (Schema) DW_DESTINO

Schema (Work Schema) DW_TEMP

Criando Contextos

Os contextos é que permitem que possamos ligar um Esquema Físico a um Esquema

Lógico, relembrando que no momento de desenvolvimento o único esquema disponível

é o esquema lógico, portanto criar os contextos é de suma importância para o nosso

projeto.

Para este projeto criaremos 4 (quatro) contextos para representar: desenvolvimento,

teste, homologação e produção.

No módulo Topology, clique na aba Context, em seguida selecione o contexto Global,

este contexto é criado automaticamente pelo ODI, clique com o botão direito, uma

nova jalena será mostrada, conforme a figura abaixo:

Selecione a opção “Insert” e a janela abaixo será apresentada:

Digite o nome do contexto e clique em OK para validar. Repita o procedimento para

criar todos os contextos. Após o processo devemos ter a seguinte visão da janela de

contextos:

Criados os contextos, devemos agora parametrizar o esquema lógico.

Configurando o Esquema Lógico

Chegamos ao último passo da configuração de Topologias do nosso projeto, lembrando

que esse trabalho dentro de uma estrutura de projeto ETL é dinâmica e a qualquer

momento poderá surgir a necessidade da criação de novos servidores de dados

(baseados em sua tecnologia), como por exemplo, criar uma conexão com arquivo

texto.

No módulo Topology clique na aba Logical Architecture e posteriormente na estrutura

Tecnologia Oracle, conforme figura abaixo:

Após selecionada a tecnologia Oracle, clique com o botão direito no mouse, abrirá a

janela mostrada acima, clique em “Insert Logical Schema”.

Vamos trabalhar o projeto apenas com o contexto de Desenvolvimento, e neste

instante definimos o nome do Logical Schema para os repositórios de Origem e

Destino, veja os parâmetros na tabela abaixo:

Logical Schema Parâmetro

Name LOGICAL_DW_ORIGEM

Context Desenvolvimento

Physical Schemas DW_ORIGEM.DW_ORIGEM

Devemos repetir o processo para o repositório Destino:

Logical Schema Parâmetro

Name LOGICAL_DW_DESTINO

Context Desenvolvimento

Physical Schemas DW_DESTINO.DW_DESTINO

Os demais contextos criados serão utilizados em Tutoriais futuros, até o final deste

tutorial apenas o contexto de Desenvolvimento será utilizado.