Modelagem de dados

Um mergulho nos principais pilares de modelagem de dados de um data warehouse.

Figura 1: imagem de Shubham por Unsplash.

Modelagem de dados: o que é, para que serve e sua importância

Muito se fala no ambiente corporativo sobre o valor e importância do uso dos dados para a tomada de decisões assertivas. No entanto, os dados transacionais gerados pelos inúmeros sistemas de uma empresa não são adequados para o consumo direto do negócio. Por esse motivo, surge a necessidade de modelar os dados.

A modelagem de dados consiste na criação de um conjunto de elementos que respondam dúvidas e reflitam as regras de negócio. Através dela, transformamos os dados brutos, com o fim de convertê-los em informações que permitem gerar conhecimento de valor. Sendo assim, ela deve ser totalmente focada nas necessidades do usuário final.

Decisões de negócio são tomadas com base em produtos de dados, como análises exploratórias, dashboards, detecção de padrões e problemas, modelos e métodos de inteligência artificial. Por isso, é extremamente importante que os dados reflitam informações verdadeiras — caso contrário, uma organização pode estar direcionando suas escolhas baseadas em informações erradas.

É essencial que quem use o produto dessa modelagem consiga compreender de forma simples aquele conjunto de dados. Por isso, a padronização de nomenclaturas e formatação são de extrema importância, além das documentações que registrem as características importantes para compreensão e uso daquele conjunto de dados.

Para o profissional responsável pela modelagem obter êxito em seu trabalho é indispensável que ele mergulhe no contexto do negócio e se aproxime dos usuários finais, a fim de compreender o dia a dia e a forma de pensar dessas pessoas.

Por outro lado, também é necessário desenvolver habilidades técnicas dentro da área de dados, tornando-se uma ponte entre o negócio e a tecnologia. Assim, uma boa modelagem permite aumentar a velocidade e confiança na tomada de decisões, tornando-se uma vantagem competitiva.

O resultado de uma modelagem deve ser um conjunto de dados que:

• seja de fácil acesso;
• contenha informações consistentes;
• seja adaptável a mudanças;
• gere informações em tempo hábil;
• esteja armazenado em um local seguro para proteger as informações;
• seja a fonte da verdade para a tomada de decisões;
• atenda às necessidades do time de negócios.

Até aqui explicamos a motivação da modelagem de dados e seus objetivos, mas qual a diferença entre modelar e simplesmente executar uma query?

O conceito de processamento de dados define todo o fluxo de vida dos dados desde sua extração até sua disponibilização e, a modelagem dos dados é uma parte importante que torna esse processo consistente. Para esclarecer um pouco o assunto, vamos descrever brevemente como funcionam as etapas do processamento de dados.

Processamento de dados

Uma organização possui diversos softwares e sistemas que geram dados a todo momento. Normalmente, sua arquitetura de dados é pensada para suprir as necessidades do backend (o código que conecta a aplicação com o banco de dados), onde a preocupação com o conteúdo e o formato dos dados é focada em eficiência computacional. Por essa razão, esses dados não são ideais para o consumo direto pelo negócio.

Para obter esses dados é necessário fazer um processo de ETL (Extract, Transform and Load) — que significa extração, transformação e carregamento, em português. Estas operações compreendem tudo que é necessário para preparar os dados desde os sistemas operacionais de origem até a sua apresentação para o usuário final.

• A extração consiste em identificar e extrair esse dado da fonte para enviá-lo a um local em que ele possa ser trabalhado, comumente o data lake, que permite o armazenamento de dados que podem ou não ser estruturados. Dados estruturados são organizados e possuem uma estrutura rígida previamente definida, enquanto dados não estruturados são dinâmicos e flexíveis, podendo conter até imagens, áudios, vídeos, emojis;
• A transformação é onde ocorre a modelagem de dados, ou seja, é nesta etapa que os dados são transformados — tendo como base regras e premissas de negócio, além dos objetivos claros para o consumo final e as análises que serão feitas a partir daqueles dados. Os principais processos que ocorrem na transformação são:
  - A limpeza de dados, que pode incluir a correção de erros ortográficos, tratamento de campos vazios, formatação padronizada, deduplicação (remoção de duplicidades) de informações e substituição de um campo por uma nomenclatura mais compreensível;
  - A combinação de dados, que pode consistir em operações matemáticas, criação de campos booleanos e outras inúmeras regras de negócio que façam sentido naquele contexto. Essa é a parte mais complexa da transformação de dados e é nela que focaremos;
  - A realização de testes, que envolvem tanto testes técnicos que garantam, por exemplo, aspectos da limpeza de dados e granularidade, quanto testes que asseguram as regras de negócio sobre aquela entidade. Portanto, os testes feitos nas tabelas modeladas devem assegurar que se algum comportamento inesperado ocorrer, os responsáveis serão alertados.
