Base de Datos Avanzada 2005

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA
FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

Programa de Ingeniería de Sistemas
MODULO
BASE DE DATOS AVANZADA
ROGELIO VASQUEZ BERNAL
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD

PROGRAMA INGENIERIA DE SISTEMAS
BOGOTÁ D.C., 2005
CONTENIDO
Temas Pág.
Introducción 8
UNIDAD 1
BASES DE DATOS RELACIONALES 1
CAPÍTULO 1. Conceptos básicos de bases de datos 1
1. Modelo entidad relación 1

1.2. Importancia del modelo entidad relación 2
1.3. Elementos del Modelo entidad relación 3
1.4 identificador único 10
2. Álgebra relacional 14
2.1. Selección 15
2.2. Proyección 15
2.3. Producto. 15
2.4. Unión. 16
2.5. Intersección 16
2.6. Diferencia 17
2.7. Join o Reunión. 17
2.8. División 19
3. Normalización de datos 19
3.1 Modelo entidad – relación 19
3.2 Normalización 20
3.3 Desnormalización de datos 23
CAPÍTULO 2. Transacciones 24
2.1. Propiedades de la transacción 24

2.2. Concurrencia 25
2.3 Seguridad y recuperación de datos 26
CAPÍTULO 3. Consultas 29
3.1 Recuperación 29
3.2 Cálculo relacional
31
3.3 Optimización de consultas
32
UNIDAD 2 34
BASES DE DATOS DISTRIBUIDAS 34
Introducción y fundamentos de Base de Datos Distribuidas. 34

CAPÍTULO 1. Diseño de bases de datos distribuidas 39
1.1 El problema de diseño 39
1.2 Objetivos del Diseño de la Distribución de los Datos 40
1.3 Enfoques al problema de diseño de bases de datos distribuidas 40
1.4 Fragmentación 42
1.5 Diseño de la Replica 49
CAPITULO 2. Consultas Distribuidas 51
2.1. Objetivo del procesamiento de las consultas 51

2.2. Niveles de procesador de consultas 51
2.3. Localización de datos 52
2.4 Procesamiento de intersección simple 53
2.5. Descomposición de una consulta y localización de datos distribuidos 56
2.6. Plan de optimización de consultas distribuidas 58
CAPITULO 3. Transacciones Distribuidas 58
3.1 Definición de una transacción 58

3.2 Condiciones de terminación de una transacción 59
3.3 Caracterización de transacciones 60
3.4 Caracterización de transacciones 61
3.5. Propiedades de las transacciones 61
3.6. Tipos de Transacciones 62
3.7. Estructura de transacciones 63
3.8. Aspectos relacionados al procesamiento de transacciones 64
3.9. Incorporación del manejador de transacciones a la arquitectura de un
SMBD 65
3.10 Recuperación En Sistemas Distribuidos 67
3.11. Control De Concurrencia 70
3.11.1 Teoría de la seriabilidad 70
3.11.2 Seriabilidad en SMBD distribuidos 73
3.11.3. Taxonomía de los mecanismos de control de concurrencia 73
3.11.4 Algoritmos basados en candados 74
3.11.5 Algoritmos basados en estampas de tiempo 77
3.11.6 Control de concurrencia optimista 79
CAPITULO 4. Catalogo 82
4.1. Conceptos básicos 82
4.2. Centralizado 82
4.3. Completamente replicado 82
4.4. Dividido 82
4.5. Combinación de centralizado y dividido 82
UNIDAD 3 86
OTROS MODELOS DE BASES DE DATOS 86
CAPÍTULO 1. Bases de datos orientadas a objetos 86
1.1 Introducción 86
1.2 Conceptos básicos 87
1.3 Arquitectura de administrador de sistemas de BDOO. 89
1.4 Ssistema administradores de bases de datos orientadas a objetos
(SABD-OO) 91
1.5 El sistema Postgres 92
1.6 Lenguaje de modelado unificado (UML) 92
1.6.1 Introducción 92
1.6.2 UML, ¿Método o Lenguaje de Modelado? 94
1.6.3 Una perspectiva de uml 95
1.6.4 Diagramas de Secuencia 99
1.6.5. Diagramas de Colaboración 100
1.6.6. Modelando el comportamiento de las Clases con Diagramas de
Estado 101
1.6.7. Diagramas de Actividad 102
1.6.8 Modelando Componentes de Software 103
1.6.9 Modelando la Distribución y la Implementación 104
1.6.10 Diseño de Bases de Datos Relacionales -- Una extensión informal
de UML 105
1.7 Consultas orientadas a objetos 107
CAPÍTULO 2. Bodega de datos 109
2.1 Introducción 109

2.2 Construcción y manejo de una bodega de datos 110
2.3 Manejo de los metadatos 111
2.4 Acceso y análisis de datos 111
2.5 Manejo de sistemas 111
3. Construcción de la bodega de datos 112
3.1 Ambiente actual 112
3.2 Ambiente de Negocios. 112

3.3 Ambiente técnico 112
3.4 Expectativas de los usuarios 112
4. Estrategias recomendadas para diseño de datos 112
4.1 Prototipo 112
4.2 Piloto 113
4.3 Prueba del concepto tecnológico 113
4.4 Arquitectura de la Bodega de Datos 113
4.5 Factores de riesgo 115
5. Minería de Datos 116
5.1. Introducción 116
5.2. Los Fundamentos del Data Mining 116
5.3. El Alcance de Data Minino 117
5.4. Fases de un Proyecto de Minería de Datos 119
5.5. ¿Cómo Trabaja el Data Mining? 119
5.6. Una arquitectura para Data Minino 120
5.7. Técnicas más comúnmente usadas en Data Mining: 121
GLOSARIO DE TÉRMINOS DE DATA MINING 123

ANEXO:Resultados de ejemplos referenciados en la sección 2 “Álgebra
Relacional”
LISTA DE FIGURAS
FIGURAS Pág.
Figura1. Representación de entidad

12
Figura 2. Representación de una relación

12
Figura 3. Relación recursiva

14
Figura 4. Nombre relaciones

14
Figura 5. Ejemplo nombre relaciones

15
Figura 6. Incorporando atributos

16
Figura 7. Atributos candidatos

16

17
Figura 9. Un atributo repetido indica una entidad perdida.

18
Figura 10. Añadir la entidad perdida 18
Figura 11. Muestra de identificadores únicos 20
Figura 12. Refinamiento de Entidades 21
Figura 13. Reconocimiento de patrones 22
Figura 14 - Esquema de Relaciones de Ejemplo 23
Figura 15 Primera forma normal 29
Figura 16. Segunda y tercera forma normal 31
Figura 17 - Pasos en el procesamiento de una consulta SQL 33

Figura 18. Motivación de los sistemas de bases de datos distribuidos. 44
Figura 19. Un sistema centralizado sobre una red 45
Figura 20. Un medio ambiente distribuido para bases de datos 46
Figura 21. El enfoque top-down para el diseño de bases de datos distribuidas 50
Figura 22. El problema de fragmentación de relaciones 51
Figura 23. El grado de fragmentación 53
Figura 24. Un modelo de transacción. 68
Figura 25. Un modelo del administrador de transacciones. 76
Figura 26. Ejecución centralizada de transacciones. 77
Figura 26b. Ejecución distribuida de transacciones. 77
Figura 27. Clasificación de los algoritmos de control de concurrencia 84
Figura 28. Gráfica del uso de los candados de dos fases
Figura 29. Comportamiento de los candados de dos fases estrictos 86
Figura 30. Comunicación en un administrador centralizado de candados de

dos fases estrictos. 87
Figura 31. Comunicación en candados de dos fases distribuidos 88
Figura 32. Fases de la ejecución de una transacción a) pesimista,

b) optimista. 90
Figura 33. Casos diferentes de las pruebas de validación para control de

concurrencia optimista. 91
Figura 34: Organizando el sistema mediante el uso de paquetes 106
Figura 35: Modelado de Casos de Uso. 107
Figura 36: Relación caso de uso Extiende (extends) frente a relación de caso
Usa (uses). 109
Figura 37: Diagrama de Secuencia para un escenario 110

Figura 38: Diagrama de Colaboración para un grupo de Objetos 111
Figura 39: Modelando Comportamiento Dinámico de un objeto 'Vuelo' con

un diagrama de estado 112
Figura 40: Diagrama de Actividad 113
Figura 41: Modelando componentes con el Diagrama de Componentes 114
Figura 42: Modelando la Distribución del Sistema con el Diagrama de

Implementación 115
Figura 43: Extensión de UML -- Diseño de Bases de Datos Relacionales
con el Diagrama de Relación de Entidad (ER Diagram) 116
Figura 44: Relaciones clave entre entidades en un Diagrama de

Relación de Entidad 117
Figura 45: Fases de un Proyecto de Minería de Datos 129
LISTA DE TABLAS
Pág.
Tabla 1 - Operadores del Álgebra relacional 23
Tabla 2. Comparación de las estrategias de replicación de fragmentos. 54
INTRODUCCIÓN
“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.
UNIDAD 1
BASES DE DATOS RELACIONALES
Capítulo 1. Conceptos básicos de bases de datos
2. 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 modelizar, 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 modelizar 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 auque 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.
1.3. 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:
1.3.1 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.
1.3.2. 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.
Representación de una relación: Una relación se representa mediante una línea

que une dos recuadros de entidades, o recursivamente (recurrentemente) une un
recuadro de entidad consigo mismo. La relación más común es la que tiene un
grado de muchos a uno: en el extremo muchos es obligatoria y opcional en el
extremo uno, como se muestra en la figura 2.
uno
Muchos opcional
obligatorio
Figura 2. Representación de una relación
Para un grado de muchos, la línea de relación une un recuadro de tres puntos,

conocido como ramificación. Para un grado de uno, la línea se une solamente en
un punto. En donde la terminación de la relación es obligatoria, se dibuja una línea
continua para esa mitad de la relación. En donde la terminación de la relación es
opcional, se dibuja una línea discontinua o de guiones.
Es útil pensar acerca de una relación de uno a muchos como una relación padre
a hijo, con la existencia del hijo encontrándose en una forma dependiente de su
padre.
1.3.2.1 Relación recursiva

Es una relación que se llama así misma, a continuación se muestra una relación
recursiva con propiedades idénticas.
Figura 3. Relación recursiva
Nombre de las relaciones: El nombre de cada extremo de una relación se sitúa

cerca al extremo apropiado en minúsculas como se muestra a continuación.
nombre- extremo-1
nombre-extremo-2
Figura 4. Nombre relaciones
Cuando la terminación de la relación es obligatoria, la frase “debe ser” se utiliza

para preceder al nombre final de la relación; para los nombres finales opcionales
de la relación se utiliza la frase “puede ser”
Por lo tanto el diagrama de la figura 5 se leería así:
Cada ENTIDAD-A debe ser el nombre-extremo-1 una y solo una ENTIDAD-B,
y de derecha a izquierda:
Cada ENTIDAD-B puede ser el nombre-extremo-2 y una o más ENTIDADes-A.

Veamos el siguiente ejemplo:
para
mostrado en
Figura 5. Ejemplo nombre relaciones
Explicación: Cada TIQUETE debe ser para uno y sólo un PASAJERO y derecha a
izquierda, cada PASAJERO se puede observar en uno o más TIQUETES.
El plural del nombre de la entidad se utiliza cuando el grado es muchos. Un grado

de muchos se lee como uno o más, y un grado de uno como uno y solamente
uno.
Cuando se dibujan diagramas de entidad relación, se puede encontrar un grado

mayor de precisión si la ramificación (los finales de muchos) se puede situar en la
terminación izquierda y superior de la línea de relación.
1.3.3. Atributos
Las entidades se componen de atributos que son cada una de las propiedades o
características que tienen las entidades. Cada ejemplar de una misma entidad
posee los mismos atributos, tanto en nombre como en número, diferenciándose
cada uno de los ejemplares por los valores que toman dichos atributos. Ejemplo si
consideramos la entidad PROFESOR y definimos los atributos Nombre, Teléfono,
Salario; podríamos obtener lo siguiente:
Juan Pérez Rodríguez, 4253250, 800.000
Martha López Jiménez, 8553260, 600.000
1.3.3.1 Representación de los atributos
Para representar un atributo hay que escribir su nombre en singular y en

minúscula, y de forma opcional con un ejemplo de su valor.
Figura 6. Incorporando atributos
En el ejemplo siguiente, los atributos candidatos son esenciales para ayudar a

distinguir entre dos entidades.
de !" #
"$% & !'
clasificación de
En este informe, la línea aérea puede que haya adquirido sólo cuatro o cinco tipos
de aviones diferentes, pero puede tener cien o más aviones reales. El número de
registro de atributo tendría un único valor para cada instancia de la entidad
AVION.
1.3.4. Características del atributo
Las siguientes normas simples ayudan a crear un modelo preciso, completo y

flexible.
1.3.4.1. Un atributo describe una entidad
El atributo debe describir la entidad en contra de lo que se muestra.
Esto puede ser obvio, pero es el error más común que se encuentra en los
atributos. Por ejemplo. ¿El "número de asiento" es un atributo de un cupón,
billete, tarjeta de embarque, avión o asiento de un avión? Obviamente es un
atributo de ASIENTO, pero en la vida real el número a menudo se ve duplicado
muchas veces; por ejemplo, en una tarjeta de embarque, que se muestra como
una entidad en la Figura 8.
¿Por qué? En el mundo real, un número de asiento es una forma muy

conveniente de representar una relación. Por el contrario, cuando se encuentran
estas situaciones hay que dibujar la línea de relación (si es necesario , crear la
entidad a la que se refiere), como se muestra a continuación.
Para que sirva de guía la mayoría de las entidades sólo se describirán manejando
entre dos y ocho atributos. Si se tienen más, probablemente existirán muchas
relaciones y/o entidades perdidas.
emitido para
'+,$
($ )* utilizado mediante
en
compuesto de
Figura 8. Asignar un atributo a la entidad correcta
1.3.4.2 Leer nombres de atributos
No hay que utilizar el nombre de la entidad como parte del nombre del atributo.
Sería redundante, ya que el atributo sólo describe la entidad. En el ejemplo
anterior, el “el número asiento” realmente ayudó a identificar una entidad perdida
llamada ASIENTO que se podría describir con el atributo ’número’ y quizás con
otros atributos como ‘tipo’.
Para leer atributos que se nombren de esta manera, se pueden utilizar de una de
las dos formas:
Nombre entidad nombre atributo o

Nombre atributo de nombre entidad.
Por ejemplo, asiento número o número de asiento.

1.3.4.2. Eliminar atributos repetidos (primera forma normal)
Una entidad que sólo tenga un valor para un atributo en cualquier momento. Si
son esenciales muchos valores, se debe crear una entidad nueva para
mantenerlos en la relación muchos a uno unidos con la entidad original.
'+,$ "$ $#%

' , $
*% $'
*% $'
*% $' -
Figura 9. Un atributo repetido indica una entidad perdida.
Siguiendo la norma anterior se obtiene:
'+,$ en '+,$ "$ $#%

' , $
compuesto de
Figura 10. Añadir la entidad perdida
Esta es una norma o regla que se llama normalmente ’Primera forma normal’
1.3.4.3. Nombre en singular
El nombre de un atributo debe ir en singular. Los nombres plurales generalmente

reflejan el problema de los atributos repetidos que se ha mostrado anteriormente.
¿Es una entidad?
Un atributo se convierte en una entidad cuando tiene importancia por sí misma,

con sus propias relaciones y atributos.
1.3.4.4. identificador único
Cada entidad debe ser identificable únicamente por una combinación de atributo
y/o relación. De esta forma se podría buscar siempre cualquier atributo candidato
que ayude a identificar una entidad.
1.3.4.5. El valor del atributo debe ser dependiente de todo el identificador único.
(segunda forma normal)
Hay que quitar los atributos por los que los valores son dependientes sólo de parte
del identificador único. Esto se conoce como ’Segunda forma normal’ . Dichos
atributos normalmente suponen una entidad perdida, pero relacionada.
1.3.4.6. Los atributos deben ser dependientes directamente del identificador

único (tercera forma normal)
Hay que quitar los atributos que no sean dependientes directamente del
identificador único de la entidad. Esto se conoce como ‘Tercera forma normal’. En
el subtema tres se profundizara el concepto de normalización.
1.4. Identificador único
1.4.1. Definición
Cada entidad debe ser únicamente identificable de forma que cada instancia de la
entidad esté separada y sea claramente identificable de todas las otras instancias
de ese tipo de entidad. El identificador único puede ser un atributo, una
combinación de relaciones o una combinación de atributos y relaciones.
Una entidad puede tener más de un medio alternativo de identificación única. El

método primario se puede mostrar en el diagrama entidad-relación antecediendo
a un atributo que forme el identificador con una marca ‘#’ , y colocando una barra
cruzada en el caso de una (s) línea (s) de relación. Figura 11
TIQUETE DE
EMBARQUE emitida para
# * fecha emitida # * número
# . hora emitida
usado mediante
emitida para en
utilizado compuesto de
mediante
de
planificado
como
/ /
# . '+,$ "$
0 $1
Figura 11. Muestra de identificadores únicos
Así, pues, para identificar únicamente una tarjeta de embarque se necesita:
La relación con el asiento, y por tanto el número de asiento.

La relación con el vuelo, y por tanto la fecha y hora de la salida,
La fecha y hora emitidas en el caso raro en que las tarjetas de
embarque se hayan reemitido; para volver a sentar a una familia
junta después de que alguien no haya aparecido en el vuelo
Como el identificador único del vuelo también incluye la relación
con la ruta de la línea aérea, se necesita el número de vuelo.
'+,$ en '+,$ "$ $#%

' , $
compuesto de
Figura 12. Refinamiento de Entidades
1.4.2. Norma de Diseño
Las normas simples del diseño que siguen a continuación se han definido para
que el diagrama sea fácil de leer, aplicable para personas que necesiten trabajar
con ellas y para maximizar la calidad y la precisión.
1.4.2.1. Diagrama de Subconjunto

Cuando se trata un área funcional en particular con un usuario o un diseño con

