Base_de_datos_avanzada_v3

5/14/2018 Base_de_datos_avanzada_v3 - slidepdf.com

http://slidepdf.com/reader/full/basededatosavanzadav3 1/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 avanzadasGuí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







La primera versión de este documento fue escrita por el ingeniero Rogelio VásquezBernal, posteriormente ha sido actualizado por otros profesionales, docentes de laUNAD, cuyos nombres no fueron registrados. Esta versión del documento ha sidoeditada por Anívar Chaves Torres.

Este documento fue preparado para estudiantes de Ingeniería de sistemas de la Unad yse acoge a la licencia Creative Commons 3.0. En consecuencia, se permite su uso confines académicos, siempre que se reconozca el crédito al autor. Se prohíbe lareproducción, por cualquier medio, con fines comerciales.

Los ejemplos y ejercicios han sido diseñados exclusivamente con fines didácticos, elautor, el editor y la universidad no asumen ninguna responsabilidad por la aplicación delos mismos en con propósitos diferentes a la comprensión de los temas de este curso.







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







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







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 deUML .................................................................................................................................... 154







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 sistemade 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 elestudiante, 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







Protocolo

Introducción

El curso de Bases de datos Avanzada hace una revisión acerca de diversasaplicaciones, 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 datosy 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 dededicación independiente, investigando, leyendo, interiorizando los conceptos,desarrollo de actividades colaborativas con otros compañeros de curso; 36 horas deacompañamiento tutorial, donde se resuelven dudas, se apoya el proceso individual yde grupo.

El curso pretende:

Conocer otros tipos de modelos de datos.

Determinar las condiciones, necesidades, ventajas y desventajas de los diferentes tiposde 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 deinformación. Aunque el sustento teórico sigue siendo el mismo, las realidades de laempresa, las aplicaciones de la información almacenadas en las bases de datos, comosoporte decisional, las inclusión de los objetos en el mundo planificado y pensado pararegistros planos, hace de este curso importante para ver otras realidades y retos en eldesarrollo 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 deldesarrollo, monitoreo y aplicación de procesos de pensamiento.

Comunicativa: Capacidad de comprender, expresar mensajes y de desarrollar procesosargumentativos, 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 lacalidad de vida de la población.

Valorativa: Capacidad de apropiarse de valores como el respeto a la vida y a las ideasde los demás; la dignidad humana, la convivencia, la solidaridad, la tolerancia y lalibertad que orientan las acciones del individuo como persona, como ser social y comoprofesional.

Para el logro de éstas competencias, es necesario que se planifique de maneraresponsable 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 fuentesdocumentales (consultas en bibliotecas, Internet, bibliografía recomendada, consulta abases de datos documentales, entre otros)

Trabajo en grupos colaborativos: Creación de grupos de estudio o discusión con elpropó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 nuevamenteel 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 laautoevaluación, coevaluación y heteroevaluación.

Se entiende por autoevaluación, el proceso autocritico, donde el estudiante determinasi 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 suscompañeros.

Por último, una vez el estudiante ha pasado los filtros necesarios para garantizar lascompetencias básicas del curso, se presenta ante los procesos de evaluaciónpropuestos por el tutor.







Intensionalidades formativas

Propósitos

El curso pretende definir un marco de trabajo que facilite el desarrollo de conocimientosalrededor de los temas propuestos

Reconocer la existencia de modelos de datos y sus implicaciones en los sistemas deinformación

Determinar cuando se deben usar las estructuras de bases de datos definidas en elcurso académico

Objetivos

Reconocer las ventajas de las bases de datos en los procesos de análisis deinformación y como herramienta para la toma de decisiones.

Entender el modelo de bases de datos distribuido, sus ventajas, desventajas ylas posibilidades del modelo sobre la plataforma de alta velocidad de trasmisión.

Conocer y aplicar los conceptos de bodegas de datos, como herramientaindispensable para almacenar información que facilite procesos de análisis ytoma de decisiones

Conocer las técnicas de minería de datos, sus aplicaciones y los resultadosobtenidos.

Reconocer los conceptos básicos de un sistema de base de datos orientado aobjetos, el modelo de datos, sus ventajas, desventajas y aplicaciones.

Metas

Que el estudiante refuerce los conocimientos de bases de datos relacionales, eluso 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 sistemasde bases de datos transaccionales, bodegas de datos y modelos de datosorientados 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 contenidodel curso a través del desarrollo, monitoreo y aplicación de procesos de pensamiento.







Comunicativa: Capacidad de comprender, expresar mensajes y de desarrollar procesosargumentativos, 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 ladisposición y capacidad para aplicarlo en procesos de transformación que inciden en lacalidad de vida de la población.

Valorativa: Capacidad de apropiarse de valores como el respeto a la vida y a las ideasde los demás; la dignidad humana, la convivencia, la solidaridad, la tolerancia y lalibertad que orientan las acciones del individuo como persona, como ser social y comoprofesional.

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ónde datos y SQL.

Unidad I.

Bases de datos distribuidas, que son, modelo de datos Entidad Relación, fragmentacióny replicación, transacciones, consultas y catalogo distribuido.

Unidad II.

Bodegas de datos, que son, modelo relacional, modelo copo de nieve. Carga de datosy minería de datos.

Unidad III

Bases de datos orientadas a objeto. Objetos, propiedades, diseño de objetos UML,

SQL.







Estructura del curso

Contexto teórico

El curso de bases de datos avanzada, se ha pensado como un curso electivo quequiere 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ónque han reactivado ese tipo de proyectos.

De otro lado, hoy en día los sistemas de bodegas de datos tienen un espacio claro enla 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, esimportante 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, esimportante que se planifique de manera responsable el proceso de aprendizaje







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 conocimientosprevios del estudiante, por lo tanto la función didáctica consiste en crear actividadesmediante las cuales se identifican los propósitos del curso, sus intencionalidades y sepresenta el desarrollo del curso. Esta fase puede desarrollarse de manera individual através del estudio del protocolo del curso, el modulo y las fuentes documentalessuministradas 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 actividadespreviamente planificadas conducentes al dominio de conceptos y competencias deordenes diferentes, se han definido los siguientes propósitos de formación:

Trabajo personal: desarrolladas por el estudiante, a través de: estudio delmaterial sugerido en el curso académico, consulta de fuentes documentales(bibliografía de documentos impresos en papel: libros y revistas; bibliografía dedocumentos situados en Internet; direcciones de sitios Web de informaciónespecializada y bibliotecas)

Trabajo en grupo: desarrolladas por estudiantes a través de pequeños gruposcolaborativos de carácter obligatorio, con el propósito de: socialización deltrabajo 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 elintercambio 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 lacomunicación, tales como: correo electrónico, salas de conversación, foros dediscusión, el teléfono y Chat; también se puede complementar con encuentrospresenciales.

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 yprofundización que se elaboren ensayos, evaluaciones, mapas conceptuales ytalleres 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 demanera necesaria al principio de autonomía y generaran en el estudiante competenciaspara la realización de procesos de auto evaluación, coevaluación y heteroevaluación. Acontinuación se indica cada uno de estos procesos:







Autoevaluación: Es aquella que realiza el mismo estudiante, donde a medida que vaestudiando, se va planteando preguntas que el mismo las resuelve. De esta forma elestudiante hace su propio seguimiento, identificando avances y dificultades, lo quehace el proceso de autoaprendizaje muy dinámico y participativo. Este tipo deevaluación NO tiene ponderación en la valoración del curso, solo es una forma deidentificar fortalezas, oportunidades, debilidades y amenazas en el proceso deaprendizaje.

Coevaluación: Cuando el estudiante realiza estudio en grupo colaborativo, loscompañeros pueden valorar los avances, por medio de la Coevaluación, en ésta loscompañ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. LaCoevaluación es un espacio para desarrollar habilidades comunicativas y NO tieneponderación en la valoración del curso.

Heteroevaluación: Es aquella preparada por el Tutor o por el Docente Titular delCurso, para hacer el seguimiento al rendimiento académico de los estudiantes, sepuede 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 laUNAD 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 siguienteforma:

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%).







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 paraun nivel más avanzado.

Los temas aquí tratados requieren de un buen conocimiento de bases de datos y ungran deseo por profundizar cada uno de ellos en la bibliografía y cibergrafíarecomendada.

Los estudiantes deben trabajar el modulo acompañado de la guía de actividades y delprotocolo académico para lograr así el propósito del curso académico.

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







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. Elmodelo entidad relación en su forma más simple implica identificar asuntos importantesdentro de la organización (entidades) , propiedades de esos asuntos (atributos) y comose relacional entre si (relación). Esto tiene valor solamente dentro del contexto de loque se realiza en la empresa y en la forma de actuar de estas funciones de gestiónsobre 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 ymétodo de acceso, que permita tomar decisiones de las técnicas de implementación ycoexistencia 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 lasnecesidades de información. A continuación se indican diez temas clave que senecesitan 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ónsatisfactoria 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 elcompromiso de la dirección.

Convenciones

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

Definición mínima







Se debería definir o modelar cualquier información o concepto de datos sólo deuna forma, y a continuación configurar asociaciones para los objetosrelacionados. Como por ejemplo, se debería definir una vez una cosadenominada “Pedido de compra” y a continuación relacionarlo con eldepartamento, 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 seanindependientes de cualquier almacenamiento final o método de acceso y quenos permita tener una visión creativa y objetiva de la empresa y del diseñosubsiguiente.

Patrones genéricos

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

Actitud y calidad

Los modelizadores deben comenzar aplicar las convenciones automáticas yvelozmente, 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 ellospuedan entender aunque debe seguir siendo técnicamente riguroso. Estastécnicas de modelización se han utilizado durante muchos años para ayudar aaltos ejecutivos, directores y a otros a comprender su gestión. Es esencialutilizar un lenguaje claro, sin abreviaturas, para lograr su comprensión. Con unusuario final no deberíamos utilizar la palabra entidad.

Relevancia

Los requisitos de información solamente pueden tener valor si aportan lasnecesidades funcionales de la organización, dentro del marco de trabajo de losobjetivos y propósitos de la empresa.

Un medio, no un fin







Aunque el modelo entidad relación es muy potente, ofrecer una idea increíblede 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 loselementos del modelo

Es un modelo que se implementa directamente en el computador







Lección 2. Elementos del Modelo entidad relación

El modelo entidad relación para ser funcional requiere de la definición de unoselementos, los cuales se precisan a continuación:

Entidad

Se define como entidad a cualquier objeto real o abstracto, que existe en un contextodeterminado 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 unrecuadro y en su interior un nombre. El nombre se muestra en singular y con letrasmayúsculas (figura 1).

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 lasdemás instancias de ese tipo de entidad.

Relación

Se entiende por relación a la asociación, vinculación o correspondencia entreentidades. Por ejemplo entre la entidad PROFESOR y la entidad CURSO podemosestablecer la relación IMPARTE porque el profesor imparte cursos.

Una relación es binaria en el sentido de que es siempre una asociación entreexactamente dos entidades, o entre una entidad y ella misma. Cada relación tiene dosextremos, 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 debendefinir ambos extremos.

Figura1. Representación de entidad







Representación de una relación: Una relación se representa mediante una línea queune dos recuadros de entidades, o recursivamente (recurrentemente) une un recuadrode entidad consigo mismo.

La relación es una función que indica por cada elemento de la relación A cuantoselementos dependen en la relación B. Los valores se dividen en dos (2) y se conocencomo cardinalidad de la relación (Figura 2).

El primer valor, denominado cardinalidad mínima, indica el menor número deelementos en esa relación; generalmente ese valor puede ser 0 ó 1. Si el valor es 0, sedice que la relación es opcional y la gráfica de la relación se presenta con un circulo enla terminación de la relación ó se hace con una línea punteada. Si el valor es 1, se diceque la relación es obligatoria, la cual se presenta en la terminación de la relaciónmediante una línea perpendicular o mediante una línea continua.

El segundo valor de la cardinalidad, cardinalidad máxima, indica la cantidad máximade registros de la relación B por cada valor de la relación A; generalmente son valores1, 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ónrecursiva, por ejemplo, jefe y empleado.







Figura 3. Relación recursiva

Nombre de las relaciones: El nombre de cada extremo de una relación se sitúa cercaal 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 parapreceder al nombre final de la relación; para los nombres finales opcionales de larelación se utiliza la frase “puede ser”

Figura 5. Ejemplo nombre relaciones







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 puedeobservar 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 poseelos mismos atributos, tanto en nombre como en número, diferenciándose cada uno delos ejemplares por los valores que toman dichos atributos. Ejemplo si consideramos laentidad PROFESOR y definimos los atributos Nombre, Teléfono, Salario; podríamosobtener 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, yde 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.







Figura 7. Atributos candidatos

En la gráfica, por cada tiquete debe tenerse un código y una fecha expedición. Paraese 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 deembarque, 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 unatarjeta 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 derepresentar una relación. Por el contrario, cuando se encuentran estas situaciones hayque 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 entredos y ocho atributos. Si se tienen más, probablemente existirán muchas relaciones y/oentidades perdidas.







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íaredundante, ya que el atributo sólo describe la entidad. En el ejemplo anterior, el “elnúmero asiento” realmente ayudó a identificar una entidad perdida llamada ASIENTOque 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 lasdos 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 sonesenciales muchos valores, se debe crear una entidad nueva para mantenerlos en larelación muchos a uno unidos con la entidad original.







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 generalmentereflejan 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 suspropias relaciones y atributos.

Identificador único

Cada entidad debe ser identificable únicamente por una combinación de atributo y/orelación. De esta forma se podría buscar siempre cualquier atributo candidato queayude a identificar una entidad.

El valor del atributo debe ser dependiente de todo el identificador único. (segundaforma normal)

Figura 9. Un atributo repetido indica una entidad perdida.







Hay que quitar los atributos por los que los valores son dependientes sólo de parte delidentificador único. Esto se conoce como ’Segunda forma normal’ . Dichos atributosnormalmente suponen una entidad perdida, pero relacionada.

