MATERIA: Modulo I, II

CATEDRATICO: Alberto Mendes

ALUMNA: Tahiri Velzquez Aguilar

TRABAJO: investigacin

TEMA: las 3 formas normales para aplicar en

un diseo de Base de Datos.

FECHA DE ENTREGA: 24-09-2015

INTRODUCCION

Al realizar este trabajo podrs encontrar cuales son las tres formas normales para aplicar a un diseo de Base de Datos. Existen varios niveles de normalizacin: Primera Forma Normal, Segunda Forma Normal, Tercera Forma Normal, Forma Normal Boyce-Codd, Cuarta Forma Normal, Quinta Forma Normal o Forma Normal de Proyeccin-Unin, Forma Normal de Proyeccin-Unin Fuerte, Forma Normal de Proyeccin-Unin Extra.

DESARROLLO

El proceso de normalizacin de bases de datos consiste en designar y aplicar una

serie de reglas a las relaciones obtenidas tras el paso del modelo entidad-

relacin al modelo.

Las bases de datos relacionales se normalizan para:

Evitar la redundancia de los datos.

Disminuir problemas de actualizacin de los datos en las tablas.

Proteger la integridad de los datos.

En el modelo relacional es frecuente llamar tabla a una relacin, aunque para que

una tabla sea considerada como una relacin 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.

Figura 1.0: Trabajo (Cdigo, Nombre, Posicin, Salario), donde Cdigo es la Clave

Primaria.

Relacin = tabla o archivo

Registro = registro, fila , rengln o tupla

Atributo = columna o campo

Clave = llave o cdigo de identificacin

Clave Candidata = superclave mnima

Clave Primaria = clave candidata elegida

Clave Ajena (o fornea) = clave externa o clave fornea

Clave Alternativa = clave secundaria

Dependencia Multivaluada = dependencia multivalor

RDBMS = Del ingls Relational Data Base Manager System que

significa, Sistema Gestor de Bases de Datos Relacionales.

1FN = Significa, Primera Forma Normal o 1NF del ingls First Normal Form.

Los trminos Relacin, Tupla y Atributo derivan del lgebra y clculo relacional,

que constituyen la fuente terica del modelo de base de datos relacional.

Todo atributo en una tabla tiene un dominio, el cual representa el conjunto de

valores que el mismo puede tomar. Una instancia de una tabla puede verse

entonces como un subconjunto del producto cartesiano entre los dominios de los

atributos. Sin embargo, suele haber algunas diferencias con la analoga

matemtica, ya que algunos RDBMS permiten filas duplicadas, entre otras cosas.

Finalmente, una tupla puede razonarse matemticamente como un elemento del

producto cartesiano entre los dominios.

Las formas normales son aplicadas a las tablas de una base de datos. Decir que

una base de datos est en la forma normal N es decir que todas sus tablas estn

en la forma normal N.

Diagrama de inclusin de todas las formas normales.

En general, las primeras tres formas normales son suficientes para cubrir las

necesidades de la mayora de las bases de datos. El creador de estas 3 primeras

formas normales (o reglas) fue Edgar F. Codd.1

GRADOS DE NORMALIZACIN

Existen bsicamente tres niveles de normalizacin: Primera Forma Normal (1NF),

Segunda Forma Normal (2NF) y Tercera Forma Normal (3NF). Cada una de estas formas

tiene sus propias reglas. Cuando una base de datos se conforma a un nivel, se considera

normalizada a esa forma de normalizacin. No siempre es una buena idea tener una base

de datos conformada en el nivel ms alto de normalizacin, puede llevar a un nivel de

complejidad que pudiera ser evitado si estuviera en un nivel ms bajo de normalizacin.

PRIMERA FORMA NORMAL 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.

EJEMPLO 1: DOMINIOS Y VALORES

Suponga que un diseador principiante desea guardar los nombres y los nmeros

telefnicos de los clientes. Procede a definir una tabla de cliente como la que

sigue:

Cliente

ID Cliente Nombre Apellido Telfono

123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1659

789 Cesar Dure 555-808-9633

En este punto, el diseador se da cuenta que un requerimiento es

guardar mltiples nmeros telefnicos para algunos clientes. Razona que la

manera ms simple de hacer esto es permitir que el campo "Telfono" contenga

ms de un valor en cualquier registro dado:

Cliente

ID Cliente Nombre Apellido Telfono

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 "Telfono" est definida en algn tipo de

dominio de nmero telefnico (por ejemplo, el dominio de cadenas de 12

caracteres de longitud), la representacin de arriba no est en 1FN. La 1FN (y,

para esa materia, el RDBMS) prohbe a un campo contener ms de un valor de su

dominio de columna.

EJEMPLO 2: GRUPOS REPETIDOS A TRAVS DE COLUMNAS

El diseador puede evitar esta restriccin definiendo mltiples columnas del

nmero telefnico:

Cliente

ID Cliente Nombre Apellido Telfono 1 Telfono 2 Telfono 3

123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1659 555-776-4100

789 Cesar Dure 555-808-9633

Sin embargo, esta representacin hace uso de columnas que permiten valores

nulos, y por lo tanto no se conforman con la definicin de la 1NF de Date. Incluso

si se contempla la posibilidad de columnas con valores nulos, el diseo no est en

armona con el espritu de 1NF. Telfono 1, Telfono 2, y Telfono 3, comparten

exactamente el mismo dominio y exactamente el mismo significado; dividir los

nmeros de telfono en tres encabezados es artificial y causa problemas lgicos.

Estos problemas incluyen:

Dificultad en hacer consultas a la tabla. Es difcil contestar preguntas tales

como "Qu clientes tienen el telfono X?" y "Qu pares de clientes

comparten un nmero de telfono?".

La imposibilidad de hacer cumplir la unicidad los enlaces Cliente-a-Telfono

por medio del RDBMS. Al cliente 789 se le puede dar equivocadamente un

valor para el Telfono 2 que es exactamente igual que el valor de su Telfono

1.

La restriccin de los nmeros de telfono por cliente a tres. Si viene un cliente

con cuatro nmeros de telfono, estamos obligados a guardar solamente tres y

dejar el cuarto sin guardar. Esto significa que el diseo de la base de datos

est imponiendo restricciones al proceso del negocio, en vez de (como

idealmente debe ser el caso) al revs.

EJEMPLO 3: REPETICIN DE GRUPOS DENTRO DE COLUMNAS

El diseador puede, alternativamente, conservar una sola columna de nmero de

telfono, pero alterando su dominio, haciendo una cadena de suficiente longitud

para acomodar mltiples nmeros telefnicos:

Cliente

ID Cliente Nombre Apellido Telfono

123 Rachel Ingram 555-861-2025

456 James Wright 555-403-1659, 555-776-4100

789 Cesar Dure 555-808-9633

ste es defendiblemente el peor diseo de todos, y otra vez no mantiene el

espritu de la 1NF. El encabezado "Telfono" llega a ser semnticamente difuso,

ya que ahora puede representar, o un nmero de telfono, o una lista de nmeros

de telfono, o de hecho cualquier cosa. Una consulta como "Qu pares de

clientes comparten un nmero telefnico?" es virtualmente imposible de formular,

dada la necesidad de proveerse de listas de nmeros telefnicos as como

nmeros telefnicos individuales. Con este diseo en la RDBMS, son tambin

imposibles de definir significativas restricciones en nmeros telefnicos.

UN DISEO CON 1FN

Un diseo que est inequvocamente en 1FN hace uso de dos tablas: una tabla de

cliente y una tabla de telfono del cliente.

Cliente

ID Cliente Nombre Apellido

123 Rachel Ingram

456 James Wright

789 Cesar Dure

En este diseo no ocurren grupos repetidos de nmeros telefnicos. En lugar

de eso, cada enlace Cliente-a-Telfono aparece en su propio registro. Es

valioso notar que este diseo cumple los requerimientos adicionales para la

segunda (2NF) y la tercera forma normal (3FN).

Telfono del cliente

ID Cliente Telfono

123 555-861-2025

456 555-403-1659

456 555-776-4100

789 555-808-9633

SEGUNDA FORMA NORMAL La regla de la Segunda Forma Normal 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.

Considere una tabla describiendo las habilidades de los empleados:

Habilidades de los empleados

Empleado Habilidad Lugar actual de trabajo

Jones Mecanografa 114 Main Street

Jones Taquigrafa 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 2NF. 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 anomalas de actualizacin: por ejemplo, es posible actualizar el lugar del trabajo

de Jones en sus registros "Mecanografa" y "Taquigrafa" y no actualizar su

registro "Tallado". Los datos resultantes implicaran respuestas contradictorias a la

pregunta "Cul es el lugar actual de trabajo de Jones?".

Un alternativa 2NF a este diseo representara la misma informacin 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

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales

estn en 2NF.

Sin embargo, no todas las tablas 2NF estn libres de anomalas de

actualizacin. Un ejemplo de una tabla 2NF que sufre de anomalas de

actualizacin es:

Ganadores del torneo

Torneo Ao 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

TERCERA FORMA NORMAL 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 deben haber datos repetidos. Esto provee un esquema limpio y elegante, que es fcil de trabajar y expandir.

Un ejemplo de una tabla 2NF que falla en satisfacer los requerimientos de la 3NF

es:

Ganadores del torneo

Torneo Ao 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, Ao}.

La violacin de la 3NF ocurre porque el atributo no primario Fecha de nacimiento

del ganador es dependiente transitivamente de {Torneo, Ao} va el atributo no

primarioGanador. El hecho de que la Fecha de nacimiento del ganador es

funcionalmente dependiente en el Ganador hace la tabla vulnerable a

inconsistencias lgicas, 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 3NF, es necesario dividir la tabla en

dos:

Ganadores del torneo

Torneo Ao Ganador

Indiana Invitational 1998 Al Fredrickson

Cleveland Open 1999 Bob Albertson

Des Moines Masters 1999 Al Fredrickson

Indiana Invitational 1999 Chip Masterson

Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales

estn en 3NF.

Fecha de nacimiento del jugador

Ganador Fecha de nacimiento

Chip Masterson 14 de marzo de 1977

Al Fredrickson 21 de julio de 1975

Bob Albertson 28 de septiembre de 1968

CONCLUSION

Como conclusin llegue a que gracias a estos tres tipos de formas normales

para agregar a una Base de Datos podemos saber ms como es que una base

de datos est formada, o como realizar para que quede muy bien nuestra

Base.

Fuentes

http://ucipedia.uci.cu/index.php/Normalizaci%C3%B3n_de_una_base_de_datos

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

http://es.slideshare.net/sesa78/normalizacion-de-base-de-datos-14102278

http://isc.itcj.s5.com/bdd1/unidad4.htm