los diseñadores, es bueno crear un diagrama de subconjunto y expresar las
ideas de nuevo más eficazmente como un vehículo de comunicación con ese
propósito. Durante el proceso se van a encontrar omisiones y errores, que se
pueden corregir rápidamente la perspectiva diferente es una potente herramienta
analítica.
1.4.2.2. Esmerado y pulcro
Hay que organizar el diagrama de forma que los recuadros de las entidades
estén alineados y que las líneas de las relaciones sean rectas en sentido
horizontal o vertical. Hay que dibujar el menor número de líneas cruzadas
posible.
Hay que evitar Construir un diagrama que tenga demasiadas líneas paralelas
que estén muy juntas. Hay que utilizar el mayor espacio en blanco que se pueda
para evitar el sentimiento de congestión y utilice de vez en cuando la línea en
diagonal para ayudar a la estética del diagrama.
1.4.2.3. Reconocimiento de patrones
La mayoría de las personas tienen la capacidad incorporada de reconocer formas

y patrones en un instante y por tanto pueden recordar fácilmente el tema. Los
modelizadores pueden beneficiarse de esto haciendo que cada diagrama sea

claramente diferente en forma.
1.4.2.4. Texto
Hay que asegurarse de que el texto no sea ambiguo. Hay que evitar las
abreviaturas y las jergas. Hay que utilizar las convenciones de lectura descritas
anteriormente y leer todo el diagrama para asegurarse de que es completo y
preciso. Un buen diagrama entidad relación debería ser semánticamente
completo. Para mejorar la comprensión y la precisión al leerlo, hay que añadir
adjetivos y ejemplos cuando sea necesario.
2
clasificado por
clasificado para
Figura 13. Reconocimiento de patrones
Hay que centrar, alinear a la izquierda o a la derecha el texto consecuentemente,

de forma que se extraigan resultados de buena calidad.
1.4.4.5. Grado de relación
Hay que situar la terminación de muchas (ramificaciones) de las relaciones a la

izquierda o en la parte superior de la línea de relación. Se ha probado que esta
técnica ha incrementado la precisión del modelo formando la consideración de las
relaciones, desde las entidades que aparecen con más frecuencia a las menos
frecuentes.
2. Álgebra relacional
Es necesario que el lector se familiarice con el termino “relación”, entendida en

dos aspectos, en primer lugar cuando mencionamos esta palabra en el modelo
entidad relación se hace referencia a la asociación entre dos o más entidades, y,
al hablar de “relación” en el álgebra relacional se esta haciendo referencia a
tablas, puesto que las tablas son esencialmente relaciones.
El Álgebra relacional es un lenguaje de consulta procedural. Consta de un

conjunto de operaciones que toman como entrada una o dos relaciones y
producen como resultado una nueva relación, por lo tanto, es posible anidar y
combinar operadores. Hay ocho operadores en el álgebra relacional que
construyen relaciones y manipulan datos, estos son:
1. Selección 2. Proyección 3. Producto

4. Unión 5. Intersección 6. Diferencia
7. Join 8. División
Tabla 1 - Operadores del Álgebra relacional
Las operaciones de proyección, producto, unión, diferencia, y selección son

llamadas primitivas, puesto que las otras tres se pueden definir en términos de
estas.
Se hace necesario en este punto incluir un modelo de datos de ejemplo en el cual

trabajar para generar ejemplos de comandos y operadores. Para este efecto se
incluye un modelo básico de administración de Radio taxis. El Gráfico que se
presenta a continuación representa el Modelo conceptual (Modelo Lógico) o
Diagrama de Entidad-Relación, (este adopta una metodología similar a la
anterior):
Figura 14 - Esquema de Relaciones de Ejemplo
Los Esquemas de relaciones que se pueden construir a partir de este modelo son
los siguientes:
Dueño = {rut, nombre, teléfono, dirección, vigencia}
Chofer = {rut, nombre, teléfono, dirección, fecha_licencia_desde, fecha_licencia_hasta, vigencia}
Vale = {correlativo, hora_desde, hora_hasta, metraje_total, tarifa_total}
Móvil = {patente, rut_dueño, rut_chofer, marca, modelo, año}
Viaje = {correlativo_vale, patente_movil, Hora_Desde, hora_hasta, origen, destino, tarifa, metraje}
2.1. Selección.
El operador de selección opta por tuplas que satisfagan cierto predicado, se utiliza
la letra griega sigma minúscula ( ) para señalar la selección. El predicado aparece
como subíndice de . La Relación que constituye el argumento se da entre
paréntesis después de la .
Ejemplos :
2.2. Proyección.
La operación de proyección permite quitar ciertos atributos de la relación, esta

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

paréntesis.
Ejemplos :
2.3. Producto
En álgebra relacional el producto de dos relaciones A y B es:
A Veces B o A X B
Produce el conjunto de todas las Tuplas t tales que t es el encadenamiento de

una tupla a perteneciente a A y de una b que pertenece a B. se utiliza el símbolo
X para representar el producto.
Ejemplos:
Dueño x Móvil
2.4. Unión.
[1]
En álgebra relacional la unión de dos relaciones compatibles A y B es:
A UNION B o A B
Produce el conjunto de todas las tuplas que pertenecen ya sea a A o a B o a

