Modelagem dimensional no Microsoft Fabric Warehouse: tabelas de dimensões

Aplica-se a:✅ ponto de extremidade de análise SQL e Warehouse no Microsoft Fabric

Este artigo fornece orientação e práticas recomendadas para projetar tabelas de dimensão em um modelo dimensional. Ele fornece orientação prática para o Warehouse no Microsoft Fabric, que é uma experiência que oferece suporte a muitos recursos do T-SQL, como a criação de tabelas e o gerenciamento de dados em tabelas. Assim, você tem o controle total de criar suas tabelas de modelo dimensional e carregá-las com dados.

Em um modelo dimensional, uma tabela de dimensões descreve uma entidade relevante para seus requisitos de negócios e análise. Em termos gerais, as tabelas de dimensões representam as coisas que você modela. As coisas podem ser produtos, pessoas, lugares ou qualquer outro conceito, incluindo data e hora. Para identificar facilmente tabelas de dimensão, você normalmente prefixa seus nomes com d_ ou Dim_.

Estrutura da tabela de dimensões

Para descrever a estrutura de uma tabela de dimensão, considere o exemplo a seguir de uma tabela de dimensão de vendedor chamada d_Salesperson. Este exemplo aplica boas práticas de design. Cada um dos grupos de colunas é descrito nas seções a seguir.

CREATE TABLE d_Salesperson
(
    --Surrogate key
    Salesperson_SK INT NOT NULL,
    
    --Natural key(s)
    EmployeeID VARCHAR(20) NOT NULL,
    
    --Dimension attributes
    FirstName VARCHAR(20) NOT NULL,
    <…>
    
    --Foreign key(s) to other dimensions
    SalesRegion_FK INT NOT NULL,
    <…>
    
    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,
    
    --Audit attributes
    AuditMissing BIT NOT NULL,
    AuditIsInferred BIT NOT NULL,
    AuditCreatedDate DATE NOT NULL,
    AuditCreatedBy VARCHAR(15) NOT NULL,
    AuditLastModifiedDate DATE NOT NULL,
    AuditLastModifiedBy VARCHAR(15) NOT NULL
);

Chave de substituição

A tabela de dimensões de exemplo tem uma chave substituta, chamada Salesperson_SK. Uma chave substituta é um identificador exclusivo de coluna única que é gerado e armazenado na tabela de dimensões. É uma coluna de chave primária usada para se relacionar com outras tabelas no modelo dimensional.

As chaves substitutas se esforçam para isolar o data warehouse de alterações nos dados de origem. Eles também oferecem muitos outros benefícios, permitindo que você:

• Consolide várias fontes de dados (evitando o conflito de identificadores duplicados).
• Consolide chaves naturais de várias colunas em uma chave de coluna única mais eficiente.
• Acompanhe o histórico de dimensões com uma dimensão de mudança lenta (SCD) tipo 2.
• Limite a largura da tabela de fatos para otimização de armazenamento (selecionando o menor tipo de dados inteiro possível).

Uma coluna de chave substituta é uma prática recomendada, mesmo quando uma chave natural (descrita a seguir) parece um candidato aceitável. Você também deve evitar dar significado aos valores de chave (exceto para chaves de dimensão de data e hora, conforme descrito mais adiante).

Chaves naturais

A tabela de dimensões de exemplo também tem uma chave natural, que é chamada EmployeeID. Uma chave natural é a chave armazenada no sistema de origem. Ele permite relacionar os dados de dimensão com seu sistema de origem, o que normalmente é feito por um processo de extração, carga e transformação (ETL) para carregar a tabela de dimensão. Às vezes, uma chave natural é chamada de chave de negócios e seus valores podem ser significativos para os usuários corporativos.

Às vezes, as dimensões não têm uma chave natural. Esse pode ser o caso de sua dimensão de data ou dimensões de pesquisa, ou quando você gera dados de dimensão normalizando um arquivo simples.

Atributos de dimensão

