PresentacióN Tema 8

1,822 views

Published on

Prueba

Published in: Education, Technology
  • Be the first to comment

PresentacióN Tema 8

  1. 1. Tema 9: Diseño lógico de datos. <ul><li>Modelo Relacional </li></ul><ul><ul><li>Presentación y objetivos </li></ul></ul><ul><ul><li>Elementos del modelo relacional </li></ul></ul><ul><ul><li>Claves </li></ul></ul><ul><ul><li>Restricciones </li></ul></ul><ul><ul><li>Álgebra relacional </li></ul></ul><ul><li>Pasos en el Diseño de datos </li></ul><ul><li>Transformación del esquema conceptual al esquema lógico </li></ul><ul><ul><li>Transformación de interrelaciones N:M </li></ul></ul><ul><ul><li>Transformación de interrelaciones 1:N </li></ul></ul><ul><ul><li>Transformación de interrelaciones 1:1 </li></ul></ul><ul><ul><li>Transformación n-arias </li></ul></ul><ul><ul><li>Transformación de dependencia en existencia e identificación </li></ul></ul><ul><ul><li>Transformación Interrelaciones exclusivas </li></ul></ul><ul><ul><li>Transformación Generalizaciones </li></ul></ul><ul><li>Normalización del esquema lógico de datos </li></ul><ul><ul><li>Introducción </li></ul></ul><ul><ul><li>Noción intuitiva de las formas normales </li></ul></ul><ul><ul><li>Dependencias funcionales. Teoría de la normalización </li></ul></ul><ul><ul><li>Definición de dependencia funcional </li></ul></ul><ul><ul><li>Dependencia funcional completa y 2FN </li></ul></ul><ul><ul><li>Dependencia funcional transitiva y 3FN </li></ul></ul>
  2. 2. MODELO RELACIONAL. PRESENTACIÓN Y OBJETIVOS <ul><li>Presentación y objetivos. </li></ul><ul><ul><li>Codd propone, a finales de los años sesenta, un modelo de datos basado en la teoría de las relaciones, en donde los datos se estructuran en forma de relaciones (tablas). </li></ul></ul><ul><ul><li>El trabajo publicado por Codd presentaba un nuevo modelo de datos que perseguía una serie de objetivos, que se pueden resumir en los siguientes: </li></ul></ul><ul><ul><li>Independencia Física : es decir, que el modo en el que se almacenan los datos no influya en su manipulación lógica y, por tanto, los usuarios que accedan a esos datos no tengan que modificar sus programas por cambios en el almacenamiento físico. </li></ul></ul><ul><ul><li>Independencia Lógica : esto es, que el añadir, eliminar o modificar objetos de la base de datos no repercuta en los programas y/o usuarios que están accediendo a subconjuntos parciales de los mismos (vistas). </li></ul></ul><ul><ul><li>Flexibilidad : en el sentido de poder presentar a cada usuario los datos de la forma en que éste prefiera. </li></ul></ul><ul><ul><li>Sencillez : las características anteriores, así como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo de datos relacional sea fácil de comprender y de utilizar por parte del usuario final. </li></ul></ul>ÍNDICE
  3. 3. MODELO RELACIONAL. PRESENATICÓN Y OBJETIVOS <ul><li>Presentación y objetivos </li></ul><ul><ul><li>Para conseguir los objetivos citados, Codd introduce el concepto de relación (tabla) como estructura básica del modelo. </li></ul></ul><ul><ul><li>En este tema, una vez que estudiemos el modelo relacional, lo que haremos será convertir el modelo entidad interrelación creado en la fase de análisis en una serie de tablas (o relaciones) con una serie de reglas. </li></ul></ul>ÍNDICE
  4. 4. MODELO RELACIONAL. ELEMENTOS <ul><li>Tablas o relación: </li></ul><ul><li>Conjunto de campos, cada uno con su propio dominio, para describir un conjunto de entidades del mismo tipo. </li></ul><ul><li>Ejemplo: Tabla persona </li></ul>ÍNDICE
  5. 5. MODELO RELACIONAL. ELEMENTOS <ul><li>Tupla o fila: </li></ul><ul><li>Conjuntos de valores que dentro de una tabla sirven para describir una ocurrencia de la entidad que describimos mediante la tabla. </li></ul><ul><li>Ej: Fila de la tabla persona. </li></ul>ÍNDICE
  6. 6. MODELO RELACIONAL. ELEMENTOS <ul><li>Tupla o fila: </li></ul>ÍNDICE
  7. 7. MODELO RELACIONAL. CLAVES <ul><li>Claves: </li></ul><ul><ul><li>Clave candidata : Conjunto no vacío de atributos que identifican unívoca y mínimamente cada tupla (o fila). Siempre debe existir, al menos, una clave candidata ya que no pueden existir en una tabla dos tuplas iguales. Si no se cumpliese este requisito deberíamos eliminar aquellos atributos que lo impidiesen. Una relación puede tener más de una clave candidata, entre las cuales se debe distinguir: </li></ul></ul><ul><ul><ul><li>Clave primaria: es aquella clave candidata que el usuario escogerá, por consideraciones ajenas al modelo relacional, para identificar las tuplas de la relación. </li></ul></ul></ul><ul><ul><ul><li>Clave alternativa: son aquellas claves candidata que no han sido escogidas como clave primaria. </li></ul></ul></ul><ul><ul><li>Clave ajena : Se denomina clave ajena de una relación R2 a un conjunto no vacío de atributos cuyos valores han de coincidir con los valores de la clave primaria de una relación R1. Cabe destacar que la clave ajena y la correspondiente clave primaria han de estar definidas sobre los mismos dominios. </li></ul></ul>ÍNDICE
  8. 8. MODELO RELACIONAL. CLAVES <ul><li>Claves: </li></ul><ul><ul><li>Veamos un ejemplo de clave ajena: </li></ul></ul>ÍNDICE 2 87456321S Sánchez José 1 54789321C Jiménez Pedro 1 28689555B Pérez Juan Cod_departamento DNI Apellidos Nombre 2 Historia 1 Ciencias Cod_departamento Nombre
  9. 9. MODELO RELACIONAL. RESTRICCIONES <ul><li>Restricciones: </li></ul><ul><ul><li>Las tablas sólo contienen un tipo de filas. </li></ul></ul><ul><ul><li>Todas las filas tienen el mismo número de campos o columnas. </li></ul></ul><ul><ul><li>Cada campo o columna tiene un nombre único. </li></ul></ul><ul><ul><li>En cada fila, cada campo tiene un único valor. </li></ul></ul><ul><ul><li>Ese valor debe estar dentro del domino del campo de dicha fila o columna. </li></ul></ul><ul><ul><li>No hay dos tuplas iguales. </li></ul></ul><ul><ul><li>El orden de las tuplas no es significativo. </li></ul></ul><ul><ul><li>El orden de los atributos (columnas) no es significativo. </li></ul></ul><ul><ul><li>Cada atributo sólo puede tomar un único valor del dominio. </li></ul></ul><ul><ul><li>Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo. </li></ul></ul>ÍNDICE
  10. 10. MODELO RELACIONAL. ÁLGEBRA RELACIONAL <ul><li>Álgebra Relacional: </li></ul><ul><li>Es el lenguaje de consulta del modelo relacional. Nos va a permitir obtener información de las tablas que definen nuestro modelo relacional mediante una serie de operadores que dadas una o varias tablas nos dan como resultado una nueva tabla. </li></ul>ÍNDICE
  11. 11. MODELO RELACIONAL. ÁLGEBRA RELACIONAL <ul><li>Álgebra Relacional: </li></ul><ul><li>Las operaciones son las siguientes: </li></ul><ul><ul><li>Operadores primitivos </li></ul></ul><ul><ul><ul><li>Unarios: Trabajan con una única tabla . </li></ul></ul></ul><ul><ul><ul><ul><li>Selección (σ) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Proyección (π) </li></ul></ul></ul></ul><ul><ul><ul><li>Binarias: Trabajan con dos tablas </li></ul></ul></ul><ul><ul><ul><ul><li>Unión (U) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Diferencia (-) </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Producto cartesiano (x) </li></ul></ul></ul></ul><ul><ul><li>Operadores derivados : Obtenidas por composición de varias operaciones de las citadas anteriormente </li></ul></ul><ul><ul><ul><li>Combinación ( θ ) </li></ul></ul></ul><ul><ul><ul><li>Intersección (∩) </li></ul></ul></ul>ÍNDICE
  12. 12. MODELO RELACIONAL. AR. SELECCIÓN ( σ) <ul><li>Álgebra Relacional. Selección ( σ ): </li></ul><ul><li>La selección , también llamada restricción, de una relación mediante una condición, da como resultado una relación formada por el subconjunto de tuplas que satisface la expresión. </li></ul>ÍNDICE EMPLEADOS σ apellidos=“Pérez ” (EMPLEADOS) 1 45215632L Pérez Julián 1 28689555B Pérez Juan Cod_departamento DNI Apellidos Nombre 1 45215632L Pérez Julián 2 87456321S Sánchez José 1 54789321C Jiménez Pedro 1 28689555B Pérez Juan Cod_departamento DNI Apellidos Nombre
  13. 13. MODELO RELACIONAL. AR. PROYECCIÓN ( π) <ul><li>Álgebra Relacional. Proyección ( π ): </li></ul><ul><li>La proyección de una relación sobre un subconjunto de sus atributos es una relación definida sobre ellos; es, por tanto, un subconjunto vertical de la relación a la que se aplica el operador. </li></ul>ÍNDICE EMPLEADOS π nombre,apellidos (EMPLEADOS) Pérez Julián Sánchez José Jiménez Pedro Pérez Juan Apellidos Nombre 1 45215632L Pérez Julián 2 87456321S Sánchez José 1 54789321C Jiménez Pedro 1 28689555B Pérez Juan Cod_departamento DNI Apellidos Nombre
  14. 14. MODELO RELACIONAL. AR. UNIÓN ( U) <ul><li>Álgebra Relacional. Unión ( U ): </li></ul><ul><li>La unión de dos relaciones compatibles (los campos están definidos sobre el mismo dominio) en su esquema es otra relación definida sobre el mismo esquema de relación, cuya extensión estará constituida por las tuplas que pertenezcan a r o r´ o a ambas (se eliminarán las tuplas duplicadas puesto que se trata de una relación). </li></ul>ÍNDICE
  15. 15. MODELO RELACIONAL. AR. DIFERENCIA (- ) <ul><li>Álgebra Relacional. Diferencia (-): </li></ul><ul><li>La diferencia de dos relaciones compatibles (los campos están definidos sobre el mismo dominio) en su esquema es otra relación definida sobre el mismo esquema de relación, cuya extensión estará constituida por las tuplas que pertenezcan a r pero no a r´. </li></ul><ul><li>No es lo mismo hacer r-r´ que r´-r. El resultado será una relación diferente. </li></ul>ÍNDICE
  16. 16. MODELO RELACIONAL.AR.PRODUCTO CARTESIANO(X ) <ul><li>Álgebra Relacional. Producto cartesiano (x): </li></ul><ul><li>El producto cartesiano de dos relaciones de cardinalidades m y m´es una relación cuyo esquema estará definido sobre la unión de los atributos de ambas relaciones, y cuya extensión estará constituida por las m x m´tuplas formadas concatenando cada tupla de la primera relación con cada una de las tuplas de la segunda. </li></ul><ul><li>Nº columnas= Suma de las columnas de las dos tablas. </li></ul><ul><li>Nº Filas = El producto de las filas de T1 por las filas de T2. </li></ul>ÍNDICE
  17. 17. MODELO RELACIONAL. AR. COMBINACIÓN ( θ ) <ul><li>Álgebra Relacional. Combinación ( θ ): </li></ul>ÍNDICE EMP EMP θ DPTO = Π EMP.nombre,apellidos,dni,DPTO.cod,DPTO.nombre ( σ EMP.cod=DPTO.cod (EMP X DPTO) ) DPTO 2 Historia 1 Ciencias Cod Nombre 1 45215632L Pérez Julián 2 87456321S Sánchez José 1 54789321C Jiménez Pedro 1 28689555B Pérez Juan Cod DNI Apellidos Nombre 1 2 1 1 Cod Ciencias 45215632L Pérez Julián Historia 87456321S Sánchez José Ciencias 54789321C Jiménez Pedro Ciencias 28689555B Pérez Juan Nombre dpto DNI Apellidos Nombre
  18. 18. MODELO RELACIONAL. AR. COMBINACIÓN ( θ ) <ul><li>Álgebra Relacional. Combinación ( θ ): </li></ul>ÍNDICE
  19. 19. MODELO RELACIONAL. AR. INTERSECCIÓN ( ∩ ) <ul><li>Álgebra Relacional. Intersección ( ∩ ): </li></ul><ul><li>La intersección de dos relaciones compatibles (los campos están definidos sobre el mismo dominio) en su esquema es otra relación definida sobre el mismo esquema de relación, cuya extensión estará constituida por las tuplas que pertenezcan a ambas relaciones. </li></ul>ÍNDICE
  20. 20. PASOS EN EL DISEÑO DE DATOS ÍNDICE E-R DFD Modelo lógico de datos Modelo físico de datos Arquitectura de procesos (Diseño Modular) Descripción de los módulos (Diseño procedimental) Esquema de BD y ficheros Cuadernos de carga Codificación y pruebas Análisis (Qué) Lenguaje comprensible por el usuario Diseño de alto nivel (arquitectónico) Diseño de bajo nivel (detallado) Diseño (Cómo) Organización lógica Decisiones concretas: organización y rendimiento Implementación Lenguaje comprensible por la máquina Enfoque de datos Enfoque funcional ERS
  21. 21. PASOS EN EL DISEÑO DE DATOS ÍNDICE E-R Modelo lógico de datos Modelo físico de datos Esquema de BD y ficheros Diseño de alto nivel (arquitectónico) Diseño de bajo nivel (detallado) Enfoque de datos <ul><li>Transformación del esquema conceptual al esquema lógico </li></ul><ul><li>Normalización del esquema lógico </li></ul>ERS TEMA 9 TEMA 11
  22. 22. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación del esquema conceptual </li></ul><ul><li>El paso de un esquema en el modelo E/R al relacional está basado en los tres principios siguientes: </li></ul><ul><ul><li>Todo tipo de entidad se convierte en una relación. </li></ul></ul><ul><ul><li>Todo tipo de interrelación N:M se transforma en una relación. </li></ul></ul><ul><ul><li>Todo tipo de interrelación 1:N se traduce en el fenómeno de propagación de clave o se crea una nueva relación. </li></ul></ul>ÍNDICE Modelo E/R Entidades, atributos, relaciones Modelo lógico Tablas
  23. 23. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones N:M : Se transforma en una relación (tabla) que tendrá como clave primaria la concatenación de las claves primarias de las entidades involucradas. El resto de atributos serán los que pueda tener la interrelación. </li></ul></ul><ul><ul><li>Además, cada uno de los atributos que forman la clave primaria de esta relación son clave ajena respecto a cada una de las tablas donde este atributo es clave primaria. </li></ul></ul>ÍNDICE
  24. 24. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones N:M : Un ejemplo. </li></ul></ul>ÍNDICE
  25. 25. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones 1:N : Se propaga la clave primaria del tipo de entidad que tiene la cardinalidad máxima 1 a la que tiene N, es decir, en el sentido de la flecha. </li></ul></ul><ul><ul><li>Además, los atributos que forman la clave primaria que se propagan son clave ajena respecto a la tabla donde este atributo es clave primaria. </li></ul></ul><ul><ul><li>Además, si la relación tiene atributos, se propagan en el mismo sentido. </li></ul></ul>ÍNDICE
  26. 26. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones 1:N : Ejemplo </li></ul></ul>ÍNDICE <ul><ul><li>Como vemos en la figura, al ser la cardinalidad de EDITORIAL (1,1), no pueden admitirse valores nulos en la clave ajena pero se han de admitir, en cambio, valores nulos si la cardinalidad es (0,1). A esto lo llamaremos una RESTRICCIÓN. </li></ul></ul>
  27. 27. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones 1:N : Las interrelaciones 1:N también pueden transformarse como si se tratará de una interrelación N:M. Esta opción suele ser mejor cuando la interrelación tiene atributos. </li></ul></ul>ÍNDICE En este caso mejor
  28. 28. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones 1:1: no hay regla fija para la transformación de este tipo de interrelación. Por tanto podríamos crear una relación o propagar la clave. En este segundo caso la propagación de la clave puede efectuarse en ambas direcciones. </li></ul></ul><ul><ul><li>Los criterios para aplicar una transformación u otra y para propagar la clave se basan en las cardinalidades mínimas: </li></ul></ul><ul><ul><ul><li>Si las entidades que se asocian poseen cardinalidades (0,1), entonces la interrelación 1:1 se transformará en una relación. </li></ul></ul></ul>ÍNDICE
  29. 29. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones 1:1: Ejemplo transformación en una relación. </li></ul></ul>ÍNDICE Cod_mujer debe ser clave alternativa
  30. 30. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones 1:1: </li></ul></ul><ul><ul><ul><li>Si una de las entidades que participa en la interrelación posee cardinalidades (0,1), mientras que en la otra es (1,1) entonces conviene propagar la clave de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad con cardinalidad (0,1). </li></ul></ul></ul>ÍNDICE
  31. 31. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones 1:1: Ejemplo propagación. </li></ul></ul>ÍNDICE
  32. 32. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones 1:1: </li></ul></ul><ul><ul><ul><li>En el caso de que ambas entidades presenten cardinalidades (1,1), se puede propagar la clave de cualquiera de ellas a la tabla resultante de la otra, teniendo en cuenta en este caso los accesos más frecuentes y prioritarios a los datos. </li></ul></ul></ul>ÍNDICE
  33. 33. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones n-arias : Si las cardinalidades máximas de todas las entidades es N, entonces se crea una tabla por cada entidad y se creará otra donde la clave será la agregación de las claves de todas las tablas. </li></ul></ul><ul><ul><li>En el ejemplo de abajo la interrelación es N:N:N </li></ul></ul>ÍNDICE
  34. 34. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones n-arias : Si las cardinalidades máximas de todas las entidades es N, entonces se crea una tabla por cada entidad y se creará otra donde la clave será la agregación de las claves de todas las tablas. </li></ul></ul><ul><ul><li>En el ejemplo de abajo la interrelación es N:N:N </li></ul></ul>ÍNDICE
  35. 35. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones n-arias : Si las cardinalidades máximas de alguna entidad es 1, entonces se crea una tabla por cada entidad y se creará otra donde la clave será la agregación de las claves de las entidades donde la cardinalidad máxima es N. </li></ul></ul>ÍNDICE <ul><ul><li>Proveedor ( cod_proveedor , …) </li></ul></ul><ul><ul><li>Proyecto ( cod_proyecto , …) </li></ul></ul><ul><ul><li>Pieza ( cod_pieza , …) </li></ul></ul><ul><ul><li>Suministrar ( cod_pieza, cod_proyecto , cod_proveedor, …) </li></ul></ul>Clave ajena 1:N:M suministrar PROVEEDOR PROYECTO (0,1) (0,N) PIEZA (0,M) suministra Es suministrado por Suministra para
  36. 36. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones n-arias : Si todas las cardinalidades máximas de las entidades es 1, excepto 1, entonces se crea una tabla por cada entidad y la tabla que corresponde a la cardinalidad máxima N tendrá claves ajenas a las demás. </li></ul></ul>ÍNDICE <ul><ul><li>Proveedor ( cod_proveedor , …) </li></ul></ul><ul><ul><li>Proyecto ( cod_proyecto , …) </li></ul></ul><ul><ul><li>Pieza ( cod_pieza , cod_proveedor, cod_proyecto …) </li></ul></ul>Claves ajenas 1:1:M suministrar PROVEEDOR PROYECTO (0,1) (0,N) PIEZA (0,1) suministra Es suministrado por Suministra para
  37. 37. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Dependencias en existencia e identificación: La manera de transformar una interrelación de este tipo es utilizar el mecanismo de propagación de clave, creando una clave ajena, con nulos no permitidos, en la entidad dependiente. También deberemos obligar a una modificación y y un borrado en cascada. </li></ul></ul><ul><ul><li>Además, en el caso de dependencia en identificación la clave primaria de la relación de la entidad débil debe estar formada por la concatenación de las claves de las dos entidades participantes en la interrelación. </li></ul></ul>ÍNDICE
  38. 38. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Interrelaciones exclusivas: La manera de transformar una interrelación de este tipo es utilizar el mecanismo de propagación de clave, creando dos claves ajenas. Para obligar a dicha exclusividad necesitamos una restricción. (La forma de poner las restricciones en SQL lo veremos en el tema 11). </li></ul></ul><ul><ul><li>BECA ( cod_beca , ….) </li></ul></ul><ul><ul><li>PROYECTO ( cod_proyecto , …) </li></ul></ul><ul><ul><li>PROFESOR ( nif , cod_beca, cod_proyecto, …) </li></ul></ul><ul><ul><li>Restricción: Una de las dos claves ajenas es nula y la otra no. </li></ul></ul>ÍNDICE percibe PROFESOR BECA (0,N) (0,1) contratado (1,N) (0,N) PROYECTO N:1 N:M
  39. 39. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Tipos y subtipos: Los tipos y subtipos no son objetos que se puedan representar explícitamente en el modelo relacional. Ante una entidad y sus subtipos caben varias soluciones de transformación en el modelo relacional, con la consiguiente pérdida de semántica dependiendo de la estrategia elegida. Destacamos tres principalmente: </li></ul></ul>ÍNDICE
  40. 40. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Tipos y subtipos: </li></ul></ul><ul><ul><ul><li>Opción a : englobar todos los atributos de la entidad y sus subtipos en una sola relación, añadiendo un atributo adicional que indique el tipo (el discriminante de la jerarquía). Este discriminante podrá tener valores nulos si la jerarquía es parcial y todo lo contrario si la jerarquía es total. </li></ul></ul></ul><ul><ul><ul><li>En general, adoptaremos esta solución cuando los subtipos se diferencian en muy pocos atributos y las interrelaciones que se asocian con el resto de entidades sean las mismas para todos los subtipos. </li></ul></ul></ul>ÍNDICE No utilizar nunca en PARCIAL CON SOLAPAMIENTO Si total CON SOLAPAMIENTO, entonces el discriminante formará parte de la clave. Es posible que haya que incluir restricciones semánticas. Por ejemplo: Si el tipo de documento es ARTICULO, entonces el año de edición y el código de editorial deben ser nulos.
  41. 41. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Tipos y subtipos: </li></ul></ul><ul><ul><ul><li>Opción b : crear una relación para el supertipo y tantas relaciones como subtipos haya, con sus atributos correspondientes. </li></ul></ul></ul><ul><ul><ul><li>En general, adoptaremos esta solución cuando existen muchos atributos distintos entre los subtipos y se quieren mantener de todas maneras los atributos comunes a todos ellos en una relación. </li></ul></ul></ul>ÍNDICE Es posible que haya que incluir restricciones semánticas.
  42. 42. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Tipos y subtipos: </li></ul></ul><ul><ul><ul><li>Opción c : Considerar relaciones distintas para cada subtipo, que contengan además los atributos comunes. </li></ul></ul></ul><ul><ul><ul><li> En general, adoptaremos esta solución cuando existen muchos atributos distintos entre los subtipos, pocos atributos comunes en el supertipo y existan pocas relaciones en las que participe el supertipo. </li></ul></ul></ul>ÍNDICE Esta opción sólo nos la podemos plantear si la generalización es total y sin solapamiento. Es posible que haya que incluir restricciones semánticas. Por ejemplo: Si el tipo de documento es ARTICULO, entonces el año de edición y el código de editorial deben ser nulos.
  43. 43. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>Transformación de interrelaciones </li></ul><ul><ul><li>Tipos y subtipos: Podemos, por tanto, elegir entre tres estrategias distintas para la transformación de un tipo y sus subtipos al modelo relacional . Sin embargo, desde un punto de vista exclusivamente semántico la opción b es la mejor. Por otra parte, desde el punto de vista de la eficiencia tenemos que tener en cuenta que: </li></ul></ul><ul><ul><ul><li>Opción a : El acceso a una fila que refleje toda la información de una determinada entidad es mucho más rápido (no hace falta combinar varias relaciones). </li></ul></ul></ul><ul><ul><ul><li>Opción b : La menos eficiente, aunque es la mejor desde el punto de vista exclusivamente semántico. </li></ul></ul></ul><ul><ul><ul><li>Opción c : Con esta solución aumentamos la eficiencia ante determinadas consultas (por ejemplo, las que afecten a todos los atributos de un subtipo) pero la disminuimos ante otras (como las que conciernen a los atributos comunes de los distintos subtipos) e introducimos redundancias. Esta solución es en la que se pierde más semántica. </li></ul></ul></ul><ul><ul><li>Elegiremos una estrategia u otra dependiendo de que sea la semántica o la eficiencia la que imprime para el usuario en un momento determinado. </li></ul></ul>ÍNDICE
  44. 44. TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL <ul><li>NOTACIÓN DEL DISEÑO LÓGICO DE DATOS </li></ul><ul><ul><li>Para cada relación obtenida creamos lo siguiente: </li></ul></ul>ÍNDICE NOMBRE_RELACIÓN (atrib1, atrib2, atrib3, …, atribn) PK( atributos que forman la clave principal ) AK1 (atributos de una clave alternativa) AK2 (……) Akn(…….)  Uno por cada clave alternativa FK1 (atributos de una clave ajena)/Entidad a la que referencia FK2 (…..)/Entidad FKn (…..)/Entidad  Uno por cada clave ajena Restricciones: atributo NOT NULL Cualquier otra restricción expresada en lenguaje natural * Comentarios*
  45. 45. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Introducción </li></ul><ul><ul><li>Cuando se diseña una B.D. mediante el modelo relacional, tenemos distintas alternativas, es decir, podemos obtener diferentes esquemas relacionales, y no todos ellos son equivalentes, ya que unos van a representar la realidad mejor que otros. </li></ul></ul><ul><ul><li>Las relaciones que resultan de la transformación del esquema E/R pueden presentar algunos problemas, derivados de fallos en la percepción del universo de discurso, en el diseño del esquema E/R o en el paso al modelo relacional. </li></ul></ul><ul><ul><li>En definitiva, el esquema relacional debe ser analiazado para comprobar que no presenta los problemas anteriormente citados, evitando la pérdida de información y la aparición de estados que no son válidos en el mundo real. </li></ul></ul><ul><ul><li>Ante las posibles dudas respecto a si un determinado esquema relacional es correcto, es mejor aplicar a dicho esquema un método formal de análisis que determine lo que pueda estar equivocado en el mismo y nos permita deducir otro que nos asegure el cumplimiento de ciertos requisitos; este método formal es la teoría de la normalización. </li></ul></ul>ÍNDICE
  46. 46. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Introducción </li></ul><ul><ul><li>Se ha de comentar que la anomalias a las que da lugar un diseño inadecuado de una B.D se producen sólo en procesos de actualización y nunca en los de consulta. La aplicación de la teoría de la normalización consigue una disminución de dichas anomalías, evitando much os de los problemas que se pueden plantear en las actualizaciones. </li></ul></ul>ÍNDICE
  47. 47. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Noción intuitiva de las formas normales </li></ul><ul><ul><li>La teoría de la normalización consiste en obtener esquemas relacionales que cumplan unas determinadas condiciones, y se centra en lo que se conoce como formas normales. Se dice que un esquema lógico de datos está en una determinada forma normal si satisface determinado conjunto específico de restricciones. </li></ul></ul>ÍNDICE Todas las relaciones que están en la 5FN también están en 4FN, y así sucesivamente; sin embargo, existen relaciones que estando en 1FN no están en 2FN, ni estando en 2FN están en 3FN, etc. A fin de evitar las anomalías que describíamos anteriormente es preferible la 2FN a la 1FN, la 3FN es mejor que la 2FN, etc.
  48. 48. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Noción intuitiva de las formas normales </li></ul><ul><ul><li>1FN: Un atributo no puede tomar más de un valor. </li></ul></ul>ÍNDICE <ul><ul><li>La segunda (2FN) y la tercera (3FN) formas normales se formulan teniendo en cuenta la relación entre los campos claves y los que no forman parte de ninguna clave. </li></ul></ul><ul><ul><li>2FN: Si además de estar en 1FN, todos los campos que no formen parte de ninguna clave candidata suministran información acerca de la clave completa. Ejemplo: </li></ul></ul><ul><ul><li>VENTAS(Cod_pieza, cod_almacén, cantidad, dirección_almacén) </li></ul></ul><ul><ul><li>PK(Cod_pieza, cod_almacén) </li></ul></ul><ul><ul><li>La dirección del almacén es un campo que da información sobre el código del almacén pero no de la clave completa por lo que esta relación viola la 2FN. Para evitarlo podríamos descomponer la relación en: </li></ul></ul><ul><ul><li>NUMERO_VENTAS( Cod_pieza, cod_almacén, cantidad) </li></ul></ul><ul><ul><li>ALMACENES( Cod_almacén, dirección_almacén) </li></ul></ul>
  49. 49. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Noción intuitiva de las formas normales </li></ul><ul><ul><li>3FN: Además de estar en la 1FN y en la 2FN, los campos que no forman parte de la clave candidata deben facilitar información sólo acerca de la(s) clave(s) candidatas, y no acerca de otros campos. Ejemplo: </li></ul></ul><ul><ul><li>EMPLEADOS( cod_empleado, cod_departamento, nombre_departamento) </li></ul></ul><ul><ul><li>PK(cod_empleado) </li></ul></ul><ul><ul><li>Esta relación no está en 3FN ya que el nombre del departamento es un hecho acerca del código del departamento además de serlo, transitivamente, del código de empleado. </li></ul></ul><ul><ul><li>Para conseguir la 3FN sería conveniente descomponerlo de la siguiente manera: </li></ul></ul><ul><ul><li>EMPLEADOS( cod_empleado, nombre_departamento) </li></ul></ul><ul><ul><li>DEPARTAMENTO( cod_departamento, nombre_departamento) </li></ul></ul>ÍNDICE
  50. 50. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Noción intuitiva de las formas normales </li></ul><ul><ul><li>Forma normal de Boyce-Codd (FNBC): Una relación está en FNBC si, y solo si, las claves candidatas son los únicos descriptores sobre los que se facilita información por cualquier otro atributo. Ejemplo: </li></ul></ul><ul><ul><li>PRESTAMOS (num_socio, nombre_socio, cod_libro, fecha_prestamo) </li></ul></ul><ul><ul><li>PK(num_socio, cod_libro) </li></ul></ul><ul><ul><li>AK(nombre_socio, cod_libro) </li></ul></ul><ul><ul><li>Aunque está en 3FN no está en FNBC porque el número de socio es una información acerca del nombre de socio y viceversa; sin embargo, ninguno de estos dos atributos son clave (aunque formen parte de la clave). Para solucionarlo: </li></ul></ul><ul><ul><li>PRESTAMOS (num_socio, cod_libro, fecha_prestamo) </li></ul></ul><ul><ul><li>SOCIOS (num_socio, nombre_socio) </li></ul></ul>ÍNDICE
  51. 51. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Dependencias funcionales.Teoría de la normalización </li></ul><ul><ul><li>Ya hemos visto la noción intuitiva de las formas normales pero no podemos normalizar un esquema lógico de datos de manera intuitiva. </li></ul></ul><ul><ul><li>La normalización a nivel teórico se basa en el concepto de dependencia funcional. Existen muchos tipos de dependencias (funcionales, multivaluadas, de combinación, etc.), pero nosotros sólo trataremos las dependencias funcionales, ya que son las que se encuentran asociadas a las tres primeras formas normales. </li></ul></ul>ÍNDICE
  52. 52. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Dependencias funcionales.Teoría de la normalización </li></ul><ul><ul><li>Definición de dependencia funcional: </li></ul></ul><ul><ul><li>Decimos que un descriptor Y (conjunto de campos) depende funcionalmente del descriptor X o que X determina o implica a Y , si, y solo si, cada valor de X tiene asociado en todo momento un único valor de Y. Lo que se representa como: X  Y . </li></ul></ul><ul><ul><li>Así, por ejemplo, podemos decir que: </li></ul></ul><ul><ul><li>COD_ALMACEN  DIRECCION_ALMACEN </li></ul></ul><ul><ul><li>Ya que cada código de almacén existe una sola dirección o que el código del almacén determina su dirección. En esta dependencia al COD_ALMACÉN (X) lo denominaremos Implicante y a DIRECCIÓN_ALMACÉN (Y) Implicado . </li></ul></ul>ÍNDICE
  53. 53. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Dependencias funcionales.Teoría de la normalización </li></ul><ul><ul><li>Dependencia funcional completa y 2FN: </li></ul></ul><ul><ul><li>Si el descriptor X es compuesto: (X1, X2), se dice que Y tiene dependencia funcional completa o plena respecto de X, si depende funcionalmente de X, pero no depende de ningún subconjunto del mismo, esto es: X  Y , pero X1 -/->Y y X2 -/->Y . </li></ul></ul><ul><ul><li>Así, por ejemplo, si suponemos que en una empresa un empleado puede trabajar en varios proyectos, realizando una sola función en cada uno de ellos (consultor, analista, programador, etc.), aunque pueda ser distinta según el proyecto, tendríamos que: </li></ul></ul><ul><ul><li>(DNI_EMPLEADO, COD_PROYECTO)  FUNCIÓN </li></ul></ul><ul><ul><li>es una dependencia completa, ya que ninguno de los elementos del descriptor por separado determina el implicado, al poder tener un empleado muchas funciones, lo mismo que un proyecto. </li></ul></ul>ÍNDICE
  54. 54. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Dependencias funcionales.Teoría de la normalización </li></ul><ul><ul><li>Dependencia funcional completa y 2FN: </li></ul></ul><ul><ul><li>Sin embargo, la dependencia: </li></ul></ul><ul><ul><li>(COD_PIEZA, COD_ALMACÉN)  DIRECCIÓN_ALMACÉN </li></ul></ul><ul><ul><li>no es completa, ya que: COD_ALMACÉN  DIRECCIÓN_ALMACÉN </li></ul></ul><ul><ul><li>Podemos ahora definir la 2FN de manera más rigurosa diciendo que un registro está en 2FN si: </li></ul></ul><ul><ul><ul><li>Está en 1FN. </li></ul></ul></ul><ul><ul><ul><li>Todo campo no clave tiene una dependencia funcional completa respecto de las claves candidatas. </li></ul></ul></ul>ÍNDICE
  55. 55. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Dependencias funcionales.Teoría de la normalización </li></ul><ul><ul><li>Dependencia funcional completa y 2FN: </li></ul></ul><ul><ul><li>Veamos un ejemplo: la relación </li></ul></ul><ul><ul><li>VENTAS (cod_pieza, cod_almacén, cantidad, dirección_almacén) </li></ul></ul><ul><ul><li>no se encuentra en 2FN ya que la clave es el código de la pieza y el código del almacén y la dirección del almacén no presenta dependencia funcional completa ya que: </li></ul></ul><ul><ul><li>COD_ALMACÉN  DIRECCIÓN_ALMACÉN </li></ul></ul><ul><ul><li>Sin embargo, las relaciones N_VENTAS( cod_pieza, cod_almacén, cantidad) y ALMACENES( cod_almacén, dirección_almacén) sí están en 2FN, ya que: COD_PIEZA, COD_ALMACÉN  CANTIDAD es una dependencia completa y COD_ALMACÉN  DIRECCIÓN_ALMACÉN también lo es, ya que en el caso de que la clave sea simple (esté formada por un solo campo) siempre que se encuentre en 1FN estará también en 2FN. </li></ul></ul>ÍNDICE
  56. 56. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Dependencia funcional transitiva y 3FN </li></ul><ul><ul><li>Si existen las siguientes dependencias funcionales que se muestran en el diagrama. </li></ul></ul>ÍNDICE <ul><ul><li>Se dice que Z tiene una dependencia transitiva respecto de X a través de Y, lo que se representa como: X  Z . </li></ul></ul><ul><ul><li>Por ejemplo, si suponemos que se dan las siguientes dependencias: </li></ul></ul><ul><ul><li>COD_EMPLEADO  COD_DEPARTAMENTO </li></ul></ul><ul><ul><li>COD_DEPARTAMENTO  NOMBRE_DEPARTAMENTO </li></ul></ul><ul><ul><li>COD_DEPARTAMENTO -/-> COD_EMPLEADO </li></ul></ul><ul><ul><li>Podemos afirmar que COD_EMPLEADO  NOMBRE_DEPARTAMENTO transitivamente a través de COD_DEPARTAMENTO . </li></ul></ul>
  57. 57. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Dependencia funcional transitiva y 3FN </li></ul><ul><ul><li>S e dice que un registro se encuentra en 3FN si: </li></ul></ul><ul><ul><ul><li>Está en 2FN. </li></ul></ul></ul><ul><ul><ul><li>Ningún campo no clave depende transitivamente de ninguna clave. </li></ul></ul></ul><ul><ul><li>Ejemplo: La relación </li></ul></ul><ul><ul><li>EMPLEADOS (cod_empleado, cod_depto, nombre_depto) no se encuentra en 3FN ya que la clave es el COD_EMPLEADO y: </li></ul></ul><ul><ul><li>COD_EMPLEADO  COD_DEPARTAMENTO </li></ul></ul><ul><ul><li>COD_DEPARTAMENTO  NOMBRE_DEPARTAMENTO </li></ul></ul><ul><ul><li>Por tanto, COD_EMPLEADO  NOMBRE_DEPARTAMENTO y esto significa que un campo no clave (nombre del departamento) depende transitivamente de la clave (código de empleado). </li></ul></ul>ÍNDICE
  58. 58. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Forma normal de Boyce-Codd (FNBC) </li></ul><ul><ul><li>Se dice que un registro se encuentra en FNBC si, y solo si, todo determinante es clave, donde por determinante entendemos cualquier conjunto de campos del que otro campo depende funcionalmente de forma completa. Ejemplo: dada la relación </li></ul></ul><ul><ul><li>VENTAS( cod_pieza, cod_almacén, nombre_almacén, cantidad) donde suponemos que los almacenes se identifican tanto por su código como por su nombre. Por tanto, en la relación VENTAS existen dos claves candidatas: (cod_pieza, cod_almacén) y (cod_pieza, nombre_almacén) </li></ul></ul><ul><ul><li>Veamos cuales son los determinantes: </li></ul></ul><ul><ul><li>(cod_pieza, cod_almacén) y (cod_pieza, nombre_almacén) son determinantes al ser claves por cod_almacén y nombre_almacén también son determinantes por sí solo ya que: </li></ul></ul><ul><ul><li>cod_almacén  nombre almacén y al contrario. Por tanto esta relación no está en FNBC, ya que no todo determinante es clave. Estos campos forman parte de la clave pero no son la clave. </li></ul></ul>ÍNDICE
  59. 59. NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS <ul><li>Forma normal de Boyce-Codd (FNBC) </li></ul><ul><ul><li>Si queremos cumplir la FNBC deberemos descomponer la relación, por ejemplo, de la siguiente manera: </li></ul></ul><ul><ul><li>ALMACENES( cod_almacén, nombre_almacén) </li></ul></ul><ul><ul><li>N_VENTAS( cod_pieza, cod_almacén, cantidad) donde en la primera relación existen dos claves: cod_almacén y nombre_almacén y ambos campos son también determinante ya que: </li></ul></ul><ul><ul><li>cod_almacén  nombre_almacén </li></ul></ul><ul><ul><li> nombre_almacén  cod_almacén por tanto está en FNBC. Mientras que en la segunda relación existe una clave compuesta (cod_pieza, cod_almacén) y un único determinante formado por esos dos campos ya que: </li></ul></ul><ul><ul><li>cod_pieza, cod_almacén  cantidad por lo que se encuentra en FNBC. </li></ul></ul>ÍNDICE

×