tesis de maestría en computación

Universidad Nacional Autónoma de Nicaragua UNAN–León

Tesis de Maestría en Computación Maestría impartida por la UAH-España en la UNAN-León

PLAN DOCENTE PARA LA ASIGNATURA

BASES DE DATOS II

TITULACIÓN INGENIERÍA EN SISTEMA DE INFORMACIÓN

Autor: Ernesto Antonio Espinoza Montenegro Director: José María Gutiérrez

León, Julio de 2004

ii

TTTAAABBBLLLAAA DDDEEE CCCOOONNNTTTEEENNNIIIDDDOOOSSS Capítulo 1: Introducción ...............................................................................................1

Introducción. .............................................................................................................2 Objetivos generales..................................................................................................3 Objetivos específicos................................................................................................3 Desarrollo del proyecto.............................................................................................3

Capítulo 2 : Plan de Estudios y Metodología Docente.................................................4 2.1 Bases de datos II en el plan de estudios de Ingeniería en Sistemas .................5

2.1.1 Programación II............................................................................................6 2.1.2 Algoritmos y estructuras de datos................................................................6 2.2.3 Bases de datos I. .........................................................................................7

2.2 Metodología docente ..........................................................................................8 2.2.1 Material y método didáctico. ........................................................................8 2.2.2 Metodología de evaluación. .........................................................................9

Capítulo 3 : Desarrollo del temario para Bases de Datos II .......................................10 3.1 Introducción. .....................................................................................................11

3.1.1 Objetivos ....................................................................................................11 3.2 Planificación temporal ......................................................................................12 3.3 Almacenamiento y estructuras de archivos de bases de datos. ......................13

3.3.1 Visión general de los medios físicos..........................................................14 3.3.2 Técnicas de organización de discos: Sistemas RAID................................16 3.3.3 Acceso al almacenamiento: gestor de memoria intermedia ......................20 3.3.4 Organización de archivos ..........................................................................21 3.3.5 Diccionario de datos ..................................................................................28

3.4 Indexación y asociación ...................................................................................29 3.4.1 Índices ordenados......................................................................................30 3.4.2 Archivos indexados de árboles B+ ............................................................37 3.4.3 Técnicas hashing .......................................................................................41

3.5 Procesamiento de consultas ............................................................................44 3.5.1 Interpretación de consultas........................................................................44 3.5.2 Equivalencias de expresiones ...................................................................45 3.5.3 Estimación del costo de procesamiento de consultas ...............................49

3.5.4 Mecanismos de implementación de las operaciones ................................50 3.5.5 Materialización y encauzamiento...............................................................64

3.6 Transacciones ..................................................................................................66 3.6.1 Propiedades de una transacción ...............................................................66 3.6.2 Estados de una transacción.......................................................................68 3.6.5 Implementación de la atomicidad y durabilidad .........................................69 3.6.6 Ejecuciones concurrentes..........................................................................70 3.6.7 Secuencialidad...........................................................................................73 3.6.8 Recuperabilidad .........................................................................................76 3.6.9 Implementación del aislamiento.................................................................78 3.6.10 Comprobación de la secuencialidad ........................................................78

3.7 Control de concurrencia ...................................................................................80 3.7.1 Protocolos basados en el bloqueo.............................................................80 3.7.2 Protocolos basados en marcas temporales...............................................87 3.7.3 Protocolos basados en validación .............................................................89 3.7.4 Granularidad múltiple.................................................................................90

3.8 Recuperación frente a caídas del sistema .......................................................94 3.8.1 Estructura y operaciones de almacenamiento...........................................94 3.8.2 Recuperación basada en registro histórico................................................96 3.8.3 Shadow pages ...........................................................................................99 3.8.4 Transacciones concurrentes y recuperación ...........................................101

Capítulo 4 : Prácticas de laboratorio ........................................................................102 4.1 Objetivos generales........................................................................................103 4.2 Introducción ....................................................................................................103 4.3 Mecanismo de evaluación de laboratorios .....................................................103 4.4 Temporización de las prácticas ......................................................................104 4.5 Materiales para el desarrollo de las prácticas ................................................104 4.6 Prácticas previas ............................................................................................105

4.6.1 Práctica 0: Instalación de PostgreSQL ....................................................105 4.6.2 Práctica 1: Acceder a PostgreSQL desde clientes Windows...................107 4.6.3 Práctica 2: Familiarización con el entorno PostgreSQL...........................109 4.6.4 Práctica 3: Creación de la estructura de la base de datos ......................110 4.6.5 Práctica 4: Sentencias de manipulación de datos con SQL. ...................111 4.6.6 Práctica 5: Creación de una interfaz sencilla con VC++..........................115

4.7 Proyectos de bases de datos .........................................................................124 Capítulo 5 : Bibliografía............................................................................................125

iv

ÍÍÍNNNDDDIIICCCEEE DDDEEE FFFIIIGGGUUURRRAAASSS Ilustración 2-1: Relación de la asignatura con otros componentes curriculares ..........5 Ilustración 2-2: Desarrollo de las clases magistrales ...................................................8 Ilustración 2-3: Distribución de las evaluaciones en el semestre.................................9 Ilustración 3-1: Avance programático basado en 16 semanas ..................................12 Ilustración 3-2: Relación Velocidad-Coste-Capacidad...............................................14 Ilustración 3-3: Estructura interna de un disco duro...................................................15 Ilustración 3-4: Estructura RAID 0..............................................................................17 Ilustración 3-5: Estructura RAID 1..............................................................................18 Ilustración 3-6: Estructura RAID 3..............................................................................19 Ilustración 3-7: Estructura RAID 5..............................................................................19 Ilustración 3-8: Gestor de Buffer de la base de datos................................................20 Ilustración 3-9: Dificultad de almacenamiento en registros de longitud fija ...............22 Ilustración 3-10: Borrado por desplazamiento en registros de longitud fija ...............22 Ilustración 3-11: Borrado pasar último en registros de longitud fija ...........................23 Ilustración 3-12: Borrado utilizando cabeceras de archivo ........................................23 Ilustración 3-13: Ejemplo de estructura cadenas de bytes ........................................24 Ilustración 3-14: Ejemplo de estructura de página con ranura...................................25 Ilustración 3-15: Registros variables mediante espacio reservado............................25 Ilustración 3-16: Registros variables mediante listas .................................................26 Ilustración 3-17: Registro variable mediante bloque ancla-desborde ........................26 Ilustración 3-18: Ejemplo de la estructura de los archivos indexados .......................27 Ilustración 3-19: Implementación de índice denso.....................................................30 Ilustración 3-20: Estructura de índice disperso ..........................................................31 Ilustración 3-21: Estructura de índice multinivel.........................................................31 Ilustración 3-22: Inserción en índices densos (nueva entrada)..................................32 Ilustración 3-23: Inserción en índices densos (un puntero por clave)........................32 Ilustración 3-24: Inserción en índices densos (una entrada por clave diferente).......33 Ilustración 3-25: Inserción en índice disperso............................................................33 Ilustración 3-26: Borrado índices densos (única clave) .............................................34 Ilustración 3-27: Borrado índices densos (un puntero por clave)...............................34 Ilustración 3-28: Borrado índices densos (primer clave de lista) ...............................34

Ilustración 3-29: Borrado en índice escaso (eliminar entrada)...................................35 Ilustración 3-30: Borrado en índice escaso (reemplazar por la siguiente clave)........35 Ilustración 3-31: índice denso secundario por existencias.........................................36 Ilustración 3-32: índice escaso secundario por fecha ................................................36 Ilustración 3-33: Inserción árbol B+ (no split en raíz).................................................38 Ilustración 3-34: Inserción árbol B+ (nodo no hoja) ...................................................39 Ilustración 3-35: Borrado en árbol B+ (sin fusiones) ..................................................40 Ilustración 3-36: Borrado en árbol B+ (fusión de nodos)............................................40 Ilustración 3-37: Implementación de una fn hash con cadenas de caracteres ..........41 Ilustración 3-38: Estructura hashing extensible .........................................................42 Ilustración 3-39: Inserción utilizando extensible hashing ...........................................43 Ilustración 3-40: Campos innecesarios en el proceso de selección ..........................46 Ilustración 3-41: Selecciones de igualdad con índices secundarios ..........................52 Ilustración 3-42: Selecciones de comparación con índices secundarios ...................53 Ilustración 3-43: Implementación de selección sobre índices compuestos ...............54 Ilustración 3-44: Implementación de selección mediante intersección de punteros ..54 Ilustración 3-45: Segunda fase de la técnica mezcla-externa....................................56 Ilustración 3-46: Técnica de ordenamiento-mezcla-externa ......................................57 Ilustración 3-47: Implementación de la operación reunión por mezcla ......................61 Ilustración 3-48: Ejemplo de la estructura de árbol generada en la materialización..64 Ilustración 3-49: Aplicación de la técnica de encauzamiento.....................................65 Ilustración 3-50: Diagrama de transición de estados de una transacción..................68 Ilustración 3-51: Cuadro de la transacción t1 (transferencias en córdobas)...............70 Ilustración 3-52: Cuadro de la transacción t2 (transferencias en córdobas)...............71 Ilustración 3-53: Planificación secuencial t1 después de t2 ........................................71 Ilustración 3-54: Planificación concurrente equivalente al caso anterior ...................72 Ilustración 3-55: Planificación concurrente con problemas de consistencia ..............72 Ilustración 3-56: Planificación con conflicto de instrucciones ....................................73 Ilustración 3-57: Planificaciones equivalentes en cuanto a conflictos........................74 Ilustración 3-58: Ejemplo de planificaciones secuenciables en cuanto a conflictos ..74 Ilustración 3-59: planificaciones no secuenciables en cuanto a vistas ......................75 Ilustración 3-60: Ejemplo de planificaciones equivalentes en cuanto a vistas...........76 Ilustración 3-61: Ejemplo de planificación no recuperable.........................................77 Ilustración 3-62: Ejemplo de retroceso de transacciones en cascada .......................77 Ilustración 3-63: Grafo de precedencia con bucles....................................................79 Ilustración 3-64: Topologías lineales para un grafo de precedencia..........................79 Ilustración 3-65: Definición de transacciones con desbloqueo inmediato..................81

vi

Ilustración 3-67: Propuesta de transacciones con desbloqueos retrasados..............82 Ilustración 3-68: Planificación que presenta la anomalía de interbloqueo .................82 Ilustración 3-69: Planificación con conversión de bloqueos.......................................84 Ilustración 3-70: Ejemplo de una tabla de bloqueos simplificada ..............................85 Ilustración 3-71: Grafo de la base de datos bajo el protocolo del árbol .....................86 Ilustración 3-72: Ejemplo de planificación secuenciable con protocolo de árbol .......87 Ilustración 3-73: Transacciones ejemplo para protocolo de marcas temporales .......88 Ilustración 3-74: Planificación utilizando marcas temporales.....................................89 Ilustración 3-75: Planificación utilizando validación ...................................................90 Ilustración 3-76: Ejemplo de árbol de jerarquía de granularidad ...............................91 Ilustración 3-77: Esquema general de las operaciones input y output.......................95 Ilustración 3-78: Posibles fallos de las operaciones input y output............................95 Ilustración 3-79: Ejemplo de contenido de un archivo bitácora..................................97 Ilustración 3-80: Descartar contenido del registro de historial (no commit) ...............97 Ilustración 3-81: Rehacer y deshacer transacciones con registro histórico ...............98 Ilustración 3-82: Rehacer las transacciones encontradas en el historial ...................98 Ilustración 3-83: Ejemplo de registro historial con actualizaciones inmediatas .........99 Ilustración 3-84: Ejemplo de estado inicial del sistema en shadow pages ..............100 Ilustración 3-85: Proceso de ejecución de una transacción bajo paginación doble.100

ÍÍÍNNNDDDIIICCCEEE DDDEEE TTTAAABBBLLLAAASSS Tabla 0-1: Fases de desarrollo del proyecto............................................................... 3 Tabla 2-1: Relación de la asignatura con Programación II. ........................................ 6 Tabla 2-2: Relación de la asignatura con algoritmos y estructuras de datos.............. 6 Tabla 2-3: Relación de la asignatura con bases de datos I ........................................ 7 Tabla 3-1: Distribución temporal de los temas teóricos de la asignatura.................. 12 Tabla 3-2: Visión general del tema 1 ........................................................................ 13 Tabla 3-3: Visión general del tema 2 ........................................................................ 29 Tabla 3-4: Visión general del tema 3 ........................................................................ 44 Tabla 3-5: Ejemplo de materialización (tabla Factura).............................................. 64 Tabla 3-6: Ejemplo de Materialización (tabla Detallefactura).................................... 64 Tabla 3-7: Objetivos, eje y bibliografía recomendada para el tema 4....................... 66 Tabla 3-8: Objetivos, eje y bibliografía recomendada para el tema 5....................... 80 Tabla 3-9: Matriz de compatibilidad para protocolo de granularidad múltiple........... 92 Tabla 3-10: Objetivos, eje y bibliografía recomendada para el tema 6..................... 94

Capítulo 1: Introducción

Introducción

2

Introducción. La carrera de Licenciatura en Computación, nace en el seno del Departamento de Estadística Matemática de la Facultad de Ciencias de la UNAN - León en el año 1993. Las tareas del estudio de factibilidad y del diseño de los componentes curriculares estuvieron a cargo de profesores de dicho Departamento. Se realizó una serie de visitas a Universidades públicas y privadas ubicadas en la ciudad de Managua, para solicitar información e intercambiar ideas y experiencias al respecto de la futura empresa. El perfil del profesional descansaba en la formación que el estudiante recibiría en lenguajes y técnicas de programación, con énfasis en el desarrollo de software. En esta época moderna, en donde la base del poder competitivo es la información, las empresas y organizaciones se ven en la necesidad de contratar especialistas en el área de sistemas de información con un enfoque administrativo, y que a su vez sean capaces de afrontar los rápidos cambios tecnológicos. El Departamento de Computación, en su afán de obtener como resultado profesionales que contribuyan al desarrollo local como nacional en el ambiente tecnológico, se encuentra en una continua transformación. El personal docente como pilar fundamental de las estructuras del departamento en aspectos académicos, en un perpetuo ciclo de renovación de conocimientos, está impulsando la elaboración de proyectos docentes que contribuyan a la consolidación de los planes académicos de este departamento.

En el presente documento se desarrolla un plan docente para la asignatura Bases de Datos II que será impartida en la carrera de Ingeniería en Sistemas de Información que es ofertada por el Departamento de Computación en la Facultad de Ciencias de la UNAN-León. Esta asignatura dentro del plan de estudios constituye el eje troncal para el tercer año de Ingeniería en Sistemas, es por ello, que el departamento considera de suma importancia la elaboración del proyecto docente relacionado a este componente curricular.

Este documento presenta la situación actual, relación con otras asignaturas, metodología y material didáctico para impartir la asignatura. También se describirá la metodología de evaluación, así como la presentación del contenido teórico y práctico. El desarrollo del proyecto se plantea en dos partes. En la primera se hace un análisis de los aspectos relacionados con las características docentes y el método para impartir la asignatura de Bases de Datos II. En la segunda parte se incluyen los elementos, tanto teóricos como prácticos, que constituyen el material didáctico necesario para dicha asignatura.

La asignatura de Bases de Datos II, es de carácter obligatorio, y se imparte en el VI semestre de la carrera de Ingeniería en Sistemas de Información. Cuenta con 4 horas a la semana para la clase teórica, y 2 horas semanales para el laboratorio. Este documento servirá como guía de los elementos claves que se deben impartir en la asignatura de Bases de Datos II. El proyecto docente deja abierta la posibilidad de que el profesor encargado de la asignatura aplique sus propios criterios del curso, haciendo énfasis en aquellos temas que considere conveniente.

Objetivos

3

Objetivos generales. Los objetivos generales del proyecto son:

• Desarrollar un proyecto docente que sirva como guía de la temática teórico-práctica para la asignatura de bases de datos II.

• Proponer una metodología para la elaboración de proyectos de aplicaciones

de bases de datos complejos, basados en patrones de prácticas sencillas en laboratorio.

Objetivos específicos

• Trazar estimados temporales de asignación para cada uno de los módulos que forman parte del componente curricular.

• Capacitar al estudiante por medio de prácticas cortas en laboratorio, para

luego dirigir proyectos de bases de datos completos.

• Incentivar en el estudiante la creatividad, la capacidad de trabajo en grupo y formación autodidacta a través de la investigación.

• Brindar al estudiante una visión general de las estructuras que dan soporte a

los sistemas de bases de datos.

Desarrollo del proyecto Fase 1: Establecer las asignaturas que tienen influencia y se relacionan estrechamente con la asignatura de Bases de Datos II. Fase 2: Indicar material, método didáctico, planificación temporal global, metodología de evaluación y contenido del temario. Fase 3: Desarrollo del temario. Aquí se plantean objetivos generales y la bibliografía que se ha utilizado para el desarrollo de cada aspecto teórico, así como material auxiliar donde el alumno pueda profundizar y consolidar los conocimientos tratados en clase. Fase 4: Desarrollo de las prácticas sugeridas para la asignatura de Bases de Datos II. Cada práctica contiene una breve reseña de los elementos teóricos que el estudiante debe dominar para desarrollar el módulo práctico propuesto. La modalidad de cada práctica tendrá una dinámica guiada, en donde el estudiante va paso a paso incorporando nuevos elementos que le permitirán presentar un proyecto final de una aplicación completa de bases de datos.

Tabla 0-1: Fases de desarrollo del proyecto

Capítulo 2 : Plan de Estudios y Metodología Docente

Bases de Datos II en el plan de estudios de ISI

5

2.1 Bases de datos II en el plan de estudios de Ingeniería en Sistemas Es importante resaltar las relaciones que tienen los distintos cursos que componen un plan académico, debido a que el proceso de enseñanza no consiste en el atesoramiento de un conjunto de islas de conocimiento, si no en la asimilación de distintas disciplinas que se relacionan entre sí.

Es con las asignaturas que tienen una estrecha relación con Bases de Datos II, con las que hay que realizar un mayor esfuerzo de coordinación para que al alumno se le presenten los contenidos en el orden más adecuado, evitando repeticiones innecesarias y la posibilidad de que algún tema de interés no se imparta en ninguna.

Por lo anterior es que se hace necesario mostrar y establecer la relación entre las asignaturas del plan académico con Bases de datos II, relación que se muestra gráficamente a través de la figura siguiente.

Ilustración 2-1: Relación de la asignatura con otros componentes curriculares

Programación II IV Semestre

Algoritmos y Estructuras

de Datos V Semestre

Bases de Datos II VI Semestre

Bases de Datos I V Semestre

Plan de estudios y metodología docente

6

2.1.1 Programación II. La programación a lo largo de la carrera constituye uno de los ejes troncales más importantes en la carrera, esta asignatura esta relacionada con la mayoría de los componentes curriculares del plan académico. La relación con Base de Datos II se esta concentrada en los siguientes temas:

FUNCIONES ESTÁNDAR DE E/S: · Manipulación de Ficheros en el Disco. · Apertura y cierre de Ficheros. · Detección de Errores. · Diferentes tipos de E/S. · Comandos que controlan el Buffer. · Ficheros Temporales. · Comandos para el Acceso aleatorio. ESTRUCTURAS DINÁMICAS : · Listas Lineales y sus Operaciones Básicas. · Pilas, Colas, Listas Circulares, Listas Doblemente Enlazadas. · Ordenación de ficheros en Disco.

Tabla 2-1: Relación de la asignatura con Programación II.

2.1.2 Algoritmos y estructuras de datos. Las estructuras de datos juegan un papel fundamental a lo largo del curso de Bases de Datos II. El estudiante debe llegar con bases sólidas en esta rama para aplicar los conocimientos adquiridos en algoritmos y estructuras de datos a los temas relacionados con el diseño físico de las bases de datos. Los temas que se consideran cruciales en la relación son los siguientes:

CLASIFICACIÓN DE DATOS · Clasificación de Datos · Búsqueda de Datos. · Secuencial · Binaria. · Cadenas. · Algoritmo de Hash. · Array Hash · Método Abierto de Hash

Tabla 2-2: Relación de la asignatura con algoritmos y estructuras de datos.

Bases de Datos II en el plan de estudios de ISI

7

2.2.3 Bases de datos I. La asignatura de Bases de datos se divide en dos componentes que se imparten en el primer y segundo semestre del tercer año de la carrera de Ingeniería en Sistemas de Información. El primer curso prepara al alumno con una visión general de los sistemas de bases de datos desde un punto de vista lógico. El comportamiento de los sistemas de bases de datos se trata a nivel de administración y gestión. En la segunda parte se le exponen las estructuras que dan soporte a este tipo de sistemas. Para dar una idea más clara de la estrecha relación entre estos dos módulos el primero consiste en aprender a manejar un carro, sin preocuparse de los detalles mecánicos de cómo el automóvil nos lleva de un lado a otro. En este primer punto se aprende a encender el carro, meter cambios, manejar el sistema de luces, etc. En el segundo módulo nos preocupa conocer la estructura interna del motor, sistema de frenos, sistema de suspensión, etc. De forma que utilizando unos componentes u otros le saquemos el máximo rendimiento al vehículo. Como se ha expuesto, hasta ahora ambas asignaturas se complementan. Es necesario que el estudiante en el primer curso desarrolle destreza al enfrentar problemas de diseño de bases de datos a nivel lógico. También aconsejo agilidad en la elaboración de consultas al sistema con cierto grado de complejidad, este segundo aspecto es crucial para tratar los laboratorios que se proponen en este plan docente. Los tópicos que tienen una mayor relación de esta asignatura con Bases de datos II son:

INTRODUCCIÓN A LAS BASES DE DATOS · Objetivos de las Bases de Datos · Modelos de Datos · Manejador de Base de Datos MODELO ENTIDAD RELACIÓN · Entidades y Conjuntos de Entidades · Relaciones y Conjuntos de Relaciones · Diagrama de Entidad Relación EL MODELO RELACIONAL · Estructura de las Bases de Datos Relacionales · El Algebra Relacional MODELO FÍSICO DE LA BASE DE DATOS · SQL

Tabla 2-3: Relación de la asignatura con bases de datos I

Plan de estudios y metodología docente

8

2.2 Metodología docente La metodología a utilizar para impartir esta asignatura serán las lecciones magistrales con una duración de 2h:00m, con una frecuencia de 2 veces a la semana. Durante el semestre se propondrán la realización de trabajos investigativos que le permitirán al alumno profundizar en la materia, y que a su vez le permitirán desarrollar su capacidad autodidáctica, de búsqueda y uso de la información.

2.2.1 Material y método didáctico.

El material didáctico para impartir las clases será la pizarra clásica y el uso de retroproyector con retrotransparecias, este modelo se aplicará en el curso teórico de la asignatura. Para el curso práctico se recomienda la utilización del datashow, debido a la naturaleza de la exposición de determinados casos prácticos. La figura siguiente muestra la división general para desarrollar las lecciones magistrales:

4%

4%

42%

42%8% Resumen de la clase anterior (5 min)

Contenido y objetivos (10 min)

Primer bloque (50 min)

Segundo bloque (50 min)

Receso interbloque (10 min)

Ilustración 2-2: Desarrollo de las clases magistrales

El alumno podrá complementar las clases, aclarar inquietudes y realizar

preguntas relacionadas con la asignatura, a través de tutorías. Las cuales, están propuestas fuera del aula en un horario determinado, brindado por el profesor al principio del curso.

La asignatura constará con un sitio Web con toda la información, apuntes y material de apoyo sobre la misma, así como enlaces que se consideren de importancia y a través de los cuales se podrán hacer consultas al profesor y descarga de software necesario para las prácticas.

El estudiante también tendrá acceso en forma impresa a todo el material disponible en la Web de la asignatura, así como a la bibliografía básica y complementaria de la misma, que estarán disponibles en el Departamento para su debido uso. Se contemplan para este curso una serie de ejercicios que se proponen al finalizar cada capítulo, con el objetivo de fomentar en el estudiante la formación autodidacta.

Metodología docente

9

2.2.2 Metodología de evaluación. La asignatura está compuesta por clases teóricas y prácticas. La relación entre ambos aspectos no es directa, es decir, la cantidad de material teórico impartido en un determinado momento no indica de forma directa el avance práctico, es por esta razón que ambos aspectos se evalúan de forma independiente. A lo largo del semestre se realizarán dos evaluaciones parciales que corresponderán al 60% de la nota y el restante 40% se obtendrá de una evaluación final. Las evaluaciones parciales están compuestas por un examen teórico con el 60% de la nota parcial y un 40% correspondiente a las prácticas de laboratorio. En la figura siguiente se resume lo expuesto:

12%

18%12%

24%

18%16%

1er Parcial(Teoría)1er Parcial(Práctica)2do Parcial(Teoría)2do Parcial(Práctica)Examen Final(Teoría)Examen Final(Práctica)

Ilustración 2-3: Distribución de las evaluaciones en el semestre

Los exámenes escritos constarán de preguntas teóricas directas que

