Alguma vez já lhe ocorreu de estar aprendendo algo completamente novo, e você é bombardeado com tanto conteúdo que se sente perdido e não sabe muito bem o que fazer?
Hoje o dataholic Jefferson dos Santos vai abordar um conceito de BI, utilizando a ferramenta Power BI. Que tal focar naquilo que normalmente nos enche os olhos? O que veio em sua mente? DAX? Linguagem M? Visualização utilizando boas práticas de storytelling?
Estou aqui para apresentar um assunto que normalmente não faz brilharem os olhos como deveria, mas sem ele, nada do que foi citado acima funcionaria. Vamos falar de modelagem de dados!
O modelo de dados
Termos como Star Schema, Desnormalização, Relacionamento, Cardinalidade, Product Key e até mesmo a tal Bridge Table, deveriam ser mais comuns quando se trata de projetos de Business Intelligence, e estarem na ponta da língua quando analisamos a modelagem dos nossos dados.
A principal pergunta é: O que é um modelo de dados?
R: Um conjunto de tabelas conectadas através de colunas com a intenção de responder questões de negócios.
Mas será só isso? E como esse processo ocorre? Vamos lá!
Um pilar essencial para a criação de bons relatórios é com certeza, fazer uma boa modelagem, juntamente com um bom ETL. Pois, quando não temos uma boa relação entre nossas tabelas, automaticamente vamos ter problemas com nossas medidas DAX, também não poderemos criar nossos visuais de forma aceitável e com dados conexos.
O primeiro ponto de conhecimento necessário é a respeito de suas tabelas, que são seus modeladores, elas vão ditar o desempenho e usabilidade do relatório.
Tabelas Fato e Tabelas Dimensão
Tabela Fato: São aquelas que nos trazem fatos ou eventos que ocorreram. Exemplos desse tipo de tabela são vendas, saldos, ordens e outros valores quantitativos. Como característica, nossa fTabela normalmente contém milhões de linhas, e está continuamente incluindo registros. Também é muito comum ter uma coluna com informações de data. Outra informação muito importante é que nossa Tabela Fato nos trará a chave conhecida como Primary Key, que será a chave de relação com o nosso outro tipo de tabela.
Esta tabela é o coração do relatório.
Tabela Dimensão: São tabelas que vão nos trazer pontos nos quais os fatos serão analisados. Na nossa dTabela, teremos descrições dos eventos que foram trazidos em nossa Tabela Fato, e não seria errado pensar em Tabela Dimensão como cadastros. Também temos nossa coluna Product Key, chave para fazer o relacionamento entre as tabelas Dimensão e Fato, contendo informações com registros únicos como o ID.
Como exemplos de dimensão temos: datas, produtos, países, clientes etc.
Dica: A ideia mais comum entre nossas tabelas dimensão e fato é: uma tabela dimensão tem muitas colunas e poucas linhas, pois nela temos os registros de cadastros. Já em nossas tabelas fato normalmente temos muitas linhas e poucas colunas, pois as colunas nos trazem as chaves que serão relacionadas às tabelas dimensão.
Tabela Fato:
Figura 1
Tabela Dimensão:
Figura 2
Cardinalidade
Com o conhecimento a respeito dos tipos de tabelas, podemos falar em como que estas se relacionam, e vamos utilizar uma palavra que gosto bastante “CARDINALIDADE”.
Quando utilizamos nossas Product Keys para fazer o relacionamento, é necessário ter em mente os tipos de cardinalidades existentes para fazer essa conexão, são: um para muitos, muitos para um, um para um e muitos para muitos.
A forma mais comum dentre esses tipos, é quando utilizamos cardinalidade um para muitos (1 ─ *) onde o lado 1 (um) fica na dimensão, e * (muitos) na nossa tabela fato, com o filtro D → F significando que nossa tabela dTabela está filtrando nossa fTabela. Não é regra, porém acontece na maior parte dos casos. A lógica é que o 1 está relacionando a nossa tabela dimensão com nosso Product Key (cadastro único), já o * fica na tabela fato que irá registrar o evento quantas vezes for necessário, vendas por exemplo.
Utilizar o muitos para muitos (* ─ *) é necessário em alguns casos mais raros, quando fazemos relacionamento entre tabelas dimensão em que não estão no mesmo nível de granularidade. Dessa forma utilizamos uma Bridge Table (uma tabela auxiliar), que vai fazer a ponte entre as duas dimensões. Outro bom exemplo, é durante a relação de tabela fato e dimensão em que também temos granularidades diferentes.
“Como falei anteriormente a ideia principal é: dimensões filtram fatos”, e isso significa... NUNCA RELACIONAR TABELAS FATO ENTRE SI!!!
Exemplo de dTabela filtrando fTabela através da cardinalidade um para muitos (1 - *):,.
Figura 3
É nesse momento que abordamos uma questão: E se eu quiser colocar informações descritivas dentro da minha tabela fato? É errado? 🤔
Essa pergunta é respondida trazendo mais dois termos muito importantes que são: normalização e desnormalização. Durante a obtenção de dados, na transformação para ser mais específico, fazemos todas as alterações necessárias para que, posteriormente, possamos criar o nosso modelo de dados.
Um bom exemplo de normalização, é quando trazemos apenas as chaves (product keys), os quantificáveis e datas em nossa tabela fato. Isso significa que nossa tabela fato irá nos apresentar apenas as informações necessárias para análise, ganhando assim desempenho e velocidade na leitura dos dados.
Desnormalização de tabela
A fTabela utilizada como exemplo na Figura 1, é uma tabela normalizada.
Desnormalização de tabela acontece quando temos informações descritivas que poderiam estar em dimensões, isto é, fora da tabela fato ou na existência de ambiguidade de dados. Significa que você está trazendo para o seu modelo informações desnecessárias naquela tabela, e isso acarreta problemas relacionados a desempenho e até mesmo na maneira de sua análise.
Utilizar do Power Query para normalizar suas tabelas é um bom passo.
Vamos ver uma tabela fato desnormalizada como exemplo:
Figura 4
Star Schema e Snowflake
Acredito que o último tópico teve muitos pontos abordados então vamos ser um pouco mais práticos aqui, ok?
Os modelos relacionais utilizados durante a modelagem no Power BI são: esquema estrela (Star Schema) e floco de neve (Snowflake). Existe também a citada por alguns como constelação, chamam assim quando temos duas tabelas fato, porém como prometido seremos mais práticos e principalmente objetivos.
Star Schema (Esquema Estrela)
Boas práticas nos levam a utilizar o Star Schema pois é facilmente compreendido, além de que a filtragem e resumo das informações acontece de forma mais performática.
Dessa forma temos o formato de uma estrela com nossa tabela fato ao centro e as dimensões ao seu redor.
Aplicando aquele conceito que já foi abordado, onde as dimensões filtram fato.
Figura 5
Curiosidade: Existe um conceito na metodologia de negócios 5W2H e funciona exatamente da mesma forma. Sendo:
What (o que), When (quando), Where (onde), Why (por que), Who (quem) – referente a tabelas dimensão. How (como) e How Much (quanto) – referente a tabela fato.
Snowflake (Floco de neve)
Snowflake funciona como um conjunto de tabelas normalizadas, onde tabelas dimensão filtram outras tabelas dimensão.
Existem problemas que são acarretados através desse modelo, e isso pode se agravar ainda mais dependendo do seu modelo de dados.
Ao utilizar o floco de neve, o Power BI terá que carregar mais tabelas, e consequentemente percorrer mais relacionamentos e mais filtros. Tudo isso irá impactar no desempenho final.
Algumas vezes você irá perceber a necessidade de utilizar um Snowflake para relacionar categoria com subcategoria por exemplo, mas sempre analise a possibilidade de mesclar as duas tabelas, sendo assim, você obtém a sua categoria dentro da sua tabela de subcategoria.
Deixo também um exemplo de Snowflake:
Figura 6
Para finalizar com os schemas também podemos falar um pouco de relacionamentos inativos que como o próprio nome já diz, estão inativos. É uma linha tracejada que faz a relação entre as duas tabelas, ainda assim, pode “forçar” a ativação deste através da linguagem DAX.
Para fazer isso a função USERELATIONSHIP com certeza, será sua amiga.
Figura 7
Dicas e finalização
Até aqui, é possível compreender que sem um bom relacionamento entre suas tabelas, você não poderá fazer suas medidas ou prosseguir com seus filtros de forma correta.
O caminho, é prestar bastante atenção ao modelar seus dados.
Então algumas dicas sempre são bem-vindas, certo? 😊
· Utilizar números como chave é sempre uma boa pedida.
· Elimine redundância nos dados ao repetir informação em tabelas.
· Star Schema é seu amigo e vai te ajudar a chegar aonde você deseja.
· Nunca relacione tabelas fato entre si.
· Padronize os nomes de suas tabelas fato e dimensão ex: dTabela e fTabela.
· Atenção a tabelas desconectadas ao modelo.
· Muita atenção ao filtro sentido ambos.
· Elimine colunas desnecessárias.
Abordamos aqui conhecimento em modelo utilizando a ferramenta Power BI como exemplo, mesmo assim, este é um conceito muito amplo e utilizado em todo banco de dados. Tenha em mente a importância da modelagem.
Essa foi minha primeira vez aqui e prometo que não será a última, espero que tenham gostado. Nos encontraremos aqui novamente em breve! Não deixe de comentar o que mais gostaria de ver relacionado a este conteúdo, e deixe suas sugestões para melhorá-lo, além de compartilhar com aquele amigo que ainda não entende de modelagem.
Um abraço queridxs!