Una base de datos de navegación es un tipo de base de datos en la que los registros u objetos se encuentran principalmente siguiendo referencias de otros objetos. El término se popularizó con el título del artículo de Charles Bachman de 1973 para el premio Turing , El programador como navegante . [1] Este artículo enfatizaba el hecho de que los nuevos sistemas de bases de datos basados en discos permitían al programador elegir rutas de navegación arbitrarias siguiendo relaciones de registro a registro, en contraste con las limitaciones de los sistemas anteriores de cinta magnética y tarjeta perforada donde el acceso a los datos era estrictamente secuencial.
Una de las primeras bases de datos de navegación fue Integrated Data Store (IDS), desarrollada por Bachman para General Electric en la década de 1960. IDS se convirtió en la base del modelo de base de datos CODASYL en 1969.
Aunque Bachman describió el concepto de navegación en términos abstractos, la idea del acceso navegacional llegó a asociarse fuertemente con el diseño procedimental del lenguaje de manipulación de datos CODASYL . En 1982, por ejemplo, Tsichritzis y Lochovsky [2] afirman que "la noción de moneda es central para el concepto de navegación". Con la noción de moneda, se refieren a la idea de que un programa mantiene (explícita o implícitamente) una posición actual en cualquier secuencia de registros que esté procesando, y que operaciones como GET NEXTy GET PRIORrecuperan registros relativos a esta posición actual, al mismo tiempo que cambian la posición actual al registro que se recupera.
De esta manera, la programación de bases de datos de navegación pasó a ser vista como intrínsecamente procedimental y, además, dependiente del mantenimiento de un conjunto implícito de variables globales ( indicadores de moneda ) que mantienen el estado actual. Como tal, el enfoque fue visto como diametralmente opuesto al estilo de programación declarativa utilizado por el modelo relacional . La naturaleza declarativa de los lenguajes relacionales como SQL ofrecía una mejor productividad del programador y un mayor nivel de independencia de los datos (es decir, la capacidad de los programas de seguir funcionando a medida que evoluciona la estructura de la base de datos). Como resultado, las interfaces de navegación fueron eclipsadas gradualmente durante la década de 1980 por los lenguajes de consulta declarativos.
Durante la década de 1990, comenzó a quedar claro que para ciertas aplicaciones que manejaban datos complejos (por ejemplo, bases de datos espaciales y bases de datos de ingeniería), el cálculo relacional tenía limitaciones. En ese momento, comenzó una reevaluación de todo el mercado de bases de datos, y varias empresas describieron los nuevos sistemas utilizando el término de marketing NoSQL . Muchos de estos sistemas introdujeron lenguajes de manipulación de datos que, si bien estaban muy alejados del DML de CODASYL con sus indicadores monetarios, podrían entenderse como la implementación de la visión "navegacional" de Bachman. Algunos de estos lenguajes son procedimentales; otros (como XPath ) son completamente declarativos. Las derivaciones del concepto de navegación, como la base de datos gráfica , encontraron nuevos usos en las cargas de trabajo de procesamiento de transacciones modernas .
El acceso navegable se asocia tradicionalmente con el modelo de red y el modelo jerárquico de la base de datos , y describe convencionalmente las API de manipulación de datos en las que los registros (u objetos) se procesan uno a la vez, de forma iterativa. Sin embargo, la característica esencial descrita por Bachman es encontrar registros en virtud de su relación con otros registros: por lo que una interfaz aún puede ser navegable si tiene características orientadas a conjuntos. [3] Desde este punto de vista, la diferencia clave entre los lenguajes de manipulación de datos navegables y los lenguajes relacionales es el uso de relaciones con nombre explícitas en lugar de uniones basadas en valores: for department with name="Sales", find all employees in set department-employeesversus find employees, departments where employee.department-code = department.code and department.name="Sales".
En la práctica, sin embargo, la mayoría de las API de navegación han sido procedimentales: la consulta anterior se ejecutaría utilizando lógica procedimental según las líneas del siguiente pseudocódigo:
Obtener el departamento con nombre='Ventas'Obtener el primer empleado en el conjunto de departamentos-empleadoshasta el final del conjunto hacer { Obtener el siguiente empleado en el conjunto de departamentos-empleados empleado de proceso}Desde este punto de vista, la diferencia clave entre las API de navegación y el modelo relacional (implementado en bases de datos relacionales ) es que las API relacionales utilizan técnicas de programación "declarativa" o lógica que preguntan al sistema qué buscar, mientras que las API de navegación instruyen al sistema en una secuencia de pasos sobre cómo llegar a los registros requeridos.
La mayoría de las críticas a las API de navegación caen en una de dos categorías:
Durante muchos años, la principal defensa de las API de navegación fue el rendimiento. Los sistemas de bases de datos que admiten API de navegación suelen utilizar estructuras de almacenamiento internas que contienen enlaces físicos o punteros de un registro a otro. Si bien estas estructuras pueden permitir una navegación muy eficiente, tienen desventajas porque resulta difícil reorganizar la ubicación física de los datos. Es muy posible implementar API de navegación sin la búsqueda de punteros de bajo nivel (el artículo de Bachman preveía que las relaciones lógicas se implementaran tal como en los sistemas relacionales, utilizando claves primarias y claves externas), por lo que las dos ideas no deberían combinarse. Pero sin los beneficios de rendimiento de los punteros de bajo nivel, las API de navegación se vuelven más difíciles de justificar.
Los modelos jerárquicos suelen construir claves primarias para los registros concatenando las claves que aparecen en cada nivel de la jerarquía. Estos identificadores compuestos se encuentran en los nombres de archivos informáticos ( /usr/david/docs/index.txt), en las URI, en el sistema decimal Dewey y, por cierto, en las direcciones postales. Se puede considerar que una clave compuesta de este tipo representa una ruta de navegación hacia un registro, pero también se puede considerar una clave primaria simple que permite el acceso asociativo.
A medida que los sistemas relacionales adquirieron importancia en la década de 1980, las API de navegación (y en particular, las API de procedimiento) fueron criticadas y cayeron en desgracia. Sin embargo, la década de 1990 trajo consigo una nueva ola de bases de datos orientadas a objetos que a menudo proporcionaban interfaces tanto declarativas como procedimentales. Una explicación de esto es que a menudo se utilizaban para representar información estructurada en gráficos (por ejemplo, datos espaciales y datos de ingeniería) donde el acceso es inherentemente recursivo: las matemáticas que sustentan SQL (específicamente, el cálculo de predicados de primer orden ) no tienen la potencia suficiente para admitir consultas recursivas, incluso aquellas tan simples como un cierre transitivo .
Un ejemplo actual de una API de navegación popular se puede encontrar en el Modelo de Objeto de Documento (DOM) que se utiliza a menudo en los navegadores web y está estrechamente asociado con JavaScript . El DOM es esencialmente una base de datos jerárquica en memoria con una API que es tanto procedimental como de navegación. Por el contrario, se puede acceder a los mismos datos ( XML o HTML ) utilizando XPath , que se puede clasificar como declarativo y de navegación: se accede a los datos siguiendo relaciones, pero el programa que realiza la llamada no emite una secuencia de instrucciones que se deben seguir en orden. Los lenguajes como SPARQL utilizados para recuperar datos vinculados de la Web semántica también son simultáneamente declarativos y de navegación.