Dimensão (data warehouse) - Dimension (data warehouse)

Este artigo é sobre uma dimensão em um data warehouse . Para outros usos, veja dimensão (desambiguação) .
Uma tabela de dimensão em um cubo OLAP com um esquema em estrela

Uma dimensão é uma estrutura que categoriza fatos e medidas para permitir que os usuários respondam a perguntas de negócios. As dimensões comumente usadas são pessoas, produtos, lugar e tempo. (Observação: as pessoas e o tempo às vezes não são modelados como dimensões.)

Em um data warehouse , as dimensões fornecem informações de rotulagem estruturadas para medidas numéricas não ordenadas. A dimensão é um conjunto de dados composto de elementos de dados individuais não sobrepostos . As funções principais das dimensões são três: fornecer filtragem, agrupamento e rotulagem.

Essas funções são freqüentemente descritas como " fatiar e dados ". Um exemplo comum de data warehouse envolve vendas como medida, com cliente e produto como dimensões. Em cada venda, um cliente compra um produto. Os dados podem ser divididos removendo todos os clientes, exceto para um grupo em estudo, e então divididos por agrupamento por produto.

Um elemento de dados dimensionais é semelhante a uma variável categórica em estatísticas.

Normalmente, as dimensões em um data warehouse são organizadas internamente em uma ou mais hierarquias. "Data" é uma dimensão comum, com várias hierarquias possíveis:

  • "Dias (agrupados em) Meses (agrupados em) Anos",
  • "Dias (agrupados em) Semanas (agrupados em) Anos"
  • "Dias (agrupados em) Meses (agrupados em) Trimestres (agrupados em) Anos"
  • etc.

Tipos

Dimensão conformada

Uma dimensão conformada é um conjunto de atributos de dados que foram fisicamente referenciados em várias tabelas de banco de dados usando o mesmo valor de chave para se referir à mesma estrutura, atributos, valores de domínio, definições e conceitos. Uma dimensão conformada atravessa muitos fatos.

As dimensões são conformadas quando são exatamente as mesmas (incluindo chaves) ou uma é um subconjunto apropriado da outra. Mais importante, os cabeçalhos de linha produzidos em dois conjuntos de respostas diferentes da (s) mesma (s) dimensão (ões) conformada (s) devem ser capazes de combinar perfeitamente. '

As dimensões conformadas são subconjuntos matemáticos idênticos ou estritos da dimensão mais granular e detalhada. As tabelas de dimensão não são conformadas se os atributos forem rotulados de forma diferente ou contiverem valores diferentes. As dimensões conformadas vêm em vários sabores diferentes. No nível mais básico, as dimensões conformadas significam exatamente a mesma coisa com todas as tabelas de fatos possíveis às quais estão unidas. A tabela de dimensão de data conectada aos fatos de vendas é idêntica à dimensão de data conectada aos fatos de estoque.

Dimensão de lixo

Uma dimensão de lixo é um agrupamento conveniente de sinalizadores e indicadores de baixa cardinalidade. Ao criar uma dimensão abstrata, esses sinalizadores e indicadores são removidos da tabela de fatos ao serem colocados em uma estrutura dimensional útil. Uma dimensão de lixo é uma tabela de dimensão que consiste em atributos que não pertencem à tabela de fatos ou a qualquer uma das tabelas de dimensão existentes. A natureza desses atributos é geralmente de texto ou vários sinalizadores, por exemplo, comentários não genéricos ou apenas indicadores simples sim / não ou verdadeiro / falso. Esses tipos de atributos normalmente permanecem quando todas as dimensões óbvias no processo de negócios foram identificadas e, portanto, o designer se depara com o desafio de onde colocar esses atributos que não pertencem às outras dimensões.

Uma solução é criar uma nova dimensão para cada um dos atributos restantes, mas devido à sua natureza, pode ser necessário criar um grande número de novas dimensões resultando em uma tabela de fatos com um número muito grande de chaves estrangeiras. O designer também pode decidir deixar os atributos restantes na tabela de fatos, mas isso pode tornar o comprimento da linha da tabela desnecessariamente grande se, por exemplo, o atributo for uma sequência de texto longa.

A solução para esse desafio é identificar todos os atributos e, em seguida, colocá-los em uma ou várias dimensões de lixo. Uma dimensão de lixo pode conter vários indicadores verdadeiro / falso ou sim / não que não têm correlação entre si, portanto, seria conveniente converter os indicadores em um atributo mais descritivo. Um exemplo seria um indicador sobre a chegada de um pacote: em vez de indicar “sim” ou “não”, seria convertido em “chegado” ou “pendente” na dimensão do lixo. O designer pode escolher construir a tabela de dimensão de forma que ela acabe mantendo todos os indicadores que ocorrem com todos os outros indicadores, de forma que todas as combinações sejam cobertas. Isso configura um tamanho fixo para a própria tabela, que seria 2 x linhas, onde x é o número de indicadores. Esta solução é apropriada em situações onde o projetista esperaria encontrar muitas combinações diferentes e onde as combinações possíveis são limitadas a um nível aceitável. Em uma situação onde o número de indicadores é grande, criando uma tabela muito grande ou onde o designer espera apenas encontrar algumas das combinações possíveis, seria mais apropriado construir cada linha na dimensão de lixo à medida que novas combinações são encontradas . Para limitar o tamanho das tabelas, várias dimensões de lixo podem ser apropriadas em outras situações, dependendo da correlação entre vários indicadores.

Dimensões de lixo também são apropriadas para colocar atributos como comentários não genéricos da tabela de fatos. Esses atributos podem consistir em dados de um campo de comentário opcional quando um cliente faz um pedido e, como resultado, provavelmente estarão em branco em muitos casos. Portanto, a dimensão de lixo deve conter uma única linha que representa os espaços em branco como uma chave substituta que será usada na tabela de fatos para cada linha retornada com um campo de comentário em branco.

Dimensão degenerada

Uma dimensão degenerada é uma chave, como um número de transação, número de fatura, número de bilhete ou número de conhecimento de embarque, que não tem atributos e, portanto, não se junta a uma tabela de dimensão real. Dimensões degeneradas são muito comuns quando a granulação de uma tabela de fatos representa um único item de transação ou item de linha porque a dimensão degenerada representa o identificador exclusivo do pai. As dimensões degeneradas geralmente desempenham um papel integral na chave primária da tabela de fatos.

Dimensão RPG

As dimensões geralmente são recicladas para vários aplicativos no mesmo banco de dados. Por exemplo, uma dimensão "Data" pode ser usada para "Data de Venda", bem como "Data de Entrega" ou "Data de Aluguer". Isso é freqüentemente referido como uma "dimensão de desempenho de papéis". Isso pode ser implementado usando uma visão sobre a mesma tabela de dimensão.

Dimensão Outrigger

Normalmente, as tabelas de dimensão não fazem referência a outras dimensões por meio de chaves estrangeiras. Quando isso acontece, a dimensão referenciada é chamada de dimensão estabilizadora . As dimensões do estabilizador devem ser consideradas um antipadrão do data warehouse: é considerada uma prática melhor usar algumas tabelas de fatos que relacionam as duas dimensões.

Dimensão encolhida

Uma dimensão conformada é considerada uma dimensão reduzida quando inclui um subconjunto das linhas e / ou colunas da dimensão original.

Dimensão da data do calendário

Um tipo especial de dimensão pode ser usado para representar datas com a granularidade de um dia. As datas seriam referenciadas em uma tabela de fatos como chaves estrangeiras para uma dimensão de data. A chave primária de dimensão de data pode ser uma chave substituta ou um número usando o formato AAAAMMDD.

A dimensão da data pode incluir outros atributos como a semana do ano ou sinalizadores que representam dias úteis, feriados, etc. Também pode incluir linhas especiais que representam: datas desconhecidas ou datas ainda a serem definidas. A dimensão de data deve ser inicializada com todas as datas necessárias, digamos, os próximos 10 anos de datas, ou mais, se necessário, ou datas anteriores, se eventos no passado forem tratados.

Em vez disso, o tempo geralmente é melhor representado como um carimbo de data / hora na tabela de fatos .

Uso de termos de representação ISO

Ao fazer referência a dados de um registro de metadados , como ISO / IEC 11179 , termos de representação como "Indicador" (um valor booleano verdadeiro / falso), "Código" (um conjunto de valores enumerados não sobrepostos) são normalmente usados ​​como dimensões. Por exemplo, usando o National Information Exchange Model (NIEM), o nome do elemento de dados seria "PersonGenderCode" e os valores enumerados poderiam ser "masculino", "feminino" e "desconhecido".

Tabela de dimensão

No armazenamento de dados , uma tabela de dimensão faz parte do conjunto de tabelas complementares a uma tabela de fatos .

A tabela de fatos contém fatos de negócios (ou medidas ) e chaves estrangeiras que se referem a chaves candidatas (normalmente chaves primárias ) nas tabelas de dimensão.

Ao contrário das tabelas de fatos , as tabelas de dimensão contêm atributos descritivos (ou campos) que são tipicamente campos textuais (ou números discretos que se comportam como texto). Esses atributos são projetados para servir a dois propósitos críticos: restrição e / ou filtragem de consulta e rotulagem do conjunto de resultados da consulta.

Os atributos de dimensão devem ser:

  • Detalhado (rótulos que consistem em palavras completas)
  • Descritivo
  • Completo (sem valores ausentes)
  • Com valores discretos (tendo apenas um valor por linha da tabela de dimensão)
  • Qualidade garantida (sem erros ortográficos ou valores impossíveis)

As linhas da tabela de dimensões são identificadas exclusivamente por um único campo-chave. Recomenda-se que o campo-chave seja um número inteiro simples porque um valor-chave não faz sentido, usado apenas para unir campos entre as tabelas de fatos e dimensões. As tabelas de dimensão geralmente usam chaves primárias que também são chaves substitutas. As chaves substitutas costumam ser geradas automaticamente (por exemplo, uma "coluna de identidade" do Sybase ou SQL Server, um serial PostgreSQL ou Informix, um Oracle SEQUENCE ou uma coluna definida com AUTO_INCREMENT no MySQL).

O uso de chaves de dimensão substitutas traz várias vantagens, incluindo:

  • Desempenho . O processamento de junção é muito mais eficiente usando um único campo (a chave substituta )
  • Buffer de práticas de gerenciamento de chave operacional. Isso evita situações em que as linhas de dados removidas podem reaparecer quando suas chaves naturais são reutilizadas ou reatribuídas após um longo período de dormência
  • Mapeamento para integrar fontes díspares
  • Tratamento de conexões desconhecidas ou não aplicáveis
  • Acompanhamento de mudanças em valores de atributo de dimensão

Embora o uso de surrogate key sobrecarregue o sistema ETL , o processamento de pipeline pode ser aprimorado e as ferramentas ETL possuem processamento de surrogate key aprimorado.

O objetivo de uma tabela de dimensão é criar dimensões padronizadas e conformadas que podem ser compartilhadas em todo o ambiente de data warehouse da empresa e permitir a junção a várias tabelas de fatos que representam vários processos de negócios.

As dimensões conformadas são importantes para a natureza empresarial dos sistemas DW / BI porque promovem:

  • Consistência. Cada tabela de fatos é filtrada de forma consistente, para que as respostas da consulta sejam rotuladas de forma consistente.
  • Integração. As consultas podem fazer drill em diferentes tabelas de fatos de processos separadamente e, em seguida, unir os resultados em atributos de dimensão comuns.
  • Tempo de desenvolvimento reduzido para o mercado. As dimensões comuns estão disponíveis sem recriá-las.

