Base de Datos Avanzada v3

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD
Escuela de Ciencias Bsicas, Tecnologa e Ingeniera

Programa Ingeniera de sistemas
Curso 301125 Bases de datos avanzadas
Gua de componente prctico
301125 - BASES DE DATOS AVANZADAS
Curso Electivo
ANVAR CHAVES TORRES
(Director Nacional)
JAVIER JIMENEZ
(Acreditador)
San Juan de Pasto
7 de febrero de 2012
La primera versin de este documento fue escrita por el ingeniero Rogelio Vsquez
Bernal, posteriormente ha sido actualizado por otros profesionales, docentes de la
UNAD, cuyos nombres no fueron registrados. Esta versin del documento ha sido
editada por Anvar Chaves Torres.
Este documento fue preparado para estudiantes de Ingeniera de sistemas de la Unad y
se acoge a la licencia Creative Commons 3.0. En consecuencia, se permite su uso con
fines acadmicos, siempre que se reconozca el crdito al autor. Se prohbe la
reproduccin, por cualquier medio, con fines comerciales.
Los ejemplos y ejercicios han sido diseados exclusivamente con fines didcticos, el
autor, el editor y la universidad no asumen ninguna responsabilidad por la aplicacin de
los mismos en con propsitos diferentes a la comprensin de los temas de este curso.
CONTENIDO
Nmero de crditos y dedicacin horaria................................................................................. 6
Protocolo........................................................................................................................................ 7
Introduccin general al curso ................................................................................................... 14
Unidad I. Bases de datos distribuidas..................................................................................... 15
Capitulo 1. Conceptos bsicos de bases de datos........................................................... 15
Leccin 1. Modelo entidad relacin................................................................................. 15
Leccin 2. Elementos del Modelo entidad relacin....................................................... 18
Leccin 3. lgebra relacional ........................................................................................... 28
Leccin 5. Transacciones ................................................................................................. 39
Captulo 2. Diseo de bases de datos distribuidas........................................................... 50
Leccin 6. Bases de datos distribuidas .......................................................................... 50
Leccin 7. Bases de datos distribuidas .......................................................................... 55
Leccin 8. Fragmentacin................................................................................................. 59
Leccin 9. Tipos de fragmentacin de datos ................................................................. 64
Leccin 10. Diseo de replica .......................................................................................... 68
Capitulo 3. Consultas............................................................................................................. 70
Leccin 11. Consultas distribuidas.................................................................................. 70
Leccin 12. Descomposicin de una consulta y localizacin de datos distribuidos 74
Leccin 13. Transacciones Distribuidas......................................................................... 76
Leccin 14. Consistencia de la base de datos interna. ................................................ 84
Leccin 15. Catlogo....................................................................................................... 101
Unidad 2. Bodegas de datos.................................................................................................. 106
Captulo 4. Diseo de bodegas de datos ......................................................................... 106
Leccin 16. Introduccin ................................................................................................. 106
Leccin 17. Construccin y manejo de una bodega de datos .................................. 108
Leccin 18. Construccin del Data Warehouse. ......................................................... 109
Leccin 19. Estrategias recomendadas para diseo de datos ................................. 111
Leccin 20. Factores de riesgo...................................................................................... 114
Capitulo 5. Minera de datos............................................................................................... 115
Leccin 22. Fundamentos del Data Mining.................................................................. 116
Leccin 23. Alcance de Data Mining............................................................................. 117
Leccin 24. Fases de un Proyecto de Minera de Datos ........................................... 119
Leccin 25. Cmo Trabaja el Data Mining?................................................................. 120
Captulo 6. Herramientas de minera de datos................................................................ 122
Leccin 26. Redes neuronales artificiales:................................................................... 122
Leccin 27. rboles de decisin: ................................................................................... 123
Leccin 28. Mtodo del vecino ms cercano:.............................................................. 124
Leccin 29. Algoritmos genticos.................................................................................. 125
Leccin 30. Regla de induccin: .................................................................................... 126
Unidad 3. Bases de datos orientadas a objetos.................................................................. 127
Captulo 7. Orientacin a objetos ...................................................................................... 127
Leccin 31. Introduccin................................................................................................ 127
Leccin 32. Conceptos bsicos: .................................................................................... 129
Leccin 33. Arquitectura de administrador de sistemas de BDOO.......................... 132
Leccin 34. Sistema administradores de bases de datos orientadas a objetos
(SABD-OO) ....................................................................................................................... 134
Leccin 35. El sistema Postgres................................................................................... 135
Capitulo 8. Lenguaje de Modelado Unificado UML ........................................................ 136
Leccin 36. Introduccin................................................................................................. 136
Leccin 37. Mtodo o Lenguaje de Modelado?........................................................ 138
Leccin 38. Una perspectiva de UML........................................................................... 140
Leccin 39. Diagramas de Secuencia .......................................................................... 145
Leccin 40. Diagramas de Colaboracin...................................................................... 147
Captulo 9. Modelado con UML ......................................................................................... 148
Leccin 41. Modelando el comportamiento de las Clases con Diagramas de Estado
............................................................................................................................................ 148
Leccin 42. Diagramas de Actividad............................................................................. 150
Leccin 43. Modelando Componentes de Software................................................... 152
Leccin 44. Modelando la Distribucin y la Implementacin..................................... 153
Leccin 45. Diseo de Bases de Datos Relacionales -- Una extensin informal de
UML.................................................................................................................................... 154
Nmero de crditos y dedicacin horaria
El curso de Bases de datos avanzada est configurado como curso de 3 crditos.
El sistema de crditos, garantiza procesos de movilidad entre instituciones del sistema
de educacin superior e indica la cantidad de tiempo que un estudiante debe invertir
para conocer y manejar los temas propuestos en un curso acadmico.
Para la UNAD, por cada crdito acadmico, el estudiante debe invertir:
2 horas de trabajo individual por semana. El tiempo de trabajo individual lo define el
estudiante, de acuerdo a su disponibilidad de tiempo. En este espacio se incluye el
tiempo de trabajo colaborativo.
1 hora de trabajo en acompaamiento con tutor. Sea mediante tutorias CV o ST
Es decir, que el curso exige que el estudiante mnimo invierta 144 horas en el semestre
Protocolo
Introduccin
El curso de Bases de datos Avanzada hace una revisin acerca de diversas
aplicaciones, en cuanto a bases de datos se refiere, que permiten identificar ventajas,
desventajas y reas de aplicacin.
Este curso es electivo, pretende fortalecer los conocimientos bsicos de bases de datos
y revisar los temas de diferentes tipos de aplicacin.
Es un curso metodolgico, de tres crditos (3), lo que significa que deben realizar
procesos de aprendizaje de por lo menos 144 horas en el semestre: 108 horas de
dedicacin independiente, investigando, leyendo, interiorizando los conceptos,
desarrollo de actividades colaborativas con otros compaeros de curso; 36 horas de
acompaamiento tutorial, donde se resuelven dudas, se apoya el proceso individual y
de grupo.
El curso pretende:
Conocer otros tipos de modelos de datos.
Determinar las condiciones, necesidades, ventajas y desventajas de los diferentes tipos
de bases de datos.
Aplicar los conceptos de acuerdo a los requerimientos de la empresa
Justificacin
Los sistemas de bases de datos, son los ms importantes para el manejo eficiente de
informacin. Aunque el sustento terico sigue siendo el mismo, las realidades de la
empresa, las aplicaciones de la informacin almacenadas en las bases de datos, como
soporte decisional, las inclusin de los objetos en el mundo planificado y pensado para
registros planos, hace de este curso importante para ver otras realidades y retos en el
desarrollo de los sistemas de bases de datos.
Las competencias que promueve el curso y que son necesarias son:
Cognitiva: Capacidad de apropiarse de un conjunto de conocimientos a travs del
desarrollo, monitoreo y aplicacin de procesos de pensamiento.
Comunicativa: Capacidad de comprender, expresar mensajes y de desarrollar procesos
argumentativos, apoyados por las relaciones interpersonales.
Contextual: Capacidad de ubicar el conocimiento en el contexto cientfico, poltico,
cultural, tecnolgico, social y en el plano nacional e internacional, as como la
disposicin y capacidad para aplicarlo en procesos de transformacin que inciden en la
calidad de vida de la poblacin.
Valorativa: Capacidad de apropiarse de valores como el respeto a la vida y a las ideas
de los dems; la dignidad humana, la convivencia, la solidaridad, la tolerancia y la
libertad que orientan las acciones del individuo como persona, como ser social y como
profesional.
Para el logro de stas competencias, es necesario que se planifique de manera
responsable el proceso de auto estudio por parte del estudiante si se quieren lograr
resultados positivos en el aprendizaje de los conceptos incluidos en el curso.
Este proceso se puede planificar en diferentes momentos:
Autoestudio: Estudio individual del material sugerido y consulta de otras fuentes
documentales (consultas en bibliotecas, Internet, bibliografa recomendada, consulta a
bases de datos documentales, entre otros)
Trabajo en grupos colaborativos: Creacin de grupos de estudio o discusin con el
propsito de proponer ideas, resolver dudas o preparar consultas estructuradas al tutor.
Consultas al tutor: Consulta al tutor de las inquietudes surgidas en el punto anterior.
Retroalimentacin: Una vez el tutor haya resuelto las inquietudes, estudie nuevamente
el tema, teniendo en cuenta las sugerencias o respuestas dadas en los encuentros por
el tutor.
Procesos de evaluacin: Una vez se haya realizado el proceso de retroalimentacin,
desarrolle los diferentes momentos de evaluacin propuestos en el curso como son la
autoevaluacin, coevaluacin y heteroevaluacin.
Se entiende por autoevaluacin, el proceso autocritico, donde el estudiante determina
si su conocimiento del tema es aceptable o si debe reiniciar el proceso.
Coevaluacin, proceso mediante el cual, el grupo de estudiantes que desarrolla
actividades colaborativas en un tema, califica el desempeo de cada uno de sus
compaeros.
Por ltimo, una vez el estudiante ha pasado los filtros necesarios para garantizar las
competencias bsicas del curso, se presenta ante los procesos de evaluacin
propuestos por el tutor.
Intensionalidades formativas
Propsitos
El curso pretende definir un marco de trabajo que facilite el desarrollo de conocimientos
alrededor de los temas propuestos
Reconocer la existencia de modelos de datos y sus implicaciones en los sistemas de
informacin
Determinar cuando se deben usar las estructuras de bases de datos definidas en el
curso acadmico
Objetivos
Reconocer las ventajas de las bases de datos en los procesos de anlisis de
informacin y como herramienta para la toma de decisiones.
Entender el modelo de bases de datos distribuido, sus ventajas, desventajas y
las posibilidades del modelo sobre la plataforma de alta velocidad de trasmisin.
Conocer y aplicar los conceptos de bodegas de datos, como herramienta
indispensable para almacenar informacin que facilite procesos de anlisis y
toma de decisiones
Conocer las tcnicas de minera de datos, sus aplicaciones y los resultados
obtenidos.
Reconocer los conceptos bsicos de un sistema de base de datos orientado a
objetos, el modelo de datos, sus ventajas, desventajas y aplicaciones.
Metas
Que el estudiante refuerce los conocimientos de bases de datos relacionales, el
uso de SQL y tenga los conceptos bsicos para administrar una base de datos
Que el estudiante pueda aplicar los modelos de datos usados para los sistemas
de bases de datos transaccionales, bodegas de datos y modelos de datos
orientados a objeto
Que el estudiante conozca que tcnicas puede aplicar para minera de datos.
Que el estudiante pueda plantear proyectos que requieran las tecnologas
desarrolladas en el curso
Competencias
Las competencias que promueve el curso y que son necesarias son:
Cognitiva: Capacidad de apropiarse de los conocimientos planteados en el contenido
del curso a travs del desarrollo, monitoreo y aplicacin de procesos de pensamiento.
Comunicativa: Capacidad de comprender, expresar mensajes y de desarrollar procesos
argumentativos, apoyados por las relaciones interpersonales.
Contextual: Capacidad de ubicar el conocimiento en el contexto cientfico, poltico,
cultural, tecnolgico, social y en el plano nacional e internacional, as como la
disposicin y capacidad para aplicarlo en procesos de transformacin que inciden en la
calidad de vida de la poblacin.
Valorativa: Capacidad de apropiarse de valores como el respeto a la vida y a las ideas
de los dems; la dignidad humana, la convivencia, la solidaridad, la tolerancia y la
libertad que orientan las acciones del individuo como persona, como ser social y como
profesional.
El curso busca que el estudiante reconoce las diferentes reas de aplicacin de las
bases de datos, diseando y construyendo soluciones eficientes que permiten apoyar
los procesos de toma de decisiones en la empresa.
Unidades didcticas
Repaso
Conceptos Bases de datos. Este tema incluye, Modelo Entidad Relacin, normalizacin
de datos y SQL.
Unidad I.
Bases de datos distribuidas, que son, modelo de datos Entidad Relacin, fragmentacin
y replicacin, transacciones, consultas y catalogo distribuido.
Unidad II.
Bodegas de datos, que son, modelo relacional, modelo copo de nieve. Carga de datos
y minera de datos.
Unidad III
Bases de datos orientadas a objeto. Objetos, propiedades, diseo de objetos UML,
SQL.
Estructura del curso
Contexto terico
El curso de bases de datos avanzada, se ha pensado como un curso electivo que
quiere fortalecer los temas vistos en el curso bsico.
Se intenta mostrar el sustento terico en los sistemas de bases de datos distribuidos,
sistema que hoy retoma importancia por los desarrollos en los medios de comunicacin
que han reactivado ese tipo de proyectos.
De otro lado, hoy en da los sistemas de bodegas de datos tienen un espacio claro en
la empresa, para permitir, al revisar la historia, crear el concepto de fidelidad y
conocimiento de los gustos del cliente para ofrecer mejores servicios.
De otro lado, la idea de objetos y como los sistemas de bases de datos los utilizan, es
importante por el auge que ha tomado este tipo de sistemas.
Metodologa
Con el propsito de dar cumplimiento a las intencionalidades formativas del curso, es
importante que se planifique de manera responsable el proceso de aprendizaje
teniendo en cuenta las caractersticas de la metodologa de educacin a distancia, por
tal razn, este proceso se puede estructurar mediante las siguientes fases:
Reconocimiento: Mediante esta etapa se pretende reconocer los conocimientos
previos del estudiante, por lo tanto la funcin didctica consiste en crear actividades
mediante las cuales se identifican los propsitos del curso, sus intencionalidades y se
presenta el desarrollo del curso. Esta fase puede desarrollarse de manera individual a
travs del estudio del protocolo del curso, el modulo y las fuentes documentales
suministradas por el tutor y a travs de actividades grupales desarrolladas por el tutor.
Profundizacin: Teniendo en cuenta que esta se refiere al conjunto de actividades
previamente planificadas conducentes al dominio de conceptos y competencias de
ordenes diferentes, se han definido los siguientes propsitos de formacin:
Trabajo personal: desarrolladas por el estudiante, a travs de: estudio del
material sugerido en el curso acadmico, consulta de fuentes documentales
(bibliografa de documentos impresos en papel: libros y revistas; bibliografa de
documentos situados en Internet; direcciones de sitios Web de informacin
especializada y bibliotecas)
Trabajo en grupo: desarrolladas por estudiantes a travs de pequeos grupos
colaborativos de carcter obligatorio, con el propsito de: socializacin del
trabajo personal, desarrollo de actividades en equipo, elaboracin de informes,
de acuerdo con las actividades programadas en la gua didctica.
Tutora en grupo de curso: teniendo en cuenta las inquietudes presentadas por
el estudiante a partir del trabajo personal y del trabajo en grupo, el tutor estar
dispuesto a resolver las consultas mediante la valoracin de informes y el
intercambio de conocimientos en el tratamiento de las temticas propuestas.
Tutora individual: entendida como el acompaamiento que el tutor debe ofrecer
al estudiante mediante el uso de las tecnologas de informacin y la
comunicacin, tales como: correo electrnico, salas de conversacin, foros de
discusin, el telfono y Chat; tambin se puede complementar con encuentros
presenciales.
Transferencia: todo conocimiento, habilidad, destreza o competencias puede permitir
la transferencia de situaciones conocidas a situaciones desconocidas; por lo tanto
en esta fase requiere que tomando como referencia las fases de reconocimiento y
profundizacin que se elaboren ensayos, evaluaciones, mapas conceptuales y
talleres de aplicacin en las diferente fases del curso acadmico.
Sistema de evaluacin
Los procesos de evaluacin del aprendizaje estarn correlacionados y articulados de
manera necesaria al principio de autonoma y generaran en el estudiante competencias
para la realizacin de procesos de auto evaluacin, coevaluacin y heteroevaluacin. A
continuacin se indica cada uno de estos procesos:
Autoevaluacin: Es aquella que realiza el mismo estudiante, donde a medida que va
estudiando, se va planteando preguntas que el mismo las resuelve. De esta forma el
estudiante hace su propio seguimiento, identificando avances y dificultades, lo que
hace el proceso de autoaprendizaje muy dinmico y participativo. Este tipo de
evaluacin NO tiene ponderacin en la valoracin del curso, solo es una forma de
identificar fortalezas, oportunidades, debilidades y amenazas en el proceso de
aprendizaje.
Coevaluacin: Cuando el estudiante realiza estudio en grupo colaborativo, los
compaeros pueden valorar los avances, por medio de la Coevaluacin, en sta los
compaeros se evalan entre s, con el fin de identificar los avances y detectar
debilidades y fortalezas en el desarrollo de los temas que se estn estudiando. La
Coevaluacin es un espacio para desarrollar habilidades comunicativas y NO tiene
ponderacin en la valoracin del curso.
Heteroevaluacin: Es aquella preparada por el Tutor o por el Docente Titular del
Curso, para hacer el seguimiento al rendimiento acadmico de los estudiantes, se
puede realizar por medio de parciales, quices, revisin de informes, trabajos,
portafolios, evaluacin nacional y otros. Este estilo de evaluacin es la utilizada por la
UNAD para determinar la aprobacin o no del curso acadmico.
El sistema de evaluacin tendr como referente las diversas fases de aprendizaje:
Reconocimiento, Profundizacin y Transferencia, las cuales se valoraran de la siguiente
forma:
Fase de reconocimiento: diez por ciento (10%)
Fase de profundizacin: treinta por ciento (30%)
Fase de transferencia: veinte por ciento (20%)
Examen nacional: cuarenta por ciento (40%).
Introduccin general al curso
Un sistema de base de datos es bsicamente un sistema computarizado para llevar
registros
1
El modulo base de datos avanzada tiene como propsito fundamental profundizar
algunos temas tratados en base de datos bsica y presentar un esquema nuevo para
un nivel ms 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 bibliografa y cibergrafa
recomendada.
Los estudiantes deben trabajar el modulo acompaado de la gua de actividades y del
protocolo acadmico para lograr as el propsito del curso acadmico.
1
C.J. DATE. Introduccin a los sistemas de bases de datos
Unidad I. Bases de datos distribuidas
Capitulo 1. Conceptos bsicos de bases de datos
Leccin 1. Modelo entidad relacin
Es una tcnica para definir las necesidades de informacin de una organizacin. El
modelo entidad relacin en su forma ms simple implica identificar asuntos importantes
dentro de la organizacin (entidades) , propiedades de esos asuntos (atributos) y como
se relacional entre si (relacin). 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 gestin
sobre el modelo de informacin.
1.1. Objetivos del modelo entidad relacin
Proporcionar un modelo preciso de las necesidades de informacin de la organizacin.
Proporcionar un modelo independiente de cualquier almacenamiento de datos y
mtodo de acceso, que permita tomar decisiones de las tcnicas de implementacin y
coexistencia con sistemas antiguos.
1.2. Importancia del modelo entidad relacin
Ofrece un medio efectivo y preciso de especificar y controlar la definicin de las
necesidades de informacin. A continuacin se indican diez temas clave que se
necesitan tener en cuenta cuando se utiliza el modelo:
Dato: un recurso clave
Hoy en da un dato, como recurso, se acepta por ser importante para la evolucin
satisfactoria de la organizacin como lo son los recursos financieros, humanos y fsicos.
Compromiso con la direccin
La direccin debe confirmar los requisitos de informacin. No importa lo
inteligente que usted resulte al modelar, tendr un xito limitado sin el
compromiso de la direccin.
Convenciones
En todo momento se deben aplicar convenciones rigurosas, estndares y
directrices, incluyendo los conceptos de normalizacin de datos.
Definicin mnima
Se debera definir o modelar cualquier informacin o concepto de datos slo de
una forma, y a continuacin configurar asociaciones para los objetos
relacionados. Como por ejemplo, se debera definir una vez una cosa
denominada Pedido de compra y a continuacin relacionarlo con el
departamento, los productos, las funciones de autorizacin y as
sucesivamente, como se requiera.
Independencia de los datos
Se deben definir los requisitos de informacin de forma que sean
independientes de cualquier almacenamiento final o mtodo de acceso y que
nos permita tener una visin creativa y objetiva de la empresa y del diseo
subsiguiente.
Patrones genricos
Deberan buscarse patrones genricos de datos para permitir a los usuarios
utilizarlos en su gestin, adems de tener la oportunidad de perfeccionar la
forma de procesar sus datos y de sugerir estructuras ms rentables y flexibles
para los diseadores de bases de datos.
Actitud y calidad
Los modelizadores deben comenzar aplicar las convenciones automticas y
velozmente, pero sin sacrificar el rigor. Tambin debe aprovechar cualquier
oportunidad con los usuarios para mejorar la precisin de los modelos.
Comunicacin
Debe haber comunicacin con los usuarios finales, en trminos que ellos
puedan entender aunque debe seguir siendo tcnicamente riguroso. Estas
tcnicas de modelizacin se han utilizado durante muchos aos para ayudar a
altos ejecutivos, directores y a otros a comprender su gestin. Es esencial
utilizar un lenguaje claro, sin abreviaturas, para lograr su comprensin. Con un
usuario final no deberamos utilizar la palabra entidad.
Relevancia
Los requisitos de informacin solamente pueden tener valor si aportan las
necesidades funcionales de la organizacin, dentro del marco de trabajo de los
objetivos y propsitos de la empresa.
Un medio, no un fin
Aunque el modelo entidad relacin es muy potente, ofrecer una idea increble
de la compaa y actuar como un marco de trabajo para el diseo de los datos,
solo es una tcnica intermedia, aunque desde luego importante.
Autoevaluacin
Una de las ventajas del modelo Entidad Relacin es:
Es un modelo de datos estndar que organiza la informacin del sistema.
Es un modelo de datos que indica como se almancena la informacin en los discos
Es un modelo de datos donde cada persona define su estandar para identificar los
elementos del modelo
Es un modelo que se implementa directamente en el computador
Leccin 2. Elementos del Modelo entidad relacin
El modelo entidad relacin para ser funcional requiere de la definicin de unos
elementos, los cuales se precisan a continuacin:
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 informacin.
Representacin 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
maysculas (figura 1).
Reglas para definir una entidad: Cualquier objeto slo 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 (aparicin)
de una entidad debe encontrarse separada e identificable claramente de todas las
dems instancias de ese tipo de entidad.
Relacin
Se entiende por relacin a la asociacin, vinculacin o correspondencia entre
entidades. Por ejemplo entre la entidad PROFESOR y la entidad CURSO podemos
establecer la relacin IMPARTE porque el profesor imparte cursos.
Una relacin es binaria en el sentido de que es siempre una asociacin entre
exactamente dos entidades, o entre una entidad y ella misma. Cada relacin 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 asociacin desde un extremo; se deben
definir ambos extremos.
Figura1. Representacin de entidad
Representacin de una relacin: Una relacin se representa mediante una lnea que
une dos recuadros de entidades, o recursivamente (recurrentemente) une un recuadro
de entidad consigo mismo.
La relacin es una funcin que indica por cada elemento de la relacin A cuantos
elementos dependen en la relacin B. Los valores se dividen en dos (2) y se conocen
como cardinalidad de la relacin (Figura 2).
El primer valor, denominado cardinalidad mnima, indica el menor nmero de
elementos en esa relacin; generalmente ese valor puede ser 0 1. Si el valor es 0, se
dice que la relacin es opcional y la grfica de la relacin se presenta con un circulo en
la terminacin de la relacin se hace con una lnea punteada. Si el valor es 1, se dice
que la relacin es obligatoria, la cual se presenta en la terminacin de la relacin
mediante una lnea perpendicular o mediante una lnea continua.
El segundo valor de la cardinalidad, cardinalidad mxima, indica la cantidad mxima
de registros de la relacin B por cada valor de la relacin A; generalmente son valores
1, o muchos (2, 3, ....n). La representacin se realiza con la terminacin conocida como
"pata de gallina", que es, la terminacin con 3 lneas.
Figura 2. Representacin de una relacin
Es til pensar acerca de una relacin de uno a muchos como una relacin padre a hijo,
con la existencia del hijo encontrndose en una forma dependiente de su padre.
Relacin recursiva
Es una relacin que se llama as misma, a continuacin se muestra una relacin
recursiva, por ejemplo, jefe y empleado.
Figura 3. Relacin recursiva
Nombre de las relaciones: El nombre de cada extremo de una relacin se sita cerca
al extremo apropiado en minsculas como se muestra a continuacin.
Figura 4. Nombre relaciones
Cuando la terminacin de la relacin es obligatoria, la frase debe ser se utiliza para
preceder al nombre final de la relacin; para los nombres finales opcionales de la
relacin se utiliza la frase puede ser
Figura 5. Ejemplo nombre relaciones
Cada ENTIDAD-A debe ser el nombre-extremo-1 una y solo una ENTIDAD-B,
y de derecha a izquierda:
Cada ENTIDAD-B puede ser el nombre-extremo-2 y una o ms ENTIDADes-A.
Para la figura 5, la lectura de esa representacin sera:
Cada TIQUETE debe ser para uno y slo un PASAJERO y, cada PASAJERO se puede
observar en uno o ms TIQUETES.
Atributos
Las entidades se componen de atributos que son cada una de las propiedades o
caractersticas que tienen las entidades. Cada ejemplar de una misma entidad posee
los mismos atributos, tanto en nombre como en nmero, diferencindose cada uno de
los ejemplares por los valores que toman dichos atributos. Ejemplo si consideramos la
entidad PROFESOR y definimos los atributos Nombre, Telfono, Salario; podramos
obtener lo siguiente:
Juan Prez Rodrguez, 4253250, 800.000
Martha Lpez Jimnez, 8553260, 600.000
Representacin de los atributos
Para representar un atributo hay que escribir su nombre en singular y en minscula, 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.
Figura 7. Atributos candidatos
En la grfica, por cada tiquete debe tenerse un cdigo y una fecha expedicin. Para
ese modelo, un pasajero tiene su identificacin y el nombre del pasajero
Caractersticas del atributo
Las siguientes normas simples ayudan a crear un modelo preciso, completo y flexible.
Un atributo describe una entidad
El atributo debe describir la entidad en contra de lo que se muestra.
Esto puede ser obvio, pero es el error ms comn que se encuentra en los atributos.
Por ejemplo. El "nmero de asiento" es un atributo de un cupn, billete, tarjeta de
embarque, avin o asiento de un avin? Obviamente es un atributo de ASIENTO, pero
en la vida real el nmero 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 nmero de asiento es una forma muy conveniente de
representar una relacin. Por el contrario, cuando se encuentran estas situaciones hay
que dibujar la lnea de relacin (si es necesario , crear la entidad a la que se refiere),
como se muestra a continuacin.
Para que sirva de gua la mayora de las entidades slo se describirn manejando entre
dos y ocho atributos. Si se tienen ms, probablemente existirn muchas relaciones y/o
entidades perdidas.
Figura 8. Asignar un atributo a la entidad correcta
Leer nombres de atributos
No hay que utilizar el nombre de la entidad como parte del nombre del atributo. Sera
redundante, ya que el atributo slo describe la entidad. En el ejemplo anterior, el el
nmero asiento realmente ayud a identificar una entidad perdida llamada ASIENTO
que se podra describir con el atributo nmero y quizs con otros atributos como tipo.
Para leer atributos que se nombren de esta manera, se pueden utilizar de una de las
dos formas:
Por ejemplo, asiento nmero o nmero de asiento.
Eliminar atributos repetidos (primera forma normal)
Una entidad que slo tenga un valor para un atributo en cualquier momento. Si son
esenciales muchos valores, se debe crear una entidad nueva para mantenerlos en la
relacin muchos a uno unidos con la entidad original.
Siguiendo la norma anterior se obtiene:
Figura 10. Aadir la entidad perdida
Esta es una norma o regla que se llama normalmente Primera forma normal
Nombre en singular
El nombre de un atributo debe ir en singular. Los nombres plurales generalmente
reflejan el problema de los atributos repetidos que se ha mostrado anteriormente.
Es una entidad?
Un atributo se convierte en una entidad cuando tiene importancia por s misma, con sus
propias relaciones y atributos.
Identificador nico
Cada entidad debe ser identificable nicamente por una combinacin de atributo y/o
relacin. De esta forma se podra buscar siempre cualquier atributo candidato que
ayude a identificar una entidad.
El valor del atributo debe ser dependiente de todo el identificador nico. (segunda
forma normal)
Figura 9. Un atributo repetido indica una entidad perdida.
Hay que quitar los atributos por los que los valores son dependientes slo de parte del
identificador nico. Esto se conoce como Segunda forma normal . Dichos atributos
normalmente suponen una entidad perdida, pero relacionada.
Los atributos deben ser dependientes directamente del identificador nico (tercera
forma normal)
Hay que quitar los atributos que no sean dependientes directamente del identificador
nico de la entidad. Esto se conoce como Tercera forma normal. En el subtema tres
se profundizara el concepto de normalizacin.
Identificador nico
Definicin
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 combinacin de
relaciones o una combinacin de atributos y relaciones.
Una entidad puede tener ms de un medio alternativo de identificacin nica. El mtodo
primario se puede mostrar en el diagrama entidad-relacin antecediendo a un atributo
que forme el identificador con una marca # , y colocando una barra cruzada en el caso
de una (s) lnea (s) de relacin. Figura 11
Figura 11. Muestra de identificadores nicos
As, pues, para identificar nicamente una tarjeta de embarque se necesita:
embarque se hayan reemitido; para volver a sentar a una familia
junta despus de que alguien no haya aparecido en el vuelo
ruta de la lnea area, se necesita el nmero de vuelo.
Figura 12. Refinamiento de Entidades
Norma de Diseo
Las normas simples del diseo que siguen a continuacin se han definido para que el
diagrama sea fcil de leer, aplicable para personas que necesiten trabajar con ellas y
para maximizar la calidad y la precisin.
Diagrama de Subconjunto
Cuando se trata un rea funcional en particular con un usuario o un diseo con los
diseadores, es bueno crear un diagrama de subconjunto y expresar las ideas de
nuevo ms eficazmente como un vehculo de comunicacin con ese propsito.
Durante el proceso se van a encontrar omisiones y errores, que se pueden corregir
rpidamente la perspectiva diferente es una potente herramienta analtica.
Esmerado y pulcro
Hay que organizar el diagrama de forma que los recuadros de las entidades estn
alineados y que las lneas de las relaciones sean rectas en sentido horizontal o
vertical. Hay que dibujar el menor nmero de lneas cruzadas posible.
Hay que evitar Construir un diagrama que tenga demasiadas lneas paralelas que
estn muy juntas. Hay que utilizar el mayor espacio en blanco que se pueda para
evitar el sentimiento de congestin y utilice de vez en cuando la lnea en diagonal para
ayudar a la esttica del diagrama.
Reconocimiento de patrones
La mayora de las personas tienen la capacidad incorporada de reconocer formas y
patrones en un instante y por tanto pueden recordar fcilmente el tema. Los
modelizadores pueden beneficiarse de esto haciendo que cada diagrama sea
claramente diferente en forma.
Texto
Hay que asegurarse de que el texto no sea ambiguo. Hay que evitar las abreviaturas y
las jergas. Hay que utilizar las convenciones de lectura descritas anteriormente y leer
todo el diagrama para asegurarse de que es completo y preciso. Un buen diagrama
entidad relacin debera ser semnticamente completo. Para mejorar la comprensin y
la precisin al leerlo, hay que aadir adjetivos y ejemplos cuando sea necesario.
Figura 13. Reconocimiento de patrones
Grado de relacin
Hay que situar la terminacin de muchas (ramificaciones) de las relaciones a la
izquierda o en la parte superior de la lnea de relacin. Se ha probado que esta tcnica
ha incrementado la precisin del modelo formando la consideracin de las relaciones,
desde las entidades que aparecen con ms frecuencia a las menos frecuentes.
Autoevaluacin
Una relacin reflexiva es
Relacin entre la entidad A y ella misma
Relacin entre la entidad A y la entidad B
Relacin entre la entidad A y sus atributos
Relacin entre los atributos de la entidad A y la llave principal
Leccin 3. lgebra relacional
Es necesario que el lector se familiarice con el trmino relacin, entendida en dos
aspectos, en primer lugar cuando mencionamos esta palabra en el modelo entidad
relacin se hace referencia a la asociacin entre dos o ms entidades, y, al hablar de
relacin en el lgebra relacional se est haciendo referencia a tablas, puesto que las
tablas son esencialmente relaciones.
El lgebra relacional es un lenguaje de consulta procedural. Consta de un conjunto de
operaciones que toman como entrada una o dos relaciones y producen como resultado
una nueva relacin, 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. Seleccin 2. Proyeccin 3. Producto
4. Unin 5. Interseccin 6. Diferencia
7. Join 8. Divisin
Tabla 1 - Operadores del lgebra relacional
Las operaciones de proyeccin, producto, unin, diferencia, y seleccin son llamadas
primitivas, puesto que las otras tres se pueden definir en trminos 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 bsico de administracin de Radio taxis. El Grfico que se presenta a
continuacin representa el Modelo conceptual (Modelo Lgico) o Diagrama de Entidad-
Relacin, (este adopta una metodologa 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:
Dueo = {rut, nombre, telfono, direccin, vigencia}
Chofer = {rut, nombre, telfono, direccin, fecha_licencia_desde, fecha_licencia_hasta,
vigencia}
Vale = {correlativo, hora_desde, hora_hasta, metraje_total, tarifa_total}
Mvil = {patente, rut_dueo, rut_chofer, marca, modelo, ao}
Viaje = {correlativo_vale, patente_movil, Hora_Desde, hora_hasta, origen, destino,
tarifa, metraje}
1. Seleccin
El operador de seleccin opta por tuplas que satisfagan cierto predicado, se utiliza la
letra griega sigma minscula () para sealar la seleccin. El predicado aparece como
subndice de . La Relacin que constituye el argumento se da entre parntesis
despus de la .
Ejemplos :
2. Proyeccin
La operacin de proyeccin permite quitar ciertos atributos de la relacin, esta
operacin es unaria, copiando su relacin base dada como argumento y quitando
ciertas columnas, La proyeccin se seala con la letra griega pi mayscula (). Como
subndice de se coloca una lista de todos los atributos que se desea aparezcan en el
resultado. La relacin argumento se escribe despus de entre parntesis.
Ejemplos :
3. Producto.
En lgebra relacional el producto de dos relaciones A y B es:
A Veces B o A X B
Produce el conjunto de todas las Tuplas t tales que t es el encadenamiento de una
tupla a perteneciente a A y de una b que pertenece a B. se utiliza el smbolo X para
representar el producto.
Ejemplos:
Dueo x Mvil
4. Unin.
En lgebra relacional la unin de dos relaciones compatibles
2
A y B es:
A UNION B o A U B
Produce el conjunto de todas las tuplas que pertenecen ya sea a A o a B o a Ambas. Al
igual que en teora de conjuntos el smbolo U representa aqu la unin de dos
relaciones.
Ejemplo :
Devuelve todos los Dueos y los Chferes.
5. Interseccin.
En lgebra relacional la interseccin de dos relaciones compatibles A y B
A INTERSECCION B o A B
Produce el conjunto de todas las tuplas pertenecientes a A y B. Al igual que en teora
de conjuntos el smbolo representa aqu la interseccin entre dos relaciones.
Ejemplo:
(Dueo) (Chofer)
Devuelve todos los dueos que tambin son chferes
6. Diferencia
En lgebra relacional la diferencia entre dos relaciones compatibles A y B
A MENOS B o A B
Produce el conjunto de todas las tuplas t que pertenecen a A y no pertenecen a B.
2
Relaciones Compatibles: En el lgebra relacional la compatibilidad se aplica a las operaciones
de Unin, Interseccin y Diferencia. Cada operacin requiere dos relaciones que deben ser
compatibles, esto significa que deben ser del mismo grado, n, y el i-simo atributo de cada una
(i= 1, 2...n) se debe basar en el mismo dominio.
Ejemplo:
Devuelve todos los dueos que NO son chferes
7. Join o Reunin.
En lgebra relacional el JOIN entre el atributo X de la relacin A con el atributo Y de la
relacin 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 proyeccin) entonces el resultado es un JOIN-NATURAL.
Ejemplo :
8. Divisin
En lgebra relacional el operador de divisin divide la relacin A con grado m + n por la
relacin B entregando como resultado una relacin 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 relacin C con un slo 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 chferes les caduca la licencia el 01/01/1999
Nota del autor: los resultados de cada uno de los ejemplos citados en este tema estn
al final del modulo como un anexo.
Autoevaluacin
Los operadores Seleccin y Proyeccin son conocidos como operadores Unarios
porque
Son operadores unarios porque se aplican sobre una tabla o relacin
Son operadores unarios porque se aplican a un conjunto de tuplas
Son operadores unarios porque se aplican a los ndices
Son operadores unarios porque se aplican a un tablespace
Leccin 4. Normalizacin de datos
La normalizacin de datos es un procedimiento que asegura que un modelo de datos
se ajusta a algunos estndares tiles. Para los datos y los modelos entidad-relacin,
estos estndares se han definido para minimizar la duplicacin de datos, proporcionar
la flexibilidad necesaria para soportar requisitos funcionales y para permitir que el
modelo se estructure sobre una amplia variedad de diseos alternativos de base de
datos.
Modelo entidad relacin
El modelo entidad-relacin tiende a producir entidades que estn normalizadas de
forma natural. Esto debido a que se sigue un proceso simple, como el siguiente:
informacin. 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 maysculas.
adir las relaciones de gestin, las cuales se han nombrado como asociaciones
significativas entre entidades. Estas relaciones se muestran como una lnea
entre dos recuadros; cada terminacin tiene un grado (un tringulo o
ramificacin que significa muchos; si no hay tringulo significa uno) y la
opcionalidad (una lnea de puntos significa opcional, una lnea continua significa
obligatorio).
conocer. Estos atributos se muestran dentro de la entidad como nombres en
minsculas.
ser identificada de forma nica. Esto se har mediante alguna combinacin de
atributos y/o relaciones. Cuando un atributo es parte del identificador nico se
muestra con una marca #. Cuando una relacin es parte del identificador nico
se muestra mediante una barra cruzada cruzando la lnea de relacin. El
seguimiento del proceso anterior dar rigurosa y automticamente un modelo
normalizado, pero depende de la buena comprensin del analista acerca de lo
que es realmente un atributo, una relacin y una entidad.
Normalizacin
Para comprobar que un modelo entidad-relacin tiene todas sus entidades
unvocamente 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 combinacin de atributos y / o relaciones
Primera forma normal: [1NF]
Eliminar los atributos repetidos o grupos de atributos.
Si existe ms de un valor a la vez para un atributo o para ms 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 relacin (de muchos a uno) se lleva a la entidad original.
Figura 15 Primera forma normal
Segunda forma normal: [2NF]
Eliminar atributos dependientes slo en parte del identificador nico.
Si una entidad tiene un identificador nico compuesto de ms de un atributo y/o
relacin, y si otro atributo depende slo de parte de este identificador compuesto,
entonces el atributo, y la parte del identificador del que depende, debern 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 relacin de uno a muchos unido a
la entidad original.
Tercera forma normal: [3NF]
Eliminar los atributos dependientes de atributos que no son parte del identificador
nico.
Si un atributo de una entidad es dependiente de otro atributo, que no es parte del
identificador nico, entonces estos atributos deberan formar la base de la nueva
entidad, que tenga una relacin 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
continuacin se presenta la representacin de esta forma:
Figura 16. Segunda y tercera forma normal
En general, una relacin R est en la tercera forma normal (3NF) si y slo si en
cualquier momento cada tupla (lnea relacional) de R se compone de un valor clave
primario que identifica alguna identidad, junto con un grupo de cero o ms valores
independientes mutuamente que describen esa entidad de alguna manera
3
Adems, una relacin R est en la cuarta forma normal (4NF) si y nicamente si
donde quiera que haya una dependencia multivalores (MVD) en R, digamos A
todos los atributos de R son tambin funcionalmente dependientes de A. En otras
palabras, las nicas dependencias (funcionales o multivalores) en R son de la forma K
multivalores) son de verdad dependencias funcionales (FD).
3
Date, C.J. An Introduction to Database System, 4ed. 1986. Adisson-Wesley Publishing Co
Tambin, una relacin R est en quinta forma normal (5NF), tambin denominada
forma normal de unin de proteccin (PJ/PN), si y nicamente si cada dependencia de
unin en R es una consecuencia de las claves candidatas de R.
Desnormalizacin de datos
La desnormalizacin de datos es el procedimiento inverso, llevado a cabo puramente
por razones de mejorar la realizacin de sistemas de produccin, particularmente
cuando estn computarizados. La desnormalizacin slo se debe realizar sobre el
diseo. No poner en peligro nunca el modelo de gestin.
La desnormalizacin en formas manuales de procedimientos es necesariamente muy
comn, 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.
Autoevaluacin
Una Base de datos que no est en 3FN
Tiene problemas a nivel de insercin y borrado de datos
Tiene problemas al generar el backup
Tiene problemas a nivel de generacin de roles
Tiene problemas de identidad
Leccin 5. Transacciones
Una transaccin es una unidad de la ejecucin de un programa que accede y
posiblemente actualiza varios elementos de datos. Se delimita dependiendo del
lenguaje por las sentencias inicio transaccin y fin transaccin y se compone de todas
las instrucciones que se encuentran entre estos dos delimitadores.
Propiedades de la transaccin
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 continuacin
explicamos cada una de estas propiedades:
Asegura que o bien todos los efectos de la transaccin 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 transaccin se haya ejecutado parcialmente.
ia:
Asegura que si la base de datos es consistente inicialmente, la ejecucin de la
transaccin deja la base de datos en un estado consistente.
Asegura que en la ejecucin concurrente de transacciones, estas estn aisladas unas
de otras, de tal manera que cada una tiene la impresin de que ninguna otra
transaccin se ejecuta concurrentemente con ella.
Asegura que una vez que la transaccin se ha comprometido, las actualizaciones
hechas por la transaccin no se pierden, incluso si hay un fallo en el sistema.
Una transaccin que termina con xito se dice que est comprometida (commited), una
transaccin 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 transaccin slo puede estar en uno de los siguientes estados:
ejecucin.
transaccin.
cucin normal.
base de datos a su estado anterior al comienzo de la transaccin.
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 interaccin entre las transacciones concurrentes. Puesto que una
transaccin por definicin conserva la consistencia, una ejecucin lineal de
transacciones la garantiza tambin. Un sistema que asegure esta propiedad se dice
que asegura la secuencialidad.
Concurrencia
Existen varios esquemas de control de concurrencia que aseguran la secuencialidad,
todos estos esquemas o bien retrasan una operacin o bien abortan la transaccin que
ha realizado la operacin. Los ms conocidos son los protocolos de bloqueo, el
esquema de ordenacin por marcas temporales, las tcnicas de validacin, el esquema
de granularidad mltiple y los esquemas multiversin.
Un protocolo de bloqueo es un conjunto de reglas que indican el momento en que una
transaccin puede bloquear o desbloquear un objeto de la base de datos. El protocolo
de bloqueo de dos fases permite que una transaccin bloquee un objeto slo despus
de que haya desbloqueado otro objeto distinto, este mtodo asegura la secuencialidad.
El esquema de ordenacin 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 lgico 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
transaccin se retrasa y se le asigna una nueva marca temporal. Por ejemplo, una
operacin leer se puede retrasar porque todava no se ha escrito el valor apropiado o
incluso rechazar si ha sobrescrito el valor que supuestamente se iba a leer.
Un esquema de validacin es un mtodo de control de concurrencia adecuado para
transacciones de slo lectura y en las cuales la tasa de conflictos es baja. Se basa en
dividir una transaccin en 3 etapas (lectura, validacin y escritura) y trabajar con el
esquema de marcas temporales sobre la etapa de validacin. 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 sincronizacin. Se define como una jerarqua 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 ms un nuevo tipo de bloqueo llamado el bloqueo intencional, el cual indica
que existen nodos descendientes que tienen bloqueos compartidos o exclusivos.
El esquema multiversin se basa en la creacin de nuevas versiones de los elementos
de datos cada vez que una transaccin 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 versin que se va a leer se elige de forma que
asegure la secuencialidad por medio de marcas temporales. En este esquema una
operacin de lectura tiene xito siempre, sin embargo, una operacin de escritura
puede provocar el retroceso de una transaccin.
Un sistema est en estado de interbloqueo si existe un conjunto de transacciones tal
que toda transaccin del conjunto est esperando a otra transaccin del conjunto. En
tal situacin, ninguna de las transacciones puede progresar. Existen 2 mtodos 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 prevencin
de interbloqueos asegura que el sistema nunca llegar a un estado de interbloqueos
mientras que el mtodo de deteccin y de interbloqueos permite que el sistema llegue a
un estado de interbloqueos para luego tratar de recuperarse. La prevencin se usa
normalmente cuando la probabilidad de que el sistema llegue a un estado de
interbloqueo es relativamente alta, de lo contrario lo ms conveniente es usar la
deteccin y recuperacin.
Seguridad y recuperacin de datos
Los fallos que ocurren en un computador pueden darse por diferentes motivos (fallos de
disco, cortes de energa o fallos en el software). En cada uno de estos casos puede
perderse informacin concerniente a la base de datos. Existen varios tipos de fallas, a
considerar:
sistema. Un error lgico ocurre cuando una transaccin no puede continuar con su
ejecucin normal a causa de una condicin interna como lo es un desbordamiento o un
exceso de recursos. Un error del sistema ocurre cuando el sistema se encuentra en un
estado no deseado como en el caso de los interbloqueos.
software de base de datos. Comnmente causa la prdida del contenido de la memoria
primaria y aborta el procesamiento de una transaccin.
lo sirve la recuperacin por medio de copias existentes
en medios de almacenamiento secundario como cintas magnticas.
La forma ms aceptada de lograr un tipo de almacenamiento lo ms estable posible es
replicando la informacin en varios medios de almacenamiento no voltil, con modos de
fallos independientes. Los sistemas RAID (disposicin redundante de discos
independientes) garantizan que el fallo de un slo disco no conduzca a la perdida de
datos. Sin embargo los sistemas RAID, no pueden proteger al sistema de una prdida
de datos en el caso de una catstrofe geogrfica, 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 ms seguros guardan copias de cada bloque de
almacenamiento en otra disposicin geogrfica, 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 transaccin
sea atmica. Garantizar la propiedad de atomicidad es responsabilidad del esquema de
recuperacin.
Existen bsicamente 2 esquemas que garantizan la atomicidad.
Basados en el registro histrico. Todas las modificaciones se graban en el registro
histrico, el cual debe estar guardado en almacenamiento estable. En el esquema de
modificacin diferida, durante la ejecucin de una transaccin, se difieren todas las
operaciones de escritura hasta que la transaccin se compromete parcialmente,
momento en el cual se utiliza la informacin del registro histrico asociado con la
transaccin para ejecutar las escrituras diferidas. Con la tcnica de modificacin
inmediata todas las modificaciones se aplican directamente en la base de datos. Si
ocurre una cada se utiliza la informacin del registro histrico para llevar a la base de
datos a un estado estable previo.
Paginacin en la sombra. Durante la vida de una transaccin se mantienen 2 tablas de
pginas: la tabla actual de pginas y la tabla de pginas sombra. Ambas tablas son
idnticas al principio de la transaccin, sin embargo, la tabla actual de pginas puede ir
cambiando luego de cada operacin escribir. Todas las operaciones de lectura y
escritura utilizan la tabla de pginas actual, cuando una transaccin se compromete
parcialmente se desecha la tabla de pginas sombra y la tabla actual se convierte en la
nueva tabla de pginas. Si la transaccin fracasa, simplemente se desecha la tabla
actual de pginas.
El procesamiento de transacciones se basa en un modelo de almacenamiento en el
cual la memoria principal contiene una memoria intermedia para el registro histrico,
una memoria intermedia para la base de datos y una memoria intermedia para el
sistema. Una implementacin eficiente de un esquema de recuperacin de datos
requiere que sea mnimo el nmero de escrituras de la base de datos y que sea
realizado en almacenamiento estable. Los registros del registro histrico pueden
guardarse inicialmente en la memoria intermedia del registro histrico pero deben ser
llevados a almacenamiento estable bajo dos situaciones:
que referencien a la transaccin T
i
antes de grabar el registro que indique que la
transaccin T
i
ha sido comprometida
os los registros del registro histrico
pertenecientes a los datos de un bloque antes de que ese bloque de datos se
escriba desde la memoria intermedia a la base de datos.
Consultas
El Procesamiento de consultas hace referencia a la serie de actividades a seguir para
llevar a cabo la recuperacin de datos desde una base de datos. Estas actividades
incluyen la traduccin de consultas en lenguajes de consultas de alto nivel (Ej: SQL) a
expresiones que se puedan implementar en un nivel fsico, as como tambin los
algoritmos de evaluacin y optimizacin de consultas.
Recuperacin
Una de las ventajas principales del modelo relacional presentado por Codd en 1970 es
la que tiene relacin con la independencia de los datos que se entiende aqu como la
separacin entre el modelo (lgico) y la implementacin (fsica). Esta separacin nos
permite desarrollar una poderosa semntica lgica independiente de una
implementacin fsica particular.
Uno de los desafos de la independencia de datos es que la codificacin de una
consulta para la base de datos se componga de 2 fases:
1. La descripcin lgica de la consulta (que se supone que debe hacer).
2. La definicin del plan de ejecucin fsico (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 representacin interno con el cual le sea fcil operar. As, por ejemplo
para SQL la representacin ms til es la del lgebra relacional extendida (rbol
relacional). Este proceso cumple la misma funcin que el analizador lxico y sintctico
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 expresin relacional que la representa.
El plan de ejecucin es un rbol relacional armado a partir de la consulta y que slo
puede ser entendido por el motor de ejecucin de consultas. La transformacin 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 podra ser la mejor estrategia,
sin embargo, una de las ventajas que nos ofrece el modelo relacional es la capacidad
de usar la informacin del catalogo de la base de datos, que como se ver ms
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 mecnico que garantice que el plan de ejecucin elegido satisfaga la
consulta que se quiere implementar, puesto que:
1. Un Plan calculado a mano (o un plan precalculado) ser invalidado por cambios
lgicos dentro del esquema o por cambios fsicos en el camino de acceso a la
informacin o en el almacenamiento fsico.
2. Si los parmetros de la consulta (o los datos) cambian, la relacin 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
Despus de enviar la consulta, la base de datos debe producir su correspondiente plan
de ejecucin. El primer paso en este proceso es traducir la consulta desde SQL a un
rbol lgico en lgebra relacional, proceso comnmente llamado parser.
El Prximo paso es traducir el rbol de la consulta en el plan de ejecucin.
Generalmente existe un gran nmero de planes que implementan al rbol de la
consulta; el proceso de encontrar el mejor de estos planes se le denomina optimizacin
de consultas.
Clculo relacional
La manipulacin del modelo relacional esta basada en el lgebra relacional; sin
embargo, de igual forma podemos indicar que tambin esta basada en el clculo
relacional. lgebra y clculo son alternativos entre s, la diferencia entre ellos es la
siguiente: mientras que el lgebra proporciona un conjunto de operadores explcitos
(juntar, unir, proyectar, etc), que pueden usarse para indicar al sistema cmo construir
cierta relacin dada, al clculo simplemente proporciona una notacin para establecer
la definicin de esa relacin deseada en trminos de dichas relaciones dadas
4
El clculo relacional de tuplas describe la informacin deseada sin dar un
procedimiento especfico para obtenerla. Las consultas en el clculo relacional de
tuplas se expresan como:
4
C.J Date, Introduccin a los Sistemas de Bases de Datos, Prentice Hall
{ t | P(t)},
Es decir, son el conjunto de tuplas t tales que se cumple el predicado P para cada t.
Siguiendo la misma notacin, se utiliza t[A] para el valor de la tupla t en el atributo A.
Si slo se desea obtener un atributo de la tupla, se utiliza el constructor Existe de la
lgica matemtica. As, si lo que se desea es el Nombre de los dueos de taxis que
estn vigentes:
"Conjunto de todas las tuplas t tales que existe una tupla s en la relacin Dueo 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 slo en el atributo Nombre,
puesto que ste es el nico atributo para el que se especifica una condicin para t. As,
el resultado es una relacin sobre (Nombre).
Si lo que se desea es obtener las tarifas de todos los viajes que ha efectuado todos los
mviles de marca chevrolet, la consulta requiere de dos clusulas Existe conectadas
por el operador de conjuncin lgica y.
Que se lee como el conjunto de todas las tuplas (tarifa) correspondientes a los viajes
que han hecho todos los mviles de marca chevrolet.
Considrese ahora la consulta obtener todos los RUT de los dueos de mviles, cuyos
mviles no hayan efectuado nunca un viaje:
que ocupa la clusula Existe para exigir que el dueo posea un mvil y la clusula no
existe para eliminar a aquellos mviles que tengan viajes realizados.
La consulta que se presenta a continuacin utiliza la implicacin, la frmula 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 chferes les
caduca la licencia el 01/01/1999.
Sin embargo como la intencin del modulo no es la de suplir al texto, se recomienda
consultar el tema completo en la bibliografa recomendada.
Optimizacin de consultas
Las consultas de base de datos relacionales son o bien declarativas o algebraicas. Los
lenguajes algebraicos permiten la transformacin algebraica de la consulta, luego,
basndose en la especificacin algebraica de la consulta es relativamente fcil 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
cdigo de un compilador para el lenguaje SQL, que produce el cdigo que ser
interpretado por el motor de ejecucin de consultas, excepto que el optimizador marca
nfasis en la capacidad de producir el cdigo ms eficiente, haciendo uso para tales
efectos del catlogo de la base de datos, de donde obtiene informacin estadstica de
las relaciones referenciadas por la consulta, algo que los lenguajes de programacin
tradicionales no hacen.
Un aspecto de la optimizacin de consultas se sita en el nivel del lgebra relacional.
Dado un conjunto de reglas se trata de encontrar una expresin que sea equivalente a
la expresin dada pero que sea ms eficiente en la ejecucin.
Con el fin de seleccionar la mejor estrategia para la recuperacin de datos el
optimizador estima un costo que estar relacionado a cada plan de ejecucin. Este
costo est determinado por frmulas predefinidas en base a informacin que se posee
de la tabla y que se ha rescatado previamente del catlogo de la base de datos, en
realidad el optimizador no siempre escoge el plan ms ptimo, ya que encontrar la
estrategia ptima puede consumir mucho tiempo, por lo tanto se dice que el
optimizador slo escoge una estrategia razonablemente eficiente. La manera con la
que el optimizador utiliza esa informacin, las distintas tcnicas 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 evaluacin para una
consulta y luego elige el que tiene un menor costo asociado, las medidas de costo
comnmente tienen que ver con la E/S y el tiempo de CPU utilizado en ejecutar la
consulta, sin embargo, es cuestin de cada SGBD el elegir las medidas de costo que
mejor representen el criterio de minimizacin en la utilizacin de recursos.
Autoevaluacin
Una de las propiedades de la transaccin es la de Aislamiento. En bases de datos, el
Aislamiento significa
Una transaccin A no puede ver datos de una transaccin B, mientras la
transaccin B no termine.
Una transaccin A puede ver datos de una transaccin B siempre
Una transaccin A no puede ver datos de una transaccin B, mientras B no le
asigne timesptamp
Una transaccin A no puede ver datos de una transaccin B, mientras tenga
abiertas tablas
Referencias
CERI S, Pelagatti G.,Distributed databases principles & systems.. Ed. MacGraw-Hill.
1985.
DATE, C. J, Introduccin a los sistemas de bases de datos. Ed. Prentice Hall. Sptima
edicin.
SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGraw-
Hill. Cuarta edicin
OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill
www.lsi.us.es/docencia/asignaturas/dbd.html
www.cieloprogramadores.com
Captulo 2. Diseo de bases de datos distribuidas
Leccin 6. Bases de datos distribuidas
Introduccin y fundamentos de Base de Datos Distribuidas.
La cantidad de innovaciones tecnolgicas que ha habido en los ltimos aos ha
promovido un cambio en la forma de observar a los sistemas de informacin y, en
general, a las aplicaciones computacionales. Existen avances tecnolgicos que se
realizan continuamente en circuitos, dispositivos de almacenamiento, programas y
metodologas. Sin embargo, los cambios tecnolgicos van de la mano con la demanda
de los usuarios y programas para la explotacin exhaustiva de tales dispositivos
mejorados. Por tanto, existe un continuo desarrollo de nuevos productos los cuales
incorporan ideas nuevas desarrolladas por compaas e instituciones acadmicas.
An cuando es posible que un usuario comn no perciba los desarrollos relevantes de
nuevos productos, para las aplicaciones existe una demanda permanente por mayor
funcionalidad, mayor nmero de servicios, ms flexibilidad y mejor rendimiento. As, al
disear un nuevo sistema de informacin o al prolongar la vida de uno ya existente, se
debe buscar siempre formas para enlazar las soluciones ofrecidas por la tecnologa
disponible a las necesidades de las aplicaciones de los usuarios.
Un rea en la cual las soluciones estn integrando tecnologa con nuevas arquitecturas
o formas de hacer las cosas es, sin lugar a dudas, el rea de los sistemas distribuidos
de informacin. Ellos se refieren al manejo de datos almacenados en facilidades de
cmputo localizadas en muchos sitios ligados a travs de una red de comunicaciones.
Un caso especfico de estos sistemas distribuidos es lo que se conoce como bases de
datos distribuidas, tpico a estudiar en estas notas.
Conceptualizacin de Bases de Datos Distribuidas.
Los sistemas de bases de datos distribuidas son un caso particular de los sistemas de
cmputo distribuido en los cuales un conjunto de elementos de procesamiento
autnomos (no necesariamente homogneos) se interconectan por una red de
comunicaciones y cooperan entre ellos para realizar sus tareas asignadas.
Histricamente, el cmputo distribuido se ha estudiado desde muchos puntos de vista.
As, es comn encontrar en la literatura un gran nmero de trminos que se han usado
para identificarlo. Entre los trminos ms comunes que se utilizan para referirse al
cmputo distribuido podemos encontrar: funciones distribuidas, procesamiento
distribuido de datos, multiprocesadores, multicomputadoras, procesamiento satelital,
procesamiento tipo "backend", computadoras dedicadas y de propsito especfico,
sistemas de tiempo compartido, sistemas funcionalmente modulares.
Existen muchos componentes a distribuir para realizar una tarea. En computacin
distribuida los elementos que se pueden distribuir son:
radas en una actividad de
procesamiento de informacin.
Figura 18. Motivacin de los sistemas de bases de datos distribuidos.
Una base de datos distribuida (BDD) es un conjunto de mltiples bases de datos
lgicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios
interconectados por una red de comunicaciones (ver Figura18).
Un sistema de base de datos distribuida (SBDD) es un sistema en el cual mltiples
sitios de bases de datos estn 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
distribucin sea transparente a los usuarios. El trmino transparente significa que la
aplicacin trabajara, desde un punto de vista lgico, como si un solo SMBD ejecutado
en una sola mquina, administrara esos datos.
Un sistema de base de datos distribuida (SBDD) es entonces el resultado de la
integracin de una base de datos distribuida con un sistema para su manejo.
Dada la definicin 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 travs 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 administracin esta centralizada en un solo nodo
pero se permite el acceso a ella a travs de la red de computadoras.
Figura 19. Un sistema centralizado sobre una red.
El medio ambiente tpico 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 geogrficamente dispersos, entonces, ellos estn
interconectados por una red de tipo WAN. Por otro lado, si los sitios estn localizados
en diferentes edificios o departamentos de una misma organizacin pero
geogrficamente en la misma ubicacin, entonces, estn conectados por una red local
(LAN) (Figura 20).
Figura 20. Un medio ambiente distribuido para bases de datos.
Tipos de bases de datos distribuidas.
En trminos generales, podemos decir que existen dos tipos de sistemas de bases de
datos distribuidas, homogneas y sistemas de bases de datos distribuidas
heterogneas.
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 administracin 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 comunicacin entre los sistemas de bases de datos
que conforman el sistema, para dar la visin al usuario de integracin y de un nico
sistema de bases de datos.
Autoevaluacin
Una base de datos distribuida heterogenea es
Aquella que incluye diferentes modelos de datos y motores de administracin de
datos
Aquella que tiene los mismos modelos de datos y motores de administracin de
datos
Aquella que incluye diferentes sitios
Aquella que incluye redes de datos
Leccin 7. Bases de datos distribuidas
En el presente captulo se mostrar los aspectos importantes referentes al diseo de
una base de datos distribuida. Se revisar el problema de fragmentacin de los datos
as como la transparencia que un sistema de datos distribuidos debe guardar respecto
a la vista del usuario. Se presentarn los algoritmos para fragmentacin horizontal,
fragmentacin horizontal derivada y fragmentacin vertical. En la parte final de este
captulo se discute el problema de asignacin de fragmentos.
El problema de diseo
El problema de diseo de bases de datos distribuidos se refiere, en general, a tomar
decisiones acerca de la ubicacin de datos y programas a travs de los diferentes sitios
de una red de computadoras. Este problema debera estar relacionado al diseo de la
misma red de computadoras. Sin embargo, en estas notas nicamente el diseo de la
base de datos se toma en cuenta. La decisin 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 diseo de las bases de datos centralizadas contempla los puntos siguientes:
1. Diseo 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. Diseo "fsico de la base de datos", esto es, mapear el esquema conceptual a
las reas de almacenamiento y determinar los mtodos de acceso a las bases
de datos.
En el caso de las bases de datos distribuidas se tienen que considerar los problemas
siguientes:
1. Diseo del esquema conceptual, donde se busca describir el modelo de datos
de todo el sistema
2. Diseo de la fragmentacin, este proceso se determina mediante la divisin de
las tablas en fragmentos horizontales, verticales o mixtos, dependiendo de las
necesidades de informacin detectadas en la etapa de anlisis del sistema.
3. Diseo de la asignacin de los fragmentos, esto determina la forma en que los
fragmentos se mapean en los sitios o nodos del sistema.
4. Diseo de replicacin. Proceso que indica en que lugar (nodos), se ubican
copias de tablas o fragmentos y la frecuencia de actualizacin de la informacin.
Objetivos del Diseo de la Distribucin de los Datos.
En el diseo de la distribucin de los datos, se deben de tomar en cuenta los siguientes
objetivos:
Procesamiento local. La distribucin 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 diseo de la distribucin de los
datos para maximizar el procesamiento local agregando el nmero de referencias
locales y remotas que le corresponden a cada fragmentacin candidata y la localizacin
del fragmento, que de esta forma se seleccione la mejor solucin de ellas.
Distribucin de la carga de trabajo. La distribucin de la carga de trabajo sobre los
sitios, es una caracterstica importante de los sistemas de cmputo distribuidos. Esta
distribucin de la carga se realiza para tomar ventaja de las diferentes caractersticas
(potenciales) o utilizaciones de las computadoras de cada sitio, y maximizar el grado de
ejecucin de paralelismo de las aplicaciones. Sin embargo, la distribucin de la carga
de trabajo podra afectar negativamente el procesamiento local deseado.
Costo de almacenamiento y disponibilidad. La distribucin 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 transmisin de las aplicaciones.
Enfoques al problema de diseo de bases de datos distribuidas
Existen dos estrategias generales para abordar el problema de diseo de bases de
datos distribuidas:
El enfoque de arriba hacia abajo (top-down). Este enfoque es ms apropiado para
aplicaciones nuevas y para sistemas homogneos. Consiste en partir desde el anlisis
de requerimientos para definir el diseo 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 diseo de la fragmentacin de la base de datos, y de aqu se contina
con la localizacin de los fragmentos en los sitios, creando las imgenes fsicas. Esta
aproximacin se completa ejecutando, en cada sitio, "el diseo fsico" 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 diseo 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 diseo bottom-up de una base de datos distribuida requiere de la seleccin
de un modelo de bases de datos comn para describir el esquema global de la base de
datos. Esto se debe, a que es posible que se utilicen diferentes SMBD. Despus se
hace la traduccin de cada esquema local en el modelo de datos comn y finalmente
se hace la integracin del esquema local en un esquema global comn.
Figura 21. El enfoque top-down para el diseo de bases de datos distribuidas.
El diseo de una base de datos distribuida, cualquiera sea el enfoque que se siga, debe
responder satisfactoriamente las siguientes preguntas:
Por qu hacer una fragmentacin de datos?
Cmo realizar la fragmentacin?
Qu tanto se debe fragmentar?
Cmo probar la validez de una fragmentacin?
Cmo realizar el asignamiento de fragmentos?
Cmo considerar los requerimientos de la informacin?
Autoevaluacin
El diseo Top-Down, es mejor desarrollarlo cuando
El sistema de base de datos a trabajar es nuevo, comienza de cero
Ya existen bases de datos y hay que integrarlas en el sistema distribuido
La programacin a utilizar es orientada a objeto
Se utiliza patrones de diseo
Leccin 8. Fragmentacin
Figura 22. El problema de fragmentacin de relaciones.
El problema de fragmentacin se refiere al particionamiento de la informacin para
distribuir cada parte a los diferentes sitios de la red, como se observa en la Figura 22.
Inmediatamente aparece la siguiente pregunta: cul es la unidad razonable de
distribucin? Se puede considerar que una relacin 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
ejecucin concurrente de varias transacciones que accesan porciones diferentes de
una relacin. Sin embargo, el uso de sub-relaciones tambin presenta inconvenientes.
Por ejemplo, las vistas de usuario que no se pueden definir sobre un solo fragmento
necesitarn un procesamiento adicional a fin de localizar todos los fragmentos de una
vista. Aunado a esto, el control semntico de datos es mucho ms 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 relacin. En resumen, el objetivo de la
fragmentacin 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 relacin J del ejemplo visto en la introduccin del presente
captulo.
J:
JNO JNOMBRE PRESUPUESTO LUGAR
J1 Instrumentacin 150000 Guajira
J2 Desarrollo de bases de datos 135000 Cartagena
J3 CAD/CAM 250000 Medelln
J4 Mantenimiento 310000 Cartagena
J5 CAD/CAM 500000 Bogot
La relacin J se puede fragmentar horizontalmente produciendo los siguientes
fragmentos.
J1: Proyectos con presupuesto menor que $200,000
J1 Instrumentacin 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 Medelln
J4 Mantenimiento 310000 Cartagena
J5 CAD/CAM 500000 Bogot
Ejemplo 2. La relacin J del ejemplo anterior se puede fragmentar verticalmente
produciendo los siguientes fragmentos:
J1: informacin acerca de presupuestos de proyectos
JNO PRESUPUESTO
J1 150000
J2 135000
J3 250000
J4 310000
J5 1500000
J2: informacin acerca de los nombres y ubicaciones de proyectos
JNO JNOMBRE LUGAR
J1 Instrumentacin Guajira
J2 Desarrollo de bases de datos Cartagena
J3 CAD/CAM Medelln
J4 Mantenimiento Cartagena
J5 CAD/CAM Bogot
Figura 23. El grado de fragmentacin.
Correctitud de una fragmentacin: Al realizar la fragmentacin de una relacin se
deben satisfacer las siguientes condiciones para garantizar la correctitud de la misma:
Condicin de completitud. La descomposicin de una relacin R en los fragmentos R1,
R2, ..., Rn es completa si y solamente si cada elemento de datos en R se encuentra en
algn de los Ri.
Condicin de Reconstruccin. Si la relacin R se descompone en los fragmentos R1,
R2, ..., Rn, entonces debe existir algn operador relacional U , tal que,
R = U 1 i <= n Ri
Condicin de Fragmentos Disjuntos. Si la relacin R se descompone en los fragmentos
R1, R2, ..., Rn, y el dato di est en Rj, entonces, no debe estar en ningn otro
fragmento Rk (k j).
Alternativas sobre replicacin para el asignamiento de fragmentos
La replicacin de informacin es de utilidad para obtener un mejor rendimiento y para
ofrecer un mayor grado de confiabilidad (tolerancia a fallas). La replicacin se complica
cuando es necesario hacer actualizaciones a las copias mltiples de un dato. Por tanto,
respecto a la replicacin, en el asignamiento de fragmentos se tienen tres estrategias:
Como regla general se debe considerar que la replicacin de fragmentos es de utilidad
cuando el nmero de consultas de solo lectura es (mucho) mayor que el nmero de
consultas para actualizaciones. En la Tabla 1 se comparan la complejidad de
implementar o tomar ventaja de las diferentes alternativas de replicacin, respecto de
los diferentes aspectos importantes en bases de datos distribuidas.
Recopilacin
completa
Recopilacin Parcial Particionamiento
Procesamiento de
Consultas
Fcil Moderado Moderado
Manejo de Directorios Fcil o no existente Moderado Moderado
Control de
Concurrencia
Moderado Difcil Fcil
Confiabilidad Muy alto Alto Bajo
Realidad Aplicacin posible Realista Aplicacin posible
Tabla 2. Comparacin de las estrategias de replicacin de fragmentos.
Requerimientos de informacin:
Con el fin de realizar una fragmentacin adecuada es necesario proporcionar
informacin que ayude a realizarla. Esta informacin normalmente debe ser
proporcionada por el usuario y tiene que ver con cuatro tipos:
Autoevaluacin
En trminos generales, la fragmentacin busca
Que la informacin se administre en el sitio donde ella pertenece
Que la informacin se administre en todos los sitios
Que la informacin se administre verticalmente
Que la informacin se administre horizontalmente
Leccin 9. Tipos de fragmentacin de datos
Existen tres tipos de fragmentacin:
En las siguientes secciones revisaremos de manera informal cada uno de los tipos
mencionados. Ms adelante, se presentar de manera ms formal la construccin de
los diferentes tipos de fragmentacin.
Fragmentacin horizontal primaria
Consiste del particionamiento en tuplas de una relacin global en subconjuntos, donde
cada subconjunto puede contener datos que tienen propiedades comunes y se puede
definir expresando cada fragmento como una operacin de seleccin sobre la relacin
global.
Ejemplo 3. Considere la relacin global
SUPPLIER (SNUM, NAME, CITY)
entonces, la fragmentacin horizontal puede ser definida como:
SUPPLIER1 = SLcity == "SF"SUPPLIER
SUPPLIER1 = SLcity == "LA"SUPPLIER
Esta fragmentacin satisface la condicin de completes si "SF" y "LA" son solamente
los nicos valores posibles del atributo CITY.
2. La condicin de reconstruccin se logra con:
SUPPLIER = SUPPLIER1 unin SUPPLIER2
3. La condicin de disjuntos se cumple claramente en este ejemplo.
Fragmentacin horizontal derivada
La fragmentacin derivada horizontal se define partiendo de una fragmentacin
horizontal.
En esta operacin 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 fragmentacin horizontal derivada de
la relacin SUPPLY.
SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1
Fragmentacin vertical
La fragmentacin vertical es la subdivisin de atributos en grupos. Los fragmentos se
obtienen proyectando la relacin global sobre cada grupo. La fragmentacin es correcta
si cada atributo se mapea en al menos un atributo del fragmento.
Ejemplo 5. Considere la siguiente relacin global:
EMP( empnum, name, sal, tax, mgrnum, depnum )
una fragmentacin vertical de esta relacin puede ser definida como:
EMP1 = PJempnum, name, mgrnum, depnum EMP
EMP2 = PJempnum, sal, tax EMP
La reconstruccin de la relacin EMP puede ser obtenida como:
EMP = EMP1 (JN empnum) EMP2 porque empnum es una clave de EMP
Fragmentacin hbrida
En lo que respecta a la fragmentacin hbrida, esta consiste en aplicar la fragmentacin
vertical seguida de la fragmentacin horizontal o viceversa.
Ejemplo 6. Considere la relacin global
EMP (empnum, name, sal, tax, mrgnum, depnum)
Las siguientes son para obtener una fragmentacin 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 reconstruccin de la relacin EMP es definida por la siguiente expresin:
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)
Despus de aplicar una fragmentacin 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)
Autoevaluacin
La fragmentacin
se trabaja a nivel de tabla
Verdadero Falso
Leccin 10. Diseo de replica
La replicacin de informacin es de utilidad para obtener un mejor rendimiento y para
ofrecer un mayor grado de confiabilidad (tolerancia a fallas). Se entiende por
Replicacin, la administracin de copias de fragmentos o tablas y de asegurar su
actualizacin en los periodos de tiempo definidos por el administrador del sistema.
La replicacin se complica cuando es necesario hacer actualizaciones a las copias
mltiples de un dato. Por tanto, respecto a la replicacin, en la asignacin de
fragmentos se tienen tres estrategias:
1 No soportar replicacin. Cada fragmento reside en un solo sitio.
2 Soportar replicacin completa. Cada fragmento en cada uno de los sitios.
3 Soportar replicacin parcial. Cada fragmento en algunos de los sitios.
Como regla general se debe considerar que la replicacin de fragmentos es de utilidad
cuando el nmero de consultas de solo lectura es (mucho) mayor que el nmero de
consultas para actualizaciones. En la Tabla 1 se comparan la complejidad de
implementar o tomar ventaja de las diferentes alternativas de replicacin, respecto de
los diferentes aspectos importantes en bases de datos distribuidas.
Adems de indicar en que sitios se desea guardar copia de la entidad o tabla, es
necesario definir la frecuencia o periodo de actualizacin de la copia. En este sentido,
podemos encontrar los siguientes tipos de rplica:
1 En tiempo real, es decir en el momento que un sitio actualiza un registro
(insercin, modificacin y borrado de registros), se enva una copia de la
informacin a los sitios donde reside la copia.
2 Copia fuera de lnea, esta opcin permite que una vez registrada la transaccin
en el sitio donde ella se genera, pueda pasar un tiempo para actualizar las copias
de la informacin almacenadas en otros lugares.
Con estos dos tipos de replicacin, es posible definir varios modelos de sistemas de
replica:
1. Maestro - maestro, hace que una vez generada y registrada una transaccin en un
sitio del sistema, inmediatamente se actualicen las copias de la informacin que se
guardan en los otros sitios. Este modelo, aumenta la opcin de acceso a datos desde
cualquier punto, aumentando la disponibilidad del sistema. El mayor problema de este
modelo es que debe garantizarse canales de comunicacin entre los nodos en todo
momento, de tal manera que se asegure la copia de los fragmentos cuando la
transaccin se realice, de lo contrario el sistema cae en un estado de invalidez de
informacin.
2. Maestro-copia. Este modelo permite que la actualizacin de los sitios pueda
generarse en un periodo de tiempo T despus de generarse una t transaccin 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 comunicacin, 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 determinacin de un sitio, donde se
guardarn las replicas de los datos. Una vez se realice una transaccin 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 informacin 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
Autoevaluacin
El modelo Maestro Bodega indica que
Cada vez que se modifique un dato en el Maestro, actualiza la informacin en el
sitio de la bodega de datos
Cada vez que se modifique un dato en el Maestro, actualiza en todos los dems
sitios involucrados
Cada vez que se modifique un dato en el Maestro, solo se actualiza el sitio
maestro
Cada vez que se modifique un dato en el Maestro, se hace rplica
Capitulo 3. Consultas
Leccin 11. Consultas distribuidas
El procesamiento de consultas es de suma importancia en bases de datos
centralizadas. Sin embargo, en BDD ste adquiere una relevancia mayor. El objetivo es
convertir transacciones de usuario en instrucciones para manipulacin 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 optimizacin 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 transmisin de informacin al lugar en donde se
solicit la consulta.
Objetivo del procesamiento de las consultas
En un sistema de base de datos es posible cambiar la estructura inicial, pero es algo
que puede resultar muy costoso desde el punto de vista de tiempo y dinero. Por tanto,
cuando se presenta una consulta al sistema, es necesario hallar el mejor mtodo de
encontrar la respuesta utilizando la estructura existente de la base de datos. Existe un
gran nmero 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 seleccin de una buena estrategia. El coste de
procesar una consulta normalmente est dominado por el acceso al disco. Pero, en un
sistema distribuido es preciso tener en cuenta otros factores, como son:
procesaran en paralelo partes de la consulta.
La diferencia entre una buena estrategia y una mala, en trminos del nmero de
accesos a disco requeridos y el coste de transmisin 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 slo una vez.
Niveles de procesador de consultas
Existen varios medios para calcular la respuesta a una consulta; siempre debe elegirse
una estrategia de procesamiento de consultas que reduzca al mnimo 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 especfica es el nmero de accesos
al disco. En un sistema distribuido es preciso tener en cuenta otros factores, como son:
El coste de transmisin de datos en la red.
procesaran en paralelo partes de la consulta.
El coste relativo de la transferencia de datos en la red y la transferencia de datos entre
la memoria y el disco vara 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
slo los costes del disco o los de la red. Es necesario llegar a un equilibrio adecuado
entre los dos.
Localizacin de datos
Consideremos una consulta muy sencilla: Encontrar todas las tuplas de la relacin
depsito. Aunque la consulta es muy simple, de hecho es trivial; su procesamiento no
es trivial, ya que es posible que la relacin depsito est fragmentada, repetida o las
dos cosas. Si la relacin depsito 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 transmisin ms reducidos. Pero si una copia est fragmentada, la eleccin
no es tan sencilla, ya que es preciso calcular varios productos o uniones para
reconstruir la relacin depsito. En tal caso, el nmero de estrategias para este ejemplo
sencillo puede ser grande. De hecho, la eleccin de una estrategia puede ser una tarea
tan compleja como hacer una consulta arbitraria.
La transparencia de la fragmentacin implica que el usuario puede escribir una consulta
como sta:
Puesto que depsito est definido como
La expresin que resulta del esquema de traduccin de nombres es
Al emplear las tcnicas de optimizacin podemos simplificar de manera automtica esta
expresin. La expresin que resulta es
La cual incluye dos subexpresiones. La primera incluye slo depsito1 y, por tanto,
puede ser calculada en la localidad de Riverside. La segunda incluye solamente
depsito2 y, por tanto, puede ser calculada en la localidad de Columbia.
Existe an una optimizacin que se puede hacer as:
Puesto que depsito1 tiene solamente tuplas de pertenecientes a la sucursal Riverside,
podemos eliminar la operacin de seleccin. Calculando
Podemos aplicar la definicin del fragmento depsito2 para obtener
Esta expresin es el conjunto vaco, independientemente del contenido de la relacin
depsito.
As, nuestra estrategia final para la localidad Riverside consistir en devolver depsito1
como resultado de la consulta.
Procesamiento de interseccin simple
Un aspecto importante de la eleccin de una estrategia de procesamiento de consulta
es elegir una estrategia de interseccin. Considere la expresin algebraica relacional:
Cliente |x| depsito |x| sucursal
Suponemos que ninguna de las tres relaciones est repetida o fragmentada y que
cliente est almacenada en la localidad L
c
, depsito en la L
d
y sucursal en la L
b
. Sea L
i
la localidad donde se origin la consulta. El sistema debe producir el resultado en la
localidad Li. Entre las posibles estrategias para procesar posibles estrategias para
procesar esta consulta se encuentran en las siguientes:
i
. Escoger una estrategia para
procesar en forma local la consulta completa en L
i
.
d
y calcular cliente |x|
depsito de L
d
. Enviar cliente |x| depsito de L
d
a L
b
, donde se calcula (cliente |x|
deposito) |x| sucursal. El resultado de esta operacin es enviado a Li.
de L
c
, L
d
y L
b
.
No puede garantizarse que una estrategia sea la mejor en todos los casos. Entre los
factores que deben tener en cuenta estn 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 envan las tres relaciones a L
i
y existen ndices para
ellas, puede ser necesario volver a crear esos ndices en L
i
. Esto requiere tiempo extra
de procesamiento y ms accesos al disco. Sin embargo, la segunda estrategia tiene la
desventaja de que una relacin potencialmente grande (cliente |x| deposito) debe
transmitirse desde L
d
a L
b
. Esta relacin repite los datos del domicilio de un cliente una
vez por cada cuenta que tenga el cliente. As, la segunda estrategia puede requerir la
transmisin de un volumen mayor que la primera estrategia.
Tambin pueden utilizarse dos estrategias adicionales, la de interseccin utilizando el
paralelismo y la estrategia de semi-interseccin.
Autoevaluacin
La consulta de datos intenta reducir el costo de trasmisin
Verdadero Falso
Leccin 12. Descomposicin de una consulta y localizacin 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 representacin interna de una consulta
dentro del sistema. Una representacin interna ms til es la que se basa en el lgebra
relacional.
La primera accin que el sistema debe tomar en una consulta es traducirla a su forma
interna. Este proceso de traduccin es similar al trabajo realizado por el analizador
sintctico (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 trminos de una vista, el parser
sustituye todas las referencias al nombre de la vista por la expresin 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 optimizacin. La primera fase de la optimizacin se lleva a cabo en el nivel
del lgebra relacional. Se hace un intento para encontrar una expresin que sea
equivalente a la expresin dada, pero que pueda ejecutarse de manera eficiente. La
siguiente fase implica la seleccin de una estrategia detallada para procesar la
consulta. Debe tomarse una decisin acerca de la manera exacta en que se va a
ejecutar la consulta. Se deben elegir los ndices especficos que se van a usar. Se debe
determinar el orden en que se van a procesar las tuplas. La eleccin final de una
estrategia se basa principalmente en el nmero de accesos a disco que se requieran.
Plan de optimizacin de consultas distribuidas
Dada una consulta, generalmente existe una variedad de mtodos 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 ms 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 ms eficiente. Esta optimizacin, o ms
exactamente, mejora de la estrategia para procesar una consulta se llama optimizacin
de consultas. Existe una analoga entre la optimizacin de consultas por un sistema de
base de datos.
La optimizacin de consultas es una cuestin importante en cualquier sistema de base
de datos puesto que la diferencia en tiempo de ejecucin entre una buena estrategia y
una mala puede ser enorme. En el modelo de red y en el modelo jerrquico la
optimizacin de consultas se deja en su mayor parte al programador de aplicaciones.
Esto se debe a que las sentencias de los lenguajes de manipulacin de datos de estos
dos modelos normalmente se incorporan en un lenguaje de programacin principal, y
no es fcil transformar una consulta de red o jerrquica en una equivalente sin
conocimiento del programa de aplicacin completo.
Ya que una consulta relacional puede expresarse completamente en un lenguaje de
consulta relacional sin emplear un lenguaje principal, es posible realizar
automticamente una cantidad importante de optimizacin de consultas.
Algunos sistemas reducen el nmero de estrategias que necesitan ser completamente
consideradas haciendo una suposicin heurstica de una estrategia buena. Segn 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, slo unas pocas estrategias competentes requerirn un anlisis
completo del coste. Esto puede reducir el tiempo de optimizacin de consultas.
Para simplificar la tarea de seleccin de estrategias se debe dividir una consulta en
varias subconsultas. Esto no slo simplifica la seleccin de estrategias sino que
tambin 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
optimizacin de la consulta como en la ejecucin de la consulta. El reconocimiento de
subconsultas comunes es anlogo al reconocimiento de subexpresiones comunes en
muchos compiladores optimizadores de lenguajes de programacin.
Es obvio que examinar la consulta buscando subconsultas comunes y estimar el coste
de un gran nmero de estrategias supone un tiempo extra considerable en el
procesamiento de consultas. Sin embargo, el coste adicional de optimizacin de
consultas generalmente se compensa con creces por el ahorro en el tiempo de
ejecucin de la consulta. El ahorro logrado es an mayor en aquellas aplicaciones que
se ejecutan sobre una base regular y vuelven a ejecutar las mismas consultas en cada
ejecucin. Por tanto, la mayor parte de los sistemas comerciales incluyen optimizadores
relativamente sofisticados.
Autoevaluacin
Todo Sistema Manejador de Bases de Datos incluye optimizadores de consulta
Verdadero Falso
Leccin 13. Transacciones Distribuidas
Hasta este momento, las primitivas bsicas 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 ejecucin de una consulta. Dada la naturaleza de una consulta, de
lectura o actualizacin, a veces no se puede simplemente reactivar la ejecucin 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 informacin en la base de datos
contenga datos incorrectos.
El concepto fundamental aqu es la nocin de "ejecucin consistente" o "procesamiento
confiable" asociada con el concepto de una consulta. El concepto de una transaccin
es usado dentro del dominio de la base de datos como una unidad bsica de cmputo
consistente y confiable.
Definicin de una transaccin
Una transaccin es una coleccin 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 informacin. Por supuesto, se quiere
asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin
embargo, durante la ejecucin de una transaccin, 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 ejecucin de una transaccin
(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 transaccin.
Ejemplo 1. Considere la siguiente consulta en SQL para incrementar el 10% del
presupuesto del proyecto CAD/CAM de la base de datos de ejemplo.
UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"
Esta consulta puede ser especificada, usando la notacin de SQL, como una
transaccin otorgndole un nombre:
Begin_transaction ACTUALIZA_PRESUPUESTO
begin
UPDATE J
SET BUDGET = BUDGET*1.1
WHERE JNAME = "CAD/CAM"
end.
Ejemplo 2. Considere una agencia de reservaciones para lneas areas con las
siguientes relaciones:
FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP )
CUST( CNAME, ADDR, BAL )
FC( FNO, DATE, CNAME, SPECIAL )
Una versin simplificada de una reservacin tpica puede ser implementada
mediante la siguiente transaccin:
Begin_transaction Reservacin
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("reservacin terminada");
end.
Condiciones de terminacin de una transaccin
Una transaccin siempre termina, aun en la presencia de fallas. Si una transaccin
termina de manera exitosa se dice que la transaccin hace un commit (se usar el
trmino en ingls cuando no exista un trmino en espaol que refleje con brevedad el
sentido del trmino en ingls). Si la transaccin se detiene sin terminar su tarea, se dice
que la transaccin aborta. Cuando la transaccin es abortada, su ejecucin es detenida
y todas sus acciones ejecutadas hasta el momento son deshechas (undone)
regresando a la base de datos al estado antes de su ejecucin. A esta operacin
tambin se le conoce como rollback.
Ejemplo 3. Considerando de nuevo el Ejemplo 3.2, veamos el caso cuando no
existen asientos disponibles para hacer la reservacin.
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("reservacin terminada");
endif
end.
Caracterizacin 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 transaccin se dice que constituyen el conjunto de lectura (RS).
Similarmente, los elementos de datos que una transaccin escribe se les denomina el
conjunto de escritura (WS). Note que los conjuntos de lectura y escritura no tienen que
ser necesariamente disjuntos. La unin de ambos conjuntos se le conoce como el
conjunto base de la transaccin (BS = RS U WS).
Ejemplo 4. Los conjuntos de lectura y escritura de la transaccin del Ejemplo 3.3 son:
RS[Reservacin] = { FLIGHT.STSOLD, FLIGHT.CAP }
WS[Reservacin] = { FLIGHT.STSOLD, FC.FNO, FC.DATE, FC.NAME,
FC.SPECIAL }
Formalizacin del concepto de transaccin
Sea Oij(x) una operacin Oj de la transaccin Ti la cual trabaja sobre alguna entidad x.
Oj Oj es una operacin atmica, esto es, se ejecuta como una unidad
indivisible. Se denota por OSi = U j Oij al conjunto de todas las operaciones de la
transaccin Ti. Tambin, se denota por Ni la condicin de terminacin para Ti, donde,
Ni
La transaccin Ti es un orden parcial, Ti = { I i, <i }, donde
Sumatoria i = OSi I {Ni}
Para cualesquiera dos operaciones, Oij, Oik OSi, si Oij = R(x) y Oik = W(x) para
cualquier elemento de datos x, entonces, Oij <i Oik Oik <i Oij
Para todo Oij I OSi, Oij <i Ni
Ejemplo 3. Considere una transaccin simple T que consiste de los siguientes
pasos:
Read( x )
Read( y )
x x + y
Write( x )
Commit
La especificacin de su transaccin de acuerdo con la notacin formal que se ha
introducido es la siguiente:
Sumatoria = { R(x), R(y), W(x), C }
<i = { (R(x), W(x)), (R(y), W(x)), (W(x), C), (R(x), C), (R(y), C) }
Note que la relacin de ordenamiento especifica el orden relativo de todas las
operaciones con respecto a la condicin de terminacin. Esto se debe a la tercera
condicin de la definicin de transaccin. Tambin note que no se define el
ordenamiento entre cualquier par de operaciones, esto es, debido a que se ha definido
un orden parcial.
Propiedades de las transacciones
La discusin en la seccin previa clarifica el concepto de transaccin. Sin embargo, aun
no se ha dado ninguna justificacin para afirmar que las transacciones son unidades de
procesamiento consistentes y confiables. Las propiedades de una transaccin son las
siguientes:
Atomicidad. Se refiere al hecho de que una transaccin se trata como una unidad de
operacin. Por lo tanto, o todas las acciones de la transaccin se realizan o ninguna de
ellas se lleva a cabo. La atomicidad requiere que si una transaccin 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 recuperacin de
transacciones. La actividad de asegurar la atomicidad en presencia de cadas del
sistema se le llama recuperacin de cadas.
Consistencia. La consistencia de una transaccin es simplemente su correctitud. En
otras palabras, una transaccin es un programa correcto que lleva la base de datos de
un estado consistente a otro con la misma caracterstica. Debido a esto, las
transacciones no violan las restricciones de integridad de una base de datos.
Aislamiento. Una transaccin en ejecucin no puede revelar sus resultados a otras
transacciones concurrentes antes de su commit. Ms an, 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
transaccin 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 transaccin sobrevivirn a fallas del sistema. Esta propiedad motiva el aspecto de
recuperacin 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 ejecucin atmica y confiable en
presencia de fallas, una ejecucin correcta en presencia de accesos de usuario
mltiples y un manejo correcto de rplicas (en el caso de que se soporten).
Tipos de Transacciones
Las transacciones pueden pertenecer a varias clases. Aun cuando los problemas
fundamentales son los mismos para las diferentes clases, los algoritmos y tcnicas que
se usan para tratarlas pueden ser considerablemente diferentes. Las transacciones
pueden ser agrupadas a lo largo de las siguientes dimensiones:
reas de aplicacin. 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 transaccin que realiza un commit son durables, la nica forma de deshacer los
efectos de una transaccin con commit es mediante otra transaccin. A este tipo de
transacciones se les conoce como transacciones compensatorias. Finalmente, en
ambientes heterogneos se presentan transacciones heterogneas sobre los datos.
Tiempo de duracin. Tomando en cuenta el tiempo que transcurre desde que se inicia
una transaccin hasta que se realiza un commit o se aborta, las transacciones pueden
ser de tipo batch o en lnea. Estas se pueden diferencias tambin como transacciones
de corta y larga vida. Las transacciones en lnea se caracterizan por tiempos de
respuesta muy cortos y por accesar una porcin relativamente pequea 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 transaccin se examinan
dos aspectos: si una transaccin puede contener a su vez subtransacciones o el orden
de las acciones de lectura y escritura dentro de una transaccin.
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 transaccin pueden ser as
mismo transacciones. Por ejemplo,
. . .
Begin_transaction Vuelo
. . .
end. {Vuelo}
. . .
Begin_transaction Hotel
. . .
end.
. . .
end.
Una transaccin anidada dentro de otra transaccin 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 transaccin anidada: debe empezar
despus que su padre y debe terminar antes que l. Ms an, el commit de una
subtransaccin es condicional al commit de su padre, en otras palabras, si el padre de
una o varias transacciones aborta, las subtransacciones hijas tambin sern abortadas.
Las transacciones anidadas proporcionan un nivel ms alto de concurrencia entre
transacciones. Ya que una transaccin consiste de varias transacciones, es posible
tener ms concurrencia dentro de una sola transaccin. As tambin, es posible
recuperarse de fallas de manera independiente de cada subtransaccin. Esto limita el
dao a un parte ms pequea de la transaccin, haciendo que costo de la recuperacin
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 restriccin, entonces,
a este tipo de transacciones se les conoce como generales. En contraste, si se
restringe o impone que un dato deber ser ledo 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 accin
para transacciones restringidas en donde se aplica an ms la restriccin de que cada
par <read,write> tiene que ser ejecutado de manera atmica.
Ejemplo 6. Los siguientes son algunos ejemplos de los modelos de transaccin
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}
Accin: 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 atmica
8. Aspectos relacionados al procesamiento de transacciones
Los siguientes son los aspectos ms importantes relacionados con el procesamiento de
transacciones:
Modelo de estructura de transacciones. Es importante considerar si las transacciones
son planas o pueden estar anidadas.
Autoevaluacin
Toda transaccin exitosa hace Rollback
Verdadero Falso
Leccin 14. Consistencia de la base de datos interna.
Los algoritmos de control de datos semntico tienen que satisfacer siempre las
restricciones de integridad cuando una transaccin pretende hacer un commit.
Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios
de comunicacin entre los diferentes nodos de una red para garantizar la atomicidad y
durabilidad de las transacciones. As tambin, se requieren protocolos para la
recuperacin local y para efectuar los compromisos (commit) globales.
Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben
sincronizar la ejecucin de transacciones concurrentes bajo el criterio de correctitud. La
consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
Protocolos de control de rplicas. El control de rplicas se refiere a cmo garantizar la
consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia
read-one-write-all (ROWA).
Incorporacin del manejador de transacciones a la arquitectura de un SMBD
El monitor de ejecucin distribuida consiste de dos mdulos: 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 ejecucin en la base de
datos de las operaciones que realiza una aplicacin. El despachador, por otra parte, es
responsable de implementar un algoritmo especfico 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 recuperacin local cuya funcin es implementar procedimientos
locales que le permitan a una base de datos local recuperarse a un estado consistente
despus de una falla.
Figura 25. Un modelo del administrador de transacciones.
Los administradores de transacciones implementan una interfaz para los programas de
aplicacin que consiste de los comandos:
Begin_transaction.
Read.
Write.
Commit.
Abort.
En la Figura 26 se presenta la arquitectura requerida para la ejecucin centralizada de
transacciones. Las modificaciones requeridas en la arquitectura para una ejecucin
distribuida se pueden apreciar en las Figura 26b. En esta ltima figura se presentan
tambin los protocolos de comunicacin necesarios para el manejo de transacciones
distribuidas.
Figura 26. Ejecucin centralizada de transacciones.
Figura 26b. Ejecucin distribuida de transacciones.
Recuperacin en Sistemas Distribuidos
Una transaccin debe ejecutarse en forma atmica. Es decir, se ejecutan
completamente todas las instrucciones de la transaccin, o no se ejecuta ninguna.
Adems, en el caso de ejecucin concurrente, el efecto de ejecutar una transaccin
debe ser el mismo que si se ejecutara sola en el sistema.
Estructura del sistema.
Cuando se tiene un sistema de base de datos distribuido, es mucho ms difcil
garantizar la propiedad de atomicidad de una transaccin. Esto se debe a que es
posible que participen varias localidades en la ejecucin de una transaccin. El fallo de
una de estas localidades o el fallo de la lnea de comunicacin entre ellas, puede dar
como resultado un clculo errneo.
La funcin del gestor de transacciones de un sistema de base de datos distribuidos es
asegurar que la ejecucin de las distintas transacciones. Los distintos gestores de
transacciones cooperan para ejecutar las transacciones globales. Para comprender
cmo puede estructurarse un gestor de este tipo, definiremos un modelo abstracto para
un sistema de transacciones.
Gestor de transacciones, cuya funcin es gestionar la ejecucin de aquellas
transacciones (o subtransacciones) que accedan a datos almacenados en esa
localidad. Observamos que da transaccin puede ser bien una transaccin local
(es decir, que se ejecuta slo en esa localidad), o parte de una transaccin
global (es decir, que se ejecuta en varias localidades).
Coordinador de transacciones, cuya funcin es la de coordinar la ejecucin 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:
ejecucin 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:
transaccin.
las localidades apropiadas para su ejecucin.
abordada en todas las localidades.
Robustez
Es una configuracin distribuida es necesario prever otro tipo de fallos, como pueden
ser:
Por tanto, para que el sistema sea robusto, es necesario que detecte cualquiera de
estos fallos, que reconfigure el sistema de manera que pueda reanudarse el proceso y
que se recupere una vez que haya sido reparado el procesador o la lnea de
comunicacin afectados.
En general, no es posible distinguir entre los fallos en las lneas de comunicacin de la
red y de las localidades. Por tanto, el esquema de reconfiguracin que se adopte debe
estar diseado para que funcione correctamente aun cuando la red quede fragmentada.
Tambin es necesario tener cuidado al reintegrar al sistema una localidad o lnea de
comunicacin separada. Cuando una localidad que qued fuera de servicio se
recupera, debe iniciar un procedimiento de actualizacin de sus tablas de sistema para
que reflejen los cambios que tuvieron lugar mientras estaba inactiva. Si la localidad
tena copias de datos, debe obtener los valores actuales de todos ellos y asegurarse de
recibir las actualizaciones futuras. Esto es ms complicado de lo que parece, ya que es
posible que se actualicen los datos que se estn procesando mientras que el sistema
se recupera.
Es necesario representar a las tareas de recuperacin 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 reintegracin de la
localidad.
Si se recupera una lnea de comunicacin interrumpida, es posible que se unan de
nuevo dos fragmentos de la red. Dado que la fragmentacin 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 delacin que la lnea se
recuper.
Control de concurrencia
El control de concurrencia trata con los problemas de aislamiento y consistencia del
procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS
asegura que la consistencia de la base de datos se mantiene en un ambiente
distribuido multiusuario. Si las transacciones son internamente consistentes, la manera
ms simple de lograr este objetivo es ejecutar cada transaccin sola, una despus de
otra. Sin embargo, esto puede afectar grandemente el desempeo de un DDBMS dado
que el nivel de concurrencia se reduce al mnimo. El nivel de concurrencia, el nmero
de transacciones activas, es probablemente el parmetro ms 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
anomalas. En primer lugar, se pueden perder actualizaciones provocando que los
efectos de algunas transacciones no se reflejen en la base de datos. En segundo
trmino, pueden presentarse recuperaciones de informacin inconsistentes.
En este captulo se hace la suposicin de que el sistema distribuido es completamente
confiable y no experimente falla alguna.
Teora de la seriabilidad
Una calendarizacin (schedule), tambin llamado una historia, se define sobre un
conjunto de transacciones T = { T1, T2, ..., Tn } y especifica un orden entrelazado de la
ejecucin de las operaciones de las transacciones. La calendarizacin 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 calendarizacin 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 O
ij
(x) y O
kl
(x) (i y k no necesariamente distintos) que accesan el
mismo dato de la base de datos x se dice que estn 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 transaccin
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 ejecucin es importante. El orden de dos operaciones de lectura es
insignificante.
Una calendarizacin completa define el orden de ejecucin de todas las operaciones en
su dominio. Formalmente, una calendarizacin completa STc definido sobre un
conjunto de transacciones T = { T1, T2, ..., Tn } es un orden parcial STc = { T, <T } en
donde
Sumatoria T = Ui i , para todos los i = 1, 2, ..., n
<T i <i , para todos los i = 1, 2, ..., n
Para cualesquiera dos operaciones en conflicto Oij y Okl T, Oij <T Okl
Okl <T Oij
La primera condicin establece simplemente que el dominio de la calendarizacin es la
unin de los dominios de las transacciones individuales. La segunda condicin define la
relacin de ordenamiento como un superconjunto de la relacin de ordenamiento de
transacciones individuales. Esto mantiene el ordenamiento de las operaciones dentro
de cada transaccin. La condicin final define el orden de ejecucin entre dos
operaciones en conflicto.
Ejemplo 2. Considere las tres transacciones del Ejemplo 1, una posible calendarizacin
completa est dada por la siguiente grfica dirigida acclica (DAG).
Una calendarizacin se define como un prefijo de una calendarizacin completa. Un
prefijo de un orden parcial se define como sigue. Dado un orden parcial
Las primeras dos condiciones definen a P como una restriccin de P en el dominio
en donde las relaciones de ordenamiento en P se mantienen por P. La ltima condicin
indica que para cualquier elemento de
incluidos tambin en
Ejemplo 3. La siguiente calendarizacin es un prefijo de la calendarizacin del Ejemplo
2.
Si en una calendarizacin S, las operaciones de varias transacciones no estn
entrelazadas, esto es, si las operaciones de una transaccin ocurren de manera
consecutiva, entonces se dice que la calendarizacin es serial. Si cada transaccin es
consistente (obedece las reglas de integridad), entonces la base de datos se garantiza
ser consistente al final de la calendarizacin serial. La historia asociada a este tipo de
calendarizacin 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
relacin 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 relacin se le conoce como
equivalencia de conflictos puesto que define la equivalencia de dos calendarizaciones
en trmino del orden de ejecucin relativo de las operaciones en conflicto en ellas.
Una calendarizacin S se dice que es serializable, si y solamente si, es equivalente por
conflictos a una calendarizacin 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 funcin primaria de un controlador de concurrencia es generar una calendarizacin
serializable para la ejecucin de todas las transacciones. El problema es, entonces,
desarrollar algoritmos que garanticen que nicamente se generan calendarizaciones
serializables.
Seriabilidad en SMBD distribuidos
En bases de datos distribuidas es necesario considerar dos tipos de historia para poder
generar calendarizaciones serializables: la calendarizacin de la ejecucin de
transacciones en un nodo conocido como calendarizacin local y la calendarizacin
global de las transacciones en el sistema. Para que las transacciones globales sean
serializables se deben satisfacer las siguientes condiciones:
historias locales donde las operaciones aparecen juntas.
La segunda condicin simplemente asegura que el orden de serializacin sea el mismo
en todos los nodos en donde las transacciones en conflicto se ejecutan juntas.
Ejemplo 6. Considere las siguientes tres transacciones:
T1: Read( x ) T2: Read( x ) x x ) Write( x ) Commit Commit
Las siguientes historias locales son individualmente serializables (de hecho son
seriales), pero las dos transacciones no son globalmente serializables.
LH1 = { R1(x), W1(x), C1, R2(x), W2(x), C2 }
LH2 = { R2(x), W2(x), C2, R1(x), W1(x), C1 }
Taxonoma de los mecanismos de control de concurrencia
El criterio de clasificacin ms comn de los algoritmos de control de concurrencia es el
tipo de primitiva de sincronizacin. Esto resulta en dos clases: aquellos algoritmos que
estn basados en acceso mutuamente exclusivo a datos compartidos (candados) y
aquellos que intentar ordenar la ejecucin 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 ejecucin concurrente de las transacciones en
su etapa inicial de su ciclo de ejecucin. Los algoritmos optimistas retrasan la
sincronizacin de las transacciones hasta su terminacin. El grupo de algoritmos
pesimistas consiste de algoritmos basados en candados, algoritmos basados en
ordenamiento por estampas de tiempo y algoritmos hbridos. El grupo de los algoritmos
optimistas se clasifican por basados en candados y basados en estampas de tiempo
(Ver. Figura 27).
Figura 27. Clasificacin de los algoritmos de control de concurrencia.
Algoritmos basados en candados
En los algoritmos basados en candados, las transacciones indican sus intenciones
solicitando candados al despachador (llamado el administrador de candados). Los
candados son de lectura (rl), tambin llamados compartidos, o de escritura (wl),
tambin 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 operacin sobre la base de datos (lectura o escritura) e
informacin asociada, como por ejemplo el elemento de datos que es accesado y el
identificador de la transaccin que est enviando la operacin 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 transaccin solicitante es retrasada. De
otra forma, el candado se define sobre el dato en el modo deseado y la operacin a la
base de datos es transferida al procesador de datos. El administrador de transacciones
es informado luego sobre el resultado de la operacin. La terminacin de una
transaccin libera todos los candados y se puede iniciar otra transaccin que estaba
esperando el acceso al mismo dato.
Candados de dos fases (2PL)
En los candados de dos fases una transaccin le pone un candado a un objeto antes
de usarlo. Cuando un objeto es bloqueado con un candado por otra transaccin, la
transaccin solicitante debe esperar. Cuando una transaccin libera un candado, ya no
puede solicitar ms candados. As una transaccin 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
terica 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 transaccin aborta despus de liberar un candado, otras
transacciones que hayan accesado el mismo elemento de datos aborten tambin
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 transaccin termina (con commit o aborta). El comportamiento anterior se
muestra en la Figura 29.
Figura 28. Grfica del uso de los candados de dos fases.
Figura 29. Comportamiento de los candados de dos fases estrictos.
Candados de dos fases centralizados
En sistemas distribuidos puede que la administracin 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
comunicacin de un administrador centralizado de candados de dos fases. La
comunicacin se presenta entre el administrador de transacciones del nodo en donde
se origina la transaccin (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 operacin se va a llevar a cabo.
Figura 30. Comunicacin en un administrador centralizado de candados de dos
fases estrictos.
La crtica ms 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. Ms an, su disponibilidad es reducida a cero cuando se presentan fallas en el
nodo central.
Candados de dos fases distribuidos
En los candados de dos fases distribuidos se presentan despachadores en cada nodo
del sistema. Cada despachador maneja las solicitudes de candados para los datos en
ese nodo. Una transaccin 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
comunicacin entre los nodos que cooperan para ejecutar una transaccin de acuerdo
al protocolo de candados distribuidos de dos fases se presenta en la Figura 31. Los
mensajes de solicitud de candados se envan 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 enva su
mensaje de "fin de operacin" al administrador de transacciones coordinador.
Algoritmos basados en estampas de tiempo
A diferencia de los algoritmos basados en candados, los algoritmos basados en
estampas de tiempo no pretenden mantener la seriabilidad por exclusin mutua. En
lugar de eso, ellos seleccionan un orden de serializacin a priori y ejecutan las
transacciones de acuerdo a ellas. Para establecer este ordenamiento, el administrador
de transacciones le asigna a cada transaccin Ti una estampa de tiempo nica ts( Ti )
cuando sta inicia. Una estampa de tiempo es un identificador simple que sirve para
identificar cada transaccin 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. Comunicacin en candados de dos fases distribuidos.
Existen varias formas en que las estampas de tiempo se pueden asignar. Un mtodo es
usar un contador global monotnicamente 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 autnoma las estampas de tiempos basndose 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 posicin 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 tambin una estampa de tiempo a todas las
operaciones solicitadas por una transaccin. Ms an, a cada elemento de datos x se
le asigna una estampa de tiempo de escritura, wts(x), y una estampa de tiempo de
lectura, rts(x); sus valores indican la estampa de tiempo ms 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 transaccin ms vieja y
Tk se dice ser una transaccin ms 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 accin de rechazar una operacin, significa que la
transaccin que la envi necesita reiniciarse para obtener la estampa de tiempo ms
reciente del dato e intentar hacer nuevamente la operacin sobre el dato.
Ordenamiento conservador por estampas de tiempo
El ordenamiento bsico por estampas de tiempo trata de ejecutar una operacin tan
pronto como se recibe una operacin. As, la ejecucin de las operaciones es
progresiva pero pueden presentar muchos reinicios de transacciones. El ordenamiento
conservador de estampas de tiempo retrasa cada operacin hasta que exista la
seguridad de que no ser reiniciada. La forma de asegurar lo anterior es sabiendo que
ninguna otra operacin 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 creacin de nter bloqueos (deadlocks).
Ordenamiento por estampas de tiempo mltiples
Para prevenir la formacin de nter bloqueos se puede seguir la estrategia siguiente. Al
hacer una operacin de escritura, no se modifican los valores actuales sino se crean
nuevos valores. As, puede haber copias mltiples de un dato. Para crear copias nicas
se siguen las siguientes estrategias de acuerdo al tipo de operacin de que se trate:
Una operacin de lectura Ri(x) se traduce a una operacin de lectura de x de una sola
versin encontrando la versin de x, digamos xv, tal que, ts(xv) es la estampa de
tiempo ms grande que tiene un valor menor a ts(Ti).
Una operacin de escritura Wi(x) se traduce en una sola versin, Wi(xw), y es aceptada
si el despachador no ha procesado cualquier lectura Rj(xr), tal que, ts(Ti) < ts(xr) <
ts(Tj)
Control de concurrencia optimista
Los algoritmos de control de concurrencia discutidos antes son por naturaleza
pesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones son
muy frecuentes y no permiten el acceso a un dato si existe una transaccin conflictiva
que accesa el mismo dato. As, la ejecucin de cualquier operacin de una transaccin
sigue la secuencia de fases: validacin (V), lectura (R), cmputo (C) y escritura (W) (ver
Figura 6.6a). Los algoritmos optimistas, por otra parte, retrasan la fase de validacin
justo antes de la fase de escritura (ver Figura 32). De esta manera, una operacin
sometida a un despachador optimista nunca es retrasada.
Las operaciones de lectura, cmputo y escrita de cada transaccin se procesan
libremente sin actualizar la base de datos corriente. Cada transaccin inicialmente hace
sus cambios en copias locales de los datos. La fase de validacin 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 transaccin es abortada y tiene que reiniciar
Figura 32. Fases de la ejecucin de una transaccin 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. Ms an, las estampas de tiempo no se asignan al inicio de una
transaccin sino justamente al inicio de su fase de validacin. Esto se debe a que las
estampas se requieren nicamente durante la fase de validacin.
Cada transaccin Ti se subdivide en varias subtransacciones, cada una de las cuales
se puede ejecutar en nodos diferentes. Sea Tij una subtransaccin 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
validacin se realiza una prueba de validacin, si una transaccin falla, todas las
transacciones se rechazan.
La prueba de validacin 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 validacin tiene xito.
En este caso la ejecucin de las transacciones es completamente serial como se
muestra en la Figura 7a.
Si existe alguna transaccin 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 validacin tiene xito si
WS(Tk ) RS(Tij ) =
como se muestra en la Figura 7b, pero Tij no lee datos que son escritos por Tk.
Si existe alguna transaccin 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 validacin tiene xito si
WS(Tk ) RS(Tij ) = WS(Tk ) WS(Tij ) =
traslapan, como se muestra en la Figura 33, pero las transacciones no accesan datos
comunes.
Figura 33. Casos diferentes de las pruebas de validacin para control de
concurrencia optimista.
Autoevaluacin
Un candado de dos fases, solicita la primero los candados (fase de preparacin) y al
terminar , los libera
Verdadero Falso
Leccin 15. Catlogo
Conceptos bsicos
Existe un elemento denominado Catlogo, que es imprescindible conocer si se quiere
llegar a ser experto en el manejo de cualquier SGBD (Sistema de gestin de base de
datos). El catlogo guarda la informacin 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 catlogo, 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 definicin de datos, de rendimiento u optimizacin es
necesario conocer las caractersticas del motor, la forma como se comporta en
determinada plataforma e incluso sus deficiencias.
En un sistema distribuido, el catlogo del sistema incluir no solo los datos usuales del
catlogo con relacin a las varrels base, vistas, autorizaciones, etc., sino tambin toda
la informacin de control necesaria para permitir que el sistema proporcione la
independencia de ubicacin, fragmentacin y replicacin necesaria. Surge entonces un
interrogante Dnde y cmo debe ser almacenado el propio catlogo?. A continuacin
se muestran las posibilidades:
Centralizado
El catlogo total es almacenado exactamente una vez en un sitio central.
Completamente replicado
El catlogo total es almacenado por completo en cada uno de los sitios.
Dividido
Cada sitio mantiene su propio catlogo de los objetivos que estn almacenados en ese
sitio. El catlogo total es la unin de todos los catlogos locales disjuntos.
Combinacin de centralizado y dividido
Cada sitio mantiene su propio catlogo local, como en el punto 4.4; adems, un nico
sitio central mantiene una copia unificada de todos esos catlogos 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 prdida de autonoma, ya que cada
actualizacin del catlogo tiene que ser propagada por cada uno de los sitios. El
enfoque dividido eleva el costo de operaciones que no son locales. La combinacin de
centralizado y dividido es ms eficiente que el dividido, pero viola nuevamente el
objetivo de no dependencia de un sitio central, por lo tanto, en la prctica 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 catlogo 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 sera necesario algn mecanismo por lo general la calificacin por nombre de
sitio para eliminar la ambigedad (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
comn de un objeto, que es el nombre por el cual los usuarios hacen normalmente
referencia al objeto ( por ejemplo una instruccin 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:
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 comn. Este nombre
se usa sin calificativos, ya sea el componente nombre local del nombre a nivel
sistema (STATS en el ejemplo anterior) o un sinnimo para ese nombre a nivel de
sistema, definido por medio de la instruccin especial de SQL, R* CREATE SYNONYM.
En el ejemplo en cuestin:
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 sinnimo), el sistema determina el nombre a nivel de
sistema consultando la tabla sinnimos relevante. Las tablas del sinnimos pueden ser
vistas como el primer componente del catlogo; cada sitio mantiene un conjunto de
esas tablas para los usuarios que se sabe que estn en ese sitio y transforma los
sinnimos conocidos para ese usuario en los nombres a nivel de sistema
correspondientes. Adems en las tablas de sinnimos cada sitio mantiene:
1. Una entrada de catlogo para cada objeto nacido en este sitio;
2. Una entrada de catlogo para cada objeto almacenado actualmente en ese
sitio.
Supongamos que ahora el usuario emite una solicitud que hace referencia al sinnimo
MSTATS. Primero, el sistema busca el nombre a nivel sistema correspondiente en la
tabla de sinnimos adecuada (una simple bsqueda local), Ahora ya sabe el sitio de
nacimiento(es decir Londres en el ejemplo) y puede consultar el catlogo de Londres (y
se supone, de manera general, que ser una bsqueda renota; el primer acceso
remoto). El catlogo de Londres contendr una entrada para ese objeto gracias al
punto 1 anterior. Si el objeto est todava en Londres ya habr sido encontrado. Sin
embargo, si el objeto ha emigrado (digamos) a Los ngeles, entonces la entrada de
catlogo en Londres lo dir y por lo tanto, el sistema podr ahora consultar al catlogo
de Los ngeles (segundo acceso remoto). Y el catlogo de los ngeles contendr una
entrada para los objetos gracias al punto 2 anterior. Por lo tanto, ha sido encontrado en,
como mximo, dos accesos remotos.
Adems, si el objeto emigra nuevamente, digamos a San Francisco, entonces el
sistema:
Insertar una entrada en el catlogo de San Francisco;
Borrar la entrada del catlogo de los ngeles;
Actualizar la entrada del catlogo de Londres para que se apunte a San Francisco en
lugar de Los ngeles.
El efecto neto es que el objeto todava puede ser encontrado en dos accesos remotos,
como mximo. Y este es un esquema completamente distribuido; no hay un sitio con
catlogo central y no hay punto alguno de falla dentro del sistema.
Autoevaluacin
El catalogo guarda la estructura del sistema de base de datos
Verdadero Falso
Referencias
DORSEY, P, Hudicka Oracle8. Diseo de bases de datos con UML. J. Ed. Oracle
press. 1999.
KROENKE,D. Procesamiento de bases de datos. Fundamentos, diseo e
implementacin. 2003. Ed. Pearson Education. Octava edicin
Hill. Cuarta edicin
Unidad 2. Bodegas de datos
Captulo 4. Diseo de bodegas de datos
Leccin 16. Introduccin
Hoy en da se habla mucho del tema de Data Warehousing o Bodega de Datos, que
permite la utilizacin de los datos de una Organizacin o un conjunto de ellas, como
soporte en la toma de decisiones.
Est informacin puede provenir de mltiples fuentes heterogneas no slo en
ambiente de computacin sino tambin en formato, ambiente de captura, significado,
etc, informacin toda esta indispensable en su interpretacin y correcta utilizacin y que
es lo que se conoce como Metadatos.
La funcin de una Bodega de Datos es la de entregar la informacin correcta a la gente
indicada en el momento adecuado en el formato correcto.
Cuntos tornillos se vendieron el ao pasado en el ltimo trimestre? Quien? En que
Departamentos o ciudades? Cuanto fueron las ventas totales en este trimestre? Cules
campaas de publicidad dieron el mejor resultado? Las ventas se incrementaron como
resultado de las campaas de las ltimas semanas? Cules son las caractersticas de
un cliente tpico? Cules han sido los valores histricos de la razn cida, para un
conjunto de compaas que conforman un pool? Cmo es la composicin 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 implementacin de una
herramienta de mercadeo. Es una forma de operar dentro de una organizacin.
Inicia con el proceso de recoleccin, transformacin 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 informacin se analice y se presente
en la forma que necesita el usuario.
Los datos pueden ser extractados de grandes aplicaciones en Mainframe o de mltiples
fuentes distribuidas, de ambiente C/S, en ambientes dismiles. Usualmente los datos
son transformados (reformateados o agregados) antes de ser colocados en la Bodega
de Datos.
La problemtica de Bodega de Datos difiere de compaa en compaa. Una puede
necesitar una Base de Datos centralizada, mientras que una organizacin distribuida a
lo largo del pas o del mundo puede necesitar de una gran Base de Datos distribuida.
Autoevaluacin
Una bodega de datos almacena
Informacin histrica del desempeo de la empresa
Informacin de produccin
Informacin transaccional
Informacin institucional
Leccin 17. Construccin y manejo de una bodega de datos
Si la organizacin tiene muchos datos de aplicaciones tradicionales y est buscando
una solucin para transferir grandes volmenes de datos de un Mainframe, se necesita
una solucin 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 extraccin de datos a altas velocidades y altos volmenes de datos, traslade y
distribuya de mltiples y diferentes Bases de Datos en Mainframes en la BODEGA y
ojal elimine la necesidad de escribir complejos programas y rutinas de conversin.
Usualmente estas herramientas tienen habilidades grficas y proveen de criterio de
seleccin fcilmente puede llevar los datos al formato requerido en la Base de Datos.
Por definicin Bodega de Datos es una coleccin de datos actualizada, por lo tanto la
herramienta utilizada debe completar las actualizaciones en el momento.
Distribucin 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 distribucin define Base de Datos Objetivo, informacin de
conversin 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 sincronizacin mas sofisticadas a travs de ambientes mltiples y heterogneos.
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
Autoevaluacin
Un sistema que facilite la minera de datos permite
Buscar tendencias y comportamientos
Buscar entidades
Buscar atributos
Buscar inconsistencias
Leccin 18. Construccin del Data Warehouse.
Como todo proyecto informtico, el proyecto de bodega de datos consta de los
siguientes pasos.
Planeacin
La fase define la metodologa a utilizar. Como se muestra en el modelo de bases de
datos avanzada, existe el enfoque Top-Down (De Arriba abajo), y Bottom-up (De abajo
a arriba) o una combinacin de estas dos.
Todo proyecto de sistemas, requiere una metodologa de desarrollo del producto. En
general, se usa el mtodo de anlisis y diseo estructurado y el mtodo del desarrollo
en espiral.
Requerimientos
Especificacin de lo que se desean lograr del data warehouse. Comenzando por la
vista de usuario, para que se quiere desarrollar la bodega. En el diseo, se puede
trabajar dos modelos diferentes, bodegas basadas en el Modelo Entidad Relacin o
bodegas diseadas con el modelo copo de nieve (snowflake).
En ambos casos, debe disearse las tablas que administran los datos del proceso que
se desea revisar (produccin, ventas, compras), llamadas tablas de hecho y las tablas
que registran los elementos que pueden explicar ese hecho, denominadas dimensiones
o categoras (estrato, tiempo, categoras de los elementos, da en que se realiz la
transaccin), elementos que histricamente, pueden determinar un comportamiento o
tendencia.
Anlisis
Una vez definidos los requerimientos, se determinan y clarifican las necesidades, se
identifican las entidades de donde se alimentar la informacin de la bodega; se
revisan los atributos, sus propiedades y las transformaciones que se deben desarrollar
para homogenizar los datos. Se definen los procedimientos de conexin con las fuentes
de datos y el data warehouse y las herramientas de acceso del usuario final.
Diseo
Los modelos lgicos de la fase anterior se convierten en modelos fsicos. Incluye la
implementacin de la bodega en la herramienta; los programas que manipulan los
datos para crear, modificar, estandarizar, sumarizar o generar los ndices a partir de los
datos de los sistemas de alimentacin de informacin definidos en la etapa anterior;
determinar la periodicidad en que se hace el proceso de carga de datos a la bodega
Montaje
Procesos relacionados con la puesta en marcha del sistema. Un elemento importante
consiste en concientizar a los usuarios sobre la disponibilidad, beneficios y
presentacin de de la bodega (proceso de comercializacin de la informacin).
En la literatura especializada, estos pasos se conocen como el proceso ETL, llamado
as, por las siglas Extraccin, Transformacin y Carga de datos. Los procesos de
Extraccin identifican los sistemas que alimentarn la bodega; el proceso de
transformacin, define la manipulacin de los datos para convertirlos y dejarlos en el
formato que requiere la bodega y el proceso de Carga, que define la periodicidad en
que se debe realizar el proceso para cargar los datos a la bodega.
Autoevaluacin
Se conoce como ETL, el proceso de Extraccin, Transformacin y Carga de los datos
a la bodeba
Verdadero Falso
Leccin 19. Estrategias recomendadas para diseo de datos
La metodologa recomendada es iniciar con un prototipo.
Prototipo: La meta del prototipo de Bodega de Datos es proveer a los usuarios finales
con una aproximacin de lo que la Bodega de Datos les puede proporcionar en un
perodo 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
ms pronto la retroalimentacin crtica 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 Decisin si es aplicable. Sin embargo el proceso de
integrar y transformar los datos de la Bodega de Datos no ser completamente
automatizado.
En la mayora 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 tambin diferir de aquellas para la
arquitectura definitiva de Bodega de Datos, lo que es importante tambin, es que la
presentacin de los Datos al usuario final sea tan fiel como sea posible para que sea
igualmente presentada en posteriores etapas de la Bodega de Datos.
Piloto
En la construccin 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
mtodos, tcnicas y herramientas que ser la base para una Bodega de Datos
completa. Por esta razn el proyecto piloto de Bodega de Datos debe tener un pequeo
alcance y tiempo adicional comparativamente con los esfuerzos sucesivos de Bodega
de Datos.
Prueba del concepto tecnolgico
La prueba del concepto tecnolgico 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 mayora de proyectos de Bodega de Datos el esfuerzo del piloto
ha servido tambin como la prueba del concepto para la arquitectura tcnica. Es crtico
que la prueba del concepto tecnolgico no est cercana al prototipo, dado que la meta
del prototipo es poner datos en las manos de los usuarios tan pronto como sea posible.
Arquitectura de la Bodega de Datos.
Datos de los sistemas de Aplicacin y de otras fuentes de Bodegas de Datos deben ser
peridicamente extrados y alimentados en la capa de Data Scrubbing. La extraccin
debe ser realizada en muchos casos utilizando los programas para acompaar 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 corazn de la Bodega de Datos debe ser organizado desde un punto de vista de
negocio. Se debe utilizar una estructura de Datos para el corazn de la Bodega de
Datos, ligeramente normalizada. Esta estructura de Datos parece estar normalizada
cuando se ve al nivel de Entidad-relacin. Cuando se miran los atributos sin embargo,
la estructura de datos puede estar desnormalizada. Esta representa una visin de
negocio de la compaa 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 informacin es usada, cambiar frecuentemente y se necesita una Base de
Datos estable para soportar el cambio.
Por esta razn se debe utilizar una serie de Data Marts para proveer a los usuarios
finales con fcil acceso a sus datos. Los Data Marts deben consistir en Datos extrados
del corazn de la Bodega de Datos y reorganizados y/o reformateados para hacer ms
fcil su uso para diferentes propsitos. Pero fofo que esos propsitos especficos
pueden cambiar en el tiempo, los Data Marts deben ser concebidos con estructuras de
Datos temporales. Cuando los usuarios no ven ms los datos como estn presentados
por un Data Mart en particular, este Data Mart debe ser removido. Y mientras los
usuarios desarrollan nuevas formas de hacer bsquedas y mirar los datos, deben ser
creados nuevos Data Marts para hacer sus bsquedas ms simples y con un mejor
desempeo.
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 geogrfica, un perodo especfico de tiempo,
una unidad de negocios.
Es crtico que los usuarios sean provistos del mtodo apropiado para utilizar la
informacin de las Bodegas de Datos. No se debe esperar que un usuario novato
negocie una compleja y poderosa herramienta slo para hacer una simple pregunta de
la Bodega de Datos. Similarmente un usuario adelantado rpidamente quedar
frustrado con la Bodega de Datos si el o ella esperan hacer un complejo anlisis 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.
Autoevaluacin
Para alimentar la bodega es necesario tener herramientas para
Extraer datos de diferentes sistemas
Herramientas grficas
Herramientas de backup
Herramientas de antivirus
Leccin 20. Factores de riesgo
Es importante conocerlos para poder monitorearlos. Son stos:
Expectativas de los usuarios. Se debe trabajar con las expectativas de los
usuarios. Muchas veces el xito depende de la diferencia entre lo que los
usuarios esperan y lo que ellos perciben que les es entregado. Es crtico 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.
Direccin estratgica. Es relativamente lgico definir un punto de inicio lgico
para la Bodega de Datos. Sin embargo cuando esta primera rea se haya
completado, es ms difcil identificar reas para esfuerzos futuros y asegurar
que esos esfuerzos estn 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 informacin del
negocio y desarrollar una implementacin de Bodega de Datos a largo plazo
que cumpla con estas propiedades.
Autoevaluacin
Un factor de riesgo es determinar lo que el usuario desea de la bodega de datos
Verdadero Falso
Capitulo 5. Minera de datos
Esta unidad tiene como propsito introducir al lector en los conceptos fundamentales de
la minera de datos y su relacin con las bodegas de datos, no es la intencin de
profundizar en cada uno de los temas, estos pueden ser ampliados en la bibliografa
recomendada, es necesario que el lector tenga conocimientos en base de datos
relacionales y distribuidas para una mejor comprensin del tema.
Data Mining, la extraccin de informacin oculta y predecible de grandes bases de
datos, es una poderosa tecnologa nueva con gran potencial para ayudar a las
compaas a concentrarse en la informacin ms importante de sus Bases de
Informacin (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 informacin (knowledge-
driven). Los anlisis prospectivos automatizados ofrecidos por un producto as van ms
all de los eventos pasados provistos por herramientas retrospectivas tpicas de
sistemas de soporte de decisin. 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 informacin casi no estn dispuestos a
aceptar. Estas herramientas exploran las bases de datos en busca de patrones ocultos,
encontrando informacin predecible que un experto no puede llegar a encontrar porque
se encuentra fuera de sus expectativas.
Las tcnicas de minera de datos se emplean para mejorar el rendimiento de procesos
de negocio o industriales en los que se manejan grandes volmenes de informacin
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
planificacin y a la decisin en marketing, finanzas, etc.
Asimismo, la minera de datos es fundamental en la investigacin cientfica y tcnica,
como herramienta de anlisis y descubrimiento de conocimiento a partir de datos de
observacin o de resultados de experimentos.
Autoevaluacin
La minera de datos (Data Mining) busca predecir comportamientos a partir de la
informacin histrica almacenada en la bodega
Verdadero Falso
Leccin 22. Fundamentos del Data Mining
Las tcnicas de Data Mining son el resultado de un largo proceso de investigacin y
desarrollo de productos. Esta evolucin comenz cuando los datos de negocios fueron
almacenados por primera vez en computadoras, y continu con mejoras en el acceso a
los datos, y ms recientemente con tecnologas generadas para permitir a los usuarios
navegar a travs de los datos en tiempo real. Data Mining toma este proceso de
evolucin ms all del acceso y navegacin retrospectiva de los datos, hacia la entrega
de informacin prospectiva y proactiva. Data Mining est lista para su aplicacin en la
comunidad de negocios porque est soportado por tres tecnologas que ya estn
suficientemente maduras:
Las bases de datos comerciales estn 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 estn 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 nmeros pueden ser an
mayores. La necesidad paralela de motores computacionales mejorados puede ahora
alcanzarse de forma ms efectiva con de con multiprocesamiento paralelo. Los de Data
Mining utilizan tcnicas que han existido por lo menos desde hace 10 aos, pero que
slo han sido implementadas recientemente como herramientas maduras, confiables,
entendibles que consistentemente son ms performantes que estadsticos clsicos.
Los componentes esenciales de la de Data Mining han estado bajo desarrollo por
dcadas, en reas de investigacin como estadsticas, inteligencia artificial y
aprendizaje de mquinas. Hoy, la madurez de estas tcnicas, junto con los motores de
bases de datos relacionales de alta performance, hicieron que estas tecnologas fueran
prcticas para los entornos de data warehouse actuales.
Autoevaluacin
Entre las herramientas de minera encontramos a la estadstica
Verdadero Falso
Leccin 23. Alcance de Data Mining
El nombre de Data Mining deriva de las similitudes entre buscar valiosa informacin de
negocios en grandes bases de datos, por ej.: encontrar informacin de la venta de un
producto entre grandes montos de Gigabytes almacenados, minar una montaa 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 tamao y
calidad, la tecnologa de Data Mining puede generar nuevas oportunidades de negocios
al proveer estas capacidades:
Prediccin automatizada de tendencias y comportamientos. Data Mining
automatiza el proceso de encontrar informacin predecible en grandes bases de
datos. Preguntas que tradicionalmente requeran un intenso anlisis manual,
ahora pueden ser contestadas directa y rpidamente desde los datos. Un tpico
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 inversin en
futuros mailing. Otros problemas predecibles incluyen pronsticos de problemas
financieros futuros y otras formas de incumplimiento, e identificar segmentos de
poblacin 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 slo paso. Otros problemas de descubrimiento
de modelos incluye detectar transacciones fraudulentas de tarjetas de crditos e
identificar datos anormales que pueden representar errores de tipeado en la
carga de datos.
Las tcnicas de Data Mining pueden redituar los beneficios de automatizacin 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 ms rpido significa que los usuarios pueden automticamente
experimentar con ms modelos para entender datos complejos. Alta velocidad
hace que sea prctico 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:
Ms columnas. Los analistas muchas veces deben limitar el nmero de
variables a examinar cuando realizan anlisis manuales debido a limitaciones
de tiempo. Sin embargo, variables que son descartadas porque parecen sin
importancia pueden proveer informacin 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.
Ms filas. Muestras mayores producen menos errores de estimacin y desvos,
y permite a los usuarios hacer inferencias acerca de pequeos pero importantes
segmentos de poblacin.
Autoevaluacin
Las minera de datos puede decirse que busca informacin dentro de la informacin
Verdadero Falso
Leccin 24. Fases de un Proyecto de Minera de Datos
Los pasos a seguir para la realizacin de un proyecto de minera de datos son siempre
los mismos, independientemente de la tcnica especfica de extraccin de
conocimiento usada. Ver fig. 45.
Figura 45: Fases de un Proyecto de Minera de Datos
El proceso de minera de datos pasa por las siguientes fases:
Si desea obtener una descripcin ms detallada, puede consultar la documentacin de
CRISP-DM. CRISP-DM (CRoss Industry Standard Process for Data Mining) es un
estndar industrial utilizado por ms de 160 empresas e instituciones de todo el mundo,
que surge en respuesta a la falta de estandarizacin y propone un modelo de proceso
general para proyectos de minera de datos.
Autoevaluacin
Uno de los pasos en el proceso de minera de datos es la seleccin de variables
Verdadero Falso
Leccin 25. Cmo Trabaja el Data Mining?
Cun exactamente es capaz Data Mining de decirle cosas importantes que usted
desconoce o que van a pasar? La tcnica usada para realizar estas hazaas en Data
Mining se llama Modelado. Modelado es simplemente el acto de construir un modelo en
una situacin donde usted conoce la respuesta y luego la aplica en otra situacin de la
cual desconoce la respuesta. Por ejemplo, si busca un galen espaol hundido en los
mares lo primero que podra hacer es investigar otros tesoros espaoles que ya fueron
encontrados en el pasado. Notara que esos barcos frecuentemente fueron
encontrados fuera de las costas de Bermuda y que hay ciertas caractersticas respecto
de las corrientes ocenicas y ciertas rutas que probablemente tomara el capitn del
barco en esa poca. Usted nota esas similitudes y arma un modelo que incluye las
caractersticas 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 ms probabilidad de darse una situacin similar. Con un poco de esperanza, si
tiene un buen modelo, probablemente encontrar el tesoro.
Este acto de construccin 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 tecnologa 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 informacin acerca de una variedad de situaciones donde una
respuesta es conocida y luego el software de Data Mining en la computadora debe
correr a travs de los datos y distinguir las caractersticas de los datos que llevarn 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,
Cmo puede saber si es realmente un buen modelo? La primera cosa que puede
probar es pedirle que aplique el modelo a su base de clientes - donde usted ya conoce
la respuesta. Con Data Mining, la mejor manera para realizar esto es dejando de lado
ciertos datos para aislarlos del proceso de Data Mining. Una vez que el proceso est
completo, los resultados pueden ser testeados contra los datos excluidos para
confirmar la validez del modelo. Si el modelo funciona, las observaciones deben
mantenerse para los datos excluidos.
Una arquitectura para Data Mining
Para aplicar mejor estas tcnicas avanzadas, stas deben estar totalmente integradas
con el data warehouse as como con herramientas flexibles e interactivas para el
anlisis de negocios. Varias herramientas de Data Mining actualmente operan fuera del
warehouse, requiriendo pasos extra para extraer, importar y analizar los datos.
Adems, cuando nuevos conceptos requieren implementacin operacional, la
integracin con el warehouse simplifica la aplicacin de los resultados desde Data
Mining. El Data warehouse analtico resultante puede ser aplicado para mejorar
procesos de negocios en toda la organizacin, en reas tales como manejo de
campaas promocionales, deteccin de fraudes, lanzamiento de nuevos productos, etc.
El punto de inicio ideal es un data warehouse que contenga una combinacin de datos
de seguimiento interno de todos los clientes junto con datos externos de mercado
acerca de la actividad de los competidores. Informacin histrica sobre potenciales
clientes tambin 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 rpido.
Un server multidimensional OLAP permite que un modelo de negocios ms 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 lnea 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 anlisis de negocios directamente en esta infraestructura.
Un avanzado, metadata centrado en procesos define los objetivos del Data Mining para
resultados especficos tales como manejos de campaa, prospecting, y optimizacin de
promociones. La integracin 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 organizacin puede "minar"
las mejores prcticas y aplicarlas en futuras decisiones.
Este diseo representa una transferencia fundamental desde los sistemas de soporte
de decisin convencionales. Ms que simplemente proveer datos a los usuarios finales
a travs de software de consultas y reportes, el server de Anlisis Avanzado aplica los
modelos de negocios del usuario directamente al warehouse y devuelve un anlisis
proactivo de la informacin ms relevante. Estos resultados mejoran los metadatos en
el server OLAP (procesamiento analtico on-line) proveyendo una estrato de metadatos
que representa una vista fraccionada de los datos. Generadores de reportes,
visualizadores y otras herramientas de anlisis pueden ser aplicadas para planificar
futuras acciones y confirmar el impacto de esos planes.
Autoevaluacin
El data mining facilita generar reglas del negocio
Verdadero Falso
Captulo 6. Herramientas de minera de datos
Leccin 26. Redes neuronales artificiales:
Modelos predecible no-lineales que aprenden a travs del entrenamiento y semejan la
estructura de una red neuronal biolgica.
Autoevaluacin
Una red neuronal es similar a la manera como funciona el cerebro
Verdadero Falso
Leccin 27. rboles de decisin:
Estructuras de forma de rbol que representan conjuntos de decisiones. Estas
decisiones generan reglas para la clasificacin de un conjunto de datos. Mtodos
especficos de rboles de decisin incluyen rboles de Clasificacin y Regresin
(CART: Classification And Regression Tree) y Deteccin de Interaccin Automtica de
Chi Cuadrado (CHAI: Chi Square Automatic Interaction Detection)
Autoevaluacin
Un tipo de rbol, es el rbol de decisin
Verdadero Falso
Leccin 28. Mtodo del vecino ms cercano:
Es una tcnica que clasifica cada registro en un conjunto de datos basado en una
combinacin de las clases del/de los k registro (s) ms similar/es a l en un conjunto de
datos histricos (donde k 1). Algunas veces se llama la tcnica del vecino k-ms
cercano.
Autoevaluacin
El analisis de vecino ms cercano es tambin llamado analisis Cluster
Verdadero Falso
Leccin 29. Algoritmos genticos
Tcnicas de optimizacin que usan procesos tales como combinaciones genticas,
mutaciones y seleccin natural en un diseo basado en los conceptos de evolucin.
Autoevaluacin
Las tcnicas de algoritmos genticos, simulan el proceso de seleccin natural
Verdadero Falso
Leccin 30. Regla de induccin:
La extraccin de reglas if-then de datos basados en significado estadstico
Autoevalucin
La regla de induccin utiliza la estadstica
Verdadero Falso
Referencias
BATINI C.; Ceri S.; Navathe S. Diseo conceptual de bases de datos. Un enfoque de
entidades-interrelaciones. 1994. Ed. Addison-Wesley.
CASTAO A.; Piattini M. Fundamentos y modelos de bases de datos. 1999. Ed.
Alfaomega. Segunda edicin.
CERI S, Pelagatti G.,Distributed databases principles & systems.. Ed. MacGraw-Hill.
1985.
edicin.
DORSEY, P, Hudicka Oracle8. Diseo de bases de datos con UML. J. Ed. Oracle
press. 1999.
KROENKE,D. Procesamiento de bases de datos. Fundamentos, diseo e
implementacin. 2003. Ed. Pearson Education. Octava edicin
Hill. Cuarta edicin
OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill.
ULLMAN, J Principles of database systems, Ed. Computer science press, 1982.
Unidad 3. Bases de datos orientadas a objetos
Captulo 7. Orientacin a objetos
Los sistemas de bases de datos orientados a objetos tienen sus orgenes en los
lenguajes de programacin orientados a objetos. La idea fundamental es que el usuario
no debera tener que batallar con construcciones orientadas al computador tales como
registros y campos, sino ms bien debera poder manejar objetos (y operaciones) que
se asemejen ms a sus equivalentes en el mundo real. Por ejemplo, en vez de pensar
en trminos 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
debera 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 relacin EMP con un valor apropiado de NUMDEPTO (la clave ajena), el
usuario debera ser capaz de crear en forma directa un nuevo objeto empleado e
incluirlo en el objeto departamento pertinente tambin en forma directa. Dicho de otro
modo, la idea fundamental es elevar el nivel de abstraccin.
La elevacin del nivel de abstraccin es sin duda un objetivo deseable, y el paradigma
de la orientacin a objetos ha tenido considerable xito en alcanzar ese objetivo en el
campo de los lenguajes de programacin. Por tanto, es natural preguntar si es posible
aplicar el mismo paradigma en el rea de las bases de datos. Es ms, la idea de
manejar una base de datos formada por "objetos encapsulados" (por ejemplo, un objeto
dependencia que "sabe qu significa" aadir un empleado o cambiar al gerente o
recortar el presupuesto), en vez de tener que entender relaciones, actualizaciones de
tuplas, claves ajenas, etctera, es desde luego mucho ms atractiva y fcil desde el
punto de vista del usuario, al menos en lo superficial.
Paradigma de orientacin 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 caractersticas se encuentran separadas.
Los primeros intentos en aplicar la orientacin a objetos al ambiente de bases de datos
fueron mediante la construccin de interfaces como una capa externa a los SABDs
relacinales.
Uno de los problemas que se tienen actualmente es la falta de estndares en la
concepcin y definicin de trminos. Sin embargo, a continuacin se van a introducir
los conceptos mnimos, que se consideran fundamentales en la aplicacin de este
paradigma a la tecnologa de bases de datos.
Leccin 32. Conceptos bsicos:
En esta seccin se presentan algunos de los trminos y conceptos principales del
enfoque 00, como los objetos mismos (por supuesto), las clases, mtodos, mensajes y
jerarquas de clases. Tambin relacionaremos estas ideas con trminos y conceptos
ms familiares siempre que sea posible o apropiado. De hecho, quiz resulte til mostrar
antes que nada una correspondencia burda entre los trminos OO y los trminos de
programacin tradicional:
Trmino OO Trmino en programacin
Objeto variable
Clase tipo
Mtodo funcin
Mensaje llamada
Jerarqua de clases jerarqua de tipos
Objetos
Antes de entrar en detalles, es bueno advertir que en el mundo de los objetos no se
encuentra el tipo de precisin al que estamos acostumbrados en el mundo relacional.
Adems, 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 ms bsico. 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 bsico 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 podran ser los objetos de departamento y empleado. Por lo tanto, en la
terminologa tradicional, los objetos inmutables corresponden a los valores y los objetos
mutables corresponden a las variables.
Todo objeto tiene un tipo (el trmino en objetos es clase). A los objetos individuales con
frecuencia se les llama especficamente ejemplares (instancias) de objeto, para
distinguirlos con claridad del tipo o clase del objeto correspondiente. El trmino tipo se
utiliza en su sentido usual de lenguaje de programacin; por lo tanto, en particular en
este trmino se incluye el conjunto de operadores (el trmino en el entorno de objetos
es mtodos) que pueden ser aplicados a los objetos de ese tipo.
Polimorfismo.
El polimorfismo es otro de los pilares fundamentales de la programacin 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 slo poderse acceder a travs de
dicha variable a los miembros comunes a ambos tipos. Sin embargo, las versiones de
los mtodos virtuales a las que se llamara a travs de esas variables no seran las
definidas como miembros del tipo de dichas variables, sino las definidas en el verdadero
tipo de los objetos que almacenan.
Herencia
El mecanismo de herencia es uno de los pilares fundamentales en los que se basa la
programacin orientada a objetos. Es un mecanismo que permite definir nuevas clases a
partir de otras ya definidas de modo que si en la definicin 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 automticamente como si su definicin incluyese la definicin
de la segunda a la que se le suele llamar clase padre o clase base.
Encapsulacin
Ya hemos visto que la herencia y el polimorfismo son dos de los pilares fundamentales
en los que se apoya la programacin orientada a objetos. Pues bien, el tercero es la
encapsulacin, que es un mecanismo que permite a los diseadores de tipos de datos
determinar qu miembros de los tipos pueden ser utilizados por otros programadores y
cules 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 cmo trabajar con l, pues se le
pueden ocultar todos los detalles relativos a su implementacin interna y
slo dejarle visibles aquellos que puedan usar con seguridad. Adems, as
se les evita que cometan errores por manipular inadecuadamente miembros
que no deberan tocar.
Se facilita al creador del tipo la posterior modificacin del mismo, pues si los
programadores clientes no pueden acceder a los miembros no visibles, sus
aplicaciones no se vern afectadas si stos cambian o se eliminan. Gracias a
esto es posible crear inicialmente tipos de datos con un diseo sencillo
aunque poco eficiente, y si posteriormente es necesario modificarlos para
aumentar su eficiencia, ello puede hacerse sin afectar al cdigo escrito en
base a la no mejorada de tipo.
La encapsulamiento de objetos u ocultacin de la informacin 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 difcil) y b) ofrecer un acceso
disciplinado a objetos slo a travs de una interfaz pblica, 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, razn por la cual la idea de slo poder operar a travs de
mtodos predefinidos no es aceptable en algunas situaciones. Los sistemas OO tienden
a ser demasiado rgidos en este aspecto.
La encapsulacin se consigue aadiendo modificadores de acceso en las definiciones
de miembros y tipos de datos. Estos modificadores son partculas que se les colocan
delante para indicar desde qu cdigos puede accederse a ellos, entendindose por
acceder el hecho de usar su nombre para cualquier cosa que no sea definirlo, como
llamarlo si es una funcin, leer o escribir su valor si es un campo, crear objetos o
heredar de l si es una clase, etc
Leccin 33. Arquitectura de administrador de sistemas de BDOO.
La estructura de las bases de datos orientadas a objetos no presenta la uniformidad de
las bases de datos relacinales. Para construir una estructura fsica fcil de mantener,
comnmente los objetos se representan as:
Determinadas clases se tratan como clases bsicas de bloques que se construyan, que
el sistema de computadores implemente directamente. Comnmente, las clases bsicas
corresponden a tipos de datos de lenguajes de programacin estndar, tales como
entero, flotante, carcter y cadena.
Las instancias de clases que no son bsicas 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 bsicas, o bien el identificador del objeto
para instancias de las clases que no son bsicas. Las variables con un conjunto de
valores se representan por una lista enlazada de los objetos que son miembros del
conjunto.
La estructura fsica hace que sea posible utilizar registros de longitud fija para
implementar una base de datos orientada a objetos, aunque la modificacin del
esquema puede complicar esto.
Cuando la relacin de contenido es jerrquica, 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 fsicamente y que, por razones prcticas, normalmente
se manipulan mediante programas de aplicacin que no son parte del conjunto de
mtodos 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. Comnmente, los datos de audio son una representacin comprimida
digitalizada del habla que manejan aplicaciones de software separadas.
Datos de video y grficos. Los datos de video pueden representarse como un mapa de
bytes o como un conjunto de lneas, cajas y otros objetos geomtricos.
Aunque algunos datos grficos 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 implementacin 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 mtodo ms ampliamente utilizado para acceder a campos largos es el mtodo de
verificacin de resultados de salida (checkout)/verificacin de datos de entrada (checkin).
El usuario comprueba (checkout) la copia de un objeto con campo largo, opera sobre esta
copia utilizando programas de aplicacin de propsito especial y comprueba la copia
modificada (checkin). Las nociones de verificacin de resultados de salida (checkout) y
verificacin de datos de entrada (checkin) corresponden aproximadamente a una lectura
y a una escritura. Sin embargo, el resultado de la operacin de verificacin de datos de
entrada normalmente no es una escritura sino ms bien la creacin de una nueva versin.
Leccin 34. Sistema administradores de bases de datos orientadas a
objetos (SABD-OO)
La primera vez que se habla del concepto de un SABD-OO se remonta al ao 1983 con
una propuesta de G. Copeland y D. Maier, en la cual sugieren construir tal SABD a partir
del lenguaje de programacin Smalltalk y con la colaboracin 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 ao, la compaa 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 caractersticas mnimas que deben ser satisfechas. En efecto, un SABD para ser
considerado con una etiqueta de orientacin 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 jerarqua 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 administracin de objetos complejos.
Reglas de orientacin a objetos
Los objetos deben tener una identidad independiente de su valor.
El sistema debe adems:
Permitir la nocin de encapsulamiento.
Agrupar los objetos en clases o poder establecer tipos.
Definir una jerarqua de clases o de tipos.
Permitir la programacin completa de las aplicaciones.
Permitir la extensin de las clases o tipos predefinidos por parte del usuario.
Leccin 35. El sistema Postgres
Para referenciar uno de los productos que trabajan este tipo de bases de datos hemos
tomado el proyecto Postgres. El proyecto Postgres- Post Ingres- inicia en 1986 como una
extensin del SABD Ingres. Ha sido escrito en el lenguaje de programacin C y consta de
180000 lneas de cdigo (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 jerarquas 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 atmico: 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 administracin de los objetos complejos
Permitir la definicin de nuevos tipos de datos, nuevos operadores y nuevos
mtodos de acceso.
Brindar mecanismos primarios para la definicin de bases de datos.
Mejorar la seguridad de funcionamiento.
Capitulo 8. Lenguaje de Modelado Unificado UML
La intencin de este captulo 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 temtica y su relacin con las bases de datos
UML es un lenguaje de modelamiento para la especificacin, visualizacin,
construccin y documentacin de los artefactos de un proceso de sistema intensivo.
Incluye dentro de otras las siguientes caractersticas:
Dentro de un proceso de sistema intensivo, un mtodo es aplicado para
llegar o evolucionar un sistema
Como un lenguaje, es usado para la comunicacin. Es decir, un medio
para capturar el conocimiento (semnticas) respecto a un tema y
expresar el conocimiento (sintaxis) resguardando el tema propsito de la
comunicacin. El tema es el sistema en estudio.
Como un lenguaje para modelamiento, se enfoca en la comprensin de
un tema a travs de la formulacin de un modelo del tema (y su contexto
respectivo). El modelo abarca el conocimiento cuidando del tema, y la
apropiada aplicacin de este conocimiento constituye inteligencia.
Cuidando la unificacin, integra las mejores prcticas de la ingeniera de la
industria tecnolgica y sistemas de informacin 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 cmo se aplica para especificar sistemas, puede ser usado
para comunicar "qu" se requiere de un sistema y "cmo" un sistema
puede ser realizado.
En cuanto a cmo se aplica para visualizar sistemas, puede ser usado
para describir visualmente un sistema antes de ser realizado.
En cuanto a cmo se aplica para construir sistemas, puede ser usado
para guiar la realizacin de un sistema similar a los "planos".
En cuanto a cmo 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 programacin visual, sino un lenguaje de modelamiento
visual
Una herramienta o depsito de especificacin, sino un lenguaje para
modelamiento de especificacin.
Un proceso, sino que habilita procesos.
Leccin 37. Mtodo o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los mtodos de anlisis
y diseo. Existen diferencias importantes entre un mtodo y un lenguaje de modelado.
Un mtodo es una manera explcita de estructurar el pensamiento y las acciones de cada
individuo. Adems, el mtodo le dice al usuario qu hacer, cmo hacerlo, cundo
hacerlo y por qu hacerlo; mientras que el lenguaje de modelado carece de estas
instrucciones. Los mtodos contienen modelos y esos modelos son utilizados para
describir algo y comunicar los resultados del uso del mtodo.
Elementos de UML:
Diagramas: Los diagramas son las grficas que describen el contenido de una vista.
UML tiene nueve tipos de diagramas que son utilizados en combinacin para proveer
todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de
estados, de secuencia, de colaboracin, de actividad, de componentes y de distribucin.
Smbolos 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
asociacin, dependencia y generalizacin. Un elemento
de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo
significado y simbologa.
Reglas o Mecanismos generales: Proveen comentarios extras, informacin o semntica
acerca del elemento de modelo; adems proveen mecanismos de extensin para
adaptar o extender UML a un mtodo o proceso especfico, organizacin o usuario.
Utilidad de UML
UML es un lenguaje para modelamiento de propsito 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
mtodos o procesos.
Como lenguaje de propsito general, se enfoca en el corazn de un
conjunto de conceptos para la adquisicin, comparticin y utilizacin de
conocimientos emparejados con mecanismos de extensin.
Como un lenguaje para modelamiento ampliamente aplicable, puede ser
aplicado a diferentes tipos de sistemas (software y no - software),
dominios (negocios versus software) y mtodos o procesos.
Como un lenguaje para modelamiento soportable por herramientas, las
herramientas ya estn disponibles para soportar la aplicacin 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 ms bien, un
lenguaje abierto y totalmente extensible reconocido por la industria.
Mejores tiempos totales de desarrollo (de 50 % o ms).
Modelar sistemas (y no slo de software) utilizando conceptos orientados
a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de
misin crtica.
Crear un lenguaje de modelado utilizado tanto por humanos como por
mquinas.
Mejor soporte a la planeacin y al control de proyectos.
Alta reutilizacin y minimizacin de costos.
UML posibilita la captura, comunicacin y nivelacin de conocimiento estratgico, tctico y
operacional para facilitar el incremento de valor, aumentando la calidad, reduciendo costos
y reduciendo el tiempo de presentacin al mercado; manejando riesgos y siendo proactivo
para el posible aumento de complejidad o cambio.
Leccin 38. Una perspectiva de UML
Las siguientes secciones presentan una vista ms detallada al modelado con UML. Un
sistema de reserva de aerolneas simple se va a usar para mostrar los diagramas y
tcnicas de modelado con UML. Se cubren los siguientes puntos:
Organizando tu sistema con paquetes
Modelando con Casos de Uso, y usndolos para averiguar los requisitos
del sistema
Modelando con Diagramas de Secuencia y Colaboracin
Analizando y diseando con el Diagrama de Clase, y extendiendo UML
con la tcnica de las tarjetas CRC
Modelando comportamiento con Diagramas de Actividad y de Estado
Modelando componentes de software, distribucin e implementacin
Extendiendo UML con el diseo 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,
categoras o subsistemas, la idea es la misma: dividir el sistema en reas que tengan
competencias parecidas.
UML introduce la nocin 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 ms alto, donde son usados para subdividir
el sistema en dominios, hasta el nivel ms 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
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 tcnica ms efectiva y a la vez la ms simple para
modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso
se utilizan para modelar cmo un sistema o negocio funciona actualmente, o cmo los
usuarios desean que funcione. No es realmente una aproximacin a la orientacin a
objetos; es realmente una forma de modelar procesos. Es, sin embargo, una manera
muy buena de dirigirse hacia el anlisis de sistemas orientado a objetos. Los casos de
uso son generalmente el punto de partida del anlisis 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 "muecos" 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 estmulo desde un actor. Se dibujan como
elipses.
Figura 35: Modelado de Casos de Uso.
Use Case Description in S1ep Form
1.Passenger rec&ests
ffightirom ticket vendar.
2.Ticket vendor crete
avaaJiifity frorr\ Airline 7~~"-
-
__
3.Airline says ticket is
available; provte sflight
details.
4.Ticket vendor praw'ftes
passenger wrth flight details.
5.Passenger reo/e-
ssseat preference. G.
Ticket vendor
jbooteseai.
7.Ticket vendor cof/fifms res
tvativftwih passenger
"Honre are
possible
classes or
class
attributes.
- Verbs
are
possible
operations
.
Cada caso de uso se documenta por una descripcin del escenario. La descripcin
puede ser escrita en modo de texto o en un formato paso a paso. Cada caso de uso
puede ser tambin 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 despus de que el escenario se completa. Los Diagramas de Actividad
ofrecen una herramienta grfica para modelar el proceso de un Caso de Uso. Ver fig.
35
Estudiar y descubrir los requisitos
El objetivo final en cualquier diseo 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 diseo, y que el
diseo 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 travs de los
Casos de Uso, permite el descubrimiento de estos requisitos.
Organizacin de Diagramas de Casos de Uso
Durante el anlisis de negocio (business) del sistema, puedes desarrollar un modelo de
caso de uso para este sistema, y construir paquetes para representar los varios dominios
de negocio (business) del sistema. Puedes descomponer cada paquete con un Diagrama
de Caso de Uso que contenga los Casos de Uso de un dominio, con interacciones de
actor.
Modelar secuencias alternas a travs de la relacin "Extiende"
(extends)
Tpicamente, 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 estn relacionados con el caso de uso
original mediante una relacin "Extiende" (extends). Las relaciones Extiende (extends)
pueden ser pensadas como un caso de uso equivalente a herencia, en el cual el caso
de uso extendido, hereda y modifica el comportamiento del caso de uso original.
Eliminar el modelado redundante a travs de la relacin "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 relacin
"Usa" (uses). La relacin Usa (uses) se puede pensar como un caso de uso equivalente.
Ver fig. 36.
Figura 36: Relacin caso de uso Extiende (extends) frente a relacin de caso
Usa (uses).
Leccin 39. Diagramas de Secuencia
El Diagrama de Secuencia es uno de los diagramas ms efectivos para modelar
interaccin 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 implementacin del
escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y
mensajes pasados entre los objetos.
Tpicamente uno examina la descripcin de un caso de uso para determinar qu objetos
son necesarios para la implementacin del escenario. Si tienes modelada la descripcin 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 lneas
discontinuas verticales, y los mensajes pasados entre los objetos como vectores
horizontales. Los mensajes se dibujan cronolgicamente desde la parte superior del
diagrama a la parte inferior; la distribucin horizontal de los objetos es arbitraria. Ver fig. 37.
Figura 37: Diagrama de Secuencia para un escenario
Durante el anlisis inicial, el modelador tpicamente coloca el nombre 'business' de
un mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre
'business' es reemplazado con el nombre del mtodo que est siendo llamado por
un objeto en el otro. El mtodo llamado, o invocado, pertenece a la definicin de la
case instan ciada por el objeto en la recepcin final del mensaje.
Leccin 40. Diagramas de Colaboracin
El Diagrama de Colaboracin 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 cronolgica del escenario que estamos
modelando, el diagrama de colaboracin 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 asociacin entre las clases
implicadas, ver fig. 38. El enlace muestra los mensajes enviados entre los objetos,
el tipo de mensaje (sincrnico, asincrnico, simple, blanking, y 'time-out'), y la
visibilidad de un objeto con respecto a los otros.
Figura 38: Diagrama de Colaboracin para un grupo de Objetos
Captulo 9. Modelado con UML
Leccin 41. Modelando el comportamiento de las Clases con Diagramas de
Estado
Mientras los diagramas de interaccin y colaboracin modelan secuencias
dinmicas de accin entre grupos de objetos en un sistema, el diagrama de estado
se usa para modelar el comportamiento dinmico 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 dinmico. En l, modelas la secuencia de estado que un objeto
de la clase atraviesa durante su vida en respuesta a los estmulos recibidos, junto
con sus propias respuestas y acciones.
Por ejemplo, un comportamiento de un objeto se modela en trminos de en qu
estado est inicialmente, y a qu estado cambia cuando recibe un evento en
particular. Tambin 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 lneas de transicin describen el movimiento desde un
estado hasta otro. Cada lnea de transicin se nombre con el evento que causa
esta transicin. Las acciones ocurren cuando un objeto llega a un estado. Ver fig.
39.
Figura 39: Modelando Comportamiento Dinmico de un objeto 'Vuelo' con un
diagrama de estado
Leccin 42. Diagramas de Actividad
El Diagrama de Actividad es un diagrama de flujo del proceso multi-propsito 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 mtodo
complicado.
Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave
es que los diagramas de actividad pueden mostrar procesado paralelo (parallel
processing). Esto es importante cuando se usan diagramas de actividad para
modelar procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y
para modelar varios hilos en los programas concurrentes.
Usando Diagramas de Actividad para modelar Casos de Uso
Los Diagramas de Actividad ofrecen una herramienta grfica para modelar el
proceso de un Caso de Uso. Se pueden usar como un aadido a una descripcin
textual del caso de uso, o para listar los pasos del caso de uso. Una descripcin
textual, cdigo, u otros diagramas de actividad pueden detallar ms la actividad.
Usando Diagramas de Actividad para modelar Clases
Cuando se modela el comportamiento de una clase, un diagrama de estado de
UML se suele usar normalmente para modelar situaciones donde ocurren eventos
asincrnicos. El diagrama de actividad se usa cuando todos o la mayora de los
elementos representan el desarrollo de los pasos dados por las acciones
generadas internamente. Ver fig. 40. Deberas asignar actividades a las clases
antes de terminar con el diagrama de actividad.
Figura 40: Diagrama de Actividad
Leccin 43. Modelando Componentes de Software
El Diagrama de Componentes se usa para modelar la estructura del software, incluyendo
las dependencias entre los componentes de software, los componentes de cdigo 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
Leccin 44. Modelando la Distribucin y la Implementacin
Los Diagramas de Implementacin se usan para modelar la configuracin de los
elementos de procesado en tiempo de ejecucin (run-time processing elements) y
de los componentes, procesos y objetos de software que viven en ellos. En el
diagrama 'deployment', empiezas modelando nodos fsicos y las asociaciones de
comunicacin que existen entre ellos. Para cada nodo, puedes indicar qu
instancias de componentes viven o corren (se ejecutan) en el nodo. Tambin
puedes modelar los objetos que contiene el componente.
Los Diagramas de Implementacin ver fig. 42, se usan para modelar slo
componentes que existen como entidades en tiempo de ejecucin; no se usan
para modelar componentes solo de tiempo de compilacin o de tiempo de
enlazado. Puedes tambin modelar componentes que migran de nodo a nodo u
objetos que migran de componente a componente usando una relacin de
dependencia con el estereotipo 'becomes' (se transforma)
Leccin 45. Diseo de Bases de Datos Relacionales -- Una extensin
informal de UML
El Diagrama de Clase presenta un mecanismo de implementacin 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
mtodo ms 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 diseo de bases de datos relacionales, pero no cubre toda la
semntica involucrada en el modelado relacional, mayoritariamente la nocin de atributos
clave que relacionan entre s las tablas unas con otras. Para capturar esta informacin, un
Diagrama de Relacin de Entidad (ER diagram) se recomienda como extensin a UML.
El Diagrama de Clase se puede usar para modelar la estructura lgica 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
mtodo de implementacin escogido, entonces el diagrama de clase puede ser
referenciados a un diagrama de relacin de entidad lgico. Las clases persistentes y sus
atributos hacen referencia directamente a las entidades lgicas y a sus atributos; el
modelador dispone de varias opciones sobre cmo 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 relacin de entidad (ER diagram).
Figura 43: Extensin de UML -- Diseo de Bases de Datos Relacionales con el
Diagrama de Relacin de Entidad (ER Diagram)
Ya en el Diagrama de Relacin de Entidad, el modelador puede empezar el proceso de
determinar cmo 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 lgico que sea conforme a las reglas de normalizacin de datos.
Al implementar el diseo relacional, es una estrategia encaminada a hacer referencia al
diagrama de relacin de entidad lgico a un diagrama fsico que represente el objetivo, el
RDBMS. El diagrama fsico puede ser denormalizado para lograr un diseo 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. Adems, el diagrama fsico
se usa para modelar propiedades especficas de cada fabricante para el RDBMS. Se crean
varios diagramas fsicos si hay varios RDBMSs siendo 'deployed'; cada diagrama fsico
representa uno de los RDBMS que son nuestro objetivo. Ver fig. 44
Figura 44: Relaciones clave entre entidades en un Diagrama de Relacin de Entidad
Consultas orientadas a objetos
Los lenguajes de programacin orientados a objetos requieren que toda la interaccin con
objetos sea mediante envo de mensajes. Esto presenta serias limitaciones en las
aplicaciones de bases de datos. Considrese el ejemplo del diseo 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
programacin orientada a objetos, se deber enviar un mensaje a cada instancia de la clase
Chip para verificar su valor vendedor. Si tratramos esta solicitud como un problema de la
base de datos, esperaramos que existiera un ndice para la clase Chip para las cuales el
campo vendedor fuera Old-block Corporation.
La ltima forma de cmo se va a tratar la consulta corresponde a una vista relacional de la
base de datos de objetos que vimos. De hecho, podramos 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 mtodos.
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 diseo
del lenguaje, a menudo conocido como impedancia desajustada.
Referencias
BATINI C.; Ceri S.; Navathe S. Diseo conceptual de bases de datos. Un enfoque de
entidades-interrelaciones. 1994. Ed. Addison-Wesley.
CASTAO A.; Piattini M. Fundamentos y modelos de bases de datos. 1999. Ed.
Alfaomega. Segunda edicin.
CERI S, Pelagatti G.,Distributed databases principles & systems.. Ed. MacGraw-Hill. 1985.
edicin.
DORSEY, P, Hudicka Oracle8. Diseo de bases de datos con UML. J. Ed. Oracle press.
1999.
KROENKE,D. Procesamiento de bases de datos. Fundamentos, diseo e implementacin.
2003. Ed. Pearson Education. Octava edicin
SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGraw-Hill.
Cuarta edicin
OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill.
ULLMAN, J Principles of database systems, Ed. Computer science press, 1982.

Base de Datos Avanzada v3

Cargado por

Información del documento

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 v3

Cargado por

Copyright:

Formatos disponibles

UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA UNAD

Escuela de Ciencias Bsicas, Tecnologa e Ingeniera

También podría gustarte