Diretrizes de recuperação de dados para relatórios paginados

Este artigo destina-se a você como um autor de relatório projetando relatórios paginados do Power BI. Ele fornece recomendações para ajudá-lo a projetar uma recuperação de dados eficaz e eficiente.

Tipos de fonte de dados

Os relatórios paginados suportam nativamente fontes de dados relacionais e analíticas. Essas fontes são ainda categorizadas, como baseadas na nuvem ou no local. As fontes de dados locais, sejam hospedadas no local ou em uma máquina virtual, exigem um gateway de dados para que o Power BI possa se conectar. Baseado na nuvem significa que o Power BI pode se conectar diretamente usando uma conexão com a Internet.

Se você puder escolher o tipo de fonte de dados (possivelmente o caso em um novo projeto), recomendamos que use fontes de dados baseadas em nuvem. Os relatórios paginados podem se conectar com latência de rede mais baixa, especialmente quando as fontes de dados residem na mesma região que seu locatário do Power BI. Além disso, é possível conectar-se a essas fontes usando o Single Sign-On (SSO). Isso significa que a identidade do usuário do relatório pode fluir para a fonte de dados, permitindo que as permissões de nível de linha por usuário sejam impostas. Atualmente, o SSO só é suportado para fontes de dados locais SQL Server e Oracle (consulte Fontes de dados suportadas para relatórios paginados do Power BI).

Fontes de dados relacionais

Geralmente, as fontes de dados relacionais são adequadas para relatórios de estilo operacional, como faturas de vendas. Eles também são adequados para relatórios que precisam recuperar conjuntos de dados muito grandes (acima de 10.000 linhas). As fontes de dados relacionais também podem definir procedimentos armazenados, que podem ser executados por conjuntos de dados de relatório. Os procedimentos armazenados oferecem vários benefícios:

• Parametrização
• Encapsulamento da lógica de programação, permitindo a preparação de dados mais complexos (por exemplo, tabelas temporárias, cursores ou funções escalares definidas pelo usuário)
• Melhor capacidade de manutenção, permitindo que a lógica do procedimento armazenado seja facilmente atualizada. Em alguns casos, isso pode ser feito sem a necessidade de modificar e republicar relatórios paginados (fornecendo nomes de colunas e tipos de dados permanecem inalterados).
• Melhor desempenho, pois seus planos de execução são armazenados em cache para reutilização
• Reutilização de procedimentos armazenados em vários relatórios

No Construtor de Relatórios do Power BI, você pode usar o designer de consulta relacional para construir graficamente uma instrução de consulta, mas apenas para fontes de dados da Microsoft.

Fontes de dados analíticos

As fontes de dados analíticas — também conhecidas como modelos de dados ou apenas modelos — são adequadas para relatórios operacionais e analíticos e podem fornecer resultados de consulta resumidos rápidos, mesmo em volumes de dados muito grandes. Medidas de modelo e KPIs podem encapsular regras de negócios complexas para obter a sumarização de dados. Essas fontes de dados, no entanto, não são adequadas para relatórios que precisam recuperar volumes muito grandes de dados (mais de 10.000 linhas).

No Construtor de Relatórios do Power BI, você pode escolher entre dois designers de consulta: o designer de consulta DAX do Analysis Services e o designer de consulta MDX do Analysis Services. Esses designers podem ser usados para fontes de dados de modelo semântico do Power BI ou qualquer modelo do SQL Server Analysis Services ou do Azure Analysis Services — tabular ou multidimensional.

Recomendamos que você use o designer de consultas DAX, desde que ele atenda inteiramente às suas necessidades de consulta. Se o modelo não definir as medidas necessárias, você precisará alternar para o modo de consulta. Nesse modo, você pode personalizar a instrução query adicionando expressões (para obter a sumarização).

O designer de consulta MDX requer que seu modelo inclua medidas. O designer tem dois recursos não suportados pelo designer de consulta DAX. Especificamente, permite-lhe:

• Defina membros calculados no nível de consulta (em MDX).
• Configure regiões de dados para solicitar agregações de servidor em grupos não detalhados . Se o relatório precisar apresentar resumos de medidas semi ou não aditivas (como cálculos de inteligência de tempo ou contagens distintas), provavelmente será mais eficiente usar agregações de servidor do que recuperar linhas de detalhes de baixo nível e fazer com que o relatório compute resumos.

Tamanho do resultado da consulta

Em geral, é uma prática recomendada recuperar apenas os dados exigidos pelo relatório. Portanto, não recupere colunas ou linhas que não são exigidas pelo relatório.

Para limitar linhas, você deve sempre aplicar os filtros mais restritivos e definir consultas agregadas. Agregue o grupo de consultas e resuma os dados de origem para recuperar resultados de maior granulação. Por exemplo, considere que seu relatório precisa apresentar um resumo das vendas do vendedor. Em vez de recuperar todas as linhas de ordem de venda, crie uma consulta de conjunto de dados que agrupa por vendedor e resume as vendas de cada grupo.

Campos baseados em expressões

É possível estender um conjunto de dados de relatório com campos baseados em expressões. Por exemplo, se o conjunto de dados originar o nome e o sobrenome do cliente, talvez você queira um campo que concatene os dois campos para produzir o nome completo do cliente. Para conseguir esse cálculo, você tem duas opções. Pode:

• Crie um campo calculado, que é um campo de conjunto de dados com base em uma expressão.
• Injete uma expressão diretamente na consulta do conjunto de dados (usando o idioma nativo da fonte de dados), o que resulta em um campo de conjunto de dados regular.

Recomendamos esta última opção, sempre que possível. Há duas boas razões pelas quais injetar expressões diretamente em sua consulta de conjunto de dados é melhor:

• É possível que sua fonte de dados seja otimizada para avaliar a expressão de forma mais eficiente do que o Power BI (é especialmente o caso de bancos de dados relacionais).
• O desempenho do relatório é melhorado porque não há necessidade de o Power BI materializar campos calculados antes da renderização do relatório. Os campos calculados podem estender visivelmente o tempo de renderização do relatório quando os conjuntos de dados recuperam um grande número de linhas.

Nomes de campo

Quando você cria um conjunto de dados, seus campos são nomeados automaticamente após as colunas de consulta. É possível que esses nomes não sejam amigáveis ou intuitivos. Também é possível que os nomes das colunas de consulta de origem contenham caracteres proibidos nos identificadores de objeto RDL (Report Definition Language) (como espaços e símbolos). Nesse caso, os caracteres proibidos são substituídos por um caractere de sublinhado (_).

Recomendamos que você verifique primeiro se todos os nomes de campo são amigáveis, concisos, mas ainda assim significativos. Caso contrário, sugerimos que você os renomeie antes de iniciar o layout do relatório. Isso ocorre porque os campos renomeados não propagam as alterações nas expressões usadas no layout do relatório. Se você decidir renomear campos depois de iniciar o layout do relatório, precisará localizar e atualizar todas as expressões quebradas.

Filtro vs parâmetro

É provável que seus designs de relatório paginado tenham parâmetros de relatório. Os parâmetros de relatório são normalmente usados para solicitar que o usuário do relatório filtre o relatório. Como autor de relatório paginado, você tem duas maneiras de obter a filtragem de relatório. Você pode mapear um parâmetro de relatório para:

• Um filtro de conjunto de dados, caso em que o(s) valor(es) do(s) parâmetro(s) de relatório são usados para filtrar os dados já recuperados pelo conjunto de dados.
• Um parâmetro de conjunto de dados, caso em que o(s) valor(es) do(s) parâmetro(s) de relatório são injetados na consulta nativa enviada para a fonte de dados.

Considere, então, um exemplo de um relatório de vendas que tenha um único parâmetro de relatório para filtrar o relatório por um único ano. O conjunto de dados recupera as vendas de todos os anos. Ele faz isso porque o parâmetro de relatório mapeia para os filtros do conjunto de dados. O relatório exibe dados para o ano solicitado, que é um subconjunto dos dados do conjunto de dados. Quando o usuário do relatório altera o parâmetro de relatório para um ano diferente e, em seguida, exibe o relatório, o Power BI não precisa recuperar nenhum dado de origem. Em vez disso, ele aplica um filtro diferente ao conjunto de dados já armazenado em cache. Uma vez que o conjunto de dados é armazenado em cache, a filtragem pode ser muito rápida.

Agora, considere um design de relatório diferente. Desta vez, o design do relatório mapeia o parâmetro de relatório do ano de vendas para um parâmetro de conjunto de dados. Dessa forma, o Power BI injeta o valor do ano na consulta nativa e o conjunto de dados recupera dados somente desse ano. Sempre que o usuário do relatório altera o valor do parâmetro do relatório do ano — e, em seguida, exibe o relatório — o conjunto de dados recupera um novo resultado de consulta apenas para esse ano.

Ambas as abordagens de design podem filtrar dados de relatório, e ambos os designs podem funcionar bem para seus designs de relatório. Um design otimizado, no entanto, dependerá dos volumes de dados previstos, da volatilidade dos dados e dos comportamentos previstos dos usuários do relatório.

Recomendamos a filtragem do conjunto de dados quando você prevê que um subconjunto diferente das linhas do conjunto de dados será reutilizado muitas vezes (economizando tempo de renderização porque novos dados não precisam ser recuperados). Nesse cenário, você reconhece que o custo de recuperar um conjunto de dados maior pode ser trocado pelo número de vezes que ele será reutilizado. Portanto, é útil para consultas que são demoradas para gerar. Mas tenha cuidado: o armazenamento em cache de grandes conjuntos de dados por usuário pode afetar negativamente o desempenho e a taxa de transferência de capacidade.

Recomendamos a parametrização do conjunto de dados quando você antecipa que é improvável que um subconjunto diferente de linhas do conjunto de dados seja solicitado — ou, quando o número de linhas do conjunto de dados a serem filtradas provavelmente será muito grande (e ineficiente para armazenar em cache). Essa abordagem de design também funciona bem quando seu armazenamento de dados é volátil. Nesse caso, cada alteração no valor do parâmetro de relatório resultará na recuperação de dados atualizados.

