Aplicar relações muitos-para-muitos no Power BI Desktop

  • Artigo

Com relações com uma cardinalidade muitos-para-muitos no Power BI Desktop, você pode unir tabelas que usam uma cardinalidade de muitos-para-muitos. Você pode criar modelos de dados de forma mais fácil e intuitiva que contenham duas ou mais fontes de dados. As relações com uma cardinalidade muitos-para-muitos fazem parte dos recursos maiores de modelos compostos no Power BI Desktop. Para obter mais informações sobre modelos compostos, consulte Usar modelos compostos no Power BI Desktop

Captura de ecrã de uma relação muitos-para-muitos no painel Editar relações.

O que uma relação com uma cardinalidade muitos-para-muitos resolve

Antes de as relações com uma cardinalidade muitos-para-muitos se tornarem disponíveis, a relação entre duas tabelas era definida no Power BI. Pelo menos uma das colunas da tabela envolvidas na relação tinha que conter valores exclusivos. Muitas vezes, porém, nenhuma coluna continha valores exclusivos.

Por exemplo, duas tabelas podem ter uma coluna chamada CountryRegion. No entanto, os valores de CountryRegion não foram únicos em nenhuma das tabelas. Para juntar essas tabelas, você teve que criar uma solução alternativa. Uma solução alternativa pode ser introduzir tabelas extras com os valores exclusivos necessários. Com relacionamentos com uma cardinalidade muitos-para-muitos, você pode juntar essas tabelas diretamente, se você usar um relacionamento com uma cardinalidade de muitos-para-muitos.

Use relacionamentos com uma cardinalidade muitos-para-muitos

Ao definir uma relação entre duas tabelas no Power BI, você deve definir a cardinalidade da relação. Por exemplo, a relação entre ProductSales e Product, usando as colunas ProductSales[ProductCode] e Product[ProductCode], seria definida como Many-1. Definimos a relação desta forma, porque cada produto tem muitas vendas, e a coluna na tabela Produto (ProductCode) é única. Quando você define uma cardinalidade de relacionamento como Muitos-1, 1-Muitos ou 1-1, o Power BI a valida, de modo que a cardinalidade selecionada corresponde aos dados reais.

Por exemplo, dê uma olhada no modelo simples nesta imagem:

Captura de ecrã da tabela ProductSales e Product na vista Relação.

Agora, imagine que a tabela Produto exibe apenas duas linhas, conforme mostrado:

Captura de ecrã de um visual de tabela de produtos com duas linhas.

Imagine também que a tabela Vendas tem apenas quatro linhas, incluindo uma linha para um produto C. Devido a um erro de integridade referencial, a linha C do produto não existe na tabela Produto .

Captura de ecrã de um visual de tabela Sales com quatro linhas.

O ProductName e o Price (da tabela Product), juntamente com o Qty total de cada produto (da tabela ProductSales), seriam exibidos conforme mostrado:

Captura de tela de um Visual exibindo o nome, o preço e a quantidade do produto.

Como você pode ver na imagem anterior, uma linha ProductName em branco está associada às vendas do produto C. Esta linha em branco tem em conta as seguintes considerações:

  • Quaisquer linhas na tabela ProductSales para as quais não exista uma linha correspondente na tabela Product. Há um problema de integridade referencial, como vemos para o produto C neste exemplo.

  • Quaisquer linhas na tabela ProductSales para as quais a coluna de chave estrangeira é nula.

Por estas razões, a linha em branco em ambos os casos contabiliza as vendas em que o ProductName e o Price são desconhecidos.

Às vezes, as tabelas são unidas por duas colunas, mas nenhuma coluna é exclusiva. Por exemplo, considere estas duas tabelas:

  • A tabela Sales exibe dados de vendas por Estado, e cada linha contém o valor de vendas para o tipo de venda nesse estado. Os estados incluem CA, WA e TX.

    Captura de tela de uma tabela Sales exibindo vendas por estado.

  • A tabela CityData exibe dados sobre cidades, incluindo a população e o estado (como CA, WA e Nova York).

    Captura de tela de uma tabela Sales exibindo cidade, estado e população.

