Tweet

As 12 Regras de Codd para Sistemas de Bancos de Dados Relacionais

As Doze Regras de Codd são um conjunto de (na verdade) treze regras (enumeradas de zero a doze) publicadas pelo cientista da computação Edgar F. Codd em outubro de 1985, com o intuito de definir o que é necessário para que um sistema de gerenciamento de banco de dados possa ser considerado realmente um sistema relacional, ou seja, um SGBDR.

Edgar Frank “Ted” Codd (19 de agosto de 1923 – 18 de abril de 2003) foi um cientista da computação inglês que, enquanto trabalhava para a IBM, inventou o modelo relacional para gerenciamento de banco de dados, a base teórica para bancos de dados relacionais e sistemas de gerenciamento de banco de dados relacionais.

À medida que o modelo relacional de bancos de dados se popularizou no início dos anos 1980, Codd travou uma campanha por vezes complicada para evitar que o termo fosse mal utilizado por fornecedores de bancos de dados que apenas acrescentaram um verniz relacional à tecnologias mais antigas.

Como parte desta campanha, ele publicou suas 12 regras para definir o que constituía um banco de dados relacional. Isso tornou sua posição na IBM cada vez mais difícil, e então ele saiu para formar uma empresa de consultoria com Christopher J. Date e outros.

A seguir trago o texto integral traduzido para o português com as 12 regras mais a regra 0, de acordo como publicado em duas matérias na revista Computerworld no mês de outubro de 1985: “Is your DBMS really relational?“, Computerworld. 14/10/1985, Vol. 19, e “Does your DBMS run by the rules?“, Computerworld. 21/10/1985, Vol. 19.

Texto integral traduzido das 12 Regras de Codd

As 12 regras
Por E. F. Codd
Outubro 1985

Doze regras são citadas abaixo como parte de um teste para determinar se um produto que se afirma ser totalmente relacional o é realmente. O emprego do termo “totalmente relacional” neste relatório é ligeiramente mais rigoroso do que no meu artigo de Turing (escrito em 1981). Isso ocorre em parte porque os fornecedores em seus anúncios e manuais traduziram o termo “minimamente relacional” para “totalmente relacional” e em parte porque neste relatório estamos lidando com SGBDs relacionais e não com sistemas relacionais em geral, o que incluiria meros sistemas de relatórios de consultas.

No entanto, as 12 regras tendem a explicar porque é que o suporte total ao modelo relacional é do interesse dos usuários. Nenhum novo requisito é adicionado ao modelo relacional. Posteriormente, um esquema de notas é definido e utilizado para medir o grau de fidelidade ao modelo relacional.

Primeiro, defino essas regras. Embora eu tenha definido cada regra em artigos anteriores, acredito que esta seja a primeira ocorrência de todas as 12 juntas.

Nas regras de oito a 11, especifico e exijo quatro tipos diferentes de independência destinados a proteger os investimentos dos clientes em programas de aplicação, atividades de terminal e treinamento. As regras oito e nove — independência física e lógica dos dados — têm sido amplamente discutidas há muitos anos.

As regras 10 e 11 — independência de integridade e independência de distribuição — são aspectos da abordagem relacional que não receberam atenção adequada até à data, mas que provavelmente se tornarão tão importantes quanto a oito e a nove.

Estas regras se baseiam em uma única regra fundamental, que chamarei de Regra Zero:

Regra Zero.
Regra 0: Para qualquer sistema anunciado como, ou que se alega ser, um sistema de gerenciamento de banco de dados relacional, esse sistema deve ser capaz de gerenciar bancos de dados inteiramente por meio de suas capacidades relacionais.

Esta regra deve ser válida quer o sistema suporte ou não quaisquer capacidades não relacionais de gerenciamento de dados. Qualquer SGBD que não satisfaça esta Regra Zero não vale a pena ser classificado como um SGBD relacional.

Uma consequência desta regra: qualquer sistema que se alega ser um SGBD relacional deve suportar inserção, atualização e exclusão em banco de dados no nível relacional (múltiplos registros por vez). Outra consequência é a necessidade de dar suporte à regra da informação e à regra do acesso garantido.

“Múltiplos registros por vez” inclui como casos especiais aquelas situações em que zero ou um registro é recuperado, inserido, atualizado ou excluído. Em outras palavras, uma relação (tabela) pode ter zero tuplas (linhas) ou uma tupla e ainda assim ser uma relação válida.

Qualquer declaração nos manuais de um sistema alegado ser um SGBD relacional que aconselhe os usuários a reverter para algumas capacidades não relacionais “para alcançar um desempenho aceitável” – ou por qualquer razão que não seja a compatibilidade com programas escritos no passado em sistemas de banco de dados não relacionais – deve ser interpretado como uma desculpa do fornecedor. Tal afirmação indica que o fornecedor não realizou o trabalho necessário para alcançar um bom desempenho com a abordagem relacional.

Qual é o perigo para compradores e usuários de um sistema que é considerado um SGBD relacional e que falha na Regra Zero?

Compradores e usuários esperarão todas as vantagens de um SGBD verdadeiramente relacional e não conseguirão obter essas vantagens. Agora descreverei as 12 regras que, juntamente com os nove recursos estruturais, 18 manipulativos e três de integridade do modelo relacional, determinam em detalhes específicos a extensão da validade da reivindicação de um fornecedor de ter um “SGBD totalmente relacional”.

Todas as 12 regras são motivadas pela Regra Zero definida acima, mas um SGBD pode ser verificado mais facilmente quanto à conformidade com essas 12 do que com a Regra Zero.

A regra da informação.
Regra 1: Todas as informações em um banco de dados relacional são representadas explicitamente no nível lógico e exatamente de uma maneira — por valores em tabelas.

Até mesmo nomes de tabelas, nomes de colunas e nomes de domínio são representados como cadeias de caracteres em algumas tabelas. As tabelas que contêm esses nomes normalmente fazem parte do catálogo interno do sistema. O catálogo é, portanto, uma base de dados relacional em si – dinâmica e ativa e que representa os metadados (dados que descrevem o restante dos dados no sistema). A regra de informação é aplicada não apenas para a produtividade do usuário, mas também para tornar um trabalho razoavelmente simples para os fornecedores de software definir pacotes de software adicionais (como auxílios ao desenvolvimento de aplicativos, sistemas especialistas e assim por diante) que fazem interface com SGBD relacionais e, por definição, estão bem integrados ao SGBD.

Ou seja, esses pacotes recuperam informações já existentes no catálogo e, conforme a necessidade, colocam novas informações no catálogo pelo próprio ato de utilizar o SGBD.

Uma razão adicional para aplicar esta regra é tornar a tarefa do administrador da base de dados de manter a base de dados num estado de integridade geral mais simples e mais eficaz. Não há nada mais embaraçoso para um administrador de base de dados do que ser questionado se a sua base de dados contém certas informações específicas e ele responder, após uma semana de exame da base de dados, que ele não sabe.

Regra de acesso garantido.
Regra 2: É garantido que todo e qualquer dado (valor atômico) em um banco de dados relacional seja logicamente acessível recorrendo a uma combinação de nome de tabela, valor de chave primária e nome de coluna.

Claramente, cada dado em um banco de dados relacional pode ser acessado em uma rica variedade – possivelmente milhares – de maneiras logicamente distintas. No entanto, é importante ter pelo menos uma forma, independente da base de dados relacional específica, que seja garantida, porque a maioria dos conceitos orientados para o computador (como a varredura de endereços sucessivos) foram deliberadamente omitidos do modelo relacional.

Observe que a regra de acesso garantido representa um esquema de endereçamento associativo exclusivo do modelo relacional. A regra não depende em nada do endereçamento usual orientado por computador. No entanto, o conceito de chave primária é uma parte essencial dele.

