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.

...