En general, se diseña un diagrama E/R antes de definir las tablas. En el contexto de los proyectos, hemos detectado muchos problemas con los diagramas E/R entregados, pues los datos ya vienen como tablas. Igual, en muchos casos las tablas crudas están mal diseñadas, y la mejor forma de resolver este problema es definir un diagrama E/R y luego convertir ese diagrama a un modelo relacional más limpio.

Igual, se generan complicaciones al intentar interpretar un diagrama E/R de tablas con problemas conceptuales, como en el caso de muchos de los conjuntos de datos usados en los proyectos.

Algo que funciona muy mal, por ejemplo, es definir una entidad para cada tabla CSV y luego conectarlas con rombos arbitrarios. Falla la estrategia porque el diagrama E/R no corresponderá con los datos base, y de todos modos, los datos base tienen un mal diseño. Quedará mal porque los rombos también representan tablas (salvo en casos excepcionales, como relaciones débiles), y es muy probable que algunas de las tablas base son relaciones (rombos) en vez de entidades (cajas). No solo eso, pero muchas veces las tablas pueden “ocultar” entidades, pueden contener los datos de varias entidades y relaciones, pueden tener nulos, etc.

Más concretamente, en la preparación de su diagrama E/R para el proyecto, deberían evitar estos errores comunes que, muchas veces, son síntomas de lo descrito anteriormente:

• Los atributos de una entidad no pueden contener los atributos de otra entidad
• Entidades débiles deberían tener una llave parcial
• No se pueden reemplazar relaciones con entidades débiles
• Evitar poner múltiples relaciones en vez de roles

Ver los ejemplos a continuación.

Considerar, por ejemplo, datos CSV con un esquema así:

Estudiante(_rut_,nombre)
Curso(_código_,nombre)
NotaFinal(_rut_,_código_,valor)

Para la entidad NotaFinal en el diagrama E/R, no es válido agregar código o rut como atributos, pues son atributos de otras entidades (código de Curso, rut de Estudiante). Entonces algo así sería mal (por varios razones, pero la raíz de los problemas es poner atributos de una entidad como atributos de otra):

Hay que representar las relaciones entre entidades con relaciones (rombos) en el diagrama E/R, no con atributos compartidos. De hecho, en este caso, un buen diagrama E/R sale mucho más simple:

Ojo que dos o más entidades pueden tener atributos con el mismo nombre sin problema si realmente son de esa entidad; por ejemplo, nombre de Estudiante es diferente acá que nombre de Curso.

Considerar, por ejemplo, datos CSV con un esquema así:

Nota(_rut_,_curso_,nota,notaRevisión)

donde notaRevisión es nulo en muchos casos, pues muchos estudiantes aprobaron la primera vez y no tienen que entregar una revisión. Así, notaRevisión no puede ser atributo de Nota pues no pueden ser nulos los atributos de entidades. En ese caso, podemos pensar en una entidad débil Revisión, pero no va a tener una llave parcial; la llave de esa entidad será exactamente la llave de Nota sin otro elemento adicional.

En este tipo de caso, es mejor pensar en una jerarquía de clases, con Nota como súper-clase, y NotaConRevisión como sub-clase. Ojo que así, NotaConRevisión va a heredar la llave de Nota (como queremos). No hay problema con tener solo una sub-clase.

En resumen, al crear una entidad débil sin llave parcial, indica un problema. Una alternativa puede ser una clase de jerarquía, donde las sub-clases son la misma entidad pero con la información opcional/adicional incluida. De haber múltiple grupos de información opcional, puede resultar en varias sub-clases, como NotaConRevisión, NotaConAusencia, etc.

Considerar, por ejemplo, datos CSV con un esquema así:

Estudiante(_rut_,nombre)
Inscripción(_rut_,_códigoCurso_,nombreCurso)

En este caso, hay que evitar definir Inscripción como una entidad débil con llave parcial de códigoCurso.

Eso porque realmente representa una relación entre dos entidades: Estudiante y Curso, con la relación (rombo) inscribe entre ambas.

Lo que pasa en ese caso es que los datos no dan una tabla para Curso, pues tienen un mal diseño. Así que queda una entidad “oculta” acá, pero realmente hay una entidad Curso, que tiene una identidad independiente mediante su código, y el diseño conceptual queda más simple:

Este diagrama E/R nos va a dar un mejor esquema relacional así:

Estudiante(_rut_,nombre)
Curso(_códigoCurso_,nombre)
Inscribe(_rut_,_códigoCurso_)

Por si acaso, se puede comparar el caso previo con un caso en que necesitamos una entidad débil:

Curso(_código_,nombre)
Tarea(_códigoCurso_,_nombreTarea_,fechaInicio,fechaTérmino)

En este caso, la tabla Tarea no representa una relación entre dos entidades con su propia identidad (hay Curso pero no hay una segunda entidad identificable), sino representa una entidad débil Tarea cuya identidad depende de Curso. Entonces en este caso necesitamos una entidad débil.

Considerar, por ejemplo, datos CSV con un esquema así:

Tesis(_carrera_,_rutEstudiante_,nombreEstudiante,rutGuía,nombreGuía)

Según la llave, podemos asumir que un estudiante puede tener al máximo una tesis por grado (p.ej., Magíster del DCC), y un profe guía por tesis/grado.

Se puede ver que la tabla mezcla varias entidades y relaciones. En un primer intento, podemos pensar en algo así:

Pero no es correcto, pues al separar las relaciones así en dos relaciones binarias, no vamos a saber qué guía está asociado con qué estudiante. Mejor así con roles:

Ahora tenemos una relación que conecta el estudiante, el profe guía, y el grado. Lo que tenemos ahora es una relación ternaria que usa la misma relación dos veces (con roles).

Ojo que en la relación nueva, no tenemos una forma de definir bien que un estudiante tiene al máximo una tesis por grado (solo podemos decir que un estudiante tiene al máximo una tesis), pero podemos agregar esa información luego en el modelo relacional con una llave primaria.

En resumen, si tienen varias relaciones entre el mismo par de entidades, hay que pensar si realmente son relaciones distintas, o mejor combinarlas en una relación con roles.