Tarea 3

El Proceso de Normalización

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. El objetivo de esto es evitar la redundancia de datos, evitar problemas asociados a la actualización de las tablas (relaciones) y ademas proteger la integridad de los datos. Para que una tabla sea considerada como una relación tiene que tener un nombre único, no pueden haber dos filas iguales ni duplicados y todos los datos en una columna deben ser del mismo tipo.

Dependencias Funcionales

Una dependencia funcional es una conexión entre uno o más atributos, por ej. fecha de nacimiento y edad. Escrito como dependencia funcional, esto sería FechaDeNacimiento ---> Edad.

Hay tres propiedades fundamentales:

-Reflexiva: El atributo tiene la suficiente información como para reconstruirse a si mismo.

-Aumentativa: Si de "X" construimos "Y" entonces de "XZ" construimos "YZ"

-Transitiva: Si de "X" construimos "Y", y de "Y" construimos "Z", entonces somos capaces de construir "Z" a partir de "X".

Formas Normales

Primera Forma Normal (1FN)

La primera forma normal (1FN o forma mínima) es una forma normal usada en normalizacion de bases de datos. Una tabla de base de datos relacional que se adhiere a la 1FN es una que satisface cierto conjunto mínimo de criterios. Estos criterios se refieren básicamente a asegurarse que la tabla es una representación fiel de una relación y está libre de "grupos repetitivos".

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 llave primaria única.

• La llave primaria no contiene atributos nulos.

• No debe existir variación en el número de columnas.

• Los Campos no llave deben identificarse por la llave (Dependencia Funcional)

• Debe Existir una independencia del orden tanto de las filas como de las columnas, es decir, si los datos cambian de orden no deben cambiar sus significados

• Una tabla no puede tener múltiples valores en cada columna.

• Los datos son atómicos (a cada valor de X le pertenece un valor de Y y viceversa).

Esta forma normal elimina los valores repetidos dentro de una BD.

Ejemplo:

Suponga que un diseñador principiante desea guardar los nombres y los números telefónicos de los clientes. Procede a definir una tabla de cliente como la que sigue:

Cliente
ID Cliente	Nombre	Apellido	Teléfono
123	Rachel	Ingram	555-861-2025
456	James	Wright	555-403-1659
789	Cesar	Dure	555-808-9633

En este punto, el diseñador se da cuenta de un requisito para guardar múltiples números teléfonicos para algunos clientes. Razona que la manera más simple de hacer esto es permitir que el campo "Teléfono" contenga más de un valor en cualquier registro dado:

Cliente
ID Cliente	Nombre	Apellido	Teléfono
123	Rachel	Ingram	555-861-2025
456	James	Wright	555-403-1659 555-776-4100
789	Cesar	Dure	555-808-9633

Asumiendo, sin embargo, que la columna "Teléfono" está definida en algún tipo de dominio de número telefónico (por ejemplo, el dominio de cadenas de 12 caracteres de longitud), la representación de arriba no está en 1FN. La 1FN prohíbe a un campo contener más de un valor de su dominio de columna.

Solución

Un diseño que está inequívocamente en 1FN hace uso de dos tablas: una tabla de cliente y una tabla de teléfono del cliente.

Cliente
ID Cliente	Nombre	Apellido
123	Rachel	Ingram
456	James	Wright
789	Cesar	Dure

Teléfono del cliente
ID Cliente	Teléfono
123	555-861-2025
456	555-403-1659
456	555-776-4100
789	555-808-9633

En este diseño no ocurren grupos repetidos de números telefónicos. En lugar de eso, cada enlace Cliente-a-Teléfono aparece en su propio registro. Es valioso notar que este diseño cumple los requerimientos adicionales para la segunda (2FN) y la tercera forma normal (3FN).

Segunda Forma Normal (2FN)

Una tabla 1FN está en 2FN si y solo si ninguno de sus atributos no-principales son funcionalmente dependientes en una parte (subconjunto propio) de una clave primaria (Un atributo no-principal es uno que no pertenece a ninguna clave primaria)

Considere una tabla describiendo las habilidades de los empleados:

Habilidades de los empleados
Empleado	Habilidad	Lugar actual de trabajo
Jones	Mecanografía	114 Main Street
Jones	Taquigrafía	114 Main Street
Jones	Tallado	114 Main Street
Bravo	Limpieza ligera	73 Industrial Way
Ellis	Alquimia	73 Industrial Way
Ellis	Malabarismo	73 Industrial Way
Harrison	Limpieza ligera	73 Industrial Way

