WIXLIB

TEMA 7. DISEÑO LÓGICO DEBASES DE DATOS RELACIONALES1. Introducción2. Metodología de diseño lógico en el modelo relacional3. Normalización4. Desnormalización, partición de relaciones yoptimización

1. IntroducciónDiseñ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 laestructuración de datos y el modelado de restricciones disponibles en el modelo lógico.esquema conceptualinformación de la cargacriterios de rendimientoDISEÑOLÓGICOesquema lógicoInformació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.Tema 7. Diseño lógico de bases de datos relacionales2

2. Metodología de diseño lógico en el modelo relacional1. Convertir los esquemas conceptuales locales enesquemas lógicos locales.2. Derivar un conjunto de relaciones (tablas) para cadaesquema lógico local.Construir y validarlos esquemas lógicos localespara cada vista de usuario3. Validar cada esquema mediante la normalización.4. Validar cada esquema frente a las transacciones delusuario.5. Dibujar el diagrama entidad – relación.6. Definir las restricciones de integridad.7. Revisar cada esquema lógico local con el usuariocorrespondiente.8. Mezclar los esquemas lógicos locales en un esquemalógico global.Construir y validarel esquema lógico global9. 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.Tema 7. Diseño lógico de bases de datos relacionales3

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 cardinalidadde las nuevas relaciones binarias dependerá de su significado. Si la relación sustituida tieneatributos, éstos serán los atributos de la nueva rip 0,n)codavimatrícula(0,n)TRIPULACIÓNTema 7. Diseño lógico de bases de datos relacionalescodtripnombre4

(b) Eliminar las relaciones IE(0,n)CIUDADnacimiento(0,1)Tema 7. Diseño lógico de bases de datos relacionales(0,n)5

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 dentrode la tabla, como un atributo más.¾ De entre los identificadores de la entidad se debe escoger uno como clave primaria dela ñotítulotítulo ppalautoridiomasubtítuloLIBRO(isbn, editorial, AUTOR(autor), idioma, título ppal, subtítulo, EDICIÓN(número, año))Tema 7. Diseño lógico de bases de datos relacionales6

(b) Hay tres opciones para representar las jerarquías de generalización.a1a2E( p/t, e/s Tema 7. Diseño lógico de bases de datos a2(0/1,1/n)AD7

(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)NulosBorradoE1.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;Tema 7. Diseño lógico de bases de datos relacionales8

(c) Por cada relación binaria (1:1), incluir la clave primaria de la tabla correspondiente a laentidad padre en la tabla de la entidad hijo como una clave ajena. ¿Y los atributos de la relación?hijo(0,1)EMPLEADOcodemp nombre(1,1)VEHíCULOconducefecha inimatrículamodelohijo(1,1)EMPLEADOcodemp nombre(0,1)conducefecha iniTema 7. Diseño lógico de bases de datos relacionalesVEHíCULOmatrículamodelo9

hijo(0,1)EMPLEADOcodemp nombre(1,1)VEHíCULOconducefecha inimatrículamodeloEMPLEADO(codemp, nombre )¿nulos?VEHíCULO(matrícula, modelo, codemp, fecha ini)codempNulos BorradoVEHíCULOEMPLEADO¿son tan diferentes?hijo(1,1)EMPLEADOcodemp nombre(0,1)conducefecha iniVEHíCULOmatrículamodeloVEHíCULO(matrícula, modelo)¿nulos?EMPLEADO(codemp, nombre, matrícula, fecha ini)Nulos BorradomatrículaEMPLEADOVEHíCULO¿Y si las dos entidades participan con cardinalidad (0,1)? ¿Y si son ambas (1,1)?Tema 7. Diseño lógico de bases de datos relacionales10

Ojo: Si las entidades relacionadas son sinónimos, integrarlas en una sola tabla.codcli(0,1)(1,1)CLIENTEdirección¡¡son codcli, dirección, nombre, dirección envío)ENVÍO es una entidad débil porque no tiene atributos que le sirvan como identificador.acompaña aEjerciciocodpernombre(0,1)PERSONA(1,1)es acompañada porTema 7. Diseño lógico de bases de datos relacionales11

(d) Por cada relación binaria (1:n), incluir la clave primaria de la tabla correspondiente a laentidad padre en la tabla de la entidad hijo (será una clave ajena). ¿Y los atributos de IÓNnumhabedificioTema 7. Diseño lógico de bases de datos relacionalesocupafecha(0,1)ESTUDIANTEcodest nombre12

ombrePROFESOR(codpro, nombre)(1,1)fechacodestnombreESTUDIANTE(codest, nombre, codpro, ITACIÓN(numhab, edificio)(0,1)ESTUDIANTEcodest nombreESTUDIANTE(codest, nombre, numhab, fecha)ESTUDIANTEnumhabNulosBorradoHABITACION¿Y si hay muy pocos estudiantes que viven enuna habitación del campus?Tema 7. Diseño lógico de bases de datos relacionales13

a horarecomienda a(0,n)codclinombreCLIENTE(1,1)recomendado porTema 7. Diseño lógico de bases de datos relacionales14

(e) Por cada relación binaria (m:n), incluir una nueva tabla con una clave ajena a cada una de lastablas correspondientes a las entidades participantes. La clave primaria, la clave primaria .¿cuál es la clave primaria? ¿Y los atributos de la mbrefechaTema 7. Diseño lógico de bases de datos relacionalesnombrecodmednombrehora15

(0,n)ASIGNATURAcodasicursaASIGNATURA(codasi, raTema 7. Diseño lógico de bases de datos relacionalesESTUDIANTE(codest, nombre)CURSA(codest, ulos BorradoPACIENTE(codpac, nombre)MÉDICO(codmed, nombre)CITA(codmed, fecha, hora, codpac)codmedCITAMÉDICOcodpacCITAPACIENTENulos Borrado16

Resumen de la correspondencia entre esquemas para las relaciones binariasRelación 1:1Integrar las dos tablascorrespondientes acada una de las entidades participantes en larelación binaria, en unasola tabla.Relación 1:nEs lo más aconsejable cuando ambasentidades tienen el mismo identifica- Para este tipo de relaciones binariasdor. Los atributos de la relación binaria no se puede escoger esta opción.también estarán en la tabla. OJO: esposible que algunos atributos debanaceptar nulos.Relación n:mPara este tipo de relacionesbinarias no se puede escogeresta opción.La clave ajena se debe poner en latabla correspondiente a la entidad queLa clave ajena se puede poner enPoner una clave ajena cualquiera de las tablas. La tabla que participa en la relación binaria conPara este tipo de relacionesen la tabla correspon- recibe la clave ajena también recibecardinalidad máxima 1. Los atributos binarias no se puede escogerdiente a una de lasde la relación binaria se ponen como esta opción.los atributos de la relación binaria.entidades participantes OJO: es posible que algunos atributos atributos en la tabla que recibe laen la relación binaria. deban aceptar nulos.clave ajena. OJO: es posible quealgunos atributos deban aceptar nulos.Es lo más aconsejable cuando ambasentidades participan en la relación deAñadir al esquema una forma opcional y hay pocas ocurrennueva tabla en la quecias de la misma. Esta nueva tablase refleje la relacióntiene una clave ajena a cada una debinaria.las dos tablas y también los atributosde la relación binaria.Tema 7. Diseño lógico de bases de datos relacionalesLa nueva tabla tiene una clave ajena acada una de las dos tablas y tambiénlos atributos de la relación binaria. Laclave primaria de la nueva tabla serála clave ajena que hace referencia a latabla de la entidad que participa en larelación binaria con cardinalidadmáxima 1.Esta nueva tabla tiene unaclave ajena a cada una de lasdos tablas y también los atributos de la relación binaria. Laclave primaria variará según elsignificado de la relaciónbinaria (hay que "meditarla").17

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

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

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.Ventajas9 Evita anomalías en inserciones, modificaciones y borrados.9 Mejora la independencia de datos.Tema 7. Diseño lógico de bases de datos relacionales20

Fecha: 16/2/991234569876Productos SurtidosBorriol, CastellónPedido nº:Proveedor nº:Nombre del proveedor:Dirección del proveedor:Deseamos avija antena100101.000124763Enchufe150101.500Importe total: 72.500Tema 7. Diseño lógico de bases de datos relacionales21

PEDIDO (npedido, nprov, nomprov, dirprov, fecha,LÍNEA (nproducto, descrip, precio, cant, total), xxHay atributos que tienen valores de tipo relación (tabla).Tema 7. Diseño lógico de bases de datos relacionales22

PEDIDO (npedido, nprov, nomprov, dirprov, fecha, importe)LÍNEA (npedido, nproducto, descrip, precio, cant, total)PEDIDOnpedidoxxxxxxxxxxxxTema 7. Diseño lógico de bases de datos relacionalesLÍNEAnpedido nproductoxxxxxxxxxxxxxxxxxxxxxxxx23

PEDIDO (npedido, nprov, nomprov, dirprov, fecha, importe)LÍNEA (npedido, nproducto, descrip, precio, cant, total)LÍNEAnpedidoPEDIDO 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!Tema 7. Diseño lógico de bases de datos relacionales24

PEDIDO (npedido, nprov, nomprov, dirprov, fecha, importe)LÍNEA (npedido, nproducto, cant, total)PRODUCTO (nproducto, descrip, precio)LÍNEAnpedidoPEDIDOLÍNEAnproductoPRODUCTO 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!Tema 7. Diseño lógico de bases de datos relacionales25