Você está na página 1de 27

Normalizacin de Base De Datos

Lic. Emerson Galdmez


Objetivo
Conocer y aplicar las reglas bsicas de la normalizacin de las bases de datos
Normalizacin de Base De Datos

Uno de los pasos ms importantes en el diseo de una base de datos


consiste en asegurarse de que los datos se distribuyen correctamente entre
las tablas. Si las estructuras de datos sean correctos, y el resto de la
aplicacin (las consultas, los formularios, los informes, el cdigo entre otros)
se ver simplificada en gran medida. El nombre formal que recibe el diseo
apropiado de una tabla es de normalizacin de Base De Datos.
Bsicamente, la reglas de normalizacin estn encaminadas a eliminar
redundancias y inconsistencias de dependencia en el diseo de las tablas.

Problemas por diseo inadecuado.


Incapacidad para almacenar ciertos hechos.
Redundancia y, por tanto, posibilidad de inconsistencias.
Ambigedades.
Prdida de informacin.
Prdida de ciertas restricciones de integridad que dan lugar a inter
dependencias de los datos (dependencias funcionales).
Aparicin en la base de datos, como consecuencia de las redundancias, de
estados que no son vlidos en el mundo real; es lo que se le conoce como
anomalas de insercin, borrado, modificacin.
Por ejemplo:

Anomalas de insercin: dar de alta a un libro obliga a insertar en la base de


datos tantas tuplas como autores tenga el libro

Anomalas de modificacin: al cambiar el editorial de un libro obliga a


modificar todas las tuplas que corresponden a ese libro

Anomalas de borrado: El borrado de un libro obliga a borrar varias tuplas,


tantos como autores tenga ese libro
Trminos claves en la normalizacin

Dependencia funcional
Un descriptores Y se dice que depende funcionalmente de otro X, si y slo si
a cada valor de X le corresponde un nico valor de Y.
Ejemplo:

Empleado(cod_empl, salario, categora, ...)


Salario y categora dependen funcionalmente de cod_empl

cod_empl -> salario


cod_empl -> categora
Los atributos de lado izquierdo se llaman DERMINANTES
Primera forma normal

La celda de la tabla deben poseer valores simples y no se permiten ni grupos


ni arreglos
Todas las entradas a cualquier columna, deben de ser del mismo tipo
Dos filas en una tabla no deben ser idnticas
Cada columna debe tener un nombre nico, el orden no es importante
ID ACTIVIDAD CUOTA
100 Esqui 200
150 Natacion 50
175 Squash 50
200 Natacion 50
Segunda forma normal

Una afinidad est en segundo forma normal, si todos sus atributos que no son
claves dependen por ejemplo de la clave (esta forma se refiere a afinidades
con claves nicamente) si la clave es: SID, ACTIVIDAD
SID ACTIVIDAD CUOTA
100 Esqu 200
100 Golf 65
150 Natacin 50
175 Squash 50
175 Natacin 50
200 Golf 65
Resolucin:
Estu-act (SID, actividad)

SID ACTIVIDAD
100 Esqu
100 Golf
150 Natacin
175 Squash
175 Natacin
200 Golf
Act-cout (actividad, cuota) clave: actividad

ACTIVIDAD CUOTA
Esqu 200
Golf 65
Natacin 50
Squash 50
Natacin 50
Golf 65
Tercera forma normal.

Una afinidad est en tercera forma normal, si est en segundo forma normal y no tiene
dependencias transitivas.
Ejemplo:
VIVIENDA (SID, edificio, cuota)
Clave: SID
Dependencias funcionales
Edificio -> cuota
SID -> edificio -> cuota
SID EDIFICIO CUOTA
100 Randolph 1200
150 Ingersol 1100
200 Randolph 1200

Ya que edificio a cuota y SID Determina a edificio, se dice SID determina la


cuota indirectamente
Resolucin:
Estu-vivienda (SID, edificio) clave: SID
SID EDIFICIO
100 Randolph
150 Ingersol
200 Randolph
250 Pitkin
300 Randolph
Edif-cuota clave: edificio

EDIFICIO CUOTA
Randolph 1200
Ingersol 1100
Pitkin 1100
Ejemplo de Normalizacin
Ejemplo de Normalizacin

Digamos que se desea crear una tabla con la informacin de usuarios, los
datos a guardar son El nombre, la empresa, la direccin de la empresa,
algn e-mail, o bien URL si se tienen. En principio se puede iniciar
definiendo la estructura de una tabla como esta:(tabla sin normalizacin)
USUARIOS

NOMBRE EMPRESA DIR_EMPR URL1 URL2


Joe ABC 1 Work Lane abc.com xyz.com
Jill XYZ 1 Job Street abc.com xyz.com
Se puede decir que la anterior tabla est en nivel de formalizacin cero
porque ninguna regla de normalizacin ha sido aplicada. Observe los
campos URL1 y URL2 ?que haremos cuando la aplicacin necesitemos una
tercera URL? ?pensar en aadir otro campo/columna A tu tabla y tener que
reprogramar toda la entrada de datos de tu cdigo al programa de
aplicacin? Obviamente no, desea crear un sistema funcional que pueda
crecer y adaptarse fcilmente a los nuevos requisitos. Demos un vistazo a
las reglas de primer nivel de formalizacin-Normalizacin, Y las aplicaremos
a esta tabla
Primer nivel de formalizacin / normalizacin.
(F/N)

1. Eliminar los grupos repetitivos de las tablas individuales.


2. Crear una tabla separada por cada grupo de datos relacionados.
3. Identificar cada grupo de datos relacionados con una clave primaria.
?Observe que estamos rompiendo la primera regla cuando repetimos los
campus URL1 y URL2? ? Y qu pasa con la tercera regla, la clave primaria? La
regla tres bsicamente significa que tenemos que poner un campo tipo
contador auto incrementado para cada registro. De otra forma, ? Qu
pasara si tuviramos dos usuarios llamado Joe y queremos diferenciarlos?
Una vez que se aplicar el primer nivel de F/N nos encontraramos con la
siguiente tabla:

USERID NOMBRE EMPRESA DIR_EMPR URL


1 Joe ABC 1 Work Lane abc.com
1 Joe ABC 1 Work Lane xyz.com
2 Jill XYZ 1 Job Street abc.com
2 Jill XYZ 1 Job Street xyz.com
Ahora diremos tabla y est en primer nivel de F/N. Hemos solucionado el
problema de la limitacin del campo URL. Pero sin embargo vemos otros
problemas... Cada vez que introducimos un nuevo registro en la tabla
usuarios, tenemos que duplicar el nombre de la empresa y el usuario. No
slo nuestra BD crecer muchsimo, si no que ser muy fcil que la BD se
corrompa si escribimos mal alguno de los datos redundantes. Aplicaremos
pues el segundo nivel de F/N
Segundo nivel de F/N

Crear tablas separadas para aquellos grupos de datos que se aplican a varios
registros
Relacionar estas tablas mediante una clave externa.
Parado el campo URL en otra tabla, de forma que podamos aadir ms en el
futuro sin tener que duplicar los dems datos.
Tambin vamos a usar nuestra clave primaria para relacionar estos campos:
USERID NOMBRE EMPRESA DIR_EMPR
1 Joe ABC 1 Work Lane
2 Jill XYZ 1 Job Street

URL_ID REL_USERID URL


1 1 abc.com
2 1 xyz.com
3 2 abc.com
4 2 xyz.com

Você também pode gostar