Ambas. Al igual que en teoría de conjuntos el símbolo representa aquí la unión
de dos relaciones.
Ejemplo :
4 $5 6 4 ) ($ 6
Π 30#$' * Π 30#$' *
Devuelve todos los Dueños y los Chóferes.
2.5. Intersección.
En álgebra relacional la intersección de dos relaciones compatibles A y B
A INTERSECCION B o A 7 B
Produce el conjunto de todas las tuplas pertenecientes a A y B. Al igual que en

teoría de conjuntos el símbolo 7 representa aquí la intersección entre dos
relaciones.
Ejemplo:
4 $5 6 4 ) ($ 6
Π 30#$' * ∩Π 30#$' *
Devuelve todos los dueños que también son chóferes
2.6. Diferencia
En álgebra relacional la diferencia entre dos relaciones compatibles A y B
A MENOS B o A – B
Produce el conjunto de todas las tuplas t que pertenecen a A y no pertenecen a B.
Ejemplo:
4 $5 6 4 ) ($ 6
Π 30#$' * Π 30#$' *
Devuelve todos los dueños que NO son chóferes
2.7. Join o Reunión.
En álgebra relacional el JOIN entre el atributo X de la relación A con el atributo Y

de la relación B produce el conjunto de todas las tuplas t tal que t es el
encadenamiento de una tupla a perteneciente a A y una tupla b perteneciente a B
que cumplen con el predicado “A.X comp B.Y es verdadero” (siendo comp un
operador relacional y los atributos A.X y B.Y pertenecientes al mismo dominio). Si
el operador relacional “comp” es “=” entonces el conjunto resultante es un EQUI-
JOIN. Si se quita uno de éstos (usando una proyección) entonces el resultado es
un JOIN-NATURAL
Ejemplo :
2.8. División
En álgebra relacional el operador de división divide la relación A con grado m + n

por la relación B entregando como resultado una relación con grado m. El atributo
m + i de A y el atributo i de B deben estar definidos dentro del mismo dominio. Así
el resultado de
A DIVIDIDO POR B o A / B
produce la relación C con un sólo atributo X, tal que cada valor de x de C.X
aparece como un valor de A.X, y el par de valores (x, y) aparece en A para todos
los valores y que aparecen en B.
Ejemplo:
Selecciona todos los autos a cuyos chóferes les caduca la licencia el

01/01/1999
1% $% 1*" % "$ *"* ' "$ 1% $8$,&1% *" % $' $% $ $,* $% 9' *1
('*1"$1, " 1 , ' *'$:
Relaciones Compatibles: En el álgebra relacional la compatibilidad se aplica a

las operaciones de Unión, Intersección y Diferencia. Cada operación requiere dos
relaciones que deben ser compatibles, esto significa que deben ser del mismo
grado, n, y el i-ésimo atributo de cada una (i= 1, 2...n) se debe basar en el mismo
dominio.
3. Normalización de datos
La normalización de datos es un procedimiento que asegura que un modelo de
datos se ajusta a algunos estándares útiles. Para los datos y los modelos entidad-
relación, estos estándares se han definido para minimizar la duplicación de datos,
proporcionar la flexibilidad necesaria para soportar requisitos funcionales y para
permitir que el modelo se estructure sobre una amplia variedad de diseños
alternativos de base de datos.
3.1 Modelo entidad – relación
El modelo entidad-relación tiende a producir entidades que están normalizadas de

forma natural. Esto debido a que se sigue un proceso simple, como el siguiente:
Percibir las cosas de significación sobre lo que se necesita saber y

mantener la información. Estas entidades deben ser mutuamente
exclusivas, y se representan en un diagrama por medio de un recuadro con
el nombre de la entidad en singular y en mayúsculas.
Añadir las relaciones de gestión, las cuales se han nombrado como

asociaciones significativas entre entidades. Estas relaciones se muestran
como una línea entre dos recuadros; cada terminación tiene un grado (un
triángulo o ramificación que significa muchos; si no hay triángulo significa
uno) y la opcionalidad (una línea de puntos significa opcional, una línea
continua significa obligatorio).
En cada entidad se listan los tipos de información que se podrían mantener

o conocer. Estos atributos se muestran dentro de la entidad como nombres
en minúsculas.
Finalmente, se determina la forma en que cada aparición de una entidad

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

unívocamente identificadas, se ha normalizado completamente y por tanto se
ajusta a la tercera forma normal; se pueden aplicar las siguientes comprobaciones
simples:
Asegurar que todas las entidades son identificables de forma única

Por una combinación de atributos y / o relaciones
3.2.1 Primera forma normal: [1NF]
Eliminar los atributos repetidos o grupos de atributos.

Si existe más de un valor a la vez para un atributo o para más de uno con el
mismo nombre, se define una entidad nueva, la cual se describe mediante ese
atributo. El identificador único de esta nueva entidad consta de uno de los
atributos que se fueron con ella y la relación (de muchos a uno) se lleva a la
entidad original.
/
@ ($ )*
@) *
@ '+,$ "$ 0 $1
' , $1 A'$* 9$*
' , $ *$ & $
& "$ *0!'
*&* "*" "$ *% $' %
' , $ & 1 *' $
( ' !' & 1 *' $
' , $ & 1 *' $
( ' !' & 1 *' $
' , $ & 1 *' $ ;
/
/ B @ ($ )*
&* * @) *
.' , $ @ '+,$ "$ 0 $1
. ( ' !' & 1*" & ' , $ "$ *$ 1 A'$*
' , $ *$ & $
& "$ *0!'
*&* "*" "$ *% $' %
Figura 15 Primera forma normal

; $# '"* ( ,* ' ,*1<= >?
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.
3.2.3 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:
&* * /
/ B @ ($ )*
' , $ & 1*" & @) *
( ' !'
"$
&1
*' ( *"
,
@'+,$ "$ 0 $1
' , $ *$ 1 A'$*
' , $ *$ & $
& "$ *0!'
*&* "*" "$ *% $' %
%$ 0" &
&$ *" % $
&$ *"* &
$' * #*"* "$
Figura 16. Segunda y tercera forma normal

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

cualquier momento cada tupla (línea relacional) de R se compone de un valor
clave primario que identifica alguna identidad, junto con un grupo de cero o más
valores independientes mutuamente que describen esa entidad de alguna
2
manera”.
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
B, 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 X. De modo equivalente: R está en 4NF si todos los MVDs
(dependencias multivalores) son de verdad dependencias funcionales (FD).
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.”
3.3 Desnormalización de datos
La desnormalización de datos es el procedimiento inverso, llevado a cabo

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

muy común, como queda evidenciado por el hecho de que la mayor parte de los
formularios en papel mantienen grandes datos de referencias. Todos conocemos
los problemas que se pueden originar cuando ese dato se cambia y se tiene que
volver a emitir el grupo entero de formularios.
* $3 ' ' " ' * * *%$ C% $,3D$" - " %% ' E $%1$C 1%)'#
Capítulo 2. 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.
2.1. 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:
Atomicidad:
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.
Consistencia:
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.
Aislamiento:
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.
Durabilidad:
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:
Activa (Active): el estado inicial; la transacción permanece en este estado

durante su ejecución.
Parcialmente comprometida (Uncommited): Después de ejecutarse la última
transacción.
Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.
Abortada (Rolled Back): después de haber retrocedido la transacción y

restablecido la base de datos a su estado anterior al comienzo de la transacción.
Comprometida (Commited): tras completarse con éxito.
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.
2.2. 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.
2.3. 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:
Fallo en la transacción, que a su vez se dividen en errores lógicos y

errores del sistema. Un error lógico ocurre cuando una transacción no puede
continuar con su ejecución normal a causa de una condición interna como lo es un
desbordamiento o un exceso de recursos. Un error del sistema ocurre cuando el
sistema se encuentra en un estado no deseado como en el caso de los
interbloqueos.
Caída del sistema, provocado ya sea por el hardware, el sistema operativo

o por el software de base de datos. Comúnmente causa la pérdida del contenido
de la memoria primaria y aborta el procesamiento de una transacción.
Fallo de disco, para el cual sólo sirve la recuperación por medio de copias
existentes en medios de almacenamiento secundario como cintas magnéticas.
La forma más aceptada de lograr un tipo de almacenamiento lo más estable

posible es replicando la información en varios medios de almacenamiento no
volátil, con modos de fallos independientes. Los sistemas RAID (disposición
redundante de discos independientes) garantizan que el fallo de un sólo disco no
conduzca a la perdida de datos. Sin embargo los sistemas RAID, no pueden
proteger al sistema de una pérdida de datos en el caso de una catástrofe
geográfica, para tales efectos muchos sistemas de almacenamiento guardan
copias de seguridad en cintas en otros lugares, no obstante, como las cintas no
pueden ser trasladadas continuamente, los últimos cambios realizados luego del
traslado de cintas no se pueden volver a recuperar en el caso de tales desastres.
Los sistemas más seguros guardan copias de cada bloque de almacenamiento en
otra disposición geográfica, datos que se transmiten por medios de redes de
computadores al sistema de respaldo remoto...
El estado de un sistema de base de datos puede no volver a ser consistente en

caso de que ocurran fallos, para preservar la consistencia es necesario que cada
transacción sea atómica. Garantizar la propiedad de atomicidad es
responsabilidad del esquema de recuperación.
Existen básicamente 2 esquemas que garantizan la atomicidad.

[4]
Basados en el registro histórico . Todas las modificaciones se graban en el
registro histórico, el cual debe estar guardado en almacenamiento estable. En el
esquema de modificación diferida, durante la ejecución de una transacción, se
difieren todas las operaciones de escritura hasta que la transacción se
compromete parcialmente, momento en el cual se utiliza la información del
registro histórico asociado con la transacción para ejecutar las escrituras diferidas.
Con la técnica de modificación inmediata todas las modificaciones se aplican
directamente en la base de datos. Si ocurre una caída se utiliza la información del
registro histórico para llevar a la base de datos a un estado estable previo.
Paginación en la sombra. Durante la vida de una transacción se mantienen 2

tablas de páginas: la tabla actual de páginas y la tabla de páginas sombra. Ambas
tablas son idénticas al principio de la transacción, sin embargo, la tabla actual de
páginas puede ir cambiando luego de cada operación escribir. Todas las
operaciones de lectura y escritura utilizan la tabla de páginas actual, cuando una

transacción se compromete parcialmente se desecha la tabla de páginas sombra
y la tabla actual se convierte en la nueva tabla de páginas. Si la transacción
fracasa, simplemente se desecha la tabla actual de páginas.
El procesamiento de transacciones se basa en un modelo de almacenamiento en

el cual la memoria principal contiene una memoria intermedia para el registro
histórico, una memoria intermedia para la base de datos y una memoria
intermedia para el sistema. Una implementación eficiente de un esquema de
recuperación de datos requiere que sea mínimo el número de escrituras de la
base de datos y que sea realizado en almacenamiento estable. Los registros del
registro histórico pueden guardarse inicialmente en la memoria intermedia del
registro histórico pero deben ser llevados a almacenamiento estable bajo dos
situaciones:
Deben escribirse en almacenamiento estable todos los registros del registro

histórico que referencien a la transacción Ti antes de grabar el registro que
indique que la transacción Ti ha sido comprometida
Deben escribirse en almacenamiento estable todos los registros del registro

histórico pertenecientes a los datos de un bloque antes de que ese bloque de
datos se escriba desde la memoria intermedia a la base de datos.
[4]
Comúnmente llamado log de transacciones
Capítulo 3. Consultas
El Procesamiento de consultas hace referencia a la serie de actividades a seguir

para llevar a cabo la recuperación de datos desde una base de datos. Estas
actividades incluyen la traducción de consultas en lenguajes de consultas de alto
nivel (Ej: SQL) a expresiones que se puedan implementar en un nivel físico, así
como también los algoritmos de evaluación y optimización de consultas.
3.1 Recuperación
Una de las ventajas principales del modelo relacional presentado por Codd en
1970 es la que tiene relación con la independencia de los datos que se entiende
aquí como la separación entre el modelo (lógico) y la implementación (física). Esta
separación nos permite desarrollar una poderosa semántica lógica independiente
de una implementación física particular.
Uno de los desafíos de la independencia de datos es que la codificación de una

consulta para la base de datos se componga de 2 fases:
La descripción lógica de la consulta (que se supone que debe hacer).

La definición del plan de ejecución físico (el que muestra como implementar
la consulta).
Antes de empezar el procesamiento de la consulta el sistema debe traducir la

consulta a un medio de representación interno con el cual le sea fácil operar. Así,
por ejemplo para SQL la representación más útil es la del álgebra relacional
extendida (árbol relacional). Este proceso cumple la misma función que el
analizador léxico y sintáctico de un compilador, es decir, revisa la sintaxis de la
consulta y chequea que todos lo identificadores sean nombres de objetos de la
base de datos, en el caso de las vistas reemplaza el nombre de la vista por la
expresión relacional que la representa.
El plan de ejecución es un árbol relacional armado a partir de la consulta y que

sólo puede ser entendido por el motor de ejecución de consultas. La
transformación de la consulta a un plan puede ser hecha efectivamente a mano y
en algunos casos de consultas simples que se ejecutan miles de veces esta
podría ser la mejor estrategia, sin embargo, una de las ventajas que nos ofrece el
modelo relacional es la capacidad de usar la información del catalogo de la base
de datos, que como se verá más adelante, podrá responder una gran cantidad de
preguntas distintas.
Por otro lado, aunque una consulta simple pueda ser ejecutada miles de veces, no
existe un camino mecánico que garantice que el plan de ejecución elegido
satisfaga la consulta que se quiere implementar, puesto que:
Un Plan calculado a mano (o un plan precalculado) será invalidado por

cambios lógicos dentro del esquema o por cambios físicos en el camino de
acceso a la información o en el almacenamiento físico.
Si los parámetros de la consulta (o los datos) cambian, la relación optima
que asocia a un plan con una consulta por sobre otros puede cambiar.
La siguiente figura nos muestra los pasos en el procesamiento de una consulta.
Figura 17 - Pasos en el procesamiento de una consulta SQL
Después de enviar la consulta, la base de datos debe producir su correspondiente

plan de ejecución. El primer paso en este proceso es traducir la consulta desde
SQL a un árbol lógico en álgebra relacional, proceso comúnmente llamado parser.
El Próximo paso es traducir el árbol de la consulta en el plan de ejecución.

Generalmente existe un gran número de planes que implementan al árbol de la
consulta; el proceso de encontrar el mejor de estos planes se le denomina
optimización de consultas.
3.2. Cálculo relacional

La manipulación del modelo relacional esta basada en el álgebra relacional; sin

embargo, de igual forma podemos indicar que también esta basada en el cálculo
relacional. Álgebra y cálculo son alternativos entre sí, la diferencia entre ellos es la
siguiente: mientras que el álgebra proporciona un conjunto de operadores
explícitos (juntar, unir, proyectar, etc), que pueden usarse para indicar al sistema
cómo construir cierta relación dada, al cálculo simplemente proporciona una
notación para establecer la definición de esa relación deseada en términos de
3
dichas relaciones dadas .
El cálculo relacional de tuplas describe la información deseada sin dar un

procedimiento específico para obtenerla. Las consultas en el cálculo relacional de
tuplas se expresan como:
{ t | P(t)},
Es decir, son el conjunto de tuplas t tales que se cumple el predicado P para cada
t. Siguiendo la misma notación, se utiliza t[A] para el valor de la tupla t en el
atributo A.
Si sólo se desea obtener un atributo de la tupla, se utiliza el constructor “Existe” de

la lógica matemática. Así, si lo que se desea es el Nombre de los dueños de taxis
que estén vigentes:
"Conjunto de todas las tuplas t tales que existe una tupla s en la relación Dueño
para la que los valores de t y de s son iguales en el atributo Nombre y el valor de s
para el atributo vigencia = ‘S’ ". La variable de tupla t se define sólo en el atributo
Nombre, puesto que éste es el único atributo para el que se especifica una
condición para t. Así, el resultado es una relación sobre (Nombre).
Si lo que se desea es obtener las tarifas de todos los viajes que ha efectuado
todos los móviles de marca “chevrolet”, la consulta requiere de dos cláusulas
“Existe” conectadas por el operador de conjunción lógica “y”.
;
* $3 ' " !' * 1% % $,*% "$ *%$% "$ * %3 $' $ F*11
Que se lee como el conjunto de todas las tuplas (tarifa) correspondientes a los
viajes que han hecho todos los móviles de marca “chevrolet”.
Considérese ahora la consulta “obtener todos los RUT de los dueños de móviles,
cuyos móviles no hayan efectuado nunca un viaje”:
que ocupa la cláusula “Existe” para exigir que el dueño posea un móvil y la
cláusula “no existe” para eliminar a aquellos móviles que tengan viajes realizados.
La consulta que se presenta a continuación utiliza la implicación, la fórmula “P

implica Q” significa que “si P es verdad entonces Q debe ser verdad”, se introduce
el constructor “para todo”. Se desea Selecciona todos los autos a cuyos chóferes
les caduca la licencia el “01/01/1999”.
Sin embargo como la intención del modulo no es la de suplir al texto, se

recomienda consultar el tema completo en la bibliografía recomendada.
3.3 Optimización de consultas
Las consultas de base de datos relacionales son o bien declarativas o algebraicas.

Los lenguajes algebraicos permiten la transformación algebraica de la consulta,
luego, basándose en la especificación algebraica de la consulta es relativamente
fácil para el optimizador generar diversos planes equivalentes para la consulta y
elegir el menos costoso.
Dado este nivel de generalidad, el optimizador puede ser visto como el generador
de código de un compilador para el lenguaje SQL, que produce el código que será
interpretado por el motor de ejecución de consultas, excepto que el optimizador
marca énfasis en la capacidad de producir el código más eficiente, haciendo uso
para tales efectos del catálogo de la base de datos, de donde obtiene información
estadística de las relaciones referenciadas por la consulta, algo que los lenguajes
de programación tradicionales no hacen.
Un aspecto de la optimización de consultas se sitúa en el nivel del álgebra

relacional. Dado un conjunto de reglas se trata de encontrar una expresión que
sea equivalente a la expresión dada pero que sea más eficiente en la ejecución.
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.
UNIDAD 2
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 cómputo distribuido podemos encontrar: funciones distribuidas,
procesamiento distribuido de datos, multiprocesadores, multicomputadoras,
procesamiento satelital, procesamiento tipo "backend", computadoras dedicadas y

de propósito específico, sistemas de tiempo compartido, sistemas funcionalmente
modulares.
Existen muchos componentes a distribuir para realizar una tarea. En computación

distribuida los elementos que se pueden distribuir son:
Control. Las actividades relacionadas con el manejo o administración del

sistema.
Datos. La información que maneja el sistema.
Funciones. Las actividades que cada elemento del sistema realiza.
Procesamiento lógico. Las tareas específicas involucradas en una actividad
de procesamiento de información.
Figura 18. Motivación de los sistemas de bases de datos distribuidos.
Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos

lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes
sitios interconectados por una red de comunicaciones (ver Figura18).
Un sistema de bases de datos distribuida (SBDD) es un sistema en el cual

múltiples sitios de bases de datos están ligados por un sistema de
comunicaciones, de tal forma que, un usuario en cualquier sitio puede accesar los
datos en cualquier parte de la red exactamente como si los datos estuvieran
almacenados en su sitio propio.
Un sistema de manejo de bases de datos distribuidas (SMBDD) es aquel que

se encarga del manejo de la BDD y proporciona un mecanismo de acceso que
hace que la distribución sea transparente a los usuarios. El término transparente
significa que la aplicación trabajaría, desde un punto de vista lógico, como si un
solo SMBD ejecutado en una sola máquina, administrara esos datos.
Un sistema de base de datos distribuida (SBDD) es entonces el resultado de la

integración de una base de datos distribuida con un sistema para su manejo.
Dada la definición anterior, es claro que algunos sistemas no se pueden

considerar como SBDD. Por ejemplo, un sistema de tiempo compartido no incluye
necesariamente un sistema de manejo de bases de datos y, en caso de que lo
haga, éste es controlado y administrado por una sola computadora.
Un sistema de multiprocesamiento puede administrar una base de datos pero lo

hace usualmente a través de un solo sistema de manejo de base de datos; los
procesadores se utilizan para distribuir la carga de trabajo del sistema completo o
incluso del propio SMBD pero actuando sobre una sola base de datos.
Finalmente, una base de datos la cual reside en un solo sitio de una red de
computadoras y que es accesada por todos los nodos de la red no es una base de
datos distribuida (Figura 19). Este caso se trata de una base de datos cuyo control
y administración esta centralizada en un solo nodo pero se permite el acceso a
ella a través de la red de computadoras.
// 2
2
2
Figura 19. Un sistema centralizado sobre una red.
El medio ambiente típico de un SMBDD consiste de un conjunto de sitios o nodos

los cuales tienen un sistema de procesamiento de datos completo que incluye una
base de datos local, un sistema de manejo de bases de datos y facilidades de
comunicaciones. Si los diferentes sitios pueden estar geográficamente dispersos,
entonces, ellos están interconectados por una red de tipo WAN. Por otro lado, si
los sitios están localizados en diferentes edificios o departamentos de una misma
organización pero geográficamente en la misma ubicación, entonces, están

conectados por una red local (LAN) (Figura 20).
// 2
2
2
Figura 20. Un medio ambiente distribuido para bases de datos.
Tipos de bases de datos distribuidas.
En términos generales, podemos decir que existen dos tipos de sistemas de

bases de datos distribuidas, homogéneas y sistemas de bases de datos
distribuidas heterogéneas.
La homogeneidad o heterogeneidad, puede darse a diferentes niveles, Hardware,

Software o sistema operativo. Para este curso, se asume que cuando se indica la
homogeneidad del sistema, se hace referencia a que en todos los sitios del
sistema, existe el mismo sistema de administración de base de datos y
generalmente incluye el mismo modelo de datos.
Un sistema de bases de datos distribuido, incluye diferentes sistemas

manejadores de bases de datos, probablemente con modelos de datos diferentes
que hay que compatibilizar y con retos a nivel de comunicación entre los sistemas
de bases de datos que conforman el sistema, para dar la visión al usuario de
integración y de un único sistema de bases de datos.
CAPÍTULO 1. Diseño de bases de datos distribuidas
En el presente capítulo se mostrará los aspectos importantes referentes al diseño

de una base de datos distribuida. Se revisará el problema de fragmentación de los
datos así como la transparencia que un sistema de datos distribuidos debe
guardar respecto a la vista del usuario. Se presentarán los algoritmos para
fragmentación horizontal, fragmentación horizontal derivada y fragmentación
vertical. En la parte final de este capítulo se discute el problema de asignamiento
de fragmentos.
1.1 El problema de diseño
El problema de diseño de bases de datos distribuidos se refiere, en general, a

tomar decisiones acerca de la ubicación de datos y programas a través de los
diferentes sitios de una red de computadoras. Este problema debería estar
relacionado al diseño de la misma red de computadoras. Sin embargo, en estas
notas únicamente el diseño de la base de datos se toma en cuenta. La decisión
de donde colocar a las aplicaciones tiene que ver tanto con el software del
SMBDD (sistema manejador de base de datos distribuidas) como con las
aplicaciones que se van a ejecutar sobre la base de datos.
El diseño de las bases de datos centralizadas contempla los puntos siguientes:
1. Diseño del "esquema conceptual" el cual describe la base de datos

integrada (esto es, todos los datos que son utilizados por las aplicaciones
que tienen acceso a las bases de datos).
2. Diseño "físico de la base de datos", esto es, mapear el esquema

conceptual a las áreas de almacenamiento y determinar los métodos de
acceso a las bases de datos.
En el caso de las bases de datos distribuidas se tienen que considerar los

problemas siguientes:
1. Diseño del “esquema conceptual”, donde se busca describir el modelo de datos

de todo el sistema
1. Diseño de la fragmentación, este proceso se determina mediante la división de las

tablas en fragmentos horizontales, verticales o mixtos, dependiendo de las
necesidades de información detectadas en la etapa de análisis del sistema.
3. Diseño de la asignación de los fragmentos, esto determina la forma en que los

fragmentos se mapean en los sitios o nodos del sistema.
4. Diseño de replicación. Proceso que indica en que lugar (nodos), se ubican copias
de tablas o fragmentos y la frecuencia de actualización de la información.
1.2 Objetivos del Diseño de la Distribución de los Datos.
En el diseño de la distribución de los datos, se deben de tomar en cuenta los

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

procesamiento local corresponde al principio simple de colocar los datos tan cerca
como sea posible de las aplicaciones que los utilizan. Se puede realizar el diseño
de la distribución de los datos para maximizar el procesamiento local agregando el
número de referencias locales y remotas que le corresponden a cada
fragmentación candidata y la localización del fragmento, que de esta forma se
seleccione la mejor solución de ellas.
Distribución de la carga de trabajo. La distribución de la carga de trabajo sobre

los sitios, es una característica importante de los sistemas de cómputo
distribuidos. Esta distribución de la carga se realiza para tomar ventaja de las
diferentes características (potenciales) o utilizaciones de las computadoras de
cada sitio, y maximizar el grado de ejecución de paralelismo de las aplicaciones.
Sin embargo, la distribución de la carga de trabajo podría afectar negativamente el
procesamiento local deseado.
Costo de almacenamiento y disponibilidad. La distribución de la base de datos

refleja el costo y disponibilidad del almacenamiento en diferentes sitios. Para esto,
es posible tener sitios especializados en la red para el almacenamiento de datos.
Sin embargo el costo de almacenamiento de datos no es tan relevante si éste se
compara con el del CPU, I/O y costos de transmisión de las aplicaciones
1.3 Enfoques al problema de diseño de bases de datos distribuidas
Existen dos estrategias generales para abordar el problema de diseño de bases

de datos distribuidas:
El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado para
aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el
análisis de requerimientos para definir el diseño conceptual y las vistas de usuario.
A partir de ellas se define un esquema conceptual global y los esquemas externos
necesarios. Se prosigue con el diseño de la fragmentación de la base de datos, y
de aquí se continúa con la localización de los fragmentos en los sitios, creando las
imágenes físicas. Esta aproximación se completa ejecutando, en cada sitio, "el
diseño físico" de los datos, que se localizan en éste. En la Figura 21 se presenta
un diagrama con la estructura general del enfoque top-down.
El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de

bases de datos existentes, generando con esto bases de datos distribuidas. En
forma resumida, el diseño bottom-up de una base de datos distribuida requiere de

la selección de un modelo de bases de datos común para describir el esquema
global de la base de datos. Esto se debe, a que es posible que se utilicen
diferentes SMBD. Después se hace la traducción de cada esquema local en el
modelo de datos común y finalmente se hace la integración del esquema local en
un esquema global común.
Figura 21. El enfoque top-down para el diseño de bases de datos

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

¿Cómo considerar los requerimientos de la información?
Figura 22. El problema de fragmentación de relaciones
1.4 Fragmentación
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 Ñ , tal que,
GH ≤ ≤ '
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:
No soportar replicación. Cada fragmento reside en un solo sitio.

Soportar replicación completa. Cada fragmento en cada uno de los sitios.
Soportar replicación parcial. Cada fragmento en algunos de los sitios.
Como regla general se debe considerar que la replicación de fragmentos es de

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

$%*, $' "$ >9 1 "$ *" "$ *"
'% 1*%
*'$8 "$ $ % >9 1 ' $:% $' $ "$ *" "$ *"
' 1"$ "$ *" (A 1 >9 1
' $' *
'(* 1"*" C*1 1 *8
$*1"*" &1 * !' & % 1$ $*1% * &1 * !' & % 1$
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:
Información sobre el significado de los datos

Información sobre las aplicaciones que los usan
Información acerca de la red de comunicaciones
Información acerca de los sistemas de cómputo
1.4.1 Tipos de fragmentación de datos
Existen tres tipos de fragmentación:
Fragmentación horizontal
Fragmentación vertical
Fragmentación híbrida
En las siguientes secciones revisaremos de manera informal cada uno de los tipos
mencionados. Más adelante, se presentará de manera más formal la construcción
de los diferentes tipos de fragmentación.
1.4.2 Fragmentación horizontal primaria
Consiste del particionamiento en tuplas de una relación global en subconjuntos,

donde cada subconjunto puede contener datos que tienen propiedades comunes
y se puede definir expresando cada fragmento como una operación de selección
sobre la relación global.
Ejemplo 3. Considere la relación global
SUPPLIER (SNUM, NAME, CITY)
entonces, la fragmentación horizontal puede ser definida como:
SUPPLIER1 = SLcity == "SF"SUPPLIER
SUPPLIER1 = SLcity == "LA"SUPPLIER
Esta fragmentación satisface la condición de completes si "SF" y "LA" son

solamente los únicos valores posibles del atributo CITY.
2. La condición de reconstrucción se logra con:
SUPPLIER = SUPPLIER1 unión SUPPLIER2
3. La condición de disjuntos se cumple claramente en este ejemplo.
1.4.3 Fragmentación horizontal derivada
La fragmentación derivada horizontal se define partiendo de una fragmentación

horizontal.
En esta operación se requiere de Semi-junta (Semi-Join) el cual nos sirve para

derivar las tuplas o registros de dos relaciones.
Ejemplo 4. Las siguientes relaciones definen una fragmentación horizontal

derivada de la relación SUPPLY.
SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1

1.4.4 Fragmentación vertical
La fragmentación vertical es la subdivisión de atributos en grupos. Los fragmentos

se obtienen proyectando la relación global sobre cada grupo. La fragmentación es
correcta si cada atributo se mapea en al menos un atributo del fragmento.
Ejemplo 5. Considere la siguiente relación global:
EMP( empnum, name, sal, tax, mgrnum, depnum )
una fragmentación vertical de esta relación puede ser definida como:
EMP1 = PJempnum, name, mgrnum, depnum EMP
EMP2 = PJempnum, sal, tax EMP
La reconstrucción de la relación EMP puede ser obtenida como:
EMP = EMP1 (JN empnum) EMP2 porque empnum es una clave de EMP
1.4.5 Fragmentación híbrida
En lo que respecta a la fragmentación híbrida, esta consiste en aplicar la

fragmentación vertical seguida de la fragmentación horizontal o viceversa.
Ejemplo 6. Considere la relación global
EMP (empnum, name, sal, tax, mrgnum, depnum)
Las siguientes son para obtener una fragmentación mixta, aplicando la vertical
seguida de la horizontal:
EMP1 = SL depnum <= 10 PJempnum, name, mgrnum, depnum EMP
EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum EMP
EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum EMP
EMP4 = PJ empnum, name, sal, tax EMP
La reconstrucción de la relación EMP es definida por la siguiente expresión:
EMP = UN(EMP1, EMP2, EMP3)JNempnum = empnumPJempnum, sal, tax EMP4

Finalmente, como otro ejemplo considere el siguiente esquema global
EMP(EMPNUM, NAME, SAL, TAX, MGRNUM, DEPNUM)
DEP(DEPNUM, NAME, AREA, MGRNUM)
SUPPLIER(SNUM, NAME, CITY)
SUPPLY(SNUM, PNUM, DEPNUM, QUAN)
Después de aplicar una fragmentación mixta se obtiene el siguiente esquema

fragmentado
EMP1 = Sldepnum <= 10 PJempnum, name, mgrnum, depnum (EMP)
EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum (EMP)
EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum (EMP)
EMP4 = PJ empnum, name, sal, tax (EMP)
DEP1 = SL depnum <= 10 (DEP)
DEP2 = SL 10 < depnum <= 20 (DEP)
DEP3 = SL depnum > 20 (DEP)
SUPPLIER1 = SL city == "SF" (SUPPLIER)
SUPPLIER2 = SL city == "LA" (SUPPLIER)
1.5 Diseño de la Replica
La replicación de información es de utilidad para obtener un mejor rendimiento y

para ofrecer un mayor grado de confiabilidad (tolerancia a fallas). Se entiende por
Replicación, la administración de copias de fragmentos o tablas y de asegurar su
actualización en los periodos de tiempo definidos por el administrador del sistema.
La replicación se complica cuando es necesario hacer actualizaciones a las copias

múltiples de un dato. Por tanto, respecto a la replicación, en la asignación de
fragmentos se tienen tres estrategias:
1 No soportar replicación. Cada fragmento reside en un solo sitio.

2 Soportar replicación completa. Cada fragmento en cada uno de los sitios.
3 Soportar replicación parcial. Cada fragmento en algunos de los sitios.
Como regla general se debe considerar que la replicación de fragmentos es de

utilidad cuando el número de consultas de solo lectura es (mucho) mayor que el
número de consultas para actualizaciones. En la Tabla 1 se comparan la
complejidad de implementar o tomar ventaja de las diferentes alternativas de
replicación, respecto de los diferentes aspectos importantes en bases de datos
distribuidas.
Además de indicar en que sitios se desea guardar copia de la entidad o tabla, es

necesario definir la frecuencia o periodo de actualización de la copia. En este
sentido, podemos encontrar los siguientes tipos de réplica:
1 En tiempo real, es decir en el momento que un sitio actualiza un registro

(inserción, modificación y borrado de registros), se envía una copia de la
información a los sitios donde reside la copia.
2 Copia fuera de línea, esta opción permite que una vez registrada la
transacción en el sitio donde ella se genera, pueda pasar un tiempo para
actualizar las copias de la información almacenadas en otros lugares.
Con estos dos tipos de replicación, es posible definir varios modelos de sistemas
de replica:
1. Maestro - maestro, hace que una vez generada y registrada una transacción en
un sitio del sistema, inmediatamente se actualicen las copias de la información
que se guardan en los otros sitios. Este modelo, aumenta la opción de acceso a
datos desde cualquier punto, aumentando la disponibilidad del sistema. El mayor
problema de este modelo es que debe garantizarse canales de comunicación
entre los nodos en todo momento, de tal manera que se asegure la copia de los
fragmentos cuando la transacción se realice, de lo contrario el sistema cae en un
estado de invalidez de información.
2. Maestro-copia. Este modelo permite que la actualización de los sitios pueda

generarse en un periodo de tiempo T después de generarse una t
transacción en un sitio del sistema. Este modelo asume que los datos de
las copias pueden estar diferentes al registro original durante un periodo de
tiempo, sin afectar los procesos del sistema.
El modelo reduce costos de canal de comunicación, ya que este es requerido

durante algunos periodos de tiempo, durante el cual se realizan las
actualizaciones a las replicas del sistema.
3. Maestro - bodega. Este modelo exige la determinación de un sitio, donde se

guardarán las replicas de los datos. Una vez se realice una transacción en un
sitio, inmediata o durante un periodo de tiempo, debe generarse la copia de la
replica en la bodega de datos. Esto hace que las consultas a información que no
se encuentre en el sitio, solo puede hacerse a la bodega de datos.
Este modelo reduce los costos de canales de datos, pero debe asegurarse que el
sitio de la bodega siempre se encuentre accesible.
Capitulo 2. Consultas Distribuidas
El procesamiento de consultas es de suma importancia en bases de datos

centralizadas. Sin embargo, en BDD éste adquiere una relevancia mayor. El
objetivo es convertir transacciones de usuario en instrucciones para manipulación
de datos. No obstante, el orden en que se realizan las transacciones afecta
grandemente la velocidad de respuesta del sistema. Así, el procesamiento de
consultas presenta un problema de optimización en el cual se determina el orden
en el cual se hace la menor cantidad de operaciones. En BDD se tiene que
considerar el procesamiento local de una consulta junto con el costo de
transmisión de información al lugar en donde se solicitó la consulta.
2.1. Objetivo del procesamiento de las consultas

En un sistema de base de datos es posible cambiar la estructura inicial, pero es
algo que puede resultar muy costoso desde el punto de vista de tiempo y dinero.
Por tanto, cuando se presenta una consulta al sistema, es necesario hallar el
mejor método de encontrar la respuesta utilizando la estructura existente de la
base de datos. Existe un gran número de estrategias posibles para procesar una
consulta, especialmente si la estructura es compleja. No obstante, normalmente
vale la pena que el sistema dedique una cantidad importante de tiempo en la
selección de una buena estrategia. El coste de procesar una consulta
normalmente está dominado por el acceso al disco. Pero, en un sistema
distribuido es preciso tener en cuenta otros factores, como son:
El coste de transmisión de datos en la red.

El beneficio potencial que supondría en la ejecución el que varias
localidades procesaran en paralelo partes de la consulta.
La diferencia entre una buena estrategia y una mala, en términos del número de
accesos a disco requeridos y el coste de transmisión de datos en la red, a menudo
es importante, y puede tener varios órdenes de magnitud. Así pues, el tiempo
empleado en elegir una estrategia de procesamiento de consultas merece la pena
incluso para una consulta que se ejecuta sólo una vez.
2.2. Niveles de procesador de consultas

Existen varios medios para calcular la respuesta a una consulta; siempre debe
elegirse una estrategia de procesamiento de consultas que reduzca al mínimo el
tiempo que se requiere para calcular la respuesta. En el caso de sistemas
centralizados, el criterio principal para determinar el coste de una estrategia
específica es el número de accesos al disco. En un sistema distribuido es preciso
tener en cuenta otros factores, como son:
El coste de transmisión de datos en la red.

El beneficio potencial que supondría en la ejecución el que varias

localidades 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.
2.3. Localización de datos

Consideremos una consulta muy sencilla: “Encontrar todas las tuplas de la
relación depósito”. Aunque la consulta es muy simple, de hecho es trivial; su
procesamiento no es trivial, ya que es posible que la relación depósito esté
fragmentada, repetida o las dos cosas. Si la relación depósito está repetida, es
preciso decidir que copia se va a utilizar. Si ninguna de las copias está
fragmentada, se elige la copia que implique costes de transmisión más reducidos.
Pero si una copia está fragmentada, la elección no es tan sencilla, ya que es
preciso calcular varios productos o uniones para reconstruir la relación depósito.
En tal caso, el número de estrategias para este ejemplo sencillo puede ser
grande. De hecho, la elección de una estrategia puede ser una tarea tan compleja
como hacer una consulta arbitraria.
La transparencia de la fragmentación implica que el usuario puede escribir una

consulta como ésta:
σNombre-sucursal = “Riverside” (depósito)
Puesto que depósito está definido como
depósito1 ∪ depósito2
La expresión que resulta del esquema de traducción de nombres es
σNombre-sucursal = “Riverside” (depósito1 ∪ depósito2)
Al emplear las técnicas de optimización podemos simplificar de manera

automática esta expresión. La expresión que resulta es
σNombre-sucursal = “Riverside” (depósito1) ∪ σNombre-sucursal = “Riverside” (depósito2)
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í:
σNombre-sucursal = “Riverside” (depósito1)
Puesto que depósito1 tiene solamente tuplas de pertenecientes a la sucursal

Riverside, podemos eliminar la operación de selección. Calculando
σNombre-sucursal = “Riverside” (depósito2)
Podemos aplicar la definición del fragmento depósito2 para obtener
σNombre-sucursal = “Riverside” ( σNombre-sucursal = “Columbia” (depósito))
Esta expresión es el conjunto vacío, independientemente del contenido de la

relación depósito.
Así, nuestra estrategia final para la localidad Riverside consistirá en devolver

depósito1 como resultado de la consulta.
2.4 Procesamiento de intersección simple
Un aspecto importante de la elección de una estrategia de procesamiento de

consulta es elegir una estrategia de intersección. Considere la expresión
algebraica relacional:
Cliente |x| depósito |x| sucursal
Suponemos que ninguna de las tres relaciones esté repetida o fragmentada y que
cliente está almacenada en la localidad Lc, depósito en la Ld y sucursal en la Lb.
Sea Li la localidad donde se originó la consulta. El sistema debe producir el
resultado en la localidad Li. Entre las posibles estrategias para procesar posibles
estrategias para procesar esta consulta se encuentran en las siguientes:
Enviar copia de las tres relaciones a la localidad Li. Escoger una estrategia
para procesar en forma local la consulta completa en Li.
Enviar una copia de la relación cliente a la localidad Ld y calcular cliente |x|
depósito de Ld. Enviar cliente |x| depósito de Ld a Lb, donde se calcula
(cliente |x| deposito) |x| sucursal. El resultado de esta operación es enviado
a Li.
Pueden elaborarse estrategias similares a la anterior al intercambiar los
papeles de Lc, Ld y Lb.
No puede garantizarse que una estrategia sea la mejor en todos los casos. Entre
los factores que deben tener en cuenta están la cantidad de datos que debe
transmitirse, el costo de transmitir un bloque de datos entre dos localidades
determinadas y la velocidad de procesamiento relativa en cada localidad.
Considerar las dos primeras estrategias mencionadas. Si se envían las tres
relaciones a Li y existen índices para ellas, puede ser necesario volver a crear
esos índices en Li. Esto requiere tiempo extra de procesamiento y más accesos al
disco. Sin embargo, la segunda estrategia tiene la desventaja de que una relación
potencialmente grande (cliente |x| deposito) debe transmitirse desde Ld a Lb. Esta
relación repite los datos del domicilio de un cliente una vez por cada cuenta que
tenga el cliente. Así, la segunda estrategia puede requerir la transmisión de un
volumen mayor que la primera estrategia.
También pueden utilizarse dos estrategias adicionales, la de intersección

utilizando el paralelismo y la estrategia de semi-intersección.
2.5. 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 eferencias 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.
2.6. 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.
CAPITULO 3. 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.
3.1 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 3.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 3.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.
3.2 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.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.
3.3 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 conjunto de escritura (WS). Note que los conjuntos de
lectura y escritura no tienen que ser necesariamente disjuntos. La unión de ambos
conjuntos se le conoce como el conjunto base de la transacción (BS = RS U WS).
Ejemplo 3.4. Los conjuntos de lectura y escritura de la transacción del Ejemplo

3.3 son<
RS[Reservación] = { FLIGHT.STSOLD, FLIGHT.CAP }

WS[Reservación] = { FLIGHT.STSOLD, FC.FNO, FC.DATE, FC.NAME,
FC.SPECIAL }
3.4 Formalización del concepto de transacción
Sea Oij(x) una operación Oj de la transacción Ti la cual trabaja sobre alguna

entidad x ∈ Iread, writeJ C es una operación atómica, esto es, se ejecuta
como una unidad indivisible. Se denota por OSi = U j Oij al conjunto de todas las
operaciones de la transacción Ti. También, se denota por Ni la condición de
terminación para Ti, donde3 ∈ Iabort, commitJ
La transacción Ti es un orden parcial3 G IΣ 3K J3donde
Συµατορια G I J
Para cualesquiera dos operaciones3Oij, Oik ∈ OSi, si Oij = R(x) y Oik = W(x)
para cualquier elemento de datos x, entonces, ó Oij <i Oik ó Oik <i Oij
Παρα τοδο Oij ∈ OSi, Oij <i Ni
Ejemplo 3.3. Considere una transacción simple T que consiste de los

siguientes pasos<
Read( x )
Read( y )
x <−−− x + y
Write( x )
Commit
La especificación de su transacción de acuerdo con la notación formal que se

ha introducido es la siguiente:
Συµατορια G { R(x), R(y), W(x), C }

<i = { (R(x), W(x)), (R(y), W(x)), (W(x), C), (R(x), C), (R(y), C) }
Note que la relación de ordenamiento especifica el orden relativo de todas 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.
3.5. 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).
3.6. 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.
3.7. 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 3.6. Los siguientes son algunos ejemplos de los modelos de transacción
mencionados antes.
General: T1: { R(x), R(y), W(y), R(z), W(x), W(z), W(w), C}

Dos pasos: T2: { R(x), R(y), R(z), W(x), W(y), W(z), W(w), C}
Restringida: T3: { R(x), R(y), W(y), R(z), W(x), W(z), R(w), W(w), C}
Restringida y de dos pasos:
T4: { R(x), R(y), R(z), R(w), W(y), W(x), W(z), W(w), C}
Acción: T3: { [R(x), W(x)], [R(y), W(y)], [R(z), W(z)], [R(w), W(w)], C}
Note que cada par de acciones encerrado en [ ] se ejecuta de manera atómica
3.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.
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).
3.9. 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 25. Un modelo del administrador de transacciones.
Los administradores de transacciones implementan una interfaz para los

programas de aplicación que consiste de los comandos:
Begin_transaction.
Read.
Write.
Commit.
Abort.
En la Figura 26 se presenta la arquitectura requerida para la ejecución

centralizada de transacciones. Las modificaciones requeridas en la arquitectura
para una ejecución distribuida se pueden apreciar en las Figura 26b. En esta
última figura se presentan también los protocolos de comunicación necesarios
para el manejo de transacciones distribuidas
Figura 26. Ejecución centralizada de transacciones.
Figura 26b. Ejecución distribuida de transacciones
3.10 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.
3.10.1 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:
Mantener una bitácora para la recuperación.

Participar en un esquema de control de concurrencia apropiado para
coordinar la 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:
Iniciar la ejecución de la transacción.
Dividir la transacción en varias subtransacciones, las cuales ha de distribuir
en las localidades apropiadas para su ejecución.
Coordinar la terminación de la transacción, ya sea que quede ejecutada o

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

pueden ser:
El fallo total de una localidad.

La interrupción de una línea de comunicación.
Pérdida de mensajes.
Fragmentación de la red.
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.
Elección de dos o más distribuidores centrales en distintos fragmentos.

Actualización de un dato repetido en más de un fragmento de la red.
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ó.
3.11. 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.
3.11.1 Teoría de la seriabilidad
Una calendarización (schedule), también llamado una historia, se define sobre un

conjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado
de la ejecución de las operaciones de las transacciones. La calendarización
puede ser especificada como un orden parcial sobre T.
Ejemplo 1. Considere las siguientes tres transacciones:
T1: Read( x ) T2: Write( x ) T3: Read( x ) Write( x ) Write( y ) Read( y ) Commit
Read( z ) Read( z ) Commit Commit Una calendarización de las acciones de
las tres transacciones anteriores puede ser:
H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 }
Dos operaciones Oij(x) y Okl(x) (i y k no necesariamente distintos) que accesan el

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

de dos operaciones de lectura es insignificante.
Una calendarización completa define el orden de ejecución de todas las
operaciones en su dominio. Formalmente, una calendarización completa STc
definido sobre un conjunto de transacciones T = { T1, T2, ..., Tn } es un orden
parcial G IΣ 3K Jen donde
Συµατορια G Σ 3para todos los i = 1, 2, ..., n

K ⊇ 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 P G I
Συµατορια 3K J3 LG IΣυµατορια L3KL}, es un prefijo de P si
Σ L⊂ Σ
∀ ei ∈ Σ L3e1 K’ e2, si y solamente si, e1 < e2, y
∀ ei ∈ Σ L3si ∃ ej ∈ Σ Cej K ei, entonces, ej Σ L
Las primeras dos condiciones definen a P’ como una restricción de P en el

dominio Σ L3en donde las relaciones de ordenamiento en P se mantienen por P’.
La última condición indica que para cualquier elemento de Σ L3 todos sus
predecesores en Σ deben ser incluidos también en Σ L
Ejemplo 3. La siguiente calendarización es un prefijo de la calendarización del

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

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

historia resultante sobre la base de datos es equivalente a alguna historia serial.
Basada en la relación de precedencia introducida por el orden parcial, es posible
discutir la equivalencia de diferentes calendarizaciones con respecto a sus efectos
sobre la base de datos.
Dos calendarizaciones, S1 y S2, definidas sobre el mismo conjunto de

transacciones T, se dice que son equivalentes si para cada par de operaciones en
conflicto Oij y Okl (i ≠ k), cada vez que Oij <1 Okl, entonces, Oij <2 Okl. A esta
relación se le conoce como equivalencia de conflictos puesto que define la
equivalencia de dos calendarizaciones en término del orden de ejecución relativo
de las operaciones en conflicto en ellas.
Una calendarización S se dice que es serializable, si y solamente si, es

equivalente por conflictos a una calendarización serial.
Ejemplo 5. Las siguientes calendarizaciones no son equivalentes por conflicto:
H1 = { W2(x), R1(x), R3(x), W1(x), C1, W2(y), R3(y), R2(z), C2, R3(z), C3 }
Las siguientes calendarizaciones son equivalentes por conflictos; por lo tanto

H2 es serializable:
H2 = { W2(x), R1(x), W1(x), C1, R3(x), W2(y), R3(y), R2(z), C2, R3(z), C3 }
La función primaria de un controlador de concurrencia es generar una

calendarización serializable para la ejecución de todas las transacciones. El
problema es, entonces, desarrollar algoritmos que garanticen que únicamente se
generan calendarizaciones serializables.
3.11.2 Seriabilidad en SMBD distribuidos
En bases de datos distribuidas es necesario considerar dos tipos de historia para

