Taller de base

de datos
Normalización en base de datos

Liliana Ruíz Lázaro 14010299

[Seleccione la fecha]
Normalización de la base de datos

Qué es la normalización

La normalización es un concepto de diseño de bases de datos que se aplica a las bases de datos
relacionales para evitar las redundancias.

El modelo relacional es el concepto más extendido en la gestión informatizada de los datos. En las
bases de datos de este tipo, la información se guarda en registros en tablas interconectadas por
medio de claves. Un registro se compone de varios campos de valores que se subordinan a ciertos
atributos a lo largo de las columnas de la tabla.

Objetivos de la normalización de base de datos

Al proceder a la normalización de base de datos hay que plantearse 4 metas:

 Organizar los datos en grupos lógicos, de tal manera que cada grupo describa una
pequeña parte del todo.
 Minimizar la cantidad de datos duplicados almacenados en una base de datos.
 Perfeccionar la organización de los datos de tal manera que, cuando se necesite
introducir modificaciones, el cambio sólo deba aplicarse en un lugar.
 Construir una base de datos a la que se pueda acceder de forma rápida y donde sea
posible manipular los datos con la máxima eficiencia y sin comprometer su integridad.

La normalización de base de datos es especialmente importante en el entorno del

procesamiento transaccional, sobre todo en el que se lleva a cabo en línea. Esto es debido a la
agilidad con que se llevan a cabo las modificaciones de datos que, además, suelen darse de
forma aleatoria. Inserciones, eliminaciones o actualizaciones afectan a los datos almacenados
pudiendo disminuir el rendimiento de la base de datos si ésta no se ha normalizado.

No obstante, antes de poder empezar a normalizar una base de datos es preciso realizar un
análisis de requisitos, que servirá para determinar las políticas y procedimientos a aplicar. De
esta investigación resultará un compendio de reglas de negocio.

Estas reglas han de ser obtenidas por consenso y, este acuerdo entre los usuarios de la base de
datos, tanto en materia de uso de los distintos elementos de cada tabla, como en cuanto a sus
definiciones, es fundamental para lograr los objetivos de la normalización de base de datos.
Para llegar al consenso pueden emplearse esquemas o metodologías, que faciliten la transición
a lo largo de la fase de requisitos, análisis y esquema de base de datos. Lo importante es que
las reglas estén claras y que el significado de cada término y la forma de utilizarlo quede
confirmada antes de empezar a normalizar.
Primera Formal Normal

La primera regla de normalización se expresa generalmente en forma de dos indicaciones

separadas.

 Todos los atributos, valores almacenados en las columnas, deben ser indivisibles.
 No deben existir grupos de valores repetidos.

La primera forma normal impone un requisito muy elemental a las relaciones; a diferencia de
las demás formas normales, no exige información adicional como las dependencias
funcionales. Un dominio es atómico si se considera que los elementos del dominio son
unidades indivisibles. Se dice que el esquema de una relación R está en la primera forma normal
(1FN) si los dominios de todos los atributos de R son atómicos.

En el ejemplo tenemos una tabla No Normalizada que contiene Estudiantes, Tutor, Habitación y
las Clases 1,2 y 3. Vamos a implementar la primera forma normal, luego la segunda y la tercera.
Al aplicarle la primera forma normal eliminamos los grupos repetidos quedándonos con una
sola columna de clases y repitiendo los datos del estudiante tutor y habitación y ahora no
tenemos grupos repetidos porque aplicamos la primera forma normal (1FN).
Segunda Forma Normal

La segunda forma normal asegura que cada atributo describe la entidad

Crear tablas separadas para el conjunto de valores y los registros múltiples, estas tablas se
deben relacionar con una clave externa.

Los registros no deben depender de otra cosa que la clave principal de la tabla, incluida la clave
compuesta si es necesario

Al pasar a la segunda forma normal vamos a eliminar los datos redundantes, y para lograrlo
vamos a crear dos tablas. Una tabla se llamara Estudiantes donde eliminaremos los datos
redundantes quedándonos con los datos únicos (Estudiante, Tutor y Habitación) y en una
segunda tabla que llamaremos Registro para el numero de estudiante y las clases que llevara en
el ejemplo el estudiante 1606 y 2602 llevara cada uno tres clases. El contenido de la (1FN)
Primera Forma Normal que estaba en una tabla ha sido divido en dos tablas para eliminar los
datos redundantes e introducirlo a la (2FN) Segunda Forma Normal.
Tercera Forma Normal

Hay esquemas relacionales en que la descomposición FNBC no puede conservar las

dependencias. Para estos esquemas hay dos alternativas si se desea comprobar si una
actualización viola alguna dependencia funcional:

Soportar el coste extra del cálculo de las reuniones para buscar violaciones.
Emplear una descomposición alternativa, la tercera forma normal (3FN), que se
presenta a continuación, que hace menos costoso el examen de las actualizaciones.

A diferencia de FNBC, las descomposiciones 3FN pueden contener cierta redundancia en el

esquema descompuesto. Se verá que siempre resulta posible hallar una descomposición de
reunión sin pérdida que conserve las dependencias que esté en 3FN. La alternativa que se
escoja es una decisión de diseño que debe adoptar el diseñador de la base de datos con base
en los requisitos de la aplicación.

