As 12 Regras de Codd para SEFAZ: entenda o que realmente cai na prova

Quem estuda Banco de Dados para concursos da área fiscal precisa dominar um ponto que costuma ser subestimado: as Regras de Codd. Muita gente olha para esse tema como algo excessivamente teórico, quase “de museu”, mas a verdade é outra. Quando a banca cobra Codd, ela não está testando mera curiosidade histórica. Ela está verificando se o candidato compreende os fundamentos do modelo relacional, isto é, a lógica que sustenta a organização, a integridade e a independência dos dados.

Em provas de SEFAZ, esse tipo de assunto aparece com frequência porque a área fiscal trabalha diretamente com grandes volumes de informação, consistência cadastral, cruzamento de bases e confiabilidade dos registros. Por isso, não basta saber escrever um SELECT. É preciso entender por que o banco relacional foi concebido da forma como foi. E é exatamente aí que entram as regras formuladas por Edgar F. Codd.

Codd propôs um conjunto de regras para definir o que, de fato, deveria ser considerado um sistema gerenciador de banco de dados relacional. Em termos práticos, essas regras buscam garantir que o banco preserve princípios como estrutura lógica consistente, independência entre visão do usuário e armazenamento físico, tratamento adequado de nulos, integridade e manipulação uniforme dos dados. Em prova, a banca raramente cobra as regras de forma totalmente aberta; normalmente, ela insere uma delas em meio a alternativas parecidas e tenta confundir o candidato com formulações técnicas.

Antes de passar uma a uma, guarde uma chave mental: as Regras de Codd sempre caminham no sentido de fortalecer o modelo relacional. Então, quando uma alternativa falar em dependência excessiva de detalhes físicos, flexibilização indevida da integridade ou quebra da uniformidade do sistema, desconfie. Em regra, a resposta certa estará alinhada à ideia de proteção da lógica relacional.

Regra 0: regra fundamental

A primeira é chamada de Regra 0. Ela afirma, em essência, que um sistema só pode ser chamado de relacional se gerenciar o banco de dados inteiramente por seus recursos relacionais.

O que isso quer dizer na prática? Significa que não basta um software guardar dados em tabelas bonitas na interface. Ele precisa operar segundo os princípios do modelo relacional.

Exemplo: imagine um sistema que armazena dados em tabelas, mas várias operações críticas só podem ser feitas por mecanismos externos, fora da lógica relacional do banco. Nesse caso, ele não atenderia plenamente à ideia da Regra 0.

Regra 1: regra da informação

Essa regra estabelece que toda informação do banco deve ser representada de forma explícita e exclusivamente por valores em tabelas, organizadas em linhas e colunas.

Aqui está um dos corações do modelo relacional. Dados devem estar representados de forma tabular, e não escondidos em ponteiros obscuros, estruturas paralelas ou recursos proprietários sem representação relacional clara.

Exemplo: em um cadastro fiscal, o nome do contribuinte, o CPF, a inscrição estadual e a situação cadastral devem aparecer como valores armazenados em atributos de uma relação, e não “embutidos” em códigos internos indecifráveis.

Regra 2: regra do acesso garantido

Cada valor atômico do banco deve ser acessível por meio do nome da tabela, valor da chave primária e nome da coluna.

Isso significa que o dado precisa ser localizado logicamente sem depender de truques de implementação física.

Exemplo: se você deseja recuperar a inscrição estadual de determinado contribuinte, deve conseguir fazê-lo identificando a tabela Contribuinte, a chave daquele registro e a coluna inscricao_estadual.

Essa regra é importante porque reforça a noção de acesso lógico padronizado.

Regra 3: tratamento sistemático de valores nulos

Os valores nulos devem ser tratados de forma sistemática e uniforme, representando ausência de valor, valor desconhecido ou inaplicável.

O ponto central aqui é que nulo não é zero, nulo não é string vazia e nulo não é um valor comum. Ele precisa receber tratamento próprio.

Exemplo: se um contribuinte ainda não teve um campo de data de baixa preenchido, isso pode ser NULL. Esse NULL não significa “01/01/0000”, nem “sem baixa” em texto, mas ausência de valor naquele atributo.

Essa regra cai muito quando a banca tenta confundir o candidato sobre comparações, filtros e semântica de NULL.

Regra 4: catálogo on-line baseado no modelo relacional

O catálogo do banco, isto é, seus metadados, também deve ser acessível pela mesma lógica relacional usada para acessar os dados comuns.

Em outras palavras, a descrição das tabelas, colunas, restrições e demais objetos do banco deve poder ser consultada de forma estruturada.

Exemplo: visualizar definições de colunas, tipos de dados e chaves por consultas ao dicionário de dados do próprio SGBD.

A importância disso para prova é mostrar que o modelo relacional busca coerência: até a informação sobre a estrutura do banco deve seguir lógica organizada.

Regra 5: sublinguagem abrangente de dados

O sistema deve oferecer ao menos uma linguagem completa que permita definição de dados, manipulação, restrições, controle de acesso e transações.

Na prática, essa ideia conversa diretamente com a SQL.

Exemplo: uma linguagem capaz de criar tabela, consultar dados, alterar registros, definir permissões e controlar transações atende a essa lógica. Por isso, quando estudamos SQL com CREATE, SELECT, UPDATE, GRANT, COMMIT e ROLLBACK, estamos vendo reflexos dessa regra.

Regra 6: atualização de visões

Se uma visão for teoricamente atualizável, o sistema deve permitir sua atualização.

A prova gosta desse ponto porque muitos candidatos confundem visão com algo necessariamente “apenas de leitura”. Nem sempre é assim.

Exemplo: suponha uma visão simples construída sobre uma única tabela, sem agregações nem junções complexas. Em certos contextos, ela pode ser atualizável. A regra aponta que, se a atualização fizer sentido lógico, o sistema deve tratá-la adequadamente.

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

O banco deve permitir operações de inserção, atualização e exclusão atuando sobre conjuntos de linhas, e não apenas sobre registros individualizados de forma procedural.

Essa regra é importantíssima para entender a força do paradigma relacional.

Exemplo: quando se executa um comando como:

UPDATE multas_tributarias
SET valor_multa = valor_multa * 0.9
WHERE status = ‘Pendente’;

o banco está realizando uma alteração em conjunto, e não exigindo uma manipulação linha por linha em baixo nível.

Regra 8: independência física de dados

Mudanças na forma física de armazenamento não devem obrigar alteração nas aplicações que usam o banco.

Esse é um dos pontos mais cobrados em prova.

Exemplo: se o administrador cria um índice novo, muda a organização interna dos arquivos ou troca a estratégia física de armazenamento, a consulta feita pela aplicação continua a mesma do ponto de vista lógico.

Para a área fiscal, isso é essencial. Sistemas grandes precisam evoluir internamente sem quebrar toda a camada de uso.

Regra 9: independência lógica de dados

Mudanças lógicas que preservem a informação, dentro de certos limites, não deveriam exigir reescrita generalizada das aplicações.

Ela é mais difícil de implementar plenamente do que a independência física, mas o conceito é clássico em prova.

Exemplo: a criação de uma nova coluna não utilizada por determinada aplicação não deveria obrigar a reformulação de tudo que já funciona.

A banca adora inverter esse princípio e falar em “dependência lógica” como se fosse característica desejável. Não é.

Regra 10: independência de integridade

As restrições de integridade devem ser definidas no catálogo do banco, e não espalhadas apenas no código das aplicações.

Aqui a ideia é fortalecer o controle centralizado da qualidade dos dados.

Exemplo: definir chave primária, chave estrangeira, restrições NOT NULL, UNIQUE e CHECK no banco, em vez de confiar unicamente que o sistema externo “vai validar direito”.

Em ambiente fiscal, isso é especialmente importante porque a confiabilidade do dado não pode depender apenas da boa vontade da aplicação cliente.

Regra 11: independência de distribuição

O usuário não deve precisar saber se o banco está centralizado ou distribuído para manipulá-lo logicamente.

Essa é uma das regras mais lembradas em concursos.

Exemplo: se parte dos dados está em um servidor e outra parte em outro ambiente, a operação lógica do usuário deve permanecer coerente, sem exigir que ele reescreva sua forma de interação apenas por causa da distribuição física.

Essa regra aparece muito em itens objetivos porque tem nome marcante e forte relação com o ideal de transparência do modelo relacional.

Regra 12: não subversão

Se o sistema oferecer uma interface de baixo nível, ela não pode ser usada para contornar as regras de integridade e segurança definidas no nível relacional.

Esse é um fechamento muito importante do raciocínio de Codd: não adianta o banco parecer relacional na superfície e permitir “atalhos” por baixo que violem tudo.

Exemplo: não faria sentido um SGBD impedir duplicidade de chave no uso normal, mas permitir, por uma interface inferior, gravar registros que destruam essa consistência.

Essa regra reforça a seriedade do modelo.

Como isso cai em questão

Agora vejamos um modelo clássico de cobrança:

Questão:
Uma das regras de Codd para o modelo relacional consiste:

A) na dependência de dados físicos.
B) no não tratamento das atualizações de visões.
C) na independência de distribuição.
D) na flexibilização das restrições de integridade por linguagem de baixo nível.
E) na necessidade de acesso aos dados por mecanismos fora do modelo relacional.

Comentário

A alternativa correta é a letra C: independência de distribuição.

As demais erram porque contrariam justamente o espírito das regras de Codd. A ideia nunca é aumentar dependência física, abandonar tratamento de visões, fragilizar integridade ou exigir mecanismos externos para operar o sistema. Ao contrário: as regras existem para preservar uniformidade, integridade, independência e coerência lógica.

Essa é a grande dica de prova: quando a banca trabalhar Regras de Codd, observe a direção da alternativa. Se ela aponta para mais consistência do modelo relacional, há boa chance de estar correta. Se ela sugere quebra, fragilidade ou dependência indevida, provavelmente está errada.

Como memorizar sem decorar mecanicamente

A pior maneira de estudar Codd é tentar decorar as 12 regras como se fossem uma lista seca. O melhor caminho é agrupá-las em blocos de sentido:

• Representação e acesso aos dados: regras 1 e 2. 
• Tratamento consistente do sistema: regras 3, 4 e 5. 
• Operações e visões: regras 6 e 7. 
• Independências do modelo: regras 8, 9, 10 e 11. 
• Proteção contra atalhos destrutivos: regra 12. 

Com isso, a memorização fica muito mais natural.

Fechamento

Para concursos de SEFAZ, estudar as Regras de Codd é estudar a base conceitual do Banco de Dados Relacional. E isso importa porque a área fiscal exige informação íntegra, consistente e logicamente estruturada. A banca sabe disso. Por essa razão, cobra o tema para separar quem apenas viu SQL de quem realmente entende o modelo que está por trás dela.

Se você dominar a lógica das 12 regras, perceberá que esse assunto deixa de ser um bloco teórico distante e passa a funcionar como ferramenta de interpretação de questões. E, em concurso, isso vale muito.