• Finalmente, ocorre o carregamento desses dados já tratados em um local específico, comumente chamado de data warehouse, de onde os usuários sabem que podem fazer suas consultas e análises de forma segura.

Embora a modelagem componha a etapa de transformação de dados, para que ela funcione com qualidade, é essencial haver processos sólidos de extração e de carregamento.

Figura 2: Representação de um processo de ETL (Extract, Transform and Load).

Agora que entendemos o processamento de dados, vamos explicar como podemos traduzir os acontecimentos do mundo real de uma forma lógica por meio do Modelo Entidade Relacionamento, que é um dos pilares da modelagem de dados.

Modelo Entidade Relacionamento

O Modelo Entidade Relacionamento é uma disciplina da Engenharia de Software que surgiu para facilitar a compreensão de um projeto de banco de dados na forma de um fluxograma. No modelo são descritos os objetos de interesse (Entidades), suas características (Atributos) e como elas se relacionam (Relacionamento), tudo dentro de um processo de negócio. O esquema da Figura 3 ilustra um Modelo Entidade Relacionamento, tomando como exemplo um cenário de vendas.

Figura 3: Estrutura de entidades, atributos e relacionamentos no contexto do exemplo de uma loja de vendas.

As entidades são os objetos de um domínio de negócio possíveis de serem definidos, que se deseja conhecer informações (atributos) e se relacionam com outros objetos, como por exemplo: cliente, estudante, produto, venda, vendedor, médico, prédio. Usualmente essas entidades tornam-se tabelas, que podem ser:

• Entidades fortes: possuem significado sozinhas, não dependem de outras, têm chave primária e são representadas por um único retângulo. No exemplo da Figura 3, “cliente”, “pedido” e “loja” são entidades fortes;
• Entidades fracas: dependem de uma identidade forte para existirem com significado, não possuem uma chave primária e são representadas por um retângulo duplo. No exemplo de vendas da Figura 3, os “itens” são entidades fracas, já que não existem sem um pedido.

Os atributos são as características daquela entidade naquele contexto. Eles são representados por uma elipse e podem ser:

• Descritivos: são atributos que caracterizam a entidade. Por exemplo, no caso de um cliente pode ser sua profissão ou endereço;
• Nominativos: também descrevem mas permitem a identificação da entidade. Por exemplo, o ID de um cliente, seu CPF e nome.

Os relacionamentos são a forma em que as entidades identificadas se conectam. Elas são representadas por um losango e podem ser de três tipos:

• Relacionamento 1:1: são entidades que possuem apenas uma possibilidade de conexão entre si. Por exemplo, uma pessoa pode ter apenas uma habilitação cadastrada, assim como a habilitação só pode estar conectada a uma pessoa;
• Relacionamento 1:n: são entidades que podem se relacionar com muitas (duas ou mais) em uma outra tabela, mas essas muitas só se relacionam com uma. Por exemplo, um cliente pode fazer muitos pedidos, mas cada um dos pedidos só pode se relacionar com um cliente;
• Relacionamento n:n: são entidades em que ambos os lados podem se conectar com muitas entidades da outra tabela. Por exemplo, um ator pode ser relacionado com muitas peças de teatro, assim como uma peça de teatro pode ser relacionada com muitos atores.

Referências na área

Agora que já sabemos um pouco sobre a Modelagem Entidade Relacionamento, falaremos sobre dois estudiosos que se tornaram referência na área, Ralph Kimball e William H. Inmon.

Kimball começou a publicar estudos sobre o assunto na década de 1980 e posteriormente escreveu o livro “The Data Warehouse Toolkit”, que consolida a teoria da modelagem de dados e apresenta estudos de casos. Segundo o autor, para obter sucesso na modelagem é necessário:

• selecionar um processo de negócio específico;
• declarar a granularidade desejada (temporal e da entidade);
• identificar quais são as Tabelas Fato (registram as transações daquele processo) — definidas com maiores detalhes na seção seguinte;
• identificar quais são as Tabelas Dimensão (descrevem e suportam as Tabelas Fato) — são definidas com maiores detalhes na seção seguinte.

A modelagem de Kimball, por ser focada em um único processo de negócio, acaba sendo relativamente mais rápida de construir, o que também permite a obtenção de insights com maior facilidade. Por outro lado, não há integração de todos os dados da organização, dificultando a geração de relatórios integrados, uma vez que a modelagem é focada em um único processo de negócio.

Kimball define um data warehouse como um conjunto de data marts que representam, cada qual, um foco de análise de um tema de negócio de forma intuitiva, facilitando a filtragem e agregação dos dados gerenciais. Podemos pensar em um data mart como sendo uma estrutura de armazenamento de dados focada em um único processo de negócio e com informações detalhadas para aquele contexto.

Na Figura 4 está representado o ciclo de vida do dado de acordo com a modelagem de Kimball, que pode ser entendida pelos passos abaixo:

1. Dados são extraídos das diferentes fontes de dados (que armazenam os dados brutos dos diversos sistemas de backend);
2. São feitas algumas modelagens focadas cada uma delas em um processo de negócio e armazenados cada uma em um data mart;
3. Esses data marts são unificados em um data warehouse que armazena todos os dados em um único lugar. No caso do exemplo, a arquitetura do data warehouse segue o formato star schema — estrutura organizacional que será explicada com maiores detalhes na seção seguinte;
4. O data warehouse torna-se fonte para processamentos e agregações dos dados no processamento analítico, que resulta em tabelas de mais fácil acesso para as informações que os usuários finais buscam;
5. Esse conjunto de tabelas agregadas utilizadas pelo usuário final constitui a camada analítica.

Figura 4: Ciclo de vida do dado, segundo metodologia proposta por Kimball.

Inmon começou suas publicações com o livro “Building the Data Warehouse” na década de 1990 e tornou-se a primeira pessoa a oferecer aulas sobre a modelagem de dados no meio acadêmico.

Sua abordagem ficou conhecida por pensar do topo para a base de um negócio, ou seja, Inmon defende a importância de definir os assuntos chave dentro de uma organização (topo) e, a partir destes, definir quais são as entidades existentes (base).

A modelagem de Inmon permite uma fonte da verdade unificada para todo o negócio, reduz irregularidades e é flexível. Por outro lado, trata-se de um processo mais demorado cuja complexidade cresce conforme a volumetria de dados aumenta.

Em sua modelagem, o autor identifica um assunto dentro da empresa, analisa quais entidades estão presentes nesse assunto e integra todos detalhes possíveis relacionados a ele, evitando ao máximo redundâncias de dados. Após a modelagem do data warehouse, orientada por assuntos e focada na organização, cada área de interesse inserida em um contexto de negócio cria data marts que funcionam para eles.

Inmon define o data warehouse como uma base de dados orientada por assuntos, integrada, não volátil e com histórico cumulativo.

Na Figura 5 está representado o ciclo de vida do dado de acordo com a modelagem de Inmon, que pode ser entendida pelos passos abaixo:

1. Dados são extraídos das diferentes fontes de dados (que extraem os dados brutos dos diversos sistemas de backend);
2. São feitas algumas tranformações desses dados que são armazenados em um data warehouse de forma consolidada e unificada;
3. Esse data warehouse torna-se fonte para criação de data marts, portanto, aqueles dados unificados e transformados de forma generalizada para a organização passam por mais transformações que se preocupam, cada qual, com um processo de negócio específico, e ficam armazenados em data marts dedicados;
4. Os data marts tornam-se fontes para processamentos e agregações dos dados no processamento analítico, que resulta em tabelas de mais fácil acesso para as informações que os usuários finais buscam;
5. Esse conjunto de tabelas agregadas utilizadas pelo usuário final constitui a camada analítica.