Para pasar a la tercera forma normal tenemos que eliminar los campos de No Dependen de la
Clave y para lograrlo dividimos la tabla estudiante en dos tablas y creamos la tabla Facultad
donde trasladaremos la columna habitación que No Depende de la Clave que es la columna
estudiante, el nombre del tutor sera el enlace con al tabla estudiante aunque también podría
ser la columna estudiante.
Cuarta Formal Normal

La cuarta forma normal también se llama la forma normal de Boyce Codd (BCNF) y la quinta
forma normal existe, pero rara vez se consideran en el diseño práctico.

Un esquema de relación R está en la cuarta forma normal (4FN) con respecto a un conjunto F
de dependencias funcionales y multivaloradas si, para todas las dependencias multivaloradas
de F+ de la forma α →→ β, donde α ⊆ R y β ⊆ R, se cumple, como mínimo, una de las
condiciones siguientes

• α →→ β es una dependencia multivalorada trivial.

• α es una superclave del esquema R. Un diseño de base de datos está en 4FN si cada
componente del conjunto de esquemas de relación que constituye el diseño halla en 4FN.

Considere el siguiente ejemplo:

Permutaciones de envíos de pizzas

Restaurante Variedad de Pizza Área de envío

Vincenzo's Pizza Corteza gruesa Springfield

Vincenzo's Pizza Corteza gruesa Shelbyville

Vincenzo's Pizza Corteza fina Springfield

Vincenzo's Pizza Corteza fina Shelbyville

Elite Pizza Corteza fina Capital City

Elite Pizza Corteza rellena Capital City

A1 Pizza Corteza gruesa Springfield

A1 Pizza Corteza gruesa Shelbyville

A1 Pizza Corteza gruesa Capital City

A1 Pizza Corteza rellena Springfield

A1 Pizza Corteza rellena Shelbyville

A1 Pizza Corteza rellena Capital City

Cada fila indica que un restaurante dado puede entregar una variedad dada de pizza a un área
dada.
Note que debido a que la tabla tiene una clave única y ningún atributo no-clave, no viola
ninguna forma normal hasta el FNBC. Pero debido a que las variedades de pizza que un
restaurante ofrece son independientes de las áreas a las cuales el restaurante envía, hay
redundancia en la tabla: por ejemplo, nos dicen tres veces que A1 Pizza ofrece la Corteza rellena,
y si A1 Pizza comienza a producir pizzas de Corteza de queso entonces necesitaremos agregar
múltiples registros, uno para cada una de las Áreas de envío de A1 Pizza. En términos formales,
esto se describe como que Variedad de pizza está teniendo una dependencia multivalor
en Restaurante.
Para satisfacer la 4FN, debemos poner los hechos sobre las variedades de pizza ofrecidas en una
tabla diferente de los hechos sobre áreas de envío:

Áreas de envío por restaurante

Variedades por restaurante

Área de
Restaurante
envío
Variedad de
Restaurante
pizza
Vincenzo's
Springfield
Pizza
Vincenzo's
Corteza gruesa
Pizza
Vincenzo's
Shelbyville
Pizza
Vincenzo's
Corteza fina
Pizza
Elite Pizza Capital City
 Elite Pizza Corteza fina A1 Pizza Springfield

Elite Pizza Corteza rellena A1 Pizza Shelbyville

A1 Pizza Corteza gruesa A1 Pizza Capital City

A1 Pizza Corteza rellena

En contraste, si las variedades de pizza ofrecidas por un restaurante a veces variaran de un área
de envío a otra, la tabla original de la tres columnas satisfaría la 4FN.

Quinta Forma Normal

La quinta forma normal (5FN), también conocida como forma normal de proyección-unión (PJ/NF),
es un nivel de normalización de bases de datos diseñado para reducir redundancia en las bases de
datos relacionales que guardan hechos multi-valores aislando semánticamente relaciones múltiples
relacionadas. Una tabla se dice que está en 5NF si y sólo si está en 4NF y cada dependencia de
unión (join) en ella es implicada por las claves candidatas.
Sexta Forma Normal

La sexta forma de normalización es muy reciente. Fue presentada a finales de la década de los
años 90 por Christopher J. Date. En esta normalización la variable de relación se descompone
hasta componentes irreductibles. Una base de datos cumplirá con la sexta forma de
normalización si satisface los siguientes criterios:

1. Que cumpla con la 5NF

2. Que cada dependencia de la relación sea trivial.

Para comprender lo anterior, imaginemos la siguiente tabla que está en 5NF:

Tabla MEC

Matrícula Estudiante Calificación

En el caso anterior, las dependencias join serían {Matrícula, Estudiante} y {Matrícula,

Calificación}. Para que la anterior tabla cumpla con la 6NF, debería escindirse de la siguiente
forma:

Tabla ME

Matrícula Estudiante

Tabla MC

Matrícula Calificación
Bibliografía
http://aldi.blogspot.es/1417121799/5ta-forma-normal/

https://blog.powerdata.es/el-valor-de-la-gestion-de-datos/por-que-se-necesita-la-normalizacion-
de-base-de-datos

http://www.interaktiv.cl/clases/disenobd/libros/FundaBD_Silverschatz.pdf

https://adgarza.blogspot.com/2019/03/normalizacion-de-bases-de-datos-parte-6.html

https://programas.cuaed.unam.mx/repositorio/moodle/pluginfile.php/872/mod_resource/conte
nt/1/contenido/index.html

https://picodotdev.github.io/blog-bitix/2018/02/las-6-plus-2-formas-normales-de-las-bases-de-
datos-relacionales/