Com o tempo, os atributos de uma determinada linha em uma tabela de dimensão podem mudar. Por exemplo, o endereço de entrega de uma empresa pode mudar. Kimball se refere a esse fenômeno como uma dimensão que muda lentamente . As estratégias para lidar com esse tipo de mudança são divididas em três categorias:

  • Digite um: simplesmente substitua os valores antigos.
  • Tipo dois: adicione uma nova linha contendo o (s) novo (s) valor (es) e diferencie entre as linhas usando técnicas de controle de versão em tupla .
  • Digite três: adicione um novo atributo à linha existente.

Padrões comuns

Data e hora

Como muitas tabelas de fatos em um data warehouse são séries temporais de observações, uma ou mais dimensões de data são frequentemente necessárias. Um dos motivos para ter dimensões de data é colocar o conhecimento do calendário no data warehouse em vez de codificá-lo em um aplicativo. Embora um carimbo de data / hora SQL simples seja útil para fornecer informações precisas sobre a hora em que um fato foi registrado, ele não pode fornecer informações sobre feriados, períodos fiscais, etc. Um carimbo de data / hora SQL ainda pode ser útil para armazenar na tabela de fatos, pois permite cálculos precisos.

Ter a data e a hora do dia na mesma dimensão pode facilmente resultar em uma dimensão enorme com milhões de linhas. Se uma grande quantidade de detalhes for necessária, geralmente é uma boa ideia dividir a data e a hora em duas ou mais dimensões separadas. Uma dimensão de tempo com um grão de segundos em um dia terá apenas 86400 linhas. Um grão mais ou menos detalhado para dimensões de data / hora pode ser escolhido dependendo das necessidades. Como exemplos, as dimensões de data podem ser precisas para ano, trimestre, mês ou dia e as dimensões de tempo podem ser precisas para horas, minutos ou segundos.

Como regra geral, a dimensão da hora do dia só deve ser criada se os agrupamentos hierárquicos forem necessários ou se houver descrições textuais significativas para períodos de tempo dentro do dia (por exemplo, "pico da noite" ou "primeiro turno").

Se as linhas em uma tabela de fatos vierem de vários fusos horários, pode ser útil armazenar a data e a hora tanto no horário local quanto no horário padrão. Isso pode ser feito tendo duas dimensões para cada dimensão de data / hora necessária - uma para a hora local e outra para a hora padrão. O armazenamento de data / hora tanto no horário local quanto no horário padrão permitirá a análise de quando os fatos são criados em um ambiente local e também global. A hora padrão escolhida pode ser uma hora padrão global (ex. UTC ), pode ser a hora local da sede da empresa ou qualquer outro fuso horário que faça sentido usar.

Veja também

Referências

  1. ^ " Oracle Data Warehousing Guide ", Oracle Corporation, recuperado em 9 de junho de 2014
  2. ^ Definição: Dimension "Search Data Management, TechTarget, recuperado em 9 de junho de 2014
  3. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Segunda Edição, Wiley Computer Publishing, 2002. ISBN  0471-20024-7 , Páginas 82-87, 394
  4. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Segunda Edição, Wiley Computer Publishing, 2002. ISBN  0471-20024-7 , Pages 202, 405
  5. ^ Kimball, Ralph, e outros. (2008): The Data Warehouse Lifecycle Toolkit, segunda edição, Wiley Publishing Inc., Indianapolis, IN. Páginas 263-265
  6. ^ Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Complete Guide to Dimensional Modeling, Segunda Edição, Wiley Computer Publishing, 2002. ISBN  0471-20024-7 , Pages 50, 398
  7. ^ Ralph Kimball; Margy Ross (2013). The Data Wharehouse Toolkit 3ª edição . Wiley. p. 50. ISBN  978-1-118-53080-1.
  8. ^ Ralph Kimball; Margy Ross (2013). The Data Wharehouse Toolkit 3ª edição . Wiley. p. 51. ISBN  978-1-118-53080-1.
  9. ^ Ralph Kimball; Margy Ross (2013). The Data Wharehouse Toolkit 3ª edição . Wiley. p. 48. ISBN  978-1-118-53080-1.
  10. ^ Ralph Kimball, The Data Warehouse Toolkit, Segunda Edição, Wiley Publishing, Inc., 2008. ISBN  978-0-470-14977-5 , Páginas 253-256