Fórum Técnico: 2018

Edgar F. Codd

La creación del modelo teórico de las bases de datos relacionales, tras una apariencia fría y académica, esconde una apasionante historia que incluye grandes corporaciones, luchas personales, comunismo, caza de brujas y agencias militares y espaciales. Vamos a descubrir al hombre que sentó las bases más sólidas y duraderas de la tecnología de la información, y contaremos la historia de cómo sufrió la incomprensión de la propia empresa para la que desarrolló su trabajo.

Una biografía movidita

El trabajo de un matemático en un centro de cálculo diseñando bases de datos nos parece algo rutinario y reposado, pero la vida de Codd no fue precisamente aburrida.

Su nombre completo era Edgar Frank Codd, aunque era conocido por sus allegados como Ted Codd. Nació el 18 de agosto de 1923 en Portland Bill, un remoto pueblo de Dorset, Inglaterra. Su padre era curtidor y su madre profesora, y era el menor de siete hermanos. A pesar de ese origen tan humilde, y gracias a una beca, estudió matemáticas y química en Oxford.

Podría haber evitado participar en la Segunda Guerra Mundial por ser estudiante, pero quiso alistarse en las Fuerzas Aéreas, llegando al grado de Teniente.

Bombardero de patrulla Short S.25 Sunderland, como el que pilotó Codd. (Public Domain, Link)

Una vez terminado su servicio como piloto, a los 25 años se marchó a Estados Unidos, donde IBM le contrató como programador matemático. Para él debió ser toda una experiencia llegar a Manhattan y encontrarse que iba a trabajar con un prototipo de computador que ocupaba dos pisos completos.

En 1953, cuando llevaba varios años labrándose un prestigio en una gran empresa como IBM, todo parecía ir sobre ruedas para Ted. Sin embargo, al igual que hiciera cuando abandonó la Universidad para luchar en la guerra, no dudó en dejarse llevar por sus ideas políticas cuando en EEUU comenzó la oscura etapa del Macartismo. No he encontrado referencias de que Codd fuese militante comunista, o de que estuviese siendo perseguido en ningún modo, pero su odio hacia esta ola de intolerancia le llevó a abandonar el país y trasladarse a Canadá.

Panfleto llamando a la población a luchar contra el comunismo. (Public Domain, Link)

Cuatro años después, cuando el apoyo al Macartismo decayó, Codd decide volver e incluso nacionalizarse estadounidense. De nuevo obtuvo trabajo en IBM y se dedicó a terminar su formación académica. Completó el doctorado en la Universidad de Michigan en Ann Arbor en 1965.

El hecho de tener una formación brillante y haber dedicado media vida a la empresa no parece que impresionara mucho a sus supervisores, dado que en 1967 realizaron una evaluación negativa de su trabajo y fue derivado a un laboratorio de menor nivel en San José (California).

Curiosamente, ese hecho aparentemente negativo supuso un golpe de suerte para él, dado que fue en San José donde tomó contacto con el incipiente mundo de las bases de datos y, a la larga, escribiría una de las páginas de oro de la computación.

Así estaban las cosas

A finales de los 60, los modelos de datos jerárquicos y en red (con Codasyl a la cabeza) lideraban el mercado, cada vez más demandado y competitivo, del tratamiento automatizado de la información. Era algo evidente que en el futuro cercano, como podemos comprobar hoy día, quien tuviera el control de la información tendría el poder. Era una batalla entre grandes corporaciones para tomar las posiciones de cabeza, ahora que la era de las tarjetas perforadas iba quedando atrás a pasos agigantados.

El gigante IBM había apostado fuertemente por el modelo jerárquico. La poderosa compañía creada 60 años atrás por el inventor de las tarjetas perforadas quería afianzarse como líder indiscutible y no iba a escatimar esfuerzos. En 1968 presenta su sistema IMS, derivado de uno anterior que se había creado nada menos que para el programa Apolo de la NASA.

IMS se basa en un modelo jerárquico, es decir, su estructura es de árbol, compuesto de nodos, que representan las entidades (por ejemplo, un cliente), enlazadas por arcos, que representan asociaciones (por ejemplo, un cliente con sus facturas). A diferencia de los sistemas en red, donde el grafo es más flexible, en estos sistemas no es posible acceder a la información como no sea a través de las asociaciones padre-hijo. Esta característica, en aquellos tiempos en los que el hardware era muy limitado, se consideraba una ventaja para dar un mayor rendimiento a las transacciones (inserciones, modificaciones y borrados) en la base de datos.

Por supuesto, el mantenimiento de toda esta estructura en árbol se lleva a base de punteros, es decir, cada nodo contiene información de direccionamiento que permite localizar a sus hijos, a los hijos de los hijos, y así sucesivamente. Cualquiera que haya programado alguna vez se dará cuenta de lo complicado y propenso a errores que podría llegar a ser cualquier procesamiento sobre semejante estructura.

IMS tenía muchas ventajas que lo hacían robusto y eficiente, de hecho siguió evolucionando y aún hoy sigue utilizándose.

Pero, como tantas veces ha ocurrido, alguien con otra visión tenía que venir para hacer ver que lo que todo el mundo veía como ventajas, en su justa medida, eran más bien inconvenientes. Y, muy a su pesar, ese revolucionario le iba a surgir a IBM de dentro de sus propias filas.

Surge la idea

Ted Codd no estaba muy satisfecho con el modelo jerárquico de IBM y empezó a redactar informes describiendo nuevas formas de organizar los datos. Esos trabajos eran internos y, paradójicamente, pudieron ver la luz en un ámbito científico y abierto precisamente porque dentro de la empresa a nadie, literalmente nadie, le importaba lo más mínimo.

Ni siquiera el propio Codd estaba convencido de que aquello fuera más allá de una curiosidad teórica cuando, en 1970, publicó sus investigaciones en la prestigiosa revista Communications of the ACM. El título del artículo fue "A relational model of data for large shared data banks" (Un modelo de datos relacional para grandes bancos de datos compartidos) (PDF).

Su idea más brillante, a mi modo de ver, fue olvidarse de la ubicación física de los datos, de los malditos punteros y direccionamientos, de las series de registros secuenciales, etc. Codd, en su lugar, definió un modelo matemático abstracto, en el cual los datos se organizaban en entidades llamadas relaciones, definidas como conjuntos de tuplas.

Una relación es como un fichero o un nodo jerárquico, pero de la que no necesitas conocer su ubicación; te basta con llamarla por su nombre. ¡Simple!
Una tupla es como un registro de un fichero, pero el cual es localizable por su contenido, no por su dirección. Ciertos datos contenidos en la propia la tupla nos sirven para identificarla y distinguirla de las demás, es la clave principal (la clave para un producto podría ser, por ejemplo, su modelo y número de serie).

Al no tener direcciones, las tuplas no tienen ubicaciones específicas dentro de la relación, ni tampoco hay un orden establecido. ¡Efectivamente! Las relaciones son conjuntos de elementos en el sentido abstracto y matemático del término. Con esta radical simplificación, Codd liberaba al usuario del sistema relacional del corsé de la estructura de almacenamiento, sólo debía preocuparse por el qué y no por el cómo. En sus propias palabras: "Los usuarios de los futuros bancos de datos deberán ser protegidos de tener que saber cómo están organizados los datos en la máquina (la representación interna)".

De la incomprensión a la indiferencia

Como ya hemos dicho, IBM había apostado fuertemente y estaba haciendo enormes inversiones en su sistema jerárquico IMS. Las ideas teóricas e imaginativas de un empleado no muy bien considerado de un laboratorio de segundo nivel no iban a demoler todo eso de la noche a la mañana. Es más, podemos decir que, en la compañía que lo vio nacer, el brillante modelo relacional encontró, no ya oposición, sino más bien incomprensión e indiferencia.

Codd siguió a lo suyo, y un año después ya tenía listo otro de los pilares de su teoría: la normalización. En este caso, el artículo no se publicó abiertamente, sino que apareció en un principio como informe técnico interno de la empresa. En él se definían las tres reglas (formas normales) que debían cumplir las bases de datos relacionales. Con ellas se conseguía evitar la redundancia de los datos y garantizar su integridad.

Para explicar estos conceptos eminentemente matemáticos con un lenguaje sencillo, lo mejor que se me ocurre es poner un par de ejemplos de problemas que podemos llegar a tener si no normalizamos nuestra base de datos:

Si rellenamos la dirección de un cliente cada vez que le emitimos una factura, lo más probable es que terminemos con varios domicilios distintos, sin saber cuál es el correcto, y que sea un dolor de cabeza cada vez que haya que actualizar sus datos de contacto. La redundancia es mala, ¡caca!
Los movimientos de una cuenta bancaria deberían estar indisolublemente ligados a dicha cuenta. Debería ser imposible eliminar una cuenta del sistema sin eliminar sus movimientos, y no debería haber ningún movimiento sin cuenta asociada. La integridad y la dependencia funcional entre datos no son solo condicionantes teóricos; surgen de la vida real, del modelo vivo del que el sistema de información pretende ser imagen. Sin ellos la base de datos se terminará llenando de basura y perdiendo valor.

En los años siguientes, Codd siguió publicando sus conclusiones ante la indiferencia de su empleador. Lo hizo tanto internamente como en publicaciones en la revista de la ACM. Sin embargo, algo ocurrió en 1978.

Y por fin cambiaron las cosas

En una reunión técnica rutinaria, el modelo relacional de Codd llegó a oídos del presidente de la compañía, Frank Cary, quien empezó a interesarse en aquello.

Unos años más tarde, IBM lanzaba su primer producto relacional, el SQL/DS, y un poco después, DB2. Habían perdido un tiempo precioso, puesto que las publicaciones de Codd habían calado en el ámbito académico y la Universidad de California en Berkeley, con financiación en parte de las Fuerzas Armadas, se había adelantado sacando al mercado Ingres, el primer sistema relacional. También se le adelantó Oracle, al introducir por primera vez en 1979 el lenguaje SQL, derivado del cálculo de predicados que había postulado Codd.

Doce reglas para dominarlos a todos

En 1985, crecido por el espectacular éxito de su modelo, Codd publicó en Computerworld otro artículo seminal: "Is Your DBMS Really Relational?" (¿Es tu sistema de base de datos realmente relacional?).

Como todo producto de éxito, los fabricantes se habían lanzado a llamar "relacional" a cualquier cosa que produjeran. El objetivo del nuevo artículo de Codd fue poner un poco de orden, dictando 12 reglas para validar en qué medida un modelo de datos se ajustaba a sus principios relacionales. Bueno, en realidad eran 13, pero Codd las numeró desde el cero, quizá por superstición, aunque nunca he encontrado un referencia a este detalle.

No voy a enumerar las reglas, porque sería farragoso y ya hay numerosas fuentes en Internet que lo hacen. Sólo voy a citar a la más enigmática y autorreferencial, la regla cero, que nos hace ver que Ted Codd también era amigo de Perogrullo: