PresentacióN Tema 8

59
Anális y diseño de aplicaciones informáticas de gestión (TEMA 9) Anális y diseño de aplicaciones informáticas de gestión (TEMA 9) Tema 9: Tema 9: Diseño lógico de datos. 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

description

Prueba

Transcript of PresentacióN Tema 8

Page 1: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

Tema 9: Tema 9: Diseño lógico de datos.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

Page 2: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. PRESENTACIÓN Y OBJETIVOSMODELO RELACIONAL. PRESENTACIÓN Y OBJETIVOS

Presentación y objetivos.Presentación y objetivos.Codd propone, a finales de los años sesenta, un modelo de datos basado en la 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 teoría de las relaciones, en donde los datos se estructuran en forma de relaciones (tablas).relaciones (tablas).El trabajo publicado por Codd presentaba un nuevo modelo de datos que 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:perseguía una serie de objetivos, que se pueden resumir en los siguientes:

– Independencia FísicaIndependencia Física: es decir, que el modo en el que se almacenan los : 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 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 accedan a esos datos no tengan que modificar sus programas por cambios en el almacenamiento físico.el almacenamiento físico.

– Independencia LógicaIndependencia Lógica: esto es, que el añadir, eliminar o modificar : esto es, que el añadir, eliminar o modificar objetos de la base de datos no repercuta en los programas y/o usuarios que 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).están accediendo a subconjuntos parciales de los mismos (vistas).

– FlexibilidadFlexibilidad: en el sentido de poder presentar a cada usuario los datos de la : en el sentido de poder presentar a cada usuario los datos de la forma en que éste prefiera.forma en que éste prefiera.

– SencillezSencillez: las características anteriores, así como unos lenguajes de usuario : las características anteriores, así como unos lenguajes de usuario muy sencillos, producen como resultado que el modelo de datos relacional sea muy sencillos, producen como resultado que el modelo de datos relacional sea fácil de comprender y de utilizar por parte del usuario final.fácil de comprender y de utilizar por parte del usuario final.

Page 3: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. PRESENATICÓN Y OBJETIVOSMODELO RELACIONAL. PRESENATICÓN Y OBJETIVOS

Presentación y objetivosPresentación y objetivosPara conseguir los objetivos citados, Codd introduce el concepto de Para conseguir los objetivos citados, Codd introduce el concepto de relación (tabla) como estructura básica del modelo.relación (tabla) como estructura básica del modelo.

En este tema, una vez que estudiemos el modelo relacional, lo que En este tema, una vez que estudiemos el modelo relacional, lo que haremos será convertir el modelo entidad interrelación creado en la 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 fase de análisis en una serie de tablas (o relaciones) con una serie de reglas.reglas.

Page 4: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. ELEMENTOSMODELO RELACIONAL. ELEMENTOS

Tablas o relación:Tablas o relación:Conjunto de campos, cada uno con su propio dominio, para describir un Conjunto de campos, cada uno con su propio dominio, para describir un conjunto de entidades del mismo tipo.conjunto de entidades del mismo tipo.

Ejemplo: Tabla personaEjemplo: Tabla persona

N o m b r e A p e l l i d o s D i r e c c i o n T e l e f o n o

Page 5: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. ELEMENTOSMODELO RELACIONAL. ELEMENTOS

Tupla o fila:Tupla o fila:Conjuntos de valores que dentro de una tabla sirven para describir una ocurrencia Conjuntos de valores que dentro de una tabla sirven para describir una ocurrencia de la entidad que describimos mediante la tabla.de la entidad que describimos mediante la tabla.

Ej: Fila de la tabla persona.Ej: Fila de la tabla persona.

J u a n P e r e z C \ S e v i l l a 9 5 5 6 6 7 7 8 8

Page 6: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. ELEMENTOSMODELO RELACIONAL. ELEMENTOS

Tupla o fila:Tupla o fila:

Page 7: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. CLAVESMODELO RELACIONAL. CLAVES

Claves:Claves:– Clave candidataClave candidata: : Conjunto no vacío de atributos que identifican Conjunto no vacío de atributos que identifican

unívoca y mínimamenteunívoca y mínimamente cada tupla (o fila). Siempre debe existir, al cada tupla (o fila). Siempre debe existir, al menos, una clave candidata ya que no pueden existir en una tabla dos menos, una clave candidata ya que no pueden existir en una tabla dos tuplas iguales. Si no se cumpliese este requisito deberíamos eliminar tuplas iguales. Si no se cumpliese este requisito deberíamos eliminar aquellos atributos que lo impidiesen. Una relación puede tener más de aquellos atributos que lo impidiesen. Una relación puede tener más de una clave candidata, entre las cuales se debe distinguir:una clave candidata, entre las cuales se debe distinguir: Clave primaria:Clave primaria: es aquella clave candidata que el usuario escogerá, por es aquella clave candidata que el usuario escogerá, por

consideraciones ajenas al modelo relacional, para identificar las tuplas de consideraciones ajenas al modelo relacional, para identificar las tuplas de la relación.la relación.

