Artigo SQL Magazine 68 - Desvendando o

Oracle Data Integrator

Uso da ferramenta Oracle Data Integrator (ODI) para a
construo de processos ETL (Extract, Transform, Load).
Neste artigo, utilizaremos o ODI para integrar dados de
diferentes origens (SGBD Oracle, Firebird e arquivo texto)
para uma base de destino Oracle.
Publicado no Canal Banco de Dados por Rodrigo Atkinson

De que trata o artigo:

Uso da ferramenta Oracle Data Integrator (ODI) para a construo de processos ETL
(Extract, Transform, Load). Neste artigo, utilizaremos o ODI para integrar dados de
diferentes origens (SGBD Oracle, Firebird e arquivo texto) para uma base de destino
Oracle.

Para que serve:

O ODI nos permite transformar o trabalho, muitas vezes maante, da construo de

processos ETLs, em interfaces e fluxos de fcil desenvolvimento, manuteno e
visualizao.

Em que situao o tema til:

Alm de padronizar e otimizar processos de ETL, o ODI capaz de fazer a integrao

de diferentes tecnologias e bancos de dados em um nico lugar, facilitando o trabalho
de qualquer projeto que necessite fazer integrao de dados.

Desvendando o Oracle Data Integrator Parte II - Resumo DevMan:

Por ser uma ferramenta visual, o ODI proporciona um ambiente de fcil desenvolvimento
e manuteno. Os diagramas ETL das interfaces do ODI so de fcil entendimento,
onde at pessoas sem um grande conhecimento tcnico entendem o processo ETL que
ser efetuado. Os Mdulos de Conhecimento (KMs) trazem uma padronizao e
facilidade de manuteno de cdigo incrvel.

Fora o ambiente de desenvolvimento, o ODI traz um ambiente completo de

monitoramento de execues (Mdulo Operator) dos processos ETL, onde possvel
ver todos os passos gerados pelo processo, assim como linhas inseridas, erros, tempo
de execuo, etc.

Para retomarmos a estrutura apresentada no artigo publicado na SQL Magazine 65,

vamos relembrar de que maneira est estruturada e armazenada as tabelas envolvidas
no processo de ETL. Como explicado, embora nosso modelo esteja em um DER nico,
nossas origens esto armazenadas em estruturas diferentes: as tabelas Cliente,
TipoCliente, Venda e Vendedor esto alocadas no banco de dados ORACLE; as tabelas
Grupo, Item e ItVenda esto no FIREBIRD; e ainda vamos utilizar uma fonte de dados
oriunda de arquivo texto.

Para facilitar o entendimento e a leitura dos tpicos apresentados a seguir, vamos

disponibilizar no contexto da estrutura relacional apresentada no primeiro artigo, todas
as DDLs e DMLs envolvidas nos processos descritos. Estes scripts podem ser obtidos
no site da revista SQL Magazine.

DML (Linguagem de Manipulao de Dados):A DML um subconjunto da linguagem

usada para selecionar, inserir, atualizar e apagar dados.

SELECT: o mais usado do DML, comanda e permite ao usurio especificar

uma query como uma descrio do resultado desejado.

INSERT: usada para inserir um registro (formalmente uma tupla) a uma tabela
existente;

UPDATE: para mudar os valores de dados em uma ou mais linhas da tabela

existente;

DELETE: permite remover linhas existentes de uma tabela.

Sequence:No Oracle possvel gerar de forma automtica uma seqncia de nmeros,

usando o comando sequence. Isto pode ser bastante til quando se pretende criar um
nmero nico para uma chave primria.

Iniciando o desenvolvimento

Depois de configurada todas as Topologias (passos apresentados na primeira parte do

artigo), vamos iniciar o desenvolvimento no mdulo Designer. A primeira tarefa que
temos criar um novo projeto. Na aba Projetos do Mdulo Designer devemos clicar com
o boto direito e escolher a opo Inserir Projeto. Vamos nomear nosso projeto como
PROJETO_ETL conforme Figura 1.

Figura 1. Inserindo Projeto de ETL.

Ainda na Figura 1 vamos explorar alguns conceitos importantes. Na Primeira Pasta

localizam-se os nossos objetos criados no ODI que so disponibilizados em estruturas
de pastas para uma melhor organizao. Porm, uma pasta sempre contm um
conjunto de trs tipos de objetos: Pacotes, Interfaces e Procedimentos.

Pacotes: so os objetos que serviro para modelar o nosso fluxo no processo de ETL.
No pacote so armazenados os objetos utilizados e a ligao entre eles. Depois que
finalizamos a construo de um pacote, geramos a partir dele, um Cenrio, que a
verso compilada do nosso pacote. Faamos uma analogia a um programa comum.
Os pacotes contm os arquivos fonte do programa e os cenrios so os executveis
gerados a partir dos arquivos fonte;

 Interfaces: so os objetos que realmente fazem o trabalho de ETL. Nas interfaces so

definidas as tabelas de origem, de destino e quais as regras sero aplicadas no
processo de ETL;

Procedimentos: como o nome indica, so objetos em que so escritos qualquer tipo

de procedimento extra que se faa necessrio no processo de ETL. Podemos criar
procedimentos que contenham vrios tipos de cdigos, de diferentes tecnologias
suportadas pelo ODI, como por exemplo, escrever um procedimento em PL/SQL, em
Java, em Jython, etc.

Dentro da hierarquia do PROJETO_ETL ainda temos:

Variveis: so utilizadas no ODI como qualquer varivel utilizada em um programa.

Elas armazenam um valor que utilizado e modificado durante o processo de ETL;

Seqncias: o ODI nos d a possibilidade de criao de Sequences, iguais a

uma Sequence de Banco de Dados. Criamos seqncias no ODI quando a Tecnologia
que estamos utilizando no nos permite ter uma Sequence prpria no banco;

Funes do Usurio: estas funes nos do a possibilidade de criao de funes

que iro ser utilizadas vrias vezes no processo de ETL. Por exemplo, se temos que
fazer um determinado tratamento em uma string ou uma data, podemos criar uma
funo para no ter que escrever a mesma funo vrias vezes nas nossas Interfaces;

Mdulos de Conhecimento: so conhecidos tambm como KMs (Knowledge

Modules). Os KMs so considerados os coraes do processo de ETL no ODI. Eles
so os responsveis por todas as tarefas executadas nos processos de ETL.

Para melhorar o entendimento vamos detalhar cada tipo de Mdulo de Conhecimento

(KM):

RKM - Reverse Knowledge Module (Engenharia Reversa): o responsvel por fazer

uma reversa customizada dos armazenamentos de dados no ODI. Por exemplo: se
existir uma situao em que se necessite fazer algum tipo de procedimento extra ao
reverter um modelo de dados, podemos utilizar RKMs especficos e no o padro para
esta tarefa. O ODI faz reversas de tabelas automaticamente, mas podemos customizar
estas reversas com um RKM;

LKM - Load Knowledge Module (Carga): o responsvel por carregar os dados das
tabelas de origens no nosso processo de ETL quando estas tabelas se encontram em
servidores de dados (Data Servers) diferentes;

CKM - Check Knowledge Module (Verificao): o responsvel por realizar as

validaes dos dados no processo de ETL. No ODI podemos criar check constraints
prprias contendo alguma regra de negcio (por exemplo, valor no pode ser negativo)
ou podemos validar FKs de banco antes de inserir os dados na tabela de destino, ou
ainda, durante o prprio processo de ETL, podemos verificar dados not null, etc. O CKM
o responsvel por executar todas estas verificaes;

