Hubo un tiempo en el que pensé que el lenguaje Entidad-Relación (Entty-Relationship o ER) había pasado su mejor momento. Pero ahora veo que estaba equivocado, muy equivocado. El lenguaje ER está más fuerte, más de moda que nunca.

Voy a intentar explicar el porqué cambié de opinión. ¡Veamos si estás de acuerdo!

Breve introducción al lenguaje ER

Propuesto originalmente por Peter Chen en 1976 en el artículo El modelo entidad-relación: hacia una vista unificada de los datos, el lenguaje ER rápidamente se hizo muy popular en la comunidad emergente (en ese momento) de bases de datos. De hecho, el lenguaje ER se convirtió en el estándar de facto para el diseño de bases de datos, con muchos proveedores (empezando por la mayoría de las empresas que vendían sistemas de gestión de bases de datos relacionales) que ofrecían entornos de modelado para diagramas ER con la posibilidad de traducir automáticamente dichos modelos a scripts SQL DDL.

Como sugiere el nombre, los elementos clave del lenguaje ER son las entidades y las relaciones. Las entidades son equivalentes a objetos en el mundo orientado a objetos (es decir, una persona específica, un producto o un evento) y las relaciones son los vínculos entre estas entidades. Las entidades similares se agrupan en conjuntos de entidades, también conocidos como tipos de entidad (entity types). Del mismo modo, las relaciones se agrupan en tipos de relación (relationship types). Claramente, los tipos de entidad se parecen al concepto de clases en la terminología orientada a objetos, mientras que los tipos de relación serían el equivalente de asociaciones. Los tipos de entidad también pueden tener atributos. Tanto los atributos como los tipos de relación pueden estar restringidos por relaciones de multiplicidad.

Se propusieron varias extensiones del lenguaje ER original, comúnmente conocidas como la familia de lenguajes EER (“Lenguajes de Entidad-Relación Extendido”). Una de estas extensiones clave agregó relaciones de herencia entre tipos de entidad.

Dado este conjunto limitado de conceptos de modelado, es fácil ver que el mapeo desde modelos ER a esquemas de bases de datos relacionales era una traducción casi directa. Más que nada la complicación real al principio, cuando muchos proveedores aún no seguían estrictamente el esquema SQL, era poder generar scripts SQL para todos los diferentes “sabores” de SQL existentes en ese momento.

Los años oscuros del ER

ER siempre tuvo su comunidad, especialmente en el mundo de las bases de datos, pero perdió su atractivo en la comunidad más amplia de desarrollo de software.
En mi humilde opinión, por dos razones:

  • La llegada de UML. Con UML puedes modelar todo lo que puedes modelar con el lenguaje ER (o casi) y mucho más, ya que con UML puedes definir todas las dimensiones de tu proyecto de software y no “sólo” el esquema de tus datos (aunque para mí, esto sigue siendo el elemento central de todo proyecto)
  • La tendencia NoSQL. Con las bases de datos NoSQL, no hay un esquema fijo. Al menos en teoría, a mi me gusta decir que NoSQL no es realmente schema less, que, como mucho, podemos decir que es less schema, “menos esquema”, que otros datos. Pero aun así, la creación de esquemas de bases de datos pasó de moda.

La resurrección del lenguaje Entidad-Relación

Después de unos años, la gente entendió que UML tenía muchas cualidades, pero que venían con un coste a pagar, ya que era un lenguaje mucho más complejo que ER, por lo que si sólo querías crear una base de datos o construir una aplicación que básicamente fuera un envoltorio web sobre una base de datos (que podría ser fácilmente generado desde la base de datos en sí), tal vez era mejor idea abandonar la complejidad de UML y quedarse con el lenguaje ER, más simple. Y también fue pronto obvio que todos los proveedores de NoSQL estaban agregando soporte para SQL, ya que SQL era el único lenguaje que cualquier usuario conocía. Así que aunque internamente los datos se almacenaran utilizando una variedad de estrategias NoSQL, volvieron a traer la “ilusión” de un esquema parcial que podía, de nuevo, ser modelado.

Además, una señal clara de que un lenguaje está recibiendo cada vez más un rneovado interés es la creación de nuevas herramientas de modelado para él.

Y he sido testigo de esto en torno al lenguaje ER. Después de un tiempo, con solo algunas de las herramientas clásicas de diseño de bases de datos (por ejemplo, PowerDesigner que yo ya usaba hace más de 20 años ????), estamos viendo muchas nuevas iniciativas de herramientas, incluyendo herramientas ER en línea, herramientas de modelado textual ER, e incluso un complemento ER para VS Code.

Incluso me atrevería a agregar que la explosión del aprendizaje automático (o Machine Learning, ML) también ha ayudado, ya que ha dado mucha importancia a los conjuntos de datos requeridos para entrenar los modelos de ML. Y donde hay conjuntos de datos, hay la necesidad de describir dichos conjuntos de datos (y nada más, con lo que no es necesario usar un lenguaje de modelado completo como UML para eso).

En resumen, dada la clara importancia de los modelos de datos en todo tipo de iniciativas y la mejor comprensión que todos tenemos sobre las fortalezas y debilidades de ER en comparación con otros lenguajes, creo que ER seguirá siendo popular por mucho tiempo. Es cierto que la comunidad de ingeniería de software más estricta probablemente nunca lo adoptará, pero a veces tendemos a olvidar que hay muchas otras comunidades a nuestro alrededor que tienen necesidades diferentes y para las cuales el lenguaje ER podría ser perfecto.