DiseñO LóGico De Bases De Datos Para El Modelo Relacional
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

DiseñO LóGico De Bases De Datos Para El Modelo Relacional

on

  • 26,585 views

 

Statistics

Views

Total Views
26,585
Views on SlideShare
26,494
Embed Views
91

Actions

Likes
1
Downloads
431
Comments
1

1 Embed 91

http://www.slideshare.net 91

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
  • jaja no entendi nada pero de todas formas gracias
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

DiseñO LóGico De Bases De Datos Para El Modelo Relacional Presentation Transcript

  • 1.
    • BASE DE DATOS AVANZADAS
    • Autores:
    • Keyner Abarca
    • Natalia Ludeña
    • Cristopher Ortega
  • 2. Capítulo 16 METODOLOGÍA: diseño lógico de bases de datos para el modelo relacional
  • 3. 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.
  • 4.
    • Para lograr este objetivo, se realizarán los siguientes pasos:
    • Paso 2.1 determinar las relaciones para el modelo lógico de los datos
    • Paso 2.2 validar las relaciones mediante técnicas de normalización
    • Paso 2.3 validar las relaciones comprobando las transacciones de los usuarios
    • Paso 2.4 comprobar las restricciones de integridad
    • Paso 2.5 repasar el modelo lógico de los datos con los usuarios
    • Paso 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
  • 5. 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.
  • 6.
    • Utilizaremos las siguientes estructuras que pueden aparecer en un modelo conceptual:
    • tipos de entidad fuertes
    • tipos de entidad débiles
    • tipos de relación binaria uno a muchos
    • tipos de relación binaria uno a uno
    • tipos de relación recursiva uno a uno
    • tipos de relación superclase/subclase
    • tipos de relación binaria muchos a muchos
    • tipos de relaciones complejas
    • atributos multivaluados
  • 7.
    • 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.
  • 8.
    • 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
  • 9.
    • 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.
  • 10.
    • 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.
  • 11.
    • Atributos Multivaluados:
    • Un atributo multivaluado tiene múltiples valores para un mismo elemento de la entidad
    • Ejemplo: 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
  • 12. Ejemplo
    • Branch (branchNo, street ,city, postcode)
    • Clave principal branchNo
    • Se incluye branchNo en Telephone
    • Telephone(telNo,branchNo)
    • Clave Principal telNo
    • Clave Externa branchNo hace referencia a Branch(branchNo)
  • 13. Documentación de las tablas y de los atributos de 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
  • 14. 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 integridad
    • Las 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)
  • 15. Restricciones relativas a los dominios de los atributos
    • Todo atributo tiene un dominio , es decir un conjunto de valore legales Ejemplo: sexo de una persona “Masc” “Fem”
    • Multiplicidad
    • Representa las restricciones que se imponen a las relaciones entre los datos de la base de datos
    • Integridad de entidad
    • En una relación base ningún atributo de una clave principal puede ser nulo
    • Integridad referencial
    • Para 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:
  • 16. 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 hija
    • Si se borra una tupla de una tabla hija las condiciones de integridad no se ven afectadas
    • Caso 3: Actualización de la clave externa de la tupla hija
    • Similar 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 padre
    • Si se borra la tabla padre , la integridad referencial se pierde si existen tuplas hijas que hagan referencia a la tupla padre borrada.
  • 17. Caso 6: Actualización de la clave principal de la tupla padre
    • 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 integridad
    • Hay que documentar todas las restricciones de integridad en el diccionario de datos para poder tenerlas en cuenta en el diseño físico.
  • 18. 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ógico de datos refleja la estructura de los datos almacenados para una organización . Un diagrama de flujo de datos muestra como se mueven los datos por la organización y como se los guarda.
  • 19. 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.
  • 20. 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.
  • 21. 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.
  • 22. 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.
  • 23. Combinación de las entidades/tablas con el Mismo Nombre y la Misma Clave Principal
    • Las 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.
  • 24. 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.
  • 25. 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.
  • 26. 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.
  • 27. 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.
  • 28. 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.
  • 29. Comprobar las Claves Externas
    • Comprobar que las claves externas de las tablas hijas siguen siendo correctas y realizar cualquier modificación necesaria.
  • 30. 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 Global
    • Actualizar La Documentación
  • 31. 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.
  • 32. 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
    •  
    •