IKM - Integration Knowledge Module (Integrao): o responsvel pela integrao dos

dados efetivamente no banco de destino. Ele resolve as regras do ETL descritas nas
interfaces e insere os dados finais na tabela de destino;

JKM - Journalizing Knowledge Module (Documentao): o responsvel por fazer a

jornalizao de dados quando se trabalha com este tipo de conceito. Pode ser usado,
por exemplo, para se fazer replicao de bancos de dados;

 SKM - Service Knowledge Modules (Servio): utilizado para publicar dados utilizando
Web Services. Pode ser utilizado para gerar e manipular dados via Web Services para
arquiteturas SOA (Service Oriented Architecture Arquitetura Orientada a Servios);

Marcadores: so utilizados para colocar marcadores nos objetos criados no ODI.

Servem para a organizao do projeto.

Nesta fase de nosso projeto ainda no temos nenhum KM. A cada novo projeto
fundamental a escolha de quais KMs iremos utilizar. Para o nosso projeto vamos
importar os KMs necessrios, que so dois:

LKM: para carregar os dados de origens diferentes do nosso destino;

IKM: para fazer a integrao efetiva dos nossos dados para o destino;

No Mdulo Designer, acessamos a aba Projetos e clicamos com o boto direito sobre
a opo Importar e escolhemos a opo Importar Knowledge Modules.... Devemos
ento informar o diretrio onde se encontram os KMs a serem importados.
Originalmente os KMs que fazem parte da instalao do ODI esto na pasta
oracledi\oracledi\impexp.

Vrias opes sero apresentadas e devemos escolher as que se encaixam ao Projeto.

Os KMs que vamos utilizar no nosso projeto so:

LKM File to SQL: Carrega dados de arquivos texto e traz para uma rea de
armazenamento temporrio (ou rea de estagiamento, ou stagging, onde ficam as
tabelas temporrias que o ODI cria automaticamente no processo de ETL);

 LKM SQL to ORACLE: Carrega dados de um banco de dados genrico para um

banco de dados ORACLE;

IKM ORACLE Incremental Update: Integra os dados de forma incremental em um

banco de dados ORACLE, ou seja, linhas que ainda no existem na tabela so
inseridas, linhas que existem sofrem atualizao.

Quando os KMs j estiverem importados podemos ter uma definio do que cada um
faz, bastando clicar duas vezes sobre o mesmo, surgindo assim uma tela com a
descrio e a funcionalidade do mesmo.

Para este processo de ETL no importamos todos os KMs, pois isso dificultaria a
seleo dos mesmos no momento do desenvolvimento devido grande quantidade de
KMs existentes. Portanto, uma boa prtica importar para o seu projeto apenas os KMs
que sero realmente utilizados, a fim de trabalhar com um ambiente mais limpo e com
menos chances de selecionar um KM errado. Em relao aos KMs importados para o
nosso projeto, suas funcionalidades ficaro mais claras no decorrer do Projeto, mais
precisamente no momento do desenvolvimento das Interfaces.

Construindo a Estrutura do Projeto Modelos de Dados

Partimos para a definio de nosso Modelo de Dados, e neste ponto o entendimento de

dois conceitos so importantes: Modelo de Dados (Data Models) e o Armazenamento
de Dados (Data Stores). Um Modelo de Dados pode conter N armazenamentos de
dados (tabelas efetivas do banco de dados). utilizado para agrupar tabelas de uma
determinada tecnologia de um determinado Esquema Lgico. Em nosso Projeto
teremos quatro Modelos de Dados, um para cada finalidade: Origem Oracle, Origem
Firebird, Origem File e Destino Oracle. Dentro de cada modelo estaro os nossos
armazenamentos de dados, ou seja, nossas tabelas do banco de dados.

Portanto, dentro do Mdulo Designer, mais precisamente na aba Modelos, vamos criar
pastas para melhor organizao. Vamos inserir duas pastas de modelos: uma chamada
Destinos e outra Origens.

Agora vamos inserir as pastas de modelos para ambas. Para isso, basta clicar com o
boto direito sobre a pasta Destinos e selecionar a opo Inserir Pasta de Modelos.
Vamos inserir a pasta ORACLE, onde ficaro as tabelas de destino da tecnologia
ORACLE, e repetimos a tarefa para as Origens, criando trs pastas: FILE, FIREBIRD
e ORACLE, onde ficaro as tabelas de origem das suas respectivas tecnologias.

Inserindo o Modelo de Dados Oracle Origem

Vamos criar nosso Modelo da Origem ORACLE. Para esta tarefa devemos clicar com o
boto direito sobre a Pasta de Modelo ORACLE que acabamos de criar e escolher a
opo Inserir Modelo.

Na janela que se abre devemos inserir o nome para o nosso modelo, selecionar a
tecnologia (ORACLE) e a qual Esquema Lgico (ORACLE_ORIGEM) o modelo ir se
referenciar.

nome

de

nosso

Modelo

auto-explicativo

(MODELO_ORACLE_ORIGEM).

Ainda nas configuraes do Modelo vamos acessar a aba Reverter, pois devemos
setar o Contexto que iremos utilizar para importar as nossas tabelas. Em nosso Projeto
o Contexto selecionado o Desenvolvimento. Nesta aba tambm devemos selecionar
quais tipos de objetos queremos que a reversa importe para o ODI. Para o nosso caso
selecionamos apenas Tabelas, pois queremos reverter apenas as tabelas criadas nos
scripts (que se encontram no site da SQL Magazine). Nesta aba de configurao
poderamos tambm aplicar alguma mscara de filtro para que no momento da reversa

o ODI selecionasse apenas os objetos que se adequassem a esta determinada

mscara.

A prxima aba de configurao a Reverso Seletiva (Figura 2). Nesta aba devemos
escolher, das tabelas que passaram no filtro anterior, quais tabelas importar para o ODI.
Para o nosso projeto iremos importar as quatro tabelas que esto alocadas no banco de
dados. Aps selecionar as tabelas podemos clicar na opo Aplicar, e aps em
Reverter.

Figura 2. Executando a Reversa do Modelo de Origem.

Uma mensagem de confirmao ser exibida: Deseja fazer engenharia reversa neste
modelo antes de fechar esta janela? Se anteriormente j clicamos na opo Reverter
podemos clicar em No nesta confirmao. Depois de revertido, teremos as tabelas
da nossa origem ORACLE no ODI.

Inserindo o Modelo de Dados Firebird Origem

Devemos agora inserir o Modelo de Dados tambm para o Firebird. Faremos o mesmo
processo detalhado anteriormente apenas alterando a Tecnologia escolhida.

Selecionamos a Tecnologia Interbase que foi a selecionada para utilizao com o

Firebird no momento da criao da Topologia.

Conforme a Figura 3, selecionamos a tecnologia Interbase e o Esquema Lgico

FIREBIRD_ORIGEM.

Figura 3. Criando modelo de Origem do Firebird.

Aps selecionar o contexto e quais objetos queremos importar na aba Reverter

(novamente selecionamos Tabelas), e quais as tabelas que importaremos na aba
Reverso Seletiva (tabelas criadas no script que se encontra no site da SQL Magazine),
podemos clicar na opo Aplicar e aps em Reverter. Se o procedimento for correto,
as tabelas da Origem Firebird sero importadas.

Inserindo o Modelo de Dados File Origem

Terminada a incluso dos Modelos de Dados ORACLE e Firebird vamos partir para a
incluso do Modelo de Dados do tipo FILE. Para esta tecnologia existem algumas
particularidades que devem ser observadas. Vamos proceder com a criao do modelo
de forma normal seguindo os padres da incluso da Tecnologia ORACLE. Nomeamos

o modelo para MODELO_FILE_ORIGEM e selecionamos a Tecnologia FILE. Tambm

associamos neste ponto o Esquema Lgico FILE_ORIGEM. Vamos aba Reverter,
selecionando o contexto Desenvolvimento. A nica particularidade est no momento
de salvar o modelo: devemos salv-lo sem revert-lo.

Podemos notar que o ODI no apresentou nenhuma mensagem de aviso ou

confirmao em relao reversa no momento que ns criamos o modelo. Isso
acontece porque a Tecnologia FILE no segue necessariamente um padro. Podemos
ter arquivos com delimitaes por caracteres, como ; (ponto e vrgula) ou ento |
(pipe) como podemos ter arquivos que no so delimitados mas sim fixos por um
determinado valor em cada coluna. Todos estes padres se encaixam na Tecnologia
FILE. Devido a particularidades de cada arquivo devemos fazer a reversa de cada
arquivo de forma individual.

Para isso devemos estar no Repositrio de Trabalho do ODI, e clicar com o boto direito
no MODELO_FILE_ORIGEM que se encontra dentro da pasta FILE. Devemos
escolher a opo Inserir Armazenamento de Dados.

Na janela que ser exibida, na aba Definio, devemos colocar um nome para o
modelo de dados e devemos escolher o arquivo correspondente que queremos reverter.
Neste caso o arquivo do tipo TXT (dtempo.txt) e armazena as informaes referentes
dimenso tempo de nosso Data Warehouse. Depois de feita a seleo do arquivo,
vamos para a aba Arquivos (Figura 4), onde devemos informar se o arquivo possui ou
no delimitao. No nosso caso, escolhemos que ele Delimitado. Neste ponto
informamos que o caractere separador de campos do arquivo dtempo.txt o ; (ponto
e vrgula). Tambm nesta estrutura de configurao podemos informar se o arquivo
possui cabealho e de quantas linhas o mesmo formado. Para este caso informamos

o valor 0 (zero). Se algum valor fosse informado, a quantidade de linhas informada seria
retirada do incio do arquivo e seria desprezada.

Outra opo que precisamos definir diz respeito ao Separador de Registros. Podemos
selecionar se o arquivo tem separador do tipo:

MS-DOS (CR+LF (Carriage Return / Line Feed) = '\r\n' hexa 0D0A);

UNIX (LF (Line Feed) = '\n' hexa 0A).

Figura 4. Criando o armazenamento de dados da origem TXT.

Estes padres de separadores de registros se referem s possveis quebras de linhas

do arquivo. Tambm devemos configurar o delimitador de texto que neste caso
(aspas simples), ou seja, as strings do arquivo texto so envoltos por aspas simples.
Com esta configurao o ODI ir considerar apenas o contedo interno da string
ignorando as aspas.

Neste ponto tambm podemos indicar qual separador decimal os nossos valores esto
utilizando, o que no se aplica neste caso.

Finalizando o processo de configurao devemos clicar na aba Colunas e selecionar

a opo reverter. Neste momento o ODI busca as informaes da aba arquivos e
separa em colunas automaticamente (Figura 5).

Figura 5. Coluna do modelo de origem TXT.

Por padro as colunas ficam com nomes C1, C2, C..., mas podem ser renomeadas
conforme necessidade e\ou organizao.

Inserindo o Modelo de Dados Oracle Destino

Vamos agora proceder com a criao do modelo de destino seguindo os padres da

incluso

da

tecnologia

Oracle

para

Origem.

MODELO_ORACLE_DESTINO conforme Figura 6.

Nomeamos

modelo

como

Figura 6. Criao do Modelo de destino Oracle.

Devemos reverter as tabelas repetindo os mesmos passos do modelo de dados Oracle

da origem. Para isso, na aba Definio devemos selecionar a tecnologia Oracle e o
esquema lgico ORACLE_DESTINO. Na aba Reverter selecionamos o contexto de
Desenvolvimento e o tipo de armazenamento de dados a ser revertido (Tabela), e na
aba Reverso Seletiva escolhemos as tabelas contidas no script disponvel no site da
SQL Magazine. Depois deste passo estamos prontos para iniciar o desenvolvimento das
interfaces.

Iniciando o Desenvolvimento das Interfaces

Neste ponto iniciamos efetivamente o desenvolvimento ETL. Vamos desenvolver as

interfaces, procedimentos, variveis e pacotes, que sero os objetos utilizados para a
realizao do ETL.

Desenvolvimento da Interface Carga Destino DIM_CLIENTE

Para iniciarmos o desenvolvimento das interfaces vamos alternar da aba Modelos para
a aba Projetos no Mdulo Designer. Nesta aba vamos alterar o nome da Primeira
Pasta para DW. Esta alterao pode ser feita dando duplo clique sobre a estrutura.

Vamos iniciar carregando as dimenses do DW. A primeira interface a ser desenvolvida

dever fazer a carga de dados para a Dimenso Cliente. Ainda na aba Projetos devemos
expandir a pasta DW e clicar com o boto direito sobre Interfaces selecionando a opo
Inserir Interface, conforme Figura 7.

Figura 7. Inserindo uma nova interface.

Vamos desenvolver a Interface para contemplar o ETL da Dimenso Cliente e, portanto,

nomeamos a Interface como CLIENTES_IN. Neste passo tambm devemos selecionar
o contexto de otimizao, que serve para o ODI montar o fluxo de execuo (Figura 8).

Figura 8. Criando a interface de clientes.

Para melhorar a explicao sobre o contexto de otimizao, vamos imaginar o seguinte

exemplo: temos em desenvolvimento dois esquemas que apontam para uma mesma
instancia de banco de dados. Para o ODI, como os dois esquemas esto no mesmo
banco no seria necessria a utilizao de um LKM (o LKM busca os dados de data
servers diferentes), pois o IKM (mdulo de integrao) conseguiria fazer sozinho a
integrao de dados, otimizando assim o cdigo, pois diminuiria os passos do mesmo.
Porm, se estes mesmos esquemas, em um contexto de Produo, estiverem em
servidores fisicamente separados, o ODI necessitaria utilizar um LKM, pois a sua origem
est fisicamente separada do destino.

Se a interface fosse construda com o contexto de otimizao menos fragmentado

(como o de desenvolvimento neste caso) teramos um problema ao rodar esta interface
em produo, pois o cdigo gerado no contemplaria um LKM.

Portanto, ao selecionar um contexto de otimizao, devemos escolher sempre o

contexto mais fragmentado, pois o ODI ir se basear neste contexto para montar o
fluxo do ETL. No nosso caso, como temos apenas um contexto, pode-se manter o
contexto de desenvolvimento. Outra opo que podemos selecionar nesta etapa
(Figura 8) esta relacionada rea de Stagging, que pode ser diferente do destino. Por
padro, a rea de Stagging sempre no destino, ou seja, os objetos temporrios
necessrios ao processo de ETL sero criados no Esquema de Trabalho do destino
setado anteriormente, no momento da criao da topologia (ESQUEMA_TMP do banco
ORACLE).

