Artigo SQL Magazine 59 - Implementando uma solução Business Intelligence com o Microsoft SQL Server 2005 - Parte 1

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (2)  (0)

Aprenda Modelagem Multidimensional, Data Mart, ETL, Cubo Olap e Visualização de dados com o Excel 2007.

Esse artigo faz parte da revista SQL Magazine edição 59. Clique aqui para ler todos os artigos desta edição

imagem_pdf.jpg

SQL Server 2005

Implementando uma solução Business Intelligence com o Microsoft SQL Server 2005 – Parte 1

Modelagem Multidimensional,  Data Mart, ETL, Cubo Olap e Visualização de dados com o Excel 2007

 

Atualmente, a necessidade de cruzar informações para realizar uma gestão empresarial eficiente é uma realidade vivenciada pelo mercado, fazendo com que as empresas não adiem decisões importantes relacionadas diretamente ao seu negócio. O interesse pelo Business Intelligence (BI) vem crescendo na medida em que seu emprego possibilita às organizações realizarem uma série de análises e projeções, de forma a agilizar os processos relacionados às tomadas de decisão.

Resumindo, BI é um conjunto de ferramentas e metodologias para gestão do negócio que tem como objetivo final auxiliar os responsáveis para tomada de decisões através da análise das informações internas e externas à empresa. O BI é composto de um conjunto de processos, conceitos e tecnologias, os quais serão abordados e explicados no decorrer deste artigo.

 

Sistemas OLTP x Sistemas OLAP

Os sistemas OLTP (On-Line Transaction Processing) são sistemas que armazenam as transações de um negócio e as colocam em estruturas relacionais, seguindo um padrão baseado nas Formas Normais de bancos de dados relacionais. As principais características dos sistemas OLTP são:

·         Realizar transações em tempo real e, desta forma, os dados armazenados mudam constantemente;

·         São os responsáveis pela manutenção dos dados, realizando inclusões, atualizações e exclusões dos dados;

·         As estruturas dos dados devem estar otimizadas para validar a entrada dos mesmos e rejeitá-los se não atenderem a determinadas regras de negócio;

·         Para a tomada de decisões, possuem capacidades limitadas, pois não é seu objetivo principal. Caso seja necessário obter uma informação histórica poderá ocorrer uma sobrecarga no sistema, devido à necessidade de execução de consultas SQL complexas.

 

Como exemplo de sistema OLTP pode-se citar sistemas de Vendas, de Folha de Pagamento, de controle Acadêmico, dentre outros.

Os sistemas OLAP (On-Line Analytical Processing) oferecem uma alternativa aos sistemas transacionais, produzindo uma visão dos dados orientada à análise, além de uma navegação rápida e flexível. Um sistema OLAP apresenta as seguintes características:

·         Esquema otimizado para que as consultas realizadas pelos usuários sejam retornadas rapidamente;

·         Geração de relatórios complexos de uma forma simples;

·         Utilização interativa com os usuários, ou seja, as consultas não necessitam estar pré-definidas;

·         Permite a redundância de dados para otimização das consultas.

 

Pode-se tomar como exemplo de um sistema OLAP a construção de um Data Mart gerado a partir de um Sistema OLTP de Vendas.

 

Conceitos de Data Warehouse e Data Mart

Pode-se definir um Data Warehouse como uma coleção de dados orientados por assuntos, integrados, variáveis com o tempo e não voláteis, com o objetivo de dar suporte ao processo de tomada de decisão.

Um Data Mart é um armazém de dados com informações de interesse particular para um determinado setor da empresa. Desta forma, um Data Mart é um pequeno Data Warehouse que fornece suporte à tomada de decisão para uma determinada área de negócio, como, áreas de vendas, compras, estoque ou recursos humanos.

Alguns autores possuem visões diferentes na hora de definir uma estratégia para a construção de um armazém de dados. Para Bill Inmon, uma empresa inicia um projeto com a construção de um Data Warehouse, de onde os Data Marts extraem suas informações. Mas para Ralph Kimball, um Data Warehouse inicia-se com a criação de Data Marts, que juntos irão formar o Data Warehouse da empresa. Neste artigo será abordada a filosofia de Kimball.

Na prática muitos projetos iniciam-se com a construção do Data Mart pois, neste caso, é possível obter um resultado mais rápido devido ao menor escopo do projeto (atende apenas a uma determinada área de negócio).

 

Modelagem Multidimensional

Os sistemas de base de dados tradicionais utilizam a normalização para garantir a consistência dos dados e uma minimização do espaço de armazenamento necessário.

Entretanto, algumas transações e consultas em bases de dados normalizadas podem se tornar lentas devido às operações de junção entre as tabelas envolvidas.

Um Data Warehouse ou Data Mart utiliza normalmente dados em formato desnormalizados. Isto aumenta o desempenho das consultas e, como benefício adicional, o processo torna-se mais intuitivo para os usuários finais.

O modelo multidimensional é baseado em três tipos de tabelas:

·         Fatos;

·         Dimensões;

·         Medidas.

 

Tabela de Fatos

A tabela de Fatos é a tabela central do modelo e contém os valores do negócio que se deseja analisar, geralmente possui um grande volume de dados. A tabela Fato possui chaves externas (estrangeiras), que se relacionam com suas respectivas tabelas de dimensões, e campos numéricos que são os valores (medidas) que serão analisados.

 

Tabelas de Dimensão

As tabelas de dimensões representam um aspecto do negócio que está sendo analisado. Cada dimensão é definida pela sua chave primária, que serve para manter a integridade referencial na tabela Fato à qual está relacionada. Uma dimensão oferece ao usuário um grande número de combinações e interseções para analisar os dados. As tabelas de Dimensões podem ser implementadas de duas maneiras (ver Figura 1):

 

·         Esquema Estrela: Cada dimensão será formada por apenas uma tabela não padronizada. Pelo fato das tabelas não estarem normalizadas, isto resultará em uma menor quantidade de tabelas no modelo do Data Mart, mas como conseqüência poderá causar redundância dos dados, fato característico neste tipo de aplicação;

·         Esquema Floco de Neve: Neste esquema, as tabelas da dimensão estão padronizadas para eliminar a redundância de dados. Diferente do esquema Estrela, neste esquema os dados das dimensões estão distribuídos em múltiplas tabelas.

 

Figura 1. Exemplo de tabela Não Padronizada e tabela Padronizada

 

Em relação à estrutura das dimensões, estas possuem níveis, onde cada nível de uma dimensão deve ter correspondência com uma coluna na tabela da dimensão. Os níveis são ordenados por grau de detalhe e são organizados em uma estrutura hierárquica (ver Figura 2).

 

Figura 2. Estrutura hierárquica de uma dimensão

 

Neste exemplo, a dimensão Produto possui três níveis. O nível mais alto hierarquicamente é representado pela Categoria, em seguida tem-se o nível Subcategoria, ligado hierarquicamente a Categoria, e o nível Produto, subordinado ao nível Subcategoria.

Na prática, isso significa que se pode detalhar a consulta de determinada medida (por exemplo, quantidade de vendas) de acordo com o nível desejado.

 

Medidas

Uma Medida é um atributo que qualifica um determinado fato, representando o desempenho de um indicador em relação às dimensões que participam do fato. O contexto de uma medida é determinado em função das dimensões que participam do fato.

Por exemplo, quando a implementação do estudo de caso deste artigo estiver concluída, será possível consultar a quantidade de vendas (medida contida na tabela fato) por Loja, Vendedor ou Cidade (dimensões do modelo que representam um aspecto do negócio).

Será possível, também, incluir a dimensão Tempo, definindo o período para o qual se pretende realizar a análise. Por exemplo, perguntas do tipo: “Qual o número de vendas por vendedor em determinada loja e em um determinado período?” poderão ser respondidas.

 

Estudo de Caso

Este artigo irá demonstrar o desenvolvimento de uma solução de BI que terá como base a área de negócios de uma rede de lojas com filiais distribuídas em vários estados e cidades do Brasil. Estas lojas vendem diversos produtos que são classificados por categoria e subcategoria. Cada loja possui uma equipe de vendedores responsáveis pelas vendas dos produtos. A Figura 3 apresenta o Modelo Relacional do banco de dados de produção “dbVendas”.

 

Figura 3. Visualização do Modelo Relacional do banco de dados de produção “dbVendas”

 

Nota: Para obter o banco de dados “dbVendas” já populado, é necessário fazer o download do backup “dbVendas.bak” no site da revista SQLMagazine.

 

Os requisitos levantados nesta etapa provêm de entrevistas realizadas com os usuários finais que irão utilizar a ferramenta. Por se tratar de um estudo de caso de uma área específica, ou seja, o setor de vendas da empresa, será desenvolvido um Data Mart. De acordo com as necessidades levantadas, é importante para empresa obter as seguintes informações:

 

ü       A quantidade de unidades vendidas por estados e cidades onde existem lojas da rede: pode-se destacar como possível medida a quantidade de unidades vendidas, exibidas em detalhes por Estado, Cidade e Loja, assim, deve-se criar a dimensão Loja com os níveis Estado, Cidade e Loja. Por outro lado, a quantidade de unidades vendidas refere-se aos produtos, detecta-se então uma nova dimensão, a dimensão Produto;

ü       O valor de vendas por produto: identifica-se aqui uma nova medida, valor de vendas por produto, sabendo que será utilizada a dimensão Produto para obter o valor das vendas de cada Produto;

ü       Verificar o perfil de produtos vendidos em cada cidade em um determinado período: para isso, é necessário tratar das vendas realizadas por categoria de produto por cidade e por ano, mês e dia. Verifica-se que é necessário analisar os produtos de acordo com a sua categoria, agrupando por Categoria e Subcategoria, definindo mais dois níveis na dimensão Produto;

ü       Premiar anualmente os vendedores que ultrapassem as metas de vendas atribuídas. A análise, neste caso, deverá incluir os vendedores e as vendas realizadas por mês para o ano fiscal: sobre este requisito, deve-se acrescentar a dimensão Vendedor, e as medidas utilizadas serão as mesmas destacadas anteriormente. Pode ser muito útil acrescentar o nível Loja na dimensão Vendedor para facilitar na hora da pesquisa. Para premiar os vendedores que ultrapassarem a meta estipulada deve-se implementar uma KPI (Key Performance Indicators). KPIs são indicadores de desempenho que fornecem a capacidade de definir gráficos e métricas customizáveis de negócio. Um KPI é representado por um símbolo gráfico que assume determinado estado de acordo com a programação realizada;"

A exibição deste artigo foi interrompida :(
Este post está disponível para assinantes MVP

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?