ANOMALIAS CODD

El proceso de normalizacin es un estndar que consiste, bsicamente, en un

proceso de conversin de las relaciones entre las entidades, evitando:
La redundancia de datos: Repeticin de datos en un sistema
Anomalas de actualizacin: inconsistencias de los datos como resultado de
datos redundantes y actualizaciones parciales.
Anomalas de Borrado: Perdidas no intencionadas de datos debido a que se
han borrado otros datos.
Anomalas de Insercin: Imposibilidad de adicionar en la base de datos
debido a la ausencia de otros datos.
Integridad de los Datos: La solucin a estas anomalas es la descomposicin
del esquema original en subesquema lo que seguimos con el proceso.
NORMALIZACION:
El proceso de normalizacin de bases de datos consiste en aplicar una serie de
reglas a las relaciones obtenidas tras el paso del modelo entidad-relacin al modelo
relacional. Las bases de datos relacionales se normalizan para:
Evitar la redundancia de los datos.
Evitar problemas de actualizacin de los datos en las tablas.
Proteger la integridad de los datos.
Tienen en cuenta los tres aspectos siguientes de los datos:
1) La estructura, que debe permitir representar la informacin
2) La manipulacin, a la que da apoyo mediante las operaciones de
actualizacin y consulta de los datos.
3) La integridad, es facilitada mediante el establecimiento de reglas de
integridad es decir, condiciones de los datos de cumplir.
VISIN FORMAL DE UNA RELACIN
Definimos formalmente las relaciones y otros conceptos que estn vinculados a
ellas, como por ejemplo dominio, esquema de relacin, etc.
Un dominio es un conjunto de valores atmicos. Por lo que respecta al modelo
relacional, atmico significa indivisible; es decir, que por muy complejo o largo que
sea un valor atmico, no tiene una estructuracin interna para un SGBD relacional.
Los dominios pueden ser de dos tipos:
1. Dominios predefinidos, que corresponde a los tipos de datos que
normalmente proporcionan los lenguajes de bases de datos, como por
ejemplo los enteros, las cadenas de caracteres, los reales, etc.
2. Dominios definidos por el usuario, que pueden ser ms especficos. Toda
definicin de un dominio debe constar, como mnimo, del nombre del
dominio y de la descripcin de los valores que forman parte de ste.

VISIN INFORMAL DE UNA RELACIN
Se puede obtener una buena idea intuitiva de lo que es una relacin si la
visualizamos como una tabla o un fichero. No tienen reglas establecidas, adems
no hay una organizacin de cmo va a ser el diseo o estructura.
En la figura se muestra la visualizacin tabular de una relacin que contiene datos
de empleados. Cada fila de la tabla contiene una coleccin de valores de datos
relacionados entre s; en nuestro ejemplo, son los datos correspondientes a un
mismo empleado. La tabla tiene un nombre (EMPLEADOS) y tambin tiene un
nombre cada una de sus columnas (DNI, nombre, apellido y sueldo). El nombre de
la tabla y los de las columnas ayudan a entender el significado de los valores que
contiene la tabla. Cada columna contiene valores de un cierto dominio; por
ejemplo, la columna DNI contiene valores del dominio nmeros DNI

EMPLEADOS
CEDULA NOMBRE APELLIDO SUELDO
1207568054 Tania Contreras 650
1711813616 Bladimir Carranco 740
0908515653 Xavier Mortensen 680
Primera Forma Normal (1FN)

La regla de la Primera Forma Normal establece que las columnas repetidas deben
eliminarse y colocarse en tablas separadas.
Poner la base de datos en la Primera Forma Normal resuelve el problema de los
encabezados de columna mltiples. Muy a menudo, los diseadores de bases de
datos inexpertos harn algo similar a la tabla no normalizada. Una y otra vez,
crearn columnas que representen los mismos datos. La normalizacin ayuda a
clarificar la base de datos y a organizarla en partes ms pequeas y ms fciles de
entender. En lugar de tener que entender una tabla gigantesca y monoltica que
tiene muchos diferentes aspectos, slo tenemos que entender los objetos
pequeos y ms tangibles, as como las relaciones que guardan con otros objetos
tambin pequeos.
Una tabla est en Primera Forma Normal si:
Todos los atributos son atmicos. Un atributo es atmico si los elementos
del dominio son indivisibles, mnimos.
La tabla contiene una llave primaria nica.
La llave primaria no contiene atributos nulos.
No debe existir variacin en el nmero de columnas.
Los Campos no llave deben identificarse por la llave (Dependencia
Funcional)
Esta forma normal elimina los valores repetidos dentro de una Base de datos.
Segunda Forma Normal (2FN)

Establece que todas las dependencias parciales se deben eliminar y separar dentro
de sus propias tablas. Una dependencia parcial es un trmino que describe a
aquellos datos que no dependen de la llave primaria de la tabla para identificarlos.
Una vez alcanzado el nivel de la Segunda Forma Normal, se controlan la mayora de
los problemas de lgica. Podemos insertar un registro sin un exceso de datos en la
mayora de las tablas.
Por ejemplo {DNI, ID_PROYECTO} HORAS_TRABAJO (con el DNI de un empleado
y el ID de un proyecto sabemos cuntas horas de trabajo por semana trabaja un
empleado en dicho proyecto) es completamente funcional dado que ni DNI
HORAS_TRABAJO ni ID_PROYECTO HORAS_TRABAJO mantienen la dependencia.
Sin embargo {DNI, ID_PROYECTO} NOMBRE_EMPLEADO es parcialmente
dependiente dado que DNI NOMBRE_EMPLEADO mantiene la dependencia.

Tercera Forma Normal (3FN)
La tabla se encuentra en 3FN si es 2FN y si no existe ninguna dependencia funcional
transitiva entre los atributos que no son clave.

Tercera forma normal (3FN)

Una tabla est normalizada en esta forma si todas las columnas que no son llave
son funcionalmente dependientes por completo de la llave primaria y no hay
dependencias transitivas. Comentamos anteriormente que una dependencia
transitiva es aquella en la cual existen columnas que no son llave que dependen de
otras columnas que tampoco son llave. Cuando las tablas estn en la Tercera Forma
Normal se previenen errores de lgica cuando se insertan o borran registros. Cada
columna en una tabla est identificada de manera nica por la llave primaria, y no
debe haber datos repetidos. Esto provee un esquema limpio y elegante, que es fcil
de trabajar y expandir.
Un ejemplo de este concepto sera que, una dependencia funcional X->Y en un
esquema de relacin R es una dependencia transitiva si hay un conjunto de
atributos Z que no es un subconjunto de alguna clave de R, donde se mantiene X->Z
y Z->Y.
Por ejemplo, la dependencia SSN->DMGRSSN es una dependencia transitiva en
EMP_DEPT de la siguiente figura. Decimos que la dependencia de DMGRSSN el
atributo clave SSN es transitiva va DNUMBER porque las dependencias
SSNDNUMBER y DNUMBERDMGRSSN son mantenidas, y DNUMBER no es un
subconjunto de la clave de EMP_DEPT. Intuitivamente, podemos ver que la
dependencia de DMGRSSN sobre DNUMBER es indeseable en EMP_DEPT dado que
DNUMBER no es una clave de EMP_DEPT.