HISTORIA DE LAS COMP

HISTORIA DE LAS BASES DE DATOS

En la entrada anterior vimos cómo comenzaron a usarse los PC’s en la empresa (y poco después en todos lados). Otro de los hitos tecnológicos que tuvieron lugar a mediados de la década de los ochenta del siglo pasado fue la irrupción en el mercado de las Bases de Datos Relacionales, sin las que hoy en día no podríamos entender la informática, y a relatar cómo comenzaron a ser lo que hoy en día son me voy a dedicar en esta entrada y la siguiente.

En esta entrada de hoy, sin embargo, y por razones de espacio, no voy a hablar de Bases de Datos Relacionales, de las que sí que hablaré en la próxima, sino que me centraré en los antecedentes: daremos un repaso a la historia de las Bases de Datos, mejor dicho, de los Sistemas de Gestión de Base de Datos que existían en el momento (sobre 1984-85). Es más, comenzaremos incluso antes, por conocer cómo eran las técnicas de almacenamiento de la información antes de que existieran las Bases de Datos (de cualquier tipo), o cuando sí que existían, pero, debido a sus limitaciones, no se podían usar…

Como la serie tiene ya unos pocos artículos, en esta dirección encontraréis el enlace a todos los artículos publicados hasta ahora.

Los primeros ordenadores sólo eran capaces de procesar una clase de ficheros: los secuenciales. Es decir, un conjunto de registros de información guardados todos juntos, uno detrás de otro, y que se leían o escribían también de uno en uno, uno tras otro, hasta acabar todo el conjunto.

Los primeros ficheros informáticos fueron en tarjeta perforada (ya la máquina de Hollerith para el censo de 1890 funcionaba con ellas). Un fichero en tarjetas perforadas es un bloque de tarjetas que tienen perforaciones que representan los

Caracteres que componen la información del registro. Los bloques de tarjetas se procesaban todos completos: se comenzaba a leer desde la primera tarjeta hasta alcanzar la última. Por tanto, si por algún motivo era necesario acceder exclusivamente a un registro, se debía leer secuencialmente todo el bloque, desde el principio, hasta llegar a él.

En esta nostálgica entrada, gracias a Jaume, os mostré cómo era un programa Cobol en tarjetas perforadas. Para que os hagáis una idea, un fichero en tarjetas perforadas es la misma cosa, sólo que las tarjetas tendrían todas la misma estructura, y en ellas habría grabados datos, no programas.

Unidad de Cinta IBM 2420 (años 60)

El soporte fue evolucionando. Primero, cinta perforada, heredada directamente del telégrafo, que es para las tarjetas lo mismo que los rollos de papiro en que los antiguos griegos escribían sus tratados, a los códices encuadernados en que los copistas medievales copiaron los escritos originales (los pocos que sobrevivieron, desde luego).

Después, a partir de principios de la década de 1950, fue la cinta magnética la que tomó el relevo… y esta vez para quedarse. Una cinta de 2.400 pies, la habitual a partir de los sesentas, grabada a 1600 ppi (phrames per inch, o caracteres por pulgada) podía almacenar unos 50 Mb de información… cuando los carísimos discos de la época podían almacenar quizá tres o cuatro… Las cintas magnéticas actuales almacenan Gigas y Gigas a un coste ridículo.

La aparición de las cintas magnéticas supuso un cambio sustancial en la forma de diseñar aplicaciones: ahora era posible mantener un fichero maestro (digamos, de Cuentas Corrientes) y diariamente acumular en otra cinta los movimientos del día, y entonces, leyendo simultáneamente ambos ficheros (¡el omnipresente padre-hijo!), escribir en una tercera cinta magnética el fichero maestro actualizado.

Este proceso igual podría hacerse en ficha perforada… pero es que, además de lento… ¡era carísimo! Las tarjetas perforadas no son reutilizables (una vez perforadas, no se pueden des-perforar…), mientras que las cintas sí que lo son: se pueden leer y escribir una y otra vez sin merma en su funcionamiento (al menos durante mucho tiempo).

.

Publicidad de Discos en 1977. ¡Obsérvese el precio!

Pero, con la aparición de los discos magnéticos (a finales de los cincuenta), la situación comenzó a cambiar. Porque con un disco magnético es posible algo que con una cinta no lo es: acceder a un registro determinado de un fichero sin necesidad de leer previamente todos los registros anteriores, simplemente dando instrucciones a la cabeza lectora de qué área del disco leer. Y lo mismo con la grabación. Esta característica abría nuevas posibilidades, que al poco se comenzaron a explotar.

Para que un programa supiera en qué dirección física del disco se encuentra la información demandada (supongamos la cuenta número 1537), antes había que haber anotado, en algún sitio, en el momento de la escritura, la dirección física donde había ido a parar tal cuenta.

