You are on page 1of 157

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125

– Bases de datos avanzadas Guía de componente práctico

301125 - BASES DE DATOS AVANZADAS
Curso Electivo

ANÍVAR CHAVES TORRES (Director Nacional)

JAVIER JIMENEZ (Acreditador)

San Juan de Pasto 7 de febrero de 2012

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

La primera versión de este documento fue escrita por el ingeniero Rogelio Vásquez Bernal, posteriormente ha sido actualizado por otros profesionales, docentes de la UNAD, cuyos nombres no fueron registrados. Esta versión del documento ha sido editada por Anívar Chaves Torres. Este documento fue preparado para estudiantes de Ingeniería de sistemas de la Unad y se acoge a la licencia Creative Commons 3.0. En consecuencia, se permite su uso con fines académicos, siempre que se reconozca el crédito al autor. Se prohíbe la reproducción, por cualquier medio, con fines comerciales. Los ejemplos y ejercicios han sido diseñados exclusivamente con fines didácticos, el autor, el editor y la universidad no asumen ninguna responsabilidad por la aplicación de los mismos en con propósitos diferentes a la comprensión de los temas de este curso.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

CONTENIDO Número de créditos y dedicación horaria................................................................................. 6 Protocolo........................................................................................................................................ 7 Introducción general al curso ................................................................................................... 14 Unidad I. Bases de datos distribuidas..................................................................................... 15 Capitulo 1. Conceptos básicos de bases de datos ........................................................... 15 Lección 1. Modelo entidad relación................................................................................. 15 Lección 2. Elementos del Modelo entidad relación....................................................... 18 Lección 3. Álgebra relacional ........................................................................................... 28 Lección 5. Transacciones ................................................................................................. 39 Capítulo 2. Diseño de bases de datos distribuidas........................................................... 50 Lección 6. Bases de datos distribuidas .......................................................................... 50 Lección 7. Bases de datos distribuidas .......................................................................... 55 Lección 8. Fragmentación................................................................................................. 59 Lección 9. Tipos de fragmentación de datos ................................................................. 64 Lección 10. Diseño de replica .......................................................................................... 68 Capitulo 3. Consultas............................................................................................................. 70 Lección 11. Consultas distribuidas .................................................................................. 70 Lección 12. Descomposición de una consulta y localización de datos distribuidos 74 Lección 13. Transacciones Distribuidas ......................................................................... 76 Lección 14. Consistencia de la base de datos interna................................................. 84 Lección 15. Catálogo ....................................................................................................... 101 Unidad 2. Bodegas de datos .................................................................................................. 106 Capítulo 4. Diseño de bodegas de datos ......................................................................... 106

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 16. Introducción ................................................................................................. 106 Lección 17. Construcción y manejo de una bodega de datos .................................. 108 Lección 18. Construcción del Data Warehouse. ......................................................... 109 Lección 19. Estrategias recomendadas para diseño de datos ................................. 111 Lección 20. Factores de riesgo...................................................................................... 114 Capitulo 5. Minería de datos............................................................................................... 115 Lección 22. Fundamentos del Data Mining.................................................................. 116 Lección 23. Alcance de Data Mining ............................................................................. 117 Lección 24. Fases de un Proyecto de Minería de Datos ........................................... 119 Lección 25. Cómo Trabaja el Data Mining?................................................................. 120 Capítulo 6. Herramientas de minería de datos................................................................ 122 Lección 26. Redes neuronales artificiales:................................................................... 122 Lección 27. Árboles de decisión: ................................................................................... 123 Lección 28. Método del vecino más cercano:.............................................................. 124 Lección 29. Algoritmos genéticos .................................................................................. 125 Lección 30. Regla de inducción: .................................................................................... 126 Unidad 3. Bases de datos orientadas a objetos.................................................................. 127 Capítulo 7. Orientación a objetos ...................................................................................... 127 Lección 31. Introducción ................................................................................................ 127 Lección 32. Conceptos básicos: .................................................................................... 129 Lección 33. Arquitectura de administrador de sistemas de BDOO.......................... 132 Lección 34. Sistema administradores de bases de datos orientadas a objetos (SABD-OO) ....................................................................................................................... 134 Lección 35. El sistema Postgres................................................................................... 135 Capitulo 8. Lenguaje de Modelado Unificado UML ........................................................ 136

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 36. Introducción ................................................................................................. 136 Lección 37. ¿Método o Lenguaje de Modelado? ........................................................ 138 Lección 38. Una perspectiva de UML ........................................................................... 140 Lección 39. Diagramas de Secuencia .......................................................................... 145 Lección 40. Diagramas de Colaboración...................................................................... 147 Capítulo 9. Modelado con UML ......................................................................................... 148 Lección 41. Modelando el comportamiento de las Clases con Diagramas de Estado ............................................................................................................................................ 148 Lección 42. Diagramas de Actividad............................................................................. 150 Lección 43. Modelando Componentes de Software ................................................... 152 Lección 44. Modelando la Distribución y la Implementación..................................... 153 Lección 45. Diseño de Bases de Datos Relacionales -- Una extensión informal de UML .................................................................................................................................... 154

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Número de créditos y dedicación horaria
El curso de Bases de datos avanzada está configurado como curso de 3 créditos. El sistema de créditos, garantiza procesos de movilidad entre instituciones del sistema de educación superior e indica la cantidad de tiempo que un estudiante debe invertir para conocer y manejar los temas propuestos en un curso académico. Para la UNAD, por cada crédito académico, el estudiante debe invertir: 2 horas de trabajo individual por semana. El tiempo de trabajo individual lo define el estudiante, de acuerdo a su disponibilidad de tiempo. En este espacio se incluye el tiempo de trabajo colaborativo. 1 hora de trabajo en acompañamiento con tutor. Sea mediante tutorias CV o ST Es decir, que el curso exige que el estudiante mínimo invierta 144 horas en el semestre

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Protocolo
Introducción El curso de Bases de datos Avanzada hace una revisión acerca de diversas aplicaciones, en cuanto a bases de datos se refiere, que permiten identificar ventajas, desventajas y áreas de aplicación. Este curso es electivo, pretende fortalecer los conocimientos básicos de bases de datos y revisar los temas de diferentes tipos de aplicación. Es un curso metodológico, de tres créditos (3), lo que significa que deben realizar procesos de aprendizaje de por lo menos 144 horas en el semestre: 108 horas de dedicación independiente, investigando, leyendo, interiorizando los conceptos, desarrollo de actividades colaborativas con otros compañeros de curso; 36 horas de acompañamiento tutorial, donde se resuelven dudas, se apoya el proceso individual y de grupo. El curso pretende: Conocer otros tipos de modelos de datos. Determinar las condiciones, necesidades, ventajas y desventajas de los diferentes tipos de bases de datos. Aplicar los conceptos de acuerdo a los requerimientos de la empresa Justificación Los sistemas de bases de datos, son los más importantes para el manejo eficiente de información. Aunque el sustento teórico sigue siendo el mismo, las realidades de la empresa, las aplicaciones de la información almacenadas en las bases de datos, como soporte decisional, las inclusión de los objetos en el mundo planificado y pensado para registros planos, hace de este curso importante para ver otras realidades y retos en el desarrollo de los sistemas de bases de datos. Las competencias que promueve el curso y que son necesarias son: Cognitiva: Capacidad de apropiarse de un conjunto de conocimientos a través del desarrollo, monitoreo y aplicación de procesos de pensamiento. Comunicativa: Capacidad de comprender, expresar mensajes y de desarrollar procesos argumentativos, apoyados por las relaciones interpersonales.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Contextual: Capacidad de ubicar el conocimiento en el contexto científico, político, cultural, tecnológico, social y en el plano nacional e internacional, así como la disposición y capacidad para aplicarlo en procesos de transformación que inciden en la calidad de vida de la población. Valorativa: Capacidad de apropiarse de valores como el respeto a la vida y a las ideas de los demás; la dignidad humana, la convivencia, la solidaridad, la tolerancia y la libertad que orientan las acciones del individuo como persona, como ser social y como profesional. Para el logro de éstas competencias, es necesario que se planifique de manera responsable el proceso de auto estudio por parte del estudiante si se quieren lograr resultados positivos en el aprendizaje de los conceptos incluidos en el curso. Este proceso se puede planificar en diferentes momentos: Autoestudio: Estudio individual del material sugerido y consulta de otras fuentes documentales (consultas en bibliotecas, Internet, bibliografía recomendada, consulta a bases de datos documentales, entre otros) Trabajo en grupos colaborativos: Creación de grupos de estudio o discusión con el propósito de proponer ideas, resolver dudas o preparar consultas estructuradas al tutor. Consultas al tutor: Consulta al tutor de las inquietudes surgidas en el punto anterior. Retroalimentación: Una vez el tutor haya resuelto las inquietudes, estudie nuevamente el tema, teniendo en cuenta las sugerencias o respuestas dadas en los encuentros por el tutor. Procesos de evaluación: Una vez se haya realizado el proceso de retroalimentación, desarrolle los diferentes momentos de evaluación propuestos en el curso como son la autoevaluación, coevaluación y heteroevaluación. Se entiende por autoevaluación, el proceso autocritico, donde el estudiante determina si su conocimiento del tema es aceptable o si debe reiniciar el proceso. Coevaluación, proceso mediante el cual, el grupo de estudiantes que desarrolla actividades colaborativas en un tema, califica el desempeño de cada uno de sus compañeros. Por último, una vez el estudiante ha pasado los filtros necesarios para garantizar las competencias básicas del curso, se presenta ante los procesos de evaluación propuestos por el tutor.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Intensionalidades formativas Propósitos El curso pretende definir un marco de trabajo que facilite el desarrollo de conocimientos alrededor de los temas propuestos Reconocer la existencia de modelos de datos y sus implicaciones en los sistemas de información Determinar cuando se deben usar las estructuras de bases de datos definidas en el curso académico Objetivos
  

 

Reconocer las ventajas de las bases de datos en los procesos de análisis de información y como herramienta para la toma de decisiones. Entender el modelo de bases de datos distribuido, sus ventajas, desventajas y las posibilidades del modelo sobre la plataforma de alta velocidad de trasmisión. Conocer y aplicar los conceptos de bodegas de datos, como herramienta indispensable para almacenar información que facilite procesos de análisis y toma de decisiones Conocer las técnicas de minería de datos, sus aplicaciones y los resultados obtenidos. Reconocer los conceptos básicos de un sistema de base de datos orientado a objetos, el modelo de datos, sus ventajas, desventajas y aplicaciones.

Metas

Que el estudiante refuerce los conocimientos de bases de datos relacionales, el uso de SQL y tenga los conceptos básicos para administrar una base de datos Que el estudiante pueda aplicar los modelos de datos usados para los sistemas de bases de datos transaccionales, bodegas de datos y modelos de datos orientados a objeto Que el estudiante conozca que técnicas puede aplicar para minería de datos. Que el estudiante pueda plantear proyectos que requieran las tecnologías desarrolladas en el curso

 

Competencias Las competencias que promueve el curso y que son necesarias son: Cognitiva: Capacidad de apropiarse de los conocimientos planteados en el contenido del curso a través del desarrollo, monitoreo y aplicación de procesos de pensamiento.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Comunicativa: Capacidad de comprender, expresar mensajes y de desarrollar procesos argumentativos, apoyados por las relaciones interpersonales. Contextual: Capacidad de ubicar el conocimiento en el contexto científico, político, cultural, tecnológico, social y en el plano nacional e internacional, así como la disposición y capacidad para aplicarlo en procesos de transformación que inciden en la calidad de vida de la población. Valorativa: Capacidad de apropiarse de valores como el respeto a la vida y a las ideas de los demás; la dignidad humana, la convivencia, la solidaridad, la tolerancia y la libertad que orientan las acciones del individuo como persona, como ser social y como profesional. El curso busca que el estudiante reconoce las diferentes áreas de aplicación de las bases de datos, diseñando y construyendo soluciones eficientes que permiten apoyar los procesos de toma de decisiones en la empresa. Unidades didácticas Repaso Conceptos Bases de datos. Este tema incluye, Modelo Entidad Relación, normalización de datos y SQL. Unidad I. Bases de datos distribuidas, que son, modelo de datos Entidad Relación, fragmentación y replicación, transacciones, consultas y catalogo distribuido. Unidad II. Bodegas de datos, que son, modelo relacional, modelo copo de nieve. Carga de datos y minería de datos. Unidad III Bases de datos orientadas a objeto. Objetos, propiedades, diseño de objetos UML, SQL.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Estructura del curso

Contexto teórico El curso de bases de datos avanzada, se ha pensado como un curso electivo que quiere fortalecer los temas vistos en el curso básico. Se intenta mostrar el sustento teórico en los sistemas de bases de datos distribuidos, sistema que hoy retoma importancia por los desarrollos en los medios de comunicación que han reactivado ese tipo de proyectos. De otro lado, hoy en día los sistemas de bodegas de datos tienen un espacio claro en la empresa, para permitir, al revisar la historia, crear el concepto de fidelidad y conocimiento de los gustos del cliente para ofrecer mejores servicios. De otro lado, la idea de objetos y como los sistemas de bases de datos los utilizan, es importante por el auge que ha tomado este tipo de sistemas. Metodología Con el propósito de dar cumplimiento a las intencionalidades formativas del curso, es importante que se planifique de manera responsable el proceso de aprendizaje

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

teniendo en cuenta las características de la metodología de educación a distancia, por tal razón, este proceso se puede estructurar mediante las siguientes fases: Reconocimiento: Mediante esta etapa se pretende reconocer los conocimientos previos del estudiante, por lo tanto la función didáctica consiste en crear actividades mediante las cuales se identifican los propósitos del curso, sus intencionalidades y se presenta el desarrollo del curso. Esta fase puede desarrollarse de manera individual a través del estudio del protocolo del curso, el modulo y las fuentes documentales suministradas por el tutor y a través de actividades grupales desarrolladas por el tutor. Profundización: Teniendo en cuenta que esta se refiere al conjunto de actividades previamente planificadas conducentes al dominio de conceptos y competencias de ordenes diferentes, se han definido los siguientes propósitos de formación:

Trabajo personal: desarrolladas por el estudiante, a través de: estudio del material sugerido en el curso académico, consulta de fuentes documentales (bibliografía de documentos impresos en papel: libros y revistas; bibliografía de documentos situados en Internet; direcciones de sitios Web de información especializada y bibliotecas) Trabajo en grupo: desarrolladas por estudiantes a través de pequeños grupos colaborativos de carácter obligatorio, con el propósito de: socialización del trabajo personal, desarrollo de actividades en equipo, elaboración de informes, de acuerdo con las actividades programadas en la guía didáctica. Tutoría en grupo de curso: teniendo en cuenta las inquietudes presentadas por el estudiante a partir del trabajo personal y del trabajo en grupo, el tutor estará dispuesto a resolver las consultas mediante la valoración de informes y el intercambio de conocimientos en el tratamiento de las temáticas propuestas. Tutoría individual: entendida como el acompañamiento que el tutor debe ofrecer al estudiante mediante el uso de las tecnologías de información y la comunicación, tales como: correo electrónico, salas de conversación, foros de discusión, el teléfono y Chat; también se puede complementar con encuentros presenciales.

Transferencia: todo conocimiento, habilidad, destreza o competencias puede permitir la transferencia de situaciones conocidas a situaciones desconocidas; por lo tanto en esta fase requiere que tomando como referencia las fases de reconocimiento y profundización que se elaboren ensayos, evaluaciones, mapas conceptuales y talleres de aplicación en las diferente fases del curso académico. Sistema de evaluación Los procesos de evaluación del aprendizaje estarán correlacionados y articulados de manera necesaria al principio de autonomía y generaran en el estudiante competencias para la realización de procesos de auto evaluación, coevaluación y heteroevaluación. A continuación se indica cada uno de estos procesos:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Autoevaluación: Es aquella que realiza el mismo estudiante, donde a medida que va estudiando, se va planteando preguntas que el mismo las resuelve. De esta forma el estudiante hace su propio seguimiento, identificando avances y dificultades, lo que hace el proceso de autoaprendizaje muy dinámico y participativo. Este tipo de evaluación NO tiene ponderación en la valoración del curso, solo es una forma de identificar fortalezas, oportunidades, debilidades y amenazas en el proceso de aprendizaje. Coevaluación: Cuando el estudiante realiza estudio en grupo colaborativo, los compañeros pueden valorar los avances, por medio de la Coevaluación, en ésta los compañeros se evalúan entre sí, con el fin de identificar los avances y detectar debilidades y fortalezas en el desarrollo de los temas que se están estudiando. La Coevaluación es un espacio para desarrollar habilidades comunicativas y NO tiene ponderación en la valoración del curso. Heteroevaluación: Es aquella preparada por el Tutor o por el Docente Titular del Curso, para hacer el seguimiento al rendimiento académico de los estudiantes, se puede realizar por medio de parciales, quices, revisión de informes, trabajos, portafolios, evaluación nacional y otros. Este estilo de evaluación es la utilizada por la UNAD para determinar la aprobación o no del curso académico. El sistema de evaluación tendrá como referente las diversas fases de aprendizaje: Reconocimiento, Profundización y Transferencia, las cuales se valoraran de la siguiente forma: Fase de reconocimiento: diez por ciento (10%) Fase de profundización: treinta por ciento (30%) Fase de transferencia: veinte por ciento (20%) Examen nacional: cuarenta por ciento (40%).

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Introducción general al curso
“Un sistema de base de datos es básicamente un sistema computarizado para llevar registros”1 El modulo base de datos avanzada tiene como propósito fundamental profundizar algunos temas tratados en base de datos básica y presentar un esquema nuevo para un nivel más avanzado. Los temas aquí tratados requieren de un buen conocimiento de bases de datos y un gran deseo por profundizar cada uno de ellos en la bibliografía y cibergrafía recomendada. Los estudiantes deben trabajar el modulo acompañado de la guía de actividades y del protocolo académico para lograr así el propósito del curso académico.

1

C.J. DATE. Introducción a los sistemas de bases de datos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Unidad I. Bases de datos distribuidas
Capitulo 1. Conceptos básicos de bases de datos
Lección 1. Modelo entidad relación
Es una técnica para definir las necesidades de información de una organización. El modelo entidad relación en su forma más simple implica identificar asuntos importantes dentro de la organización (entidades) , propiedades de esos asuntos (atributos) y como se relacional entre si (relación). Esto tiene valor solamente dentro del contexto de lo que se realiza en la empresa y en la forma de actuar de estas funciones de gestión sobre el modelo de información. 1.1. Objetivos del modelo entidad relación Proporcionar un modelo preciso de las necesidades de información de la organización. Proporcionar un modelo independiente de cualquier almacenamiento de datos y método de acceso, que permita tomar decisiones de las técnicas de implementación y coexistencia con sistemas antiguos. 1.2. Importancia del modelo entidad relación Ofrece un medio efectivo y preciso de especificar y controlar la definición de las necesidades de información. A continuación se indican diez temas clave que se necesitan tener en cuenta cuando se utiliza el modelo:

Dato: un recurso clave

Hoy en día un dato, como recurso, se acepta por ser importante para la evolución satisfactoria de la organización como lo son los recursos financieros, humanos y físicos.

Compromiso con la dirección La dirección debe confirmar los requisitos de información. No importa lo inteligente que usted resulte al modelar, tendrá un éxito limitado sin el compromiso de la dirección.

Convenciones En todo momento se deben aplicar convenciones rigurosas, estándares y directrices, incluyendo los conceptos de normalización de datos.

Definición mínima

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Se debería definir o modelar cualquier información o concepto de datos sólo de una forma, y a continuación configurar asociaciones para los objetos relacionados. Como por ejemplo, se debería definir una vez una cosa denominada “Pedido de compra” y a continuación relacionarlo con el departamento, los productos, las funciones de autorización y así sucesivamente, como se requiera.

Independencia de los datos Se deben definir los requisitos de información de forma que sean independientes de cualquier almacenamiento final o método de acceso y que nos permita tener una visión creativa y objetiva de la empresa y del diseño subsiguiente.

Patrones genéricos Deberían buscarse patrones genéricos de datos para permitir a los usuarios utilizarlos en su gestión, además de tener la oportunidad de perfeccionar la forma de procesar sus datos y de sugerir estructuras más rentables y flexibles para los diseñadores de bases de datos.

Actitud y calidad Los modelizadores deben comenzar aplicar las convenciones automáticas y velozmente, pero sin sacrificar el rigor. También debe aprovechar cualquier oportunidad con los usuarios para mejorar la precisión de los modelos.

Comunicación Debe haber comunicación con los usuarios finales, en términos que ellos puedan entender aunque debe seguir siendo técnicamente riguroso. Estas técnicas de modelización se han utilizado durante muchos años para ayudar a altos ejecutivos, directores y a otros a comprender su gestión. Es esencial utilizar un lenguaje claro, sin abreviaturas, para lograr su comprensión. Con un usuario final no deberíamos utilizar la palabra entidad.

Relevancia Los requisitos de información solamente pueden tener valor si aportan las necesidades funcionales de la organización, dentro del marco de trabajo de los objetivos y propósitos de la empresa.

Un medio, no un fin

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Aunque el modelo entidad relación es muy potente, ofrecer una idea increíble de la compañía y actuar como un marco de trabajo para el diseño de los datos, solo es una técnica intermedia, aunque desde luego importante. Autoevaluación Una de las ventajas del modelo Entidad Relación es: Es un modelo de datos estándar que organiza la información del sistema. Es un modelo de datos que indica como se almancena la información en los discos Es un modelo de datos donde cada persona define su estandar para identificar los elementos del modelo Es un modelo que se implementa directamente en el computador

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 2. Elementos del Modelo entidad relación
El modelo entidad relación para ser funcional requiere de la definición de unos elementos, los cuales se precisan a continuación: Entidad Se define como entidad a cualquier objeto real o abstracto, que existe en un contexto determinado o puede llegar a existir y del cual deseamos guardar información. Representación de entidad: Una entidad se representa en forma de diagrama con un recuadro y en su interior un nombre. El nombre se muestra en singular y con letras mayúsculas (figura 1).

Figura1. Representación de entidad Reglas para definir una entidad: Cualquier objeto sólo puede ser representado por una entidad. Es decir las entidades son mutuamente exclusivas en todos los casos. Cada entidad debe ser identificada en forma única. Es decir, cada instancia (aparición) de una entidad debe encontrarse separada e identificable claramente de todas las demás instancias de ese tipo de entidad. Relación Se entiende por relación a la asociación, vinculación o correspondencia entre entidades. Por ejemplo entre la entidad PROFESOR y la entidad CURSO podemos establecer la relación IMPARTE porque el profesor imparte cursos. Una relación es binaria en el sentido de que es siempre una asociación entre exactamente dos entidades, o entre una entidad y ella misma. Cada relación tiene dos extremos, para cada uno de los cuales tiene un:
  

Nombre Grado / cardinalidad (cuantos) Opcionalidad (opcional u obligatorio).

Estas propiedades se utilizan para describir la asociación desde un extremo; se deben definir ambos extremos.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Representación de una relación: Una relación se representa mediante una línea que une dos recuadros de entidades, o recursivamente (recurrentemente) une un recuadro de entidad consigo mismo. La relación es una función que indica por cada elemento de la relación A cuantos elementos dependen en la relación B. Los valores se dividen en dos (2) y se conocen como cardinalidad de la relación (Figura 2). El primer valor, denominado cardinalidad mínima, indica el menor número de elementos en esa relación; generalmente ese valor puede ser 0 ó 1. Si el valor es 0, se dice que la relación es opcional y la gráfica de la relación se presenta con un circulo en la terminación de la relación ó se hace con una línea punteada. Si el valor es 1, se dice que la relación es obligatoria, la cual se presenta en la terminación de la relación mediante una línea perpendicular o mediante una línea continua. El segundo valor de la cardinalidad, cardinalidad máxima, indica la cantidad máxima de registros de la relación B por cada valor de la relación A; generalmente son valores 1, o muchos (2, 3, ....n). La representación se realiza con la terminación conocida como "pata de gallina", que es, la terminación con 3 líneas.

Figura 2. Representación de una relación Es útil pensar acerca de una relación de uno a muchos como una relación padre a hijo, con la existencia del hijo encontrándose en una forma dependiente de su padre. Relación recursiva Es una relación que se llama así misma, a continuación se muestra una relación recursiva, por ejemplo, jefe y empleado.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 3. Relación recursiva Nombre de las relaciones: El nombre de cada extremo de una relación se sitúa cerca al extremo apropiado en minúsculas como se muestra a continuación.

Figura 4. Nombre relaciones Cuando la terminación de la relación es obligatoria, la frase “debe ser” se utiliza para preceder al nombre final de la relación; para los nombres finales opcionales de la relación se utiliza la frase “puede ser”

Figura 5. Ejemplo nombre relaciones

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Cada ENTIDAD-A debe ser el nombre-extremo-1 una y solo una ENTIDAD-B, y de derecha a izquierda: Cada ENTIDAD-B puede ser el nombre-extremo-2 y una o más ENTIDADes-A. Para la figura 5, la lectura de esa representación sería: Cada TIQUETE debe ser para uno y sólo un PASAJERO y, cada PASAJERO se puede observar en uno o más TIQUETES. Atributos Las entidades se componen de atributos que son cada una de las propiedades o características que tienen las entidades. Cada ejemplar de una misma entidad posee los mismos atributos, tanto en nombre como en número, diferenciándose cada uno de los ejemplares por los valores que toman dichos atributos. Ejemplo si consideramos la entidad PROFESOR y definimos los atributos Nombre, Teléfono, Salario; podríamos obtener lo siguiente: Juan Pérez Rodríguez, 4253250, 800.000 Martha López Jiménez, 8553260, 600.000 Representación de los atributos Para representar un atributo hay que escribir su nombre en singular y en minúscula, y de forma opcional con un ejemplo de su valor.

Figura 6. Incorporando atributos En el ejemplo siguiente, los atributos candidatos son esenciales para ayudar a distinguir entre dos entidades.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 7. Atributos candidatos En la gráfica, por cada tiquete debe tenerse un código y una fecha expedición. Para ese modelo, un pasajero tiene su identificación y el nombre del pasajero Características del atributo Las siguientes normas simples ayudan a crear un modelo preciso, completo y flexible. Un atributo describe una entidad El atributo debe describir la entidad en contra de lo que se muestra. Esto puede ser obvio, pero es el error más común que se encuentra en los atributos. Por ejemplo. ¿El "número de asiento" es un atributo de un cupón, billete, tarjeta de embarque, avión o asiento de un avión? Obviamente es un atributo de ASIENTO, pero en la vida real el número a menudo se ve duplicado muchas veces; por ejemplo, en una tarjeta de embarque, que se muestra como una entidad en la Figura 8. ¿Por qué? En el mundo real, un número de asiento es una forma muy conveniente de representar una relación. Por el contrario, cuando se encuentran estas situaciones hay que dibujar la línea de relación (si es necesario , crear la entidad a la que se refiere), como se muestra a continuación. Para que sirva de guía la mayoría de las entidades sólo se describirán manejando entre dos y ocho atributos. Si se tienen más, probablemente existirán muchas relaciones y/o entidades perdidas.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 8. Asignar un atributo a la entidad correcta Leer nombres de atributos No hay que utilizar el nombre de la entidad como parte del nombre del atributo. Sería redundante, ya que el atributo sólo describe la entidad. En el ejemplo anterior, el “el número asiento” realmente ayudó a identificar una entidad perdida llamada ASIENTO que se podría describir con el atributo ’número’ y quizás con otros atributos como ‘tipo’. Para leer atributos que se nombren de esta manera, se pueden utilizar de una de las dos formas:

Por ejemplo, asiento número o número de asiento. Eliminar atributos repetidos (primera forma normal) Una entidad que sólo tenga un valor para un atributo en cualquier momento. Si son esenciales muchos valores, se debe crear una entidad nueva para mantenerlos en la relación muchos a uno unidos con la entidad original.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 9. Un atributo repetido indica una entidad perdida. Siguiendo la norma anterior se obtiene:

Figura 10. Añadir la entidad perdida Esta es una norma o regla que se llama normalmente ’Primera forma normal’ Nombre en singular El nombre de un atributo debe ir en singular. Los nombres plurales generalmente reflejan el problema de los atributos repetidos que se ha mostrado anteriormente. ¿Es una entidad? Un atributo se convierte en una entidad cuando tiene importancia por sí misma, con sus propias relaciones y atributos. Identificador único Cada entidad debe ser identificable únicamente por una combinación de atributo y/o relación. De esta forma se podría buscar siempre cualquier atributo candidato que ayude a identificar una entidad. El valor del atributo debe ser dependiente de todo el identificador único. (segunda forma normal)

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Hay que quitar los atributos por los que los valores son dependientes sólo de parte del identificador único. Esto se conoce como ’Segunda forma normal’ . Dichos atributos normalmente suponen una entidad perdida, pero relacionada. Los atributos deben ser dependientes directamente del identificador único (tercera forma normal) Hay que quitar los atributos que no sean dependientes directamente del identificador único de la entidad. Esto se conoce como ‘Tercera forma normal’. En el subtema tres se profundizara el concepto de normalización. Identificador único Definición Cada entidad debe ser únicamente identificable de forma que cada instancia de la entidad esté separada y sea claramente identificable de todas las otras instancias de ese tipo de entidad. El identificador único puede ser un atributo, una combinación de relaciones o una combinación de atributos y relaciones. Una entidad puede tener más de un medio alternativo de identificación única. El método primario se puede mostrar en el diagrama entidad-relación antecediendo a un atributo que forme el identificador con una marca ‘#’ , y colocando una barra cruzada en el caso de una (s) línea (s) de relación. Figura 11

Figura 11. Muestra de identificadores únicos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Así, pues, para identificar únicamente una tarjeta de embarque se necesita:

embarque se hayan reemitido; para volver a sentar a una familia junta después de que alguien no haya aparecido en el vuelo ruta de la línea aérea, se necesita el número de vuelo.

Figura 12. Refinamiento de Entidades Norma de Diseño Las normas simples del diseño que siguen a continuación se han definido para que el diagrama sea fácil de leer, aplicable para personas que necesiten trabajar con ellas y para maximizar la calidad y la precisión. Diagrama de Subconjunto Cuando se trata un área funcional en particular con un usuario o un diseño con los diseñadores, es bueno crear un diagrama de subconjunto y expresar las ideas de nuevo más eficazmente como un vehículo de comunicación con ese propósito. Durante el proceso se van a encontrar omisiones y errores, que se pueden corregir rápidamente la perspectiva diferente es una potente herramienta analítica. Esmerado y pulcro Hay que organizar el diagrama de forma que los recuadros de las entidades estén alineados y que las líneas de las relaciones sean rectas en sentido horizontal o vertical. Hay que dibujar el menor número de líneas cruzadas posible. Hay que evitar Construir un diagrama que tenga demasiadas líneas paralelas que estén muy juntas. Hay que utilizar el mayor espacio en blanco que se pueda para evitar el sentimiento de congestión y utilice de vez en cuando la línea en diagonal para ayudar a la estética del diagrama.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Reconocimiento de patrones La mayoría de las personas tienen la capacidad incorporada de reconocer formas y patrones en un instante y por tanto pueden recordar fácilmente el tema. Los modelizadores pueden beneficiarse de esto haciendo que cada diagrama sea claramente diferente en forma. Texto Hay que asegurarse de que el texto no sea ambiguo. Hay que evitar las abreviaturas y las jergas. Hay que utilizar las convenciones de lectura descritas anteriormente y leer todo el diagrama para asegurarse de que es completo y preciso. Un buen diagrama entidad relación debería ser semánticamente completo. Para mejorar la comprensión y la precisión al leerlo, hay que añadir adjetivos y ejemplos cuando sea necesario.

Figura 13. Reconocimiento de patrones Grado de relación Hay que situar la terminación de muchas (ramificaciones) de las relaciones a la izquierda o en la parte superior de la línea de relación. Se ha probado que esta técnica ha incrementado la precisión del modelo formando la consideración de las relaciones, desde las entidades que aparecen con más frecuencia a las menos frecuentes. Autoevaluación Una relación reflexiva es Relación entre la entidad A y ella misma Relación entre la entidad A y la entidad B Relación entre la entidad A y sus atributos Relación entre los atributos de la entidad A y la llave principal

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 3. Álgebra relacional
Es necesario que el lector se familiarice con el término “relación”, entendida en dos aspectos, en primer lugar cuando mencionamos esta palabra en el modelo entidad relación se hace referencia a la asociación entre dos o más entidades, y, al hablar de “relación” en el álgebra relacional se está haciendo referencia a tablas, puesto que las tablas son esencialmente relaciones. El Álgebra relacional es un lenguaje de consulta procedural. Consta de un conjunto de operaciones que toman como entrada una o dos relaciones y producen como resultado una nueva relación, por lo tanto, es posible anidar y combinar operadores. Hay ocho operadores en el álgebra relacional que construyen relaciones y manipulan datos, estos son: 1. Selección 4. Unión 7. Join 2. Proyección 5. Intersección 8. División Tabla 1 - Operadores del Álgebra relacional Las operaciones de proyección, producto, unión, diferencia, y selección son llamadas primitivas, puesto que las otras tres se pueden definir en términos de estas. Se hace necesario en este punto incluir un modelo de datos de ejemplo en el cual trabajar para generar ejemplos de comandos y operadores. Para este efecto se incluye un modelo básico de administración de Radio taxis. El Gráfico que se presenta a continuación representa el Modelo conceptual (Modelo Lógico) o Diagrama de EntidadRelación, (este adopta una metodología similar a la anterior): 3. Producto 6. Diferencia

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 14 - Esquema de Relaciones de Ejemplo Los Esquemas de relaciones que se pueden construir a partir de este modelo son los siguientes: Dueño = {rut, nombre, teléfono, dirección, vigencia} Chofer = {rut, nombre, teléfono, dirección, fecha_licencia_desde, fecha_licencia_hasta, vigencia} Vale = {correlativo, hora_desde, hora_hasta, metraje_total, tarifa_total} Móvil = {patente, rut_dueño, rut_chofer, marca, modelo, año} Viaje = {correlativo_vale, patente_movil, Hora_Desde, hora_hasta, origen, destino, tarifa, metraje}

1. Selección
El operador de selección opta por tuplas que satisfagan cierto predicado, se utiliza la letra griega sigma minúscula (σ) para señalar la selección. El predicado aparece como subíndice de σ. La Relación que constituye el argumento se da entre paréntesis después de la σ. Ejemplos :

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

2. Proyección La operación de proyección permite quitar ciertos atributos de la relación, esta operación es unaria, copiando su relación base dada como argumento y quitando ciertas columnas, La proyección se señala con la letra griega pi mayúscula (Π). Como subíndice de Π se coloca una lista de todos los atributos que se desea aparezcan en el resultado. La relación argumento se escribe después de Π entre paréntesis. Ejemplos :

3. Producto.
En álgebra relacional el producto de dos relaciones A y B es: A Veces B o A X B Produce el conjunto de todas las Tuplas t tales que t es el encadenamiento de una tupla a perteneciente a A y de una b que pertenece a B. se utiliza el símbolo X para representar el producto. Ejemplos: Dueño x Móvil 4. Unión.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

En álgebra relacional la unión de dos relaciones compatibles2 A y B es: A UNION B o A U B Produce el conjunto de todas las tuplas que pertenecen ya sea a A o a B o a Ambas. Al igual que en teoría de conjuntos el símbolo U representa aquí la unión de dos relaciones. Ejemplo :

Devuelve todos los Dueños y los Chóferes.

5. Intersección.
En álgebra relacional la intersección de dos relaciones compatibles A y B

A INTERSECCION B o A ∩ B Produce el conjunto de todas las tuplas pertenecientes a A y B. Al igual que en teoría de conjuntos el símbolo ∩ representa aquí la intersección entre dos relaciones. Ejemplo:
(Dueño) (Chofer)

Devuelve todos los dueños que también son chóferes

6. Diferencia
En álgebra relacional la diferencia entre dos relaciones compatibles A y B A MENOS B o A – B Produce el conjunto de todas las tuplas t que pertenecen a A y no pertenecen a B.
2

Relaciones Compatibles: En el álgebra relacional la compatibilidad se aplica a las operaciones de Unión, Intersección y Diferencia. Cada operación requiere dos relaciones que deben ser compatibles, esto significa que deben ser del mismo grado, n, y el i-ésimo atributo de cada una (i= 1, 2...n) se debe basar en el mismo dominio.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Ejemplo:

Devuelve todos los dueños que NO son chóferes 7. Join o Reunión. En álgebra relacional el JOIN entre el atributo X de la relación A con el atributo Y de la relación B produce el conjunto de todas las tuplas t tal que t es el encadenamiento de una tupla a perteneciente a A y una tupla b perteneciente a B que cumplen con el predicado “A.X comp B.Y es verdadero” (siendo comp un operador relacional y los atributos A.X y B.Y pertenecientes al mismo dominio). Si el operador relacional “comp” es “=” entonces el conjunto resultante es un EQUI-JOIN. Si se quita uno de éstos (usando una proyección) entonces el resultado es un JOIN-NATURAL.

Ejemplo :

8. División En álgebra relacional el operador de división divide la relación A con grado m + n por la relación B entregando como resultado una relación con grado m. El atributo m + i de A y el atributo i de B deben estar definidos dentro del mismo dominio. Así el resultado de A DIVIDIDO POR B o A / B produce la relación C con un sólo atributo X, tal que cada valor de x de C.X aparece como un valor de A.X, y el par de valores (x, y) aparece en A para todos los valores y que aparecen en B. Ejemplo:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Selecciona todos los autos a cuyos chóferes les caduca la licencia el 01/01/1999 Nota del autor: los resultados de cada uno de los ejemplos citados en este tema están al final del modulo como un anexo. Autoevaluación Los operadores Selección y Proyección son conocidos como operadores Unarios porque Son operadores unarios porque se aplican sobre una tabla o relación Son operadores unarios porque se aplican a un conjunto de tuplas Son operadores unarios porque se aplican a los índices Son operadores unarios porque se aplican a un tablespace

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 4. Normalización de datos
La normalización de datos es un procedimiento que asegura que un modelo de datos se ajusta a algunos estándares útiles. Para los datos y los modelos entidad-relación, estos estándares se han definido para minimizar la duplicación de datos, proporcionar la flexibilidad necesaria para soportar requisitos funcionales y para permitir que el modelo se estructure sobre una amplia variedad de diseños alternativos de base de datos. Modelo entidad – relación El modelo entidad-relación tiende a producir entidades que están normalizadas de forma natural. Esto debido a que se sigue un proceso simple, como el siguiente:

información. Estas entidades deben ser mutuamente exclusivas, y se representan en un diagrama por medio de un recuadro con el nombre de la entidad en singular y en mayúsculas. ñadir las relaciones de gestión, las cuales se han nombrado como asociaciones significativas entre entidades. Estas relaciones se muestran como una línea entre dos recuadros; cada terminación tiene un grado (un triángulo o ramificación que significa muchos; si no hay triángulo significa uno) y la opcionalidad (una línea de puntos significa opcional, una línea continua significa obligatorio).

conocer. Estos atributos se muestran dentro de la entidad como nombres en minúsculas.

ser identificada de forma única. Esto se hará mediante alguna combinación de atributos y/o relaciones. Cuando un atributo es parte del identificador único se muestra con una marca #. Cuando una relación es parte del identificador único se muestra mediante una barra cruzada cruzando la línea de relación. El seguimiento del proceso anterior dará rigurosa y automáticamente un modelo normalizado, pero depende de la buena comprensión del analista acerca de lo que es realmente un atributo, una relación y una entidad.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Normalización Para comprobar que un modelo entidad-relación tiene todas sus entidades unívocamente identificadas, se ha normalizado completamente y por tanto se ajusta a la tercera forma normal; se pueden aplicar las siguientes comprobaciones simples: Asegurar que todas las entidades son identificables de forma única Por una combinación de atributos y / o relaciones Primera forma normal: [1NF] Eliminar los atributos repetidos o grupos de atributos. Si existe más de un valor a la vez para un atributo o para más de uno con el mismo nombre, se define una entidad nueva, la cual se describe mediante ese atributo. El identificador único de esta nueva entidad consta de uno de los atributos que se fueron con ella y la relación (de muchos a uno) se lleva a la entidad original.

Figura 15 Primera forma normal

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Segunda forma normal: [2NF] Eliminar atributos dependientes sólo en parte del identificador único. Si una entidad tiene un identificador único compuesto de más de un atributo y/o relación, y si otro atributo depende sólo de parte de este identificador compuesto, entonces el atributo, y la parte del identificador del que depende, deberán formar la base de una nueva entidad. La entidad nueva se identifica por la parte emigrada del identificador único de la entidad original, y tiene una relación de uno a muchos unido a la entidad original. Tercera forma normal: [3NF] Eliminar los atributos dependientes de atributos que no son parte del identificador único. Si un atributo de una entidad es dependiente de otro atributo, que no es parte del identificador único, entonces estos atributos deberían formar la base de la nueva entidad, que tenga una relación de uno a muchos con la entidad original. El identificador único de la entidad nueva es el atributo del que depende el otro atributo. A continuación se presenta la representación de esta forma:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 16. Segunda y tercera forma normal En general, “una relación R está en la tercera forma normal (3NF) si y sólo si en cualquier momento cada tupla (línea relacional) de R se compone de un valor clave primario que identifica alguna identidad, junto con un grupo de cero o más valores independientes mutuamente que describen esa entidad de alguna manera”3 Además, “una relación R está en la cuarta forma normal (4NF) si y únicamente si donde quiera que haya una dependencia multivalores (MVD) en R, digamos A todos los atributos de R son también funcionalmente dependientes de A. En otras palabras, las únicas dependencias (funcionales o multivalores) en R son de la forma K multivalores) son de verdad dependencias funcionales (FD).
3

Date, C.J. An Introduction to Database System, 4ed. 1986. Adisson-Wesley Publishing Co

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

También, “una relación R está en quinta forma normal (5NF), también denominada forma normal de unión de protección (PJ/PN), si y únicamente si cada dependencia de unión en R es una consecuencia de las claves candidatas de R.” Desnormalización de datos La desnormalización de datos es el procedimiento inverso, llevado a cabo puramente por razones de mejorar la realización de sistemas de producción, particularmente cuando están computarizados. La desnormalización sólo se debe realizar sobre el diseño. No poner en peligro nunca el modelo de gestión. La desnormalización en formas manuales de procedimientos es necesariamente muy común, como queda evidenciado por el hecho de que la mayor parte de los formularios en papel mantienen grandes datos de referencias. Todos conocemos los problemas que se pueden originar cuando ese dato se cambia y se tiene que volver a emitir el grupo entero de formularios. Autoevaluación Una Base de datos que no esté en 3FN Tiene problemas a nivel de inserción y borrado de datos Tiene problemas al generar el backup Tiene problemas a nivel de generación de roles Tiene problemas de identidad

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 5. Transacciones
Una transacción es una unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos. Se delimita dependiendo del lenguaje por las sentencias inicio transacción y fin transacción y se compone de todas las instrucciones que se encuentran entre estos dos delimitadores. Propiedades de la transacción Para asegurar la consistencia de los datos se necesita que el sistema de base de datos tengan las propiedades llamadas ACID: (Atomicity, Consistency, Isolation, Durability Atomicidad, Consistencia, Aislamiento, Durabilidad [Silberschatz97]). A continuación explicamos cada una de estas propiedades:

Asegura que o bien todos los efectos de la transacción se reflejan en la base de datos, o bien ninguno de ellos; un fallo no puede dejar a la base de datos en un estado en el cual una transacción se haya ejecutado parcialmente. ia: Asegura que si la base de datos es consistente inicialmente, la ejecución de la transacción deja la base de datos en un estado consistente.

Asegura que en la ejecución concurrente de transacciones, estas están aisladas unas de otras, de tal manera que cada una tiene la impresión de que ninguna otra transacción se ejecuta concurrentemente con ella.

Asegura que una vez que la transacción se ha comprometido, las actualizaciones hechas por la transacción no se pierden, incluso si hay un fallo en el sistema. Una transacción que termina con éxito se dice que está comprometida (commited), una transacción que haya sido comprometida llevará a la base de datos a un nuevo estado consistente que debe permanecer incluso si hay un fallo en el sistema. En cualquier momento una transacción sólo puede estar en uno de los siguientes estados:

ejecución.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

transacción. cución normal.

base de datos a su estado anterior al comienzo de la transacción.

Cuando varias transacciones se ejecutan concurrentemente, existe la posibilidad de que se pierda la consistencia de datos. Se hace necesario por lo tanto un sistema que controle la interacción entre las transacciones concurrentes. Puesto que una transacción por definición conserva la consistencia, una ejecución lineal de transacciones la garantiza también. Un sistema que asegure esta propiedad se dice que asegura la secuencialidad.

Concurrencia
Existen varios esquemas de control de concurrencia que aseguran la secuencialidad, todos estos esquemas o bien retrasan una operación o bien abortan la transacción que ha realizado la operación. Los más conocidos son los protocolos de bloqueo, el esquema de ordenación por marcas temporales, las técnicas de validación, el esquema de granularidad múltiple y los esquemas multiversión. Un protocolo de bloqueo es un conjunto de reglas que indican el momento en que una transacción puede bloquear o desbloquear un objeto de la base de datos. El protocolo de bloqueo de dos fases permite que una transacción bloquee un objeto sólo después de que haya desbloqueado otro objeto distinto, este método asegura la secuencialidad. El esquema de ordenación por marcas temporales asegura la secuencialidad seleccionando previamente un orden en todo par de transacciones. Existen 2 formas de implementar este esquema, uno es por medio de valores timestamp (dependientes del reloj del sistema) y por medio de un contador lógico que se incrementa cada vez que asigna una nueva marca temporal. Este protocolo asegura la secuencialidad en cuanto a conflictos y la ausencia de interbloqueos, si una de las transacciones viola la norma la transacción se retrasa y se le asigna una nueva marca temporal. Por ejemplo, una operación leer se puede retrasar porque todavía no se ha escrito el valor apropiado o incluso rechazar si ha sobrescrito el valor que supuestamente se iba a leer. Un esquema de validación es un método de control de concurrencia adecuado para transacciones de sólo lectura y en las cuales la tasa de conflictos es baja. Se basa en dividir una transacción en 3 etapas (lectura, validación y escritura) y trabajar con el

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

esquema de marcas temporales sobre la etapa de validación. De esta manera se quita una sobrecarga en la etapa de lectura, en la cual no se necesita un esquema de control de concurrencia dado que toda lectura lleva a la base de datos al mismo estado de consistencia. Una manera distinta manejar la concurrencia es por medio de la granularidad, este concepto permite agrupar varios elementos de datos y definirlos como un todo para efectos de sincronización. Se define como una jerarquía de distintos niveles, donde el nivel superior puede representar toda la base de datos, se esquematiza como estructura de árbol donde los nodos hijos de un nodo interno representan las dependencias de datos asociadas. Se utilizan los tipos de bloqueos Compartidos y Exclusivos más un nuevo tipo de bloqueo llamado el bloqueo intencional, el cual indica que existen nodos descendientes que tienen bloqueos compartidos o exclusivos. El esquema multiversión se basa en la creación de nuevas versiones de los elementos de datos cada vez que una transacción vaya a escribir dicho elemento. Cuando se va a realizar una escritura el sistema elige una de las versiones para que se lea. El esquema de control de versiones garantiza que la versión que se va a leer se elige de forma que asegure la secuencialidad por medio de marcas temporales. En este esquema una operación de lectura tiene éxito siempre, sin embargo, una operación de escritura puede provocar el retroceso de una transacción. Un sistema está en estado de interbloqueo si existe un conjunto de transacciones tal que toda transacción del conjunto está esperando a otra transacción del conjunto. En tal situación, ninguna de las transacciones puede progresar. Existen 2 métodos para tratar los interbloqueos y ambos provocan un retroceso de las transacciones, la diferencia radica en que uno es preventivo y otro curativo. El protocolo de prevención de interbloqueos asegura que el sistema nunca llegará a un estado de interbloqueos mientras que el método de detección y de interbloqueos permite que el sistema llegue a un estado de interbloqueos para luego tratar de recuperarse. La prevención se usa normalmente cuando la probabilidad de que el sistema llegue a un estado de interbloqueo es relativamente alta, de lo contrario lo más conveniente es usar la detección y recuperación.

Seguridad y recuperación de datos
Los fallos que ocurren en un computador pueden darse por diferentes motivos (fallos de disco, cortes de energía o fallos en el software). En cada uno de estos casos puede perderse información concerniente a la base de datos. Existen varios tipos de fallas, a considerar:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

sistema. Un error lógico ocurre cuando una transacción no puede continuar con su ejecución normal a causa de una condición interna como lo es un desbordamiento o un exceso de recursos. Un error del sistema ocurre cuando el sistema se encuentra en un estado no deseado como en el caso de los interbloqueos.

software de base de datos. Comúnmente causa la pérdida del contenido de la memoria primaria y aborta el procesamiento de una transacción. ólo sirve la recuperación por medio de copias existentes en medios de almacenamiento secundario como cintas magnéticas. La forma más aceptada de lograr un tipo de almacenamiento lo más estable posible es replicando la información en varios medios de almacenamiento no volátil, con modos de fallos independientes. Los sistemas RAID (disposición redundante de discos independientes) garantizan que el fallo de un sólo disco no conduzca a la perdida de datos. Sin embargo los sistemas RAID, no pueden proteger al sistema de una pérdida de datos en el caso de una catástrofe geográfica, para tales efectos muchos sistemas de almacenamiento guardan copias de seguridad en cintas en otros lugares, no obstante, como las cintas no pueden ser trasladadas continuamente, los últimos cambios realizados luego del traslado de cintas no se pueden volver a recuperar en el caso de tales desastres. Los sistemas más seguros guardan copias de cada bloque de almacenamiento en otra disposición geográfica, datos que se transmiten por medios de redes de computadores al sistema de respaldo remoto... El estado de un sistema de base de datos puede no volver a ser consistente en caso de que ocurran fallos, para preservar la consistencia es necesario que cada transacción sea atómica. Garantizar la propiedad de atomicidad es responsabilidad del esquema de recuperación. Existen básicamente 2 esquemas que garantizan la atomicidad. Basados en el registro histórico. Todas las modificaciones se graban en el registro histórico, el cual debe estar guardado en almacenamiento estable. En el esquema de modificación diferida, durante la ejecución de una transacción, se difieren todas las operaciones de escritura hasta que la transacción se compromete parcialmente, momento en el cual se utiliza la información del registro histórico asociado con la transacción para ejecutar las escrituras diferidas. Con la técnica de modificación inmediata todas las modificaciones se aplican directamente en la base de datos. Si ocurre una caída se utiliza la información del registro histórico para llevar a la base de datos a un estado estable previo.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Paginación en la sombra. Durante la vida de una transacción se mantienen 2 tablas de páginas: la tabla actual de páginas y la tabla de páginas sombra. Ambas tablas son idénticas al principio de la transacción, sin embargo, la tabla actual de páginas puede ir cambiando luego de cada operación escribir. Todas las operaciones de lectura y escritura utilizan la tabla de páginas actual, cuando una transacción se compromete parcialmente se desecha la tabla de páginas sombra y la tabla actual se convierte en la nueva tabla de páginas. Si la transacción fracasa, simplemente se desecha la tabla actual de páginas. El procesamiento de transacciones se basa en un modelo de almacenamiento en el cual la memoria principal contiene una memoria intermedia para el registro histórico, una memoria intermedia para la base de datos y una memoria intermedia para el sistema. Una implementación eficiente de un esquema de recuperación de datos requiere que sea mínimo el número de escrituras de la base de datos y que sea realizado en almacenamiento estable. Los registros del registro histórico pueden guardarse inicialmente en la memoria intermedia del registro histórico pero deben ser llevados a almacenamiento estable bajo dos situaciones:

que referencien a la transacción Ti antes de grabar el registro que indique que la transacción Ti ha sido comprometida os los registros del registro histórico pertenecientes a los datos de un bloque antes de que ese bloque de datos se escriba desde la memoria intermedia a la base de datos. Consultas El Procesamiento de consultas hace referencia a la serie de actividades a seguir para llevar a cabo la recuperación de datos desde una base de datos. Estas actividades incluyen la traducción de consultas en lenguajes de consultas de alto nivel (Ej: SQL) a expresiones que se puedan implementar en un nivel físico, así como también los algoritmos de evaluación y optimización de consultas. Recuperación Una de las ventajas principales del modelo relacional presentado por Codd en 1970 es la que tiene relación con la independencia de los datos que se entiende aquí como la separación entre el modelo (lógico) y la implementación (física). Esta separación nos permite desarrollar una poderosa semántica lógica independiente de una implementación física particular.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Uno de los desafíos de la independencia de datos es que la codificación de una consulta para la base de datos se componga de 2 fases: 1. La descripción lógica de la consulta (que se supone que debe hacer). 2. La definición del plan de ejecución físico (el que muestra como implementar la consulta). Antes de empezar el procesamiento de la consulta el sistema debe traducir la consulta a un medio de representación interno con el cual le sea fácil operar. Así, por ejemplo para SQL la representación más útil es la del álgebra relacional extendida (árbol relacional). Este proceso cumple la misma función que el analizador léxico y sintáctico de un compilador, es decir, revisa la sintaxis de la consulta y chequea que todos lo identificadores sean nombres de objetos de la base de datos, en el caso de las vistas reemplaza el nombre de la vista por la expresión relacional que la representa. El plan de ejecución es un árbol relacional armado a partir de la consulta y que sólo puede ser entendido por el motor de ejecución de consultas. La transformación de la consulta a un plan puede ser hecha efectivamente a mano y en algunos casos de consultas simples que se ejecutan miles de veces esta podría ser la mejor estrategia, sin embargo, una de las ventajas que nos ofrece el modelo relacional es la capacidad de usar la información del catalogo de la base de datos, que como se verá más adelante, podrá responder una gran cantidad de preguntas distintas. Por otro lado, aunque una consulta simple pueda ser ejecutada miles de veces, no existe un camino mecánico que garantice que el plan de ejecución elegido satisfaga la consulta que se quiere implementar, puesto que: 1. Un Plan calculado a mano (o un plan precalculado) será invalidado por cambios lógicos dentro del esquema o por cambios físicos en el camino de acceso a la información o en el almacenamiento físico. 2. Si los parámetros de la consulta (o los datos) cambian, la relación optima que asocia a un plan con una consulta por sobre otros puede cambiar. La siguiente figura nos muestra los pasos en el procesamiento de una consulta.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 17 - Pasos en el procesamiento de una consulta SQL Después de enviar la consulta, la base de datos debe producir su correspondiente plan de ejecución. El primer paso en este proceso es traducir la consulta desde SQL a un árbol lógico en álgebra relacional, proceso comúnmente llamado parser. El Próximo paso es traducir el árbol de la consulta en el plan de ejecución. Generalmente existe un gran número de planes que implementan al árbol de la consulta; el proceso de encontrar el mejor de estos planes se le denomina optimización de consultas. Cálculo relacional La manipulación del modelo relacional esta basada en el álgebra relacional; sin embargo, de igual forma podemos indicar que también esta basada en el cálculo relacional. Álgebra y cálculo son alternativos entre sí, la diferencia entre ellos es la siguiente: mientras que el álgebra proporciona un conjunto de operadores explícitos (juntar, unir, proyectar, etc), que pueden usarse para indicar al sistema cómo construir cierta relación dada, al cálculo simplemente proporciona una notación para establecer la definición de esa relación deseada en términos de dichas relaciones dadas4 El cálculo relacional de tuplas describe la información deseada sin dar un procedimiento específico para obtenerla. Las consultas en el cálculo relacional de tuplas se expresan como:
4

C.J Date, Introducción a los Sistemas de Bases de Datos, Prentice Hall

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

{ t | P(t)}, Es decir, son el conjunto de tuplas t tales que se cumple el predicado P para cada t. Siguiendo la misma notación, se utiliza t[A] para el valor de la tupla t en el atributo A.

Si sólo se desea obtener un atributo de la tupla, se utiliza el constructor “Existe” de la lógica matemática. Así, si lo que se desea es el Nombre de los dueños de taxis que estén vigentes:

"Conjunto de todas las tuplas t tales que existe una tupla s en la relación Dueño para la que los valores de t y de s son iguales en el atributo Nombre y el valor de s para el atributo vigencia = ‘S’ ". La variable de tupla t se define sólo en el atributo Nombre, puesto que éste es el único atributo para el que se especifica una condición para t. Así, el resultado es una relación sobre (Nombre). Si lo que se desea es obtener las tarifas de todos los viajes que ha efectuado todos los móviles de marca “chevrolet”, la consulta requiere de dos cláusulas “Existe” conectadas por el operador de conjunción lógica “y”.

Que se lee como el conjunto de todas las tuplas (tarifa) correspondientes a los viajes que han hecho todos los móviles de marca “chevrolet”. Considérese ahora la consulta “obtener todos los RUT de los dueños de móviles, cuyos móviles no hayan efectuado nunca un viaje”:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

que ocupa la cláusula “Existe” para exigir que el dueño posea un móvil y la cláusula “no existe” para eliminar a aquellos móviles que tengan viajes realizados. La consulta que se presenta a continuación utiliza la implicación, la fórmula “P implica Q” significa que “si P es verdad entonces Q debe ser verdad”, se introduce el constructor “para todo”. Se desea Selecciona todos los autos a cuyos chóferes les caduca la licencia el “01/01/1999”.

Sin embargo como la intención del modulo no es la de suplir al texto, se recomienda consultar el tema completo en la bibliografía recomendada. Optimización de consultas Las consultas de base de datos relacionales son o bien declarativas o algebraicas. Los lenguajes algebraicos permiten la transformación algebraica de la consulta, luego, basándose en la especificación algebraica de la consulta es relativamente fácil para el optimizador generar diversos planes equivalentes para la consulta y elegir el menos costoso. Dado este nivel de generalidad, el optimizador puede ser visto como el generador de código de un compilador para el lenguaje SQL, que produce el código que será interpretado por el motor de ejecución de consultas, excepto que el optimizador marca énfasis en la capacidad de producir el código más eficiente, haciendo uso para tales efectos del catálogo de la base de datos, de donde obtiene información estadística de las relaciones referenciadas por la consulta, algo que los lenguajes de programación tradicionales no hacen. Un aspecto de la optimización de consultas se sitúa en el nivel del álgebra relacional. Dado un conjunto de reglas se trata de encontrar una expresión que sea equivalente a la expresión dada pero que sea más eficiente en la ejecución.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Con el fin de seleccionar la mejor estrategia para la recuperación de datos el optimizador “estima” un costo que estará relacionado a cada plan de ejecución. Este costo está determinado por fórmulas predefinidas en base a información que se posee de la tabla y que se ha rescatado previamente del catálogo de la base de datos, en realidad el optimizador no siempre escoge el plan más óptimo, ya que encontrar la estrategia óptima puede consumir mucho tiempo, por lo tanto se dice que el optimizador “sólo escoge una estrategia razonablemente eficiente”. La manera con la que el optimizador utiliza esa información, las distintas técnicas y algoritmos que aplica y las transformaciones algebraicas que se realizan son las que diferencian a los optimizadores de bases de datos. Un optimizador basado en el costo genera una serie de planes de evaluación para una consulta y luego elige el que tiene un menor costo asociado, las medidas de costo comúnmente tienen que ver con la E/S y el tiempo de CPU utilizado en ejecutar la consulta, sin embargo, es cuestión de cada SGBD el elegir las medidas de costo que mejor representen el criterio de minimización en la utilización de recursos. Autoevaluación Una de las propiedades de la transacción es la de Aislamiento. En bases de datos, el Aislamiento significa Una transacción A no puede ver datos de una transacción B, mientras la transacción B no termine. Una transacción A puede ver datos de una transacción B siempre Una transacción A no puede ver datos de una transacción B, mientras B no le asigne timesptamp Una transacción A no puede ver datos de una transacción B, mientras tenga abiertas tablas Referencias CERI S, Pelagatti G.,Distributed databases principles & systems.. Ed. MacGraw-Hill. 1985. DATE, C. J, Introducción a los sistemas de bases de datos. Ed. Prentice Hall. Séptima edición. SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGrawHill. Cuarta edición OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill www.lsi.us.es/docencia/asignaturas/dbd.html

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

www.cieloprogramadores.com

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Capítulo 2. Diseño de bases de datos distribuidas
Lección 6. Bases de datos distribuidas
Introducción y fundamentos de Base de Datos Distribuidas. La cantidad de innovaciones tecnológicas que ha habido en los últimos años ha promovido un cambio en la forma de observar a los sistemas de información y, en general, a las aplicaciones computacionales. Existen avances tecnológicos que se realizan continuamente en circuitos, dispositivos de almacenamiento, programas y metodologías. Sin embargo, los cambios tecnológicos van de la mano con la demanda de los usuarios y programas para la explotación exhaustiva de tales dispositivos mejorados. Por tanto, existe un continuo desarrollo de nuevos productos los cuales incorporan ideas nuevas desarrolladas por compañías e instituciones académicas. Aún cuando es posible que un usuario común no perciba los desarrollos relevantes de nuevos productos, para las aplicaciones existe una demanda permanente por mayor funcionalidad, mayor número de servicios, más flexibilidad y mejor rendimiento. Así, al diseñar un nuevo sistema de información o al prolongar la vida de uno ya existente, se debe buscar siempre formas para enlazar las soluciones ofrecidas por la tecnología disponible a las necesidades de las aplicaciones de los usuarios. Un área en la cual las soluciones están integrando tecnología con nuevas arquitecturas o formas de hacer las cosas es, sin lugar a dudas, el área de los sistemas distribuidos de información. Ellos se refieren al manejo de datos almacenados en facilidades de cómputo localizadas en muchos sitios ligados a través de una red de comunicaciones. Un caso específico de estos sistemas distribuidos es lo que se conoce como bases de datos distribuidas, tópico a estudiar en estas notas. Conceptualización de Bases de Datos Distribuidas. Los sistemas de bases de datos distribuidas son un caso particular de los sistemas de cómputo distribuido en los cuales un conjunto de elementos de procesamiento autónomos (no necesariamente homogéneos) se interconectan por una red de comunicaciones y cooperan entre ellos para realizar sus tareas asignadas. Históricamente, el cómputo distribuido se ha estudiado desde muchos puntos de vista. Así, es común encontrar en la literatura un gran número de términos que se han usado para identificarlo. Entre los términos más comunes que se utilizan para referirse al

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

cómputo distribuido podemos encontrar: funciones distribuidas, procesamiento distribuido de datos, multiprocesadores, multicomputadoras, procesamiento satelital, procesamiento tipo "backend", computadoras dedicadas y de propósito específico, sistemas de tiempo compartido, sistemas funcionalmente modulares. Existen muchos componentes a distribuir para realizar una tarea. En computación distribuida los elementos que se pueden distribuir son:

procesamiento de información.

radas en una actividad de

Figura 18. Motivación de los sistemas de bases de datos distribuidos. Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones (ver Figura18). Un sistema de base de datos distribuida (SBDD) es un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones, de tal forma que, un usuario en cualquier sitio puede accesar los datos en cualquier parte de la red exactamente como si los datos estuvieran almacenados en su sitio propio. Un sistema de manejo de bases de datos distribuidas (SMBDD) es aquel que se encarga del manejo de la BDD y proporciona un mecanismo de acceso que hace que la distribución sea transparente a los usuarios. El término transparente significa que la

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

aplicación trabajaría, desde un punto de vista lógico, como si un solo SMBD ejecutado en una sola máquina, administrara esos datos. Un sistema de base de datos distribuida (SBDD) es entonces el resultado de la integración de una base de datos distribuida con un sistema para su manejo. Dada la definición anterior, es claro que algunos sistemas no se pueden considerar como SBDD. Por ejemplo, un sistema de tiempo compartido no incluye necesariamente un sistema de manejo de bases de datos y, en caso de que lo haga, éste es controlado y administrado por una sola computadora. Un sistema de multiprocesamiento puede administrar una base de datos pero lo hace usualmente a través de un solo sistema de manejo de base de datos; los procesadores se utilizan para distribuir la carga de trabajo del sistema completo o incluso del propio SMBD pero actuando sobre una sola base de datos. Finalmente, una base de datos la cual reside en un solo sitio de una red de computadoras y que es accesada por todos los nodos de la red no es una base de datos distribuida (Figura 19). Este caso se trata de una base de datos cuyo control y administración esta centralizada en un solo nodo pero se permite el acceso a ella a través de la red de computadoras.

Figura 19. Un sistema centralizado sobre una red. El medio ambiente típico de un SMBDD consiste de un conjunto de sitios o nodos los cuales tienen un sistema de procesamiento de datos completo que incluye una base de datos local, un sistema de manejo de bases de datos y facilidades de comunicaciones. Si los diferentes sitios pueden estar geográficamente dispersos, entonces, ellos están

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

interconectados por una red de tipo WAN. Por otro lado, si los sitios están localizados en diferentes edificios o departamentos de una misma organización pero geográficamente en la misma ubicación, entonces, están conectados por una red local (LAN) (Figura 20).

Figura 20. Un medio ambiente distribuido para bases de datos. Tipos de bases de datos distribuidas. En términos generales, podemos decir que existen dos tipos de sistemas de bases de datos distribuidas, homogéneas y sistemas de bases de datos distribuidas heterogéneas. La homogeneidad o heterogeneidad, puede darse a diferentes niveles, Hardware, Software o sistema operativo. Para este curso, se asume que cuando se indica la homogeneidad del sistema, se hace referencia a que en todos los sitios del sistema, existe el mismo sistema de administración de base de datos y generalmente incluye el mismo modelo de datos. Un sistema de bases de datos distribuido, incluye diferentes sistemas manejadores de bases de datos, probablemente con modelos de datos diferentes que hay que compatibilizar y con retos a nivel de comunicación entre los sistemas de bases de datos que conforman el sistema, para dar la visión al usuario de integración y de un único sistema de bases de datos.

Autoevaluación

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Una base de datos distribuida heterogenea es Aquella que incluye diferentes modelos de datos y motores de administración de datos Aquella que tiene los mismos modelos de datos y motores de administración de datos Aquella que incluye diferentes sitios Aquella que incluye redes de datos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 7. Bases de datos distribuidas
En el presente capítulo se mostrará los aspectos importantes referentes al diseño de una base de datos distribuida. Se revisará el problema de fragmentación de los datos así como la transparencia que un sistema de datos distribuidos debe guardar respecto a la vista del usuario. Se presentarán los algoritmos para fragmentación horizontal, fragmentación horizontal derivada y fragmentación vertical. En la parte final de este capítulo se discute el problema de asignación de fragmentos. El problema de diseño El problema de diseño de bases de datos distribuidos se refiere, en general, a tomar decisiones acerca de la ubicación de datos y programas a través de los diferentes sitios de una red de computadoras. Este problema debería estar relacionado al diseño de la misma red de computadoras. Sin embargo, en estas notas únicamente el diseño de la base de datos se toma en cuenta. La decisión de donde colocar a las aplicaciones tiene que ver tanto con el software del SMBDD (sistema manejador de base de datos distribuidas) como con las aplicaciones que se van a ejecutar sobre la base de datos. El diseño de las bases de datos centralizadas contempla los puntos siguientes: 1. Diseño del "esquema conceptual" el cual describe la base de datos integrada (esto es, todos los datos que son utilizados por las aplicaciones que tienen acceso a las bases de datos). 2. Diseño "físico de la base de datos", esto es, mapear el esquema conceptual a las áreas de almacenamiento y determinar los métodos de acceso a las bases de datos. En el caso de las bases de datos distribuidas se tienen que considerar los problemas siguientes: 1. Diseño del “esquema conceptual”, donde se busca describir el modelo de datos de todo el sistema 2. Diseño de la fragmentación, este proceso se determina mediante la división de las tablas en fragmentos horizontales, verticales o mixtos, dependiendo de las necesidades de información detectadas en la etapa de análisis del sistema. 3. Diseño de la asignación de los fragmentos, esto determina la forma en que los fragmentos se mapean en los sitios o nodos del sistema. 4. Diseño de replicación. Proceso que indica en que lugar (nodos), se ubican copias de tablas o fragmentos y la frecuencia de actualización de la información. Objetivos del Diseño de la Distribución de los Datos.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

En el diseño de la distribución de los datos, se deben de tomar en cuenta los siguientes objetivos: Procesamiento local. La distribución de los datos, para maximizar el procesamiento local corresponde al principio simple de colocar los datos tan cerca como sea posible de las aplicaciones que los utilizan. Se puede realizar el diseño de la distribución de los datos para maximizar el procesamiento local agregando el número de referencias locales y remotas que le corresponden a cada fragmentación candidata y la localización del fragmento, que de esta forma se seleccione la mejor solución de ellas. Distribución de la carga de trabajo. La distribución de la carga de trabajo sobre los sitios, es una característica importante de los sistemas de cómputo distribuidos. Esta distribución de la carga se realiza para tomar ventaja de las diferentes características (potenciales) o utilizaciones de las computadoras de cada sitio, y maximizar el grado de ejecución de paralelismo de las aplicaciones. Sin embargo, la distribución de la carga de trabajo podría afectar negativamente el procesamiento local deseado. Costo de almacenamiento y disponibilidad. La distribución de la base de datos refleja el costo y disponibilidad del almacenamiento en diferentes sitios. Para esto, es posible tener sitios especializados en la red para el almacenamiento de datos. Sin embargo el costo de almacenamiento de datos no es tan relevante si éste se compara con el del CPU, I/O y costos de transmisión de las aplicaciones. Enfoques al problema de diseño de bases de datos distribuidas Existen dos estrategias generales para abordar el problema de diseño de bases de datos distribuidas: El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado para aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el análisis de requerimientos para definir el diseño conceptual y las vistas de usuario. A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. Se prosigue con el diseño de la fragmentación de la base de datos, y de aquí se continúa con la localización de los fragmentos en los sitios, creando las imágenes físicas. Esta aproximación se completa ejecutando, en cada sitio, "el diseño físico" de los datos, que se localizan en éste. En la Figura 21 se presenta un diagrama con la estructura general del enfoque top-down. El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En forma resumida, el diseño bottom-up de una base de datos distribuida requiere de la selección de un modelo de bases de datos común para describir el esquema global de la base de datos. Esto se debe, a que es posible que se utilicen diferentes SMBD. Después se

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

hace la traducción de cada esquema local en el modelo de datos común y finalmente se hace la integración del esquema local en un esquema global común.

Figura 21. El enfoque top-down para el diseño de bases de datos distribuidas. El diseño de una base de datos distribuida, cualquiera sea el enfoque que se siga, debe responder satisfactoriamente las siguientes preguntas: ¿Por qué hacer una fragmentación de datos? ¿Cómo realizar la fragmentación? ¿Qué tanto se debe fragmentar? ¿Cómo probar la validez de una fragmentación? ¿Cómo realizar el asignamiento de fragmentos? ¿Cómo considerar los requerimientos de la información?

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Autoevaluación El diseño Top-Down, es mejor desarrollarlo cuando El sistema de base de datos a trabajar es nuevo, comienza de cero Ya existen bases de datos y hay que integrarlas en el sistema distribuido La programación a utilizar es orientada a objeto Se utiliza patrones de diseño

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 8. Fragmentación

