Trabajo Práctico 2
Estructuras de Almacenamiento de Datos
ÍNDICE:
Ejercicio 1
Ejercicio 2
Figura 2
Figura 3
Ejercicio 3
Ejercicio 4
Ejercicio 5
1. Relación binaria N:1
2. Relación binaria N:N
Ejercicio 1
Derivación del modelo lógico relacional:
PRODUCTO_QUIMICO(id_prod_quim, nombre_prod_quim, formula,tipo_pq)
PQ_LIQUIDO(id_prod_quim, inflamable, tipo_envase, condicion_traslado)
----------
PQ_SOLIDO(id_prod_quim, forma, empaque_max)
----------
ENVIO(nro_envio, cantidad, peso, id_cliente, id_prod_quim)
------- ------ --
CLIENTE(id_cliente, cuit, apellido, nombre, calle, puerta, piso, e_mail, telefono, id_cliente_garante)
======== ---------------
COMPONE(id_prod_quim, id_prod_quim_componente)
--------- --------------------
Restricciones de integridad referencial y acciones referenciales:
AR: (delete, update)
PQ_LIQUIDO[id_prod_quim] << PRODUCTO[id_prod_quim]: (C, C)
PQ_SOLIDO[id_prod_quim] << PRODUCTO[id_prod_quim]: (C, C)
ENVIO[id_cliente] << CLIENTE[id_cliente]: (C, C)
ENVIO[id_prod_quim] << PRODUCTO_QUIMICO[id_prod_quim]: (R, C)
CLIENTE[id_cliente_garante] << CLIENTE[id_cliente]: (SN, C)
COMPONE[id_prod_quim] << PRODUCTO_QUIMICO[id_prod_quim]: (C, C)
COMPONE[id_prod_quim_componente] << PRODUCTO_QUIMICO[id_prod_quim]: (R, C)
Ejercicio 2
Figura 2
Derivación del modelo lógico relacional:
CARRETERA(IdCarretera, Nombre, TipoCarretera)
TRAMO(IdCarretera, NroTramo, KmFinal)
--------
PROVINCIA(NombreProvincia)
MUNICIPIO(NomreProvincia, NombreMunicipio)
------------
RNN(NombreProvincia, NombreMunicipio, IdCarretera, NroTramo)
------------------------- ----------------
Para relaciones con cardinalidad maxima “a”, tal que: 1 < a < n; se derivan suponiendo que la cardinalidad
maxima es a = n y se agrega una regla de negocio para indicar que en la tabla de la relación solo pueden
aparecer hasta “a” tuplas con una misma clave de la tabla del lado N (real, no la suposición). Ejemplo:
Se trata de una relación 2:N, pero suponemos que es N:N.
Hacemos la yuxtaposición de las claves de los participantes de la relación. Clave de la agregación (es decir,
clave de la relación RNN) y clave de TRAMO.
R2N(NombreProvincia, NombreMunicipio, IdCarretera, NroTramo, IdCarretera_T, NroTramo_T)
------------------------------------------- -------------------
Los últimos dos campos pertenecen a la clave de la entidad TRAMO, pero fueron renombrados para poder
diferenciarlos de los demas.
Ahora hay que propones una regla de negocio para que la semántica de la relación original con cardinalidad
2:N se mantenga. Por lo tanto, podemos decir que la proyección de la R2N puede tener hasta dos tuplas con
los primeros cuatro campos iguales. Ej:
<Buenos Aires, Tandil, 226, 02, 226, 05>
<Buenos Aires, Tandil, 226, 02, 3, 04>
No pueden existir mas tuplas del estilo: <Buenos Aires, Tandil, 226, 02, …> ya que la semántica del diagrama
indica eso.
Restricciones de integridad referencial y acciones referenciales:
AR: (delete, update)
TRAMO[IdCarretera] << CARRETERA[IdCarretera]: (R, C)
MUNICIPIO[NombreProvincia] << PROVINCIA[NombreProvincia]: (R, C)
RNN[NombreProvincia, NombreMunicipio] << MUNICIPIO[NombreProcincia, NombreMunicipio]: (R, C)
RNN[IdCarretera, NroTramo] << TRAMO[IdCarretera, NroTramo]: (R, C)
R2N[NombreProvincia, NombreMunicipio, IdCarretera, NroTramo] << RNN[NombreProvincia, |---------------------
-------------------->NombreMunicipio, IdCarretera, NroTramo]: (R, C)
R2N[IdCarretera_T, NroTramo_T] << TRAMO[IdCarretera, NroTramo]: (R, C)
Figura 3
Derivación del modelo lógico relacional:
HABITACION(id_hab, tipo_hab, capacidad)
CAMA(id_hab, id_cama, tipo_cama, fecha_compra)
-----
TURISTA(id_turista, pasaporte, pais, nombre)
=======
OCUPA(id_turista, id_hab, id_cama)
------ -----------
FECHA_OCUPA(id_turista, id_hab, id_cama, fecha_ini, fecha_fin)
--------------------
Se pierde la condición de nulidad en el atributo fecha_fin componente de un multivaluado. Además, hay que
agregar una regla extra para indicar que la fecha sea obligatoria:
∏id_turista,id_cama(OCUPA) = ∏id_turista,id_cama(FECHA_OCUPA)
Restricciones de integridad referencial y acciones referenciales:
AR: (delete, update)
CAMA[id_hab] << HABITACION[id_hab]: (R, C)
OCUPA[id_turista] << TURISTA[id_turista]: (C, C)
OCUPA[id_hab, id_cama] << CAMA[id_hab, id_cama]: (R,C)
FECHA_OCUPA[id_turista, id_hab, id_cama] << OCUPA[id_turista, id_hab, id_cama]: (C, C)
Ejercicio 3
a. Diagrama realizado en la herramienta de la catedra.
b. AR: (delete, update)
“Si el artículo se elimina se elimina su producción y comercialización, en el resto de los casos no se
pueden eliminar instancias que estén siendo referenciadas”
PRODUCE(id_comercio) << COMERCIO(id_comercio): (R, C)
PRODUCE(id_fabrica) << FABRICA(id_fabrica): (R, C)
PRODUCE(id_articulo) << ARTICULO(id_articulo): (C, C) <---- Representación del fragmento
COMERCIO(id_distribuidor) << COMERCIO(id_comercio): (R, C)
Ejercicio 4
Derivación del modelo lógico relacional:
PERSONA(DNI, email, apellido, nombre, fechaNac)
====
NODOCENTE(DNI, idLegajo)
- - - ======
DOCENTE(DNI, idProfesor, antiguedad)
- - - =======
ALUMNO(DNI, Lu)
- - - ===
CARRERA(idCarrera, nombre, nombre_titulo_otorgado)
===== ==================
MATERIA(idCarrera, idMateria, nombre)
------- ======
matriculado(DNI, idCarrera, fechaMatricula)
--- -------
INSTANCIA_MATERIA(idCarrera, idMateria, semestre, promocionable)
---------------
dicta(DNI, idCarrera, idMateria, semestre)
--- ----------------------
cursa(DNI, idCarrera, idMateria, semestre, nota_cursada)
--- ----------------------
Restricciones de integridad referencial:
NODOCENTE[DNI] << PERSONA[DNI]
DOCENTE[DNI << PERSONA[DNI]
ALUMNO[DNI] << PERSONA[DNI]
MATERIA[idCarrera] << CARRERA[idCarrera]
matriculado[DNI] << ALUMNO[DNI]
matriculado[idCarrera] << CARRERA[idCarrera]
INSTANCIA_MATERIA[idCarrera, idMateria] << MATERIA[idCarrera, idMateria]
dicta[DNI] << DOCENTE[DNI]
dicta[idCarrera, idMateria, semestre] << INSTANCIA_MATERIA[idCarrera, idMateria, semestre]
cursa[DNI] << ALUMNO[DNI]
cursa[idCarrera, idMateria, semestre] << INSTANCIA_MATERIA[idCarrera, idMateria, semestre]
Ejercicio 5
1. Relación binaria N:1
A. (0,1) : (0,N)
Derivacion:
EMPLEADO(NroEmpleado, Nombre, Apellido)
SUCURSAL(CodSuc, Nombre, Calle, Puerta, Piso, Ciudad, NroEmpleado)
-----------
RIRs y AR:
SUCURSAL[NroEmpleado] << EMPLEADO[NroEmpleado]: (SN, C)
Si quiero eliminar una tupla de EMPLEADO con un NroEmpleado que es referenciado por
SUCURSAL, debo dejar en nulo (Set Null) el campo NroEmpelado de la tabla SUCURSAL. Eso quiere
decir que la sucursal queda sin empleado.
Si quiero modificar el NroEmpleado de alguno de ellos, debo actualizar en cascada en las relaciones
referenciantes.
B. (1,1) : (0,N)
Derivacion:
EMPLEADO(NroEmpleado, Nombre, Apellido)
SUCURSAL(CodSuc, Nombre, Calle, Puerta, Piso, Ciudad, NroEmpleado)
-----------
RIRs y AR:
SUCURSAL[NroEmpleado] << EMPLEADO[NroEmpleado]: (SD, C)
Si quiero eliminar una tupla de EMPLEADO con un NroEmpleado que es referenciado por
SUCURSAL, debo dejar un valor por defecto (Set Default) en el campo NroEmpelado de la tabla
SUCURSAL. Eso quiere decir que la sucursal siempre tiene que tener un empleado a cargo.
Si quiero modificar el NroEmpleado de alguno de ellos, debo actualizar en cascada en las relaciones
referenciantes.
C. (0,1) : (1,N)
D. (1,1) : (1,N)
Los puntos C y D quedan igual a los anteriores (respectivamente). Aclarando que hay dependencia de
inclusión (DI):
∏NroEmpleado(EMPLEADO) ⊆ ∏NroEmpleado(SUCURSAL)
Esto se debe a que cada empleado debe trabajar en AL MENOS una sucursal (la cardinalidad mínima del
lado de la sucursal es 1 en los puntos C y D).
2. Relación binaria N:N
A. (0,N) : (0,N)
Derivacion:
EMPLEADO(NroEmpleado, Nombre, Apellido)
SUCURSAL(CodSuc, Nombre, Calle, Puerta, Piso, Ciudad)
R(CodSuc, NroEmpleado)
------ ---------
RIRs y AR:
R[CodSuc] << SUCURSAL[CodSuc]: (C, C)
R[NroEmpleado] << EMPLEADO[NroEmpleado]: (C, C)
En este caso si podemos hacer cascade a la hora de eliminar tuplas en las tablas EMPLEADO y
SUCURSAL. Esto se debe a que eliminar un empleado no afecta la integridad de las sucursales, y
viceversa. En cambio en las relaciones binarias N:1 del enunciado anterior, si que afectaba la
integridad de las sucursales (eliminar un empleado y luego hacer cascada, podia hacer que se elimine
la sucursal de su propia tabla).
B. (1,N) : (0,N)
La derivacion, rirs y ar quedan iguales. Aclarando que hay dependencia de inclusion (DI):
∏CodSuc(SUCURSAL) ⊆ ∏CodSuc(R)
C. (0,N) : (1,N)
La derivacion, rirs y ar quedan iguales. Aclarando que hay dependencia de inclusion (DI):
∏NroEmpleado(EMPLEADO) ⊆ ∏NroEmpleado(R)
D. (1,N) : (1,N)
La derivacion, rirs y ar quedan iguales. Aclarando que hay dependencia de inclusion (DI):
Se deben impleamentar las dos dependencias anteriores, ya que hay obligatoriedad a ambos lados.