Uma tabela de dimensão de exemplo também tem atributos de dimensão, como a FirstName coluna. Os atributos de dimensão fornecem contexto para os dados numéricos armazenados em tabelas de fatos relacionadas. Normalmente, são colunas de texto que são usadas em consultas analíticas para filtrar e agrupar (fatias e dados), mas não para serem agregadas. Algumas tabelas de dimensão contêm poucos atributos, enquanto outras contêm muitos atributos (tantos quantos forem necessários para dar suporte aos requisitos de consulta do modelo dimensional).

Se você planeja criar um modelo semântico Direct Lake, deve incluir todas as colunas possíveis necessárias para filtrar e agrupar como atributos de dimensão. Isso porque os modelos semânticos Direct Lake não suportam colunas calculadas.

Chaves estrangeiras

A tabela de dimensões de exemplo também tem uma chave estrangeira, que é chamada SalesRegion_FK. Outras tabelas de dimensão podem fazer referência a uma chave estrangeira, e sua presença em uma tabela de dimensão é um caso especial. Ele indica que a tabela está relacionada a outra tabela de dimensão, o que significa que ela pode fazer parte de uma dimensão de floco de neve ou está relacionada a uma dimensão outrigger.

O Fabric Warehouse suporta restrições de chave estrangeira, mas elas não podem ser impostas. Portanto, é importante que o processo ETL teste a integridade entre tabelas relacionadas quando os dados são carregados.

Ainda é uma boa ideia criar chaves estrangeiras. Uma boa razão para criar chaves estrangeiras não impostas é permitir que ferramentas de modelagem, como o Power BI Desktop, detetem e criem automaticamente relações entre tabelas no modelo semântico.

Atributos de rastreamento históricos

A tabela de dimensões de exemplo também tem vários atributos de acompanhamento histórico. Os atributos de acompanhamento histórico são opcionais com base na sua necessidade de controlar alterações específicas à medida que ocorrem no sistema de origem. Eles permitem armazenar valores para suportar a função principal de um data warehouse, que é descrever o passado com precisão. Especificamente, esses atributos armazenam o contexto histórico à medida que o processo ETL carrega dados novos ou alterados na dimensão.

Para obter mais informações, consulte Gerenciar alterações históricas mais adiante neste artigo.

Atributos de auditoria

A tabela de dimensões de exemplo também tem vários atributos de auditoria. Os atributos de auditoria são opcionais, mas recomendados. Eles permitem que você acompanhe quando e como os registros de dimensão foram criados ou modificados, e podem incluir informações de diagnóstico ou solução de problemas geradas durante os processos de ETL. Por exemplo, você desejará controlar quem (ou qual processo) atualizou uma linha e quando. Os atributos de auditoria também podem ajudar a diagnosticar um problema desafiador, como quando um processo de ETL é interrompido inesperadamente. Eles também podem sinalizar membros da dimensão como erros ou membros inferidos.

Tamanho da tabela de dimensões

Muitas vezes, as dimensões mais úteis e versáteis em um modelo dimensional são dimensões grandes e amplas. Eles são grandes em termos de linhas (mais de milhões) e largos em termos do número de atributos de dimensão (potencialmente centenas). O tamanho não é tão importante (embora você deva projetar e otimizar para o menor tamanho possível). O que importa é que a dimensão suporte a filtragem necessária, o agrupamento e a análise histórica precisa dos dados dos fatos.

Grandes dimensões podem ser originadas de vários sistemas de origem. Nesse caso, o processamento de dimensão precisa combinar, mesclar, desduplicar e padronizar os dados; e atribuir chaves substitutas.

Em comparação, algumas dimensões são minúsculas. Eles podem representar tabelas de pesquisa que contêm apenas vários registros e atributos. Muitas vezes, essas pequenas dimensões armazenam valores de categoria relacionados a transações em tabelas de fato, e são implementadas como dimensões com chaves substitutas para se relacionar com os registros de fatos.

Conceitos de design de dimensão

Esta seção descreve vários conceitos de design de dimensão.

Desnormalização vs. normalização

É quase sempre o caso de as tabelas de dimensões deverem ser desnormalizadas. Enquanto normalização é o termo usado para descrever dados armazenados de forma a reduzir dados repetitivos, desnormalização é o termo usado para definir onde existem dados redundantes pré-computados. Os dados redundantes existem normalmente devido ao armazenamento de hierarquias (discutido mais tarde), o que significa que as hierarquias são achatadas. Por exemplo, uma dimensão de produto pode armazenar subcategoria (e seus atributos relacionados) e categoria (e seus atributos relacionados).

Como as dimensões são geralmente pequenas (quando comparadas com tabelas de fatos), o custo de armazenamento de dados redundantes é quase sempre superado pelo melhor desempenho e usabilidade da consulta.

Dimensões dos flocos de neve

Uma exceção à desnormalização é projetar uma dimensão de floco de neve. Uma dimensão de floco de neve é normalizada e armazena os dados da dimensão em várias tabelas relacionadas.

O diagrama a seguir mostra uma dimensão de floco de neve que compreende três tabelas de dimensões relacionadas: Product, Subcategory, e Category.

Considere implementar uma dimensão de floco de neve quando:

• A dimensão é extremamente grande e os custos de armazenamento superam a necessidade de alto desempenho de consulta. (No entanto, reavalie periodicamente se este continua a ser o caso.)
• Você precisa de chaves para relacionar a dimensão com fatos de grão mais alto. Por exemplo, a tabela de fatos de vendas armazena linhas no nível do produto, mas a tabela de fatos de destino de vendas armazena linhas no nível da subcategoria.
• Você precisa acompanhar as alterações históricas em níveis mais altos de granularidade.

Hierarquias

Comumente, as colunas de dimensão produzem hierarquias. As hierarquias permitem explorar dados em níveis distintos de sumarização. Por exemplo, a visualização inicial de um visual de matriz pode mostrar vendas anuais, e o consumidor do relatório pode optar por detalhar para revelar vendas trimestrais e mensais.

Há três maneiras de armazenar uma hierarquia em uma dimensão. Pode utilizar:

• Colunas de uma única dimensão desnormalizada.
• Uma dimensão de floco de neve, que compreende várias tabelas relacionadas.
• Uma relação pai-filho (autorreferência) numa dimensão.

As hierarquias podem ser equilibradas ou desequilibradas. Também é importante entender que algumas hierarquias estão esfarrapadas.

Hierarquias equilibradas

As hierarquias equilibradas são o tipo mais comum de hierarquia. Uma hierarquia equilibrada tem o mesmo número de níveis. Um exemplo comum de uma hierarquia equilibrada é uma hierarquia de calendário em uma dimensão de data que compreende níveis para ano, trimestre, mês e data.

O diagrama a seguir mostra uma hierarquia equilibrada de regiões de vendas. Ele compreende dois níveis, que são grupo de região de vendas e região de vendas.

Os níveis de uma hierarquia equilibrada são baseados em colunas de uma única dimensão desnormalizada ou em tabelas que formam uma dimensão de floco de neve. Quando baseadas em uma única dimensão desnormalizada, as colunas que representam os níveis mais altos contêm dados redundantes.

Para hierarquias equilibradas, os factos relacionam-se sempre com um único nível da hierarquia, que é tipicamente o nível mais baixo. Dessa forma, os fatos podem ser agregados (enrolados) ao mais alto nível da hierarquia. Os factos podem relacionar-se com qualquer nível, que é determinado pelo grão da tabela de factos. Por exemplo, a tabela de fatos de vendas pode ser armazenada no nível de data, enquanto a tabela de fatos de destino de vendas pode ser armazenada no nível trimestral.

Hierarquias desequilibradas

Hierarquias desequilibradas são um tipo menos comum de hierarquia. Uma hierarquia desequilibrada tem níveis baseados numa relação pai-filho. Por esse motivo, o número de níveis em uma hierarquia desequilibrada é determinado pelas linhas de dimensão e não pelas colunas específicas da tabela de dimensões.

