As regras de Codd para Bancos de Dados Relacionais

Edgar Frank Codd

Edgar Frank Codd

Dr. Edgar Frank Codd, o criador dos bancos de dados relacionais, publicou uma lista de 12 regras que definem os Sistemas de Banco de Dados Relacional (SBDR) na Computerworld, de 14 e 21 de outubro de 1985, com o título “Is your DBMS Really Relational?” e “Does Your DBMS Run by the Rules?”.

Sua preocupação era que os fornecedores comercializassem seus produtos como relacionais, ainda que não estivessem sendo atendidas as regras mínimas dos padrões. Suas regras servem como modelo de referência sobre o que deve ser um Banco de Dados Relacional.

É muito comum você encontrar publicações falando que são 12 regras, e menos comum sendo 13 regras. O que acontece na verdade, é que são 13 regras que são enumeradas do 0 (zero) até o 12 (doze). Veja abaixo quais são essas regras:

As regras de Codd

Regra Zero: Todas as regras baseiam-se na noção de que para que um Banco de Dados seja considerado Relacional, ele deve utilizar os recursos relacionais exclusivamente para seu gerenciamento.

Regra 1: Informação – Todas as informações de um BDR devem ser representadas logicamente como valores de coluna em linhas dentro das tabelas.

Regra 2: Garantia de Acesso – Deve-se garantir que todos os valores de uma tabela possam ser acessados por meio de uma combinação de nome de tabela, valor de chave primária e nome de coluna.

Regra 3: Tratamento Sistemático de Nulos – Os nulos devem ser representados e tratados de modo sistemático, independente do tipo de dados.

Regra 4: Catálogo On-Line Dinâmico com Base no Modelo Relacional – Os metadados devem ser armazenados e gerenciados como dados comuns, ou seja, em tabelas no interior do BD. Esses dados devem estar disponíveis aos usuários autorizados, utilizando a linguagem relacional padrão do BD.

Regra 5: Sublinguagem Ampla de Dados – O BDR pode suportar várias linguagens. No entanto deve suportar uma linguagem declarativa bem definida com suporte para definição de dados, definição de visualização, manipulação de dados (interativa ou por programa), restrições de integridade, autorização e gerenciamento de transações (iniciar, comprometer e desfazer).

Regra 6: Atualização de Visualização – Qualquer visualização que teoricamente possa ser atualizada deve ser por meio do sistema.

Regra 7: Inserção, atualização e exclusão de alto nível – O BD deve dar suporte à configuração do nível de inserções, atualizações e exclusões. Ou seja, a capacidade de manipular um conjunto de dados através de um comando, deve-se estender às operações de Linguagem de Manipulação de Dados (DML) como insert, update e delete.

Regra 8: Independência Física de Dados – Aplicativos e recursos ad hoc não são afetados logicamente quando os métodos de acesso ou as estruturas de armazenamento físico são alterados.

Regra 9: Independência Lógica de Dados – Aplicativos e recursos ad hoc não são afetados logicamente quando de alterações de estruturas de tabela que preservem os valores originais da tabela (alteração da ordem ou inserção de colunas). Alterações nas relações e nas views causam pouco ou nenhum impacto nas aplicações.

Regra 10: Independência de Integridade – Deve ser possível que todas as restrições de integridade relacional sejam definidas na linguagem relacional e armazenadas no catálogo de sistema, não no nível da aplicação. As aplicações não devem ser afetadas quando ocorrer mudanças nas restrições de integridade.

Regra 11: Independência de Distribuição – Os usuários finais e aplicativos não conhecem nem são afetados pela localização dos dados (BD Distribuídos VS. BD Locais).

Regra 12: Não transposição das Regras – Se o sistema dá suporte a acesso de baixo nível aos dados, não deve haver um modo  de negligenciar as regras de integridade do BD.

Bom amigos, espero que esse post tenha ajudado e estou a disposição para sugestões de outros assuntos. Grande abraço!

Sou bacharel em Sistemas de Informação pela Estácio de Sá (Alagoas), especialista em Gestão Estratégica da Tecnologia da Informação pela Univ. Gama Filho (UGF) e pós-graduando em Gestão da Segurança da Informação pela Univ. do Sul de Santa Catarina (UNISUL). Certificações que possuo: EC-Council CEH, CompTIA (Security+, CySA+ e Pentest+), EXIN (EHF e ISO 27001), MCSO, MCRM, ITIL v3. Tenho interesse por todas as áreas da informática, mas em especial em Gestão e Governança de TI, Segurança da Informação e Ethical Hacking.

Deixe um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *