PresentacióN Tema 8

Tema 9: Diseño lógico de datos. Modelo Relacional Presentación y objetivos Elementos del modelo relacional Claves Restricciones Álgebra relacional Pasos en el Diseño de datos Transformación del esquema conceptual al esquema lógico Transformación de interrelaciones N:M Transformación de interrelaciones 1:N Transformación de interrelaciones 1:1 Transformación n-arias Transformación de dependencia en existencia e identificación Transformación Interrelaciones exclusivas Transformación Generalizaciones Normalización del esquema lógico de datos Introducción Noción intuitiva de las formas normales Dependencias funcionales. Teoría de la normalización Definición de dependencia funcional Dependencia funcional completa y 2FN Dependencia funcional transitiva y 3FN

MODELO RELACIONAL. PRESENTACIÓN Y OBJETIVOS Presentación y objetivos. 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). 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: 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. 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). Flexibilidad : en el sentido de poder presentar a cada usuario los datos de la forma en que éste prefiera. 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. ÍNDICE

MODELO RELACIONAL. PRESENATICÓN Y OBJETIVOS Presentación y objetivos Para conseguir los objetivos citados, Codd introduce el concepto de relación (tabla) como estructura básica del modelo. 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. ÍNDICE

MODELO RELACIONAL. ELEMENTOS Tablas o relación: Conjunto de campos, cada uno con su propio dominio, para describir un conjunto de entidades del mismo tipo. Ejemplo: Tabla persona ÍNDICE

MODELO RELACIONAL. ELEMENTOS Tupla o fila: Conjuntos de valores que dentro de una tabla sirven para describir una ocurrencia de la entidad que describimos mediante la tabla. Ej: Fila de la tabla persona. ÍNDICE

MODELO RELACIONAL. ELEMENTOS Tupla o fila: ÍNDICE

MODELO RELACIONAL. CLAVES Claves: 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: Clave primaria: es aquella clave candidata que el usuario escogerá, por consideraciones ajenas al modelo relacional, para identificar las tuplas de la relación. Clave alternativa: son aquellas claves candidata que no han sido escogidas como clave primaria. 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. ÍNDICE

MODELO RELACIONAL. CLAVES Claves: Veamos un ejemplo de clave ajena: Í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

MODELO RELACIONAL. RESTRICCIONES Restricciones: Las tablas sólo contienen un tipo de filas. Todas las filas tienen el mismo número de campos o columnas. Cada campo o columna tiene un nombre único. En cada fila, cada campo tiene un único valor. Ese valor debe estar dentro del domino del campo de dicha fila o columna. No hay dos tuplas iguales. El orden de las tuplas no es significativo. El orden de los atributos (columnas) no es significativo. Cada atributo sólo puede tomar un único valor del dominio. Ningún atributo que forme parte de la clave primaria de una relación puede tomar un valor nulo. ÍNDICE

MODELO RELACIONAL. ÁLGEBRA RELACIONAL Álgebra Relacional: 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. ÍNDICE

MODELO RELACIONAL. ÁLGEBRA RELACIONAL Álgebra Relacional: Las operaciones son las siguientes: Operadores primitivos Unarios: Trabajan con una única tabla . Selección (σ) Proyección (π) Binarias: Trabajan con dos tablas Unión (U) Diferencia (-) Producto cartesiano (x) Operadores derivados : Obtenidas por composición de varias operaciones de las citadas anteriormente Combinación ( θ ) Intersección (∩) ÍNDICE

MODELO RELACIONAL. AR. SELECCIÓN ( σ) Álgebra Relacional. Selección ( σ ): 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. Í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

MODELO RELACIONAL. AR. PROYECCIÓN ( π) Álgebra Relacional. Proyección ( π ): 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. Í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

MODELO RELACIONAL. AR. UNIÓN ( U) Álgebra Relacional. Unión ( U ): 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). ÍNDICE

MODELO RELACIONAL. AR. DIFERENCIA (- ) Álgebra Relacional. Diferencia (-): 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´. No es lo mismo hacer r-r´ que r´-r. El resultado será una relación diferente. ÍNDICE

MODELO RELACIONAL.AR.PRODUCTO CARTESIANO(X ) Álgebra Relacional. Producto cartesiano (x): 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. Nº columnas= Suma de las columnas de las dos tablas. Nº Filas = El producto de las filas de T1 por las filas de T2. ÍNDICE

MODELO RELACIONAL. AR. COMBINACIÓN ( θ ) Álgebra Relacional. Combinación ( θ ): Í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

MODELO RELACIONAL. AR. COMBINACIÓN ( θ ) Álgebra Relacional. Combinación ( θ ): ÍNDICE

MODELO RELACIONAL. AR. INTERSECCIÓN ( ∩ ) Álgebra Relacional. Intersección ( ∩ ): 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. ÍNDICE

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

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 Transformación del esquema conceptual al esquema lógico Normalización del esquema lógico ERS TEMA 9 TEMA 11

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación del esquema conceptual El paso de un esquema en el modelo E/R al relacional está basado en los tres principios siguientes: Todo tipo de entidad se convierte en una relación. Todo tipo de interrelación N:M se transforma en una relación. 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. ÍNDICE Modelo E/R Entidades, atributos, relaciones Modelo lógico Tablas

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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. 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. ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones Interrelaciones N:M : Un ejemplo. ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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. 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. Además, si la relación tiene atributos, se propagan en el mismo sentido. ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones Interrelaciones 1:N : Ejemplo ÍNDICE 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.

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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. ÍNDICE En este caso mejor

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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. Los criterios para aplicar una transformación u otra y para propagar la clave se basan en las cardinalidades mínimas: Si las entidades que se asocian poseen cardinalidades (0,1), entonces la interrelación 1:1 se transformará en una relación. ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones Interrelaciones 1:1: Ejemplo transformación en una relación. ÍNDICE Cod_mujer debe ser clave alternativa

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones Interrelaciones 1:1: 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). ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones Interrelaciones 1:1: Ejemplo propagación. ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones Interrelaciones 1:1: 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. ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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. En el ejemplo de abajo la interrelación es N:N:N ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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. ÍNDICE Proveedor ( cod_proveedor , …) Proyecto ( cod_proyecto , …) Pieza ( cod_pieza , …) Suministrar ( cod_pieza, cod_proyecto , cod_proveedor, …) Clave ajena 1:N:M suministrar PROVEEDOR PROYECTO (0,1) (0,N) PIEZA (0,M) suministra Es suministrado por Suministra para

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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. ÍNDICE Proveedor ( cod_proveedor , …) Proyecto ( cod_proyecto , …) Pieza ( cod_pieza , cod_proveedor, cod_proyecto …) Claves ajenas 1:1:M suministrar PROVEEDOR PROYECTO (0,1) (0,N) PIEZA (0,1) suministra Es suministrado por Suministra para

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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. 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. ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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). BECA ( cod_beca , ….) PROYECTO ( cod_proyecto , …) PROFESOR ( nif , cod_beca, cod_proyecto, …) Restricción: Una de las dos claves ajenas es nula y la otra no. ÍNDICE percibe PROFESOR BECA (0,N) (0,1) contratado (1,N) (0,N) PROYECTO N:1 N:M

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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: ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones Tipos y subtipos: 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. 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. Í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.

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones Tipos y subtipos: Opción b : crear una relación para el supertipo y tantas relaciones como subtipos haya, con sus atributos correspondientes. 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. ÍNDICE Es posible que haya que incluir restricciones semánticas.

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones Tipos y subtipos: Opción c : Considerar relaciones distintas para cada subtipo, que contengan además los atributos comunes. 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. Í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.

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL Transformación de interrelaciones 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: 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). Opción b : La menos eficiente, aunque es la mejor desde el punto de vista exclusivamente semántico. 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. 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. ÍNDICE

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL NOTACIÓN DEL DISEÑO LÓGICO DE DATOS Para cada relación obtenida creamos lo siguiente: Í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*

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Introducción 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. 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. 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. 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. ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Introducción 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. ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Noción intuitiva de las formas normales 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. Í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.

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Noción intuitiva de las formas normales 1FN: Un atributo no puede tomar más de un valor. ÍNDICE 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. 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: VENTAS(Cod_pieza, cod_almacén, cantidad, dirección_almacén) PK(Cod_pieza, cod_almacén) 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: NUMERO_VENTAS( Cod_pieza, cod_almacén, cantidad) ALMACENES( Cod_almacén, dirección_almacén)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Noción intuitiva de las formas normales 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: EMPLEADOS( cod_empleado, cod_departamento, nombre_departamento) PK(cod_empleado) 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. Para conseguir la 3FN sería conveniente descomponerlo de la siguiente manera: EMPLEADOS( cod_empleado, nombre_departamento) DEPARTAMENTO( cod_departamento, nombre_departamento) ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Noción intuitiva de las formas normales 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: PRESTAMOS (num_socio, nombre_socio, cod_libro, fecha_prestamo) PK(num_socio, cod_libro) AK(nombre_socio, cod_libro) 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: PRESTAMOS (num_socio, cod_libro, fecha_prestamo) SOCIOS (num_socio, nombre_socio) ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Dependencias funcionales.Teoría de la normalización Ya hemos visto la noción intuitiva de las formas normales pero no podemos normalizar un esquema lógico de datos de manera intuitiva. 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. ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Dependencias funcionales.Teoría de la normalización Definición de dependencia funcional: 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 . Así, por ejemplo, podemos decir que: COD_ALMACEN  DIRECCION_ALMACEN 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 . ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Dependencias funcionales.Teoría de la normalización Dependencia funcional completa y 2FN: 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 . 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: (DNI_EMPLEADO, COD_PROYECTO)  FUNCIÓN 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. ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Dependencias funcionales.Teoría de la normalización Dependencia funcional completa y 2FN: Sin embargo, la dependencia: (COD_PIEZA, COD_ALMACÉN)  DIRECCIÓN_ALMACÉN no es completa, ya que: COD_ALMACÉN  DIRECCIÓN_ALMACÉN Podemos ahora definir la 2FN de manera más rigurosa diciendo que un registro está en 2FN si: Está en 1FN. Todo campo no clave tiene una dependencia funcional completa respecto de las claves candidatas. ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Dependencias funcionales.Teoría de la normalización Dependencia funcional completa y 2FN: Veamos un ejemplo: la relación VENTAS (cod_pieza, cod_almacén, cantidad, dirección_almacén) 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: COD_ALMACÉN  DIRECCIÓN_ALMACÉN 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. ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Dependencia funcional transitiva y 3FN Si existen las siguientes dependencias funcionales que se muestran en el diagrama. ÍNDICE Se dice que Z tiene una dependencia transitiva respecto de X a través de Y, lo que se representa como: X  Z . Por ejemplo, si suponemos que se dan las siguientes dependencias: COD_EMPLEADO  COD_DEPARTAMENTO COD_DEPARTAMENTO  NOMBRE_DEPARTAMENTO COD_DEPARTAMENTO -/-> COD_EMPLEADO Podemos afirmar que COD_EMPLEADO  NOMBRE_DEPARTAMENTO transitivamente a través de COD_DEPARTAMENTO .

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Dependencia funcional transitiva y 3FN S e dice que un registro se encuentra en 3FN si: Está en 2FN. Ningún campo no clave depende transitivamente de ninguna clave. Ejemplo: La relación EMPLEADOS (cod_empleado, cod_depto, nombre_depto) no se encuentra en 3FN ya que la clave es el COD_EMPLEADO y: COD_EMPLEADO  COD_DEPARTAMENTO COD_DEPARTAMENTO  NOMBRE_DEPARTAMENTO 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). ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Forma normal de Boyce-Codd (FNBC) 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 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) Veamos cuales son los determinantes: (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: 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. ÍNDICE

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS Forma normal de Boyce-Codd (FNBC) Si queremos cumplir la FNBC deberemos descomponer la relación, por ejemplo, de la siguiente manera: ALMACENES( cod_almacén, nombre_almacén) 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: cod_almacén  nombre_almacén 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: cod_pieza, cod_almacén  cantidad por lo que se encuentra en FNBC. ÍNDICE

PresentacióN Tema 8

Más contenido relacionado

La actualidad más candente

Destacado

Similar a PresentacióN Tema 8

Último

PresentacióN Tema 8