Los atributos deben ser dependientes directamente del identificador único (terceraforma 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 tresse profundizara el concepto de normalización.

Identificador único

Definición

Cada entidad debe ser únicamente identificable de forma que cada instancia de laentidad esté separada y sea claramente identificable de todas las otras instancias deese tipo de entidad. El identificador único puede ser un atributo, una combinación derelaciones o una combinación de atributos y relaciones.

Una entidad puede tener más de un medio alternativo de identificación única. El métodoprimario se puede mostrar en el diagrama entidad-relación antecediendo a un atributoque forme el identificador con una marca ‘#’ , y colocando una barra cruzada en el casode una (s) línea (s) de relación. Figura 11

Figura 11. Muestra de identificadores únicos







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 eldiagrama sea fácil de leer, aplicable para personas que necesiten trabajar con ellas ypara 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 losdiseñadores, es bueno crear un diagrama de subconjunto y expresar las ideas denuevo 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énalineados y que las líneas de las relaciones sean rectas en sentido horizontal overtical. Hay que dibujar el menor número de líneas cruzadas posible.

Hay que evitar Construir un diagrama que tenga demasiadas líneas paralelas queestén muy juntas. Hay que utilizar el mayor espacio en blanco que se pueda paraevitar el sentimiento de congestión y utilice de vez en cuando la línea en diagonal paraayudar a la estética del diagrama.







Reconocimiento de patrones

La mayoría de las personas tienen la capacidad incorporada de reconocer formas ypatrones en un instante y por tanto pueden recordar fácilmente el tema. Losmodelizadores pueden beneficiarse de esto haciendo que cada diagrama seaclaramente diferente en forma.

Texto

Hay que asegurarse de que el texto no sea ambiguo. Hay que evitar las abreviaturas ylas 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 diagramaentidad relación debería ser semánticamente completo. Para mejorar la comprensión yla 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écnicaha 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







Lección 3. Álgebra relacional

Es necesario que el lector se familiarice con el término “relación”, entendida en dosaspectos, en primer lugar cuando mencionamos esta palabra en el modelo entidadrelació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 lastablas son esencialmente relaciones.

El Álgebra relacional es un lenguaje de consulta procedural. Consta de un conjunto deoperaciones que toman como entrada una o dos relaciones y producen como resultadouna nueva relación, por lo tanto, es posible anidar y combinar operadores. Hay ochooperadores en el álgebra relacional que construyen relaciones y manipulan datos, estosson:

1. Selección 2. Proyección 3. Producto

4. Unión 5. Intersección 6. Diferencia

7. Join 8. División

Tabla 1 - Operadores del Álgebra relacional

Las operaciones de proyección, producto, unión, diferencia, y selección son llamadasprimitivas, 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 cualtrabajar para generar ejemplos de comandos y operadores. Para este efecto se incluyeun modelo básico de administración de Radio taxis. El Gráfico que se presenta acontinuación representa el Modelo conceptual (Modelo Lógico) o Diagrama de Entidad-Relación, (este adopta una metodología similar a la anterior):







Figura 14 - Esquema de Relaciones de Ejemplo

Los Esquemas de relaciones que se pueden construir a partir de este modelo son lossiguientes:

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 laletra griega sigma minúscula (σ) para señalar la selección. El predicado aparece comosubíndice de σ. La Relación que constituye el argumento se da entre paréntesisdespués de la σ.

Ejemplos :







2. Proyección

La operación de proyección permite quitar ciertos atributos de la relación, estaoperación es unaria, copiando su relación base dada como argumento y quitandociertas columnas, La proyección se señala con la letra griega pi mayúscula (Π). Comosubí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 unatupla 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.







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. Aligual que en teoría de conjuntos el símbolo U representa aquí la unión de dosrelaciones.

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 operacionesde 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.







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 larelación B produce el conjunto de todas las tuplas t tal que t es el encadenamiento deuna 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 losatributos 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 larelación B entregando como resultado una relación con grado m. El atributo m + i de Ay 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 aparececomo 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:







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ánal final del modulo como un anexo.

Autoevaluación

Los operadores Selección y Proyección son conocidos como operadores Unariosporque

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







Lección 4. Normalización de datos

La normalización de datos es un procedimiento que asegura que un modelo de datosse 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 elmodelo se estructure sobre una amplia variedad de diseños alternativos de base dedatos.

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 serepresentan en un diagrama por medio de un recuadro con el nombre de laentidad en singular y en mayúsculas.

ñadir las relaciones de gestión, las cuales se han nombrado como asociacionessignificativas entre entidades. Estas relaciones se muestran como una líneaentre dos recuadros; cada terminación tiene un grado (un triángulo oramificación que significa muchos; si no hay triángulo significa uno) y laopcionalidad (una línea de puntos significa opcional, una línea continua significaobligatorio).

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

ser identificada de forma única. Esto se hará mediante alguna combinación deatributos y/o relaciones. Cuando un atributo es parte del identificador único se

muestra con una marca #. Cuando una relación es parte del identificador únicose muestra mediante una barra cruzada cruzando la línea de relación. Elseguimiento del proceso anterior dará rigurosa y automáticamente un modelonormalizado, pero depende de la buena comprensión del analista acerca de loque es realmente un atributo, una relación y una entidad.







Normalización

Para comprobar que un modelo entidad-relación tiene todas sus entidadesunívocamente identificadas, se ha normalizado completamente y por tanto se ajusta ala 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 mismonombre, se define una entidad nueva, la cual se describe mediante ese atributo. Elidentificador único de esta nueva entidad consta de uno de los atributos que se fueroncon ella y la relación (de muchos a uno) se lleva a la entidad original.

Figura 15 Primera forma normal







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/orelació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 labase de una nueva entidad. La entidad nueva se identifica por la parte emigrada delidentificador único de la entidad original, y tiene una relación de uno a muchos unido ala 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 delidentificador único, entonces estos atributos deberían formar la base de la nuevaentidad, que tenga una relación de uno a muchos con la entidad original. Elidentificador único de la entidad nueva es el atributo del que depende el otro atributo. Acontinuación se presenta la representación de esta forma:







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 encualquier momento cada tupla (línea relacional) de R se compone de un valor claveprimario que identifica alguna identidad, junto con un grupo de cero o más valoresindependientes 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 sidonde quiera que haya una dependencia multivalores (MVD) en R, digamos Atodos los atributos de R son también funcionalmente dependientes de A. En otraspalabras, 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







También, “una relación R está en quinta forma normal (5NF), también denominadaforma 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 puramentepor razones de mejorar la realización de sistemas de producción, particularmentecuando están computarizados. La desnormalización sólo se debe realizar sobre eldiseño. No poner en peligro nunca el modelo de gestión.

La desnormalización en formas manuales de procedimientos es necesariamente muycomú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 problemasque se pueden originar cuando ese dato se cambia y se tiene que volver a emitir elgrupo 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







Lección 5. Transacciones

Una transacción es una unidad de la ejecución de un programa que accede yposiblemente actualiza varios elementos de datos. Se delimita dependiendo dellenguaje por las sentencias inicio transacción y fin transacción y se compone de todaslas 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 datostengan las propiedades llamadas ACID: (Atomicity, Consistency, Isolation, Durability -

Atomicidad, Consistencia, Aislamiento, Durabilidad [Silberschatz97]). A continuaciónexplicamos 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 elcual 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 unasde otras, de tal manera que cada una tiene la impresión de que ninguna otratransacció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), unatransacción que haya sido comprometida llevará a la base de datos a un nuevo estadoconsistente 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.







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 deque se pierda la consistencia de datos. Se hace necesario por lo tanto un sistema quecontrole la interacción entre las transacciones concurrentes. Puesto que una

transacción por definición conserva la consistencia, una ejecución lineal detransacciones la garantiza también. Un sistema que asegure esta propiedad se diceque 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 queha realizado la operación. Los más conocidos son los protocolos de bloqueo, elesquema 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 unatransacción puede bloquear o desbloquear un objeto de la base de datos. El protocolode bloqueo de dos fases permite que una transacción bloquee un objeto sólo despuésde que haya desbloqueado otro objeto distinto, este método asegura la secuencialidad.

