o problema
Em 1970 os sistemas de dados formatados já tinham tabelas de descrição de dados — Codd cita IMS, IDS, TDMS e GIS — e isso era considerado um avanço rumo à independência de dados. O avanço parava cedo. A variedade de características da representação que dava para mudar sem estragar algum programa era pequena, e o modelo com que o usuário interagia continuava entupido de propriedades de representação, principalmente na hora de descrever coleções de dados em vez de itens isolados.
Codd separa três dependências. Ordenação: se os registros de um arquivo estão guardados em ordem crescente de número de peça, os programas assumem que a ordem de apresentação é a ordem armazenada, e quebram quando essa ordem precisa mudar. Índice: do ponto de vista informacional o índice é redundante, existe por desempenho e vai e vem conforme o padrão de acesso muda — mas no IDS o programa precisa nomear as cadeias de índice que usa, e para de funcionar quando elas são removidas. Caminho de acesso: o argumento mais forte do paper. Codd escreve cinco arranjos hierárquicos para o mesmo conjunto de fatos sobre peças, projetos e quantidade comprometida, e observa que um programa escrito para um deles, sem testar qual está em vigor, falha em pelo menos três dos outros quatro — ou referencia um arquivo que não existe, ou deixa de referenciar o arquivo que tem a informação. Manter todo caminho de acesso vivo até o último programa que o usa morrer não é política praticável: o número de caminhos cresce demais.
a ideia
Usar relação no sentido matemático mesmo. Dados os conjuntos S₁…Sₙ, uma relação R de grau n é um conjunto de n-tuplas. O banco inteiro passa a ser uma coleção de relações que variam no tempo, sofrendo inserção, remoção e alteração de componentes. A representação em array de duas dimensões é recurso de exposição, não parte essencial do modelo: ordem de linhas é irrelevante, linhas são distintas, e cada coluna é identificada pelo nome do domínio.
O passo seguinte é o que o leitor de hoje reconhece como óbvio, e não era. Grau 30 não é incomum, diz Codd, e ninguém deveria ser obrigado a decorar a ordem dos domínios de uma relação dessas. Então o usuário não lida com relações ordenadas por domínio, e sim com relationships — a contrapartida sem ordem. Onde dois domínios são iguais, um role name qualifica cada um (sub.part, super.part). Daí sai a exploração simétrica: sabendo que a relação está lá, o usuário espera usar qualquer combinação de argumentos como conhecidos e o resto como incógnitas, porque a informação está lá.
como funciona
Sobre as relações, o paper monta o vocabulário: domínio ativo (os valores presentes num instante), chave primária (o domínio ou combinação que identifica cada tupla, não redundante se nenhum componente é supérfluo), chave estrangeira (domínio que não é chave primária de R mas cujos valores são chave primária de alguma S, possivelmente a própria R). Domínio simples tem valores atômicos; domínio não simples tem relações como elementos — histórico salarial de um empregado, por exemplo.
A normalização elimina os não simples. Comece pela relação no topo da árvore, copie a chave primária dela para dentro de cada relação imediatamente subordinada, apague os domínios não simples do pai, remova o nó e repita:
employee (man#, name, birthdate, jobhistory, children)
jobhistory (jobdate, title, salaryhistory)
salaryhistory (salarydate, salary)
children (childname, birthyear)
vira
employee' (man#, name, birthdate)
jobhistory' (man#, jobdate, title)
salaryhistory' (man#, jobdate, salarydate, salary)
children' (man#, childname, birthyear)Vale se o grafo dos domínios não simples for uma coleção de árvores e nenhuma chave primária tiver componente não simples. O resultado em forma normal é um array sem ponteiro, sem endereçamento hash e sem índice ou lista de ordenação — por isso serve como formato de intercâmbio entre sistemas de representações diferentes.
A seção 2 define as operações: permutação, projeção (πL, que remove as duplicatas resultantes), join e natural join (R*S), composição (a natural é π₁₃ do natural join), restrição e tie. Sobre elas vêm redundância forte (uma projeção derivável de outras, caracterizável por equação) e fraca (não derivável, mas sempre projeção de algum join das outras). Consistência é uma propriedade do estado instantâneo mais um conjunto declarado de restrições.
o que isso custou
Codd é explícito: implementações de sistemas que suportem o modelo relacional não são discutidas. Nem os detalhes linguísticos da sublinguagem. Traduzir pedidos de alto nível em ações eficientes sobre a representação armazenada é chamado de problema de projeto desafiador — que precisa ser resolvido, e o paper não resolve. Exploração simétrica é garantia lógica: “simetria em desempenho não é de se esperar”.
A forma normal apresentada só tira domínios não simples; Codd registra que outras operações de normalização são possíveis e ficam de fora. Redundâncias fracas nascem das necessidades lógicas da comunidade de usuários e não são removíveis pelo administrador. O sistema não consegue deduzir quais redundâncias valem — sem informação semântica, tentar induzi-las é falível, então elas têm que ser declaradas. E verificar consistência a cada inserção, remoção ou atualização de chave, naturalmente, deixa essas operações mais lentas; a alternativa é verificação em lote com um journal das transações. Tirar um retrato instantâneo de relações grandes e muito variáveis tem problemas práticos que o paper diz não discutir.
Há ainda o limite conceitual da definição de consistência: ela não distingue omissão de erro. Inserir (2, 5) em P pode ser um dado correto cujos companheiros em Q e R chegam depois, ou pode ser entrada errada — o sistema não tem como decidir sem interrogar o ambiente, isto é, o usuário.
onde isso aparece hoje
O vocabulário do paper virou o vocabulário do trabalho: chave primária, chave estrangeira, projeção, join, normalização. Bancos relacionais e SQL descendem desta linha, junto com a divisão que Codd propõe entre uma sublinguagem declarativa de dados e uma linguagem hospedeira que faz a computação.
O argumento contra navegação por ponteiro sobreviveu melhor ainda. O connection trap — supor que percorrer todos os caminhos de fornecedor a peça e de peça a projeto entrega o conjunto correto de projetos atendidos por aquele fornecedor — continua acontecendo toda vez que alguém confunde derivar conexões com derivar relações, agora em grafos de objetos e em APIs encadeadas. E a observação de que a forma normal é intercambiável justamente por não ter ponteiro nem índice ecoa em todo formato de troca de dados em massa que se recusa a carregar a estrutura interna de quem o gerou.