permitan evaluar el grado de comprensión de los conceptos básicos que tiene el estudiante. También contendrá preguntas de carácter analítico, en las cuales el alumno deberá realizar un análisis a partir de los conocimientos teóricos adquiridos. Se harán preguntas de carácter práctico, donde el estudiante tendrá que aplicar los conocimientos teóricos en casos prácticos.

Los estudiantes deberán realizar todas las prácticas establecidas en tiempo y forma para poder tener derecho al 40% correspondiente al laboratorio. El valor de cada práctica será proporcional entre el número de prácticas realizadas en cada evaluación parcial. El estudiante deberá mostrar cada práctica funcionando, responder a las preguntas hechas por el profesor y entregar una memoria que contendrá lo siguiente: • Explicación de la solución. • Código comentado (cuando proceda). • Conclusiones y comentarios

Final: 40% Parciales: 60%

El estudiante debe acumular al menos el 30% de la nota parcial para tener derecho a presentar el examen final

Capítulo 3 : Desarrollo del temario para Bases de Datos II

Introducción

11

3.1 Introducción. La asignatura de Bases de Datos II, es de carácter obligatorio, será impartida en el VI semestre de la carrera de Ingeniería de Sistemas de Información. Cuenta con 4 horas a la semana para la clase teórica y 2 horas semanales para encuentros prácticos.

En esta asignatura se le mostrarán al estudiante las distintas estructuras y algoritmos que dan soporte a un sistema de bases de datos. Aquí se describirá en detalle cada uno de los componentes necesarios, así como diversas técnicas para implementar un sistema de bases de datos. Se pretende que el estudiante con los conocimientos que adquiera en esta asignatura logre obtener el máximo rendimiento al gestionar y administrar bases de datos.

La asignatura de Bases de Datos II está dividida en tres ejes: almacenamiento de datos y consultas, gestión de transacciones y recuperación del sistema frente a fallos. A continuación, se hará una breve descripción de cada uno de estos ejes: • El primer eje consiste en dar una visión general de cómo influyen los

diferentes dispositivos y técnicas de almacenamiento sobre el rendimiento del sistema de bases de datos. Aquí se estudian temas como: medios de almacenamiento, sistemas RAID, organización de archivos, indexación y asociación, procesamiento de consultas, etc.

• El segundo eje toca un punto sensible en cuanto a la administración y gestión

de las bases de datos, aquí se tratan todos los conceptos relacionados con la manipulación de transacciones. También se discuten algunas técnicas de control de concurrencia.

• En el tercer eje se discuten temas relacionados a las distintas alternativas

que existen para tratar los fallos que se pueden presentar en entornos que manejan información.

3.1.1 Objetivos Los objetivos generales de esta asignatura son: • Desarrollar en el estudiante habilidades de simulación de las distintas

técnicas de diseño e implementación de modelos relacionales y la correspondencia con los sistemas de archivos.

• Capacitar al estudiante en el estudio de las distintas técnicas disponibles

para implementar mecanismos de búsqueda sobre datos, optimización de consultas y gestión de transacciones en sistemas de bases de datos.

• Brindar una visión general sobre la panorámica actual de las diferentes

arquitecturas que se pueden aplicar a sistemas de bases de datos.

Desarrollo del temario de Bases de Datos II

12

3.2 Planificación temporal Partiendo del calendario académico propuesto por la UNAN-León y tomando en cuenta que la asignatura será impartida durante el segundo semestre del año, obtenemos que se cuenta con un total de 17 semanas, pero considerando los días festivos y dando margen a otras incidencias que puedan ocurrir durante el semestre, podemos deducir que se tienen 16 semanas efectivas para cumplir con el con el contenido de la asignatura.

Para el desarrollo de la parte teórica de la asignatura se cuenta con dos períodos semanales de dos horas cada uno, por lo tanto se tienen un total de 64 horas. Para el laboratorio se cuenta con una semana menos, la cual es dedicada para la organización de los grupos, lo que resulta en 15 laboratorios durante el semestre, para un total de 30 horas. La planificación se muestra en la tabla siguiente: No. Unidad didáctica Clase

magistral Clase práctica

Horas Totales

I Almacenamiento y estructuras de archivos. 4 2 12 II Indexación y asociación. 4 2 12 III Procesamiento de consultas. 5 1 12 IV Transacciones. 4 1 10 V Control de concurrencia. 4 1 10 VI Recuperación frente a caídas del sistema. 3 1 8

Tabla 3-1: Distribución temporal de los temas teóricos de la asignatura

Ilustración 3-1: Avance programático basado en 16 semanas

Tema 1: Almacenamiento y estructuras de archivos de bases de datos

13

3.3 Almacenamiento y estructuras de archivos de bases de datos.

Hasta ahora el estudiante tiene conocimientos principalmente orientados al diseño y administración del sistema de bases de datos, las áreas de estudio más importantes que se abordaron en el primer curso fueron: • Representación de los elementos en la base de datos a un nivel conceptual

(E-R). • Una vez que el estudiante tenía ese esquema general de la base de datos,

aprendió a obtener información (lenguajes de consulta, énfasis sobre SQL). • Por último, estudio un mecanismo que le permitiera decidir si el diseño de la

base de datos propuesto cumplía con ciertos parámetros (Normalización).

Se tiene proyectado para este tema un total de doce horas, de las cuales ocho se utilizan para las lecciones magistrales y cuatro horas para desarrollar clases prácticas con los estudiantes. La tabla siguiente muestra una visión general de este tema.

TEMARIO

3.3.1 Visión general de los medios físicos 3.3.2 Técnicas de organización de discos: Sistemas RAID 3.3.3 Acceso al almacenamiento: gestor de memoria intermedia3.3.4 Organización de archivos 3.3.5 Diccionario de datos

OBJETIVOS GENERALES

-Estudiar las distintas técnicas y estructuras de datos disponibles para almacenar la información relacionada con la base de datos. -Que el estudiante sea capaz de aplicar en sistemas de bases de datos las distintas técnicas de protección de la información basadas en implementaciones RAID. -Que a través del conocimiento del funcionamiento y características de los distintos medios que dan soporte al almacenamiento de información aprenda a optimizar recursos para una explotación máxima del sistema de bases de datos.

EJE -Almacenamiento de datos y consultas.

BIBLIOGRAFÍA BÁSICA

-FUNDAMENTOS DE BASES DE DATOS. Korth, Silberschatz y Sudarshan. Mc Graw Hill. {4ª Ed. CAP11} -FUNDAMENTOS DE BASES DE DATOS. Korth y Silberschatz. Mc Graw Hill. {2ª Ed. CAP7}

Tabla 3-2: Visión general del tema 1


14

3.3.1 Visión general de los medios físicos Los medios de almacenamiento se clasifican según la tripleta: Velocidad-Coste-Fiabilidad, los más importantes: • Caché: Pequeña, Rápida y Costosa (Control HW). • MP: Operar de forma rápida cierta cantidad de datos (Obviamente en la

mayoría de los casos no alcanza toda la base de datos). • Memoria Flash: Electrically Erasable Programmable Read Only Memory

(EEPROM). Acceso en el orden de 100ns[0,001ms]. Solo para volúmenes de datos pequeños (5 a 10Mb): Agendas electrónicas, cámaras digitales, computadores de bolsillo. (Escritura lenta).

• Discos magnéticos: Principal medio de almacenamiento a largo plazo de los

datos (toda la base de datos). Tamaña típico 80Gb, crecimiento promedio del 50% anual.

• Almacenamiento óptico: ofrece gran portabilidad y coste muy bajo

(respaldo de información poco variante). Compact Disk (CD): 640Mb, 700Mb. Digital Video Disk (DVD): 4-17Gb.

• Cintas Magnéticas: Copias de respaldo. Dispositivos bastantes baratos.

Acceso secuenciales (lentos). Almacenan volúmenes de información en el orden de los 20Gb-1Tb.

La siguiente gráfica muestra los dispositivos de almacenamiento más

utilizados. Como se puede observar a medida que descendemos en la pirámide nos vamos encontrando con dispositivos de mayor capacidad de almacenamiento, pero con velocidades de acceso más lentas.

Ilustración 3-2: Relación Velocidad-Coste-Capacidad


15

Uno de los dispositivos de almacenamiento que tiene gran influencia sobre el

desempeño de los sistemas de bases de datos son los discos magnéticos, es por ello que comentaremos sus características más sobresalientes. Discos magnéticos Las características principales de estos dispositivos son las siguientes:

• Motor giros de 60, 90, 120 hasta 250rps.

• Tamaño típico de sector 512 Bytes.

• 16,000 pistas (2 a 4 platos / 2 caras).

• 200 a 400 sectores por pista.

Ilustración 3-3: Estructura interna de un disco duro

Los fabricantes generalmente se rigen por estándares de fabricación según las prestaciones que debe ofrecer cada dispositivo, entre las interfaces de discos más populares actualmente están las siguientes: • Interfaz ATA (AT Attachment): Conocida también como Ultra-DMA, soporta

velocidades de transferencia 33 a los 66 MBytes por segundo. • Interfaz SCSI (Small Computer-System Interconnect Interface):

Velocidades de transferencia 40 a 300 MBytes por segundo. • Interfaz IDE (Integrated Drive Electronics): Velocidades de transferencia

de 4 a 16 MBytes por segundo. Para comparar un HD con otro se suelen analizar los siguientes parámetros: • Tiempo de Acceso (solicitud L/E: Tbúsqueda + Tlatencia). • Tiempo de Búsqueda (del siguiente sector 2..30ms). • Latencia Rotacional (Esperando que pase el sector 4..11ms). • Velocidad de Transferencia de Datos (ver tipos de disco). • Tiempo Medio entre Fallos (el período de vida esperado es de 5 años).


16

La unidad de transferencia básica entre memoria principal y disco se

denomina bloque de disco, existen algunas técnicas que optimizan estas transferencias. Algunas de las técnicas que mejoran los accesos son las siguientes: • Planificación: Aplicar algoritmos de planificación sobre el brazo del disco.

Ejemplo el algoritmo del ascensor -> Barrido en zig-zag, deteniéndose en las pistas (pisos) con solicitudes (pasajeros) pendientes.

• Organización de archivos: Optimizar almacenamientos (misma pista o

cilindro). En los sistemas operativos actuales la organización interna del disco es transparente al usuario. Para aminorar los efectos de fragmentación se pueden utilizar utilitarios para defragmentar.

3.3.2 Técnicas de organización de discos: Sistemas RAID RAID: Redundant Array of Independent (Inexpensive) Disk. Esta técnica intenta mejorar las prestaciones de los sistemas de bases de datos: • Discos “pequeños” baratos que bajo este sistema proporcionan gran

rendimiento y fiabilidad (aunque en la actualidad los sistemas que protegen información con esta técnica utilizan dispositivos de almacenamiento relativamente grandes y no tan baratos, generalmente controladores SCSI).

• Múltiples modos de funcionamiento, con redundancia, paridad de datos,

paralelismo. • Varios niveles dependiendo de la necesidad, generalmente en sistemas de

almacenamiento masivo de datos se utiliza RAID 5.

Los siguientes puntos dan una referencia general de los beneficios que aporta RAID en sistemas de bases de datos con múltiples dispositivos de almacenamiento que utilizan esta técnica:

1.- Mejora de la fiabilidad mediante la redundancia (el sólo hecho de múltiples discos no asegura un sistema fiable), considere lo siguiente:

• Suponga el Tmedio de fallos cada 43,800h (5 años).

• Un sistema compuesto por 15 discos el Tmedio entre fallos será =

43,800/15 (4 meses). La posibilidad de fallos se eleva.

• Si sólo se guarda una copia de los datos, cada fallo genera pérdida.

Solución: Introducir redundancia de datos. La creación de copias de los datos proporcione un sistema más robusto. Crear imágenes o sombras (shadows), define un disco lógico y N dispositivos físicos (un fallo activa una copia). La mejora que se introduce se explica con el siguiente ejemplo: • Suponga que los fallos de los discos son independientes, y agregue a los

cálculos el Tmedio de reparación de la unidad dañada (1 día). El nuevo Tmedio de pérdidas de datos en un sist. con 1 réplica es (43,800)2/2*24 = 4,562 años.


17

2.- Mejora del rendimiento mediante el paralelismo :

• Distribuir los datos entre varios discos (la velocidad de transferencia

de cada proceso de lectura es la misma, pero el número de procesos de lectura por unidad de tiempo ha aumentado).

• Distribuir a nivel de bit. Por ejemplo, un sistema con 8 discos escribir el

bit i de cada Byte en el disco i.

• Distribuir a nivel de bloque o bandas. Asigna el bloque lógico (comienza de 0) i al disco (i MOD n) + 1, en el bloque físico i / n. Ejemplo: Suponer 4(n) discos. Escribir bloque lógico 16, da como resultado el acceso al disco 1, el número de bloque a escribir es el 4.

Técnicas RAID más utilizadas RAID 0. Características más importantes: • Bandas sin paridad. • Si falla un disco falla toda la matriz de discos. • Operaciones de L/E simultáneas. • Almacenaje máximo (no hay paridad). • Mercado: Video digital.

Ilustración 3-4: Estructura RAID 0


18

RAID 1. Características más importantes: • Cada bloque de datos es almacenado simultáneamente sobre dos discos

(Mirroring). • Tolerancia a errores. Frente a fallos carga la réplica. • Desventaja principal: duplicación de la Información. • Mercado: Financiero, Seguridad.


RAID 3. Características principales: • Configuración en banda (un disco dedicado que utiliza paridad a nivel de

sector o de banda). • Las operaciones de lectura no se pueden realizar de forma paralela a todos

los discos (solo datos o solo paridad). • Si falla algunos de los discos de datos la información perdida se puede

recuperar a partir de la información que siga siendo válida y la información de paridad.

• Mercado: Servidores, Intranets. • Esta técnica es válida para empresas pequeñas puesto que como se ha

explicado las ventajas son muchas en relación a la inversión.


19


RAID 5: Principales características: • El bloque de ECC puede caer en cualquiera de los discos, protegiendo al

resto de bandas homólogas. • Se puede aplicar operaciones de lectura de forma paralela a todos los discos. • Mercado: Servidores, Intranets.



20

3.3.3 Acceso al almacenamiento: gestor de memoria intermedia Uno de los principales objetivos del Sistema Gestor de Bases de Datos es minimizar el número de transferencias entre memoria principal y disco. Los recursos disponibles no son infinitos: • Imposible mantener todos los bloques que hay que gestionar en memoria

principal.

• Los datos se almacenan temporalmente en memoria intermedia (BUFFER): Mantiene la copia de una porción de los bloques de la BD.

Se pueden presentar algunos problemas al momento de gestionar esta zona

de memoria: usualmente se encuentra en el buffer una copia con los datos más recientes, pero si el buffer se llena qué bloque se reemplaza? el gestor de bases de datos para dar solución a esta problemática se apoya en el gestor de memoria intermedia, que es el encargado de realizar todas las gestiones referentes al buffer asignado a la base de datos.

Los Gestores de Memoria Intermedia, son gobernados por los sistemas operativos anfitriones de la base de datos. Los SS.OO. utilizan esquemas de gestión de memoria estáticos, en base a previsiones estadísticas. Los SGBD utilizan estrategias para forzar el comportamiento del Gestor de Memoria Intermedia. A continuación se expone mediante una gráfica el mecanismo utilizado para responder a las solicitudes de espacio de memoria intermedia hechos por el gestor de la base de datos.

Ilustración 3-8: Gestor de Buffer de la base de datos


21

Esquema de gestión

• Generalmente los sistemas operativos utilizan LRU/MRU. • Bloques clavados (el sistema operativo debe proporcionar este mecanismo):

Se marca el bloque para forzar mantenerlo en memoria intermedia (limitando las escrituras de ese bloque a disco). Con esto se consigue la menor cantidad de transferencias, mejorando los tiempos de respuestas a la aplicación que ha realizado un solicitud.

• Salida forzada de bloque: Volcado forzado a disco (aunque no se necesite

espacio en memoria intermedia). Este mecanismo gana seguridad en el almacenamiento de la información a costas de la velocidad de respuesta.

En el siguiente ejemplo: Prestatario [X] Cliente (suponer las relaciones en

distintos archivos). Aplicar LRU (Extracción Inmediata): Cuando se completa el procesamiento de un bloque completo de tuplas de propietario (ya no es necesario) indicar al gestor que libere ese bloque. El código siguiente muestra que en este caso sería beneficioso para el sistema utilizar esta política de reemplazo.

For each tupla P de prestatario Do For each tupla C de cliente Do If P[Nombre_Cli]=C[Nombre_Cli] Then Begin Sea X una tupla de Reunión Natural (Resultado) X[Nombre_Cli]:=P[Nombre_Cli] X [Numero_Prest]:=P [Numero_Prest] X[Calle_Cli]:=C[Calle_Cli] X[Ciudad_Cli]:=[Ciudad_Cli] End End End Al código anterior se podría aplicar MRU de la siguiente forma: Eliminar el

bloque de cliente al que se haya hecho referencia más recientemente, será el último bloque al que se vuelva a referenciar (esperar la siguiente iteración). Tenga en cuenta que para cada tupla de prestatario se revisarán todos los bloques de cliente, por tanto una vez comparada la tupla con todos los registros en ese bloque ya no es necesario el mismo, para esa iteración en especifico.

3.3.4 Organización de archivos Generalmente en el entorno de sistemas de bases de datos, cuando hablamos de archivos estamos hablando de una secuencia de registros (por ej, archivo clientes). La correspondencia entre un registro y un bloque rara vez es directa (una vez localizado el bloque hay que aplicar desplazamiento).


22

Podemos organizar los registros en un bloque utilizando: • Registros de tamaño fijo (mayor velocidad de acceso). • Registros de longitud variable (optimización del espacio). Registros de longitud fija A continuación se expone a través de pseudocódigo la definición de un registro de longitud fija:

EJ: Type Deposito=Record numero_cuenta: char(10); nombre_sucursal: char(22); saldo: real;

Problemas de este enfoque: • Dificultad de borrado: Lagunas (problemas para identificar las entradas

libres). • Dificultad de almacenamiento: Si el tamaño del registro no es múltiplo del

tamaño de bloque, se necesitan dos accesos, un ejemplo de este caso se muestra en la figura siguiente.

Ilustración 3-9: Dificultad de almacenamiento en registros de longitud fija

Tipos de borrado a) Desplazar: esta técnica consiste en desplazar todos los registros hacia

adelante de forma que el espacio que quedó libre con el borrado sea llenado. Este tipo de técnica de borrado genera bastante sobrecarga en el disco debido a la gran cantidad de desplazamientos que se tienen que hacer si el número de registros es grande.

Ilustración 3-10: Borrado por desplazamiento en registros de longitud fija

Char ASCII, 1 byte. Real 8 bytes. Total 40 bytes

200Metropolitana C-05

900Ciudad Jardín C-04

800Las Fuentes C-03

500Chinandega C-02



23

b) Pasar el último: esta técnica consiste en pasar el último registro al espacio

que estaba ocupado por el registro eliminado.

Ilustración 3-11: Borrado pasar último en registros de longitud fija

c) Cabecera de archivo: Se agrega a la estructura que albergará a los

registros, un puntero que se utilizará en ciertas ocasiones para indicar la siguiente posición de inserción de nuevo registro. También es necesario para esta técnica, un puntero de cabecera que indique el inicio de la lista de punteros de espacios vacíos. Si no existen espacios vacíos el nuevo registro se añade al final.

Ilustración 3-12: Borrado utilizando cabeceras de archivo

Registros de longitud variable Este tipo de estructura para almacenar registros se utiliza en bases de datos con varios tipos de registros en un mismo archivo, por ejemplo, el Motor Jet de Access. También se suele emplear en registros que permiten longitudes variables de sus campos es decir, no se conoce a priori su tamaño real, por ejemplo un campo que almacena fotografía. Otra posible utilización de registros de longitud variable puede observarse en campos que permiten campos multivalorados (suponga un campo teléfono con los valores: 311-3345, 311-3045. etc.).


900Ciudad Jardín C-04

800Las Fuentes C-03

500Chinandega C-02


Psig …... Vacío, listo ……

200

800 ….. 700

Metropolitana C-05

Las Fuentes C-03 Psig Vacío, Listo …… Metropolitana C-01

NULL


24

El siguiente trozo de código hace referencia a una posible definición de un

registro de longitud variable. Type lista_cuentas = record nombre_suc: char(22); info_cuenta: array [1..N] of record; num_cuenta: char(10); saldo: real; end end Cadenas de byte Las cadenas de bytes insertan registros de cualquier tamaño dentro de un bloque, al finalizar la inserción el sistema pone una marca de fin de registro. Los problemas principales con las cadenas de bytes son los siguientes: • Tener distintas longitudes (dificultad de reutilización de espacio). Hay que

compactar frecuentemente. • No se deja espacio para el crecimiento de un registro, si un registro aumenta

desplaza al resto.

Ilustración 3-13: Ejemplo de estructura cadenas de bytes

Estructura de páginas con ranuras Este tipo de estructura de almacenamiento de registros puede ser una excelente alternativa al mecanismo propuesto anteriormente. Bajo este esquema el bloque que alberga los registro se divide en dos zonas, la primera, contiene características propias de los datos que contiene el bloque como: la dirección de cada registro dentro del bloque, así como la dirección de inicio del espacio libre. La segunda zona son propiamente los datos almacenados más el espacio libre. Los registros se añaden empezando por el final del bloque. Las principales funciones de manejo de datos con páginas con ranuras son las siguientes: • Inserción: Se agrega una entrada al array, se inserta el registro al final del

espacio libre. Por último, actualizar el puntero de espacio libre.

• Borrado: Se pone su entrada a vacío (-1), se desplazan los registros que habían antes que él y se actualiza el resto de la cabecera.

Zona Variable


25

El costo de actualización del bloque no es alto y se reduce la fragmentación

del espacio no utilizado. La siguiente figura muestra la estructura de un bloque que utiliza este mecanismo para almacenar los registros de una base de datos:

Ilustración 3-14: Ejemplo de estructura de página con ranura

Implementación de registros variables mediante longitud fija Se reserva un espacio máximo asociado a la parte variante de cada registro, si el espacio no se utiliza por completo se rellena con los símbolos de fin de registro. Para efectos del sistema cada registro ocupa todo el espacio reservado. Si en un determinado momento se necesita espacio extra para un registro no se podrá realizar ninguna operación para extender el espacio que se ha reservado para almacenar el registro. Esta claro que si se elige este mecanismo para almacenar registros de longitud variable la tarea más difícil es indicar el espacio extra que se deberá dejar para cada registro.

Si la información variante en el registro no es cercana al máximo, se desaprovecha un espacio considerable si se suman todas las lagunas dejadas por un grupo de registros almacenados de esta forma. En caso contrario esta técnica resulta provechosa.

Ilustración 3-15: Registros variables mediante espacio reservado

Implementación de registros variables mediante longitud fija con punteros Método de listas enlazadas Este método consiste en ingresar un registro maestro dentro de cada bloque, y luego tirar un puntero para cada registro asociado a este primer registro. La estructura por tanto estará compuesta por el espacio ocupado por el registro en sí, más el espacio requerido para apuntar a una posición dentro de un bloque. Recorrer todos los registros asociados a un registro maestro no es más que localizarlo y seguir la lista de punteros tirados a cada detalle de registro asociado.


26

El problema principal de utilizar este método es que solo el primer registro

llena toda la estructura reservada, por tanto, si sumamos todos los espacios no ocupados por los registros enlazados a cada registro maestro, podría resultar en una porción considerable de espacio desperdiciado.

Ilustración 3-16: Registros variables mediante listas

Método de bloque ancla-desborde

Para este método se utilizan dos tipos de estructuras una para los registros maestros y otra para los registros detalle. En el primer tipo de estructura, siempre se tiene un espacio reservado para el registro maestro y un puntero, pero ahora el puntero referencia a estructuras del tipo detalle, en las que únicamente se dejará espacio para almacenar la parte variante de cada registro, este segundo tipo de estructura tiene un puntero que referencia al siguiente detalle del mismo tipo.

Ilustración 3-17: Registro variable mediante bloque ancla-desborde

Organización de los registros en archivos Los registros se pueden organizar de diversas formas, cada mecanismo tiene ventajas y desventajas, los más usuales son: • En montículo: Se colocan los registros en donde haya espacio libre (sin

orden). • Archivos Secuenciales: Orden a partir de una clave (generalmente la llave

primaria). Esto es válido sólo para bloques que guardan información de la misma relación.

• Organización Hash: Dependiendo del resultado de la función elegida se

coloca el registro en uno u otro bloque. • Agrupaciones: Los registros de distintas relaciones se guardan en el mismo

bloque.


27

Archivos secuenciales

Los archivos secuenciales son bastantes utilizados como mecanismo para albergar registros de una base de datos, estos facilitan principalmente la implementación de índices sobre los datos almacenados, lo que acelera la recuperación de la información utilizando algoritmos sencillos de implementar. Las características principales de los archivos secuenciales son: • Diseñados para maximizar la capacidad de procesamiento relacionada con

un atributo (usualmente la clave). • El orden de los registros se establece mediante punteros. • Dificultad de mantener el orden físico en procesos de borrado e inserción de

registros.

Ilustración 3-18: Ejemplo de la estructura de los archivos indexados

La inserción se lleva a cabo por clave de búsqueda, o atributo por medio del

cual se encuentra ordenado (lógicamente) el archivo. En el caso de la figura, la clave que establece el orden del archivo son cadenas de caracteres ordenadas alfabéticamente. Cuando se pierde significativamente la correspondencia orden físico-lógico, hay que reorganizar. Aunque la reorganización del archivo consume tiempo, es de vital importancia realizar esta actividad para reducir los accesos a disco al momento de recuperar la información almacenada. Agrupaciones

Esta estrategia es utilizada para bases de datos relativamente grandes en las que se utiliza un único archivo. La gestión del archivo y su estructura es manejada directamente por el Sistema Gestor de Bases de Datos (no por el sistema operativo). Las características de esta estrategia son las siguientes: • Se optimiza su estructura para la ejecución de consultas. • Se mezclan datos de distintas relaciones en el mismo bloque de disco: una

lectura recupera datos de distintas relaciones. • La mezcla de tuplas de distintas relaciones se complementa con punteros

que dependiendo de la situación, permiten acceder a los registros de una relación de forma independiente cuando es necesario.


28

3.3.5 Diccionario de datos El diccionario de datos es el encargado de guardar metadatos (información referente a las distintas estructuras que dan soporte a la información almacenada), entre los cuales tenemos: • Nombres de las relaciones. • Nombres, Dominios y longitudes de los atributos de cada relación. • Vistas y procedimientos almacenados. • Restricciones de integridad (por ejemplo, llaves). • Permisos de seguridad. • Información de contabilidad y auditoria de procesos. • Información sobre índices.

Tema 2: Indexación y Asociación

29

3.4 Indexación y asociación Se tiene proyectado para este tema un total de doce horas, de las cuales ocho se utilizan para las lecciones magistrales y cuatro horas para desarrollar clases prácticas con los estudiantes. La tabla siguiente muestra una visión general de este tema.

TEMARIO 3.4.1 Índices ordenados 3.4.2 Archivos indexados de árboles B+ 3.4.3 Técnicas hashing

OBJETIVOS GENERALES

-Estudiar las distintas técnicas y estructuras de datos disponibles para localizar directamente registros dentro de una base de datos. -Que el estudiante puede establecer criterios de comparación entre las distintas técnicas de búsqueda de la información. -Que a través del conocimiento del funcionamiento y características de los distintos escenarios que dan soporte a los mecanismos de búsqueda de información aprenda a optimizar recursos para una explotación máxima del sistema de bases de datos.



-FUNDAMENTOS DE BASES DE DATOS. Korth, Silberschatz y Sudarshan. Mc Graw Hill. {4 ª Ed. CAP12} -FUNDAMENTOS DE BASES DE DATOS. Korth y Silberschatz. Mc Graw Hill. {2 ª Ed. CAP8}


Los índices son cruciales para la manipulación de información dentro de una

base de datos, a través de éstos se puede acceder a porciones de información evitando la lectura de datos innecesarios. Las técnicas para implementar referencias a registros de la base de datos son diversas, cada una presenta bondades y desventajas, pero todas intentan acelerar los procesos de búsqueda de información. Los conceptos básicos cuando hablamos de indexación son los siguientes: • Índice: Referencia a una porción de la información, generalmente una llave,

para acelerar los procesos de búsqueda. • Dos tipos básicos de índice los ordenados: lista ordenada de valores

donde cada entrada referencia una posición de un dato en concreto. Los asociativos: La ubicación del dato se obtiene mediante la aplicación de una Función.


30

Para evaluar las técnicas de indexación se cuenta con los siguientes criterios: • Tipos de acceso: valor en concreto por ejemplo Va = ‘C-001’. Rango de

valores específico Va like ‘H%’. • Tiempo de acceso: es el tiempo promedio que sobre la estructura de índice

un algoritmo tarda en localizar dato en concreto. • Tiempo de Inserción: es el tiempo que tarda un algoritmo sobre la

estructura de índice en buscar el lugar apropiado para insertar el nuevo elemento, más el tiempo que se dedique para actualizar la estructura del índice.

• Tiempo de borrado: es el tiempo que tarda un algoritmo sobre la estructura

de índice en buscar el lugar donde está ubicado el elemento que se borrará, más el tiempo que se dedique para actualizar la estructura del índice.

• Espacio adicional requerido: para almacenar el los índices. No vale de

nada que tengamos un índice con tiempos de inserción y borrado teóricos maravillosos, si la estructura que se necesita para implementarlo requiere de recursos ilimitados.

3.4.1 Índices ordenados Se aplican sobre archivos ordenados secuencialmente, según alguna clave de búsqueda. El índice cuya clave de búsqueda especifica el orden secuencial del archivo (no necesariamente la llave primaria) se le conoce como índice primario o índice con agrupación (clustering index). El índice cuya clave de búsqueda especifica un orden diferente del orden secuencial del archivo se llama índice secundario o índice sin agrupación (non clustering index). Índice denso Los índices densos utilizan una entrada de índice por cada valor diferente de la clave de búsqueda (aunque se puede lanzar un puntero a cada valor de clave). Debido a que mantienen una entrada para cada valor de forma ordenada, los algoritmos de búsquedas son sencillos de implementar sobre este tipo de estructura.

Ilustración 3-19: Implementación de índice denso


31

Índice disperso Los índices dispersos mantienen una entrada para algunos de los valores clave. Localizar un dato es más dilatado, puesto que ahora el número de registros sobre los que hay que buscar el elemento es mayor, salvo en el mejor de los casos, que la búsqueda corresponda con el valor de la entrada de índice. La tabla índice es más liviana, esto es beneficioso ya que se debe dar menos mantenimiento a la estructura de índice.

La distancia entre una entrada con respecto a otra se hace muy difícil de

calcular por lo que los sistemas lo que suelen hacer es asignar una entrada apuntando al primer elemento de un bloque de datos por cada entrada de índice.

Ilustración 3-20: Estructura de índice disperso

Índices multinivel Este tipo de estructura de índice se hacer realmente necesaria cuando los registros referenciados son demasiados (una tabla con un solo nivel muy grande para mantenerla en memoria principal).

Ilustración 3-21: Estructura de índice multinivel


32

Inserciones en índices densos Se aplica el algoritmo de búsqueda del registro a insertar por el valor clave de búsqueda. Pueden suceder las siguientes situaciones con este tipo de estructura:

1.- El registro no tiene una entrada de índice asociada: con la ayuda del índice se busca la posición adecuada en los bloques ocupados por la base de datos. Una vez que la posición donde se insertará el registro es encontrada, este se agrega a la base de datos y se tira un puntero de ese registro a la entrada de índice adecuada.

Ilustración 3-22: Inserción en índices densos (nueva entrada)

2.- Ya existe una entrada de índice y se reserva un puntero para cada

valor de clave (inclusive claves de valores repetidos). El mecanismo de inserción es el siguiente: se localiza el último de los valores para esa clave dentro de la cubeta de punteros, el nuevo registro se insertará justo después del registro apuntado por el puntero encontrado.

Ilustración 3-23: Inserción en índices densos (un puntero por clave)

3.- Ya existe una entrada de índice y se reserva una entrada de índice

para cada valor de clave diferente. El mecanismo de inserción es el siguiente: se localiza el último de los valores para el cual esa clave es menor dentro del índice, el nuevo registro se insertará justo después del registro apuntado por la entrada de índice encontrada.


33

Ilustración 3-24: Inserción en índices densos (una entrada por clave diferente)

Inserciones en índices dispersos Se asume que el índice almacena una entrada por cada bloque en el archivo de datos. Hay que actualizar el índice si se añade un registro con una llave menor a la que ocupa la primer posición. El proceso de inserción consiste en localizar el bloque de datos donde se insertará el nuevo elemento, si el elemento a insertar es menor que el registro que encabeza ese bloque, el nuevo registro reemplaza el valor de la entrada de índice a ese bloque de disco.

Ilustración 3-25: Inserción en índice disperso

Borrado en índices densos Como se estudió en la parte de inserción utilizando este tipo de estructura, pueden caber dos casos dependiendo de la forma de tirar punteros hacia los registros. De manera general para borrar una entrada de índice el registro que se está eliminando debe provocar que la estructura de índice se actualice, esto sólo puede suceder si el registro eliminado es el último de un conjunto de valores, o encabezaba una lista de valores.


34

1.- El registro era el único con ese valor de clave: se localiza la posición

del registro en el banco de datos y se elimina, luego se elimina su entrada asociada en la estructura de índice.

Ilustración 3-26: Borrado índices densos (única clave)

2.- Existe un puntero para cada valor (se maneja una cubeta de

punteros): se elimina el puntero de la cubeta que referencia la posición dentro del bloque de datos al registro. Si ya no quedan más punteros dentro de la cubeta, la eliminación se trata como el caso anterior.

Ilustración 3-27: Borrado índices densos (un puntero por clave)

3.- El registro encabezaba una lista de valores: se localiza la posición del

registro en el banco de datos y se elimina, luego se apunta a la posición del siguiente registro en la lista de valores.

Ilustración 3-28: Borrado índices densos (primer clave de lista)


35

Borrado en índices dispersos a). El registro borrado era el único registro en ese bloque: si el registro está en

un bloque desborde entonces se eliminan todas las referencias a ese bloque. Si el registro tiene una entrada índice asociada, entonces se elimina esa entrada del índice y los punteros asociados a ese bloque.

Ilustración 3-29: Borrado en índice escaso (eliminar entrada)

b). La entrada apunta al registro a borrar y quedan más llaves dentro del bloque

del registro que será eliminado. La entrada de índice es reemplazada por el siguiente valor dentro del bloque, al mismo tiempo, el puntero de la entrada de índice referencia al nuevo registro cabecera de bloque.

Ilustración 3-30: Borrado en índice escaso (reemplazar por la siguiente clave)

Índices secundarios Los índices secundarios como se había indicado anteriormente mantienen un orden lógico de los datos, a través de la utilización de cubetas de punteros a los valores de clave, esto es necesario debido a que la llave de búsqueda no representa el orden físico del archivo. Se pueden establecer estructuras basadas en índices densos y escasos, a continuación veremos los dos casos.


36

a). Índice denso secundario: esta situación es bastante parecida al caso de los

índices densos con un puntero para cada valor de clave, si teníamos múltiples registros con el mismo valor de clave, se agregaba una sola vez la clave en la estructura de índice y se lanzaba un puntero a la cubeta de referencia a registros. En este caso forzosamente tenemos que tirar desde la cubeta un apuntador a cada valor de clave. La siguiente figura muestra un ejemplo de este caso.

Ilustración 3-31: índice denso secundario por existencias

b). Índice escaso secundario: el puntero de cada cubeta individual señala a los

registros con valores de clave de búsqueda en el rango definido por la propia entrada y el siguiente valor de entrada índice.

Ilustración 3-32: índice escaso secundario por fecha


37

3.4.2 Archivos indexados de árboles B+ Las estructuras propuestas anteriormente para acelerar los procesos de búsquedas de datos pierden eficiencia a medida que el archivo de datos crece. Las estructuras de índice de árbol B+ mantienen su eficiencia a pesar de que el archivo crezca o se reduzca. Un índice de árbol B (balanced) + toma la forma de árbol equilibrado donde los caminos de la raíz a cada hoja del árbol son de la misma longitud. Estructura de nodos Las características de cada nodo están determinadas por su orden n, donde n determina el número mínimo de llaves que puede mantener en un determinado momento cada nodo. En general la características más sobresalientes de este tipo de estructura son:

• Cada nodo puede contener entre n y 2n valores de llave (K). • Cada nodo puede ser una hoja (nodos que referencian a los datos), o un

nodo padre con m+1 hijos (referencian a otros nodos del árbol), donde m es el número de valores de llave en el nodo actual.

• Todos los nodos hoja están al mismo nivel.

Los nodos hoja tienen la siguiente forma:

P1 K1 P2 ... P2N K2N P2N+1

• Los valores de llave se guardan ordenados dentro de un nodo, si el valor de una posición i menor que otra j, entonces Ki < Kj.

• Para i=1,2,..,2n, Pi apunta a un registro del archivo con clave de búsqueda

Ki, a un cajón de punteros (si el archivo no está ordenado por la llave de búsqueda), o bien, al primer registro de una lista (como en los índices escasos).

• El puntero P2n+1 (aprovechando que las claves se encuentran ordenadas)

sirve para encadenar los nodos hoja (procesamiento secuencial eficiente del archivo).

Estructura de los nodos que no son hoja: • Todos los punteros apuntan a otros nodos del árbol. • Para i=2,3,..,2n, el puntero Pi apunta al subárbol que contiene los valores

de clave de búsqueda menores que Ki y mayor o igual que Ki- 1.


38

• El puntero 2n+1, apunta a la parte del subárbol que contiene los valores de

clave mayores o iguales que K2n. • El puntero P1 apunta a la parte del subárbol que contiene los valores de

clave menores que K1.

Para realizar la consulta de los registros con valor de llave k, se examinan los nodos empezando por la raíz y siguiendo el siguiente mecanismo: • Si k(valor buscar) < K1(valor en nodo), se sigue la búsqueda por P1

(Subárbol con los elementos menores).

• Si k > = K2n, se sigue la búsqueda por P2n+1.

• Si Ki-1 <= k <= Ki, se sigue la búsqueda por Pi.

En la práctica el proceso de búsqueda sólo alcanza unos cuantos nodos. Si hay K valores de la clave de búsqueda en el archivo, el camino recorrido no será más largo que Logn(K). Generalmente cada nodo ocupa un bloque de disco. Suponga un tamaño de bloque de 4k, con una clave = 24bytes, un tamaño de puntero a disco = 8Bytes, el número de claves por nodo anda por 128. Si se tienen 500,000 de valores de claves de búsqueda en el archivo de índice B+, una búsqueda necesitaría únicamente Log128(500,000) = 2.70450..86 ≅ 3 accesos (Log(500,000)/Log(128)). Inserción Para insertar un nuevo registro, suponiendo que la llave no existe:

Ilustración 3-33: Inserción árbol B+ (no split en raíz)


39

De forma general cuando se inserta una nueva clave que no ha sido

incorporada en el árbol se realizan los siguientes pasos: • Determinar el nodo hoja i donde se debe hacer la inserción. • Si cabe, se inserta y reordena si es necesario, sino:

-Se crea un nuevo nodo (redistribuir las 2n+1 llaves): poniendo las n primeras en el nodo actual y el resto en el nuevo nodo creado. -Tirar un puntero desde el padre del nodo actual al nuevo hijo.

• La inserción puede generar múltiples split’s, incluso en el nodo raíz, esto

agregaría un nuevo nivel al árbol.

El siguiente gráfico muestra un split sobre un nodo no hoja. Al darse un split sobre una hoja se deja copia de la llave (referencia a los datos). En caso de split sobre un nodo interno no es necesario ya que la información ya esta referenciada en una hoja del árbol.

Ilustración 3-34: Inserción árbol B+ (nodo no hoja)

Borrado en el árbol B+ El procedimiento de borrado suponiendo que la clave a borrar corresponde al único registro en el archivo con esa clave: • Se localiza el nodo hoja i en el que está la llave y se borra. • Si el nodo i se queda con menos de n llaves:

- Considerar el hermano a la derecha del padre salvo que este sea el nodo más a la derecha se considera su hermano inmediato a la izquierda.

- Intentar agregar las llaves de i a su hermano (borrar i). • Si no caben todas las llaves del nodo i, se redistribuyen las m llaves

(ambos nodos): m/2 primeras a la izquierda y el resto a la derecha.


40

La siguiente figura muestra un borrado en puntos del árbol que no generan ni

fusiones ni paso de llaves.

Ilustración 3-35: Borrado en árbol B+ (sin fusiones)

La figura siguiente muestra dos casos: el primero cuando se redistribuyen las

llaves entre nodos hermanos, y el segundo cuando se fusionan dos nodos hermanos.

Ilustración 3-36: Borrado en árbol B+ (fusión de nodos)

Si las hojas apuntan a cubetas de punteros en caso de tratarse de índices

secundarios que referencian múltiples valores o de índices primarios con claves duplicadas, se procede de la misma manera como se ha comentado, exceptuando aquellos casos donde el bucket de punteros no esté vacío.


41

3.4.3 Técnicas hashing Permite ahorrarse el recorrido de una estructura de índice. Se basa en el cálculo de la dirección de un dato, directamente calculando una función sobre el valor de la llave de búsqueda del registro deseado.

¿Cómo elegir una función para aplicar la técnica hashing?

• buscar una distribución uniforme (el número de llaves por cubeta de datos igual para todas las cubetas).

• idealmente todas las cubetas están compuestas por una sola página (evitar

los punteros de una cubeta a otra cuando se sobrepasan el número de llaves por cubeta).

Ejemplo de elección de una mala función hashing para trabajar con llaves

que son cadenas de caracteres: • Las tres primeras letras del valor del string (es una función muy sencilla pero

no resulta una distribución uniforme van a almacenarse más elementos por ejemplo con a/m/n que con z/u).

Una posible corrección del ejemplo anterior. Korth, Silberschatz y

Sudarshan: la suma de todos los caracteres del string donde la letra número i del alfabeto [gringo] esta representada por el entero i modulo b (donde b es el número de cubetas).

Utilizando la función de cálculo anterior realice la tabla de cálculo de dirección para el archivo deposito empleando nombre_sucursal como llave, suponiendo un total de 10 cubetas (0..9).

Ilustración 3-37: Implementación de una fn hash con cadenas de caracteres


42

Extensible hashing La mayoría de las bases de datos crecen conforme pasa el tiempo, si quisiéramos utilizar asociación estática nos encontraríamos con la siguiente problemática:

• Si elegimos una función basada en el tamaño actual del archivo (degradación

conforme éste crezca). • Una función basada en el tamaño anticipado del archivo (un mal cálculo

puede generar desperdicio al comienzo). • Reorganizar periódicamente en respuesta al crecimiento del archivo (nueva

función de asociación, recalcular la función para la nueva organización, nuevas asignaciones de cubetas, lo que redunda en elevado consumo de tiempo)

Existen varias técnicas de asociación que permiten modificar de forma

dinámica la función de asociación para compensar el crecimiento del archivo. Estas técnicas se llaman funciones de asociación (hash) dinámicas. Aquí se abordará la técnica de asociación llamada Extensible Hashing. La siguiente gráfica muestra una estructura de asociación extensible.

Ilustración 3-38: Estructura hashing extensible

