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

Tutorial Series

Guia para Configuração e Desenvolvimento do Oracle Data Integrator

Introdução

A integração de dados em estruturas únicas e organizadas é um dos pilares estratégicos para o bom funcionamento de uma organização. Como matéria prima principal estas estruturas serão responsáveis por disponibilizar informações essenciais para o bom andamento de qualquer ramo empresarial e/ou organizacional. Fundamentadas na TI as empresas prezam pela uniformização de estruturas visando o retorno de informações rápidas, confiáveis e de qualidade. Os pressupostos da aplicação e estruturação de Business Intelligence (BI) em um projeto de sucesso esbarram no aspecto mais complexo da construção desta plataforma: o desenvolvimento dos processos de ETL.

A TI tem neste sentido uma missão muito grande: desenvolver e garantir os processos de ETL em tempo e custos hábeis 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 básicas de um sistema de vendas de mercadorias variadas. Este sistema armazena o cadastro básico de pessoas (clientes/classificação dos clientes e vendedores) e o cadastro de itens que são 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 através dos processos desenvolvidos e explicados neste tutorial.

Figura 2 - Modelo Estrela - DW Controle de Vendas

Tendo o objetivo estratégico 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 estão armazenadas em estruturas diferentes: as tabelas Cliente, TipoCliente, Venda e Vendedor estão alocados no banco de dados ORACLE; as tabelas Grupo, Item e ItVenda estão 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 irão realizar as cargas dos dados da origem (Sistema de Vendas da Figura 1) para o destino (DW da Figura 2). Para a realização do processo de

ETL vamos utilizar o Oracle Data Integrator (ODI). Todos os processos envolvendo a ferramenta de ETL, serão detalhados posteriormente.

Oracle Data Integrator

O ODI é a mais recente solução da gama de produtos Oracle Fusion Middleware, destinado a negócios de missão crítica, como BI e DW ou arquitetura orientada a serviços (SOA) e monitoração das atividades de negócios.

Com aspectos e objetivos diferentes do Oracle Warehouse Builder o Oracle Data Integrator assume características da ferramenta de integração de dados anteriormente associada à Empresa Sunopsis, e adiciona à mesma as funcionalidades específicas das ferramentas Oracle.

ODI foi incorporado pela Oracle a partir da aquisição 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 através da geração dinâmica de código. Sua plataforma cobre todos os requisitos de Integração de Dados como volumes elevados (utilização do SGBD para executar cargas massivas), sua arquitetura simples e orientada aos dados (utiliza SQL nativo)? facilita o desempenho dos processamentos em lote.

Ela utiliza uma abordagem diferente do processo de ETL Tradicional, o qual é denominado E-LT. Algumas particularidades da estrutura do ODI (E-LT):

Utiliza um projeto declarativo o qual dispensa codificação das instruções de atualização dos Bancos de Dados, sistemas de arquivos e chamadas de ferramentas externas;

Módulos de conhecimento permitem isolar as características próprias das diferentes origens e destinos tratando tudo, internamente, com SQL;

Diferentes repositórios compartilhados e vinculados permitem armazenar as informações sobre os metadados e sobre as execuções;

Agentes especializados organizam no tempo as atividades de execução das integrações.

Para melhor entendimento, no ETL Tradicional (Figura 3):

Extrai dados de diferentes origens; Transforma os dados em um Processador ETL de Middle-Tier

proprietário, ou seja, um servidor de ETL dedicado. Esta máquina seria responsável pelo recebimento das informações de origem e aplicaria o ETL nas mesmas. Depois de transformado os dados são carregados para o DW;

Carrega os dados transformados no destino.

Figura 3 - Processo Tradicional de ETL

Na estrutura ODI E-LT (Figura 4):

Arquitetura ETL Tradicional

Extract LoadTransform

Figura 4 - Processo E-LT do Oracle Data Integrator

Utiliza as capacidades do(s) Banco(s) de Dados para as transformações;

Conexão via JDBC. O agente de conexão da ferramenta ODI realiza a sua conexão com os diversos bancos de dados através do JDBC, o que garante facilidade de conexão, confiança e desempenho;

Sem hardware extra para o processo de ETL. A grande vantagem da ferramenta é de não necessitar de hardware para aplicação de ETL. Estes processos são sempre realizados nos bancos de dados de origem e destino.

Após conhecer um pouco da estrutura da ferramenta vamos iniciar o seu processo de instalação.

Arquitetura da Próxima Geração

“E-LT”“E-LT”LoadExtract

Transform Transform

Requisitos para a Instalação e Configuração

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 conterão as nossas tabelas de origem e de destino. Além disso, a estrutura da ferramenta necessita de dois esquemas de dados para armazenamento de tabelas e demais objetos que irão garantir seu perfeito funcionamento. Portanto, necessitaremos criar os seguintes esquemas:

ODI_MASTER_REP: Deve ser criado na base Oracle e conterá o Repositório Mestre do ODI. Este repositório contém as estruturas das diferentes tecnologias usadas no ODI, informações sobre segurança e versionamento dos projetos e modelos desenvolvidos;

ODI_WORK_REP: Deve ser criado na nossa base Oracle e conterá o Repositório de Trabalho do ODI. Este repositório contém todas as informações dos objetos desenvolvidos, como informações dos modelos de dados, projetos, interfaces e como eles são utilizados, seus valores e propriedades;

ESQUEMA_ORIGEM: Conterá as tabelas de origem Oracle que serão utilizadas;

ESQUEMA_DESTINO: Conterá as tabelas de destino Oracle que serão populadas;

ESQUEMA_TMP: Será utilizado para criar as tabelas temporárias do processo de ETL e será o esquema utilizado para conexão no banco Oracle de origem e de destino;

Existe também de um banco de dados Firebird onde estarão as tabelas de origem do Firebird.

Ambiente de Trabalho do ODI

É muito importante ressaltar que o ODI possui quatro grandes módulos:

Módulo Designer: Este módulo é o responsável pelo desenvolvimento em si. É neste módulo que criamos as interfaces, modelos, procedures, variáveis e todo o tipo de objeto que for necessário para o desenvolvimento da carga de dados;

Módulo Operator: Neste módulo encontramos a lista de todas as cargas executadas pelo usuário do ODI. É um visualizador de execução das cargas, onde é possível ver todos os passos executados, tempos de execução, número de linhas inseridas, deletadas, atualizadas, etc. Um desenvolvedor ODI trabalha sempre com o Designer em conjunto com o Operator, pois os processos de desenvolvimento são realizados com o Módulo Designer e o acompanhamento da execução da sua carga é feita no Módulo Operator;

Módulo Topology: Este módulo é responsável pela configuração das bases e objetos de origem e destino que participarão do processo de ETL. Aqui se definem os bancos de dados, assim como servidores para arquivos textos, XML, etc;

Módulo Security: Este módulo é responsável por guardar e permitir realizar a configuração de toda a parte de segurança, como por exemplo, criação de perfis de acesso, aplicação de restrições específicas, criação e visualização de objetos, etc. As permissões e/ou restrições podem ser aplicados a um usuário ou a um grupo de usuários.

Criando o Repositório Mestre (Master Repository)

A primeira tarefa de devemos fazer depois do ambiente instalado e disponível é a construção do Repositório Mestre. Para realizar esta tarefa devemos acessar a aplicação Master Repository Creation que se encontra no diretório Oracle/Oracle Data Integrator/Repository Management.

Figura 5 - Assistente para criação de repositório

No Master Repository Creation (Figura 5) devemos indicar qual esquema do Banco deverá receber as tabelas padrões e necessárias para o funcionamento do Repositório Mestre, ou seja, o esquema ODI_MASTER_REP. Para relembrar, neste esquema ficarão todas as

tabelas internas que o ODI utiliza para guardar informações sobre as estruturas das diferentes tecnologias usadas, informações sobre segurança e versionamento dos projetos e modelos desenvolvidos.

Como podemos perceber na Figura 5, a ferramenta permite que o seu Repositório Mestre esteja alocado em outro SGBD, diferente do padrão 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 repositório mestre, a senha deste esquema no banco e a tecnologia que ele pertence, que neste caso é ORACLE.

Para garantir a eficiência da instalação, é prudente observarmos na base do Repositório Mestre se as tabelas de configuração e suporte (prefixo SNP) foram criadas corretamente (Figura 6). Esta verificação pode ser feita através de um simples acesso ao SGBD escolhido para o armazenamento do Repositório.

Figura 6 - Tabelas de Configuração

Criando um Novo Usuário no ODI – Módulo Security Manager

Dando continuidade ao processo de configuração do ODI, vamos demonstrar através da utilização do Security Manager como proceder para realizar a criação de um usuário. Para não haver confusão, segue a explicação sobre as nomenclaturas que adotamos neste tutorial:

Login: Login de acesso ao ODI, ou seja, uma configuração que é criada e usada para acessar o ODI. Em outras palavras, é a conta de acesso ao ODI;

Usuário: Usuário do próprio ODI. O ODI nos permite criar diversos usuários, com diversos tipos de acesso e restrições diferentes. Podemos utilizar qualquer usuário para conectar em um determinado Login;

Esquema: Nome do esquema do banco de dados Oracle.

Este passo não é obrigatório, pois como o ODI já possui um usuário padrão para a conexão aos módulos (SUPERVISOR), nós poderíamos utilizá-lo. Porém, para demonstrar todas as funcionalidades da ferramenta, criaremos um usuário próprio para utilizá-lo durante este tutorial. Para isso, devemos acessar o Módulo Security Manager que se encontra no diretório Oracle/Oracle Data Integrator/Security Manager.

Na tela de login vamos criar um novo Login e associá-lo ao Repositório Master que criamos anteriormente.

Clicando no botão “Novo” vemos a tela de configuração para logar no módulo Security. Nesta tela deve-se informar o nome do novo Login, o usuário (do ODI), a senha deste usuário bem como as informações sobre a conexão ao repositório mestre. Deve-se notar, porém, que o usuário que deve ser informado na configuração da conexão do repositório mestre é o esquema do banco de dados que contém o Repositório Mestre do ODI e não um usuário do ODI. Por padrão, um usuário já é criado na instalação

do ODI. Este usuário é o SUPERVISOR com a senha SUNOPSIS (a Sunopsis era a empresa responsável pela ferramenta antes da aquisição da ORACLE), portanto, iremo utilizar este usuário para a nossa primeira conexão. A configuração completa pode ser vista na Figura 7.

Figura 7 - Configurando a conexão com o repositório

Ao entrar no módulo Security, clicaremos na aba “Usuários” e clicaremos com o botão direito do mouse na área branca demonstrada na Figura 8 para selecionar a opção “Inserir Usuário”.

Figura 8 - Inserindo novo usuário no ODI

Importante: quando um novo usuário é criado, o mesmo recebe os privilégios básicos. Na tela principal de criação do usuário temos a opção SUPERVISOR, na qual, se marcada, dará todas as permissões possíveis a este usuário. A configuração de cada usuário depende de sua utilidade dentro da estrutura do ODI. Se o mesmo não for SUPERVISOR é possível customizá-lo para as funções pretendidas. Estas permissões variam desde as permissões de criação de novos usuáriose grupos de acesso até permissões de execução de algum processo de carga. Para este tutorial criamos o usuário SQLMASTER com as permissões de SUPERVISOR, de acordo com a Figura 9.

Figura 9 - Configurando usuário do ODI

É importante salientar que a tela principal do Security Manager possui algumas abas (ver Figura 10) que contém os padrões de configuração não somente de usuários. Podemos configurar, por exemplo, perfis para cada usuário, as permissões de acesso para cada objeto do ODI, bem como as permissões de acesso e utilização para outros servidores ODI.

Figura 10 - Abas de configuração do Módulo Security Manager

Criando o Repositório de Trabalho (Work Repository)

O próximo passo é configurar e criar o Repositório de Trabalho. Esta configuração é feita através do Módulo Topology, acessando em Oracle/Oracle Data Integrator/Topology Manager.

Na tela do Topology Manager (Figura 11) podemos usar o login de conexão criado no passo anterior (Módulo Security). Para o usuário, podemos utilizar o usuário padrão do ODI (SUPERVISOR) ou podemos utilizar o nosso novo usuário criado no passo anterior (SQLMASTER).

Figura 11 - Tela de Login do Topology Manager

Dando continuidade à configuração do ambiente, vamos inserir um repositório de trabalho. Dentro do Módulo Topology, na aba Repositórios (Figura 12) iremos inserir um novo repositório de trabalho. Para isso basta clicarmos com o botão direito do mouse na opção Repositórios de Trabalho e escolher a opção “Inserir Repositório de Trabalho”.

Figura 12 - Inserindo novo repositório de trabalho

Na janela seguinte (aba Definição) devemos dar um nome ao novo Servidor de dados e escolher qual tecnologia utilizar (Oracle neste caso). Neste procedimento também devemos indicar o schema e a senha que iremos utilizar como Repositório 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 Repositório de Trabalho

Voltando para a aba Definição, testamos a conexão com o repositório de trabalho clicando na opção Testar, desta mesma janela. Ao escolher esta opção será necessário selecionar um Agente. Um agente no ODI representa um serviço Java que atua como um listener (representa um arquivo de conexão. Este arquivo é responsável pela conexão de qualquer Ferramenta com o Banco de dados Oracle) para uma determinada porta de conexão TCP\IP. Um agente permite a execução de sessões, execução de cenários, execução de interfaces, engenharia reversa de modelos dos bancos de dados para o ODI, entre outros. Inicialmente vamos selecionar a opção Local (sem Agente).

Após o Teste de conexão (clicando no botão OK da janela de aviso) devemos indicar um determinado número de identificação (ID) para o repositório que será utilizado pelo ODI e um nome para este repositório. Também devemos fazer a escolha do tipo de Repositório: Desenvolvimento ou Execução.

Para esclarecer, o Repositório de Desenvolvimento é um repositório completo do ODI, ou seja, contém todas as tabelas para guardar as execuções, interfaces, pacotes, procedures e demais objetos que são

criados no desenvolvimento. Um repositório de execução é um pouco menor, e contêm apenas as estruturas que guardam cenários compilados (prontos para execução), informações sobre execuções de carga, entre outros. Em resumo, um repositório de execução armazena somente informações para execuções de carga, sem os objetos do desenvolvimento. Para exemplificação, este tutorial irá utilizar um repositório de desenvolvimento (Figura 14).

Figura 14 - Configurando o repositório de trabalho

Depois de criado, podemos conferir no banco de dados as tabelas que foram geradas no esquema ODI_WORK_REP.

Configurando as Topologias – Módulo Topology Manager

Agora que temos os repositórios de trabalho e repositório mestre criados, precisamos configurar as nossas topologias, ou seja, especificar as fontes de dados (Data Servers) onde estarão as tabelas e arquivos de origem, suas arquiteturas físicas e lógicas e seus respectivos contextos. Cada uma das partes citadas e que compõem a estruturas de uma topologia será explicada neste tópico.

Para iniciarmos a explicação do módulo Topology Manager vamos abordar os três conceitos fundamentais na topologia do ODI.

Esquema Físico: O esquema físico é o objeto criado no ODI que contém as informações reais dos Data Servers, por exemplo, a tecnologia envolvida, as informações referentes ao driver que será utilizado, informações referentes ao usuário que será utilizado para conexão, entre outros;

Esquema Lógico: O esquema lógico é um objeto criado para representar logicamente um esquema físico. No desenvolvimento ODI, a referência a algum banco de dados acontece através do seu esquema lógico e não pelo físico. Esta característica é fundamentada na grande flexibilidade para o desenvolvimento, conforme será explicado a seguir;

Contexto: O contexto é o responsável por fazer a ligação entre o esquema lógico e o esquema físico.

Para facilitar o entendimento vamos imaginar um cenário com três bancos de dados: Teste, Desenvolvimento e Produção. Para cada banco de dados criamos um esquema físico, pois fisicamente os mesmos são diferentes (estruturas, processamento, usuários de conexão, etc.).

Neste sentido, vamos ter apenas um esquema lógico para as três estruturas físicas que iremos chamar de ORACLE_ESQUEMA_ORIGEM, fazendo a ligação entre os respectivos contextos, conforme Tabela 1.

Esquema Lógico Contexto Esquema FísicoORACLE_ESQUEMA_ORIGEM Desenvolvimento BANCO_FISICO_DESENVORACLE_ESQUEMA_ORIGEM Teste BANCO_FISICO_TSTORACLE_ESQUEMA_ORIGEM Produção BANCO_FISICO_PROD

Tabela 1 - Abas de configuração do Módulo Security Manager

Como podemos observar neste caso, temos três contextos, para três bancos fisicamente distintos, mas com apenas um equema lógico. Com isso, o desenvolvimento de nossas cargas irá utilizar um determinado esquema lógico manipulando as informações de um determinado banco físico 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 Físico BANCO_FISICO_DESENV.

Outra grande vantagem e uma característica importante do ODI é a fácil reestruturação 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 alterações que precisam ser realizadas estão relacionadas à criação de um novo esquema físico, fazer a troca do apontamento do esquema lógico ORACLE_ESQUEMA_ORIGEM no contexto de Desenvolvimento para este novo esquema físico. Com esta flexibilidade não é preciso nenhuma modificação nas estruturas já desenvolvidas, pois estaremos referenciando as mesmas a um esquema lógico e não a um banco de dados ou algum recurso físico. As vantagens deste tipo de flexibilidade são inúmeros e muito práticas no dia a dia, e ficarão mais claras quando explicarmos o desenvolvimento dos ETLs.

Criando o Esquema Físico – Módulo Topology

O primeiro passo para a continuidade deste tutorial é cria e configurar o Esquema Físico que apontará para o banco de dados de origem.

Relembrando: na estrutura Topology, mais especificamente na aba Arquitetura Física, exsitem várias tecnologias o Oracle nos permite criar, novas, mas não é o caso neste momento, pois inicialmente iremos utilizar a tecnologia ORACLE. Existem dois conceitos básicos para melhorar o entendimento na continuidade da configuração da Arquitetura Física. O primeiro conceito é o Servidor de Dados. Este objeto contém as informações sobre qual driver será utilizado para conexão, qual URL e qual usuário será utilizado para a conexão com o banco de dados.

Esse passo é fundamental na configuração de uma arquitetura física, pois devemos ter em mente que o usuário que fará a conexão aos nossos esquemas físicos precisa necessariamente ter os grants necessários para “enxergar” as tabelas dos outros esquemas que teremos que configurar. Posteriormente, mais precisamente quando iniciarmos o desenvolvimento em si esta explanação ficará mais clara, porém é importante ressaltar que todas as vezes que o ODI se conectar neste Servidor de Dados, ele utilizará este usuário de conexão para ler as tabelas dos esquemas.

O outro conceito se refere ao próprio Esquema Físico. Assim como o conceito anterior, este também contém duas informações 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 criação dos objetos temporários são 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 Módulo Topology. Na aba Arquitetura são apresentadas várias tecnologias distintas para a criação do Servidor de Dados. Vamos selecionar a tecnologia ORACLE, clicar com o botão direito do mouse e escolher a opção “Inserir Servidor de Dados”.

Uma nova janela de configuração será aberta. Na aba JDBC devemos inserir as informações necessárias para a conexão com o driver. É importante salientar que o ODI nos fornece apenas um template para a conexão 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 Definição devemos indicar qual esquema será utilizado para ser nosso Esquema de Conexão. Iremos utilizar neste tutorial, o ESQUEMA_TEMP, e este será o esquema que deverá ter os grants necessários de select nas tabelas de origem. A lacuna referente à Instância / dblink (Servidor de Dados) só é preenchida quando trabalhamos com DBLINKS no ODI, que não é o caso do estudo desenvolvido. As demais abas da janela de configuração não necessitam de intervenção para configuração, pois é automatizada pelo ODI.

Figura 15 - Configuração do Driver do JDBC do ODI

Portanto, podemos clicar em OK para seguir nossa configuração. Neste momento uma nova janela irá abrir. Nesta tela vamos criar o Esquema Físico, conforme Figura 16.

Figura 16 - Configurando novo Servidor de Dados

A Figura 16 nos traz muitas informações importantes. Nossa primeira tarefa é setar o esquema que irá conter nossas tabelas de origem, escolhemos o ESQUEMA_ORIGEM. Neste ponto podemos também setar o esquema de trabalho (que irá criar os objetos temporários necessário para o processo de ETL).

Conforme explicado anteriormente, o ODI possui a característica ELT, a qual iremos utilizar neste momento, ou seja, a transformação pode ocorrer tanto na origem, quanto no destino, sem a necessidade de um hardware proprietário fazendo as transformações no meio do processo.

Para este tutoria, foi decidido que não vamos utilizar o nosso esquema de origem para criar os objetos temporários, fazendo assim, todo este processo no banco de dados de destino. Nesta mesma tela podemos também verificar informações sobre os prefixos de tabela de trabalho e jornalização. Estes dois conceitos serão retomados no momento que criarmos o esquema de destino (Sessão Configurando os Destinos). Podemos também colocar regras de nomeação do Esquema Físico a ser criado. Para o exemplo deixaremos com os valores padrões.

Concluída as específicações da inserção de nosso Servidor de Dados, podemos clicar em OK para finalizar. Logo após esta ação o ODI apresentará uma informação explicando que não existe ainda nenhum contexto especificado e com isso não 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 Módulo Topology Manager.

De acordo com a Figura 17, podemos verificar que já existe um contexto criado denominado “Global”. Este contexto é criado de forma padrão pelo ODI. Ele poderia ser utilizado para os nossos propósitos, mas para o estudo criaremos um contexto próprio. Desta forma, basta clicarmos com o botão direito do mouse e escolher a opção “Inserir Contexto”.

Figura 17 - Criando um novo Contexto

No próximo passo devemos nomear o contexto que será utilizado para executar as cargas no ambiente de desenvolvimento. Dentro da estrutura do ODI é possível criar N contextos, como contextos voltados para Teste, Produção, etc. Dentre outras configurações, ainda é possível 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 padrões.

Criado o contexto, é hora de definir o esquema lógico. Na aba “Arquitetura Lógica” e posteriormente na estrutura Tecnologia Oracle, devemos clicar com o botão direito do mouse e escolher a opção “Inserir Esquema Lógico”.

Vamos nomear o Esquema Lógico de ORACLE_ORIGEM. Neste passo já vamos aproveitar para setar no nosso contexto de Desenvolvimento o Esquema Físico 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 é responsável pelo apontamento para a pasta padrão 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 Física e selecionarmos a tecnologia FILE. Com o botão direito do mouse escolhemos a opção “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 físico, devemos indicar o diretório que se encontram os arquivos (Esquema) e o diretório do Esquema de Trabalho, onde ficarão os possíveis arquivos de log gerados pelo processo de carga.

Criado o Esquema Físico devemos criar o Esquema Lógico na tecnologia “File” e posteriormente apontar este esquema criado para o Esquema Físico, 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 Física pode-se notar que não existe uma tecnologia para o “Firebird”. O ODI permite que o usuário crie uma nova tecnologia, mas este é um passo mais avançado para ser visto em outra oportunidade. Na lista de tecnologias padrões existe uma denominada Interbase. Como sabemos, o Firebird se originou do Interbase, portanto, no que diz respeito à tecnologia no ODI, as mesmas são perfeitamente compatíveis. 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 não possui um driver de conexão para o Firebird, portanto, o próximo passo é adicionar este driver à ferramenta.

Para realizarmos a conexão do ODI com o Firebird vamos utilizar o Jaybird. É possível 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 instalação do ODI, mais precisamente na estrutura ...\oracledi\oracledi\drivers.

Neste passo devemos ter muito cuidado. Vamos fazer um procedimento que consiste na criação de um objeto “SnpDriver” e um objeto “SnpUrl” no ODI. Estes objetoso permitirão escolher através de um “combobox”, o driver e URL do Jaybird.

Passos para Configuração do Driver:

1. Feche todos os módulos do ODI;2. Na pasta “...\oracledi\oracledi\lib” faça o backup do arquivo

“sunopsis.zip”. Iremos modificar um arquivo que compõe esta estrutura e um backup para estes casos sempre é útil;

3. Extraia para algum diretório o arquivo “sunopsis.zip”. Na pasta descompactada, procure pelo arquivo DriverRefV3.xml (geralmente se encontra na estrutura “sunopsis\com\sunopsis\res\”). Este arquivo contém todas as informações sobre os drivers disponíveis para seleção no combobox do ODI;

4. Abra o arquivo e insira os dois novos objetos descritos abaixo, porém, muito cuidado! Deve ser respeitado o local da inserção destes objetos no arquivo, observando as regras do XML. Os objetos devem ser adicionados embaixo da tag <SunopsisExport> e antes de </SunopsisExport> e também não devem interferir em nenhum outro objeto descrito no XML, ou seja, os objetos devem ficar entre as tags <SunopsisExport> e não dentro de alguma outra tag.

5. Para facilitar o trabalho, copie todo o código da Listagem 1 para o correto funcionamento da conexão com o Firebird;

6. Após a modificação do arquivo DriverRefV3.xml devemos salva-lo e compactar novamente a estrutura originalmente denominada “sunopsis.zip”;

7. Feito esta alteração, devemos susbstituir a estrutura “sunopsis.zip” original pela estrutura “sunopsis.zip” alterada.

Realizada a configuração, vamos testá-la para validar seu funcionamento. Acessamos novamente o Módulo Topology. Na tecnologia Interbase, clicamos com o botão direito e escolhemos a opção “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 incluímos anteriormente.

Devemos então fazer a configuração na aba JDBC, colocando o Driver JDBC e a sua URL. Um exemplo pode ser visto na Firgura 19.

Figura 19 - Configuração do JDBC para o novo Servidor de Dados

Na aba Definição, deve-se nomear o Servidor de Dados, informar o usuário e a senha de conexão no banco informado na URL do JDBC e fazer o teste de conexão. Se a mensagem “CONEXÃO BEM SUCEDIDA” aparecer é porque nossas configurações funcionaram e estamos prontos para a próxima etapa.

A utilização do Firebird exige uma particularidade: é preciso fazer uma configuração específica na Tecnologia Interbase para que a estrutura funcione corretamente. Para isso, temos que dar dois cliques sobre a Tecnologia Interbase, na aba “Definição” e na estrutura “Manipulação de Dados” selecionarmos a opção “Selecionar” e “Onde” (Figura 20).

Figura 20 - Configurando o Interbase para utilização da Cláusula Where

Esta alteração é necessária, pois a estrutura do Interbase por padrão no ODI não suporta o uso da cláusula “WHERE”. Sem esta alteração o ODI não permitiria o uso de JOINS entre as origens do Firebird.

Para finalizar, é necessário criar um Esquema Lógico, seguindo os mesmos passos descritos anteriormente na criação do Esquema Lógico da origem Oracle, porém, colocando o Esquema Lógico na tecnologia Interbase. Na criação do Esquema Lógico associamos o contexto de Desenvolvimento ao Esquema Físico “SERVIDOR_FIREBIRD_Default”.

Finalmente temos todas as nossas Origens Configuradas.

Configurando o(s) Destino(s)

A próxima 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, também ORACLE estão alocados na mesma estrutura física (em esquemas diferentes). Neste sentido temos duas opções: podemos criar um Data Server novo para o Destino ou criar apenas um novo Esquema Físico no Data Server que já temos criado.

As duas soluções possíveis terão o mesmo efeito e, portanto a escolha por alguma delas está voltada à organização de sua estrutura de trabalho. Nesta situação criaremos apenas o Esquema Fisico no próprio Data Server existente. É importante notar que como estamos utilizando o mesmo Data Server, o nosso usuário de conexão (ESQUEMA_TMP configurado no Data Server da origem Oracle) será utilizado tanto para a Origem quanto para o Destino. Assim, o usuário ESQUEMA_TMP deve ter grants tanto para as tabelas de origem como para as tabelas de destino. Então, no Servidor ORACLE clicamos com o botão direito do mouse e escolhemos o opção “Inserir Esquema Físico”.

Na aba “Definição” (Figura 21) devemos setar a opção Esquema como ESQUEMA_DESTINO e Esquema de Trabalho como ESQUEMA_TMP. O ESQUEMA_TMP também será utilizado para armazenar os objetos temporários criados durante o processo de ETL.

Figura 21 - Configurando o Esquema de Destino Oracle

No decorrer do estudo quando partirmos para a construção 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 é responsável pela criação e armazenamento dos objetos temporários 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 Físico.

Podemos perceber na Figura 21 que existem prefixos para as tabelas de trabalho e de jornalização. A jornalização é o conceito de manutenção de

registros diários. O propósito da mesma é garantir a integridade dos metadados.

Estas tabelas (trabalho e jornalização) são 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 são gravados nesta tabela que é criada por default como E$_<NOME_DA_TABELA>;

C$: Criada quando estamos buscando os dados de um banco diferente do destino. O ODI cria esta tabela, popula com as informações da origem e depois utiliza a mesma no processo de ETL. Criada por padrão como C$_<NOME_DA_TABELA>;

I$: Criada durante o processo de ETL. Nesta tabela são resolvidos todos os relacionamentos entre as tabelas envolvidas no ETL, e depois de pronta é utilizada para popular a tabela de destino. Criada por padrão como I$_<NOME_DA_TABELA>;

J$,JV$ e T$: São tabelas criadas quando se está trabalhando com o conceito de jornalização.

