Los Primeros SABD

Los primeros SABD

La demanda de una mayor capacidad de aplicaciones en computación seguía en aumento y los investigadores se dieron cuenta que incluso los sistemas de archivos indexados eran instrumentos rústicos. Las aplicaciones para procesamiento de pedidos tendían a imponer un modelo jerárquico en sus datos, que corresponde a la naturaleza jerárquica de un pedido con varios elementos de línea y a los productos descritos mediante estructuras de ensamble jerárquico. Estas presiones impulsaron la creación de los primeros sistemas construidos sobre sistemas de archivos, conocidos como sistemas de administración de las bases de datos (SABD). El SABD jerárquico más conocido era IMS (Siglas en inglés: sistema de administración de la información).

Los SABD se basaban en un modelo de datos independiente de cualquier aplicación particular. Esto permitió a los diseñadores de aplicaciones disponer de más tiempo para concentrarse en la arquitectura de su aplicación. El diseño de datos se convirtió en la actividad más importante, lo que provocó un cambio fundamental en el paradigma hacia un modelo de desarrollo orientado por datos. Esto llevó al desarrollo de grupos de aplicaciones relacionados entre sí en los sistemas empresariales, ejecutándose todos bajo un SABD común. A partir de este fenómeno surgieron otras necesidades, como disponer de varias aplicaciones que interactuaran simultáneamente con el SABD y crear aplicaciones de utilerías independientes para el manejo del SABD. Así nacieron los conceptos de control de concurrencia y la mayoría de las actividades conocidas como la administración de la base de datos: respaldo, recuperación, distribución de recursos, seguridad, etc.

Al crecer los sistemas construidos con base en los SABD, también crecieron los problemas, centrados en la reorganización y la navegación. La reorganización era el mayor de los problemas, el modelo conceptual y la implantación física estaban tan íntimamente asociados. Las relaciones jerárquicas y orientadas por los conjuntos se implantaban por lo general al colocar la dirección física de un registro en otro. Durante la reorganización era usual que las grandes bases de datos no estuviesen disponibles durante varios días.

El segundo problema, la navegación, se refiere a la forma en que las aplicaciones están restringidas por el SABD. Cualquier cambio o extensión del modelo invalidaba a muchas aplicaciones y la recopilación no podía resolver el problema. La aplicación debía volverse a escribirse para adecuarla al nuevo modelo.

Las actividades de mantenimiento comenzaron a dominar al nuevo desarrollo y el tiempo necesario para idear nuevas aplicaciones se volvió prohibitivo. Los sistemas actuaban como dinosaurios luchando en pantanos de alquitrán, cada movimiento los hundía más, hasta que desaparecían.

Las bases de datos por relación

Las BDR tenían algunas características importantes que resolvían muchos de los problemas mencionados. El modelo por relación no se basaba en el paradigma particular para la estructuración de los datos, sino en ciertos fundamentos matemáticos. El modelo resultante podía expresar una expresión no redundante de los datos y en conjunto de operadores fijos a partir de los cuales se podían obtener de manera formal. El modelo por relación se podía representar mediante una estructura tabular sencilla y ofrecía un útil formato visual para el despliegue de la información contenida en la base de datos.

Todo el proceso pasaba a un nivel mayor al centrarse las cuestiones importantes en los principios centrales del modelo empresarial. Las BDR representaban los primeros sistemas que proporcionaban una interfaz de aplicación en la cual, se eliminaban del proceso los aspectos de la implantación. Se había logrado uno de los objetivos principales de la tecnología de las bases de datos: Los datos eran independientes del proceso.

Este modelo define tres tipos de datos: la tabla (relación), la hilera (n-ada o n-uplo) y la columna (atributo). El modelo especifica tres modelos de las tablas: seleccionar, proyectar y unir. Proyectar especifica un subconjunto de las columnas definidas en una tabla. Regresa una nueva tabla que contiene todas las hileras originales junto con aquellas que corresponden a los valores de la columna especificados por la proyección. El operador unir combina dos tablas para producir una tabla única. Esta tabla representa el producto cartesiano de todas las tablas que conforman la unión. Así, un operador booleano compara una columna de la tabla original y el resultado de la unión es una nueva tabla que contiene aquellas hileras para las que el operador booleano regresa el valor de verdadero.

Otra razón más la constituyen los modernos ambientes de desarrollo de aplicaciones originados por la BDR, sobre todo para los lenguajes de cuarta generación, estos se caracterizan por un lenguaje con operadores de una base de datos ya integrados y tal vez el formato de informe. Esto simplifica el proceso de desarrollo de aplicaciones y reduce el tiempo necesario para terminar una nueva aplicación.

Base de datos activas

La base de datos por relación clásica era pasiva. Solo almacenaba datos de manera independiente a los procesos. El concepto de base de datos activa fue evolucionando hasta una parte que realizara ciertas acciones de manera automática cuando se intentase leer o actualizar los datos. El sistema de administración cambió de modo que aplicara controles de seguridad, controles de integridad o cálculos automáticos. Esto se hizo en Sibase, y era de utilidad paras una base de datos en un sistema de cliente-despachador, donde los clientes eran desconocidos.

Base con conocimiento

El mundo de la inteligencia artificial produjo otra forma de base de datos activa. Se deseaba que almacenara conocimiento. El conocimiento se consideraba activo, mientras que los datos eran pasivos. Este poderoso concepto se aplicó exitosamente a ciertos problemas altamente complejos.

Base de datos orientada a objetos

Las bases de datos orientadas a objetos surgieron en un principio para soportar la programación orientada a objetos. Los programadores de Smalltalk y C++ necesitaban almacenar datos persistentes, datos que permanecen después de terminado un proceso. Las BDOO se volvieron importantes para ciertos tipos de aplicaciones con datos complejos: CAD (Diseño apoyado por computadora) y CAE (Ingeniería apoyada por computadora). También para el manejo de los BLOB (Objetos binarios de gran tamaño: imágenes, sonido, video y texto sin formato).

Las BDOO representan el siguiente

...