As 12 Regras de Codd: o que torna um banco de dados realmente relacional?

Quando falamos em bancos de dados relacionais, normalmente pensamos em tabelas, linhas, colunas, chaves primárias, SQL e consultas usando SELECT. Porém, para Edgar Frank Codd, o criador do modelo relacional, isso não era suficiente.

Codd não queria apenas que os bancos de dados parecessem relacionais. Ele queria estabelecer critérios técnicos para dizer se um Sistema Gerenciador de Banco de Dados, ou SGBD, era de fato relacional.

Foi nesse contexto que surgiram as famosas 12 Regras de Codd, publicadas em 1985, em artigos como Is Your DBMS Really Relational? e Does Your DBMS Run By the Rules?, na revista Computerworld. Essas regras serviam como uma espécie de teste de fidelidade ao modelo relacional.

Curiosamente, apesar do nome “12 regras”, elas são geralmente apresentadas com uma Regra Zero, seguida das regras de 1 a 12. Ou seja, na prática temos 13 pontos, mas a tradição manteve o nome “12 Regras de Codd”.

Antes das regras: o que é um SGBD relacional?

Um SGBD relacional é um sistema que organiza os dados usando o modelo relacional. Nesse modelo, os dados são representados em estruturas chamadas relações, que na prática costumamos visualizar como tabelas.

Cada tabela possui:

• linhas, também chamadas de registros ou tuplas;
• colunas, também chamadas de atributos;
• valores, armazenados nas células;
• chaves, usadas para identificar registros e relacionar tabelas.

Por exemplo, uma tabela alunos pode ter colunas como id, nome, email e curso. Outra tabela, chamada matriculas, pode guardar os vínculos entre alunos e disciplinas. O relacionamento entre essas tabelas normalmente ocorre por meio de chaves, como id_aluno.

Mas, para Codd, um banco de dados relacional não deveria depender de atalhos físicos, ponteiros escondidos, arquivos internos ou comandos especiais fora da lógica relacional. O usuário deveria manipular os dados de forma lógica, baseada em relações.

Regra Zero: regra fundamental

A Regra Zero diz que um SGBD só pode ser considerado relacional se gerenciar os dados exclusivamente por meio de suas capacidades relacionais.

Em outras palavras, não basta ter tabelas. O sistema precisa permitir que definição, manipulação, consulta e integridade dos dados sejam feitas dentro do próprio modelo relacional.

Essa regra é importante porque muitos sistemas antigos ou híbridos diziam ser relacionais, mas ainda dependiam de mecanismos internos não relacionais.

Regra 1: regra da informação

Toda informação em um banco de dados relacional deve ser representada de uma única forma: como valores em tabelas.

Isso inclui dados dos usuários e também metadados, como informações sobre tabelas, colunas, permissões e estruturas internas.

Na prática, essa regra reforça uma ideia central: se algo pertence ao banco de dados, deve poder ser tratado como dado relacional.

Regra 2: regra do acesso garantido

Cada valor atômico no banco de dados deve ser acessível por meio de uma combinação lógica de:

• nome da tabela;
• valor da chave primária;
• nome da coluna.

Por exemplo, para encontrar o e-mail de um aluno, eu deveria conseguir chegar até ele sabendo a tabela alunos, o id do aluno e a coluna email.

Essa regra elimina a necessidade de navegar fisicamente por arquivos ou estruturas internas do banco.

Regra 3: tratamento sistemático de valores nulos

O banco de dados deve tratar valores nulos de forma consistente.

Um valor nulo representa ausência de informação, informação desconhecida ou informação ainda não aplicável. Ele não deve ser confundido com zero, string vazia ou espaço em branco.

Por exemplo, se um aluno ainda não informou telefone, isso não significa que o telefone dele seja “0”. Significa apenas que aquela informação está ausente.

Essa regra é muito importante, porque valores nulos afetam consultas, comparações, filtros e regras de integridade.

Regra 4: catálogo relacional ativo

A estrutura do banco de dados deve estar armazenada em tabelas relacionais, acessíveis pela mesma linguagem usada para consultar os dados comuns.

Esse catálogo inclui informações como:

• quais tabelas existem;
• quais colunas pertencem a cada tabela;
• quais tipos de dados são usados;
• quais restrições foram definidas.

Hoje, quando usamos comandos para consultar metadados do banco, estamos vendo uma aplicação prática dessa ideia.

Regra 5: sublinguagem de dados abrangente

O SGBD deve oferecer uma linguagem relacional completa, capaz de realizar várias tarefas importantes, como:

• definição de dados;
• manipulação de dados;
• criação de visões;
• controle de permissões;
• definição de restrições;
• controle de transações.

Na prática moderna, o SQL assumiu esse papel na maioria dos SGBDs relacionais, embora Codd tenha feito várias críticas ao SQL por não ser uma implementação perfeita do modelo relacional.

Regra 6: atualização de visões

As visões, quando teoricamente atualizáveis, devem poder ser atualizadas pelo sistema.

Uma view é uma tabela virtual baseada em uma consulta. Por exemplo, podemos criar uma visão chamada alunos_ativos, mostrando apenas alunos com matrícula ativa.

A regra diz que, se fizer sentido atualizar essa visão sem ambiguidade, o SGBD deve permitir essa atualização.

Nem toda view pode ser atualizada facilmente. Uma view com agregações, agrupamentos ou junções complexas pode gerar dúvidas sobre qual tabela real deveria ser modificada.

Regra 7: inserção, atualização e exclusão em alto nível

O sistema deve permitir operações de inserção, atualização e exclusão em conjuntos de dados, e não apenas registro por registro.

Essa regra é uma das grandes forças do modelo relacional.

Por exemplo, em vez de alterar um aluno por vez, posso fazer:

UPDATE alunos
SET status = 'inativo'
WHERE ultimo_acesso < '2025-01-01';

Esse comando altera todos os alunos que atendem à condição. O foco está no conjunto de dados, não em um laço manual navegando linha por linha.

Regra 8: independência física dos dados

Mudanças na forma física de armazenamento não devem afetar as aplicações.

Por exemplo, o banco pode mudar:

• o arquivo onde os dados são armazenados;
• o índice usado;
• a organização interna das páginas;
• a estratégia de armazenamento em disco.

Mesmo assim, os programas que usam o banco não deveriam precisar ser reescritos.

Essa regra separa a visão lógica dos dados da implementação física.

Regra 9: independência lógica dos dados

Mudanças lógicas na estrutura do banco não devem quebrar aplicações, desde que essas mudanças preservem as informações necessárias.

Por exemplo, se uma tabela for dividida em duas para melhorar a organização, o sistema pode oferecer uma view que mantenha a aparência antiga para as aplicações.

Essa regra é mais difícil de cumprir do que a independência física, porque alterações lógicas mexem diretamente na forma como os dados são compreendidos.

Regra 10: independência de integridade

As regras de integridade devem ser definidas no próprio banco de dados, e não apenas no código da aplicação.

Isso inclui restrições como:

• chave primária;
• chave estrangeira;
• unicidade;
• obrigatoriedade de preenchimento;
• regras de domínio;
• validações estruturais.

Por exemplo, se um pedido precisa obrigatoriamente estar associado a um cliente existente, essa regra deve estar no banco por meio de uma chave estrangeira, e não apenas em uma verificação no backend.

Isso evita inconsistências quando diferentes sistemas acessam o mesmo banco.

Regra 11: independência de distribuição

O usuário não deve precisar saber se os dados estão armazenados em uma única máquina ou distribuídos em vários servidores.

O SGBD deve esconder a complexidade da distribuição.

Por exemplo, uma consulta em uma tabela de clientes deveria funcionar da mesma forma se os dados estivessem em um único servidor ou distribuídos entre diferentes nós.

Essa regra é especialmente interessante hoje, com bancos distribuídos, replicação, clusters e sistemas em nuvem.

Regra 12: regra da não subversão

Se o sistema oferece uma linguagem de baixo nível, ela não pode ser usada para burlar as regras de integridade definidas no nível relacional.

Em outras palavras, não deve existir um “atalho interno” capaz de violar as restrições do banco.

Por exemplo, se existe uma chave estrangeira impedindo a criação de um pedido para um cliente inexistente, nenhuma interface alternativa deveria permitir quebrar essa regra.

Essa regra protege a coerência do banco contra acessos privilegiados ou comandos fora do modelo relacional.

Por que essas regras ainda importam?

As 12 Regras de Codd continuam importantes porque nos ajudam a entender que um banco relacional não é apenas um conjunto de tabelas. Ele é uma forma rigorosa de modelar, consultar, proteger e manipular dados.

Mesmo bancos modernos como PostgreSQL, MySQL, MariaDB, Oracle, SQL Server e SQLite possuem diferenças no grau de aderência ao ideal relacional. A própria literatura técnica costuma observar que nenhum SGBD comercial implementa perfeitamente todas as regras de Codd, mas elas continuam servindo como referência conceitual.

Na prática, essas regras nos ensinam princípios valiosos:

• separar modelo lógico de armazenamento físico;
• evitar dependência de estruturas internas;
• tratar dados como conjuntos;
• proteger integridade dentro do banco;
• usar uma linguagem declarativa;
• garantir independência entre aplicações e estrutura de dados.

Conclusão

As 12 Regras de Codd são mais do que uma lista histórica. Elas são uma base conceitual para entender o que significa um banco de dados ser realmente relacional.

Para quem está aprendendo banco de dados, essas regras ajudam a enxergar além do SQL básico. Para quem já desenvolve sistemas, elas ajudam a tomar melhores decisões de modelagem, integridade, manutenção e arquitetura.

No fim, Codd estava defendendo uma ideia poderosa: os dados devem ser manipulados de forma lógica, consistente e independente da forma como estão fisicamente armazenados.

Essa visão continua extremamente atual, principalmente em um mundo onde aplicações crescem, se distribuem, usam múltiplos serviços e precisam manter dados confiáveis por muitos anos.

Fonte principal

Artigo original referenciado: E. F. Codd — “Is Your DBMS Really Relational?”, publicado na Computerworld em 14 de outubro de 1985. Uma cópia transcrita/referenciada pode ser encontrada no acervo The Thaumatorium, que apresenta o texto com a indicação do artigo original.

Referência complementar: E. F. Codd — “Does Your DBMS Run By the Rules?”, também publicado na Computerworld, em 21 de outubro de 1985.