Design Tip #124 Alternativas para Dimensões Multi-Valoradas

Um projeto dimensional pode necessitar de um relacionamento multi-valorado mais complexo entre fato e dimensão… Joy Mundy © Copyright Kimball Group, 2010 All rights reserved.

A relação normal entre fato e tabelas de dimensão é a de muitos-para-um: Uma linha da tabela fato tem um vínculo de uma e só uma linha na tabela de dimensão. Em uma tabela de fato de um evento detalhado de vendas, cada linha da tabela fato representa uma venda de um produto para um cliente em uma data específica. Cada linha em uma tabela de dimensão, como cliente único, normalmente aponta de volta para muitas linhas na tabela de fato.

Um projeto dimensional pode necessitar de um relacionamento multi-valorado mais complexo entre fato e dimensão. Por exemplo, talvez nosso sistema de entrada de ordens de venda nos deixe coletar informações sobre por que o cliente escolheu um produto específico (como preço, características, ou recomendação). Dependendo de como o sistema transacional  é projetado, fica fácil ver como um item da venda pode ser associado, potencialmente, com  muitas razões da venda.

A robustez  do chamado modo de apresentação-completa, como um relacionamento em um mundo dimensional, é semelhante a técnica de modelagem para um banco de dados transacional. A tabela de dimensão de Razão das Vendas é normal, com uma chave substituta (Surrogate Key), uma linha para cada razão das vendas, e potencialmente vários atributos como nome da razão de vendas, descrição longa, e tipo. Em nosso exemplo simples, a tabela de dimensão de razão de vendas seria bastante pequena, talvez dez linhas. Nós não podemos pôr essa chave de razão das vendas na tabela fato porque cada transação de vendas pode ser associada com muitas razões das vendas. A tabela de ponte de razão das vendas preenche esse ‘buraco’. Amarra junto todos os possíveis (ou observados) conjuntos de razões das vendas: {Preço, Preço e Características, Características e Recomendação, Preço e Características e Recomendação}. Cada um destes conjuntos de razões é amarrado junto com uma chave única de grupo de razão das vendas que é propagada na tabela de fato.

Por exemplo, a figura abaixo exibe um modelo dimensional para um fato de vendas que captura razões de vendas múltiplas:

Se nós tivermos dez razões de vendas possíveis, a tabela de Ponte de Razão das Vendas conterá  cem linhas.

O maior problema com este projeto é sua adequação para o uso por usuários ad hoc. O relacionamento multi-valorado, por sua natureza, ‘explode’ eficazmente a tabela fato. Imagine um usuário de negócios mal treinado que tenta construir um relatório que retorna uma lista de razões de vendas e quantias de vendas. É absurdamente fácil dobrar a contagem dos fatos para transações com múltiplas razões das vendas. O fator de pesagem na tabela de ponte é projetado para tratar desse assunto, mas o usuário precisa saber o que é esse fator e como usá-lo.

No nosso exemplo estamos discutindo, razão das vendas que é, provavelmente,  um ‘embelezamento’ muito secundário para uma chave de tabela fato que localiza nossas vendas. A tabela de fato de vendas é usada ao longo da organização por muitas comunidades de usuários ad hoc e estruturados, para geração de relatórios. Existem várias abordagens para o problema apresentado pelo uso de projetos de tabelas ponte. Estes incluem:

  •  Esconda a razão de vendas da maioria de usuários. Você pode publicar duas versões do esquema: O cheio para ser usado em relatórios estruturados e por usuários mais capacitados, e uma versão que elimina razão das vendas para ser usada por usuários mais casuais. 
  • Elimine a tabela de ponte usando uma única respostas possível. Adicione uma linha na tabela de dimensão razão das vendas: “Escolha por múltiplas razões.” A tabela de fato pode então se ligar diretamente com a dimensão de razão de vendas. Como todas as decisões de projeto, o Depto de TI da empresa não pode escolher esta abordagem sem consultar  a comunidade de usuário. Mas você pode ficar surpreso por ouvir quantos de seus usuários seriam absolutamente de acordo com esta abordagem. Nós freqüentemente ouvimos usuários dizerem “oh, nós já diminuímos todas as respostas múltiplas para umas poucas mesmo.” Para essa situação, algo como um código de razão (que limitou valor de informações), esta abordagem pode ser bastante aceitável.
    • Uma maneira de fazer esta abordagem mais ‘saborosa’ é ter duas versões da estrutura de dimensão, e duas chaves na tabela de fato: A chave de grupo de razão de vendas e a chave de razão de vendas diretamente. A visão do esquema que é compartilhada com a maioria de usuários casuais exibe só a relação simples; A visão para o time de relatórios e usuários mais capacitados pode também incluir a mais completa versão da tabela ponte.
  •  Identifique uma razão de vendas primária única. Pode ser possível identificar uma razão de vendas primária, ou baseada em um pouco de lógica no sistema de transação ou por via de regras de negócios. Por exemplo, usuários de negócios podem dizer a você que se o cliente escolhe preço como uma razão de vendas, então de um ponto de vista analítico, preço é a razão de vendas primária. Nossa experiência diz que é relativamente improvável que você possa tecer um algoritmo executável a partir dos usuários de negócios, mas vale a pena tentar. Como com na abordagem anterior, você pode combinar esta técnica com a abordagem diferente de tabela ponte para comunidades de usuário diferentes.
  •  Eliminar a dimensão razões das vendas. Se o domínio do espaço de escolha múltiplo é pequeno — em outras palavras, se você tiver só algumas razões das vendas possíveis — você pode eliminar a tabela de ponte criando uma tabela de dimensão com uma coluna para cada escolha. No nosso exemplo, nós temos usado a dimensão de razão das vendas com colunas para preço, características, recomendação, e outras razões das vendas. Cada atributo pode tomar o valor sim ou não. Este esquema é ilustrado abaixo:

Esta abordagem resolve o problema de explosão da tabela fato, mas cria alguns problemas na dimensão de razão das vendas. Somente é prático com um número relativamente pequeno de valores de domínio, talvez 50 ou 100. Todo atributo na dimensão original aparece como uma coluna adicional para cada valor de domínio. Talvez a maior desvantagem seja que qualquer mudança no domínio (adicionando outra razão de vendas) exige uma mudança no modelo de dados e aplicação de ETL.

Todavia, se a dimensão multi-valorada é importante para toda a comunidade de usuários ad hoc, e você tem um conjunto relativamente pequeno e estático de valores de domínio, esta abordagem pode ser mais atraente que a técnica de tabela de ponte. Fica muito mais fácil para os usuários de negócios construírem consultas significativas.

Claramente a eliminação de dimensão não funciona para todas as dimensões multi-valoradas. O exemplo clássico de uma dimensão multi-valorada: múltiplos diagnósticos para os pacientes de um hospital — tem um domínio extremamente grande de valores possíveis para se encaixar na estrutura de colunas.

A abordagem de projeto de tabela ponte para dimensões multi-valoradas, que o Grupo Kimball descreveu muitas vezes durante as últimas décadas, é, ainda, o melhor. Mas a técnica exige uma comunidade de usuários treinados, e treinamento de usuário parece ser um dos primeiros lugares, no orçamento, em que o machado cortante é aplicado. Em algumas circunstâncias, os problemas de adequação para o uso podem ser diminuídos, apresentando-se uma alternativa, simplificando a estrutura para a comunidade de usuários ad hoc.

Até a próxima!!! 

 

Uma resposta to “Design Tip #124 Alternativas para Dimensões Multi-Valoradas”

  1. Rodrigo Magalhães Says:

    Excelente, se todos tivessem os conceitos na ponta da língua seria tudo mais fácil.
    Abraços.


Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: