Normalização em bancos de dados relacionais: da 1FN à 3FN

Normalização em bancos de dados relacionais é o processo de organizar atributos em relações para representar dependências entre dados com menos redundância e menos anomalias de inserção, atualização e exclusão. Sua aplicação exige compreender as regras do domínio e identificar chaves e dependências funcionais.

Um conceito bem importante durante a normalização é o das Formas Normais (FNs), que são regras que devem ser obedecidas por tabelas para que sejam consideradas “bem projetadas”. A ideia é garantir que as tabelas estejam construídas de forma que não tenham nenhum tipo de anomalia (inconsistência).

Existem diversas formas normais e elas basicamente tentam eliminar redundâncias e/ou inconsistências nos dados, trazendo vantagens para o sistema. Por exemplo, Codd (1972) apresentou a segunda e a terceira formas normais como convenções de projeto destinadas, entre outros objetivos, a reduzir dependências indesejáveis nas operações sobre os dados.

Este artigo desenvolve as três formas normais mais comuns — primeira forma normal (1FN), segunda forma normal (2FN) e terceira forma normal (3FN) — por meio de um cenário contínuo de inscrições universitárias. O foco é o projeto lógico de relações, de forma que os detalhes de implementação variam entre sistemas gerenciadores de bancos de dados.

Por que normalizar?

Imagine que uma universidade mantenha uma única tabela com estudante, disciplina, professor e nota. Se vários estudantes cursam a mesma disciplina, o nome dela e o professor responsável aparecem repetidos em muitas linhas. Essa repetição abre espaço para inconsistências e cria três tipos conhecidos de anomalia:

• Atualização: se o nome do professor mudar, várias linhas precisam ser alteradas. Uma linha esquecida deixa valores conflitantes.
• Inserção: pode ser impossível cadastrar uma disciplina antes de haver estudante inscrito, caso a tabela exija dados de matrícula.
• Exclusão: apagar a última matrícula de uma disciplina pode apagar também a única cópia dos dados da disciplina e do professor.

A normalização organiza fatos que pertencem a entidades ou associações diferentes em relações próprias. Consultas que combinam essas informações podem então usar junções. O objetivo é representar corretamente o domínio e controlar redundâncias, mesmo que isso signifique maximizar o número de tabelas.

Conceitos necessários

Uma relação é, em termos práticos, uma tabela; cada linha é uma tupla e cada coluna representa um atributo. Uma chave candidata é um conjunto mínimo de atributos que identifica cada tupla. Uma dessas chaves pode ser escolhida como chave primária. Atributos que participam de alguma chave candidata são chamados primos; os demais, não primos.

Uma dependência funcional X → Y afirma que, em todas as instâncias válidas segundo as regras do domínio, o valor de X determina um único valor de Y. Por exemplo, se cada identificador de estudante corresponde a uma única pessoa, então estudante_id → estudante_nome. A dependência expressa uma regra semântica, não apenas uma coincidência encontrada em algumas linhas de uma amostra. A definição de dependência funcional é central nas formas normais discutidas por Codd (1972).

Considere, ao longo do artigo, estas regras do cenário didático:

• um estudante pode cursar várias disciplinas;
• cada disciplina pode ter vários estudantes;
• cada estudante tem um único nome associado ao seu identificador;
• cada disciplina tem um nome e, neste recorte, um único professor responsável;
• cada professor tem um único nome associado ao seu identificador;
• a nota é registrada para cada par estudante-disciplina.

Essas regras implicam, entre outras, as dependências estudante_id → estudante_nome, disciplina_id → disciplina_nome, professor_id, professor_id → professor_nome e (estudante_id, disciplina_id) → nota. Em palavras mais simples, uma dependência funcional é uma ligação entre dois ou mais atributos, onde o valor de um atributo identifica o valor do outro (Araújo, 2022).

Existe também a dependência funcional parcial, que ocorre quando os atributos não-identificadores não dependem de toda a chave primária (se ela for composta). Além disso, há a dependência funcional transitiva, que ocorre quando um ou mais campos de uma tabela não são dependentes diretamente da chave primária, ou de parte dela, mas sim dependente de outro campo da tabela que não é uma chave primária. Falaremos mais sobre elas nas próximas seções.

Primeira forma normal (1FN)

Uma relação está na 1FN quando cada atributo contém valores atômicos em seu domínio, em vez de conjuntos ou grupos repetidos dentro de uma célula. Na definição clássica de Codd, nenhum domínio da relação contém valores que sejam, eles próprios, conjuntos (Codd, 1972).

Para Elmasri e Navathe (2011), a primeira forma normal afirma que o domínio de um atributo deve incluir apenas valores atômicos (simples, indivisíveis) e que o valor de qualquer atributo em uma tupla deve ser um único valor do domínio desse atributo. Numa definição semiformal, podemos dizer que uma tabela está na primeira forma normal quando ela não contém tabelas aninhadas (Heuser, 2009).

O termo “atômico” deve ser entendido em relação às operações e regras do domínio: um endereço pode ser tratado como um único valor se a aplicação não precisa separá-lo; se busca por cidade ou código postal for necessária, essa escolha deve ser reavaliada.

Em termos práticos, para colocarmos um banco na primeira forma normal basta eliminarmos os atributos multivalorados e compostos (Araújo, 2022). Assim, cumprimos a obrigação da atomicidade dos campos. Portanto, ao identificarmos a existência de atributos multivalorados e compostos, podemos criar uma tabela para armazenar os dados dos atributos multivalorados e desfazer os campos compostos.

Uma tabela como a seguinte viola a 1FN quando a coluna disciplinas guarda vários códigos juntos (multivalorada):

O valor de disciplinas contém uma lista, não um único valor do domínio usado para identificar uma disciplina. Uma forma de remover o grupo repetido é registrar uma linha por inscrição:

Assumindo que o estudante não possa se inscrever duas vezes na mesma disciplina, a chave candidata desta relação é (estudante_id, disciplina_id). Os atributos são atômicos para o uso definido e cada linha representa uma inscrição, portanto a relação está na 1FN. Isso ainda não basta: nome do estudante depende apenas de parte da chave composta, e os dados da disciplina também se repetem.

Segunda forma normal (2FN)

Uma relação está na 2FN quando está na 1FN e cada atributo não primo depende funcionalmente da chave candidata inteira, sem depender de um subconjunto próprio dela. Conforme Heuser (2009), uma tabela está na 2FN quando, além de estar na 1FN, não contém dependências parciais.

Assim, a 2FN é especialmente relevante quando há chave composta. Se a chave candidata tem apenas um atributo, não existe subconjunto próprio não vazio dela que possa determinar parcialmente os demais atributos.

Podemos entender a ideia da 2FN como: uma tabela está na segunda forma normal se ela atende todos os requisitos da 1FN e se os campos na tabela, que não são chaves, dependam da chave primária em sua totalidade e não apenas parte dela. (Araújo, 2022). Por exemplo, na relação de inscrições, a chave é (estudante_id, disciplina_id), mas as dependências incluem:

• estudante_id → estudante_nome;
• disciplina_id → disciplina_nome, professor_id, professor_nome;
• (estudante_id, disciplina_id) → nota.

estudante_nome depende apenas de estudante_id, e não do par completo. Os dados da disciplina dependem apenas de disciplina_id. São dependências parciais em relação à chave composta. A nota, por sua vez, depende do par, pois representa o resultado daquele estudante naquela disciplina.

Portanto, podemos decompor a relação em três:

• Estudante(estudante_id, estudante_nome)
• Disciplina(disciplina_id, disciplina_nome, professor_id, professor_nome)
• Inscrição(estudante_id, disciplina_id, nota)

Os identificadores destacados são chaves primárias; em Inscrição, os dois juntos formam uma chave composta. A chave de estudante em Inscrição referencia Estudante, e a chave de disciplina referencia Disciplina. Agora, nenhum atributo não primo em cada relação depende de apenas uma parte de uma chave composta. As três relações estão na 2FN. Porém, Disciplina ainda contém uma dependência transitiva: disciplina_id → professor_id → professor_nome.

A Figura 1 representa esse esquema como um modelo entidade-relacionamento. Cada caixa é uma relação, a sigla PK marca a chave primária e a sigla FK, a chave estrangeira. Na figura, repare que a entidade Estudante tem o símbolo (||) do seu lado, enquanto a entidade Inscricao tem outro símbolo, o (o) na conexão da linha. Devemos ler esta conexão da seguinte maneira: um registro do lado esquerdo (Estudante) se associa a zero ou mais registros do lado direito (Inscrição). Logo, cada estudante pode ter várias inscrições, e cada disciplina pode receber várias inscrições.

erDiagram
    Estudante ||--o{ Inscricao : realiza
    Disciplina ||--o{ Inscricao : recebe
    Estudante {
        INTEGER estudante_id PK
        VARCHAR(120) estudante_nome
    }
    Disciplina {
        VARCHAR(10) disciplina_id PK
        VARCHAR(120) disciplina_nome
        INTEGER professor_id
        VARCHAR(120) professor_nome
    }
    Inscricao {
        INTEGER estudante_id PK, FK
        VARCHAR(10) disciplina_id PK, FK
        DECIMAL(4,2) nota
    }

Figura 1. Esquema na 2FN. Elaborada pelo autor.

Observe que professor_nome aparece em Disciplina, embora dependa de professor_id e não da chave disciplina_id. É essa dependência transitiva que a 3FN remove.

Terceira forma normal (3FN)

A formulação informal ensina que uma relação está na 3FN quando está na 2FN e atributos não chave não dependem transitivamente da chave. Para maior precisão, uma relação está na 3FN quando, para toda dependência funcional não trivial X → A, vale ao menos uma destas condições: X é superchave, ou A é atributo primo. Essa definição formal também cobre situações nas quais existem várias chaves candidatas.

Algumas sugestões de passos para colocar tabelas na 3FN:

• Identificar cada grupo de atributos não-chave que dependam de outros atributos não-chave.
• Criar uma tabela para armazenar os atributos (ou conjunto de atributos) não-chave que não estão relacionados à chave primária da tabela original.

Na tabela Disciplina, as dependências relevantes são disciplina_id → professor_id e professor_id → professor_nome. Logo, professor_nome é determinado indiretamente por disciplina_id, por meio de professor_id. Como professor_id não é chave da relação Disciplina e professor_nome é não primo, a tabela não satisfaz a 3FN. O nome do professor seria repetido para cada disciplina sob sua responsabilidade.

Decomponha então Disciplina em:

Disciplina(disciplina_id, disciplina_nome, professor_id)

Professor(professor_id, professor_nome)

O esquema final é:

• Estudante(estudante_id, estudante_nome)
• Professor(professor_id, professor_nome)
• Disciplina(disciplina_id, disciplina_nome, professor_id)
• Inscrição(estudante_id, disciplina_id, nota)

Em cada relação, os atributos descritivos dependem da chave daquela relação, da chave inteira e de nada além dela no conjunto de dependências considerado. As relações estão em 3FN. Em particular, professor_nome é armazenado uma vez por professor, enquanto Disciplina.professor_id registra a associação entre disciplina e responsável.

A Figura 2 mostra o esquema final. A nova relação Professor aparece à esquerda, sendo que cada disciplina tem exatamente um professor responsável, e que um professor pode responder por zero ou mais disciplinas. Comparando com a Figura 1, percebemos que o atributo professor_nome saiu da entidade Disciplina, e o atributo professor_id passou a ser chave estrangeira.

erDiagram
    Professor ||--o{ Disciplina : "é responsável por"
    Estudante ||--o{ Inscricao : realiza
    Disciplina ||--o{ Inscricao : recebe
    Estudante {
        INTEGER estudante_id PK
        VARCHAR(120) estudante_nome
    }
    Professor {
        INTEGER professor_id PK
        VARCHAR(120) professor_nome
    }
    Disciplina {
        VARCHAR(10) disciplina_id PK
        VARCHAR(120) disciplina_nome
        INTEGER professor_id FK
    }
    Inscricao {
        INTEGER estudante_id PK, FK
        VARCHAR(10) disciplina_id PK, FK
        DECIMAL(4,2) nota
    }

Figura 2. Esquema final na 3FN. Elaborada pelo autor.

Esquema relacional e consulta

Uma representação SQL compatível com a estrutura apresentada, e com a Figura 2, é:

CREATE TABLE Estudante (
    estudante_id INTEGER PRIMARY KEY,
    estudante_nome VARCHAR(120) NOT NULL
);

CREATE TABLE Professor (
    professor_id INTEGER PRIMARY KEY,
    professor_nome VARCHAR(120) NOT NULL
);

CREATE TABLE Disciplina (
    disciplina_id VARCHAR(10) PRIMARY KEY,
    disciplina_nome VARCHAR(120) NOT NULL,
    professor_id INTEGER NOT NULL REFERENCES Professor(professor_id)
);

CREATE TABLE Inscricao (
    estudante_id INTEGER NOT NULL REFERENCES Estudante(estudante_id),
    disciplina_id VARCHAR(10) NOT NULL REFERENCES Disciplina(disciplina_id),
    nota DECIMAL(4, 2),
    PRIMARY KEY (estudante_id, disciplina_id)
);

As chaves estrangeiras expressam referências entre relações. Elas evitam duplicar a inscrição do mesmo estudante na mesma disciplina, conforme a regra assumida.

Uma consulta pode reconstruir os dados necessários por junções com JOIN:

SELECT e.estudante_nome,
       d.disciplina_nome,
       p.professor_nome,
       i.nota
FROM Inscricao AS i
JOIN Estudante AS e ON e.estudante_id = i.estudante_id
JOIN Disciplina AS d ON d.disciplina_id = i.disciplina_id
JOIN Professor AS p ON p.professor_id = d.professor_id;

A decomposição mantém os fatos em suas relações próprias e permite recuperar a visão combinada. O uso de JOIN é parte normal do trabalho com um esquema relacional; não indica, por si só, um projeto ruim.

Benefícios, limites e decisões de projeto

As três formas normais ajudam a reduzir redundância e anomalias, além de tornar explícitas algumas regras de dependência. Ainda assim, não substituem a modelagem do domínio. Se o professor responsável puder variar por semestre, a regra disciplina_id → professor_id deixa de ser verdadeira sem incluir o semestre — ou outra dimensão temporal — na chave da associação. Uma normalização baseada em uma regra incorreta produz um esquema tecnicamente coerente, mas semanticamente errado.

Normalizar pode aumentar a quantidade de relações e exigir mais junções em certas consultas. Além disso, uma relação em 3FN nem sempre está em forma normal de Boyce-Codd (FNBC). Para este artigo, a progressão termina na 3FN, que é suficiente para apresentar dependências parciais e transitivas, sem afirmar que resolva toda anomalia possível.

Em algumas aplicações analíticas ou de leitura intensiva, pode haver decisão consciente de desnormalizar partes do modelo para simplificar consultas ou melhorar desempenho. Isso deve ser feito depois de definir as regras e medir o custo, preservando mecanismos de consistência. A normalização também não garante que o inventário de dados esteja completo, logo é preciso identificar corretamente quais fatos o sistema deve guardar (Microsoft, s.d.).

Conclusão

O caminho das três formas normais começa por garantir valores atômicos na 1FN, remove dependências parciais de atributos não primos sobre chaves compostas na 2FN e trata dependências transitivas para atingir a 3FN.

No exemplo adotado, a separação de estudante, disciplina, professor e inscrição decorre das dependências funcionais definidas para o domínio. A parte mais importante do processo é justificar cada chave e dependência pelas regras reais, e depois verificar se a decomposição preserva os fatos que a aplicação precisa representar.

Obrigado pela leitura e bons estudos!

Referências

ARAÚJO, Raquel. O que são Formas Normais em Bancos de Dados? In: Hashtag Treinamentos, 2022. Disponível em: www.hashtagtreinamentos.com/o-que-sao-formas-normais-em-bancos-de-dados-sql. Acesso em: 26 out. 2026.

CODD, Edgar F. Further normalization of the data base relational model. In: RUSTIN, Randall J. (ed.). Data base systems. Englewood Cliffs: Prentice-Hall, 1972. (Courant Computer Science Symposia Series, 6).

ELMASRI, Ramez; NAVATHE, Shamkant B. Sistemas de banco de dados. 6. ed. São Paulo: Pearson Addison Wesley, 2011.

HEUSER, Carlos Alberto. Projeto de Banco de Dados. 6 ed. Porto Alegre: Bookman, 2009.

MICROSOFT. Database design basics. Microsoft Support, [s. d.]. Disponível em: https://support.microsoft.com/en-us/access/database-design-basics. Acesso em: 30 out. 2026.