cornelio modulo.pdf

7/23/2019 cornelio modulo.pdf

1/15

C.B.T.i.s. 243

Materia:

Mdulo 1 y 2.

Docente:

Cornelio Alberto Prez Mndez

Alumna:

Yeimi Fabiola Escalante Roblero.

Especialidad:

Ofimtica

Semestre:

5 semestre, grupo A.

Trabajo:

Investigacin.

Tres formas normales para aplicar un diseo de BD.

Fecha de entrega:23/septiembre/2015.

Motozintla de Mendoza, Chiapas.


2/15

INTRODUCCION

En el transcurso de este trabajo que a continuacin realizare ser con la

finalidad e dar a conocer tres formas normales para para aplicar un diseo de

Base de Datos.

Cada forma contiene una breve explicacin para saber en qu consiste cada

una de ellas, de igual manera dar a conocer una explicacin clara, para saber

cmo realizar cada una de las formulas, es decir los pasos para poder

realizarlas, as mismo se mostrar un ejemplo claro de cada una de estas

formas normales para disear una base de datos, ya que ser de muchautilidad para poder comprender un buen aprendizaje, ya que con base a ello

obtendr conceptos que me ayudaran a mejorar y fortalecer los conocimientos

con base a esta investigacin.

1


3/15

TRES FORMAS NORMALES PARA APLICAR EN UN DISEO DE BASE DEDATOS

La Primera Forma Normal

1FN. Una relacin est en primera forma normal si slo satisface que sus

dominios simples slo tienen valores atmicos, es decir, si todos sus atributos son

atmicos, una base de datos se considera que est en 1FN si cada atributo

(campo) de una tabla contiene un solo valor atmico1 (simple). Los atributos, en

cada tabla de una base de datos 1FN, no pueden tener listas o arrays de valores,

ya sean del mismo dominio o de dominios diferentes. Cada atributo debe tener un

nombre nico, ya que la creacin de las tablas implica definir cada columna de un

tipo concreto y con un nombre nico. Un atributo que contiene varios valores

puede derivar en una prdida de datos, tampoco pueden existir tuplas idnticas.

Supongamos una base de datos para la gestin de la biblioteca, y que el mismo

da, y al mismo socio, se le presta dos veces el mismo libro (evidentemente, el

libro es devuelto entre cada prstamo, claro). Esto producir, si no tenemos

cuidado, dos registros iguales. Debemos evitar este tipo de situaciones, porejemplo, aadiendo un atributo con un identificador nico de prstamo.

Las restrinciones de la primera forma normal coinciden con las condiciones de las

relaciones de una base de datos relacional, por lo tanto, siempre es obligatorio

aplicar esta forma normal.

Aplicar la primera forma normal es muy simple, bastar con dividir cada columna

no atmica en tantas columnas atmicas como sea necesario.

1Atmica significa "indivisible", es decir, cada atributodebe contener un nicovalor del dominio

2


4/15

Pasos para la Primera forma normal

Elimine los grupos repetidos de las tablas individuales.

Cree una tabla independiente para cada conjunto de datos relacionados.

Identifique cada conjunto de datos relacionados con una clave principal.

No usar varios campos en una sola tabla para almacenar datos similares. Por

ejemplo, para realizar el seguimiento de un elemento del inventario que proviene

de dos orgenes posibles, un registro del inventario puede contener campos para

el Cdigo de proveedor 1 y para el Cdigo de proveedor 2.Qu ocurre cuando se agrega un tercer proveedor? Agregar un campo no es la

respuesta, requiere modificaciones en las tablas y el programa, y no admite

fcilmente un nmero variable de proveedores. En su lugar, coloque toda la

informacin de los proveedores en una tabla independiente denominada

Proveedores y despus vincule el inventario a los proveedores con el nmero de

elemento como clave, o los proveedores al inventario con el cdigo de proveedor

como clave.

3


5/15

Ejemplo

Si tenemos una relacin que contiene la informacin de una agenda de amigos

con este esquema:Agenda(Nombre, email)

El nombre, normalmente, estar compuesto por el tratamiento (seor, seora, don,

doa, excelencia, alteza, seora, etc), un nombre de pila y los apellidos.

Podramos considerar el nombre como un dato atmico, pero puede interesarnos

separar algunas de las partes que lo componen.

Y qu pasa con la direccin de correo electrnico? Tambin podemos considerar

que es un valor no atmico, la parte a la izquierda del smbolo @ es el usuario, y a

la derecha el dominio. De nuevo, dependiendo de las necesidades del cliente o del

uso de los datos, podemos estar interesados en dividir este campo en dos, o

incluso en tres partes (puede interesar separar la parte a la derecha del punto en

el dominio).

Tanto en esta forma normal, como en las prximas que veremos, es importante no

llevar el proceso de normalizacin demasiado lejos. Se trata de facilitar el trabajo y

evitar problemas de redundancia e integridad, y no de lo contrario. Debemos

considerar las ventajas o necesidades de aplicar cada norma en cada caso, y no

excedernos por intentar aplicar las normas demasiado al pie de la letra.

El esquema de la relacin puede quedar como sigue:

Agenda(Nombre_Tratamiento, Nombre_Pila, Nombre_Apellidos, email)

Otro caso frecuente de relaciones que no cumplen 1FN es cuando existen

atributos multivaluados, si todos los valores se agrupan en un nico atributo:

Libros (Titulo, autores, fecha, editorial)

Hemos previsto, muy astutamente, que un libro puede tener varios autores. No es

que sea muy frecuente pero sucede, y ms con libros tcnicos y libros de texto.

4


6/15

Sin embargo, esta relacin no es 1FN, ya que en la columna de autores slo debe

existir un valor del dominio, por lo tanto debemos convertir ese atributo en uno

multivaluado:

Libros

Titulo fecha editorial

Qu bueno es MySQL fulano 12/10/2003 La buena

Qu bueno es MySQL mengano 12/10/2003 La buena

Catstrofes naturales fulano 18/03/1998 Pentriga

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

En este diseo no ocurrengrupos 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

Cliente

ID Cliente Nombre Apellido

123 Rachel Ingram

456 James Wright

789 Cesar Dure

5
https://es.wikipedia.org/wiki/Segunda_forma_normalhttps://es.wikipedia.org/wiki/Segunda_forma_normalhttps://es.wikipedia.org/wiki/Segunda_forma_normalhttps://es.wikipedia.org/wiki/Tercera_forma_normalhttps://es.wikipedia.org/wiki/Tercera_forma_normalhttps://es.wikipedia.org/wiki/Tercera_forma_normalhttps://es.wikipedia.org/wiki/Tercera_forma_normalhttps://es.wikipedia.org/wiki/Segunda_forma_normal


7/15

La Segunda Forma Normal

(Si o si debe estar previamente aplicada la Primera Forma Normal) La SegundaForma 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

registrosdic, hos datos deberan atomizarse en una nueva tabla

2FN. Una relacin se encuentra en segunda forma normal si slo est en primera

forma normal y todos los atributos no clave (*) dependen por completo de la clave

primaria.

Segunda forma normal (2FN) La segunda forma normal, como la tercera, se

relaciona con el concepto de dependencia funcional. Entendemos como

dependencia funcional a la relacin que tienen los atributos (campos) de una tabla

con otros atributos de la propia tabla. Un campo tiene dependencia funcional si

necesita informacin de otro/s campo/s para poder contener un valor. Una tabla se

dice que est en segunda forma normal (2FN) si sucede que: Est en 1FN

Cada atributo (campo) no clave depende de la clave completa, no de parte de ella.Por supuesto, una base de datos estar en 2FN si todas sus tablas lo estn. La

idea intuitiva de la 2FN es identificar todas las tablas con una clave compuesta,

pues todas las tablas con clave simple estn por defecto en 2FN si estn en 1FN,

y comprobar que cada uno de los campos de esta tabla depende de la clave

completa.

6


8/15

Pasos para la Segunda forma normal

Cree tablas independientes para conjuntos de valores que se apliquen a varios

registros.

Relacione estas tablas con una clave externa.

Los registros no deben depender de nada que no sea una clave principal de una

tabla, una clave compuesta si es necesario. Por ejemplo, considere la direccin de

un cliente en un sistema de contabilidad. La direccin se necesita en la tabla

Clientes, pero tambin en las tablas Pedidos, Envos, Facturas, Cuentas por

cobrar y Colecciones. En lugar de almacenar la direccin de un cliente como unaentrada independiente en cada una de estas tablas, almacnela en un lugar, ya

sea en la tabla Clientes o en una tabla Direcciones independiente.

Ejemplo

VentaID ItemID FechaVenta ClienteVenta ProductoId Cantidad

1 1 01/12/2007 2 2334 10

1 2 01/12/2007 2 3333 2

1 3 01/12/2007 2 66643 34

1 4 01/12/2007 2 21 3

2 1 02/12/2007 5 3566 6

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

VENTASy que contenga esos 2 datos ?Es evidente que la columna

ClienteVentay FechaVenta se repetirn por cada venta realizada. Es por ello que

proponemos el siguiente esquema

7


9/15

VentaID ItemID ProductoId Cantidad

1 1 2334 10

1 2 3333 2

1 3 66643 34

1 4 21 3

2 1 3566 6

Y ahora nuestra nueva tabla maestra

VentaId FechaVenta ClienteVenta

1 01/12/2007 22 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.

Tercera forma normal

3FN. Una relacin est en tercera forma normal si slo est en segunda forma

normal y adems, cada atributo no clave (*) depende de la clave primaria de modo

no transitivo. Dicho de otra forma, una relacin est en tercera forma normal si y

slo si sus atributos no clave son: o Mutuamente independientes, es decir, no

existe un atributo no clave que dependa funcionalmente de alguna combinacin

del resto de atributos no clave. o Por completo dependientes funcionalmente de la

clave primaria.

Tercera forma normal (3FN). Una tabla se dice que est en tercera forma normal

(3FN) si: Est en 2FN. Todos los atributos que no son claves deben ser

mutuamente independientes, es decir, un atributo no debe depender de otro

atributo no clave de su tabla. Si un atributo que no es clave depende de otro

8


10/15

atributo que no es clave, la tabla posiblemente contiene datos acerca de ms de

una entidad, contradiciendo el principio de que cada tabla almacene informacin

de una entidad.

Ejemplo de Pasos para formacin de diseo de la tercera forma de esta BD.

Podemos observar que las tablas ARTCULO y DETALLE_FACTURA se

encuentran en 3FN. Sin embargo, la tabla FACTURA no est en 3FN, pues los

atributos Nombre_cliente, Direccion_cliente y Poblacion_cliente dependen

funcionalmente del atributo Codigo_cliente, campo que no es clave. Por ello,

debemos extraer estos atributos de la tabla FACTURA e incluirlos en una nueva

tabla que haga referencia al cliente, tabla que llamaremos CLIENTE y que

contendr como clave primaria el Codigo_cliente y como atributos el

Nombre_cliente, Direccion_cliente y Poblacion_cliente. Aplicando esto, nuestro

diseo de la base de datos para las facturas da lugar a las tablas que pueden

verse en la siguiente figura y que ya estn en 3FN por lo que podemos considerar

que es un buen diseo. FACTURA Codigo_factura Codigo_cliente Fecha_factura

Forma_pago Tipo_IVA DETALLE_FACTURA Codigo_factura Codigo_articulo

Cantidad Importe ARTICULO Codigo_articulo Descripcion CLIENTE

Codigo_cliente Nombre_cliente Direccion_cliente Poblacion_cliente Como detalle,

hay que destacar que la ltima descomposicin se podra haber realizado de la

forma: Codigo_factura Codigo_cliente , Codigo_factura Nombre_cliente , 5

Bases de Datos Biblioteconoma 2003-2004 Tema 6: Teora de la

Normalizacin. Pero es evidente que con esta descomposicin se pierde

informacin sobre la dependencia Codigo_cliente Nombre_cliente y por tanto

sera una mala descomposicin. Entonces, en las relaciones con transitividad

habr que obrar con cautela antes de decidir que tipo de descomposicin serealiza.

9


11/15

Aplicacin de la normalizacin.

Disear el modelo E-R y aplicar normalizacin Una empresa pretende desarrollar

una base de datos de empleados y proyectos. La empresa est estructurada en

departamentos, cada uno de los cuales posee uno o varios proyectos, de forma

que un proyecto solo depende de un departamento. Por otro lado, cada

departamento consta de uno o varios empleados que trabajan de forma exclusiva

para ese departamento, pero pueden trabajar simultneamente en varios

proyectos. Cada empleado tiene un jefe encargado de supervisar su trabajo,

pudiendo cada jefe supervisar el trabajo de varios empleados. Dada la descripcin

anterior, desarrollar la base de datos normalizada hasta 3FN. jefe Empleado

Departamento Proyecto Pertenece Trabaja Controla Supervisa (0,M) (1,1) (1,1)

(1,1) (0,M) (0,M) (0,M) (0,N) Este es el diseo conceptual que hemos desarrollado

para solucionar el problema. 6 Bases de DatosBiblioteconoma2003-2004

Teora de la Normalizacin.

Una vez realizado el esquema conceptual, pasamos a realizar el diseo lgico,

modelo relacional. Para ello aplicamos las tres reglas generales de forma

sucesiva: De la regla referente a las entidades, obtenemos la existencia de las tres

tablas siguientes: EMPLEADO Codigo_empleado Nombre Edad Direccion

poblacin DEPARTAMENTO Codigo_dpto Nombre PROYECTO Codigo_proyecto

descripcin Aplicando la regla referente a las relaciones 1:M, obtenemos la

inclusin de tres claves ajenas en las tablas, dos en la tabla empleado y una en la

tabla proyecto, quedando las tablas de la siguiente forma: EMPLEADO

Codigo_empleado Nombre Edad Direccin Poblacin Codigo_directorCodigo_dpto DEPARTAMENTO Codigo_dpto Nombre PROYECTO

Codigo_proyecto Descripcin Codigo_dpto Aplicando ahora la regla referente a las

relaciones M:N, creamos una nueva tabla llamada TRABAJA que relaciona el

empleado con los proyectos en los que trabaja y viceversa, quedando las tablas

10


12/15

como: EMPLEADO Codigo_empleado Nombre Edad Direccin poblacin

Codigo_director Codigo_dpto DEPARTAMENTO Codigo_dpto Nombre

PROYECTO Codigo_proyecto descripcin Codigo_dpto TRABAJA

Codigo_empleado Codigo_proyecto Horas Se pueden comprobar que el diseoobtenido cumplen las tres formas normales.

Pasos para la Tercera forma normal

Se eliminan los campos que no dependan de la clave.

Los valores de un registro que no sean parte de la clave de ese registro no

pertenecen a la tabla. En general, siempre que el contenido de un grupo de

campos pueda aplicarse a ms de un nico registro de la tabla, considere colocar

estos campos en una tabla independiente. Por ejemplo, en una tabla Contratacin

de empleados, puede incluirse el nombre de la universidad y la direccin de un

candidato. Pero necesita una lista completa de universidades para enviar

mensajes de correo electrnico en grupo. Si la informacin de las universidades se

almacena en la tabla Candidatos, no hay forma de enumerar las universidades

que no tengan candidatos en ese momento. Cree una tabla Universidadesindependiente y vinclela a la tabla Candidatos con el cdigo de universidad como

clave.

EXCEPCIN: cumplir la tercera forma normal, aunque en teora es deseable, no

siempre es prctico. Si tiene una tabla Clientes y desea eliminar todas las

dependencias posibles entre los campos, debe crear tablas independientes para

las ciudades, cdigos postales, representantes de venta, clases de clientes y

cualquier otro factor que pueda estar duplicado en varios registros. En teora, la

normalizacin merece el trabajo que supone. Sin embargo, muchas tablas

pequeas pueden degradar el rendimiento o superar la capacidad de memoria o

de archivos abiertos. Puede ser ms factible aplicar la tercera forma normal slo a

los datos que cambian con frecuencia. Si quedan algunos campos dependientes,

11


13/15

se disea la aplicacin para que pida al usuario que compruebe todos los campos

relacionados cuando cambie alguno.

EjemploYa no quedara normalizacin por aplicar y podramos decir que nuestro ejemplo

cumple con las 3 formas normales, ya que la 3ra Forma Normal nos habla de que:

1. Ninguna Columna puede depender de una columna que no tenga una clave

2. No puede haber datos derivados

En el 2do ejemplo hemos descubierto campos que dependan de la clave principal

(VentaID) y que podran incluirse en una tabla maestra. Se supone un ejemplo

donde ciertas columnas no dependen de la clave principal y si dependen de unacolumna de nuestra tabla.

VentaI

D

ItemID

ProductoID

Cantidad

Descripcin

Medida

Proveedor

1 1 3455 12 Impresora

HP LJ8000

122cm 1

1 2 2455 34 Scanner HP

A3555

33cm 1

2 1 5444 21 Mouse HP

Wireless

1

Esto es muy normal encontrar en bases mal normalizadas. Vemos que los campos

DESCRIPCION, MEDIDA y PROVEEDOR no dependen de VENTAID y es por ello

que no deberan estar dentro de la tabla de detalle de ventas, ya que dependen de

PRODUCTOID. Aqu no se trata ya de eliminar grupos repetidos de datos (1ra

Forma Normal) sino que ante la inclusin de una clave perteneciente a otra tabla,

cualquier campo que sea subordinado de dicha clave debe estar en otra tabla y no

en nuestra tabla detalle

12


14/15

CONCLUSION

Al termino de este trabajo, comprend muchos conceptos que son de suma

importancia tomar en cuenta para poder tener un claro aprendizaje de cada una de

estas tres formas normales para aplicar en un diseo de base de datos.

Nos ayuda a estructurar mejor las tablas de la base de datos, dependiendo de la

forma que estemos aplicando para no tener problemas al realizarlas. Por otra

parte, si seguimos la metodologa de disear primero el modelo E-R y obtener un

diseo conceptual que despus es convertido en diseo lgico, modelo relacional,este diseo lgico resultante estar en 3FN siempre que todo el proceso se haya

realizado de forma correcta, sirviendo en este caso la teora de la normalizacin

para comprobar que el diseo ha sido realizado correctamente. De otra forma,

podremos aplicar las formas normales para corregir los errores que se producen.

Tambin aprend que la normalizacin nos ayuda a estructurar mejor las tablas de

la base de datos, evitando posibles.

Por tanto, en ciertas ocasiones es necesario llegar a un compromiso entre el nivel

de normalizacin de la base de datos y el rendimiento del sistema.

Esta investigacin ser de mucha importancia para, ya que a travs e ello

podemos aprender a tener un buen diseo de base de datos para que a travs del

tiempo estos conocimientos sean adquiridos, y sea de suma importancia y utilidad

13


15/15

REFERNCIAS

http://informatica.uv.es/docencia/biblioguia/BD/ficheros/tema6.pdf

https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-formas-normales/

https://www.google.com.mx

http://analisisyprogramacionoop.blogspot.mx/2013/05/teoria-de-la-normalizacion-formas.html

http://es.slideshare.net/MonjeOneble/formas-normales

https://support.microsoft.com/es-es/kb/283878

14
http://informatica.uv.es/docencia/biblioguia/BD/ficheros/tema6.pdfhttps://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-formas-normales/https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-formas-normales/https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-formas-normales/https://www.google.com.mx/http://analisisyprogramacionoop.blogspot.mx/2013/05/teoria-de-la-normalizacion-formas.htmlhttp://analisisyprogramacionoop.blogspot.mx/2013/05/teoria-de-la-normalizacion-formas.htmlhttp://analisisyprogramacionoop.blogspot.mx/2013/05/teoria-de-la-normalizacion-formas.htmlhttp://es.slideshare.net/MonjeOneble/formas-normaleshttp://es.slideshare.net/MonjeOneble/formas-normaleshttp://analisisyprogramacionoop.blogspot.mx/2013/05/teoria-de-la-normalizacion-formas.htmlhttp://analisisyprogramacionoop.blogspot.mx/2013/05/teoria-de-la-normalizacion-formas.htmlhttps://www.google.com.mx/https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-formas-normales/https://cvva.wordpress.com/2007/12/04/normalizacion-de-bases-de-datos-las-3-formas-normales/http://informatica.uv.es/docencia/biblioguia/BD/ficheros/tema6.pdf

cornelio modulo.pdf

Documents