ODI

2012
Uso da ferramenta Oracle Data Integrator (ODI) para a
construo de processos ETL (Extract, Transform e Load). Neste
tutorial, utilizaremos o ODI para integrar dados de diferentes
origens (banco de dados: diferentes e arquivo texto) para uma
base de destino Oracle.
Tutorial
Series

Guia para Configurao e Desenvolvimento do
Oracle Data Integrator


Introduo
A integrao de dados em estruturas nicas e organizadas um dos
pilares estratgicos para o bom funcionamento de uma organizao.
Como matria prima principal estas estruturas sero responsveis por
disponibilizar informaes essenciais para o bom andamento de qualquer
ramo empresarial e/ou organizacional. Fundamentadas na TI as empresas
prezam pela uniformizao de estruturas visando o retorno de
informaes rpidas, confiveis e de qualidade. Os pressupostos da
aplicao e estruturao de Business Intelligence (BI) em um projeto de
sucesso esbarram no aspecto mais complexo da construo desta
plataforma: o desenvolvimento dos processos de ETL.
A TI tem neste sentido uma misso muito grande: desenvolver e garantir
os processos de ETL em tempo e custos hbeis para a viabilidade do
projeto de BI. Desta forma, vamos desenvolver um estudo de caso onde
originalmente temos um modelo de dados (DER Figura 1) de controle de
vendas.

Figura 1 - Modelo DER Controle de Vendas


O modelo proposto na Figura 1 representa as estruturas bsicas de um
sistema de vendas de mercadorias variadas. Este sistema armazena o
cadastro bsico de pessoas (clientes/classificao dos clientes e
vendedores) e o cadastro de itens que so vendidos bem como a que
grupo o item est relacionado. Todo o sistema gira em torno do controle
das vendas realizadas.
Do modelo original, modelamos o Data Warehouse (apresentado na
Figura 2) que posteriormente ser populado atravs dos processos
desenvolvidos e explicados neste tutorial.

Figura 2 - Modelo Estrela - DW Controle de Vendas

Tendo o objetivo estratgico de apenas controlar as vendas e o
desempenho dos vendedores, desenvolveremos o processo de ETL
utilizando a ferramenta proposta neste estudo. Embora nosso modelo
esteja em um DER nico, nossas origens esto armazenadas em estruturas
diferentes: as tabelas Cliente, TipoCliente, Venda e Vendedor esto
alocados no banco de dados ORACLE; as tabelas Grupo, Item e ItVenda
esto no FIREBIRD; e ainda temos uma origem de datas em um arquivo
texto.
O desafio, depois de criado o Data Warehouse desenvolver os processos
que iro realizar as cargas dos dados da origem (Sistema de Vendas da
Figura 1) para o destino (DW da Figura 2). Para a realizao do processo de
ETL vamos utilizar o Oracle Data Integrator (ODI). Todos os processos
envolvendo a ferramenta de ETL, sero detalhados posteriormente.

Oracle Data Integrator
O ODI a mais recente soluo da gama de produtos Oracle Fusion
Middleware, destinado a negcios de misso crtica, como BI e DW ou
arquitetura orientada a servios (SOA) e monitorao das atividades de
negcios.

Com aspectos e objetivos diferentes do Oracle Warehouse Builder o
Oracle Data Integrator assume caractersticas da ferramenta de integrao
de dados anteriormente associada Empresa Sunopsis, e adiciona
mesma as funcionalidades especficas das ferramentas Oracle.

ODI foi incorporado pela Oracle a partir da aquisio da empresa Sunopsis,
de origem francesa, em outubro de 2006. Anteriormente o nome do
produto era Sunopsis Data Conductor.

A ferramenta objetiva integrar diferentes tecnologias atravs da gerao
dinmica de cdigo. Sua plataforma cobre todos os requisitos de
Integrao de Dados como volumes elevados (utilizao do SGBD para
executar cargas massivas), sua arquitetura simples e orientada aos dados
(utiliza SQL nativo)? facilita o desempenho dos processamentos em lote.

Ela utiliza uma abordagem diferente do processo de ETL Tradicional, o
qual denominado E-LT. Algumas particularidades da estrutura do ODI (E-
LT):
Utiliza um projeto declarativo o qual dispensa codificao das
instrues de atualizao dos Bancos de Dados, sistemas de
arquivos e chamadas de ferramentas externas;

Mdulos de conhecimento permitem isolar as caractersticas
prprias das diferentes origens e destinos tratando tudo,
internamente, com SQL;
Diferentes repositrios compartilhados e vinculados permitem
armazenar as informaes sobre os metadados e sobre as
execues;
Agentes especializados organizam no tempo as atividades de
execuo das integraes.

Para melhor entendimento, no ETL Tradicional (Figura 3):
Extrai dados de diferentes origens;
Transforma os dados em um Processador ETL de Middle-Tier
proprietrio, ou seja, um servidor de ETL dedicado. Esta mquina
seria responsvel pelo recebimento das informaes de origem e
aplicaria o ETL nas mesmas. Depois de transformado os dados so
carregados para o DW;
Carrega os dados transformados no destino.

Figura 3 - Processo Tradicional de ETL



Na estrutura ODI E-LT (Figura 4):

Figura 4 - Processo E-LT do Oracle Data Integrator

Utiliza as capacidades do(s) Banco(s) de Dados para as
transformaes;
Conexo via JDBC. O agente de conexo da ferramenta ODI realiza a
sua conexo com os diversos bancos de dados atravs do JDBC, o
que garante facilidade de conexo, confiana e desempenho;
Sem hardware extra para o processo de ETL. A grande vantagem da
ferramenta de no necessitar de hardware para aplicao de ETL.
Estes processos so sempre realizados nos bancos de dados de
origem e destino.
Aps conhecer um pouco da estrutura da ferramenta vamos iniciar o seu
processo de instalao.



Requisitos para a Instalao e Configurao
Para o estudo vamos utilizar o ODI na plataforma Microsoft Windows XP
SP3 e os SGBDs Oracle 10g Express Edition e Firebird 2.1. Para este
tutorial, precisaremos criar nos bancos, esquemas de dados que contero
as nossas tabelas de origem e de destino. Alm disso, a estrutura da
ferramenta necessita de dois esquemas de dados para armazenamento de
tabelas e demais objetos que iro garantir seu perfeito funcionamento.
Portanto, necessitaremos criar os seguintes esquemas:
ODI_MASTER_REP: Deve ser criado na base Oracle e conter o
Repositrio Mestre do ODI. Este repositrio contm as estruturas
das diferentes tecnologias usadas no ODI, informaes sobre
segurana e versionamento dos projetos e modelos desenvolvidos;
ODI_WORK_REP: Deve ser criado na nossa base Oracle e conter o
Repositrio de Trabalho do ODI. Este repositrio contm todas as
informaes dos objetos desenvolvidos, como informaes dos
modelos de dados, projetos, interfaces e como eles so utilizados,
seus valores e propriedades;
ESQUEMA_ORIGEM: Conter as tabelas de origem Oracle que sero
utilizadas;
ESQUEMA_DESTINO: Conter as tabelas de destino Oracle que
sero populadas;
ESQUEMA_TMP: Ser utilizado para criar as tabelas temporrias do
processo de ETL e ser o esquema utilizado para conexo no banco
Oracle de origem e de destino;
Existe tambm de um banco de dados Firebird onde estaro as tabelas
de origem do Firebird.




Ambiente de Trabalho do ODI
muito importante ressaltar que o ODI possui quatro grandes mdulos:
Mdulo Designer: Este mdulo o responsvel pelo
desenvolvimento em si. neste mdulo que criamos as interfaces,
modelos, procedures, variveis e todo o tipo de objeto que for
necessrio para o desenvolvimento da carga de dados;
Mdulo Operator: Neste mdulo encontramos a lista de todas as
cargas executadas pelo usurio do ODI. um visualizador de
execuo das cargas, onde possvel ver todos os passos
executados, tempos de execuo, nmero de linhas inseridas,
deletadas, atualizadas, etc. Um desenvolvedor ODI trabalha sempre
com o Designer em conjunto com o Operator, pois os processos de
desenvolvimento so realizados com o Mdulo Designer e o
acompanhamento da execuo da sua carga feita no Mdulo
Operator;
Mdulo Topology: Este mdulo responsvel pela configurao das
bases e objetos de origem e destino que participaro do processo
de ETL. Aqui se definem os bancos de dados, assim como servidores
para arquivos textos, XML, etc;
Mdulo Security: Este mdulo responsvel por guardar e permitir
realizar a configurao de toda a parte de segurana, como por
exemplo, criao de perfis de acesso, aplicao de restries
especficas, criao e visualizao de objetos, etc. As permisses
e/ou restries podem ser aplicados a um usurio ou a um grupo de
usurios.


Criando o Repositrio Mestre (Master Repository)
A primeira tarefa de devemos fazer depois do ambiente instalado e
disponvel a construo do Repositrio Mestre. Para realizar esta tarefa
devemos acessar a aplicao Master Repository Creation que se encontra
no diretrio Oracle/Oracle Data Integrator/Repository Management.

Figura 5 - Assistente para criao de repositrio

No Master Repository Creation (Figura 5) devemos indicar qual esquema
do Banco dever receber as tabelas padres e necessrias para o
funcionamento do Repositrio Mestre, ou seja, o esquema
ODI_MASTER_REP. Para relembrar, neste esquema ficaro todas as
tabelas internas que o ODI utiliza para guardar informaes sobre as
estruturas das diferentes tecnologias usadas, informaes sobre
segurana e versionamento dos projetos e modelos desenvolvidos.

Como podemos perceber na Figura 5, a ferramenta permite que o seu
Repositrio Mestre esteja alocado em outro SGBD, diferente do padro
Oracle, adotado neste tutorial. Para tanto, o mesmo dever ser
previamente configurado.

No assistente deve ser informado o driver que ser utilizado para conectar
na base do esquema ODI_MASTER_REP, a URL, o esquema no qual ser
criado o repositrio mestre, a senha deste esquema no banco e a
tecnologia que ele pertence, que neste caso ORACLE.

Para garantir a eficincia da instalao, prudente observarmos na base
do Repositrio Mestre se as tabelas de configurao e suporte (prefixo
SNP) foram criadas corretamente (Figura 6). Esta verificao pode ser feita
atravs de um simples acesso ao SGBD escolhido para o armazenamento
do Repositrio.

Figura 6 - Tabelas de Configurao




Criando um Novo Usurio no ODI Mdulo Security
Manager
Dando continuidade ao processo de configurao do ODI, vamos
demonstrar atravs da utilizao do Security Manager como proceder
para realizar a criao de um usurio. Para no haver confuso, segue a
explicao sobre as nomenclaturas que adotamos neste tutorial:
Login: Login de acesso ao ODI, ou seja, uma configurao que
criada e usada para acessar o ODI. Em outras palavras, a conta de
acesso ao ODI;
Usurio: Usurio do prprio ODI. O ODI nos permite criar diversos
usurios, com diversos tipos de acesso e restries diferentes.
Podemos utilizar qualquer usurio para conectar em um
determinado Login;
Esquema: Nome do esquema do banco de dados Oracle.

Este passo no obrigatrio, pois como o ODI j possui um usurio padro
para a conexo aos mdulos (SUPERVISOR), ns poderamos utiliz-lo.
Porm, para demonstrar todas as funcionalidades da ferramenta,
criaremos um usurio prprio para utiliz-lo durante este tutorial. Para
isso, devemos acessar o Mdulo Security Manager que se encontra no
diretrio Oracle/Oracle Data Integrator/Security Manager.
Na tela de login vamos criar um novo Login e associ-lo ao Repositrio
Master que criamos anteriormente.
Clicando no boto Novo vemos a tela de configurao para logar no
mdulo Security. Nesta tela deve-se informar o nome do novo Login, o
usurio (do ODI), a senha deste usurio bem como as informaes sobre a
conexo ao repositrio mestre. Deve-se notar, porm, que o usurio que
deve ser informado na configurao da conexo do repositrio mestre o
esquema do banco de dados que contm o Repositrio Mestre do ODI e
no um usurio do ODI. Por padro, um usurio j criado na instalao
do ODI. Este usurio o SUPERVISOR com a senha SUNOPSIS (a Sunopsis
era a empresa responsvel pela ferramenta antes da aquisio da
ORACLE), portanto, iremo utilizar este usurio para a nossa primeira
conexo. A configurao completa pode ser vista na Figura 7.

Figura 7 - Configurando a conexo com o repositrio

Ao entrar no mdulo Security, clicaremos na aba Usurios e clicaremos
com o boto direito do mouse na rea branca demonstrada na Figura 8
para selecionar a opo Inserir Usurio.

Figura 8 - Inserindo novo usurio no ODI

Importante: quando um novo usurio criado, o mesmo recebe os
privilgios bsicos. Na tela principal de criao do usurio temos a opo
SUPERVISOR, na qual, se marcada, dar todas as permisses possveis a
este usurio. A configurao de cada usurio depende de sua utilidade
dentro da estrutura do ODI. Se o mesmo no for SUPERVISOR possvel
customiz-lo para as funes pretendidas. Estas permisses variam desde
as permisses de criao de novos usuriose grupos de acesso at
permisses de execuo de algum processo de carga. Para este tutorial
criamos o usurio SQLMASTER com as permisses de SUPERVISOR, de
acordo com a Figura 9.

Figura 9 - Configurando usurio do ODI
importante salientar que a tela principal do Security Manager possui
algumas abas (ver Figura 10) que contm os padres de configurao no
somente de usurios. Podemos configurar, por exemplo, perfis para cada
usurio, as permisses de acesso para cada objeto do ODI, bem como as
permisses de acesso e utilizao para outros servidores ODI.

Figura 10 - Abas de configurao do Mdulo Security Manager

Criando o Repositrio de Trabalho (Work Repository)
O prximo passo configurar e criar o Repositrio de Trabalho. Esta
configurao feita atravs do Mdulo Topology, acessando em
Oracle/Oracle Data Integrator/Topology Manager.
Na tela do Topology Manager (Figura 11) podemos usar o login de
conexo criado no passo anterior (Mdulo Security). Para o usurio,
podemos utilizar o usurio padro do ODI (SUPERVISOR) ou podemos
utilizar o nosso novo usurio criado no passo anterior (SQLMASTER).

