Diretrizes de relação ativas versus inativas

Este artigo tem como destino você como um modelador de dados que trabalha com o Power BI Desktop. Ele fornece orientação sobre quando criar relações de modelo ativas ou inativas. Por padrão, as relações ativas propagam filtros para outras tabelas. No entanto, a relação inativa só propaga filtros quando uma expressão DAX ativa (usa) a relação.

Nota

Uma introdução às relações de modelo não é abordada neste artigo. Se você não estiver completamente familiarizado com relacionamentos, suas propriedades ou como configurá-los, recomendamos que você leia primeiro o artigo Relacionamentos de Modelo no Power BI Desktop.

Também é importante que você compreenda o design do esquema em estrela. Para obter mais informações, confira Entender o esquema em estrela e a importância dele para o Power BI.

Relações ativas

Geralmente, recomendamos que você defina relações ativas sempre que possível. Elas ampliam o escopo e o potencial de como seu modelo pode ser usado por autores de relatórios e usuários que trabalham com P e R.

Considere um exemplo de um Modelo de importação projetado para analisar a OTP (pontualidade) dos voos de companhias aéreas. O modelo tem uma tabela Flight, que é uma tabela de fatos e armazena uma linha por voo. Cada linha registra a data do voo, o número do voo, os aeroportos de partida e chegada e qualquer tempo de atraso (em minutos). Há também uma tabela Airport, que é uma tabela de dimensões que armazena uma linha por aeroporto. Cada linha descreve o código do aeroporto, o nome do aeroporto e o país ou a região.

Aqui está um diagrama de modelo parcial das duas tabelas.

Há duas relações de modelo entre as tabelas Flight e Airport. Na tabela Flight, as colunas DepartureAirport e ArrivalAirport estão relacionadas à coluna Airport da tabela Airport. No design do esquema em estrela, a tabela Airport é descrita como uma dimensão com função múltipla. Neste modelo, as duas funções são aeroporto de partida e aeroporto de chegada.

Embora esse design funcione bem para designs de esquema de estrela relacional, ele não funciona bem para modelos do Power BI. Isso ocorre porque as relações de modelo são caminhos para propagação de filtro e esses caminhos devem ser determinísticos. Para obter mais informações sobre como garantir que os caminhos de propagação de filtro sejam determinísticos, consulte Resolver a ambiguidade do caminho de relação. Assim, como apresentado neste exemplo, uma relação está ativa enquanto a outra está inativa (representada pela linha tracejada). Especificamente, é a relação com a coluna ArrivalAirport que está ativa, o que significa que os filtros aplicados à tabela Airport são propagados automaticamente para a coluna ArrivalAirport da tabela Flight.

Esse design de modelo impõe limitações severas sobre como os dados podem ser relatados. Especificamente, não é possível filtrar a tabela Airport para isolar automaticamente os detalhes do voo para um aeroporto de partida. Como os relatórios precisam filtrar (ou agrupar) por aeroportos de partida e chegada ao mesmo tempo, são necessárias duas relações ativas. Traduzir esse requisito em um design de modelo do Power BI significa que o modelo deve ter duas tabelas de aeroporto.

Aqui está o design de modelo aprimorado.

O modelo agora tem duas tabelas de aeroporto: Departure Airport e Arrival Airport. Cada relação de modelo entre essas tabelas e a tabela Flight está ativa. Observe também que os nomes das colunas nas tabelas Departure Airport e Arrival Airport são prefixados com a palavra Saída ou Chegada.

O modelo aprimorado oferece suporte à produção do seguinte design de relatório.

A página de relatório filtra por Melbourne como o aeroporto de partida, e o visual da tabela agrupa por aeroportos de chegada.

Nota

Para modelos de importação, a adição de outra tabela de dimensões resultou em um aumento do tamanho do modelo e tempos de atualização mais longos. Dessa forma, contradiz as recomendações descritas no artigo Técnicas de redução de dados para modelagem de importação. No entanto, no exemplo, o requisito de ter apenas relações ativas substitui essas recomendações.

Além disso, é comum que as tabelas de dimensão armazenem um número menor de linhas em relação às contagens de linhas da tabela de fatos. Portanto, o tamanho do modelo e os tempos de atualização aumentados provavelmente não serão excessivamente grandes.

Metodologia de refatoração

Esta é uma metodologia para refatorar um modelo de uma tabela de dimensão com função múltipla para um design com uma tabela por função.

1. Remova as relações inativas.

2. Considere renomear a tabela de dimensão com função múltipla para descrever melhor a função dela. No exemplo deste artigo, a tabela Airport está relacionada à coluna ArrivalAirport da tabela Flight, portanto, ela é renomeada como Arrival Airport.

3. Crie uma cópia da tabela com função múltipla nomeando-a de acordo com a função. Se for uma tabela de importação, recomendamos que você crie uma tabela calculada. Se for uma tabela DirectQuery, você poderá duplicar a consulta do Power Query.

   No exemplo, a tabela Departure Airport foi criada usando a definição de tabela calculada a seguir.

   Departure Airport = 'Arrival Airport'
   

