El Cedazo

En la entrada anterior vimos los comienzos de las Bases de Datos (jerárquicas o en red, siguiendo en más o en menos el modelo CODASYL) y cómo estaba el panorama a mediados de los ochenta. En ésta veremos cómo fue la aparición de las Bases de Datos Relacionales, sin las que hoy en día no podríamos entender la informática.

Igual que dije en la entrada anterior (en realidad, en toda la serie) no intento realizar una crónica oficial de nada, sino más bien cómo son mis recuerdos y reflexiones de aquella época (segunda mitad de los ochenta); también viví muy de cerca el lanzamiento inicial, los balbuceos y la final adopción (no sin reticencias) de estas primeras versiones relacionales.

Como la serie ya va teniendo unos pocos capítulos, aquí os dejo el enlace para ver todos los artículos publicados hasta el momento.

A mediados de los ochenta existían múltiples bases de datos, jerárquicas, en red, de fabricantes y de compañías de software independiente, mayormente incompatibles entre sí… (ahí nos quedamos en el capítulo anterior). Pero pronto iban a comenzar a cambiar las cosas.

…Remontémonos en el tiempo… (ejem, permitidme este pequeño homenaje a Antonio Ferrandis -Chanquete- en la película “Biba la Banda”, de Ricardo Palacios).

Edgar "Ted" Codd

A principios de los setenta, un ingeniero de IBM en San José, California, el británico Edgar. F. Codd estaba convencido de que las Bases de Datos no tenían mucho futuro en la forma que estaban planteadas, sobre todo desde el punto de vista del diseño.

Diseñar correctamente una Base de Datos Jerárquica o en Red no era nada sencillo (doy fe), y programar los accesos, menos aún (doy fe, también). Y él abogaba por un método de diseño mucho más natural, más sencillo y que viniera determinado exclusivamente por los datos de la Aplicación. Si os acordáis de la entrada sobre programación estructurada, tanto el francés Warnier como, sobre todo, el inglés Jackson estaban pensando casi lo mismo: que para diseñar programas la única fuente fiable de información eran los datos sobre los que se aplicaba dicho programa.

Así que, tan pronto como en 1970, Codd publicó un paper de título “A Relational Model of Data for Large Shared Data Banks”, en el que expresó sus teorías. No tuvo mucho éxito. IBM, su patrono, no puso ningún interés en meterse en más berenjenales. Sinceramente, a mí no me extraña nada, puesto que, por un lado, estaba el reciente lanzamiento de IMS (1968), base de datos jerárquica en la que IBM había hecho un gran esfuerzo inversor, y que pretendía, lógicamente, amortizar; y por otro, con la tecnología de la época era imposible imaginarse siquiera la implementación de algo como un Gestor Relacional de Bases de Datos.

Pero… ¿En qué consistían las ideas de Codd?

En primer lugar, como ya he comentado, que el diseño debe ser realizado de manera natural, utilizando la más sencilla posible de las representaciones de los datos, es decir, los ficheros planos, los de toda la vida. Nada de complicadas estructuras reticulares ni jerárquicas: Basta con la Relación de todos los datos necesarios para la Aplicación: un compendio de todos los campos a gestionar en una sola Lista de Datos. De aquí viene el propio nombre de “Relacional”, puesto que se basa en Relaciones o listas de datos.

Un modelo relacional

Y además, la recuperación (toda la gestión, en realidad) de la información debería atenerse a las normas formales del Álgebra y del Cálculo. Así que describe el Álgebra Relacional aplicable a sus relaciones (que existía ya, pero no había sido muy explorada), que permite realizar operaciones con Relaciones. Estas operaciones básicas son:

Selección, que permite obtener un cierto número de filas (tuplas en la jerga relacional) de la Relación original;

Proyección, que permite obtener un determinado número de datos -columnas- de una determinada Relación;

Producto Cartesiano, que permite obtener todas las combinaciones resultantes de la mezcla de dos Relaciones con columnas diferentes (pero con clave idéntica);

Unión, que permite obtener una única relación que contenga todas las filas de dos o más relaciones con las mismas columnas;

Diferencia, que permite obtener las filas de una relación que no tienen correspondencia en otra relación, es decir, las que están en una, pero no en la otra; y

Renombrado, añadida posteriormente por cuestiones formales, que permite cambiar el nombre a una columna de una relación.

Si os acordáis de la Logica de Conjuntos, quizá echaréis en falta la intersección, pero es el resultado de aplicar dos diferencias consecutivas: si los conjuntos son A y B, la intersección de A y B se calcula como (A – (A – B)).

En definitiva, el Álgebra Relacional queda definida como un subconjunto de la Lógica de Primer Orden. Y el Teorema de Codd establece la correspondencia entre el Álgebra Relacional y el Cálculo Relacional.

¡Menudo rollo que os he soltado! Pero es que tenía mis razones: estando como está toda la Teoría Relacional gobernada por el Álgebra Relacional (o el Cálculo, que es lo mismo), y en definitiva, con la Lógica clásica y por tanto, con el bien conocido  Cálculo de Predicados, es posible establecer procedimientos puramente matemáticos para obtener el resultado de una petición a partir de la o las Relaciones Originales y la enumeración de los resultados deseados.

¡El programador automático!

En una palabra: sería factible construir un programa que, dados los resultados deseados (o sea, las especificaciones funcionales), y la estructura de la Base de Datos, calcule matemáticamente el mejor camino para obtener la información… eliminando, con ello, uno de los puntos más espinosos de la programación de las Bases de Datos tradicionales: la necesidad de que un programador avezado escribiera el código exacto para optimizar los accesos.

En efecto, se trata de esa procelosa e insondable pieza de código que conocemos por el nombre de Optimizador. Pero no nos adelantemos…

Porque, incluso en 1970, era evidente que almacenar toda la información de una gran Aplicación en un solo fichero físico era entonces (como lo sigue siendo ahora) una auténtica locura: la gigantesca redundancia de información que se produciría haría inviable cualquier proceso posible.

Así que Codd empezó a describir Reglas para Normalizar Bases de Datos Relacionales. Ya en 1971 había formalizado la primera, y tan pronto como en 1973 estaban ya formalizadas las Tres Primeras Formas Normales, que es adonde todo el mundo llega normalmente en el proceso de diseño (o donde todo el mundo se queda, según lo veáis).

Proceso de Normalización

En 1974, entre Codd y Raymond Boyce definieron la así llamada Forma Normal de Boyce-Codd, y posteriormente se definieron la Cuarta, la Quinta y la Sexta Formas Normales, esta última tan tarde como en 2002. A fuer de ser sincero, no me preguntéis para qué sirven, ni si tienen mucha aplicación: en mi aburrida vida de diseñador de aplicaciones comerciales, jamás me he visto en la necesidad de llegar más allá de la famosa Tercera Forma Normal…

Aunque IBM (la Madrastra de los Enanitos de principios de los años 70) no tuvo el menor interés en abrir otro melón (bastantes tenía ya abiertos por entonces), el amigo Codd era un tipo machacón: con el tiempo consiguió que IBM arrancara su primer proyecto relacional, el abuelo de todos ellos: System/R.

Sin embargo, por algún motivo ignoto (quizá porque resultaba demasiado “matemático” para las entendederas de los programadores de la época, yo el primero, porque, desde luego, por tema de patentes no era), en lugar de utilizar el Lenguaje ALPHA que Codd había diseñado, inventaron otro diferente, de nombre SEQUEL, que años después, y debido a que el nombre SEQUEL estaba registrado ya, cambió su nombre a SQL, nombre que quizá os suene de algo. Para los curiosos, Chris Date, el otro gran divulgador de la tecnología relacional, publicó en 1999, en Intelligent Enterprise, dos artículos sobre el lenguaje ALPHA: éste es el primero, y éste el segundo.

System/R terminó con cierto éxito, no porque fuera muy eficiente, que no lo era, sino porque demostró que era factible construir un Gestor de Bases de Datos Relacionales con un buen rendimiento en entornos transaccionales. Y muchas de las decisiones de diseño que se tomaron entonces han sido adoptadas por todas las Bases de Datos Relacionales desde entonces.

Por ejemplo, la decisión de almacenar la propia definición de las Bases de Datos (Tablas, Índices, etc, en definitiva, los metadatos) en unas tablas más (el famoso Catálogo), y acceder a ellas como si fueran unos datos cualesquiera, es de System/R, y todos sus seguidores siguieron la misma solución, a pesar de que desde el punto de vista del rendimiento es una solución espantosa; en IMS, por ejemplo, las definiciones de las Bases de Datos, índices, accesos, etc, se compilan (en realidad, se ensamblan), generando un código compacto y eficiente que es el usado por el Gestor.

Y otra decisión que tuvieron que tomar los diseñadores de System/R fue cómo realizar el interfaz entre una petición de información a la Base de Datos y los programas que usan esta información. El motivo es que la propia lógica relacional es per se una Lógica de Conjuntos, y por tanto, cada query puede devolver cero filas, o una… o muchas, incluso todas las filas de una tabla (o conjunto de tablas). Y, claro, los ordenadores siguen siendo unas humildes y escalares máquinas von Neumann, que tienen la costumbre de tratar secuencialmente los datos, y no todos a la vez, de golpe.

En una palabra, había que hacer convivir el hecho de que las queries relacionales son del tipo Set-At-A-Time, mientras que las máquinas eran, y siguen siendo, del tipo Record-At-A-Time… Y se inventaron la técnica de los Cursores, con todas sus sentencias asociadas (DECLARE CURSOR, FETCH, OPEN, CLOSE…), que permiten tratar un conjunto de filas (o de datos) como si se tratara de un fichero secuencial mondo y lirondo. También los Cursores están presentes en prácticamente todas las Bases de Datos Relacionales de hoy en día.

System/R incluso llegó a instalarse en algún cliente, sobre 1977-78, pero tuvo escaso éxito, debido a su no menos escaso rendimiento en las máquinas de la época.

También había vida relacional fuera de los esfuerzos (no demasiado esforzados todavía) de IBM. En la Universidad de Berkeley (California) habían asumido los planteamientos de Codd, y comenzaron un proyecto de investigación, que dio origen, a principios de los ochenta, a la Base de Datos Ingres. Fue un proyecto bajo licencia BSD, y por tanto, por una pequeña cantidad se podía adquirir el código fuente y reutilizarlo. Buena parte de las Bases de Datos de hoy en día deben mucho a Ingres (Sybase, Microsoft SQL Server y NonStop SQL, entre otras).

Y mientras tanto, IBM seguía trabajando en las secuelas de System/R. En 1982 sacó al mercado la Base de Datos SQL/DS, exclusivamente para DOS/VSE (VSE es un Sistema Operativo de IBM “competidor” de MVS, y heredero de DOS, el primer sistema operativo basado en disco de IBM; todavía hoy en día siguen existiendo instalaciones funcionando en VSE, y tan ricamente…).

Larry Ellison, fundador de Oracle

A partir de las especificaciones públicas de SQL/DS, Larry Ellison (fundador de Relational Software) y un equipo de ingenieros (entre los que había alguno que participó en el proyecto System/R) diseñaron una Base de Datos llamada Oracle, que comenzó a ser vendida alrededor de 1981 u 82, en principio para Digital/VAX, aunque la primera versión “utilizable” se vendió a partir de 1983-84, los mismos año en los que IBM lanzó DB2, el equivalente de SQL/DS, pero para MVS (sólo en entorno mainframe, desde luego). El nombre “DB2” se eligió para enfatizar la idea de que IMS era la primera Base de Datos (DL/1 era el lenguaje de tratamiento de la información), y DB2 era la segunda (y mejor) de ellas…

Esta versión DB2 v1.0 teóricamente funcionaba… siempre que las tablas tuvieran algunos cientos de filas, no se hicieran muchos joins (mejor, ninguno), y no hubiera que recuperar nada ante fallos. En una palabra, era completamente inservible para Aplicaciones en Producción. Larry Ellison fue más listo: la primera versión de Oracle lanzada al mercado era la 2.0… aunque le pasaban cosas muy parecidas.

A la versión 1.0 de DB2 siguió un año después la v1.1. Esta fue la primera versión que probamos en el banco en que trabajaba por entonces. La presión comercial de IBM (y las facilidades de apoyo que ofrecía en la instalación y prueba) hizo que estas primeras versiones se instalaran en muchísimas de las instalaciones españolas de MVS en aquellos años tempranos (86-87-88).

La conclusión general es que era un producto que prometía, pero que no se podía usar para Producción real.

Un ejemplo que yo viví: una de las pruebas que hicimos fue pasar un proceso de actualización a una tabla de algunos miles de filas, que actualizaba todas las filas de la tabla, y a mitad del proceso, cascar deliberadamente el programa (le hacíamos dividir un número por cero, cosa que a casi ningún ordenador le gusta demasiado; en MVS obtienes un hermoso abend S0CB). La Base de Datos debía, entonces, de tirar de log y recuperar todos los cambios, para dejar la tabla como al principio del proceso. Y eso fue lo que comenzó a hacer… Un par de horas más tarde, aburridos, cancelamos también el recovery… y entonces comenzó a recuperar la propia recuperación… hasta que otras tres horas después, paramos todo el DB2, que de todos modos se había quedado poco menos que frito, y lo mandamos todo a hacer gárgaras. Desde luego, muy estable no era.

Chris Date

Así que nadie instaló tampoco la versión 1.1. Pero había gran ruido e interés en esta nueva tecnología. Además de los esfuerzos de los fabricantes por convencernos de las supuestas bondades de la cosa relacional, hay que resaltar la enorme labor evangelizadora de Chris Date, dando conferencias por todo el mundo (en España, también), escribiendo libros, artículos… Una buena parte del éxito inicial es debido a él.

Tanto interés había, que el Grupo de DB2 de GUIDE se convirtió en el más numeroso con diferencia de todos los grupos de GUIDE (en España, al menos). Para los que no sepáis qué es GUIDE (o sea, casi todos), se trata de una Asociación de Usuarios, auspiciado por IBM, en el que los usuarios participan, junto con técnicos de la propia IBM, para poner en común las experiencias que cada cuál tiene con los productos de IBM, de hardware y de software: MVS, CICS, IMS…, así como hacer peticiones sobre funcionalidades de las nuevas versiones, etc. Cuando se constituyó el Grupo de DB2, casi todo el mundo se apuntó (pues, en la práctica, todas las grandes instalaciones sabíamos que, tarde o temprano, acabaríamos con uno o varios DB2 en nuestra instalación).

El motivo de tanta expectación era, sobre todo, la esperanza de que por fin íbamos a poder disfrutar de una herramienta con un interfaz común (el SQL), que permitiría migrar aplicaciones de entorno con facilidad y sencillez (aunque no se hiciera casi nunca) y, sobre todo, que permitiría reaprovechar (¡por fin!) la formación de los técnicos: una vez sabes SQL, puedes manejarte con cualquier Base de Datos Relacional… más o menos.

Porque nunca nos creímos del todo eso de que el Optimizador sería cada vez más listo y sería capaz siempre de encontrar el camino más eficaz para resolver la query sin necesidad de ayudarle. Y sabéis que, al menos hasta ahora, veinte años más tarde, teníamos razón: los Optimizadores son cada vez más listos… y siguen metiendo la pata con demasiada frecuencia como para poder dejarlos siempre solos; de ahí que en ocasiones haya que darles “hints” para orientarles.

