Tercera Forma Normal
Administración de Bases de Datos
Lilia González Arroyo
Equipo 3
Ambriz Pérez Alan Humberto
Cabrera Landaverde Iván Uriel
Cortes Covarrubias Oscar
Gandarela Bravo Isaías
Hernández Hernández Hidai
López Espinosa Javier Alberto
Muñiz Huerta María Fernanda
Ramírez Cásarez Diego
Rodríguez Zamudio Kevin Brian
Torres Farias Alan
Fecha de entrega
17 de octubre de 2020
0
ÍNDICE ÍNDICE
ÍNDICE .................................................................................................................................................................................... 1
INTORDUCCIÓN .................................................................................................................................................................... 2
DEFINICIÓN............................................................................................................................................................................ 2
CONCEPTOS DE DEPENDENCIA ........................................................................................................................................ 3
Dependencia funcional ........................................................................................................................................................ 3
Dependencia funcional completa ........................................................................................................................................ 4
Dependencia funcional parcial ............................................................................................................................................ 4
Dependencia transitiva ........................................................................................................................................................ 5
EJEMPLO ................................................................................................................................................................................ 5
EJERCICIO ............................................................................................................................................................................. 8
EJEMPLOS DE 3FN ............................................................................................................................................................... 9
Ejemplo 1 ............................................................................................................................................................................. 9
Ejemplo 2 ........................................................................................................................................................................... 12
Ejemplo 3 ........................................................................................................................................................................... 13
Ejemplo 4: .......................................................................................................................................................................... 14
CONCLUSIÓN ...................................................................................................................................................................... 15
ANEXO .................................................................................................................................................................................. 16
BIBLIOGRAFÍA ..................................................................................................................................................................... 16
REFERENCIAS ..................................................................................................................................................................... 17
1
INTORDUCCIÓN
ÍNTRODUCCIÓN
Como bien sabemos, la Normalización de bases de datos es muy importante debido a que al realizar este procedimiento
se evita la redundancia de los datos, los problemas de actualización de los datos en las tablas y se protege la integridad
de los datos.
Dentro de la Normalización se encuentra la Tercera Forma Normal (3FN), en la cual se enfoca este trabajo. La 3FN fue
definida originalmente por E.F. Codd en el año de 1971, y algunos años después, apareció una formulación alternativa de
la definición de este autor, dada por Carlo Zaniolo en 1982, la cual abordaremos más delante.
Los objetivos principales de la 3FN son eliminar las dependencias transitivas entre atributos no claves de las tablas en la
base de datos, y eliminar por completo cualquier tipo de redundancia que haya en la base de datos.
A grandes rasgos, con la 3FN se obtiene un diseño correcto de la base de datos, la cual es adaptable a las necesidades
de las aplicaciones, pues en este momento las tablas presentan una estructura relacional que nos permite manipular los
datos de manera sencilla.
A continuación, se abordarán aspectos conceptuales básicos relacionados con la 3FN, además de incluir algunos ejemplos
y ejercicios para tener claro el concepto y una mejor comprensión del tema.
DEFINICIÓN
DEFINICIÓN
FNBC exige que todas las dependencias no transitivas sean de la forma α → β donde α es una superclave. 3FN relaja
ligeramente esta restricción permitiendo dependencias funcionales no transitivas cuya parte izquierda no sea una
superclave. (1)
Un esquema de relación R está en tercera forma normal (3FN) respecto a un conjunto F de dependencias funcionales si,
para todas las dependencias funcionales de F+ de la forma α → β, donde α ⊆ R y β ⊆ R, se cumple al menos una de las
siguientes condiciones:
• α → β es una dependencia funcional transitiva.
• α es una superclave de R.
• Cada atributo A de β – α está contenido en alguna clave candidata de R. (1)
Por otro lado, tenemos a Elmasri y a Shamkant con la siguiente definición:
“Un esquema de relación R está en tercera forma normal (3FN) si, siempre que una dependencia funcional no transitiva X
-) A se cumple en R, ya sea (a) X una superclave de R, o (b) A un atributo primo de R.” (2)
Dos son los puntos a destacar en la definición general de la 3FN:
2
• Una tabla x viola 3FN porque la tabla y depende transitivamente de cada una de las claves candidatas de la tabla
x a través del atributo no primo de la tabla z.
• Las dependencias transitiva y parcial que violan 3FN pueden eliminarse en cualquier orden. (2)
Además, el esquema de 3FN debe cumplir necesariamente, las condiciones de la segunda forma normal. De una manera
más sencilla podemos expresar la 3NF para su realización a continuación:
• Primero se identifican los atributos que dependen indirectamente de la PK, porque tienen una dependencia con
otro atributo que si depende directamente de la PK. (Dependencia funcional Transitiva).
• Se agrupan esos atributos en una nueva entidad con el atributo del que dependen
Un memorable resumen de la definición de Codd de la 3FN, siendo paralelo al compromiso tradicional de dar evidencia
verdadera en un tribunal de justicia, fue dado por Bill Kent: cada atributo no-clave "debe proporcionar un hecho sobre la
clave, la clave entera, y nada más excepto la clave". Una variación común complementa esta definición con el juramento:
"con la ayuda de Codd".
Requerir que los atributos no-clave sean dependientes en "la clave completa" asegura que una tabla esté en 2NF; un
requerimiento posterior que los atributos no-clave sean dependientes de "nada excepto la clave" asegura que la tabla esté
en 3NF.
Los atributos primarios (que son claves o partes de claves) no deben ser funcionalmente dependientes en absoluto; cada
uno de ellos representa un hecho sobre la clave en el sentido de proporcionar parte o toda la clave en sí misma. Debe ser
observado que esta regla se aplica solamente a los atributos funcionalmente dependientes, ya que aplicándola a todos los
atributos prohibiría implícitamente claves de candidato compuestas, puesto que cada parte de cualquiera de tales claves
violaría la cláusula de "clave completa".
CONCEPTOSDE
CONCEPTOS DEDEPENDENCIA
DEPENDENCIA
Antes de definir la dependencia que se describe en la Tercera Forma Normal, se retomaran los conceptos de la
dependencia funcional y sus tipos para enriquecer la diferenciación que debe existir entre cada uno de ellos.
Dependencia funcional
Es el concepto individual más importante en el diseño de esquemas relacionales.
Una dependencia funcional es una restricción entre dos conjuntos de atributos de la base de datos, es decir, describe la
relación que existe entre los atributos de una relación. (5)
Es una propiedad del significado, o bien, de la semántica de los atributos de una relación. La semántica indica cómo se
relacionan entre sí los atributos y especifica las dependencias funcionales que existen entre ellos. Cuando hay presente
una dependencia funcional, la dependencia se especifica como una restricción entre los atributos. (4)
La utilidad principal de las dependencias funcionales es describir mejor un esquema de relación R mediante la
especificación de restricciones sobre sus atributos que deban cumplirse siempre.
3
Considerando el siguiente esquema, a partir de la semántica de los atributos, sabemos que deben cumplirse las siguientes
dependencias funcionales:
(a) NSS → NNOMBREE
El valor del número de seguro social de un empleado (NSS) determina de manera única el nombre de ese
empleado (NOMBREE)
(b) NÚMEROP → {NOMBREPR, LUGARP}
El valor del número de un proyecto (N~MEROP) determina de manera única el nombre del proyecto (NOMBREPR)
y su lugar (LUGARP)
(c) {NSS, NÚMEROP} → HORAS
Una combinación de valores de NSS y NÚMEROP determina de manera única el número de horas que el empleado
trabaja en el proyecto cada semana (HORAS).
Alternativamente, podemos decir que NOMBREE está depende funcionalmente de NSS, y así sucesivamente. (5)
Dependencia funcional completa
Es una característica adicional de las dependencias funcionales que resulta útil para el proceso de normalización, y
menciona que sus determinantes deben tener el número mínimo de atributos necesario para mantener la dependencia
funcional de los atributos del lado derecho.
En otras palabras, indica que, si A y B son atributos de una relación, B depende funcionalmente de manera completa de A
si B depende funcionalmente de A, pero no de ningún subconjunto propio de A. (8)
Dependencia funcional parcial
Es otra característica adicional de las dependencias funcionales y se presenta cuando hay algunos atributos que pueden
ser eliminados de X y la dependencia todavía se mantiene, esto es. Ejemplo:
(9)
4
Dependencia transitiva
Una dependencia transitiva es una dependencia funcional X → Z en la cual Z no es inmediatamente dependiente de X,
pero sí de un tercer conjunto de atributos Y, que a su vez depende de X. Es decir, X → Z por virtud de X → Y e Y → Z.
Es una condición en la que A, B y C son atributos de una relación tales que si A → B Y B → C, entonces C depende
transitivamente de A a través de B (supuesto que A no sea funcionalmente dependiente de B o C). (6)
Considerando el siguiente esquema, sabemos que deben cumplirse las siguientes dependencias transitivas:
La dependencia NSS → NSSGTED es transitiva a través de NÚMEROD porque se cumplen las dos dependencias NSS +
NÚMEROD y NÚMEROD → NSSGTED y NÚMEROD no es un subconjunto de la clave de EMP_DEPTO. Intuitivamente,
podemos ver que en EMP_DEPTO no es deseable la dependencia de NSSGTED con respecto a NÚMEROD porque
NÚMEROD no es una clave de EMP_DEPTO. (7)
Generalmente se toma que una entidad está en 3FN si está en 2FN y todos sus atributos no principales dependen
directamente de la clave primaria, es decir, no hay dependencias funcionales transitivas de atributos no principales respecto
de las claves.
Una vez identificados los atributos que dependen de otro atributo distinto de la clave, se formará con ellos una nueva
entidad y se eliminarán de la antigua. La clave principal de la nueva entidad será el atributo del cual dependen. Este atributo
en la entidad antigua, pasará a ser una clave ajena.
Una herramienta muy útil para visualizar las dependencias funcionales es el grafo o diagrama de dependencias funcionales,
mediante el cual se representa un conjunto de atributos y las dependencias funcionales existentes entre ellos. En el grafo
aparecen los nombres de los atributos unidos por flechas, las cuales indican las dependencias funcionales completas que
existen entre ellos, partiendo del implicante hacia el implicado. Cuando el implicante de una dependencia no es un único
atributo, es decir, se trata de un implicante compuesto, los atributos que lo componen se encierran en un recuadro y la
flecha parte de éste, no de cada Atributo.
EJEMPLO
EJEMPLO
Se trata de normalizar hasta la 3FN una base de datos de una academia que contenga información sobre Cursos,
Profesores, Libros, Editorial de los libros, Ciudad de la editorial, Teléfono de los profesores y aulas. Se imponen ahora las
siguientes condiciones:
• Cada curso es impartido siempre por un grupo bien definido de profesores.
• Cada curso tiene un grupo bien definido de libros.
• Cada curso impartido por un profesor con un cierto libro se realizará en un aula distinta.
5
Para plasmar todas estas condiciones, se incorpora a continuación una hipotética tabla con los tipos de datos anteriormente
definidos.
Curso Profesor Libro Aula Editorial Ciudad Teléfono
Física Luis A 1 Ciencia CDMX 1212121212
Física Luis B 2 Saber Monterrey 1212121212
Física Paco A 3 Ciencia CDMX 2323232323
Física Paco B 4 Saber Monterrey 2323232323
Español Pepe C 5 Saber Monterrey 3434343434
Español Pepe D 6 Futuro Morelos 3434343434
Español Ana C 7 Saber Monterrey 4545454545
Español Ana D 8 Futuro Morelos 4545454545
Español Juan C 9 Saber Monterrey 5656565656
Español Juan D 10 Futuro Morelos 5656565656
Teniendo en cuenta el enunciado del problema y los datos de la tabla anterior, se puede trazar el siguiente diagrama de
dependencias funcionales:
Para normalizar hasta la tercera forma normal se debe seguir los siguientes pasos:
• Determinar cuáles son las claves de la relación.
• Determinar cuál de estas claves funcionará como clave primaria.
En el ejemplo, la clave primaria sería (Curso, Profesor, Libro)
• Mirar si la relación se encuentra en 1FN.
En el ejemplo, se puede afirmar que la relación se encuentra en primera forma normal ya que los dominios son
atómicos.
• Confirmar si la relación se encuentra en 2FN.
En el ejemplo, la relación no se encuentra en segunda forma normal ya existen dependencias funcionales no completas
de la clave primaria.
Por lo tanto, se procede a llevar el ejemplo a la 2FN de la siguiente manera:
Sea una relación R (A, B, C, D) con clave primaria (A, B) y tal que RA -> RD, entonces la relación R puede descomponerse
como:
R1(A, D)
R2(A, B, C)
6
En el diagrama de dependencias funcionales, se muestra claramente que existen dos dependencias no completas de la
clave. Es decir, existen dos atributos que no dependen de la clave completa, sino de parte de ella.
Se procede a aplicar la 2FN a las dependencias no completas del ejemplo.
R= (Curso, Profesor, Libro, Aula, Editorial, Ciudad, Teléfono)
Después se procede a deshacer la dependencia no completa entre teléfono y profesor
R1= (Profesor, Teléfono)
R2= (Curso, Profesor, Libro, Aula, Editorial, Ciudad)
Después se va a deshacer la dependencia no completa R2 entre libro y editorial.
R1= (Profesor, Teléfono)
R3= (Libro, Editorial, Ciudad)
R4= (Curso, Profesor, Libro, Aula)
Ahora se puede afirmar que la relación R1, R3 y R4 se encuentran en 2FN. Las relaciones R1 y R4, se encuentran en 3FN,
ya que las dependencias funcionales que existen no son transitivas.
Sin embargo, la relación R3 no se encuentra en 3FN, ya que existen dependencias funcionales transitivas, es decir, que
existen atributos que dependen de otros atributos que no son clave.
7
EJERCICIO
EJERCICIO
Continuando con el ejemplo anterior: sea una relación R (A, B, C) con clave primaria (A) y tal que RB -> RC, entonces la
relación R puede descomponerse como:
R1 (A, B)
R2 (B, C)
Se procederá a deshacer la dependencia transitiva en R3.
R5= (Libro, Editorial)
R6= (Editorial, Ciudad)
Ahora se puede afirmar que las relaciones R1, R4, R5 y R6 se encuentran en 3FN.
El diagrama de dependencias funcionales quedará de la siguiente manera:
Las relaciones serán las siguientes:
R1= (Profesor, Teléfono)
R4= (Curso, Profesor, Libro, Aula)
R5= (Libro, Editorial)
R6= (Editorial, Ciudad)
8
R1
R1Profesor R1Teléfono
Luis 1212121212
Paco 2323232323
Pepe 3434343434
Ana 4545454545
Juan 5656565656
R4
R4Curso R4Profesor R4Libro R4Aula
Física1 Luis A 1
Física2 Luis B 2
Física3 Paco A 3
Física4 Paco B 4
Español1 Pepe C 5
Español2 Pepe D 6
Español3 Ana C 7
Español4 Ana D 8
Español5 Juan C 9
Español6 Juan D 10
R5
R5Libro R5Editorial
A Ciencia
B Saber
C Saber
D Futuro
R6
R6Editorial R6Ciudad
Ciencia CDMX
Saber Monterrey
Futuro Morelos
EJEMPLOS
EJEMPLOS DE 3FN
DE 3FN
Ejemplo 1
Se deberán considerar los datos de la siguiente tabla. ticket (id_orden, fecha, id_cliente, nom_cliente, ubicación, num_art,
nom_art, cant, precio)
Ticket
Id_orden Fecha Id_cliente Nom_cliente Ubicación Num_art nom_art cant Precio
240518 14/10/20 101 Eduardo EST-1 3786 Red 3 35,00
240518 14/10/20 101 Eduardo EST-1 4011 Raqueta 6 65,00
240518 14/10/20 101 Eduardo EST-1 9132 Paq-3 8 4,75
9
240517 16/10/20 107 Herman EST-2 5794 Paq-6 4 5,00
240516 1710/20 110 Daniela EST-3 4011 Raqueta 2 65,00
240516 1710/20 110 Daniela EST-3 3141 Funda 2 10,00
Primera formal normal (1FN)
Al examinar estos registros, podemos darnos cuenta de que contienen un grupo repetido para NUM_ART, NOM_ART,
CANT y PRECIO. La 1FN prohíbe los grupos repetidos, por lo tanto, tenemos que convertir a la primera forma normal. Los
pasos a seguir son:
Tenemos que eliminar los grupos repetidos.
Tenemos que crear una nueva tabla con la PK de la tabla base y el grupo repetido.
Los registros quedan ahora conformados en dos tablas que llamaremos TICKET y ARTICULOS_TICKET
ticket (id_orden, fecha, id_cliente, nom_cliente, Ubicación)
Articulos_ticket (id_orden, num_art, nom_art, cant, precio)
Ticket
Id_orden Fecha Id_cliente Nom_cliente Ubicación
240518 14/10/20 101 Eduardo EST-1
240517 16/10/20 107 Herman EST-2
240516 1710/20 110 Daniela EST-3
Articulos_ticket
Id_orden Num_art nom_art cant Precio
240518 3786 Red 3 35,00
240518 4011 Raqueta 6 65,00
240518 9132 Paq-3 8 4,75
240517 5794 Paq-6 4 5,00
240516 4011 Raqueta 2 65,00
240516 3141 Funda 2 10,00
Segunda formal normal (2FN)
Ahora procederemos a aplicar la segunda formal normal, es decir, tenemos que eliminar cualquier columna no llave que
no dependa de la llave primaria de la tabla. Los pasos a seguir son:
• Determinar cuáles columnas que no son llave no dependen de la llave primaria de la tabla.
• Eliminar esas columnas de la tabla base.
• Crear una segunda tabla con esas columnas y la(s) columna(s) de la PK de la cual dependen.
La tabla TICKET está en 2FN. Cualquier valor único de ID_ORDEN determina un sólo valor para cada columna. Por lo
tanto, todas las columnas son dependientes de la llave primaria ID_ORDEN.
Por su parte, la tabla ARTICULOS_TICKET no se encuentra en 2FN ya que las columnas PRECIO y NOM_ART son
dependientes de NUM_ART, pero no son dependientes de ID_ORDEN. Lo que haremos a continuación es eliminar estas
10
columnas de la tabla ARTICULOS_TICKET y crear una tabla ARTICULOS con dichas columnas y la llave primaria de la
que dependen.
Las tablas quedan ahora de la siguiente manera.
Articulos_ticket (id_orden, num_art, cant)
Articulos_ticket
Id_orden Num_art cant
240518 3786 3
240518 4011 6
240518 9132 8
240517 5794 4
240516 4011 2
240516 3141 2
Articulos ( num_art, nom_art, precio)
Articulos
Num_art nom_art Precio
3786 Red 35,00
4011 Raqueta 65,00
9132 Paq-3 4,75
5794 Paq-6 5,00
3141 Funda 10,00
Tercera formal normal (3FN)
La tercera forma normal nos dice que tenemos que eliminar cualquier columna no llave que sea dependiente de otra
columna no llave. Los pasos a seguir son:
• Determinar las columnas que son dependientes de otra columna no llave.
• Eliminar esas columnas de la tabla base.
• Crear una segunda tabla con esas columnas y con la columna no llave de la cual son dependientes.
Al observar las tablas que hemos creado, nos damos cuenta de que tanto la tabla ARTICULOS, como la tabla
ARTICULOS_TICKET se encuentran en 3FN. Sin embargo, la tabla TICKET no lo está, ya que NOM_CLIENTE y
UBICACIÓN son dependientes de ID_CLIENTE, y esta columna no es la llave primaria.
Para normalizar esta tabla, moveremos las columnas no llave y la columna llave de la cual dependen dentro de una nueva
tabla CLIENTES. Las nuevas tablas CLIENTES y TICKET se muestran a continuación.
ticket (id_orden, fecha, id_cliente)
Ticket
Id_orden Fecha Id_cliente
240518 14/10/20 101
240517 16/10/20 107
240516 1710/20 110
11
Clientes (id_cliente, nom_cliente, Ubicación)
Ticket
Id_cliente Nom_cliente Ubicación
101 Eduardo EST-1
107 Herman EST-2
110 Daniela EST-3
Por lo tanto, la base de datos queda de la siguiente manera:
ticket (id_orden, fecha, id_cliente)
Clientes (id_cliente, nom_cliente, Ubicación)
Articulos ( num_art, nom_art, precio)
Articulos_ticket (id_orden, num_art, cant)
Ejemplo 2
Se tiene la siguiente tabla ESTUDIANTE, donde la clave primaria es Id_estudiante y está compuesta por los siguientes
atributos:
ESTUDIANTE
Id_estudiante
Nombre_estudiante
Calle
Ciudad
Codigo_Postal
ESTUDIANTE
Id_estudiante Nombre_estudiante Calle Ciudad Codigo_Postal
1 José Moreno Arenal Monterrey 48035
2 Alan Pérez Mayor CDMX 48036
3 Patricia Juárez Insurgentes Guadalajara 48038
4 Cristian Hernández Bucareli Mérida 48039
En este ejemplo, Calle y Ciudad no tienen relación directa con la llave primaria, ya que no están directamente relacionado
con el estudiante, sino dependen del código postal.
Supongamos que hay múltiples estudiantes ubicados en un mismo código postal, con la tabla ESTUDIANTE teniendo una
inmensa cantidad de registros, y se requiere cambiar el nombre de la calle o la ciudad, entonces se deberá buscar y
actualizar esta calle o ciudad en toda la tabla ESTUDIANTE.
Buscar en una tabla enorme y actualizar los registros únicos o múltiples sería un trabajo muy agotador, en consecuencia,
afectará el rendimiento de la base de datos.
Esto se puede solucionar creando una nueva tabla (POSTAL) que esté relacionada con la tabla ESTUDIANTE usando el
atributo CODIGO_POSTAL.
12
De esta manera si se quisiera hacer el cambio de la calle o ciudad solo se tendría que hacer una vez en la tabla POSTAL
y se reflejará inmediatamente en la tabla ESTUDIANTE.
Como resultado se obtendrán las siguientes tablas y estarán en 3FN:
ESTUDIANTE POSTAL
Id_estudiante Codigo_Postal
Nombre_estudiante Calle
Codigo_Postal Ciudad
ESTUDIANTE
Id_estudiante Nombre_estudiante Codigo_postal
1 José Moreno 48035
2 Alan Pérez 48036
3 Patricia Juárez 48038
4 Cristian Hernández 48039
POSTAL
Codigo_Postal Calle Ciudad
48035 Arenal Monterrey
48036 Mayor CDMX
48038 Insurgentes Guadalajara
48039 Bucareli Mérida
Ejemplo 3
Sea la siguiente tabla con el campo Num_Proyecto como clave principal y con valores repetidos en atributos que no son
claves.
Proyectos
Num_Proyecto Titulo_Proyecto Gerente_Proyecto Teléfono
30-452-T3 Manual STAR Juan 2756
30-457-T3 Procedimientos ISO Fernanda 2947
30-482-TC Página Web Pedro 2846
31-124-T3 Manual Empleado Víctor 3102
31-238-TC Prototipo de STAR Juan 2756
31-241-TC Nuevo catalogo Víctor 3102
35-152-TC Precio de STAR Karen 3022
36-272-TC Sistema de Orden Fernanda 2947
El valor de Teléfono se repite cada vez que se repite el nombre de un gerente. Esto es porque el número de teléfono solo
tiene una dependencia de segundo grado con el número de proyecto. Realmente primero depende del gerente, y este a
su vez depende del número de proyecto, lo cual hace una dependencia transitiva.
El atributo Gerente_Proyecto no puede ser una posible clave en la tabla Proyectos porque un mismo gerente maneja más
de un proyecto. La solución para esto es eliminar el atributo con los datos repetidos (Teléfono), creando una tabla separada.
Se deben agrupar los atributos que correspondan, creando una nueva tabla para guardarlos. Los datos se ingresan y se
verifica que los valores que se repitan no formen parte de la clave primaria. Se establece la clave primaria para cada tabla
y, si es necesario, se agregan claves externas.
13
Para cumplir con la tercera forma normal se crea una nueva tabla (Gerentes) para así solucionar el problema. Ambas tablas
se relacionan a través del campo Gerente_Proyecto:
Proyectos
Num_Proyecto Titulo_Proyecto Gerente_Proyecto
30-452-T3 Manual STAR Juan
30-457-T3 Procedimientos ISO Fernanda
30-482-TC Página Web Pedro
31-124-T3 Manual Empleado Víctor
31-238-TC Prototipo de STAR Juan
31-241-TC Nuevo catalogo Víctor
35-152-TC Precio de STAR Karen
36-272-TC Sistema de Orden Fernanda
Gerentes
Gerente_Proyecto Teléfono
Juan 2756
Fernanda 2947
Pedro 2846
Víctor 3102
Juan 2756
Víctor 3102
Karen 3022
Fernanda 2947
Ejemplo 4:
Como podemos apreciar en este ejercicio contamos con Eventos y Cursos; Teniendo un enlace de uno a muchos desde
curso en la tabla superior (Eventos) a IDCurso en la tabla inferior (Cursos). Ambas tablas ya se encuentran en la primera
forma normal debido a que no contamos con ninguna repetición de valores, ni tenemos grupos de repetición y también ya
se encuentran en la segunda forma normal es decir no hay ninguna parte que sea dependiente solo de una parte de la
clave compuesta.
Ahora, aplica la tercera forma normal:
14
El problema se encontraba en el aula y la capacidad que estas tienen ya que estos campos no son clave y las columnas
tampoco forman parte de la clave primaria ; cómo podemos apreciar el aula 4A tiene 12 asientos (Plazas) disponibles sin
importar el curso que se esté tomando, lo mismo pasa con el aula 7B en este caso 14 asientos; es decir cada que entremos
a el aula 7A siempre tendremos 12 asientos y siempre que entremos a el Aula 7B tendremos 14 por lo tanto, no necesitamos
repetir esa información podemos averiguar la capacidad del aula simplemente averiguando el número del aula en
consecuencia no es necesario que los datos estén almacenados dentro de la misma tabla (tabla Eventos) de modo que
dividimos parte de esa información y la separamos en su propia tabla. Sacando Plazas de la tabla eventos. Esto nos dice
que las aulas tienen una capacidad fija; ahora si estamos dentro de la tercera forma normal.
CONCLUSIÓN
CONCLUSIÓN
Como resultado de este trabajo, es posible concluir que la normalización es básicamente utilizada para diseñar tablas en
las que las redundancias de datos se reducen a lo más mínimo, por lo que las formas de mayor nivel son mejores que las
de menor nivel, es decir, la 3FN es mejor que la 2FN y por ende es mejor que la 1FN.
Por otro lado, es importante recordar que cada una de las formas normales exige cierto nivel de complejidad, y por ello se
debe analizar si se requiere llegar hasta la 3FN dependiendo de las necesidades de la base de datos, aunque casí todos
los diseños de negocios utilizan la 3FN como forma ideal.
De manera resumida podemos decir que la 3FN es una manera bastante sencilla de manejar los datos, ya que el diseño
que se obtiene al concluir su proceso es muy seguro. Además, sirve para mejorar el desempeño de una base de datos, así
como evitar la redundancia dentro de ella.
15
ANEXO
A continuación, se anexa un vídeo con la finalidad de entender mejor la explicación de la 3FN
(Yacklyon, 2019)
BIBLIOGRAFÍA
BIBLIOGRAFÍA
(1) Silberschatz, A., Korth, H. & Sudarshan, S. (2002). Fundamentos de bases de datos. 28023 Aravaca (Madrid):
McGRAW-HILL. PP. 174-179.
(2) Elmasri, R. & Shamkant B. (2007). Fundamentos de Sistemas de Bases de Datos. 28042 Madrid: PEARSON
EDUCACiÓN S.A. PP. 304-308.
(3) Database Dev (2015). Third Normal Form (3NF) – Normalising Your Database. Tomado de: databasedev.co.uk.
(4) Thomas M. Connolly, Carolyn E. Begg. (2005). Sistemas de bases de datos. Madrid: PEARSON. PP. 358.
(5) Elmasri, R. & Shamkant B. (2007). Fundamentos de Sistemas de Bases de Datos. 28042 Madrid: PEARSON
EDUCACiÓN S.A. PP. 406.
(6) Thomas M. Connolly, Carolyn E. Begg. (2005). Sistemas de bases de datos. Madrid: PEARSON. PP. 361.
(7) Elmasri, R. & Shamkant B. (2007). Fundamentos de Sistemas de Bases de Datos. 28042 Madrid: PEARSON
EDUCACiÓN S.A. PP. 418.
16
(8) Thomas M. Connolly, Carolyn E. Begg. (2005). Sistemas de bases de datos. Madrid: PEARSON. PP. 360.
(9) Thomas M. Connolly, Carolyn E. Begg. (2005). Sistemas de bases de datos. Madrid: PEARSON. PP. 371.
(10) Gabillaud, J. (2009). SQL Server 2008. Cornellà de Llobregat: ENI.
REFERENCIAS
REFERENCIAS
Atom. (s.f.). Diagramas de dependencia funcional. Ejemplo de normalización. Obtenido de
http://teonormalgebrarelaciobal.blogspot.com/p/se-trata-de-normalizar-hasta-la-3fn-una.html
Birt LH. (31 de Marzo de 2020). Dependencias funcionales y formas normales. Obtenido de
https://ikastaroak.birt.eus/edu/argitalpen/backupa/20200331/1920k/es/ASIR/GBD/GBD02/es_ASIR_GBD02_Cont
enidos/website_51_dependencias_funcionales_y_formas_normales.html
Corvo, H. S. (s.f.). ¿Qué es la tercera forma normal? Obtenido de https://www.lifeder.com/tercera-forma-normal/
Yacklyon. (31 de 07 de 2019). CURSO de DISEÑO de BASE DE DATOS #13 TERCERA FORMA NORMAL. Obtenido
de https://www.youtube.com/watch?v=_0OyBCLq-kM
17
