Banco de dados de navegação - Navigational database

Um banco de dados de navegação é um tipo de banco de dados no qual os registros ou objetos são encontrados principalmente pelas referências a seguir de outros objetos. O termo foi popularizado pelo título do artigo do Prêmio Turing de Charles Bachman de 1973 , The Programmer as Navigator . Este artigo enfatizou o fato de que os novos sistemas de banco de dados baseados em disco permitiram ao programador escolher rotas de navegação arbitrárias seguindo relações de registro para registro, contrastando isso com as restrições dos sistemas anteriores de fita magnética e cartão perfurado, onde o acesso aos dados era estritamente sequencial.

Um dos primeiros bancos de dados de navegação foi o Integrated Data Store (IDS), desenvolvido por Bachman para a General Electric na década de 1960. O IDS tornou-se a base para o modelo de banco de dados CODASYL em 1969.

Embora Bachman tenha descrito o conceito de navegação em termos abstratos, a ideia de acesso navegacional passou a ser fortemente associada ao design procedimental da CODASYL Data Manipulation Language . Escrevendo em 1982, por exemplo, Tsichritzis e Lochovsky afirmam que "A noção de moeda é central para o conceito de navegação". Pela noção de moeda, eles se referem à ideia de que um programa mantém (explícita ou implicitamente) uma posição atual em qualquer sequência de registros que está processando, e que operações como GET NEXT e GET PRIOR recuperam registros relativos a esta posição atual, enquanto também alteram a posição atual para o registro que é recuperado.

Assim, a programação de banco de dados de navegação passou a ser vista como intrinsecamente procedimental ; e, além disso, depender da manutenção de um conjunto implícito de variáveis ​​globais ( indicadores de moeda ) que mantêm o estado atual. Como tal, a abordagem foi vista como diametralmente oposta ao estilo de programação declarativo usado pelo modelo relacional . A natureza declarativa das linguagens relacionais, como SQL, ofereceu melhor produtividade do programador e um nível mais alto de independência de dados (ou seja, a capacidade dos programas de continuarem trabalhando conforme a estrutura do banco de dados evolui). As interfaces de navegação, como resultado, foram gradualmente eclipsadas durante o 1980 por linguagens de consulta declarativas.

Durante a década de 1990, começou a ficar claro que, para certos aplicativos que lidam com dados complexos (por exemplo, bancos de dados espaciais e bancos de dados de engenharia), o cálculo relacional tinha limitações. Naquela época, iniciou-se uma reavaliação de todo o mercado de banco de dados, com várias empresas descrevendo os novos sistemas usando o termo de marketing NoSQL . Muitos desses sistemas introduziram linguagens de manipulação de dados que, embora distantes do CODASYL DML com seus indicadores de moeda, poderiam ser entendidas como implementando a visão "navegacional" de Bachman. Algumas dessas linguagens são procedurais; outros (como XPath ) são totalmente declarativos. Desdobramentos do conceito de navegação, como o banco de dados de gráficos , encontraram novos usos em cargas de trabalho de processamento de transações modernas .

Descrição

O acesso de navegação é tradicionalmente associado ao modelo de rede e ao modelo hierárquico de banco de dados e, convencionalmente, descreve APIs de manipulação de dados nas quais os registros (ou objetos) são processados ​​um de cada vez, de forma iterativa. A característica essencial, conforme descrito por Bachman, no entanto, é encontrar registros em virtude de seu relacionamento com outros registros: portanto, uma interface ainda pode ser de navegação se tiver recursos orientados a conjuntos. Deste ponto de vista, a principal diferença entre as linguagens de manipulação de dados de navegação e as linguagens relacionais é o uso de relacionamentos nomeados explícitos em vez de junções baseadas em valores: for department with name="Sales", find all employees in set department-employees versus find employees, departments where employee.department-code = department.code and department.name="Sales" .

Na prática, entretanto, a maioria das APIs de navegação tem sido procedural: a consulta acima seria executada usando lógica procedural ao longo das linhas do seguinte pseudocódigo:

get department with name='Sales'
get first employee in set department-employees
until end-of-set do {
  get next employee in set department-employees
  process employee
}

Nesse ponto de vista, a principal diferença entre APIs de navegação e o modelo relacional (implementado em bancos de dados relacionais ) é que as APIs relacionais usam técnicas de programação "declarativa" ou lógica que perguntam ao sistema o que buscar, enquanto APIs de navegação instruem o sistema em uma sequência de passos como para alcançar os registros necessários.

A maioria das críticas às APIs de navegação se enquadra em uma de duas categorias:

  • Usabilidade: o código do aplicativo rapidamente se torna ilegível e difícil de depurar
  • Independência de dados: o código do aplicativo precisa mudar sempre que a estrutura de dados muda

Por muitos anos, a principal defesa das APIs de navegação foi o desempenho. Os sistemas de banco de dados que suportam APIs de navegação geralmente usam estruturas de armazenamento interno que contêm links físicos ou ponteiros de um registro para outro. Embora essas estruturas possam permitir uma navegação muito eficiente, elas têm desvantagens porque se torna difícil reorganizar o posicionamento físico dos dados. É perfeitamente possível implementar APIs de navegação sem perseguição de ponteiro de baixo nível (o artigo de Bachman previa relacionamentos lógicos sendo implementados da mesma forma que em sistemas relacionais, usando chaves primárias e chaves estrangeiras), então as duas ideias não devem ser confundidas. Mas sem os benefícios de desempenho dos indicadores de baixo nível, as APIs de navegação tornam-se mais difíceis de justificar.

Os modelos hierárquicos geralmente constroem chaves primárias para registros concatenando as chaves que aparecem em cada nível da hierarquia. Esses identificadores compostos são encontrados em nomes de arquivos de computador ( /usr/david/docs/index.txt ), em URIs, no sistema decimal de Dewey e, nesse caso, em endereços postais. Essa chave composta pode ser considerada como representando um caminho de navegação para um registro; mas, igualmente, pode ser considerada uma chave primária simples que permite o acesso associativo.

À medida que os sistemas relacionais ganharam destaque na década de 1980, as APIs de navegação (e, em particular, as APIs procedurais) foram criticadas e caíram em desgraça. A década de 1990, no entanto, trouxe uma nova onda de bancos de dados orientados a objetos que frequentemente forneciam interfaces declarativas e procedurais. Uma explicação para isso é que eles eram frequentemente usados ​​para representar informações estruturadas em gráfico (por exemplo, dados espaciais e dados de engenharia), onde o acesso é inerentemente recursivo: a matemática que sustenta SQL (especificamente, cálculo de predicado de primeira ordem) não tem poder suficiente para suporta consultas recursivas, mesmo aquelas tão simples como um fechamento transitivo .

Um exemplo atual de uma API de navegação popular pode ser encontrado no Document Object Model (DOM) frequentemente usado em navegadores da web e intimamente associado ao JavaScript . O DOM é essencialmente um banco de dados hierárquico na memória com uma API procedural e de navegação. Por outro lado, os mesmos dados ( XML ou HTML ) podem ser acessados ​​usando XPath , que podem ser categorizados como declarativos e navegacionais: os dados são acessados ​​pelos seguintes relacionamentos, mas o programa de chamada não emite uma sequência de instruções a serem seguidas em ordem. Linguagens como SPARQL usadas para recuperar Dados Vinculados da Web Semântica também são declarativas e navegacionais simultaneamente.

Exemplos

Veja também

Referências

links externos