Viejo Informatico

7/26/2019 Viejo Informatico

1/17

Historia de un Viejo Informtico. El caminohacia las Bases de Datos Relacionales.

En un trabajo anterior vimos cmo comenzaron a usarse los PCs en la empresa (ypoco despus en todos lados). Otro de los hitos tecnolgicos que tuvieron lugar amediados de la dcada de los ochenta del siglo pasado fue la irrupcin en el mercadode las Bases de Datos Relacionales, sin las que hoy en da no podramos entender lainformtica, y a relatar cmo comenzaron a ser lo que hoy en da son me voy a dedicaren esta entrada y la siguiente.

En esta entrada de hoy, me centrar en los antecedentes: daremos un repaso a lahistoria de las Bases de Datos, mejor dicho, de los Sistemas de Gestin de Base deDatos que existan en el momento (sobre 1984-85). Es ms, comenzaremos incluso

antes, por conocer cmo eran las tcnicas de almacenamiento de la informacin antesde que existieran las Bases de Datos (de cualquier tipo), o cuando s que existan, pero,debido a sus limitaciones, no se podan usar

Los primeros ordenadores slo eran capaces de procesar una clase de ficheros: lossecuenciales. Es decir, un conjunto de registros de informacin guardados todos juntos,uno detrs de otro, y que se lean o escriban tambin de uno en uno, uno tras otro,hasta acabar todo el conjunto.

Los primeros ficheros informticos fueron en tarjeta perforada (ya la mquina deHollerith para el censo de 1890 funcionaba con ellas). Un fichero en tarjetas perforadases un bloque de tarjetas que tienen perforaciones que representan los caracteres quecomponen la informacin del registro. Los bloques de tarjetas se procesaban todoscompletos: se comenzaba a leer desde la primera tarjeta hasta alcanzar la ltima. Portanto, si por algn motivo era necesario acceder exclusivamente a un registro, se debaleer secuencialmente todo el bloque, desde el principio, hasta llegar a l.

En esta nostlgica entrada, gracias a Jaume, os mostr cmo era un programa Cobolen tarjetas perforadas. Para que os hagis una idea, un fichero en tarjetas perforadases la misma cosa, slo que las tarjetas tendran todas la misma estructura, y en ellashabra grabados datos, no programas.
http://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Database_management_systemhttp://eltamiz.com/elcedazo/2009/03/27/historia-de-un-viejo-informatico-nostalgia-un-programa-cobol-en-tarjetas-perforadas/http://eltamiz.com/elcedazo/2009/03/27/historia-de-un-viejo-informatico-nostalgia-un-programa-cobol-en-tarjetas-perforadas/http://en.wikipedia.org/wiki/Database_management_systemhttp://en.wikipedia.org/wiki/Database_management_system


2/17

Unidad de Cinta IBM 2420 (aos 60)

El soporte fue evolucionando. Primero, cinta perforada, heredada directamentedel telgrafo, que es para las tarjetas lo mismo que los rollos de papiro en que losantiguos griegos escriban sus tratados, a los cdices encuadernados en que loscopistas medievales copiaron los escritos originales (los pocos que sobrevivieron, desdeluego).

Despus, a partir de principios de la dcada de 1950, fue la cinta magntica la que tomel relevo y esta vez para quedarse. Una cinta de 2.400 pies, la habitual a parti r de lossesentas, grabada a 1600 ppi ( phrames per inch , o caracteres por pulgada) podaalmacenar unos 50 Mb de informacin cuando los carsimos discos de la pocapodan almacenar quiz tres o cuatro Las cintas magnticas actuales almacenanGigas y Gigas a un coste ridculo.

La aparicin de la cintas magnticas supuso un cambio sustancial en la forma de disearaplicaciones: ahora era posible mantener un fichero maestro (digamos, de CuentasCorrientes) y diariamente acumular en otra cinta los movimientos del da, y entonces,leyendo simultneamente ambos ficheros (el omnipresente padre-hijo !), escribir en unatercera cinta magntica el f ichero maestro actualizado.

Este proceso igual podra hacerse en ficha perforada pero es que, adems de lentoera carsimo! Las tarjetas perforadas no son reutilizables (una vez perforadas, no sepueden des-perforar ), mientras que las cintas s que lo son: se pueden leer y escribiruna y otra vez sin merma en su funcionamiento (al menos durante mucho tiempo).

.
http://es.wikipedia.org/wiki/Cinta_perforadahttp://eltamiz.com/2008/10/05/inventos-ingeniosos-el-telegrafo-electrico/http://en.wikipedia.org/wiki/Magnetic_tape_data_storagehttp://en.wikipedia.org/wiki/Magnetic_tape_data_storagehttp://en.wikipedia.org/wiki/Magnetic_tape_data_storagehttp://en.wikipedia.org/wiki/Magnetic_tape_data_storagehttp://eltamiz.com/2008/10/05/inventos-ingeniosos-el-telegrafo-electrico/http://es.wikipedia.org/wiki/Cinta_perforada


3/17

Publicidad de Discos en 1977. Obsrvese el precio!

Pero, con la aparicin de los discos magnticos (a finales de los cincuenta), la situacincomenz a cambiar. Porque con un disco magntico es posible algo que con una cintano lo es: acceder a un registro determinado de un fichero sin necesidad de leerpreviamente todos los registros anteriores , simplemente dando instrucciones a lacabeza lectora de qu rea del disco leer. Y lo mismo con la grabacin. Estacaracterstica abra nuevas posibilidades, que al poco se comenzaron a explotar.

Para que un programa supiera en qu direccin fsica del disco se encuentra lainformacin demandada (supongamos la cuenta nmero 1537), antes haba que haberanotado, en algn sitio, en el momento de la escritura, la direccin fsica dondehaba ido a parar tal cuenta .

Una solucin obvia es utilizar el propio nmero de cuenta como direccin a la hora degrabar. As, la cuenta 1537 estara en la direccin 1537, y localizarla es inmediato.

Pero, claro, quiz la numeracin de las cuentas no permita esta solucin, por ejemplo,

porque el propio nmero incluya el tipo de la cuenta, o porque tengan muchos huecosde numeracin entre las cuentas (porque las cuentas adyacentes a la 1537 fueran la
http://en.wikipedia.org/wiki/Disk_storagehttp://en.wikipedia.org/wiki/Disk_storage


4/17

1459 y la 1703, por ejemplo, con lo que se desaprovechara muchsimo espacio). En laprctica, casi nunca puede usarse tal tipo de direccionamiento, salvo para ficheros-tablade cdigos, que tienen relativamente pocos registros y son muy estables en el tiempo.

Una forma de solucionar esto sera con la aplicacin de una frmula matemtica que

convirtiese el cdigo del registro a buscar a una direccin fsica y unvoca. Esta tcnicaimplica usar una funcin hash , y es muy eficiente en los casos donde es factibleusarla, que tampoco son tantos.

As que rpidamente se constat que la nica forma eficaz de poder conocer la direccinfsica de un determinado registro de un fichero era mediante la utilizacin de ndices.

Un ndice consiste ni ms ni menos que crear, simultneamente a la creacin del ficheroque se pretende indexar, otro fichero diferente al principal, que contendr, ordenadas,las claves de acceso junto con sus direcciones. As, tendramos que nuestras cuentasestaran representadas, por ejemplo, con registros que podran decir: 1459-007; 1537-008; 1703- 009 Es decir, la cuenta 1459 est ubicada en el bloque 007, la 1537 en el008, etc.

Ahora, para poder acceder a la cuenta 1537, basta con leer el fichero de ndices (muchoms corto que el principal) hasta determinar la direccin de la cuenta y entonces ir alfichero principal, con un acceso directo, a dicha direccin. Es ms, si es posible,mantendremos en memoria principal el fichero de ndices, agilizando muchsimo elacceso (pues evitamos siquiera leer el ndice).

Pero los propios ndices pueden resultar de buen tamao, as que se crea a su vez unndice para el propio ndice, y as sucesivamente hasta llegar a un tamao de ndicerazonable para mantener en memoria, creando as un rbol de ndices. En realidad lascosas son un poco ms complicadas de lo que he explicado aqu, pero creo que parahacerse una idea es suficiente y los que ya conocis todo esto pues eso: ya loconocis.

Tpico rbol de ndices

Ya desde el advenimiento del Cobol en 1960, se incluy la definicin y tratamiento deficheros indexados (ORGANIZATION IS INDEXED, mediante diversas clusulas dedefinicin y extensiones a las sentencias de lectura y escritura), y esto permiti disearlas primeras aplicaciones con acceso directo a la informacin (en ingls se llamaacceso Random , es decir, aleatorio, pero en realidad no es aleatorio en absoluto, sinoque tu programa decide a qu registro acceder en funcin de la informacin solicitada).Y las aplicaciones que tpicamente necesitan acceder a informacin de esta forma sonlas Aplicac iones Onl ine . Es decir, si el Online existe es ni ms ni menos gracias a laexistencia de los ndices
http://en.wikipedia.org/wiki/Hash_(computer_science)http://en.wikipedia.org/wiki/Hash_(computer_science)http://en.wikipedia.org/wiki/Index_(information_technology)http://en.wikipedia.org/wiki/Index_(information_technology)http://en.wikipedia.org/wiki/Hash_(computer_science)


5/17

Porque lo interesante de todo esto es que el acceso mediante ndices ha sido, ysigue siendo el mtodo uti lizado por todas las Bases de Datos de todo tipo paraacceder a la informacin .

Utilizando ficheros secuenciales indexados , se pudo empezar a desarrollar las

incipientes aplicaciones online, aunque hasta que no se dispuso de Gestores deTeleproceso era realmente difcil programar estos sistemas (que, adems, tenan muypoca capacidad: a los exiguos tamaos de memoria y procesador existentes, se aadala mnima velocidad de las lneas telefnicas de entonces: punto a punto, a 1200 o2400 baudios bits por segundo-).

Una curiosidad : uno de los primeros M onitores serios de Teleproceso (anterior envarios aos al CICS de IBM), fue el PCL . El acrnimo PCL significa Programa deControl de Lneas (en espaol, s), dado que fue desarrollado en el laboratorio de IBMen Barcelona, por un equipo dirigido por el holands Rainer Berk, bajo lasespecificaciones del cliente, y trabajando codo a codo con ellos, y que se instal porprimera vez en La Caixa dEstalvis i Pensions, alrededor de nada menos que 1964.

Este programa, que fue evolucionando y mejorando con los aos, se us durante losprimeros tiempos en todos los bancos espaoles que empezaron a hacer pinitos con suteleproceso en la dcada de los sesenta y primeros setenta, pues hasta al menos 1970 71 no comenz IBM a ofrecer CICS en Espaa (e IMS/DC es posterior en cinco aoso ms).

No esperis un link a algn artculo de la Wikipedia hablando de PCL, ni algn link aalgn otro sitio hablando de PCL No hay ! Es como si nunca hubiera existido . Fue unhito espaol en informtica y prcticamente nadie lo conoce, ni se encuentradocumentacin, aparte de en la memoria de algunos viejos rockeros. Y, aunque notanto, lo mismo sucede, por ejemplo, con otra gran innovacin espaola de la poca(adems, sta fue completamente espaola): la Red Especial de Transmisin deDatos (RETD), que fue la primera red mundial de transmisin de paquetes, y sobre laque tambin ha cado el olvido, aunque afortunadamente Jess Martn Tardo (ingenierode Telefnica de aquellos aos) ha escrito un maravilloso relato de lo que pas esosaos gloriosos.

Ignoro si ser exclusivamente tradicin espaola la de ignorar (o peor, despreciar!) lascosas buenas que se han hecho y magnificar las malas, pero indudablemente esoocurre, y hay muchsimos ejemplos. Uno flagrante (que no tiene nada que ver conordenadores):

Sabis quin fue el Almirante Nelson ? Sabis quiz qu pas en la batalla deTrafalgar , en 1805? Quiz os suene de algo

S, ya veo que s. Y Sabis quin fue el Almirante Blas de Lezo ? Sabis por venturaqu ocurri en el Sitio de Cartagena de Indias sesenta aos antes, en 1741? Puescuando lo leis, si lo leis, igual os llevis una sorpresa

