lunes, 21 de diciembre de 2015

La Tercera Forma Normal (3FN)


La tercera forma normal (3NF) es una forma normal usada en la normalización de bases de datos. La 3NF fue definida originalmente por E.F. Codd en 1971. La definición de Codd indica que una tabla está en 3NF si y solo si las dos condiciones siguientes se mantienen:

  • La tabla está en la segunda forma normal (2NF)
  • Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave primaria

Cada atributo debe representar un hecho acerca de la clave, la clave entera, y nada excepto la clave. La versión 3NF de la definición es más débil que la variación de BCNF de Date, pues el anterior se refiere solamente a asegurarse de que los atributos no-clave son dependientes en las claves. Los atributos primarios (que son claves o partes de claves) no deben ser funcionalmente dependientes en absoluto; cada uno de ellos representa un hecho sobre la clave en el sentido de proporcionar parte o toda la clave en sí misma. Debe ser observado que esta regla se aplica solamente a los atributos funcionalmente dependientes, Ya que aplicándola a todos los atributos prohibiría implícitamente claves de candidato compuestas, puesto que cada parte de cualquiera de tales claves violaría la cláusula de "clave completa".

Ejemplo: Tabla en 2FN > 3FN

                                              Ganadores del torneo

Torneo
Año
Ganador
Fecha de nacimiento del ganador
Indiana Invitational
1998
Al Fredrickson
21 de julio de 1975
Cleveland Open
1999
Bob Albertson
28 de septiembre de 1968
Des Moines Masters
1999
Al Fredrickson
21 de julio de 1975
Indiana Invitational
1999
Chip Masterson
14 de marzo de 1979

Tabla en 3FN:

Ganadores del torneo

Torneo
Año
Ganador
Indiana Invitational
1998
Al Fredrickson
Cleveland Open
1999
Bob Albertson
Des Moines Masters
1999
Al Fredrickson
Indiana Invitational
1999
Chip Masterso


Fecha de nacimiento del jugador

Jugador
Fecha de nacimiento
Chip Masterson
14 de marzo de 1977
Al Fredrickson
21 de julio de 1975
Bob Albertson
28 de septiembre de 1968


Ejemplo:





Fallas en Tercera forma Normal (3FN) 


Incluso las afinidades en tercera forma normal pueden tener anomalías.  Considere la siguiente afinidad ASESOR. Suponga que los requerimientos que sustentan esta afinidad son que un estudiante (SID), pueda tener una ó más especialidades, una especialidad puede tener varios miembros de la facultad (nombreF) como consejeros, y un miembro de la facultad (nombreF), sólo imparte asesoría en una área de especialidad.





Puesto que los estudiantes pueden tener varias especialidades, SID, no determina la especialidad.  Como los estudiantes pueden tener varios asesores, SID tampoco determina nombre F.  SID por si mismo no puede ser una clave.
La combinación (SID, especialidad) determina nombre F y la combinación (SID, nombre F), determina especialidad.  Cualquiera de las combinaciones puede ser una clave.  Dos ó mas atributos o conjuntos de atributos que puedan ser una clave, se denominan claves candidatas.  Cualquiera de las candidatas que se seleccione para ser la clave se denomina clave primaria.

ASESOR está en primera forma normal.  También está en segunda forma normal, pues cualquier atributo que no es clave depende de toda la clave (sin importar cual clave candidata se seleccione).  También está en tercera forma normal porque no tiene dependencias transitivas.  A pesar de todo esto tiene anomalías por modificación.

Suponga que estudiante 300 deja la escuela, si quita la tupla de estudiante 300 se perderá el hecho de que Perls imparte asesoría en psicología.  Ésta es una anomalía de eliminación.  En forma similar ¿Cómo se almacena el hecho de que  Keynes asesor en economía? No es posible, hasta que un estudiante se inscribe en tal materia.  Esta es una anomalía de inserción.

Situaciones como la anterior conducen a la definición de la forma normal de Boyce-Codd (BCNF):  Una afinidad está en BCNF si cada determinante es una clave candidata.  ASESOR no está en BCNF puesto que tiene un determinante, nombre F, que no es una clave candidata.

ASESOR puede descomponerse en dos afinidades que no tengan anomalías.


La Segunda Forma Normal (2FN)

La regla de la 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 término que describe a aquellos datos que no dependen de la clave de la tabla para identificarlos. 

Una de las mayores desventajas de la normalización es el tiempo que lleva hacerlo. La mayoría de la gente está demasiado ocupada, y emplear tiempo para asegurarse de que sus datos están normalizados cuando todo funciona más o menos bien, parece ser un desperdicio de tiempo. Pero no es así. Usted tendrá que emplear más tiempo arreglando una base de datos no normalizada que el que emplearía en una normalizada. 

Al haber alcanzado la Segunda Forma Normal, usted puede disfrutar de algunas de las ventajas de las bases de datos relacionales, por ejemplo:

  • Puede añadir nuevas columnas a una tabla sin afectar a las demás tablas. 
  • Lo mismo aplica para las otras tablas.
  • Alcanzar este nivel de normalización permite que los datos se acomoden de una manera natural dentro de los límites esperados. 
Ejemplos:

 


Como ya habíamos utilizado este ejemplo en la entrada anterior, ahora podemos utilizar la 2FN para poder administrar mejor los datos.



 



Esto denota la diferencia que existe entre la 1FN que incluía los datos del lector,en la tabla Libro sin que exista dependencia de código entre ellos.

Otro Ejemplo:



 



El primary key de la tabla alumnos es el N° de DNI por lo que en tabla asistencia para vincular al alumno con la asistencia, solo se necesitaría el N° de  DNI.


Primera Forma Normal en Bases de Datos (1FN)

El proceso de normalización de bases de datos consiste en aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
  • Evitar la redundancia de los datos.
  • Evitar problemas de actualización de los datos en las tablas.
  • Proteger la integridad de los datos.
La primera forma normal, requiere que los datos sean atómicos. En otras palabras, la 1FN prohíbe a un campo contener más de un valor de su dominio de columna. También exige que todas las tablas deben tener una clave primaria. Adicionalmente, indica que una tabla no debe tener atributos que acepten valores nulos.

Cuando no existe normalización, se presentan anomalías en la base de datos. Que ocasionan problemas al momento de insertar, modificar o eliminar datos. 

Ejemplos:


  • Multiples valores:
 La forma correcta sería:


  • Redundancia de datos:
 La forma correcta de representar la tabla sería:

  • Columnas que permiten valores nulos:


La forma correcta de representar esta tabla seria como en el ejemplo anterior


  • Tabla sin llave principal:
La forma correcta sería agregando una llave principal
NORMALIZACION DE BASE DE DATOS

Resultado de imagen de normalizacion de base de datos


El proceso de normalización de bases de datos consiste en designar y aplicar una serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-relación al modelo relacional.
Las bases de datos relacionales se normalizan para:
  • Evitar la redundancia de los datos.
  • Disminuir problemas de actualización de los datos en las tablas.
  • Proteger la integridad de los datos.



En el modelo relacional es frecuente llamar tabla a una relación, aunque para que una tabla sea considerada como una relación tiene que cumplir con algunas restricciones:

  • Cada tabla debe tener su nombre único.
  • No puede haber dos filas iguales. No se permiten los duplicados.
  • Todos los datos en una columna deben ser del mismo tipo.



LINK:https://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos