BASES DE DATOS

CÓDIGO: 301330A

Unidad 2: Fase 3 - Diseño

Presentado a:
IVAN ARTURO LOPEZ ORTIZ
(Tutor)

Entregado por:

XIMENA ZORANY POSSO PINCHAO

Código: 1033788287

JEIMY TATIANA PEREZ

Código:

ANDRES CAMILO TAUTIVA VARGAS

Código: 1.016.107.393

Grupo: 301330_14

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA - UNAD

ESCUELA DE CIENCIAS BÁSICAS TECNOLOGÍA E INGENIERÍA
11 DE ABRIL DE 2019
BOGOTÁ D.C
 UNIDAD 2: FASE 3 - DISEÑO

Modelo relacional
Es una colección de tablas. Consistente en el almacenamiento de datos en tablas compuestas
por filas, o tuplas, y columnas o campos. Se distingue de otros modelos, como el jerárquico,
por ser más comprensible para el usuario inexperto, y por basarse en la lógica de predicados
para establecer relaciones entre distintos datos.

Base Teórica y conceptual

Tablas: El modelo relacional proporciona una manera simple de representar los datos: una
tabla bidimensional llamada relación.
Ejemplo:
A partir de la siguiente tabla, se tomará como ejemplo la descripción en cuanto a modelo
relacional

Relación Películas
La relación Películas tiene la intención de manejar la información de las instancias en la
entidad Películas, cada renglón corresponde a una entidad película y cada columna
corresponde a uno de los atributos de la entidad. Sin embargo, las relaciones pueden
representar más que entidades
Atributos: son las columnas de una relación y describen características particulares de ella.
Esquemas: Es el nombre que se le da a una relación y el conjunto de atributos en ella.
Ejemplo:
Películas (título, año, duración, tipo)
En un modelo relación, un diseño consiste de uno o más esquemas, a este conjunto se le
conoce como "esquema relacional de base de datos" (relational database schema) o
simplemente "esquema de base de datos" (database schema)
Conversión del modelo e-r a un esquema de base de datos (Conversión a tablas)
El modelo es una representación visual que gráficamente nos da una perspectiva de cómo se
encuentran los datos involucrados en un proyecto u organización.
Pero el modelo no nos presenta propiamente una instancia de los datos, un ejemplo que
muestre con claridad algunos datos de muestra y como se relacionan en realidad. Por eso es
conveniente crear un "esquema", el cual consiste de tablas las cuales en sus renglones (tuplas)
contienen instancias de los datos.
Conversión a tablas desde un modelo con relaciones (1-1, 1-m, m-m)
Las tablas siguientes muestran las reglas que se deben seguir para poder crear dicho esquema.

modelo e-r conversión a tablas

 una tabla por cada conjunto de entidades

o nombre de tabla = nombre de conjunto de entidades
 una tabla por cada conjunto de relaciones m-m
o nombre de tabla = nombre de conjunto de relaciones
 definición de columnas para cada tabla
o conjuntos fuertes de entidades
 columnas = nombre de atributos
o conjuntos débiles de entidades
 columnas = llave_primaria (dominante) U atributos(subordinado)
o conjunto de relaciones R (m-m) entre A, B
 columnas (R) = llave_primaria (A) U llave_primaria (B) U atributos(R)
o conjunto de relaciones R (1-1) entre A y B
 columnas (A) = atribs(A) U llave primaria(B) U atributos(R)
o conjunto de relaciones R (1-m) entre A y B
 columnas (B) = atribs(B) U llave primaria(A) U atributos(R)
El diagrama anterior se convertiría al siguiente esquema:

donde:
LLP_X es la llave primaria de la entidad X (un subconjunto de atribs_X)
Ejemplo:

De acuerdo al diagrama anterior, se tendría el esquema:

Tuplas:
Cada uno de los renglones en una relación conteniendo valores para cada uno de los atributos.
Ejemplo:
(Star Wars, 1977, 124, color)
Dominios: Se debe considerar que cada atributo (columna) debe ser atómico, es decir, que
no sea divisible, no se puede pensar en un atributo como un "registro" o "estructura" de datos.
Representaciones equivalentes de una relación
Las relaciones son un conjunto de tuplas, no una lista de tuplas. El orden en que aparecen las
tuplas es irrelevante. Así mismo el orden de los atributos tampoco es relevante, como se
muestra en la siguiente tabla:

Instancia de la relación: Colección de instancias de relaciones que verifican las

restricciones de integridad. El conjunto de tuplas{(x1,x2,..,xn)} ⊆ D1×D2×..×Dn que la
componen en cada momento.
• Técnica de normalización
La normalización es la transformación de las vistas de usuario complejas y del almacén de
datos a un juego de estructuras de datos más pequeñas y estables. Además de ser más simples
y estables, las estructuras de datos son más fáciles de mantener que otras estructuras de datos.
(Kendall, 2005)
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.
Para que las tablas de nuestra BD estén normalizadas deben cumplir las siguientes reglas:
 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.

Existen 3 niveles de normalización que deben respetarse para poder decir que nuestra BDs,
se encuentra NORMALIZADA, es decir, que cumple con los requisitos naturales para
funcionar óptimamente y no perjudicar el rendimiento por mala arquitectura.
• Formas normales
De acuerdo al siguiente ejemplo, se explicarán las 3 formas normales de una base de datos
Existen dos alumnos que cursarán ambas materias: Juanito en maestría y Pepito en
licenciatura, nuestro modelo de datos podría quedar de la siguiente manera:
Sin Normalizar:
Alumnos

En la tabla anterior, se tienen los registros de ambos estudiantes con ambas materias
asignadas, pero esto es poco funcional, imaginemos que cada estudiante tuviera más materias
en su horario, eso significaría, agregarle más columnas a cada alumno, lo que no es muy
óptimo.

Primera Forma Normal:

NO repetir campos en las tablas (atributos atómicos).
Alumnos

Al aplicar la primera forma normal, se genera un identificado para cada alumno y un registro
por materia asignada, se duplica información, sin embargo, se ha conservado la integridad de
las columnas de la información lo que es más óptimo que el modelo anterior, sin embargo,
se puede mejorar con la segunda forma normal.
Segunda Forma Normal:
Se debe aplicar la 1FN. Cada campo de la tabla debe depender de una clave única, si se
tuviera alguna columna que se repite a lo largo de todos los registros, dichos datos deberían
atomizarse en una nueva tabla.

Materias

Al aplicar la segunda forma normal, se evita la duplicación de registros y se separa la

información de los alumnos de la relación que guardan con las materias generando una
segunda tabla, sin embargo, dicha tabla puede mejorarse con la tercera forma normal o su
versión mejorada la forma de Boyce-Codd.
Tercera Forma Normal:
Se debe aplicar la 1FN y 2FN. Los campos que NO son clave NO deben tener
dependencias.

Forma Normal Boyce-Codd (FNBC):

Se debe aplicar la 1FN, 2FN y 3FN. Es una versión mejorada de la 3FN. Los campos que NO
son clave NO deben tener dependencias. Los campos que NO dependan de la clave se deben
eliminar.
Alumnos

Estudios

Materias

Con la ayuda de la tercera forma y la Boyce-Codd, se logra obtener la información de los

planes de estudio de la información principal de los alumnos, lo que asegura una mejor
integridad de los datos, permitiendo que el número de estudios crezcan y que los estudiantes
puedan matricularse a más de un estudio sin tener que desordenar el modelo de datos.
Cuarta Forma Normal:
Se debe aplicar la FNBC. La 4FN aplica únicamente para relaciones M a M, y esto ayuda a
eliminar la redundancia de información generada por dicho tipo de relación.
Alumnos

Estudios

Materias

Materias x alumno

Con la cuarta forma se ha logrado separar la relación que guardan los alumnos con sus
respectivas materias asignadas, separándolas en un catálogo independiente de materias, y
guardando la relación entre alumnos y materias en otra tabla pivote que sólo guarde la
relación entre ambas entidades con un registro único.
Quinta Forma Normal:
Se debe aplicar la 1FN, 2FN, 3FN y 4FN. Existe otro nivel de normalización que se aplica
con poca frecuencia y en la mayoría de los casos no es necesario, para obtener la mejor
funcionalidad de la estructura de datos. Su principio sugiere:
 La tabla original debe ser reconstruida desde las tablas resultantes en las cuales ha sido
partida.
 Los beneficios de aplicar la 5FN asegura que no se haya creado ninguna columna extraña
en las tablas y que su estructura sea del tamaño justo que tiene que ser.
 Es una buena práctica aplicar la 5FN, cuando tenemos una extensa y compleja estructura
de datos, en modelos pequeños no se recomienda usar.
 En síntesis, la quinta forma, en modelos muy grandes donde se tienen muchas relaciones
y entidades, sugiere que una vez se haya terminado la normalización del modelo, se debe
volver a revisar en busca de posibles errores de lógica en la normalización.

• Ventajas
• Desventajas
• Diccionario de Datos:
Es una lista de todos los elementos incluido en el conjunto de los diagramas de flujo de
datos que describen un sistema.
Su objetivo es dar precisión sobre los datos que se manejan en un sistema, evitando así
malas interpretaciones o ambigüedades.
Define con precisión los datos de entrada, salida, componentes de almacenes, flujos,
detalles de las relaciones entre almacenes, etc.
El diccionario de datos guarda y organiza los detalles del Diagrama de Flujo de Datos
(DFD).
 JEIMY TATIANA PEREZ

Describa la transformación de entidades en tablas.

Para ello se requiere que extraigamos del problema o necesidad central, los objetos que deben
interactuar ahí; así mismo, se justifica su existencia dentro del mundo del problema para que se
logre ver realmente si es necesario que se tenga dicha entidad o si se puede reorganizar dentro de
la base.

 Describa la transformación de atributos en columnas.

Las entidades pueden tener uno o más atributos. Los atributos son las características que pueden
tener esos elementos o entidades; como por ejemplo, para la entidad “Libros” podríamos tener los
atributos de el año de publicación, el tema, el nombre, la editorial, entre otros.

Cada atributo se transforma en una columna a la que se justifica su existencia con la entidad a la
que esta relacionada. Hay muchos tipos de atributos y pueden llegar a cumplir roles más o menos
importantes según la designación, así mismo tienen un identificador único.

 Describa como agregar a cada tabla un identificador único (UID) o Primary Key.
Como se comentó en el punto de atributos, cada uno cuenta con un identificador único y es
además el que permite hacer diferentes operaciones para las aplicaciones que usan las bases de
datos. Adicional la Primary key es un atributo que generalmente nos permite generar las
relaciones entre tablas, cada tabla generalmente cuenta con una Primary key por tabla.

 Describa la transformación de las relaciones 1:1 o 1:m en llaves foráneas,

implementando el concepto de la integridad referencial.

Para llevar esto, primero es necesario desarrollar la matriz de relaciones, con esto determinamos a
las entidades y su tipo de relacionamiento con otras entidades

 Describa la aplicación de las técnicas de normalización al modelo relacional.

Básicamente lo que busca la normalización es aplicar reglas a las relaciones obtenidos entre el
modelo entidad – relación y el modelo relacional.

Esto se realiza con el propósito de evitar la redundancia en los datos de la bd, primer los pilares de
la seguridad de la información y disminuir el riesgo de actualización en las tablas.

Primera forma normal

 Elimine los grupos repetidos de las tablas individuales.

 Cree una tabla independiente para cada conjunto de datos relacionados.
 Identifique cada conjunto de datos relacionados con una clave principal.
No use varios campos en una sola tabla para almacenar datos similares. Por ejemplo, para realizar
el seguimiento de un elemento del inventario que proviene de dos orígenes posibles, un registro del
inventario puede contener campos para el Código de proveedor 1 y para el Código de proveedor 2.
¿Qué ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la respuesta, requiere
modificaciones en las tablas y el programa, y no admite fácilmente un número variable de
proveedores. En su lugar, coloque toda la información de los proveedores en una tabla
independiente denominada Proveedores y después vincule el inventario a los proveedores con el
número de elemento como clave, o los proveedores al inventario con el código de proveedor como
clave.

Segunda forma normal

Cree tablas independientes para conjuntos de valores que se apliquen a varios registros.

Relacione estas tablas con una clave externa.

Los registros no deben depender de nada que no sea una clave principal de una tabla, una clave
compuesta si es necesario. Por ejemplo, considere la dirección de un cliente en un sistema de
contabilidad. La dirección se necesita en la tabla Clientes, pero también en las tablas Pedidos, Envíos,
Facturas, Cuentas por cobrar y Colecciones. En lugar de almacenar la dirección de un cliente como
una entrada independiente en cada una de estas tablas, almacénela en un lugar, ya sea en la tabla
Clientes o en una tabla Direcciones independiente.

Tercera forma normal

Elimine los campos que no dependan de la clave.

Los valores de un registro que no sean parte de la clave de ese registro no pertenecen a la tabla. En
general, siempre que el contenido de un grupo de campos pueda aplicarse a más de un único
registro de la tabla, considere colocar estos campos en una tabla independiente.

Por ejemplo, en una tabla Contratación de empleados, puede incluirse el nombre de la universidad
y la dirección de un candidato. Pero necesita una lista completa de universidades para enviar
mensajes de correo electrónico en grupo. Si la información de las universidades se almacena en la
tabla Candidatos, no hay forma de enumerar las universidades que no tengan candidatos en ese
momento. Cree una tabla Universidades independiente y vincúlela a la tabla Candidatos con el
código de universidad como clave.

EXCEPCIÓN: cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico.
Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe
crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de
clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la
normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden
degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos.

 Describa el proceso de construcción y diseñe el diccionario de datos del modelo

relacional.
 ANDRES CAMILO TAUTIVA VARGAS

Describa la transformación de entidades en tablas

 Para pasar a tablas todos los datos sin dejarnos nada y que las tablas tengan
sentido por si solas tenemos que seguir unos pasos:

Toda entidad se transforma en una tabla

todo atributo se transforma en una columna dentro de la tabla a la que
pertenece
El identificador de la entidad se convierte en la clave primaria de la
tabla
Toda relación N:M se convierte en una tabla que tendrá como clave
primaria las dos claves primarias de las entidades que se asocian
En las relaciones 1:N la clave primaria de la entidad con cardinalidad
1 pasa a la tabla de la entidad cuya cardinalidad es N
en las relaciones N: M existen tres posibilidades: Si la cardinalidad es
(0,1) en ambas entidades, se crea tabla. Mientras que si la
cardinalidad de una es (0,1) y de la otra es (1,1) se suele pasar la
clave primaria de (1,1) a la de (0,1). Si la cardinalidad de ambas es
(1,1) se pasa la clave de cualquiera de ellas a la otra.

 Para este modelo de entidad-relación el paso a tablas quedaría de la

siguiente forma

Describa la transformación de atributos en columnas.

 Primero encontramos los atributos en relación.
Atributos Simples o Compuestos

Atributos Mono valuados o Multivaluados

Atributos almacenados y derivados

Atributos Clave

Cardinalidad
Describa como agregar a cada tabla un identificador único (UID) o primary key.

 En el diseño de base de datos una compound key es una llave que consiste
en dos o más atributos que identifican unívocamente la ocurrencia de una
entidad. Una simple key en oposición a la compound key es una llave que
tiene solo un atributo. Las compound keys pueden estar compuestas por
otras unique simple keys y por atributos non-key, pero no pueden incluir otra
compound key.

Las primary key, secondary key y foreign key pueden componerse de más
de un campo. Una simple key consiste en un único campo como identificador
único del registro.

Una compound key se distingue de una composite key porque cada campo
es una clave primaria.

Una composite key contiene al menos una compound key y uno o más
atributos. Las composite keys también pueden incluir simple keys y atributos
non-key.

Un ejemplo puede ser una entidad que representa los estudiantes por modulo
en una Universidad. La entidad tiene un identificador de estudiante y un
código de modulo como llave primaría. Cada uno de los atributos con que se
constituyen la llave primaria son simple keys porque representan una
referencia única cuando se identifica a una estudiante en un módulo.

Describa la transformación de las relaciones 1:1 o 1: m en llaves foráneas,

implementando el concepto de la integridad referencial.

 El modelo de datos más extendido es el denominado ENTIDAD/RELACIÓN

(E/R) En el modelo E/R se parte de una situación real a partir de la cual se
definen entidades y relaciones entre dichas entidades:

Entidad.- Objeto del mundo real sobre el que queremos almacenar información (Ej:
una persona). Las entidades están compuestas de atributos que son los datos que
definen el objeto (para la entidad persona serían DNI, nombre, apellidos,
dirección,...). De entre los atributos habrá uno o un conjunto de ellos que no se
repite; a este atributo o conjunto de atributos se le llama clave de la entidad, (para
la entidad persona una clave seria DNI). En toda entidad siempre hay al menos una
clave que en el peor de los casos estará formada por todos los atributos de la tabla.
Ya que puede haber varias claves y necesitamos elegir una, lo haremos atendiendo
a estas normas:

 Que sea única.

 Que se tenga pleno conocimiento de ella.- ¿Por qué en las empresas se
asigna a cada cliente un número de cliente?
 Que sea mínima, ya que será muy utilizada por el gestor de base de datos.

Relación.- Asociación entre entidades, sin existencia propia en el mundo real que
estamos modelando, pero necesaria para reflejar las interacciones existentes entre
entidades. Las relaciones pueden ser de tres tipos:

 Relaciones 1-1.- Las entidades que intervienen en la relación se asocian una

a una (Ej: la entidad HOMBRE, la entidad MUJER y entre ellos la relación
MATRIMONIO).
 Relaciones 1-n.- Una ocurrencia de una entidad está asociada con muchas
(n) de otra (Ej: la entidad EMPERSA, la entidad TRABAJADOR y entre ellos
la relación TRABAJAR-EN).
 Relaciones n-n.-Cada ocurrencia, en cualquiera de las dos entidades de la
relación, puede estar asociada con muchas (n) de la otra y viceversa (Ej: la
entidad ALUMNO, la entidad EMPRESA y entre ellos la relación
MATRÍCULA).

Describa la aplicación de las técnicas de normalización al modelo Relacional.

 Las bases de datos son parte esencial de cualquier sistema informático,
puesto que todos los programas necesitan recurrir a diversos datos mientras
se ejecutan o generan otros que se han de almacenar de forma fiable, sin
contradicciones y a largo plazo. Esto es posible en bases de datos (BD)
estructuradas y gestionadas por sistemas de gestión de bases de datos
(SGBD), aplicaciones de software que interactúan con el usuario o con otros
programas para poner a su disposición un segmento de la información
guardada en la base de datos.

Hasta hoy la gestión electrónica de datos ha estado dominada por el modelo de

base de datos relacional. Entre los gestores de bases de datos relacionales más
utilizados se cuentan, por orden alfabético:
  Db2: con Db2 los usuarios disponen de un SGBD relacional propietario de
la casa IBM.

 Microsoft SQL Server: la aplicación de Microsoft para gestionar bases de

datos relacionales está disponible con una licencia Microsoft de pago.

 MySQL: MySQL es el SGBD de código abierto más utilizado a nivel global.

Desde que pasa a las manos de Oracle, MySQL se distribuye con una
licencia dual. Sus primeros desarrolladores siguen encargándose del
proyecto, ahora bajo el nombre de MariaDB.

 PostgreSQL: con PostgreSQL los usuarios disponen de un SGBD relacional

libre y orientado a objetos de cuyo continuo desarrollo se ocupa su
comunidad open source.

 Oracle Database: el programa de Oracle se distribuye como software

propietario.

 SQLite: por último, SQLite constituye una biblioteca de programas con

licencia de dominio público que contiene un gestor de bases de datos
relacionales.

Describa el proceso de construcción y Diseñe el diccionario de Datos del modelo

Relacional.


 WEBGRAFÍA

Logicalis. Conceptos básicos del modelo relacional. 2015.

https://blog.es.logicalis.com/analytics/conceptos-basicos-del-modelo-relacional-en-la-
gestion-de-bases-de-datos
Carlos. Modelo relacional. 2019. http://ict.udlap.mx/people/carlos/is341/bases03.html
Universidad de Granada. Departamento de ciencias de la computación. 2019.
https://elvex.ugr.es/idbis/db/docs/intro/D%20Modelo%20relacional.pdf
https://programas.cuaed.unam.mx/repositorio/moodle/pluginfile.php/872/mod_resource/co
ntent/1/contenido/index.html
Coronel, C., Morris, S. y Rob, P. Bases de datos. Diseño, implementación y administración.
(J. H. Romo, trad.). México: Cengage Learning. 2011
Coronel, C. y Rob, P. 2003. Sistemas de bases de datos. Diseño, implementación y
administración. México: Thomson.
Kendall, K. E. y Kendall, J. E. Análisis y diseño de sistemas. México: Prentice Hall. 2005.
Jonathan MirCha. Normalización de Bases de Datos. 2017.
https://ed.team/blog/normalizacion-de-bases-de-datos
tproduccionmultimedia. 2019. https://tproduccionmultimedia.wordpress.com/diccionario-
de-datos/
Diana Gabriela Higuera Robles. Base de Datos 2. 2019.
http://katyygaby.blogspot.com/p/diccionario-de-datos.html