El esquema de ordenación por marcas temporales asegura la secuencialidadseleccionando previamente un orden en todo par de transacciones. Existen 2 formas deimplementar este esquema, uno es por medio de valores timestamp (dependientes delreloj 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 cuantoa conflictos y la ausencia de interbloqueos, si una de las transacciones viola la norma latransacción se retrasa y se le asigna una nueva marca temporal. Por ejemplo, unaoperación leer se puede retrasar porque todavía no se ha escrito el valor apropiado oincluso 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 paratransacciones de sólo lectura y en las cuales la tasa de conflictos es baja. Se basa endividir una transacción en 3 etapas (lectura, validación y escritura) y trabajar con el







esquema de marcas temporales sobre la etapa de validación. De esta manera se quitauna 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 deconsistencia.

Una manera distinta manejar la concurrencia es por medio de la granularidad, esteconcepto permite agrupar varios elementos de datos y definirlos como un todo paraefectos de sincronización. Se define como una jerarquía de distintos niveles, donde elnivel superior puede representar toda la base de datos, se esquematiza comoestructura de árbol donde los nodos hijos de un nodo interno representan lasdependencias de datos asociadas. Se utilizan los tipos de bloqueos Compartidos yExclusivos más un nuevo tipo de bloqueo llamado el bloqueo intencional, el cual indicaque existen nodos descendientes que tienen bloqueos compartidos o exclusivos.

El esquema multiversión se basa en la creación de nuevas versiones de los elementosde datos cada vez que una transacción vaya a escribir dicho elemento. Cuando se va arealizar una escritura el sistema elige una de las versiones para que se lea. El esquemade control de versiones garantiza que la versión que se va a leer se elige de forma queasegure la secuencialidad por medio de marcas temporales. En este esquema unaoperación de lectura tiene éxito siempre, sin embargo, una operación de escriturapuede 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. Ental situación, ninguna de las transacciones puede progresar. Existen 2 métodos paratratar los interbloqueos y ambos provocan un retroceso de las transacciones, ladiferencia radica en que uno es preventivo y otro curativo. El protocolo de prevenciónde interbloqueos asegura que el sistema nunca llegará a un estado de interbloqueosmientras que el método de detección y de interbloqueos permite que el sistema llegue aun estado de interbloqueos para luego tratar de recuperarse. La prevención se usanormalmente cuando la probabilidad de que el sistema llegue a un estado deinterbloqueo es relativamente alta, de lo contrario lo más conveniente es usar ladetección y recuperación.

Seguridad y recuperación de datos

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







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 unexceso de recursos. Un error del sistema ocurre cuando el sistema se encuentra en unestado no deseado como en el caso de los interbloqueos.

software de base de datos. Comúnmente causa la pérdida del contenido de la memoriaprimaria y aborta el procesamiento de una transacción.

ólo sirve la recuperación por medio de copias existentesen medios de almacenamiento secundario como cintas magnéticas.

La forma más aceptada de lograr un tipo de almacenamiento lo más estable posible esreplicando la información en varios medios de almacenamiento no volátil, con modos defallos independientes. Los sistemas RAID (disposición redundante de discosindependientes) garantizan que el fallo de un sólo disco no conduzca a la perdida dedatos. Sin embargo los sistemas RAID, no pueden proteger al sistema de una pérdidade datos en el caso de una catástrofe geográfica, para tales efectos muchos sistemasde almacenamiento guardan copias de seguridad en cintas en otros lugares, noobstante, como las cintas no pueden ser trasladadas continuamente, los últimoscambios realizados luego del traslado de cintas no se pueden volver a recuperar en elcaso 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 deredes de computadores al sistema de respaldo remoto...

El estado de un sistema de base de datos puede no volver a ser consistente en caso deque ocurran fallos, para preservar la consistencia es necesario que cada transacciónsea atómica. Garantizar la propiedad de atomicidad es responsabilidad del esquema derecuperació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 demodificación diferida, durante la ejecución de una transacción, se difieren todas lasoperaciones 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 latransacción para ejecutar las escrituras diferidas. Con la técnica de modificacióninmediata todas las modificaciones se aplican directamente en la base de datos. Siocurre una caída se utiliza la información del registro histórico para llevar a la base dedatos a un estado estable previo.







Paginación en la sombra. Durante la vida de una transacción se mantienen 2 tablas depá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 yescritura utilizan la tabla de páginas actual, cuando una transacción se comprometeparcialmente se desecha la tabla de páginas sombra y la tabla actual se convierte en lanueva tabla de páginas. Si la transacción fracasa, simplemente se desecha la tablaactual de páginas.

El procesamiento de transacciones se basa en un modelo de almacenamiento en elcual 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 elsistema. 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 searealizado en almacenamiento estable. Los registros del registro histórico puedenguardarse 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 T i antes de grabar el registro que indique que latransacció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 seescriba desde la memoria intermedia a la base de datos.

Consultas

El Procesamiento de consultas hace referencia a la serie de actividades a seguir parallevar a cabo la recuperación de datos desde una base de datos. Estas actividadesincluyen la traducción de consultas en lenguajes de consultas de alto nivel (Ej: SQL) aexpresiones que se puedan implementar en un nivel físico, así como también losalgoritmos de evaluación y optimización de consultas.

Recuperación

Una de las ventajas principales del modelo relacional presentado por Codd en 1970 esla que tiene relación con la independencia de los datos que se entiende aquí como laseparación entre el modelo (lógico) y la implementación (física). Esta separación nospermite desarrollar una poderosa semántica lógica independiente de unaimplementación física particular.







Uno de los desafíos de la independencia de datos es que la codificación de unaconsulta 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 consultaa un medio de representación interno con el cual le sea fácil operar. Así, por ejemplopara SQL la representación más útil es la del álgebra relacional extendida (árbolrelacional). Este proceso cumple la misma función que el analizador léxico y sintácticode un compilador, es decir, revisa la sintaxis de la consulta y chequea que todos loidentificadores 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ólopuede ser entendido por el motor de ejecución de consultas. La transformación de laconsulta a un plan puede ser hecha efectivamente a mano y en algunos casos deconsultas 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 capacidadde usar la información del catalogo de la base de datos, que como se verá másadelante, 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 laconsulta que se quiere implementar, puesto que:

1. Un Plan calculado a mano (o un plan precalculado) será invalidado por cambioslógicos dentro del esquema o por cambios físicos en el camino de acceso a lainformación o en el almacenamiento físico.

2. Si los parámetros de la consulta (o los datos) cambian, la relación optima queasocia a un plan con una consulta por sobre otros puede cambiar.

La siguiente figura nos muestra los pasos en el procesamiento de una consulta.







Figura 17 - Pasos en el procesamiento de una consulta SQL

Después de enviar la consulta, la base de datos debe producir su correspondiente plande 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 laconsulta; 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; sinembargo, de igual forma podemos indicar que también esta basada en el cálculorelacional. Álgebra y cálculo son alternativos entre sí, la diferencia entre ellos es lasiguiente: 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 unprocedimiento específico para obtenerla. Las consultas en el cálculo relacional detuplas se expresan como:

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







{ 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 lalógica matemática. Así, si lo que se desea es el Nombre de los dueños de taxis queestén vigentes:

"Conjunto de todas las tuplas t tales que existe una tupla s en la relación Dueño para laque los valores de t y de s son iguales en el atributo Nombre y el valor de s para elatributo 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 losmóviles de marca “chevrolet”, la consulta requiere de dos cláusulas “Existe” conectadaspor 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, cuyosmóviles no hayan efectuado nunca un viaje”:







que ocupa la cláusula “Existe” para exigir que el dueño posea un móvil y la cláusula “noexiste” 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 implicaQ” significa que “si P es verdad entonces Q debe ser verdad”, se introduce elconstructor “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 recomiendaconsultar 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. Loslenguajes 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 eloptimizador generar diversos planes equivalentes para la consulta y elegir el menoscostoso.

Dado este nivel de generalidad, el optimizador puede ser visto como el generador decó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 talesefectos del catálogo de la base de datos, de donde obtiene información estadística delas relaciones referenciadas por la consulta, algo que los lenguajes de programacióntradicionales 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 ala expresión dada pero que sea más eficiente en la ejecución.







Con el fin de seleccionar la mejor estrategia para la recuperación de datos eloptimizador “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 poseede la tabla y que se ha rescatado previamente del catálogo de la base de datos, enrealidad el optimizador no siempre escoge el plan más óptimo, ya que encontrar laestrategia óptima puede consumir mucho tiempo, por lo tanto se dice que eloptimizador “sólo escoge una estrategia razonablemente eficiente”. La manera con laque el optimizador utiliza esa información, las distintas técnicas y algoritmos que aplicay las transformaciones algebraicas que se realizan son las que diferencian a losoptimizadores de bases de datos.

Un optimizador basado en el costo genera una serie de planes de evaluación para unaconsulta 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 laconsulta, sin embargo, es cuestión de cada SGBD el elegir las medidas de costo quemejor 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 latransacció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 leasigne timesptamp

Una transacción A no puede ver datos de una transacción B, mientras tengaabiertas 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éptimaedición.

SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGraw-Hill. Cuarta edición

OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill

www.lsi.us.es/docencia/asignaturas/dbd.html







www.cieloprogramadores.com







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 hapromovido un cambio en la forma de observar a los sistemas de información y, engeneral, a las aplicaciones computacionales. Existen avances tecnológicos que serealizan continuamente en circuitos, dispositivos de almacenamiento, programas ymetodologías. Sin embargo, los cambios tecnológicos van de la mano con la demandade los usuarios y programas para la explotación exhaustiva de tales dispositivosmejorados. Por tanto, existe un continuo desarrollo de nuevos productos los cualesincorporan 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 denuevos productos, para las aplicaciones existe una demanda permanente por mayor funcionalidad, mayor número de servicios, más flexibilidad y mejor rendimiento. Así, aldiseñar un nuevo sistema de información o al prolongar la vida de uno ya existente, sedebe 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 arquitecturaso formas de hacer las cosas es, sin lugar a dudas, el área de los sistemas distribuidosde información. Ellos se refieren al manejo de datos almacenados en facilidades decó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 dedatos 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 procesamientoautónomos (no necesariamente homogéneos) se interconectan por una red decomunicaciones 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 usadopara identificarlo. Entre los términos más comunes que se utilizan para referirse al







cómputo distribuido podemos encontrar: funciones distribuidas, procesamientodistribuido 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óndistribuida los elementos que se pueden distribuir son:

radas en una actividad deprocesamiento de información.

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 datoslógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitiosinterconectados por una red de comunicaciones (ver Figura18).

Un sistema de base de datos distribuida (SBDD) es un sistema en el cual múltiplessitios de bases de datos están ligados por un sistema de comunicaciones, de tal formaque, un usuario en cualquier sitio puede accesar los datos en cualquier parte de la redexactamente como si los datos estuvieran almacenados en su sitio propio.

Un sistema de manejo de bases de datos distribuidas (SMBDD) es aquel que seencarga del manejo de la BDD y proporciona un mecanismo de acceso que hace que ladistribución sea transparente a los usuarios. El término transparente significa que la







aplicación trabajaría, desde un punto de vista lógico, como si un solo SMBD ejecutadoen una sola máquina, administrara esos datos.

Un sistema de base de datos distribuida (SBDD) es entonces el resultado de laintegració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 necesariamenteun sistema de manejo de bases de datos y, en caso de que lo haga, éste es controladoy administrado por una sola computadora.

Un sistema de multiprocesamiento puede administrar una base de datos pero lo haceusualmente 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 propioSMBD pero actuando sobre una sola base de datos. Finalmente, una base de datos lacual reside en un solo sitio de una red de computadoras y que es accesada por todoslos nodos de la red no es una base de datos distribuida (Figura 19). Este caso se tratade una base de datos cuyo control y administración esta centralizada en un solo nodopero 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 loscuales tienen un sistema de procesamiento de datos completo que incluye una base dedatos 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







interconectados por una red de tipo WAN. Por otro lado, si los sitios están localizadosen 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 dedatos distribuidas, homogéneas y sistemas de bases de datos distribuidasheterogéneas.

La homogeneidad o heterogeneidad, puede darse a diferentes niveles, Hardware,Software o sistema operativo. Para este curso, se asume que cuando se indica lahomogeneidad 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 elmismo modelo de datos.

Un sistema de bases de datos distribuido, incluye diferentes sistemas manejadores debases de datos, probablemente con modelos de datos diferentes que hay quecompatibilizar y con retos a nivel de comunicación entre los sistemas de bases de datosque conforman el sistema, para dar la visión al usuario de integración y de un únicosistema de bases de datos.

Autoevaluación







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 dedatos

Aquella que incluye diferentes sitios

Aquella que incluye redes de datos







Lección 7. Bases de datos distribuidas

En el presente capítulo se mostrará los aspectos importantes referentes al diseño deuna base de datos distribuida. Se revisará el problema de fragmentación de los datosasí como la transparencia que un sistema de datos distribuidos debe guardar respectoa 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 estecapí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 sitiosde una red de computadoras. Este problema debería estar relacionado al diseño de lamisma red de computadoras. Sin embargo, en estas notas únicamente el diseño de labase de datos se toma en cuenta. La decisión de donde colocar a las aplicaciones tieneque ver tanto con el software del SMBDD (sistema manejador de base de datosdistribuidas) 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 basesde datos.

En el caso de las bases de datos distribuidas se tienen que considerar los problemassiguientes:

1. Diseño del “esquema conceptual”, donde se busca describir el modelo de datosde todo el sistema

2. Diseño de la fragmentación, este proceso se determina mediante la división delas tablas en fragmentos horizontales, verticales o mixtos, dependiendo de lasnecesidades 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 losfragmentos se mapean en los sitios o nodos del sistema.

4. Diseño de replicación. Proceso que indica en que lugar (nodos), se ubicancopias 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.







En el diseño de la distribución de los datos, se deben de tomar en cuenta los siguientesobjetivos:

Procesamiento local. La distribución de los datos, para maximizar el procesamientolocal corresponde al principio simple de colocar los datos tan cerca como sea posiblede las aplicaciones que los utilizan. Se puede realizar el diseño de la distribución de losdatos para maximizar el procesamiento local agregando el número de referenciaslocales y remotas que le corresponden a cada fragmentación candidata y la localizacióndel 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 lossitios, es una característica importante de los sistemas de cómputo distribuidos. Estadistribució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 deejecución de paralelismo de las aplicaciones. Sin embargo, la distribución de la cargade trabajo podría afectar negativamente el procesamiento local deseado.

Costo de almacenamiento y disponibilidad. La distribución de la base de datosrefleja el costo y disponibilidad del almacenamiento en diferentes sitios. Para esto, esposible tener sitios especializados en la red para el almacenamiento de datos. Sinembargo el costo de almacenamiento de datos no es tan relevante si éste se comparacon 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 dedatos distribuidas:

El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado paraaplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el análisisde requerimientos para definir el diseño conceptual y las vistas de usuario. A partir deellas se define un esquema conceptual global y los esquemas externos necesarios. Seprosigue con el diseño de la fragmentación de la base de datos, y de aquí se continúacon la localización de los fragmentos en los sitios, creando las imágenes físicas. Estaaproximació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 generaldel enfoque top-down.

El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de basesde datos existentes, generando con esto bases de datos distribuidas. En formaresumida, el diseño bottom-up de una base de datos distribuida requiere de la selecciónde un modelo de bases de datos común para describir el esquema global de la base dedatos. Esto se debe, a que es posible que se utilicen diferentes SMBD. Después se







hace la traducción de cada esquema local en el modelo de datos común y finalmentese 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, deberesponder 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?







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







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 paradistribuir 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 dedistribución? Se puede considerar que una relación completa es lo adecuado ya que lasvistas de usuario son subconjuntos de las relaciones. Sin embargo, el uso completo derelaciones no favorece las cuestiones de eficiencia sobre todo aquellas relacionadascon 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 deuna 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 fragmentonecesitarán un procesamiento adicional a fin de localizar todos los fragmentos de unavista. 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 losque se distribuyen todos los registros de la relación. En resumen, el objetivo de lafragmentación es encontrar un nivel de particionamiento adecuado en el rango que vadesde tuplas o atributos hasta relaciones completas (ver Figura 23 ).

Ejemplo 1. Considere una relación J del ejemplo visto en la introducción del presentecapítulo.

J:

JNO JNOMBRE PRESUPUESTO LUGAR

J1 Instrumentación 150000 Guajira







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 siguientesfragmentos.

J1: Proyectos con presupuesto menor que $200,000


J1 Instrumentación 150000 Guajira

J2 Desarrollo de bases de datos 135000 Cartagena

J2: Proyectos con presupuesto mayor que o igual a $200,000


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 verticalmenteproduciendo los siguientes fragmentos:

J1: información acerca de presupuestos de proyectos

JNO PRESUPUESTO

J1 150000

J2 135000

J3 250000

J4 310000







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 sedeben 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 enalgú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 = U 1 i <= n Ri

Condición de Fragmentos Disjuntos. Si la relación R se descompone en los fragmentosR1, R2, ..., Rn, y el dato di está en Rj, entonces, no debe estar en ningún otrofragmento Rk (k¹ j).

Alternativas sobre replicación para el asignamiento de fragmentos







La replicación de información es de utilidad para obtener un mejor rendimiento y paraofrecer 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 utilidadcuando 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 deimplementar o tomar ventaja de las diferentes alternativas de replicación, respecto delos diferentes aspectos importantes en bases de datos distribuidas.

Recopilacióncompleta

Recopilación Parcial Particionamiento

Procesamiento deConsultas

Fácil Moderado Moderado

Manejo de Directorios Fácil o no existente Moderado Moderado

Control de

Concurrencia

Moderado Difícil Fácil

Confiabilidad Muy alto Alto Bajo

Realidad Aplicación posible Realista Aplicación posible

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:







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







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 tiposmencionados. Más adelante, se presentará de manera más formal la construcción delos diferentes tipos de fragmentación.

Fragmentación horizontal primaria

Consiste del particionamiento en tuplas de una relación global en subconjuntos, dondecada subconjunto puede contener datos que tienen propiedades comunes y se puededefinir expresando cada fragmento como una operación de selección sobre la relaciónglobal.

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 solamentelos ú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ónhorizontal.







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 dela relación SUPPLY.

SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1


Fragmentación vertical

La fragmentación vertical es la subdivisión de atributos en grupos. Los fragmentos seobtienen 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ónvertical 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 seguidade 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







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 esquemafragmentado

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)



Autoevaluación

La fragmentación

se trabaja a nivel de tabla







Verdadero Falso







Lección 10. Diseño de replica

La replicación de información es de utilidad para obtener un mejor rendimiento y paraofrecer 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 suactualización en los periodos de tiempo definidos por el administrador del sistema.

La replicación se complica cuando es necesario hacer actualizaciones a las copiasmúltiples de un dato. Por tanto, respecto a la replicación, en la asignación defragmentos 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 utilidadcuando el número de consultas de solo lectura es (mucho) mayor que el número deconsultas para actualizaciones. En la Tabla 1 se comparan la complejidad deimplementar o tomar ventaja de las diferentes alternativas de replicación, respecto delos diferentes aspectos importantes en bases de datos distribuidas.

Además de indicar en que sitios se desea guardar copia de la entidad o tabla, esnecesario 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 lainformación a los sitios donde reside la copia.

2 Copia fuera de línea, esta opción permite que una vez registrada la transacciónen el sitio donde ella se genera, pueda pasar un tiempo para actualizar las copiasde la información almacenadas en otros lugares.

Con estos dos tipos de replicación, es posible definir varios modelos de sistemas dereplica:

1. Maestro - maestro, hace que una vez generada y registrada una transacción en unsitio del sistema, inmediatamente se actualicen las copias de la información que seguardan en los otros sitios. Este modelo, aumenta la opción de acceso a datos desdecualquier punto, aumentando la disponibilidad del sistema. El mayor problema de estemodelo es que debe garantizarse canales de comunicación entre los nodos en todomomento, de tal manera que se asegure la copia de los fragmentos cuando latransacción se realice, de lo contrario el sistema cae en un estado de invalidez deinformación.







2. Maestro-copia. Este modelo permite que la actualización de los sitios puedagenerarse en un periodo de tiempo T después de generarse una t transacción en unsitio 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 delsistema.

El modelo reduce costos de canal de comunicación, ya que este es requerido durantealgunos periodos de tiempo, durante el cual se realizan las actualizaciones a lasreplicas del sistema.

3. Maestro - bodega. Este modelo exige la determinación de un sitio, donde seguardará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 labodega 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 sitiode la bodega siempre se encuentre accesible

Autoevaluación

El modelo Maestro Bodega indica queCada vez que se modifique un dato en el Maestro, actualiza la información en elsitio de la bodega de datos

Cada vez que se modifique un dato en el Maestro, actualiza en todos los demássitios involucrados

Cada vez que se modifique un dato en el Maestro, solo se actualiza el sitiomaestro

Cada vez que se modifique un dato en el Maestro, se hace réplica







Capitulo 3. Consultas

Lección 11. Consultas distribuidas

El procesamiento de consultas es de suma importancia en bases de datoscentralizadas. Sin embargo, en BDD éste adquiere una relevancia mayor. El objetivo esconvertir transacciones de usuario en instrucciones para manipulación de datos. Noobstante, el orden en que se realizan las transacciones afecta grandemente lavelocidad de respuesta del sistema. Así, el procesamiento de consultas presenta unproblema 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 deuna 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 algoque 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 deencontrar la respuesta utilizando la estructura existente de la base de datos. Existe ungran número de estrategias posibles para procesar una consulta, especialmente si laestructura es compleja. No obstante, normalmente vale la pena que el sistema dediqueuna cantidad importante de tiempo en la selección de una buena estrategia. El coste deprocesar una consulta normalmente está dominado por el acceso al disco. Pero, en unsistema 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 deaccesos a disco requeridos y el coste de transmisión de datos en la red, a menudo esimportante, y puede tener varios órdenes de magnitud. Así pues, el tiempo empleadoen 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 elegirseuna estrategia de procesamiento de consultas que reduzca al mínimo el tiempo que serequiere para calcular la respuesta. En el caso de sistemas centralizados, el criterioprincipal para determinar el coste de una estrategia específica es el número de accesosal disco. En un sistema distribuido es preciso tener en cuenta otros factores, como son:







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 entrela memoria y el disco varía en forma considerable, dependiendo del tipo de red y de lavelocidad de los discos. Por tanto, en un caso general, no podemos tener en cuentasólo los costes del disco o los de la red. Es necesario llegar a un equilibrio adecuadoentre los dos.

Localización de datos

Consideremos una consulta muy sencilla: “Encontrar todas las tuplas de la relacióndepósito”. Aunque la consulta es muy simple, de hecho es trivial; su procesamiento noes trivial, ya que es posible que la relación depósito esté fragmentada, repetida o lasdos cosas. Si la relación depósito está repetida, es preciso decidir que copia se va autilizar. Si ninguna de las copias está fragmentada, se elige la copia que impliquecostes de transmisión más reducidos. Pero si una copia está fragmentada, la elecciónno es tan sencilla, ya que es preciso calcular varios productos o uniones parareconstruir la relación depósito. En tal caso, el número de estrategias para este ejemplosencillo puede ser grande. De hecho, la elección de una estrategia puede ser una tareatan compleja como hacer una consulta arbitraria.

La transparencia de la fragmentación implica que el usuario puede escribir una consultacomo é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







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 consultaes 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







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 L i y existen índices para

ellas, puede ser necesario volver a crear esos índices en L i. 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







Lección 12. Descomposición de una consulta y localización de datosdistribuidos

Antes de que pueda iniciarse el procesamiento de una consulta, el sistema debetraducir la consulta a una forma que pueda manejar. Los lenguajes como el SQL sonadecuados a las personas, pero no para ser la representación interna de una consultadentro del sistema. Una representación interna más útil es la que se basa en el álgebrarelacional.

La primera acción que el sistema debe tomar en una consulta es traducirla a su formainterna. 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 derelaciones 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 álgebrarelacional para calcular esa vista.

Una vez que se ha traducido la consulta a una forma interna del álgebra, empieza elproceso de optimización. La primera fase de la optimización se lleva a cabo en el niveldel álgebra relacional. Se hace un intento para encontrar una expresión que seaequivalente a la expresión dada, pero que pueda ejecutarse de manera eficiente. Lasiguiente fase implica la selección de una estrategia detallada para procesar laconsulta. Debe tomarse una decisión acerca de la manera exacta en que se va aejecutar la consulta. Se deben elegir los índices específicos que se van a usar. Se debedeterminar el orden en que se van a procesar las tuplas. La elección final de unaestrategia 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 larespuesta. Cada forma de expresar la consulta “sugiere” una estrategia para encontrar la respuesta. Sin embargo, no esperamos que los usuarios escriban sus consultas deuna forma que sugiera la estrategia más eficiente. Así pues, el sistema debeencargarse de transformar la consulta como la introdujo el usuario en una consultaequivalente que pueda calcularse de manera más eficiente. Esta “optimización”, o másexactamente, mejora de la estrategia para procesar una consulta se llama optimizaciónde consultas. Existe una analogía entre la optimización de consultas por un sistema debase de datos.

La optimización de consultas es una cuestión importante en cualquier sistema de basede datos puesto que la diferencia en tiempo de ejecución entre una buena estrategia yuna mala puede ser enorme. En el modelo de red y en el modelo jerárquico laoptimizació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







dos modelos normalmente se incorporan en un lenguaje de programación principal, yno es fácil transformar una consulta de red o jerárquica en una equivalente sinconocimiento del programa de aplicación completo.

Ya que una consulta relacional puede expresarse completamente en un lenguaje deconsulta 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 completamenteconsideradas 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 prontocomo determine que el coste es mayor que la mejor de las estrategias consideradasanteriormente. Si el optimizador empieza con una estrategia que es probable que tengaun 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 envarias subconsultas. Esto no sólo simplifica la selección de estrategias sino quetambién permite al optimizador de consultas reconocer los casos en los que unasubconsulta determinada aparezca varias veces en la misma consulta. Si esassubconsultas se calculan una sola vez, se ahorra tiempo tanto en la fase deoptimización de la consulta como en la ejecución de la consulta. El reconocimiento desubconsultas comunes es análogo al reconocimiento de subexpresiones comunes enmuchos 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 elprocesamiento de consultas. Sin embargo, el coste adicional de optimización deconsultas generalmente se compensa con creces por el ahorro en el tiempo deejecución de la consulta. El ahorro logrado es aún mayor en aquellas aplicaciones quese ejecutan sobre una base regular y vuelven a ejecutar las mismas consultas en cadaejecución. Por tanto, la mayor parte de los sistemas comerciales incluyen optimizadoresrelativamente sofisticados.

Autoevaluación

Todo Sistema Manejador de Bases de Datos incluye optimizadores de consulta

Verdadero Falso







Lección 13. Transacciones Distribuidas

Hasta este momento, las primitivas básicas de acceso que se han considerado son lasconsultas (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 delsistema durante la ejecución de una consulta. Dada la naturaleza de una consulta, delectura o actualización, a veces no se puede simplemente reactivar la ejecución de unaconsulta, puesto que algunos datos pueden haber sido modificados antes la falla. El notomar en cuenta esos factores puede conducir a que la información en la base de datoscontenga datos incorrectos.

El concepto fundamental aquí es la noción de "ejecución consistente" o "procesamientoconfiable" asociada con el concepto de una consulta. El concepto de una transacciónes 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 transformacionesconsistentes 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 deintegridad definidas sobre ella. Los cambios de estado ocurren debido aactualizaciones, inserciones, y supresiones de información. Por supuesto, se quiereasegurar que la base de datos nunca entra en un estado de inconsistencia. Sinembargo, 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 unatransparencia adecuada de las acciones concurrentes a una base de datos y por otrolado tener una transparencia adecuada en el manejo de las fallas que se puedenpresentar en una base de datos.







Figura 24. Un modelo de transacción.

Ejemplo 1. Considere la siguiente consulta en SQL para incrementar el 10% delpresupuesto 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 unatransacció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 lassiguientes 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 implementadamediante la siguiente transacción:

Begin_transaction Reservaciónbegin

input( flight_no, date, customer_name );EXEC SQL UPDATE FLIGHT

SET STSOLD = STSOLD + 1WHERE FNO = flight_noAND DATE = date







EXEC SQL INSERTINTO FC( FNAME, DATE, CNAME, SPECIAL )VALUES (flight_no, date, customer_name, null )

output("reservación terminada");end.

Condiciones de terminación de una transacción

Una transacción siempre termina, aun en la presencia de fallas. Si una transaccióntermina de manera exitosa se dice que la transacción hace un commit (se usará eltérmino en inglés cuando no exista un término en español que refleje con brevedad elsentido del término en inglés). Si la transacción se detiene sin terminar su tarea, se diceque la transacción aborta. Cuando la transacción es abortada, su ejecución es deteniday 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óntambién se le conoce como rollback .

Ejemplo 3. Considerando de nuevo el Ejemplo 3.2, veamos el caso cuando noexisten asientos disponibles para hacer la reservación.

Begin_transaction Reservaciónbegin

input( flight_no, date, customer_name );INTO temp1, temp2EXEC SQL SELECT STSOLD, CAPFROM FLIGHT

WHERE FNO = flight_no AND DATE = dateif temp1 = temp2 thenoutput( "no hay asientos libres" )Abortelse

EXEC SQL UPDATE FLIGHTSET STSOLD = STSOLD + 1WHERE FNO = flight_no AND DATE = date

EXEC SQL INSERTINTO 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. Estasacciones se utilizan como base para caracterizar a las transacciones. Los elementos dedatos 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







conjunto de escritura (WS). Note que los conjuntos de lectura y escritura no tienen queser necesariamente disjuntos. La unión de ambos conjuntos se le conoce como elconjunto 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 unidadindivisible. Se denota por OSi = U j Oij al conjunto de todas las operaciones de latransacció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 ) paracualquier 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 siguientespasos:

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 haintroducido 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 ) }







Note que la relación de ordenamiento especifica el orden relativo de todas lasoperaciones con respecto a la condición de terminación. Esto se debe a la terceracondición de la definición de transacción. También note que no se define elordenamiento entre cualquier par de operaciones, esto es, debido a que se ha definidoun orden parcial.

Propiedades de las transacciones

La discusión en la sección previa clarifica el concepto de transacción. Sin embargo, aunno se ha dado ninguna justificación para afirmar que las transacciones son unidades deprocesamiento consistentes y confiables. Las propiedades de una transacción son lassiguientes:

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 deellas 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 apreservar la atomicidad de transacciones en presencia de abortos debido a errores deentrada, sobrecarga del sistema o ínter bloqueos se le llama recuperación detransacciones. La actividad de asegurar la atomicidad en presencia de caídas delsistema se le llama recuperación de caídas.

Consistencia. La consistencia de una transacción es simplemente su correctitud. Enotras palabras, una transacción es un programa correcto que lleva la base de datos deun estado consistente a otro con la misma característica. Debido a esto, lastransacciones no violan las restricciones de integridad de una base de datos.

Aislamiento. Una transacción en ejecución no puede revelar sus resultados a otrastransacciones concurrentes antes de su commit . Más aún, si varias transacciones seejecutan concurrentemente, los resultados deben ser los mismos que si ellas sehubieran ejecutado de manera secuencial (seriabilidad).

Durabilidad . Es la propiedad de las transacciones que asegura que una vez que unatransacció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 deuna transacción sobrevivirán a fallas del sistema. Esta propiedad motiva el aspecto derecuperación de bases de datos, el cual trata sobre como recuperar la base de datos aun 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 enpresencia de fallas, una ejecución correcta en presencia de accesos de usuariomú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 problemasfundamentales son los mismos para las diferentes clases, los algoritmos y técnicas que







se usan para tratarlas pueden ser considerablemente diferentes. Las transaccionespueden ser agrupadas a lo largo de las siguientes dimensiones:

Áreas de aplicación. En primer lugar, las transacciones se pueden ejecutar enaplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se lesconocen como transacciones distribuidas. Por otro lado, dado que los resultados deuna transacción que realiza un commit son durables, la única forma de deshacer losefectos de una transacción con commit es mediante otra transacción. A este tipo detransacciones se les conoce como transacciones compensatorias. Finalmente, enambientes heterogéneos se presentan transacciones heterogéneas sobre los datos.

Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que se iniciauna transacción hasta que se realiza un commit o se aborta, las transacciones puedenser 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 derespuesta muy cortos y por accesar una porción relativamente pequeña de la base dedatos. Por otro lado, las transacciones de tipo batch toman tiempos relativamentelargos y accesan grandes porciones de la base de datos.

Estructura. Considerando la estructura que puede tener una transacción se examinandos aspectos: si una transacción puede contener a su vez subtransacciones o el ordende 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.







Una transacción anidada dentro de otra transacción conserva las mismas propiedadesque la de sus padres, esto implica, que puede contener así mismo transacciones dentrode 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 unasubtransacción es condicional al commit de su padre, en otras palabras, si el padre deuna o varias transacciones aborta, las subtransacciones hijas también serán abortadas.

Las transacciones anidadas proporcionan un nivel más alto de concurrencia entretransacciones. Ya que una transacción consiste de varias transacciones, es posibletener más concurrencia dentro de una sola transacción. Así también, es posiblerecuperarse de fallas de manera independiente de cada subtransacción. Esto limita eldaño a un parte más pequeña de la transacción, haciendo que costo de la recuperaciónsea menor.

En el segundo punto de vista se considera el orden de las lecturas y escrituras. Si lasacciones 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 serestringe o impone que un dato deber ser leído antes de que pueda ser escritoentonces se tendrá transacciones restringidas. Si las transacciones son restringidas aque todas las acciones de lectura se realicen antes de las acciones de escrituraentonces se les conoce como de dos pasos. Finalmente, existe un modelo de acciónpara transacciones restringidas en donde se aplica aún más la restricción de que cadapar <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: T 1: { R ( x ), R (y ), W (y ), R (z ), W ( x ), W (z ), W (w ), C }

Dos pasos: T 2: { R ( x ), R (y ), R (z ), W ( x ), W (y ), W (z ), W (w ), C }

Restringida: T 3: { R ( x ), R (y ), W (y ), R (z ), W ( x ), W (z ), R (w ), W (w ), C }

Restringida y de dos pasos:

T 4: { R ( x ), R (y ), R (z ), R (w ), W (y ), W ( x ), W (z ), W (w ), C }

Acción: T 3: { [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 detransacciones:







Modelo de estructura de transacciones. Es importante considerar si las transaccionesson planas o pueden estar anidadas.

Autoevaluación

Toda transacción exitosa hace Rollback

Verdadero Falso







Lección 14. Consistencia de la base de datos interna.

Los algoritmos de control de datos semántico tienen que satisfacer siempre lasrestricciones de integridad cuando una transacción pretende hacer un commit.

Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir mediosde comunicación entre los diferentes nodos de una red para garantizar la atomicidad ydurabilidad de las transacciones. Así también, se requieren protocolos para larecuperación local y para efectuar los compromisos (commit) globales.

Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia debensincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. Laconsistencia 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 laconsistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategiaread-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 detransacciones (TM) y el despachador (SC). Como se puede apreciar en la Figura 25, eladministrador de transacciones es responsable de coordinar la ejecución en la base dedatos 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 parasincronizar los accesos a la base de datos.

Un tercer componente que participa en el manejo de transacciones distribuidas es eladministrador de recuperación local cuya función es implementar procedimientoslocales que le permitan a una base de datos local recuperarse a un estado consistentedespués de una falla.







Figura 25. Un modelo del administrador de transacciones.

Los administradores de transacciones implementan una interfaz para los programas deaplicació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 detransacciones. Las modificaciones requeridas en la arquitectura para una ejecucióndistribuida se pueden apreciar en las Figura 26b. En esta última figura se presentantambién los protocolos de comunicación necesarios para el manejo de transaccionesdistribuidas.







Figura 26. Ejecución centralizada de transacciones.

Figura 26b. Ejecución distribuida de transacciones.

Recuperación en Sistemas Distribuidos







Una transacción debe ejecutarse en forma atómica. Es decir, se ejecutancompletamente 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óndebe 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ícilgarantizar la propiedad de atomicidad de una transacción. Esto se debe a que esposible que participen varias localidades en la ejecución de una transacción. El fallo deuna 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 detransacciones cooperan para ejecutar las transacciones globales. Para comprender cómo puede estructurarse un gestor de este tipo, definiremos un modelo abstracto paraun sistema de transacciones.

Gestor de transacciones, cuya función es gestionar la ejecución de aquellastransacciones (o subtransacciones) que accedan a datos almacenados en esalocalidad. 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ónglobal (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 seutiliza en el caso de un sistema centralizado. Cada gestor de transacciones se encargade:

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 estastransacciones, el coordinador debe:

transacción.

las localidades apropiadas para su ejecución.







abordada en todas las localidades.

Robustez

Es una configuración distribuida es necesario prever otro tipo de fallos, como puedenser:

Por tanto, para que el sistema sea robusto, es necesario que detecte cualquiera deestos fallos, que reconfigure el sistema de manera que pueda reanudarse el proceso yque se recupere una vez que haya sido reparado el procesador o la línea decomunicación afectados.

En general, no es posible distinguir entre los fallos en las líneas de comunicación de lared y de las localidades. Por tanto, el esquema de reconfiguración que se adopte debeestar 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 decomunicación separada. Cuando una localidad que quedó fuera de servicio serecupera, debe iniciar un procedimiento de actualización de sus tablas de sistema paraque reflejen los cambios que tuvieron lugar mientras estaba inactiva. Si la localidadtenía copias de datos, debe obtener los valores actuales de todos ellos y asegurarse derecibir las actualizaciones futuras. Esto es más complicado de lo que parece, ya que esposible que se actualicen los datos que se están procesando mientras que el sistemase recupera.

Es necesario representar a las tareas de recuperación como una seria detransacciones. En este caso, el subsistema de control de concurrencia y el manejo detransacciones puede encargarse de realizar de manera fiable la reintegración de lalocalidad.

Si se recupera una línea de comunicación interrumpida, es posible que se unan denuevo dos fragmentos de la red. Dado que la fragmentación de una red limita lasoperaciones que pueden permitirse en algunas localidades, o en todas ellas, es







conveniente enviar un mensaje a todas ellas informando sin delación que la línea serecuperó.

Control de concurrencia

El control de concurrencia trata con los problemas de aislamiento y consistencia delprocesamiento de transacciones. El control de concurrencia distribuido de una DDBMSasegura que la consistencia de la base de datos se mantiene en un ambientedistribuido multiusuario. Si las transacciones son internamente consistentes, la maneramás simple de lograr este objetivo es ejecutar cada transacción sola, una después deotra. Sin embargo, esto puede afectar grandemente el desempeño de un DDBMS dadoque el nivel de concurrencia se reduce al mínimo. El nivel de concurrencia, el númerode transacciones activas, es probablemente el parámetro más importante en sistemasdistribuidos. 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 elmantenimiento de un alto nivel de concurrencia.

Si no se hace un adecuado control de concurrencia, se pueden presentar dosanomalías. En primer lugar, se pueden perder actualizaciones provocando que losefectos de algunas transacciones no se reflejen en la base de datos. En segundotérmino, pueden presentarse recuperaciones de información inconsistentes.

En este capítulo se hace la suposición de que el sistema distribuido es completamenteconfiable y no experimente falla alguna.

Teoría de la seriabilidad

Una calendarización (schedule), también llamado una historia, se define sobre unconjunto de transacciones T = { T 1, T 2, ..., Tn } y especifica un orden entrelazado de laejecució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:

T 1: Read( x ) T 2: Write( x ) T 3: Read( x ) Write( x ) Write( y ) Read( y ) CommitRead( z ) Read( z ) Commit Commit Una calendarización de las acciones de las trestransacciones anteriores puede ser:

H 1 = { W 2( x ), R 1( x ), R 3( x ), W 1( x ), C 1, W 2(y ), R 3(y ), R 2(z ), C 2, R 3(z ), C 3 }

Dos operaciones Oij ( x ) y Okl ( x ) (i y k no necesariamente distintos) que accesan elmismo dato de la base de datos x se dice que están en conflicto si al menos una deellas es una escritura. De esta manera, las operaciones de lectura no tienen conflictosconsigo mismas. Por tanto, existen dos tipos de conflictos read-write (o write-read ) ywrite-write. Las dos operaciones en conflicto pueden pertenecer a la misma transaccióno a transacciones diferentes. En el último caso, se dice que las transacciones tienenconflicto. De manera intuitiva, la existencia de un conflicto entre dos operaciones indica







que su orden de ejecución es importante. El orden de dos operaciones de lectura esinsignificante.

Una calendarización completa define el orden de ejecución de todas las operaciones ensu dominio. Formalmente, una calendarización completa STc definido sobre unconjunto de transacciones T = { T 1, T 2, ..., Tn } es un orden parcial STc = { T , <T } endonde

Sumatoria T = Ui i , para todos los i = 1, 2, ..., n

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

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

Okl <T Oij

La primera condición establece simplemente que el dominio de la calendarización es launión de los dominios de las transacciones individuales. La segunda condición define larelación de ordenamiento como un superconjunto de la relación de ordenamiento detransacciones individuales. Esto mantiene el ordenamiento de las operaciones dentrode cada transacción. La condición final define el orden de ejecución entre dosoperaciones en conflicto.

Ejemplo 2. Considere las tres transacciones del Ejemplo 1, una posible calendarizacióncompleta 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







Las primeras dos condiciones definen a P ’ como una restricción de P en el dominioen donde las relaciones de ordenamiento en P se mantienen por P ’. La última condiciónindica que para cualquier elemento deincluidos también en

Ejemplo 3. La siguiente calendarización es un prefijo de la calendarización del Ejemplo2.

Si en una calendarización S, las operaciones de varias transacciones no estánentrelazadas, esto es, si las operaciones de una transacción ocurren de maneraconsecutiva, entonces se dice que la calendarización es serial . Si cada transacción esconsistente (obedece las reglas de integridad), entonces la base de datos se garantizaser consistente al final de la calendarización serial. La historia asociada a este tipo decalendarización se le conoce como serial.

Ejemplo 4. La siguiente es una historia serial para el Ejemplo 1.

HS = { W 2( x ), W 2(y ), R 2(z ), C 2, R 1( x ), W 1( x ), C 1, R 3( x ), R 3(y ), R 3(z ), C 3 }

Las transacciones se ejecutan de manera concurrente, pero el efecto neto de la historiaresultante sobre la base de datos es equivalente a alguna historia serial . Basada en larelación de precedencia introducida por el orden parcial, es posible discutir laequivalencia de diferentes calendarizaciones con respecto a sus efectos sobre la basede 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 comoequivalencia de conflictos puesto que define la equivalencia de dos calendarizacionesen 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:


H 1 = { W 2( x ), R 1( x ), R 3( x ), W 1( x ), C 1, W 2(y ), R 3(y ), R 2(z ), C 2, R 3(z ), C 3 }

Las siguientes calendarizaciones son equivalentes por conflictos; por lo tanto H 2 esserializable:


H 2 = { W 2( x ), R 1( x ), W 1( x ), C 1, R 3( x ), W 2(y ), R 3(y ), R 2(z ), C 2, R 3(z ), C 3 }







La función primaria de un controlador de concurrencia es generar una calendarizaciónserializable para la ejecución de todas las transacciones. El problema es, entonces,desarrollar algoritmos que garanticen que únicamente se generan calendarizacionesserializables.

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 detransacciones en un nodo conocido como calendarización local y la calendarizaciónglobal de las transacciones en el sistema. Para que las transacciones globales seanserializables 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 mismoen todos los nodos en donde las transacciones en conflicto se ejecutan juntas.

Ejemplo 6. Considere las siguientes tres transacciones:

T 1: Read( x ) T 2: Read( x ) x x ) Write( x ) Commit CommitLas siguientes historias locales son individualmente serializables (de hecho sonseriales), pero las dos transacciones no son globalmente serializables.

LH 1 = { R 1( x ), W 1( x ), C 1, R 2( x ), W 2( x ), C 2 }

LH 2 = { R 2( x ), W 2( x ), C 2, R 1( x ), W 1( x ), C 1 }

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 eltipo de primitiva de sincronización. Esto resulta en dos clases: aquellos algoritmos queestán basados en acceso mutuamente exclusivo a datos compartidos (candados) yaquellos que intentar ordenar la ejecución de las transacciones de acuerdo a unconjunto de reglas (protocolos). Sin embargo, esas primitivas se pueden usar enalgoritmos con dos puntos de vista diferentes: el punto de vista pesimista que consideraque muchas transacciones tienen conflictos con otras, o el punto de vista optimista quesupone que no se presentan muchos conflictos entre transacciones.

Los algoritmos pesimistas sincronizan la ejecución concurrente de las transacciones ensu etapa inicial de su ciclo de ejecución. Los algoritmos optimistas retrasan lasincronización de las transacciones hasta su terminación. El grupo de algoritmospesimistas consiste de algoritmos basados en candados, algoritmos basados enordenamiento por estampas de tiempo y algoritmos híbridos. El grupo de los algoritmos







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 intencionessolicitando candados al despachador (llamado el administrador de candados). Loscandados 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 delectura presentan conflictos con los candados de escritura, dado que las operacionesde lectura y escritura son incompatibles.

rl wl rl si no wl no no En sistemas basados en candados, el despachador es unadministrador de candados (LM). El administrador de transacciones le pasa aladministrador de candados la operación sobre la base de datos (lectura o escritura) einformación asociada, como por ejemplo el elemento de datos que es accesado y elidentificador de la transacción que está enviando la operación a la base de datos. Eladministrador de candados verifica si el elemento de datos que se quiere accesar ya hasido bloqueado por un candado. Si candado solicitado es incompatible con el candadocon que el dato está bloqueado, entonces, la transacción solicitante es retrasada. Deotra forma, el candado se define sobre el dato en el modo deseado y la operación a labase de datos es transferida al procesador de datos. El administrador de transacciones







es informado luego sobre el resultado de la operación. La terminación de unatransacción libera todos los candados y se puede iniciar otra transacción que estabaesperando 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 antesde usarlo. Cuando un objeto es bloqueado con un candado por otra transacción, latransacción solicitante debe esperar. Cuando una transacción libera un candado, ya nopuede solicitar más candados. Así una transacción que utiliza candados de dos fasesse comporta como en la Figura 28. En la primera fase solicita y adquiere todos loscandados sobre los elementos que va a utilizar y en la segunda fase libera loscandados obtenidos uno por uno.

La importancia de los candados de dos fases es que se ha demostrado de manerateórica que todos las calendarizaciones generadas por algoritmos de control deconcurrencia que obedecen a los candados de dos fases son serializables.

Puede suceder que si una transacción aborta después de liberar un candado, otrastransacciones que hayan accesado el mismo elemento de datos aborten tambiénprovocando lo que se conoce como abortos en cascada. Para evitar lo anterior, losdespachadores para candados de dos fases implementan lo que se conoce como loscandados estrictos de dos fases en los cuales se liberan todos los candados juntoscuando la transacción termina (con commit o aborta). El comportamiento anterior semuestra en la Figura 29.

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







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 unsolo nodo del sistema, por lo tanto, se tiene un despachador central el cual recibe todaslas 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. Lacomunicación se presenta entre el administrador de transacciones del nodo en dondese origina la transacción (llamado el coordinador TM), el administrador de candados enel nodo central y los procesadores de datos (DP) de todos los nodos participantes. Losnodos participantes son todos aquellos en donde la operación se va a llevar a cabo.







Figura 30. Comunicación en un administrador centralizado de candados de dosfases estrictos.

La crítica más fuerte a los algoritmos centralizados es el "cuello de botella" que seforma alrededor del nodo central reduciendo los tiempos de respuesta de todo elsistema. Más aún, su disponibilidad es reducida a cero cuando se presentan fallas en elnodo central.

Candados de dos fases distribuidos

En los candados de dos fases distribuidos se presentan despachadores en cada nododel sistema. Cada despachador maneja las solicitudes de candados para los datos enese 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 . Lacomunicación entre los nodos que cooperan para ejecutar una transacción de acuerdoal protocolo de candados distribuidos de dos fases se presenta en la Figura 31. Losmensajes de solicitud de candados se envían a todos los administradores de candadosque participan en el sistema. Las operaciones son pasadas a los procesadores dedatos por los administradores de candados. Los procesadores de datos envía sumensaje 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 enestampas 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 lastransacciones 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 paraidentificar cada transacción de manera única. Otra propiedad de las estampas detiempo es la monoticidad , esto es, dos estampas de tiempo generadas por el mismoadministrador de transacciones deben ser monotonicamente crecientes. Así, lasestampas de tiempo son valores derivados de un dominio totalmente ordenado.







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 esusar un contador global monotónicamente creciente. Sin embargo, el mantenimiento decontadores globales es un problema en sistemas distribuidos. Por lo tanto, es preferibleque cada nodo asigne de manera autónoma las estampas de tiempos basándose en uncontador local. Para obtener la unicidad, cada nodo le agrega al contador su propioidentificador. 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, demanera que, éste sirve solo en el caso en que dos nodos diferentes le asignen elmismo contador local a dos transacciones diferentes.

El administrador de transacciones asigna también una estampa de tiempo a todas lasoperaciones solicitadas por una transacción. Más aún, a cada elemento de datos x sele asigna una estampa de tiempo de escritura, wts( x ), y una estampa de tiempo delectura, 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 lastransacciones Ti y Tk , respectivamente, Oij es ejecutada antes de Okl , si ysolamente si, ts(Ti ) < ts(Tk ). En este caso Ti se dice ser una transacción más vieja yTk se dice ser una transacción más joven.

Dado este orden, un conflicto entre operaciones se puede resolver de la siguienteforma:







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 latransacción que la envió necesita reiniciarse para obtener la estampa de tiempo másreciente 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 tanpronto como se recibe una operación. Así, la ejecución de las operaciones esprogresiva pero pueden presentar muchos reinicios de transacciones. El ordenamientoconservador de estampas de tiempo retrasa cada operación hasta que exista laseguridad de que no será reiniciada. La forma de asegurar lo anterior es sabiendo queninguna otra operación con una estampa de tiempo menor puede llegar al

despachador. Un problema que se puede presentar al retrasar las operaciones es queesto 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. Alhacer una operación de escritura, no se modifican los valores actuales sino se creannuevos valores. Así, puede haber copias múltiples de un dato. Para crear copias únicasse 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 solaversió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 aceptadasi 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 naturalezapesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones sonmuy frecuentes y no permiten el acceso a un dato si existe una transacción conflictivaque 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ónsometida a un despachador optimista nunca es retrasada.

Las operaciones de lectura, cómputo y escrita de cada transacción se procesanlibremente sin actualizar la base de datos corriente. Cada transacción inicialmente hacesus 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







es positiva, los cambios se hacen globales (escritos en la base de datos corriente). Deotra 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 propuestosoriginalmente con el uso de estampas de tiempo. Sin embargo, en este tipo demecanismos las estampas de tiempo se asocian únicamente con las transacciones, nocon los datos. Más aún, las estampas de tiempo no se asignan al inicio de unatransacción sino justamente al inicio de su fase de validación. Esto se debe a que lasestampas se requieren únicamente durante la fase de validación.

Cada transacción Ti se subdivide en varias subtransacciones, cada una de las cualesse puede ejecutar en nodos diferentes. Sea Tij una subtransacción de Ti que se ejecutaen el nodo j . Supongamos que las transacciones se ejecutan de manera independientey ellas alcanzan el fin de sus fases de lectura. A todas las subtransacciones se lesasigna una estampa de tiempo al final de su fase de lectura. Durante la fase devalidación se realiza una prueba de validación, si una transacción falla, todas lastransacciones 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 deescritura 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 semuestra en la Figura 7a.

Si existe alguna transacción Tk , tal que, ts( Tk ) < ts( Tij ) y la cual completa su fase deescritura mientras Tij está en su fase de lectura, entonces, la validación tiene éxito siWS(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 delectura antes que Tij termine su fase de lectura, entonces, la validación tiene éxito si







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

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

Autoevaluación

Un candado de dos fases, solicita la primero los candados (fase de preparación) y alterminar , los libera

Verdadero Falso







Lección 15. Catálogo

Conceptos básicos

Existe un elemento denominado Catálogo, que es imprescindible conocer si se quierellegar a ser experto en el manejo de cualquier SGBD (Sistema de gestión de base dedatos). El catálogo guarda la información del esquema de la base de datos y es graciasa él que se pueden compartir los esquemas de dominio, y definir las relaciones deintegridad y de datos.

Comprender la estructura del catálogo, debe de ser un objetivo de todo administrador yanalista que quiera conocer el comportamiento de la base de datos. Para poder llegar asolucionar problemas de definición de datos, de rendimiento u optimización esnecesario 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 delcatálogo con relación a las varrels base, vistas, autorizaciones, etc., sino también todala información de control necesaria para permitir que el sistema proporcione laindependencia de ubicación, fragmentación y replicación necesaria. Surge entonces uninterrogante ¿Dónde y cómo debe ser almacenado el propio catálogo?. A continuaciónse 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 esesitio. 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 únicositio central mantiene una copia unificada de todos esos catálogos locales, como enpunto 4.2

Cada uno de los enfoques mencionados anteriormente, tiene sus propios problemas. Elenfoque centralizado viola el objetivo de “no dependencia de un sitio central”. Elenfoque completamente replicado sufre una pérdida de autonomía, ya que cadaactualización del catálogo tiene que ser propagada por cada uno de los sitios. Elenfoque dividido eleva el costo de operaciones que no son locales. La combinación de







centralizado y dividido es más eficiente que el dividido, pero viola nuevamente elobjetivo de no dependencia de un sitio central, por lo tanto, en la práctica los sistemasno usan ninguno de los enfoque antes mencionados. A manera de ejemplo describimosel 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 primerodecir algo acerca del nombramiento de objetos en R*. Este nombramiento esimportante para los sistemas distribuidos en general, ya que la posibilidad de que lossitios distintos X y Y, puedan tener un objeto, digamos una varrel llamada A, implicaque sería necesario algún mecanismo – por lo general la calificación por nombre desitio – para “eliminar la ambigüedad” (es decir, garantizar la unicidad de nombres anivel de sistema). Por lo tanto, lo que se necesita es un medio para transformar losnombres conocidos por los usuarios a sus nombres correspondientes conocidos por elsistema.

Este es el enfoque de R* para este problema. R* primero distingue entre el nombrecomún de un objeto, que es el nombre por el cual los usuarios hacen normalmentereferencia al objeto ( por ejemplo una instrucción SELECT de SQL), y su nombre anivel de sistema, que es identificador interno globalmente único para el objeto. Losnombres a nivel del sistema tienen cuatro componentes:

se almacenó inicialmente elobjeto).

Los IDs de usuario son únicos dentro del sito en el cual y los IDs del sitio son únicos anivel 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 elusuario 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 nombrese usa sin calificativos, ya sea el componente “nombre local” del nombre a nivelsistema (STATS en el ejemplo anterior) o un sinónimo para ese nombre a nivel desistema, 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;







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 sistemasuponiendo todos los valores predeterminados obvios; es decir que el objeto fue creadopor este usuario, que fue creado en este sitio y que fue guardado inicialmente en estesitio.

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 deesas tablas para los usuarios que se sabe que están en ese sitio y transforma lossinónimos conocidos para ese usuario en los nombres a nivel de sistemacorrespondientes. 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 esesitio.

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 latabla de sinónimos adecuada (una simple búsqueda local), Ahora ya sabe el sitio denacimiento(es decir Londres en el ejemplo) y puede consultar el catálogo de Londres (yse supone, de manera general, que será una búsqueda renota; el primer accesoremoto). El catálogo de Londres contendrá una entrada para ese objeto gracias alpunto 1 anterior. Si el objeto está todavía en Londres ya habrá sido encontrado. Sinembargo, si el objeto ha emigrado (digamos) a Los Ángeles, entonces la entrada decatálogo en Londres lo dirá y por lo tanto, el sistema podrá ahora consultar al catálogode Los Ángeles (segundo acceso remoto). Y el catálogo de los Ángeles contendrá unaentrada 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 elsistema:

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 enlugar de Los Ángeles.







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 concatá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







Referencias

DORSEY, P, Hudicka Oracle8. Diseño de bases de datos con UML. J. Ed. Oraclepress. 1999.

KROENKE,D. Procesamiento de bases de datos. Fundamentos, diseño eimplementación. 2003. Ed. Pearson Education. Octava edición








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, quepermite la utilización de los datos de una Organización o un conjunto de ellas, comosoporte en la toma de decisiones.

Está información puede provenir de múltiples fuentes heterogéneas no sólo enambiente 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 quees lo que se conoce como Metadatos.

La función de una Bodega de Datos es la de entregar la información correcta a la genteindicada en el momento adecuado en el formato correcto.

Cuántos tornillos se vendieron el año pasado en el último trimestre? Quien? En queDepartamentos o ciudades? Cuanto fueron las ventas totales en este trimestre? Cuálescampañas de publicidad dieron el mejor resultado? Las ventas se incrementaron comoresultado 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 unconjunto de compañías que conforman un pool? Cómo es la composición de lascuentas del presupuesto?

Estas son las preguntas a las que la Bodega de Datos tiene respuestas. Sin embargovale la pena aclarar que Bodega de Datos no es un proyecto de implementación de unaherramienta 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 seconoce como el proceso de Scrubbing. Almacena los metadatos en lo que se conocecomo repositorio y a partir de ahí permite que la información se analice y se presenteen la forma que necesita el usuario.

Los datos pueden ser extractados de grandes aplicaciones en Mainframe o de múltiplesfuentes distribuidas, de ambiente C/S, en ambientes disímiles. Usualmente los datosson transformados (reformateados o agregados) antes de ser colocados en la Bodegade Datos.

La problemática de Bodega de Datos difiere de compañía en compañía. Una puedenecesitar una Base de Datos centralizada, mientras que una organización distribuida alo largo del país o del mundo puede necesitar de una gran Base de Datos distribuida.







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







Lección 17. Construcción y manejo de una bodega de datos

Si la organización tiene muchos datos de aplicaciones tradicionales y está buscandouna solución para transferir grandes volúmenes de datos de un Mainframe, se necesitauna solución de Bodega de Datos de fuerza industrial para hacer transferencia bruta dedatos 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 querealice extracción de datos a altas velocidades y altos volúmenes de datos, traslade ydistribuya de múltiples y diferentes Bases de Datos en Mainframes en la BODEGA yojalá elimine la necesidad de escribir complejos programas y rutinas de conversión.

Usualmente estas herramientas tienen habilidades gráficas y proveen de criterio deselecció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 laherramienta utilizada debe completar las actualizaciones en el momento.

Distribución de datos es el proceso de mover los datos extractados y trasladarlos a laBodega 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 deconversió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 rutinasde 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 plataformasMainframe y C/S para mantener actualizada y sincronizada la Base de Datos en todaslas localidades

Autoevaluación

Un sistema que facilite la minería de datos permite

Buscar tendencias y comportamientos

Buscar entidades

Buscar atributos

Buscar inconsistencias







Lección 18. Construcción del Data Warehouse.

Como todo proyecto informático, el proyecto de bodega de datos consta de lossiguientes pasos.

Planeación

La fase define la metodología a utilizar. Como se muestra en el modelo de bases dedatos avanzada, existe el enfoque Top-Down (De Arriba abajo), y Bottom-up (De abajoa arriba) o una combinación de estas dos.

Todo proyecto de sistemas, requiere una metodología de desarrollo del producto. Engeneral, se usa el método de análisis y diseño estructurado y el método del desarrolloen espiral.

Requerimientos

Especificación de lo que se desean lograr del data warehouse. Comenzando por lavista de usuario, para que se quiere desarrollar la bodega. En el diseño, se puedetrabajar dos modelos diferentes, bodegas basadas en el Modelo Entidad Relación obodegas diseñadas con el modelo copo de nieve (snowflake).

En ambos casos, debe diseñarse las tablas que administran los datos del proceso quese desea revisar (producción, ventas, compras), llamadas tablas de hecho y las tablas

que registran los elementos que pueden explicar ese hecho, denominadas dimensioneso categorías (estrato, tiempo, categorías de los elementos, día en que se realizó latransacción), elementos que históricamente, pueden determinar un comportamiento otendencia.

Análisis

Una vez definidos los requerimientos, se determinan y clarifican las necesidades, seidentifican las entidades de donde se alimentará la información de la bodega; serevisan los atributos, sus propiedades y las transformaciones que se deben desarrollar

para homogenizar los datos. Se definen los procedimientos de conexión con las fuentesde 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 laimplementación de la bodega en la herramienta; los programas que manipulan losdatos para crear, modificar, estandarizar, sumarizar o generar los índices a partir de losdatos de los sistemas de alimentación de información definidos en la etapa anterior;







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 importanteconsiste en concientizar a los usuarios sobre la disponibilidad, beneficios ypresentació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, llamadoasí, por las siglas Extracción, Transformación y Carga de datos. Los procesos deExtracción identifican los sistemas que alimentarán la bodega; el proceso detransformación, define la manipulación de los datos para convertirlos y dejarlos en elformato 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 datosa la bodeba

Verdadero Falso







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 finalescon una aproximación de lo que la Bodega de Datos les puede proporcionar en unperíodo de tiempo tan corto como sea posible tal que el grupo de Bodega de Datospueda demostrar los beneficios de la Bodega de Datos a los usuarios y recolectar lomás pronto la retroalimentación crítica de los usuarios.

Las estructuras de Datos apropiadas pueden ser distribuidas herramientas de accesode datos a usuarios finales y aplicaciones para realizar queries. Deben ser creadasherramientas de soporte en la Decisión si es aplicable. Sin embargo el proceso deintegrar 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 unasola vez) de los datos de las estructuras de las Bodegas de Datos. La plataforma y laBase de Datos para el almacenamiento puede también diferir de aquellas para laarquitectura definitiva de Bodega de Datos, lo que es importante también, es que lapresentación de los Datos al usuario final sea tan fiel como sea posible para que seaigualmente presentada en posteriores etapas de la Bodega de Datos.

Piloto

En la construcción de una Bodega de Datos, se debe observar especial cuidado porquees la primera fase del proyecto en el cual el equipo de Bodega de Datos utilizará losmétodos, técnicas y herramientas que será la base para una Bodega de Datoscompleta. Por esta razón el proyecto piloto de Bodega de Datos debe tener un pequeñoalcance y tiempo adicional comparativamente con los esfuerzos sucesivos de Bodegade Datos.

Prueba del concepto tecnológico

La prueba del concepto tecnológico es un paso opcional que se puede necesitar paradefinir si la arquitectura especificada para la Bodega de Datos funcionará finalmentecomo 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íticoque la prueba del concepto tecnológico no esté cercana al prototipo, dado que la metadel 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óndebe ser realizada en muchos casos utilizando los programas para acompañar estatarea. El Data scrubbing debe ser hecho bien sea con ayuda de programas







desarrollados para esto, o con ayuda de herramientas de scrubbing tales comoPlatinum Infopump.

El corazón de la Bodega de Datos debe ser organizado desde un punto de vista denegocio. Se debe utilizar una estructura de Datos para el corazón de la Bodega deDatos, ligeramente normalizada. Esta estructura de Datos parece estar normalizadacuando 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 denegocio de la compañía y sus datos, independiente de cuanto usuarios este mirando aesos datos en un momento en particular. Esto es importante debido a que la forma enque la información es usada, cambiará frecuentemente y se necesita una Base deDatos 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ídosdel corazón de la Bodega de Datos y reorganizados y/o reformateados para hacer másfácil su uso para diferentes propósitos. Pero fofo que esos propósitos específicospueden cambiar en el tiempo, los Data Marts deben ser concebidos con estructuras deDatos temporales. Cuando los usuarios no ven más los datos como están presentadospor un Data Mart en particular, este Data Mart debe ser removido. Y mientras losusuarios 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 puedenser 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 lainformación de las Bodegas de Datos. No se debe esperar que un usuario novatonegocie una compleja y poderosa herramienta sólo para hacer una simple pregunta dela 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 denegocio usando una herramienta de acceso con menos poder del que se necesita. Esimportante reconocer que hay diferentes estilos de usuarios finales cada uno con supropio nivel de conocimiento y necesidades, para así proveer de apropiadosmecanismos 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







Herramientas de antivirus







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 losusuarios. Muchas veces el éxito depende de la diferencia entre lo que losusuarios esperan y lo que ellos perciben que les es entregado. Es crítico que elequipo de Bodega de Datos comunique las expectativas acerca de lo que seráentregado muy claramente y ayude al usuario final a entender la naturalezaiterativa 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ógicopara la Bodega de Datos. Sin embargo cuando esta primera área se hayacompletado, es más difícil identificar áreas para esfuerzos futuros y asegurar que esos esfuerzos están alineados con los objetivos y necesidades delnegocio. El riesgo se puede mitigar siguiendo la estrategia recomendada de laBodega, para entender las necesidades y prioridades de la información delnegocio y desarrollar una implementación de Bodega de Datos a largo plazoque cumpla con estas propiedades.

Autoevaluación

Un factor de riesgo es determinar lo que el usuario desea de la bodega de datos

Verdadero Falso







Capitulo 5. Minería de datosLección 21. Introducción

Esta unidad tiene como propósito introducir al lector en los conceptos fundamentales dela minería de datos y su relación con las bodegas de datos, no es la intención deprofundizar en cada uno de los temas, estos pueden ser ampliados en la bibliografíarecomendada, es necesario que el lector tenga conocimientos en base de datosrelacionales 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 lascompañías a concentrarse en la información más importante de sus Bases deInformación (Data Warehouse). Las herramientas de Data Mining predicen futurastendencias y comportamientos, permitiendo en los negocios tomar decisionesproactivas y conducidas por un conocimiento acabado de la información (knowledge-driven). Los análisis prospectivos automatizados ofrecidos por un producto así van másallá de los eventos pasados provistos por herramientas retrospectivas típicas desistemas de soporte de decisión. Las herramientas de Data Mining pueden responder apreguntas 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 aaceptar. Estas herramientas exploran las bases de datos en busca de patrones ocultos,encontrando información predecible que un experto no puede llegar a encontrar porquese encuentra fuera de sus expectativas.

Las técnicas de minería de datos se emplean para mejorar el rendimiento de procesosde negocio o industriales en los que se manejan grandes volúmenes de informaciónestructurada y almacenada en bases de datos. Por ejemplo, se usan con éxito enaplicaciones de control de procesos productivos, como herramienta de ayuda a laplanificació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 deobservación o de resultados de experimentos.

Autoevaluación

La minería de datos (Data Mining) busca predecir comportamientos a partir de lainformación histórica almacenada en la bodega

Verdadero Falso







Lección 22. Fundamentos del Data Mining

Las técnicas de Data Mining son el resultado de un largo proceso de investigación ydesarrollo de productos. Esta evolución comenzó cuando los datos de negocios fueronalmacenados por primera vez en computadoras, y continuó con mejoras en el acceso alos datos, y más recientemente con tecnologías generadas para permitir a los usuariosnavegar a través de los datos en tiempo real. Data Mining toma este proceso deevolución más allá del acceso y navegación retrospectiva de los datos, hacia la entregade información prospectiva y proactiva. Data Mining está lista para su aplicación en lacomunidad de negocios porque está soportado por tres tecnologías que ya estánsuficientemente maduras:

Las bases de datos comerciales están creciendo a un ritmo sin precedentes. Unreciente 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 algunasindustrias, tales como ventas al por menor (retail), estos números pueden ser aúnmayores. La necesidad paralela de motores computacionales mejorados puede ahoraalcanzarse de forma más efectiva con de con multiprocesamiento paralelo. Los de DataMining utilizan técnicas que han existido por lo menos desde hace 10 años, pero quesó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 yaprendizaje de máquinas. Hoy, la madurez de estas técnicas, junto con los motores debases de datos relacionales de alta performance, hicieron que estas tecnologías fueranprácticas para los entornos de data warehouse actuales.

Autoevaluación

Entre las herramientas de minería encontramos a la estadística

Verdadero Falso







Lección 23. Alcance de Data Mining

El nombre de Data Mining deriva de las similitudes entre buscar valiosa información denegocios en grandes bases de datos, por ej.: encontrar información de la venta de unproducto entre grandes montos de Gigabytes almacenados, minar una montaña paraencontrar una veta de metales valiosos. Ambos procesos requieren examinar unainmensa cantidad de material, o investigar inteligentemente hasta encontrar exactamente donde residen los valores. Dadas bases de datos de suficiente tamaño ycalidad, la tecnología de Data Mining puede generar nuevas oportunidades de negociosal proveer estas capacidades:

Predicción automatizada de tendencias y comportamientos. Data Mining

automatiza el proceso de encontrar información predecible en grandes bases dedatos. Preguntas que tradicionalmente requerían un intenso análisis manual,ahora pueden ser contestadas directa y rápidamente desde los datos. Un típicoejemplo de problema predecible es el marketing apuntado a objetivos (targetedmarketing). Data Mining usa datos en mailing promocionales anteriores paraidentificar posibles objetivos para maximizar los resultados de la inversión enfuturos mailing. Otros problemas predecibles incluyen pronósticos de problemasfinancieros futuros y otras formas de incumplimiento, e identificar segmentos depoblación que probablemente respondan similarmente a eventos dados.

Descubrimiento automatizado de modelos previamente desconocidos. Lasherramientas de Data Mining barren las bases de datos e identifican modelos

previamente escondidos en un sólo paso. Otros problemas de descubrimientode modelos incluye detectar transacciones fraudulentas de tarjetas de créditos eidentificar datos anormales que pueden representar errores de tipeado en lacarga de datos.

Las técnicas de Data Mining pueden redituar los beneficios de automatización enlas plataformas de hardware y software existentes y puede ser implementadasen sistemas nuevos a medida que las plataformas existentes se actualicen ynuevos productos sean desarrollados. Cuando las herramientas de Data Miningson implementadas en sistemas de procesamiento paralelo de altaperformance, 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 velocidadhace 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 devariables a examinar cuando realizan análisis manuales debido a limitacionesde tiempo. Sin embargo, variables que son descartadas porque parecen sinimportancia pueden proveer información acerca de modelos desconocidos. Un







Data Mining de alto rendimiento permite a los usuarios explorar toda la base dedatos, 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 importantessegmentos de población.

Autoevaluación

Las minería de datos puede decirse que busca información dentro de la información

Verdadero Falso







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 siemprelos mismos, independientemente de la técnica específica de extracción deconocimiento 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 deCRISP-DM. CRISP-DM (CRoss Industry Standard Process for Data Mining) es unestá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 procesogeneral 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







Lección 25. Cómo Trabaja el Data Mining?

¿Cuán exactamente es capaz Data Mining de decirle cosas importantes que usteddesconoce o que van a pasar? La técnica usada para realizar estas hazañas en DataMining se llama Modelado. Modelado es simplemente el acto de construir un modelo enuna situación donde usted conoce la respuesta y luego la aplica en otra situación de lacual desconoce la respuesta. Por ejemplo, si busca un galeón español hundido en losmares lo primero que podría hacer es investigar otros tesoros españoles que ya fueronencontrados en el pasado. Notaría que esos barcos frecuentemente fueronencontrados fuera de las costas de Bermuda y que hay ciertas características respectode las corrientes oceánicas y ciertas rutas que probablemente tomara el capitán delbarco 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 estosmodelos en mano sale a buscar el tesoro donde el modelo indica que en el pasadohubo más probabilidad de darse una situación similar. Con un poco de esperanza, sitiene un buen modelo, probablemente encontrará el tesoro.

Este acto de construcción de un modelo es algo que la gente ha estado haciendodesde hace mucho tiempo, seguramente desde antes del auge de las computadoras yde la tecnología de Data Mining. Lo que ocurre en las computadoras, no es muydiferente de la manera en que la gente construye modelos. Las computadoras soncargadas con mucha información acerca de una variedad de situaciones donde unarespuesta es conocida y luego el software de Data Mining en la computadora debecorrer 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 similaresdonde 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 puedeprobar es pedirle que aplique el modelo a su base de clientes - donde usted ya conocela respuesta. Con Data Mining, la mejor manera para realizar esto es dejando de ladociertos datos para aislarlos del proceso de Data Mining. Una vez que el proceso estácompleto, los resultados pueden ser testeados contra los datos excluidos paraconfirmar la validez del modelo. Si el modelo funciona, las observaciones debenmantenerse para los datos excluidos.

Una arquitectura para Data Mining

Para aplicar mejor estas técnicas avanzadas, éstas deben estar totalmente integradascon el data warehouse así como con herramientas flexibles e interactivas para elanálisis de negocios. Varias herramientas de Data Mining actualmente operan fuera delwarehouse, requiriendo pasos extra para extraer, importar y analizar los datos.

Además, cuando nuevos conceptos requieren implementación operacional, laintegración con el warehouse simplifica la aplicación de los resultados desde DataMining. El Data warehouse analítico resultante puede ser aplicado para mejorar







procesos de negocios en toda la organización, en áreas tales como manejo decampañ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 datosde seguimiento interno de todos los clientes junto con datos externos de mercadoacerca de la actividad de los competidores. Información histórica sobre potencialesclientes también provee una excelente base para prospecting. Este warehouse puedeser 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 sofisticadopueda ser aplicado cuando se navega por el data warehouse. Las estructurasmultidimensionales permiten que el usuario analice los datos de acuerdo a como quieramirar 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 elserver OLAP para insertar el análisis de negocios directamente en esta infraestructura.Un avanzado, metadata centrado en procesos define los objetivos del Data Mining pararesultados específicos tales como manejos de campaña, prospecting, y optimización depromociones. La integración con el data warehouse permite que decisionesoperacionales sean implementadas directamente y monitoreadas. A medida que el datawarehouse 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 soportede decisión convencionales. Más que simplemente proveer datos a los usuarios finalesa 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álisisproactivo de la información más relevante. Estos resultados mejoran los metadatos enel server OLAP (procesamiento analítico on-line) proveyendo una estrato de metadatosque 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







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 laestructura de una red neuronal biológica.

AutoevaluaciónUna red neuronal es similar a la manera como funciona el cerebro

Verdadero Falso







Lección 27. Árboles de decisión:

Estructuras de forma de árbol que representan conjuntos de decisiones. Estasdecisiones generan reglas para la clasificación de un conjunto de datos. Métodosespecí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 deChi Cuadrado (CHAI: Chi Square Automatic Interaction Detection)

Autoevaluación

Un tipo de árbol, es el árbol de decisión

Verdadero Falso







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 unacombinación de las clases del/de los k registro (s) más similar/es a él en un conjunto dedatos históricos (donde k 1). Algunas veces se llama la técnica del vecino k -máscercano.

Autoevaluación

El analisis de vecino más cercano es también llamado analisis Cluster

Verdadero Falso







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







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 deentidades-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.


DORSEY, P, Hudicka Oracle8. Diseño de bases de datos con UML. J. Ed. Oraclepress. 1999.

KROENKE,D. Procesamiento de bases de datos. Fundamentos, diseño eimplementación. 2003. Ed. Pearson Education. Octava edición


OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill.

ULLMAN, J Principles of database systems, Ed. Computer science press, 1982.







Unidad 3. Bases de datos orientadas a objetos

Capítulo 7. Orientación a objetos


Los sistemas de bases de datos orientados a objetos tienen sus orígenes en loslenguajes de programación orientados a objetos. La idea fundamental es que el usuariono debería tener que batallar con construcciones orientadas al computador tales comoregistros y campos, sino más bien debería poder manejar objetos (y operaciones) quese 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 cualesincluyen valores de clave ajena que hacen referencia a esa tupla DEPTO, el usuariodebería poder pensar directamente en un "objeto" departamento que contenga enrealidad 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), elusuario debería ser capaz de crear en forma directa un nuevo objeto empleado eincluirlo en el objeto departamento pertinente también en forma directa. Dicho de otromodo, 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 elcampo de los lenguajes de programación. Por tanto, es natural preguntar si es posibleaplicar el mismo paradigma en el área de las bases de datos. Es más, la idea demanejar una base de datos formada por "objetos encapsulados" (por ejemplo, un objetodependencia que "sabe qué significa" añadir un empleado o cambiar al gerente orecortar el presupuesto), en vez de tener que entender relaciones, actualizaciones detuplas, claves ajenas, etcétera, es desde luego mucho más atractiva y “fácil” desde elpunto 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 queincorporan tanto su estructura como su comportamiento, en contraste con ambientestradicionales en donde estas dos características se encuentran separadas.

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







Uno de los problemas que se tienen actualmente es la falta de estándares en laconcepció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 esteparadigma a la tecnología de bases de datos.







Lección 32. Conceptos básicos:

En esta sección se presentan algunos de los términos y conceptos principales delenfoque 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 conceptosmá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 deprogramación tradicional:

Término OO Término en programación

Objeto variableClase tipo

Método función

Mensaje llamada

Jerarquía de clases jerarquía de tipos

Objetos

Antes de entrar en detalles, es bueno advertir que en el mundo de los objetos no seencuentra 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 objetos-

son 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 esun objeto de primera clase”). Algunos objetos son inmutables: ejemplos de esto puedenser los enteros y las cadenas de caracteres. Otros objetos son mutables; algunosejemplos podrían ser los objetos de departamento y empleado. Por lo tanto, en laterminología tradicional, los objetos inmutables corresponden a los valores y los objetosmutables corresponden a las variables.

Todo objeto tiene un tipo (el término en objetos es clase). A los objetos individuales confrecuencia se les llama específicamente ejemplares (instancias) de objeto, paradistinguirlos con claridad del tipo o clase del objeto correspondiente. El término tipo seutiliza en su sentido usual de lenguaje de programación; por lo tanto, en particular eneste término se incluye el conjunto de operadores (el término en el entorno de objetoses métodos) que pueden ser aplicados a los objetos de ese tipo.

