Normalizacion db

3,095 views
2,968 views

Published on

Habla de normalizacion bases de datos

Published in: Technology, Business
0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,095
On SlideShare
0
From Embeds
0
Number of Embeds
12
Actions
Shares
0
Downloads
0
Comments
0
Likes
4
Embeds 0
No embeds

No notes for slide

Normalizacion db

  1. 1. DependenciaFuncional<br /><ul><li>Dependencia funcional es una relación entre atributos de una misma relación(tabla). Si X e Y son atributos de la relación R, se dice que Y es funcionalmente dependiente de X (se denota por X--> Y) si cada valor de X tiene asociado un solo valor de X (X e Y pueden constar de uno o varios atributos). A X se le denomina determinante, ya que X determina el valor de Y. Se dice que el atributo Y es completamente dependiente de X si depende funcionalmente de X y no depende de ningún subconjunto de X.</li></ul>http://es.wikipedia.org/wiki/Dependencia_funcional<br />Las dependencias funcionales son restricciones de integridad sobre los datos. Conocer las dependencias funcionales en el momento del diseño de la base de datos permite crear mecanismos para evitar la redundancia (y los potenciales problemas de integridad que eso conlleva) y mejorar la eficiencia.<br />
  2. 2. DependenciaFuncional<br />Por ejemplo, sea la siguiente relacion: Vehiculo(serie, nombre, motor, carroceria, peso, eficiencia).<br />Aqui, serie es la clave. Por ende, hay solo un [modelo de] motor por serie, solo una [forma de]<br />carroceriapor serie, solo un peso por serie y solo una eficiencia [energetica] por serie: nombre = nombre(<br /> serie), motor = motor(serie), asi, como sigue. O sea, serie nombre, motor, carrocera, peso, eficiencia<br /> (la relación es función de su clave; solo hay una tupla por clave).<br />Sea un relación Película(título, año, estudio, presidente, fono_presidente).<br />Digamos que ”título” es la clave de la relación (determina todo). Sin embargo, notemos que el presidente de un estudio se puede determinar conociendo el estudio y el año (idealmente). <br /> estudio, año presidente. <br /> Además, es claro que  <br /> presidente fono_presidente. <br /> La relación ”Película” fue mal modelada desde un principio. En un modelo entidad-relacion,<br /> ”Película”, ”Estudio” y ”Presidente” deberían ser entidades distintas, luego relaciones distintas en el modelo relacional.<br />
  3. 3. Normalización<br /> la normalización son una serie de reglas que sirven para ayudar a los diseñadores de bases de datos a desarrollar un esquema que minimice los problemas de lógica a proteger los datos, lo cual permite hacer que la base de datos sea más flexible al eliminar la redundancia y las dependencias incoherentes. <br />¿Qué es una "dependencia incoherente"? Aunque es intuitivo para un usuario mirar en la tabla Clientes para buscar la dirección de un cliente en particular, puede no tener sentido mirar allí el salario del empleado que llama a ese cliente. El salario del empleado está relacionado con el empleado, o depende de él, y por lo tanto se debería pasar a la tabla Empleados. Las dependencias incoherentes pueden dificultar el acceso porque la ruta para encontrar los datos puede no estar o estar interrumpida. <br />Las guías que la normalización provee crean el marco de referencia para simplificar una estructura de datos compleja.<br />Se toma un esquema relacional y se le aplica un conjunto de técnicas para producir un nuevo esquema que representa la misma información pero contiene menos redundancias y evita posibles anomalías en las inserciones, actualizaciones y borrados.<br /> tablas relacionales se pueden definir diferentes restricciones<br /> La integridad de entidad: Cada entidad representada por una tupla o fila tiene que ser diferente de las demás en su relación(Claves primarias).<br /> La integridad referencial: La clave foránea solo debe contener valores que o bien sean nulos, o bien existan en la relación referenciada por la clave foránea.<br />http://es.wikipedia.org/wiki/Normalizaci%C3%B3n_de_bases_de_datos<br />
  4. 4. Normalización<br />Esquema relacional<br />EMPLEADOS(idnumero, nombre, puesto, salario, emails) con idnumerocomo clave primaria.<br />
  5. 5. Primera forma normal (1FN)<br />Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.<br />http://es.wikipedia.org/wiki/Primera_forma_normal<br />tenemos dos opciones.<br />Solución 1: duplicar los registros con valores repetidos <br />En general, esta solución pasa por sustituir R por una nueva relación modicada R', en la cual: <br /> El atributo M que violaba 1FN se elimina. Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K]. En otras palabras, para una tupla con n valores duplicados en M, en la nueva relación habrá n tuplas, que sólo varían en que cada una de ellas guarda uno de los valores que había en M.<br />La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los valores multivaluados en M.<br />
  6. 6. Primera forma normal (1FN)<br /><ul><li>Una tabla está en 1FN si sus atributos contienen valores atómicos. En el ejemplo, podemos ver que el atributo emails puede contener más de un valor, por lo que viola 1FN.
  7. 7. tenemos dos opciones.
  8. 8. Solución 1: duplicar los registros con valores repetidos
  9. 9. Sustituir R por una nueva relación modicada R', en la cual:
  10. 10. El atributo M que violaba 1FN se elimina. Se incluye un nuevo atributo M' que solo puede contener valores simples, de modo que si R'[M'] es uno de los valores que teníamos en R[M], entonces R'[K] = R[K].
  11. 11. La clave primaria de R' es (K, M'), dado que podrá haber valores de K repetidos, para los valores multivaluados en M.</li></ul>la nueva tabla EMPLEADOS'(a)<br />clave primaria(PK)<br />(idnumero, email):<br />
  12. 12. Primera forma normal (1FN)<br /><ul><li>Solución 2: separar el atributo que viola 1FN en una tabla .
  13. 13. sustituir R por una nueva relación modificada R' que no contiene el atributo M.
  14. 14. Crear una nueva relación N(K, M'), es decir, una relación con una clave foránea K referenciando R', junto al atributo M', que es la variante mono-valuada del atributo M.
  15. 15. La nueva relación N tiene como clave (K, M').</li></ul>la nueva tabla EMPLEADOS‘(b)<br />la nueva tabla EMAILS<br />clave primaria(PK)<br />(idnumero, email):<br />
  16. 16. Segunda forma normal (2FN)<br />Está en 1FN.<br />Todos sus atributos que no son de la clave principal tienen dependencia funcional completa respecto de todas las claves existentes en el esquema. En otras palabras, para determinar cada atributo no clave se necesita la clave primaria completa, no vale con una subclave.<br />La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN.<br />En general, tendremos que observar los atributos no clave que dependan de parte de la clave.<br />http://es.wikipedia.org/wiki/Segunda_forma_normal<br />Para solucionar este problema, tenemos que hacer lo siguiente para los grupos de atributos con dependencia incompleta M:<br />Eliminar de R el atributo M.<br />Crear una nueva relación N con el atributo M y la parte de la clave primaria K de la que depende, que llamaremos K'.<br />La clave primaria de la nueva relación será K'.<br />
  17. 17. Segunda forma normal (2FN)<br /><ul><li>de las soluciones anteriores.
  18. 18. Por tanto, la tabla EMPLEADOS'(b) está en 1FN
  19. 19. La tabla EMAILS no tiene atributos no clave, por lo que el esquema está en 2FN.</li></ul> tabla EMPLEADOS‘(b)<br /> tabla EMAILS<br />clave primaria(PK)<br />(idnumero, email):<br />
  20. 20. Segunda forma normal (2FN)<br /><ul><li>examinar las dependencias funcionales de los atributos no clave de EMPLEADOS'(a).
  21. 21. Las dependencias funcionales que tenemos son las siguientes:
  22. 22. Idnumero->nombre, salario, email
  23. 23. puesto->salario
  24. 24. Como la clave es (idnumero, email), las dependencias de nombre, salario y email son incompletas, por lo que la relación no está en 2FN.</li></ul> tabla EMPLEADOS'(a)<br />clave primaria(PK)<br />(idnumero, email)<br />
  25. 25. Segunda forma normal (2FN)<br /><ul><li>Aplicando lo sugerido.
  26. 26. Eliminar de Empleados(a) el atributo EMAILS como resultado queda la relación EMPLEADOS’(d) .
  27. 27. Crear una nueva relación EMAILS con el atributo emails y la parte de la clave primaria de empleados (idnumero) de la que depende, que llamaremos K'.
  28. 28. La clave primaria de la nueva relación será PK'.</li></ul> tabla EMPLEADOS’(d)<br /> tabla EMAILS<br />clave primaria(PK’)<br />(idnumero, email):<br />
  29. 29. Tercera forma normal (3FN)<br />Está en 2FN.<br />Ningún atributo no-primario de la tabla es dependiente transitivamente de una clave candidata o primaria<br />La 2FN se aplica a las relaciones que tienen claves primarias compuestas por dos o más atributos. Si una relación está en 1FN y su clave primaria es simple (tiene un solo atributo), entonces también está en 2FN.<br />En general, tendremos que observar los atributos no clave que dependan de parte de la clave.<br />http://es.wikipedia.org/wiki/Tercera_forma_normal <br />Para solucionar este problema, tenemos que hacer lo siguiente para los grupos de atributos con dependencia incompleta M:<br />Determinar los atributos que son dependientes de un atributo que no es clave.<br />Sustituir R por una nueva relación modicada R', en la cual: <br />El o los atributos M que son dependientes se eliminan.<br />Crear una nueva relación N con los atributos M que son dependientes y la clave primaria K de la que depende, que llamaremos K'.<br />
  30. 30. Tercera forma normal (3FN)<br /><ul><li>la tabla ORDENES no esta en 3FN, ya que NOM_CLIENTE y ESTADO son dependientes de ID_CLIENTE, y esta columna no es la llave primaria, la clave primaria es ID_ORDEN. </li></ul>Tabla Ordenes(S)<br />
  31. 31. Tercera forma normal (3FN)<br /><ul><li>Aplicando lo sugerido.
  32. 32. Eliminar de ordenes(a) los atributos NOM_CLIENTE y ESTADO como resultado queda la relación ORDENES’(d) .
  33. 33. Crear una nueva relación CLIENTES con el atributo ID_CLIENTE como clave primaria, y los atributos NOM_CLIENTES y ESTADO que son atributos dependientes de ID_CLIENTE</li></ul>Tabla Ordenes ’(d)<br />Tabla Clientes(d)<br />
  34. 34. NORMALIZACIÓN<br />Los datos redundantes desperdician el espacio de disco y crean problemas de mantenimiento, por esto es de gran utilidad hacer normalización en la base de datos.<br />La normalización no es una ciencia exacta, más bien subjetiva.<br />“Cumplir la tercera forma normal, aunque en teoría es deseable, no siempre es práctico. Si tiene una tabla Clientes y desea eliminar todas las dependencias posibles entre los campos, debe crear tablas independientes para las ciudades, códigos postales, representantes de venta, clases de clientes y cualquier otro factor que pueda estar duplicado en varios registros. En teoría, la normalización merece el trabajo que supone. Sin embargo, muchas tablas pequeñas pueden degradar el rendimiento o superar la capacidad de memoria o de archivos abiertos. Puede ser más factible aplicar la tercera forma normal sólo a los datos que cambian con frecuencia. Si quedan algunos campos dependientes, diseñe la aplicación para que pida al usuario que compruebe todos los campos relacionados cuando cambie alguno.”<br />

×