segunda-feira, 6 de maio de 2019

Role-Play Dimensions em Modelos Tabulares

Em um modelo de dados, as dimensões dão significado às perspectivas pelas quais os dados serão filtrados e analisados, além disso elas facilitam a leitura e simplificam os modelos trazendo semântica e organização. Normalmente as dimensões são estruturas de dados que possuem um relacionamento de 1 para N com as tabelas de fatos, e se o modelo possui mais de uma tabela de fatos a mesma dimensão pode ser utilizada para ambas, criando assim uma visão compartilhada entre processos diferentes (representados pelas suas tabelas de fatos).

Alguns bons exemplos são dimensões de "Clientes" e "Datas": o cliente poderia estar relacionado com a tabela de fatos do processo de vendas e a tabela de fatos do processo de atendimentos de um SAC, e a dimensão de datas poderia estar relacionada com a data da venda e com a data do atendimento no SAC.

Dimensões que se relacionam com múltiplas tabelas de fatos são relativamente comuns em data warehouses maiores. Porém, existem situações nas quais uma dimensão têm mais de um relacionamento com a mesma tabela de fatos, como por exemplo as dimensões de datas. Uma tabela de vendas pode ter um fato com uma coluna para a data da venda, data do envio, data da entrega, etc. Um processo de atendimento no SAC pode ter data da ligação, data da solução do atendimento, data da resposta ao cliente. Em geral, são tabelas que possuem colunas que armazenam datas para cada fase de um processo.

Essas dimensões são chamadas de "Role-playing Dimensons". Vamos ver como implementar em modelos tabulares no analysis services.

O primeiro passo é garantir que exista um relacionamento N:1 para cada coluna de data na tabela de fatos.

DimDate => OrderDate (ativa)
DimDate => DueDate (inativa)
DimDate => ShipDate (inativa)
















Uma questão importante é que os modelos tabulares permitem que apenas um relacionamento esteja ativo por vez, isso garante que as funções DAX funcionem sem ambiguidade sem que seja necessário definir o relacionamento padrão.

Sempre que a tabela de fatos for filtrada pela dimensão de datas as medidas irão aplicar os filtros na coluna de data que estiver com o relacionamento ativo, no exemplo abaixo, não é necessário instruir a função DAX em qual relacionamento se propagar para filtrar as vendas por data, pois OrderDate está com relacionamento ativo.

SalesByOrderDate := SUM ( FactInternetSales[SalesAmount] )


Para fazer com que uma medida considere os relacionamentos inativos temos que explicitar isso utilizando a função USERELANTIONSHIP 


SalesByDueDate :=
CALCULATE (
    SUM ( FactInternetSales[SalesAmount] ),
    USERELATIONSHIP (
        FactInternetSales[DueDateKey],
        DimDate[DateKey]
    )
)


SalesByShipDate :=
CALCULATE (
    SUM ( FactInternetSales[SalesAmount] ),
    USERELATIONSHIP (
        FactInternetSales[ShipDateKey],
        DimDate[DateKey]
    )
)


A função USERELATIONSHIP recebe como argumento as chaves envolvidas no relacionamento. Com isso as medidas irão filtrar corretamente o contexto de datas sem que o filtro de uma data afete o filtro das outras.











Usando relacionamentos inativos em colunas calculadas:

Nos exemplos acima, estou descrevendo como ativar relacionamentos em medidas que usam o contexto de coluna, nos casos em que o contexto é de linha, como em colunas calculadas que usam RELATED para buscar um valor a partir dos relacionamentos, a implementação é diferente.

Não podemos usar CALCULATE em funções de contexto de linha pois o DAX altera automaticamente para contexto de coluna, temos que usar LOOKUP.

A função LOOKUP faz uma relação entre as chaves de data sem que exista uma relação fisicamente criada. É uma espécie de relacionamento virtual.

* onde [DueDateKey]  foi igual a [DateKey] retorna o nome do dia da semana.

FactInternetSales[DayDue] =
LOOKUPVALUE (
    DimDate[EnglishDayNameOfWeek],
    DimDate[DateKey],
    FactInternetSales[DueDateKey]
)


Desta forma nós contornamos a necessidade de usar a função CALCULATE para ativar uma relação inativa e fazer o uso correto da função RELATED.


















Fontes:
https://www.sqlbi.com/articles/userelationship-in-calculated-columns/
https://www.youtube.com/watch?v=2BxaUXlx3K4

Nenhum comentário:

Postar um comentário