BASES DE DATOS II

Paola Otálora

EJE 2
Analicemos la situación

Fuente: Shutterstock/579290236
 Introducción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

El modelo de datos relacional . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

Diseño de las bases de datos relacionales . . . . . . . . . . . . . . . . . . . . . . . . . 7

Diagramas de entidad-relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Concepto de herencia en bases de datos relacionales . . . . . . . . . . . . . . 15

Vínculo existente entre el modelo relacional y el diagrama de

entidad- relación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Bibliografía . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
ÍNDICE
 Introducción

Uno de los modelos de bases de datos más amplia-

mente difundidos es el modelo relacional, ya que desde el
momento de su formulación, en el año de 1970, ha demos-
trado ser un paradigma que permite representar la reali-
dad de los datos informáticos. Se debe tener claro que un
insumo fundamental para este modelo son los diagra-
mas de entidad-relación, a partir de los cuales es posible Diagrama enti-
INTRODUCCIÓN

estructurar el flujo de datos y la lógica del negocio de cada dad-relación

empresa, elementos que serán estudiados en el presente Es una herramienta que está
formada por un conjunto
referente de pensamiento. de conceptos que permiten
describir la realidad median-
te representaciones gráficas
Elementos como entidades, relaciones y cardinalidad y lingüísticas (Marqués, 2011,
juegan un papel decisivo en el correcto análisis de bases p. 106).

de datos, pues de ellos parte la manera de vincular la infor- Reglas del negocio
Describen las características
mación de forma que pueda apoyar efectivamente los pro- principales sobre el com-
cesos de toma de decisiones para que se logre responder portamiento de los datos
así como las de la empresa
la siguiente inquietud, ¿qué tan relevante y justificable es (Marqués, 2011, p. 5).
el uso del modelo relacional tradicional en la creación de
una base de datos teniendo en cuenta las diferentes herra-
mientas de gestión de bases de datos existentes?
El modelo de datos
relacional
 El científico informático inglés Edgar Codd propuso en el año de 1970 los fundamentos
de lo que hoy conocemos como el modelo relacional para bases de datos, el cual plantea
una metodología para interactuar con la información basada en el álgebra relacional y
el cálculo de predicados.

Si bien el modelo relacional no es el único que existe, ha sobresalido notablemente

sobre los demás y es claramente una de las modalidades más ampliamente utilizadas en
la actualidad puesto que se considera a los datos como un conjunto ordenado y categori-
zado con el que es posible el establecimiento de relaciones, facilitando el establecimiento
de correspondencias entre datos similares.

Este modelo, también ha sobresalido sobre los demás, debido

principalmente a su sencillez al momento de representar los datos,
siendo altamente intuitivo, de forma que un usuario no experto,
estaría fácilmente en capacidad de comprender las relaciones y
su significado.

Algunos años después de la formulación realizada por Codd,

surgió un nuevo lenguaje SQL (Structured Query Language), el SQL
cual terminó por consolidar el modelo relacional pues resultó Lenguaje estructurado de
consulta (Marqués, 2011, p.
ser el lenguaje ideal para realizar los procesos de explotación 40).
de los datos.

El modelo de datos relacional debe ofrecer algún mecanismo

por el cual los diseñadores y los programadores de la base de
datos puedan generar un conjunto de relaciones que permitan
abstraer y representar la información tal como se muestra en el
mundo real.

Figura 1.
Fuente: Shutterstock/83873797

Bases de datos II - eje 2 analicemos la situación 5

 Existen tres aspectos fundamentales
en los que el modelo relacional se enfoca,
veamos:
• Estructura: a través de este aspecto
el modelo debe permitir abstraer y
representar la información del mun-
do real.
• Manipulación: con esta caracterís-
tica el modelo relacional ofrece ca-
pacidades para generar, recuperar y
modificar la información.
• Integridad: por medio de la genera-
ción de reglas que deben ser respe-
tadas y cumplidas al momento del
ingreso de los datos, el modelo ga-
rantiza que la información sea con-
sistente y coherente.
Por medio del modelo relacional, un
SGBD (sistema gestor de bases de datos)
se encarga de brindar apoyo a los procesos
de definición y estructuración de los datos,
facilitando la manipulación controlada y
segura de información, así como la certi-
ficación en relación al cumplimiento de las
reglas de integridad.
Uno de los principales objetivos del
modelo de datos relacional es el de sumi-
nistrar un esquema de trabajo que, desde
el punto de vista del usuario, tenga una
estructura clara y ordenada que, por medio
de la lógica de sus relaciones, pueda ser
operada con naturalidad, agregando de
paso un mayor grado de independencia a
los datos.
¡Importante!
Recordemos pues que un SGBD debe pro-
porcionar independencia de los datos a nivel
físico y a nivel lógico, por tanto, la estructura
de los datos a nivel lógico –como el usuario
ve la información–, no tiene por qué verse
afectada por las técnicas empleadas para el
almacenamiento a nivel físico –como el com-
putador ve la información– y viceversa.
Las bases de datos apoyadas en el
modelo relacional establecen su enfoque
en el desarrollo y creación de asociaciones
entre las tablas contenidas por la misma
base de datos, a esta noción se la conoce
como relación entre tablas. En el proceso
de vincular dos o más tablas se deben reco-
nocer los datos contenidos una de estas,
que tiene algún tipo de relacionamiento
con los datos de la otra, tal procedimiento
se realiza durante la etapa del diseño con-
ceptual de la base de datos.
Esquema conceptual
Es modelar los datos del negocio
de manera independiente de la
tecnología a utilizar (Andy Oppel,
2009, p. 30).
Instrucción
A continuación, se invita al estudiante a
revisar el recurso de aprendizaje: infografía,
acerca del modelo relacional de datos. Lo
encuentra disponible en la plataforma.
Bases de datos II - eje 2 analicemos la situación 6
 Diseño de las bases de datos relacionales

El pilar fundamental sobre el que se apoya el diseño de bases de datos relaciones está
directamente relacionado con las tres características fundamentales de la arquitectura
ANSI/Sparc, es decir, nivel conceptual, lógico y físico.

Comenzaremos analizando el nivel conceptual, esto es, la creación de diagramas

de entidad-relación y su posterior traducción a un modelo de datos relacional, estos
elementos preliminares se desarrollan a partir de los procesos de levantamiento de los
requerimientos empresariales para el tratamiento de los datos.

Diagramas de entidad-relación

Los diagramas de entidad-relación son una representación esquemática en la que

se plasman los diferentes elementos que conforman un sistema de procesamiento de
datos como las entidades, sus características y sus relaciones, siendo muy similares a
un diagrama de flujo. Estos ayudan a la compresión de los procesos realizados por las
empresas en lo referente al tratamiento de la información.

Para desarrollar adecuadamente un diagrama de entidad-relación, algunas veces

nombrado diagrama E/R, se deben incluir los siguientes elementos (ver figura 2).

Entidad Atributo Relación Cardinalidad

Simple -
Fuerte Compuesto Entidad
#
fuerte

Débil Multivalorado

Entidad #
fuerte
Derivado

Figura 2. Componente del diagrama entidad-relación

Fuente: propia

Entidad

Al hablar de entidad, se hace referencia de forma general Entidad

Es una persona, lugar, cosa,
a cualquier objeto del mundo real, el cual, de acuerdo con su suceso o concepto sobre
naturaleza, posee una serie de características y particularidades el que se compilan datos
(Oppel, 2009, p. 30).
únicas que ayudan a diferenciarlo de otros objetos o entidades.

Bases de datos II - eje 2 analicemos la situación 7

 Dentro del modelo relacional una entidad puede ser débil o fuerte, en este momento,
antes de entrar a explicar lo que es una llave, diremos que una entidad débil se caracteriza
por no tener llaves propias; sin embargo, sí pueden tener llaves de relación, es decir, llaves
de otras tablas, comúnmente denominadas llaves foráneas. Por otra parte, una entidad
fuerte sí posee atributos clave o llaves propias.

Ejemplo

Algunos ejemplos tradicionales de entidad son:

Una persona, un automóvil, un libro, un paciente y su historia médica, en

la figura 3 se puede apreciar gráficamente la diferencia entre una entidad
débil (historia_médica) y una entidad fuerte (paciente). La entidad fuerte
puede existir sin la necesidad de la existencia de una entidad débil, sin
embargo, la entidad débil no puede existir a menos de que exista algún tipo
de relación con una entidad fuerte. De esta forma, un paciente puede ser
registrado en la base de datos aun cuando no tenga una historia médica,
no obstante, una historia médica no puede ser registrada a menos que sea
vinculada a un paciente en particular.

Paciente Historia médica

Figura 3. Entidad fuerte-entidad débil
Fuente: propia

De manera análoga a la realidad, dos o más entidades podrían tener los

mismos atributos, por ejemplo, los médicos y los pacientes tiene en común
los atributos de nombre, apellidos, teléfono y dirección, pero también exis-
tirán otros que no son comunes, por ejemplo, el médico, a diferencia de
los pacientes, deberá tener alguna licencia para ejercer su profesión, para Redundancia
optimizar el almacenamiento, su identificación y evitar redundancias. Se Campos repetidos en di-
suelen generar entidades o clases superiores para agruparlos, en este caso, ferentes tablas (Valderrey,
2014, p. 31).
ambas entidades (médicos y pacientes) pueden ser contenidos por la clase
personas, la cual hereda parte de los atributos que son idénticos, dejando
a cada clase únicamente el manejo de los atributos con los que difieren.

¡Recordemos que!
Se invita al estudiante a revisar el recurso de aprendizaje:
nube de palabras, donde encontrará los principales con-
ceptos asociados al desarrollo de este eje. Disponible en
la plataforma.

Bases de datos II - eje 2 analicemos la situación 8

Atributo
Atributo
Se trata de las características que tienen las entidades, las Es un hecho unitario que
caracteriza o describe de al-
cuales definen cualidades y/o cantidades, además, hacen que guna manera a una entidad
las entidades sean diferentes entre sí. En los diagramas de E/R (Oppel, 2009, p. 32).

encontramos los siguientes tipos de atributos:

• Simple: un atributo en su forma más sencilla se trata de características atómicas,

las cuales, por definición, no pueden ser divididas, ejemplo de ello son el estrato
social, la edad, la estatura y el género de una persona.

• Compuestos: son un poco más estructurados que los atributos simples, puesto
que pueden ser contenedores de otros atributos, por ejemplo, el nombre de una
persona se puede dividir en nombre y apellidos, o en primer nombre, segundo nom-
bre, primer apellido y segundo apellido. Otro ejemplo sería la fecha de nacimiento
de una persona, la cual se puede descomponer en año, mes y día.

• Multivalorado: estos atributos están facultados para contener valores múltiples

dentro del mismo campo, así un doctor podría haber desarrollado dos o más es-
pecialidades en el área de medicina, por tanto, cada especialidad finalizada debe
ser cargada e incluida dentro de su perfil profesional.

• Derivado: se trata de un cálculo, una operación o una deducción lógica que puede
ser obtenida de un dato o valor existente, por ejemplo, la edad puede ser calculada
tomando como base la fecha de nacimiento y la fecha actual. En la figura 4 se
puede apreciar un tipo de entidad con todos los ejemplos de atributos.

Atributo nulo
Atributo nulo
En la práctica, algunos atributos de entidades podrían no Es un atributo que no tiene
ningún contenido (Valderrey,
aplicar o no ser necesario su diligenciamiento, por ejemplo, una 2014, p. 45).
persona podría tener un teléfono celular, pero no un teléfono fijo,
en este caso, este último atributo no tendría un valor dentro de
la base de datos para esa persona.

Bases de datos II - eje 2 analicemos la situación 9

 Médico

Identificación Nombres Apellidos Fecha de Especialidad Edad

nacimiento

Primer Segundo
apellido apellido
Figura 4. Entidad fuerte y atributos de diferentes tipos
Fuente: propia

Relación

A través de este elemento, es posible, dentro de un modelo de bases de datos relacio-

nal, desarrollar asociaciones entre diferentes entidades, la cuales gráficamente se presen-
tan con un rombo en cuyo interior se indica alguna acción con un verbo generalmente. Al
igual que las entidades, las relaciones también pueden contener uno o más atributos. En
la figura 5 se esquematizan dos entidades fuertes relacionadas por medio de la acción
de consulta, como se puede apreciar, la relación incluye dos atributos: la fecha en la que
el paciente es atendido por el médico y el tipo de consulta realizada.

Médico Consulta Paciente

Fecha de Tipo de
consulta consulta

Figura 4. Entidad fuerte y atributos de diferentes tipos

Fuente: propia

Tipos de relaciones:

• Relaciones binarias: es el tipo más común de relación, en la que se vinculan dos

entidades.

• Relaciones n-arias: con este tipo de relación, es posible vincular a 3 o más entida-
des en una misma relación.

• Relaciones dobles: es posible también establecer dos o más tipos de relaciones

entre el mismo par de entidades.

• Relaciones reflexivas: es un tipo de relación en el que una única entidad se rela-

ciona consigo misma.

Bases de datos II - eje 2 analicemos la situación 10

 En la figura 6 se pueden apreciar los diferentes tipos de relaciones entre entidades.

Persona

Médico Consulta Paciente

Médico Consulta Paciente

Relación binaria Relación n-aria

Amigo

Médico Paciente Es jefe Médico

Consulta

Relación doble Relación reflexiva

Figura 6. Tipos de relaciones
Fuente: propia

Cardinalidad
Cardinalidad
Dentro del modelamiento de bases de datos relacionales, el Es el número de tuplas que
concepto de cardinalidad se refiere al nivel de la relación que contiene una relación (Mar-
qués, 2011, p. 16).
existe entre dos o más entidades, así como a la forma en que
Relación uno a uno
estas se asocian. Es una asociación en la que
una instancia de una entidad
se puede asociar cuando mu-
Respecto a la forma, existen 3 tipos de cardinalidad: cho con una instancia de la
otra entidad (Oppel, 2009, p.
34).
• Uno a uno: este tipo de relación ocurre cuando un atributo
de una entidad X tiene una relación únicamente con otro Relación uno a muchos
Es una asociación entre dos
de la entidad Y; por ejemplo, un paciente únicamente pue- entidades en la que cualquier
de tener una historia clínica. instancia de la primera entidad
puede asociarse con una o más
instancias de la segunda enti-
• Uno a muchos: este tipo de relación ocurre cuando un atri- dad y cualquier instancia de la
segunda entidad puede aso-
buto de la entidad X se relaciona con varios atributos de ciarse cuando mucho con una
la entidad Y; por ejemplo, la enfermedad de un paciente instancia de la primera (Oppel,
2009, p. 35).
puede tener muchos tratamientos.
Relación muchos a mu-
chos
• Muchos a muchos: este tipo de relación ocurre cuando Es una asociación entre dos
muchos atributos de la entidad X se relacionan con varios entidades en la que cualquier
instancia de la primera entidad
atributos de una entidad Y; por ejemplo, un paciente pue- puede asociarse con una o más
de ser atendido por muchos médicos y, de la misma forma, instancias de la segunda, y vi-
ceversa (Oppel, 2009, p. 36).
un médico atiende a muchos pacientes (ver figura 7).

Bases de datos II - eje 2 analicemos la situación 11

 Historia 1 1
clínica Tiene Paciente Relación uno a uno

1 Tiene M Tratamiento
Paciente Relación uno a muchos

Historia M Atiente M
clínica Médico Relación muchos a muchos

Figura 7. Formas de cardinalidad

Fuente: propia

Respecto al nivel, existen 2 tipos de cardinalidad:

• Cardinalidad máxima: este nivel corresponde a la cantidad máxima de ocurren-

cias con las que puede estar asociada una entidad, la cual puede tomar valores
de 1 hasta n, siendo n el valor máximo posible de una ocurrencia; por ejemplo,
un médico podrá tener mínimo un paciente hasta un máximo de n pacientes. De
manera análoga, un paciente podrá tener mínimo un médico hasta un máximo
de M médicos.

• Cardinalidad mínima: este nivel corresponde a la cantidad mínima de ocurren-

cias con las que puede estar relacionada una entidad, la cual puede tomar valores
de 0 hasta 1, siendo n el valor máximo posible de una ocurrencia; por ejemplo, un
paciente puede tener un mínimo de cero tratamientos hasta un máximo de n,
pero un tratamiento va a corresponder solamente a un paciente.

La cardinalidad se puede expresar como una colección de pares en las que el primer
valor se refiere a la cardinalidad mínima y el segundo valor se refiere a la cardinalidad
máxima: (cardinalidad mínima, cardinalidad máxima) por ejemplo (0,1) – (1,1) – (0,M) – (1,
M) – (N,M), ayudan a describir la forma y el nivel en ambos sentidos. Ver figura 8.

Bases de datos II - eje 2 analicemos la situación 12

 Una historia clínica corresponde solo a un paciente

Historia (1,1) (1,1)

clínica Tiene Paciente Relación uno a uno

Un paciente tiene solo una historia clínica

Un paciente puede tener 0 o muchos tratamientos

(1,1) (0,M) Tratamiento

Paciente Tiene Relación uno a muchos

Un tratamiento corresponde a un paciente

Figura 8. Relaciones de cardinalidad
Fuente: propia

