Diretrizes de relações ativas vs inativas
Este artigo destina-se aos modeladores de dados que trabalham com o Power BI Desktop. Ele fornece diretrizes 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.
Observação
Este artigo não inclui nenhuma introdução às relações de modelo. Se você não estiver totalmente familiarizado com essas relações, as respectivas propriedades e como configurá-las, recomendamos que leia primeiro o artigo Relações de modelo no Power BI Desktop.
Também é importante que você compreenda o design em 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
Em geral, recomendamos definir 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 perguntas e respostas.
Considere um exemplo de modelo de importação projetado para analisar o OTP (desempenho no prazo) de voos da companhia aérea. O modelo tem uma tabela Flight, que é uma tabela do tipo fato que armazena uma linha por voo. Cada linha registra a data e o número do voo, aeroportos de partida e de chegada e qualquer tempo de atraso (em minutos). Há também uma tabela com o nome Airport, do tipo dimensão que armazena uma linha por aeroporto. Cada linha descreve o código, o nome e o país ou região do aeroporto.
Confira abaixo um diagrama de modelo parcial das duas tabelas.
Existem duas relações de modelo entre as tabelas de Flight e Airport. Na tabela Flight, as colunas DepartureAirport (aeroporto de partida) e ArrivalAirport (aeroporto de chegada) 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. Nesse modelo, as duas funções são aeroporto de partida e aeroporto de chegada.
Embora esse design funcione bem em esquemas em estrela relacionais, ele não funciona com modelos do Power BI. Isso ocorre porque as relações de modelo são caminhos para a 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 do filtro sejam determinísticos, confira resolver ambiguidade do caminho da relação. Portanto, conforme descrito nesse exemplo, uma relação está ativa enquanto a outra está inativa (representada pela linha tracejada). Mais especificamente a relação com a coluna ArrivalAirport que está ativa. Isso significa que os filtros aplicados à tabela Airport são propagados automaticamente para a coluna ArrivalAirport da tabela Flight.
Esse design de modelo impõe severas limitações sobre como os dados podem ser relatados. Especificamente, não é possível filtrar a tabela Airport para isolar automaticamente os detalhes do voo de um aeroporto de partida. Como os requisitos de relatório envolvem filtragem (ou agrupamento) pelos aeroportos de partida e chegada ao mesmo tempo, são necessárias duas relações ativas. Para converter esse requisito em um design de modelo do Power BI, é necessário que o modelo tenha duas tabelas de aeroporto.
Veja a seguir o modelo de design aprimorado.
O modelo agora tem duas tabelas de aeroporto: Departure Airport e Arrival Airport. 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 Departure Airport e Arrival Airport estão prefixados com as palavras Departure (partida) ou Arrival (chegada).
O design aprimorado do modelo dá suporte à produção do design de relatório a seguir.
A página do relatório filtra por Melbourne como o aeroporto de partida, e o visual de tabela agrupa os aeroportos de chegada.
Observação
Para modelos de importação, a tabela adicional resultou em um tamanho de modelo aumentado e em tempos de atualização mais longos. Sendo assim, isso contradiz as recomendações descritas no artigo Técnicas de redução de dados para modelagem de importação. No entanto, no exemplo, a necessidade de se ter apenas relações ativas substitui essas recomendações.
Além disso, é comum que as tabelas do tipo dimensão contenham contagens de linhas baixas em relação às contagens de linhas das tabelas do tipo fato. Portanto, o aumento do tamanho do modelo e os tempos de atualização provavelmente não serão excessivamente grandes.
Metodologia de refatoração
Veja a seguir uma metodologia de refatoração de um modelo de uma única tabela do tipo dimensão com função múltipla para um design com uma tabela por função.
Remova quaisquer relações inativas.
Considere renomear a tabela do tipo dimensão com função múltipla para descrever melhor sua função. No exemplo, a tabela Airport está relacionada à coluna ArrivalAirport da tabela Flight, portanto, ela é renomeada como Arrival Airport.
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 definir uma tabela calculada. Se a tabela for do DirectQuery, será possível duplicar a consulta do Power Query.
Neste exemplo, a tabela Departure Airport foi criada usando a definição de tabela calculada a seguir.
Departure Airport = 'Arrival Airport'Crie uma relação ativa para relacioná-la a nova tabela.
Considere renomear as colunas nas tabelas para que elas reflitam precisamente a função. No exemplo, todas as colunas são prefixadas com a palavra Departure ou Arrival. Esses nomes garantem que os visuais do relatório, por padrão, tenham rótulos autoexplicativos e não ambíguos. Isso também melhora a experiência de perguntas e respostas, permitindo que os usuários façam suas perguntas facilmente.
Considere adicionar descrições às tabelas com função múltipla. (No painel Campos, é exibida uma descrição em uma dica de ferramenta quando o autor do relatório passa o cursor sobre a tabela.) Dessa forma, você pode comunicar quaisquer detalhes adicionais 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 especiais de geração de relatórios.
Agora, vamos considerar diferentes requisitos de modelo e de relatório:
- Um modelo de vendas contém uma tabela Sales (vendas) que possui duas colunas de data: OrderDate (data do pedido) e ShipDate (data de envio)
- Cada linha na tabela Sales registra um único pedido
- Os filtros de data quase sempre são 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 espaços EM BRANCO (até que o pedido seja enviado)
- Não há necessidade de filtrar simultaneamente (ou agrupar por) datas de pedido e de envio
Confira abaixo um diagrama de modelo parcial das duas tabelas.
Existem duas relações de modelo entre as tabelas Sales e Date. Na tabela de 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. A medida de Orders Shipped (pedidos enviados), no entanto, deve ser filtrada pela coluna ShipDate.
Veja a seguir a definição da medida de Orders. Ela simplesmente conta as linhas da tabela Sales no contexto do filtro. Quaisquer filtros aplicados à tabela Date serão propagados para a coluna OrderDate.
Orders = COUNTROWS(Sales)
Veja a seguir a definição da medida Orders Shipped. Ela usa a função DAX USERELATIONSHIP, que ativa a propagação de filtro para uma relação específica apenas durante a avaliação da expressão. Neste exemplo, foi usada a relação com a coluna ShipDate.
Orders Shipped =
CALCULATE(
COUNTROWS(Sales)
,USERELATIONSHIP('Date'[Date], Sales[ShipDate])
)
Esse design de modelo é compatível com a produção do design de relatório a seguir.
A página do relatório é filtrada pelo 4º trimestre de 2019. 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 resumo (contagem de linhas da tabela Sales), mas diferentes propagações de filtro da tabela Date.
Observe que a segmentação de trimestre inclui um item EM BRANCO. Esse item de segmentação é exibido como resultado da expansão da tabela. Embora cada linha da tabela Sales tenha uma data do pedido, algumas linhas têm uma data de envio EM BRANCO – esses pedidos ainda não foram enviados. A expansão da tabela também considera as relações inativas e, portanto, os espaços EM BRANCO podem aparecer devido a itens EM BRANCO no lado "muitos" da relação ou devido a problemas de integridade de dados.
Observação
Os filtros de segurança em nível de linha só se propagam por meio de relacionamentos ativos. Os filtros de segurança em nível de linha não serão propagados para relacionamentos inativos mesmo se UseRelationship for adicionado explicitamente a uma definição de medida.
Recomendações
Em resumo, recomendamos definir relacionamentos ativos sempre que possível, especialmente quando funções de segurança em nível de linha são definidas para seu modelo de dados. 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 perguntas e respostas. Isso significa que as tabelas do tipo dimensão com função múltipla devem ser duplicadas no seu modelo.
Em circunstâncias específicas, no entanto, é possível definir uma ou mais relações inativas para uma tabela do tipo dimensão com função múltipla. Considere esse design quando:
- Não é necessário que os visuais de relatório sejam filtrados simultaneamente por diferentes funções
- A função DAX USERELATIONSHIP é usada 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:
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de