Orientação de relacionamento um-para-um

Este artigo destina-se a você como um modelador de dados que trabalha com o Power BI Desktop. Ele fornece orientação sobre como trabalhar com relações de modelo um-para-um. Uma relação um-para-um pode ser criada quando ambas as tabelas contêm uma coluna de valores comuns e exclusivos.

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.

Há dois cenários que envolvem relações um-para-um:

• Dimensões degeneradas: Você pode derivar uma dimensão degenerada de uma tabela de fatos .

• Os dados de linha se estendem por tabelas: Uma única entidade de negócios ou assunto é carregado como duas (ou mais) tabelas de modelo, possivelmente porque seus dados são provenientes de armazenamentos de dados diferentes. Esse cenário pode ocorrer frequentemente em tabelas de dimensão . Por exemplo, os detalhes do produto mestre são armazenados em um sistema de vendas operacional e os detalhes suplementares do produto são armazenados em uma fonte diferente.

  É incomum, no entanto, que você relacione duas tabelas de fatos com uma relação um-para-um. Isso porque ambas as tabelas de fatos precisariam ter a mesma dimensionalidade e granularidade. Além disso, cada tabela de fatos precisaria de colunas exclusivas para permitir que a relação do modelo fosse criada.

Dimensões degeneradas

Quando as colunas de uma tabela de fatos são usadas para filtragem ou agrupamento, você pode considerar disponibilizá-las em uma tabela separada. Dessa forma, você separa as colunas usadas para filtragem ou agrupamento das colunas usadas para resumir linhas de fatos. Esta separação pode:

• Reduza o espaço de armazenamento.
• Simplifique os cálculos do modelo.
• Contribua para melhorar o desempenho das consultas.
• Ofereça uma experiência mais intuitiva do painel de dados aos autores do relatório.

Considere uma tabela de origem chamada Sales que armazena referências detalhadas das linhas de ordens de venda em duas colunas.

A coluna OrderNumber armazena o número da ordem e a coluna OrderLineNumber armazena uma sequência de linhas dentro da ordem.

Na imagem a seguir, observe que as colunas número do pedido e número da linha do pedido não foram carregadas na tabela Sales. Em vez disso, os valores deles foram usados para criar uma coluna de chave substituta chamada OrderLineNumberID. (O valor da chave é calculado multiplicando o número da ordem por 1000 e, em seguida, adicionando o número da linha da ordem.)

A tabela de dimensões Sales Order fornece uma experiência rica para os autores de relatórios com duas colunas: Sales Order e Sales Order Line. Essas colunas específicas oferecem suporte a designs de relatórios que precisam filtrar, agrupar ou detalhar ordens e linhas de pedidos.

Como a tabela Sales Order é derivada dos dados de vendas, deve haver exatamente o mesmo número de linhas em cada tabela. Além disso, deve haver valores correspondentes entre cada coluna OrderLineNumberID.

Os dados de linha se estendem por tabelas

Considere um exemplo que envolve duas tabelas de dimensões relacionadas um-para-um: Product e Product Category. Cada tabela representa dados importados e tem uma coluna SKU (unidade de manutenção de estoque) que contém valores exclusivos.

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

A primeira tabela tem o nome Producte contém três colunas: Color, Producte SKU. A segunda tabela é denominada Product Categorye contém duas colunas: Category e SKU. Uma relação um-para-um relaciona as duas SKU colunas. A relação filtra em ambas as direções, o que é sempre o caso das relações um-para-um.

Para ajudar a descrever como funciona a propagação do filtro de relacionamento, a imagem a seguir revela algumas linhas da tabela. Todos os exemplos neste artigo são baseados nesses dados.

Os detalhes da linha para as duas tabelas são descritos na seguinte lista com marcadores:

• A tabela Product tem três linhas:
  • SKU CL-01, ProductCamiseta, ColorVerde
  • SKU CL-02, ProductJeans, ColorBlue
  • SKU AC-01, ProductChapéu, ColorAzul
• A tabela Product Category tem duas linhas:
  • SKU CL-01, CategoryVestuário
  • SKU AC-01, CategoryAcessórios

Observe que a tabela Product Category não inclui uma linha para o produto SKU CL-02. Discutiremos as consequências dessa linha ausente mais adiante neste artigo.

No painel de dados, os autores de relatórios localizam campos relacionados ao produto em duas tabelas: Product e Product Category. Vamos ver o que acontece quando campos de ambas as tabelas são adicionados a um visual de tabela. Neste exemplo, a coluna SKU é originada da tabela Product.

Observe que o valor de Category para o produto SKU CL-02 é BLANK. Isso porque não há nenhuma linha correspondente na tabela de Product Category para este produto.

Recomendações