Um exemplo comum de uma hierarquia desequilibrada é uma hierarquia de funcionários em que cada linha em uma dimensão de funcionário se relaciona com uma linha do gerente de relatórios na mesma tabela. Neste caso, qualquer funcionário pode ser um gerente com funcionários reportantes. Naturalmente, alguns ramos da hierarquia terão mais níveis do que outros.

O diagrama a seguir mostra uma hierarquia desequilibrada. Compreende quatro níveis, e cada membro na hierarquia é um vendedor. Observe que os vendedores têm um número diferente de antepassados na hierarquia de acordo com quem eles se reportam.

Outros exemplos comuns de hierarquias desequilibradas incluem listas de materiais, modelos de propriedade da empresa e contabilidade geral.

Para hierarquias desequilibradas, os factos relacionam-se sempre com a dimensão grão. Por exemplo, os fatos de vendas estão relacionados a diferentes vendedores, que têm diferentes estruturas de relatório. A tabela de dimensões teria uma chave substituta (chamada Salesperson_SK) e uma coluna de ReportsTo_Salesperson_FK chave estrangeira, que faz referência à coluna de chave primária. Cada vendedor sem ninguém para gerenciar não está necessariamente no nível mais baixo de qualquer ramo da hierarquia. Quando não estão no nível mais baixo, um vendedor pode vender produtos e ter vendedores que também vendem produtos. Assim, o rollup de dados de fatos deve considerar o vendedor individual e todos os seus descendentes.

Consultar hierarquias pai-filho pode ser complexo e lento, especialmente para grandes dimensões. Embora o sistema de origem possa armazenar relações como pai-filho, recomendamos que você naturalize a hierarquia. Neste caso, naturalizar significa transformar e armazenar os níveis hierárquicos na dimensão como colunas.

Hierarquias desbalanceadas

Às vezes, uma hierarquia é irregular porque o pai de um membro na hierarquia existe em um nível que não está imediatamente acima dele. Nesses casos, os valores de nível ausentes repetem o valor do pai.

Considere um exemplo de uma hierarquia geográfica equilibrada. Existe uma hierarquia irregular quando um país/região não tem estados ou províncias. Por exemplo, a Nova Zelândia não tem estados nem províncias. Portanto, ao inserir a linha Nova Zelândia, você também deve armazenar o valor de país/região na StateProvince coluna.

O diagrama a seguir mostra uma hierarquia irregular de regiões geográficas.

Gerenciar mudanças históricas

Quando necessário, a mudança histórica pode ser gerida através da implementação de uma dimensão de mudança lenta (SCD). Um SCD mantém o contexto histórico à medida que dados novos ou alterados são carregados nele.

Aqui estão os tipos de SCD mais comuns.

• Tipo 1: Substitua o membro da dimensão existente.
• Tipo 2: Insira um novo membro de dimensão versionado com base no tempo.
• Tipo 3: Acompanhe o histórico limitado com atributos.

É possível que uma dimensão possa suportar alterações de SCD tipo 1 e SCD tipo 2.

SCD tipo 3 não é comumente usado, em parte devido ao fato de que é difícil de usar em um modelo semântico. Pondere cuidadosamente se uma abordagem SCD tipo 2 seria mais adequada.

SCD tipo 1

As alterações do tipo 1 do SCD substituem a linha de dimensão existente porque não há necessidade de acompanhar as alterações. Este tipo de SCD também pode ser usado para corrigir erros. É um tipo comum de SCD e deve ser usado para a maioria dos atributos que mudam, como nome do cliente, endereço de e-mail e outros.

O diagrama a seguir mostra o estado antes e depois de um membro da dimensão de vendedor onde seu número de telefone foi alterado.

Esse tipo de SCD não preserva a perspetiva histórica porque a linha existente é atualizada. Isso significa que as alterações do tipo 1 do SCD podem resultar em diferentes agregações de nível superior. Por exemplo, se um vendedor for atribuído a uma região de vendas diferente, uma alteração do tipo 1 do SCD substituirá a linha de dimensão. O rollup dos resultados históricos de vendas dos vendedores para a região produziria um resultado diferente porque agora usa a nova região de vendas atual. É como se esse vendedor estivesse sempre designado para a nova região de vendas.

SCD tipo 2

As alterações do tipo 2 do SCD resultam em novas linhas que representam uma versão baseada no tempo de um membro da dimensão. Há sempre uma linha de versão atual e ela reflete o estado do membro da dimensão no sistema de origem. Os atributos de acompanhamento histórico na tabela de dimensões armazenam valores que permitem identificar a versão atual (o sinalizador atual é TRUE) e seu período de tempo de validade. Uma chave substituta é necessária porque haverá chaves naturais duplicadas quando várias versões forem armazenadas.

É um tipo comum de SCD, mas deve ser reservado para atributos que devem preservar a perspetiva histórica.

Por exemplo, se um vendedor for atribuído a uma região de vendas diferente, uma alteração do tipo 2 do SCD envolverá uma operação de atualização e uma operação de inserção.

1. A operação de atualização substitui a versão atual para definir os atributos de rastreamento históricos. Especificamente, a coluna de validade final é definida como a data de processamento ETL (ou um carimbo de data/hora adequado no sistema de origem) e o sinalizador atual é definido como FALSE.
2. A operação insert adiciona uma nova versão atual, definindo a coluna de validade inicial como o valor da coluna de validade final (usada para atualizar a versão anterior) e o sinalizador atual como TRUE.

É importante entender que a granularidade das tabelas de fatos relacionadas não está no nível do vendedor, mas sim no nível da versão do vendedor. O rollup de seus resultados históricos de vendas para a região produzirá resultados corretos, mas haverá duas (ou mais) versões de membros vendedores para analisar.

O diagrama a seguir mostra o estado antes e depois de um membro da dimensão de vendedor onde sua região de vendas foi alterada. Como a organização deseja analisar o esforço dos vendedores pela região à qual estão atribuídos, ela dispara uma alteração de tipo 2 do SCD.

Considere os seguintes atributos de rastreamento histórico do tipo 2 do SCD.

CREATE TABLE d_Salesperson
(
    <…>

    --Historical tracking attributes (SCD type 2)
    RecChangeDate_FK INT NOT NULL,
    RecValidFromKey INT NOT NULL,
    RecValidToKey INT NOT NULL,
    RecReason VARCHAR(15) NOT NULL,
    RecIsCurrent BIT NOT NULL,

    <…>
);

Aqui estão as finalidades dos atributos de rastreamento histórico.

• A RecChangeDate_FK coluna armazena a data em que a alteração entrou em vigor. Ele permite que você consulte quando as alterações ocorreram.
• As RecValidFromKey colunas e RecValidToKey armazenam as datas efetivas de validade da linha. Considere armazenar a data mais antiga encontrada na dimensão de data para RecValidFromKey representar a versão inicial e armazenar 01/01/9999 para a RecValidToKey das versões atuais.
• A RecReason coluna é opcional. Permite documentar o motivo pelo qual a versão foi inserida. Ele pode codificar quais atributos foram alterados ou pode ser um código do sistema de origem que declara um motivo comercial específico.
• A RecIsCurrent coluna permite recuperar apenas as versões atuais. Ele é usado quando o processo ETL procura chaves de dimensão ao carregar tabelas de fatos.

SCD tipo 3

As alterações do tipo 3 do SCD controlam o histórico limitado com atributos. Essa abordagem pode ser útil quando há a necessidade de registrar a última alteração ou várias das alterações mais recentes.

Este tipo de SCD preserva uma perspetiva histórica limitada . Pode ser útil quando apenas os valores iniciais e atuais devem ser armazenados. Neste caso, não seriam necessárias alterações provisórias.

Por exemplo, se um vendedor for atribuído a uma região de vendas diferente, uma alteração do tipo 3 do SCD substituirá a linha de dimensão. Uma coluna que armazena especificamente a região de vendas anterior é definida como a região de vendas anterior e a nova região de vendas é definida como a região de vendas atual.

