BI Online
Autor: Diogo Roos | Publicado: 2015-01-08T19:16:00-02:00


Quando se fala em BI, há sempre a mesma expectativa por parte do usuário: analisar os dados de maneira online, isto é, em tempo real.
E a grande maioria dos profissionais que trabalham com esse tipo de sistema de análise diz a mesma coisa: o BI deve trabalhar com dados históricos, defasados.
Em geral, justificam este modelo de trabalho com duas explicações:
- As análises complexas não devem concorrer com as rotinas do sistema fonte (ERP, CRM, HR, etc);
- Os dados do sistema fonte são desorganizados e precisam ser extraídos, transformados e carregados para uma base de dados organizada, com dados claros e objetivos para serem utilizados na plataforma de análise (BI).

Daí começa a bagunça: data warehouse, data mart, licença para o novo banco de dados do bi, um novo servidor só para o novo banco, etc.
A meu ver, isso definitivamente só atrasa o desenvolvimento e engessa o sistema de análise. O usuário não será capaz de sequer tentar fazer uma nova visão por si só, seja ela a mais simples que for.
Aonde fica a versatilidade da plataforma de BI?
Qual a grande diferença dessa plataforma de BI para os relatórios estáticos que o usuário já tem em seu sistema fonte? Seriam os gráficos? Os mapas? As "bolhas coloridas"?

"Mas eu adquiri esse sistema de análise pensando que eu mesmo poderia extrair as informações de forma fácil e ágil, como mostra no site do BI", diz o usuário, contrariado.

"É versátil, mas nem tanto" deveria ser o slogan desses profissionais.

Profissionais e empresas que seguem o caminho "o meu sistema é muito bem estruturado, com data warehouse, data mart, ETL, agendador...", como deuses, fazem a mesma coisa: limitam o poder não só do sistema de análises, mas também dos usuários.

Se você é usuário, acredite, você pode. É isso que boas plataformas de BI querem proporcionar: versatilidade.
Se o seu sistema de análises está engessado, repense. Não deveria ser assim.

Isso não quer dizer que você sozinho conseguirá extrair qualquer informação, principalmente se você não conhece a estrutura de tabelas do seu sistema fonte -aí entra o analista de sistema para lhe auxiliar a extrair e unir as informações. E algumas vezes poderá ser necessário contar com auxílio de um DBA, para que ele crie rotinas, function's, tabelas extras ou view's no banco de dados para extrair a informação que você deseja.
Isso é diferente de sempre ter que esperar pela criação de um data mart, esperar pela configuração do ETL, e principalmente não poder ter acesso rápido a outras informações do sistema fonte que já não estejam disponíveis no sistema de análise. Sem falar, é claro, que neste modelo, as informações seriam defasadas.

Quem ganha com isso? Os desenvolvedores de análises em plataformas de BI, já que, sempre que um usuário precisar extrair uma informação, terá que pedir para tal desenvolvedor criar um data mart, configurar o ETL, etc.
Quem perde? Já disse, o usuário.


Particularmente eu não concordo com a ideia de que análises e decisões devem ser feitas com base em dados defasados, mesmo que sejam de 1 dia, ou 10 horas, ou 4 horas e nem mesmo em 30 minutos.
30 minutos antes do fim do expediente uma empresa pode ter uma grande novidade. E o analista do BI terá que deixar a novidade para amanhã, já que os novos dados só estarão disponíveis às 18 horas e 20 minutos, quando todos já foram embora -imagine isso em uma sexta-feira. Ele dirá para seus diretores: "vamos finalizar a reunião agora porque não temos como visualizar o resultado atual da empresa neste momento, pois os novos dados só estarão disponíveis amanhã".
Note que estou falando de 30 minutos de atraso. Imagine visões que são atualizadas apenas às 02 horas da manhã.

Claro que há implicações em trabalhar com dados online (em tempo real). As duas que citei acima não foram metafóricas, especialmente a primeira das duas, que realmente deve acontecer se você tiver um ambiente com centenas de transações por segundo.

Entretanto, há maneiras fáceis de resolvê-las.
- Análises complexas e demoradas em ambiente crítico: trabalhe com plataforma de bi com recurso "in-memory". Atente-se para que este recurso seja compartilhado entre os usuários, isto é, se um analista carregar uma visão com todo o estoque de 2014 de toda a empresa, e outro analista vier a utilizar esta mesma visão posteriormente, ela já estará carregada e pronta para ser visualizada quase que instantaneamente. Isso é diferente de ter simplesmente o recurso in-memory na plataforma, pois este carrega os dados de forma instantânea apenas para o próprio usuário, já a opção avançada deste recurso, que chamo aqui por "shared in-memory", trata-se de utilizar os dados da memória que foram carregados independentemente de quem gerou primeiro.
Sei que o Tableau faz isso. O Qlikview tem o recurso in-memory
E claro, a plataforma de BI só deve atualizar os dados (com recurso automático) apenas se houver diferença da informação original. E você deve ter a opção de não permitir que o usuário atualize a visão manualmente.
E caso a análise seja realmente complexa e demorada, tente aprimorar algo no banco de dados, como criar índices, disponibilizar filtros e pré-filtros nas visões, etc.
Uma opção para melhorar o desempenho que pode ser aplicada em muitos casos, é fazer com que informação original atualize uma ou mais tabelas destinadas para o BI através de trigger's. Por exemplo, se você tem uma visão que mostra o saldo do estoque, pense em criar trigger's para atualizar tais tabelas do BI a cada novo registro de maneira mais limpa e objetiva para o fim da análise, tudo no mesmo banco de dados. Você continuará tendo informação online no BI, de maneira mais objetiva e rápida, já que não passará por uma tabela que tem dezenas de informações inúteis para o BI.
- Dados do sistema fonte desorganizados para o BI: se você tem uma regra complexa no seu ETL e não vê maneiras de organizar os dados através de um select, com certeza poderá fazer isso através de function's do banco de dados. A ideia da function é selecionar, organizar, modificar e exibir os dados através de select, como se fosse uma tabela com regras e cálculos internos e pode retornar dados de uma ou mais tabelas. Como se fosse uma "procedure table", é possível disponibilizar parâmetros para que você utilize-os como filtros em "where's" ou faça cálculos com eles, o que flexibiliza as visões dependendo dos parâmetros.
Pesquise a respeito de criação de function para seu banco de dados.

Sim, já trabalhei com visões de muitos dados e sei como é, e se realmente quiser, é possível trabalhar de maneira online.
Qualquer usuário irá preferir aguardar um tempo a mais para ter informação em tempo real do que só ter a opção de trabalhar com informação defasada.