Quando possível, recomendamos que você evite criar relações de modelo um-para-um quando os dados de linha se estendem entre tabelas de modelo. Isso porque esse design pode:

• Contribua para a confusão do painel Dados , listando mais tabelas do que o necessário.
• Torne difícil para os autores de relatórios encontrar campos relacionados, porque eles estão distribuídos em várias tabelas.
• Limite a capacidade de criar hierarquias, pois seus níveis devem ser baseados em colunas da mesma tabela.
• Produza resultados inesperados quando não houver uma correspondência completa de linhas entre as tabelas.

As recomendações específicas diferem consoante a relação um-para-um seja intra-source group ou cross source group. Para obter mais informações sobre avaliação de relações, consulte Modelos de relações no Power BI Desktop.

Relação um-para-um intra-grupo de origem

Quando existe uma relação de grupo intra-fonte um-para-um entre tabelas, recomendamos consolidar os dados em uma única tabela de modelo. Você pode fazer isso mesclando as consultas do Power Query.

As etapas a seguir apresentam uma metodologia para consolidar e modelar os dados relacionados um-para-um.

1. Mesclar consultas: ao combinar as duas consultas, considere a integridade dos dados em cada consulta. Se uma consulta contiver um conjunto completo de linhas (como uma lista mestra), mescle a outra consulta com ela. Defina a transformação de mesclagem para usar uma junção externa , que é o tipo de junção padrão. Esse tipo de associação garante que você manterá todas as linhas da primeira consulta e as complementará com quaisquer linhas correspondentes da segunda consulta. Expanda todas as colunas necessárias da segunda consulta para a primeira.

   

2. Desativar carga de consulta: Certifique-se de desativar a carga da segunda consulta. Dessa forma, ele não carregará seu resultado como uma tabela modelo. Essa configuração reduz o tamanho de armazenamento do modelo de dados e ajuda a organizar o painel Dados .

   Em nosso exemplo, os autores de relatórios agora encontram uma única tabela chamada no painel Dados. Ele contém todos os campos relacionados ao produto.

3. Substituir valores ausentes: se a segunda consulta tiver linhas incomparáveis, os valores nulos aparecerão nas colunas introduzidas a partir dela. Quando apropriado, considere substituir valores nulos por um valor de token. A substituição de valores ausentes é especialmente importante quando os autores de relatórios filtram ou agrupam pelos valores de coluna, pois BLANKs podem aparecer em visuais de relatório.

   Na imagem a seguir, observe que a categoria do produto SKU CL-02 agora lê [Indefinido]. Na consulta, as categorias nulas foram substituídas por esse valor de texto de token.

   

4. Criar hierarquias: se existirem relações entre as colunas da tabela agora consolidada, considere a criação de hierarquias. Dessa forma, os autores do relatório identificarão rapidamente oportunidades para a perfuração visual do relatório.

   Em nosso exemplo, os autores de relatórios agora podem usar uma hierarquia que tem dois níveis: Category e Product.

   

Se você gosta de como tabelas separadas ajudam a organizar seus campos, ainda recomendamos a consolidação em uma única tabela. Você ainda pode organizar seus campos, mas usando pastas de exibição.

Em nosso exemplo, os autores de relatórios podem encontrar o campo Category dentro da pasta de exibição Marketing.

Se você ainda decidir definir relações de grupo intra-fonte um-para-um em seu modelo, quando possível, verifique se há linhas correspondentes nas tabelas relacionadas. Como uma relação de grupo intra-fonte um-para-um é avaliada como uma relação regular, problemas de integridade de dados podem surgir em seus visuais de relatório como BLANKs. (Você pode ver um exemplo de um agrupamento BLANK no primeiro visual de tabela apresentado neste artigo.)

Relação um-para-um entre grupos de origem

Quando existe uma relação de grupo de origem cruzado de um para um entre as tabelas, não existe um design alternativo para o modelo, a menos que se pré-consolidem os dados na sua fonte de dados. O Power BI avaliará a relação de modelo um-para-um como uma relação limitada. Portanto, tome cuidado para garantir que haja linhas correspondentes nas tabelas relacionadas, pois linhas incomparáveis são eliminadas dos resultados da consulta.

Vamos ver o que acontece quando campos de ambas as tabelas são adicionados a um visual de tabela e existe uma relação limitada entre as tabelas.

O primeiro visual de tabela, que usa uma relação de grupo entre fontes, exibe apenas duas linhas. Produto SKU CL-02 está faltando porque não há nenhuma linha correspondente na tabela Product Category. O visual da segunda tabela, baseado em uma única tabela consolidada no modelo, exibe três linhas.

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? Experimente perguntar à Comunidade Fabric
• Sugestões? Contribua com ideias para melhorar o Fabric