Modelo Relacional

O que mais cai

Do que trata o tópico

O modelo relacional organiza os dados em tabelas ligadas por valores, e é a base dos bancos de dados usados na maior parte dos órgãos públicos e das empresas. O tópico cobre os conceitos do modelo (relação, tupla, atributo, domínio, chaves e restrições), a passagem do diagrama entidade-relacionamento para tabelas, a álgebra relacional, que é a linguagem formal de consulta por trás do SQL, e a normalização, que é a técnica para tirar redundância das tabelas.

Base de referência

• ISO/IEC 9075:2023, padrão da linguagem SQL. É norma paga, e o guia explica o conteúdo com palavras próprias.

Conteúdo

Conceitos e fundamentos do modelo relacional

Pense num setor de pessoal que guarda os dados dos servidores em fichas de papel. Cada ficha tem os mesmos campos (matrícula, nome, cargo), e achar todos os servidores de um cargo exige ler ficha por ficha. O modelo relacional, proposto por Edgar F. Codd, resolve esse problema com uma ideia simples: os dados ficam em tabelas, e as tabelas se ligam pelo valor que elas têm em comum, sem ponteiros nem caminhos fixos.

Na teoria, a tabela se chama relação. Cada linha da relação é uma tupla, e cada coluna é um atributo. O conjunto de valores que um atributo pode receber é o domínio do atributo: o domínio de "idade" pode ser o conjunto dos inteiros de 0 a 130, e o domínio de "UF" pode ser o conjunto das 27 siglas.

A tabela abaixo mostra a correspondência entre os termos formais, os termos do dia a dia e os termos de arquivo, que a banca costuma misturar.

O esquema da relação é a descrição da estrutura: o nome da relação e a lista de atributos, como SERVIDOR(matricula, nome, cpf, cod_setor). A instância, também chamada de estado, é o conjunto de tuplas que a relação tem num dado momento. O esquema muda pouco; a instância muda a cada inclusão, alteração ou exclusão.

O grau da relação é o número de atributos, e a cardinalidade é o número de tuplas. Uma relação com 4 colunas e 1.000 linhas tem grau 4 e cardinalidade 1.000. A troca entre grau e cardinalidade é um erro frequente, e a palavra "cardinalidade" também aparece no modelo entidade-relacionamento com outro sentido (1:1, 1:N, N:N), o que aumenta a confusão.

Propriedades de uma relação.

A relação é um conjunto de tuplas, no sentido matemático. Por isso ela tem propriedades que a tabela de uma planilha não tem:

1. Não há duas tuplas iguais, porque um conjunto não tem elementos repetidos.
2. A ordem das tuplas não tem significado: trocar a ordem das linhas não muda a relação.
3. A ordem dos atributos também não tem significado quando cada atributo é identificado pelo nome.
4. Cada valor de atributo é atômico, isto é, indivisível no modelo: uma célula não guarda uma lista de telefones nem uma tabela dentro dela.

O SQL, que é a linguagem usada na prática, relaxa a primeira propriedade. Uma tabela SQL sem chave primária aceita linhas repetidas, e uma consulta só tira as repetições com DISTINCT. Essa diferença entre o modelo teórico e o SQL é cobrada em prova.

O valor nulo (NULL) representa um valor desconhecido, que não existe ou que não se aplica. Nulo não é zero nem texto vazio. Uma comparação com nulo não dá verdadeiro nem falso, e por isso o SQL usa IS NULL em vez de = NULL.

Chaves.

A chave resolve o problema de identificar uma tupla sem ambiguidade. Há uma sequência de conceitos, do mais amplo ao mais restrito:

1. Superchave: qualquer conjunto de atributos cujo valor não se repete em duas tuplas. Toda relação tem ao menos uma superchave, que é o conjunto de todos os atributos.
2. Chave candidata: superchave mínima, isto é, uma superchave da qual nenhum atributo pode ser retirado sem que ela deixe de identificar a tupla.
3. Chave primária: a chave candidata escolhida pelo projetista para identificar as tuplas.
4. Chave alternativa (ou secundária, em parte da literatura): cada chave candidata que não foi escolhida como primária.
5. Chave estrangeira: atributo (ou conjunto de atributos) de uma relação que faz referência à chave primária de outra relação, ou da mesma relação.

Na relação SERVIDOR(matricula, nome, cpf, cod_setor), tanto {matricula} quanto {cpf} identificam o servidor. As duas são chaves candidatas. O conjunto {matricula, nome} é superchave, mas não é chave candidata, porque sem o nome a matrícula continua identificando a tupla.

Se o projetista escolhe matricula como chave primária, cpf vira chave alternativa. O atributo cod_setor é chave estrangeira se ele referencia a chave primária da relação SETOR(cod_setor, nome_setor). A chave estrangeira pode ter valores repetidos (vários servidores no mesmo setor) e pode aceitar nulo, se o modelo permitir servidor sem lotação.

A chave composta tem mais de um atributo. Na relação ITEM_PEDIDO(num_pedido, cod_produto, quantidade), nenhum dos dois atributos sozinho identifica a linha, porque um pedido tem vários produtos e um produto está em vários pedidos. Só o par {num_pedido, cod_produto} identifica.

Restrições de integridade.

As restrições de integridade são regras que o Sistema Gerenciador de Banco de Dados (SGBD) faz valer em toda inclusão, alteração e exclusão. As principais são estas:

1. Integridade de domínio: o valor de cada atributo pertence ao domínio dele.
2. Integridade de chave: duas tuplas não têm o mesmo valor de chave candidata.
3. Integridade de entidade: nenhum atributo da chave primária aceita nulo, porque um nulo na chave impediria identificar a tupla.
4. Integridade referencial: o valor de uma chave estrangeira é nulo ou é igual a um valor de chave primária que existe na relação referenciada.

A integridade referencial é a que mais cai, porque ela tem efeito nas operações. Se alguém tenta excluir o setor 10 e ainda há servidores com cod_setor 10, o SGBD reage de acordo com a regra definida: recusa a exclusão (RESTRICT ou NO ACTION), exclui também os servidores (CASCADE), põe nulo na chave estrangeira (SET NULL) ou põe um valor padrão (SET DEFAULT).

CREATE TABLE servidor (
  matricula  INTEGER PRIMARY KEY,
  nome       VARCHAR(100) NOT NULL,
  cpf        CHAR(11) UNIQUE NOT NULL,
  cod_setor  INTEGER,
  FOREIGN KEY (cod_setor) REFERENCES setor (cod_setor)
    ON DELETE SET NULL
);

O comando cria a tabela servidor. PRIMARY KEY define a chave primária e já impede nulo e repetição. UNIQUE NOT NULL em cpf faz da coluna uma chave alternativa. A cláusula FOREIGN KEY liga cod_setor à tabela setor, e ON DELETE SET NULL manda pôr nulo nos servidores quando o setor deles for excluído.

Exemplo resolvido: a relação SETOR tem as tuplas (10, Protocolo) e (20, Compras), e a relação SERVIDOR tem a tupla (1, Ana, 11111111111, 10). Diga o que acontece em cada operação.

1. Incluir o servidor (2, Bruno, 22222222222, 30): o SGBD recusa, porque não existe setor 30 e o valor não é nulo (integridade referencial).
2. Incluir o servidor (NULL, Carla, 33333333333, 20): o SGBD recusa, porque a chave primária não aceita nulo (integridade de entidade).
3. Incluir o servidor (3, Davi, 11111111111, 20): o SGBD recusa, porque o cpf repete o de Ana (integridade de chave na chave alternativa).
4. Excluir o setor 10 com a regra ON DELETE SET NULL: o SGBD exclui o setor e põe nulo em cod_setor de Ana.

Na prática, um órgão que registra processos guarda o número do processo como chave primária e o código da unidade responsável como chave estrangeira. Se a unidade é extinta, a regra RESTRICT obriga o órgão a redistribuir os processos antes de apagar a unidade, e assim nenhum processo fica apontando para uma unidade que não existe.

A diferença para o conceito vizinho está entre chave candidata e superchave. Toda chave candidata é superchave, mas nem toda superchave é chave candidata, porque a candidata precisa ser mínima. Outra troca comum é entre integridade de entidade (chave primária sem nulo) e integridade referencial (chave estrangeira apontando para algo que existe).

O erro comum de quem começa é achar que chave estrangeira precisa ser única ou não pode ser nula. Ela pode repetir e, salvo regra em contrário, pode ser nula.

Como a banca cobra: a banca pede a definição de superchave, chave candidata e chave alternativa em casos com chave composta, e testa se a chave estrangeira aceita repetição e nulo. Também troca grau por cardinalidade.

Modelagem e mapeamento ER-relacional

O projeto de um banco começa no modelo conceitual, que é o diagrama entidade-relacionamento (ER), feito para conversar com quem conhece o negócio. O SGBD relacional, porém, só entende tabelas. O mapeamento ER-relacional é o conjunto de regras que transforma cada entidade, atributo e relacionamento do diagrama em relações com chaves primárias e estrangeiras, sem perder informação.

Os elementos do diagrama ER que entram no mapeamento são estes. A entidade forte tem chave própria (SERVIDOR, com matrícula). A entidade fraca não tem chave própria e depende de uma entidade dona para ser identificada (DEPENDENTE de um servidor, identificado pelo nome dentro daquele servidor). O atributo composto se divide em partes (endereço em rua, número e cidade), o multivalorado tem vários valores (telefones) e o derivado é calculado a partir de outro (idade a partir da data de nascimento).

O relacionamento tem uma razão de cardinalidade (1:1, 1:N ou N:N, este último também escrito M:N) e uma participação, que é total quando toda instância da entidade precisa participar e parcial quando não precisa. A cardinalidade decide onde fica a chave estrangeira; a participação decide se ela aceita nulo e, no 1:1, de que lado ela fica.

Os passos do mapeamento.

O algoritmo clássico segue uma ordem fixa, porque cada passo usa as chaves criadas nos passos anteriores:

1. Entidade forte: vira uma relação com todos os atributos simples. O atributo composto entra pelas partes simples, e o derivado em geral não é guardado. A chave do diagrama vira a chave primária.
2. Entidade fraca: vira uma relação com os atributos dela e a chave primária da entidade dona como chave estrangeira. A chave primária da nova relação é a chave da dona somada à chave parcial da fraca.
3. Relacionamento 1:1: a abordagem preferida põe a chave primária de um lado como chave estrangeira no outro, de preferência no lado de participação total, o que evita nulos. Se as duas participações são totais, as duas entidades podem virar uma relação só.
4. Relacionamento 1:N: a chave primária do lado 1 vai como chave estrangeira para a relação do lado N. Os atributos do relacionamento vão junto, para o lado N.
5. Relacionamento N:N: vira uma nova relação, com as chaves primárias das duas entidades como chaves estrangeiras. A chave primária da nova relação é a combinação das duas, e os atributos do relacionamento ficam nela.
6. Atributo multivalorado: vira uma nova relação com a chave primária da entidade (como chave estrangeira) e o atributo. A chave primária da nova relação é a combinação dos dois.
7. Relacionamento de grau maior que 2 (ternário, por exemplo): vira uma nova relação com a chave estrangeira de cada entidade participante, e a chave primária é em geral a combinação delas.

A especialização (SERVIDOR que se divide em EFETIVO e COMISSIONADO) tem várias opções de mapeamento. O projeto pode criar uma relação para a superclasse e uma para cada subclasse, com a mesma chave primária; criar só as relações das subclasses, cada uma com os atributos herdados; ou criar uma relação única com todos os atributos e um atributo de tipo. A escolha depende de as subclasses serem disjuntas ou sobrepostas e de a especialização ser total ou parcial.

Exemplo resolvido: um órgão tem o diagrama abaixo e quer o esquema relacional.

• SETOR(codigo, nome), entidade forte.
• SERVIDOR(matricula, nome, endereco composto de rua e cidade, telefones multivalorado), entidade forte.
• DEPENDENTE(nome, parentesco), entidade fraca, dona SERVIDOR.
• LOTACAO entre SETOR e SERVIDOR, 1:N (um setor tem vários servidores; cada servidor fica em um setor).
• PARTICIPA entre SERVIDOR e PROJETO(cod_projeto, titulo), N:N, com o atributo horas.

1. Passo 1: SETOR(codigo, nome); SERVIDOR(matricula, nome, rua, cidade); PROJETO(cod_projeto, titulo). O endereço entrou pelas partes, e os telefones ficaram para o passo 6.
2. Passo 2: DEPENDENTE(matricula, nome, parentesco), com chave primária {matricula, nome} e matricula como chave estrangeira para SERVIDOR.
3. Passo 4: LOTACAO é 1:N, e o lado N é SERVIDOR. A chave do setor vai para SERVIDOR, que fica SERVIDOR(matricula, nome, rua, cidade, cod_setor).
4. Passo 5: PARTICIPA vira PARTICIPA(matricula, cod_projeto, horas), com chave primária {matricula, cod_projeto}. As horas ficam na nova relação, porque dependem do par servidor e projeto.
5. Passo 6: TELEFONE_SERVIDOR(matricula, telefone), com chave primária {matricula, telefone}.

O resultado tem 6 relações: SETOR, SERVIDOR, PROJETO, DEPENDENTE, PARTICIPA e TELEFONE_SERVIDOR. O diagrama tinha 4 entidades, e as relações a mais vieram do N:N e do multivalorado.

Na prática, se o órgão decide que cada servidor chefia no máximo um setor e cada setor tem exatamente um chefe (1:1 com participação total do lado do setor), a chave estrangeira matricula_chefe vai para SETOR. Se ela fosse para SERVIDOR, a maioria dos servidores, que não chefia nada, ficaria com nulo nessa coluna.

Um relacionamento ternário segue o passo 7. Se o diagrama tem AVALIA entre SERVIDOR, PROJETO e AVALIADOR (cod_avaliador), com o atributo nota, ele vira AVALIA(matricula, cod_projeto, cod_avaliador, nota). Cada uma das três chaves é chave estrangeira para a sua entidade, e a chave primária é {matricula, cod_projeto, cod_avaliador}.

O conceito vizinho que a banca troca é o lado da chave estrangeira. No 1:N ela vai para o lado N; quem põe no lado 1 precisaria de vários valores numa célula, o que quebra a atomicidade. No N:N não há lado certo, e por isso nasce uma relação nova.

O erro comum é guardar o atributo de um relacionamento N:N numa das entidades. As horas de PARTICIPA não são do servidor nem do projeto, são do par, e só a relação nova guarda esse valor sem repetição.

Como a banca cobra: a banca descreve um diagrama e pergunta quantas relações resultam ou onde fica a chave estrangeira. Os casos mais cobrados são o N:N com atributo, o multivalorado e a entidade fraca.

Álgebra relacional

O SGBD precisa de uma forma exata de dizer o que uma consulta faz, sem ambiguidade. A álgebra relacional é essa forma: um conjunto de operações que recebem uma ou duas relações e devolvem uma relação. Como o resultado é sempre uma relação, as operações se encaixam umas nas outras, e uma consulta é uma expressão montada com elas.

A álgebra é procedural, porque a expressão diz a sequência de operações. O cálculo relacional, que a banca às vezes compara com ela, é declarativo: diz o que se quer, não como obter. O SQL mistura as duas ideias, e o otimizador do SGBD traduz a consulta SQL para uma expressão de álgebra antes de executá-la.

Operações unárias.

As operações unárias recebem uma relação só.

1. Seleção (σ, sigma): escolhe as tuplas que atendem a uma condição. Ela filtra linhas e mantém todas as colunas, por isso o grau do resultado é igual ao da entrada e a cardinalidade é menor ou igual. Equivale ao WHERE do SQL.
2. Projeção (π, pi): escolhe atributos. Ela corta colunas e, como o resultado é um conjunto, elimina as tuplas que ficaram repetidas. Equivale à lista do SELECT com DISTINCT.
3. Renomeação (ρ, rô): troca o nome da relação ou dos atributos. Ela serve para usar a mesma relação duas vezes numa expressão, como ao comparar servidores com o chefe deles.

A seleção é comutativa: aplicar σ com a condição A e depois com a condição B dá o mesmo que a ordem inversa, e as duas seleções podem virar uma só com a condição "A e B". A projeção não troca de ordem livremente: depois de projetar só o nome, não há como projetar o salário, que já saiu.

Operações de conjunto.

As operações de conjunto recebem duas relações compatíveis para união, isto é, com o mesmo grau e domínios iguais, coluna a coluna.

1. União (∪): as tuplas que estão em R, em S ou nas duas, sem repetição.
2. Interseção (∩): as tuplas que estão em R e em S.
3. Diferença (−): as tuplas que estão em R e não estão em S. A diferença não é comutativa: R − S é diferente de S − R.

A interseção pode ser escrita com diferenças: R ∩ S = R − (R − S). Por isso ela não faz parte do conjunto mínimo de operações.

Produto cartesiano e junções.

O produto cartesiano (×) combina cada tupla de R com cada tupla de S. Ele não exige compatibilidade. O grau do resultado é a soma dos graus, e a cardinalidade é o produto das cardinalidades.

A junção (⋈) é um produto cartesiano seguido de uma seleção, e é a operação que liga tabelas pela chave estrangeira. As variantes são estas:

1. Junção theta: a condição usa qualquer comparação (=, <, >, ≠, ≤, ≥).
2. Equijunção: a condição usa só igualdade; os dois atributos comparados aparecem no resultado.
3. Junção natural (⋈ sem condição escrita, ou *): iguala os atributos de mesmo nome e mantém só uma cópia de cada um.
4. Junções externas: a da esquerda (⟕) mantém todas as tuplas de R, a da direita (⟖) mantém todas as de S e a completa (⟗) mantém as de ambas. Onde não há par, o resultado recebe nulo.

A junção interna (as três primeiras) perde as tuplas sem par. Essa perda é a razão de existir da junção externa.

A divisão (÷) responde a perguntas com "todos": quais servidores participam de todos os projetos. Ela devolve os valores de R que aparecem combinados com todas as tuplas de S.

O conjunto completo de operações é {σ, π, ∪, −, ×}, com a renomeação quando há nomes repetidos. Interseção, junção e divisão podem ser escritas com essas cinco, e por isso são operações derivadas.

Exemplo resolvido com tabelas.

Exemplo resolvido: as relações SERVIDOR e SETOR têm as tuplas abaixo.

A consulta pedida é o nome do servidor e o nome do setor, para quem ganha mais de 5000: π nome, nome_setor (σ salario > 5000 (SERVIDOR ⋈ SETOR)).

1. Junção natural pelo atributo comum cod_setor: Ana com Protocolo, Bruno com Compras e Carla com Protocolo. Davi (setor 30) sai, porque não há setor 30, e o setor 40 sai, porque não há servidor nele. O resultado tem 3 tuplas e 5 atributos.
2. Seleção com salario > 5000: ficam Ana (6000) e Carla (5200). Bruno (4500) sai.
3. Projeção em nome e nome_setor: o resultado é (Ana, Protocolo) e (Carla, Protocolo).

SELECT DISTINCT s.nome, t.nome_setor
FROM servidor s
JOIN setor t ON t.cod_setor = s.cod_setor
WHERE s.salario > 5000;

A consulta SQL faz a mesma coisa. O JOIN ... ON é a junção, o WHERE é a seleção e o SELECT DISTINCT é a projeção com eliminação de repetidos.

Três contas sobre as mesmas tabelas completam o exemplo:

1. SERVIDOR × SETOR tem grau 4 + 2 = 6 e cardinalidade 4 × 3 = 12.
2. π cod_setor (SERVIDOR) tem 3 tuplas (10, 20 e 30), não 4, porque o 10 repetido aparece uma vez só.
3. SERVIDOR ⟕ SETOR tem 4 tuplas: as 3 da junção natural e Davi, com nulo em nome_setor.

Na prática, a auditoria de um órgão quer saber quais setores cadastrados não têm nenhum servidor. A expressão π cod_setor (SETOR) − π cod_setor (SERVIDOR) dá {10, 20, 40} − {10, 20, 30} = {40}: o Jurídico. As duas projeções têm o mesmo grau e o mesmo domínio, e por isso a diferença é permitida.

Exemplo resolvido da divisão: o órgão quer os servidores que participam de todos os projetos. As tabelas PARTICIPA e PROJETO têm as tuplas abaixo.

A expressão é π matricula, cod_projeto (PARTICIPA) ÷ π cod_projeto (PROJETO).

1. O divisor é {P1, P2}: a lista completa de projetos.
2. A matrícula 1 aparece com P1 e com P2. Ela tem par com todos os projetos e entra no resultado.
3. A matrícula 2 aparece só com P1. Falta P2, e ela sai.
4. A matrícula 3 aparece com P1 e com P2 e entra no resultado.
5. O resultado tem só o atributo matricula, que é o atributo do dividendo que não está no divisor: {1, 3}.

Se o órgão cadastra um projeto P3 sem nenhum participante, o divisor passa a ser {P1, P2, P3} e o resultado fica vazio. A divisão compara com a lista completa do divisor, e por isso a resposta muda quando o divisor muda.

A diferença para o conceito vizinho é a dupla seleção e projeção. A seleção corta linhas (horizontal) e a projeção corta colunas (vertical); a letra grega da seleção é sigma, e a da projeção é pi. Outra troca frequente é entre o produto cartesiano, que combina tudo com tudo, e a junção, que só combina as tuplas que atendem à condição.

O erro comum é esquecer que a projeção elimina repetidos e contar as tuplas como se ela não eliminasse. Outro é aplicar união ou diferença em relações de graus diferentes.

Considere as relações R(A, B) e S(B, C), com estas tuplas: R tem (1, x), (2, y) e (3, x); S tem (x, 10), (x, 20) e (z, 30).

Como a banca cobra: a banca mostra uma expressão com σ, π e ⋈ e pede o resultado sobre tabelas pequenas, ou pede o grau e a cardinalidade do produto e da junção. Também cobra a troca entre seleção e projeção e a compatibilidade exigida pela união e pela diferença.

Normalização

Imagine uma planilha de pedidos em que cada linha repete o nome e o endereço do cliente. Se o cliente muda de endereço, alguém precisa alterar dezenas de linhas, e se esquece uma, o banco passa a ter dois endereços para o mesmo cliente. A normalização é a técnica que decompõe tabelas assim em tabelas menores, para que cada fato fique guardado num lugar só.

A redundância causa três anomalias. A anomalia de inclusão impede cadastrar um fato sem outro (não há como cadastrar um cliente que ainda não fez pedido). A de exclusão apaga um fato junto com outro (excluir o único pedido do cliente apaga o cliente). A de alteração obriga a mudar o mesmo dado em várias linhas, com risco de inconsistência.

Dependência funcional.

A ferramenta da normalização é a dependência funcional. Escreve-se X → Y (X determina Y) quando duas tuplas com o mesmo valor de X têm sempre o mesmo valor de Y. Em SERVIDOR, matricula → nome, porque a mesma matrícula nunca aparece com dois nomes. O lado esquerdo se chama determinante.

A dependência funcional vem do significado dos dados, não de uma instância. Se a tabela de hoje tem um nome por cidade, isso não prova que cidade → nome; basta um segundo servidor na mesma cidade para a dependência cair.

Três tipos de dependência decidem as formas normais:

1. Dependência total: Y depende da chave inteira. Em ITEM_PEDIDO, {num_pedido, cod_produto} → quantidade é total, porque a quantidade precisa do pedido e do produto.
2. Dependência parcial: Y depende só de parte de uma chave composta. Em ITEM_PEDIDO, cod_produto → nome_produto é parcial, porque o nome do produto não precisa do pedido.
3. Dependência transitiva: Y depende da chave por meio de outro atributo que não é chave. Se matricula → cod_setor e cod_setor → nome_setor, então nome_setor depende transitivamente da matrícula.

Um atributo primo é o que faz parte de alguma chave candidata. Os demais são não primos, e as definições de 2FN e 3FN falam deles.

As formas normais.

Cada forma normal exige a anterior e acrescenta uma condição:

1. Primeira forma normal (1FN): todos os atributos são atômicos. Não há atributo multivalorado, composto nem tabela dentro de tabela. A correção cria uma relação nova para o grupo repetido, como TELEFONE_SERVIDOR.
2. Segunda forma normal (2FN): está na 1FN e nenhum atributo não primo depende parcialmente de uma chave candidata. A correção leva o atributo e a parte da chave de que ele depende para uma relação nova.
3. Terceira forma normal (3FN): está na 2FN e nenhum atributo não primo depende transitivamente de uma chave candidata. A correção leva o atributo e o determinante intermediário para uma relação nova.
4. Forma normal de Boyce-Codd (FNBC): em toda dependência funcional não trivial X → Y, o determinante X é superchave. É uma 3FN mais rígida.
5. Quarta forma normal (4FN): está na FNBC e não tem dependência multivalorada não trivial, que aparece quando dois fatos independentes ficam na mesma tabela (os idiomas e os projetos de um servidor).
6. Quinta forma normal (5FN): trata da dependência de junção, quando a tabela só pode ser decomposta sem perda em três ou mais partes.

Uma consequência da 2FN cai muito em prova: uma relação na 1FN cuja chave primária tem um só atributo está automaticamente na 2FN, porque não há parte de uma chave de um atributo só. Isso vale quando essa é a única chave candidata; com outra chave candidata composta, a análise precisa olhar também essa chave.

A diferença entre 3FN e FNBC aparece quando um atributo primo depende de algo que não é superchave. A definição de 3FN aceita X → A quando X é superchave ou quando A é primo. A FNBC não aceita a segunda saída, e por isso toda relação na FNBC está na 3FN, mas nem toda relação na 3FN está na FNBC.

Um caso clássico mostra a diferença. Na relação AULA(aluno, disciplina, professor), cada professor dá uma só disciplina (professor → disciplina) e cada aluno tem um só professor por disciplina ({aluno, disciplina} → professor). As chaves candidatas são {aluno, disciplina} e {aluno, professor}, e por isso todos os atributos são primos e a relação está na 3FN; mas professor → disciplina tem um determinante que não é superchave, e a relação não está na FNBC.

Propriedades da decomposição.

Toda decomposição precisa ter a junção sem perda (também chamada não aditiva): juntar as tabelas novas devolve exatamente a tabela original, sem tuplas a mais. Uma decomposição em duas partes tem essa propriedade quando os atributos comuns às duas partes são chave de pelo menos uma delas.

A preservação de dependências é desejável: cada dependência funcional continua verificável dentro de uma das tabelas novas, sem junção. A 3FN sempre pode ser alcançada com as duas propriedades. A FNBC sempre pode ser alcançada com junção sem perda, mas às vezes perde uma dependência, como no caso AULA.

A desnormalização é a decisão consciente de voltar a juntar tabelas para ganhar desempenho em consulta, comum em bancos analíticos (data warehouse). Ela aceita redundância em troca de menos junções.

Exemplo resolvido: a relação PEDIDO_ITEM(num_pedido, cod_produto, data_pedido, cod_cliente, nome_cliente, nome_produto, quantidade) tem a chave primária {num_pedido, cod_produto} e estas dependências: num_pedido → data_pedido, cod_cliente; cod_cliente → nome_cliente; cod_produto → nome_produto; {num_pedido, cod_produto} → quantidade.

1. 1FN: todos os valores são atômicos. A relação está na 1FN.
2. 2FN: data_pedido e cod_cliente dependem só de num_pedido, e nome_produto depende só de cod_produto. Há dependência parcial, e a relação não está na 2FN.
3. Correção para a 2FN: PEDIDO(num_pedido, data_pedido, cod_cliente, nome_cliente); PRODUTO(cod_produto, nome_produto); ITEM(num_pedido, cod_produto, quantidade).
4. 3FN: em PEDIDO, num_pedido → cod_cliente → nome_cliente é transitiva. PEDIDO não está na 3FN.
5. Correção para a 3FN: PEDIDO(num_pedido, data_pedido, cod_cliente) e CLIENTE(cod_cliente, nome_cliente).

O resultado tem 4 relações: PEDIDO, CLIENTE, PRODUTO e ITEM. Em cada uma, o único determinante é a chave, e por isso todas estão também na FNBC.

A tabela ITEM mostra o efeito: o nome do produto P1 não aparece mais nas duas linhas, e sim uma vez só em PRODUTO. Mudar o nome do produto passou a ser uma alteração em uma linha.

Na prática, um almoxarifado guarda numa tabela só o código do material, a descrição, o código do fornecedor e o telefone do fornecedor. O telefone depende do fornecedor, e não do material, o que é uma dependência transitiva. O projeto em 3FN cria a tabela FORNECEDOR, e a troca de telefone de um fornecedor deixa de exigir a alteração de todos os materiais dele.

Diagnóstico da forma normal, na ordem:
1. Há valor não atômico?               sim -> não está na 1FN
2. Não primo depende de parte da chave? sim -> não está na 2FN
3. Não primo depende de outro não primo? sim -> não está na 3FN
4. Algum determinante não é superchave?  sim -> não está na FNBC

O roteiro acima resume o diagnóstico. A pergunta é feita na ordem. A primeira resposta "sim" mostra a primeira forma normal que a relação não atinge, e a relação está na forma normal anterior a ela. Se a resposta 3 é a primeira "sim", por exemplo, a relação está na 2FN e não está na 3FN nem na FNBC.

A diferença para o conceito vizinho é entre dependência parcial e transitiva. A parcial liga o atributo a uma parte da chave composta e quebra a 2FN; a transitiva liga o atributo a outro atributo não primo e quebra a 3FN. Só existe dependência parcial quando há chave composta.

O erro comum é dizer que uma relação está na 3FN olhando só a 3FN, sem verificar antes a 1FN e a 2FN. Outro erro é concluir que toda relação na 3FN está na FNBC.

Como a banca cobra: a banca dá uma relação com dependências e pergunta em que forma normal ela está ou qual decomposição a corrige. Também cobra a diferença entre 3FN e FNBC e a regra de que chave de um só atributo garante a 2FN.

Quadros e comparações

A tabela compara os tipos de chave pelo papel de cada um.

A tabela compara as operações da álgebra relacional pelo efeito no grau e na cardinalidade.

A tabela resume onde vai cada construção do diagrama ER no mapeamento.

A tabela compara as formas normais pelo que cada uma proíbe.

Para decorar

Pegadinhas

Fontes e data

• [1] ISO/IEC 9075:2023, padrão da linguagem SQL (norma paga, citada só pelo nome e pela edição).

Texto conferido em 14/10/2026.