Orientação de relacionamento ativo vs inativo

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.

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 leia primeiro o artigo Relações de modelo 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 para o Power BI.

Relações ativas

Geralmente, recomendamos a definição de relações ativas 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 perguntas e respostas.

Considere um exemplo de um modelo de importação projetado para analisar o desempenho pontual (OTP) de voos da companhia aérea. O modelo tem uma tabela de voo, que é uma tabela de fatos que armazena uma linha por 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 do tipo 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.

Existem dois modelos de relações entre as tabelas Voo e Aeroporto. Na tabela Voo, as colunas Aeroporto de partida e Aeroporto de chegada estão relacionadas à coluna Aeroporto da tabela Aeroporto. No design de esquema em estrela, a tabela Airport é descrita como uma dimensão de RPG. 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 para modelos do Power BI. É 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 ambiguidade do caminho de relacionamento. Portanto, conforme descrito 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. Isso significa que os filtros aplicados à tabela Aeroporto se propagam automaticamente para a coluna Aeroporto de Chegada da tabela Voo.

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 Aeroporto para isolar automaticamente os detalhes do voo de um aeroporto de partida. Uma vez que os requisitos de comunicação de informações envolvem a filtragem (ou agrupamento) por aeroportos de partida e de 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 do modelo melhorado.

O modelo conta agora com duas tabelas aeroportuárias: Aeroporto de Partida e Aeroporto de Chegada. As relações de modelo entre essas tabelas e a tabela Flight estão ativas. Observe também que os nomes das colunas nas tabelas Aeroporto de Partida e Aeroporto de Chegada são prefixados com a palavra Partida ou Chegada.

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

A página de relatório filtra por Melbourne como o aeroporto de partida e os grupos visuais da tabela por aeroportos de chegada.

Nota

Para modelos de importação, a tabela adicional 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 tipo de dimensão contenham contagens de linhas baixas em relação às contagens de linhas de tabelas de tipo de fato. 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 papel para um design com uma tabela por função.

1. Remova quaisquer relações inativas.

2. Considere renomear a tabela de dimensão de interpretação de papéis para descrever melhor sua função. No exemplo, a tabela Aeroporto está relacionada à coluna Aeroporto de Chegada da tabela Voo, por isso é renomeada como Aeroporto de Chegada.

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 Importar, recomendamos definir uma tabela calculada. Se for uma tabela DirectQuery, pode duplicar a consulta do Power Query.

   No exemplo, a tabela Aeroporto de partida 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, todas as colunas são prefixadas com a palavra Partida ou 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 de perguntas e respostas, permitindo que os utilizadores escrevam facilmente as suas perguntas.

6. Considere adicionar descrições a mesas de interpretação de papéis. (No período de Painel de campos, 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 quaisquer detalhes adicionais 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 especiais de comunicação de informações.

Vamos agora considerar 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 Vendas registra uma única ordem
• Os filtros de data são quase sempre aplicados à coluna DataDoOrdem, 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 BLANKs (até que o pedido seja enviado)
• Não é necessário filtrar (ou agrupar por) simultaneamente os períodos de ordem e data de envio

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. Neste modelo, as duas funções para a tabela Data são data do pedido e data de envio. É a relação com a coluna DataDoEncomenda que está ativa.

Todas as seis medidas, exceto uma, devem ser filtradas pela coluna DataDoOrdem. A medida Pedidos enviados , no entanto, deve ser filtrada pela coluna Data de envio .

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

Orders = COUNTROWS(Sales)

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

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

A página do relatório filtra por trimestre de 2019 Q4. A tabela visual agrupa por mês e exibe várias estatísticas de vendas. As medidas Pedidos e Pedidos Enviados produzem resultados diferentes. Cada um deles usa a mesma lógica de sumarização (contar linhas da tabela Sales), mas propagação de filtro de tabela Data diferente.

Observe que a segmentação de dados de trimestre inclui um item BLANK. Este item de segmentação de dados aparece como resultado da expansão da tabela. Embora cada linha da tabela de vendas tenha uma data de pedido, 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, BLANKs podem aparecer devido a BLANKs em muitos lados do relacionamento ou devido a problemas de integridade de dados.

Nota

Os filtros de segurança em nível de linha só se propagam através de relações ativas. Os filtros de segurança em nível de linha não serão propagados para relações inativas, mesmo que UseRelationship seja adicionado explicitamente a uma definição de medida.

Recomendações

Em resumo, recomendamos definir relações ativas sempre que possível, especialmente quando funções de segurança em nível de linha 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 perguntas e respostas. Isso significa que as tabelas do tipo dimensão de interpretação de papéis 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 função. Pode considerar este desenho ou modelo quando:

• Não há nenhum requisito para que os visuais de relatório filtrem simultaneamente por funções diferentes
• Use a função USERELATIONSHIP DAX para ativar um relacionamento específico para cálculos de modelo relevantes

Conteúdos relacionados

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

• Relações de modelo no Power BI Desktop
• Compreender o esquema em estrela e a importância para o Power BI
• Orientação para solução de problemas de relacionamento
• Perguntas? Tente perguntar à Comunidade do Power BI
• Sugestões? Contribua com ideias para melhorar o Power BI