Com o tempo, os problemas de análise retornam aos dados subjacentes. Registros de clientes duplicados, valores de receita que não correspondem em vários relatórios e dashboards que se contradizem não são problemas de visualização ou consulta; são problemas de esquema, e a normalização de dados é como as equipes os consertam na origem.

Abaixo, discutiremos como a normalização de dados funciona, como é um esquema normalizado na prática e onde os trade-offs reais aparecem para equipes de análise e warehouse.

Destaques

• A normalização de dados estrutura um banco de dados relacional para que cada informação exista em exatamente um lugar. Isso elimina valores duplicados e conflitantes.

• As equipes de análise podem aplicar a normalização em um pipeline construindo primeiro tabelas de entidades centrais normalizadas e depois criando camadas de relatórios desnormalizados sobre elas.

• Um provedor de pagamento moderno pode sincronizar os dados de pagamento diretamente no warehouse de uma empresa. Isso fornece aos esquemas normalizados uma fonte completa e nova para construção, sem encaminhar dados financeiros confidenciais por meio de conectores de terceiros.

O que é normalização de dados?

A normalização de dados é o processo de organizar um banco de dados relacional para que cada informação exista em exatamente um lugar. Você faz isso dividindo os dados em tabelas relacionadas e vinculando-as por meio de chaves, em vez de repetir os mesmos valores nas linhas.

O objetivo é a consistência. À medida que o volume de dados cresce, essa disciplina estrutural é o que separa um warehouse em que você pode confiar de um que você está constantemente auditando.

Por que a normalização de dados é importante para a precisão e governança da análise?

Dados não normalizados podem criar categorias de problemas que se agravam à medida que seus dados crescem.

Cada um dos seguintes problemas é uma falha estrutural no próprio esquema:

• Anomalias de atualização: ocorrem quando o mesmo fato aparece em várias linhas. Se o nome de um plano de assinatura for armazenado diretamente em cada linha da fatura, renomear o plano significa atualizar milhares de registros, e perder apenas um cria uma discrepância. Em um esquema normalizado, o nome do plano fica em uma tabela de planos; a fatura contém apenas um plan_id.

• Anomalias de inserção: ocorrem quando você não pode registrar algo sem registrar outra coisa não relacionada. Em uma tabela simples que armazena dados de clientes e pedidos em conjunto, você não pode adicionar um novo cliente até que ele faça um pedido, o que significa que a tabela quebra no momento em que a equipe de vendas começa a carregar clientes em potencial no warehouse.

• Anomalias de exclusão: ocorrem quando a exclusão de um registro específico remove de modo não intencional dados importantes não relacionados. Exclua o último pedido de um cliente em uma tabela simples e você perderá também as informações de contato dele, pois elas não tinham onde ficar de forma independente.

Quais são as principais formas normais?

As formas normais são uma sequência de regras cada vez mais rigorosas de como os dados devem ser estruturados.

As equipes que usam a normalização de dados precisam entender as formas até a terceira forma normal (3NF) para tomar boas decisões de esquema. Um banco de dados é frequentemente descrito como “normalizado” se atender à 3NF.

• Primeira Forma Normal (1NF): exige que cada coluna contenha valores atômicos — sem listas, sem strings separadas por vírgulas e sem arrays em um único campo. Uma coluna de produtos contendo “camisa, calça, jaqueta” não atende à 1NF. Três linhas com um product_id e um product_name cada atendem à 1NF.

• Segunda Forma Normal (2NF): baseia-se na 1NF e exige que cada coluna não chave dependa de toda a chave primária, e não apenas de parte dela. Se uma tabela de itens de linha usa “(order_id, product_id)” como chave, mas também armazena a cidade do cliente, que depende apenas do order_id, isso é uma dependência parcial e uma violação da 2NF. A cidade do cliente pertence à tabela de pedidos.

• Terceira Forma Normal (3NF): elimina as dependências transitivas, o que significa que as colunas não chave dependem de outras colunas não chave em vez da própria chave. Se uma tabela de pedidos armazenar zip_code e city, e a cidade for determinada pelo código postal e não pelo pedido, esses campos deverão estar em uma tabela de geografia separada.

• Forma Normal de Boyce-Codd (BCNF): esta é uma versão mais restrita da 3NF que lida com casos extremos envolvendo chaves candidatas sobrepostas. Para esquemas de análise, atingir a 3NF é suficiente.

Como a normalização de dados funciona na prática?

A forma mais clara de ver o que a normalização realmente faz é começar com uma tabela desorganizada e corrigi-la. Aqui está um exemplo de uma tabela de pedidos não normalizada e uma explicação do que acontece com ela após a normalização.

Tabela de pedidos não normalizada

Existem três problemas imediatos com esta tabela. O e-mail de Ana aparece duas vezes: se você atualizá-lo em uma linha, criará um conflito. O nome e a categoria do produto se repetem em cada linha de pedido, então alterar uma categoria significa modificar todos os pedidos históricos que a incluíram. E não há como adicionar um novo cliente ou produto sem anexar um pedido a ele.

Após a normalização, você teria três tabelas:

• Clientes: customer_id, nome, email
  
• Produtos: product_id, nome, categoria
  
• Pedidos: order_id, customer_id, product_id, quantidade, unit_price
  

O e-mail de Ana existe apenas uma vez. A categoria do headset existe apenas uma vez. Os pedidos fazem referência a ambos por ID. Uma instrução SELECT com dois joins em Structured Query Language (SQL) pode combinar dados de várias tabelas com base em condições comuns: um custo pequeno e permanente para um esquema que não acumula erros à medida que cresce.

Quais são as contrapartidas comuns da normalização de dados?

Embora tenha benefícios importantes, a normalização também pode apresentar custos reais para as equipes.

As contrapartidas ocorrem em três áreas:

• Complexidade de consulta: cada relacionamento que você normaliza em sua própria tabela é um join que você escreverá depois. Um relatório que você poderia ler de uma única tabela simples agora exige três joins, e a carga cognitiva aumenta em uma equipe de analistas trabalhando diretamente no SQL.

• Esforço inicial de modelagem: projetar um esquema normalizado requer entender o domínio bem o suficiente para identificar entidades, seus atributos e as relações entre eles. As equipes sob pressão para entregar muitas vezes pulam isso para construir estruturas simples que parecem mais fáceis no momento, mas se tornam caras depois.

• Desempenho de leitura: em tabelas muito grandes, os joins são mais lentos do que as varreduras. Os data warehouses (por exemplo, BigQuery, Snowflake e Redshift) têm otimizadores de consulta que lidam razoavelmente bem com joins, mas estruturas desnormalizadas geralmente oferecem melhor velocidade bruta de consulta para cargas de trabalho analíticas com bilhões de linhas.

Como as equipes de análise e warehouse aplicam a normalização de dados em fluxos de trabalho?

Na prática, as equipes de análise criam camadas de normalização em um pipeline. Diferentes níveis de estrutura atendem a propósitos e interesses distintos: a integridade dos dados é tratada na camada central normalizada, e o desempenho da consulta e a ergonomia do analista são tratados na camada de relatórios.

Veja como:

• Camada de preparo: os dados brutos chegam aqui quase da mesma forma que foram originados. Pouca ou nenhuma transformação ocorre nessa fase. O objetivo é apenas obter os dados de forma intacta e consultável no warehouse, sem modelá-los.

• Camada central normalizada: as ferramentas de transformação produzem tabelas de entidades normalizadas a partir da camada de preparo — uma para clientes, uma para assinaturas e uma para transações. Elas ficam em torno da 3NF e servem como fonte da verdade para qualquer modelo posterior.

• Camada de relatórios: acima da parte central normalizada, as equipes criam tabelas amplas e desnormalizadas, criadas para ter velocidade e facilidade de uso em uma ferramenta de business intelligence (BI), como Tableau ou Looker. Um modelo de dashboard de receita pode associar cinco tabelas normalizadas em uma ampla tabela de fatos que a ferramenta de BI lê diretamente.

Como a Stripe proporciona dados mais limpos e confiáveis para normalização posterior

A qualidade de qualquer esquema normalizado depende inteiramente da qualidade e completude dos dados que o alimentam. Registros de transação desatualizados ou incompletos podem criar lacunas de reconciliação que nenhuma quantidade de design cuidadoso de esquema pode corrigir.

Veja o que um provedor de pagamento pode oferecer:

• Sincronização: o Stripe Data Pipeline move os dados da Stripe (por exemplo, cobranças, clientes, assinaturas, reembolsos, contestações e repasses) diretamente para um data warehouse ou destino de armazenamento em nuvem, sem conectores de terceiros intermediários ou limitação de fluxo de API.

• Completude: a Stripe garante a completude dos dados sincronizando todos os dados da Stripe, relatórios financeiros pré-criados e conjuntos de dados selecionados.

• Segurança: quando as equipes direcionam dados da Stripe por meio de conectores de extração, transformação e carregamento (ETL) de terceiros, elas enviam dados financeiros confidenciais para a infraestrutura de um fornecedor adicional. O Data Pipeline lida com o transporte diretamente, o que remove esse intermediário e elimina um fornecedor da sua lista de revisão de segurança de dados.

O Data Pipeline não substitui uma plataforma ETL completa. Se você estiver combinando dados da Stripe com dados de várias outras fontes, ainda precisará de ferramentas de transformação. No entanto, essa solução foi projetada especificamente para sincronizar seus dados da Stripe melhor do que um conector de terceiros, garantindo que seus dados financeiros sejam sincronizados de forma confiável, segura e precisa.