O diagrama a seguir mostra o estado antes e depois de um membro da dimensão de vendedor onde sua região de vendas foi alterada. Como a organização deseja determinar qualquer atribuição anterior de região de vendas, ela dispara uma alteração do tipo 3 do SCD.

Membros de dimensão especial

Você pode inserir linhas em uma dimensão que representam estados ausentes, desconhecidos, N/A ou de erro. Por exemplo, você pode usar os seguintes valores de chave substituta.

Valor-chave	Objetivo
0	Ausente (não disponível no sistema de origem)
-1	Desconhecido (falha de pesquisa durante o carregamento de uma tabela de fatos)
-2	N/A (não aplicável)
-3	Erro

Calendário e hora

Quase sem exceção, as tabelas de fatos armazenam medidas em momentos específicos. Para suportar a análise por data (e possivelmente hora), deve haver dimensões de calendário (data e hora).

É incomum que um sistema de origem tenha dados de dimensão de calendário, portanto, eles devem ser gerados no data warehouse. Normalmente, ele é gerado uma vez e, se for uma dimensão de calendário, é estendido com datas futuras quando necessário.

Dimensão de data

A dimensão de data (ou calendário) é a dimensão mais comum usada para análise. Ele armazena uma linha por data e suporta o requisito comum de filtrar ou agrupar por períodos específicos de datas, como anos, trimestres ou meses.

A chave natural da dimensão de data deve usar o tipo de dados de data . A chave substituta deve armazenar a data usando YYYYMMDD o formato e o tipo de dados int . Esta prática aceite deve ser a única exceção (a par da dimensão temporal) quando o valor-chave substituto tem significado e é legível por humanos. O armazenamento YYYYMMDD como um tipo de dados int não é apenas eficiente e classificado numericamente, mas também está em conformidade com o formato de data inequívoco da International Standards Organization (ISO) 8601.

Aqui estão alguns atributos comuns a serem incluídos em uma dimensão de data.

• Year, Quarter, Month, Day
• QuarterNumberInYear, MonthNumberInYear – que pode ser necessário para classificar rótulos de texto.
• FiscalYear, FiscalQuarter – alguns cronogramas de contabilidade corporativa começam no meio do ano, de modo que o início/fim do ano civil e do ano fiscal são diferentes.
• FiscalQuarterNumberInYear, FiscalMonthNumberInYear – que pode ser necessário para classificar rótulos de texto.
• WeekOfYear – existem várias formas de rotular a semana do ano, incluindo uma norma ISO com 52 ou 53 semanas.
• IsHoliday, HolidayText – se a sua organização opera em várias geografias, você deve manter vários conjuntos de listas de feriados que cada geografia observa como uma dimensão separada ou naturalizada em vários atributos na dimensão data. Adicionar um HolidayText atributo pode ajudar a identificar feriados para relatórios.
• IsWeekday – da mesma forma, em algumas geografias, a semana de trabalho padrão não é de segunda a sexta-feira. Por exemplo, a semana de trabalho é de domingo a quinta-feira em muitas regiões do Oriente Médio, enquanto outras regiões empregam uma semana de trabalho de quatro ou seis dias.
• LastDayOfMonth
• RelativeYearOffset, RelativeQuarterOffset, RelativeMonthOffset, RelativeDayOffset – que pode ser necessário para suportar a filtragem de data relativa (por exemplo, mês anterior). Os períodos atuais usam um deslocamento de zero (0); períodos anteriores armazenam compensações de -1, -2, -3...; períodos futuros armazenam compensações de 1, 2, 3....

Como em qualquer dimensão, o importante é que ela contenha atributos que suportem os requisitos conhecidos de filtragem, agrupamento e hierarquia. Também pode haver atributos que armazenam traduções de rótulos para outros idiomas.

Quando a dimensão é usada para se relacionar com fatos de maior grão, a tabela de fatos pode usar a primeira data do período de data. Por exemplo, uma tabela de fatos de meta de vendas que armazena metas trimestrais de vendedores armazenaria a primeira data do trimestre na dimensão de data. Uma abordagem alternativa é criar colunas-chave na tabela de datas. Por exemplo, uma chave trimestral pode armazenar a chave trimestral usando YYYYQ o formato e o tipo de dados smallint .

