1) O documento descreve como configurar as topologias no Oracle Data Integrator (ODI) para definir as origens e destinos de dados para um projeto de ETL. 2) Inclui detalhes sobre como configurar as arquiteturas física, lógica e contextos no ODI para mapear as bases de dados físicas às lógicas. 3) Fornece exemplos de como criar servidores de dados, esquemas físicos, contextos e esquemas lógicos no ODI.

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

2. Configurando as Topologias
Neste tutorial vamos definir e parametrizar a arquitetura física e lógica do nosso
projeto de ETL. No ODI o módulo responsável por organizar, armazenar e disponibilizar
as bases e objetos de origem e destino é o Topology. As origens e destinos podem ser
definidas por Tecnologia, ou seja, podemos definir desde servidores de arquivo texto,
Oracle, MySQL, Jython e etc.
Para o nosso tutorial, a principio, iremos configurar somente topologias de origem e
destino para trabalhar com banco de dados Oracle.
Na figura acima, podemos ver os componentes do módulo Topology, no tutorial
passado trabalhamos com o componente Repositories onde definimos o repositório
de trabalho do nosso projeto. Neste tutorial iremos trabalhar com os componentes
Physical Architecture, Logical Architecture e Context.
Physical Architecture (Arquitetura Física)
A arquitetura física define quais são os parâmetros de acesso ao ambiente físico de
dados origem ou destino que estamos utilizando. Como por exemplo, armazenamento
de informações do sistema, características de usuários, tipo do banco de dados
(Oracle, DB2, SQL Server,etc), formato de arquivo (XML, File), tipo de conexão e etc.
Em resumo a arquitetura física, armazena as informações reais dos servidores de
dados assim como suas características de acesso.
Logical Architecture (Arquitetura Lógica)
A arquitetura lógica é utilizada para fazer os agrupamentos dos esquemas físicos. No
processo de desenvolvimento a referência aos bancos de dados se dá através do
esquema lógico e não através do esquema físico. Isso nos permite uma grande
flexibilidade de parametrização.
Contexts (Contextos)
O contexto é o responsável por fazer a união entre o esquema físico e o esquema
lógico.

3. O conceito aqui exposto é muito importante para a continuidade e para as boas
práticas de utilização do ODI, portanto para que fique bem claro o conceito dos
elementos, vamos imaginar um cenário onde temos o seguinte desenho de ambientes:
Desenvolvimento, Testes, Homologação e Produção.
Para cada ambiente devemos criar um banco de dados físico, pois cada um possui
estrutura, processamento, usuários de conexão e etc distintos. Por consequência
teremos quatro arquiteturas físicas para representar nosso cenário.
Seguindo neste exemplo, iremos precisar de apenas uma arquitetura lógica para fazer
a ligação com os esquemas físicos.
Veja a representação na tabela abaixo de como ficaria o desenho desta solução:
Arquitetura Lógica Contexto Arquitetura Física
ORCL_ORIGEM Desenvolvimento ORCL_DESENV
ORCL_ORIGEM Teste ORCL_TESTE
ORCL_ORIGEM Homologação ORCL_HOMOL
ORCL_ORIGEM Produção ORCL_PROD
Como podemos observar, temos quatro contextos, para quatro esquemas físicos
distintos, e apenas um esquema lógico. Com isso, o desenvolvimento do nosso projeto
irá utilizar uma determinada arquitetura lógica parametrizada para acessar as
informações de um determinado banco de dados físico dependendo do contexto
utilizado.
Quando for fazer o processamento de uma carga e o contexto for selecionado, o ODI
automaticamente irá buscas as informações necessárias no esquema correspondente.
Por exemplo: a interface de dados está sendo executada com o contexto de
Homologação, os dados serão capturados do esquema físico ORCL_HOMOL.
Outra vantagem e uma importante característica do ODI é a fácil reestruturação de sua
plataforma de desenvolvimento. Ainda seguindo o exemplo dado acima, vamos
imaginar que o banco de dados de testes teve que mudar de servidor e trocaram o
nome de identificação, vamos chamar de ORCL_TST. As alterações que precisam ser
feitas estão relacionadas à criação de uma nova arquitetura física, depois fazer a troca
do parâmetro da arquitetura lógica ORCL_ORIGEM no contexto de Teste para esta
nova arquitetura física. Com esta flexibilidade não é preciso nenhuma modificação nas
estruturas já desenvolvidas, estamos apenas redefinindo os parâmetros das novas
arquiteturas físicas a uma arquitetura lógica e não a um banco de dados ou recurso
físico.

4. Criando a arquitetura Física
Relembrando: Quando criamos uma arquitetura física estamos direcionando um
ponteiro de conexão para um banco de dados físico, para o nosso projeto devemos
criar os esquemas físicos para as informações de origem e destino.
No módulo Topology como já havia falado anteriormente possui diversas tecnologias
para definir os servidores de dados, no nosso projeto iremos utilizar a tecnologia
ORACLE.
Antes de iniciar a parametrização da arquitetura física garanta que os usuários de
banco de dados “schemas/users” que serão utilizados possua os grants necessários
para visualizar as tabelas, as visões, e etc. Os “schemas/users” que iremos utilizar são
os mesmos criados no tutorial anterior. Para relembrar segue a relação na tabela
abaixo:
SCHEMA/USER PASSWORD
DW_ORIGEM DW_ORIGEM
DW_DESTINO DW_DESTINO
DW_TEMP DW_TEMP
Neste projeto vamos trabalhar com três repositórios físicos, um representando o
esquema de origem dos dados, um representando o esquema de destino, esse
desenho nos mostra um repositório tipo DW (origem) e um repositório tipo DM
(destino). Ainda temos mais um repositório o DW_TEMP, quando estamos definindo a
arquitetura física, devemos parametrizar dois banco de dados físicos que são
chamados de Schema(Schema) e Schema(Work Schema) vamos traduzir como
Esquema Principal e Esquema de Trabalho.
O Esquema Principal nos informa qual será o esquema no banco de dados que
conterá as tabelas que iremos fazer “consultas” ou “gravar” dados, ou seja, as tabelas
envolvidas diretamente no processo de ETL.
O Esquema de Trabalho indica o banco de dados que o ODI irá utilizar para criar os
objetos temporários durante o processo de integração (objetos com prefixos I$, C$,
etc).
Configurando o Esquema Físico
Para inserir um servidor de dados acesse o módulo Topology. Procure a aba Physical
Architecture, clique na pasta Technology, irá abrir várias opções de tecnologia,
encontre e selecione a tecnologia ORACLE, neste instantes será apresentada uma
opção identica a figura abaixo:

5. Agora pressione o botão direito do mouse e escolha a opção “Insert Data Server”,
conforme a figura abaixo.
Uma nova janela será aberta, nesta etapa teremos duas atividades importantes por
fazer. A primeira delas é configurar os acessos, identificar o servidor, colocar usuário e
senha de acesso ao banco de dados que será o repositório e a segunda atividade é
configurar a forma de acesso, no nosso caso através de JDBC. Vamos ver como fazer a
primeira tarefa:

6. Data Server Parâmetro
Name DW_ORIGEM
Technology Oracle
Instance / dblink (Data Server) Xe
User dw_origem
Password dw_origem
O próximo passo é fazer a configuração do JDBC, para tanto, selecione a aba JDBC
dentro desta mesma janela de configuração, lembre-se que se você clicar em qualquer
botão de validação irá produzir erro, pois o JDBC ainda não está parametrizado.
Quando abrir a janela do JDBC você deve ver a seguinte figura:

7. JDBC Parâmetro
JDBC Driver oracle.jdbc.driver.OracleDriver
JDBC Url jdbc:oracle:thin:@localhost:1521:xe
Após fazer essas duas parametrizações, teste a conexão. Clique no botão teste, deverá
aparecer as próximas duas janelas, na primeira janela selecione o agent, deixe como
Local e pressione o botão Test.

8. Se o teste for bem sucedido aparecerá a figura abaixo:
Até esse instante só definimos o repositório mestre para os servidores de origem e a
forma de conexão, ainda falta fazer a parametrização mais importante, que é definir a
área de trabalho e a área temporária. Clique em OK para seguir a configuração. Agora
devemos clicar no botão Apply, neste momento uma nova janela irá abrir. Nesta janela
iremos parametrizar o Esquema Físico, veja na figura abaixo:

9. Nesta figura temos muitas informações importante. A primeira coisa que devemos
fazer é parametrizar os campos Schema (Schema) e Schema (Work Schema). O
parâmetro Schema (Schema) representa o local físico onde as tabelas do DW irão ser
armazenadas, o parâmetro Schema (Work Schema) representa a área temporária que
será utilizada pelo ODI para gerar tabelas temporárias no processo de integração.
Adotando o critério de melhores práticas sempre parametrize com schemas distintos,
pois o ODI possui a característica E-LT, ou seja, a transformação pode ocorrer tanto na
origem, quando no destino, sem a necessidade de um hardware proprietário fazendo
as transformações no meio do processo.
Nesta mesma janela podemos ver informações sobre os prefixos das tabelas
temporarias (Work Tables) e também das tabelas de jornalização (Journalizing
elements). Você deve estar se perguntando para que serve esses dois conceitos ?
A jornalização é o conceito de manutenção de registros diários, o propósito da mesma
é garantir a integridade dos metadados.

10. As tabelas temporárias são criadas como espelho, de acordo com a necessidade do
processo de integração. Todas as tabelas (trabalho e jornalização) são criadas
automaticamente durante o processo de integração dentro do schema/user definido
como esquema de trabalho (Work Schema). No ODI existe o conceito de “Stagging
Area”, que é responsável pela criação e armazenamento dos objetos temporários do
ETL, este conceito será revisto e abordado profundamente no momento em que
estivermos construíndo as interfaces de integração.
O que significa as extensões ? Abaixo segue uma breve explicação de cada prefixo:
 E$: quando utilizamos tratamento de erros no ODI, os erros gerados são
gravados nesta tabela que é criada por default como
E$_<NOME_DA_TABELA>;
 C$: criada quando estamos buscando os dados de um banco diferente do
destino. O ODI cria esta tabela, popula com as informações da origem e depois
utiliza a mesma no processo de ETL. Criada por default como
C$_<NOME_DA_TABELA>;
 I$: criada durante o processo de ETL. Nesta tabela são resolvidos todos os
relacionamentos entre as tabelas envolvidas no processo, e depois de pronta é
utilizada para popular a tabela de destino. Criada por default como
I$_<NOME_DA_TABELA>;
 J$, JV$ e T$: são tabelas criadas quando se está trabalhando com o conceito
de jornalização.
Neste instante terminamos a parametrização do Esquema Físico de origem, repita todo
esse processo para o Esquema Físico de destino, alterando o parâmetro Schema
(Schema) para DW_DESTINO mas, mantendo o Schema (Work Schema) com
DW_TEMP, iremos utilizar o mesmo repositório temporário utilizado nos parâmetros do
Esquema Físico de origem, fazemos isso por praticidade e segurança, sabendo que
todos os objetos temporários envolvidos no projeto serão criados no mesmo
repositório. Esse tipo de decisão deve ser adotada de projeto para projeto, arquitetura
de banco de dados para arquitetura.
Data Server:DW_ORIGEM Parâmetro
Name DW_ORIGEM.DW_ORIGEM
Schema (Schema) DW_ORIGEM
Schema (Work Schema) DW_TEMP
Data Server:DW_DESTINO Parâmetro
Name DW_DESTINO.DW_DESTINO
Schema (Schema) DW_DESTINO
Schema (Work Schema) DW_TEMP

11. Criando Contextos
Os contextos é que permitem que possamos ligar um Esquema Físico a um Esquema
Lógico, relembrando que no momento de desenvolvimento o único esquema disponível
é o esquema lógico, portanto criar os contextos é de suma importância para o nosso
projeto.
Para este projeto criaremos 4 (quatro) contextos para representar: desenvolvimento,
teste, homologação e produção.
No módulo Topology, clique na aba Context, em seguida selecione o contexto Global,
este contexto é criado automaticamente pelo ODI, clique com o botão direito, uma
nova jalena será mostrada, conforme a figura abaixo:
Selecione a opção “Insert” e a janela abaixo será apresentada:

12. Digite o nome do contexto e clique em OK para validar. Repita o procedimento para
criar todos os contextos. Após o processo devemos ter a seguinte visão da janela de
contextos:
Criados os contextos, devemos agora parametrizar o esquema lógico.

13. Configurando o Esquema Lógico
Chegamos ao último passo da configuração de Topologias do nosso projeto, lembrando
que esse trabalho dentro de uma estrutura de projeto ETL é dinâmica e a qualquer
momento poderá surgir a necessidade da criação de novos servidores de dados
(baseados em sua tecnologia), como por exemplo, criar uma conexão com arquivo
texto.
No módulo Topology clique na aba Logical Architecture e posteriormente na estrutura
Tecnologia Oracle, conforme figura abaixo:
Após selecionada a tecnologia Oracle, clique com o botão direito no mouse, abrirá a
janela mostrada acima, clique em “Insert Logical Schema”.

14. Vamos trabalhar o projeto apenas com o contexto de Desenvolvimento, e neste
instante definimos o nome do Logical Schema para os repositórios de Origem e
Destino, veja os parâmetros na tabela abaixo:
Logical Schema Parâmetro
Name LOGICAL_DW_ORIGEM
Context Desenvolvimento
Physical Schemas DW_ORIGEM.DW_ORIGEM
Devemos repetir o processo para o repositório Destino:
Logical Schema Parâmetro
Name LOGICAL_DW_DESTINO
Context Desenvolvimento
Physical Schemas DW_DESTINO.DW_DESTINO
Os demais contextos criados serão utilizados em Tutoriais futuros, até o final deste
tutorial apenas o contexto de Desenvolvimento será utilizado.