FUNDAMENTOS DE BASES DE DATOS

SEMANA 3
Normalización de bases de datos

Todos los derechos de autor son de la exclusiva propiedad de IACC o de los otorgantes de sus licencias. No está
permitido copiar, reproducir, reeditar, descargar, publicar, emitir, difundir, poner a disposición del público ni 1
ESTE
utilizarDOCUMENTO
los contenidos paraCONTIENE LAdeSEMANA
fines comerciales 3
ninguna clase.
 2
ESTE DOCUMENTO CONTIENE LA SEMANA 3
ÍNDICE

NORMALIZACIÓN DE BASES DE DATOS ............................................................................................... 4

OBJETIVOS ESPECÍFICOS ...................................................................................................................... 4
INTRODUCCIÓN ................................................................................................................................... 4
1. NORMALIZACIÓN ........................................................................................................................ 5
1.1. DEFINICIÓN.......................................................................................................................... 5
1.2. CARACTERÍSTICAS................................................................................................................ 5
1.3. OBJETIVOS DE LA NORMALIZACIÓN .................................................................................... 6
1.4. DEPENDENCIA FUNCIONAL ................................................................................................. 6
1.4.1. CONCEPTO ................................................................................................................... 7
1.4.2. FINALIDAD ................................................................................................................... 7
1.5. FORMAS NORMALES ........................................................................................................... 8
1.5.1. PRIMERA FORMA NORMAL: 1FN ................................................................................ 8
1.5.2. SEGUNDA FORMA NORMAL: 2FN ............................................................................. 10
1.5.3. TERCERA FORMA NORMAL: 3FN ............................................................................... 11
1.5.4. CUARTA FORMA NORMAL: 4FN ................................................................................ 13
1.5.5. QUINTA FORMA NORMAL: 5FN ................................................................................ 14
COMENTARIO FINAL.......................................................................................................................... 14
REFERENCIAS ..................................................................................................................................... 15

3
ESTE DOCUMENTO CONTIENE LA SEMANA 3
NORMALIZACIÓN DE BASES DE DATOS

OBJETIVOS ESPECÍFICOS
 Analizar las características y objetivo del proceso de normalización de bases de datos.

 Aplicar formas normales en el diseño de bases de datos.

INTRODUCCIÓN
En la presente semana se abordará el tema de normalización de bases de datos, dado que al
diseñarlas es muy común que existan errores o no se dimensione que el diseño permite el
almacenamiento de redundancias. Es por eso que surge este proceso llamado normalización, con
el que se busca dejar el diseño lo más cercano posible a la realidad del negocio que se modeló a
través del mismo, pero eliminando cualquier tipo de redundancias.

Para abordar el tema, primeramente se conocerá su definición, objetivo, finalidad y luego se

concluye con cada una de las formas normales que estipula el proceso de normalización.

4
ESTE DOCUMENTO CONTIENE LA SEMANA 3
 1. NORMALIZACIÓN
Cuando se diseñan bases de datos, es posible que en algunas ocasiones no se evidencien errores,
los que originan que un mismo dato pueda estar repetido en varias tablas, que estos no
representen exactamente la información que se buscará más adelante o bien que se den
operaciones inconsistentes sobre los datos. Ante esta posibilidad de error, es necesario, luego del
diseño de datos, ir al proceso llamado normalización.

1.1.DEFINICIÓN
Según Ramos, Ramos y Montero (2006, p.75), la normalización es “una técnica para diseñar la
estructura lógica de los datos de un sistema de información en el modelo relacional”. Fue creado
por E. F. Codd en el año 1972. Ricardo (2009, p.166) complementa esta definición indicando que la
normalización “es el proceso de eliminación de redundancias en un tabla para que sea más fácil de
modificar”.

Por ejemplo, si dentro de la base de datos se tiene una tabla “cliente”, que almacena todos los
datos del cliente, y donde su clave única es el RUT, y luego una tabla “factura”, donde de cada
cliente se registran las compras que ha hecho; en esta tabla “factura” no es necesario que
almacene nuevamente el RUT del cliente, nombres, apellidos, etc. Bastará con registrar el RUT del
cliente al cual pertenece cada factura y con eso es posible buscar el resto de datos del mismo en la
tabla “cliente”.

 Si se tomara en cuenta los recursos, resulta importante el proceso

de normalización de bases de datos, ya que de nada vale
almacenar datos repetidos, cuando estos van a ocupar más
espacio del debido en el disco y pueden generar problemas de
mantención.

