Las bases de datos relacionales

Una base de datos relacional guarda la información en tablas, filas y columnas de valores sencillos, y responde a las preguntas cruzando tablas en lugar de seguir punteros de una ficha a otra. Es la arquitectura que sostiene casi todos los sistemas de información serios desde hace medio siglo: bancos, aerolíneas, hospitales, administraciones. La idea la publicó Edgar Codd en 1970, desde un laboratorio de IBM, y en su momento fue una herejía. Codd propuso que el programador declarase qué datos quería y dejase al gestor el cómo conseguirlos, cuando todo lo que existía obligaba a recorrer la estructura a mano, registro a registro.

El antecedente es mucho más viejo que el ordenador. El catálogo de fichas de una biblioteca, que Melvil Dewey popularizó en el siglo XIX, ya era una base de datos: un registro por obra, campos en posiciones fijas, y la regla de que no puede haber dos fichas iguales. Su límite era físico. Las fichas solo admitían un orden, así que solo admitían una clase de pregunta: si el cajón estaba ordenado por autor, buscar por título exigía un segundo catálogo entero. Los primeros sistemas informáticos heredaron la trampa con la excusa del hardware. El modelo jerárquico de IBM IMS (1966) y el modelo en red del comité CODASYL (1969) organizaban los datos como árboles y grafos de punteros, rápidos para las preguntas previstas y ciegos para las demás: cada pregunta nueva exigía reprogramar el recorrido.

Codd desmontó el problema. Su modelo define una relación como un conjunto matemático de tuplas con los mismos atributos, que es lo que todos llamamos hoy tabla, y de la palabra «conjunto» se siguen dos reglas que parecen triviales y lo son todo: las filas no tienen orden y no hay dos filas iguales. La primera figura las pone a prueba. La consulta que se va componiendo con los controles aparece escrita en SQL encima de la tabla, y cada control corresponde a una de las operaciones de Codd: WHERE elige filas (la selección), SELECT elige columnas (la proyección), ORDER BY pide un orden. Al pulsar «Pedir la tabla otra vez» las filas llegan barajadas, porque el orden que se ve es el de la respuesta y no el de la tabla; con ORDER BY, en cambio, la respuesta sale siempre igual aunque el gestor guarde las filas como quiera. Y al intentar insertar una fila que ya estaba, la fila no entra. El resultado de cada operación vuelve a ser una relación, así que las preguntas se componen unas con otras, y esa clausura es lo que hace que el álgebra funcione.

El lenguaje llegó de la misma IBM. Donald Chamberlin y Raymond Boyce diseñaron SEQUEL en 1974, luego SQL, como un inglés estructurado que describe el resultado y no el camino: SELECT, FROM, WHERE. La utilidad práctica del modelo nace de la composición de esas piezas con JOIN, que cruza dos tablas por una condición de emparejamiento. La pregunta «qué libros ha escrito cada autor» no sigue ningún puntero; declara que el autor de un libro tiene que coincidir con el identificador de un autor, y el gestor decide cómo ejecutarlo, con qué índice y en qué orden. La declaración, no el recorrido, es la revolución.

Para que dos tablas se puedan cruzar hace falta un contrato entre ellas, y ese contrato son las claves. La clave primaria identifica cada fila, en la figura la columna id, subrayada. Una clave externa es una columna que toma sus valores prestados de la clave primaria de otra tabla: la columna autor de libros guarda el id de una fila de autores, y esa referencia es lo que convierte un montón de tablas en una base. La segunda figura la dibuja con líneas y con un color por autor, y deja al descubierto la regla que la protege, la integridad referencial. Añadir un libro cuyo autor sea el 9 cuando no existe ningún autor 9 termina con la fila rechazada entera; borrar un autor que todavía tiene libros termina con el gestor negándose, porque dejaría referencias a nada. El borrado en cascada, que la figura activa con un botón, es la decisión opuesta: permitir el borrado a cambio de que se lleve consigo a sus dependientes. Lo importante es quién aplica la regla. La aplica el gestor, una vez, para todos los programas que toquen esas tablas, y la coherencia deja de depender de que cada programador se acuerde de comprobarla.