poder generar calendarizaciones serializables: la calendarización de la ejecución
de transacciones en un nodo conocido como calendarización local y la
calendarización global de las transacciones en el sistema. Para que las
transacciones globales sean serializables se deben satisfacer las siguientes
condiciones:
cada historia local debe ser serializable, y

dos operaciones en conflicto deben estar en el mismo orden relativo en
todas las historias locales donde las operaciones aparecen juntas.
La segunda condición simplemente asegura que el orden de serialización sea el

mismo en todos los nodos en donde las transacciones en conflicto se ejecutan
juntas.
Ejemplo 6. Considere las siguientes tres transacciones:
T1: Read( x ) T2: Read( x ) x ← x M N x ← x . N Write( x ) Write( x ) Commit

Commit Las siguientes historias locales son individualmente serializables (de
hecho son seriales), pero las dos transacciones no son globalmente
serializables.
LH1 = { R1(x), W1(x), C1, R2(x), W2(x), C2 }

LH2 = { R2(x), W2(x), C2, R1(x), W1(x), C1 }
3.11.3. Taxonomía de los mecanismos de control de concurrencia
El criterio de clasificación más común de los algoritmos de control de concurrencia

es el tipo de primitiva de sincronización. Esto resulta en dos clases: aquellos
algoritmos que están basados en acceso mutuamente exclusivo a datos
compartidos (candados) y aquellos que intentar ordenar la ejecución de las
transacciones de acuerdo a un conjunto de reglas (protocolos). Sin embargo, esas
primitivas se pueden usar en algoritmos con dos puntos de vista diferentes: el
punto de vista pesimista que considera que muchas transacciones tienen
conflictos con otras, o el punto de vista optimista que supone que no se presentan
muchos conflictos entre transacciones.
Los algoritmos pesimistas sincronizan la ejecución concurrente de las

transacciones en su etapa inicial de su ciclo de ejecución. Los algoritmos
optimistas retrasan la sincronización de las transacciones hasta su terminación. El
grupo de algoritmos pesimistas consiste de algoritmos basados en candados,
algoritmos basados en ordenamiento por estampas de tiempo y algoritmos
híbridos. El grupo de los algoritmos optimistas se clasifican por basados en

candados y basados en estampas de tiempo (Ver. Figura 27).
Figura 27. Clasificación de los algoritmos de control de concurrencia.
3.11.4 Algoritmos basados en candados
En los algoritmos basados en candados, las transacciones indican sus intenciones

solicitando candados al despachador (llamado el administrador de candados). Los
candados son de lectura (rl), también llamados compartidos, o de escritura (wl),
también llamados exclusivos. Como se aprecia en la tabla siguiente, los candados
de lectura presentan conflictos con los candados de escritura, dado que las
operaciones de lectura y escritura son incompatibles.
rl wl rl si no wl no no En sistemas basados en candados, el despachador es un

administrador de candados (LM). El administrador de transacciones le pasa al
administrador de candados la operación sobre la base de datos (lectura o
escritura) e información asociada, como por ejemplo el elemento de datos que es
accesado y el identificador de la transacción que está enviando la operación a la
base de datos. El administrador de candados verifica si el elemento de datos que
se quiere accesar ya ha sido bloqueado por un candado. Si candado solicitado es
incompatible con el candado con que el dato está bloqueado, entonces, la
transacción solicitante es retrasada. De otra forma, el candado se define sobre el
dato en el modo deseado y la operación a la base de datos es transferida al
procesador de datos. El administrador de transacciones es informado luego sobre
el resultado de la operación. La terminación de una transacción libera todos los
candados y se puede iniciar otra transacción que estaba esperando el acceso al
mismo dato.
3..11.4.1Candados de dos fases (2PL)
En los candados de dos fases una transacción le pone un candado a un objeto

antes de usarlo. Cuando un objeto es bloqueado con un candado por otra
transacción, la transacción solicitante debe esperar. Cuando una transacción
libera un candado, ya no puede solicitar más candados. Así una transacción que
utiliza candados de dos fases se comporta como en la Figura 28. En la primera
fase solicita y adquiere todos los candados sobre los elementos que va a utilizar y
en la segunda fase libera los candados obtenidos uno por uno.
La importancia de los candados de dos fases es que se ha demostrado de
manera teórica que todos las calendarizaciones generadas por algoritmos de
control de concurrencia que obedecen a los candados de dos fases son
serializables.
Puede suceder que si una transacción aborta después de liberar un candado,

otras transacciones que hayan accesado el mismo elemento de datos aborten
también provocando lo que se conoce como abortos en cascada. Para evitar lo
anterior, los despachadores para candados de dos fases implementan lo que se
conoce como los candados estrictos de dos fases en los cuales se liberan todos
los candados juntos cuando la transacción termina (con commit o aborta). El
comportamiento anterior se muestra en la Figura 29.
Figura 28. Gráfica del uso de los candados de dos fases

Figura 29. Comportamiento de los candados de dos fases estrictos.
3.11.4.2 Candados de dos fases centralizados
En sistemas distribuidos puede que la administración de los candados se dedique

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

dos fases estrictos.
La crítica más fuerte a los algoritmos centralizados es el "cuello de botella" que se

forma alrededor del nodo central reduciendo los tiempos de respuesta de todo el
sistema. Más aún, su disponibilidad es reducida a cero cuando se presentan fallas
en el nodo central.
3.11.4.3 Candados de dos fases distribuidos
En los candados de dos fases distribuidos se presentan despachadores en cada

nodo del sistema. Cada despachador maneja las solicitudes de candados para los
datos en ese nodo. Una transacción puede leer cualquiera de las copias replicada
del elemento x, obteniendo un candado de lectura en cualquiera de las copias de
x. La escritura sobre x requiere que se obtengan candados para todas las copias
de x. La comunicación entre los nodos que cooperan para ejecutar una
transacción de acuerdo al protocolo de candados distribuidos de dos fases se
presenta en la Figura 31. Los mensajes de solicitud de candados se envían a
todos los administradores de candados que participan en el sistema. Las
operaciones son pasadas a los procesadores de datos por los administradores de
candados. Los procesadores de datos envía su mensaje de "fin de operación" al
administrador de transacciones coordinador.
3.11.5 Algoritmos basados en estampas de tiempo
A diferencia de los algoritmos basados en candados, los algoritmos basados en

estampas de tiempo no pretenden mantener la seriabilidad por exclusión mutua.
En lugar de eso, ellos seleccionan un orden de serialización a priori y ejecutan las
transacciones de acuerdo a ellas. Para establecer este ordenamiento, el
administrador de transacciones le asigna a cada transacción Ti una estampa de
tiempo única ts( Ti ) cuando ésta inicia. Una estampa de tiempo es un identificador
simple que sirve para identificar cada transacción de manera única. Otra
propiedad de las estampas de tiempo es la monoticidad, esto es, dos estampas de
tiempo generadas por el mismo administrador de transacciones deben ser
monotonicamente crecientes. Así, las estampas de tiempo son valores derivados
de un dominio totalmente ordenado.
Figura 31. Comunicación en candados de dos fases distribuidos
Existen varias formas en que las estampas de tiempo se pueden asignar. Un

método es usar un contador global monotónicamente creciente. Sin embargo, el
mantenimiento de contadores globales es un problema en sistemas distribuidos.
Por lo tanto, es preferible que cada nodo asigne de manera autónoma las
estampas de tiempos basándose en un contador local. Para obtener la unicidad,
cada nodo le agrega al contador su propio identificador. Así, la estampa de tiempo
es un par de la forma:
<contador local, identificador de nodo>
Note que el identificador de nodo se agrega en la posición menos significativa, de

manera que, éste sirve solo en el caso en que dos nodos diferentes le asignen el
mismo contador local a dos transacciones diferentes.
El administrador de transacciones asigna también una estampa de tiempo a todas
las operaciones solicitadas por una transacción. Más aún, a cada elemento de
datos x se le asigna una estampa de tiempo de escritura, wts(x), y una estampa de
tiempo de lectura, 4 6Osus valores indican la estampa de tiempo más grande
para cualquier lectura y escritura de x, respectivamente.
El ordenamiento de estampas de tiempo (TO) se realiza mediante la siguiente

regla:
Regla TO: dadas dos operaciones en conflicto, Oij y Okl, perteneciendo a las
transacciones Ti y Tk, respectivamente, Oij es ejecutada antes de Okl, si y
solamente si, ts(Ti) < ts(Tk). En este caso Ti se dice ser una transacción más
vieja y Tk se dice ser una transacción más joven.
Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente

forma:
for Ri(x) do begin if ts(Ti) < wts( x ) then reject Ri(x) else accept Ri(x) rts(x) ←
ts(Ti) endfor Wi(x) do begin if ts(Ti) < rts(x) and ts(Ti) < wts(x) then reject Wi(x)
else accept Wi(x) wts(x) ← ts(Ti) end. La acción de rechazar una operación,
significa que la transacción que la envió necesita reiniciarse para obtener la
estampa de tiempo más reciente del dato e intentar hacer nuevamente la
operación sobre el dato.
3.11.5.1 Ordenamiento conservador por estampas de tiempo
El ordenamiento básico por estampas de tiempo trata de ejecutar una operación

tan pronto como se recibe una operación. Así, la ejecución de las operaciones es
progresiva pero pueden presentar muchos reinicios de transacciones. El
ordenamiento conservador de estampas de tiempo retrasa cada operación hasta
que exista la seguridad de que no será reiniciada. La forma de asegurar lo anterior
es sabiendo que ninguna otra operación con una estampa de tiempo menor puede
llegar al despachador. Un problema que se puede presentar al retrasar las
operaciones es que esto puede inducir la creación de ínter bloqueos (deadlocks).
3.11.5.2 Ordenamiento por estampas de tiempo múltiples
Para prevenir la formación de ínter bloqueos se puede seguir la estrategia

siguiente. Al hacer una operación de escritura, no se modifican los valores
actuales sino se crean nuevos valores. Así, puede haber copias múltiples de un
dato. Para crear copias únicas se siguen las siguientes estrategias de acuerdo al
tipo de operación de que se trate:
Una operación de lectura Ri(x) se traduce a una operación de lectura de x de una

sola versión encontrando la versión de x, digamos xv, tal que, ts(xv) es la estampa
de tiempo más grande que tiene un valor menor a ts(Ti).
Una operación de escritura Wi(x) se traduce en una sola versión, Wi(xw), y es

aceptada si el despachador no ha procesado cualquier lectura Rj(xr), tal que, ts(Ti)
< ts(xr) < ts(Tj)
3.11.6 Control de concurrencia optimista
Los algoritmos de control de concurrencia discutidos antes son por naturaleza

pesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones
son muy frecuentes y no permiten el acceso a un dato si existe una transacción
conflictiva que accesa el mismo dato. Así, la ejecución de cualquier operación de
una transacción sigue la secuencia de fases: validación (V), lectura (R), cómputo
(C) y escritura (W) (ver Figura 6.6a). Los algoritmos optimistas, por otra parte,
retrasan la fase de validación justo antes de la fase de escritura (ver Figura 32).
De esta manera, una operación sometida a un despachador optimista nunca es
retrasada.
Las operaciones de lectura, cómputo y escrita de cada transacción se procesan

libremente sin actualizar la base de datos corriente. Cada transacción inicialmente
hace sus cambios en copias locales de los datos. La fase de validación consiste
en verificar si esas actualizaciones conservan la consistencia de la base de datos.
Si la respuesta es positiva, los cambios se hacen globales (escritos en la base de
datos corriente). De otra manera, la transacción es abortada y tiene que reiniciar
Figura 32. Fases de la ejecución de una transacción a) pesimista, b)

optimista.
Los mecanismos optimistas para control de concurrencia fueron propuestos

originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de
mecanismos las estampas de tiempo se asocian únicamente con las
transacciones, no con los datos. Más aún, las estampas de tiempo no se asignan
al inicio de una transacción sino justamente al inicio de su fase de validación. Esto
se debe a que las estampas se requieren únicamente durante la fase de
validación.
Cada transacción Ti se subdivide en varias subtransacciones, cada una de las

cuales se puede ejecutar en nodos diferentes. Sea Tij una subtransacción de Ti
que se ejecuta en el nodo j. Supongamos que las transacciones se ejecutan de
manera independiente y ellas alcanzan el fin de sus fases de lectura. A todas las
subtransacciones se les asigna una estampa de tiempo al final de su fase de
lectura. Durante la fase de validación se realiza una prueba de validación, si una
transacción falla, todas las transacciones se rechazan.
La prueba de validación se realiza con una de las siguientes reglas:
Si todas las transacciones Tk, tales que, ts( Tk ) < ts( Tij ), han terminado su fase
de escritura antes que Tij ha iniciado su fase de lectura entonces la validación
tiene éxito. En este caso la ejecución de las transacciones es completamente
serial como se muestra en la Figura 7a.
Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su
fase de escritura mientras Tij está en su fase de lectura, entonces, la validación
tiene éxito si WS(Tk ) ∩ RS(Tij ) G ∅ En este caso, las fases de lectura y escritura
se traslapan, como se muestra en la Figura 7b, pero Tij no lee datos que son
escritos por Tk.
Si existe alguna transacción Tk, tal que, ts( Tk ) < ts( Tij ) y la cual completa su
fase de lectura antes que Tij termine su fase de lectura, entonces, la validación
tiene éxito si WS(Tk ) ∩ RS(Tij ) = ∅ y WS(Tk 6 ∩ WS(Tij ) = ∅ En este caso, las
fases de lectura se traslapan, como se muestra en la Figura 33, pero las
transacciones no accesan datos comunes.
Figura 33. Casos diferentes de las pruebas de validación para control de

concurrencia optimista.
Capitulo 4. Catalogo
4.1. Conceptos básicos
Existe un elemento denominado Catálogo, que es imprescindible conocer si se

quiere llegar a ser experto en el manejo de cualquier SGBD (Sistema de gestión
de base de datos). El catálogo guarda la información del esquema de la base de
datos y es gracias a él que se pueden compartir los esquemas de dominio, y
definir las relaciones de integridad y de datos.
Comprender la estructura del catálogo, debe de ser un objetivo de todo
administrador y analista que quiera conocer el comportamiento de la base de
datos. Para poder llegar a solucionar problemas de definición de datos, de
rendimiento u optimización es necesario conocer las características del motor, la
forma como se comporta en determinada plataforma e incluso sus deficiencias.
En un sistema distribuido, el catálogo del sistema incluirá no solo los datos

usuales del catálogo con relación a las varrels base, vistas, autorizaciones, etc.,
sino también toda la información de control necesaria para permitir que el sistema
proporcione la independencia de ubicación, fragmentación y replicación necesaria.
Surge entonces un interrogante ¿Dónde y cómo debe ser almacenado el propio
catálogo?. A continuación se muestran las posibilidades:
4.2. Centralizado
El catálogo total es almacenado exactamente una vez en un sitio central.
4.3. Completamente replicado
El catálogo total es almacenado por completo en cada uno de los sitios.
4.4. Dividido
Cada sitio mantiene su propio catálogo de los objetivos que están almacenados
en ese sitio. El catálogo total es la unión de todos los catálogos locales disjuntos.
4.5. Combinación de centralizado y dividido
Cada sitio mantiene su propio catálogo local, como en el punto 4.4; además, un
único sitio central mantiene una copia unificada de todos esos catálogos locales,
como en punto 4.2
Cada uno de los enfoques mencionados anteriormente, tiene sus propios

problemas. El enfoque centralizado viola el objetivo de “no dependencia de un
sitio central”. El enfoque completamente replicado sufre una pérdida de
autonomía, ya que cada actualización del catálogo tiene que ser propagada por
cada uno de los sitios. El enfoque dividido eleva el costo de operaciones que no
son locales. La combinación de centralizado y dividido es más eficiente que el
dividido, pero viola nuevamente el objetivo de no dependencia de un sitio central,
por lo tanto, en la práctica los sistemas no usan ninguno de los enfoque antes
mencionados. A manera de ejemplo describimos el enfoque usado en R* (donde
R* es un prototipo tomado como referencia).
Para explicar la forma en que está estructurado el catálogo de R*, es necesario

primero decir algo acerca del nombramiento de objetos en R*. Este
nombramiento es importante para los sistemas distribuidos en general, ya que la
posibilidad de que los sitios distintos X y Y, puedan tener un objeto, digamos una
varrel llamada A, implica que sería necesario algún mecanismo – por lo general la
calificación por nombre de sitio – para “eliminar la ambigüedad” (es decir,
garantizar la unicidad de nombres a nivel de sistema). Por lo tanto, lo que se
necesita es un medio para transformar los nombres conocidos por los usuarios a
sus nombres correspondientes conocidos por el sistema.
Este es el enfoque de R* para este problema. R* primero distingue entre el

nombre común de un objeto, que es el nombre por el cual los usuarios hacen
normalmente referencia al objeto ( por ejemplo una instrucción SELECT de SQL),
y su nombre a nivel de sistema, que es identificador interno globalmente único
para el objeto. Los nombres a nivel del sistema tienen cuatro componentes:
ID del creador (el ID del usuario que creó el objeto)

ID del sitio del creador (el ID del sitio en el cual se dio la operación
CREATE)
Nombre local(el nombre del objeto sin calificativos) y
ID del sitio de nacimiento (el ID del sitio en el cual se almacenó inicialmente
el objeto).
Los IDs de usuario son únicos dentro del sito en el cual y los IDs del sitio son
únicos a nivel global. Por lo tanto, el nombre a nivel de sistema de
MARIO @ NEWAYORK . STATS LONDRES

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

O
SELECT … FROM MSTATS…;
En el primer caso (al usar el nombre local), el sistema infiere el nombre a nivel
sistema suponiendo todos los valores predeterminados obvios; es decir que el
objeto fue creado por este usuario, que fue creado en este sitio y que fue
guardado inicialmente en este sitio.
En el segundo caso (al usar el sinónimo), el sistema determina el nombre a nivel

de sistema consultando la tabla sinónimos relevante. Las tablas del sinónimos
pueden ser vistas como el primer componente del catálogo; cada sitio mantiene
un conjunto de esas tablas para los usuarios que se sabe que están en ese sitio y
transforma los sinónimos conocidos para ese usuario en los nombres a nivel de
sistema correspondientes. Además en las tablas de sinónimos cada sitio
mantiene:
1. Una entrada de catálogo para cada objeto nacido en este sitio;

2. Una entrada de catálogo para cada objeto almacenado actualmente en
ese sitio.
Supongamos que ahora el usuario emite una solicitud que hace referencia al
sinónimo MSTATS. Primero, el sistema busca el nombre a nivel sistema
correspondiente en la tabla de sinónimos adecuada (una simple búsqueda local),
Ahora ya sabe el sitio de nacimiento(es decir Londres en el ejemplo) y puede
consultar el catálogo de Londres (y se supone, de manera general, que será una
búsqueda renota; el primer acceso remoto). El catálogo de Londres contendrá una
entrada para ese objeto gracias al punto 1 anterior. Si el objeto está todavía en
Londres ya habrá sido encontrado. Sin embargo, si el objeto ha emigrado
(digamos) a Los Ángeles, entonces la entrada de catálogo en Londres lo dirá y por
lo tanto, el sistema podrá ahora consultar al catálogo de Los Ángeles (segundo
acceso remoto). Y el catálogo de los Ángeles contendrá una entrada para los
objetos gracias al punto 2 anterior. Por lo tanto, ha sido encontrado en, como
máximo, dos accesos remotos.
Además, si el objeto emigra nuevamente, digamos a San Francisco, entonces el

sistema:
Insertará una entrada en el catálogo de San Francisco;
Borrará la entrada del catálogo de los Ángeles;
Actualizará la entrada del catálogo de Londres para que se apunte a San
Francisco en lugar de Los Ángeles.
El efecto neto es que el objeto todavía puede ser encontrado en dos accesos
remotos, como máximo. Y este es un esquema completamente distribuido; no hay
un sitio con catálogo central y no hay punto alguno de falla dentro del sistema.
UNIDAD 3
OTROS MODELOS DE BASES DE DATOS
Capítulo 1. Bases de datos orientadas a objetos
1.1 Introducción
Los sistemas de bases de datos orientados a objetos tienen sus orígenes en los
lenguajes de programación orientados a objetos. La idea fundamental es que el
usuario no debería tener que batallar con construcciones orientadas al
computador tales como registros y campos, sino más bien debería poder manejar
objetos (y operaciones) que se asemejen más a sus equivalentes en el mundo
real. Por ejemplo, en vez de pensar en términos de una tupla DEPTO junto con un
conjunto de tuplas EMP, las cuales incluyen valores de clave ajena que hacen
referencia a esa tupla DEPTO, el usuario debería poder pensar directamente en
un "objeto" departamento que contenga en realidad un conjunto de "objetos"
empleado. Y en vez de (por ejemplo) tener que insertar una tupla en la relación
EMP con un valor apropiado de NUMDEPTO (la clave ajena), el usuario debería
ser capaz de crear en forma directa un nuevo objeto empleado e incluirlo en el
objeto departamento pertinente también en forma directa. Dicho de otro modo, la
idea fundamental es elevar el nivel de abstracción.
La elevación del nivel de abstracción es sin duda un objetivo deseable, y el

paradigma de la orientación a objetos ha tenido considerable éxito en alcanzar
ese objetivo en el campo de los lenguajes de programación. Por tanto, es natural
preguntar si es posible aplicar el mismo paradigma en el área de las bases de
datos. Es más, la idea de manejar una base de datos formada por "objetos
encapsulados" (por ejemplo, un objeto dependencia que "sabe qué significa"
añadir un empleado o cambiar al gerente o recortar el presupuesto), en vez de
tener que entender relaciones, actualizaciones de tuplas, claves ajenas, etcétera,
es desde luego mucho más atractiva y “fácil” desde el punto de vista del usuario,
al menos en lo superficial.
Paradigma de orientación a objetos (oo)

