Está en la página 1de 21

TECNOLÓGICO NACIONAL DE MÉXICO

CAMPUS CUAUTLA

FUNDAMENTOS DE BASE DE DATOS

LUIS ADRIAN GRACÍA GARCÍA

INVESTIGACIÓN UNIDAD 3
GRUPO 1
EQUIPO 4

García López Blas Francisco 19680152


Torres Gonzalez Elid Ailton 19680267
Ponce Mocha Dexter 19680227
Cardenas Villarruel Alonso Eliseo 19680118
Galindo Guerrero Luis Iván 19680150
Marín Huerta Favio Daniel 19680186
Muñoz Naranjo Diego Aldahir 19680208
Castro Arellano Angel Emanuel 19680124
Rivera Ferrer Oscar Alberto 19680237

16/NOV/2020
INTRODUCCIÓN

El modelo relacional se basa en dos ramas de las matemáticas: la teoría de conjuntos y la lógica
de predicados de primer orden. El hecho de que el modelo relacional se base en la teoría
matemática lo hace tan seguro y robusto. Al mismo tiempo, estas ramas de las matemáticas
proporcionan los elementos básicos necesarios para la creación de una base datos relacional
bien estructurada y aportan ideas para establecer un buen método de diseño.
La teoría matemática proporciona la base para el modelo relacional, de modo que el modelo sea
predecible, confiable y seguro. La teoría describe los elementos básicos que se utilizan para crear
una base de datos relacional y proporciona pautas para establecer una base de datos. La
organización de estos elementos para lograr el resultado deseado se llama diseño.
3.1 Introducción al Modelo Relacional
¿Qué es un Modelo?
Cuando en teoría de diseño de bases de datos se emplea el término "modelo" , esto no tiene el
mismo significado que en Lógica . En Lógica por "modelo" se entiende una interpretación en la
que se satisfacen ( se evalúan como ciertas ) las fórmulas de una teoría , lo que asegura su
consistencia . En Bases de Datos , un Modelo es un formalismo que nos permite representar la
realidad y , más concretamente , aquella parte de la realidad que nos interesa ( Una Empresa ,
una Universidad , una Biblioteca , el catálogo de las especies protegidas en un determinado país...
). Las partes fundamentales de un Modelo , son :
• Estructura de datos
• Restricciones
• Operadores asociados
El modelo relacional se ha establecido actualmente como el principal modelo de datos para las
aplicaciones de procesamiento de datos. Debido a su simplicidad, Facilita el trabajo del
programador y una base de datos relacional consiste en un conjunto de tablas.
El principal objetivo del modelo de datos relacional es facilitar que la base de datos sea percibida
o vista por el usuario como una estructura lógica que consiste en un conjunto de relaciones y no
como una estructura física de implementación. Esto ayuda a conseguir un alto grado de
independencia de los datos.
Un objetivo adicional del modelo es conseguir que esta estructura lógica con la que se percibe la
base de datos sea simple y uniforme. Con el fin de proporcionar simplicidad y uniformidad, toda
la información se representa de una única manera: mediante valores explícitos que contienen las
relaciones (no se utilizan conceptos como por ejemplo apuntadores entre las relaciones). Con el
mismo propósito, todos los valores de datos se consideran atómicos; es decir, no es posible
descomponerlos.
Hay que precisar que un SGBD relacional, en el nivel físico, puede emplear cualquier estructura
de datos para implementar la estructura lógica formada por las relaciones. En particular, a nivel
físico, el sistema puede utilizar apuntadores, índices, etc. Sin embargo, esta implementación
física queda oculta al usuario.
En los siguientes apartados estudiaremos la estructura de los datos, las operaciones y las reglas
de integridad del modelo relacional. Hay dos formas posibles de enfocar el estudio de los
contenidos de este módulo. La primera consiste en seguirlos en orden de exposición. De este
modo, se van tratando todos los elementos de la teoría del modelo relacional de forma muy
precisa y en un orden lógico.
Otra posibilidad, sin embargo, es empezar con la lectura del resumen final del módulo y leer
después todo el resto de los contenidos en el orden normal. El resumen describe los aspectos
más relevantes de la teoría relacional que se explican y, de este modo, proporciona una visión
global de los contenidos del módulo que, para algunos estudiantes, puede ser útil comprender
antes de iniciar un estudio detallado.
Estructura de datos en el Modelo Relacional.

El Modelo Relacional fue propuesto por E.Codd en 1970 ( E. Codd era entonces un investigador
del Centro de IBM en San José (California ) y publicó su propuesta en un artículo fundamental
que obtuvo el ACM Award correspondiente al Congreso VLDB de 1970 ) . La estructura
subyacente básica es la relación , entendida en su acepción matemática básica : Un subconjunto
de un producto cartesiano de conjuntos .
Cuando se pretende describir una parcela de la realidad mediante el formalismo relacional, el
primer paso es discernir los atributos presentes en el problema. Un atributo es un ítem elemental
de información, en el sentido de no poder desglosarse en componentes más simples. Los
atributos son los nombres que damos a las propiedades de los objetos acerca de los cuales se
va a guardar información.

3.2 Conversión de Modelo E-R a Modelo Relacional


Así como existe una relación entre una clase de un diagrama de clases y el código, también existe
una relación entre una entidad (o un vínculo) de un diagrama ERE o una clase y el modelo
relacional.
El modelo ER es un modelo de datos conceptual de alto nivel.
● Facilita las tareas de diseño conceptual de bases de datos.
● Es necesario traducirlo a un esquema que sea compatible con un SGBD.
● El Modelo Relacional es utilizado por la mayoría de los SGBD existentes en el mercado.

Transformación del Modelo ER al Modelo Relacional (Básico)

● Modelo Entidad Relación (Básico), transformación al modelo Relacional de:


– Entidades (no débiles)
– Entidades Débiles
– Vínculos 1:N
– Vínculos 1:1 Definir una serie de esquemas de relaciones
equivalentes
– Vínculos M:N
– Atributos Multivaluados
– Vínculos n-arios
1. Transformación de Entidades

Persona
cedula
primNombre
primApellido
segApellido
telefono

Empleado (Cédula, PrimNombre, PrimApellido, SegApellido, Teléfono)

Clave Primaria Atributo compuesto Nombre


En caso de que más de un atributo sea parte de la clave primaria:

Proyecto
numero
nombre
descripcion

Proyecto (Número_Proyecto, Nombre_Proyecto, Descripción_Proyecto)

CP compuesta

• Para cada tipo normal (no débil) de entidad E del modelo ERE se define una relación R.
• En la relación R se incluyen todos los atributos simples de E.
• Se incluyen en R los atributos simples que sean componentes de los atributos
compuestos.
• Se eligen todos los atributos clave de E como atributos claves de R.
2. Transformación de Entidades Débiles

Hito (Número_Proyecto, Nombre_Proyecto, Codigo_Hito, Fecha_Hito, Descripción_Hito)

Proyecto (Número_Proyecto, Nombre_Proyecto, Descripción_Proyecto)

Como composición se vería así:

Proyecto es_parte_de Hito


numero codigo
nombre fecha
descripcion 1 1…* descripcion

• Para cada entidad débil D del modelo ER y su respectivo vínculo con su entidad
propietaria E se define una relación R.
• La relación R tiene todos los atributos de la entidad débil D más los atributos que
conforman la clave primaria de la entidad propietaria E.
• La clave primaria de la relación R está formada por los atributos de la clave primaria de la
entidad propietaria E más los atributos de la clave parcial de D.

3. Transformación de Vínculos 1:N

Empleado(Cédula, PrimNombre,PrimApellido, SegApellido, Teléfono, Numero_Dpto)

Departamento (Numero_Dpto, Nombre_Dpto)


Como composición se vería así:

Empleado pertenece_a
Departamento
cedula
numero
primNombre
nombre
PrimApellido 0…* 1
SegApelllido
telefono

• Para cada vinculo 1:N entre dos entidades (no débiles) E y F donde F está del lado N del
vínculo, se añade a la relación correspondiente a la entidad F de alguna de las entidades
la clave primaria de la otra entidad relacionada.

4. Transformación de Vínculos 1:1

Departamento (Número_Dpto, Nombre_Dpto, Cédula_Jefe)

Empleado (Cédula, PrimNombre, PrimApellido, SegApellido, Teléfono)

Empleado Tiene_jefe
Departamento
cedula
numero
primNombre
nombre
PrimApellido 1 1
SegApelllido
telefono

• Para cada vinculo 1:1 entre dos entidades (no débiles) E y F se añade a la relación de
alguna de las entidades, a modo de clave foránea, la clave primaria de la otra entidad
relacionada.
• Se especifica una restricción que define que la clave foránea añadida debe ser única (no
se puede repetir, porque de hacerlo entonces sería una relación 1:N
5. Transformación de Vínculos M:N

¿Cuantas veces puede un empleado


trabajar en un proyecto? O bien,
¿Cuántos registros puedo tener en
Trabaja En para un mismo empleado y
proyecto?

Empleado (cedula, PrimNombre, PrimApellido, SegApellido, Teléfono)

Trabaja_en (cedula, numero_Proyecto, Horas)

Proyecto (Número_Proyecto, Nombre_Proyecto)

Empleado
Proyecto
cedula
numero
primNombre
nombre
PrimApellido 0 …* 0 …*
SegApelllido
telefono
Trabaja_en
Horas

• Para cada vinculo M:N entre dos entidades se crea una relación R.
• Los atributos de la relación R serán las claves primarias de las entidades relacionadas
más los atributos propios del vínculo.
• La clave primaria de la relación R será el conjunto de todos los atributos que sean claves
primarias de las entidades relacionadas.
6. Transformación de Atributos Multivaluados

Lugares_Dptos (Numero_Dpto, Lugar)


Departamento (Número_Dpto, Nombre_Dpto)

• Para cada atributo multivaluado se creará una relación R.


• Los atributos de la relación R serán la clave primaria de las entidad a la cual pertenece el
atributo multivaluado más el (o los) atributos correspondientes al atributo multivaluado.
• La clave primaria de la relación R será la clave primaria de la entidad a la cual pertenece
el atributo multivaluado más el (o los) atributos correspondientes al atributo multivaluado
7. Transformación de Vínculos n-arios

Presta (Numero_Dpto, Codigo_Servicio, RIF, Fecha)

Presta
fecha

Departamento Cliente
numero 0 …* 0 …*
RIF
nombre nombre
1
Servicio
codigo
nombre

• Para cada vinculo M:N entre tres o más entidades se crea una relación R.
• Los atributos de la relación R serán las claves primarias de todas las entidades
relacionadas más los atributos propios del vinculo.
• La clave primaria de la relación R será el conjunto de todos los atributos que sean claves
primarias de todas las entidades relacionadas.

Transformación del Modelo ERE al Modelo Relacional (Extendido)


Transformación al modelo Relacional de:
– Generalización (o Especialización) – Categorización

Definir una serie de esquemas de


relaciones equivalentes
8. Transformación de una Generalización

Usando un diagrama de clases...

Existen cuatro estrategias para transformar una relación de generalización (o especialización)


al modelo Relacional:

• Estrategia 1: Crear una relación R para la entidad padre E y una relación Ri para cada
entidad especializada Ei.
– La relación R tiene todos los atributos de la entidad E.
– Cada relación Ri tiene todos los atributos de la entidad Ei correspondiente.

– Todas las relaciones (tanto R como cada Ri ) comparten la misma clave primaria
de la entidad padre E.

Persona (Cédula, Nombre, Apellido,


Dirección)

Empleado (Cédula, Salario)

Estudiante (Cédula, Carrera)

Profesor (Cédula, Costo_Hora)


Esta estrategia funciona tanto para subclases que se traslapan como para subclases disjuntas y
para especializaciones totales o parciales.
Persona <12453334, 'Pedro', 'Perez', 'Av. 8'>
Empleado <12453334, 2000>
Estudiante <12453334, 'Ingeniería'>

• Estrategia 2: Crear una relación Ri para cada entidad especializada Ei .


– Cada relación Ri tiene todos los atributos de la entidad Ei correspondiente más los
atributos de la entidad padre E.
– La clave primaria de cada relación Ri es la clave primaria de la entidad padre E.

Empleado (Cédula, Nombre, Apellido, Dirección, Salario)

Profesor (Cédula, Nombre, Apellido, Dirección, Costo_Hora)

Estudiante (Cédula, Nombre, Apellido, Dirección, Carrera)

• Estrategia 3: Utilizar una misma relación R para la entidad padre E y para las entidades
especializadas Ei .
– La relación R tiene todos los atributos de la entidad padre E más todos los atributos
todas las entidades especializadas Ei .
– Se crea un atributo adicional que define el “tipo” de entidad Ei que representa una
tupla en particular. – Aplica sólo a casos donde las subclases son disjuntas.
Persona (Cédula, Nombre, Apellido, Direccion,Tipo, Salario, Costo_Hora, Carrera)

Donde Tipo puede ser 0 para la subclase Empleado, 1 para la subclase Profesor o 2 para la
subclase Estudiante
<12453334, 'Pedro', 'Perez', 'Av. 8',0, 2000, NULL, NULL>

• Estrategia 4: Utilizar una misma relación R para la entidad padre E y para las entidades
especializadas Ei . (Similar a la estrategia 3).
– La relación R tiene todos los atributos de la entidad padre E más todos los atributos
todas las entidades especializadas Ei . (Similar a 3)
– Se crea un atributo booleano adicional por cada entidad especializada que define
si una tupla en particular pertenece dicha entidad

Persona (Cédula, Nombre, Apellido, Dirección, Es_Empleado, Salario, Es_Profesor,


Costo_Hora, Es_Estudiante, Carrera)
Los atributos “Es_*” son verdaderos para una tupla si esta es una la clase especializada de la
entidad correspondiente
<12453334, 'Pedro', 'Perez', 'Av. 8',true, 2000, true, 50, false, NULL>
9. Transformación de una Categorización

Existen dos casos posibles al transformar una relación de categorización al modelo Relacional

• Caso 1: Las superclases de la categoría tienen diferentes claves primarias.


– Se crea una relación R que corresponda a la categoría y se asigna una clave
sustituta arbitraria.
– Se añade la clave sustituta a modo de clave foránea a cada una de las relaciones
Ri que correspondan a las superclases de la categoría.
Claves primarias de las superclases no compatibles

Persona (Cédula, Nombre, Apellido, Dirección, IdCuentaHabiente) Compañía (RIF, Nombre,


IdCuentaHabiente) CuentaHabiente (IdCuentaHabiente)

• Caso 2: Las superclases de la categoría tienen la misma clave primaria.


– Se crea una relación R que corresponda a la categoría y se le asigna como atributo
de clave primaria la clave común a todas las superclases de la categoría.
Claves primarias compatibles entre las superclases
Vehículo_Registrado (Matrícula)
Auto (Matrícula, MarcaA, ModeloA, Color)
Camión (Matrícula, ModeloC, NumEjes, Peso)

Se transforma al modelo relacional de la siguiente forma:


3.3 Esquema de la base de datos Relacional
El término "esquema de base de datos" (en inglés Database Schema) puede referirse a una
representación visual de una base de datos, a un conjunto de reglas que rige una base de datos,
o bien, a todo el conjunto de objetos que pertenecen a un usuario en particular. Se especifica
mediante un conjunto de definiciones expresadas mediante un lenguaje especial llamado
lenguaje de definición de datos (LDD).
Los esquemas son raramente modificados, si es que lo son alguna vez. Un esquema de base de
datos corresponde a las declaraciones de variables (junto con definiciones de tipos asociadas)
en un programa. Cada variable tiene un valor particular en un instante de tiempo. Los valores de
las variables en un programa en un instante de tiempo corresponden a un ejemplar de un
esquema de bases de datos.
Los sistemas de bases de datos tienen varios esquemas divididos de acuerdo a los niveles de
abstracción.
Esquema Conceptual: El esquema especifica todos los conjuntos de entidades, conjuntos de
relaciones, atributos y restricciones de correspondencia. El diseñador revisa el esquema para
confirmar que todos los requisitos de datos se satisfacen realmente y no hay conflictos entre sí.
También se examina el diseño para eliminar características redundantes.
Esquema Lógico: Es un mapa de las entidades y sus atributos y las relaciones. El diseñador
traduce el esquema conceptual de alto nivel al modelo de datos de la implementación del sistema
de base de datos que se usará. El diseñador usa el esquema resultante específico a la base de
datos en la siguiente fase.
Esquema Físico: Es una aplicación de un esquema lógico. Se especifican las características
físicas de la base de datos. Estas características incluyen la forma de organización de los archivos
y las estructuras de almacenamiento interno.
De éstos, el esquema lógico es con mucho el más importante, en términos de su efecto en los
programas de aplicación, ya que los programadores construyen las aplicaciones usando el
esquema lógico. El esquema físico está oculto bajo el esquema lógico, y puede ser fácilmente
cambiado usualmente sin afectar a los programas de aplicación. Los programas de aplicación se
dice que muestran independencia física de datos si no dependen del esquema físico y, por tanto,
no deben ser modificados si cambia el esquema físico.
En general, los esquemas de las relaciones incluyen una lista de los atributos y de sus dominios
correspondientes. La definición exacta del dominio de cada atributo no será relevante hasta que
se discuta el lenguaje SQL.
Suele ser almacenado en un Diccionario de Datos. Aunque generalmente el esquema es definido
en un lenguaje de Base de datos, el término se usa a menudo para referirse a una representación
gráfica de la estructura de base de datos.
3.4 Restricciones
Las restricciones son limitaciones que deseamos imponer en nuestro sistema, de forma que sea
imposible almacenar datos incorrectos. Por ejemplo, la limitación de los valores posibles de los
atributos a un subconjunto, lo que denominábamos dominio del atributo.

• Restricciones de integridad
Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones
hechas a la base de datos por los usuarios autorizados no provoquen la pérdida de la consistencia
de los datos. Protegen a la base de datos contra los daños accidentales.
Tipos de restricciones de integridad:
Declaración de claves (primarias, candidatas).
Cardinalidad de la relación – de varios a varios, de uno a varios, de uno a uno.
Participación mín/máx.
Restricciones de los dominios.
Integridad referencial.
Dependencias funcionales.
Dependencias multivaloradas. Los asertos y disparadores permiten implementar restricciones de
integridad.

• Restricciones de los dominios


Las restricciones de los dominios no sólo permiten verificar los valores introducidos en la base de
datos sino también examinar las consultas para asegurarse de que tengan sentido las
comparaciones que hagan.

3.4.1 Integridad de entidad


Se basa en que la clave primaria dispone que los atributos de la clave primaria de una relación
no pueden tener valores nulos.
Ejemplo:

DESPACHOS
Edificio Número Superficie
---------- 120 10
Marina 122 15
Marina 230 20
Diagonal 120 10
Si un despacho tuviese un valor nulo para edificio porque en un momento dado el nombre de este
edificio no se conoce, no podríamos estar seguros de que el valor desconocido de edificio no es
ni Marina ni Diagonal.

Esta regla es necesaria para que los valores de las claves primarias puedan identificar las tuplas
individuales de las relaciones. Si las claves primarias tuviesen valores nulos, es posible que
algunas tuplas no se pudieran distinguir.

A continuación, definimos esta regla de forma más precisa:


- La regla de integridad de entidad de la clave primaria establece que, si el conjunto de
atributos CP es la clave primaria de una relación R, la extensión de R no puede tener
ninguna tupla con algún valor nulo para alguno de los atributos de CP.

Un SGBD relacional tendrá que garantizar el cumplimiento de esta regla de integridad en todas
las inserciones y, también, en todas las modificaciones que afecten a atributos que pertenecen a
la clave primaria de la relación.

3.4.2 Integridad referencial


Las restricciones de integridad proporcionan un medio de asegurar que las modificaciones hechas a la base
de datos por los usuarios autorizados no provoquen la pérdida de la consistencia de los datos. Por tanto,
las restricciones de integridad protegen a la base de datos contra los daños accidentales.

Una base de datos contiene unos datos que, en cada momento, deben reflejar la realidad o, más
concretamente, la situación de una porción del mundo real. En el caso de las bases de datos dato
relacionales, esto significa que las tuplas o filas que contienen las relaciones deben tener valores que
reflejen la realidad correctamente.

Las restricciones de integridad referencial están especificadas entre dos relaciones y se utilizan para
mantener la consistencia entre las tuplas de dos relaciones. Informalmente, las restricciones de integridad
referencial dicen que una tupla de una relación que hace referencia a otra relación debe hacer referencia
a una tupla existente de esa relación.

La regla de integridad referencial está relacionada con el concepto de clave foránea. Concretamente,
determina que todos los os valores que toma una clave foránea deben ser valores nulos o valores que
existen en la clave primaria que referencia.

Un SGBD relacional tendrá que hacer cumplir esta regla de integridad. Deberá efectuar comprobaciones
cuando se produzcan las siguientes operaciones:

• Inserciones en una relación que tenga una clave foránea.


• Modificaciones que afecten a atributos que pertenecen a la clave foránea de una relación.
• Borrados en relaciones referenciadas por otras relaciones.
• Modificaciones que afecten a atributos que pertenecen a la clave primaria de una relación
referenciada por otra relación.
3.5 Integridad de dominio
La regla de integridad de dominio está relacionada, como su nombre indica, con la noción de
dominio. Esta regla establece dos condiciones.
La primera condición consiste en que un valor no nulo de un atributo Ai debe pertenecer al dominio
del atributo Ai; es decir, debe pertenecer a dominio(Ai).
Esta condición implica que todos los valores no nulos que contiene la base de datos para un
determinado atributo deben ser del dominio declarado para dicho atributo.
Recordemos que los dominios pueden ser de dos tipos: predefinidos o definidos por el usuario.
Observad que los dominios definidos por el usuario resultan muy útiles, porque nos permiten
determinar de forma más específica cuáles serán los valores admitidos por los atributos.
Esta segunda condición sirve para establecer que los operadores que pueden aplicarse sobre los
valores dependen de los dominios de estos valores; es decir, un operador determinado sólo se
puede aplicar sobre valores que tengan dominios que le sean adecuados.
Las restricciones permiten definir el modo en que SQL Server automáticamente fuerza la
integridad de la base de datos.
En estas se definen reglas indicando los valores permitidos en las columnas y son el mecanismo
estándar para asegurar integridad.
Usar restricciones es preferible a usar desencadenadores, reglas o valores por defecto. El query
optimizer (optimizador de consultas) de SQL Server utiliza definiciones de restricciones para
construir planes de ejecución de consultas de alto rendimiento.
Se puede asegurar la integridad de dominio restringiendo el tipo (a través de tipos de datos), el
formato (a través de las restricciones CHECK y de las reglas).
CONCLUSIÓN
En esta unidad, podemos entender que el modelo relacional es un proceso que se debe llevar a
cabo en el desarrollo de la base de datos y debe ser considerado porque nos muestra el tipo de
relación que tenemos, la cardinalidad y el tipo de clave que contiene.
La función del modelo relacional es ganar un buen control del sistema entendiendo cómo aplicar
el modelo de relación de entidades y la cardinalidad correspondiente a cada tabla. Otro punto a
destacar es que también sabemos aplicar y aprender conceptos como entidad, atributo y llave
para así utilizar estos dentro de la tabla.
REFERENCIAS
ABRAHAM SILBERSCHATZ. (2006). FUNDAMENTOS DE BASES DE DATOS (5ª ED.).
ESPAÑA: S.A. MCGRAW-HILL.
Rafael Camps Paré, Luis Alberto Casillas Santillán. (2005). Bases de datos. Av. Tibidabo, 39-43,
08035 Barcelona: Eureca Media, SL.
ELMASRI, R. (2007). Fundamentos de Sistemas de Bases de Datos. Madrid: PEARSON
EDUCACIÓN.
Silberschatz, A. (2002). FUNDAMENTOS DE BASES DE DATOS. Madrid: McGRAW-HILL.
Integridad de dominio. (2010, 30 enero). RAHSuarez’s Blog.
https://rahsuarez.wordpress.com/2010/01/05/integridad-de-dominio-restricciones-
check/#:%7E:text=La%20integridad%20de%20dominio%20es,de%20la%20base%20de%20dat
os.&text=Usar%20restricciones%20es%20preferible%20a,reglas%20o%20valores%20por%20d
efecto/

UNIDAD 3 MODELO RELACIONAL. (2019, 20 mayo). modeloer2.blogspot.com.


https://modeloer2.blogspot.com/2019/05/25-la-notacion-e-r-con-
uml.htmlhttps://modeloer2.blogspot.com/2019/05/25-la-notacion-e-r-con-uml.html

Jorge Sánchez, [Unidad 3] El Modelo Relacional, consultado el 15/11/2020, disponible en:


https://funbasedato.blogspot.com/2019/11/unidad-3-modelo-relacional.html
https://www.dataprix.com/es/bases-datos-master-software-libre-uoc/1-introduccion-al-modelo-
relacional
http://pegaso.ls.fi.upm.es/BD/Documentacion/MR-Introduccion.pdf
Oppel, A. (2010). Fundamentos de bases de datos. McGraw-Hill Interamericana.
https://elibro.net/es/lc/cuautla/titulos/37322

También podría gustarte