Como usar uma dimensão role-playing num Data Warehouse

Numa venda, a data da encomenda, a data de envio e a data de entrega apontam todas para o mesmo calendário, mas significam coisas diferentes. Uma dimensão role-playing resolve exactamente isto: reutiliza uma única tabela de dimensão em vários papéis dentro do mesmo Data Warehouse, mantendo o modelo simples, consistente e fácil de manter. É um padrão clássico da modelação dimensional de Kimball e aparece em quase todos os projetos reais de BI.

Pré-requisitos

• Um Data Warehouse com esquema em estrela (SQL Server, Azure Synapse, Microsoft Fabric ou equivalente).
• Uma dimensão de data (DimData) já criada e preenchida.
• Uma tabela de factos com mais do que uma coluna de data.
• Conhecimentos básicos de SQL (JOIN e views).

Passo 1: Identificar as várias datas na tabela de factos

Imagina uma tabela FactVendas com três datas diferentes: quando a encomenda foi feita, quando foi enviada e quando foi entregue. Cada uma é uma chave estrangeira que aponta para a mesma dimensão de data. Guardar várias datas é normal — representam o ciclo de vida da encomenda.

CREATE TABLE FactVendas (
    VendaKey          INT           NOT NULL,
    DataEncomendaKey  INT           NOT NULL,
    DataEnvioKey      INT           NOT NULL,
    DataEntregaKey    INT           NOT NULL,
    ProdutoKey        INT           NOT NULL,
    Quantidade        INT           NOT NULL,
    ValorTotal        DECIMAL(12,2) NOT NULL
);

Passo 2: Reutilizar a mesma dimensão com aliases

O erro mais comum é criar três tabelas de data separadas. Não é preciso: basta juntar a mesma DimData três vezes, dando um alias diferente a cada papel. Duplicar a dimensão significaria manter três processos de ETL, ocupar mais espaço e arriscar inconsistências quando o calendário muda; reutilizar evita tudo isto.

SELECT
    f.VendaKey,
    de.Data AS DataEncomenda,
    dv.Data AS DataEnvio,
    dt.Data AS DataEntrega,
    f.ValorTotal
FROM FactVendas AS f
JOIN DimData AS de ON f.DataEncomendaKey = de.DataKey
JOIN DimData AS dv ON f.DataEnvioKey     = dv.DataKey
JOIN DimData AS dt ON f.DataEntregaKey   = dt.DataKey;

Cada alias (de, dv, dt) representa um papel da mesma dimensão. Mantés assim uma única fonte de verdade para o calendário, sem duplicar dados.

Passo 3: Criar vistas para tornar cada papel explícito

Para que os analistas e as ferramentas de BI vejam nomes claros, cria uma view por papel, renomeando as colunas. É a forma mais limpa de expor uma dimensão role-playing num Data Warehouse, e as vistas quase não ocupam espaço.

CREATE VIEW dim.DataEncomenda AS
SELECT
    DataKey  AS DataEncomendaKey,
    Data     AS DataEncomenda,
    Ano      AS AnoEncomenda,
    NomeMes  AS MesEncomenda
FROM DimData;
GO

CREATE VIEW dim.DataEnvio AS
SELECT
    DataKey  AS DataEnvioKey,
    Data     AS DataEnvio,
    Ano      AS AnoEnvio,
    NomeMes  AS MesEnvio
FROM DimData;

Repete o mesmo padrão para dim.DataEntrega. Todas as vistas apontam para a mesma DimData, mas apresentam nomes específicos de cada papel.

Passo 4: Consultar através das vistas

Agora as consultas ficam legíveis e cada data traz o seu próprio contexto — ideal, por exemplo, para comparar o total por ano de encomenda com o total por ano de envio.

SELECT
    e.AnoEncomenda,
    v.AnoEnvio,
    SUM(f.ValorTotal) AS Total
FROM FactVendas AS f
JOIN dim.DataEncomenda AS e ON f.DataEncomendaKey = e.DataEncomendaKey
JOIN dim.DataEnvio     AS v ON f.DataEnvioKey     = v.DataEnvioKey
GROUP BY e.AnoEncomenda, v.AnoEnvio;

Verificar o resultado

Faz duas verificações simples. Primeiro, o número de linhas ao usar as vistas deve ser igual ao da tabela de factos — se for menor, perdeste linhas num JOIN:

SELECT COUNT(*) AS TotalLinhas
FROM FactVendas AS f
JOIN dim.DataEncomenda AS e ON f.DataEncomendaKey = e.DataEncomendaKey
JOIN dim.DataEnvio     AS v ON f.DataEnvioKey     = v.DataEnvioKey;

Depois, agrupa primeiro por AnoEncomenda e depois por AnoEnvio: se os totais forem diferentes, confirmas que cada papel funciona de forma independente.

Conclusão

Com uma dimensão role-playing evitas duplicar tabelas, garantes um calendário consistente e tornas os relatórios muito mais claros. O passo seguinte é levar este modelo ao Power BI: como só pode existir uma relação ativa entre duas tabelas, vais usar relações inativas com USERELATIONSHIP ou cópias da dimensão. Que outra dimensão do teu modelo — como cliente ou geografia — poderia beneficiar de vários papéis?