IBM comenzó también a dar formación para los incipientes “probadores”, y así hasta que a principios de 1987 IBM sacó al mercado la versión v1.2. Esta versión ya funcionaba razonablemente bien, pero aún tenía un problema: ¡no hablaba con IMS/DC, sólo con CICS! Y esto era un serio inconveniente para aquéllas instalaciones (la más grandes) que teníamos IMS no sólo como Base de Datos, sino como Gestor Transaccional… porque nadie estaba dispuesto a cambiar el robustísimo IMS por un CICS que, en aquellas épocas, era mucho menos potente, más inestable y tenía un rendimiento bastante inferior.

Y por fin, a fines de 1987 o principios de 1988, IBM publicó la versión v1.3, que (además de seguir mejorando su funcionalidad y su rendimiento), por fin era compatible también con IMS. Seguía teniendo importantes lagunas: por ejemplo, la compilación de las queries tardaba muchísimo y además producía espeluznantes encolamientos en el acceso al Catálogo; el rendimiento de los joins seguía siendo malo (como ahora, vaya); un recovery de un proceso batch en base al log seguía tardando mucho (aunque al menos ahora siempre acababa bien)… pero obviando estos problemas conocidos, que podían solucionarse a base de normativa (prohibiendo por Decreto hacer lo que se sabía que no iba a ir bien), daba un rendimiento suficientemente bueno como para poder confiar en ella.

Ese fue el momento en que, en el plazo de unos pocos meses, muchas empresas (la mía entre ellas) tomaron la decisión de comenzar a usar DB2 “en serio”, es decir, para las nuevas aplicaciones que se comenzaban a escribir… y para ello, hubo que preparar extensísimos Planes de Formación para Analistas, Programadores, Técnicos de Sistemas… El Departamento de Formación de IBM quedó desbordado (no había tantos buenos formadores en algo nuevo, como era DB2), y los clientes tuvimos literalmente que hacer cola, porque no había otra alternativa: ninguna empresa de formación informática tenía entonces conocimientos de DB2 (ni de ninguna otra Base de Datos Relacional, diría yo) como para poder formar a nadie. Y claro, cuando una gran empresa decidía entrar en una tecnología básica como ésta debía dar formación igual a cuatrocientas o quinientas personas…

Y sobre 1988 comenzamos por fin a escribir las primeras aplicaciones usando DB2. Y hubo que reescribir buena parte de las normas de nomenclatura, diseño de programas, etc. Y hubo que asegurarse que todas las incipientes aplicaciones que se escribían para DB2 fueran de una mínima calidad, y que no hacían la cosas que se sabía que no iban bien… Por cierto, muchas de aquellas prohibiciones de fines de los ochenta siguen vigentes hoy en día en muchas instalaciones, a pesar de que lo que entonces iba mal ahora ya va bien… y es que ¡mira que nos cuesta trabajo cambiar a los informáticos!

Así que fue el terreno abonado para la tercera gran explosión tecnológica de la época: la adopción de las Arquitecturas, las Metodologías de Desarrollo y las Herramientas CASE, cosas muy interesantes de las que hablaremos en los próximos capítulos.

Proceso de Compilación SQL (DB2)

Sólo unos breves apuntes sobre la compilación de programas que accedan a DB2: es posible, desde luego, lanzar una query desde un programa Cobol (o lo que sea) y que el Optimizador la reciba, la compile, hallando el mejor camino para su resolución, y luego la ejecute. Pero es un proceso costoso (entre otras cosas, debido a que toda la información acerca de las propias Bases de Datos está contenida en otras Bases de Datos), que provoca una fuerte concurrencia sobre el Catálogo, y por tanto no es nada aconsejable hacer “SQL Dinámico”, ni en batch ni tampoco en online.

Así que IBM inventó para DB2 el “SQL Estático”, es decir, las queries se compilan y optimizan en batch, mediante un proceso llamado “BIND“, que compila cada query, calcula el mejor camino a usar, en función de la propia query, del número de filas de cada tabla, la distribución de las claves, los índices existentes y lo desorganizados que estén… y esa información del “mejor camino”, denominada Plan, se almacena en el propio catálogo y se usa siempre… para bien o para mal. Técnica ésta, la del SQL Precompilado, que, a pesar de que según la teoría no es recomendable en absoluto, casi todas las Bases de Datos actuales utilizan… por algo será.

El proceso de “BIND”, pues, se convierte en una parte más de la compilación de un programa que acceda a DB2, que queda, por tanto, con cuatro pasos (por lo menos): Precompilación DB2 (este paso convierte las llamadas a DB2, con “EXEC SQL”, en llamadas a módulos internos de DB2 que resuelven esa petición particular); Compilación (por ejemplo, Cobol, que genera el programa objeto); Linkedit (genera el programa ejecutable, uniendo todos los módulos llamados por el principal, incluidos los de DB2), y BIND (que obtiene el mejor camino para cada query). Si además tiene CICS, tendrá también su propia Precompilación (que en caso de IMS no es necesaria). En una palabra, la compilación comienza a ser un proceso pesado y muy consumidor de recursos…

…Pero este sistema soluciona el problema… siempre que las condiciones de las tablas no varíen, al menos en exceso (que se creen nuevos índices o se borre alguno existente, que la tabla se desorganice, debido a las inserciones y borrados reiterados, o, simplemente… que crezca o decrezca el tamaño de las tablas). Cuando algo de esto ocurre, se debe hacer “REBIND” de todos los Planes que afecten a la tabla, para permitir a DB2 calcular de nuevo el mejor camino… o no, pero bueno.

Pero también era posible acceder a las tablas DB2 directamente desde TSO, sin necesidad de programar, mediante dos productos específicos: SPUFI y QMF, que permiten a los usuarios finales lanzar sus propias queries contra las Bases de Datos, y obtener los resultados; estos dos productos, sobre todo QMF, fueron pilares básicos para la introducción, a fines de los ochenta, del concepto de Centro de Información, del que algo comentaremos cuando en la serie le toque el turno al artículo sobre el Data Warehouse.

.

IBM concentró sus esfuerzos relacionales de la década de los ochenta en el mundo mainframe… donde arrasó (y también en el mundo AS/400, para el que sacó al mercado DB2/400, base de datos que comparte con DB2 el nombre, casi todo el interfaz SQL… y poco más). No creo que hoy en día subsistan muchas Bases de Datos Relacionales en entorno mainframe que no sean DB2…

Pero en los ochenta, IBM dejó de lado el resto de los mundos (de hecho, recordad que hasta 1990 no anunció IBM su entrada en el mundo UNIX, de la mano de la gama RS/6000).

Y esos mundos fueron aprovechados por pequeñas empresas independientes, que lanzaron rápidamente productos que funcionaban en VMS (el Sistema de los VAX de Digital), en UNIX, en OS/2, e incluso en MS/DOS (yo tuve la oportunidad de probar la versión de Oracle para MS/DOS allá por 1990 o así: os podéis imaginar que no servía para nada, aunque las queries las hacía, y las hacía bien… siempre y cuando las tablas no tuvieran más allá de quince o veinte filas).

Estas compañías fueron, sobre todo, Relational Software (con su producto Oracle) aunque pronto cambió su nombre a Oracle  Corp.), Informix (acrónimo de Information on Unix), y Sybase, fundamentalmente, aparte de la propia Ingres, que sacó al mercado su versión UNIX a mediados de la década.

El gran avance de todas estas Bases de Datos lo constituyó el hecho de que todas ellas tuvieran el mismo (o casi el mismo) interfaz, que copiaron del que IBM inventó (pero no patentó, o quizá no pudo patentar: de ahí su gran éxito, como ocurrió con los PC’s): SQL. Por una parte les ahorró costes de diseño y desarrollo; por otra parte les ayudó comercialmente a crear “masa crítica”; todas eran compañías pequeñas, que un buen día podían quebrar… pero la inversión realizada por los clientes podría ser fácilmente transportable a otra de las que sobrevivieran; este hecho facilitó la toma de decisiones a favor de esta tecnología relacional.

Yo creo que IBM se equivocó de estrategia, al dejar durante unos años desatendido este mercado (bueno, no sólo yo, también IBM lo cree… ahora), que creció mucho más rápido de lo que pudieron prever. Y ahí está ahora Oracle, por ejemplo, como una de las mayores compañías de tecnología de mundo (y mayor que IBM, de hecho), que además hace sólo unas pocas horas (hoy, 20 de abril de 2009) que ha anunciado que compra a Sun, entrando de lleno, por primera vez, en el negocio del hardware…

Este no fue, desde luego, el único error de estrategia que IBM cometió… pero ésa es otra historia, y será contada en otro momento.

Fueron apareciendo, además, otros nichos de mercado que IBM no atendía: en el mundo de los sistemas tolerantes a fallos (ahora casi todos los sistemas importantes tienen una gran tolerancia a fallos, pero no entonces) Tandem se hizo con una buena parte del mercado de los Sistemas Críticos que no podían dejar de funcionar por un fallo de un componente cualquiera. Por cierto, IBM tenía también, cómo no, oferta en este mercado: el IBM System/88, que en realidad eran ordenadores Stratus, vendidos por IBM como OEM… aunque fue Tandem quien lideró el mercado esos años. Y Tandem puso en el mercado NonStop SQL (a partir de la base de Ingres), Base de Datos Relacional para sus sistemas tolerantes a fallos.

Otro nicho lo ocupó otra pequeña compañía, Teradata, que comenzó a vender la primera Máquina de Base de Datos, es decir, un hardware diseñado específicamente para obtener el máximo rendimiento en accesos a los discos magnéticos, y una Base de Datos especializada, que permite usar eficientemente el hardware, paralelizando accesos, e incrementando en mucho su velocidad, sobre todo en lectura, y, de paso, permitiendo incrementar el espacio en disco disponible en los mainframes, ya que Teradata tiene desde su creación una conectividad excelente con estos mainframes: se conecta vía canal, como un dispositivo externo más, y para MVS se trata de una cinta magnética… por lo que instalarlo no tiene apenas trabajo que hacer en el sistema principal.

Teradata 5400H

Teradata, de todos modos, encontró su nicho de mercado (bueno, en realidad prácticamente lo creó) cuando a mediados de los noventa comenzó a ponerse de moda (mejor, a necesitarse por las compañías) el concepto de Data Warehouse. Pero ésa es otra historia, y será contada en otro momento.

Y por fin, otras bases de datos que no eran ni mucho menos relacionales comenzaron a añadirles un interfaz relacional, para adaptarse a los nuevos tiempos. Datacom y Adabas fueron dos de ellas. El rendimiento era peor, sin duda, que utilizar su interfaz tipo CALL de toda la vida… pero así tenían más appeal para su venta, basándose en la portabilidad de aplicaciones, etc. No les fue mal del todo: ambas siguen existiendo en nuestros relacionales días, que es mucho decir.

En una palabra, aparecieron multitud de Bases de Datos Relacionales, pseudo-Relacionales o no-Relacionales-con-interfaz-SQL, con lo que la confusión del mercado creció y creció… Así que nuestro buen Codd, siempre velando por la pureza relacional, se aprestó a sacarnos de dudas: publicó sus famosas 12 Reglas, para poder discernir las Bases de Datos Relacionales de verdad, de las que sólo decían que eran relacionales, pero no lo eran (para los que tengáis curiosidad, ninguna Base de Datos de principios de los noventa cumplía con las 12 reglas, ni tan siquiera DB2).

Ignoro si el cumplimiento o no de las reglas famosas se tuvo en cuenta a la hora de hacer la selección de una u otra Base de Datos para un proyecto concreto por una empresa concreta. Pero sí que se hicieron estudios sobre cuál era la que más o la que menos cumplía con las reglas.

Recuerdo que, a principios de los noventa, cierta Universidad madrileña anunció, en el entorno del SIMO, una charla en la que nos explicaría un estudio completísimo que habían realizado sobre cuál era la mejor Base de Datos Relacional. Aprovechando que por aquella época aún iba yo al SIMO todos los años (hace ya muchos que no, y este último año 2008 no ha ido al SIMO ni siquiera el propio SIMO…), fui a la charla de conclusiones. Acudimos muchos profesionales, pensando… “Vaya, por fin un estudio serio, independiente y español sobre Bases de Datos, ¡pardiez, qué interesante!”.

Pues no.

Una encuesta...

Resulta que habían realizado una encuesta a los doce o catorce vendedores de RDBMSs que entonces había en España, mediante un cuestionario, en el que éstos contestaban cuál era el grado de cumplimiento de su Gestor sobre las doce reglas de Codd. Por ejemplo: “¿Su Base de Datos mantiene un Catálogo Dinámico Online basado en el modelo relacional?” Conteste Sí, No, o según el día“, y así con todo.

Y ya.

…Y en base a las respuestas, con un sencillo proceso de tabulación (porcentajes de cumplimiento y poco más, nada de estadísticos complejos), llegaron a la conclusión de que la mejor de todas, la chachi piruli, era CA/Universe (de Computer Associates, que por entonces estaba empeñado en fusionarla con la otra Base de Datos de su propiedad: Datacom, aunque ignoro si llegaron a terminar la fusión alguna vez…).

Yo (que siempre he sido un poco preguntón) no pude resistirme, e hice dos preguntas en el turno de Ruegos y Preguntas, sólo dos:

Una: “¿Han hecho algún tipo de prueba de funcionamiento en la práctica?” Respuesta: “No, ninguna. La pobrecita Universidad no tiene fondos suficientes, tralarí, tralará…”

Dos: “¿Han utilizado, al menos, los manuales técnicos de las Bases de Datos para hacer la evaluación?” Respuesta: “Uy, no, menudo trabajo, pues vaya, todo en inglés… Nos hemos basado exclusivamente en las respuestas que los fabricantes han dado a las doce preguntitas del cuestionario. Es que la Universidad tiene pocos recursos, ya sabe, tralará, tralarí…”

Y no hubo una pregunta tres: me levanté y me fui; a ver qué iba yo a hacer allí perdiendo el tiempo… Sinceramente, me dio mucha pena. Cuando lo comparo con la Universidad de Berkeley, arrancando un proyecto de investigación y creando de la nada Ingres… pues eso, que me da mucha pena. Y no creo yo que las cosas hayan mejorado mucho desde aquellos años hasta ahora, desgraciadamente…

Bueno, para acabar esta historia que se está alargando mucho (como siempre, pensaréis) IBM entró por fin en el mercado de Bases de Datos Relacionales para UNIX… perdón, para AIX, que era el UNIX que IBM se inventó para su gama RS/6000, y sacaron, sobre 1991 o 1992, DB2/6000. Que no tenía nada que ver con DB2 (el del mainframe) ni con DB2/400, menos el nombre y la mayor parte del interfaz. La versión mainframe fue durante mucho tiempo responsabilidad del Laboratorio de Santa Teresa (California), mientras que DB2/6000 lo era del Laboratorio de Toronto (Canadá)… así que, para no perder la costumbre, los laboratorios parecían peleados, y los planes de desarrollo de una y otra Base de Datos eran no sólo distintos, sino en ocasiones, contradictorios.

Este DB2/6000 con el tiempo se convirtió en lo que es hoy: DB2 Universal Database, y ya funciona en todos los sabores, olores y colores de UNIX, OS/2, Linux, supongo que Windows, PDAs, etc… menos en mainframe, donde sigue funcionando una cosa llamada DB2, sí, pero que no tiene mucho que ver con su Universal primo.

… Y colorín, colorado, las Bases de Datos Relacionales se hicieron con el mercado.Y esta entrada, por cierto, se ha acabado (que ya es hora).

En la próxima entrada os hablaré, siempre que vuestra indulgencia lo siga permitiendo, de eso tan bonito y lujoso llamado “Ventana Batch“, tan desconocido para muchos, y que tantos dolores de cabeza nos da a otros…

Disfrutad de la vida, mientras podáis.

The Historia de un Viejo Informático. La entrada en escena de Las Bases de Datos Relacionales. by , unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 Spain License.