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

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

Observação

Este artigo faz parte da série sobre Modelagem Dimensional. Esta série se concentra nas diretrizes e melhores práticas de design relacionadas à modelagem dimensional no Warehouse do Microsoft Fabric.

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

Observação

Neste artigo, o termo data warehouse refere-se a um data warehouse empresarial, que oferece integração abrangente de dados críticos em toda a organização. Por outro lado, o termo autônomo warehouse refere-se a um Warehouse do Fabric, uma oferta de banco de dados relacional de software como serviço (SaaS) que pode ser usada para implementar um data warehouse. Para maior clareza, neste artigo, este último termo é mencionado como Fabric Warehouse.

Dica

Caso não tenha experiência com modelagem dimensional, esta série de artigos é o primeiro passo. Ela não se destina a fornecer uma discussão completa sobre o projeto de modelagem dimensional. Para obter mais informações, consulte diretamente o conteúdo publicado amplamente adotado, como The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3ª edição, 2013) de Ralph Kimball e outros.

Em um modelo dimensional, uma tabela de dimensões descreve uma entidade relevante para seus requisitos de negócios e de análise. Em linhas 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 as tabelas de dimensões, você normalmente prefixa seus nomes com d_ ou Dim_.

Estrutura da tabela de dimensões

Para descrever a estrutura de uma tabela de dimensões, considere o exemplo a seguir de uma tabela de dimensões referente a um vendedor chamada d_Salesperson. Este exemplo aplica as 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 alternativa

A amostra da tabela de dimensões tem uma chave alternativa, chamada Salesperson_SK. Uma chave alternativa é um identificador exclusivo de coluna única 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 alternativas isolam o data warehouse de alterações nos dados de origem. Elas também fornecem muitos outros benefícios, permitindo que você:

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

Uma coluna de chave alternativa é 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 temporal e de data, conforme descrito posteriormente).

Chaves naturais

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

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

Atributos de dimensão

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

Dica

Uma boa maneira de determinar quais dimensões e atributos são necessários é encontrando as pessoas certas e fazendo as perguntas certas. Especificamente, preste atenção à menção da palavra por. Por exemplo, quando alguém diz que precisa analisar as vendas por vendedor, por mês e por categoria de produto, significa que precisa de dimensões com esses atributos.

Caso planeje criar um modelo semântico do Direct Lake, inclua todas as colunas possíveis necessárias para filtragem e agrupamento como atributos de dimensão. Isso ocorre porque os modelos semânticos do Direct Lake não oferecem suporte a colunas calculadas.

Chaves estrangeiras

A amostra da tabela de dimensões também tem uma chave estrangeira, chamada SalesRegion_FK. Outras tabelas de dimensões podem fazer referência a uma chave estrangeira, e sua presença em uma tabela de dimensões é um caso especial. Isso indica que a tabela está relacionada a outra tabela de dimensões, ou seja, que ela pode fazer parte de uma dimensão do Snowflake ou está relacionada a uma dimensão de tabela de dimensões.

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

Ainda é uma boa ideia criar chaves estrangeiras. Um bom motivo para criar chaves estrangeiras não impostas é permitir que ferramentas de modelagem, como o Power BI Desktop, detectem e criem automaticamente relacionamentos entre tabelas no modelo semântico.

Atributos de acompanhamento histórico

A amostra da tabela de dimensões 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 dar suporte à 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 de ETL carrega dados novos ou alterados na dimensão.

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

Atributos de auditoria

A amostra da tabela de dimensões também tem vários atributos de auditoria. Os atributos de auditoria são opcionais, mas recomendados. Eles permitem controlar 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, convém controlar quem (ou qual processo) atualizou uma linha e quando isso ocorreu. Os atributos de auditoria também podem ajudar a diagnosticar um problema desafiador, como quando um processo de ETL para inesperadamente. Além disso, sinalizam 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 grandes e amplas. Elas são grandes em termos de linhas (mais de milhões) e amplas em termos de 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 importante é que a dimensão ofereça suporte à filtragem, ao agrupamento e à análise histórica precisa dos dados de fatos que são necessários.

Grandes dimensões podem ser originadas de vários sistemas de origem. Nesse caso, o processamento de dimensões precisa combinar, mesclar, eliminar a duplicação e padronizar os dados, além de atribuir chaves alternativas.

Em comparação, algumas dimensões são minúsculas. Elas 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, sendo implementadas como dimensões com chaves alternativas para se relacionar aos registros de fatos.

Dica

Quando você tiver muitas dimensões pequenas, considere consolidá-las em uma dimensão de lixo eletrônico.

Conceitos de design de dimensão

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

Desnormalização versus normalização

As tabelas de dimensões quase sempre devem ser desnormalizadas. Enquanto normalização é o termo que descreve dados armazenados de forma a reduzir os dados repetitivos, a desnormalização é usada para definir onde existem dados redundantes pré-computados. Normalmente, os dados redundantes existem devido ao armazenamento de hierarquias (discutidas mais adiante), o que significa que as hierarquias são niveladas. Por exemplo, uma dimensão do produto poderia armazenar subcategoria (e seus atributos relacionados) e categoria (e seus atributos relacionados).

Como as dimensões costumam ser pequenas (quando comparadas às tabelas de fatos), o custo de armazenar dados redundantes quase sempre é compensado pela melhoria do desempenho e da usabilidade da consulta.

Dimensões de floco de neve

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

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

Considere implementar uma dimensão do Snowflake quando:

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

Observação

Lembre-se de que uma hierarquia em um modelo semântico do Power BI só pode ser baseada em colunas de uma única tabela do modelo semântico. Portanto, uma dimensão do Snowflake deve entregar um resultado desnormalizado usando uma exibição que une as tabelas do Snowflake.

Hierarquias

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

Há três maneiras de armazenar uma hierarquia em uma dimensão. Você pode usar:

• Colunas de uma única dimensão desnormalizada.
• Uma dimensão do Snowflake, que compreende várias tabelas relacionadas.
• Um relacionamento entre elementos pais e filhos (autorreferencial) em uma dimensão.

As hierarquias podem ser equilibradas ou desbalanceadas. Também é importante entender que algumas hierarquias são irregulares.

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 de ano, trimestre, mês e data.

O diagrama a seguir descreve uma hierarquia equilibrada de regiões de vendas. Ele é composto por dois níveis, sendo eles 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 do Snowflake. Quando baseadas em uma única dimensão desnormalizada, as colunas que representam os níveis mais altos contêm dados redundantes.

Em hierarquias equilibradas, os fatos sempre se relacionam a um único nível da hierarquia, que normalmente é o nível mais baixo. Dessa forma, os fatos podem ser agregados (acumulados) ao nível mais alto da hierarquia. Os fatos podem se relacionar a qualquer nível, o que é determinado pela granularidade da tabela de fatos. Por exemplo, a tabela de fatos de vendas pode ser armazenada no nível da data, enquanto a tabela de fatos de metas de vendas pode ser armazenada no nível do trimestre.

Hierarquias desbalanceadas

As hierarquias desbalanceadas são um tipo menos comum de hierarquia. Uma hierarquia desbalanceada tem níveis baseados em um relacionamento entre elementos pais e filhos. Por esse motivo, o número de níveis em uma hierarquia desbalanceada é determinado pelas linhas de dimensão e não por colunas específicas da tabela de dimensões.

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

O diagrama a seguir descreve uma hierarquia desbalanceada. Ele é composto por quatro níveis, e cada membro da hierarquia é um vendedor. Observe que os vendedores têm um número diferente de ancestrais na hierarquia de acordo com sua subordinação.

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

Em hierarquias desbalanceadas, os fatos sempre se relacionam com a granularidade da dimensão. Por exemplo, os fatos de vendas estão relacionados a vendedores diferentes, com estruturas de subordinação diferentes. A tabela de dimensões teria uma chave alternativa (chamada Salesperson_SK) e uma coluna de chave estrangeira ReportsTo_Salesperson_FK, que faz referência à coluna da 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á no nível mais baixo, um vendedor pode vender produtos e ter vendedores subordinados que também vendem produtos. Assim, o rollup de dados de fatos deve considerar o vendedor individual e todos os seus descendentes.

Consultar hierarquias de pai e filho pode ser complexo e lento, principalmente em grandes dimensões. Embora o sistema de origem possa armazenar relacionamentos como pai e filho, recomendamos naturalizar a hierarquia. Nesse caso, naturalizar significa transformar e armazenar os níveis de hierarquia na dimensão como colunas.

