O que é normalização de banco de dados?

A normalização de banco de dados é um processo usado no design de banco de dados para organizar os dados de maneira eficiente. Ela pode ajudar a reduzir a redundância de dados (dados duplicados) e melhorar a integridade dos dados (precisão e consistência dos dados). É como organizar um arquivo bagunçado: em vez de ter as mesmas informações em vários lugares, você coloca cada informação em um só lugar e usa um sistema de referências cruzadas para conectá-las.

O que queremos dizer com "banco de dados"?

Um banco de dados é simplesmente uma coleção organizada de dados, geralmente armazenados eletronicamente em um sistema de computador. Pense nele como um arquivo digital. Em vez de pastas e gavetas de papel, você usa tabelas estruturadas (ou outros métodos de organização de dados) que permitem armazenar, gerenciar e recuperar informações de maneira rápida e eficiente.

As empresas modernas usam bancos de dados para rastrear tudo, desde pedidos de clientes e níveis de estoque até detalhes de contas de usuários e transações financeiras, e muitas optam por executar seus bancos de dados na nuvem.

O que é um banco de dados relacional?

Um banco de dados relacional organiza os dados em uma ou mais tabelas de colunas e linhas. Ele é chamado de "relacional" porque estabelece relações específicas e predefinidas entre essas tabelas. A ideia principal é dividir informações complexas em partes menores e gerenciáveis, evitando a necessidade de armazenar as mesmas informações várias vezes.

Exemplo de normalização de banco de dados

Imagine um banco de dados simples para uma loja on-line. Você teria uma tabela para clientes (nome, endereço, telefone) e outra para pedidos (data, total). Quando um cliente faz um pedido, você não precisa copiar todo o endereço dele para a tabela de pedidos. Basta usar o ID exclusivo do cliente para conectar o pedido aos detalhes completos do cliente.

Se o cliente se mudar e mudar de endereço, você só precisa atualizar o endereço em um lugar: a tabela "Clientes". Se você copiou para 100 registros de pedidos, teria que atualizar todos os 100, o que provavelmente levaria a dados confusos e inconsistentes. Esse problema de precisar atualizar informações em vários lugares é chamado de anomalia de dados.

No entanto, você quer copiar o preço de um produto para o registro do pedido no momento da compra. Por quê? Porque o preço do produto pode mudar no futuro na sua tabela principal de produtos, mas o registro do pedido precisa refletir o preço que o cliente realmente pagou na data da transação. Nesse caso, copiar e congelar os dados (ou criar um snapshot) é a escolha de design correta.

A normalização é o processo sistemático de projetar suas tabelas relacionais e os relacionamentos entre elas para eliminar essas inconsistências e economizar espaço de armazenamento. As "formas normais" (1FN, 2FN, 3FN etc.) são uma série de regras prescritivas. Elas são uma solução para a redundância de dados e as anomalias que ela cria, fornecendo um caminho claro para organizar os dados de maneira eficiente e confiável com base nas necessidades do seu aplicativo.

Diferentes formas normais (1FN, 2FN, 3FN)

A normalização é um guia detalhado para estruturar suas tabelas, com cada etapa (ou "forma") baseada na anterior. Para estar na terceira forma normal (3FN), uma tabela precisa passar nos testes da 1FN e da 2FN. A maioria dos bancos de dados operacionais é projetada para atender pelo menos ao padrão 3NF, porque ele pode fornecer um equilíbrio entre integridade e desempenho dos dados.

Primeira forma normal (1FN): a base estrutural

A regra da 1FN é garantir que suas tabelas estejam estruturadas corretamente desde o início, como configurar uma planilha limpa.

Regra: cada coluna precisa ter um nome exclusivo, e cada célula precisa conter apenas um valor único e indivisível.

O que ele resolve: não é possível colocar uma lista de itens em uma única célula. Por exemplo, em uma tabela "Pedidos", você não pode listar "Leite, Ovos, Pão" em uma célula na coluna "Produtos pedidos". Em vez disso, cada produto precisa ter sua própria linha, o que garante que os dados sejam pesquisáveis e gerenciáveis.

Segunda forma normal (2FN): eliminação de dependências parciais

A regra da 2FN só se aplica se a tabela usa uma chave composta, ou seja, uma chave primária formada por duas ou mais colunas combinadas (como um ID do pedido mais um ID do produto). Uma chave primária é a coluna ou conjunto de colunas cujos valores identificam de maneira exclusiva cada linha em uma tabela. Uma coluna sem chave é qualquer coluna que não faça parte da chave primária.

Regra: uma tabela já precisa estar na 1FN, e todas as colunas não chave precisam depender da chave composta inteira, não apenas de parte dela.

