cornelio modulo.pdf
-
Upload
yeimi-escalante -
Category
Documents
-
view
233 -
download
0
Transcript of 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.
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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
-
7/23/2019 cornelio modulo.pdf
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