UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
MODULO BASE DE DATOS AVANZADA
ROGELIO VASQUEZ BERNAL
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA – UNAD FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA PROGRAMA INGENIERIA DE SISTEMAS BOGOTÁ D.C., 2005
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
CONTENIDO Temas Introducción
Pág. 8
UNIDAD 1 BASES DE DATOS RELACIONALES
1
CAPÍTULO 1. Conceptos básicos de bases de datos
1
1. Modelo entidad relación 1.2. Importancia del modelo entidad relación 1.3. Elementos del Modelo entidad relación 1.4 identificador único 2. Álgebra relacional 2.1. Selección 2.2. Proyección
1 2 3 10 14 15 15
2.4. Unión. 2.5. Intersección 2.6. Diferencia 2.7. Join o Reunión. 2.8. División 3. Normalización de datos 3.1 Modelo entidad – relación 3.2 Normalización 3.3 Desnormalización de datos
16 16 17 17 19 19 19 20 23
2.3. Producto.
15
CAPÍTULO 2. Transacciones
24
2.1. Propiedades de la transacción
24
CAPÍTULO 3. Consultas
29
3.1 Recuperación 3.2 Cálculo relacional 31 3.3 Optimización de consultas 32
29
2.2. Concurrencia 2.3 Seguridad y recuperación de datos
25 26
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
CONTENIDO Temas Introducción
Pág. 8
UNIDAD 1 BASES DE DATOS RELACIONALES
1
CAPÍTULO 1. Conceptos básicos de bases de datos
1
1. Modelo entidad relación 1.2. Importancia del modelo entidad relación 1.3. Elementos del Modelo entidad relación 1.4 identificador único 2. Álgebra relacional 2.1. Selección 2.2. Proyección
1 2 3 10 14 15 15
2.4. Unión. 2.5. Intersección 2.6. Diferencia 2.7. Join o Reunión. 2.8. División 3. Normalización de datos 3.1 Modelo entidad – relación 3.2 Normalización 3.3 Desnormalización de datos
16 16 17 17 19 19 19 20 23
2.3. Producto.
15
CAPÍTULO 2. Transacciones
24
2.1. Propiedades de la transacción
24
CAPÍTULO 3. Consultas
29
3.1 Recuperación 3.2 Cálculo relacional 31 3.3 Optimización de consultas 32
29
2.2. Concurrencia 2.3 Seguridad y recuperación de datos
25 26
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
UNIDAD 2
34
BASES DE DATOS DISTRIBUIDAS
34
Introducción y fundamentos de Base de Datos Distribuidas. CAPÍTULO 1. Diseño de bases de datos distribuidas 1.1 El problema de diseño 1.2 Objetivos del Diseño de la Distribución de los Datos 1.3 Enfoques al problema de diseño de bases de datos distribuidas 1.4 Fragmentación 1.5 Diseño de la Replica
34 39 39
40
CAPITULO 2. Consultas Distribuidas
2.1. Objetivo del procesamiento de las consultas 2.2. Niveles de procesador de consultas 2.3. Localización de datos 2.4 Procesamiento de intersección simple 2.5. Descomposición de una consulta y localización de datos distribuidos 2.6. Plan de optimización de consultas distribuidas
40 42 49 51 51 51 52 53 56 58
CAPITULO 3. Transacciones Distribuidas
58
3.1 Definición de una transacción 3.2 Condiciones de terminación de una transacción 3.3 Caracterización de transacciones 3.4 Caracterización de transacciones 3.5. Propiedades de las transacciones 3.6. Tipos de Transacciones 3.7. Estructura de transacciones 3.8. Aspectos relacionados al procesamiento de transacciones 3.9. Incorporación del manejador de transacciones a la arquitectura de un SMBD 3.10 Recuperación En Sistemas Distribuidos 3.11. Control De Concurrencia 3.11.1 Teoría de la seriabilidad 3.11.2 Seriabilidad en SMBD distribuidos 3.11.3. Taxonomía de los mecanismos de control de concurrencia 3.11.4 Algoritmos basados en candados 3.11.5 Algoritmos basados en estampas de tiempo 3.11.6 Control de concurrencia optimista
58 59 60 61 61 62 63 64 65 67 70 70 73 73 74 77 79
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
CAPITULO 4. Catalogo 4.1. Conceptos básicos 4.2. Centralizado 4.3. Completamente replicado 4.4. Dividido 4.5. Combinación de centralizado y dividido
82 82 82 82 82 82
UNIDAD 3
86
OTROS MODELOS DE BASES DE DATOS
86
CAPÍTULO 1. Bases de datos orientadas a objetos
86
1.1 Introducción 1.2 Conceptos básicos 1.3 Arquitectura de administrador de sistemas de BDOO. 1.4 Ssistema administradores de bases de datos orientadas a objetos (SABD-OO) 1.5 El sistema Postgres 1.6 Lenguaje de modelado unificado (UML) 1.6.1 Introducción 1.6.2 UML, ¿Método o Lenguaje de Modelado? 1.6.3 Una perspectiva de uml
86 87 89 91 92 92 92 94 95
1.6.4 Diagramas de Secuencia 1.6.5. Diagramas de Colaboración 1.6.6. Modelando el comportamiento de las Clases con Diagramas de Estado 1.6.7. Diagramas de Actividad 1.6.8 Modelando Componentes de Software 1.6.9 Modelando la Distribución y la Implementación 1.6.10 Diseño de Bases de Datos Relacionales -- Una extensión informal de UML 1.7 Consultas orientadas a objetos
101 102 103 104
CAPÍTULO 2. Bodega de datos
109
2.1 Introducción 2.2 Construcción y manejo de una bodega de datos 2.3 Manejo de los metadatos 2.4 Acceso y análisis de datos 2.5 Manejo de sistemas 3. Construcción de la bodega de datos 3.1 Ambiente actual
99 100
105 107
109 110 111 111 111 112 112
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
3.2 Ambiente de Negocios. 3.3 Ambiente técnico 3.4 Expectativas de los usuarios 4. Estrategias recomendadas para diseño de datos 4.1 Prototipo 4.2 Piloto 4.3 Prueba del concepto tecnológico 4.4 Arquitectura de la Bodega de Datos 4.5 Factores de riesgo 5. Minería de Datos 5.1. Introducción 5.2. Los Fundamentos del Data Mining 5.3. El Alcance de Data Minino 5.4. Fases de un Proyecto de Minería de Datos 5.5. ¿Cómo Trabaja el Data Mining? 5.6. Una arquitectura para Data Minino 5.7. Técnicas más comúnmente usadas en Data Mining:
112 112 112 112 112 113 113 113 115 116 116 116 117 119 119 120 121
GLOSARIO DE TÉRMINOS DE DATA MINING
123
FUENTES DOCUMENTALES
ANEXO:Resultados Relacional”
de ejemplos referenciados en la sección 2 “Álgebra
LISTA DE FIGURAS
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
FIGURAS
Pág.
Figura1. Representación de entidad 12 Figura 2. Representación de una relación 12 Figura 3. Relación recursiva 14 Figura 4. Nombre relaciones 14 Figura 5. Ejemplo nombre relaciones 15 Figura 6. Incorporando atributos 16 Figura 7. Atributos candidatos 16 Figura 8. Atributos candidatos 17 Figura 9. Un atributo repetido indica una entidad perdida. 18 Figura 10. Añadir la entidad perdida
18
Figura 11. Muestra de identificadores únicos
20
Figura 12. Refinamiento de Entidades
21
Figura 13. Reconocimiento de patrones
22
Figura 14 - Esquema de Relaciones de Ejemplo
23
Figura 15 Primera forma normal
29
Figura 16. Segunda y tercera forma normal
31
Figura 17 - Pasos en el procesamiento de una consulta SQL
33
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 18. Motivación de los sistemas de bases de datos distribuidos.
44
Figura 19. Un sistema centralizado sobre una red
45
Figura 20. Un medio ambiente distribuido para bases de datos
46
Figura 21. El enfoque top-down para el diseño de bases de datos distribuidas 50 Figura 22. El problema de fragmentación de relaciones.
51
Figura 23. El grado de fragmentación
53
Figura 24. Un modelo de transacción.
68
Figura 25. Un modelo del administrador de transacciones.
76
Figura 26. Ejecución centralizada de transacciones.
77
Figura 26b. Ejecución distribuida de transacciones.
77
Figura 27. Clasificación de los algoritmos de control de concurrencia
84
Figura 28. Gráfica del uso de los candados de dos fases.
86
Figura 29. Comportamiento de los candados de dos fases estrictos
86
Figura 30. Comunicación en un administrador centralizado de candados de dos fases estrictos.
87
Figura 31. Comunicación en candados de dos fases distribuidos
88
Figura 32. Fases de la ejecución de una transacción a) pesimista, b) optimista.
90
Figura 33. Casos diferentes de las pruebas de validación para control de concurrencia optimista. Figura 34: Organizando el sistema mediante el uso de paquetes Figura 35: Modelado de Casos de Uso.
91 106
107
Figura 36: Relación caso de uso Extiende (extends) frente a relación de caso
Usa (uses). Figura 37: Diagrama de Secuencia para un escenario
109 110
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 38: Diagrama de Colaboración para un grupo de Objetos
111
Figura 39: Modelando Comportamiento Dinámico de un objeto 'Vuelo' con
un diagrama de estado
112
Figura 40: Diagrama de Actividad
113
Figura 41: Modelando componentes con el Diagrama de Componentes
114
Figura 42: Modelando la Distribución del Sistema con el Diagrama de Implementación Figura 43: Extensión de UML -- Diseño de Bases de Datos Relacionales con el Diagrama de Relación de Entidad (ER Diagram) Figura 44: Relaciones clave entre entidades en un Diagrama de Relación de Entidad Figura 45: Fases de un Proyecto de Minería de Datos
LISTA DE TABLAS
115 116 117 129
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Pág. Tabla 1 - Operadores del Álgebra relacional
23
Tabla 2. Comparación de las estrategias de replicación de fragmentos.
54
INTRODUCCIÓN
“Un sistema de base de datos es básicamente un sistema computarizado para llevar registros”1. El modulo base de datos avanzada tiene como propósito fundamental profundizar algunos temas tratados en base de datos básica y presentar un esquema nuevo para un nivel más avanzado. Los temas aquí tratados requieren de un buen conocimiento de bases de datos y un gran deseo por profundizar cada uno de ellos en la bibliografía y cibergrafía recomendada. Los estudiantes deben trabajar el modulo acompañado de la guía de actividades y del protocolo académico para lograr así el propósito del curso académico.
1
C.J. DATE
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
UNIDAD 1 BASES DE DATOS RELACIONALES Capítulo 1. Conceptos básicos de bases de datos 2. Modelo entidad relación
Es una técnica para definir las necesidades de información de una organización. El modelo entidad relación en su forma más simple implica identificar asuntos importantes dentro de la organización (entidades) , propiedades de esos asuntos (atributos) y como se relacional entre si (relación). Esto tiene valor solamente dentro del contexto de lo que se realiza en la empresa y en la forma de actuar de estas funciones de gestión sobre el modelo de información. 1.1. Objetivos del modelo entidad relación Proporcionar un modelo preciso de las necesidades de información de la organización.
Proporcionar un modelo independiente de cualquier almacenamiento de datos y método de acceso, que permita tomar decisiones de las técnicas de implementación y coexistencia con sistemas antiguos. 1.2. Importancia del modelo entidad relación Ofrece un medio efectivo y preciso de especificar y controlar la definición de las necesidades de información. A continuación se indican diez temas clave que se necesitan tener en cuenta cuando se utiliza el modelo:
Dato: un recurso clave Hoy en día un dato, como recurso, se acepta por ser importante para la evolución satisfactoria de la organización como lo son los recursos financieros, humanos y físicos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Compromiso con la dirección La dirección debe confirmar los requisitos de información. No importa lo inteligente que usted resulte al modelizar, tendrá un éxito limitado sin el compromiso de la dirección.
Convenciones En todo momento se deben aplicar convenciones rigurosas, estándares y directrices, incluyendo los conceptos de normalización de datos.
Definición mínima Se debería definir o modelizar cualquier información o concepto de datos sólo de una forma, y a continuación configurar asociaciones para los objetos relacionados. Como por ejemplo, se debería definir una vez una cosa denominada “Pedido de compra” y a continuación relacionarlo con el departamento, los productos, las funciones de autorización y así sucesivamente, como se requiera.
Independencia de los datos Se deben definir los requisitos de información de forma que sean independientes de cualquier almacenamiento final o método de acceso y que nos permita tener una visión creativa y objetiva de la empresa y del diseño subsiguiente.
Patrones genéricos Deberían buscarse patrones genéricos de datos para permitir a los usuarios utilizarlos en su gestión, además de tener la oportunidad de perfeccionar la forma de procesar sus datos y de sugerir estructuras más rentables y flexibles para los diseñadores de bases de datos.
Actitud y calidad Los modelizadores deben comenzar aplicar las convenciones automáticas y velozmente, pero sin sacrificar el rigor. También debe aprovechar cualquier oportunidad con los usuarios para mejorar la precisión de los modelos.
Comunicación Debe haber comunicación con los usuarios finales, en términos que ellos puedan entender auque debe seguir siendo técnicamente riguroso. Estas técnicas de modelización se han utilizado durante muchos años para ayudar a altos ejecutivos, directores y a otros a comprender su gestión. Es esencial utilizar un lenguaje claro, sin abreviaturas, para lograr su comprensión. Con un usuario final no deberíamos utilizar la palabra entidad.
Relevancia Los requisitos de información solamente pueden tener valor si aportan las necesidades funcionales de la organización, dentro del marco de trabajo de los objetivos y propósitos de la empresa.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Un medio, no un fin Aunque el modelo entidad relación es muy potente, ofrecer una idea increíble de la compañía y actuar como un marco de trabajo para el diseño de los datos, solo es una técnica intermedia, aunque desde luego importante.
1.3. Elementos del Modelo entidad relación
El modelo entidad relación para ser funcional requiere de la definición de unos elementos, los cuales se precisan a continuación: 1.3.1 Entidad Se define como entidad a cualquier objeto real o abstracto, que existe en un contexto determinado o puede llegar a existir y del cual deseamos guardar información. Representación de entidad : Una entidad se representa en forma de diagrama con un recuadro y en su interior un nombre. El nombre se muestra en singular y con letras mayúsculas (figura 1).
NOMBRE ENTIDAD
Figura1. Representación de entidad Reglas para definir una entidad: Cualquier objeto sólo puede ser representado por una entidad. Es decir las entidades son mutuamente exclusivas en todos los casos. Cada entidad debe ser identificada en forma única. Es decir, cada instancia (aparición) de una entidad debe encontrarse separada e identificable claramente de todas las demás instancias de ese tipo de entidad.
1.3.2. Relación Se entiende por relación a la asociación, vinculación o correspondencia entre entidades. Por ejemplo entre la entidad PROFESOR y la entidad CURSO podemos establecer la relación IMPARTE porque el profesor imparte cursos. Una relación es binaria en el sentido de que es siempre una asociación entre exactamente dos entidades, o entre una entidad y ella misma. Cada relación tiene dos extremos, para cada uno de los cuales tiene un: Nombre Grado / cardinalidad (cuantos)
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Opcionalidad (opcional u obligatorio).
Estas propiedades se utilizan para describir la asociación desde un extremo; se deben definir ambos extremos. Representación de una relación : Una relación se representa mediante una línea que une dos recuadros de entidades, o recursivamente (recurrentemente) une un recuadro de entidad consigo mismo. La relación más común es la que tiene un grado de muchos a uno: en el extremo muchos es obligatoria y opcional en el extremo uno, como se muestra en la figura 2.
Muchos
opcional obligatorio
uno
Figura 2. Representación de una relación
Para un grado de muchos, la línea de relación une un recuadro de tres puntos, conocido como ramificación. Para un grado de uno, la línea se une solamente en un punto. En donde la terminación de la relación es obligatoria, se dibuja una línea continua para esa mitad de la relación. En donde la terminación de la relación es opcional, se dibuja una línea discontinua o de guiones. Es útil pensar acerca de una relación de uno a muchos como una relación padre a hijo, con la existencia del hijo encontrándose en una forma dependiente de su padre. 1.3.2.1 Relación recursiva Es una relación que se llama así misma, a continuación se muestra una relación recursiva con propiedades idénticas.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 3. Relación recursiva Nombre de las relaciones : El nombre de cada extremo de una relación se sitúa cerca al extremo apropiado en minúsculas como se muestra a continuación.
ENTIDAD - A
nombre- extremo-1
ENTIDAD -B
nombre-extremo-2 Figura 4. Nombre relaciones
Cuando la terminación de la relación es obligatoria, la frase “debe ser” se utiliza para preceder al nombre final de la relación; para los nombres finales opcionales de la relación se utiliza la frase “puede ser” Por lo tanto el diagrama de la figura 5 se leería así: Cada ENTIDAD-A debe ser el nombre-extremo-1 una y solo una ENTIDAD-B, y de derecha a izquierda: Cada ENTIDAD-B puede ser el nombre-extremo-2 y una o más ENTIDADes-A. Veamos el siguiente ejemplo:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
TIQUETE
PASAJERO
para mostrado en Figura 5. Ejemplo nombre relaciones
Explicación: Cada TIQUETE debe ser para uno y sólo un PASAJERO y derecha a izquierda, cada PASAJERO se puede observar en uno o más TIQUETES. El plural del nombre de la entidad se utiliza cuando el grado es muchos. Un grado de muchos se lee como uno o más, y un grado de uno como uno y solamente uno. Cuando se dibujan diagramas de entidad relación, se puede encontrar un grado mayor de precisión si la ramificación (los finales de muchos) se puede situar en la terminación izquierda y superior de la línea de relación. 1.3.3. Atributos Las entidades se componen de atributos que son cada una de las propiedades o características que tienen las entidades. Cada ejemplar de una misma entidad posee los mismos atributos, tanto en nombre como en número, diferenciándose cada uno de los ejemplares por los valores que toman dichos atributos. Ejemplo si consideramos la entidad PROFESOR y definimos los atributos Nombre, Teléfono, Salario; podríamos obtener lo siguiente: Juan Pérez Rodríguez, 4253250, 800.000 Martha López Jiménez, 8553260, 600.000 1.3.3.1 Representación de los atributos Para representar un atributo hay que escribir su nombre en singular y en minúscula, y de forma opcional con un ejemplo de su valor.
ENTIDAD - A Atributo – 1 Atributo - 2
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 6. Incorporando atributos
En el ejemplo siguiente, los atributos candidatos son esenciales para ayudar a distinguir entre dos entidades.
AVION
de clasificación de
PASAJERO código descripción
Figura 7. Atributos candidatos
En este informe, la línea aérea puede que haya adquirido sólo cuatro o cinco tipos de aviones diferentes, pero puede tener cien o más aviones reales. El número de registro de atributo tendría un único valor para cada instancia de la entidad AVION. 1.3.4. Características del atributo
Las siguientes normas simples ayudan a crear un modelo preciso, completo y flexible. 1.3.4.1. Un atributo describe una entidad El atributo debe describir la entidad en contra de lo que se muestra.
Esto puede ser obvio, pero es el error más común que se encuentra en los atributos. Por ejemplo. ¿El "número de asiento" es un atributo de un cupón, billete, tarjeta de embarque, avión o asiento de un avión? Obviamente es un atributo de ASIENTO, pero en la vida real el número a menudo se ve duplicado muchas veces; por ejemplo, en una tarjeta de embarque, que se muestra como una entidad en la Figura 8. ¿Por qué? En el mundo real, un número de asiento es una forma muy conveniente de representar una relación. Por el contrario, cuando se encuentran estas situaciones hay que dibujar la línea de relación (si es necesario , crear la entidad a la que se refiere), como se muestra a continuación.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Para que sirva de guía la mayoría de las entidades sólo se describirán manejando entre dos y ocho atributos. Si se tienen más, probablemente existirán muchas relaciones y/o entidades perdidas.
TIQUETE DE EMBARQUE
ASIENTO
emitido para
fecha
número
utilizado mediante en compuesto de
AVION
Figura 8. Asignar un atributo a la entidad correcta
1.3.4.2 Leer nombres de atributos
No hay que utilizar el nombre de la entidad como parte del nombre del atributo. Sería redundante, ya que el atributo sólo describe la entidad. En el ejemplo anterior, el “el número asiento” realmente ayudó a identificar una entidad perdida llamada ASIENTO que se podría describir con el atributo ’número’ y quizás con otros atributos como ‘tipo’. Para leer atributos que se nombren de esta manera, se pueden utilizar de una de las dos formas:
Nombre entidad nombre atributo o Nombre atributo de nombre entidad.
Por ejemplo, asiento número o número de asiento. 1.3.4.2.
Eliminar atributos repetidos (primera forma normal)
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Una entidad que sólo tenga un valor para un atributo en cualquier momento. Si son esenciales muchos valores, se debe crear una entidad nueva para mantenerlos en la relación muchos a uno unidos con la entidad original.
AVION número de registro nombre asiento 1 asiento 2 ... asiento 96
Figura 9. Un atributo repetido indica una entidad perdida.
Siguiendo la norma anterior se obtiene:
ASIENTO número
en compuesto de
AVION número de registro nombre
Figura 10. Añadir la entidad perdida
Esta es una norma o regla que se llama normalmente ’Primera forma normal’ 1.3.4.3. Nombre en singular El nombre de un atributo debe ir en singular. Los nombres plurales generalmente reflejan el problema de los atributos repetidos que se ha mostrado anteriormente.
¿Es una entidad? Un atributo se convierte en una entidad cuando tiene importancia por sí misma, con sus propias relaciones y atributos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
1.3.4.4. identificador único Cada entidad debe ser identificable únicamente por una combinación de atributo y/o relación. De esta forma se podría buscar siempre cualquier atributo candidato que ayude a identificar una entidad. 1.3.4.5. El valor del atributo debe ser dependiente de todo el identificador único. (segunda forma normal) Hay que quitar los atributos por los que los valores son dependientes sólo de parte del identificador único. Esto se conoce como ’Segunda forma normal’ . Dichos atributos normalmente suponen una entidad perdida, pero relacionada. 1.3.4.6. Los atributos deben ser dependientes directamente del identificador único (tercera forma normal) Hay que quitar los atributos que no sean dependientes directamente del identificador único de la entidad. Esto se conoce como ‘Tercera forma normal’. En el subtema tres se profundizara el concepto de normalización. 1.4.
Identificador único
1.4.1. Definición Cada entidad debe ser únicamente identificable de forma que cada instancia de la entidad esté separada y sea claramente identificable de todas las otras instancias de ese tipo de entidad. El identificador único puede ser un atributo, una combinación de relaciones o una combinación de atributos y relaciones. Una entidad puede tener más de un medio alternativo de identificación única. El método primario se puede mostrar en el diagrama entidad-relación antecediendo a un atributo que forme el identificador con una marca ‘#’ , y colocando una barra cruzada en el caso de una (s) línea (s) de relación. Figura 11
TIQUETE DE EMBARQUE # * fecha emitida # * hora emitida
ASIENTO
emitida para
# * número
usado mediante
emitida para utilizado mediante
en compuesto de
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
AVION
de planificado como RUTA DELA LINEA AEREA
# * número de vuelo
Figura 11. Muestra de identificadores únicos
Así, pues, para identificar únicamente una tarjeta de embarque se necesita:
La relación con el asiento, y por tanto el número de asiento. La relación con el vuelo, y por tanto la fecha y hora de la salida, La fecha y hora emitidas en el caso raro en que las tarjetas de embarque se hayan reemitido; para volver a sentar a una familia junta después de que alguien no haya aparecido en el vuelo Como el identificador único del vuelo también incluye la relación con la ruta de la línea aérea, se necesita el número de vuelo.
ASIENTO número
en compuesto de
AVION número de registro nombre
Figura 12. Refinamiento de Entidades
1.4.2. Norma de Diseño Las normas simples del diseño que siguen a continuación se han definido para que el diagrama sea fácil de leer, aplicable para personas que necesiten trabajar con ellas y para maximizar la calidad y la precisión. 1.4.2.1. Diagrama de Subconjunto
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Cuando se trata un área funcional en particular con un usuario o un diseño con los diseñadores, es bueno crear un diagrama de subconjunto y expresar las ideas de nuevo más eficazmente como un vehículo de comunicación con ese propósito. Durante el proceso se van a encontrar omisiones y errores, que se pueden corregir rápidamente la perspectiva diferente es una potente herramienta analítica. 1.4.2.2. Esmerado y pulcro Hay que organizar el diagrama de forma que los recuadros de las entidades estén alineados y que las líneas de las relaciones sean rectas en sentido horizontal o vertical. Hay que dibujar el menor número de líneas cruzadas posible. Hay que evitar Construir un diagrama que tenga demasiadas líneas paralelas que estén muy juntas. Hay que utilizar el mayor espacio en blanco que se pueda para evitar el sentimiento de congestión y utilice de vez en cuando la línea en diagonal para ayudar a la estética del diagrama. 1.4.2.3. Reconocimiento de patrones La mayoría de las personas tienen la capacidad incorporada de reconocer formas y patrones en un instante y por tanto pueden recordar fácilmente el tema. Los
modelizadores pueden beneficiarse de esto haciendo que cada diagrama sea claramente diferente en forma. 1.4.2.4. Texto Hay que asegurarse de que el texto no sea ambiguo. Hay que evitar las abreviaturas y las jergas. Hay que utilizar las convenciones de lectura descritas anteriormente y leer todo el diagrama para asegurarse de que es completo y preciso. Un buen diagrama entidad relación debería ser semánticamente completo. Para mejorar la comprensión y la precisión al leerlo, hay que añadir adjetivos y ejemplos cuando sea necesario.
PRODUCTO
clasificado por
GRUPO DE PRODUCTOS
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
clasificado para
Figura 13. Reconocimiento de patrones
Hay que centrar, alinear a la izquierda o a la derecha el texto consecuentemente, de forma que se extraigan resultados de buena calidad. 1.4.4.5. Grado de relación Hay que situar la terminación de muchas (ramificaciones) de las relaciones a la izquierda o en la parte superior de la línea de relación. Se ha probado que esta técnica ha incrementado la precisión del modelo formando la consideración de las relaciones, desde las entidades que aparecen con más frecuencia a las menos frecuentes.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
2. Álgebra relacional
Es necesario que el lector se familiarice con el termino “relación”, entendida en dos aspectos, en primer lugar cuando mencionamos esta palabra en el modelo entidad relación se hace referencia a la asociación entre dos o más entidades, y, al hablar de “relación” en el álgebra relacional se esta haciendo referencia a tablas, puesto que las tablas son esencialmente relaciones. El Álgebra relacional es un lenguaje de consulta procedural. Consta de un conjunto de operaciones que toman como entrada una o dos relaciones y producen como resultado una nueva relación, por lo tanto, es posible anidar y combinar operadores. Hay ocho operadores en el álgebra relacional que construyen relaciones y manipulan datos, estos son: 1. Selección 4. Unión 7. Join
2. Proyección 5. Intersección 8. División
3. Producto 6. Diferencia
Tabla 1 - Operadores del Álgebra relacional
Las operaciones de proyección, producto, unión, diferencia, y selección son llamadas primitivas, puesto que las otras tres se pueden definir en términos de estas. Se hace necesario en este punto incluir un modelo de datos de ejemplo en el cual trabajar para generar ejemplos de comandos y operadores. Para este efecto se incluye un modelo básico de administración de Radio taxis. El Gráfico que se presenta a continuación representa el Modelo conceptual (Modelo Lógico) o Diagrama de Entidad-Relación, (este adopta una metodología similar a la anterior):
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 14 - Esquema de Relaciones de Ejemplo
Los Esquemas de relaciones que se pueden construir a partir de este modelo son los siguientes: Dueño = {rut, nombre, teléfono, dirección, vigencia} Chofer = {rut, nombre, teléfono, dirección, fecha_licencia_desde, fecha_licencia_h asta, vigencia} Vale = {correlativo, hora_desde, hora_hasta, metraje_total, tarifa_total} Móvil = {patente, rut_dueño, rut_chofer, marca, modelo, año} Viaje = {correlativo_vale, patente_movil, Hora_Desde, hora_hasta, origen, destino, tarifa, metraje}
2.1. Selección. El operador de selección opta por tuplas que satisfagan cierto predicado, se utiliza la letra griega sigma minúscula (σ) para señalar la selección. El predicado aparece como subíndice de σ. La Relación que constituye el argumento se da entre paréntesis después de la σ.
Ejemplos :
2.2. Proyección.
La operación de proyección permite quitar ciertos atributos de la relación, esta operación es unaria, copiando su relación base dada como argumento y quitando ciertas columnas, La proyección se señala con la letra griega pi mayúscula ( Π). Como subíndice de Π se coloca una lista de todos los atributos que se desea
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
aparezcan en el resultado. La relación argumento se escribe después de Π entre paréntesis. Ejemplos :
2.3. Producto En álgebra relacional el producto de dos relaciones A y B es: .
A Veces B o A X B Produce el conjunto de todas las Tuplas t tales que t es el encadenamiento de una tupla a perteneciente a A y de una b que pertenece a B. se utiliza el símbolo X para representar el producto. Ejemplos: Dueño x Móvil
2.4. Unión.
En álgebra relacional la unión de dos relaciones compatibles [1]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 teoría de conjuntos el símbolo U representa aquí la unión de dos relaciones. Ejemplo :
(Dueño)
(Chofer)
Π rut, vigencia U Π rut, vigencia Devuelve todos los Dueños y los Chóferes .
2.5. Intersección. En álgebra relacional la intersección de dos relaciones compatibles A y B
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
A INTERSECCION B o A ∩ B Produce el conjunto de todas las tuplas pertenecientes a A y B. Al igual que en teoría de conjuntos el símbolo ∩ representa aquí la intersección entre dos relaciones. Ejemplo: (Dueño)
(Chofer)
Π rut, vigencia ∩ Π rut, vigencia Devuelve todos los dueños que también son chóferes
2.6. Diferencia En álgebra relacional la diferencia entre dos relaciones compatibles A y B
A MENOS B o A – B Produce el conjunto de todas las tuplas t que pertenecen a A y no pertenecen a B. Ejemplo: Π rut, vigencia
(Dueño)
- Π rut, vigencia (Chofer)
Devuelve todos los dueños que NO son chóferes
2.7. Join o Reunión.
En álgebra relacional el JOIN entre el atributo X de la relación A con el atributo Y de la relación B produce el conjunto de todas las tuplas t tal que t es el encadenamiento de una tupla a perteneciente a A y una tupla b perteneciente a B que cumplen con el predicado “A.X comp B.Y es verdadero” (siendo comp un operador relacional y los atributos A.X y B.Y pertenecientes al mismo dominio). Si el operador relacional “comp” es “=” entonces el conjunto resultante es un EQUIJOIN. Si se quita uno de éstos (usando una proyección) entonces el resultado es un JOIN-NATURAL. Ejemplo :
2.8. División
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
En álgebra relacional el operador de división divide la relación A con grado m + n por la relación B entregando como resultado una relación con grado m. El atributo m + i de A y el atributo i de B deben estar definidos dentro del mismo dominio. Así el resultado de A DIVIDIDO POR B o A / B produce la relación C con un sólo atributo X, tal que cada valor de x de C.X aparece como un valor de A.X, y el par de valores (x, y) aparece en A para todos los valores y que aparecen en B. Ejemplo:
Selecciona todos los autos a cuyos chóferes les caduca la licencia el 01/01/1999 Nota del autor: los resultados de cada uno de los ejemplos citados en este tema están al
final del modulo como un anexo.
Relaciones Compatibles: En el álgebra relacional la compatibilidad se aplica a las operaciones de Unión, Intersección y Diferencia. Cada operación requiere dos relaciones que deben ser compatibles, esto significa que deben ser del mismo grado, n, y el i-ésimo atributo de cada una (i= 1, 2...n) se debe basar en el mismo dominio. [1]
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
3. Normalización de datos La normalización de datos es un procedimiento que asegura que un modelo de datos se ajusta a algunos estándares útiles. Para los datos y los modelos entidadrelación, estos estándares se han definido para minimizar la duplicación de datos, proporcionar la flexibilidad necesaria para soportar requisitos funcionales y para permitir que el modelo se estructure sobre una amplia variedad de diseños alternativos de base de datos. 3.1 Modelo entidad – relación
El modelo entidad-relación tiende a producir entidades que están normalizadas de forma natural. Esto debido a que se sigue un proceso simple, como el siguiente:
Percibir las cosas de significación sobre lo que se necesita saber y mantener la información. Estas entidades deben ser mutuamente exclusivas, y se representan en un diagrama por medio de un recuadro con el nombre de la entidad en singular y en mayúsculas.
Añadir las relaciones de gestión, las cuales se han nombrado como asociaciones significativas entre entidades. Estas relaciones se muestran como una línea entre dos recuadros; cada terminación tiene un grado (un triángulo o ramificación que significa muchos; si no hay triángulo significa uno) y la opcionalidad (una línea de puntos significa opcional, una línea continua significa obligatorio).
En cada entidad se listan los tipos de información que se podrían mantener o conocer. Estos atributos se muestran dentro de la entidad como nombres en minúsculas.
Finalmente, se determina la forma en que cada aparición de una entidad puede ser identificada de forma única. Esto se hará mediante alguna combinación de atributos y/o relaciones. Cuando un atributo es parte del identificador único se muestra con una marca #. Cuando una relación es parte del identificador único se muestra mediante una barra cruzada cruzando la línea de relación. El seguimiento del proceso anterior dará rigurosa y automáticamente un modelo normalizado, pero depende de la buena comprensión del analista acerca de lo que es realmente un atributo, una relación y una entidad.
3.2 Normalización
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Para comprobar que un modelo entidad-relación tiene todas sus entidades unívocamente identificadas, se ha normalizado completamente y por tanto se ajusta a la tercera forma normal; se pueden aplicar las siguientes comprobaciones simples: Asegurar que todas las entidades son identificables de forma única Por una combinación de atributos y / o relaciones 3.2.1 Primera forma normal: [1NF]
Eliminar los atributos repetidos o grupos de atributos. Si existe más de un valor a la vez para un atributo o para más de uno con el mismo nombre, se define una entidad nueva, la cual se describe mediante ese atributo. El identificador único de esta nueva entidad consta de uno de los atributos que se fueron con ella y la relación (de muchos a uno) se lleva a la entidad original. VUELO # fecha # hora # número de vuelo nombre línea área nombre aeropuerto tipo de avión capacidad de asientos nombre tripulante 1 función tripulante 1 nombre tripulante 2 función tripulante 2 nombre tripulante 3
1NF
Eliminar atributos repetidos
MIEMBRO DE TRIPULACIÓN para * nombre * función
tripulado por
VUELO # fecha # hora # número de vuelo nombre de aerolínea nombre aeropuerto tipo de avión capacidad de asientos
Eliminar atributos dependientes en sólo una parte del identificador único
Figura 15 Primera forma normal 3.2.2 Segunda forma normal: [2NF]
Eliminar atributos dependientes sólo en parte del identificador único.
2NF
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Si una entidad tiene un identificador único compuesto de más de un atributo y/o relación, y si otro atributo depende sólo de parte de este identificador compuesto, entonces el atributo, y la parte del identificador del que depende, deberán formar la base de una nueva entidad. La entidad nueva se identifica por la parte emigrada del identificador único de la entidad original, y tiene una relación de uno a muchos unido a la entidad original. 3.2.3 Tercera forma normal: [3NF]
Eliminar los atributos dependientes de atributos que no son parte del identificador único. Si un atributo de una entidad es dependiente de otro atributo, que no es parte del identificador único, entonces estos atributos deberían formar la base de la nueva entidad, que tenga una relación de uno a muchos con la entidad original. El identificador único de la entidad nueva es el atributo del que depende el otro atributo. A continuación se presenta la representación de esta forma:
MIEMBRO DE TRIPULACIÓN nombre función
para tripulado por
VUELO # fecha # hora de planificado como
Eliminar atributos dependientes
RUTA DE LINEAS AEREAS #número de vuelo nombre aerolínea nombre aeropuerto tipo de avión capacidad de asientos
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
s
servido por operado sobre operada por encargada de
Figura 16. Segunda y tercera forma normal
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
En general, “una relación R está en la tercera forma normal (3NF) si y sólo si en cualquier momento cada tupla (línea relacional) de R se compone de un valor clave primario que identifica alguna identidad, junto con un grupo de cero o más valores independientes mutuamente que describen esa entidad de alguna manera”.2 Además, “una relación R está en la cuarta forma normal (4NF) si y únicamente si donde quiera que haya una dependencia multivalores (MVD) en R, digamos A B, todos los atributos de R son también funcionalmente dependientes de A. En otras palabras, las únicas dependencias (funcionales o multivalores) en R son de la forma K X. De modo equivalente: R está en 4NF si todos los MVDs (dependencias multivalores) son de verdad dependencias funcionales (FD). También, “una relación R está en quinta forma normal (5NF), también denominada forma normal de unión de protección (PJ/PN), si y únicamente si cada dependencia de unión en R es una consecuencia de las claves candidatas de R.” 3.3 Desnormalización de datos
La desnormalización de datos es el procedimiento inverso, llevado a cabo puramente por razones de mejorar la realización de sistemas de producción, particularmente cuando están computarizados. La desnormalización sólo se debe realizar sobre el diseño. No poner en peligro nunca el modelo de gestión. La desnormalización en formas manuales de procedimientos es necesariamente muy común, como queda evidenciado por el hecho de que la mayor parte de los formularios en papel mantienen grandes datos de referencias. Todos conocemos los problemas que se pueden originar cuando ese dato se cambia y se tiene que volver a emitir el grupo entero de formularios.
2
Date, C.J. An Introduction to Database System, 4ed. 1986. Adisson-Wesley Publishing Co.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Capítulo 2. Transacciones
Una transacción es una unidad de la ejecución de un programa que accede y posiblemente actualiza varios elementos de datos. Se delimita dependiendo del lenguaje por las sentencias inicio transacción y fin transacción y se compone de todas las instrucciones que se encuentran entre estos dos delimitadores. 2.1. Propiedades de la transacción Para asegurar la consistencia de los datos se necesita que el sistema de base de datos tengan las propiedades llamadas ACID: (Atomicity, Consistency, Isolation, Durability - Atomicidad, Consistencia, Aislamiento, Durabilidad [Silberschatz97]). A continuación explicamos cada una de estas propiedades:
Atomicidad: Asegura que o bien todos los efectos de la transacción se reflejan en la base de datos, o bien ninguno de ellos; un fallo no puede dejar a la base de datos en un estado en el cual una transacción se haya ejecutado parcialmente.
Consistencia: Asegura que si la base de datos es consistente inicialmente, la ejecución de la transacción deja la base de datos en un estado consistente.
Aislamiento: Asegura que en la ejecución concurrente de transacciones, estas están aisladas unas de otras, de tal manera que cada una tiene la impresión de que ninguna otra transacción se ejecuta concurrentemente con ella.
Durabilidad: Asegura que una vez que la transacción se ha comprometido, las actualizaciones hechas por la transacción no se pierden, incluso si hay un fallo en el sistema.
Una transacción que termina con éxito se dice que está comprometida (commited), una transacción que haya sido comprometida llevará a la base de datos a un nuevo estado consistente que debe permanecer incluso si hay un fallo en el sistema. En cualquier momento una transacción sólo puede estar en uno de los siguientes estados:
Activa (Active): el estado inicial; la transacción permanece en este estado durante su ejecución.
Parcialmente comprometida (Uncommited): Después de ejecutarse la última transacción.
Fallida (Failed): tras descubrir que no se puede continuar la ejecución normal.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Abortada (Rolled Back): después de haber retrocedido la transacción y restablecido la base de datos a su estado anterior al comienzo de la transacción.
Comprometida (Commited): tras completarse con éxito. Cuando varias transacciones se ejecutan concurrentemente, existe la posibilidad de que se pierda la consistencia de datos. Se hace necesario por lo tanto un sistema que controle la interacción entre las transacciones concurrentes. Puesto que una transacción por definición conserva la consistencia, una ejecución lineal de transacciones la garantiza también. Un sistema que asegure esta propiedad se dice que asegura la secuencialidad.
2.2. Concurrencia Existen varios esquemas de control de concurrencia que aseguran la secuencialidad, todos estos esquemas o bien retrasan una operación o bien abortan la transacción que ha realizado la operación. Los más conocidos son los protocolos de bloqueo, el esquema de ordenación por marcas temporales, las técnicas de validación, el esquema de granularidad múltiple y los esquemas multiversión.
Un protocolo de bloqueo es un conjunto de reglas que indican el momento en que una transacción puede bloquear o desbloquear un objeto de la base de datos. El protocolo de bloqueo de dos fases permite que una transacción bloquee un objeto sólo después de que haya desbloqueado otro objeto distinto, este método asegura la secuencialidad. El esquema de ordenación por marcas temporales asegura la secuencialidad seleccionando previamente un orden en todo par de transacciones. Existen 2 formas de implementar este esquema, uno es por medio de valores timestamp (dependientes del reloj del sistema) y por medio de un contador lógico que se incrementa cada vez que asigna una nueva marca temporal. Este protocolo asegura la secuencialidad en cuanto a conflictos y la ausencia de interbloqueos, si una de las transacciones viola la norma la transacción se retrasa y se le asigna una nueva marca temporal. Por ejemplo, una operación leer se puede retrasar porque todavía no se ha escrito el valor apropiado o incluso rechazar si ha sobrescrito el valor que supuestamente se iba a leer. Un esquema de validación es un método de control de concurrencia adecuado para transacciones de sólo lectura y en las cuales la tasa de conflictos es baja. Se basa en dividir una transacción en 3 etapas (lectura, validación y escritura) y trabajar con el esquema de marcas temporales sobre la etapa de validación. De esta manera se quita una sobrecarga en la etapa de lectura, en la cual no se necesita un esquema de control de concurrencia dado que toda lectura lleva a la base de datos al mismo estado de consistencia. Una manera distinta manejar la concurrencia es por medio de la granularidad, este
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
concepto permite agrupar varios elementos de datos y definirlos como un todo para efectos de sincronización. Se define como una jerarquía de distintos niveles, donde el nivel superior puede representar toda la base de datos, se esquematiza como estructura de árbol donde los nodos hijos de un nodo interno representan las dependencias de datos asociadas. Se utilizan los tipos de bloqueos Compartidos y Exclusivos más un nuevo tipo de bloqueo llamado el bloqueo intencional, el cual indica que existen nodos descendientes que tienen bloqueos compartidos o exclusivos. El esquema multiversión se basa en la creación de nuevas versiones de los elementos de datos cada vez que una transacción vaya a escribir dicho elemento. Cuando se va a realizar una escritura el sistema elige una de las versiones para que se lea. El esquema de control de versiones garantiza que la versión que se va a leer se elige de forma que asegure la secuencialidad por medio de marcas temporales. En este esquema una operación de lectura tiene éxito siempre, sin embargo, una operación de escritura puede provocar el retroceso de una transacción. Un sistema está en estado de interbloqueo si existe un conjunto de transacciones tal que toda transacción del conjunto está esperando a otra transacción del conjunto. En tal situación, ninguna de las transacciones puede progresar. Existen 2 métodos para tratar los interbloqueos y ambos provocan un retroceso de las transacciones, la diferencia radica en que uno es preventivo y otro curativo. El protocolo de prevención de interbloqueos asegura que el sistema nunca llegará a un estado de interbloqueos mientras que el método de detección y de interbloqueos permite que el sistema llegue a un estado de interbloqueos para luego tratar de recuperarse. La prevención se usa normalmente cuando la probabilidad de que el sistema llegue a un estado de interbloqueo es relativamente alta, de lo contrario lo más conveniente es usar la detección y recuperación. 2.3. Seguridad y recuperación de datos
Los fallos que ocurren en un computador pueden darse por diferentes motivos (fallos de disco, cortes de energía o fallos en el software). En cada uno de estos casos puede perderse información concerniente a la base de datos. Existen varios tipos de fallas, a considerar: Fallo en la transacción, que a su vez se dividen en errores lógicos y errores del sistema. Un error lógico ocurre cuando una transacción no puede continuar con su ejecución normal a causa de una condición interna como lo es un desbordamiento o un exceso de recursos. Un error del sistema ocurre cuando el sistema se encuentra en un estado no deseado como en el caso de los interbloqueos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Caída del sistema, provocado ya sea por el hardware, el sistema operativo o por el software de base de datos. Comúnmente causa la pérdida del contenido de la memoria primaria y aborta el procesamiento de una transacción.
Fallo de disco, para el cual sólo sirve la recuperación por medio de copias existentes en medios de almacenamiento secundario como cintas magnéticas.
La forma más aceptada de lograr un tipo de almacenamiento lo más estable posible es replicando la información en varios medios de almacenamiento no volátil, con modos de fallos independientes. Los sistemas RAID (disposición redundante de discos independientes) garantizan que el fallo de un sólo disco no conduzca a la perdida de datos. Sin embargo los sistemas RAID, no pueden proteger al sistema de una pérdida de datos en el caso de una catástrofe geográfica, para tales efectos muchos sistemas de almacenamiento guardan copias de seguridad en cintas en otros lugares, no obstante, como las cintas no pueden ser trasladadas continuamente, los últimos cambios realizados luego del traslado de cintas no se pueden volver a recuperar en el caso de tales desastres. Los sistemas más seguros guardan copias de cada bloque de almacenamiento en otra disposición geográfica, datos que se transmiten por medios de redes de computadores al sistema de respaldo remoto... El estado de un sistema de base de datos puede no volver a ser consistente en caso de que ocurran fallos, para preservar la consistencia es necesario que cada transacción sea atómica. Garantizar la propiedad de atomicidad es responsabilidad del esquema de recuperación. Existen básicamente 2 esquemas que garantizan la atomicidad. Basados en el registro histórico[4]. Todas las modificaciones se graban en el registro histórico, el cual debe estar guardado en almacenamiento estable. En el esquema de modificación diferida, durante la ejecución de una transacción, se difieren todas las operaciones de escritura hasta que la transacción se compromete parcialmente, momento en el cual se utiliza la información del registro histórico asociado con la transacción para ejecutar las escrituras diferidas. Con la técnica de modificación inmediata todas las modificaciones se aplican directamente en la base de datos. Si ocurre una caída se utiliza la información del registro histórico para llevar a la base de datos a un estado estable previo. Paginación en la sombra. Durante la vida de una transacción se mantienen 2 tablas de páginas: la tabla actual de páginas y la tabla de páginas sombra. Ambas tablas son idénticas al principio de la transacción, sin embargo, la tabla actual de páginas puede ir cambiando luego de cada operación escribir. Todas las operaciones de lectura y escritura utilizan la tabla de páginas actual, cuando una
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
transacción se compromete parcialmente se desecha la tabla de páginas sombra y la tabla actual se convierte en la nueva tabla de páginas. Si la transacción fracasa, simplemente se desecha la tabla actual de páginas.
El procesamiento de transacciones se basa en un modelo de almacenamiento en el cual la memoria principal contiene una memoria intermedia para el registro histórico, una memoria intermedia para la base de datos y una memoria intermedia para el sistema. Una implementación eficiente de un esquema de recuperación de datos requiere que sea mínimo el número de escrituras de la base de datos y que sea realizado en almacenamiento estable. Los registros del registro histórico pueden guardarse inicialmente en la memoria intermedia del registro histórico pero deben ser llevados a almacenamiento estable bajo dos situaciones:
Deben escribirse en almacenamiento estable todos los registros del registro histórico que referencien a la transacción Ti antes de grabar el registro que indique que la transacción Ti ha sido comprometida
Deben escribirse en almacenamiento estable todos los registros del registro histórico pertenecientes a los datos de un bloque antes de que ese bloque de datos se escriba desde la memoria intermedia a la base de datos.
[4]
Comúnmente llamado log de transacciones
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Capítulo 3. Consultas
El Procesamiento de consultas hace referencia a la serie de actividades a seguir para llevar a cabo la recuperación de datos desde una base de datos. Estas actividades incluyen la traducción de consultas en lenguajes de consultas de alto nivel (Ej: SQL) a expresiones que se puedan implementar en un nivel físico, así como también los algoritmos de evaluación y optimización de consultas. 3.1 Recuperación
Una de las ventajas principales del modelo relacional presentado por Codd en 1970 es la que tiene relación con la independencia de los datos que se entiende aquí como la separación entre el modelo (lógico) y la implementación (física). Esta separación nos permite desarrollar una poderosa semántica lógica independiente de una implementación física particular. Uno de los desafíos de la independencia de datos es que la codificación de una consulta para la base de datos se componga de 2 fases: 1. La descripción lógica de la consulta (que se supone que debe hacer). 2. La definición del plan de ejecución físico (el que muestra como implementar
la consulta).
Antes de empezar el procesamiento de la consulta el sistema debe traducir la consulta a un medio de representación interno con el cual le sea fácil operar. Así, por ejemplo para SQL la representación más útil es la del álgebra relacional extendida (árbol relacional). Este proceso cumple la misma función que el analizador léxico y sintáctico de un compilador, es decir, revisa la sintaxis de la consulta y chequea que todos lo identificadores sean nombres de objetos de la base de datos, en el caso de las vistas reemplaza el nombre de la vista por la expresión relacional que la representa. El plan de ejecución es un árbol relacional armado a partir de la consulta y que sólo puede ser entendido por el motor de ejecución de consultas. La transformación de la consulta a un plan puede ser hecha efectivamente a mano y en algunos casos de consultas simples que se ejecutan miles de veces esta podría ser la mejor estrategia, sin embargo, una de las ventajas que nos ofrece el modelo relacional es la capacidad de usar la información del catalogo de la base de datos, que como se verá más adelante, podrá responder una gran cantidad de preguntas distintas.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Por otro lado, aunque una consulta simple pueda ser ejecutada miles de veces, no existe un camino mecánico que garantice que el plan de ejecución elegido satisfaga la consulta que se quiere implementar, puesto que: 1. Un Plan calculado a mano (o un plan precalculado) será invalidado por
cambios lógicos dentro del esquema o por cambios físicos en el camino de acceso a la información o en el almacenamiento físico.
2. Si los parámetros de la consulta (o los datos) cambian, la relación optima
que asocia a un plan con una consulta por sobre otros puede cambiar.
La siguiente figura nos muestra los pasos en el procesamiento de una consulta.
Figura 17 - Pasos en el procesamiento de una consulta SQL
Después de enviar la consulta, la base de datos debe producir su correspondiente plan de ejecución. El primer paso en este proceso es traducir la consulta desde SQL a un árbol lógico en álgebra relacional, proceso comúnmente llamado parser. El Próximo paso es traducir el árbol de la consulta en el plan de ejecución. Generalmente existe un gran número de planes que implementan al árbol de la consulta; el proceso de encontrar el mejor de estos planes se le denomina optimización de consultas.
3.2.
Cálculo relacional
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
La manipulación del modelo relacional esta basada en el álgebra relacional; sin embargo, de igual forma podemos indicar que también esta basada en el cálculo relacional. Álgebra y cálculo son alternativos entre sí, la diferencia entre ellos es la siguiente: mientras que el álgebra proporciona un conjunto de operadores explícitos (juntar, unir, proyectar, etc), que pueden usarse para indicar al sistema cómo construir cierta relación dada, al cálculo simplemente proporciona una notación para establecer la definición de esa relación deseada en términos de dichas relaciones dadas3. El cálculo relacional de tuplas describe la información deseada sin dar un procedimiento específico para obtenerla. Las consultas en el cálculo relacional de tuplas se expresan como: { t | P(t)} ,
Es decir, son el conjunto de tuplas t tales que se cumple el predicado P para cada t . Siguiendo la misma notación, se utiliza t[A] para el valor de la tupla t en el atributo A.
Si sólo se desea obtener un atributo de la tupla, se utiliza el constructor “Existe” de la lógica matemática. Así, si lo que se desea es el Nombre de los dueños de taxis que estén vigentes:
"Conjunto de todas las tuplas t tales que existe una tupla s en la relación Dueño para la que los valores de t y de s son iguales en el atributo Nombre y el valor de s para el atributo vigencia = ‘S’ ". La variable de tupla t se define sólo en el atributo Nombre, puesto que éste es el único atributo para el que se especifica una condición para t. Así, el resultado es una relación sobre (Nombre). Si lo que se desea es obtener las tarifas de todos los viajes que ha efectuado todos los móviles de marca “chevrolet”, la consulta requiere de dos cláusulas “Existe” conectadas por el operador de conjunción lógica “y”.
3
C.J Date, Introducción a los Sistemas de Bases de d e Datos, Prentice Hall
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Que se lee como el conjunto de todas las tuplas (tarifa) correspondientes a los viajes que han hecho todos los móviles de marca “chevrolet”. Considérese ahora la consulta “obtener todos los RUT de los dueños de móviles, cuyos móviles no hayan efectuado nunca un viaje”:
que ocupa la cláusula “Existe” para exigir que el dueño posea un móvil y la cláusula “no existe” para eliminar a aquellos móviles que tengan viajes realizados. La consulta que se presenta a continuación utiliza la implicación, la fórmula “P implica Q” significa que “si P es verdad entonces Q debe ser verdad”, se introduce el constructor “para todo”. Se desea Selecciona todos los autos a cuyos chóferes les caduca la licencia el “01/01/1999”.
Sin embargo como la intención del modulo no es la de suplir al texto, se recomienda consultar el tema completo en la bibliografía recomendada. 3.3 Optimización de consultas
Las consultas de base de datos relacionales son o bien declarativas o algebraicas. Los lenguajes algebraicos permiten la transformación algebraica de la consulta, luego, basándose en la especificación algebraica de la consulta es relativamente fácil para el optimizador generar diversos planes equivalentes para la consulta y elegir el menos costoso. Dado este nivel de generalidad, el optimizador puede ser visto como el generador de código de un compilador para el lenguaje SQL, que produce el código que será interpretado por el motor de ejecución de consultas, excepto que el optimizador marca énfasis en la capacidad de producir el código más eficiente, haciendo uso para tales efectos del catálogo de la base de datos, de donde obtiene información estadística de las relaciones referenciadas por la consulta, algo que los lenguajes de programación tradicionales no hacen.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Un aspecto de la optimización de consultas se sitúa en el nivel del álgebra relacional. Dado un conjunto de reglas se trata de encontrar una expresión que sea equivalente a la expresión dada pero que sea más eficiente en la ejecución. Con el fin de seleccionar la mejor estrategia para la recuperación de datos el optimizador “estima” un costo que estará relacionado a cada plan de ejecución. Este costo está determinado por fórmulas predefinidas en base a información que se posee de la tabla y que se ha rescatado previamente del catálogo de la base de datos, en realidad el optimizador no siempre escoge el plan más óptimo, ya que encontrar la estrategia óptima puede consumir mucho tiempo, por lo tanto se dice que el optimizador “sólo escoge una estrategia razonablemente eficiente”. La manera con la que el optimizador utiliza esa información, las distintas técnicas y algoritmos que aplica y las transformaciones algebraicas que se realizan son las que diferencian a los optimizadores de bases de datos. Un optimizador basado en el costo genera una serie de planes de evaluación para una consulta y luego elige el que tiene un menor costo asociado, las medidas de costo comúnmente tienen que ver con la E/S y el tiempo de CPU utilizado en ejecutar la consulta, sin embargo, es cuestión de cada SGBD el elegir las medidas de costo que mejor representen el criterio de minimización en la utilización de recursos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
UNIDAD 2 BASES DE DATOS DISTRIBUIDAS Introducción y fundamentos de Base de Datos Distribuidas.
La cantidad de innovaciones tecnológicas que ha habido en los últimos años ha promovido un cambio en la forma de observar a los sistemas de información y, en general, a las aplicaciones computacionales. Existen avances tecnológicos que se realizan continuamente en circuitos, dispositivos de almacenamiento, programas y metodologías. Sin embargo, los cambios tecnológicos van de la mano con la demanda de los usuarios y programas para la explotación exhaustiva de tales dispositivos mejorados. Por tanto, existe un continuo desarrollo de nuevos productos los cuales incorporan ideas nuevas desarrolladas por compañías e instituciones académicas. Aún cuando es posible que un usuario común no perciba los desarrollos relevantes de nuevos productos, para las aplicaciones existe una demanda permanente por mayor funcionalidad, mayor número de servicios, más flexibilidad y mejor rendimiento. Así, al diseñar un nuevo sistema de información o al prolongar la vida de uno ya existente, se debe buscar siempre formas para enlazar las soluciones ofrecidas por la tecnología disponible a las necesidades de las aplicaciones de los usuarios. Un área en la cual las soluciones están integrando tecnología con nuevas arquitecturas o formas de hacer las cosas es, sin lugar a dudas, el área de los sistemas distribuidos de información. Ellos se refieren al manejo de datos almacenados en facilidades de cómputo localizadas en muchos sitios ligados a través de una red de comunicaciones. Un caso específico de estos sistemas distribuidos es lo que se conoce como bases de datos distribuidas, tópico a estudiar en estas notas. Conceptualización de Bases de Datos Distribuidas.
Los sistemas de bases de datos distribuidas son un caso particular de los sistemas de cómputo distribuido en los cuales un conjunto de elementos de procesamiento autónomos (no necesariamente homogéneos) se interconectan por una red de comunicaciones y cooperan entre ellos para realizar sus tareas asignadas. Históricamente, el cómputo distribuido se ha estudiado desde muchos puntos de vista. Así, es común encontrar en la literatura un gran número de términos que se han usado para identificarlo. Entre los términos más comunes que se utilizan para referirse al cómputo distribuido podemos encontrar: funciones distribuidas, procesamiento distribuido de datos, multiprocesadores, multicomputadoras, procesamiento satelital, procesamiento tipo "backend", computadoras dedicadas y
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
de propósito específico, sistemas de tiempo compartido, sistemas funcionalmente modulares. Existen muchos componentes a distribuir para realizar una tarea. En computación distribuida los elementos que se pueden distribuir son:
Control. Las actividades relacionadas con el manejo o administración del sistema. Datos. La información que maneja el sistema. Funciones. Las actividades que cada elemento del sistema realiza. Procesamiento lógico. Las tareas específicas involucradas en una actividad de procesamiento de información.
Figura 18. Motivación de los sistemas de bases de datos distribuidos.
Una base de datos distribuida (BDD) es un conjunto de múltiples bases de datos lógicamente relacionadas las cuales se encuentran distribuidas entre diferentes sitios interconectados por una red de comunicaciones (ver Figura18). Un sistema de bases de datos distribuida (SBDD) es un sistema en el cual múltiples sitios de bases de datos están ligados por un sistema de comunicaciones, de tal forma que, un usuario en cualquier sitio puede accesar los datos en cualquier parte de la red exactamente como si los datos estuvieran almacenados en su sitio propio. Un sistema de manejo de bases de datos distribuidas (SMBDD) es aquel que se encarga del manejo de la BDD y proporciona un mecanismo de acceso que hace que la distribución sea transparente a los usuarios. El término transparente significa que la aplicación trabajaría, desde un punto de vista lógico, como si un solo SMBD ejecutado en una sola máquina, administrara esos datos. Un sistema de base de datos distribuida (SBDD) es entonces el resultado de la integración de una base de datos distribuida con un sistema para su manejo.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Dada la definición anterior, es claro que algunos sistemas no se pueden considerar como SBDD. Por ejemplo, un sistema de tiempo compartido no incluye necesariamente un sistema de manejo de bases de datos y, en caso de que lo haga, éste es controlado y administrado por una sola computadora. Un sistema de multiprocesamiento puede administrar una base de datos pero lo hace usualmente a través de un solo sistema de manejo de base de datos; los procesadores se utilizan para distribuir la carga de trabajo del sistema completo o incluso del propio SMBD pero actuando sobre una sola base de datos. Finalmente, una base de datos la cual reside en un solo sitio de una red de computadoras y que es accesada por todos los nodos de la red no es una base de datos distribuida (Figura 19). Este caso se trata de una base de datos cuyo control y administración esta centralizada en un solo nodo pero se permite el acceso a ella a través de la red de computadoras.
CALI MEDELLIN
GUAJIRA
RED DE COMUNICACIÓN
CARTAGENA
BOGOTA
Figura 19. Un sistema centralizado sobre una red.
El medio ambiente típico de un SMBDD consiste de un conjunto de sitios o nodos los cuales tienen un sistema de procesamiento de datos completo que incluye una base de datos local, un sistema de manejo de bases de datos y facilidades de comunicaciones. Si los diferentes sitios pueden estar geográficamente dispersos, entonces, ellos están interconectados por una red de tipo WAN. Por otro lado, si los sitios están localizados en diferentes edificios o departamentos de una misma organización pero geográficamente en la misma ubicación, entonces, están conectados por una red local (LAN) (Figura 20).
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
CALI MEDELLIN
GUAJIRA
RED DE COMUNICACIÓN
CARTAGENA
BOGOTA
Figura 20. Un medio ambiente distribuido para bases de datos . Tipos de bases de datos distribuidas.
En términos generales, podemos decir que existen dos tipos de sistemas de bases de datos distribuidas, homogéneas y sistemas de bases de datos distribuidas heterogéneas. La homogeneidad o heterogeneidad, puede darse a diferentes niveles, Hardware, Software o sistema operativo. Para este curso, se asume que cuando se indica la homogeneidad del sistema, se hace referencia a que en todos los sitios del sistema, existe el mismo sistema de administración de base de datos y generalmente incluye el mismo modelo de datos. Un sistema de bases de datos distribuido, incluye diferentes sistemas manejadores de bases de datos, probablemente con modelos de datos diferentes que hay que compatibilizar y con retos a nivel de comunicación entre los sistemas de bases de datos que conforman el sistema, para dar la visión al usuario de integración y de un único sistema de bases de datos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
CAPÍTULO 1. Diseño de bases de datos distribuidas
En el presente capítulo se mostrará los aspectos importantes referentes al diseño de una base de datos distribuida. Se revisará el problema de fragmentación de los datos así como la transparencia que un sistema de datos distribuidos debe guardar respecto a la vista del usuario. Se presentarán los algoritmos para fragmentación horizontal, fragmentación horizontal derivada y fragmentación vertical. En la parte final de este capítulo se discute el problema de asignamiento de fragmentos. 1.1 El problema de diseño
El problema de diseño de bases de datos distribuidos se refiere, en general, a tomar decisiones acerca de la ubicación de datos y programas a través de los diferentes sitios de una red de computadoras. Este problema debería estar relacionado al diseño de la misma red de computadoras. Sin embargo, en estas notas únicamente el diseño de la base de datos se toma en cuenta. La decisión de donde colocar a las aplicaciones tiene que ver tanto con el software del SMBDD (sistema manejador de base de datos distribuidas) como con las aplicaciones que se van a ejecutar sobre la base de datos. El diseño de las bases de datos centralizadas contempla los puntos siguientes: 1. Diseño del "esquema conceptual" el cual describe la base de datos integrada (esto es, todos los datos que son utilizados por las aplicaciones que tienen acceso a las bases de datos). 2. Diseño "físico de la base de datos", esto es, mapear el esquema conceptual a las áreas de almacenamiento y determinar los métodos de acceso a las bases de datos. En el caso de las bases de datos distribuidas se tienen que considerar los problemas siguientes: 1. Diseño del “esquema conceptual”, donde se busca describir el modelo de datos de todo el sistema
1. Diseño de la fragmentación, este proceso se determina mediante la división de las tablas en fragmentos horizontales, verticales o mixtos, dependiendo de las necesidades de información detectadas en la etapa de análisis del sistema.
3. Diseño de la asignación de los fragmentos, esto determina la forma en que los
fragmentos se mapean en los sitios o nodos del sistema. 4. Diseño de replicación. Proceso que indica en que lugar (nodos), se ubican copias de tablas o fragmentos y la frecuencia de actualización de la información.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
1.2 Objetivos del Diseño de la Distribución de los Datos.
En el diseño de la distribución de los datos, se deben de tomar en cuenta los siguientes objetivos: Procesamiento local. La distribución de los datos, para maximizar el procesamiento local corresponde al principio simple de colocar los datos tan cerca como sea posible de las aplicaciones que los utilizan. Se puede realizar el diseño de la distribución de los datos para maximizar el procesamiento local agregando el número de referencias locales y remotas que le corresponden a cada fragmentación candidata y la localización del fragmento, que de esta forma se seleccione la mejor solución de ellas. Distribución de la carga de trabajo . La distribución de la carga de trabajo sobre los sitios, es una característica importante de los sistemas de cómputo distribuidos. Esta distribución de la carga se realiza para tomar ventaja de las diferentes características (potenciales) o utilizaciones de las computadoras de cada sitio, y maximizar el grado de ejecución de paralelismo de las aplicaciones. Sin embargo, la distribución de la carga de trabajo podría afectar negativamente el procesamiento local deseado. Costo de almacenamiento y disponibilidad . La distribución de la base de datos refleja el costo y disponibilidad del almacenamiento en diferentes sitios. Para esto, es posible tener sitios especializados en la red para el almacenamiento de datos. Sin embargo el costo de almacenamiento de datos no es tan relevante si éste se compara con el del CPU, I/O y costos de transmisión de las aplicaciones. 1.3 Enfoques al problema de diseño de bases de datos distribuidas
Existen dos estrategias generales para abordar el problema de diseño de bases de datos distribuidas: El enfoque de arriba hacia abajo (top-down). Este enfoque es más apropiado para aplicaciones nuevas y para sistemas homogéneos. Consiste en partir desde el análisis de requerimientos para definir el diseño conceptual y las vistas de usuario. A partir de ellas se define un esquema conceptual global y los esquemas externos necesarios. Se prosigue con el diseño de la fragmentación de la base de datos, y de aquí se continúa con la localización de los fragmentos en los sitios, creando las imágenes físicas. Esta aproximación se completa ejecutando, en cada sitio, "el diseño físico" de los datos, que se localizan en éste. En la Figura 21 se presenta un diagrama con la estructura general del enfoque top-down. El diseño de abajo hacia arriba (bottom-up). Se utiliza particularmente a partir de bases de datos existentes, generando con esto bases de datos distribuidas. En
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
forma resumida, el diseño bottom-up de una base de datos distribuida requiere de la selección de un modelo de bases de datos común para describir el esquema global de la base de datos. Esto se debe, a que es posible que se utilicen diferentes SMBD. Después se hace la traducción de cada esquema local en el modelo de datos común y finalmente se hace la integración del esquema local en un esquema global común.
Figura 21. El enfoque top-down para el diseño de bases de datos distribuidas.
El diseño de una base de datos distribuida, cualquiera sea el enfoque que se siga, debe responder satisfactoriamente las siguientes preguntas: ¿Por qué hacer una fragmentación de datos? ¿Cómo realizar la fragmentación? ¿Qué tanto se debe fragmentar? ¿Cómo probar la validez de una fragmentación? ¿Cómo realizar el asignamiento de fragmentos?
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
¿Cómo considerar los requerimientos de la información?
Figura 22. El problema de fragmentación de relaciones. 1.4 Fragmentación
El problema de fragmentación se refiere al particionamiento de la información para distribuir cada parte a los diferentes sitios de la red, como se observa en la Figura 22. Inmediatamente aparece la siguiente pregunta: ¿cuál es la unidad razonable de distribución? Se puede considerar que una relación completa es lo adecuado ya que las vistas de usuario son subconjuntos de las relaciones. Sin embargo, el uso completo de relaciones no favorece las cuestiones de eficiencia sobre todo aquellas relacionadas con el procesamiento de consultas. La otra posibilidad es usar fragmentos de relaciones (sub-relaciones) lo cual favorece la ejecución concurrente de varias transacciones que accesan porciones diferentes de una relación. Sin embargo, el uso de sub-relaciones también presenta inconvenientes. Por ejemplo, las vistas de usuario que no se pueden definir sobre un solo fragmento necesitarán un procesamiento adicional a fin de localizar todos los fragmentos de una vista. Aunado a esto, el control semántico de datos es mucho más complejo ya que, por ejemplo, el manejo de llaves únicas requiere considerar todos los fragmentos en los que se distribuyen todos los registros de la relación. En resumen, el objetivo de la fragmentación es encontrar un nivel de particionamiento adecuado en el rango que va desde tuplas o atributos hasta relaciones completas (ver Figura 23 ). Ejemplo 1. Considere una relación J del ejemplo visto en la introducción del presente capítulo. J: JNO
JNOMBRE
PRESUPUESTO
LUGAR
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
J1 J2 J3 J4 J5
Instrumentación Desarrollo de bases de datos CAD/CAM Mantenimiento CAD/CAM
150000 135000 250000 310000 500000
Guajira Cartagena Medellín Cartagena Bogotá
La relación J se puede fragmentar horizontalmente produciendo los siguientes fragmentos. J1: Proyectos con presupuesto menor que $200,000 JNO
JNOMBRE
PRESUPUESTO
J1 J2
Instrumentación Desarrollo de bases de datos
150000 135000
LUGAR Guajira Cartagena
J2: Proyectos con presupuesto mayor que o igual a $200,000 JNO
JNOMBRE
J3 J4 J5
CAD/CAM Mantenimiento CAD/CAM
PRESUPUESTO 250000 310000 500000
LUGAR Medellín Cartagena Bogotá
Ejemplo 2. La relación J del ejemplo anterior se puede fragmentar verticalmente produciendo los siguientes fragmentos: J1: información acerca de presupuestos de proyectos JNO
PRESUPUESTO
J1 J2 J3 J4 J5
150000 135000 250000 310000 1500000
J2: información acerca de los nombres y ubicaciones de proyectos JNO
JNOMBRE
J1
Instrumentación
LUGAR Guajira
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
J2 J3 J4 J5
Desarrollo de bases de datos CAD/CAM Mantenimiento CAD/CAM
Cartagena Medellín Cartagena Bogotá
Figura 23. El grado de fragmentación. Correctitud de una fragmentación: Al realizar la fragmentación de una relación se deben satisfacer las siguientes condiciones para garantizar la correctitud de la misma:
Condición de completitud. La descomposición de una relación R en los fragmentos R1, R2, ..., Rn es completa si y solamente si cada elemento de datos en R se encuentra en algún de los Ri. Condición de Reconstrucción. Si la relación R se descompone en los fragmentos R1, R2, ..., Rn, entonces debe existir algún operador relacional Ñ , tal que, R = Ñ 1≤ I ≤ n Ri
Condición de Fragmentos Disjuntos. Si la relación R se descompone en los fragmentos R1, R2, ..., Rn, y el dato di está en Rj, entonces, no debe estar en ningún otro fragmento Rk (k¹ j). Alternativas sobre replicación para el asignamiento de fragmentos La replicación de información es de utilidad para obtener un mejor rendimiento y para ofrecer un mayor grado de confiabilidad (tolerancia a fallas). La replicación se complica cuando es necesario hacer actualizaciones a las copias múltiples de un dato. Por tanto, respecto a la replicación, en el asignamiento de fragmentos se tienen tres estrategias:
No soportar replicación. Cada fragmento reside en un solo sitio. Soportar replicación completa. Cada fragmento en cada uno de los sitios.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Soportar replicación parcial. Cada fragmento en algunos de los sitios.
Como regla general se debe considerar que la replicación de fragmentos es de utilidad cuando el número de consultas de solo lectura es (mucho) mayor que el número de consultas para actualizaciones. En la Tabla 1 se comparan la complejidad de implementar o tomar ventaja de las diferentes alternativas de replicación, respecto de los diferentes aspectos importantes en bases de datos distribuidas.
Procesamiento de Consultas Manejo de Directorios Control de Concurrencia Confiabilidad Realidad
Recopilación completa Recopilación Parcial Fácil Moderado
Particionamiento Moderado
Fácil o no existente Moderado
Moderado Difícil
Moderado Fácil
Muy alto Aplicación posible
Alto Realista
Bajo Aplicación posible
Tabla 2. Comparación de las estrategias de replicación de fragmentos . Requerimientos de información:
Con el fin de realizar una fragmentación adecuada es necesario proporcionar información que ayude a realizarla. Esta información normalmente debe ser proporcionada por el usuario y tiene que ver con cuatro tipos:
Información sobre el significado de los datos Información sobre las aplicaciones que los usan Información acerca de la red de comunicaciones Información acerca de los sistemas de cómputo
1.4.1 Tipos de fragmentación de datos
Existen tres tipos de fragmentación:
Fragmentación horizontal
Fragmentación vertical
Fragmentación híbrida
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
En las siguientes secciones revisaremos de manera informal cada uno de los tipos mencionados. Más adelante, se presentará de manera más formal la construcción de los diferentes tipos de fragmentación. 1.4.2 Fragmentación horizontal primaria
Consiste del particionamiento en tuplas de una relación global en subconjuntos, donde cada subconjunto puede contener datos que tienen propiedades comunes y se puede definir expresando cada fragmento como una operación de selección sobre la relación global. Ejemplo 3. Considere la relación global SUPPLIER (SNUM, NAME, CITY) entonces, la fragmentación horizontal puede ser definida como: SUPPLIER1 = SLcity == "SF"SUPPLIER SUPPLIER1 = SLcity == "LA"SUPPLIER Esta fragmentación satisface la condición de completes si "SF" y "LA" son solamente los únicos valores posibles del atributo CITY. 2. La condición de reconstrucción se logra con: SUPPLIER = SUPPLIER1 unión SUPPLIER2 3. La condición de disjuntos se cumple claramente en este ejemplo. 1.4.3 Fragmentación horizontal derivada
La fragmentación derivada horizontal se define partiendo de una fragmentación horizontal. En esta operación se requiere de Semi-junta (Semi-Join) el cual nos sirve para derivar las tuplas o registros de dos relaciones. Ejemplo 4. Las siguientes relaciones definen una fragmentación horizontal derivada de la relación SUPPLY. SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1 SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
1.4.4 Fragmentación vertical
La fragmentación vertical es la subdivisión de atributos en grupos. Los fragmentos se obtienen proyectando la relación global sobre cada grupo. La fragmentación es correcta si cada atributo se mapea en al menos un atributo del fragmento. Ejemplo 5. Considere la siguiente relación global: EMP( empnum, name, sal, tax, mgrnum, depnum ) una fragmentación vertical de esta relación puede ser definida como: EMP1 = PJempnum, name, mgrnum, depnum EMP EMP2 = PJempnum, sal, tax EMP La reconstrucción de la relación EMP puede ser obtenida como: EMP = EMP1 (JN empnum) EMP2 porque empnum es una clave de EMP 1.4.5 Fragmentación híbrida
En lo que respecta a la fragmentación híbrida, esta consiste en aplicar la fragmentación vertical seguida de la fragmentación horizontal o viceversa. Ejemplo 6. Considere la relación global EMP (empnum, name, sal, tax, mrgnum, depnum) Las siguientes son para obtener una fragmentación mixta, aplicando la vertical seguida de la horizontal: EMP1 = SL depnum <= 10 PJempnum, name, mgrnum, depnum EMP EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum EMP EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum EMP EMP4 = PJ empnum, name, sal, tax EMP La reconstrucción de la relación EMP es definida por la siguiente expresión: EMP = UN(EMP1, EMP2, EMP3)JNempnum = empnumPJempnum, sal, tax EMP4
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Finalmente, como otro ejemplo considere el siguiente esquema global EMP(EMPNUM, NAME, SAL, TAX, MGRNUM, DEPNUM) DEP(DEPNUM, NAME, AREA, MGRNUM) SUPPLIER(SNUM, NAME, CITY) SUPPLY(SNUM, PNUM, DEPNUM, QUAN) Después de aplicar una fragmentación mixta se obtiene el siguiente esquema fragmentado EMP1 = Sldepnum <= 10 PJempnum, name, mgrnum, depnum (EMP) EMP2 = SL 10 < depnum <= 20 PJempnum, name, mgrnum, depnum (EMP) EMP3 = SL depnum > 20 PJempnum, name, mgrnum, depnum (EMP) EMP4 = PJ empnum, name, sal, tax (EMP) DEP1 = SL depnum <= 10 (DEP) DEP2 = SL 10 < depnum <= 20 (DEP) DEP3 = SL depnum > 20 (DEP) SUPPLIER1 = SL city == "SF" (SUPPLIER) SUPPLIER2 = SL city == "LA" (SUPPLIER) SUPPLY1 = SUPPLYSJsnum == snumSUPPLIER1 SUPPLY2 = SUPPLYSJsnum == snumSUPPLIER2 1.5 Diseño de la Replica
La replicación de información es de utilidad para obtener un mejor rendimiento y para ofrecer un mayor grado de confiabilidad (tolerancia a fallas). Se entiende por Replicación, la administración de copias de fragmentos o tablas y de asegurar su actualización en los periodos de tiempo definidos por el administrador del sistema. La replicación se complica cuando es necesario hacer actualizaciones a las copias múltiples de un dato. Por tanto, respecto a la replicación, en la asignación de fragmentos se tienen tres estrategias:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
1 No soportar replicación. Cada fragmento reside en un solo sitio. 2 Soportar replicación completa. Cada fragmento en cada uno de los sitios. 3 Soportar replicación parcial. Cada fragmento en algunos de los sitios. Como regla general se debe considerar que la replicación de fragmentos es de utilidad cuando el número de consultas de solo lectura es (mucho) mayor que el número de consultas para actualizaciones. En la Tabla 1 se comparan la complejidad de implementar o tomar ventaja de las diferentes alternativas de replicación, respecto de los diferentes aspectos importantes en bases de datos distribuidas. Además de indicar en que sitios se desea guardar copia de la entidad o tabla, es necesario definir la frecuencia o periodo de actualización de la copia. En este sentido, podemos encontrar los siguientes tipos de réplica: 1 En tiempo real, es decir en el momento que un sitio actualiza un registro (inserción, modificación y borrado de registros), se envía una copia de la información a los sitios donde reside la copia. 2 Copia fuera de línea, esta opción permite que una vez registrada la transacción en el sitio donde ella se genera, pueda pasar un tiempo para actualizar las copias de la información almacenadas en otros lugares. Con estos dos tipos de replicación, es posible definir varios modelos de sistemas de replica: 1. Maestro - maestro, hace que una vez generada y registrada una transacción en un sitio del sistema, inmediatamente se actualicen las copias de la información que se guardan en los otros sitios. Este modelo, aumenta la opción de acceso a datos desde cualquier punto, aumentando la disponibilidad del sistema. El mayor problema de este modelo es que debe garantizarse canales de comunicación entre los nodos en todo momento, de tal manera que se asegure la copia de los fragmentos cuando la transacción se realice, de lo contrario el sistema cae en un estado de invalidez de información. 2. Maestro-copia. Este modelo permite que la actualización de los sitios pueda generarse en un periodo de tiempo T después de generarse una t transacción en un sitio del sistema. Este modelo asume que los datos de las copias pueden estar diferentes al registro original durante un periodo de tiempo, sin afectar los procesos del sistema. El modelo reduce costos de canal de comunicación, ya que este es requerido durante algunos periodos de tiempo, durante el cual se realizan las actualizaciones a las replicas del sistema.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
3. Maestro - bodega. Este modelo exige la determinación de un sitio, donde se guardarán las replicas de los datos. Una vez se realice una transacción en un sitio, inmediata o durante un periodo de tiempo, debe generarse la copia de la replica en la bodega de datos. Esto hace que las consultas a información que no se encuentre en el sitio, solo puede hacerse a la bodega de datos. Este modelo reduce los costos de canales de datos, pero debe asegurarse que el sitio de la bodega siempre se encuentre accesible.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Capitulo 2. Consultas Distribuidas
El procesamiento de consultas es de suma importancia en bases de datos centralizadas. Sin embargo, en BDD éste adquiere una relevancia mayor. El objetivo es convertir transacciones de usuario en instrucciones para manipulación de datos. No obstante, el orden en que se realizan las transacciones afecta grandemente la velocidad de respuesta del sistema. Así, el procesamiento de consultas presenta un problema de optimización en el cual se determina el orden en el cual se hace la menor cantidad de operaciones. En BDD se tiene que considerar el procesamiento local de una consulta junto con el costo de transmisión de información al lugar en donde se solicitó la consulta. 2.1. Objetivo del procesamiento de las consultas
En un sistema de base de datos es posible cambiar la estructura inicial, pero es algo que puede resultar muy costoso desde el punto de vista de tiempo y dinero. Por tanto, cuando se presenta una consulta al sistema, es necesario hallar el mejor método de encontrar la respuesta utilizando la estructura existente de la base de datos. Existe un gran número de estrategias posibles para procesar una consulta, especialmente si la estructura es compleja. No obstante, normalmente vale la pena que el sistema dedique una cantidad importante de tiempo en la selección de una buena estrategia. El coste de procesar una consulta normalmente está dominado por el acceso al disco. Pero, en un sistema distribuido es preciso tener en cuenta otros factores, como son:
El coste de transmisión de datos en la red. El beneficio potencial que supondría en la ejecución el que varias localidades procesaran en paralelo partes de la consulta.
La diferencia entre una buena estrategia y una mala, en términos del número de accesos a disco requeridos y el coste de transmisión de datos en la red, a menudo es importante, y puede tener varios órdenes de magnitud. Así pues, el tiempo empleado en elegir una estrategia de procesamiento de consultas merece la pena incluso para una consulta que se ejecuta sólo una vez. 2.2. Niveles de procesador de consultas
Existen varios medios para calcular la respuesta a una consulta; siempre debe elegirse una estrategia de procesamiento de consultas que reduzca al mínimo el tiempo que se requiere para calcular la respuesta. En el caso de sistemas centralizados, el criterio principal para determinar el coste de una estrategia específica es el número de accesos al disco. En un sistema distribuido es preciso tener en cuenta otros factores, como son:
El coste de transmisión de datos en la red.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
El beneficio potencial que supondría en la ejecución el que varias localidades procesaran en paralelo partes de la consulta.
El coste relativo de la transferencia de datos en la red y la transferencia de datos entre la memoria y el disco varía en forma considerable, dependiendo del tipo de red y de la velocidad de los discos. Por tanto, en un caso general, no podemos tener en cuenta sólo los costes del disco o los de la red. Es necesario llegar a un equilibrio adecuado entre los dos. 2.3. Localización de datos
Consideremos una consulta muy sencilla: “Encontrar todas las tuplas de la relación depósito ”. Aunque la consulta es muy simple, de hecho es trivial; su procesamiento no es trivial, ya que es posible que la relación depósito esté fragmentada, repetida o las dos cosas. Si la relación depósito está repetida, es preciso decidir que copia se va a utilizar. Si ninguna de las copias está fragmentada, se elige la copia que implique costes de transmisión más reducidos. Pero si una copia está fragmentada, la elección no es tan sencilla, ya que es preciso calcular varios productos o uniones para reconstruir la relación depósito . En tal caso, el número de estrategias para este ejemplo sencillo puede ser grande. De hecho, la elección de una estrategia puede ser una tarea tan compleja como hacer una consulta arbitraria. La transparencia de la fragmentación implica que el usuario puede escribir una consulta como ésta: Nombre-sucursal
= “Riverside” (depósito)
Puesto que depósito está definido como depósito1
depósito2
La expresión que resulta del esquema de traducción de nombres es Nombre-sucursal
= “Riverside” (depósito1
depósito2)
Al emplear las técnicas de optimización podemos simplificar de manera automática esta expresión. La expresión que resulta es Nombre-sucursal
= “Riverside” (depósito1)
Nombre-sucursal
= “Riverside” (depósito2)
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
La cual incluye dos subexpresiones. La primera incluye sólo depósito1 y, por tanto, puede ser calculada en la localidad de Riverside. La segunda incluye solamente depósito2 y, por tanto, puede ser calculada en la localidad de Columbia. Existe aún una optimización que se puede hacer así: Nombre-sucursal
= “Riverside” (depósito1)
Puesto que depósito1 tiene solamente tuplas de pertenecientes a la sucursal Riverside, podemos eliminar la operación de selección. Calculando Nombre-sucursal
= “Riverside” (depósito2)
Podemos aplicar la definición del fragmento depósito2 para obtener Nombre-sucursal
= “Riverside” (
Nombre-sucursal
= “Columbia” (depósito))
Esta expresión es el conjunto vacío, independientemente del contenido de la relación depósito . Así, nuestra estrategia final para la localidad Riverside consistirá en devolver depósito1 como resultado de la consulta. 2.4 Procesamiento de intersección simple
Un aspecto importante de la elección de una estrategia de procesamiento de consulta es elegir una estrategia de intersección. Considere la expresión algebraica relacional: Cliente |x| depósito |x| sucursal
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Suponemos que ninguna de las tres relaciones esté repetida o fragmentada y que cliente está almacenada en la localidad Lc, depósito en la Ld y sucursal en la Lb. Sea Li la localidad donde se originó la consulta. El sistema debe producir el resultado en la localidad Li. Entre las posibles estrategias para procesar posibles estrategias para procesar esta consulta se encuentran en las siguientes: Enviar copia de las tres relaciones a la localidad Li. Escoger una estrategia para procesar en forma local la consulta completa en Li. Enviar una copia de la relación cliente a la localidad L d y calcular cliente |x| depósito de Ld . Enviar cliente |x| depósito de Ld a Lb, donde se calcula (cliente |x| deposito) |x| sucursal. El resultado de esta operación es enviado a Li. Pueden elaborarse estrategias similares a la anterior al intercambiar los papeles de Lc, Ld y Lb. No puede garantizarse que una estrategia sea la mejor en todos los casos. Entre los factores que deben tener en cuenta están la cantidad de datos que debe transmitirse, el costo de transmitir un bloque de datos entre dos localidades determinadas y la velocidad de procesamiento relativa en cada localidad. Considerar las dos primeras estrategias mencionadas. Si se envían las tres relaciones a Li y existen índices para ellas, puede ser necesario volver a crear esos índices en Li. Esto requiere tiempo extra de procesamiento y más accesos al disco. Sin embargo, la segunda estrategia tiene la desventaja de que una relación potencialmente grande (cliente |x| deposito) debe transmitirse desde Ld a Lb. Esta relación repite los datos del domicilio de un cliente una vez por cada cuenta que tenga el cliente. Así, la segunda estrategia puede requerir la transmisión de un volumen mayor que la primera estrategia.
También pueden utilizarse dos estrategias adicionales, la de intersección utilizando el paralelismo y la estrategia de semi-intersección.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
2.5. Descomposición de una consulta y localización de datos distribuidos
Antes de que pueda iniciarse el procesamiento de una consulta, el sistema debe traducir la consulta a una forma que pueda manejar. Los lenguajes como el SQL son adecuados a las personas, pero no para ser la representación interna de una consulta dentro del sistema. Una representación interna más útil es la que se basa en el álgebra relacional. La primera acción que el sistema debe tomar en una consulta es traducirla a su forma interna. Este proceso de traducción es similar al trabajo realizado por el analizador sintáctico (parser ) de un compilador. Al generar la forma interna de la consulta, el parser revisa la sintaxis de la consulta del usuario, verifica que los nombres de relaciones que aparecen en la consulta sean nombres de relaciones de base de datos, y así sucesivamente. Si la consulta se expresó en términos de una vista, el parser sustituye todas las eferencias al nombre de la vista por la expresión del álgebra relacional para calcular esa vista. Una vez que se ha traducido la consulta a una forma interna del álgebra, empieza el proceso de optimización. La primera fase de la optimización se lleva a cabo en el nivel del álgebra relacional. Se hace un intento para encontrar una expresión que sea equivalente a la expresión dada, pero que pueda ejecutarse de manera eficiente. La siguiente fase implica la selección de una estrategia detallada para procesar la consulta. Debe tomarse una decisión acerca de la manera exacta en que se va a ejecutar la consulta. Se deben elegir los índices específicos que se van a usar. Se debe determinar el orden en que se van a procesar las tuplas. La elección final de una estrategia se basa principalmente en el número de accesos a disco que se requieran. 2.6. Plan de optimización de consultas distribuidas
Dada una consulta, generalmente existe una variedad de métodos para calcular la respuesta. Cada forma de expresar la consulta “sugiere” una estrategia para encontrar la respuesta. Sin embargo, no esperamos que los usuarios escriban sus consultas de una forma que sugiera la estrategia más eficiente. Así pues, el sistema debe encargarse de transformar la consulta como la introdujo el usuario en una consulta equivalente que pueda calcularse de manera más eficiente. Esta “optimización”, o más exactamente, mejora de la estrategia para procesar una consulta se llama optimización de consultas . Existe una analogía entre la optimización de consultas por un sistema de base de datos. La optimización de consultas es una cuestión importante en cualquier sistema de base de datos puesto que la diferencia en tiempo de ejecución entre una buena estrategia y una mala puede ser enorme. En el modelo de red y en el modelo jerárquico la optimización de consultas se deja en su mayor parte al programador
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
de aplicaciones. Esto se debe a que las sentencias de los lenguajes de manipulación de datos de estos dos modelos normalmente se incorporan en un lenguaje de programación principal, y no es fácil transformar una consulta de red o jerárquica en una equivalente sin conocimiento del programa de aplicación completo. Ya que una consulta relacional puede expresarse completamente en un lenguaje de consulta relacional sin emplear un lenguaje principal, es posible realizar automáticamente una cantidad importante de optimización de consultas. Algunos sistemas reducen el número de estrategias que necesitan ser completamente consideradas haciendo una suposición heurística de una estrategia buena. Según esto, el optimizador considera cada una de las posibles estrategias, pero acaba tan pronto como determine que el coste es mayor que la mejor de las estrategias consideradas anteriormente. Si el optimizador empieza con una estrategia que es probable que tenga un coste bajo, sólo unas pocas estrategias competentes requerirán un análisis completo del coste. Esto puede reducir el tiempo de optimización de consultas. Para simplificar la tarea de selección de estrategias se debe dividir una consulta en varias subconsultas. Esto no sólo simplifica la selección de estrategias sino que también permite al optimizador de consultas reconocer los casos en los que una subconsulta determinada aparezca varias veces en la misma consulta. Si esas subconsultas se calculan una sola vez, se ahorra tiempo tanto en la fase de optimización de la consulta como en la ejecución de la consulta. El reconocimiento de subconsultas comunes es análogo al reconocimiento de subexpresiones comunes en muchos compiladores optimizadores de lenguajes de programación. Es obvio que examinar la consulta buscando subconsultas comunes y estimar el coste de un gran número de estrategias supone un tiempo extra considerable en el procesamiento de consultas. Sin embargo, el coste adicional de optimización de consultas generalmente se compensa con creces por el ahorro en el tiempo de ejecución de la consulta. El ahorro logrado es aún mayor en aquellas aplicaciones que se ejecutan sobre una base regular y vuelven a ejecutar las mismas consultas en cada ejecución. Por tanto, la mayor parte de los sistemas comerciales incluyen optimizadores relativamente sofisticados.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
CAPITULO 3. Transacciones Distribuidas
Hasta este momento, las primitivas básicas de acceso que se han considerado son las consultas (queries). Sin embargo, no se ha discutido qué pasa cuando, por ejemplo, dos consultas tratan de actualizar el mismo elemento de datos, o si ocurre una falla del sistema durante la ejecución de una consulta. Dada la naturaleza de una consulta, de lectura o actualización, a veces no se puede simplemente reactivar la ejecución de una consulta, puesto que algunos datos pueden haber sido modificados antes la falla. El no tomar en cuenta esos factores puede conducir a que la información en la base de datos contenga datos incorrectos. El concepto fundamental aquí es la noción de "ejecución consistente" o "procesamiento confiable" asociada con el concepto de una consulta. El concepto de una transacción es usado dentro del dominio de la base de datos como una unidad básica de cómputo consistente y confiable. 3.1 Definición de una transacción
Una transacción es una colección de acciones que hacen transformaciones consistentes de los estados de un sistema preservando la consistencia del sistema. Una base de datos está en un estado consistente si obedece todas las restricciones de integridad definidas sobre ella. Los cambios de estado ocurren debido a actualizaciones, inserciones, y supresiones de información. Por supuesto, se quiere asegurar que la base de datos nunca entra en un estado de inconsistencia. Sin embargo, durante la ejecución de una transacción, la base de datos puede estar temporalmente en un estado inconsistente. El punto importante aquí es asegurar que la base de datos regresa a un estado consistente al fin de la ejecución de una transacción (Ver Figura 3.1) Lo que se persigue con el manejo de transacciones es por un lado tener una transparencia adecuada de las acciones concurrentes a una base de datos y por otro lado tener una transparencia adecuada en el manejo de las fallas que se pueden presentar en una base de datos.
Figura 24. Un modelo de transacción. Ejemplo 3.1. Considere la siguiente consulta en SQL para incrementar el 10% del presupuesto del proyecto CAD/CAM de la base de datos de ejemplo.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
UPDATE J SET BUDGET = BUDGET*1.1 WHERE JNAME = "CAD/CAM"
Esta consulta puede ser especificada, usando la notación de SQL, como una transacción otorgándole un nombre: Begin_transaction ACTUALIZA_PRESUPUESTO begin UPDATE J SET BUDGET = BUDGET*1.1 WHERE JNAME = "CAD/CAM" end. ♦
Ejemplo 3.2. Considere una agencia de reservaciones para líneas aéreas con las siguientes relaciones:
FLIGHT( FNO, DATE, SRC, DEST, STSOLD, CAP ) CUST( CNAME, ADDR, BAL ) FC( FNO, DATE, CNAME, SPECIAL ) Una versión simplificada de una reservación típica puede ser implementada mediante la siguiente transacción: Begin_transaction Reservación begin input( flight_no, date, customer_name ); EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date EXEC SQL INSERT INTO FC( FNAME, DATE, CNAME, SPECIAL ) VALUES (flight_no, date, customer_name, null ) output("reservación terminada"); end. 3.2 Condiciones de terminación de una transacción
Una transacción siempre termina, aun en la presencia de fallas. Si una transacción termina de manera exitosa se dice que la transacción hace un commit (se usará el término en inglés cuando no exista un término en español que refleje con brevedad el sentido del término en inglés). Si la transacción se detiene sin terminar su tarea, se dice que la transacción aborta . Cuando la transacción es abortada, su ejecución es detenida y todas sus acciones ejecutadas hasta el
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
momento son deshechas (undone ) regresando a la base de datos al estado antes de su ejecución. A esta operación también se le conoce como rollback . Ejemplo 3.3. Considerando de nuevo el Ejemplo 3.2, veamos el caso cuando no existen asientos disponibles para hacer la reservación. Begin_transaction Reservación begin input( flight_no, date, customer_name ); INTO temp1, temp2 EXEC SQL SELECT STSOLD, CAP FROM FLIGHT WHERE FNO = flight_no AND DATE = date if temp1 = temp2 then output( "no hay asientos libres" ) Abort else EXEC SQL UPDATE FLIGHT SET STSOLD = STSOLD + 1 WHERE FNO = flight_no AND DATE = date EXEC SQL INSERT INTO FC( FNAME, DATE, CNAME, SPECIAL ) VALUES (flight_no, date, customer_name, null ) Commit output("reservación terminada"); endif end. 3.3 Caracterización de transacciones
Observe que en el ejemplo anterior las transacciones leen y escriben datos. Estas acciones se utilizan como base para caracterizar a las transacciones. Los elementos de datos que lee una transacción se dice que constituyen el conjunto de lectura (RS ). Similarmente, los elementos de datos que una transacción escribe se les denomina el conjunto de escritura (WS ). Note que los conjuntos de lectura y escritura no tienen que ser necesariamente disjuntos. La unión de ambos conjuntos se le conoce como el conjunto base de la transacción (BS = RS U WS ). Ejemplo 3.4. Los conjuntos de lectura y escritura de la transacción del Ejemplo 3.3 son: RS [Reservación] = { FLIGHT.STSOLD, FLIGHT.CAP } WS [Reservación] = { FLIGHT.STSOLD, FC.FNO, FC.DATE, FC.NAME,
FC.SPECIAL }
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
3.4 Formalización del concepto de transacción
Sea Oij (x ) una operación Oj de la transacción Ti la cual trabaja sobre alguna entidad x . Oj ∈ {read, write} y Oj es una operación atómica, esto es, se ejecuta como una unidad indivisible. Se denota por OSi = U j Oij al conjunto de todas las operaciones de la transacción Ti . También, se denota por Ni la condición de terminación para Ti , donde, Ni ∈ {abort, commit}. La transacción Ti es un orden parcial, Ti = { Σ i,
Para cualesquiera dos operaciones, Oij , Oik ∈ OSi , si Oij = R (x ) y Oik = W (x ) para cualquier elemento de datos x , entonces, ó Oij
La especificación de su transacción de acuerdo con la notación formal que se ha introducido es la siguiente: Συματορια = { R (x ), R (y ), W (x ), C }
Note que la relación de ordenamiento especifica el orden relativo de todas las operaciones con respecto a la condición de terminación. Esto se debe a la tercera condición de la definición de transacción. También note que no se define el ordenamiento entre cualquier par de operaciones, esto es, debido a que se ha definido un orden parcial. 3.5. Propiedades de las transacciones
La discusión en la sección previa clarifica el concepto de transacción. Sin embargo, aun no se ha dado ninguna justificación para afirmar que las transacciones son unidades de procesamiento consistentes y confiables. Las propiedades de una transacción son las siguientes: Atomicidad . Se refiere al hecho de que una transacción se trata como una unidad
de operación. Por lo tanto, o todas las acciones de la transacción se realizan o ninguna de ellas se lleva a cabo. La atomicidad requiere que si una transacción se interrumpe por una falla, sus resultados parciales deben ser deshechos. La actividad referente a preservar la atomicidad de transacciones en presencia de
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
abortos debido a errores de entrada, sobrecarga del sistema o ínter bloqueos se le llama recuperación de transacciones . La actividad de asegurar la atomicidad en presencia de caídas del sistema se le llama recuperación de caídas . Consistencia . La consistencia de una transacción es simplemente su correctitud.
En otras palabras, una transacción es un programa correcto que lleva la base de datos de un estado consistente a otro con la misma característica. Debido a esto, las transacciones no violan las restricciones de integridad de una base de datos. Aislamiento . Una transacción en ejecución no puede revelar sus resultados a otras transacciones concurrentes antes de su commit . Más aún, si varias transacciones se ejecutan concurrentemente, los resultados deben ser los mismos que si ellas se hubieran ejecutado de manera secuencial (seriabilidad).
Durabilidad . Es la propiedad de las transacciones que asegura que una vez que una transacción hace su commit , sus resultados son permanentes y no pueden
ser borrados de la base de datos. Por lo tanto, los DBMS aseguran que los resultados de una transacción sobrevivirán a fallas del sistema. Esta propiedad motiva el aspecto de recuperación de bases de datos , el cual trata sobre como recuperar la base de datos a un estado consistente en donde todas las acciones que han hecho un commit queden reflejadas. En resumen, las transacciones proporcionan una ejecución atómica y confiable en presencia de fallas, una ejecución correcta en presencia de accesos de usuario múltiples y un manejo correcto de réplicas (en el caso de que se soporten). 3.6. Tipos de Transacciones
Las transacciones pueden pertenecer a varias clases. Aun cuando los problemas fundamentales son los mismos para las diferentes clases, los algoritmos y técnicas que se usan para tratarlas pueden ser considerablemente diferentes. Las transacciones pueden ser agrupadas a lo largo de las siguientes dimensiones: Áreas de aplicación. En primer lugar, las transacciones se pueden ejecutar en aplicaciones no distribuidas. Las transacciones que operan en datos distribuidos se les conocen como transacciones distribuidas. Por otro lado, dado que los resultados de una transacción que realiza un commit son durables, la única forma de deshacer los efectos de una transacción con commit es mediante otra transacción. A este tipo de transacciones se les conoce como transacciones compensatorias . Finalmente, en ambientes heterogéneos se presentan transacciones heterogéneas sobre los datos. Tiempo de duración. Tomando en cuenta el tiempo que transcurre desde que se inicia una transacción hasta que se realiza un commit o se aborta, las transacciones pueden ser de tipo batch o en línea. Estas se pueden diferencias también como transacciones de corta y larga vida. Las transacciones en línea se caracterizan por tiempos de respuesta muy cortos y por accesar una porción relativamente pequeña de la base de datos. Por otro lado, las transacciones de
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
tipo batch toman tiempos relativamente largos y accesan grandes porciones de la base de datos. Estructura. Considerando la estructura que puede tener una transacción se examinan dos aspectos: si una transacción puede contener a su vez subtransacciones o el orden de las acciones de lectura y escritura dentro de una transacción. 3.7. Estructura de transacciones
Las transacciones planas consisten de una secuencia de operaciones primitivas encerradas entre las palabras clave begin y end. Por ejemplo, Begin_transaction Reservación ... end.
En las transacciones anidadas, las operaciones de una transacción pueden ser así mismo transacciones. Por ejemplo, Begin_transaction Reservación ... Begin_transaction Vuelo ... end. {Vuelo} ... Begin_transaction Hotel ... end. ... end.
Una transacción anidada dentro de otra transacción conserva las mismas propiedades que la de sus padres, esto implica, que puede contener así mismo transacciones dentro de ella. Existen restricciones obvias en una transacción anidada: debe empezar después que su padre y debe terminar antes que él. Más aún, el commit de una subtransacción es condicional al commit de su padre, en otras palabras, si el padre de una o varias transacciones aborta, las subtransacciones hijas también serán abortadas. Las transacciones anidadas proporcionan un nivel más alto de concurrencia entre transacciones. Ya que una transacción consiste de varias transacciones, es posible tener más concurrencia dentro de una sola transacción. Así también, es posible recuperarse de fallas de manera independiente de cada subtransacción. Esto limita el daño a un parte más pequeña de la transacción, haciendo que costo de la recuperación sea menor.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
En el segundo punto de vista se considera el orden de las lecturas y escrituras. Si las acciones de lectura y escritura pueden ser mezcladas sin ninguna restricción, entonces, a este tipo de transacciones se les conoce como generales . En contraste, si se restringe o impone que un dato deber ser leído antes de que pueda ser escrito entonces se tendrá transacciones restringidas . Si las transacciones son restringidas a que todas las acciones de lectura se realicen antes de las acciones de escritura entonces se les conoce como de dos pasos . Finalmente, existe un modelo de acción para transacciones restringidas en donde se aplica aún más la restricción de que cada par tiene que ser ejecutado de manera atómica. Ejemplo 3.6. Los siguientes son algunos ejemplos de los modelos de transacción mencionados antes.
General: T 1: { R (x ), R (y ), W (y ), R (z ), W (x ), W (z ), W (w ), C } Dos pasos: T 2: { R (x ), R (y ), R (z ), W (x ), W (y ), W (z ), W (w ), C } Restringida: T 3: { R (x ), R (y ), W (y ), R (z ), W (x ), W (z ), R (w ), W (w ), C } Restringida y de dos pasos: T 4: { R (x ), R (y ), R (z ), R (w ), W (y ), W (x ), W (z ), W (w ), C } Acción: T 3: { [R (x ), W (x )], [R (y ), W (y )], [R (z ), W (z )], [R (w ), W (w )], C } Note que cada par de acciones encerrado en [ ] se ejecuta de manera atómica 3.8. Aspectos relacionados al procesamiento de transacciones
Los siguientes son los aspectos más importantes relacionados con el procesamiento de transacciones: Modelo de estructura de transacciones. Es importante considerar si las transacciones son planas o pueden estar anidadas. Consistencia de la base de datos interna. Los algoritmos de control de datos semántico tienen que satisfacer siempre las restricciones de integridad cuando una transacción pretende hacer un commit. Protocolos de confiabilidad. En transacciones distribuidas es necesario introducir medios de comunicación entre los diferentes nodos de una red para garantizar la atomicidad y durabilidad de las transacciones. Así también, se requieren protocolos para la recuperación local y para efectuar los compromisos (commit) globales. Algoritmos de control de concurrencia. Los algoritmos de control de concurrencia deben sincronizar la ejecución de transacciones concurrentes bajo el criterio de correctitud. La consistencia entre transacciones se garantiza mediante el aislamiento de las mismas.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Protocolos de control de réplicas. El control de réplicas se refiere a cómo garantizar la consistencia mutua de datos replicados. Por ejemplo se puede seguir la estrategia read-one-write-all (ROWA). 3.9. Incorporación del manejador de transacciones a la arquitectura de un SMBD
El monitor de ejecución distribuida consiste de dos módulos: El administrador de transacciones (TM) y el despachador (SC). Como se puede apreciar en la Figura 25, el administrador de transacciones es responsable de coordinar la ejecución en la base de datos de las operaciones que realiza una aplicación. El despachador, por otra parte, es responsable de implementar un algoritmo específico de control de concurrencia para sincronizar los accesos a la base de datos. Un tercer componente que participa en el manejo de transacciones distribuidas es el administrador de recuperación local cuya función es implementar procedimientos locales que le permitan a una base de datos local recuperarse a un estado consistente después de una falla.
Figura 25. Un modelo del administrador de transacciones.
Los administradores de transacciones implementan una interfaz para los programas de aplicación que consiste de los comandos: Begin_transaction. Read. Write. Commit. Abort.
En la Figura 26 se presenta la arquitectura requerida para la ejecución centralizada de transacciones. Las modificaciones requeridas en la arquitectura
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
para una ejecución distribuida se pueden apreciar en las Figura 26b. En esta última figura se presentan también los protocolos de comunicación necesarios para el manejo de transacciones distribuidas .
Figura 26. Ejecución centralizada de transacciones.
Figura 26b. Ejecución distribuida de transacciones. 3.10 Recuperación En Sistemas Distribuidos
Una transacción debe ejecutarse en forma atómica. Es decir, se ejecutan completamente todas las instrucciones de la transacción, o no se ejecuta ninguna.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Además, en el caso de ejecución concurrente, el efecto de ejecutar una transacción debe ser el mismo que si se ejecutara sola en el sistema.
3.10.1 Estructura del sistema.
Cuando se tiene un sistema de base de datos distribuido, es mucho más difícil garantizar la propiedad de atomicidad de una transacción. Esto se debe a que es posible que participen varias localidades en la ejecución de una transacción. El fallo de una de estas localidades o el fallo de la línea de comunicación entre ellas, puede dar como resultado un cálculo erróneo. La función del gestor de transacciones de un sistema de base de datos distribuidos es asegurar que la ejecución de las distintas transacciones. Los distintos gestores de transacciones cooperan para ejecutar las transacciones globales. Para comprender cómo puede estructurarse un gestor de este tipo, definiremos un modelo abstracto para un sistema de transacciones.
Gestor de transacciones, cuya función es gestionar la ejecución de aquellas transacciones (o subtransacciones) que accedan a datos almacenados en esa localidad. Observamos que da transacción puede ser bien una transacción local (es decir, que se ejecuta sólo en esa localidad), o parte de una transacción global (es decir, que se ejecuta en varias localidades). Coordinador de transacciones, cuya función es la de coordinar la ejecución de varias transacciones (tanto local como global) iniciadas en esa localidad.
La estructura de un gestor de transacciones es similar en muchos aspectos a la que se utiliza en el caso de un sistema centralizado. Cada gestor de transacciones se encarga de:
Mantener una bitácora para la recuperación. Participar en un esquema de control de concurrencia apropiado para coordinar la ejecución en paralelo de las transacciones que se ejecuten en esa localidad.
Como su nombre lo indica, un coordinador de transacciones se encarga de coordinar todas las transacciones que se inicien en esa localidad. Para cada una de estas transacciones, el coordinador debe: Iniciar la ejecución de la transacción. Dividir la transacción en varias subtransacciones, las cuales ha de distribuir en las localidades apropiadas para su ejecución.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Coordinar la terminación de la transacción, ya sea que quede ejecutada o abordada en todas las localidades.
3.10.2 Robustez
Es una configuración distribuida es necesario prever otro tipo de fallos, como pueden ser:
El fallo total de una localidad. La interrupción de una línea de comunicación. Pérdida de mensajes. Fragmentación de la red.
Por tanto, para que el sistema sea robusto, es necesario que detecte cualquiera de estos fallos, que reconfigure el sistema de manera que pueda reanudarse el proceso y que se recupere una vez que haya sido reparado el procesador o la línea de comunicación afectados. En general, no es posible distinguir entre los fallos en las líneas de comunicación de la red y de las localidades. Por tanto, el esquema de reconfiguración que se adopte debe estar diseñado para que funcione correctamente aun cuando la red quede fragmentada.
Elección de dos o más distribuidores centrales en distintos fragmentos. Actualización de un dato repetido en más de un fragmento de la red.
También es necesario tener cuidado al reintegrar al sistema una localidad o línea de comunicación separada. Cuando una localidad que quedó fuera de servicio se recupera, debe iniciar un procedimiento de actualización de sus tablas de sistema para que reflejen los cambios que tuvieron lugar mientras estaba inactiva. Si la localidad tenía copias de datos, debe obtener los valores actuales de todos ellos y asegurarse de recibir las actualizaciones futuras. Esto es más complicado de lo que parece, ya que es posible que se actualicen los datos que se están procesando mientras que el sistema se recupera. Es necesario representar a las tareas de recuperación como una seria de transacciones. En este caso, el subsistema de control de concurrencia y el manejo de transacciones puede encargarse de realizar de manera fiable la reintegración de la localidad. Si se recupera una línea de comunicación interrumpida, es posible que se unan de nuevo dos fragmentos de la red. Dado que la fragmentación de una red limita las operaciones que pueden permitirse en algunas localidades, o en todas ellas, es conveniente enviar un mensaje a todas ellas informando sin delación que la línea se recuperó.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
3.11. Control De Concurrencia
El control de concurrencia trata con los problemas de aislamiento y consistencia del procesamiento de transacciones. El control de concurrencia distribuido de una DDBMS asegura que la consistencia de la base de datos se mantiene en un ambiente distribuido multiusuario. Si las transacciones son internamente consistentes, la manera más simple de lograr este objetivo es ejecutar cada transacción sola, una después de otra. Sin embargo, esto puede afectar grandemente el desempeño de un DDBMS dado que el nivel de concurrencia se reduce al mínimo. El nivel de concurrencia, el número de transacciones activas, es probablemente el parámetro más importante en sistemas distribuidos. Por lo tanto, los mecanismos de control de concurrencia buscan encontrar un balance entre el mantenimiento de la consistencia de la base de datos y el mantenimiento de un alto nivel de concurrencia. Si no se hace un adecuado control de concurrencia, se pueden presentar dos anomalías. En primer lugar, se pueden perder actualizaciones provocando que los efectos de algunas transacciones no se reflejen en la base de datos. En segundo término, pueden presentarse recuperaciones de información inconsistentes. En este capítulo se hace la suposición de que el sistema distribuido es completamente confiable y no experimente falla alguna. 3.11.1 Teoría de la seriabilidad
Una calendarización (schedule ), también llamado una historia , se define sobre un conjunto de transacciones T = { T 1, T 2, ..., Tn } y especifica un orden entrelazado de la ejecución de las operaciones de las transacciones. La calendarización puede ser especificada como un orden parcial sobre T . Ejemplo 1. Considere las siguientes tres transacciones: T 1: Read( x ) T 2: Write( x ) T 3: Read( x ) Write( x ) Write( y ) Read( y ) Commit Read( z ) Read( z ) Commit Commit Una calendarización de las acciones de
las tres transacciones anteriores puede ser: H 1 = { W 2(x ), R 1(x ), R 3(x ), W 1(x ), C 1, W 2(y ), R 3(y ), R 2(z ), C 2, R 3(z ), C 3 }
Dos operaciones 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 están en conflicto si al menos una de ellas es una escritura. De esta manera, las operaciones de lectura no tienen conflictos consigo mismas. Por tanto, existen dos tipos de conflictos read-write (o write-read ) y write-write . Las dos operaciones en conflicto pueden pertenecer a la misma transacción o a transacciones diferentes. En el último caso, se dice que las transacciones tienen conflicto . De manera intuitiva, la existencia de un conflicto
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
entre dos operaciones indica que su orden de ejecución es importante. El orden de dos operaciones de lectura es insignificante. Una calendarización completa define el orden de ejecución de todas las operaciones en su dominio. Formalmente, una calendarización completa STc definido sobre un conjunto de transacciones T = { T 1, T 2, ..., Tn } es un orden parcial STc = { Σ T ,
La primera condición establece simplemente que el dominio de la calendarización es la unión de los dominios de las transacciones individuales. La segunda condición define la relación de ordenamiento como un superconjunto de la relación de ordenamiento de transacciones individuales. Esto mantiene el ordenamiento de las operaciones dentro de cada transacción. La condición final define el orden de ejecución entre dos operaciones en conflicto. Ejemplo 2. Considere las tres transacciones del Ejemplo 1, una posible calendarización completa está dada por la siguiente gráfica dirigida acíclica (DAG).
Una calendarización se define como un prefijo de una calendarización completa. Un prefijo de un orden parcial se define como sigue. Dado un orden parcial P = { Συματορια , < }, P’ = { Συματορια ’, <’ }, es un prefijo de P si Σ’⊂Σi ∀ ei ∈ Σ ’, e 1 <’ e 2, si y solamente si, e 1 < e 2, y ∀ ei ∈ Σ ’, si ∃ ej ∈ Σ y ej < ei , entonces, ej Σ ’
Las primeras dos condiciones definen a P ’ como una restricción de P en el dominio Σ ’, en donde las relaciones de ordenamiento en P se mantienen por P ’. La última condición indica que para cualquier elemento de Σ ’, todos sus predecesores en Σ deben ser incluidos también en Σ ’. Ejemplo 3. La siguiente calendarización es un prefijo de la calendarización del Ejemplo 2.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Si en una calendarización S , las operaciones de varias transacciones no están entrelazadas, esto es, si las operaciones de una transacción ocurren de manera consecutiva, entonces se dice que la calendarización es serial . Si cada transacción es consistente (obedece las reglas de integridad), entonces la base de datos se garantiza ser consistente al final de la calendarización serial. La historia asociada a este tipo de calendarización se le conoce como serial. Ejemplo 4. La siguiente es una historia serial para el Ejemplo 1. HS = { W 2(x ), W 2(y ), R 2(z ), C 2, R 1(x ), W 1(x ), C 1, R 3(x ), R 3(y ), R 3(z ), C 3 }
Las transacciones se ejecutan de manera concurrente, pero el efecto neto de la historia resultante sobre la base de datos es equivalente a alguna historia serial . Basada en la relación de precedencia introducida por el orden parcial, es posible discutir la equivalencia de diferentes calendarizaciones con respecto a sus efectos sobre la base de datos. Dos calendarizaciones, S 1 y S 2, definidas sobre el mismo conjunto de transacciones T , se dice que son equivalentes si para cada par de operaciones en conflicto Oij y Okl (i ≠ k ), cada vez que Oij <1 Okl , entonces, Oij <2 Okl . A esta relación se le conoce como equivalencia de conflictos puesto que define la equivalencia de dos calendarizaciones en término del orden de ejecución relativo de las operaciones en conflicto en ellas. Una calendarización S se dice que es serializable , si y solamente si, es equivalente por conflictos a una calendarización serial. Ejemplo 5. Las siguientes calendarizaciones no son equivalentes por conflicto: HS = { W 2(x ), W 2(y ), R 2(z ), C 2, R 1(x ), W 1(x ), C 1, R 3(x ), R 3(y ), R 3(z ), C 3 } H 1 = { W 2(x ), R 1(x ), R 3(x ), W 1(x ), C 1, W 2(y ), R 3(y ), R 2(z ), C 2, R 3(z ), C 3 }
Las siguientes calendarizaciones son equivalentes por conflictos; por lo tanto H 2 es serializable: HS = { W 2(x ), W 2(y ), R 2(z ), C 2, R 1(x ), W 1(x ), C 1, R 3(x ), R 3(y ), R 3(z ), C 3 } H 2 = { W 2(x ), R 1(x ), W 1(x ), C 1, R 3(x ), W 2(y ), R 3(y ), R 2(z ), C 2, R 3(z ), C 3 }
La función primaria de un controlador de concurrencia es generar una calendarización serializable para la ejecución de todas las transacciones. El problema es, entonces, desarrollar algoritmos que garanticen que únicamente se generan calendarizaciones serializables.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
3.11.2 Seriabilidad en SMBD distribuidos
En bases de datos distribuidas es necesario considerar dos tipos de historia para poder generar calendarizaciones serializables: la calendarización de la ejecución de transacciones en un nodo conocido como calendarización local y la calendarización global de las transacciones en el sistema. Para que las transacciones globales sean serializables se deben satisfacer las siguientes condiciones:
cada historia local debe ser serializable, y dos operaciones en conflicto deben estar en el mismo orden relativo en todas las historias locales donde las operaciones aparecen juntas.
La segunda condición simplemente asegura que el orden de serialización sea el mismo en todos los nodos en donde las transacciones en conflicto se ejecutan juntas. Ejemplo 6. Considere las siguientes tres transacciones: T 1: Read( x ) T 2: Read( x ) x ← x + 5 x ← x * 5 Write( x ) Write( x ) Commit
Commit Las siguientes historias locales son individualmente serializables (de hecho son seriales), pero las dos transacciones no son globalmente serializables. LH 1 = { R 1(x ), W 1(x ), C 1, R 2(x ), W 2(x ), C 2 } LH 2 = { R 2(x ), W 2(x ), C 2, R 1(x ), W 1(x ), C 1 }
3.11.3. Taxonomía de los mecanismos de control de concurrencia
El criterio de clasificación más común de los algoritmos de control de concurrencia es el tipo de primitiva de sincronización. Esto resulta en dos clases: aquellos algoritmos que están basados en acceso mutuamente exclusivo a datos compartidos (candados) y aquellos que intentar ordenar la ejecución de las transacciones de acuerdo a un conjunto de reglas (protocolos). Sin embargo, esas primitivas se pueden usar en algoritmos con dos puntos de vista diferentes: el punto de vista pesimista que considera que muchas transacciones tienen conflictos con otras, o el punto de vista optimista que supone que no se presentan muchos conflictos entre transacciones. Los algoritmos pesimistas sincronizan la ejecución concurrente de las transacciones en su etapa inicial de su ciclo de ejecución. Los algoritmos optimistas retrasan la sincronización de las transacciones hasta su terminación. El grupo de algoritmos pesimistas consiste de algoritmos basados en candados , algoritmos basados en ordenamiento por estampas de tiempo y algoritmos híbridos . El grupo de los algoritmos optimistas se clasifican por basados en candados y basados en estampas de tiempo (Ver. Figura 27).
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 27. Clasificación de los algoritmos de control de concurrencia . 3.11.4 Algoritmos basados en candados
En los algoritmos basados en candados, las transacciones indican sus intenciones solicitando candados al despachador (llamado el administrador de candados ). Los candados son de lectura (rl ), también llamados compartidos , o de escritura ( wl ), también llamados exclusivos . Como se aprecia en la tabla siguiente, los candados de lectura presentan conflictos con los candados de escritura, dado que las operaciones de lectura y escritura son incompatibles. rl wl rl si no wl no no En sistemas basados en candados, el despachador es un administrador de candados (LM). El administrador de transacciones le pasa al
administrador de candados la operación sobre la base de datos (lectura o escritura) e información asociada, como por ejemplo el elemento de datos que es accesado y el identificador de la transacción que está enviando la operación a la base de datos. El administrador de candados verifica si el elemento de datos que se quiere accesar ya ha sido bloqueado por un candado. Si candado solicitado es incompatible con el candado con que el dato está bloqueado, entonces, la transacción solicitante es retrasada. De otra forma, el candado se define sobre el dato en el modo deseado y la operación a la base de datos es transferida al procesador de datos. El administrador de transacciones es informado luego sobre el resultado de la operación. La terminación de una transacción libera todos los candados y se puede iniciar otra transacción que estaba esperando el acceso al mismo dato.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
3..11.4.1Candados de dos fases (2PL)
En los candados de dos fases una transacción le pone un candado a un objeto antes de usarlo. Cuando un objeto es bloqueado con un candado por otra transacción, la transacción solicitante debe esperar. Cuando una transacción libera un candado, ya no puede solicitar más candados. Así una transacción que utiliza candados de dos fases se comporta como en la Figura 28. En la primera fase solicita y adquiere todos los candados sobre los elementos que va a utilizar y en la segunda fase libera los candados obtenidos uno por uno. La importancia de los candados de dos fases es que se ha demostrado de manera teórica que todos las calendarizaciones generadas por algoritmos de control de concurrencia que obedecen a los candados de dos fases son serializables. Puede suceder que si una transacción aborta después de liberar un candado, otras transacciones que hayan accesado el mismo elemento de datos aborten también provocando lo que se conoce como abortos en cascada . Para evitar lo anterior, los despachadores para candados de dos fases implementan lo que se conoce como los candados estrictos de dos fases en los cuales se liberan todos los candados juntos cuando la transacción termina (con commit o aborta). El comportamiento anterior se muestra en la Figura 29.
Figura 28. Gráfica del uso de los candados de dos fases.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 29. Comportamiento de los candados de dos fases estrictos. 3.11.4.2 Candados de dos fases centralizados
En sistemas distribuidos puede que la administración de los candados se dedique a un solo nodo del sistema, por lo tanto, se tiene un despachador central el cual recibe todas las solicitudes de candados del sistema. En la Figura 30 se presenta la estructura de la comunicación de un administrador centralizado de candados de dos fases. La comunicación se presenta entre el administrador de transacciones del nodo en donde se origina la transacción (llamado el coordinador TM), el administrador de candados en el nodo central y los procesadores de datos (DP) de todos los nodos participantes. Los nodos participantes son todos aquellos en donde la operación se va a llevar a cabo.
Figura 30. Comunicación en un administrador centralizado de candados de dos fases estrictos.
La crítica más fuerte a los algoritmos centralizados es el "cuello de botella" que se forma alrededor del nodo central reduciendo los tiempos de respuesta de todo el sistema. Más aún, su disponibilidad es reducida a cero cuando se presentan fallas en el nodo central.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
3.11.4.3 Candados de dos fases distribuidos
En los candados de dos fases distribuidos se presentan despachadores en cada nodo del sistema. Cada despachador maneja las solicitudes de candados para los datos en ese nodo. Una transacción puede leer cualquiera de las copias replicada del elemento x , obteniendo un candado de lectura en cualquiera de las copias de x . La escritura sobre x requiere que se obtengan candados para todas las copias de x . La comunicación entre los nodos que cooperan para ejecutar una transacción de acuerdo al protocolo de candados distribuidos de dos fases se presenta en la Figura 31. Los mensajes de solicitud de candados se envían a todos los administradores de candados que participan en el sistema. Las operaciones son pasadas a los procesadores de datos por los administradores de candados. Los procesadores de datos envía su mensaje de "fin de operación" al administrador de transacciones coordinador. 3.11.5 Algoritmos basados en estampas de tiempo
A diferencia de los algoritmos basados en candados, los algoritmos basados en estampas de tiempo no pretenden mantener la seriabilidad por exclusión mutua. En lugar de eso, ellos seleccionan un orden de serialización a priori y ejecutan las transacciones de acuerdo a ellas. Para establecer este ordenamiento, el administrador de transacciones le asigna a cada transacción Ti una estampa de tiempo única ts ( Ti ) cuando ésta inicia. Una estampa de tiempo es un identificador simple que sirve para identificar cada transacción de manera única. Otra propiedad de las estampas de tiempo es la monoticidad , esto es, dos estampas de tiempo generadas por el mismo administrador de transacciones deben ser monotonicamente crecientes. Así, las estampas de tiempo son valores derivados de un dominio totalmente ordenado.
Figura 31. Comunicación en candados de dos fases distribuidos.
Existen varias formas en que las estampas de tiempo se pueden asignar. Un método es usar un contador global monotónicamente creciente. Sin embargo, el mantenimiento de contadores globales es un problema en sistemas distribuidos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Por lo tanto, es preferible que cada nodo asigne de manera autónoma las estampas de tiempos basándose en un contador local. Para obtener la unicidad, cada nodo le agrega al contador su propio identificador. Así, la estampa de tiempo es un par de la forma: Note que el identificador de nodo se agrega en la posición menos significativa, de manera que, éste sirve solo en el caso en que dos nodos diferentes le asignen el mismo contador local a dos transacciones diferentes. El administrador de transacciones asigna también una estampa de tiempo a todas las operaciones solicitadas por una transacción. Más aún, a cada elemento de datos x se le asigna una estampa de tiempo de escritura , wts (x ), y una estampa de tiempo de lectura , rts( x); sus valores indican la estampa de tiempo más grande para cualquier lectura y escritura de x , respectivamente. El ordenamiento de estampas de tiempo (TO) se realiza mediante la siguiente regla: Regla TO: dadas dos operaciones en conflicto, Oij y Okl , perteneciendo a las transacciones Ti y Tk , respectivamente, Oij es ejecutada antes de Okl , si y solamente si, ts (Ti ) < ts (Tk ). En este caso Ti se dice ser una transacción más vieja y Tk se dice ser una transacción más joven .
Dado este orden, un conflicto entre operaciones se puede resolver de la siguiente forma: for Ri (x ) do begin if ts (Ti ) < wts ( x ) then reject Ri (x ) else accept Ri (x ) rts (x ) ← ts (Ti ) endfor Wi (x ) do begin if ts (Ti ) < rts (x ) and ts (Ti ) < wts (x ) then reject Wi (x ) else accept Wi (x ) wts (x ) ← ts (Ti ) end. La acción de rechazar una operación,
significa que la transacción que la envió necesita reiniciarse para obtener la estampa de tiempo más reciente del dato e intentar hacer nuevamente la operación sobre el dato. 3.11.5.1 Ordenamiento conservador por estampas de tiempo
El ordenamiento básico por estampas de tiempo trata de ejecutar una operación tan pronto como se recibe una operación. Así, la ejecución de las operaciones es progresiva pero pueden presentar muchos reinicios de transacciones. El ordenamiento conservador de estampas de tiempo retrasa cada operación hasta que exista la seguridad de que no será reiniciada. La forma de asegurar lo anterior es sabiendo que ninguna otra operación con una estampa de tiempo menor puede llegar al despachador. Un problema que se puede presentar al retrasar las operaciones es que esto puede inducir la creación de ínter bloqueos ( deadlocks ).
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
3.11.5.2 Ordenamiento por estampas de tiempo múltiples
Para prevenir la formación de ínter bloqueos se puede seguir la estrategia siguiente. Al hacer una operación de escritura, no se modifican los valores actuales sino se crean nuevos valores. Así, puede haber copias múltiples de un dato. Para crear copias únicas se siguen las siguientes estrategias de acuerdo al tipo de operación de que se trate: Una operación de lectura Ri (x ) se traduce a una operación de lectura de x de una sola versión encontrando la versión de x , digamos xv , tal que, ts (xv ) es la estampa de tiempo más grande que tiene un valor menor a ts (Ti ). Una operación de escritura Wi (x ) se traduce en una sola versión, Wi (xw ), y es aceptada si el despachador no ha procesado cualquier lectura Rj (xr ), tal que, ts (Ti ) < ts (xr ) < ts (Tj ) 3.11.6 Control de concurrencia optimista
Los algoritmos de control de concurrencia discutidos antes son por naturaleza pesimistas. En otras palabras, ellos asumen que los conflictos entre transacciones son muy frecuentes y no permiten el acceso a un dato si existe una transacción conflictiva que accesa el mismo dato. Así, la ejecución de cualquier operación de una transacción sigue la secuencia de fases: validación (V), lectura (R), cómputo (C) y escritura (W) (ver Figura 6.6a). Los algoritmos optimistas, por otra parte, retrasan la fase de validación justo antes de la fase de escritura (ver Figura 32). De esta manera, una operación sometida a un despachador optimista nunca es retrasada. Las operaciones de lectura, cómputo y escrita de cada transacción se procesan libremente sin actualizar la base de datos corriente. Cada transacción inicialmente hace sus cambios en copias locales de los datos. La fase de validación consiste en verificar si esas actualizaciones conservan la consistencia de la base de datos. Si la respuesta es positiva, los cambios se hacen globales (escritos en la base de datos corriente). De otra manera, la transacción es abortada y tiene que reiniciar
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 32. Fases de la ejecución de una transacción a) pesimista, b) optimista.
Los mecanismos optimistas para control de concurrencia fueron propuestos originalmente con el uso de estampas de tiempo. Sin embargo, en este tipo de mecanismos las estampas de tiempo se asocian únicamente con las transacciones, no con los datos. Más aún, las estampas de tiempo no se asignan al inicio de una transacción sino justamente al inicio de su fase de validación. Esto se debe a que las estampas se requieren únicamente durante la fase de validación. Cada transacción Ti se subdivide en varias subtransacciones, cada una de las cuales se puede ejecutar en nodos diferentes. Sea Tij una subtransacción de Ti que se ejecuta en el nodo j . Supongamos que las transacciones se ejecutan de manera independiente y ellas alcanzan el fin de sus fases de lectura. A todas las subtransacciones se les asigna una estampa de tiempo al final de su fase de lectura. Durante la fase de validación se realiza una prueba de validación, si una transacción falla, todas las transacciones se rechazan. La prueba de validación se realiza con una de las siguientes reglas: Si todas las transacciones Tk , tales que, ts ( Tk ) < ts ( Tij ), han terminado su fase de escritura antes que Tij ha iniciado su fase de lectura entonces la validación tiene éxito. En este caso la ejecución de las transacciones es completamente serial como se muestra en la Figura 7a. Si existe alguna transacción Tk , tal que, ts ( Tk ) < ts ( Tij ) y la cual completa su fase de escritura mientras Tij está en su fase de lectura, entonces, la validación tiene éxito si WS (Tk ) ∩ RS (Tij ) = ∅ . En este caso, las fases de lectura y escritura se traslapan, como se muestra en la Figura 7b, pero Tij no lee datos que son escritos por Tk . Si existe alguna transacción Tk , tal que, ts ( Tk ) < ts ( Tij ) y la cual completa su fase de lectura antes que Tij termine su fase de lectura, entonces, la validación tiene éxito si WS (Tk ) ∩ RS (Tij ) = ∅ y WS (Tk ) ∩ WS (Tij ) = ∅ . En este caso, las fases de lectura se traslapan, como se muestra en la Figura 33, pero las transacciones no accesan datos comunes.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 33. Casos diferentes de las pruebas de validación para control de concurrencia optimista.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Capitulo 4. Catalogo 4.1. Conceptos básicos
Existe un elemento denominado Catálogo, que es imprescindible conocer si se quiere llegar a ser experto en el manejo de cualquier SGBD (Sistema de gestión de base de datos). El catálogo guarda la información del esquema de la base de datos y es gracias a él que se pueden compartir los esquemas de dominio, y definir las relaciones de integridad y de datos. Comprender la estructura del catálogo, debe de ser un objetivo de todo administrador y analista que quiera conocer el comportamiento de la base de datos. Para poder llegar a solucionar problemas de definición de datos, de rendimiento u optimización es necesario conocer las características del motor, la forma como se comporta en determinada plataforma e incluso sus deficiencias. En un sistema distribuido, el catálogo del sistema incluirá no solo los datos usuales del catálogo con relación a las varrels base, vistas, autorizaciones, etc., sino también toda la información de control necesaria para permitir que el sistema proporcione la independencia de ubicación, fragmentación y replicación necesaria. Surge entonces un interrogante ¿Dónde y cómo debe ser almacenado el propio catálogo?. A continuación se muestran las posibilidades: 4.2. Centralizado
El catálogo total es almacenado exactamente una vez en un sitio central. 4.3. Completamente replicado
El catálogo total es almacenado por completo en cada uno de los sitios. 4.4. Dividido
Cada sitio mantiene su propio catálogo de los objetivos que están almacenados en ese sitio. El catálogo total es la unión de todos los catálogos locales disjuntos. 4.5. Combinación de centralizado y dividido
Cada sitio mantiene su propio catálogo local, como en el punto 4.4; además, un único sitio central mantiene una copia unificada de todos esos catálogos locales, como en punto 4.2 Cada uno de los enfoques mencionados anteriormente, tiene sus propios problemas. El enfoque centralizado viola el objetivo de “no dependencia de un sitio central”. El enfoque completamente replicado sufre una pérdida de autonomía, ya
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
que cada actualización del catálogo tiene que ser propagada por cada uno de los sitios. El enfoque dividido eleva el costo de operaciones que no son locales. La combinación de centralizado y dividido es más eficiente que el dividido, pero viola nuevamente el objetivo de no dependencia de un sitio central, por lo tanto, en la práctica los sistemas no usan ninguno de los enfoque antes mencionados. A manera de ejemplo describimos el enfoque usado en R* (donde R* es un prototipo tomado como referencia). Para explicar la forma en que está estructurado el catálogo de R*, es necesario primero decir algo acerca del nombramiento de objetos en R*. Este nombramiento es importante para los sistemas distribuidos en general, ya que la posibilidad de que los sitios distintos X y Y, puedan tener un objeto, digamos una varrel llamada A, implica que sería necesario algún mecanismo – por lo general la calificación por nombre de sitio – para “eliminar la ambigüedad” (es decir, garantizar la unicidad de nombres a nivel de sistema). Por lo tanto, lo que se necesita es un medio para transformar los nombres conocidos por los usuarios a sus nombres correspondientes conocidos por el sistema. Este es el enfoque de R* para este problema. R* primero distingue entre el nombre común de un objeto, que es el nombre por el cual los usuarios hacen normalmente referencia al objeto ( por ejemplo una instrucción SELECT de SQL), y su nombre a nivel de sistema , que es identificador interno globalmente único para el objeto. Los nombres a nivel del sistema tienen cuatro componentes:
ID del creador (el ID del usuario que creó el objeto) ID del sitio del creador (el ID del sitio en el cual se dio la operación CREATE) Nombre local(el nombre del objeto sin calificativos) y ID del sitio de nacimiento (el ID del sitio en el cual se almacenó inicialmente el objeto).
Los IDs de usuario son únicos dentro del sito en el cual y los IDs del sitio son únicos a nivel global. Por lo tanto, el nombre a nivel de sistema de MARIO @ NEWAYORK . STATS LONDRES Denota un objeto, tal vez una varrel base, con el nombre local STATS, creada por el usuario Mario en el sitio Nueva York y almacenada inicialmente en el sitio Londres. Este garantizado que este nombre nunca cambiará, ni auque el objeto migre a otro sitio. Los usuarios se refieren normalmente a los objetos por su nombre común. Este nombre se usa sin calificativos, ya sea el componente “nombre local” del nombre a nivel sistema (STATS en el ejemplo anterior) o un sinónimo para ese nombre a nivel de sistema, definido por medio de la instrucción especial de SQL, R* CREATE SYNONYM. En el ejemplo en cuestión:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
CREATE SYNONYM MSTATS FOR MARIO NUEVAYORK. STATS @ LONDRES; Ahora el usuario puede decir (ejemplo) O
SELECT … FROM STATS…; SELECT … FROM MSTATS…;
En el primer caso (al usar el nombre local), el sistema infiere el nombre a nivel sistema suponiendo todos los valores predeterminados obvios; es decir que el objeto fue creado por este usuario, que fue creado en este sitio y que fue guardado inicialmente en este sitio. En el segundo caso (al usar el sinónimo), el sistema determina el nombre a nivel de sistema consultando la tabla sinónimos relevante. Las tablas del sinónimos pueden ser vistas como el primer componente del catálogo; cada sitio mantiene un conjunto de esas tablas para los usuarios que se sabe que están en ese sitio y transforma los sinónimos conocidos para ese usuario en los nombres a nivel de sistema correspondientes. Además en las tablas de sinónimos cada sitio mantiene: 1. Una entrada de catálogo para cada objeto nacido en este sitio; 2. Una entrada de catálogo para cada objeto almacenado actualmente en ese sitio. Supongamos que ahora el usuario emite una solicitud que hace referencia al sinónimo MSTATS. Primero, el sistema busca el nombre a nivel sistema correspondiente en la tabla de sinónimos adecuada (una simple búsqueda local), Ahora ya sabe el sitio de nacimiento(es decir Londres en el ejemplo) y puede consultar el catálogo de Londres (y se supone, de manera general, que será una búsqueda renota; el primer acceso remoto). El catálogo de Londres contendrá una entrada para ese objeto gracias al punto 1 anterior. Si el objeto está todavía en Londres ya habrá sido encontrado. Sin embargo, si el objeto ha emigrado (digamos) a Los Ángeles, entonces la entrada de catálogo en Londres lo dirá y por lo tanto, el sistema podrá ahora consultar al catálogo de Los Ángeles (segundo acceso remoto). Y el catálogo de los Ángeles contendrá una entrada para los objetos gracias al punto 2 anterior. Por lo tanto, ha sido encontrado en, como máximo, dos accesos remotos. Además, si el objeto emigra nuevamente, digamos a San Francisco, entonces el sistema: Insertará una entrada en el catálogo de San Francisco; Borrará la entrada del catálogo de los Ángeles; Actualizará la entrada del catálogo de Londres para que se apunte a San Francisco en lugar de Los Ángeles.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
El efecto neto es que el objeto todavía puede ser encontrado en dos accesos remotos, como máximo. Y este es un esquema completamente distribuido; no hay un sitio con catálogo central y no hay punto alguno de falla dentro del sistema.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
UNIDAD 3 OTROS MODELOS DE BASES DE DATOS Capítulo 1.
Bodega de datos
1.1 Introducción
Hoy en día se habla mucho del tema de Data Warehousing o Bodega de Datos, que permite la utilización de los datos de una Organización o un conjunto de ellas, como soporte en la toma de decisiones. Está información puede provenir de múltiples fuentes heterogéneas no sólo en ambiente de computación sino también en formato, ambiente de captura, significado, etc, información toda esta indispensable en su interpretación y correcta utilización y que es lo que se conoce como Metadatos. La función de una Bodega de Datos es la de entregar la información correcta a la gente indicada en el momento adecuado en el formato correcto. Cuántos tornillos se vendieron el año pasado en el último trimestre? Quien? En que Departamentos o ciudades? Cuanto fueron las ventas totales en este trimestre? Cuáles campañas de publicidad dieron el mejor resultado? Las ventas se incrementaron como resultado de las campañas de las últimas semanas? Cuáles son las características de un cliente típico? Cuáles han sido los valores históricos de la razón ácida, para un conjunto de compañías que conforman un pool? Cómo es la composición de las cuentas del presupuesto? Estas son las preguntas a las que la Bodega de Datos tiene respuestas. Sin embargo vale la pena aclarar que Bodega de Datos no es un proyecto de implementación de una herramienta de mercadeo. Es una forma de operar dentro de una organización. Inicia con el proceso de recolección, transformación y lanzamiento de los datos, que se conoce como el proceso de Scrubbing. Almacena los metadatos en lo que se conoce como repositorio y a partir de ahí permite que la información se analice y se presente en la forma que necesita el usuario. Los datos pueden ser extractados de grandes aplicaciones en Mainframe o de múltiples fuentes distribuidas, de ambiente C/S, en ambientes disímiles. Usualmente los datos son transformados (reformateados o agregados) antes de ser colocados en la Bodega de Datos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
La problemática de Bodega de Datos difiere de compañía en compañía. Una puede necesitar una Base de Datos centralizada, mientras que una organización distribuida a lo largo del país o del mundo puede necesitar de una gran Base de Datos distribuida. 1.2 Construcción y manejo de una bodega de datos
Si la organización tiene muchos datos de aplicaciones tradicionales y está buscando una solución para transferir grandes volúmenes de datos de un Mainframe, se necesita una solución de Bodega de Datos de fuerza industrial para hacer transferencia bruta de datos diferentes de fuentes en Mainframes a Bodegas de Datos en DB2 o en Unix. Se requiere de alguna herramienta para poblar y actualizar la Bodega de Datos que realice extracción de datos a altas velocidades y altos volúmenes de datos, traslade y distribuya de múltiples y diferentes Bases de Datos en Mainframes en la BODEGA y ojalá elimine la necesidad de escribir complejos programas y rutinas de conversión. Usualmente estas herramientas tienen habilidades gráficas y proveen de criterio de selección fácilmente puede llevar los datos al formato requerido en la Base de Datos. Por definición Bodega de Datos es una colección de datos actualizada, por lo tanto la herramienta utilizada debe completar las actualizaciones en el momento. Distribución de datos es el proceso de mover los datos extractados y trasladarlos a la Bodega de Datos o a diferentes Bases de Datos en cualquier plataforma en cualquier sitio. Una herramienta de distribución define Base de Datos Objetivo, información de conversión y entrada y salida de datos. Una vez creadas estas definiciones, pueden ser salvadas para ser reutilizadas, editadas o ejecutadas posteriormente. Algunas soluciones de Bodega de Datos requieren de enrutadores de datos o rutinas de sincronización mas sofisticadas a través de ambientes múltiples y heterogéneos. Este tipo de proceso puede necesitar un movimiento vi direccional entre las plataformas Mainframe y C/S para mantener actualizada y sincronizada la Base de Datos en todas las localidades.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
1.3 Manejo de los metadatos
El repositorio sirve como un sitio para almacenar los datos de los activos de información de una organización. Abarca todos los datos de la organización, sin importar cual es la fuente original y facilita el entendimiento de toda la empresa y controla la existencia de los recursos de datos existentes. El repositorio sirve como una guía para definir un ambiente de migración de datos. Contiene:
El mapeo entre las fuentes y/o la Bodega de Datos objetivo Requerimientos de traslado de la información Reglas de negocio Pista de auditoria
1.4 Acceso y análisis de datos .
Una vez que la Bodega de Datos se ha llenado de información, los usuarios finales están listos para acceder y analizar los datos. Para dar respuestas a las necesidades de usuarios finales en cualquier plataforma, se provee de algunas herramientas especializadas para hacer reportes y queries algunas muy sofisticadas, para desarrolladores de aplicaciones de oficina y usuarios poderosos que necesitan revisar datos sumarizados de la Bodega así como crecientes niveles de detalle. 1.5 Manejo de sistemas
La Base de Datos de la Bodega debe ser frecuentemente mantenida y manejada por DBA´s para reducir el impacto en el desempeño del sistema y recursos. Par ser eficiente y productivo, el proceso de Bodega de Datos debe ser automatizado dentro de un ambiente de producción. Las herramientas necesarias para su mantenimiento, se clasifican en: Herramientas de manejos de Base de Datos Sistemas para manejo de Procesos de Jobs Resolución de Problemas (Help Desk) Manejo de Almacenamiento y desempeño Seguridad Distribución.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
2. Construcción de la bodega de datos
Para abordar un proyecto de Bodega de Datos es necesario hacer el levantamiento de algunos temas generales de la Organización. Estos se agrupan en los siguientes tópicos: 2.1 Ambiente actual
Con el objetivo de recomendar el más apropiado curso de acción para construir y utilizar una Bodega de Datos, es crítico entender el negocio y el ambiente tecnológico actual de la Organización. Cualquier solución propuesta de Bodega de Datos debe estar muy orientada por las necesidades del negocio y debe ser compatible con la arquitectura técnica existente y planteada de la compañía. 2.2 Ambiente de Negocios.
Es indispensable tener el conocimiento exacto sobre el tipo de negocios de la Organización y el soporte que representa la información dentro de todo su proceso de toma de decisiones. 2.3 Ambiente técnico
Se debe tener un claro concepto desde una perspectiva técnica de los Sistemas de Información de la Organización. En este análisis se debe tener claridad del ambiente técnico actual y futuro a nivel de detalle. Se debe incluir tanto el aspecto de ambiente hardware: mainframes, servidores, redes., así como aplicativos y herramientas. Se dará gran foco a los Sistemas de soporte en la decisión, si existe en la actualidad, como operan, etc. 2.4 Expectativas de los usuarios
El punto es determinante en el éxito de un proyecto de Bodega de Datos puesto que no hay que perder de vista que Bodega de Datos no es un proyecto tecnológico, es una forma de Vida de las Organizaciones y como tal, tiene que contar con el apoyo de todos los usuarios y su convencimiento sobre su bondad. 3. Estrategias recomendadas para diseño de datos
La metodología recomendada es iniciar con un prototipo. 3.1 Prototipo: La meta del prototipo de Bodega de Datos es proveer a los usuarios finales con una aproximación de lo que la Bodega de Datos les puede proporcionar en un período de tiempo tan corto como sea posible tal que el grupo de Bodega de Datos pueda demostrar los beneficios de la Bodega de Datos a los usuarios y recolectar lo más pronto la retroalimentación crítica de los usuarios.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Las estructuras de Datos apropiadas pueden ser distribuidas herramientas de acceso de datos a usuarios finales y aplicaciones para realizar queries. Deben ser creadas herramientas de soporte en la Decisión si es aplicable. Sin embargo el proceso de integrar y transformar los datos de la Bodega de Datos no será completamente automatizado. En la mayoría de los casos el prototipo contemplará una cargada no repetible (de una sola vez) de los datos de las estructuras de las Bodegas de Datos. La plataforma y la Base de Datos para el almacenamiento puede también diferir de aquellas para la arquitectura definitiva de Bodega de Datos, lo que es importante también, es que la presentación de los Datos al usuario final sea tan fiel como sea posible para que sea igualmente presentada en posteriores etapas de la Bodega de Datos. 3.2 Piloto En la construcción de una Bodega de Datos, se debe observar especial cuidado porque es la primera fase del proyecto en el cual el equipo de Bodega de Datos utilizará los métodos, técnicas y herramientas que será la base para una Bodega de Datos completa. Por esta razón el proyecto piloto de Bodega de Datos debe tener un pequeño alcance y tiempo adicional comparativamente con los esfuerzos sucesivos de Bodega de Datos. 3.3 Prueba del concepto tecnológico
La prueba del concepto tecnológico es un paso opcional que se puede necesitar para definir si la arquitectura especificada para la Bodega de Datos funcionará finalmente como se intenta. En la mayoría de proyectos de Bodega de Datos el esfuerzo del piloto ha servido también como la prueba del concepto para la arquitectura técnica. Es crítico que la prueba del concepto tecnológico no esté cercana al prototipo, dado que la meta del prototipo es poner datos en las manos de los usuarios tan pronto como sea posible. 3.4 Arquitectura de la Bodega de Datos. Datos de los sistemas de Aplicación y de otras fuentes de Bodegas de Datos deben ser periódicamente extraídos y alimentados en la capa de Data Scrubbing. La extracción debe ser realizada en muchos casos utilizando los programas para acompañar esta tarea. El Data scrubbing debe ser hecho bien sea con ayuda de programas desarrollados para esto, o con ayuda de herramientas de scrubbing tales como Platinum Infopump.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
El corazón de la Bodega de Datos debe ser organizado desde un punto de vista de negocio. Se debe utilizar una estructura de Datos para el corazón de la Bodega de Datos, ligeramente normalizada. Esta estructura de Datos parece estar normalizada cuando se ve al nivel de Entidad-relación. Cuando se miran los atributos sin embargo, la estructura de datos puede estar desnormalizada. Esta representa una visión de negocio de la compañía y sus datos, independiente de cuanto usuarios este mirando a esos datos en un momento en particular. Esto es importante debido a que la forma en que la información es usada, cambiará frecuentemente y se necesita una Base de Datos estable para soportar el cambio. Por esta razón se debe utilizar una serie de Data Marts para proveer a los usuarios finales con fácil acceso a sus datos. Los Data Marts deben consistir en Datos extraídos del corazón de la Bodega de Datos y reorganizados y/o reformateados para hacer más fácil su uso para diferentes propósitos. Pero fofo que esos propósitos específicos pueden cambiar en el tiempo, los Data Marts deben ser concebidos con estructuras de Datos temporales. Cuando los usuarios no ven más los datos como están presentados por un Data Mart en particular, este Data Mart debe ser removido. Y mientras los usuarios desarrollan nuevas formas de hacer búsquedas y mirar los datos, deben ser creados nuevos Data Marts para hacer sus búsquedas más simples y con un mejor desempeño. Los Data Mart pueden incluir una gran variedad de estilos de tablas. Algunas pueden ser simplemente un subconjunto de datos de la Bodega de Datos, conteniendo solamente datos para una particular zona geográfica, un período específico de tiempo, una unidad de negocios. Es crítico que los usuarios sean provistos del método apropiado para utilizar la información de las Bodegas de Datos. No se debe esperar que un usuario novato negocie una compleja y poderosa herramienta sólo para hacer una simple pregunta de la Bodega de Datos. Similarmente un usuario adelantado rápidamente quedará frustrado con la Bodega de Datos si el o ella esperan hacer un complejo análisis de negocio usando una herramienta de acceso con menos poder del que se necesita. Es importante reconocer que hay diferentes estilos de usuarios finales cada uno con su propio nivel de conocimiento y necesidades, para así proveer de apropiados mecanismos de acceso para cada clase de usuarios. 3.5 Factores de riesgo
Es importante conocerlos para poder monitorearlos. Son éstos:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Expectativas de los usuarios . Se debe trabajar con las expectativas de los usuarios. Muchas veces el éxito depende de la diferencia entre lo que los usuarios esperan y lo que ellos perciben que les es entregado. Es crítico que el equipo de Bodega de Datos comunique las expectativas acerca de lo que será entregado muy claramente y ayude al usuario final a entender la naturaleza iterativa de construir una Bodega de Datos.
Experiencia con Bodegas de Datos. Este riesgo se puede reducir con el uso juicioso de experiencias de proveedores y consultores.
Dirección estratégica. Es relativamente lógico definir un punto de inicio lógico para la Bodega de Datos. Sin embargo cuando esta primera área se haya completado, es más difícil identificar áreas para esfuerzos futuros y asegurar que esos esfuerzos están alineados con los objetivos y necesidades del negocio. El riesgo se puede mitigar siguiendo la estrategia recomendada de la Bodega, para entender las necesidades y prioridades de la información del negocio y desarrollar una implementación de Bodega de Datos a largo plazo que cumpla con estas propiedades.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
4. Minería de Datos 3.1. Introducción Esta unidad tiene como propósito introducir al lector en los conceptos fundamentales de la minería de datos y su relación con las bodegas de datos, no es la intención de profundizar en cada uno de los temas, estos pueden ser ampliados en la bibliografía recomendada, es necesario que el lector tenga conocimientos en base de datos relacionales y distribuidas para una mejor comprensión del tema. Data Mining, la extracción de información oculta y predecible de grandes bases de datos , es una poderosa tecnología nueva con gran potencial para ayudar a las compañías a concentrarse en la información más importante de sus Bases de Información (Data Warehouse). Las herramientas de Data Mining predicen futuras tendencias y comportamientos, permitiendo en los negocios tomar decisiones proactivas y conducidas por un conocimiento acabado de la información (knowledge-driven). Los análisis prospectivos automatizados ofrecidos por un producto así van más allá de los eventos pasados provistos por herramientas retrospectivas típicas de sistemas de soporte de decisión. Las herramientas de Data Mining pueden responder a preguntas de negocios que tradicionalmente consumen demasiado tiempo para poder ser resueltas y a los cuales los usuarios de esta información casi no están dispuestos a aceptar. Estas herramientas exploran las bases de datos en busca de patrones ocultos, encontrando información predecible que un experto no puede llegar a encontrar porque se encuentra fuera de sus expectativas. Las técnicas de minería de datos se emplean para mejorar el rendimiento de procesos de negocio o industriales en los que se manejan grandes volúmenes de información estructurada y almacenada en bases de datos. Por ejemplo, se usan con éxito en aplicaciones de control de procesos productivos, como herramienta de ayuda a la planificación y a la decisión en marketing, finanzas, etc. Asimismo, la minería de datos es fundamental en la investigación científica y técnica, como herramienta de análisis y descubrimiento de conocimiento a partir de datos de observación o de resultados de experimentos. 4.2. Los Fundamentos del Data Mining
Las técnicas de Data Mining son el resultado de un largo proceso de investigación y desarrollo de productos. Esta evolución comenzó cuando los datos de negocios fueron almacenados por primera vez en computadoras, y continuó con mejoras en el acceso a los datos, y más recientemente con tecnologías generadas para permitir a los usuarios navegar a través de los datos en tiempo real. Data Mining toma este proceso de evolución más allá del acceso y navegación retrospectiva de los datos, hacia la entrega de información prospectiva y proactiva. Data Mining está lista para su aplicación en la comunidad de negocios porque está soportado por tres tecnologías que ya están suficientemente maduras:
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Recolección masiva de datos
Potentes computadoras con multiprocesadores
Algoritmos de Data Mining
Las bases de datos comerciales están creciendo a un ritmo sin precedentes. Un reciente estudio del META GROUP sobre los proyectos de Data Warehouse encontró que el 19% de los que contestaron están por encima del nivel de los 50 Gigabytes, mientras que el 59% espera alcanzarlo en el segundo trimestre de 1997. En algunas industrias, tales como ventas al por menor (retail), estos números pueden ser aún mayores. La necesidad paralela de motores computacionales mejorados puede ahora alcanzarse de forma más efectiva con de con multiprocesamiento paralelo. Los de Data Mining utilizan técnicas que han existido por lo menos desde hace 10 años, pero que sólo han sido implementadas recientemente como herramientas maduras, confiables, entendibles que consistentemente son más performantes que estadísticos clásicos. Los componentes esenciales de la de Data Mining han estado bajo desarrollo por décadas, en áreas de investigación como estadísticas, inteligencia artificial y aprendizaje de máquinas. Hoy, la madurez de estas técnicas, junto con los motores de bases de datos relacionales de alta performance, hicieron que estas tecnologías fueran prácticas para los entornos de data warehouse actuales. 4.3. El Alcance de Data Mining
El nombre de Data Mining deriva de las similitudes entre buscar valiosa información de negocios en grandes bases de datos, por ej.: encontrar información de la venta de un producto entre grandes montos de Gigabytes almacenados, minar una montaña para encontrar una veta de metales valiosos. Ambos procesos requieren examinar una inmensa cantidad de material, o investigar inteligentemente hasta encontrar exactamente donde residen los valores. Dadas bases de datos de suficiente tamaño y calidad, la tecnología de Data Mining puede generar nuevas oportunidades de negocios al proveer estas capacidades:
Predicción automatizada de tendencias y comportamientos . Data Mining automatiza el proceso de encontrar información predecible en grandes bases de datos. Preguntas que tradicionalmente requerían un intenso análisis manual, ahora pueden ser contestadas directa y rápidamente desde los datos. Un típico ejemplo de problema predecible es el marketing apuntado a objetivos (targeted marketing). Data Mining usa datos en mailing promocionales anteriores para identificar posibles objetivos para maximizar los resultados de la inversión en futuros mailing. Otros problemas predecibles incluyen pronósticos de problemas financieros futuros y otras formas de incumplimiento, e identificar segmentos de población que probablemente respondan similarmente a eventos dados.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Descubrimiento automatizado de modelos previamente desconocidos. Las herramientas de Data Mining barren las bases de datos e identifican modelos previamente escondidos en un sólo paso. Otros problemas de descubrimiento de modelos incluye detectar transacciones fraudulentas de tarjetas de créditos e identificar datos anormales que pueden representar errores de tipeado en la carga de datos.
Las técnicas de Data Mining pueden redituar los beneficios de automatización en las plataformas de hardware y software existentes y puede ser implementadas en sistemas nuevos a medida que las plataformas existentes se actualicen y nuevos productos sean desarrollados. Cuando las herramientas de Data Mining son implementadas en sistemas de procesamiento paralelo de alta performance, pueden analizar bases de datos masivas en minutos. Procesamiento más rápido significa que los usuarios pueden automáticamente experimentar con más modelos para entender datos complejos. Alta velocidad hace que sea práctico para los usuarios analizar inmensas cantidades de datos. Grandes bases de datos, a su vez, producen mejores predicciones.
Las bases de datos pueden ser grandes tanto en profundidad como en ancho:
Más columnas. Los analistas muchas veces deben limitar el número de variables a examinar cuando realizan análisis manuales debido a limitaciones de tiempo. Sin embargo, variables que son descartadas porque parecen sin importancia pueden proveer información acerca de modelos desconocidos. Un Data Mining de alto rendimiento permite a los usuarios explorar toda la base de datos, sin preseleccionar un subconjunto de variables.
Más filas. Muestras mayores producen menos errores de estimación y desvíos, y permite a los usuarios hacer inferencias acerca de pequeños pero importantes segmentos de población. 4.4. Fases de un Proyecto de Minería de Datos
Los pasos a seguir para la realización de un proyecto de minería de datos son siempre los mismos, independientemente de la técnica específica de extracción de conocimiento usada. Ver fig. 45.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 45: Fases de un Proyecto de Minería de Datos
El proceso de minería de datos pasa por las siguientes fases: Filtrado de datos Selección de variables Extracción de conocimiento Interpretación y evaluación Si desea obtener una descripción más detallada, puede consultar la documentación de CRISP-DM. CRISP-DM (CRoss Industry Standard Process for Data Mining) es un estándar industrial utilizado por más de 160 empresas e instituciones de todo el mundo, que surge en respuesta a la falta de estandarización y propone un modelo de proceso general para proyectos de minería de datos. 4.5. ¿Cómo Trabaja el Data Mining?
¿Cuán exactamente es capaz Data Mining de decirle cosas importantes que usted desconoce o que van a pasar? La técnica usada para realizar estas hazañas en Data Mining se llama Modelado . Modelado es simplemente el acto de construir un modelo en una situación donde usted conoce la respuesta y luego la aplica en otra situación de la cual desconoce la respuesta. Por ejemplo, si busca un galeón español hundido en los mares lo primero que podría hacer es investigar otros tesoros españoles que ya fueron encontrados en el pasado. Notaría que esos barcos frecuentemente fueron encontrados fuera de las costas de Bermuda y que hay ciertas características respecto de las corrientes oceánicas y ciertas rutas que probablemente tomara el capitán del barco en esa época. Usted nota esas similitudes y arma un modelo que incluye las características comunes a todos los sitios de estos tesoros hundidos. Con estos modelos en mano sale a buscar el tesoro donde el modelo indica que en el pasado hubo más probabilidad de darse una situación similar. Con un poco de esperanza, si tiene un buen modelo, probablemente encontrará el tesoro. Este acto de construcción de un modelo es algo que la gente ha estado haciendo desde hace mucho tiempo, seguramente desde antes del auge de las computadoras y de la tecnología de Data Mining. Lo que ocurre en las computadoras, no es muy diferente de la manera en que la gente construye
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
modelos. Las computadoras son cargadas con mucha información acerca de una variedad de situaciones donde una respuesta es conocida y luego el software de Data Mining en la computadora debe correr a través de los datos y distinguir las características de los datos que llevarán al modelo. Una vez que el modelo se construyó, puede ser usado en situaciones similares donde usted no conoce la respuesta. Si alguien le dice que tiene un modelo que puede predecir el uso de los clientes, ¿Cómo puede saber si es realmente un buen modelo? La primera cosa que puede probar es pedirle que aplique el modelo a su base de clientes - donde usted ya conoce la respuesta. Con Data Mining, la mejor manera para realizar esto es dejando de lado ciertos datos para aislarlos del proceso de Data Mining. Una vez que el proceso está completo, los resultados pueden ser testeados contra los datos excluidos para confirmar la validez del modelo. Si el modelo funciona, las observaciones deben mantenerse para los datos excluidos. 4.6. Una arquitectura para Data Mining
Para aplicar mejor estas técnicas avanzadas, éstas deben estar totalmente integradas con el data warehouse así como con herramientas flexibles e interactivas para el análisis de negocios. Varias herramientas de Data Mining actualmente operan fuera del warehouse, requiriendo pasos extra para extraer, importar y analizar los datos. Además, cuando nuevos conceptos requieren implementación operacional, la integración con el warehouse simplifica la aplicación de los resultados desde Data Mining. El Data warehouse analítico resultante puede ser aplicado para mejorar procesos de negocios en toda la organización, en áreas tales como manejo de campañas promocionales, detección de fraudes, lanzamiento de nuevos productos, etc. El punto de inicio ideal es un data warehouse que contenga una combinación de datos de seguimiento interno de todos los clientes junto con datos externos de mercado acerca de la actividad de los competidores. Información histórica sobre potenciales clientes también provee una excelente base para prospecting. Este warehouse puede ser implementado en una variedad de sistemas de bases relacionales y debe ser optimizado para un acceso a los datos flexible y rápido. Un server multidimensional OLAP permite que un modelo de negocios más sofisticado pueda ser aplicado cuando se navega por el data warehouse. Las estructuras multidimensionales permiten que el usuario analice los datos de acuerdo a como quiera mirar el negocio - resumido por línea de producto, u otras perspectivas claves para su negocio. El server de Data Mining debe estar integrado con el data warehouse y el server OLAP para insertar el análisis de negocios directamente en esta infraestructura. Un avanzado, metadata centrado en procesos define los objetivos del Data Mining para resultados específicos tales como manejos de campaña, prospecting, y optimización de promociones. La integración con el data warehouse permite que decisiones operacionales sean implementadas directamente y monitoreadas. A medida que el data warehouse
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
crece con nuevas decisiones y resultados, la organización puede "minar" las mejores prácticas y aplicarlas en futuras decisiones. Este diseño representa una transferencia fundamental desde los sistemas de soporte de decisión convencionales. Más que simplemente proveer datos a los usuarios finales a través de software de consultas y reportes, el server de Análisis Avanzado aplica los modelos de negocios del usuario directamente al warehouse y devuelve un análisis proactivo de la información más relevante. Estos resultados mejoran los metadatos en el server OLAP (procesamiento analítico on-line) proveyendo una estrato de metadatos que representa una vista fraccionada de los datos. Generadores de reportes, visualizadores y otras herramientas de análisis pueden ser aplicadas para planificar futuras acciones y confirmar el impacto de esos planes. 4.7. Técnicas más comúnmente usadas en Data Mining:
Redes neuronales artificiales: modelos predecible no-lineales que aprenden a través del entrenamiento y semejan la estructura de una red neuronal biológica.
Árboles de decisión: estructuras de forma de árbol que representan conjuntos de decisiones. Estas decisiones generan reglas para la clasificación de un conjunto de datos. Métodos específicos de árboles de decisión incluyen Árboles de Clasificación y Regresión (CART: Classification And Regression Tree) y Detección de Interacción Automática de Chi Cuadrado (CHAI: Chi Square Automatic Interaction Detection)
Algoritmos genéticos: técnicas de optimización que usan procesos tales como combinaciones genéticas, mutaciones y selección natural en un diseño basado en los conceptos de evolución.
Método del vecino más cercano: una técnica que clasifica cada registro en un conjunto de datos basado en una combinación de las clases del/de los k registro (s) más similar/es a él en un conjunto de datos históricos (donde k 1). Algunas veces se llama la técnica del vecino≥ k -más cercano.
Regla de inducción: la extracción de reglas if-then de datos basados en significado estadístico.
Muchas de estas tecnologías han estado en uso por más de una década en herramientas de análisis especializadas que trabajan con volúmenes de datos relativamente pequeños. Estas capacidades están ahora evolucionando para integrarse directamente con herramientas OLAP y de Data Warehousing.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Capítulo 2. Bases de datos orientadas a objetos 2.1 Introducción
Los sistemas de bases de datos orientados a objetos tienen sus orígenes en los lenguajes de programación orientados a objetos. La idea fundamental es que el usuario no debería tener que batallar con construcciones orientadas al computador tales como registros y campos, sino más bien debería poder manejar objetos (y operaciones) que se asemejen más a sus equivalentes en el mundo real. Por ejemplo, en vez de pensar en términos de una tupla DEPTO junto con un conjunto de tuplas EMP, las cuales incluyen valores de clave ajena que hacen referencia a esa tupla DEPTO, el usuario debería poder pensar directamente en un "objeto" departamento que contenga en realidad un conjunto de "objetos" empleado. Y en vez de (por ejemplo) tener que insertar una tupla en la relación EMP con un valor apropiado de NUMDEPTO (la clave ajena), el usuario debería ser capaz de crear en forma directa un nuevo objeto empleado e incluirlo en el objeto departamento pertinente también en forma directa. Dicho de otro modo, la idea fundamental es elevar el nivel de abstracción. La elevación del nivel de abstracción es sin duda un objetivo deseable, y el paradigma de la orientación a objetos ha tenido considerable éxito en alcanzar ese objetivo en el campo de los lenguajes de programación. Por tanto, es natural preguntar si es posible aplicar el mismo paradigma en el área de las bases de datos. Es más, la idea de manejar una base de datos formada por "objetos encapsulados" (por ejemplo, un objeto dependencia que "sabe qué significa" añadir un empleado o cambiar al gerente o recortar el presupuesto), en vez de tener que entender relaciones, actualizaciones de tuplas, claves ajenas, etcétera, es desde luego mucho más atractiva y “fácil” desde el punto de vista del usuario, al menos en lo superficial. Paradigma de orientación a objetos (oo)
En un ambiente OO, el software se organiza como un conjunto de objetos discretos que incorporan tanto su estructura como su comportamiento, en contraste con ambientes tradicionales en donde estas dos características se encuentran separadas. Los primeros intentos en aplicar la orientación a objetos al ambiente de bases de datos fueron mediante la construcción de interfaces como una capa externa a los SABDs relaciónales. Uno de los problemas que se tienen actualmente es la falta de estándares en la concepción y definición de términos. Sin embargo, a continuación se van a
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
introducir los conceptos mínimos, que se consideran fundamentales en la aplicación de este paradigma a la tecnología de bases de datos. 2.2 Conceptos básicos:
En esta sección se presentan algunos de los términos y conceptos principales del enfoque 00, como los objetos mismos (por supuesto), las clases, métodos, mensajes y jerarquías de clases. También relacionaremos estas ideas con términos y conceptos más familiares siempre que sea posible o apropiado. De hecho, quizá resulte útil mostrar antes que nada una correspondencia burda entre los términos OO y los términos de programación tradicional: Término OO
Término en programación
Objeto Clase Método Mensaje Jerarquía de clases
variable
tipo función llamada jerarquía de tipos
2.2.1 Objetos
Antes de entrar en detalles, es bueno advertir que en el mundo de los objetos no se encuentra el tipo de precisión al que estamos acostumbrados en el mundo relacional. Además, muchos conceptos de objetos –o las definiciones publicadas de esos objetos- son bastante imprecisos y hay muy poco consenso verdadero y mucho desacuerdo, incluso en el nivel más básico. En particular, no hay un “modelo de datos de objetos” abstracto ni formalmente definido, y tampoco hay consenso sobre un modelo informal. ¿Qué es un objeto? Todo.
Es un principio básico del enfoque de objetos que “todo es un objeto” (a veces “todo es un objeto de primera clase”). Algunos objetos son inmutables: ejemplos de esto pueden ser los enteros y las cadenas de caracteres. Otros objetos son mutables; algunos ejemplos podrían ser los objetos de departamento y empleado. Por lo tanto, en la terminología tradicional, los objetos inmutables corresponden a los valores y los objetos mutables corresponden a las variables. Todo objeto tiene un tipo (el término en objetos es clase). A los objetos individuales con frecuencia se les llama específicamente ejemplares (instancias) de objeto, para distinguirlos con claridad del tipo o clase del objeto correspondiente. El término tipo se utiliza en su sentido usual de lenguaje de programación; por lo tanto, en particular en este término se incluye el conjunto de
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
operadores (el término en el entorno de objetos es métodos) que pueden ser aplicados a los objetos de ese tipo. 2.2.2 Polimorfismo.
El polimorfismo es otro de los pilares fundamentales de la programación orientada a objetos. Es la capacidad de almacenar objetos de un determinado tipo en variables de tipos antecesores del primero a costa, claro está, de sólo poderse acceder a través de dicha variable a los miembros comunes a ambos tipos. Sin embargo, las versiones de los métodos virtuales a las que se llamaría a través de esas variables no serían las definidas como miembros del tipo de dichas variables, sino las definidas en el verdadero tipo de los objetos que almacenan. 2.2.3 Herencia.
El mecanismo de herencia es uno de los pilares fundamentales en los que se basa la programación orientada a objetos. Es un mecanismo que permite definir nuevas clases a partir de otras ya definidas de modo que si en la definición de una clase indicamos que ésta deriva de otra, entonces la primera -a la que se le suele llamar clase hija- será tratada por el compilador automáticamente como si su definición incluyese la definición de la segunda –a la que se le suele llamar clase padre o clase base. 2.2.4 Encapsulación.
Ya hemos visto que la herencia y el polimorfismo son dos de los pilares fundamentales en los que se apoya la programación orientada a objetos. Pues bien, el tercero es la encapsulación, que es un mecanismo que permite a los diseñadores de tipos de datos determinar qué miembros de los tipos pueden ser utilizados por otros programadores y cuáles no. Las principales ventajas que ello aporta son:
Se facilita a los programadores que vayan a usar el tipo de dato (programadores clientes) el aprendizaje de cómo trabajar con él, pues se le pueden ocultar todos los detalles relativos a su implementación interna y sólo dejarle visibles aquellos que puedan usar con seguridad. Además, así se les evita que cometan errores por manipular inadecuadamente miembros que no deberían tocar.
Se facilita al creador del tipo la posterior modificación del mismo, pues si los programadores clientes no pueden acceder a los miembros no visibles, sus aplicaciones no se verán afectadas si éstos cambian o se eliminan. Gracias a esto es posible crear inicialmente tipos de datos con un diseño sencillo aunque poco eficiente, y si posteriormente es necesario modificarlos para
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
aumentar su eficiencia, ello puede hacerse sin afectar al código escrito en base a la no mejorada de tipo. La encapsulamiento de objetos u ocultación de la información es sin duda una buena idea en muchos casos: es evidente que los conceptos gemelos de a) ocultar los detalles irrelevantes a la vista del usuario (con lo cual es posible alterar esos detalles, cuando sea necesario, en una forma controlada y relativamente poco difícil) y b) ofrecer un acceso disciplinado a objetos sólo a través de una interfaz pública, son claramente apropiados para muchos usuarios y muchas aplicaciones. Pero hay que tener en cuenta que siempre existirá la necesidad de obtener acceso a los datos en formas no previstas para realizar consultas especiales, razón por la cual la idea de sólo poder operar a través de métodos predefinidos no es aceptable en algunas situaciones. Los sistemas OO tienden a ser demasiado rígidos en este aspecto. La encapsulación se consigue añadiendo modificadores de acceso en las definiciones de miembros y tipos de datos. Estos modificadores son partículas que se les colocan delante para indicar desde qué códigos puede accederse a ellos, entendiéndose por acceder el hecho de usar su nombre para cualquier cosa que no sea definirlo, como llamarlo si es una función, leer o escribir su valor si es un campo, crear objetos o heredar de él si es una clase, etc 2.3 Arquitectura de administrador de sistemas de BDOO.
La estructura de las bases de datos orientadas a objetos no presenta la uniformidad de las bases de datos relaciónales. Para construir una estructura física fácil de mantener, comúnmente los objetos se representan así: Determinadas clases se tratan como clases básicas de bloques que se construyan, que el sistema de computadores implemente directamente. Comúnmente, las clases básicas corresponden a tipos de datos de lenguajes de programación estándar, tales como entero, flotante, carácter y cadena. Las instancias de clases que no son básicas se representan así: Las variables se representan por campos de un tipo de registro. Cada campo contiene el valor del objeto para instancias de las clases básicas, o bien el identificador del objeto para instancias de las clases que no son básicas. Las variables con un conjunto de valores se representan por una lista enlazada de los objetos que son miembros del conjunto. La estructura física hace que sea posible utilizar registros de longitud fija para implementar una base de datos orientada a objetos, aunque la modificación del esquema puede complicar esto.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Cuando la relación de contenido es jerárquica, el esquema de base de datos para una base de datos orientada a objetos puede representarse utilizando el modelo relacional anidado. No todas las variables encajan convenientemente en la estructura que se ha descrito. Algunas de las aplicaciones que se citan incluyen tipos de datos altamente especializados que son grandes físicamente y que, por razones prácticas, normalmente se manipulan mediante programas de aplicación que no son parte del conjunto de métodos con las clases: Datos de texto. El texto, normalmente se trata como una cadena de bytes que manipulan los editores y formateadores. Datos de audio. Comúnmente, los datos de audio son una representación comprimida digitalizada del habla que manejan aplicaciones de software separadas. Datos de video y gráficos. Los datos de video pueden representarse como un mapa de bytes o como un conjunto de líneas, cajas y otros objetos geométricos. Aunque algunos datos gráficos a menudo se gestionan dentro del sistema de base de datos, en muchos casos se utilizan aplicaciones de software especiales. Las variables que contienen datos de los tipos anteriores, con frecuencia se denominan campos largos, debido a que una implementación relacional de objetos que contengan estas variables requiere registros que contengan campos cuya longitud pueda ser de varios mega bites. Un campo largo se almacena en un archivo especial (o conjunto de archivos) reservado para almacenamiento de campos largos. El método más ampliamente utilizado para acceder a campos largos es el método de verificación de resultados de salida (checkout)/verificación de datos de entrada (checkin). El usuario comprueba (checkout) la copia de un objeto con campo largo, opera sobre esta copia utilizando programas de aplicación de propósito especial y comprueba la copia modificada (checkin). Las nociones de verificación de resultados de salida (checkout) y verificación de datos de entrada (checkin) corresponden aproximadamente a una lectura y a una escritura. Sin embargo, el resultado de la operación de verificación de datos de entrada normalmente no es una escritura sino más bien la creación de una nueva versión. 2.4 Sistema administradores de bases de datos orientadas a objetos (SABDOO)
La primera vez que se habla del concepto de un SABD-OO se remonta al año 1983 con una propuesta de G. Copeland y D. Maier, en la cual sugieren construir tal SABD a partir del lenguaje de programación Smalltalk y con la colaboración de miembros del Oregon Graduate Center. De este prototipo se desarrolla un producto y se comercializa en 1988 por Servio Logia, bajo el nombre de GemStone
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Por otra parte, en ese mismo año, la compañía Hewlett Packard implementa un proyecto bajo el nombre de Iris. A pesar de que aun no existe un consenso de lo que debe ser un SABD-OO, existen algunas características mínimas que deben ser satisfechas. En efecto, un SABD para ser considerado con una etiqueta de orientación a objetos, debe satisfacer al menos los siguientes criterios:
Debe ser un SABD en el sentido tradicional Debe ser un sistema orientado a objetos
De esta forma, un SAGD-OO debe satisfacer las reglas que aparecen en la figura siguiente: Reglas de bases de datos El sistema debe: Asegurar la persistencia de los datos. Poder administrar en forma eficiente una jerarquía de memorias. Permitir a los usuarios manipular los datos en forma concurrente. Permitir al usuario consultar la base en forma natural y sencilla. Permitir la administración de objetos complejos. Reglas de orientación a objetos Los objetos deben tener una identidad independiente de su valor. El sistema debe además: Permitir la noción de encapsulamiento. Agrupar los objetos en clases o poder establecer tipos. Definir una jerarquía de clases o de tipos. Permitir la programación completa de las aplicaciones. Permitir la extensión de las clases o tipos predefinidos por parte del usuario. 2.5 El sistema Postgres
Para referenciar uno de los productos que trabajan este tipo de bases de datos hemos tomado el proyecto Postgres. El proyecto Postgres- Post Ingres- inicia en 1986 como una extensión del SABD Ingres. Ha sido escrito en el lenguaje de programación C y consta de 180000 líneas de código (STON91) Postgres se apoya en la idea de extender el modelo relacional con mecanismos generales que permitan el soporte de objetos complejos, así como implementar jerarquías de objetos. Entre los mecanismos, se pueden mencionar los tipos de datos abstractos, los datos de tipo procedimiento y las reglas.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Una base datos en Postgres se puede ver como un conjunto de tablas. El tipo de un atributo puede ser atómico: entero, punto flotante, booleano, date, o bien estructurado: arreglos o procedimientos. Entre los objetivos principales del sistema Postgres de pueden mencionar los siguientes:
Mejorar la administración de los objetos complejos Permitir la definición de nuevos tipos de datos, nuevos operadores y nuevos métodos de acceso. Brindar mecanismos primarios para la definición de bases de datos. Mejorar la seguridad de funcionamiento.
2.6 Lenguaje de modelado unificado (UML) 2.6.1 Introducción
La intención de este capítulo no es la de hacer un estudio detallado de Uml, es tan solo motivar al lector a que con base en los temas aquí tratados pueda consultar textos avanzados sobre la temática y su relación con las bases de datosUml es un lenguaje de modelamiento para la especificación, visualización, construcción y documentación de los artefactos de un proceso de sistema intensivo. Incluye dentro de otras las siguientes características: Dentro de un proceso de sistema intensivo , un método es aplicado para llegar o evolucionar un sistema
Como un lenguaje , es usado para la comunicación. Es decir, un medio para capturar el conocimiento (semánticas) respecto a un tema y expresar el conocimiento (sintaxis) resguardando el tema propósito de la comunicación. El tema es el sistema en estudio.
Como un lenguaje para modelamiento , se enfoca en la comprensión de un tema a través de la formulación de un modelo del tema (y su contexto respectivo). El modelo abarca el conocimiento cuidando del tema, y la apropiada aplicación de este conocimiento constituye inteligencia.
Cuidando la unificación , integra las mejores prácticas de la ingeniería de la industria tecnológica y sistemas de información pasando por todos os tipos de sistemas (software y no - software), dominios (negocios versus software) y los procesos de ciclo de vida.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
En cuanto a cómo se aplica para especificar sistemas, puede ser usado para comunicar "qué" se requiere de un sistema y "cómo" un sistema puede ser realizado.
En cuanto a cómo se aplica para visualizar sistemas, puede ser usado para describir visualmente un sistema antes de ser realizado.
En cuanto a cómo se aplica para construir sistemas, puede ser usado para guiar la realización de un sistema similar a los "planos".
En cuanto a cómo se aplica para documentar sistemas, puede ser usado para capturar conocimiento respecto a un sistema a lo largo de todo el proceso de su ciclo de vida. Uml no es: Un lenguaje de programación visual, sino un lenguaje de modelamiento visual
Una herramienta o depósito de especificación, sino un lenguaje para modelamiento de especificación.
Un proceso, sino que habilita procesos.
2.6.2 UML, ¿Método o Lenguaje de Modelado?
UML es un lenguaje para hacer modelos y es independiente de los métodos de análisis y diseño. Existen diferencias importantes entre un método y un lenguaje de modelado. Un método es una manera explícita de estructurar el pensamiento y las acciones de cada individuo. Además, el método le dice al usuario qué hacer, cómo hacerlo, cuándo hacerlo y por qué hacerlo; mientras que el lenguaje de modelado carece de estas instrucciones. Los métodos contienen modelos y esos modelos son utilizados para describir algo y comunicar los resultados del uso del método. 2.6.2.1 Elementos de Uml : Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución. Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología. Reglas o Mecanismos generales : Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario. 2.6.2.2 Utilidad de UML UML es un lenguaje para modelamiento de propósito general evolutivo, ampliamente aplicable, que puede ser soportado por diferentes herramientas e industrialmente estandarizado. Se aplica a una multitud de diferentes tipos de sistemas, dominios, y métodos o procesos. Como lenguaje de propósito general , se enfoca en el corazón de un conjunto de conceptos para la adquisición, compartición y utilización de conocimientos emparejados con mecanismos de extensión.
Como un lenguaje para modelamiento ampliamente aplicable, puede ser aplicado a diferentes tipos de sistemas (software y no - software), dominios (negocios versus software) y métodos o procesos.
Como un lenguaje para modelamiento soportable por herramientas, las herramientas ya están disponibles para soportar la aplicación del lenguaje para especificar, visualizar, construir y documentar sistemas.
Como un lenguaje para modelamiento industrialmente estandarizado, no es un lenguaje cerrado, propiedad de alguien, sino más bien, un lenguaje abierto y totalmente extensible reconocido por la industria.
Mejores tiempos totales de desarrollo (de 50 % o más).
Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
Establecer conceptos y artefactos ejecutables.
Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
Mejor soporte a la planeación y al control de proyectos.
Alta reutilización y minimización de costos. UML posibilita la captura, comunicación y nivelación de conocimiento estratégico, táctico y operacional para facilitar el incremento de valor, aumentando la calidad, reduciendo costos y reduciendo el tiempo de presentación al mercado; manejando riesgos y siendo proactivo para el posible aumento de complejidad o cambio.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
2.6.3 Una perspectiva de uml Las siguientes secciones presentan una vista más detallada al modelado con UML. Un sistema de reserva de aerolíneas simple se va a usar para mostrar los diagramas y técnicas de modelado con UML. Se cubren los siguientes puntos:
Organizando tu sistema con paquetes
Modelando con Casos de Uso, y usándolos para averiguar los requisitos del sistema
Modelando con Diagramas de Secuencia y Colaboración
Analizando y diseñando con el Diagrama de Clase, y extendiendo UML con la técnica de las tarjetas CRC
Modelando comportamiento con Diagramas de Actividad y de Estado
Modelando componentes de software, distribución e implementación
Extendiendo UML con el diseño de Bases de Datos relacionales
Una de las tareas clave para modelar un sistema de software de grandes dimensiones es dividirlo primero en áreas manejables. Aunque estas áreas se llaman dominios, categorías o subsistemas, la idea es la misma: dividir el sistema en áreas que tengan competencias parecidas. UML introduce la noción de un paquete como el ítem universal para agrupar elementos, permitiendo a los modeladores subdividir y categorizar sistemas. Los paquetes pueden ser usados en cualquier nivel, desde el nivel más alto, donde son usados para subdividir el sistema en dominios, hasta el nivel más bajo, donde son usados para agrupar casos de uso individuales, clases, o componentes. Ver fig.34
Figura 34: Organizando el sistema mediante el uso de paquetes
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
2.6.3.1 Modelado de Casos de Uso Un Caso de Uso es un documento narrativo que describe a los actores utilizando un sistema para satisfacer un objetivo. Es una historia o una forma particular de usar un sistema. Los casos de uso son requisitos, en particular requisitos funcionales.
El modelado de Casos de Uso es la técnica más efectiva y a la vez la más simple para modelar los requisitos del sistema desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cómo un sistema o negocio funciona actualmente, o cómo los usuarios desean que funcione. No es realmente una aproximación a la orientación a objetos; es realmente una forma de modelar procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el análisis de sistemas orientado a objetos. Los casos de uso son generalmente el punto de partida del análisis orientado a objetos con UML. El modelo de casos de uso consiste en actores y casos de uso. Los actores representan usuarios y otros sistemas que interaccionan con el sistema. Se dibujan como "muñecos" de palo. Actualmente representan el tipo de usuario, no una instancia de usuario. Los casos de uso representan el comportamiento del sistema, los escenarios que el sistema atraviesa en respuesta a un estímulo desde un actor. Se dibujan como elipses.
Figura 35: Modelado de Casos de Uso.
Cada caso de uso se documenta por una descripción del escenario. La descripción puede ser escrita en modo de texto o en un formato paso a paso. Cada caso de uso puede ser también definido por otras propiedades, como las condiciones pre- y post- del escenario --- condiciones que existen antes de que el escenario comience, y condiciones que existen después de que el escenario se
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
completa. Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. Ver fig. 35 2.6.3.2 Estudiar y descubrir los requisitos El objetivo final en cualquier diseño de software es satisfacer los requisitos del usuario para el sistema. Estos requisitos pueden ser requisitos de software, requisitos de productos, o requisitos de pruebas. La meta de capturar y comprobar los requisitos del usuario es asegurar que todos los requisitos son completados por el diseño, y que el diseño es acorde con los requisitos especificados.
Muchas veces los requisitos del sistema ya existen en forma de documentos de requisitos. Los casos de uso se utilizan para correlacionar cada escenario con los requisitos que completa. Si los requisitos no existen, modelar el sistema a través de los Casos de Uso, permite el descubrimiento de estos requisitos. 2.6.3.3 Organización de Diagramas de Casos de Uso Durante el análisis de negocio (business) del sistema, puedes desarrollar un modelo de caso de uso para este sistema, y construir paquetes para representar los varios dominios de negocio (business) del sistema. Puedes descomponer cada paquete con un Diagrama de Caso de Uso que contenga los Casos de Uso de un dominio, con interacciones de actor. 2.6.3.4 Modelar secuencias alternas a través de la relación "Extiende" (extends) Típicamente, uno modela cada Caso de Uso con una secuencia normal de acciones. El usuario entonces considera condiciones "que si" para cada paso, y desarrolla Casos de Uso basados en estas secuencias alternas de eventos. Las secuencias alternas se modelan en casos de uso separados, los cuales están relacionados con el caso de uso original mediante una relación "Extiende" (extends). Las relaciones Extiende (extends) pueden ser pensadas como un caso de uso equivalente a herencia, en el cual el caso de uso extendido, hereda y modifica el comportamiento del caso de uso original. 2.6.3.5 Eliminar el modelado redundante a través de la relación "Usa" (uses) Para eliminar el modelado redundante de buena parte del comportamiento que aparezca en varios casos de uso, la parte del comportamiento puede ser modelada en un caso de uso separado que está relacionado con los otros casos de uso mediante la relación "Usa" (uses). La relación Usa (uses) se puede pensar como un caso de uso equivalente. Ver fig. 36.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 36: Relación caso de uso Extiende (extends) frente a relación de caso Usa (uses). 2.6.4. Diagramas de Secuencia El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos en un sistema. Un diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de una vista 'business' del escenario, el diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos.
Típicamente uno examina la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Si tienes modelada la descripción de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar sobre" esos pasos para descubrir qué objetos son necesarios para que se puedan seguir los pasos. Un diagrama de secuencia muestra los objetos que intervienen en el escenario con líneas discontinuas verticales, y los mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronológicamente desde la parte superior del diagrama a la parte inferior; la distribución horizontal de los objetos es arbitraria. Ver fig. 37.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 37: Diagrama de Secuencia para un escenario
Durante el análisis inicial, el modelador típicamente coloca el nombre 'business' de un mensaje en la línea del mensaje. Más tarde, durante el diseño, el nombre 'business' es reemplazado con el nombre del método que está siendo llamado por un objeto en el otro. El método llamado, o invocado, pertenece a la definición de la case instan ciada por el objeto en la recepción final del mensaje. 2.6.5. Diagramas de Colaboración El Diagrama de Colaboración presenta una alternativa al diagrama de secuencia para modelar interacciones entre objetos en el sistema. Mientras que el diagrama de secuencia se centra en la secuencia cronológica del escenario que estamos modelando, el diagrama de colaboración se centra en estudiar todos los efectos de un objeto dado durante un escenario. Los objetos se conectan por medio de enlaces, cada enlace representa una instancia de una asociación entre las clases implicadas, ver fig. 38. El enlace muestra los mensajes enviados entre los objetos, el tipo de mensaje (sincrónico, asincrónico, simple, blanking, y 'time-out'), y la visibilidad de un objeto con respecto a los otros.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 38: Diagrama de Colaboración para un grupo de Objetos 2.6.6. Modelando el comportamiento de las Clases con Diagramas de Estado Mientras los diagramas de interacción y colaboración modelan secuencias dinámicas de acción entre grupos de objetos en un sistema, el diagrama de estado se usa para modelar el comportamiento dinámico de un objeto en particular, o de una clase de objetos.
Un diagrama de estado se modela para todas las clases que se consideran con un comportamiento dinámico. En él, modelas la secuencia de estado que un objeto de la clase atraviesa durante su vida en respuesta a los estímulos recibidos, junto con sus propias respuestas y acciones. Por ejemplo, un comportamiento de un objeto se modela en términos de en qué estado está inicialmente, y a qué estado cambia cuando recibe un evento en particular. También modelas qué acciones realiza un objeto en un estado en concreto. Los estados representan las condiciones de objetos en ciertos puntos en el tiempo. Los eventos representan incidentes que hacen que los objetos pasen de un estado a otro. Las líneas de transición describen el movimiento desde un estado hasta otro. Cada línea de transición se nombre con el evento que causa esta transición. Las acciones ocurren cuando un objeto llega a un estado. Ver fig. 39.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 39: Modelando Comportamiento Dinámico de un objeto 'Vuelo' con un diagrama de estado 2.6.7. Diagramas de Actividad El Diagrama de Actividad es un diagrama de flujo del proceso multi-propósito que se usa para modelar el comportamiento del sistema. Los diagramas de actividad se pueden usar para modelar un Caso de Uso, o una clase, o un método complicado.
Un diagrama de actividad es parecido a un diagrama de flujo; la diferencia clave es que los diagramas de actividad pueden mostrar procesado paralelo (parallel processing). Esto es importante cuando se usan diagramas de actividad para modelar procesos 'bussiness' algunos de los cuales pueden actuar en paralelo, y para modelar varios hilos en los programas concurrentes. 2.6.7.1 Usando Diagramas de Actividad para modelar Casos de Uso Los Diagramas de Actividad ofrecen una herramienta gráfica para modelar el proceso de un Caso de Uso. Se pueden usar como un añadido a una descripción textual del caso de uso, o para listar los pasos del caso de uso. Una descripción textual, código, u otros diagramas de actividad pueden detallar más la actividad. 2.6.7.2 Usando Diagramas de Actividad para modelar Clases Cuando se modela el comportamiento de una clase, un diagrama de estado de UML se suele usar normalmente para modelar situaciones donde ocurren eventos asincrónicos. El diagrama de actividad se usa cuando todos o la mayoría de los elementos representan el desarrollo de los pasos dados por las acciones generadas internamente. Ver fig. 40. Deberías asignar actividades a las clases antes de terminar con el diagrama de actividad.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 40: Diagrama de Actividad 2.6.8 Modelando Componentes Componentes de Software El Diagrama de Componentes se usa para modelar la estructura del software, incluyendo las dependencias entre los componentes de software, los componentes de código binario, y los componentes ejecutables. En el Diagrama de Componentes modelas componentes del sistema ver fig. 41, a veces agrupados por paquetes, y las dependencias que existen entre componentes (y paquetes de componentes).
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 41: Modelando componentes con el Diagrama de Componentes 2.6.9 Modelando la Distribución Distribución y la la Implementación Los Diagramas de Implementación se usan para modelar la configuración de los elementos de procesado en tiempo de ejecución (run-time processing elements) y de los componentes, procesos y objetos de software que viven en ellos. En el diagrama 'deployment', empiezas modelando nodos físicos y las asociaciones de comunicación que existen entre ellos. Para cada nodo, puedes indicar qué instancias de componentes viven o corren (se ejecutan) en el nodo. También puedes modelar los objetos que contiene el componente.
Los Diagramas de Implementación ver fig. fig. 42, se usan para modelar sólo componentes que existen como entidades en tiempo de ejecución; no se usan para modelar componentes solo de tiempo de compilación o de tiempo de enlazado. Puedes también modelar componentes que migran de nodo a nodo u objetos que migran de componente a componente usando una relación de dependencia con el estereotipo 'becomes' (se transforma)
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 42: Modelando la Distribución del Sistema con el Diagrama de Implementación 2.6.10 Diseño de Bases de Datos Relacionales -- Una extensión informal de UML El Diagrama de Clase presenta un mecanismo de implementación neutral para modelar los aspectos de almacenado de datos del sistema. Las clases persistentes, sus atributos, y sus relaciones pueden ser implementados directamente en una base de datos orientada a objetos. Aun así, en el entorno de desarrollo actual, la base de datos relacional es el método más usado para el almacenamiento de datos. Es en el modelado de esta área donde UML se queda corto. El diagrama de clase de UML se puede usar para modelar algunos aspectos del diseño de bases de datos relacionales, pero no cubre toda la semántica involucrada en el modelado relacional, mayoritariamente la noción de atributos clave que relacionan entre sí las tablas unas con otras. Para capturar esta información, un Diagrama de Relación de Entidad (ER diagram) se recomienda como extensión a UML.
El Diagrama de Clase se puede usar para modelar la estructura lógica de la base de datos, independientemente de si es orientada a objetos o relacional, con clases representando tablas, y atributos de clase representando columnas. Si una base de datos relacional es el método de implementación escogido, entonces el diagrama de clase puede ser referenciados a un diagrama de relación de entidad lógico. Las clases persistentes y sus atributos hacen referencia directamente a las entidades lógicas y a sus atributos; el modelador dispone de varias opciones sobre cómo inferir asociaciones en relaciones entre entidades. Las relaciones de
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
herencia son referenciadas directamente a super-sub relaciones entre entidades en un diagrama( ver fig. 43) de relación de entidad (ER diagram).
Figura 43: Extensión de UML -- Diseño de Bases de Datos Relacionales con el Diagrama de Relación de Entidad (ER Diagram)
Ya en el Diagrama de Relación de Entidad, el modelador puede empezar el proceso de determinar cómo el modelo relacional encaja; y qué atributos son claves primarias, claves secundarias, y claves externas basadas en relaciones con otras entidades. La idea es construir un modelo lógico que sea conforme a las reglas de normalización de datos. Al implementar el diseño relacional, es una estrategia encaminada a hacer referencia al diagrama de relación de entidad lógico a un diagrama físico que represente el objetivo, el RDBMS. El diagrama físico puede ser denormalizado para lograr un diseño de base de datos que tiene tiempos eficientes de acceso a los datos. Las relaciones super-sub entre entidades se resuelven por las estructuras de tablas actuales. Además, el diagrama físico se usa para modelar propiedades específicas de cada fabricante para el RDBMS. Se crean varios diagramas físicos si hay varios RDBMSs siendo 'deployed'; cada diagrama físico representa uno de los RDBMS que son nuestro objetivo. Ver fig. 44
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Figura 44: Relaciones clave entre entidades en un Diagrama de Relación de Entidad 2.7 Consultas orientadas a objetos
Los lenguajes de programación orientados a objetos requieren que toda la interacción con objetos sea mediante envío de mensajes. Esto presenta serias limitaciones en las aplicaciones de bases de datos. Considérese el ejemplo del diseño de sistema de computadores y la consulta “Encontrar todos los sistemas de computadores que utilicen chips vendidos por Oldblock Corporation”. Si seguimos estrictamente el modelo de la programación orientada a objetos, se deberá enviar un mensaje a cada instancia de la clase Chip para verificar su valor vendedor. Si tratáramos esta solicitud como un problema de la base de datos, esperaríamos que existiera un índice para la clase Chip para las cuales el campo vendedor fuera “Old-block Corporation”. La última forma de cómo se va a tratar la consulta corresponde a una vista relacional de la base de datos de objetos que vimos. De hecho, podríamos
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
plantear consultas que implicasen intersecciones de conjuntos de objetos. Sin embargo, la vista relacional de objetos está limitada a variables, y gran parte de que el modelo orientado a objetos sea tan atractivo se debe al uso de los métodos. Así, un lenguaje de consultas para un sistema de base de datos orientado a objetos debe incluir tanto el modelo de pasar el mensaje de objeto en objeto (un objeto cada vez) como el modelo de pasar el mensaje de conjunto en conjunto en conjunto (un conjunto cada vez). La mezcla del proceso con los dos modelos conduce a serias complicaciones en el diseño del lenguaje, a menudo conocido como “impedancia desajustada”.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
La intención de este modulo no es la de profundizar en cada una de estas reglas, el lector interesado en profundizar el tema puede hacerlo en la bibliografía recomendada4 o en la web.
4
Hernández Orallo y Otros, Introducción a la minería de datos.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Glosario de Términos de Data Mining
Algoritmos genéticos: Técnicas de optimización que usan procesos tales como combinación genética, mutación y selección natural en un diseño basado en los conceptos de evolución natural.
Análisis de series de tiempo (time-series): Análisis de una secuencia de medidas hechas a intervalos específicos. El tiempo es usualmente la dimensión dominante de los datos.
Análisis prospectivo de datos: Análisis de datos que predice futuras tendencias, comportamientos o eventos basado en datos históricos.
Análisis exploratorio de datos: Uso de técnicas estadísticas tanto gráficas como descriptivas para aprender acerca de la estructura de un conjunto de datos.
Análisis retrospectivo de datos: Análisis de datos que provee una visión de las tendencias , comportamientos o eventos basado en datos históricos.
Árbol de decisión: Estructura en forma de árbol que representa un conjunto de decisiones. Estas decisiones generan reglas para la clasificación de un conjunto de datos. Ver CART y CHAID.
Base de datos multidimensional: Base de datos diseñada para procesamiento analítico on-line (OLAP ). Estructurada como un hipercubo con un eje por dimensión.
CART Árboles de clasificación y regresión : Una técnica de árbol de decisión usada para la clasificación de un conjunto da datos. Provee un conjunto de reglas que se pueden aplicar a un nuevo (sin clasificar) conjunto de datos para predecir cuáles registros darán un cierto resultado. Segmenta un conjunto de datos creando 2 divisiones. Requiere menos preparación de datos que CHAID .
CHAID Detección de interacción automática de Chi cuadrado : Una técnica de árbol de decisión usada para la clasificación de un conjunto da datos. Provee un conjunto de reglas que se pueden aplicar a un nuevo (sin clasificar) conjunto de datos para predecir cuáles registros darán un cierto resultado. Segmenta un conjunto de datos utilizando tests de chi cuadrado para crear múltiples divisiones. Antecede, y requiere más preparación de datos, que CART.
Clasificación: Proceso de dividir un conjunto de datos en grupos mutuamente excluyentes de tal manera que cada miembro de un grupo esté lo "más cercano" posible a otro, y grupos diferentes estén lo "más lejos" posible uno del otro, donde la distancia está medida con respecto a variable(s) específica(s) las cuales se están tratando de predecir. Por ejemplo, un problema típico de clasificación es el de dividir una base de datos de compañías en grupos que
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
son lo más homogéneos posibles con respecto a variables como "posibilidades de crédito" con valores tales como "Bueno" y "Malo".
Clustering (agrupamiento): Proceso de dividir un conjunto de datos en grupos mutuamente excluyentes de tal manera que cada miembro de un grupo esté lo "más cercano" posible a otro, y grupos diferentes estén lo "más lejos" posible uno del otro, donde la distancia está medida con respecto a todas las variables disponibles.
Data cleansing: Proceso de asegurar que todos los valores en un conjunto de datos sean consistentes y correctamente registrados.
Data Mining: La extracción de información predecible escondida en grandes bases de datos.
Data Warehouse: Sistema para el almacenamiento y distribución de cantidades masivas de datos
Datos anormales: Datos que resultan de errores (por ej.: errores en el tipeado durante la carga) o que representan eventos inusuales.
Dimensión: En una base de datos relacional o plana, cada campo en un registro representa una dimensión. En una base de datos multidimensional , una dimensión es un conjunto de entidades similares; por ej.: una base de datos multidimensional de ventas podría incluir las dimensiones Producto, Tiempo y Ciudad.
Modelo analítico: Una estructura y proceso para analizar un conjunto de datos. Por ejemplo, un árbol de decisión es un modelo para la clasificación de un conjunto de datos
Modelo lineal: Un modelo analítico que asume relaciones lineales entre una variable seleccionada (dependiente) y sus predictores (variables independientes).
Modelo no lineal: Un modelo analítico que no asume una relación lineal en los coeficientes de las variables que son estudiadas.
Modelo predictivo: Estructura y proceso para predecir valores de variables especificadas en un conjunto de datos.
Navegación de datos: Proceso de visualizar diferentes dimensiones, "fetas" y niveles de una base de datos multidimensional . Ver OLAP .
OLAP Procesamiento analítico on-line (On Line Analitic prossesing): Se refiere a aplicaciones de bases de datos orientadas a array que permite a los usuarios ver, navegar, manipular y analizar bases de datos multidimensionales .
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Regresión lineal: Técnica estadística utilizada para encontrar la mejor relación lineal que encaja entre una variable seleccionada (dependiente) y sus predicados (variables independientes).
Regresión logística: Una regresión lineal que predice las proporciones de una variable seleccionada categórica, tal como Tipo de Consumidor, en una población.
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
FUENTES DOCUMENTALES
BATINI C.; Ceri S.; Navathe S. Diseño conceptual de bases de datos. Un enfoque de entidades-interrelaciones. 1994. Ed. Addison-Wesley. CASTAÑO A.; Piattini M. Fundamentos y modelos de bases de datos. 1999. Ed. Alfaomega. Segunda edición. CERI S, Pelagatti G.,Distributed databases principles & systems.. Ed. MacGraw-Hill. 1985. DATE, C. J, Introducción a los sistemas de bases de datos. Ed. Prentice Hall. Séptima edición. DORSEY, P, Hudicka Oracle8. Diseño de bases de datos con UML. J. Ed. Oracle press. 1999. KROENKE,D. Procesamiento de bases de datos. Fundamentos, diseño e implementación. 2003. Ed. Pearson Education. Octava edición SILVERSCHATZ, Korth y Sudarshan, Fundamentos de bases de datos, Ed MacGraw-Hill. Cuarta edición OTZU, Valduriez, Distributed databases, Ed. MacGraw-Hill. ULLMAN, J Principles of database systems, Ed. Computer science press, 1982. CIBERGRAFIA
www.lsi.us.es/docencia/asignaturas/dbd.html www.programación.net/sql.html www.cieloprogramadores.com www.rational.com. www.vico.org
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
ANEXO
Resultados de ejemplos referenciados en la sección 2 “Álgebra Relacional”
Chofer
Nombre
Teléfono
Dirección
Fecha_licenci Fecha_licenci Vigencia a_desde a_hasta
Cra 5 # 5-28 Cll 45 # 4545 Cll 1 # 30-43 Apto108 Int 4 Cra 5 # 65-18
01-01-2000 06-06-2004
31-12-2007 05-06-2011
S S
08-04-1990
07-04-1997
N
03-04-1995
02-04-2002
N
Rut 74123456 1472583
Juan Valdés 2147258 Pedro de la Rosa 5876932
97894561
Pedro Pérez
78945624
Gustavo Yacaman
3127845698
Dueño
Rut 74123456 97894561
Nombre Juan Valdés Pedro Pérez
Teléfono 2147258
Dirección Cra 5 # 5-28 Cll 1 # 30-43 Apto108 Int 4
Vigencia S N
98526341 1234568 5478978
Maria Ussa Luisa Fernández Luisa Suárez
6875421 3154758698 3004567892
Tr 4 # 5-9 Cll 34 # 120-13 Cll170 # 120-12
S S S
Móvil
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Patente HL-8483 NV-1214 NW-1500 AV-7898 CZ-0123
Marca Nissan Toyota Renault Renault Renault
Modelo Sentra Corolla Clio Megane 4
Año 1988 1978 2005 2003 1978
Rut_dueño
Rut_Chofer
74123456 74123456
74123456 97894561 74123456 74123456 97894561
1234568 5478978 5478978
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
El resultado de la operación Rut 74123456 98526341 1234568 5478978
es:
Nombre Juan Valdés Maria Ussa Luisa Fernández Luisa Suárez
El resultado de la operación Patente Marca HL-8483 Nissan
Teléfono 2147258 6875421 3154758698 3004567892
Dirección Cra 5 # 5-28 Tr 4 # 5-9 Cll 34 # 120-13 Cll170 # 120-12
es Modelo Sentra
Año 1988
, el resultado es Nombre Juan Valdés Pedro Pérez Maria Ussa Luisa Fernández Luisa Suárez
Dirección Cra 5 # 5-28 Cll 1 # 30-43 Apto108 Int 4 Tr 4 # 5-9 Cll 34 # 120-13 Cll170 # 120-12 :
Rut 74123456 1472583 97894561 78945624
Vigencia S S N N
Vigencia S S S S
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
Dueño X Móvil
Rut
Nombre
Teléfono
Dirección
74123 Juan Valdés 456 97894 Pedro Pérez 561
2147258
Cra 5 # 5-28
98526 341 12345 68 54789 78
Maria Ussa Luisa Fernández Luisa Suárez
Vigen Patente cia S HL-8483
Marca
Modelo
Año
Nissan
Sentra
1988
Cll 1 # 30-43 Apto108 Int 4 N
HL-8483
Nissan
Sentra
1988
6875421
Tr 4 # 5-9
S
HL-8483
Nissan
Sentra
1988
3154758698
Cll 34 # 120-13
S
HL-8483
Nissan
Sentra
1988
3004567892
Cll170 # 120-12
S
HL-8483
Nissan
Sentra
1988
74123 Juan Valdés 456 97894 Pedro Pérez 561
2147258
Cra 5 # 5-28
S
NV-1214
Toyota
Corolla
1978
Cll 1 # 30-43 Apto108 Int 4 N
NV-1214
Toyota
Corolla
1978
98526 341 12345 68 54789 78
Maria Ussa
6875421
Tr 4 # 5-9
S
NV-1214
Toyota
Corolla
1978
Luisa Fernández Luisa Suárez
3154758698
Cll 34 # 120-13
S
NV-1214
Toyota
Corolla
1978
3004567892
Cll170 # 120-12
S
NV-1214
Toyota
Corolla
1978
74123 Juan Valdés 456 97894 Pedro Pérez 561
2147258
Cra 5 # 5-28
S
NW-1500
Renault
Clio
2005
Cll 1 # 30-43 Apto108 Int N 4
NW-1500
Renault
Clio
2005
98526 Maria Ussa 341 12345 Luisa 68 Fernández
6875421
Tr 4 # 5-9
S
NW-1500
Renault
Clio
2005
3154758698
Cll 34 # 120-13
S
NW-1500
Renault
Clio
2005
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
54789 Luisa Suárez 78
3004567892
Cll170 # 120-12
S
NW-1500
Renault
Clio
2005
74123 Juan Valdés 456 97894 Pedro Pérez 561
2147258
Cra 5 # 5-28
S
AV-7898
Renault
Megane
2003
Cll 1 # 30-43 Apto108 Int 4 N
AV-7898
Renault
Megane
2003
98526 341 12345 68 54789 78
Maria Ussa
6875421
Tr 4 # 5-9
S
AV-7898
Renault
Megane
2003
Luisa Fernández Luisa Suárez
3154758698
Cll 34 # 120-13
S
AV-7898
Renault
Megane
2003
3004567892
Cll170 # 120-12
S
AV-7898
Renault
Megane
2003
74123 Juan Valdés 456 97894 Pedro Pérez 561
2147258
Cra 5 # 5-28
S
CZ-0123
Renault
4
1978
Cll 1 # 30-43 Apto108 Int 4 N
CZ-0123
Renault
4
1978
98526 341 12345 68 54789 78
Maria Ussa
6875421
Tr 4 # 5-9
S
CZ-0123
Renault
4
1978
Luisa Fernández Luisa Suárez
3154758698
Cll 34 #120-13
S
CZ-0123
Renault
4
1978
3004567892
Cll170 # 120-12
S
CZ-0123
Renault
4
1978
Patente HL-8483 NV-1214 NW-1500 AV-7898 CZ-0123
Marca Nissan Toyota Renault Renault Renault
Modelo Sentra Corolla Clio Megane 4
Año 1988 1978 2005 2003 1978
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
54789 Luisa Suárez 78
3004567892
Cll170 # 120-12
S
NW-1500
Renault
Clio
2005
74123 Juan Valdés 456 97894 Pedro Pérez 561
2147258
Cra 5 # 5-28
S
AV-7898
Renault
Megane
2003
Cll 1 # 30-43 Apto108 Int 4 N
AV-7898
Renault
Megane
2003
98526 341 12345 68 54789 78
Maria Ussa
6875421
Tr 4 # 5-9
S
AV-7898
Renault
Megane
2003
Luisa Fernández Luisa Suárez
3154758698
Cll 34 # 120-13
S
AV-7898
Renault
Megane
2003
3004567892
Cll170 # 120-12
S
AV-7898
Renault
Megane
2003
74123 Juan Valdés 456 97894 Pedro Pérez 561
2147258
Cra 5 # 5-28
S
CZ-0123
Renault
4
1978
Cll 1 # 30-43 Apto108 Int 4 N
CZ-0123
Renault
4
1978
98526 341 12345 68 54789 78
Maria Ussa
6875421
Tr 4 # 5-9
S
CZ-0123
Renault
4
1978
Luisa Fernández Luisa Suárez
3154758698
Cll 34 #120-13
S
CZ-0123
Renault
4
1978
3004567892
Cll170 # 120-12
S
CZ-0123
Renault
4
1978
Patente HL-8483 NV-1214 NW-1500 AV-7898 CZ-0123
Marca Nissan Toyota Renault Renault Renault
Modelo Sentra Corolla Clio Megane 4
Año 1988 1978 2005 2003 1978
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
(Dueño)
U Π rut, vigencia Π rut, vigencia El resultado de la operación unión es:
(Chofer)
Vigencia
Rut 74123456 1472583 97894561 78945624 98526341 1234568 5478978
S S N N S S S (Dueño)
rut, vigencia
rut, vigencia
(Chofer)
El resultado de la operación intersección es: Vigencia
Rut 74123456 97894561
S N (Dueño)
rut, vigencia
-
rut, vigencia
(Chofer)
UNIVERSIDAD NACIONAL ABIERTA Y A DISTANCIA FACULTAD DE CIENCIAS BÁSICAS E INGENIERÍA Programa de Ingeniería de Sistemas
(Dueño)
U Π rut, vigencia Π rut, vigencia El resultado de la operación unión es:
(Chofer)
Vigencia
Rut 74123456 1472583 97894561 78945624 98526341 1234568 5478978
S S N N S S S (Dueño)
rut, vigencia
rut, vigencia
(Chofer)
El resultado de la operación intersección es: Vigencia
Rut 74123456 97894561
S N (Dueño)
rut, vigencia
-
rut, vigencia
(Chofer)
El resultado de la operación diferencia es: Rut 98526341 1234568 5478978
Vigencia S S S
El resultado de la operación join es Rut Nombre Teléfono Dirección 741 Juan 2147258 Cra 5 # 5234 Valdés 28 56 741 Juan 2147258 Cra 5 # 5234 Valdés 28 56
123 456 8 547 897 8 547 897 8
Vigencia S
Patente Marca HL-8483 Nissan
Modelo Sentra
Año 1988
S
NV1214
Toyota
Corolla
1978
Luisa Fernánde z Luisa Suárez
3154758 Cll 34 # 698 120-13
S
NW1500
Renault Clio t
2005
3004567 Cll170 # 892 120-12
S
AV7898
Renault Megane
2003
Luisa Suárez
3004567 Cll170 # 892 120-12
S
AV7898
Renault Megane
2003
137