9Equipo-4Práctica - Jorge González

Vista previa del material en texto

UNIVERSIDAD NACIONAL AUTÓNOMA DE MÉXICO
FACULTAD DE INGENIERÍA
Lab. de Bases de Datos
Grupo: 07 - Semestre: 2022-1
Práctica 4:
Diseño de modelos relacionales
FECHA DE ENTREGA: 28/09/2021
Profesora:
López Pelcastre Martha M.I.
Alumno:
N.L: 26 Téllez González Jorge Luis
N.L: 23 Solano González Felipe de Jesús
Facultad de Ingenierı́a Lab. de Bases de Datos
Índice
1. Objetivo 2
2. Introducción 2
3. Desarrollo 4
3.1. Esquemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1. Versión 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2. Versión 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3. Versión final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Modelos relacionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Versión 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. Versión 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.3. Versión final . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.4. Análisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3. Modelo ER Incompleto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.1. Entidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.3.2. Atributos y Claves primarias . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.3. Relaciones y cardinalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.4. Diagrama en Dia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.5. Esquemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.6. Modelo relacional en ER Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.7. Análisis de resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4. Conclusiones 16
LATEX
1
Facultad de Ingenierı́a Lab. de Bases de Datos
1. Objetivo
El alumno comprenderá e implementará la construcción de modelos de datos relacionales empleando
herramientas CASE a partir de un diagrama ER.
2. Introducción
En los principios de la utilización de las bases de datos, cada base de datos era creada y diseñada para
que un departamento o grupo especial solo guardara datos que les interesara. El acceso a estas bases de
datos era muy particular por lo que se necesitaba de un programador con experiencia para poder acceder a
esta. Este tipo de diseño de bases de datos eran bastante ineficientes, difı́ciles de administrar y optimizar.
El surgimiento del modelo relacional fue diseñado para resolver los principales problemas que las bases de
datos antiguas tenı́an.
Este modelo fue desarrollado por Edgar Frank Codd de los laboratorios IBM. Un artı́culo histórico
de Codd [1970] definió el modelo relacional y formas no procedimentales de consultar los datos en el
modelo relacional, y nacieron las bases de datos relacionales. La simplicidad del modelo relacional y la
posibilidad de ocultar completamente los detalles de implementación al programador fueron realmente
atractivas. Codd obtuvo posteriormente el prestigioso premio Turing de la ACM (Association of Computing
Machinery, asociación de maquinaria informática) por su trabajo.
Figura 1: Edgar Frank Codd.
El modelo relacional proporciona un estándar para poder representar y consultar datos para cualquier
tipo de aplicación. Desde los inicios del modelo relacional, uno de sus puntos mas fuertes fue que los
datos eran presentados en un formato de tablas, un formato intuitivo para cualquier personal relacionado.
El modelo de datos relacional es el modelo de datos más ampliamente usado, y una amplia mayorı́a de
sistemas de bases de datos actuales se basan en el modelo relacional.
LATEX
2
Facultad de Ingenierı́a Lab. de Bases de Datos
Figura 2: Modelo Relacional.
En el modelo relacional se utiliza un grupo de tablas para representar los datos y las relaciones
entre ellos. Cada tabla está compuesta por varias columnas, y cada columna tiene un nombre único. El
modelo relacional es un ejemplo de un modelo basado en registros. Los modelos basados en registros se
denominan ası́ porque la base de datos se estructura en registros de formato fijo de varios tipos. Cada tabla
contiene registros de un tipo particular. Cada tipo de registro define un número fijo de campos, o atributos.
Las columnas de la tabla corresponden a los atributos del tipo de registro. Este modelo se encuentra a un
nivel de abstracción inferior al modelo de datos E-R. En la práctica, los diseños de bases de datos a menudo
se realizan en el modelo E-R, y posteriormente se traducen al modelo relacional; lo que se conoce en la
actualidad como el paso del diseño conceptual al diseño lógico.
Figura 3: Transformación E/R a Relacional.
LATEX
3
Facultad de Ingenierı́a Lab. de Bases de Datos
Aunque académicamente interesante, el modelo relacional no se usó inicialmente en la práctica debido a sus
inconvenientes por el rendimiento; las bases de datos relacionales no pudieron competir con el rendimiento
de las bases de datos de red y jerárquicas existentes. Esta situación cambió con System R, un proyecto
innovador en IBM Research que desarrolló técnicas para la construcción de un sistema de bases de datos
relacionales eficiente. Los primeros sistemas de bases de datos relacionales, como DB2 de IBM, Oracle,
Ingres y Rdb de DEC, jugaron un importante papel en el desarrollo de técnicas para el procesamiento efi-
ciente de consultas declarativas. Desde su escalada en el dominio en la década de 1980, el modelo relacional
ha conseguido el reinado supremo entre todos los modelos de datos.
Figura 4: El manejador de Oracle es uno de los más conocidos DBMS para bases relacionales.
Conforme el modelo relacional fue creciendo, los desarrolladores de bases de datos comenzaron a
utilizar un lenguaje estructurado de consulta y escritura de datos, conocido como SQL. Durante muchos
años, incluyendo la actualidad, el lenguaje SQL ha sido utilizado debido a que proporciona un lenguaje
matemático que facilita la mejora del rendimiento de todas las consultas.
3. Desarrollo
La primer actividad de la práctica es la siguiente: A partir de los diagramas Entidad Relación realizados
en las prácticas anteriores, realizar la transformación al modelo relacional generando los objetos
necesarios en la herramienta CASE elegida.
Para efectos de la práctica, se empleará el siguiente modelo E/R del ejercicio de la Guarderı́a, el
cual fue realizado durante el desarrollo de la práctica 3.
A continuación, se mostrarán los esquemas desarrollados por cada integrante del equipo en conjunto
con otros compañeros del grupo de laboratorio.
LATEX
4
Facultad de Ingenierı́a Lab. de Bases de Datos
Figura 5: Diagrama E/R de la guarderı́a.
3.1. Esquemas
3.1.1. Versión 1
La primer versión a abordar fue desarrollada por Téllez González Jorge Luis y un equipo de compañeros
durante la sesión del laboratorio.
Cabe señalar que este esquema fue desarrollado considerando a la relación entre las entidades PLA-
TILLO y MENÚ como una relación m:m; lo cual implicó la creación de una tabla adicional para la relación
identificativa de acuerdo a las reglas estudiadas durante la sesión. A continuación se enlistan los esquemas
desarrollados:
NIÑO= {numRegistro (PK), nombre, materno, paterno, cargoMensualFijo, fechaBaja (N), fe-
chIngreso, edad (CK), fechNacimiento}
PERSONA= {idPersona (PK), materno, nombre, paterno, CURP (U), dirección}
RECOGE= {[numRegistro (FK), idPersona (FK)] (PK), parentesco}
TELÉFONO= {idTeléfono (PK), idPersona (FK), teléfono (U)}
LATEX
5
Facultad de Ingenierı́a Lab. de Bases de Datos
TUTOR= {idTutor (PK), numRegistro (FK), teléfono, materno, nombre,paterno, CURP (U),
calle, numero, colonia, alcaldia}
TARJETA= {idTarjeta (PK), idTutor (FK), [banco, numCuenta] (U)}
DATOSFACTURA= {idFactura (PK), idTutor (FK), domicilioFiscal, correo, RFC (U)}
PAGO= {idPago (PK), idTutor (FK), fecha, cargoComidas (CK), cargoMensual (CK)}
INGREDIENTE= {idIngrediente (PK), nombreIngrediente}
RECHAZA= {[numRegistro (FK), idIngrediente (FK)] (PK)}
CONSUME= {[numRegistro (FK), idMenu (FK)] (PK), fechaConsumo}
PLATILLO= {idPlatillo (PK), nombrePlatillo}
CORRESPONDE= {[idIngrediente (FK), idPlatillo (FK)] (PK), cantidad}
MENÚ= {idMenu (PK), costo, nombreMenú}
CONTIENE= {[idPlatillo (FK), idMenu (FK)] (PK)}
3.1.2. Versión 2
La primer versión a abordar fue desarrollada por Solano González Felipe de Jesús y un equipo de com-
pañeros durante la sesión del laboratorio.
La modelación se hizo con base al diagrama entidad/relación. Se tomó en cuenta las diferentes
relaciones entre las entidades para formar de manera correcta entidades extra que surge de la relación
muchos a muchos. También, se considero el tipo de atributos que tiene cada entidad, aunado a eso, se
hicieron presente en el esquema las diferentes consideraciones semánticas para la correcta categorización
de los atributos.
DATOSFACTURA= {idFactura(PK), idTutor(FK), RFC(U), domicilioFiscal, correo}
PAGO= {idPago(PK), idTutor(FK), cargoMensual(C,CK), cargoComidas(C,CK), fecha}
TUTOR= {idTutor(PK), CURP(U), paterno, materno, nombre, teléfono, número, colonia, al-
caldia)}
TARJETA TUTOR= {idTarjeta(PK), idTutor(FK,CK), banco, numCuenta(U)}
NIÑO= {numRegistro(PK), idTutor(FK), edad(C), fechaBaja(N), fechaIngreso, fechaNacimien-
LATEX
6
Facultad de Ingenierı́a Lab. de Bases de Datos
to, paterno, materno, nombre, cargoMensualFijo}
PERSONA= {idPersona(PK), CURP(U), paterno, materno, nombre, direccion}
TELEFONO PERSONA= {idTelefono(PK), idPersona(FK), telefono}
PERSONA NIÑO= {[numRegistro(FK),idPersona(FK)](PK),parentesco}
INGREDIENTE= {idIngrediente(PK),nombreIngrediente}
NIÑO INGREDIENTE= {[idIngrediente(FK), numRegistro(FK)](PK),descripcionAlergia}
PLATILLO= {idPlatillo(PK), idMenu(FK), nombrePlatillo}
INGREDIENTE PLATILLO= {[idPlatillo(FK), idIngrediente(FK)](PK),cantidad}
MENU= {idMenu(PK), costo, nombreMenu}
MENU NIÑO= {[idMenu(FK), numRegistro(FK)](PK), fechaConsumo}
Nota: en este modelo se hace la consideración de que la relación entre menu y platillo es de (M:1).
3.1.3. Versión final
Tras realizar un análisis de ambas propuestas de esquemas, se encontraron las siguientes diferencias entre
ambos conjuntos de esquemas propuestos:
1. Edad se coloca como (CK) por C.S/Edad se coloca como (C) únicamente.
2. númRegistro se envı́a como FK a Tutor/idTutor se envı́a como FK a Niño.
3. Los atributos banco y numCuenta se agrupan en un único atributo compuesto y (U)/Ambos atributos
se consideran separados y con numCuenta (U).
4. Los atributos cargoComidas y cargoMensual se manejan como (CK) por C.S/ Ambos se consideran
como (C,CK).
5. No se agrega atributos a la relación Rechaza/Se agrega un atributo llamado descripciónAlergia.
6. Se generó un nuevo esquema considerando una relación (m:m) entre Platillo y Menú/Se envı́o id-
Menú como FK a Platillo considerando una relación (m:1).
Finalmente, tras deliberar sobre qué propuesta resultaba óptima para trabajarse, finalmente en con-
censo se decidió utilizar la Versión 1 de los esquemas propuestos. Únicamente se agregó un atributo llamado
LATEX
7
Facultad de Ingenierı́a Lab. de Bases de Datos
descripciónAlergia al esquema que representa a la relación RECHAZA; el resto de los esquemas propues-
tos se mantuvieron sin cambio alguno.
RECHAZA= {[numRegistro (FK), idIngrediente (FK)] (PK), descripcionAlergia}
3.2. Modelos relacionales
3.2.1. Versión 1
El modelo relacional dibujado a mano con base en la primer versión de los esquemas desarrollados en la
sesión de laboratorio es el siguiente, el cual está compuesto por 2 hojas ya que su tamaño no permitı́a
acomodarlo en una única página.
Figura 6: Primer parte del modelo relacional dibujado V1.
LATEX
8
Facultad de Ingenierı́a Lab. de Bases de Datos
Figura 7: Segunda parte del modelo relacional dibujado V1.
3.2.2. Versión 2
El modelo relacional dibujado a mano con base en la segunda versión de los esquemas desarrollados en la
sesión de laboratorio es el siguiente:
Figura 8: Versión 2 del modelo relacional dibujado.
LATEX
9
Facultad de Ingenierı́a Lab. de Bases de Datos
3.2.3. Versión final
La versión final del modelo relacional estuvo completamente basada en la primer versión de los esquemas
desarrollados con la única diferencia de que se tiene un atributo adicional en RECHAZA. Esta diferencia
en realidad es mı́nima y no tiene impacto alguno en el modelo ya que las tablas generadas por relaciones
identificativas pueden estar únicamente con las llaves foráneas como PK’s sin otros atributos en ellas.
Figura 9: Diferencia en la tabla RECHAZA. El resto del modelo es idéntico a la Versión 1.
Figura 10: Versión final del modelo relacional en ER Studio.
LATEX
10
Facultad de Ingenierı́a Lab. de Bases de Datos
3.2.4. Análisis de resultados
El modelo propuesto fue desarrollado considerando ambos esquemas, sin embargo, como se mencionó
previamente la primer versión fue la elegida debido a los detalles que presentaba la segunda versión con
respecto a las consideraciones semánticas y el tratamiento de ciertos atributos.
Una vez hechos los dibujos de ambos modelos y del modelo final, fue posible observar que en
realidad, más allá de las diferencias en cuanto a la nomenclatura para las relaciones y ciertos atributos, la
idea general del modelado realizado en ambos trabajos resulta muy similar. La única diferencia importante
a destacar fue el tratamiento de la relación entre PLATILLO y MENÚ, donde se prefirió dejarla como una
relación M:M.
Consideramos que, al final, ambas versiones terminaban tendiendo a un único concenso común
sobre como aplicar las reglas de transformación; siendo la primera la más cercana a una correcta transfor-
mación hacia el modelo relacional.
3.3. Modelo ER Incompleto
El segundo ejercicio propuesto para la práctica es el siguiente: Realizar la revisión de propuestas de
modelos, analizar y discutir posibles errores, ventajas y desventajas. Partir de un modero ER con
errores, corregir y generar el modelo relacional correcto.
El caso de estudio a analizar es el siguiente:
Realiza el diseño de una base de datos para una universidad la cual consiste en un número de departamen-
tos. Cada departamento se identifica por su nombre único y ofrece varios cursos. Un número de módulos
los cuales se identifican con una clave y su nombre, conforman cada curso. Los estudiantes de los cuales
se requiere su nombre, dirección (desglosada) y la clave que los identifica se matriculan en los cursos (los
cuales tienen nombre, duración en horas y clave), y toman los módulos para la realización de este curso.
Algunos cursos son seriados, se desea saber cuáles cursos son seriados. Cada módulo es explicado por un
profesor (se desea almacenar su rfc, nombre y carrera) y cada profesor puede impartir más de un módulo.
Cada profesor es tutor de un grupo de estudiantes y un estudiante tiene un solo tutor, es importante saber
las fechas de las tutorı́as que les da a los alumnos.
3.3.1. Entidades
Se identifican las siguientes entidades:
Departamento
Módulo
Estudiante
LATEX
11
Facultad de Ingenierı́a Lab. de Bases de Datos
Curso
Profesor
3.3.2. Atributos y Claves primarias
En este caso particular, todas las claves primarias fueron homologadas a claves artificiales.
Departamento: departamentoID, nombreDepartamento.
Módulo: móduloID, nombreMódulo.
Estudiante: estudianteID, nombre, dirección [Compuesto: calle, colonia, número y alcaldı́a].
Curso: cursoID, nombreCurso, duración.
Profesor: profesorID, rfc [Clave candidata], nombre, carrera.
3.3.3. Relaciones y cardinalidadesSe identificaron las siguiente relaciones y cardinalidades en el caso de estudio:
Un departamento ofrece varios cursos. (1:M)
Un curso es ofrecido por un departamento. (1:1)
Cardinalidad: (1:M)
Un curso es matriculado por varios estudiantes. (1:M)
Un estudiante se matricula en varios cursos. (1:M)
Cardinalidad: (M:N)
Un curso es conformado por muchos módulos. (1:M)
Un módulo conforma a un curso. (1:1)
Cardinalidad: (1:M)
Un módulo es explicado por un profesor. (1:1)
Un profesor explica uno o más módulos. (1:M)
Cardinalidad: (1:M)
LATEX
12
Facultad de Ingenierı́a Lab. de Bases de Datos
Un profesor es tutor de uno o más estudiantes. (1:M)
Un estudiante tiene como tutor a un profesor. (1:1)
Cardinalidad: (1:M)
3.3.4. Diagrama en Dia
El diagrama E/R de Dia presentado en la práctica cuenta con varios problemas identificados:
1. La entidad CURSO no incluye al atributo duración.
2. La relación entre CURSO y ESTUDIANTE es (M:N) y no (1:M).
3. La entidad ESTUDIANTE no contiene al atributo compuesto dirección.
4. No se encuentra la relación tutor entre ESTUDIANTE y PROFESOR.
5. Se identifica una relación erronea llamada toman entre ESTUDIANTE y MÓDULO.
6. La entidad PROFESOR se identifica como una entidad débil.
7. Se omiten los atributos rfc y carrera en la entidad PROFESOR.
8. La relación entre PROFESOR y MÓDULO se identifica como 1:1 cuando en realidad es 1:M.
A continuación se muestra el diagrama con todos estos errores subsanados en Dia:
3.3.5. Esquemas
A partir del diagrama E/R desarrollado y corregido, se procede a enlistar los esquemas para cada entidad y
relación, según corresponda:
DEPARTAMENTO= {departamentoID (PK), nombreDepartamento}
CURSO= {cursoID (PK), departamentoID (FK), nombreCurso, duración}
MATRÍCULA= {[cursoID (FK), estudianteID (FK)] (PK)}
ESTUDIANTE= {estudianteID (PK), profesorID (FK), nombre, apPat, apMat, calle, colonia,
número, alcaldı́a}
MÓDULO= {móduloID (PK), cursoID (FK), profesorID (FK), nombreMódulo}
PROFESOR= {profesorID (PK), rfc (U), carrera, nombre, apPat, apMat}
LATEX
13
Facultad de Ingenierı́a Lab. de Bases de Datos
Figura 11: Diagrama E/R del caso de estudio con errores.
Figura 12: Diagrama E/R del caso de estudio corregido.
LATEX
14
Martha López Pelcastre
faltaron las consideraciones semánticas
Martha López Pelcastre
faltan las fechas de asesoría
Martha López Pelcastre
faltó si es seriado
Facultad de Ingenierı́a Lab. de Bases de Datos
3.3.6. Modelo relacional en ER Studio
Finalmente, con los esquemas anteriores se procede a realizar el modelo conceptual haciendo uso de ER
Studio:
Figura 13: Diagrama E/R del caso de estudio corregido.
3.3.7. Análisis de resultados
En primer lugar, es importante señalar que la metodologı́a para realizar el análisis del caso de estudio
consistió en dejar momentáneamente de lado el diagrama ER inicial y comenzar a observar desde 0 el caso
de estudio, identificando las entidades, atributos, relaciones y cardinalidades para construir el diagrama sin
considerar el primer diagrama salvo en su estructura para comparar ambos diagramas.
Al comparar ambos diagramas fue mucho más sencillo el análisis tanto del diagrama creado como
del proporcionado al contar con un caso de estudio desarrollado. De lo anterior, fue posible señalar los
errores del diagrama original y, con la retroalimentación proporcionada, corregir los detalles de la propuesta
del equipo para, finalmente, construir el modelo relacional haciendo uso de ER Studio.
Finalmente, es importante señalar que en este caso se tiene que prestar mucha atención a la regla
de transformación para relaciones (1:M) especialmente al asignar el tipo de relación en ER Studio, ya que
se pueden tener relaciones que consideren cardinalidad mı́nima de 0 para el padre. Por tanto, es importante
seleccionar la cardinalidad correcta para la relación considerando que esta va de padre a hijo.
LATEX
15
Facultad de Ingenierı́a Lab. de Bases de Datos
4. Conclusiones
Solano González Felipe de Jesús: En la realización de la práctica se comprende en gran manera lo
qué es un modelo relacional, desde el momento de su surgimiento hasta la actualidad. Claramente, en
los ejercicios realizados se refuerza en gran manera los métodos para formular un modelo relacional,
tomando en cuenta todos los puntos importantes del diseño entidad/relación. Es importante destacar
la importancia que tiene llevar un proceso de diseño con cuidado porque el diseño debe acoplarse a
las reglas de negocio y requerimientos de diseño provocando en ocasiones que se tenga que rediseñar
o tome más tiempo del estimado.
En conclusión, se puede mencionar que los objetivos de la práctica se cumplen porque se comprendio
el modelo relacional y se realizaron diferentes ejercicios para su implementación, utilizando herra-
mientas CASE partiendo de un diagrama entidad/relación.
Téllez González Jorge Luis: Uno de los retos más importantes de esta práctica consistió en enlazar
adecuadamente los elementos del diseño conceptual y el diseño lógico sin mezclar incorrectamente
elementos propios de cada fase. El trabajo desarrollado permitió por primera vez poner en práctica la
transición del modelo de datos E/R al modelo relacional; el cual es la base para la propia implemen-
tación fı́sica enmarcada en el diseño lógico que representa la última fase de una base de datos.
Una de las dificultades que tuve estuvo especialmente en la notación a usar en ER Studio al asignar
relaciones identificativas o no según correspondiera. Estas dudas dificultaron en un inicio mi flujo
de trabajo, sin embargo, una vez estas dudas fueron aclaradas, realizar los modelos fue mucho más
sencillo. Otra duda que tuve fue respecto a la regla de transformación para entidades (1:m) la cual
también fue aclarada debidamente.
Finalmente, considero que el objetivo principal de esta práctica ha sido cumplido por medio del
trabajo colaborativo junto con mi compañero de equipo, ya que se tuvo que realizar un análisis de los
esquemas que realizamos para llegar a un concenso y desarrollar juntos el modelo relacional final.
De igual forma, tuvimos la oportunidad de poner en práctica una vez más los conceptos del modelo
E/R en un caso de estudio con un diagrama con errores; lo que evidentemente requiere que tengamos
conceptos claros para poder realizar las correcciones pertinentes.
Referencias
[1] Diseño Lógico de una Base de Datos. Recuperado de: https://programas.cuaed.unam.mx/
repositorio/moodle/pluginfile.php/1122/mod_resource/content/1/Contenido/index.
html. Fecha de consulta: 27/09/2021.
[2] ¿Qué es una base de datos relacional? Recuperado de: https://www.oracle.com/mx/database/
what-is-a-relational-database/. Fecha de consulta: 27/09/2021.
LATEX
16
https://programas.cuaed.unam.mx/repositorio/moodle/pluginfile.php/1122/mod_resource/content/1/Contenido/index.html
https://programas.cuaed.unam.mx/repositorio/moodle/pluginfile.php/1122/mod_resource/content/1/Contenido/index.html
https://programas.cuaed.unam.mx/repositorio/moodle/pluginfile.php/1122/mod_resource/content/1/Contenido/index.html
https://www.oracle.com/mx/database/what-is-a-relational-database/
https://www.oracle.com/mx/database/what-is-a-relational-database/
Facultad de Ingenierı́a Lab. de Bases de Datos
[3] Silberschatz, A., Korth, H. F., and Sudarshan, S. (2002). Fundamentos de Bases de Datos. McGrawHill,
4th edition.
Los créditos de las fotografı́as pertenecen a sus respectivos autores. ©
LATEX
17