4. Crie uma relação ativa para relacionar a nova tabela.

5. Considere renomear as colunas nas tabelas para que elas reflitam com precisão sua função. No exemplo deste artigo, todas as colunas são prefixadas com a palavra Saída ou Chegada. Esses nomes garantem que os visuais de relatório, por padrão, terão rótulos autoexplicativos e sem ambiguidades. Isso também aprimora a experiência de P e R, permitindo que os usuários escrevam perguntas precisas com facilidade.

6. Considere adicionar descrições às tabelas com função múltipla. (No painel Data, uma descrição aparece em uma dica de ferramenta quando um autor de relatório passa o cursor sobre a tabela.) Dessa forma, você pode comunicar outros detalhes de propagação de filtro aos autores do relatório.

Relações inativas

Em circunstâncias específicas, as relações inativas podem atender a necessidades específicas de relatório.

Considere diferentes requisitos de modelo e relatório:

• Um modelo de vendas contém uma tabela Sales que tem duas colunas de data: OrderDate e ShipDate.
• Cada linha na tabela Sales registra uma única ordem.
• Os filtros de data são quase sempre aplicados à coluna OrderDate, que sempre armazena uma data válida.
• Apenas uma medida requer a propagação de filtro de data para a coluna ShipDate, que pode conter BLANKs (até que o pedido seja enviado).
• Não há nenhum requisito para filtrar (ou agrupar) simultaneamente os períodos de data de envio dos pedidos e.

Aqui está um diagrama de modelo parcial das duas tabelas.

Há duas relações de modelo entre as tabelas Sales e Date. Na tabela Sales, as colunas OrderDate e ShipDate estão relacionadas à coluna Date da tabela Date. Nesse modelo, as duas funções da tabela Date são data do pedido e data de envio. É a relação com a coluna OrderDate que está ativa.

Todas as seis medidas, exceto uma, devem ser filtradas pela coluna OrderDate. No entanto, a medida Orders Shipped precisa ser filtrada pela coluna ShipDate.

Aqui está a definição de medida Orders. Ele simplesmente conta as linhas da tabela Sales dentro do contexto de filtro. Todos os filtros aplicados à tabela Date são propagados para a coluna OrderDate.

Orders = COUNTROWS(Sales)

Aqui está a definição da medida Orders Shipped. Ele usa a função USERELATIONSHIP DAX, que ativa a propagação de filtro para uma relação específica, mas somente durante a avaliação da expressão. Neste exemplo, a relação com a coluna ShipDate é usada.

Orders Shipped =
CALCULATE(
    COUNTROWS(Sales)
    ,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)

Esse design de modelo dá suporte à produção do design de relatório a seguir.

A página de relatório filtra pelo trimestre 2019 Q4. O visual da tabela é agrupado por mês e exibe várias estatísticas de vendas. As medidas Orders e Orders Shipped produzem resultados diferentes. Cada uma delas usa a mesma lógica de sumarização (contagem de linhas da tabela Sales), mas a propagação de filtro da tabela Date é diferente.

Observe que a segmentação por trimestre inclui uma opção BLANK. Essa opção de segmentação aparece como resultado da expansão da tabela. Embora cada linha de tabela Sales tenha uma data de pedido válida, algumas linhas têm uma data de remessa BLANK. Esses pedidos ainda não foram enviados. A expansão da tabela também considera relações inativas e, portanto, os BLANKs podem aparecer devido a valores BLANKs no lado "muitos" da relação (ou devido a problemas de integridade dos dados).

Nota

Os filtros RLS (segurança em nível de linha) só se propagam por meio de relações ativas. Os filtros de RLS nunca se propagam para relações inativas, mesmo quando a função DAX USERELATIONSHIP é usada por uma definição de medida.

Recomendações

Recomendamos que você defina relações ativas sempre que possível, especialmente quando as funções RLS são definidas para seu modelo de dados. Eles ampliam o escopo e o potencial de como seu modelo pode ser usado por autores de relatórios e usuários que trabalham com Q&A. Isso significa que as tabelas de dimensão com função múltipla devem ser duplicadas em seu modelo.

Em circunstâncias específicas, no entanto, você pode definir uma ou mais relações inativas para uma tabela de dimensão com função múltipla. Você pode considerar essa abordagem quando:

• Não há nenhum requisito para que os visuais de relatório sejam filtrados simultaneamente por funções diferentes.
• Use a função USERELATIONSHIP DAX para ativar uma relação específica para cálculos de modelo relevantes.

Conteúdo relacionado

Para obter mais informações relacionadas a este artigo, confira os seguintes recursos:

• Modelar relações no Power BI Desktop
• Entenda o esquema estrela e a importância para o Power BI
• diretrizes de solução de problemas de relação
• Perguntas? Tente perguntar à Comunidade do Fabric
• Sugestões? Contribua com ideias para aprimorar o Fabric