Pode-se notar também que utilizamos o mesmo ESQUEMA_TMP como Esquema de Conexão na configuração do Data Server. Fizemos isso por praticidade e segurança, pois o usuário de conexão tem que ter grants para todos os objetos que estarão envolvidos no processo de ETL, até mesmo os objetos de trabalho (temporários). Como não sabemos quais serão os objetos temporários criados durante o processo de ETL, o usuário padrão para conexão teria que ter todos os privilégios para estas tabelas, o que representaria uma falha de segurança na estrutura.

A maneira de resolver este problema é configurar o esquema de trabalho como sendo o mesmo de conexão, pois este será o “dono” dos objetos temporários, não necessitando de privilégios específicos para estes objetos.

Para finalizar, devemos criar o Esquema Lógico e apontá-lo para o contexto de Desenvolvimento. O procedimento para inserir o Esquema Lógico segue os mesmos padrões dos demais. Clicando sobre a tecnologia

ORACLE com o botão direito do mouse e selecionando a opção “Inserir Esquema Lógico”. Feito isso, basta nomearmos o Esquema Lógico (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 módulo Designer. A primeira tarefa que temos é criar um novo projeto. Na aba Projetos do Módulo Designer devemos clicar com o botão direito e escolher a opção “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 são disponibilizados em estruturas de pastas para uma melhor organização. Porém, uma pasta sempre contém um conjunto de três tipos de objetos: Pacotes, Interfaces e Procedimentos.

Pacotes: são os objetos que servirão para modelar o nosso fluxo no processo de ETL. No pacote são armazenados os objetos utilizados e a ligação entre eles. Depois que finalizamos a construção de um pacote, geramos a partir dele, um Cenário, que é a versão “compilada” do nosso pacote. Façamos uma analogia a um programa “comum”. Os pacotes

contêm os arquivos fonte do programa e os cenários são os executáveis gerados a partir dos arquivos fonte;

Interfaces: são os objetos que realmente fazem o trabalho de ETL. Nas interfaces são definidas as tabelas de origem, de destino e quais as regras serão aplicadas no processo de ETL;

Procedimentos: como o nome indica, são objetos em que são escritos qualquer tipo de procedimento “extra” que se faça necessário no processo de ETL. Podemos criar procedimentos que contenham vários tipos de códigos, 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:

Variáveis: são utilizadas no ODI como qualquer variável é utilizada em um programa. Elas armazenam um valor que é utilizado e modificado durante o processo de ETL;

Seqüências: o ODI nos dá a possibilidade de criação de Sequences, iguais a uma Sequence de Banco de Dados. Criamos seqüências no ODI quando a Tecnologia que estamos utilizando não nos permite ter uma Sequence própria no banco;

Dentro da hierarquia do “PROJETO_ETL” ainda temos:

Variáveis: são utilizadas no ODI como qualquer variável é utilizada em um programa. Elas armazenam um valor que é utilizado e modificado durante o processo de ETL;

Seqüências: o ODI nos dá a possibilidade de criação de Sequences, iguais a uma Sequence de Banco de Dados. Criamos seqüências no ODI quando a Tecnologia que estamos utilizando não nos permite ter uma Sequence própria no banco;

Funções do Usuário: estas funções nos dão a possibilidade de criação de funções que irão ser utilizadas várias vezes no processo de ETL. Por exemplo, se temos que fazer um determinado tratamento em uma string ou uma data, podemos criar uma função para não ter que escrever a

mesma função várias vezes nas nossas Interfaces;zes nas nossas Interfaces;Módulos de Conhecimento: são conhecidos também como KMs (Knowledge Modules). Os KMs são considerados os “corações” do processo de ETL no ODI. Eles são os responsáveis por todas as tarefas executadas nos processos de ETL.

Para melhorar o entendimento vamos detalhar cada tipo de Módulo de Conhecimento (KM):

RKM - Reverse Knowledge Module (Engenharia Reversa): é o responsável por fazer uma reversa “customizada” dos armazenamentos de dados no ODI. Por exemplo: se existir uma situação em que se necessite fazer algum tipo de procedimento extra ao reverter um modelo de dados, podemos utilizar RKMs específicos e não o padrão para esta tarefa. O ODI faz reversas de tabelas automaticamente, mas podemos customizar estas reversas com um RKM;

LKM - Load Knowledge Module (Carga): é o responsável 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 (Verificação): é o responsável por realizar as validações dos dados no processo de ETL. No ODI podemos criar check constraints próprias contendo alguma regra de negócio (por exemplo, valor não pode ser negativo) ou podemos validar FKs de banco antes de inserir os dados na tabela de destino, ou ainda, durante o próprio processo de ETL, podemos verificar dados not null, etc. O CKM é o responsável por executar todas estas verificações;

IKM - Integration Knowledge Module (Integração): é o responsável pela integração 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 (Documentação): é o responsável por fazer a jornalização de dados quando se trabalha com este tipo de

conceito. Pode ser usado, por exemplo, para se fazer replicação de bancos de dados;

SKM - Service Knowledge Modules (Serviço): é 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 Serviços);

Marcadores: são utilizados para colocar marcadores nos objetos criados no ODI. Servem para a organização do projeto.

Nesta fase de nosso projeto ainda não temos nenhum KM. A cada novo projeto é fundamental a escolha de quais KMs iremos utilizar. Para o nosso projeto vamos importar os KMs necessários, que são dois:

LKM: para carregar os dados de origens diferentes do nosso destino; IKM: para fazer a integração efetiva dos nossos dados para o destino;

No Módulo Designer, acessamos a aba “Projetos” e clicamos com o botão direito sobre a opção “Importar” e escolhemos a opção “Importar Knowledge Modules...”. Devemos então informar o diretório onde se encontram os KMs a serem importados. Originalmente os KMs que fazem parte da instalação do ODI estão na pasta “oracledi\oracledi\impexp”. Várias opções serão apresentadas e devemos escolher as que se encaixam ao Projeto.

Os KMs que vamos utilizar no nosso projeto são:

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

LKM SQL to ORACLE: Carrega dados de um banco de dados genérico 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 não existem na tabela são inseridas, linhas que existem sofrem atualização.

Quando os KMs já estiverem importados podemos ter uma definição do que cada um faz, bastando clicar duas vezes sobre o mesmo, surgindo assim uma tela com a descrição e a funcionalidade do mesmo. Para este processo de ETL não importamos todos os KMs, pois isso dificultaria a seleção dos mesmos no momento do desenvolvimento devido à grande quantidade de KMs existentes. Portanto, é uma boa prática importar para o seu projeto apenas os KMs que serão realmente utilizados, a fim de trabalhar com um ambiente mais “limpo” e com menos chances de selecionar um KM errado. Em relação aos KMs importados para o nosso projeto, suas funcionalidades ficarão 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 definição de nosso Modelo de Dados, e neste ponto o entendimento de dois conceitos são 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 Lógico. 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 estarão os nossos armazenamentos de dados, ou seja, nossas tabelas do banco de dados.

Portanto, dentro do Módulo Designer, mais precisamente na aba Modelos, vamos criar pastas para melhor organização. 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 botão direito sobre a pasta Destinos e selecionar a opção “Inserir Pasta de Modelos”. Vamos inserir a pasta “ORACLE”, onde ficarão as tabelas de destino da tecnologia ORACLE, e repetimos a tarefa para as Origens, criando três pastas: “FILE”, “FIREBIRD” e “ORACLE”, onde ficarão 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 botão direito sobre a Pasta de Modelo ORACLE que acabamos de criar e escolher a opção “Inserir Modelo”.

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

O nome de nosso Modelo é auto-explicativo (MODELO_ORACLE_ORIGEM). Ainda nas configurações 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 também 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 configuração poderíamos também aplicar alguma máscara de filtro para que no momento da reversa o ODI selecionasse apenas os objetos que se adequassem a esta determinada máscara.

A próxima aba de configuração é a “Reversão 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 estão alocadas no banco de dados. Após selecionar as tabelas podemos clicar na opção “Aplicar”, e após em “Reverter”. Uma mensagem de confirmação será exibida: “Deseja fazer engenharia reversa neste modelo antes de fechar esta janela?” Se anteriormente já clicamos na opção “Reverter” podemos clicar em “Não” nesta confirmação. Depois de “revertido”, teremos as tabelas da nossa origem ORACLE no ODI.

Figura 23 - Executando a Reversão do Modelo de Origem

Inserindo o Modelo de Dados Firebird – Origem

Devemos agora inserir o Modelo de Dados também para o Firebird. Faremos o mesmo processo detalhado anteriormente apenas alterando a Tecnologia escolhida. Selecionamos a Tecnologia Interbase que foi a selecionada para utilização com o Firebird no momento da criação da Topologia.

Conforme a Figura 24, selecionamos a tecnologia Interbase e o Esquema Lógico FIREBIRD_ORIGEM.

Figura 24 - Criando modelo de Origem do Firebird

Após selecionar o contexto e quais objetos queremos importar na aba Reverter (novamente selecionamos Tabelas), e quais as tabelas que importaremos na aba Reversão Seletiva, podemos clicar na opção “Aplicar” e após em “Reverter”. Se o procedimento for correto, as tabelas da Origem Firebird serão importadas.

Inserindo o Modelo de Dados File – Origem

Terminada a inclusão dos Modelos de Dados ORACLE e Firebird vamos partir para a inclusão do Modelo de Dados do tipo FILE. Para esta tecnologia existem algumas particularidades que devem ser observadas. Vamos proceder com a criação do modelo de forma normal seguindo os padrões da inclusão da Tecnologia ORACLE. Nomeamos o modelo para MODELO_FILE_ORIGEM e selecionamos a Tecnologia FILE. Também associamos neste ponto o Esquema Lógico 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 não apresentou nenhuma mensagem de aviso ou confirmação em relação à reversa no momento que nós criamos o modelo. Isso acontece porque a Tecnologia FILE não segue necessariamente um padrão. Podemos ter arquivos com delimitações por caracteres, como “;” (ponto e vírgula) ou então “|” (pipe) como podemos ter arquivos que não são delimitados mas sim fixos por um determinado valor em cada coluna. Todos estes padrões 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 Repositório de Trabalho do ODI, e clicar com o botão direito no “MODELO_FILE_ORIGEM” que se encontra dentro da pasta FILE. Devemos escolher a opção “Inserir Armazenamento de Dados”.

Na janela que será exibida, na aba “Definição”, 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 informações referentes à dimensão tempo de nosso Data Warehouse. Depois de feita a seleção do arquivo, vamos para a aba “Arquivos” (Figura 25), onde devemos informar se o arquivo possui ou não delimitação. No nosso caso, escolhemos que ele é “Delimitado”. Neste ponto informamos que o caractere separador de campos do arquivo

dtempo.txt é o “;” (ponto e vírgula). Também nesta estrutura de configuração podemos informar se o arquivo possui cabeçalho 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 início do arquivo e seria desprezada.

Outra opção 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 padrões de separadores de registros se referem às possíveis quebras de linhas do arquivo. Também devemos configurar o delimitador de texto que neste caso é ‘ (aspas simples), ou seja, as strings do arquivo texto são envoltos por aspas simples. Com esta configuração o ODI irá considerar apenas o conteúdo “interno” da string ignorando as aspas. Neste ponto também podemos indicar qual separador decimal os nossos valores estão utilizando, o que não se aplica neste caso.

Figura 25 - Criando o armazenamento de dados da origem TXT

Finalizando o processo de configuração devemos clicar na aba “Colunas” e selecionar a opção reverter. Neste momento o ODI busca as informações da aba “arquivos” e separa em colunas automaticamente (Figura 26).

Por padrão as colunas ficam com nomes C1, C2, C..., mas podem ser renomeadas conforme necessidade e\ou organização.

Figura 26 - Coluna do modelo de origem TXT

Inserindo o Modelo de Dados Oracle – Destino

Vamos agora proceder com a criação do modelo de destino seguindo os padrões da inclusão 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 Definição devemos selecionar a tecnologia Oracle e o esquema lógico ORACLE_DESTINO. Na aba Reverter selecionamos o contexto de Desenvolvimento e o tipo de armazenamento de dados a ser revertido (Tabela), e na aba Reversão Seletiva escolhemos as tabelas contidas no script. Depois deste passo estamos prontos para iniciar o desenvolvimento das interfaces.

Figura 27 - Criação do Modelo de destino Oracle

Iniciando o Desenvolvimento das Interfaces

Neste ponto iniciamos efetivamente o desenvolvimento ETL. Vamos desenvolver as interfaces, procedimentos, variáveis e pacotes, que serão os objetos utilizados para a realização 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 Módulo Designer. Nesta aba vamos alterar o nome da “Primeira Pasta” para “DW”. Esta alteração pode ser feita dando duplo clique sobre a estrutura.

Vamos iniciar carregando as dimensões do DW. A primeira interface a ser desenvolvida deverá fazer a carga de dados para a Dimensão Cliente. Ainda na aba Projetos devemos expandir a pasta DW e clicar com o botão direito sobre Interfaces selecionando a opção “Inserir Interface”, conforme Figura 28.

Figura 28 - Inserindo uma nova interface

Vamos desenvolver a Interface para contemplar o ETL da Dimensão Cliente e, portanto, nomeamos a Interface como CLIENTES_IN. Neste passo também devemos selecionar o contexto de otimização, que serve para o ODI montar o fluxo de execução (Figura 29).

Figura 29 - Criando a Interface de Clientes

Para melhorar a explicação sobre o contexto de otimização, 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 estão no mesmo banco não seria necessária a utilização de um LKM (o LKM busca os dados de data servers diferentes), pois o IKM (módulo de integração) conseguiria fazer sozinho a integração de dados, otimizando assim o código, pois diminuiria os “passos” do mesmo. Porém, se estes mesmos esquemas, em um contexto de Produção, estiverem em servidores fisicamente separados, o ODI necessitaria utilizar um LKM, pois a sua origem está fisicamente separada do destino.

Se a interface fosse construída com o contexto de otimização menos “fragmentado” (como o de desenvolvimento neste caso) teríamos um problema ao rodar esta interface em produção, pois o código gerado não contemplaria um LKM.

Portanto, ao selecionar um contexto de otimização, 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 opção que podemos selecionar nesta etapa (Figura 30) esta relacionada à área de Stagging, que pode ser diferente do destino. Por padrão, a área de Stagging é sempre no destino, ou seja, os objetos temporários necessários ao processo de ETL serão criados no Esquema de Trabalho do destino setado anteriormente, no momento da criação da topologia (ESQUEMA_TMP do banco ORACLE).

Neste ponto poderíamos selecionar qualquer esquema para ser a Stagging, mas vamos mantê-lo no Esquema de Trabalho do destino. Após inserir esta nova Interface devemos acessar a aba “Diagrama”. Nesta estrutura serão armazenados todos os relacionamentos, regras e mapeamentos de origem e destino que deverão 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. Após 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 automático dos campos. Como na nossa estrutura a nomenclatura das colunas são iguais, o mapeamento iria funcionar sem problemas. Na prática de desenvolvimento de um projeto, o mapeamento automático não é recomendado. Na grande maioria dos casos, as nomenclaturas de origem e destino são diferentes e\ou existirá alguma regra de transformação. Desta forma o ODI pode mapear campos para os locais errados, gerando re-trabalho para mapeá-los novamente. Portanto, selecione “Não” e vamos mapear manualmente. Porém, 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 informações 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 não acontecesse de forma automática teríamos 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 não acontece.

Figura 32 - Montando os Joins entre as tabelas de Origem

Podemos notar ao clicar no join (Figura 33) que várias opções são apresentadas (todas são 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 construção da DIM_CLIENTE utilizamos um inner join. Esta tarefa avisa que retornará “Todas as linhas emparelhadas pela condição de união entre CLIENTE e TIPOCLI”.

IMPORTANTE: Neste ponto temos a opção 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 opção é na origem, o ODI fará o join na origem e trará apenas o resultado daquele join para o esquema de trabalho.

Figura 33 - Opções de Join para montagem da interface de carga

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

Para mapear um campo no ODI o processo é relativamente simples. Deve-se clicar no campo de destino que se deseja mapear, clicar no campo de origem a ser mapeado, arrastar e soltar na área branca “Implementação”, 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 têm um ID próprio e único que é a PK da tabela. Estas PKs devem ser populadas com um número ú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 “lápis” para abrir o editor de expressões (Figura 35).

O editor de expressões auxilia a montar as expressões que estarão 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 não é recomendado para grandes projetos. Exemplo: o esquema principal está nomeado como ESQUEMA_DESTINO em desenvolvimento, mas em outro ambiente (produção) o esquema pode variar de nome.

Figura 35 - Editor de expressões

Esta alteração faria com que a Interface não executasse de maneira correta. A solução deste problema seria utilizar uma função própria do ODI que retorna o nome do esquema em que a interface esta sendo executada.

Esta função pode ser encontrada dentro do Editor de Expressões (Figura 36), mais precisamente em Funções OdiRef. O ODI possui várias funções muito úteis. A lista completa destas funções podem ser encontradas no manual de referência da ferramenta.

Para este exemplo em vez de ter uma sequence com o esquema prefixado (ESQUEMA_DESTINO.SEQ_DESTINOS) substituiríamos pela função denominada getShemaName, Figura 36.

Figura 36 - Editor de Expressões

Após 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 não se encontra na tela), um alvo e uma chave.

Figura 37 - Mapeamento completo para DIM_CLIENTE

Cada símbolo 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 não 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 própria chave primária (PK) da tabela, mas, como veremos neste

caso, podemos modificar a chave para fazer com que o ODI resolva o ETL da maneira que nós desejamos.

Podemos trocar o local que o campo será executado (resolvido) clicando na coluna que desejamos modificar e em seguida na opção “Executar em:”, selecionando o local escolhido. No caso da sequence, iremos especificar que irá executar no ambiente de destino. Esta troca de diretório tem um motivo: a sequence não deve ser avaliada durante o processo de ETL e deve ser executada somente no momento da inserção do novo registro no destino. Se não for estruturada desta maneira causará um erro na sua execução.

Outra tarefa necessária é a alteração 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 executássemos dez vezes a carga, os clientes estariam dez vezes duplicados na tabela de destino.

O correto para a tabela Cliente é existir apenas um código por cliente, ou seja, precisamos que a coluna CDCLI seja a chave natural (NK - Natural Key). Para o ODI levar em consideração a coluna CDCLI como chave e não a atual PK ID_CLIENTE devemos proceder com a alteração conforme a Figura 38. Ao clicar sobre a tabela de destino DIM_CLIENTE percebemos que na opção “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 opção “sem definição” e agora temos a liberdade de selecionar a chave que necessitamos. Selecionamos então 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 funções definidas pelo usuário (UD - User Defined). No nosso caso, todos os campos por padrão estão marcados como “Inserir” e “Atualizar”. Porém, no caso da coluna ID_CLIENTE devemos desmarcar a opção “Atualizar” (Figura 40), pois a sequence não pode participar do passo de update gerado pelo KM sob o risco de erros serem gerados na execução. Este processo ficará mais claro no momento da execução da interface que será explicado a seguir.

Figura 40 - Configurando o comportamento dos campos

Concluída as configurações vamos para a aba “Fluxo”. Na tela de Fluxo (Figura 41) é representada a forma como a ferramenta irá fazer a execução da Interface.

Figura 41 - Fluxo de trabalho do ODI

Para este caso o ODI demonstra apenas um único exemplo com a utilização 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 composição de um LKM responsável 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 construção 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 padrão é 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 não existe no destino o processo faz a inserção da mesma de forma automática. Se esta chave já existe o processo apenas faz o Update nas colunas selecionadas com a opção “Atualizar”.Podemos notar também que o KM vem com várias opções de valores padrões. Ao clicar sobre cada opção, ao lado, apresenta-se a sua descrição. Para este trabalho iremos modificar apenas a opção “Flow Control” que devemos mudar para opção “não” (Figura 20). Quando a opção descrita estiver selecionada como “Sim” o ODI irá invocar o CKM (Validações - Ver explicação sobre CKM neste artigo) selecionado e fará a verificação dos dados durante o processo de ETL. Como não criamos nenhuma validação para esta tabela, podemos retirar a opção de “Flow Control” desta interface.Para realizar a execução da interface basta clicar sobre o botão “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 nível de registro, que indica o grau de informações que deve ser gerado no log do ODI, que podemos deixar o valor padrão 5.

Figura 42 - Execução de uma Interface

Durante a execução da Interface podemos acessar a “Lista de sessões” do módulo Operator e acompanhar o processo de execução das cargas (Figura 43).

Verificando a execução (Figura 43), podemos observar os passos criados pelos KMs do ODI. Reparamos que a primeira palavra escrita é “Integração”. 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, porém a execução continua normalmente. Ícones em vermelho significam erros que interrompem a execução da carga, que não foi o caso.

No exemplo da Figura 43 percebe-se que o passo indicou “atenção”. Isto aconteceu porque o ODI tentou dropar uma tabela temporária que ainda não existia no banco.

Figura 43 - Execução da Interface CLIENTES_IN

Clicando duas vezes sobre qualquer passo é possível 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 veríamos novamente os mesmos onze passos, mas no processo nenhuma nova linha seria inserida. Como esta Interface é incremental, ela carrega apenas as linhas que ainda não foram carregadas e faz a atualização de linhas quando a mesma não existir.

DICA

Para compreender melhor como funcionam as configurações feitas no ODI, tente marcar a opção “Atualização” no campo ID_CLIENTE que é carregada juntamente com a sequence ou mude o local de execução de “Destino” para “Stagging” e compare os passos de uma execução e outra. No começo parece complicado, mas depois que aprendemos os “pequenos truques” da ferramenta verificamos que o ODI é uma poderosa e flexível ferramenta para processos ETL.

Desenvolvimento da Interface – Carga Destino DIM_PRODUTO

O próximo 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 são provenientes da origem FIREBIRD.

Importante: Devemos efetuar a modificação da coluna ID_PRODUTO para ser executada no banco de destino (Ícone do “Alvo” da coluna ID_PRODUTO na Figura 44). Também devemos desmarcar a opção “Atualizar” para este atributo. Outra modificação 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 “lápis”, 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 relação 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 relação ao IKM selecionamos o IKM Oracle Incremental Update não esquecendo que neste devemos modificar a opção de “Flow Control” para “Não”.

Ao executar esta Interface os resultados podem ser consultados na “lista de sessões” do Operator (veja a Figura 46). Notamos na Figura 46 que o número de passos de execuções aumentou para dezessete e que temos descrições das ações como “Carregando” e “Integração”. Os passos com as descrições carregando se referem aos passos gerados pelo LKM e os passos com “Integração” se referem aos passos gerados pelo IKM.

Figura 46 - Execução 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 execução da sequence no alvo, desmarcamos a opção de “Atualizar” e trocamos a chave para CDVEND (Figura 47).

Figura 47 - Mapeamento de VENDEDORES_IN

Em alguns casos a utilização de um filtro para os dados se torna necessária e pode auxiliar no processo de carga. Para exemplificar a utilização 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. Após 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 estratégia incremental (IKM Oracle Incremental Update). Modificamos a opção do “Flow Control” para “Não” e executamos a interface.

Figura 48 - Utilizando filtro no ODI

Desenvolvimento da Interface – Carga Destino DIM_TEMPO

Para a carga da dimensão 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 função 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 não iremos utilizar a sequence do banco e sim a própria 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 opção “Flow Control” igual a “Não”.

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 lógica mais elaborada (Figura 51): estamos buscando as informações 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.

Além dessas origens ainda fazemos joins com as nossas tabelas de Dimensões, pois precisamos buscar os IDs que foram gravados anteriormente nas nossas interfaces. Os joins que são realizados são 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 reforçar o exemplo de utilização): 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 também a opção “Flow Control” no IKM para “Não”. Como padrão, podemos executar a interface e ver o seu resultado no Operator.

Desenvolvimento do Pacote para Carga de Dados

Após executar individualmente cada Interface podemos consultar as tabelas de destino e conferir que todas estão carregadas. Mesmo com a eficiência comprovada para cada carga este não é um modo prático para execução de cargas. Em um grande projeto, por exemplo, estas Interfaces não poderiam ser enviadas para outros ambientes, pois não são estruturas compiladas para execução em outros ambientes. Neste sentido necessitamos criar Pacotes para controlar o fluxo e criar cenários compilados para que a execução em outros ambientes seja garantida.

Para inserir um novo Pacote, no projeto DW, clique com o botão direito sobre a opção “Pacotes” e em seguida selecione “Inserir Pacote”. Na aba “Definição” nomeamos o pacote. É na aba “Diagrama” que será desenvolvido o fluxo do processo de ETL. Nesta mesma tela pode-se encontrar várias funcionalidades (em forma de botões) que podem ser detalhados com o simples “passar” do mouse sobre cada um.

A caixa de ferramentas do ODI contém diversos objetos que podem ser incluídos no fluxo ETL do nosso pacote. Entre eles temos objetos de envio de e-mail, execução de comandos do sistema operacional, processo de espera de eventos (tempo limite ou espera de algum registro em alguma tabela específica), manipulação 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 é possível clicar em cima do objeto escolhido com o botão direito e escolher a opção “Primeira etapa”. Se executássemos o pacote neste momento somente a interface CLIENTES_IN seria executada, pois ainda não criamos o fluxo de execução completo do pacote.

Para criar este fluxo devemos clicar no botão “ok” (Etapa seguinte ao êxito) que contém uma flecha verde, na barra superior. Após este passo deve-se clicar sobre o objeto de origem e arrastar até o objeto de destino, conforme Figura 53. Temos também o botão “ko” (Próxima etapa ao falhar) que contém 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 Execução

O mesmo procedimento deve ser repetido para o restante das Interfaces (Figura 54). Após isso, executaremos o pacote clicando no botão “Executar” (canto inferior direito).

OBSERVAÇÃO: Para manipular o local dos objetos no pacote, escolha o primeiro botão (o cursor branco - “Escolha livre”) na barra superior.

Figura 54 - Fluxo do Pacote

Observando a execução da Interface no módulo Operator (Figura 54) podemos verificar que agora todas as nossas interfaces estão agrupadas em uma única execução do pacote, evitando a execução individual de cada uma.

Outra tarefa importante pode ser realizada neste Pacote. Vamos implementar um LOG personalizado para guardar as informações importantes relacionadas a execução deste Pacote. Para isso usaremos a tabela LOG_CARGA que conterá o ID da sessão do ODI correspondente à execução e uma descrição informando se todos os processos da carga executaram com sucesso ou com erro. Para completar esta demanda vamos precisar criar uma Variável e dois novos Procedimentos: um para inserir os dados e outro para retornar o ID da sessão. Para completar esta tarefa precisamos entender melhor o que é uma Variável e um Procedimento no ODI.

Figura 55 - Execução do Pacote

Criando Variáveis

Para criar uma Variável devemos acessar o projeto PROJETO_ETL, na aba projetos, clicar com o botão direito sobre a opção “Variáveis” e escolher “Inserir Variável”. Na aba “Definição”, colocamos o nome da variável, escolhemos o seu tipo de dado e a sua Ação (Figura 56).

Figura 56 - Criação de Variáveis no ODI

Para a opção Ação, temos as seguintes opções:

Historiar: O ODI manterá na aba “Histórico” todos os valores que a variável já recebeu durante as suas execuções;

Valor mais recente: O ODI manterá na aba “Histórico” o último valor que a variável recebeu durante as suas execuções;

Não persistente: O ODI não manterá nenhum histórico.

A Ação escolhida neste caso é a “Não persistente”, pois não temos a necessidade de manter histórico para esta tarefa. Na aba “Atualizando” vamos adicionar um comando DDL que retornará o valor para a variável, ou seja, o comando é executado no banco de dados e o resultado é atribuído para a variável. Para este exemplo utilizamos um select simples na tabela “dual” (que retornará apenas um registro) utilizando a função do

ODI <%=odiRef.getSession("SESS_NO")%>, que retornará o número da sessão.

No combobox “Esquema” escolhemos em qual esquema queremos executar esta DDL, que neste caso é o ORACLE_DESTINO (Figura 57).

Figura 57 - Configurando a variável

O teste para verificar se o procedimento foi realizado com sucesso pode ser feito ao clicar no botão Renovar. Se a Ação da variável é “Historiar” ou “Valor mais recente”, podemos ver o valor da variável na aba Histórico (Figura 58).

Figura 58 - Histórico da Variável

Nosso próximo passo é adicionar a variável no pacote e setarmos a mesma para ser executada como demanda inicial, pois queremos ter o número da sessão para gravar no log antes de começar o processo de ETL. Quando clicamos sobre a variável, podemos observar as suas propriedades, entre elas o “Tipo”, que pode ser setado de várias formas (o ícone no pacote e suas propriedades mudarão conforme o que for setado). As opções de Tipo são:

Declarar variável: é utilizado para receber um valor passado por parâmetro quando executamos um cenário compilado;

Avaliar variável: é utilizado para fazer um teste lógico (=, <>, >, <, etc.) sobre o valor da variável. Se o teste lógico retornar verdadeiro, o fluxo segue para a próxima etapa seguinte ao êxito (flecha verde). Se retornar falso, o fluxo segue a próxima etapa ao falhar (flecha vermelha);

Renovar variável: executa o select colocado na aba “Atualizando” da variável, atribuindo o resultado do select à variável (o select deve retornar apenas um valor, ou um erro ocorrerá);

Definir variável: atribui manualmente o valor desejado à variável.

