Sei sulla pagina 1di 14

LISTA DE COTEJO PARA TRABAJO ESCRITO

1
2
3
4
5
6

NOMBRE DEL ALUMNO (S)


Efrn David Daz Lpez

OBSERVACIONES:

FECHA DE APLICACIN:
MODULO:
GRUPO:
EQUIPO NUM:

PRODUCTO

ASPECTOS A OBSERVAR
INVESTIG TODOS LOS TEMAS
SOLICITADOS
ES CONGRUENTE CON EL TEMA

SI NO N/P OBSERVACIONES %
10

EL TRABAJO FUE PRESENTABLE


LOS TEMAS SE ORDENARON
CORRECTAMENTE
CUMPLI EN TIEMPO Y FORMA
EL CONTENIDO FUE CLARO

FORMA:
TITULO: MAYUSCULA ARIAL 12
PARRAFOS: ARIAL 12 MINUSCULA
ENGARGOLADO O EN CAPETA CON BROCHE:
MARGENES: 3
INTERLINEADO: 1.5
BORDE: DOBLE
El trabajo debe de tener los siguientes apartados.
PRESENTACION.
INTRODUCCION.
DESARROLLO.
CONCLUSION.
REFERENCIAS.

30
5
5
20
30

Materia:
Submodulo I y II
Nombre del docente:
Cornelio Alberto Prez Mndez
Nombre del alumno:
Efrn David Daz Lpez
Especialidad:
Ofimtica
Semestre y grupo:
5 A

Trabajo:
Investigacion
Tema:
Las 3 formas normales para aplicar en un diseo de BD

Fecha de entrega:
23 de septiembre de 2015

Motozintla de Mendoza, Chiapas

INTRODUCCION

En esta investigacin que realizaremos en base a la creacin de base de datos


con el tema de las 3 formas normales para aplicar a un diseo de BD.
Adquirir una retroalimentacin a mis conocimientos y aprender ms a fondo
de cada una de las tres formas, ya sea en su definicin las caractersticas, y las
formas de cmo debemos aplicarlo cuando estemos creando nuestra propia
base de datos, ya que, al comprenderlo o entender bien esta informacin as ya
no se nos presentara errores como en la redundancia.
As de esta manera al dominar bien con este tema ya mencionado nos ser
muy til en nuestra vida escolar ya que cuando se nos presente ejercicios de
realizar una BD ya no se nos presentara errores, como uno de los que ms
tenemos que tener en cuenta es la redundancia.

LAS 3 FORMAS NORMALES PARA APLICAR A UN DISEO DE BD


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 las
Performance por mala arquitectura. Estas 3 reglas de Normalizacin se las
conoce como las 3 FORMAS NORMALES.

1 Forma normal (1FN)


Cuando hablamos del universo de datos, hacemos referencia a todos los datos
capturados por un criterio en comn. Sin embargo, estn desorganizados, lo
cual dificulta su utilidad y anlisis. Esto origina redundancias e inconsistencias.
Cuando una relacin no est normalizada, cabe la posibilidad que alguna celda
no est llena, que los datos se repitan, que aparezcan dos datos en una celda,
que algunos datos como atributos incorrectos, que los datos no sean valores
simples,

que

la

misma

tabla

no

cuente

con

claves

primarias.

En cambio, una relacin que est en Primera Forma Normal cuenta,


primeramente, con todas las celdas llenas y, con al menos, una clave primaria.
Adems de ello, lo que busca la 1FN es que todas las tuplas tengan slo un
valor por atributo. Es decir que por ms que una celda pueda poseer dos
valores para el mismo atributo, no pueden figurar juntas, sino que se debe
crear una tupla nueva para colocar por separado esos dos datos. Cabe
mencionar que la 1FN busca que los datos sean simples y que estn colocados
en la columna correcta.
El proceso de normalizacin de bases de datos consiste en 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 problemas de actualizacin de los datos en las tablas.

Evitar la redundancia de los datos

Proteger la integridad de los datos.

relacional.

La primera forma normal, requiere que los datos sean atmicos. En otras
palabras, la 1FN prohbe a un campo contener ms de un valor de su dominio
de columna. Tambin 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 normalizacin, se presentan anomalas en la base de datos.
Que ocasionan problemas al momento de insertar, modificar o eliminar datos.
Los famosos maestro detalle, deben aplicarse a la estructura de la tabla. Si
nuestra tabla de ventas repite una y otra vez (por cada venta), el nombre, el
domicilio y otros datos del Cliente, es 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. Lo
mismo ocurrira en una tabla de detalle de ventas, si por cada tem vendido
colocamos

el

detalle

del

producto,

con

su

descripcin,

medidas,

etcTendramos un desaprovechamiento de espacio y recursos muy


grande. Para ello, tendremos nuestra tabla maestra de Productos y con solo
grabar el cdigo de dicho producto en nuestra tabla de ventas, ser suficiente.

EJEMPLO:
En este ejemplo podemos ver en la primera tabla todos los datos de los clientes
de una empresa, en donde visualizamos el cdigo de cliente, el nombre y
apellido del cliente as como su telfono.

Podemos ver que un cliente tiene dos telfonos y se le estn colocando en la


mismo campo lo cual no es posible en una implementacin de base de datos,
por lo cual debemos separar en otra tabla el cdigo de cliente con el telfono
como

se

muestra

continuacin:

Ejemplo 2:
En el siguiente ejemplo tenemos los datos de clientes y podemos darnos
cuenta que cuando un cliente tiene dos correos se le agrega dos veces en la
tabla.

Para solucionar este problema podemos realizar una tabla con el cdigo del
cliente y el correo electrnico como se muestra a continuacin:

Ejemplo

3:

En este ejemplo visualizamos la tabla de ciudadanos con sus respectivas


direcciones, provincias y poblados, si un ciudadano tiene 2 o mas direcciones
ocurriria lo mostrado esta tabla:

Para poder optimizar esta tabla y pasarla a la primera forma normal tendramos
que crear otra tabla con las direcciones de los ciudadanos.

2 Forma normal (2FN):


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.
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 trmino que describe a aquellos datos
que no dependen de la clave de la tabla para identificarlos.
Una de las mayores desventajas de la normalizacin es el tiempo que lleva
hacerlo. La mayora de la gente est demasiado ocupada, y emplear tiempo
para asegurarse de que sus datos estn normalizados cuando todo funciona
ms o menos bien, parece ser un desperdicio de tiempo. Pero no es as. Usted
tendr que emplear ms tiempo arreglando una base de datos no normalizada
que el que empleara 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

aadir

nuevas

columnas

una

tabla

sin

afectar

las dems tablas.

Lo mismo aplica para las otras tablas.

Alcanzar este nivel de normalizacin permite que los datos se acomoden

de una manera natural dentro de los lmites esperados.

Ejemplo:
VentaID ItemID

FechaVenta

ClienteVenta

ProductoId

Cantidad

01/12/2007

2334

10

01/12/2007

3333

01/12/2007

66643

34

01/12/2007

21

02/12/2007

3566

Ah tenemos un claro problema! Acaso no se busca NO REPETIR DATOS ?Si


toda una venta tendr el mismo nmero de Cliente y la misma FechaPor que
no crear una Tabla de MAESTRO DE VENTAS y que contenga esos 2 datos
Es evidente que la columna Cliente Venta y FechaVenta se repetirn por cada
venta realizada. Es por ello que proponemos el siguiente esquema
VentaID ItemID

Productold

Cantidad

2334

10

3333

66643

34

21

2
1
3566
6
Y ahora nuestra nueva tabla maestra
VentaId

FechaVenta

ClienteVenta

01/12/2007

2
02/12/2007
5
Entonces, nuestra 2da Forma Normal nos habla de que cada columna de una
tabla debe depender de toda la clave y no constituir un dato unico para cada
grupo de registros.

3 Forma normal:
La tercera forma normal (3NF) es una forma normal usada en la normalizacin
de bases de datos. La definicin 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)

Ningn 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 versin 3NF de la definicin es ms dbil que la
variacin 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

aplicndola

todos

los

atributos

prohibira

implcitamente claves de candidato compuestas, puesto que cada parte de


cualquiera de tales claves violara la clusula de "clave completa".

Ejemplo:

En este cuadro, tendramos como Clave Primaria al C_Evento y los dems


atributos dependen de la PK. Sin embargo, vemos que la Direccin del local
T_Direccin depende del nombre del Local donde se realiza el evento. Para
resolver este problema y tener un mejor almacenamiento de datos, la 3FN hace
que creemos una 2da tabla haciendo PK al Nombre del local teniendo como
atributo dato a la Direccin.

Ejemplo

2:

En este ejemplo tenemos una tabla de los empleados de una empresa donde
estn identificados por numero de seguro social el cual es PK, y los atributos
restantes

son

su

nombre,

puesto

salario

que

reciben.

En este caso, el salario no depende del nmero de seguro social pero si del
puesto que ocupa el empleado, entonces se procede a separar el salario en
otra tabla.

Ahora

tenemos

la

relacion

en

3FN.

Conclusin:

Bien al darle fin con esta investigacin he conocido muy a fondo cada una de
las tres formas normales que se le puede aplicar a un diseo de base de datos,
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.

As he aprendido que as en general, las primeras tres formas normales son


suficientes para cubrir las necesidades de la mayora de las bases de datos.
1NF significa que tus relaciones tienen un nmero de atributos fijos y atmicos
2NF significa que los atributos dependen de toda la clave primaria y no de parte
de ella 3NF significa que loa atributos dependen directamente de la clave
primaria (y no indirectamente a travs de otro atributo). Una vez que ya
conozcamos bien acerca de este tema y ya lo dominemos se nos facilitara la
creacin de una base de datos ya que con esta informacin he adquirido una
retroalimentacin a mis conocimientos as todo esto es muy til en la vida
escolar y es bueno que siempre lo tengamos en cuenta cada uno de estas tres
formas normales de la base de datos.

Bibliografa:

https://www.google.com.mx/ -formas+normales+de+base+de+datos
https://www.google.com.mx/-oncepto+de+la+forma+normal+de+base+de+datos
http://datosconbase.blogspot.mx/2012/01/tercera-forma-normal.html
http://campuscurico.utalca.cl/~jperez/bd/documentos/3nf-bcnf.pdf
http://basededatos-jonathan-delatorre.blogspot.mx/2012/04/la-tercera-formanormal-3fn.html
http://tadebasegino.blogspot.mx/2012/08/la-segunda-forma-normal-2fn.html
http://kvnbd.blogspot.mx/2011/09/primera-forma-normal.html
http://normalizacion-bd.blogspot.mx/2012/08/3-primera-forma-normal-1fn.html
https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3formas-normales/
http://virtual.uaeh.edu.mx/repositoriooa/paginas/Normalizacion

de

Base

Datos/tercera_forma_normal_3fn.html
http://normalizacion-bd.blogspot.mx/2012/08/5-tercera-forma-normal-3fn.html

de

Potrebbero piacerti anche