Relações de modelo no Power BI Desktop

Este artigo destina-se a modeladores de dados de importação que trabalham com o Power BI Desktop. É um tópico importante de design de modelo que é essencial para fornecer modelos intuitivos, precisos e ideais.

Para obter uma discussão mais profunda sobre o design ideal do modelo, incluindo funções e relações de tabela, consulte Compreender o esquema em estrela e a importância do Power BI.

Propósito do relacionamento

Uma relação de modelo propaga filtros aplicados na coluna de uma tabela de modelo para uma tabela de modelo diferente. Os filtros serão propagados desde que haja um caminho de relacionamento a seguir, que pode envolver a propagação para várias tabelas.

Os caminhos de relacionamento são deterministas, o que significa que os filtros são sempre propagados da mesma maneira e sem variações aleatórias. No entanto, os relacionamentos podem ser desabilitados ou ter o contexto do filtro modificado por cálculos de modelo que usam funções DAX específicas. Para obter mais informações, consulte o tópico Funções DAX relevantes mais adiante neste artigo.

Importante

As relações de modelo não impõem a integridade dos dados. Para obter mais informações, consulte o tópico Avaliação de relacionamento mais adiante neste artigo, que explica como as relações de modelo se comportam quando há problemas de integridade de dados com seus dados.

Veja como as relações propagam filtros com um exemplo animado.

Neste exemplo, o modelo consiste em quatro tabelas: Categoria, Produto, Ano e Vendas. A tabela Categoria está relacionada à tabela Produto e a tabela Produto está relacionada à tabela Vendas . A tabela Ano também se relaciona com a tabela Vendas . Todas as relações são um-para-muitos (cujos detalhes são descritos mais adiante neste artigo).

Uma consulta, possivelmente gerada por um visual de cartão do Power BI, solicita a quantidade total de vendas para ordens de venda feitas para uma única categoria, Cat-A, e para um único ano, CY2018. É por isso que você pode ver filtros aplicados nas tabelas Categoria e Ano. O filtro na tabela Categoria se propaga para a tabela Produto para isolar dois produtos atribuídos à categoria Cat-A. Em seguida, os filtros da tabela Produto propagam-se para a tabela Vendas para isolar apenas duas linhas de vendas para estes produtos. Estas duas linhas de venda representam as vendas de produtos atribuídos à categoria Cat-A. A sua quantidade combinada é de 14 unidades. Ao mesmo tempo, o filtro da tabela Ano se propaga para filtrar ainda mais a tabela Vendas , resultando em apenas uma linha de vendas que é para produtos atribuídos à categoria Cat-A e que foi encomendada no ano CY2018. O valor de quantidade retornado pela consulta é de 11 unidades. Observe que quando vários filtros são aplicados a uma tabela (como a tabela Sales neste exemplo), é sempre uma operação AND, exigindo que todas as condições sejam verdadeiras.

Aplicar princípios de design de esquema em estrela

Recomendamos que você aplique os princípios de design do esquema em estrela para produzir um modelo que inclua tabelas de dimensões e fatos. É comum configurar o Power BI para impor regras que filtram tabelas de dimensão, permitindo que as relações de modelo propaguem eficientemente esses filtros para tabelas de fatos.

A imagem a seguir é o diagrama de modelo do modelo de dados de análise de vendas da Adventure Works. Ele mostra um design de esquema em estrela compreendendo uma única tabela de fatos chamada Sales. As outras quatro tabelas são tabelas de dimensão que suportam a análise de medidas de vendas por data, estado, região e produto. Observe as relações de modelo conectando todas as tabelas. Essas relações propagam filtros (direta ou indiretamente) para a tabela Sales .

Tabelas desconectadas

