aaaaa

Normalización blog.std-io.com

2014

Au

to

r:

Eb

erle

A

lex

an

de

r

Ba

se

s d

e d

ato

s

Normalización 2

Aaaaa

Autor: Eberle Alexander

Contenido

Notas de autor ............................................................................................................................ 3

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

Primera forma normal (1FN) ...................................................................................................... 4

Segunda forma normal (2FN) ..................................................................................................... 6

Tercera forma normal (3FN) ...................................................................................................... 7

Forma normal de Boyce-Codd .................................................................................................... 8

Cuarta forma normal (4FN) ........................................................................................................ 8

Quinta forma normal (5FN) ........................................................................................................ 9

Normalización blog.std-io.com

Normalización - Autor: Eberle Alexander 3

3

Notas de autor

La idea de éste documento es centralizar las distintas entradas de mi blog relacionadas con

bases de datos, de igual forma puedes ver el índice de entradas aquí ordenados por orden

de lectura.

También quiero comentar que la idea de este pdf es resumir y compilar todo el proceso de

normalización de la forma más clara y sencilla posible sin perder la esencia y el concepto

general.

Introducción

Hoy en día, y desde hace muchos años, nosotros usamos bases de datos para guardar

distintos tipos de datos que luego usaremos tiempo después en un programa; podríamos

decir que una base de datos es un conjunto de datos ordenados, pero estaríamos en un

error, cualquiera que conozca un poco sobre este tema podría recaer en cosas como "datos

que tienen un tipo" y otra clase de falencias que descartan -obviamente- esta definición. No

obstante lo antedicho, no vengo a detallar ni a inmiscuirme en lo profundo de la definición

de bases de datos, por lo que tomaremos por el momento a la señalada antes (si, esa cutre

definición) como el concepto de base de datos, por el momento.

En la década del 70', (como dije en entradas anteriores Winston Royce, creaba el ciclo de

desarrollo de software), el señor Edgar F. Codd publicaba un trabajo denominado "A

Relational Model of Data for Large Shared Data Banks", creando entonces el modelo

relacional que hoy en día aplica a todas las bases de datos (o debería hacerlo). No obstante,

uno suele encontrar software (de dudosa calidad) en internet como los conocidos sistemas

de foros Vbulletin, o SMF, que cuentan con serios problemas a la hora de cumplir los

criterios de normalización.

Codd, a la hora de diseñar el modelo relacional, construyó una serie de criterios para poder

verificar que las tablas estuvieran correctas, estas normas de corrección le permiten al

programador poder corregir y realizar una tabla normalizada.

Originalmente, estas formas normales o criterios de normalización eran 3, creadas por el

mismo Codd; no obstante, tiempo después se mejoró la 3FN (3º criterio o forma normal 3)

junto con Boyce nombrando la nueva FN como FNBC (Forma Normal Boyce-Codd).

Normalización - Autor: Eberle Alexander 4

4

Luego, para finalizar la trayectoria de agregados a las FN, se agregaron la 4º forma normal y

la 5º forma normal (otros dos criterios que deben ser cumplidos para que una tabla esté

normalizada), aunque –generalmente- se cree que con tener los primeros 3 criterios

cumplidos, una tabla ya está razonablemente normalizada. Es importante en ciertos casos

para bases de datos muy grandes aplicar las nuevas FN.

Quiero aclarar que, en mi blog, solo pondré un resumen de lo que es el proceso de

normalización, no obstante invito a todos a profundizar leyendo cualquiera de los siguientes

libros:

Date, C. J. (1999). An Introduction to Database Systems

Kent, W. (1983). A Simple Guide to Five Normal Forms in Relational Database Theory

Primera forma normal (1FN)

A modo de introducción, es conveniente señalar que si hablamos de normalización debes

comprender la importancia de normalizar tu base de datos. Cuando diseñas un sistema X, y

diagramas la base de datos, es probable que cometas una cierta cantidad de errores

intolerables que te lleven a tener una base de datos inestable, inconsistente, y con varios

problemas.

Normalizar la base de datos es como comprar un seguro a largo plazo, con una base de datos

normalizada te aseguras que en un futuro no tendrá problemas típicos.

Considera la importancia de normalizar la base de datos al comienzo, esto es, antes de tener

datos cargados; debido a que si luego tenemos la base de datos rellena de registros, hacer

cambios puede conllevar la ardua tarea de alterar una cantidad significativa de los mismos,

por lo que llevará a un costo muy superior al que puede tener normalizar la base de datos al

inicio.

Normalización - Autor: Eberle Alexander 5

5

Para poder comprenderlo, observe la imagen del post y notará que hay niveles de

normalización, y cuanto más superior sea el nivel de normalización de la base de datos mejor

será la misma.

El primer nivel es el 1FN. Debes saber que cuando hablamos de normalizar la base de datos,

nos referimos a normalizar cada una de las tablas de la base de datos y todas estas reglas, o

formas normales, son para procesarlas en tablas particulares.

Una tabla está en 1FN si y solo si:

Una tabla está en Primera Forma Normal si:

Todos los atributos son atómicos. Un atributo es atómico si los elementos del

dominio son indivisibles, mínimos.

La tabla contiene una clave primaria única.

La clave primaria no contiene atributos nulos.

Los Campos no clave deben identificarse por la clave (Dependencia Funcional)

Profundicemos el análisis de los ítems anteriores. El primer punto, “los atributos son

atómicos”, significa que un campo no posee varios valores -solo posee uno y solo un valor- y

que ese valor no puede ser dividido en dos campos; en otras palabras, con un ejemplo

sencillo podemos ilustrar la situación, así decimos que un campo "Nombre y Apellido" no es

atómico ya que cuenta con dos valores tales como el nombre y el apellido, y puede ser

dividido en dos campos, uno llamado nombre y el otro llamado apellido.

El segundo punto, hace referencia a que la tabla tiene una clave primaria y ésta es -clave

primaria- porque si un valor no se puede repetir y es único, quiere decir que no habrá dos

registros con el mismo valor para ese campo llamado “clave primaria”.

El tercer punto es bastante obvio, la clave primaria no puede contener un valor nulo, como

puede pasar en otros campos, tiene que haber un valor X.

El cuarto punto, tiene relación con que cada campo debe estar basado en la clave primaria;

en otras palabras, supongamos que tengo una tabla usuarios y pongo de clave primaria color

de pelo, y el resto de los campos son dni, nombre, apellido, etc. esto sería completamente

erróneo, ya que por el color de pelo no puedo deducir el nombre, el apellido y el dni de la

persona. En cambio, si pusiera de clave primaria DNI, esto sería correcto ya que el nombre,

el apellido y el color de pelo se pueden obtener basándose en el DNI, entonces todos los

demás campos están identificados por esa clave primaria.

Normalización - Autor: Eberle Alexander 6

6

Esto es -a grandes rasgos- los requisitos que debe tener una tabla para considerarse estar en

1FN.

Cada forma normal tiene un objetivo, el objetivo de ésta es eliminar los valores repetidos

dentro de una Base de Datos.

Segunda forma normal (2FN)

La segunda forma normal hace referencia a la dependencia funcional absoluta, sobre todo

cuando haya más de una clave primaria. Habíamos visto que para estar en 1FN era necesario

que todos los campos sean directamente dependientes de la clave primaria.

Primero, una tabla está en 2FN si y solo si la misma se encuentra en 1FN y cumple con el

siguiente requisito:

Los atributos que no forman parte de ninguna clave dependen de forma completa de la

clave principal. Es decir que no existen dependencias parciales. (Todos los atributos que no

son clave principal deben depender únicamente de la clave principal).

Esto quiere decir, que si tienes dos claves primarias, es necesario que cada campo de la tabla

que no sea clave primaria dependa de todas las claves primarias, si un campo solo depende

de una o algunas (pero no todas) las claves primarias, ese campo es erróneo.

Imaginemos una tabla con los siguientes campos:

id_proyecto dni_empleado horas_trabajadas nombre_empleado

(donde dni_empleado e id_proyecto son claves primarias)

Como podrán apreciar, las horas trabajadas en el proyecto son dependientes del id del

proyecto y del dni del empleado. No podemos saber las horas trabajadas únicamente

teniendo el id_proyecto o el dni_empleado, ya que no podremos saber con uno solo de

éstos cuantas horas trabajó en ese proyecto, por lo que ese campo es correcto; depende de

todas las claves primarias de la tabla y no tiene dependencias parciales. Pero veamos el

campo nombre_empleado, el mismo es erróneo, ya que depende del dni_empleado pero no

tiene ninguna dependencia con id_proyecto (no tiene nada que ver el nombre de un

empleado con el id de un proyecto), de modo que ese campo no debe estar en esa tabla

para que esa tabla esté en 2FN, ya que tiene dependencias parciales.

Normalización - Autor: Eberle Alexander 7

7

Tercera forma normal (3FN)

Recordemos que el proceso de normalización es un proceso sumamente importante que

prevé problemas futuros con una base de datos cuando la misma adquiera gran cantidad de

registros. El proceso consta en verificar y diseñar las distintas tablas para que cumplan los

requisitos de cada uno de los niveles (hasta el nivel que queramos llegar), cuando todas las

tablas cumplen los requisitos de un nivel, se dice que la base de datos está en ese nivel.

La tercera forma normal es para muchos el final del camino, ya que a no ser que hablemos

de una gran base de datos de importancia mayor, y que pueda darse el caso que se

necesiten los demás niveles, la mayoría de las bases de datos que se ven terminan sus tablas

en 3FN.

Una tabla está en 3FN si y solo si se encuentra en 2FN, y cumple con las siguientes

características:

No existe ninguna dependencia funcional transitiva entre los campos que no son clave.

Primero explicaremos qué es una dependencia funcional transitiva, recordemos que hay

campos que dependen de otros, y que en las FN anteriores los campos debían depender de

la clave primaria.

La dependencia funcional transitiva ocurre cuando un campo B depende un campo A, y un

campo C depende de un campo B, de modo que se asume que el campo C depende

transitoriamente del campo A.

A B C, B depende de A, C depende de B, entonces C depende de A.

Veamos la siguiente tabla con los siguientes campos:

fecha_nacimiento, edad, conducir

Fecha de nacimiento es la clave primaria en nuestra tabla, vemos que con la fecha de

nacimiento podemos conocer la edad, y con la edad podemos saber si alcanza la suficiente

para poder conducir; entonces podemos deducir solo con la fecha de nacimiento si puede

conducir o no, esto es una dependencia funcional transitiva.

De modo que una tabla que tenga dependencias de este tipo no está en 3FN, en cambio si la

tabla no tiene dependencias transitivas entonces está en 3FN.

Normalización - Autor: Eberle Alexander 8

8

Si un campo que no es clave primaria, y depende de otro campo que no es clave primaria;

entonces es muy probable que haya una dependencia transitiva (asumiendo que el segundo

campo que no es clave primaria sí tenga una dependencia sobre una clave primaria.)

Forma normal de Boyce-Codd

La FNBC es una forma normal que se puede considerar como una extensión de la tercera

forma normal, establece un requisito extra.

Una tabla se encuentra en FNBC si y solo si se encuentra en 3FN (por lo que también se

encuentra en 2FN y 1FN), y cumple el siguiente requisito:

No deben existir dependencias funcionales no triviales.

Esto quiere decir que todos aquellos campos que tienen campos que dependan de ellos, son

claves primarias.

En otras palabras que la tabla no tenga campos de este tipo sin ser clave primaria, ya que de

lo contrario habría una dependencia transitiva. No obstante es necesario tener mucho

cuidado al modificar esto ya que puede -al hacer claves primarias a campos de este estilo-

crear un conflicto con la 2FN suponiendo que no todos los campos sean dependientes del

mismo o que con ese campo haya otros campos que no dependan de las demás claves

primarias.

Ésta entrada es bastante simple y corta ya que no hay mucho que agregar a la explicación de

FNBC, es bastante sencilla y simplemente una extensión de la 3FN.

Cuarta forma normal (4FN)

La 4FN está relacionada con la dependencia multivalor, ésta es aquella dependencia que

ocurre con los distintos valores que puede tener un campo y que depende de un valor de un

campo X.

Esto es, cuando un campo tiene un valor X, otro campo puede tener alguno de muchos

valores que dependan de ese valor de ese campo.

Una tabla está en 4FN si y solo si, la misma se encuentra en 3FN, además cumple con el

siguiente requisito:

Normalización - Autor: Eberle Alexander 9

9

Para cada una de sus dependencias múltiples no funcionales, asumiendo X como el campo

de único valor -cuyo dependiente campo es Y (de múltiples valores)-, éste campo X es clave

candidata o grupo de claves candidatas.

En otras palabras tomando la idea de dependencia funcional multivalor, aquel campo con el

valor que puede resultar en la dependencia de varios posibles de otro campo, es una clave

primaria, o grupo de claves primarias.

Cuando un campo tiene un valor X, otro campo puede tener alguno de muchos valores que

dependan de ese valor de ese campo, la tabla estaría en 4FN si el campo del valor X es una

clave primaria o conjuntos de claves.

Por supuesto, esta forma normal solo será útil cuando existan dependencias funcionales

multivalor.

Quinta forma normal (5FN)

Ésta no es tan complicada como la 4FN, de hecho es bastante sencilla de explicar y se establece de la siguiente manera, una tabla se encuentra en 5FN si y solo si, se encuentra en 4FN y cumple el siguiente requisito:

No existen relaciones de dependencias no triviales que no siguen los criterios de las claves.

Una tabla que se encuentra en la 4FN -se dice que está en la 5FN- si, y sólo si, cada relación

de dependencia se encuentra definida por claves candidatas.

En otras palabras, cualquier relación de dependencia que haya en la tabla debe estar

compuesta por un campo o un grupo de campos que sean clave primaria, y el resto de los

campos no clave primaria dependan de los campos anteriores.

Por lo que no puede existir una relación de dependencia en la que no haya una clave

primaria y sean simples campos, esto también está apoyado por la 3FN donde se prevé el

problema de la dependencia transitiva.

Espero que hayan comprendido el desarrollo hasta éste punto, esto es, las 6 formas

normales (incluyendo la de B-C). Como sugerencia, quisiera agregar la lectura del artículo de

wikipedia de normalización y sobre todo en particular el tema de las reglas de Codd ya que

decidí no hacer una entrada puesto que la explicación de Wikipedia es simple y concreta.

Normalización - Autor: Eberle Alexander 10

10

Conclusión

Las formas normales son niveles de “calidad” (si se quiere) para las tablas, con ciertos

requisitos para que una tabla sea considerada como parte de ese nivel, cuando todas las

tablas de una db están en un nivel se considera que la db está en ese nivel.

Se deben ir modificando las tablas para cumplir los requisitos de cada nivel y así avanzar al

nivel siguiente.

Cuando tu base de datos se encuentre en nivel 3 o incluso FNBC, en ese momento uno debe

cuestionarse la necesidad de seguir escalando niveles, y si es que corresponde, se seguirán

escalando los niveles hasta tener una base de datos en 5FN (nivel máximo alcanzable).

Estos niveles evitan que la base de datos a la larga sufra inconvenientes graves con los datos

que lleva almacenados.

Es conveniente diseñar una base de datos normalizada de entrada y no esperar a que la base

esté llena de registros, porque luego los cambios estructurales llevarán un costo exagerado.

Confío en que el fatigado lector encuentre útil la información, colabore en subsanar errores

y facilite las tareas con base de datos, Los espero en la siguiente entrada de mi blog:

http://std-io.com.