Olá pessoal!
Bom dia, boa tarde, boa noite !!!
Vamos de mais um artigo dando continuidade ao tópico sobre Modelagem Multidimensional.
Recomendo fortemente a leitura do artigo anterior: Modelagem Multidimensional – Parte 1.
Vamos que vamos, simbora! 😉
Antes de iniciarmos, trouxe abaixo breve resumo sobre características das Tabelas Fato e Tabelas Dimensões:
Agora, vamos em frente! vem comigo!
Hoje vou abordar neste artigo os passos para iniciar a modelagem dimensional, segundo Kimball.
Kimball, em sua obra indica um processo contendo 4 passos para iniciar a modelagem dimensional, vejamos abaixo cada um deles:
Passo 1: Selecione o Processo de Negócio.
Um processo de negócios é uma atividade de baixo nível realizada por uma organização, como processar pedidos, faturamento, recebimento de pagamentos, atendimento de chamadas de serviço, registro de alunos, realização de um procedimento médico ou processamento de reclamações. Nesta etapa é importante focar os esforços nos processos que darão resultado no curto prazo, ou seja, processos onde o tomador de decisão ao utilizar a ferramenta BI adotada se sinta satisfeito. Resumindo, os processos mais relevantes para organização devem ser escolhidos primeiro.
Passo 2: Declare a granularidade.
Declarar a granularidade significa especificar exatamente o que será representado individualmente numa linha na tabela fato. A granularidade transmite o nível de detalhe associado às medidas da tabela de fatos. Ele fornece a resposta à pergunta: “Como você descreve uma linha única na tabela de fatos? ”
O grão(ou atomicidade do grão) é determinado pelas realidades físicas que o sistema OLTP captura nos eventos do processo de negócio. A depender do resultado do levantamento, cada proposta de granularidade da tabela fato pode resultar em tabelas físicas separadas, porém deve-se tomar cuidado para que diferentes granularidades não sejam usadas na mesma tabela.
Passo 3: Identificar as Dimensões.
As dimensões podem ser levantadas com o seguinte questionamento: “Como os empresários descrevem os dados resultante dos eventos de medição de processos de negócios? ”
Você precisa modelar as tabelas de fatos com um conjunto robusto de dimensões que representam todas as descrições possíveis que assumem valores únicos no contexto de cada medição. Se você está certo sobre a granularidade, as dimensões podem ser facilmente identificadas, pois representam o “Quem, o quê, onde, quando, porquê e como” associado ao evento.
Exemplos de dimensões comuns incluem data, produto, cliente, funcionário e instalação. Com a escolha de cada dimensão, você lista todos os atributos semelhantes de acordo com o que foi levantado.
Tipo de Tabelas Dimensão verificadas na literatura:
- Slowly Changing Dimensions (SCD) – (Dimensões que Mudam Lentamente) e retrata as dimensões que sofrem atualizações em seus campos e os classifica pelo tipo de mudança existente em cada uma delas.
- Degenerate Dimension – Dimensão degenerada é uma chave de dimensão na tabela fato que não possui sua própria tabela de dimensão, ou seja, é a dimensão que “não mereceu ser uma dimensão” e foi inserida como coluna na tabela fato pois todos os atributos interessantes foram colocados em dimensões analíticas. O termo “dimensão degenerada” foi originado por Kimball.
- Role-Playing Dimension – Uma única dimensão pode ser referenciada várias vezes em uma tabela fato, com cada referência vinculada a uma função logicamente distinta para a dimensão. Por exemplo, uma tabela fato pode ter várias datas, cada uma delas representada por uma chave estrangeira para a dimensão da data. É essencial que cada chave estrangeira se refira a uma visão separada da dimensão da data, para que as referências sejam independentes.
- Conformed Dimension – As tabelas de dimensões estão em conformidade quando os atributos em tabelas de dimensões separadas têm os mesmos nomes de coluna. As informações de tabelas fato separadas podem ser combinadas em um único relatório usando atributos de conformidade de dimensão, que estão associados a cada tabela fato.
- Junk Dimension – A dimensão lixo é simplesmente uma estrutura que fornece um local para armazenar os atributos ou uma coleção de códigos transacionais aleatórios que não estão relacionados a nenhuma dimensão específica. Esses tipos de atributos não se integram facilmente às dimensões convencionais, como Cliente, Fornecedor e Produto, no entanto, alguns dos atributos diversos contém dados que têm um valor comercial significativo, dessa forma são armazenados em uma dimensão lixo.
Passo 4: Identificar os fatos
Os fatos podem ser determinados respondendo à pergunta: “Qual é o processo de medição?”
Os usuários de negócios estão profundamente interessados em analisar essas métricas de desempenho. Todos os fatos candidatos em um projeto devem ser fiéis a granularidade definida na etapa 2.
Fatos que claramente pertencem a um grão diferente deve estar em uma tabela de fatos separada. Você precisa considerar os requisitos e as realidades dos usuários do negócio. Veja abaixo um exemplo de tabela fato com suas dimensões:
No exemplo que trouxe acima temos uma Tabela Fato trazendo registros que fazem parte das vendas no varejo, onde será possível visualizar este dados sob diferentes perspectivas (Tabelas Dimensões).
Tipo de Tabelas Fato verificadas na literatura:
Transactional – Uma tabela fato transacional é a mais comum em tabelas fato, a granularidade associada a uma tabela de fato transacional é geralmente especificada como uma linha por linha em uma transação. Normalmente, uma tabela fato transacional contém dados do nível mais detalhado de negócio, fazendo com que tenha muitas dimensões associadas.
Aggregate – Tabelas fato agregadas são usadas em modelos dimensionais do data warehouse para produzir um resumo de informações pré-calculadas, as agregações geralmente são pré-computadas podendo ser carregadas diretamente da fonte de dados ou da tabela fato transacional alterando a granularidade para um nível mais alto. Com os dados resumidos carregados na tabela agregada o volume de dados é menor obtendo-se um ganho de performance considerável nas consultas comparado com um fato transacional.
Periodic snapshots – As tabelas snapshots periódico registram dados instantâneos em um período predefinido, podendo ser diariamente, semanalmente ou mensalmente. Como o nome indica tira-se uma “imagem do momento” em que o fato ocorreu, os dados de origem da tabela snapshot periódico são dados de uma tabela de fato transacional em que se escolhe um período a ser capturado.
Accumulating snapshots – As tabelas de snapshots acumulado descreve a atividade de um processo de negócios que possui início e fim. Esse tipo de tabela de fato possui várias colunas de data para representar marcos no processo. A medida em que as etapas do processo forem sendo concluídas o registro correspondente na tabela de fato é atualizado.
É isso pessoal, vou ficando por aqui 🙂
Desejo a todos ótimos estudos e nos veremos no próximo artigo, abração!
==========================================
Prof. Luis Octavio Lima
Participe da conversa