República Bolivariana de Venezuela

Ministerio de Poder Popular para la Educación Universitaria

Universidad Nacional Experimental

“Simón Rodríguez”

Núcleo: Palo Verde

Autor:

Br. Robinson Calderón Leandro Blanco

V-24656308

Caracas, octubre 2023

1
 Índice

Índice...........................................................................................................................2

Introducción.................................................................................................................3

¿Conceptos de normalización en la vinculación y/o relación de tablas y....................4

Contenedores de bases de datos?.................................................................................4

¿Por qué es necesaria la normalización?.....................................................................4

¿Qué es dependencia funcional?..................................................................................5

Diferentes formas normales: Anomalías. 1FN, 2FN, 3FN, FNBC (Boyce Codd),.....5

4FN y DK/NF (dominio/clave)....................................................................................5

Cómo alcanzar las diferentes Formas Normales.........................................................7

3 Ejemplos y análisis de cada uno...............................................................................8

Conclusión.................................................................................................................17

Bibliografía................................................................................................................18

Referencia página web...............................................................................................18

2
 Introducción

En la bases de datos es importante un concepto lo cual es normalización de las

misma, esto ayuda a que todas las tablas tenga la menor redundancia posible para la
claridad de los datos y la facilidad de la información, por ende cada paso para normalizar,
los datos redundantes desperdician el espacio de disco y crean problemas de
mantenimiento. Si hay que cambiar datos que existen en más de un lugar, se deben cambiar
de la misma forma exactamente en todas sus ubicaciones. Un cambio en la dirección de un
cliente es mucho más fácil de implementar si los datos sólo se almacenan en la tabla
Clientes y no en algún otro lugar de la base de datos.

3
 ¿Conceptos de normalización en la vinculación y/o relación de tablas y

Contenedores de bases de datos?

Es el proceso de organizar los datos de una base de datos, valga la redundancia.

Debemos tener en cuenta la creación de tablas y las reglas que se usan para definir las
relaciones, estas reglas son diseñadas para proteger los datos, y para que la base de datos
sea flexible con el fin de eliminar redundancias y dependencias incoherentes.
Siendo la aplicación de una serie de reglas para evitar a futuro realizar queries o
consultas innecesariamente complejas. En otras palabras están enfocadas en eliminar
redundancias e inconsistencias de dependencia en el diseño de las tablas que creamos para
organizar las bases de datos.

¿Por qué es necesaria la normalización?

La normalización de base de datos ayuda a evitar estos efectos negativos ya desde el

diseño de nuevas bases de datos y permite también comprobar si las existentes garantizan la
integridad de datos o referencial necesaria. Lo más recomendable es proceder a normalizar
los datos antes de crear las tablas de la base de datos, aunque siempre es preferible asegurar
su integridad y, aunque ya se cuente con las bases de datos y no sean de nueva creación,
utilizar estas técnicas para ponerlas a prueba, teniendo claros los objetivos a alcanzar en el
proceso.
La normalización tiene como objetivo optimizar los datos y brindar integridad, los
beneficios específicos son:
Evitar la redundancia de los datos.
Prevenir problemas de actualización.
Proteger la integridad de los datos.
Facilitar el acceso e interpretación de los datos.
Reducir el tiempo y complejidad de revisión de las bases de datos.
Optimizar el espacio de almacenamiento.
Prevenir borrados indeseados.

4
 ¿Qué es dependencia funcional?

Una dependencia funcional es un tipo de restricción que constituye una

generalización del concepto de clave, como se estudió en el modelo E-R y el modelo
relacional. Pero no es tan sencillo localizar las dependencias, ya que requieren un análisis
de los atributos o, con más precisión, de las interrelaciones entre atributos, y
frecuentemente la intuición no es suficiente a la hora de encontrar y clasificar todas las
dependencias. La teoría nos puede ayudar un poco en ese sentido, clasificando las
dependencias en distintos tipos, indicando qué características tiene cada tipo.
Es importante mencionar que las dependencias se pueden dar entre atributos o entre
subconjuntos de atributos. Estas dependencias son consecuencia de la estructura de la base
de datos y de los objetos del mundo real que describen, y no de los valores actualmente
almacenados en cada relación.

Diferentes formas normales: Anomalías. 1FN, 2FN, 3FN, FNBC (Boyce Codd),

4FN y DK/NF (dominio/clave)

El proceso de normalización consiste verificar el cumplimiento de ciertas reglas que

aseguran la eliminación de redundancias e inconsistencias, con el objetivo de
conseguir tablas con una estructura óptima y eficaz. Esto se hace mediante la aplicación de
ciertos procedimientos y en ocasiones se traduce en la separación de los datos en diferentes
relaciones.
FN – Primera Forma Normal
Una tabla está en Primera Forma Normal si:
Todos los atributos son «atómicos». Por ejemplo, en el campo teléfono no tenemos
varios teléfonos. La tabla contiene una clave primaria única. Por ejemplo el NIF para
personas, la matrícula para vehículos o un simple id autoincrementar. Si no tiene clave, no
es 1FN.
La clave primaria no contiene atributos nulos. No podemos tener filas para las que
no haya clave (por ejemplo, personas sin NIF o vehículos sin matrícula). No debe existir
variación en el número de columnas. Si algunas filas tienen 8 columnas y otras 3, pues no
estamos en 1FN.

5
 Los campos no clave deben identificarse por la clave. Es decir, que los campos no
clave dependen funcionalmente de la clave. Esto es prácticamente lo mismo que decir que
existe clave primaria.
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. Por ejemplo, si en
la columna 1 tenemos el primer apellido y en la columna 2 tenemos el segundo, pues no
estamos en 1FN. Igualmente si en la tercera fila tenemos el tercer mejor expediente y en la
quinta fila el quinto, no estamos en 1FN.
2FN – Segunda Forma Normal
Una tabla está en 2FN si además de estar en 1FN cumple que los atributos no clave
depende de TODA la clave principal.
Por ejemplo, si tenemos una tabla con Personas, identificadas por su NIF y
recogemos su empresa y dirección de trabajo, la clave sería NIF-Empresa. Pero nos
encontraremos con que una misma persona puede trabajar en varias empresas. Y vemos que
la dirección de trabajo no depende de TODA la clave primaria, sino solo de la empresa. Por
lo tanto, no estamos en 2FN.
3FN – Tercera Forma Normal
Una tabla está en 3FN si además de estar en 2FN no existe ninguna dependencia
transitiva entre los atributos que no son clave.
Vamos a explicarlo. Como dijo Bill Kent, «todo atributo no clave debe proporcionar
información sobre la clave, sobre toda la clave y nada más que la clave… con la ayuda de
Codd».
Bueno, en serio, supongamos que tenemos una tabla de ganadores de torneos de
tenis. En ella figura el nombre del torneo, el año, el nombre del ganador y su nacionalidad.
La clave sería Torneo-Año. Pues esta tabla no está en 3FN porque el atributo nacionalidad,
que no es de la clave, depende del nombre del ganador (también depende de la clave).
Digamos que nacionalidad aporta información sobre el ganador, pero no sobre la clave. Es
una dependencia transitiva porque nacionalidad depende de ganador que a su vez depende
de Torneo-Año.
FN de Boyce-Codd

6
 Es una FN ligeramente más estricta que la 3FN. En concreto requiere esté en 3FN y
que no existan dependencias funcionales no triviales de los atributos que no sean un
conjunto de la clave candidata. O dicho de otra forma: una tabla está en FNBC si está en
3FN y los únicos determinantes (atributo que depende de otro atributo) son claves
candidatas.

Cómo alcanzar las diferentes Formas Normales.

