Base de datos de navegación

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 desde otros objetos. El término se popularizó con el título del artículo de Charles Bachman de 1973 , ganador del Premio Turing , titulado "El programador como navegador" . ^{[ 1 ]} Este artículo enfatizó el hecho de que los nuevos sistemas de bases de datos basados ​​en disco permitían al programador elegir rutas de navegación arbitrarias siguiendo relaciones entre registros, en contraste con las limitaciones de los sistemas anteriores 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 de navegación llegó a asociarse fuertemente con el diseño procedimental del lenguaje de manipulación de datos CODASYL . Por ejemplo, en 1982, Tsichritzis y Lochovsky ^{[ 2 ]} afirman que "La noción de moneda es fundamental 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 NEXTrecuperar GET PRIORregistros en relación con esta posición actual, al tiempo que cambian la posición actual al registro que se recupera.

La programación de bases de datos basada en navegación pasó a considerarse intrínsecamente procedimental y, además, dependiente del mantenimiento de un conjunto implícito de variables globales ( indicadores de cambio ) que almacenaban el estado actual. Por ello, este enfoque se percibía 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 mayor productividad al programador y un mayor nivel de independencia de datos (es decir, la capacidad de los programas para seguir funcionando a medida que evoluciona la estructura de la base de datos). En consecuencia, las interfaces de navegación fueron gradualmente eclipsadas durante la década de 1980 por los lenguajes de consulta declarativos.

Durante la década de 1990, se hizo evidente que, para ciertas aplicaciones que manejaban datos complejos (por ejemplo, bases de datos espaciales y de ingeniería), el cálculo relacional presentaba limitaciones. En ese momento, se inició 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 se alejaban del DML CODASYL con sus indicadores de moneda, podían entenderse como una implementación de la visión "navegacional" de Bachman. Algunos de estos lenguajes son procedimentales; otros (como XPath ) son completamente declarativos. Derivados del concepto de navegación, como las bases de datos de grafos , encontraron nuevos usos en las cargas de trabajo modernas de procesamiento de transacciones .

El acceso de navegación se asocia tradicionalmente con el modelo de red y el modelo jerárquico de base de datos , y convencionalmente describe 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, como la describe 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 nombre explícitas en lugar de uniones basadas en valores: versus . fordepartmentwithname="Sales",findallemployeesinsetdepartment-employeesfind 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 similar al siguiente pseudocódigo:

obtener departamento con nombre = 'Ventas' obtener primer empleado en el conjunto department-employees hasta el final del conjunto hacer { obtener siguiente empleado en el conjunto department-employees procesar empleado }

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 le preguntan al sistema qué debe obtener, mientras que las API de navegación le indican al sistema, mediante una secuencia de pasos, cómo llegar a los registros requeridos.

La mayoría de las críticas a las API de navegación se dividen en dos categorías:

• Usabilidad: el código de la aplicación se vuelve rápidamente ilegible y difícil de depurar.
• Independencia de datos: el código de la aplicación debe cambiar cada vez que cambie la estructura de datos .

Durante muchos años, la principal defensa de las API de navegación fue su 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 entre registros. Si bien estas estructuras pueden permitir una navegación muy eficiente, presentan desventajas, ya que dificultan la reorganización de la ubicación física de los datos. Es perfectamente posible implementar API de navegación sin el seguimiento de punteros de bajo nivel (el artículo de Bachman preveía que las relaciones lógicas se implementaran igual que en los sistemas relacionales, utilizando claves primarias y foráneas), por lo que no deben confundirse ambas ideas. Sin embargo, sin las ventajas de rendimiento que ofrecen los punteros de bajo nivel, resulta más difícil justificar las API de navegación.

Los modelos jerárquicos suelen construir claves primarias para los registros concatenando las claves presentes 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 de clasificación decimal Dewey e incluso en las direcciones postales. Dicha clave compuesta puede considerarse como una ruta de navegación hacia un registro; pero también puede interpretarse como una clave primaria simple que permite el acceso asociativo.

A medida que los sistemas relacionales ganaron protagonismo en la década de 1980, las API de navegación (y en particular, las API procedimentales) fueron criticadas y cayeron en desuso. 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 se usaban con frecuencia para representar información estructurada en grafos (por ejemplo, datos espaciales y datos de ingeniería) donde el acceso es inherentemente recursivo: las matemáticas que originalmente 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 . Las implementaciones más recientes de SQL sí admiten consultas jerárquicas y recursivas .

Un ejemplo actual de una API de navegación popular se encuentra en el Modelo de Objetos del Documento (DOM), utilizado frecuentemente en navegadores web y estrechamente vinculado a JavaScript . El DOM es esencialmente una base de datos jerárquica en memoria con una API tanto procedimental como de navegación. En contraste, 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 siguiendo relaciones, pero el programa que realiza la llamada no emite una secuencia de instrucciones que deban seguirse en orden. Lenguajes como SPARQL , utilizados para recuperar datos enlazados de la Web Semántica, también son simultáneamente declarativos y de navegación.

• Sistema de gestión de información de IBM
• Sistemas de gestión de identidades

• CODASYL
• Base de datos gráfica
• Base de datos de red
• Base de datos de objetos
• Base de datos relacional

• Clasificación de DB-Engines de los sistemas de gestión de bases de datos de navegación por popularidad, actualizada mensualmente.