Resumo TI Banco de Dados: Integridade de Entidade e Integridade Referencial

O resumo anterior fechou o vocabulário formal de domínio, grau e cardinalidade. Agora entram em cena as duas regras que garantem que uma relação — e o banco como um todo — permaneçam consistentes ao longo do tempo, mesmo com INSERTs, UPDATEs e DELETEs acontecendo o tempo todo: integridade de entidade e integridade referencial. Não são sugestões de boa prática, são restrições que o SGBD pode (e deve) impedir que sejam violadas.

Neste resumo, você vai entender exatamente o que cada uma dessas restrições exige, por que chave primária composta é o ponto onde mais gente erra a integridade de entidade, o que de fato acontece quando uma chave estrangeira aponta para “nada”, e como as ações referenciais (CASCADE, SET NULL, SET DEFAULT, RESTRICT, NO ACTION) tratam esse cenário na prática.

🔑 Integridade de entidade

A integridade de entidade exige que nenhum atributo que faça parte da chave primária de uma relação assuma valor nulo. A justificativa é direta: a chave primária é o que garante que cada tupla seja unicamente identificável, e um valor nulo em qualquer parte dela quebraria essa garantia — duas tuplas com chave parcialmente nula não podem ser comparadas de forma confiável para saber se são “a mesma” ou não.

O ponto onde essa regra mais pega candidato desatento é a chave primária composta: a restrição não é “a combinação dos atributos não pode ser nula”, é que cada atributo componente, individualmente, não pode ser nulo. Numa relação Matrícula(aluno_id, disciplina_id, semestre) com chave primária composta por aluno_id e disciplina_id, não basta o par existir — nenhum dos dois pode ser nulo isoladamente, mesmo que o outro esteja preenchido.

Importante também demarcar o alcance da regra: integridade de entidade fala só da chave primária. Atributos que não fazem parte dela podem receber NULL livremente, a menos que exista uma restrição NOT NULL separada definida por regra de negócio.

🔗 Integridade referencial

A integridade referencial exige que todo valor não nulo de chave estrangeira (FK) numa relação referenciante corresponda a um valor existente da chave (em geral a chave primária, mas pode ser qualquer chave candidata com restrição UNIQUE) na relação referenciada. Em outras palavras: uma FK não pode apontar para “nada” — se ela tem valor, esse valor tem que existir do outro lado.

A exceção que mais confunde: chave estrangeira pode ser nula, e isso não viola integridade referencial — significa apenas que, para aquela tupla, o relacionamento é opcional e não está preenchido naquele momento (ex.: Funcionário.gerente_matricula nulo para quem ainda não tem gerente definido). A regra só entra em ação quando a FK tem um valor: aí sim, esse valor precisa existir na relação referenciada.

Referências autorreferenciadas (a FK aponta para a própria relação, como Funcionário.gerente_matricula → Funcionário.matricula) seguem exatamente a mesma regra — não é um caso especial, é a mesma restrição aplicada com relação referenciada igual à referenciante.

⚙️ Ações referenciais

Quando uma tupla referenciada é alterada ou excluída, o SGBD precisa decidir o que fazer com as tuplas que dependem dela via FK. Essa decisão é declarada na própria constraint (ON DELETE / ON UPDATE) e tem cinco comportamentos padrão previstos pelo SQL (embora nem todo SGBD implemente todos):

• CASCADE: propaga a alteração/exclusão para as tuplas dependentes — apagar o “pai” apaga automaticamente todos os “filhos”;
• SET NULL: define a FK das tuplas dependentes como NULL (só é possível se a coluna permitir NULL);
• SET DEFAULT: atribui às tuplas dependentes o valor default definido para a coluna de FK (só funciona se houver um default configurado e ele apontar para um valor válido na relação referenciada);
• RESTRICT: bloqueia a operação no “pai” enquanto existir qualquer “filho” dependente — a exclusão simplesmente falha;
• NO ACTION: semanticamente próximo de RESTRICT (bloqueia se a integridade ficaria violada), mas verificado ao final da instrução/transação, não imediatamente — a diferença prática entre os dois varia por SGBD.

A escolha da ação é uma decisão de projeto, não um detalhe: CASCADE é conveniente mas perigoso em cadeias longas de dependência (um DELETE pode arrastar muito mais dado do que o esperado); RESTRICT é mais seguro contra exclusões acidentais, mas exige que a aplicação trate o erro explicitamente.

⚠️ Pegadinhas comuns

• Integridade de entidade é só sobre chave primária: atributos comuns podem ser nulos sem violar essa regra;
• Em chave composta, cada atributo conta sozinho: não existe “só um dos dois pode ficar nulo” — nenhum componente da PK pode ser nulo;
• FK nula não é erro: viola integridade referencial só quando tem valor e esse valor não existe na relação referenciada — FK nula representa relacionamento opcional não preenchido;
• A relação referenciada precisa ter restrição de unicidade no atributo referenciado: uma FK não pode apontar para um atributo qualquer sem PRIMARY KEY ou UNIQUE do outro lado;
• SET NULL depende da coluna permitir NULL: se a FK também tiver NOT NULL, declarar ON DELETE SET NULL gera conflito de constraints.

🎯 Dica Final para a Prova

Separe as duas regras pelo alvo: integridade de entidade protege a chave primária da própria relação (nunca nula, em nenhum componente); integridade referencial protege a relação entre chave estrangeira e chave referenciada (todo valor de FK não nulo tem que existir do outro lado). Quando a questão citar CASCADE/SET NULL/SET DEFAULT/RESTRICT/NO ACTION, ela está testando ação referencial — ou seja, uma consequência prática da integridade referencial, não da integridade de entidade.

✓ Agora que você domina as duas restrições que mantêm o banco consistente, o próximo passo é ver as restrições de chave em mais detalhe — inclusive a diferença entre chave primária e as demais chaves candidatas que também exigem unicidade.

📍Gostou do conteúdo? Deixe um comentário, compartilhe e continue acompanhando o Dicionário do Concurseiro para mais Resumos de TI – Banco de Dados. Aqui você encontra explicações claras, atualizadas e com foco total no que cai em prova!

👉 Leia também no Dicionário do Concurseiro: Resumo TI Banco de Dados: Restrições de Chave e Unicidade

📘 Chave primária nunca nula, chave estrangeira nula é permitida — decorar essa assimetria entre as duas integridades evita boa parte dos erros de prova sobre o tema. Continue estudando!