Diretrizes de relação um-para-um

Este artigo tem como destino você como um modelador de dados que trabalha com o Power BI Desktop. Ele fornece diretrizes 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.

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.

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

• Dimensão de degeneração: é possível derivar uma dimensão de degeneração de uma tabela de fatos.

• Dados de linha que abrangem tabelas: uma entidade empresarial ou entidade é carregada como duas (ou mais) tabelas de modelo, possivelmente porque os dados são provenientes de fontes de dados diferentes. Esse cenário pode ser comum para tabelas de dimensão. Por exemplo, os detalhes do produto mestre são armazenados em um sistema de vendas operacionais, e os detalhes do produto suplementar são armazenados em outra fonte.

  No entanto, é incomum relacionar 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 de modelo fosse criada.

Dimensões de degeneração

Quando 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 dessas colunas usadas para resumir linhas de fatos. Essa separação pode:

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

Considere uma tabela de origem chamada Sales que armazena informações de referência de linha de ordem de vendas em duas colunas.

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

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

A tabela de dimensões Sales Order fornece uma experiência avançada para autores de relatório com duas colunas: Sales Order e Sales Order Line. Essas colunas específicas dão suporte a designs de relatório que precisam filtrar, agrupar ou analisar detalhadamente os pedidos 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 pelas tabelas

Considere um exemplo que envolva duas tabelas de dimensão 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.

Confira abaixo um diagrama de modelo parcial das duas tabelas.

A primeira tabela é denominada 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 colunas SKU. A relação é filtrada em ambas as direções, que é sempre o caso para relações um-para-um.

Para ajudar a descrever como a propagação do filtro de relação funciona, a imagem a seguir revela algumas linhas de tabela. Todos os exemplos deste artigo se baseiam nesses dados.

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

• A tabela Product tem três linhas:
  • SKU CL-01, ProductT-shirt, ColorGreen
  • SKU CL-02, ProductJeans, ColorBlue
  • SKUAC-01, ProductChapéu, ColorAzul
• A tabela Product Category tem duas linhas:
  • SKU CL-01, CategoryClothing
  • SKUAC-01, acessórios Category

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

No painel Data, os autores do relatório encontram campos relacionados ao produto em duas tabelas: Product e Product Category. Vejamos o que acontece quando os 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 Category para o produto, SKU CL-02, é BLANK. Isso ocorre porque não há nenhuma linha correspondente na tabela Product Category deste 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 pelas tabelas de modelo. Isso ocorre porque esse design pode:

• Contribuem para a desordem do painel Dados, listando mais tabelas do que o necessário.
• Dificultam a localização de campos relacionados por autores de relatório, pois sã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.
• Gera resultados inesperados quando não há uma correspondência completa de linhas entre as tabelas.

As recomendações específicas diferem dependendo se a relação um-para-um é interna ao grupo de origem ou entre grupos de origem. Para obter mais informações sobre avaliação de relação, consulte Relações de modelo no Power BI Desktop.

Relação um-para-um interna ao grupo de origem

Quando existe uma relação um-para-um interna ao grupo de origem entre as 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 à esquerda , que é o tipo de junção padrão. Esse tipo de junção garante que você mantenha todas as linhas da primeira consulta e as complete com as linhas correspondentes da segunda consulta. Expanda todas as colunas necessárias da segunda consulta na primeira consulta.

   

2. Desabilitar o carregamento de consulta: certifique-se de desabilitar o carregamento da segunda consulta. Dessa forma, não haverá o carregamento de seu resultado como uma tabela de modelo. Essa configuração reduz o tamanho do armazenamento do modelo de dados e ajuda a organizar o painel Dados.

   Em nosso exemplo, os autores dos relatórios agora encontram uma única tabela chamada Product no painel de dados do . Contém todos os campos relacionados ao produto.

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

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

   

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

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

   

Caso você goste de como as tabelas separadas ajudam a organizar seus campos, ainda é recomendável consolidar em uma única tabela. Você ainda pode organizar seus campos, mas usando pastas de exibição em vez disso.

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

Se você ainda decidir definir relações um-para-um internas ao grupo de origem em seu modelo, quando possível, verifique se há linhas correspondentes nas tabelas relacionadas. A medida que uma relação um-para-um interna ao grupo de origem é avaliada como uma relação regular, problemas de integridade de dados podem surgir nos visuais do relatório como valores em branco. (Você pode ver um exemplo de um agrupamento EM BRANCO no primeiro visual da tabela apresentada neste artigo.)

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

Quando existe uma relação um-para-um entre o grupo de origem e as tabelas, não há design alternativo de modelo, a menos que você pré-consolide 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 as linhas não compatíveis são eliminadas dos resultados da consulta.

Vejamos o que acontece quando os 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. O SKU do produto CL-02 está faltando porque não há uma linha correspondente na tabela Product Category. O visual da segunda tabela, baseado em uma única tabela consolidada no modelo, exibe três linhas.

Conteúdo relacionado

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

• Modelar relações no Power BI Desktop
• Entender o esquema em estrela e a importância para o Power BI
• Diretrizes da solução de problemas de relação
• Perguntas? Tente perguntar à Comunidade do Fabric
• Sugestões? Contribua com ideias para aprimorar o Fabric