Codd vio también que no basta con decidir qué tablas hay, sino hasta dónde hay que partir los datos. Su artículo de 1971 sobre la normalización parte de una observación incómoda: una tabla que lo guarda todo en la misma fila repite datos, y repetir datos es invitar a tres anomalías. La tercera figura las ejecuta, y las ejecuta en cada paso del camino, porque lo instructivo no es ver que fallan sino ver cuándo dejan de fallar. La anomalía de actualización: Ana Ruiz se muda, su dirección está en varias filas, se cambian todas menos una y la base afirma dos direcciones para la misma persona sin que nadie haya escrito nada mal. La de inserción: llega una clienta que todavía no ha pedido nada y no hay fila donde guardarla, porque la fila necesita un número de pedido que no existe. La de borrado: se archiva el único pedido de Carmen Díaz y su dirección se va con él, sin que nadie haya decidido borrar a la clienta.

La cura son las formas normales, y la figura las recorre. La primera parte la celda «libros», que guardaba dos títulos con sus precios, en una fila por línea de pedido; la repetición empeora, y eso es honesto, porque la primera forma normal solo hace explícito lo que ya estaba mal. La segunda saca del pedido lo que depende de la clave entera, separando pedidos de líneas. La tercera manda cada dato a la tabla de la cosa que describe: la dirección es de la clienta, el precio es del libro, y cada uno vuelve a casa. La regla que resume las tres formas dice que cada dato depende de la clave, de la clave entera y de nada más que la clave. El premio se comprueba con los mismos tres botones: en cuatro tablas sin nada repetido, cambiar la dirección de Ana toca una sola fila, Marta Sanz entra en clientes sin pedido alguno, y borrar el pedido de Carmen borra un pedido.

Queda la pregunta física, la que Codd se permitió ignorar porque era asunto del gestor. Si las filas viven en disco, ¿cómo se encuentra una entre millones sin leerlas todas? El catálogo de fichas ya sugería la respuesta, un segundo catálogo ordenado de otra manera, y el hardware la hizo indispensable. El IBM 305 RAMAC de 1956, la primera máquina con disco duro, podía leer cualquier registro sin pasar por los anteriores, pero cada lectura costaba mil veces más que un acceso a memoria. Desde entonces la unidad de coste en bases de datos es la página de disco, unos pocos kilobytes que se leen de golpe, y toda la ingeniería consiste en tocar el menor número posible de páginas.

El índice que lo resuelve es el árbol B, que Rudolf Bayer y Edward McCreight publicaron en 1972: un árbol de búsqueda con muchas claves por nodo, pensado para que cada nodo ocupe exactamente una página. La última figura lo construye inserción a inserción sobre unas páginas de datos que guardan las filas en el orden en que llegaron, que es como quedan en la realidad. Cuando un nodo se llena se divide en dos y la clave del medio sube al padre, y esa regla mantiene todas las hojas a la misma profundidad: el árbol crece hacia arriba y nunca hacia un lado, por mal que lleguen las claves, al revés de lo que le pasa a el árbol binario de búsqueda con los datos ordenados. Buscar una clave sin índice es leer las páginas de datos una tras otra; buscarla con índice es bajar desde la raíz tocando un nodo por nivel. La figura hace las dos búsquedas sobre la misma clave y cuenta las páginas de cada una. A este tamaño la diferencia es modesta; con un millón de filas, un recorrido lee cientos de miles de páginas y el índice sigue tocando tres o cuatro, y esa es la diferencia entre un sistema que responde y uno que no.

Lo que consolidó al modelo relacional no fue solo la elegancia sino que encajó con lo que la industria necesitaba justo entonces. Las transacciones bancarias exigían garantías que el modelo declaraba como propiedades del gestor y no como deberes de cada programa, la atomicidad y el resto de las siglas ACID que Jim Gray formalizó en 1976 y que la transacción informática trata por separado; y las consultas improvisadas de los analistas exigían precisamente la flexibilidad que los punteros negaban. Medio siglo después el modelo ha absorbido un rival tras otro, los almacenes de objetos de los noventa, las bases NoSQL de los años diez, que devolvieron los punteros en forma de documentos anidados, y sigue ahí, normalizado hasta el tuétano. Las cuatro figuras de esta página recorren sus cuatro ideas: la relación como conjunto, la clave como contrato, la normalización como higiene y el índice como truco físico. La primera es la que envejece mejor, porque es matemática. Todo lo demás es ingeniería, y la ingeniería se reemplaza.