El modelo relacional: la historia de los datos

En 1970, un matemático británico llamado Edgar Frank Codd publicó un artículo desde los laboratorios IBM en San José (California) que redefinió cómo entendemos y gestionamos la información. Su título era tan sobrio como revolucionario: “A Relational Model of Data for Large Shared Data Banks”.

Codd no estaba simplemente proponiendo una forma más ordenada de guardar datos. Estaba plantando la semilla de algo mucho más profundo: la independencia entre los datos y la forma en que los almacenamos. Hasta ese momento, las bases de datos eran rígidas, jerárquicas, casi laberínticas. Si querías llegar a un dato, tenías que saber exactamente dónde vivía dentro del sistema. Codd cambió eso para siempre.

Una idea sencilla… que cambió el mundo

El modelo relacional se basaba en dos pilares matemáticos:

• La teoría de conjuntos, que permite describir datos como colecciones.

• El álgebra relacional, que define operaciones lógicas sobre esas colecciones (seleccionar, proyectar, unir…).

O dicho en términos más humanos: los datos se organizan en tablas (relaciones), donde cada fila representa una entidad y cada columna un atributo. A partir de ahí, puedes formular consultas declarativas sin preocuparte de cómo están guardados físicamente los datos.

Tip técnico #1: si has usado SQL, cada vez que escribes un SELECT nombre FROM clientes WHERE pais = 'España';, estás aplicando una operación de proyección (nombre) y selección (país = España) sobre un conjunto relacional. Así de puro es el legado de Codd.

Cuando IBM no creyó en su propio genio

IBM tenía a Codd en nómina, pero no supo ver el potencial de su idea. El gigante seguía vendiendo sistemas jerárquicos como IMS y la propuesta relacional parecía demasiado teórica. De hecho, tardaron años en implementar un prototipo funcional: el famoso System R.

Mientras tanto, otros equipos sí entendieron el alcance del cambio. De esas ideas surgirían posteriormente Oracle, Ingres o PostgreSQL (este último, descendiente directo de Ingres, sigue siendo hoy una de las joyas de la ingeniería de bases de datos).

Tip técnico #2: el System R de IBM fue el primero en implementar algo parecido a SQL, que por entonces se llamaba SEQUEL. Si hoy te preguntas por qué SQL usa palabras “en inglés natural” (SELECT, FROM, WHERE…), es porque desde el principio se diseñó para ser legible por humanos, no por máquinas.

La independencia lógica

El objetivo de Codd era lograr lo que llamó “data independence”: que los programadores pudieran modificar la estructura física o lógica de los datos sin que las aplicaciones se rompieran.

En otras palabras, que el qué y el cómo estuvieran separados. Hoy nos parece obvio, pero fue una auténtica revolución conceptual.

Tip técnico #3: cuando usas una vista en SQL, estás aplicando exactamente esa idea. Una vista (CREATE VIEW...) abstrae la estructura real de las tablas y ofrece a los usuarios una interfaz estable, incluso si la base de datos subyacente cambia.

De la teoría a la práctica

Con el tiempo, el modelo relacional se convirtió en el estándar de facto. Nació el lenguaje SQL, los índices B-tree, las claves primarias y foráneas, los esquemas normalizados… y todo ese ecosistema que todavía define la capa estructural de Internet.

Incluso cuando llegaron las bases de datos NoSQL, lo hicieron como reacción: “no relacionales”. Pero, paradójicamente, muchas de ellas (como los motores documentales o las bases de grafos) acabaron incorporando principios relacionales para ofrecer consultas más expresivas.

Tip técnico #4 (nivel avanzado): las operaciones de join que tanto castigamos en SQL son la esencia del álgebra relacional. Si necesitas optimizarlas, recuerda que los motores modernos aplican hash joins o merge joins dependiendo del tamaño de los conjuntos y los índices disponibles. Puedes forzar una pista (USE HASH JOIN) en sistemas como SQL Server o PostgreSQL para entender cómo cambia el plan de ejecución.

Codd y la inteligencia artificial

Podría parecer que el modelo relacional pertenece a otra era, pero en realidad su influencia llega hasta el corazón de la inteligencia artificial actual. Cuando construimos datasets para entrenar modelos, lo que hacemos —en esencia— es definir relaciones entre entidades: ejemplos, atributos, etiquetas.

Cada dataset es una tabla, cada fila un vector, cada columna una característica. Los modelos de machine learning no existirían sin la estructura lógica y la integridad que el pensamiento relacional introdujo hace más de medio siglo.

Tip técnico #5: si trabajas con embeddings o datasets en IA, piensa en ellos como “tablas relacionales extendidas”. Los índices vectoriales (como los de FAISS o Milvus) son herederos conceptuales de los índices relacionales, adaptados a un espacio de alta dimensionalidad.

Hoy, más de cincuenta años después, el modelo relacional sigue siendo la base sobre la que se construyen aplicaciones, algoritmos y arquitecturas de datos. Codd no solo cambió la informática: enseñó a toda una generación de ingenieros a pensar en los datos como conocimiento estructurado.

Y eso, en un mundo dominado por la información, es tan vigente como en 1970.

Fuentes y referencias recomendadas:

• Codd, E. F. (1970). A Relational Model of Data for Large Shared Data Banks. Communications of the ACM.

• IBM Research: The Birth of the Relational Database.

• Stonebraker, M. The Design of Postgres.