BASE DE DATOS AVANZADAS

Autores:Keyner AbarcaNatalia Ludeña

Cristopher Ortega

Capítulo 16

METODOLOGÍA:diseño lógico de bases de datos para el modelo relacional

Paso 2: Construir y validar el modelo lógico de los datos.

Objetivo: Traducir el modelo de datos conceptual en un modelo lógico de datos y después validar este modelo para comprobar que sea estructuralmente correcto y capaz de soportar las transacciones requeridas.

Para lograr este objetivo, se realizarán los siguientes pasos:Paso 2.1 determinar las relaciones para el modelo lógico

de los datosPaso 2.2 validar las relaciones mediante técnicas de

normalizaciónPaso 2.3 validar las relaciones comprobando las

transacciones de los usuariosPaso 2.4 comprobar las restricciones de integridadPaso 2.5 repasar el modelo lógico de los datos con los

usuariosPaso 2.6 combinar los modelos lógicos de los datos en un

modelo global (paso opcional)Paso 2.7 verificar las consideraciones derivadas del

crecimiento futuro

Paso 2.1 determinar las relaciones para el modelo lógico de los datos

Crear tablas relacionales para el modelo lógico de los datos que representen las entidades, relaciones y atributos que se hayan identificado. En este paso vamos a derivar las tablas relacionales para el modelo lógico de datos con las que representar las entidades, relaciones y atributos. Describiremos la composición de cada tabla relacional utilizando DBDL.

Utilizaremos las siguientes estructuras que pueden aparecer en un modelo conceptual:

tipos de entidad fuertestipos de entidad débiles tipos de relación binaria uno a muchostipos de relación binaria uno a unotipos de relación recursiva uno a unotipos de relación superclase/subclasetipos de relación binaria muchos a muchostipos de relaciones complejasatributos multivaluados

Tipos de entidad fuertes

Se crea una tabla relacional que incluya todos los atributos simples de dicha entidad. Para los compuestos se incluye únicamente los atributos simples componentes.

Tipos de entidad débiles

Se crea una tabla relacional que incluya todos los atributos simples de dicha entidad. La clave principal de una entidad débil se deriva parcial o totalmente a partir de cada entidad propietaria, por lo que la identificación de la clave principal de una entidad débil no puede llevarse a cabo hasta que se hayan obtenido las tablas correspondientes a todas las relaciones existentes con las entidades propietarias.

Tipos de relaciones binarias uno a muchos Se designa como entidad padre a la entidad situada “en el

lado de uno” de la relación, y la “del lado de muchos” es la entidad hija. Para representar esta relación se incluye una copia de los atributos de clave principal de la entidad padre en la tabla relacional que represente a la entidad hija, para que actúe como clave externa.

Tipos de relaciones binarias uno a uno Se emplean restricciones de participación a la hora de

decidir si es mejor representar la relación combinando las entidades implicadas en una única tabla relacional o crear dos tablas relacionales y colocar una copia de la clave principal de la tabla en la otra.

Participación obligatoria en ambos lados de la relación

Participación obligatoria en un lado de la relación Participación opcional en ambos lados de la relación

Tipos de relaciones recursivas uno a uno También se utilizan las restricciones de participación: Con participación obligatoria en ambos lados

Con participación obligatoria en un solo lado

Tipos de relaciones superclase/subclase Identificamos la entidad superclase como padre, y la

subclase como hija. Hay algunas opciones para representar esta relación en forma de una o más tablas. La selección de la opción más apropiada dependerá de diversos factores, como las restricciones de disyunción de participación que afecten a la relación, de si las subclases están implicadas en relaciones diferentes y del número de participantes en la relación.

Tipos de relaciones binarias muchos a muchos Crearemos una tabla que represente la relación e

incluiremos los atributos que formen parte de la relación. Se añade una copia de los atributos de clave principal de las entidades que participan en la relación dentro de la nueva tabla, con el fin de que actúen como claves externas. Una o ambas claves externas formarán también la clave principal de la nueva tabla, posiblemente en combinación con uno o más atributos de la relación.

Tipos de relaciones complejas Crearemos una tabla que represente la relación e

incluiremos los atributos que formen parte de la relación. Se añade una copia de los atributos de clave principal de las entidades que participan en la relación dentro de la nueva tabla, con el fin de que actúen como claves externas. Las claves externas que representen una relación de tipo “muchos” generalmente formarán también la clave principal de esta nueva tabla, posiblemente en combinación con algunos de los atributos de la relación.

Atributos Multivaluados:Un atributo multivaluado tiene múltiples valores para un mismo elemento de la entidadEjemplo: números de teléfono , títulos de un profesional

Para cada atributo multivaluado de una entidad hay que crear una nueva tabla que represente el atributo multivaluado, e incluir en ella la clave principal de la entidad con el fin de que actué como clave externa

EjemploEjemploBranch (branchNo, street ,city, postcode)Clave principal branchNo

Se incluye branchNo en Telephone

Telephone(telNo,branchNo)Clave Principal telNoClave Externa branchNo hace referencia a hace referencia a

Branch(branchNo)

Documentación de las tablas y de los atributos Documentación de las tablas y de los atributos de clave externade clave externa Esto es importante para las entidades débiles que

dependen de la inclusión de la clave principal de la entidad padre para formar una clave principal propia

Validar las relaciones mediante técnicas de normalización

En este paso vamos a validar las agrupaciones de atributos de cada tabla utilizando reglas de normalización.

Las tablas deben de tener una redundancia de datos mínima, con el fin de evitar anomalías de actualización

Un diseño normalizado es robusto y esta libre de anomalías

Paso 2.3 : Validar las relaciones comprobando las transacciones de los usuarios

En este paso comprobamos que lar relaciones creadas soportan también esas transacciones , garantizando así que no se haya introducido ningún error.

Paso 2.4 : Comprobar las restricciones de integridadLas restricciones de integridad son las restricciones que queremos imponer para proteger la base de datos frente a la posibilidad de que llegue a ser incompleta , imprecisa o incoherente.

Consideramos los siguientes tipos de restricciones de integridad:

Datos Requeridos :Algunos atributos deben siempre contener un valor valido , no se permite que contengan valores nulos. Ejemplo: Todo empleado debe tener una categoría (asistente , supervisor , administrador)

Restricciones relativas a los dominios de los atributosTodo atributo tiene un dominio , es decir un conjunto de valore legales Ejemplo: sexo de una persona “Masc” “Fem”

MultiplicidadRepresenta las restricciones que se imponen a las relaciones entre los datos de la base de datos

Integridad de entidadEn una relación base ningún atributo de una clave principal puede ser nulo

Integridad referencialPara garantizar la integridad referencial especificamos restricciones de existencia que definen las condiciones bajo las cuales se puede actualiza, insertar , borrar una clave candidata o una clave externa.

Para ello considere los siguientes pasos:

Caso 1: Inserción de una tupla en la tabla hija

Hay que comprobar que el atributo de la clave externa tenga un valor nulo o un valor que se corresponda con una tupla existente.

Caso 2: Borrado de una tupla de la tabla hijaSi se borra una tupla de una tabla hija las condiciones de

integridad no se ven afectadasCaso 3: Actualización de la clave externa de la tupla

hijaSimilar al caso 1 Caso 4: Selección de una tupla en la tabla padre Insertar una tupla en la tabla padre no afecta a la integridad

referencial , dicha tupla se convierte en un padre que no tiene ningún hijo asignado.

Caso 5: Borrado de una tupla de la tabla padreSi se borra la tabla padre , la integridad referencial se

pierde si existen tuplas hijas que hagan referencia a la tupla padre borrada.

Caso 6: Actualización de la clave principal de la tupla Caso 6: Actualización de la clave principal de la tupla padrepadre

Si se actualiza el valor de la clave principal en una tabla padre se pierde la integridad referencial si existe una tupla hija que haga referencia al valor de clave principal antiguo.

Lo normal es que las actualizaciones se especifiquen con la opción CASCADE

Documentación de las restricciones de integridadHay que documentar todas las restricciones de integridad en el diccionario de datos para poder tenerlas en cuenta en el diseño físico.

Paso 2.5 : Repasar el modelo lógico de los datos con los usuarios

El modelo lógico debe estar ahora completo y totalmente documentado.

Para confirmar , hay que es así hay que solicitar a los usuarios que revisen el modelo lógico de los datos y requisitos reales de datos de la organización.

Modelo lógico de los datos y los diagramas de flujo de datos

Un modelo lógicoUn modelo lógico de datos refleja la estructura de los datos almacenados para una organización .Un diagrama de flujo de datosUn diagrama de flujo de datos muestra como se mueven los datos por la organización y como se los guarda.

Paso 2.6: Combinar los modelos lógicos de los datos en un modelo global

Este paso solo es necesario para el diseño de una base de datos con múltiples vistas de usuario que están gestionando mediante la técnica de integración de vistas.

Para facilitar la descripción del proceso de combinación utilizamos:

Modelo lógico de datos local: Representa una o mas vistas de usuario pero no todas de la base de datos

