Unidad 2: Fase 3 – Diseño-Normalización

Presentado por:
Mario Fernando Pantoja Revelo
Código: 1085304083
Grupo: 25

Presentado a:
Iván Arturo López

Base de Datos Básico

Universidad Nacional Abierta a distancia (UNAD) Escuela de Ciencias Básicas
Tecnología e Ingeniería
11 de abril del 2019
 Luego el estudiante debe abstraer del modelo Entidad Relación generado en la Fase 2 la
información que le permita construir los siguientes puntos:

 Descripción de la transformación de entidades en tablas

 Descripción dela transformación de atributos en columnas
 Descripción decomo agregar a cada tabla un identificador único (UID) o primary
key.
 Descripción dela transformaciónde las relaciones 1:1 o 1:m en llaves foráneas,
implementando el concepto de la integridad referencial.
 Descripción dela aplicación de las técnicas de normalización al modelo
Relacional.
 Describa el proceso de construcción y Diseñe el diccionario de Datos del modelo
Relacional.
 Diseño el Modelo Relacional funcional en la software SQL Developer Data
Modeler.

Desarrollo

Tomando como ejemplo la entidad libro fue necesario abrir primeramente la tabla por
su atributo llamado Editorial. Agregado así nuevas tablas llamadas Libro Editora y
Editores con el objetivo de tener un solo código para cada editor. En su relación
decimos que un libro puede tener muchos editores y muchos editores puede aplicar en
un libro entonces es una relación de n:n por esta razón fue necesario abrir la entidad.

Cod_Libro Titulo Editora Edicion AñoPublic Autores

2250 Bases de Datos Basico Akal Primera 2000 Miguel,Y. Juan,P.
2280 El Poder del Ahora Alianza Primera 1998 Maria,E.
2290 Bases de Datos Avanzado Akal Segunda 2003 Efrain,Z. Gustabo.A

Libro_Editora Editores
Cod_Libro Id_Editorial Id_Editorial Nombre_Editorial
2250 1112 1112 Akal
2280 1115 1115 Alianza
2290 1112 1112 Akal
Como vemos tenemos dos nueva tablas llamadas editores y libro editores ahora
debemos unirlas con nuestro usuario y además agregamos un identificador único para
estas tablas. veamos.

Ed_Unico Libro_Editora Editores

Id_Editorial_U Id_Usuario Cod_Libro Id_Editorial Cod_Libro Id_Editorial Id_Editorial Nombre_Editorial
1 1010 2250 1112 2250 1112 1112 Akal
2280 1115 1115 Alianza
2 2211 2280 1115 2290 1112 1112 Akal
3 1020 2290 1112

Y de esta forma ya no necesitamos nuestra columna original editores.

De igual forma fue necesario abrir la entidad libro por su atributo llamado Autores.
Agregado así nuevas tablas llamadas Libro autores y autores con sus atributos
presentados en las siguientes tablas. en su relación también podemos decir que un libro
tiene uno o varios autores y un autor puede crear muchos libros entonces tenemos una
relación de n:n y por esta razón también fue necesario abrir la entidad.

Libro_Autores Autores
Cod_Libro Id_Autor Id_Autores Autores
2250 122 122 Miguel Yela
2250 138 138 Juan P
2288 149 149 Maria E
2290 157 157 Efrain Z
2290 161 161 Gustabo A

Ahora ya no necesitamos el atributo de la tabla original llamado Autores.

Debemos unir nuestro usuario con el código de libro y los autores, de igual forma
debemos agregar nuestro identificador único o llave primary Key. Veamos.

Libro_Autores
Libro_Autores Autores
Id_A_Unico Cod_Libro Id_Usuario Id_Autor Cod_Libro Id_Autor Id_Autores Autores
1 2250 1010 122 2250 122 122 Miguel Yela
2 2250 2211 138 2250 138 138 Juan P
3 2288 1020 149 2288 149 149 Maria E
4 2290 3030 157 2290 157 157 Efrain Z
5 2290 3029 161 2290 161 161 Gustabo A
1
ENTIDAD PROFESOR

La entidad profesor se convierte en dos tablas llamadas Profesor_Tituacion y Titulación

Entidad Original

Profesor
Id_Profesor Titulación
1010 Ingeniero Sistemas
1010 Ingeniero Electronico
1010 Especializacion Informatica
1020 Ingeniero Sistemas
1020 Ingeniero Electronico

Transformación en dos nueva Tablas, los atributos que se agregan y se convierten en

columnas son: id Titulación, Nombre de Titulación para lograrse unir con la entidad
Porfesor-Titulacion la cual contiene sus columnas o atributos llamados Id Profesor e Id
Titulación

Profesor_Titulación Titulación
Id_Profesor Id_Titulación Id_Titulación Nombre_Titulación
1010 1122 1122 Ingeniería Sistemas
1010 1123 1123 Ingeniería Electronica
1010 1124 1124 Especialización Informatica
1020 1122 1125 Ingeniería Ambiental
1020 1123 1126 Psicología

El identificador único o llave primary key fue agregado a la tabla Profesor-Titulación

logrando así conectar esta con las entidades que se requiere. Este fue llamado
Id_Prof_Tit.

Profesor_Titulación
Id_Prof_Tit Id_Profesor Id_Titulación
1 1010 1122
2 1010 1123
3 1010 1124
4 1020 1122
5 1020 1123

Identificación de relaciones, fue necesario abrir la tabla Profesor debido a que cuenta
con su atributo titulación.
De este modo ya podemos decir que un profesor puede tener muchas titulaciones y una
titulación es aplicada a muchos profesores entonces tenemos una relación de n.n.

Aplicando las técnicas de normalización la tabla profesor fue remplazada por las dos
tablas llamadas profesor_Titulacion y Titulación Agregando sus identificadores.
Quedando como final de la tabla profesor
Titulación
lo siguiente. Id_Titulación Nombre_Titulación
1122 Ingeniería Sistemas
Profesor_Titulación 1123 Ingeniería Electronica
Id_Profesor Id_Titulación 1124 Especialización Informatica
1010 1122 1125 Ingeniería Ambiental
1010 1123 1126 Psicología
1010 1124
1020 1122
1020 1123

ENTIDAD ALUMNO

Alumno
Id_Alumno Nmatricula
2011 4875
2011 4875
2011 4875
2012 2562
2012 2562

Esta entidad no es necesario normalizarla ya que un alumno si tiene una sola matricula y
un número de matrícula es aplicada a un solo estudiante por lo tanto en esta tabla solo se
agrega un identificador único o Primary Key el cual se lo llamo Id_Alum_Nmat.

Al final queda nuestra tabla o entidad con su nombre Id_Alumno_Nmatricula, y cuenta

con sus columnas o atributos llamados Id_Alum_Nmat, Id_Alumno, Nmatricula.

En su relación decimos que un alumno puede tener una sola matricula y un número de
matrícula es aplicado a un solo estudiante por lo tanto es una relación de 1:1.

Id_Alumno_Nmatricula
Id_Alum_Nmat Id_Alumno Nmatricula
1 2011 4875
2 2011 4875
3 2011 4875
4 2012 2562
5 2012 2562
ENTIDAD EJEMPLAR

Ejemplar
Nombre_E Estado
Base datos Bueno
Poder ahora Malo
Base datos A Regular

Como vemos esta tabla ya se encuentra normalizada, en su relación decimos que un

nombre de libro solo puede tener un estado y un estado es aplicado a un solo libro por lo
tanto es una relación de 1:1 .

En esta tabla solo fue necesario agregar un identificador único o llave Primary Key,
quedando esta tabla con el nombre N_Ejemplar_Estado y sus atributos Id_Ejm_Estado
Nombre_E y Estado. . Veamos .

N_Ejemplar_Estado
Id_Ejm_Estado Nombre_E Estado
1 Base datos Bueno
2 Poder ahora Malo
3 Base datos A Regular

ENTIDAD ORIGINAL CONVERTIDA EN TABLA LLAMADA PRESTAMOS.

Prestamo
FechaP FehcaPrevD Estado
6/4/2019 6/5/2019 Bueno
7/4/2019 7/5/2019 Bueno
8/4/2019 8/5/2019 Regular

Esta tabla como vemos no se necesita una normalización, ya se encuentra normalizada,

entonces en su relación decimos que un libro que se presta es llevado en una sola fecha
específica de igual forma solo tendrá una sola fecha prevista de devolución.

Por lo tanto, decimos que es una relación de 1.1

En esta tabla fue necesario agregar un identificador único o llave Primary Key llamado
id_Prestamo, sin embargo es necesario agregar el id del usuario para saber a quién le
emprestamos ese ejemplar o libro, entonces nuestra tabla quedo con el nombre Id-
Prestamo-Id Usuario y con sus at ributos Id_Prestamo Id_Usuario FechaP FehcaPrevD
Estado, Veamos.
 Id-Prestamo-Id Usuario
Id_Prestamo Id_Usuario FechaP FehcaPrevD Estado
1 1010 6/4/2019 6/5/2019 Bueno
2 2211 7/4/2019 7/5/2019 Bueno
3 1020 8/4/2019 8/5/2019 Regular

ENTIDAD ORIGINAL PASADA A TABLA CON SU NOMBRE DEVOLUCIÓN

Devolucion
Id_Usuario Fecha-D Estado
1010 6/5/2019 Bueno
2211 7/5/2019 Bueno
1020 8/5/2019 Regular

Esta tabla como vemos no se necesita una normalización, ya se encuentra normalizada,

entonces en su relación decimos que un libro que se presta es devuelto en una sola fecha
específica al igual que su estado el libro va hacer devuelto en un solo estado, por lo
tanto, esta es una relación de 1:1.

Fue necesario agregar una llave parmary llamada id-devolucion. Y agregamos como
atributo un id del prestamos el di y la fecha en que se devuelve. Quedando nuestra
entidad devolución trasformada y normalizada en una tabla llamada devolución con sus
atributos Id_Debolucion Id_Prestamo Id_Usuario Fecha_D Estado.

Devolucion
Id_Debolucion Id_Prestamo Id_Usuario Fecha_D Estado
1 5 1110 6/5/2019 Bueno
2 2 1020 7/5/2019 Bueno
3 14 2020 8/5/2019 Regular

Sin embargo, para realizar una buena relación en cuanto al préstamo y devolución de los
ejemplares es necesarios crear nuevas tablas. veamos.

Ejemplar_Prestamo
Id_Ejem_Pres Id_Ejemplar Id_Prestamo
1111 122 8
1112 123 20
1113 124 34

Ejemplar_Prestamo_Dev
Id_Prest_Dev Id_Ejep_Pres Id_Devolucion
5552 20 1
5558 32 2
5557 42 3
Como vemos se crearon nuevas tablas, estas con el fin de lograr relacionarlas con el
prestamos de los ejemplares y con las devoluciones., de igual forma el préstamo debe
estar relacionado con el usuario.

ENTIDAD ORIGINAL PASADA A TABLA LLAMADA USUARIO

Id_Usuario Nombre Rol Direccion Email Ncelular

1020 Miguel Armando Yela QuenguanEstudiante Providencia Calle 16 No. 23 yelamiguel527@gmail.com.
- 57 3207291289
2020 Efrain Arturo Gomez Bolaños Profesor Bogota Calle 20 No. 35 - 58 Arturo75@hotmail.com 3148568957
2030 Maria Elena Lopez Perez Estudiante Pasto Calle 2 No. 10 - 59 Maria@gmail.co 3002562558

Para esta tabla es necesario normalizar los atributos como son la dirección y el número
de celular, decimo que un usuario puede 1 o muchos números de celular

Normalizamos primeramente la columna Nombres, como vemos hay demasiado dato en

esta columna lo cual no es una práctica de normalización por ello realizamos una
separación de cada nombre. Veamos.

Id_Usuario Rol Id_Usuario 1Nombre 2Nombre 1Apellido 2Apellido

1020 Estudiante 1020 Miguel Armando Yela Quenguan
2020 Profesor 2020 Efrain Arturo Gomez Bolaños
2030 Estudiante 2030 Maria Elena Lopez Perez

Como vemos ahora ya tenemos nuestra tabla un poco más ordenada, pero sin embargo
nos queda faltando la dirección y numero de celular por lo cual se hace necesario abrir
esa entidad, sacamos nueva entidad para identificar plenamente la dirección del usuario.
Veamos.

Departamento Municipio
Id_Depart Nombre_Departamento Id_Municipio Nomre_Municipio
52 Nariño 565 Providencia
11 Bogota 008 Chapinero
52 Nariño 001 Pasto

Barrio Calle
Id_Barrio Nombre_Barrio Num.Calle N_Calle
252 Las Lajas 57 Americas manzana 2
056 Bolibar 59 manzana 8
526 Pasto 592 76

Como vemos tenernos nuevas tablas las cuales las relacionaremos con usuario y al
mismo tiempo estas serán relacionada de acuerdo a su tipo.
Entonces ya tenemos un id o llave Primary key para cada entidad o tabla, ahora la
relacionamos con nuestra tabla usuarios veamos.

Usuario Normalizado Usuario_Direccion

Id_Usuario Rol 1Nombre 2Nombre 1Apellido 2Apellido Id_Depart Id_Municipio Id_Barrio N.Calles
1020 Estudiante Miguel Armando Yela Quenguan 52 565 252 5
2020 Profesor Efrain Arturo Gomez Bolaños 11 008 056 25
2030 Estudiante Maria Elena Lopez Perez 52 001 526 54

Hasta ahí ya tenemos todo bien, pero si regresamos a mirar nuestra tabla original usuario,
vemos que tenemos una tabla llamada celular, la cual es necesario realziar una nromalizacion.

Ahora nos queda pendiente la columna celular, en donde realizamos el mimo

procedimiento que se hizo con la columna dirección. Veamos.

OPeradoNumCEL Celular_Pais
identificador_NumId_Operador Nombre-operN_Celular Id_Pais Pais
5 111 Claro 5256841 059 Ecuador
56 222 Movistar 7598545 592 Peru
333 Tigo 548952 057 Colombia

Tenemos dos nuevas tablas, ahora las debemos y como vemos cada una tiene su llave
única o Primary Key la cual debe ser obligatoria.

Ahora solo nos queda citar cada id o identificador único en nuestra tabla usuarios.
Veamos cómo nos queda.
Usuario Normalizado Usuario_Direccion Celular
Id_Usuario Rol 1Nombre 2Nombre 1Apellido 2Apellido Id_Depart Id_Municipio Id_Barrio N.Calles Id_Cel_Pais Identi-NumCel
1020 Estudiante Miguel Armando Yela Quenguan 52 565 252 5 57 3207589568
2020 Profesor Efrain Arturo Gomez Bolaños 11 008 056 25 592 314865895
2030 Estudiante Maria Elena Lopez Perez 52 001 526 54 458 455412587
DISEÑO EL MODELO RELACIONAL FUNCIONAL EN LA SOFTWARE SQL
DEVELOPER DATA MODELER
 Referencias

Sosa, F. M. & López, V. M. (2007). Diseño de bases de datos relacionales. Córdoba,

AR: El Cid Editor. Pág. 20-85

Chicano, T. E. (2013). Utilización de las bases de datos relacionales en el sistema de

gestión y almacenamiento de datos: uf0348. IC Editorial, 2013. ProQuest Ebook
Central, pág. 87-110.

Köhler H. A, & Link. S. (2018) SQL schema design: foundations, normal forms, and
normalization Information Systems. Auckland, New Zealand. Pág. 88–113.

Camuña, R. J. F. (2014). Lenguajes de definición y modificación de datos SQL

(UF1472), Capitulo 2 - Lenguajes de definición, manipulación y control. Madrid,
ESPAÑA: IC Editorial. pág. 101-104