.

Volvamos a los fich eros indexados
http://en.wikipedia.org/wiki/Indexed_filehttp://en.wikipedia.org/wiki/Indexed_filehttp://en.wikipedia.org/wiki/Indexed_filehttp://en.wikipedia.org/wiki/Baudhttp://en.wikipedia.org/wiki/Baudhttp://en.wikipedia.org/wiki/Baudhttp://en.wikipedia.org/wiki/CICShttp://en.wikipedia.org/wiki/CICShttp://en.wikipedia.org/wiki/CICShttp://personales.ya.com/tardio/Zips/Td.pdfhttp://personales.ya.com/tardio/Zips/Td.pdfhttp://personales.ya.com/tardio/Zips/Td.pdfhttp://es.wikipedia.org/wiki/Horatio_Nelsonhttp://es.wikipedia.org/wiki/Horatio_Nelsonhttp://www.batalladetrafalgar.com/http://www.batalladetrafalgar.com/http://www.batalladetrafalgar.com/http://www.batalladetrafalgar.com/http://es.wikipedia.org/wiki/Blas_de_Lezohttp://es.wikipedia.org/wiki/Blas_de_Lezohttp://es.wikipedia.org/wiki/Blas_de_Lezohttp://es.wikipedia.org/wiki/Sitio_de_Cartagena_de_Indias_(1741)http://es.wikipedia.org/wiki/Sitio_de_Cartagena_de_Indias_(1741)http://es.wikipedia.org/wiki/Sitio_de_Cartagena_de_Indias_(1741)http://es.wikipedia.org/wiki/Sitio_de_Cartagena_de_Indias_(1741)http://es.wikipedia.org/wiki/Blas_de_Lezohttp://www.batalladetrafalgar.com/http://www.batalladetrafalgar.com/http://es.wikipedia.org/wiki/Horatio_Nelsonhttp://personales.ya.com/tardio/Zips/Td.pdfhttp://en.wikipedia.org/wiki/CICShttp://en.wikipedia.org/wiki/Baudhttp://en.wikipedia.org/wiki/Indexed_file


6/17

Efectivamente, su capacidad de recuperar o grabar la informacin mediante un accesodirecto, sin necesidad de leer el fichero completo, permiti el advenimiento de lasprimeras aplicaciones online pero si las aplicaciones en s eran posibl es, en realidadtenan muchas dificultades para su normal explotacin diaria.

Una de ellas era la dificultad para organizar los accesos concurrentes, es decir, lagestin de los bloqueos. En un proceso bancario, por ejemplo un pago de cheque, esnormal acceder primero a la cuenta para ver, lo primero, si existe, y despus, si tienesaldo suficiente para hacer frente al cheque, luego a los talonarios de la cuenta paracomprobar que el cheque existe y no est bloqueado por algn motivo, etc. Al final detodas las comprobaciones, se marca el cheque como pagado, se actualiza el saldo dela cuenta, y se graba el movimiento para su contabilidad.

Si todo va bien, no pasa nada. Pero puede ocurrir que otra transaccin que se ejecutaen la regin de al lado (que para algo habamos inventado ya la multiprogramacin ),pretenda pagar un recibo de la misma cuenta en el mismo momento. Si no se controlamuy bien, y se obliga a la segunda a esperar a que la primera termine, se puede montarun carajal de mucha consideracin. Con los ficheros indexados, todo este montaje hayque controlarlo a mano, complicando enormemente la programacin en unosordenadores que, re cordad, slo tienen unas pocas Kbs de memoria

Pero la otra es an ms seria: Ante un error de hardware o de programa (que, aveces, cascan sabis?, por muy bien escritos que estn) el fichero indexado se quedahecho unos zorros . Como en realidad se mantienen dos ficheros a la vez, el de ndicesy el de datos, es muy posible (es ms: era lo normal) que el fallo deje actualizado unode ellos, pero no el otro dejando el fichero inservible. Entonces, la nica alternativaera asumir que el contenido del fichero principal (los datos) es el correcto, y a partir del reconstruir los ndices utilizando el fichero en exclusiva durante el tiempo que dureel rebuild (y rezar porque todo acabe bien y no haya que volver a la versin anterior,perdiendo toda la sesin online hasta el fallo). O sea, parando la aplicacin onlinemientras se recupera. Bastante inaceptable, como podis suponer.

Charles Bachman

Otro de los gurs de la informtica, Charles Bachman , estuvo en la gnesis de lasolucin a todos estos problemas: el concepto de Base de Datos .

De sus trabajos naci la primera Base de Datos de la historia: IDS , de General Electric(una de las grandes compaas mundiales, tambin en informtica; de hecho durantelos aos sesenta era uno de los as llamados Siete Enanitos , las siguientes sietemayores compaas de informtica que competan en el mercado con la madrastra ,
http://es.wikipedia.org/wiki/Multiprogramaci%C3%B3nhttp://es.wikipedia.org/wiki/Multiprogramaci%C3%B3nhttp://es.wikipedia.org/wiki/Multiprogramaci%C3%B3nhttp://en.wikipedia.org/wiki/Charles_Bachmanhttp://en.wikipedia.org/wiki/Charles_Bachmanhttp://en.wikipedia.org/wiki/Charles_Bachmanhttp://en.wikipedia.org/wiki/DBMShttp://en.wikipedia.org/wiki/DBMShttp://en.wikipedia.org/wiki/DBMShttp://en.wikipedia.org/wiki/Integrated_Data_Storehttp://en.wikipedia.org/wiki/Integrated_Data_Storehttp://en.wikipedia.org/wiki/Integrated_Data_Storehttp://en.wikipedia.org/wiki/Integrated_Data_Storehttp://en.wikipedia.org/wiki/DBMShttp://en.wikipedia.org/wiki/Charles_Bachmanhttp://es.wikipedia.org/wiki/Multiprogramaci%C3%B3n


7/17

IBM, hasta que decidi abandonar el negocio en 1970, vendiendo la divisin deinformtica a otro de los enanitos : Honeywell).

La idea fundacional de las Bases de Datos (en realidad, de los Sistemas Gestores deBases de Datos ) era solventar todos los problemas derivados del uso aislado de los

diferentes ficheros, no tanto pensando en el batch (que, en realidad, estaba resuelto sinnecesidad de Base de Datos alguna), sino para dar soporte a los emergentes procesosonline y de tiempo compartido.

Un DBMS deba, en primer lugar, asegurar la coherencia de los datos en todomomento . Esta es una conditio sine qua non para poder desarrollar y explotar con xitouna aplicacin online. Y adems debe permitir interactuar con ella a desarrolladores,tcnicos de sistemas, etc con cierta sencillez, para facilitar el desarrollo, explotacin yposterior mantenimiento de las aplicaciones. Resumiendo, un DBMS (de cualquier tipo,por cierto, incluido uno Relacional) que se precie debera, al menos, de cumplir lascaractersticas siguientes:

1 Ante un fal lo de un programa, debe ser capaz de r ecuperar la inform acin queste se encontr, deshaciendo todos los cambios realizados antes de su fallo. Estoimplica la existencia de un log de cambios donde quedan reflejados todos los cambiosefectuados por el programa, y que permiten deshacerlos para volver a la situacinoriginal.

2 Debe ser, adems, capaz de recuperar un proceso completo que haya resultadoerrneo , aunque haya terminado aparentemente bien (o sea, que no ha cascado). Porejemplo, puede que un determinado proceso batch haya funcionado mal, y actualizadoerrneamente muchos registros, o todos; el Gestor debe permitir recuperar el procesocompleto para repetirlo una vez arreglado el programa falln. Esto exige una gestinavanzada de copias de seguridad, coordinada con la propia gestin del log.

3 Debe proporcionar un procedimiento robusto ante fallos del propio sis tema . En elcaso de un error en una Base de Datos, debe permitir recuperar la que est afectada,sin necesidad de afectar el resto; de esta manera se independizan unas aplicaciones deotras.

Concurrencia de Procesos
http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datoshttp://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datoshttp://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datoshttp://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datoshttp://es.wikipedia.org/wiki/Log_(registro)http://es.wikipedia.org/wiki/Log_(registro)http://es.wikipedia.org/wiki/Log_(registro)http://es.wikipedia.org/wiki/Log_(registro)http://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datoshttp://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datos


8/17

4 Debe gestionar de forma eficaz la concurrencia entre procesos . Esto exige uncontrol automtico y eficaz de los bloqueos: cuando un programa accede a un registrode la Base de Datos con la intencin de actualizarlo, el DBMS debe dejarlo bloqueadopara cualquier otro proceso, hasta su terminacin (correcta, en cuyo caso los cambiosse consolidan, o errnea, en cuyo caso se deshacen).

Para lograr todo esto se requiere que el lenguaje de interfaz con la Base de Datospermita avisarla de que el programa tiene intencin de actualizar el registro que estsolicitando para lectura; que yo sepa toda Base de Datos tiene esta funcin (como laspeticiones tipo GHU en IMS, o la SELECT FOR UPDATE en SQL).

Cuando se produce concurrencia, la estrategia correcta no es precisamente la delavestruz , sino dejar en espera al segundo peticionario que lleg, hasta que el registrobloqueado quede liberado, y entonces permitirle continuar su proceso. Pero estemecanismo tambin tien e sus problemas

Deadlock de procesos

5 Porque en caso de que dos transacciones requieran registros cruzados (lo que enla literatura tcnica se conoce como deadlock , o, en cheli , el abrazo del oso ), o seresuelve de alguna manera, o quedarn bloqueados ambos registros para siempre.Un proceso P1 requiere el registro B, y lo bloquea, y despus el registro A, mientras queotro proceso P2 requiere el registro A, y lo bloquea, y despus el registro B (estas cosasse dan con ms frecuencia de lo que podra parecer). Si hay la mala suerte de queambos procesos, ejecutndose simultneamente, han obtenido sin problemas susprimeros registros tenemos un problema. Porque el proceso P1 tiene bloqueado elregistro B y est a la espera del A que est bloqueado por el proceso P2, que a suvez est esperando el registro B. Si el DBMS no reconoce el problema para ponerlesolucin (tpicamente calzarse uno cualquiera de los dos procesos, para dejar que unoal menos, el otro, termine bien, y despus relanzar el proceso abortado), podracolapsarse y requerir intervencin manual, lo que no parece muy buena idea. El Gestorde Bases de Datos debe solventar los deadlocks cuando ocurren . Adems, estecaso puede darse no slo con dos procesos, sino con tres, cuatro lo que es bastantecomplicado de resolver.

6 Las bases de datos deben pr oveer un int erfaz para que los programadores puedancodificar correctamente los accesos, en lectura o actualizacin, o la navegacin entrediferentes registros relacionados; interfaz documentado y nico, y a ser posible quelibere al programador de todas las funciones de control, gestin de los ndices, de los
http://www.webprogramacion.com/registro.aspx?id=43http://www.webprogramacion.com/registro.aspx?id=43http://www.webprogramacion.com/registro.aspx?id=43http://en.wikipedia.org/wiki/Deadlockhttp://en.wikipedia.org/wiki/Deadlockhttp://en.wikipedia.org/wiki/Deadlockhttp://en.wikipedia.org/wiki/Deadlockhttp://www.webprogramacion.com/registro.aspx?id=43


9/17

punteros, los backups o recoveries, etc. Deben proveer tambin toda una seriede programas de utilidad para todas las tareas tcnicas, como reorganizacin, creacinde ndices, etc.

7 Y adems d eben permitir al usuario (el usuario de estas Bases de Datos era el

programador, no el usuario final) la abstraccin del modelo fsico : es decir, se diseael modelo lgico de la informacin, cmo son las entidades de datos y cmo serelacionan entre s, y se plasma en el propio diseo de la Base de Datos. Naturalmente,esto cambi, con el tiempo, la propia forma de disear las aplicaciones, dando origen alpoco tiempo al nacimiento de las metodologas de Diseo Estructurado, el modeloEntidad-Relacin, etc. Pero sa es otra historia, y ser contada en otro momento.

Todas estas caractersticas estn resumidas (ms o menos) en lo que se conocecomo ACID : Atomicidad, Consistencia, Aislamiento, Durabilidad ..

Podemos decir que las Bases de Datos cumplieron sobradamente sus objetivos ,desde el primer momento. Doy fe. Evidentemente, las primeras de ellas no eran sencillasni de disear ni de programar correctamente (bueno, si nos ponemosquisquillosos, tampoco ahora, je, je ), pero efectivamente eran razonablemente seguras,rpidas y eficaces, cuando se rompan, se arreglaban bien y rpido, y, aunquecomplicadas de programar, lo eran mucho menos que si hubiera habido que hacerlodirectamente con los ficheros indexados.

Programar para IMS era bastante complicado. Lo s: yo lo hice. Lidiar con las PSBs, lasPCBs, las SSAs, etc, necesita de mucha, pero mucha, atencin por parte delprogramador (y conocimientos, desde luego), y tener siempre presente el diagrama deldiseo fsico de la Base de Datos.

An recuerdo una transaccin que tena un tiempo de respuesta normal (pequeo), yante una (aparentemente) mnima modificacin, de pronto se convirti en la transaccinque ms recursos consuma de todo el Banco. Resulta que la modificacin obligaba alIMS a recorrer toda una largusima cadena de gemelos (las distintas ocurrencias de unmismo segmento) para insertar el suyo y nadie nos dimos cuenta de ese hecho (ni el

Analista - yo, y mira que saba yo de IMS por entonces-, ni el programador, que sabatambin lo suyo, ni el Tcnico de Sistemas). Para solucionarlo, se a adi un nuevopuntero al segmento padre que apuntara a la ltima ocurrencia del segmento hijo (elpuntero PCL, por Phisical Child Last) y el programa ahora solicitaba directamente elltimo segmento, antes de insertar. Un xito: la transaccin volvi a ser de las msmodositas de la instalacin. Esta ancdota tontorrona puede ayudar a haceros una ideade lo fino que haba que hilar.
http://en.wikipedia.org/wiki/Utility_softwarehttp://en.wikipedia.org/wiki/Utility_softwarehttp://en.wikipedia.org/wiki/Utility_softwarehttp://en.wikipedia.org/wiki/ACIDhttp://en.wikipedia.org/wiki/ACIDhttp://en.wikipedia.org/wiki/ACIDhttp://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datoshttp://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datoshttp://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datoshttp://es.wikipedia.org/wiki/Sistema_de_gesti%C3%B3n_de_base_de_datoshttp://en.wikipedia.org/wiki/ACIDhttp://en.wikipedia.org/wiki/Utility_software


10/17

Base de Datos Codasyl

A raz de los esfuerzos de Bachman, se cre en CODASYL un grupo para definir lascaractersticas y especificaciones que deban cumplir las Bases de Datos en Red ; estas

especificaciones se publicaron en 1969 y permitieron el avance de la industria de lasBases de Datos.

Aunque algunos, como IBM, haban avanzado por su cuenta, y ya tenan en el mercadola suya propia (IMS) desde 1968, ya que fue diseada para poder gestionar elcomplicadsimo control de inventario del Programa Apolo (se que hizo que Armstrong,

Aldrin y compaa pisaran la Luna aunque todava hay quien lo duda ).

Comenzaron a aparecer en el mercado diferentes bases de datos, que implementaron,unas ms y otras menos, los estndares CODASYL: unas fueron concebidas comobases de datos en red, y otras fueron diseadas com o jerrquicas ; el modelo jerrquico(que admite slo relaciones de padre a hijo, y entre gemelos) no es ms que un modeloen red restringido, y por tanto estaba tambin contemplado en las especificacionesCODASYL.

Diagrama de Base de Datos en Red

En esta pgina tenis una recopilacin de las Bases de Datos de todo tipo que se habancreado y/o comercializado antes de 1986, antes de la explosin relacional . Hay unaspocas : Ms de 150!, y aunque en puridad algunas de ellas no son en realidad Basesde Datos, sino ms bien sistemas de acceso a ficheros, o aplicaciones escritas sobreuna Base de Datos, os podis hacer una idea del gran folln basedatsitico que haba.

Casi cada fabricante importante construy y vendi la suya, y aparecieron bastantesempresas independientes de software que construyeron y vendieron sus propias bases
http://en.wikipedia.org/wiki/CODASYLhttp://en.wikipedia.org/wiki/CODASYLhttp://en.wikipedia.org/wiki/CODASYLhttp://en.wikipedia.org/wiki/Network_modelhttp://en.wikipedia.org/wiki/Network_modelhttp://en.wikipedia.org/wiki/Network_modelhttp://es.wikipedia.org/wiki/IMS_(IBM)http://es.wikipedia.org/wiki/IMS_(IBM)http://es.wikipedia.org/wiki/IMS_(IBM)http://en.wikipedia.org/wiki/Apollo_programhttp://en.wikipedia.org/wiki/Apollo_programhttp://en.wikipedia.org/wiki/Apollo_programhttp://eltamiz.com/2007/07/03/falacias-el-hombre-nunca-ha-llegado-a-la-luna/http://eltamiz.com/2007/07/03/falacias-el-hombre-nunca-ha-llegado-a-la-luna/http://eltamiz.com/2007/07/03/falacias-el-hombre-nunca-ha-llegado-a-la-luna/http://en.wikipedia.org/wiki/Hierarchical_modelhttp://en.wikipedia.org/wiki/Hierarchical_modelhttp://en.wikipedia.org/wiki/Hierarchical_modelhttp://infolab.stanford.edu/pub/gio/dbd/acm/app2.pdfhttp://infolab.stanford.edu/pub/gio/dbd/acm/app2.pdfhttp://infolab.stanford.edu/pub/gio/dbd/acm/app2.pdfhttp://infolab.stanford.edu/pub/gio/dbd/acm/app2.pdfhttp://en.wikipedia.org/wiki/Hierarchical_modelhttp://eltamiz.com/2007/07/03/falacias-el-hombre-nunca-ha-llegado-a-la-luna/http://en.wikipedia.org/wiki/Apollo_programhttp://es.wikipedia.org/wiki/IMS_(IBM)http://en.wikipedia.org/wiki/Network_modelhttp://en.wikipedia.org/wiki/CODASYL


11/17

de datos (probablemente debieron ser de las primeras empresas que construyeronsoftware bsico sin ser fabricantes de hardware).

A la primera de todas, IDS (de GE, luego Honeywell), le siguieron (adems de IMS, deIBM), DMS1100 (de Sperry Univac), DMS II (Burroughs), IDS2 (Bull), IDMS (Cullinet,

luego Computer Associates), Total (Cincom ), Datacom (ADR, luego Computer Associates), Adabas (Software AG), System 2000 (De una tal INTEL -antes MRI-, queno es la misma Intel que todo el mundo conoce; yo jurara que en Espaa la vendaSiemens, para sus ordenadores Siemens 4004, aunque no lo puedo asegurar), etc, etc,etc.

Estas tres ltimas se basan en el concepto de listas invertidas que proporciona unexcelente tiempo de acceso en lectura, aunque no precisamente en actualizacin, loque las hace especialmente eficientes en entornos de slo-consulta, con poca o nulaactualizacin. Adabas, en concreto, sigue siendo utilizada en grandes instalacionesespaolas (y de todo el mundo) despus de su lavado de cara relacional de hace yabastantes aos (admite SQL como interfaz), aunque buena parte de la culpa de que sigaestando vigente la tiene Natural , tambin de Software AG , el nico lenguaje de CuartaGeneracin que de verdad tuvo xito, que funciona muy bien con Adabas (y con DB2, ycon Oracle), y que se mantiene funcionando en la actualidad pero esa es otrahistoria, y ser contada en otro momento.

Esto de las listas invertidas puede parecer antiguo, pero sigue siendo muy usado en laactualidad: por ejemplo, los buscadores que se usan en aplicaciones web, incluyendo eltodopoderoso Google, utilizan variaciones de listas invertidas para realizar lasbsquedas (necesitan muy buen tiempo de acceso en lectura, pero no tanto enactualizacin).

Desde luego, los nombres de la mayora de Bases de Datos de la poca parecanuna sopa de letras . Tanto, que en aqullos tiempos gloriosos, no podamos evitar, entrelos enteradillos de la profesin, contarnos el siguiente chiste (que entonces tena muchams gracia que ahora, por cierto):

En una tienda:

Cliente (sealando): Dme se. Y dme se. Y de se y de se, dos .

Tendero (a la cajera): Dle uno. Total, debe dos .
http://en.wikipedia.org/wiki/Integrated_Data_Storehttp://en.wikipedia.org/wiki/Integrated_Data_Storehttp://en.wikipedia.org/wiki/Integrated_Data_Storehttp://en.wikipedia.org/wiki/Information_Management_Systemhttp://en.wikipedia.org/wiki/Information_Management_Systemhttp://en.wikipedia.org/wiki/Information_Management_Systemhttp://en.wikipedia.org/wiki/Unisys_DMSIIhttp://en.wikipedia.org/wiki/Unisys_DMSIIhttp://en.wikipedia.org/wiki/Unisys_DMSIIhttp://fr.wikipedia.org/wiki/Bullhttp://fr.wikipedia.org/wiki/Bullhttp://fr.wikipedia.org/wiki/Bullhttp://en.wikipedia.org/wiki/IDMShttp://en.wikipedia.org/wiki/IDMShttp://en.wikipedia.org/wiki/IDMShttp://en.wikipedia.org/wiki/Cincomhttp://en.wikipedia.org/wiki/Cincomhttp://en.wikipedia.org/wiki/Cincomhttp://en.wikipedia.org/wiki/DATACOM/DBhttp://en.wikipedia.org/wiki/DATACOM/DBhttp://en.wikipedia.org/wiki/DATACOM/DBhttp://en.wikipedia.org/wiki/ADABAShttp://en.wikipedia.org/wiki/ADABAShttp://en.wikipedia.org/wiki/ADABAShttp://en.wikipedia.org/wiki/Inverted_filehttp://en.wikipedia.org/wiki/Inverted_filehttp://en.wikipedia.org/wiki/Inverted_filehttp://www.softwareag.com/es/products/natural/default.asphttp://www.softwareag.com/es/products/natural/default.asphttp://www.softwareag.com/es/products/natural/default.asphttp://en.wikipedia.org/wiki/Software_AGhttp://en.wikipedia.org/wiki/Software_AGhttp://en.wikipedia.org/wiki/Software_AGhttp://en.wikipedia.org/wiki/Software_AGhttp://www.softwareag.com/es/products/natural/default.asphttp://en.wikipedia.org/wiki/Inverted_filehttp://en.wikipedia.org/wiki/ADABAShttp://en.wikipedia.org/wiki/DATACOM/DBhttp://en.wikipedia.org/wiki/Cincomhttp://en.wikipedia.org/wiki/IDMShttp://fr.wikipedia.org/wiki/Bullhttp://en.wikipedia.org/wiki/Unisys_DMSIIhttp://en.wikipedia.org/wiki/Information_Management_Systemhttp://en.wikipedia.org/wiki/Integrated_Data_Store


12/17

Ya, ya dije que no tena gracia Mejora un poco si lo ponemos en su contexto:

Cliente : DMS. IDMS. IDSIDS2 .

Tendero : DL/1. Total, DB2 .

En fin. A Adabas no haba forma de meterle en el chascarrillo

Desde luego, la propia sobreabundancia de versiones de Bases de Datos de todos tiposy colores a finales de los setenta ya quiere decir mucho: Tuvieron un gran xito, ycumplieron con las expectativas ms halageas. Efectivamente resolvieron aquellosproblemas que vinieron a resolver: Las aplicaciones fueron mucho ms fiables, los datosmucho ms coherentes, el proceso de diseo de los datos, ms estructurado y lgico, yante un fallo de cualquier tipo, la informacin se recuperaba normalmente de formarpida y completa, sin prdida alguna.