Figura 11 - Tela de Login do Topology Manager
Dando continuidade configurao do ambiente, vamos inserir um
repositrio de trabalho. Dentro do Mdulo Topology, na aba Repositrios
(Figura 12) iremos inserir um novo repositrio de trabalho. Para isso basta
clicarmos com o boto direito do mouse na opo Repositrios de
Trabalho e escolher a opo Inserir Repositrio de Trabalho.

Figura 12 - Inserindo novo repositrio de trabalho


Na janela seguinte (aba Definio) devemos dar um nome ao novo
Servidor de dados e escolher qual tecnologia utilizar (Oracle neste caso).
Neste procedimento tambm devemos indicar o schema e a senha que
iremos utilizar como Repositrio de trabalho; vamos utilizar o
ODI_WORK_REP. Na aba JDBC devemos escolher o driver Oracle e
colocarmos a URL do JDBC conforme Figura 13.

Figura 13 - Configurando JDBC para o Repositrio de Trabalho
Voltando para a aba Definio, testamos a conexo com o repositrio de
trabalho clicando na opo Testar, desta mesma janela. Ao escolher esta
opo ser necessrio selecionar um Agente. Um agente no ODI
representa um servio Java que atua como um listener (representa um
arquivo de conexo. Este arquivo responsvel pela conexo de qualquer
Ferramenta com o Banco de dados Oracle) para uma determinada porta
de conexo TCP\IP. Um agente permite a execuo de sesses, execuo
de cenrios, execuo de interfaces, engenharia reversa de modelos dos
bancos de dados para o ODI, entre outros. Inicialmente vamos selecionar
a opo Local (sem Agente).
Aps o Teste de conexo (clicando no boto OK da janela de aviso)
devemos indicar um determinado nmero de identificao (ID) para o
repositrio que ser utilizado pelo ODI e um nome para este repositrio.
Tambm devemos fazer a escolha do tipo de Repositrio:
Desenvolvimento ou Execuo.
Para esclarecer, o Repositrio de Desenvolvimento um repositrio
completo do ODI, ou seja, contm todas as tabelas para guardar as
execues, interfaces, pacotes, procedures e demais objetos que so
criados no desenvolvimento. Um repositrio de execuo um pouco
menor, e contm apenas as estruturas que guardam cenrios compilados
(prontos para execuo), informaes sobre execues de carga, entre
outros. Em resumo, um repositrio de execuo armazena somente
informaes para execues de carga, sem os objetos do
desenvolvimento. Para exemplificao, este tutorial ir utilizar um
repositrio de desenvolvimento (Figura 14).

Figura 14 - Configurando o repositrio de trabalho
Depois de criado, podemos conferir no banco de dados as tabelas que
foram geradas no esquema ODI_WORK_REP.



Configurando as Topologias Mdulo Topology
Manager
Agora que temos os repositrios de trabalho e repositrio mestre criados,
precisamos configurar as nossas topologias, ou seja, especificar as fontes
de dados (Data Servers) onde estaro as tabelas e arquivos de origem,
suas arquiteturas fsicas e lgicas e seus respectivos contextos. Cada uma
das partes citadas e que compem a estruturas de uma topologia ser
explicada neste tpico.
Para iniciarmos a explicao do mdulo Topology Manager vamos abordar
os trs conceitos fundamentais na topologia do ODI.
Esquema Fsico: O esquema fsico o objeto criado no ODI que
contm as informaes reais dos Data Servers, por exemplo, a
tecnologia envolvida, as informaes referentes ao driver que ser
utilizado, informaes referentes ao usurio que ser utilizado para
conexo, entre outros;
Esquema Lgico: O esquema lgico um objeto criado para
representar logicamente um esquema fsico. No desenvolvimento
ODI, a referncia a algum banco de dados acontece atravs do seu
esquema lgico e no pelo fsico. Esta caracterstica
fundamentada na grande flexibilidade para o desenvolvimento,
conforme ser explicado a seguir;
Contexto: O contexto o responsvel por fazer a ligao entre o
esquema lgico e o esquema fsico.
Para facilitar o entendimento vamos imaginar um cenrio com trs bancos
de dados: Teste, Desenvolvimento e Produo. Para cada banco de dados
criamos um esquema fsico, pois fisicamente os mesmos so diferentes
(estruturas, processamento, usurios de conexo, etc.).
Neste sentido, vamos ter apenas um esquema lgico para as trs
estruturas fsicas que iremos chamar de ORACLE_ESQUEMA_ORIGEM,
fazendo a ligao entre os respectivos contextos, conforme Tabela 1.

Esquema Lgico Contexto Esquema Fsico
ORACLE_ESQUEMA_ORIGEM Desenvolvimento BANCO_FISICO_DESENV
ORACLE_ESQUEMA_ORIGEM Teste BANCO_FISICO_TST
ORACLE_ESQUEMA_ORIGEM Produo BANCO_FISICO_PROD
Tabela 1 - Abas de configurao do Mdulo Security Manager
Como podemos observar neste caso, temos trs contextos, para trs
bancos fisicamente distintos, mas com apenas um equema lgico. Com
isso, o desenvolvimento de nossas cargas ir utilizar um determinado
esquema lgico manipulando as informaes de um determinado banco
fsico dependendo do contexto. Ao executar a carga j desenvolvida em
um determinado contexto, o ODI ir automaticamente buscar os dados no
esquema correspondente. Exemplo: se a carga fosse executada no
contexto de Desenvolvimento os dados seriam buscados do Esquema
Fsico BANCO_FISICO_DESENV.
Outra grande vantagem e uma caracterstica importante do ODI a fcil
reestruturao de sua plataforma de desenvolvimento. Ainda no exemplo
da Tabela 1, vamos imaginar que por algum motivo o banco de dados de
desenvolvimento mudou para outra estrutura e possui outro nome,
vamos chamar de BANCO_DESENV_2. As alteraes que precisam ser
realizadas esto relacionadas criao de um novo esquema fsico, fazer a
troca do apontamento do esquema lgico ORACLE_ESQUEMA_ORIGEM no
contexto de Desenvolvimento para este novo esquema fsico. Com esta
flexibilidade no preciso nenhuma modificao nas estruturas j
desenvolvidas, pois estaremos referenciando as mesmas a um esquema
lgico e no a um banco de dados ou algum recurso fsico. As vantagens
deste tipo de flexibilidade so inmeros e muito prticas no dia a dia, e
ficaro mais claras quando explicarmos o desenvolvimento dos ETLs.



Criando o Esquema Fsico Mdulo Topology
O primeiro passo para a continuidade deste tutorial cria e configurar o
Esquema Fsico que apontar para o banco de dados de origem.
Relembrando: na estrutura Topology, mais especificamente na aba
Arquitetura Fsica, exsitem vrias tecnologias o Oracle nos permite criar,
novas, mas no o caso neste momento, pois inicialmente iremos utilizar
a tecnologia ORACLE. Existem dois conceitos bsicos para melhorar o
entendimento na continuidade da configurao da Arquitetura Fsica. O
primeiro conceito o Servidor de Dados. Este objeto contm as
informaes sobre qual driver ser utilizado para conexo, qual URL e qual
usurio ser utilizado para a conexo com o banco de dados.
Esse passo fundamental na configurao de uma arquitetura fsica, pois
devemos ter em mente que o usurio que far a conexo aos nossos
esquemas fsicos precisa necessariamente ter os grants necessrios para
enxergar as tabelas dos outros esquemas que teremos que configurar.
Posteriormente, mais precisamente quando iniciarmos o desenvolvimento
em si esta explanao ficar mais clara, porm importante ressaltar que
todas as vezes que o ODI se conectar neste Servidor de Dados, ele utilizar
este usurio de conexo para ler as tabelas dos esquemas.
O outro conceito se refere ao prprio Esquema Fsico. Assim como o
conceito anterior, este tambm contm duas informaes vitais: o
Esquema Principal e o Esquema de Trabalho.
O Esquema Principal nos informa qual ser o esquema no banco de dados
que conter as tabelas que queremos ler ou popular, ou seja, as
tabelas envolvidas no processo de ETL.
O Esquema de Trabalho nos diz qual esquema ser usado para a criao
dos objetos temporrios so criados automaticamente pelo ODI (Objetos
com prefixo I$, C$, etc).


Configurando as Origens
Inserindo o Servidor de Dados ORACLE
Para inserir um novo servidor de dados devemos acessar o Mdulo
Topology. Na aba Arquitetura so apresentadas vrias tecnologias
distintas para a criao do Servidor de Dados. Vamos selecionar a
tecnologia ORACLE, clicar com o boto direito do mouse e escolher a
opo Inserir Servidor de Dados.
Uma nova janela de configurao ser aberta. Na aba JDBC devemos
inserir as informaes necessrias para a conexo com o driver.
importante salientar que o ODI nos fornece apenas um template para a
conexo com drivers novos. Para configurar a tecnologia JDBC, devemos
informar o driver JDBC que iremos utilizar e qual a URL do JDBC (Figura
15).
Na aba Definio devemos indicar qual esquema ser utilizado para ser
nosso Esquema de Conexo. Iremos utilizar neste tutorial, o
ESQUEMA_TEMP, e este ser o esquema que dever ter os grants
necessrios de select nas tabelas de origem. A lacuna referente Instncia
/ dblink (Servidor de Dados) s preenchida quando trabalhamos com
DBLINKS no ODI, que no o caso do estudo desenvolvido. As demais
abas da janela de configurao no necessitam de interveno para
configurao, pois automatizada pelo ODI.

Figura 15 - Configurao do Driver do JDBC do ODI
Portanto, podemos clicar em OK para seguir nossa configurao. Neste
momento uma nova janela ir abrir. Nesta tela vamos criar o Esquema
Fsico, conforme Figura 16.

Figura 16 - Configurando novo Servidor de Dados
A Figura 16 nos traz muitas informaes importantes. Nossa primeira
tarefa setar o esquema que ir conter nossas tabelas de origem,
escolhemos o ESQUEMA_ORIGEM. Neste ponto podemos tambm setar o
esquema de trabalho (que ir criar os objetos temporrios necessrio para
o processo de ETL).
Conforme explicado anteriormente, o ODI possui a caracterstica ELT, a
qual iremos utilizar neste momento, ou seja, a transformao pode
ocorrer tanto na origem, quanto no destino, sem a necessidade de um
hardware proprietrio fazendo as transformaes no meio do processo.
Para este tutoria, foi decidido que no vamos utilizar o nosso esquema de
origem para criar os objetos temporrios, fazendo assim, todo este
processo no banco de dados de destino. Nesta mesma tela podemos
tambm verificar informaes sobre os prefixos de tabela de trabalho e
jornalizao. Estes dois conceitos sero retomados no momento que
criarmos o esquema de destino (Sesso Configurando os Destinos).
Podemos tambm colocar regras de nomeao do Esquema Fsico a ser
criado. Para o exemplo deixaremos com os valores padres.
Concluda as especficaes da insero de nosso Servidor de Dados,
podemos clicar em OK para finalizar. Logo aps esta ao o ODI
apresentar uma informao explicando que no existe ainda nenhum
contexto especificado e com isso no conseguiremos usar este esquema
criado no desenvolvimento de nossas cargas.
Para continuar devemos criar um novo contexto de Desenvolvimento.
Assim, deve-se acessar a aba Contextos dentro do Mdulo Topology
Manager.
De acordo com a Figura 17, podemos verificar que j existe um contexto
criado denominado Global. Este contexto criado de forma padro pelo
ODI. Ele poderia ser utilizado para os nossos propsitos, mas para o
estudo criaremos um contexto prprio. Desta forma, basta clicarmos com
o boto direito do mouse e escolher a opo Inserir Contexto.

Figura 17 - Criando um novo Contexto

No prximo passo devemos nomear o contexto que ser utilizado para
executar as cargas no ambiente de desenvolvimento. Dentro da estrutura
do ODI possvel criar N contextos, como contextos voltados para Teste,
Produo, etc. Dentre outras configuraes, ainda possvel criar uma
senha para cada contexto, o que tornaria esta estrutura mais segura, pois
a cada carga rodada o contexto exigira uma senha. Manteremos o nosso
contexto com os valores padres.
Criado o contexto, hora de definir o esquema lgico. Na aba
Arquitetura Lgica e posteriormente na estrutura Tecnologia Oracle,
devemos clicar com o boto direito do mouse e escolher a opo Inserir
Esquema Lgico.
Vamos nomear o Esquema Lgico de ORACLE_ORIGEM. Neste passo j
vamos aproveitar para setar no nosso contexto de Desenvolvimento o
Esquema Fsico que ele ir representar. Para o estudo, ser o
SERVIDOR_ORACLE.ESQUEMA_ORIGEM.

Inserindo o Servidor de Dados Tipo FILE
Para utilizar arquivos texto como fonte de dados preciso inserir um novo
servidor de dados. importante destacar que este processo deve ser
repetido para cada nova tecnologia utilizada como fonte de dados.
Portanto, temos que incluir um novo Servidor de Dados que ir refletir
nosso arquivo texto. O ODI j possui um Servidor de Dados denominado
FILE_GENERIC, que responsvel pelo apontamento para a pasta padro
dentro da estrutura do ODI. Mesmo dando suporte para o tipo .TXT,
vamos incluir um novo para melhor exemplificar. Para isso, devemos
acessar o Topology Manager a aba Arquitetura Fsica e selecionarmos a
tecnologia FILE. Com o boto direito do mouse escolhemos a opo
Inserir Servidor de Dados.
Neste servidor de dados, devemos apenas nome-lo e escolher a
tecnologia File. Na aba JDBC, devemos escolher o driver Sunopsis File
JDBC Driver e informar a URL conforme a Figura 18.

Figura 18 - Configurando JDBC para Servidor File
Logo, na tela do esquema fsico, devemos indicar o diretrio que se
encontram os arquivos (Esquema) e o diretrio do Esquema de Trabalho,
onde ficaro os possveis arquivos de log gerados pelo processo de carga.
Criado o Esquema Fsico devemos criar o Esquema Lgico na tecnologia
File e posteriormente apontar este esquema criado para o Esquema
Fsico, como fizemos anteriormente para a Tecnologia ORACLE. O servidor
FILE_ORIGEM est configurado e pronto para ser utilizado.