Las formas normales deben ser aplicadas a todas las tablas de una base de datos. Por
lo tanto, cuando afirmamos que una base de datos se encuentra en la Forma Normal N
estamos asegurando que todas sus tablas lo están.
En general, las tres primeras formas normales son el mínimo que deben cubrir la
mayoría de las bases de datos y, aunque son posibles otros niveles de normalización, es
considerado como el máximo nivel necesario para la mayoría de las aplicaciones.
El creador de estas tres primeras formas normales fue Edgar F. Codd.
Cada uno de estos niveles cumple con ciertos requisitos que tienen el objetivo de
simplificar la información sin que exista una pérdida de datos.
A continuación, veamos cada de ellas.
Primera Forma Normal (1FN)
Una tabla está en la primera forma normal si, y solo si, cumple con estas reglas:
Todos los datos son atómicos.
Todos los atributos o columnas son del mismo tipo de datos.
Segunda Forma Normal (2FN)
Una tabla está en la segunda forma normal si sigue estas reglas:
Si la tabla está en la primera forma normal.
Los atributos que no forman parte de ninguna clave han de depender funcionalmente
de toda la clave primaria.
Tercera Forma Normal (3FN)
Una tabla está en la tercera forma normal si cumple estas reglas:
Si la tabla está en la segunda forma normal.

7
 Los atributos no-clave no pueden depender de forma transitiva de una clave
candidata (cuando un atributo que no sea clave depende de una clave primaria a través de
otro atributo que no sea clave).
Forma Normal de Boyce-Codd
Una tabla está en la forma de Boyce-Codd si cumple las siguientes condiciones:
Si está en la tercera forma normal.
Si cada determinante es una clave candidata.
Un determinante es un atributo que determina el valor de otro atributo.
Una clave candidata es una clave o una clave alternativa (en otras palabras, el
atributo puede ser una clave para dicha tabla).
Cuarta Forma Normal (4FN)
Una tabla está en la cuarta forma normal si cumple los siguientes criterios:
Si está en la forma normal de Boyce-Codd.
Si no contiene más de una dependencia multi-valor.
Quinta Forma Normal (5FN) y otras Básicamente, una tabla está en la quinta forma
normal, cuando no puede ser dividida en tablas más pequeñas con diferentes claves (la
mayor parte de las tablas se pueden dividir en tablas más pequeñas con la misma clave).
Más allá de la quinta forma normal, entramos en el apasionante mundo de las formas
normales de clave dominante, un tipo ideal teórico que no se utiliza en la práctica.
3 Ejemplos y análisis de cada uno.

Todas las entradas son atómicas y hay una clave primaria compuesta (employee_id,
job_code) así que la tabla está en la primera forma normal (1NF).

8
 Pero inclusive si solamente sabes el employee_id de alguien, entonces puedes
determinar su name, home_state, y state_code (porque deberían ser la misma persona). Esto
significa que name, home_state, y state_code son dependientes de employee_id (una parte
de la clave primaria compuesta). Así que, la tabla no está en 2NF. Deberíamos separarlos a
una tabla distinta para hacerlo 2NF.

home_state ahora es dependiente de state_code. Así que, si sabes el state_code,

entonces puedes encontrar el valor de home_state.
Para llevar esto a un paso más allá, deberíamos separarlos otra vez a una tabla
distinta para hacerlo 3NF.

9
 Con esta tenemos nuestra base de datos normalizada
Segundo ejemplo

A tabla sin clave primaria: La tabla SI tiene clave primaria. (Titulo)

Redundancia de claves primarias (clave primaria repetida): Por el momento NO hay
redundancia de claves primarias.

10
 Celdas con múltiples datos: La celda Genero ya NO tiene múltiples datos.