En un ambiente OO, el software se organiza como un conjunto de objetos
discretos que incorporan tanto su estructura como su comportamiento, en
contraste con ambientes tradicionales en donde estas dos características se
encuentran separadas.
Los primeros intentos en aplicar la orientación a objetos al ambiente de bases de

datos fueron mediante la construcción de interfaces como una capa externa a los
SABDs relaciónales.
Uno de los problemas que se tienen actualmente es la falta de estándares en la
concepción y definición de términos. Sin embargo, a continuación se van a
introducir los conceptos mínimos, que se consideran fundamentales en la
aplicación de este paradigma a la tecnología de bases de datos.
1.2 Conceptos básicos:
En esta sección se presentan algunos de los términos y conceptos principales del

enfoque 00, como los objetos mismos (por supuesto), las clases, métodos,
mensajes y jerarquías de clases. También relacionaremos estas ideas con
términos y conceptos más familiares siempre que sea posible o apropiado. De
hecho, quizá resulte útil mostrar antes que nada una correspondencia burda entre
los términos OO y los términos de programación tradicional:
Término OO Término en programación
Objeto variable
Clase tipo
Método función
Mensaje llamada
Jerarquía de clases jerarquía de tipos
1.2.1 Objetos
Antes de entrar en detalles, es bueno advertir que en el mundo de los objetos no

se encuentra el tipo de precisión al que estamos acostumbrados en el mundo
relacional. Además, muchos conceptos de objetos –o las definiciones publicadas
de esos objetos- son bastante imprecisos y hay muy poco consenso verdadero y
mucho desacuerdo, incluso en el nivel más básico. En particular, no hay un
“modelo de datos de objetos” abstracto ni formalmente definido, y tampoco hay
consenso sobre un modelo informal.
¿Qué es un objeto? Todo.
Es un principio básico del enfoque de objetos que “todo es un objeto” (a veces

“todo es un objeto de primera clase”). Algunos objetos son inmutables: ejemplos
de esto pueden ser los enteros y las cadenas de caracteres. Otros objetos son
mutables; algunos ejemplos podrían ser los objetos de departamento y empleado.
Por lo tanto, en la terminología tradicional, los objetos inmutables corresponden a
los valores y los objetos mutables corresponden a las variables.
Todo objeto tiene un tipo (el término en objetos es clase). A los objetos
individuales con frecuencia se les llama específicamente ejemplares (instancias)
de objeto, para distinguirlos con claridad del tipo o clase del objeto
correspondiente. El término tipo se utiliza en su sentido usual de lenguaje de
programación; por lo tanto, en particular en este término se incluye el conjunto de
operadores (el término en el entorno de objetos es métodos) que pueden ser
aplicados a los objetos de ese tipo.
1.2.2 Polimorfismo.
El polimorfismo es otro de los pilares fundamentales de la programación orientada

a objetos. Es la capacidad de almacenar objetos de un determinado tipo en
variables de tipos antecesores del primero a costa, claro está, de sólo poderse
acceder a través de dicha variable a los miembros comunes a ambos tipos. Sin
embargo, las versiones de los métodos virtuales a las que se llamaría a través de
esas variables no serían las definidas como miembros del tipo de dichas variables,
sino las definidas en el verdadero tipo de los objetos que almacenan.
1.2.3 Herencia.
El mecanismo de herencia es uno de los pilares fundamentales en los que se

basa la programación orientada a objetos. Es un mecanismo que permite definir
nuevas clases a partir de otras ya definidas de modo que si en la definición de una
clase indicamos que ésta deriva de otra, entonces la primera -a la que se le suele
llamar clase hija- será tratada por el compilador automáticamente como si su
definición incluyese la definición de la segunda –a la que se le suele llamar clase
padre o clase base.
1.2.4 Encapsulación.
Ya hemos visto que la herencia y el polimorfismo son dos de los pilares

fundamentales en los que se apoya la programación orientada a objetos. Pues
bien, el tercero es la encapsulación, que es un mecanismo que permite a los
diseñadores de tipos de datos determinar qué miembros de los tipos pueden ser
utilizados por otros programadores y cuáles no. Las principales ventajas que ello
aporta son:
Se facilita a los programadores que vayan a usar el tipo de dato

(programadores clientes) el aprendizaje de cómo trabajar con él, pues se le
pueden ocultar todos los detalles relativos a su implementación interna y
sólo dejarle visibles aquellos que puedan usar con seguridad. Además, así
se les evita que cometan errores por manipular inadecuadamente
miembros que no deberían tocar.
Se facilita al creador del tipo la posterior modificación del mismo, pues si

los programadores clientes no pueden acceder a los miembros no visibles,
sus aplicaciones no se verán afectadas si éstos cambian o se eliminan.
Gracias a esto es posible crear inicialmente tipos de datos con un diseño
sencillo aunque poco eficiente, y si posteriormente es necesario
modificarlos para aumentar su eficiencia, ello puede hacerse sin afectar al
código escrito en base a la no mejorada de tipo.
La encapsulamiento de objetos u ocultación de la información es sin duda una

buena idea en muchos casos: es evidente que los conceptos gemelos de a)
ocultar los detalles irrelevantes a la vista del usuario (con lo cual es posible alterar
esos detalles, cuando sea necesario, en una forma controlada y relativamente
poco difícil) y b) ofrecer un acceso disciplinado a objetos sólo a través de una
interfaz pública, son claramente apropiados para muchos usuarios y muchas
aplicaciones. Pero hay que tener en cuenta que siempre existirá la necesidad de
obtener acceso a los datos en formas no previstas para realizar consultas
especiales, razón por la cual la idea de sólo poder operar a través de métodos
predefinidos no es aceptable en algunas situaciones. Los sistemas OO tienden a
ser demasiado rígidos en este aspecto.
La encapsulación se consigue añadiendo modificadores de acceso en las

definiciones de miembros y tipos de datos. Estos modificadores son partículas que
se les colocan delante para indicar desde qué códigos puede accederse a ellos,
entendiéndose por acceder el hecho de usar su nombre para cualquier cosa que
no sea definirlo, como llamarlo si es una función, leer o escribir su valor si es un
campo, crear objetos o heredar de él si es una clase, etc
1.3 Arquitectura de administrador de sistemas de BDOO.
La estructura de las bases de datos orientadas a objetos no presenta la

uniformidad de las bases de datos relaciónales. Para construir una estructura
física fácil de mantener, comúnmente los objetos se representan así:
Determinadas clases se tratan como clases básicas de bloques que se

construyan, que el sistema de computadores implemente directamente.
Comúnmente, las clases básicas corresponden a tipos de datos de lenguajes de
programación estándar, tales como entero, flotante, carácter y cadena.
Las instancias de clases que no son básicas se representan así:
Las variables se representan por campos de un tipo de registro. Cada campo

contiene el valor del objeto para instancias de las clases básicas, o bien el
identificador del objeto para instancias de las clases que no son básicas.
Las variables con un conjunto de valores se representan por una lista enlazada de
los objetos que son miembros del conjunto.
La estructura física hace que sea posible utilizar registros de longitud fija para
implementar una base de datos orientada a objetos, aunque la modificación del
esquema puede complicar esto.
Cuando la relación de contenido es jerárquica, el esquema de base de datos para

una base de datos orientada a objetos puede representarse utilizando el modelo
relacional anidado.
No todas las variables encajan convenientemente en la estructura que se ha

descrito. Algunas de las aplicaciones que se citan incluyen tipos de datos
altamente especializados que son grandes físicamente y que, por razones
prácticas, normalmente se manipulan mediante programas de aplicación que no
son parte del conjunto de métodos con las clases:
Datos de texto. El texto, normalmente se trata como una cadena de bytes que
manipulan los editores y formateadores.
Datos de audio. Comúnmente, los datos de audio son una representación
comprimida digitalizada del habla que manejan aplicaciones de software
separadas.
Datos de video y gráficos. Los datos de video pueden representarse como un
mapa de bytes o como un conjunto de líneas, cajas y otros objetos geométricos.
Aunque algunos datos gráficos a menudo se gestionan dentro del sistema de
base de datos, en muchos casos se utilizan aplicaciones de software especiales.
Las variables que contienen datos de los tipos anteriores, con frecuencia se
denominan campos largos, debido a que una implementación relacional de
objetos que contengan estas variables requiere registros que contengan campos
cuya longitud pueda ser de varios mega bites. Un campo largo se almacena en un
archivo especial (o conjunto de archivos) reservado para almacenamiento de
campos largos.
El método más ampliamente utilizado para acceder a campos largos es el método

de verificación de resultados de salida (checkout)/verificación de datos de entrada
(checkin). El usuario comprueba (checkout) la copia de un objeto con campo
largo, opera sobre esta copia utilizando programas de aplicación de propósito
especial y comprueba la copia modificada (checkin). Las nociones de verificación
de resultados de salida (checkout) y verificación de datos de entrada (checkin)
corresponden aproximadamente a una lectura y a una escritura. Sin embargo, el
resultado de la operación de verificación de datos de entrada normalmente no es
una escritura sino más bien la creación de una nueva versión.
1.4 Sistema administradores de bases de datos orientadas a objetos (SABD-

OO)
La primera vez que se habla del concepto de un SABD-OO se remonta al año

1983 con una propuesta de G. Copeland y D. Maier, en la cual sugieren construir
tal SABD a partir del lenguaje de programación Smalltalk y con la colaboración de
miembros del Oregon Graduate Center. De este prototipo se desarrolla un
producto y se comercializa en 1988 por Servio Logia, bajo el nombre de
GemStone
Por otra parte, en ese mismo año, la compañía Hewlett Packard implementa un
proyecto bajo el nombre de Iris.
A pesar de que aun no existe un consenso de lo que debe ser un SABD-OO,

existen algunas características mínimas que deben ser satisfechas. En efecto, un
SABD para ser considerado con una etiqueta de orientación a objetos, debe
satisfacer al menos los siguientes criterios:
Debe ser un SABD en el sentido tradicional

Debe ser un sistema orientado a objetos
De esta forma, un SAGD-OO debe satisfacer las reglas que aparecen en la figura
siguiente:
Reglas de bases de datos

El sistema debe:
Asegurar la persistencia de los datos.
Poder administrar en forma eficiente una jerarquía de memorias.
Permitir a los usuarios manipular los datos en forma concurrente.
Permitir al usuario consultar la base en forma natural y sencilla.
Permitir la administración de objetos complejos.
Reglas de orientación a objetos

Los objetos deben tener una identidad independiente de su valor.
El sistema debe además:
Permitir la noción de encapsulamiento.
Agrupar los objetos en clases o poder establecer tipos.
Definir una jerarquía de clases o de tipos.
Permitir la programación completa de las aplicaciones.
Permitir la extensión de las clases o tipos predefinidos por parte del
usuario.
1.5 El sistema Postgres
Para referenciar uno de los productos que trabajan este tipo de bases de datos
hemos tomado el proyecto Postgres. El proyecto Postgres- Post Ingres- inicia en
1986 como una extensión del SABD Ingres. Ha sido escrito en el lenguaje de
programación C y consta de 180000 líneas de código (STON91)
Postgres se apoya en la idea de extender el modelo relacional con mecanismos

generales que permitan el soporte de objetos complejos, así como implementar
jerarquías de objetos. Entre los mecanismos, se pueden mencionar los tipos de
datos abstractos, los datos de tipo procedimiento y las reglas.
Una base datos en Postgres se puede ver como un conjunto de tablas. El tipo de
un atributo puede ser atómico: entero, punto flotante, booleano, date, o bien
estructurado: arreglos o procedimientos.
Entre los objetivos principales del sistema Postgres de pueden mencionar los
siguientes:
Mejorar la administración de los objetos complejos

Permitir la definición de nuevos tipos de datos, nuevos operadores y
nuevos métodos de acceso.
Brindar mecanismos primarios para la definición de bases de datos.
Mejorar la seguridad de funcionamiento.
1.6 Lenguaje de modelado unificado (UML)
1.6.1 Introducción
La intención de este capítulo no es la de hacer un estudio detallado de Uml, es tan

solo motivar al lector a que con base en los temas aquí tratados pueda consultar
textos avanzados sobre la temática y su relación con las bases de datos-
Uml es un lenguaje de modelamiento para la especificación, visualización,

construcción y documentación de los artefactos de un proceso de sistema
intensivo. Incluye dentro de otras las siguientes características:
Dentro de un proceso de sistema intensivo, un método es aplicado para
llegar o evolucionar un sistema
Como un lenguaje, es usado para la comunicación. Es decir, un medio
para capturar el conocimiento (semánticas) respecto a un tema y
expresar el conocimiento (sintaxis) resguardando el tema propósito de la
comunicación. El tema es el sistema en estudio.
Como un lenguaje para modelamiento, se enfoca en la comprensión de
un tema a través de la formulación de un modelo del tema (y su contexto
respectivo). El modelo abarca el conocimiento cuidando del tema, y la
apropiada aplicación de este conocimiento constituye inteligencia.
Cuidando la unificación, integra las mejores prácticas de la ingeniería de
la industria tecnológica y sistemas de información pasando por todos os
tipos de sistemas (software y no - software), dominios (negocios versus

software) y los procesos de ciclo de vida.
En cuanto a cómo se aplica para especificar sistemas, puede ser usado
para comunicar "qué" se requiere de un sistema y "cómo" un sistema
puede ser realizado.
En cuanto a cómo se aplica para visualizar sistemas, puede ser usado
para describir visualmente un sistema antes de ser realizado.
En cuanto a cómo se aplica para construir sistemas, puede ser usado
para guiar la realización de un sistema similar a los "planos".
En cuanto a cómo se aplica para documentar sistemas, puede ser usado
para capturar conocimiento respecto a un sistema a lo largo de todo el
proceso de su ciclo de vida.
Uml no es:
Un lenguaje de programación visual, sino un lenguaje de modelamiento
visual
Una herramienta o depósito de especificación, sino un lenguaje para
modelamiento de especificación.
Un proceso, sino que habilita procesos.
1.6.2 UML, ¿Método o Lenguaje de Modelado?

UML es un lenguaje para hacer modelos y es independiente de los métodos de
análisis y diseño. Existen diferencias importantes entre un método y un lenguaje
de modelado. Un método es una manera explícita de estructurar el pensamiento y
las acciones de cada individuo. Además, el método le dice al usuario qué hacer,
cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de
modelado carece de estas instrucciones. Los métodos contienen modelos y esos
modelos son utilizados para describir algo y comunicar los resultados del uso del
método.
1.6.2.1 Elementos de Uml:
Diagramas: Los diagramas son las gráficas que describen el contenido de una
vista. UML tiene nueve tipos de diagramas que son utilizados en combinación
para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases,
de objetos, de estados, de secuencia, de colaboración, de actividad, de
componentes y de distribución.
Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas

son los elementos de modelo que representan conceptos comunes orientados a
objetos, tales como clases, objetos y mensajes, y las relaciones entre estos
conceptos incluyendo la asociación, dependencia y generalización. Un elemento
de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el
mismo significado y simbología.
Reglas o Mecanismos generales: Proveen comentarios extras, información o

semántica acerca del elemento de modelo; además proveen mecanismos de
extensión para adaptar o extender UML a un método o proceso específico,
organización o usuario
1.6.2.2 Utilidad de UML
UML es un lenguaje para modelamiento de propósito general evolutivo,
ampliamente aplicable, que puede ser soportado por diferentes herramientas e
industrialmente estandarizado. Se aplica a una multitud de diferentes tipos de
sistemas, dominios, y métodos o procesos.
Como lenguaje de propósito general, se enfoca en el corazón de un
conjunto de conceptos para la adquisición, compartición y utilización de
conocimientos emparejados con mecanismos de extensión.
Como un lenguaje para modelamiento ampliamente aplicable, puede ser
aplicado a diferentes tipos de sistemas (software y no - software),
dominios (negocios versus software) y métodos o procesos.
Como un lenguaje para modelamiento soportable por herramientas, las
herramientas ya están disponibles para soportar la aplicación del
lenguaje para especificar, visualizar, construir y documentar sistemas.
Como un lenguaje para modelamiento industrialmente estandarizado, no
es un lenguaje cerrado, propiedad de alguien, sino más bien, un
lenguaje abierto y totalmente extensible reconocido por la industria.
Mejores tiempos totales de desarrollo (de 50 % o más).
Modelar sistemas (y no sólo de software) utilizando conceptos
orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de
misión crítica.
Crear un lenguaje de modelado utilizado tanto por humanos como por
máquinas.
Mejor soporte a la planeación y al control de proyectos.
Alta reutilización y minimización de costos.
UML posibilita la captura, comunicación y nivelación de conocimiento estratégico,
táctico y operacional para facilitar el incremento de valor, aumentando la calidad,
reduciendo costos y reduciendo el tiempo de presentación al mercado; manejando

riesgos y siendo proactivo para el posible aumento de complejidad o cambio.
1.6.3 Una perspectiva de uml

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

Un Caso de Uso es un documento narrativo que describe a los actores utilizando
un sistema para satisfacer un objetivo. Es una historia o una forma particular de
usar un sistema. Los casos de uso son requisitos, en particular requisitos
funcionales.
El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple
para modelar los requisitos del sistema desde la perspectiva del usuario. Los
Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona
actualmente, o cómo los usuarios desean que funcione. No es realmente una
aproximación a la orientación a objetos; es realmente una forma de modelar
procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de
sistemas orientado a objetos. Los casos de uso son generalmente el punto de
partida del análisis orientado a objetos con UML.
El modelo de casos de uso consiste en actores y casos de uso. Los actores
representan usuarios y otros sistemas que interaccionan con el sistema. Se
dibujan como "muñecos" de palo. Actualmente representan el tipo de usuario, no
una instancia de usuario. Los casos de uso representan el comportamiento del
sistema, los escenarios que el sistema atraviesa en respuesta a un estímulo desde
un actor. Se dibujan como elipses.
Figura 35: Modelado de Casos de Uso.

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

El objetivo final en cualquier diseño de software es satisfacer los requisitos del
usuario para el sistema. Estos requisitos pueden ser requisitos de software,
requisitos de productos, o requisitos de pruebas. La meta de capturar y comprobar
los requisitos del usuario es asegurar que todos los requisitos son completados por
el diseño, y que el diseño es acorde con los requisitos especificados.
Muchas veces los requisitos del sistema ya existen en forma de documentos de
requisitos. Los casos de uso se utilizan para correlacionar cada escenario con los
requisitos que completa. Si los requisitos no existen, modelar el sistema a través
de los Casos de Uso, permite el descubrimiento de estos requisitos.
1.6.3.3 Organización de Diagramas de Casos de Uso

Durante el análisis de negocio (business) del sistema, puedes desarrollar un
modelo de caso de uso para este sistema, y construir paquetes para representar
los varios dominios de negocio (business) del sistema. Puedes descomponer cada
paquete con un Diagrama de Caso de Uso que contenga los Casos de Uso de un
dominio, con interacciones de actor.
1.6.3.4 Modelar secuencias alternas a través de la relación "Extiende"
(extends)
Típicamente, uno modela cada Caso de Uso con una secuencia normal de
acciones. El usuario entonces considera condiciones "que si" para cada paso, y
desarrolla Casos de Uso basados en estas secuencias alternas de eventos. Las
secuencias alternas se modelan en casos de uso separados, los cuales están
relacionados con el caso de uso original mediante una relación "Extiende"
(extends). Las relaciones Extiende (extends) pueden ser pensadas como un caso
de uso equivalente a herencia, en el cual el caso de uso extendido, hereda y
modifica el comportamiento del caso de uso original.
1.6.3.5 Eliminar el modelado redundante a través de la relación "Usa" (uses)
Para eliminar el modelado redundante de buena parte del comportamiento que
aparezca en varios casos de uso, la parte del comportamiento puede ser modelada
en un caso de uso separado que está relacionado con los otros casos de uso
mediante la relación "Usa" (uses). La relación Usa (uses) se puede pensar como
un caso de uso equivalente. Ver fig. 36.
Figura 36: Relación caso de uso Extiende (extends) frente a relación de caso
Usa (uses).
1.6.4. Diagramas de Secuencia

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

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

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

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

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

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

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

Implementación
1.6.10 Diseño de Bases de Datos Relacionales -- Una extensión informal de

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

en un diagrama( ver fig. 43) de relación de entidad (ER diagram).
Figura 43: Extensión de UML -- Diseño de Bases de Datos Relacionales con

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

Entidad
1.7 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”.
Capítulo 2. Bodega de datos
2.1 Introducción
Hoy en día se habla mucho del tema de Data Warehousing o Bodega de Datos,
que permite la utilización de los datos de una Organización o un conjunto de ellas,
como soporte en la toma de decisiones.
Está información puede provenir de múltiples fuentes heterogéneas no sólo en

ambiente de computación sino también en formato, ambiente de captura,
significado, etc, información toda esta indispensable en su interpretación y
correcta utilización y que es lo que se conoce como Metadatos.
La función de una Bodega de Datos es la de entregar la información correcta a la

gente indicada en el momento adecuado en el formato correcto.
Cuántos tornillos se vendieron el año pasado en el último trimestre? Quien? En

que Departamentos o ciudades? Cuanto fueron las ventas totales en este
trimestre? Cuáles campañas de publicidad dieron el mejor resultado? Las ventas
se incrementaron como resultado de las campañas de las últimas semanas?
Cuáles son las características de un cliente típico? Cuáles han sido los valores
históricos de la razón ácida, para un conjunto de compañías que conforman un
pool? Cómo es la composición de las cuentas del presupuesto?
Estas son las preguntas a las que la Bodega de Datos tiene respuestas. Sin
embargo vale la pena aclarar que Bodega de Datos no es un proyecto de
implementación de una herramienta de mercadeo. Es una forma de operar dentro
de una organización.
Inicia con el proceso de recolección, transformación y lanzamiento de los datos,

que se conoce como el proceso de Scrubbing. Almacena los metadatos en lo que
se conoce como repositorio y a partir de ahí permite que la información se analice
y se presente en la forma que necesita el usuario.
Los datos pueden ser extractados de grandes aplicaciones en Mainframe o de

múltiples fuentes distribuidas, de ambiente C/S, en ambientes disímiles.
Usualmente los datos son transformados (reformateados o agregados) antes de
ser colocados en la Bodega de Datos.
La problemática de Bodega de Datos difiere de compañía en compañía. Una

puede necesitar una Base de Datos centralizada, mientras que una organización
distribuida a lo largo del país o del mundo puede necesitar de una gran Base de
Datos distribuida.
2.2 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.
2.3 Manejo de los metadatos
El repositorio sirve como un sitio para almacenar los datos de los activos de
información de una organización. Abarca todos los datos de la organización, sin
importar cual es la fuente original y facilita el entendimiento de toda la empresa y

controla la existencia de los recursos de datos existentes.
El repositorio sirve como una guía para definir un ambiente de migración de datos.
Contiene:
El mapeo entre las fuentes y/o la Bodega de Datos objetivo

Requerimientos de traslado de la información
Reglas de negocio
Pista de auditoria
2.4 Acceso y análisis de datos.
Una vez que la Bodega de Datos se ha llenado de información, los usuarios

finales están listos para acceder y analizar los datos. Para dar respuestas a las
necesidades de usuarios finales en cualquier plataforma, se provee de algunas
herramientas especializadas para hacer reportes y queries algunas muy
sofisticadas, para desarrolladores de aplicaciones de oficina y usuarios poderosos
que necesitan revisar datos sumarizados de la Bodega así como crecientes
niveles de detalle.
2.5 Manejo de sistemas
La Base de Datos de la Bodega debe ser frecuentemente mantenida y manejada

por DBA´s para reducir el impacto en el desempeño del sistema y recursos. Par
ser eficiente y productivo, el proceso de Bodega de Datos debe ser automatizado
dentro de un ambiente de producción. Las herramientas necesarias para su
mantenimiento, se clasifican en:
Herramientas de manejos de Base de Datos
Sistemas para manejo de Procesos de Jobs
Resolución de Problemas (Help Desk)
Manejo de Almacenamiento y desempeño
Seguridad
Distribución.
3. Construcción de la bodega de datos
Para abordar un proyecto de Bodega de Datos es necesario hacer el

levantamiento de algunos temas generales de la Organización. Estos se agrupan
en los siguientes tópicos:
3.1 Ambiente actual

Con el objetivo de recomendar el más apropiado curso de acción para construir y

utilizar una Bodega de Datos, es crítico entender el negocio y el ambiente
tecnológico actual de la Organización. Cualquier solución propuesta de Bodega
de Datos debe estar muy orientada por las necesidades del negocio y debe ser
compatible con la arquitectura técnica existente y planteada de la compañía.
3.2 Ambiente de Negocios.
Es indispensable tener el conocimiento exacto sobre el tipo de negocios de la

Organización y el soporte que representa la información dentro de todo su
proceso de toma de decisiones.
3.3 Ambiente técnico
Se debe tener un claro concepto desde una perspectiva técnica de los Sistemas
de Información de la Organización. En este análisis se debe tener claridad del
ambiente técnico actual y futuro a nivel de detalle. Se debe incluir tanto el
aspecto de ambiente hardware: mainframes, servidores, redes., así como
aplicativos y herramientas. Se dará gran foco a los Sistemas de soporte en la
decisión, si existe en la actualidad, como operan, etc.
3.4 Expectativas de los usuarios
El punto es determinante en el éxito de un proyecto de Bodega de Datos puesto

que no hay que perder de vista que Bodega de Datos no es un proyecto
tecnológico, es una forma de Vida de las Organizaciones y como tal, tiene que
contar con el apoyo de todos los usuarios y su convencimiento sobre su bondad.
4. Estrategias recomendadas para diseño de datos
La metodología recomendada es iniciar con un prototipo.
4.1 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.
4.2 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.
4.3 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.
4.4 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.
4.5 Factores de riesgo

Es importante conocerlos para poder monitorearlos. Son éstos:
Expectativas de los usuarios. Se debe trabajar con las expectativas de

los usuarios. Muchas veces el éxito depende de la diferencia entre lo que
los usuarios esperan y lo que ellos perciben que les es entregado. Es
crítico que el equipo de Bodega de Datos comunique las expectativas
acerca de lo que será entregado muy claramente y ayude al usuario final a
entender la naturaleza iterativa de construir una Bodega de Datos.
Experiencia con Bodegas de Datos. Este riesgo se puede reducir con el

uso juicioso de experiencias de proveedores y consultores.
Dirección estratégica. Es relativamente lógico definir un punto de inicio

lógico para la Bodega de Datos. Sin embargo cuando esta primera área se
haya completado, es más difícil identificar áreas para esfuerzos futuros y
asegurar que esos esfuerzos están alineados con los objetivos y
necesidades del negocio. El riesgo se puede mitigar siguiendo la estrategia
recomendada de la Bodega, para entender las necesidades y prioridades
de la información del negocio y desarrollar una implementación de Bodega
de Datos a largo plazo que cumpla con estas propiedades.
5. Minería de Datos
5.1. Introducción
Esta unidad tiene como propósito introducir al lector en los conceptos
fundamentales de la minería de datos y su relación con las bodegas de datos, no
es la intención de profundizar en cada uno de los temas, estos pueden ser
ampliados en la bibliografía recomendada, es necesario que el lector tenga
conocimientos en base de datos relacionales y distribuidas para una mejor
comprensión del tema.
Data Mining, la extracción de información oculta y predecible de grandes bases de

datos, es una poderosa tecnología nueva con gran potencial para ayudar a las
compañías a concentrarse en la información más importante de sus Bases de
Información (Data Warehouse). Las herramientas de Data Mining predicen futuras
tendencias y comportamientos, permitiendo en los negocios tomar decisiones
proactivas y conducidas por un conocimiento acabado de la información
(knowledge-driven). Los análisis prospectivos automatizados ofrecidos por un
producto así van más allá de los eventos pasados provistos por herramientas
retrospectivas típicas de sistemas de soporte de decisión. Las herramientas de
Data Mining pueden responder a preguntas de negocios que tradicionalmente
consumen demasiado tiempo para poder ser resueltas y a los cuales los usuarios
de esta información casi no están dispuestos a aceptar. Estas herramientas
exploran las bases de datos en busca de patrones ocultos, encontrando
información predecible que un experto no puede llegar a encontrar porque se
encuentra fuera de sus expectativas.
Las técnicas de minería de datos se emplean para mejorar el rendimiento de
procesos de negocio o industriales en los que se manejan grandes volúmenes de
información estructurada y almacenada en bases de datos. Por ejemplo, se usan
con éxito en aplicaciones de control de procesos productivos, como herramienta
de ayuda a la planificación y a la decisión en marketing, finanzas, etc.
Asimismo, la minería de datos es fundamental en la investigación científica y
técnica, como herramienta de análisis y descubrimiento de conocimiento a partir
de datos de observación o de resultados de experimentos.
5.2. Los Fundamentos del Data Mining

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

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

El nombre de Data Mining deriva de las similitudes entre buscar valiosa
información de negocios en grandes bases de datos, por ej.: encontrar información
de la venta de un producto entre grandes montos de Gigabytes almacenados,
minar una montaña para encontrar una veta de metales valiosos. Ambos procesos
requieren examinar una inmensa cantidad de material, o investigar
inteligentemente hasta encontrar exactamente donde residen los valores. Dadas
bases de datos de suficiente tamaño y calidad, la tecnología de Data Mining puede
generar nuevas oportunidades de negocios al proveer estas capacidades:
Predicción automatizada de tendencias y comportamientos. Data

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

Las herramientas de Data Mining barren las bases de datos e identifican
modelos previamente escondidos en un sólo paso. Otros problemas de
descubrimiento de modelos incluye detectar transacciones fraudulentas de
tarjetas de créditos e identificar datos anormales que pueden representar
errores de tipeado en la carga de datos.
Las técnicas de Data Mining pueden redituar los beneficios de

automatización en las plataformas de hardware y software existentes y
puede ser implementadas en sistemas nuevos a medida que las
plataformas existentes se actualicen y nuevos productos sean
desarrollados. Cuando las herramientas de Data Mining son implementadas
en sistemas de procesamiento paralelo de alta performance, pueden
analizar bases de datos masivas en minutos. Procesamiento más rápido
significa que los usuarios pueden automáticamente experimentar con más
modelos para entender datos complejos. Alta velocidad hace que sea
práctico para los usuarios analizar inmensas cantidades de datos. Grandes
bases de datos, a su vez, producen mejores predicciones.
Las bases de datos pueden ser grandes tanto en profundidad como en

ancho:
Más columnas. Los analistas muchas veces deben limitar el número de

variables a examinar cuando realizan análisis manuales debido a
limitaciones de tiempo. Sin embargo, variables que son descartadas porque
parecen sin importancia pueden proveer información acerca de modelos
desconocidos. Un Data Mining de alto rendimiento permite a los usuarios
explorar toda la base de datos, sin preseleccionar un subconjunto de
variables.
Más filas. Muestras mayores producen menos errores de estimación y

desvíos, y permite a los usuarios hacer inferencias acerca de pequeños
pero importantes segmentos de población.
5.4. Fases de un Proyecto de Minería de Datos
Los pasos a seguir para la realización de un proyecto de minería de datos son

siempre los mismos, independientemente de la técnica específica de extracción
de conocimiento usada. Ver fig. 45.
Figura 45: Fases de un Proyecto de Minería de Datos

El proceso de minería de datos pasa por las siguientes fases:
Filtrado de datos
Selección de variables
Extracción de conocimiento
Interpretación y evaluación
Si desea obtener una descripción más detallada, puede consultar la

documentación de CRISP-DM. CRISP-DM (CRoss Industry Standard Process for
Data Mining) es un estándar industrial utilizado por más de 160 empresas e
instituciones de todo el mundo, que surge en respuesta a la falta de
estandarización y propone un modelo de proceso general para proyectos de
minería de datos.
5.5. ¿Cómo Trabaja el Data Mining?

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

Para aplicar mejor estas técnicas avanzadas, éstas deben estar totalmente
integradas con el data warehouse así como con herramientas flexibles e
interactivas para el análisis de negocios. Varias herramientas de Data Mining
actualmente operan fuera del warehouse, requiriendo pasos extra para extraer,
importar y analizar los datos. Además, cuando nuevos conceptos requieren
implementación operacional, la integración con el warehouse simplifica la
aplicación de los resultados desde Data Mining. El Data warehouse analítico
resultante puede ser aplicado para mejorar procesos de negocios en toda la
organización, en áreas tales como manejo de campañas promocionales, detección
de fraudes, lanzamiento de nuevos productos, etc.
El punto de inicio ideal es un data warehouse que contenga una combinación de
datos de seguimiento interno de todos los clientes junto con datos externos de
mercado acerca de la actividad de los competidores. Información histórica sobre
potenciales clientes también provee una excelente base para prospecting. Este
warehouse puede ser implementado en una variedad de sistemas de bases
relacionales y debe ser optimizado para un acceso a los datos flexible y rápido.
Un server multidimensional OLAP permite que un modelo de negocios más
sofisticado pueda ser aplicado cuando se navega por el data warehouse. Las
estructuras multidimensionales permiten que el usuario analice los datos de
acuerdo a como quiera mirar el negocio - resumido por línea de producto, u otras
perspectivas claves para su negocio. El server de Data Mining debe estar
integrado con el data warehouse y el server OLAP para insertar el análisis de
negocios directamente en esta infraestructura. Un avanzado, metadata centrado
en procesos define los objetivos del Data Mining para resultados específicos tales
como manejos de campaña, prospecting, y optimización de promociones. La
integración con el data warehouse permite que decisiones operacionales sean
implementadas directamente y monitoreadas. A medida que el data warehouse
crece con nuevas decisiones y resultados, la organización puede "minar" las

mejores prácticas y aplicarlas en futuras decisiones.
Este diseño representa una transferencia fundamental desde los sistemas de
soporte de decisión convencionales. Más que simplemente proveer datos a los
usuarios finales a través de software de consultas y reportes, el server de Análisis
Avanzado aplica los modelos de negocios del usuario directamente al warehouse y
devuelve un análisis proactivo de la información más relevante. Estos resultados
mejoran los metadatos en el server OLAP (procesamiento analítico on-line)
proveyendo una estrato de metadatos que representa una vista fraccionada de los
datos. Generadores de reportes, visualizadores y otras herramientas de análisis
pueden ser aplicadas para planificar futuras acciones y confirmar el impacto de
esos planes.
5.7. Técnicas más comúnmente usadas en Data Mining:
Redes neuronales artificiales: modelos predecible no-lineales que aprenden

a través del entrenamiento y semejan la estructura de una red neuronal
biológica.
Árboles de decisión: estructuras de forma de árbol que representan

conjuntos de decisiones. Estas decisiones generan reglas para la clasificación
de un conjunto de datos. Métodos específicos de árboles de decisión incluyen
Árboles de Clasificación y Regresión (CART: Classification And Regression
Tree) y Detección de Interacción Automática de Chi Cuadrado (CHAI: Chi
Square Automatic Interaction Detection)
Algoritmos genéticos: técnicas de optimización que usan procesos tales

como combinaciones genéticas, mutaciones y selección natural en un diseño
basado en los conceptos de evolución.
Método del vecino más cercano: una técnica que clasifica cada registro en
un conjunto de datos basado en una combinación de las clases del/de los k
registro (s) más similar/es a él en un conjunto de datos históricos (donde k 1).
Algunas veces se llama la técnica del vecino≥ k-más cercano.
Regla de inducción: la extracción de reglas if-then de datos basados en

significado estadístico.
Muchas de estas tecnologías han estado en uso por más de una década en
herramientas de análisis especializadas que trabajan con volúmenes de datos
relativamente pequeños. Estas capacidades están ahora evolucionando para
integrarse directamente con herramientas OLAP y de Data Warehousing.
La intención de este modulo no es la de profundizar en cada una de estas reglas,

el lector interesado en profundizar el tema puede hacerlo en la bibliografía
4
recomendada o en la web.
D
F$ '9'"$P *11 C %3 ' " !' * 1* , '$ A* "$ "* %
Glosario de Términos de Data Mining
Algoritmos genéticos: Técnicas de optimización que usan procesos tales

como combinación genética, mutación y selección natural en un diseño basado
en los conceptos de evolución natural.
Análisis de series de tiempo (time-series): Análisis de una secuencia de

medidas hechas a intervalos específicos. El tiempo es usualmente la
dimensión dominante de los datos.
Análisis prospectivo de datos: Análisis de datos que predice futuras

tendencias, comportamientos o eventos basado en datos históricos.
Análisis exploratorio de datos: Uso de técnicas estadísticas tanto gráficas

como descriptivas para aprender acerca de la estructura de un conjunto de
datos.
Análisis retrospectivo de datos: Análisis de datos que provee una visión de

las tendencias , comportamientos o eventos basado en datos históricos.
Árbol de decisión: Estructura en forma de árbol que representa un conjunto

de decisiones. Estas decisiones generan reglas para la clasificación de un
conjunto de datos. Ver CART y CHAID.
Base de datos multidimensional: Base de datos diseñada para

procesamiento analítico on-line (OLAP). Estructurada como un hipercubo con
un eje por dimensión.
CART Árboles de clasificación y regresión: Una técnica de árbol de decisión

usada para la clasificación de un conjunto da datos. Provee un conjunto de
reglas que se pueden aplicar a un nuevo (sin clasificar) conjunto de datos para
predecir cuáles registros darán un cierto resultado. Segmenta un conjunto de
datos creando 2 divisiones. Requiere menos preparación de datos que CHAID
.
CHAID Detección de interacción automática de Chi cuadrado: Una técnica

de árbol de decisión usada para la clasificación de un conjunto da datos.
Provee un conjunto de reglas que se pueden aplicar a un nuevo (sin clasificar)
conjunto de datos para predecir cuáles registros darán un cierto resultado.
Segmenta un conjunto de datos utilizando tests de chi cuadrado para crear
múltiples divisiones. Antecede, y requiere más preparación de datos, que
CART.
Clasificación: Proceso de dividir un conjunto de datos en grupos mutuamente

excluyentes de tal manera que cada miembro de un grupo esté lo "más
cercano" posible a otro, y grupos diferentes estén lo "más lejos" posible uno
del otro, donde la distancia está medida con respecto a variable(s)
específica(s) las cuales se están tratando de predecir. Por ejemplo, un
problema típico de clasificación es el de dividir una base de datos de

compañías en grupos que son lo más homogéneos posibles con respecto a
variables como "posibilidades de crédito" con valores tales como "Bueno" y
"Malo".
Clustering (agrupamiento): Proceso de dividir un conjunto de datos en grupos

mutuamente excluyentes de tal manera que cada miembro de un grupo esté lo
"más cercano" posible a otro, y grupos diferentes estén lo "más lejos" posible
uno del otro, donde la distancia está medida con respecto a todas las variables
disponibles.
Data cleansing: Proceso de asegurar que todos los valores en un conjunto de

datos sean consistentes y correctamente registrados.
Data Mining: La extracción de información predecible escondida en grandes

bases de datos.
Data Warehouse: Sistema para el almacenamiento y distribución de

cantidades masivas de datos
Datos anormales: Datos que resultan de errores (por ej.: errores en el tipeado
durante la carga) o que representan eventos inusuales.
Dimensión: En una base de datos relacional o plana, cada campo en un

registro representa una dimensión. En una base de datos multidimensional,
una dimensión es un conjunto de entidades similares; por ej.: una base de
datos multidimensional de ventas podría incluir las dimensiones Producto,
Tiempo y Ciudad.
Modelo analítico: Una estructura y proceso para analizar un conjunto de

datos. Por ejemplo, un árbol de decisión es un modelo para la clasificación de
un conjunto de datos
Modelo lineal: Un modelo analítico que asume relaciones lineales entre una
variable seleccionada (dependiente) y sus predictores (variables
independientes).
Modelo no lineal: Un modelo analítico que no asume una relación lineal en los
coeficientes de las variables que son estudiadas.
Modelo predictivo: Estructura y proceso para predecir valores de variables

especificadas en un conjunto de datos.
Navegación de datos: Proceso de visualizar diferentes dimensiones, "fetas" y

niveles de una base de datos multidimensional. Ver OLAP.
OLAP Procesamiento analítico on-line (On Line Analitic prossesing): Se

refiere a aplicaciones de bases de datos orientadas a array que permite a los
usuarios ver, navegar, manipular y analizar bases de datos multidimensionales.
Regresión lineal: Técnica estadística utilizada para encontrar la mejor relación

lineal que encaja entre una variable seleccionada (dependiente) y sus
predicados (variables independientes).
Regresión logística: Una regresión lineal que predice las proporciones de una
variable seleccionada categórica, tal como Tipo de Consumidor, en una
población.
!" # $%
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.
CIBERGRAFIA
QQQ 1% % $%R" $' *R*% #'* *%R" " ),1

QQQ & # *,* !' '$ R%S1),1
QQQ $1& # *,*" $% ,
QQQ * '*1 ,
QQQ 0 #
ANEXO
Resultados de ejemplos referenciados en la sección 2 “Álgebra Relacional”
"&
, $ $1T( ' $ !' >$ )*U1 $' >$ )*U1 $' #$' *
' *U"$%"$ *U)*% *
VD ;DN *' *1"T% DV N *N@N W W WWW ; WWV

DV N ; $" "$ 1* %* N V -; 11DN @ DN W W WWD WN W W
DN
-V -DN $" T$P 11 @ ;W D; W WD --W WV WD --V
& W ' D
V -DN D 2 % *0 ; V DN - *N@ N W; WD --N W WD WW
X* *,*'
(
, $ $1T( ' $ !' #$' *
VD ;DN *' *1"T% DV N *N@N
-V -DN $" T$P 11 @ ;W D; & W ' D
- N ;D * * %%* VND D@N -
;DN / %* >$ '9'"$P ; NDVN - 11;D @ W ;
NDV -V / %* 9$P ;WWDN V - 11VW@ W
# )
* $' $ * * "$1 5 U" $5 U ) ($

F/ D ; %%*' $' * - VD ;DN VD ;DN
D C * 11* -V VD ;DN -V -DN
E NWW $'* 1 1 WWN ;DN VD ;DN
V- $'* 1 $#*'$ WW; NDV -V VD ;DN
YW ; $'* 1 D -V NDV -V -V -DN
1 $% 1*" "$ 1* &$ * !' $%<
, $ $1T( ' $ !' #$' *

VD ;DN *' *1"T% DV N *N@N
- N ;D * * %%* VND D@N -
;DN / %* >$ '9'"$P ; NDVN - 11;D @ W ;
NDV -V / %* 9$P ;WWDN V - 11VW @ W
1 $% 1*" "$ 1* &$ * !' $%

* $' $ * * "$1 5
F/ D ; %%*' $' * -
3$1 $% 1*" $%
, $ $ !'
*' *1"T% *N@N
$" T$P 11 @ ;W D; & W ' D
* * %%* D@ N -
/ %* >$ '9'"$P 11;D @ W ;
/ %* 9$P 11VW @ W
<
#$' *
VD ;DN
DV N ;
-V -DN
V -DN D
( *# )
, $ $1T( ' $ !' #$' * $' $ * * "$1 5
*
VD ; *' *1"T% DV N *N @N F/ D ; %%*' $' * -
DN
-V -D $" T$P 11 @ ;W D; & W ' D F/ D ; %%*' $' * -
N
- N * * %%* VND D@ N - F/ D ; %%*' $' * -
;D
;DN / %* ; NDVN - 1
1;D @ W ; F/ D ; %%*' $' * -
>$ '9'"$P
NDV - / %* 9$P ;WWDN V - 1
1VW @ W F/ D ; %%*' $' * -
V
VD ; *' *1"T% DV N *N@ N D C * 11
* -V
DN
-V -D $" T$P 11 @ ;W D; & W ' D D C * 11
* -V
N
- N * * %%* VND D@N- D C * 11
* -V
;D
;DN / %* ; NDVN - 1
1;D @ W ; D C * 11
* -V
>$ '9'"$P
NDV - / %* 9$P ;WWDN V - 1
1VW@ W D C * 11
* -V
V
VD ; *' *1"T% DV N *N@N E NWW $'* 1 1 WWN
DN
-V -D $" T$P 11 @ ;W D; & W ' E NWW $'* 1 1 WWN
N D
- N * * %%* VND D@N - E NWW $'* 1 1 WWN
;D
;DN / %* ; NDVN - 1
1;D @ W ; E NWW $'* 1 1 WWN
>$ '9'"$P
NDV - / %* 9$P ;WWDN V - 1
1VW@ W E NWW $'* 1 1 WWN
V
VD ; *' *1"T% DV N *N@N V- $'* 1 $#*'$ WW;
DN
-V -D $" T$P 11 @ ;W D; & W ' D V- $'* 1 $#*'$ WW;
N
- N * * %%* VND D@N - V- $'* 1 $#*'$ WW;
;D
;DN / %* ; NDVN - 1
1;D @ W ; V- $'* 1 $#*'$ WW;
>$ '9'"$P
NDV - / %* 9$P ;WWDN V - 1
1VW@ W V- $'* 1 $#*'$ WW;
V
VD ; *' *1"T% DV N *N@N YW ; $'* 1 D -V
DN
-V -D $" T$P 11 @ ;W D; & W ' D YW ; $'* 1 D -V
N
- N * * %%* VND D@N- YW ; $'* 1 D -V
;D
;DN / %* ; NDVN - 1
1;D @ W ; YW ; $'* 1 D -V
>$ '9'"$P
NDV - / %* 9$P ;WWDN V - 1
1VW@ W YW ; $'* 1 D -V
V
* $' $ * * "$1 5
F/ D ; %%*' $' * -
D C * 11* -V
E NWW $'* 1 1 WWN
V- $'* 1 $#*'$ WW;
YW ; $'* 1 D -V
4 $5 6 4 ) ($ 6
Π 30#$' * Π 30#$' *
#$' *
'
VD ;DN
DV N ;
-V -DN
V -DN D
- N ;D
;DN
NDV -V
- (. -"& .
Π +), ∩Π +),
1 $% 1*" "$ 1* &$ * !' ' $ %$ !' $%<
#$' *
'
VD ;DN
-V -DN
- (. -"& .
Π +), /Π +),
1 $% 1*" "$ 1* &$ * !' " ($ $' * $%<

#$' *
- N ;D
;DN
NDV -V
1 $% 1*" "$ 1* &$ * !' 8 ' $%

, $ $1T( ' $ !' #$' * * $' $ * * "$1 5
VD *' DV N *N@N F/ D ; %%*' $' * -
;D *1"T%
N
VD *' DV N *N@N C * 11
* -V
;D *1"T% D
N
; / %* ; NDVN 1
1;D @ E $'* 1 1 WWN
DN >$ '9'"$P - W ; NWW
NDV / %* ;WWDN V 1
1VW@ $'* 1 $#*'$ WW;
-V 9$P - W V-
NDV / %* ;WWDN V 1
1VW@ $'* 1 $#*'$ WW;
-V 9$P - W V-
;-
DW

Base de Datos Avanzada 2005

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

Base de Datos Avanzada 2005

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA

FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA

BASE DE DATOS AVANZADA

ROGELIO VASQUEZ BERNAL

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD

CAPÍTULO 1. Conceptos básicos de bases de datos 1

1. Modelo entidad relación 1

2.1. Propiedades de la transacción 24

BASES DE DATOS DISTRIBUIDAS 34

Introducción y fundamentos de Base de Datos Distribuidas. 34

CAPITULO 2. Consultas Distribuidas 51

2.1. Objetivo del procesamiento de las consultas 51

CAPITULO 3. Transacciones Distribuidas 58

3.1 Definición de una transacción 58

OTROS MODELOS DE BASES DE DATOS 86

CAPÍTULO 1. Bases de datos orientadas a objetos 86

CAPÍTULO 2. Bodega de datos 109

2.1 Introducción 109

3.2 Ambiente de Negocios. 112

GLOSARIO DE TÉRMINOS DE DATA MINING 123

Figura1. Representación de entidad

Figura 2. Representación de una relación

Figura 3. Relación recursiva

Figura 4. Nombre relaciones

Figura 5. Ejemplo nombre relaciones

Figura 6. Incorporando atributos

Figura 7. Atributos candidatos

Figura 8. Atributos candidatos

Figura 9. Un atributo repetido indica una entidad perdida.

Figura 10. Añadir la entidad perdida 18

Figura 11. Muestra de identificadores únicos 20

Figura 12. Refinamiento de Entidades 21

Figura 13. Reconocimiento de patrones 22

Figura 14 - Esquema de Relaciones de Ejemplo 23

Figura 15 Primera forma normal 29

Figura 16. Segunda y tercera forma normal 31

Figura 17 - Pasos en el procesamiento de una consulta SQL 33

Figura 18. Motivación de los sistemas de bases de datos distribuidos. 44

Figura 19. Un sistema centralizado sobre una red 45

Figura 20. Un medio ambiente distribuido para bases de datos 46

Figura 21. El enfoque top-down para el diseño de bases de datos distribuidas 50

Figura 22. El problema de fragmentación de relaciones 51

Figura 23. El grado de fragmentación 53

Figura 24. Un modelo de transacción. 68

Figura 25. Un modelo del administrador de transacciones. 76

Figura 26. Ejecución centralizada de transacciones. 77

Figura 26b. Ejecución distribuida de transacciones. 77

Figura 27. Clasificación de los algoritmos de control de concurrencia 84

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

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

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

Figura 31. Comunicación en candados de dos fases distribuidos 88

Figura 32. Fases de la ejecución de una transacción a) pesimista,

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

Figura 35: Modelado de Casos de Uso. 107

Figura 37: Diagrama de Secuencia para un escenario 110

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

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

Figura 40: Diagrama de Actividad 113

Figura 41: Modelando componentes con el Diagrama de Componentes 114

Figura 42: Modelando la Distribución del Sistema con el Diagrama de

Figura 44: Relaciones clave entre entidades en un Diagrama de

Tabla 1 - Operadores del Álgebra relacional 23