Mapeo del modelo ER al modelo relacional

modelo de relación 

Después de diseñar el diagrama ER del sistema, debemos convertirlo en modelos relacionales que pueden implementarse directamente mediante cualquier RDBMS como Oracle, MySQL, etc. En este artículo, analizaremos cómo convertir el diagrama ER en un modelo relacional para diferentes escenarios. 

Caso 1: Relación Binaria con cardinalidad 1:1 con participación total de una entidad 

 

Una persona tiene 0 o 1 número de pasaporte y el pasaporte siempre es propiedad de 1 persona. Por lo tanto, es una cardinalidad 1: 1 con restricción de participación total de Passport. 

Primero Convierta cada entidad y relación en tablas.   La tabla de personas corresponde a la Entidad de persona con clave como Per-Id. De manera similar, la tabla de Pasaportes corresponde a la Entidad de Pasaportes con la clave Pass-No. Has Table representa la relación entre Persona y Pasaporte (Qué persona tiene qué pasaporte). Por lo tanto, tomará el atributo Per-Id de Person y Pass-No de Passport. 

  
 

Persona			Posee			Pasaporte
por ID	Atributo de otra persona		por ID	Pase-No		Pase-No	Otro atributo de pasaporte
PR1	–		PR1	ps1		ps1	–
PR2	–		PR2	ps2		ps2	–
PR3	–

 

                                                                     tabla 1                                                                                  

Como podemos ver en la Tabla 1, cada Per-Id y Pass-No tiene solo una entrada en Has Table. Entonces podemos fusionar las tres tablas en 1 con los atributos que se muestran en la Tabla 2. Cada Per-Id será único y no nulo. Así que será la clave. Pass-No no puede ser clave porque para alguna persona, puede ser NULL. 
 

por ID

Atributo de otra persona

Pase-No

Otro atributo de pasaporte

 

Tabla 2

Caso 2: Relación Binaria con cardinalidad 1:1 y participación parcial de ambas entidades 

 

Un hombre se casa con 0 o 1 mujer y viceversa también. Por lo tanto, es una cardinalidad 1: 1 con restricción de participación parcial de ambos. Primero Convierta cada entidad y relación en tablas. La tabla masculina corresponde a la entidad masculina con clave como M-Id. De manera similar, la tabla Femenina corresponde a la Entidad Femenina con clave como F-Id. Marry Table representa la relación entre hombre y mujer (qué hombre se casa con qué mujer). Por lo tanto, tomará el atributo M-Id de Male y F-Id de Female. 

 

Masculino			Casar			Femenino
Medio	Otro atributo masculino		Medio	Defensor		Defensor	Otro atributo femenino
M1	–		M1	F2		F1	–
M2	–		M2	F1		F2	–
M3	–					F3	–

 

Tabla 3

Como podemos ver en la Tabla 3, algunos hombres y algunas mujeres no se casan. Si fusionamos 3 tablas en 1, para algunos M-Id, F-Id será NULL. Por lo tanto, no hay ningún atributo que siempre no sea NULL. Entonces no podemos fusionar las tres tablas en 1. Podemos convertirlas en 2 tablas. En la tabla 4, los M-Id que estén casados ​​tendrán asociado F-Id. Para otros, será NULL. La tabla 5 tendrá información de todas las hembras. Las claves primarias han sido subrayadas. 
 

Medio

Otro atributo masculino

Defensor

 

 Tabla 4   

 

Defensor

Otro atributo femenino

 

                                                                Tabla 5                                                                 

Nota: La relación binaria con cardinalidad 1:1 tendrá 2 tablas si hay participación parcial de ambas entidades en la relación. Si al menos 1 entidad tiene participación total, el número de mesas requeridas será 1. 

Caso 3: Relación binaria con n: 1 cardinalidad 

 

En este escenario, cada estudiante puede inscribirse solo en un curso electivo, pero para un curso electivo puede haber más de un estudiante. Primero Convierta cada entidad y relación en tablas. La tabla de Estudiante corresponde a la Entidad de Estudiante con clave como S-Id. De manera similar, la tabla Elective_Course corresponde a Elective_Course Entity con clave como E-Id. La tabla de inscripciones representa la relación entre el estudiante y el curso electivo (qué estudiante se inscribe en qué curso). Por lo tanto, tomará el atributo S-Id de Student y E-Id de Elective_Course. 
 

Alumno			se inscribe			Curso electivo
ID-S	Otro atributo de estudiante		ID-S	identificación electrónica		identificación electrónica	Otro atributo de curso optativo
S1	–		S1	E1		E1	–
S2	–		S2	E2		E2	–
S3	–		S3	E1		E3	–
S4	–		S4	E1

 

Tabla 6

Como podemos ver en la Tabla 6, S-Id no se repite en la Tabla de inscripciones. Por lo tanto, puede considerarse como una clave de la tabla de Inscripciones. Tanto la clave de la tabla de Estudiantes como la de Inscripciones es la misma; podemos fusionarlo como una sola tabla. Las tablas resultantes se muestran en la Tabla 7 y la Tabla 8. Las claves principales se han subrayado. 
 

ID-S

Otro atributo de estudiante

identificación electrónica

 

Tabla 7 

 

identificación electrónica

Otro atributo de curso optativo

 

Tabla 8

Caso 4: Relación binaria con cardinalidad m:n

 

En este escenario, cada alumno puede inscribirse en más de 1 curso obligatorio y para un curso obligatorio puede haber más de 1 alumno. Primero Convierta cada entidad y relación en tablas. La tabla de Estudiante corresponde a la Entidad de Estudiante con clave como S-Id. De manera similar, la tabla Compulsory_Courses corresponde a la entidad de cursos obligatorios con clave como C-Id. La tabla de inscripciones representa la relación entre el estudiante y los cursos obligatorios (qué estudiante se inscribe en qué curso). Por lo tanto, tomará el atributo S-Id de Person y C-Id de Compulsory_Courses. 
 

Alumno			se inscribe			Cursos obligatorios
ID-S	Otro atributo de estudiante		ID-S	Identificación C		Identificación C	Otro atributo de curso obligatorio
S1	–		S1	C1		C1	–
S2	–		S1	C2		C2	–
S3	–		S3	C1		C3	–
S4	–		S4	C3		C4	–
			S4	C2
			S3	C3

 

Tabla 9

Como podemos ver en la Tabla 9, S-Id y C-Id se repiten en la Tabla de inscripciones. Pero su combinación es única; por lo que puede ser considerado como una clave de la tabla de Enrolls. Las claves de todas las tablas son diferentes, no se pueden fusionar. Las claves principales de todas las tablas se han subrayado. 

Caso 5: Relación binaria con entidad débil

 

En este escenario, un empleado puede tener muchos dependientes y un dependiente puede depender de un empleado. Un dependiente no tiene existencia sin un empleado (por ejemplo, usted como hijo puede ser dependiente de su padre en su empresa). Entonces será una entidad débil y su participación será siempre total. Entidad débil no tiene llave propia. Por lo que su clave será la combinación de la clave de su entidad identificadora (E-Id of Employee en este caso) y su clave parcial (D-Name). 

Primero Convierta cada entidad y relación en tablas. La tabla de Empleados corresponde a la Entidad Empleado con clave como E-Id. De manera similar, la tabla Dependientes corresponde a la Entidad dependiente con clave como D-Name y E-Id. Has Table representa la relación entre el empleado y los dependientes (qué empleado tiene qué dependientes). Por lo tanto, tomará el atributo E-Id del empleado y D-Name de los dependientes. 
 

Empleado			Posee			dependientes
identificación electrónica	Otro atributo de empleado		identificación electrónica	Nombre D		Nombre D	identificación electrónica	Atributo de otros dependientes
E1	–		E1	RAM		RAM	E1	–
E2	–		E1	SRINI		SRINI	E1	–
E3	–		E2	RAM		RAM	E2	–
			E3	CENIZA		CENIZA	E3	–

 

 Tabla 10

 Como podemos ver en la Tabla 10, E-Id, D-Name es clave para la tabla Has y Dependents. Entonces podemos fusionar estos dos en 1. Entonces, las tablas resultantes se muestran en las Tablas 11 y 12. Las claves principales de todas las tablas se han subrayado. 
 

identificación electrónica

Otro atributo de empleado

 

Tabla 11

 

Nombre D

identificación electrónica

Atributo de otros dependientes

 

Tabla 12

 

 

Artículo aportado por . Escriba comentarios si encuentra algo incorrecto o si desea compartir más información sobre el tema tratado anteriormente.