- 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.
- La tabla no contiene atributos nulos.
- Si no posee ciclos repetitivos.
Una columna no puede tener múltiples valores. Los datos son atómicos. (Si a cada valor de X le pertenece un valor de Y, entonces a cada valor de Y le pertenece un valor de X).
Esta forma normal elimina los valores repetidos dentro de una BD.
2da Forma Normal (2FN): Dependencia Funcional. Una relación está en 2FN si está en 1FN y si los atributos que no forman parte de ninguna clave dependen de forma completa de la clave principal. Es decir que no existen dependencias parciales.
En otras palabras podríamos decir que la segunda forma normal está basada en el concepto de dependencia completamente funcional. Una dependencia funcional es completamente funcional si al eliminar los atributos A de X significa que la dependencia no es mantenida, esto es que A Є X, (X – {A}) -x-> Y. Una dependencia funcional es una dependencia parcial si hay algunos atributos que pueden ser removidos de X y la dependencia todavía se mantiene, esto es A Є X, (X – {A}) -> Y.
Por ejemplo {SSN, PNUMBER} HOURS es completamente dependiente dado que ni SSN HOURS ni PNUMBER HOURS mantienen la dependencia. Sin embargo {SSN, PNUMBER} ENAME es parcialmente dependiente dado que SSN ENAME mantiene la dependencia.
EJEMPLO 1:
1FN
La primera forma normal requiere que no existan atributos multi-valores, así como tampoco grupo de repetición. Un atributo multi-valor contiene más de un valor por ese campo en cada fila.
Consideremos la siguiente tabla referida a Cursos de estudiantes:
En esta tabla, el campo Curso es un campo multi-valor: no hay un valor simple para cada campo.
Ahora considere este otro ejemplo:
Los campos Curso1, Curso2 y Curso3 representan grupos repetitivos. Si aplicamos los requisitos de la Primer Forma Normal el ejemplo quedaría de la siguiente manera:
En los primeros 2 ejemplos, seleccionar un estudiante inscripto en algún curso es una tarea dificultosa. Digamos que quiero saber lo siguiente: “Todos los estudiantes inscriptos en el curso 3100”.
En el primer diseño, Ud. deberá tomar el campo Curso y analizarlo de alguna forma "por dentro" para saber si cumple o no con los requisitos de la búsqueda.
En el segundo diseño, deberá analizar 3 campos por separado para saber si el alumno está inscripto en el curso 3100.
En el tercer diseño, la consulta es tan simple como:
Select Nro de Registro from Cursos where Curso = 3100
2FN
La Segunda Forma Normal requiere que cualquier campo no integrante de la Clave Primaria, debería ser totalmente dependiente de la clave. Por ejemplo, considere la siguiente tabla de Cursos, donde Nro. de Registro y Curso componen la clave primaria.
El Nombre del estudiante no depende de toda la clave primaria, sino solo del Nro. de Registro. El Depto. es un campo que solo depende del Curso.
En consecuencia, estos datos deberían ser divididos en 3 tablas separadas, a saber:
En este ejemplo, el campo Nota es el único dependiente de la clave primaria completa.
EJEMPLO 2: Ejemplo simplificado de una base de datos para una pequeña biblioteca.
Esta tabla no cumple el requisito de la Primera Forma Normal (1FN) de sólo tener campos atómicos, pues el nombre del lector es un campo que puede (y conviene) descomponerse en apellido paterno, apellido materno y nombres. Tal como se muestra en la siguiente tabla.
1FN
Como se puede ver, hay cierta redundancia característica de 1FN.
La Segunda Forma Normal (2FN) pide que no existan dependencias parciales o dicho de otra manera, todos los atributos no clave deben depender por completo de la clave primaria. Actualmente en nuestra tabla tenemos varias dependencias parciales si consideramos como atributo clave el código del libro.
Por ejemplo, el título es completamente identificado por el código del libro, pero el nombre del lector en realidad no tiene dependencia de este código, por tanto estos datos deben ser trasladados a otra tabla.
2FN
La nueva tabla sólo contendrá datos del lector.
Hemos creado una tabla para contener los datos del lector y también tuvimos que crear la columna CodLector para identificar unívocamente a cada uno. Sin embargo, esta nueva disposición de la base de datos necesita que exista otra tabla para mantener la información de qué libros están prestados a qué lectores. Esta tabla se muestra a continuación:
No hay comentarios:
Publicar un comentario