É provável que a sua empresa utilize um sistema Enterprise Resource Planning (ERP), um software de contabilidade ou um sistema Customer Relationship Management (CRM) para armazenar e gerir informação importante sobre o negócio, os clientes e as suas finanças. Estes sistemas apoiam-se em bases de dados instaladas num servidor na sua empresa ou na “cloud”. Independentemente do sistema, o Power BI pode importar a informação armazenada em diversos tipos de bases de dados, limpá-la, transformá-la e dar-lhe vida com relatórios e dashboards.

Neste artigo, vamos regressar à loja de desporto e importar a base de dados Access que está contida no ficheiro “1_LojasDesporto”.

O processo de importação começa no botão “Obter Dados”. De seguida, clique em “Base de Dados” e escolha “Base de Dados do Access”:

Escolha o caminho até ao ficheiro com a base de dados e clique em “Abrir”. É provável que a seguinte mensagem surja no seu monitor:

Este erro ocorre quando não tem o motor de ligação à base de dados instalado no seu computador ou quando, apesar de instalado, não corresponde à versão (32 ou 64 bits) do Power BI Desktop.

Para instalar o motor de ligação à base de dados, siga este link: https://www.microsoft.com/en- us/download/details.aspx?id=13255

Para verificar a versão do Power BI Desktop, aceda a “Ficheiro”, “Opções” e “Diagnóstico”. Se pretende alterar a versão do Power BI Desktop, terá de o desinstalar e instalar novamente com a versão pretendida.

Ultrapassado o problema, deverá poder ver a pré-visualização das tabelas da base de dados, tal como representada na seguinte figura:

Esta base de dados é composta por oito tabelas, das quais todas terão de ser importadas exceto a tabela “FactosNovasLojas”. Clique em “Editar” e abra o Editor de Consultas para navegar pelos dados que está prestes a importar tentando familiarizar-se com a sua estrutura.

Repare que os seus dados têm uma tabela designada por “Factos” com 1.068.327 linhas. Nesta tabela estão registadas todas as transações de venda da loja. Abrindo a tabela verá uma extensa listagem com a data de cada uma seguida de uma série de códigos e valores de faturação e margens.

As restantes tabelas são bastante mais pequenas e traduzem os códigos da tabela “Factos” em designações que conseguimos compreender. Por exemplo, a tabela “Gestor” contém os seguintes dados:

A primeira coluna da tabela “ID” é uma chave primária. Esta coluna acrescenta automaticamente uma unidade ao valor mais elevado que contiver, começando no 1 até ao n. A chave primária é única, por isso não podemos ter dois gestores com o mesmo número nem o mesmo gestor deverá estar repetido com números diferentes na tabela. Esta característica torna-a perfeita para estabelecer relações.
Analisando as relações desta base de dados facilmente nos apercebemos que segue uma estrutura em estrela, isto é, no meio existe uma tabela de factos e à sua volta um conjunto de tabelas dimensionais (ou de referência) que lhe servem de apoio. Na tabela de factos, não podemos saber qual é a loja 6 mas estabelecendo a relação do campo “ID” da tabela “Loja” com o campo “Loja” da tabela de factos, verificamos que essa é a loja do Funchal.

Organizar a base de dados desta forma tem as seguintes vantagens:

• Se for necessário mudar algum dos valores das tabelas dimensionais, como por exemplo, se o gestor de uma loja mudar, a alteração será tão simples como alterar um único registo mantendo intacta a tabela de factos que é bastante mais extensa;
• Permite adotar várias tabelas de factos. Por exemplo, se esta empresa começar a vender os seus produtos pela Internet ou através de uma força de vendas, poderia criar tabelas exclusivamente para esses canais de venda e ainda assim manter as mesmas tabelas de produtos.

Esquematicamente temos uma base de dados com as seguintes relações:

As relações são de um para muitos, como pode ver neste esquema, o que significa por exemplo que uma loja tem uma única chave primária na tabela “Loja”, mas pode aparecer repetidas vezes na tabela “Factos”.

Por outro lado, nem todas as tabelas se relacionam diretamente com a tabela “Factos”. Por exemplo, a tabela “Categoria” depende da tabela “Produto” que por sua vez se liga à tabela “Factos”. O mesmo acontece com a tabela “Gestor”. Este tipo de estrutura permite a criação de grupos e hierarquias.

MEDIDAS PERSONALIZADAS

Quando analisamos a tabela “Factos” verificamos que contém vários campos numéricos: “Faturação”, “Marca”, “Margem”, “Produto” e “Unidades”. Quando uma tabela contém campos numéricos, o Power BI assume que os queremos agregar de alguma forma, isto é, que estaremos interessados em calcular uma soma, média, valor mínimo e máximo, entre outras.

Os campos numéricos surgem na listagem de campos precedidos do ícone ∑. Por isso, quando criamos uma visualização com os campos “Produto” e “Margem” o Power BI soma automaticamente o valor da margem, o que não nos interessa.

Todos os campos numéricos são medidas calculadas automaticamente, mas, se não nos interessam, podemos ocultá-las da listagem de campos através da opção “Ocultar na Vista de Relatório”, como demonstra a seguinte imagem:

Assim, quando acedemos à área de Relatório, estes campos não figuram na listagem apesar de continuarem a existir no modelo de dados. Podemos ocultá-los sem qualquer problema porque as relações foram criadas e podemos usar os nomes dos produtos e das marcas a partir das respetivas tabelas.
Supondo que pretendemos analisar os resultados por produto, poderíamos criar a seguinte visualização de tabela:

No entanto, seria igualmente interessante saber qual é o valor das margens percentuais e o preço médio por produto. E, se nos quisermos antecipar a uma eventual pergunta, porque não também esses valores por ano ou por gestor?

É precisamente para executar esse tipo de cálculos que servem as medidas personalizadas. Ao contrário das colunas personalizadas, que vimos anteriormente, e que calculam valores linha-a- linha, as medidas personalizadas são calculadas em função do contexto em que se inserem. Se o filtro ou os parâmetros de visualização se alteram então, o cálculo é executado em função desse contexto.

Para calcular a margem percentual, teremos de dividir o valor da margem absoluta pelo valor da faturação absoluta. Mas, como queremos agregar estes valores em função do produto (ou de outro contexto qualquer), teremos primeiro que somar o total de cada um dos membros da equação.

Assim, acedendo à área do relatório, posicionamo-nos sobre a tabela “Factos” onde vamos introduzir esta medida e clicando no símbolo em elipse à direita (…) escolhemos “Nova medida”:

E o cursor posiciona-se automaticamente na barra de fórmulas com uma medida vazia. Teremos de voltar a recorrer à linguagem DAX para exprimir esta fórmula, que poderá ser a seguinte:

Esta nova medida personalizada figura na listagem de campos tal como as restantes e podemos agregá-la em diversas dimensões. Vejamos como detalhar a margem por produto e por marca vs ano: