Differences

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

--- proyecto:diagrama_er [2024/07/02 20:10] – ahogan
+++ proyecto:diagrama_er [2024/07/02 22:30] (current) – [Relaciones no pueden tener llaves] ahogan
@@ Line 1: / Line 1: @@
-======Indicaciones importantes para el diagrama E/R======
+======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. 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.
@@ Line 12: / Line 12: @@
   * **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**
@@ Line 53: / Line 54: @@
 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 88: / Line 90: @@
 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=====