Descargado 29 veces
Subido porRobert Rodriguez
Diseño Logico de Base de datos Relacionales
Este documento describe la metodología para el diseño lógico de bases de datos relacionales. Explica cómo convertir un esquema conceptual en un esquema lógico mediante la transformación de entidades en tablas y relaciones en claves ajenas y tablas. También cubre la normalización, definición de restricciones y validación del diseño lógico con los usuarios.
Más contenido relacionado
Similar a Diseño Logico de Base de datos Relacionales
Diseño Logico de Base de datos Relacionales
- 1. TEMA 7. DISEÑOLÓGICO DE BASES DE DATOS RELACIONALES 1. Introducción 2. Metodología de diseño lógico en el modelo relacional 3. Normalización 4. Desnormalización, partición de relaciones y optimización
- 2. Tema 7. Diseñológico de bases de datos relacionales 2 1. Introducción Diseño lógico: conversión del esquema conceptual de datos en un esquema lógico. Objetivo: obtener una representación que use de la manera más eficiente posible los recursos para la estructuración de datos y el modelado de restricciones disponibles en el modelo lógico. Información de la carga Volumen de la base de datos. Conocimiento de consultas y transacciones a realizar, y su frecuencia. Criterios de rendimiento Tiempo de respuesta medio o máximo. Espacio de almacenamiento ocupado por la base de datos. Utilización de CPU o tiempo de E/S. DISEÑO LÓGICO esquema conceptual información de la carga criterios de rendimiento esquema lógico
- 3. Tema 7. Diseñológico de bases de datos relacionales 3 2. Metodología de diseño lógico en el modelo relacional Construir y validar los esquemas lógicos locales para cada vista de usuario 1. Convertir los esquemas conceptuales locales en esquemas lógicos locales. 2. Derivar un conjunto de relaciones (tablas) para cada esquema lógico local. 3. Validar cada esquema mediante la normalización. 4. Validar cada esquema frente a las transacciones del usuario. 5. Dibujar el diagrama entidad – relación. 6. Definir las restricciones de integridad. 7. Revisar cada esquema lógico local con el usuario correspondiente. Construir y validar el esquema lógico global 8. Mezclar los esquemas lógicos locales en un esquema lógico global. 9. Validar el esquema lógico global. 10. Estudiar el crecimiento futuro. 11. Dibujar el diagrama entidad/relación final. 12. Revisar el esquema lógico global con los usuarios.
- 4. Tema 7. Diseñológico de bases de datos relacionales 4 1. Convertir los esquemas conceptuales locales en esquemas lógicos locales (a) Sustituir cada relación entre tres o más entidades por una entidad intermedia. La cardinalidad de las nuevas relaciones binarias dependerá de su significado. Si la relación sustituida tiene atributos, éstos serán los atributos de la nueva entidad. PILOTO codpil (0,n) (0,n) AVIÓN codavinombre matrícula TRIPULACIÓN codtrip nombre (0,n) viaje fecha PILOTO codpil (0,n) (0,n) AVIÓN codavinombre matrícula TRIPULACIÓN codtrip (0,n) viaje fecha nombre (1,1) (1,1) (1,n)
- 5. Tema 7. Diseñológico de bases de datos relacionales 5 (b) Eliminar las relaciones redundantes. ANIMAL ZOO ESPECIE posee pertenece (1,1) (1,1) (1,n) (1,n) alberga (1,n) (1,n) EMPLEADO CIUDAD residencia nacimiento (1,n) (0,1) (0,n) (0,n)
- 6. Tema 7. Diseñológico de bases de datos relacionales 6 2. Derivar un conjunto de relaciones para cada esquema lógico local (a) Cada entidad del esquema conceptual se transforma en una relación base (tabla). Los atributos de la entidad se convierten en los atributos de la tabla. Cada componente de un atributo compuesto se convierte en un atributo de la tabla. Por cada atributo con cardinalidad máxima mayor que uno se incluye una tabla dentro de la tabla, como un atributo más. De entre los identificadores de la entidad se debe escoger uno como clave primaria de la tabla. LIBRO isbn editorial autor (1,n) edición número año (1,n) idioma título_ppal subtítulo título LIBRO(isbn, editorial, AUTOR(autor), idioma, título_ppal, subtítulo, EDICIÓN(número, año))
- 7. Tema 7. Diseñológico de bases de datos relacionales 7 (b) Hay tres opciones para representar las jerarquías de generalización. E E1 E2 E3 a1 a2 a3 a4 a5 E E1 E2 E3 a1 a2 (0,1) (0,1)(0,1) (1,1) (1,1) (1,1) E1 E2 E3 a3 a4 a5a1 a2 a1 a2 a1 a2 E a1 a2 a3 a4 a5 (0,1) (0,1) (0,1) AD (0/1,1/n) opción (1) opción (2) opción (3) ( p/t, e/s ) a3 a4 a5
- 8. Tema 7. Diseñológico de bases de datos relacionales 8 (1) Una tabla por cada entidad. Sirve para cualquier tipo de jerarquía (t/p, e/s). E(a1, a2) , E1(a1, a3) , E2(a1, a4) , E3(a1, a5) E1.a1, E2.a1, E3.a1 son claves ajenas a E (2) Una tabla por cada subentidad. Sólo sirve para jerarquías totales y exclusivas. E1(a1, a2, a3) , E2(a1, a2, a4) , E3(a1, a2, a5) (3) Integrar todas las entidades en una tabla. Sirve para cualquier tipo de jerarquía (t/p, e/s). E(a1, a2, a3, a4, a5, tipo) si es exclusiva; a3, a4, a5 aceptan nulos; tipo acepta nulos si es parcial. E(a1, a2, a3, a4, a5, AD(tipo) ) si es superpuesta; a3, a4, a5 aceptan nulos; Nulos Borrado
- 9. Tema 7. Diseñológico de bases de datos relacionales 9 (c) Por cada relación binaria (1:1), incluir la clave primaria de la tabla correspondiente a la entidad padre en la tabla de la entidad hijo como una clave ajena. ¿Y los atributos de la relación? EMPLEADO codemp (0,1) (1,1) VEHíCULO matrículanombre modelo EMPLEADO codemp (1,1) (0,1) VEHíCULO matrículanombre modelo hijo hijo conduce conduce fecha_ini fecha_ini
- 10. Tema 7. Diseñológico de bases de datos relacionales 10 EMPLEADO(codemp, nombre ) VEHíCULO(matrícula, modelo, codemp, fecha_ini) VEHíCULO EMPLEADO ¿son tan diferentes? VEHíCULO(matrícula, modelo) EMPLEADO(codemp, nombre, matrícula, fecha_ini) EMPLEADO VEHíCULO ¿Y si las dos entidades participan con cardinalidad (0,1)? ¿Y si son ambas (1,1)? EMPLEADO codemp (0,1) (1,1) VEHíCULO matrículanombre modelo codemp matrícula EMPLEADO codemp (1,1) (0,1) VEHíCULO matrículanombre modelo hijo hijo conduce conduce Nulos Borrado Nulos Borrado fecha_ini fecha_ini ¿nulos? ¿nulos?
- 11. Tema 7. Diseñológico de bases de datos relacionales 11 Ojo: Si las entidades relacionadas son sinónimos, integrarlas en una sola tabla. CLIENTE(codcli, dirección, nombre, dirección_envío) ENVÍO es una entidad débil porque no tiene atributos que le sirvan como identificador. Ejercicio CLIENTE dirección (0,1) (1,1) ENVÍO nombre dirección ¡¡son sinónimos!! codcli ¿nulos? PERSONA codper (0,1) (1,1) nombre es_acompañada_por acompaña_a
- 12. Tema 7. Diseñológico de bases de datos relacionales 12 (d) Por cada relación binaria (1:n), incluir la clave primaria de la tabla correspondiente a la entidad padre en la tabla de la entidad hijo (será una clave ajena). ¿Y los atributos de la relación? PROFESOR HABITACIÓN codpro numhab (0/1,n) (0/1,n) (1,1) (0,1) ESTUDIANTE ESTUDIANTE codest codest nombre edificio nombre nombre padre padre ocupa tutor fecha fecha
- 13. Tema 7. Diseñológico de bases de datos relacionales 13 PROFESOR(codpro, nombre) ESTUDIANTE(codest, nombre, codpro, fecha) ESTUDIANTE PROFESOR HABITACIÓN(numhab, edificio) ESTUDIANTE(codest, nombre, numhab, fecha) ESTUDIANTE HABITACION ¿Y si hay muy pocos estudiantes que viven en una habitación del campus? PROFESOR HABITACIÓN codpro numhab (0/1,n) (0/1,n) (1,1) (0,1) ESTUDIANTE ESTUDIANTE codest codest nombre edificio nombre nombre codpro numhab padre padre ocupa tutor Nulos Borrado Nulos Borrado fecha fecha ¿nulos? ¿nulos?
- 14. Tema 7. Diseñológico de bases de datos relacionales 14 Ejercicios CLIENTE codcli (0/1,n) (¿,?) CITA nombre fecha hora CLIENTEcodcli (0,n) (1,1) nombre recomendado_por recomienda_a
- 15. Tema 7. Diseñológico de bases de datos relacionales 15 (e) Por cada relación binaria (m:n), incluir una nueva tabla con una clave ajena a cada una de las tablas correspondientes a las entidades participantes. La clave primaria, la clave primaria ... ¿cuál es la clave primaria? ¿Y los atributos de la relación? ASIGNATURA PACIENTE codasi codpac (0,n) (1,n) (1,n) (0,n) codest codmed nombre nombre fecha hora ESTUDIANTE MÉDICO nombre nombre cursa cita
- 16. Tema 7. Diseñológico de bases de datos relacionales 16 ASIGNATURA(codasi, nombre) ESTUDIANTE(codest, nombre) CURSA(codest, codasi) CURSA ESTUDIANTE CURSA ASIGNATURA PACIENTE(codpac, nombre) MÉDICO(codmed, nombre) CITA(codmed, fecha, hora, codpac) CITA MÉDICO CITA PACIENTE ASIGNATURA PACIENTE codasi codpac (0,n) (1,n) (1,n) (0,n) codest codmed nombre nombre fecha hora ESTUDIANTE MÉDICO nombre nombre cursa cita Nulos Borrado codest codasi codmed codpac Nulos Borrado
- 17. Tema 7. Diseñológico de bases de datos relacionales 17 Resumen de la correspondencia entre esquemas para las relaciones binarias Relación 1:1 Relación 1:n Relación n:m Integrar las dos tablas correspondientes a cada una de las entida- des participantes en la relación binaria, en una sola tabla. Es lo más aconsejable cuando ambas entidades tienen el mismo identifica- dor. Los atributos de la relación binaria también estarán en la tabla. OJO: es posible que algunos atributos deban aceptar nulos. Para este tipo de relaciones binarias no se puede escoger esta opción. Para este tipo de relaciones binarias no se puede escoger esta opción. Poner una clave ajena en la tabla correspon- diente a una de las entidades participantes en la relación binaria. La clave ajena se puede poner en cualquiera de las tablas. La tabla que recibe la clave ajena también recibe los atributos de la relación binaria. OJO: es posible que algunos atributos deban aceptar nulos. La clave ajena se debe poner en la tabla correspondiente a la entidad que participa en la relación binaria con cardinalidad máxima 1. Los atributos de la relación binaria se ponen como atributos en la tabla que recibe la clave ajena. OJO: es posible que algunos atributos deban aceptar nulos. Para este tipo de relaciones binarias no se puede escoger esta opción. Añadir al esquema una nueva tabla en la que se refleje la relación binaria. Es lo más aconsejable cuando ambas entidades participan en la relación de forma opcional y hay pocas ocurren- cias de la misma. Esta nueva tabla tiene una clave ajena a cada una de las dos tablas y también los atributos de la relación binaria. La nueva tabla tiene una clave ajena a cada una de las dos tablas y también los atributos de la relación binaria. La clave primaria de la nueva tabla será la clave ajena que hace referencia a la tabla de la entidad que participa en la relación binaria con cardinalidad máxima 1. Esta nueva tabla tiene una clave ajena a cada una de las dos tablas y también los atribu- tos de la relación binaria. La clave primaria variará según el significado de la relación binaria (hay que "meditarla").
- 18. Tema 7. Diseñológico de bases de datos relacionales 18 Continuamos con la metodología de diseño lógico ... 3. Validar cada esquema lógico local mediante la normalización. 4. Validar cada esquema frente a las transacciones del usuario. 5. Dibujar el diagrama entidad – relación. 6. Definir las restricciones de integridad. (a) Datos requeridos. (b) Restricciones de dominios. (c) Integridad de entidades. (d) Integridad referencial. (1) Regla de los nulos (Sí admite / No admite). (2) Regla del borrado (Restringir / Propagar / Anular). (3) Regla de la modificación (Restringir / Propagar / Anular). (e) Reglas de negocio.
- 19. Tema 7. Diseñológico de bases de datos relacionales 19 Continuamos con la metodología de diseño lógico ... 7. Revisar cada esquema lógico local con el usuario. Utilizar los DFD para comprobar la consistencia y completitud de los esquemas lógicos. 8. Mezclar los esquemas lógicos locales en un esquema lógico global. 9. Validar el esquema lógico global. 10. Estudiar el crecimiento futuro. 11. Dibujar el diagrama entidad/relación final. 12. Revisar el esquema lógico global con los usuarios.
- 20. Tema 7. Diseñológico de bases de datos relacionales 20 3. Normalización Técnica para diseñar bases de datos relacionales. Se debe a Codd (1972). No se utiliza como una estrategia de diseño de bases de datos. Se utiliza para verificar esquemas relacionales. Ventajas Evita anomalías en inserciones, modificaciones y borrados. Mejora la independencia de datos.
- 21. Tema 7. Diseñológico de bases de datos relacionales 21 Fecha: 16/2/99 Pedido nº: 123456 Proveedor nº: 9876 Nombre del proveedor: Productos Surtidos Dirección del proveedor: Borriol, Castellón Deseamos envíen: Número producto Descripción Precio unitario Cantidad Total 511246 Televisión 70.000 1 70.000 124456 Clavija antena 100 10 1.000 124763 Enchufe 150 10 1.500 Importe total: 72.500
- 22. Tema 7. Diseñológico de bases de datos relacionales 22 PEDIDO (npedido, nprov, nomprov, dirprov, fecha, LÍNEA (nproducto, descrip, precio, cant, total), importe) PEDIDO LÍNEA x x x x x x x x x x x x Hay atributos que tienen valores de tipo relación (tabla). x x x x x x x x x x x x x x x x x x x x
- 23. Tema 7. Diseñológico de bases de datos relacionales 23 PEDIDO (npedido, nprov, nomprov, dirprov, fecha, importe) LÍNEA (npedido, nproducto, descrip, precio, cant, total) PEDIDO npedido x x x x x x x x x x x x LÍNEA npedido nproducto x x x x x x x x x x x x x x x x x x x x x x x x
- 24. Tema 7. Diseñológico de bases de datos relacionales 24 PEDIDO (npedido, nprov, nomprov, dirprov, fecha, importe) LÍNEA (npedido, nproducto, descrip, precio, cant, total) • Guardar nuevo producto. Producto nº 511944, Reproductor de vídeo, 35.000 pesetas. • Modificar el precio de un producto. Producto nº 511246, Televisión, 68.000 pesetas. • Eliminar la única compra de un producto: Producto nº 124763, Enchufe, 150 pesetas. ¡Anomalías en las actualizaciones de datos! LÍNEA npedido PEDIDO
- 25. Tema 7. Diseñológico de bases de datos relacionales 25 PEDIDO (npedido, nprov, nomprov, dirprov, fecha, importe) LÍNEA (npedido, nproducto, cant, total) PRODUCTO (nproducto, descrip, precio) • Guardar nuevo proveedor. Proveedor nº 5194, Don Proveedor, Játiva. • Modificar la dirección de un proveedor. Proveedor nº 9876, Productos Surtidos, Castellón de la Plana. • Eliminar la única compra realizada a un proveedor. ¡Anomalías en las actualizaciones de datos! LÍNEA npedido PEDIDO LÍNEA nproducto PRODUCTO
- 26. Tema 7. Diseñológico de bases de datos relacionales 26 PEDIDO (npedido, nprov, fecha, importe) LÍNEA (npedido, nproducto, precio, cant, total) PRODUCTO (nproducto, descrip, precio) PROVEEDOR (nprov, nomprov, dirprov) LÍNEA npedido PEDIDO LÍNEA nproducto PRODUCTO PEDIDO nprov PROVEEDOR
- 27. Tema 7. Diseñológico de bases de datos relacionales 27 Dependencia funcional Y es funcionalmente dependiente de X, si X determina el valor de Y: X Y Ejemplo: CLIENTE(codcli, nombre, codpostal, población) codpostal población Observaciones La dependencia funcional es una noción semántica. Cada dependencia funcional es una clase especial de regla de integridad. Cada dependencia funcional representa una relación de uno a muchos.
- 28. Tema 7. Diseñológico de bases de datos relacionales 28 Primera forma normal (1FN) Una relación está en 1FN si, y sólo si, todos sus dominios contienen valores atómicos. PRODUCTO codprod nombre VERSIÓN número fecha ventas LH4 Ladrillo hueco 1 1/3/1996 30.000 2 1/8/1998 50.000 3 1/2/2000 13.000 LP7 Ladrillo perforado 1 1/6/1996 70.000 2 1/12/2000 PRODUCTO (codprod, nombre, VERSIÓN (número, fecha, ventas)) 1FN Se descompone en: PRODUCTO (codprod, nombre, descripción) VERSIÓN (codprod, número, fecha, ventas) hereda la clave primaria OJO VERSIÓN codprod PRODUCTO Nulos Borrado grupos repetitivos (valores no atómicos)
- 29. Tema 7. Diseñológico de bases de datos relacionales 29 Segunda forma normal (2FN) Una relación está en 2FN si, y sólo si, está en 1FN y, además, cada atributo no clave depende completamente de la clave primaria (no depende de algún subconjunto). INSCRIPCIÓN (estudiante, actividad, precio) 2FN actividad precio estudiante actividad precio 100 Tenis 1500 100 Yoga 1500 200 Tenis 1500 300 Escalada 5000 Se descompone en las proyecciones: INSCRIPCIÓN (estudiante, actividad) y ACTIVIDAD (actividad, precio) estudiante actividad precio misma actividad, mismo precio. INSCRIPCIÓN actividad ACTIVIDAD Nulos Borrado
- 30. Tema 7. Diseñológico de bases de datos relacionales 30 Tercera forma normal (3FN) Una relación está en 3FN si, y sólo si, está en 2FN y, además, cada atributo no clave no depende transitivamente de la clave primaria. INQUILINO (inqulino, edificio, alquiler) 3FN edificio alquiler inquilino edificio alquiler 100 E04 50.000 200 E13 50.000 300 E09 65.000 400 E04 50.000 Se descompone en las proyecciones: INQUILINO (inqulino, edificio) y EDIFICIO (edificio, alquiler) inquilino alquiler edificio mismo edificio, mismo alquiler. INQUILINO edificio EDIFICIO Nulos Borrado
- 31. Tema 7. Diseñológico de bases de datos relacionales 31 Ejercicio de normalización estudiante nombre apellido DNI dirección codbeca nombeca requisito fecha 0123 Carlos Gil 159357 C/ Paz, 23 A223 EEUU Ing. Sup. 10/10/98 7636 Paula Tena 913752 C/ Río Po, 1 B567 ERASMUS Ing. Téc. 12/11/98 7636 Paula Tena 913752 C/ Río Po, 1 A223 EEUU Ing. Sup. 14/10/98 7636 Paula Tena 913752 C/ Río Po, 1 G654 DRAC Ing. Sup. 15/09/99 0123 Carlos Gil 159357 C/ Paz, 23 G654 DRAC Ing. Sup. 17/09/98 9516 Andrés Calpe 682432 Plz. Sol, 40 G654 DRAC Ing. Sup. 12/09/99 0123 Carlos Gil 159357 C/ Paz, 23 B567 ERASMUS Ing. Téc. 12/11/98 9516 Andrés Calpe 682432 Plz. Sol, 40 B567 ERASMUS Ing. Téc. 23/11/99 0123 Carlos Gil 159357 C/ Paz, 23 A223 EEUU Ing. Sup. 12/10/99 3361 Lucía Porcar 243115 Plz. Sol, 26 A223 EEUU Ing. Sup. 12/10/99 ... ... ... ... ... ... ... ... ... SOLICITUD (estudiante, codbeca, fecha, nombre, apellido, DNI, dirección, nombeca, requisito)
- 32. Tema 7. Diseñológico de bases de datos relacionales 32 4. Desnormalización, partición de relaciones y optimización A partir del esquema lógico obtenido y teniendo en cuenta el modelado de la carga ... Se pueden fundir varias relaciones en una si se usan juntas con frecuencia mediante operaciones de JOIN Desnormalización. Se pueden dividir algunas relaciones con el objeto de reorganizar la distribución de los casos Partición Horizontal, o de los atributos Partición Vertical, de manera que una relación incluya atributos o casos a los que se requiera acceso simultáneo con frecuencia. Se pueden introducir otros cambios para conseguir un acceso más eficiente Optimización.
- 33. Tema 7. Diseñológico de bases de datos relacionales 33 Desnormalización Por ejemplo, se pueden fusionar las relaciones: CLIENTE(codcli, nombre, codpostal) y CODPOSTAL(codpostal, codpueblo) en una sola relación: CLIENTE(codcli, nombre, codpostal, codpueblo) Así se mejora el funcionamiento frente a la necesidad de hacer el JOIN de las dos tablas. Se notará más la mejora cuanto más frecuentes sean los accesos. Pero mucho OJO: se han introducido redundancias que ahora será necesario controlar ¿alguna idea sobre cómo hacerlo?
- 34. Tema 7. Diseñológico de bases de datos relacionales 34 Partición de tablas Por ejemplo, se puede descomponer la siguiente relación: EMPLEADO(codemp, nombre, teléfono, fecha_eval, aspecto1, aspecto2) en las relaciones: EMPLEADO(codemp, nombre, teléfono) EVALUACION(codemp, fecha_eval, aspecto1, aspecto2) porque no se accede con frecuencia a los datos de la evaluación de los empleados, o bien porque se quiere preservar la seguridad de los mismos. ¿Y qué hacemos para el usuario que necesita ver la tabla tal y como estaba?
- 35. Tema 7. Diseñológico de bases de datos relacionales 35 Optimización UNIVERSIDAD(universidad, director, vicedirector) Cada universidad tiene un director y de uno a tres vicedirectores ¿clave primaria? Hay una dependencia funcional no deseada: universidad director UNIVERSIDAD no se encuentra en 2FN debe descomponerse en: UNIVERSIDAD(universidad, director) ASISTENTE (universidad, vicedirector) Siempre que una aplicación necesite información de la universidad, debe leer entre dos y cuatro filas de datos. Una alternativa que consigue mayor eficiencia es: UNIVERSIDAD(universidad, director, vicedirector1, vicedirector2, vicedirector3) ¿nulos? ¿nulos? ¿nulos?