Modelo lógico de datos global: Representa todas las vistas de usuario de la base de datos.

Revisar los nombres y el contenido de las Entidades/Tablas y sus claves

candidatas Suele ser útil revisar los nombres y descripciones de

las entidades/tablas que aparecen en los modelos locales de los datos, inspeccionando el diccionario de los datos:

Tengan el mismo nombre pero sean de hecho, diferentes (homónimas)

Sean iguales pero tengan nombres diferentes (sinónimos)

Puede ser necesario compara el contenido de los datos de cada entidad/relación. Utilice las claves candidatas como ayuda para identificar las entidades/tablas equivalentes que pueden estar nombradas en las diferentes vistas.

Revisar los nombres y los contenidos de las relaciones/claves externas

Comparar los nombres de las entidades/tablas y de las relaciones claves externas es un buen punto de partida a la hora de buscar posibles solapamientos entre las vistas; siempre y cuando seamos consientes de las posibles fuentes de error en este proceso.

Es preciso tener cuidado con las entidades o relaciones que tengan el mismo nombre pero representen, de hecho conceptos diferentes.

Combinar las Entidades /tablas de los modelos de datos locales

Examinar el nombre y el contenido de cada Entidad/Tabla de los modelos que ay que cambiar para determinar si las entidades/tablas presentan una misma cosa puede por lo tanto cambiarse.

Combinar las Entidades/Tablas que tengan el mismo nombre y la misma clave principal.

Combinar las Entidades/Tablas que tengan el mismo nombre pero diferentes claves principales

Combinar las entidades /tablas que tengan nombres diferentes y utilicen claves principales iguales o diferentes.

Combinación de las entidades/tablas con el Mismo Nombre y la Misma Clave

PrincipalLas entidades/tablas con la misma clave

principal representan el mismo objeto del Mundo Real. La entidad/tabla combinada incluirá los atributos de las entidades tablas originales, eliminando los posibles duplicados.

Combinación De Las Entidades/Tablas Con El Mismo Nombre Pero Diferentes

Claves Principales

Podemos combinar dos entidades/tablas con el mismo nombre y similares claves candidatas, pero diferentes pero con diferentes claves principales.

Combinación de las entidades /tablas con Diferentes Nombres y que Utilicen Claves Principales Iguales o Diferentes

Podemos identificar entidades/tablas que tienen diferentes nombres pero parecen tener el mismo nombre. Se pueden detectase de la siguiente forma:

Su nombre, que indica que tiene un propósito similar.

Su contenido y, en particular su clave principal.Su asociación con relaciones concretas.

Incluir (Sin Combinarlas) Las Entidades/Tablas Exclusivas De Cada

Modelo De Datos Locales

Todas las tablas e entidades restantes o las tablas diferentes se incluirán en el modelo global sin ninguna educación.

Combinar Las Relaciones /Claves Externas De Los Modelos De Datos

Locales

Examinaremos el nombre y el propósito de cada relación /clave externa incluida en los modelos de datos. Existen dos actividades que son:

Combinar las relaciones/claves externas de los modelos de datos locales

Combinar las relaciones/claves externas que tengan diferentes nombres pero el mismo propósito.

Verificar Si Falta Alguna Entidad/Tabla O Relación/Clave Externa

Es una de las tareas más difíciles a la hora de generar el modelo global es identificar las entidades/tablas o relaciones/claves externas entre los diferentes modelos de datos locales.

Comprobar las Claves Externas

Comprobar que las claves externas de las tablas hijas siguen siendo correctas y realizar cualquier modificación necesaria.

Comprobar Las Restricciones De Integridad

Comprobar que las restricciones de integridad correspondientes al modelo lógico global de los datos no entren en conflictos con las restricciones originalmente especificadas para cada vista.

Dibujar El Diagrama ER GlobalActualizar La Documentación

Validar El Esquema Lógico Global

Objetivo: Validar las tablas creadas a partir del modelo lógico de datos global usando la técnica de normalización y garantizar que soporten las transacciones requeridas

Revisión Del Modelo Lógico Global De Los Datos Con Los Usuarios

Objetivo: Revisar el modelo lógico de datos global con los usuarios para verificar que éstos consideren el modelo como una representación real de los requisitos de datos de la organización.

Paso 2.7 Verificar las consideraciones derivadas del crecimiento futuro

Objetivo: Determinar si es necesario prever para el futuro cambios significativos y evaluar si el modelo lógico de datos puede aceptar dichos cambios.

El diseño lógico concluye tomando en consideración si el modelo obtenido es susceptible de ampliación para soportar posibles desarrollos futuros