1.2. CARACTERÍSTICAS
Si se toma en cuenta lo publicado por Ricardo (2009), entre las características que se pueden
mencionar para la normalización, se tendría:

5
ESTE DOCUMENTO CONTIENE LA SEMANA 3
  Es un proceso que simplifica los datos, es decir, al aplicar normalización se pueden tener
menos datos, o estos estar organizados de una forma más simple y adecuada.
 Ahorra espacio en disco, ya que al simplificar datos se almacenan menos y por ende se
utiliza menos espacio de disco.
 Elimina datos repetidos, al validar que se guarden solo los datos una sola vez, y dado que
través de las relaciones entre entidades se llegua a determinado dato, no se tienen datos
repetidos.
 Elimina errores lógicos, al revisar minuciosamente el diseño que se elaboró.
 Presenta datos de forma ordenada, pues solo se almacenan los que se requieren y de
forma adecuada.
 Elimina dependencias no deseadas entre atributos, entendiendo como dependencia a la
relación entre atributos de una misma tabla. De esta forma no se contará con relaciones
entre atributos que no sean adecuadas.

A medida que se conozcan cada una de las formas normales, se podrán evidenciar estas
características.

1.3.OBJETIVOS DE LA NORMALIZACIÓN
Ricardo (2009) especifica que el objetivo principal de la normalización es la producción de un
conjunto estable de relaciones, que sea un modelo casi exacto a las operaciones que lleva la
empresa.

Al aplicar la normalización, se logra tener un diseño flexible, que permite a futuro incorporar
extensiones que faciliten la creación de nuevos elementos. Además, este proceso evita la
redundancia de datos para así ahorrar espacio e impedir inconsistencias.

Como último objetivo, Ricardo (2009) menciona que busca lograr la integridad de los datos, a
través de la eliminación de anomalías en las operaciones con estos, tomando en cuenta que una
anomalía la define como un estado incompleto de la base de datos. Dicho de otra forma, es
descomponer aquellas relaciones que presentan anomalías o inconsistencias para producir
relaciones más pequeñas y mejor estructuradas.

1.4. DEPENDENCIA FUNCIONAL

En bases de datos, es posible encontrarse con conceptos del área de álgebra y de lógica
matemática. Tal es el caso del concepto de dependencia funcional, que será descrito a
continuación.

6
ESTE DOCUMENTO CONTIENE LA SEMANA 3
 1.4.1. CONCEPTO

Según Ramos, Ramos y Montero (2006, p.75), la dependencia funcional “es una relación entre
atributos de una misma relación (tabla)”; donde si se extrapola a lógica matemática, se podría
definir de la siguiente forma:

Tomando que X e Y son atributos de una relación R, se dice que Y es funcionalmente

dependiente de X (denotando esto por: X  Y). Si cada valor en X tiene un único valor en Y,
tanto X como Y pueden constar de uno o varios atributos.

Llevando este concepto a términos más cercanos, la dependencia funcional es aquella que exhibe
la conexión entre uno o más atributos pertenecientes a una base de datos. Se representa a través
de flechas que unen dichos atributos, donde es importante acotar que en la normalización se hace
imprescindible identificar estas dependencias funcionales para así contar con una base de datos
eficiente.

1.4.2. FINALIDAD

Ramos, Ramos y Montero (2006) mencionan que la finalidad de las dependencias funcionales es
facilitar la identificación y eliminación de redundancias de los datos que se encuentran presentes
en las tablas de una base de datos relacional. Esto se da porque a través de las dependencias
funcionales se determina las interrelaciones entre dos o más atributos, y a partir de ellas será
posible observar si se tienen o no redundancias.

 En el siguiente video se puede observar una explicación

sobre lo visto hasta ahora:

https://goo.gl/qtK0Vv

7
ESTE DOCUMENTO CONTIENE LA SEMANA 3
 1.5. FORMAS NORMALES
Para llevar a cabo el proceso de normalización, existen normas o reglas que determinan cómo se
hace este proceso. Ramos, Ramos y Montero (2006) indican que estas reglas consisten en la
aplicación de una operación que toma como entrada una relación, pero genera como resultado
dos o más relaciones. Para la normalización, existen varias formas normales, donde en estricto
rigor las tres primeras formas normales se consideran suficientes para la mayoría de las bases de
datos que se tienen (en este curso se abordará hasta la quinta forma normal). A continuación se
mostrará un gráfico en el cual Ricardo (2009) ilustra las formas normales existentes.