Para o nosso pacote, escolheremos o tipo Renovar variável, pois queremos que a variável contenha o valor retornado do select da aba “Atualizando”. Isto faz com que tenhamos o valor da sessão do ODI atribuída a nossa variável, com o objetivo de gravarmos posteriormente no log (Figura 59).

Figura 59 - Tipos de Variáveis

Criando Procedimentos

Para criar Procedimentos no ODI devemos acessar a pasta DW, clicar com o botão direito sobre a opção “Procedimentos” e depois em “Inserir Procedimento” (Figura 60).

Na aba “Definição” devemos apenas colocar o nome do nosso Procedimento. Já na aba “Detalhes”, devemos clicar no primeiro botão “Adicionar” na parte superior. Após este passo será aberta uma janela onde deve ser inserido o comando que queremos que este Procedimento execute. Percebemos aqui o nível de flexibilidade de trabalhar com o ODI. Nesta tela que foi apresentada é possível 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 são muito maiores, podendo ter blocos inteiros de PL-SQL com uma lógica 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( )%>: Função que retorna o nome do esquema do banco de dados referente ao esquema lógico escolhido (ORACLE_DESTINO). Isso se faz necessário pois podemos ter nomes de esquemas diferentes em contextos diferentes. Em desenvolvimento podemos ter ORACLE_DESTINO e em produção podemos ter ORACLE_DESTINO_PROD. Assim, não podemos deixar o nome do esquema fixo, pois em produção geraria um erro;

#SESSAO_ODI: Nome da variável que criamos que conterá o número da sessão do ODI, prefixada com #. No momento de execução, a ferramenta procurará e substituirá as variáveis que ele encontrar no código pelo seu valor no momento da execução. Devemos ter apenas cuidado para que a variável contenha algum valor, caso contrário um erro será gerado.

Podemos clicar em OK para fechar esta janela (Figura 61). Observe que poderíamos incluir quantos comandos fossem necessários, bastando apenas clicar no botão “Adicionar”. Poderíamos inclusive executar comandos de N tecnologias diferentes em ordem seqüencial. Nossa próxima tarefa é realizar a inclusão de outro procedimento. Para

criar procedimentos no ODI devemos acessar novamente a pasta DW, clicar com o botão direito sobre a opção “Procedimentos” e clicar em “Inserir Procedimento”. Para esta estrutura basta nomeá-la e clicar em OK, pois iremos inserir uma novaOpção para este Procedimento. Opções são parâmetros que são repassados para o Procedimento. Para inserirmos uma Opção clicamos com o botão direito sobre o Procedimento e em seguida “Inserir Opção”.

Será inserida uma Opção para indicar ao Procedimento se desejamos gravar uma mensagem de sucesso ou erro. Uma Opção pode ser de três tipos:

Marcar Caixa: Opção do tipo checkbox, onde é possível escolher entre as opções SIM/NÃO;

Valor: Recebe um valor alfanumérico com capacidade máxima de 250 caracteres;

Texto: Recebe um valor alfanumérico com capacidade ilimitada. O acesso a este tipo de opção é mais lenta do que o tipo Valor.

Escolheremos o tipo “Valor” (ver Figura 62).

Figura 62 - Criando uma nova Opção

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 parâmetro 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 parâmetro através da Opção 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 atualização da variável 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 botão “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 botão “ok”. A última tarefa necessária para execução do pacote é setar a Opção 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 “Opções” 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 (também UPDATE_LOG_pr), onde adicionamos o STATUS para ‘S´ (SUCESSO). Pronto, agora podemos executar o nosso pacote clicando no botão 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 - Execução com sucesso do pacote

Neste ponto podemos simular um erro para verificar a diferença com o processo de carga anterior. Para esta simulação vamos dropar a tabela FATO_VENDAS do banco de destino. Executando o cenário 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 diferença entre a Figura 65, que teve a execução da carga aplicada com sucesso e a Figura 66 que resultou em erro.

Figura 66 - Execução com erro do pacote

Gerando um Cenário

Agora que temos nosso pacote completo, falta apenas criar um cenário, que nada mais é do que a versão “compilada” do pacote. É este cenário que será mandado para outros ambientes (testes, produção, etc.) e que será utilizado para rodar as cargas. Para gerar um cenário, basta clicar com o botão direito sobre o pacote e depois em “Gerar cenário” (Figura 67).

Figura 67 - Gerando um cenário

Quando geramos um cenário, temos a opção de colocar uma versão para o mesmo e também a opção de dizer quais são as variáveis que o cenário receberá de entrada. Neste exemplo não temos variáveis de entrada, logo, podemos desmarcá-las.

Pronto! Temos nosso cenário criado, como pode ser visto na Figura 68.

Figura 68 - Cenário Criado

Este cenário funciona como qualquer programa compilado, onde não sofre mais alterações. É possível então fazer modificações nas nossas interfaces, modificar o fluxo do pacote, etc., porém este cenário continuará com a versão compilada anteriormente. Podemos, no entanto, recriar o cenário para refletir as modificações que por ventura foram realizadas, bastando para isso clicar com o botão direito sobre o cenário gerado e escolher a opção “Regenerar...”.

Conclusão

Vimos neste tutorial a facilidade e a versatilidade do ODI para construir processos de ETL. Sem muito esforço, 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 Módulos de Conhecimento (KMs) nos facilitam a manutenção e a padronização dos códigos, tornando assim o ODI uma grande ferramenta para o desenvolvimento dos processos de ETL.

Notas Explicativas

BUSINESS INTELLIGENCE

Também conhecido como BI, pode ser traduzido como inteligência de negócios, refere-se ao processo de coleta, organização, análise, compartilhamento e monitoramento de informações que oferecem suporte à gestão de negócios.

DER

Também conhecido como Diagrama de Entidade-Relacionamento, é um modelo em rede que descreve a diagramação dos dados armazenados de um sistema em alto nível de abstração. Este modelo da ênfase aos dados e seus relacionamentos.

GRANTS

É um comando padrão SQL. O comando GRANT concede privilégios específicos para um objeto (tabela, visão, seqüência, banco de dados, função, linguagem procedural, esquema ou espaço de tabelas) para um ou mais usuários ou grupos de usuários. Estes privilégios são adicionados ao já concedidos, se existirem.

TABELA DUAL ORACLE

Tabela “dual” Oracle: A tabela DUAL é uma pequena tabela no dicionário de dados que o Oracle ou qualquer usuário 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 usuários. 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, porém, se utilizarmos qualquer tabela “povoada” nesta consulta, teremos uma série de inconvenientes, como estratégia de acesso ou eventual utilização de índices, etc.

DDL – Linguagem de Definição de Dados

A DDL permite ao usuário definir tabelas novas e elementos associados. A maioria dos bancos de dados de SQL comerciais têm extensões proprietárias no DDL. Os comandos básicos da DDL são 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 usuário 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 Manipulação 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 usuário especificar uma query como uma descrição 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 é possível gerar de forma automática uma seqüência de números, usando o comando sequence. Isto pode ser bastante útil quando se pretende criar um número único para uma chave primária.

Melhores Práticas

O Oracle Data Integrator (ODI) é um produto muito poderoso quando utilizado corretamente. Infelizmente, alguns erros podem levar a resultados desastrosos em projetos de integração de dados. Para tentar mitigar esses problemas segue abaixo um resumo de 10 práticas que podem ajudar nessa tarefa:

#1 – Entenda e Use Corretamente os Contextos e a Topologia

Os Contextos e a Topologia são algumas das características mais poderosas do ODI em tempo de Design e em tempo de Execução de artefatos e vários ambientes diferentes.

No ODI, todos os desenvolvimentos bem como as execuções são feitos sobre uma Arquitetura Lógica (schemas lógicos, agentes lógicos), que se resolvem em um dado Contexto para uma Arquitetura Física (fonte de dados física/servidores de dados de destino/schemas e agentes de run-time do ODI). Os Contextos nos permitem chavear a execução dos artefatos de um ambiente (Contexto) para outro.

Dois erros comuns que são cometidas em relação aos Contextos:

Esquecer de mapear as arquiteturas física e lógica para um determinado Contexto. Isso é um erro de administração de Topologia que leva a falhas de execução em um dado Contexto. Para evitar isso, garanta que todos os recursos lógicos estão mapeados para recursos físicos nesse Contexto.

Um grande erro é forçar o Contexto quando não é necessário. Nas interfaces ou nas procedures, existem caixas de seleção com a lista de Contextos, defina como “default” ou “execution context”. A não ser que seja realmente necessário forçar o contexto por uma razão funcional, deixe as caixas de seleção como estiverem. São raros os casos onde é realmente necessário forçar o Contexto.

Resumo

Garanta que o seu entendimento sobre Contextos e Topologia esteja sólido. Defina cuidadosamente a Topologia e o mapeamento dos Contextos. Evite forçar Contextos.

#2 – Design Independente de Contexto

Em vários tipos de artefatos do ODI (procedures, variáveis, interfaces, etc.) é possível adicionar código 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 “código dependente de contexto”. Se você executa esse código em ambiente de produção onde a área de staging se chama PRD_STG, seu código não funciona. Perceba que os nomes dos schemas são definidos na Topologia, e os contextos acessam o schema correto dependendo do contexto de execução. Nesse caso a pergunta é: Como usar isso no seu código?

Os Métodos de Substituição (OdiRef API) existem para disponibilizar no seu código os metadados armazenados no ODI tornando o código independente de contexto. Sendo assim, eles garantem que o nome qualificado da tabela em questão será gerado de acordo com o contexto onde o código está sendo executado.

Utilizando os Métodos de Substituição, o código genérico ficaria assim:

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

Consulte o Substitution Methods Reference Guide para mais informações sobre como utilizar essa API. O “expression editor” também ajuda muito.

Resumo

Tão logo você comece a digitar um nome de schema, nome de database, nome de usuário ou qualquer informação referente à um servidor ou schema, pare, respire fundo e considere utilizar um Método de Substituição.

#3 – Utilize Procedures Apenas Quando Necessário