Tratamento sistemático de valores nulos.
Regra 3: Valores nulos (distintos da sequência de caracteres vazia ou de uma sequência de caracteres em branco e distintos de zero ou qualquer outro número) são suportados em SGBDs totalmente relacionais para representar informações ausentes e informações inaplicáveis de forma sistemática, independente do tipo de dados.

Para suportar integridade do banco de dados, deve ser possível especificar “nulos não permitidos” para cada coluna de chave primária e para quaisquer outras colunas onde o administrador do banco de dados considere uma restrição de integridade apropriada (por exemplo, certas colunas de chave estrangeira).

As técnicas anteriores envolviam a definição de um valor especial (peculiar a cada coluna ou campo) para representar a informação faltante. Isto seria muito assistemático em um banco de dados relacional porque os usuários teriam que empregar técnicas diferentes para cada coluna ou domínio — uma tarefa difícil devido ao alto nível de linguagem em uso (e uma tarefa que acredito que diminuiria a produtividade do usuário).

Catálogo on-line dinâmico baseado no modelo relacional.
Regra 4: A descrição do banco de dados é representada no nível lógico da mesma forma que os dados comuns, de modo que os usuários autorizados possam aplicar à sua interrogação a mesma linguagem relacional que aplicam aos dados regulares.

Uma consequência disso é que cada usuário (seja um programador de aplicação ou um usuário final) precisa aprender apenas um modelo de dados – uma vantagem que os sistemas não relacionais geralmente não oferecem (o IMS da IBM, juntamente com seu dicionário, exige que o usuário aprenda dois modelos de dados distintos).

Outra consequência é que os usuários autorizados podem facilmente estender o catálogo para se tornar um dicionário de dados relacional ativo e completo sempre que o fornecedor não o fizer.

Regra abrangente de sublinguagem de dados.
Regra 5: Um sistema relacional pode suportar diversas linguagens e vários modos de uso de terminal (por exemplo, o modo de preencher as lacunas). No entanto, deve haver pelo menos uma linguagem cujas instruções sejam expressáveis, de acordo com alguma sintaxe bem definida, como cadeias de caracteres e que seja abrangente no suporte a todos os itens a seguir:

• Definição de dados.
• Definição de Views.
• Manipulação de dados (interativa e por programa).
• Restrições de integridade.
• Autorização.
• Limites de transação (início, confirmação e reversão).

A abordagem relacional é altamente dinâmica de forma intencional — ou seja, raramente será necessário interromper a atividade do banco de dados (em contraste com um SGBD não relacional). Portanto, não faz sentido separar os serviços listados acima em linguagens distintas.

Em meados dos anos 70, o Comitê de Planejamento e Requisitos de Padrões Ansi gerou um documento defendendo 42 interfaces distintas e (potencialmente) 42 linguagens distintas para SGBD. Felizmente, essa ideia aparentemente foi abandonada.

Regra de atualização de visões
Regra 6: Todas as visões que são teoricamente atualizáveis também são atualizáveis pelo sistema.

Observe que uma visão é teoricamente atualizável se existir um algoritmo independente de tempo para determinar inequivocamente uma única série de mudanças nas relações de base que terão como efeito precisamente as mudanças solicitadas na visão. A este respeito, “atualização” pretende incluir inserção e exclusão, bem como modificação.

Inserção, atualização e exclusão de alto nível.
Regra 7: A capacidade de tratar uma relação base ou uma relação derivada como um único operando aplica-se não apenas à recuperação de dados, mas também à inserção, atualização e exclusão de dados.

Este requisito dá ao sistema muito mais espaço para otimizar a eficiência de suas ações em tempo de execução. Ele permite que o sistema determine quais caminhos de acesso explorar para obter o código mais eficiente. Também pode ser extremamente importante para obter um tratamento eficiente de transações em um banco de dados distribuído. Neste caso, os usuários prefeririam que os custos de comunicação fossem poupados, evitando a necessidade de transmitir um pedido separado para cada registro obtido de locais remotos.

Independência física de dados.
Regra 8: Os programas aplicativos e as atividades do terminal permanecem logicamente inalterados sempre que qualquer alteração é feita nas representações de armazenamento ou nos métodos de acesso.

Para lidar com isso, o SGBD deve suportar uma fronteira clara e nítida entre os aspectos lógicos e semânticos, por um lado, e os aspectos físicos e de desempenho das tabelas base, por outro; os programas aplicativos devem lidar apenas com os aspectos lógicos.

SGBDs não relacionais raramente fornecem suporte completo para esta regra – na verdade, não conheço nenhum que o faça.

Independência lógica de dados.
Regra 9: Os programas aplicativos e as atividades de terminal permanecem logicamente intactos quando alterações de qualquer tipo que preservem informações e que teoricamente permitam a integridade são feitas nas tabelas base.

Tomemos os dois exemplos a seguir: dividir uma tabela em duas tabelas, seja por linhas usando conteúdo de linha ou por colunas usando nomes de coluna, se as chaves primárias forem preservadas em cada resultado; ou combinar duas tabelas em uma por meio de uma junção sem perdas (os autores da Universidade de Stanford e do MIT chamam essas junções de “sem perdas”). Para fornecer este serviço sempre que possível, o SGBD deve ser capaz de lidar com inserções, atualizações e exclusões em todas as visões que são teoricamente atualizáveis. Esta regra permite que o design do banco de dados lógico seja alterado dinamicamente se, por exemplo, tal alteração melhorar o desempenho.

As regras de independência de dados físicos e lógicos permitem que os projetistas de bancos de dados para SGBDs relacionais cometam erros em seus projetos sem as pesadas penalidades impostas pelos SGBDs não relacionais. Isso, por sua vez, significa que é muito mais fácil começar com um SGBD relacional porque não é necessário tanto planejamento orientado ao desempenho antes da “decolagem”.

Independência de integridade.
Regra 10: As restrições de integridade específicas de um banco de dados relacional em particular devem ser definíveis na sublinguagem de dados relacionais e armazenáveis no catálogo, e não nos programas aplicativos.

Além das duas regras de integridade (integridade de entidade e integridade referencial) que se aplicam a todos os bancos de dados relacionais, há uma necessidade clara de poder especificar restrições de integridade adicionais que reflitam políticas de negócios ou regulamentações governamentais.

Suponha que o modelo relacional seja refletido fielmente. Então, as restrições de integridade adicionais são definidas em termos da sublinguagem de dados de alto nível e das definições armazenadas no catálogo, não nos programas aplicativos. Informações sobre objetos identificados inadequadamente nunca são registradas em um banco de dados relacional. Para ser mais específico, as duas regras de integridade a seguir se aplicam a todos os bancos de dados relacionais:

• Integridade da entidade. Nenhum componente de uma chave primária pode ter um valor nulo.
• Integridade referencial. Para cada valor de chave estrangeira não nulo distinto em um banco de dados relacional, deve existir um valor de chave primária correspondente do mesmo domínio.

Se, como às vezes acontece, as políticas empresariais ou as regulamentações governamentais mudarem, provavelmente será necessário alterar as restrições de integridade. Normalmente, isso pode ser feito em um SGBD totalmente relacional, alterando uma ou mais instruções de integridade armazenadas no catálogo.

Em muitos casos, nem os programas aplicativos nem as atividades do terminal são prejudicadas logicamente.

SGBDs não relacionais raramente suportam esta regra como parte do mecanismo do SGBD, ao qual ela pertence. Em vez disso, eles dependem de um pacote de dicionário, que pode ou não estar presente e pode ser facilmente ignorado.

Independência de distribuição.
Regra 11: Um SGBD relacional possui independência de distribuição.

Por independência de distribuição, quero dizer que o SGBD possui uma sublinguagem de dados que permite que programas aplicativos e atividades de terminal permaneçam logicamente intactos:

• Quando a distribuição de dados é introduzida pela primeira vez (se o SGBD instalado originalmente gerencia apenas dados não distribuídos);
• Quando os dados são redistribuídos (se o SGBD gerencia dados distribuídos).

Note que a definição é cuidadosamente redigida para que tanto o SGBD distribuído quanto o não distribuído possam suportar totalmente a Regra 11. O SQL/DS e DB2 da IBM, Oracle Corp. da Oracle e Ingres da Relational Technology, Inc. (todos não distribuídos nos releases atuais) suportam totalmente esta regra.

Isso foi demonstrado da seguinte forma: programas SQL foram escritos para operar em dados não distribuídos (usando o System R), rodam corretamente em versões distribuídas desses dados (usando System R*, o protótipo do IBM San Jose Research Laboratory), e o projeto distribuído Ingres na Universidade da Califórnia em Berkeley mostrou a mesma capacidade para a linguagem Quel de Ingres.

É importante distinguir o processamento distribuído dos dados distribuídos. No primeiro caso, o trabalho (por exemplo, programas) é transmitido aos dados; neste último caso, os dados são transmitidos para o trabalho. Muitos DBMS não relacionais suportam processamento distribuído, mas não dados distribuídos. Os únicos sistemas que suportam o conceito de fazer com que todos os dados distribuídos pareçam locais são SGBDs relacionais – estes são protótipos no momento.

No caso de um SGBD relacional distribuído, uma única transação pode abranger vários locais remotos. Isso é gerenciado inteiramente nos bastidores – o sistema pode ter que executar a recuperação em vários locais. Cada programa ou atividade de terminal trata a totalidade dos dados como se fossem todos locais do site onde o programa aplicativo ou atividade de terminal está sendo executado.

Um SGBD totalmente relacional que não suporta bancos de dados distribuídos tem a capacidade de ser estendido para fornecer esse suporte, deixando os programas aplicativos e as atividades do terminal logicamente intactos, tanto no momento da distribuição inicial quanto sempre que a redistribuição posterior for feita.

Existem quatro razões importantes pelas quais um SGBD relacional desfruta desta vantagem:

• Flexibilidade de decomposição na decisão de como implantar os dados.
• Poder de recomposição dos operadores relacionais ao combinar os resultados de subtransações executadas em diferentes sites.
• Economia de transmissão resultante do fato de não ser necessário enviar uma mensagem de solicitação para cada registro a ser recuperado de qualquer site remoto.
• Analisabilidade da intenção (devido ao nível muito alto das linguagens relacionais) para uma otimização de execução amplamente melhorada.

Regra de não subversão.
Regra 12: Se um sistema relacional tiver uma linguagem de baixo nível (registro único por vez), esse baixo nível não pode ser usado para subverter ou contornar as regras e restrições de integridade expressas na linguagem relacional de nível superior (múltiplos registros por vez).

Na abordagem relacional, a preservação da integridade é independente da estrutura lógica de dados para alcançar a independência da integridade. Esta regra é extremamente difícil para um sistema “nascido de novo” obedecer porque tal sistema já suporta uma interface abaixo da interface de restrição relacional. Os fornecedores de sistemas “nascidos de novo” não parecem ter dado a devida atenção a este problema.

Essas foram as 12 regras de Codd para sistemas de bancos de dados relacionais. Note que, embora essas regras fossem bastante válidas para a época da publicação dos artigos, sua intenção e seu público, hoje em dia é mais apropriado levar em consideração os artigos batizados de “O Terceiro Manifesto”, escritos por Christopher J. Date e Hugh Darwen sobre o modelo relacional, que podem ser acessados em http://thethirdmanifesto.com.

Fonte do texto e referências: https://reldb.org/c/index.php/twelve-rules/

Colabore com a Bóson Treinamentos

Ajude o canal adquirindo meus cursos na Udemy:

• Bancos de Dados com MySQL Básico: https://bit.ly/35QdWE4
• Lógica de Programação com Português Estruturado: https://bit.ly/3QKPn22
• Programação em Python do Zero: https://bit.ly/python-boson

Adquira também livros e outros itens na loja da Bóson Treinamentos na Amazon e ajude o canal a se manter e crescer: https://www.amazon.com.br/shop/bosontreinamentos