Fuente: Ricardo (2009, p. 224).

1.5.1. PRIMERA FORMA NORMAL: 1FN

La primera forma normal o 1FN es obligatoria para que pueda existir un esquema relacional,
donde al implementar esta forma normal se garantiza que no se repitan grupos en cada tupla.
Entendiendo como tupla un registro de una tabla de la base de datos. Si se piensa en una tabla
como una hoja de Excel, donde las columnas son los campos y las filas cada registro, una tupla
sería cada fila. Ahora bien, Ricardo (2009, p.171) comenta lo siguiente: “Una relación está en
primera forma normal (1FN) si, y solo si, cada atributo tiene valor sencillo para cada tupla”.

Para entender mejor este concepto, se partirá con el siguiente ejemplo, en el que se observa una
tabla que registra los datos de proveedores. Sobre este se aplicará la primera forma normal.

8
ESTE DOCUMENTO CONTIENE LA SEMANA 3
CodProveedor Nombre DirProveeor TlfProveedor
001 Marco Polo Caupolicán 9401, RM +56226302590
002 Evercrisp Los Cerrillos 999, RM +56226407080
+56226451232
003 Carozzi Camino Longitudinal Sur - Av Diego Portales +56222259957
5201, RM +56222599564

Si se analiza lo que indica estar en primera forma normal, inmediatamente se observa que no
cumple con esta, porque hay proveedores que tienen más de un número de teléfono. Para
resolver esto, será necesario crear otra tabla que almacene los teléfonos que tenga este
proveedor, para no limitar en cada campo (columnas para el caso analizado) la cantidad de
números de teléfono.

La primera tabla tendría los siguientes datos:

CodProveedor Nombre DirProveeor

001 Marco Polo Caupolicán 9401, RM
002 Evercrisp Los Cerrillos 999, RM
003 Carozzi Camino Longitudinal Sur - Av Diego Portales 5201, RM

Y la segunda tendría el código del proveedor y el teléfono.

CodProveedor TlfProveedor
001 +56226302590
002 +56226407080
002 +56226451232
003 +56222259957
003 +56222599564

Como se observa en la primera tabla, se mantiene información única en cada tupla, y en la

segunda igualmente. Si se quisiera agregar un nuevo teléfono a algunos de esos proveedores,
bastaría con agregar un nuevo registro con el código del proveedor y el teléfono que se desea
agregar.

Luego de abordar el ejemplo, se pueden analizar las características que menciona Ricardo (2009)
para la primera forma normal:

 Su definición determina la prohibición de los atributos con múltiples valores compuestos y

sus combinaciones.
 Esta forma establece que los dominios (posibles valores) de los atributos solo incluyen
valores simples o indivisibles, tal como se vio en teléfono, que quedó uno solo por
proveedor.
 Este tipo de relación forma parte de la definición de cada relación.

9
ESTE DOCUMENTO CONTIENE LA SEMANA 3
 1.5.2. SEGUNDA FORMA NORMAL: 2FN

Ricardo (2009) indica que para que se cumpla esta forma normal, primeramente debe estar en
1FN (primera forma normal), y además cumplir con que cada atributo que no sea clave dependa
en forma funcional completa de cualquiera de las claves. Depender en forma funcional completa
implica que todos los atributos dependen directamente de la clave primaria.

Ramos, Ramos y Montero (2006) explican que si se tiene una relación en 1FN y la clave primera
está formada por solo un atributo, ya estaría en 2FN también, por lo que el ejemplo visto
anteriormente cumpliría con esto:

CodProveedor Nombre DirProveeor

001 Marco Polo Caupolicán 9401, RM
002 Evercrisp Los Cerrillos 999, RM
003 Carozzi Camino Longitudinal Sur - Av Diego Portales 5201, RM

Ahora bien, si se tuviera una relación en 1FN, pero la clave primaria estuviera formada por más de
un atributo, la situación cambiaría. Por ejemplo, si se tuviera la siguiente tabla que registra los
precios de productos por proveedor de un minimarket:

CodProducto Nombre Proveedor DirProveedor Precio Área DsctoProveedor

001 Papas Marco Caupolicán 650 Snacks 1%
Fritas Polo 9401, RM
001 Papas Evercrisp Los Cerrillos 550 Snacks 2%
Fritas 999, RM
002 Ramitas Evercrisp Los Cerrillos 600 Snacks 3%
999, RM
003 Doritos Evercrisp Los Cerrillos 500 Snacks 3%
999, RM
004 Cabritas Evercrisp Los Cerrillos 440 Snacks 2%
dulces 999, RM
005 Coca Coca Cola Avenida 700 Bebestible 1%
Cola Zero Andina Miraflores
9153, RM

La clave primaria de la tabla anterior está dada por el CodProducto más el Proveedor, viéndose
por ejemplo que el producto 001 es vendido por 02 proveedores. Pero existen atributos que no
dependen de ambas claves primarias. Por ejemplo, la dirección del proveedor no depende del
código del producto, además el área a la que pertenece el producto no depende del proveedor,
sino de la categoría que le otorga el dueño del minimarket. Sin embargo, el descuento que se
pueda ofrecer para determinado producto sí depende del producto como tal y su proveedor.
Además, es por eso que se hace necesario crear otras tablas o relaciones. Quedando de la
siguiente forma:

10
ESTE DOCUMENTO CONTIENE LA SEMANA 3
 Nombre DirProveedor
Marco Polo Caupolicán 9401, RM
Evercrisp Los Cerrillos 999, RM
Coca Cola Andina Avenida Miraflores
9153, RM

CodProducto Nombre Área

001 Papas Fritas Snacks
002 Ramitas Snacks
003 Doritos Snacks
004 Cabritas Snacks
dulces
005 Coca Cola Bebestible
Zero

CodProducto Nombre Proveedor Precio DsctoProveedor

001 Papas Fritas Marco Polo 650 1%
001 Papas Fritas Evercrisp 550 2%
002 Ramitas Evercrisp 600 3%
003 Doritos Evercrisp 500 3%
004 Cabritas Evercrisp 440 2%
dulces
005 Coca Cola Coca Cola 500 1%
Zero Andina

Según Ramos, Ramos y Montero (2006), se pueden determinar las siguientes características para
la segunda forma normal 2FN:

 Si la clave está compuesta por un solo atributo, ya existe seguridad de que se cumple con
esta forma normal.
 Basa su funcionamiento en las dependencias funcionales.
 Esta forma normal permite eliminar redundancias en cuanto a que se asegura que ningún
atributo sea determinado solo por una parte de la clave.

1.5.3. TERCERA FORMA NORMAL: 3FN

Según Ramos, Ramos y Montero (2006, p.81), “una relación está en tercera forma normal, si, y
solo si, está en 2FN y, además, cada atributo que no está en la clave primaria no depende
transitivamente de la clave primaria”. Esto quiere decir que los atributos no dependen unos de

11
ESTE DOCUMENTO CONTIENE LA SEMANA 3
otros, sino que dependen únicamente de la clave, la cual puede estar formada por uno o más
atributos.

Se puede ver la transitividad en la siguiente dependencia: X  Z es transitiva, si existe X  Y, Y 

Z, siendo tanto X como Y atributos de una misma relación.

Para entender mejor esto, observe la siguiente tabla:

CodProducto Nombre Proveedor DirProveeor Precio

001 Papas Fritas Marco Polo Caupolicán 9401, RM 650
001 Papas Fritas Evercrisp Los Cerrillos 999, RM 550
002 Ramitas Evercrisp Los Cerrillos 999, RM 600
003 Doritos Evercrisp Los Cerrillos 999, RM 500
004 Cabritas dulces Evercrisp Los Cerrillos 999, RM 440
005 Cheezel Evercrisp Los Cerrillos 999, RM 500

La clave primaria de la tabla anterior está dada por el CodProducto más el Proveedor, por cuanto
se ve por ejemplo que el producto 001 es vendido por 2 proveedores, pero existen atributos que
no dependen de ambas claves primarias, por ejemplo la dirección del proveedor no depende del
código del producto, aun cuando en el empaque pueda salir esta dirección. Es por eso que se hace
necesario crear otras tablas o relaciones, quedando de la siguiente forma:

Nombre DirProveeor
Marco Polo Caupolicán 9401, RM
Evercrisp Los Cerrillos 999, RM

CodProducto Nombre Proveedor Precio

001 Papas Fritas Marco Polo 650
001 Papas Fritas Evercrisp 550
002 Ramitas Evercrisp 600
003 Doritos Evercrisp 500
004 Cabritas dulces Evercrisp 440
005 Cheezel Evercrisp 500

