Nova integração? Comece pela view layer!

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:

  1. Acessar dinâmicamente a outra base de dados, via sinônimo e/ou db-link: View Layer ou Visualização em Camadas
  2. 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:

  1. 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.
  2. 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

 

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *