ESCUELA :

1. BASE DE DATOS II ESCUELA: CIENCIAS DE LA COMPUTACIÓN ING. JUAN CARLOS MOROCHO PONENTE: I BIMESTRE BIMESTRE: ABRIL 2007 – AGOSTO 2007 CICLO:

2. Objetivos Generales • Dotar al profesional en formación de las bases formales para el diseño de Bases de Datos. • Dar a conocer al profesional en formación los criterios aplicables en el diseño de Bases de Datos. • Desarrollar en el profesional en formación las destrezas necesarias para el diseño y puesta en marcha de una base de datos de acuerdo a sus necesidades.

3. Objetivos para el Primer Bimestre • Desarrollar en el profesional en formación las destrezas necesarias para el desarrollo de una base de datos a través de las tres fases principales: diseño conceptual, diseño lógico y diseño físico. • Analizar algunas técnicas para afinar un diseño de bases de datos.

4. Objetivos para el Primer Bimestre (cont.) • Reconocer los peligros de accesos indebidos que enfrenta una base de datos y la forma de contrarrestarlos.

5. Metodología • Es importante que apoye su estudio siguiendo la guía de la materia, puesto que no es posible revisar todo el contenido del libro, por lo que en la guía encontrará orientaciones útiles para aprovechar al máximo su tiempo y recursos. • El ingreso al campus virtual es de suma importancia, ya que allí se publican anuncios y material de interés para complementar el contenido del texto base.

6. Acceso al Campus Virtual htpp://www.utpl.edu.ec

7. Interacción en el Campus Virtual

8. Metodología • Es importante que usted dedique un tiempo semanal a la asignatura, para que pueda avanzar en forma continua con los conocimientos y pueda ir desarrollando el trabajo a distancia.

9. Contenidos esenciales del I Bimestre • Metodología de diseño de bases de datos. • Diseño conceptual • Diseño lógico • Diseño físico

10. Metodología de diseño de bases de datos Una metodología de diseño debería tener las siguientes características: • Claridad y comprensibilidad, ya que en el diseño participan distintas clases de usuarios y la metodología debe ser comprensible para todos ellos. • Capacidad de soportar la evolución de los sistemas, es decir debe soportar los cambios de los sistemas sin tener que cambiar todo el diseño de base de datos.

11. Metodología de diseño de bases de datos • Facilitar la portabilidad, es decir cambiar de un sistema informático a otro sin mayores inconvenientes. • Versatilidad respecto a los tipos de aplicaciones, ya que no debe estar orientada a un tipo de aplicaciones en concreto sino que puede utilizarse en aplicaciones diversas.

12. Metodología de diseño de bases de datos • Flexibilidad (independencia respecto de la dimensión de los proyectos), ya que debe servir tanto para proyectos grandes como pequeños. • Rigurosidad, puesto que con los principios metodológicos se pretende imprimir un carácter riguroso a la forma de hacer las cosas pero no debe resultar excesivamente formalista para no provocar el rechazo de los usuarios. • Adopción de estándares, aplicar en lo posible estándares internacionales para elaborar productos con altos niveles de calidad.

13. Factores críticos en el diseño de una Base de Datos • Trabajo interactivo con usuarios • Adoptar una metodología para el modelado • Utilización de diagramas para representar los modelos de datos • Construir un diccionario de datos para complementar los diagramas • Volver a repetir algunos pasos hasta que el diseño sea óptimo

14. Diseño conceptual El propósito de ésta fase es obtener una buena representación de los recursos de información, con independencia de usuarios o aplicaciones (SGBD), y sin realizar consideraciones sobre la eficiencia. Las principales tareas que se deben ejecutar son:

15. Diseño conceptual • Identificar las entidades • Identificar las relaciones • Identificar y asociar los atributos con las entidades y relaciones • Determinar los dominios de los atributos • Determinar los atributos de clave candidata, principal y alternativa • Considerar el uso de conceptos de modelado avanzados* • Comprobar si el modelo tiene redundancia • Validar el modelo conceptual comprobando las transacciones de los usuarios • Repasar el modelo de datos conceptual con los usuarios

16. Diseño conceptual • Examinar la ERS • Identificar objetos que tengan existencia propia • A veces difíciles de identificar por el lenguaje de usuarios • Se complica con la utilización de sinónimos y homónimos Identificar las entidades

17. Diseño conceptual (ejercicio) Crear un modelo entidad/relación que resuelva el siguiente problema de datos. Se trata de gestionar los datos de un banco que maneja estos datos: • Posee clientes que contratan cuentas en el banco. De los clientes tenemos su DNI, Nombre, Apellidos, Localidad, Dirección y Teléfono. • Todas las cuentas tienen un número de 20 dígitos de los cuatro primeros se refieren al banco, los cuatro siguientes a la entidad, los dos siguientes son de control y los 10 siguientes el número en sí de la cuenta. Toda cuenta tiene un saldo actual y se anota la fecha de contratación • Las cuentas pueden ser de ahorro, de plazo fijo (indicando el tiempo mínimo de supervivencia en años (1,2,3,..), cuentas vivienda y cuentas de pensiones (jubilación). • Del personal se anotan los siguientes datos, DNI, Nº personal, Nombre, Apellidos, Dirección, Teléfono y una Cuenta bancaria (que tiene que estar en el banco) • El personal puede tener o ser jefe. Un jefe puede tener un jefe superior.

18. Entidades identificadas

19. Diseño conceptual • Identificar las relaciones entre entidades • Se indican mediante verbos o expresiones verbales • Mayormente son binarias • Garantizar que se expresen todas las relaciones Identificar las relaciones

20. Entidades con sus relaciones

21. Diseño conceptual • Buscar nombres o frases nominales en la ERS • Puede ser una propiedad, cualidad identificador o característica • ¿Qué información necesitamos almacenar de x o y? • Atributos simples/compuestos – univaluados/multivaluados – derivados Identificar atributos de entidades y relaciones

22. Entidades y sus atributos

23. Diseño conceptual Determinar los dominios • Conjunto de valores que uno o mas atributos pueden tomar • Actualizar el diccionario de datos

24. Entidades con sus atributos claves

25. Diseño conceptual • Especialización/generalización, agregación y composición • No existen reglas claras de cuando aplicar estos conceptos • Decisión subjetiva y dependiente de las características a modelar Considerar conceptos de modelado avanzados (opcional)

26. Diseño conceptual Comprobar si el modelo tiene redundancia • Volver a examinar las relaciones uno a uno • Eliminar las relaciones redundantes • Considerar la dimensión temporal

27. Diseño conceptual • Manualmente resolver todas las transacciones • Dos métodos: descripción de las transacciones y utilización de las rutas de las transacciones Validar el modelo conceptual

28. Diseño conceptual • Revisar el modelo de datos con el usuario • Diagramas E/R y documentación de soporte • Repetir algunos pasos si es necesario • Hasta que el usuario esté dispuesto a “autorizar” el modelo Repasar el modelo de datos con los usuarios

29. Diseño lógico • Consiste en transformar el esquema conceptual obtenido en la etapa anterior, adaptándolo a una representación de tablas, apoyándose para ello en el modelo relacional.

30. Diseño lógico • Existen tres reglas básicas para convertir un modelo conceptual al modelo relacional, éstas son: • Todo tipo de entidad se convierte en una relación.

31. Diseño lógico

32. Diseño lógico • Todo tipo de interrelación n:n se transforma en una relación.

33. Diseño lógico

34. Diseño lógico • Para todo tipo de interrelación 1:n se realiza lo que se denomina propagación de clave (regla general), o se crea una nueva relación.

35. Diseño lógico Propagación de clave

36. Diseño lógico

37. Diseño lógico El producto es el modelo relacional

38. Diseño lógico • Una vez creadas las relaciones, éstas deben pasar por el proceso de normalización, que es un método formal que puede utilizarse para identificar relaciones basándose en sus claves y en las dependencias funcionales existentes entre sus atributos. Al normalizar se pretende evitar las anomalías de actualización asegurando la consistencia de los datos y a través de las dependencias funcionales conservar la integridad de la información.

39. Diseño físico • Es el proceso de conseguir una implementación, lo más eficiente posible, del esquema lógico. Permite al diseñador tomar decisiones sobre cómo hay que implementar la base de datos, por tanto el diseño físico está adaptado a un SGBD concreto.

40. Diseño físico

41. Diseño físico • Es el proceso de conseguir una implementación, lo más eficiente posible, del esquema lógico. Permite al diseñador tomar decisiones sobre cómo hay que implementar la base de datos, por tanto el diseño físico está adaptado a un SGBD concreto.

42. Monitorización y optimización del sistema final • Aparece el concepto de desnormalización • Como regla práctica, si el rendimiento no es satisfactorioy una tabla tiene baja tasa de actualización y una tasa de consulta muy alta, la desnormalización puede ser una técnica adecuada .

43. Seguridad de la base de datos • Mecanismos que protegen a la base de datos frente a amenazas intencionales o accidentales • Se trata de evitar: robo y fraude, pérdida de confidencialidad, pérdida de privacidad, pérdida de integridad y pérdida de disponibilidad

44. GRACIAS !!! Información de contacto: Telf. 2570275 ext. 2637 E-mail: jcmorocho@utpl.edu.ec, cmorocho4@utplonline.edu.ec Horario de tutoría semanal: Lunes 16H00 – 18H00 Martes y miércoles 16H00 – 17H00