Figura 22. El problema de fragmentación de relaciones. El problema de fragmentación se refiere al particionamiento de la información para distribuir cada parte a los diferentes sitios de la red, como se observa en la Figura 22. Inmediatamente aparece la siguiente pregunta: ¿cuál es la unidad razonable de distribución? Se puede considerar que una relación completa es lo adecuado ya que las vistas de usuario son subconjuntos de las relaciones. Sin embargo, el uso completo de relaciones no favorece las cuestiones de eficiencia sobre todo aquellas relacionadas con el procesamiento de consultas. La otra posibilidad es usar fragmentos de relaciones (sub-relaciones) lo cual favorece la ejecución concurrente de varias transacciones que accesan porciones diferentes de una relación. Sin embargo, el uso de sub-relaciones también presenta inconvenientes. Por ejemplo, las vistas de usuario que no se pueden definir sobre un solo fragmento necesitarán un procesamiento adicional a fin de localizar todos los fragmentos de una vista. Aunado a esto, el control semántico de datos es mucho más complejo ya que, por ejemplo, el manejo de llaves únicas requiere considerar todos los fragmentos en los que se distribuyen todos los registros de la relación. En resumen, el objetivo de la fragmentación es encontrar un nivel de particionamiento adecuado en el rango que va desde tuplas o atributos hasta relaciones completas (ver Figura 23 ). Ejemplo 1. Considere una relación J del ejemplo visto en la introducción del presente capítulo. J: JNO JNOMBRE PRESUPUESTO LUGAR J1 Instrumentación 150000 Guajira

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

J2 Desarrollo de bases de datos 135000 Cartagena J3 CAD/CAM 250000 Medellín J4 Mantenimiento 310000 Cartagena J5 CAD/CAM 500000 Bogotá La relación J se puede fragmentar horizontalmente produciendo los siguientes fragmentos. J1: Proyectos con presupuesto menor que $200,000 JNO JNOMBRE PRESUPUESTO LUGAR J1 Instrumentación 150000 Guajira J2 Desarrollo de bases de datos 135000 Cartagena J2: Proyectos con presupuesto mayor que o igual a $200,000 JNO JNOMBRE PRESUPUESTO LUGAR J3 CAD/CAM 250000 Medellín J4 Mantenimiento 310000 Cartagena J5 CAD/CAM 500000 Bogotá Ejemplo 2. La relación J del ejemplo anterior se puede fragmentar verticalmente produciendo los siguientes fragmentos: J1: información acerca de presupuestos de proyectos JNO PRESUPUESTO J1 150000 J2 135000 J3 250000 J4 310000

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

J5 1500000 J2: información acerca de los nombres y ubicaciones de proyectos JNO JNOMBRE LUGAR J1 Instrumentación Guajira J2 Desarrollo de bases de datos Cartagena J3 CAD/CAM Medellín J4 Mantenimiento Cartagena J5 CAD/CAM Bogotá

Figura 23. El grado de fragmentación. Correctitud de una fragmentación: Al realizar la fragmentación de una relación se deben satisfacer las siguientes condiciones para garantizar la correctitud de la misma: Condición de completitud. La descomposición de una relación R en los fragmentos R1, R2, ..., Rn es completa si y solamente si cada elemento de datos en R se encuentra en algún de los Ri. Condición de Reconstrucción. Si la relación R se descompone en los fragmentos R1, R2, ..., Rn, entonces debe existir algún operador relacional U , tal que, R=U1 i <= n Ri

Condición de Fragmentos Disjuntos. Si la relación R se descompone en los fragmentos R1, R2, ..., Rn, y el dato di está en Rj, entonces, no debe estar en ningún otro fragmento Rk (k¹ j). Alternativas sobre replicación para el asignamiento de fragmentos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

La replicación de información es de utilidad para obtener un mejor rendimiento y para ofrecer un mayor grado de confiabilidad (tolerancia a fallas). La replicación se complica cuando es necesario hacer actualizaciones a las copias múltiples de un dato. Por tanto, respecto a la replicación, en el asignamiento de fragmentos se tienen tres estrategias:

Como regla general se debe considerar que la replicación de fragmentos es de utilidad cuando el número de consultas de solo lectura es (mucho) mayor que el número de consultas para actualizaciones. En la Tabla 1 se comparan la complejidad de implementar o tomar ventaja de las diferentes alternativas de replicación, respecto de los diferentes aspectos importantes en bases de datos distribuidas. Recopilación completa Fácil Fácil o no existente Moderado Muy alto Aplicación posible Recopilación Parcial Moderado Moderado Difícil Alto Realista Particionamiento Moderado Moderado Fácil Bajo Aplicación posible

Procesamiento de Consultas Manejo de Directorios Control de Concurrencia Confiabilidad Realidad

Tabla 2. Comparación de las estrategias de replicación de fragmentos. Requerimientos de información: Con el fin de realizar una fragmentación adecuada es necesario proporcionar información que ayude a realizarla. Esta información normalmente debe ser proporcionada por el usuario y tiene que ver con cuatro tipos:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Autoevaluación En términos generales, la fragmentación busca Que la información se administre en el sitio donde ella pertenece Que la información se administre en todos los sitios Que la información se administre verticalmente Que la información se administre horizontalmente

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 9. Tipos de fragmentación de datos
Existen tres tipos de fragmentación:

En las siguientes secciones revisaremos de manera informal cada uno de los tipos mencionados. Más adelante, se presentará de manera más formal la construcción de los diferentes tipos de fragmentación. Fragmentación horizontal primaria Consiste del particionamiento en tuplas de una relación global en subconjuntos, donde cada subconjunto puede contener datos que tienen propiedades comunes y se puede definir expresando cada fragmento como una operación de selección sobre la relación global. Ejemplo 3. Considere la relación global SUPPLIER (SNUM, NAME, CITY) entonces, la fragmentación horizontal puede ser definida como: SUPPLIER1 = SLcity == "SF"SUPPLIER SUPPLIER1 = SLcity == "LA"SUPPLIER Esta fragmentación satisface la condición de completes si "SF" y "LA" son solamente los únicos valores posibles del atributo CITY. 2. La condición de reconstrucción se logra con: SUPPLIER = SUPPLIER1 unión SUPPLIER2 3. La condición de disjuntos se cumple claramente en este ejemplo. Fragmentación horizontal derivada La fragmentación derivada horizontal se define partiendo de una fragmentación horizontal.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

En esta operación se requiere de Semi-junta (Semi-Join) el cual nos sirve para derivar las tuplas o registros de dos relaciones. Ejemplo 4. Las siguientes relaciones definen una fragmentación horizontal derivada de la relación SUPPLY. SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1 SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2 Fragmentación vertical La fragmentación vertical es la subdivisión de atributos en grupos. Los fragmentos se obtienen proyectando la relación global sobre cada grupo. La fragmentación es correcta si cada atributo se mapea en al menos un atributo del fragmento. Ejemplo 5. Considere la siguiente relación global: EMP( empnum, name, sal, tax, mgrnum, depnum ) una fragmentación vertical de esta relación puede ser definida como: EMP1 = PJempnum, name, mgrnum, depnum EMP EMP2 = PJempnum, sal, tax EMP La reconstrucción de la relación EMP puede ser obtenida como: EMP = EMP1 (JN empnum) EMP2 porque empnum es una clave de EMP Fragmentación híbrida En lo que respecta a la fragmentación híbrida, esta consiste en aplicar la fragmentación vertical seguida de la fragmentación horizontal o viceversa. Ejemplo 6. Considere la relación global EMP (empnum, name, sal, tax, mrgnum, depnum) Las siguientes son para obtener una fragmentación mixta, aplicando la vertical seguida de la horizontal: EMP1 = SL depnum <= 10 PJempnum, name, mgrnum, depnum EMP EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum EMP EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum EMP

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

EMP4 = PJ empnum, name, sal, tax EMP La reconstrucción de la relación EMP es definida por la siguiente expresión: EMP = UN(EMP1, EMP2, EMP3)JNempnum = empnumPJempnum, sal, tax EMP4 Finalmente, como otro ejemplo considere el siguiente esquema global EMP(EMPNUM, NAME, SAL, TAX, MGRNUM, DEPNUM) DEP(DEPNUM, NAME, AREA, MGRNUM) SUPPLIER(SNUM, NAME, CITY) SUPPLY(SNUM, PNUM, DEPNUM, QUAN) Después de aplicar una fragmentación mixta se obtiene el siguiente esquema fragmentado EMP1 = Sldepnum <= 10 PJempnum, name, mgrnum, depnum (EMP) EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum (EMP) EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum (EMP) EMP4 = PJ empnum, name, sal, tax (EMP) DEP1 = SL depnum <= 10 (DEP) DEP2 = SL 10 < depnum <= 20 (DEP) DEP3 = SL depnum > 20 (DEP) SUPPLIER1 = SL city == "SF" (SUPPLIER) SUPPLIER2 = SL city == "LA" (SUPPLIER) SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1 SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2 Autoevaluación La fragmentación se trabaja a nivel de tabla

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Verdadero

Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 10. Diseño de replica
La replicación de información es de utilidad para obtener un mejor rendimiento y para ofrecer un mayor grado de confiabilidad (tolerancia a fallas). Se entiende por Replicación, la administración de copias de fragmentos o tablas y de asegurar su actualización en los periodos de tiempo definidos por el administrador del sistema. La replicación se complica cuando es necesario hacer actualizaciones a las copias múltiples de un dato. Por tanto, respecto a la replicación, en la asignación de fragmentos se tienen tres estrategias: 1 No soportar replicación. Cada fragmento reside en un solo sitio. 2 Soportar replicación completa. Cada fragmento en cada uno de los sitios. 3 Soportar replicación parcial. Cada fragmento en algunos de los sitios. Como regla general se debe considerar que la replicación de fragmentos es de utilidad cuando el número de consultas de solo lectura es (mucho) mayor que el número de consultas para actualizaciones. En la Tabla 1 se comparan la complejidad de implementar o tomar ventaja de las diferentes alternativas de replicación, respecto de los diferentes aspectos importantes en bases de datos distribuidas. Además de indicar en que sitios se desea guardar copia de la entidad o tabla, es necesario definir la frecuencia o periodo de actualización de la copia. En este sentido, podemos encontrar los siguientes tipos de réplica: 1 En tiempo real, es decir en el momento que un sitio actualiza un registro (inserción, modificación y borrado de registros), se envía una copia de la información a los sitios donde reside la copia. 2 Copia fuera de línea, esta opción permite que una vez registrada la transacción en el sitio donde ella se genera, pueda pasar un tiempo para actualizar las copias de la información almacenadas en otros lugares. Con estos dos tipos de replicación, es posible definir varios modelos de sistemas de replica: 1. Maestro - maestro, hace que una vez generada y registrada una transacción en un sitio del sistema, inmediatamente se actualicen las copias de la información que se guardan en los otros sitios. Este modelo, aumenta la opción de acceso a datos desde cualquier punto, aumentando la disponibilidad del sistema. El mayor problema de este modelo es que debe garantizarse canales de comunicación entre los nodos en todo momento, de tal manera que se asegure la copia de los fragmentos cuando la transacción se realice, de lo contrario el sistema cae en un estado de invalidez de información.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

2. Maestro-copia. Este modelo permite que la actualización de los sitios pueda generarse en un periodo de tiempo T después de generarse una t transacción en un sitio del sistema. Este modelo asume que los datos de las copias pueden estar diferentes al registro original durante un periodo de tiempo, sin afectar los procesos del sistema. El modelo reduce costos de canal de comunicación, ya que este es requerido durante algunos periodos de tiempo, durante el cual se realizan las actualizaciones a las replicas del sistema. 3. Maestro - bodega. Este modelo exige la determinación de un sitio, donde se guardarán las replicas de los datos. Una vez se realice una transacción en un sitio, inmediata o durante un periodo de tiempo, debe generarse la copia de la replica en la bodega de datos. Esto hace que las consultas a información que no se encuentre en el sitio, solo puede hacerse a la bodega de datos. Este modelo reduce los costos de canales de datos, pero debe asegurarse que el sitio de la bodega siempre se encuentre accesible Autoevaluación El modelo Maestro Bodega indica que Cada vez que se modifique un dato en el Maestro, actualiza la información en el sitio de la bodega de datos Cada vez que se modifique un dato en el Maestro, actualiza en todos los demás sitios involucrados Cada vez que se modifique un dato en el Maestro, solo se actualiza el sitio maestro Cada vez que se modifique un dato en el Maestro, se hace réplica

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Capitulo 3. Consultas
Lección 11. Consultas distribuidas
El procesamiento de consultas es de suma importancia en bases de datos centralizadas. Sin embargo, en BDD éste adquiere una relevancia mayor. El objetivo es convertir transacciones de usuario en instrucciones para manipulación de datos. No obstante, el orden en que se realizan las transacciones afecta grandemente la velocidad de respuesta del sistema. Así, el procesamiento de consultas presenta un problema de optimización en el cual se determina el orden en el cual se hace la menor cantidad de operaciones. En BDD se tiene que considerar el procesamiento local de una consulta junto con el costo de transmisión de información al lugar en donde se solicitó la consulta. Objetivo del procesamiento de las consultas En un sistema de base de datos es posible cambiar la estructura inicial, pero es algo que puede resultar muy costoso desde el punto de vista de tiempo y dinero. Por tanto, cuando se presenta una consulta al sistema, es necesario hallar el mejor método de encontrar la respuesta utilizando la estructura existente de la base de datos. Existe un gran número de estrategias posibles para procesar una consulta, especialmente si la estructura es compleja. No obstante, normalmente vale la pena que el sistema dedique una cantidad importante de tiempo en la selección de una buena estrategia. El coste de procesar una consulta normalmente está dominado por el acceso al disco. Pero, en un sistema distribuido es preciso tener en cuenta otros factores, como son:

procesaran en paralelo partes de la consulta. La diferencia entre una buena estrategia y una mala, en términos del número de accesos a disco requeridos y el coste de transmisión de datos en la red, a menudo es importante, y puede tener varios órdenes de magnitud. Así pues, el tiempo empleado en elegir una estrategia de procesamiento de consultas merece la pena incluso para una consulta que se ejecuta sólo una vez. Niveles de procesador de consultas Existen varios medios para calcular la respuesta a una consulta; siempre debe elegirse una estrategia de procesamiento de consultas que reduzca al mínimo el tiempo que se requiere para calcular la respuesta. En el caso de sistemas centralizados, el criterio principal para determinar el coste de una estrategia específica es el número de accesos al disco. En un sistema distribuido es preciso tener en cuenta otros factores, como son:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

El coste de transmisión de datos en la red.

procesaran en paralelo partes de la consulta. El coste relativo de la transferencia de datos en la red y la transferencia de datos entre la memoria y el disco varía en forma considerable, dependiendo del tipo de red y de la velocidad de los discos. Por tanto, en un caso general, no podemos tener en cuenta sólo los costes del disco o los de la red. Es necesario llegar a un equilibrio adecuado entre los dos. Localización de datos Consideremos una consulta muy sencilla: “Encontrar todas las tuplas de la relación depósito”. Aunque la consulta es muy simple, de hecho es trivial; su procesamiento no es trivial, ya que es posible que la relación depósito esté fragmentada, repetida o las dos cosas. Si la relación depósito está repetida, es preciso decidir que copia se va a utilizar. Si ninguna de las copias está fragmentada, se elige la copia que implique costes de transmisión más reducidos. Pero si una copia está fragmentada, la elección no es tan sencilla, ya que es preciso calcular varios productos o uniones para reconstruir la relación depósito. En tal caso, el número de estrategias para este ejemplo sencillo puede ser grande. De hecho, la elección de una estrategia puede ser una tarea tan compleja como hacer una consulta arbitraria. La transparencia de la fragmentación implica que el usuario puede escribir una consulta como ésta:

Puesto que depósito está definido como

La expresión que resulta del esquema de traducción de nombres es

Al emplear las técnicas de optimización podemos simplificar de manera automática esta expresión. La expresión que resulta es

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

La cual incluye dos subexpresiones. La primera incluye sólo depósito1 y, por tanto, puede ser calculada en la localidad de Riverside. La segunda incluye solamente depósito2 y, por tanto, puede ser calculada en la localidad de Columbia. Existe aún una optimización que se puede hacer así:

Puesto que depósito1 tiene solamente tuplas de pertenecientes a la sucursal Riverside, podemos eliminar la operación de selección. Calculando

Podemos aplicar la definición del fragmento depósito2 para obtener

Esta expresión es el conjunto vacío, independientemente del contenido de la relación depósito. Así, nuestra estrategia final para la localidad Riverside consistirá en devolver depósito1 como resultado de la consulta. Procesamiento de intersección simple Un aspecto importante de la elección de una estrategia de procesamiento de consulta es elegir una estrategia de intersección. Considere la expresión algebraica relacional: Cliente |x| depósito |x| sucursal Suponemos que ninguna de las tres relaciones esté repetida o fragmentada y que cliente está almacenada en la localidad Lc, depósito en la Ld y sucursal en la Lb. Sea Li la localidad donde se originó la consulta. El sistema debe producir el resultado en la

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

localidad Li. Entre las posibles estrategias para procesar posibles estrategias para procesar esta consulta se encuentran en las siguientes:
i.

Escoger una estrategia para

procesar en forma local la consulta completa en Li.
d

y calcular cliente |x|

depósito de Ld. Enviar cliente |x| depósito de Ld a Lb, donde se calcula (cliente |x| deposito) |x| sucursal. El resultado de esta operación es enviado a Li.

de Lc, Ld y Lb. No puede garantizarse que una estrategia sea la mejor en todos los casos. Entre los factores que deben tener en cuenta están la cantidad de datos que debe transmitirse, el costo de transmitir un bloque de datos entre dos localidades determinadas y la velocidad de procesamiento relativa en cada localidad. Considerar las dos primeras estrategias mencionadas. Si se envían las tres relaciones a Li y existen índices para ellas, puede ser necesario volver a crear esos índices en Li. Esto requiere tiempo extra de procesamiento y más accesos al disco. Sin embargo, la segunda estrategia tiene la desventaja de que una relación potencialmente grande (cliente |x| deposito) debe transmitirse desde Ld a Lb. Esta relación repite los datos del domicilio de un cliente una vez por cada cuenta que tenga el cliente. Así, la segunda estrategia puede requerir la transmisión de un volumen mayor que la primera estrategia. También pueden utilizarse dos estrategias adicionales, la de intersección utilizando el paralelismo y la estrategia de semi-intersección. Autoevaluación La consulta de datos intenta reducir el costo de trasmisión Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 12. Descomposición de una consulta y localización de datos distribuidos
Antes de que pueda iniciarse el procesamiento de una consulta, el sistema debe traducir la consulta a una forma que pueda manejar. Los lenguajes como el SQL son adecuados a las personas, pero no para ser la representación interna de una consulta dentro del sistema. Una representación interna más útil es la que se basa en el álgebra relacional. La primera acción que el sistema debe tomar en una consulta es traducirla a su forma interna. Este proceso de traducción es similar al trabajo realizado por el analizador sintáctico (parser) de un compilador. Al generar la forma interna de la consulta, el parser revisa la sintaxis de la consulta del usuario, verifica que los nombres de relaciones que aparecen en la consulta sean nombres de relaciones de base de datos, y así sucesivamente. Si la consulta se expresó en términos de una vista, el parser sustituye todas las referencias al nombre de la vista por la expresión del álgebra relacional para calcular esa vista. Una vez que se ha traducido la consulta a una forma interna del álgebra, empieza el proceso de optimización. La primera fase de la optimización se lleva a cabo en el nivel del álgebra relacional. Se hace un intento para encontrar una expresión que sea equivalente a la expresión dada, pero que pueda ejecutarse de manera eficiente. La siguiente fase implica la selección de una estrategia detallada para procesar la consulta. Debe tomarse una decisión acerca de la manera exacta en que se va a ejecutar la consulta. Se deben elegir los índices específicos que se van a usar. Se debe determinar el orden en que se van a procesar las tuplas. La elección final de una estrategia se basa principalmente en el número de accesos a disco que se requieran. Plan de optimización de consultas distribuidas Dada una consulta, generalmente existe una variedad de métodos para calcular la respuesta. Cada forma de expresar la consulta “sugiere” una estrategia para encontrar la respuesta. Sin embargo, no esperamos que los usuarios escriban sus consultas de una forma que sugiera la estrategia más eficiente. Así pues, el sistema debe encargarse de transformar la consulta como la introdujo el usuario en una consulta equivalente que pueda calcularse de manera más eficiente. Esta “optimización”, o más exactamente, mejora de la estrategia para procesar una consulta se llama optimización de consultas. Existe una analogía entre la optimización de consultas por un sistema de base de datos. La optimización de consultas es una cuestión importante en cualquier sistema de base de datos puesto que la diferencia en tiempo de ejecución entre una buena estrategia y una mala puede ser enorme. En el modelo de red y en el modelo jerárquico la optimización de consultas se deja en su mayor parte al programador de aplicaciones. Esto se debe a que las sentencias de los lenguajes de manipulación de datos de estos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

dos modelos normalmente se incorporan en un lenguaje de programación principal, y no es fácil transformar una consulta de red o jerárquica en una equivalente sin conocimiento del programa de aplicación completo. Ya que una consulta relacional puede expresarse completamente en un lenguaje de consulta relacional sin emplear un lenguaje principal, es posible realizar automáticamente una cantidad importante de optimización de consultas. Algunos sistemas reducen el número de estrategias que necesitan ser completamente consideradas haciendo una suposición heurística de una estrategia buena. Según esto, el optimizador considera cada una de las posibles estrategias, pero acaba tan pronto como determine que el coste es mayor que la mejor de las estrategias consideradas anteriormente. Si el optimizador empieza con una estrategia que es probable que tenga un coste bajo, sólo unas pocas estrategias competentes requerirán un análisis completo del coste. Esto puede reducir el tiempo de optimización de consultas. Para simplificar la tarea de selección de estrategias se debe dividir una consulta en varias subconsultas. Esto no sólo simplifica la selección de estrategias sino que también permite al optimizador de consultas reconocer los casos en los que una subconsulta determinada aparezca varias veces en la misma consulta. Si esas subconsultas se calculan una sola vez, se ahorra tiempo tanto en la fase de optimización de la consulta como en la ejecución de la consulta. El reconocimiento de subconsultas comunes es análogo al reconocimiento de subexpresiones comunes en muchos compiladores optimizadores de lenguajes de programación. Es obvio que examinar la consulta buscando subconsultas comunes y estimar el coste de un gran número de estrategias supone un tiempo extra considerable en el procesamiento de consultas. Sin embargo, el coste adicional de optimización de consultas generalmente se compensa con creces por el ahorro en el tiempo de ejecución de la consulta. El ahorro logrado es aún mayor en aquellas aplicaciones que se ejecutan sobre una base regular y vuelven a ejecutar las mismas consultas en cada ejecución. Por tanto, la mayor parte de los sistemas comerciales incluyen optimizadores relativamente sofisticados. Autoevaluación Todo Sistema Manejador de Bases de Datos incluye optimizadores de consulta Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 13. Transacciones Distribuidas
Hasta este momento, las primitivas básicas de acceso que se han considerado son las consultas (queries). Sin embargo, no se ha discutido qué pasa cuando, por ejemplo, dos consultas tratan de actualizar el mismo elemento de datos, o si ocurre una falla del sistema durante la ejecución de una consulta. Dada la naturaleza de una consulta, de lectura o actualización, a veces no se puede simplemente reactivar la ejecución de una consulta, puesto que algunos datos pueden haber sido modificados antes la falla. El no tomar en cuenta esos factores puede conducir a que la información en la base de datos contenga datos incorrectos. El concepto fundamental aquí es la noción de "ejecución consistente" o "procesamiento confiable" asociada con el concepto de una consulta. El concepto de una transacción es usado dentro del dominio de la base de datos como una unidad básica de cómputo consistente y confiable. Definición de una transacción Una transacción es una colección de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema. Una base de datos está en un estado consistente si obedece todas las restricciones de integridad definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción (Ver Figura 3.1) Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 24. Un modelo de transacción. Ejemplo 1. Considere la siguiente consulta en SQL para incrementar el 10% del presupuesto del proyecto CAD/CAM de la base de datos de ejemplo. UPDATE J SET BUDGET = BUDGET*1.1 WHERE JNAME = "CAD/CAM" Esta consulta puede ser especificada, usando la notación de SQL, como una transacción otorgándole un nombre: Begin_transaction ACTUALIZA_PRESUPUESTO begin UPDATE J SET BUDGET = BUDGET*1.1 WHERE JNAME = "CAD/CAM" end.

