Regístrate | Conectar
El Tamiz Libros Recursos Series Únete 13 Users Online
Skip to content

Historia de un Viejo Informático. La entrada en escena de Las Bases de Datos Relacionales.




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

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

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!

¡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

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

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

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 reaprovecharpor 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)

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).

oracle_logo

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 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...

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…

db2-logo

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.


Sobre el autor:

Macluskey ( )

Macluskey es un informático de los tiempos heroicos, pero no ha dejado de trabajar en Informática y disfrutar con ella hasta la fecha. Y lo que el cuerpo aguante. Y además, le gusta la música...
 

{ 22 } Comentarios

  1. Gravatar sir_eider | 20/04/2009 at 05:58 | Permalink

    Prime esta vez! Jeje…

    Aunque no tuve oportunidad de toquetear esos “mostruos” de las bases de datos, sí recuerdo cuando en mi tierna infancia aprendíamos en la academia prácticamente la única base de datos “decente” que había para PCs compatibles: Dbase III (y III plus que ya añadía interfaz, y IV toda feota…).

    Por aquella época ya había aprendido Basic y Pascal (bueno, sus “rudimentos”) y me pareció tela de cómodo el manejo de ficheros y bases de datos en general del Dbase en comparación… ¡Que “ilu” me hacía programar mis propias interfaces, consultas, pantallitas…! Ya me veía forrado vendiendo aplicaciones de bases de datos para las fruterías y videoclubs del barrio, jeje…

    Lo del modelo relacional y su aplicación en programación ya lo vi “de mayor” en la Uni, y para entonces me había vuelto un comodón que prefería diseñar todo visualmente en “esacosaquellamanbasededatos” también llamada Access, jeje

    Pero es muy ilustrativo ver cómo era la cosa en los ordenadores “mayores”.

    Un saludo y que no decaiga!

  2. Gravatar David Asorey Álvarez | 20/04/2009 at 09:52 | Permalink

    Llevo siguiendo tus relatos desde el principio y me encantan, todos, sin excepción. Si algún día decides publicarlos en forma de libro impreso (me gusta leer en papel, qué se le va a hacer), vas a tener un comprador seguro al menos.

    Excelente entrada, como todas. ¡Que no decaiga!

    Mi experiencia con la familia DB2 se limita a una aplicación que desarrollé para el cliente Lotus Notes que se conectaba a un DB2/400, leía datos de allí, no recuerdo qué guarradas les hacía y los enchufaba en un DB2 “universal” que corría en un Unix, no recuerdo cual. Era esperpéntico, para conectarnos usábamos ODBC y era horroroso lo mal que iba.

    Las guarradas y chapuzas que se han hecho (y que tu habrás visto, por supuesto) son espeluznantes. Y algunas se siguen haciendo … malditas consultoras …

    Gracias por tus artículos.

  3. Gravatar badaman | 21/04/2009 at 12:45 | Permalink

    ¿Hay alguna experiencia que contar en tu ámbito sobre MySQL y/o PostgreSQL?

  4. Gravatar Macluskey | 21/04/2009 at 07:25 | Permalink

    @badaman: No. Lo siento. Me han pillado, no mayor, sino “director”. Así que sólo sé de ellas de oidas… y de oidas, prefiero no hablar, que ya está la wikipedia y mil blogs fantásticos que hablan de MySql, de Java y de C, C++, C++plus, etc.

    Gracias por vuestro comentarios

  5. Gravatar cruzki | 21/04/2009 at 08:52 | Permalink

    Dios, como se nota que no tengo npi de bases de datos. Comparado con lo que iba enterando normalmente en tus entradas, en esta no me he enterado de una mierda @:(

    Tengo pendiente estudiar estas cosas, a ver si saco tiempo…

  6. Gravatar Jimmy Jazz | 21/04/2009 at 09:59 | Permalink

    Grande!

    El QMF es una maravilla, pero en la instalación que lo usé, si metías joins en según que consultas te mandaba a paseo (si el optimizador pensaba que la consulta iba a ser costosa supongo); y había que hacer las consultas en batch.

    Una duda, en IBM escribiendo en ficheros (solo trabajé con BBDD) había que poner cada cuantos registros se hace el COMMIT, como si fueran tablas, y hacen rollbacks si el proceso casca?

    Es por curiosidad, en Bull si que van así los ficheros UFAS, y como creo que son una copia de los VSAM…

    Venga, saludos!!

  7. Gravatar Macluskey | 21/04/2009 at 10:32 | Permalink

    @Jimmy Jazz: Trabajando con ficheros indexados, no hay ningún software de control que se preocupe de recuperar nada. O tú le dices cuándo tomar los checkpoints, o no hay tu tía. Precisamente para eso se inventaron las Bases de Datos, desde IDS e IMS hasta la última relacional: para automatizar el proceso.

    Pero vamos, que no es tan raro; si tienes un proceso que deseas que sea rearrancable (es decir, que si casca, o si se aborta por el operador, que al lanzarlo de nuevo siga por donde iba), tienes que ser tú, con o sin Bases de Datos, el que dé las instrucciones al Sistema y vaya apuntando por dónde iba… Un peñazo. Necesario, pero un peñazo.

    @cruzki: ¡Anda ya! No me lo puedo creer… pero si en estos tiempos hasta los niños de primaria saben SQL… Me tomas la cabellera, amigo.

  8. Gravatar yomismo | 21/04/2009 at 11:56 | Permalink

    Recuerdo que cuando empecé a interesarme por la informática lo único que conocía de bases de datos era un poco de dbase y luego con asp y vb algo de sqlserver. En ese momento lo normal era construir las sentencias dinámicamente y para mí era lo mejor. De repente, por trabajo me ví inmerso en el mundo mainframe (en el que después de 7 años ahí sigo) con la famosa triada (COBOL/CICS/DB2) . Al principio no entendía cómo era posible que se tuvieran que hacer las sentencias estáticas. Me parecía un error atroz tener que construir, una a una, cada sentencia necesaria, en lugar de hacerlo en tiempo de ejecución. ¡Qué equivocado estaba! El rendimiento es portentosamente mayor!! Además, si tienes bien diseñado el proceso o la transacción, casi nunca es necesario construir dinámicamente la sentencia.

    Por cierto, sólo por curiosidad. ¿Eres de QMF o SPUFI? Yo abogo por QMF, porque es la herramienta que está en todas las instalaciones de DB2, mietras que SPUFI no siempre está…

  9. Gravatar Macluskey | 22/04/2009 at 09:43 | Permalink

    @yomismo: Me alegro de que confirmes lo que dije en el artículo: la compilación de una query es siempre un proceso costoso, debido a que debe acceder a un puñado de tablas del catálogo, que siempre tienen contención, siempre… así que mejor tener la query compilada de antemano y el Plan preparado.

    En cuanto a si “soy” de QMF o de SPUFI… de ninguno. QMF es más “fino”, está más pensado para usuarios finales que saquen listados bonitos, y tal. SPUFI es más duro, más para gente que conozca la Base de Datos bien y mejor el SQL. Cada cuál tiene sus ventajas. Pero para sacar información de verdad, nada como un buen Data Warehouse… ya saldrá en algún momento el Data Warehouse, ya…

    Saludos

  10. Gravatar piluso | 22/04/2009 at 02:27 | Permalink

    Macluskey: como otro “viejo informático” no puedo menos que saludar tus artículos. Yo también me inicié en el mundo de los Main Frames, las teletipos, las cintas, y los núcleos magnéticos, en Bull de Argentina. Es mas, ví desde lejos con desdén los ordenadores de escritorio hasta principios de los 90…

    Como despunto el vicio de la docencia dictando Introducción a la Informática, Bases de Datos y otras yerbas en la carrera de Analista Universitario de Sistemas, me encuentro con que mis clases tiene un costado muy parecido al de tu serie. Por eso, no hago mas que recomendarle a mis alumnos, calurosamente, mas bien se los ordeno, que lean tus “Historias…”

  11. Gravatar piluso | 22/04/2009 at 02:33 | Permalink

    Me olvidé decir en el comentario anterior, que entre las cosas con las que me incié, estaba, como no podía ser de otra manera, el COBOL Y despúes de no usarlo durante años, me encuentro otra vez participando del mantenimiento de un gran “core” bancario en ese lenguaje. Si embargo en la Facultad no se le dedica ni un pobre seminario.

  12. Gravatar Macluskey | 22/04/2009 at 03:40 | Permalink

    ¡Bienvenido, Piluso!

    Otro colega más que aparece por aquí… y es que somos legión. Quizá tengamos las rodillas un poco oxidadas, pero las neuronas… esas las tenemos un rato bien puestas. Y si a tus alumnos le sirven estas historietas de cuando “se hacía la mili con lanza”, como decimos en España, pues encantado!

    Saludos y hasta otra

  13. Gravatar Monik | 23/04/2009 at 07:18 | Permalink

    Me ha encantado tu artículo (y los anteriores, gracias a ti ya voy pillando al db2 y el porque de sus cosas) Yo me dedico a las bases de datos y le doy principalmente al SQL server y hago mis pinitos en DB2 y Oracle. La verdad que el mundo del mainframe es complicado si toda tu vida has trabajado con las ventanitas, meterte en los menús del tso y en todas sus cosas, pero una vez que le coges el tranquillo va muy bien.

    Yo las bases de datos prehistóricas que use fueron Fox-Pro (nada de visual fox-pro) en la universidad y Clipper (en mi primer y único trabajo como programadora) y cuando descubrí que había un comando para hacer búsquedas de registros sin tener que currártelo a mano como cuando hacias algo en Pascal, flipé y fue cuando decidí que algún día me querría dedicar a las BDs (administrarlas y no programar).

    Espero que este blog dure mucho tiempo…. me encanta todo lo que tiene que ver con Informática prehistórica (como le llamo yo)….

  14. Gravatar lucas | 26/04/2009 at 02:42 | Permalink

    Este artículo -fantástico como todos los tuyos- me ha hecho reflexionar… ¿Será que el destino de la humanidad pende del desarrollo de bases de datos cada vez más y más potentes, con el solo afán de computar la naturaleza? Si las bases de datos pretenden reformular los conceptos de “orden”, de “organización”, de “relación”, de “estabilidad”, ¿por qué nuestra sociedad refleja lo contrario? ¿Será que cuanto mayor es el dominio tecnológico, menor es el dominio (es decir, la comprensión de la estructura) social? Los ingenieros desarrollan bases de datos cada vez con más soporte de registros, con mayor estabilidad, etc., pero ¿intentamos estabilizar y relacionar a la sociedad, o sólo a su faceta virtual (sus datos)? Todo hace pensar que terminaremos en un “proyecto #194”…

    Perdón por este fárrago, pero la tecnología informática brinda mucho para reflexionar…

    Un abrazo Mac.

  15. Gravatar rmramoslima | 28/04/2009 at 12:56 | Permalink

    Mac, realmente deberìas escribir un libro para que la gente nueva que se dedica a la informatica sepa como ha ido evolucionando las cosas hasta ahora, no soy de la vieja guardia pero tampoco de la nueva, yo ingrese a la uni en el año 97 cuando ya existia windows pero de niño programaba en basic con un atari 800xl que tenia, he aprendido mucho con tus historias, siempre me ha llamado la atencion como se hacian las cosas antes y con decirte que tambien trabajo en un banco y hay programas en cobol y RPG que usamos, en el de cobol (que esta en un AS400) hay sentencias SQL pero no se si es que ha usado el BIND asi que voy a averiguarlo; veo que la gente comenta que ya no enseñan Cobol curiosamente en mi uni si me enseñaron y la gente se quejaba de que eso ya no se usaba, sin embargo a mi si me gustaba y lo estudie bastante y cuando entre al banco tuve que usarlo y me fue sencillo entender y modificar los programas; seguramente como la curricula de la uni era un poco antigua nos seguian enseñando no se si lo habran quitado, lo que mas se usa aca es un case llamado genexus que genera RPG, nos permite desarrollar aplicativos (incluyendo paneles) rapidamente a lo mejor cuando llegues a la parte de herramientas case puedes comentar algunas otros case que se usan para AS400, un saludo desde Perù.

  16. Gravatar Macluskey | 04/05/2009 at 03:03 | Permalink

    @Lucas:

    Tus comentarios son siempre de los que hacen pensar… parece que ves más allá que nosotros los pobres mortales.

    Pues sí. Parece que con tanta Base de Datos Gigantesca que hay por ahñi (ya hablaremos del Data Warehouse más adelante, ya) los informáticos intentáramos revertir La Segunda Ley de la Termodinámica y convertir el Caos en Orden (como los Borg de la serie Star Treck, jeje). Sólo que hasta que no he leído tu comentario no lo he pensado. Y yo creo que, por mucho que nos pongamos, no va a poder ser… ¡El Caos, al final, ganará, nos pongamos como nos pongamos!

    Y… ¡Qué gran placer poder discutir con gente como vos! (discutir en el sentido del “discuss” anglosajón, of course, no en el del barriobajero hispánico medio…).

    Un gran abrazo interoceánico…

    A todos: Gracias por vuestros comentarios, y no os enfadéis conmigo por tardar, que estaba reponiendo fuerzas para poder seguir escribiendo y daros la lata……>>

  17. Gravatar Amstrad PC1512 | 23/06/2009 at 01:00 | Permalink

    Primero que nada felicitarte por tus entregas, que pese a que soy mucho mas baby que la mayoria de los integrantes del foro (Naci en el 70 y toque mi primer ordenador allá por el 82), me traen muchos recuerdos de cosas que vi, viví o estudie en la carrera?? (jaja) de informática.

    He echado de menos en tu artículo el DBase de Haston-Tate y su hijo aventajado el Clipper de Nantuket, lenguajes con los que dejé de ser un aficcionado a la informática y me convertí en un informático de provecho (como diría mi padre xD). Se que son aplicaciones menores que no entran en el ámbito de las DB nbombradas en este artículo, pero sentimentalmente para mi son importantes.

    Mi trabajo actual, por suerte o por desgracia, ya no está relacionado con la informática, pero intento estar al dia y leer tu blog me hace esbozar una sonrisa recordando mis “good old times”.

    Enhorabuena y gracias.

    Jose Antonio

  18. Gravatar Venger | 20/01/2012 at 10:36 | Permalink

    Muy chulo, pero Mac, tú que has demostrado que eres aficionado a la historia y más a la historia de España, yo creo que igual que has mentado a Blas de Lezo muy oportunamente, tendrías que haber hecho lo propio con el auténtico creador de las bases de datos, allá por el siglo VII…

    http://www.rezaconmigo.com/blog/santo-patrono-de-internet/

    No os perdáis la Oración… :·)

  19. Gravatar Sergio B | 20/01/2012 at 12:29 | Permalink

    Joe Venger, lo bonito de internet es que cuando uno se cree un frikazo de algo, siempre aparece alguien peor ha hacerte sentir normal

  20. Gravatar Venger | 20/01/2012 at 01:03 | Permalink

    http://www.elpais.com/articulo/agenda/VATICANO/SAN/ISIDORO/PATRON/INTERNET/elpepigen/19990618elpepiage_5/Tes

    http://www.facebook.com/group.php?gid=26362614726

    http://www.canaljuridico.com/Noticias/vernoticia.asp?id=1791

  21. Gravatar Erick | 10/10/2016 at 08:39 | Permalink

    Excelente contenido, muy completo, me sirvio perfecto para mi trabajo de la Uni.

  22. Gravatar Macluskey | 11/10/2016 at 02:42 | Permalink

    Me alegro, Erik.

    Y si además has aprendido algo, entonces… ¡me alegro mucho más!! ;)

    Gracias por comentar.

{ 1 } Trackback

  1. Gravatar meneame.net | 20/04/2009 at 04:14 | Permalink

    Historia de un Viejo Informático. La entrada en escena de Las Bases de Datos Relacionales…

    Nueva entrega de las Historia del Viejo Informatico. Hoy el comienzo de las bases de datos relacionales en España a mediados de la decada de los 80. Llena de anécdotas y datos, como siempre….

Escribe un comentario

Tu dirección de correo no es mostrada. Los campos requeridos están marcados *

Al escribir un comentario aquí nos otorgas el permiso irrevocable de reproducir tus palabras y tu nombre/sitio web como atribución.