El diagrama entidad-relación (ER) es una representación esquemática de los datos en las bases de datos, muestra cómo se relacionan los datos.
Nota: este artículo es para aquellos que ya saben qué es un diagrama ER y cómo dibujar un diagrama ER.
1) Cuando hay cardinalidades Muchos a Uno en el diagrama ER.
Por ejemplo, un estudiante puede estar inscrito solo en un curso, pero un curso puede estar inscrito por muchos estudiantes.
Para Student(SID, Name), SID es la clave principal. Para Course(CID, C_name ), CID es la clave principal
Student Course
(SID Name) ( CID C_name )
-------------- -----------------
1 A c1 Z
2 B c2 Y
3 C c3 X
4 D
Enroll
(SID CID)
----------
1 C1
2 C1
3 c3
4 C2
Ahora la pregunta es, ¿cuál debería ser la clave principal para Enroll? Debe ser SID o CID o ambos combinados en uno. No podemos tener CID como clave principal porque un CID puede tener varios SID. (SID, CID) puede distinguir la tabla únicamente, pero no es mínimo. Entonces SID es la clave principal para la inscripción de la relación.
Para el diagrama ER anterior, consideramos tres tablas en la base de datos
Student Enroll Course
Pero podemos combinar la tabla Student y Enroll renombrada como Student_enroll.
Student_Enroll
( SID Name CID )
---------------------
1 A c1
2 B c1
3 C c3
4 D c2
Las tablas de estudiantes y de inscripción ahora están fusionadas.
Por lo tanto, requiera un mínimo de dos tablas DBMS para Student_enroll y Course.
Nota: En las relaciones Uno a Muchos podemos tener un mínimo de dos tablas.
2. Cuando hay muchas a muchas cardinalidades en el diagrama ER.
Consideremos el ejemplo anterior con el cambio de que ahora un estudiante puede inscribirse en más de 1 curso.
Student Course
( SID Name) ( CID C_name )
-------------- -----------------
1 A c1 Z
2 B c2 Y
3 C c3 X
4 D
Enroll
( SID CID )
----------
1 C1
1 C2
2 C1
2 C2
3 c3
4 C2
Ahora, surge la misma pregunta. ¿Cuál es la clave principal de la relación Inscribirse? Si analizamos cuidadosamente, la clave principal para la tabla de inscripción es (SID, CID).
Pero en este caso, no podemos fusionar la tabla de Inscripción con ninguno de los Estudiantes y Cursos. Si tratamos de fusionar Enroll con cualquiera de Student y Course, se crearán datos redundantes.
Nota: Se requiere un mínimo de tres tablas en las relaciones Muchos a Muchos.
3. Relación uno a uno
Hay dos posibilidades
A) Si tenemos una relación Uno a Uno y tenemos participación total en al menos un extremo.
Por ejemplo, considere el siguiente diagrama ER.
A1 y B1 son claves primarias de E1 y E2 respectivamente.
En el diagrama anterior, tenemos participación total en el extremo E1.
Solo se requiere una sola tabla en este caso que tenga la clave principal de E1 como su clave principal.
Dado que E1 es una participación total, cada entrada en E1 está relacionada con una sola entrada en E2, pero no todas las entradas en E2 están relacionadas con una entrada en E1.
La clave principal de E1 debe permitirse como clave principal de la tabla reducida, ya que si se usa la clave principal de E2, podría tener valores nulos para muchas de sus entradas en la tabla reducida.
Nota: Solo se requiere 1 mesa.
B) Relación uno a uno sin participación total.
A1 y B1 son claves primarias de E1 y E2 respectivamente.
La clave principal de R puede ser A1 o B1, pero aún no podemos combinar las tres tablas en una sola. si lo hacemos, algunas entradas en la tabla combinada pueden tener entradas NULL. Entonces, la idea de fusionar las tres tablas en una sola no es buena.
Pero podemos fusionar R en E1 o E2. Por lo tanto, se requiere un mínimo de 2 mesas.
A continuación se muestra la pregunta del año anterior de Gate.
https://www.geeksforgeeks.org/gate-gate-cs-2008-question-82/
https://www.geeksforgeeks.org/gate-gate-cs-2008-question-83/
Escriba comentarios si encuentra algo incorrecto o si desea compartir más información sobre el tema tratado anteriormente.
Publicación traducida automáticamente
Artículo escrito por GeeksforGeeks-1 y traducido por Barcelona Geeks. The original can be accessed here. Licence: CCBY-SA