Vous êtes sur la page 1sur 102

ODI

2012
Tutorial Series

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.

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 (ELT): 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 ORACLE_ESQUEMA_ORIGEM Desenvolvimento ORACLE_ESQUEMA_ORIGEM Teste ORACLE_ESQUEMA_ORIGEM Produo

Esquema Fsico BANCO_FISICO_DESENV BANCO_FISICO_TST 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. Devese 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 runtime 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.