Neste ponto poderamos selecionar qualquer esquema para ser a Stagging, mas vamos
mant-lo no Esquema de Trabalho do destino. Aps inserir esta nova Interface devemos

acessar

a aba Diagrama.

Nesta estrutura sero armazenados todos os

relacionamentos, regras e mapeamentos de origem e destino que devero ser

configurados. No lado direito (Figura 9) temos a tabela de destino, no esquerdo,
teremos as tabelas de origem e seus relacionamentos.

Figura 9. Diagrama de uma Interface.

Na estrutura do Diagrama vamos montar a regra de ETL para o nosso destino. Primeiro
devemos

clicar

na

aba

Modelos

selecionar

estrutura

DESTINOS/ORACLE/MODELO_ORACLE_DESTINO. Aps localizar a estrutura basta

clicar e arrastar a tabela DIM_CLIENTE para dentro da estrutura de armazenamento
DESTINO, como pode ser visto na Figura 10.

Figura 10. Adicionando as tabelas de Origem.

Posteriormente devemos selecionar e arrastar a ORIGEM para o lado esquerdo do

Diagrama. Neste momento o ODI pergunta se desejamos fazer o mapeamento
automtico dos campos. Como na nossa estrutura a nomenclatura das colunas so
iguais, o mapeamento iria funcionar sem problemas. Na prtica de desenvolvimento de
um projeto, o mapeamento automtico no recomendado. Na grande maioria dos
casos, as nomenclaturas de origem e destino so diferentes e\ou existir alguma regra
de transformao. Desta forma o ODI pode mapear campos para os locais errados,
gerando re-trabalho para mape-los novamente.

Portanto, selecione No e vamos mapear manualmente. Porm, antes disso, temos

que fazer um join entre tabelas de origem com o objetivo de popular a tabela
DIM_CLIENTE. A DIM_CLIENTE recebe tanto as informaes dos clientes quanto do
seu tipo. Para isso, clique e arraste TIPOCLI para o diagrama. Podemos ver pela Figura
11 que o ODI identificou as colunas que fazem relacionamento entre as tabelas e j
colocou o join automaticamente.

Figura 11. Montando os Joins entre as tabelas de Origem.

Se o processo de montagem dos joins no acontecesse de forma automtica teramos

que clicar sobre a primeira coluna do relacionamento, arrastar e soltar em cima da
segunda coluna do relacionamento. Este o processo manual quando o mapeamento
automatizado no acontece.

Podemos notar ao clicar no join (Figura 12) que vrias opes so apresentadas (todas
so auto-explicativas), como por exemplo, se o join vai ser um inner join ou um left outer
join. Clicando nos diferentes tipos de joins, o ODI nos diz o que ir acontecer em cada
caso.

Figura 12. Opes de Join para montagem da interface de carga.

No caso apresentado para a construo da DIM_CLIENTE utilizamos um inner join. Esta

tarefa avisa que retornar Todas as linhas emparelhadas pela condio de unio entre
CLIENTE e TIPOCLI.

IMPORTANTE: Neste ponto temos a opo de executar este join na origem ou na rea
de teste (stagging). Se for na stagging, o ODI trar as duas tabelas inteiras para o
esquema de trabalho e depois far o join entre elas. Se a opo na origem, o ODI far
o join na origem e trar apenas o resultado daquele join para o esquema de trabalho.

Esta escolha depende de cada caso. No nosso exemplo mais eficiente resolver o join
na origem e trazer resolvido para o destino, pois isso resultar em trazer apenas os
registros que obedeceram regra do join, tornando assim o volume de dados trafegados
de uma ponta a outra menor.

Para mapear um campo no ODI o processo relativamente simples. Deve-se clicar no

campo de destino que se deseja mapear, clicar no campo de origem a ser mapeado,
arrastar e soltar na rea branca Implementao, que fica na parte de baixo do
diagrama. O resultado pode ser visto naFigura 13.

Figura 13. Mapeando uma coluna no ODI.

Faltou apenas o mapeamento do campo ID_CLIENTE e neste passo faremos algo

diferente. Todas as tabelas de destino tm um ID prprio e nico que a PK da tabela.

Estas PKs devem ser populadas com um nmero nico de uma sequence chamada
SEQ_DESTINOS, que se encontra criada no banco de destino.

Agora, devemos clicar sobre a coluna ID_CLIENTE e clicar diretamente no cone do

lpis para abrir o editor de expresses (Figura 14).

Figura 14. Editor de expresses.

O editor de expresses auxilia a montar as expresses que estaro mapeadas nas

colunas. Neste caso, mapeamos uma sequence na coluna ID_CLIENTE. Para isso,
prefixamos o esquema onde a mesma se encontra no banco, por exemplo,
ESQUEMA_DESTINO.SEQ_DESTINOS.

O procedimento de manter prefixado (ESQUEMA.OBJETO) o esquema na Interface

desenvolvida no recomendado para grandes projetos. Exemplo: o esquema principal
est nomeado como ESQUEMA_DESTINO em desenvolvimento, mas em outro
ambiente (produo) o esquema pode variar de nome. Esta alterao faria com que a
Interface no executasse de maneira correta. A soluo deste problema seria utilizar
uma funo prpria do ODI que retorna o nome do esquema em que a interface esta
sendo executada. Esta funo pode ser encontrada dentro do Editor de Expresses
(Figura 15), mais precisamente em Funes OdiRef. O ODI possui vrias funes muito

teis. A lista completa destas funes podem ser encontradas no manual de referncia
da ferramenta.

Para este exemplo em vez de ter uma sequence com o esquema prefixado
(ESQUEMA_DESTINO.SEQ_DESTINOS) substituiramos pela funo denominada
getShemaName,Figura 15.

Figura 15. Editor de Expresses.

Aps escrever o comando a ser mapeado confirmamos com um OK na janela.

Voltamos para a montagem da Interface. Notamos na Figura 16 que, ao lado do nome
das colunas, encontram-se pequenos cones, como uma pequena janela, um martelo
(que ainda no se encontra na tela), um alvo e uma chave.

Figura 16. Mapeamento completo para DIM_CLIENTE.

Cada smbolo possui um significado:

Janela: indica que o campo ser resolvido na origem e ser avaliado durante o
processo do ETL;

Martelo: indica que o campo ser resolvido na rea de stagging e ser avaliado
durante o processo do ETL;

Alvo: indica que o campo ser resolvido apenas no destino, o que significa que ele
no ser avaliado durante o ETL e ser apenas inserido no destino;

Chave: indica a chave da tabela. Por default, o ODI escolhe para ser a chave a prpria
chave primria (PK) da tabela, mas, como veremos neste caso, podemos modificar a
chave para fazer com que o ODI resolva o ETL da maneira que ns desejamos.

Podemos trocar o local que o campo ser executado (resolvido) clicando na coluna que
desejamos modificar e em seguida na opo Executar em:, selecionando o local
escolhido. No caso da sequence, iremos especificar que ir executar no ambiente de
destino. Esta troca de diretrio tem um motivo: a sequence no deve ser avaliada
durante o processo de ETL e deve ser executada somente no momento da insero do
novo registro no destino. Se no for estruturada desta maneira causar um erro na sua
execuo.

Outra tarefa necessria a alterao da chave da tabela Cliente. Esta tabela tem como
PK o campo ID_CLIENTE e populado por uma sequence. Isso significa que o valor da
PK sempre muda e novos registros seriam inseridos na tabela sempre que a Interface

fosse executada. Se executssemos dez vezes a carga, os clientes estariam dez vezes
duplicados na tabela de destino.

O correto para a tabela Cliente existir apenas um cdigo por cliente, ou seja,
precisamos que a coluna CDCLI seja a chave natural (NK Natural Key). Para o ODI
levar em considerao a coluna CDCLI como chave e no a atual PK ID_CLIENTE
devemos proceder com a alterao conforme aFigura 17. Ao clicar sobre a tabela de
destino DIM_CLIENTE percebemos que na opo Atualizar Chave est selecionado
DIM_CLIENTE_PK que representa a PK da tabela no ODI.

Figura 17. Chave de DIM_CLIENTE.

Trocamos o Atualizar Chave para a opo sem definio e agora temos a liberdade
de selecionar a chave que necessitamos. Selecionamos ento a coluna CDCLI e
clicamos em chave, conformeFigura 18.

Figura 18. Mapeamento de DIM_CLIENTE.

Com isso a chave para o ODI passa a ser CDCLI. Clicando sobre as colunas, podemos
notar na estrutura Atualizar, check-boxes de Inserir, Atualizar, UD1, UD2, etc.
(Figura 19). Estes checks funcionam para configurar se o campo ser inserido no
destino, se ele ser atualizado no destino ou se ele executar alguma das funes
definidas pelo usurio (UD User Defined). No nosso caso, todos os campos por padro
esto marcados como Inserir e Atualizar. Porm, no caso da coluna ID_CLIENTE
devemos desmarcar a opo Atualizar (Figura 19), pois a sequence no pode
participar do passo de update gerado pelo KM sob o risco de erros serem gerados na
execuo. Este processo ficar mais claro no momento da execuo da interface que
ser explicado a seguir.

Figura 19. Configurando o comportamento dos campos.

Concluda as configuraes vamos para a aba Fluxo. Na tela de Fluxo (Figura 20)
representada a forma como a ferramenta ir fazer a execuo da Interface.

Figura 20. Fluxo de trabalho do ODI.

Para este caso o ODI demonstra apenas um nico exemplo com a utilizao do IKM,
que por si s ir resolver todo processo de ETL. Esta estrutura nica devido s tabelas
que estamos utilizando como origem e as tabelas que queremos popular (tabelas de
destino) se encontrarem em um mesmo Data Server (uma mesma Origem) configurado
na topologia.

Se esta estrutura estivesse em Data Servers diferentes, a ferramenta nos mostraria

duas estruturas distintas, uma com a composio de um LKM responsvel pela carga
dos dados para as reas de stage e outra com o IKM que realizaria os demais processos
de ETL. Este caso ser explorado no momento da construo das Interfaces que
carregam os dados oriundos dos arquivos do tipo texto e do banco de dados Firebird.

Ao clicar sobre a caixa denominada Alvo-rea de Teste (Figura 20) podemos observar
que o KM utilizado por padro o IKM (Oracle incremental Update). Resumidamente
este KM faz cargas incrementais, ou seja, ele verifica a chave definida na interface
(CDCLI neste caso) e se esta chave ainda no existe no destino o processo faz a
insero da mesma de forma automtica. Se esta chave j existe o processo apenas
faz o Update nas colunas selecionadas com a opo Atualizar (Figura 19).

Podemos notar tambm que o KM vem com vrias opes de valores padres. Ao clicar
sobre cada opo, ao lado, apresenta-se a sua descrio. Para este trabalho iremos
modificar apenas a opo Flow Control que devemos mudar para opo no (Figura
20). Quando a opo descrita estiver selecionada como Sim o ODI ir invocar o CKM
(Validaes Ver explicao sobre CKM neste artigo) selecionado e far a verificao
dos dados durante o processo de ETL. Como no criamos nenhuma validao para esta
tabela, podemos retirar a opo de Flow Control desta interface.

Para realizar a execuo da interface basta clicar sobre o boto Executar no canto
inferior direito da interface (Figura 21). Neste momento ser apresentada uma tela
questionando em qual contexto executar, neste caso o contexto de Desenvolvimento;
qual o agente, vamos executar no agente local; e o nvel de registro, que indica o grau
de informaes que deve ser gerado no log do ODI, que podemos deixar o valor padro
5.

Figura 21. Execuo de uma Interface.

Durante a execuo da Interface podemos acessar a Lista de sesses do mdulo

Operator e acompanhar o processo de execuo das cargas (Figura 22).

Verificando a execuo (Figura 22), podemos observar os passos criados pelos KMs
do ODI. Reparamos que a primeira palavra escrita Integrao. Isto significa que
todos os passos gerados por esta Interface foram de um IKM.

Para carregar a tabela DIM_CLIENTES, a ferramenta gerou onze passos distintos. Os

cones em verde indicam comandos executados com sucesso. cones em amarelo
indicam que o comando falhou, porm a execuo continua normalmente. cones em
vermelho significam erros que interrompem a execuo da carga, que no foi o caso.

No exemplo da Figura 22 percebe-se que o passo indicou ateno. Isto aconteceu

porque o ODI tentou dropar uma tabela temporria que ainda no existia no banco.
Clicando duas vezes sobre qualquer passo possvel ver o que executou, quanto tempo
levou para executar a carga, quantas linhas foram inseridas, entre outros.

Figura 22. Execuo da Interface CLIENTES_IN.

Esta Interface (CLIENTES_IN) inseriu sete linhas na tabela de destino. Se esta Interface
fosse executada novamente veramos novamente os mesmos onze passos, mas no
processo nenhuma nova linha seria inserida. Como esta Interface incremental, ela
carrega apenas as linhas que ainda no foram carregadas e faz a atualizao de linhas
quando a mesma no existir.

DICA: Para compreender melhor como funcionam as configuraes feitas no ODI, tente
marcar a opo Atualizao no campo ID_CLIENTE que carregada juntamente com
a sequence ou mude o local de execuo de Destino para Stagging e compare os
passos de uma execuo e outra. No comeo parece complicado, mas depois que
aprendemos os pequenos truques da ferramenta verificamos que o ODI uma
poderosa e flexvel ferramenta para processos ETL.
Desenvolvimento da Interface Carga Destino DIM_PRODUTO

O prximo passo para o projeto criar a Interface que carrega a tabela DIM_PRODUTO.
A tarefa para montagem da carga a mesma explanada anteriormente. Desta forma,
vamos direto para o Diagrama da Interface (Figura 23). Todas as tabelas desta estrutura
so provenientes da origem FIREBIRD.

Figura 23. Diagrama de PRODUTOS_IN.

Importante: Devemos efetuar a modificao da coluna ID_PRODUTO para ser

executada no banco de destino (cone do Alvo da coluna ID_PRODUTO na Figura
23). Tambm devemos desmarcar a opo Atualizar para este atributo. Outra
modificao que dever ser efetuada a troca da chave da tabela (DIM_PRODUTO)
para ser CDITEM e CDGRUPO, pois estes dois atributos referenciam a NK (Natural Key
- Chave Natural) da tabela. Outro ponto importante que ao clicar no cone do lpis,
o ODI perguntar qual a tecnologia a ser considerada no editor, pois temos duas
tecnologias no diagrama (Firebird e Oracle). Selecionaremos o Oracle pois a sequence
est no banco Oracle.

Clicando na estrutura da aba Fluxo temos uma novidade: a caixa do LKM (Figura
24). Esta estrutura se encontra presente devido necessidade de carregar dados que
se encontram em outro banco de dados (neste caso o Firebird).

