Enquanto os Fatos acontecem a todo momento (milhares de vendas por minuto), as Dimensões mudam lentamente. Um cliente não muda de nome ou de endereço todos os dias. Porém, quando essa mudança acontece, a Engenharia de Dados precisa decidir como lidar com ela.

Se o João morava em São Paulo em 2025 e se mudou para o Rio de Janeiro em 2026, a venda que ele fez em 2025 deve ser contabilizada para SP ou para o RJ?

É para resolver esse problema de rastreamento histórico que existem as Slowly Changing Dimensions (SCD), ou Dimensões de Alteração Lenta. Os três tipos principais são o SCD Tipo 1, Tipo 2 e Tipo 3.

SCD Tipo 1: Substituição Direta (O Esquecimento)

O SCD Tipo 1 é a abordagem mais simples. Quando um dado muda no sistema de origem, você simplesmente sobrescreve o dado antigo no seu banco analítico.

• Objetivo: Ter sempre a informação mais atualizada possível.
• O que acontece com o histórico: Ele é perdido para sempre.
• Quando usar: Quando a mudança for uma correção de erro (ex: nome digitado errado) ou quando o histórico daquela informação não tiver nenhuma importância para as regras de negócio da empresa.

Exemplo Prático:

A cliente “Ana” atualiza seu número de telefone no cadastro.

Tabela Antes:

Tabela Depois (SCD 1 aplicado):

Note que não há como saber qual era o telefone antigo da Ana.

SCD Tipo 2: Versionamento (A Máquina do Tempo)

O SCD Tipo 2 é o padrão ouro da Engenharia de Dados corporativa. Quando um atributo muda, você não apaga nada. Em vez disso, você “encerra” a validade do registro antigo e insere uma nova linha na tabela com o dado atualizado.

Para que isso funcione, a tabela ganha novas colunas de controle, geralmente: Data_Inicio, Data_Fim e Status_Atual (Ativo/Inativo), além de uma Surrogate Key (Chave Artificial) para diferenciar as versões da mesma pessoa.

• Objetivo: Manter o histórico completo e preciso de todas as mudanças.
• O que acontece com o histórico: É totalmente preservado. Relatórios do passado puxarão os dados exatamente como eram na época.
• Quando usar: Quando o rastreamento histórico for essencial para auditoria, relatórios financeiros ou análises temporais (ex: mudança de cargo de um funcionário, mudança de endereço de um cliente).

Exemplo Prático:

O cliente “Carlos” morava em São Paulo, mas no dia 09/04/2026 ele se mudou para o Rio de Janeiro.

Tabela Antes:

Tabela Depois (SCD 2 aplicado):

Se o analista pedir as vendas do Carlos em 2025, o sistema fará um JOIN com a linha SK_Cliente 1001 (SP). Se pedir as vendas de hoje, usará a linha 1002 (RJ).

SCD Tipo 3: Nova Coluna (A História Parcial)

O SCD Tipo 3 é um meio-termo. Ele mantém o histórico, mas apenas da versão imediatamente anterior. Em vez de adicionar uma nova linha (como no Tipo 2), você adiciona uma nova coluna à tabela atual para guardar o valor antigo.

• Objetivo: Permitir a comparação rápida entre o estado atual e o estado anterior sem aumentar o número de linhas da tabela.
• O que acontece com o histórico: Você retém apenas 1 nível de passado. Se o dado mudar uma terceira vez, o histórico mais antigo é sobrescrito e perdido.
• Quando usar: É muito raro hoje em dia. Geralmente usado em casos muito específicos de vendas, como quando um representante muda de território e você quer ver os resultados dele tanto na “Região Atual” quanto na “Região Anterior” em uma mesma linha do relatório.

Exemplo Prático:

A vendedora “Mariana” cobria a região “Sul”, mas foi transferida para a região “Sudeste”.

Tabela Antes:

Tabela Depois (SCD 3 aplicado):

Quadro Resumo para Decisão de Arquitetura

Para resumir as diferenças de forma prática na hora de desenhar a modelagem do seu Data Warehouse:

O Fluxo Lógico (A Engenharia por trás)

Para aplicar o SCD Tipo 2, o seu pipeline de dados não pode simplesmente “sobrescrever” a tabela. Ele precisa realizar uma operação de Upsert (Update + Insert) complexa seguindo estes passos:

1. Comparação: O pipeline lê os dados que acabaram de chegar da fonte e compara com o que já está no seu Data Warehouse.
2. Identificação de Mudança: Para saber se algo mudou sem comparar coluna por coluna, os engenheiros costumam usar uma Hash Diff (uma assinatura digital da linha). Se o Hash da fonte for diferente do Hash do destino, algo mudou.
3. Fechamento do Passado: O script executa um UPDATE na linha antiga do banco de dados, preenchendo a data_fim com o horário atual e alterando o status para Inativo.
4. Abertura do Futuro: O script executa um INSERT de uma nova linha com os dados atualizados, data_inicio como agora e data_fim como nula (ou uma data infinita como 9999-12-31).

Ferramentas Práticas

Usando dbt (Snapshots)

O dbt é a ferramenta favorita para isso hoje. Ele tem uma funcionalidade nativa chamada snapshots. Você apenas define qual é a chave única e qual coluna indica a atualização, e o dbt gera toda a lógica de datas e versões automaticamente para você.

Usando SQL Puro (Merge)

Em bancos como Snowflake, BigQuery ou Databricks, usamos o comando MERGE. É um comando poderoso que consegue inserir ou atualizar registros em uma única transação, garantindo que o histórico não seja corrompido se o processo cair no meio.

3. Exemplo de Código SQL

Imagine que você está atualizando a dimensão de Produtos porque o preço ou a categoria mudaram:

-- Exemplo simplificado de lógica de aplicação SCD 2
-- 1. Marcar como expirado o que mudou
UPDATE dim_produtos
SET data_fim = CURRENT_DATE,
    atual = FALSE
WHERE id_produto IN (SELECT id_produto FROM staging_produtos)
  AND atual = TRUE;

-- 2. Inserir a nova versão "fresca"
INSERT INTO dim_produtos (sk_produto, id_produto, nome, preco, data_inicio, atual)
SELECT 
    nextval('seq_sk_produtos'), -- Gera uma nova Surrogate Key
    id_produto, 
    nome, 
    preco, 
    CURRENT_DATE, 
    TRUE
FROM staging_produtos;

-- Exemplo simplificado de lógica de aplicação SCD 2
-- 1. Marcar como expirado o que mudou
UPDATE dim_produtos
SET data_fim = CURRENT_DATE,
    atual = FALSE
WHERE id_produto IN (SELECT id_produto FROM staging_produtos)
  AND atual = TRUE;

-- 2. Inserir a nova versão "fresca"
INSERT INTO dim_produtos (sk_produto, id_produto, nome, preco, data_inicio, atual)
SELECT 
    nextval('seq_sk_produtos'), -- Gera uma nova Surrogate Key
    id_produto, 
    nome, 
    preco, 
    CURRENT_DATE, 
    TRUE
FROM staging_produtos;

O impacto no BI (O consumo do dado)

Para o analista que usa o Power BI ou Tableau, a aplicação prática do SCD Tipo 2 resolve o problema da Integridade Referencial Histórica.

• Sem SCD: Se um produto custava 10 e mudou para 20, todos os gráficos de lucro do ano passado seriam recalculados com o preço de 20, gerando números falsos.
• Com SCD: A tabela Fato de Vendas aponta para a Surrogate Key (SK) que era válida naquele dia. Assim, a venda de ontem usa a SK do preço 10, e a venda de hoje usa a SK do preço 20. O passado permanece intacto.

Na prática, aplicar SCD é gerenciar Surrogate Keys. Se você tentar fazer histórico usando apenas o ID original do sistema (Natural Key), você vai falhar, pois o ID 42 não pode aparecer duas vezes na mesma tabela como chave primária. A Surrogate Key (1001, 1002…) é o que permite que o ID 42 tenha várias vidas.

O post Slowly Changing Dimensions (SCD) apareceu primeiro em Data Universe.

O CRUD é o padrão absoluto que define as funções essenciais para o armazenamento persistente de dados em sistemas de software.

Entendendo cada letra do CRUD

Para ilustrar, imagine que você está usando a agenda de contatos do seu smartphone:

• C – Create (Criar): É a ação de inserir uma nova informação no sistema.
  • Exemplo prático: Quando você conhece alguém novo e salva o nome e o número de telefone dessa pessoa na sua agenda.
• R – Read (Ler): É a ação de consultar, buscar ou recuperar dados que já foram armazenados. É a operação mais executada na maioria dos sistemas.
  • Exemplo prático: Quando você abre a agenda e pesquisa pelo nome “João” para ver qual é o número dele.
• U – Update (Atualizar): É a ação de modificar um dado que já existe no banco de dados.
  • Exemplo prático: Quando o João muda de número de telefone e você edita o contato dele na agenda para salvar a informação nova.
• D – Delete (Excluir): É a ação de remover permanentemente uma informação do sistema.
  • Exemplo prático: Quando você não fala mais com o João e decide apagar o contato dele do seu celular.

Como o CRUD se traduz na Tecnologia?

O conceito de CRUD é universal, mas ele ganha “nomes” diferentes dependendo de onde o Engenheiro de Dados ou Desenvolvedor está trabalhando.

A tabela abaixo mostra como essas quatro ações conceituais são traduzidas para a linguagem de Banco de Dados Relacional (SQL) e para o padrão de comunicação da web (APIs REST):

Create (Criar/Inserir)

A operação de criação é feita através do comando INSERT. Aqui, passamos o nome da tabela, as colunas que queremos preencher e os respectivos valores.

-- Inserindo um novo aluno na tabela
INSERT INTO Alunos (nome_aluno, matricula, data_nasc)
VALUES ('Felipe Andrade', '2026105', '2004-08-20');

-- Inserindo um novo aluno na tabela
INSERT INTO Alunos (nome_aluno, matricula, data_nasc)
VALUES ('Felipe Andrade', '2026105', '2004-08-20');

Read (Ler/Consultar)

A leitura é a alma do SQL, feita com o comando SELECT. Podemos buscar todos os dados de uma vez ou filtrar por critérios específicos.

-- Consultar todos os alunos cadastrados
SELECT * FROM Alunos;

-- Consultar apenas o nome de um aluno específico usando a matrícula
SELECT nome_aluno 
FROM Alunos 
WHERE matricula = '2026105';

-- Consultar todos os alunos cadastrados
SELECT * FROM Alunos;

-- Consultar apenas o nome de um aluno específico usando a matrícula
SELECT nome_aluno 
FROM Alunos 
WHERE matricula = '2026105';

Update (Atualizar/Alterar)

O comando UPDATE modifica registros existentes. Atenção: É vital usar a cláusula WHERE; caso contrário, você atualizará todos os alunos da tabela de uma só vez (o pesadelo de todo DBA).

-- Alterando a data de nascimento do Felipe
UPDATE Alunos
SET data_nasc = '2004-09-20'
WHERE matricula = '2026105';

-- Alterando a data de nascimento do Felipe
UPDATE Alunos
SET data_nasc = '2004-09-20'
WHERE matricula = '2026105';

Delete (Excluir/Remover)

A exclusão é feita com o comando DELETE. Assim como no Update, o uso do WHERE é obrigatório para garantir que você está apagando apenas o registro correto.

-- Removendo o aluno do sistema através do seu ID único
DELETE FROM Alunos
WHERE id_aluno = 5;

-- Removendo o aluno do sistema através do seu ID único
DELETE FROM Alunos
WHERE id_aluno = 5;

Em ambientes de produção, é comum utilizarmos o Soft Delete. Em vez de usar o comando DELETE físico, adicionamos uma coluna chamada ativo (booleano). Para “apagar” o usuário, apenas fazemos um UPDATE Alunos SET ativo = false. Isso mantém o histórico e a integridade dos dados para auditoria futura.

Por que o CRUD é tão importante?

Entender o CRUD é o primeiro passo para projetar qualquer aplicação. Se você modelou um banco de dados (como vimos nas fases Conceitual, Lógica e Física) e o seu sistema não consegue realizar pelo menos o Create e o Read, ele não tem utilidade prática.

Além disso, é através da limitação das operações CRUD que implementamos a segurança e o RBAC (Role-Based Access Control). Por exemplo, um estagiário pode ter permissão apenas de Read em uma tabela financeira, enquanto o gerente tem permissão completa de Create, Read, Update e Delete.

O post CRUD (Create, Read, Update e Delete) apareceu primeiro em Data Universe.

O objetivo é ilustrar os tipos de dados utilizados e armazenados no sistema, as relações entre esses tipos de dados, as formas como os dados podem ser agrupados e organizados e seus formatos e atributos.

Os modelos de dados são construídos em torno das necessidades do negócio. As regras e os requisitos são definidos antecipadamente através do feedback das partes interessadas do negócio, para que possam ser incorporados no design de um novo sistema ou adaptados na iteração de um sistema existente.

Os dados podem ser modelados em vários níveis de abstração. O processo começa com a coleta de informações sobre os requisitos de negócios das partes interessadas e dos usuários finais.

Essas regras de negócios são então traduzidas em estruturas de dados para formular um projeto concreto de banco de dados. 

Um modelo de dados pode ser comparado a um roteiro, um projeto de arquiteto ou qualquer diagrama formal que facilite uma compreensão mais profunda do que está sendo projetado.

A modelagem de dados emprega esquemas padronizados e técnicas formais. Isso fornece uma maneira comum, consistente e previsível de definir e gerenciar recursos de dados em uma organização ou mesmo fora dela.

Idealmente, os modelos de dados são documentos vivos que evoluem junto com as mudanças nas necessidades de negócios. Eles desempenham um papel importante no suporte aos processos de negócios e no planejamento da arquitetura e estratégia de TI. 

1. Modelo Conceitual:
   • Pergunta: O QUÊ?
   • Visão do Negócio
   • Sem Detalhes Técnicos
   • Entidades e Relacionamentos
   • Atividade: Reuniões com Usuários
2. Modelo Lógico:
   • Pergunta: COMO?
   • Estrutura Lógica
   • Independente de SGBD
   • Tabelas, Chaves, Atributos
   • Atividade: Design do Banco
3. Modelo Físico:
   • Pergunta: IMPLEMENTAÇÃO
   • Banco de Dados Real
   • Específico para SGBD
   • Índices, Constraints, Tipos
   • Resultado: Banco Pronto para Usar

Progressão Lógica:

• Conceitual → Lógico → Físico
• Cada nível adiciona mais detalhe técnico
• Do abstrato para o concreto

Primeiro passo: Entendimento do Negócio

Imagine que você vai construir uma casa. Você não começa comprando cimento e tijolos no primeiro dia. Primeiro, você desenha um esboço com o arquiteto para entender quantos quartos a casa terá (o conceito). Depois, faz uma planta baixa com as medidas e a disposição das portas (a lógica). Por fim, o engenheiro define a espessura da parede, a fiação e o tipo de encanamento (o físico).

Na Engenharia de Software e de Dados, o processo de criar um banco de dados segue exatamente a mesma lógica. A Modelagem de Dados é dividida em três fases: Conceitual, Lógica e Física.

Atividades:

• Reuniões com stakeholders para entender o modelo de negócio, processos e objetivos da startup.
• Análise de documentos e softwares utilizados pela contabilidade.
• Levantamento dos requisitos de dados para cada área da empresa (financeiro, fiscal, clientes, etc.).

Exemplo: Identificar quais dados são necessários para registrar transações financeiras, gerar relatórios fiscais, gerenciar clientes e acompanhar indicadores de desempenho.

Modelagem Conceitual: A Visão de Negócio

O modelo conceitual é o mais alto nível de abstração. O foco aqui não é a tecnologia, mas sim entender as regras de negócio e como as informações se relacionam no mundo real. É um desenho feito para que gerentes, diretores e analistas de negócio consigam entender o sistema sem precisar saber programação.

Os modelos conceituais geralmente são criados como parte do processo de coleta dos requisitos iniciais do projeto. Normalmente, eles incluem classes de entidade (definindo os tipos de coisas que são importantes para o negócio representar no modelo de dados), suas características e restrições, os relacionamentos entre elas e os requisitos relevantes de segurança e integridade de dados. 

Objetivo: Criar uma representação abstrata das entidades, relacionamentos e atributos dos dados, independente de tecnologia.

Atividades:

• Identificação das entidades principais (Cliente, Conta Bancária, Transação Financeira, Plano de Contas, Nota Fiscal, etc.).
• Definição dos atributos de cada entidade (nome, CPF/CNPJ, data, valor, descrição, categoria, etc.).
• Estabelecimento dos relacionamentos entre as entidades (um cliente possui várias contas bancárias, uma transação está associada a uma conta e a um plano de contas, etc.).
• Criação de um Diagrama Entidade-Relacionamento (DER) para visualizar o modelo conceitual.

Exemplo Prático:

Em um sistema de biblioteca escolar:

• Um Aluno pega emprestado um Livro.
• O modelo conceitual mostrará apenas caixas para “Aluno” e “Livro”, unidas por uma linha representando o “Empréstimo”. Não nos importamos com o CPF do aluno ou o ISBN do livro ainda.

Esse modelo oferece uma visão geral do que o sistema conterá, como será organizado e quais regras de negócios estão envolvidas. 

2. Modelagem Lógica: A Estrutura da Informação

Esse modelo fornece maiores detalhes sobre os conceitos e relações no domínio em consideração. 

Os modelos lógicos não especificam nenhum requisito técnico do sistema. Este estágio é frequentemente omitido em práticas ágeis ou DevOps. 

Os modelos lógicos podem ser úteis em ambientes de implementação altamente processuais ou para projetos que são orientados a dados por natureza, como design de Data Warehouse ou desenvolvimento de sistemas de relatórios.

Objetivo: Transformar o modelo conceitual em um modelo mais detalhado, utilizando estruturas e regras específicas.

Atividades:

• Definição das características detalhadas dos dados (tipo de dado, tamanho, formato, constraints, etc.).
• Estabelecimento de regras de negócio (validações, gatilhos, etc.).
• Criação de um Modelo Lógico de Dados (MLD) utilizando notações como UML.

Uma vez aprovado o conceito, avançamos para o modelo lógico. Aqui, começamos a adicionar detalhes estruturais aos dados, mas ainda sem nos prender a um banco de dados específico (como Oracle, MySQL ou PostgreSQL). Este modelo é geralmente construído por Arquitetos de Dados ou Analistas de Sistemas.

• Objetivo: Responder como os dados serão estruturados e relacionados.
• Elementos adicionados:
  • Atributos: As características das entidades (ex: Nome, Data de Nascimento, Preço).
  • Chaves Primárias (PK): O identificador único de cada registro (ex: ID_Cliente).
  • Chaves Estrangeiras (FK): O campo que cria a ligação entre duas tabelas.
  • Normalização: É aqui que aplicamos as Formas Normais (1FN, 2FN, 3FN) para evitar redundâncias.

Exemplo Prático (Tabelas Lógicas):

Tabela: LIVRO

Tabela: AUTOR

Tabela: CATEGORIA

Tabela: MEMBRO

Tabela: EMPRESTIMO

Entidades (Tabelas) e seus Atributos:

1. LIVRO:
   • id_livro (Chave Primária)
   • titulo, isbn (Chave Única)
   • descricao, data_publicacao
   • quantidade_total, quantidade_disponível
   • id_autor (Chave Estrangeira)
   • id_categoria (Chave Estrangeira)
2. AUTOR:
   • id_autor (Chave Primária)
   • nome, nacionalidade
   • data_nascimento, biografia
3. CATEGORIA:
   • id_categoria (Chave Primária)
   • nome, descricao
4. MEMBRO:
   • id_membro (Chave Primária)
   • nome, email (Chave Única)
   • telefone, endereco
   • data_cadastro, status
5. EMPRESTIMO:
   • id_emprestimo (Chave Primária)
   • id_membro (Chave Estrangeira)
   • id_livro (Chave Estrangeira)
   • data_emprestimo, data_devolucao_prevista
   • data_devolucao_real, status

Relacionamentos:

• Um LIVRO é escrito por Um AUTOR
• Um LIVRO pertence a Uma CATEGORIA
• Um LIVRO tem vários EMPRÉSTIMOs
• Um MEMBRO realiza vários EMPRÉSTIMOs

Legenda

• PK (Primary Key): Chave Primária – Identifica unicamente cada registro
• FK (Foreign Key): Chave Estrangeira – Estabelece relacionamento com outra tabela
• UK (Unique Key): Chave Única – Campo único que não pode ser duplicado

3. Modelagem Física: A Implementação Tecnológica

O modelo físico é a “mão na massa”. É aqui que o modelo lógico é traduzido para a linguagem de um Sistema Gerenciador de Banco de Dados (SGBD) específico. O Engenheiro de Dados ou o DBA (Database Administrator) define como os dados serão efetivamente gravados no disco do servidor.

• Objetivo: Responder como o sistema vai armazenar os dados fisicamente, otimizando o desempenho.
• Elementos adicionados:
  • Tipos de Dados (Data Types): Definir se um campo será VARCHAR(50), INT, DECIMAL(10,2) ou BOOLEAN.
  • Índices (Indexes): Criados para acelerar a busca de dados.
  • Restrições (Constraints): Regras do banco, como NOT NULL ou UNIQUE.
  • Particionamento: Decisões de arquitetura (como vimos no caso do Sharding e Partitioning).

Exemplo Prático (Especificação Física):

A tabela de Aluno agora ganha sua definição técnica, pronta para virar código SQL:

Quadro Resumo: Comparando as 3 Fases

Para facilitar a visualização e servir de material de estudo, aqui está a comparação direta:

Referências Importantes sobre o Tema

Se você deseja se aprofundar na literatura acadêmica e de mercado que padronizou esses conceitos, recomendo os seguintes pilares da engenharia de dados:

1. Peter Chen (1976): Criador do Modelo Entidade-Relacionamento (MER), que é a base da modelagem conceitual até hoje. Seu artigo “The Entity-Relationship Model: Toward a Unified View of Data” mudou a história da computação.
2. DAMA-DMBOK (Data Management Body of Knowledge): O guia oficial da Data Management Association. O capítulo de Data Modeling and Design estabelece os padrões globais da indústria para a criação de modelos lógicos e físicos em empresas de grande porte.
3. Ralph Kimball e Bill Inmon: Para modelagem focada em Data Warehouses (OLAP), que utiliza modelagem dimensional (Star Schema/Snowflake), que é uma variação específica após a modelagem relacional clássica.

O post Modelagem de dados Conceitual, Lógica e Física apareceu primeiro em Data Universe.

Eles não são inimigos, mas sim estratégias opostas usadas para resolver problemas diferentes. A normalização foca na escrita e integridade (OLTP), enquanto a desnormalização foca na velocidade de leitura (OLAP).

O que é Normalização?

A normalização é o processo de organizar os dados em um banco de dados relacional para reduzir a redundância e melhorar a integridade. O objetivo é garantir que cada pedaço de informação seja armazenado em apenas um lugar. Quando você precisa atualizar o nome de um cliente, por exemplo, você altera apenas uma linha em uma única tabela, e não em centenas de registros de vendas.

Para atingir esse nível de organização, aplicamos regras progressivas chamadas de Formas Normais (FN).

O processo de normalização aplica uma série de regras sobre as tabelas de um banco de dados para verificar se estas estão corretamente projetadas.

Embora existam cinco formas normais (ou regras de normalização), na prática usamos um conjunto de três Formas Normais, ou seja, um banco de dados é considerado normalizado se nele foram aplicadas as regras destas três formas normais.

O que é Desnormalização?

A desnormalização é o processo intencional de adicionar redundância a um banco de dados que já foi normalizado. O objetivo é melhorar a performance de leitura.

Em sistemas de Data Warehouse ou Analytics (OLAP), fazer dezenas de JOINs para montar um relatório através de tabelas na 3FN é extremamente lento. A desnormalização “achata” essas tabelas, agrupando dados frequentemente consultados em um lugar só.

• Exemplo Prático: Em vez de fazer um JOIN entre Vendas, Clientes, Cidades e Estados para saber o total vendido em São Paulo, você cria uma tabela desnormalizada gigante (Fato/Dimensão) onde a linha da venda já contém o nome da cidade e do estado, mesmo que isso repita a palavra “São Paulo” um milhão de vezes.

1ª Forma Normal (1FN): Atomicidade

A regra de ouro aqui é: cada coluna deve conter apenas um valor único e indivisível (atômico), e não pode haver grupos repetidos. Uma entidade estará na primeira forma normal (IFN) se todos os campos forem atômicos (simples) e não multivalorados (com múltiplos valores).

Problema (Não Normalizado): Uma tabela de livros onde um livro possui vários autores na mesma célula.

Solução (1FN): Dividir em múltiplas linhas, garantindo que a coluna Autores tenha apenas um valor por registro.

Quais os problemas de uma tabela não normalizada com a 1FN?

São vários. A primeira forma normal tenta resolver um dos maiores problemas de bancos de dados que é
a repetição (redundância de dados) e a desorganização deles.

Imagine um campo telefone que permita a entrada de mais de um valor (dois números de telefones) por exemplo. Como faríamos uma busca em um dos valores apenas? Mesma coisa em um campo endereço onde as partes não estivessem desmembradas, da seguinte forma:

Rua das Oliveiras, 256, Parque Novo Mundo, São Paulo, SP.

Como seria possível fazer uma busca de todos os clientes que morassem no Parque Novo
Mundo? Ou na cidade de São Paulo? Ou no estado de SP?

Toda tabela precisa obrigatoriamente ser normalizada com a 1FN?

Não. A normalização é um processo corretivo que deve ser aplicado em casos específicos onde o problema for identificado. Tudo irá depender de como a análise dos dados foi feita. De início você terá muita dificuldade em aplicar as regras de normalização e somente o tempo e o acúmulo de experiência farão esse processo ser natural para você. Um analista experiente aplica a normalização de dados por padrão, pois ele olha para uma tabela e já ‘sente’ que tem algo errado ali e aplica a correção para tal.

2ª Forma Normal (2FN): Dependência Total

Para estar na 2FN, a tabela precisa estar na 1FN e todos os atributos não-chave devem depender de toda a chave primária (isso se aplica a tabelas com chaves primárias compostas). Uma entidade estará na 2FN se ela já se encontrar na 1FN e todos os atributos não chave forem totalmente dependentes da chave primária.

• Crie tabelas separadas para conjuntos de valores que se aplicam a vários registros.
• Relacione essas tabelas com uma chave estrangeira.
• Primeiramente, para estar na 2FN é preciso estar também na 1FN. 

2FN define que os atributos normais, ou seja, os não chave, devem depender unicamente da chave primária da tabela. Assim como as colunas da tabela que não são dependentes dessa chave devem ser removidas da tabela principal e cria-se uma nova tabela utilizando esses dados.

Problema (1FN, mas viola 2FN): Uma tabela de matrículas onde a chave composta é ID_Aluno + ID_Curso. O Nome_Curso depende apenas do ID_Curso, não do aluno.

Solução (2FN): Separar as informações específicas do curso em uma nova tabela.

Tabela Matricula:

Tabela Curso:

Conforme vimos tanto com a 1FN quanto agora com a 2FN, quando aplicamos a normalização de dados é comum gerar novas tabelas a fim de satisfazer as formas normais que estão sendo aplicadas. Mais uma vez gostaria de deixar claro que a normalização de dados, apesar das regras serem simples, causa grande dificuldade nos iniciantes da área. Então tenha paciência pois com o tempo irá ganhar experiência e tudo ficará mais fácil.

3ª Forma Normal (3FN): Sem Dependências Transitivas

Para estar na 3FN, a tabela deve estar na 2FN e nenhum atributo não-chave pode depender de outro atributo não-chave. Todos devem depender apenas da chave primária.

• Elimine campos que não dependem da chave.
• Assim como para estar na 2FN é preciso estar na 1FN, para estar na 3FN é preciso estar também na 2FN. 

3FN define que todos os atributos dessa tabela devem ser funcionalmente independentes uns dos outros, ao mesmo tempo que devem ser dependentes exclusivamente da chave primária da tabela. 

3FN foi projetada para melhorar o desempenho de processamento dos banco de dados e minimizar os custos de armazenamento. 

Problema (2FN, mas viola 3FN): Uma tabela de veículos onde a chave primária é a Placa. O atributo Pais_Origem_Marca depende da Marca, e não diretamente da Placa.

Solução (3FN): Criar uma tabela separada para as marcas.

Tabela Veiculo:

Tabela Marca:

3.5 Forma Normal de Boyce-Codd (BCNF)

Conhecida como “3.5FN”, ela é uma versão mais rigorosa da 3FN. A regra dita que todo determinante deve ser uma chave candidata. Ela resolve anomalias em tabelas que possuem múltiplas chaves candidatas compostas e sobrepostas.

Problema: Uma clínica onde a chave primária é (ID_Paciente + Especialidade). Um médico atende apenas uma especialidade. O Nome_Medico determina a Especialidade, criando uma redundância se o médico mudar de especialidade.

Solução (BCNF): Separar a relação do paciente com o médico, e do médico com a especialidade.

Tabela Consulta:

Tabela Medico_Especialidade:

4ª Forma Normal (4FN): Dependências Multivaloradas Independentes

Para estar na 4FN, a tabela deve estar na BCNF e não pode conter mais de uma dependência multivalorada independente.

Problema: Um programador tem várias “Linguagens” (Python, Java) e possui várias “Certificações” (AWS, Azure). Colocar tudo na mesma tabela cria uma multiplicação (produto cartesiano) de registros desnecessários.

Solução (4FN): Criar duas tabelas distintas para separar as dependências que não têm relação entre si.

Tabela Programador_Linguagem:

Tabela Programador_Certificacao:

5ª Forma Normal (5FN): Dependência de Junção

É extremamente rara na prática. Diz que uma tabela está na 5FN se ela não puder ser dividida em tabelas menores sem perder informações ao tentar juntá-las (JOIN) novamente. Trata de relações ternárias (três variáveis conectadas) que causam anomalias se agrupadas.

Problema: Uma relação complexa onde um Vendedor vende produtos de uma Marca que pertence a uma Categoria. Se juntarmos tudo, podemos inferir erroneamente que um vendedor vende uma categoria de uma marca específica que ele, na verdade, não tem autorização para vender.

Solução (5FN): Dividir a relação ternária em três tabelas binárias (relação de dois em dois).

Tabela Vendedor_Marca:

Tabela Vendedor_Categoria:

Tabela Marca_Categoria:

O post Normalização vs. Desnormalização de Dados apareceu primeiro em Data Universe.