Esta técnica funciona de la siguiente manera: • Usar i de b bits para encontrar el resultado generado por la función hash (i

crece a medida que se agregan nuevas llaves en los buckets. • Se agrega un nuevo nivel que se llama directorio (apuntan a los buckets que

contienen las llaves). • Diferentes entradas de directorio pueden apuntar a un mismo bucket. • Asociar con cada bucket la longitud del prefijo común para las llaves en la

cubeta.


43

La siguiente figura muestra el mecanismo de inserción de valores utilizando

la técnica hashing extensible en un conjunto de valores numéricos.

Ilustración 3-39: Inserción utilizando extensible hashing


44

3.5 Procesamiento de consultas Se tiene proyectado para este tema un total de doce horas, de las cuales diez se utilizan para las lecciones magistrales y dos horas para desarrollar clases prácticas con los estudiantes. La tabla siguiente muestra una visión general de este tema.

TEMARIO

3.5.1 Interpretación de consultas 3.5.2 Equivalencias de expresiones 3.5.3 Estimación del costo de procesamiento de consultas 3.5.4 Mecanismos de implementación de las operaciones 3.5.5 Materialización y encauzamiento

OBJETIVOS GENERALES

-Que a través del conocimiento de las distintas estructuras que dan soporte a las consultas en el sistema, el estudiante estructure peticiones a nivel de usuario, que contribuyan al aminoramiento de los tiempos de respuesta de una consulta estructurada en un lenguaje de alto nivel. -Que el estudiante sea capaz de comparar estrategias de tratamiento de consultas, y que pueda identificar cuando un mecanismo de recuperación de información supone un menor coste para el sistema.





3.5.1 Interpretación de consultas No es posible ir modificando las estructuras que dan soporte a los datos almacenados dependiendo de la información que se solicita. Por esta razón y por motivos de acelerar los resultados que se le brindarán al usuario es necesario implementar estrategias de procesamiento de las consultas al sistema. De forma general, se intentará trabajar con datos en memoria principal para aminorar los accesos a disco. Pero la elección de una estrategia consume tiempo, todo lo que supone tiempo extra se intenta excluir en todo proceso, pero en este caso compensa a largo plazo. Distintos caminos pueden generar idénticos resultados:

• Select * from cliente where idcli=‘R-01’ OR idcli=‘R-05’ OR idcli=‘R-10’

≡ • Select * from cliente where idcli in (‘R-01’, ‘R-05’, ‘R-10’)

Tema 3: Procesamiento de consultas

45

Las dos consultas propuestas anteriormente, sugieren un costo distinto de

procesamiento. No entraremos en detalle a discutir cuál es la que el sistema podría ejecutar de forma más eficiente, lo interesante aquí es que podemos observar 2 caminos sugeridos por el usuario, pero no podemos esperar que el usuario tome el camino óptimo. El sistema toma la consulta del usuario y la transforma a una expresión equivalente, que desde el punto de vista de procesamiento sea más eficiente. Las expresiones que el sistema utiliza internamente son equivalencias del álgebra relacional, por lo tanto de ahora en adelante tendremos en cuenta la consulta de alto nivel y su posible representación utilizando álgebra relacional.

Se puede hacer una analogía entre la optimización de consultas y la optimización de código que hacen los compiladores. Al momento de realizar la conversión de la consulta de usuario, el sistema analiza aspectos sintácticos (similar al parseo) y genera errores si los hay. Una vez transformada, comienza el proceso de optimización. Generalmente se elige la equivalencia que tome menos accesos al disco.

3.5.2 Equivalencias de expresiones Utilizaremos los siguientes esquemas para abordar las distintas estrategias de equivalencias que se pueden seguir:

-Esquema_Cliente(nombre_cliente, calle, ciudad_cliente) -Esquema_Deposito(nombre_sucursal, numero_cuenta, nombre_cliente, saldo) -Esquema_Sucursal(nombre_sucursal, activo, ciudad_sucursal) Operación Selección Esta primera estrategia se basa principalmente en adelantar las operaciones de selección para aminorar el tamaño de los resultados intermedios que se van generando antes de llegar al resultado final de la consulta.

Para ilustrar como influyen las operaciones de selección, analizaremos la problemática que trae consigo la consulta: obtener los nombres y activos de las sucursales con clientes que viven en ‘Port Chester’ [CASO1].

πnombre_sucursal, activo ( σciudad_cliente=‘Port Chester’ (cliente|x|deposito|x|sucursal) )

Aunque la propuesta de consulta anterior genera los resultados deseados, tiene algunas deficiencias relacionadas con el proceso de selección: • La relación que se genera de forma intermedia es demasiado grande: cliente

|x| deposito |x| sucursal, cuando el número final de registro es relativamente pequeño.

• Sólo interesan 2 de los 8 atributos de la relación intermedia. Observe la

intersección de los atributos necesario en la figura siguiente.


46

Ilustración 3-40: Campos innecesarios en el proceso de selección

Una de las primeras estrategias que vamos a utilizar para aminorar los

resultados intermedios generados por el proceso de consulta es: realizar las operaciones de selección lo más pronto posible. Considere esta modificación a la consulta propuesta en el caso 1. πnombre_sucursal, activo (( σciudad_cliente=‘Port Chester’ (cliente)) |x|deposito|x|sucursal )

Esta solución no es siempre aplicable: modifiquemos el predicado de la consulta original: encontrar a los clientes que viven en ‘Port Chester’ y tienen un saldo mayor a 1,000. [Caso 2].

¿Puede aplicarse la solución anterior? Ahora el predicado hace referencia a tuplas de dos relaciones distintas. La estrategia utilizada en el primer caso no es válida para esta segunda propuesta.

El caso 2 se puede expresar en algebra relacional de la siguiente forma:

πnombre_sucursal, activo ( σciudad_ cliente= ‘Port Chester’ ^ saldo>1,000 ) (cliente|x|deposito|x|sucursal )

Puesto que el predicado anterior excluye a sucursal, podríamos pensar en un primer filtrado donde participara únicamente la relación cliente y la relación depósito. Si seguimos esta idea podríamos construir en algebra relacional: πnombre_sucursal, activo((σciudad_ cliente= ‘Port Chester’ ^ saldo>1,000

(cliente|x|deposito)) |x| sucursal )

Ahora vamos a reestructurar la expresión anterior basándonos en las siguientes expresiones del àlgebra relacional que son equivalentes:

σp1(σp2(e))=σp2(σp1(e))=σp1^p2(e)


47

Se puede reescribir la subconsulta señalada anteriormente, como:

σciudad_ cliente= ‘Port Chester’ (σ saldo>1,000 (cliente|x|deposito))

A esta nueva expresión si le podemos aplicar la regla “efectuar pronto las selecciones”:

(σciudad_ cliente= ‘Port Chester’(cliente) |x| (σ saldo>1,000 (deposito)) De forma general la segunda regla indica sustituir expresiones de la forma:

σp1^p2(e) por σp1(σp2(e))

La transformación final del caso 2 quedaría: πnombre_sucursal, activo ((σciudad_cliente=‘Port Chester’ (cliente) |x| (σsaldo>1,000 (deposito)))|x|sucursal ) Operación producto natural También se pueden reducir los resultados intermedios de las consultas eligiendo un orden óptimo para las operaciones de producto natural. Recuerde que el producto natural es asociativo:

r1|x|(r2|x|r3) ≡ (r1|x|r2)|x|r3

Vamos a utilizar el siguiente ejemplo para estudiar los conceptos

relacionados al procesamiento de las consultas en la operación de producto natural. Para introducir los distintos escenarios que se pueden presentar consideremos la siguiente expresión en algebra relacional: πnombre_sucursal, activo (( σciudad_cliente=‘Port Chester’ (cliente)) |x|deposito|x|sucursal )

Cómo influye el orden de ejecución del producto natural en el predicado de la consulta anterior: • [Caso 1]: deposito|x|sucursal|x|(σciudad_cliente=‘Port Chester’ (cliente)). Se

procesan todas las cuentas de todas las sucursales. • [Caso 2]: (σciudad_cliente=‘Port Chester’ (cliente))|x|deposito|x|sucursal. Solo las

cuentas de los clientes que viven en “Port Chester”. • [Caso 3]: (σciudad_cliente=‘Port Chester’ (cliente))|x|sucursal|x|deposito. Si hay C

clientes en “Port Chester” y S sucursales, se producen SxC valores intermedios (equivale a un producto cartesiano).


48

Los tres casos expuestos anteriormente, demuestran las grandes variaciones

de los resultados intermedios, que se pueden generar si no se tiene cuidado con el orden de los productos naturales que se van construyendo para generar un solución. Esta claro que la mejor opción es la que se propone en el caso 2, debido a que en esta opción se toman únicamente las tuplas que se necesitan para la solución final. De forma general, se intentará ordenar las relaciones que participan en el producto natural de tal manera que el orden coincida con las necesidades de cada etapa de la consulta. En el caso óptimo propuesto anteriormente se seleccionan las tuplas que satisfacen primeramente una condición, luego ese resultado se combina con la relación que tiene mayor prioridad de combinación, en este caso depósito, por último se realiza el enlace con sucursal para luego filtrar las columnas que interezan. Operación de proyección Reduce considerablemente los resultados intermedios, esta frase se fundamenta en que casi nunca son necesarias todas las columnas de una relación para generar un resultado. Como norma general “hay que realizar pronto las proyecciones” y eliminar atributos excepto: • Si aparecen en el resultado de la consulta. • Se necesitan para procesar operaciones subsecuentes.

Consideremos las mejoras que supone el adelantamiento de las proyecciones, a través del siguiente ejemplo: πnombre_sucursal, activo (( σciudad_cliente=‘Port Chester’ (cliente)) |x|deposito|x|sucursal )

Si elegimos calcular la subexpresión: σciudad_cliente=‘Port Chester’ (cliente) |x|deposito, se generan los atributos intermedios: nombre_cliente, ciudad_cliente, nombre_sucursal, numero_cuenta y saldo (como se puede observar la mayoría son innecesarios). Se puede reformular la consulta así: πnombre_sucursal, activo ((πnombre_sucursal (σciudad_cliente=‘Port Chester’ (cliente)) |x|deposito) |x| sucursal )

Con esta última expresión del álgebra relacional se proyecta el único atributo verdaderamente necesario para generar el resultado de la consulta. Como puede ver se han eliminado la mayoría de los atributos de la relación intermedia “Todos los clientes que pertenecen a Port Chester”, esto se pudo realizar puesto que para los procesos subsecuentes solo es necesario el atributo nombre_sucursal.


49

3.5.3 Estimación del costo de procesamiento de consultas Para elegir una estrategia que reduzca los resultados intermedios, los sistemas de bases de datos suelen mantener información de cada relación. Generalmente, esta información está basada en estadísticos almacenados a partir de ejecución de las peticiones de usuario. Esto quiere decir, que el sistema se guiará por esta información para elegir la estrategia que permita ejecutar, con el menor coste para el sistema la consulta. Alguno de los datos estadísticos que guarda son: • Nr, Tuplas en la relación r. • Sr, Tamaño de un registro (para registros de longitud fija). • V(A,r), Valores distintos en r para el atributo A.

Esta primera aproximación en la estimación del coste de procesar una consulta, supone búsquedas directas sobre las relaciones sin utilizar índices. Vamos a estudiar los principales escenarios que pueden suceder principalmente cuando es necesario realizar la combinación de relaciones para generar resultados.

Con los valores estadísticos anteriores almacenados por el sistema de bases de datos, estimar valores de productos cartesianos consistiría en lo siguiente: suponga dos relaciones r1 x r2, cada relación tiene Nr1 *Nr2 tuplas, cada tupla pesa Sr1 + Sr2 Bytes. A continuación vamos a ver que realizar la estimación para los productos cartesianos hay que tomar en cuenta algunos aspectos extra.

Estimar cuantas tuplas satisfacen <nombre-atributo> = valor. Suponiendo una distribución uniforme, es decir, todos los valores tienen la misma probabilidad de aparecer enlazado con un valor en la otra relación. Esto en algunas ocasiones se aleja bastante de la realidad, consideremos la tabla estudiantes_ISI, tiene una mayor probabilidad de aparecer edad=20, que edad=25. Aunque la distribución uniforme presenta estos inconvenientes es un estimado que permite de forma sencilla realizar los cálculos para estimar costos de procesamiento: • Para la selección σA = a (r), se tienen Nr /V(A,r) tuplas. • Para el producto natural debemos considerar tres casos:

-Conjunto generado es Φ. -Producto basado en una clave. -Producto no basado en atributo clave.

Sean r1(R1) y r2(R2) relaciones:

• Si R1 ∩ R2 = φ entonces r1|x|r2 = r1 x r2. Es decir, el coste de calcular el

producto natural equivale al coste de calcular un producto cartesiano. • Si R1 ∩ R2 es una clave de r1, cada tupla en r2 se exactamente con una

tupla de r1, entonces r1|x|r2 ≤ Nr2. Si R1 ∩ R2 no participa una clave, ya que cada valor tiene la misma probabilidad de aparecer, suponemos que una tupla t en r1 produce Nr2 /V(A,r2), para todo r1= Nr1*Nr2 /V(A,r2).


50

En términos generales, para realizar una estimación del costo de la consulta

utilizando índices o realizando la búsqueda directamente en el archivo:

• Se utiliza el término, número de transferencias de bloques de disco como medida para el coste de ejecución.

• Si se quiere una medida más precisa hay que tomar en cuenta: • Número de operaciones de búsqueda realizadas. • Número de bloques leídos. • Número de bloques escritos (consume más tiempo que la lectura). • Tiempo de CPU.

3.5.4 Mecanismos de implementación de las operaciones Con este tema se pretende conocer los algoritmos y estructuras que se manejan dentro de un sistema de bases de datos para dar soporte a las operaciones básicas del álgebra relacional. Operación de selección Las operaciones, se pueden aplicar buscando predicados que satisfacen una consulta directamente en el archivo, o echando mano de una estructura de índice, en el caso de contar con esta. Como siempre, cada opción tiene ventajas y desventajas dependiendo de la situación y las condiciones del entorno donde se intenta implementar la consulta.

Siempre que se cuente con un índice que referencia a los atributos que

participan en un determinado predicado, es conveniente usarlo, aunque es difícil mantener índices para cada uno de los atributos en la base de datos, si realizamos consultas habitualmente sobre cierto grupo de atributos, conviene tirar un índice sobre estos.

Los exploradores de archivos son algoritmos que recuperan registros que

cumplen una condición, estos algoritmos se aplican directamente al archivo que contiene los registros que se están buscando. Vamos a ir estudiando todos los algoritmos que caben bajo determinadas circunstancias de búsquedas de datos. ALGORITMO 1 (búsqueda lineal) • Exploración bloque a bloque en el archivo de la relación. No nos

apresuremos a decir que el coste de este algoritmo es el tiempo que se tarda en recorrer todos los bloques de la relación, aunque la mayoría de las veces esto es verdad, esta verdad no es absoluta.

• Si la búsqueda es sobre un atributo clave finaliza al hacer match. No hay otro

campo igual dentro de esa relación no tiene sentido seguir el recorrido. • En el peor de los casos el coste es br, donde br es el número de bloques en

la relación r. • No es necesario orden físico de tuplas. Como la exploración examina todo el

archivo, se alcanzan a comparar el 100% de los registros en la relación.


51

ALGORITMO 2 (Búsqueda binaria) • Necesita orden físico por el atributo de búsqueda. Si el orden físico de la

relación no esta basado en los valores del atributo de búsqueda este algoritmo no se puede implementar.

• Realizar búsqueda binaria, genera unos costes relativamente pequeños si

comparamos con la búsqueda lineal. El peor de los casos Log 2 (br), donde br es el total de bloques por los que esta compuesta la relación r.

Selecciones con índices ALGORITMO 3 (índice primario, igualdad basada en atributo clave) • Buscar en el índice para localizar el único registro resultado. La búsqueda se

realiza directamente en el índice una vez encontrado el registro se sigue el puntero asociado que referencia al bloque donde se encuentra el resultado.

• En el peor de los casos (el valor está en el último de los bloques índice): Los

bloques que se analizan son bindice + 1, donde el primero de los sumandos representa el número de bloques que componen el índice, el segundo de los sumandos es el acceso necesario para recuperar el registro en sí.

• Si se usa un B+, el costo es altura del árbol, más un acceso al bloque. que

contiene el registro. ALGORITMO 4 (índice primario, valores repetidos) • Puede recuperar varios registros (única diferencia con ALG3). Si el índice

ocupa un apuntador para cada registro con la misma clave (una entrada en el índice apuntando a la cubeta de punteros que contiene las referencias a disco), hay que sumar las recuperaciones que se hagan de bloques de disco que albergan las cubetas relacionadas a esa clave, usualmente esto no supera un bloque de disco. Aunque lo que se ha comentado anteriormente, es una posibilidad casi nunca se implementa, lo que generalmente se hace, es mantener una referencia sólo al primero de los valores, aprovechando que los registros se encuentran físicamente ordenados.

• Una vez localizado el valor en el índice, recuperar con una exploración lineal

(aprovechar orden físico).

ALGORITMO 5 (índice secundario, igualdad)

• Recordar: la llave de búsqueda no representa el orden físico. • Se pueden recuperar uno o varios registros dependiendo si el atributo es

clave o no. • En el peor de los casos caeríamos en una búsqueda lineal. Aunque se podría

elevar el coste superando a una búsqueda lineal.


52

• En el caso de valores clave utilizando Árboles B+, el coste es igual a

encontrar la clave (altura del árbol), más una operación de E/S para recuperar el registro. Si los valores no son clave, el coste podría superar una búsqueda lineal si el número de registros obtenido es grande. En la figura siguiente se muestra un caso en el que el coste es relativamente grande:

Ilustración 3-41: Selecciones de igualdad con índices secundarios

Selecciones con condiciones de comparación ALGORITMO 6 (índice primario, comparación) Para los casos A > Va o A ≥ Va • A ≥ Va: buscar en el índice hasta A = Va, luego se puede usar un

explorador de archivos para recuperar todos los registros a partir de esa posición.

• A > Va: buscar en el índice hasta A > Va. Luego, como en el caso anterior

se puede utilizar el explorador de archivo para recuperar el resto de registros. Para los casos A < Va o A ≤ Va • A ≤ Va: No es necesario el índice. Recuperar hasta A = Va, donde A

representa el valor en la relación y Va es el valor de búsqueda. Aprovechamos el orden físico, y le indicamos al explorador de archivos que retorne los bloques que contienen registros con valores menores que Va, incluyendo A = Va, si procede.

• A < Va: Recuperar hasta A > Va sin incluir éste último. ALGORITMO 7 (índice secundario, comparación) La mecánica es idéntica a la ocupada en un índice primario. Si la selección genera resultados grandes podría ser más cara esta opción que una recuperación lineal. Volvemos al caso en el que una cubeta de punteros que referencia a los valores que se desean recuperar, puede retardar considerablemente el proceso de implementar la comparación. A continuación se muestra una figura donde se expone un caso en el que el coste se eleva tanto que supera la búsqueda lineal.


53

Ilustración 3-42: Selecciones de comparación con índices secundarios

En la figura anterior, se propone recuperar los valores menores que el

valor 12, en una estructura de índices la mecánica es ir recorriendo el índice hasta que la condición sea falsa, y recuperar los bloques que están referenciados por los punteros en cada cubeta. Como puede observar la entrada de índice que contiene el valor cinco, apunta a una cubeta que referencia a los bloques uno, cinco y seis. Si el buffer del sistema albergara como máximo 3 bloques de disco, la lectura de los bloques asociados al valor seis, generarían dos reemplazos. Implementación de selecciones complejas • Hasta ahora sólo se han considerado condiciones de selección simple, en

donde se pasaba un valor que se comparaba con los registros de una determinada relación. Pueden darse dentro de una solicitud de usuario peticiones de comparación más complejas de la forma: σθ1^θ2,..,^θn (r). A continuación vamos a exponer los algoritmos que tratan operaciones de conjunción concatenadas.

ALGORITMO 8 (Selección con operaciones conjuntivas concatenadas) • Elegir un algoritmo para cualquiera de las selecciones simples θi (el que

represente el menor coste). • Con los valores recuperados en memoria intermedia comparar el resto de

condiciones. • En este tipo de casos si una de las condiciones falla, no tiene sentido seguir

comparando el resto de conjunciones. ALGORITMO 9 (Selección conjuntiva utilizando índice compuesto) • Conveniente para 2 o más θi de la forma: A = Va. Debido a que este tipo de

índice mantiene referencias a los registros de una determinada relación a través del enlace en dos campos diferentes, es necesario que la consulta del usuario involucre a los campos que componen el índice.


54

• El tipo de índice determina el algoritmo a utilizar: si la estructura de índice

está soportada sobre un conjunto de valores cuyo orden lógico corresponde al orden físico del archivo y además forman la llave primaria de la relación entonces podríamos considerar el algoritmo tres (índice primario sobre atributo clave) visto anteriormente, si la consulta no cumple la última de las características expuestas se puede considerar el algoritmo cuatro (índice primario sobre atributo no clave). El último de los casos a considerar es que el orden lógico de las claves no corresponde al orden de los registros que mantienen esos valores en el archivo, en este caso consideraremos el algoritmo cinco (índice secundario).

Por ejemplo suponga la relación persona(nomb, apell, sexo, edad), donde la llave primaria de esa relación está conformada por los atributos: nomb y apell. Además se forma un índice compuesto a partir de esos dos atributos.

Ilustración 3-43: Implementación de selección sobre índices compuestos

ALGORITMO 10 (Selección mediante intersección de identificadores) • Necesita punteros directamente a registros o identificadores de registro. • Para cada condición se examina el índice apropiado (todavía no se

recuperan los registros). • La intersección de todos los punteros recuperados forman el conjunto de

punteros a tuplas que satisfacen la condición conjuntiva.

La siguiente figura muestra un ejemplo de cómo se lleva a cabo éste algoritmo. Observe que se recuperarán dos punteros que contendrán direcciones idénticas, esto es debido a que el registro seleccionado en el ejemplo cumple con ambas conjunciones: el valor de nombre es ‘Ernesto’, y el valor de ciudad es ‘León’.

Ilustración 3-44: Implementación de selección mediante intersección de punteros


55

El tipo de mecanismo anterior necesita que cada atributo que participa en las

condiciones del predicado de la consulta tenga asociado una estructura de índice. Los sistemas que utilizan esta alternativa de recuperación de registros suelen ordenar los punteros recuperados para aminorar los accesos a disco. Por ejemplo, considere que se recuperan los punteros P3, P5, P1, P1, P3, P5 que referencian a los registros R1, R3, R5 en el archivo de bases de datos alcanzan dos registros por bloque. Suponga que R1 y R3 se encuentran en el mismo bloque de disco, la intersección de los punteros recuperados genera el conjunto de punteros {P3, P5, P1}. Teniendo un tamaño de memoria intermedia de la base de datos igual al espacio ocupado por un bloque de disco, los accesos generados por: P3, P5, P1 no son los mismos que si se implementa el orden P1, P3, P5.

De forma general, en este algoritmo el coste es la suma de los costes de exploraciones de índice más el coste de acceder propiamente a los registros. Resumiendo lo expuesto anteriormente, cuando trabajemos con esta técnica: -Ordenar la lista de punteros y recuperar en orden los registros. -Los punteros a los registros de un bloque van juntos (única operación E/S). -Lectura de bloques ordenada (minimiza los tiempos de búsqueda). ALGORITMO 11 (selección disyuntiva mediante la unión de identificadores) Si se disponen de caminos de acceso (apuntadores para cada campo), para cada condición se explora cada índice en busca de punteros que cumplan esa condición. La unión de todos los punteros recuperados es la solución. Si alguna de las condiciones no tiene un índice asociado, hay que hacer una búsqueda lineal, para este caso conviene no utilizar índices del todo. Ordenación de resultados Si la relación cabe completamente en el buffer de memoria principal utilizado para la gestión de la base de datos, se pueden aplicar algoritmos de ordenación clásica como quicksort. Si los elementos a ordenar no caben en el buffer, se debe utilizar una técnica de ordenación externa, como ordenación-mezcla-externa. El proceso de ordenación es crucial para la ejecución óptima de algunas operaciones como el producto natural.

ALGORITMO: Ordenación-Mezcla-Externa: Se cuentan con M marcos de página (suponemos que un marco ≅ un bloque de disco). La primera etapa consiste en crear varias secuencias ordenadas de registros como se muestra en el siguiente pseudocódigo: i=0; Newbr = br; //total de bloques en la relación While(true) Si Newbr ≤ M Entonces Leer, Escribir a Si y Salir; //última lectura Leer M Blqs de la relación r; Newbr = Newbr – M; //M blqs de la r han sido leídos Escribir los datos ordenados en el archivo de secuencia Si; i = i + 1; End While


56

En el pseudocódigo anterior se generan varias secuencias de archivos que

están compuestas de registros ordenados. Cada secuencia tiene el tamaño del buffer, a excepción de la última secuencia, la cual puede ser menor que el tamaño del buffer.

La segunda etapa consiste en mezclar las secuencias que se generaron en la etapa anterior. Si N archivos Si generados son menores que los M marcos en Buffer, entonces, se debe asignar un marco por secuencia, y reservar uno para el resultado. El pseudocódigo utilizado para esta segunda etapa es el siguiente: -Leer un blq de c/u de los N archivos Si, guardar en el Buffer. Repeat Elegir la primer tupla (según orden) de entre todos los marcos; Escribir la tupla en la página de salida; Suprimir la tupla de la página de entrada; Si marco en buffer de Si = vacío y Not EOF(Si) Entonces Leer el siguiente blq de Si y guardarlo en el marco vacío; Until todas las páginas del buffer estén vacías;

La siguiente figura muestra el proceso de ordenamiento de cada una de las secuencias que fueron previamente generadas en la fase anterior:

Ilustración 3-45: Segunda fase de la técnica mezcla-externa

En la gráfica anterior se muestra un ejemplo de la implementación del

algoritmo descrito anteriormente, el tamaño de buffer es de cuatro páginas. Tres páginas se utilizan para albergar secuencias de archivos, otra página, almacena los ordenamientos que se van haciendo con los elementos en las secuencias de archivos creadas en la primera fase.

Para cada página se permiten como máximo cuatro registros. En el archivo

de salida se van generando las nuevas secuencias de registros ordenadas, que van a constituir el resultado final de la consulta.


57

La gráfica siguiente muestra una perspectiva del procesamiento general que

se lleva a cabo cuando se aplica la técnica de ordenación-mezcla-externa:

Ilustración 3-46: Técnica de ordenamiento-mezcla-externa

Operación de reunión Estudiaremos varios algoritmos para calcular la reunión entre relaciones y sus costes asociados. La palabra equireunión denota la expresión r|x|r.A=s.Bs, donde A y B son atributos de las relaciones r y s respectivamente. Como ejemplo utilizaremos r1|x|r2 con la siguiente información de catálogo:

-Registros en r1: nr1=10,000. Que ocupan 400 bloques de disco. -Registros en r2: nr2=5,000. Que ocupan 100 bloques de disco.

Reunión en bucle anidado

Esta técnica Utiliza dos bucles for anidados, al primero se le suele denominar bucle externo y al que depende de éste bucle interno. La aplicación de este mecanismo para realizar operaciones de reunión sobre relaciones no necesita de índices. Para convertir la reunión en un producto natural basta con eliminar los valores duplicados. La principal fortaleza de esta técnica es que, se concibe como un algoritmo sencillo de implementar. La principal desventaja es que la aplicación supone un costo alto.

El algoritmo es válido para cualquier tipo de comparación en la reunión (=,>,<). El problema principal es que el número de operaciones de E/S crece sustancialmente a medida que la relación del bucle externo crece.


58

El pseudocódigo para la reunión en bucle anidado es el siguiente:

For cada tupla tr (donde r es una relación) Begin For cada tupla ts (donde s es una relación) Begin comprobar que (tr,ts) satisface la condición de la reunión Si cumple la condición Entonces resultado += tr x ts end end

Si ninguna de las relaciones cabe por completo en memoria, se realizan muchos reemplazos. Vamos a suponer el siguiente caso: en el buffer asociado al sistema cabe un bloque para cada relación, al realizar r1|x|r2 en el peor de los casos el número de E/S:

-nr1 * br2 + br1 = 1,000(registros r1) * 100(bloques r2) + 400(bloques r1)

Aunque es poco probable que las dos relaciones alcancen en el buffer por completo, existe la posibilidad que una de las relaciones quepa por completo, y la otra se cargue a trozos en el buffer. Cuando una de las relaciones cabe por completo se intenta asociar el bucle interno con esa relación. Como regla general se ubicará a la relación de menor peso en el bucle interno. Supongamos que r2 cabe por completo en memoria, los accesos pueden variar a:

-br2 + br1 = 100(blq r2) + 400(blq r1) En el ejemplo anterior, se puede observar cómo de forma drástica las

operaciones de E/S decrecen. Este ejemplo constituye el mejor de los casos para este algoritmo. Reunión bucle anidado por bloques Este mecanismo es una variante del anterior, introduciendo mejoras significativas en cuanto al rendimiento. Las características de este algoritmo son: • Se empareja cada bloque de la relación externa con cada bloque de la

relación interna. • La diferencia fundamental con el caso anterior, es que en peor de los casos,

cada bloque de la relación interna, se lee solamente una vez por cada bloque de la relación externa.

• Para r1 |x| r2 en el peor de los casos genera:

o br1 * br2 + br1 = 400(bloques r1) * 100(bloques r2) + 400(bloques r1)


59

El pseudocódigo para los bucles anidados por bloque es el siguiente: For cada bloque br en r Begin For cada bloque bs en s Begin For cada tupla tr en br Begin For cada tupla ts en bs Begin Comprobar que (tr,ts) satisface la condición de la reunión Si cumple la condición Entonces resultado += tr*ts End End End End

El rendimiento en ambos casos puede mejorar si los atributos en la reunión de igualdad forman una clave de la relación interna. El bucle interno puede terminar al encontrar la primer incidencia.

Otra mejora que se puede considerar es la siguiente: en la anidación de

bloques, pueden leerse M-2 bloques de golpe en el buffer para la relación externa. El sumando M, representa el tamaño del buffer en bloques, y el segundo es el espacio para un bloque de la relación interna. Se deja otro bloque para la salida de los resultados. El coste total es de este algoritmo utilizando esta mejora es [br/(M-2)] * bs + br.

Por ejemplo, suponga un tamaño de buffer que pueda albergar 42 bloques de

disco. El peor de los casos para la expresión r1|x|r2 se generan un total de accesos a disco de [400/(40)] * 100 + 400.

Otras estrategias para aminorar los accesos a disco pueden ser: explorar el bucle interno en forma de ascensor, con esto aprovechamos los bloques que han sido recientemente llevados al buffer (se aminoran los reemplazos). También, se puede mantener un índice al atributo del bucle interno, las comparaciones con los registros del bucle externo se realizan con el índice y no directamente con el registro en disco. A continuación detallaremos esta técnica. Reunión en bucle anidado indexado

Necesita de un índice sobre el atributo de la reunión. Si no existe hay que considerar crear uno temporal. Como se mencionó anteriormente, para cada tupla en la relación externa, se realiza una búsqueda sobre el índice y no sobre el valor propiamente del registro en sí. El costo total se puede calcular como: br + nr * C, donde br y nr, son el número de bloques y registros respectivamente de la relación r. El tercer elemento “C” es el coste de una búsqueda en el índice del bucle interno.

Por ejemplo: Considere una reunión en bucle anidado indexado de las relaciones empleador|x|asegurado, con los siguientes estadísticos:

-empleador: 50,000 tuplas, 500 bloques. -asegurado: 3,000 tuplas, 100 bloques.


60

Suponer un índice B+ primario sobre el campo nombre_empleado de la

relación asegurado. Cada entrada del árbol tiene un promedio de 50 entradas por nodo. Calcular el coste total medido en accesos a disco. empleador = 50,000 tuplas asegurado = 3,000 tuplas -> altura del árbol B+ -Altura B+ (50 entradas X nodo) para 3,000 tuplas

base del árbol = 3,000 / 50 ≡ 60 nodos hoja = 3 Niveles. -Accesos por cada búsqueda = 3 + 1 acceso al registro. Costo: 500(bloques empleador) + 50,000 (registros empleador) * 4 (búsqueda) Reunión por mezcla

Necesita que ambas relaciones estén ordenadas por los atributos que participan en la operación de reunión. Si no están ordenadas, antes de aplicar este algoritmo se deberá ordenar las relaciones participantes. Pero como siempre, este proceso de ordenación supone un coste extra al algoritmo en sí. En el peor de los casos ordenar suponiendo una M = 3 (un bloque para cada relación y otro para la salida) el proceso de orden por mezcla agrega: br * (2 * [LogM-1 * (br/M)] + 1) accesos al disco.

El procedimiento para poner en marcha este algoritmo es el siguiente: • Suponga dos relaciones R y S ordenadas, entonces tirar un puntero a cada

relación PR y PS respectivamente. • Crear el conjunto SS, compuesto por los valores consecutivos iguales en S. • Si el valor apuntado por PR es menor que cualquiera de los valores en

conjunto SS entonces avanzar el puntero al siguiente registro. • Si al recorrer R el valor apuntado por PR es igual a cualquiera de los valores

en el conjunto SS, por cada tupla en el conjunto se agrega lo siguiente al resultado: (tupla en SS , tupla apuntada por PR).

A continuación se muestra el pseudocódigo del algoritmo:

pr:= dirección de la primera tupla de r; ps:= dirección de la primera tupla de s; while (ps ≠ null and pr ≠ null) do begin ts:= tupla a la que apunta ps; Ss:= {ts}; hacer que ps apunte a la siguiente tupla de s; hecho:= falso; while (not hecho and ps ≠ null) do begin ts’:= tupla a la que apunta ps; if (ts' [AtribsReunión] = ts [AtribsReunión]) then begin Ss:= Ss U {ts'}; hacer que ps apunte a la siguiente tupla de s;


61

endif else hecho:= cierto; endwhile tr:= tupla a la que apunta pr; while (pr ≠ null and tr[AtribsReunión] < ts[AtribsReunión]) do begin hacer que pr apunte a la siguiente tupla de r; tr:= tupla a la que apunta pr; endwhile while (pr ≠ null and t,[AtribsReunión] = ts[AtribsReunión]) do begin for each ts in Ss do begin añadir ts |x| tr al resultado; endfor hacer que pr apunte a la siguiente tupla de r; tr:= tupla a la que apunta pr; endwhile endwhile

la siguiente gráfica muestra la aplicación de este algoritmo sobre las relaciones r y s. Los indicadores de flecha sobre cada registro contienen un número que indica el orden en que fueron procesados esos registros. La aplicación de este algoritmo en este caso se dividió en tres fases, cada una agrupa los aspectos sobresalientes que se van aplicando a través de los punteros que recorren las relaciones.

Ilustración 3-47: Implementación de la operación reunión por mezcla


62

Reuniones complejas Para este tipo de operación pueden utilizarse las técnicas de bucle anidado, las otras técnicas son más eficientes pero sólo se pueden utilizar con condiciones simples. En las reuniones de la forma: r|x| θ1^ θ2^,…,^ θn s, se calcula por separado cada r|x| θi s, utilizando cualquiera de los algoritmos vistos para la reunión. En las reuniones de la forma: r|x| θ1v θ2 v,…,v θn s, puede calcularlo como (r|x|θ1s) U (r|x|θ2s) U,…,U (r|x|θns). Luego se juntan todos los resultados que cumplieron una determinada condición. Otras operaciones (Eliminación de duplicados) Es necesario implementar antes la ordenación (todas las tuplas con el mismo valor aparecen una tras de la otra). Aprovechando que todas las tuplas se encuentran ordenadas, eliminar todas las copias de un mismo valor. Si utilizamos para ordenar el algoritmo: ordenación-mezcla externa, se pueden borrar duplicados en la creación de las secuencias y en la reunión, antes de escribir a disco. Con esto logramos un ahorro significativo de accesos a disco, ya que no esperamos a recuperar los resultados generados por el algoritmo, sino que las eliminaciones se van realizando paralelamente a la aplicación del mecanismo de ordenación. Proyección Aquí solo hay que filtrar los campos de la proyección y luego eliminar los duplicados. El filtrado se realiza depositando las columnas del resultado en una relación intermedia, luego, se le puede aplicar el proceso de eliminación de duplicados visto anteriormente a la nueva relación temporal. Operaciones sobre conjuntos con exploraciones directas Para las operaciones unión, intersección y diferencia de conjunto utilizando exploraciones directas al archivo. Es necesario ordenar las relaciones participantes, luego para cada operación en concreto se puede realizar lo siguiente: • Para r ∪ s: en este caso se deben agregar al resultado aquellos registros

que cumplen una determinada condición en cualquiera de las relaciones participantes, para ello, se exploran de forma concurrente ambas relaciones, si se detecta el mismo valor en un momento dado, sólo se agrega una vez el valor al resultado.

• Para r ∩ s: en esta operación la condición debe cumplirse en los registros de

ambas relaciones, el mecanismo es el siguiente, se exploran de forma concurrente las relaciones participantes, se agrega el valor coincidente en las dos relaciones.

• Para r – s: la nueva relación resultante se genera aplicando el siguiente

mecanismo, se guardan en el resultado aquellas tuplas de r que no estén en s.

La exploración directa genera un coste: br + bs, si no están ordenadas las

relaciones hay que agregar al supuesto anterior el coste de ordenar alguna de las dos relaciones o ambas.


63

Operaciones sobre conjuntos con asociación En el caso anterior se estudió como resolver esta problemática utilizando exploraciones directas sobre los archivos. Aquí se revisarán los casos donde la implementación se lleva a cabo utilizando conjuntos con asociación. Para aplicar este mecanismo es necesario lo siguiente:

Dividir en particiones ambas relaciones utilizando la misma función de asociación. Se generan Hro,…,Hrn y Hso,…,Hsn particiones. Hacer lo siguiente en cada partición: • Para r ∪ s:

1.- Construir un índice Hri en memoria principal. 2.- Añadir las tuplas no presentes de Hsi al índice. 3.- Volcar al resultado las tuplas referenciadas en el índice.

• Para r ∩ s:

1- Construir un índice para Hri en memoria principal. 2- Añadir una tupla de Hsi al índice, solo si ya estaba presente. 3- Volcar las tuplas referenciadas al resultado.

• Para r - s:

1- Construir un índice para Hri en memoria principal. 2- Quitar las tuplas Hsi que ya esten presentes en el índice. 3- Volcar las tuplas referenciadas al resultado.

Agregación Utilizar un mecanismo parecido a la eliminación de duplicados. En vez de eliminar de los grupos con un mismo valor las copias, aplicar la función de agregación de la consulta. Para aminorar los accesos a disco se puede realizar lo siguiente: • Aplicar las funciones de agregación sobre los grupos parciales de datos (si

no cabe toda la relación en memoria principal). • Los consolidados se dejan en una sola tupla de resultado para cada valor

diferente de un grupo. Es decir, no se almacenan todos los valores de cada elemento dentro de un grupo, sino que se van almacenando resúmenes para cada grupo de datos inspeccionado.

Por ejemplo, los valores generados para un cálculo de los montos agrupados

por departamento (Managua, Masaya, Granada, León, etc) de la empresa “X”, se podrían generar los resultados parciales: León 40,000 (obtenido de [León 15,000] [León 20,000] [León 5,000]), Managua 75,000, etc. En la secuencia S2, si se utilizara ordenación- mezcla.


64

3.5.5 Materialización y encauzamiento Materialización Si construimos un árbol de operadores, el enfoque de materialización comienza por las operaciones de nivel más bajo, siguiendo hacia la raíz. Cada vez que se sube un nivel se genera una relación temporal formada a partir de otras relaciones temporales, o de una combinación de éstas con relaciones en la base de datos. Se denomina evaluación materializada ya que los resultados de cada operación intermedia se “materializan” para utilizarse en la siguiente evaluación de expresión. Suponga las relaciones Factura y Detallefactura con los datos:

Factura IdF Fecha Cliente F-01 10/06/04 Clte01 F-02 11/06/04 Clte02 F-03 10/06/04 Clte03

Tabla 3-5: Ejemplo de materialización (tabla Factura)

Detallefactura

IdF Producto Cantidad Monto F-01 Prod01 3 C$30 F-01 Prod05 2 C$100 F-02 Prod01 5 C$50 F-03 Prod01 8 C$80 F-03 Prod02 1 C$20 F-03 Prod05 2 C$100

Tabla 3-6: Ejemplo de Materialización (tabla Detallefactura)

Una ejecución con enfoque materializado de la expresión: πcliente, fecha (σProducto=“Prod01” ( Detallefactura) |x| Factura ) genera el siguiente árbol:

Ilustración 3-48: Ejemplo de la estructura de árbol generada en la materialización


65

Encauzamiento Intenta eliminar resultados intermedios, aplicando las operaciones directamente a los resultados parciales generados. Si aplicamos este enfoque al ejemplo anterior tenemos:

Ilustración 3-49: Aplicación de la técnica de encauzamiento


66

3.6 Transacciones Se tiene proyectado para este tema un total de diez horas, de las cuales ocho se utilizan para las lecciones magistrales y dos horas para desarrollar clases prácticas con los estudiantes. La tabla siguiente muestra una visión general de este tema.

TEMARIO

3.6.1 Propiedades de un transacción 3.6.2 Estados de una transacción 3.6.3 Implementación de la atomicidad y durabilidad 3.6.4 Ejecuciones concurrentes 3.6.5 Secuencialidad 3.6.6 Recuperabilidad 3.6.7 Implementación del aislamiento 3.6.8 Comprobación de la secuencialidad

OBJETIVOS GENERALES

-Que el estudiante pueda establecer criterios para evaluar si una propuesta de ejecución de una transacción en un ambiente concurrente, es factible o no, y que sea capaz de corregir posibles debilidades que pueda presentar una determinada planificación de transacción. -Que el estudiante conozca las propiedades que deben existir en un sistema que da soporte a la ejecución de transacciones concurrentes.

EJE -Gestión de transacciones.


-FUNDAMENTOS DE BASES DE DATOS. Korth, Silberschatz y Sudarshan. Mc Graw Hill. {4ª Ed. CAP15} -FUNDAMENTOS DE BASES DE DATOS. Korth y Silberschatz. Mc Graw Hill. {2ª Ed. CAP11-12}

Tabla 3-7: Visión general del tema 4.

3.6.1 Propiedades de una transacción

Existen muchos conceptos que definen de forma correcta lo que es una transacción, aquí ponemos uno bastante fácil de aprender y que cataloga una transacción como una colección de operaciones que forman una unidad lógica de trabajo.

Para un programador, una transacción es un conjunto de líneas de código delimitadas por ciertas etiquetas especiales que cambian dependiendo del entorno donde se hayan programado. En lo general, para todos los casos, las transacciones que se programan para un sistema de bases de datos deben cumplir las propiedades ACID (Atomicity, Consistency, Isolation and Durability). Comentaremos cada una de las palabras que componen la abreviatura anterior.

Tema 4: Transacciones

67

• Atomicidad: Garantizar que la base de datos, se modifica, únicamente si

todas las operaciones de una transacción son ejecutadas sin errores. • Consistencia: La ejecución de las instrucciones de la propia transacción no

hace al sistema inconsistente. • Aislamiento: Garantizar que la ejecución de una transacción ti no interfiere

con la ejecución de otra tj. • Durabilidad: Una vez finalizada una transacción con éxito, los cambios

perduran incluso si hay fallos en el sistema.

Es necesario cumplir las propiedades ACID, debido a que son las que garantizan la correcta ejecución de las transacciones en el sistema. Supongamos el siguiente escenario:

• El acceso a la base de datos se lleva a cabo mediante las operaciones

read(x) y write(x). • read(x): transfiere un dato (de la transacción) desde la base de datos al

buffer. • write(x): transfiere un dato (de la transacción) desde la base de datos al

buffer. • Aunque en la realidad cada modificación no necesariamente produce una

modificación en disco, vamos a suponer que cada llamada a write(x) produce una escritura a disco.

Suponiendo el escenario anterior, se transfieren en la transacción ti(C$1,000)

de la cuenta C01 a la cuenta C02. Utilizando las primitivas anteriores ti puede definirse como:

ti read(C01); C01 := C01 – 1,000; write(C01); read(C02); C02 := C02 + 1,000; write(C02);

De no cumplirse ACID en ti, podrían pasar las siguientes anomalías:

• Consistencia: suponga C01 con C$5,000 y C02 con C$2,000. No puede

pasar que después de efectuada la transacción, la suma de las cuentas genere C$8,000.

• Atomicidad: si esta propiedad no se cumple, y hay un fallo luego de leer C02,

la cuenta C01 queda con C$4,000. • Durabilidad: generalmente, basta con garantizar que antes que ti se dé por

finalizada, exista un mecanismo en caso de fallo que permita dejar la base de datos en un estado consistente, una vez reiniciado el sistema.

• Aislamiento: otra transacción debita de C01 C$500 y termina, pero ti ya ha

leído C$5,000, y no C$4,500.


68

3.6.2 Estados de una transacción. Una transacción puede encontrarse en uno de los estados siguientes: • Activa: la transacción se ha iniciado. Permanece en este estado durante

todo su período de vida. • Parcialmente cometida: se ejecutaron todas las operaciones de la

transacción satisfactoriamente, pero está esperando la orden para finalizar o darse por fallida.

• Fallida: no puede continuar su ejecución normal. • Abortada: si se realizaron cambios, hay que deshacerlos, y dejar la base de

datos en el estado que tenía antes de ejecutar la transacción. • Cometida: nuevo estado consistente de la base de datos.

La ilustración siguiente, muestra los distintos estados en los que se puede encontrar una transacción mientras se ejecuta dentro del sistema de bases de datos.

Ilustración 3-50: Diagrama de transición de estados de una transacción

Cuando una transacción es abortada se pueden realizar dos acciones:

1.- Reiniciar la transacción: si fue abortada a causa de un factor externo a la transacción, y no por error en la lógica de la propia transacción. Cuando reinicia se considera una transacción nueva. 2.- Cancelar la transacción (lo usual):

-si hay algún error interno en la lógica de la transacción. -no se ha podido encontrar los datos que necesita la transacción


69

3.6.5 Implementación de la atomicidad y durabilidad En un sistema de bases de datos el componente de gestión de recuperaciones es el encargado de implementar la atomicidad y durabilidad de transacciones. Comentaremos de forma superficial un primer algoritmo en la temática de recuperación: “shadow pages”. Este algoritmo asume los siguientes supuestos: • Una transacción en cada momento. • La base de datos, esta compuesta por un único archivo en disco. • El sistema manejador de disco proporciona actualizaciones atómicas de

bloques enteros. Suponiendo que este algoritmo es host de un sistema con soporte al

esquema anterior, las características fundamentales de shadow pages son:

1.- Mantiene un puntero (puntero_BD) que apunta a la copia actual de la base de datos. 2.- Las actualizaciones generadas por las transacciones se realizan sobre una copia de la base de datos entera. 3.- Si la transacción hace commit se desencadenan las siguientes tareas:

-Consulta al Sistema Operativo asegurándose que todas las páginas de la base de datos están escritas en disco (en UNIX es la orden fsync). -puntero_BD, apunta a la copia actualizada, convirtiéndose en la nueva base de datos actual.

La atomicidad y durabilidad teniendo como soporte el algoritmo anterior, se

pueden dar de la siguiente forma: • Si falla la transacción, o falla el sistema (sólo consideramos errores en

memoria principal) en cualquier punto de la ejecución de la transacción, la base de datos queda en el estado consistente anterior. No se logró modificar el valor del puntero a la base de datos por lo tanto, el sistema no conoce del archivo temporal creado para ejecutar la transacción.

• Si la transacción tiene éxito, la base de datos pasa al nuevo estado. La copia

de la base de datos se convierte en la base de datos actual. • Las actualizaciones atómicas de copias de bloques de disco, garantizan que

la copia del puntero_BD, se realice de forma atómica, es decir, se logró modificar el contenido total de éste o en caso de suceder algún error, el puntero queda con el valor anterior.


70

3.6.6 Ejecuciones concurrentes Como se ha comentado anteriormente, la ejecución concurrente de transacciones puede dejar al sistema en un estado inconsistente, entonces, ¿por qué permitir ejecuciones concurrentes de transacciones? Las dos razones fundamentales de el por qué se permiten las ejecuciones concurrentes de transacciones en un sistema de bases de datos se explican a continuación:

1.- Productividad y utilización de recursos mejorada: hay que explotar al máximo el paralelismo de la CPU y el sistema E/S, mientras la transacción ti utiliza la CPU, la transacción tj realiza una escritura en disco. 2.- Reducir el tiempo de espera: si la ejecución fuera secuencial, transacciones largas, harían que los tiempos de espera para transacciones pequeñas se incrementaran considerablemente, antes de empezar a ejecutarse.

El problema principal de la concurrencia, es que puede dejar la base de

datos en un estado inconsistente, auque no se hayan generado fallos en las transacciones. Los mecanismos que evitan dejar la base de datos en un estado inconsistente, se denominan: esquemas de control de concurrencia. Estos mecanismos de control se estudian más adelante en detalle, por ahora, nos concentraremos en los posibles escenarios que se pueden generar cuando se ejecutan transacciones de forma concurrente. Vamos a trabajar con los siguientes cuadros de transacciones de ejemplo (transacciones t1y t2):

Ilustración 3-51: Cuadro de la transacción t1 (transferencias en córdobas)

La figura anterior muestra las instrucciones que componen la transacción t1,

ésta transfiere C$50 de la cuenta “A” a la cuenta “B”. El gráfico que sigue a continuación muestra el conjunto de instrucciones que componen la transacción t2, que realiza lo siguiente: transfiere el diez por ciento del saldo de la cuenta “A” a la cuenta “B”.


71

Ilustración 3-52: Cuadro de la transacción t2 (transferencias en córdobas)

Antes de continuar, vamos a estudiar el concepto de planificación. Una

planificación en el ambiente de transacciones se define como las secuencias de ejecución de las transacciones, que representan el orden cronológico en que se ejecutaron las operaciones de cada transacción en el sistema. A continuación se muestra una figura con una posible ejecución de las transacciones t1 y t2.

Ilustración 3-53: Planificación secuencial t1 después de t2

Si suponemos que las cuentas en el momento de ejecutarse la primera

transacción tienen C$1,000 y C$2,000 respectivamente, al finalizar la ejecución de la segunda transacción A, queda con C$850 y B, con C$2,150. Si sumamos A y B, el resultado después de ejecutadas ambas transacciones mantiene la suma inicial de ambas cuentas, el cual es de 3,000 córdobas. Al tipo de planificación anterior en la que se ejecutan todas las operaciones de una transacción y a continuación la siguiente transacción, se les llama planificaciones secuenciales.


72

De forma general, para un conjunto de n transacciones que se ejecutan de

forma concurrente es imposible predecir en que punto de la transacción habrá un cambio de contexto. Tomando en cuenta esto, el número de planificaciones posibles se incrementa considerablemente. Una planificación concurrente de transacciones es buena, siempre y cuando los efectos de esa planificación, sean los mismos que como si se hubiese ejecutado sin concurrencia.

La planificación secuencial mostrada en la figura 3-53, se podría haber

ejecutado tomando cambios de contextos aleatorios de la manera siguiente:

Ilustración 3-54: Planificación concurrente equivalente al caso anterior

En la planificación mostrada en la figura 3-54 se mantiene la consistencia de

la base de datos, observe que A termina con C$850 y B con C$2,150, lo que sigue generando la suma inicial de C$3,000.

No todas las planificaciones generan resultados correctos observe lo que sucede después de que se ejecutan las transacciones de la siguiente figura:

Ilustración 3-55: Planificación concurrente con problemas de consistencia


73

En la figura 3-55, se muestra un caso de planificación en la ejecución

concurrente de dos transacciones que dejan al sistema en un estado inconsistente. El estado de inconsistencia se observa al sumar los valores finales de A y B, los cuales finalizan con C$950 y C$2,100 respectivamente, el monto total final de la transacción es de C$3,050, en ves de los C$3,000 que deberían mantener la ejecución de las transacciones de la figura 3-55.

3.6.7 Secuencialidad Puesto que las transacciones son programas, es difícil indicar las operaciones que éstas realizan sobre los datos. De forma general, se consideran dos operaciones read y write sobre un dato cualquiera Q. Las operaciones sobre los datos Q, que se llevan en el buffer antes o después de una lectura o escritura, desde el punto de vista de la planificación no son significativas. Es por esta razón que en las propuestas siguientes no se planifican.

El tema de secuencialidad surge de la necesidad de encontrar propuestas de transacciones concurrentes equivalentes a una ejecución secuencial. Para estudiar este tema, debemos conocer cuándo dos transacciones se encuentran en conflicto. Para introducir este concepto, suponga dos transacciones ti y tj, con dos instrucciones consecutivas Ii e Ij pertenecientes a ti y tj respectivamente. Ambas instrucciones operan sobre el mismo dato Q. Se dice que las instrucciones Ii e Ij están en conflicto, si al menos una de estas realiza una operación de escritura sobre Q.

El siguiente gráfico muestra alguno de los posibles conflictos entre instrucciones que se pueden generar al realizar propuestas de planificaciones:

Ilustración 3-56: Planificación con conflicto de instrucciones

Como se puede observar en la ilustración 3-56, la instrucción write(A) de t1,

está en conflicto con la instrucción read(A) de t2, debido a que ambas operaciones trabajan sobre el mismo dato y una de ellas lo modifica. Observe sin embargo, que la instrucción write(A) de t2, no entra en conflicto con read(B) de t1. Debido a que si bien es cierto se da una operación de escritura no se realiza sobre el mismo dato.


74

Si una planificación P se puede transformar en otra P’, por medio de

intercambios de instrucciones no conflictivas, se dice que P y P’ son equivalentes en cuanto a conflictos. En la figura siguiente se muestran dos planificaciones que cumplen con esta disposición de equivalencia:

Ilustración 3-57: Planificaciones equivalentes en cuanto a conflictos

La ilustración 3-57, muestra que después de intercambiar algunas de las

instrucciones no conflictivas en P, se generó otra planificación P’ que es equivalente en cuanto a conflictos a la planificación inicial P. El intercambio realizado en la planificación original fue el siguiente: write(A) en t1 por read(B) en t2.

Planificaciones secuenciables en cuanto a conflictos Podemos extender la equivalencia entre planificaciones por medio del siguiente concepto: se define que una planificación P, es secuenciable en cuanto a conflictos, si es equivalente en cuanto a conflictos a una planificación secuencial (utilizando intercambios no conflictivos lograr una planificación secuencial) por ejemplo:

Ilustración 3-58: Ejemplo de planificaciones secuenciables en cuanto a conflictos


75

Secuencialidad en cuanto a vistas Dos planificaciones P y P’ son equivalentes en cuanto a vistas si cumplen:

1.- Las transacciones ti, tj en P y P’ respectivamente, para todo elemento de datos Q se debe leer el mismo valor inicial, en ambas planificaciones. 2.- Si un dato ha sido producido por tj y leído por ti, o viceversa, debe respetarse este orden tanto en P como en P’. 3.- El último dato Q escrito por cualquiera de las transacciones en P, debe ser la última operación que modifica Q en P’.

La siguiente gráfica muestra un ejemplo de dos planificaciones no

equivalentes en cuanto a vistas:

Ilustración 3-59: planificaciones no secuenciables en cuanto a vistas

Las planificaciones que se muestran en la ilustración 3-59, no son

equivalentes en cuanto a vistas por que no cumplen las siguientes restricciones: • Ambas leen los mismos valores iniciales para A, no así para B. Observe que

el valor inicial de B, se inicializa por t1al hacer un read(B) sobre el dato, en la primer planificación. Mientras que en la segunda planificación este valor es inicializado por la transacción número dos.

• B, es producido por t1 (P) y por t2 en P’. Se viola la regla de que en ambas

planificaciones los valores deben ser producidos y leídos en el mismo orden. • Para ningún Q se cumple que la última transacción que lo modificó en P, sea

quien escriba ese dato en P’. En la primera planificación es t1 la que realiza la última escritura de A y B. En la segunda planificación sucede todo lo contrario, los datos son escritos por última vez en t2.


76

A continuación se muestran dos casos de planificaciones que cumplen con

todas las restricciones de equivalencias en cuanto a vistas:

Ilustración 3-60: Ejemplo de planificaciones equivalentes en cuanto a vistas

El ejemplo anterior muestra dos casos en los que se cumplen todas las

condiciones para que ambas planificaciones sean equivalentes en cuanto a vistas, se comentarán algunos de los puntos más relevantes de las restricciones cumplidas: • Los valores A y B son producidos en t1y leídos en t2. • Los valores iniciales tanto de A como de B son leídos en t1. • Tanto A como B se modifican por última vez en la transacción t2.

3.6.8 Recuperabilidad Hasta ahora se ha asumido que ninguna de las transacciones en ninguna de las planificaciones falla. Si una transacción ti falla, en un sistema que permite concurrencia, es necesario asegurar también que cualquier transacción que haya leído datos escritos por ti sea abortada también. Para lograr lo expuesto anteriormente hay que restringir las planificaciones permitidas en el sistema.

Una planificación recuperable, es aquella en la que para todo par de transacciones ti y tj, donde tj lee datos escritos por ti, la operación commit de ti debe aparecer antes que la operación commit de tj.


77

Existen planificaciones de transacciones que no pueden ser deshechas bajo

ciertas circunstancias, a las que se les conoce como planificaciones no recuperables. El siguiente gráfico muestra un caso de este tipo de planificación:

Ilustración 3-61: Ejemplo de planificación no recuperable

Si ambas transacciones concluyen sus procesos satisfactoriamente, la

planificación anterior deja al sistema en un estado consistente. Pero que sucede, si tj hace commit y ti falla justo después de hacer read(B), la transacción tj no podrá ser abortada. Este tipo de planificación no es deseable en un sistema de bases de datos, y suele ocurrir cuando se programan planificaciones donde la brecha de diferencia entre transacciones en cuanto al número de operaciones es grande. Con esto no se quiere decir que sólo bajo este tipo de situación se puede dar este caso, de forma general, se puede indicar que toda planificación puede presentar esta anomalía, siempre que no cumpla la característica de planificación recuperable. Planificación sin cascada Las planificaciones sin cascada, cumplen la característica de planificaciones recuperables, ya que evitan la lectura de datos producidos por otras transacciones antes de que éstas hayan finalizado su ejecución. Los retrocesos en cascada se dan cuando el fallo de una transacción desencadena operaciones rollback sobre otras transacciones, esto debido a que alguna de las operaciones de estas transacciones estaba basada en un dato modificado por la transacción fallida. El siguiente muestra un caso de retroceso en cascada:

Ilustración 3-62: Ejemplo de retroceso de transacciones en cascada


78

Vamos a suponer en el gráfico anterior que ti hace commit antes de ti, y que tj

hace commit antes de tz, lo que garantiza una planificación recuperable. Aunque hemos logrado una planificación que en el peor de los casos dejará al sistema en el estado actual. Observemos que sucede cuando ocurren retrocesos de todas las transacciones involucradas en una planificación. Suponga un fallo en write(B) de ti, esto desencadena debido al dato A, abortar tj y tz.

3.6.9 Implementación del aislamiento Para que la ejecución de una transacción, no interfiera con la ejecución de otra, en cuanto a dejar en estado consistente la base de datos, se debe cumplir con las siguientes características: • Las planificaciones son secuenciables en cuanto a conflictos. • Son secuenciables en cuanto a vistas. • Las planificaciones propuestas no presentan el efecto de retroceso en

cascada.

Los aislamientos se implementan en el sistema a través de los esquemas de control de concurrencia, los que realizan bloqueos sobre los datos bajo determinadas circunstancias, esto garantiza la no interferencia entre transacciones. Toda esta temática de control se discute en detalle en el siguiente tema.

3.6.10 Comprobación de la secuencialidad En este tema veremos un método que se soporta en la utilización de grafos para determinar si una planificación cualquiera es secuenciable en cuanto a conflictos. Para empezar a aplicar este método se debe construir un grafo de precedencia, donde los vértices son las transacciones que participan en la planificación, y las aristas representan una de las tres condiciones siguientes, para cada par de transacciones ti tj:

1.- ti hace un write(Q) antes de que tj realice un read(Q). 2.- ti ejecuta read(Q) antes de que tj ejecute write(Q). 3.- ti ejecuta write(Q) antes de que tj ejecute write(Q).

Si existe un arco ti tj en el grafo de precedencia, entonces en toda

planificación secuencial P’ que es equivalente a P, la transacción ti aparece antes. Si el grafo de precedencia de una planificación P tiene un ciclo, entonces P, no es secuenciable en cuanto a conflictos. El orden de secuencialidad se puede obtener a través de la ordenación topológica del grafo.


79

La siguiente ilustración muestra un grafo de precedencia con bucles. La

planificación que se muestra en el ejemplo no es secuenciable en cuanto a conflictos.

Ilustración 3-63: Grafo de precedencia con bucles

El siguiente ejemplo muestra una topología base y dos disposiciones lineales

de la topología inicial: la primer topología lineal es válida, y la segunda no cumple con la regla de que para todo arco ti tj en el grafo, ti aparece antes que tj.

Ilustración 3-64: Topologías lineales para un grafo de precedencia


80

3.7 Control de concurrencia Se tiene proyectado para este tema un total de diez horas, de las cuales ocho se utilizan para las lecciones magistrales y dos horas para desarrollar clases prácticas con los estudiantes. La tabla siguiente muestra una visión general de este tema.

TEMARIO 3.7.1 Protocolos basados en el bloqueo 3.7.2 Protocolos basados en marcas temporales 3.7.3 Protocolos basados en validación 3.7.4 Granularidad múltiple

OBJETIVOS GENERALES

-Que el estudiante conozca las anomalías que pueden darse en un sistema que ejecuta transacciones de forma concurrente. -Que el estudiante aplique los conceptos que se estudiarán de los distintos escenarios de gestión y control de concurrencia en un sistema de bases de datos, al diseño de las transacciones que se crean en entornos de programación de bases de datos.

EJE -Gestión de transacciones.




3.7.1 Protocolos basados en el bloqueo

Todos los esquemas de control de concurrencia que se comentan de aquí en adelante se basan en la propiedad de secuencialidad. El sistema operativo debe proporcionar a los algoritmos basados en bloqueo, acceso a datos en exclusión mutua, para las actualizaciones. Una transacción, para poder acceder a un dato tanto para leer como para escribir, debe poseer algún tipo de bloqueo para ese dato. Existen varios tipos de bloqueo, nos vamos a concentrar por el momento, en los dos más importantes:

1.- Compartido: si se concede a una transacción ti un bloqueo compartido sobre un dato Q, ti sólo puede leer este dato, pero no puede modificarlo. 2.- Exclusivo: si se concede a una transacción ti un bloqueo en modo exclusivo sobre un dato Q, ti puede leer y modificar el dato Q.

Para indicar la solicitud de un bloqueo en modo compartido sobre un dato Q,

utilizaremos lock-S(Q). Para indicar la solicitud de un bloqueo en modo exclusivo sobre un dato Q, utilizaremos lock-X(Q). Dado un conjunto MB de modos de bloqueo, dos modos arbitrarios A, B que pertenecen a MB, son compatibles si y sólo sí, se puede alcanzar el modo de bloqueo B desde la transacción tj sobre el dato Q, estando Q bloqueado en el modo A desde la transacción ti o viceversa, siendo i distinto de j.

Tema 5: Control de concurrencia

81

Para este primer intento de gestión de transacciones concurrentes, el único

modo compatible entre sí, es el modo compartido, es decir, transacciones diferentes pueden tener de forma simultánea varios bloqueos de este tipo. En caso de darse una solicitud de bloqueo sobre un dato Q, que no es compatible con el modo de bloqueo actual del dato, dicha solicitud deberá esperar que se realice una operación de liberación del dato Q, para ello se utiliza la operación unlock(Q). Situaciones anómalas que se pueden dar al trabajar con bloqueos A medida que aumenta el tiempo en el que un dato permanece bloqueado, disminuye el grado de concurrencia. Se intentará en la medida de lo posible liberar los datos de bloqueos tan pronto se pueda. Aunque esto no siempre garantiza dejar el sistema estable. Por ejemplo, considere dos cuentas A y B, a las que acceden las transacciones tA , tV La primera transfiere C$500 de la cuenta B a la cuenta A, la segunda visualiza el total del saldo de (A+B). Si se realizan los desbloqueos de los datos tan pronto como sea posible las transacciones tA , tV pueden definirse como se muestra en la siguiente figura:

Ilustración 3-65: Definición de transacciones con desbloqueo inmediato

Si suponemos que la cuenta A tiene un

saldo inicial de C$1,000 y la cuenta B un saldo inicial de C$2,000. La operación display en tV generaría un dato incorrecto al sumar los saldos de las cuentas.

Si se ejecuta la planificación de estas transacciones como se muestra en la ilustración 3-67, la operación display muestra C$2,500, a diferencia de los C$3,000 que debería mostrar si las transacciones se ejecutaran de forma secuencial

Ilustración 3-66: Planificación concurrente con desbloqueos inmediatos


82

La situación de anomalía anterior se dio por que la transacción tA desbloqueó

el dato B demasiado pronto. Una solución a esto podría ser retrasar los desbloqueos. Una pequeña modificación de zonas de desbloqueos puede solucionar la situación presentada anteriormente. La figura siguiente muestra las transacciones anteriores modificadas, donde los desbloqueos en ambas se retrasan hasta el final de cada transacción:

Ilustración 3-67: Propuesta de transacciones con desbloqueos retrasados

Interbloqueos

Con la nueva posición de los desbloqueos en las transacciones anteriores, se soluciona la problemática de integridad. Pero esta nueva disposición puede dar paso a nuevas anomalías. Suponga la siguiente planificación de tA y tV con desbloqueos retrasados.

Ilustración 3-68: Planificación que presenta la anomalía de interbloqueo

Cuando ocurre un interbloqueo el sistema debe retroceder una de las

transacciones. Una ves hecho esto los datos son liberados.


83

Inanición

Suponga que la transacción tj realiza lock-S(Q). Posteriormente ti solicita lock-X(Q). ti debe esperar que tj haga un unlock(Q). Las transacciones ta , tb y tc solicitan lock-S(Q), obviamente se concede este modo compatible de bloqueo a las tres transacciones sobre el dato Q. Ahora ti tiene que esperar que tj , ta , tb y tc hagan un unlock(Q).

Al caso anterior donde la transacción ti no progresa, se le conoce como estado de inanición. Esto se evita si el gestor de control de concurrencia, concede los bloqueos de la siguiente manera: si una transacción ti solicita un bloqueo sobre un dato Q el gestor lo concede siempre que

1.- No existe otra transacción que posea un bloqueo sobre Q, que entre en conflicto con el modo de bloqueo solicitado. 2.- No exista otra transacción que esté esperando un bloqueo sobre Q, y que lo haya solicitado antes que ti.

Protocolo de bloqueo en dos fases

Este protocolo asegura la secuencialidad en cuanto a conflictos. Exige que las peticiones de bloqueo se realicen en dos fases:

1.- Fase de crecimiento: en esta fase una transacción solo puede pedir al gestor de concurrencia bloqueos, y no se le permite utilizar la orden unlock. 2.- Fase de decrecimiento: en esta fase la transacción puede liberar cualquiera de los bloqueos obtenidos, pero no puede solicitar nuevos.

El punto de planificación en el cual la transacción obtiene su bloqueo final (fin

de la fase de crecimiento) se denomina punto de bloqueo de la transacción. El protocolo de bloqueo en dos fases no adolece de interbloqueos. La planificación de las transacciones tA y tV con desbloqueos retrasados cumplen con este protocolo, pero como se analizó en la planificación concurrente anterior, presentan la anomalía de interbloqueos. Protocolo de bloqueo estricto en dos fases

Dado que el protocolo de bloqueo en dos fases presenta la anomalía de interbloqueo, el retroceso en cascada puede ocurrir al trabajar con este protocolo. El protocolo de bloqueo estricto, evita el retroceso en cascada de las transacciones. Esta variación del protocolo en dos fases, exige que los bloqueos sean en modo exclusivo, hasta que la transacción se complete, evitando que ninguna otra transacción lea el dato. Protocolo de bloqueo riguroso en dos fases

Exige que se posean todos los bloqueos hasta un commit de la transacción. Permite cambio de modo de bloqueo sobre un dato Q. El mecanismo para cambiar de modo compartido a modo exclusivo se realiza mediante la operación upgrade(Q). El mecanismo para cambiar de modo exclusivo a modo compartido es downgrade(Q).


84

Esta conversión no se lleva a cabo de forma arbitraria, la orden upgrade sólo

se permite en la fase de crecimiento, mientras que downgrade sólo puede tener lugar en la fase de decrecimiento. En el ejemplo siguiente se promueve el bloqueo del dato a1 de compartido a exclusivo para realizar la operación de actualización.

Ilustración 3-69: Planificación con conversión de bloqueos

Implementación de bloqueos

El gestor de bloqueos se implementa como un proceso que recibe mensajes de las transacciones solicitando: el bloqueo sobre un dato, o la liberación del mismo.

La estructura de datos que da soporte a este gestor es la siguiente: - Tabla de bloqueos: es una tabla de asociación indexada por el nombre del elemento (dato) de datos. - Por cada elemento en la tabla de bloqueos, mantiene una lista enlazada de registros, uno para cada solicitud, estos se ordenan por tiempo de llegada.

- Cada registro en la lista enlazada mantiene cuál fue la transacción y el modo de bloqueo que esta solicitó, para ser aplicado al dato en esa entrada de la tabla de bloqueo, también indica si el bloqueo fue concedido o se encuentra en espera. - Un índice identificador de transacciones, que determina el conjunto de bloqueos que mantiene una transacción dada.

Cuando llega una solicitud de bloqueo hecha por alguna transacción activa

en el sistema, el gestor de bloqueo hace lo siguiente:

-Si la entrada de datos no existe, crea una nueva y añade un nuevo registro de solicitud, por último concede el bloqueo solicitado. -Si la entrada existe, se añade el registro a la cola de la lista. Si el modo del bloqueo actual es compatible con el bloqueo solicitado, y no hay registros en espera, la petición de bloqueo se concede, en caso contrario queda en espera.


85

En cambio si el gestor de bloqueos recibe un mensaje de desbloqueo, por

parte de cualquier transacción activa: -Borra el registro de la lista enlazada asociada al dato bloqueado. -Prueba el siguiente registro (si lo hay) para determinar si se le puede conceder el bloqueo solicitado. -Realiza el paso anterior y se detiene, debido a que ha llegado al último registro, o por que se ha encontrado con un registro que solicita un modo de bloqueo incompatible.

Ilustración 3-70: Ejemplo de una tabla de bloqueos simplificada

Si la transacción que ha pedido un bloqueo sobre un dato Q se interrumpe,

puede desencadenar los siguientes sucesos:

- Se borra cualquier solicitud en espera realizada por la transacción, utilizando el índice que referencia a las transacciones con solicitudes de bloqueo. - Una vez que el sistema ha retrocedido satisfactoriamente la transacción libera todos los bloqueos que mantiene la transacción abortada.


86

Protocolos basados en grafo Los protocolos basados en grafos garantizan la secuencialidad en cuanto a conflictos, adolecen de interbloqueos. Se impone un orden (organización lógica o física) sobre un conjunto de datos D = {d1, d2,..,dn}. Si di antecede a dj, entonces toda transacción que accede tanto a di como a dj, debe acceder a di antes que a dj. Protocolo de árbol

Sólo permite la instrucción de bloqueo lock-X. toda transacción ti para solicitar un bloqueo debe seguir las siguientes reglas:

1.- El primer bloqueo de ti, puede hacerlo sobre cualquier dato. 2.- Si ti quiere hacer un nuevo bloqueo sobre un dato Q, debe poseer un bloqueo sobre el padre de Q en el árbol. 3.- En todo momento se puede hacer unlock(Q). 4.- ti no puede bloquear de nuevo un elemento de datos que haya bloqueado y desbloqueado con anterioridad.

El orden del conjunto de datos D se puede implementar como un grafo

dirigido acíclico, conocido como grafo de base de datos, la figura muestra un ejemplo de orden de datos en la basa de datos.

Ilustración 3-71: Grafo de la base de datos bajo el protocolo del árbol

El principal problema que presenta este mecanismo es que si se quiere

bloquear por ejemplo A, J se debe bloquear también B, D y H. Esto claramente aumenta el costo de los bloqueos sobre datos, debido a que se bloquean nodos intermedios sobre los cuales no se ejercerá ninguna acción.


87

La siguiente figura muestra un ejemplo de planificación concurrente utilizando

el orden del grafo de base de datos propuesto anteriormente.

Ilustración 3-72: Ejemplo de planificación secuenciable con protocolo de árbol

3.7.2 Protocolos basados en marcas temporales Marcas temporales Son marcas que asocia el sistema a cada transacción ti, antes de que ésta empiece su ejecución. La marca temporal de ti se denota como MT(ti). Si se ha asignado una marca a ti y entra una transacción nueva tj entonces MT(ti) < MT(tj). Se pueden utilizar dos métodos para implementar esto:

1.-Usar el valor del reloj del sistema para cada nueva transacción. 2.-Usar un contador lógico que se incrementa cada vez que se asigna una nueva marca temporal.


88

Las marcas temporales determinan el orden de secuencia, entonces si MT(ti)

< MT(tj), la planificación propuesta debe ser equivalente a una planificación secuencial ti tj. Para cada elemento de datos Q:

- marca_temporal_w(Q): denota la mayor marca temporal de todas las transacciones que han ejecutado con éxito write(Q). - marca_temporal_r(Q): denota la mayor marcatemporal de todas las transacciones que han ejecutado con éxito read(Q).

Protocolo de ordenación por marcas temporales Si ti ejecuta read(Q):

- Si MT(ti) < marca_temporal_w(Q), entonces el valor de Q leído está desactualizado. Hay que rechazar la operación read y retroceder ti. - Si MT(ti) >= marca_temporal_w(Q), entonces aceptar la operación, actualizar marca_temporal_r(Q).

Si ti ejecuta write(Q):

- Si MT(ti) < marca_temporal_r(Q), entonces el valor fue leído por una transacción que no fue ti, después de la lectura hecha por ti sobre ese dato. Por tanto, se debe rechazar ese write y retroceder ti. - Si MT(ti) < marca_temporal_w(Q). La transacción está intentando escribir un valor de Q obsoleto. Rechazar write y retroceder ti. En otro caso se ejecuta write y MT(ti) se asigan a marca_temporal_w(Q).

Aunque este protocolo garantiza la secuencialidad en cuanto a conflictos y la

ausencia de interbloqueos, existe la posibilidad de inanición. Si se está ejecutando una transacción larga y transacciones cortas provocan el reinicio repetido de esta transacción, es necesario bloquear las transacciones conflictivas para que la transacción larga termine. Para mostrar el funcionamiento del protocolo anterior, se utilizan las transacciones tg y tf. La primera visualiza el contenido de las cuentas A y B, mientras que tf transafiere C$100 de la cuenta A a la cuenta B, luego visualiza (A+B). La figura siguiente muestra las definiciones de estas transacciones:

Ilustración 3-73: Transacciones ejemplo para protocolo de marcas temporales


89

A continuación se muestra una simulación del método para la planificación

parcial concurrente de tg y tj, suponiendo que MT(tg) 21:06:00 y MT(tf) 21:07:00.

Ilustración 3-74: Planificación utilizando marcas temporales

3.7.3 Protocolos basados en validación

Se basan en sistemas en los que la mayoría de las transacciones son de solo lectura, por tanto la tasa de conflictos entre transacciones es baja. Las transacciones se pueden ejecutar en dos fases (solo lectura), o en tres fases (actualización):

1.- Fase de lectura: se almacenan y modifican los elementos en variables locales (sin actualizar la base de datos). 2.- Fase de validación: se prueba si los datos en memoria se pueden escribir en la BD sin violar la secuencialidad. 3.- Fase de escritura: una vez validadas las operaciones de escritura, se reflejan en la BD, en otro caso la transacción se retrocede.

Para hacer la prueba de validación, se debe determinar el orden de

secuencialidad, para esto se utiliza una técnica basada en las tres marcas temporales siguientes:

1.- Inicio(ti), momento en el cual ti comienza su ejecución. 2.- Validación(ti), momento en el cual ti termina su fase de lectura y comienza su fase de validación. 3.- Fin(ti), momento en el cual ti termina su fase de escritura.


90

Finalmente la comprobación de validación para una transacción ti , exige que

para toda ti con MT(ti) < MT(tj), se cumpla una de las dos condiciones siguientes:

1.- Fin(ti) < Inicio(tj). Puesto que ti completa su ejecución antes de que comience tj, el orden de secuencialidad se mantiene. 2.- Todos los elementos de datos que escribe ti , tienen intersección vacía con los datos que lee tj , y ti completa su fase de escritura antes que tj comience su fase de validación (esto evita que las escrituras de datos se superpongan).

Ejemplo de una planificación que aplica validación. Se utilizan las

transacciones tf y tj.

Ilustración 3-75: Planificación utilizando validación

Observe que Inicio(tf) < Fin(tg) y Fin(tg) < Validar(tf). Con esto garantizamos

que los datos en tg han sido validados y pueden ser escritos por tf

El esquema visto anteriormente se denomina control de concurrencia optimista, dado que las transacciones se ejecutan de forma optimista, asumiendo que serán capaces de finalizar su ejecución y validar al final. Los bloqueos y la ordenación por marcas temporales son pesimistas, debido a que fuerzan una espera o un retroceso cada vez que se detecta un conflicto aún cuando exista una posibilidad de resolverlo.

3.7.4 Granularidad múltiple La base de datos se modela en una estructura de árbol por zonas, donde cada zona contiene grupos de archivos como hijos, cada grupos de archivos contiene nodos hijos de tipo registro. Ningún archivo puede pertenecer a más de una zona. Ver la ilustración.


91

Ilustración 3-76: Ejemplo de árbol de jerarquía de granularidad

Una primera intención de aplicar este tipo de mecanismo es que los bloqueos

S y X, se hacen explícitamente sobre un nodo e implícitamente sobre su descendencia. Esto traería los siguientes inconvenientes:

1.- Trabajando con la estructura de árbol anterior ti bloquea todo el archivo Aa de forma explícita, de manera implícita también ra1, ra2,…, ran. Si otra transacción tj quiere bloquear explícitamente cualquier registro de Aa, cómo sabe qué registros están bloqueados? R = se recorre el árbol desde la raíz hasta rax si cualquier nodo del camino está bloqueado en modo incompatible, entonces se retrocede tj.

2.- Suponga que una transacción ti quiere bloquear todo el archivo de la base de datos. Para hacerlo sólo necesita bloquear la raíz. Esto se puede hacer en cualquier momento? R = si algún nodo del árbol se encuentra bloqueado en modo incompatible, no se logra bloquear la base de datos.

Por lo que hemos comentado este mecanismo no es muy conveniente,

vamos a ver un mecanismo que utiliza granularidad de forma más eficiente. Modo de bloqueo intencional Los bloqueos de “intensión” se colocan en toda la ruta en el árbol antes de llegar al elemento que se desea bloquear explícitamente. Los posibles modos intencionales bajo este mecanismo son los siguientes:

1.- modo_intencional_shared (IS): indica que en esa ruta se va a dar un modo de bloqueo compartido explísito. 2.- modo_intencional_exclusive (IX): indica que en esa ruta se va a dar un bloqueo exclusivo explícito.

3.- modo_intencional_exclusive_and_shared (IXS): el subárbol cuya raíz es ese nodo, se bloquea explícitamente en modo exclusivo, y dicho bloqueo explícito se expande a un nivel inferior con bloqueos en modo exclusivos.


92

A continuación se muestra la matriz de compatibilidad de granularidad

múltiple entre los distintos modos de bloqueos permisibles con este algoritmo:

IS IX S IXS X IS True True True True False IX True True False False False S True False True False False IXS True False False False False X False False False False False

Tabla 3-9: Matriz de compatibilidad para protocolo de granularidad múltiple.

La matriz de compatibilidad se usa de la siguiente forma: suponga que una

transacción ti quiere leer el registro rc1 entonces realiza los siguientes bloqueos sobre los nodos del árbol de la base de datos

- IS(BD), IS(Z2), IS(Ac), S(rc1 ). Ahora bien ti quiere realizar una operación sobre rbk , entonces debido a que existen bloqueos sobre el árbol consulta a la matriz de compatibilidad y para cada nodo en el camino hacia rbk pregunta lo siguiente: modo de bloqueo actual del nodo que se intenta bloquear y el nuevo modo de bloqueo son compatibles? Si la matriz de compatibilidad devuelve verdadero, entonces se concede el bloqueo de lo contrario se deberá esperar a que se libere ese nodo.

El protocolo de bloqueo de granularidad múltiple asegura la secuencialidad,

si cada transacción ti puede bloquear un nodo Q usando las reglas siguientes:

1.- Revisar la compatibilidad del nuevo modo de bloqueo que se desea aplicar utilizando la matriz de compatibilidad. 2.- Los bloqueos siempre empiezan desde la raíz, y dependiendo del grado de granularidad se bloquean explícitamente hojas o nodos internos del árbol.

3.- Puede bloquear un nodo Q en modo S o IS, sólo si está bloqueando actualmente al padre de Q en modo IX o IS. 4.- Puede bloquear al nodo Q en modo X, IXS o IX sólo si está bloqueando actualmente al padre de Q en modo IX o IXS. 5.- Puede bloquear un nodo, sólo si no ha desbloqueado un nodo previamente (el método es de dos fases). 6.- Para poder desbloquear un nodo Q debe haber desbloqueado antes a todos sus hijos.


93

Ejemplos de aplicación de bloqueos con esta técnica:

1.- Suponga que la transacción tinf , necesita leer todos los registros de Ab y Ac para generar un informe, entonces se bloquea la base de datos, Z1 y Z2 en modo IS, luego se bloquea Ab y Ac en modo S. 2.- Suponga que la transacción tact , necesita actualizar al registro rbk del archivo Ab, entonces bloquea la base de datos, Z1 y Ab en modo IX, luego bloquea el nodo rbk en modo X.


94

3.8 Recuperación frente a caídas del sistema Se tiene proyectado para este tema un total de ocho horas, de las cuales seis se utilizan para las lecciones magistrales y dos horas para desarrollar clases prácticas con los estudiantes. La tabla siguiente muestra una visión general de este tema.

TEMARIO 3.8.1 Estructura y operaciones de almacenamiento 3.8.2 Recuperación basada en registro histórico 3.8.3 Shadow pages 3.8.4 Transacciones concurrentes y recuperación

OBJETIVOS GENERALES

-Que el estudiante conozca los distintos mecanismos disponibles para la recuperación de sistemas de bases de datos frente a posibles fallos provocados por agentes internos o externos a la base de datos. -Que el estudiante reconozca los factores de riesgo a los que se encuentra expuesto un determinado sistema de bases de datos, y sea capaz de elaborar planes que reduzcan la probabilidad de pérdida de información.

EJE -Recuperación frente a fallos.




3.8.1 Estructura y operaciones de almacenamiento Los dispositivos que dan soporte al almacenamiento de datos son susceptibles a fallos: El Aterrizaje de cabezas en la unidad de disco hace que la información que éste mantenía se pierda (aunque en la mayoría de los HD actuales menos). La interrupción del suministro de energía (en Nicaragua, no es nada trivial considerarlo, perdemos el contenido de la memoria principal). Por último debemos considerar errores software, debido a insuficientes estudios en el diseño de las transacciones, ataques maliciosos sobre el sistema, etc.

Los tipos de almacenamiento más importantes que son utilizados por los sistemas de bases de datos son:

Almacenamiento volátil: Punto donde más nos tenemos que preocupar. La información que reside en el almacenamiento volátil no suele quedar disponible ante una caída del sistema. (MP, MCa). • Almacenamiento No Volátil: Discos, Cintas (frente a fallos más seguro que

el anterior).

Tema 6: Recuperación frente a caídas del sistema

95

• Almacenamiento estable: Redundancia de la Información. La estadística

frente a fallos es bastante aceptable. (por ejemplo, implementación de las técnicas RAID).

Las transferencias entre MP HD se realizan por medio de dos

operaciones la operación input y la operación output, el esquema de estas operaciones se muestra en la ilustración 3-77.

- input(x): bloque físico donde reside x Transferirlo a MP. - output(x): bloque de buffer donde reside x reemplazar en HD

Ilustración 3-77: Esquema general de las operaciones input y output.

Operaciones read y write

- read(X, xi) Asignar el valor del elemento de información X a la variable local xi. Si la Información está en MP Asignar a xi el valor de X sino input(X de a ). - write(X, xi) Asignar el valor de variable local xi al elemento de información X. Si la Información no está en MP hay que hacer otra vez un input(X de a ), El manejador de buffer necesitó ese espacio (Si el DBMS después de cada operación write, hace un output(X), entonces se dice que utiliza la técnica de salida forzada de bloques ).

Como hemos estudiado anteriormente, lo que parece ser correcto no siempre

genera los resultados esperados cuando utilizamos las operaciones de lectura y escritura. Suponer: Un sistema bancario y un conjunto de aplicaciones que acceden al sistema. Considere la operación transferir C$100 de la cuenta A(C$5000) a la cuenta B(C$2000). Veamos que situaciones se pueden dar

Ilustración 3-78: Posibles fallos de las operaciones input y output


96

En la gráfica anterior se muestra una posible falla al ejecutar la transacción

de transferencia propuesta, observe que para el usuario los valores de resultado son correctos, debido a que está visualizando datos en la memoria principal del sistema. De forma general estos errores podrían evitar que el programa termine con éxito: • Error Lógico: No existen las cuentas A o B. (entrada errónea) • Error de sistema: Verificación de paridad fallido. • Caída del sistema: a1 y b1 se pierden, no se pueden actualizar las copias

en disco. • Fallo de Disco: Error al ejecutar input(A) o input(B).

3.8.2 Recuperación basada en registro histórico

El registro histórico: es una secuencia de etiquetas que mantiene el historial de las actividades de actualización en la base de datos. Los tipos de etiquetas que se manejan dentro del historial: • <Ti starts>: La transacción Ti ha comenzado. • <Ti, Xj, Va, Vn>: La transacción Ti, ha realizado una escritura sobre el

elemento de datos Xj (Identificador, que suele coincidir con la ubicación del elemento de datos en disco), que tiene el valor actual Va y será reemplazado por el nuevo valor Vn.

• <Ti commits>: La transacción Ti se ha comprometido. • <Ti aborts>: La transacción ha sido finalizada explícitamente. Modificaciones diferidas

Las modificaciones se realizan de forma diferida en la base de datos. Primero se guardan las marcas de actualización en el archivo bitácora. Si Ti alcanza el estado parcialmente cometida se utiliza la información de T en el archivo bitácora para completar la transacción. Si el almacenamiento volátil falla, se podrá rehacer Ti solo cuando las marcas: <Ti starts> y <Ti commits> aparecen en la bitácora. Las operaciones que se guardan en el registro histórico deben ser idempotente, es decir, el resultado en la base de datos de ejecutar estas sentencias varias veces debe ser el mismo como que se hubiese ejecutado una vez.

Vamos a ver un primer ejemplo del funcionamiento de este mecanismo. Sean T0, T1 dos transacciones que se ejecutan de forma secuencial: T0, tranferir C$1000 de la cuenta A, a la B y depositar C$500 de B, a la cuenta C. A(1000), B(2000), C(700). T1, retirar desde un cajero automático C$200 de C.


97

Ilustración 3-79: Ejemplo de contenido de un archivo bitácora

Observe que no es obligatorio para este esquema especificar el valor

anterior del dato que fue modificado, es por esta razón que un undo(Ti) en realidad significa no realizar ninguna acción sobre la base de datos. Si el sistema falla luego de terminar de escribir T1 en el disco, una vez que este se recupera podrá ejecutar los cambios propuestos en estas transacciones.

Cómo funciona la técnica de recuperación? Después de ocurrir una falla (que no sea en el propio medio de almacenamiento no volátil) el subsistema de recuperación consulta el historial para determinar qué transacciones se deben repetir (aplicar redo(Ti)).

Caso de estudio A: Suponga que hay una caída del sistema después de

ejecutar la operación write(C, c1) en T0. La ilustración siguiente muestra gráficamente esta situación de fallo.

Ilustración 3-80: Descartar contenido del registro de historial (no commit)

Caso de estudio B: Suponga que hay una caída del sistema después de

ejecutar la operación write(C, c1) en T1. La ilustración 3-81 muestra gráficamente esta situación de fallo.

Caso de estudio C: Suponga que hay una caída del sistema después de se registra en el Historial <T1 commits>. La ilustración 3-82 muestra gráficamente esta situación de fallo.


98

Ilustración 3-81: Rehacer y deshacer transacciones con registro histórico

Ilustración 3-82: Rehacer las transacciones encontradas en el historial

Actualizaciones inmediatas

Las actualizaciones directamente en la base de datos (no se espera a que la transacción termine). No se permite la actualización en la base de datos hasta que su registro de historial (de modificación) este almacenado en almacenamiento estable.·Este mecanismo si exige el valor anterior del dato antes de ser modificado por la transacción. Pero, si se cae el sistema? Un undo(Ti) ahora significa que se restauran los valores que tenía el sistema antes de iniciarse esa transacción. La figura 3-83 muestra 3 casos en los que se aplica esta técnica.


99

Ilustración 3-83: Ejemplo de registro historial con actualizaciones inmediatas

Puntos de verificación (check points)

No es preciso repetir todas las transacciones cada vez que el sistema se cae. Cada cierto tiempo el sistema introducirá un punto de verificación en el historial indicando que hasta ese instante todas las operaciones anteriores han concluido con éxito. Cada vez que el sistema agrega un nuevo punto de verificación esto se debe hacer de forma atómica. ¿Ante una caída del sistema? Se examina el historial hacia atrás localizando el primer punto de verificación <checkpoint>, luego se tendrá que encontrar el primer registro <Ti starts> para aplicar las operaciones undo y redo sobre esta transacción y las transacciones Tj que le siguen a Ti.

3.8.3 Shadow pages Shadow pages o paginación doble, es otro algoritmo de recuperación frente a fallos. El total de bloque en disco ocupados por la base de datos, son apuntados por dos tablas que utilizan mecanismo de paginación, la tabla de paginación Actual (típicamente en memoria principal), y la tabla de paginación Doble (típicamente en disco). Cuando se inicia una transacción las dos tablas son idénticas. La tabla de paginación doble nunca se modifica mientras dure la transacción. Se trabaja en conjunto con el buffer y la tabla de páginas actual para tratar modificaciones. Este algoritmo supone una transacción en cada momento, y que la base de datos está compuesta sólo por un archivo.

Las modificaciones se tratan de la siguiente forma, suponga que una transacción realiza un a operación write(X, Xj), y que X reside en la página i:

1.- Si página i (donde está X) no reside en memoria hacer un input(X). 2.- Si es la primera operación de escritura que ejecuta esta transacción en la página i entonces, se debe Localizar una página vacía en disco, modificar Actual haciendo que la entrada i apunte a la nueva página. 3.- Asignar Xj a X en la página que está en el buffer.


100

Para dar una transacción como comprometida debe hacerse lo siguiente:

1.- Volcar las páginas modificadas en el buffer a disco (a las nuevas páginas creadas). 2.- Grabar a disco la tabla de paginación actual (no sobrescribir la tabla de paginación doble). 3.- Hacer que la referencia a la tabla de paginación doble sea la dirección de la tabla de paginación actual grabada anteriormente en disco (Actual ahora es Doble).

Ejemplo, suponer una transacción bancaria compuesta por 3 cuentas:

A($1,000), B($3,000) y C($2,500). Las operaciones que se realizan sobre estas cuentas son: transferir $500 de B a C y transferir $1,000 de C a A. El número de páginas de la base de datos es 10. Los datos de A y B se encuentran en la página 5 de la bases de datos y los datos de la cuenta C se encuentran en la página 1 de la base de datos. El estado inicial se muestra a continuación

Ilustración 3-84: Ejemplo de estado inicial del sistema en shadow pages

La figura siguiente muestra el proceso que se lleva en el sistema al

ejecutarse la transacción utilizando este mecanismo.

Ilustración 3-85: Proceso de ejecución de una transacción bajo paginación doble


101

3.8.4 Transacciones concurrentes y recuperación Hasta ahora solo hemos considerado una transacción en cada momento. Vamos a extender el esquema basado en registro histórico para permitir la ejecución concurrente de varias transacciones teniendo en cuenta el siguiente ámbito: • Una sola zona de memoria intermedia.

• Un único registro histórico independiente de las T.

• Se permiten actualizaciones inmediatas a la base de datos.

El mecanismo de control de concurrencia funciona de la siguiente forma: suponga que la transacción Ti modificó el dato X, y Ti Fracasa (hay que retroceder Ti). Si otra Tj realiza un cambio sobre X antes de completarse undo(Ti). Por ejemplo:

- <Ti, X, 1000, 900> ejecuta antes Tj: <Tj, X, 900, 500> - Al retroceder Ti, X queda en 1000 en vez de 600.

Solución al supuesto anterior: Ninguna transacción puede modificar el

mismo elemento de dato hasta que la transacción poseedora se comprometa o retroceda.

Puntos de revisión (<CHECK POINTS>) para transacciones concurrentes • Tienen la forma <CHECK POINT L>, donde L es la lista de transacciones

activas después del último Check Point.

• La recuperación implica recorrer hacia atrás el registros histórico y hasta encontrar el primer punto de verificación:

-Un <Ti Commits>, añade Ti a Lista-Redo. -Un <Ti Starts> y Ti no en L-Redo, añade Ti a Lista-Undo. Una vez construidas las listas Undo-Redo: -Deshacer las T en L-Undo (hacia atrás), ignorar L-Redo. -Rehacer las T en L-Redo (hacia adelante).

Capítulo 4 : Prácticas de laboratorio

Objetivos generales

103

4.1 Objetivos generales • Elaborar un conjunto de prácticas sencillas de gestión de bases de datos con

los conceptos más relevantes, que sirvan de patrón para el desarrollo de propuestas de sistemas completos de bases de datos.

• Promover en el estudiante el trabajo en equipo para desarrollo de sistemas

de bases de datos.

4.2 Introducción Las prácticas de laboratorio se proponen en dos momentos, el primero, consiste en dejar al estudiante una serie de módulos de aplicaciones sencillas, que le permitan irse adiestrando en la utilización de una serie de herramientas software para la implementación de sistemas de bases de datos. En esta primera parte las prácticas estarán propuestas desde el inicio en el Web. El segundo momento, contempla la elaboración de un pequeño sistema de bases de datos. Para esta segunda parte el estudiante cuenta con la experiencia de las prácticas que ha elaborado en la asignatura bases de datos I, y las prácticas que ha realizado en las primeras sesiones de laboratorio en esta propuesta.

El seguimiento del proyecto se realizará de forma semanal. Para cada encuentro entre el profesor y el estudiante este último deberá presentar avances según un pequeño diagrama de actividades que el estudiante elabora antes de iniciar el proyecto.

Todas las propuestas de prácticas de laboratorio han sido guiadas por el

autor de este documento y elaboradas por estudiantes del último curso de la carrera. Los estudiantes han dedicado un gran esfuerzo y tiempo a desarrollar el conjunto de prácticas que aquí se presentan, para que sirvan de guía a los estudiantes del tercer año de esta carrera. Aunque el enfoque desde el punto de vista didáctico y de herramientas software para el desarrollo de los distintos entornos de implementación de aplicaciones, ha sido propuesto por el autor del documento, la influencia en la forma como se presentaban los conceptos está bastante marcada por propuestas frescas e inquietudes recopiladas por los estudiantes.

4.3 Mecanismo de evaluación de laboratorios Debido a que el desarrollo del proyecto de aplicación de bases de datos supone un mayor esfuerzo, éste representa el 70% de la calificación de prácticas de laboratorio, y será elaborado en grupos no mayores de 3 estudiantes. El otro 30% el estudiante se obtiene de la entrega y defensa de todas las propuestas de laboratorio que se le indiquen.

Desarrollo de las prácticas de laboratorio

104

El 30% del puntaje total asignado a las prácticas de laboratorio será evaluado

en el primer examen parcial de la asignatura, es decir, el estudiante tendrá hasta antes de la fecha prevista a realizar el primer examen teórico, para resolver los ejercicios que se proponen en la primer parte de prácticas de laboratorio. Para que pueda cumplir con la entrega de prácticas, el docente encargado del laboratorio garantizará la instalación del software necesario, y la apertura de las cuentas de usuario y permisos correspondientes que el estudiante necesita para empezar a trabajar desde la segunda semana se clases.

El otro 70% de la evaluación práctica abarca el examen segundo parcial y

final de la asignatura, esto quiere decir que el estudiante tiene como fecha tope de entrega de la aplicación hasta la fecha en que se realice el examen final teórico. Luego de la entrega se propone un ciclo de defensas de cada proyecto.

4.4 Temporización de las prácticas Para elaborar las prácticas que propuestas se cuenta con un total de 16 semanas (2 horas por semana), pero sólo 15 efectivas debido a que la primera se deja para poner a punto los laboratorios. La tabla siguiente muestra los tiempos en que se deben completar las prácticas que se proponen en este documento. Práctica propuesta Tiempo

desarrollo Instalación de PostgreSQL Acceso a PostgreSQL mediante ODBC Familiarización con el entorno PostgreSQL Creación de la estructura de la base de datos Sentencias de manipulación de datos con SQL Creación de una interfaz sencilla con VC++

FASE I 4 Semanas

Proyecto de aplicación de un sistema de bases de datos

FASE II 11 Semanas

4.5 Materiales para el desarrollo de las prácticas Para desarrollar las prácticas de laboratorio, se necesitan los siguientes componentes software instalados en laboratorio:

1. Plataformas Microsoft Windows 2000 o superior y Linux distribución Red Hat preferiblemente 8.0.

2. Microsoft Visual Studio 6.0, en concreto se utilizarán los productos: Visual

Basic y Visual C++. 3. Microsoft Access. 4. Driver ODBC para PostgreSQL.

Prácticas previas

105

4.6 Prácticas previas Este conjunto de prácticas son de carácter obligatorio. El estudiante debe entregarlas como fecha tope, el día de la programación del primer examen teórico de la asignatura. Estas prácticas le sirven al estudiante como entrenamiento para elaborar luego en equipo el proyecto de aplicación final de un sistema de bases de datos.

4.6.1 Práctica 0: Instalación de PostgreSQL Ahora, vamos a describir el proceso de instalación de PostgreSQL para Linux. En nuestro caso hemos utilizado la distribución Red Hat Linux 8.0, por lo tanto, de aquí en adelante siempre que hablemos de Linux estaremos haciendo referencia a dicha versión.

Linux utiliza un sistema de gestión de paquetes denominado RPM (Red Hat Package Manager) que permite instalar fácilmente el gestor de base de datos. Además PostgreSQL viene incluido en la distribución estándar de Linux por lo que simplemente hemos de tener presente a la hora de realizar la instalación del sistema operativo seleccionar en los grupos de paquetes a instalar la opción “Servidor de base de datos SQL”. Hay que tener en cuenta que si se realiza la instalación de PostgreSQL de esta manera solo se instalaran los paquetes básicos como son: PostgreSQL-7.2.2-1.i386.rpm PostgreSQL-server-7.2.2-1.i386.rpm Postgresql-libs-7.2.7-1.i386.rpm

Los cuales permiten utilizar PostgreSQL pero sin muchas de sus capacidades, como por ejemplo el paquete PostgreSQL-odbc-7.2.2-1.i386.rpm que permite conectar PostgreSQL con programas que tienen un drivers ODBC compatible (tal como Acces) y Postgresql-tcl-7.2.2-1.i386.rpm que permite instalar aplicaciones PostgreSQL que requieren soporte tcl tales como pgacces (cliente gráfico de base de datos), entre otros paquetes que aumentan considerablemente la capacidad de PostgreSQL.

En caso de que haya realizado una instalación como la antes descrita y quisiera agregar paquetes que le den a PostgreSQL la potencialidad que usted necesita en el CD 3 de instalación de Red Hat Linux encontrará dichos paquetes y para su instalación puede seguir el numeral 3 de los pasos descritos a continuación. Si no tiene instalado PostgreSQL para proceder a realizar su instalación siga los pasos siguientes: Nota: Si ya tiene Linux instalado es recomendable antes de proceder a realizar la instalación, verificar primero si ya tiene o no instalado PostgreSQL. Esto se puede hacer mediante el siguiente comando: rpm –qa|grep -i postgres. Con esta orden se listaran los paquetes PostgreSQL instalados si existen.


106

1. En la distribución de Red Hat Linux 8.0, en el CD número 2, está el paquete fuente de PostgreSQL-7.2.2-1.i386.rpm, así como también sus librerías (PostgreSQL-libs-7.2.2-1.i386.rpm). Copiar los archivos a un directorio temporal de compilación, por lo general se utiliza usr/src/ (el cual será nuestro caso) para almacenar los códigos basados en RPM, pero puede elegir otro directorio si usted desea. Una vez copiado los archivos mediante la siguiente orden:

$cp postgresql-nombre_paquete-7.2.2-1.i386.rpm /usr/src/ 2. Nos movemos al directorio mencionado, pero antes de proceder a realizar la instalación de los paquetes individuales nos tenemos que convertir en el usuario root, de lo contrario no podremos realizar la instalación. Otra cosa que hay que tener presente es el orden en que se van extrayendo los paquetes: Primero se procede con las librerías mediante la orden:

[jyo@localhost src]$ rpm –Uvhi postgresql-libs-7.2.2-1.i386.rpm Después se procede con los siguientes paquetes, en el orden respectivo:

[jyo@localhost src]$ rpm –Uvhi postgresql-7.2.2-1.i386.rpm [jyo@localhost src]$ rpm –Uvhi postgresql-server-7.2.2- 1.i386.rpm

3. Hasta aquí, ya tiene instalado PostgreSQL (ya operativo) en su sistema pero sin muchos de los paquetes que proporcionan a PostgreSQL soporte adicional, y esos paquetes son: • PostgreSQL-odbc-7.2.2-1.i386.rpm: que permite conectar PostgreSQL con

programas que tenga un drivers ODBC. • Postgresql-jdbc-7.2.2-1.i386.rpm: Activa el soporte Java. • Postgresql-perl-7.2.2-1.i386.rpm: esta opción es necesaria si usted pretende

utilizar lenguajes procedurales. • Postgresql-contrib-7.2.2-1.i386.rpm: • Postgresql-devel-7.2.2-1.i386.rpm • Postgresql-python-7.2.2-1.i386.rpm: Esta opción sólo se requiere si usted

planea usar el lenguaje procedural pl/Python. • Postgresql-tcl-7.2.2-1.i386.rpm: Esta opción instalará aplicaciones

PostgreSQL y aplicaciones que requieren Tcl, tales como pgaccess (un popular cliente gráfico de bases de datos) y el lenguaje procedural pl/Tcl.

Prácticas previas

107

Para proceder a la instalación de cualquiera de los paquetes anteriores utilice

la orden: rpm –Uvhi postgresql-nombre_paquete-7.2.2-1.i386.rpm Nota: si no tiene los CD de instalación puede visitar el sitio Web de PostgreSQL (www.postgresql.org) para descargar los paquetes que usted necesite.

4.6.2 Práctica 1: Acceso a PostgreSQL mediante ODBC. Los sistemas que son usados actualmente por compañías, instituciones, agrupaciones pequeñas o grandes, tratan de utilizar sistemas homogéneos, es decir, las mismas plataformas, las mismas aplicaciones para no tener problemas de conectividad, eso seria lo ideal, pero bueno estamos en un mundo globalizado, en donde cada vez mas las empresas se asocian y comparten información, cuando sucede esto lo primero que tienen que hacer es interconectar sus sistemas, para poder compartir información o los recursos deseados, pero también se enfrentan muchas veces al primer problema, "la plataforma que usa la otra empresa es distinta a la que usamos nosotros!!", la base de datos, no son las mismas, ahí es donde entran los sistemas abiertos que hacen que no importen las diferencias.

Bien nos enfrentaremos a escenarios con sistemas heterogéneos. Existen muchos estándares para lograr conectividad, uno de ellos es el estándar ODBC (Open Data Base Conectivity), el cual permite hacer conexión con un origen de Datos, o sea, mediante un controlador acceder a una base de datos desde plataformas distintas de la plataforma en que está el origen de datos (nuestro Gestor de Base de Datos).

Ilustración 4-1: Acceso a postgreSQL desde Windows

Para esto necesitaremos tener el drivers ODBC para PostgreSQL, el cual lo

podemos obtener del siguiente servidor:

ftp: http://odbc.postgresql.org/ftpsite/odbc/versions/full/

A continuación se describe la instalación y configuración de PsqlODBC en una plataforma Windows XP.


108

Instalación del driver ODBC En primer lugar, lanzamos la ejecución del fichero PsqlODBC.exe con lo cual aparece el asistente de instalación. Dejar las opciones por defecto.

Ilustración 4-2: Pantalla de inicio de instalación del driver ODBC

Configuración del Driver ODBC Seguidamente, desde el panel de control, seleccionamos la opción Rendimiento y Mantenimiento, luego Herramientas del Sistema y ahora de click en origen de datos ODBC y configuraremos el DSN (data source names ) del sistema, añadiendo el driver PsqlODBC que acabamos de instalar. Para ello damos clic en la opción "Agregar" nos aparece el siguiente cuadro. Seleccionamos PostgreSQL

Ilustración 4-3: Creación del nuevo origen de datos

Prácticas previas

109

Ilustración 4-4: Interfaz de configuración del driver

Ahora procedemos a configurar desde la pantalla mostrada anteriormente.

Para ello debemos insertar los datos correspondientes a nuestra base de datos (Database = nombre de la base de datos a la que se quiere acceder), nuestro servidor (Server = nombre o número IP del servidor donde está alojada nuestra base de datos), el nombre de usuario (User Name = nombre del usuario postgres autorizado para acceder a la base de datos, ver configuración del archivo pg_hba.conf) y el Password de acceso (Contraseña del usuario postgres).

Si usted desea puede seleccionar las opciones avanzadas Data Source y Global que nos permitirán de manera general: • Seleccionar opciones de acceso ( read-only, exclusive... ) • Especificar Conversiones de tipo. • Elegir Opciones de caché y de métodos de indexación. • Decidir si se exportan o no las tablas internas.

Una vez configurado el sistema, cerramos el panel de control y aunque no es necesario reiniciar la máquina, no estaría de más. Para que la configuración tenga éxito, el servidor de PostgreSQL debe estar correctamente configurado y funcionando. Pruebe haciendo un Telnet desde Windows a Linux al puerto 5432. Finalmente, ahora que ya tenemos el servidor y el cliente instalados, podemos empezar a trabajar con el sistema.

4.6.3 Práctica 2: Familiarización con el entorno PostgreSQL El objetivo es lograr que el estudiantes sepa cómo crear un sistema de ficheros mediante la opción initdb y sus variantes para poder iniciar un servidor de base de datos en el mismo usando el comando postmaster con sus opciones. 1.- Crear un sistema de base de datos llamado prueba. • Initdb prueba ó Initdb –D prueba


110

2.- Crear un sistema de base de datos llamado prueba1 que impida que se creen todos los ficheros en caso que ocurra un error y remueva todos aquellos ficheros que se hayan creado. • Initdb prueba1 –n 3.- Crear un sistema de base de datos llamado prueba2 que imprima la salida de depuración del backend. • Initdb prueba2 –d 4.- ¿Qué es el postmaster? Es el proceso que administra la comunicación entre el proceso cliente y el servidor, aunque el postmaster no interactúa directamente con el usuario crea un proceso en segundo plano llamado frontend que es el que interactúa directamente con el usuario. 5.- ¿Cómo se detiene el servidor de base de datos (postmaster)? • Ps aux | grep postmaster • Kill –s SIGTERM No_proceso_de_postmaster 6.- Iniciar el servidor de base de datos para el sistema de ficheros llamado prueba. • Postmaster –D prueba 7.- Iniciar el servidor de base de datos para el sistema de ficheros llamado prueba1 que permita conexiones remota usando el protocolo TCP/IP y atienda peticiones por el puerto 5430. • Postmaster –D prueba1 –i –p 5430 8.- Iniciar el servidor de base de datos para el sistema de ficheros llamado prueba1 que permita el intercambio entre cliente / servidor de manera encriptada. • Postmaster –D prueba1 –i –l 10.- ¿Qué sucede si se intenta iniciar un proceso postmaster con las opciones por defecto cuando ya existe otro proceso postmaster ejecutándose con las mismas opciones? Argumente.

4.6.4 Práctica 3: Creación de la estructura de la base de datos Con esta practica se pretende lograr que el estudiante sea capaz de crear y borrar bases de datos en el sistema de fichero creado en la practica 1, así como también crear, modificar y borrar tablas.

Prácticas previas

111

1.- ¿Qué comandos se pueden utilizar en PostgreSQL para crear base de datos? • createdb: permite crear una base de datos desde el prompt de linux el cual

puede ser usada para ser pasada como parámetro cuando se desea utilizar el psql.

• create database: también permite crear base de datos pero desde el psql. 2.- Crear una base de datos llamada registros para un servidor que escuche peticiones por el puerto por defecto. • Createdb registros 3.- Crear una base de datos llamada registros1 para un servidor que escucha • peticiones por el puesto 5430: Createdb –p 5430 registros1 4.- ¿Qué comandos se pueden utilizar en PostgreSQL para borrar base de datos? • dropdb: permite borrar base de datos desde el prompt de linux.

• drop database: permite borrar base de datos desde el psql. 5.- Borrar la base de datos que se llama registros1 pidiendo la confirmación antes de borrar la base de datos. • Dropdb –p 5430 –i registros1

4.6.5 Práctica 4: Sentencias de manipulación de datos con SQL. En esta práctica introduciremos algunas sentencias SQL, que modificaran y consultaran la base de datos a la que estamos. 1.- Crear una tabla llamada clases que tenga como atributos cod_asig, nombre_asig y carrera de tipo texto de una longitud definida por usted. • Create table clases(cod_asig varchar(10),nombre_asig varchar(30),carrera

varchar(25)); 2.- Cambiar el nombre del atributo llamada nombre_asig de la tabla creada anteriormente por el nombre asignaturas. • Alter table asignaturas Rename nombre_asig To asignaturas


112

3.- Listar la estructura de la tabla. • \d clases 4.- Agregar el atributo anio_acad a la tabla clases el cual será de tipo numérico y contendrá el año académico en que dicha asignatura es impartida y que contenga valor por defecto 1. • Alter table clases Add anio_acad int default 1; 5.- Cambie el nombre de la tabla clases por el nombre asignaturas y luego visualice los resultados. • Alter table clases rename asignaturas. 6.- Inserte cinco registros a la tabla asignaturas (una por cada año académico). • Insert into asignaturas values(‘001’,’Base de Datos I’,’Computacion’,3); • Insert into asignaturas values(‘002’,’Introduccion a la Informatica’ ,

’Computacion’ ,1); • Insert into asignaturas values(‘003’,’Sistema Operativo’,’Computacion’,4); • Insert into asignaturas values(‘004’,’Redes I’,’Computacion’,5); • Insert into asignaturas values(‘005’,’Programacion I’,’Computacion’,2); 7.- Visualice los resultados • Select * from asignaturas; 8.- Cambiar el código de asignatura para Redes I. Poner como nuevo código 010 y visualice los resultados. • Update asignaturas set cod_asig=’010’ where asignaturas.asignaturas

nombre=’Redes I’; 9.- Eliminar todos los registros de la tabla asignaturas. • Truncate asignaturas; • Delete from asignaturas; 10.- Visualice los registros de la tabla asignaturas. • Select * from asignaturas; 11.- Borre la tabla asignaturas. • Drop table asignaturas;

Prácticas previas

113

Antes de continuar con esta práctica el estudiante deberá crear la tabla

estudiantes con atributos:

- nombre texto -apellidos texto -asignatura texto -becado true/false -ciudad texto

Luego deberá insertar 10 registros, de los cuales 6 deberán ser becados, 3

de los registros debe tener como ciudad león, 4 de Managua y 3 de Masaya. Como asignatura 3 registros contendrán Redes, 5 de Programación y 2 de Informática. 12.- Visualice todos los registros de la tabla estudiantes. • Select * from Estudiantes; 13.- Seleccionar todos aquellos estudiantes que sean becados. • Select * from Estudiantes where becado=true; 14.- Seleccionar el nombre y el apellido de los estudiantes que sean de la ciudad de León. • Select nombre, apellidos from estudiantes where ciudad=’leon’; 15.- Visualizar todos los estudiantes que lleven la asignatura de Redes. • Select * from estudiantes where asignatura=’Redes’; 16.- Seleccionar todos los estudiantes de sean de managua y que no sean becados. • Select * from estudiantes where ciudad=’managua’ and becado=false; 17.- Seleccione a los estudiantes que sean de la ciudad de Managua o Masaya • Select * from estudiantes where ciudad=’Managua’ or ciudad=’Masaya’; 18.- Seleccionar el nombre, apellidos, ciudad y becado de los estudiantes que llevan la asignatura de Programación. • Select nombre,apellidos,ciudad,becado from estudiantes where

asignatura=’Programacion’;

Recordemos un poco. En los ejercicios anteriores existe una tabla Estudiantes. Agregarle a dicha tabla dos nuevos atributos llamado no_carnet de tipo texto de longitud 10, y edad de tipo entero.


114

Teniendo en cuenta que el número de carnet tiene que empezar con 00-

00001-0 y terminar con 00-00010-0 y la edad tiene que ir entre 18 y 30, • Alter table Estudiante add no_carnet varchar(10); • Alter table Estudiante add edad int; 19.- Seleccionar de la tabla Estudiantes las personas cuyo número de carnet este entre el 00-00002-0 y el 00-00007-0. • Select * from Estudiante where no_carnet between ‘00-00002-0’ and ‘00-

00007-0’; 20.- Seleccionar a los estudiantes cuyo número de carnet este comprendido entre 00-00001-0 y 00-00004-0 y del 00-00008-0 al 00-00010-0. • Select * from Estudiantes where no_carnet not between

’00-00005-0’ and ’00-00008-0’; 21.- Seleccionar el nombre, apellido y número de carnet de los estudiantes vivan ya sea en León, Managua y Masaya. • Select nombre,apellido,no_carnet from Estudiantes where ciudad

in(‘leon’,’managua’,’masaya’); 22.- Calcular el total de los estudiantes becados. • Select count(becado) as total from Estudiantes where becado=true; 23.- Calcular el total de los estudiantes que llevan la asignatura de programación. • Select count(asignatura) as total from Estudiantes where

asignatura=’programacion’; 24.- Calcular el total de estudiantes cuya edad este comprendida entre 20 y 27. • Select count(edad) as total from Estudiantes where edad between 20 and 27; 25.- Escriba la consulta que de cómo resultado la edad mínima de los estudiantes. • Select min(edad) as menor from Estudiantes; 26.- Escriba la consulta que de cómo resultado la edad máxima de los estudiantes. • Select max(edad) as mayor from Estudiantes; 27.- Obtener el número de carnet, nombre, apellido de los estudiantes que tengan edad entre 20 y 25. • Select no_carnet,nombre,apellido from Estudiantes where edad between 20

and 25;

Prácticas previas

115

4.6.6 Práctica 5: Creación de una interfaz sencilla con VC++ Esta práctica fue guiada en cuanto a contenido y alcance por el autor de este documento, y diseñada por un estudiante de intercambio bajo el programa PIMA. En primer lugar este documento supone que ha sido instalado el controlador ODBC adecuado y que la base de datos ha sido incluida en el origen de datos. 0. Explicación teórica El modo de acceder a una base de datos empleando ODBC es algo distinto a hacerlo mediante un cliente de bases de datos o la línea de comandos. Se puede acceder a Visual C++ desde dos tipos de clases, la clase CDataBase y la clase CRecordset. La diferencia entre ambas es notable, con la clase CDataBase podemos conectarnos a una base de datos y podemos ejecutar sentencias SQL sobre la base de datos pero no podemos operar con registros. Con la clase CRercordset si podemos trabajar con registros.

Visual C++ representa las tablas de una base de datos mediante clases que heredan de la clase base CRecordset. Los atributos de estas clases son los atributos de la tabla.

Cuando hacemos una conexión a la base de datos mediante una instancia de la clase, esta instancia representa a una fila completa de datos. Podemos acceder a estos datos leyendo los atributos de la clase.

Es decir, tenemos una tabla y controlamos esta tabla mediante una variable que representa una fila de nuestra tabla. Utilizando los métodos que se nos proporcionan podemos movernos por la tabla.

Para este documento se va a utilizar una tabla cuyas especificaciones se detallan a continuación:

- Campo “Nombre” de tipo cadena de caracteres. - Campo “Direccion” de tipo cadena de caracteres. - Campo “DNI” de tipo entero. - Campo “Teléfono” de tipo entero. - DNI es clave primaria.

1. Creación del Proyecto de Visual C++ -Tendremos que acudir al menú archivo, nuevo. -Seleccionar la pestaña de proyectos y elegir: “MFC AppWizard(exe)” -Hay que indicar el nombre de Proyecto que vamos a crear así como la ruta donde va a ubicarse.


116

Ilustración 4-5: Creando el proyecto en VC++

- En el siguiente paso (MFC AppWizard – Step1) hay que seleccionar “Single document” y presionar “Next >” - En MFC AppWizard –Step2 tenemos que presionar el radio botón “Database view without file support” y luego presionar “Data Source” - Se ha de seleccionar la base de datos a la que queremos acceder, que esto sea posible, requiere como se dijo al principio del documento que haya sido incluida dicha base de datos en el origen de datos ODBC en el Panel de Control - Una vez seleccionada la base de datos, el compilador nos pedirá que seleccionemos las tablas de nuestra base de datos que queremos incluir en el proyecto. En nuestro caso tan solo hemos de seleccionar una tabla. - Los pasos 3, 4, 5 y 6 no es necesario modificarlos, las mas adecuadas son las opciones por defecto. 2. Creación de la interfaz Gráfica Una vez que hemos creado nuestro proyecto, tenemos que realizar dos partes claramente diferenciadas. Una es la parte que hemos de escribir mediante código y otra es la parte de diseño que se puede realizar con la herramienta que nos proporciona Visual C++.

Prácticas previas

117

Después de haber creado nuestro proyecto hemos de dirigirnos a la parte

izquierda de nuestras pantallas y contemplar una ventana con tres pestañas: “Class”, “Resources” y “FileView”. Tenemos que pulsar la pestaña de Resources y expandir pestañas del siguiente modo:

Ilustración 4-6: Creación de formularios

Cuando pulsemos sobre ese recurso en la pantalla central nos aparecerá un

Frame que podemos rellenar con botones y cajas de texto a nuestra elección. En alguna parte de nuestra pantalla debe encontrarse la siguiente barra de herramientas que nos es imprescindible:

Ilustración 4-7: Barra de herramientas de formulario

Después de haber colocado los botones y las cajas de texto nuestra Frame

tiene que tener un aspecto similar al siguiente:


118

Ilustración 4-8: Interfaz principal de ejemplo

3. Cómo introducir y extraer información de las cajas de texto Para manejar las cajas de texto en Visual C++ hay dos modos distintos de hacerlo. El primero: Mediante actualización de variables miembro asociadas a las cajas de texto. Es decir, por cada caja de texto que creamos, asociamos a esta una variable de tipo String. Pulsando la pestaña View de la barra de herramientas y luego seleccionando ClassWizard.

Ilustración 4-9: Actualización de variables miembro

Prácticas previas

119

- En esta pestaña podemos observar que están representados todos los

botones, cajas de texto y etiquetas que tenemos en nuestro documento1. - Para añadir una variable asociada a nuestra caja de texto tenemos que

primero seleccionar el objeto y luego pulsar el botón Add Variable:

Ilustración 4-10: Asociar la variable miembro a un string

- Ya tenemos asociada nuestra variable. - En principio hay dos operaciones distintas. Una es cuando queremos reflejar

el contenido de la variable en la caja de texto y otro cuando queremos que el valor de la caja de texto pase a la variable.

o Si queremos que el valor de la variable pueda verlo el usuario en la

caja de texto tenemos que introducir la siguiente línea de código: “UpdateData(false);”.

o Si queremos cargar en la variable el valor de la caja de texto para por

ejemplo trabajar con los datos, entonces tenemos que incluir: “UpdateData(true);”.

El segundo es mediante la llamada a dos métodos: SetDlgItemText(ID,CString) y GetDlgItemText(ID,CString). El método Set introduce en la caja de texto el CString pasado como parámetro. El método Get introduce en la variable CString pasada como parámetro el contenido de la caja de texto.

1 Por defecto el entorno de desarrollo adjudica nombres tales como IDC_EDIT1 ó IDC_BUTTON1. Para mejorar la legibilidad podemos modificar esto pulsando con el botón derecho sobre el elemento y modificando dentro de propiedades la propiedad ID.


120

4. Añadir un evento a un botón En nuestro caso tenemos que añadir eventos a todos los botones. Esto es muy sencillo, desde la Frame, tenemos que hacer doble clic sobre el botón que queremos realice alguna opción. Y en la ventana que posteriormente nos saldrá dar el nombre a la función asociada que queramos (normalmente esta bien si dejamos lo que el compilador nos incluye por defecto). 5. Edición del Código Al código se puede acceder mediante el explorador de proyectos situado en la parte izquierda de la pantalla.

Ilustración 4-11: Visor de clases

Se puede observar que el compilador ha creado muchas clases, pero a

nosotros sólo nos va a preocupar la clase CNombreDeProyectoView.

Siempre que se crea un documento, el programa entra a un método de ésta clase: “OnInitialUpdate()”2. En este método vamos incluir el código necesario para crear la primera conexión a la base de datos e introducir en una caja de texto el nombre de la base de datos: void CProyecto3View::OnInitialUpdate() { m_pSet = &GetDocument()->m_proyecto3Set; CRecordView::OnInitialUpdate(); GetParentFrame()->RecalcLayout();

2 Este método pertenece a la clase CNombreDeProyectoView, podemos acceder a el pulsando doble clic sobre él en la parte izquierda: (Ilustración 2).

Prácticas previas

121

ResizeParentToFit();

//conectamos a la base de datos. No hay que espeficar nombre porque ya ha sido asociado desde un principio

m_pSet->GetDefaultConnect(); //creamos una variable de tipo string e introducimos en ella el nombre de la tabla

CString nombreTabla=m_pSet->GetTableName(); //introducimos el nombre en la caja de texto SetDlgItemText(IDC_EDIT_NOMBRE_TABLA,nombreTabla); }

Código del botón Buscar por Nombre: void CProyecto3View::OnBotPorNombre() { //Conexion a la base de datos m_pSet->GetDefaultConnect(); m_pSet->Close(); CString LoQueHayEnLaCajaDeTexto; CString Temporal; //Capturo los datos de la caja de texto, el nombre que he de buscar GetDlgItemText(IDC_EDIT_POR_NOMBRE,LoQueHayEnLaCajaDeTexto); //Introduzco la condición sql m_pSet->m_strFilter= "Nombre ='"+LoQueHayEnLaCajaDeTexto+"'"; //Creo una conexión con la condición m_pSet->Open(); //si ha cargado registros es que existe en la base de datos int numeroRegistros= m_pSet->GetRecordCount(); //si la consulta a devuelto algun resultado if (numeroRegistros>0){ int TemporalEntero=(int) m_pSet->m_Telefono; Temporal.Format("%i",TemporalEntero); SetDlgItemText(IDC_EDITNOMBRE,m_pSet->m_Nombre); SetDlgItemText(IDC_EDITDIRECCION,m_pSet->m_Direccion); SetDlgItemText(IDC_EDITTELEFONO,Temporal); TemporalEntero=(int) m_pSet->m_DNI; Temporal.Format("%i",TemporalEntero); SetDlgItemText(IDC_EDITCEDULA,Temporal); m_cargadoRegistro=true; }


122

//si el registro no ha sido encontrado en la base de datos else { SetDlgItemText(IDC_EDITNOMBRE,"No encontrado"); SetDlgItemText(IDC_EDITDIRECCION,"No encontrado"); SetDlgItemText(IDC_EDITTELEFONO,"No encontrado"); SetDlgItemText(IDC_EDITCEDULA,"No encontrado"); } } Código del botón Buscar por Cedula void CProyecto3View::OnBotPorCedula() { m_pSet->GetDefaultConnect(); m_pSet->Close(); CString LoQueHayEnLaCajaDeTexto; CString Temporal; GetDlgItemText(IDC_EDIT_POR_CEDULA,LoQueHayEnLaCajaDeTexto); m_pSet->m_strFilter= "DNI ="+LoQueHayEnLaCajaDeTexto; m_pSet->Open(); //si ha cargado registros es que existe en la base de datos int numeroRegistros= m_pSet->GetRecordCount(); if (numeroRegistros>0){ int TemporalEntero=(int) m_pSet->m_Telefono; Temporal.Format("%i",TemporalEntero); SetDlgItemText(IDC_EDITNOMBRE,m_pSet->m_Nombre); SetDlgItemText(IDC_EDITDIRECCION,m_pSet->m_Direccion); SetDlgItemText(IDC_EDITTELEFONO,Temporal); TemporalEntero=(int) m_pSet->m_DNI; Temporal.Format("%i",TemporalEntero); SetDlgItemText(IDC_EDITCEDULA,Temporal); m_cargadoRegistro=true; } else { SetDlgItemText(IDC_EDITNOMBRE,"No encontrado"); SetDlgItemText(IDC_EDITDIRECCION,"No encontrado"); SetDlgItemText(IDC_EDITTELEFONO,"No encontrado"); SetDlgItemText(IDC_EDITCEDULA,"No encontrado"); } }

Prácticas previas

123

Código del botón Eliminar. Para eliminar es necesario que se haya buscado primero el registro. Para eso utilizamos la variable miembro m_cargadoRegistro. Si es verdadera podremos eliminar el registro. Si es falsa mostraremos en las cajas de texto un mensaje de error: void CProyecto3View::OnBotEliminar() { //si hemos cargado anteriormente un registro podemos eliminarlo if (m_cargadoRegistro) { m_pSet->Delete(); SetDlgItemText(IDC_EDITNOMBRE,"Eliminado"); SetDlgItemText(IDC_EDITDIRECCION,"Eliminado"); SetDlgItemText(IDC_EDITTELEFONO,"Eliminado"); SetDlgItemText(IDC_EDITCEDULA,"Eliminado"); } else { SetDlgItemText(IDC_EDITNOMBRE,"No cargado"); SetDlgItemText(IDC_EDITDIRECCION,"No cargado"); SetDlgItemText(IDC_EDITTELEFONO,"No cargado"); SetDlgItemText(IDC_EDITCEDULA,"No cargado"); } } Código del Botón Insertar: void CProyecto3View::OnBotInsertar() { m_pSet->GetDefaultConnect(); //Creamos un nuevo registro de la base de datos en blanco m_pSet->AddNew(); //supongo libre de errores UpdateData(true); //introducimos en las variables los campos de la caja de texto m_pSet->m_Direccion=m_sInsertarDireccion; m_pSet->m_Nombre=m_sInsertarNombre; m_pSet->m_DNI=atoi(m_sInsertarCedula); m_pSet->m_Telefono=atoi(m_sInsertarTelefono); int numeroDni=atoi(m_sInsertarCedula); int numeroTelf=atoi(m_sInsertarTelefono); //La función atoi pasa un strin a un entero //si ha habido error en la conversión retorna un 0 //de modo que si ha habido un error entra en este if if (numeroDni==0 || numeroTelf==0) { m_sInsertarNombre="ERROR FORMATO DATOS";


124

m_sInsertarDireccion="ERROR FORMATO DATOS"; m_sInsertarCedula="ERROR FORMATO DATOS"; m_sInsertarTelefono="ERROR FORMATO DATOS"; UpdateData(false); } else //sino actualiza la base de datos { try{ int resultadoActualizacion= m_pSet->Update(); m_sInsertarNombre="OK"; m_sInsertarDireccion="OK"; m_sInsertarCedula="OK"; m_sInsertarTelefono="OK"; UpdateData(false); } catch (CDBException){ UpdateData(false); } } }

4.7 Proyectos de bases de datos En esta práctica se pretende fomentar el interés por la investigación de los estudiantes, mediante la implementación de sistemas completos de bases de datos. Las propuestas sin embargo no tienen que ser demasiado largas, recordemos que se cuenta con un estimado de unas 11 semanas para desarrollar estos proyectos.

Todos los sistemas que sean propuestos por los estudiantes están limitados a atacar bases de datos PostgreSQL, las interfaces pueden diseñarlas haciendo uso de cualquier entorno de diseño de interfases. Se le recomendará al estudiante probar con el entorno de Visual Basic o con Visual C++.

Cada proyecto puede estar compuesto por un máximo de tres estudiantes,

los cuales tendrán que defender de forma individual el trabajo que han hecho. Aquellos trabajos que estén terminados antes de la fecha propuesta (examen final teórico de la asignatura) podrán defenderse previo acuerdo con el docente.

La coordinación de los trabajos se realizará en horas de tutoría, utilizando

medios electrónicos de mensajería y consultas cortas en el laboratorio. El objetivo de esta coordinación es que el docente lleve un seguimiento de los avances parciales del estudiante.

Capítulo 5 : Bibliografía

Bibliografía

126

Bibliografía complementaria • Concepts in Data structures / software development. Schneider Bruell. West. • Data Base Design. Wieder Hold. McGraw Hill. • Data structures. Smith. McGraw Hill. • Data structures and algorithms. Aho/ Cropfot/ Ullman. Addison Wesley. • Enciclopedia de Visual Basic. Fco. Javier Ceballos. Rama. • Programación Avanzada con Visual Basic 6.0. Fco. Balena. McGrawHill. • Visual C++ 6. Fco. Javier Caballos. Rama.

tesis de maestría en computación

Documents