Introdução
Criar um excelente modelo semântico é uma das tarefas mais importantes que um analista de dados pode realizar no Microsoft Power BI. Ao realizar bem esta tarefa, pode ajudar a que seja mais fácil para as pessoas entender os seus dados, tornando mais simples para si e para elas criar relatórios úteis no Power BI.
As páginas neste módulo são apenas instrutivas, não são fornecidos ficheiros de dados. Tem a oportunidade de trabalhar com dados reais nos laboratórios.
Um bom modelo semântico oferece os seguintes benefícios:
Maior rapidez na exploração de dados.
As agregações são mais fáceis de criar.
Os relatórios são mais exatos.
Demora menos tempo a criar relatórios.
Os relatórios são mais fáceis em termos de manutenção futura.
O fornecimento de regras definidas para o que torna um bom modelo semântico é difícil porque todos os dados são diferentes e a utilização desses dados varia. Geralmente, um modelo semântico mais pequeno é melhor porque tem um desempenho mais rápido e será mais simples de utilizar. No entanto, definir o que um modelo semântico mais pequeno implica é igualmente problemático porque é um conceito heurístico e subjetivo.
Normalmente, um modelo semântico mais pequeno é composto por menos tabelas e menos colunas em cada tabela que o utilizador possa ver. Se importar todas as tabelas necessárias de uma base de dados de vendas, mas o número total for 30 tabelas, o utilizador não considerará isso intuitivo. Fechar essas tabelas em cinco tabelas torna o modelo semântico mais intuitivo para o utilizador, ao passo que, se o utilizador abrir uma tabela e encontrar 100 colunas, poderá ser esmagador. Remover colunas desnecessárias para fornecer um número mais gerível aumenta a probabilidade de o utilizador ler todos os nomes de colunas. Para resumir, deve apontar para a simplicidade ao conceber os seus modelos semânticos.
A imagem seguinte é um modelo semântico de exemplo. As caixas contêm tabelas de dados, em que cada item de linha na caixa é uma coluna. As linhas que ligam as caixas representam relações entre as tabelas. Estas relações podem ser complexas, mesmo num modelo tão simples. O modelo semântico pode tornar-se facilmente desorganizado e a contagem total de tabelas no modelo pode aumentar gradualmente. Manter o seu modelo semântico simples, abrangente e preciso requer um esforço constante.
As relações são definidas entre tabelas através de chaves primárias e externas. As chaves primárias são colunas que identificam cada linha de dados exclusiva e não nula. Por exemplo, se tiver uma tabela Customers, pode ter um índice que identifique cada cliente diferente. A primeira linha tem um ID de 1, a segunda linha um ID de 2, etc. Cada linha recebe um valor exclusivo, que se designa com este valor simples: a chave primária. Este processo é importante quando referencia linhas numa tabela diferente, e é isso que as chaves externas fazem. As relações entre tabelas formam-se quando tem chaves primárias e externas em comum em diferentes tabelas.
O Power BI permite estabelecer relações entre tabelas com diferentes origens de dados, uma função avançada que permite obter uma tabela do Microsoft Excel e outra de uma base de dados relacional. Em seguida, criaria a relação entre essas duas tabelas e trataria-as como um modelo semântico unificado.
Agora que aprendeu sobre as relações que compõem o esquema de dados, pode explorar um tipo específico de estrutura de esquema, o esquema de star, que está otimizado para elevado desempenho e utilização.
Esquemas de estrela
Pode criar um esquema de estrela para simplificar os seus dados. Não é a única forma de simplificar dados, mas é um método popular, pelo que todos os analistas de dados do Power BI devem compreendê-lo. Num esquema star, cada tabela dentro do modelo semântico é definida como uma dimensão ou uma tabela de factos, conforme mostrado no seguinte elemento visual.
As tabelas de factos contêm valores de dados de eventos ou observacionais: encomendas de vendas, contagens de produtos, preços, datas, horas e quantidades de transações. As tabelas de factos podem conter diversos valores repetidos. Por exemplo, um produto pode aparecer múltiplas vezes em diferentes linhas, para clientes diferentes e em datas diferentes. Estes valores podem ser agregados para criar elementos visuais. Por exemplo, um elemento visual do total de encomendas de vendas é uma agregação de todas as encomendas de vendas na tabela de factos. Nas tabelas de factos, é frequente ver colunas preenchidas com números e datas. Os números podem ser unidades de medida, como quantidades de vendas, ou podem ser chaves, como um ID de cliente. As datas representam a altura do seu registo, como uma data de encomenda ou data de envio.
As tabelas de dimensões contêm informações sobre os dados nas tabelas de factos: produtos, localizações, colaboradores e tipos de encomenda. Estas tabelas estão ligadas à tabela de factos por colunas de chaves. As tabelas de dimensões utilizam-se para filtrar e agrupar os dados em tabelas de factos. As tabelas de factos, por outro lado, contêm os dados mensuráveis, como vendas e receitas, e cada linha representa uma combinação exclusiva de valores das tabelas de dimensão. Para o elemento visual de total de encomendas de vendas, pode agrupar os dados de forma a ver o total de encomendas de vendas por produto, em que cada produto corresponde a dados na tabela de dimensões.
As tabelas de factos são muito maiores do que as tabelas de dimensão porque ocorrem inúmeros eventos em tabelas de factos, como vendas individuais. As tabelas de dimensões costumam ser mais pequenas, porque está limitado ao número de itens que pode filtrar e agrupar. Por exemplo, um ano contém apenas tantos meses e os Estados Unidos são compostos apenas por um determinado número de estados.
Tendo em conta estas informações sobre tabelas de factos e tabelas de dimensões, pode perguntar-se como criar este elemento visual no Power BI.
Os dados pertinentes residem em duas tabelas, Employee e Sales, conforme mostrado no seguinte modelo semântico. Uma vez que a tabela Sales contém os valores de encomendas de vendas, que podem ser agregados, considera-se uma tabela de factos. A tabela Employee contém o nome específico do colaborador, que filtra as encomendas de vendas, pelo que seria uma tabela de dimensão. A coluna comum entre as duas tabelas, que é a chave primária na tabela Employee, é EmployeeID, para que possa estabelecer uma relação entre as duas tabelas com base nesta coluna.
Ao criar esta relação, pode criar o elemento visual de acordo com os requisitos, como mostra a seguinte imagem. Se não tivesse estabelecido esta relação, embora tenha em atenção a comunhão entre as duas tabelas, teria tido mais dificuldade a criar o seu elemento visual.
Os esquemas de estrela e o modelo semântico subjacente são a base de relatórios organizados; quanto mais tempo passar a criar estas ligações e estrutura, mais fácil será criar e manter relatórios.