La única clave candidata de la tabla es {Empleado, Habilidad}.

El atributo restante, Lugar actual de trabajo, es dependiente solo en parte de la clave candidata, llamada Empleado. Por lo tanto la tabla no está en 2FN. Observe la redundancia de la manera en que son representadas los Lugares actuales de trabajo: nos dicen tres veces que Jones trabaja en la 114 Main Street, y dos veces que Ellis trabaja en 73 Industrial Way. Esta redundancia hace a la tabla vulnerable a anomalías de actualización: por ejemplo, es posible actualizar el lugar del trabajo de Jones en sus registros "Mecanografía" y "Taquigrafía" y no actualizar su registro "Tallado". Los datos resultantes implicarían respuestas contradictorias a la pregunta "¿Cuál es el lugar actual de trabajo de Jones?".

Un alternativa 2FN a este diseño representaría la misma información en dos tablas:

Empleados
Empleado	Lugar actual de trabajo
Jones	114 Main Street
Bravo	73 Industrial Way
Ellis	73 Industrial Way
Harrison	73 Industrial Way

Habilidades de los empleados
Empleado	Habilidad
Jones	Mecanografía
Jones	Taquigrafía
Jones	Tallado
Bravo	Limpieza ligera
Ellis	Alquimia
Ellis	Malabarismo
Harrison	Limpieza ligera

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 2NF.

Sin embargo, no todas las tablas 2FN están libres de anomalías de actualización. Un ejemplo de una tabla 2NF que sufre de anomalías de actualización es:

Ganadores del torneo
Torneo	Año	Ganador	Fecha de nacimiento del ganador
Des Moines Masters	1998	Chip Masterson	14 de marzo de 1977
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 1977

Aunque el Ganador y la Fecha de nacimiento del ganador están determinadas por una clave completa {Torneo, Año} y no son partes de ella, particularmente las combinaciones Ganador / Fecha de nacimiento del ganador son mostradas redundantemente en múltiples registros. Este problema es tratado por la tercera forma normal (3FN).

Una tabla para la cual no hay dependencias funcionales parciales en la clave primaria está típicamente, pero no siempre, en 2FN. Además de la clave principal, la tabla puede contener otras claves candidatas; es necesario establecer que ningún atributo no-principal tienen dependencias de clave parciales en cualesquiera de estas claves candidatas.

Las múltiples claves candidatas ocurren en la siguiente tabla:

Modelos eléctricos de cepillo de dientes
Fabricante	Modelo	Nombre completo del modelo	País del fabricante
Forte	X-Prime	Forte X-Prime	Italia
Forte	Ultraclean	Forte Ultraclean	Italia
Dent-o-Fresh	EZBrush	Dent-o-Fresh EZBrush	USA
Kobayashi	ST-60	Kobayashi ST-60	Japón
Hoch	Toothmaster	Hoch Toothmaster	Alemania
Hoch	Contender	Hoch Contender	Alemania

Aun si el diseñador ha especificado la clave principal como {Nombre completo del modelo}, la tabla no está en 2NF. {Fabricante, Modelo} es también una clave candidata, y País del fabricante es dependiente en un subconjunto apropiado de él: Fabricante.

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.

Un ejemplo de una tabla 2FN que falla en satisfacer los requerimientos de la 3FN es:

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 1977

La única clave candidata es {Torneo, Año}.

La violación de la 3FN ocurre porque el atributo no primario Fecha de nacimiento del ganador es dependiente transitivamente de {Torneo, Año} vía el atributo no primario Ganador. El hecho de que la Fecha de nacimiento del ganador es funcionalmente dependiente en el Ganador hace la tabla vulnerable a inconsistencias lógicas, pues no hay nada que impida a la misma persona ser mostrada con diferentes fechas de nacimiento en diversos registros.

Para expresar los mismos hechos sin violar la 3FN, es necesario dividir la tabla en dos:

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 Masterson

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

Las anomalías de actualización no pueden ocurrir en estas tablas, las cuales están en 3FN.

Bibliografia:

http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos

http://es.wikipedia.org/wiki/Primera_forma_normal

http://es.wikipedia.org/wiki/Segunda_forma_normal

http://es.wikipedia.org/wiki/Tercera_forma_normal