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 del Premio Turing de 1973 , The Programmer as Navigator . [1] Este artículo enfatizó el hecho de que los nuevos sistemas de bases de datos basados en disco permitieron al programador elegir rutas de navegación arbitrarias siguiendo relaciones de un registro a otro, contrastando esto con las limitaciones de los anteriores sistemas de cinta magnética y tarjetas perforadas 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 de acceso por navegación llegó a asociarse fuertemente con el diseño de procedimientos del lenguaje de manipulación de datos CODASYL . Por ejemplo, en un escrito de 1982, Tsichritzis y Lochovsky [2] afirman que "la noción de moneda es central para el concepto de navegación". Por 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.
La programación de bases de datos de navegación pasó a ser vista como intrínsecamente procesal ; y además depender del mantenimiento de un conjunto implícito de variables globales ( indicadores monetarios ) que mantienen el estado actual. Como tal, el enfoque se consideró 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 para continuar trabajando a medida que evoluciona la estructura de la base de datos). Como resultado, las interfaces de navegación fueron eclipsadas gradualmente durante el Década de 1980 por lenguajes de consulta declarativos.
Durante la década de 1990 empezó 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 comercial NoSQL . Muchos de estos sistemas introdujeron lenguajes de manipulación de datos que, si bien estaban muy alejados del CODASYL DML con sus indicadores monetarios, podrían entenderse como implementando la visión "navegacional" de Bachman. Algunos de estos lenguajes son procesales; otros (como XPath ) son completamente declarativos. Las derivaciones del concepto de navegación, como la base de datos de gráficos , encontraron nuevos usos en las cargas de trabajo de procesamiento de transacciones modernas .
El acceso por navegación se asocia tradicionalmente con el modelo de red y el modelo jerárquico de base de datos , y convencionalmente describe 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 tanto, una interfaz aún puede ser de navegación si tiene características orientadas a conjuntos. [3] Desde este punto de vista, la diferencia clave entre los lenguajes de manipulación de datos de navegación y los lenguajes relacionales es el uso de relaciones con nombres explícitos 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 de procedimiento: la consulta anterior se ejecutaría utilizando una lógica de procedimiento similar al siguiente pseudocódigo:
obtener departamento con nombre = 'Ventas'obtener el primer empleado en el conjunto de empleados del departamentohasta el final de la serie haz { obtener el siguiente empleado en el conjunto de empleados del departamento 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 lógica o "declarativa" que preguntan al sistema qué buscar, mientras que las API de navegación instruyen al sistema en una secuencia de pasos para alcanzar los registros requeridos.
La mayoría de las críticas a las API de navegación se clasifican 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 interno 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 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 deben 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 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 los URI, en el sistema decimal Dewey y, de hecho, en las direcciones postales. Se puede considerar que dicha clave compuesta representa una ruta de navegación hacia un registro; pero igualmente, puede considerarse como una clave primaria simple que permite el acceso asociativo.
A medida que los sistemas relacionales cobraron 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 una nueva ola de bases de datos orientadas a objetos que a menudo proporcionaban interfaces tanto declarativas como procedimentales. Una explicación para esto es que a menudo se usaban 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 el poder suficiente para Admite 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 objetos de documento (DOM), que se utiliza a menudo en 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 de procedimiento como de navegación. Por el contrario, se puede acceder a los mismos datos ( XML o HTML ) mediante XPath , que se puede clasificar como declarativo y de navegación: se accede a los datos mediante las siguientes relaciones, pero el programa que llama no emite una secuencia de instrucciones a 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.