Ejemplo 2. Considere una agencia de reservaciones para líneas aéreas con las siguientes relaciones: FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP ) CUST( CNAME, ADDR, BAL ) FC( FNO, DATE, CNAME, SPECIAL ) Una versión simplificada de una reservación típica puede ser implementada mediante la siguiente transacción: Begin_transaction Reservación begin input( flight_no, date, customer_name ); EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

end.

EXEC SQL INSERT INTO FC( FNAME, DATE, CNAME, SPECIAL ) VALUES (flight_no, date, customer_name, null ) output("reservación terminada");

Condiciones de terminación de una transacción Una transacción siempre termina, aun en la presencia de fallas. Si una transacción termina de manera exitosa se dice que la transacción hace un commit (se usará el término en inglés cuando no exista un término en español que refleje con brevedad el sentido del término en inglés). Si la transacción se detiene sin terminar su tarea, se dice que la transacción aborta. Cuando la transacción es abortada, su ejecución es detenida y todas sus acciones ejecutadas hasta el momento son deshechas (undone) regresando a la base de datos al estado antes de su ejecución. A esta operación también se le conoce como rollback. Ejemplo 3. Considerando de nuevo el Ejemplo 3.2, veamos el caso cuando no existen asientos disponibles para hacer la reservación. Begin_transaction Reservación begin input( flight_no, date, customer_name ); INTO temp1, temp2 EXEC SQL SELECT STSOLD, CAP FROM FLIGHT WHERE FNO = flight_no AND DATE = date if temp1 = temp2 then output( "no hay asientos libres" ) Abort else EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date EXEC SQL INSERT INTO FC( FNAME, DATE, CNAME, SPECIAL ) VALUES (flight_no, date, customer_name, null ) Commit output("reservación terminada"); endif end. Caracterización de transacciones Observe que en el ejemplo anterior las transacciones leen y escriben datos. Estas acciones se utilizan como base para caracterizar a las transacciones. Los elementos de datos que lee una transacción se dice que constituyen el conjunto de lectura (RS). Similarmente, los elementos de datos que una transacción escribe se les denomina el

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

conjunto de escritura (WS). Note que los conjuntos de lectura y escritura no tienen que ser necesariamente disjuntos. La unión de ambos conjuntos se le conoce como el conjunto base de la transacción (BS = RS U WS). Ejemplo 4. Los conjuntos de lectura y escritura de la transacción del Ejemplo 3.3 son: RS[Reservación] = { FLIGHT.STSOLD, FLIGHT.CAP } WS[Reservación] = { FLIGHT.STSOLD, FC.FNO, FC.DATE, FC.NAME, FC.SPECIAL } Formalización del concepto de transacción Sea Oij(x) una operación Oj de la transacción Ti la cual trabaja sobre alguna entidad x. Oj Oj es una operación atómica, esto es, se ejecuta como una unidad indivisible. Se denota por OSi = U j Oij al conjunto de todas las operaciones de la transacción Ti. También, se denota por Ni la condición de terminación para Ti, donde, Ni La transacción Ti es un orden parcial, Ti = { I i, <i }, donde Sumatoria i = OSi I {Ni} Para cualesquiera dos operaciones, Oij, Oik OSi, si Oij = R(x) y Oik = W(x) para cualquier elemento de datos x, entonces, ó Oij <i Oik ó Oik <i Oij Para todo Oij I OSi, Oij <i Ni Ejemplo 3. Considere una transacción simple T que consiste de los siguientes pasos: Read( x ) Read( y ) x x + y Write( x ) Commit La especificación de su transacción de acuerdo con la notación formal que se ha introducido es la siguiente: Sumatoria = { R(x), R(y), W(x), C } <i = { (R(x), W(x)), (R(y), W(x)), (W(x), C), (R(x), C), (R(y), C) }

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Note que la relación de ordenamiento especifica el orden relativo de todas las operaciones con respecto a la condición de terminación. Esto se debe a la tercera condición de la definición de transacción. También note que no se define el ordenamiento entre cualquier par de operaciones, esto es, debido a que se ha definido un orden parcial. Propiedades de las transacciones La discusión en la sección previa clarifica el concepto de transacción. Sin embargo, aun no se ha dado ninguna justificación para afirmar que las transacciones son unidades de procesamiento consistentes y confiables. Las propiedades de una transacción son las siguientes: Atomicidad. Se refiere al hecho de que una transacción se trata como una unidad de operación. Por lo tanto, o todas las acciones de la transacción se realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una transacción se interrumpe por una falla, sus resultados parciales deben ser deshechos. La actividad referente a preservar la atomicidad de transacciones en presencia de abortos debido a errores de entrada, sobrecarga del sistema o ínter bloqueos se le llama recuperación de transacciones. La actividad de asegurar la atomicidad en presencia de caídas del sistema se le llama recuperación de caídas. Consistencia. La consistencia de una transacción es simplemente su correctitud. En otras palabras, una transacción es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma característica. Debido a esto, las transacciones no violan las restricciones de integridad de una base de datos. Aislamiento. Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de su commit. Más aún, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad). Durabilidad. Es la propiedad de las transacciones que asegura que una vez que una transacción hace su commit, sus resultados son permanentes y no pueden ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los resultados de una transacción sobrevivirán a fallas del sistema. Esta propiedad motiva el aspecto de recuperación de bases de datos, el cual trata sobre como recuperar la base de datos a un estado consistente en donde todas las acciones que han hecho un commit queden reflejadas. En resumen, las transacciones proporcionan una ejecución atómica y confiable en presencia de fallas, una ejecución correcta en presencia de accesos de usuario múltiples y un manejo correcto de réplicas (en el caso de que se soporten). Tipos de Transacciones Las transacciones pueden pertenecer a varias clases. Aun cuando los problemas fundamentales son los mismos para las diferentes clases, los algoritmos y técnicas que

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

se usan para tratarlas pueden ser considerablemente diferentes. Las transacciones pueden ser agrupadas a lo largo de las siguientes dimensiones: Áreas de aplicación. En primer lugar, las transacciones se pueden ejecutar en aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les conocen como transacciones distribuidas. Por otro lado, dado que los resultados de una transacción que realiza un commit son durables, la única forma de deshacer los efectos de una transacción con commit es mediante otra transacción. A este tipo de transacciones se les conoce como transacciones compensatorias. Finalmente, en ambientes heterogéneos se presentan transacciones heterogéneas sobre los datos. Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que se inicia una transacción hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en línea. Estas se pueden diferencias también como transacciones de corta y larga vida. Las transacciones en línea se caracterizan por tiempos de respuesta muy cortos y por accesar una porción relativamente pequeña de la base de datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente largos y accesan grandes porciones de la base de datos. Estructura. Considerando la estructura que puede tener una transacción se examinan dos aspectos: si una transacción puede contener a su vez subtransacciones o el orden de las acciones de lectura y escritura dentro de una transacción. Estructura de transacciones Las transacciones planas consisten de una secuencia de operaciones primitivas encerradas entre las palabras clave begin y end. Por ejemplo, Begin_transaction Reservación ... end. En las transacciones anidadas, las operaciones de una transacción pueden ser así mismo transacciones. Por ejemplo, Begin_transaction Reservación ... Begin_transaction Vuelo ... end. {Vuelo} ... Begin_transaction Hotel ... end. ... end.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Una transacción anidada dentro de otra transacción conserva las mismas propiedades que la de sus padres, esto implica, que puede contener así mismo transacciones dentro de ella. Existen restricciones obvias en una transacción anidada: debe empezar después que su padre y debe terminar antes que él. Más aún, el commit de una subtransacción es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones aborta, las subtransacciones hijas también serán abortadas. Las transacciones anidadas proporcionan un nivel más alto de concurrencia entre transacciones. Ya que una transacción consiste de varias transacciones, es posible tener más concurrencia dentro de una sola transacción. Así también, es posible recuperarse de fallas de manera independiente de cada subtransacción. Esto limita el daño a un parte más pequeña de la transacción, haciendo que costo de la recuperación sea menor. En el segundo punto de vista se considera el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restricción, entonces, a este tipo de transacciones se les conoce como generales. En contraste, si se restringe o impone que un dato deber ser leído antes de que pueda ser escrito entonces se tendrá transacciones restringidas. Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de dos pasos. Finalmente, existe un modelo de acción para transacciones restringidas en donde se aplica aún más la restricción de que cada par <read,write> tiene que ser ejecutado de manera atómica. Ejemplo 6. Los siguientes son algunos ejemplos de los modelos de transacción mencionados antes. General: T1: { R(x), R(y), W(y), R(z), W(x), W(z), W(w), C} Dos pasos: T2: { R(x), R(y), R(z), W(x), W(y), W(z), W(w), C} Restringida: T3: { R(x), R(y), W(y), R(z), W(x), W(z), R(w), W(w), C} Restringida y de dos pasos: T4: { R(x), R(y), R(z), R(w), W(y), W(x), W(z), W(w), C} Acción: T3: { [R(x), W(x)], [R(y), W(y)], [R(z), W(z)], [R(w), W(w)], C} Note que cada par de acciones encerrado en [ ] se ejecuta de manera atómica 8. Aspectos relacionados al procesamiento de transacciones Los siguientes son los aspectos más importantes relacionados con el procesamiento de transacciones:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas. Autoevaluación Toda transacción exitosa hace Rollback Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 14. Consistencia de la base de datos interna.
Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas. Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA). Incorporación del manejador de transacciones a la arquitectura de un SMBD El monitor de ejecución distribuida consiste de dos módulos: El administrador de transacciones (TM) y el despachador (SC). Como se puede apreciar en la Figura 25, el administrador de transacciones es responsable de coordinar la ejecución en la base de datos de las operaciones que realiza una aplicación. El despachador, por otra parte, es responsable de implementar un algoritmo específico de control de concurrencia para sincronizar los accesos a la base de datos. Un tercer componente que participa en el manejo de transacciones distribuidas es el administrador de recuperación local cuya función es implementar procedimientos locales que le permitan a una base de datos local recuperarse a un estado consistente después de una falla.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 25. Un modelo del administrador de transacciones. Los administradores de transacciones implementan una interfaz para los programas de aplicación que consiste de los comandos: Begin_transaction. Read. Write. Commit. Abort. En la Figura 26 se presenta la arquitectura requerida para la ejecución centralizada de transacciones. Las modificaciones requeridas en la arquitectura para una ejecución distribuida se pueden apreciar en las Figura 26b. En esta última figura se presentan también los protocolos de comunicación necesarios para el manejo de transacciones distribuidas.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 26. Ejecución centralizada de transacciones.

Figura 26b. Ejecución distribuida de transacciones. Recuperación en Sistemas Distribuidos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Una transacción debe ejecutarse en forma atómica. Es decir, se ejecutan completamente todas las instrucciones de la transacción, o no se ejecuta ninguna. Además, en el caso de ejecución concurrente, el efecto de ejecutar una transacción debe ser el mismo que si se ejecutara sola en el sistema. Estructura del sistema. Cuando se tiene un sistema de base de datos distribuido, es mucho más difícil garantizar la propiedad de atomicidad de una transacción. Esto se debe a que es posible que participen varias localidades en la ejecución de una transacción. El fallo de una de estas localidades o el fallo de la línea de comunicación entre ellas, puede dar como resultado un cálculo erróneo. La función del gestor de transacciones de un sistema de base de datos distribuidos es asegurar que la ejecución de las distintas transacciones. Los distintos gestores de transacciones cooperan para ejecutar las transacciones globales. Para comprender cómo puede estructurarse un gestor de este tipo, definiremos un modelo abstracto para un sistema de transacciones. Gestor de transacciones, cuya función es gestionar la ejecución de aquellas transacciones (o subtransacciones) que accedan a datos almacenados en esa localidad. Observamos que da transacción puede ser bien una transacción local (es decir, que se ejecuta sólo en esa localidad), o parte de una transacción global (es decir, que se ejecuta en varias localidades). Coordinador de transacciones, cuya función es la de coordinar la ejecución de varias transacciones (tanto local como global) iniciadas en esa localidad. La estructura de un gestor de transacciones es similar en muchos aspectos a la que se utiliza en el caso de un sistema centralizado. Cada gestor de transacciones se encarga de:

ejecución en paralelo de las transacciones que se ejecuten en esa localidad. Como su nombre lo indica, un coordinador de transacciones se encarga de coordinar todas las transacciones que se inicien en esa localidad. Para cada una de estas transacciones, el coordinador debe: transacción. las localidades apropiadas para su ejecución.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

abordada en todas las localidades. Robustez Es una configuración distribuida es necesario prever otro tipo de fallos, como pueden ser:

Por tanto, para que el sistema sea robusto, es necesario que detecte cualquiera de estos fallos, que reconfigure el sistema de manera que pueda reanudarse el proceso y que se recupere una vez que haya sido reparado el procesador o la línea de comunicación afectados. En general, no es posible distinguir entre los fallos en las líneas de comunicación de la red y de las localidades. Por tanto, el esquema de reconfiguración que se adopte debe estar diseñado para que funcione correctamente aun cuando la red quede fragmentada.

También es necesario tener cuidado al reintegrar al sistema una localidad o línea de comunicación separada. Cuando una localidad que quedó fuera de servicio se recupera, debe iniciar un procedimiento de actualización de sus tablas de sistema para que reflejen los cambios que tuvieron lugar mientras estaba inactiva. Si la localidad tenía copias de datos, debe obtener los valores actuales de todos ellos y asegurarse de recibir las actualizaciones futuras. Esto es más complicado de lo que parece, ya que es posible que se actualicen los datos que se están procesando mientras que el sistema se recupera. Es necesario representar a las tareas de recuperación como una seria de transacciones. En este caso, el subsistema de control de concurrencia y el manejo de transacciones puede encargarse de realizar de manera fiable la reintegración de la localidad. Si se recupera una línea de comunicación interrumpida, es posible que se unan de nuevo dos fragmentos de la red. Dado que la fragmentación de una red limita las operaciones que pueden permitirse en algunas localidades, o en todas ellas, es

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

conveniente enviar un mensaje a todas ellas informando sin delación que la línea se recuperó. Control de concurrencia El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra. Sin embargo, esto puede afectar grandemente el desempeño de un DDBMS dado que el nivel de concurrencia se reduce al mínimo. El nivel de concurrencia, el número de transacciones activas, es probablemente el parámetro más importante en sistemas distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de la base de datos y el mantenimiento de un alto nivel de concurrencia. Si no se hace un adecuado control de concurrencia, se pueden presentar dos anomalías. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo término, pueden presentarse recuperaciones de información inconsistentes. En este capítulo se hace la suposición de que el sistema distribuido es completamente confiable y no experimente falla alguna. Teoría de la seriabilidad Una calendarización (schedule), también llamado una historia, se define sobre un conjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado de la ejecución de las operaciones de las transacciones. La calendarización puede ser especificada como un orden parcial sobre T. Ejemplo 1. Considere las siguientes tres transacciones: T1: Read( x ) T2: Write( x ) T3: Read( x ) Write( x ) Write( y ) Read( y ) Commit Read( z ) Read( z ) Commit Commit Una calendarización de las acciones de las tres transacciones anteriores puede ser: H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 } Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que accesan el mismo dato de la base de datos x se dice que están en conflicto si al menos una de ellas es una escritura. De esta manera, las operaciones de lectura no tienen conflictos consigo mismas. Por tanto, existen dos tipos de conflictos read-write (o write-read) y write-write. Las dos operaciones en conflicto pueden pertenecer a la misma transacción o a transacciones diferentes. En el último caso, se dice que las transacciones tienen conflicto. De manera intuitiva, la existencia de un conflicto entre dos operaciones indica

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

que su orden de ejecución es importante. El orden de dos operaciones de lectura es insignificante. Una calendarización completa define el orden de ejecución de todas las operaciones en su dominio. Formalmente, una calendarización completa STc definido sobre un conjunto de transacciones T = { T1, T2, ..., Tn } es un orden parcial STc = { T, <T } en donde Sumatoria T = Ui <T i , para todos los i = 1, 2, ..., n

i <i , para todos los i = 1, 2, ..., n T, ó Oij <T Okl ó

Para cualesquiera dos operaciones en conflicto Oij y Okl Okl <T Oij

La primera condición establece simplemente que el dominio de la calendarización es la unión de los dominios de las transacciones individuales. La segunda condición define la relación de ordenamiento como un superconjunto de la relación de ordenamiento de transacciones individuales. Esto mantiene el ordenamiento de las operaciones dentro de cada transacción. La condición final define el orden de ejecución entre dos operaciones en conflicto. Ejemplo 2. Considere las tres transacciones del Ejemplo 1, una posible calendarización completa está dada por la siguiente gráfica dirigida acíclica (DAG).

Una calendarización se define como un prefijo de una calendarización completa. Un prefijo de un orden parcial se define como sigue. Dado un orden parcial

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Las primeras dos condiciones definen a P’ como una restricción de P en el dominio en donde las relaciones de ordenamiento en P se mantienen por P’. La última condición indica que para cualquier elemento de incluidos también en Ejemplo 3. La siguiente calendarización es un prefijo de la calendarización del Ejemplo 2. Si en una calendarización S, las operaciones de varias transacciones no están entrelazadas, esto es, si las operaciones de una transacción ocurren de manera consecutiva, entonces se dice que la calendarización es serial. Si cada transacción es consistente (obedece las reglas de integridad), entonces la base de datos se garantiza ser consistente al final de la calendarización serial. La historia asociada a este tipo de calendarización se le conoce como serial. Ejemplo 4. La siguiente es una historia serial para el Ejemplo 1. HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 } Las transacciones se ejecutan de manera concurrente, pero el efecto neto de la historia resultante sobre la base de datos es equivalente a alguna historia serial. Basada en la relación de precedencia introducida por el orden parcial, es posible discutir la equivalencia de diferentes calendarizaciones con respecto a sus efectos sobre la base de datos. Dos calendarizaciones, S1 y S2, definidas sobre el mismo conjunto de transacciones T, se dice que son equivalentes si para cada par de operaciones en conflicto Oij y Okl (i k), cada vez que Oij <1 Okl, entonces, Oij <2 Okl. A esta relación se le conoce como equivalencia de conflictos puesto que define la equivalencia de dos calendarizaciones en término del orden de ejecución relativo de las operaciones en conflicto en ellas. Una calendarización S se dice que es serializable, si y solamente si, es equivalente por conflictos a una calendarización serial. Ejemplo 5. Las siguientes calendarizaciones no son equivalentes por conflicto: HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 } H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 } Las siguientes calendarizaciones son equivalentes por conflictos; por lo tanto H2 es serializable: HS = { W2(x), W2(y), R2(z), C2, R1(x), W1(x), C1, R3(x), R3(y), R3(z), C3 } H2 = { W2(x), R1(x), W1(x), C1, R3(x), W2(y), R3(y), R2(z), C2, R3(z), C3 }

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

La función primaria de un controlador de concurrencia es generar una calendarización serializable para la ejecución de todas las transacciones. El problema es, entonces, desarrollar algoritmos que garanticen que únicamente se generan calendarizaciones serializables. Seriabilidad en SMBD distribuidos En bases de datos distribuidas es necesario considerar dos tipos de historia para poder generar calendarizaciones serializables: la calendarización de la ejecución de transacciones en un nodo conocido como calendarización local y la calendarización global de las transacciones en el sistema. Para que las transacciones globales sean serializables se deben satisfacer las siguientes condiciones:

historias locales donde las operaciones aparecen juntas. La segunda condición simplemente asegura que el orden de serialización sea el mismo en todos los nodos en donde las transacciones en conflicto se ejecutan juntas. Ejemplo 6. Considere las siguientes tres transacciones: T1: Read( x ) T2: Read( x ) x x ) Write( x ) Commit Commit Las siguientes historias locales son individualmente serializables (de hecho son seriales), pero las dos transacciones no son globalmente serializables. LH1 = { R1(x), W1(x), C1, R2(x), W2(x), C2 } LH2 = { R2(x), W2(x), C2, R1(x), W1(x), C1 } Taxonomía de los mecanismos de control de concurrencia El criterio de clasificación más común de los algoritmos de control de concurrencia es el tipo de primitiva de sincronización. Esto resulta en dos clases: aquellos algoritmos que están basados en acceso mutuamente exclusivo a datos compartidos (candados) y aquellos que intentar ordenar la ejecución de las transacciones de acuerdo a un conjunto de reglas (protocolos). Sin embargo, esas primitivas se pueden usar en algoritmos con dos puntos de vista diferentes: el punto de vista pesimista que considera que muchas transacciones tienen conflictos con otras, o el punto de vista optimista que supone que no se presentan muchos conflictos entre transacciones. Los algoritmos pesimistas sincronizan la ejecución concurrente de las transacciones en su etapa inicial de su ciclo de ejecución. Los algoritmos optimistas retrasan la sincronización de las transacciones hasta su terminación. El grupo de algoritmos pesimistas consiste de algoritmos basados en candados, algoritmos basados en ordenamiento por estampas de tiempo y algoritmos híbridos. El grupo de los algoritmos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

optimistas se clasifican por basados en candados y basados en estampas de tiempo (Ver. Figura 27).

Figura 27. Clasificación de los algoritmos de control de concurrencia. Algoritmos basados en candados En los algoritmos basados en candados, las transacciones indican sus intenciones solicitando candados al despachador (llamado el administrador de candados). Los candados son de lectura (rl), también llamados compartidos, o de escritura (wl), también llamados exclusivos. Como se aprecia en la tabla siguiente, los candados de lectura presentan conflictos con los candados de escritura, dado que las operaciones de lectura y escritura son incompatibles. rl wl rl si no wl no no En sistemas basados en candados, el despachador es un administrador de candados (LM). El administrador de transacciones le pasa al administrador de candados la operación sobre la base de datos (lectura o escritura) e información asociada, como por ejemplo el elemento de datos que es accesado y el identificador de la transacción que está enviando la operación a la base de datos. El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si candado solicitado es incompatible con el candado con que el dato está bloqueado, entonces, la transacción solicitante es retrasada. De otra forma, el candado se define sobre el dato en el modo deseado y la operación a la base de datos es transferida al procesador de datos. El administrador de transacciones

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

es informado luego sobre el resultado de la operación. La terminación de una transacción libera todos los candados y se puede iniciar otra transacción que estaba esperando el acceso al mismo dato. Candados de dos fases (2PL) En los candados de dos fases una transacción le pone un candado a un objeto antes de usarlo. Cuando un objeto es bloqueado con un candado por otra transacción, la transacción solicitante debe esperar. Cuando una transacción libera un candado, ya no puede solicitar más candados. Así una transacción que utiliza candados de dos fases se comporta como en la Figura 28. En la primera fase solicita y adquiere todos los candados sobre los elementos que va a utilizar y en la segunda fase libera los candados obtenidos uno por uno. La importancia de los candados de dos fases es que se ha demostrado de manera teórica que todos las calendarizaciones generadas por algoritmos de control de concurrencia que obedecen a los candados de dos fases son serializables. Puede suceder que si una transacción aborta después de liberar un candado, otras transacciones que hayan accesado el mismo elemento de datos aborten también provocando lo que se conoce como abortos en cascada. Para evitar lo anterior, los despachadores para candados de dos fases implementan lo que se conoce como los candados estrictos de dos fases en los cuales se liberan todos los candados juntos cuando la transacción termina (con commit o aborta). El comportamiento anterior se muestra en la Figura 29.

Figura 28. Gráfica del uso de los candados de dos fases.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 29. Comportamiento de los candados de dos fases estrictos.

Candados de dos fases centralizados En sistemas distribuidos puede que la administración de los candados se dedique a un solo nodo del sistema, por lo tanto, se tiene un despachador central el cual recibe todas las solicitudes de candados del sistema. En la Figura 30 se presenta la estructura de la comunicación de un administrador centralizado de candados de dos fases. La comunicación se presenta entre el administrador de transacciones del nodo en donde se origina la transacción (llamado el coordinador TM), el administrador de candados en el nodo central y los procesadores de datos (DP) de todos los nodos participantes. Los nodos participantes son todos aquellos en donde la operación se va a llevar a cabo.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 30. Comunicación en un administrador centralizado de candados de dos fases estrictos. La crítica más fuerte a los algoritmos centralizados es el "cuello de botella" que se forma alrededor del nodo central reduciendo los tiempos de respuesta de todo el sistema. Más aún, su disponibilidad es reducida a cero cuando se presentan fallas en el nodo central. Candados de dos fases distribuidos En los candados de dos fases distribuidos se presentan despachadores en cada nodo del sistema. Cada despachador maneja las solicitudes de candados para los datos en ese nodo. Una transacción puede leer cualquiera de las copias replicada del elemento x, obteniendo un candado de lectura en cualquiera de las copias de x. La escritura sobre x requiere que se obtengan candados para todas las copias de x. La comunicación entre los nodos que cooperan para ejecutar una transacción de acuerdo al protocolo de candados distribuidos de dos fases se presenta en la Figura 31. Los mensajes de solicitud de candados se envían a todos los administradores de candados que participan en el sistema. Las operaciones son pasadas a los procesadores de datos por los administradores de candados. Los procesadores de datos envía su mensaje de "fin de operación" al administrador de transacciones coordinador. Algoritmos basados en estampas de tiempo A diferencia de los algoritmos basados en candados, los algoritmos basados en estampas de tiempo no pretenden mantener la seriabilidad por exclusión mutua. En lugar de eso, ellos seleccionan un orden de serialización a priori y ejecutan las transacciones de acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le asigna a cada transacción Ti una estampa de tiempo única ts( Ti ) cuando ésta inicia. Una estampa de tiempo es un identificador simple que sirve para identificar cada transacción de manera única. Otra propiedad de las estampas de tiempo es la monoticidad, esto es, dos estampas de tiempo generadas por el mismo administrador de transacciones deben ser monotonicamente crecientes. Así, las estampas de tiempo son valores derivados de un dominio totalmente ordenado.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 31. Comunicación en candados de dos fases distribuidos. Existen varias formas en que las estampas de tiempo se pueden asignar. Un método es usar un contador global monotónicamente creciente. Sin embargo, el mantenimiento de contadores globales es un problema en sistemas distribuidos. Por lo tanto, es preferible que cada nodo asigne de manera autónoma las estampas de tiempos basándose en un contador local. Para obtener la unicidad, cada nodo le agrega al contador su propio identificador. Así, la estampa de tiempo es un par de la forma: <contador local, identificador de nodo> Note que el identificador de nodo se agrega en la posición menos significativa, de manera que, éste sirve solo en el caso en que dos nodos diferentes le asignen el mismo contador local a dos transacciones diferentes. El administrador de transacciones asigna también una estampa de tiempo a todas las operaciones solicitadas por una transacción. Más aún, a cada elemento de datos x se le asigna una estampa de tiempo de escritura, wts(x), y una estampa de tiempo de lectura, rts(x); sus valores indican la estampa de tiempo más grande para cualquier lectura y escritura de x, respectivamente. El ordenamiento de estampas de tiempo (TO) se realiza mediante la siguiente regla: Regla TO: dadas dos operaciones en conflicto, Oij y Okl, perteneciendo a las transacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si y solamente si, ts(Ti) < ts(Tk). En este caso Ti se dice ser una transacción más vieja y Tk se dice ser una transacción más joven. Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente forma:

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

for Ri(x) do begin if ts(Ti) < wts( x ) then reject Ri(x) else accept Ri(x) rts(x) ts(Ti) endfor Wi(x) do begin if ts(Ti) < rts(x) and ts(Ti) < wts(x) then reject Wi(x) else accept Wi(x) wts(x) ts(Ti) end. La acción de rechazar una operación, significa que la transacción que la envió necesita reiniciarse para obtener la estampa de tiempo más reciente del dato e intentar hacer nuevamente la operación sobre el dato. Ordenamiento conservador por estampas de tiempo El ordenamiento básico por estampas de tiempo trata de ejecutar una operación tan pronto como se recibe una operación. Así, la ejecución de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones. El ordenamiento conservador de estampas de tiempo retrasa cada operación hasta que exista la seguridad de que no será reiniciada. La forma de asegurar lo anterior es sabiendo que ninguna otra operación con una estampa de tiempo menor puede llegar al despachador. Un problema que se puede presentar al retrasar las operaciones es que esto puede inducir la creación de ínter bloqueos (deadlocks). Ordenamiento por estampas de tiempo múltiples Para prevenir la formación de ínter bloqueos se puede seguir la estrategia siguiente. Al hacer una operación de escritura, no se modifican los valores actuales sino se crean nuevos valores. Así, puede haber copias múltiples de un dato. Para crear copias únicas se siguen las siguientes estrategias de acuerdo al tipo de operación de que se trate: Una operación de lectura Ri(x) se traduce a una operación de lectura de x de una sola versión encontrando la versión de x, digamos xv, tal que, ts(xv) es la estampa de tiempo más grande que tiene un valor menor a ts(Ti). Una operación de escritura Wi(x) se traduce en una sola versión, Wi(xw), y es aceptada si el despachador no ha procesado cualquier lectura Rj(xr), tal que, ts(Ti) < ts(xr) < ts(Tj) Control de concurrencia optimista Los algoritmos de control de concurrencia discutidos antes son por naturaleza pesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones son muy frecuentes y no permiten el acceso a un dato si existe una transacción conflictiva que accesa el mismo dato. Así, la ejecución de cualquier operación de una transacción sigue la secuencia de fases: validación (V), lectura (R), cómputo (C) y escritura (W) (ver Figura 6.6a). Los algoritmos optimistas, por otra parte, retrasan la fase de validación justo antes de la fase de escritura (ver Figura 32). De esta manera, una operación sometida a un despachador optimista nunca es retrasada. Las operaciones de lectura, cómputo y escrita de cada transacción se procesan libremente sin actualizar la base de datos corriente. Cada transacción inicialmente hace sus cambios en copias locales de los datos. La fase de validación consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

es positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra manera, la transacción es abortada y tiene que reiniciar

Figura 32. Fases de la ejecución de una transacción a) pesimista, b) optimista. Los mecanismos optimistas para control de concurrencia fueron propuestos originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de mecanismos las estampas de tiempo se asocian únicamente con las transacciones, no con los datos. Más aún, las estampas de tiempo no se asignan al inicio de una transacción sino justamente al inicio de su fase de validación. Esto se debe a que las estampas se requieren únicamente durante la fase de validación. Cada transacción Ti se subdivide en varias subtransacciones, cada una de las cuales se puede ejecutar en nodos diferentes. Sea Tij una subtransacción de Ti que se ejecuta en el nodo j. Supongamos que las transacciones se ejecutan de manera independiente y ellas alcanzan el fin de sus fases de lectura. A todas las subtransacciones se les asigna una estampa de tiempo al final de su fase de lectura. Durante la fase de validación se realiza una prueba de validación, si una transacción falla, todas las transacciones se rechazan. La prueba de validación se realiza con una de las siguientes reglas: Si todas las transacciones Tk, tales que, ts( Tk ) < ts( Tij ), han terminado su fase de escritura antes que Tij ha iniciado su fase de lectura entonces la validación tiene éxito. En este caso la ejecución de las transacciones es completamente serial como se muestra en la Figura 7a. Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su fase de escritura mientras Tij está en su fase de lectura, entonces, la validación tiene éxito si WS(Tk ) RS(Tij ) = como se muestra en la Figura 7b, pero Tij no lee datos que son escritos por Tk. Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su fase de lectura antes que Tij termine su fase de lectura, entonces, la validación tiene éxito si

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

WS(Tk ) RS(Tij ) = WS(Tk ) WS(Tij ) = traslapan, como se muestra en la Figura 33, pero las transacciones no accesan datos comunes.

Figura 33. Casos diferentes de las pruebas de validación para control de concurrencia optimista.

Autoevaluación Un candado de dos fases, solicita la primero los candados (fase de preparación) y al terminar , los libera Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 15. Catálogo
Conceptos básicos Existe un elemento denominado Catálogo, que es imprescindible conocer si se quiere llegar a ser experto en el manejo de cualquier SGBD (Sistema de gestión de base de datos). El catálogo guarda la información del esquema de la base de datos y es gracias a él que se pueden compartir los esquemas de dominio, y definir las relaciones de integridad y de datos. Comprender la estructura del catálogo, debe de ser un objetivo de todo administrador y analista que quiera conocer el comportamiento de la base de datos. Para poder llegar a solucionar problemas de definición de datos, de rendimiento u optimización es necesario conocer las características del motor, la forma como se comporta en determinada plataforma e incluso sus deficiencias. En un sistema distribuido, el catálogo del sistema incluirá no solo los datos usuales del catálogo con relación a las varrels base, vistas, autorizaciones, etc., sino también toda la información de control necesaria para permitir que el sistema proporcione la independencia de ubicación, fragmentación y replicación necesaria. Surge entonces un interrogante ¿Dónde y cómo debe ser almacenado el propio catálogo?. A continuación se muestran las posibilidades: Centralizado El catálogo total es almacenado exactamente una vez en un sitio central. Completamente replicado El catálogo total es almacenado por completo en cada uno de los sitios. Dividido Cada sitio mantiene su propio catálogo de los objetivos que están almacenados en ese sitio. El catálogo total es la unión de todos los catálogos locales disjuntos. Combinación de centralizado y dividido Cada sitio mantiene su propio catálogo local, como en el punto 4.4; además, un único sitio central mantiene una copia unificada de todos esos catálogos locales, como en punto 4.2 Cada uno de los enfoques mencionados anteriormente, tiene sus propios problemas. El enfoque centralizado viola el objetivo de “no dependencia de un sitio central”. El enfoque completamente replicado sufre una pérdida de autonomía, ya que cada actualización del catálogo tiene que ser propagada por cada uno de los sitios. El enfoque dividido eleva el costo de operaciones que no son locales. La combinación de

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

centralizado y dividido es más eficiente que el dividido, pero viola nuevamente el objetivo de no dependencia de un sitio central, por lo tanto, en la práctica los sistemas no usan ninguno de los enfoque antes mencionados. A manera de ejemplo describimos el enfoque usado en R* (donde R* es un prototipo tomado como referencia). Para explicar la forma en que está estructurado el catálogo de R*, es necesario primero decir algo acerca del nombramiento de objetos en R*. Este nombramiento es importante para los sistemas distribuidos en general, ya que la posibilidad de que los sitios distintos X y Y, puedan tener un objeto, digamos una varrel llamada A, implica que sería necesario algún mecanismo – por lo general la calificación por nombre de sitio – para “eliminar la ambigüedad” (es decir, garantizar la unicidad de nombres a nivel de sistema). Por lo tanto, lo que se necesita es un medio para transformar los nombres conocidos por los usuarios a sus nombres correspondientes conocidos por el sistema. Este es el enfoque de R* para este problema. R* primero distingue entre el nombre común de un objeto, que es el nombre por el cual los usuarios hacen normalmente referencia al objeto ( por ejemplo una instrucción SELECT de SQL), y su nombre a nivel de sistema, que es identificador interno globalmente único para el objeto. Los nombres a nivel del sistema tienen cuatro componentes:

objeto).

se almacenó inicialmente el

Los IDs de usuario son únicos dentro del sito en el cual y los IDs del sitio son únicos a nivel global. Por lo tanto, el nombre a nivel de sistema de MARIO @ NEWAYORK . STATS LONDRES Denota un objeto, tal vez una varrel base, con el nombre local STATS, creada por el usuario Mario en el sitio Nueva York y almacenada inicialmente en el sitio Londres. Este garantizado que este nombre nunca cambiará, ni auque el objeto migre a otro sitio. Los usuarios se refieren normalmente a los objetos por su nombre común. Este nombre se usa sin calificativos, ya sea el componente “nombre local” del nombre a nivel sistema (STATS en el ejemplo anterior) o un sinónimo para ese nombre a nivel de sistema, definido por medio de la instrucción especial de SQL, R* CREATE SYNONYM. En el ejemplo en cuestión: CREATE SYNONYM MSTATS FOR MARIO NUEVAYORK. STATS @ LONDRES;

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Ahora el usuario puede decir (ejemplo) SELECT … FROM STATS…; O SELECT … FROM MSTATS…; En el primer caso (al usar el nombre local), el sistema infiere el nombre a nivel sistema suponiendo todos los valores predeterminados obvios; es decir que el objeto fue creado por este usuario, que fue creado en este sitio y que fue guardado inicialmente en este sitio. En el segundo caso (al usar el sinónimo), el sistema determina el nombre a nivel de sistema consultando la tabla sinónimos relevante. Las tablas del sinónimos pueden ser vistas como el primer componente del catálogo; cada sitio mantiene un conjunto de esas tablas para los usuarios que se sabe que están en ese sitio y transforma los sinónimos conocidos para ese usuario en los nombres a nivel de sistema correspondientes. Además en las tablas de sinónimos cada sitio mantiene: 1. Una entrada de catálogo para cada objeto nacido en este sitio; 2. Una entrada de catálogo para cada objeto almacenado actualmente en ese sitio. Supongamos que ahora el usuario emite una solicitud que hace referencia al sinónimo MSTATS. Primero, el sistema busca el nombre a nivel sistema correspondiente en la tabla de sinónimos adecuada (una simple búsqueda local), Ahora ya sabe el sitio de nacimiento(es decir Londres en el ejemplo) y puede consultar el catálogo de Londres (y se supone, de manera general, que será una búsqueda renota; el primer acceso remoto). El catálogo de Londres contendrá una entrada para ese objeto gracias al punto 1 anterior. Si el objeto está todavía en Londres ya habrá sido encontrado. Sin embargo, si el objeto ha emigrado (digamos) a Los Ángeles, entonces la entrada de catálogo en Londres lo dirá y por lo tanto, el sistema podrá ahora consultar al catálogo de Los Ángeles (segundo acceso remoto). Y el catálogo de los Ángeles contendrá una entrada para los objetos gracias al punto 2 anterior. Por lo tanto, ha sido encontrado en, como máximo, dos accesos remotos. Además, si el objeto emigra nuevamente, digamos a San Francisco, entonces el sistema: Insertará una entrada en el catálogo de San Francisco; Borrará la entrada del catálogo de los Ángeles; Actualizará la entrada del catálogo de Londres para que se apunte a San Francisco en lugar de Los Ángeles.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

El efecto neto es que el objeto todavía puede ser encontrado en dos accesos remotos, como máximo. Y este es un esquema completamente distribuido; no hay un sitio con catálogo central y no hay punto alguno de falla dentro del sistema. Autoevaluación El catalogo guarda la estructura del sistema de base de datos Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Referencias DORSEY, P, Hudicka Oracle8. Diseño de bases de datos con UML. J. Ed. Oracle press. 1999. KROENKE,D. Procesamiento de bases de datos. Fundamentos, implementación. 2003. Ed. Pearson Education. Octava edición diseño e

SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGrawHill. Cuarta edición

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Unidad 2. Bodegas de datos
Capítulo 4. Diseño de bodegas de datos
Lección 16. Introducción
Hoy en día se habla mucho del tema de Data Warehousing o Bodega de Datos, que permite la utilización de los datos de una Organización o un conjunto de ellas, como soporte en la toma de decisiones. Está información puede provenir de múltiples fuentes heterogéneas no sólo en ambiente de computación sino también en formato, ambiente de captura, significado, etc, información toda esta indispensable en su interpretación y correcta utilización y que es lo que se conoce como Metadatos. La función de una Bodega de Datos es la de entregar la información correcta a la gente indicada en el momento adecuado en el formato correcto. Cuántos tornillos se vendieron el año pasado en el último trimestre? Quien? En que Departamentos o ciudades? Cuanto fueron las ventas totales en este trimestre? Cuáles campañas de publicidad dieron el mejor resultado? Las ventas se incrementaron como resultado de las campañas de las últimas semanas? Cuáles son las características de un cliente típico? Cuáles han sido los valores históricos de la razón ácida, para un conjunto de compañías que conforman un pool? Cómo es la composición de las cuentas del presupuesto? Estas son las preguntas a las que la Bodega de Datos tiene respuestas. Sin embargo vale la pena aclarar que Bodega de Datos no es un proyecto de implementación de una herramienta de mercadeo. Es una forma de operar dentro de una organización. Inicia con el proceso de recolección, transformación y lanzamiento de los datos, que se conoce como el proceso de Scrubbing. Almacena los metadatos en lo que se conoce como repositorio y a partir de ahí permite que la información se analice y se presente en la forma que necesita el usuario. Los datos pueden ser extractados de grandes aplicaciones en Mainframe o de múltiples fuentes distribuidas, de ambiente C/S, en ambientes disímiles. Usualmente los datos son transformados (reformateados o agregados) antes de ser colocados en la Bodega de Datos. La problemática de Bodega de Datos difiere de compañía en compañía. Una puede necesitar una Base de Datos centralizada, mientras que una organización distribuida a lo largo del país o del mundo puede necesitar de una gran Base de Datos distribuida.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Autoevaluación Una bodega de datos almacena Información histórica del desempeño de la empresa Información de producción Información transaccional Información institucional

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 17. Construcción y manejo de una bodega de datos
Si la organización tiene muchos datos de aplicaciones tradicionales y está buscando una solución para transferir grandes volúmenes de datos de un Mainframe, se necesita una solución de Bodega de Datos de fuerza industrial para hacer transferencia bruta de datos diferentes de fuentes en Mainframes a Bodegas de Datos en DB2 o en Unix. Se requiere de alguna herramienta para poblar y actualizar la Bodega de Datos que realice extracción de datos a altas velocidades y altos volúmenes de datos, traslade y distribuya de múltiples y diferentes Bases de Datos en Mainframes en la BODEGA y ojalá elimine la necesidad de escribir complejos programas y rutinas de conversión. Usualmente estas herramientas tienen habilidades gráficas y proveen de criterio de selección fácilmente puede llevar los datos al formato requerido en la Base de Datos. Por definición Bodega de Datos es una colección de datos actualizada, por lo tanto la herramienta utilizada debe completar las actualizaciones en el momento. Distribución de datos es el proceso de mover los datos extractados y trasladarlos a la Bodega de Datos o a diferentes Bases de Datos en cualquier plataforma en cualquier sitio. Una herramienta de distribución define Base de Datos Objetivo, información de conversión y entrada y salida de datos. Una vez creadas estas definiciones, pueden ser salvadas para ser reutilizadas, editadas o ejecutadas posteriormente. Algunas soluciones de Bodega de Datos requieren de enrutadores de datos o rutinas de sincronización mas sofisticadas a través de ambientes múltiples y heterogéneos. Este tipo de proceso puede necesitar un movimiento vi direccional entre las plataformas Mainframe y C/S para mantener actualizada y sincronizada la Base de Datos en todas las localidades Autoevaluación Un sistema que facilite la minería de datos permite Buscar tendencias y comportamientos Buscar entidades Buscar atributos Buscar inconsistencias

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 18. Construcción del Data Warehouse.
Como todo proyecto informático, el proyecto de bodega de datos consta de los siguientes pasos. Planeación La fase define la metodología a utilizar. Como se muestra en el modelo de bases de datos avanzada, existe el enfoque Top-Down (De Arriba abajo), y Bottom-up (De abajo a arriba) o una combinación de estas dos. Todo proyecto de sistemas, requiere una metodología de desarrollo del producto. En general, se usa el método de análisis y diseño estructurado y el método del desarrollo en espiral. Requerimientos Especificación de lo que se desean lograr del data warehouse. Comenzando por la vista de usuario, para que se quiere desarrollar la bodega. En el diseño, se puede trabajar dos modelos diferentes, bodegas basadas en el Modelo Entidad Relación o bodegas diseñadas con el modelo copo de nieve (snowflake). En ambos casos, debe diseñarse las tablas que administran los datos del proceso que se desea revisar (producción, ventas, compras), llamadas tablas de hecho y las tablas que registran los elementos que pueden explicar ese hecho, denominadas dimensiones o categorías (estrato, tiempo, categorías de los elementos, día en que se realizó la transacción), elementos que históricamente, pueden determinar un comportamiento o tendencia. Análisis Una vez definidos los requerimientos, se determinan y clarifican las necesidades, se identifican las entidades de donde se alimentará la información de la bodega; se revisan los atributos, sus propiedades y las transformaciones que se deben desarrollar para homogenizar los datos. Se definen los procedimientos de conexión con las fuentes de datos y el data warehouse y las herramientas de acceso del usuario final. Diseño Los modelos lógicos de la fase anterior se convierten en modelos físicos. Incluye la implementación de la bodega en la herramienta; los programas que manipulan los datos para crear, modificar, estandarizar, sumarizar o generar los índices a partir de los datos de los sistemas de alimentación de información definidos en la etapa anterior;

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

determinar la periodicidad en que se hace el proceso de carga de datos a la bodega Montaje Procesos relacionados con la puesta en marcha del sistema. Un elemento importante consiste en concientizar a los usuarios sobre la disponibilidad, beneficios y presentación de de la bodega (proceso de comercialización de la información). En la literatura especializada, estos pasos se conocen como el proceso ETL, llamado así, por las siglas Extracción, Transformación y Carga de datos. Los procesos de Extracción identifican los sistemas que alimentarán la bodega; el proceso de transformación, define la manipulación de los datos para convertirlos y dejarlos en el formato que requiere la bodega y el proceso de Carga, que define la periodicidad en que se debe realizar el proceso para cargar los datos a la bodega.

Autoevaluación Se conoce como ETL, el proceso de Extracción, Transformación y Carga de los datos a la bodeba Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 19. Estrategias recomendadas para diseño de datos
La metodología recomendada es iniciar con un prototipo. Prototipo: La meta del prototipo de Bodega de Datos es proveer a los usuarios finales con una aproximación de lo que la Bodega de Datos les puede proporcionar en un período de tiempo tan corto como sea posible tal que el grupo de Bodega de Datos pueda demostrar los beneficios de la Bodega de Datos a los usuarios y recolectar lo más pronto la retroalimentación crítica de los usuarios. Las estructuras de Datos apropiadas pueden ser distribuidas herramientas de acceso de datos a usuarios finales y aplicaciones para realizar queries. Deben ser creadas herramientas de soporte en la Decisión si es aplicable. Sin embargo el proceso de integrar y transformar los datos de la Bodega de Datos no será completamente automatizado. En la mayoría de los casos el prototipo contemplará una cargada no repetible (de una sola vez) de los datos de las estructuras de las Bodegas de Datos. La plataforma y la Base de Datos para el almacenamiento puede también diferir de aquellas para la arquitectura definitiva de Bodega de Datos, lo que es importante también, es que la presentación de los Datos al usuario final sea tan fiel como sea posible para que sea igualmente presentada en posteriores etapas de la Bodega de Datos. Piloto En la construcción de una Bodega de Datos, se debe observar especial cuidado porque es la primera fase del proyecto en el cual el equipo de Bodega de Datos utilizará los métodos, técnicas y herramientas que será la base para una Bodega de Datos completa. Por esta razón el proyecto piloto de Bodega de Datos debe tener un pequeño alcance y tiempo adicional comparativamente con los esfuerzos sucesivos de Bodega de Datos. Prueba del concepto tecnológico La prueba del concepto tecnológico es un paso opcional que se puede necesitar para definir si la arquitectura especificada para la Bodega de Datos funcionará finalmente como se intenta. En la mayoría de proyectos de Bodega de Datos el esfuerzo del piloto ha servido también como la prueba del concepto para la arquitectura técnica. Es crítico que la prueba del concepto tecnológico no esté cercana al prototipo, dado que la meta del prototipo es poner datos en las manos de los usuarios tan pronto como sea posible. Arquitectura de la Bodega de Datos. Datos de los sistemas de Aplicación y de otras fuentes de Bodegas de Datos deben ser periódicamente extraídos y alimentados en la capa de Data Scrubbing. La extracción debe ser realizada en muchos casos utilizando los programas para acompañar esta tarea. El Data scrubbing debe ser hecho bien sea con ayuda de programas

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

desarrollados para esto, o con ayuda de herramientas de scrubbing tales como Platinum Infopump. El corazón de la Bodega de Datos debe ser organizado desde un punto de vista de negocio. Se debe utilizar una estructura de Datos para el corazón de la Bodega de Datos, ligeramente normalizada. Esta estructura de Datos parece estar normalizada cuando se ve al nivel de Entidad-relación. Cuando se miran los atributos sin embargo, la estructura de datos puede estar desnormalizada. Esta representa una visión de negocio de la compañía y sus datos, independiente de cuanto usuarios este mirando a esos datos en un momento en particular. Esto es importante debido a que la forma en que la información es usada, cambiará frecuentemente y se necesita una Base de Datos estable para soportar el cambio. Por esta razón se debe utilizar una serie de Data Marts para proveer a los usuarios finales con fácil acceso a sus datos. Los Data Marts deben consistir en Datos extraídos del corazón de la Bodega de Datos y reorganizados y/o reformateados para hacer más fácil su uso para diferentes propósitos. Pero fofo que esos propósitos específicos pueden cambiar en el tiempo, los Data Marts deben ser concebidos con estructuras de Datos temporales. Cuando los usuarios no ven más los datos como están presentados por un Data Mart en particular, este Data Mart debe ser removido. Y mientras los usuarios desarrollan nuevas formas de hacer búsquedas y mirar los datos, deben ser creados nuevos Data Marts para hacer sus búsquedas más simples y con un mejor desempeño. Los Data Mart pueden incluir una gran variedad de estilos de tablas. Algunas pueden ser simplemente un subconjunto de datos de la Bodega de Datos, conteniendo solamente datos para una particular zona geográfica, un período específico de tiempo, una unidad de negocios. Es crítico que los usuarios sean provistos del método apropiado para utilizar la información de las Bodegas de Datos. No se debe esperar que un usuario novato negocie una compleja y poderosa herramienta sólo para hacer una simple pregunta de la Bodega de Datos. Similarmente un usuario adelantado rápidamente quedará frustrado con la Bodega de Datos si el o ella esperan hacer un complejo análisis de negocio usando una herramienta de acceso con menos poder del que se necesita. Es importante reconocer que hay diferentes estilos de usuarios finales cada uno con su propio nivel de conocimiento y necesidades, para así proveer de apropiados mecanismos de acceso para cada clase de usuarios. Autoevaluación Para alimentar la bodega es necesario tener herramientas para Extraer datos de diferentes sistemas Herramientas gráficas Herramientas de backup

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Herramientas de antivirus

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 20. Factores de riesgo
Es importante conocerlos para poder monitorearlos. Son éstos: Expectativas de los usuarios. Se debe trabajar con las expectativas de los usuarios. Muchas veces el éxito depende de la diferencia entre lo que los usuarios esperan y lo que ellos perciben que les es entregado. Es crítico que el equipo de Bodega de Datos comunique las expectativas acerca de lo que será entregado muy claramente y ayude al usuario final a entender la naturaleza iterativa de construir una Bodega de Datos. Experiencia con Bodegas de Datos. Este riesgo se puede reducir con el uso juicioso de experiencias de proveedores y consultores. Dirección estratégica. Es relativamente lógico definir un punto de inicio lógico para la Bodega de Datos. Sin embargo cuando esta primera área se haya completado, es más difícil identificar áreas para esfuerzos futuros y asegurar que esos esfuerzos están alineados con los objetivos y necesidades del negocio. El riesgo se puede mitigar siguiendo la estrategia recomendada de la Bodega, para entender las necesidades y prioridades de la información del negocio y desarrollar una implementación de Bodega de Datos a largo plazo que cumpla con estas propiedades. Autoevaluación Un factor de riesgo es determinar lo que el usuario desea de la bodega de datos Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Capitulo 5. Minería de datos
Lección 21. Introducción
Esta unidad tiene como propósito introducir al lector en los conceptos fundamentales de la minería de datos y su relación con las bodegas de datos, no es la intención de profundizar en cada uno de los temas, estos pueden ser ampliados en la bibliografía recomendada, es necesario que el lector tenga conocimientos en base de datos relacionales y distribuidas para una mejor comprensión del tema. Data Mining, la extracción de información oculta y predecible de grandes bases de datos, es una poderosa tecnología nueva con gran potencial para ayudar a las compañías a concentrarse en la información más importante de sus Bases de Información (Data Warehouse). Las herramientas de Data Mining predicen futuras tendencias y comportamientos, permitiendo en los negocios tomar decisiones proactivas y conducidas por un conocimiento acabado de la información (knowledgedriven). Los análisis prospectivos automatizados ofrecidos por un producto así van más allá de los eventos pasados provistos por herramientas retrospectivas típicas de sistemas de soporte de decisión. Las herramientas de Data Mining pueden responder a preguntas de negocios que tradicionalmente consumen demasiado tiempo para poder ser resueltas y a los cuales los usuarios de esta información casi no están dispuestos a aceptar. Estas herramientas exploran las bases de datos en busca de patrones ocultos, encontrando información predecible que un experto no puede llegar a encontrar porque se encuentra fuera de sus expectativas. Las técnicas de minería de datos se emplean para mejorar el rendimiento de procesos de negocio o industriales en los que se manejan grandes volúmenes de información estructurada y almacenada en bases de datos. Por ejemplo, se usan con éxito en aplicaciones de control de procesos productivos, como herramienta de ayuda a la planificación y a la decisión en marketing, finanzas, etc. Asimismo, la minería de datos es fundamental en la investigación científica y técnica, como herramienta de análisis y descubrimiento de conocimiento a partir de datos de observación o de resultados de experimentos. Autoevaluación La minería de datos (Data Mining) busca predecir comportamientos a partir de la información histórica almacenada en la bodega Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 22. Fundamentos del Data Mining
Las técnicas de Data Mining son el resultado de un largo proceso de investigación y desarrollo de productos. Esta evolución comenzó cuando los datos de negocios fueron almacenados por primera vez en computadoras, y continuó con mejoras en el acceso a los datos, y más recientemente con tecnologías generadas para permitir a los usuarios navegar a través de los datos en tiempo real. Data Mining toma este proceso de evolución más allá del acceso y navegación retrospectiva de los datos, hacia la entrega de información prospectiva y proactiva. Data Mining está lista para su aplicación en la comunidad de negocios porque está soportado por tres tecnologías que ya están suficientemente maduras:

Las bases de datos comerciales están creciendo a un ritmo sin precedentes. Un reciente estudio del META GROUP sobre los proyectos de Data Warehouse encontró que el 19% de los que contestaron están por encima del nivel de los 50 Gigabytes, mientras que el 59% espera alcanzarlo en el segundo trimestre de 1997. En algunas industrias, tales como ventas al por menor (retail), estos números pueden ser aún mayores. La necesidad paralela de motores computacionales mejorados puede ahora alcanzarse de forma más efectiva con de con multiprocesamiento paralelo. Los de Data Mining utilizan técnicas que han existido por lo menos desde hace 10 años, pero que sólo han sido implementadas recientemente como herramientas maduras, confiables, entendibles que consistentemente son más performantes que estadísticos clásicos. Los componentes esenciales de la de Data Mining han estado bajo desarrollo por décadas, en áreas de investigación como estadísticas, inteligencia artificial y aprendizaje de máquinas. Hoy, la madurez de estas técnicas, junto con los motores de bases de datos relacionales de alta performance, hicieron que estas tecnologías fueran prácticas para los entornos de data warehouse actuales. Autoevaluación Entre las herramientas de minería encontramos a la estadística Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 23. Alcance de Data Mining
El nombre de Data Mining deriva de las similitudes entre buscar valiosa información de negocios en grandes bases de datos, por ej.: encontrar información de la venta de un producto entre grandes montos de Gigabytes almacenados, minar una montaña para encontrar una veta de metales valiosos. Ambos procesos requieren examinar una inmensa cantidad de material, o investigar inteligentemente hasta encontrar exactamente donde residen los valores. Dadas bases de datos de suficiente tamaño y calidad, la tecnología de Data Mining puede generar nuevas oportunidades de negocios al proveer estas capacidades: Predicción automatizada de tendencias y comportamientos. Data Mining automatiza el proceso de encontrar información predecible en grandes bases de datos. Preguntas que tradicionalmente requerían un intenso análisis manual, ahora pueden ser contestadas directa y rápidamente desde los datos. Un típico ejemplo de problema predecible es el marketing apuntado a objetivos (targeted marketing). Data Mining usa datos en mailing promocionales anteriores para identificar posibles objetivos para maximizar los resultados de la inversión en futuros mailing. Otros problemas predecibles incluyen pronósticos de problemas financieros futuros y otras formas de incumplimiento, e identificar segmentos de población que probablemente respondan similarmente a eventos dados. Descubrimiento automatizado de modelos previamente desconocidos. Las herramientas de Data Mining barren las bases de datos e identifican modelos previamente escondidos en un sólo paso. Otros problemas de descubrimiento de modelos incluye detectar transacciones fraudulentas de tarjetas de créditos e identificar datos anormales que pueden representar errores de tipeado en la carga de datos. Las técnicas de Data Mining pueden redituar los beneficios de automatización en las plataformas de hardware y software existentes y puede ser implementadas en sistemas nuevos a medida que las plataformas existentes se actualicen y nuevos productos sean desarrollados. Cuando las herramientas de Data Mining son implementadas en sistemas de procesamiento paralelo de alta performance, pueden analizar bases de datos masivas en minutos. Procesamiento más rápido significa que los usuarios pueden automáticamente experimentar con más modelos para entender datos complejos. Alta velocidad hace que sea práctico para los usuarios analizar inmensas cantidades de datos. Grandes bases de datos, a su vez, producen mejores predicciones. Las bases de datos pueden ser grandes tanto en profundidad como en ancho: Más columnas. Los analistas muchas veces deben limitar el número de variables a examinar cuando realizan análisis manuales debido a limitaciones de tiempo. Sin embargo, variables que son descartadas porque parecen sin importancia pueden proveer información acerca de modelos desconocidos. Un

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Data Mining de alto rendimiento permite a los usuarios explorar toda la base de datos, sin preseleccionar un subconjunto de variables. Más filas. Muestras mayores producen menos errores de estimación y desvíos, y permite a los usuarios hacer inferencias acerca de pequeños pero importantes segmentos de población. Autoevaluación Las minería de datos puede decirse que busca información dentro de la información Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 24. Fases de un Proyecto de Minería de Datos
Los pasos a seguir para la realización de un proyecto de minería de datos son siempre los mismos, independientemente de la técnica específica de extracción de conocimiento usada. Ver fig. 45.

Figura 45: Fases de un Proyecto de Minería de Datos El proceso de minería de datos pasa por las siguientes fases:

Si desea obtener una descripción más detallada, puede consultar la documentación de CRISP-DM. CRISP-DM (CRoss Industry Standard Process for Data Mining) es un estándar industrial utilizado por más de 160 empresas e instituciones de todo el mundo, que surge en respuesta a la falta de estandarización y propone un modelo de proceso general para proyectos de minería de datos. Autoevaluación Uno de los pasos en el proceso de minería de datos es la selección de variables Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 25. Cómo Trabaja el Data Mining?
¿Cuán exactamente es capaz Data Mining de decirle cosas importantes que usted desconoce o que van a pasar? La técnica usada para realizar estas hazañas en Data Mining se llama Modelado. Modelado es simplemente el acto de construir un modelo en una situación donde usted conoce la respuesta y luego la aplica en otra situación de la cual desconoce la respuesta. Por ejemplo, si busca un galeón español hundido en los mares lo primero que podría hacer es investigar otros tesoros españoles que ya fueron encontrados en el pasado. Notaría que esos barcos frecuentemente fueron encontrados fuera de las costas de Bermuda y que hay ciertas características respecto de las corrientes oceánicas y ciertas rutas que probablemente tomara el capitán del barco en esa época. Usted nota esas similitudes y arma un modelo que incluye las características comunes a todos los sitios de estos tesoros hundidos. Con estos modelos en mano sale a buscar el tesoro donde el modelo indica que en el pasado hubo más probabilidad de darse una situación similar. Con un poco de esperanza, si tiene un buen modelo, probablemente encontrará el tesoro. Este acto de construcción de un modelo es algo que la gente ha estado haciendo desde hace mucho tiempo, seguramente desde antes del auge de las computadoras y de la tecnología de Data Mining. Lo que ocurre en las computadoras, no es muy diferente de la manera en que la gente construye modelos. Las computadoras son cargadas con mucha información acerca de una variedad de situaciones donde una respuesta es conocida y luego el software de Data Mining en la computadora debe correr a través de los datos y distinguir las características de los datos que llevarán al modelo. Una vez que el modelo se construyó, puede ser usado en situaciones similares donde usted no conoce la respuesta. Si alguien le dice que tiene un modelo que puede predecir el uso de los clientes, ¿Cómo puede saber si es realmente un buen modelo? La primera cosa que puede probar es pedirle que aplique el modelo a su base de clientes - donde usted ya conoce la respuesta. Con Data Mining, la mejor manera para realizar esto es dejando de lado ciertos datos para aislarlos del proceso de Data Mining. Una vez que el proceso está completo, los resultados pueden ser testeados contra los datos excluidos para confirmar la validez del modelo. Si el modelo funciona, las observaciones deben mantenerse para los datos excluidos. Una arquitectura para Data Mining Para aplicar mejor estas técnicas avanzadas, éstas deben estar totalmente integradas con el data warehouse así como con herramientas flexibles e interactivas para el análisis de negocios. Varias herramientas de Data Mining actualmente operan fuera del warehouse, requiriendo pasos extra para extraer, importar y analizar los datos. Además, cuando nuevos conceptos requieren implementación operacional, la integración con el warehouse simplifica la aplicación de los resultados desde Data Mining. El Data warehouse analítico resultante puede ser aplicado para mejorar

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

procesos de negocios en toda la organización, en áreas tales como manejo de campañas promocionales, detección de fraudes, lanzamiento de nuevos productos, etc. El punto de inicio ideal es un data warehouse que contenga una combinación de datos de seguimiento interno de todos los clientes junto con datos externos de mercado acerca de la actividad de los competidores. Información histórica sobre potenciales clientes también provee una excelente base para prospecting. Este warehouse puede ser implementado en una variedad de sistemas de bases relacionales y debe ser optimizado para un acceso a los datos flexible y rápido. Un server multidimensional OLAP permite que un modelo de negocios más sofisticado pueda ser aplicado cuando se navega por el data warehouse. Las estructuras multidimensionales permiten que el usuario analice los datos de acuerdo a como quiera mirar el negocio - resumido por línea de producto, u otras perspectivas claves para su negocio. El server de Data Mining debe estar integrado con el data warehouse y el server OLAP para insertar el análisis de negocios directamente en esta infraestructura. Un avanzado, metadata centrado en procesos define los objetivos del Data Mining para resultados específicos tales como manejos de campaña, prospecting, y optimización de promociones. La integración con el data warehouse permite que decisiones operacionales sean implementadas directamente y monitoreadas. A medida que el data warehouse crece con nuevas decisiones y resultados, la organización puede "minar" las mejores prácticas y aplicarlas en futuras decisiones. Este diseño representa una transferencia fundamental desde los sistemas de soporte de decisión convencionales. Más que simplemente proveer datos a los usuarios finales a través de software de consultas y reportes, el server de Análisis Avanzado aplica los modelos de negocios del usuario directamente al warehouse y devuelve un análisis proactivo de la información más relevante. Estos resultados mejoran los metadatos en el server OLAP (procesamiento analítico on-line) proveyendo una estrato de metadatos que representa una vista fraccionada de los datos. Generadores de reportes, visualizadores y otras herramientas de análisis pueden ser aplicadas para planificar futuras acciones y confirmar el impacto de esos planes. Autoevaluación El data mining facilita generar reglas del negocio Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Capítulo 6. Herramientas de minería de datos
Lección 26. Redes neuronales artificiales:
Modelos predecible no-lineales que aprenden a través del entrenamiento y semejan la estructura de una red neuronal biológica.

Autoevaluación Una red neuronal es similar a la manera como funciona el cerebro Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 27. Árboles de decisión:
Estructuras de forma de árbol que representan conjuntos de decisiones. Estas decisiones generan reglas para la clasificación de un conjunto de datos. Métodos específicos de árboles de decisión incluyen Árboles de Clasificación y Regresión (CART: Classification And Regression Tree) y Detección de Interacción Automática de Chi Cuadrado (CHAI: Chi Square Automatic Interaction Detection)

Autoevaluación Un tipo de árbol, es el árbol de decisión Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 28. Método del vecino más cercano:
Es una técnica que clasifica cada registro en un conjunto de datos basado en una combinación de las clases del/de los k registro (s) más similar/es a él en un conjunto de datos históricos (donde k 1). Algunas veces se llama la técnica del vecino k-más cercano.

Autoevaluación El analisis de vecino más cercano es también llamado analisis Cluster Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 29. Algoritmos genéticos
Técnicas de optimización que usan procesos tales como combinaciones genéticas, mutaciones y selección natural en un diseño basado en los conceptos de evolución. Autoevaluación Las técnicas de algoritmos genéticos, simulan el proceso de selección natural Verdadero Falso

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 30. Regla de inducción:
La extracción de reglas if-then de datos basados en significado estadístico Autoevalución La regla de inducción utiliza la estadística Verdadero Falso

Referencias BATINI C.; Ceri S.; Navathe S. Diseño conceptual de bases de datos. Un enfoque de entidades-interrelaciones. 1994. Ed. Addison-Wesley. CASTAÑO A.; Piattini M. Fundamentos y modelos de bases de datos. 1999. Ed. Alfaomega. Segunda edición. CERI S, Pelagatti G.,Distributed databases principles & systems.. Ed. MacGraw-Hill. 1985. DATE, C. J, Introducción a los sistemas de bases de datos. Ed. Prentice Hall. Séptima edición. DORSEY, P, Hudicka Oracle8. Diseño de bases de datos con UML. J. Ed. Oracle press. 1999. KROENKE,D. Procesamiento de bases de datos. Fundamentos, implementación. 2003. Ed. Pearson Education. Octava edición diseño e

SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGrawHill. Cuarta edición OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill. ULLMAN, J Principles of database systems, Ed. Computer science press, 1982.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Unidad 3. Bases de datos orientadas a objetos
Capítulo 7. Orientación a objetos

Lección 31. Introducción
Los sistemas de bases de datos orientados a objetos tienen sus orígenes en los lenguajes de programación orientados a objetos. La idea fundamental es que el usuario no debería tener que batallar con construcciones orientadas al computador tales como registros y campos, sino más bien debería poder manejar objetos (y operaciones) que se asemejen más a sus equivalentes en el mundo real. Por ejemplo, en vez de pensar en términos de una tupla DEPTO junto con un conjunto de tuplas EMP, las cuales incluyen valores de clave ajena que hacen referencia a esa tupla DEPTO, el usuario debería poder pensar directamente en un "objeto" departamento que contenga en realidad un conjunto de "objetos" empleado. Y en vez de (por ejemplo) tener que insertar una tupla en la relación EMP con un valor apropiado de NUMDEPTO (la clave ajena), el usuario debería ser capaz de crear en forma directa un nuevo objeto empleado e incluirlo en el objeto departamento pertinente también en forma directa. Dicho de otro modo, la idea fundamental es elevar el nivel de abstracción. La elevación del nivel de abstracción es sin duda un objetivo deseable, y el paradigma de la orientación a objetos ha tenido considerable éxito en alcanzar ese objetivo en el campo de los lenguajes de programación. Por tanto, es natural preguntar si es posible aplicar el mismo paradigma en el área de las bases de datos. Es más, la idea de manejar una base de datos formada por "objetos encapsulados" (por ejemplo, un objeto dependencia que "sabe qué significa" añadir un empleado o cambiar al gerente o recortar el presupuesto), en vez de tener que entender relaciones, actualizaciones de tuplas, claves ajenas, etcétera, es desde luego mucho más atractiva y “fácil” desde el punto de vista del usuario, al menos en lo superficial. Paradigma de orientación a objetos (oo) En un ambiente OO, el software se organiza como un conjunto de objetos discretos que incorporan tanto su estructura como su comportamiento, en contraste con ambientes tradicionales en donde estas dos características se encuentran separadas.

Los primeros intentos en aplicar la orientación a objetos al ambiente de bases de datos fueron mediante la construcción de interfaces como una capa externa a los SABDs relaciónales.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Uno de los problemas que se tienen actualmente es la falta de estándares en la concepción y definición de términos. Sin embargo, a continuación se van a introducir los conceptos mínimos, que se consideran fundamentales en la aplicación de este paradigma a la tecnología de bases de datos.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 32. Conceptos básicos:
En esta sección se presentan algunos de los términos y conceptos principales del enfoque 00, como los objetos mismos (por supuesto), las clases, métodos, mensajes y jerarquías de clases. También relacionaremos estas ideas con términos y conceptos más familiares siempre que sea posible o apropiado. De hecho, quizá resulte útil mostrar antes que nada una correspondencia burda entre los términos OO y los términos de programación tradicional: Término OO Objeto Clase Método Mensaje Jerarquía de clases Objetos Antes de entrar en detalles, es bueno advertir que en el mundo de los objetos no se encuentra el tipo de precisión al que estamos acostumbrados en el mundo relacional. Además, muchos conceptos de objetos –o las definiciones publicadas de esos objetosson bastante imprecisos y hay muy poco consenso verdadero y mucho desacuerdo, incluso en el nivel más básico. En particular, no hay un “modelo de datos de objetos” abstracto ni formalmente definido, y tampoco hay consenso sobre un modelo informal. ¿Qué es un objeto? Todo. Es un principio básico del enfoque de objetos que “todo es un objeto” (a veces “todo es un objeto de primera clase”). Algunos objetos son inmutables: ejemplos de esto pueden ser los enteros y las cadenas de caracteres. Otros objetos son mutables; algunos ejemplos podrían ser los objetos de departamento y empleado. Por lo tanto, en la terminología tradicional, los objetos inmutables corresponden a los valores y los objetos mutables corresponden a las variables. Todo objeto tiene un tipo (el término en objetos es clase). A los objetos individuales con frecuencia se les llama específicamente ejemplares (instancias) de objeto, para distinguirlos con claridad del tipo o clase del objeto correspondiente. El término tipo se utiliza en su sentido usual de lenguaje de programación; por lo tanto, en particular en este término se incluye el conjunto de operadores (el término en el entorno de objetos es métodos) que pueden ser aplicados a los objetos de ese tipo. Polimorfismo. Término en programación variable tipo función llamada jerarquía de tipos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

El polimorfismo es otro de los pilares fundamentales de la programación orientada a objetos. Es la capacidad de almacenar objetos de un determinado tipo en variables de tipos antecesores del primero a costa, claro está, de sólo poderse acceder a través de dicha variable a los miembros comunes a ambos tipos. Sin embargo, las versiones de los métodos virtuales a las que se llamaría a través de esas variables no serían las definidas como miembros del tipo de dichas variables, sino las definidas en el verdadero tipo de los objetos que almacenan. Herencia El mecanismo de herencia es uno de los pilares fundamentales en los que se basa la programación orientada a objetos. Es un mecanismo que permite definir nuevas clases a partir de otras ya definidas de modo que si en la definición de una clase indicamos que ésta deriva de otra, entonces la primera -a la que se le suele llamar clase hija- será tratada por el compilador automáticamente como si su definición incluyese la definición de la segunda –a la que se le suele llamar clase padre o clase base. Encapsulación Ya hemos visto que la herencia y el polimorfismo son dos de los pilares fundamentales en los que se apoya la programación orientada a objetos. Pues bien, el tercero es la encapsulación, que es un mecanismo que permite a los diseñadores de tipos de datos determinar qué miembros de los tipos pueden ser utilizados por otros programadores y cuáles no. Las principales ventajas que ello aporta son:  Se facilita a los programadores que vayan a usar el tipo de dato (programadores clientes) el aprendizaje de cómo trabajar con él, pues se le pueden ocultar todos los detalles relativos a su implementación interna y sólo dejarle visibles aquellos que puedan usar con seguridad. Además, así se les evita que cometan errores por manipular inadecuadamente miembros que no deberían tocar. Se facilita al creador del tipo la posterior modificación del mismo, pues si los programadores clientes no pueden acceder a los miembros no visibles, sus aplicaciones no se verán afectadas si éstos cambian o se eliminan. Gracias a esto es posible crear inicialmente tipos de datos con un diseño sencillo aunque poco eficiente, y si posteriormente es necesario modificarlos para aumentar su eficiencia, ello puede hacerse sin afectar al código escrito en base a la no mejorada de tipo.

La encapsulamiento de objetos u ocultación de la información es sin duda una buena idea en muchos casos: es evidente que los conceptos gemelos de a) ocultar los detalles irrelevantes a la vista del usuario (con lo cual es posible alterar esos detalles, cuando sea necesario, en una forma controlada y relativamente poco difícil) y b) ofrecer un acceso disciplinado a objetos sólo a través de una interfaz pública, son claramente apropiados para muchos usuarios y muchas aplicaciones. Pero hay que tener en cuenta que

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

siempre existirá la necesidad de obtener acceso a los datos en formas no previstas para realizar consultas especiales, razón por la cual la idea de sólo poder operar a través de métodos predefinidos no es aceptable en algunas situaciones. Los sistemas OO tienden a ser demasiado rígidos en este aspecto. La encapsulación se consigue añadiendo modificadores de acceso en las definiciones de miembros y tipos de datos. Estos modificadores son partículas que se les colocan delante para indicar desde qué códigos puede accederse a ellos, entendiéndose por acceder el hecho de usar su nombre para cualquier cosa que no sea definirlo, como llamarlo si es una función, leer o escribir su valor si es un campo, crear objetos o heredar de él si es una clase, etc

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 33. Arquitectura de administrador de sistemas de BDOO.
La estructura de las bases de datos orientadas a objetos no presenta la uniformidad de las bases de datos relaciónales. Para construir una estructura física fácil de mantener, comúnmente los objetos se representan así: Determinadas clases se tratan como clases básicas de bloques que se construyan, que el sistema de computadores implemente directamente. Comúnmente, las clases básicas corresponden a tipos de datos de lenguajes de programación estándar, tales como entero, flotante, carácter y cadena. Las instancias de clases que no son básicas se representan así: Las variables se representan por campos de un tipo de registro. Cada campo contiene el valor del objeto para instancias de las clases básicas, o bien el identificador del objeto para instancias de las clases que no son básicas. Las variables con un conjunto de valores se representan por una lista enlazada de los objetos que son miembros del conjunto. La estructura física hace que sea posible utilizar registros de longitud fija para implementar una base de datos orientada a objetos, aunque la modificación del esquema puede complicar esto.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Cuando la relación de contenido es jerárquica, el esquema de base de datos para una base de datos orientada a objetos puede representarse utilizando el modelo relacional anidado. No todas las variables encajan convenientemente en la estructura que se ha descrito. Algunas de las aplicaciones que se citan incluyen tipos de datos altamente especializados que son grandes físicamente y que, por razones prácticas, normalmente se manipulan mediante programas de aplicación que no son parte del conjunto de métodos con las clases: Datos de texto. El texto, normalmente se trata como una cadena de bytes que manipulan los editores y formateadores. Datos de audio. Comúnmente, los datos de audio son una representación comprimida digitalizada del habla que manejan aplicaciones de software separadas. Datos de video y gráficos. Los datos de video pueden representarse como un mapa de bytes o como un conjunto de líneas, cajas y otros objetos geométricos. Aunque algunos datos gráficos a menudo se gestionan dentro del sistema de base de datos, en muchos casos se utilizan aplicaciones de software especiales. Las variables que contienen datos de los tipos anteriores, con frecuencia se denominan campos largos, debido a que una implementación relacional de objetos que contengan estas variables requiere registros que contengan campos cuya longitud pueda ser de varios mega bites. Un campo largo se almacena en un archivo especial (o conjunto de archivos) reservado para almacenamiento de campos largos. El método más ampliamente utilizado para acceder a campos largos es el método de verificación de resultados de salida (checkout)/verificación de datos de entrada (checkin). El usuario comprueba (checkout) la copia de un objeto con campo largo, opera sobre esta copia utilizando programas de aplicación de propósito especial y comprueba la copia modificada (checkin). Las nociones de verificación de resultados de salida (checkout) y verificación de datos de entrada (checkin) corresponden aproximadamente a una lectura y a una escritura. Sin embargo, el resultado de la operación de verificación de datos de entrada normalmente no es una escritura sino más bien la creación de una nueva versión.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 34. Sistema administradores de bases de datos orientadas a objetos (SABD-OO)
La primera vez que se habla del concepto de un SABD-OO se remonta al año 1983 con una propuesta de G. Copeland y D. Maier, en la cual sugieren construir tal SABD a partir del lenguaje de programación Smalltalk y con la colaboración de miembros del Oregon Graduate Center. De este prototipo se desarrolla un producto y se comercializa en 1988 por Servio Logia, bajo el nombre de GemStone Por otra parte, en ese mismo año, la compañía Hewlett Packard implementa un proyecto bajo el nombre de Iris. A pesar de que aun no existe un consenso de lo que debe ser un SABD-OO, existen algunas características mínimas que deben ser satisfechas. En efecto, un SABD para ser considerado con una etiqueta de orientación a objetos, debe satisfacer al menos los siguientes criterios:  Debe ser un SABD en el sentido tradicional  Debe ser un sistema orientado a objetos De esta forma, un SAGD-OO debe satisfacer las reglas que aparecen en la figura siguiente: Reglas de bases de datos El sistema debe:      Asegurar la persistencia de los datos. Poder administrar en forma eficiente una jerarquía de memorias. Permitir a los usuarios manipular los datos en forma concurrente. Permitir al usuario consultar la base en forma natural y sencilla. Permitir la administración de objetos complejos.

Reglas de orientación a objetos       Los objetos deben tener una identidad independiente de su valor. El sistema debe además: Permitir la noción de encapsulamiento. Agrupar los objetos en clases o poder establecer tipos. Definir una jerarquía de clases o de tipos. Permitir la programación completa de las aplicaciones. Permitir la extensión de las clases o tipos predefinidos por parte del usuario.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 35. El sistema Postgres
Para referenciar uno de los productos que trabajan este tipo de bases de datos hemos tomado el proyecto Postgres. El proyecto Postgres- Post Ingres- inicia en 1986 como una extensión del SABD Ingres. Ha sido escrito en el lenguaje de programación C y consta de 180000 líneas de código (STON91) Postgres se apoya en la idea de extender el modelo relacional con mecanismos generales que permitan el soporte de objetos complejos, así como implementar jerarquías de objetos. Entre los mecanismos, se pueden mencionar los tipos de datos abstractos, los datos de tipo procedimiento y las reglas. Una base datos en Postgres se puede ver como un conjunto de tablas. El tipo de un atributo puede ser atómico: entero, punto flotante, booleano, date, o bien estructurado: arreglos o procedimientos. Entre los objetivos principales del sistema Postgres de pueden mencionar los siguientes:     Mejorar la administración de los objetos complejos Permitir la definición de nuevos tipos de datos, nuevos operadores y nuevos métodos de acceso. Brindar mecanismos primarios para la definición de bases de datos. Mejorar la seguridad de funcionamiento.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Capitulo 8. Lenguaje de Modelado Unificado UML
Lección 36. Introducción
La intención de este capítulo no es la de hacer un estudio detallado de UML, es tan solo motivar al lector a que con base en los temas aquí tratados pueda consultar textos avanzados sobre la temática y su relación con las bases de datos UML es un lenguaje de modelamiento para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo. Incluye dentro de otras las siguientes características:  Dentro de un proceso de sistema intensivo, un método es aplicado para llegar o evolucionar un sistema  Como un lenguaje, es usado para la comunicación. Es decir, un medio para capturar el conocimiento (semánticas) respecto a un tema y expresar el conocimiento (sintaxis) resguardando el tema propósito de la comunicación. El tema es el sistema en estudio.  Como un lenguaje para modelamiento, se enfoca en la comprensión de un tema a través de la formulación de un modelo del tema (y su contexto respectivo). El modelo abarca el conocimiento cuidando del tema, y la apropiada aplicación de este conocimiento constituye inteligencia.  Cuidando la unificación, integra las mejores prácticas de la ingeniería de la industria tecnológica y sistemas de información pasando por todos os tipos de sistemas (software y no - software), dominios (negocios versus software) y los procesos de ciclo de vida.  En cuanto a cómo se aplica para especificar sistemas, puede ser usado para comunicar "qué" se requiere de un sistema y "cómo" un sistema puede ser realizado.  En cuanto a cómo se aplica para visualizar sistemas, puede ser usado para describir visualmente un sistema antes de ser realizado.  En cuanto a cómo se aplica para construir sistemas, puede ser usado para guiar la realización de un sistema similar a los "planos".  En cuanto a cómo se aplica para documentar sistemas, puede ser usado para capturar conocimiento respecto a un sistema a lo largo de todo el proceso de su ciclo de vida. UML no es:  Un lenguaje de programación visual, sino un lenguaje de modelamiento

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

visual   Una herramienta o depósito de especificación, sino un lenguaje para modelamiento de especificación. Un proceso, sino que habilita procesos.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 37. ¿Método o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método. Elementos de UML: Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución. Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología. Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario. Utilidad de UML UML es un lenguaje para modelamiento de propósito general evolutivo, ampliamente aplicable, que puede ser soportado por diferentes herramientas e industrialmente estandarizado. Se aplica a una multitud de diferentes tipos de sistemas, dominios, y métodos o procesos.  Como lenguaje de propósito general, se enfoca en el corazón de un conjunto de conceptos para la adquisición, compartición y utilización de conocimientos emparejados con mecanismos de extensión.  Como un lenguaje para modelamiento ampliamente aplicable, puede ser aplicado a diferentes tipos de sistemas (software y no - software), dominios (negocios versus software) y métodos o procesos.  Como un lenguaje para modelamiento soportable por herramientas, las herramientas ya están disponibles para soportar la aplicación del lenguaje para especificar, visualizar, construir y documentar sistemas.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

 Como un lenguaje para modelamiento industrialmente estandarizado, no es un lenguaje cerrado, propiedad de alguien, sino más bien, un lenguaje abierto y totalmente extensible reconocido por la industria.  Mejores tiempos totales de desarrollo (de 50 % o más).  Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.  Establecer conceptos y artefactos ejecutables.  Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.  Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.  Mejor soporte a la planeación y al control de proyectos.  Alta reutilización y minimización de costos. UML posibilita la captura, comunicación y nivelación de conocimiento estratégico, táctico y operacional para facilitar el incremento de valor, aumentando la calidad, reduciendo costos y reduciendo el tiempo de presentación al mercado; manejando riesgos y siendo proactivo para el posible aumento de complejidad o cambio.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 38. Una perspectiva de UML
Las siguientes secciones presentan una vista más detallada al modelado con UML. Un sistema de reserva de aerolíneas simple se va a usar para mostrar los diagramas y técnicas de modelado con UML. Se cubren los siguientes puntos:  Organizando tu sistema con paquetes  Modelando con Casos de Uso, y usándolos para averiguar los requisitos del sistema  Modelando con Diagramas de Secuencia y Colaboración  Analizando y diseñando con el Diagrama de Clase, y extendiendo UML con la técnica de las tarjetas CRC  Modelando comportamiento con Diagramas de Actividad y de Estado  Modelando componentes de software, distribución e implementación  Extendiendo UML con el diseño de Bases de Datos relacionales Una de las tareas clave para modelar un sistema de software de grandes dimensiones es dividirlo primero en áreas manejables. Aunque estas áreas se llaman dominios, categorías o subsistemas, la idea es la misma: dividir el sistema en áreas que tengan competencias parecidas. UML introduce la noción de un paquete como el ítem universal para agrupar elementos, permitiendo a los modeladores subdividir y categorizar sistemas. Los paquetes pueden ser usados en cualquier nivel, desde el nivel más alto, donde son usados para subdividir el sistema en dominios, hasta el nivel más bajo, donde son usados para agrupar casos de uso individuales, clases, o componentes. Ver fig.34

Figura 34: Organizando el sistema mediante el uso de paquetes

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Modelado de Casos de Uso Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en particular requisitos funcionales. El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione. No es realmente una aproximación a la orientación a objetos; es realmente una forma de modelar procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casos de uso son generalmente el punto de partida del análisis orientado a objetos con UML. El modelo de casos de uso consiste en actores y casos de uso. Los actores representan usuarios y otros sistemas que interaccionan con el sistema. Se dibujan como "muñecos" de palo. Actualmente representan el tipo de usuario, no una instancia de usuario. Los casos de uso representan el comportamiento del sistema, los escenarios que el sistema atraviesa en respuesta a un estímulo desde un actor. Se dibujan como elipses. Use Case Description in S1ep Form 1.Passenger rec&ests "Honre are ffightirom ticket vendar. 2.Ticket vendor créete possible avaüaJiifity frorr\ Airline 7~~"—- classes or class attributes. __ - Verbs are possible operations .

3.Airline says ticket is available; provtáe sflight details. Figura 35: Modelado de Casos de Uso. 4.Ticket vendor praw'ftes passenger wrth flight details. 5.Passenger reo/üesísseat preference. G. Ticket vendor jbooteseai. 7.Ticket vendor cof/fifms resé

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Cada caso de uso se documenta por una descripción del escenario. La descripción puede ser escrita en modo de texto o en un formato paso a paso. Cada caso de uso puede ser también definido por otras propiedades, como las condiciones pre- y post- del escenario --- condiciones que existen antes de que el escenario comience, y condiciones que existen después de que el escenario se completa. Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. Ver fig. 35

Estudiar y descubrir los requisitos El objetivo final en cualquier diseño de software es satisfacer los requisitos del usuario para el sistema. Estos requisitos pueden ser requisitos de software, requisitos de productos, o requisitos de pruebas. La meta de capturar y comprobar los requisitos del usuario es asegurar que todos los requisitos son completados por el diseño, y que el diseño es acorde con los requisitos especificados. Muchas veces los requisitos del sistema ya existen en forma de documentos de requisitos. Los casos de uso se utilizan para correlacionar cada escenario con los requisitos que completa. Si los requisitos no existen, modelar el sistema a través de los Casos de Uso, permite el descubrimiento de estos requisitos. Organización de Diagramas de Casos de Uso Durante el análisis de negocio (business) del sistema, puedes desarrollar un modelo de caso de uso para este sistema, y construir paquetes para representar los varios dominios de negocio (business) del sistema. Puedes descomponer cada paquete con un Diagrama de Caso de Uso que contenga los Casos de Uso de un dominio, con interacciones de actor. Modelar secuencias (extends) alternas a través de la relación "Extiende"

Típicamente, uno modela cada Caso de Uso con una secuencia normal de acciones. El usuario entonces considera condiciones "que si" para cada paso, y desarrolla Casos de Uso basados en estas secuencias alternas de eventos. Las secuencias alternas se modelan en casos de uso separados, los cuales están relacionados con el caso de uso original mediante una relación "Extiende" (extends). Las relaciones Extiende (extends) pueden ser pensadas como un caso de uso equivalente a herencia, en el cual el caso de uso extendido, hereda y modifica el comportamiento del caso de uso original. Eliminar el modelado redundante a través de la relación "Usa" (uses)

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Para eliminar el modelado redundante de buena parte del comportamiento que aparezca en varios casos de uso, la parte del comportamiento puede ser modelada en un caso de uso separado que está relacionado con los otros casos de uso mediante la relación "Usa" (uses). La relación Usa (uses) se puede pensar como un caso de uso equivalente. Ver fig. 36.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 36: Relación caso de uso Extiende (extends) frente a relación de caso Usa (uses).

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 39. Diagramas de Secuencia
El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de una vista 'business' del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Ver fig. 37.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 37: Diagrama de Secuencia para un escenario

Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la case instan ciada por el objeto en la recepción final del mensaje.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 40. Diagramas de Colaboración
El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario. Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas, ver fig. 38. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con respecto a los otros.

Figura 38: Diagrama de Colaboración para un grupo de Objetos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Capítulo 9. Modelado con UML
Lección 41. Modelando el comportamiento de las Clases con Diagramas de Estado
Mientras los diagramas de interacción y colaboración modelan secuencias dinámicas de acción entre grupos de objetos en un sistema, el diagrama de estado se usa para modelar el comportamiento dinámico de un objeto en particular, o de una clase de objetos. Un diagrama de estado se modela para todas las clases que se consideran con un comportamiento dinámico. En él, modelas la secuencia de estado que un objeto de la clase atraviesa durante su vida en respuesta a los estímulos recibidos, junto con sus propias respuestas y acciones. Por ejemplo, un comportamiento de un objeto se modela en términos de en qué estado está inicialmente, y a qué estado cambia cuando recibe un evento en particular. También modelas qué acciones realiza un objeto en un estado en concreto. Los estados representan las condiciones de objetos en ciertos puntos en el tiempo. Los eventos representan incidentes que hacen que los objetos pasen de un estado a otro. Las líneas de transición describen el movimiento desde un estado hasta otro. Cada línea de transición se nombre con el evento que causa esta transición. Las acciones ocurren cuando un objeto llega a un estado. Ver fig. 39.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 39: Modelando Comportamiento Dinámico de un objeto 'Vuelo' con un diagrama de estado

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 42. Diagramas de Actividad
El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito que se usa para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado. Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es que los diagramas de actividad pueden mostrar procesado paralelo (parallel processing). Esto es importante cuando se usan diagramas de actividad para modelar procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes. Usando Diagramas de Actividad para modelar Casos de Uso Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. Se pueden usar como un añadido a una descripción textual del caso de uso, o para listar los pasos del caso de uso. Una descripción textual, código, u otros diagramas de actividad pueden detallar más la actividad. Usando Diagramas de Actividad para modelar Clases Cuando se modela el comportamiento de una clase, un diagrama de estado de UML se suele usar normalmente para modelar situaciones donde ocurren eventos asincrónicos. El diagrama de actividad se usa cuando todos o la mayoría de los elementos representan el desarrollo de los pasos dados por las acciones generadas internamente. Ver fig. 40. Deberías asignar actividades a las clases antes de terminar con el diagrama de actividad.

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Figura 40: Diagrama de Actividad

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 43. Modelando Componentes de Software
El Diagrama de Componentes se usa para modelar la estructura del software, incluyendo las dependencias entre los componentes de software, los componentes de código binario, y los componentes ejecutables. En el Diagrama de Componentes modelas componentes del sistema ver fig. 41, a veces agrupados por paquetes, y las dependencias que existen entre componentes (y paquetes de componentes).

Figura 41: Modelando componentes con el Diagrama de Componentes

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 44. Modelando la Distribución y la Implementación
Los Diagramas de Implementación se usan para modelar la configuración de los elementos de procesado en tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos. En el diagrama 'deployment', empiezas modelando nodos físicos y las asociaciones de comunicación que existen entre ellos. Para cada nodo, puedes indicar qué instancias de componentes viven o corren (se ejecutan) en el nodo. También puedes modelar los objetos que contiene el componente. Los Diagramas de Implementación ver fig. 42, se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado. Puedes también modelar componentes que migran de nodo a nodo u objetos que migran de componente a componente usando una relación de dependencia con el estereotipo 'becomes' (se transforma)

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Lección 45. Diseño de Bases de Datos Relacionales -- Una extensión informal de UML
El Diagrama de Clase presenta un mecanismo de implementación neutral para modelar los aspectos de almacenado de datos del sistema. Las clases persistentes, sus atributos, y sus relaciones pueden ser implementados directamente en una base de datos orientada a objetos. Aun así, en el entorno de desarrollo actual, la base de datos relacional es el método más usado para el almacenamiento de datos. Es en el modelado de esta área donde UML se queda corto. El diagrama de clase de UML se puede usar para modelar algunos aspectos del diseño de bases de datos relacionales, pero no cubre toda la semántica involucrada en el modelado relacional, mayoritariamente la noción de atributos clave que relacionan entre sí las tablas unas con otras. Para capturar esta información, un Diagrama de Relación de Entidad (ER diagram) se recomienda como extensión a UML. El Diagrama de Clase se puede usar para modelar la estructura lógica de la base de datos, independientemente de si es orientada a objetos o relacional, con clases representando tablas, y atributos de clase representando columnas. Si una base de datos relacional es el método de implementación escogido, entonces el diagrama de clase puede ser referenciados a un diagrama de relación de entidad lógico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades lógicas y a sus atributos; el modelador dispone de varias opciones sobre cómo inferir asociaciones en relaciones entre entidades. Las relaciones de herencia son referenciadas directamente a super-sub relaciones entre entidades en un diagrama( ver fig. 43) de relación de entidad (ER diagram).

Figura 43: Extensión de UML -- Diseño de Bases de Datos Relacionales con el Diagrama de Relación de Entidad (ER Diagram) Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el proceso de determinar cómo el modelo relacional encaja; y qué atributos son claves primarias, claves

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

secundarias, y claves externas basadas en relaciones con otras entidades. La idea es construir un modelo lógico que sea conforme a las reglas de normalización de datos. Al implementar el diseño relacional, es una estrategia encaminada a hacer referencia al diagrama de relación de entidad lógico a un diagrama físico que represente el objetivo, el RDBMS. El diagrama físico puede ser denormalizado para lograr un diseño de base de datos que tiene tiempos eficientes de acceso a los datos. Las relaciones super-sub entre entidades se resuelven por las estructuras de tablas actuales. Además, el diagrama físico se usa para modelar propiedades específicas de cada fabricante para el RDBMS. Se crean varios diagramas físicos si hay varios RDBMSs siendo 'deployed'; cada diagrama físico representa uno de los RDBMS que son nuestro objetivo. Ver fig. 44

Figura 44: Relaciones clave entre entidades en un Diagrama de Relación de Entidad Consultas orientadas a objetos

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

Los lenguajes de programación orientados a objetos requieren que toda la interacción con objetos sea mediante envío de mensajes. Esto presenta serias limitaciones en las aplicaciones de bases de datos. Considérese el ejemplo del diseño de sistema de computadores y la consulta “Encontrar todos los sistemas de computadores que utilicen chips vendidos por Oldblock Corporation”. Si seguimos estrictamente el modelo de la programación orientada a objetos, se deberá enviar un mensaje a cada instancia de la clase Chip para verificar su valor vendedor. Si tratáramos esta solicitud como un problema de la base de datos, esperaríamos que existiera un índice para la clase Chip para las cuales el campo vendedor fuera “Old-block Corporation”. La última forma de cómo se va a tratar la consulta corresponde a una vista relacional de la base de datos de objetos que vimos. De hecho, podríamos plantear consultas que implicasen intersecciones de conjuntos de objetos. Sin embargo, la vista relacional de objetos está limitada a variables, y gran parte de que el modelo orientado a objetos sea tan atractivo se debe al uso de los métodos. Así, un lenguaje de consultas para un sistema de base de datos orientado a objetos debe incluir tanto el modelo de pasar el mensaje de objeto en objeto (un objeto cada vez) como el modelo de pasar el mensaje de conjunto en conjunto en conjunto (un conjunto cada vez). La mezcla del proceso con los dos modelos conduce a serias complicaciones en el diseño del lenguaje, a menudo conocido como “impedancia desajustada”.

Referencias BATINI C.; Ceri S.; Navathe S. Diseño conceptual de bases de datos. Un enfoque de entidades-interrelaciones. 1994. Ed. Addison-Wesley. CASTAÑO A.; Piattini M. Fundamentos y modelos de bases de datos. 1999. Ed. Alfaomega. Segunda edición. CERI S, Pelagatti G.,Distributed databases principles & systems.. Ed. MacGraw-Hill. 1985. DATE, C. J, Introducción a los sistemas de bases de datos. Ed. Prentice Hall. Séptima edición. DORSEY, P, Hudicka Oracle8. Diseño de bases de datos con UML. J. Ed. Oracle press. 1999. KROENKE,D. Procesamiento de bases de datos. Fundamentos, diseño e implementación. 2003. Ed. Pearson Education. Octava edición SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGraw-Hill. Cuarta edición

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD Escuela de Ciencias Básicas, Tecnología e Ingeniería Programa Ingeniería de sistemas Curso 301125 – Bases de datos avanzadas Guía de componente práctico

OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill. ULLMAN, J Principles of database systems, Ed. Computer science press, 1982.