Dica

Se você optar por não naturalizar a hierarquia, ainda poderá criar uma com base em um relacionamento entre elementos pais e filhos em um modelo semântico do Power BI. No entanto, essa abordagem não é recomendada para grandes dimensões. Para saber mais, confira Compreensão das funções para hierarquias pai-filho no DAX.

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 desbalanceada 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 referente à Nova Zelândia, você também deve armazenar o valor de país/região na coluna StateProvince.

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

Gerenciar alterações históricas

Quando necessário, a mudança histórica pode ser gerenciada implementando uma dimensão variável lenta (SCD). Uma SCD mantém o contexto histórico à medida que dados novos ou alterados são carregados nele.

Estes são os tipos de SCD mais comuns.

• Tipo 1: substitui o membro da dimensão existente.
• Tipo 2: insere um novo membro da dimensão com controle de versão baseado em hora.
• Tipo 3: controla o histórico limitado com atributos.

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

A SCD do tipo 3 não é comumente usada, em parte porque é difícil usá-la em um modelo semântico. Considere cuidadosamente se uma abordagem com SCD do tipo 2 seria mais adequada.

Dica

Se você antecipar uma dimensão variável rápida, que é uma dimensão com um atributo que muda com frequência, considere adicionar esse atributo à tabela de fatos. Se o atributo for numérico, como o preço do produto, você pode adicioná-lo como uma medida na tabela de fatos. Se o atributo for um valor de texto, você pode criar uma dimensão com base em todos os valores de texto e adicionar a chave de dimensão à tabela de fatos.

SCD do tipo 1

As alterações de SCD do tipo 1 substituem a linha de dimensão existente porque não há necessidade de controlar as alterações. Esse 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 de alteração, 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 do vendedor cujo número de telefone foi alterado.

Esse tipo de SCD não preserva a perspectiva histórica porque a linha existente é atualizada. Isso significa que as alterações de SCD do tipo 1 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 de SCD do tipo 1 substituirá a linha de dimensão. O rollup dos resultados históricos de vendas dos vendedores para a região produziria um resultado final diferente porque agora usa a região de vendas atual. É como se aquele vendedor estivesse sempre atribuído à nova região de vendas.

SCD do tipo 2

As alterações de SCD do tipo 2 resultam em novas linhas que representam uma versão baseada em hora de um membro da dimensão. Há sempre uma linha de versão atual que reflete o estado do membro da dimensão no sistema de origem. Os atributos de controle 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 validade. Uma chave alternativa é 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 preservam a perspectiva histórica.

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

1. A operação de atualização substitui a versão atual para definir os atributos de controle histórico. Especificamente, a coluna de validade final é definida como a data de processamento de ETL (ou um carimbo de data/hora adequado no sistema de origem) e o sinalizador atual é definido como FALSE.
2. A operação de inserção adiciona uma nova versão atual, definindo a coluna de validade inicial para o valor da coluna de validade final (usado para atualizar a versão anterior) e o sinalizador atual para 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 dos resultados históricos de vendas para a região produzirá resultados corretos, mas haverá duas (ou mais) versões de membros do vendedor para analisar.

O diagrama a seguir mostra o estado antes e depois de um membro da dimensão do vendedor cuja 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 aciona uma alteração de SCD do tipo 2.

Dica

Quando uma tabela de dimensões oferece suporte a alterações de SCD do tipo 2, você deve incluir um atributo de rótulo que descreva o membro e a versão. Considere um exemplo quando a vendedora Lynn Tsoflias da Adventure Works muda a atribuição da região de vendas australiana para a região de vendas do Reino Unido. O atributo de rótulo da primeira versão poderia ser "Lynn Tsoflias (Austrália)" e o atributo de rótulo da nova versão atual poderia ser "Lynn Tsoflias (Reino Unido)". Se for útil, você também pode incluir as datas de validade no rótulo.

Você deve equilibrar a necessidade de precisão histórica com a usabilidade e eficiência. Tente evitar muitas alterações de SCD do tipo 2 em uma tabela de dimensões, porque isso pode resultar em um número esmagador de versões que dificultam a compreensão dos analistas.

Além disso, muitas versões podem indicar que um atributo de alteração é melhor armazenado na tabela de fatos. Ampliando o exemplo anterior, se as alterações na região de vendas fossem frequentes, a região de vendas poderia ser armazenada como uma chave de dimensão na tabela de fatos em vez de implementar uma SCD do tipo 2.

Considere os atributos a seguir referentes ao controle histórico de SCD do tipo 2.

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,

    <…>
);

Estas são as finalidades dos atributos de controle histórico.

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

Observação

Alguns sistemas de origem não armazenam alterações históricas, por isso é importante que a dimensão seja processada regularmente para detectar alterações e implementar novas versões. Dessa forma, você pode detectar alterações logo após elas ocorrerem, e suas datas de validade serão precisas.

SCD do tipo 3

As alterações de SCD do tipo 3 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 alterações mais recentes.

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

Por exemplo, se um vendedor for atribuído a uma região de vendas diferente, uma alteração de SCD do tipo 3 substitui 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 do vendedor cuja região de vendas foi alterada. Como a organização deseja determinar qualquer atribuição de região de vendas anterior, ela aciona uma alteração de SCD do tipo 3.

Membros da dimensão especial

Você pode inserir linhas em uma dimensão que represente estados ausentes, desconhecidos, N/D ou de erro. Por exemplo, você pode usar os valores de chave alternativa a seguir.

Valor de chave	Finalidade
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 pontos específicos no tempo. Para apoiar a análise por data (e possivelmente por 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, é ampliado 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. Ela armazena uma linha por data e oferece suporte ao requisito comum de filtrar ou agrupar por períodos específicos de datas, como anos, trimestres ou meses.

Importante

Uma dimensão de data não deve incluir uma granularidade que se estenda à hora do dia. Se a análise de hora do dia for necessária, você deverá ter uma dimensão de data e uma dimensão temporal (descrita a seguir). As tabelas de fatos que armazenam fatos de hora do dia devem ter duas chaves estrangeiras, uma para cada uma dessas dimensões.

A chave natural da dimensão de data deve usar o tipo de dados date. A chave alternativa deve armazenar a data usando o formato YYYYMMDD e o tipo de dados int. Essa prática aceita deve ser a única exceção (com a dimensão temporal) quando o valor da chave alternativa tem significado e é legível por humanos. Armazenar 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.

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

• Year, Quarter, Month, Day
• QuarterNumberInYear, MonthNumberInYear: que podem ser necessários 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 podem ser necessários para classificar rótulos de texto.
• WeekOfYear: há várias maneiras de rotular a semana do ano, incluindo um padrão ISO com 52 ou 53 semanas.
• IsHoliday, HolidayText: se a organização opera em várias regiões geográficas, você deve manter vários conjuntos de listas de feriados que cada região observa como uma dimensão separada ou naturalizada em vários atributos na dimensão de data. Adicionar um atributo HolidayText pode ajudar a identificar feriados para relatórios.
• IsWeekday: da mesma forma, em algumas regiões geográficas, 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 podem ser necessários para dar suporte à filtragem de data relativa (por exemplo, mês anterior). Os períodos atuais usam um deslocamento de zero (0); períodos anteriores armazenam deslocamentos de -1, -2, -3...; períodos futuros armazenam deslocamentos de 1, 2, 3....

Como ocorre em qualquer dimensão, o importante é que ela contenha atributos que ofereçam suporte aos 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 granularidade, a tabela de fatos pode usar a primeira data do período de data. Por exemplo, uma tabela de fatos de metas de vendas que armazena metas trimestrais de vendedores armazenaria a primeira data do trimestre na dimensão de data. Uma abordagem alternativa é criar colunas de chave na tabela de datas. Por exemplo, uma chave trimestral poderia armazenar a chave trimestral usando o formato YYYYQ 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. Ela também deve incluir datas futuras quando o data warehouse armazena fatos sobre metas, orçamentos ou previsões. Assim como acontece com outras dimensões, você pode incluir linhas que representam situações ausentes, desconhecidas, N/D ou de erro.

Dica

Pesquise na internet por "gerador de dimensão de data" para encontrar scripts e planilhas que geram dados de data.

Normalmente, no início do ano seguinte, o processo de ETL deve ampliar 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 de ETL deve ser executado diariamente para atualizar os valores de atributo de deslocamento com base na data atual (hoje).

Dimensão de tempo

Às vezes, os fatos precisam ser armazenados em um ponto no tempo (como na hora do dia). Nesse caso, crie uma dimensão temporal (ou de relógio). Ela pode ter uma granularidade de minutos (24 x 60 = 1.440 linhas) ou até segundos (24 x 60 x 60 = 86.400 linhas). Outras granularidades possíveis incluem meia hora ou uma hora.

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

Estes são alguns atributos comuns a serem incluídos em uma dimensão temporal.

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

Dimensões conformes

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

Por exemplo, é comum 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 conforme 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 fatos Sales e a tabela de fatos Inventory. Cada tabela de fatos está relacionada à dimensão Date e à dimensão Product, que são dimensões conformes.

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

Dimensões com função múltipla

Quando uma dimensão é referenciada várias vezes em uma tabela de fatos, ela é conhecida como uma dimensão com função múltipla.

Por exemplo, quando uma tabela de fatos de vendas tem chaves de dimensão referentes à data do pedido, data de remessa e data de entrega, a dimensão de data se relaciona de três maneiras. Cada uma representa uma função distinta, mas há apenas uma dimensão de data física.

O diagrama a seguir mostra uma tabela de fatos Flight. A dimensão Airport é uma dimensão com função múltipla porque está relacionada duas vezes com a tabela de fatos, como a dimensão Departure Airport e a dimensão Arrival Airport.

Dimensões de lixo eletrônico

Uma dimensão de lixo eletrônico é útil quando há muitas dimensões independentes, principalmente quando compreendem alguns atributos (talvez um) e quando esses atributos têm baixa cardinalidade (poucos valores). O objetivo de uma dimensão de lixo eletrônico é consolidar muitas pequenas dimensões em uma única dimensão. Essa abordagem de design pode diminuir o número de dimensões e de chaves da tabela de fatos e, portanto, o tamanho do armazenamento de tabelas de fatos. Ela também ajuda a reduzir a desorganização do painel de dados por apresentar menos tabelas aos usuários.

Normalmente, uma tabela de dimensão de lixo eletrônico armazena o produto cartesiano de todos os valores de atributo de dimensão, com um atributo de chave alternativa.

Os bons candidatos incluem sinalizadores 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 eletrônico chamada Sales Status que combina valores de status do pedido e valores de status da entrega.

Degenerar dimensões

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

O diagrama a seguir mostra uma dimensão Sales Order que é uma dimensão de degeneração baseada na coluna SalesOrderNumber em 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 de venda.

Dica

É possível criar um modo de exibição em um Warehouse do Fabric que apresenta a dimensão de degeneração como uma dimensão para fins de consulta.

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

Dimensões de tabela de dimensões

Quando uma tabela de dimensões está relacionada a outras tabelas de dimensões, ela é conhecida como uma dimensão de tabela de dimensões. Uma dimensão de tabela de dimensões 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 CEP. Essa dimensão poderia então ser referenciada pela dimensão do cliente e pela dimensão do vendedor, que armazenariam a chave alternativa 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 dimensão Geography que é uma dimensão de tabela de dimensões. Ela não está diretamente relacionada à tabela de fatos Sales. Em vez disso, está indiretamente relacionada por meio da dimensão Customer e da dimensão Salesperson.

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

Dimensões de múltiplos valores

Quando um atributo de dimensão deve armazenar diversos valores, é necessário projetar uma dimensão de múltiplos valores. Você implementa uma dimensão de múltiplos valores criando uma tabela de 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 talvez mais regiões de vendas. Nesse 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 de ponte, armazena uma linha para cada relacionamento entre vendedor e região de vendas. Fisicamente, há uma relação um-para-muitos da dimensão do vendedor para a tabela de ponte e outra relação um-para-muitos da dimensão da região de vendas para a tabela de ponte. Logicamente, há uma relação muitos para muitos entre o vendedor e as regiões de vendas.

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

Conteúdo relacionado

No próximo artigo desta série, aprenda sobre diretrizes e melhores práticas de design para tabelas de fatos.