Polimorfismo.







El polimorfismo es otro de los pilares fundamentales de la programación orientada aobjetos. 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 dedicha variable a los miembros comunes a ambos tipos. Sin embargo, las versiones delos métodos virtuales a las que se llamaría a través de esas variables no serían lasdefinidas como miembros del tipo de dichas variables, sino las definidas en el verdaderotipo de los objetos que almacenan.

Herencia

El mecanismo de herencia es uno de los pilares fundamentales en los que se basa laprogramación orientada a objetos. Es un mecanismo que permite definir nuevas clases apartir 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ónde 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 fundamentalesen los que se apoya la programación orientada a objetos. Pues bien, el tercero es laencapsulación, que es un mecanismo que permite a los diseñadores de tipos de datosdeterminar qué miembros de los tipos pueden ser utilizados por otros programadores ycuá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 lepueden ocultar todos los detalles relativos a su implementación interna ysólo dejarle visibles aquellos que puedan usar con seguridad. Además, asíse les evita que cometan errores por manipular inadecuadamente miembrosque no deberían tocar.

Se facilita al creador del tipo la posterior modificación del mismo, pues si losprogramadores clientes no pueden acceder a los miembros no visibles, susaplicaciones no se verán afectadas si éstos cambian o se eliminan. Gracias aesto es posible crear inicialmente tipos de datos con un diseño sencillo

aunque poco eficiente, y si posteriormente es necesario modificarlos paraaumentar su eficiencia, ello puede hacerse sin afectar al código escrito enbase a la no mejorada de tipo.

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







siempre existirá la necesidad de obtener acceso a los datos en formas no previstas pararealizar 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 tiendena ser demasiado rígidos en este aspecto.

La encapsulación se consigue añadiendo modificadores de acceso en las definicionesde miembros y tipos de datos. Estos modificadores son partículas que se les colocandelante 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, comollamarlo si es una función, leer o escribir su valor si es un campo, crear objetos oheredar de él si es una clase, etc







Lección 33. Arquitectura de administrador de sistemas de BDOO.La estructura de las bases de datos orientadas a objetos no presenta la uniformidad delas 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, queel sistema de computadores implemente directamente. Comúnmente, las clases básicascorresponden a tipos de datos de lenguajes de programación estándar, tales comoentero, 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 contieneel valor del objeto para instancias de las clases básicas, o bien el identificador del objetopara instancias de las clases que no son básicas. Las variables con un conjunto devalores se representan por una lista enlazada de los objetos que son miembros delconjunto.

La estructura física hace que sea posible utilizar registros de longitud fija paraimplementar una base de datos orientada a objetos, aunque la modificación delesquema puede complicar esto.