As procedures permitem a execução de ações bem complexas, incluindo comandos SQL. Além disso, elas permitem a utilização das conexões source e target e ainda suportam binding. Isso significa que é possível mover dados de um lado para o outro usando apenas procedures.

Os desenvolvedores que se sentem à vontade com código SQL ficam sériamente tentados a escrever código para fazer transformações e movimentação de dados ao invés de desenvolver interfaces.

Existem alguns problemas quanto à isso:

Procedures contém código manual que precisa sofrer manutenção manualmente.

Procedures não mantém referências com os outros artefatos ODI como datastores, modelos, etc., fazendo com que a manutenção seja muito mais complexa comparado às interfaces.

Procedures nunca devem ser utilizadas para mover ou transformar dados, essas operações devem ser feitas utilizando as intefaces.

Resumo

Quando você começar 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 líder de projeto de integração de dados não leva em conta a qualidade dos dados. Isso é um erro comum. O processo de integração pode estar movendo e transformando lixo e propagando esse lixo para outras aplicações.

O ODI permite que a qualidade dos dados seja garantida na fonte, (source) utilizando static checks ou então durante o processo de integração antes de gravar no destino (target) utilizando flow checks. Utilizando esses dois mecanismos de checagem de dados é possível garantir a qualidade dos dados.

Resumo

Garanta a qualidade dos dados usando os dois métodos: static checks e flow checks. Qualidade de dados não é uma opção.

#5 – Capturar Erros em Packages

Numa package é possível sequenciar passos de execução. Cada passo em uma package é passível de falha por qualquer razão (source ou target fora do ar, muitos registros rejeitados em uma interface, etc.).

É necessário sempre procurar prever os possíveis erros em cada passo da package.

Resumo

As setas de “OK” (verdes) nas packages precisam existir e as setas “KO” (vermelhas) são o que tornam a sua package à prova de balas.

#6 – Escolha o KM correto

A escolha do KM é crítica ao desenvolver uma interface pois define quais as features estarão disponíveis e afeta também a performance de uma package.

Alguns erros comuns na escolha do KM:

Começar com KM’s complexos: Desenvolvedores iniciantes que ter suas interfaces rodando rapidamente mas às vezes não levam em conta todos os requisitos para utilizar um KM. Escolhendo, por exemplo, um LKM de uma tecnologia específica pode não funcionar por uma configuração ou instalação incorreta do loader. Uma ecolha mais segura seria começar usando KM’s mais genéricos (como KM’s de SQL) que funcionam na maioria dos casos. Depois de desenvolver suas primeiras interfaces com esses KM’s é hora de mudar para KM’s mais específicos (estude as especificações antes!).

Interfaces com excesso de engenharia: KM’s com features extras causam um custo extra de performance. Por exemplo, executar inserts é mais rápido do que executar updates incrementais. Se sua interface deleta os dados no destino antes da integração, 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 opções default do KM são suficientes para executar o KM da forma como ele foi fornecido. Após executar o KM com as opções default é sempre bom revisar e checar se alguma opção pode ser alterada de acordo com a sua necessidade. A descrição do KM é sempre uma boa opção de documentação para entender e otimizar a utilização do KM.

Resumo

Comece com os KM’s mais simples, não se utilize de “excesso de engenharia” com KM’s complexos ou ativando opções complexas e preste atenção às opções dos KM’s.

#7 - Customize Seus KMs

Knowledge Modules (KMs) é um poderoso framework utilizado em cada ponto de integração no ODI. Um grande número de KM’s está disponível para utilização. Eles suportam uma grande variedade de bancos de dados. Mesmo não sendo necessário na maiorias dos casos, alguns projetos podem ter casos de uso ou requerimentos que solicitem uma customização de KM.

Então, qual deve ser o momento de customizar um KM? A resposta é: Tão logo seja detectada uma operação que precisa ser executada em várias interfaces, por exemplo, rodar um comando no target para otimização da execução.

Não é recomendado começar um KM à partir de uma folha em branco. O caminho recomendado é encontrar um KM que esteja o mais próximo possível do comportamento desejado e à partir dele, customizar de acordo com a necessidade.

Resumo

Quando uma operação é necessária em muitas interfaces, não tenha medo de customizar um KM e criar o seu próprio KM baseado em algum já existente.

#8 – Organize o Seu Projeto no Início

Gerenciamento e organização podem não parecer pontos críticos quando o assunto é integração de dados, mas são.

O ODI oferece muitas ferramentas que ajudam a organizar o desenvolvimento e o ciclo de vida do projeto: perfis de segurança, projetos de desenvolvimento, pastas, marcadores, versionamento, importação/exportação, impressão da documentação em PDF, etc.

Revise e utilize todas essas ferramentas e features para gerenciar o projeto. Defina a organização do projeto, a padronização de nomes e tudo o que pode evitar o caos depois que o projetos tiver iniciado. Faça isso desde o início do projeto.

Resumo

Mantenha alta produtividade com o ODI, é melhor ter regras de organização baseadas nas features do ODI para evitar o desenvolvimento do caos.

#9 – Controle os Repositórios

No ODI, um repositório master pode ter vários repositórios work. Também é possível ter vários repositórios master, cada um com seu grupo de repositórios work. Cada repositório tem um ID definido na hora da criação do repositório.

Bem, um repositório não é um documento. É “a fonte da verdade”, é a referência central entre os artefatos do ODI.

Além disso, todo objeto é identificado por um ID interno que depende do ID do repositório. Esse ID interno identifica unicamente um objeto e é utilizado pelo sistema de importação do ODI. Dois repositórios com o mesmo ID possivemente contém objetos com o mesmo ID interno, o que significa o mesmo objeto para o ODI. Transferir objetos entre esses repositórios é como copiar arquivos com o mesmo nome entre diretórios e pode fazer com que o objeto seja substituído.

Garanta que todos os repositorios sejam criados com ID’s diferentes (mesmo em sites diferentes), e defina uma documentação para o processo de mover objetos entre repositórios utilizando import/export ou versionamento.

Resumo

A multiplicação de repositorios deve ser feita sob estrito controle e planejamento (especialmente quanto à escolha do ID do repositório), e o gerenciamento de transferências de objetos utilizando import/export ou versionamento deve ser feito por vias formais.

#10 – Cuidado Com o Conteúdo dos Repositórios

O ODI armazena todas as informações num repositório de metadados em um banco de dados relacional. Sabendo disso é muito tentador começar a explorar as tabelas do repositório para conseguir informações “mais rápido”.

O repositório não implementa toda a lógica que existe na interface gráfica e também não implementa toda a lógica de negócios que existe no código Java. Construir, por exemplo, dashboards ou relatórios sobre o repositório é aceitável mas escrever dados ou alterar as informações do repositório é perigoso e deve ser deixado para operações do suporte técnico da Oracle.

Resumo

Você faria isso no banco de dados do ERP da sua empresa? Também não faça com o repositório de metadados do ODI.

FAQ

O que é o Oracle Data Integrator (ODI) ?

O ODI é uma ferramenta que nos permite transforma o trabalho, muitas vezes maçante, da construção de processos E-LT (Extract, Load and Tranform), em interfaces e fluxos de fácil desenvolvimento, manutenção e visualização.

Além de padronizar e otimizar processos, o ODI é capaz também de fazer a integração de diferentes tecnologias e bancos de dados em um único lugar, facilitando o trabalho de qualquer projeto que necessite fazer integração 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 criação, implantação e gerenciamento de soluções empresariais de integração de dados:

Oracle Data Integrator Enterprise Edition Oracle Data Relationship Management Oracle Service Bus Oracle BPEL Oracle Weblogic Server

Opção 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 também pode se conectar a qualquer fonte de dados que tenha suporte para JDBC, é possível até mesmo usar o servidor Oracle BI como fonte de dados usando os drivers jdbc que estão no pacote BI Publisher.

Quais são Módulos de Conhecimento ?

Módulos de conhecimentos são conhecidos também como KMs (Knowledge Modules). Os KMs são considerados o “coração” do processo de ETL no ODI. Eles são os responsáveis por todas as tarefas executadas nos processos de ETL. Para melhorar o entendimento vamos detalhar cada tipo de Módulo de Conhecimento (KM):

RKM – Reverse Knowledge Module (Engenharia Reversa): é o responsável por fazer uma reversa “customizada” dos armazenamentos de dados no ODI. Por exemplo: se existir uma situação em que se necessite fazer algum tipo de procedimento extra ao reverter um modelo de dados, podemos utilizar RKMs específicos e não o padrão para esta tarefa. O ODI faz reversas de tabelas automaticamente, mas podemos customizar estas reversas com um RKM;

LKM – Load Knowledge Module (Carga): é o responsável 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 (Verificação): é o responsável por realizar as validações dos dados no processo de ETL. No ODI podemos criar check constraints próprias contendo alguma regra de negócio (por exemplo, valor não pode ser negativo) ou podemos validar FKs de banco antes de inserir os dados na tabela de destino, ou ainda, durante o próprio processo de ETL, podemos verificar dados not null, etc. O CKM é o responsável por executar todas estas verificações;

IKM – Integration Knowledge Module (Integração): é o responsável pela integração 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 (Documentação): é o responsável por fazer a jornalização de dados quando se trabalha com este tipo de conceito. Pode ser usado, por exemplo, para se fazer replicação de bancos de dados;

SKM – Service Knowledge Modules (Serviço): é 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 Serviços);

A minha infra-estrutura ODI requerem um banco de dados Oracle ?

Não, os repositórios ODI (Master e Work) pode ser instalado em qualquer banco de dados RDBMS que suporta ANSI ISO89. Alguns dos bancos que suportam são Oracle, Microsoft SQL Server, Sybase AS Enterprise, IBM DB2 UDB, IBM DB2/40.

Onde posso obter mais informações sobre ODI ?

http://www.oracle.com/us/products/middleware/data-integration/index.html

O ODI é usado pela Oracle em seus produtos ?

Sim, existem vários 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 aplicações do Oracle BI também usam o ODI como sua ferramenta principal de E-LT.