Partilhar via

Orientação para Relacionamentos Ativos vs Inativos

  • Artigo

Este artigo destina-se a você como um modelador de dados que trabalha com o Power BI Desktop. Ele fornece orientação sobre quando criar relacionamentos de modelo ativos ou inativos. 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.

Observação

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

Também é importante que você tenha uma compreensão do design do esquema de estrelas. Para obter mais informações, consulte Compreender o esquema em estrela e a importância do Power BI.

Relações ativas

Geralmente, recomendamos que você defina relacionamentos ativos sempre que possível. 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.

Considere um exemplo de um modelo Import projetado para analisar o desempenho pontual (OTP) de voos de companhias aéreas. O modelo tem uma tabela Flight, que é uma tabela de factos que armazena uma linha para cada voo. Cada linha regista 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ão que armazena uma linha por aeroporto. Cada linha descreve o código do aeroporto, o nome do aeroporto e o país ou região.

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

Diagrama mostrando um modelo contendo duas tabelas: Voo e Aeroporto. O design do relacionamento é descrito no parágrafo a seguir.

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 de esquema em estrela, a tabela de Airport é descrita como uma dimensão de interpretação de papéis. 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 porque as relações de modelo são caminhos para a propagação de filtros, e esses caminhos devem ser determinísticos. Para obter mais informações sobre como garantir que os caminhos de propagação do filtro sejam determinísticos, consulte resolver a ambiguidade do caminho de relacionamento. Portanto, como apresentado neste exemplo, um relacionamento está ativo enquanto o outro está inativo (representado pela linha tracejada). Especificamente, é a relação com a coluna ArrivalAirport que está ativa, o que significa que os filtros aplicados à tabela Airport se propagam automaticamente para a coluna ArrivalAirport da tabela Flight.

Este design de modelo impõe limitações severas na forma como os dados podem ser relatados. Especificamente, não é possível filtrar a tabela Airport para selecionar automaticamente os detalhes do voo de um aeroporto de partida. Como os relatórios precisam filtrar (ou agrupar) por aeroportos de partida e chegada ao mesmo tempo, duas relações ativas são necessárias. 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 do modelo melhorado.

Diagrama mostrando um modelo contendo quatro tabelas: Data, Voo, Aeroporto de Partida e Aeroporto de Chegada.

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 de partida ou de chegada.

O design de modelo aprimorado suporta a produção do seguinte design de relatório.

Diagrama que mostra uma página de relatório com duas segmentações de dados e uma visualização de tabela. As segmentações são Mês e Aeroporto de Partida.

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

Observação

Para modelos de importação, a adição de outra tabela de dimensões resultou em um tamanho de modelo maior e tempos de atualização mais longos. Como tal, 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ões guardem um número de linhas inferior em relação ao número de linhas das tabelas de factos. Assim, o aumento do tamanho do modelo e os tempos de atualização provavelmente não serão excessivamente grandes.

Metodologia de refatoração

Aqui está uma metodologia para refatorar um modelo de uma única tabela de dimensão de interpretação de papéis para um design com uma tabela por função.

  1. Remova quaisquer relações inativas.

  2. Considere renomear a tabela de dimensões de interpretação de papéis para descrever melhor seu papel. No exemplo deste artigo, a tabela Airport está relacionada à coluna ArrivalAirport da tabela Flight, por isso é renomeada como Arrival Airport.

  3. Crie uma cópia da tabela de interpretação de funções, fornecendo-lhe um nome que reflita o seu papel. Se for uma tabela Import, recomendamos que crie uma tabela calculada. Se for uma tabela DirectQuery, pode duplicar a consulta do Power Query.

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

    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 de partida ou de chegada. Esses nomes garantem que os visuais de relatório, por padrão, terão rótulos autodescritivos e não ambíguos. Também melhora a experiência Q&A, permitindo que os usuários escrevam facilmente perguntas precisas.

  6. Considere adicionar descrições a sessões de jogos de interpretação de papéis. (No painel de Dados , uma descrição aparece numa tooltip quando um autor de relatório passa o cursor sobre a tabela.) Desta forma, pode comunicar outros detalhes de propagação do filtro aos autores do relatório.

Relações inativas

Em circunstâncias específicas, as relações inativas podem dar resposta a necessidades específicas de comunicação de informações.

Considere diferentes requisitos de modelo e relatórios:

  • 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 do filtro de data para a coluna ShipDate, que pode conter valores em branco (até que a encomenda seja enviada).
  • Não é necessário filtrar (ou agrupar) simultaneamente os períodos de data de envio do pedido e.

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

Diagrama mostrando um modelo contendo duas tabelas: Vendas e Data. A tabela Vendas inclui seis medidas.

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. Neste modelo, as duas funções para a tabela Date são data de ordem 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. A medida Orders Shipped, no entanto, deve 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 propagam-se para a coluna OrderDate.

Orders = COUNTROWS(Sales)

Aqui está a definição de medida Orders Shipped. Ele usa a função USERELATIONSHIP DAX, que ativa a propagação do filtro para uma relação específica, mas apenas 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])
)

Este design de modelo suporta a produção do seguinte design de relatório.

Diagrama mostrando uma página de relatório com uma segmentação de dados e um visual de tabela. A segmentação de dados é Trimestre, e o visual da tabela lista as estatísticas mensais de vendas.

A página do relatório filtra por trimestre 2019 Q4. A tabela visual agrupa os dados por mês e apresenta diversas estatísticas de vendas. As medidas Orders e Orders Shipped produzem resultados diferentes. Cada um deles usa a mesma lógica de sumarização (contar linhas da tabela Sales), mas propagações diferentes do filtro da tabela Date.

Observe que o fatiador de trimestres inclui uma opção BLANK. Esta opção de segmentador aparece como resultado da expansão da tabela . Embora cada linha da tabela Sales tenha uma data de pedido válida, algumas linhas têm uma data de envio EM BRANCO — essas ordens ainda não foram enviadas. A expansão da tabela também considera relacionamentos inativos e, portanto, os BLANKs podem aparecer devido a BLANKs nos vários lados do relacionamento (ou devido a problemas de integridade de dados).

Observação

Os filtros de segurança em nível de linha (RLS) só se propagam através de relações ativas. Os filtros RLS nunca se propagam para relações inativas, mesmo quando a função USERELATIONSHIP DAX é 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 de RPG devem ser duplicadas em seu modelo.

Em circunstâncias específicas, no entanto, você pode definir um ou mais relacionamentos inativos para uma tabela de dimensão de interpretação de RPG. Você pode considerar essa abordagem quando:

  • Não há nenhum requisito para que os visuais de relatório filtrem simultaneamente por diferentes funções.
  • 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: