MATERIA:
MODULO
ESPECIALIDAD:
OFIMATICA
ALUMNA:
GLADIS ALEJANDRA GOMEZ UTRILLA
DOCENTE:
LIC. CORNELIO ALBERTO PEREZ MENDEZ
TRABAJO:
LAS 3 FORMAS NORMALES PARA APLICAR EN UN DISEO DE BASE DE DATOS.
SEMESTRE:
5
GRUPO:
A
FECHA:
MIERCOLES, 23 DE SEPTIEMBRE DEL 2015.
INTRODUCCION
En esta investigacin que a continuacin presentare, esta relacionado con las 3
formas normales para aplicar en un diseo de base datos. Existen 3 niveles de
normalizacin que deben respetarse para poder decir que nuestra base de datos,
se encuentra normalizada, es decir, que cumple con los requisitos naturales para
funcionar ptimamente y no perjudicar. Estas 3 reglas de normalizacin se las
conoce como las 3 formas normales. En donde mostrare ejemplos de casa unos
de ellos.
LA PRIMERA FORMA NORMAL
Esta primera forma normal, nos lleva a no repetir datos en nuestras tablas deben
aplicarse a la estructura. Si nuestra tabla de ventas repite una y otra vez (por cada
venta), el nombre, el domicilio y otros datos del Cliente, es por que no hemos
aplicado esta normalizacin. Si tenemos una tabla clientes, en la tabla ventas, solo
debera figurar el cdigo del cliente, para que el resto de los datos se puedan
referenciar automticamente sin problemas y sin duplicar informacin.
En general, las primeras tres formas normales son suficientes para cubrir las
necesidades de la mayora de base de datos. El creador de las 3 primeras formas
normales (o reglas) fue Edgar F. Codd.
Segn la definicin de Datos de la 1FN, una tabla est en primera forma normal si
solo es "isomorfa a alguna relacin", lo que significa, especficamente, que
satisface las siguientes cinco condiciones:
1. No hay orden de arriba-a-abajo en las filas.
2. No hay orden de izquierda-a-derecha en las columnas.
3. No hay filas duplicadas.
4. Cada interseccin de fila-y-columna contiene exactamente un valor del dominio
aplicable (y nada ms).
5. Todas las columnas son regulares [es decir, las filas no tienen componentes
como IDs de fila, IDs de objeto, o timestamps ocultos].
La violacin de cualquiera de estas condiciones significara que la tabla no es
estrictamente relacional, y por lo tanto no est en 1FN. Algunos ejemplos de tablas
(o de vistas) que no satisfacen esta definicin de 1FN son:
Una tabla que carece de una clave primaria podra acomodar filas duplicadas,
en violacin de la condicin 3.
Una vista cuya definicin exige que los resultados sean retornados en un orden
particular, de modo que el orden de la fila sea un aspecto intrnseco y
significativo de la vista. Esto viola la condicin 1.
Una tabla que contenga un atributo puede ser nula ya que estara en violacin
de la condicin 4, que requiere a cada campo contener exactamente un valor
de su dominio de columna. Sin embargo, debe observarse que este aspecto de
la condicin 4 es controvertido.
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:
ID
Cliente
Nombre Apellido Telfono
123 Rachel Ingram 555-861-2025
456 James Wright 555-403-1656
789 Cesar Dure 555-808-9566
CLIENTE
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.
LA SEGUNDA FORMA NORMAL
La Segunda Forma Normal nos habla de que cada columna de la tabla debe
depender de la clave. Esto significa que todo un registro debe depender
nicamente de la clave principal, si tuviramos alguna columna que se repite a lo
largo de todos los registros, dichos datos deberan atomizarse en una nueva tabla,
en esta segunda forma normal debe estar aplicada la primera.
En trminos levemente ms formales: una tabla 1FN est en 2FN 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).
Observe que cuando una tabla 1FN no tiene ninguna clave candidata compuesta
(claves candidatas consistiendo en ms de un atributo), la tabla est
automticamente en 2FN.
Ejemplo 1:
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:
Las anomalas de actualizacin no pueden ocurrir en estas tablas, las cuales estn
en 2FN.
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 Mecanografa
Jones Taquigrafa
Jones Tallado
Bravo Limpieza ligera
Ellis Alquimia
Ellis Malabarismo
Harrison Limpieza ligera
LA TERCERA FORMA NORMAL
La tercera forma normal (3NF) es usada en la normalizacin de bases de datos.
La 3FN fue definida originalmente por E.F. Codd en 1971. La definicin de Codd
indica que una tabla est en 3FN solo si las tres condiciones siguientes se
cumplen:
La tabla est en la segunda forma normal (2NF)
Ningn atributo no-primario de la tabla es dependiente transitivamente de
una clave primaria
Es una relacin que no incluye ningn atributo clave
Un atributo no-primario es un atributo que no pertenece a ninguna clave candidata.
Una dependencia transitiva es una dependencia funcional X Z en la cual Z no
es inmediatamente dependiente de X, pero s de un tercer conjunto de atributos Y,
que a su vez depende de X. Es decir, X Z por virtud de X Y e Y Z.
Una formulacin alternativa de la definicin de Codd, dada por Carlo Zaniolo en
1982, es sta: Una tabla est en 3FN para cada una de sus dependencias
funcionales X A, por lo menos una de las condiciones siguientes se mantiene:
X contiene A,
X es una sper clave,
A es un atributo primario es decir, A est contenido dentro de una clave
candidata.
Ejemplo:
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 3FN ocurre porque el atributo no primario Fecha de nacimiento
del ganador es dependiente transitivamente de {Torneo, Ao} va 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 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:
Las anomalas de actualizacin no
pueden ocurrir en estas tablas, las
cuales estn en 3NF.
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
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
He llegado a la conclusin de esta investigacin relacionada con las 3 formas
normales para poder aplicar un diseo de base datos que es muy importante ya
que nos redacta y nos especifica como debe de ir el diseo y nos explica el por
que se repite y por que se relacin una forma con otra por ejemplo la 1FN con la
2FN tienen algo en especifico y eso nos va enseando el por que hay datos
iguales.
REFERENCIAS
https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-
las-3-formas-normales/
https://www.google.com.mx/?gfe_rd=cr&ei=fBQCVpCSDMun8we-
uqz4Dg#q=ejemplo+de+la+primera+forma+de+dise%C3%B1o+de+base+d
atos
https://es.wikipedia.org/wiki/Tercera_forma_normal