Differences

This shows you the differences between two versions of the page.

--- proyecto:diagrama_er [2024/07/02 19:45] – [Indicaciones para el diagrama E/R] ahogan
+++ proyecto:diagrama_er [2024/07/02 22:30] (current) – [Relaciones no pueden tener llaves] ahogan
@@ Line 1: / Line 1: @@
 ======Indicaciones para el diagrama E/R======
-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 (muchas veces con un mal diseño), y se intenta interpretar un diagrama E/R de esas tablas.
+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.
-Algo que funciona muy mal, por ejemplo, es definir una entidad para cada tabla CSV y luego conectarlas con rombos arbitrarios. Eso porque los rombos también representan tablas (salvo en casos excepciones, como relaciones débiles), y es muy probable que algunas de las tablas base son relaciones (rombos), no entidades (cajas).
+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.
-Más concretamente, en la preparación de su diagrama E/R para el proyecto, deberían evitar estos errores comunes:
+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**
+  * **Relaciones no pueden tener llaves**
   * **Evitar poner múltiples relaciones en vez de roles**
 Ver los ejemplos a continuación.
 =====Los atributos de una entidad no pueden contener los atributos de otra entidad=====
@@ Line 20: / Line 24: @@
 Estudiante(_rut_,nombre)
 Curso(_código_,nombre)
-Nota(_rut_,_código_,valor)
+NotaFinal(_rut_,_código_,valor)
 </code>
-Para la entidad ''Nota'' 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):
+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):
 {{ :proyecto:er_atributos_incorrectos.png?400 |}}
-Las relaciones entre entidades hay que represantar con relaciones (rombos) en el diagrama E/R. De hecho, en este caso, puede salir algo mucho más simple:
+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:
 {{ :proyecto:er_simple_correcto.png?400 |}}
-Ojo que dos o más entidades pueden tener atributos con el mimso nombre sin problema si realmente son de esa entidad;  por ejemplo, ''nombre'' de ''Estudiante'' es diferente acá que ''nombre'' de ''Curso''.
+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''.
 =====Entidades débiles deberían tener una llave parcial=====
@@ Line 38: / Line 42: @@
 <code>
-Nota(_rut_,_código_,_año_,nota,notaRevisión)
+Nota(_rut_,_curso_,nota,notaRevisión)
 </code>
@@ Line 49: / Line 53: @@
 {{ :proyecto:er_jerarquia_de_clases.png?210 |}}
-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'', ''NotaConAusenciaJustificada'', etc.
+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.
 =====No se pueden reemplazar relaciones con entidades débiles=====
@@ Line 66: / Line 70: @@
 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 da 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:
+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:
 {{ :proyecto:er_correcto_con_relacion.png?400 |}}
@@ Line 85: / Line 89: @@
 </code>
-En este caso, la tabla ''Tarea'' no representa una relación entre dos entidades con su propia identitad (hay ''Curso'' pero no hay una segunda entidad identificable), sino representa una entidad débil ''Tarea'' cuya identitad depende de ''Curso''. Entonces en este caso necesitamos una entidad débil.
+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.
+=====Relaciones no pueden tener llaves=====
+Consider, por ejemplo, datos CSV con un esquema asi:
+<code>
+Estudiante(_rut_,nombre)
+Inscripción(_id_,rut,códigoCurso,nombreCurso)
+</code>
+Es un ejemplo muy parecido al ejemplo anterior, salvo que ahora, lo que tuvimos como una relación (''Inscripción''/''inscribe'') ahora tiene una llave ''_id_''. Pero no se puede hacer algo así, puedes relaciones no puede tener llaves así:
+{{ :proyecto:er_relacion_con_llave.png?400 |}}
+Hay dos opciones. La primera es ignorar el atributo _id_ de los datos, y simplemente usar (como antes):
+{{ :proyecto:er_correcto_con_relacion.png?400 |}}
+La otra opción es definir ''Inscripción'' con su ''_id_'' como una entidad ahora, dado que tiene una llave, y relacionarla con sus entitidades relacionadas mediante multiplicidades de exactamente uno:
+{{ :proyecto:er_relacion_como_entidad.png?400 |}}
+Ojo que dadas las relaciones de multiplicidad exactamente uno, se pueden combinar las tablas de ''de'' y ''en'' con la tabla de ''Inscripción''. El modelo relacional sería:
+<code>
+Estudiante(_rut_,nombre)
+Inscripción(_id_,rut,código)
+Curso(_código,nombre)
+</code>
+En el caso de que el mismo estudiante no pueda inscribir el mismo curso dos veces, se puede elegir la primera o la segunda opción. En el caso de que el mismo estudiante pueda inscribir el mismo curso varias veces, hay que elegir la segunda opción.
 =====Evitar poner múltiples relaciones en vez de roles=====
@@ Line 105: / Line 140: @@
 {{ :proyecto:er_roles.png?420 |}}
-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 donde usamos la misma relación dos veces (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.