En 1970, Edgar Frank "Ted" Codd publicó A Relational Model of Data for Large Shared Data Banks, libro en el que exponía las ideas centrales sobre la creación y funcionamiento de las bases de datos relacionales. Por algún motivo, se sorprendió de que su empresa, IBM, no se apresurara a convertir sus planteamientos en programas funcionales, cuando, en realidad, eso se puede considerar el sello identificador de IBM. De hecho, no puso manos a la obra hasta que Oracle, basándose en el libro de Codd, comenzó a producir bases de datos comerciales. Pero la explosión de las mismas vino de otro lado.
En 1978, Wayne Ratliff trabajaba para el Jet Propulsion Laboratory (JPL), cuyo personal tenía por costumbre hacer una porra semanal sobre los partidos de la NFL. Aunque a Ratliff parece que no le interesaba demasiado el fútbol americano, pensó que podría superar a sus colegas generando predicciones que se basasen en las estadísticas que se publicaban sobre cada partido. Tomó entonces una vieja base de datos que se empleaba en el JPL llamada RETRIEVE y la adaptó para sus necesidades. Le dio el nombre de Vulcan por el origen del Mr. Spock de la serie Star Trek. No consta si Ratliff consiguió realmente batir a sus compañeros con sus predicciones, pero Vulcan demostró una enorme versatilidad para el desempeño de tareas diversas, tanto que los dueños de Ashton-Tate, la primera empresa en vender software por correo, se interesaron por la criatura de Ratliff, llegando a un acuerdo comercial con él. Había nacido dBase.
dBase escaló hasta dominar por completo el sector de las bases de datos domésticas en los años 80. Expandido primero a lomos de los ordenadores fabricados por Apple, su salto al entorno Windows le abrió la puerta de millones de hogares. En cierta medida, su popularidad lo mató. Hacia finales de los 80, los ordenadores habían dado paso en las empresas a las redes locales y con ellas llegó SQL, la tardía pero eficaz respuesta de IBM a las ideas planteadas por Codd. Los directivos de Ashton-Tate decidieron coger el toro por los cuernos y crear dBase IV, capaz de abastecer redes locales y entenderse con SQL. Sin embargo, al mercado llegó una versión desastrosamente lenta e inestable, que dejó la puerta abierta a rivales como Paradox y Clipper. Para entonces, un nuevo y más desafiante problema se hallaba en ciernes.
Si las bases de datos habían seguido el paradigma de Codd, los lenguajes para redes cada vez más extensas que aparecieron en los años 90, habían crecido siguiendo el paradigma de los algoritmos, pues, en esencia, todo programa no constituye más que un algoritmo. En los algoritmos hay un nodo de inicio y una sucesión de pasos en forma de árbol que va escindiéndose en ramales, más conocidos como subrutinas. En consecuencia, cuando hay que tratar con datos, los lenguajes informáticos, al igual que los naturales, los entienden como objetos, quiero decir, como un nodo que se conecta con varias propiedades, campos o características. Sin embargo, una base de datos relacional como dBase, como todas las que siguen las ideas de Codd, contienen una sucesión de tablas, por ejemplo, todos los colores posibles de un coche, todos los motores posibles de un coche y todos los terminados de tapicería posibles en un coche. Cuando uno trata con objetos y aparece uno nuevo con rasgos singulares, por ejemplo, cuando uno trata el organigrama de una empresa y se crea un nuevo departamento, no tenemos más que tomar un nodo concreto y añadirle un ramal más a los que ya tenía. Pero cuando uno trata con tablas, la aparición de un objeto nuevo significa que hay que volver a reescribir todas las tablas porque hay que organizar lo contenido en ellas de otra manera. Todavía me acuerdo la que había que liar en dBase cuando, después de haber construido una base de datos y haber empezado a meter registros te dabas cuenta de que se te había olvidado especificar un campo. A cambio, buscar algo en una tabla resulta mucho más rápido y fácil que ir recorriendo todos los nodos en los que puede hallarse la información. Dicho de otro modo, acoplar programas que tomaban en consideración objetos con bases de datos que tomaban en consideración relaciones significaba perder alguno de los rasgos que hacían a unos y otras tan útiles… A menos que se encontrase otra solución.
La solución consistió en crear lo que se llaman “motores de persistencia”. Un motor de persistencia consiste en un programa (o, como les gusta decir a los informáticos, una capa más de programación) que descompone los objetos en relaciones y que compone objetos a partir de relaciones. El motor de persistencia debe tener en cuenta la estructura del programa y la estructura de cada una de las bases de datos a las que se va a acceder desde él, de modo que si hay que incorporar una nueva base de datos, hay que añadirle líneas de código. A cambio, el usuario final puede hacer sus búsquedas y obtener resultados sin enterarse en absoluto de toda esta labor. Eso es precisamente lo que ocurre con nuestras búsquedas en Internet. La interfaz con la que buscamos, carga en la memoria RAM de nuestro ordenador un motor de persistencia que nos va a permitir acceder a datos colocados en bases de datos dispersas por todo el mundo y con estructuras dispares sin que nos demos cuenta de ello. Hasta tal punto no nos damos cuenta que los filósofos llevan tres décadas utilizando herramientas que demuestran el ridículo de uno de los principios básicos que ha movido a la filosofía durante esas tres décadas. En efecto, cualquier motor de persistencia hace cotidianamente para nosotros lo que los filósofos dieron por “imposible”, traducir entre dos lenguajes no ya con palabras o gramáticas “diferentes” o “alejados”, sino que presentan estructuras ontológicas toto caelo dispares, hasta el punto de que no existe un par de idiomas humanos que presenten una heterogeneidad semejante a la de un lenguaje basado en objetos y otro en relaciones. Por supuesto, los motores de persistencia no carecen de problemas y de desafíos por vencer, pero demuestran, en cada búsqueda que efectuamos con ellos, una funcionalidad que los filósofos vienen negando a cualquier género de traducción.
No hay comentarios:
Publicar un comentario