Introdução
A criação de um modelo semântico excelente é uma das tarefas mais importantes que um analista de dados pode executar no Power BI da Microsoft. Ao fazer esse trabalho bem, você ajuda a facilitar a compreensão dos seus dados pelas pessoas, o que facilitará a criação de relatórios do Power BI valiosos para eles e para você.
As páginas neste módulo são apenas instrutivas, nenhum arquivo de dados é fornecido. Você terá a oportunidade de trabalhar com os dados reais nos laboratórios.
Um bom modelo semântico oferece os seguintes benefícios:
A exploração de dados é mais rápida.
As agregações são mais simples de criar.
Os relatórios são mais precisos.
A escrita de relatórios leva menos tempo.
Os relatórios são mais fáceis de manter no futuro.
Fornecer um conjunto de regras que garanta a criação de um bom modelo semântico é difícil, já que os dados são sempre diferentes e seu uso varia. Em geral, um modelo semântico menor é melhor por ser executado com mais rapidez e mais simples de usar. No entanto, definir o que compõe um modelo semântico menor é igualmente problemático, porque se trata de um conceito heurístico e subjetivo.
Um modelo semântico menor costuma ser composto de menos tabelas e menos colunas em cada tabela do que as que um usuário costuma ver. Se você importar todas as tabelas necessárias de um banco de dados de vendas mas a contagem total de tabelas for igual a 30, o usuário não achará isso intuitivo. Recolher essas tabelas para limitá-las a cinco tornará o modelo semântico mais intuitivo para os usuários, embora o usuário possa se sentir sobrecarregado ao abrir uma tabela e se deparar com 100 colunas. A remoção de colunas desnecessárias para fornecer um número mais gerenciável aumenta a probabilidade de o usuário ler todos os nomes de coluna. Para resumir, você deve optar pelo máximo de simplicidade ao projetar seus modelos semânticos.
A imagem a seguir é um exemplo de modelo de dados. As caixas contêm tabelas de dados, em que cada item de linha dentro da caixa é uma coluna. As linhas que conectam as caixas representam as relações entre as tabelas. Essas relações podem ser complexas, mesmo em um modelo tão simplista. O modelo semântico pode facilmente se tornar desorganizado e o número total de tabelas no modelo pode aumentar gradualmente. Garantir que seu modelo semântico permaneça simples, abrangente e preciso requer um esforço constante.
As relações são definidas entre tabelas por meio de chaves primárias e estrangeiras. As chaves primárias são colunas que identificam cada linha de dados exclusiva e não nula. Por exemplo, se você tiver uma tabela Customers, poderá ter um índice que identifique cada cliente único. A primeira linha tem uma ID igual a 1, a segunda linha, uma ID igual a 2 e assim por diante. Um valor exclusivo será atribuído a cada linha, ao qual será possível fazer referência usando este valor simples: a chave primária. Esse processo torna-se importante quando você está fazendo referência a linhas em uma tabela diferente, que é o que as chaves estrangeiras fazem. As relações entre tabelas são formadas quando você tem chaves primárias e estrangeiras em comum entre tabelas diferentes.
O Power BI permite que as relações sejam criadas com base em tabelas com fontes de dados diferentes, uma função poderosa que permite que você extraia uma tabela do Microsoft Excel e outra de um banco de dados relacional. Em seguida, você deve criar a relação entre essas duas tabelas e tratá-las como um modelo semântico unificado.
Agora que você aprendeu sobre as relações que compõem o esquema de dados, pode explorar um tipo específico de design de esquema, o esquema em estrela, que é otimizado para alto desempenho e usabilidade.
Esquemas em estrela
É possível criar um esquema em estrela para simplificar os dados. Essa não é a única maneira de simplificar os dados, mas é um método popular; portanto, todo analista de dados do Power BI deve conhecê-lo. No esquema em estrela, cada tabela dentro do seu modelo semântico é definida como uma dimensão ou uma tabela de fatos, conforme mostrado no elemento visual a seguir.
As tabelas de fatos contêm valores de dados observacionais ou de evento: pedidos de venda, contagens de produtos, preços, datas e horas de transação e quantidades. As tabelas de fatos podem conter vários valores repetidos. Por exemplo, um produto pode aparecer várias vezes em várias linhas, para clientes diferentes em datas diferentes. É possível agregar esses valores a fim de criar visuais. Por exemplo, um visual do total de pedidos de vendas é uma agregação de todos os pedidos de vendas na tabela de fatos. Com as tabelas de fatos, é comum ver colunas preenchidas com números e datas. Os números podem ser unidades de medida, como um valor de venda, ou podem ser chaves, como uma ID do cliente. As datas representam a hora que está sendo registrada, como data do pedido ou data de envio.
As tabelas de dimensões contêm os detalhes sobre os dados nas tabelas de fatos: produtos, locais, funcionários e tipos de pedido. Essas tabelas são conectadas à tabela de fatos por meio de colunas de chave. As tabelas de dimensões são usadas para filtrar e agrupar os dados nas tabelas de fatos. As tabelas de fatos, por outro lado, contêm os dados mensuráveis, como vendas e receita, e cada linha representa uma combinação exclusiva de valores das tabelas de dimensão. Para o visual de total de pedidos de vendas, você pode agrupar os dados para ver o total de pedidos de vendas por produto, em que produto é um dado na tabela de dimensões.
As tabelas de fatos são muito maiores do que as tabelas de dimensões, pois um número grande de eventos ocorrem em tabelas de fatos, como vendas individuais. As tabelas de dimensões normalmente são menores porque você está limitado ao número de itens pelos quais você pode filtrar e agrupar. Por exemplo, um ano contém apenas um determinado número de meses e os Estados Unidos são compostos de apenas um determinado número de estados.
Considerando essas informações sobre tabelas de fatos e tabelas de dimensões, você deve se perguntar como é possível criar esse visual no Power BI.
Os dados pertinentes residem em duas tabelas:Funcionários e Vendas, conforme mostrado no modelo semântico a seguir. Como a tabela Sales contém os valores de pedido de venda, que podem ser agregados, ela é considerada uma tabela de fatos. A tabela Employee contém o nome do funcionário específico, que filtra os pedidos de venda, portanto, ela seria uma tabela de dimensões. A coluna comum entre as duas tabelas, que é a chave primária na tabela Employee, é EmployeeID, de modo que é possível estabelecer uma relação entre as duas tabelas com base nessa coluna.
Ao criar essa relação, é possível criar o visual de acordo com os requisitos, conforme mostrado na figura a seguir. Se você não estabeleceu essa relação, mesmo mantendo em mente o elemento comum entre as duas tabelas, é mais difícil criar seu visual.
Os esquemas de estrela e o modelo semântico subjacente são a base dos relatórios organizados; quanto mais tempo você investir criando essas conexões e esse design, mais fácil será criar e manter relatórios.