domingo, 28 de agosto de 2016

Descomplicando uma sopa de letrinhas chamada Business Intelligence

Você faz parte de uma equipe de TI de uma empresa relativamente nova. Desenvolve um sistema de gestão para a mesma, visando a este apoiar as atividades dos colaboradores de outras áreas da Empresa.

Daí o gerente da área de vendas da Empresa pede um relação das vendas efetuadas nos últimos três anos. Mais tarde, esse mesmo gerente solicita a relação dessas vendas agrupados por Vendedor, de modo a calcular as comissões a serem pagas para esses vendedores. A Empresa vai crescendo, inaugurando uma filial a cada ano e consequentemente o volume de vendas, de vendedores e de dados sobre as vendas também.

Aquela relação solicitada constantemente pelo Gerente cresce exponencialmente dificultando a análise desta, além de onerar o Banco de Dados alimentado pelo velho e bom Sistema de Gestão mantido por você. Seu Gerente que muitas vezes não entende nada de TI, fala que vem recebendo uma série de reclamações sobre a lentidão do Sistema e fala pra você se virar de modo a resolver o problema.

Para complicar ainda mais, surgem novos pedidos de informações de vendas daquele e de outros gerentes de outras áreas da Empresa. Você então pensa: "Vou ter que extrair essas informações em horários de vale (momentos em que os usuários não estão utilizando o Sistema). A empresa começa a receber uma quantidade imensa de pedidos e resolve ampliar o expediente de trabalho de modo a atender esses pedidos. Extrair as informações fica cada vez mais difícil, mais demorado.

Os colaboradores da Empresa começam a reclamar da demora na entrega das relações solicitadas a equipe de TI. Chega um momento que você não consegue mais atender as solicitações dos colaboradores no tempo que as atividades da Empresa exige. Daí você pensa: "Tô fudido!" e se pergunta:"O que fazer?".

Ao mesmo tempo, aquele diretor que tomava as decisões baseado nas experiências dele  deixa a Empresa e no lugar dele, entra um camarada bem intencionado, mas que não possui experiência tão aprofundada quanto a do antigo diretor.

O novo diretor chega e demanda informações dizendo que a Empresa está perdendo vendas por falta de produtos em alguns momentos e em outros, tendo que fazer promoções por conta de muito produto em estoque. Daí você pensa:"Dá zero pra ele! Será que esse diretor não é burro?". E daí ele fala pra você: "Arruma uma solução, ô inteligência!"

Você então começa pensar num modo de resolver a situação. O diretor precisava se basear em informações para tomar decisões. Por mais que o diretor tivesse experiência, dependendo do cenário, as decisões por mais que pareçam estar corretas poderiam acarretar em consequências desastrosas para a Empresa.

A conclusão a que você vai chegar é que a empresa deveria adquirir uma inteligência de modo a evitar e prever problemas futuros para o negócios da Empresa. E é aí que o BI (Business Intelligence), surge.

Hoje em dia o pai Google tem solução pra tudo. Você digita  algo no google rezando pra que surja uma resposta. Entaum o Google mostra um monte de coisas.BI,OLAP,OLTP, DW, modelagem dimensional...  Pesquisando um pouco mais, eis que surge o nome de um camarada de sobrenome "Kimbal" que já vinha pensando sobre o assunto há muito tempo.

A primeira conclusão a que você vai chegar é que não devemos utilizar a base de dados do Sistema de gestão para extrair as informações para apoiar a decisões da empresa. Segundo a terminologia esses sistemas são conhecidos como OLTP (Online Transaction Processing ou Processamento de Transações em Tempo Real) são sistemas que se encarregam de registrar todas as transações contidas em uma determinada operação organizacional.

Bom, se você não pode usar o Sistema de Gestão da Empresa, e muito menos a base de dados que ele alimenta, como resolver o problema? A solução será utilizar ou desenvolver um outro tipo de sistema que proporcione a capacidade de ter idéias sobre os dados, permitindo analisá-los profundamente em diversos ângulos. Esses sistemas são classificados como do tipo OLAP (Online Analytical Processing).

Para modelar o Sistema de Gestão, você fez uso da metodologia de modelagem do tipo Entidade - Relacionamento. O tal do Kimball preconizou que para modelar uma base de dados para um sistema do tipo OLAP deveria se fazer isso de um jeitão meio diferente. Surge então modelagem dimensional, onde a ideia é criar um modelo que se destine à análise de dados. No que diz respeito à análise de dados, o que se espera do modelo de dados para um sistema OLAP é que:
  • Seja uma representação simples do modelo de negócios estudado;
  • Seja um modelo físico de fácil interpretação, de modo que usuários sem treinamento formal em TI possam entendê-lo;
  • Facilite a implementação física do modelo de modo a maximizar performance das consultas aos dados.
 Portanto, no modelo multidimensional, deixamos de focar a coleta de dados para nos ocuparmos com a consulta aos dados.

Isso não quer dizer que você deva esquecer a modelagem relacional. Tudo o que sabemos a respeito de modelagem relacional, vale novamente para a modelagem multidimensional.  Na modelagem multidimensional, teremos novamente que identificar entidades, tabelas, atributos, chaves primárias, integridade referencial e normalização. A principal diferença está em relação à normalização.

O modelo multidimensional usa sim normalização, mas considera apenas até a Segunda Forma Normal.

Damos o nome de modelo multidimensional ou modelo relacional em esquema estrela por causa da distribuição das tabelas no diagrama. Teremos sempre uma tabela central, que armazena as transações que vamos analisar. Esta tabela é chamada de tabela fato. Ao redor da tabela fato, temos as tabelas que chamamos de dimensões.



Todas as dimensões se relacionam exclusivamente com a tabela fato, daí a referência da estrela.