Una solución obvia es utilizar el propio número de cuenta como dirección a la hora de grabar. Así, la cuenta 1537 estaría en la dirección 1537, y localizarla es inmediato.

Pero, claro, quizá la numeración de las cuentas no permita esta solución, por ejemplo, porque el propio número incluya el tipo de la cuenta, o porque tengan muchos huecos de numeración entre las cuentas (porque las cuentas adyacentes a la 1537 fueran la 1459 y la 1703, por ejemplo, con lo que se desaprovecharía muchísimo espacio). En la práctica, casi nunca puede usarse tal tipo de direccionamiento, salvo para ficheros-tabla de códigos, que tienen relativamente pocos registros y son muy estables en el tiempo.

Una forma de solucionar esto sería con la aplicación de una fórmula matemática que convirtiese el código del registro a buscar a una dirección física y unívoca. Esta técnica implica usar una función hash, y es muy eficiente… en los casos donde es factible usarla, que tampoco son tantos.

Así que rápidamente se constató que la única forma eficaz de poder conocer la dirección física de un determinado registro de un fichero era mediante la utilización de índices.

Un índice consiste ni más ni menos que crear, simultáneamente a la creación del fichero que se pretende indexar, otro fichero diferente al principal, que contendrá, ordenadas, las claves de acceso junto con sus direcciones. Así, tendríamos que nuestras cuentas estarían representadas, por ejemplo, con registros que podrían decir: 1459-007; 1537-008; 1703-009… Es decir, la cuenta 1459 está ubicada en el bloque 007, la 1537 en el 008, etc.

Ahora, para poder acceder a la cuenta 1537, basta con leer el fichero de índices (mucho más corto que el principal) hasta determinar la dirección de la cuenta y entonces ir al fichero principal, con un acceso directo, a dicha dirección. Es más, si es posible, mantendremos en memoria principal el fichero de índices, agilizando muchísimo el acceso (pues evitamos siquiera leer el índice).

Pero los propios índices pueden resultar de buen tamaño, así que se crea a su vez un índice para el propio índice, y así sucesivamente hasta llegar a un tamaño de índice razonable para mantener en memoria, creando así un árbol de índices. En realidad las cosas son un poco más complicadas de lo que he explicado aquí, pero creo que para hacerse una idea es suficiente… y los que ya conocéis todo esto… pues eso: ya lo conocéis.

Típico árbol de índices

Ya desde el advenimiento del Cobol en 1960, se incluyó la definición y tratamiento de ficheros indexados (ORGANIZATION IS INDEXED, mediante diversas cláusulas de definición y extensiones a las sentencias de lectura y escritura), y esto permitió diseñar las primeras aplicaciones con acceso directo a la información (en inglés se llama acceso Random, es decir, aleatorio, pero en realidad no es aleatorio en absoluto, sino que tu programa decide a qué registro acceder en función de la información solicitada). Y las aplicaciones que típicamente necesitan

Acceder a información de esta forma son las Aplicaciones Online. Es decir, si el Online existe es ni más ni menos gracias a la existencia de los índices……Porque lo interesante de todo esto es que el acceso mediante índices ha sido, y sigue siendo el método utilizado por todas las Bases de Datos de todo tipo para acceder a la información.

Utilizando ficheros secuenciales indexados, se pudo empezar a desarrollar las incipientes aplicaciones online, aunque hasta que no se dispuso de Gestores de Teleproceso era realmente difícil programar estos sistemas (que, además, tenían muy poca capacidad: a los exiguos tamaños de memoria y procesador existentes, se añadía la mínima velocidad de las líneas telefónicas de entonces: punto a punto, a 1200 o 2400 baudios –bits por segundo-).

Una curiosidad: uno de los primeros Monitores “serios” de Teleproceso (anterior en varios años al CICS de IBM), fue el PCL. El acrónimo PCL significa Programa de Control de Líneas (en español, sí), dado que fue desarrollado en el laboratorio de IBM en Barcelona, por un equipo dirigido por el holandés Rainer Berk, bajo las especificaciones del cliente, y trabajando codo a codo con ellos, y que se instaló por primera vez en La Caixa d’Estalvis i Pensions, alrededor de nada menos que 1964.

Este programa, que fue evolucionando y mejorando con los años, se usó durante los primeros tiempos en todos los bancos españoles que empezaron a hacer pinitos con su teleproceso en la década de los sesenta y primeros setenta, pues hasta al menos 1970 ó 71 no comenzó IBM a ofrecer CICS en España (e IMS/DC es posterior en cinco años o más).

No esperéis un link a algún artículo de la Wikipedia

...