Clave alternativa:Clave alternativa: son aquellas claves candidata que no han sido son aquellas claves candidata que no han sido escogidas como clave primaria.escogidas como clave primaria.

– Clave ajenaClave ajena:: Se denomina clave ajena de una relación R2 a un Se denomina clave ajena de una relación R2 a un conjunto no vacío de atributos cuyos valores han de coincidir con los 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 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 clave ajena y la correspondiente clave primaria han de estar definidas sobre los mismos dominios.sobre los mismos dominios.

Page 8: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. CLAVESMODELO RELACIONAL. CLAVES

Claves:Claves:Veamos un ejemplo de clave ajena:Veamos un ejemplo de clave ajena:

287456321SSánchezJosé

154789321CJiménezPedro

128689555BPérezJuan

Cod_departamentoDNIApellidosNombre

2Historia

1Ciencias

Cod_departamentoNombre

Page 9: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. RESTRICCIONESMODELO RELACIONAL. RESTRICCIONES

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.

Page 10: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. ÁLGEBRA RELACIONALMODELO RELACIONAL. ÁLGEBRA 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.

Page 11: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. ÁLGEBRA RELACIONALMODELO RELACIONAL. ÁLGEBRA RELACIONAL

Álgebra Relacional:Álgebra Relacional:Las operaciones son las siguientes:– Operadores primitivos

– Unarios: Trabajan con una única tabla.1. Selección (σ)2. Proyección (π)

B. Binarias: Trabajan con dos tablas1. Unión (U)2. Diferencia (-)3. Producto cartesiano (x)

– Operadores derivados: Obtenidas por composición de varias operaciones de las citadas anteriormenteA. Combinación (θ)B. Intersección ( )∩

Page 12: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

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

145215632LPérezJulián

128689555BPérezJuan

Cod_departamentoDNIApellidosNombre

145215632LPérezJulián

287456321SSánchezJosé

154789321CJiménezPedro

128689555BPérezJuan

Cod_departamentoDNIApellidosNombre

EMPLEADOS

σapellidos=“Pérez”(EMPLEADOS)

Page 13: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

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

PérezJulián

SánchezJosé

JiménezPedro

PérezJuan

ApellidosNombre

145215632LPérezJulián

287456321SSánchezJosé

154789321CJiménezPedro

128689555BPérezJuan

Cod_departamentoDNIApellidosNombre

EMPLEADOS

π nombre,apellidos(EMPLEADOS)

Page 14: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

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

Page 15: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. AR. DIFERENCIA (-MODELO RELACIONAL. AR. DIFERENCIA (-) Álgebra Relacional. 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.

Page 16: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL.AR.PRODUCTO CARTESIANO(XMODELO RELACIONAL.AR.PRODUCTO CARTESIANO(X)

Álgebra Relacional. 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.

Page 17: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

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

2Historia

1Ciencias

CodNombre

145215632LPérezJulián

287456321SSánchezJosé

154789321CJiménezPedro

128689555BPérezJuan

CodDNIApellidosNombre

EMP

EMP θ DPTO = ΠEMP.nombre,apellidos,dni,DPTO.cod,DPTO.nombre(σEMP.cod=DPTO.cod (EMP X DPTO))

DPTO

1

2

1

1

Cod

Ciencias45215632LPérezJulián

Historia87456321SSánchezJosé

Ciencias54789321CJiménezPedro

Ciencias28689555BPérezJuan

Nombre dptoDNIApellidosNombre

Page 18: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

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

Page 19: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

MODELO RELACIONAL. AR. INTERSECCIÓN (MODELO RELACIONAL. AR. INTERSECCIÓN (∩) Álgebra Relacional. 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.

Page 20: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

PASOS EN EL DISEÑO DE DATOSPASOS EN EL DISEÑO DE DATOS

E-R

ERS

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

Page 21: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

PASOS EN EL DISEÑO DE DATOSPASOS EN EL DISEÑO DE DATOS

E-R

ERS

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

1. Transformación del esquema conceptual al esquema lógico

1. Normalización del esquema lógicoTEMA 9

TEMA 11

Page 22: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación del esquema conceptualTransformación del esquema conceptualEl paso de un esquema en el modelo E/R al relacional está basado en los El paso de un esquema en el modelo E/R al relacional está basado en los tres principios siguientes:tres principios siguientes:– Todo tipo de entidad se convierte en una relación.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 N:M se transforma en una relación.– Todo tipo de interrelación 1:N se traduce en el fenómeno de 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.propagación de clave o se crea una nueva relación.

Modelo E/REntidades, atributos,

relaciones

Modelo lógicoTablas

Page 23: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones N:M : Se transforma en una relación (tabla) que tendrá Interrelaciones N:M : Se transforma en una relación (tabla) que tendrá

como clave primaria la concatenación de las claves primarias de las como clave primaria la concatenación de las claves primarias de las entidades involucradas. El resto de atributos serán los que pueda entidades involucradas. El resto de atributos serán los que pueda tener la interrelación.tener la interrelación.

Además, cada uno de los atributos que forman la clave primaria de 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 esta relación son clave ajena respecto a cada una de las tablas donde este atributo es clave primaria.este atributo es clave primaria.

A B

a1

a2

a3

b1

b2

b3

r1 r2

(1,M) (1,N)(M,N)

A1 A2 A3 B1 B2 B3

A1 B1 R1 R2

Page 24: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones N:M : Un ejemplo.Interrelaciones N:M : Un ejemplo.

Page 25: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones 1:N : Se propaga la clave primaria del tipo de entidad 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 que tiene la cardinalidad máxima 1 a la que tiene N, es decir, en el sentido de la flecha.sentido de la flecha.Además, los atributos que forman la clave primaria que se propagan Además, los atributos que forman la clave primaria que se propagan son clave ajena respecto a la tabla donde este atributo es clave son clave ajena respecto a la tabla donde este atributo es clave primaria.primaria.Además, si la relación tiene atributos, se propagan en el mismo Además, si la relación tiene atributos, se propagan en el mismo sentido.sentido.

A B

a1

a2

a3

b1

b2

b3

r1 r2

(1,1) (1,N)(1,N)

A1 A2 A3 B1 B2 B3 A1 R1 R2

Page 26: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones 1:N : EjemploInterrelaciones 1:N : Ejemplo

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.

Page 27: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones 1:N : Las interrelaciones 1:N también pueden Interrelaciones 1:N : Las interrelaciones 1:N también pueden

transformarse como si se tratará de una interrelación N:M. Esta opción transformarse como si se tratará de una interrelación N:M. Esta opción suele ser mejor cuando la interrelación tiene atributos.suele ser mejor cuando la interrelación tiene atributos.

En este caso mejor

Page 28: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones 1:1: no hay regla fija para la transformación de este 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 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 propagar la clave. En este segundo caso la propagación de la clave puede efectuarse en ambas direcciones.puede efectuarse en ambas direcciones.

Los criterios para aplicar una transformación u otra y para propagar la Los criterios para aplicar una transformación u otra y para propagar la clave se basan en las cardinalidades mínimas:clave se basan en las cardinalidades mínimas: Si las entidades que se asocian poseen cardinalidades (0,1), entonces la Si las entidades que se asocian poseen cardinalidades (0,1), entonces la

interrelación 1:1 se transformará en una relación.interrelación 1:1 se transformará en una relación.

A B

a1

a2

a3

b1

b2

b3

r1 r2

(0,1) (0,1)(1,1)

A1 A2 A3 B1 B2 B3

A1 B1 R1 R2

Page 29: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones 1:1: Ejemplo transformación en una relación.Interrelaciones 1:1: Ejemplo transformación en una relación.

Cod_mujer debe ser clave alternativa

Page 30: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones 1:1:Interrelaciones 1:1:

Si una de las entidades que participa en la interrelación posee 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 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 propagar la clave de la entidad con cardinalidad (1,1) a la tabla resultante de la entidad con cardinalidad (0,1).de la entidad con cardinalidad (0,1).

A B

a1

a2

a3

b1

b2

b3

r1 r2

(1,1) (0,1)(1,1)

A1 A2 A3 B1 B2 B3 A1 R1 R2

Page 31: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones 1:1: Ejemplo propagación.Interrelaciones 1:1: Ejemplo propagación.

Page 32: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones 1:1:Interrelaciones 1:1:

En el caso de que ambas entidades presenten cardinalidades (1,1), se 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 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 otra, teniendo en cuenta en este caso los accesos más frecuentes y prioritarios a los datos.prioritarios a los datos.

Page 33: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones n-arias : Si las cardinalidades máximas de todas las Interrelaciones n-arias : Si las cardinalidades máximas de todas las

entidades es N, entonces se crea una tabla por cada entidad y se 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 creará otra donde la clave será la agregación de las claves de todas las tablas.las tablas.

En el ejemplo de abajo la interrelación es N:N:NEn el ejemplo de abajo la interrelación es N:N:N

A B

a1

a2

a3

b1

b2

b3

r1 r2

A1 A2 A3

B1 B2 B3

C

C1 C2 C3

A1 B1 C1 R1 R2

Page 34: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones n-arias : Si las cardinalidades máximas de todas las Interrelaciones n-arias : Si las cardinalidades máximas de todas las

entidades es N, entonces se crea una tabla por cada entidad y se 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 creará otra donde la clave será la agregación de las claves de todas las tablas.las tablas.

En el ejemplo de abajo la interrelación es N:N:NEn el ejemplo de abajo la interrelación es N:N:N

A B

a1

a2

a3

b1

b2

b3

r1 r2

A1 A2 A3

B1 B2 B3

C

C1 C2 C3

A1 B1 C1 R1 R2

Page 35: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones n-arias : Si las cardinalidades máximas de alguna Interrelaciones n-arias : Si las cardinalidades máximas de alguna

entidad es 1, entonces se crea una tabla por cada entidad y se creará 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 otra donde la clave será la agregación de las claves de las entidades donde la cardinalidad máxima es N.donde la cardinalidad máxima es N.

1:N:M

suministrar

PROVEEDOR PROYECTO

(0,1)

(0,N)

PIEZA

(0,M)

suministra

Es suministrado por Suministra para

Proveedor (cod_proveedor, …)Proyecto (cod_proyecto, …)Pieza (cod_pieza, …)Suministrar (cod_pieza, cod_proyecto, cod_proveedor, …)

Clave ajena

Page 36: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones n-arias : Si todas las cardinalidades máximas de las Interrelaciones n-arias : Si todas las cardinalidades máximas de las

entidades es 1, excepto 1, entonces se crea una tabla por cada 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á entidad y la tabla que corresponde a la cardinalidad máxima N tendrá claves ajenas a las demás.claves ajenas a las demás.

1:1:M

suministrar

PROVEEDOR PROYECTO

(0,1)

(0,N)

PIEZA

(0,1)

suministra

Es suministrado por Suministra para

Proveedor (cod_proveedor, …)Proyecto (cod_proyecto, …)Pieza (cod_pieza, cod_proveedor, cod_proyecto …)

Claves ajenas

Page 37: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Dependencias en existencia e identificación: La manera de transformar Dependencias en existencia e identificación: La manera de transformar

una interrelación de este tipo es utilizar el mecanismo de propagación 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 de clave, creando una clave ajena, con nulos no permitidos, en la entidad dependiente. También deberemos obligar a una modificación y entidad dependiente. También deberemos obligar a una modificación y y un borrado en cascada.y un borrado en cascada.Además, en el caso de dependencia en identificación la clave primaria 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 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 concatenación de las claves de las dos entidades participantes en la interrelación.interrelación.

Page 38: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Interrelaciones exclusivas: La manera de transformar una interrelación Interrelaciones exclusivas: La manera de transformar una interrelación

de este tipo es utilizar el mecanismo de propagación de clave, creando de este tipo es utilizar el mecanismo de propagación de clave, creando dos claves ajenas. Para obligar a dicha exclusividad necesitamos una dos claves ajenas. Para obligar a dicha exclusividad necesitamos una restricción. (La forma de poner las restricciones en SQL lo veremos en restricción. (La forma de poner las restricciones en SQL lo veremos en el tema 11).el tema 11).BECA (BECA (cod_becacod_beca, ….), ….)PROYECTO (PROYECTO (cod_proyectocod_proyecto, …), …)PROFESOR (PROFESOR (nifnif, cod_beca, cod_proyecto, …), cod_beca, cod_proyecto, …)Restricción: Una de las dos claves ajenas es nula y la otra no.Restricción: Una de las dos claves ajenas es nula y la otra no.

percibe

PROFESOR

BECA(0,N)

(0,1)

contratado(1,N)

(0,N)PROYECTO

N:1

N:M

Page 39: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Tipos y subtipos: Los tipos y subtipos no son objetos que se puedan Tipos y subtipos: Los tipos y subtipos no son objetos que se puedan

representar explícitamente en el modelo relacional. Ante una entidad y representar explícitamente en el modelo relacional. Ante una entidad y sus subtipos caben varias soluciones de transformación en el modelo sus subtipos caben varias soluciones de transformación en el modelo relacional, con la consiguiente pérdida de semántica dependiendo de relacional, con la consiguiente pérdida de semántica dependiendo de la estrategia elegida. Destacamos tres principalmente:la estrategia elegida. Destacamos tres principalmente:

Page 40: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Tipos y subtipos: Tipos y subtipos:

Opción aOpción a: englobar todos los atributos de la entidad y sus subtipos en : 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 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 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.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 general, adoptaremos esta solución cuando los subtipos se diferencian en muy pocos atributos y las interrelaciones que se asocian con el resto de en muy pocos atributos y las interrelaciones que se asocian con el resto de entidades sean las mismas para todos los subtipos.entidades sean las mismas para todos los subtipos.

No utilizar nunca en PARCIAL CON SOLAPAMIENTONo utilizar nunca en PARCIAL CON SOLAPAMIENTO

Si total CON SOLAPAMIENTO, entonces el Si total CON SOLAPAMIENTO, entonces el discriminante formará parte de la clave.discriminante formará parte de la clave.

Es posible que haya que incluir restricciones Es posible que haya que incluir restricciones semánticas. Por ejemplo: Si el tipo de documento es semánticas. Por ejemplo: Si el tipo de documento es ARTICULO, entonces el año de edición y el código de ARTICULO, entonces el año de edición y el código de editorial deben ser nulos.editorial deben ser nulos.

Page 41: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Tipos y subtipos: Tipos y subtipos:

Opción bOpción b: crear una relación para el supertipo y tantas relaciones como : crear una relación para el supertipo y tantas relaciones como subtipos haya, con sus atributos correspondientes.subtipos haya, con sus atributos correspondientes.En general, adoptaremos esta solución cuando existen muchos atributos En general, adoptaremos esta solución cuando existen muchos atributos distintos entre los subtipos y se quieren mantener de todas maneras los distintos entre los subtipos y se quieren mantener de todas maneras los atributos comunes a todos ellos en una relación.atributos comunes a todos ellos en una relación.

Es posible que haya que incluir restricciones Es posible que haya que incluir restricciones semánticas.semánticas.

Page 42: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Tipos y subtipos: Tipos y subtipos:

Opción cOpción c: Considerar relaciones distintas para cada subtipo, que : Considerar relaciones distintas para cada subtipo, que contengan además los atributos comunes.contengan además los atributos comunes. En general, adoptaremos esta solución cuando existen muchos atributos En general, adoptaremos esta solución cuando existen muchos atributos distintos entre los subtipos, pocos atributos comunes en el supertipo y distintos entre los subtipos, pocos atributos comunes en el supertipo y existan pocas relaciones en las que participe el supertipo.existan pocas relaciones en las que participe el supertipo.

Esta opción sólo nos la podemos plantear si la Esta opción sólo nos la podemos plantear si la generalización es total y sin solapamiento.generalización es total y sin solapamiento.

Es posible que haya que incluir restricciones Es posible que haya que incluir restricciones semánticas. Por ejemplo: Si el tipo de documento es semánticas. Por ejemplo: Si el tipo de documento es ARTICULO, entonces el año de edición y el código de ARTICULO, entonces el año de edición y el código de editorial deben ser nulos.editorial deben ser nulos.

Page 43: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

Transformación de interrelacionesTransformación de interrelaciones– Tipos y subtipos: Podemos, por tanto, elegir entre tres estrategias distintas Tipos y subtipos: Podemos, por tanto, elegir entre tres estrategias distintas

para la transformación de un tipo y sus subtipos al para la transformación de un tipo y sus subtipos al modelo relacionalmodelo relacional. Sin . Sin embargo, desde un punto de vista exclusivamente semántico la opción b es la 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 mejor. Por otra parte, desde el punto de vista de la eficiencia tenemos que tener en cuenta que:tener en cuenta que: Opción aOpción a: El acceso a una fila que refleje toda la información de una determinada : 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).entidad es mucho más rápido (no hace falta combinar varias relaciones). Opción bOpción b: La menos eficiente, aunque es la mejor desde el punto de vista : La menos eficiente, aunque es la mejor desde el punto de vista

exclusivamente semántico.exclusivamente semántico. Opción cOpción c: Con esta solución aumentamos la eficiencia ante determinadas consultas : Con esta solución aumentamos la eficiencia ante determinadas consultas

(por ejemplo, las que afecten a todos los atributos de un subtipo) pero la (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 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 distintos subtipos) e introducimos redundancias. Esta solución es en la que se pierde más semántica.más semántica.

Elegiremos una estrategia u otra dependiendo de que sea la semántica o la 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.eficiencia la que imprime para el usuario en un momento determinado.

Page 44: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

TRANSFORMACIÓN DEL ESQUEMA CONCEPTUALTRANSFORMACIÓN DEL ESQUEMA CONCEPTUAL

NOTACIÓN DEL DISEÑO LÓGICO DE DATOSNOTACIÓN DEL DISEÑO LÓGICO DE DATOSPara cada relación obtenida creamos lo siguiente:Para cada relación obtenida creamos lo siguiente:

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*

Page 45: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

IntroducciónIntroducciónCuando se diseña una B.D. mediante el modelo relacional, tenemos Cuando se diseña una B.D. mediante el modelo relacional, tenemos distintas alternativas, es decir, podemos obtener diferentes esquemas distintas alternativas, es decir, podemos obtener diferentes esquemas relacionales, y no todos ellos son equivalentes, ya que unos van a relacionales, y no todos ellos son equivalentes, ya que unos van a representar la realidad mejor que otros.representar la realidad mejor que otros.Las relaciones que resultan de la transformación del esquema E/R Las relaciones que resultan de la transformación del esquema E/R pueden presentar algunos problemas, derivados de fallos en la pueden presentar algunos problemas, derivados de fallos en la percepción del universo de discurso, en el diseño del esquema E/R o percepción del universo de discurso, en el diseño del esquema E/R o en el paso al modelo relacional.en el paso al modelo relacional.En definitiva, el esquema relacional debe ser analiazado para En definitiva, el esquema relacional debe ser analiazado para comprobar que no presenta los problemas anteriormente citados, comprobar que no presenta los problemas anteriormente citados, evitando la pérdida de información y la aparición de estados que no evitando la pérdida de información y la aparición de estados que no son válidos en el mundo real.son válidos en el mundo real.Ante las posibles dudas respecto a si un determinado esquema Ante las posibles dudas respecto a si un determinado esquema relacional es correcto, es mejor aplicar a dicho esquema un método 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 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 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.ciertos requisitos; este método formal es la teoría de la normalización.

Page 46: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

IntroducciónIntroducciónSe ha de comentar que la anomalias a las que da lugar un 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 diseño inadecuado de una B.D se producen sólo en procesos de actualización y nunca en los de consulta. La procesos de actualización y nunca en los de consulta. La aplicación de la teoría de la normalización consigue una aplicación de la teoría de la normalización consigue una disminución de dichas anomalías, evitando muchdisminución de dichas anomalías, evitando muchos de los os de los problemas que se pueden plantear en las problemas que se pueden plantear en las actualizaciones.actualizaciones.

Page 47: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Noción intuitiva de las formas normalesNoción intuitiva de las formas normalesLa teoría de la normalización consiste en obtener La teoría de la normalización consiste en obtener esquemas relacionales que cumplan unas determinadas esquemas relacionales que cumplan unas determinadas condiciones, y se centra en lo que se conoce como formas condiciones, y se centra en lo que se conoce como formas normales. Se dice que un esquema lógico de datos está en normales. Se dice que un esquema lógico de datos está en una determinada forma normal si satisface determinado una determinada forma normal si satisface determinado conjunto específico de restricciones.conjunto específico de restricciones.

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.

Page 48: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Noción intuitiva de las formas normalesNoción intuitiva de las formas normales– 1FN: Un atributo no puede tomar más de un valor.1FN: Un atributo no puede tomar más de un valor.

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)

Page 49: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Noción intuitiva de las formas normalesNoción intuitiva de las formas normales– 3FN: Además de estar en la 1FN y en la 2FN, los campos que no forman parte 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) de la clave candidata deben facilitar información sólo acerca de la(s) clave(s) candidatas, y no acerca de otros campos. Ejemplo:candidatas, y no acerca de otros campos. Ejemplo:EMPLEADOS( cod_empleado, cod_departamento, nombre_departamento)EMPLEADOS( cod_empleado, cod_departamento, nombre_departamento)

PK(cod_empleado)PK(cod_empleado)Esta relación no está en 3FN ya que el nombre del departamento es un hecho 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 acerca del código del departamento además de serlo, transitivamente, del código de empleado.código de empleado.Para conseguir la 3FN sería conveniente descomponerlo de la siguiente Para conseguir la 3FN sería conveniente descomponerlo de la siguiente manera:manera:EMPLEADOS( cod_empleado, nombre_departamento)EMPLEADOS( cod_empleado, nombre_departamento)DEPARTAMENTO( cod_departamento, nombre_departamento)DEPARTAMENTO( cod_departamento, nombre_departamento)

Page 50: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Noción intuitiva de las formas normalesNoción intuitiva de las formas normales– Forma normal de Boyce-Codd (FNBC): Una relación está en FNBC si, y solo si, 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 las claves candidatas son los únicos descriptores sobre los que se facilita información por cualquier otro atributo. Ejemplo:información por cualquier otro atributo. Ejemplo:PRESTAMOS (num_socio, nombre_socio, cod_libro, fecha_prestamo)PRESTAMOS (num_socio, nombre_socio, cod_libro, fecha_prestamo)

PK(num_socio, cod_libro)PK(num_socio, cod_libro)AK(nombre_socio, cod_libro)AK(nombre_socio, cod_libro)

Aunque está en 3FN no está en FNBC porque el número de socio es una 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 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 estos dos atributos son clave (aunque formen parte de la clave). Para solucionarlo:solucionarlo:PRESTAMOS (num_socio, cod_libro, fecha_prestamo)PRESTAMOS (num_socio, cod_libro, fecha_prestamo)SOCIOS (num_socio, nombre_socio)SOCIOS (num_socio, nombre_socio)

Page 51: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Dependencias funcionales.Teoría de la normalizaciónDependencias funcionales.Teoría de la normalizaciónYa hemos visto la noción intuitiva de las formas normales pero no Ya hemos visto la noción intuitiva de las formas normales pero no podemos normalizar un esquema lógico de datos de manera intuitiva.podemos normalizar un esquema lógico de datos de manera intuitiva.La normalización a nivel teórico se basa en el concepto de La normalización a nivel teórico se basa en el concepto de dependencia funcional. Existen muchos tipos de dependencias dependencia funcional. Existen muchos tipos de dependencias (funcionales, multivaluadas, de combinación, etc.), pero nosotros sólo (funcionales, multivaluadas, de combinación, etc.), pero nosotros sólo trataremos las dependencias funcionales, ya que son las que se trataremos las dependencias funcionales, ya que son las que se encuentran asociadas a las tres primeras formas normales.encuentran asociadas a las tres primeras formas normales.

Page 52: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Dependencias funcionales.Teoría de la normalizaciónDependencias funcionales.Teoría de la normalización– Definición de dependencia funcional:Definición de dependencia funcional:

Decimos que un descriptor Y (conjunto de campos) depende Decimos que un descriptor Y (conjunto de campos) depende funcionalmente del descriptor X funcionalmente del descriptor X o que X determina o implica a Yo que X determina o implica a Y, si, y , si, y solo si, cada valor de X tiene asociado en todo momento un único solo si, cada valor de X tiene asociado en todo momento un único valor de Y. Lo que se representa como: valor de Y. Lo que se representa como: X X Y Y..

Así, por ejemplo, podemos decir que:Así, por ejemplo, podemos decir que:COD_ALMACEN COD_ALMACEN DIRECCION_ALMACEN DIRECCION_ALMACENYa que cada código de almacén existe una sola dirección o que el 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 código del almacén determina su dirección. En esta dependencia al COD_ALMAC…N (X) lo denominaremos COD_ALMAC…N (X) lo denominaremos ImplicanteImplicante y a y a DIRECCIÓN_ALMAC…N (Y) DIRECCIÓN_ALMAC…N (Y) ImplicadoImplicado..

Page 53: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Dependencias funcionales.Teoría de la normalizaciónDependencias funcionales.Teoría de la normalización– Dependencia funcional completa y 2FN:Dependencia funcional completa y 2FN:

Si el descriptor X es compuesto: (X1, X2), se dice que Y tiene Si el descriptor X es compuesto: (X1, X2), se dice que Y tiene dependencia funcional completa o plena respecto de X, si depende dependencia funcional completa o plena respecto de X, si depende funcionalmente de X, pero no depende de ningún subconjunto del funcionalmente de X, pero no depende de ningún subconjunto del mismo, esto es: mismo, esto es: X X Y Y, pero , pero X1 -/->YX1 -/->Y y y X2 -/->YX2 -/->Y..

Así, por ejemplo, si suponemos que en una empresa un empleado Así, por ejemplo, si suponemos que en una empresa un empleado puede trabajar en varios proyectos, realizando una sola función en puede trabajar en varios proyectos, realizando una sola función en cada uno de ellos (consultor, analista, programador, etc.), aunque cada uno de ellos (consultor, analista, programador, etc.), aunque pueda ser distinta según el proyecto, tendríamos que:pueda ser distinta según el proyecto, tendríamos que:

(DNI_EMPLEADO, COD_PROYECTO) (DNI_EMPLEADO, COD_PROYECTO) FUNCIÓN FUNCIÓNes una dependencia completa, ya que ninguno de los elementos del es una dependencia completa, ya que ninguno de los elementos del descriptor por separado determina el implicado, al poder tener un descriptor por separado determina el implicado, al poder tener un empleado muchas funciones, lo mismo que un proyecto.empleado muchas funciones, lo mismo que un proyecto.

Page 54: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Dependencias funcionales.Teoría de la normalizaciónDependencias funcionales.Teoría de la normalización– Dependencia funcional completa y 2FN:Dependencia funcional completa y 2FN:

Sin embargo, la dependencia:Sin embargo, la dependencia:(COD_PIEZA, COD_ALMAC…N) (COD_PIEZA, COD_ALMAC…N) DIRECCIÓN_ALMAC…N DIRECCIÓN_ALMAC…Nno es completa, ya que: no es completa, ya que: COD_ALMAC…N COD_ALMAC…N DIRECCIÓN_ALMAC…N DIRECCIÓN_ALMAC…N

Podemos ahora definir la 2FN de manera más rigurosa diciendo que un Podemos ahora definir la 2FN de manera más rigurosa diciendo que un registro está en 2FN si:registro está en 2FN si: Está en 1FN.Está en 1FN. Todo campo no clave tiene una dependencia funcional completa respecto Todo campo no clave tiene una dependencia funcional completa respecto

de las claves candidatas.de las claves candidatas.

Page 55: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Dependencias funcionales.Teoría de la normalizaciónDependencias funcionales.Teoría de la normalización– Dependencia funcional completa y 2FN:Dependencia funcional completa y 2FN:

Veamos un ejemplo: la relaciónVeamos un ejemplo: la relaciónVENTAS (cod_pieza, cod_almacén, cantidad, dirección_almacé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 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 código del almacén y la dirección del almacén no presenta dependencia funcional completa ya que:dependencia funcional completa ya que:COD_ALMAC…N COD_ALMAC…N DIRECCIÓN_ALMAC…N DIRECCIÓN_ALMAC…NSin embargo, las relaciones Sin embargo, las relaciones N_VENTAS( cod_pieza, cod_almacén, N_VENTAS( cod_pieza, cod_almacén, cantidad)cantidad) y y ALMACENES( cod_almacén, dirección_almacén)ALMACENES( cod_almacén, dirección_almacén) sí están en sí están en 2FN, ya que: 2FN, ya que: COD_PIEZA,COD_PIEZA, COD_ALMAC…N COD_ALMAC…N CANTIDAD CANTIDAD es una es una dependencia completa y dependencia completa y COD_ALMAC…N COD_ALMAC…N DIRECCIÓN_ALMAC…N DIRECCIÓN_ALMAC…N también lo es, ya que en el caso de que la clave sea simple (esté 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á formada por un solo campo) siempre que se encuentre en 1FN estará también en 2FN.también en 2FN.

Page 56: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Dependencia funcional transitiva y 3FNDependencia funcional transitiva y 3FNSi existen las siguientes dependencias funcionales que se muestran en Si existen las siguientes dependencias funcionales que se muestran en el diagrama.el diagrama.

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_DEPARTAMENTOCOD_DEPARTAMENTO NOMBRE_DEPARTAMENTOCOD_DEPARTAMENTO -/-> COD_EMPLEADOPodemos afirmar que COD_EMPLEADO NOMBRE_DEPARTAMENTO transitivamente a través de COD_DEPARTAMENTO.

Page 57: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Dependencia funcional transitiva y 3FNDependencia funcional transitiva y 3FNSSe dice que un registro se encuentra en 3FN si:e dice que un registro se encuentra en 3FN si: Está en 2FN.Está en 2FN. Ningún campo no clave depende transitivamente de ninguna clave.Ningún campo no clave depende transitivamente de ninguna clave.

Ejemplo: La relación Ejemplo: La relación EMPLEADOS (cod_empleado, cod_depto, nombre_depto) no se EMPLEADOS (cod_empleado, cod_depto, nombre_depto) no se encuentra en 3FN ya que la clave es el COD_EMPLEADO y:encuentra en 3FN ya que la clave es el COD_EMPLEADO y:COD_EMPLEADO COD_EMPLEADO COD_DEPARTAMENTO COD_DEPARTAMENTOCOD_DEPARTAMENTO COD_DEPARTAMENTO NOMBRE_DEPARTAMENTO NOMBRE_DEPARTAMENTO

Por tanto, Por tanto, COD_EMPLEADO COD_EMPLEADO NOMBRE_DEPARTAMENTO NOMBRE_DEPARTAMENTO y esto significa y esto significa que un campo no clave (nombre del departamento) depende que un campo no clave (nombre del departamento) depende transitivamente de la clave (código de empleado).transitivamente de la clave (código de empleado).

Page 58: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Forma normal de Boyce-Codd (FNBC)Forma normal de Boyce-Codd (FNBC)Se dice que un registro se encuentra en FNBC si, y solo si, todo Se dice que un registro se encuentra en FNBC si, y solo si, todo determinante es clave, donde por determinante entendemos cualquier determinante es clave, donde por determinante entendemos cualquier conjunto de campos del que otro campo depende funcionalmente de conjunto de campos del que otro campo depende funcionalmente de forma completa.forma completa. Ejemplo: dada la relaciónEjemplo: dada la relaciónVENTAS( cod_pieza, cod_almacén, nombre_almacén, cantidad)VENTAS( cod_pieza, cod_almacén, nombre_almacén, cantidad) donde donde suponemos que los almacenes se identifican tanto por su código como 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 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)candidatas: (cod_pieza, cod_almacén) y (cod_pieza, nombre_almacén)Veamos cuales son los determinantes:Veamos cuales son los determinantes:(cod_pieza, cod_almacén) y (cod_pieza, nombre_almacén) son (cod_pieza, cod_almacén) y (cod_pieza, nombre_almacén) son determinantes al ser claves por cod_almacén y nombre_almacén determinantes al ser claves por cod_almacén y nombre_almacén también son determinantes por sí solo ya que:también son determinantes por sí solo ya que:cod_almacén cod_almacén nombre almacén nombre almacén y al contrario. Por tanto esta relación y al contrario. Por tanto esta relación no está en FNBC, ya que no todo determinante es clave. Estos campos no está en FNBC, ya que no todo determinante es clave. Estos campos forman parte de la clave pero no son la clave.forman parte de la clave pero no son la clave.

Page 59: PresentacióN Tema 8

Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)Anális y diseño de aplicaciones informáticas de gestión (TEMA 9)

NORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOSNORMALIZACIÓN DEL ESQUEMA LÓGICO DE DATOS

Forma normal de Boyce-Codd (FNBC)Forma normal de Boyce-Codd (FNBC)Si queremos cumplir la FNBC deberemos descomponer la relación, por Si queremos cumplir la FNBC deberemos descomponer la relación, por ejemplo, de la siguiente manera:ejemplo, de la siguiente manera:ALMACENES( cod_almacén, nombre_almacén)ALMACENES( cod_almacén, nombre_almacén)N_VENTAS( cod_pieza, cod_almacén, cantidad)N_VENTAS( cod_pieza, cod_almacén, cantidad) donde en la primera donde en la primera relación existen dos claves: cod_almacén y nombre_almacén y ambos relación existen dos claves: cod_almacén y nombre_almacén y ambos campos son también determinante ya que: campos son también determinante ya que: cod_almacén cod_almacén nombre_almacén nombre_almacén nombre_almacén nombre_almacén cod_almacén cod_almacén por tanto está en FNBC. Mientras por tanto está en FNBC. Mientras que en la segunda relación existe una clave compuesta (cod_pieza, que en la segunda relación existe una clave compuesta (cod_pieza, cod_almacén) y un único determinante formado por esos dos campos cod_almacén) y un único determinante formado por esos dos campos ya que:ya que:cod_pieza, cod_almacén cod_pieza, cod_almacén cantidad cantidad por lo que se encuentra en FNBC. por lo que se encuentra en FNBC.