É incomum que uma tabela modelo não esteja relacionada a outra tabela modelo. Essa tabela em um design de modelo válido é descrita como uma tabela desconectada. Uma tabela desconectada não se destina a propagar filtros para outras tabelas modelo. Em vez disso, ele aceita "entrada do usuário" (talvez com um visual de segmentação de dados), permitindo que os cálculos do modelo usem o valor de entrada de forma significativa. Por exemplo, considere uma tabela desconectada carregada com um intervalo de valores de taxa de câmbio. Desde que um filtro seja aplicado ao filtro por um único valor de taxa, uma expressão de medida pode usar esse valor para converter valores de vendas.

O parâmetro what-if do Power BI Desktop é um recurso que cria uma tabela desconectada. Para obter mais informações, consulte Criar e usar um parâmetro E se para visualizar variáveis no Power BI Desktop.

Propriedades de relacionamento

Uma relação de modelo relaciona uma coluna de uma tabela a uma coluna de uma tabela diferente. (Há um caso especializado em que esse requisito não é verdadeiro e se aplica apenas a relações de várias colunas em modelos DirectQuery. Para obter mais informações, consulte o artigo da função COMBINEVALUES DAX.)

Nota

Não é possível relacionar uma coluna a uma coluna diferente na mesma tabela. Esse conceito às vezes é confundido com a capacidade de definir uma restrição de chave estrangeira de banco de dados relacional que é autorreferência de tabela. Você pode usar esse conceito de banco de dados relacional para armazenar relações pai-filho (por exemplo, cada registro de funcionário está relacionado a um "relatórios para" funcionário). No entanto, não é possível usar relações de modelo para gerar uma hierarquia de modelo com base nesse tipo de relação. Para criar uma hierarquia pai-filho, consulte Funções pai e filho.

Tipos de dados de colunas

O tipo de dados para as colunas "de" e "para" da relação deve ser o mesmo. Trabalhar com relações definidas em colunas DateTime pode não se comportar como esperado. O mecanismo que armazena dados do Power BI usa apenas tipos de dados DateTime ; Os tipos de dados Data, Hora e Data/Hora/Fuso horário são construções de formatação do Power BI implementadas na parte superior. Todos os objetos dependentes do modelo ainda aparecerão como DateTime no mecanismo (como relacionamentos, grupos e assim por diante). Como tal, se um usuário selecionar Data na guia Modelagem para essas colunas, ele ainda não se registrará como sendo a mesma data, porque a parte de tempo dos dados ainda está sendo considerada pelo mecanismo. Leia mais sobre como os tipos de data/hora são tratados. Para corrigir o comportamento, os tipos de dados de coluna devem ser atualizados no Editor do Power Query para remover a parte de tempo dos dados importados, para que, quando o mecanismo estiver manipulando os dados, os valores apareçam os mesmos.

Cardinalidade

Cada relação de modelo é definida por um tipo de cardinalidade. Existem quatro opções de tipo de cardinalidade, representando as características de dados das colunas relacionadas "de" e "para". O lado "um" significa que a coluna contém valores únicos; O lado "muitos" significa que a coluna pode conter valores duplicados.

Nota

Se uma operação de atualização de dados tentar carregar valores duplicados em uma coluna lateral "um", toda a atualização de dados falhará.

As quatro opções, juntamente com suas notações taquigráficas, são descritas na seguinte lista com marcadores:

• Um para muitos (1:*)
• Muitos para um (*:1)
• Um para um (1:1)
• Muitos para muitos (*:*)

Quando você cria uma relação no Power BI Desktop, o designer deteta e define automaticamente o tipo de cardinalidade. O Power BI Desktop consulta o modelo para saber quais colunas contêm valores exclusivos. Para modelos de importação, utiliza estatísticas de armazenamento interno; para modelos DirectQuery, ele envia consultas de criação de perfil para a fonte de dados. Às vezes, no entanto, o Power BI Desktop pode errar. Pode errar quando as tabelas ainda não foram carregadas com dados ou porque as colunas que você espera que contenham valores duplicados atualmente contêm valores exclusivos. Em ambos os casos, você pode atualizar o tipo de cardinalidade, desde que qualquer coluna lateral "uma" contenha valores exclusivos (ou a tabela ainda não tenha sido carregada com linhas de dados).

Cardinalidade um-para-muitos (e muitos-para-um)

As opções de cardinalidade um-para-muitos e muitos-para-um são essencialmente as mesmas, e também são os tipos de cardinalidade mais comuns.

Ao configurar uma relação um-para-muitos ou muitos-para-um, você escolherá aquele que corresponde à ordem em que relacionou as colunas. Considere como você configuraria a relação da tabela Produto para a tabela Vendas usando a coluna ProductID encontrada em cada tabela. O tipo de cardinalidade seria um-para-muitos, pois a coluna ProductID na tabela Product contém valores exclusivos. Se você relacionasse as tabelas na direção inversa, Vendas a Produto, então a cardinalidade seria muitos-para-um.

Cardinalidade um-para-um

Uma relação um-para-um significa que ambas as colunas contêm valores exclusivos. Esse tipo de cardinalidade não é comum e provavelmente representa um design de modelo subótimo devido ao armazenamento de dados redundantes.

Para obter mais informações sobre como usar esse tipo de cardinalidade, consulte Diretrizes de relacionamento um-para-um.

Cardinalidade muitos-para-muitos

Uma relação muitos-para-muitos significa que ambas as colunas podem conter valores duplicados. Este tipo de cardinalidade é usado com pouca frequência. Normalmente, é útil ao projetar requisitos de modelo complexos. Você pode usá-lo para relacionar muitos para muitos fatos ou para relacionar fatos de grãos superiores. Por exemplo, quando os fatos-alvo de vendas são armazenados no nível da categoria do produto e a tabela de dimensões do produto é armazenada no nível do produto.

Para obter orientação sobre como usar esse tipo de cardinalidade, consulte Diretrizes de relacionamento muitos-para-muitos.

Nota

O tipo de cardinalidade Muitos-para-muitos é suportado para modelos desenvolvidos para o Servidor de Relatório do Power BI de janeiro de 2024 e posterior.

Gorjeta

No modo de exibição de modelo do Power BI Desktop, você pode interpretar o tipo de cardinalidade de um relacionamento observando os indicadores (1 ou *) em ambos os lados da linha de relacionamento. Para determinar quais colunas estão relacionadas, você precisará selecionar ou passar o cursor sobre a linha de relacionamento para realçar as colunas.

Direção do filtro cruzado

Cada relação de modelo é definida com uma direção de filtro cruzado. Sua configuração determina a(s) direção(ões) que os filtros propagarão. As possíveis opções de filtro cruzado dependem do tipo de cardinalidade.

Tipo de cardinalidade	Opções de filtro cruzado
Um para muitos (ou Muitos para um)	Única Ambos
Um para um	Ambos
Muitos para muitos	Single (Tabela 1 a Tabela 2) Single (Tabela 2 a Tabela 1) Ambos

Direção de filtro cruzado único significa "direção única", e ambos significam "ambas as direções". Uma relação que filtra em ambas as direções é comumente descrita como bidirecional.

Para relações um-para-muitos, a direção do filtro cruzado é sempre do lado "um" e, opcionalmente, do lado "muitos" (bidirecional). Para relações um-para-um, a direção do filtro cruzado é sempre de ambas as tabelas. Por fim, para relações muitos-para-muitos, a direção do filtro cruzado pode ser de uma das tabelas ou de ambas as tabelas. Observe que quando o tipo de cardinalidade inclui um lado "um", esses filtros sempre se propagarão desse lado.

Quando a direção do filtro cruzado é definida como Both, outra propriedade fica disponível. Ele pode aplicar filtragem bidirecional quando o Power BI impõe regras de segurança em nível de linha (RLS). Para obter mais informações sobre RLS, consulte Segurança em nível de linha (RLS) com o Power BI Desktop.

Você pode modificar a direção do filtro cruzado de relacionamento, incluindo a desativação da propagação do filtro, usando um cálculo de modelo. Isso é conseguido usando a função CROSSFILTER DAX.

Tenha em mente que as relações bidirecionais podem ter um impacto negativo no desempenho. Além disso, tentar configurar uma relação bidirecional pode resultar em caminhos de propagação de filtro ambíguos. Nesse caso, o Power BI Desktop pode falhar ao confirmar a alteração de relacionamento e alertará você com uma mensagem de erro. Às vezes, no entanto, o Power BI Desktop pode permitir que você defina caminhos de relacionamento ambíguos entre tabelas. A resolução da ambiguidade do caminho de relacionamento é descrita mais adiante neste artigo.

Recomendamos o uso da filtragem bidirecional somente conforme necessário. Para obter mais informações, consulte Diretrizes de relacionamento bidirecional.

Gorjeta

No modo de exibição de modelo do Power BI Desktop, você pode interpretar a direção do filtro cruzado de uma relação observando a(s) ponta(s) de seta ao longo da linha de relacionamento. Uma única ponta de seta representa um filtro de direção única na direção da ponta da seta; Uma ponta de seta dupla representa uma relação bidirecional.

Tornar esta relação ativa

Só pode haver um caminho de propagação de filtro ativo entre duas tabelas de modelo. No entanto, é possível introduzir caminhos de relacionamento adicionais, embora você deva definir esses relacionamentos como inativos. As relações inativas só podem ser ativadas durante a avaliação de um cálculo de modelo. Isso é conseguido usando a função USERELATIONSHIP DAX.

Geralmente, recomendamos a definição de relações ativas sempre que possível. Eles ampliam o escopo e o potencial de como os autores de relatórios podem usar seu modelo. Usar apenas relações ativas significa que as tabelas de 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 RPG. Pode considerar este desenho ou modelo quando:

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

Para obter mais informações, consulte Orientação de relacionamento ativo versus inativo.

Gorjeta

No modo de exibição de modelo do Power BI Desktop, você pode interpretar o status ativo versus inativo de um relacionamento. Uma relação ativa é representada por uma linha sólida; Uma relação inativa é representada como uma linha tracejada.

Assumir integridade referencial

A propriedade de integridade referencial Assume está disponível apenas para relações um-para-muitos e um-para-um entre duas tabelas de modo de armazenamento DirectQuery que pertencem ao mesmo grupo de origem. Você só pode habilitar essa propriedade quando a coluna lateral "muitos" não contém NULLs.

Quando habilitadas, as consultas nativas enviadas para a fonte de dados unirão as duas tabelas usando um INNER JOIN em vez de um OUTER JOIN. Geralmente, habilitar essa propriedade melhora o desempenho da consulta, embora dependa das especificidades da fonte de dados.

Sempre habilite essa propriedade quando existir uma restrição de chave estrangeira de banco de dados entre as duas tabelas. Mesmo quando uma restrição de chave estrangeira não existir, considere habilitar a propriedade, desde que você tenha certeza de que a integridade dos dados existe.

Importante

Se a integridade dos dados ficar comprometida, a junção interna eliminará linhas incomparáveis entre as tabelas. Por exemplo, considere uma tabela Modelo de vendas com um valor de coluna ProductID que não existia na tabela Product relacionada. A propagação do filtro da tabela Produto para a tabela Vendas eliminará as linhas de vendas de produtos desconhecidos. Tal resultaria numa subavaliação dos resultados das vendas.

Para obter mais informações, consulte Assumir configurações de integridade referencial no Power BI Desktop.

Funções DAX relevantes

Há várias funções DAX que são relevantes para relações de modelo. Cada função é descrita brevemente na seguinte lista com marcadores:

• RELACIONADO: Recupera o valor de "um" lado de um relacionamento. É útil quando envolve cálculos de diferentes tabelas que são avaliadas em contexto de linha.
• RELATEDTABLE: Recupere uma tabela de linhas do lado "muitos" de um relacionamento.
• USERELATIONSHIP: Permite que um cálculo use uma relação inativa. (Tecnicamente, esta função modifica o peso de uma relação de modelo inativo específica, ajudando a influenciar o seu uso.) É útil quando seu modelo inclui uma tabela de dimensões de interpretação de papéis e você opta por criar relações inativas a partir dessa tabela. Você também pode usar essa função para resolver ambiguidade em caminhos de filtro.
• CROSSFILTER: Modifica a relação direção do filtro cruzado (para um ou ambos) ou desativa a propagação do filtro (nenhum). É útil quando você precisa alterar ou ignorar relações de modelo durante a avaliação de um cálculo específico.
• COMBINEVALUES: une duas ou mais cadeias de texto em uma cadeia de texto. O objetivo dessa função é oferecer suporte a relações de várias colunas em modelos DirectQuery quando as tabelas pertencem ao mesmo grupo de origem.
• TREATAS: Aplica o resultado de uma expressão de tabela como filtros a colunas de uma tabela não relacionada. É útil em cenários avançados quando você deseja criar um relacionamento virtual durante a avaliação de um cálculo específico.
• Funções pai e filho: uma família de funções relacionadas que você pode usar para gerar colunas calculadas para naturalizar uma hierarquia pai-filho. Em seguida, você pode usar essas colunas para criar uma hierarquia de nível fixo.

Avaliação de relacionamento

As relações de modelo, do ponto de vista da avaliação, são classificadas como regulares ou limitadas. Não é uma propriedade de relacionamento configurável. Na verdade, é inferido a partir do tipo de cardinalidade e da fonte de dados das duas tabelas relacionadas. É importante entender o tipo de avaliação porque pode haver implicações ou consequências de desempenho caso a integridade dos dados seja comprometida. Essas implicações e consequências de integridade são descritas neste tópico.

Primeiro, alguma teoria de modelagem é necessária para entender completamente as avaliações de relacionamento.

Um modelo de importação ou DirectQuery obtém todos os seus dados do cache Vertipaq ou do banco de dados de origem. Em ambos os casos, o Power BI é capaz de determinar que existe um lado "um" de uma relação.

Um modelo composto, no entanto, pode incluir tabelas usando diferentes modos de armazenamento (importação, DirectQuery ou dual) ou várias fontes DirectQuery. Cada fonte, incluindo o cache Vertipaq de dados importados, é considerada um grupo de fontes. As relações de modelo podem então ser classificadas como grupo intra-fonte ou grupo inter/entre fontes. Uma relação de grupo intra-fonte relaciona duas tabelas dentro de um grupo de origem, enquanto uma relação de grupo entre fontes/entre fontes relaciona tabelas em dois grupos de origem. Observe que as relações em modelos de importação ou DirectQuery são sempre intragrupo de origem.

Aqui está um exemplo de um modelo composto.

Neste exemplo, o modelo composto consiste em dois grupos de origem: um grupo de origem Vertipaq e um grupo de origem DirectQuery. O grupo de origem Vertipaq contém três tabelas e o grupo de origem DirectQuery contém duas tabelas. Existe uma relação de grupo entre fontes para relacionar uma tabela no grupo de origem Vertipaq a uma tabela no grupo de origem DirectQuery.

Relações regulares

Uma relação de modelo é regular quando o mecanismo de consulta pode determinar o lado "um" da relação. Ele tem a confirmação de que a coluna lateral "um" contém valores exclusivos. Todas as relações de grupo intra-fonte um-para-muitos são relações regulares.

No exemplo a seguir, há duas relações regulares, ambas marcadas como R. As relações incluem a relação um-para-muitos contida no grupo de origem Vertipaq e a relação um-para-muitos contida na fonte DirectQuery.

Para modelos de importação, onde todos os dados são armazenados no cache Vertipaq, o Power BI cria uma estrutura de dados para cada relação regular no momento da atualização de dados. As estruturas de dados consistem em mapeamentos indexados de todos os valores coluna a coluna e sua finalidade é acelerar a junção de tabelas no momento da consulta.

No momento da consulta, as relações regulares permitem que a expansão da tabela aconteça. A expansão da tabela resulta na criação de uma tabela virtual incluindo as colunas nativas da tabela base e, em seguida, expandindo para tabelas relacionadas. Para tabelas de importação, a expansão da tabela é feita no mecanismo de consulta; para tabelas DirectQuery, isso é feito na consulta nativa enviada para o banco de dados de origem (desde que a propriedade de integridade referencial Assume não esteja habilitada). Em seguida, o mecanismo de consulta atua sobre a tabela expandida, aplicando filtros e agrupando pelos valores nas colunas da tabela expandida.

Nota

As relações inativas também são expandidas, mesmo quando a relação não é usada por um cálculo. As relações bidirecionais não têm impacto na expansão da tabela.

Para relações um-para-muitos, a expansão da tabela ocorre dos lados "muitos" para "um" usando LEFT OUTER JOIN semântica. Quando um valor correspondente do lado "muitos" para o lado "um" não existe, uma linha virtual em branco é adicionada à tabela lateral "um". Este comportamento aplica-se apenas a relações regulares, não a relações limitadas.

A expansão da tabela também ocorre para relações de grupo intra-fonte um-para-um, mas usando FULL OUTER JOIN semântica. Esse tipo de junção garante que linhas virtuais em branco sejam adicionadas em ambos os lados, quando necessário.

Linhas virtuais em branco são membros efetivamente desconhecidos. Membros desconhecidos representam violações de integridade referencial onde o valor de lado "muitos" não tem valor de lado "um" correspondente. Idealmente, esses espaços em branco não deveriam existir. Eles podem ser eliminados limpando ou reparando os dados de origem.

Veja como a expansão de tabela funciona com um exemplo animado.

Neste exemplo, o modelo consiste em três tabelas: Categoria, Produto e Vendas. A tabela Categoria está relacionada à tabela Produto com uma relação um-para-muitos, e a tabela Produto está relacionada à tabela Vendas com uma relação um-para-muitos. A tabela Categoria contém duas linhas, a tabela Produto contém três linhas e as tabelas Vendas contém cinco linhas. Há valores correspondentes em ambos os lados de todos os relacionamentos, o que significa que não há violações de integridade referencial. Uma tabela expandida em tempo de consulta é revelada. A tabela consiste nas colunas das três tabelas. É efetivamente uma perspetiva desnormalizada dos dados contidos nas três tabelas. Uma nova linha é adicionada à tabela Sales e tem um valor de identificador de produção (9) que não tem valor correspondente na tabela Product . É uma violação de integridade referencial. Na tabela expandida, a nova linha tem valores (Em branco) para as colunas da tabela Categoria e Produto.

Relações limitadas

Uma relação modelo é limitada quando não há um lado "um" garantido. Uma relação limitada pode acontecer por dois motivos:

• A relação usa um tipo de cardinalidade muitos-para-muitos (mesmo que uma ou ambas as colunas contenham valores exclusivos).
• A relação é de grupo de fontes cruzadas (o que só pode ser o caso de modelos compostos).

No exemplo a seguir, há duas relações limitadas, ambas marcadas como L. As duas relações incluem a relação muitos-para-muitos contida no grupo de origem Vertipaq e a relação um-para-muitos grupo de origem cruzada.

Para modelos de importação, as estruturas de dados nunca são criadas para relações limitadas. Nesse caso, o Power BI resolve junções de tabela no momento da consulta.

A expansão da tabela nunca ocorre para relações limitadas. As junções de tabela são obtidas usando INNER JOIN semântica e, por esse motivo, linhas virtuais em branco não são adicionadas para compensar violações de integridade referencial.

Existem outras restrições relacionadas com relações limitadas:

• A RELATED função DAX não pode ser usada para recuperar os valores de coluna lateral "um".
• A imposição de RLS tem restrições de topologia.

Gorjeta

No modo de exibição de modelo do Power BI Desktop, você pode interpretar uma relação como limitada. Uma relação limitada é representada com marcas semelhantes a parênteses ( ) após os indicadores de cardinalidade.