Nombres de las columnas con caracteres extraños ($#%): Todos los nombres están
correctos.
Solucionamos el problema de la columna (Genero) pero ahora se presentó otro
problema.
Al guardar en cada celda un dato. Esto creo una redundancia de clave primaria.
Por ello la primera forma sigue sin cumplirse. Porque esa columna sigue generando
complicaciones.

Una tabla sin clave primaria: La tabla SI tiene clave primaria. (Titulo)
Redundancia de claves primarias (claves primarias repetidas): Todo correcto.
Celdas con múltiples datos: La celda Género ya NO tiene múltiples datos.
Nombres de las columnas con caracteres extraños ($#%): Todos los nombres están
correctos.

11
 Casi todas las columnas dependen funcionalmente de titulo y solamente el Precio
depende de la clave primaria compuesta completa.
Esto es un problema de dependencias parciales, porque los atributos dependen de
una parte de la clave y no de la clave primaria completa (Titulo + Formato)
Por consecuente no cumplimos con la segunda forma normal.

Tabla de precios

Tabla: Películas.

12
 La clave primaria de nuestra tabla es (Titulo), tomando en cuenta esto.
Las dependencias funcionales deberían ser así…
Titulo -> Director
Titulo -> Nacionalidad
Titulo -> Duración
Titulo -> Puntuación
Titulo -> Productora
Pero no es el caso… Esta es la dependencia funcional actual:
Titulo -> Director
Director -> Nacionalidad
Titulo -> Duración
Titulo -> Puntuación
Titulo -> Productora
Todas las columnas son determinadas por el título, excepto la nacionalidad del
director que es determinada por el director.
Titulo -> director: El titulo determina el director, porque dependiendo de la película
el director es diferente.
Director -> Nacionalidad: El título de la película no tiene ninguna relación con la
nacionalidad, la única columna que puede determinarla es el director en sí.
Todas las columnas son dependientes de la clave primaria (Titulo), excepto
nacionalidad que depende de un atributo no clave (director), y director si depende de la
clave (Titulo)
Esto es un problema de dependencias transitivas, porque el atributo no depende de la
clave sino de un campo no clave. Aquí te dejo otro ejemplo de dependencia transitiva por si
tienes dudas.

13
 3 ejemplo

Primera Forma Normal. Separamos las tablas estableciendo la relación entre ella por
matricula, que referencia al alumno (clave primaria). Por tanto la nueva tabla tiene como
clave primaria “código” y posee un campo matricula que actúa como clave foránea a
matricula en alumno.
La relación alumno. Matricula <- curso. Matricula establece la vinculación entre los
registros de cada tabla.

14
 Segunda Forma Normal. Cuando se estable una relación muchos a muchos (N:M) se
genera una relación como tabla adicional. En este caso alumno curso.

Tercera Forma Normal. Eliminar aquellos campos que no dependan de la clave.

Carrera no depende directamente de la clave primaria en alumnos, por tanto debe sacarse de
la tabla alumnos.

15
16
 Conclusión

La normalización es una herramienta fundamental en las bases de datos ya que ella

permite el mejor manejo de datos de forma clara que la redundancia sea un problema
resuelto la facilidad de leer mejor y ordenado los datos son lo que nos llevara a un
excelente manejos de datos facilitando la información clara concreta y versátil.

17
 Bibliografía

Referencia página web

https://www.uv.mx/personal/ermeneses/files/2020/09/Clase7-
Normalizacion_parteIFinal.pdf
https://bookdown.org/paranedagarcia/database/normalizacion.html
https://platzi.com/blog/normalizar-una-base-de-datos-y-no-morir-en-el-intento/
https://www.google.com/url?
sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwidg9ak5teCAxWHVTABHVu
hDj0QFnoECA4QAQ&url=https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Fexplodat.cl%2FAnalytics%2Fdesarrollo-de-
software%2Fnormalizacion-de-bases-de-datos%2F&usg=AOvVaw1P-
ItlFHXfV4mRLXzGS_WT&opi=89978449
https://www.google.com/url?
sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwidg9ak5teCAxWHVTABHVu
hDj0QFnoECA4QAQ&url=https%3A%2F%2F2.zoppoz.workers.dev%3A443%2Fhttps%2Fexplodat.cl%2FAnalytics%2Fdesarrollo-de-
software%2Fnormalizacion-de-bases-de-datos%2F&usg=AOvVaw1P-
ItlFHXfV4mRLXzGS_WT&opi=89978449
https://learn.microsoft.com/es-es/office/troubleshoot/access/database-normalization-
description

18