SolaloGonzalezTellezGonzalez_PC4 - Jorge González

Vista previa del material en texto

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO
FACULTAD DE INGENIERÍA
Bases de Datos
Grupo: 05 - Semestre: 2022-1
Práctica Complementaria 4 :
Diseño de Modelos Relacionales
FECHA DE ENTREGA: 16/10/2021
Profesor:
Rodríguez Campos Jorge Alberto Ing.
Alumno:
Téllez González Jorge Luis
Solano González Felipe de Jesús
Facultad de Ingenierı́a Bases de Datos (T)
Índice
1. (C1) Lista de relaciones 2
2. (C3) Borradores 2
2.1. Versión 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2. Versión 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. (C3) Modelo Relacional final 4
4. Conclusiones 5
LATEX
1
Facultad de Ingenierı́a Bases de Datos (T)
1. (C1) Lista de relaciones
A continuación, se muestra una tabla que contiene todas las relaciones identificadas entre las tablas del
modelo relacional y su cardinalidad final:
Figura 1: Tabla de relaciones identificadas.
2. (C3) Borradores
2.1. Versión 1
Este borrador del modelo relacional fue realizado por Téllez González Jorge Luis tomando como base el
modelo E/R realizado en la Práctica Complementaria 3. En este modelo, ciertos detalles que presentaba el
modelo E/R fueron subsanados, sin embargo, otros detalles persistieron:
La tabla HUELLA no tiene sentido, ya que únicamente se van a guardar 2 huellas (izquierda y dere-
cha) para cada cliente y, además, se está forzando a que cada cliente deba tener sus huellas registradas,
lo que no deberı́a ser ası́ considerando los comentarios realizados en clase sobre las personas con ca-
pacidades distintas.
Biometrı́a no es una entidad débil, aunque en este caso se modeló propagando a la PK de CLIENTE ya
que no se comprendió claramente como modelar esta entidad identificado como débil en su momento
(aunque, en realidad, es lo correcto).
La cardinalidad de Cliente a Préstamo es (1,*). Esto tendrı́a sentido si la participación de Cliente
fuese oblighatoria (es decir, que un Cliente debe pedir un préstamo), lo cual no se encuentra dentro
LATEX
2
Facultad de Ingenierı́a Bases de Datos (T)
de las reglas de negocio del caso de estudio. En realidad, esta cardinalidad deberı́a ser (0,*), es decir,
puede pedir 0 o muchos préstamos.
Figura 2: Borrador del Modelo Relacional V1.
2.2. Versión 2
Esta versión fue realizada por Solano González Felipe de Jesús. En esta versión, se basa en el diagrama enti-
dad/relación realizdo en la práctica complementaria 3, si bien las correciones ya se realizaron en la práctica
anterior se resalta la forma en como se transportó el diagrama al modelo relacional. Algunas correcciones
y observaciones del modelo son las siguientes:
De igual manera que el diagrama, en la entidad BIOMETRÍA los datos del atributo compuesto HUE-
LLA no se marcaron como atributos opcionales, ya que no todos los clientes tienen la oportunidad de
registrar esta información.
Para la relación entre la entidad BIOMETRIA y CLIENTE se marcó como identificativa y no lo es,
la clave primaria de cliente debe pasar como foránea a BIOMETRIA.
Para la entidad PRESTAMO, se seleccionó el atributo CLABE como clave primaria que es un error
debido a que una misma CLABE puede utilizarse para instancias distintas de préstamos.
Uno de los errores más graves que tiene este modelo es que se omite la relación que existe entre las
entidades TARJETA y BANCO.
La relación existente entre PRESTAMO y PAGO no se marca como identificativa.
Para la entidad CLIENTE se optó utilizar una llave primaria artificial, sin embargo, las reglas de
LATEX
3
Facultad de Ingenierı́a Bases de Datos (T)
negocio especifican que debe utilizarse como llave primaria el atributo RFC.
El borrador versión 2 es el siguiente:
Figura 3: Borrador del Modelo Relacional V2
3. (C3) Modelo Relacional final
El modelo Entidad-Relación final para el caso de estudio analizado es el siguiente:
Figura 4: Modelo relacional final generado para el caso de estudio.
LATEX
4
Facultad de Ingenierı́a Bases de Datos (T)
4. Conclusiones
De forma similar a la práctica complementaria 3 que fue realizada en paralelo a esta, los conceptos estu-
diados durante la clase fueron aplicados en un caso de estudio similar al que se revisó en la última parte
del tema 4. Ya que los conceptos clave del modelado relacional se estudiaron junto con su equivalente en
el modelo E/R, la transformación del diseño conceptual al lógico fue relativamente sencilla gracias a la
facilidad de uso que ER Studio proporciona para la creación de diseños.
Con respecto a las dificultades o errores detectados, en ambos borradores al momento de realizar
el mapeo hacia el relacional se llevaron arrastrando detalles derivados de un identificación erronea de de-
terminados elementos del caso de estudio (mismos que se abordaron durante la práctica anterior). Una
vez identificados y corregidos esos errores, se optó por elegir una de las propuestas, corregir sus errores y
elaborar la propuesta final que se presentó en la práctica presente.
Una vez más se hace hincapie en lo útil que es analizar el modelo ER con el relacional al mismo
tiempo, ya que realizar las transformaciones se torna en un proceso sencillo; aunque no trivial ya que en
un caso u otro (como las relaciones 1:1) el mapeo al relacional puede tomar rutas distintas, cada una con
sus ventajas o desventajas respectivas que pueden traer implicaciones importantes al funcionamiento y/o
rendimiento de una base de datos.
Finalmente, considerando que el objetivo principal de aplicar en un caso de estudio los conceptos
del modelo relacional realizando el mapeo desde el modelo ER ha sido exitoso, se puede afirmar que
la experiencia adquirida será de suma importancia para el análisis posterior de otros casos de estudio y
servirá como base para el análisis de otros casos que requieran conceptos del modelo extendido o incluso
la aplicación de técnicas de normalizado.
Los créditos de las fotografı́as pertenecen a sus respectivos autores. ©
LATEX
5