Eis que no meu projeto de BI, foi solicitado o acesso à outra base de dados, para integrar informações complementares. E isso é bem comum, né? Já que o projeto tende a crescer e exigir maior demanda e dimensão.
Nesse caso, temos algumas opções de como integrar, por exemplo:
- Acessar dinâmicamente a outra base de dados, via sinônimo e/ou db-link: View Layer ou Visualização em Camadas
- Copiar periodicamente as informações da outra base de dados e ter o acesso local
Ambos os casos funcionam perfeitamente, mas como escolher a melhor forma de integrar?
É importante levar em consideração os seguintes pontos:
- Quais tabelas e colunas serão necessárias.
- É preciso ter acesso aos dados em tempo-real? Ou podemos fornecer as informações atualizadas a cada 4 horas, ou 12 horas, ou 24 horas, ou semanal, ou mensal?
Caso o volume de dados para a integração seja muito elevado, o acesso dinâmico por view layer, via sinônimo e/ou db-link, pode gerar lentidão no processo.
Caso seja necessário ter acesso em tempo real às informações da outra base de dados, a opção pela cópia local dos dados pode impactar no elevado tráfico de informação na rede.
É preciso mostrar esses dois cenários ao usuário para que chegue num consenso de ter as informações atualizadas a cada X hora, por exemplo, ou então reduzir o volume de informação necessária para manter o acesso dinâmico na outra base de dados e ter as informações em tempo real.
Seja qual for a decisão, eu reforço que a entrega dessa integração seja feita em pelo menos 2 etapas:
- Acesso dinâmico, view layer. Mesmo que seja escolhido fazer uma cópia das informações localmente, o usuário descobrirá inúmeras outras necessidades e desnecessidades, no decorrer da integração. Então, antes de usar um tempo maior em duplicar as informações e agendar JOBs no banco de dados, ofereça uma integração inicial via view layer, para a validação das informações. E neste caso, solicite o acesso às tabelas da outra base de dados, crie sinônimos e integre as informações. Apresente ao usuário e solicite a aprovação. Caso a apresentação ao usuário esteja lenta, devido ao volume de informações na outra base de dados, tire print screen dos resultados, e/ou extraia as informações em excel, para que o usuário possa analisar e validar as informações.
- Cópia dos dados localmente. Uma vez que a parte 1 esteja aprovada pelo usuário, inicie a copia das informações localmente:
- Crie as tabelas com as colunas necessárias, de acordo com a estrutura das tabelas originais.
- Elabore uma package que terá um MERGE onde carregará as informações de cada tabela. Pode ser criado uma package por tabela, para facilitar a manutenção.
- Agende um JOB que executará a package no interval de tempo necessário.
- Crie uma tabela de log, onde registrará o inicio e término de cada load.
- Crie uma tabela de controle, registrando o timestamp da finalização do último load e um processo que verificará se o próximo load está atrasado, com o envio de um email notificando.
- Na apresentação ao usuário, substitua os sinônimos das tabelas de origem, para as views das tabelas locais.
Ou seja, se possível, sempre inicie uma integração por View Layer, via sinonimo/db-link, para que o usuário valide as informações. Posteriormente, caso necessário, migre para a copia local dos dados, com o maior numero de controle possível nos carregamento. Boa sorte e arrase!
E você, já passou por situações semelhantes? Comente abaixo a sua experiência!
Flavia Grohmann – AmpliaWeb