[DEBATE]Modelo Entidad-Relacion VS Modelo Relacional

[gnzsoloyo]

Tengo la impresión de que tienes algunas confusiones conceptuales respecto de "Modelo Relacional" y "Modelo Entidad-Relación", y su aplicación tanto en el área de sistemas como del de las Bases de Datos.
Empecemos haciendo algunas aclaraciones:

- Modelo Entidad-Relación no es "solamente el diagrama". El modelo E-R es un modelo teórico y el diagrama es solamente su representación, la cual no tiene directa vinculación con las bases de datos, porque el modelo E-R es en realidad un modo de analizar los sistemas, y no los datos. El objetivo principal es el diseño estructurado de sistemas, del cual el modelo de datos es sólo una parte.

- Modelo Relacional no es el diagrama de tablas. Este ni siquiera se denomina así. Modelo Relacional es el modelo teórico desarrollado por Codd en 1970, sobre el que se basan todos los desarrollos posteriores de las bases de datos relacionales, pero no es aplicable en forma directa, ya que lo que hace es análisis a nivel lógico. En el modelo relacional no se trabaja con datos, sino con relaciones, entidades y conjuntos. Y las operaciones que se realizan se hacen con Algebra Relacional y Cálculo Relacional, ninguno de los cuales es utilizable en forma directa en el mundo de los datos.

- Lo que tu estás llamando "Modelo Entidad Relación", y "sólo diagrama", es la etapa del DER Lógico, donde se analizan las Entidades del sistema y sus relaciones. Pero es un diagrama de tipo teórico que sirve para lograr un acercamiento al modelo de sistema y los flujos de datos que originará, y sobre esa base establecer los requerimientos de datos necesarios. Como etapa previa, no es utilizable en forma directa.

- Lo que estás llamando "Modelo Relacional", es en realidad el DER Físico, o Modelo Físico de datos, que es una transformación del DER Lógico a estructuras de tablas, previo a la normalización. No son excluyentes uno de otro, sino que uno es consecuencia del otro, pero especialmente, el DER Lógico no da solamente origen al Modelo Físico, sino al diseño del software, de los sistemas de comunicación, el diseño de clases y objetos, los mensajes, las dependencias, las librerías y un largo etcétera.

La cosa es que si bien es común suprimir la creación del DERL y directamente crear el DERF, seguir la secuencia natural ayuda a evitar estar bocetando constantemente sobre el DERF, por cuanto muchísimas redundancias, errores de análisis e inconsistencias se hacen manifiestamente visibles cuando trababajas el DERL primero. Una vez que lo tienes bien definido, el resto de los pasos (Clases, DFD, DERF, etc.) se vuelven mucho más simples y sencillos, y sin tantos errores.

Hacer directamente el DERF, y que este resulte optimo y bien desarrollado, requiere de mucha experiencia y sólo he visto que lo hagan bien aquellas personas que han estudiado el tema en la Universidad. No he visto, hasta ahora, ningún autodidacta que lo logre, porque dominarlo requiere el conocimiento y dominio mentalmente del paso previo, el DERL, a niveles que sólo con una guía profesional se logra.
Puede parecerte exagerado, pero el objetivo de la enseñanza de Análisis de Sistemas antes de Bases de Datos tiene su fundamento en que para entrar en BBDD bien parado tienes que haber aprendido a pensar como analista, a razonar como analista, a ver el mundo como analista.
Y no hay manuales que enseñen eso.

Por tanto: DERL y DERF (según se entiende lo que dices), son necesarios ambos, interdependientes y sólo puedes suprimir uno de ellos (cuando no es por fiaca), con experiencia y estudio.

Ahora bien, yo he visto modelos de datos de bases empresariales que han ido siendo modificadas por sucesivas adaptaciones a un entorno cambiante. Esto ha hecho que la distancia entre el modelo físico implementado y el modelo físico originalmente diseñado se haya transformado en un abismo insalvable. Asimismo, el modelo lógico ha ido sufriendo otro enorme conjunto de cambios al punto de no guardar relaciones con su diseño original.
El resultado es que existe cierta dificultad para la software factory (SF) para lograr implemtnar los cambios futuros, porque el análisis de impacto se vuelve extremadamente dificultoso ya que no existe una documentación del modelo lógico que permita hacer un seguimiento simple del impacto que un cambio , por menor que sea, tiene en el sistema.
Esta es probablemente la razón por la cual es siempre una muy buena idea no saltarse las etapas: Cualquier modificación ulterior debe tener suficiente documentación sobre el modelo del sistema hasta un nivel de desagregación muy básica, tal que permita conocer las consecuencias de un cambio, antes de que el mismo entre en producción.

Como experiencia de terceros, he visto suceder que un error de implementación por documentación deficiente de las relaciones entre entidades, se hayan perdido los datos contables de cinco años de 12.000 afiliados a un sistema de medicina prepaga (seguro médico). REcuperar parcialmente los datos desde los backups (Ley de Murphy: Los backups nunca están suficientemente actualizados) resultó una tortura, y requirió de reinstalar los sistemas anteriores, antes de comenzar a hacer nueva reingeniería para ver dónde se había metido la pata.

Por supuesto que no se trata de situaciones diarias, pero resolver los problemas de diseño en la mente, no es suficiente para crear un sistema seguro, y menos para que los siguientes responsables (cuando el diseñador ya no está en la empresa), puedan trabajar sin sobresaltos.

En definitiva: Saltarse etapas, ir directamente a las implementaciones y resolver en la mente los problemas de normalización y consistencia, es algo que sólo debería existir para los trabajos hogareños, o para los hobbies. Los profesionales en el ramo tenemos cierta responsabilidad de hacer las cosas bien, no solo para nosotros y nuestro respeto a la profesión, también como consideración a los analistas que nos suplan cuando nos hayamos ido a trabajar a otra empresa.