Lectura recomendada
Se invita al estudiante a realizar la lectura complementaria
1, capitulo 2:

Bases de datos

Rafael Campos Paré, et ál.

También lo invitamos a obser var la siguiente

videocápsula:

¿Qué son las bases de datos relacionales?

https://youtu.be/CBVp8sbo1w0

Llaves

Dentro del marco de las bases de datos relacionales, las llaves hacen referencia a
campos o atributos por medio de los cuales es posible relacionar diferentes tablas. Existen
diferentes tipos de llaves:

• Llave primaria: conocida también como llave principal, es un requisito de todas

las entidades fuertes. Se trata de un atributo que permite identificar de manera
unívoca a cada uno de los registros contenidos en la tabla, de forma que no pue-

Bases de datos II - eje 2 analicemos la situación 13

 den existir dos o más registros con la misma llave primaria. Ejemplo: el documento
de identidad describe únicamente a una persona, de modo que no pueden existir
dos personas con el mismo número de documento. De forma análoga, en las ba-
ses de datos se deben identificar las llaves primarias de cada tabla, su elección es
libre siempre y cuando se cumpla con el requisito que no puede repetirse en más
de un registro. Dentro de la notación tradicional de bases de datos relacionales se
reconocen las llaves primarias puesto que son los atributos que van subrayados.

• Llave foránea: conocida también como llave externa, se trata de un campo o atri-
buto en una tabla que hace referencia a la llave primaria de otra tabla, a través de
estas llaves se puede establecer que existe una relación entre ambas tablas.

Llave primaria

Tabla del paciente (ID_paciente, nombres, apellidos, edad y teléfono)

Llave foránea

Tabla del tratamiento (ID_tratamiento, nombre, ID_paciente y detalles)

Figura 9. Llave primaria y llave foránea
Fuente: propia

En la figura 9 se puede apreciar la forma en que se definen las llaves primarias y

secundarias dentro de una relación de tablas en una base de datos.

• Súper llave: conocida también como llave compuesta, se presenta cuando en una
tabla no existe una llave primaria, de forma tal que la unión de dos o más cam-
pos de la tabla permite la creación de una llave primaria, es decir: que identifica
a todos los registros de manera única, por ejemplo, es posible unir los campos de
teléfono y correo para crear una súper llave (ver figura 10).

Llave compuesta

Tabla del paciente (nombres, apellidos, edad, teléfono y correo )

Figura 10. Llave compuesta
Fuente: propia

Bases de datos II - eje 2 analicemos la situación 14

 Concepto de herencia en bases de datos relacionales

Es un mecanismo de adaptación tomado del paradigma de la programación orientada

a objetos (POO), aplicado al modelamiento de bases de datos relacionales a través del
cual se establece un tipo de relación entre una entidad padre hacia una entidad hija en la
cual la tabla padre “hereda” o transfiere un grupo de campos o atributos a la tabla hija,
pudiendo compartir de esta forma una serie de características, mejorando y optimizando
el modelo y aprovechando elementos como la extensión y la reutilización.

La relación de herencia se representa mediante un triángulo que está

interconectado a las entidades por medio de líneas. La entidad conectada
por el vértice superior del triángulo se denomina la entidad “padre”, y las
entidades “hijo” se conectan por la base del triángulo, únicamente puede
darse herencia simple, es decir, solo puede existir una entidad “padre”.

Continuando con el ejemplo que se viene desarrollando, tanto un medio como un

paciente pueden heredar de una entidad padre denominada “persona”, que contiene
atributos genéricos como identificación, nombre, apellido, teléfono, entre otros. Ver figura
11 para comprender mejor este concepto.

ID Nombres Apellidos Teléfono Correo Dirección Género

Persona

1,1
Corresponde

1,1 1,1
Paciente Médico

Tipo de
ID_paciente ID_médico Especialidad
paciente

Figura 11. Herencia

Fuente: propia

Bases de datos II - eje 2 analicemos la situación 15

 En la figura 11 se puede apreciar el concepto de herencia, en el que la entidad “padre”
comparte los datos personales que son iguales para cualquier tipo de persona, en este
caso las entidades “hijas”, sea paciente o médico, son un tipo de persona que además
tiene unas características particulares en cada caso. Para la entidad "hija Paciente", se
tiene un ID_paciente –que además es llave primaria– y un tipo de paciente; para la entidad
Médico se tiene un ID_médico y una especialidad.

Vínculo existente entre el modelo relacional y el diagrama de

entidad- relación

El diagrama entidad-relación es un modelo conceptual que va muy de la mano con las

reglas del negocio y que genera el diseño de la base de datos; por otra parte, el modelo
relacional es una estructura que con base en las tablas y una serie de relaciones permite
el almacenamiento físico de los datos bajo una estructura jerárquica que respeta el
concepto de estructura, manipulación e integridad; claramente, se trata de un proceso
en el que se crea una estructura fundamentada en el diagrama entidad-relación y pos-
teriormente se transforma en un modelo relacional.

Instrucción
Se invita al estudiante a realizar la actividad de
aprendizaje: prácticas o simulaciones. Disponible en
la plataforma.

Durante la lectura del referente de pensamiento correspondiente al eje 3 se abordaron

los temas del diagrama entidad-relación y su importancia al momento de desarrollar un
modelo de bases de datos relacionales; se estudiaron también los conceptos de entida-
des, relaciones, cardinalidad y finalmente se planteó la importancia de las denominadas
llaves primarias en la correcta identificación de cada uno de los registros almacenados.

Como se analizó en el presente referente, a través del diseño conceptual se logra hacer
una descripción de alto nivel de la estructura de la base de datos, la cual resulta ser
independiente del sistema gestor de bases de datos implementado el objetivo principal:
describir el contenido de información de la base de datos.

A continuación, se invita al estudiante a desarrollar la actividad evaluativa.

Bases de datos II - eje 2 analicemos la situación 16

 Bibliografía

Abril, D., y Pérez, J. (2007). Estado actual de las tecnologías de bodega de

datos y OLAP aplicadas a bases de datos. Recuperado de http://www.
redalyc.org/html/643/64327109/

Caro, J. (2016). El modelo relacional. Recuperado de http://informatica.

uv.es/estguia/ATD/apuntes/teoria/documentos/ModeloRelacional.pdf

Díaz, A. (2015). Bases de datos. Recuperado de https://aiu.edu/cursos/

base%20de%20datos/pdf%20leccion%201/lecci%C3%B3n%201.pdf
BIBLIOGRAFÍA

Escalante, J. (2011). Bases de datos. Modelo relacional. Recuperado

de http://files.especializacion-tig.webnode.com/200000708-
0c8db0e832/Presentaci%C3%B3n3%20bd.pdf

Elmasri, R., y Shamkant, N. Navathe. (2007). Fundamentos de Sistemas de

Bases de Datos. Boston USA: Addison-Wesley.

Frassia, M. (2016). Introducción a las bases de datos. Recuperado de http://

www.cursogis.com.ar/BasesP/Zip/Base_Clase1.pdf

Fuentes, M. (2013). Bases de datos. Recuperado de http://www.cua.uam.

mx/pdfs/conoce/libroselec/Notas_del_curso_Bases_de_Datos.pdf

Guzmán, E. (2015). Modelo Relacional. Recuperado de http://disi.unal.edu.

co/profesores /eleonguz/old/BD_2014_II/presentaciones /S4_modelo_
relacional.pdf

Quintero, J., Anaya, R., Marín, J., y López, A. (2012). Un estudio comparativo
de herramientas para el modelado con UML. Recuperado de http://
publicaciones.eafit.edu.co /index.php /revista-universidad-eafit /
article/view/838

Olarte, C. (2015). El Modelo Relacional. Recuperado el 10 de 07

de 2018, de http://cic.javerianacali.edu.co/wiki/lib/exe/fetch.
php?media=materias:mrelacional.pdf

Romero, A., González, J., y Callejas, M. (2012). Utilidad y funcionamiento

de las bases de datos NoSQ. Recuperado de http://www.redalyc.org/
pdf/4139/413940772003.pdf
 Sánchez, J. (2004). Diseño Conceptual de Bases de Datos. Recuperado de
http://www.emtelco.com.co/sites/default/files/2017-03/disenoBD.pdf

Sánchez, J. (2013). El Modelo Relacional de Base de datos. Recuperado

de https://jorgesanchez.net/presentaciones/bases-de-datos/pdf/
modelo-relacional.pdf

Velázquez, J., Álvarez, F., y Moreno, L. (2017). Generador del Modelo

Relacional y Esquemas de Bases de Datos a partir del modelo Entidad/
BIBLIOGRAFÍA

Relación. Recuperado de http://eprints.ucm.es/9037/1/Generador_del_

Modelo_Relacional_y_Esquemas_de_Bases_de_Datos.pdf