O que resolve: você só deve armazenar dados onde eles pertencem. Se você tem uma tabela em que a chave é (OrderID, ProductID), uma coluna como Product Price não deve estar nela porque o preço depende apenas do ProductID, não do OrderID. A solução é mover o ProductID e o Product Price para uma tabela de produtos separada, em que o ProductID é a única chave primária. Isso evita que o preço do produto seja repetido desnecessariamente em todos os pedidos que contêm esse produto.

Terceira forma normal (3FN): eliminação de dependências transitivas

A regra da 3FN é o alvo mais comum para o design de banco de dados e trata da remoção de relações indiretas entre pontos de dados.

Regra: uma tabela precisa estar na 2FN e as colunas não principais precisam depender apenas da chave primária, não de outras colunas não principais.

O que ela resolve: evitar que um dado não chave determine o valor de outro dado não chave. Considere uma tabela "Employees" que armazena um ID de escritório (uma coluna não chave) e o local do escritório (outra coluna não chave). O local do escritório é determinado pelo ID do escritório, não pelo ID do funcionário (a chave primária da tabela). Esse link indireto é uma dependência transitiva. Para corrigir isso, você cria uma nova tabela "Offices" contendo apenas o ID do escritório e a localização do escritório e, em seguida, vincula as duas tabelas usando o ID do escritório. Isso garante que você só precise atualizar a localização do escritório em um lugar se ela mudar.

Normalização x desnormalização

Recurso	Normalização	Desnormalização
Meta principal	Reduzir a redundância e melhorar a integridade dos dados.	Melhorar o desempenho da leitura
Exemplos de casos de uso	Bancos de dados transacionais (atualizações frequentes).	Bancos de dados analíticos e data warehouses (leituras frequentes); dados que não podem mudar após a criação (por exemplo, um contrato ou snapshot de fatura).
Result	Mais tabelas, menos duplicação de dados.	Menos tabelas, duplicação intencional de dados.

Recurso

Normalização

Desnormalização

Meta principal

Reduzir a redundância e melhorar a integridade dos dados.

Melhorar o desempenho da leitura

Exemplos de casos de uso

Bancos de dados transacionais (atualizações frequentes).

Bancos de dados analíticos e data warehouses (leituras frequentes); dados que não podem mudar após a criação (por exemplo, um contrato ou snapshot de fatura).

Result

Mais tabelas, menos duplicação de dados.

Menos tabelas, duplicação intencional de dados.

A desnormalização é a adição intencional de dados redundantes a um banco de dados, geralmente para melhorar o desempenho da consulta para relatórios ou análises. É uma troca: você sacrifica um pouco da integridade e aumenta o espaço de armazenamento para uma recuperação de dados mais rápida. No entanto, em cenários como um contrato legal, você pode querer essa redundância intencional para criar um snapshot dos dados que seja independente de mudanças futuras. Isso garante que os termos, nomes e preços registrados no momento da assinatura do contrato permaneçam fixos e disponíveis permanentemente, mesmo que os dados principais do cliente ou do produto sejam atualizados posteriormente.

Por que a normalização de banco de dados é importante?

A normalização torna os bancos de dados relacionais (como o Cloud SQL ou o Spanner) mais eficientes, confiáveis e fáceis de gerenciar usando "formas normais" para estruturar os dados e evitar problemas comuns.

Reduzir a redundância de dados

Armazene cada parte dos dados, como o endereço de um cliente, em apenas um lugar para economizar espaço de armazenamento e aumentar a eficiência.

Eliminar anomalias nos dados

Evitar inconsistências que podem ocorrer com dados redundantes, como anomalias de inserção, exclusão ou atualização.

Melhorar a integridade dos dados

Garantir que os dados sejam precisos e consistentes em todo o banco de dados, garantindo que cada parte dos dados esteja correta e armazenada em apenas um local.

Se sua prioridade for desempenho ultra-alto, escala massiva ou um esquema flexível, você pode escolher um banco de dados não relacional (NoSQL), como o Bigtable ou o Firestore. Os bancos de dados NoSQL são projetados com princípios diferentes que incluem intencionalmente a redundância de dados para otimizar leituras rápidas e disponibilidade.

Resolva seus desafios comerciais com o Google Cloud

Clientes novos recebem US$ 300 em créditos para usar no Google Cloud.

Normalização de banco de dados com o Google Cloud

O Google Cloud oferece uma variedade de serviços que oferecem suporte e se beneficiam da normalização de banco de dados.

Vá além

Comece a criar no Google Cloud com US$ 300 em créditos e mais de 20 produtos do programa Sempre gratuito.

Precisa de ajuda para começar?
Entre em contato com a equipe de vendas
Trabalhe com um parceiro confiável
Encontre um parceiro
Continue navegando
Ver todos os produtos