Separar relatórios de modelos no Power BI Desktop

Ao criar uma solução do Power BI Desktop, uma das primeiras tarefas que você precisa fazer é obter dados. A obtenção de dados pode resultar em dois resultados distintos. Ela poderia:

  • Criar uma conexão dinâmica a um modelo já publicado, que poderia ser um modelo semântico do Power BI (anteriormente conhecido como conjunto de dados) ou um modelo do Analysis Services hospedado remotamente.
  • Iniciar o desenvolvimento de um novo modelo, que pode ser um modelo de importação, DirectQuery ou composto.

Este artigo se preocupa com o segundo cenário. Ele fornece orientação sobre se um relatório e um modelo devem ou não ser combinados em um único arquivo do Power BI Desktop.

Solução de arquivo único

Uma solução de arquivo único funciona bem quando há apenas um relatório com base no modelo. Nesse caso, é provável que o modelo e o relatório sejam esforços da mesma pessoa. Definimos isso como uma solução de BI pessoal, embora o relatório possa ser compartilhado com outras pessoas. Essas soluções podem representar relatórios com escopo de função ou avaliações de um desafio comercial a serem realizadas uma única vez, geralmente descritas como relatórios ad hoc.

A single file contains a model and report, developed by the same person.

Separar arquivos de relatório

Faz sentido colocar o desenvolvimento de modelos e o de relatórios em arquivos separados do Power BI Desktop quando:

  • Os modeladores de dados e os autores de relatórios são pessoas diferentes.
  • Entende-se que um modelo será a fonte de vários relatórios, agora ou no futuro.

There are three PBIX files. The first contains only a model. The other two contain only reports, and they live connect to the model hosted in the Power BI service. The reports are developed by different people.

Os modeladores de dados ainda podem usar a experiência de criação de relatório do Power BI Desktop para testar e validar seus próprios designs de modelo. No entanto, logo após publicarem o arquivo no serviço do Power BI, eles deverão remover o relatório do workspace. E eles precisam se lembrar de remover o relatório cada vez que republicarem e substituírem o modelo semântico.

Preservar a interface do modelo

Às vezes, as alterações de modelo são inevitáveis. Os modeladores de dados precisam tomar cuidado então para não causarem falhas na interface do modelo. Se o fizerem, visuais de relatório ou blocos de dashboard relacionados poderão apresentar falhas. Os visuais com falhas aparecem como erros e podem resultar em frustração para os criadores e consumidores de relatórios. E pior: eles podem reduzir a confiança nos dados.

Portanto, gerencie as alterações aos modelos com cuidado. Se possível, evite as seguintes alterações:

  • Renomeação de tabelas, colunas, hierarquias, níveis de hierarquia ou medidas.
  • Modificação de tipos de dados de coluna.
  • Modificação de expressões de medida para que elas retornem um tipo de dados diferente.
  • Mudança de medidas para uma tabela base diferente. Isso ocorre porque mover uma medida pode causar falha em medidas no escopo do relatório que qualificam totalmente as medidas com o respectivo nome de tabela inicial. Não recomendamos que você escreva expressões DAX usando nomes de medidas totalmente qualificados. Para obter mais informações, confira DAX: referências de coluna e de medida.

A adição de novas tabelas, colunas, hierarquias, níveis de hierarquia ou medidas é segura, com uma exceção: é possível que um novo nome de medida possa entrar em conflito com um nome de medida no escopo do relatório. Para evitar o conflito, recomendamos que os autores de relatórios adotem uma convenção de nomenclatura ao definir medidas em seus relatórios. Eles podem prefixar nomes de medidas no escopo do relatório com um sublinhado ou outro caractere.

Se você precisar fazer alterações da falha em seus modelos, recomendamos:

As duas opções permitem que você identifique rapidamente os relatórios e dashboards relacionados. A exibição de linhagem de dados é provavelmente a melhor opção, porque é fácil ver a pessoa de contato para cada item relacionado. Na verdade, trata-se de um hiperlink que abre uma mensagem de email endereçada ao contato.

Recomendamos que você entre em contato com o proprietário de cada item relacionado para informá-los sobre eventuais alterações interruptivas planejadas. Desse modo, eles podem estar preparados e prontos para corrigir e republicar os próprios relatórios, ajudando a minimizar o tempo de inatividade e a frustração.

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