Según Ramos, Ramos y Montero (2006), se pueden determinar las siguientes características para
la tercera forma normal 3FN:

 Basa su funcionamiento en la dependencia funcional transitiva.

 Esta forma normal elimina las redundancias de manera que no existan dependencias
transitivas entre atributos.
 Con el pasar de los años se considera como normalización satisfactoria llegar hasta esta
forma normal.

12
ESTE DOCUMENTO CONTIENE LA SEMANA 3
 1.5.4. CUARTA FORMA NORMAL: 4FN

Para poder abordar esta cuarta forma normal, es importante conocer la forma FNBC. Ricardo
(2009, p. 177) indica que esta es un poco más estricta que la 3FN y la define explicando que “una
relación está en forma Boyce/Codd (FNBC) si, siempre que existe una dependencia funcional no
trivial X  A, entonces X es una superclave”. Se entenderá por superclave uno o varios atributos
que identifican una entidad única, donde si pensamos en clientes la superclave sería el número de
RUT.

Ahora, la cuarta forma normal 4FN es definida por Ramos, Ramos y Montero (2006) como una
relación que está en FNBC, y donde no existen dependencias multivaluadas. Una dependencia es
multivaluada si teniendo los atributos A y B, se permite que un valor de A tenga asociado
diferentes valores de B.

Para entender un poco mejor esta forma normal, se tiene el siguiente ejemplo:

Categoría Proveedor Producto

Snack Evercrisp Papas fritas
Snack Marco Polo Papas fritas
Snack Lays Papas fritas
Bebestibles Cachantun Agua
Bebestibles Vital Agua
Bebestibles Puyehue Agua

Analizando la tabla anterior, la clave primara la forma la categoría más proveedor más producto,
sin embargo, según la cuarta forma normal se tendrían redundancias, porque se repiten categorías
y productos. Es por eso que para cumplir con esta forma normal se debería tener lo siguiente:

Categoría Producto
Snack Papas fritas
Bebestibles Agua

Categoría Proveedor
Snack Evercrisp
Snack Marco Polo
Snack Lays
Bebestibles Cachantun
Bebestibles Vital
Bebestibles Puyehue

13
ESTE DOCUMENTO CONTIENE LA SEMANA 3
 1.5.5. QUINTA FORMA NORMAL: 5FN

Ramos, Ramos y Montero (2006, p.84) indican que “una relación se encuentra en 5FN si, y solo si,
toda dependencia de reunión en la relación es una consecuencia de las claves candidatas”. Esta
forma normal implica dividir las tablas en muchas subtablas, lo cual a nivel práctico no es tan
utilizado, ya que origina muchas divisiones.

 Para profundizar en la normalización, se recomienda

consultar el siguiente video:

https://goo.gl/8dw5TS

COMENTARIO FINAL
Al finalizar la semana de estudio, se pudo evidenciar la importancia que reviste el proceso de
normalización de una base de datos, el hecho de velar por la integridad de la misma, así como
buscar evitar las redundancias; lo que hace que se tenga un mejor diseño, en el cual los datos sean
almacenados adecuadamente.

De nada sirve tener una base de datos con una cantidad de data que no tiene utilidad, o que esté
repetida en muchos sitios. Con esto lo único que se lograría sería desperdiciar espacio en disco, y
hacer el proceso de registro y recuperación de datos más lento.

Es importante tomar en cuenta que tener una base de datos normalizada hasta la tercera forma
normal es óptimo, y lo más común en la práctica es que se encuentren la mayoría de las bases de
datos hasta esta forma. Otro punto importante es que el éxito en el proceso de normalización está
dado por las continuas prácticas sobre base de datos, donde puede que la primera no se logre
tener normalizada de forma óptima, pero trabajando sobre varias sí se lograrán mejores
resultados.

14
ESTE DOCUMENTO CONTIENE LA SEMANA 3
REFERENCIAS
Ramos, M.; Ramos, A. y Montero, F. (2006). Sistemas gestores de bases de datos. Madrid, España:

McGraw-Hill.

Ricardo, C. (2009). Bases de datos. México DF, México: McGraw-Hill.

PARA REFERENCIAR ESTE DOCUMENTO, CONSIDERE:

IACC (2016). Normalización de bases de datos. Fundamentos de Bases de Datos. Semana 3.

15
ESTE DOCUMENTO CONTIENE LA SEMANA 3
 16
ESTE DOCUMENTO CONTIENE LA SEMANA 3