A dimensão deve ser preenchida com o intervalo conhecido de datas usado por todas as tabelas de fatos. Também deve incluir datas futuras em que o data warehouse armazena fatos sobre metas, orçamentos ou previsões. Tal como acontece com outras dimensões, pode incluir linhas que representam situações em falta, desconhecidas, N/A ou de erro.

Normalmente, no início do próximo ano, o processo ETL deve estender as linhas de dimensão de data para um número específico de anos à frente. Quando a dimensão inclui atributos de deslocamento relativo, o processo ETL deve ser executado diariamente para atualizar os valores dos atributos de deslocamento com base na data atual (hoje).

Dimensão temporal

Às vezes, os fatos precisam ser armazenados em um momento no tempo (como na hora do dia). Nesse caso, crie uma dimensão de tempo (ou relógio). Pode ter um grão de minutos (24 x 60 = 1.440 linhas) ou mesmo segundos (24 x 60 x 60 = 86.400 linhas). Outros grãos possíveis incluem meia hora ou hora.

A chave natural de uma dimensão de tempo deve usar o tipo de dados de tempo . A chave substituta pode usar um formato apropriado e armazenar valores que tenham significado e sejam legíveis por humanos, por exemplo, usando o HHMM formato ou HHMMSS .

Aqui estão alguns atributos comuns a serem incluídos em uma dimensão de tempo.

• Hour, HalfHour, QuarterHour, Minute
• Rótulos de período de tempo (manhã, tarde, noite, noite)
• Nomes dos turnos de trabalho
• Bandeiras de pico ou fora de pico

Dimensões conformadas

Algumas dimensões podem ser dimensões conformes. As dimensões conformadas estão relacionadas a muitas tabelas de fatos e, portanto, são compartilhadas por várias estrelas em um modelo dimensional. Eles fornecem consistência e podem ajudá-lo a reduzir o desenvolvimento e a manutenção contínuos.

Por exemplo, é típico que as tabelas de fatos armazenem pelo menos uma chave de dimensão de data (porque a atividade é quase sempre registrada por data e/ou hora). Por essa razão, uma dimensão de data é uma dimensão conformada comum. Portanto, você deve garantir que sua dimensão de data inclua atributos relevantes para a análise de todas as tabelas de fatos.

O diagrama a seguir mostra a tabela de Sales fatos e a tabela de Inventory fatos. Cada tabela de fatos refere-se à dimensão e Product dimensãoDate, que são dimensões conformadas.

Como outro exemplo, seu funcionário e usuários podem ser o mesmo conjunto de pessoas. Neste caso, pode fazer sentido combinar os atributos de cada entidade para produzir uma dimensão conforme.

Dimensões de desempenho de funções

Quando uma dimensão é referenciada várias vezes em uma tabela de fatos, ela é conhecida como uma dimensão de interpretação de papéis.

Por exemplo, quando uma tabela de fatos de vendas tem chaves de dimensão de data de pedido, data de envio e data de entrega, a dimensão de data se relaciona de três maneiras. Cada maneira representa um papel distinto, mas há apenas uma dimensão física de data.

O diagrama a seguir mostra uma tabela de Flight fatos. A Airport dimensão é uma dimensão de role-playing porque está relacionada duas vezes com a tabela de fatos como a Departure Airport dimensão e a Arrival Airport dimensão.

Dimensões do lixo

Uma dimensão lixo é útil quando há muitas dimensões independentes, especialmente quando elas compreendem alguns atributos (talvez um), e quando esses atributos têm baixa cardinalidade (poucos valores). O objetivo de uma dimensão "lixo" é consolidar muitas pequenas dimensões numa única dimensão. Essa abordagem de design pode reduzir o número de dimensões e diminuir o número de chaves de tabela de fatos e, portanto, o tamanho de armazenamento da tabela de fatos. Eles também ajudam a reduzir a confusão do painel de dados porque apresentam menos tabelas aos usuários.

Uma tabela de dimensões de lixo normalmente armazena o produto cartesiano de todos os valores de atributos de dimensão, com um atributo de chave substituta.

Bons candidatos incluem bandeiras e indicadores, status do pedido e estados demográficos do cliente (sexo, faixa etária e outros).

O diagrama a seguir mostra uma dimensão de lixo chamado Sales Status que combina valores de status de pedido e valores de status de entrega.

Dimensões degeneradas

Uma dimensão degenerada pode ocorrer quando a dimensão está no mesmo grão que os fatos relacionados. Um exemplo comum de uma dimensão degenerada é uma dimensão de número de ordem de venda relacionada a uma tabela de fatos de vendas. Normalmente, o número da fatura é um único atributo não hierárquico na tabela de fatos. Portanto, é uma prática aceita não copiar esses dados para criar uma tabela de dimensão separada.

O diagrama a seguir mostra uma Sales Order dimensão que é uma dimensão degenerada com base na coluna de SalesOrderNumber uma tabela de fatos de vendas. Essa dimensão é implementada como um modo de exibição que recupera os valores distintos do número da ordem do cliente.

De uma perspetiva de modelagem semântica do Power BI, uma dimensão degenerada pode ser criada como uma tabela separada usando o Power Query. Dessa forma, o modelo semântico está em conformidade com a prática recomendada de que os campos usados para filtrar ou agrupar são originados de tabelas de dimensão e os campos usados para resumir fatos são originados de tabelas de fatos.

Dimensões do gatilho

Quando uma tabela de dimensões se relaciona com outras tabelas de dimensão, ela é conhecida como uma dimensão outrigger. Uma dimensão outrigger pode ajudar a conformar e reutilizar definições no modelo dimensional.

Por exemplo, você pode criar uma dimensão geográfica que armazene localizações geográficas para cada código postal. Essa dimensão poderia então ser referenciada pela dimensão do cliente e pela dimensão do vendedor, que armazenaria a chave substituta da dimensão geográfica. Dessa forma, clientes e vendedores poderiam ser analisados usando localizações geográficas consistentes.

O diagrama a seguir mostra uma Geography dimensão que é uma dimensão outrigger. Não se relaciona diretamente com a tabela de Sales fatos. Em vez disso, está relacionado indiretamente através da Customer dimensão e da Salesperson dimensão.

Considere que a dimensão de data pode ser usada como uma dimensão outrigger quando outros atributos de tabela de dimensão armazenam datas. Por exemplo, a data de nascimento em uma dimensão de cliente pode ser armazenada usando a chave substituta da tabela de dimensão de data.

Dimensões multivaloradas

Quando um atributo de dimensão deve armazenar vários valores, você precisa projetar uma dimensão de vários valores. Você implementa uma dimensão de vários valores criando uma tabela ponte (às vezes chamada de tabela de junção). Uma tabela de ponte armazena uma relação muitos-para-muitos entre entidades.

Por exemplo, considere que há uma dimensão de vendedor e que cada vendedor é atribuído a uma ou possivelmente mais regiões de vendas. Neste caso, faz sentido criar uma dimensão de região de vendas. Essa dimensão armazena cada região de vendas apenas uma vez. Uma tabela separada, conhecida como tabela ponte, armazena uma linha para cada relação de vendedor e região de vendas. Fisicamente, há uma relação um-para-muitos, desde a dimensão do vendedor até a mesa da ponte, e outra relação um-para-muitos, da dimensão da região de vendas à mesa da ponte. Logicamente, há uma relação muitos-para-muitos entre vendedores e regiões de vendas.

No diagrama a seguir, a tabela de Account dimensões está relacionada à tabela de Transaction fatos. Como os clientes podem ter várias contas e as contas podem ter vários clientes, a tabela de Customer dimensões é relacionada por meio da Customer Account tabela bridge.

Conteúdos relacionados

No próximo artigo desta série, saiba mais sobre orientação e práticas recomendadas de design para tabelas de fatos.