Fontes de dados não nativas

Se você precisar desenvolver relatórios paginados com base em fontes de dados que não são suportadas nativamente por relatórios paginados, você deve primeiro desenvolver um modelo de dados no Power BI Desktop. Dessa forma, você pode se conectar a centenas de fontes de dados suportadas pelo Power BI. Depois de publicado no serviço do Power BI, você pode desenvolver um relatório paginado que se conecta ao modelo semântico do Power BI.

Integração de dados

Se você precisar combinar dados de várias fontes de dados, terá duas opções:

• Combinar conjuntos de dados de relatório: se as fontes de dados forem suportadas nativamente por relatórios paginados, você poderá considerar a criação de campos calculados que usem as funções Lookup ou LookupSet Report Builder.
• Desenvolver um modelo do Power BI Desktop: é provavelmente mais eficiente, no entanto, que você desenvolva um modelo de dados no Power BI Desktop. Pode utilizar o Power Query para combinar consultas com base em qualquer origem de dados suportada. Depois de publicado no serviço do Power BI, você pode desenvolver um relatório paginado que se conecta ao modelo semântico do Power BI.

Latência de rede

A latência da rede pode afetar o desempenho do relatório, aumentando o tempo necessário para que as solicitações cheguem ao serviço do Power BI e para que as respostas sejam entregues. Os locatários no Power BI são atribuídos a uma região específica.

Quando os usuários de um locatário acessam o serviço do Power BI, suas solicitações sempre são encaminhadas para essa região. À medida que as solicitações chegam ao serviço do Power BI, o serviço pode enviar solicitações adicionais — por exemplo, para a fonte de dados subjacente ou um gateway de dados — que também estão sujeitas à latência da rede. Em geral, para minimizar o impacto da latência da rede, esforce-se para manter as fontes de dados, gateways e sua capacidade do Power BI o mais próximo possível. Preferencialmente, residem na mesma região. Se a latência da rede for um problema, tente localizar gateways e fontes de dados mais próximos da sua capacidade do Power BI colocando-os dentro de máquinas virtuais hospedadas na nuvem.

Tipos de dados complexos do SQL Server

Como o SQL Server é uma fonte de dados local, o Power BI deve se conectar por meio de um gateway. O gateway, no entanto, não suporta a recuperação de dados para tipos de dados complexos. Os tipos de dados complexos incluem tipos internos, como os tipos de dados espaciais GEOMETRY e GEOGRAPHY e hierarchyid. Eles também podem incluir tipos definidos pelo usuário implementados por meio de uma classe de um assembly no CLR (Common Language Runtime) do Microsoft.NET Framework.

A plotagem de dados espaciais e análises na visualização de mapa requer dados espaciais do SQL Server. Portanto, não é possível trabalhar com a visualização de mapa quando o SQL Server é sua fonte de dados. Para ser claro, ele funcionará se sua fonte de dados for o Banco de Dados SQL do Azure porque o Power BI não se conecta por meio de um gateway.

Imagens relacionadas a dados

As imagens podem ser usadas para adicionar logotipos ou imagens ao layout do relatório. Quando as imagens se relacionam com as linhas recuperadas por um conjunto de dados de relatório, você tem duas opções:

• É possível que os dados de imagem também possam ser recuperados da sua fonte de dados (se já estiverem armazenados em uma tabela).
• Quando as imagens são armazenadas em um servidor Web, você pode usar uma expressão dinâmica para criar o caminho de URL da imagem.

Para obter mais informações e sugestões, consulte Diretrizes de imagem para relatórios paginados.

Recuperação de dados redundantes

É possível que seu relatório recupere dados redundantes. Isso pode acontecer quando você exclui campos de consulta de conjunto de dados ou o relatório tem conjuntos de dados não utilizados. Evite essas situações, pois elas resultam em uma sobrecarga desnecessária sobre suas fontes de dados, a rede e os recursos de capacidade do Power BI.

Campos de consulta excluídos

Na página Campos da janela Propriedades do Conjunto de Dados, é possível excluir campos de consulta de conjunto de dados (campos de consulta mapeados para colunas recuperadas pela consulta do conjunto de dados). No entanto, o Construtor de Relatórios não remove as colunas correspondentes da consulta do conjunto de dados.

Se você precisar excluir campos de consulta do conjunto de dados, recomendamos remover as colunas correspondentes da consulta do conjunto de dados. O Construtor de Relatórios removerá automaticamente todos os campos de consulta redundantes. Se acontecer de você excluir campos de consulta, certifique-se de também modificar a instrução de consulta do conjunto de dados para remover as colunas.

Conjuntos de dados não utilizados

Quando um relatório é executado, todos os conjuntos de dados são avaliados, mesmo que não estejam vinculados a objetos de relatório. Por esse motivo, certifique-se de remover todos os conjuntos de dados de teste ou desenvolvimento antes de publicar um relatório.

Conteúdos relacionados

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

• Fontes de dados suportadas para relatórios paginados do Power BI
• Perguntas? Tente perguntar à Comunidade do Power BI
• Sugestões? Contribua com ideias para melhorar o Power BI