Figura 5: Ciclo de vida do dado, segundo metodologia proposta por Inmon.

Principais schemas de modelagem

Agora que já entendemos melhor a necessidade de estruturar tabelas em nosso data warehouse de maneira consistente, vamos explorar alguns exemplos práticos de arquiteturas aplicadas no mercado.

Vimos que uma forma de traduzir diferentes informações para os nossos bancos de dados no processo de modelagem é aplicando o Modelo Entidade Relacionamento. Com ele, conseguimos estruturar e organizar os dados, além de transformá-los em métricas (medidas quantificáveis, calculadas com o fim de analisar e acompanhar processos, por exemplo “receita” ou “total de clientes”), fornecendo conhecimentos de valor para o negócio.

Uma vez que temos as definições de entidade e relacionamento bem estabelecidas, trabalhamos então na organização prática dos nossos dados aplicando arquiteturas específicas, denominadas esquemas — ou schemas. Schemas podem ser entendidos como um conjunto de regras que norteiam a estrutura e organização do nosso data warehouse (DW), respondendo perguntas como:

• onde deve ficar cada uma das entidades e métricas?
• quais entidades são armazenadas em conjunto e quais ficam separadas?
• como as entidades se conectam?
• como são definidas as quebras, hierarquias e subdivisões das informações?

Existem diferentes tipos de modelos dimensionais (schemas) possíveis para um DW, dentre eles: Star Schema (Modelo estrela), SnowFlake Schema (Modelo Floco de Neve), Galaxy Schema (Modelo Galáxia) e Star Cluster Schema (Modelo Cluster), cada qual com suas particularidades no que diz respeito a:

• otimização organizacional dos dados
• facilidade de consulta e de acesso às informações
• desempenho computacional de consultas
• agregações e valor para o negócio.

Os dois schemas mais difundidos e utilizados nos DWs atuais são o Star Schema, proposto por Kimball, e o SnowFlake, que surgiu posteriormente, e são eles que iremos definir em maiores detalhes nesse artigo.

Tabela Fato e Tabela Dimensão

Para entender os principais schemas, é importante antes assimilar os conceitos de Tabela Fato e Tabela Dimensão — também teorizados por Kimball — que representam as tabelas do nosso banco de dados que foram processadas e estruturadas seguindo padrões específicos, de acordo com seu objetivo e formato da informação armazenada.

Cada Tabela Dimensão descreve uma entidade de negócio, ou seja, um item que você modela com suas diversas características, ou atributos, junto dele. Geralmente são tabelas qualitativas e com muitas colunas, comumente contendo informações descritivas ou nominativas sobre a entidade. Em um contexto de uma loja de vendas, podemos pensar nas dimensões como sendo os produtos, vendedores, clientes, datas, etc.

Já uma Tabela Fato armazena eventos de um determinado acontecimento do mundo real. Ela contém um conjunto de fatos com informações de caráter não descritivo que ocorrem em determinada periodicidade, além disso, a agregação de Tabelas Dimensão também pode resultar em uma Tabela Fato. Podemos pensar nos fatos como métricas (algo que pode ser medido) resultantes de um processo de negócio. Geralmente são tabelas quantitativas, com menos colunas. No mesmo exemplo citado de uma loja, uma Tabela Fato poderia armazenar os eventos de vendas, uma outra tabela poderia guardar os eventos de entrega dessas vendas.

Feito esse breve resumo sobre Tabelas Dimensão e Fato, vamos para as definições dos principais schemas citados.

Star Schema

A estrutura de Star Schema facilita a distinção entre Dimensões e Fatos e simplifica a visualização dimensional dos dados. O esquema consiste em várias Tabelas Dimensão ligadas a uma Tabela Fato em um formato de estrela — daí o nome da estrutura.