Uma coluna para Estado está agora em ambas as tabelas. É razoável querer informar sobre as vendas totais por estado e população total de cada estado. No entanto, existe um problema: a coluna Estado não é exclusiva em nenhuma das tabelas.

A solução alternativa anterior

Antes da versão de julho de 2018 do Power BI Desktop, não era possível criar uma relação direta entre essas tabelas. Uma solução comum foi:

  • Crie uma terceira tabela que contenha apenas as IDs de estado exclusivas. A tabela pode ser qualquer um ou todos:

    • Uma tabela calculada (definida usando Data Analysis Expressions [DAX]).
    • Uma tabela baseada numa consulta definida no Power Query Editor, que pode apresentar os IDs exclusivos extraídos de uma das tabelas.
    • O conjunto completo combinado.

  • Em seguida, relacione as duas tabelas originais a essa nova tabela usando relações Many-1 comuns.

Você pode deixar a tabela de solução alternativa visível. Ou você pode ocultar a tabela de solução alternativa, para que ela não apareça na lista Campos . Se você ocultar a tabela, as relações Many-1 normalmente serão definidas para filtrar em ambas as direções, e você poderá usar o campo Estado de qualquer tabela. Esta última filtragem cruzada propagar-se-ia para a outra tabela. Essa abordagem é mostrada na imagem a seguir:

Captura de ecrã de uma tabela de Estado oculta na vista Relação.

Um visual que exibe o Estado (da tabela CityData), juntamente com a População total e o total de Vendas, apareceria da seguinte maneira:

Captura de ecrã a mostrar uma tabela com dados de Estado, População e Vendas.

Nota

Como o estado da tabela CityData é usado nesta solução alternativa, somente os estados nessa tabela são listados, portanto, TX é excluído. Além disso, ao contrário das relações Many-1, embora a linha total inclua todas as Vendas (incluindo as de TX), os detalhes não incluem uma linha em branco cobrindo essas linhas incompatíveis. Da mesma forma, nenhuma linha em branco cobriria Vendas para as quais há um valor nulo para o Estado.

Suponha que você também adicione City a esse visual. Embora a população por cidade seja conhecida, as Vendas mostradas para Cidade simplesmente repetem as Vendas para o Estado correspondente. Esse cenário normalmente ocorre quando o agrupamento de colunas não está relacionado a alguma medida agregada, como mostrado aqui:

Captura de tela de uma tabela mostrando a população e as vendas do estado e da cidade.

Digamos que você defina a nova tabela Vendas como a combinação de todos os Estados aqui, e nós a tornamos visível na lista Campos . O mesmo visual exibiria o Estado (na nova tabela), a População total e o total de Vendas:

Captura de tela de um visual mostrando Estado, população e visual de vendas.

Como você pode ver, TX — com dados de Vendas, mas dados de População desconhecidos — e Nova York — com dados de População conhecidos, mas sem dados de Vendas — seriam incluídos. Essa solução alternativa não é ideal e tem muitos problemas. Para relacionamentos com cardinalidade muitos-para-muitos, as questões resultantes são abordadas, conforme descrito na próxima seção.

Para obter mais informações sobre como implementar essa solução alternativa, consulte Diretrizes de relacionamento muitos-para-muitos.

Use um relacionamento com uma cardinalidade muitos-para-muitos em vez da solução alternativa

Você pode relacionar tabelas diretamente, como as que descrevemos anteriormente, sem ter que recorrer a soluções alternativas. Agora é possível definir a cardinalidade da relação para muitos-para-muitos. Essa configuração indica que nenhuma tabela contém valores exclusivos. Para essas relações, você ainda pode controlar qual tabela filtra a outra tabela. Ou você pode aplicar filtragem bidirecional, onde cada tabela filtra a outra.

No Power BI Desktop, a cardinalidade assume como padrão muitos-para-muitos quando determina que nenhuma tabela contém valores exclusivos para as colunas de relacionamento. Nesses casos, uma mensagem de aviso confirma que você deseja definir uma relação e que a alteração não é o efeito indesejado de um problema de dados.

Por exemplo, quando você cria uma relação diretamente entre CityData e Sales, onde os filtros devem fluir de CityData para Sales, o Power BI Desktop exibe a caixa de diálogo Editar relacionamento :

Captura de ecrã da caixa de diálogo Editar relação com a direção Cardinalidade e Filtro cruzado realçada.

O modo de exibição Relacionamento resultante exibiria a relação direta, muitos-para-muitos, entre as duas tabelas. A aparência das tabelas na lista Campos e seu comportamento posterior quando os elementos visuais são criados são semelhantes aos de quando aplicamos a solução alternativa. Na solução alternativa, a tabela extra que exibe os dados de estado distintos não é tornada visível. Conforme descrito anteriormente, um visual que mostra dados de Estado, População e Vendas seria exibido:

Captura de ecrã de uma tabela Estado, População e Vendas.

As principais diferenças entre as relações com uma cardinalidade muitos-para-muitos e as relações Many-1 mais típicas são as seguintes:

  • Os valores mostrados não incluem uma linha em branco que contabiliza linhas incompatíveis na outra tabela. Além disso, os valores não levam em conta as linhas em que a coluna usada na relação na outra tabela é nula.

  • Não é possível usar a RELATED() função, porque mais de uma linha pode estar relacionada.

  • Usar a ALL() função em uma tabela não remove filtros que são aplicados a outras tabelas relacionadas por uma relação muitos-para-muitos. No exemplo anterior, uma medida definida como mostrado aqui não removeria filtros em colunas na tabela CityData relacionada:

    Captura de tela de um exemplo de script. O exemplo é, Total de vendas = Calcular(Soma('Vendas'[Vendas]), Todos('Vendas')).

    Um visual mostrando dados de estado, vendas e total de vendas resultaria neste gráfico:

    Captura de ecrã de um visual de tabela que mostra o Estado, as Vendas e o total de Vendas resultantes da fórmula.

Com as diferenças anteriores em mente, certifique-se de que os cálculos usados ALL(<Table>), como % do total geral, estão retornando os resultados pretendidos.

Considerações e limitações

Existem algumas limitações para esta libertação de relações com uma cardinalidade muitos-para-muitos e modelos compostos.

As seguintes fontes (multidimensionais) do Live Connect não podem ser usadas com modelos compostos:

  • SAP HANA
  • SAP Business Warehouse
  • SQL Server Analysis Services
  • Modelos semânticos do Power BI
  • Azure Analysis Services

Quando você se conecta a essas fontes multidimensionais usando o DirectQuery, não pode se conectar a outra fonte do DirectQuery ou combiná-la com dados importados.

As limitações existentes do uso do DirectQuery ainda se aplicam quando você usa relações com cardinalidade muitos-para-muitos. Muitas limitações agora são por tabela, dependendo do modo de armazenamento da tabela. Por exemplo, uma coluna calculada em uma tabela importada pode se referir a outras tabelas, mas uma coluna calculada em uma tabela DirectQuery ainda pode se referir apenas a colunas na mesma tabela. Outras limitações se aplicam a todo o modelo se alguma tabela dentro do modelo for DirectQuery. Por exemplo, os recursos QuickInsights e P&R não estarão disponíveis em um modelo se qualquer tabela dentro dele tiver um modo de armazenamento do DirectQuery.

Conteúdos relacionados

Para obter mais informações sobre modelos compostos e DirectQuery, consulte os seguintes artigos: