Compreender o esquema em estrela e a importância para o Power BI

Este artigo destina-se aos modeladores de dados do Power BI Desktop. Ele descreve o design do esquema em estrela e sua relevância para o desenvolvimento de modelos de dados do Power BI otimizados para desempenho e usabilidade.

Este artigo não se destina a fornecer uma discussão completa sobre o design do esquema em estrela. Para obter mais detalhes, consulte diretamente o conteúdo publicado, como The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling (3ª edição, 2013) de Ralph Kimball e outros.

Visão geral do esquema em estrela

O esquema Star é uma abordagem de modelagem madura amplamente adotada por data warehouses relacionais. Ele requer que os modeladores classifiquem suas tabelas de modelo como dimensão ou fato.

As tabelas de dimensão descrevem entidades comerciais — as coisas que você modela. As entidades podem incluir produtos, pessoas, lugares e conceitos, incluindo o próprio tempo. A tabela mais consistente que você encontrará em um esquema em estrela é uma tabela de dimensão de data. Uma tabela de dimensões contém uma coluna de chave (ou colunas) que atua como um identificador exclusivo e colunas descritivas.

As tabelas de fatos armazenam observações ou eventos, e podem ser ordens de venda, saldos de estoque, taxas de câmbio, temperaturas, etc. Uma tabela de fatos contém colunas de chave de dimensão relacionadas a tabelas de dimensão e colunas de medida numérica. As colunas de chave de dimensão determinam a dimensionalidade de uma tabela de fatos, enquanto os valores de chave de dimensão determinam a granularidade de uma tabela de fatos. Por exemplo, considere uma tabela de fatos projetada para armazenar destinos de venda que tenha duas colunas de chave de dimensão Data e ProductKey. É fácil entender que a tabela tem duas dimensões. A granularidade, no entanto, não pode ser determinada sem considerar os valores-chave da dimensão. Neste exemplo, considere que os valores armazenados na coluna Data são o primeiro dia de cada mês. Neste caso, a granularidade está no nível do produto do mês.

Geralmente, as tabelas de dimensão contêm um número relativamente pequeno de linhas. As tabelas de factos, por outro lado, podem conter um número muito grande de linhas e continuar a crescer ao longo do tempo.

Normalização vs. desnormalização

Para entender alguns conceitos de esquema estelar descritos neste artigo, é importante conhecer dois termos: normalização e desnormalização.

Normalização é o termo usado para descrever dados armazenados de forma a reduzir dados repetitivos. Considere uma tabela de produtos que tenha uma coluna de valor de chave exclusiva, como a chave do produto, e colunas adicionais descrevendo as características do produto, incluindo nome, categoria, cor e tamanho do produto. Uma tabela de vendas é considerada normalizada quando armazena apenas chaves, como a chave do produto. Na imagem a seguir, observe que somente a coluna ProductKey registra o produto.

Se, no entanto, a tabela de vendas armazenar detalhes do produto além da chave, ela é considerada desnormalizada. Na imagem a seguir, observe que a ProductKey e outras colunas relacionadas ao produto registram o produto.

Quando você obtém dados de um arquivo de exportação ou extração de dados, é provável que eles representem um conjunto desnormalizado de dados. Neste caso, utilize o Power Query para transformar e moldar os dados de origem em várias tabelas normalizadas.

Conforme descrito neste artigo, você deve se esforçar para desenvolver modelos de dados otimizados do Power BI com tabelas que representam dados de fato e dimensão normalizados. No entanto, há uma exceção em que uma dimensão de floco de neve deve ser desnormalizada para produzir uma única tabela modelo.

Relevância do esquema em estrela para modelos do Power BI

O design de esquema em estrela e muitos conceitos relacionados introduzidos neste artigo são altamente relevantes para o desenvolvimento de modelos do Power BI otimizados para desempenho e usabilidade.

Considere que cada visual de relatório do Power BI gera uma consulta que é enviada para o modelo do Power BI (que o serviço do Power BI chama de modelo semântico, anteriormente conhecido como conjunto de dados). Essas consultas são usadas para filtrar, agrupar e resumir dados do modelo. Um modelo bem projetado, então, é aquele que fornece tabelas para filtragem e agrupamento, e tabelas para resumir. Este design se encaixa bem com os princípios do esquema em estrela:

• As tabelas de dimensão suportam filtragem e agrupamento
• As tabelas de fatos suportam a sumarização

Não há nenhuma propriedade de tabela que os modeladores definam para configurar o tipo de tabela como dimensão ou fato. Na verdade, é determinado pelas relações do modelo. Uma relação de modelo estabelece um caminho de propagação de filtro entre duas tabelas, e é a propriedade Cardinality da relação que determina o tipo de tabela. Uma cardinalidade de relacionamento comum é um-para-muitos ou seu inverso muitos-para-um. O lado "um" é sempre uma tabela do tipo dimensão, enquanto o lado "muitos" é sempre uma tabela do tipo fato. Para obter mais informações sobre relações, consulte Modelar relações no Power BI Desktop.

Um design de modelo bem estruturado deve incluir tabelas que são tabelas de tipo de dimensão ou tabelas de tipo de fato. Evite misturar os dois tipos para uma única mesa. Também recomendamos que você se esforce para oferecer o número certo de mesas com os relacionamentos certos. Também é importante que as tabelas de tipo de fatos sempre carreguem dados em um grão consistente.

Por fim, é importante entender que o design ideal de modelos é parte ciência e parte arte. Às vezes, você pode romper com uma boa orientação quando faz sentido fazê-lo.

Há muitos conceitos adicionais relacionados ao design de esquema em estrela que podem ser aplicados a um modelo do Power BI. Estes conceitos incluem:

• Medidas
• Chaves substitutas
• Dimensões dos flocos de neve
• Dimensões de interpretação de papéis
• Dimensões em mudança lenta
• Dimensões do lixo
• Dimensões degeneradas
• Tabelas de factos sem factos

Medições

No design de esquema em estrela, uma medida é uma coluna de tabela de fatos que armazena valores a serem resumidos.

Em um modelo do Power BI, uma medida tem uma definição diferente, mas semelhante. É uma fórmula escrita em Data Analysis Expressions (DAX) que alcança a sumarização. As expressões de medida geralmente aproveitam funções de agregação DAX como SUM, MIN, MAX, AVERAGE, etc. para produzir um resultado de valor escalar no momento da consulta (os valores nunca são armazenados no modelo). A expressão de medida pode variar de simples agregações de coluna a fórmulas mais sofisticadas que substituem o contexto do filtro e/ou a propagação da relação. Para obter mais informações, leia o artigo Noções básicas do DAX no Power BI Desktop .

É importante entender que os modelos do Power BI oferecem suporte a um segundo método para obter a sumarização. Qualquer coluna — e normalmente colunas numéricas — pode ser resumida por um relatório, visual ou P&R. Estas colunas são referidas como medidas implícitas. Eles oferecem uma conveniência para você como desenvolvedor de modelos, pois em muitos casos você não precisa criar medidas. Por exemplo, a coluna Valor de vendas do revendedor Adventure Works pode ser resumida de várias maneiras (soma, contagem, média, mediana, min, max, etc.), sem a necessidade de criar uma medida para cada tipo de agregação possível.

No entanto, há três razões convincentes para você criar medidas, mesmo para resumos simples em nível de coluna:

• Quando você souber que os autores do relatório consultarão o modelo usando MDX (Multidimensional Expressions), o modelo deverá incluir medidas explícitas. Medidas explícitas são definidas usando DAX. Essa abordagem de design é altamente relevante quando um conjunto de dados do Power BI é consultado usando MDX, porque o MDX não pode obter a sumarização de valores de coluna. Notavelmente, o MDX será usado ao executar Analisar no Excel, porque as Tabelas Dinâmicas emitem consultas MDX.
• Quando você souber que os autores do relatório criarão relatórios paginados do Power BI usando o designer de consulta MDX, o modelo deverá incluir medidas explícitas. Somente o designer de consulta MDX oferece suporte a agregações de servidor. Portanto, se os autores de relatório precisarem ter medidas avaliadas pelo Power BI (em vez de pelo mecanismo de relatório paginado), eles deverão usar o designer de consulta MDX.
• Quando você precisa garantir que os autores do relatório só possam resumir colunas de maneiras específicas. Por exemplo, a coluna Preço Unitário de vendas do revendedor (que representa uma taxa por unidade) pode ser resumida, mas apenas usando funções de agregação específicas. Nunca deve ser somado, mas é apropriado resumir usando outras funções de agregação como min, max, average, etc. Nesse caso, o modelador pode ocultar a coluna Preço Unitário e criar medidas para todas as funções de agregação apropriadas.

Essa abordagem de design funciona bem para relatórios criados no serviço Power BI e para P&R. No entanto, as conexões ao vivo do Power BI Desktop permitem que os autores de relatórios mostrem campos ocultos no painel Campos, o que pode resultar em contornar essa abordagem de design.

Chaves substitutas

Uma chave substituta é um identificador exclusivo que você adiciona a uma tabela para dar suporte à modelagem de esquema em estrela. Por definição, ele não é definido ou armazenado nos dados de origem. Geralmente, as chaves substitutas são adicionadas às tabelas de dimensões do data warehouse relacional para fornecer um identificador exclusivo para cada linha da tabela de dimensão.

As relações de modelo do Power BI são baseadas em uma única coluna exclusiva em uma tabela, que propaga filtros para uma única coluna em uma tabela diferente. Quando uma tabela de tipo de dimensão em seu modelo não inclui uma única coluna exclusiva, você deve adicionar um identificador exclusivo para se tornar o lado "um" de uma relação. No Power BI Desktop, você pode atingir facilmente esse requisito criando uma coluna de índice do Power Query.

Você deve mesclar essa consulta com a consulta do lado "muitos" para que você possa adicionar a coluna de índice a ela também. Ao carregar essas consultas no modelo, você pode criar uma relação um-para-muitos entre as tabelas do modelo.

Dimensões dos flocos de neve

Uma dimensão de floco de neve é um conjunto de tabelas normalizadas para uma única entidade comercial. Por exemplo, a Adventure Works classifica os produtos por categoria e subcategoria. Os produtos são atribuídos a subcategorias e, por sua vez, as subcategorias são atribuídas a categorias. No data warehouse relacional da Adventure Works, a dimensão do produto é normalizada e armazenada em três tabelas relacionadas: DimProductCategory, DimProductSubcategory e DimProduct.

Se você usar sua imaginação, você pode imaginar as mesas normalizadas posicionadas para fora da tabela de fatos, formando um design de floco de neve.

No Power BI Desktop, você pode optar por imitar um design de dimensão de floco de neve (talvez porque seus dados de origem o façam) ou integrar (desnormalizar) as tabelas de origem em uma única tabela de modelo. Geralmente, os benefícios de uma única tabela de modelo superam os benefícios de várias tabelas de modelo. A decisão mais ideal pode depender dos volumes de dados e dos requisitos de usabilidade para o modelo.

Quando você escolhe imitar um design de dimensão de floco de neve:

• O Power BI carrega mais tabelas, o que é menos eficiente do ponto de vista do armazenamento e do desempenho. Essas tabelas devem incluir colunas para dar suporte a relações de modelo e isso pode resultar em um tamanho de modelo maior.
• Cadeias de propagação de filtros de relacionamento mais longas precisarão ser percorridas, o que provavelmente será menos eficiente do que os filtros aplicados a uma única tabela.
• O painel Campos apresenta mais tabelas de modelo para os autores de relatórios, o que pode resultar em uma experiência menos intuitiva, especialmente quando as tabelas de dimensão de flocos de neve contêm apenas uma ou duas colunas.
• Não é possível criar uma hierarquia que abranja as tabelas.

Ao optar por integrar em uma única tabela modelo, você também pode definir uma hierarquia que engloba o grão mais alto e o menor grão da dimensão. Possivelmente, o armazenamento de dados desnormalizados redundantes pode resultar no aumento do tamanho do armazenamento do modelo, particularmente para tabelas de dimensões muito grandes.

Dimensões em mudança lenta

Uma dimensão de mudança lenta (SCD) é aquela que gerencia adequadamente a mudança de membros da dimensão ao longo do tempo. Aplica-se quando os valores das entidades empresariais mudam ao longo do tempo e de uma forma ad hoc. Um bom exemplo de uma dimensão em mudança lenta é a dimensão do cliente, especificamente suas colunas de detalhes de contato, como endereço de e-mail e número de telefone. Em contraste, algumas dimensões são consideradas como mudando rapidamente quando um atributo de dimensão muda frequentemente, como o preço de mercado de uma ação. A abordagem de design comum nesses casos é armazenar valores de atributos que mudam rapidamente em uma medida de tabela de fatos.

A teoria do projeto de esquema em estrela refere-se a dois tipos comuns de SCD: Tipo 1 e Tipo 2. Uma tabela de tipo de dimensão pode ser Tipo 1 ou Tipo 2, ou suportar ambos os tipos simultaneamente para colunas diferentes.

SCD tipo 1

Um SCD Tipo 1sempre reflete os valores mais recentes e, quando alterações nos dados de origem são detetadas, os dados da tabela de dimensões são substituídos. Essa abordagem de design é comum para colunas que armazenam valores suplementares, como o endereço de e-mail ou o número de telefone de um cliente. Quando um endereço de e-mail ou número de telefone do cliente é alterado, a tabela de dimensões atualiza a linha do cliente com os novos valores. É como se o cliente sempre tivesse essa informação de contato.

Uma atualização não incremental de uma tabela de tipo de dimensão de modelo do Power BI alcança o resultado de um SCD Tipo 1. Ele atualiza os dados da tabela para garantir que os valores mais recentes sejam carregados.

SCD tipo 2

Um SCD Tipo 2suporta versionamento de membros de dimensão. Se o sistema de origem não armazenar versões, geralmente é o processo de carga do data warehouse que deteta as alterações e gerencia adequadamente as alterações em uma tabela de dimensões. Nesse caso, a tabela de dimensões deve usar uma chave substituta para fornecer uma referência exclusiva a uma versão do membro da dimensão. Ele também inclui colunas que definem a validade do intervalo de datas da versão (por exemplo, StartDate e EndDate) e possivelmente uma coluna de sinalizador (por exemplo, IsCurrent) para filtrar facilmente por membros da dimensão atual.

Por exemplo, a Adventure Works atribui vendedores a uma região de vendas. Quando um vendedor realoca uma região, uma nova versão do vendedor deve ser criada para garantir que os fatos históricos permaneçam associados à região anterior. Para dar suporte a uma análise histórica precisa das vendas por vendedor, a tabela de dimensões deve armazenar versões dos vendedores e sua(s) região(ões) associada(s). A tabela também deve incluir valores de data de início e término para definir a validade de tempo. As versões atuais podem definir uma data de término vazia (ou 31/12/9999), o que indica que a linha é a versão atual. A tabela também deve definir uma chave substituta porque a chave comercial (neste caso, ID do funcionário) não será exclusiva.

É importante entender que, quando os dados de origem não armazenam versões, você deve usar um sistema intermediário (como um data warehouse) para detetar e armazenar alterações. O processo de carregamento de tabela deve preservar os dados existentes e detetar alterações. Quando uma alteração é detetada, o processo de carregamento da tabela deve expirar a versão atual. Ele registra essas alterações atualizando o valor EndDate e inserindo uma nova versão com o valor StartDate começando a partir do valor EndDate anterior. Além disso, os fatos relacionados devem usar uma pesquisa baseada no tempo para recuperar o valor da chave da dimensão relevante para a data do fato. Um modelo do Power BI usando o Power Query não pode produzir esse resultado. No entanto, ele pode carregar dados de uma tabela de dimensões SCD Tipo 2 pré-carregada.

O modelo do Power BI deve dar suporte à consulta de dados históricos para um membro, independentemente da alteração, e para uma versão do membro, que representa um estado específico do membro no tempo. No contexto da Adventure Works, esse design permite que você consulte o vendedor independentemente da região de vendas atribuída ou de uma versão específica do vendedor.

Para atingir esse requisito, a tabela de tipo de dimensão do modelo do Power BI deve incluir uma coluna para filtrar o vendedor e uma coluna diferente para filtrar uma versão específica do vendedor. É importante que a coluna da versão forneça uma descrição não ambígua, como "Michael Blythe (15/12/2008-26/06/2019)" ou "Michael Blythe (atual)". Também é importante educar os autores e consumidores de relatórios sobre os conceitos básicos do SCD Tipo 2 e como obter designs de relatório apropriados aplicando filtros corretos.

Também é uma boa prática de design incluir uma hierarquia que permita que os visuais sejam detalhados até o nível da versão.

Dimensões de desempenho de funções