Como esse é um modelo mais simples que conecta apenas Dimensões a Fato, o seu desempenho tem destaque, além da maior simplicidade no cálculo de métricas. No entanto, dado que esse esquema é comumente focado em um evento ou temática única de negócio, fica mais difícil analisar dados que tangem ou transitam entre diferentes assuntos. Além disso, como os dados não são normalizados nesse esquema, eles ficam sujeitos a alguns tipos de redundância — uma vez que o processo de normalização dos dados isola informações potencialmente repetidas ou não relacionadas entre si em tabelas distintas e mais granulares constituindo, portanto, estruturas no geral mais segmentadas e complexas.

A Figura 6 ilustra um exemplo de arquitetura em Star Schema.

Figura 6: Estrutura de tabelas no modelo Star Schema, no contexto do exemplo de uma loja de vendas.

SnowFlake Schema

A estrutura do esquema SnowFlake — que se parece com um floco de neve — adiciona complexidade ao modelo ao normalizar os dados, com o objetivo de reduzir a redundância do armazenamento. Ao contrário do Star Schema, que conecta apenas fatos com dimensões, o SnowFlake estabelece também conexões entre diferentes dimensões, baseadas em alguma hierarquia estabelecida.

No que diz respeito à otimização dos dados, esse modelo é melhor desenvolvido do que o de estrela, facilitando a análise de dimensões e reduzindo a redundância (os dados são normalizados). No entanto, a complexidade dessa estrutura encontra-se não apenas no armazenamento das informações, como também na consulta e extração. Desse modo, o cálculo de métricas nesse modelo pode ter um desempenho mais lento, já que requer a junção de um número maior de dimensões.

A Figura 7 ilustra um exemplo de arquitetura em SnowFlake Schema.

Figura 7: Estrutura de tabelas no modelo SnowFlake Schema, no contexto do exemplo de uma loja de vendas.

Depois de todas essas definições, você pode estar se perguntando: qual é a melhor estrutura? A resposta é que não existe um schema melhor que o outro, e sim schemas mais ou menos adequados para cada propósito. Algumas perguntas importantes a serem respondidas durante o processo de definição são:

• o que estamos avaliando e o que queremos analisar?
• como pretendemos agrupar e mensurar as informações?
• qual a granularidade da informação (nível mais baixo de detalhes)?
• qual o custo computacional para buscar as informações que precisamos?

A depender das respostas e dos objetivos de consumo ou análise de negócio, pode haver uma estrutura mais adequada para a Modelagem dos Dados.

Conclusão e principais aprendizados

• A importância da modelagem como instrumento que possibilita a garantia da qualidade de dados responsáveis pela tomada de decisões assertivas e confiáveis. A modelagem é um constante trabalho que depende de conhecimentos técnicos e de negócios e, para isso, deve resultar em uma única fonte da verdade;
• O processamento de dados, conhecido como ETL, consiste em três etapas: a extração, transformação (que envolve a modelagem) e o carregamento. Os tratamentos de dados que ocorrem na etapa de transformação são essenciais para garantir a compreensão do usuário final no momento de consumir os dados;
• Vimos que para termos dados consistentes é importante escolhermos arquiteturas (schemas) que definam as regras práticas de como nossas informações serão estruturadas nas nossas tabelas. Dentre os schemas mais difundidos hoje estão:
• Star Schema: mais simples e com melhor desempenho, porém sujeito a redundância (não é normalizado) e com maior dificuldade de integrar temas diferentes;
• SnowFlake Schema: facilita a análise de dimensões e reduz a redundância, no entanto, pode inserir mais dificuldade nas análises e consultas;

Não existe um schema melhor, cada um é mais adequado para as particularidades de situações específicas.

Existe um grande número de métodos e teorias que definem práticas consistentes para a estruturação e Modelagem de Dados. Na prática, no entanto, os sistemas, processos e corporações enfrentam muitos desafios práticos para manter uma estrutura robusta e bem definida de dados, o que torna comum a necessidade de combinar diferentes técnicas, trabalhando com um aprimoramento contínuo para adequar os dados às necessidades de negócio vigentes.

Escrito por: Angela Alves Ferreira, Analytics Engineer e Lidia Gusmão, Cientista de Dados na Pier