Pero tuvieron tambin inconvenientes, algunos de ellos bastante importantes, queabonaron el cambio de tecnologa de mediados y finales de los ochenta.

En primer lugar, cada Base de Datos era de su padre y de su madre . Literalmente.Cada una de ellas tena un lenguaje de definicin, un modo de ejecucin, diferentesprogramas de utilidad, y, por supuesto, diferente interfaz para los programas deaplicacin. La forma usual es resolver los accesos mediante la llamada (va CALL,generalmente esttica) a un determinado mdulo del gestor (en el caso del IMS de IBM , por ejemplo, el mdulo es CBLTDLI desde Cobol, ASMTDLI desde Assembler, etc), conciertos parmetros que le indican a qu Base de Datos se quiere acceder, a qusegmento o entidad, y para hacer qu (leer el segmento de cierta clave, o el siguienteen secuencia, o modificar el segmento con nuevo contenido, borrarlo).

Hay que tener en cuenta que todas las Bases de Datos de la pocaeran Navegacionales , sin excepcin, es decir, era el programador el que indicaba elorden de recuperacin de la informacin en la Base de Datos: primero recuperar unsegmento padre con una clave dada, luego recuperar la primera ocurrencia de uno desus segmentos hijo, leer en secuencia todos estos segmentos hasta cumplir ciertacondicin, reescribir el segmento, insertar un nuevo segmento al final de la cadena,saltar a otro lugar distinto, y as hasta acabar el proceso, tanto en batch como en online.

Y en cada Base de Datos este proceso es distinto, pero no un poco distinto,sino completamente diferente . Migrar de una a otra Base de Datos requiere no slo

efectuar un proceso complicado de descarga de la informacin y carga en la nueva Basede Datos, que en realidad era lo ms sencillo, sino que haba que reprogramarcompletamente todos los accesos para lo cual haba, en primer lugar, que dar uncompleto Plan de Formacin a todo el personal, y luego, reprogramar la Aplicacincompleta.
http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.ims9.doc.apdb/p3hgnp.htmhttp://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.ims9.doc.apdb/p3hgnp.htmhttp://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.ims9.doc.apdb/p3hgnp.htmhttp://en.wikipedia.org/wiki/Navigational_database_management_systemhttp://en.wikipedia.org/wiki/Navigational_database_management_systemhttp://en.wikipedia.org/wiki/Navigational_database_management_systemhttp://en.wikipedia.org/wiki/Navigational_database_management_systemhttp://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.ims9.doc.apdb/p3hgnp.htm


13/17

Portabilidad: brillaba por su ausencia...

En una palabra: No exista portabilidad entre Sistemas . Ni la ms mnima. Quiz estono fuera un problema muy serio para las instalaciones de cliente (tampoco vas a andarcambiando de Sistema a cada rato), pero era un inconveniente importantsimo para losfabricantes de Software de Gestin.

Supongamos que hemos desarrollado una Aplicacin que queremos vender a muchosclientes, por ejemplo una Nmina. Inicialmente la desarrollamos en, digamos, unmainframe IBM con IMS, que para algo tiene la mayor cuota de mercado. Cuando estlista, la empezamos a vender (bueno, antes de que est lista que el marketing es elmarketing).

Y aunque haya una base importante de clientes para nuestra Nmina, resulta que notodos los clientes tienen esa configuracin. Los hay que tienen un mainframe de IBM,pero la Base de Datos es Total, o Datacom, por ejemplo. Otros grandes clientes tienenun Siemens 4004 con System 2000, o con Adabas. Y otros, un Bull con IDS2. Migrar laaplicacin para que corra simultneamente, con las mismas funcionalidades, en todosestos sistemas y Bases de Datos es una locura. Migrar una aplicacin de Unix aWindows o viceversa es un juego de nios, comparado con lo que era migrar de IBM/IMSa Digital/Adabas Y eso que al menos, el Cobol s que era el mismo !

De hecho, la fragmentacin de la tecnologa, ms exactamente, la diversidad dediferentes interfaces con los Sistemas, redujo muchsimo el alcance del incipientemercado del software independiente durante las dcadas de 1960, 70 y casi todos losochenta del siglo pasado. Cosa que a los fabricantes de hardware no les preocupabaen absoluto, como es obvio: as, su mercado era cautivo. A los fabricantes de cualquiercosa les encantan los mercados cautivos

Y, adems de esta falta de estndares, es que tampoco era nada sencillo disear yprogramar bien para ninguno de estos Sistemas y Bases de Datos . En igualdad decondiciones, era mucho ms sencillo que hacer lo mismo a pedal , directamente conficheros indexados, desde luego que s, pero segua siendo difcil mayormente porquela propia existencia de las Bases de Datos permiti la realizacin de Aplicaciones conuna complejidad muy elevada, que hubieran sido completamente imposibles sin esasBases de Datos.


14/17

Se requera una muy buena formacin, apoyo constante en manuales (haba tal cantidadde opciones y posibilidades que necesitabas consultar los formatos de las llamadasconstantemente), y experiencia. Y lo primero se solventaba con cursos de formacin,por caros que fueran (que lo eran), lo segundo con una buena fotocopia del original paracada uno pero la experiencia slo se consegua con tiempo, y aprendiendo de las

galletas, sobre todo de las propias , que ya sabemos que nadie escarmienta en cabezaajena. Es decir, los buenos tcnicos (analistas, programadores, tcnicos desistemas) escaseaban . Mucho.

Se los reconoca porque, cuando hablaban, nadie en absoluto a su alrededor que nofuera de la profesin entenda una palabra. Y a veces, ni as. Por ejemplo: Hemostenido un 0C4 en una regin del VSAM, y el PTF del CAS no pudo instalarse porque laversin del HSM no estaba a nivel Ya me diris lo que entenda nadie de todo eso, ysobre todo, ya me diris qu entenda el pobre usuario (por ejemplo, el responsable deprstamos de la sucursal de Antequera) cuando llamaba, medio llorando, para decirteque no poda abrir un prstamo hipotecario porque la mquina no le dejaba y reciba

semejante contestacin.

Aqu estbamos muchos