Uma dimensão de interpretação de papéis é uma dimensão que pode filtrar fatos relacionados de forma diferente. Por exemplo, na Adventure Works, a tabela de dimensões de data tem três relações com os fatos de vendas do revendedor. A mesma tabela de dimensões pode ser usada para filtrar os fatos por data do pedido, data de envio ou data de entrega.

Em um data warehouse, a abordagem de design aceita é definir uma única tabela de dimensão de data. No momento da consulta, a "função" da dimensão de data é estabelecida pela coluna de fato que você usa para unir as tabelas. Por exemplo, quando você analisa as vendas por data do pedido, a junção da tabela está relacionada à coluna de data da ordem de venda do revendedor.

Em um modelo do Power BI, esse design pode ser imitado criando várias relações entre duas tabelas. No exemplo da Adventure Works, as tabelas de vendas de data e revendedor teriam três relações. Embora esse design seja possível, é importante entender que só pode haver uma relação ativa entre duas tabelas de modelo do Power BI. Todas as relações restantes devem ser definidas como inativas. Ter um único relacionamento ativo significa que há uma propagação de filtro padrão da data para as vendas do revendedor. Nesse caso, o relacionamento ativo é definido como o filtro mais comum usado pelos relatórios, que na Adventure Works é o relacionamento de data do pedido.

A única maneira de usar uma relação inativa é definir uma expressão DAX que usa a função USERELATIONSHIP. Em nosso exemplo, o desenvolvedor do modelo deve criar medidas para permitir a análise das vendas do revendedor por data de envio e data de entrega. Este trabalho pode ser tedioso, especialmente quando a tabela do revendedor define muitas medidas. Também cria uma confusão no painel Campos , com uma superabundância de medidas. Existem também outras limitações:

• Quando os autores de relatórios confiam em resumir colunas, em vez de definir medidas, eles não podem obter a sumarização para as relações inativas sem escrever uma medida no nível de relatório. As medidas no nível de relatório só podem ser definidas ao criar relatórios no Power BI Desktop.
• Com apenas um caminho de relacionamento ativo entre data e vendas de revendedores, não é possível filtrar simultaneamente as vendas de revendedores por diferentes tipos de datas. Por exemplo, não é possível produzir um visual que plote as vendas da data do pedido pelas vendas enviadas.

Para superar essas limitações, uma técnica comum de modelagem do Power BI é criar uma tabela de tipo de dimensão para cada instância de interpretação de função. Normalmente, você cria as tabelas de dimensão adicionais como tabelas calculadas, usando DAX. Usando tabelas calculadas, o modelo pode conter uma tabela Data , uma tabela Data de Envio e uma tabela Data de Entrega , cada uma com uma relação única e ativa com suas respetivas colunas da tabela de vendas do revendedor.

Essa abordagem de design não exige que você defina várias medidas para diferentes funções de data e permite a filtragem simultânea por diferentes funções de data. Um preço menor a pagar, no entanto, com essa abordagem de design é que haverá duplicação da tabela de dimensões de data, resultando em um aumento do tamanho de armazenamento do modelo. Como as tabelas de tipo de dimensão normalmente armazenam menos linhas em relação às tabelas de tipo de fato, isso raramente é uma preocupação.

Observe as seguintes boas práticas de design ao criar tabelas de tipo de dimensão de modelo para cada função:

• Certifique-se de que os nomes das colunas são autodescritos. Embora seja possível ter uma coluna Ano em todas as tabelas de datas (os nomes das colunas são exclusivos dentro da tabela), ela não é autodescritiva por títulos visuais padrão. Considere renomear colunas em cada tabela de função de dimensão, para que a tabela Data de Envio tenha uma coluna de ano chamada Ano de Envio, etc.
• Quando relevante, certifique-se de que as descrições das tabelas forneçam feedback aos autores de relatórios (por meio de dicas de ferramentas do painel Campos ) sobre como a propagação do filtro é configurada. Essa clareza é importante quando o modelo contém uma tabela com nome genérico, como Data, que é usada para filtrar muitas tabelas de tipo de fato. Caso esta tabela tenha, por exemplo, uma relação ativa com a coluna de data da ordem de venda do revendedor, considere fornecer uma descrição da tabela como "Filtra as vendas do revendedor por data do pedido".

Para obter mais informações, consulte Orientação de relacionamento ativo versus inativo.

Dimensões do lixo

Uma dimensão lixo é útil quando há muitas dimensões, especialmente consistindo em poucos atributos (talvez um), e quando esses atributos têm poucos valores. Os bons candidatos incluem colunas de status do pedido ou colunas demográficas do cliente (sexo, faixa etária, etc.).

O objetivo de design de uma dimensão de lixo eletrônico é consolidar muitas dimensões "pequenas" em uma única dimensão para reduzir o tamanho do armazenamento do modelo e também reduzir a desordem do painel Campos , apresentando menos tabelas de modelo.

Uma tabela de dimensão de lixo é tipicamente o produto cartesiano de todos os membros do atributo de dimensão, com uma coluna de chave substituta. A chave substituta fornece uma referência exclusiva para cada linha da tabela. Pode criar a dimensão num armazém de dados ou utilizando o Power Query para criar uma consulta que efetua junções de consulta externas completas e, em seguida, adiciona uma chave substituta (coluna de índice).

Carregue esta consulta para o modelo como uma tabela de tipo de dimensão. Você também precisa mesclar essa consulta com a consulta de fatos, para que a coluna de índice seja carregada no modelo para dar suporte à criação de uma relação de modelo "um-para-muitos".

Dimensões degeneradas

Uma dimensão degenerada refere-se a um atributo da tabela de fatos que é necessário para filtragem. Na Adventure Works, o número da ordem de venda do revendedor é um bom exemplo. Nesse caso, não faz sentido criar uma tabela independente composta apenas por esta coluna, porque isso aumentaria o tamanho de armazenamento do modelo e resultaria em confusão no painel Campos .

No modelo do Power BI, pode ser apropriado adicionar a coluna número da ordem de venda à tabela de tipo de fato para permitir a filtragem ou o agrupamento por número da ordem de venda. É uma exceção à regra introduzida anteriormente que você não deve misturar tipos de tabela (geralmente, as tabelas modelo devem ser do tipo de dimensão ou do tipo de fato).

No entanto, se a tabela de vendas de revendedores da Adventure Works tiver colunas de número de pedido e número de linha de pedido, e elas forem necessárias para filtragem, uma tabela de dimensão degenerada seria um bom design. Para obter mais informações, consulte Orientação de relacionamento um-para-um (Dimensões degeneradas).

Tabelas de factos sem factos

Uma tabela de fatos sem fatos não inclui colunas de medidas. Ele contém apenas chaves de dimensão.

Uma tabela de fatos sem fatos poderia armazenar observações definidas por chaves de dimensão. Por exemplo, em uma data e hora específicas, um cliente específico fez login em seu site. Você pode definir uma medida para contar as linhas da tabela de fatos sem fatos para executar a análise de quando e quantos clientes fizeram login.

Um uso mais atraente de uma tabela de fatos sem fatos é armazenar relações entre dimensões, e é a abordagem de design de modelo do Power BI que recomendamos definir relações de muitas para muitas dimensões. Em um design de relacionamento de muitas dimensões para muitas, a tabela de fatos sem fatos é referida como uma tabela de ponte.

Por exemplo, considere que os vendedores podem ser atribuídos a uma ou mais regiões de vendas. A tabela de transição seria projetada como uma tabela de fatos sem fatos composta por duas colunas: chave do vendedor e chave da região. Valores duplicados podem ser armazenados em ambas as colunas.

Esta abordagem de design muitos-para-muitos está bem documentada e pode ser alcançada sem uma mesa de transição. No entanto, a abordagem da tabela de transição é considerada a melhor prática quando se relacionam duas dimensões. Para obter mais informações, consulte Orientação de relacionamento muitos-para-muitos (Relacionar tabelas de tipo bidimensional).

Conteúdos relacionados

Para obter mais informações sobre design de esquema em estrela ou design de modelo do Power BI, consulte os seguintes artigos:

• Modelagem dimensional Artigo da Wikipédia
• Criar e gerir relações no Power BI Desktop
• Orientação de relacionamento um-para-um
• Orientação de relacionamento muitos-para-muitos
• Orientação de relacionamento bidirecional
• Orientação de relacionamento ativo vs inativo
• Perguntas? Tente perguntar à Comunidade do Power BI
• Sugestões? Contribua com ideias para melhorar o Power BI