Basededatosavanzadav 3

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

Programa Ingeniería de sistemas
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
Guía de componente práctico
3011
301125
25 - BASE
BASES
S DE DATO
DATOS
S AVAN
AVANZA
ZADA
DAS
S
Curso Electivo
ANÍVAR CHAVES TORRES

(Director Nacional)
JAVIER JIMENEZ
(Acreditador)
San Juan de Pasto

7 de feb
febrero
rero de 2012
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
La primera versión de este documento fue escrita por el ingeniero Rogelio Vásquez
Bernal, posteriormente ha sido actualizado por otros profesionales, docentes de la
UNAD, cuyos nombres no fueron registrados. Esta versión del documento ha sido
editada por Anívar Chaves Torres.
Este documento fue preparado para estudiantes de Ingeniería de sistemas de la Unad y

se acoge a la licencia Creative Commons 3.0. En consecuencia, se permite su uso con
fines académicos, siempre que se reconozca el crédito al autor. Se prohíbe la
reproducción, por cualquier medio, con fines comerciales.
Los ejemplos y ejercicios han sido diseñados exclusivamente con fines didácticos, el
autor, el editor y la universidad no asumen ninguna responsabilidad por la aplicación de
los mismos en con propósitos diferentes a la comprensión de los temas de este curso.
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
CONTENIDO
Número de créditos y dedicación horaria ...............

..............................
...................................
.......................................
...............................
............ 6
Protocolo..............
.............................
...................................
.......................................
...................................
...................................
...................................
.................................
................. 7
Introducción general al curso ..............

..............................
...................................
......................................
...................................
...............................
............... 14
Unidad I. Bases de datos distribuidas ...............

..............................
...................................
.......................................
...................................
................ 15
Capitulo 1. Conceptos básicos de bases de datos .........

...................
....................
.................
.................
....................
.............
... 15
Lección 1. Modelo entidad relación ..............

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

....................
...................
.................
.................
..................18
.........18
Lección 3. Álgebra relacional ...............

..............................
...................................
.......................................
...................................
......................
...... 28
Lección 5. Transacciones ...............

...............................
...................................
......................................
...................................
............................
............ 39
Capítulo 2. Diseño de bases de datos distribuidas .........

...................
....................
.................
.................
....................
.............
... 50
Lección 6. Bases de datos distribuidas ...............

...............................
...................................
.......................................
........................
.... 50
Lección 7. Bases de datos distribuidas ...............

...............................
...................................
.......................................
........................
.... 55
Lección 8. Fragmentación ...............

...............................
...................................
......................................
...................................
............................
............ 59
Lección 9. Tipos de fragmentación de datos ...................

.............................
.................
.................
....................
..................
.......... 64
Lección 10. Diseño de replica ..............

..............................
...................................
......................................
...................................
......................
...... 68
Capitulo 3. Consultas ...............

...............................
...................................
......................................
...................................
...................................
........................
..... 70
Lección 11. Consultas distribuidas ...............

..............................
...................................
.......................................
................................
............. 70
Lección 12. Descomposición

Descomposición de una consulta y localización
localización de datos distribuidos 74
Lección 13.
13. Transacciones
Transacciones Distribuidas
Distribuidas ...............
..............................
..................................
.......................................
........................
.... 76
Lección 14. Consistencia

Consistencia de la base de datos interna.
interna. .........
...................
...................
.................
.................
............
... 84
Lección 15. Catálogo ..............

..............................
...................................
......................................
...................................
...................................
................... 101
Unidad 2. Bodegas de datos ...............

...............................
...................................
......................................
...................................
.............................
............. 106
Capítulo 4. Diseño de bodegas de datos ..............

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

(SABD-OO) ....................................................................................................................... 134
Lección 35. El sistema Postgres ................................................................................... 135
Capitulo 8. Lenguaje de Modelado Unificado UML ........................................................136

Lección 36. Introducción ................................................................................................. 136
Lección 37. ¿Método o Lenguaje de Modelado? ........................................................138
Lección 38. Una perspectiva de UML ........................................................................... 140
Lección 39. Diagramas de Secuencia .......................................................................... 145
Lección 40. Diagramas de Colaboración ...................................................................... 147
Capítulo 9. Modelado con UML ......................................................................................... 148
Lección 41. Modelando el comportamiento de las Clases con Diagramas de Estado

............................................................................................................................................ 148
Lección 42. Diagramas de Actividad ............................................................................. 150
Lección 43. Modelando Componentes de Software ...................................................152
Lección 44. Modelando la Distribución y la Implementación ..................................... 153
Lección 45. Diseño de Bases de Datos Relacionales -- Una extensión informal de

UML .................................................................................................................................... 154
Número de créditos y dedicación horaria
El curso de Bases de datos avanzada está configurado como curso de 3 créditos.

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

argumentativos, apoyados por las relaciones interpersonales.
Contextual: Capacidad de ubicar el conocimiento en el contexto científico, político,

cultural, tecnológico, social y en el plano nacional e internacional, así como la
disposición y capacidad para aplicarlo en procesos de transformación que inciden en la
calidad de vida de la población.
Valorativa: Capacidad de apropiarse de valores como el respeto a la vida y a las ideas

de los demás; la dignidad humana, la convivencia, la solidaridad, la tolerancia y la
libertad que orientan las acciones del individuo como persona, como ser social y como
profesional.
El curso busca que el estudiante reconoce las diferentes áreas de aplicación de las
bases de datos, diseñando y construyendo soluciones eficientes que permiten apoyar
los procesos de toma de decisiones en la empresa.
Unidades didácticas
Repaso
Conceptos Bases de datos. Este tema incluye, Modelo Entidad Relación, normalización
de datos y SQL.
Unidad I.
Bases de datos distribuidas, que son, modelo de datos Entidad Relación, fragmentación
y replicación, transacciones, consultas y catalogo distribuido.
Unidad II.
Bodegas de datos, que son, modelo relacional, modelo copo de nieve. Carga de datos
y minería de datos.
Unidad III
Bases de datos orientadas a objeto. Objetos, propiedades, diseño de objetos UML,

SQL.
Estructura del curso
Contexto teórico
El curso de bases de datos avanzada, se ha pensado como un curso electivo que

quiere fortalecer los temas vistos en el curso básico.
Se intenta mostrar el sustento teórico en los sistemas de bases de datos distribuidos,

sistema que hoy retoma importancia por los desarrollos en los medios de comunicación
que han reactivado ese tipo de proyectos.
De otro lado, hoy en día los sistemas de bodegas de datos tienen un espacio claro en
la empresa, para permitir, al revisar la historia, crear el concepto de fidelidad y
conocimiento de los gustos del cliente para ofrecer mejores servicios.
De otro lado, la idea de objetos y como los sistemas de bases de datos los utilizan, es
importante por el auge que ha tomado este tipo de sistemas.
Metodología
Con el propósito de dar cumplimiento a las intencionalidades formativas del curso, es

importante que se planifique de manera responsable el proceso de aprendizaje
teniendo en cuenta las características de la metodología de educación a distancia, por

tal razón, este proceso se puede estructurar mediante las siguientes fases:
Reconocimiento: Mediante esta etapa se pretende reconocer los conocimientos

previos del estudiante, por lo tanto la función didáctica consiste en crear actividades
mediante las cuales se identifican los propósitos del curso, sus intencionalidades y se
presenta el desarrollo del curso. Esta fase puede desarrollarse de manera individual a
través del estudio del protocolo del curso, el modulo y las fuentes documentales
suministradas por el tutor y a través de actividades grupales desarrolladas por el tutor.
Profundización: Teniendo en cuenta que esta se refiere al conjunto de actividades

previamente planificadas conducentes al dominio de conceptos y competencias de
ordenes diferentes, se han definido los siguientes propósitos de formación:
 Trabajo personal: desarrolladas por el estudiante, a través de: estudio del

material sugerido en el curso académico, consulta de fuentes documentales
(bibliografía de documentos impresos en papel: libros y revistas; bibliografía de
documentos situados en Internet; direcciones de sitios Web de información
especializada y bibliotecas)
 Trabajo en grupo: desarrolladas por estudiantes a través de pequeños grupos

colaborativos de carácter obligatorio, con el propósito de: socialización del
trabajo personal, desarrollo de actividades en equipo, elaboración de informes,
de acuerdo con las actividades programadas en la guía didáctica.
 Tutoría en grupo de curso: teniendo en cuenta las inquietudes presentadas por

el estudiante a partir del trabajo personal y del trabajo en grupo, el tutor estará
dispuesto a resolver las consultas mediante la valoración de informes y el
intercambio de conocimientos en el tratamiento de las temáticas propuestas.
 Tutoría individual: entendida como el acompañamiento que el tutor debe ofrecer

al estudiante mediante el uso de las tecnologías de información y la
comunicación, tales como: correo electrónico, salas de conversación, foros de
discusión, el teléfono y Chat; también se puede complementar con encuentros
presenciales.
Transferencia: todo conocimiento, habilidad, destreza o competencias puede permitir

la transferencia de situaciones conocidas a situaciones desconocidas; por lo tanto
en esta fase requiere que tomando como referencia las fases de reconocimiento y
profundización que se elaboren ensayos, evaluaciones, mapas conceptuales y
talleres de aplicación en las diferente fases del curso académico.
Sistema de evaluación
Los procesos de evaluación del aprendizaje estarán correlacionados y articulados de

manera necesaria al principio de autonomía y generaran en el estudiante competencias
para la realización de procesos de auto evaluación, coevaluación y heteroevaluación. A
continuación se indica cada uno de estos procesos:
Autoevaluación: Es aquella que realiza el mismo estudiante, donde a medida que va

estudiando, se va planteando preguntas que el mismo las resuelve. De esta forma el
estudiante hace su propio seguimiento, identificando avances y dificultades, lo que
hace el proceso de autoaprendizaje muy dinámico y participativo. Este tipo de
evaluación NO tiene ponderación en la valoración del curso, solo es una forma de
identificar fortalezas, oportunidades, debilidades y amenazas en el proceso de
aprendizaje.
Coevaluación: Cuando el estudiante realiza estudio en grupo colaborativo, los

compañeros pueden valorar los avances, por medio de la Coevaluación, en ésta los
compañeros se evalúan entre sí, con el fin de identificar los avances y detectar
debilidades y fortalezas en el desarrollo de los temas que se están estudiando. La
Coevaluación es un espacio para desarrollar habilidades comunicativas y NO tiene
ponderación en la valoración del curso.
Heteroevaluación: Es aquella preparada por el Tutor o por el Docente Titular del

Curso, para hacer el seguimiento al rendimiento académico de los estudiantes, se
puede realizar por medio de parciales, quices, revisión de informes, trabajos,
portafolios, evaluación nacional y otros. Este estilo de evaluación es la utilizada por la
UNAD para determinar la aprobación o no del curso académico.
El sistema de evaluación tendrá como referente las diversas fases de aprendizaje:
Reconocimiento, Profundización y Transferencia, las cuales se valoraran de la siguiente

forma:
Fase de reconocimiento: diez por ciento (10%)
Fase de profundización: treinta por ciento (30%)
Fase de transferencia: veinte por ciento (20%)
Examen nacional: cuarenta por ciento (40%).

Introducción general al curso

“Un sistema de base de datos es básicamente un sistema computarizado para llevar
registros”1
El modulo base de datos avanzada tiene como propósito fundamental profundizar

algunos temas tratados en base de datos básica y presentar un esquema nuevo para
un nivel más avanzado.
Los temas aquí tratados requieren de un buen conocimiento de bases de datos y un

gran deseo por profundizar cada uno de ellos en la bibliografía y cibergrafía
recomendada.
Los estudiantes deben trabajar el modulo acompañado de la guía de actividades y del

protocolo académico para lograr así el propósito del curso académico.
1
C.J. DATE. Introducción a los sistemas de bases de datos
Unidad I. Bases de datos distribuidas

Capitulo 1. Conceptos básicos de bases de datos
Lección 1. Modelo entidad relación
Es una técnica para definir las necesidades de información de una organización. El

modelo entidad relación en su forma más simple implica identificar asuntos importantes
dentro de la organización (entidades) , propiedades de esos asuntos (atributos) y como
se relacional entre si (relación). Esto tiene valor solamente dentro del contexto de lo
que se realiza en la empresa y en la forma de actuar de estas funciones de gestión
sobre el modelo de información.
1.1. Objetivos del modelo entidad relación
Proporcionar un modelo preciso de las necesidades de información de la organización.
Proporcionar un modelo independiente de cualquier almacenamiento de datos y

método de acceso, que permita tomar decisiones de las técnicas de implementación y
coexistencia con sistemas antiguos.
1.2. Importancia del modelo entidad relación
Ofrece un medio efectivo y preciso de especificar y controlar la definición de las

necesidades de información. A continuación se indican diez temas clave que se
necesitan tener en cuenta cuando se utiliza el modelo:
 Dato: un recurso clave
Hoy en día un dato, como recurso, se acepta por ser importante para la evolución
satisfactoria de la organización como lo son los recursos financieros, humanos y físicos.
 Compromiso con la dirección
La dirección debe confirmar los requisitos de información. No importa lo

inteligente que usted resulte al modelar, tendrá un éxito limitado sin el
compromiso de la dirección.
 Convenciones
En todo momento se deben aplicar convenciones rigurosas, estándares y

directrices, incluyendo los conceptos de normalización de datos.
 Definición mínima
Se debería definir o modelar cualquier información o concepto de datos sólo de

una forma, y a continuación configurar asociaciones para los objetos
relacionados. Como por ejemplo, se debería definir una vez una cosa
denominada “Pedido de compra” y a continuación relacionarlo con el
departamento, los productos, las funciones de autorización y así
sucesivamente, como se requiera.
 Independencia de los datos
Se deben definir los requisitos de información de forma que sean

independientes de cualquier almacenamiento final o método de acceso y que
nos permita tener una visión creativa y objetiva de la empresa y del diseño
subsiguiente.
 Patrones genéricos
Deberían buscarse patrones genéricos de datos para permitir a los usuarios

utilizarlos en su gestión, además de tener la oportunidad de perfeccionar la
forma de procesar sus datos y de sugerir estructuras más rentables y flexibles
para los diseñadores de bases de datos.
 Actitud y calidad
Los modelizadores deben comenzar aplicar las convenciones automáticas y

velozmente, pero sin sacrificar el rigor. También debe aprovechar cualquier
oportunidad con los usuarios para mejorar la precisión de los modelos.
 Comunicación
Debe haber comunicación con los usuarios finales, en términos que ellos
puedan entender aunque debe seguir siendo técnicamente riguroso. Estas
técnicas de modelización se han utilizado durante muchos años para ayudar a
altos ejecutivos, directores y a otros a comprender su gestión. Es esencial
utilizar un lenguaje claro, sin abreviaturas, para lograr su comprensión. Con un
usuario final no deberíamos utilizar la palabra entidad.
 Relevancia
Los requisitos de información solamente pueden tener valor si aportan las

necesidades funcionales de la organización, dentro del marco de trabajo de los
objetivos y propósitos de la empresa.
 Un medio, no un fin
Aunque el modelo entidad relación es muy potente, ofrecer una idea increíble
de la compañía y actuar como un marco de trabajo para el diseño de los datos,
solo es una técnica intermedia, aunque desde luego importante.
Autoevaluación
Una de las ventajas del modelo Entidad Relación es:
Es un modelo de datos estándar que organiza la información del sistema.
Es un modelo de datos que indica como se almancena la información en los discos
Es un modelo de datos donde cada persona define su estandar para identificar los
elementos del modelo
Es un modelo que se implementa directamente en el computador
Lección 2. Elementos del Modelo entidad relación
El modelo entidad relación para ser funcional requiere de la definición de unos

elementos, los cuales se precisan a continuación:
Entidad
Se define como entidad a cualquier objeto real o abstracto, que existe en un contexto
determinado o puede llegar a existir y del cual deseamos guardar información.
Representación de entidad: Una entidad se representa en forma de diagrama con un

recuadro y en su interior un nombre. El nombre se muestra en singular y con letras
mayúsculas (figura 1).
Figura1. Representación de entidad
Reglas para definir una entidad: Cualquier objeto sólo puede ser representado por
una entidad. Es decir las entidades son mutuamente exclusivas en todos los casos.
Cada entidad debe ser identificada en forma única. Es decir, cada instancia (aparición)
de una entidad debe encontrarse separada e identificable claramente de todas las
demás instancias de ese tipo de entidad.
Relación
Se entiende por relación a la asociación, vinculación o correspondencia entre

entidades. Por ejemplo entre la entidad PROFESOR y la entidad CURSO podemos
establecer la relación IMPARTE porque el profesor imparte cursos.
Una relación es binaria en el sentido de que es siempre una asociación entre

exactamente dos entidades, o entre una entidad y ella misma. Cada relación tiene dos
extremos, para cada uno de los cuales tiene un:
 Nombre
 Grado / cardinalidad (cuantos)
 Opcionalidad (opcional u obligatorio).
Estas propiedades se utilizan para describir la asociación desde un extremo; se deben

definir ambos extremos.
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
Segunda forma normal: [2NF]
Eliminar atributos dependientes sólo en parte del identificador único.
Si una entidad tiene un identificador único compuesto de más de un atributo y/o

relación, y si otro atributo depende sólo de parte de este identificador compuesto,
entonces el atributo, y la parte del identificador del que depende, deberán formar la
base de una nueva entidad. La entidad nueva se identifica por la parte emigrada del
identificador único de la entidad original, y tiene una relación de uno a muchos unido a
la entidad original.
Tercera forma normal: [3NF]
Eliminar los atributos dependientes de atributos que no son parte del identificador
único.
Si un atributo de una entidad es dependiente de otro atributo, que no es parte del

identificador único, entonces estos atributos deberían formar la base de la nueva
entidad, que tenga una relación de uno a muchos con la entidad original. El
identificador único de la entidad nueva es el atributo del que depende el otro atributo. A
continuación se presenta la representación de esta forma:
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
Figura 16. Segunda y tercera forma normal

normal
En general, “una relación R está en la tercera forma normal (3NF) si y sólo si en

cualquier momento cada tupla (línea relacional) de R se compone de un valor clave
primario que identifica
identifica alguna identidad,
identidad, junto con
con un grupo de cero o más
más valores
independientes mutuamente que describen esa entidad de alguna manera” 3
Además, “una relación R está en la cuarta forma normal (4NF) si y únicamente si

donde quiera que haya una dependencia multivalores (MVD) en R, digamos A
todos los atributos de R son también funcionalmente dependientes de A. En otras
palabras, las únicas dependencias (funcionales o multivalores) en R son de la forma K
multivalores) son de verdad dependencia

dependenciass funcionales
funcionales (FD).
3
Date, C.J. An Introduction
Introduction to Database System, 4ed. 1986. Adisson-Wesley Publishing Co
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
También, “una relación R está en quinta forma normal (5NF), también denominada
forma normal de unión de protección (PJ/PN), si y únicamente si cada dependencia de
unión en R es una consecuencia de las claves candidatas de R.”
Desnormalización de datos
La desnormalización de datos es el procedimiento inverso, llevado a cabo puramente

por razones de mejorar la realización de sistemas de producción, particularmente
cuando están computa
computarizados.
rizados. La desnormalizaci
desnormalización
ón sólo se debe realizar
realizar sobre el
diseño. No poner en peligro nunca el modelo de gestión .
La desnormalización en formas manuales de procedimientos es necesariamente muy

común, como queda evidenciado por el hecho de que la mayor parte de los formularios
en papel mantienen grandes datos de referencias. Todos conocemos los problemas
que se pueden originar cuando ese dato se cambia y se tiene que volver a emitir el
grupo entero de formularios.
Autoevaluación
Una Base de datos que no esté en 3FN
Tiene problemas a nivel de inserción y borrado de datos
Tiene problemas al generar el backup
Tiene problemas a nivel de generación de roles
Tiene problemas de identidad
Lección 5. Transacciones
Una transacción es una unidad de la ejecución de un programa que accede y

posiblemente actualiza varios elementos de datos. Se delimita dependiendo del
lenguaje por las sentencias inicio transacción y fin transacción y se compone de todas
las instrucciones que se encuentran entre estos dos delimitadores.
Propiedades de la transacción
Para asegurar la consistencia de los datos se necesita que el sistema de base de datos
tengan las propiedades llamadas ACID: (Atomicity, Consistency, Isolation, Durability -
Atomicidad, Consistencia, Aislamiento, Durabilidad [Silberschatz97]). A continuación
explicamos cada una de estas propiedades:
Asegura que o bien todos los efectos de la transacción se reflejan en la base de datos,
o bien ninguno de ellos; un fallo no puede dejar a la base de datos en un estado en el
cual una transacción se haya ejecutado parcialmente.
ia:
Asegura que si la base de datos es consistente inicialmente, la ejecución de la

transacción deja la base de datos en un estado consistente.
Asegura que en la ejecución concurrente de transacciones, estas están aisladas unas

de otras, de tal manera que cada una tiene la impresión de que ninguna otra
transacción se ejecuta concurrentemente con ella.
Asegura que una vez que la transacción se ha comprometido, las actualizaciones

hechas por la transacción no se pierden, incluso si hay un fallo en el sistema.
Una transacción que termina con éxito se dice que está comprometida (commited), una
transacción que haya sido comprometida llevará a la base de datos a un nuevo estado
consistente que debe permanecer incluso si hay un fallo en el sistema. En cualquier
momento una transacción sólo puede estar en uno de los siguientes estados:
ejecución.
transacción.
cución normal.
base de datos a su estado anterior al comienzo de la transacción.
Cuando varias transacciones se ejecutan concurrentemente, existe la posibilidad de

que se pierda la consistencia de datos. Se hace necesario por lo tanto un sistema que
controle la interacción entre las transacciones concurrentes. Puesto que una
transacción por definición conserva la consistencia, una ejecución lineal de
transacciones la garantiza también. Un sistema que asegure esta propiedad se dice
que asegura la secuencialidad.
Concurrencia
Existen varios esquemas de control de concurrencia que aseguran la secuencialidad,

todos estos esquemas o bien retrasan una operación o bien abortan la transacción que
ha realizado la operación. Los más conocidos son los protocolos de bloqueo, el
esquema de ordenación por marcas temporales, las técnicas de validación, el esquema
de granularidad múltiple y los esquemas multiversión.
Un protocolo de bloqueo es un conjunto de reglas que indican el momento en que una

transacción puede bloquear o desbloquear un objeto de la base de datos. El protocolo
de bloqueo de dos fases permite que una transacción bloquee un objeto sólo después
de que haya desbloqueado otro objeto distinto, este método asegura la secuencialidad.
El esquema de ordenación por marcas temporales asegura la secuencialidad

seleccionando previamente un orden en todo par de transacciones. Existen 2 formas de
implementar este esquema, uno es por medio de valores timestamp (dependientes del
reloj del sistema) y por medio de un contador lógico que se incrementa cada vez que
asigna una nueva marca temporal. Este protocolo asegura la secuencialidad en cuanto
a conflictos y la ausencia de interbloqueos, si una de las transacciones viola la norma la
transacción se retrasa y se le asigna una nueva marca temporal. Por ejemplo, una
operación leer se puede retrasar porque todavía no se ha escrito el valor apropiado o
incluso rechazar si ha sobrescrito el valor que supuestamente se iba a leer.
Un esquema de validación es un método de control de concurrencia adecuado para

transacciones de sólo lectura y en las cuales la tasa de conflictos es baja. Se basa en
dividir una transacción en 3 etapas (lectura, validación y escritura) y trabajar con el
esquema de marcas temporales sobre la etapa de validación. De esta manera se quita

una sobrecarga en la etapa de lectura, en la cual no se necesita un esquema de control
de concurrencia dado que toda lectura lleva a la base de datos al mismo estado de
consistencia.
Una manera distinta manejar la concurrencia es por medio de la granularidad, este

concepto permite agrupar varios elementos de datos y definirlos como un todo para
efectos de sincronización. Se define como una jerarquía de distintos niveles, donde el
nivel superior puede representar toda la base de datos, se esquematiza como
estructura de árbol donde los nodos hijos de un nodo interno representan las
dependencias de datos asociadas. Se utilizan los tipos de bloqueos Compartidos y
Exclusivos más un nuevo tipo de bloqueo llamado el bloqueo intencional, el cual indica
que existen nodos descendientes que tienen bloqueos compartidos o exclusivos.
El esquema multiversión se basa en la creación de nuevas versiones de los elementos

de datos cada vez que una transacción vaya a escribir dicho elemento. Cuando se va a
realizar una escritura el sistema elige una de las versiones para que se lea. El esquema
de control de versiones garantiza que la versión que se va a leer se elige de forma que
asegure la secuencialidad por medio de marcas temporales. En este esquema una
operación de lectura tiene éxito siempre, sin embargo, una operación de escritura
puede provocar el retroceso de una transacción.
Un sistema está en estado de interbloqueo si existe un conjunto de transacciones tal

que toda transacción del conjunto está esperando a otra transacción del conjunto. En
tal situación, ninguna de las transacciones puede progresar. Existen 2 métodos para
tratar los interbloqueos y ambos provocan un retroceso de las transacciones, la
diferencia radica en que uno es preventivo y otro curativo. El protocolo de prevención
de interbloqueos asegura que el sistema nunca llegará a un estado de interbloqueos
mientras que el método de detección y de interbloqueos permite que el sistema llegue a
un estado de interbloqueos para luego tratar de recuperarse. La prevención se usa
normalmente cuando la probabilidad de que el sistema llegue a un estado de
interbloqueo es relativamente alta, de lo contrario lo más conveniente es usar la
detección y recuperación.
Seguridad y recuperación de datos
Los fallos que ocurren en un computador pueden darse por diferentes motivos (fallos de
disco, cortes de energía o fallos en el software). En cada uno de estos casos puede
perderse información concerniente a la base de datos. Existen varios tipos de fallas, a
considerar:
Con el fin de seleccionar la mejor estrategia para la recuperación de datos el

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

1985.
DATE, C. J, Introducción a los sistemas de bases de datos. Ed. Prentice Hall. Séptima
edición.
SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGraw-

Hill. Cuarta edición
OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill
www.lsi.us.es/docencia/asignaturas/dbd.html
www.cieloprogramadores.com
Capítulo 2. Diseño de bases de datos distribuidas
Lección 6. Bases de datos distribuidas
Introducción y fundamentos de Base de Datos Distribuidas.
La cantidad de innovaciones tecnológicas que ha habido en los últimos años ha

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

Así, es común encontrar en la literatura un gran número de términos que se han usado
para identificarlo. Entre los términos más comunes que se utilizan para referirse al
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
En el diseño de la distribución de los datos, se deben de tomar en cuenta los siguientes

objetivos:
Procesamiento local. La distribución de los datos, para maximizar el procesamiento

local corresponde al principio simple de colocar los datos tan cerca como sea posible
de las aplicaciones
aplicaciones que los utilizan. Se puede realizar
realizar el diseño de la distribución de los
datos para maximizar el procesamiento local agregando el número de referencias
locales y remotas que le corresponden a cada fragmentación candidata y la localización
del fragmento, que de esta forma se seleccione la mejor solución de ellas.
Distribución de la carga de trabajo . La distribución de la carga de trabajo sobre los
sitios, es una característica importante de los sistemas de cómputo distribuidos. Esta
distribución de la carga se realiza para tomar ventaja de las diferentes características
(potenciales)
(potenciales) o utilizaciones
utilizaciones de las computadoras de cada sitio, y maximizar el grado de
ejecución de paralelismo de las aplicaciones. Sin embargo, la distribución de la carga
de trabajo podría afectar negativamente el procesamiento local deseado.
Costo de almacenamiento y disponibilidad . La distribución de la base de datos
refleja el costo y disponibilidad del almacenamiento en diferentes sitios. Para esto, es
posible tener sitios especializados en la red para el almacenamiento de datos. Sin
embargo el costo de almacenamiento de datos no es tan relevante si éste se compara
con el del CPU, I/O y costos de transmisión de las aplicaciones.
Enfoques al problema
problema de diseño de bases de datos distribuidas
distribuidas
Existen dos estrategias generales para abordar el problema de diseño de bases de

datos distribuidas:
El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado para
aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el análisis
de requerimientos para definir el diseño conceptual y las vistas de usuario. A partir de
ellas se define un esquema conceptual global y los esquemas externos necesarios. Se
prosigue con el diseño de la fragmentación
fragmentación de la base de datos, y de aquí se continúa
continúa
con la localización de los fragmentos en los sitios, creando las imágenes físicas. Esta
aproximación se completa ejecutando, en cada sitio, "el diseño físico" de los datos, que
se localizan en éste. En la Figura 21 se presenta un diagrama
diagrama con la estructura general
general
del enfoque top-down.
El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de bases
de datos existentes, generando con esto bases de datos distribuidas. En forma
resumida, el diseño bottom-up de una base de datos distribuida requiere de la selección
de un modelo de bases de datos común para describir el esquema global de la base de
datos. Esto se debe, a que es posible que se utilicen diferentes SMBD. Después se
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
hace la traducción de cada esquema local en el modelo de datos común y finalmente

se hace la integración del esquema local en un esquema global común.
Figura 21. El enfoque top-down para el diseño de bases de datos distribuidas .
El diseño de una base de datos distribuida, cualquiera

cualquiera sea el enfoque que se siga, debe
responder satisfactoriamente las siguientes preguntas:
¿Por qué hacer una fragmentación de datos?
¿Cómo realizar la fragmentación?
¿Qué tanto se debe fragmentar?
¿Cómo probar la validez de una fragmentación?
¿Cómo realizar el asignamiento de fragmentos?
¿Cómo considerar los requerimientos de la información?

Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
Autoevaluación
El diseño Top-Down, es mejor desarrollarlo cuando

El sistema de base de datos a trabajar es nuevo, comienza de cero
Ya existen bases de datos y hay que integrarlas en el sistema distribuido
La programación a utilizar es orientada a objeto
Se utiliza patrones de diseño
Lección 8. Fragmentación
Figura 22. El problema de fragmentación de relaciones.
El problema de fragmentación se refiere al particionamiento de la información para

distribuir cada parte a los diferentes sitios de la red, como se observa en la Figura 22.
Inmediatamente aparece la siguiente pregunta: ¿cuál es la unidad razonable de
distribución? Se puede considerar que una relación completa es lo adecuado ya que las
vistas de usuario son subconjuntos de las relaciones. Sin embargo, el uso completo de
relaciones no favorece las cuestiones de eficiencia sobre todo aquellas relacionadas
con el procesamiento de consultas.
La otra posibilidad es usar fragmentos de relaciones (sub-relaciones) lo cual favorece la

ejecución concurrente de varias transacciones que accesan porciones diferentes de
una relación. Sin embargo, el uso de sub-relaciones también presenta inconvenientes.
Por ejemplo, las vistas de usuario que no se pueden definir sobre un solo fragmento
necesitarán un procesamiento adicional a fin de localizar todos los fragmentos de una
vista. Aunado a esto, el control semántico de datos es mucho más complejo ya que, por
ejemplo, el manejo de llaves únicas requiere considerar todos los fragmentos en los
que se distribuyen todos los registros de la relación. En resumen, el objetivo de la
fragmentación es encontrar un nivel de particionamiento adecuado en el rango que va
desde tuplas o atributos hasta relaciones completas (ver Figura 23 ).
Ejemplo 1. Considere una relación J del ejemplo visto en la introducción del presente
capítulo.
J:
JNO JNOMBRE PRESUPUESTO LUGAR
J1 Instrumentación 150000 Guajira

J2 Desarrollo de bases de datos 135000 Cartagena
J3 CAD/CAM 250000 Medellín
J4 Mantenimiento 310000 Cartagena
J5 CAD/CAM 500000 Bogotá
La relación J se puede fragmentar horizontalmente produciendo los siguientes

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

produciendo los siguientes fragmentos:
J1: información acerca de presupuestos de proyectos
JNO PRESUPUESTO
J1 150000
J2 135000
J3 250000
J4 310000
J5 1500000
J2: información acerca de los nombres y ubicaciones de proyectos
JNO JNOMBRE LUGAR
J1 Instrumentación Guajira
J2 Desarrollo de bases de datos Cartagena
J3 CAD/CAM Medellín
J4 Mantenimiento Cartagena
J5 CAD/CAM Bogotá
Figura 23. El grado de fragmentación.
Correctitud de una fragmentación: Al realizar la fragmentación de una relación se

deben satisfacer las siguientes condiciones para garantizar la correctitud de la misma:
Condición de completitud. La descomposición de una relación R en los fragmentos R1,

R2, ..., Rn es completa si y solamente si cada elemento de datos en R se encuentra en
algún de los Ri.
Condición de Reconstrucción. Si la relación R se descompone en los fragmentos R1,

R2, ..., Rn, entonces debe existir algún operador relacional U , tal que,
R=U1 i <= n Ri
Condición de Fragmentos Disjuntos. Si la relación R se descompone en los fragmentos

R1, R2, ..., Rn, y el dato di está en Rj, entonces, no debe estar en ningún otro
fragmento Rk (k¹ j).
Alternativas sobre replicación para el asignamiento de fragmentos

La replicación de información es de utilidad para obtener un mejor rendimiento y para

ofrecer un mayor grado de confiabilidad (tolerancia a fallas). La replicación se complica
cuando es necesario hacer actualizaciones a las copias múltiples de un dato. Por tanto,
respecto a la replicación, en el asignamiento de fragmentos se tienen tres estrategias:
Como regla general se debe considerar que la replicación de fragmentos es de utilidad

cuando el número de consultas de solo lectura es (mucho) mayor que el número de
consultas para actualizaciones. En la Tabla 1 se comparan la complejidad de
implementar o tomar ventaja de las diferentes alternativas de replicación, respecto de
los diferentes aspectos importantes en bases de datos distribuidas.
Recopilación Recopilación Parcial Particionamiento

completa
Procesamiento de Fácil Moderado Moderado
Consultas
Manejo de Directorios Fácil o no existente Moderado Moderado
Control de Moderado Difícil Fácil
Concurrencia
Confiabilidad Muy alto Alto Bajo
Realidad Aplicación posible Realista Aplicación posible
Tabla 2. Comparación de las estrategias de replicación de fragmentos .
Requerimientos de información:
Con el fin de realizar una fragmentación adecuada es necesario proporcionar

información que ayude a realizarla. Esta información normalmente debe ser
proporcionada por el usuario y tiene que ver con cuatro tipos:
Autoevaluación
En términos generales, la fragmentación busca

Que la información se administre en el sitio donde ella pertenece
Que la información se administre en todos los sitios
Que la información se administre verticalmente
Que la información se administre horizontalmente
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
El coste de transmisión de datos en la red.
procesaran en paralelo partes de la consulta.
El coste relativo de la transferencia de datos en la red y la transferencia de datos entre

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

como ésta:
Puesto que depósito está definido como
La expresión que resulta del esquema de traducción de nombres es
Al emplear las

las técnicas de
de optimización
optimización podemos
podemos simplificar
simplificar de manera automáti
automática
ca esta
expresión. La expresión que resulta es
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
La cual incluye dos subexpresiones. La primera incluye sólo depósito1 y, por tanto,
puede ser calculada en la localidad de Riverside. La segunda incluye solamente
depósito2 y, por tanto, puede ser calculada en la localidad de Columbia.
Existe aún una optimización que se puede hacer así:
Puesto que depósito1 tiene solamente tuplas de pertenecientes a la sucursal Riverside,

podemos eliminar la operación de selección. Calculando
Podemos aplicar la definición del fragmento depósito2 para obtener
Esta expresión es el conjunto vacío,

vacío, independientemente
independientemente del contenido
contenido de la relación
depósito.
Así, nuestra estrategia

estrategia final para la localidad Riverside
Riverside consistirá en devolver
devolver depósito1
como resultado de la consulta.
Procesamiento de intersección simple
Un aspecto importante
importante de la elección de una estrategia
estrategia de procesamiento
procesamiento de consulta
es elegir una estrategia de intersección. Considere la expresión algebraica relacional:
Cliente |x| depósito |x| sucursal
Suponemos que ninguna de las tres relaciones esté repetida o fragmentada y que
cliente está almacenada en la localidad L c, de
depós
pósito
ito en
en la L d y sucursal en la L b. Sea Li
la localidad donde se originó la consulta. El sistema debe producir el resultado en la
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
localidad Li. Entre las posibles estrategias para procesar posibles estrategias para
procesar esta consulta se encuentran en las siguientes:
i. Escoger una estrategia para

procesar en forma local la consulta completa en L i.
d y calcular cliente |x|

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

paralelismo y la estrategia de semi-intersección.
Autoevaluación
Autoevaluación
La consulta de datos intenta reducir el costo de trasmisión
Verdadero Falso
Lección 12. Descomposición de una consulta y localización de datos

distribuidos
Antes de que pueda iniciarse el procesamiento de una consulta, el sistema debe

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

de datos puesto que la diferencia en tiempo de ejecución entre una buena estrategia y
una mala puede ser enorme. En el modelo de red y en el modelo jerárquico la
optimización de consultas se deja en su mayor parte al programador de aplicaciones.
Esto se debe a que las sentencias de los lenguajes de manipulación de datos de estos
dos modelos normalmente se incorporan en un lenguaje de programación principal, y

no es fácil transformar una consulta de red o jerárquica en una equivalente sin
conocimiento del programa de aplicación completo.
Ya que una consulta relacional puede expresarse completamente en un lenguaje de

consulta relacional sin emplear un lenguaje principal, es posible realizar
automáticamente una cantidad importante de optimización de consultas.
Algunos sistemas reducen el número de estrategias que necesitan ser completamente

consideradas haciendo una suposición heurística de una estrategia buena. Según esto,
el optimizador considera cada una de las posibles estrategias, pero acaba tan pronto
como determine que el coste es mayor que la mejor de las estrategias consideradas
anteriormente. Si el optimizador empieza con una estrategia que es probable que tenga
un coste bajo, sólo unas pocas estrategias competentes requerirán un análisis
completo del coste. Esto puede reducir el tiempo de optimización de consultas.
Para simplificar la tarea de selección de estrategias se debe dividir una consulta en

varias subconsultas. Esto no sólo simplifica la selección de estrategias sino que
también permite al optimizador de consultas reconocer los casos en los que una
subconsulta determinada aparezca varias veces en la misma consulta. Si esas
subconsultas se calculan una sola vez, se ahorra tiempo tanto en la fase de
optimización de la consulta como en la ejecución de la consulta. El reconocimiento de
subconsultas comunes es análogo al reconocimiento de subexpresiones comunes en
muchos compiladores optimizadores de lenguajes de programación.
Es obvio que examinar la consulta buscando subconsultas comunes y estimar el coste

de un gran número de estrategias supone un tiempo extra considerable en el
procesamiento de consultas. Sin embargo, el coste adicional de optimización de
consultas generalmente se compensa con creces por el ahorro en el tiempo de
ejecución de la consulta. El ahorro logrado es aún mayor en aquellas aplicaciones que
se ejecutan sobre una base regular y vuelven a ejecutar las mismas consultas en cada
ejecución. Por tanto, la mayor parte de los sistemas comerciales incluyen optimizadores
relativamente sofisticados.
Autoevaluación
Todo Sistema Manejador de Bases de Datos incluye optimizadores de consulta
Verdadero Falso
Lección 13. Transacciones Distribuidas
Hasta este momento, las primitivas básicas de acceso que se han considerado son las
consultas (queries). Sin embargo, no se ha discutido qué pasa cuando, por ejemplo,
dos consultas tratan de actualizar el mismo elemento de datos, o si ocurre una falla del
sistema durante la ejecución de una consulta. Dada la naturaleza de una consulta, de
lectura o actualización, a veces no se puede simplemente reactivar la ejecución de una
consulta, puesto que algunos datos pueden haber sido modificados antes la falla. El no
tomar en cuenta esos factores puede conducir a que la información en la base de datos
contenga datos incorrectos.
El concepto fundamental aquí es la noción de "ejecución consistente" o "procesamiento

confiable" asociada con el concepto de una consulta. El concepto de una transacción
es usado dentro del dominio de la base de datos como una unidad básica de cómputo
consistente y confiable.
Definición de una transacción
Una transacción es una colección de acciones que hacen transformaciones

consistentes de los estados de un sistema preservando la consistencia del sistema.
Una base de datos está en un estado consistente si obedece todas las restricciones de
integridad definidas sobre ella. Los cambios de estado ocurren debido a
actualizaciones, inserciones, y supresiones de información. Por supuesto, se quiere
asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin
embargo, durante la ejecución de una transacción, la base de datos puede estar
temporalmente en un estado inconsistente. El punto importante aquí es asegurar que la
base de datos regresa a un estado consistente al fin de la ejecución de una transacción
(Ver Figura 3.1)
Lo que se persigue con el manejo de transacciones es por un lado tener una

transparencia adecuada de las acciones concurrentes a una base de datos y por otro
lado tener una transparencia adecuada en el manejo de las fallas que se pueden
presentar en una base de datos.
Figura 24. Un modelo de transacción.
Ejemplo 1. Considere la siguiente consulta en SQL para incrementar el 10% del

presupuesto del proyecto CAD/CAM de la base de datos de ejemplo.
UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"
Esta consulta puede ser especificada, usando la notación de SQL, como una
transacción otorgándole un nombre:
Begin_transaction ACTUALIZA_PRESUPUESTO
begin
UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"
end.
Ejemplo 2. Considere una agencia de reservaciones para líneas aéreas con las
siguientes relaciones:
FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP )
CUST( CNAME, ADDR, BAL )
FC( FNO, DATE, CNAME, SPECIAL )
Una versión simplificada de una reservación típica puede ser implementada

mediante la siguiente transacción:
Begin_transaction Reservación
begin
input( flight_no, date, customer_name );
EXEC SQL UPDATE FLIGHT
SET STSOLD = STSOLD + 1
WHERE FNO = flight_no
AND DATE = date
EXEC SQL INSERT

INTO FC( FNAME, DATE, CNAME, SPECIAL )
VALUES (flight_no, date, customer_name, null )
output("reservación terminada");
end.
Condiciones de terminación de una transacción
Una transacción siempre termina, aun en la presencia de fallas. Si una transacción

termina de manera exitosa se dice que la transacción hace un commit (se usará el
término en inglés cuando no exista un término en español que refleje con brevedad el
sentido del término en inglés). Si la transacción se detiene sin terminar su tarea, se dice
que la transacción aborta. Cuando la transacción es abortada, su ejecución es detenida
y todas sus acciones ejecutadas hasta el momento son deshechas ( undone)
regresando a la base de datos al estado antes de su ejecución. A esta operación
también se le conoce como rollback .
Ejemplo 3. Considerando de nuevo el Ejemplo 3.2, veamos el caso cuando no

existen asientos disponibles para hacer la reservación.
begin
input( flight_no, date, customer_name );
INTO temp1, temp2
EXEC SQL SELECT STSOLD, CAP
FROM FLIGHT
WHERE FNO = flight_no AND DATE = date
if temp1 = temp2 then
output( "no hay asientos libres" )
Abort
else
EXEC SQL UPDATE FLIGHT
SET STSOLD = STSOLD + 1
WHERE FNO = flight_no AND DATE = date
EXEC SQL INSERT
INTO FC( FNAME, DATE, CNAME, SPECIAL )
VALUES (flight_no, date, customer_name, null )
Commit
output("reservación terminada");
endif
end.
Caracterización de transacciones
Observe que en el ejemplo anterior las transacciones leen y escriben datos. Estas
acciones se utilizan como base para caracterizar a las transacciones. Los elementos de
datos que lee una transacción se dice que constituyen el conjunto de lectura (RS).
Similarmente, los elementos de datos que una transacción escribe se les denomina el
Note que la relación de ordenamiento especifica el orden relativo de todas las

operaciones con respecto a la condición de terminación. Esto se debe a la tercera
condición de la definición de transacción. También note que no se define el
ordenamiento entre cualquier par de operaciones, esto es, debido a que se ha definido
un orden parcial.
Propiedades de las transacciones
La discusión en la sección previa clarifica el concepto de transacción. Sin embargo, aun

no se ha dado ninguna justificación para afirmar que las transacciones son unidades de
procesamiento consistentes y confiables. Las propiedades de una transacción son las
siguientes:
Atomicidad . Se refiere al hecho de que una transacción se trata como una unidad de
operación. Por lo tanto, o todas las acciones de la transacción se realizan o ninguna de
ellas se lleva a cabo. La atomicidad requiere que si una transacción se interrumpe por
una falla, sus resultados parciales deben ser deshechos. La actividad referente a
preservar la atomicidad de transacciones en presencia de abortos debido a errores de
entrada, sobrecarga del sistema o ínter bloqueos se le llama recuperación de
transacciones. La actividad de asegurar la atomicidad en presencia de caídas del
sistema se le llama recuperación de caídas.
Consistencia. La consistencia de una transacción es simplemente su correctitud. En

otras palabras, una transacción es un programa correcto que lleva la base de datos de
un estado consistente a otro con la misma característica. Debido a esto, las
transacciones no violan las restricciones de integridad de una base de datos.
Aislamiento. Una transacción en ejecución no puede revelar sus resultados a otras

transacciones concurrentes antes de su commit . Más aún, si varias transacciones se
ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se
hubieran ejecutado de manera secuencial (seriabilidad).
Durabilidad . Es la propiedad de las transacciones que asegura que una vez que una
transacción hace su commit , sus resultados son permanentes y no pueden ser
borrados de la base de datos. Por lo tanto, los DBMS aseguran que los resultados de
una transacción sobrevivirán a fallas del sistema. Esta propiedad motiva el aspecto de
recuperación de bases de datos, el cual trata sobre como recuperar la base de datos a
un estado consistente en donde todas las acciones que han hecho un commit queden
reflejadas.
En resumen, las transacciones proporcionan una ejecución atómica y confiable en

presencia de fallas, una ejecución correcta en presencia de accesos de usuario
múltiples y un manejo correcto de réplicas (en el caso de que se soporten).
Tipos de Transacciones
Las transacciones pueden pertenecer a varias clases. Aun cuando los problemas
fundamentales son los mismos para las diferentes clases, los algoritmos y técnicas que
se usan para tratarlas pueden ser considerablemente diferentes. Las transacciones

pueden ser agrupadas a lo largo de las siguientes dimensiones:
Áreas de aplicación. En primer lugar, las transacciones se pueden ejecutar en

aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les
conocen como transacciones distribuidas. Por otro lado, dado que los resultados de
una transacción que realiza un commit son durables, la única forma de deshacer los
efectos de una transacción con commit es mediante otra transacción. A este tipo de
transacciones se les conoce como transacciones compensatorias. Finalmente, en
ambientes heterogéneos se presentan transacciones heterogéneas sobre los datos.
Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que se inicia
una transacción hasta que se realiza un commit o se aborta, las transacciones pueden
ser de tipo batch o en línea. Estas se pueden diferencias también como transacciones
de corta y larga vida. Las transacciones en línea se caracterizan por tiempos de
respuesta muy cortos y por accesar una porción relativamente pequeña de la base de
datos. Por otro lado, las transacciones de tipo batch toman tiempos relativamente
largos y accesan grandes porciones de la base de datos.
Estructura. Considerando la estructura que puede tener una transacción se examinan

dos aspectos: si una transacción puede contener a su vez subtransacciones o el orden
de las acciones de lectura y escritura dentro de una transacción.
Estructura de transacciones
Las transacciones planas consisten de una secuencia de operaciones primitivas

encerradas entre las palabras clave begin y end. Por ejemplo,
...
end.
En las transacciones anidadas, las operaciones de una transacción pueden ser así
mismo transacciones. Por ejemplo,
...
Begin_transaction Vuelo
...
end. {Vuelo}
...
Begin_transaction Hotel
...
end.
...
end.
Una transacción anidada dentro de otra transacción conserva las mismas propiedades
que la de sus padres, esto implica, que puede contener así mismo transacciones dentro
de ella. Existen restricciones obvias en una transacción anidada: debe empezar
después que su padre y debe terminar antes que él. Más aún, el commit de una
subtransacción es condicional al commit de su padre, en otras palabras, si el padre de
una o varias transacciones aborta, las subtransacciones hijas también serán abortadas.
Las transacciones anidadas proporcionan un nivel más alto de concurrencia entre

transacciones. Ya que una transacción consiste de varias transacciones, es posible
tener más concurrencia dentro de una sola transacción. Así también, es posible
recuperarse de fallas de manera independiente de cada subtransacción. Esto limita el
daño a un parte más pequeña de la transacción, haciendo que costo de la recuperación
sea menor.
En el segundo punto de vista se considera el orden de las lecturas y escrituras. Si las

acciones de lectura y escritura pueden ser mezcladas sin ninguna restricción, entonces,
a este tipo de transacciones se les conoce como generales. En contraste, si se
restringe o impone que un dato deber ser leído antes de que pueda ser escrito
entonces se tendrá transacciones restringidas. Si las transacciones son restringidas a
que todas las acciones de lectura se realicen antes de las acciones de escritura
entonces se les conoce como de dos pasos. Finalmente, existe un modelo de acción
para transacciones restringidas en donde se aplica aún más la restricción de que cada
par <read,write> tiene que ser ejecutado de manera atómica.
Ejemplo 6. Los siguientes son algunos ejemplos de los modelos de transacción

mencionados antes.
General: T 1: { R ( x ), R (y ), W (y ), R (z ), W ( x ), W (z ), W (w ), C }
Dos pasos: T 2: { R ( x ), R (y ), R (z ), W ( x ), W (y ), W (z ), W (w ), C }
Restringida: T 3: { R ( x ), R (y ), W (y ), R (z ), W ( x ), W (z ), R (w ), W (w ), C }
Restringida y de dos pasos:
T 4: { R ( x ), R (y ), R (z ), R (w ), W (y ), W ( x ), W (z ), W (w ), C }
Acción: T 3: { [R ( x ), W ( x )], [R (y ), W (y )], [R (z ), W (z )], [R (w ), W (w )], C }
Note que cada par de acciones encerrado en [ ] se ejecuta de manera atómica
8. Aspectos relacionados al procesamiento de transacciones
Los siguientes son los aspectos más importantes relacionados con el procesamiento de
transacciones:
Modelo de estructura de transacciones. Es importante considerar si las transacciones

son planas o pueden estar anidadas.
Autoevaluación
Toda transacción exitosa hace Rollback
Verdadero Falso
Lección 14. Consistencia de la base de datos interna.
Los algoritmos de control de datos semántico tienen que satisfacer siempre las
restricciones de integridad cuando una transacción pretende hacer un commit.
Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios

de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y
durabilidad de las transacciones. Así también, se requieren protocolos para la
recuperación local y para efectuar los compromisos (commit) globales.
Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben

sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La
consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la

consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia
read-one-write-all (ROWA).
Incorporación del manejador de transacciones a la arquitectura de un SMBD
El monitor de ejecución distribuida consiste de dos módulos: El administrador de

transacciones (TM) y el despachador (SC). Como se puede apreciar en la Figura 25, el
administrador de transacciones es responsable de coordinar la ejecución en la base de
datos de las operaciones que realiza una aplicación. El despachador, por otra parte, es
responsable de implementar un algoritmo específico de control de concurrencia para
sincronizar los accesos a la base de datos.
Un tercer componente que participa en el manejo de transacciones distribuidas es el

administrador de recuperación local cuya función es implementar procedimientos
locales que le permitan a una base de datos local recuperarse a un estado consistente
después de una falla.
Figura 26. Ejecución centralizada de transacciones .
Figura 26b. Ejecución distribuida de transacciones .
Recuperación en Sistemas Distribuidos

Una transacción debe ejecutarse en forma atómica. Es decir, se ejecutan

completamente todas las instrucciones de la transacción, o no se ejecuta ninguna.
Además, en el caso de ejecución concurrente, el efecto de ejecutar una transacción
debe ser el mismo que si se ejecutara sola en el sistema.
Estructura del sistema.
Cuando se tiene un sistema de base de datos distribuido, es mucho más difícil

garantizar la propiedad de atomicidad de una transacción. Esto se debe a que es
posible que participen varias localidades en la ejecución de una transacción. El fallo de
una de estas localidades o el fallo de la línea de comunicación entre ellas, puede dar
como resultado un cálculo erróneo.
La función del gestor de transacciones de un sistema de base de datos distribuidos es

asegurar que la ejecución de las distintas transacciones. Los distintos gestores de
transacciones cooperan para ejecutar las transacciones globales. Para comprender
cómo puede estructurarse un gestor de este tipo, definiremos un modelo abstracto para
un sistema de transacciones.
Gestor de transacciones, cuya función es gestionar la ejecución de aquellas

transacciones (o subtransacciones) que accedan a datos almacenados en esa
localidad. Observamos que da transacción puede ser bien una transacción local
(es decir, que se ejecuta sólo en esa localidad), o parte de una transacción
global (es decir, que se ejecuta en varias localidades).
Coordinador de transacciones, cuya función es la de coordinar la ejecución de

varias transacciones (tanto local como global) iniciadas en esa localidad.
La estructura de un gestor de transacciones es similar en muchos aspectos a la que se

utiliza en el caso de un sistema centralizado. Cada gestor de transacciones se encarga
de:
ejecución en paralelo de las transacciones que se ejecuten en esa localidad.
Como su nombre lo indica, un coordinador de transacciones se encarga de coordinar

todas las transacciones que se inicien en esa localidad. Para cada una de estas
transacciones, el coordinador debe:
transacción.
las localidades apropiadas para su ejecución.

abordada en todas las localidades.
Robustez
Es una configuración distribuida es necesario prever otro tipo de fallos, como pueden
ser:
Por tanto, para que el sistema sea robusto, es necesario que detecte cualquiera de
estos fallos, que reconfigure el sistema de manera que pueda reanudarse el proceso y
que se recupere una vez que haya sido reparado el procesador o la línea de
comunicación afectados.
En general, no es posible distinguir entre los fallos en las líneas de comunicación de la

red y de las localidades. Por tanto, el esquema de reconfiguración que se adopte debe
estar diseñado para que funcione correctamente aun cuando la red quede fragmentada.
También es necesario tener cuidado al reintegrar al sistema una localidad o línea de

comunicación separada. Cuando una localidad que quedó fuera de servicio se
recupera, debe iniciar un procedimiento de actualización de sus tablas de sistema para
que reflejen los cambios que tuvieron lugar mientras estaba inactiva. Si la localidad
tenía copias de datos, debe obtener los valores actuales de todos ellos y asegurarse de
recibir las actualizaciones futuras. Esto es más complicado de lo que parece, ya que es
posible que se actualicen los datos que se están procesando mientras que el sistema
se recupera.
Es necesario representar a las tareas de recuperación como una seria de

transacciones. En este caso, el subsistema de control de concurrencia y el manejo de
transacciones puede encargarse de realizar de manera fiable la reintegración de la
localidad.
Si se recupera una línea de comunicación interrumpida, es posible que se unan de

nuevo dos fragmentos de la red. Dado que la fragmentación de una red limita las
operaciones que pueden permitirse en algunas localidades, o en todas ellas, es
conveniente enviar un mensaje a todas ellas informando sin delación que la línea se
recuperó.
Control de concurrencia
El control de concurrencia trata con los problemas de aislamiento y consistencia del

procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS
asegura que la consistencia de la base de datos se mantiene en un ambiente
distribuido multiusuario. Si las transacciones son internamente consistentes, la manera
más simple de lograr este objetivo es ejecutar cada transacción sola, una después de
otra. Sin embargo, esto puede afectar grandemente el desempeño de un DDBMS dado
que el nivel de concurrencia se reduce al mínimo. El nivel de concurrencia, el número
de transacciones activas, es probablemente el parámetro más importante en sistemas
distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar
un balance entre el mantenimiento de la consistencia de la base de datos y el
mantenimiento de un alto nivel de concurrencia.
Si no se hace un adecuado control de concurrencia, se pueden presentar dos

anomalías. En primer lugar, se pueden perder actualizaciones provocando que los
efectos de algunas transacciones no se reflejen en la base de datos. En segundo
término, pueden presentarse recuperaciones de información inconsistentes.
En este capítulo se hace la suposición de que el sistema distribuido es completamente

confiable y no experimente falla alguna.
Teoría de la seriabilidad
Una calendarización (schedule), también llamado una historia, se define sobre un

conjunto de transacciones T = { T 1, T 2, ..., Tn } y especifica un orden entrelazado de la
ejecución de las operaciones de las transacciones. La calendarización puede ser
especificada como un orden parcial sobre T .
Ejemplo 1. Considere las siguientes tres transacciones:
T 1: Read( x ) T 2: Write( x ) T 3: Read( x ) Write( x ) Write( y ) Read( y ) Commit
Read( z ) Read( z ) Commit Commit Una calendarización de las acciones de las tres
transacciones anteriores puede ser:
H 1 = { W 2( x ), R 1( x ), R 3( x ), W 1( x ), C 1, W 2(y ), R 3(y ), R 2(z ), C 2, R 3(z ), C 3 }
Dos operaciones Oij ( x ) y Okl ( x ) (i y k no necesariamente distintos) que accesan el

mismo dato de la base de datos x se dice que están en conflicto si al menos una de
ellas es una escritura. De esta manera, las operaciones de lectura no tienen conflictos
consigo mismas. Por tanto, existen dos tipos de conflictos read-write (o write-read ) y
write-write. Las dos operaciones en conflicto pueden pertenecer a la misma transacción
o a transacciones diferentes. En el último caso, se dice que las transacciones tienen
conflicto. De manera intuitiva, la existencia de un conflicto entre dos operaciones indica
que su orden de ejecución es importante. El orden de dos operaciones de lectura es

insignificante.
Una calendarización completa define el orden de ejecución de todas las operaciones en

su dominio. Formalmente, una calendarización completa STc definido sobre un
conjunto de transacciones T = { T 1, T 2, ..., Tn } es un orden parcial STc = { T , <T } en
donde
Sumatoria T = Ui i , para todos los i = 1, 2, ..., n
<T i <i , para todos los i = 1, 2, ..., n
Para cualesquiera dos operaciones en conflicto Oij y Okl T, ó Oij <T Okl ó
Okl <T Oij
La primera condición establece simplemente que el dominio de la calendarización es la

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

prefijo de un orden parcial se define como sigue. Dado un orden parcial
Las primeras dos condiciones definen a P ’ como una restricción de P en el dominio
en donde las relaciones de ordenamiento en P se mantienen por P ’. La última condición
indica que para cualquier elemento de
incluidos también en
Ejemplo 3. La siguiente calendarización es un prefijo de la calendarización del Ejemplo

2.
Si en una calendarización S, las operaciones de varias transacciones no están

entrelazadas, esto es, si las operaciones de una transacción ocurren de manera
consecutiva, entonces se dice que la calendarización es serial . Si cada transacción es
consistente (obedece las reglas de integridad), entonces la base de datos se garantiza
ser consistente al final de la calendarización serial. La historia asociada a este tipo de
calendarización se le conoce como serial.
Ejemplo 4. La siguiente es una historia serial para el Ejemplo 1.
HS = { W 2( x ), W 2(y ), R 2(z ), C 2, R 1( x ), W 1( x ), C 1, R 3( x ), R 3(y ), R 3(z ), C 3 }
Las transacciones se ejecutan de manera concurrente, pero el efecto neto de la historia

resultante sobre la base de datos es equivalente a alguna historia serial . Basada en la
relación de precedencia introducida por el orden parcial, es posible discutir la
equivalencia de diferentes calendarizaciones con respecto a sus efectos sobre la base
de datos.
Dos calendarizaciones, S1 y S2, definidas sobre el mismo conjunto de transacciones T ,
se dice que son equivalentes si para cada par de operaciones en conflicto Oij y Okl (i
k ), cada vez que Oij <1 Okl , entonces, Oij <2 Okl . A esta relación se le conoce como
equivalencia de conflictos puesto que define la equivalencia de dos calendarizaciones
en término del orden de ejecución relativo de las operaciones en conflicto en ellas.
Una calendarización S se dice que es serializable, si y solamente si, es equivalente por

conflictos a una calendarización serial.
Ejemplo 5. Las siguientes calendarizaciones no son equivalentes por conflicto:
H 1 = { W 2( x ), R 1( x ), R 3( x ), W 1( x ), C 1, W 2(y ), R 3(y ), R 2(z ), C 2, R 3(z ), C 3 }
Las siguientes calendarizaciones son equivalentes por conflictos; por lo tanto H 2 es
serializable:
H 2 = { W 2( x ), R 1( x ), W 1( x ), C 1, R 3( x ), W 2(y ), R 3(y ), R 2(z ), C 2, R 3(z ), C 3 }
Lección 17. Construcción y manejo de una bodega de datos
Si la organización tiene muchos datos de aplicaciones tradicionales y está buscando

una solución para transferir grandes volúmenes de datos de un Mainframe, se necesita
una solución de Bodega de Datos de fuerza industrial para hacer transferencia bruta de
datos diferentes de fuentes en Mainframes a Bodegas de Datos en DB2 o en Unix.
Se requiere de alguna herramienta para poblar y actualizar la Bodega de Datos que

realice extracción de datos a altas velocidades y altos volúmenes de datos, traslade y
distribuya de múltiples y diferentes Bases de Datos en Mainframes en la BODEGA y
ojalá elimine la necesidad de escribir complejos programas y rutinas de conversión.
Usualmente estas herramientas tienen habilidades gráficas y proveen de criterio de

selección fácilmente puede llevar los datos al formato requerido en la Base de Datos.
Por definición Bodega de Datos es una colección de datos actualizada, por lo tanto la
herramienta utilizada debe completar las actualizaciones en el momento.
Distribución de datos es el proceso de mover los datos extractados y trasladarlos a la

Bodega de Datos o a diferentes Bases de Datos en cualquier plataforma en cualquier
sitio. Una herramienta de distribución define Base de Datos Objetivo, información de
conversión y entrada y salida de datos. Una vez creadas estas definiciones, pueden ser
salvadas para ser reutilizadas, editadas o ejecutadas posteriormente.
Algunas soluciones de Bodega de Datos requieren de enrutadores de datos o rutinas

de sincronización mas sofisticadas a través de ambientes múltiples y heterogéneos.
Este tipo de proceso puede necesitar un movimiento vi direccional entre las plataformas
Mainframe y C/S para mantener actualizada y sincronizada la Base de Datos en todas
las localidades
Autoevaluación
Un sistema que facilite la minería de datos permite

Buscar tendencias y comportamientos
Buscar entidades
Buscar atributos
Buscar inconsistencias
Lección 18. Construcción del Data Warehouse.
Como todo proyecto informático, el proyecto de bodega de datos consta de los

siguientes pasos.
Planeación
La fase define la metodología a utilizar. Como se muestra en el modelo de bases de

datos avanzada, existe el enfoque Top-Down (De Arriba abajo), y Bottom-up (De abajo
a arriba) o una combinación de estas dos.
Todo proyecto de sistemas, requiere una metodología de desarrollo del producto. En
general, se usa el método de análisis y diseño estructurado y el método del desarrollo
en espiral.
Requerimientos
Especificación de lo que se desean lograr del data warehouse. Comenzando por la

vista de usuario, para que se quiere desarrollar la bodega. En el diseño, se puede
trabajar dos modelos diferentes, bodegas basadas en el Modelo Entidad Relación o
bodegas diseñadas con el modelo copo de nieve (snowflake).
En ambos casos, debe diseñarse las tablas que administran los datos del proceso que
se desea revisar (producción, ventas, compras), llamadas tablas de hecho y las tablas
que registran los elementos que pueden explicar ese hecho, denominadas dimensiones
o categorías (estrato, tiempo, categorías de los elementos, día en que se realizó la
transacción), elementos que históricamente, pueden determinar un comportamiento o
tendencia.
Análisis
Una vez definidos los requerimientos, se determinan y clarifican las necesidades, se

identifican las entidades de donde se alimentará la información de la bodega; se
revisan los atributos, sus propiedades y las transformaciones que se deben desarrollar
para homogenizar los datos. Se definen los procedimientos de conexión con las fuentes
de datos y el data warehouse y las herramientas de acceso del usuario final.
Diseño
Los modelos lógicos de la fase anterior se convierten en modelos físicos. Incluye la

implementación de la bodega en la herramienta; los programas que manipulan los
datos para crear, modificar, estandarizar, sumarizar o generar los índices a partir de los
datos de los sistemas de alimentación de información definidos en la etapa anterior;
determinar la periodicidad en que se hace el proceso de carga de datos a la bodega
Montaje
Procesos relacionados con la puesta en marcha del sistema. Un elemento importante

consiste en concientizar a los usuarios sobre la disponibilidad, beneficios y
presentación de de la bodega (proceso de comercialización de la información).
En la literatura especializada, estos pasos se conocen como el proceso ETL, llamado

así, por las siglas Extracción, Transformación y Carga de datos. Los procesos de
Extracción identifican los sistemas que alimentarán la bodega; el proceso de
transformación, define la manipulación de los datos para convertirlos y dejarlos en el
formato que requiere la bodega y el proceso de Carga, que define la periodicidad en
que se debe realizar el proceso para cargar los datos a la bodega.
Autoevaluación
Se conoce como ETL, el proceso de Extracción, Transformación y Carga de los datos

a la bodeba
Verdadero Falso
Lección 19. Estrategias recomendadas para diseño de datos
La metodología recomendada es iniciar con un prototipo.
Prototipo: La meta del prototipo de Bodega de Datos es proveer a los usuarios finales
con una aproximación de lo que la Bodega de Datos les puede proporcionar en un
período de tiempo tan corto como sea posible tal que el grupo de Bodega de Datos
pueda demostrar los beneficios de la Bodega de Datos a los usuarios y recolectar lo
más pronto la retroalimentación crítica de los usuarios.
Las estructuras de Datos apropiadas pueden ser distribuidas herramientas de acceso

de datos a usuarios finales y aplicaciones para realizar queries. Deben ser creadas
herramientas de soporte en la Decisión si es aplicable. Sin embargo el proceso de
integrar y transformar los datos de la Bodega de Datos no será completamente
automatizado.
En la mayoría de los casos el prototipo contemplará una cargada no repetible (de una
sola vez) de los datos de las estructuras de las Bodegas de Datos. La plataforma y la
Base de Datos para el almacenamiento puede también diferir de aquellas para la
arquitectura definitiva de Bodega de Datos, lo que es importante también, es que la
presentación de los Datos al usuario final sea tan fiel como sea posible para que sea
igualmente presentada en posteriores etapas de la Bodega de Datos.
Piloto
En la construcción de una Bodega de Datos, se debe observar especial cuidado porque

es la primera fase del proyecto en el cual el equipo de Bodega de Datos utilizará los
métodos, técnicas y herramientas que será la base para una Bodega de Datos
completa. Por esta razón el proyecto piloto de Bodega de Datos debe tener un pequeño
alcance y tiempo adicional comparativamente con los esfuerzos sucesivos de Bodega
de Datos.
Prueba del concepto tecnológico
La prueba del concepto tecnológico es un paso opcional que se puede necesitar para
definir si la arquitectura especificada para la Bodega de Datos funcionará finalmente
como se intenta. En la mayoría de proyectos de Bodega de Datos el esfuerzo del piloto
ha servido también como la prueba del concepto para la arquitectura técnica. Es crítico
que la prueba del concepto tecnológico no esté cercana al prototipo, dado que la meta
del prototipo es poner datos en las manos de los usuarios tan pronto como sea posible.
Arquitectura de la Bodega de Datos.
Datos de los sistemas de Aplicación y de otras fuentes de Bodegas de Datos deben ser
periódicamente extraídos y alimentados en la capa de Data Scrubbing. La extracción
debe ser realizada en muchos casos utilizando los programas para acompañar esta
tarea. El Data scrubbing debe ser hecho bien sea con ayuda de programas
desarrollados para esto, o con ayuda de herramientas de scrubbing tales como

Platinum Infopump.
El corazón de la Bodega de Datos debe ser organizado desde un punto de vista de

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

Extraer datos de diferentes sistemas
Herramientas gráficas
Herramientas de backup
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
Lección 44. Modelando la Distribución y la Implementación
Los Diagramas de Implementación se usan para modelar la configuración de los

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

Diseño de Bases
Bases de Datos
Datos Relacional
Relacionales
es -- Una extensión
extensión
inform
informal
al de
de UML
El Diagrama de Clase presenta un mecanismo de implementación neutral para modelar

los aspectos de almacenado de datos del sistema. Las clases persistentes, sus atributos,
y sus relaciones pueden ser implementados
implement ados directamente enen una base de datos orientada
orientada
a objetos
objetos.. Aun así, en
en el entorn
entorno
o de desarrollo actual, la base
base de datos relacional es el
el
método más usado para el almacenamiento de datos. Es en el modelado de esta área
donde UML se queda corto. El diagrama
diagrama de clase
clase de UML se puede usar
usar para modelar
modelar
algun
alg unos
os aspec
aspectos
tos del diseño de bases de datos relacionales,
relacionales, pero no cubre toda la
semántica involucrada en el modelado relacional, mayoritariamente la noción de atributos
clave que relacionan entre sí las tablas unas con otras. Para capturar esta información, un
Diagrama de Relación de Entidad
Entidad (ER diagram) se recomienda como extensión
extensión a UML.
El Diagrama de Clase se puede usar para modelarmodelar la estructura lógica de la base de datos,
independienteme
independ ientemente
nte de si es orientada
orientada a objetos
objetos o relacional,
relacional, con clases representando
tablas,, y atributos
tablas atributos de clase represen
representando
tando column
columnas.
as. Si una base
base de datos relacional
relacional es el
método de implementac
implementaciónión escogido,
escogido, entonces
entonces el diag diagrama
rama dede clase
clase puede
puede ser
ser
referenciados a un diagrama de de relación de entidad lógico. Las clasesclases persistentes
persistentes y sus
atributos hacen
hacen referencia
referencia directamente
directamente a las entid
entidades
ades lógicas
lógicas y a sussus atributos;
atributos; el
modelador
model ador dispon
disponee de varias
varias opcion
opciones
es sobre
sobre cómo inferir
infer ir asociaciones
asociaci ones en relaciones entre
entidades.
entidades. Las relaciones
relaciones de herencia
herencia son referenci
referenciadas
adas directame
directamente
nte a super-sub
super-sub
relaciones entre entidades en un diagrama( ver ver fig. 43) de relación de entidad (ER diagram).
diagram).
Figura 43: Extensión

Extensión de UML -- Diseño de Bases
Bases de Datos
Datos Relacionales
Relacionales con el
Diagrama de Relación de Entidad (ER Diagram)
Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el proceso de
determinar cómo el modelo relacional encaja;
encaj a; y qué atributos son claves
claves primarias
primarias,, claves
claves
Curso
Curso 301
301125
125 – Bases
Bases de datos
datos avanz
avanzada
adass
secundarias,, y claves
secundarias claves externas
externas basadas
basadas en relaciones
relaciones con
con otras entidades.
e ntidades. La idea es
construir un modelo lógico que sea conforme a las reglas de normalización de datos.
Al implementa
implementarr el diseño relacional, es una estrategia
estrategia encaminad
encaminadaa a hacer referencia al
diagrama de relación de entidad lógico a un diagrama físico que represente el objetivo, el
RDBMS. El El diagrama físico puede
puede ser denormalizado
denormalizado para lograr
lograr un diseño de base de
datos que tiene
tiene tiempos
tiempos eficientes
eficientes de acceso a los datos. Las relaciones super-sub
super-sub entre
entidades se resuelven por las estructuras
estructuras de tablas actuales.
actuales. Además,
Además, el diagrama físico
se usa para modelar propiedades específicas de cada fabricante para el RDBMS. Se crean
varios diagramas físicos si hay varios RDBMSs
RDBMSs siendo
siendo 'deployed';
'deployed'; cada diagrama
diagrama físico
representa uno de los RDBMS que son nuestro objetivo. Ver fig. 44
Figura 44: Relaciones

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

Los lenguajes de programación orientados a objetos requieren que toda la interacción con
objetos sea mediante envío de mensajes. Esto presenta serias limitaciones en las
aplicaciones de bases de datos. Considérese el ejemplo del diseño de sistema de
computadores y la consulta “Encontrar todos los sistemas de computadores que utilicen chips
vendidos por Oldblock Corporation”. Si seguimos estrictamente el modelo de la
programación orientada a objetos, se deberá enviar un mensaje a cada instancia de la clase
Chip para verificar su valor vendedor. Si tratáramos esta solicitud como un problema de la
base de datos, esperaríamos que existiera un índice para la clase Chip para las cuales el
campo vendedor fuera “Old-block Corporation”.
La última forma de cómo se va a tratar la consulta corresponde a una vista relacional de la

base de datos de objetos que vimos. De hecho, podríamos plantear consultas que
implicasen intersecciones de conjuntos de objetos. Sin embargo, la vista relacional de
objetos está limitada a variables, y gran parte de que el modelo orientado a objetos sea tan
atractivo se debe al uso de los métodos.
Así, un lenguaje de consultas para un sistema de base de datos orientado a objetos debe
incluir tanto el modelo de pasar el mensaje de objeto en objeto (un objeto cada vez) como
el modelo de pasar el mensaje de conjunto en conjunto en conjunto (un conjunto cada vez).
La mezcla del proceso con los dos modelos conduce a serias complicaciones en el diseño
del lenguaje, a menudo conocido como “impedancia desajustada”.
Referencias
BATINI C.; Ceri S.; Navathe S. Diseño conceptual de bases de datos. Un enfoque de
entidades-interrelaciones. 1994. Ed. Addison-Wesley.
CASTAÑO A.; Piattini M. Fundamentos y modelos de bases de datos. 1999. Ed.

Alfaomega. Segunda edición.
CERI S, Pelagatti G.,Distributed databases principles & systems.. Ed. MacGraw-Hill. 1985.
DATE, C. J, Introducción a los sistemas de bases de datos. Ed. Prentice Hall. Séptima
edición.
DORSEY, P, Hudicka Oracle8. Diseño de bases de datos con UML. J. Ed. Oracle press.
1999.
KROENKE,D. Procesamiento de bases de datos. Fundamentos, diseño e implementación.

2003. Ed. Pearson Education. Octava edición
SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGraw-Hill.

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

Basededatosavanzadav 3

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Basededatosavanzadav 3

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD

Escuela de Ciencias Básicas, Tecnología e Ingeniería

ANÍVAR CHAVES TORRES

San Juan de Pasto

Este documento fue preparado para estudiantes de Ingeniería de sistemas de la Unad y

Número de créditos y dedicación horaria ...............

Introducción general al curso ..............

Unidad I. Bases de datos distribuidas ...............

Capitulo 1. Conceptos básicos de bases de datos .........

Lección 1. Modelo entidad relación ..............

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

Lección 3. Álgebra relacional ...............

Lección 5. Transacciones ...............

Capítulo 2. Diseño de bases de datos distribuidas .........

Lección 6. Bases de datos distribuidas ...............

Lección 7. Bases de datos distribuidas ...............

Lección 8. Fragmentación ...............

Lección 9. Tipos de fragmentación de datos ...................

Lección 10. Diseño de replica ..............

Capitulo 3. Consultas ...............

Lección 11. Consultas distribuidas ...............

Lección 12. Descomposición

Lección 14. Consistencia

Lección 15. Catálogo ..............

Unidad 2. Bodegas de datos ...............

Capítulo 4. Diseño de bodegas de datos ..............

Lección 16. Introducción ................................................................................................. 106

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

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

Lección 19. Estrategias recomendadas para diseño de datos .................................111

Lección 20. Factores de riesgo ...................................................................................... 114

Capitulo 5. Minería de datos ............................................................................................... 115

Lección 22. Fundamentos del Data Mining .................................................................. 116

Lección 23. Alcance de Data Mining ............................................................................. 117

Lección 24. Fases de un Proyecto de Minería de Datos ...........................................119

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

Capítulo 6. Herramientas de minería de datos ................................................................ 122

Lección 26. Redes neuronales artificiales: ................................................................... 122

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

Lección 28. Método del vecino más cercano: ..............................................................124

Lección 29. Algoritmos genéticos .................................................................................. 125

Lección 30. Regla de inducción: .................................................................................... 126

Unidad 3. Bases de datos orientadas a objetos .................................................................. 127

Capítulo 7. Orientación a objetos ...................................................................................... 127

Lección 31. Introducción ................................................................................................ 127

Lección 32. Conceptos básicos: .................................................................................... 129

Lección 33. Arquitectura de administrador de sistemas de BDOO. .........................132

Lección 34. Sistema administradores de bases de datos orientadas a objetos

Lección 35. El sistema Postgres ................................................................................... 135

Capitulo 8. Lenguaje de Modelado Unificado UML ........................................................136

Lección 36. Introducción ................................................................................................. 136

Lección 37. ¿Método o Lenguaje de Modelado? ........................................................138

Lección 38. Una perspectiva de UML ........................................................................... 140

Lección 39. Diagramas de Secuencia .......................................................................... 145

Lección 40. Diagramas de Colaboración ...................................................................... 147

Capítulo 9. Modelado con UML ......................................................................................... 148

Lección 41. Modelando el comportamiento de las Clases con Diagramas de Estado

Lección 42. Diagramas de Actividad ............................................................................. 150

Lección 43. Modelando Componentes de Software ...................................................152

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

Lección 45. Diseño de Bases de Datos Relacionales -- Una extensión informal de

Número de créditos y dedicación horaria

El curso de Bases de datos avanzada está configurado como curso de 3 créditos.