Traduzindo isso para o modelo proposto inicialmente, temos como resultado o modelo a seguir:



Este modelo é chamado de estrela porque a tabela de fatos fica ao centro cercada das tabelas dimensionais assemelhado a uma estrela. Mas o ponto forte a fixar é que as dimensões não são normalizadas.

No final das contas, o que nos importa é que a tabela fato armazena os indicadores que iremos analisar e as chaves que caracterizam a transação. Estas chaves são os elos de ligação com as tabelas de dimensão. Estas, por sua vez, armazenam as classificações que usaremos para analisar os indicadores. Cada dimensão registra uma entidade que caracteriza a transação e mais todos os atributos associados a esta entidade.

Algumas implicações sobre este modelo são descritas a seguir:

Característica 1 - Uma das candidatas a chave primária da tabela fato seria uma chave composta pelas chaves primárias de todas as dimensões.

Característica 2 - As dimensões devem conter todos os atributos associados à sua chave primária. Por exemplo: digamos que temos uma dimensão TEMPO no nosso modelo que monitora transações por dia. Neste caso, a dimensão conteria todos os atributos relacionados à chave dia: mês, trimestre, ano, dia da semana, semana do ano, etc. 

É por conta desta característica das dimensões que dizemos que o modelo multidimensional está na Segunda Forma Normal. Para lembrar um pouco da teoria sobre normalização, observe que as tabelas do modelo identificam as entidades descritas (não possuem tabelas aninhadas) e cada atributo não-chave da chave primária inteira.

Mas o modelo não atende à Terceira Forma Normal, porque, neste caso, suas tabelas precisariam respeitar os dois critérios que acabamos de descrever e ainda atender a mais um: que não existam dependências entre atributos não chave. Claramente isso não acontece com as tabelas de dimensão, que incluem até as hierarquias de atributos associados à chave primária.

Característica 3 - Os atributos de cada dimensão devem ser organizados em uma seqüência lógica que caracterize a(s) hierarquia(s) relacionada(s) à chave primária.

Dizemos que existe uma relação hierárquica entre dois atributos quando há entre eles uma relação de um para muitos. Uma hierarquia é caracterizada pelo encadeamento de dois ou mais atributos que apresentam relação hierárquica entre si.

Assim, no exemplo da dimensão TEMPO descrito acima, identificamos três hierarquias, como descrito a seguir: Dia, mês, trimestre, ano;

Além do modelo estrela existe uma outra estratégia de modelagem chamada modelo Floco de Neve (Snow Flake)



No modelo Floco, as tabelas dimensionais relacionam-se com a tabela de fatos, mas algumas dimensões relacionam-se apenas entre elas, isto ocorre para fins de normalização das tabelas dimensionais, visando diminuir o espaço ocupado por estas tabelas, então informações como Categoria, Departamento e Marca tornaram-se tabelas de dimensões auxiliares.

Considerações sobre ambos modelos

O Modelo Floco (Snow Flake) reduz o espaço de armazenamento dos dados dimensionais mas acrescenta várias tabelas ao modelo, deixando-o mais complexo, tornando mais difícil a navegação pelos softwares que utilizarão o banco de dados. Um outro fator é que mais tabelas serão utilizadas para executar uma consulta, então mais JOINS de instrução SQL serão feitos, tornando o acesso aos dados mais lento do que no modelo estrela.

O Modelo Estrela (Star Schema) é mais simples e mais fácil de navegação pelos softwares, porém desperdiça espaço repetindo as mesmas descrições ao longo de toda a tabela, porém análises feitas mostram que o ganho de espaço normalizando este esquema resulta em um ganho menor que 1% do espaço total no banco de dados, sendo assim existem outros fatores mais importantes para serem avaliados para redução do espaço em disco como a adição de agregados e alteração na granularidade dos dados, estes temas serão abordados em colunas posteriormente.

O recomendado é utilizar um modelo estrela, pois fornece um acesso mas rápido aos dados e mais fácil de se navegar, criando tabelas auxiliares para dimensões somente para dimensões especificas quando for estritamente necessário ou quando demonstrar um beneficio que justifique a perda de desempenho nas consultas, que também não é tão grande dependendo da forma que estas tabelas são construídas e a quantidade de registros que elas contiverem.

A modelagem dimensional é usada para modelar um banco que irá subsidiar sistemas do tipo OLAP. A esse tipo de banco de dados, damos o nome de DATA WAREHOUSE que nada mais é que um banco com dados extraídos de um banco de dados que subsidia sistemas do tipo OLTP.

Isto não quer dizer que um data warehouse possua apenas dados provenientes de um BD relacional. Um DW pode conter informações provenientes de planilhas, arquivos texto, webservices, entre outros.

Outro conceito importante é o que chamamos de Data Mart que são subconjuntos de dados de um Data warehouse.

Muito bem! Você modelou o DW da Empresa. Mas e os dados? Como popular as as tabelas fato e as dimensões? Qual estratégia utilizar para fazer isso? Daí surge o conceito de ETL do inglês Extract Transform Load (Extração Transformação Carga). São ferramentas de software cuja função é a extração de dados de diversos sistemas, transformação desses dados conforme regras de negócios e por fim a carga dos dados geralmente em um Data Mart e um Data Warehouse, porém nada impede que também seja para enviar os dados para um determinado sistema da organização. A extração e carga são obrigatórias para o processo, sendo a transformação/limpeza opcional.

Depois de falar de vários conceitos envolvidos na construção de um DW, segue um modelo com a finalidade de ilustrar um processo de BI.



Bom, é isso aí! Será que descompliquei a sopa de letrinhas? Cabe ressaltar que isso é um resumo que fiz para fixar os conceitos, mas há muito a se discutir sobre o assunto.

Até a próxima!