Inserindo o Servidor de Dados tipo FIREBIRD
Como o nosso projeto necessita, precisamos criar uma origem para nos
conectar ao Firebird. Na aba de Arquitetura Fsica pode-se notar que no
existe uma tecnologia para o Firebird. O ODI permite que o usurio crie
uma nova tecnologia, mas este um passo mais avanado para ser visto
em outra oportunidade. Na lista de tecnologias padres existe uma
denominada Interbase. Como sabemos, o Firebird se originou do
Interbase, portanto, no que diz respeito tecnologia no ODI, as mesmas
so perfeitamente compatveis. Dessa forma, em vez de criarmos uma
nova tecnologia vamos aproveitar para criar o Servidor de Dados dentro
da tecnologia do Interbase.
Ao tentar criar o Servidor de Dados vamos observar que o ODI no possui
um driver de conexo para o Firebird, portanto, o prximo passo
adicionar este driver ferramenta.
Para realizarmos a conexo do ODI com o Firebird vamos utilizar o Jaybird.
possvel obter o JayBird free no site:
http://www.firebirdsql.org/index.php?op=file& id=jaybird.
Fazendo o download do arquivo Jaybird-2.1.6JDK_1.6.zip, devemos
descompact-lo na mesma pasta onde se localiza a instalao do ODI,
mais precisamente na estrutura ...\oracledi\oracledi\drivers.
Neste passo devemos ter muito cuidado. Vamos fazer um procedimento
que consiste na criao de um objeto SnpDriver e um objeto SnpUrl
no ODI. Estes objetoso permitiro escolher atravs de um combobox, o
driver e URL do Jaybird.

Passos para Configurao do Driver:
1. Feche todos os mdulos do ODI;
2. Na pasta ...\oracledi\oracledi\lib faa o backup do arquivo
sunopsis.zip. Iremos modificar um arquivo que compe esta
estrutura e um backup para estes casos sempre til;
3. Extraia para algum diretrio o arquivo sunopsis.zip. Na pasta
descompactada, procure pelo arquivo DriverRefV3.xml (geralmente
se encontra na estrutura sunopsis\com\sunopsis\res\). Este
arquivo contm todas as informaes sobre os drivers disponveis
para seleo no combobox do ODI;
4. Abra o arquivo e insira os dois novos objetos descritos abaixo,
porm, muito cuidado! Deve ser respeitado o local da insero
destes objetos no arquivo, observando as regras do XML. Os objetos
devem ser adicionados embaixo da tag <SunopsisExport> e antes de
</SunopsisExport> e tambm no devem interferir em nenhum
outro objeto descrito no XML, ou seja, os objetos devem ficar entre
as tags <SunopsisExport> e no dentro de alguma outra tag.
5. Para facilitar o trabalho, copie todo o cdigo da Listagem 1 para o
correto funcionamento da conexo com o Firebird;
6. Aps a modificao do arquivo DriverRefV3.xml devemos salva-lo e
compactar novamente a estrutura originalmente denominada
sunopsis.zip;
7. Feito esta alterao, devemos susbstituir a estrutura sunopsis.zip
original pela estrutura sunopsis.zip alterada.
Realizada a configurao, vamos test-la para validar seu funcionamento.
Acessamos novamente o Mdulo Topology. Na tecnologia Interbase,
clicamos com o boto direito e escolhemos a opo Inserir Servidor de
Dados.
Se todos os passos anteriores foram executados de maneira correta,
vamos observar na aba JDBC, mas especificamente na lista de drivers, o
driver org.firebirdsql.jdbc.FBDriver que inclumos anteriormente.
Devemos ento fazer a configurao na aba JDBC, colocando o Driver JDBC
e a sua URL. Um exemplo pode ser visto na Firgura 19.

Figura 19 - Configurao do JDBC para o novo Servidor de Dados

Na aba Definio, deve-se nomear o Servidor de Dados, informar o usurio
e a senha de conexo no banco informado na URL do JDBC e fazer o teste
de conexo. Se a mensagem CONEXO BEM SUCEDIDA aparecer
porque nossas configuraes funcionaram e estamos prontos para a
prxima etapa.
A utilizao do Firebird exige uma particularidade: preciso fazer uma
configurao especfica na Tecnologia Interbase para que a estrutura
funcione corretamente. Para isso, temos que dar dois cliques sobre a
Tecnologia Interbase, na aba Definio e na estrutura Manipulao de
Dados selecionarmos a opo Selecionar e Onde (Figura 20).

Figura 20 - Configurando o Interbase para utilizao da Clusula Where
Esta alterao necessria, pois a estrutura do Interbase por padro no
ODI no suporta o uso da clusula WHERE. Sem esta alterao o ODI no
permitiria o uso de JOINS entre as origens do Firebird.
Para finalizar, necessrio criar um Esquema Lgico, seguindo os mesmos
passos descritos anteriormente na criao do Esquema Lgico da origem
Oracle, porm, colocando o Esquema Lgico na tecnologia Interbase. Na
criao do Esquema Lgico associamos o contexto de Desenvolvimento ao
Esquema Fsico SERVIDOR_FIREBIRD_Default.
Finalmente temos todas as nossas Origens Configuradas.

Configurando o(s) Destino(s)
A prxima etapa configurar o esquema de Destino que ser um Banco de
Dados ORACLE. Neste exemplo, tanto o Banco de Origem ORACLE como o
Banco de Destino, tambm ORACLE esto alocados na mesma estrutura
fsica (em esquemas diferentes). Neste sentido temos duas opes:
podemos criar um Data Server novo para o Destino ou criar apenas um
novo Esquema Fsico no Data Server que j temos criado.
As duas solues possveis tero o mesmo efeito e, portanto a escolha por
alguma delas est voltada organizao de sua estrutura de trabalho.
Nesta situao criaremos apenas o Esquema Fisico no prprio Data Server
existente. importante notar que como estamos utilizando o mesmo Data
Server, o nosso usurio de conexo (ESQUEMA_TMP configurado no Data
Server da origem Oracle) ser utilizado tanto para a Origem quanto para o
Destino. Assim, o usurio ESQUEMA_TMP deve ter grants tanto para as
tabelas de origem como para as tabelas de destino. Ento, no Servidor
ORACLE clicamos com o boto direito do mouse e escolhemos o opo
Inserir Esquema Fsico.
Na aba Definio (Figura 21) devemos setar a opo Esquema como
ESQUEMA_DESTINO e Esquema de Trabalho como ESQUEMA_TMP. O
ESQUEMA_TMP tambm ser utilizado para armazenar os objetos
temporrios criados durante o processo de ETL.

