Banco de dados de navegação

Content

Descrição

O acesso à navegação é tradicionalmente associado ao modelo de rede e ao modelo hierárquico do banco de dados, e descreve convencionalmente as APIs de manipulação de dados nas quais registros (ou objetos) são processados ​​um de cada vez, iterativamente. A característica essencial, conforme descrito por Bachman, no entanto, é encontrar registros em virtude de seu relacionamento com outros registros: para que uma interface ainda possa ser navegada se tiver recursos orientados para o conjunto. A partir desse ponto de vista, a principal diferença entre idiomas de manipulação de dados de navegação e idiomas relacionais é o uso de relacionamentos nomeados explícitos, em vez de junções baseadas em valor: para o departamento com nome = "vendas", encontre todos os funcionários em conjunto de departamento-empregados versus encontrar funcionários, departamentos onde funcionário.Department-code = department.code e department.name = "vendas".

Na prática, no entanto, a maioria das APIs de navegação tem sido processual: a consulta acima seria executada usando a lógica processual ao longo das linhas do seguinte pseudo-código:

Obtenha o departamento com nome = 'Sales' First funcionário em conjunto de departamento-empregados.

Nesse ponto de vista, a principal diferença entre as 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 as APIs de navegação instruem o sistema em uma sequência de Etapas como alcançar os registros necessários.

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

Usability: application code quickly becomes unreadable and difficult to debugData independence: application code needs to change whenever the data structure changes

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 internas 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 a colocação física dos dados. É bem possível implementar APIs de navegação sem perseguição de ponteiro de baixo nível (o artigo de Bachman prevê relacionamentos lógicos sendo implementados como em sistemas relacionais, usando chaves primárias e chaves estrangeiras), para que as duas idéias não devem ser conflitadas. Mas sem os benefícios de desempenho dos indicadores de baixo nível, as APIs de navegação se tornam 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 na 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, nos endereços postais. Essa chave composta pode ser considerada como representando um caminho de navegação para um registro; Mas, igualmente, pode ser considerado como uma chave primária simples, permitindo acesso associativo.

Como os sistemas relacionais ganharam destaque na década de 1980, as APIs de navegação (e, em particular, as APIs processuais) foram criticadas e caíram em desuso. Os anos 90, no entanto, trouxeram uma nova onda de bancos de dados orientados a objetos que frequentemente forneciam interfaces declarativas e processuais. Uma explicação para isso é que eles eram frequentemente usados ​​para representar informações estruturadas por gráficos (por exemplo, dados espaciais e dados de engenharia) onde o acesso é inerentemente recursivo: a matemática subjacente ao SQL (especificamente, o cálculo predicado de primeira ordem) não tem poder suficiente para Apoie as consultas recursivas, mesmo aquelas tão simples quanto um fechamento transitivo.

Um exemplo atual de uma API de navegação popular pode ser encontrado no modelo de objeto de documentos (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 que é processual e de navegação. Por outro lado, os mesmos dados (XML ou HTML) podem ser acessados ​​usando o XPath, que podem ser categorizados como declarativos e de navegação: os dados são acessados ​​seguindo os relacionamentos, mas o programa de chamada não emite uma sequência de instruções a serem seguidas em ordem. Idiomas como o SPARQL usados ​​para recuperar dados vinculados da Web semântica também são simultaneamente declarativos e de navegação.

Exemplos

IBM Information Management SystemIDMS

Veja também

CODASYLGraph databaseNetwork databaseObject databaseRelational database