Universidad Nacional Abierta y a Distancia – Unad

Bases De Datos Básico

Participantes

Nubia Esperanza Prada Barajas

Roberto Carlos Siabatto
Héctor Efrén Guerrero Barreto
David Mauricio Rojas

Grupo: 301330_48

Presenta a: Jairo Martínez Banda

Universidad Nacional Abierta y a Distancia – Unad

Fecha: 09/04/2019
 Tabla de contenido
INTRODUCCIÓN ....................................................................................................................... 3
OBJETIVOS ................................................................................................................................ 4
RESULTADO DE LA ACTIVIDAD ......................................................................................... 5
BITÁCORA ................................................................................................................................. 6
ENSAYO MODELO RELACIONAL ....................................................................................... 7
CONCLUSIONES ..................................................................................................................... 16
REFERENCIAS ........................................................................................................................ 17
 INTRODUCCIÓN

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, aquélla parte de la realidad que nos interesa.

En este caso de la actividad retomamos los conceptos anteriores y decimos que bajo la solicitud de la
guia de actividades se pretende mostrar por medio de un ensayo los conceptos de modelo relacional
incluyendo las siguientes características específicas, Modelo Relacional, Base Teórica y conceptual,
Descripción, Esquema, Instancias, Técnica de normalización, Formas normales, Ventajas,
Desventajas, y el concepto de Diccionario de Datos.

De igual forma se muestra el resultado de la actividad donde se evidencia la descripción de la

transformación de entidades en tablas, así mismo la descripción de la transformación de atributos en
columnas, la descripción de como agregar a cada tabla un identificador único (UID) o primary key, al
igual que la descripción de la transformación de las relaciones 1:1 o 1:m en llaves foráneas e
implementando el concepto de la integridad referencial y la descripción de la aplicación de las técnicas
de normalización al modelo Relacional, seguido del proceso de construcción y diseño del diccionario
de Datos del modelo Relacional.
 OBJETIVOS

 Dar solución a los puntos propuestos solicitados de acuerdo a los requerimientos exigidos por
la guia de actividades.

 Explicar en un ensayo el modelo relacional.

 Diseñar el Modelo Relacional funcional en el software SQL Developer Data Modeler

 Dar solución a la descripción de la aplicación de las técnicas de normalización al modelo

Relacional.

 Realizar una descripción de la transformación de entidades en tablas y la descripción de la

transformación de atributos en columnas.

 Agregar a cada tabla un identificador único (UID) o primary key, al igual la transformación
de las relaciones 1:1 o 1:m en llaves foráneas, implementando el concepto de la integridad
referencial.

 Diseñar el diccionario de Datos del modelo Relacional.

RESULTADO DE LA ACTIVIDAD
 BITÁCORA

Tabla con el enlace a la bitácora individual creada en Google Drive

David Mauricio https://drive.google.com/drive/folders/1eYg9dLAutlodTfTvo-o9lselX9NpL-

Rojas LG?usp=sharing
 ENSAYO MODELO RELACIONAL

Un diagrama entidad-relación, también conocido como modelo entidad relación o ERD, es un

tipo de diagrama de flujo que ilustra cómo las "entidades", como personas, objetos o conceptos, se
relacionan entre sí dentro de un sistema. Los diagramas ER se usan a menudo para diseñar o depurar
bases de datos relacionales en los campos de ingeniería de software, sistemas de información
empresarial, educación e investigación. También conocidos como los ERD o modelos ER, emplean un
conjunto definido de símbolos, tales como rectángulos, diamantes, óvalos y líneas de conexión para
representar la interconexión de entidades, relaciones y sus atributos. Son un reflejo de la estructura
gramatical y emplean entidades como sustantivos y relaciones como verbos. (Inc., 2017)

Los diagramas de ER se relacionan con los diagramas de estructura de datos (DSD), que se
centran en las relaciones de los elementos dentro de las entidades, en lugar de las relaciones entre las
entidades mismas. Los diagramas ER a menudo se combinan con los diagramas de flujo de datos
(DFD), que trazan el flujo de la información para procesos o sistemas.
 ¿Para qué sirven las bases de datos? Una base de datos es un conjunto de datos que pertenecen
al mismo contexto almacenados sistemáticamente para su posterior uso. En este sentido, una biblioteca
puede considerarse una base de datos compuesta en su mayoría por documentos y textos impresos en
papel e indexados (gracias al ISBN) para su consulta. Desde el punto de vista de la Informática, la base
de datos es un sistema formado por un conjunto de datos almacenados en discos que permiten el acceso
directo a ellos y un conjunto de programas que manipulen ese conjunto de datos

¿Qué es un diagrama entidad-relación? Es un diagrama conceptual gráfico que representa un

mini mundo gracias a un conjunto de entidades y relaciones establecidas entre ellas que tienen sentido
sobre un cierto dominio de datos. También se puede llamar esquema entidad-relación. En muchos
casos emplearemos la notación E/R para abreviar “entidad-relación”. Una entidad es una
representación de un objeto individual concreto del mundo real.

Las entidades tienen atributos. Un atributo de una entidad es una característica interesante sobre
ella, es decir, representa alguna propiedad que nos interesa conocer. Se denomina clave al conjunto de
atributos que identifican de forma unívoca una entidad. Las entidades se vinculan mediante relaciones
que, en ciertas variantes de la notación, pueden también tener sus propios atributos. En principio, estas
relaciones pueden ser n-arias, pero en la práctica se suele trabajar con relaciones binarias. Por ejemplo,
una relación ternaria entre entidades A, B y C puede representarse por una nueva entidad D que tenga
relaciones binarias con cada una de A, B y C. Nosotros permitiremos relaciones binarias y ternarias.

Para cada entidad pueden existir en un momento dado cero, una o muchas instancias. Estas
instancias toman valores para sus atributos de los dominios de datos definidos para aquellos. Las
instancias de una relación son pares ordenados de instancias de las entidades que dicha relación
vincula.

Una relación R entre dos entidades A y B se puede clasificar de acuerdo con su cardinalidad y
su participación:

Cardinalidad
 R es uno a uno cuando a cada instancia de A le corresponde una y solo una instancia de B. 8
o R es uno a muchos cuando a cada instancia de A le pueden corresponder varias instancias
de B, pero cada instancia de B sólo se relaciona con una única instancia de A.
 R es muchos a muchos cuando a cada instancia de A le pueden corresponder varias instancias
de B y asimismo a cada instancia de B le pueden corresponder varias instancias de A.

Participación
 R es total en A si para cada instancia de A existe siempre una instancia de B relacionada
mediante R o En caso contrario, R es parcial en A.

¿En qué consiste el modelo relacional? El modelo relacional es la representación lógica del
esquema entidadrelación. Este es el modelo de bases de datos más utilizado en la actualidad para
modelar problemas reales y administrar datos dinámicamente. Su idea fundamental se basa en el
concepto de tablas, que a su vez se componen de registros (las filas de una tabla) y campos (las
columnas de una tabla).
 Una tabla es una estructura lógica que sirve para almacenar los datos de un mismo tipo (desde el
punto de vista conceptual). Almacenar los datos de un mismo tipo no significa que se almacenen sólo
datos numéricos, o sólo datos alfanuméricos. Desde el punto de vista conceptual esto significa que
cada entidad se almacena en estructuras separadas. Así, cada entidad, tendrá una estructura (tabla)
pensada y diseñada para ese tipo de entidad. Cada elemento almacenado dentro de la tabla recibe el
nombre de registro, tupla o fila.

Una tabla se compone de campos o columnas, que son conjuntos de datos del mismo tipo (desde
el punto de vista físico). Ahora cuando decimos “del mismo tipo” queremos decir que los datos de una
columna son de todos del mismo tipo: numéricos, alfanuméricos, fechas…
En este modelo, el lugar y la forma en que se almacenen los datos no tienen relevancia (a diferencia
de otros modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil
de entender y de utilizar para un usuario casual de la base de datos. La información puede ser
recuperada o almacenada por medio de consultas que ofrecen una amplia flexibilidad y poder para
administrar la información.

Modelos de datos físicos, lógicos y conceptuales

Los modelos de datos y los modelos ER se dibujan típicamente con hasta tres niveles de detalle:

Modelo de datos conceptuales: La visualización de nivel más alto que contiene la menor cantidad
de detalle. Su valor muestra el alcance global del modelo y representa la arquitectura del sistema. Para
un sistema de menor alcance, quizás no sea necesario dibujarlo. En cambio, se comienza con el modelo
lógico.

Modelo de datos lógicos: Contiene más detalle que un modelo conceptual. Ahora se definen las
entidades transaccionales y operativas más detalladas. El modelo lógico es independiente de la
tecnología en la que se implementará.

Modelo de datos físicos: Uno o más modelos físicos pueden desarrollarse a partir de cada modelo
lógico. El modelo físico debe mostrar los suficientes detalles tecnológicos para producir e implementar
la base de datos en cuestión.

Por lo que debemos tener en cuenta que existen niveles de alcance y de detalle similares en otros
tipos de diagramas, como los diagramas de flujo de datos, pero esto se contrasta con el enfoque de tres
esquemas de la ingeniería de software, que divide la información de forma diferente. En algunas
ocasiones, los ingenieros ramificarán los diagramas ER con jerarquías adicionales con el fin de agregar
los niveles de información necesarios para el diseño de la base de datos. Por ejemplo, pueden agregar
categorías mediante la ampliación hacia arriba con superclases y hacia abajo con subclases.

Por lo que existen muchas técnicas para el diseño y desarrollo de sistemas en la actualidad, sin
embargo, el uso de técnicas de modelado conceptual está siendo una práctica cada vez más común
entre la ingeniera de software, ya que con esta técnica se proporciona una precisa descripción del
dominio del problema, de tal forma que la obtención de modelos a diferentes niveles de abstracción
determine el producto software final.
El Modelado Conceptual consiste en entender y dominar dominio del problema y la
conceptualización del conocimiento que se tiene sobre él, a un nivel abstracto antes de implementar
una solución, permite que los ingenieros de software y los clientes de los sistemas trabajen al mismo
nivel y que, además, exista un entendimiento sobre lo que se tiene que hacer y el producto que se
obtendrá.

Descripción: En este modelo todos los datos son almacenados en relaciones, y como cada relación
es un conjunto de datos, el orden en el que estos se almacenen no tiene relevancia (a diferencia de otros
modelos como el jerárquico y el de red). Esto tiene la considerable ventaja de que es más fácil de
entender y de utilizar por un usuario no experto. La información puede ser recuperada o almacenada
por medio de consultas que ofrecen una amplia flexibilidad y poder para administrar la información.

Este modelo considera la base de datos como una colección de relaciones. De manera simple, una
relación representa una tabla que no es más que un conjunto de filas, cada fila es un conjunto de campos
y cada campo representa un valor que interpretado describe el mundo real. Cada fila también se puede
denominar tupla o registro y a cada columna también se le puede llamar campo o atributo.

Para manipular la información utilizamos un lenguaje relacional, actualmente se cuenta con dos
lenguajes formales el Álgebra relacional y el Cálculo relacional. El Álgebra relacional permite
describir la forma de realizar una consulta, en cambio, el Cálculo relacional solamente indica lo que
se desea devolver.
Esquema: Un esquema contiene la definición de una estructura (generalmente relaciones o tablas
de una base de datos), es decir, determina la identidad de la relación y qué tipo de información podrá
ser almacenada dentro de ella; en otras palabras, el esquema contiene los metadatos de la relación.
Todo esquema constará de:

 Nombre de la relación (su identificador).

 Nombre de los atributos (o campos) de la relación y sus dominios; el dominio de un atributo o
campo define los valores permitidos para el mismo, equivalente al tipo de dato por ejemplo
character, integer, date, string.

Instancias: Una instancia de manera formal es la aplicación de un esquema a un conjunto finito de

datos. En palabras no tan técnicas, se puede definir como el contenido de una tabla en un momento
dado, pero también es válido referirnos a una instancia cuando trabajamos o mostramos únicamente
un subconjunto de la información contenida en una relación o tabla, como, por ejemplo:
 Ciertos caracteres y números (una sola columna de una sola fila).
 Algunas o todas las filas con todas o algunas columnas

 Cada fila es una tupla. El número de filas es llamado cardinalidad.

 El número de columnas es llamado aridad o grado.

Normalización: El proceso de normalización es un proceso de descomposición de los esquemas de

relación hasta que todas las relaciones alcancen la forma normal deseada. En general, interesa:
1. Determinar las llaves candidato (minimales) de cada relación.
2. Determinar la forma normal de la relación.
3. ¿Está en FNBC? Si no, normalizar.
4. ¿La normalización no asegura la preservación de información y dependencias? Conformarse
con 3FN.

Reglas de normalización: El punto de partida del proceso de normalización es un conjunto de tablas

con sus atributos, el denominado esquema relacional. Se pretende mejorar dicho esquema de datos. Se
dice que una tabla está en una determinada forma normal si satisface un cierto número de restricciones
impuestas por la correspondiente regla de normalización. La aplicación de una de estas reglas a un
esquema relacional produce un nuevo esquema relacional en el que no se ha introducido ningún nuevo
atributo. (Hilgado, 2003)

Un esquema relacional se compone de una serie de ternas T (A, D) donde T es el nombre de una tabla,
A el conjunto de los atributos de esa tabla y D, el conjunto de dependencias funcionales que existen
entre esos atributos.

Si una tabla no satisface una determinada regla de normalización, se procede a descomponerla en otras
dos nuevas que sí las satisfagan. Esto usualmente requiere decidir qué atributos de la tabla original van
a residir en una u otra de las nuevas tablas. La descomposición tiene que conservar dos propiedades
fundamentales:
1.No pérdida de información.

Sea T (A, D) que se divide en T1(A1, D1) y T2(A2, D2). A partir de los atributos comunes en ambos
esquemas es posible determinar los atributos de T1 no presentes en T2 (es decir, el conjunto A1 - A2)
o bien los atributos de T2 no presentes en T1 (el conjunto diferencia A2 - A1). Desde cualquier
esquema se consigue recuperar los datos del otro mediante un mecanismo de clave ajena que permite
reconstituir el esquema original de partida. Expresado mediante dependencias funcionales, la
intersección de los conjuntos de atributos A1 y A2 debe determinar funcionalmente la diferencia de
los conjuntos de atributos A1 - A2 o bien A2 - A1.
2.No pérdida de dependencias funcionales.

La normalización consiste pues en descomponer los esquemas relacionales (tablas) en otros

equivalentes (puede obtenerse el original a partir de los otros) de manera que se verifiquen unas
determinadas reglas de normalización. Evidentemente las reglas de normalización imponen una serie
de restricciones en lo relativo a la existencia de determinados esquemas relacionales. Según se avance
en el cumplimiento de reglas y restricciones se alcanzará una mayor forma normal. Existen
cinco formas normales hacia las cuales puede conducir el proceso de normalización de forma
incremental más una forma normal independiente de las otras.

Un esquema relacional que satisface todas las restricciones impuestas por la tercera forma normal se
considera de buena calidad, aunque es mejor que satisfaga una interesante propiedad. La verificación
de una forma normal implica el cumplimiento de todas las formas normales anteriores. La primera
forma normal es de cumplimiento obligatorio para que exista siquiera un esquema relacional
propiamente formado.

El proceso de normalización consiste en aplicar una serie de reglas a las relaciones obtenidas tras el
paso del modelo entidad-relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
 Evitar la redundancia de los datos.
 Disminuir problemas de actualización de los datos en las tablas.
 Proteger la integridad de los datos.
En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea
considerada como una relación tiene que cumplir con algunas restricciones:
 Cada tabla debe tener su nombre único.
 No puede haber dos filas iguales. No se permiten los duplicados.
 Todos los datos en una columna deben ser del mismo tipo.
Formas Normales: Como podemos ver las formas normales son aplicadas a las tablas de una base de
datos. Decir que una base de datos está en la forma normal N es decir que todas sus tablas están en la
forma normal N.

Diagrama de inclusión de todas las formas normales.

En general, las primeras tres formas normales son suficientes para cubrir las necesidades de la mayoría
de las bases de datos.

Primera Forma Normal (1FN)

Artículo principal: Primera forma normal
Una tabla está en primera forma sí.
  Todos los atributos son atómicos. Un atributo es atómico si los elementos del dominio son
simples e indivisibles.
 No debe existir variación en el número de columnas.
 Los campos no clave deben identificarse por la clave (dependencia funcional).
 Debe existir una independencia del orden tanto de las filas como de las columnas; es decir, si
los datos cambian de orden no deben cambiar sus significados.
Esta forma normal elimina los valores repetidos dentro de una base de datos.

Segunda Forma Normal (2FN)

Dependencia funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte
de ninguna clave dependen de forma completa de la clave principal. Es decir, que no existen
dependencias parciales. Todos los atributos que no son clave principal deben depender únicamente de
la clave principal.

En otras palabras, podríamos decir que la segunda forma normal está basada en el concepto de
dependencia completamente funcional. Una dependencia funcional es completamente funcional si al
eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que. Una
dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser eliminados
de X y la dependencia todavía se mantiene, esto es.

Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado y el ID de un

proyecto sabemos cuántas horas de trabajo por semana trabaja un empleado en dicho proyecto) es
completamente funcional dado que ni DNI HORAS_TRABAJO ni
ID_PROYECTO HORAS_TRABAJO mantienen la dependencia. Sin embargo {DNI,
ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente dependiente dado que
DNI NOMBRE_EMPLEADO mantiene la dependencia.

Tercera Forma Normal (3FN)

La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional transitiva entre
los atributos que no son clave.

Un ejemplo de este concepto sería que, una dependencia funcional X->Y en un esquema de relación
R es una dependencia transitiva si hay un conjunto de atributos Z que no es un subconjunto de alguna
clave de R, donde se mantiene X->Z y Z->Y.

Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en EMP_DEPT de la

siguiente figura. Decimos que la dependencia de DMGRSSN el atributo clave SSN es transitiva vía
DNUMBER porque las dependencias SSN→DNUMBER y DNUMBER→DMGRSSN son
mantenidas, y DNUMBER no es un subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos
ver que la dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que
DNUMBER no es una clave de EMP_DEPT.

Formalmente, un esquema de relación está en 3 Forma Normal Elmasri-Navathe, si para toda

dependencia funcional, se cumple al menos una de las siguientes condiciones:
1. Es superllave o clave.
 2. Es atributo primo de; esto es, si es miembro de alguna clave en.
Además, el esquema debe cumplir necesariamente, con las condiciones de segunda forma normal.

Forma Normal de Boyce - Codd

Forma normal de Boyce-Codd (FNBC)

La tabla se encuentra en FNBC si cada determinante, atributo que determina completamente a otro, es
clave candidata. Deberá registrarse de forma anillada ante la presencia de un intervalo seguido de una
formalización perpetua, es decir las variantes creadas, en una tabla no se llegarán a mostrar, si las ya
planificadas, dejan de existir.

Formalmente, un esquema de relación está en FNBC, si y sólo si, para toda dependencia funcional
válida en, se cumple que.
1. Es superllave o clave.

De esta forma, todo esquema que cumple FNBC, está además en 3FN; sin embargo, no todo
esquema que cumple con 3FN, está en FNBC.

Ventajas:
 Garantiza herramientas para evitar la duplicidad de registros, a través de campos claves o
llaves.
 Garantiza la integridad referencial: Así al eliminar un registro elimina todos los registros
relacionados dependientes.
 Favorece la normalización por ser más comprensible y aplicable.
 Provee herramientas que garantizan evitar la duplicidad de registros.
Desventajas:
 Presentan deficiencias con datos gráficos, multimedia y sistemas de información geográfica.
 No se manipulan de forma manejable los bloques de texto como tipo de dato.

Diccionario de Datos:
¿Qué es Diccionario de Datos? En este paquete encontramos todas las clases de la lógica que
interaccionan con el paquete de integración para obtener información almacenada en el diccionario de
datos. Así como los tránsfers (clases de los objetos que viajan entre capas) que contienen los datos
recogidos en la interfaz sobre el diagrama entidad – relación que en cada momento se esté tratando.

Toda la información referente a los esquemas entidad-relación es registrada en un diccionario

de datos transparente para el usuario y común para todos los esquemas creados a través de la aplicación.
La finalidad del diccionario de datos es ver posibles redundancias existentes en el esquema E/R que
se esté creando y alertar de ellas al usuario, por ejemplo: Si en dos entidades diferentes se guarda un
mismo atributo llamado Código Empresa, puede que se esté guardando información dos veces y que
no interese (aunque en algunos casos, a pesar de ser redundante, es lo que al usuario le conviene).
 O si, por ejemplo, se establece una relación entre dos entidades que ya están relacionadas, ha
de avisarse al usuario y asegurarse de que quiere crear esa nueva relación a pesar de que ya haya una.
O alertar si ya existe una relación en esa base de datos con ese nombre. (Iglesias, 2006-2007 )

El diccionario de datos se ha implementado a través de una base de datos y se organiza de la

siguiente manera (las claves están subrayadas y las claves ajenas en cursiva):

 Entidad (nombre, descripción, códigoEnt, códigoEsquema). Información sobre las

diferentes entidades.
 Relación (nombre, descripción, códigoRel, tipo, códigoEsquema). Información sobre
las distintas entidades de los distintos esquemas.
 Atributo (nombre, tipo, códigoAtributo). Guarda los datos de los atributos. Nótese que
no incluye un campo restricciones, ya que de esta forma ahorramos espacio. Por
ejemplo, imaginemos que tuviéramos el atributo “apellido” de tipo “varchar” y
contenido tanto en la entidad “empresario” como “trabajador”, si para empresario
exigimos que tenga una longitud menor que 20 y para trabajador menor que 15, si en la
tabla Atributo incluyéramos el campo restricciones tendríamos que crear dos filas
diferentes; mientras que como lo tenemos implementado sólo se creará una fila en
Atributo y en AtributoEntidad se señalarán los requisitos (lo cual implica sólo una
columna más).
 AtributoEntidad (códigoAtributo, códigoEntidad, clave, restricciones). Relación entre
una entidad y uno de sus atributos. Nótese que toda entidad tiene que estar relacionada
con al menos un atributo.
 Atributo Relación (código Atributo, códigoRelación, clave, restricciones). Relaciona
una relación con uno de sus atributos, en caso de que tenga, indicando si el mismo
pertenece o no a la clave de la misma y las restricciones que se imponen sobre él.

 Entidad Relación (códigoRelación, códigoEntidad, participación, cardinalidad). Refleja

las relaciones entre entidades, para ello cada entidad se relaciona con la entidad que la
une con la otra por separado.

 Relación es un (código, códEntMadre, códEntHija, códigoEsquema). Guarda las

relaciones es uno de los distintos esquemas, indicando quienes son las entidades hijas
y quienes las madres.

 Esquema (nombre, código Esquema). Nos indican los distintos esquemas E/R
plasmados en el diccionario de datos. Dónde: “código Esquema” representa el esquema
al que pertenece una entidad o una relación. “tipo” en una relación indica si es binaria
o ternaria y en un atributo si es varchar, int, Test, etc. “restricciones” hace referencia a
si no se permiten valores nulos (not null), si el valor del atributo tiene que estar dentro
de un rango, etc. “clave” indica si un atributo pertenece a la clave o no de una entidad
o una relación.
 CONCLUSIONES

 En esta actividad hemos aprendido que el modelo relacional no es un paso tan fundamental en
el desarrollo para una base de datos, sin embargo, debe considerarse ya que nos indica el tipo
de relaciones que tenemos, la cardinalidad y el tipo de clave que tiene (principal, foránea o
índice).

 Esta actividad está desarrollada bajo las explicaciones realizadas en las webs conferencias y
las lecturas dejadas en el entorno de conocimiento de tal manera que se ha podido cumplir con
el objetivo propuesto en dicha actividad, dejándonos amplios aprendizajes para nuestra vida
cotidiana.

 El modelo relacional es útil para tener un buen control de los sistemas y de saber aplicar el
modelo entidad-relación, así como la cardinalidad correspondiente a cada tabla. También fue
importante saber aplicar los conceptos aprendidos con anterioridad sobre entidad, atributo y
llave sobre la tabla considerado el atributo clave.

 En cuanto al modelo entidad relación podemos apreciar, como el nombre lo indica, las
entidades y relaciones que estamos utilizando. Pero si queremos llegar un poco más a fondo y
que no haya ninguna duda con respecto a las entidades, atributos y tipos de claves que
ocupamos, no debemos dejar este pasó ya que nos ayuda muchísimo en la comprensión y hace
más amigable la información requerida.
 REFERENCIAS

Hilgado, U. A. (2003). Unidad 4 Diseño de bases de datos. Centro de Innovación para el Desarrollo y la
Capacitación en Materiales Educativos "cidecame". Obtenido de
http://cidecame.uaeh.edu.mx/lcc/mapa/PROYECTO/libro14/42_normalizacin_de_tablas_relacionale
s.html

Iglesias, J. A. (2006-2007 ). Generador del Modelo Relacional y Esquemas. Obtenido de

https://eprints.ucm.es/9037/1/Generador_del_Modelo_Relacional_y_Esquemas_de_Bases_de_Dat
os.pdf

Inc., L. S. (2017). Qué es un diagrama entidad-relación. Obtenido de

https://www.lucidchart.com/pages/es/que-es-un-diagrama-entidad-relacion