Figura 24. Fluxo de PRODUTOS_IN.

Com isso o ODI primeiro extrai estes dados da base de origem repassando os mesmos
para a stagging rea. Em relao ao IKM, este ter o papel de pegar os dados e inserir
nas tabelas de destino.

Para a carga da tabela destino DIM_PRODUTO, vamos utilizar o LKM SQL to Oracle.
J em relao ao IKM selecionamos o IKM Oracle Incremental Update no esquecendo
que neste devemos modificar a opo de Flow Control para No.

Ao executar esta Interface os resultados podem ser consultados na lista de sesses

do Operator (veja a Figura 25).

Figura 25. Execuo de PRODUTOS_IN.

Notamos na Figura 25 que o nmero de passos de execues aumentou para

dezessete e que temos descries das aes como Carregando e Integrao. Os
passos com as descries carregando se referem aos passos gerados pelo LKM e os
passos com Integrao se referem aos passos gerados pelo IKM.

Desenvolvimento da Interface Carga Destino DIM_VENDEDORES

Para criar a interface de vendedores basta seguir os mesmos passos das interfaces
anteriores: selecionamos o nosso destino, a nossa origem, mapeamos os campos,

colocamos a execuo da sequence no alvo, desmarcamos a opo de Atualizar e

trocamos a chave para CDVEND (Figura 26).

Figura 26. Mapeamento de VENDEDORES_IN.

Em alguns casos a utilizao de um filtro para os dados se torna necessria e pode

auxiliar no processo de carga. Para exemplificar a utilizao de um filtro na Interface de
carga vamos inserir para esta interface, especificamente, um filtro na nossa origem
(representada por um funil amarelo no diagrama Figura 26). Para fazer um filtro, basta
clicar no campo que se deseja filtrar, arrast-lo para o lado e soltar na rea livre do
diagrama. Aps isso, podemos montar a estrutura e escrever o filtro que desejamos
fazer. Neste caso colocaremos que o campo PERCCOM deve possuir valor menor a 50
(Figura 27).

Figura 27. Utilizando filtro no ODI.

Esta carga possui somente o IKM, pois se trata do mesmo banco de dados e far a
carga com a estratgia incremental (IKM Oracle Incremental Update). Modificamos a
opo do Flow Control para No e executamos a interface.

Desenvolvimento da Interface Carga Destino DIM_TEMPO

Para a carga da dimenso tempo temos uma particularidade. A origem para esta carga
um arquivo texto com uma estrutura simples (Figura 28).

Figura 28. Mapeamento para TEMPO_IN.

Aqui temos uma novidade: no mapeamento da coluna DATA_DIA utilizamos a funo

TO_DATE do Oracle (Figura 29), pois estamos lendo uma string do arquivo texto e
estamos

populando

um

campo

do

tipo

DATE

(TO_DATE(DTE.DATA_DIA,'DD/MM/YYYY')). Neste caso no iremos utilizar a

sequence do banco e sim a prpria sequence existente no arquivo texto.

Figura 29. Mapeamento utilizando procedimento TO_DATE.

Na aba fluxo para este caso teremos um LKM e um IKM. O LKM que iremos utilizar ser
o LKM File to SQL. Para o IKM utilizaremos o Oracle Incremental, onde devemos setar
a opo Flow Control igual a No. Executando a interface podemos ver o resultado
no Operator, como explicado anteriormente.

Desenvolvimento da Interface Carga Destino FATO_VENDAS

Esta interface j tem uma lgica mais elaborada (Figura 30): estamos buscando as
informaes de duas origens: a tabela VENDA que tem sua origem proveniente do
banco de dados Oracle e da tabela ITVENDA que vem do banco de dados Firebird.
Alm dessas origens ainda fazemos joins com as nossas tabelas de Dimenses, pois
precisamos buscar os IDs que foram gravados anteriormente nas nossas interfaces. Os
joins que so realizados so os seguintes:

VENDA.NUMNF=ITVENDA.NUMNF;

 VENDA.CDCLI=DIM_CLIENTE.CDCLI;

(DIM_PRODUTO.CDITEM=ITVENDA.CDITEM)

AND

DIM_PRODUTO.CDGRUPO=ITVENDA.CDGRUPO;

DIM_VENDEDOR.CDVEND=VENDA.CDVEND;

VENDA.DTVENDA=DIM_TEMPO.DATA_DIA.

Para este caso vamos inserir outro filtro (para reforar o exemplo de utilizao):
DIM_TEMPO.TURNO = 'Manh'. Notamos na Figura 30 que a estrutura DIM_TEMPO
possui, assim como explicado anteriormente, um pequeno funil amarelo representando
que existe um filtro no processo de carga desta estrutura.

Figura 30. Diagrama de FATO_VENDAS_IN.

No fluxo selecionamos o LKM SQL to Oracle para ler as tabelas do banco Firebird e o
IKM Oracle Incremental Update para fazer a carga. Marcamos tambm a opo Flow
Control no IKM para No. Como padro, podemos executar a interface e ver o seu
resultado no Operator.

Desenvolvimento do Pacote para Carga de Dados

Aps executar individualmente cada Interface podemos consultar as tabelas de destino

e conferir que todas esto carregadas. Mesmo com a eficincia comprovada para cada
carga este no um modo prtico para execuo de cargas. Em um grande projeto, por
exemplo, estas Interfaces no poderiam ser enviadas para outros ambientes, pois no
so estruturas compiladas para execuo em outros ambientes. Neste sentido
necessitamos criar Pacotes para controlar o fluxo e criar cenrios compilados para que
a execuo em outros ambientes seja garantida.

Para inserir um novo Pacote, no projeto DW, clique com o boto direito sobre a opo
Pacotes e em seguida selecione Inserir Pacote. Na aba Definio nomeamos o
pacote. na aba Diagrama que ser desenvolvido o fluxo do processo de ETL. Nesta
mesma tela pode-se encontrar vrias funcionalidades (em forma de botes) que podem
ser detalhados com o simples passar do mouse sobre cada um.

A caixa de ferramentas do ODI contm diversos objetos que podem ser includos no
fluxo ETL do nosso pacote. Entre eles temos objetos de envio de e-mail, execuo de
comandos do sistema operacional, processo de espera de eventos (tempo limite ou
espera de algum registro em alguma tabela especfica), manipulao de arquivos, entre
outros. O detalhamento de cada componente pode ser visto no arquivo de ajuda do ODI,
que se encontra no menu Ajuda na parte superior da tela.

Para montar o fluxo devemos colocar as interfaces no diagrama do pacote. Para isso,
clicamos

sobre

alguma

interface

arrastamos

para

dentro

do

diagrama,

conforme Figura 31.

Figura 31. Adicionando as Interfaces ao Pacote.

Podemos notar na Figura 31 que a interface CLIENTES_IN possui uma pequena

flecha verde que indica que ela vai ser o primeiro objeto a ser executado. Para
modificar qual objeto ser o primeiro a ser executado possvel clicar em cima do objeto
escolhido com o boto direito e escolher a opo Primeira etapa. Se executssemos
o pacote neste momento somente a interface CLIENTES_IN seria executada, pois ainda
no criamos o fluxo de execuo completo do pacote.

Para criar este fluxo devemos clicar no boto ok (Etapa seguinte ao xito) que contm
uma flecha verde, na barra superior. Aps este passo deve-se clicar sobre o objeto de
origem e arrastar at o objeto de destino, conforme Figura 32. Temos tambm o boto
ko (Prxima etapa ao falhar) que contm uma flecha vermelha, que desviar o fluxo
se algum erro acontecer. Aplicaremos o fluxo de erro em momentos onde for pertinente.

Figura 32. Criando Fluxo de Execuo.

O mesmo procedimento deve ser repetido para o restante das Interfaces (Figura 33).
Aps isso, executaremos o pacote clicando no boto Executar (canto inferior direito).

OBSERVAO: Para manipular o local dos objetos no pacote, escolha o primeiro boto
(o cursor branco Escolha livre) na barra superior.

Figura 33. Fluxo do Pacote.

Observando a execuo da Interface no mdulo Operator (Figura 34) podemos verificar

que agora todas as nossas interfaces esto agrupadas em uma nica execuo do
pacote, evitando a execuo individual de cada uma.

Figura 34. Execuo do Pacote.

Outra tarefa importante pode ser realizada neste Pacote. Vamos implementar um LOG
personalizado para guardar as informaes importantes relacionadas a execuo deste
Pacote. Para isso usaremos a tabela LOG_CARGA que conter o ID da sesso do ODI
correspondente execuo e uma descrio informando se todos os processos da
carga executaram com sucesso ou com erro. Para completar esta demanda vamos
precisar criar uma Varivel e dois novosProcedimentos: um para inserir os dados e
outro para retornar o ID da sesso. Para completar esta tarefa precisamos entender
melhor o que uma Varivel e um Procedimento no ODI.

Criando Variveis

Para criar uma Varivel devemos acessar o projeto PROJETO_ETL, na aba projetos,
clicar com o boto direito sobre a opo Variveis e escolher Inserir Varivel. Na aba
Definio, colocamos o nome da varivel, escolhemos o seu tipo de dado e a sua Ao
(Figura 35).

Figura 35. Criao de Variveis no ODI.

Para a opo Ao, temos as seguintes opes:

Historiar: O ODI manter na aba Histrico todos os valores que a varivel j recebeu
durante as suas execues;

Valor mais recente: O ODI manter na aba Histrico o ltimo valor que a varivel
recebeu durante as suas execues;

No persistente: O ODI no manter nenhum histrico.

A Ao escolhida neste caso a No persistente, pois no temos a necessidade de

manter histrico para esta tarefa. Na aba Atualizando vamos adicionar um comando
DDL que retornar o valor para a varivel, ou seja, o comando executado no banco
de dados e o resultado atribudo para a varivel. Para este exemplo utilizamos um
select simples na tabela dual (que retornar apenas um registro) utilizando a funo
do ODI <%=odiRef.getSession("SESS_NO")%>, que retornar o nmero da sesso. No
combobox Esquema escolhemos em qual esquema queremos executar esta DDL, que
neste caso o ORACLE_DESTINO (Figura 36).

Figura 36. Configurando a varivel.

Tabela dual Oracle: A tabela DUAL uma pequena tabela no dicionrio de dados
que o Oracle ou qualquer usurio pode referenciar para garantir um resultado
conhecido. Esta tabela possui apenas uma coluna, chamada DUMMY com apenas uma
linha, contendo o valor X. A DUAL criada automaticamente pelo Oracle, sob o
esquema SYS, mas pode ser acessada por outros usurios. Sempre que precisamos
verificar um resultado conhecido, como a data e hora do servidor ou o valor atual de
uma sequence, simplesmente fazemos a consulta referenciando a tabela DUAL. Isto por
que toda consulta SQL deve envolver uma tabela, porm, se utilizarmos qualquer tabela
povoada nesta consulta, teremos uma srie de inconvenientes, como estratgia de
acesso ou eventual utilizao de ndices, etc.

O teste para verificar se o procedimento foi realizado com sucesso pode ser feito ao
clicar no boto Renovar. Se a Ao da varivel Historiar ou Valor mais recente,
podemos ver o valor da varivel na aba Histrico (Figura 37).

Figura 37. Histrico da Varivel.

DDL (Linguagem de Definio de Dados):A DDL permite ao usurio definir tabelas

novas e elementos associados. A maioria dos bancos de dados de SQL comerciais tm
extenses proprietrias no DDL. Os comandos bsicos da DDL so poucos:

CREATE: cria um objeto (uma Tabela, por exemplo) dentro da base de dados;

DROP: apaga um objeto do banco de dados.

Alguns sistemas de banco de dados (Oracle, por exemplo) usam o comando ALTER,
que permite ao usurio alterar um objeto, por exemplo, adicionando uma coluna a uma
tabela existente. Outros comandos DDL: ALTER TABLE, CREATE INDEX, ALTER
INDEX, DROP INDEX, CREATE VIEW, DROP VIEW.

Nosso prximo passo adicionar a varivel no pacote e setarmos a mesma para ser
executada como demanda inicial, pois queremos ter o nmero da sesso para gravar
no log antes de comear o processo de ETL. Quando clicamos sobre a varivel,
podemos observar as suas propriedades, entre elas o Tipo, que pode ser setado de
vrias formas (o cone no pacote e suas propriedades mudaro conforme o que for
setado). As opes de Tipo so:

 Declarar varivel: utilizado para receber um valor passado por parmetro quando
executamos um cenrio compilado;

Avaliar varivel: utilizado para fazer um teste lgico (=, <>, >, <, etc.) sobre o valor
da varivel. Se o teste lgico retornar verdadeiro, o fluxo segue para a prxima etapa
seguinte ao xito (flecha verde). Se retornar falso, o fluxo segue a prxima etapa ao
falhar (flecha vermelha);

Renovar varivel: executa o select colocado na aba Atualizando da varivel,

atribuindo o resultado do select varivel (o select deve retornar apenas um valor, ou
um erro ocorrer);

Definir varivel: atribui manualmente o valor desejado varivel.

Para o nosso pacote, escolheremos o tipo Renovar varivel, pois queremos que a
varivel contenha o valor retornado do select da aba Atualizando. Isto faz com que
tenhamos o valor da sesso do ODI atribuda a nossa varivel, com o objetivo de
gravarmos posteriormente no log (Figura 38).

Figura 38. Tipos de Variveis.

Criando Procedimentos

Para criar Procedimentos no ODI devemos acessar a pasta DW, clicar com o boto
direito sobre a opo Procedimentos e depois em Inserir Procedimento (Figura 39).

Figura 39. Inserindo novo procedimento.

Na aba Definio devemos apenas colocar o nome do nosso Procedimento. J na

aba Detalhes, devemos clicar no primeiro boto Adicionar na parte superior. Aps
este passo ser aberta uma janela onde deve ser inserido o comando que queremos
que este Procedimento execute. Percebemos aqui o nvel de flexibilidade de trabalhar
com o ODI. Nesta tela que foi apresentada possvel adicionar qualquer tipo de
comando de qualquer tipo de tecnologia suportada pelo ODI, entre elas Oracle, Java,
DBase, Hyperion Essbase, Java Script, entre outros.

A lista completa de tecnologias suportadas pode ser vista no combobox Tecnologia.

Para este exemplo, faremos apenas um simples insert em uma tabela, mas as
possibilidades so muito maiores, podendo ter blocos inteiros de PL/SQL com uma
lgica muito mais complexa, tudo dependendo da necessidade do projeto.

Portanto, escolhemos a tecnologia Oracle, o esquema ORACLE_DESTINO (onde est

a tabela de log) e escrevemos o comando a ser realizado, conforme a Figura 40.

Figura 40. Criando novo Procedimento.

Notamos alguns detalhes diferentes neste procedimento:

 <%=odiRef.getSchemaName( )%>: Funo que retorna o nome do esquema do

banco de dados referente ao esquema lgico escolhido (ORACLE_DESTINO). Isso se
faz necessrio pois podemos ter nomes de esquemas diferentes em contextos
diferentes. Em desenvolvimento podemos ter ORACLE_DESTINO e em produo
podemos ter ORACLE_DESTINO_PROD. Assim, no podemos deixar o nome do
esquema fixo, pois em produo geraria um erro;

#SESSAO_ODI: Nome da varivel que criamos que conter o nmero da sesso do

ODI, prefixada com #. No momento de execuo, a ferramenta procurar e substituir
as variveis que ele encontrar no cdigo pelo seu valor no momento da execuo.
Devemos ter apenas cuidado para que a varivel contenha algum valor, caso contrrio
um erro ser gerado.

Podemos clicar em OK para fechar esta janela (Figura 40). Observe que poderamos
incluir quantos comandos fossem necessrios, bastando apenas clicar no boto
Adicionar. Poderamos inclusive executar comandos de N tecnologias diferentes em
ordem seqencial.

Nossa prxima tarefa realizar a incluso de outro procedimento. Para criar

procedimentos no ODI devemos acessar novamente a pasta DW, clicar com o boto
direito sobre a opo Procedimentos e clicar em Inserir Procedimento. Para esta
estrutura basta nome-la e clicar em OK, pois iremos inserir uma nova Opo para
este Procedimento. Opes so

parmetros

que

so

repassados

para

o Procedimento. Para inserirmos uma Opo clicamos com o boto direito sobre
o Procedimento e em seguida Inserir Opo.

Ser inserida uma Opo para indicar ao Procedimento se desejamos gravar uma
mensagem de sucesso ou erro. Uma Opo pode ser de trs tipos:

 Marcar Caixa: Opo do tipo checkbox, onde possvel escolher entre as opes
SIM/NO;

Valor: Recebe um valor alfanumrico com capacidade mxima de 250 caracteres;

Texto: Recebe um valor alfanumrico com capacidade ilimitada. O acesso a este tipo
de opo mais lenta do que o tipo Valor.

Escolheremos o tipo Valor (ver Figura 41).

Figura 41. Criando uma nova Opo.

Vamos abrir novamente o procedimento, agora para criar um comando. Escolhemos

neste sentido a tecnologia Oracle, o esquema ORACLE_DESTINO e digitamos o
comando conforme a Figura 42. Este comando far com que a tabela de log seja
atualizada com uma mensagem de Erro ou de Sucesso, conforme o parmetro passado
para ele.

Figura 42. Procedimento para gravar detalhes em LOG.

Neste comando temos o <%=odiRef.getOption("STATUS")%> que ir buscar o valor

passado para o parmetro atravs da Opo que criamos no passo anterior. Clicamos
em OK e vamos inserir osProcedimentos no nosso fluxo do pacote.

Na Figura 43 visualizamos o Fluxo de nossa carga.

Figura 43. Fluxo Final do Pacote.

A leitura deste Fluxo pode ser feita desta forma:

1- Comece executando a atualizao da varivel SESSAO_ODI;

2- Insira um registro na tabela de LOG;

3- Execute as cinco interfaces e grave o status final na tabela do LOG;

4- Se algum procedimento der errado (flechas vermelhas), grave no LOG o status de

erro.

As flechas verdes indicam o fluxo sem erros no pacote. As flechas vermelhas indicam o
fluxo a ser tomado se algum erro ocorrer.

Para incluir as flechas vermelhas, clique no boto ko na barra superior, clique no objeto
origem e arraste para o objeto destino. Para as flechas verdes, funciona da mesma
forma, mas selecionando o boto ok. A ltima tarefa necessria para execuo do
pacote setar a Opo de cada procedimento de Update conforme a sua finalidade.
Temos, portanto dois procedimentos, um que registrar as mensagens de erro e outro

as mensagens de sucesso. Clicando no Procedimento que ir gravar a mensagem de

erro (UPDATE_LOG_pr), vamos na aba Opes para inserir o valor de STATUS que
este Procedimento deve receber quando for executado, que neste caso E (ERRO)
(Figura 44).

Figura 44. Setando o Status do procedimento de erro.

Seguiremos os mesmos passos para outro procedimento (tambm UPDATE_LOG_pr),

onde adicionamos o STATUS para S (SUCESSO). Pronto, agora podemos executar o
nosso pacote clicando no boto Executar na parte inferior da tela.

Executando um Pacote

Executando uma carga com sucesso (Figura 45) podemos notar na nossa tabela de
log (LOG_CARGA) o seguinte registro: A CARGA DA SESSAO 77001 TERMINOU
COM SUCESSO!

Figura 45. Execuo com sucesso do pacote.

Neste ponto podemos simular um erro para verificar a diferena com o processo de
carga anterior. Para esta simulao vamos dropar a tabela FATO_VENDAS do banco
de destino. Executando o cenrio observamos que o fluxo foi desviado para o
procedimento de LOG e foi gravado o seguinte registro (Figura 46): A CARGA DA
SESSAO 79001 TERMINOU COM ERRO! VEJA OPERATOR PARA MAIS
DETALHES.

Figura 46. Execuo com erro do pacote.

Percebe-se que existe uma diferena entre a Figura 45, que teve a execuo da carga
aplicada com sucesso e a Figura 46 que resultou em erro.

Gerando um Cenrio

Agora que temos nosso pacote completo, falta apenas criar um cenrio, que nada mais
do que a verso compilada do pacote. este cenrio que ser mandado para outros
ambientes (testes, produo, etc.) e que ser utilizado para rodar as cargas. Para gerar
um cenrio, basta clicar com o boto direito sobre o pacote e depois em Gerar cenrio
(Figura 47).

Figura 47. Gerando um cenrio.

Quando geramos um cenrio, temos a opo de colocar uma verso para o mesmo e
tambm a opo de dizer quais so as variveis que o cenrio receber de entrada.
Neste exemplo no temos variveis de entrada, logo, podemos desmarc-las.

Pronto! Temos nosso cenrio criado, como pode ser visto na Figura 48.

Figura 48. Cenrio Criado.

Este cenrio funciona como qualquer programa compilado, onde no sofre mais
alteraes. possvel ento fazer modificaes nas nossas interfaces, modificar o fluxo
do pacote, etc., porm este cenrio continuar com a verso compilada anteriormente.
Podemos, no entanto, recriar o cenrio para refletir as modificaes que por ventura
foram realizadas, bastando para isso clicar com o boto direito sobre o cenrio gerado
e escolher a opo Regenerar....

Concluso

Vimos neste artigo a facilidade e a versatilidade do ODI para construir processos de

ETL. Sem muito esforo, conseguimos integrar diferentes origens de dados (Oracle,
Firebird e arquivo texto) para um destino nico Oracle. Fora a facilidade de se trabalhar
com uma ferramenta visual, vimos que os Mdulos de Conhecimento (KMs) nos facilitam
a manuteno e a padronizao dos cdigos, tornando assim o ODI uma grande
ferramenta para o desenvolvimento dos processos de ETL.

Links

PRODUCT

ORACLE:

The

Official

www.oracle.com/products/middleware/odi/oracle-data-integrator.html

Site

TECNOLOGIAS

ODI:

The

www.oracle.com/technology/software/products/odi/index.html

Official

Site