Partilhar via


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 tipo de fato.

  • 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 ser comum para tabelas de tipo 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 tipo de fato com uma relação um-para-um. Isso porque ambas as tabelas de tipo de fato precisariam ter a mesma dimensionalidade e granularidade. Além disso, cada tabela de tipo de fato precisaria de colunas exclusivas para permitir que a relação de modelo fosse criada.

Dimensões degeneradas

Quando colunas de uma tabela de tipo de fato são usadas para filtragem ou agrupamento, você pode considerar disponibilizá-las em uma tabela separada. Dessa forma, você separa as colunas usadas para filtro 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 da consulta
  • Ofereça uma experiência mais intuitiva do painel Campos aos autores de relatórios

Considere uma tabela de vendas de origem que armazene os detalhes da ordem de venda em duas colunas.

Table rows for a sales table.

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

No diagrama de modelo a seguir, observe que as colunas número do pedido e número da linha do pedido não foram carregadas na tabela Vendas . Em vez disso, seus valores foram usados para criar uma coluna de chave substituta chamada SalesOrderLineID. (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 model diagram contains two tables: Sales and Sales Order. A one-to-one relationship relates the SalesOrderLineID columns.

A tabela Ordem de Venda fornece uma experiência rica para os autores de relatórios com três colunas: Ordem de Venda, Linha de Ordem de Venda e Número de Linha. Inclui também uma hierarquia. Esses recursos de tabela oferecem suporte a designs de relatórios que precisam filtrar, agrupar por ou detalhar ordens e linhas de pedidos.

Como a tabela Ordem de Venda é 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 SalesOrderLineID .

Os dados de linha se estendem por tabelas

Considere um exemplo envolvendo duas tabelas de tipo de dimensão relacionadas um-para-um: Produto e Categoria de Produto. Cada tabela representa dados importados e tem uma coluna SKU (Stock-Keeping Unit) contendo valores exclusivos.

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

A model diagram contains two tables. The design is described in the following paragraph.

A primeira tabela é chamada Produto e contém três colunas: Cor, Produto e SKU. A segunda tabela é chamada Categoria de Produto e contém duas colunas: Categoria e SKU. Uma relação um-para-um relaciona as duas colunas de SKU . 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, o diagrama de modelo foi modificado para revelar as linhas da tabela. Todos os exemplos neste artigo são baseados nesses dados.

Nota

Não é possível exibir linhas de tabela no diagrama de modelo do Power BI Desktop. É feito neste artigo para apoiar a discussão com exemplos claros.

The model diagram now reveals the table rows. The row details are described in the following paragraph.

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

  • A tabela Produto tem três linhas:
    • SKU CL-01, T-shirt do produto, Cor Verde
    • SKU CL-02, Produto Jeans, Cor Azul
    • SKU AC-01, Chapéu Produto, Cor Azul
  • A tabela Categoria de Produto tem duas linhas:
    • SKU CL-01, Categoria Vestuário
    • SKU AC-01, Categoria Acessórios

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

No painel Campos, os autores de relatórios encontrarão campos relacionados ao produto em duas tabelas: Produto e Categoria de Produto.

The Fields pane shows both tables expanded, and the columns are listed as fields with Product and Product category called out.

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 .

A table visual includes four columns: SKU, Product, Color, and Category. The Category value for product SKU CL-02 is BLANK.

Observe que o valor de categoria para o produto SKU CL-02 está em branco. É porque não há nenhuma linha na tabela Categoria de produto 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. É porque este design pode:

  • Contribuir para a desorganização do painel Campos , listando mais tabelas do que o necessário
  • Dificulta a localização de campos relacionados pelos autores de relatórios, pois 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
  • Produzir resultados inesperados quando não há 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 relacionamentos, consulte Modelar relacionamentos no Power BI Desktop (Avaliação de relacionamentos).

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. Isso é feito 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. Configure a transformação de mesclagem para usar uma junção externa esquerda, que é o tipo de associaçã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 Campos .

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

    The Fields pane shows both tables expanded, and the columns are listed as fields with Product called out.

  3. Substituir valores ausentes: se a segunda consulta tiver linhas incomparáveis, NULLs aparecerão nas colunas introduzidas a partir dela. Quando apropriado, considere substituir NULLs 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.

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

    A table visual includes four columns: SKU, Product, Color, and Category. The Category value for product SKU CL-02 is now labeled

  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: Categoria e Produto.

    The Fields pane shows both tables expanded, and the columns are listed as fields with Products called out.

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 Categoria na pasta de exibição Marketing.

The Fields pane shows the Category field within a display folder named 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 entre fontes entre tabelas, não há um design de modelo alternativo, a menos que você pré-consolide os dados em suas fontes 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 serã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.

A table visual includes four columns: SKU, Product, Color, and Category. The table has two rows only.

A tabela exibe apenas duas linhas. Produto SKU CL-02 está faltando porque não há nenhuma linha correspondente na tabela Categoria de produto.

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