Normalización de bases de datos

Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Normalización de bases de datos
La normalización de bases de datos es el proceso secuencial y cíclico para poner en orden y mejorar
las relaciones, así evitar la redundancia de datos, proteger la integridad de los mismos y corregir
anomalías de diseño.
La redundancia de datos es la causante de las anomalías de diseño, las cuales se presentan en la
inserción, modificación y eliminación de datos.
Anomalías de inserción: Esta ocurre cuando algunos atributos no pueden ser insertados a la relación
sin que existan otros atributos entre los cuales no deberían depender entre sí.
Por ejemplo, en el siguiente esquema tenemos la relación de dormitorios asignados a alumnos, y si
quisiéramos agregar un dormitorio, tendríamos que lo asignarlo a alguien.
Entonces vemos que no podemos insertar algunos datos si no existen otros datos que deberían ser
independientes.
Anomalías de modificación: Al modificar datos cuando existe redundancia, no se modifica el dato
duplicado en todas las instancias.
Por ejemplo, en la siguiente ilustración vemos que si modificamos un apellido esta no se modifica en
todas las instancias.
De esta manera terminaremos con dos alumnos diferentes.
Anomalías de eliminación: En estas anomalías podemos tener que al eliminar algunos atributos,
también se pierdan otros atributos que no queríamos eliminar.
Por ejemplo, en la siguiente relación se tiene un registro de las materias que cursan los estudiantes
y si por ejemplo un alumno quiere abandonar una materia, también se eliminaría toda la información
relacionada tanto del curso como del profesor.
1
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Para evitar estas anomalías debemos aplicar el proceso de normalización.
El proceso de normalización es un conjunto de reglas definidas, a las cuales se les conoce
como formas normales (NF Normal Forms).
5.1 Primera Forma Normal (1FN)
Una relación está en primera forma normal si no tiene grupos repetitivos.
Al observar el esquema anterior, vemos que tenemos un grupo repetitivo de cursos y en este caso,
el grupo repetitivo limita la cantidad de cursos que puede tomar un alumno, además, si el alumno se
inscribe en menos cursos, se está desperdiciando espacio.
Otro problema que tiene este grupo repetitivo es que si buscamos un dato, tendríamos que realizar
la búsqueda en tres atributos de cada tupla.
Podemos arreglar este problema si creamos una tupla para cada ocurrencia.
De esta manera ya no hay grupos repetitivos, sin embargo ahora tenemos otros problemas.
Tenemos llaves primarias duplicadas y además una redundancia de datos, para evitar estos
problemas, debemos tomar la relación original, dividirla en relaciones más pequeñas y agregar a los
grupos repetitivos la llave primaria de la relación original.
2
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Con esto ya tenemos a nuestra tabla en primera forma normal y a la tabla nueva debemos aplicar
de nuevo el proceso de normalización.
Vemos que en nuestra nueva tabla hay llaves duplicadas, pero en realidad es la llave primaria de
otra relación que hemos utilizado como vinculo, a estas llaves se les conoce como llaves foráneas
(FK).
Además vemos que en los cursos hay redundancia.
Esta redundancia la podemos eliminar agregando otra relación que contenga los nombres de las
materias y alguna llave primaria que sirva de enlace con la relación que estamos analizando.
3
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
De esta manera nuestra tabla quedaría con dos llaves foráneas, una de alumno y otra de código, a
esto se le conoce como llave primaria compuesta y a este tipo de tablas se les conoce como tablas
de relación.
Finalmente vemos que ya no hay tuplas repetidas, no hay grupos repetitivos, los atributos son
atómicos, no importa el orden de los datos y existe una llave primaria, por lo tanto, ya tenemos
nuestra tabla en 1FN.
5.2 Segunda Forma Normal (2FN)
Una relación esta en segunda forma normal si está en la primera forma normal y si todos los atributos
dependen de la llave primaria completa.
Nota: Si la llave primaria no es una llave compuesta, la relación ya está en segunda forma normal.
Veamos un ejemplo con una llave primaria compuesta.
Tenemos que la llave primaria compuesta es la unión de los atributos alumno y código. Los atributos
curso y calificación, son atributos dependientes.
En este caso tenemos que la calificación depende del alumno y del curso que está tomando, a esto
se le conoce como dependencia funcional completa.
Sin embargo el curso solamente de pende del código del curso y a esto lo llamaremos
como dependencia funcional parcial.
Entonces debemos tomar esa dependencia funcional parcial y moverla a otra relación, suprimiendo
de la relación original el atributo que es parcialmente dependiente.
4
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
De esta forma todas las relaciones que hemos obtenido dependerán completamente de la llave
primaria.
Vemos que en la tabla de curso tenemos una redundancia, esta redundancia debe ser eliminada de
esta relación.
En este caso vemos que los atributos dependen completamente de la llave primaria, así que ya están
en segunda forma normal.
5.3 Tercera Forma Normal (3FN)
A la tercera forma normal se le conoce como forma de la dependencia funcional transitiva y la
podemos definir como:
Una relación está en tercera forma normal si está en segunda forma normal y ningún atributo no
determinante depende transitivamente de la llave primaria.
Es decir, ningún atributo no primo depende funcionalmente de otro atributo no primo.
Veamos el siguiente caso: Tenemos una relación con los atributos A, B, C, D y supongamos que A,
B, determinan a C y C determina a D.
5
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Entonces identificamos que la llave primaria es A, B y los atributos dependientes son C y D. En este
caso los atributos A, B son atributos primos y los atributos dependientes C, D son atributos no primos.
Como D, depende de C tendremos que mover esa dependencia funcional a otra relación.
Y eliminar de la relación original el atributo dependiente.
Ahora tenemos que el atributo C en la segunda relación es una llave primaria, así que el atributo D ya
no depende de un atributo No Primo.
Veamos un ejemplo con datos. Supongamos que tenemos una relación donde se lleva registro de
los clientes, sus vendedores y los adeudos que tienen los clientes.
Vemos que no hay grupos repetitivos así que está en primera forma normal, la llave primaria no es
compuesta, por lo tanto está en segunda forma normal también.
Si tomamos esta relación e identificamos sus atributos con letras, veremos las siguientes
dependencias funcionales.
6
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
A (Cliente #) determina a B (Nombre), C (Apellido), D (Saldo del cliente), E (Vendedor del cliente).
También el atributo B (Vendedor #) determina a F (nombre del vendedor), G (Apellido del vendedor).
Además vemos que es una dependencia funcional transitiva ya que A determina a E y E determina
a F, G pero E no es un atributo primo y la dependencia F, G viola la regla de la tercera forma normal.
Así que tomamos la primera dependencia funcional y movemos a una nueva tabla la dependencia
funcional que viola la tercera forma normal, de esta manera nuestras tablas quedan enlazadas
mediante el atributo que generaba la transitividad.
Con esto nuestra relación ya está en tercera forma normal.
Teniendo nuestras relaciones normalizadas en la tercera forma normal, es suficiente en casi todos
los casos, pero esto no siempre es suficiente para eliminar la redundancia en nuestra base de datos.
5.4 Forma normal de Boyce y Codd (BCNF)
Aun en la tercera forma normal puede haber redundancia, son casos muy inusuales y se presenta
en casos donde hay más de una llave candidata y estas llaves candidatas tienen atributos en común,
para esos casos podemos ayudarnos de la forma normal de Boyce y Codd.
Una relación está en forma normal de Boyce y Codd si está en tercera forma normal y para cada
dependencia funcional no trivial que exista, el determinante es una súper llave.
Veamos un ejemplo con datos:
Supongamos que tenemos una relación donde se nos muestran los cursos en los que están inscritos
los alumnos y los profesores que los dictan.
Observaremos que un alumno puede estar inscrito en varios cursos y un curso puede ser dictado
por distinto profesor, esto quiere decir que necesitamos el alumno y el curso para poder determinar
el profesor.
7
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Por otro lado, vemos que siempre el mismo profesor dicta el mismo curso, es decir, el profesor
determina el curso.
Las llaves candidatas para esta relación serían Alumno, Curso y Alumno, Profesor.
Aquí el problema se presenta cuando un alumno se da de baja de una materia, perderíamos toda la
información de la tupla, o cuando llega un nuevo profesor a dictar una nueva materia, no podríamos
agregarla hasta que algún alumno se inscribiera en el curso.
Esta anomalía sucede porque la dependencia funcional Profesor, Curso viola la Forma Normal de
Boyce Codd. Profesor no es una Súper Llave.
Lo que debemos hacer es mover la dependencia funcional Profesor, Curso a una nueva relación y
en la relación original solamente dejamos el determinante de esta dependencia funcional y el resto
de los atributos.
Con esto nos quedan dos relaciones y además ya estarían en la forma normal de Boyce y Codd.
8
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
5.5 Cuarta forma normal (4 FN)
La cuarta forma normal, es la forma normal de las dependencias multivaluadas, así que primero hay
que ver que es una dependencia multivaluada.
Dependencia Multivaluada. En una relación con los atributos P, Q y V existe una dependencia
multivaludada de Q con respecto a P si los posibles valores de Q para un par de valores de P y V
dependen únicamente del valor de P.
Para que quede más claro veamos un ejemplo.
En la siguiente tabla tenemos nuestras tuplas P y Q, vemos que P y Q comparten los mismos
atributos A.
Debemos ver si existe una tupla V que tenga el mismo conjunto de atributos A que la tupla P, el
mismo conjunto de atributos B de la tupla P y el resto de los atributos de la nueva tupla debe ser el
resto de la tupla Q.
Sabemos que no importa el orden de las tuplas, así que si invirtiéramos el orden de P y Q y
aplicáramos el mismo proceso vamos a obtener una nueva tupla W con los mismos atributos A de la
tupla P y B y el resto de atributos de la tupla Q.
También observaríamos que hay una combinación de los atributos B con el resto de los atributos.
9
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Decimos entonces que A multidetermina a B. Este comportamiento debe ser constante en todas las
tuplas y para corregir este problema debemos mover a una nueva relación la dependencia funcional
multivaluada y en otra relación, dejaremos la dependencia funcional y el resto de los atributos.
Finalmente eliminar las tuplas repetidas.
Definiendo la cuarta forma normal, tenemos que una relación está en cuarta forma normal si está en
tercera forma normal o en forma normal de Boyce y Codd y en cada dependencia multivaluada no
trivial que exista, el determinante es una súper llave.
En la siguiente tabla, vemos que el alumno multidetermina al idioma, también, alumno multidetermina
al resto de los atributos.
Para corregir este problema, movemos la dependencia funcional Alumno – Idioma a una relación y
dejando en otra relación el determinante Alumno y el resto de los atributos.
10
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
En este caso, ambas dependencias funcionales s son triviales ya que la unión del determinante y
los elementos dependientes son iguales a la relación.
Por lo tanto estas dos relaciones ya están en cuarta forma normal.
5.6 Quinta forma normal (5 FN)
La quinta forma norma también es conocida como la forma normal de la proyección – unión.
Una relación está en quinta forma normal si está en cuarta forma normal y no puede ser
descompuesta no-aditivamente en relaciones más pequeñas.
No-aditiva significa que a la relación final no quedará con tuplas extra al unir naturalmente varias
relaciones.
Si una relación satisface la dependencia de unión natural, o sea que el conjunto de n relaciones es
igual a la relación original entonces NO está en quinta forma normal, ya que puede ser descompuesta
no aditivamente en relaciones más pequeñas.
Veamos un par ejemplos para aclarar estos conceptos.
Supongamos que tenemos una relación de empleados con el puesto que ocupan y el proyecto en el
que están asignados.
Realicemos 3 descomposiciones, una del empleado con su puesto, otra del empleado con su
proyecto y una más del puesto con el proyecto.
Tomamos estas tres proyecciones y realizamos una unión natural entre ellas (el orden de las uniones
naturales no importa).
Vemos que al unir las relaciones nos dan la relación original, por lo tanto la relación resultante no
está en quinta forma normal porque puede dividirse en relaciones más pequeñas de una forma no
aditiva.
11
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Sin embargo, las 3 proyecciones si están en quinta forma normal.
En el segundo caso supongamos que tenemos una productora con material audiovisual los cuales
se los vende a los canales de TV.
Y realizamos las mismas proyecciones como en la relación anterior tendremos las siguientes
proyecciones.
Si realizamos las operaciones correspondientes a la unión natura tendremos lo siguiente.
12
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Vemos que el resultado nos da dos tuplas que no cumplen con las condiciones de unión natural y
por lo tanto deben ser eliminadas del resultado.
Sin embargo aunque eliminamos esas dos tuplas, si comparamos el resultado con la relación original,
vemos que sigue habiendo una tupla demás, por lo tanto, estas relaciones no son iguales.
Esta descomposición fue una descomposición aditiva y no hay una dependencia de unión natural,
por lo tanto la relación original ya está en quinta forma normal.
Es muy importante la normalización de las relaciones en nuestra base de datos para evitar la
redundancia, garantizar la integridad de los datos y corregir anomalías de diseño. Pero, ¿debemos
normalizar todas las relaciones?
A continuación vemos un par de ejemplos que nos pueden ayudar a decidir cuándo debemos permitir
la redundancia.
5.6 Desnormalización de bases de datos
Desnormalizar significa que tendremos que permitir o generar redundancia para mejorar el
desempeño de la base de datos.
Si analizamos un caso de la parte de un sistema de facturación, donde tenemos en una relación los
datos de las facturas y en otra los detalles de estas facturas.
En estos detalles, se lleva el registro de los productos que se han vendido y por lo tanto tenemos
otra relación de productos.
El total de la factura sería un dato derivable que pudiéramos obtener de las operaciones sobre los
datos en nuestras relaciones.
Dicho lo anterior, si tenemos miles de facturas y miles de detalles, para sacar el total de las ventas
en cada factura, tendríamos que realizar muchísimas operaciones ¿no sería más sencillo almacenar
el total en la relación de las facturas, aunque este sea un campo derivable?
13
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Siguiendo con nuestro ejemplo, dijimos que tenemos una relación para llevar el registro de los
productos, otra para los detalles y una más para las facturas.
Supongamos que tenemos una venta e imprimimos la factura número 1, la cual ha quedado de la
siguiente manera.
¿Qué pasaría con esta factura si en un futuro aumentamos los precios de los productos, si
cambiamos el nombre de los productos y al aplicar estos cambios reimprimiéramos la factura número
1?
Como los datos han cambiado, al reimprimir la factura obtendríamos algo como lo siguiente.
Esta factura muestra datos incorrectos y por lo tanto no nos sirve, esto se debe a que hemos
normalizado por completo las relaciones.
Si hubiéramos mantenido atributos redundantes como por ejemplo, la descripción y el precio de los
productos, este problema no hubiera aparecido.
14
Instituto Tecnológico “Ayacucho”
Carrera: Sistemas Informáticos
Materia: Base de Datos I
Lic. Wendy Navia Chambi
Existen otras soluciones sin necesidad de recurrir a la redundancia pero las implicaciones serían que
nuestra base de datos sería más complicada y al tener que realizar muchísimas operaciones, el
proceso de recuperación de los datos sería muy lento.
Conclusión
Como vimos, la normalización de bases de datos es muy importante para corregir defectos de diseño,
así evitar la redundancia de datos y garantizar la integridad de estos.
Pero debemos analizar cuidadosamente cuando debemos permitir la redundancia para simplificar el
diseño y obtener mejor rendimiento de la base de datos.
Por el momento es todo, si tienes alguna pregunta déjala en los comentarios.
En la siguiente sección pasaremos a la de la implementación utilizando MySQL, así que suscríbete
a mi canal de Youtube para que no te pierdas de do, si tienes alguna pregunta déjala en los
comentarios.
15