Figura 21 - Configurando o Esquema de Destino Oracle
No decorrer do estudo quando partirmos para a construo das interfaces
vamos entender melhor o motivo de termos configurado apenas o
Esquema de Trabalho no Destino de nossa estrutura. No ODI existe o
conceito de Stagging Area, que responsvel pela criao e
armazenamento dos objetos temporrios do ETL.
Para posicionar sobre o assunto, sempre que uma interface criada,
poderemos informar que a Stagging Area a mesma rea do destino,
portanto, o destino, neste caso, dever conter um Esquema de Trabalho
configurado no seu Esquema Fsico.
Podemos perceber na Figura 21 que existem prefixos para as tabelas de
trabalho e de jornalizao. A jornalizao o conceito de manuteno de
registros dirios. O propsito da mesma garantir a integridade dos
metadados.
Estas tabelas (trabalho e jornalizao) so criadas automaticamente
durante o processo de ETL no nosso Esquema de Trabalho. A seguir vamos
explicar cada prefixo da estrutura:
E$: Quando utilizamos tratamento de erros no ODI, os erros
gerados so 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
informaes da origem e depois utiliza a mesma no processo de
ETL. Criada por padro como C$_<NOME_DA_TABELA>;
I$: Criada durante o processo de ETL. Nesta tabela so resolvidos
todos os relacionamentos entre as tabelas envolvidas no ETL, e
depois de pronta utilizada para popular a tabela de destino. Criada
por padro como I$_<NOME_DA_TABELA>;
J$,JV$ e T$: So tabelas criadas quando se est trabalhando com o
conceito de jornalizao.
Pode-se notar tambm que utilizamos o mesmo ESQUEMA_TMP como
Esquema de Conexo na configurao do Data Server. Fizemos isso por
praticidade e segurana, pois o usurio de conexo tem que ter grants
para todos os objetos que estaro envolvidos no processo de ETL, at
mesmo os objetos de trabalho (temporrios). Como no sabemos quais
sero os objetos temporrios criados durante o processo de ETL, o usurio
padro para conexo teria que ter todos os privilgios para estas tabelas,
o que representaria uma falha de segurana na estrutura.
A maneira de resolver este problema configurar o esquema de trabalho
como sendo o mesmo de conexo, pois este ser o dono dos objetos
temporrios, no necessitando de privilgios especficos para estes
objetos.
Para finalizar, devemos criar o Esquema Lgico e apont-lo para o
contexto de Desenvolvimento. O procedimento para inserir o Esquema
Lgico segue os mesmos padres dos demais. Clicando sobre a tecnologia
ORACLE com o boto direito do mouse e selecionando a opo Inserir
Esquema Lgico. Feito isso, basta nomearmos o Esquema Lgico
(ORACLE_DESTINO) e apontar este esquema para o Contexto de
Desenvolvimento






Iniciando o Desenvolvimento
Depois de configurada todas as Topologias, 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 22.

Figura 22 - Inserindo Projeto
Ainda na Figura 22 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;

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;zes 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 Modelo 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.
O 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. 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 23). 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.
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.


Figura 23 - Executando a Reverso do Modelo de Origem





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 24, selecionamos a tecnologia Interbase e o Esquema
Lgico FIREBIRD_ORIGEM.

Figura 24 - 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, 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 25), 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).
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.

Figura 25 - Criando o armazenamento de dados da origem TXT
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 26).

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

Figura 26 - Coluna do modelo de origem TXT




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. Nomeamos o
modelo como MODELO_ORACLE_DESTINO conforme Figura 27.
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. Depois deste passo estamos prontos para
iniciar o desenvolvimento das interfaces.

Figura 27 - Criao do Modelo de destino Oracle



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 28.

Figura 28 - 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 29).

Figura 29 - 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 30) 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 30) temos a tabela de destino, no esquerdo, teremos as
tabelas de origem e seus relacionamentos.

Figura 30 - Diagrama de uma Interface

Na estrutura do Diagrama vamos montar a regra de ETL para o nosso
destino. Primeiro devemos clicar na aba Modelos e selecionar a
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 31.

Figura 31 - 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 32 que o ODI identificou as colunas que fazem relacionamento
entre as tabelas e j colocou o join automaticamente.
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.

Figura 32 - Montando os Joins entre as tabelas de Origem
Podemos notar ao clicar no join (Figura 33) 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.
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.


Figura 33 - Opes de Join para montagem da interface de carga
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
na Figura 34.

Figura 34 - 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 35).
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.

Figura 35 - Editor de expresses
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
36), 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 36.

Figura 36 - 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 37
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 37 - 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 a
Figura 38. 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 38 - 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, conforme Figura 39.

Figura 39 - 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 40). 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 40), 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 40 - Configurando o comportamento dos campos
Concluda as configuraes vamos para a aba Fluxo. Na tela de Fluxo
(Figura 41) representada a forma como a ferramenta ir fazer a
execuo da Interface.

Figura 41 - 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 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.
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. 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 42 - 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 43).
Verificando a execuo (Figura 43), 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 43 percebe-se que o passo indicou ateno. Isto
aconteceu porque o ODI tentou dropar uma tabela temporria que ainda
no existia no banco.

Figura 43 - Execuo da Interface CLIENTES_IN
Clicando duas vezes sobre qualquer passo possvel ver o que executou,
quanto tempo levou para executar a carga, quantas linhas foram inseridas,
entre outros.
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 45). Todas as tabelas desta estrutura so provenientes da origem
FIREBIRD.
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 44). 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.

Figura 44 - Diagrama de PRODUTOS_IN
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 45). Esta estrutura se encontra presente devido necessidade
de carregar dados que se encontram em outro banco de dados (neste caso
o Firebird).


Figura 45 - 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 46). Notamos na Figura 46 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.



Figura 46 - Execuo de PRODUTOS_IN


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 47).

Figura 47 - 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 47). 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 48).
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.





Figura 48 - Utilizando filtro no ODI




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 49).

Figura 49 - Mapeamento para TEMPO_IN
Aqui temos uma novidade: no mapeamento da coluna DATA_DIA
utilizamos a funo TO_DATE do Oracle (Figura 50), 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.
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.

Figura 50 - Mapeamento utilizando procedimento TO_DATE



Desenvolvimento da Interface Carga Destino
FATO_VENDAS
Esta interface j tem uma lgica mais elaborada (Figura 51): estamos
buscando as informaes de duas origens:

Figura 51 - Diagrama de FATO_VENDAS_IN
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 51 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.
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 e arrastamos para
dentro do diagrama, conforme Figura 52.



Figura 52 - Adicionando as Interfaces ao Pacote
Podemos notar na Figura 52 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 53. 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 53 - Criando Fluxo de Execuo

O mesmo procedimento deve ser repetido para o restante das Interfaces
(Figura 54). 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 54 - Fluxo do Pacote
Observando a execuo da Interface no mdulo Operator (Figura 54)
podemos verificar que agora todas as nossas interfaces esto agrupadas
em uma nica execuo do pacote, evitando a execuo individual de
cada uma.
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 novos Procedimentos: 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.



Figura 55 - Execuo do Pacote



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 56).

Figura 56 - 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 57).

Figura 57 - Configurando a varivel
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 58).

Figura 58 - Histrico da Varivel
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 59).

Figura 59 - 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 60).
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.

Figura 60 - Inserindo novo procedimento
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 61.

Figura 61 - 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 61). 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 novaOpo 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 62).

Figura 62 - 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 63. 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 63 - 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 os Procedimentos no
nosso fluxo do pacote.



Na Figura 64 visualizamos o Fluxo de nossa carga.

Figura 64 - 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 64).
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 65) podemos notar na nossa
tabela de log (LOG_CARGA) o seguinte registro: A CARGA DA SESSAO
77001 TERMINOU COM SUCESSO!

Figura 65 - 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 66): A CARGA DA SESSAO 79001 TERMINOU
COM ERRO! VEJA OPERATOR PARA MAIS DETALHES.
Percebe-se que existe uma diferena entre a Figura 65, que teve a
execuo da carga aplicada com sucesso e a Figura 66 que resultou em
erro.


Figura 66 - Execuo com erro do pacote



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 67).

Figura 67 - 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 68.

Figura 68 - 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 tutorial 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.




Notas Explicativas
BUSINESS INTELLIGENCE
Tambm conhecido como BI, pode ser traduzido como inteligncia de
negcios, refere-se ao processo de coleta, organizao, anlise,
compartilhamento e monitoramento de informaes que oferecem
suporte gesto de negcios.

DER
Tambm conhecido como Diagrama de Entidade-Relacionamento, um
modelo em rede que descreve a diagramao dos dados armazenados de
um sistema em alto nvel de abstrao. Este modelo da nfase aos dados e
seus relacionamentos.

GRANTS
um comando padro SQL. O comando GRANT concede privilgios
especficos para um objeto (tabela, viso, seqncia, banco de dados,
funo, linguagem procedural, esquema ou espao de tabelas) para um ou
mais usurios ou grupos de usurios. Estes privilgios so adicionados ao
j concedidos, se existirem.

TABELA DUAL ORACLE
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.

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.

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.




Melhores Prticas
O Oracle Data Integrator (ODI) um produto muito poderoso quando
utilizado corretamente. Infelizmente, alguns erros podem levar a
resultados desastrosos em projetos de integrao de dados. Para tentar
mitigar esses problemas segue abaixo um resumo de 10 prticas que
podem ajudar nessa tarefa:


#1 Entenda e Use Corretamente os Contextos e a Topologia
Os Contextos e a Topologia so algumas das caractersticas mais
poderosas do ODI em tempo de Design e em tempo de Execuo de
artefatos e vrios ambientes diferentes.
No ODI, todos os desenvolvimentos bem como as execues so feitos
sobre uma Arquitetura Lgica (schemas lgicos, agentes lgicos), que se
resolvem em um dado Contexto para uma Arquitetura Fsica (fonte de
dados fsica/servidores de dados de destino/schemas e agentes de run-
time do ODI). Os Contextos nos permitem chavear a execuo dos
artefatos de um ambiente (Contexto) para outro.
Dois erros comuns que so cometidas em relao aos Contextos:
Esquecer de mapear as arquiteturas fsica e lgica para um
determinado Contexto. Isso um erro de administrao de
Topologia que leva a falhas de execuo em um dado Contexto.
Para evitar isso, garanta que todos os recursos lgicos esto
mapeados para recursos fsicos nesse Contexto.
Um grande erro forar o Contexto quando no necessrio. Nas
interfaces ou nas procedures, existem caixas de seleo com a lista
de Contextos, defina como default ou execution context. A no
ser que seja realmente necessrio forar o contexto por uma razo
funcional, deixe as caixas de seleo como estiverem. So raros os
casos onde realmente necessrio forar o Contexto.

Resumo
Garanta que o seu entendimento sobre Contextos e Topologia esteja
slido. Defina cuidadosamente a Topologia e o mapeamento dos
Contextos. Evite forar Contextos.


#2 Design Independente de Contexto
Em vrios tipos de artefatos do ODI (procedures, variveis, interfaces, etc.)
possvel adicionar cdigo SQL. Um erro muito comum inserir nomes de
objetos qualificados, como no exemplo abaixo que faz um DROP na tabela
TEMPO_001 num schema de staging:

DROP TABLE STAGING.TEMP_001

Isso um cdigo dependente de contexto. Se voc executa esse cdigo
em ambiente de produo onde a rea de staging se chama PRD_STG, seu
cdigo no funciona. Perceba que os nomes dos schemas so definidos na
Topologia, e os contextos acessam o schema correto dependendo do
contexto de execuo. Nesse caso a pergunta : Como usar isso no seu
cdigo?
Os Mtodos de Substituio (OdiRef API) existem para disponibilizar no
seu cdigo os metadados armazenados no ODI tornando o cdigo
independente de contexto. Sendo assim, eles garantem que o nome
qualificado da tabela em questo ser gerado de acordo com o contexto
onde o cdigo est sendo executado.
Utilizando os Mtodos de Substituio, o cdigo genrico ficaria assim:

DROP TABLE <%odiRef.getObjectName("L", "TEMP_001","W")%>.

Consulte o Substitution Methods Reference Guide para mais informaes
sobre como utilizar essa API. O expression editor tambm ajuda muito.

Resumo
To logo voc comece a digitar um nome de schema, nome de database,
nome de usurio ou qualquer informao referente um servidor ou
schema, pare, respire fundo e considere utilizar um Mtodo de
Substituio.


#3 Utilize Procedures Apenas Quando Necessrio
As procedures permitem a execuo de aes bem complexas, incluindo
comandos SQL. Alm disso, elas permitem a utilizao das conexes
source e target e ainda suportam binding. Isso significa que possvel
mover dados de um lado para o outro usando apenas procedures.
Os desenvolvedores que se sentem vontade com cdigo SQL ficam
sriamente tentados a escrever cdigo para fazer transformaes e
movimentao de dados ao invs de desenvolver interfaces.
Existem alguns problemas quanto isso:
Procedures contm cdigo manual que precisa sofrer manuteno
manualmente.
Procedures no mantm referncias com os outros artefatos ODI
como datastores, modelos, etc., fazendo com que a manuteno
seja muito mais complexa comparado s interfaces.
Procedures nunca devem ser utilizadas para mover ou transformar
dados, essas operaes devem ser feitas utilizando as intefaces.

Resumo
Quando voc comear a usar procedures para mover/transformar dados
provavelmente voc est fazendo uso inadequado das procedures e
deveria usar interfaces no lugar delas.


#4 Garantir Qualidade de Dados
s vezes o lder de projeto de integrao de dados no leva em conta a
qualidade dos dados. Isso um erro comum. O processo de integrao
pode estar movendo e transformando lixo e propagando esse lixo para
outras aplicaes.
O ODI permite que a qualidade dos dados seja garantida na fonte, (source)
utilizando static checks ou ento durante o processo de integrao antes
de gravar no destino (target) utilizando flow checks. Utilizando esses dois
mecanismos de checagem de dados possvel garantir a qualidade dos
dados.

Resumo
Garanta a qualidade dos dados usando os dois mtodos: static checks e
flow checks. Qualidade de dados no uma opo.


#5 Capturar Erros em Packages
Numa package possvel sequenciar passos de execuo. Cada passo em
uma package passvel de falha por qualquer razo (source ou target fora
do ar, muitos registros rejeitados em uma interface, etc.).
necessrio sempre procurar prever os possveis erros em cada passo da
package.

Resumo
As setas de OK (verdes) nas packages precisam existir e as setas KO
(vermelhas) so o que tornam a sua package prova de balas.


#6 Escolha o KM correto
A escolha do KM crtica ao desenvolver uma interface pois define quais
as features estaro disponveis e afeta tambm a performance de uma
package.
Alguns erros comuns na escolha do KM:
Comear com KMs complexos: Desenvolvedores iniciantes que ter
suas interfaces rodando rapidamente mas s vezes no levam em
conta todos os requisitos para utilizar um KM. Escolhendo, por
exemplo, um LKM de uma tecnologia especfica pode no funcionar
por uma configurao ou instalao incorreta do loader. Uma
ecolha mais segura seria comear usando KMs mais genricos
(como KMs de SQL) que funcionam na maioria dos casos. Depois de
desenvolver suas primeiras interfaces com esses KMs hora de
mudar para KMs mais especficos (estude as especificaes antes!).
Interfaces com excesso de engenharia: KMs com features extras
causam um custo extra de performance. Por exemplo, executar
inserts mais rpido do que executar updates incrementais. Se sua
interface deleta os dados no destino antes da integrao, utilizar
update incremental excesso de engenharia e causar perda de
performance. Utilize o KM que se encaixa adequadamente sua
necessidade.
De maneira similar, ativar ou desativar algumas fatures do KM pode
adicionar passos extras degradando a performance. As opes
default do KM so suficientes para executar o KM da forma como
ele foi fornecido. Aps executar o KM com as opes default
sempre bom revisar e checar se alguma opo pode ser alterada de
acordo com a sua necessidade. A descrio do KM sempre uma
boa opo de documentao para entender e otimizar a utilizao
do KM.

Resumo
Comece com os KMs mais simples, no se utilize de excesso de
engenharia com KMs complexos ou ativando opes complexas e preste
ateno s opes dos KMs.


#7 - Customize Seus KMs
Knowledge Modules (KMs) um poderoso framework utilizado em cada
ponto de integrao no ODI. Um grande nmero de KMs est disponvel
para utilizao. Eles suportam uma grande variedade de bancos de dados.
Mesmo no sendo necessrio na maiorias dos casos, alguns projetos
podem ter casos de uso ou requerimentos que solicitem uma
customizao de KM.
Ento, qual deve ser o momento de customizar um KM? A resposta : To
logo seja detectada uma operao que precisa ser executada em vrias
interfaces, por exemplo, rodar um comando no target para otimizao da
execuo.
No recomendado comear um KM partir de uma folha em branco. O
caminho recomendado encontrar um KM que esteja o mais prximo
possvel do comportamento desejado e partir dele, customizar de
acordo com a necessidade.

Resumo
Quando uma operao necessria em muitas interfaces, no tenha
medo de customizar um KM e criar o seu prprio KM baseado em algum j
existente.


#8 Organize o Seu Projeto no Incio
Gerenciamento e organizao podem no parecer pontos crticos quando
o assunto integrao de dados, mas so.
O ODI oferece muitas ferramentas que ajudam a organizar o
desenvolvimento e o ciclo de vida do projeto: perfis de segurana,
projetos de desenvolvimento, pastas, marcadores, versionamento,
importao/exportao, impresso da documentao em PDF, etc.
Revise e utilize todas essas ferramentas e features para gerenciar o
projeto. Defina a organizao do projeto, a padronizao de nomes e tudo
o que pode evitar o caos depois que o projetos tiver iniciado. Faa isso
desde o incio do projeto.

Resumo
Mantenha alta produtividade com o ODI, melhor ter regras de
organizao baseadas nas features do ODI para evitar o desenvolvimento
do caos.



#9 Controle os Repositrios
No ODI, um repositrio master pode ter vrios repositrios work. Tambm
possvel ter vrios repositrios master, cada um com seu grupo de
repositrios work. Cada repositrio tem um ID definido na hora da criao
do repositrio.
Bem, um repositrio no um documento. a fonte da verdade, a
referncia central entre os artefatos do ODI.
Alm disso, todo objeto identificado por um ID interno que depende do
ID do repositrio. Esse ID interno identifica unicamente um objeto e
utilizado pelo sistema de importao do ODI. Dois repositrios com o
mesmo ID possivemente contm objetos com o mesmo ID interno, o que
significa o mesmo objeto para o ODI. Transferir objetos entre esses
repositrios como copiar arquivos com o mesmo nome entre diretrios
e pode fazer com que o objeto seja substitudo.
Garanta que todos os repositorios sejam criados com IDs diferentes
(mesmo em sites diferentes), e defina uma documentao para o processo
de mover objetos entre repositrios utilizando import/export ou
versionamento.

Resumo
A multiplicao de repositorios deve ser feita sob estrito controle e
planejamento (especialmente quanto escolha do ID do repositrio), e o
gerenciamento de transferncias de objetos utilizando import/export ou
versionamento deve ser feito por vias formais.


#10 Cuidado Com o Contedo dos Repositrios
O ODI armazena todas as informaes num repositrio de metadados em
um banco de dados relacional. Sabendo disso muito tentador comear a
explorar as tabelas do repositrio para conseguir informaes mais
rpido.
O repositrio no implementa toda a lgica que existe na interface grfica
e tambm no implementa toda a lgica de negcios que existe no cdigo
Java. Construir, por exemplo, dashboards ou relatrios sobre o repositrio
aceitvel mas escrever dados ou alterar as informaes do repositrio
perigoso e deve ser deixado para operaes do suporte tcnico da Oracle.

Resumo
Voc faria isso no banco de dados do ERP da sua empresa? Tambm no
faa com o repositrio de metadados do ODI.









FAQ
O que o Oracle Data Integrator (ODI) ?
O ODI uma ferramenta que nos permite transforma o trabalho, muitas
vezes maante, da construo de processos E-LT (Extract, Load and
Tranform), em interfaces e fluxos de fcil desenvolvimento, manuteno e
visualizao.
Alm de padronizar e otimizar processos, o ODI capaz tambm 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.

Quais componentes formam o Oracle Data Integrator ?
O Oracle Data Integrator composto por:
Oracle Data Integrator + Topology Manager + Designer + Operator +
Agent + Security
Oracle Data Quality for Data Integrator
Oracle Data Profiling

O que o Oracle Data Integration Suite ?
O Oracle Data Integration Suite um conjunto de aplicativos de
gerenciamento de dados para criao, implantao e gerenciamento de
solues empresariais de integrao de dados:
Oracle Data Integrator Enterprise Edition
Oracle Data Relationship Management
Oracle Service Bus
Oracle BPEL
Oracle Weblogic Server

Opo de produtos adicionais:
Oracle Goldengate
Oracle Data Quality for Oracle Data Integrator
Oracle Data Profiling

Quais sistemas podem utilizar o ODI para extrair e carregar
dados ?
O Oracle Data Integrator pode se conectar nativamente com Oracle,
Sybase, MS-SQL Server, MySQL, LDAP, DB2, PostgreSQL, Netezza, ACCESS,
EXCEL, arquivos texto, etc.
Ele tambm pode se conectar a qualquer fonte de dados que tenha
suporte para JDBC, possvel at mesmo usar o servidor Oracle BI como
fonte de dados usando os drivers jdbc que esto no pacote BI Publisher.

Quais so Mdulos de Conhecimento ?
Mdulos de conhecimentos so conhecidos tambm como KMs
(Knowledge Modules). Os KMs so considerados o corao 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 Jounalizing 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 utilizado Web Services. Pode ser utilizando para
gerar e manipular dados via Web Services para arquiteturas SOA
(Service Oriented Architecture Arquitetura Orientada a Servios);

A minha infra-estrutura ODI requerem um banco de dados
Oracle ?
No, os repositrios ODI (Master e Work) pode ser instalado em qualquer
banco de dados RDBMS que suporta ANSI ISO89. Alguns dos bancos que
suportam so Oracle, Microsoft SQL Server, Sybase AS Enterprise, IBM
DB2 UDB, IBM DB2/40.


Onde posso obter mais informaes sobre ODI ?
http://www.oracle.com/us/products/middleware/data-integration/index.html

O ODI usado pela Oracle em seus produtos ?
Sim, existem vrios produtos que utilizam o Oracle Data Integrator, aqui
est uma lista de alguns deles:
Oracle Application Integration Architecture (AIA)
Oracle Agile products
Oracle Hyperion Financial Management
Oracle Hyperion Planning
Oracle Fusion Governance, Risk & Compliance
Oracle Business Activity Monitoring

As aplicaes do Oracle BI tambm usam o ODI como sua ferramenta
principal de E-LT.