Esta escasez de buenos profesionales trajo dos consecuencias, buenas o malas (segnse mire): Se activ el mercado para estos profesionales (para nosotros, vaya), que

comenzaron a cambiarse de empresa, explotando su conocimiento tan exclusivo yvalorado, y por consiguiente se comenzaron a mover los sueldos , no slo en las


15/17

empresas que fichaban nuevos empleados, sino tambin en las que pretendanconservar los suyos o sea, en todas. Y este movimiento salarial fue bueno paranosotros, los informticos del momento. Ganbamos bastante dinero. Trabajbamosmucho, eso es cierto tambin, pero el sueldo era muy bueno, y nosotros ramos buenos,importantes, imprescindibles

Y nos endiosamos.

S, lo reconozco. Lo s de buena tinta porque yo tambin fui un dios Tan importantesnos sentimos, tan insustituibles, tan necesarios que nos volvimos unos perfectoscretinos. Nos olvidamos de lo ms importante (de lo nico importante): que no somos nims ni menos que un Departamento de Gasto, es decir, que el resto de la empresa nosve como Un Mal Necesario . Y, encima, caro!.

Nosotros, los informticos, no generbamos un duro para el negocio: eran los sufridoscomerciales, gestores y administrativos los que ganaban con sus ventas y su trabajo daa da el dinero suficiente como para pagar no slo sus sueldos, sino los de losinformticos, y los de todos los dems, as como los dineros que se reparten a losaccionistas.

Sigo reconocindolo: Nos encastillamos en nuestra torre de marfil , y llegamos a pensarque lo nico importante era que nuestros sistemas fueran como la seda ( desdenuestro punto de vista, eso s ), que el tiempo de respuesta fuera bueno, que no fallaranlas aplicaciones y, sobre todo, que nos molestaran lo menos posible con peticiones,cambios, problemas y dems zarandajas .

Las peticiones de cambio en alguna aplicacin por parte del usuario, que hasta hacapoco haban sido atendidas con prontitud, comenzaron a ser sistemticamentedistradas, retenidas, paradas, cortocircuitadas Las excusas eran bueno, eran paraestar all y orlas, verbigracia:


16/17

Bla, Bla, Bla...

Mira : para hacer esta modificacin que pides, debo convertir un ndice Phisical-Child-First en un Phisical-Child-Last , con lo que debo modificar cuarenta y cinco transaccionesy treinta y siete programas batch, hacer un REORG y parar la Base de Datos unasemana y media, y adems las transacciones de consulta por LTERM tendran untiempo de respuesta mucho peor que ahora porque se producira un encolamientoestocstico masivo, y afectara al rendimiento ciclotmico del sistema transversal delVSAM, y bla bla bla.

Y el pobre usuario, compungido y desarbolado, te peda perdn por habrseleocurrido semejante proposicin deshonesta, te invitaba a un caf como desagravio yse volva a sus Cuarteles de Invierno completamente frustrado, porque en realidad l oella sigue pensando que poder sacar los movimientos de las cuentas ordenados porfecha de valor en vez de por fecha de operacin no debera ser tan complicado

Las aplicaciones se complicaban ms y ms costaban ms y ms y cada vezestbamos ms lejos de los usuarios. Los rboles no nos dejaban ver el bosque. Y alfinal lo pagamos . Pero sa es otra historia, y ser contada en otro momento.

Yo creo que de esta poca (principios y mediados de los ochenta) fue cuando empeza aparecer ese sano odio que la mayora de usuarios de las empresas (no slo lasgrandes) tenan y siguen teniendo a los informticos. Claro que a lo mejor escompletamente natural el sentimiento de unos y de otros, porque es cierto que hoy por


17/17

hoy, sin su informtica, casi ninguna empresa sera viable, pero ms cierto an es que,sin su empresa, casi ningn informtico sera viable .

Yo, por mi parte, siempre intent dar en lo posible el mejor servicio a mis atribuladosusuarios, ponerme en su lugar, y mantener las aplicaciones lo ms adecuadas y fciles

de utilizar posible, eso que ahora se llama usabilidad . Pero tambin he de entonar el meaculpa , pues soy culpable de una buena parte de los pecados descritos. Muchos aosdespus, he de reconocer que una parte de los de la profesin sufrimos (en pasado ) yan sufrimos (en presente ) esta enfermedad.

Si mis pobres palabras sirven para que algunos de vosotros, queridos lectoresinformticos, reflexionis un poco sobre esta circunstancia, habrn cumplido sumisin. Y os pido humildemente perdn, si en algo os he ofendido

Volvamos ya a las Bases de Datos, que esto va de Base de Datos, no de golpes de pecho

.

Ya a principio de los setenta, haba algunos adelantados que pensaban que estageneracin de Bases de Datos podra abocarnos, con el t iempo, a un callejn sinsalida .

Era necesario un mtodo de diseo ms sencillo , pues cada vez ms y msaplicaciones se escribiran en todo el mundo y no era conveniente que todas y cada unade ellas necesitaran unos tcnicos especializados y muy expertos, cada uno de ellos enun producto diferente e incompatible con el resto. Era necesario solventar la falta decompatibilidad entre aplicaciones mediante un interfaz comn. Era necesarioencontrar alguna cosa, algn sistema para facilitar la eleccin del mejor c amino pararecuperar la informacin pedida sin necesidad de tener que conocer de antemano (yprogramar cuidadosamente) el mejor camino para hacerlo, es decir, realizar lanavegacin de forma automtica. Era necesario que un simple cambio en ladefinicin de la Base de Datos no obligara a modificar todos los programas queacceden a ella. Era necesario, por fin, depender cada vez menos los informticos .

En una palabra, era necesario volver a acercar la t ecnologa al negocio , porque enlos ltimos tiempos ambos se estaban separando cada vez ms, y la pinta era quepodran llegar a perderse de vista

A Realizar por el Alumno:

Luego de leer todo el documento realice una sntesis conceptual del mismo (mximo 2hojas) e incluya su trabajo en la plataforma virtual mediante el siguiente formato:

ApellidoNombre_Alumno_Lectura1.

Nota: Esta lectura es individual

Viejo Informatico

Documents

Transcript of Viejo Informatico