Cuando la relación de contenido es jerárquica, el esquema de base de datos para unabase 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 altamenteespecializados que son grandes físicamente y que, por razones prácticas, normalmentese manipulan mediante programas de aplicación que no son parte del conjunto demétodos con las clases:

Datos de texto. El texto, normalmente se trata como una cadena de bytes quemanipulan 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 debytes 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 dedatos, en muchos casos se utilizan aplicaciones de software especiales.

Las variables que contienen datos de los tipos anteriores, con frecuencia se denominancampos largos, debido a que una implementación relacional de objetos que contenganestas variables requiere registros que contengan campos cuya longitud pueda ser devarios 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 deverificació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 estacopia utilizando programas de aplicación de propósito especial y comprueba la copiamodificada (checkin). Las nociones de verificación de resultados de salida (checkout) yverificación de datos de entrada (checkin) corresponden aproximadamente a una lecturay a una escritura. Sin embargo, el resultado de la operación de verificación de datos deentrada normalmente no es una escritura sino más bien la creación de una nueva versión.







Lección 34. Sistema administradores de bases de datos orientadas aobjetos (SABD-OO)

La primera vez que se habla del concepto de un SABD-OO se remonta al año 1983 conuna 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 OregonGraduate Center. De este prototipo se desarrolla un producto y se comercializa en 1988por Servio Logia, bajo el nombre de GemStone

Por otra parte, en ese mismo año, la compañía Hewlett Packard implementa un proyectobajo 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 lossiguientes 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 figurasiguiente:

Reglas de bases de datos Elsistema 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.







Lección 35. El sistema Postgres

Para referenciar uno de los productos que trabajan este tipo de bases de datos hemostomado el proyecto Postgres. El proyecto Postgres- Post Ingres- inicia en 1986 como unaextensión del SABD Ingres. Ha sido escrito en el lenguaje de programación C y consta de180000 líneas de código (STON91)

Postgres se apoya en la idea de extender el modelo relacional con mecanismos generalesque permitan el soporte de objetos complejos, así como implementar jerarquías deobjetos. Entre los mecanismos, se pueden mencionar los tipos de datos abstractos, losdatos de tipo procedimiento y las reglas.

Una base datos en Postgres se puede ver como un conjunto de tablas. El tipo de unatributo 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.







Capitulo 8. Lenguaje de Modelado Unificado UML


La intención de este capítulo no es la de hacer un estudio detallado de UML, es tan solomotivar al lector a que con base en los temas aquí tratados pueda consultar textosavanzados 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 parallegar o evolucionar un sistema

Como un lenguaje, es usado para la comunicación. Es decir, un mediopara capturar el conocimiento (semánticas) respecto a un tema yexpresar el conocimiento (sintaxis) resguardando el tema propósito de lacomunicación. El tema es el sistema en estudio.

Como un lenguaje para modelamiento, se enfoca en la comprensión deun tema a través de la formulación de un modelo del tema (y su contextorespectivo). 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 laindustria tecnológica y sistemas de información pasando por todos os tiposde sistemas (software y no - software), dominios (negocios versussoftware) y los procesos de ciclo de vida.

En cuanto a cómo se aplica para especificar sistemas, puede ser usadopara comunicar "qué" se requiere de un sistema y "cómo" un sistemapuede ser realizado.

En cuanto a cómo se aplica para visualizar sistemas, puede ser usadopara describir visualmente un sistema antes de ser realizado.

En cuanto a cómo se aplica para construir sistemas, puede ser usadopara guiar la realización de un sistema similar a los "planos".

En cuanto a cómo se aplica para documentar sistemas, puede ser usadopara capturar conocimiento respecto a un sistema a lo largo de todo elproceso de su ciclo de vida.

UML no es:

Un lenguaje de programación visual, sino un lenguaje de modelamiento







visual

Una herramienta o depósito de especificación, sino un lenguaje paramodelamiento de especificación.

Un proceso, sino que habilita procesos.







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álisisy 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 cadaindividuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándohacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estasinstrucciones. Los métodos contienen modelos y esos modelos son utilizados paradescribir 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, deestados, 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 loselementos de modelo que representan conceptos comunes orientados a objetos, talescomo clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo laasociación, dependencia y generalización. Un elemento

de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismosignificado y simbología.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semánticaacerca del elemento de modelo; además proveen mecanismos de extensión paraadaptar 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, ampliamenteaplicable, que puede ser soportado por diferentes herramientas e industrialmenteestandarizado. Se aplica a una multitud de diferentes tipos de sistemas, dominios, ymé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 deconocimientos 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, lasherramientas ya están disponibles para soportar la aplicación dellenguaje para especificar, visualizar, construir y documentar sistemas.







Como un lenguaje para modelamiento industrialmente estandarizado, noes 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 orientadosa objetos.

Establecer conceptos y artefactos ejecutables.

Encaminar el desarrollo del escalamiento en sistemas complejos demisió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 yoperacional para facilitar el incremento de valor, aumentando la calidad, reduciendo costosy reduciendo el tiempo de presentación al mercado; manejando riesgos y siendo proactivopara el posible aumento de complejidad o cambio.







Lección 38. Una perspectiva de UMLLas siguientes secciones presentan una vista más detallada al modelado con UML. Unsistema de reserva de aerolíneas simple se va a usar para mostrar los diagramas yté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 requisitosdel sistema

Modelando con Diagramas de Secuencia y Colaboración

Analizando y diseñando con el Diagrama de Clase, y extendiendo UMLcon 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 dimensioneses 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 tengancompetencias 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 puedenser 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 deuso individuales, clases, o componentes. Ver fig.34

Figura 34: Organizando el sistema mediante el uso de paquetes







Modelado de Casos de Uso

Un Caso de Uso es un documento narrativo que describe a los actores utilizando unsistema para satisfacer un objetivo. Es una historia o una forma particular de usar unsistema. 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 paramodelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Usose utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo losusuarios desean que funcione. No es realmente una aproximación a la orientación aobjetos; es realmente una forma de modelar procesos. Es, sin embargo, una maneramuy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casos deuso 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 actoresrepresentan usuarios y otros sistemas que interaccionan con el sistema. Se dibujancomo "muñecos" de palo. Actualmente representan el tipo de usuario, no una instanciade usuario. Los casos de uso representan el comportamiento del sistema, los escenariosque el sistema atraviesa en respuesta a un estímulo desde un actor. Se dibujan como

elipses.

Figura 35: Modelado de Casos de Uso.

Use Case Descri tion in S1e Form1.Passenger rec&estsffighti rom ticket vendar.2.Ticket vendor créeteavaüaJiifity frorr\ Airline 7~~"—--

__

"Honre are

possibleclasses or classattributes.







Cada caso de uso se documenta por una descripción del escenario. La descripciónpuede 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- delescenario --- condiciones que existen antes de que el escenario comience, y condicionesque existen después de que el escenario se completa. Los Diagramas de Actividadofrecen 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 usuariopara el sistema. Estos requisitos pueden ser requisitos de software, requisitos deproductos, o requisitos de pruebas. La meta de capturar y comprobar los requisitos delusuario es asegurar que todos los requisitos son completados por el diseño, y que eldiseño es acorde con los requisitos especificados.

Muchas veces los requisitos del sistema ya existen en forma de documentos derequisitos. Los casos de uso se utilizan para correlacionar cada escenario con losrequisitos que completa. Si los requisitos no existen, modelar el sistema a través de losCasos 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 decaso de uso para este sistema, y construir paquetes para representar los varios dominiosde negocio (business) del sistema. Puedes descomponer cada paquete con un Diagramade Caso de Uso que contenga los Casos de Uso de un dominio, con interacciones deactor.

Modelar secuencias alternas a través de la relación "Extiende"(extends)

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 deUso basados en estas secuencias alternas de eventos. Las secuencias alternas semodelan en casos de uso separados, los cuales están relacionados con el caso de usooriginal 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 casode 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)







Para eliminar el modelado redundante de buena parte del comportamiento que aparezcaen 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.







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

Usa (uses).







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 cadacaso 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 delescenario, incluyendo los objetos y clases que se usan para implementar el escenario, ymensajes pasados entre los objetos.

Típicamente uno examina la descripción de un caso de uso para determinar qué objetosson necesarios para la implementación del escenario. Si tienes modelada la descripción decada 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íneasdiscontinuas verticales, y los mensajes pasados entre los objetos como vectoreshorizontales. Los mensajes se dibujan cronológicamente desde la parte superior deldiagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Ver fig. 37.







Figura 37: Diagrama de Secuencia para un escenario

Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' deun 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 lacase instan ciada por el objeto en la recepción final del mensaje.







Lección 40. Diagramas de Colaboración

El Diagrama de Colaboración presenta una alternativa al diagrama de secuenciapara modelar interacciones entre objetos en el sistema. Mientras que el diagramade secuencia se centra en la secuencia cronológica del escenario que estamosmodelando, el diagrama de colaboración se centra en estudiar todos los efectosde un objeto dado durante un escenario. Los objetos se conectan por medio deenlaces, cada enlace representa una instancia de una asociación entre las clasesimplicadas, 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 lavisibilidad de un objeto con respecto a los otros.

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







Capítulo 9. Modelado con UMLLección 41. Modelando el comportamiento de las Clases con Diagramas deEstado

Mientras los diagramas de interacción y colaboración modelan secuenciasdinámicas de acción entre grupos de objetos en un sistema, el diagrama de estadose usa para modelar el comportamiento dinámico de un objeto en particular, o deuna clase de objetos.

Un diagrama de estado se modela para todas las clases que se consideran con uncomportamiento dinámico. En él, modelas la secuencia de estado que un objetode la clase atraviesa durante su vida en respuesta a los estímulos recibidos, juntocon 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 enparticular. También modelas qué acciones realiza un objeto en un estado enconcreto.

Los estados representan las condiciones de objetos en ciertos puntos en eltiempo. 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 unestado hasta otro. Cada línea de transición se nombre con el evento que causaesta transición. Las acciones ocurren cuando un objeto llega a un estado. Ver fig.39.







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

diagrama de estado







Lección 42. Diagramas de Actividad

El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito quese usa para modelar el comportamiento del sistema. Los diagramas de actividadse pueden usar para modelar un Caso de Uso, o una clase, o un métodocomplicado.

Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clavees que los diagramas de actividad pueden mostrar procesado paralelo (parallelprocessing). Esto es importante cuando se usan diagramas de actividad paramodelar 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 elproceso de un Caso de Uso. Se pueden usar como un añadido a una descripcióntextual del caso de uso, o para listar los pasos del caso de uso. Una descripcióntextual, 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 eventosasincrónicos. El diagrama de actividad se usa cuando todos o la mayoría de loselementos representan el desarrollo de los pasos dados por las accionesgeneradas internamente. Ver fig. 40. Deberías asignar actividades a las clasesantes de terminar con el diagrama de actividad.







Figura 40: Diagrama de Actividad







Lección 43. Modelando Componentes de Software

El Diagrama de Componentes se usa para modelar la estructura del software, incluyendolas dependencias entre los componentes de software, los componentes de código binario, ylos componentes ejecutables. En el Diagrama de Componentes modelas componentes delsistema ver fig. 41, a veces agrupados por paquetes, y las dependencias que existen entrecomponentes (y paquetes de componentes).

Figura 41: Modelando componentes con el Diagrama de Componentes







Lección 44. Modelando la Distribución y la Implementación

Los Diagramas de Implementación se usan para modelar la configuración de loselementos de procesado en tiempo de ejecución (run-time processing elements) yde los componentes, procesos y objetos de software que viven en ellos. En eldiagrama 'deployment', empiezas modelando nodos físicos y las asociaciones decomunicación que existen entre ellos. Para cada nodo, puedes indicar quéinstancias de componentes viven o corren (se ejecutan) en el nodo. Tambiénpuedes 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 usanpara modelar componentes solo de tiempo de compilación o de tiempo deenlazado. Puedes también modelar componentes que migran de nodo a nodo uobjetos que migran de componente a componente usando una relación dedependencia con el estereotipo 'becomes' (se transforma)







Lección 45. Diseño de Bases de Datos Relacionales -- Una extensióninformal 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 orientadaa objetos. Aun así, en el entorno de desarrollo actual, la base de datos relacional es elmétodo más usado para el almacenamiento de datos. Es en el modelado de esta áreadonde 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 lasemántica involucrada en el modelado relacional, mayoritariamente la noción de atributosclave 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 representandotablas, y atributos de clase representando columnas. Si una base de datos relacional es elmé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 susatributos hacen referencia directamente a las entidades lógicas y a sus atributos; elmodelador dispone de varias opciones sobre cómo inferir asociaciones en relaciones entreentidades. Las relaciones de herencia son referenciadas directamente a super-subrelaciones 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 elDiagrama de Relación de Entidad (ER Diagram)

Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el proceso dedeterminar cómo el modelo relacional encaja; y qué atributos son claves primarias, claves







secundarias, y claves externas basadas en relaciones con otras entidades. La idea esconstruir 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 aldiagrama de relación de entidad lógico a un diagrama físico que represente el objetivo, elRDBMS. El diagrama físico puede ser denormalizado para lograr un diseño de base dedatos que tiene tiempos eficientes de acceso a los datos. Las relaciones super-sub entreentidades se resuelven por las estructuras de tablas actuales. Además, el diagrama físicose usa para modelar propiedades específicas de cada fabricante para el RDBMS. Se creanvarios diagramas físicos si hay varios RDBMSs siendo 'deployed'; cada diagrama físicorepresenta 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







Los lenguajes de programación orientados a objetos requieren que toda la interacción conobjetos 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 decomputadores y la consulta “Encontrar todos los sistemas de computadores que utilicen chipsvendidos por Oldblock Corporation”. Si seguimos estrictamente el modelo de laprogramación orientada a objetos, se deberá enviar un mensaje a cada instancia de la claseChip para verificar su valor vendedor. Si tratáramos esta solicitud como un problema de labase de datos, esperaríamos que existiera un índice para la clase Chip para las cuales elcampo vendedor fuera “Old-block Corporation”.

La última forma de cómo se va a tratar la consulta corresponde a una vista relacional de labase de datos de objetos que vimos. De hecho, podríamos plantear consultas queimplicasen intersecciones de conjuntos de objetos. Sin embargo, la vista relacional deobjetos 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 debeincluir tanto el modelo de pasar el mensaje de objeto en objeto (un objeto cada vez) comoel 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ñodel lenguaje, a menudo conocido como “impedancia desajustada”.

Referencias

BATINI C.; Ceri S.; Navathe S. Diseño conceptual de bases de datos. Un enfoque deentidades-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.


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







OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill.

ULLMAN, J Principles of database systems, Ed. Computer science press, 1982.

Base_de_datos_avanzada_v3

Documents

Transcript of Base_de_datos_avanzada_v3