Resolver a ambiguidade do caminho do relacionamento

As relações bidirecionais podem introduzir vários e, portanto, ambíguos caminhos de propagação de filtro entre tabelas de modelo. Ao avaliar a ambiguidade, o Power BI escolhe o caminho de propagação do filtro de acordo com sua prioridade e peso.

Prioridade

As camadas de prioridade definem uma sequência de regras que o Power BI usa para resolver a ambiguidade do caminho de relacionamento. A primeira correspondência de regra determina o caminho que o Power BI seguirá. Cada regra abaixo descreve como os filtros fluem de uma tabela de origem para uma tabela de destino.

1. Um caminho que consiste em relações um-para-muitos.
2. Um caminho que consiste em relações um-para-muitos ou muitos-para-muitos.
3. Um caminho que consiste em relações muitos-para-um.
4. Um caminho que consiste em relações um-para-muitos da tabela de origem para uma tabela intermediária seguida por relações muitos-para-um da tabela intermediária para a tabela de destino.
5. Um caminho que consiste em relações um-para-muitos ou muitos-para-muitos da tabela de origem para uma tabela intermediária seguida por relações muitos-para-um ou muitos-para-muitos da tabela intermediária para a tabela de destino.
6. Qualquer outro caminho.

Quando um relacionamento é incluído em todos os caminhos disponíveis, ele é removido da consideração de todos os caminhos.

Espessura

Cada relação num caminho tem um peso. Por padrão, cada peso de relacionamento é igual, a menos que a função USERELATIONSHIP seja usada. O peso do caminho é o máximo de todos os pesos de relacionamento ao longo do caminho. O Power BI usa as ponderações de caminho para resolver a ambiguidade entre vários caminhos na mesma camada de prioridade. Ele não escolherá um caminho com uma prioridade menor, mas escolherá o caminho com o peso mais alto. O número de relações no caminho não afeta o peso.

Você pode influenciar o peso de um relacionamento usando a função USERELATIONSHIP . O peso é determinado pelo nível de aninhamento da chamada para esta função, onde a chamada mais interna recebe o maior peso.

Considere o seguinte exemplo. A medida Vendas de Produtos atribui um peso maior à relação entre Sales[ProductID] e Product[ProductID], seguida pela relação entre Inventory[ProductID] e Product[ProductID].

Product Sales = 
CALCULATE(
    CALCULATE(
        SUM(Sales[SalesAmount]), 
        USERELATIONSHIP(Sales[ProductID], Product[ProductID])
    ),
    USERELATIONSHIP(Inventory[ProductID], Product[ProductID])
)

Nota

Se o Power BI detetar vários caminhos que têm a mesma prioridade e o mesmo peso, ele retornará um erro de caminho ambíguo. Nesse caso, você deve resolver a ambiguidade influenciando os pesos de relacionamento usando a função USERELATIONSHIP ou removendo ou modificando relações de modelo.

Preferência de desempenho

A lista a seguir ordena o desempenho de propagação do filtro, do desempenho mais rápido para o mais lento:

1. Relações de grupo intra-fonte um-para-muitos
2. Relações de modelo muitos-para-muitos alcançadas com uma tabela intermediária e que envolvem pelo menos uma relação bidirecional
3. Relações de cardinalidade muitos-para-muitos
4. Relações de grupo entre fontes

Conteúdos relacionados

Para obter mais informações sobre este artigo, consulte os seguintes recursos:

• Compreender o esquema em estrela e a importância para o Power BI
• Orientação de relacionamento um-para-um
• Orientação de relacionamento muitos-para-muitos
• Orientação de relacionamento ativo vs inativo
• Orientação de relacionamento bidirecional
• Orientação para solução de problemas de relacionamento
• Vídeo: O que fazer e o que não fazer das relações do Power BI
• Perguntas? Tente perguntar à Comunidade do Power BI
• Sugestões? Contribua com ideias para melhorar o Power BI