Sistemas de Bases de Datos Connolly Cap 21 en adelante(merged3)

  • 850 views
Uploaded on

Cap 1-20 en Un regalo http://www.slideshare.net/DebateInformaticaMaterias/cap-1-20completo-y-corregido-32864494 …

Cap 1-20 en Un regalo http://www.slideshare.net/DebateInformaticaMaterias/cap-1-20completo-y-corregido-32864494

More in: Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
850
On Slideshare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
84
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Capnulo Procesamiento de consultas Objetivos del capítulo: En este capítulo aprenderá: • Los objetivos del procesamiento de consultas y optimización. • Las diferencias entre la optimización de consultas estática y dinámica. • Cómo se descompone y se analiza semánticamente una consulta. • Cómo crear un árbol de álgebra relacional para representar una consulta. • Las reglas de equivalencia para las operaciones de álgebra relacional. • Cómo aplicar reglas de transformación heurística para mejorar la eficiencia de una consulta. • Los tipos de estadísticas de bases de datos requeridas para estimar el coste de las operaciones. • Las diferentes estrategias para implementar las operaciones de álgebra relacional. • Cómo evaluar el coste y el tamaño de las operaciones de álgebra relaciona!. • Cómo puede utilizarse el pipelining para mejorar la eficiencia de las consultas. • La diferencia entre materialización y pipelining. • Las ventajas de los árboles de profundidad izquierda. • Las técnicas para determinar una estrategia de ejecución óptima. • Cómo gestiona Oracle la optimización de consultas. Cuando se lanzó por primera vez comercialmente el modelo relacional, una de las principales críticas que se hacían era el pobre rendimiento de las consultas. Desde entonces, se ha dedicado una gran cantidad de esfuer- zos de investigación para desarrollar algoritmos altamente eficientes para el procesamiento de consultas. Hay muchas formas en las que se puede ejecutar una consulta compleja y uno de los objetivos de procesamiento de consultas es determinar cuál de esas formas es la menos costosa. En los sistemas de bases de datos en red y jerárquicos de primera generación, el lenguaje de consulta pro- cedimental de bajo nivel está generalmente incrustado en un lenguaje de programación de alto nivel tal como COBOL y es responsabilidad del programador seleccionar la estrategia de ejecución más apropiada. Por con- traste, con lenguajes declarativos del tipo de SQL, el usuario especifica qué datos se requieren en lugar de cómo hay que extraerlos. Esto libera al usuario de la responsabilidad de determinar, e incluso de conocer, qué es una buena estrategia de ejecución y hace que el lenguaje sea más universalmente utilizable. Adicionalmente, asignar al SGBD la responsabilidad de seleccionar la mejor estrategia evita que los usuarios seleccionen estrategias que ya se sabe que son ineficientes y proporciona al SGBD un mayor control sobre las prestaciones del sistema. Existen dos técnicas principales de optimización de consultas, aunque en la práctica se suelen combinar ambas estrategias. La primera técnica utiliza reglas heurísticas que ordenan las operaciones de una consulta. La otra técnica compara diferentes estrategias basándose en su coste relativo y selecciona aquella que mini-
  • 2. 576 Sistemas de bases de datos mice el uso de recursos. Puesto que el acceso a disco resulta lento comparado con el acceso a memoria, los accesos a disco tienden a representar el coste más importante del procesamiento de consultas en un SGBD centralizado, y es en este aspecto en el que nos vamos a concentrar exclusivamente en este capítulo a la hora de proporcionar estimaciones de coste. Estructura del capítulo En la Sección 21.1 se proporciona una panorámica del procesamiento de consultas y se examinan las fases principales de esta actividad. En la Sección 21.2 se examina la primera fase del procesamiento de consultas, que es la descomposición de la consulta, que transforma una consulta de alto nivel en una consulta de álgebra relacional y comprueba que ésta sea sintáctica y semánticamente correcta. En la Sección 21.3 exami- namos la técnica heurística de optimización de consultas, que ordena las operaciones de una consulta utili- zando reglas de transformación que se sabe generan buenas estrategias de ejecución. En la Sección 21.4 ana- lizaremos la técnica de estimación de costes para la optimización de consultas, que se basa en comparar diferentes estrategias basándose en sus costes relativos y seleccionar aquella que minimice el uso de recursos. En la Sección 21.5 hablaremos del pipelining, que es una técnica que puede utilizarse para mejorar todavía más el procesamiento de las consultas. El pipelining (o procesamiento en cadena) permite que se realicen diversas operaciones de forma paralela, en lugar de requerir que cada operación se complete antes de que la siguiente pueda comenzar. También explicaremos cómo puede un procesador de consultas típico seleccionar una estrategia de ejecución óptima. En la sección final, examinaremos brevemente cómo lleva a cabo Oracle la optimización de las consultas. En este capítulo nos vamos a concentrar en las técnicas de procesamiento y optimización de consultas en un SGBD relacional centralizado, ya que éste es el área que ha atraído la mayor parte de los esfuerzos de investigación y es el modelo en el que nos centramos a lo largo de todo el libro. Sin embargo, algunas de las técnicas tienen aplicación general en otros tipos de sistemas que dispongan de una interfaz de alto nivel. Posteriormente, en la Sección 23.7, examinaremos brevemente el procesamiento de consultas en un SGBD distribuido. En la Sección 28.5 veremos que algunas de las técnicas examinadas en este capítulo pueden requerir un análisis adicional para un SGBD objeto-relacional, que soporta consultas que contienen tipos defi- nidos por el usuario y funciones definidas por el usuario. El lector debe estar familiarizado con los conceptos tratados en la Sección 4.1 sobre el álgebra relacional y con los del Apéndice e referidos a los tipos de organización de archivos. Los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome descrito en la Sección 10.4 Y en el Apéndice A. 21.1 Panorámica del procesamiento de consultas Procesamiento de consultas Las actividades implicadas en el análisis sintáctico, la validación, la optimización y la ejecución de una consulta. Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecución correcta y eficiente expresada en un lenguaje de bajo nivel (implementación de álgebra relacional) y ejecutar la estrategia para extraer los datos requeridos. Optimización de consultas La actividad de seleccionar una estrategia de ejecución eficiente para el procesa- miento de una consulta. Un aspecto importante del procesamiento de consultas es la optimización de la consulta. Puesto que hay otras transformaciones equivalentes de la misma consulta de alto nivel, el objetivo de la optimización de consultas consiste en elegir aquella que minimice el uso de recursos. Generalmente, lo que intentaremos será reducir el tiempo total de ejecución de la consulta, que es la suma de los tiempos de ejecución de todas las operaciones individuales que componen la consulta (Selinger el al., 1979). Sin embargo, el uso de recursos también podría medirse según el tiempo de respuesta de la consulta, en cuyo caso nos concentraremos en maximizar el núme-
  • 3. Capítulo 21 Procesamiento de consultas 577 ro de operaciones paralelas (Valduriez y Gardarin, 1984). Puesto que el problema es computacionalmente intratable cuando el número de tablas es grande, la estrategia adoptada se reduce generalmente a encontrar una solución cercana a la óptima (Ibaraki y Kameda, 1984). Ambos métodos de optimización de consultas dependen de las estadísticas de la base de datos para eva- luar apropiadamente las diferentes opciones disponibles. La precisión y grado de actualización de dichas es- tadísticas tienen un gran impacto sobre la eficiencia de la estrategia de ejecución elegida. Las estadísticas recopilan información acerca de las relaciones, atributos e índices. Por ejemplo, el catálogo del sistema puede almacenar estadísticas que proporcionen la cardinalidad de las relaciones, el número de valores distintos que tiene cada atributo y el número de niveles de un índice multinivel (véase el Apéndice C.5A). Mantener las estadísticas actualizadas puede llegar a ser problemático. Si el SGBD actualizara las estadísticas cada vez que se inserta, actualiza o borra una tupla, esto tendría un impacto significativo sobre el rendimiento durante los picos de carga de trabajo. Otra alternativa generalmente preferible, consiste en actualizar las estadísticas de forma periódica, por ejemplo todas las noches, o siempre que el sistema esté inactivo. Otra solución adopta- da por algunos sistemas consiste en asignar a los usuarios la responsabilidad de indicar cuándo hay que actua- lizar las estadísticas. Hablaremos con más detalle de las estadísticas de las bases de datos en la Sección 2104.1. Como ilustración de los efectos que las diferentes estrategias de procesamiento tienen sobre el uso de recursos, vamos a comenzar con un ejemplo. I Ejemplo 21.1 Comparación de diferentes estrategias de procesamiento Hallar todos los gerentes que trabajen en una sucursal de Londres. Podemos escribir esta consulta en SQL como: SELECT * FROM Staff s, Branch b WHERE s.branchNo = b.branchNo AND (s.position = 'Manager' AND b.city = 'London'); Tres consultas de álgebra relacional equivalentes a esta instrucción SQL serían: (1) a(position~'Manager')Á (cit)='London')(Staff.branchNo~Branch.branchNoiStaffX Branch) (2) a(position~'Manager')Á (citY~'LOndOn,)(Staff~ Staff.branchNo~Branch.branchNoBranch) (3) (aposition~'Manager,(Staff))~ Staff.branchNo~Branch.branchNo(acitY~'LOndon,(Branch)) Para los propósitos de este ejemplo, vamos a suponer que hay 1000 tuplas en Staff, 50 tuplas en Branch, 50 empleados con categoría Manager (uno por cada sucursal) y 5 sucursales en Londres. Vamos a com- parar estas tres consultas basándonos en el número de accesos de disco requeridos. En aras a la sim- plicidad, vamos a suponer que no hay índices ni claves de relación en ninguna de las relaciones y que los resultados de cualquier operación intermedia se almacenan en el disco. El coste de la escritura final se ignorará, ya que es el mismo en los tres casos. Vamos a suponer también que se accede a las tuplas de una en una (aunque en la práctica los acceso a disco se basarían en bloques, cada uno de los cuales contendría normalmente varias tuplas) y que la memoria principal es lo suficientemente grande como para procesar relaciones completas para cada una de las operaciones de álgebra relaciona!. La primera consulta calcula el producto cartesiano de Staff y Branch, que requiere (1000 + 50) accesos a disco para leer las relaciones y crea una relación con (1000 * 50) tuplas. Después tendremos que leer cada una de estas tuplas de nuevo para comprobar si cumplen el predicado de selección, lo que impli- ca otros (1000 * 50) accesos a disco, dándonos un coste total de: (1000 + 50) + 2*(1000 * 50) = 101050 accesos a disco La segunda consulta combina Staff y Branch según el número de sucursal branchNo, lo que de nuevo requiere (1000 + 50) accesos a disco para leer cada una de las relaciones. Sabemos que la combinación de las dos relaciones tiene 1000 tuplas, una por cada empleado (un empleado sólo puede trabajar en
  • 4. 578 Sistemas de bases de datos una sucursal). En consecuencia, la operación de selección requiere 1000 accesos a disco para leer el resultado de la combinación, lo que nos da un coste total de: 2*1000 + (1000 + 50) = 3050 accesos a disco La última de las consultas lee primero cada tupla de 81aff para determinar si se trata de un empleado con categoría de Manager, lo que requiere 1000 accesos a disco y produce una relación con 50 tuplas. La segunda operación de selección lee cada tupla Branch para determinar cuáles son las sucursales de Londres, lo que requiere 50 accesos a disco y genera una relación con 5 tuplas. La operación final es la combinación de las relaciones 81aff y Branch reducidas, lo que requiere (50 + 5) accesos a disco, dando un coste total de: 1000 + 2*50 + 5+(50 + 5) = 1160 accesos a disco Claramente, la tercera es la mejor de las opciones en este caso, según un factor de 87:1. Si incremen- táramos el número de tuplas de 81aff a 10000 y el número de sucursales a 500, la mejora sería según un factor de aproximadamente 870: 1. Intuitivamente, cabía esperar esto desde el principio, ya que el pro- ducto cartesiano de las operaciones de combinación es mucho más costoso que la operación de selec- ción y la tercera de las operaciones de consulta reduce significativamente el tamaño de las relaciones que están siendo combinadas. Veremos en breve que una de las estrategias fundamentales del procesa- miento de consultas es realizar las operaciones unarias, las de selección y proyección, lo antes posible, reduciendo así el tamaño de los operandos para las subsiguientes operaciones binarias. El procesamiento de consultas puede dividirse en cuatro partes principales: descomposición (compuesta de análisis sintáctico y validación), optimización, generación de código y ejecución, como se ilustra en la Figura 21.1. En la Sección 21.2 vamos a examinar brevemente la primera de las fases, de descomposición, antes de volver nuestra atención hacia la segunda fase, la de optimización de consultas. Para completar esta panorámica, vamos a hablar brevemente de cuándo puede llevarse a cabo la optimización. Optimización dinámica y estática Existen dos opciones relativas a cuándo llevar a cabo las primeras tres fases del procesamiento de una consul- ta. Una de las opciones consiste en llevar a cabo dinámicamente la descomposición y la optimización cada vez que se ejecuta una consulta. La optimización dinámica de consultas tiene la ventaja de que toda la informa- ción requerida para seleccionar una estrategia óptima estará actualizada. Las desventajas son que la velocidad de la consulta se verá afectada debido a la necesidad de analizar sintácticamente, validar y optimizar la con- sulta antes de poder ejecutarla. Además, puede que sea necesario reducir el número de estrategias de ejecu- ción que hay que realizar, con el fin de conseguir que ese coste de procesamiento adicional sea aceptable, lo que a su vez puede tener el efecto de que se seleccione una estrategia significativamente inferior a la óptima. La opción alternativa consiste en efectuar una optimización estática de consultas, en la que las consultas son analizadas sintácticamente, validadas y optimizadas una sola vez. Esta técnica es similar a la que se uti- liza cuando se ejecuta un compilador de un lenguaje de programación. Las ventajas de la optimización está- tica son que se elimina el coste adicional de procesamiento en tiempo de ejecución y que puede haber más tiempo disponible para evaluar un mayor número de estrategias de ejecución, incrementándose así las posibi- lidades de encontrar una estrategia mejor. Para las consultas que se ejecutan muchas veces, tomarse un cierto tiempo adicional para encontrar un plan mejor puede proporcionar muchos beneficios. Las desventajas sur- gen del hecho de que la estrategia de ejecución que se selecciona como óptima en el momento de compilar la consulta puede haber dejado de ser óptima en el momento de ejecutarla. De todos modos, también puede emplearse una técnica híbrida para evitar esta desventaja, técnica que consiste en reoptimizar la consulta si el sistema detecta que las estadísticas de la base de datos han cambiado significativamente desde la última vez que se compiló la consulta. Alternativamente, el sistema podría compilar la consulta para la primera ejecución de cada sesión y luego almacenar en caché el plan óptimo durante el resto de la sesión, de modo que el coste se distribuya entre toda la sesión del SGBD.
  • 5. Capítulo 21 Procesamiento de consultas 579 Consulta en un lenguaje de alto nivel (generalmente SQL) Descomposición de la consulta Expresión de álgebra relacional oCatálogo del sistema Tiempo de compilación Optimización de la consulta Plan de ejecución Generación de código Código generado Ejecución de la consulta Salida de la consulta Figura 21.1. Fases del procesamiento de consultas. 21.2 Descomposición de consultas La descomposición de consultas es la primera fase del procesamiento de consultas. Los objetivos de la des- composición de consultas son transformar una consulta de alto nivel en una consulta de álgebra relacional y comprobar que la consulta sea sintáctica y semánticamente correcta. Las etapas típicas de la descomposición de consultas son el análisis, la normalización, el análisis semántico, la simplificación y la reestructuración de la consulta. (1) Análisis En esta etapa, se analiza la consulta léxica y sintácticamente utilizando las técnicas de los compiladores de los lenguajes de programación (véase, por ejemplo Aho y Ullman, 1977). Además, en esta etapa se verifica que las relaciones y atributos especificados en la consulta están definidos en el catálogo del sistema. Se verifica asimismo que todas las operaciones aplicadas a los objetos de la base de datos sean apropiadas para el tipo de objeto. Por ejemplo, considere la siguiente consulta: SELECT staffNumber FROM Staff WHERE position > 10; Esta consulta sería rechazada por dos motivos (1) En la lista de selección, el atributo staffNumber no está definido para la relación 8taff (debería ser staffNo). (2) En la cláusula WHERE, la comparación '>1O' es incompatible con el tipo de datos position, que es una cadena de caracteres de longitud variable.
  • 6. 580 Sistemas de bases de datos Completada esta etapa, la consulta de alto nivel habrá sido trasformada en algún tipo de representación interna más adecuada para su procesamiento. La forma interna que se suele elegir es algún tipo de árbol de consulta, que se construye de la forma siguiente: • Se crea un nodo hoja para cada relación base de la consulta. • Se crea un nodo no hoja para cada relación intermedia producida por una operación de álgebra relacio- na!. • La raíz del árbol representa el resultado de la consulta. • La secuencia de operaciones se dirige desde las hojas hacia la raíz. La Figura 21.2 muestra un ejemplo de un árbol de consulta para la instrucción SQL del Ejemplo 21.1 que utiliza el álgebra relacional en su representación interna. Nos referiremos a este tipo de árbol de consulta deno- minándolo árbol de álgebra relacional. (2) Normalización La etapa de normalización del procesamiento de consulta convierte la consulta en una forma normalizada que pueda manipularse más fácilmente. El predicado (en SQL, la condición WHERE), que puede ser arbitraria- mente complejo, puede convertirse a una de dos formas aplicando unas pocas reglas de transformación (Jarke y Koch, 1984): • Forma normal conjuntiva. Una secuencia de conjunciones conectadas mediante el operador / (AND). Cada conjunción contiene uno o más términos conectados mediante el operador v (OR). Por ejemplo: (position = 'Manager' v salary > 20000) / branchNo = '8003' Una selección conjuntiva contiene únicamente aquellas tuplas que satisfacen todas las conjunciones. • Forma normal disyuntiva. Una secuencia de disyunciones conectadas mediante el operador v (OR). Cada disyunción contiene uno o más términos conectados mediante el operador / (AND). Por ejemplo, podríamos reescribir la forma normal conjuntiva anterior como: (position = 'Manager' / branchNo = '8003' ) v (salary > 20000 / branchNo = '8003') Una selección disyuntiva contiene todas las tuplas formadas por la unión de todas las tuplas que satis- facen las disyunciones. (3) Análisis semántica El objetivo del análisis semántico es rechazar las consultas normalizadas que estén incorrectamente formula- das o que sean contradictorias. Una consulta estará incorrectamente formulada si sus componentes no contri- buyen a la generación del resultado, lo que puede suceder si faltan algunas especificaciones de combinación. Una consulta será contradictoria si su predicado no puede ser satisfecho por ninguna tupla. Por ejemplo, el predicado (position = 'Manager' / position = 'Assistant') para la relación Staff será contradictorio, ya que un empleado no puede ser a la vez Manager y Assistant. Sin embargo, el predicado ((position = 'Manager' / !><I s.branchNo=b.branchNo /~0s.position='Manager' 0b.city='London' i i Raiz iOperaciones intermedias i8taft Branch Hojas Figura 21.2. Ejemplo de árbol de álgebra relaciona!.
  • 7. Capítulo 21 Procesamiento de consultas 581 position = 'Assistant') v salary > 20000) podría simplificarse a (salary > 20000) interpretándose la cláusula con- tradictoria como el valor booleano FALSE. Desafortunadamente, la manera de gestionar las cláusulas contra- dictorias no es coherente entre un SGBD y otro. I Ejemplo 21.2 Comprobación de la corrección semántica Considere la siguiente consulta SQL: SELECT p.propertyNo, p.street FROM Client e, Viewing Y, PropertyForRent p WHERE c.c1ientNo = Y.clientNo AND c.maxRent >= 500 AND c.prefType = 'Flat' AND p.ownerNo = 'C093'; El grafo de conexión de relaciones mostrado en la Figura 21.3(a) no está completamente conectado, lo que implica que la consulta no está correctamente formulada. En este caso, hemos omitido la condi- ción de combinación (Y.propertyNo = p.propertyNo) del predicado. (a) 8·:·8 s· :·s(b) Figura 21.3. (a) Grafo de conexión de relaciones que muestra que la consulta está incorrectamente formulada; (b) grafo de conexión de atributos normalizado que muestra que la consulta es contradictoria.
  • 8. 582 Sistemas de bases de datos Ahora considere la consulta: SELECT p.propertyNo,p.street FROM Clientc, Viewingv, PropertyForRentp WHERE c.maxRent > 500 ANOc.clientNo= v.c1ientNoANO v.propertyNo= p.propertyNoANOc.prefType= 'Flat'ANOc.maxRent < 200; El grafo de conexión de atributos normalizado para esta consulta se muestra en la Figura 21.3(b), donde podemos ver que tiene un ciclo entre los nodos c.maxRent y O con una suma de evaluación nega- tiva, lo que indica que la consulta es contradictoria. Claramente, no podemos tener un cliente con un alquiler máximo que sea a la vez mayor de 500 euros e inferior a 200 euros. Sólo existen algoritmos para determinar la corrección para el subconjunto de consultas que no contengan disyunciones y negaciones. Para estas consultas, podemos aplicar las siguientes comprobaciones: (1) Construimos un grajo de conexión de relaciones (Wong y Youssefi, 1976). Si el grafo no está conec- tado, la consulta estará incorrectamente formulada. Para construir un grafo de conexión de relaciones, creamos un nodo por cada relación y otro nodo para el resultado. Después dibujamos aristas entre dos nodos para representar una combinación y aristas entre los nodos que representen el origen de las ope- raciones de proyección. (2) Construimos un grajo de conexión de atributos normalizado (Rosenlcrantz y Hunt, 1980). Si el grafo tiene un ciclo para el que la suma de evaluación sea negativa, la consulta sería contradictoria. Para construir un grafo de conexión de atributos normalizado, creamos un nodo por cada referencia a un atributo o para la constante O. Después creamos una arista dirigida entre los nodo s que representen una combinación y una arista dirigida entre un nodo de atributo y un nodo de constante O que represente una operación de selección. A continuación, ponderamos las aristas a ~ b con el valor c, si represen- ta la condición de desigualdad (a ::; b + c), y ponderamos las aristas O ~ a con el valor -c si repre- senta la condición de desigualdad (a :::::c). (4) Simplificación Los objetivos de la etapa de simplificación son detectar las cualificaciones redundantes, eliminar las subex- presiones comunes y transformar la consulta en otra consulta que sea semánticamente equivalente pero que se pueda calcular de forma más fácil y eficiente. Normalmente, las restricciones de acceso, las definiciones de vista y las restricciones de integridad se toman en consideración en esta etapa, pudiendo algunas de esas restricciones y definiciones introducir redundancia. Si el usuario no dispone de los derechos de acceso apro- piados a todos los componentes de la consulta, será necesario rechazar ésta. Suponiendo que el usuario tenga los privilegios de acceso apropiados, una optimización inicial consiste en aplicar las muy conocidas reglas de idempotencia de álgebra booleana, como son: pl(p)==p P 1 false ==false p 1 true ==p p 1 (~p) ==false pl(pvq)==p pv(P)==p p v false ==p p v true ==true p v (~p) ==true pv(plq)==p Por ejemplo, considere la siguiente definición de vista y la siguiente consulta realizada sobre la vista: CREATE VIEW Staff3AS SELECT staffNo,fName, IName,salary, branchNo FROM Staff WHERE branchNo = 'B003'; SELECT * FROM Staff3 WHERE (branchNo = 'B003'ANO salary > 20000);
  • 9. Capítulo 21 Procesamiento de consultas 583 Como hemos explicado en la Sección 6.4.3, durante la resolución de la vista esta consulta se transforma- rá en: SELECT staffNo, fName, IName, salary, branchNo FROM Staff WHERE (branchNo = 'B003'ANO salary > 20000) ANO branchNo = 'B003'; y la condición WHERE se reduce a (branchNo = 'B003' AND salary > 20000). También pueden aplicarse las restricciones de integridad para ayudar a simplificar las consultas. Por ejem- plo, considere la siguiente restricción de integridad, que garantiza que sólo los empleados con categoría de Manager tengan un salario superior a 20.000 euros: CREATE ASSERTION OnlyManagerSalaryHigh CHECK ((position <> 'Manager' AND salary < 20000) OR (position = 'Manager' AND salary > 20000)); Y considere el efecto sobre la consulta: SELECT * FROM Staff WHERE (position = 'Manager' AND salary < 15000); El predicado de la cláusula WHERE, que busca gerentes cuyo salario sea inferior a 15.000 euros, estará ahora en contradicción con la restricción de integridad, por lo que no puede haber ninguna tupla que satisfa- ga este predicado. (5) Reestructuración de la consulta En la etapa final de la descomposición de una consulta, la consulta se reestructura para obtener una imple- mentación más eficiente. Hablaremos más en detalle de la reestructuración en la sección siguiente. 21.3 Método heurístico de optimización de consultas En esta sección, vamos a examinar el método heurístico de optimización de consultas, que utiliza reglas de transformación para convertir una expresión de álgebra relacional en otra forma equivalente que se sepa que es más eficiente. Por ejemplo, en el Ejemplo 21.1 hemos observado que era más eficiente realizar la opera- ción de selección sobre una relación antes de utilizar dicha relación en una combinación, en lugar de efectuar primero la combinación y luego la selección. Veremos en la Sección 21.3.1 que existe una regla de transfor- mación que permite cambiar el orden de las operaciones de combinación y selección de modo que la selec- ción pueda realizarse primero. Habiendo explicado cuáles son las transformaciones válidas, en la Sección 21.3.2 presentaremos un conjunto de reglas heurísticas que se sabe que producen estrategias de ejecución 'buenas' (aunque no necesariamente óptimas). 21.3.1 Reglas de transformación para las operaciones de álgebra relacional Aplicando reglas de transformación, el optimizador puede transformar una expresión de álgebra relacional en otra expresión equivalente que se sabe que es más eficiente. Utilizaremos estas reglas para reestructurar el árbol de álgebra relacional (canónico) generado durante la descomposición de la consulta. El lector puede encontrar demostraciones de estas reglas en Aho el al. (1979). Al enumerar estas reglas, utilizaremos tres rela- ciones R, S Y T, estando R definida sobre los atributos A = {Al, Al, ... , An} Y S definida sobre B = {BI,Bl, ... , Bn}; p, q y r denotan predicados y L, LI, Ll, M, M¡, Ml Y N denotan conjuntos de atributos.~ (1) Las operaciones conjuntivas de selección pueden transformarse en una cascada de operaciones individuales de selección (y viceversa).
  • 10. 584 Sistemas de bases de datos Esta transformación se denomina en ocasiones cascada de selecciones. Por ejemplo: U branchNo='B003'ASalarY>15000(Staff) = UbranchNo='B003'(Usalary>15000(Staff)) (2) Conmutatividad de las operaciones de selección. up(uq(R)) = uq(up(R)) Por ejemplo: U branchNo='B003'Usalary>15000(Staff)) = U salary>15000(ubranchNo='B003,(Staff)) (3) En una secuencia de operaciones de proyección, sólo se requiere la última proyección de la secuencia. ITLITM' .. ITN(R) = ITL(R) Por ejemplo: ITrNameITbranchNo,IName(Staff) = ITrName(Staff) (4) Conmutatividad de la selección y la proyección. Si el predicado p implica sólo los atributos de la lista de proyección, entonces las operaciones de selec- ción y de proyección son conmutativas: nAf,.Am (up(R)) = Up(TlAf, .,Am (R)) donde p E {Af, A2' ... , Am) Por ejemplo: ITfName,IName(UlName='Beech,(Staff)) = UIName='Beech,(ITfName,IName(Staff)) (5) Conmutatividad de la combinación Theta (y del producto cartesiano). R [><Ip S = S [><Ip R RxS=SxR Puesto que la equicombinación y la combinación natural son casos especiales de la combinación Theta, entonces esta regla también se aplica a dichas operaciones de combinación. Por ejemplo, utilizando la equicombinación de Staff y Branch: 8taff C><Jstaff.branchNo=Branch.branchNo Branch Branch C><JStaff.branchNo=Branch.branchNo Staff (6) Conmutatividad de la selección y de la combinación Theta (o del producto cartesiano). Si el predicado de selección implica sólo atributos de una de las relaciones que están siendo combina- das, entonces las operaciones de selección y de combinación (o de producto cartesiano) son conmuta- tivas: up(R [><Ir S) = (up(R)) [><Ir S up(R X S) = (up(R)) X S donde P E {A1' A2' ... , An} Alternativamente, si el predicado de selección es un predicado conjuntivo de la forma (p 1 q), donde p implica sólo atributos de R y q implica sólo atributos de S, entonces las operaciones de selección y combinación Theta son conmutativas de la forma siguiente: upAq(R [><Ir S) = (up(R)) [><Ir (uq(S)) upAq(R X S) = (up(R)) X (uq(S)) PO~jemplo:
  • 11. Capítulo 21 Procesamientode consultas 585 (T position='Manager' Á city= 'London,(Staff C><JStaff.branchNo=Branch.branchNo Branch) = (JPOSitiOn='Manager,(Staff)) [><JStaff.branChNO=BranCh.branChNO (T citY='London,(Branch)) (7) Conmutatividad de la proyección y de la combinación Theta (sobre el producto cartesiano). Si la lista de proyección tiene la forma L = L¡ U Lz, donde LI implica sólo atributos de R y Lz implica sólo atributos de s, entonces si la condición de combinación sólo contiene atributos de L, las opera- ciones de proyección y de combinación Theta son conmutativas: IlL1 v dR C><Ic S) = (IlL1 (R)) C><Ic (IlL2(S)) Por ejemplo: Ilposition, city, branchNo(Staff [><JStaff.branchNo=Branch.branchNo Branch) = (Ilpos;t;on, bcanchNO(Staff)) C><IStaff.bcanchNo=Bcanch.bcanchNo (Ilc;ty, bcanchNo(Branch)) Si la condición de combinación contiene atributos adicionales que no estén en L, como, por ejemplo, los atributos M = MI U Mz, donde MI implica sólo atributos de R y Mzimplica sólo atributos de S, enton- ces se requiere una operación final de proyección: IlL1 vL2(R C><Ic S) = IlL1 vL2 IlL1 vM1 (R)) C><Ic (IlnL2VM2(S)) Por ejemplo: Ilposition, city(Staff [><]Staff.branchNo=Branch.branchNo Branch) = Ilposition, city( (Ilposition, branchNO(Staff)) C><JStaff.branchNo=Branch"branchNo (Ilcity, branchNO(Branch))) (8) Conmutatividad de la unión y la intersección (pero no de la diferencia de conjuntos). RuS=SuR RnS=SnR (9) Conmutatividad de la selección y de las operaciones de conjuntos (unión, intersección y diferen- cia de conjuntos). up(R u S) = up(S) u up(R) up(R n S) = up(S) U up(R) up(R - S) = up(S) - up(R) (10) Conmutatividad de la proyección y la unión. IlL(R u S) = IlL(S) u IlL(R) (11) Asociatividad de la combinación Theta (y del producto cartesiano). El producto cartesiano y la combinación natural son siempre asociativos: (R C><I S) C><I T = R C><I (S C><I T) (R x S) x T = R x (S x T) Si la condición de combinación q implica sólo atributos de las relaciones S and T, entonces la com- binación Theta es asociativa de la siguiente forma: (R C><IpS) C><IqAC T = R C><IPAC(S C><Iq T) Por ejemplo: ~ (Staff C><IStaff.staffNo=pcopertYFOCRentstaffNo PropertyForRent) C><IownerNo=Ownec.ownecNo AStaff.IName=OwnecIName Owner = Staff C><I Staff.staffNo=PcopertyForRentstaffNo AStaff.IName=IName (PropertyForRent ownecNo Owner)
  • 12. 586 Sistemas de bases de datos Observe que en este ejemplo sería incorrecto simplemente 'mover los paréntesis' ya que esto resul- taría en una referencia no definida (Staff.IName)en la condición de combinación entre PropertyForRent y Owner: PropertyForRent [><J PropertyForRent.ownerNo=Owner.ownerNo Á Staff.IName=Ow[1er.IName Owner (12) Asociatividad de la unión y la intersección (pero no de la diferencia de conjuntos). (R u S) uT = S u (R uT) (R n S) nT = S n (R nT) I Ejemplo 21.3 Utilización de las reglas de transformación Para los inquilinos en perspectiva que estén buscando apartamentos, localizar los inmuebles que satisfacen sus requisitos y son propiedad del propietario C093. Podemos escribir esta consulta en SQL como: SELECT p.propertyNo,p.street FROM Clientc, Viewingv, PropertyForRentp WHERE c.prefType= 'Flat' AND c.c1ientNo= v.c1ientNoAND v.propertyNo= p.propertyNoAND c.maxRent >= p.rent AND c.prefType= p.type AND p.ownerNo= 'C093'; Para los propósitos de este ejemplo, vamos a asumir que hay menos inmuebles propiedad del propie- tario C093 que inquilinos en perspectiva que hayan especificado como tipo preferido de inmueble el de apartamento (flat). Convirtiendo la instrucción SQL en álgebra relacional, tendremos: IIp,propertyNo, p,street( (J" c.prefTyp'Flat' 1 c.c1ientNo=v.c1ientNo 1 v.propertyNo=p.propertyNo 1 c.maxRent>=p.rent A c.prefType=p.type 1 p,ownerNO='C093'( (e xv) x p)) Podemos representar esta consulta mediante el árbol de álgebra relacional canónico que se muestra en la Figura 21.4(a). A continuación utilizamos las siguientes reglas de transformación para mejorar la efi- ciencia de la estrategia de ejecución: (1) (a) Regla 1, dividir la conjunción de operaciones de selección en operaciones de selección indivi- duales. (b) Regla 2 y Regla 6, reordenar las operaciones de selección y luego conmutar las selecciones y los productos cartesianos. El resultado de estas dos primeras etapas se muestra en la Figura 21.4(b). (2) Teniendo en cuenta lo explicado en la Sección 4.1.3, podemos reescribir una selección con un pre- dicado de equicombinación y una operación de producto cartesiano como una operación de equi- combinación, es decir: aRa=Sb(R X S) = R ~Ra=Sb S Aplicamos esta transformación en todos los lugares apropiados. El resultado de este paso se mues- tra en la Figura 21.4(c). (3) Regla 11, reordenación de las equicombinaciones de modo que la selección más restrictiva sobre (p.ownerNo = 'C093') se realice en primer lugar, como se muestra en la Figura 21.4(d). (4) Reglas 4 y 7, mediante las que movemos las proyecciones hacia abajo más allá de las equicombi- naciones y creamos nuevas operaciones de proyección según sea necesario. El resultado de aplicar estas reglas se muestra en la Figura 21.4( e). l.
  • 13. Capítulo 21 Procesamiento de consultas 587 rr p.propertyNo, p.street x P TI p.propertyNo, p.street 1 i pv e I °c.pretType='Flat' IIp.propertyNo, p.street i itx1 v.propertyNo=p.propertyNo 1t><Ic.ctientNo=v.clientNo °p.ownerNo='C093' 1 0c.maxRent>=p.rent" c.pretType=p.type 0c.prefType='Flar V !e 0c.c1ientNo=v.clientNo 0p.OwnerNO='C093' t0C,maxRent>=p.rent 1 c.prefType=p.type t °v.propertyNo=p.prOpertyNo t x /"- 1 x P r ve Dc.prefType='Flaf / c.ctientNo=v.clientNo 1 v.propertyNo=p.propertyNo 1 c.maxRent>=p.rent 1 c.prefTypeop.type tP.ownerNOO'C093' x 1 (a) (b) (e) rr p.propertyNo, p.street 0c.maxRent>=p.rent 1 c.prefType=p.type CXlv.propertyNo=p.propertyNo 0c.prefType='Flat' i ev i°c.maxRent>=p.rent ITp.propertyNo, p.street ! ! P (f) 0p.ownerNo='C093' 1 p.type='Flat' itx1c.clientNo=v.clientNo 1t><Iv.propertyNo=p.propertyNo IT c.clientNo, c.maxRent 1 I1p.propertyNo, p.street Ilv,propertyNo, 0c.prefType='Flat' p.rent v.clientNo e °c.prefType='Flar v 1 rIp.propertyNo, p.street i0c,maxRent>""p.rent 1 c.prefTypeo;;;p.type I ! p (e) °p.ownerNo='C093' i~c.clientNo=v.clientNo 1CXlv.propertyNo=p.propertyNo TI c.clientNo, c.maxRent, c.preffype IIp.propertyNo, p.street, TIv.propertyNo, p.rent, p.type v.clientNo e it:x:lc.c1ientNo=v.clientNo 1 p 1 ! (d) 0p.ownerNo='C093' V Figura 21.4. Árbol de álgebra relacional para el Ejemplo 21.3: (a) árbol canónico de álgebra relacional; (b) árbol de álgebra relacional formado al llevar las selecciones hacia abajo; (c) árbol de álgebra relacional formado al cambiar las selecciones/productos cartesianos por equicombinaciones; (d) árbol de álgebra relacional que se forma aplicando la regla de asociatividad de las equicombinaciones; (e) árbol de álgebra relacional que se forma llevando las proyecciones hacia abajo; (f) árbol final reducido de álgebra relacional que se forma sustiuyendo c.prefType = 'Flat' en la selección sobre p,type y llevando hacia" abajo del árbol la selección resultante.
  • 14. 588 Sistemas de bases de datos Una optimización adicional en este ejemplo concreto consiste en observar que la operación de selec- ción (c.preIType=p.type)puede reducirse a (p.type='Flat'), ya que sabemos que (c.preIType='Flat') de la primera cláusula del predicado. Utilizando esta sustitución, movemos esta selección hacia abajo en el árbol, lo que da como resultado el árbol final reducido de álgebra relacional que se muestra en la Figura 21.4(f). ~ 21.3.2 Estrategias de procesamiento heurística Muchos SGBD utilizan reglas heurísticas para determinar las estrategias de procesamiento de las consultas. En esta sección vamos a examinar algunas reglas heurísticas convenientes que pueden aplicarse para proce- sar las consultas. (1) Realizar las operaciones de selección lo antes posible. La selección reduce la cardinalidad de la relación y el subsiguiente procesamiento de dicha relación. Por tanto, debemos utilizar la regla 1para conectar en cascada las operaciones de selección y las reglas 2, 4, 6 y 9 referidas a las conmutatividad de la selección con las operaciones unarias y binarias, con el fin de mover las operaciones de selección lo más abajo posible en el árbol. Mantenga juntos los predi- cados de selección relativos a una misma relación. (2) Combinar el producto cartesiano con una operación de selección subsiguiente cuyo predicado represente una condición de combinación, para formar una operación de combinación. Ya hemos observado que podemos reescribir una selección con un predicado de combinación Theta y una operación de producto cartesiano como una operación de combinación Theta: (3) Utilizar la asociatividad de las operaciones binarias para reordenar los nodos hoja de modo que los nodos hoja con las operaciones de selección más restrictivas se ejecuten primero. De nuevo, la regla práctica consiste en realizar el máximo posible de reducciones antes de llevar a cabo las operaciones binarias. Así, si tenemos dos operaciones de combinación consecutivas que realizar: debemos emplear las reglas 11 y 12 relativas a la asociatividad de la combinación Theta (y de la unión e intersección) para reordenar las operaciones de modo que las relaciones que nos de la combinación más pequeña se calculen primero, lo que significa que la segunda combinación también estará basada en un primer operando más pequeño. (4) Realizar las operaciones de proyección lo antes posible. De nuevo, las operaciones de proyección reducen la cardinalidad de las relaciones y, por tanto, el sub- siguiente procesamiento de las mismas. Por tanto, debemos emplear la regla 3 para conectar en casca- da las operaciones de proyección y las reglas 4, 7 Y la referidas a la conmutatividad de la proyección y las operaciones binarias con el fin de mover las operaciones de proyección lo más abajo posible en el árbol. Hay que mantener juntos los atributos de proyección correspondientes a una misma relación. (5) Calcular una única vez las expresiones comunes. Si una expresión común aparece más de una vez en el árbol y el resultado que produce no es excesi- vamente grande, hay que almacenar el resultado después de haberlo calculado la primera vez y luego reutilizarlo cada vez que se requiera. Esto sólo representará una ventaja si el tamaño del resultado correspondiente a la expresión común es lo suficientemente pequeño como para almacenarlo en memo- ria principal o como para poder acceder a él en el almacenamiento secundario con un coste inferior al de recalcular el resultado. Esto puede ser especialmente útil cuando se efectúan consultas sobre las vis- tas, puesto que puede utilizarse la misma expresión para calcular la vista cada vez.
  • 15. Capítulo 21 Procesamiento de consultas 589 En la Sección 23.7 mostraremos cómo pueden aplicarse estas reglas heurísticas a las consultas distribui- das. En la Sección 28.5 se mostrará que algunas de estas reglas heurísticas pueden requerir un análisis adicio- nal para los SGBD objeto-relacionales, que soportan consultas que contienen tipos definidos por el usuario y funciones definidas por el usuario. 21.4 Estimación de costes para las operaciones de álgebra relacional Un SGBD puede tener muchas formas distintas de implementar las operaciones de álgebra relacional. El obje- tivo de la optimización de consultas consiste en seleccionar la más eficiente. Para ello, utilice fórmulas que estiman los costes para una serie de opciones y seleccione aquella que tenga el coste menor. En esta sección vamos a examinar las diferentes opciones disponibles para implementar las principales operaciones de álge- bra relacional. Para cada una de ellas, proporcionaremos una panorámica de la implementación y daremos un coste estimado. Puesto que el coste dominante en el procesamiento de consultas es usualmente el de los acce- sos a disco, que son lentos comparados con los accesos a memoria, nos concentraremos exclusivamente en el coste de los accesos a disco dentro de las estimaciones proporcionadas. Cada estimación representa el núme- ro requerido de accesos a bloques de disco, excluyendo el coste de escribir la relación que se genera como resultado de la consulta. Muchas de las estimaciones de coste están basadas en la cardinalidad de la relación. Por tanto, puesto que necesitamos poder estimar la cardinalidad de las relaciones intermedias, también mostraremos algunas esti- maciones típicas que pueden deducirse para dichas cardinalidades. Comencemos esta sección examinando los tipos de estadísticas que el SGBD almacena en el catálogo del sistema para servir de ayuda durante la estima- ción de costes. 21.4.1 Estadísticas de la base de datos El éxito en la estimación del tamaño y el coste de las operaciones de álgebra relacional intermedias depende de la cantidad y grado de actualización de la información estadística guardada por el SGBD. Normalmente, esperamos que el SGBD sea capaz de mantener las siguientes informaciones en su catálogo del sistema: Para cada relación base R • nTuples(R): el número de tuplas (registros) en una relación R (es decir, su cardinalidad). • bFactor(R): el factor de bloqueo de R (es decir, el número de tuplas de R que caben en un bloque). • nBlocks(R): el número de bloques requeridos para almacenar R. Si las tuplas de R se almacenan físi- camente juntas, se cumplirá que: nBlocks(R) = [nTuples(R)/bFactor(R)] Utilizamos [x] para indicar que el resultado del cálculo se redondea al entero más bajo que sea igualo supenor ax. Para cada atributo A de la relación base R • nDistinctA(R): el número de valores distintos que aparecen para el atributo A en la relación R. • minA(R),maxA(R):los valores mínimo y máximo posibles para el atributo A en la relación R. • SCA(R):la cardinalidad de selección del atributo A en la relación R. Se trata del número medio de tuplas que satisfacen una condición de igualdad para el atributo A. Si asumimos que los valores de A están uniformemente distribuidos en R y que existe al menos un valor que satisface la condición, entonces: tI SCA (R) = [nTuples(R) / DistinctA (R)] si A es un atributo clave de R en caso contrario También podemos estimar la cardinalidad de selección para otras condiciones:
  • 16. 590 Sistemas de bases de datos [nTuples(R) * ((maxA(R) - c) /(maxA (R) - minA(R))] para la desigualdad (A > c) [nTuples(R) * ((c - maxA (R)) /(maxA (R) - minA(R))] para la desigualdad (A < c) SCA(R) = i[(nTUPleS(R) / nDistinctA (R)) * n] SC A(R) *SCs (R) SCA(R) +SCs (R) -SCA (R) * SCs (R) para A perteneciente a {cl, c2'·· ., cn} para (A ¡ B) para (A v B) Para cada índice multinivel 1 sobre el conjunto de atributos A • nLevelsA(I): el número de niveles de I. • nLfBlocksA(I): el número de bloques hoja de I. Mantener estas estadísticas actualizadas puede ser problemático. Si el SGBD actualiza las estadísticas cada vez que se inserta, actualiza o borra una tupla, esto tendrá un impacto significativo sobre las prestacio- nes en los momentos de mayor carga de trabajo. Una alternativa generalmente preferible consiste en que el SGBD actualice las estadísticas de forma periódica, por ejemplo durante la noche o cada vez que el sistema esté inactivo. Otro enfoque adoptado por algunos sistemas es hacer a los usuarios responsables de indicar que las estadísticas deben ser actualizadas. 21.4.2 Operación de selección (S = O"p(R» Como hemos dicho en la Sección 4.1.1, la operación de selección en el álgebra relacional funciona sobre una única relación R, y define una relación S que contiene únicamente aquellas tuplas de R que satisfacen el predicado especificado. El predicado puede ser simple, implicando la comparación de un atributo de R con un valor constante o con otro valor de atributo, y también puede ser compuesto, implicando más de una condición, combinándose las distintas condiciones mediante las conectivas lógicas ¡ (AND), v (OR) Y ~ (NOT). Existen diversas implementaciones distintas para la operación de selección, dependiendo de la estructura del archivo en que esté almacenada la relación y de si los atributos implicados en el predicado han sido indexados o se les ha aplicado una función hash. Las principales estrategias que vamos a conside- rar son: • búsqueda lineal (archivo desordenado, sin índice); • búsqueda binaria (archivo ordenado, sin índice); • igualdad de la clave hash; • condición de igualdad de la clave principal; • condición de desigualdad de la clave principal; • condición de igualdad en un índice (secundario) de clústering; • condición de igualdad en un índice (secundario) no de clústering; • condición de desigualdad en un índice secundario de tipo B+-tree. Los costes de cada una de estas estrategias se resumen en la Tabla 21.1. Estimación de la cardinalidad de la operación de selección Antes de considerar estas opciones, vamos a presentar primero estimaciones para el número esperado de tuplas y el número esperado de valores distintos de un atributo en la relación resultado S obtenida al efectuar la operación de selección sobre R. Generalmente, es bastante difícil proporcionar estimaciones precisas; sin embargo, si aceptamos las suposiciones tradicionales de simplificación que suponen que los valores de los atributos están uniformemente distribuidos dentro de su dominio y que los atributos son independientes, pode- mos usar las siguientes estimaciones: nTuples(S) = SCA(R) el predicado p es de la forma (A e x)
  • 17. Estrategias Capítulo 21 Procesamiento de consultas 591 Tabla 21.1. Resumen del coste estimado de E/S para las estrategias correspondientes a una operación de selección. Coste Búsqueda lineal (archivo desordenado, [nBlocks(R)/2], para una condición de igualdad sobre un atributo clave sin índice) nBlocks(R), en caso contrario Búsqueda binaria (archivo ordenado, [loginBlocks(R»], para una condición de igualdad sobre un atributo ordenado sin índice) [loginBlocks(R»] + [SCA(R)/bFactor(R)] - 1, en caso contrario Igualdad de la clave hash Condición de igualdad de la clave principal Condición de desigualdad de la clave principal Condición de igualdad en un índice (secundario) de clústering Condición de igualdad en un índice (secundario) no de clústering Condición de desigualdad en un índice secundario de tipo B+-tree 1, suponiendo que no se produzca desbordamiento nLevelsA(I) + 1 nLevelsA(I) + [nBlocks(R)/2] nLevelsA(I) + [SCA(R)/bFactor(R)] nLevelsA(I) + [nLfBlocksA(I)/2 nTuples(R)/2] Para cualquier atributo B *- A de s: {nTUPleS(S) nDistinctB (S) = [(nTuples(S) +nDistinctB (R»)/3] nDistinctB (R) si nTuples(S) < nDistinctB (R)/2 si nDistinctB (R)/2 :S: nTuples(s) :S: 2*nDistinctB (R) si nTuples(S) > 2*nDistinctB (R) Podemos calcular estimaciones más precisas si relajamos la suposición de la distribución uniforme de los valores, pero esto requiere el uso de información estadística más detallada, como, por ejemplo, histogramas y pasos de distribución (Piatetsky-Shapiro y Connell, 1984). Hablaremos brevemente de cómo utiliza Oracle los histogramas en la Sección 21.6.2. (1) Búsqueda lineal (archivo desordenado, sin índice) Con esta técnica, puede se necesario analizar cada tupla de cada bloque para determinar si satisface el predi- cado, como se ilustra en el algoritmo resumidos que se ilustra en la Figura 21.5. Esto se denomina algunas veces exploración completa de tabla. En el caso de una condición de igualdad sobre un atributo clave, si supo- nemos que las tuplas están uniformemente distribuidas por el archivo sólo hará falta, por término medio explorar la mitad de los bloques para encontrar una tupla específica, por lo que la estimación de costes será: [nBlocks(R)/2] Para cualquier otra condición, puede que sea necesario explorar el archivo completo, por lo que la estima- ción más general de coste será: nBlocks(R) (2) Búsqueda binaria (archivo ordenado, sin índice) Si el predicado tiene la forma (A = x) y el archivo está ordenado según el atributo A, que es también el atribu- to clave de la relación R, entonces la estimación de coste para la búsqueda será:
  • 18. 592 Sistemas de bases de datos // // Búsqueda lineal // El predicado predicate es la clave de búsqueda. // El archivo no está ordenado. Los bloques están numerados secuencialmente a partir de 1. // Devuelve una tabla de resultados que contiene las tuplas de R que satisfacen el predicado. // for i = 1 to nBlocks(R) { block = read_bJock(R, i); for j = 1 to nTuples(block) { if (block.tuple [j] satisfies predicate) then add tuple to result; // recorrer en bucle cada bloque // recorrer en bucle cada tupla del bloque i Figura 21.5. Algoritmo para búsqueda lineal. [log2(nBlocks(R))] El algoritmo para este tipo de búsqueda está esbozado en la Figura 21.6. Con carácter más general, la esti- mación de coste será: [log2(nBlocks(R))] + [SCA(R)/bFactor(R)] - 1 El primer término representa el coste de encontrar la primera tupla utilizando un método de búsqueda bina- ria. Esperamos que existan SCA(R)tuplas que satisfagan el predicado, las cuales ocuparán [SCA(R)/bFactor(R)] bloques, de los cuales uno ya ha sido extraído al localizar la primera tupla. (3) Igualdad de la clave hash Si el atributo A es la clave hash, aplicamos el algoritmo hash para calcular la dirección correspondiente a la tupla. Si no hay ningún desbordamiento, el coste esperado será 1. Si hay desbordamiento, puede que sean necesarios accesos adicionales, dependiendo de la cantidad de desbordamiento y del medio para gestionarlo. (4) Condición de igualdad de la clave principal Si el predicado implica una condición de igualdad para la clave principal (A = x), podemos utilizar el índice principal para extraer la única tupla que satisface esta condición. En este caso, necesitaremos leer un bloque más que el número de accesos de índice, equivalente al número de niveles del índice, por lo que el coste esti- mado será: nLevelsA(I) + 1 (5) Condición de desigualdad de la clave principal Si el predicado implica una condición de desigualdad para la clave principal A (A < x, A <= x, A > x, A >= x), podemos primero utilizar el índice para localizar la tupla que satisface el predicado A = x. Suponiendo que el índice está ordenado, podrá accederse a las tuplas requeridas leyendo todas las tuplas situadas antes o después de esta tupla que hemos localizado. Suponiendo una distribución uniforme, cabría esperar que la mitad de las tuplas satisfagan la desigualdad, por lo que el coste estimado será: nLevelsA(I) = [nBlocks(R)/2] (6) Condición de igualdad en un índice (secundario) de clústering Si el predicado implica una condición de igualdad para el atributo A, que no es la clave principal pero propor- ciona un índice secundario de clústering, podemos utilizar el índice para extraer las tuplas requeridas. El coste estimado será:
  • 19. Capítulo 21 Procesamiento de consultas 593 // // Búsqueda binaria // El predicado predicate es la clave de búsqueda. // El archivo está ordenado según valores ascendentes de la clave de ordenación, A. // El archivo ocupa nBlocks bloques, numerados secuencialmente a partir de l. // Devuelve una variable booleana (found) que indica si se ha encontrado un registro que // se ajuste al predicado y una tabla de resultados en caso afirmativo. // next = 1; last = nBlocks; found = FALSE;keep_searching = TRUE; while (last >= 1 and (not found) and (keep_searching» { i = (next + last)/2; // la mitad del espacio de búsqueda block = read_block(R, i) ; if (predicate < orderinll-key_fie1d(firsCrecord(block») then // el registro se encuentra en la mitad inferior del área de búsqueda last=i-l; else if (predicate > orderinll-key_fie1d(last_record(block») then // el registro se encuentra en la mitad superior del área de búsqueda next= i + 1; e1seif (check_block_for_predicate(block, predicate, result» then // el registro requerido se encuentra en el bloque found = TRUE; e1se keep_searching = FALSE; // el registro no está ahí Figura 21.6. Algoritmo de búsqueda binaria en un archivo ordenado. nLevelsA(I) + [SCA(R)/bFactor(R)] El segundo término es una estimación del número de bloques que se requerirá para almacenar el número de tuplas que satisfacen la condición de igualdad, que hemos estimado como SCA(R). (7) Condición de igualdad en un índice (secundario) no de clústering Si el predicado implica una condición de igualdad para el atributo A, que no es la clave principal pero propor- ciona un índice secundario no de clústering, podemos utilizar el índice para extraer las tuplas requeridas. En este caso, tenemos que asumir que las tuplas se encuentran en diferentes bloques (el índice no tiene estructu- ra de clúster en este caso), por lo que el coste estimado será: (8) Condición de desigualdad en un índice secundario de tipo B+-tree Si el predicado implica una condición de desigualdad para el atributo A (A < x, A <= x, A > x, A >= x), que pro- porciona un índice secundario de tipo B+-tree, entonces a partir de los nodos hoja del árbol podemos explo- rar las claves desde el valor más pequeño hasta x (para condiciones < o <=) o desde x hasta el valor máximo (para condiciones> o >=). Suponiendo una distribución uniforme cabría esperar que haya que acceder a la mitad de los bloques de nodos hoja y a la mitad de las tuplas (a través del índice). El coste estimado será entonces: nLevelsA(I) + [nLfBlocksA(I)/2 + nTuples(R)/2] El algoritmo para explorar un índice B+-tree en busca de una única tupla se muestra en la Figura 21.7.
  • 20. ~' 594 Sistemas de bases de datos // // Búsqueda B+-tree // La estructura B+-tree está representada como una lista enlazada en la que cada nodo no hoja está estructurado como: // un máximo de n elementos, cada uno compuesto por: // un valor clave (key) y un puntero (P) a un nodo hijo (posiblemente NULL). // Las claves están ordenadas: keYl < keY2 < keY3 < ... < keYn_l // Los nodos hoja apuntan a las direcciones de los registros reales. // El predicado predicate es la clave de búsqueda. // Devuelve un valor booleano (jound) que indica si el registro ha sido encontrado y // la dirección (return_address) del registro, en caso afirmativo. // nade = gecrooCnodeO; while (node is not a leaf node) { i = 1; // localizar la clave que sea inferior al predicado while (not (i > n al' predicate < node[i].key)) { i= i+ 1; node = gecnexcnode(node[i] .pYinode[i].p apunta a un subárbol que puede contener un predicado. } // Se ha encontrado un nodo hoja, así que hay que comprobar si existe un registro con este predicado. i= 1; found = FALSE; while (not (found 01' i > n)) { if (predicate = node[i].key) then { found = TRUE; retufl1_address = node[i] .p; ese i= i+ 1; Figura 21.7. Algoritmo para explorar un árbol B+-tree en busca de una única tupla que se corresponda con un determinado valor. (9) Predicados compuestos Hasta ahora, hemos limitado nuestro análisis a predicados simples que sólo implican un atributo. Sin embar- go, en muchas-s-itQaciones el predicado puede ser compuesto, consistiendo en varias condiciones relativas a más de un atributo. Ya hemos observado en la Sección 21.2 que podemos expresar un predicado compuesto de dos formas: mediante la forma normal conjuntiva y mediante la forma normal disyuntiva: • Una selección conjuntiva contendrá únicamente aquellas tuplas que satisfagan todas las conjunciones . • Una selección disyuntiva contendrá aquellas tuplas formadas por la unión de todas las tuplas que satis- fagan todas las disyunciones. Selección conjuntiva sin disyunción Si el predicado compuesto no contiene ningún término de disyunción, podemos considerar las siguientes téc- lllcas: (1) Si uno de los atributos en una conjunción tiene un índice o está ordenado, podemos utilizar una de las estrategias de selección 2-8 explicadas anteriormente para extraer las tuplas que satisfagan dicha con-
  • 21. Capítulo 21 Procesamiento de consultas 595 dición. Después podemos comprobar si cada tupla extraída satisface las condiciones restantes del pre- dicado. (2) Si la selección implica una condición de igualdad sobre dos o más atributos y existe un índice com- puesto (o clave hash) sobre los atributos combinados, podemos explorar el índice directamente, como se ha explicado anteriormente. El tipo de índice determinará cuál de los algoritmos anteriores hay que utilizar. (3) Si hay índices secundarios definidos sobre uno o más atributos y, de nuevo, estos atributos están impli- cados únicamente en condiciones de igualdad dentro del predicado, entonces si los índices utilizan punteros de registro (un puntero de registro identifica unívocamente cada tupla y proporciona la direc- ción de la tupla al disco), en lugar de punteros de bloque, podemos explorar cada índice para encon- trar las tuplas que satisfagan una condición individual. Formando a continuación la intersección de todos los punteros extraídos, tenemos el conjunto de punteros que satisfacen las condiciones. Si no hay disponibles índices para todos los atributos, podemos comprobar si las tuplas extraídas cumplen las condiciones restantes. Selecciones con disyunción Si uno de los términos de la condición de selección contiene un v (OR) y el término requiere una búsqueda lineal porque no existe ningún índice u ordenación adecuado, toda la operación de selección requerirá una búsqueda lineal. Sólo si existe un índice u ordenación para cada término de la selección podremos optimizar la consulta extrayendo las tuplas que satisfagan cada condición y aplicando la operación de unión, como se explica más abajo en la Sección 21.4.5, operación que también permitirá eliminar los duplicados. De nuevo, pueden utilizarse punteros de registros, si es que existen. Si no puede utilizarse ningún atributo para extraer de manera eficiente las tuplas, empleamos el método de la búsqueda lineal y comprobamos todas las condiciones simultáneamente para cada tupla. A continuación vamos a ver un ejemplo para ilustrar el uso de la estimación con la operación de selección. I Ejemplo 21.4 Estimación de coste para una operación de selección Para los propósitos de este ejemplo, vamos a hacer las siguientes suposiciones acerca de la relación Staff: • Existe un índice hash sin desbordamiento sobre el atributo de clave principal staffNo. • Existe un índice de clústering sobre el atributo de clave externa branchNo. • Existe un índice B+-tree sobre el atributo salary. • La relación Stafftiene las siguientes estadísticas almacenadas en el catálogo del sistema: nTuples(Staff) = 3000 taff) = 30~nBlocks(Staff) = 100= 500~SCbranchNo(Staff)=6= 10~SCposition(Staff)= 300= 500~SCsalary(Staff) =6= 10.000maxsalary(Staff)= 50.000=2 alary(l) =2nLffilockssa'ary(I)= 50 El coste estimado de una búsqueda línea sobre el atributo clave staffNoes 50 bloques y el coste de una búsqueda lineal sobre un atributo no clave es de 100 bloques. A continuación, consideramos las siguien- tes operaciones de selección y utilizamos las estrategias anteriores para mejorar estos dos costes: SI: astaffNO='SG5,(Staff) S2: aPosition='Manager,(Staff)
  • 22. 596 Sistemas de bases de datos S3: abranchNo='B003,(Staff) S4: asalary>2oooo(Staff) S5: (J"position='Manager' A branchNo='B003,(Staff) SI: S2: S3: S4: S5: Esta operación de selección contiene una condición de igualdad sobre la clave principal. Por tanto, como el atributo staffNoestá almacenado con un método hash, podemos utilizar la estrategia 3 definida anteriormente para estimar el coste, que será de 1 bloque. La cardinalidad estimada de la relación resultante será SCstaffNo(Staff)= 1. El atributo del predicado es un atributo no clave y no indexado, por lo que no podemos mejorar el método de la búsqueda lineal, lo que nos da un coste estimado de 100 bloques. La cardinalidad estimada de la relación resultante será SCposition(Staff)= 300. El atributo del predicado es una clave externa con un índice de clústering, por lo que podemos uti- lizar la Estrategia 6 para estimar el coste, que será 2 + [6/30] = 3 bloques. La cardinalidad esti- mada de la relación resultante es SCbranchNO(Staff)= 6. Este predicado implica una búsqueda de rango sobre el atributo salary, que tiene un índice B+-tree, por lo que podemos utilizar la Estrategia 7 y estimar el coste como: 2 + [50/2] + [3000/2] = 1527 bloques. Sin embargo, esto es significativamente peor que la estrategia en búsqueda lineal, por lo que en este caso utilizaríamos el método de búsqueda lineal directamente. La cardinalidad esti- mada de la relación resultante será SCsalariStaff)= [3000*(50000-20000)/(50000-10000)] = 2250. En el último ejemplo, tenemos un predicado compuesto, pero la segunda condición puede imple- mentarse utilizando el índice de clústering sobre branchNo (el caso S3 anterior), que sabemos que tiene un coste estimado de 3 bloques. Mientras extraemos cada tupla utilizando el índice de clús- tering, podemos comprobar si satisface la primera condición (position= 'Manager'). Sabemos que la cardinalidad estimada de la segunda condición es SCbranchNO(Staff)= 6. Si denominamos a esta relación intermedia T, podemos estimar el número de valores distintos de position en T, nDistinctposition(T),como: [(6 + 10)/3] = 6. Aplicando ahora la segunda condición, la cardinalidad estimada de la relación resultante será SCposition(T)= 6/6 = 1, que sería correcta si hubiera un único gerente por cada sucursal. 21.4.3 Operación de combinación (T = (R t><1F S)) Hemos mencionado al principio de este capítulo que una de las principales preocupaciones cuando se lanzó por primera vez comercialmente el modelo relacional era el rendimiento de las consultas. En particular, la ope- ración que más preocupación suscitaba era la operación de combinación que, a parte del producto cartesia~o, es la más costosa en términos de tiempo de procesamiento, por lo que será necesario garantizar que se pueda ejecutar de la forma más eficiente posible. Recuerde, de la Sección 4.1.3, que la operación de combinación Theta define una relación que contiene tuplas que satisfacen un predicado específico F dentro del producto cartesiano de dos relaciones, por ejemplo R y s. El predicado F es de la forma R.a e S.b, donde e puede ser uno de los operadores lógicos de comparación. Si el predicado sólo contiene el operador de igualdad (=), la co,binación será una equicombinación. Si la combinación implica todos los atributos comunes de R y S, se denomina combinación natural. En esta sección, vamos a examinar las principales estrategias para implemen- &r la operación de combinación: • combinación mediante bucle anidado por bloques; • combinación de bucle anidado indexada; • combinación mediante ordenación-mezcla; • combinación hash.
  • 23. Capítulo 21 Procesamiento de consultas 597 Tabla 21.2. Resumen de las estimaciones de coste de E/R de las distintas estrategias para la operación de combinación. Estrategias Combinación mediante bucle anidado por bloques Combinación mediante bucle anidado indexado Combinación mediante ordenación-mezcla Combinación hash Coste nBlocks(R) + (nBlocks(R) * nBlocks(S)), si el búfer sólo tiene un bloque para R y S nBlocks(R) + [nBlocks(S)*(nBlocks(R)/(nBuffer - 2))], si hay (nBuffer - 2) bloques para R nBlocks(R) + nBlocks(S), si todos los bloques de R pueden leerse en el búfer de la base de datos Depende del método de indexación, por ejemplo: nBlocks(R) + nTuples(R)*(nLevelsA(I) + 1), si el atributo de combinación A en S es la clave principal nBlocks(R) + nTuples(R)*(nLevelsA(I) + [SCiR)IbFactor(R)]), para un índice de clús- tering 1 sobre el atributo A nBlocks(R)*[log2(nBlocks(R)] + nBlocks(S)*[logz(nBlocks(S)], para las ordenaciones nBlocks(R) + nBlocks(S), para las mezclas 3(nBlocks(R) + nBlocks(S», si el índice hash se almacena en memoria 2(nBlocks(R) + nBlocks(S))*[lognBlllTer_¡(nBlocks(S)) - 1] + nBlocks(R) + nBlocks(S), en caso contrario (3) Si ni A ni B son claves, podemos estimar la cardinalidad de la combinación como: El lector interesado puede encontrar un resumen más completo de las estrategias de combinación en Mishra y Eich (1992). Las estimaciones de coste para las diferentes estrategias aplicables a las operaciones de combinación se resumen en la Tabla 21.2. Comenzaremos estimando la cardinalidad de las operaciones de combinación. Estimación de la cardinalidad de la operación de combinación La cardinalidad del producto cartesiano de R y S, R x S, es simplemente: nTuples(R) * nTuples(S) Desafortunadamente, es mucho más difícil estimar la cardinalidad de cualquier combinación, ya que depende de la distribución de los valores de los atributos de combinación. En el caso peor, sabemos que la cardinalidad de la combinación no puede ser superior a la cardinalidad del producto cartesiano, por lo que: nTuples(T) ::; nTuples(R) * nTuples(S) Algunos sistemas utilizan esta cota superior, pero esta estimación es generalmente demasiado pesimista. Si volvemos a asumir una distribución uniforme de valores en ambas relaciones, podemos mejorar esta esti- mación para las equicombinaciones con un predicado (R.A = S.B) de la forma siguiente: (1) Si A es un atributo clave de R, entonces cada tupla de S sólo podrá ser combinada con una tupla de R. Por tanto, la cardinalidad de la equicombinación no puede ser superior a la cardinalidad de S: nTuples(T) ::; nTuples(S) el) De forma similar, si B es una clave de S, se cumplirá que: / nTuples(T)::; nTuples(R) / nTuples(T) = SCA(R)*nTuples(S)
  • 24. 598 Sistemas de bases de datos o nTuples(T) = SCB(S)*nTuples(R) Para obtener la primera estimación, usamos el hecho de que para cualquier tupla s en s, podemos esperar como media SCA(R)tuplas con un determinado valor del atributo A y que este mismo número aparezca en la combinación. Multiplicando esto por el número de tuplas de s, se obtiene la primera de las estimaciones ante- riores. Para la segunda estimación procederíamos de forma similar. (1) Combinación mediante bucle anidado por bloques El algoritmo de combinación más simple es un bucle anidado que combine las dos relaciones entre sí, una tupla cada vez. El bucle externo recorre todas las tuplas de la relación R y el bucle interno recorre todas las tuplas de la segunda relación, S. Sin embargo, como sabemos que la unidad básica de lectura/escritura es el bloque de disco, podemos mejorar el algoritmo básico teniendo dos bucles adicionales que procesen los blo- ques, como se indica en el algoritmo resumido de la Figura 21.8. Puesto que cada bloque de R debe ser leído y cada bloque de S debe ser también leído para cada bloque de R, el coste estimado de esta solución será: nBlocks(R) + (nBlocks(R) * nBlocks(S)) Con esta estimación, el segundo término es fijo, pero el primer término podría variar dependiendo de cuál relación se elija para el bucle externo. Obviamente, deberemos elegir para el bucle externo la relación que ocupe el número más pequeño de bloques. Otra mejora de esta estrategia consiste en leer tantos bloques como sea posible de la relación más peque- ña, por ejemplo R, en el búfer de la base de datos, guardando un bloque para la relación interna y otro para la relación resultante. Si el búfer puede albergar nBuffer bloques, entonces deberemos leer (nBuffer - 2) bloques de R en el búfer cada vez y un bloque de S. El número total de bloques de R al que se accede seguirá siendo nBlocks(R), pero el número total de bloques de S leídos se reduce a aproximadamente [nBlocks(S)* (nBlocks(R)/(nBuffer - 2))]. Con esta técnica, la nueva estimación de costes será: nBlocks(R) + [nBlocks(S)*(nBlocks(R)/(nBuffer - 2))] Si podemos leer todos los bloques de R y el búfer, esto se reduce a: nBlocks(R) + nBlocks(S) // // Combinación mediante bucle anidado por bloques // Los bloques en ambos archivos están numerados secuencialmente a partir de l. 1/ Devuelve una tabla de resultados que contiene la combinación de R y S. 1/ for iblock = 1 to nBlocks(R) { 1/ bucle externo Rblock = read_block(R, iblock); for jblock = 1 to nBlocks(S) { 1/ bucle interno Sblock = read_block(S, jblock); fJr i = 1 to nTuples(Rblock) { // for j = 1 to nTuples(Sblock) { iE(Rblock.tuple[i]!Sblock.tuple[j] match join condition) then add them to result; } Figura 21.8. Algoritmo para la combinación mediante bucle anidado por bloques.
  • 25. Capítulo 21 Procesamiento de consultas 599 Si los atributos de combinación en una equicombinación (o combinación natural) constituyen una clave de la relación interna, entonces el bucle interno puede terminar en cuanto se encuentre la primera corresponden- cia. (2) Combinación mediante bucle anidado indexado Si existe un índice (o función hash) sobre los atributos de combinación de la relación interna, podemos sus- tituir la ineficiente exploracíón del archivo por una búsqueda de índice. Para cada tupla en R, utilizamos el índice para extraer las tuplas correspondientes de s. El algoritmo de combinación por bucle animado indexa- do se esboza en la Figura 21.9. En aras a la claridad, utilizamos un algoritmo simplificado que procesa el bucle externo, de bloque en bloque. Sin embargo, como hemos indicado anteriormente, debemos leer tantos bloques de R en el búfer de base de datos como sea posible. Dejemos esta modificación del algoritmo como sea posi- ble. Dejamos esta modificación del algoritmo como ejercicio para el lector (véase el Ejercicio 21.19). Este algoritmo es mucho más eficiente para una combinación, evitándose con él la enumeración del pro- ducto cartesiano de R y s. El coste de explorar R es nBlocks(R), como antes. Sin embargo, el coste de extraer las tuplas correspondientes en S dependerá del tipo de índice y del número de tuplas correspondientes. Por ejemplo, si el atributo de combinación A de S es la clave principal, la estimación de coste se hará: nBlocks(R) + nTuples(R)*(nLevelsA(I) + 1) Si el atributo de combinación A en S es un índice de clústering, la estimación de coste será: nBlocks(R) + nTuples(R)*(nLevelsA(I) + [SCA(R)/bFactor(R)]) (3) Combinación mediante ordenación-mezcla Para las equicombinaciones, la combinación más eficiente se consigue cuando ambas relaciones están orde- nadas según los atributos de combinación. En este caso, podemos buscar las tuplas apropiadas de R y S mez- clando las dos relaciones. Si no están ordenadas, puede llevarse a cabo una etapa de preprocesamiento para ordenarlas. Puesto que las relaciones están ordenadas, las tuplas con el mismo valor del atributo de combina- ción estarán necesariamente en orden consecutivo. Si asumimos que la combinación es de tipo muchos a muchos, es decir, que puede haber muchas tuplas tanto de R como de S con el mismo valor de combinación, y si asumimos que de cada conjunto de tuplas con el mismo valor de combinación puede caber en el búfer de la base de datos, entonces cada bloque de cada relación sólo tendrá que ser leído una vez. Por tanto, la esti- mación de costes para la combinación mediante ordenación-mezcla es: // // Combinación mediante bucle anidado indexado de R y S utilizando A como atributo de combinación // Suponga que hay un índice 1 sobre el atributo A de la relación S y que // hay m entrada de Úldice 1[1], 1[2], ... , I[m] con el valor indexado de la tupla R[i].A // Los bloques de R están numerados secuencialmente a partir de 1. // Devuelve una tabla de resultados que contiene la combinación de R y S. // or iblock = 1 to nBlocks(R) { Rblock read_block(R, iblock); for i = 1 to nTuples(Rblock) { for j = 1 to m { if (Rblock.tuple[i].A = I[j]) then add corresponding tuples to result; Figura 21.9. Algoritmo para la combinación mediante bucle anidado indexado.
  • 26. 600 Sistemas de bases de datos nBlocks(R) + nBlocks(S) Si es necesario ordenar una relación, por ejemplo R, tendríamos que añadir el coste de la ordenación, que podemos aproximar como: nBlocks(R)* [loglnBlocks(R))] En la Figura 21.10 se muestra un algoritmo resumido para la operación de combinación mediante ordena- ción-mezcla. (4) Combinación hash Para una combinación natural (o equicombinación) también puede utilizarse un algoritmo de combinación hash para calcular la combinación de dos relaciones R y S según el conjunto de atributos de combinación A. La idea que subyace a este algoritmo consiste en particionar las relaciones R y S utilizando alguna función hash que presente características de uniformidad y aleatoriedad. Cada partición equivalente para R y S debe contener el mismo valor de los atributos de combinación, aunque puede contener más de un valor. Por tanto, el algoritmo tiene que comprobar las particiones equivalentes para ver si tienen el mismo valor. Por ejemplo, // // Combinación mediante ordenación-mezcla de R y S según el atributo de combinación A // El algoritmo presupone que la combinación es de tipo muchos a muchos // Se omiten las lecturas por simplicidad // Primero se ordenan R y S (esto no es necesario si los archivos ya están ordenados según los atributos // de combinación) sort(R); sort(S); // Ahora se realiza la mezcla nextR = 1; nextS = 1; while (nextR <= nTuples(R) and nextS <= nTuples(S)) { join_value = R.tuples[nextR].A; // Se explora S hasta encontrar un valor inferior al valor actual de combinación while (S.tuples[nextS].A < join_value and nextS <= nTuples(S)) { nextS = nextS + 1; } // Puede que tengamos tuplas correspondientes de R y S. // Para cada tupla de S con el valor join_ value, hay que hacerla corresponder con cada tupla de R // que tenga el valor join_value. // (Se asume una combinación M:N) while (S.tuples[nextS].A = join_value and nextS <= nTuples(S)) { m = nextR; while (R.tuples[m].A = join_value and m <= nTuples(R)) { add matching tuples S.tuples[nextS] and R.tuples[m] to res~lt; m =m+ 1; nextS = nextS + 1; // Ya ~emos en~respondientes de R y S con el mismo valor join _value // Ahora localizamos la siguiente tupla de R con un valor diferente de combinación while (R.tuples[nextR].A = join_value and nextR <= nTuples(R)) { nextR = nextR + 1; Figura 21.10. Algoritmo para la combinación meOdianteordenación-mezcla.
  • 27. Capítulo 21 Procesamiento de consultas 601 si la relación R se particiona en R¡, R2' ... , RM Y la relación S en SI' S2, ... , SMutilizando una función hash hQ, entonces si By e son atributos de R y S respectivamente y h(RB) *- h(s.e), entonces RB *- s.e. Sin embar- go, si h(RB) = h(S.e), esto no implica necesariamente que RB = s.e, ya que puede haber diferentes valores que se asignen al mismo valor hash. La segunda fase, denominadafase de comprobación, lee cada una de las particiones de R por turno y para cada una de ellas trata de combinar las tuplas de la partición con las tuplas de la partición de S equivalente. Si se utiliza una combinación de bucle anidado para la segunda fase, emplearemos la partición más pequeña como bucle externo, por ejemplo R¡.Leeremos la partición completa R¡en memoria y a continuación se leerá cada bloque de la parición S¡ equivalente y se usará cada tupla para comprobar si R¡contiene tuplas corres- pondientes. Para mejorar la eficiencia, resulta común construir en memoria una tabla hash para cada partición R¡utilizando una segunda función hash, diferente de la función hash empleada para el particionamiento. El algoritmo para la combinación hash se esboza en la Figura 21.11. Podemos estimar el coste de la combina- ción hash como: 3(nBlocks(R) + nBlocks(S» Aquí estamos teniendo en cuenta que hay que leer R y S para particionarlas, escribir cada partición en disco y luego leer cada una de las particiones de R y S de nuevo para encontrar las tuplas correspondientes. Esta estimación es aproximada y no tiene en cuenta los desbordamientos que tengan lugar en una partición. 11 11Algoritmo de combinación hash 11 Se omiten las lecturas por simplicidad. 11 11 Se comienza particionando R y S. for i = 1 to nTuples(R) { hash_ value = hash_function(R.tuple[i] .A); add tuple R.tuple[i].A to the R partition corresponding to hash value, hash_value; for j = 1 to nTuples(S) { hash_value = hash_function(S.tuple[j).A); add tuple S.tuple[j).A to the S partition corresponding to hash value, hash_value; 11 Ahora se ejecuta la fase de comprobación (correspondencia). for ihash = 1 to M { read R partition corresponding to hash value ihash; RP = Rpartition[ihash]; for i = 1 to max_tuples_in_R_partition(RP) { 11 Construir un índice hash en memoria utilizando la función hash _function2( ), diferente de hash _function( ) new_hash = hash_function2(RP.tuple[i].A); add new_hash to in-memory hash index; 11 Exployar la partición S en busca de tuplas de R correspondientes = Spartition[ihash]; for j = 1 to max_tuples_in_S_partition(SP) { read S and probe hash table using hash_function2(SP.tuple[j].A); add all matching tuples to output; clear hash table to prepare for next partition; Figura 21.11. Algoritmo para una combinación hash.
  • 28. 602 Sistemas de bases de datos También presupone que el índice hash se pueda almacenar en memoria. Si no es así, el particionamiento de las relaciones no puede realizarse en una pasada y será necesario utilizar un algoritmo de particionamiento recursivo. En este caso, se puede demostrar que la estimación de costes es: 2(nBlocks(R) + nBlocks(S))*[lognBuffer_¡(nBlocks(S)) - 1] + nBlocks(R) + nBlocks(S) El lector interesado puede hallar una explicación más completa de los algoritmo s de combinación hash en Valduriez y Gardarin (1984), DeWitt el al. (1984) y DeWitt y Gerber (1985). En Shapiro (1986) se describe una serie de extensiones, incluyendo la combinación hash híbrida, y un estudio más reciente realizado por Da- vison y Graefe (1994) describe técnicas de combinación hash que pueden adaptarse a la memoria disponible. I Ejemplo 21.5 Estimación de coste para una operación de combinación Para los propósitos de este ejemplo, hacemos las siguientes suposiciones: • Hay índices hash separados sin desbordamiento para los atributos de clave principal staftNode 8taft y branchNo de Branch. • Hay 100 bloques de búfer de base de datos. • El catálogo del sistema contiene las siguientes estadísticas: nTuples(Staff) = 6000= 30=}nBlocks(Staff) = 200= 500= 50=}nBlocks(Branch) = 10= 100.000 ForRent) = 50=}nBlocks(PropertyForRent) = 2000 En la Tabla 21.3 se muestra una comparación de las anteriores cuatro estrategias para las dos combi- naciones siguientes: 11: 8taft [><J staffNo PropertyForRent J2: Branch [><J b,anchNo PropertyForRent Tabla 21.3. Coste de E/S estimado para las operaciones de combinación del Ejemplo 21.5. Estrategias J1J2Comentarios 400,20020,010El búfer sólo tiene un bloque de R y 84282NIDa(nBuffer --'-2) bloques para R2010Todos los bloques R caben en el búfer de la base de datos 6200510Claves hash Combinación mediante 25,80024,240Desordenadas 22002010Ordenadas 66006030La tabla hash cabe en memoria aTodos los bloques de R pueden leerse en el búfer. bNo se pueden leer todos los bloques de R en el búfer.
  • 29. Capítulo 21 Procesamiento de consultas 603 En ambos casos, sabemos que la cardinalidad de la relación resultante no puede ser mayor que la car- dinalidad de la primera relación, ya que estamos realizando una combinación sobre la clave de la pri- mera relación. Observe que ninguna de las estrategias es la mejor para ambas operaciones de combinación. La combinación mediante ordenación-mezcla funciona mejor para la primera combina- ción, dando por supuesto que ambas relaciones ya están ordenadas. Para la segunda combinación la mejor estrategia es la de combinación mediante bucle anidado indexado. 21.4.4 Operación de proyección (5 = TIA" Au """,AJR)) La operación de proyección es también una operación unaria que define una relación S que contiene un sub- conjunto vertical de una relación R, extrayendo los valores de los atributos especificados y eliminando los duplicados. Por tanto, para implementar una proyección, debemos llevar a cabo los siguientes pasos: (l) eliminar los atributos no requeridos; (2) eliminar cualesquiera tuplas duplicadas que hayan resultado del paso anterior. El segundo paso es el más problemático, aunque sólo es necesario si los atributos de proyección no inclu- yen ninguna clave de la relación. Hay dos técnicas principales para eliminar los duplicados: la ordenación y las funciones hash. Antes de considerar estas dos técnicas, estimemos primero la cardinalidad de la relación resultante. Estimación de la cardinalidad de la operación de proyección Cuando la proyección contiene un atributo clave, como no se requerirá la eliminación de duplicados, la car- dinalidad de la proyección será: nTuples(S) = nTuples(R) Si la proyección consiste en un único atributo no clave (S = IIA(R)), podemos estimar la cardinalidad de la proyección como: nTuples(S) = SCA(R) En caso contrario, si asumimos que la relación es un producto cartesiano de los valores de sus atributos, lo que en general es poco realista, podemos estimar la cardinalidad como: m nTuples(s) :::;min(nTuples(R), II nDistinct A(R))i=! I (1) Eliminación de los duplicados mediante ordenación El objetivo de esta técnica es ordenar las tuplas de la relación reducida utilizando todos los atributos restan- tes como clave de ordenación. Esto tiene el efecto de ordenar las tuplas de tal forma que los duplicados serán adyacentes y podrán eliminarse fácilmente a continuación. Para eliminar los atributos no deseados, tenemos que leer todas las tuplas de R y copiar los atributos requeridos a una relación temporal, lo que representa un coste nBlocks(R). El coste estimado de la ordenación es nBlocks(R)*[10g2(nBlocks(R))], por lo que el coste total será: nBlocks(R) + nBlocks(R)*[log2(nBlocks(R))] En la Figura 21.12 se muestra un resumen del algoritmo correspondiente a esta técnica.
  • 30. 604 Sistemas de bases de datos 11 11 Proyección mediante ordenación 11 Suponemos que se está proyectando la relación R sobre los atributos aJ, a2, ... , 3m. 11 Devuelve la relación resultante S 11 11 Primero, se eliminan los atributos no deseados. for iblock = 1 to nBlocks(R) { block = read_block(R, iblock); for i = 1 to nTuples(block) { copy block.tuple[i].a¡, block.tuple[i].a2' ... , block.tuple[i].am, to output T 11 Ahora se ordena T en caso necesario. if {al' a2' ... , ami contains a key then S =T; else { sort(T); 11 Finalmente, se eliminan los duplicados. i= 1; j = 2; while (i <= nTuples(T)) { output T[i] to S; 11 Saltar los duplicados de esta tupla, si es que existen. while (T[i] = T[j]) { j = j + 1; i=j; j = i+ 1; Figura 21.12. Algoritmo de proyección mediante ordenación. (2) Eliminación de duplicados mediante funciones hash La técnica de las funciones hash puede ser útil si tenemos un gran número de bloques de búfer en relación con el número de bloques de R. Este método tiene dos fases: particionamiento y eliminación de duplicados. En la fase de particionamiento, asignamos un bloque de búfer para leer la relación R y (nBuffer - 1) blo- ques de búfer para la salida. Para cada tupla de R, eliminamos los atributos no deseados y luego aplicamos una función hash h a la combinación de los atributos restantes, escribiendo la tupla reducida en el valor hash. La función hash h debe regirse de modo tal que las tuplas estén uniformemente distribuidas entre las (nBuffer - 1) particiones. Dos tuplas que pertenezcan a particiones distintas no serán, evidentemente duplicados, ya que tienen diferentes valores hash, lo que reduce el área de búsqueda para eliminación de duplicados a las par- ticiones individuales. La segunda fase se lleva a cabo de la forma siguiente: • Se lee por turno cada una de las (nBuffer - 1) particiones. • Se aplica una segunda función hash (diferente de la anterior) h20 a cada tupla a medida que se la lee. • Se inserta el valor hash calculado en una tabla hash que se conserva en memoria. • Si la tupla tiene el mismo valor hash que alguna otra tupla, se comprueba si las dos son iguales y se elimina la nueva en caso de tratarse de un duplicado. • Una vez procesada una partición, se escriben las tuplas de la tabla hash en el archivo de resultados.
  • 31. Capítulo 21 Procesamiento de consultas 605 Si el número de bloques requeridos para la tabla temporal resultante de la proyección de R antes de la eli- minación de duplicados es nb, el coste estimado será: nBlocks(R) + nb Esto no incluye la escritura de la relación resultante y presupone que la aplicación de la función hash no requiere particiones de desbordamiento. Dejamos el desarrollo de este algoritmo como ejercicio para el lector. 21.4.5 Operaciones de conjuntos de álgebra relacional (T = R u S, T = R ( S, T = R - S) Las operaciones de conjuntos binarias de unión (R u s), intersección (R n S) y diferencia de conjuntos (R - S) sólo se aplican a las relaciones que sean compatibles con respecto a la unión (véase la Sección 4.1.2). Podemos implementar estas operaciones ordenando primero ambas relaciones con respecto a los mismos atri- butos y luego explorando cada una de las relaciones ordenadas una vez para obtener el resultado deseado. En el caso de la unión, introduciremos en el resultado todas las tuplas que aparezcan en alguna de las dos rela- ciones originales, eliminando los duplicados según sea necesario. En el caso de la intersección, sólo incluire- mos en el resultado aquellas tuplas que aparezcan en ambas relaciones. En el caso de la diferencia de conjun- tos, examinaremos cada tupla de R y la incluiremos en el resultado sólo si no tiene ninguna tupla correspondiente en s. Para todas estas operaciones, podríamos desarrollar un algoritmo empleando el algorit- mo de combinación mediante ordenación-mezcla como base. El coste estimado en todos los casos es simple- mente: nBlocks(R) + nBlocks(S) + nBlocks(R)*[logz(nBlocks(R))] + nBlocks(S)*[logz(nBlocks(S))] También podríamos utilizar un algoritmo hash para implementar estas operaciones. Por ejemplo, para la unión podríamos construir un índice hash en memoria para R y luego añadir las tuplas de S al índice hash sólo si no están ya presentes. Al final de esta fase añadiríamos las tuplas del índice hash al resultado. Estimación de la cardinalidad de las operaciones de conjuntos De nuevo, puesto que los duplicados se eliminan al realizar la operación de unión, generalmente es bastante dificil estimar la cardinalidad de la operación, pero podemos dar sendos límites inferior y superior, que serán: max(nTuples(R), nTuples(S)) :5 nTuples(T) :5 nTuples(R) + nTuples(S) Para la diferencia de conjuntos, también podemos dar unos límites superior e inferior: o :5 nTuples(T) :5 nTuples(R) Considere la siguiente consulta SQL, que permite calcular el salario medio de los empleados: SELECT AVG(salary) FROM Staff; Esta consulta utiliza la función de agregación AVG. Para implementar esta consulta, podríamos explorar la relación Staff completa y llevar la cuenta del número de tuplas leídas y de la suma de todos los salarios. Al completar la operación, resulta fácil calcular la media a partir de estos dos valores de totalización. Ahora considere la siguiente consulta SQL, que calcula el salario medio de los empleados en cada su- cursal: SELECT AVG(salary) FROM Staff GROUP BY branchNo; De nuevo, esta consulta utiliza la función de agregación AVG pero, en este caso, en conjunción con una cláusula de agrupación. Para las consultas de agrupación, podemos utilizar algoritmos de ordenación o de
  • 32. 606 Sistemas de bases de datos hash de forma similar para eliminar los duplicados. Podemos estimar la cardinalidad de la relación resultan- te en presencia de una agrupación utilizando las estimaciones que hemos calculado anteriormente para las operaciones de selección. Dejamos esto como ejercicio para el lector. 21.5 Numeración de las estrategias de ejecución alternativas Un aspecto fundamental para garantizar la eficiencia del proceso de optimización de consultas es el espacio de búsqueda de posibles estrategias de ejecución y el algoritmo de numeración que se utilice para explorar este espacio en búsqueda de una estrategia óptima. Para una consulta dada, este espacio puede ser extrema- damente grande. Por ejemplo, para una consulta que esté compuesta de tres combinaciones sobre las relacio- nes R, S Y T hay 12 diferentes ordenaciones posibles de combinación: RM(SMT) SM(RMT) TM(RMS) RM(TMS) SM(TMR) TM(SMR) (SMT)MR (RMT)MS (RMS)MT (TMS)MR (TMR)MS (SMR)MT En general, con n relaciones, hay (2(n - l))!/(n - l)! ordenaciones diferentes de las combinaciones. Si n es pequeña, este número es manejable; sin embargo, a medida que se incrementa n, este número se hace extre- madamente grande. Por ejemplo, si n = 4 el número de posibilidades es igual a 120; si n = 6 ese número es de 30.240; si n = 8, el número es superior a 17 millones y con n = 10, supera los 176.000 millones. Para agra- var todavía más el problema, el optimizador puede también soportar diferentes métodos de selección (por ejemplo, búsqueda lineal o búsqueda basada en índices) y métodos de combinación (por ejemplo, combina- ción mediante ordenación-mezcla, combinación hash, etc.). En esta sección, vamos a ver cómo puede redu- cirse el espacio de búsqueda y cómo se lo puede procesar de manera eficiente. Vamos a examinar primero dos cuestiones que tienen relevancia para nuestras explicaciones: el concepto de pipelining y los árboles lineales. 21.5.1 Pipelining En esta sección vamos a explicar otro concepto adicional que a veces se utiliza para mejorar las prestacio- nes de las consultas, el concepto de pipelining (algunas veces denominado procesamiento en cadena o pro- cesamiento de flujos). En los análisis que hemos realizado hasta ahora, hemos dado por supuesto que los resultados de las operaciones intermedias de álgebra relacional se escribían temporalmente en el disco. Este proceso se conoce con el nombre de materialización: la salida de una operación se almacena en una rela- ción temporal para ser procesada por la siguiente operación. Una técnica alternativa consiste en procesar en cadena los resultados de las distintas operaciones sin crear una relación temporal para almacenar el resulta- do intermedio. Obviamente, con esta técnica de pipelining podemos ahorramos el coste de crear relaciones temporales y volver a leer los resultados. Por ejemplo, al final de la Sección 21.4.2, hemos hablado de la implementación de la operación de selec- ción cuando el predicado era compuesto, como por ejemplo en: cr position='Managcr' Á salarY>2oo00(Staff) Si asumimos que hay un índice sobre el atributo salary, podríamos utilizar la regla de conexión en casca- da de operaciones de selección para transformar esta selección en dos operaciones: (JPOSitiOn=<Manager'( (Jsalary>2oo00(Staff)) Ahora, podemos utilizar el índice para procesar de manera eficiente la primera selección sobre salary, almacenar el resultado en una relación temporal y luego aplicar la segunda selección a la relación temporal. La técnica de procesamiento en cadena nos evita tener que crear la relación temporal y aplica en su lugar la segunda selección a cada tupla del resultado de la primera selección a medida que la generamos, añadiendo las tuplas que cumplan los criterios de la segunda operación al resultado final.
  • 33. Capítulo 21 Procesamiento de consultas 607 Por regla general, una cadena de procesamiento (pipelining) se implementa como un proceso separado o área de procesamiento dentro del SGBD. Cada cadena de procesamiento toma un flujo continuo de tuplas como entrada y crea un flujo de tuplas como salida. Es necesario crear un búfer para cada pareja de operacio- nes adyacentes con el fin de almacenar las tuplas que están siendo pasadas de la primera operación a la segun- da. Una desventaja de la técnica de pipelining es que las entradas necesarias para las distintas operaciones no necesariamente tienen que estar disponibles simultáneamente para su procesamiento. Esto puede restringir la elección de algoritmos. Por ejemplo, si tenemos una operación de combinación y las tuplas de entrada a la cadena de procesamiento no están ordenadas según los atributos de combinación, no podremos usil[ el algo- ritmo estándar de combinación mediante ordenación-mezcla. De todos modos, son muchas las oportunidades de aplicación de la técnica de pipelining en las estrategias de ejecución. 21.5.2 Árboles lineales Todos los árboles de álgebra relacional que hemos creado en las secciones anteriores en este capítulo son de la forma que se muestra en la Figura 21.13(a). Este tipo de árbol de álgebra relacional se denomina árbol (de combinación) de profundidad izquierda. El término hace referencia al modo en que las operaciones se com- binan para ejecutar la consulta: por ejemplo, sólo se permite que el lado izquierdo de una combinación sea el resultado de otra combinación anterior y de aquí el nombre de árbol de profundidad izquierda. Para un algo- ritmo de combinación, el nodo hijo de la izquierda es la relación externa y el nodo derecho es la relación inter- na. Otros tipos posibles de árbol son el árbol de profundidad derecha, mostrado en la Figura 21.13(b) y el arbusto, mostrado en la Figura 21.13(d) (Graefe y DeWitt, 1987). Los arbustos también se denominan árbo- les no lineales, mientras que los árboles de profundidad izquierda y profundidad derecha se conocen con el nombre de árboles lineales. La Figura 21. 13(c) es un ejemplo de otro árbollíneal que no es ni de profundi- dad izquierda ni de profundidad derecha. Con los árboles lineales, la relación en uno de los lados en cada operador es siempre una relación base. Sin embargo, como necesitamos examinar la relación interna completa para cada tupla de la relación externa, "" "" / /"" D D"" /"" e e"" /B AB (b) "" DeB /~"" "" / /ABA /"" D /"" /e (e) (d) Figura 21.13. (a) Árbol de profundidad izquierda; (b) árbol de profundidad derecha; (c) otro árbol lineal; (d) arbusto (no lineal).
  • 34. (4) IndexScan(R, A): (3) IndexScan(R, P): (1) TableScan(R): (2) SortScan(R, L): 608 Sistemas de bases de datos las relaciones internas deben siempre estar materializadas. Esto es lo que hace atractivos a los árboles de pro- fundidad izquierda, ya que las relaciones internas son siempre relaciones base (y por tanto están ya materia- lizadas). Los árboles de profundidad izquierda tienen las ventajas de reducir el espacio de búsqueda de la estrate- gia óptima y de permitir, por tanto, que el optimizador de consultas se base en técnicas de procesamiento diná- mico, como veremos en breve. Su principal desventaja es que, al reducir el espacio de búsqueda, no se tomen en consideración muchas estrategias de ejecución alternativas, algunas de las cuales pueden tener un coste inferior al que se haya podido determinar utilizando el árbol lineal. Los árboles de profundidad izquierda per- miten la generación de todas las estrategias completamente pipelinizadas, es decir, estrategias en las que todas las combinaciones se evalúan mediante la técnica de pipelining. 21.5.3 Operadores físicos y estrategias de ejecución El término operador físico se utiliza en ocasiones para referirse a un algoritmo específico que implemente una operación lógica de base de datos, como, por ejemplo, una selección o una combinación. Por ejemplo, podemos utilizar el operador físico de combinación mediante relación-mezcla para implementar la operación de combinación de álgebra relacional. Sustituir las operaciones lógicas en un árbol de álgebra relacional para operadores físicos produce una estrategia de ejecución (también denominada plan de evaluación de la con- sulta o plan de acceso) para la consulta. La Figura 21.14 muestra un árbol de álgebra relacional y una estra- tegia de ejecución correspondiente. Aunque los SGBD tienen sus propias implementaciones internas, podemos considerar los siguientes ope- radores abstractos para implementar las funciones correspondientes a las hojas del árbol: exploración de tabla. Todos los bloques de R se leen en un orden arbitrario. exploración ordenada. Las tuplas de R se leen por orden, ordenadas de acuerdo con los atributos enumerados en la lista L. exploración indexada. P es un predicado de la forma A e c, donde A es un atribu- to de R, e es uno de los operadores normales de comparación y c es un valor cons- tante. La forma de acceder a las tuplas de R es mediante un índice sobre el atri- buto A. exploración indexada. A es un atributo de R. Se extrae la relación completa R uti- lizando el índice definido sobre el atributo A. Es similar a TableScan, pero puede ser más eficiente bajo ciertas condiciones (por ejemplo, si R no utiliza clústeres). Además, el SGBD soporta usualmente una interfaz iteradora uniforme, ocultando así los detalles inter- nos de implementación de cada operador. La interfaz iteradora está compuesta de las siguientes tres fun- ClOnes: 7~""s.branchNo=b.branchNo PropertyForRent /~ O'~T-""" """T- Staff (a) Staff Branch Combinación hash ""s.staffNo=p.staffNo /, B+-tree sobreCombinación mediante / ~StaffNobucle anidado indexado 00" plp,!;,I'g 7~ Pmp'rty,,,",,1 Operación pipelining 0s.position='Manager" 0b.city='London' Operación utilizando el índice r r pipelining hash sobre position utilizando el índice hash Branch sobre city (b) Figura 21.14. (a) Ejemplo de árbol de álgebra relacional; (b) una estrategia de ejecución correspondiente.
  • 35. Capítulo 21 Procesamiento de consultas 609 (1) Open: esta función inicializa el estado del iterador antes de extraer la primera tupla y asigna búfe- res para las entradas y para las salidas. Sus argumentos pueden definir condiciones de selec- ción que modifiquen el comportamiento del operador (2) GetNext: esta función devuelve la siguiente tupla del resultado y la coloca en el búfer de salida. GetNext llama a GetNext en cada nodo de entrada y ejecuta algún código específico del ope- rador para procesar las entradas con el fin de generar las salidas. El estado del iterador se actualiza para reflejar cuántas entradas han sido consumidas. (3) Close: cuando todas las tuplas de salida han sido generadas (mediante llamadas repetidas a GetNext), la función Close termina el operador y realiza las tareas de limpieza final, desasignando los búferes según sea necesario. Cuando se utilizan iteradores, puede haber muchas operaciones activas simultáneamente. Las tuplas se pasan entre los operadores según sea necesario, soportando así de forma natural el concepto de pipelining. Sin embargo, la decisión de utilizar una cadena de procesamiento (pipelining) o de materializar los valores inter- medios depende del código específico del operador que procese las tuplas de entrada. Si este código permite procesar las tuplas de entrada a medida que se recibe, se utiliza pipelining. Si este código procesa las mismas tuplas de entrada más de una vez, se utiliza la técnica de materialización. 21.5.4 Reducción del espacio de búsqueda Como hemos mostrado al principio de esta sección, el espacio de búsqueda para una consulta complicada puede ser enorme. Para reducir el tamaño del espacio que la estrategia de búsqueda tiene que explorar, los optimizadores de consultas suelen restringir este espacio de diversas maneras. La primera de las restricciones comunes se aplica a las operaciones unarias de selección y proyección: Restricción 1: las operaciones unarias se procesan sobre la marcha: las selecciones se procesan a medi- da que se accede a las relaciones por primera vez; las proyecciones se procesan a me- dida que se generan los resultados de otras operaciones. Esto implica que todas las operaciones se tratan como parte de la ejecución de las combinaciones. Considere ahora la siguiente versión simplificada de la consulta del Ejemplo 21.3: SELECT p.propertyNo, p.street FROM Client e, Viewing v, PropertyForRent p WHERE c.clientNo =v.clientNo AND v.propertyNo = p.propertyNo; Teniendo en cuenta las explicaciones proporcionadas al principio de esta sección, hay 12 posibles ordena- ciones de las combinaciones para esta consulta. Sin embargo, observe que algunas de estas ordenaciones dan como resultado un producto cartesiano en lugar de una combinación. Por ejemplo: Viewing 1><1(Client 1><1PropertyForRent) da como resultado el producto cartesiano de Client y PropertyForRent. La siguiente reducción elimina los árbo- les de combinación subóptimos que incluyen un producto cartesiano: Restricción 2: nunca se forman productos cartesianos a menos que la propia consulta especifique uno. La última de las reducciones comunes se refiere a la forma de los árboles de combinación y, como se expli- ca en la Sección 21.5.2, utiliza el hecho de que con los árboles de profundidad izquierda el operando izquier- do es una relación base y, por tanto, ya está materializada: Restricción 3: el operando interno de cada combinación es siempre una relación base, nunca un resul- tando intermedio. Esta tercera restricción es de una naturaleza más heurística que las otras dos y excluye muchas estrategias alternativas, algunas de las cuales pueden tener un coste inferior al del de las que podemos encontrar utilizan- do el árbol de profundidad izquierda. Sin embargo, se suele considerar que el árbol de profundidad izquierda óptimo no resulta, en la mayoría de las ocasiones, mucho más caro que el árbol óptimo absoluto. Además, la
  • 36. 610 Sistemas de bases de datos tercera restricción reduce significativamente el número de estrategias de combinación alternativas que hay que considerar, que pasa a ser 0(2") para las consultas con n relaciones y tiene una complejidad asociada en términos de tiempo igual a 0(3"). Usando esta técnica, los optimizadores de consultas pueden manejar efi- cientemente combinaciones con unas 10 relaciones, lo que permite procesar la mayoría de las consultas que tienen lugar en las aplicaciones empresariales tradicionales. 21.5.5 Enumeración de árboles de profundidad izquierda La enumeración de árboles de profundidad izquierda mediante programación dinámica se propuso por pri- mera vez para el optimizador de consultas de System R (Selinger et al., 1979). Desde entonces, muchos sis- temas comerciales han utilizado esta técnica básica. En esta sección proporcionamos una panorámica del algo- ritmo, que es esencialmente un algoritmo de búsqueda exhaustiva con poda dinámica. El algoritmo de programación dinámica se basa en la suposición de que el modelo de costes satisface el principio de optirnalidad. Así, para obtener la estrategia óptima para una consulta consistente en n combina- ciones, sólo necesitamos considerar las estrategias óptimas para subexpresiones compuestas por (n - 1) com- binaciones y extender dichas estrategias con una combinación adicional. Las restantes estrategias sub óptimas pueden descartarse. El algoritmo reconoce, sin embargo, que en esta forma simple podrían llegar a descartar- se algunas estrategias potencialmente útiles. Considere la siguiente consulta: SELECT p.propertyNo, p.street FROM Client c, Viewing v, PropertyForRent p WHERE c.maxRent < 500 AND c.clientNo = v.clientNo AND v.propertyNo = p.propertyNo; Suponga que existen índices B+-tree separados sobre los atributos c1ientNo y maxRent de Client y que el opti- mizador soporta tanto combinaciones mediante ordenación-mezcla como combinaciones mediante bucles ani- dados de bloques. Al considerar todas las formas posibles de acceder a la relación Client, calcularíamos el coste de una búsqueda lineal en la relación y el coste de utilizar los dos índices de tipo B+-tree. Si la estrategia ópti- ma implicara utilizar el índice B+-tree sobre maxRent, descartaríamos entonces los otros dos métodos. Sin embargo, la utilización del índice B+-tree sobre c1ientNo daría como resultado que la relación Client se ordena- ra según el atributo de combinación clientNo, lo que nos daría un coste inferior para una combinación median- te ordenación-mezcla de Client y Viewing (ya que una de las relaciones ya está ordenada). Para garantizar que dichas posibilidades no se descarten, el algoritmo introduce el concepto de ordenaciones interesantes: un resultado intermedio tiene una ordenación interesante si está ordenado según un atributo ORDER BY final, según un atributo GROUP BY o según cualquier atributo que participe en combinaciones subsiguientes. Para nuestro ejemplo anterior, los atributos c.clientNo, v.c1ientNo, v.propertyNo y p.propertyNo son interesantes. Durante la optimización, si algún resultado intermedio está ordenado según alguno de estos atributos, la correspon- diente estrategia parcial deberá incluirse en la búsqueda. El algoritmo de programación dinámica lleva a cabo su tarea de abajo hacia arriba y construye todos los árboles de combinación alternativos que satisfacen las restricciones definidas en la sección anterior, operan- do de la forma siguiente: Pasada 1: enumeramos las estrategias para cada relación base utilizando una búsqueda lineal y todos los índi- ces disponibles para la relación. Estas estrategias parciales (para una única relación) se particionan en clases de equivalencia basándose en las ordenaciones interesantes, como hemos comentado anteriormente. Se crea también una clase de equivalencia adicional para las estrategias parciales que no tengan una ordenación inte- resante. Para cada clase de equivalencia, retenemos la estrategia de menor coste para tomada en considera- ción en la siguiente pasada. Si la estrategia de menor coste para la clase de equivalencia que carece de orde- naciones interesantes no es inferior a todas las demás estrategias, no la conservamos. Para una relación R dada, las selecciones que impliquen únicamente atributos de R se procesan sobre la marcha. De forma similar, tam- bién se puede procesar en esta etapa los atributos de R que no formen parte de la cláusula SELECT y que no contribuyan a ninguna combinación subsiguiente (véase la Restricción 1 anterior)
  • 37. Capítulo 21 Procesamiento de consultas 611 Pasada 2: generamos todas las estrategias para dos relaciones considerando cada una de las estrategias para una relación conservada después de la Pasada 1 como relación externa, descartando los productos cartesiano s generados (Restricción 2 anterior). De nuevo, realizamos cualquier procesamiento sobre la marcha que sea necesario y conservamos la estrategia de menor coste de cada clase de equivalencia para un análisis ulterior. Pasada k: generamos todas las estrategias para k relaciones considerando cada una de las estrategias que hayamos retenido después de la Pasada (k ~ 1) como relación externa, descartando de nuevo los productos cartesianos generados y procesando las selecciones y proyecciones sobre la marcha. De nuevo, retenemos la estrategia de menor coste de cada clase de equivalencia para un procesamiento ulterior. Pasada n: generamos todas las estrategias para n relaciones considerando como relación externa cada una de las estrategias que hayamos conservado después de la pasada (n - 1) Ydescartando los posibles productos car- tesianos que se hayan generado. Después de la poda, tendremos ahora la estrategia global de menor coste para un procesamiento de la consulta. Aunque este algoritmo sigue siendo exponencial, hay algunos tipos de consultas para los que sólo genera O(n3) estrategias, por lo que para n = 10 el número de estrategias es 1000, lo cual es significativamente mejor que los 176.000 millones de diferentes ordenaciones de combinaciones que habíamos visto al principio de esta sección. 21.5.6 Optimización semántica de consultas Otra técnica diferente para la optimización de consultas se basa en utilizar las restricciones especificadas en el esquema de la base de datos para reducir el espacio de búsqueda. Esta técnica, denominada optimización semántica de consultas, puede utilizarse en conjunción con las técnicas anteriormente explicadas. Por ejem- plo, en la Sección 6.2.5 hemos definido la restricción general que evita que un empleado gestione más de 100 inmueble s al mismo tiempo, utilizando la siguiente aserción: CREATE ASSERTION StaffNotHandlingTooMuch CHECK (NOT EXISTS (SELECT staffNo FROM PropertyForRent GROUP BY staffNo HAVING COUNT(*) > 100)) Considere ahora la siguiente consulta: SELECT s.staffNo, COUNT(*) FROM Staff s, PropertyForRent p WHERE s.staffNo = p.staffNo GROUP BY s.staffNo HAVING COUNT(*) > 100; Si el optimizador es consciente de esta restricción, puede evitarse tratando de optimizar la consulta, ya que no habrá ningún grupo que satisfaga la cláusula HAVING. Considere ahora la siguiente restricción sobre el salario de un empleado: CREATE ASSERTION ManagerSalary CHECK (salary > 20000 AND position = 'Manager') y la siguiente consulta: SELECT s.staffNo, fName, IName, propertyNo FROM Staff s, PropertyForRent p WHERE s.staffNo = p.staffNo AND position = 'Manager'; Utilizando la restricción anterior, podemos reescribir esta consulta como: SELECT s.staffNo, fName, IName, propertyNo
  • 38. 612 Sistemas de bases de datos FROM Staff s, PropertyForRent p WHERE s.staffNo" p.staffNo AND salary > 20000 AND position" 'Manager'; Este predicado adicional puede ser muy útil si el único índice para la relación Staff es un índice B+-tree sobre el atributo salary. Por otro lado, este predicado adicional complicaría la consulta si no existiera dicho índice. Para tener información adicional sobre la optimización semántica de consultas, el lector interesado puede consultar King (1981); Malley y Zdonik (1986); Chakravarthy et al. (1990); Siegel et al. (1992). 21.5.7 Técnicas alternativas de optimización de consultas La optimización de consultas es un campo en el que se han llevado a cabo numerosas investigaciones, habién- dose propuesto diversas alternativas al algoritmo de programación dinámica de System R. Por ejemplo, la téc- nica de templado simulado realiza una búsqueda en un grafo cuyos nodos están constituidos por estrategias de ejecución alternativas (esta técnica modela el proceso de templado mediante el que se pueden recrecer cris- tales, calentando primero el fluido que los contiene y luego dejándolo enfriarse lentamente). Cada nodo tiene un coste asociado y el objetivo del algoritmo es localizar un nodo con un coste global mínimo. Un movimien- to de un nodo a otro se considerará cuesta abajo (cuesta arriba) si el coste del nodo de origen es superior (infe- rior) al coste del nodo de destino. Un nodo será un mínimo local si para todas las rutas que dan comienzo en ese nodo cualquier movimiento cuesta abajo viene siempre precedido de un movimiento cuesta arriba. Un nodo será un mínimo global si tiene el menor coste de entre todos los nodos. El algoritmo realiza un paseo aleatorio continuo aceptando siempre los movimientos cuesta abajo y aceptando los movimientos cuesta arri- ba con un cierto valor de probabilidad, para tratar de no quedarse con un mínimo local de alto coste. La pro- babilidad de aceptar un movimiento cuesta arriba decrece con el tiempo y llega al final a ser cero, en cuyo momento se detiene la búsqueda y se devuelve como estrategia óptima de ejecución el nodo visitado que tenga el menor coste. El lector interesado puede consultar Kirkpatrick et al. (1983) y Ioannidis y Wong (1987). El algoritmo de mejora iterativa realiza una serie de optimizaciones locales, comenzando cada una de ellas en un nodo aleatorio y aceptando repetidamente movimientos cuesta abajo hasta que se alcanza un míni- mo local. El lector interesado puede consultar Swami y Gupta (1988) y Swami (1989). El algoritmo de opti- mización en dos fases es un híbrido del templado simulado y de la mejora iterativa. En la primera fase, se utiliza la mejora iterativa para realizar determinadas optimizaciones locales que dan como resultado algún mínimo local. Este mínimo local se utiliza como entrada para la segunda fase, que está basada en el templa- do simulado con una baja probabilidad de partida para los desplazamientos cuesta arriba. El lector interesado puede consultar Ioannidis y Kang (1990). Los algoritmo s genéticos, que simulan un fenómeno biológico, también se han aplicado a la optimización de consultas. Los algoritmos comienzan con una población inicial, compuesta por un conjunto aleatorio de estrategias, cada una de ellas con su propio coste. A partir de esta población inicial, se combinan pares de estrategias extraídas de esa población para generar descendientes que heredan las características de ambos padres, aunque esos descendientes pueden sufrir pequeñas modificaciones de forma aleatoria (mutación). Para la siguiente generación, el algoritmo retiene los padres/hijos de mínimo coste. El algoritmo termina cuando toda la población está compuesta por copias de la misma estrategia (óptima). El lector interesado puede con- sultar Bennett et al. (1991). El algoritmo heurístico A* se ha utilizado en inteligencia artificial para resolver problemas de búsqueda complejos y también se ha empleado en la optimización de consultas (Yoo y Lafortune, 1989). A diferencia del algoritmo de programación dinámica anteriormente explicado, el algoritmo A* expande una estrategia de ejecución cada vez, basándose en su proximidad a la estrategia óptima. Se ha demostrado que A * genera una estrategia completa mucho antes que la programación dinámica y es capaz de realizar la poda del árbol de bús- queda de manera mucho más agresiva. 21.5.8 Optimización distribuida de consultas En los Capítulos 22 y 23 hablaremos de los SGBD distribuidos (SGBDD), que están compuestos por una colección lógicamente interrelacionada de bases de datos distribuidas físicamente en una red informática y
  • 39. Capítulo 21 Procesamiento de consultas 613 cada una de ellas bajo control de un SGBD local. En un SGBDD, una relación puede dividirse en una serie de fragmentos distribuidos entre una serie de sistemas; esos fragmentos pueden ser replicados. En la Sección 23.6 veremos el tema de la optimización de consultas en un SGBDD. La optimización de consultas distribui- das es más compleja debido a la distribución de los datos entre los diferentes sitios de la red. En el entorno distribuido, además de los costes de procesamiento local (es decir, costes de procesador y de E/S), es necesa- rio tomar en consideración la velocidad de la red subyacente a la hora de comparar diferentes estrategias. En particular, analizaremos una extensión del algoritmo de programación dinámica de System R que hemos expuesto anteriormente, así como el algoritmo de optimización de consultas de otro proyecto de investigación sobre sistemas SGBDD muy conocido, denominado SDD-l. 21.6 Optimización de consultas en Oracle Para completar este capítulo, vamos a examinar los mecanismos de optimización de consultas utilizados en Oracle9i (Oracle Corporation, 2004b). Restringiremos nuestro análisis en esta sección a las técnicas de opti- mización basadas en tipos de datos primitivos. Posteriormente, en la Sección 28.5, veremos cómo proporcio- na Oracle un mecanismo de optimización ampliable para gestionar los tipos definidos por el usuario. En esta sección emplearemos la terminología Oracle, refiriéndonos a las relaciones mediante el término tabla y estan- do las tablas compuestas de columnas yfilas. En la Sección 8.2 el lector puede encontrar una introducción a Oracle. 21.6.1 Optimización basada en reglas y basada en costes Oracle soporta las técnicas de optimización de consultas que hemos expuesto en este capítulo: optimización basada en reglas y optimización basada en costes. El optimizador basado en reglas El optimizador basado en reglas de Oracle tiene 15 reglas, ordenadas según su eficiencia, como se muestra en la Tabla 21.4. El optimizador puede seleccionar la utilización de una ruta de acceso concreta a una tabla sólo si la instrucción contiene un predicado u otro tipo de estructura que haga que esa ruta de acceso esté dis- ponible. El optimizador basado en reglas asigna una puntuación a cada estrategia de ejecución utilizando estas clasificaciones y luego selecciona la estrategia de ejecución con la mejor puntuación (es decir, la más baja). Cuando dos estrategias tienen la misma puntuación, Oracle resuelve el empate tomando una decisión que depende del orden en que aparezcan las tablas dentro de la instrucción SQL, lo que no parece que sea una forma particularmente buena de tomar la decisión final. Por ejemplo, considere la siguiente consulta sobre la tabla PropertyForRent y suponga que tenemos un índi- ce sobre la clave principal, propertyNo, otro índice sobre la columna rooms y otro más sobre la columna city: SELECT propertyNo FROM PropertyForRent WHERE rooms > 7 AND city = 'London'; En este caso, el optimizador basado en reglas considerará las siguientes rutas de acceso: • Una ruta de acceso mono-columna utilizando el índice sobre la columna city de la condición WHERE (city = 'London'). Esta ruta de acceso tiene rango 9. • Una exploración de rango no limitado utilizando el índice sobre la columna rooms de la condición WHERE (rooms > 7). Esta ruta de acceso tiene rango 11. • Una exploración completa de tabla, que está disponible para todas las instrucciones SQL. Esta ruta de acceso tiene rango 15. Aunque hay un índice para la columna propertyNo, esta columna no aparece en la cláusula WHERE y el optimizador basado en reglas, como consecuencia, no la toma en consideración. Basándose en estas rutas, el optimizador basado en reglas decidirá utilizar el índice referido a la columna city. En la actualidad, la opti- mización basada en reglas está desaconsejada por Oracle.
  • 40. 614 Sistemas de bases de datos Tabla 21.4. Clasificaciones de la optimización basada en reglas. Rango 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Ruta de acceso Una sola fila basándose en ROWID (identificador de fila) Una sola fila basándose en combinación con clúster Una sola fila basándose en clave hash de clúster con clave unívoca o principal Una sola fila basándose en clave unívoca o principal Combinación clúster Clave hash con clúster Clave indexada con clúster Clave compuesta Índices mono-columna Búsqueda de rango limitado sobre columnas indexadas Búsqueda de rango no limitado sobre columnas indexadas Combinación mediante ordenación-mezcla MAX o MIN de columnas indexadas ORDER BY sobre columnas indexadas Exploración completa de tabla El optimizador basado en costes Para mejorar la optimización de las consultas, Oracle introduce el optimizador basado en costes en la versión Oracle 7; dicho optimizador selecciona la estrategia de ejecución que requiera el mínimo uso de recursos necesario para procesar todas las filas a las que accede la consulta (evitando la anomalía de los empates que antes hemos mencionado). El usuario puede seleccionar si el uso mínimo de recursos debe definirse basándo- se en la tasa de procesamiento (minimización de la cantidad de recursos necesaria para procesar todas las filas a las que accede la consulta) o basándose en el tiempo de respuesta (minimizar la cantidad de recursos nece- saria para procesar la primera fila a la que accede la consulta), configurando para ello el parámetro de inicia- lización OPTIMIZER _MODE. El optimizador basado en costes también toma en consideración las sugeren- cias que el usuario pueda proporcionar, como explicaremos a continuación. Estadísticas El optimizador basado en costes depende para su funcionamiento de las estadísticas disponibles para todas las tablas, clústeres e índices a los que accede la consulta. Sin embargo, Oracle no recopila estadísticas automá- ticamente, sino que deja en manos del usuario la responsabilidad de generar dichas estadísticas y mantener- las actualizadas. Puede utilizarse el paquete PL/SQL DBMS _STATS para generar y gestionar las estadísticas de las tablas, columnas, índices, particiones y los demás objetos de esquema de la base de datos. Siempre que sea posible, Oracle utiliza un método de procesamiento paralelo para recopilar las estadísticas, aunque las estadísticas de índice se recopilan en serie. Por ejemplo, podemos recopilar estadísticas para el esquema 'Manager' utilizando la siguiente instrucción SQL: EXECUTE DBMS _STATS.GATHER_SCHEMA _STATS('Manager', DBMS_STATS. AUTO_SAMPLE_SIZE); El último parámetro le dice a Oracle que debe determinar por sí mismo el mejor tamaño muestral para la obtención de unas buenas estadísticas. Hay una serie de opciones que pueden especificarse a la hora de recopilar estadísticas. Por ejemplo, pode- mos especificar si las estadísticas deben calcularse para la estructura de datos completa o sólo para una mues-
  • 41. Capítulo 21 Procesamiento de consultas 615 tra de los datos. En este último caso, se puede también especificar si el muestreo debe estar basado en filas o en bloques: • El muestreo basado en filas lee las filas ignorando su ubicación fisica en el disco. Como escenario de caso peor, el muestreo de filas podría seleccionar una única fila de cada bloque, requiriendo una explo- ración completa de la tabla o índice. • El muestreo de bloques lee una muestra aleatoria de bloques y genera las estadísticas utilizando todas las filas contenidas en esos bloques. Generalmente, el muestreo utiliza menos recursos que si se calcula el valor exacto para la estructura com- pleta. Por ejemplo, sí se analiza un 10% o menos de una tabla de tamaño muy grande podemos obtener los mismos porcentajes relativos de espacios no utilizados. También se puede hacer que Oracle recopile estadísticas al crear o reconstruir índices, especificando la opción COMPUTE STATlSTlCS en los comandos CREATE INDEX o ALTER INDEX. Las estadísticas se almacenan en el diccionario de datos de Oracle y pueden ser inspeccionadas mediante las vistas que se mues- tran en la Tabla 21.5. Cada vista puede estar precedida por tres prefijos: • ALL_ incluye todos los objetos de la base de datos a los que el usuario tiene acceso, incluyendo los obje- tos de otros esquemas a los que se haya concedido acceso al usuario. • DBA_ incluye todos los objetos de la base de datos. • USER_ incluye sólo los objetos del esquema del usuario. Sugerencias Como hemos mencionado anteriormente, el optimizador basado en costes también toma en consideración las sugerencias que el usuario pueda proporcionar. Una sugerencia se especifica como un comentario formatea- do de manera especial dentro de una instrucción SQL. Hay una serie de sugerencias que pueden emplearse para forzar al optimizador a tomar diferentes decisiones, como por ejemplo forzarle a utilizar: Tabla 21.5. Vistas del diccionario de datos de Oracle. Vista ALLJABLES TAB_HISTOGRAMS TAB COLUMNS TAB_COL_STATlSTlCS TAB]ARTITTONS CLUSTERS INDEXES IND_COLUMNS CONS COLUMNS CONSTRAINTS LOBS SEQUENCES SYNONYMS TRIGGERS VIEWS Descripción Información sobre los objetos y tablas relacionales a los que el usuario tiene acceso. Estadísticas sobre el uso de histogramas. Información sobre las columnas de las tablas/vistas. Estadísticas utilizadas por el optimizador basado en costes. Información sobre las particiones de una tabla particionada. Información sobre los clústeres. Información sobre los índices. Información sobre las columnas de cada índice. Información sobre las columnas de cada restricción. Información sobre las restricciones de las tablas. Información sobre las columnas con tipo de datos LOB (large object, objeto de gran tamaño). Información sobre los objetos de secuencia. Información sobre los sinónimos. Información sobre los disparadores de las tablas. Información sobre las vistas.
  • 42. 616 Sistemas de bases de datos • el optimizador basado en reglas; • una ruta de acceso concreta; • un orden de combinación concreto; • una operación de combinación concreta, como por ejemplo una combinación mediante ordenación- mezcla. Por ejemplo, podemos forzar la utilización de un índice concreto utilizando la siguiente sugerencia: SELECT /*+ INDEX(sexlndex) *j fName, IName, position FROMStaff WHERE sex = 'M'; Si hay tantos empleados de sexo masculino como femenino, la consulta devolverá aproximadamente la mitad de las filas de la tabla Staff y es probable que una exploración de tabla completa sea más eficiente que una exploración de índice. Sin embargo, si supiéramos que hay un número significativamente mayor de muje- res que de hombres, la consulta devolvería un pequeño porcentaje de las filas de la tabla Staff y es probable que la exploración mediante índice fuera más eficiente. Si el optimizador basado en costes asume que hay una distribución equitativa de valores en la columna sex, es probable que seleccione una exploración completa de tabla. En este caso, la sugerencia le dice al optimizador que debe utilizar el índice disponible sobre la colum- na sexo Planes de ejecución almacenados Hay muchas veces en las que se ha encontrado un plan óptimo y es innecesario o poco conveniente que el optimizador genere un nuevo plan de ejecución cada vez que se vuelva a ejecutar la instrucción SQL. En este caso, es posible crear un esbozo almacenado utilizando la instrucción CREATE OUTLINE, que almacenará los atributos utilizados por el optimizador para generar el plan de ejecución. A partir de ese momento, el opti- mizador empleará los atributos almacenados para crear el plan de ejecución en lugar de generar un nuevo plan cada vez. 21.6.2 Histogramas En las secciones anteriores, hemos hecho la suposición de que los valores de datos dentro de las columnas de una tabla estaban uniformemente distribuidos. Un histograma de valores junto con sus frecuencias relativas proporciona al optimizador unas estimaciones de selectividad mejores en presencia de una distribución no uniforme. Por ejemplo, la Figura 21.15(a) ilustra una distribución uniforme estimada para la columna rooms de la tabla PropertyForRent mientras que la Figura 21.15(b) muestra la distribución no uniforme real. La pri- mera distribución puede no almacenarse de forma bastante compacta mediante un valor inferior (1) y un valor superior (10) y un recuento total de todas las frecuencias (en este caso, 100). Para un predicado simple tal como rooms > 9, si nos basamos en una distribución uniforme podemos esti- mar fácilmente el número de tuplas del resultado, que será (1/10)*100 = 10 tuplas. Sin embargo, esta estima- ción es bastante imprecisa (como podemos ver en la Figura 21.15(b), sólo hay en realidad una tupla). Un histograma es una estructura de datos que puede utilizarse para mejorar dicha estimación. La Figura 21.16 muestra dos tipos de histograma: • un histograma con anchuras equilibradas, que divide los datos en un número fijo de rangos de igual anchura (denominados ranuras) y cada uno de los cuales contiene un recuento del número de valores que caen dentro de dicha ranura); • un histograma de altura equilibrada, que sitúa aproximadamente el mismo número de valores en cada ranura de modo que los puntos terminales de cada una de ellas se determinan según el número de valo- res contenidos en la ranura. Por ejemplo, suponga que tenemos cinco ranuras. La Figura 21.16(a) ilustra el histograma de anchu- ras equilibradas para la columna rooms. Todas las ranuras tienen igual anchura, comprendiendo dos valores
  • 43. Capítulo 21 Procesamiento de consultas 617 6 14 20 20 20 8 4 4 3 10 10 10 10 10 10 10 10 10 10 2 3 4 5 6 7 8 9 10 (a) 2 3 4 5 6 7 8 9 10 (b) Figura 21.15. Histograma de valores de la columna rooms en la tabla PropertyForRent: (a) distribución uniforme; (b) distribución no uniforme. (1-2,3-4, etc.), y dentro de cada ranura se asume que la distribución es uniforme. Esta información se puede almacenar de forma bastante compacta escribiendo el valor inferior y superior de cada ranura y el recuento del número de valores contenidos en la ranura. Si consideramos de nuevo el predicado rooms > 9, el histogra- ma de anchuras equilibradas nos permitiría estimar el número de tuplas que satisfacen este predicado, calcu- lándolo como un elemento de rango multiplicado por el número de elementos de rango, es decir 2*1 = 2, lo cual es mejor que la estimación basada en la distribución uniforme. El histograma de alturas equilibradas se ilustra en la Figura 21.16(b). En este caso, la altura de cada colum- na es 20 (100/5). De nuevo, los datos pueden almacenarse de forma bastante compacta escribiendo los valo- res inferior y superior de cada ranura, así como la altura de todas las ranuras. Si consideramos el predicado rooms > 9, podemos estimar mediante el histograma de alturas equilibradas el número de tuplas que satisfa- cen este predicado utilizando la fórmula: (1/5)*20 = 4, que en este caso no es tan buena como la estimación proporcionada por el histograma de anchuras equilibradas. Oracle utiliza histogramas de alturas equilibradas. Otra variante del histograma de alturas equilibradas utiliza una altura uniforme dentro de una ranura pero posi- blemente alturas ligeramente distintas entre unas ranuras y otras. Puesto que los histogramas son objetos persistentes, existe un coste asociado al almacenamiento y man- tenimiento de los mismos. Algunos sistemas, como SQL de Microsoft, crean y mantienen los histogramas 20 20 20 20 20 20 14 10 4 1 2 3 4 5 6 7 8 9 10 LJLJLJLJLJCount 20 40 28 8 4 (a) 1 2 3 4 LJ 5 6 7 8 l (b) 9 10 1 Figura 21.16. Histograma de valores de la columna rooms en la tabla PropertyForRent: (a) anchuras equilibradas; (b) alturas equilibradas.
  • 44. 618 Sistemas de bases de datos automáticamente sin necesidad de que el usuario introduzca ningún dato. Por el contrario, en Orac1e es res- ponsabilidad del usuario crear y mantener los histogramas para las columnas apropiadas, utilizando de nuevo el paquete PL/SQL DBMS_STATS. Las columnas apropiadas son, normalmente, aquellas columnas que se utilicen dentro de la cláusula WHERE de las instrucciones SQL y que tienen una distribución no uniforme, como la columna rooms en el ejemplo anterior. 21.6.3 Visualización del plan de ejecución Oracle permite visualizar el plan de ejecución que el optimizador va a elegir utilizando el comando EXPLAIN PLAN. Este comando puede ser enormemente útil si la eficiencia de una consulta no es la esperada. La sali- da de EXPLAIN PLAN se escribe en una tabla de la base de datos (la tabla predeterminada es PLAN_ TABLE). Las columnas principales de esta tabla son: • STATEMENT _ID, el valor de un parámetro opcional STATEMENT _ID especificado en la instrucción EXPLAIN PLAN. • OPERATION, el nombre de la operación interna realizada. La primera fila sería la propia instrucción SQL: SELECT, INSERT, UPDATE o DELE TE. • OPTIONS, el nombre de otra operación interna realizada. • OBJECT_NAME, el nombre de la tabla del índice. • ID, un número asignado a cada paso del plan de ejecución. • PARENT_ID, el identificador del siguiente paso que opera sobre la salida del paso ID. • POSITION, el orden de procesamiento para aquellos pasos que tienen el mismo valor de PARENT _ID. • COST, una estimación de coste para la operación (null para las instrucciones que utilicen el optimiza- dor basado en reglas). • CARDINALlTY, una estimación del número de filas a las que accede la operación. En la Figura 21.17 se muestra un plan de ejemplo. Cada línea de este plan representa un único paso en el plan de ejecución. Se ha utilizado el sangrado de las líneas para mostrar el orden de las operaciones (observe que el valor ID de columna es insuficiente por sí mismo para mostrar la ordenación). SQL> EXPLAIN PLAN 2 SET STATEMENT_IO = 'PB' 3 FOR SELECT b.branchNo, b.city, propertyNo 4 FROM Branch b, PropertyForRent p 5 WHERE b.branchNo = p.branchNo 6 OROER BY b.city; Explained. SQL> SELECT 1011''IIPARENT_IOII' 'IILPAO(' ',2*(LEVEL - 1)1I10PERATIONII' '1I0PTIONSII 2 ' 'IIOBJECT_NAME "Query Plan" 3 FROM Plan_Table 4 START WITH ID = O ANO STATEMENT_IO = 'PB' 5 CONNECT BY PRIOR ID = PARENT_IO ANO STATEMENT_ID = 'PB'; Query Plan O SELECT STATEMENT 1 O SORT OROER BY 2 1 NESTEO LOOPS 3 2 TABLE ACCESS FULL PROPERTYFORRENT 4 2 TABLE ACCESS BY INOEX ROWIO BRANCH 5 4 INOEX UNIQUE SCAN SYS_C007455 6 rows selected. Figura 21.7. Salida de la utilidad Explain Plan.
  • 45. Capítulo 21 Procesamiento de consultas 619 Resumen del capítulo • Los objetivos del procesamiento de consultas son transformar una consulta escrita en un lenguaje de alto nivel, normalmente SQL, en una estrategia de ejecución correcta y eficiente expresada en un lenguaje de bajo nivel, como, por ejemplo, el álgebra relacional, y ejecutar dicha estrategia para extraer los datos soli- citados. • Puesto que hay muchas transformaciones equivalentes para una misma consulta de alto nivel, el SGBD tiene que elegir aquella que minimice el uso de recursos. Este es el objetivo de la optimización de con- sultas. Puesto que el problema es intratable desde el punto de vista computacional cuando hay un gran número de relaciones, la estrategia adoptada se reduce generalmente a determinar una solución cercada a la óptima. • Hay dos técnicas principales de optimización de consultas, aunque las dos estrategias se suelen combinar en la práctica. La primera técnica utiliza reglas heurísticas que ordenan las operaciones de la consulta. La otra técnica compara las diferentes estrategias basándose en sus costes relativos y selecciona aquella que minimiza el uso de recursos. • El procesamiento de consultas puede dividirse en cuatro fases principales: descomposición (compuesta de análisis sintáctico y validación), optimización, generación de código y ejecución. Las primeras tres fases pueden realizarse en tiempo de compilación y en tiempo de ejecución. • La descomposición de consultas transforma una consulta de alto nivel en una consulta de álgebra rela- cional y comprueba que dicha consulta sea sintáctica y semánticamente correcta. Las etapas típicas de la descomposición de consultas son el análisis, la normalización, el análisis semántico, la simplificación y la reestructuración de la consulta. Puede utilizarse un árbol de álgebra relacional para proporcionar una representación interna de la consulta transformada. • La optimización de consultas puede aplicar reglas de transformación para convertir una expresión de álgebra relacional en una expresión equivalente que se sepa que es más eficiente. Entre las reglas de transformación se incluyen la conexión en cascada de operaciones de selección, la conmutatividad de las operaciones unarias, la conmutatividad de la combinación Theta (y del producto cartesiano), la conmu- tatividad de las operaciones unarias y de la combinación Theta (y del producto cartesiano) y la asociati- vidad de la combinación Theta (y del producto cartesiano). • Entre las reglas heurísticas se incluyen la realización de las operaciones de selección y proyección lo antes posible; la combinación de un producto cartesiano con una selección subsiguiente cuyo predicado represente una condición de combinación en una operación de combinación; la utilización de la asociati- vidad de las operaciones binarias para reordenar los nodos hoja de modo que aquellos que tengan las selec- ciones más restrictivas se ejecuten primero, etc. • La estimación de coste depende de la información estadística recopilada del catálogo del sistema. Entre las estadísticas típicas se incluye la cardinalidad de cada relación base, el número de bloques requeridos para almacenar una relación, el número de valores distintos para cada atributo, la cardinalidad de selec- ción de cada atributo y el número de niveles en cada índice multinivel. • Las principales estrategias para implementar la operación de selección son: búsqueda lineal (archivo no ordenado y no indexado), búsqueda binaria (archivo ordenado y no indexado), igualdad de clave hash, condición de igualdad de clave principal, condición de desigualdad de clave principal, condición de igual- dad de índice (secundario) de clústering, condición de igualdad de índice (secundario) no de clústering y condición de desigualdad en un índice secundario de tipo B+-tree. • Las principales estrategias para implementar la operación de combinación son: combinación mediante bucle anidado por bloques, combinación mediante bucle anidado indexado, combinación mediante orde- nación-mezcla y combinación hash. • Con la técnica de materialización la salida de una operación se almacena en una relación temporal para su procesamiento por parte de la siguiente operación. Otra técnica alternativa consiste en procesar en cadena los resultados de una operación, pasándolos a la operación siguiente sin crear una relación tempo-
  • 46. 620 Sistemas de bases de datos ral donde se almacenen los resultados intermedios; esta técnica de pipelining nos permite ahorramos el coste de crear relaciones temporales y de volver a leer los resultados. • A un árbol de álgebra relacional donde la relación del árbol derecho sea siempre una relación base se le denomina árbol de profundidad izquierda. Los árboles de profundidad izquierda tienen las ventajas de reducir el espacio de búsqueda de la estrategia óptima y de permitir que el optimizador de consulta se base en técnicas de procesamiento dinámico. Su principal desventaja es que, al reducir el espacio de búsqueda, no se toman en cuenta muchas estrategias de ejecución alternativas, algunas de las cuales podrían tener un coste menor que la determinada mediante un árbol lineal. • Un aspecto fundamental para la eficiencia de la optimización de consultas es el espacio de búsqueda de las posibles estrategias de ejecución y el algoritmo de enumeración utilizado para buscar en este espa- cio una estrategia óptima. Para una consulta determinada, este espacio de búsqueda puede ser muy gran- de; como resultado, los optimizadores de consultas restringen dicho espacio mediante una serie de técni- cas. Por ejemplo, las operaciones unarias pueden procesarse sobre la marcha; los productos cartesianos nunca se forman a menos que la propia consulta lo especifique; el operando interno de cada combinación es una relación base, etc. • El algoritmo de programación dinámica se basa en la suposición de que el modelo de coste satisface el principio de optimalidad. Para obtener la estrategia óptima para una consulta compuesta por n combina- ciones, sólo necesitamos considerar las estrategias óptimas para (n - 1) combinaciones y ampliar dichas estrategias con una combinación adicional. Se crean clases de equivalencias basadas en las ordenaciones interesantes y se retiene la estrategia de menor coste dentro de cada clase de equivalencia para ponerla en consideración en el siguiente paso, hasta construir toda la consulta, momento en que se selecciona la estra- tegia que tenga el menor coste global. Cuestiones de repaso 21.1. ¿Cuáles son los objetivos del procesamiento de consultas? 21.2. ¿En qué sentido difiere el procesamiento de consultas en los sistemas relacionales del procesamiento de lenguajes de consultas de bajo nivel para sistemas de red y jerárquicos? 21.3. ¿Cuáles son las fases típicas del procesamiento de consultas? 21.4. ¿Cuáles son las etapas típicas de la descomposición de consultas? 21.5. ¿Cuál es la diferencia entre las formas normales conjuntiva y disyuntiva? 21.6. ¿Como comprobaría la corrección semántica de una consulta? 21.7. Indique las reglas de transformación que pueden aplicarse a: (a) Operaciones de selección (b) Operaciones de proyección (c) Operaciones de combinación Theta. 21.8. Indique las reglas heurísticas que deberían aplicarse para mejorar el procesamiento de una consulta. 21.9. ¿Qué tipos de estadísticas debe almacenar un SGBD para poder calcular estimaciones del coste de las operaciones de álgebra relacional? 21.10. ¿En qué circunstancias tendrá que utilizar el sistema una búsqueda lineal a la hora de implementar una operación de selección? 21.11. ¿Cuáles son las estrategias principales para implementar la operación de combinación? 21.12. ¿Cuáles son las diferencias entre materialización y pipelining? 21.13. Explique la diferencia entre árboles de álgebra relacionallineales y no lineales. Proporcione ejemplos para ilustrar su respuesta. 21.14. ¿Cuáles son las ventajas y desventajas de los árboles de profundidad izquierda?
  • 47. Capítulo 21 Procesamiento de consultas 621 21.15. Describa cómo funciona el algoritmo de programación dinámica del optimizador de consultas de System R. Ejercicios 21.16. Calcule el coste de las tres estrategias citadas en el Ejemplo 21.1 si la relación 8taff tiene 10000 tuplas, si Branch tiene 500 tuplas, si hay 500 empleados con categoría de Manager (uno por cada sucursal) y si hay 10 sucursales en Londres. 21.17. Utilizando el esquema Hotel dado al principio de los ejercicios del Capítulo 3, determine si las siguien- tes consultas son semánticamente correctas: (a) SELECT rtype, r.price FROM Room r, Hotel h WHERE r.hotel_number = h.hotel_number AND h.hotel_name = 'Grosvenor Hotel' AND r.type > 100; (b) SELECT g.guestNo, g.name FROM Hotel h, Booking b, Guest 9 WHERE h.hotelNo = b.hotelNo AND h.hotelName = 'Grosvenor Hotel'; (c) SELECT r.roomNo, h.hotelNo FROM Hotel h, Booking b, Room r WHERE h.hotelNo = b.hotelNo AND h.hotelNo = 'H21' AND b.roomNo = r.roomNo AND type = 'S' AND bhotelNo = 'H22'; 21.18. Utilizando de nuevo el esquema Hotel, dibuje un árbol de álgebra relacional para cada una de las siguientes consultas y utilice las reglas heurísticas dadas en la Sección 21.3.2 para transformar las con- sultas en una forma más eficiente. Explique cada paso y enuncie las reglas de transformación usadas en el proceso. (a) SELECT r.roomNo, r.type, r.price FROM Room r, Booking b, Hotel h WHERE rroomNo = b.roomNo AND b.hotelNo = h.hotelNo AND h.hotelName = 'Grosvenor Hotel' AND r.price > 100; (b) SELECT g.guestNo, g.guestName FROM Room r, Hotel h, Booking b, Guest 9 WHERE h.hotelNo = b.hotelNo AND g.guestNo = b.guestNo AND h.hotelNo = r.hotelNo AND h.hotelName = 'Grosvenor Hotel' AND dateFrom >= '1-Jan-04' AND dateTo <= '31-Dec-04'; 21.19 Utilizando el esquema Hotel, suponga que existen los siguientes índices: • un índice hash sin desbordamiento sobre los atributos de clave principal, room No/hotel No en Room; • un índice de clústering sobre el atributo de clave externa hotelNo en Room; • un índice B+-tree sobre el atributo price en Room; • un índice secundario sobre el atributo type en Room. nTuples(Room) nTuples(Hotel) nTuples(Booking) nDistincthotelNo(Room) nDi stinct,ype(Room) nDistinctpriceCRoom) = 10.000 = 50 = 100.000 = 50 = 10 = 500 bFactor(Room) bFactor(Hotel) bFactor(Booking) = 200 = 40 = 60
  • 48. 622 Sistemas de bases de datos minprice(Room) nLevelshotelNo(I) nLevelspriee(I) = 200 =2 =2 maxprice(Room) nLfB lockspriee(I) = 50 = 50 (a) Calcule la cardinalidad y el coste mínimo para cada una de las siguientes operaciones de selección: SI: <TroomNo=1A holeINo='HOOI,(Room) S2: <T1ype='D,(Room) S3: <TholeINo='H002,(Room) S4: <Tprlee>loo(Room) S5: <T1ype='S'A hoteINo='HOOJ,(Room) S6: <Ttype='S'vprlee< loo(Room) (b) Calcule la cardinalidad y el coste mínimo para cada uno de las siguientes operaciones de combi- nación: Jl: Hotell><J hotelNoRoom J2: Hotel I><J hotelNoBooking 13: Room I><J roomNoBooking J4: Room I><J hotelNoHotel J5: Booking I><J holelNoHotel J6: Booking I><J roomNoRoom (c) Calcule la cardinalidad y el coste mínimo para cada una de las siguientes operaciones de pro- yección: P 1: IIhole'No(Hotel) P2: IIhole'No(Room) P3: IIprlee(Room) P4: Uype(Room) P5: IIhote,No,prlee(Room) 21.20, Modifique los algoritmo s de combinación mediante el bucle anidado por bloques y el bucle anidado indexado presentados en la Sección 21.4.3 para leer (nBuffer - 2) bloques de la relación externa R cada vez, en lugar de leer un sólo bloque en cada ocasión.
  • 49. Parte Bases de datos distribuidas y replicación Capítulo 22 Capítulo 23 Capítulo 24 Bases de datos distribuidas: conceptos y diseño Bases de datos disinbuidas: conceptos avanzados Replicación y bases de datos móviles
  • 50. Bases de datos distribuidas: conceptos y diseño Objetivos del capítulo: En este capítulo aprenderá: • La necesidad de las bases de datos distribuidas. • Las diferencias entre sistemas de bases de datos distribuidas, procesamiento distribuido y sistemas de bases de datos paralelas. • Las ventajas y desventajas de las bases de datos distribuidas. • Los problemas de heterogeneidad en un SGBD distribuido. • Conceptos básicos de interconexión por red. • Las funciones que debe proporcionar un SGBD distribuido. • Una arquitectura para los SGBD distribuidos. • Los problemas principales asociados con el diseño de bases de datos distribuidas, y en especial los pro- blemas de fragmentación, replicación y asignación. • Cómo debe llevarse a cabo la fragmentación. • La importancia de la asignación y la replicación en las bases de datos distribuidas. • Los niveles de transparencia que un SGBD distribuido debe proporcionar. • Criterios de comparación para los SGBD distribuidos. La tecnología de bases de datos ha evolucionado desde un paradigma de procesamiento de datos en el que cada aplicación definía y mantenía sus propios datos, hasta otro en el que los datos se definían y administra- ban de manera centralizada. En los últimos años, hemos visto una serie de rápidos desarrollos en la tecnolo- gía de redes y de comunicación de datos, cuyas mejores representaciones son Internet, la comunicación móvil e inalámbrica, los dispositivos inteligentes y la computación reticular. Ahora, con la combinación de estas dos tecnologías, la tecnología de bases de datos distribuidas permite cambiar el modo de trabajo, pasando de un modo centralizado a otro descentralizado. Este tipo de tecnología combinada es uno de los avances principa- les en el área de los sistemas de base de datos. En los capítulos anteriores nos hemos centrado en los sistemas de bases de datos centralizados, sistemas con una única base de datos lógica ubicada en un determinado lugar bajo control de un único SGBD. En este capítulo, hablaremos de los conceptos y cuestiones asociados con los sistemas de gestión de bases de datos distribuidas (SGBDD) que permiten a los usuarios acceder no sólo a los datos situados en su misma ubica- ción, sino también a aquellos otros que están almacenados en ubicaciones remotas. Algunos autores sostienen que los SGBD centralizados llegarán a quedar completamente obsoletos a medida que las organizaciones migren hacia sistemas de gestión de base de datos distribuidas.
  • 51. 626 Sistemas de bases de datos Estructura del capítulo En la Sección 22.1 se presentan los conceptos básicos de los SGBDD y se explican las diferencias entre un SGBDD, el procesamiento distribuido y los SGBD paralelos. En la Sección 22.2 se proporciona una breve introducción a los conceptos de interconexión de red para que resulten más claras algunas de las explicacio- nes posteriores. En la Sección 22.3 se examina la funcionalidad ampliada que cabe esperar que un SGBDD proporcione. También se analizan posibles arquitecturas de referencia para un SGBDD como extensiones de la arquitectura ANSI-SPARC presentada en el Capítulo 2. En la Sección 22A se explica cómo ampliar la meto- dología de diseño de bases de datos presentada en la Parte 4 de este libro para tener en cuenta las cuestiones de la distribución de datos. En la Sección 22.5 se explican los mecanismos de transparencia que cabe esperar encontrar en un SGBDD y en la Sección 22.6 concluimos con un breve repaso de las doce reglas de Date para un SGBDD. De nuevo, los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome des- crito en la Sección lOA y en el Apéndice A. En el siguiente capítulo examinaremos cómo pueden extenderse los protocolos de control de concurren- cia, de gestión de interbloqueos y de control de recuperación explicados en el Capítulo 20 para tener en cuen- ta las características de un entorno distribuido. En el Capítulo 24 hablaremos de los servidores de replicación, que constituyen una técnica alternativa, y potencialmente más simpl~la implementación de mecanismos de distribución de datos. También hablaremos de las bases de datos móviles y veremos cómo soporta Oracle la movilidad y la replicación de datos. 22.1 Introducción Una de las principales motivaciones para el desarrollo de sistemas de bases de datos es el deseo de integrar los datos operacionales de una organización y proporcionar un acceso controlado a esos datos. Aunque la inte- gración y el acceso controlado pueden implicar la necesidad de utilizar mecanismos de centralización, el obje- tivo en realidad no es ese. De hecho, el desarrollo de redes informáticas promueve el modo descentralizado de trabajo. Esta técnica descentralizada imita la estructura organizativa de muchas empresas, que están distri- buidas de modo lógico en divisiones, departamentos, proyectos, etc., y están distribuidas de modo fisico en oficinas, fábricas e instalaciones, manteniendo cada unidad sus propios datos operacionales. (Date, 2000). La posibilidad de compartir los datos y la eficiencia del acceso a los mismos puede mejorarse mediante el de- sarrollo de sistemas de bases de datos distribuidas que reflejen esta estructura organizativa, que hagan que los datos de todas las unidades sean accesibles y que almacenen esos datos en algún lugar próximo a aquel donde más frecuentemente se los utilice. Los SGBD distribuidos deberían ayudamos a resolver el problema de las isras de información. Las bases de datos se consideran en ocasiones, islas electrónicas que constituyen lugares diferenciados y generalmente inaccesibles, igual que las islas remotas. Esto puede ser resultado de la separación geográfica, de la incompa- tibilidad de las arquitecturas informáticas, de la incompatibilidad de los protocolos de comunicaciones, etc. Si se consigue integrar las bases de datos en un todo lógico coherente, podemos resolver el problema. 22.1.1 Conceptos Para comenzar nuestro análisis de los SGBD distribuidos, veamos primero algunas definiciones. Base de datos distribuida SGBD distribuido Una colección lógicamente interrelacionada de datos compartidos Ounto con una descripción de estos datos) físicamente distribuidos por una red informática. El sistema software que permite gestionar la base de datos distribuida y hace que dicha distribución sea transparente para los usuarios. Un sistema de gestión de bases de datos distribuidas (SGBDD) está compuesto por una única base de datos lógica dividida en una serie de fragmentos. Cada fragmento se almacena en una o más computadoras
  • 52. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 627 bajo el control de un SGBD independiente, estando dichas computadoras conectadas mediante una red de comunicaciones. Cada una de las instalaciones es capaz de procesar de forma independiente las solicitudes de los usuarios que requieran acceso a los datos locales (es decir, cada instalación tiene un cierto grado de auto- nomía local) y también es capaz de procesar los datos almacenados en otras computadoras de la red. Los usuarios acceden a la base de datos distribuida a través de una serie de aplicaciones, que podemos cla- sificar en dos grupos: aquellas que no requieren datos de otras instalaciones (aplicaciones locales) y aquellas que sí requieren datos de esas otras instalaciones (aplicaciones globales). Para que un SGBDD pueda ser con- siderado como tal, deberá disponer al menos de una aplicación global. Un SGBDD tiene, por tanto, las siguientes características: • una colección de datos compartidos lógicamente relacionados; • los datos están divididos en una serie de fragmentos; • los fragmentos pueden ser replicados; . • los fragmentos/réplicas se asignan a distintas instal~iones; • las distintas instalaciones están enlazadas mediante una red de comunicaciones; • los datos de cada instalación están bajo control de un SGBD; • el SGBD de cada instalación puede gestionar las aplicaciones locales de manera autónoma; • cada SGBD participa en al menos una aplicación global. No es necesario que todas las instalaciones del sistema tengan su propia base de datos local, como se ilus- tra mediante la topología de SGBDD mostrada en la Figura 22.1 Instalación 1 BO Instalación 4 Instalación 3 BO Instalación 2 BO Figura 22.1. Sistema de gestión de bases de datos distribuidas. 1 Ejemplo 22.1 DreamHome Utilizando tecnología de distribución de base de datos, DreamHome puede implementar su sistema de base de datos en una serie de sistemas informáticos independientes, en lugar de utilizar un único main- frame centralizado. Los sistemas informáticos pueden estar ubicados en cada sucursal local: por ejem- plo Londres, Aberdeen y Glasgow. Una red que enlace las distintas computadoras permitirá que las sucursales se comuniquen entre sí y un SGBDD les permitirá acceder a los datos almacenados en las
  • 53. 628 Sistemas de bases de datos restantes sucursales. Así, un cliente que viva en Glasgow puede acudir a la sucursal más próxima para averiguar qué inmuebles hay disponibles en Londres, en lugar de tener que telefonear o escribir a la sucursal de Londres para conseguir los detalles oportunos. Alternativamente, si cada sucursal de DreamHome tiene ya su propia base de datos (heterogénea), puede utilizarse un SGBDD para integrar las distintas bases de datos en una única base de datos lógi- ca, haciendo de nuevo que los datos locales estén disponibles de manera mucho más amplia. ~ A partir de la definición de un SGBDD, podemos esperar que el sistema haga que la distribución de los datos sea transparente (invisible) a ojos del usuario. Así, el hecho de que una base de datos distribuida esté dividida en una serie de fragmentos que puedan estar almacenados en diferentes computadoras y quizás repli- cados debería ocultarse al usuario. El objetivo de la transparencia consiste en hacer que el sistema distribui- do parezca un sistema centralizado. Algunas veces se denomina este concepto como el principio fundamen- tal de los SGBD distribuidos (Date, 1987b). Este requisito proporciona una funcionalidad muy potente al usuario final pero, desafortunadamente, crea muchos problemas ~dici.onales que deberá resolver el SGBDD,como se explica en la Sección 22.5. ~ Procesamiento distribuido Es muy importante entender la diferencia entre un SGBD distribuido y el procesamiento distribuido. Procesamiento distribuido Una base de datos centralizada a la que se puede acceder a través de una red infor- mática. El punto clave en la definición de un SGBD distribuido es que el sistema está compuesto por datos que están físicamente distribuidos entre una serie de nadas de la red. Si los datos están centralizados, aunque otros usuarios estén accediendo a los datos a través de la red, no consideraremos que se trate de un SGBD distri- buido, sino simplemente de un sistema de procesamiento distribuido. En la Figura 22.2 se ilustra la topología del procesamiento distribuido; compare esta figura, que tiene una base de datos central en el nodo 2, con la Figura 22.1, que muestra varios nadas o instalaciones, cada uno de ellos con su propia base de datos (BD). Instalación 1 Instalación 4 Instalación 2 Instalación 3 Figura 22.2. Procesamiento distribuido. BD
  • 54. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 629 Bases de datos paralelas También conviene entender la diferencia entre un SGBD distribuido y un SGBD paralelo. SGBD paralelo Un SGBD que se ejecuta sobre múltiples procesado res y utilizando múltiples discos y que está diseñado para ejecutar las operaciones en paralelo, siempre que sea posible, con el fin de mejorar las prestaciones. Los SGBD paralelos se basan, de nuevo, en la premisa de que los sistemas monoprocesador no pueden satisfacer los requisitos crecientes de escalabilidad, fiabilidad y prestaciones a precios razonables. Una alter- nativa potente y atractiva desde el punto de vista económico a los SGBD monoprocesador son los SGBD para- lelos que utilizan múltiples procesadores. Los SGBD paralelos enlazan múltiples máquinas de menor tamaño para conseguir la misma capacidad de procesamiento que una única máquina de tamaño mayor, a menudo con una mayor escalabilidad y fiabilidad que los SGBD mofprocesador. Para proporcionar a los múltiples procesadores un aCfeso común a una única base de datos, el SGBD para- lelo debe encargarse de la gestión de los recursos compartidos. Qué recursos estén compartidos y cómo se (a) (b) Red de interconexión (e) Figura 22.3. Arquitecturas de bases de datos paralelas: (a) memoria compartida; (b) disco compartido; (c) sin compartición.
  • 55. 630 Sistemas de bases de datos implementen esos recursos compartidos afectará directamente a las prestaciones y a la escalabilidad del sis- tema, lo que a su vez determinará si resulta apropiado para una determinada aplicación o entorno. Las tres principales arquitecturas de SGBD paralelo, ilustradas en la Figura 22.3, son: • memoria compartida; • disco compartido; • sin compartición. La arquitectura de memoria compartida es una arquitectura fuertemente acoplada en la que una serie de procesadores situados en un mismo sistema comparten la memoria del sistema. Conocida con el nombre de multiprocesamiento simétrico (SMP, symmetric multiprocessing), esta técnica se ha hecho muy popular en diversos tipos de plataformas, desde estaciones de trabajo personales que poseen unos pocos microprocesa- dores funcionando en paralelo, hasta máquinas RISC (Reduced Instructio~t Computer) de gran tamaño e incluso mainframes. Esta arquitectura proporciona un acceso de datos de alta velocidad para un número limi- tado de procesadores, pero no puede escalarse esta arquitectura más allá de 64 procesadores, ya que la red de interconexión pasa entonces a convertirse en un cuello de botella. La arquitectura de disco compartido es una arquitectura débilmente acoplada que está optimizada para aplicaciones inherentemente centralizadas y que requiere una alta disponibilidad y unas altas prestaciones. Cada procesador puede acceder directamente a todos los discos, pero cada uno de ellos tiene su propia memoria privada. Al igual que la arquitectura sin compartición, la arquitectura de disco compartido elimina el cuello de botella representado por la memoria compartida. Sin embargo, a diferencia de la arquitectura sin compartición, la arquitectura de disco compartido elimina este cuello de botella sin el engorro de introducir un particionamiento físico de los datos. Los sistemas de disco compartido se denominan en ocasiones clús- teres. La arquitectura sin compartición, a menudo denominada procesamiento masivamente paralelo (MPP, massively parallel processing), es una arquitectura multiprocesador en la que cada procesador es parte de un sistema completo, con su propia memoria y su propio almacenamiento en disco. La base de datos se particio- na entre todos los discos de cada uno de los sistemas asociados con la base de datos, y los datos están dispo- nibles de forma transparente para los usuarios de todos los sistemas. Esta arquitectura es más escalable que la de memoria compartida y permite soportar más fácilmente un mayor número de procesadores. Sin embargo, las prestaciones sólo son óptimas si los datos solicitados están almacenados localmente. Aunque la definición de arquitectura sin compartición incluye en ocasiones a los SGBD distribuidos, la distribución de los datos en un SGBD paralelo está basada únicamente en consideraciones de rendimiento. Además, los nodos de un SGBDD están normalmente distribuidos de manera geográfica, se administran por separado y tienen una red de interconexión más lenta, mientras que los nadas de un SGBD paralelo se encuen- tran normalmente dentro de una misma computadora o dentro de un mismo nodo. La tecnología paralela se utiliza normalmente para bases de datos de muy gran tamaño, por ejemplo del orden de los terabytes (l 012 bytes) o para sistemas que tengan que procesar miles de transacciones por segun- do. Estos sistemas necesitan acceder a grandes volúmenes de datos y deben proporcionar una respuesta rápi- da a las consultas que se realicen. Un SGBD paralelo puede utilizar la arquitectura subyacente para mejorar la velocidad de ejecución de las consultas complejas, utilizando técnicas paralelas de exploración, de combi- nación y de ordenación que permiten que los múltiples nodos procesadores compartan de forma automática la carga de trabajo. Hablaremos más en detalle de esta arquitectura en el Capítulo 31, cuando tratemos el tema de los almacenes de datos. Baste decir aquí que todos los principales fabricantes de sistemas de gestión de bases de datos tienen versiones paralelas de sus motores de bases de datos. 22.1.2 Ventajas y desventajas de los SGBDD La distribución de datos y de aplicaciones presenta ventajas potenciales con respecto a los sistemas centrali- zados tradicionales de bases de datos. Desafortunadamente, también hay algunas desventajas. En esta sección vamos a analizar tanto las unas como las otras.
  • 56. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 631 Ventajas Refleja la estructura organizativa Muchas organizaciones están distribuidas de forma natural en diversas ubicaciones. Por ejemplo, DreamHome tiene muchas oficinas en diversas ciudades. Resulta natural que las bases de datos utilizadas en dicho tipo de aplicaciones estén distribuidas entre esas diferentes ubicaciones. DreamHome puede mantener una base de datos en cada sucursal donde se contengan los detalles relativos a cosas tales como el personal que trabaja en dicha oficina, los inmueble s que tiene en ~l~uiler y los clientes que poseen o quieren alquilar dichos inmue-bles. El personal que trabaje en una sucurs~uede realizar consultas locales a la base de datos. Por su parte, el personal de las oficinas centrales puede necesitar realizar consultas globales que requieran acceder a los datos de todas las sucursales o de un número significativo de ellas. Mejora la compartición de los datos y la autonomía local La distribución geográfica de una organización puede reflejarse en la distribución de los datos; los usuarios de uno de los nadas pueden acceder a los datos almacenados en los otros nadas. Los datos pueden colocarse en el nodo más próximo a los usuarios que normalmente los usan. De esta forma, los usuarios tienen un con- trollocal de los datos y pueden, en consecuencia establecer e imponer políticas locales relativas al uso de estos datos. Un administrador global de la base de datos será responsable del sistema completo. Generalmente, parte de esta responsabilidad se delega en el nivel local, de modo que el DBA local puede gestionar el SGBD local (véase la Sección 9.15). Mayor disponibilidad En un SGBD centralizado, un fallo de la computadora hace que se detengan las operaciones del SGBD. Sin embargo, un fallo en uno de los nodos de un SGBDD, o un fallo de un enlace de comunicaciones que haga que algunos nadas sean inaccesibles, no hace que todo el sistema deje de operar. Los SGBD distribuidos están diseñados para continuar funcionando a pesar de tales fallos. Si se produce un fallo en un único nodo, puede que el sistema sea capaz de reencaminar las solicitudes dirigidas al nodo fallido hacia otro nodo. Mayor fiabilidad Ya que los datos pueden replicarse, de modo que estén almacenados en más de un nodo, el fallo de un nodo o de un enlace de comunicaciones no hace necesariamente que los datos dejen de estar accesibles. Mayores prestaciones Ya que los datos están localizados cerca del nodo de 'mayor demanda', y dado el inherente paralelismo de un SGBD distribuido, la velocidad del acceso a la base de datos puede ser superior que la que podría alcanzarse utilizando una base de datos centralizada remota. Además, dado que cada nodo gestiona únicamente una parte de la base de datos completa, puede que no haya el mismo grado de contienda por el procesador y por los ser- vicios de E/S que el que se experimenta en un SGBD centralizado. Economía En la década de ]960, la potencia de procesamiento se calculaba según el cuadrado del coste de los equipos: multiplicando el coste por tres, se incrementaba por nueve la potencia de procesamiento. Esto se conocía con el nombre de Ley de Grosch. Sin embargo, hoy en día se acepta con carácter general que resulta mucho más barato crear un sistema de pequeñas computadoras con la potencia equivalente de una única computadora de gran tamaño. Esto hace que sea más eficiente en términos económicos que las divisiones y departamentos cor- porativos adquieran computadoras independientes. También es mucho más barato añadir estaciones de traba- jo a una red que actualizar un sistema mainframe. La segunda área potencial de ahorro de costes está relacionada con aquellas situaciones en las que las bases de datos son geográficamente remotas y las aplicaciones necesitan acceder a datos distribuidos. En tales casos, debido al alto coste de transmisión de los datos a través de la red (si lo comparamos con el coste del acceso
  • 57. 632 Sistemas de bases de datos local), puede ser mucho más económico particionar la aplicación y realizar el procesamiento localmente en cada nodo. Crecimiento modular En un entorno distribuido, resulta mucho más sencillo expandir el sistema. Pueden añadirse nuevos nodos a la red sin afectar a las operaciones de otros nodos. Esta flexibilidad permite a una organización expandirse de forma relativamente simple. Para incrementar el tamaño de la base de datos, basta con añadir potencia de pro- cesamiento y espacio de almacenamiento a la red. En un SGBD centralizado, el crecimiento puede necesitar de cambios en el hardware (la compra de un sis~ema más potente) y en el software (la adquisición de un SGBDmás potente o más configurable). ~ Integración Al principio de esta sección hemos indicado ya que la integración, no la centralización, es una ventaja clave de los SGBD. La integración de los sistemas herederos constituye un ejemplo concreto que demuestra cómo algunas organizaciones están forzadas a utilizar un procesamiento de datos distribuido para que sus sistemas heredados coexistan con los otros sistemas más modernos. Al mismo tiempo, ningún paquete software puede proporcionar toda la funcionalidad que una organización requiere hoy en día. Por tanto, es importante que las organizaciones puedan integrar componentes software de diferentes fabricantes para satisfacer sus requisitos específicos. Capacidad de competir Diversos desarrollos relativamente recientes dependen en buena medida de la tecnología de bases de datos distribuidas. Este es el caso, del e-Business, de la gestión de flujos de trabajo y de los sistemas de trabajo en colaboración basados en computadora. Muchas empresas han tenido que reorganizar sus operaciones y utili- zar tecnología de bases de datos distribuidas para seguir siendo competitivas. Por ejemplo, aunque no es pro- bable que haya más personas que alquilen inmuebles simplemente debido a la existencia de Internet, DreamHome puede perder parte de su cuota de mercado si no permite a los clientes ver los inmuebles en línea. Desventajas Complejidad Un SGBD distribuido que oculte la naturaleza distribuida de los datos a ojos del usuario y que proporcione un nivel aceptable de rendimiento, fiabilidad y disponibilidad es inherentemente más complejo que un SGBD centralizado. El hecho de que los datos puedan replicarse añade también un nivel adicional de complejidad al SGBD distribuido. Si el software no gestiona adecuadamente la replicación de los datos, habrá una degrada- ción en la disponibilidad, la fiabilidad y las prestaciones por comparación con un sistema centralizado, y las ventajas que antes hemos citado se transformarán en desventajas. Coste La mayor complejidad implica que cabe esperar que los costes de adquisición y de mantenimiento de un SGBDD sean mayores que para un SGBD centralizado. Además, un SGBD distribuido requiere un hardware adicional para implantar la red de comunicaciones entre los distintos nodos. Con el uso de esta red, además, existen una serie de costes de comunicación continuados. Por último, tenemos que tener en cuenta los costes adicionales de personal requeridos para gestionar y mantener los SGBD locales y la red subyacente. Seguridad En un sistema centralizado, el acceso a los datos puede controlarse fácilmente. Por el contrario, en un SGBD distribuido no sólo es necesario controlar el acceso a los datos replicados en múltiples ubicaciones, sino que también es necesario dotar de seguridad a la propia red. En el pasado, las redes se consideraban un medio de comunicación inseguro. Aunque esto continua siendo parcialmente cierto, diversos desarrollos de gran impor- tancia han incrementado considerablemente el nivel de seguridad de las redes.
  • 58. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 633 Control de integridad más complicado La integridad de la base de datos es un término que hace referencia a la validez y coherencia de los datos alma- cenados. La integridad se expresa normalmente en términos de restricciones, que son reglas de coherencia que no se permite que la base de datos viole. Imponer las restricciones de integridad requiere, generalmente, acce- der a una gran cantidad de datos que definen la restricción pero que no están implicados en la propia opera- ción de actualización. En un SGBD distribuido, los costes de comunicaciones y de procesamiento requeridos para imponer las restricciones de integridad pueden ser prohibitivos. Volveremos sobre este problema en la Sección 23.4.5. Carencia de estándares Aunque los SGBD distribuidos dependen de que existan unas comunicaciones efectivas, sólo ahora estamos comenzando a ser testigos de la aparición de protocolos de comunicaciones y de acceso a datos estándar. Esta falta de estándares ha inundado considerablemente el potencial de los SGBD distribuidos. Asimismo, tampo- co hay herramientas o metodologías que ayuden a los usuarios a convertir un SGBD centralizado en un SGBD distribuido. Falta de experiencia Los SGBD distribuidos de propósito general no han sido aceptados ampliamente, aunque muchos de los pro- tocolos y de los problemas se comprendan a la perfección. En consecuencia, todavía no tenemos el mismo nivel de experiencia en este sector que en el caso de los SGBD centralizados. Para alguien que esté pensan- do en adoptar esta tecnología, este factor puede ser uno de los obstáculos principales. Diseño de la base de datos más complejo Además de las dificultades normales de diseñar una base de datos centralizada, el diseño de una base de datos distribuida tiene que tener en cuenta la fragmentación de los datos, la asignación de fragmentos en los dife- rentes nodos y las cuestiones de replicación de los datos. Hablaremos de estos problemas en la Sección 22.4. La Tabla 22.1 resume las ventajas y desventajas de los SGBDD. 22.1.3 Sistemas SGBDD homogéneos y heterogéneos Los SGBDD pueden c1asificarse como homogéneos o heterogéneos. En un sistema homogéneo todos los nodos utilizan el mismo SGBD. En un sistema heterogéneo, los nodos pueden estar ejecutando diferentes SGBD, los cuales no tienen por qué estar basados en un mismo modelo de datos subyacente, de modo que el sistema puede estar compuesto de diversos SGBD relacionales, en red, jerárquicos u orientados a objetos. Tabla 22.1. Resumen de ventajas y desventajas de los SGBDD. Ventajas Reflejan la estructura de la organización Mejoran la compartición y la autonomía local Mejoran la disponibilidad Mejoran la fiabilidad Mejoran las prestaciones Economía Crecimiento modular Integración Capacidad para seguir siendo competitivos Desventajas Complejidad Costes Seguridad Control de integridad más complicado Carencia de estándares Falta de experiencia Diseño de la base de datos más complejo
  • 59. 634 Sistemas de bases de datos Los sistemas homogéneos son mucho más fáciles de diseñar y mantener. Esta técnica permite el crecimien- to incremental, haciendo que la adición de un nuevo nodo al SGBDD sea sencilla, y también permite conse- guir unas mayores prestaciones, al aprovechar las capacidades de procesamiento paralelo de los múltiples nodos. ( Los sistemas heterogéneo s suelen crearse cuando los nodos individuales han implementado por su cuenta(US propias bases de datos y la integración de los nodos se pone en marcha en una fase posterior. En un siste- ma heterogéneo, se requiere una cierta labor de traducción para que los distintos SGBD puedan comunicarse entre sí. Para proporcionar un cierto grado de transparencia con respecto al SGBD, los usuarios deben poder realizar las solicitudes en el lenguaje del SGBD que utilicen en su nodo local. El sistema deberá entonces encargarse de localizar los datos y de realizar toda la labor de traducción necesaria. Puede que el usuario soli- cite datos de otro nodo que tenga: • un hardware diferente; • productos SGBD diferentes; • diferentes hardware y productos SGBD diferentes. Si el hardware es diferente pero el SGBD es igual, la traducción es bastante sencilla, bastando con modi- ficar los códigos y la longitud de palabra. Si los productos SGBD son distintos, la traducción se complica, ya que es necesario establecer una correspondencia entre las estructuras de datos de un modelo de datos y las estructuras de datos equivalentes en el otro modelo. Por ejemplo, las relaciones dentro del modelo de datos relacional se hacen corresponder con registros y conjuntos en el modelo de red. También es necesario tradu- cir el lenguaje de consulta utilizado (por ejemplo, las instrucciones SELECT de SQL deben traducirse a ins- trucciones FIND y GET de red). Si tanto el hardware como el software son distintos, hace falta efectuar ambos tipos de traducción, lo que hace que el procesamiento sea extremadamente complejo. Un nivel adicional de complejidad es la necesidad de proporcionar un esquema conceptual común, que se forma mediante la integración de los esquemas conceptuales locales. Como hemos visto ya en el Paso 2.6 de la metodología del diseño lógico de bases de datos presentada en el Capítulo 16, la integración de modelos de datos puede ser muy difícil debido a la heterogeneidad semántica. Por ejemplo, dos atributos con el mismo nombre en sendos esquemas pueden representar diferentes cosas; asimismo, atributos con nombres distintos pueden modelar el mismo concepto. Un análisis completo de los mecanismos de detección y resolución de los problemas derivados de la heterogeneidad semántica cae fuera del alcance de este libro, pero el lector intere- sado puede consultar el artículo de García-Solaco el al. (1996). La solución típica empleada en algunos sistemas relacionales que forman parte de un SGBDD heterogé- neo consiste en utilizar pasarelas, que convierten el lenguaje y el modelo de cada SGBD al lenguaje y el modelo del sistema relacional. Sin embargo, la técnica basada en pasarelas tiene algunas limitaciones impor- tantes. En primer lugar, puede que no soporte la gestión de transacciones, incluso para una simple pareja de sistemas; en otras palabras, la pasarela entre dos sistemas puede ser únicamente un traductor de consultas. Por ejemplo, un sistema puede no coordinar el control de concurrencia y la recuperación de transacciones en las que se incluyen actualizaciones a las dos bases de datos. En segundo lugar, la solución basada en pasarelas se preocupa sólo del problema de traducir una consulta expresada en un lenguaje a otra expresión equivalente en otro lenguaje. Por ello, generalmente no resuelve el problema de homogeneizar las diferencias estructurales y de representación existentes entre los diferentes esquemas. Acceso abierto a bases de datos e interoperabilidad Open Group formó un grupo de trabajo (SWG, Specification Working Group) para tratar de dar una respues- ta a las cuestiones de acceso abierto a bases de datos e interoperabilidad (Gualtieri, 1996). El objetivo de este grupo era proporcionar especificaciones o verificar la existencia de especificaciones que ya hubieran sido desarrolladas o que estuvieran en desarrollo y que permitieran crear una infraestructura de bases de datos con: • una interfaz de programación de aplicaciones SQL común y suficientemente potente que permitiera escribir aplicaciones cliente que no necesitaran conocer el fabricante del SGBD al que estuvieran acce- diendo;
  • 60. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 635 • un protocolo de base de datos común que permitiera a un SGBD de un fabricante comunicarse direc- tamente con el SGBD de otro fabricante sin necesidad de una pasarela; • un protocolo de red común que permitiera la comunicación entre diferentes SGBD. El objetivo más ambicioso es encontrar una forma de permitir la traducción entre bases de datos gestiona- das por sistemas SGBD de diferentes fabricantes, sin necesidad de utilizar una pasarela. Este grupo de traba- jo se ha transformado recientemente en el consorcio DBIOP (Database Interoperability) en el momento de escribir este libro, y está trabajando en la versión 3 de la arquitectura DRDA (Distributed Relational Database Architecture), de la que hablaremos brevemente en la Sección 22.5.2. Sistemas multi-base de datos Antes de completar esta sección vamos a hablar brevemente de un tipo concreto de SGBD distribuido, cono- cido con el nombre de sistema multi-base de datos. Sistema multi- base de datos Un SGBD distribuido en el que cada nodo mantiene una completa autonomía. En los últimos años, ha habido un considerable interés en los sistemas multi-base de datos (MDBS, Multidatabase system), que tratan de integrar desde el punto de vista lógico diversos SGBDD independientes, al mismo tiempo que permiten que los SGBD locales mantengan un control completo de sus operaciones. Una consecuencia de esta total autonomía es que no pueden efectuarse modificaciones software en los SGBD loca- les. Por tanto, un MDBS requiere una capa de software adicional por encima de los sistemas locales para pro- porcionar la funcionalidad necesaria. Un MDBS permite a los usuarios acceder a los datos y compartidos sin necesidad de que exista una inte- gración completa del esquema de base de datos. Sin embargo, sigue permitiendo que los usuarios administren sus propias bases de datos sin un control centralizado, al igual que sucede con los SGBDD. El DBA de un SGBD local puede autorizar el acceso a partes concretas de su base de datos especificando un esquema de exportación, que define las partes de la base de datos a las que los usuarios no locales pueden acceder. Existen sistemas MDBS no federados (donde no hay usuarios locales) y federados. Un sistema federado es un cruce entre un SGBD distribuido y un SGBD centralizado; se trata de un sistema distribuido para usuarios globales y de un sistema centralizado para los usuarios locales. El lector interesado puede consultar la obra de Sheth y Larson (1990) para ver una taxonomía de los SGBD distribuidos, así como la obra de Bukhres y Elmagarmid (1996). En términos simples, un MDBS es un SGBD que reside transparentemente por encima de los sistemas de archivo y de las bases de datos existentes y que presenta a los usuarios una única base de datos. Un MDBS mantiene únicamente el esquema global de acuerdo con el cual los usuarios plantean sus consultas y actuali- zaciones, siendo los propios SGBD locales los que se encargan de mantener todos los datos del usuario. El esquema global se construye integrando los esquemas de las bases de datos locales. El MDBS traduce prime- ro las consultas y actualizaciones globales en consultas y actualizaciones dirigidas a los SGBD locales apro- piados. A continuación, combina los resultados locales y genera el resultado global final para el usuario. Además, el MDBS coordina las operaciones de confirmación y de aborto de las transacciones globales por parte de los SGBD locales que las procesan, con el fin de mantener la coherencia de los datos entre las dis- tintas bases de datos locales. Un MDBS controla múltiples pasarelas y gestiona las bases de datos locales a través de estas pasarelas. Hablaremos de la arquitectura de un MDBS en la Sección 22.3.3. 22.2 Panorámica de la comunicación por red Red Una colección interconectada de computadoras autónomas que son capaces de intercambiar información. El tema de las redes informáticas constituye un campo complejo y en rápida evolución, pero resulta útil tener algunas nociones de este campo para poder comprender los sistemas distribuidos. Comparando la situación
  • 61. 636 Sistemas de bases de datos con la existe hace algunas décadas, cuando los sistemas eran completamente autónomos, lo que ahora vemos es que las redes informáticas son ya algo común. Estas redes van desde sistemas que conectan unas pocas computadoras de sobremesa hasta redes de alcance mundial con miles de máquinas y millones de usuarios. En lo que a nosotros respecta, los SGBDD se construyen sobre una red informática de modo tal que la red queda oculta a ojos del usuario. Podemos clasificar las redes de comunicaciones de varias formas. Una de las posibles clasificaciones es la que podemos efectuar de acuerdo a la distancia que separa las distintas computadoras, que puede ser peque- ña (red de área local) o grande (red de área extensa). Una red de área local (LAN) conecta una serie de com- putadoras relativamente próximas entre sí, como por ejemplo dentro de un edificio de oficinas, dentro de una universidad o dentro de un domicilio. En ocasiones, en un mismo edificio puede haber varias redes LAN de pequeño tamaño, mientras que en otros casos una misma LAN puede abarcar varios edificios cercanos. Las redes LAN son normalmente propiedad de una única organización o persona que es quien las controla y las gestiona. Las principales tecnologías de conectividad utilizadas en este tipo de redes son Ethernet y Token Ring. Las redes de área extensa (WAN) se utilizan cuando es necesario conectar una serie de computadoras o redes LAN a larga distancia. La red WAN de mayor tamaño que existe es Internet. A diferencia de una LAN, las redes WAN no son propiedad, generalmente, de una única organización, sino que la propiedad y la gestión de este tipo de redes es colectiva o distribuida. Las redes WAN utilizan tecnologías tales como ATM, FrameRelay y X.25 para la conectividad. Un caso especial de red WAN es la red de área metropolitana (MAN), que cubre generalmente una ciudad o un suburbio. Debido a la gran separación geográfica, los enlaces de comunicaciones en una WAN son relativamente lentos y menos fiables que en una LAN. Las velocidades de transmisión para una WAN van generalmente desde los 33,6 kilobits por segundo (módem de acceso telefónico) a 45 megabits por segundo (línea privada T3 no conmutada). Las velocidades de transmisión de las redes LAN son muy superiores, operando desde 10 megabits por segundo (ethernet compartida) hasta 2500 megabits por segundo (ATM), y son altamente fia- bles. Obviamente, un SGBDD que utilice una red LAN como medio de comunicación proporcionará un tiem- po de respuesta mucho más rápido que otro que utilice una red WAN. Si examinamos el método de selección de rutas, o encaminamiento, podemos clasificar una red como punto a punto o de difusión. En una red punto a punto, si un nodo quiere enviar un mensaje a todos los nodos, deberá enviar varios mensajes independientes. En una red de difusión, todos los nodos recibirán todos los mensajes, pero cada mensaje tiene un prefijo que identifica el nodo de destino, por lo que los demás nodos simplemente ignorarán los mensajes que no vayan dirigidos a ellos. Las redes WAN se basan generalmente en una red punto a punto, mientras que las redes LAN utilizan por regla general mecanismos de difusión. En la Tabla 22.2 se presenta un resumen de las características típicas de las redes WAN y LAN. Tabla 22.2. Resumen de las características típicas de las redes WAN y LAN. WAN Distancias de hasta miles de kilómetros Enlaza computadoras autónomas Red gestionada por una organización independiente (utilizando enlaces telefónicos o vía satélite) LAN Distancias de unos pocos kilómetros Enlaza computadoras que cooperan en aplicaciones distribuidas Red gestionada por los usuarios (utilizando cables de propiedad privada) Velocidad de datos de hasta 33,6 kbit/s (acceso tele- Velocidad de datos de hasta 2500 Mbit/s (ATM). Actualmente fónico por módem), 45 Mbit/s (circuito T3) están en desarrollo las redes Ethernet a 10 gigabits (10.000 millones de bits por segundo) Protocolo complejo Utiliza encaminamiento punto a punto Utiliza topologías irregulares Tasa de errores de aproximadamente 1:105 Protocolo más simple Utiliza encaminamiento por difusión Utiliza topologías de bus o anillo Tasa de errores de aproximadamente 1:109
  • 62. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 637 La organización ISO (International Organization for Standardization) ha definido un protocolo que gobier- na la forma en que los sistemas pueden comunicarse (ISO, 1981). El enfoque adoptado consiste en dividir la red en una serie de niveles, proporcionando cada nivel un servicio concreto al nivel situado por encima suyo, al mismo tiempo que oculta los detalles de implementación. El protocolo, denominado modelo de intercone- xión de sistemas abiertos (OSI, Open Systems Interconnection) está compuesto por siete niveles indepen- dientes. Los niveles se encargan de la transmisión de bits a través de la red, de la gestión de la conexión y de garantizar que el enlace esté libre de errores, del encaminamiento y el control de congestión, de la gestión de sesiones entre diferentes máquinas y de resolver las diferencias de formato y de representación de los datos entre unas máquinas y otras. No es necesario proporcionar una descripción de este protocolo para compren- der los tres capítulos que en este libro dedicamos al tema de los SGBD distribuidos y móviles, por lo que el lector interesado puede consultar Halsall (1995) y Tanenbaum (1996). CCITT (International Telegraph and Telephone Consultative Committee) ha elaborado un estándar cono- cido como X.25 que cumple con los tres niveles inferiores de esta arquitectura. La mayoría de los SGBDD están desarrollados para utilizar X.25. Sin embargo, se están desarrollando ahora nuevos estándares para los niveles superiores que pueden proporcionar servicios útiles para los SGBDD, como por ejemplo RDA (Remote Database Access) para el acceso remoto a bases de datos (ISO 9579) o DTP (Distributed Transaction Processing) para el procesamiento distribuido de transacciones (ISO 10026). Examinaremos el estándar DTP de X/Open en la Sección 23.5. Como información de referencia adicional, vamos a repasar ahora brevemen- te los principales protocolos de comunicación por red. Protocolos de red Protocolo de red Un conjunto de reglas que determina cómo se envían, interpretan y procesan los mensajes entre computadoras. En esta sección vamos a describir brevemente los principales protocolos de red. TCP/IP {Transmission Control Protocol/lnternet Protoco!} Este es el protocolo estándar de comunicaciones para Internet, una colección mundial de redes informáticas interconectadas. TCP es responsable de verificar la correcta entrega de los datos intercambiados entre los clientes y los servidores. IP proporciona el mecanismo de encaminamiento, basado en una dirección de des- tino de cuatro bytes (la dirección IP). La parte delantera de la dirección IP indica la parte de red, mientras que la parte trasera indica la parte de la dirección correspondiente al host. La línea divisoria entre las partes de red y de host de una dirección IP no es fija. TCP/IP es un protocolo encaminable, lo que significa que los mensa- jes no sólo contienen la dirección de la estación de destino, sino también la dirección de la red de destino. Esto permite que los mensajes TCP/IP sean enviados a múltiples redes dentro de una organización o distribuidas por todo el mundo, lo cual es la razón de que se utilice este protocolo en Internet. SPX/IPX (Sequenced Packet Exchange/lnternetwork Package Exchange) Novell creó el protocolo SPX/IPX como parte de su sistema operativo NetWare. Similar a TCP, SPX garanti- za que un mensaje llegue intacto, aunque difiere de TCP en que utiliza el protocolo IPX de NetWare como mecanismo de entrega. Al igual que IP, IPX se encarga de encaminar los paquetes a través de la red, pero a diferencia de aquél, IPX utiliza un espacio de direcciones de 80 bits, con una parte de red de 32 bits y una parte de host de 48 bits (este espacio de direccionamiento es mucho mayor que los 32 bits usados por IP para las direcciones). Asimismo, a diferencia de IP, IPX no se encarga de la fragmentación de paquetes. Sin embar- go, una de las grandes ventajas de IPX es su sistema de direccionamiento automático de host. Los usuarios pueden mover su PC de una ubicación de la red a otra y continuar trabajando simplemente volviendo a conec- tarse. Esto es particularmente importante para los usuarios móviles. Hasta la aparición de NetWare 5, SPX/IPX era el protocolo predeterminado de las redes de Novell, pero para reflejar la importancia de Internet, NetWare 5 ha adoptado TCP/IP como protocolo predeterminado.
  • 63. 638 Sistemas de bases de datos NetBIOS (Network Basic Input/Output System) Es un protocolo de red desarrollado en 1984 por IBM y Sytek como estándar para la comunicación entre apli- caciones basadas en PC. Originalmente NetBIOS y NetBEUI (NetBIOS Extended User Interface) se conside- raban un mismo protocolo. Posteriormente, se decidió separar NetBIOS, ya que podía utilizarse con otros pro- tocolos de transporte encaminables, por lo que hoy en día las sesiones NetBIOS pueden transportarse sobre NetBEUI, TCP/IP y SPX/IPX. NetBEUI es un protocolo rápido, eficiente y con poca carga de procesamien- to adicional. Sin embargo, tiene la desventaja de que no es encaminable, por lo que una configuración típica utiliza NetBEUI para la comunicación dentro de la LAN y TCP/IP para las comunicaciones que transciendan las fronteras de ésta. APPC (Advanced Program-to-Program Communications) Un protocolo de comunicaciones de alto nivel desarrollado por IBM que permite que un programa interactúe con otro a través de una red. Soporta la arquitectura cliente-servidor y el procesamiento distribuido propor- cionando una interfaz de programación común para todas las plataformas IBM. Proporciona comandos para gestionar una sesión, para enviar y recibir datos y para la gestión de transacciones mediante un protocolo de confirmación en dos fases (tema del que hablaremos en el siguiente capítulo). El software APPC forma parte de todos los sistemas operativos IBM y de muchos no IBM, o constituye una opción que puede adquirirse por separado. Puesto que APPC sólo soportaba originalmente la arquitectura SNA (Systems Network Architecture) de IBM, que utiliza el protocolo LU 6.2 para establecimiento de sesiones, APPC y LU 6.2 se consideran a menudo sinónimos. DECnet DECnet es el protocolo de comunicaciones encaminable de Digital, que soporta redes LAN estilo Ethernet y redes WAN de banda base y de banda ancha sobre líneas privadas o públicas. Interconecta máquinas PDP, VAX, PC, Mac y estaciones de trabajo. AppleTalk Es el protocolo encaminable de Apple para redes LAN presentado en 1985, que soporta el método de acceso LocalTalk propietario de Apple, además de Ethernet y Token Ring. El gestor de red AppleTalk y el método de acceso LocalTalk están integrados en todas las computadoras Macintosh y en las impresoras LaserWriters. W AP (Wireless Application Protocoll Un estándar para proporcionar a los teléfonos móviles, buscapersonas y otros dispositivos de mano un acce- so seguro a los servicios de correo electrónico y a las páginas web basadas en texto. Introducido en 1997 por Phone.com (antiguamente denominada Unwired Planet), Ericsson, Motorola y Nokia, WAP proporciona un entorno completo para aplicaciones inalámbricas que incluye un equivalente inalámbrico de TCP/IP y un entorno de aplicación para integración telefónica, como por ejemplo para control de llamadas y acceso a lis- tines telefónicos. Tiempo de comunicación El tiempo necesario para enviar un mensaje depende de la longitud del mensaje y del tipo de red que se esté utilizando. Puede calcularse utilizando la fórmula: Tiempo de comunicación = Ca+ (nO_de_bits_en_mensaje/velocidad_transmisión) donde Ca es un coste fijo de iniciación de un mensaje, denominado retardo de acceso. Por ejemplo, utilizan- do un retardo de acceso de 1 segundo y una velocidad de transmisión de 10000 bits por segundo, podemos calcular el tiempo necesario para enviar 100000 registros compuestos cada uno de 100 bits: Tiempo de comunicación = 1 + (100000*100/10000) = 1001 segundos Si queremos transferir 100000 registros de uno en uno, obtenemos
  • 64. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 639 Tiempo de comunicación = 100000 * [1+(100/10000)] = 100000 * [1.01] = 101000 segundos Obviamente, el tiempo de comunicación es significativamente mayor si se transfieren 100000 individual- mente, debido al retardo de acceso. En consecuencia, un objetivo de un SGBDD es minimizar tanto el volu- men de los datos transmitidos a través de la red como el número de transmisiones de red. Volveremos sobre este punto cuando hablemos de la optimización de consultas distribuidas en la Sección 22.5.3. 22.3 Funciones y arquitectura de un SGBDD En el Capitulo 2 hemos examinado las funciones, la arquitectura y los componentes de un mensaje descentra- lizado. En esta sección, vamos a ver cómo afecta la distribución a la funcionalidad esperada y a la arquitec- tura de los sistemas de gestión de bases de datos. 22.3.1 Funciones de un SGBDD Lo que esperamos de un SGBDD es que tenga al menos la funcionalidad de un SGBD centralizado, funcio- nalidad que hemos expuesto en el Capítulo 2. Además, esperamos que el SGBDD proporcione la siguiente funcionalidad adicional: • servicios avanzados de comunicaciones para proporcionar acceso a nodos remotos y permitir la trans- ferencia de consultas y de datos entre los nodo s a través de una red; • un catálogo ampliado del sistema en el que se almacenen los detalles relativos a la distribución de los datos; • procesamiento avanzado de consultas, incluyendo mecanismos de optimización de consultas y de acce- so remoto a datos; • un control avanzado de seguridad para mantener los apropiados privilegios de autorización/acceso a los datos distribuidos; • mecanismos avanzados de control de concurrencia para mantener la coherencia de los datos distribui- dos y posiblemente replicados: • servicios avanzados de recuperación para tener en cuenta los fallos de los nodos individuales y los fallos de los enlaces de comunicaciones. Hablaremos de estos temas con más profundidad en las secciones posteriores, asi como en el Capítulo 23. 22.3.2 Arquitectura de referencia para un SGBDD La arquitectura en tres niveles ANSI-SPARC para un SGBD presentada en la Sección 2.1 proporciona una arquitectura de referencia para un SGBD centralizado. Debido a la diversidad de sistemas SGBD distribuidos, resulta mucho más difícil presentar una arquitectura equivalente que sea de general aplicación. Sin embargo, puede resultar útil presentar una posible arquitectura de referencia que contemple la distribución de datos. La arquitectura de referencia mostrada en la Figura 22.4 está compuesta de los siguientes esquemas: • un conjunto de esquemas externos globales; • un esquema conceptual global; • un esquema de fragmentación y un esquema de asignación; • un conjunto de esquemas para cada SGBD local conformes a la arquitectura en tres niveles de ANSI- SPARC. Las aristas de esta figura representan correspondencias entres los distintos esquemas. Dependiendo de qué niveles de transparencia estén soportados, puede que algunos niveles no estén presentes en una arquitectura de un sistema concreto.
  • 65. )640 Sistemas de bases de datos ••• Esquema externo global Esquema externo global Esquema conceptual global Esquema de fragmentación Esquema externo global Esquema de asignación S, S2•••Sn Esquema de Esquema de correspondencia correspondencia local local =r L:quema II Esquema conceptual conceptual local local rsquema I I Esquema internointernolocallocal BD BD BD Figura 22.4. Arquitectura de referencia para un SGBDD. Esquema conceptual global El esquema conceptual global es una descripción lógica de toda la base de datos, como si ésta no estuviera distribuida. Este nivel se corresponde con el nivel conceptual de la arquitectura ANSI-SPARC y contiene defi- niciones de entidades, relaciones, restricciones, mecanismos de seguridad e información de integridad. Proporciona independencia física de los datos con respecto al entorno distribuido. Los esquemas externos glo- bales proporcionan independencia lógica de los datos. Esquemas de fragmentación y asignación El esquema de fragmentación es una descripción del modo en que hay que particionar lógicamente los datos. El esquema de asignación es una descripción de dónde hay que ubicar los datos, teniendo en cuenta los meca- nismos de replicación utilizados.
  • 66. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 641 Esquemas locales Cada SGBD local tiene su propio conjunto de esquemas. Los esquemas conceptual e interno locales se corres- ponden con los niveles equivalentes de la arquitectura ANSI-SPARC. El esquema de correspondencia local establece la correspondencia entre los fragmentos del esquema de asignación y los objetos externos de la base de datos local. Este nivel es independiente del SGBD y es la base para el soporte de sistemas SGBD hetero- géneos. 22.3.3 Arquitectura de referencia para un MDBS federado En la Sección 22.1.3 hemos hablado brevemente de los sistemas multi-base de datos (MDBS) federados. Los sistemas federados difieren de los SGBDD en el nivel de autonomía local permitido. Esta diferencia se refle- ja también en la arquitectura de referencia. La Figura 22.5 ilustra una arquitectura de referencia para un sis- tema multi-base de datos federado estrechamente acoplado, es decir, que tiene un esquema conceptual global. En un SGBDD, el esquema conceptual global es la unión de todos los esquemas conceptuales locales. Por el contrario, en un MDBS federado, el esquema conceptual global es un subconjunto de los esquemas con- ceptuales locales, compuesto de los datos que cada sistema local decide compartir. El esquema conceptual glo- bal en un sistema fuertemente acoplado implica la integración de partes de los esquemas conceptuales locales o de los esquemas externos locales . 8, Esquema externo global Esquema externo local Esquema externo local • • • • Esquema conceptual global Esquema externo local Esquema externo global Esquema externo local Esquema conceptual local Esquema interno local BD Esquema conceptual local Esquema interno local BD Figura 22.5. Arquitectura de referencia para un MDBS federado fuertemente acoplado.
  • 67. 642 Sistemas de bases de datos Algunos autores argumentan que un MDBS federado no debe tener un esquema conceptual global (Litwin, 1988), en cuyo caso se dice que el sistema está débilmente acoplado. En este caso, los esquemas externos están compuestos por uno o más esquemas conceptuales locales. Para obtener información adicional sobre los MDBS, el lector interesado puede consultar Litwin (1988) y Sheth y Larson (1990). 22.3.4 Componentes de un SGBDD Independientemente de la arquitectura de referencia, podemos identificar cuatro componentes principales en un SGBDD: • SGBD local (SGBDL); • componente de comunicaciones de datos (CD); • catálogo global del sistema (CGS); • SGBD distribuido. La arquitectura de componentes de un SGBDD basada en la Figura 22.1 se ilustra en la Figura 22.6. Para una mayor claridad, hemos omitido el Nodo 2 del diagrama, ya que tiene la misma estructura que el Nodo 1. SGBD local El SGBD local es un SGBD estándar, responsable de controlar los datos locales en cada nodo que tenga una base de datos. Tiene su propio catálogo local del sistema que almacena información acerca de los datos con- tenidos en dicho nodo. En un sistema homogéneo, todos los SGBD locales serán el mismo producto, replica- do en cada nodo. En un sistema heterogéneo, habrá al menos dos nadas con diferentes productos SGBD y/o plataformas. Componentes de comunicación de datos El componente de comunicación de datos es el software que permite que todos los nodos se comuniquen entre sí. El componente de comunicación de datos contiene información acerca de los nodos y de los enlaces. Nodo 1 CGS SGBDD CD Nodo 3 CGS BD Figura 22.6. Componentes de un SGBDD.
  • 68. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 643 Catálogo global del sistema El catálogo global del sistema tiene la misma funcionalidad que el catálogo del sistema en un sistema centra- lizado. El catálogo global del sistema mantiene información específica de la naturaleza distribuida del siste- ma, como por ejemplo los esquemas de fragmentación, replicación y asignación. El propio catálogo puede ser gestionado como una base de datos distribuida, por lo que puede estar fragmentado y distribuido, completa- mente replicado o centralizado, como cualquier otra relación, según veremos en breve. Un catálogo global del sistema completamente replicado pone en cuestión la autonomía de los nodos, ya que toda modificación del catálogo global del sistema tendrá que ser comunicada a todos los demás nodos. Un catálogo global del sis- tema centralizado también pone en cuestión la autonomía de los nodos y es vulnerable a los fallos del nodo central. La solución adoptada en el sistema distribuido R* resuelve estos problemas (Williams et al., 1982). En R*, hay un catálogo local en cada nodo que contiene los metadatos relativos a los datos que se almacenan en dicho nodo. Para las relaciones creadas en un cierto nodo (el nodo de creación), es responsabilidad del catálogo local de dicho nodo registrar la definición de cada fragmento y de cada réplica de cada fragmento, así como de registrar la ubicación de cada fragmento o réplica. Cuando un fragmento de réplica se mueve a una ubica- ción distinta, el catálogo local del correspondiente nodo de creación de la relación deberá ser actualizado. Así, para localizar un fragmento o réplica de una relación, es necesario acceder al catálogo del nodo de creación de dicha relación. El nodo de creación de cada relación global se registra en cada catálogo local del sistema. Volveremos sobre el tema de la denominación de objetos cuando hablemos de la transparencia de denomina- ción en la Sección 22.5.1. SGBD distribuido El SGBDD es la unidad de control del sistema completo. Ya hemos explicado brevemente la funcionalidad de este componente en la sección anterior y hablaremos más en detalle de dicha funcionalidad en la Sección 22.5 y en el Capítulo 23. 22.4 Diseño de bases de datos relacionales distribuidas En los Capítulos 15 y 16 hemos presentado una metodología para el diseño conceptual y lógico de una base de datos relacional centralizada. En esta sección, vamos a examinar los factores adicionales que hay que tener en cuenta para el diseño de una base de datos relacional distribuida. Más específicamente, vamos a examinar los siguientes conceptos: • Fragmentación. Una relación puede dividirse en una serie de subrelaciones, denominadas fragmen- tos, que a continuación se distribuyen. Hay dos tipos principales de fragmentación: horizontal y ver- tical. Los fragmentos horizontales son subconjuntos de tuplas, mientras que los fragmentos verticales son subconjuntos de atributos. • Asignación. Cada fragmento se almacena en el nodo 'óptimo' desde el punto de vista de la distribu- ción. • Replicación. El SGBDD puede mantener una copia de un fragmento en varios nodos diferentes. La definición y asignación de fragmentos debe estar basada en el modo en que se va a utilizar la base de datos. Esto implica analizar las transacciones. Generalmente, no es posible analizar todas las transacciones, por lo que habremos de concentramos en las más importantes. Como hemos indicado en la Sección 17.2, algu- nos autores sugieren que el 20% de consultas de usuario más utilizadas representan el 80% de los accesos tota- les a los datos, y esta regla 80/20 puede utilizarse como guía a la hora de llevar a cabo el análisis (Wiederhold, 1983). El diseño debe estar basado en información tanto cuantitativa como cualitativa. La información cuantita- tiva se usa para la asignación; la información cualitativa se usa durante la fragmentación. La información cuantitativa puede incluir: • la frecuencia con la que se ejecuta cada transacción;
  • 69. 644 Sistemas de bases de datos • el nodo desde el que se ejecuta una transacción; • los criterios de rendimiento para las transacciones. La información cualitativa puede incluir información acerca de las transacciones que se ejecutan, como por ejemplo: • las relaciones, atributos y tuplas a las que se accede; • el tiempo de acceso (lectura o escritura); • los predicados de las operaciones de lectura. La definición y asignación de fragmentos se lleva a cabo de manera estratégica para conseguir los siguien- tes objetivos: • Localidad de referencia. Siempre que sea posible los datos deben almacenarse en un punto próximo al de su utilización. Si un fragmento se utiliza en varios nadas, puede ser conveniente almacenar copias del fragmento en todos esos nadas. • Mayor fiabilidad y disponibilidad. La fiabilidad y la disponibilidad se mejoran gracias a la replicación: hay otra copia del fragmento disponible en otro nodo, en caso de que uno de los nadas falle. • Rendimiento aceptable. Una mala asignación puede dar como resultado la aparición de cuellos de bote- lla, es decir, que un nodo se vea inundado de solicitudes procedentes de otros nadas, lo que quizá trai- ga consigo una degradación significativa en el rendimiento. Alternativamente, una mala asignación puede provocar una infrautilización de los recursos. • Equilibrio entre la capacidad de almacenamiento y el coste. Debe prestarse atención a la disponibili- dad y coste del almacenamiento en cada nodo, para que puedan utilizarse soportes de almacenamien- to masivo de bajo coste, siempre que sea posible. Este criterio debe equilibrarse con el de localidad de referencia. • Costes de comunicaciones mínimos. También hay que prestar atención al coste de las solicitudes remo- tas. Los costes de extracción de datos se minimizan cuando se optimiza la localidad de referencia o cuando cada nodo dispone de su propia copia de los datos. Sin embargo, cuando se actualizan los datos replicados, la actualización debe llevarse a cabo en todos los nadas que mantengan una copia duplica- da, incrementándose así los costes de comunicaciones. 22.4.1 Asignación de los datos Hay cuatro estrategias alternativas en lo que respecta a la ubicación de los datos: centralizada, fragmentada, replicación completa y replicación selectiva. Vamos a comparar estas estrategias utilizando los objetivos que acabamos de identificar. Centralizada Esta estrategia se basa en un único SGBD y una única base de datos almacenada en un nodo, estando los usua- rios distribuidos por toda la red (anteriormente hemos denominado a esta estrategia 'procesamiento distribui- do'). La localidad de referencia es pésima, ya que todos los nadas (excepto en el nodo central) tienen que utilizar la red para todos los accesos a datos. Esto significa también que los costes de comunicaciones son altos. La fiabilidad y la disponibilidad son bajas, ya que un fallo en el nodo central tiene como resultado la pérdida de todo el sistema de base de datos. Fragmentada (o particionada) Esta estrategia particiona la base de datos en una serie de fragmentos disjuntos, estando cada fragmento asig- nado a un nodo. Si los elementos de datos están ubicados en el nodo donde se les usa más frecuentemente, la localidad de referencia será alta. Como no hay ninguna replicación, los costes de almacenamiento son bajos; de forma similar, la fiabilidad y la disponibilidad también son bajas, aunque superiores a las del caso centra- lizado, ya que el fallo de un nodo hace que sólo se pierdan los datos de dicho nodo. Las prestaciones pueden
  • 70. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 645 ser buenas y los costes de comunicación bajos, siempre y cuando los mecanismos de distribución hayan sido diseñados apropiadamente. Replicación completa Esta estrategia consiste en mantener una copia completa de la base de datos en cada nodo. Como consecuen- cia, la localidad de referencia, la fiabilidad, la disponibilidad y las prestaciones se maximizan. Sin embargo, los costes de almacenamiento y los costes de comunicaciones para las organizaciones son máximos. Para resolver algunos de estos problemas, se utilizan en ocasiones las denominadas instantáneas. Una instantánea es una copia de los datos en un instante concreto. Dichas copias se actualizan periódicamente, como por ejem- plo cada hora o cada semana, así que puede que no siempre estén actualizadas. En ocasiones, las instantáneas se utilizan también para implementar las vistas en una base de datos distribuida, con el fin de mejorar el tiem- po que se tarda en realizar una operación de base de datos sobre una vista. Hablaremos de las instantáneas en la Sección 24.6.2. Replicación selectiva Esta estrategia es una combinación de fragmentación, replicación y centralización. Algunos elementos de datos se fragmentan para conseguir una alta localidad de referencia, mientras que otros, que se utilizan en muchos nodo s y no se actualizan frecuentemente, se replican; todos los demás elementos de datos se centra- lizan. El objetivo de esta estrategia es conseguir todas las ventajas de las otras técnicas, pero sin ninguna de las desventajas. Esta es la estrategia más comúnmente utilizada, debido a su flexibilidad. La Tabla 22.3 resu- me las distintas estrategias. Para obtener más detalles sobre el tema de asignación, el lector interesado puede consultar Ozsu y Valduriez (1999) y Teorey (1994). 22.4.2 Fragmentación ¿Por qué fragmentar? Antes de hablar en detalle de la fragmentación, indiquemos cuatro razones para fragmentar una relación: • Utilización. En general, las aplicaciones funcionan con vistas, en lugar de con relaciones completas. Por tanto, para la distribución de datos, parece apropiado trabajar con subconjuntos de las relaciones como unidad de distribución . • Eficiencia. Los datos se almacenan cerca del lugar donde se los utiliza más frecuentemente. Además, los datos que las aplicaciones locales no necesitan no se almacenan en ese nodo. Tabla 22.3. Comparación de estrategias para la asignación de datos. Localidad de referencia Fiabilidad y disponibilidad Prestaciones Costes de almacenamiento Costes de comunicaciones Centralizada MínimaMínimaInsatisfactoriaMínimosMáximosAlta'Baja para losSatisfactoria'MínimosBajos' para el sistema MáximaMáximaMáximas paraMáximosAltos para actuali- lecturazación; bajos para lectura Alta'Baja para losSatisfactoria'MediosBajos' elementos; alta para el sistema--un buen diseño.
  • 71. 646 Sistemas de bases de datos • Paralelismo. Utilizando el fragmento como unidad de distribución, una transacción puede dividirse en varias sub consultas que operan sobre distintos fragmentos. Esto debería permitir incrementar el grado de concurrencia o paralelismo en el sistema, permitiendo así que se ejecuten en paralelo aquellas trans- acciones que puedan paralelizarse con seguridad. • Seguridad. Los datos no requeridos por las aplicaciones locales no se almacenan en ese nodo y, con- secuentemente, no están disponibles para los usuarios no autorizados. La fragmentación tiene dos desventajas principales, que ya hemos mencionado antes: • Rendimiento. El rendimiento de las aplicaciones globales que requieren datos de diversos fragmentos ubicados en diferentes nadas puede ser menor. • Integridad. El control de integridad puede ser más dificil si los datos y las dependencias funcionales están fragmentados y ubicados en nadas distintos. Corrección de la fragmentación La fragmentación no puede llevarse a cabo descuidadamente. Hay tres reglas que es preciso respetar durante la fragmentación: (1) Completud. Si una instancia R de una relación se descompone en fragmentos R¡, Rz, ... , Rm cada ele- mento de datos que aparezca en R debe aparecer al menos en un fragmento. Esta regla es necesaria para garantizar que no haya pérdida de datos durante la fragmentación. (2) Reconstrucción. Debe ser posible definir una operación relacional que permita reconstruir la relación R a partir de los fragmentos. Esta regla garantiza que se preserven las dependencias funcionales. (3) Disyunción. Si un elemento de datos d¡ aparece en el fragmento R¡, no debe aparecer en ningún otro fragmento. La fragmentación vertical es la excepción a esta regla, ya que los atributos de clave princi- pal deberán estar repetidos para permitir la reconstrucción de la relación. Esta regla garantiza una redundancia mínima de los datos. En el caso de la fragmentación horizontal, el elemento de datos es la tupla; para la fragmentación vertical, el elemento de datos es un atributo. Tipos de fragmentación Hay dos tipos principales de fragmentación: horizontal y vertical. Los fragmentos horizontales son subcon- juntos de tuplas y los fragmentos verticales son subconjuntos de atributos, como se ilustra en la Figura 22.7. Hay también otros dos tipos de fragmentación: mixta, ilustrada en la Figura 22.8, y derivada, un tipo de frag- mentación horizontal. Vamos a proporcionar a continuación ejemplos de los diferentes tipos de fragmentación, utilizando la instancia de la base de datos de DreamHome mostrada en la Figura 3.3. (a) (b) Figura 22.7. (a) Fragmentación horizontal y (b) fragmentación vertical.
  • 72. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 647 (a) (b) Figura 22.8. Fragmentación mixta: (a) fragmentos verticales fragmentados horizontalmente; (b) fragmentos horizontales fragmentados verticalmente. Fragmentación horizontal Fragmento horizontal Está compuesto de un subconjunto de las tuplas de una relación. La fragmentación horizontal agrupa las tuplas de una relación que son utilizadas de manera colectiva por las transacciones de mayor importancia. Los fragmentos horizontales se generan especificando un predicado que imponga una restricción a las tuplas de la relación. Dicho predicado se define utilizando la operación de selec- ción del álgebra relacional (véase la Sección 4.1.1). La operación de selección agrupa tuplas que tengan algu- na propiedad común; por ejemplo, las tuplas que sean utilizadas por una misma aplicación o que sean utiliza- das en un mismo nodo. Dada una relación R, un fragmento horizontal se define como: (Jp(R) donde p es un predicado basado en uno o más atributos de la relación. I Ejemplo 22.2 Fragmentación horizontal Suponiendo que sólo haya dos tipos de inmuebles, Flat (apartamento) y House (casa), la fragmenta- ción horizontal de PropertyForRent de acuerdo con el tipo de inmueble puede obtenerse de la forma siguiente: P1: (Jtype='House·(PropertyForRent) P2: lTtype='Flar(PropertyForRent) Esto genera dos fragmentos (p¡ y P2), uno compuesto por aquellas tuplas para las que el valor del atri- buto type es 'House' y el otro compuesto por aquellas tuplas para las que el valor del atributo type es 'Flat', como se muestra en la Figura 22.9. Esta estrategia de fragmentación concreta puede ser venta- josa si se utilizan aplicaciones distintas para gestionar las casas y los apartamentos. El esquema de fragmentación satisface las reglas de corrección: Fragmento P1 propertyNo streetcitypostcodetyperoomsrentownerNostaffNobranchNo16 HolheadAberdeenAB75SUHouse6650C046 SA9B00718 Dale RdGlasgowG12House5600C087 SG37B003 Fragmento P2 propertyNo streetcitypostcodetyperoomsrentownerNostaffNobranchNo6Argyll StLondonNW2Flat4 400C087 SL41B0056 Lawrence StGlasgowG119QXFlat3 350C040 SG14B0032 ManorRdGlasgowG324QXFlat3 375C093 SG37B0035 Novar DI'GlasgowG129AXFlat4 450C093 SG14B003 Figura 22.9. Fragmentación horizontal de PropertyForRent de acuerdo con el tipo de inmueble.
  • 73. 648 Sistemas de bases de datos • Completud. Cada tupla de la relación aparece en el fragmento PI o en el fragmento P2. • Reconstrucción. La relación PropertyForRentpuede reconstruirse a partir de los fragmentos utilizan- do el operador de unión: P, U P2 = PropertyForRent • Disyunción. Los fragmentos son disjuntos; no puede haber ningún inmueble que sea a la vez de tipo 'House'y 'Flat'. ~ En ocasiones, la elección de la estrategia de fragmentación horizontal resulta obvia. Sin embargo, en otros casos, es necesario analizar la aplicación en detalle. El análisis implica un examen de los predicados (o con- diciones de búsqueda) usados por las transacciones o consultas en las aplicaciones. Los predicados pueden ser simples, implicando un solo atributo, o complejos, implicando múltiples atributos. Los predicados para cada atributo pueden ser univaluados o multivaluados. En este último caso, los valores pueden ser discretos o impli- car rangos de valores. La estrategia de fragmentación requiere encontrar un conjunto de predicados mínimo (es decir, completo y relevante) que pueda usarse como base para el esquema de fragmentación (Ceri et al., 1982). Un conjunto de predicados es completo si y sólo si cualquiera de las dos tuplas del mismo fragmento se referencian con la misma probabilidad por cualquier transacción. Un predicado es relevante si existe al menos una transac- ción que acceda de manera distinta a los fragmentos resultantes. Por ejemplo, si el único requisito es selec- cionar tuplas de PropertyForRentbasándose en el tipo de inmueble, el conjunto {type = 'House', type = 'Flat'} es completo, mientras que el conjunto {type = 'House'} no es completo. Por otro lado, con este requisito, el predicado (city = 'Aberdeen') no sería relevante. Fragmentación vertical Fragmento vertical Está compuesto de un subconjunto de los atributos de una relación. El mecanismo de fragmentación vertical agrupa los atributos de una relación que son utilizados de manera conjunta por las transacciones de mayor importancia. Un fragmento vertical se define utilizando la operación de proyección del álgebra relacional (véase la Sección 4.1.1). Dada una relación R, un fragmento vertical se define como: Da", " a/R) donde al' ... , an son atributos de la relación R. I Ejemplo 22.3 Fragmentación vertical La aplicación de nóminas de DreamHome requiere el número de empleado staffNoy los atributos posi- tion, sex, DOB y salary de cada empleado; el departamento de personal requiere los atributos staffNo, fName, IName y branchNo. La fragmentación vertical de Staffpara este ejemplo puede obtenerse de la forma siguiente: 81: IIstaffNo, position, sex, 008, salary(Staff) 82: IIstaffNo, fName, IName, branchNo(Staff) Esto produce dos fragmentos (SI y S2), como se muestra en la Figura 22.10. Observe que ambos frag- mentos contienen la clave principal, staffNo,para permitir reconstruir la relación original. La ventaja de la fragmentación vertical es que los fragmentos pueden almacenarse en los nodos que los necesitan. Además, las prestaciones se mejoran, ya que el fragmento es más pequeño que la relación base origi- nal. Este esquema de fragmentación satisface las reglas de corrección:
  • 74. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 649 Fragmento S1 staffNo positionsexDOS salary SL21 ManagerM1-0ct-4530000 SG37 AssistantF10-Nov-6012000 SG14 SupervisorM24-Mar-5818000 SA9 AssistantF19-Feb-709000 SG5 ManagerF3-jun-4024000 SL41 AssistantF13-jun-659000 - staffNo fNameINamebranchNo SU1 johnWhiteB005 SG37 AnnBeechB003 SG14 DavidFordB003 SA9 MaryHoweB007 SG5 SusanBrandB003 SL41 julieLeeB005 Fragmento S2 Figura 22.10. Fragmentación vertical de 8taff. • Completud. Cada atributo de la relación Staff aparece en el fragmento SI o S2· • Reconstrucción. La relación Staff puede reconstruirse a partir de dos fragmentos utilizando la ope- ración de combinación natural: S, WS2 = Staff • Disyunción. Los fragmentos son disjuntos, salvo por la clave principal, que es necesaria para la reconstrucción. ~ Los fragmentos verticales se determinan estableciendo la afinidad de un atributo con otro. Una forma de hacer esto es crear una matriz que muestre el número de acceso que se refiere a cada pareja de atributos. Por ejemplo, una transacción que acceda a los atributos al' a2 Ya4 de la relación R con atributos (al, a2, a3, a4) puede representarse mediante la siguiente matriz: al a2 a3 a4 al l O l a2 O l a3 O a4 La matriz es triangular; no es necesario rellenar la diagonal, ya que la mitad inferior es una imagen espe- cular de la superior. Los unos representan un acceso que implica la correspondiente pareja de atributos, y se los puede reemplazar por números que representen la frecuencia de la transacción. Hay que crear una matriz para cada transacción y luego generar una matriz global que muestre la suma de todos los accesos para cada pareja de atributos. Las parejas con una alta afinidad deben aparecer en el mismo fragmento vertical; las pare- jas con baja afinidad pueden separarse. Claramente, si trabajamos con atributos individuales y con todas las transacciones principales, los cálculos pueden ser muy engorrosos. Por tanto, si se conoce que algunos atri- butos están relacionados, puede que sea mejor trabajar con grupos de atributos. Esta técnica se conoce con el nombre de división y fue propuesta por primera vez por Navathe et al. (1984). Genera un conjunto de fragmentos no solapados, lo que garantiza el cumplimiento de la regla de dis- función anteriormente definida. De hecho, la característica de no solapamiento se aplica únicamente a los atri- butos que no forman parte de la clave principal. Los campos de la clave principal aparecen en todos los frag-
  • 75. Fragmento mixto 650 Sistemas de bases de datos mentos, por lo que pueden omitirse del análisis. Para obtener información adicional sobre esta técnica, el lec- tor puede consultar Ozsu y Valduriez (1999). Fragmentación mixta Para algunas aplicaciones, la fragmentación horizontal o vertical de un esquema de base de datos pueden ser insuficientes por sí mismas para distribuir los datos adecuadamente. En su lugar, puede que se requiera una fragmentación mixta o híbrida. Está compuesto por un fragmento horizontal que se fragmenta a continuación ver- ticalmente, o por un fragmento vertical que se fragmenta a continuación horizontal- mente. Un fragmento mixto se define utilizando las operaciones de selección y proyección del álgebra relaciona. Dada una relación R, un fragmento mixto se define como: o (Da, .. a/up(R)) donde p es un predicado basado en uno o más atributos de R y al' ... , an son atributos de R. I Ejemplo 22.4 Fragmentación mixta En el Ejemplo 22.3, hemos fragmentado verticalmente Staff para los departamentos de nóminas y de personal, obteniendo: 81: llstaffNo, position,sex, DOB, sa'ary(Staff) 82: IlstaffNo, fName, IName, branchNO(Staff) Podríamos ahora fragmentar horizontalmente S2 de acuerdo con el número de sucursal (por simplici- dad, vamos a suponer que sólo hay tres sucursales): 821: abranchNo = 'B003,(82) 822: (TbranchNo = '8005,(82) 823: abranchNo = '8007'(82) Fragmento 51 staffNo positionsexDOS salaryManagerM1-0ct-4S30000AssistantF1O-Nov-6012000SupervisorM24-Mar-S818000AssistantF19-Feb-709000ManagerF3-Jun-4024000AssistantF13-Jun-6S9000 Fragmento 521 staffNo fNameINamebranchNo SG37 AnnBeechB003 SG14 DavidFordB003 SGS SusanBrandB003 Fragmento 522 staffNo fNameINamebranchNo SL21 JohnWhiteBOOS SL41 JulieLeeBOOS Fragmento 523 staffNo fNameINamebranchNo SA9 MaryHoweB007 Figura 22.11. Fragmentación mixta de Staff.
  • 76. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 651 Esto produce tres fragmentos (S21, S22 y S23), uno de ellos compuesto por tuplas para las que el núme- ro de sucursal es B003 (S21), otro compuesto de aquellas tuplas en las que el número de sucursal es B005 (S22) Yel otro compuesto de aquellas tuplas en las que el número de sucursal es B007 (S23)' como muestra la Figura 22.11. El esquema de fragmentación satisface las reglas de corrección: • Completud. Cada atributo de la relación Staff aparece en los fragmentos SI o en los fragmentos S2; cada tupla aparece (parcialmente) en el fragmento SI y en uno de los fragmentos S21, S22 o S23' • Reconstrucción. La relación Staff puede reconstruirse a partir de los fragmentos utilizando las' ope- raciones de unión y de combinación natural: S, [Xl (S21 U S22 u Sd = Staff • Disyunción. Los fragmentos son disjuntos; no puede haber ningún empleado que trabaje en más de una sucursal y SI Y S2 son disjuntos, salvo por la necesaria duplicación de la clave prinCiPal.~ Fragmentación horizontal derivada Algunas aplicaciones pueden implicar una combinación de dos o más relaciones. Si las relaciones están alma- cenadas en diferentes ubicaciones, puede haber una significativa cantidad de procesamiento extra debido a la combinación. En tales casos, puede ser más apropiado garantizar que las relaciones, o fragmentos de relacio- nes, se encuentren en la misma ubicación. Podemos conseguir esto mediante la fragmentación horizontal deri- vada. Fragmento derivado Un fragmento horizontal que está basado en la fragmentación horizontal de una relación padre. Utilizamos el término hija para referimos a la relación que contiene la clave externa y padre para hacer referencia a la relación que contiene una clave principal de destino. La fragmentación derivada se define uti- lizando la operación de semicombinación del álgebra relacional (véase la Sección 4.1.3). Dada una relación hija R y otra padre s, la fragmentación derivada de R se define como: donde w es el número de fragmentos horizontales definidos sobre S y f es el atributo de combinación. I Ejemplo 22.5 Fragmentación horizontal derivada Podemos tener una aplicación que combine las relaciones Staff y PropertyForRent. Para este ejemplo, vamos a asumir que Staff está fragmentada horizontalmente de acuerdo con el número de sucursal, de modo que los datos relativos a la sucursal se almacenan localmente: S3 = (TbranchNo= 'B003,(Staff) S4 = (TbranchNo= 'Boos,(Staff) S5 = (TbranchNo= 'BOO7'(Staff) Vamos a asumir también que el inmueble PG4 está siendo gestionado actualmente por SG 14. Sería útil almacenar los datos de los inmuebles utilizando la misma estrategia de fragmentación. Esto se consi- gue empleando la fragmentación derivada para fragmentar horizontalmente la relación PropertyForRent de acuerdo con el número de sucursal: p¡= PropertyForRent bs1af1NOS¡ 3 $ i$ 5 Esto produce tres fragmentos (P3, P4 Y ps), uno compuesto por los inmuebles gestionados por los empleados de la sucursal número B003 (P3), otro compuesto por los inmuebles gestionados por los empleados de la sucursal B005 (P4) y el otro compuesto de los inmuebles gestionados por el per-
  • 77. 652 Sistemas de bases de datos Fragmento P3 propertyNo streetcitypostcodetyperoomsrentownerNostaffNo6 Lawrence StGlasgowG119QXFlat3350C040 SG142 ManorRdGlasgowG324QXFlat3375C093SG3718 Dale RdGlasgowG12House 5600C087SG375 Novar DrGlasgowG129AXFlat4450C093SG14 Fragmento P4 propertyNo streetcitypostcodetyperoomsrentownerNostaffNo6 Argyll StLondonNW2Flat4400C087SL41 Fragmento Ps propertyNo streetcítypostcodetyperoomsrentownerNostaffNo16 HolheadAberdeenAB75SUHouse6650C046SA9 Figura 22.12. Fragmentación derivada de PropertyForRent basada en Staff. sonal de la sucursal B007 (ps), como se muestra en la Figura 22.12. Podemos ver fácilmente que este esquema de fragmentación satisface las reglas de corrección. Dejamos esto como ejercicio para el lector. Si una relación contiene más de una clave externa, será necesario seleccionar como padre una de las relaciones referenciadas. La elección puede estar basada en la fragmentación que se utilice más fre- cuentemente o en la fragmentación que exhiba mejores características de combinación, es decir, la combinación que implique fragmentos más pequeños o la combinación que pueda llevarse a cabo con un mayor grado de paralelismo. ~ Sin fragmentación Una última estrategia consiste en no fragmentar una relación. Por ejemplo, la relación Branch contiene sólo un pequeño número de tuplas y no se actualiza muy frecuentemente. En lugar de tratar de fragmentar horizontal- mente la relación de acuerdo con, por ejemplo, el número de sucursal, sería más lógico conservar la relación completa y simplemente replicada en cada uno de los nodos. Resumen de la metodología de diseño de una base de datos distribuida Ahora podemos presentar una metodología resumida para el diseño de bases de datos distribuidas. (1) Utilizar la metodología descrita en los Capítulos 15 y 16 para obtener un diseño de las tablas globales. (2) Adicionalmente, examinar la topología del sistema. Por ejemplo, considerar si DreamHome tendrá una base de datos en cada sucursal, o en cada ciudad, o posiblemente a nivel regional. En el primer caso, puede que resulte apropiado fragmentar las tablas de acuerdo con el número de sucursal. Sin embargo, en los últimos dos casos, sería quizá más apropiado tratar de fragmentar las tablas según la ciudad o la región. (3) Analizar las transacciones más importantes del sistema e identificar si conviene utilizar fragmentación horizontal o vertical. (4) Decidir qué tablas no hay que fragmentar; estas tablas serán replicadas en todos los nodos. A partir del diagrama ER global, eliminar las tablas que no vayan a ser fragmentadas y todas las relaciones en las que estas transacciones están implicadas. (5) Examinar las tablas que se encuentren en el lado uno de una relación y decidir un esquema de frag- mentación adecuado para estas tablas, tomando en consideración la topología del sistema. Las tablas
  • 78. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 653 correspondientes aliado muchos de una relación pueden ser candidatas para aplicar una fragmentación derivada. (6) Durante el paso anterior, comprobar si hay situaciones en las que sería apropiado utilizar fragmenta- ción vertical o mixta (es decir, cuando haya transacciones que requieran acceder a un subconjunto de los atributos de una tabla). 22.5 Transparencia en un SGBDD La definición de SGBDD dada en la Sección 22.1.1 afirma que el sistema debe hacer que la distribución sea transparente para el usuario. La transparencia oculta al usuario los detalles de implementación. Por ejemplo, en un SGBD centralizado, la independencia de los datos es una forma de transparencia: oculta al usuario los cambios en la definición y organización de los datos. Un SGBDD puede proporcionar distintos niveles de transparencia. Sin embargo, todos esos tipos de transparencia tienen el mismo objetivo global: hacer que el uso de una base de datos distribuida sea equivalente al de una base de datos centralizada. Podemos identifi- car cuatro tipos principales de transparencia en un SGBDD: • transparencia de distribución; • transparencia de transacción; • transparencia de rendimiento; • transparencia de SGBD. Antes de hablar de cada uno de estos tipos de transparencias, conviene resaltar que la transparencia com- pleta no es un objetivo universalmente aceptado. Por ejemplo, Gray (1989) argumenta que una transparencia completa hace que la gestión de los datos distribuidos sea muy dificil y que las aplicaciones codificadas con acceso transparente a bases de datos geográficamente distribuidas tienen limitadas posibilidades de gestión, pobre modularidad y un bajo rendimiento en lo que al intercambio de mensajes se refiere. Observe también que sólo en muy raras ocasiones ofrecen los sistemas todos los tipos de transparencia mencionados. 22.5.1 Transparencia de distribución La transparencia de distribución permite al usuario percibir la base de datos como una única entidad lógica. Si un SGBDD exhibe transparencia de distribución, entonces el usuario no necesita saber que los datos están fragmentados (transparencia de fragmentación) o la ubicación de los elementos de datos (transparencia de ubicación). Si el usuario necesita saber que los datos están fragmentados y cuál es la ubicación de los fragmentos, denominamos a esta situación transparencia de asignación local. Estas transparencias están ordenadas, como ahora veremos. Para ilustrar estos conceptos, vamos a considerar la distribución de la relación 81aff dada en el Ejemplo 22.4, de forma tal que: 81: IlstaffNo, poslt;on, sex, DOS, salarl8laff) ubicada en el nodo 5 82: ITstaffNo, fName, IName, branChNO( Staff) 821: (J"branchNo = '8003,(S2) ubicada en el nodo 3 822: (J"branchNo = '8005,(S2) ubicada en el nodo 5 823: (J"branchNo = '8007'(S2) ubicada en el nodo 7 Transparencia de fragmentación La fragmentación es el nivel más alto de transparencia de distribución. Si la transparencia de fragmentación es proporcionada por el SGBDD, entonces el usuario no necesita saber que los datos están fragmentados. Como resultado, los accesos a la base de datos se basan en el esquema global, de modo que el usuario no nece- sita especificar nombres de fragmentos ni ubicaciones de los datos. Por ejemplo, para extraer los nombres de todos los empleados con categoría Manager, si existe transparencia de fragmentación escribiríamos:
  • 79. 654 Sistemas de bases de datos SELECT fName, IName FROM 8taff WHERE position = 'Manager'; Ésta es la misma instrucción SQL que escribiríamos en un sistema centralizado. Transparencia de ubicación La transparencia de ubicación es el nivel intermedio de la transparencia de distribución. Con la transparencia de ubicación, el usuario debe conocer cómo han sido fragmentados los datos, pero puede ignorar cuál es la ubicación de esos datos. La consulta anterior, si existe transparencia de ubicación, quedaría: SELECT fName, IName FROM821 WHERE staffNo IN (SELECT staffNo FROM 81 WHERE position = 'Manager') UNION SELECT fName, IName FROM 822 WHERE staffNo IN (SELECT staffNo FROM 81 WHERE position = 'Manager') UNION SELECT fName, IName FROM 823 WHERE staffNo IN (SELECT staffNo FROM 81 WHERE position = 'Manager'); Ahora tenemos que especificar los nombres de los fragmentos en la consulta. También tenemos que usar una combinación (o subconsulta), ya que los atributos position y fName/IName aparecen en diferentes fragmen- tos verticales. La principal ventaja de la transparencia de ubicación es que puede reorganizarse físicamente la base de datos sin que ello afecte a los programas de aplicación que acceden a la misma. Transparencia de replicación Estrechamente relacionada con la transparencia de ubicación está la transparencia de replicación, que quiere decir que el usuario no es consciente de la replicación de los fragmentos. La transparencia de replicación está implícita en la transparencia de ubicación. Sin embargo, es posible que un sistema no tenga transparencia de ubicación y sí que la tenga de replicación. Transparencia de asignación local Este es el nivel inferior de transparencia de distribución. Con la transparencia de asignación local, el usuario necesita especificar tanto los nombres de los fragmentos como la ubicación de los elementos de datos, toman- do en consideración los mecanismos de replicación que puedan existir. Nuestra consulta de ejemplo, si exis- te transparencia de asignación local, quedaría: SELECT fName, IName FROM 821 AT SITE 3 WHERE staffNo IN (SELECT staffNo FROM 81 AT SITE 5 WHERE position = 'Manager') UNION SELECT fName, IName FROM 822 AT SITE 5 WHERE staffNo IN (SELECT staffNo FROM 81 AT SITE 5 WHERE position = 'Manager') UNION SELECT fName, IName FROM 823 AT SITE 7 WHERE staffNo IN (SELECT staffNo FROM 81 AT SITE 5 WHERE position = 'Manager'); Para propósitos de ilustración, hemos extendido SQL con la palabra clave AT SITE para expresar el nodo en el que un fragmento concreto está ubicado. Obviamente, esta consulta es más compleja y se tarda más tiem- po en escribirla que las dos consultas anteriores. No resulta muy probable que un sistema que proporcione sólo este nivel de transparencia sea aceptable para los usuarios finales.
  • 80. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 655 Transparencia de denominación Como corolario de los tipos mencionados de transparencias de distribución, tenemos la denominada transpa- rencia de denominación. Al igual que en una base de datos centralizada, cada elemento de una base de datos distribuida debe tener un nombre uní vaca. Por tanto, el SGBDD debe garantizar que dos nadas no creen un objeto de base de datos que tenga el mismo nombre. Una solución a este problema consiste en crear un ser- vidor de nombres centralizado, que tenga la responsabilidad de garantizar la unicidad de todos los nombres del sistema. Sin embargo, este enfoque da como resultado: • una pérdida de un cierto grado de autonomía local; • problemas de rendimiento, si el nodo central se convierte en un cuello de botella; • baja disponibilidad; si falla el nodo central, los nadas restantes no pueden crear nuevos objetos de base de datos. Una solución alternativa consiste en añadir como prefijo a cada objeto el identificador del nodo que lo ha creado. Por ejemplo, la relación Branch creada en el nodo SI puede denominarse S1.Branch. De forma similar, tenemos que poder identificar cada fragmento y cada una de sus copias. Así, la copia 2 del fragmento 3 de la relación Branch creada en el nodo SI puede denominarse S1.Branch.F3.C2. Sin embargo, esto hace que perda- mos la transparencia de distribución. Una técnica que resuelve los problemas de estas dos soluciones consiste en utilizar alias (algunas veces denominados sinónimos) para cada objeto de base de datos. Así, S1.Branch.F3.C2 podría ser denominada LocalBranchpor los usuarios del nodo SI. El SGBDD tiene la responsabilidad de establecer la correspondencia entre un alias y el objeto de base de datos apropiado. El sistema distribuido R* distingue entre el nombre imprimible de un objeto y su nombre del sistema. El nombre imprimible es el nombre que los usuarios emplean normalmente para referirse al objeto. El nombre del sistema es un identificador interno globalmente unívoco para el objeto, identificador que el sistema garan- tiza que nunca será modificado. El nombre del objeto en el sistema está formado por cuatro componentes: • ID del creador: un identificador unívoco dentro del nodo, asignado al usuario que creó el objeto; • Identificador de nodo creador: un identificador globalmente unívoco para el nodo en el que el objeto fue creado; • Nombre local: un nombre no cualificado para el objeto; • ID del nodo de creación: un identificador globalmente unívoco para el nodo en el que el objeto fue ini- cialmente almacenado (como hemos explicado para el catálogo global del sistema en la Sección 22.3.4). Por ejemplo, el nombre del sistema: Manager@London.LocaIBranch@Glasgow representa un objeto con nombre local LocalBranch,creado por el usuario Manager en el nodo de Londres y almacenado inicialmente en el nodo de Glasgow. 22.5.2 Transparencia de transacción La transparencia de transacción en un entorno SGBDD garantiza que todas las transacciones distribuidas man- tengan la integridad y coherencia de la base de datos distribuida. Una transacción distribuida accede a datos almacenados en más de una ubicación. Cada transacción está dividida en una serie de subtransacciones, una por cada nodo al que haya que acceder; cada transacción está representada por un agente, como se ilustra en el siguiente ejemplo. I Ejemplo 22.6 Transacción distribuida Considere una transacción T que imprime los nombres de todos los nombres de todos los empleados, utilizando el esquema de fragmentación definida anteriormente compuesta por SI' S2, S21,S22y S23.
  • 81. 656 Sistemas de bases de datos Podemos definir tres subtransacciones Ts" Ts, Y Ts, para representar los agentes en los nodos 3, 5 Y 7, respectivamente. Cada subtransacción imprime los nombres de los empleados de su correspondiente nodo. La transacción distribuida se muestra en la Figura 22.13. Observe el paralelismo inherente al sis- tema: las subtransacciones de cada nodo pueden ejecutarse concurrentemente. Tiempo Ts, begin_transaction read(fName, lName) print(fName, lName) end_transaction begin_transaction read(fName, lName) print(fName, lName) end_transaction begin_transaction read(fName, lName) print(fName, lName) end_transaction Figura 22.13. Transacción distribuida. La atomicidad de la transacción distribuida sigue siendo fundamental para el concepto de transacción, pero además, el SGBDD debe garantizar también la atomicidad de cada subtransacción (véase la Sección 20.1.1). Por tanto, no sólo debe el SGBDD garantizar ]a sincronización de las subtransacciones con las otras transac- ciones locales que se estén ejecutando concurrentemente en cada nodo, sino que también debe garantizar la sincronización de las subtransacciones con las transacciones globales que se estén ejecutando simultáneamen- te en el mismo o en diferentes nodos. La transparencia de transacción en un SGBD distribuido se complica debido a los esquemas de fragmentación, de asignación y de replicación. Vamos a considerar dos aspectos adi- cionales de la transparencia de transacción: transparencia de concurrencia y transparencia de fallos. Transparencia de concurrencia Decimos que el SGBDD proporciona transparencia de concurrencia si los resultados de todas las transaccio- nes concurrentes (distribuidas y no distribuidas) se obtienen independientemente y son lógicamente coheren- tes con los resultados que se obtendrían si las transacciones se ejecutaran de una en una, en alguna secuencia serie arbitraria. Estos son los mismo principios fundamentales que ya hemos explicado para los SGBD cen- tralizados en la Sección 20.2.2. Sin embargo, existe la complejidad añadida de que el SGBDD debe garanti- zar que las transacciones tanto globales como locales no interfieran entre sí. De forma similar, el SGBDD debe garantizar la coherencia de todas las subtransacciones de la transacción global. La replicación hace que el problema de la concurrencia sea todavía más complejo. Si se actualiza una copia de un elemento de datos replicado, dicha actualización deberá propagarse antes o después a todas las copias. Una estrategia obvia consiste en propagar los cambios como parte de la transacción original, hacien- do que sea una operación atómica. Sin embargo, si no se puede alcanzar uno de los nodos que almacenan una copia en el momento de procesar la actualización, porque haya fallado el nodo o el enlace de comunicacio- nes, entonces la transacción completa se verá retardada hasta que el nodo vuelva a ser alcanzable. Si hay muchas copias del elemento de datos, la probabilidad de que la transacción tenga éxito decrece exponencial- mente. Una estrategia alternativa consiste en limitar la propagación de la actualización exclusivamente a aque- llos nodos que estén actualmente disponibles. Los nodos restantes deberán ser actualizados cuando vuelvan a estar disponibles. Otra estrategia alternativa sería permitir que las actualizaciones de las copias se realicen asincronamente, en algún momento posterior a la actualización original. El retardo necesario para volver a restaurar ]a coherencia puede ir desde unos pocos segundos a varias horas. En el siguiente capítulo hablare- mos de cómo gestionar correctamente el control de concurrencia distribuido y la replicación. Transparencia de fallos En la Sección 20.3.2 hemos dicho que un SGBD centralizado debe proporcionar un mecanismo de recupera- ción que garantice que las transacciones sean atómicas en presencia de fallos: o bien se llevan a cabo todas las operaciones de la transacción, o no se lleva a cabo ninguna. Además, en cuanto una transacción haya con- firmado los cambios, estos cambios serán duraderos. También hemos examinado los tipos de fallos que pue-
  • 82. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 657 den producirse en un sistema centralizado, como por ejemplo la parada catastrófica de un sistema, el fallo de un soporte de almacenamiento, errores del software, descuidos, desastres físicos naturales y sabotajes. En un entorno distribuido, el SGBDD deberá tener además en cuenta: • la pérdida de mensajes; • el fallo de un enlace de comunicaciones; • el fallo de un nodo; • el particionamiento de la red. El SGBDD debe garantizar la atomicidad de la transacción global, lo que quiere decir garantizar que todas las subtransacciones de la transacción global se confirmen, o que todas se aborten. Por tanto, el SGBDD debe- rá sincronizar la transacción global para garantizar que todas las subtransacciones se hayan completado con éxito antes de registrar la operación COMMIT final para la transacción global. Por ejemplo, considere una transacción global que tenga que actualizar datos en dos nadas, por ejemplo SI y S2' Suponga que la subtran- sacción del nodo SI se completa con éxito y se confirma, pero que la subtransacción del nodo Sl no puede con- firmar las operaciones y deshace los cambios, con el fin de mantener la coherencia local. La base de datos dis- tribuida estará ahora en un estado incoherente: no podemos desconfirmar los datos del nodo SI' debido a la propiedad de durabilidad de la subtransacción de SI' Hablaremos de cómo gestionar correctamente los meca- nismos de recuperación de bases de datos distribuidas en el siguiente capítulo. Clasificación de las transacciones Antes de completar nuestro análisis de las transacciones en este capítulo, vamos a presentar brevemente una clasificación de las transacciones definida en la arquitectura DRDA (Distributed Relational Database Architecture) de IBM. En DRDA, hay cuatro tipos de transacciones, con un nivel progresivo de complejidad en la interacción entre los distintos SGBD: (1) solicitud remota; (2) unidad de trabajo remota; (3) unidad de trabajo distribuida; (4) solicitud distribuida. En este contexto, una 'solicitud' es equivalente a una instrucción SQL y una 'unidad de trabajo' es una transacción. Los cuatro niveles están ilustrados en la Figura 22.14. (1) Solicitud remota. Una aplicación en un nodo puede enviar una solicitud (instrucción SQL) a otro nodo remoto para su ejecución. La solicitud se ejecuta por entero en el nodo remoto y puede hacer referen- cia exclusivamente a datos que se encuentren en el nodo remoto. (2) Unidad de trabajo remota. Una aplicación en un nodo (local) puede enviar todas las instrucciones SQL de una unidad de trabajo (transacción) a algún nodo remoto para su ejecución. Todas las instrucciones SQL se ejecutan enteramente en el nodo remoto y sólo pueden hacer referencia a datos que se encuen- tren en el nodo remoto. Sin embargo, es el nodo local quien decide si la transacción debe confirmarse o anularse. (3) Unidad de trabajo distribuida. Una aplicación en un nodo (local) puede enviar parte o todas las ins- trucciones SQL de una transacción a uno o más nadas remotos para su ejecución. Cada instrucción SQL se ejecuta enteramente en el nodo remoto y sólo puede hacer referencia a datos que se encuentren en dicho nodo. Sin embargo, las diferentes instrucciones SQL pueden ejecutarse en nadas distintos. De nuevo, es el sitio local quien decide si hay que confirmar o anular la transacción. (4) Solicitud distribuida. Una aplicación en un nodo (local) puede enviar parte o todas las instrucciones SQL de una transacción a uno o más nadas remotos para su ejecución. Sin embargo, una instrucción SQL puede requerir acceder a datos de más de un nodo (por ejemplo, la instrucción SQL puede nece- sitar combinar o unir relaciones/fragmentos ubicados en diferentes nadas).
  • 83. 658 Sistemas de bases de datos SELECT* FROM Staff WHERE salary > 20000 (a) UPDATE Staff SET salary = salary*1.05; UPDATE PropertyForRen SET rent = rent*1.06; COMMIT; (e) Staff Staff PropertyForRent UPDATE Staff SET salary = salary*1.05; UPDATE PropertyForRent SET rent = rent*1.06; COMMIT; UPDATE Staff SET salary = salary*1.05; UPDATE PropertyForRent SET rent = rent*1.06; SELECT * FROM Staff s, PropertyForRent pfr WHERE s.staffNo = pfr.staffNo; COMMIT; (b) (d) Staff PropertyForRent Staff PropertyForRent Figura 22.14. Clasificación DRDA de las transacciones: (a) solicitud remota; (b) unidad de trabajo remota; (c) unidad de trabajo distribuida; (d) solicitud distribuida. 22.5.3 Transparencia de rendimiento La transparencia de rendimiento requiere que el SGBDD tenga unas prestaciones equivalentes al caso de que se tratara de un SGBDD centralizado. En un entorno distribuido, el sistema no debe sufrir una degradación de rendimiento debido a la arquitectura distribuida, por ejemplo a la presencia de la red. La transparencia de ren- dimiento también requiere que el SGBDD determine la estrategia más eficiente para ejecutar cada solicitud. En un SGBDD centralizado, el procesador de consultas debe evaluar todas las solicitudes de datos y encontrar una estrategia de ejecución óptima, compuesta por una secuencia ordenada de operaciones sobre la base de datos. En un entorno distribuido, el procesador de consultas distribuido hace corresponder a cada soli- citud de datos una secuencia ordenada de operaciones sobre las bases de datos locales. Tiene la complejidad añadida de tener en cuenta los sistemas de fragmentación, replicación y asignación. El procesador de consul- tas distribuidas tiene que decidir; • a qué fragmentos acceder; • qué copia de cada fragmento utilizar, si el fragmento está replicado; • qué indicación emplear. El procesador de consultas distribuidas genera una estrategia de ejecución que está optimizada con respec- to a alguna función de coste. Normalmente, los costes asociados con una solicitud distribuida incluyen: • el tiempo de acceso (E/S) requerido para acceder a los datos fisicos en disco; • el tiempo de procesador necesario para efectuar operaciones sobre los datos contenidos en la memoria principal; • los costes de comunicaciones asociados con la transmisión de los datos a través de la red.
  • 84. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 659 Los primeros dos factores son los únicos que se consideran en un sistema centralizado. En un entorno dis- tribuido, el SGBDD debe tener en cuenta los costes de comunicaciones, que pueden ser el factor dominante en las redes WAN que tengan un ancho de banda de unos pocos kilobytes por segundo. En tales casos, la estra- tegia de optimización puede ignorar los costes de E/S y de procesador. Sin embargo, las redes LAN tienen un ancho de banda comparable al de los discos, por lo que en tales casos los procedimientos de utilización no deben ignorar por completo los costes de E/S y de procesador. Una técnica para la optimización de consultas consiste en minimizar el tiempo total necesario para ejecu- tar la consulta (Sacco y Yao, 1982). Otra técnica alternativa lo que hace es minimizar el tiempo de respuesta de la consulta, en cuyo caso el procesador de consultas distribuido trata de maximizar la ejecución paralela de las operaciones (Epstein et al., 1978). En ocasiones, el tiempo de respuesta será significativamente inferior al tiempo total. El siguiente ejemplo, adaptado de Rothnie y Goodman (1977), ilustra la amplia variación en tiempos de respuesta que puede surgir debido a la adopción de estrategias de ejecución diferentes, pero plau- sibles. I Ejemplo 22.7 Procesamiento de consultas distribuidas Considere un esquema relacional simplificado para DreamHome compuesto por las siguientes tres relaciones: Property(propertyNo, city) Client(c1ientNo, maxPrice) Viewing(propertyNo, clientNo) 10000 registros almacenados en Londres 100000 registros almacenados en Glasgow 1000000 registros almacenados en Londres Para enumerar los inmuebles de Aberdeen que han sido vistos por clientes que hayan indicado un lími- te de precio máximo superior a 200.000 euros, podemos utilizar la siguiente consulta SQL: SELECT p.propertyNo FROM Property p INNER JOIN (Client e INNER JOIN Viewing v ON c.c1ientNo = v.c1ientNo) ON p.propertyNo = v.propertyNo WHERE p.city = 'Aberdeen' AND c.maxPrice > 200000; Por s~mplicidad, suponga que cada tupla de cada relación tiene 100 caracteres de longitud, suponga también que hay 10 clientes con un precio máximo superior a 200.000 euros, que hay 100000 visitas a inmueb1es en Aberdeen y que el tiempo de procesamiento es despreciable comparado con el tiempo de comunicación. Vamos a suponer también que el sistema de comunicaciones tiene una velocidad de transmisión de datos igual a 10000 caracteres por segundo y un retardo de acceso de un segundo para enviar un mensaje de un nodo a otro. Rothnie identifica seis posibles estrategias para esta consulta, como se resume en la Tabla 22.4. Utilizando el algoritmo para cálculo del tiempo de comunicación que hemos enunciado en la Sección 22.2, podemos calcular los tiempos de respuesta de estas estrategias de la forma siguiente: Estrategia 1. Mover la relación Client a Londres y procesar la consulta allí: Tiempo =1 + (100000 * 100/10000) == 16,7 minutos Estrategia 2. Mover las relaciones Property y Viewing a Glasgow y procesar la consulta allí: Tiempo =2 + [(1000000 + 10000) * 100/10000] == 28 horas Estrategia 3. Combinar las relaciones Property y Viewing en Londres, seleccionar las tuplas relativas a inmueble s de Aberdeen y luego, para cada una de estas tuplas, enviarlas por turno a Glasgow para determinar si maxPrice > 200.000 euros para el cliente asociado. La com- probación requerida para cada tupla necesita dos mensajes: una consulta y una res- puesta.
  • 85. 660 Sistemas de bases de datos Tabla 22.4. Comparación de estrategias de procesamiento de una consulta distribuida. Estrategia Tiempo (1) Mover la relación Clienta Londres y procesar la consulta alIí 16,7minutos (2) Mover las relaciones Propertyy Viewinga Glasgow y procesar la consulta alIí 28 horas (3) Combinar las relacíones Propertyy Viewingen Londres, seleccionar las tuplas 2,3 días relativas a inmuebles de Aberdeen y luego, para cada una de estas tuplas, enviarlas por turno a G1asgowpara determinar si maxPrice > 200.000 euros para el cliente asociado (4) Seleccionar los clientes con maxPrice > 200.000 euros en Glasgow y, para cada 20 segundos cliente que se haya encontrado, comprobar en Londres si hay una visita de ese cliente a un inmueble de Aberdeen (5) Combinar las relaciones Propertyy Viewingen Londres, seleccionar los inmue- 16,7 minutos bles de Aberdeen, proyectar los resultados sobre propertyNoy c1ientNoy mover este resultado a Glasgow para efectuar la comprobación maxPrice > 200.000 euros (6) Seleccionar los clientes con maxPrice > 200.000 euros en Glasgow y mover l segundo el resultado a Londres para efectuar la correspondencia con los inmuebles de Aberdeen Tiempo =100000 * (1 + 100/10000) + 100000 * 1 == 2,3 días Estrategia 4. Seleccionar los clientes con maxPrice > 200.000 euros en Glasgow y, para cada clien- te que se haya encontrado, comprobar en Londres si hay una visita de ese cliente a un inmueble de Aberdeen. De nuevo, son necesarios dos mensajes: Tiempo = 1O * (1 + 100/10000) + 10* 1 == 20 segundos Estrategia 5. Combinar las relaciones Property y Viewingen Londres, seleccionar los inmuebles de Aberdeen, proyectar los resultados sobre propertyNoy clientNoy mover este resultado a Glasgow para efectuar la comprobación maxPrice > 200.000 euros. Por simplicidad, asumimos que el resultado proyectado sigue teniendo 100 caracteres de longitud: Tiempo =1 + (100000 * 100/10000) == 16,7 minutos Estrategia 6. Seleccionar los clientes con maxPrice > 200.000 euros en Glasgow y mover el resulta- do a Londres para efectuar la correspondencia con los inmuebles de Aberdeen: Tiempo = 1 + (10 * 100/1 0000) == 1 segundo El tiempo de respuesta varía de 1 segundo a 2,3 días, aunque todas las estrategias constituyen una forma legítima de ejecutar la consulta. Claramente, si se elige la estrategia incorrecta, el efecto sobre el rendimiento del sistema puede ser devastador. Hablaremos más en detalle del procesamiento de con- sultas distribuidas en la Sección 23.6. -.-J 22.5.4 Transparencia de SGBD La transparencia de SGBD oculta el hecho de que los SGBD locales puedan ser diferentes, por lo que este tipo de transparencia sólo es aplicable a los SGBDD heterogéneos. Es uno de los tipos de transparencia más difíciles de proporcionar. Hemos hablado de los problemas asociados con la provisión de servicios de base de datos sobre sistemas heterogéneos en la Sección 22.1.3.
  • 86. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 661 22.5.5 Resumen de los conceptos de transparencia en un SGBDD Al principio de esta sección dedicada al concepto de transparencia en un SGBDD hemos mencionado que el objetivo de conseguir una transparencia completa no es universalmente aceptado. Como hemos visto, el con- cepto de transparencia no es un concepto de 'todo o nada', sino que puede proporcionarse transparencia a dife- rentes niveles. Cada nivel requiere un tipo concreto de acuerdo entre los nadas participantes. Por ejemplo, con una transparencia completa, los nadas deben ponerse de acuerdo en cosas tales como el modelo de datos, la interpretación de los esquemas, la representación de los datos y la funcionalidad proporcionada por cada nodo. En el otro extremo del espectro, en un sistema no transparente, sólo existe acuerdo sobre el formato de inter- cambio de los datos y la funcionalidad proporcionada por cada nodo. Desde la perspectiva del usuario, la transparencia completa es altamente deseable. Sin embargo, desde la perspectiva del DBA local, un acceso completamente transparente puede resultar dificil de controlar. Como un mecanismo de seguridad, la facilidad tradicional de vistas puede no ser lo suficientemente potente como para proporcionar una adecuada protección. Por ejemplo, el mecanismo de vistas de SQL permite restringir el acceso a una relación base o a un subconjunto de una relación base a una serie de usuarios, pero no permite restringir fácilmente el acceso basándose en un conjunto de criterios que no estén basados en el nombre del usuario. En el caso de estudio de DreamHome, podemos restringir el acceso de borrado de la relación Lease a una serie de empleados determinados, pero no podemos imponer fácilmente la condición de que un contra- to de alquiler no sea borrado si el contrato de alquiler ha finalizado, si todos los pagos pendientes han sido realizados por el inquilino y si el inmueble se encuentra todavía en condiciones satisfactorias. Puede que resulte más fácil proporcionar este tipo de funcionalidad dentro de un procedimiento que se invoque remotamente. De esta forma, los usuarios locales pueden ver los datos que normalmente tienen per- mitido ver utilizando mecanismos de seguridad estándar del SGBD. Sin embargo, los usuarios remotos sólo verán datos que estarán encapsulados dentro de un conjunto de procedimientos, de forma similar a lo que sucede en un sistema orientado a objetos. Este tipo de arquitectura federada es más simple de implementar que un sistema con transparencia completa, y puede proporcionar un mayor grado de autonomía local. 22.6 Las doce reglas de Date para un SGBDD En esta sección final, vamos a enumerar las doce reglas (u objetivos) de Date para un SGBDD (Date, 1987b). El fundamento de estas reglas es que un SGBDD distribuido debe parecer que no está distribuido a ojos del usuario. Estas reglas son similares a las doce reglas de Codd para los sistemas relacionales que presentamos en el Apéndice D. Principio fundamental Para el usuario, un sistema distribuido debe parecer exactamente como si fuera no distribuido. (1) Autonomía local Los nadas de un sistema distribuido deben ser autónomos. En este contexto, autonomía significa que: • los datos locales son propiedad local y se gestionan localmente; • las operaciones locales siguen siendo puramente locales; • todas las operaciones en un nodo concreto son controladas por dicho nodo. (2) No dependencia de un nodo central No debe haber ningún nodo sin el cual el sistema no pueda operar. Esto implica que no debe haber servido- res centralizados para servicios tales como la gestión de transacciones, la detección de interbloqueos, la opti- mización de consultas y la gestión del catálogo global del sistema.
  • 87. 662 Sistemas de bases de datos (3) Operación continua Idealmente, nunca debería existir la necesidad de efectuar una detección planificada del sistema para realizar operaciones tales como: • añadir o eliminar un nodo del sistema; • la creación y borrado de fragmentos dinámicamente en uno o más nodos. (4) Independencia de ubicación La independencia de ubicación es equivalente a la transparencia de ubicación. El usuario debe poder acceder a la base de datos desde cualquier nodo. Además, el usuario debe poder acceder a todos los datos como si estu- vieran almacenados en el nodo del usuario, independientemente de dónde estén físicamente almacenados. (5) Independencia de fragmentación El usuario debe poder acceder a los datos con independencia de cómo estén fragmentados. (6) Independencia de replicación El usuario no debe ser consciente de que los datos han sido replicados. Así, el usuario no debe poder acceder a una copia concreta de un elemento de datos directamente, ni tampoco debe tener que actualizar específica- mente todas las copias de un elemento de datos. (7) Procesamiento de consultas distribuidas El sistema debe ser capaz de procesar consultas que hagan referencia a datos situados en más de un nodo. (8) Procesamiento de transacciones distribuidas El sistema debe soportar el concepto de transacción como unidad de recuperación. El sistema debe garantizar que las transacciones tanto globales como locales se adapten a las reglas ACID de las transacciones, es decir: atomicidad, coherencia, aislamiento y durabilidad. (9) Independencia del hardware Debe ser posible ejecutar el SGBDD en una diversidad de plataformas hardware. (10) Independencia del sistema operativo Como corolario de la regla anterior, debe ser posible ejecutar el SGBDD sobre una diversidad de sistemas operativos (11) Independencia de la red De nuevo, debe ser posible ejecutar el SGBDD sobre una diversidad de redes de comunicaciones distintas. (12) Independencia de la base de datos Debe ser posible tener un SGBDD formado por diferentes SGBD locales, que quizá soporten diferentes mode- los de datos subyacentes. En otras palabras, el sistema debe admitir la heterogeneidad. Las últimas cuatro reglas son ideales. Ya que las reglas son tan generales, y como hay una falta de están- dares en lo que se refiere a las arquitecturas informáticas y de red, cabe esperar que sólo se cumplan estas reglas parcialmente por parte de los fabricantes en el futuro próximo. Resumen del capítulo • Una base de datos distribuida es una colección lógicamente interrelacionada de datos compartidos (y una descripción de estos datos), físicamente distribuida en una red informática. El SGBDD es el software que gestiona de manera transparente la base de datos distribuida.
  • 88. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 663 • Un SGBDD es distinto de un sistema de procesamiento distribuido, que es un sistema en el que se acce- de a un SGBD centralizado a través de una red. También es diferente de un SGBD paralelo, que es un SGBD que se ejecuta sobre múltiples procesadores y discos y que ha sido diseñado para evaluar las ope- raciones en paralelo siempre que sea posible, para así mejorar el rendimiento. • Las ventajas de un SGBDD son que refleja mejor la estructura de la organización, que hace que los datos puedan compartirse en mayor medida, que mejora la fiabilidad, la disponibilidad y las prestaci.ones, que puede ser más económico, que permite el crecimiento modular, que facilita la integración y que ayuda a las organizaciones a seguir siendo competitivas. Las principales desventajas son el coste, la complejidad, la falta de estándares y la falta de experiencia. • Los SGBDD pueden clasificarse como homogéneos o heterogéneos. En un SGBD homogéneo, todos los nodos utilizan el mismo tipo de SGBD. En un sistema heterogéneo, los nodos pueden ejecutar sistemas SGBD de diferentes fabricantes, los cuales pueden estar basados en modelos de datos distintos, de modo que el sistema pueda estar compuesto de una mezcla de SGBD relacionales, en red, jerárquicos y orienta- dos a objetos. • Un sistema multi-base de datos (MDBS) es un SGBD distribuido en el que cada nodo mantiene una com- pleta autonomía. Un MDBS se instala transparentemente por encima de los sistemas de archivos y bases de datos existentes, presentando a los usuarios una única base de datos. Mantiene un esquema global que es el que los usuarios utilizan para realizar las consultas y las actualizaciones. El MDBS se encarga úni- camente de mantener el esquema global, mientras que son los SGBD locales los que mantienen los datos de los usuarios. • Las comunicaciones tienen lugar a través de una red, que puede ser una red de área local (LAN) o una red de área extensa (WAN). Las redes LAN se suelen utilizar para distancias cortas y proporcionan una comu- nicación más rápida que las redes WAN. Un caso especial de red WAN es la red de área metropolitana (MAN, metropolitan area network), que generalmente cubre una ciudad o un suburbio. • Además de tener la funcionalidad estándar que cabe esperar de un SGBD centralizado, los SGBDD nece- sitan servicios avanzados de comunicaciones, un catálogo ampliado del sistema, procesamiento distribui- do de consultas y servicios avanzados de seguridad, concurrencia y recuperación. • Una relación puede dividirse en una serie de subrelaciones denominadas fragmentos, que se asignan a uno o más nodos. Los fragmentos pueden ser replicados para mejorar la disponibilidad y las presta- cIOnes. • Hay dos tipos principales de fragmentación: horizontal y vertical. Los fragmentos horizontales son sub- conjuntos de tuplas y los fragmentos verticales son subconjuntos de atributos. Hay otros dos tipos adicio- nales de fragmentación: mixta y derivada, un tipo de fragmentación horizontal en el que la fragmenta- ción de una relación está basada en la fragmentación de otra relación. • La definición y asignación de fragmentos se llevan a cabo estratégicamente para conseguir la localidad de referencia, una mayor fiabilidad y disponibilidad, un rendimiento aceptable, un equilibrio entre la capaci- dad de almacenamiento y el coste y unos costes de comunicación mínimos. Las tres reglas de corrección aplicables a la fragmentación son: completud, reconstrucción y disyunción. • Existen cuatro estrategias de asignación en lo que se refiere a la ubicación de los datos: centralizada (una única base de datos centralizada), fragmentada (se asigna cada fragmento a un nodo), replicación com- pleta (se mantiene una copia completa de la base de datos en cada nodo) y replicación selectiva (combi- nación de las primeras tres estrategias). • El SGBDD debe aparecer como un SGBD centralizado, proporcionando una serie de niveles de transpa- rencia. Con la transparencia de distribución, los usuarios no deben ser conscientes de que los datos han sido fragmentados/replicados. Con la transparencia de transacción, debe mantenerse la coherencia de la base de datos global cuando múltiples usuarios estén accediendo a la base de datos concurrentemente y cuando se produzcan fallos. Con la transparencia de rendimiento, el sistema debe ser capaz de gestio- nar de manera eficiente las consultas que hagan referencia a datos situados en más de un nodo. Con la transparencia de SGBD, debe ser posible tener sistemas SGBD de diferentes tipos en el sistema.
  • 89. 664 Sistemas de bases de datos Cuestiones de repaso 22.1. Explique el concepto de SGBDD y diga cuál es la motivación para proporcionar este tipo de sistemas. 22.2. Indique las similitudes y diferencias entre un SGBDD y el procesamiento distribuido. ¿En qué circuns- tancias es preferible un SGBDD a un sistema de procesamiento distribuido? 22.3. Indique las similitudes y diferencias entre un SGBDD y un SGBD paralelo. ¿En qué circunstancias es preferible un SGBDD a un SGBD paralelo? 22.4. Explique las ventajas y desventajas de un SGBDD. 22.5. ¿Cuál es la diferencia entre un SGBDD homogéneo y otro heterogéneo? ¿En qué circunstancias sue- len utilizarse ambos tipos de sistemas? 22.6. ¿Cuáles son las principales diferencias entre una LAN y una WAN? 22.7. ¿Qué funcionalidad cabe esperar encontrar en un SGBDD? 22.8. ¿Qué es un sistema multi-base de datos? Describa una arquitectura de referencia para dicho tipo de sis- tema. 22.9. Uno de los problemas que afectan a los SGBDD es el diseño de bases de datos distribuidas. Indique los problemas que hay que resolver en el diseño de bases de datos distribuidas. Explique cómo se apli- can estas cuestiones al catálogo global del sistema. 22.10. ¿Cuáles son los objetivos estratégicos para la definición y asignación de fragmentos? 22.11. Describa diversos esquemas alternativos para fragmentar una relación global. Indique cómo compro- baría la corrección del esquema de fragmentación para garantizar que la base de datos no sufra cam- bios semánticos durante el proceso de fragmentación. 22.12. ¿Qué niveles de transparencia debe proporcionar un SGBDD? Proporcione ejemplos para ilustrar su respuesta y justifíquela. 22.13. Un SGBDD debe garantizar que no haya dos nodos que creen un objeto de datos con el mismo nom- bre. Una solución a este problema consiste en disponer de un servidor de nombres centralizado. ¿Cuáles son las desventajas de este enfoque? Proponga un enfoque alternativo que resuelva estas des- ventajas. 22.14. ¿Cuáles son los cuatro niveles de transacciones definidos en la arquitectura DRDA de IBM? Indique las similitudes y diferencias entre los cuatro niveles. Proporcione ejemplos para ilustrar su respuesta. Ejercicios Una empresa de ingeniería multinacional ha decidido distribuir su información de gestión de proyectos en el nivel regional dentro de Gran Bretaña. El esquema re1acional centralizado actual es el siguiente: Employee (NIN, fName, IName, address, DOB, sex, salary, taxCode, deptNo) Department (deotNo, deptName, managerNIN, businessAreaNo, regionNo) Project (proiNo, projName, contractPrice, projectManagerNIN, deptNo) WorksOn (NIN, projNo, horasWorked) Business (businessAreaNo, businessAreaName) Region (regionNo, regionName) donde Employee contiene detalles de los.empleados y el número de la seguridad social NIN es la clave. Department contiene detalles de los departamentos y deptNo es la clave. managerNIN identifica el empleado que actúa como gerente del departamento. Sólo hay un gerente en cada departamento. Project contiene detalles de los proyectos de la empresa y la clave es projNo. El jefe de pro- yecto se identifica mediante projectManagerNIN y el departamento responsable del proyecto se identifica mediante deptNo.
  • 90. Capítulo 22 Bases de datos distribuidas: conceptos y diseño 665 WorksOn contiene detalles de las horas que han dedicado los empleados y (NIN, projNo) forma la clave. Business contiene los nombres de las áreas de negocio y la clave es businessAreaNo. Region contiene los nombres de las regiones y la clave es regionNo. Los departamentos están agrupados regionalmente de la forma siguiente: Región 1: Escocia Región 2: Gales Región 3: Inglaterra Se requiere información por área de negocio, lo que cubre: Ingeniería del software, Ingeniería mecánica e Ingeniería eléctrica. No hay Ingeniería del software en Gales y todos departamentos de Ingeniería eléctrica están en Inglaterra. La asignación de personal a los proyectos se hace a partir del personal de los departamen- tos locales. Además de distribuir los datos regionalmente, hay un requisito adicional, que es que se debe poder acceder a los datos de los empleados bien mediante la información personal (por parte del departamento de recursos humanos) o mediante información relacionada con el trabajo (por parte del departamento de nóminas). 22.15. Dibuje un diagrama de Entidad-Relación (ER) para representar este sistema. 22.16. Utilizando el diagrama ER del Ejercicio 22.15, realice un diseño de base de datos distribuida para este sistema en el que se incluya: (a) un esquema de fragmentación adecuado para el sistema; (b) en el caso de una fragmentación horizontal principal, un conjunto mínimo de predicados; (c) la reconstrucción de las relaciones globales a partir de los fragmentos. Indique las suposiciones en las que haya basado su diseño. 22.17. Repita el Ejercicio 22.16 para el caso de estudio de DreamHome documentado en el Apéndice A. 22.18. Repita el Ejercicio 22.16 para el caso de estudio de EasyDrive School 01Motoring documentado en el Apéndice B.2. 22.19. Repita el Ejercicio 22.16 para el caso de estudio de Wellmeadows documentado en el Apéndice B.3. 22.20. En la Sección 22.5.1, al hablar de la transparencia de nominación, hemos propuesto el uso de alias para identificar de forma unívoca cada réplica de cada fragmento. Realice un esbozo de diseño para la implementación de esta técnica de obtención de la transparencia de denominación. 22.21. Compare un SGBD distribuido al que tenga acceso con las doce reglas enunciadas por Date para los SGBDD. Para cada regla que el sistema no cumpla, indique las razones por las que piensa que el sis- tema no se adecua a esa regla.
  • 91. CapítUlo Bases de datos distribuidas: conceptos avanzados Objetivos del capítulo: En este capítulo aprenderá: • Cómo afecta la distribución de datos a los componentes de gestión de transacciones. • Cómo pueden ampliarse las técnicas de control de concurrencia centralizadas para gestionar la distri- bución de datos. • Cómo detectar el interbloqueo en los casos en que hay múltiples nodos implicados. • Cómo recuperarse de un fallo de la base de datos en un entorno distribuido utilizando: • confirmación en dos fases (2PC) • confirmación en tres fases (3PC). • Las dificultades de detectar y mantener la integridad en un entorno distribuido. • Algunos conceptos sobre el estándar DTP X/Open. • Las técnicas de optimización de consultas distribuidas. • La importancia de la operación de semi combinación en los entorno s distribuidos. • Cómo gestiona Oracle la distribución de datos. En el capítulo anterior hemos hablado de los conceptos básicos y de los problemas asociados con los sistemas distribuidos de gestión de bases de datos (SGBDD). Desde la perspectiva del usuario, la funcionalidad ofre- cida por un SGBDD es altamente atractiva. Sin embargo, desde la perspectiva de la implementación, los pro- tocolos y algoritmos requeridos para proporcionar esta funcionalidad son bastante complejos y hacen que sur- jan numerosos problemas que pueden hacer que no merezcan la pena las ventajas ofrecidas por esta tecnología. En este capítulo, continuaremos nuestro análisis de la tecnología de los sistemas SGBDD y exa- minaremos cómo pueden ampliarse los protocolos de control de concurrencia, de gestión de interbloqueos y de recuperación presentados en el Capítulo 20 para tratar con la distribución de datos y la replicación. Una alternativa, potencialmente más simple, a la distribución de datos es la proporcionada por los servi- dores de replicación, que gestionan la replicación de datos a nodos remotos. Todos los principales fabrican- tes de bases de datos disponen de alguna solución de replicación de un tipo u otro y muchos fabricantes de software no especializados en bases de datos ofrecen también métodos alternativos de replicación de los datos. En el capítulo siguiente tomaremos también en cuenta el servidor de replicación como alternativa a un SGBDD. Estructura del capítulo En la Sección 23.1 se repasan brevemente los objetivos del procesamiento distribuido de transacciones. En la Sección 23.2 se examina cómo afecta la distribución de datos a la definición de serializabilidad proporciona-
  • 92. 668 Sistemas de bases de datos da en la Sección 20.2.2 y luego se analiza cómo ampliar los protocolos de control de concurrencia presenta- dos en las Secciones 20.2.3 y 20.2.5 a un entorno distribuido. En la Sección 23.3 se examina el incremento de complejidad a la hora de identificar interbloqueos en un SGBD distribuido y se analizan los protocolos de detección de interbloqueos distribuidos. En la Sección 23.4 se examinan los fallos que pueden producir- se en un entorno distribuido y se presentan los protocolos que cabe utilizar para garantizar la atomicidad y la durabilidad de las transacciones distribuidas. En la Sección 23.5 se repasa brevemente el modelo X/Open de procesamiento de transacciones distribuidas, que especifica una interfaz de programación para el proce- samiento de transacciones. En la Sección 23.6 se proporciona una panorámica de la optimización de consul- tas distribuidas y en la Sección 23.7 veremos cómo gestiona Oracle la distribución. De nuevo, los ejemplos de este capítulo están extraídos del caso de estudio de DreamHome descrito en la Sección 10.4 y en el ApéndiceA. 23.1 Gestión de transacciones distribuidas En la Sección 22.5.2 ya hemos indicado que los objetivos del procesamiento distribuido de transacciones son los mismos que en los sistemas centralizados, aunque resultan más complejos debido a que el SGBDD debe también garantizar la atomicidad de la transacción global, además de la de cada subtransacción componente. En la Sección 20.1.2 hemos identificado cuatro módulos de base de datos de alto nivel encargados de gestio- nar las transacciones, el control de concurrencia y la recuperación en un SGBD centralizado. El gestor de transacciones coordina las transacciones por cuenta de los programas de aplicación, comunicándose con el planificador, que es el módulo responsable de implementar una estrategia concreta de control de concurren- cia. El objetivo del planificador es maximizar la concurrencia impidiendo que las transacciones que se ejecu- tan simultáneamente interfieran entre sí y pongan en peligro la coherencia de la base de datos. En caso de que se produzca un fallo durante la transacción, el gestor de recuperación garantiza que se restaure la base de datos al estado en el que se encontraba antes del comienzo de la transacción, que por definición es un estado coherente. El gestor de recuperación es también responsable de restaurar la base de datos a un estado cohe- rente después de producirse un fallo del sistema. El gestor de búferes es el encargado de la transferencia efi- ciente de los datos entre el almacenamiento en disco y la memoria principal. En un SGBD distribuido, estos módulos siguen existiendo en cada SGBD local. Además, hay también un gestor global de transacciones o coordinador de transacciones en cada nodo para coordinar la ejecución de las transacciones globales y locales iniciadas en dicho nodo. La comunicación inter-nodos se sigue produ- ciendo a través del componente de comunicación de datos (los gestores de transacciones de los distintos nodos no se comunican directamente entre sí). El procedimiento para ejecutar una transacción global iniciada en el nodo S¡ es el siguiente: • El coordinador de transacciones (TC]) en el nodo S¡ divide la transacción en una serie de subtransac- ciones utilizando la información almacenada en el catálogo global del sistema. • El componente de comunicación de datos en el nodo S] envía las subtransacciones a los nodos apro- piados, por ejemplo S2y S3. • Los coordinadores de transacciones de los nodos S2y S3 se encargan de gestionar estas subtransaccio- nes. Los resultados de las subtransacciones se devuelven a TC¡ a través de los componentes de comu- nicación de datos. Este proceso se ilustra en la Figura 23.1. Ahora que hemos presentado esta panorámica de la gestión de transacciones distribuidas, vamos a analizar los protocolos de control de concurrencia, gestión de interblo- queos y recuperación. 23.2 Control de concurrencia distribuido En esta sección se presentan los protocolos que pueden utilizarse para realizar el control de concurrencia en un SGBD distribuido. Comenzamos examinando los objetivos del control de concurrencia distribuido.
  • 93. Capítulo 23 Bases de datos distribuidas: conceptos avanzados 669 Comunicación de datos Coordinador TM local Comunicación de datos Coordinador (TC1) TM local Figura 23.1. Coordinación de una transacción distribuida. 23.2.1 Objetivos Suponiendo que el sistema no haya fallado, todos los mecanismos de control de concurrencia deben garanti- zar que se preserve la coherencia de los elementos de datos y que cada acción atómica se complete en un tiem- po finito. Además, un buen mecanismo de control de concurrencia para un SGBD distribuido debe: • ser resistente a los fallos de comunicaciones y a los fallos de los nodos; • permitir mecanismos de paralelismo para satisfacer los requisitos de prestaciones; • no imponer un gasto excesivo de capacidad de proceso y de espacio de almacenamiento; • funcionar satisfactoriamente en un entorno de red donde exista un retardo de comunicación significativo; • no imponer muchas restricciones a la estructura de las acciones atómicas (Kohler, 1981). En la Sección 20.2.1 hemos explicados los tipos de problemas que pueden surgir cuando se permite a múl- tiples usuarios acceder concurrentemente a la base de datos; dichos problemas son el de la actualización per- dida, el de la dependencia no confirmada y el del análisis incoherente. Estos problemas también se producen en los entorno s distribuidos, pero en éstos hay problemas adicionales que pueden surgir como resultado de la propia distribución de los datos. Uno de dichos problemas es el problema de la coherencia multicopia, que se produce cuando un elemento de datos está replicado en ubicaciones diferentes. Obviamente, para mante- ner la coherencia de la base de datos global, cuando se actualice un elemento de datos replicado en un nodo todas las demás copias del elemento de datos deberán ser también actualizadas. Si no se actualiza una copia, la base de datos pasará a ser incoherente. Vamos a suponer en esta sección que las actualizaciones de los ele- mentos replicados se llevan a cabo síncronamente, como parte de la transacción que las engloba. En el Capítulo 24 veremos cómo pueden realizarse asíncronamente estas actualizaciones de los elementos replica- dos, es decir, cómo pueden realizarse dichas actualizaciones en algún instante posterior al momento en que se completa la transacción donde se actualiza la copia original del elemento de datos. 23.2.2 Serializabilidad distribuida El concepto de serializabilidad, del que hemos hablado en la Sección 20.2.2, puede ampliarse para el entorno distribuido con el fin de tener en cuenta los problemas inherentes a la distribución de datos. Si la planifica- ción de ejecución de una transacción es serializable en cada nodo, entonces la planificación global (la unión de todas las planificaciones locales) será también serializable, supuesto que los órdenes de serialización loca- les sean idénticos. Esto requiere que todas las subtransacciones aparezcan en el mismo orden en la planifica- ción serie equivalente en todos los nodos. Así, si denotamos mediante T~ la subtransacción Ti en el nodo SI' debemos garantizar que si T~< T;entonces:
  • 94. 670 Sistemas de bases de datos T/ < T/ para todos los nodos Sx en los que Ti y Tj tengan subtransacciones Las soluciones para el control de concurrencia en un entorno distribuido se basan en las dos técnicas prin- cipales de bloqueo y de marcado temporal, que ya hemos considerado para los sistemas centralizados en la Sección 20.2. De esta forma, dado un conjunto de transacciones que haya que ejecutar concurrentemente, ten- dremos que: • el bloqueo garantiza que la ejecución concurrente es equivalente a alguna ejecución serie (impredeci- ble) de dichas transacciones; • el marcado temporal garantiza que la ejecución concurrente sea equivalente a una ejecución serie espe- cifzca de dichas transacciones, correspondiente al orden de las marcas temporales. Si la base de datos es centralizada o fragmentada, pero no replicada, de forma que sólo exista una copia de cada elemento de datos y todas las transacciones sean locales o puedan ser realizadas en un nodo remoto, se podrán usar los protocolos presentados en la Sección 20.2. Sin embargo, si los datos están replicados o las transacciones afectan a datos situados en más de un nodo, será necesario ampliar dichos protocolos. Además, si adoptamos un protocolo basado en bloqueos, tendremos que proporcionar un mecanismo para gestionar los interbloqueos (véase la Sección 20.2.4). Utilizando un mecanismo de detección y recuperación de interblo- queos, esto implica comprobar si hay una situación de interbloqueo no sólo en cada nivel local, sino también en el nivel global, lo que puede requerir combinar los datos de interbloqueo de más de un nodo. Hablaremos de los interbloqueos distribuidos en la Sección 23.3. 23.2.3 Protocolos de bloqueo En esta sección vamos a presentar los siguientes protocolos basados en el bloqueo en dos fases (2PL, two- phase locking), que pueden emplearse para garantizar la serializabilidad en un SGBD distribuido: 2PL cen- tralizado, 2PL de copia principal, 2PL distribuido y bloqueo por mayoría. 2PL centralizado Con el protocolo 2PL centralizado, hay un único nodo que mantiene toda la información de bloqueo (Alsberg y Day, 1976; García-Molina, 1979). Sólo hay un planificador, o gestor de bloqueos, para el conjunto del SGBD distribuido, planificador que se responsabiliza de conceder y liberar los bloqueos. El protocolo 2PL centralizado para una transacción global iniciada en el sitio SI funciona de la forma siguiente: (1) El coordinador de la transacción en el sitio SI divide la transacción en una serie de subtransacciones, utilizando la información almacenada en el catálogo global del sistema. El coordinador es responsable de garantizar que se mantenga la coherencia. Si la transacción implica una actualización de un elemen- to de datos que está replicado, el coordinador deberá garantizar que también se actualicen todas las copias del elemento de datos. Así, el coordinador solicitará bloqueos exclusivos sobre todas las copias antes de actualizar cada copia y liberar los bloqueos. El coordinador puede elegir utilizar cualquiera de las copias de los elementos de datos para las lecturas, generalmente la copia situada en su propio nodo, si es que existe. (2) Los gestores de transacciones locales implicados en la transacción global solicitan (y liberan) bloqueos al gestor de bloqueos centralizados utilizando las reglas normales del bloqueo en dos fases. (3) El gestor de bloqueos centralizado comprueba si las solicitudes de bloqueos sobre un elemento de datos son compatibles con los bloqueos que existan actualmente. En caso afirmativo, el gestor de bloqueos devuelve un mensaje al nodo de origen confirmándole que se ha concedido el bloqueo. En caso con- trario, pone la solicitud en una cola hasta que el bloqueo pueda concederse. Una variación de este esquema consiste en que el coordinador de transacciones realice todas las solicitu- des de bloqueo por cuenta de los gestores de transacciones locales. En este caso, el gestor de bloqueos sólo interactúa con el coordinador de transacciones y no con los gestores de transacciones locales individuales. La ventaja del protocolo 2PL centralizado es que la implementación es relativamente sencilla. La detec- ción de interbloqueos no resulta más difícil que para un SGBD centralizado, porque hay un único gestor de
  • 95. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 671 bloqueos que mantiene toda la información sobre los bloqueos. Las desventajas de la centralización en un SGBD distribuido son la posible aparición de cuellos de botella y la reducción en la fiabilidad. Ya que todas las solicitudes de bloqueos se dirigen a un nodo central, dicho nodo puede convertirse en un cuello de bote- lla. El sistema puede también ser menos fiable, ya que el fallo del nodo central provocará un fallo de gran importancia en el sistema. Sin embargo, los costes de comunicaciones son relativamente bajos. Por ejemplo, una operación de actualización global que tenga agentes (subtransacciones) en n nadas puede requerir inter- cambiar un mínimo de 2n + 3 mensajes con un gestor de bloqueos centralizado: • una solicitud de bloqueo; • un mensaje de concesión del bloqueo; • n mensajes de actualización; • n confirmaciones; • una solicitud de desbloqueo. 2PL de copia principal Este protocolo trata de resolver las desventajas del 2PL centralizado, distribuyendo los gestores de bloqueos entre una serie de nadas. Cada gestor de bloqueos es entonces responsable de gestionar los bloqueos para un conjunto de elementos de datos. Para cada elemento de datos replicado, se elige una copia para que sea la copia principal llamándose a las demás copias copias esclavas. La elección de qué nodo debe ser el nodo primario es flexible, y el nodo elegido para gestionar los bloqueos para una copia principal no tiene por qué almacenar la copia principal de dicho elemento (Stonebraker y Neuhold, 1977). El protocolo es una extensión sencilla del 2PL centralizado. La principal diferencia es que, a la hora de actualizar un elemento, el coordinador de la transacción debe determinar dónde está la copia principal, para enviar las solicitudes de bloqueo al gestor de bloqueos apropiado. Sólo es necesario imponer un bloqueo exclusivo a la copia principal del elemento de datos que haya que actualizar. Una vez actualizada la copia prin- cipal, puede probarse el cambio a las copias esclavas. Esta propagación debe llevarse a cabo lo antes posible para evitar que otras transacciones lean valores desactualizados. Sin embargo, no es estrictamente necesario llevar a cabo las actualizaciones como una operación atómica. Este protocolo sólo garantiza que esté actuali- zada la copia principal. Esta técnica puede utilizarse cuando los datos se repliquen selectivamente, cuando las actualizaciones sean infrecuentes y cuando los nadas no necesiten siempre la versión más reciente de los datos. Las desventaja de esta técnica son que resulta más complejo gestionar los interbloqueos, debido a la existencia de múltiples ges- tores de bloqueos, y que sigue existiendo un cierto grado de centralización en el sistema: las solicitudes de bloqueo para una copia principal específica sólo pueden gestionarse en un único nodo. Esta última desventa- ja puede resolverse parcialmente designando una serie de nadas de reserva para que almacenen la informa- ción de bloqueo. Esta técnica tiene menor coste de comunicación y, por tanto, unas mejores prestaciones que el 2PL centralizado, ya que hay menos bloqueos remotos. 2PL distribuido Este protocolo trata, de nuevo, de resolver las desventajas del 2PL centralizado, pero esta vez distribuyendo los gestores de bloqueos entre todos los nadas. Cada gestor de bloqueo será entonces responsable de gestio- nar los bloqueos correspondientes a los datos situados en dicho nodo. Si no se replican los datos, este proto- colo es equivalente al 2PL de copia principal; pero si los datos están replicados, el 2PL distribuido implemen- ta un protocolo de control de réplicas denominado ROWA (Read-One-Write-All, leer una y escribir todas). Esto quiere decir que puede utilizarse cualquier copia de un elemento replicado para las operaciones de lec- tura, pero que es necesario establecer un bloqueo exclusivo sobre todas las copias antes de poder actualizar un elemento. Este esquema gestiona los bloqueos de forma descentralizada, evitando así las desventajas del control centralizado. Sin embargo, las desventajas de esta técnica son que la gestión de interbloqueo resulta más compleja, debido a la existencia de múltiples gestores de bloqueos, y que los costes de comunicaciones son mayores que en el 2PL de copia principal, ya que es preciso bloquear todos los elementos antes de cada
  • 96. 672 Sistemas de bases de datos actualización. Una operación de actualización global que tenga agentes en n sitios, puede recibir un mínimo de 5n mensajes con este protocolo: • n mensajes de solicitud de bloqueo; • n mensajes de concesión de bloqueo; • n mensajes de actualización; • n confirmaciones; • n solicitudes de desbloqueos. Puede reducirse esta cantidad a 4n mensajes si se omiten las solicitudes de desbloqueo y se gestionan éstas mediante la operación final de confirmación. El protocolo 2PL distribuido se utiliza en R* (Mohan et al., 1986). Bloqueo por mayoría Este protocolo es una extensión del 2PL distribuido que trata de evitar la necesidad de bloquear todas las copias de un elemento replicado antes de la actualización. De nuevo, el sistema mantiene un gestor de blo- queos en cada nodo para gestionar los bloqueos de todos los datos almacenados en el mismo. Cuando una transacción desea leer o escribir un elemento de datos que está replicado en n nodos, debe enviar una solici- tud de bloqueos a más de la mitad de los n nodos donde el elemento está almacenado. La transacción no puede continuar hasta que obtenga bloqueos sobre una mayoría de las copias. Si la transacción no recibe una mayo- ría de confirmación de bloqueos dentro de un cierto periodo de temporización, cancela su solicitud e informa a todos los nodos de la cancelación. Si recibe una mayoría de confirmaciones, informa a todos los nodos de que ha adquirido el bloqueo. Puede haber varias transacciones que mantengan simultáneamente un bloqueo compartido sobre una mayoría de las copias; sin embargo, sólo una transacción puede mantener un bloqueo exclusivo sobre una mayoría de las copias. De nuevo, este esquema resuelve las desventajas del control centralizado. Pero también tiene sus propias desventajas, que consisten en que el protocolo es más complicado, en que la detección de interbloqueos es más compleja y en que el bloqueo requiere al menos [en +1)/2] mensajes para las solicitudes de bloqueo y [en + 1)/2] mensajes para las solicitudes de desbloqueo. Esta técnica funciona correctamente, pero es excesi- vamente estricta en el caso de los bloqueos compartidos: en realidad, sólo es necesario bloquear una única copia de un elemento de datos, el elemento de datos leído, pero esta técnica solicita bloqueos sobre una mayo- ría de las copias. 23.2.4 Protocolos de marcado temporal Hemos hablado de los métodos de marcado temporal para los métodos SGBD centralizados en la Sección 20.2.5. El objetivo del marcado temporal es ordenar las transacciones globalmente de tal forma que las trans- acciones más antiguas (las transacciones con marcas temporales más pequeñas) tengan prioridad en caso de conflicto. En un entorno distribuido, seguimos necesitando generar marcas temporales unívocas tanto local- mente como globalmente. Claramente, la utilización del reloj del sistema o de un contador incremental de sucesos en cada nodo, como se propone en la Sección 20.2.5, no resultaría adecuada. Los relojes de los dife- rentes nodos podrían no estar sincronizados; asimismo, si se utilizara un contador de sucesos, sería posible que los diferentes nodos generaran el mismo valor de contador. La técnica general en los SGBD distribuidos consiste en utilizar la concatenación de la marca temporal local con un identificador unívoco de nodo, <marca temporal, identificador de nodo> (Lamport, 1978). El identificador de nodo se coloca en la posición menos significativa para garantizar que los sucesos puedan ordenarse de acuerdo con el instante en que se produjeron, en lugar de ordenarse de acuerdo con su ubicación. Para evitar que un nodo con mucha actividad genere marcas temporales de mayor tamaño que otros nodos menos ocupados los distintos nodos sincronizan sus marcas temporales. Cada nodo incluye su marca tempo- ral en los mensajes intercambiados con los otros nodos. Al recibir un mensaje, el nodo compara su propia marca temporal con la marca temporal del mensaje y, si su propia marca temporal es más pequeña, le asigna algún valor que sea superior a la marca temporal del mensaje. Por ejemplo, si el nodo 1 cuya marca temporal
  • 97. S3 read _lock(T3' Z3) Capítulo 23 Basesde datos distribuidas: conceptos avanzados 673 actual es <10,1> envía un mensaje al nodo 2 cuya marca temporal es <15, 2>, el nodo 2 no cambiará su marca temporal. Por el contrario, si la marca temporal actual en el nodo 2 fuera <5,2>, el nodo cambiaría su marca temporal a <11, 2>. 23.3 Gestión distribuida de interbloqueos Todo algoritmo de control de concurrencia basado en bloqueos (y algunos algoritmo s basados en marcas tem- porales que requieren que las transacciones realicen esperas) puede dar lugar a interbloqueos, como se expli- ca en la Sección 20.2.4. En un entorno distribuido, la detección de interbloqueos puede ser más complicada si la gestión de los bloqueos no está centralizada, como se muestra en el Ejemplo 23.l. I Ejemplo 23.1 Interbloqueo distribuido Considere tres transacciones TI, T2 Y T3 tales que: • TI ha sido iniciada en el nodo SI y está creando un agente en el nodo S2; • T2 ha sido iniciada en el nodo S2 y está creando un agente en el nodo S3; • T3 ha sido iniciada en el nodo S3 y está creando un agente en el nodo SI' Las transacciones comparten bloqueos compartidos (para lectura) y exclusivos (para escritura), como se ilustra a continuación, donde read_lock(T¡, x) denota un bloqueo compartido por la transacción T¡ sobre el elemento de datos xj y write _lock(T¡, x) denota un bloqueo exclusivo por parte de la transac- ción T¡ sobre el elemento de datos Xj' Tiempo S¡ S2 ti read_lock(T¡, Xl) write_lock(T2' Y2) t2 write_lock(T¡, Y¡) write_lock(T2, Z2) t3 write_lock(T3, Xl) write_lock(TI' Y2) write_lock(T2' Z3) Podemos construir los grafos de espera para cada nodo, los cuales se muestran en la Figura 23.2. No hay ningún ciclo en los grafos individuales, lo que podría llevamos a pensar que no puede producirse un interbloqueo. Sin embargo, si combinamos los grafos de espera, como se ilustra en la Figura 23.3, podemos ver que sí existe un interbloqueo, debido a la existencia del ciclo: S, Figura 23.2. Gratos de espera para los nadas 8" 82 Y 83, Figura 23.3. Gratos de espera combinados para los nadas 8" 82 Y 83,
  • 98. 674 Sistemas de bases de datos El Ejemplo 23.1 demuestra que en un SGBDD no es suficiente que cada nodo construya su propio grafo de espera local con el fin de comprobar si existen interbloqueos; también es necesario construir un grafo de espera global que sea la unión de todos los grafos de espera locales. Hay tres métodos comunes para gestio- nar la detección de interbloqueos en los SGBDD: detección de interbloqueos centralizada, jerárquica y dis- tribuida. Detección de interbloqueos centralizada Con la detección de interbloqueos centralizada, se nomina a un único nodo como coordinación de detección de interbloqueos (DDC, Deadlock Detection Coordinator). El DDC tiene la responsabilidad de construir y mantener el grafo de espera global. Periódicamente, cada gestor de bloqueos transmite su grafo de espera local al DDC. El DDC construye el grafo de espera global y comprueba si existen ciclos en él. Si existen uno o más ciclos, el DDC debe romper cada ciclo seleccionando las transacciones que hay que anular y reiniciar. El DDC debe informar a todos los nadas implicados en el procesamiento de dichas transacciones que las transaccio- nes deben ser anuladas y reiniciadas. Para minimizar la cantidad de datos que hay que enviar, cada gestor de bloqueos sólo necesita enviar los cambios que hayan tenido lugar en el grafo de espera local desde la última vez que lo enviaron. Estos cam- bios representan la adición o eliminación de aristas en el grafo de espera local. La desventaja de esta técnica centralizada es que el sistema puede ser menos fiable, ya que el fallo del nodo central provocaría problemas de gran envergadura. Detección de interbloqueos jerárquica Con la detección de interbloqueos jerárquica, los nadas de la red están organizados en forma de jerarquía. Cada nodo envía su grafo de espera local al nodo de detección de interbloqueos situado por encima suyo en la jerarquía (Menasce y Muntz, 1979). La Figura 23.4 ilustra una posible jerarquía para ocho nadas, SI a Ss. Las hojas de nivel 1 son los propios nadas, donde se realiza la detección de interbloqueos locales. Los nadas de nivel 2 DDij detectan los interbloqueos en los que estén involucrados los nadas adyacentes ¡y j. Los nadas de nivel 3 detectan los interbloqueos entre cuatro nadas adyacentes. La raíz del árbol es un detector de inter- bloqueos global que permitirá detectar cualquier interbloqueo, como por ejemplo entre los nadas SI y Ss. La solución jerárquica reduce la dependencia con respecto a un nodo de detección centralizado, abaratan- do así los costes de comunicaciones. Sin embargo, esta técnica es mucho más compleja de implementar, par- ticularmente si se producen fallos de los nadas o de las líneas de comunicación. Detección de interbloqueos distribuida Se han realizado diversas propuestas de algoritmos de detección de interbloqueos distribuida, pero aquí vamos a considerar uno de los más conocidos, que fue desarrollado por Obermarck (1982). Según este algoritmo, se añade un nodo externo Texta un grafo de espera local para indicar un agente situado en un nodo remoto. Cuando, por ejemplo, una transacción TI en el nodo SI cree un agente en otro nodo S2, se añadirá una arista al grafo de esfera local desde TI hasta el nodo Text.De forma similar, en el nodo S2 se añadirá una arista al grafo de esfera local desde el nodo Tex!hasta el agente de T¡. Por ejemplo, el grafo de espera global mostrado en la Figura 23.3 se representaría mediante los grafos de espera locales de los nadas SI' S2y S3 que se muestran en la Figura 23.5. Las aristas del grafo de espera local que enlazan los agentes con Textestán etiquetadas con el nombre del nodo correspondiente. Por ejemplo, la arista que conecta a TI Y Texten el nodo SI está etiquetada como S2, ya que esta arista representa un agente creado por la transacción TI en el nodo S2' Si un grafo de espera local contiene un ciclo que no incluye al nodo Text'dicho nodo y el SGBDD estarán en una situación de interbloqueo y el interbloqueo puede ser roto por el nodo local. Existirá potencialmente un interbloqueo global si el grafo de espera local contiene un ciclo que incluya al nodo Text.Sin embargo, la existencia de dicho ciclo no implica necesariamente que haya un interbloqueo global, ya que los nadas Tex! pueden representar diferentes agentes; sin embargo, la inversa sí es cierta. Si hay un interbloqueo, deberán aparecer ciclos de este tipo en los grafos de espera. Para determinar si hay un interbloqueo, es necesario com- binar los grafos. Si un nodo SI tiene un interbloqueo potencial, su grafo de espera local será de la forma:
  • 99. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 675 Nivel 4 3 2 Figura 23.4. Detección de interbloqueos jerárquica. Para evitar que los nadas se transmitan entre sí sus grafos de espera, una estrategia simple consiste en asig- nar una marca temporal a cada transacción e imponer la regla de que el nodo SI transmita su grafo de espera al nodo para el que la transacción Tk está esperando, Sk>únicamente si ts(T;) < ts(Tk). Si suponemos que ts(T;) < tS(Tk) entonces, para comprobar si existe un interbloqueo, el nodo SI transmitiría su grafo de espera local a Sk' El nodo Skpodrá entonces añadir esta información a su grafo de espera local y comprobar si existen ciclos en el grafo ampliado donde no aparezca Text.Si no existe tal ciclo, el proceso continua hasta que aparezca un ciclo, en cuyo caso habrá que anular y reiniciar algunas transacciones junto con todos sus agentes, o hasta que se construya el grafo de espera global y se compruebe que no existe ningún ciclo. En este caso, no habrá nin- gún interbloqueo en el sistema. Obermarck demostró que si existe un interbloqueo global, este procedimien- to hará que aparezca un ciclo en alguno de los nodos. Los tres grafos de espera locales de la Figura 23.5 contienen ciclos: S1: Text-7 T3 -7 T1 -7 Text S2: Text-7 T1-7 T2-7 Text S3: Text-7 T2-7 T3-7 Text En este ejemplo, podríamos transmitir el grafo de espera local del nodo SI al nodo para el que la transac- ción TI está esperando, es decir, el nodo S2' El grafo de espera local en S2 se ampliará para incluir esta infor- mación, con lo que nos queda: Figura 23.5. Detección de interbloqueos distribuida.
  • 100. 676 Sistemas de bases de datos Vemos que este grafo sigue conteniendo un interbloqueo secuencial, por lo que transmitiríamos este grafo de espera al nodo para el que la transacción Tz está esperando, es decir, el nodo S3.Así, ampliamos el grafo de espera local de S3para obtener: Este grafo de espera global contiene un ciclo donde no aparece el nodo Text,por lo que podemos concluir que existe interbloqueo y tendremos que invocar un protocolo de recuperación apropiado. Los métodos de detección de interbloqueos distribuidos son potencialmente más robustos que los métodos jerárquicos o cen- tralizados, pero como no hay ningún nodo que contenga toda la información necesaria para detectar los inter- bloqueos, es posible que se necesite una cantidad considerable de comunicación inter-nodos. 23.4 Recuperación de bases de datos distribuidas En esta sección, vamos a hablar de los protocolos que se utilizan para gestionar los fallos en un entorno dis- tribuido. 23.4.1 Fallos en un entorno distribuido En la Sección 22.5.2 hemos mencionado cuatro tipos de fallos que son propios de los SGBD distribuidos: • la pérdida de un mensaje; • el fallo de un enlace de comunicaciones; • el fallo de un nodo; • el particionamiento de la red. La pérdida de mensajes, o la ordenación inadecuada de los mensajes, es responsabilidad del protocolo sub- yacente de la red informática. Por tanto, asumiremos que estos problemas son gestionados de forma transpa- rente por el componente de comunicación de datos del SGBDD y nos vamos a fijar aquí en los restantes tipos de fallos. Un SGBDD depende en gran medida de la capacidad de todos los nodos de la red para comunicarse entre sí de manera fiable. Antiguamente, las comunicaciones no siempre eran fiables. Aunque la tecnología de red ha mejorado significativamente y las redes actuales son mucho más fiables, sigue existiendo la posibilidad de que se produzcan fallos de comunicaciones. En concreto, dichos fallos de comunicaciones pueden tener como resultado que la red quede dividida en dos o más particiones, en las que los nodos situados dentro de una misma partición pueden comunicarse entre sí, pero no pueden comunicarse con los nodos de las otras particiones. La Figura 23.6 muestra un ejemplo de particionamiento de la red donde, después de fallar el enlace que conecta los nodos SI ---¿ Sz, los nodos (S¡, S4, Ss) quedan particionados con respecto a los nodos (Sz, S3)· (a) (b) Figura 23.6. Particionamiento de una red: (a) antes del fallo; (b) después del fallo.
  • 101. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 677 En algunos casos, es difícil distinguir si ha fallado un enlace de comunicaciones o un nodo. Por ejemplo, suponga que el nodo SI no puede comunicarse con el nodo S2 dentro de un determinado periodo de tempori- zación. Podría ser que: • el nodo S2 haya sufrido un fallo o la red se haya caído; • el enlace de comunicaciones haya fallado; • la red esté particionada; • el nodo S2tenga actualmente una gran carga de trabajo y no haya tenido tiempo para responder al men- saJe. Resulta dificil seleccionar el valor de temporización correcto que permita a SI concluir que no puede comunicarse con el nodo S2. 23.4.2 Cómo afectan los fallos a la recuperación Al igual que con la recuperación local, la recuperación distribuida trata de mantener la atomicidad y la dura- bilidad de las transacciones distribuidas. Para asegurar la atomicidad de la transacción global, el SGBDD debe garantizar que todas las subtransacciones de la transacción global se confirmen o que todas se aborten. Si el SGBDD detecta que un nodo ha fallado o es inaccesible, tendrá que llevar a cabo los siguientes pasos: • Abortar todas las transacciones que se vean afectadas por el fallo. • Marcar el nodo como fallido, para evitar que cualquier otro nodo trate de utilizado. • Comprobar periódicamente para ver si el nodo se ha recuperado o, alternativamente, esperar a que el nodo fallido difunda un mensaje informando de que se ha recuperado. • Al reiniciarse, el nodo fallido debe iniciar un procedimiento de recuperación para abortar cualesquie- ra transacciones parciales que estuvieran activas en el momento del fallo. • Después de la recuperación local, el nodo fallido debe actualizar su copia de la base de datos para hacer que sea coherente con el resto del sistema. Si se produce una partición de la red como en el ejemplo anterior, el SGBDD debe garantiza que si hay agentes de una misma transacción global activos en diferentes particiones, entonces no debe ser posible para el nodo SI (y para otros nodos de la misma partición) decidir que se confirme la transacción global, mientras que el nodo S2 (y otros nodos en su partición) deciden abortada. Esto violaría la atomicidad de la transacción global. Protocolos de recuperación distribuida Como hemos mencionado anteriormente, la recuperación en un SGBDD se ve complicada por el hecho de que se requiere mantener la característica de atomicidad tanto para las subtransacciones locales como para la trans- acción global. Las técnicas de recuperación descritas en la Sección 20.3 garantizan la atomicidad de las sub- transacciones, pero el SGBDD necesita garantizar también la atomicidad de una transacción global. Esto implica modificar el procesamiento de las órdenes de confirmar y abortar de modo que una transacción glo- bal no se confirme ni aborte hasta que todas sus subtransacciones se hayan confirmado o abortado con éxito. Además, el protocolo modificado debe tener en cuenta tanto los fallos de los nodos como los fallos de los enlaces de comunicaciones, para garantizar que el fallo de un nodo no afecte al procesamiento de otro nodo. En otras palabras, los nodos que están operativos no deben quedar bloqueados. Los protocolos que obedecen esta regla se denominan protocolos no bloqueantes. En las siguientes dos secciones, vamos a analizar dos protocolos comunes de confirmación que resultan adecuados para los SGBD distribuidos: la confirmación en dos fases (2PC, two-phase commit) y la confirmación en tres fases (3PC, three-phase commit), que es un pro- tocolo no bloqueante. Vamos a asumir que toda transacción global tiene un nodo que actúa como coordinador (o gestor de la transacción) para dicha transacción, que será generalmente el nodo en el que la transacción fuera iniciada. Los nodos en los que la transacción global tiene agentes se denominan participantes (o gestores de recur-
  • 102. 678 Sistemas de bases de datos sos). Vamos a asumir que el coordinador conoce la identidad de todos los participantes y que cada participan- te conoce la identidad del coordinador, aunque no necesariamente la de los otros participantes. 23.4.3 Confirmación en dos fases (2PC) Como el nombre indica, 2PC opera en dos fases: una fase de votación y una fase de decisión. La idea bási- ca es que el coordinador pregunte a todos los participantes si están preparados para confirmar la transacción. Si uno de los participantes vota por abortarla o no responde dentro de un cierto periodo de temporización, el coordinador instruye a todos los participantes para que aborten la transacción. Si todos votan en favor de la confirmación, el coordinador instruirá a todos los participantes para que confirmen la transacción. La decisión global debe ser adoptada por todos los participantes. Si un participante vota por abortar la transacción, podrá si quiere abortarla inmediatamente; de hecho todos los nodos son libres de abortar una transacción en cual- quier momento, antes de votar por confirmarla. Este tipo de cancelación en la transacción se conoce con el nombre de aborto unilateral. Si un participante vota por confirmar la transacción, deberá esperar a que el coordinador difunda el mensaje de confirmación global o de aborto global. Este protocolo asume que cada nodo tiene su propio registro local y que puede, por tanto, anular o confirmar la transacción de manera fiable. La confirmación en dos fases implica que los procesos tengan que esperar a recibir mensajes de otros nodos. Para evitar que los procesos queden bloqueados de forma innecesaria, se utiliza un sistema de temporizacio- nes. El procedimiento que debe seguir el coordinador para la confirmación es el siguiente: Fase 1 (1) Escribir un registro begin_commit en el archivo de registro y provocar su escritura forzada en almace- namiento estable. Enviar un mensaje PREPARE a todos los participantes. Esperar a que los participan- tes respondan dentro de un cierto periodo de temporización. Fase 2 (2) Si un participante devuelve un voto ABORT, escribir un registro abort en el archivo de registro y pro- vocar su escritura forzada en almacenamiento estable. Enviar un mensaje GLOBALfiBORT a todos los participantes. Esperar a que los participantes envíen una confirmación dentro de un cierto periodo de temporización. (3) Si un participante devuelve un voto READY _COMMIT, actualizar la lista de participantes que han res- pondido. Si todos los participantes han votado COMMIT, escribir un registro commit en el archivo de registro y provocar su escritura forzada en almacenamiento estable. Enviar un mensaje GLOBAL _COMMIT a todos los participantes. Esperar a que los participantes envíen un mensaje de confirmación dentro de un cierto periodo de temporización. (4) Una vez que se han recibido todas las confirmaciones, escribir un mensaje end_transaction en el archi- vo de registro. Si un nodo no envía su confirmación, se vuelve a enviar la decisión global hasta que se reciba una confirmación. El coordinador debe esperar hasta recibir los votos de todos los participantes. Si uno de los nodos no vota, el coordinador asumirá un valor de voto predeterminado igual aABORT y difundirá un mensaje GLOBAL_ ABORT a todos los participantes. Un poco más adelante veremos qué sucede durante el reinicio con ese par- ticipante que ha fallado. El procedimiento que debe seguir un participante durante la confirmación es el siguiente: (1) Cuando el participante recibe un mensaje PREPARE, entonces tiene que hacer una de estas dos cosas: (a) escribir un registro ready Jommit en el archivo de registro y provocar la escritura forzada de todas las entradas del registro correspondientes a la transacción en almacenamiento estable. Enviar un mensaje READY _COMMIT al coordinador o, (b) escribir un registro abort en el archivo de registro y provocar su escritura forzada en almacena- miento estable. Enviar un mensaje ABORT al coordinador. Abortar unilateralmente la transacción. Esperar a que el coordinador responda dentro de un cierto periodo de temporización.
  • 103. Capítulo 23 Bases de datos distribuidas: conceptos avanzados 679 (2) Si el participante recibe un mensaje GLOBAL_ABORT, escribir un registro abort en el archivo de registro y provocar su escritura forzada en almacenamiento estable. Abortar la transacción y, al com- pletar la operación, enviar una confirmación al coordinador. (3) Si el participante recibe un mensaje GLOBAL _COMMIT, escribir un registro commit en el archivo de registro y provocar su escritura forzada en almacenamiento estable. Confirmar la transacción, liberan- do cualesquiera bloqueos que mantuviera y, al completar la operación, enviar una confirmación al coordinador. Si un participante no recibe una instrucción de voto del coordinador, transcurrirá simplemente el periodo de temporización preestablecido y el participante abortará la transacción. Por tanto, cualquier participante podría ya haber abortado y realizado el procesamiento de aborto local correspondiente antes de votar. El pro- cesamiento para el caso en que los participantes voten COMMIT y ABORT se muestra en la Figura 23.7. El participantes tiene que esperar a recibir la instrucción GLOBAL_COMMIT o GLOBAL_ABORT del coordinador. Si el participante no recibe la instrucción del coordinador, o éste no recibe una respuesta de un participante, asumirá que el nodo ha fallado y deberá invocar un protocolo de terminación. Sólo los nodos operativos siguen el protocolo de terminación; los nodos que hayan fallado deberán seguir el protocolo de recuperación durante el reinicio. Coordinador Participante -- ........•~~ Prepare: escribir ready_commit en el registro enviar READY _COMMIT al coordinador esperar por GLOBAL_COMMlT o GLOBAL_ABORTReady _commit: si todos los participantes han votado READY: escribir commit en el registro enviar GLOBAL_COMMIT a todos los participantes ~ Global_commit: esperar las confirmaciones escribir entrada commit en el registro confirmar transacción Commit: escribir begin_commit en el registro enviar PREPARE a todos los participantes esperar las respuestas Ack: si todos los participantes han confirmado: escribir end_oLtransaction en el registro enviar confirmaciones (a) Coordinador Participante Commit: escribir begin_commit en el registro enviar PREPARE a todos los participantes esperar las respuestas Abort: si un participante ha votado ABORT: escribir abort en el registro enviar GLOBAL _ABORT a todos los participantes esperar confirmaciones •• Prepare: escribir abort en el registro enviar ABORT al coordinador abortar la transacción (b) Figura 23.7. Resumen de 2PC: (a) protocolo 2PC para el caso de que un participante vote COMMIT; (b) protocolo 2PC para el caso de que un participante vote ABORT.
  • 104. 680 Sistemas de bases de datos Protocolos de terminación para 2PC Es necesario invocar un protocolo de terminación siempre que un coordinador o un participante no reciba un mensaje esperado y se produzca un fin de temporización. La acción que habrá que tomar dependerá de si el fin de temporización se ha producido en el coordinador o en el participante y de cuándo se haya producido dicho fin de temporización. Coordinador El coordinador puede estar en uno de los cuatro estados durante el proceso de confirmación: INITIAL, WAI- TINO, DECIDED y COMPLETED, como se muestra en el diagrama de transacción de estados de la Figura 23.8(a), pero sólo puede producirse un fin de temporización en los dos estados intermedios. Las acciones que habrá que tomar son la siguientes: • Fin de temporización en el estado WAITING El coordinador está esperando a que todos los participan- tes confirmen si quieren confirmar o abortar la transacción. En este caso, el coordinador no puede coor- dinar la transacción porque no ha recibido todos los votos. Sin embargo, puede decidir abortar global- mente la transacción . • Fin de temporización en el estado DECIDED. El coordinador está esperando a que todos los partici- pantes confirmen si han abortado o confirmado con éxito la transacción. En este caso, el coordinador simplemente envía de nuevo la decisión global a aquellos nodos que no hayan enviado su mensaje de confirmación. Participante El protocolo de terminación más simple consiste en dejar bloqueado el proceso participante hasta dejar que vuelva a establecerse la comunicación con el coordinador. El participante puede entonces ser informado de la decisión global y continuar con su procesamiento de forma correspondiente. Sin embargo, hay otras acciones que pueden tomarse para mejorar el rendimiento. Un participante puede estar en uno de los cuatro estados durante el proceso de confirmación: INITrAL, PREPARED, ABORTED y COMMITTED, como se muestra en la Figura 23.8(b). Sin embargo, sólo puede producirse un fin de temporización en el participante en los primeros dos estados, como a continuación se explica: Enviado mensaje de preparación Enviado mensaje de decisión global Recibida confirmación (a) (b) Figura 23.8. Diagrama de transiciones entre estados para 2PC: (a) coordinador; (b) participante.
  • 105. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 681 • Fin de temporización en el estado INITIAL. El participante está esperando a recibir el mensaje PRE- PARE del coordinador, lo que implica que el coordinador debe de haber fallado mientras se encontra- ba en el estado INITIAL. En este caso, el participante puede abortar unilateralmente la transacción. Si recibe después un mensaje PREPARE, puede ignorado, en cuyo caso el coordinador detectará un fin de temporización y abortará la transacción global, o puede enviar un mensaje ABORT al coordinador. • Fin de temporización en el estado PREPARED. El participante está esperando recibir una instrucción de confirmar o abortar globalmente la transacción. El participante debe haber ya abortado para confir- mar la transacción, por lo que no puede cambiar su voto y abortar la transacción. Asimismo, tampoco puede continuar y confirmar la transacción, ya que la decisión global podría ser abortada. Sin infor- mación adicional, el participante quedará bloqueado. Sin embargo, el participante puede contactar a cada uno de los otros participantes para tratar de localizar a uno que conozca la decisión. Esto se cono- ce con el nombre de protocolo de terminación cooperativo. Una forma sencilla de informar a los par- ticipantes de quiénes son los otros participantes es que el coordinador añada una lista de participantes a la instrucción de voto. Aunque el protocolo de terminación cooperativo reduce la posibilidad de bloqueo, dicha posibilidad sigue existiendo y el proceso bloqueado tendrá que continuar intentando desbloquearse a medida que se reparen los fallos. Si solamente ha fallado el coordinador y todos los participantes detectan este hecho como resultado de la ejecución del protocolo de terminación, pueden elegir un nuevo coordinador y resolver el bloqueo de esta manera, como explicaremos en breve. Protocolos de recuperación para 2PC Habiendo analizado las acciones que un nodo operativo debe tomar en caso de fallo, vamos a ver ahora las acciones que un nodo fallido debe llevar a cabo durante la recuperación. La acción que haya que tomar duran- te el reinicio dependerá, de nuevo, del estado que el coordinador o participante hubiera alcanzado en el momento del fallo. Fallo del coordinador Vamos a considerar tres diferentes estados para el fallo del coordinador: • Fallo en el estado INITIAL. El coordinador todavía no ha iniciado el procedimiento de confirmación. La recuperación en este caso consiste en iniciar dicho procedimiento de confirmación. • Fallo en el estado WAITING. El coordinador ha enviado el mensaje PREPARE y, aunque no ha reci- bido todas las respuestas, tampoco ha recibido una respuesta indicando que hay que abortar la transac- ción. En este caso, el procedimiento de recuperación consiste en reiniciar el procedimiento de confir- mación. • Fallo en el estado DECIDED. El coordinador ha ordenado a todos los participantes que aborten o con- firmen globalmente la transacción. Durante el reinicio, si el coordinador ha recibido todas las confir- maciones, puede completar la transacción con éxito. En caso contrario, tiene que iniciar el protocolo de terminación al que antes hemos hecho referencia. Fallo del participante El objetivo del protocolo de recuperación para un participante consiste en garantizar que el proceso partici- pante realice en el reinicio la misma acción que todos los demás participantes, y que este reinicio pueda ser llevado a cabo de forma independiente (es decir, sin necesidad de consultar ni al coordinador ni a los otros participantes). Vamos a considerar tres estados distintos para el fallo de un participante: • Fallo en el estado INITIAL. El participante todavía no ha votado sobre la transacción. Por tanto, duran- te la recuperación, puede abortar unilateralmente la transacción ya que es imposible que el coordina- dor haya alcanzado una decisión global de confirmación sin el voto de este participante. • Fallo en el estado PREPARED. El participante ha enviado su voto al coordinador. En este caso, la recu- peración se lleva a cabo mediante el protocolo de terminación que antes hemos explicado.
  • 106. 682 Sistemas de bases de datos • Fallo en los estados ABORTED/COMMITTED. El participante ha completado la transacción. Por tanto, durante el reinicio no hace falta llevar a cabo ninguna acción adicional. Protocolos de elección Si los participantes detectan el fallo del coordinador (por el fin de temporización) pueden elegir un nuevo nodo para que actúen como coordinador. Uno de los protocolos de elección consiste en que los nodos dispon- gan de una ordenación lineal previamente acordada. Vamos a suponer que el nodo S¡ tiene el orden ien la secuencia, siendo el coordinador el de menor orden; y vamos a suponer también que cada nodo conoce la iden- tificación y ordenación de los otros nodos del sistema, algunos de los cuales pueden haber fallado también. Uno de los posibles protocolos de elección requiere que cada participante operativo envíe un mensaje a los nodos que tengan un número de identificación mayor que él mismo. Así, el nodo S¡ enviaría un mensaje a los nodos S¡+¡,S¡+2,... , S., en dicho orden. Si un nodo Skrecibe un mensaje de otro participante de menor núme- ro, Sksabrá que él no debe ser el nuevo coordinador, y dejará de enviar mensajes. Este protocolo es relativamente eficiente y la mayoría de los participantes dejan de enviar mensajes rápi- damente. Llega un momento en que cada participante sabe si hay otro participante operativo con un número menor. Si no lo hay, ese nodo pasará a ser el nuevo coordinador. Si el coordinador recién elegido también pro- vocara un fallo de temporización durante este proceso, se invocaría de nuevo el protocolo de elección. Después de que se recupere un nodo fallido, éste da comienzo inmediatamente al protocolo de elección. Si no hay ningún otro nodo operativo con un número inferior, el nodo fuerza a todos los nodos con número mayor a dejarle ser el nuevo coordinador, independientemente de si ya había sido elegido un coordinador ante- riormente. Topologías de comunicación para 2PC Hay varias formas distintas de intercambiar mensajes, o topologías de comunicación, que pueden emplearse para implementar 2PC. La que acabamos de explicar se denomina 2PC centralizado, ya que todas las comu- nicaciones pasan a través del coordinador, como se muestra en la Figura 23.9(a). Se han propuesto diversas mejoras al protocolo 2PC centralizado que tratan de mejorar su rendimiento global, bien reduciendo el núme- ro de mensajes que hay que intercambiar, o bien acelerando el proceso de toma de decisiones. Estas mejoras necesitan que se adopten formas diferentes de intercambiar los mensajes. Una alternativa consiste en utilizar 2PC lineal, en el que los participantes pueden comunicarse entre sí, como se muestra en la Figura 23.9(b). En el2PC lineal, los nodo s están ordenados 1,2, ... , n, donde el nodo 1 es el coordinador y los nodos restantes son los participantes. El protocolo 2PC se implementa mediante una cadena directa de comunicación desde el coordinador hasta el participante n para la fase de votación y una cadena inversa de comunicación desde el participante n hasta el coordinador para la fase de decisión. En la fase de votación, el coordinador pasa la instrucción de voto al nodo 2, que vota y pasa su voto al nodo 3. El nodo 3 combina entonces su voto con el del nodo 2 y transmite el nodo combinado al nodo 4, etc. Cuando el participante n-ésimo añade su voto, se tendrá ya la decisión global, la cual se pasará hacia atrás a los partici- pantes n - ], n - 2-, etc., terminando por llegar al coordinador. Aunque el protocolo 2PC lineal requiere menos mensajes que un protocolo 2PC centralizado, tiene la desventaja de que el secuenciamiento lineal no permite ningún tipo de paralelismo. El protocolo 2PC lineal puede mejorarse si el proceso de votación adopta el encaminamiento lineal hacia adelante de los mensajes, mientras que el proceso de decisión adopta la topología centralizada, de modo que el nodo n puede difundir la decisión global a todos los participantes en paralelo (Bernstein et al., 1987). Una tercera propuesta, conocida con el nombre de 2PC distribuido, utiliza una topología distribuida, como se muestra en la Figura 23.9(c). El coordinador envía el mensaje PREPARE a todos los participantes, que a su vez envían su decisión a todos los demás nodos. Cada participante espera a recibir los mensajes de los demás nodos antes de decidir si confirma o aborta la transacción. En la práctica, esto elimina la necesidad de que exista la fase de decisión del protocolo 2PC, ya que todos los participantes pueden alcanzar una deci- sión de manera coherente, pero independiente (Skeen, 1981).
  • 107. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 683 •(a) Prepare Fase 1 RC/Abort GC/GA ~ Com mitted/ Aborted Fase 2 ~ Fase 1 Prepare RC/Abort RC/Abort D<JJp'GGC/GA GC/GA GC/GA Nodo 3 Fase 2 Nodo 4~ Nodo 2Nodo 1 (b) (e) Figura 23.9. Topologías 2PC: (a) centralizada; (b) lineal; (c) distribuida. C = coordinador; p¡ = participante; RC = READY _COMMIT; GC = GLOBAL_COMMIT; GA = GLOBAL_ABORT. 23.4.4 Confirmación en tres fases (3PC) Hemos visto que 2PC no es un protocolo no bloqueante, ya que es posible que los nodos queden bloqueados en ciertas circunstancias. Por ejemplo, un proceso en el que se produzca un fin de temporización después de haber votado por la confirmación pero antes de recibir la instrucción global del coordinador quedará bloquea- do si sólo puede comunicarse con otros nodos que tampoco se hayan podido enterar de cuál es la decisión glo- bal. La probabilidad de que el bloqueo se produzca en la práctica es lo suficientemente baja como para que la mayoría de los sistemas existentes utilicen 2PC. Sin embargo, existe un protocolo alternativo no bloqueante, denominado confirmación en tres fases (3PC) propuesto por (Skeen, 1981). La confirmación en tres fases es no bloqueante con respecto a los fallos de nodo, excepto en el caso de que fallen todos los nodos. Los fallos de comunicación pueden conducir, sin embargo, a que los diferentes nodos alcancen diferentes decisiones, violando por tanto el principio de atomicidad de las transacciones globales. El protocolo requiere que:
  • 108. 684 Sistemas de bases de datos • no pueda producirse un particionamiento de la red; • al menos uno de los nodo s debe estar siempre disponible; • como máximo K nodos puedan fallar simultáneamente (en este caso el sistema se clasifica como K- resistente). La idea básica de 3PC consiste en eliminar el periodo de incertidumbre para aquellos participantes que hallan votado COMMIT y estén esperando la instrucción de confirmación o aborto global procedente del coordinador. La confirmación en tres fases introduce una tercera fase, denominada pre-confirmación, entre la votación y la decisión global. Al recibir los votos de todos los participantes, el coordinador envía un men- saje PRE-COMMIT global. Un participante que reciba la pre-confirmación global sabrá que todos los demás participantes han votado COMMIT y que, a su debido tiempo, el propio participante realizará la confirma- ción definitiva, a menos que falle. Cada participante confirma la recepción del mensaje PRE-COMMIT y, una vez que el coordinador ha recibido todas las confirmaciones, difunde el mensaje de confirmación glo- bal de la transacción. Un voto ABORT de un participante se gestionará exactamente de la misma manera que en 2PC. La Figura 23.10 muestra los nuevos diagramas de transición entre estados para un coordinador y para un participante. Tanto el coordinador como el participante siguen teniendo periodos de espera, pero la caracterís- tica importante es que todos los procesos operativos habrán sido informados mediante el mensaje PRE-COM- MIT de la decisión global de confirmar, antes de que el primer proceso realice la confirmación, por lo que pueden actuar independientemente en caso de fallo. Si el coordinador falla, los nodos operativo s pueden comunicarse entre sí y determinar si la transacción debe confirmarse o abortarse sin necesidad de esperar a que el coordinador se recupere. Si ninguno de los nodos operativo s ha recibido un mensaje PRE-COMMIT, abortarán la transacción. El procesamiento cuando todos los participantes votan COMMIT se muestra en la Figura 23.11. Vamos a analizar ahora brevemente los protocolos de terminación y recuperación para 3PC. (a) (b) Figura 23.10. Diagrama de transiciones entre estados para 3PC: (a) coordinador; (b) participante.
  • 109. Coordinador Capítulo 23 Basesde datos distribuidas: conceptos avanzados 685 Participante Commit: escribir begin_commit en el registro enviar PREPARE a todos los participantes esperar las respuestas Pre commit: si todos los participantes han votado READY: escribir pre _commit en el registro enviar PRE_COMMIT a todos los participantes esperar las confirmaciones Ready _commit: una vez que al menos K participantes han confirmado el PRE_COMMIT: escribir entrada commit en el registro •• enviar GLOBAL_COMMIT a todos los participantes enviar confirmaciones Ack: si todos los participantes han confirmado: escribir end_of_transaction en el registro Prepare: escribir ready_commit en el registro enviar READY_COMMIT al coordinador esperar por PRE_COMMIT o GLOBAL_ABORT Pre_commit: escribir entrada pre _commit en el registro enviar confirmación Global_commit: escribir entrada commit en el registro confirmar transacción enviar confirmación Figura 23.11. Protocolo 3PC para un participante que vota COMMIT. Protocolos de terminación para 3PC Igual que con 2PC, la acción que haya que tomar dependerá del estado en el que estuviera el coordinador o el participante cuando se produjo el fin de temporización. Coordinador El coordinador puede estar en uno de los cinco estados durante el proceso de confirmación, como se muestra en la Figura 23.1O(a), pero sólo puede producirse un fin de temporización en tres de esos estados. Las accio- nes que habrá que tomar son las siguientes: • Fin de temporización en el estado WAITING. Es igual que en 2PC. El coordinador está esperando a que todos los participantes confirmen si quieren confirmar o abortar la transacción, por lo que puede decidir abortar globalmente la transacción. • Fin de temporización en el estado PRE-COMMITTED. Ya se ha enviado a los participantes el mensa- je PRE-COMMIT, por lo que los participantes estarán en los estados PRE-COMMIT o READY. En este caso, el coordinador puede completar la transacción escribiendo la entrada commit en el archivo de registro y enviando el mensaje GLOBAL-COMMIT a los participantes. • Fin de temporización en el estado DECIDED. Es igual que en 2PC. El coordinador está esperando que todos los participantes confirmen si han abortado o confirmado con éxito la transacción, por lo que pueden simplemente enviar la decisión global a todos los nodos que todavía no hayan enviado su men- saje de confirmación. Participante El participante puede estar en uno de los cinco estados durante el proceso de confirmación, como se muestra en la Figura 23.10(b), pero sólo puede producirse un fin de temporización en tres estados. Las acciones que habrá que tomar son las siguientes: • Fin de temporización en el estado INITIAL. Es igual que en 2PC. El participante está esperando reci- bir el mensaje PREPARE, por lo que puede abortar unilateralmente la transacción.
  • 110. 686 Sistemas de bases de datos • Fin de temporización en el estado PREPARED. El participante ha enviado su voto al coordinador y está esperando recibir el mensaje PRE-COMMIT o ABORT. En este caso, el participante ejecutará un pro- tocolo de elección para elegir un nuevo coordinador de la transacción y realizará la terminación como se explica más adelante. • Fin de temporización en el estado PRE-COMMlTTED. El participante ha enviado la confirmación correspondiente al mensaje PRE-COMMIT y está esperando el mensaje COMMIT. De nuevo, el par- ticipante seguirá un protocolo de elección para elegir un nuevo coordinador para la transacción y lle- vará a cabo el proceso de terminación como se explica más adelante. Protocolos de recuperación para 3PC Al igual que con 2PC, la acción que habrá que realizar durante el inicio dependerá del estado que hubiera alcanzado el coordinador o participante en el momento del fallo. Fallo del coordinador Consideremos cuatro estados diferentes de fallo de coordinador: • Fallo en el estado INITIAL. El coordinador todavía no ha dado comienzo al proceso de confirmación. La recuperación consiste, en este caso, en reiniciar el proceso de confirmación. • Fallo en el estado WAITING Los participantes pueden haber elegido un nuevo coordinador y haber ter- minado la transacción. Durante el reinicio, el coordinador deberá contactar a otros nodos para deter- minar cuál fue el destino de la transacción. • Fallo en el estado PRE-COMMITTED. De nuevo, los participantes pueden haber elegido un nuevo coordinador y haber terminado la transacción. Durante el reinicio, el coordinador debe contactar a otros nodos para determinar cuál ha sido el destino de la transacción. • Fallo en el estado DECIDED. El coordinador ya ha enviado una instrucción a todos los participantes para abortar o confirmar globalmente la transacción. Durante el reinicio, si el coordinador ha recibido todas las confirmaciones, puede completar la transacción adecuadamente. En caso contrario, tendrá que iniciar el protocolo de terminación correspondiente. Participante Consideramos cuatro estados distintos para el fallo de un participante: • Fallo en el estado INIT1AL. El participante no ha votado todavía sobre la transacción. Por tanto, duran- te la recuperación, puede abortar unilateralmente la transacción. • Fallo en el estado PREPARED. El participante ha enviado su voto al coordinador. En este caso, el par- ticipante debe contactar a otros nodos para determinar cuál ha sido el destino de la transacción. • Fallo en el estado PRE-COMMlTTED. El participante debe contactar a otros nodos para determinar cuál ha sido el destino de la transacción. • Fallo en los estados ABORTED/COMMITTED. El participante ha completado la transacción. Por tanto, no es necesario llevar a cabo ninguna acción adicional durante el reinicio. Protocolo de terminación después de la elección de un nuevo coordinador Puede utilizarse el protocolo de elección que hemos explicado para 2PC con el fin de que los participantes eli- jan un nuevo coordinador después de producirse un fin de temporización. El coordinador recién elegido envia- rá un mensaje STATE-REQ a todos los participantes implicados en la elección, para tratar de determinar cuál es el mejor modo de continuar con la transacción. El nuevo coordinador puede usar las siguientes reglas: (1) Si algún participante ha abortado la transacción, la decisión global será abortar. (2) Si algún participante ha confirmado la transacción, la decisión global será confirmar. (3) Si todos los participantes que respondan todavía no han decidido, la decisión será abortar.
  • 111. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 687 (4) Si algún participante puede confirmar la transacción (porque está en el estado PRE-COMMIT), la deci- sión global será confirmar. Para impedir el bloqueo, el nuevo coordinador enviará primero el mensaje PRE-COMMIT y, una vez que todos los participantes hayan confirmado la recepción del mensaje, enviará el mensaje GLOBAL-COMMIT. 23.4.5 Particionamiento de la red Cuando se produce una partición de la red, mantener la coherencia de la base de datos puede ser más dificil, dependiendo de si los datos están replicados o no. Si los datos no están replicados, podemos permitir que la transacción continúe si ésta no requiere ningún dato de un nodo que esté situado fuera de la partición en la que haya sido iniciada. En caso contrario la transacción deberá esperar hasta que los nodos a los que necesi- te acceder vuelvan a estar disponibles. Si los datos están replicados, el procedimiento es mucho más compli- cado. Vamos a considerar dos ejemplos de anomalías que pueden surgir con los datos replicados en una red particionada, utilizando como ejemplo una relación simple de cuentas bancarias que contienen el saldo de un cliente. Identificación de las actualizaciones Las operaciones de actualización adecuadamente completadas por los usuarios de diferentes particiones pue- den ser difíciles de observar, como se ilustra en la Figura 23.12. En la partición p¡, una transacción ha retira- do 10 euros de una cuenta (con saldo bal,) y en la partición P2, dos transacciones han retirado cada una 5 euros de la misma cuenta. Suponiendo que al principio ambas particiones tuvieran 100 euros como valor de bal" al completar las operaciones ambas tendrán un valor de balx igual a 90 euros. Cuando las particiones se recupe- ren, no será suficiente comprobar el valor en balx y asumir que los campos son coherentes si los valores son iguales. En este caso, el valor después de ejecutar las tres transacciones debería ser de 80 euros. Mantenimiento de la integridad Las operaciones de actualización que los usuarios en las diferentes particiones completen con éxito pueden fácilmente violar las restricciones de integridad, como se ilustra en la Figura 23.13. Suponga que un banco impone una restricción a la cuenta de un cliente (con saldo balx), de modo que dicha cuenta no pueda bajar de O euros. En la partición P¡, una transacción ha retirado 60 euros de la cuenta y en la partición P2, otra trans- acción ha retirado 50 euros de la misma cuenta. Suponiendo que al principio ambas particiones tuvieran un saldo balx de 100 euros, al completar las operaciones una de las particiones tendrá un valor de balx igual a 40 euros y la otra tendrá 50 euros. Observe que ninguna de las dos particiones ha violado la restricción de inte- gridad. Sin embargo, al recuperarse las particiones e implementar completamente ambas transacciones, el saldo de la cuenta será de -10 euros y la restricción de integridad habrá sido violada. El procesamiento dentro de una red particionada implica un compromiso entre la disponibilidad y la corrección (Davidson, 1984; Davidson et al., 1985). La forma más fácil de proporcionar una corrección abso- luta es no permitiendo ningún procesamiento de los datos replicados mientras dura la situación de particiona- Tiempo p¡ begin_transaction balx = balx - la write(balx) commit begin_transaction balx = balx - 5 write(balx) comlnit begin_transaction balx = balx - 5 write(balx) commit Figura 23.12. Identificación de actualizaciones.
  • 112. 688 Sistemas de bases de datos Tiempo begin_transaction balx = balx - 60 write(balx) commit begin_transaction balx = balx - 50 write(balxl commit Figura 23.13. Mantenimiento de la integridad. miento. Por otro lado, la disponibilidad se maximizará si no se impone ninguna restricción al procesamiento de los datos replicados durante la condición de particionamiento. En general, no resulta posible diseñar un protocolo de confirmación atómica no bloqueante para redes arbi- trariamente particionadas (Skeen, 1981). Puesto que las técnicas de recuperación y de control de concurren- cias están tan relacionadas, las técnicas de recuperación que se utilicen después de producirse un particiona- miento de la red dependerán de la estrategia concreta de control de concurrencia que se esté utilizando. Los métodos utilizables pueden clasificarse en dos grupos: pesimistas y optimistas. Protocolos pesimistas Los protocolos pesimistas priman la coherencia de la base de datos con respecto a la disponibilidad y no per- miten, por tanto, que se ejecuten transacciones en una partición si no existe una garantía de que se puede man- tener la coherencia. El protocolo utiliza un algoritmo de control de concurrencia pesimista, como por ejem- plo el 2PL de copia principal o el protocolo de bloqueo mayoritario, como se explica en la Sección 23.2. Los mecanismos de recuperación, utilizando esta técnica, son mucho más sencillos, ya que las actualizaciones habrán estado confinadas a una única partición perfectamente determinada. Las operaciones de recuperación de la red implicarán, simplemente, propagar todas las actualizaciones a todos los demás nodos. Protocolos optimistas Los protocolos optimistas, por el contrario, priman la disponibilidad de la base de datos a expensas de la cohe- rencia, y emplean una técnica optimista de control de concurrencia en la que se permite que las actualizacio- nes tengan lugar independientemente en las distintas particiones. Por tanto, es posible que se detecten inco- herencias cuando los nadas se recuperen. Para determinar si existen incoherencias, pueden utilizarse grafos de precedencia para controlar las dependencias entre los datos. Los grafos de precedencia son similares a los grafos de espera que hemos ana- lizado en la Sección 20.2.4, y muestran qué transacciones han leído y escrito cada elemento de datos. Mientras que la red está particionada, las actualizaciones se llevan a cabo sin ninguna restricción y cada partición man- tiene sus propios grafos de precedencia. Una vez que la red se ha recuperado, se combinan los grafos de pre- cedencia de todas las particiones. Las incoherencias se ponen de manifiesto por la existencia de un ciclo en el grafo. La resolución de la incoherencias dependerá de la semántica de las transacciones y no resulta, por tanto, posible de manera general que el gestor de recuperación re-establezca la coherencia sin intervención del usuario. 23.5 El modelo X10pen de procesamiento distribuido de transacciones Open Group es un consorcio internacional de usuarios, fabricantes de software y fabricantes de hardware que tiene como misión contribuir a la creación de una infraestructura global de la información viable. Fue forma- do en febrero de 1996 por la fusión de X/Open Company Ud (fundada en 1984) y de Open Software Foundation (fundada en 1988). X/Open estableció el grupo de trabajo para procesamiento distribuido de trans- acciones (DTP, Distributed Transaction Processing) con el objetivo de especificar y promover interfaces de programación apropiadas para el procesamiento de transacciones. En aquella época, sin embargo, los sistemas
  • 113. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 689 de procesamiento de transacciones eran entornos operativo s completos, que abarcaban desde la definición de las interfaces en pantalla hasta la implementación de la base de datos. En lugar de tratar de proporcionar un conjunto de estándares para cubrir todas las áreas, el grupo se concentró en aquellos elementos de un sistema de procesamiento de transacciones que proporcionaban las propiedades ACID (atomicidad, coherencia, aisla- miento y durabilidad) que hemos presentado en la Sección 20.1.1. El están dar (de jure) DTP de X/Open que resultó de ese esfuerzo normativo especificaba tres componentes que interactuaban entre sí: una aplicación, un gestor de transacciones (TM, transaction manager) y un gestor de recursos (RM, resource manager) El gestor de recursos puede ser cualquier subsistema que implemente datos transacciones, como por ejem- plo un sistema de base de datos, un sistema de archivos transaccional o un gestor de sesión transaccional. El TM es responsable de definir el ámbito de una transacción, es decir, qué operaciones forman parte de la trans- acción. También es responsable de asignar una identificación unívoca a la transacción que pueda compartirse con otros componentes, así como de coordinar a los otros componentes para determinar el resultado de la transacción. Un TM puede comunicarse también con otros TM para coordinar la finalización de las transac- ciones distribuidas. La aplicación llama al TM para iniciar una transacción y luego llama a uno o más RM para manipular los datos, de acuerdo con la lógica de la aplicación, para finalmente volver a invocar al TM para terminar la transacción. El TM se comunica con los RM para coordinar la transacción. Además, el modelo X/Open define varias interfaces, como se ilustra en la Figura 23.14. Una aplicación puede utilizar la interfaz TX para comunicarse con un TM. La interfaz TX proporciona llamadas que definen el ámbito de la transacción (algunas veces denominado demarcación de la transacción) y que permiten indi- car si hay que confirmar/abortar la transacción. Un TM intercambia información transaccional con los RM a través de la interfaz XA. Finalmente, una aplicación puede comunicarse directamente con los RM mediante una interfaz de programación nativa, como por ejemplo SQL o ISAM. La interfaz TX está compuesta de los siguientes procedimientos: • tx_open y tx_close, para abrir y cerrar una sesión con un TM; • tx_begin, para iniciar una nueva transacción; • tx_commit y tx_abort para confirmar y abortar una transacción. La interfaz XA está compuesta de los siguientes procedimientos: • xa_open y xa_close, para conectarse y desconectarse con un RM; • xa_start y xG_end, para iniciar una nueva transacción con el ID de transacción proporcionado y para finalizarla; • xaJollback, para anular la transacción con el ID de transacción indicado; • xayrepare, para preparar la transacción con el ID de transacción indicado para su confirmación/abor- to global; • xa_commit, para confirmar globalmente la transacción con el ID de transacción indicado; • xa_recover, para extraer una lista de transacciones preparadas, heurísticamente confirmadas o heurís- ticamente abortadas. Cuando un RM está bloqueado, un operador puede imponer una decisión heu- rística (generalmente, abortar), permitiendo así que se liberen los recursos bloqueados. Cuando el TM Llamadas nativas (p. e. Sal) RM Aplicación XA Prepare, Commit, Abort TM Figura 23.14. Interfaces X/Open.
  • 114. 690 Sistemas de bases de datos se recupere, esta lista de transacciones puede utilizarse para informar a las transacciones dudosas de cuál es la decisión tomada (confirmar o abortar). A partir de los datos contenidos en el registro, tam- bién pueden notificar a la aplicación si existen decisiones heurísticas erróneas . • xaJorget, para permitir a un RM olvidar la transacción heurística con el ID de transacción indicado. Por ejemplo, considere el siguiente fragmento de código de aplicación: tx_beginO; EXEC SQL UPDATE 8taft SET salary = salary *1.05 WHERE position = 'Manager'; EXEC SQL UPDATE 8taft SET salary = salary *1.04 WHERE position <> 'Manager'; tx_commitO; Cuando la aplicación invoque la función tx_beginO CL! (call-level interface, interfaz de nivel de llama- da), el TM marcará en el registro el inicio de la transacción y asignará a ésta una identificación unívoca. Después, el TM utiliza XA para informar al servidor de base de datos SQL de que hay una transacción en pro- greso. Una vez que un RM ha recibido esta información, asumirá que todas las llamadas que reciba de la apli- cación forman parte de la transacción, en este caso las dos instrucciones de actualización SQL. Finalmente, cuando la aplicación invoque la función tx_commitO, el TM interactuará con el RM para confirmar la trans- acción. Si la aplicación estaba trabajando con más de un RM, el TM utilizará en este punto el protocolo de confirmación en dos fases para sincronizar la confirmación con los RM. En el entorno distribuido, tenemos que modificar el modelo descrito para permitir que una transacción esté compuesta por subtransacciones, cada una de ellas ejecutándose en un nodo remoto y operando sobre una base de datos remota. El modelo DTP X/Open para un entorno distribuido se ilustra en la Figura 23.15. El mode- lo X/Open se comunica con las aplicaciones a través de un tipo especial de gestor de recursos denominado gestor de comunicaciones (CM, Communications Manager). Como todos los gestores de recursos, el CM reci- be la información sobre las transacciones de los TM, y las aplicaciones hacen llamadas a un CM utilizando su interfaz nativa. En este caso, hacen falta dos mecanismos: un mecanismo de invocación remota y un meca- nismo de transacciones distribuidas. La invocación remota es proporcionada mediante ROSE (Remote Ope- rations Service, servicio de operaciones remotas) de ISO y mediante mecanismos RPC (Remote Procedure Call, llamada a procedimiento remoto). X/Open especifica el protocolo de comunicaciones OSI- TP (Open Systems Interconnection Transaction Processing, procesamiento de transacciones para interconexión de siste- mas abiertos) para coordinar las transacciones distribuidas (la interfaz TM-TM) El X/Open DTP no sólo soporta transacciones planas, sino también transacciones encadenadas y anidadas (véase la Sección 20A). Con las transacciones anidadas, una transacción se abortará si cualquiera de las sub- transacciones lo hace. Begin, Commit, Abort RM Solicitud remota RM Iniciar Figura 23.15. Interfaces X/Open en un entorno distribuido.
  • 115. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 691 El modelo de referencia XlOpen está bastante establecido dentro del sector. Diversos monitores de proce- samiento de transacciones soportan la interfaz TX y muchos fabricantes de bases de datos comerciales pro- porcionan una implementación de la interfaz XA. Entre los principales ejemplos podemos citar CICS y Encina de IBM (que se utiliza principalmente en IBM AIX o Windows NT y que están ahora incluidos en 1MB TXSeries), Tuxedo de BEA Systems, Oracle, Informix y SQL Server. 23.6 Optimización de consultas distribuidas En el Capítulo 21 hemos analizado el tema del procesamiento y optimización de consultas para sistemas SGBD centralizados. Allí vimos dos técnicas para la optimización de consultas: • la primera utilizaba reglas heurísticas para ordenar las operaciones de una consulta; • la segunda, comparaba diferentes estrategias basándose en sus costes relativos y seleccionaba aquella que minimizaba el uso de recursos. En ambos casos, representábamos la consulta mediante un árbol del álgebra relacional para facilitar el pro- cesamiento ulterior. La optimización de consultas distribuidas es más compleja debido a la distribución de los datos. La Figura 23.16 muestra cómo se procesa y optimiza la consulta distribuida en forma de una serie de niveles independientes, que son los siguientes: • Descomposición de la consulta. Este nivel toma una consulta expresada con respecto a las relaciones globales y realiza una optimización parcial empleando las técnicas explicadas en el Capítulo 21. La salida es algún tipo de árbol del álgebra relacional basado en las relaciones globales. Consulta del cálculo relacional sobre los fragmentos Esquema global Consulta de álgebra relacional parcialmente optimizada Ejecución en el nodo de control Esquema de fragmentación Consulta reducida sobre los fragmentos Datos estadisticos de los fragmentos Consulta optimizada sobre los fragmentos con primitivas de comunicación Ejecución en los nodos locales { Esquemas locales Consultas locales optimizadas Figura 23.16. Procesamiento de consultas distribuidas.
  • 116. 692 Sistemas de bases de datos • Localización de los datos. Este nivel toma en consideración el modo en que han sido distribuidos los datos. Se realiza otra iteración de optimización, sustituyendo las relaciones globales de las hojas del árbol de álgebra relacional por sus algoritmos de reconstrucción (algunas veces denominados progra- mas de localización de datos), es decir, las operaciones del álgebra relacional que reconstruyen las relaciones globales a partir de los fragmentos constituyentes. • Optimización global. Este nivel toma en consideración la información estadística para determinar un plan de ejecución casi óptimo. La salida de este nivel es una estrategia de ejecución basada en frag- mentos a la que se han añadido primitivas de comunicación para enviar partes de la consulta a los SGBD locales con el fin de que se ejecuten allí y poder luego recibir los resultados. • Optimización local. Mientras que los primeros tres niveles se ejecutan en el nodo de control (normal- mente, el nodo que ha iniciado la consulta), este nivel concreto se ejecuta en cada uno de los nodos locales implicados en la consulta. Cada SGBD local realizará su propia optimización local utilizando las técnicas descritas en el Capítulo 21. Vamos ahora a analizar los dos niveles intermedios de esta arquitectura. 23.6.1 Localización de los datos Como hemos dicho antes, el objetivo de este nivel es tomar una consulta expresada en forma de algún tipo de árbol del álgebra relacional y tener en cuenta la distribución de los datos para llevar a cabo alguna optimiza- ción ulterior utilizando reglas heurísticas. Para hacer esto, sustituimos las relaciones globales situadas en las hojas del árbol por sus algoritmos de reconstrucción, es decir, las operaciones del álgebra relacional que per- miten reconstruir las relaciones globales a partir de los fragmentos constituyentes. Para la fragmentación hori- zontal, el algoritmo de reconstrucción es la operación de unión; para la fragmentación vertical, es la opera- ción de combinación. El árbol del álgebra relacional formado al aplicar los algoritmo s de reconstrucción se conocen en ocasiones con el nombre de árbol genérico de álgebra relacional. Después, usamos técnicas de reducción para generar una consulta más simple y optimizada. La técnica concreta de reducción que emplee- mos dependerá del tipo de fragmentación del que estemos hablando. Vamos a considerar las técnicas de reduc- ción para los siguientes tipos de fragmentación: • fragmentación horizontal primaria; • fragmentación vertical; • fragmentación horizontal derivada. Reducción para la fragmentación horizontal primaria Para la fragmentación horizontal primaria, vamos a considerar dos casos: la reducción con la operación de selección y la reducción para la operación de combinación. En el primer caso, si el predicado de selección contradice la definición del fragmento, tendremos como resultado una relación intermedia vacía y las opera- ciones pueden ser eliminadas. En el segundo caso, primero usamos la regla de transformación que permite conmutar la operación de combinación y la operación de unión: (R, uR2) I><J R3 = (R, I><J R3) u(R2 I><J R3) Después examinamos cada una de las operaciones de combinación individuales para determinar si hay alguna combinación redundante que pueda eliminarse del resultado. Existirá una combinación redundante si los predicados de los fragmentos no se solapan. Esta regla de transformación es importante en los SGBDD, permitiendo implementar una combinación de dos relaciones o una unión de combinaciones parciales, pudien- do cada parte de la unión realizarse en paralelo. El uso de estas dos reglas de reducción se ilustra en el Ejemplo 23.2. Reducción para la fragmentación vertical La reducción para la fragmentación vertical implica eliminar aquellos fragmentos verticales que no tengan atributos en común con los atributos de proyección, excepto la clave de la relación.
  • 117. Capítulo 23 Bases de datos distribuidas: conceptos avanzados 693 I Ejemplo 23.2 Reducción para la fragmentación horizontal primaria Enumerar los apartamentos en alquiler junto con los correspondientes detalles de la sucursal. Podemos expresar esta consulta en SQL como: SELECT * FROM Branch b, PropertyForRent p WHERE b.branchNo = p.branchNo AND p.type = 'Flat'; Ahora, supongamos que PropertyForRent y Branch están fragmentados horizontalmente de la forma siguiente: ab,.nchNo='B003·A type='House·(PropertyForRent) ab,.nchNo='BOO3·A type='Flar(PropertyForRent) abranchNo!='BOO3'(P ro pe rtyF o rRent) t><Ib.branchNo=p.branchNo /~0p.type='Flat' U i /~U 8, 82 /i~P, (a) 8,: abranchNO='BOO3,(Braneh) B2: abranchNo='BOOABranch) t><Ib.branchNo=p.branchNo /~u u /~ /~P2 0p.type='Flat' 8, B2 i (b) u t:xl"b.branchNo=p.branchNo 1 (e) u ~~ i><lb.branchNo=p.branchNo l><Ib.branchNo=p.branchNo 1 1P2 82 0p.type=·Flat' 8, i I><lb.branchNo=p.branchNo 1°p.type='Flat' 82 i ~~ CXJb.branchNo=p.branchNo t><Ib.branchNo=p.branchNo 1 1P2 8, 0p.type='Flat' 82 i(d) Figura 23.17. Árboles del álgebra relacional para el Ejemplo 23.2: (a) árbol genérico; (b) árbol resultante de la reducción por selección; (c) árbol resultante de conmutar la combinación y la unión; (d) árbol reducido.
  • 118. 694 Sistemas de bases de datos El árbol genérico de álgebra relacional para esta consulta se muestra en la Figura 23.17(a). Si conmu- tamos las operaciones de selección y de unión, se obtiene el árbol de álgebra relacional mostrado en la Figura 23.17(b). Este árbol puede obtenerse observando que la siguiente rama del árbol es redundante (no produce ninguna tupla que contribuya al resultado) y puede ser eliminada: <Jtype:'F'al'(P ,) = <J,ype:·F,at·(<JbranChNO=·BOO3' A ,ype='House,(PropertyForRent)) = 0 Además, puesto que el predicado de selección es un subconjunto de la definición de la fragmentación para P2, la selección no es necesaria. Si ahora conmutamos las operaciones de combinación y de unión, se obtiene el árbol que se muestra en la Figura 23.17(c). Puesto que la segunda y tercera combinacio- nes no contribuyen al resultado, podemos eliminarlas, lo que nos deja la consulta reducida que se muestra en la Figura 23.17(d). I Ejemplo 23.3 Reducción para la fragmentación vertical Enumerar los nombres de cada empleado. Podemos expresar esta consulta en SQL como: SELECT fName, IName FROM Staff; Vamos a emplear el esquema de fragmentación para Staff que hemos usado en el Ejemplo 22.3: 81: nstaffNo, position, sex, 008, sa'ary(Staff) 82: ITstaffNo, fName, IName, branchNo(Staff) El árbol genérico de álgebra relacional para esta consulta se muestra en la Figura 23 .18(a). Conmutan- do las operaciones de proyección y combinación, la operación de proyección sobre SI es redundante, porque los atributos de proyección fName y IName no son parte de SI' El árbol reducido se muestra en la Figura 23.18(b). 0.'1"- I><1staffNo /~ (a) (b) Figura 23.18. Árboles del álgebra relacional para el Ejemplo 23.3: (a) árbol genérico; (b) árbol reducido. Reducción para la fragmentación horizontal derivada La reducción para la fragmentación horizontal derivada utiliza, de nuevo, la regla de transformación que per- mite conmutar las operaciones de combinación y de unión. En este caso, utilizamos el hecho de que la frag- mentación para una relación está basada en la otra relación y, al efectuar la conmutación, algunas de las com- binaciones parciales deben ser redundantes.
  • 119. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 695 I Ejemplo 23.4 Reducción para la fragmentación horizontal derivada Enumerar los clientes registrados en la sucursal B003 junto con los detalles de la sucursal. Podemos expresar esta consulta en SQL como: SELECT * FROM Branch b, Cliente WHERE b.branchNo = c.branchNoAND b.branchNo = 'B003'; Vamos a asumir que Branch está fragmentada horizontalmente como en el Ejemplo 23.2 y que la frag- mentación de Clientestá derivada de Branch: B1 = O'sbranchNo='B003,(Branch)B2 = O'sbranchNol='B003,(Branch) C¡= Client~branchNoB¡ i = 1, 2 El árbol genérico del álgebra relacional se muestra en la Figura 23.19(a). Si conmutamos las operacio- nes de selección y de unión, la selección sobre el fragmento B2será redundante y esta rama del árbol puede eliminarse. Toda la operación de selección puede eliminarse, ya que el fragmento BI está defi- nido sobre la sucursal B003. Si ahora conmutamos las operaciones de combinación y de unión, se obtiene el árbol mostrado en la Figura 23.19(b). La segunda operación de combinación entre BI y c2 produce una relación nula y puede eliminarse, lo que nos deja el árbol reducido de la Figura 23 .19(c). (a) u /~lXIb.branchNo=c.branchNo t><Ib.branchNo=c.branchNo / / (b) t><Ib.branchNo=c.branch No / (e) Figura 23.19. Árboles del álgebra relacional para el Ejemplo 23.4: (a) árbol genérico; (b) árbol resultante de conmutar la combinación y la unión; (c) árbol reducido. 23.6.2 Combinaciones distribuidas La combinación es una de las operaciones más caras del álgebra relaciona!. Una técnica utilizada en la opti- mización de consultas distribuidas consiste en sustituir las combinaciones por una serie de semicombinacio- nes (véase la Sección 4.1.3). La operación de semicombinación tiene la importante propiedad de reducir el tamaño de la relación operando. Cuando el principal componente de coste es el tiempo de conmutación, la operación de semicombinación resulta particularmente útil para mejorar el procesamiento de las consultas dis- tribuidas, ya que reduce la cantidad de datos que hay que transferir entre unos nodos y otros. Por ejemplo, suponga que queremos evaluar la expresión de combinación RI ~x R2en el nodo S2' donde RI y R2son fragmentos almacenados en los nodos SI y S2' respectivamente, RI y R2están definidas sobre los atributos A = (x, al' a2, ••• , an) y B = (x, b], b2, ... , bm), respectivamente. Podemos cambiar esto para utilizar, en su lugar, la operación de semi combinación. En primer lugar, observe que podemos reescribir una combi- nación como:
  • 120. 696 Sistemas de bases de datos R, ~x R2 = (R, ~x R2) ~x R2 Por tanto, podemos evaluar la operación de combinación de la forma siguiente: (1) Evaluar R' = IllR2) en S2 (sólo se necesitan atributos de combinación en SI)' (2) Transferir R' al nodo SI' (3) Evaluar R" = R¡ ~x R' en SI' (4) Transferir R" al nodo Sz. (5) Evaluar R" I><l R2 en el nodo Sz. La utilización de semicombinaciones es beneficiosa si sólo hay unas pocas tuplas de R¡ que participen en la combinación de R¡ y Rz.La técnica basada en la combinación directa resultará más adecuada si la mayoría de las tuplas de R¡ participan en la combinación, porque la técnica de semicombinación requiere una transfe- rencia adicional de una proyección sobre el atributo de combinación. El lector interesado en leer un estudio más completo de las semicombinaciones puede consultar el artículo de Bernstein y Chiu (1981). Es necesa- rio recalcar que la operación de semicombinación no se utiliza en ninguno de los principales SGBDD comer- ciales. 23.6.3 Optimización global Como hemos explicado antes, el objetivo de este nivel consiste en tomar el plan de consulta reducido para el nivel de localización de datos y hallar una estrategia de ejecución casi óptima. Al igual que con la optimiza- ción de consultas centralizada que hemos analizado en la Sección 21.5, esto implica evaluar el coste de dife- rentes estrategias de ejecución y seleccionar la estrategia óptima en dicho espacio de búsqueda. Costes En un SGBD centralizado, el coste de ejecución es una combinación de los costes de E/S y de procesador. Puesto que el acceso a disco es lento comparado con el acceso a memoria, el acceso a disco tiende a ser el coste dominante en el procesamiento de consultas para un SGBD centralizado, y es en él, precisamente, donde nos hemos concentrado exclusivamente a la hora de proporcionar estimaciones de costes en el Capítulo 21. Sin embargo, en el entorno distribuido es necesario tomar en consideración la velocidad de la red subyacen- te a la hora de comparar las diferentes estrategias. Como hemos mencionado en la Sección 22.5.3, una red de área extensa (WAN) puede tener un ancho de banda de sólo unos pocos kilobytes por segundo, en cuyo caso podríamos ignorar los costes del procesamiento local. Por otro lado, una red de área local (LAN) es normal- mente mucho más rápida que una WAN, aunque sigue siendo más lenta que el acceso a disco, pero en este caso no hay ningún coste que domine sobre los demás y será preciso tener en cuenta todos ellos. Además, para un SGBD centralizado hemos considerado un modelo de costes basado en el coste total (tiempo) de todas las operaciones de la consulta. Otro modelo de coste alternativo se basa en el tiempo de res- puesta, es decir, en el tiempo transcurrido desde el inicio de la consulta hasta su terminación. Este otro mode- lo toma en consideración el paralelismo inherente a los sistemas distribuidos. Los dos modelos de coste pue- den producir resultados diferentes. Por ejemplo, considere la transferencia de datos ilustrada en la Figura 23.20, donde se transfieren x bits de datos desde el nodo 1 al nodo 2 e y bits de datos desde el nodo 2 al nodo 3. Utilizando una fórmula de coste total, el coste de estas operaciones será: Nodo 1 ybits ~ Nodo 3 Tiempo total ~ 2*Co + (x + y)/tasa_transmisión Tiempo de respuesta = max{Co + (x/tasa_transmisión), Co + (y/tasa_transmisión)) Figura 23.20. Ejemplo del efecto de los diferentes modelos de coste cuando se transfieren datos entre nadas.
  • 121. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 697 Tiempo total = 2*Co+ (x + y)/tasa_transmisión Utilizando la fórmula del tiempo de respuesta, el coste de estas operaciones será: Tiempo de respuesta = max {Co + (x/tasa_transmisión), Co + (y/tasa_transmisión)} En lo que resta de esta sección, vamos a analizar dos algoritmos de optimización de consultas distribuidas: • algoritmo R*; • algoritmo SDD-l. Algoritmo R* R* era un SGBD distribuido experimental desarrollado en IBM Research a principios de la década de 1980 y . que incorporaba muchos de los mecanismos del anterior proyecto System R, adaptados a un entorno distribui- do (Williams et al., 1982). Los principales objetivos de R* eran la transparencia de ubicación, la autonomía de los sitios y un mínimo sacrificio de las prestaciones. Las principales ampliaciones a System R para sopor- tar la distribución de datos estaban relacionadas con la definición de los datos, la gestión de transacciones, el control de autorización y la compilación, optimización y ejecución de consultas. Para la distribución de consultas distribuidas R* utiliza un modelo de costes basado en el coste total y un mecanismo de optimización de consultas estático (Selinger y Abida, 1980; Lohman et al., 1985). Al igual que el optimizador centralizado de System R, el algoritmo de optimización está basado en una búsqueda exhaus- tiva de todas las ordenaciones de las combinaciones, de todos los métodos de combinación (bucle anidado o combinación de ordenación-mezcla) y de todas las rutas de acceso para cada relación, como se explica en la Sección 21.5. Cuando se requiere llevar a cabo una combinación que implique relaciones almacenadas en diferentes nodos, R* selecciona los nodos que tienen que efectuar la combinación y el método de transferir los datos entre los nodos. Para una combinación (R b<JA S) con la relación R en el nodo 1 y la relación S en el nodo 2, hay tres nodos candidatos: • nodo 1, donde está ubicada la relación R; • nodo 2, donde está ubicada la relación S; • algún otro nodo (por ejemplo, el nodo de una relación T que haya que combinar con la combinación de R y S). En R* hay dos métodos para transferir datos entre los nodos: (1) Transmitir toda la relación. En este caso, se transfiere la relación completa al nodo de combinación, donde se la almacena temporalmente antes de ejecutar la combinación o donde se la combina tupla a tupla según éstas van llegando. (2) Extraer las tuplas según sea necesario. En este caso, el nodo correspondiente a la relación externa coordina la transferencia de las tuplas y las utiliza directamente sin almacenadas de manera temporal. El nodo coordinador explora secuencialmente la relación externa y solicita, para cada valor, las tuplas correspondientes del nodo donde se encuentra la relación interna (lo que equivale en la práctica a efec- tuar una semicombinación de tupla en tupla, aunque hace falta enviar más mensajes que con la semi- combinación). El primer método requiere una mayor transferencia de datos, pero un menor número de mensajes que el segundo método. Aunque podría utilizarse cualquier método de combinación con cada uno de los métodos de transmisión, R* considera que merecen la pena los siguientes: (1) Bucle anidado, enviando toda la relación externa al nodo donde está almacenada la relación interna En este caso, no hay necesidad de utilizar ningún almacenamiento temporal y las tuplas pueden com- binarse a medida que van llegando al nodo de la relación interna. El coste es: Coste total = coste (bucle anidado) + [Co + (nTuples(R)*nBitslnTuple(R)/tasa_transmisión)]
  • 122. 698 Sistemas de bases de datos (2) Combinación de ordenación-mezcla, enviando toda la relación interna al nodo donde está almacena- da la relación externa En este caso, las tuplas no pueden combinarse a medida que llegan y es preci- so almacenadas en una relación temporal. El coste es: Coste total = coste(almacenando S en el nodo 1) + coste (ordenación-mezcla) + [Co + (nTuples(s)*nBitsInTuple(S)/tasa _transmisión)] (3) Bucle anidado, extrayendo las tuplas de la relación interna según vaya siendo necesario para cada tupla de la relación externa De nuevo, las tuplas pueden combinarse a medida que llegan. El coste es: Coste total = coste (bucle anidado) + nTuples(R)*[Co + (nBitsInAttribute(A)/tasa _transmisión)] + nTuples(R)*[Co + (AVG(R, S)*nBitsInTuple(S)/tasa_transmisión)] donde AVG(R, S) denota un número de tuplas de S que (como promedio) se corresponden con cada tupla de R, es decir AVG(R, S) = nTuples(S 1> AR)/nTuples(R) (4) Combinación de ordenación-mezcla, extrayendo las tuplas de la relación interna según vaya siendo necesario para cada tupla de la relación externa De nuevo, pueden combinarse las tuplas a medida que vayan llegando. El coste es similar al anterior y se deja como ejercicio para el lector. (5) Enviar ambas relaciones a un tercer nodo La relación interna se transfiere al tercer nodo y se alma- cena en una relación temporal. La relación externa se transfiere entonces al tercer nodo y sus tuplas se combinan con la relación temporal a medida que van llegando. Puede utilizarse tanto la combinación de bucle anidado como la de ordenación-mezcla en este caso. El coste puede deducirse a partir de los costes que antes hemos proporcionado y se deja como ejercicio para el lector. Aunque R * se ve obligado a evaluar muchas estrategias utilizando este enfoque, esta forma de actuar puede merecer la pena si la consulta se ejecuta frecuentemente. Aunque el algoritmo descrito por Selinger y Abida tiene en cuenta la fragmentación, la versión del algoritmo implementada en R* sólo trata con relacio- nes completas." Algoritmo SDD-1 SDD-l fue otro SGBD distribuido experimental desarrollado por la división de investigación de Computer Corporation de América a finales de la década de 1970 y principios de la de 1980, que se ejecutaba en una red de computadoras PDP-l1 de DEC conectadas a través de Arpanet (Rothnie et al., 1980). Proporcionaba una independencia completa con respecto a la ubicación, fragmentación y a la replicación. El optimizador del SDD-l estaba basado en un método anterior conocido con el nombre de algoritmo de 'escalada de la colina', un algoritmo que comienza con una solución factible inicial que luego se va mejorando iterativamente (Wong, 1977). Fue modificado para hacer uso del operador de semicombinación con el fin de reducir la cardinalidad de los operandos de combinación. Al igual que el algoritmo R* el objetivo del optimizador SDD-l consiste en minimizar el coste total, aunque a diferencia de R* ignora los costes de procesamiento local y se concen- tra en el tamaño de los mensajes de comunicaciones. De nuevo igual que el R*, la temporización de procesa- miento de las consultas que se utiliza es estática. El algoritmo está basado en el concepto de 'semicombinaciones beneficiosas'. El coste de comunicación de una semicombinación es simplemente el coste de transferir el atributo de combinación del primer operan- do al nodo del segundo operando, es decir: Coste de comunicación (R 1>AS) = Co + [size(TIA(S))/tasa_transmisión] = Co + [nTuples(S)*nBitsInAttribute(A)/tasa_transmisión] (A es una clave de S) El 'beneficio' de la semicombinación se toma como el coste de transferir tuplas irrelevantes de R, coste que la combinación permite evitar:
  • 123. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 699 Beneficio(R ~A s) = (1 - SFA(S)) * [nTup1es(R)*nBitslnTuple(R)/tasa_transmisión] donde SFA(S)es el factor de selectividad de la combinación (la fracción de tuplas de R que se combinan con tuplas de S), que puede estimarse como: SFA(S) = nTuples(IlA(S))/nDistinct(A) donde nDistinct(A) es el número de valores distintos en el dominio del atributo A. El algoritmo funciona de la forma siguiente: (1) Fase l. Inicialización. Se realizan todas las reducciones locales mediante operaciones de selección y proyección. Se ejecutan semicombinaciones dentro del mismo nodo para reducir el tamaño de las rela- ciones. Se genera el conjunto de todas las semicombinaciones beneficiosas entre nodos (la semicom- binación es beneficiosa si su coste es inferior a su beneficio). (2) Fase 2. Selección de semicombinaciones beneficiosas. Se seleccionan iterativamente las semicombi- naciones más beneficiosas a partir del conjunto generado en la fase anterior y se las añade a la estra- tegia de ejecución. Después de cada operación, se actualizan las estadísticas de la base de datos para reflejar la incorporación de la semicombinación y se actualiza el conjunto con nuevas semicombina- ciones beneficiosas. (3) Fase 3. Selección de nadas para las operaciones. Se selecciona, entre todos los nodos, el nodo para el que la transmisión de todas las relaciones a las que hace referencia la consulta tiene un mínimo coste. Se selecciona el nodo que contenga la mayor cantidad de datos después de la fase de reducción, de modo que la cantidad total de datos transferidos desde otros nodos sea mínima. (4) Fase 4. Postoptimización. Se descartan las semicombinaciones inútiles. Por ejemplo, si la relación R reside en el nodo donde se realizan las operaciones y R va a ser reducida por una semicombinación, pero no se utiliza para reducir otras relaciones después de la ejecución de la semi combinación, enton- ces como R no necesita ser transferida a otro nodo durante la fase de operación final, la semicombina- ción sobre R es inútil y puede descartarse. El siguiente ejemplo ilustra las anteriores explicaciones. I Ejemplo 23.5 Algoritmo SDD-1 Enumerar los detalles de las sucursales junto con los inmuebles gestionados y los detalles del empleado que los gestiona. Podemos expresar esta consulta en SQL como: SELECT * FROM Branch b, PropertyForRentp, Staffs, WHERE b.branchNo = p.branchNoAND p.staffNo= s.staffNo; Suponga que la relación Branch se encuentra en el nodo 1, que la relación PropertyForRent se encuentra en el nodo 2 y que la relación Staffse encuentra en el nodo 3. Suponga, asimismo, que el coste de ini- ciar un mensaje, Co, es Oy que la tasa de transmisión, tasa_transmisión, es 1. La Figura 23.21 propor- ciona el conjunto inicial de estadísticas de la base de datos para estas relaciones. El conjunto inicial de semicombinaciones es: SJ 1: PropertyForRent~branchNo Branch SJ2: Branch ~branchNo PropertyForRent SJ3: PropertyForRent~slaffNo Staff SJ4: Staff~SlaffNo PropertyForRent El beneficio es (1 - 1)*120,000 = O; el coste es 1600 El beneficio es (1 - 0.1)*10,000 = 9000; el coste es 640 El beneficio es (1 - 0.9)* 120,000 = 12,000; el coste es 2880 El beneficio es (1 - 0.2)*50,000 = 40,000; el coste es 1280 En este caso, las semicombinaciones beneficiosas son SJ2, SJ3 y SJ4, por lo que añadiremos SJ4 (la que tiene la mayor diferencia) a la estrategia de ejecución. Ahora actualizamos las estadísticas basándonos en esta semicombinación, con la cual la cardinalidad de Staff' pasa a ser 100*0.2 = 20, el tamaño pasa
  • 124. 700 Sistemas de bases de datos relation sitecardinality tu pie sizerelation size150 20010,000 200600120,0003100 50050,000 attribute size(ITattribute)SFattribute b.branchNo 16001 p.branchNo 6400.1 p.staffNo 12800.2 s.staffNo 28800.9 Figura 23.21. Conjunto inicial de estadísticas de la base de datos para Branch, PropertyForRent y Staff. a ser 50,000*0.2 = 10,000 Y el factor de selectividad puede estimarse como 0.9*0.2 = 0.18. En la siguiente iteración vemos que SJ3: PropertyForRent [>staffNoStaff' es beneficiosa con un coste de 3720 y la añadimos a la estrategia de ejecución. De nuevo, actualizamos las estadísticas, con lo que la cardina- lidad de PropertyForRent' pasa a ser 200*0.9 = 180 Y el tamaño pasa a ser 120,000*0.9 = 108,000. Otra iteración nos permite determinar la semicombinación SJ2: Branch [>braochNoPropertyForRent como benefi- ciosa, por lo que la añadimos a la estrategia de ejecución y actualizamos las estadísticas de Branch, que- dando la cardinalidad igual a 40*0.1 = 4 Y el tamaño 10,000*0.1 = 1000. Después de la reducción, la cantidad de datos almacenados es igual a 1000 en el nodo 1, 108,000 en el nodo 2 y 10,000 en el nodo 3. Seleccionamos el nodo 2 como el nodo para las operaciones finales. Durante la postoptimización, eliminamos la estrategia SJ3. La estrategia seleccionada consistirá en enviar Staff [>SlaffNoPropertyForRent y Branch [>braochNoPropertyForRent al nodo 3. ~ Otros algoritmo s de optimización de consultas distribuidas muy conocidos son AHY (Apers et al., 1983) y Distributed Ingres (Epstein et al., 1978). El lector interesado puede consultar asimismo diversas publicacio- nes dentro de este campo, como por ejemplo Yu y Chang (1984), Steinbrunn et al. (1997) y Kossmann (2000). 23.7 Distribución en Oracle Para completar este capítulo, vamos a examinar la funcionalidad de SGBD distribuido de Oracle9i (Oracle Corporation, 2004d). En esta sección, utilizaremos la terminología de este SGBD; Oracle utiliza el término tabla para referirse a las relaciones, estando las tablas compuestas por columnas y filas. En la Sección 8.2 hemos proporcionado ya una introducción general a Oracle. 23.7.1 Funcionalidad del SGBDD de Oracle Al igual que muchos SGBDD comerciales, Oracle no soporta el tipo de mecanismo de fragmentación que hemos analizado en el Capítulo 22, aunque el DBA puede distribuir manualmente los datos para conseguir un efecto similar. Sin embargo, esto coloca sobre el usuario final la responsabilidad de saber cómo se ha frag- mentado una tabla y de incluir dicho conocimiento dentro de la aplicación. En otras palabras, el SGBDD de Oracle no soporta la transparencia de fragmentación, aunque sí que soporta la transparencia de ubicación, como veremos en breve. En esta sección, proporcionamos una panorámica de la funcionalidad del SGBDD de Oracle, donde cubriremos: • conectividad; • nombres globales de las bases de datos; • enlaces de la base de datos; • transacciones; • integridad referencial; • bases de datos distribuidas heterogéneas; • optimización de consultas distribuidas.
  • 125. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 701 En el siguiente capítulo hablaremos de los mecanismos de replicación en Oracle Conectividad Oracle Net Services es la aplicación de acceso a datos que Oracle proporciona para soportar la comunicación entre clientes y servidores (las versiones anteriores de Oracle utilizaban SQL *Net o Net8). Oracle Net Services permite comunicaciones tanto de tipo cliente-servidor como servidor-servidor a través de cualquier red, soportando tanto el procesamiento distribuido como las capacidades del SGBD distribuido. Incluso si un proceso se está ejecutando en la misma máquina que la instancia de la base de datos sigue requiriéndose Net Services para establecer la conexión con la base de datos. Net Services es responsable también de traducir entre unos conjuntos de caracteres y otros y entre unas representaciones de datos y otras que puedan existir en el nivel del sistema operativo. Net Services establece una conexión basando la solicitud de conexión a la capa TNS (Transparent Network Substrate, substrato de red transparente), que determina qué servidor debe gestionar la solicitud y envía ésta utilizando el protocolo de red apropiado (por ejemplo, TCP/IP). Net Services también puede gestionar la comunicación entre máquinas que utilizan protocolos de red diferentes, mediante Connection Manager, este tema era anteriormente gestionado por MultiProtocol Interchange en Oracle 7. El producto Oracle Names almacena información en una ubicación centralizada acerca de las bases de datos de un entorno distribuido. Cuando una aplicación efectúa una solicitud de conexión, se consulta el repo- sitorio de Oracle Names para determinar la ubicación del servidor de base de datos. Una alternativa a la uti- lización de Oracle Names consiste en almacenar esta información en un archivo local tnsnames.ora en todas las máquinas cliente. En futuras versiones, dejará de soportarse Oracle Names para pasar a utilizar un servi- dor de directorio compatible con LDAP. Nombres globales de las bases de datos A cada base de datos distribuida se le asigna un nombre, denominado nombre global de la base de datos, que es distinto del de las demás bases de datos del sistema. Oracle forma el nombre global de la base de datos anteponiendo como prefijo al nombre local de la base de datos el nombre del dominio de red al que corres- ponde. El nombre de dominio debe seguir los convenios estándar de Internet, debiendo estar los niveles sepa- rados por puntos y ordenados desde la hoja a la raíz, de izquierda a derecha. Por ejemplo, la Figura 23.22 ilus- tra una posible disposición jerárquica de las bases de datos para DreamHome. Aunque hay dos bases de datos denominadas Rentals en esta figura, podemos utilizar el nombre del dominio de red LONDON.SOUTH.COM para diferenciar la base de datos de Londres de la situada en Glasgow. En este caso, los nombres globales de las bases de datos serán: RENTALS.LONDON.SOUTH.COM RENTALS.GLASGOW.NORTH.COM Figura 23.22. Estructura de la red de DreamHome.
  • 126. 702 Sistemas de bases de datos Enlaces de la base de datos Las bases de datos distribuidas en Oracle están construidas sobre enlaces de la base de datos, que definen una ruta de comunicación desde una base de datos Oracle a otra base de datos (posiblemente no Oracle). El propósito de los enlaces de base de datos es hacer que los datos remotos estén disponibles para su consulta y actualización, actuando en esencia como una especie de inicio de sesión almacenado para la base de datos remota. A un enlace de base de datos hay que darle el mismo nombre de base de datos global que tenga la base de datos remota a la que hace referencia, en cuyo caso los enlaces de base de datos serán esencialmen- te transparentes a los usuarios de una base de datos distribuida. Por ejemplo, la siguiente instrucción crea un enlace de base de datos en la base de datos local, enlace que apunta a la base de datos remota situada en Glasgow: CREATE PUBLIC DATABAS E LINK RENTALS.GLASGOWNORTH.COM; Una vez creado un enlace de base de datos, puede utilizarse para hacer referencia a tablas y vistas de la base de datos remota, añadiendo @enlacebasedatos al nombre de tabla o de vista utilizado en una instrucción SQL. Puede efectuarse una consulta sobre una tabla o vista remotas mediante la instrucción SELECT. Con la opción distribuida de Oracle, también puede accederse a las tablas y vistas remotas mediante instrucciones INSERT, UPDATE y DELETE. Por ejemplo, podemos utilizar las siguientes instrucciones SQL para consul- tar y actualizar la tabla Staffen el modo remoto: SELECT * FROM Staff@RENTALS.GLASGOWNORTH.COM; UPDATE Staff@RENTALS.GLASGOWNORTH.COM SET salary = salary*1.05; Un usuario puede acceder también a tablas que sean propiedad de otros usuarios en la misma base de datos, precediendo el nombre de la base de datos con el nombre del esquema. Por ejemplo, si suponemos que el usuario actual tiene acceso a la tabla Viewingdel esquema Supervisor, podemos utilizar la siguiente instruc- ción SQL: SELECT * FROM Supervisor.Viewing@RENTALS.GLASGOWNORTH.COM; Esta instrucción se conecta a la base de datos remota en nombre del usuario actual y consulta la tabla Viewingdel esquema Supervisor. Puede crearse un sinónimo para esconder el hecho de que la tabla Viewingde Supervisor está en una base de datos remota. La:'siguiente instrucción haría que todas las referencias futuras a Viewingaccedieran a una tabla Viewingremota propiedad de Supervisor: CREATE SYNONYM ViewingFOR SupervisorViewing@RENTALS.GLASGOWNORTH.COM; SELECT * FROM Viewing; De esta forma, el uso de sinónimos proporciona tanto independencia de los datos como transparencia con respecto a la ubicación. Transacciones Oracle soporta las transacciones sobre datos remotos, incluyendo: • Instrucciones SQL remotas. Una consulta remota es una consulta que selecciona información de una o más tablas remotas, todas residen en el mismo nodo remoto. Una instrucción de actualización remota es una actualización que modifica los datos en una o más tablas, todas las cuales están ubicadas en el mismo nodo remoto . • Instrucciones SQL distribuidas. Una consulta distribuida extrae información de dos o más nadas. Una instrucción de actualización distribuida modifica datos de dos o más nadas. Puede realizarse una actualización distribuida utilizando un subprograma PL/SQL, como por ejemplo un procedimiento o disparador, que incluya dos o más actualizaciones remotas que accedan a datos situados en nadas dife- rentes. Oracle envía las instrucciones del programa a los nadas remotos y su ejecución se completa adecuadamente o falla como una única unidad.
  • 127. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 703 • Transacciones remotas. Una transacción remota contiene una o más instrucciones remotas, todas las cuales hacen referencia a un único nodo remoto . • Transacciones distribuidas. Una transacción distribuida es una transacción que incluye una o más ins- trucciones que, individualmente o como grupo, actualizan datos situados en dos o más nodos distintos de una base de datos distribuida. En tales casos, Oracle garantiza la integridad de las transacciones dis- tribuidas utilizando el protocolo de confirmación en dos fases (2PC) presentado en la Sección 23.4.3. Integridad referencial Oracle no permite definir restricciones de integridad referencial declarativas entre las distintas bases de datos de un sistema distribuido (es decir, una restricción de integridad referencial declarativa sobre una tabla no puede especificar una clave externa que haga referencia a una clave principal o unívoca de una tabla remota). Sin embargo, las relaciones de tablas padre-hijo entre bases de datos pueden mantenerse utilizando dispara- dores. Bases de datos distribuidas heterogéneas En un SGBDD heterogéneo de Oracle, al menos uno de los SGBD es un sistema no Oracle. Utilizando Heterogeneous Services y un agente Heterogeneous Services específico para un sistema no Oracle, Oracle puede ocultar los aspectos de distribución y heterogeneidad a ojos del usuario. El agente de Heterogeneous Services se comunica con el sistema no Oracle y con el componente Heterogeneous Services del servidor Oracle. El agente ejecuta, por cuenta del servidor Oracle, instrucciones SQL, procedimientos y solicitudes transacciones en el sistema no Oracle. Puede accederse a Heterogeneous Services mediante las siguientes herramientas: • Transparent Gateways, que proporciona acceso SQL a un SGBD no Oracle incluyendo DB2/400, DB2 para OS/390, Informix, Sybase, SQL Server, Rdb, RMS y Non-Stop SQL. Estas pasarelas (gateway) se ejecutan normalmente sobre la máquina con el SGBD no Oracle, en lugar de en la máquina donde reside el servidor Oracle. Sin embargo, la pasarela Transparent Gateway para DRDA (véase la Sección 22.5.2), que proporciona acceso SQL a bases de datos compatibles DRDA, como DB2, SQL/DS y SQL/400, no requiere utilizar ningún software de Oracle en el sistema de destino. La Figura 23.23(a) ilustra la arquitectura de Transparent Gateway. • Generic Conectivity, que es un conjunto de agentes que están enlazados con controladores proporcio- nados por el cliente. Actualmente, Oracle proporciona agentes para ODBC y OLE DB. La funcionali- dad de estos agentes es más limitada que la de las pasarelas Transparent Gateway. La Figura 23.23(b) ilustra la arquitectura de Generic Conectivity. Las principales características de Heterogeneous Services son: • Transacciones distribuidas. Una transacción pueden abarcar tanto sistemas Oracle como no Oracle uti- lizando confirmación en dos fases (véase la Sección 23.4.3). • Acceso SQL transparente. Las instrucciones SQL ejecutadas por la aplicación se transforman de mane- ra transparente en instrucciones SQL que pueda reconocer el sistema no Oracle. • Acceso procedimental. Puede accederse a los sistemas procedimentales, como los sistemas de mensa- jería y la gestión de colas desde un servidor Oracle9i utilizando llamadas a procedimientos remotos PL/SQL. • Traducción del diccionario de datos. Para hacer que el sistema no Oracle aparezca como otro servidor Oracle, las instrucciones SQL que contienen referencias a las tablas del diccionario de datos de Oracle se transforman en instrucciones SQL con referencias a las tablas del diccionario de datos del sistema no Oracle. • SQL de paso directo y procedimientos almacenados. Una aplicación puede acceder directamente a un sistema no Oracle utilizando el dialecto SQL de dicho sistema. Los procedimientos almacenados en un sistema no Oracle basado en SQL se tratan como si fueran procedimientos remotos PL/SQL.
  • 128. 704 Sistemas de bases de datos Servidor Oracle Oracle9í Oracle Net Heterogeneous Services Oracle Net Servidor no Oracle (a) Servidor Oracle Oracle9í Componentes no Oracle Oracle Net Heterogeneous Services 1 : -Gesto-r-de coñirolador - - - - : 4 : ODBC ' 4 ,..-----------------------~ 2 : Controlador ODBC : 4 : ~ 4 : Cliente del sistema : 3 :_09_Q[élG.I!? : Servidor no Oracle (b) Sistema no Oracle Figura 23.23. Oracle Heterogeneous Services: (a) utilizando una pasarela Transparent Gateway en el sistema no Oracle; (b) utilizando Generic Conectivity a través de ODBC . • Soporte de idioma nacional. Heterogeneous Services soporta conjuntos de caracteres multibyte y se encarga de efectuar la traducción de conjuntos de caracteres entre OracIe y el sistema no OracIe.
  • 129. Capítulo 23 Bases de datos distribuidas: conceptos avanzados 705 • Optimización. Heterogeneous Services puede recopilar ciertas estadísticas sobre tablas e índices en el sistema no Oracle y transferir esa información al optimizador basado en costes de Oracle. Optimización de consultas distribuidas El SQBD local de Oracle descompone cada consulta distribuida en su correspondiente serie de consultas remotas, que se envían a los SGBD remotos para su ejecución. Los SGBD remotos ejecutan las consultas y devuelven los resultados al nodo local. El nodo local realiza entonces cualquier procesamiento que sea nece- sario y devuelve los resultados al usuario o a la aplicación. Sólo se extraen de las tablas remotas los datos necesarios, reduciendo así la cantidad de datos que hace falta transferir. La optimización de consultas distri- buidas utiliza el optimizador basado en costes de Oracle, del que hemos hablado en la Sección 21.6 Resumen del capítulo • Los objetivos del procesamiento de transacciones distribuidas son los mismos que en los sistemas centra- lizados, aunque la complejidad aumenta debido a que el SGBDD debe garantizar la atomicidad tanto de la transacción global como la de cada una de las subtransacciones. • Si la planificación de ejecución de la transacción en cada nodo es serializable, entonces la planificación global (la unión de todas las planificaciones locales) es también serializable, siempre y cuando los órde- nes de serialización locales sean idénticos. Esto requiere que todas las subtransacciones aparezcan en el mismo orden en las planificaciones serie equivalente de todos los nodos. • Dos métodos que pueden utilizarse para garantizar la serializabilidad distribuida son el bloqueo y el mar- cado temporal. En el bloqueo en dos fases (2PL), una transacción adquiere todos los bloqueos antes de liberar ninguno de ellos. Los protocolos de bloqueo en dos fases pueden utilizar gestores de bloqueo cen- tralizados, de copia principal o distribuidos. También puede usarse la técnica de votación mayoritaria. Con el marcado temporal, las transacciones se ordenan de tal forma que las más antiguas tengan prioridad en caso de conflicto. • El bloqueo distribuido implica la combinación de los grafos de espera locales, para comprobar si existen ciclos. Si se detecta un ciclo, deberá abortarse y reiniciarse una o más transacciones hasta que el ciclo quede roto. Hay tres métodos comunes de detección de interbloqueos en un SGBD distribuido: detección de interbloqueos centralizada, jerárquica y distribuida. • Las principales causas de fallo en un entorno distribuido son la pérdida de mensajes, los fallos en los enla- ces de comunicaciones, las detecciones catastróficas de los nodos y el particionamiento de red. Para faci- litar la recuperación, cada nodo mantiene su propio archivo de registro. El registro puede utilizarse para deshacer y rehacer transacciones en caso de fallo. • El protocolo de confirmación en dos fases (2PC) comprende una fase de votación y otra de decisión, mediante las que el coordinador pregunta a todos los participantes si están listos para confirmar la trans- acción. Si uno de los participantes vota por abortada, deberán abortarse tanto la transacción global como cada una de las subtransacciones. Sólo si todos los participantes votan por la confirmación podrá confir- marse la transacción global. El protocolo 2PC puede hacer que algunos nodos queden bloqueados en caso de que se produzcan fallos de nodos. • Un protocolo no bloqueante es la confirmación en tres fases (3PC), que requiere que el coordinador envíe un mensaje adicional entre las fases de votación y decisión a todos los participantes, pidiéndose que pre- confirmen la transacción. • X/Open DTP es una arquitectura de procesamiento de transacciones distribuidas para un protocolo 2PC distribuido, basada en OSI-TP. La arquitectura define una serie de interfaces de programación de aplica- ciones y un conjunto de interacciones entre las aplicaciones transaccionales, los gestores de transacciones, los gestores de recursos y los gestores de comunicaciones. • El procesamiento de consultas distribuidas puede dividirse en cuatro fases: descomposición de la consul- ta, localización de los datos, optimización global y optimización local. La descomposición de la consul-
  • 130. 706 Sistemas de bases de datos ta toma una consulta expresada sobre las relaciones globales y realiza una optimización parcial utilizan- do las técnicas explicadas en el Capítulo 21. La localización de datos toma en consideración cómo se han distribuido los datos y sustituye las relaciones globales de las hojas del árbol de álgebra relacional por sus algoritmos de reconstrucción. La optimización global tiene en cuenta la información estadística para hallar un plan de ejecución cercano al óptimo. La optimización local se realiza en cada nodo implicado en la consulta . • El modelo de costes para la optimización de consultas distribuidas puede basarse en el coste total (como en el caso centralizado) o en el tiempo de respuesta, es decir, el tiempo transcurrido desde el inicio hasta la terminación de la consulta. Este último modelo tiene en cuenta el paralelismo inherente en un sistema distribuido. Los cálculos de coste necesitan tomar en consideración los costes de procesamiento local (E/S y procesador) así como los costes de interconexión por red. En una red WAN, los costes de comunicación por red serán el factor dominante que habrá que reducir . • Cuando el principal componente del coste es el tiempo de comunicación, la operación de semicombina- ción resulta particularmente útil para mejorar el procesamiento de las combinaciones distribuidas, al redu- cir la cantidad de datos que hay que transferir entre unos nodos y otros. Cuestiones de repaso 23.1. En un entorno distribuido, los algoritmo s basados en bloqueo pueden clasificarse como centralizados, de copia principal o distribuidos. Indique las similitudes y diferencias entre estos algoritmos. 23.2. Uno de los métodos más conocidos para la detección de interbloqueos distribuidos fue desarrollado por Obermarck. Explique cómo funciona el método de Obermarck y cómo se detecta y resuelve una situa- ción de interbloqueo. 23.3. Esboce dos topologías alternativas de confirmación en dos fases que puedan considerarse como alter- nativas a la topología centralizada. 23.4. Explique el término 'protocolo no bloqueante' e indique por qué el protocolo de confirmación en dos fases no es un protocolo no bloqueante. 23.5. Explique por qué el protocolo de confirmación en tres fases es un protocolo no bloqueante a menos que fallen todos los nodos. 23.6. Indique los niveles de la optimización de consultas distribuidas y detalle la función de cada nivel. 23.7. Diga cuáles son los costes que hay que tomar en consideración durante la optimización de consultas distribuidas y exponga dos modelos de costes diferentes. 23.8. Describa los algoritmos de optimización de consultas distribuidas usados por R* y SDD-1. 23.9. Describa brevemente la funcionalidad distribuida de Oracle9i. Ejercicios 23.10. El Director Gerente de DreamHome nos pide que investiguemos los requisitos de distribución de datos de la organización y que preparemos un informe del uso potencial de un SGBD distribuido. El infor- me debe comparar la tecnología del SGBD centralizado con la del SGBD distribuido, indicar las ventajas y desventajas de implementar un SGBDD dentro de la organización y señalar las posibles fuentes de problemas. Finalmente, el informe debe contener un conjunto de recomendaciones adecua- damente justificadas que detallen la solución apropiada que se propone. 23.11. Explique en detalle cómo funciona el protocolo de confirmación en dos fases centralizado en un entor- no distribuido. Esboce los algoritmos correspondientes tanto al coordinador como a los participantes. 23.12. Explique en detalle cómo funciona el protocolo de confirmación en tres fases en un entorno distribui- do. Esboce los algoritmos correspondientes tanto al coordinador como a los participantes. 23.13. Analice los SGBD que esté utilizando actualmente y determine qué soporte proporciona cada uno para el modelo DTP de X/Open y para la replicación de datos.
  • 131. Capítulo 23 Basesde datos distribuidas: conceptos avanzados 707 23.14. Considere cinco transacciones TI, T2, T3, T4 YTs tales que: • TI se inicia en el nodo SI y crea un agente en el nodo S2 • T2 se inicia en el nodo S3 y crea un agente en el nodo SI • T3 se inicia en el nodo SI y crea un agente en el nodo S3 • T 4 se inicia en el nodo S2 y crea un agente en el nodo S3 • Ts se inicia en el nodo S3' La información de bloqueo para estas transacciones se muestra en la tabla siguiente. Transacción Elementos de datosElementos de datos por Nodo implicado en os por la los que está esperandolas operacionesla transacciónXI Xg SIx6 x2 S2x4 XI SIXs S3x2 x7 S] x3S3x7 S2x8 Xs S3x3 x7 S3 (a) Construya los grafos de espera locales para cada uno de los nodos. ¿Qué conclusiones puede sacar a partir de los grafos de espera locales? (b) Utilizando las transacciones anteriores, muestre cómo funciona el método de Obermarck para detección de interbloqueos distribuidos. ¿Qué conclusiones puede sacar del grafo de espera global?
  • 132. Replicación y bases de datos móv'iles Objetivos del capítulo: En este capítulo aprenderá: • En qué se diferencia una base de datos replicada de una base de datos distribuida. • Las ventajas de la replicación de bases de datos. • Ejemplos de aplicaciones que utilizan la replicación de la base de datos. • Componentes básicos de un sistema de replicación. • Las diferencias entre la replicación síncrona y la asíncrona. • Los tipos principales de modelos de propiedad de los datos, que son maestro/esclavo, flujo de trabajo y actualización ubicua. • La funcionalidad de un servidor de replicación de bases de datos. • Los principales problemas de implementación asociados con la replicación de bases de datos. • El modo en que la informática móvil soporta a los trabajadores móviles. • La funcionalidad de un SGBD móvil. • Cómo soporta el SGBD de Oracle la replicación de bases de datos. En el capítulo anterior hemos presentado los conceptos y problemas básicos asociados con los sistemas de gestión de bases de datos distribuidas (SGBDD). Desde la perspectiva del usuario, la funcionalidad ofrecida por un SGBDD es muy atractiva. Sin embargo, desde el punto de vista de la implementación, los protocolos y algoritmo s requeridos para proporcionar esta funcionalidad son muy complejos y dan lugar a diversos pro- blemas que pueden hacer que no merezcan la pena las ventajas ofrecidas por esta tecnología. En este capítu- lo se presenta una técnica alternativa, y potencialmente más simple, a la distribución de datos, técnica alter- nativa que se basa en un servidor de replicación que se encarga de replicar los datos en los nodos remotos. Todos los principales fabricantes de bases de datos disponen de una solución de replicación de un tipo u otro y muchos fabricantes no especializados en bases de datos ofrecen métodos alternativos para la replicación de los datos. Posteriormente en el capítulo nos centraremos en una aplicación concreta de la replicación de bases de datos, denominada bases de datos móviles, y veremos cómo presta soporte esta tecnología a los trabajadores móviles. Estructura del capítulo En la Sección 24.1 se presentan los conceptos de replicación de bases de datos y en la Sección 24.2 se exa- minan las ventajas asociadas con esta tecnología. En la Sección 24.3 se identifican las aplicaciones típicas de la replicación de bases de datos. En la Sección 24.4 se exponen algunos de los componentes más importantes de los entorno s de replicación de bases de datos y en la Sección 24.5 se analizan las opciones más relevantes
  • 133. 710 Sistemas de bases de datos para el entorno de replicación, como por ejemplo si utilizar replicación síncrona o asíncrona. En la Sección 24.6 se identifica la funcionalidad requerida del servidor de aplicación y se repasan los principales problemas de implementación asociados con esta tecnología. En la Sección 24.7 analizaremos las bases de datos móvi- les y la funcionalidad que cabe exigir a un SGBD móvil. En la Sección 24.8 se incluye una panorámica del modo en que Oracle9i gestiona la replicación. Los ejemplos en este capítulo están, de nuevo, extraídos del caso de estudio de DreamHome descrito en la Sección 10.4 Y en el Apéndice A. 24.1 Introducción a la replicación de bases de datos La replicación de bases de datos es un mecanismo de gran importancia, porque permite a las organizaciones proporcionar a los usuarios acceso a datos actualizados en todo lugar y en todo momento. Replicación de bases de datos El proceso de copiar y mantener objetos de la base de datos, como por ejemplo relaciones, en múltiples bases de datos que forman un sistema de bases de datos distribuido. Los cambios aplicados en un nodo se capturan y almacenan localmente antes de reenviarlos y aplicarlos a cada una de las ubicaciones remotas. La replicación utiliza tecnología de bases de datos distribuidas para compartir datos entre múltiples sitios, pero no es lo mismo una base de datos replicada y una base de datos distribuida. En una base de datos distribuida, los datos están disponibles en muchas ubicaciones, pero cada relación concreta sólo reside en una ubicación. Por ejemplo, si DreamHome dispusiera de una base de datos distribuida, la relación que describe los inmuebles en alquiler, es decir PropertyForRent, sólo estaría almace- nada en un único servidor de base de datos, como por ejemplo el servidor de Londres, y no en los servido- res de Glasgow o de Edimburgo. Por el contrario, la replicación significa que los mismos datos están dispo- nibles en múltiples ubicaciones. Así, si DreamHome dispusiera de una base de datos replicada, la relación PropertyForRent podría estar disponible en los servidores de base de datos de Londres, Glasgow y Edimburgo. 24.2 Beneficios de la replicación de base de datos La Tabla 24.1 enumera algunos de los beneficios principales asociados con la replicación de bases de datos. E! término disponibilidad hace referencia al modo en que la replicación incrementa la disponibilidad de los datos para los usuarios y aplicaciones, mediante la provisión de opciones alternativas de acceso a los datos. Si uno de los nadas deja de estar disponible, los usuarios pueden continuar consultando o incluso actualizan- do las ubicaciones restantes. Fiabilidad hace referencia al hecho de que, al haber múltiples copias de los datos disponibles en el siste- ma, se dispone de un mecanismo excelente de recuperación en caliente para el caso en el que se produzcan fallos en uno o más nadas. El rendimiento se mejora sobremanera para las transacciones de consulta cuando se introduce la replica- ción en un sistema que estuviera aquejado de una sobrecarga significativa de los recursos centralizados. La Tabla 24.1. Ventajas de la replicación. Disponibilidad Fiabilidad Rendimiento Reducción de la carga Procesamiento desconectado Soporta muchos usuarios Soporta aplicaciones avanzadas
  • 134. Capítulo 24 Replicación y bases de datos móviles 711 replicación proporciona un acceso rápido y local a los datos compartidos, ya que equilibra la actividad entre múltiples nodos. Algunos usuarios pueden acceder a un servidor, mientras que otros usuarios acceden a ser- vidores distintos, manteniendo así los niveles de rendimiento en todos los servidores. El término reducción de la carga hace referencia al modo en el que puede utilizarse la replicación para distribuir los datos entre múltiples ubicaciones remotas. Con ello, los usuarios pueden acceder a varios servi- dores remotos en lugar de acceder a un servidor centralizado. Esta configuración permite así reducir signifi- cativamente el tráfico de red. Asimismo, los usuarios pueden acceder a los datos almacenados en eLnodo de replicación cuyo coste de acceso sea menor, el cual será normalmente el nodo que esté geográficamente más próximo al usuario. Al hablar de procesamiento desconectado nos referimos al modo en el que la replicación puede imple- mentarse mediante el llamado mecanismo de instantáneas. Una instantánea es una copia (réplica) completa o parcial de una relación determinada en un instante temporal concreto. Las instantáneas permiten que los usuarios trabajen sobre un subconjunto de la base de datos corporativa mientras están desconectados del ser- vidor de base de datos principal. Posteriormente, al restablecer una conexión, los usuarios pueden sincronizar (refrescar) las instantáneas en la base de datos corporativa según sea necesario. Esto puede implicar que la instantánea reciba actualizaciones de la base de datos corporativa o que la base de datos corporativa reciba actualizaciones de la instantánea. Independientemente de cuál sea la acción que se lleve a cabo, los datos de la instantánea y de la base de datos corporativa volverán a ser coherentes. Cuando afirmamos que la replicación soporta a muchos usuarios estamos haciendo referencia a que las organizaciones necesitan implantar cada día más aplicaciones que requieren la posibilidad de utilizar y mani- pular datos. La replicación puede crear múltiples instantáneas personalizadas que satisfagan los requisitos de cada usuario o grupo de usuarios del sistema. Finalmente, decir que la replicación soporta aplicaciones avanzadas está relacionado con el modo en que las organizaciones necesitan cada vez más hacer que los datos corporativos estén disponibles no sólo para los sistemas tradicionales OLTP (Online Transaction Processing, procesamiento de transacciones en línea) sino también para aplicaciones avanzadas de análisis de los datos, como los almacenes de datos OLAP (Online Analytical Processing, procesamiento analítico en línea) y la minería de datos (véanse los Capítulos 31 a 34). Además, gracias a la replicación, los datos corporativos también pueden utilizarse para soportar la cada vez más popular tendencia de la informática móvil (véase la Sección 24.7). Por supuesto, un sistema de base de datos replicado que proporcione los beneficios indicados en la Tabla 24.1 será más complejo que un sistema de base de datos centralizado. Por ejemplo, las prestaciones pueden verse significativamente reducidas para las transacciones de actualización, porque será necesario realizar una misma actualización lógica en cada copia de la base de datos, con el fin de mantener la coherencia de las copias. Asimismo, las técnicas de control de concurrencia y de recuperación son más complejas y más caras, si las comparamos con un sistema donde no exista replicación. 24.3 Aplicaciones de la replicación La replicación permite soportar diversas aplicaciones con requisitos muy distintos. Algunas aplicaciones no necesitan más que una sincronización limitada entre las distintas copias de la base de datos y el sistema de base de datos corporativo, mientras que otras aplicaciones exigen una sincronización continua entre todas las copias de la base de datos. Por ejemplo, el soporte para un equipo de ventas remoto requiere normalmente la sincronización periódi- ca de un gran número de pequeños nadas móviles remotos con el sistema de base de datos corporativo. Además, dichos nadas son a menudo autónomos, estando desconectados de la base de datos corporativa durante periodos de tiempo relativamente largos. A pesar de esto, los miembros del equipo de ventas deben poder completar una venta, independientemente de si están conectados a la base de datos corporativa o no. En otras palabras, los nadas remotos deben poder soportar todas las transacciones necesarias asociadas con una venta. En este ejemplo, la autonomía de un nodo se considera más importante que garantizar la coherencia de los datos. Por otro lado, las aplicaciones financieras que implican la gestión de acciones bursátiles requieren que los datos de los múltiples servidores se sincronicen de manera continua y prácticamente instantánea, para garan-
  • 135. 712 Sistemas de bases de datos tizar que el servicio proporcionado esté disponible y sea homogéneo en todo momento. Por ejemplo, los sitios web que muestran los precios de las acciones deben garantizar que los clientes vean la misma información en cada sitio. En este ejemplo, la coherencia de los datos es más importante que la autonomía de los nodos. En la Sección 24.5.2 se proporcionan más ejemplos de aplicaciones que requieren la replicación. Asimismo, en este capítulo nos centraremos en una aplicación concreta de la replicación, denominada base de datos móviles, y explicaremos en la Sección 24.7 cómo soporta esta tecnología a los trabajadores móviles. 24.4 Componentes básicos de la replicación de bases de datos Esta sección describe con más detalle algunos de los componentes básicos del entorno de replicación de bases de datos, incluyendo los objetos de replicación, los grupos de replicación y los sitios de replicación. Un objeto de replicación es un objeto de base de datos tal como una relación, un índice, una vista, un pro- cedimiento o una función que existe en múltiples servidores en un sistema de base de datos distribuido. En un entorno de replicación, cualesquiera actualizaciones realizadas en un objeto de replicación en un sitio o nodo se aplican a las copias de todos los demás sitios. En un entorno de replicación, los objetos de replicación se gestionan mediante los denominados grupos de replicación. Un grupo de replicación es una colección de objetos de replicación que están lógicamente rela- cionados. La organización de los objetos relacionados de la base de datos en un grupo de replicación facilita la administración de dichos objetos. Cada grupo de replicación puede existir en múltiples sitios de replicación. Los entorno s de replicación soportan dos tipos básicos de sitios: sitios maestros y sitios esclavos. Un grupo de replicación puede estar asociado con uno o más sitios maestros y con uno o más sitios esclavos. Un sitio concreto puede ser tanto un sitio maestro para un grupo de replicación como un sitio esclavo para otro sitio de replicación distinto. Sin embargo, un mismo sitio no puede ser a la vez el sitio maestro y el sitio esclavo para el mismo grupo de repli- cación. Un sitio maestro controla un grupo de replicación y los objetos pertenecientes a dicho grupo. Esto se con- sigue manteniendo una copia completa de todos los objetos del grupo de replicación y propagando los cam- bios realizados en el grupo a todas las demás copias almacenadas en los sitios esclavos. Un sitio esclavo puede contener todos los objetos de un grupo de replicación o sólo un subconjunto de los mismos. Sin embargo, los sitios esclavos únicamente contienen una instantánea del grupo de replicación, como por ejemplo los datos contenidos en una relación en un instante concreto de tiempo. Normalmente, los sitios de instantáneas se refrescan periódicamente para sincronizarlos con su sitio maestro. Para un entorno de replicación con múlti- ples sitios maestros, todos esos sitios se comunican directamente entre sí para propagar continuamente los cambios realizados en el grupo de replicación. En la siguiente sección vamos a analizar los tipos de problemas asociados con el mantenimiento de la coherencia entre los sitios maestros y los sitios esclavos. 24.5 Entornos de replicación de bases de datos En esta sección se analizan características importantes de los entorno s de replicación de bases de datos, como por ejemplo si la replicación de los datos se mantiene utilizando mecanismos síncronos o asíncronos o si uno o más sitios tienen la propiedad de una copia maestra de los datos replicados. 24.5.1 Replicación síncrona y asíncrona En el capítulo anterior hemos examinado los protocolos para actualización de datos replicados, protocolos que funcionaban sobre la base de que todas las actualizaciones se llevaran a cabo como parte de la transacción que las engloba. En otras palabras, los datos replicados se actualizan inmediatamente en el momento de actuali- zar los datos de origen. Normalmente, utilizando el protocolo 2PC (confirmación en dos fases) analizada en
  • 136. Capítulo 24 Replicación y bases de datos móviles 713 la Sección 23.4.3. Este tipo de replicación se denomina replicación sÍncrona. Aunque este mecanismo puede resultar apropiado para los entorno s que deban por necesidad mantener todas las réplicas completamente sin- cronizadas (como por ejemplo para las aplicaciones financieras, también tiene diversas desventajas). Por ejemplo, la transacción no podrá completarse si uno o más de los nodos que almacenan las réplicas no están disponibles. Además, el número de mensajes requeridos para coordinar la sincronización de los datos impo- ne una carga significativa a las redes corporativas. Un mecanismo alternativo a la replicación síncrona es la denominada replicación aSÍncrona. Con este mecanismo, la base de datos de destino se actualiza después de que la base de datos de origen haya sido modi- ficada. El retardo que se experimenta antes de volver a restaurar la coherencia puede ir desde unos pocos segundos a varias horas o incluso días. Sin embargo, los datos terminarán por sincronizarse y adoptar el mismo valor en todos los sitios. Aunque esto viola el principio de la independencia de los datos distribuidos, parece ser un compromiso práctico entre la integridad y la disponibilidad de los datos, compromiso que puede resultar más apropiado para aquellas organizaciones que puedan trabajar con réplicas que no necesariamente tengan que estar siempre sincronizadas y actualizadas. 24.5.2 Propiedad de los datos El término propiedad hace referencia a cuál es el sitio que tiene el privilegio de poder actualizar los datos. Los tipos principales de propiedad son maestro/esclavo, flujo de trabajo y actualización ubicua (algunas veces denominada replicación igualitaria o replicación simétrica). Propiedad maestro/esclavo Con la propiedad maestro/esclavo, los datos asíncronamente replicados son propiedad de un sitio, el sitio maestro (o principal) y sólo pueden ser actualizados por dicho sitio. Utilizando una metáfora de publicación y subscripción, el sitio maestro (el publicador) hace que los datos estén disponibles en los sitios esclavos (los subscriptores). Los sitios esclavos se 'subscriben' a los datos propiedad del sitio maestro, lo que significa que reciben copias de sólo lectura en sus sistemas locales. Potencialmente, cada sitio puede ser el maestro de una serie de conjuntos de datos no solapados. Sin embargo, sólo puede existir un único sitio que actuali- ce la copia maestra de un conjunto de datos concreto, por lo cual no pueden aparecer conflictos de actuali- zación entre los distintos sitios. He aquí algunos ejemplos que muestran los usos potenciales de este tipo de replicación: • Análisis para sistemas de soporte a la toma de decisiones (DSS, decision support system). Los datos de una o más bases de datos distribuidas pueden descargarse a un DSS local separado para análisis de sólo lectura. En el caso de DreamHome podríamos recopilar toda la información de ventas y alquile- res de inmuebles, junto con los detalles de los clientes, y realizar análisis para determinar tendencias, como por ejemplo qué tipo de persona es más probable que compre o alquile un inmueble de un rango de precios o de una zona geográfica concretos. Hablaremos de las tecnologías que requieren este tipo de replicación de datos para el análisis de los datos, incluyendo OLAP (Online Analytical Processing) y la minoría de datos, en los Capítulos 33 y 34. • Distribución y diseminación de iriformación centralizada. La diseminación de los datos describe un entorno en el que los datos se actualizan en una ubicación central y luego se replican a sitios de sólo lectura. Por ejemplo, la información de producto tal como las listas de precios puede mantenerse en el sitio correspondiente a la serie corporativa y replicarse mediante copias de sólo lectura que se almace- nen en las sucursales remotas. Este tipo de replicación se muestra en la Figura 24.1(a). • Consolidación de la información remota. La consolidación de datos describe un entorno en el que los datos pueden actualizarse localmente y luego combinarse en un repositorio de sólo lectura situado en una determinada ubicación. Este método permite que la propiedad de los datos resida en cada sitio y que los distintos sitios sean autónomos. Por ejemplo, los detalles de los inmuebles que se mantienen en cada sucursal podrían replicarse a una copia de sólo lectura consolidada residente en la sede corpo- rativa. Este tipo de replicación se muestra en la Figura 24.1 (b).
  • 137. 714 Sistemas de bases de datos Sitio esclavo (sólo lectura) Sitio esclavo (sólo lectura) (a) Sitio maestro (lectura/escritura) (b) Sitio maestro (lectura/escritura) Sitio esclavo (sólo lectura) Sitio esclavo (sólo lectura) o oSitio maestro (lectura/escritura) Figura 24.1. Propiedad maestro/esclavo: (a) diseminación de los datos; (b) consolidación de los datos . • Informática móvil. La informática móvil ha pasado a ser mucho más accesible en los últimos años y en la mayoría de las organizaciones hay personas que trabajan fuera de la oficina. Hoy en día existen
  • 138. Capítulo 24 Replicación y bases de datos móviles 715 distintos métodos para proporcionar datos a una fuerza de trabajo móvil, uno de los cuales es la repli- cación. En este caso, los datos se descargan a voluntad desde un servidor local del grupo de trabajo. Las actualizaciones realizadas por el cliente móvil en los datos del grupo de trabajo o en los datos cen- tralizados, como por ejemplo la información de nuevos clientes o pedidos, se gestionan de forma simi- lar. Más adelante en el capítulo hablaremos con mayor detalle de esta aplicación de la replicación de datos (véase la Sección 24.7). Un sitio maestro puede ser el propietario de todos los datos de una relación, en cuyo caso los demás sitios se subscribirán a copias de sólo lectura de dicha relación. Alternativamente, puede que haya múlti- ples sitios que sean propietarios de distintos fragmentos de la relación, y los demás sitios se subscribirán entonces a copias de sólo lectura de dichos fragmentos. Este tipo de replicación se conoce también con el nombre de replicación asimétrica. Para DreamHome, podría implementarse un SGBD distribuido para permitir que cada sucursal fuera la propietaria de diferentes particiones horizontales de las relaciones PropertyForRent, Client y Lease. El sitio correspondiente a la sede central podría subscribirse a los datos propiedades de cada sucursal, con el fin de mantener una copia consolidada de sólo lectura de todos los inmuebles, clientes y contratos de alquiler de toda la organización. Propiedad tipo flujo de trabajo Al igual que la propiedad maestro/esclavo, el modelo de propiedad tipo flujo de trabajo impide los conflictos de actualización, proporcionando al mismo tiempo un modelo de propiedad más dinámico. La propiedad tipo flujo de trabajo permite que el derecho de actualizar los datos replicados se vaya transfiriendo de un sitio a otro. Sin embargo, en cada momento concreto, sólo hay un único sitio que pueda actualizar ese conjunto de datos concreto. Un ejemplo típico de propiedad tipo flujo de trabajo sería un sistema de procesamiento de pedidos, en el que el procesamiento de los pedidos sigue una serie de pasos, como introducción del pedido, aprobación del crédito, facturación, envío, etc. En un SGBD centralizado, las aplicaciones de esta naturaleza acceden y actualizan los datos en una base de datos integrada: cada aplicación actualiza los datos de los pedidos en secuencia, únicamente cuando el esta- do del pedido indique que el paso anterior ya ha sido completado. Con un modelo de propiedad de tipo flujo de trabajo, las aplicaciones pueden distribuirse entre los distintos sitios y cuando los datos se repliquen y se reenvíen al siguiente sitio de la cadena, el derecho de actualizarlos también se transferirá, como se ilustra en la Figura 24.2. Propiedad de tipo actualización ubicua (replicación simétrica) Los dos modelos anteriores comparten una propiedad común: en cada momento determinado, sólo uno de los sitios puede actualizar los datos; todos los demás sitios dispondrán de acceso de sólo lectura a las réplicas. En ISucursal I I Sede central -1 (facturación) -Relación BillingleaseNostatus ownerNoleaseNostatusLN34Facturable C087LN34FacturadoLN76Facturable C040LN76Facturado ... Figura 24.2. Propiedad tipo flujo de trabajo.
  • 139. 716 Sistemas de bases de datos algunos entornas, esto es demasiado restrictivo. El modelo de actualización ubicua crea un entorno igualita- rio en el que los múltiples nadas disponen de iguales derechos para actualizar los datos replicados. Esto permite que los sitios locales funcionen autónomamente incluso en el caso de que otros sitios no estén dispo- nibles. Por ejemplo, DreamHome puede decidir poner en marcha una línea de atención a los clientes que permi- ta a los clientes potenciales telefonear a un número gratuito para indicar su interés en una cierta zona o en un cierto inmueble, para concertar una visita o, básicamente, para hacer cualquier otra cosa que pudieran llevar a cabo visitando una sucursal. Suponga que la empresa establece centros de llamada en cada sucursal. Las lla- madas serán encaminadas a la sucursal más cercana; por ejemplo, alguien interesado en los inmuebles de Londres y que esté telefoneando desde Glasgow será encaminado a una oficina de Glasgow. El sistema de telecomunicaciones intentará equilibrar la carga y, si Glasgow está particularmente ocupada, puede reenviar las llamadas a Edimburgo. Cada centro de llamadas tiene que poder acceder a los datos, y actualizados, situa- dos en cualquiera de las otras sucursales y hacer que las tuplas actualizadas se repliquen en los restantes sitios, como se ilustra en la Figura 24.3 La propiedad compartida puede conducir a escenarios de conflicto y la arquitectura de replicación tiene que poder emplear una metodología de detección y resolución de conflictos. Volveremos a este problema en la sección siguiente. 24.6 Servidores de replicación Hasta la fecha, los sistemas de gestión de bases de datos distribuidas (SGBDD) de propósito general no han tenido una amplia aceptación. Esta falta de actividad comercial se produce a pesar de que muchos de los pro- tocolos y problemas asociados con la gestión de una base de datos distribuida se comprenden bastante bien (véase la Sección 22.1.2). Es la replicación de datos, es decir, la copia y mantenimiento de datos en múltiples servidores, la que parece ser la solución preferida. Todos los principales fabricantes de bases de datos, como Microsoft Office Access y Oracle proporcionan una solución de replicación de un tipo u otro y muchos fabri- cantes no especializados en bases de datos también ofrecen métodos alternativos para replicar los datos. El servidor de replicación es una técnica alternativa y potencialmente más simple para la distribución de datos. En esta sección, vamos a examinar la funcionalidad que cabe esperar de un servidor de replicación y luego hablaremos de algunos de los problemas de implementación asociados con esta tecnología. Glasgow (lectura/escritura) Londres (lectura/escritura) Aberdeen (1ectu ra/ escritu ra) Edimburgo (Iectu ra/ escritu ra) Figura 24.3. Propiedad de tipo actualización ubicua (igualitaria).
  • 140. Capítulo 24 Replicación y bases de datos móviles 717 24.6.1 Funcionalidad del servidor de replicación En su nivel básico, esperamos que un servicio de replicación de datos distribuido sea capaz de copiar los datos de una base de datos a otra, síncrona o asíncronamente. Sin embargo, hay muchas otras funciones que hay que proporcionar, como por ejemplo (Buretta, 1997): • Escalabilidad. El servicio debe ser capaz de gestionar la replicación tanto de pequeños como de gran- des volúmenes de datos. • Mapeado y transformación. El servicio debe ser capaz de gestionar la replicación entre diversos SGBD y plataformas heterogéneos. Como hemos indicado en la Sección 22.1.3, esto puede implicar el ma- peado y la transformación de los datos de un modelo de datos a otro distinto, o de un tipo de datos a otro tipo de datos correspondiente en otro SGBD. • Replicación de objetos. Debe ser posible replicar objetos, además de los datos. Por ejemplo, algunos sistemas permiten replicar los índices y los procedimientos almacenados (o disparadores). • Especificación del esquema de replicación. El sistema debe proporcionar un mecanismo para permitir que un usuario privilegiado especifique los datos y los objetos que hay que replicar. • Mecanismo de subscripción. El sistema debe proporcionar un mecanismo que permita a un usuario pri- vilegiado subscribirse a los datos y objetos disponibles para replicación. • Mecanismo de inicialización. El sistema debe proporcionar un mecanismo que permita la inicializa- ción de una réplica de destino. • Fácil administración. Debe ser sencillo para el DBA administrar el sistema y comprobar el estado y monitorizar el rendimiento de los componentes del sistema de replicación. 24.6.2 Problemas de implementación En esta sección vamos a examinar algunos problemas de implementación asociados con la provisión de repli- cación de datos por parte del servidor de replicación, incluyendo: • actualizaciones transaccionales; • instantáneas y disparadores de la base de datos; • detección y resolución de conflictos. Actualizaciones transaccionales Una técnica utilizada al principio por algunas organizaciones para proporcionar un mecanismo de replicación era descargar los datos apropiados en un soporte de copia de seguridad (por ejemplo, cinta) y luego enviar dicho soporte por mensajero a un segundo sitio, donde se lo cargaba en otro sistema informático. El segundo sitio tomaba entonces decisiones basándose en estos datos, que podían tener varios días de antigiledad. Las principales desventajas de esta técnica son que las copias pueden no estar actualizadas y que se requiere una intervención manual. Otros intentos posteriores para proporcionar un mecanismo de replicación automático eran no transaccio- nales por naturaleza. Los datos se copiaban sin mantener la atomicidad de la transacción, perdiéndose así potencialmente la integridad de los datos distribuidos. Esta técnica se ilustra en la Figura 24.4(a), que mues- tra una transacción consistente en múltiples operaciones de actualización de diferentes relaciones en el sitio de origen, las cuales se transformarán durante el proceso de replicación en una serie de transacciones inde- pendientes, cada una de las cuales es responsable de actualizar una relación concreta. Si algunas de las trans- acciones en el sitio de destino tienen éxito mientras que las otras fallan, la coherencia entre las bases de datos de origen y de destino se habrá perdido. Por contraste, la Figura 24.4(b) ilustra un mecanismo de replicación de tipo transaccional, en el que la estructura de la transacción original en la base de datos de origen también se mantiene en el sitio de destino.
  • 141. 718 Sistemas de bases de datos Base de datos de origen Base de datos de destino Transaction Integridad transaccionalate Relation A Transaction Update Relation A commit; violada Transaction Update Relation B commit;Transaction Update Relation e commit;Transaction Update Relation o commit; (a) Transaction TransactionIntegridad transaccional Update Relation A conservada Update Relation B Update Relation eUpdate Relation oCommit (b) Figura 24.4. (a) Actualizaciones de replicación no transaccionales; (b) actualizaciones de replicación transaccionales. Instantáneas y disparadores de la base de datos En esta sección, vamos a examinar cómo pueden utilizarse las instantáneas para proporcionar un mecanismo de replicación transaccional. También compararemos este método con otro mecanismo que utiliza disparado- res de base de datos. Instantáneas Las instantáneas permiten la distribución asíncrona de cambios realizados en relaciones individuales, colec- ciones de relaciones, vistas o fragmentos de relaciones, de acuerdo con una planificación predefinida, por ejemplo una vez por día a las 23:00. Veamos un caso: podemos almacenar la relación Staffen un sitio (el sitio maestro) y crear una instantánea que contenga una copia completa de la relación Staff en cada sucursal. Alternativamente, podríamos crear una instantánea de la relación Staffpara cada sucursal que contuviera úni- camente los detalles de los empleados que trabajan en dicha sucursal concreta. Proporcionaremos un ejemplo de cómo crear instantáneas en OracIe en la Sección 24.8. Una técnica común para gestionar las instantáneas utiliza el archivo de registro de recuperación de la base de datos, imponiendo así una mínima carga adicional al sistema. La idea básica es que el archivo de registro es la mejor fuente para capturar los cambios realizados en los datos de origen. De esa forma, puede crearse un mecanismo que utilice el archivo de registro para detectar las modificaciones en los datos de origen y pro- paguen los cambios a las bases de datos de destino, sin interferir con las operaciones normales del sistema de origen. Los distintos productos de bases de datos difieren en el modo de integrar este mecanismo con el SGBD. En algunos casos, el proceso es parte del propio servidor SGBD, mientras que en otros se ejecuta como un servidor externo independiente. También es necesario un proceso de gestión de colas para enviar las actualizaciones a los demás sitios. En caso de fallo de la red o de un sitio, la cola puede almacenar las actualizaciones hasta que se restaure la cone- xión. Para garantizar la integridad, el orden de las actualizaciones debe mantenerse durante la entrega. Disparadores de la base de datos Otra técnica alternativa permite a los usuarios construir sus propias aplicaciones de replicación utilizando dis- paradores de la base de datos. Con este método, es responsabilidad del usuario crear el código dentro de un disparador que se ejecute cada vez que tenga lugar el suceso apropiado, como por ejemplo cada vez que se
  • 142. Capítulo 24 Replicación y bases de datos móviles 719 cree una nueva tupla o cada vez que se actualice una tupla ya existente. Por ejemplo, en Oracle podemos uti- lizar el siguiente disparador para mantener una copia duplicada de la relación Staffen otro sitio, determinado por el enlace de base de datos denominado RENTALS.GLASGOW.NORTH.COM (véase la Sección 23.9): CREATE TRIGGER StaffAfterlnsRow BEFORE INSERT ON Staff FOREACHROW BEGIN INSERT INTO StaffDuplicate@RENTALS.GLASGOW.NORTH.COM VALUES (:new.staffNo,:new:fName,:new:IName,:new.position.:new:sex, :new.DOB,:new:salary,:new:branchNo); END; Este disparador será invocado para cada tupla que se inserte en la copia principal de la relación Staff. Aunque ofrece más flexibilidad que las instantáneas, esta técnica tiene las siguientes desventajas: • La gestión y ejecución de los disparadores consume recursos adicionales, reduciendo las prestaciones. • Los disparadores transfieren los elementos de datos cuando son modificados, pero no tienen ningún conocimiento sobre la naturaleza transaccional de las modificaciones. • Los disparadores se ejecutan cada vez que cambia una tupla en la relación maestra. Si la relación maes- tra se actualiza frecuentemente, esto puede imponer una sobrecarga significativa a la aplicación y a la red. Por contraste, las instantáneas recopilan todas las actualizaciones en una única transacción. • Los disparadores no pueden planificarse; se ejecutan cada vez que tiene lugar una actualización de la relación maestra. Las instantáneas, por el contrario, pueden planificarse o ejecutarse manualmente. Sin embargo, ambos métodos deben evitar que se produzca una gran carga de transacciones de replicación durante los picos de utilización del sistema. • Si se están replicando múltiples tablas relacionadas, la sincronización de las replicaciones puede lle- varse a cabo utilizando mecanismos tales como los grupos de refresco. Tratar de hacer esto con los dis- paradores es mucho más' complejo. • La activación de los disparadores no puede deshacerse fácilmente en caso de que haya que abortar o anular una transacción. Detección y resolución de conflictos Cuando se permite a múltiples sitios actualizar los datos replicados, debe emplearse un mecanismo para detec- tar las actualizaciones conflictivas y restaurar la coherencia de los datos. Un mecanismo simple para detectar los conflictos dentro de una única relación consiste en que el sitio de origen envíe tanto los valores antiguos como los nuevos (imagen anterior e imagen posterior) de las tuplas que hayan sido actualizadas desde la últi- ma operación de refresco. En el sitio de destino, el servidor de replicación puede comprobar cada tupla de la base de datos de destino que haya sido también actualizada y comparada con esos valores. Sin embargo, es necesario tener también en cuenta otros posibles tipos de conflictos que habrá que detectar, como la violación de la integridad referencial entre dos relaciones. Se han propuesto muchos mecanismos para la resolución de conflictos, pero algunos de los más comunes son los siguientes: • Marcas temporales inferiores y superiores. Se aplica la actualización correspondiente a los datos que tengan la marca temporal inferior (más antigua) o superior (más moderna). • Prioridad de los sitios. Se aplica la actualización del sitio que tenga la mayor prioridad. • Actualizaciones aditivas y promediadas. Se aplican conmutativamente las actualizaciones. Este tipo de resolución de conflictos puede utilizarse cuando los cambios efectuados en un atributo sean de natura- leza aditiva, como por ejemplo salary = salary + x
  • 143. Base de datos móvil 720 Sistemas de bases de datos • Valores mínimo y máximo. Se aplican las actualizaciones correspondientes a un atributo con el valor mínimo o máximo. • Definida por el usuario. Se permite al DBA especificar un procedimiento definido por el usuario para resolver el conflicto. Pueden existir diferentes procedimientos para distintos tipos de conflicto. • Guardar para resolución manual. Se almacena el conflicto en un registro de errores para que el DBA lo revise en un instante posterior y lo resuelva de forma manual. Algunos sistemas también resuelven los conflictos resultantes del uso distribuido de restricciones de clave primaria o unívoca; por ejemplo: • Agregar el nombre de sitio al valor duplicado Se añade el nombre global de base de datos del sitio origen de la actualización al valor del atributo replicado. • Añadir un número de secuencia al valor duplicado Se añade un número de secuencia al valor del atri- buto. • Descartar el valor duplicado Se descarta el registro del sitio de origen que provoca los errores. Claramente, si la resolución de conflictos se basa en marcas temporales, resulta vital que las marcas tem- porales de los distintos sitios que participan en la replicación incluyan un elemento indicativo de la zona hora- ria o que todos los sitios empleen la misma zona horaria. Por ejemplo, los servidores de bases de datos pue- den utilizar la hora GMT (Greenwich Mean Time) o alguna otra zona horaria preacordada, preferiblemente una donde no se produzcan cambios debido a la entrada en vigor del horario de verano. 24.7 Introducción a las bases de datos móviles Estamos asistiendo actualmente a un incremento de la demanda de informática móvil, para proporcionar el tipo de soporte requerido por un número cada vez mayor de trabajadores móviles. Dichas personas necesitan trabajar como si estuvieran en la oficina, pero en realidad están haciendo su labor en ubicaciones remotas, como sus casas, las instalaciones del cliente o simplemente mientras están de viaje hacia una ubicación remo- ta. La 'oficina' puede acompañar al trabajador remoto, en forma de una computadora portátil, un PDA (per- sonal digital assistant, asistente digital person<ll) o algún otro dispositivo de acceso a Internet. Con la rápida expansión de las comunicaciones celulares, inalámbricas y vía satélite, pronto será posible que los usuarios móviles accedan a cualquier dato, desde cualquier lugar y en cualquier momento. Sin embargo, las normas empresariales, los aspectos prácticos, las cuestiones de seguridad y el coste pueden seguir limitando las capa- cidades de comunicación, de forma que no sea posible establecer conexiones en línea durante todo el tiempo que los usuarios desearian y desde cualquier lugar. Las bases de datos móviles ofrecen una solución para algu- nas de estas restricciones. Una base de datos que es portable y físicamente independiente del servidor corpo- rativo de base de datos, pero es capaz de comunicarse con ese servidor desde sitios remotos, permitiendo la compartición de datos corporativos. Con las bases de datos móviles, los usuarios tienen acceso a datos corporativos desde su computadora por- tátil, PDA o algún otro dispositivo de acceso a Internet que las aplicaciones requieran utilizar en los sitios remotos. En la Figura 24.5 se muestra la arquitectura típica de un entorno de base de datos móvil. Los com- ponentes de un entorno de base de datos móvil incluyen: • servidor de base de datos corporativo y SGBD que gestiona y almacena los datos corporativos y pro- porciona aplicaciones corporativas; • base de datos remota y SGBD que gestiona y almacena los datos móviles y gestiona los datos móvi- les; • plataforma de base de datos móvil, que puede ser una computadora portátil, un PDA u otro disposi- tivo de acceso a Internet; • enlaces de comunicación bidireccionales entre el SGBD corporativo y el SGBD móvil.
  • 144. Capítulo 24 Replicación y bases de datos móviles 721 tUsuario final Plataforma de Usuario final base de datos móvil Plataforma de base de datos móvilBase de datos móvil Base de datos móvil Aplicaciones de base de datos móvil Enlace de comunicaciones Base de datos corporativa Servidor de datos corporativo Aplicaciones de base de datos móvil Figura 24.5. Arquitectura típica para un entorno de base de datos móvil. Dependiendo de los requisitos concretos de las aplicaciones móviles, en algunos casos el usuario de un dispositivo móvil puede conectarse a un servidor de base de datos corporativo y trabajar allí con los datos, mientras que en otros el usuario puede descargar los datos y trabajar con ellos en un dispositivo móvil o car- gar en la base de datos corporativa los datos capturados en el sitio remoto. La comunicación entre las bases de datos corporativa y móvil es usualmente intermitente y suele estable- cerse durante periodos cortos de tiempo a intervalos irregulares. Aunque no resulta muy común, hay algunas aplicaciones que requieren una comunicación directa entre las bases de datos móviles. Los dos problemas principales asociados con las bases de datos móviles son la gestión de las bases de datos móvil y la comuni- cación entre las bases de datos móvil y corporativa. En la siguiente sección se identifican los requisitos de los SGBD móviles. 24.7.1 Sistemas SGBD móviles Todos los principales fabricantes de sistemas SGBD ofrecen ahora un SGBD móvil. De hecho, este desarro- llo es en parte responsable del increíble crecimiento actual de ventas experimentado por los principales fabri- cantes de sistemas SGBD. La mayoría de los fabricantes promocionan sus SGBD móviles como capaces de comunicarse con muchos de los principales SGBD relacionales y capaces también de proporcionar servicios de base de datos que requieran recursos de procesamiento s limitados, para adaptarse a los recursos que actual- mente proporcionan los dispositivos móviles. La funcionalidad adicional requerida de los SGBD móviles incluye la capacidad de: • comunicarse con el servidor centralizado de base de datos utilizando técnicas tales como la comunica- ción inalámbrica o el acceso a Internet; • replicar los datos en el servidor de base de datos centralizado y en el dispositivo móvil; • sincronizar los datos del servidor de base de datos centralizado y del dispositivo móvil; • capturar datos de varias fuentes, como por ejemplo, de Internet; • gestionar los datos en el dispositivo móvil; • analizar los datos almacenados en un dispositivo móvil;
  • 145. 722 Sistemas de bases de datos • crear aplicaciones móviles personalizadas. Los fabricantes de sistemas SOBD están bajando los precios por usuario a tales niveles que ahora resulta atractivo para las organizaciones ampliar las aplicaciones a los dispositivos móviles, mientras que antes las aplicaciones sólo estaban disponibles dentro de la oficina. Actualmente, la mayoría de los SOBD móviles sólo proporcionan funciones SQL pre-empaquetadas para la aplicación móvil, en lugar de soportar mecanismos amplios de consulta de la base de datos o de análisis de los datos. Sin embargo, la previsión es que a corto plazo los dispositivos móviles ofrezcan funcionalidad que sea cuando menos tan amplia como la actualmen- te disponible en la sede corporativa. 24.8 Replicación en Oracle Para completar este capítulo, vamos a examinar la funcionalidad de replicación de Oracle9i (Oracle Corpora- tion, 2004e). En esta sección, utilizaremos la terminología de este SOBD concreto; Oracle hace referencia a las relaciones con el término tablas, estando las tablas compuestas por columnas yfilas. Hemos proporciona- do una introducción al SOBD Oracle en la Sección 8.2. 24.8.1 Funcionalidad de replicación de Oracle Además de proporcionar una capacidad de SOBD distribuido, Oracle también proporciona Oracle Advanced Replication para soportar tanto la replicación síncrona como la asíncrona. La replicación en Oracle permite replicar tanto las tablas como los objetos de soporte, como por ejemplo vistas, disparadores, paquetes, índi- ces y sinónimos. En la edición estándar de Oracle, sólo puede haber un sitio maestro que replique los cam- bios a los sitios esclavos. En la edición empresarial, puede haber múltiples sitios maestros y las actualizacio- nes pueden tener lugar en cualquiera de esos sitios. En esta sección, vamos a analizar brevemente el mecanismo de replicación de Oracle. Comenzaremos definiendo los tipos de replicación que Oracle soporta. Tipos de replicación Oracle soporta cuatro tipos de replicación: • Instantáneas de sólo lectura. Algunas veces se las denomina vistas materializadas. Con este mecanis- mo, se copia una tabla maestra a una o más bases de datos remotas. Los cambios en la tabla maestra se reflejan en las tablas instantáneas siempre que la instantánea se refresca, a voluntad del sitio donde la instantánea reside. • Instantáneas actualizables. Es un mecanismos similar al de las instantáneas de sólo lectura, pero difie- re en que los sitios que almacenan las instantáneas pueden verificar los datos y enviar los cambios al sitio maestro. De nuevo, quien determina la frecuencia de las operaciones de refresco es el sitio que almacena la instantánea. También determina la frecuencia con la que se envían las actualizaciones al sitio maestro. • Replicación multimaestro. Una tabla se copia en una o más bases de datos remotas, pudiendo la tabla ser actualizada. Las modificaciones son enviadas a las otras bases de datos a intervalos que puede con- figurar el DBA para cada grupo de replicación. • Replicación procedimental. Una llamada a una función o procedimiento empaquetado se replica a una o más bases de datos. Analicemos ahora con más detalles estos tipos de replicación. Grupos de replicación Para simplificar la administración, Oracle gestiona los objetos de replicación utilizando grupos de replica- ción. Nonnalmente, los grupos de replicación se crean para organizar los objetos del esquema requeridos por una aplicación concreta. Los objetos de un grupo de replicación pueden provenir de diversos esquemas y un esquema puede contener objetos de diferentes grupos de replicación. Sin embargo, cada objeto de replicación sólo puede ser miembro de un único grupo.
  • 146. Capítulo 24 Replicación y bases de datos móviles 723 Sitios de replicación Un entorno de replicación Orac1e puede tener dos tipos de sitio: • Sitio maestro. Mantiene una copia completa de todos los objetos de un grupo de replicación. Todos los sitios maestros de un entorno de replicación multimaestro se comunican directamente entre sí para pro- pagar las actualizaciones de los datos correspondientes a un grupo de replicación (que en un entorno de replicación multimaestro se denomina grupo maestro). Cada grupo maestro correspondiente de cada sitio debe contener el mismo conjunto de objetos de replicación, basado en un único sitio de definición maestro. • Sitio de instantánea. Soporta instantáneas de sólo lectura e instantáneas actualizables de los datos de las tablas almacenadas en un sitio maestro asociado. Mientras que en la replicación multimaestro las tablas son actualizadas de manera continua por otros sitios maestros, las instantáneas se actualizan a partir de una o más tablas maestras mediante lotes de actualización individuales, conocidos con el nombre de refrescos, a partir de un único sitio maestro. Los grupos de replicación almacenados en un sitio de instantáneas se denominan grupos de instantáneas. Grupos de refresco Si es necesario refrescar dos o más instantáneas al mismo tiempo, por ejemplo para preservar la integridad entre tablas, Orac1e permite definir grupos de refresco. Después de refrescar todas las instantáneas, los datos de todas las instantáneas del grupo se corresponderán con el mismo instante temporal transaccionalmente coherente. El paquete DBMS _REFRESH contiene procedimientos para mantener los grupos de refresco desde PL/SQL. Por ejemplo, podríamos agrupar las instantáneas LocalStaff, LocalClient y LocalOwner en un grupo de instantáneas de la forma siguiente: DECLARE vSnapshotList DBMS _UTILITY.UNCL _ARRAY; BEGIN vSnapshotList(l) = 'LocaIStaff'; vSnapshotList(2) = 'LocaIClient'; vSnapshotList(3) = 'LocaIOwner'; DBMS_REFRESH.MAKE (name =} 'LOCAL_INFO', tab =} vSnapshotList, next_date =} TRUNC(sysdate) + 1, interval + 'sysdate + 1'); END; Tipos de refresco Orac1e puede refrescar una instantánea en una de las siguientes formas: • COMPLETA. El servidor que gestiona la instantánea ejecuta la consulta que define la instantánea. El conjunto de resultados de la consulta sustituye a los datos de instantánea existente, con el fin de refres- car la instantánea. Orac1e puede realizar refrescos completos para cualquier instantánea. Dependiendo de la cantidad de datos que satisfaga la consulta de definición, una operación completa de refresco puede tardar bastante más tiempo que un refresco rápido. • RÁPIDO. El servidor que gestiona la instantánea identifica primero los cambios que han tenido lugar en la tabla maestra desde la operación más reciente de refresco de la instantánea y luego aplica a la ins- tantánea dichos cambios. Los refrescos rápidos son más eficientes que los refrescos completos cuando son pocos los cambios realizados en la tabla maestra, porque el servidor y la red tienen que replicar menos datos. Los refrescos rápidos sólo están disponibles para las instantáneas cuando la tabla maes- tra disponga de un registro de instantánea. Si no es posible realizar un refresco rápido, se genera un error y la instantánea no se refrescará. • FORZADA. El servidor que gestiona la instantánea trata primero de realizar un refresco rápido. Si no es posible realizar el refresco rápido, Oracle realiza un refresco completo.
  • 147. 724 Sistemas de bases de datos Creación de instantáneas El procedimiento básico para crear una instantánea de sólo lectura es el siguiente: (1) Identificar la tabla o tablas del sitio o sitios maestros que hay que replicar al sitio de instantánea y el esquema del que son propiedad las instantáneas. (2) Crear uno o más enlaces de base de datos desde el sitio de instantánea a los sitios maestros. (3) Crear registros de instantánea (véase más abajo) en la base de datos maestra para cada tabla maestra, si se necesita realizar refrescos rápidos. (4) Usar la instrucción CREATE SNAPSHOT para crear la instantánea. Por ejemplo, podemos definir una instantánea que contenga los detalles del personal que trabaja en la sucursal B003 de la siguiente forma: CREATE SNAPSHOT Staff REFRESH FAST START WITH sysdate NEXT sysdate + 7 WITH PRIMARY KEY AS SELECT * FROM Staff@RENTALS.LONDON.SOUTH.COM WHERE branchNo = 'B003'; En este ejemplo, la cláusula SELECT define las filas de la tabla maestra (ubicada en RENTALS.LON- DON.SOUTH.COM; véase la Sección 23.9) que hay que duplicar. La cláusula START WITH indica que la instantánea debe refrescarse cada siete días, a partir de hoy. En el sitio de la instantánea, Oracle crea una tabla denominada SNAP$_Staff que contiene todas las columnas de la tabla maestra Staff. Oracle también crea una vista denominada Staffdefinida sobre una consulta sobre la tabla SNAP$_Staff. También planifica un trabajo en la cola de trabajos para refrescar la instantánea. (5) Opcionalmente, crear uno o más grupos de refresco en el sitio de instantánea y asignar cada instantá- nea a un grupo. Registros de instantánea Un registro de instantánea es una tabla que controla los cambios realizados en una tabla maestra. El registro de instantánea puede crearse utilizando la instrucción CREATE SNAPSHOT LOG. Por ejemplo, podríamos crear un registro de instantánea para la tabla Staffde la siguiente forma: CREATE SNAPSHOT LOG ON Staff WITH PRIMARY KEY TABLESPACE DreamHome Data STORAGE (INITIAL 1 NEXT 1M PCTINCREASE O); Esto crea una tabla denominada DreamHome.mlog$_Staffque contiene la clave principal de la tabla Staff,que es el atributo staffNoy diversas otras columnas, como por ejemplo el instante en que la fila fue actualizada por última vez, el tipo de actualización y los valores antiguo/nuevo. Oracle también crea un disparador posterior de fila para la tabla Staffque rellena el registro de instantánea después de cada operación de inserción, actua- lización o borrado. Los registros de instantánea también pueden ser creados interactivamente por Oracle Replication Manager. Instantáneas actualizables Como hemos indicado al principio de esta sección, las instantáneas actualizables son similares a las instantá- neas de sólo lectura, pero los sitios de instantánea son capaces de modificar dos datos y de devolver los datos al sitio maestro. El sitio de instantánea determina la frecuencia de los refrescos y la frecuencia con la que se devuelven las actualizaciones al sitio maestro. Para crear una instantánea actualizable, simplemente especifi- camos la cláusula FOR UPDATE antes de la subselección en la instrucción CREATE SNAPSHOT. En el caso de crear una instantánea actualizable para la tabla Staff, Oracle crearía los siguientes objetos:
  • 148. Capítulo 24 Replicación y bases de datos móviles 725 (1) Una tabla SNAP$ _ STAFF en el sitio de instantánea que contiene los resultados de la consulta de defini- ción. (2) Una tabla USLOG$ _ STAFF en el sitio de instantánea que captura la información acerca de las filas modi- ficadas. Esta información se utiliza para actualizar la tabla maestra. (3) Un disparador USLOG$_STAFF sobre la tabla SNAP$_STAFF en el sitio de instantánea, que rellene la tabla USLOG$_STAFF. (4) Un disparador STAFF$RT sobre la tabla SNAP$_STAFF en el sitio de instantánea, que realice llamadas al paquete STAFF$TP. (5) El paquete STAFF$TP en el sitio de instantánea, que construye las llamadas diferidas a procedimien- to remoto para invocar el paquete STAFF$RP en el sitio maestro. (6) El paquete STAFF$RP que realiza las actualizaciones en la tabla maestra. (7) El paquete STAFF$RR que contiene rutinas para resolución de conflictos en el sitio maestro. (8) La vista Slaff definida sobre la tabla SNAP$ _ STAFF. (9) Una entrada en la cola de trabajos que llama al paquete DBMS_REFRESH. Resolución de conflictos Hemos hablado de la resolución de conflictos en los entornos de replicación al final de la Sección 24.5.2. Oracle implementa muchos de los mecanismos de resolución de conflictos explicados en dicha sección utili- zando grupos de columnas. Un grupo de columnas es una agrupación lógica de una o más columnas en una tabla replicada. Cada columna no puede pertenecer más que a un grupo de columnas y las columnas que no sean explícitamente asignadas a ningún grupo de columnas serán miembros de un grupo de columnas fantas- ma que utilizará métodos predeterminados para la resolución de conflictos. Pueden crearse grupos de columnas y pueden asignársele métodos de resolución de conflictos, utilizando el paquete DBMS _REPCAT. Por ejemplo, para usar sobre la tabla Slaff un método de resolución basado en la marca temporal más reciente con el fin de resolver los cambios realizados en el salario almacenado en slaff, necesitaríamos almacenar uná columna de marca temporal en la tabla slaff, que podríamos denominar salaryTimeslamp, y usar las siguientes dos llamadas a procedimiento: EXECUTE DBMS REPCAT.MAKE COLUMN GROUPS- -- (gname => 'HR', oname => 'STAFF', column_group => 'SALARY_GP', list_ oC column _names 'slaffNo, salary, salaryTimeslamp'); EXECUTE DBMS REPCAT.ADD UPDATE RESOLUTION- -- (sname => 'HR', oname => 'STAFF', column_group => 'SALARY_GP', sequence_no => 1, method => 'LATEST_TIMESTAMP', parameter_column_name => 'salaryTimestamp', comment => 'Method 1 added on' 11 sysdate); El paquete DBMS_REPCAT también contiene rutinas para crear grupos de prioridad y sitios de prioridad. Los grupos de columnas, los grupos de prioridad y los sitios de prioridad también pueden ser creados inter- activamente por Oracle Replication Manager. Replicación multimaestro Como se explica al principio de esta sección, con la replicación multimaestro se copia una tabla a una o más bases de datos remotas, en las que la tabla puede ser actualizada. Las modificaciones se envían a las otras bases de datos a intervalos que el DBA configura para cada grupo de replicación. En muchos aspectos, la implementación de la replicación multimaestro es más simple que la de las instantáneas actualizables, ya que no hay distinción entre los sitios maestros y los sitios esclavos. El mecanismo que subyace a este tipo de repli- cación está compuesto por disparadores definidos sobre las tablas replicadas y que invocan procedimientos empaquetados que ponen en cola las llamadas RPC diferidas a la base de datos maestra remota. La resolución de conflictos se lleva a cabo como hemos descrito anteriormente.
  • 149. 726 Sistemas de bases de datos Resumen del capítulo • La replicación de bases de datos es un mecanismo de gran importancia, porque permite a las organizacio- nes proporcionar a los usuarios acceso a datos actualizados desde cualquier sitio y en cualquier momento. • La replicación de bases de datos es el proceso de copiar y mantener objetos de la base de datos, como por ejemplo relaciones, en múltiples bases de datos que conforman un sistema de base de datos distri- buido. • Las ventajas de la duplicación de la base de datos son una mayor disponibilidad, una mayor fiabilidad, unas mayores prestaciones, una reducción de la carga y el soporte para el procesamiento desconectado, para un número mayor de usuarios y para aplicaciones avanzadas. • Un objeto de replicación es un objeto de la base de datos, como por ejemplo una relación, índice, vista, procedimiento o función, que existe en múltiples servidores dentro de un sistema de base de datos distri- buido. En un entorno de replicación, las actualizaciones realizadas a un objeto de replicación en un sitio se aplican a las copias de todos los demás sitios. • En un entorno de replicación, los objetos de replicación se gestionan utilizando grupos de replicación. Un grupo de replicación es una colección de objetos de replicación lógicamente relacionados. • Los grupos de replicación pueden existir en múltiples sitios de replicación. Los entorno s de replicación soportan dos tipos básicos de sitios: sitios maestros y sitios esclavos. • Un sitio maestro controla un grupo de replicación y todos los objetos pertenecientes a dicho grupo. Esto se consigue manteniendo una copia completa de todos los objetos del sitio del grupo de replicación y propagando los cambios realizados a las demás copias del grupo de replicación ubicadas en los sitios esclavos. • Un sitio esclavo contiene sólo una instantánea de un grupo de replicación, como por ejemplo los datos que una tabla tenía en un cierto instante temporal. Normalmente, las instantáneas se refrescan periódicamente para sincronizarlas con el sitio maestro. • La replicación síncrona es la actualización inmediata de los datos replicados de destino, después de efec- tuarse una actualización en los datos de origen. Esta se lleva a cabo normalmente mediante el protocolo 2PC (confirmación en dos fases). • La replicación asíncrona es el proceso por el cual la base de datos replicada de destino se actualiza en algún instante posterior a la actualización de la base de datos de origen. El retardo necesario para volver a establecer la coherencia entre la base de datos de origen y la de destino puede ir desde unos pocos segun- dos a varias horas o incluso días. Sin embargo, los datos terminarán por sincronizarse y por adoptar los mismos valores en todos los sitios. • Los modelos de propiedad de los datos para la replicación son el modelo maestro/esclavo, el modelo de flujo de trabajo y el modelo de actualización ubicua (igualitario). En los primeros dos modelos, las répli- cas son de sólo lectura. Con el modelo de actualización ubicua, todas las copias deben ser actualizadas, por lo que es necesario proporcionar un mecanismo de detección y resolución de conflictos para mantener la integridad de los datos. • Los mecanismos típicos de replicación son las instantáneas y los disparadores de la base de datos. La propagación de las actualizaciones entre las distintas réplicas puede ser transaccional o no transaccional. • Una base de datos móvil es una base de datos portable y que está fisicamente separada del servidor de base de datos corporativo pero que es capaz de comunicarse con dicho servidor de sitios remotos, permi- tiendo así la compartición de los datos corporativos. Con las bases de datos móviles, los usuarios tienen acceso a las datos corporativos desde su computadora portátil, su PDA o cualquier otro dispositivo de acceso a Internet que las aplicaciones requieran en los sitios remotos. Cuestiones de repaso 24.1. Explique en qué se diferencia una base de datos distribuida de una base de datos replicada.
  • 150. Capítulo 24 Replicación y bases de datos móviles 727 24.2. Indique las ventajas de utilizar la replicación en un sistema distribuido. 24.3. Proporcione algunos ejemplos de aplicaciones típicas que utilicen la replicación. 24.4. Describa qué es lo que representa los conceptos de objeto replicado, grupo de replicación, sitio maes- tro y sitio esclavo en un entorno de replicación de bases de datos. 24.5. Indique las similitudes y diferencias entre la replicación síncrona y la asíncrona. 24.6. Indique las similitudes y diferencias entre los distintos modelos de propiedad de los datos disponibles en un entorno de replicación. Proporcione un ejemplo de cada modelo. 24.7. Explique la funcionalidad requerida de un servidor de replicación. 24.8. Indique los problemas de implementación asociados con la replicación. 24.9. Explique cómo dan soporte las bases de datos móviles a los trabajadores móviles. 24.10. Describa la funcionalidad requerida de un SGBD móvil. Ejercicios 24.11. Se nos pide realizar una labor de consultoría por cuenta del Director Gerente de DreamHome para investigar los requisitos de distribución de datos de la organización y preparar un informe del uso potencial de un servidor de replicación de bases de datos. El informe debe comparar la tecnología del SGBD centralizado con la del servidor de replicación e indicar las ventajas y desventajas de implemen- tar mecanismos de replicación de la base de datos en la organización, así como las áreas previstas donde puedan aparecer problemas. El informe debe también contemplar la posibilidad de utilizar un servidor de replicación para satisfacer los requisitos de distribución. Finalmente, el informe debe con- tener un conjunto de recomendaciones adecuadamente justificadas donde se proponga un curso apro- piado de acción para DreamHome. 24.12. Se nos pide realizar una labor de consultoría por cuenta del Director Gerente de DreamHome para investigar cómo podría utilizarse la tecnologia de bases de datos móviles en la organización. El resul- tado de la investigación debe presentarse como un informe donde se analicen los beneficios poten- ciales asociados con Hi informática móvil y los problemas que pueden surgir al tratar de utilizar la tecnologia de bases móviles en la organización. El informe debe también contener un conjunto de reco- mendaciones adecuadamente justificado donde se proponga una solución apropiada para DreamHome.
  • 151. Bases de datos orientadas a objetos Capítulo 25 Introducción a los SGBD orientados a objetos Capítulo 26 Bases de datos orientadas a objetos: conceptos Capítulo 27 Bases de datos orientadas a objetos: estándares y sistemas Capítulo 28 Bases de datos objeto-relaciona les
  • 152. Introducción a los SGBD orientados a objetos Objetivos del capítulo: En este capítulo aprenderá: • Los requisitos para las aplicaciones avanzadas de bases de datos. • Por qué los SGBD relacionales no están actualmente bien adaptados para soportar las aplicaciones avanzadas de bases de datos. • Los conceptos asociados con la orientación a objetos: • abstracción, encapsulación y ocultación de información; • objetos y atributos; • identidad de los objetos; • métodos y mensajes; • clases, subclases, superclase y herencia; • sobrecarga; • polimorfismo y enlace dinámico. • Los problemas asociados con el almacenamiento de objetos en una base de datos relacional. • Qué constituye la siguiente generación de sistemas de bases de datos. • Los conceptos básicos del análisis y diseño de bases de datos orientadas a objetos mediante UML. La orientación a objetos es una técnica de desarrollo software que ha mostrado considerables capacidades para resolver algunos de los problemas clásicos de la ingeniería del software. El concepto subyacente a la tecno- logía de objetos es que todo el software debe construirse utilizando componentes estándar y reutilizables siem- pre que sea posible. Tradicionalmente, la ingeniería del software y la gestión de bases de datos eran discipli- nas separadas. La tecnología de bases de datos se ha concentrado en los aspectos estáticos del almacenamiento de la información, mientras que la ingeniería del software lo ha hecho en modelar los aspectos dinámicos del software. Con la llegada de la tercera generación de sistemas de gestión de bases de datos, los denominados sistemas de gestión de bases de datos orientados a objetos (SGBDOO) y sistemas de gestión de bases de datos objeto-relacionales (SGBDOR), las dos disciplinas se han combinado para permitir el modelado con- currente tanto de los datos como de los procesos que actúan sobre los mismos. Sin embargo, existe actualmente una importante discusión en lo que respecta a esta siguiente ge.neración de sistemas SGBD. El éxito de los sistemas relacionales en las dos décadas anteriores es evidente y los tradi- cionalistas consideran que es suficiente ampliar el modelo relacional con capacidades adicionales (de orien- tación a objetos). Otros piensan que un modelo relacional subyacente resulta inadecuado para gestionar apli- caciones complejas, como el diseño asistido por computadora, la ingeniería del software asistida por computadora y los sistemas de información geográfica. Para tratar de entender estos nuevos tipos de SGBD y los argumentos utilizados por ambos bandos, hemos dedicado cuatro capítulos a explicar la tecnología y los problemas relacionados con la misma.
  • 153. 732 Sistemas de bases de datos En el Capítulo 26, se analiza la aparición de los SGBDOO y se examinan algunos de los problemas que afectan a estos sistemas. En el Capítulo 27 se examina el modelo de objetos propuesto por el ODMG (Object Data Management Group), que se ha convertido en un estándar defacto para los SGBDOO, y ObjectStore, un SGBDOO comercial. En el Capítulo 28 se analiza la aparición de los SGBDOR y se examinan algunos de los problemas relacionados con ellos. En particular, examinaremos SQL:2003, la última versión del estándar ANSI/ISO para SQL, así como algunas de las características de orientación a objetos de Oracle. En este capí- tulo veremos diversos conceptos comunes tanto a los SGBDOO como a los SGBDOR. Estructura del capítulo En la Sección 25.1 se examinan los requisitos para una serie de tipos avanzados de aplicaciones de bases de datos que están siendo cada vez más comunes, y en la Sección 25.2 se analiza por qué los SGBDR tradicio- nales no están bien adaptados para soportar estas nuevas aplicaciones. En la Sección 25.3 se proporciona la introducción a los principales conceptos de orientación a objetos y en la Sección 25.4 se examinan los pro- blemas asociados con el almacenamiento de objetos en una base de datos relacional. En la Sección 25.5 se proporciona una breve historia de los sistemas de gestión de bases de datos desde su aparición hasta la terce- ra generación, formada por los SGBD orientados a objetos y objeto-relacionales. En la Sección 25.6 se exa- mina brevemente cómo puede ampliarse la metodología de diseño conceptual lógico de bases de datos pre- sentada en los Capítulos 15 y 16 para gestionar el diseño de bases de datos orientadas a objetos. Los ejemplos de este capítulo están, de nuevo, extraídos del caso de estudio de DreamHome documentado en la Sección 10.4 y en el Apéndice A. 25.1 Aplicaciones avanzadas de bases de datos La industria informática ha visto cambios muy significativos en esta última década. En los sistemas de bases de datos, hemos podido asistir a la universal aceptación de los SGBDR para aplicaciones tradicionales de carácter empresarial, como el procesamiento de pedidos, el control de almacén, aplicaciones bancarias y reser- va de billetes de líneas aéreas. Sin embargo, los SGBD existentes han demostrado ser inadecuados para apli- caciones cuyas necesidades son completamente distintas de aquellas de las aplicaciones empresariales de bases de datos tradicionales. Estas aplicaciones incluyen: • diseño asistido por computadora (CAD); • fabricación asistida por computadora (CAM); • ingeniería del software asistida por computadora (CASE); • sistema de gestión de red; • sistemas de información de oficina (OIS) y sistemas multimedia; • autoedición digital; • sistemas de información geográfica (GIS); • sitios web interactivos y dinámicos. Diseño asistido por computadora (CAD) Una base de datos CAD (computer-aided design) almacena datos relativos a diseños mecánicos y eléctricos de, por ejemplo, edificios, aeronaves y circuitos integrados. Los diseños de este tipo tienen algunas caracte- rísticas comunes: ' • Los datos de diseño se caracterizan por un gran número de tipos, cada uno con un pequeño número de instancias. Las bases de datos convencionales presentan normalmente características opuestas. Por ejemplo, la base de datos de DreamHome está compuesta de aproximadamente una docena de relacio- nes, aunque relaciones tales como PropertyForRent, Client y Viewing pueden contener miles de tuplas.
  • 154. Capítulo 25 Introducción a los SGDB orientados a objetos 733 • Los diseños pueden ser muy grandes, quizás compuestos de millones de componentes, a menudo con muchos diseños de subsistemas interdependientes. • El diseño no es estático, sino que evoluciona a lo largo del tiempo. Cuando se produce un cambio de diseño, sus implicaciones deben propagarse a través de todas las representaciones del diseño. La natu- raleza dinámica del diseño puede implicar que algunas acciones no se hayan previsto desde el prin- cipio. • Las actualizaciones tienen un largo alcance, debido a las relaciones topológicas o funcionales, a las tolerancias, etc. Resulta bastante común que un cambio afecte a un gran número de objetos de diseño. • A menudo, se consideran muchas alternativas de diseño para cada componente y es preciso mantener la versión correcta de cada pieza. Esto implica que hace falta algún tipo de control de versiones y de mecanismo de gestión de configuración. • Puede haber cientos de personas implicadas en el diseño y esas personas pueden tener que trabajar en paralelo sobre múltiples versiones de un diseño de gran tamaño. Aún así, el producto final debe ser coherente y estar coordinado. Esto se denomina en ocasiones ingeniería cooperativa. Fabricación asistida por computadora (CAM) Una base de datos CAM (computer-aided manufacturing) almacena datos similares a un sistema CAD, ade- más de datos relativos a la producción de elementos discretos (como por ejemplo coches en una línea de mon- taje) y a la producción de carácter continuo (por ejemplo una síntesis química). Por ejemplo, en las industrias químicas hay aplicaciones que monitorizan la información acerca del estado del sistema, como las tempera- turas de las vasijas de reacción, las tasas de flujo y los datos de rendimiento. También hay aplicaciones que controlan diversos procesos físicos, como la apertura de válvulas, la aplicación de más calor a las vasijas de reacción o el incremento del flujo en los sistemas de refrigeración. Estas aplicaciones están a menudo organi- zadas en una jerarquía, existiendo una aplicación de nivel superior que monitoriza toda la fábrica y una serie de aplicaciones de niveles inferiores que monitorizan procesos individuales de fabricación. Estas aplicaciones deben responder en tiempo real y son capaces de ajustar los procesos para mantener un rendimiento óptimo, con unas tolerancias mínimas. Dichas aplicaciones utilizan una combinación de algoritmos estándar y reglas personalizadas para responder a diferentes condiciones. Los operadores pueden modificar estas reglas ocasio- nalmente para optimizar el rendimiento basándose en datos históricos complejos que el sistema debe mante- ner. En este ejemplo, el sistema tiene que mantener grandes volúmenes de datos que son jerárquicos por natu- raleza y mantener también diversas relaciones complejas entre los datos. También debe permitir navegar rápidamente por los datos para revisados y poder responder a los cambios. Ingeniería del software asistida por computadora (CASE) Una base de datos CASE (computer-aided software engineering) almacena datos relativos a las etapas del ciclo de desarrollo del software: planificación, recopilación y análisis de requisitos, diseño, implementación, pruebas, mantenimiento y documentación. Al igual que sucede con el CAD, los diseños pueden ser extrema- damente grandes y la ingeniería cooperativa es la norma. Por ejemplo, las herramientas de gestión de confi- guración software permiten compartir de forma concurrente el diseño del proyecto, el código y la documen- tación. También controlan las dependencias entre dichos componentes y ayudan a la gestión de cambios. Las herramientas de gestión de proyectos facilitan la coordinación de diversas actividades de gestión de proyec- tos, como la planificación de tareas interdependientes potencialmente muy complejas, la estimación de costes y la monitorización del progreso. Sistemas de gestión de red Los sistemas de gestión de red coordinan la provisión de servicios de comunicaciones en una red informáti- ca. Estos sistemas realizan sistemas tales como la gestión de las rutas de red, la gestión de problemas y la pla- nificación de red. Al igual que con el ejemplo de la industria química que hemos presentado anteriormente, estos sistemas también gestionan datos complejos y requieren un funcionamiento en tiempo real y una opera-
  • 155. 734 Sistemas de bases de datos ción continua. Por ejemplo, una llamada telefónica puede implicar que se utilice una cadena de dispositivos de conmutación de red para encaminar los mensajes desde el emisor al receptor, como por ejemplo: Nodo <=> Enlace <=> Nodo <=> Enlace <=> Nodo <=> Enlace <=> Nodo donde cada Nodo representa un puerto en un dispositivo de red y cada Enlace representa un fragmento de ancho de banda reservado para dicha conexión. Sin embargo, un nodo puede participar en muchas conexio- nes diferentes y cualquier base de datos que se cree tendrá que gestionar un grafo complejo de relaciones. Para encaminar las conexiones, diagnosticar los problemas y equilibrar las cargas, los sistemas de gestión de red tienen que ser capaces de desplazarse a través de este grafo complejo en tiempo real. Sistemas de información de oficina (OIS) y sistemas multimedia Una base de datos GIS (office information systems) almacena datos relativos al control informatizado de la información en una empresa, incluyendo el correo electrónico, los documentos, las facturas, etc. Para propor- cionar un mejor soporte para esta tarea, necesitamos gestionar un rango más amplio de tipos de datos, y no sólo nombres, direcciones, fechas y dinero. Los sistemas modernos gestionan hoy en día texto libre, fotogra- fias, diagramas y secuencias de audio y de vídeo. Por ejemplo, un documento multimedia puede contener texto, fotografias, hojas de cálculo y comentarios de voz. Los documentos pueden tener una estructura espe- cífica, quizá descrita mediante un lenguaje de composición tal como SGML (Standardized Generalized Markup Language, lenguaje estándar generalizado de composición), HTML (HyperText Markup Language, lenguaje de composición de hipertexto), o XML (eXtended Markup Language, lenguaje de composición ampliado), como comentaremos en el Capítulo 30. Los documentos pueden ser compartidos entre muchos usuarios que utilicen sistemas tales como el correo electrónico y los foros basados en tecnología Internet.t De nuevo, dichas aplicaciones necesitan almacenar datos que tienen una estructura mucho más rica que la de unas tuplas consistentes en números y en cadenas de texto. También existe una creciente necesidad de capturar notas manuscritas utilizando dispositivos elec- trónicos. Aunque muchas notas pueden transcribirse en texto ASCII utilizando técnicas de análisis de la estructura manual, la mayor parte de esos datos no pueden transformarse. Además de palabras, los datos manuscritos incluyen dibujos, diagramas, etc. En el caso de estudio de DreamHome, podemos encontrar los siguientes requisitos para la gestión de datos multimedia: • Datos de imagen. Un cliente puede consultar una base de datos con imágenes de los inmuebles en alquiler. Algunas consultas pueden utilizar simplemente una descripción textual para identificar imá- genes de inmuebles de interés. En otros casos, puede resultar útil para el cliente consultar utilizando imágenes gráficas de las características que pueden encontrarse en los inmuebles de interés (como por ejemplo una piscina o ventajas en la buhardilla). • Datos de vídeo. Un cliente puede consultar una base de datos de secuencias de vídeo de los inmuebles en alquiler. De nuevo, algunas consultas pueden simplemente utilizar una descripción textual para identificar las imágenes de vídeo de los inmuebles deseados. En otros casos, puede resultar útil que el cliente efectúe la consulta utilizando características del vídeo de los inmuebles deseados (como por ejemplo vistas del mar o de las colinas circundantes). • Datos de audio. Un cliente puede consultar una base de datos de audio que describa las características de los inmuebles en alquiler. De nuevo, algunas consultas pueden utilizar simplemente una descripción textual para identificar el inmueble deseado. En otros casos, puede resultar útil que el cliente utilice características de audio relativas a esos inmuebles (como por ejemplo el nivel de ruido derivado del tráfico en las proximidades). t Una crítica bastante seria de los sistemas de bases de datos, como se han ocupado de resaltar diversos observadores, es que la mayor 'base de datos' del mundo, la World Wide Web, se desarrolló inicialmente sin hacer a penas uso de la tecnología de base de datos. Hablaremos de la integración de la World Wide Web y de los SGBD en el Capítulo 29.
  • 156. Capítulo 25 Introducción a los SGDB orientados a objetos 735 • Datos manuscritos. Un empleado puede tomar una serie de notas mientras que realiza inspecciones de los inmuebles en alquiler. En una fecha posterior, puede querer consultar dichos datos para ver todas las notas realizadas acerca de un apartamento determinado. Autoedición digital La industria editorial va a sufrir profundos cambios en sus prácticas empresariales a lo largo de la próxima década. Ya es posible almacenar libros, revistas, artículos y periódicos electrónicamente y distribuirlos a tra- vés de redes de alta velocidad a los consumidores. Al igual que sucede con los sistemas de información de oficina, la edición digital está ampliándose para gestionar documentos multimedia compuestos de texto, audio, imágenes, datos de vídeo y animaciones. En algunos casos, la cantidad de información disponible para poner en línea es enorme, del orden de los petabytes (1015 bytes), lo que convertiría a estas bases de datos en las mayores que un SGBD ha tenido nunca que gestionar. Sistemas de información geográfica (GIS) Una base de datos GIS (geographic information systems) almacena diversos tipos de información espacial y temporal, como por ejemplo la utilizada en la gestión catastral y en la exploración submarina. Buena parte de los datos de estos sistemas están derivados de las fotografías vía satélite y la cantidad de información tiende a ser muy grande. Las búsquedas pueden implicar la identificación de características basándose, por ejemplo, en la forma, el color o la textura, utilizando técnicas avanzadas de reconocimiento de patrones. Por ejemplo, EOS (Earth Observing System) es una colección de satélites lanzados por la NASA en la década de 1990 para recopilar información científica relativa a las tendencias a largo plazo que pueden obser- varse en la atmósfera terrestre, en los océanos y en la superficie de la Tierra. Las previsiones son que estos satélites devuelvan 0,3 petabytes de información por año. Estos datos serán integrados con otras fuentes de datos y se almacenarán en EOSDIS (EOS Data and Information System). EOSDIS permitirá satisfacer las necesidades de información tanto de los científicos como de los no científicos. Por ejemplo, los niños en edad escolar podrán acceder a EOSDIS para ver una simulación de los patrones climáticos. El inmenso tamaño de esta base de datos y la necesidad de soportar miles de usuarios con solicitudes de enormes volúmenes de infor- mación planteará numerosos desafíos a los SGBD. Sitios web interactivos y dinámicos Considere un sitio web que tenga un catálogo en línea para la venta de prendas de vestir. El sitio web mantie- ne un conjunto de preferencias para los visitantes anteriores del sitio y permite al visitante: • ojear una serie de imágenes en miniatura de los elementos del catálogo y seleccionar una de ellas para obtener una imagen a tamaño completo junto con detalles adicionales; • buscar elementos que se correspondan con una serie de criterios definidos por el usuario; • obtener una visualización en 3D de cualquier prenda de ropa basándose en una especificación perso- nalizada (por ejemplo, color, tamaño, tela); • modificar dicha visualización para tener en cuenta el movimiento, la iluminación, diversos escenarios, etc.; • seleccionar accesorios que complementen a las prendas de vestir, a partir de una serie de elementos presentados en una barra de herramientas lateral; • seleccionar la reproducción de un comentario de voz que proporcione detalles adicionales sobre el ele- mento; • ver un total actualizado de la factura, con los descuentos apropiados; • concluir la compra mediante una transacción en línea segura. Los requisitos de este tipo de aplicación no son muy diferentes de algunas de las otras aplicaciones avan- zadas que ya hemos visto: existe la necesidad de gestionar contenido multimedia (texto, audio, imágenes, datos de vídeo y animaciones) y de modificar interactivamente la visualización basándose en las preferencias
  • 157. 736 Sistemas de bases de datos y selecciones del usuario. Además de gestionar datos complejos, el sitio web tiene la complejidad añadida de tener que proporcionar visualizaciones 3D. Algunos argumentan que en dicha situación la base de datos no está simplemente presentando información al visitante, sino que está activamente implicada en la venta, pro- porcionando dinámicamente una información personalizad a y una cierta atmósfera de compra al visitante (King, 1997). Como se explica en los Capítulo 29 y 30, la Web proporciona ahora un paradigma relativamente nuevo para la gestión de datos, y lenguajes tales como XML resultan muy prometedores, particularmente para el mercado del comercio electrónico. Forrester Research Group predice que las transacciones interempresaria- les alcanzarán los 2,1 billones de dólares en Europa y los 7 billones de dólares en los Estados Unidos en 2006. En conjunto, se espera que el comercio electrónico represente 12,8 billones de dólares para los ingresos cor- porativos en todo el mundo en 2006, lo que representa un 18% de las ventas en la economía global. A medi- da que se incremente el uso de Internet y que la tecnología se vuelva más sofisticada, podremos ver a los sitios web y a las transacciones interempresariales gestionar datos mucho más complejos e interrelacionados. Otras aplicaciones avanzadas de bases de datos son: • Aplicaciones científicas y médicas, que pueden almacenar datos complejos que representan sistemas tales como modelos moleculares para compuestos químicos sintéticos y material genético. • Sistemas expertos, que pueden almacenar bases de datos de conocimientos y de reglas para aplicacio- nes de inteligencia artificial (lA). • Otras aplicaciones con objetos complejos e interrelacionados y datos procedimentales. 25.2 Debilidades de los SGBDR En el Capítulo 3 hemos visto cómo el modelo relacional tiene una fuerte base teórica, basada en la lógica de predicados de primer orden. Esta teoría fue la base para el desarrollo de SQL, un lenguaje declarativo que se ha llegado a convertir en el lenguaje estándar para la definición y manipulación de bases de datos relaciona- les. Otras fortalezas del modelo relacional son su simplicidad, que resulta adecuado para el procesamiento de transacciones en línea (OLTP) y su soporte de la independencia de los datos. Sin embargo, el modelo de datos relacional, y los SGBD relacionales en particular, no carecen de desventajas. La Tabla 25.1 enumera algunas de las debilidades más significativas que a menudo suelen citar los componentes de la técnica orientada a objetos. Vamos a hablar de estas debilidades en esta sección y dejaremos que sean los lectores los que juz- guen hasta qué punto son aplicables dichas debilidades. Pobre representación de las entidades del 'mundo real' El proceso de normalización conduce generalmente a la creación de relaciones que no se corresponden con entidades del 'mundo real'. La fragmentación de una entidad del 'mundo real' en muchas relaciones, con una Tabla 25.1. Resumen de debilidades de los SGBD relacionales. Debilidades Pobre representación de las entidades del 'mundo real' Sobrecarga semántica Soporte inadecuado para las restricciones de integridad y empresariales Estructura de datos homogénea Operaciones limitadas Dificultades para gestionar las consultas recursivas Desadaptación de impedancias Otros problemas de los SGBDR asociados con la concurrencia, los cambios en los esquemas y el inadecuado acceso navegacional
  • 158. Capítulo 25 Introducción a los SGDB orientados a objetos 737 representación física que refleja esta estructura, es ineficiente y conduce a que sea necesario realizar muchas combinaciones durante el procesamiento de las consultas. Como ya hemos visto en el Capítulo 21, las com- binaciones están entre las operaciones más costosas de realizar. Sobrecarga semántica El modelo relacional tiene una única estructura para representar los datos y las relaciones entre los datos, la estructura de relación o tabla. Por ejemplo, para representar una relación muchos a muchos (*:*) entre dos entidades A y B, creamos tres tablas, una para representar cada una de las entidades A y B, Y otra para repre- sentar la relación. No hay ningún mecanismo para distinguir entre entidades y relaciones, o para distinguir entre diferentes tipos de relaciones que puedan existir entre las entidades. Por ejemplo, una relación 1:* puede ser Has, Owns, Manages, etc. Si pudieran realizarse tales distinciones, podría ser posible incluir los aspectos semánticos dentro de las operaciones. Por ello se suele decir que el modelo relacional está semánticamente sobrecargado. Ha habido muchos intentos de resolver este problema utilizando modelos de datos semánticos, es decir, modelos que representan en mayor medida el significado de los datos. El lector interesado puede consultar los artículos de Hull y King (1987) y Peckham y Maryanski (1988). Sin embargo, el modelo relacional no care- ce completamente de características semánticas. Por ejemplo, dispone de dominios y claves (véase la Sección 3.2) y de dependencias funcionales, multivaluadas y de combinación (véanse los Capítulos 13 y 14). Soporte inadecuado para las restricciones de integridad y empresariales El término integridad hace referencia a la validez y coherencia de los datos almacenados. La integridad suele expresarse en términos de restricciones, que son reglas de coherencia que no se permite que la base de datos viole. En la Sección 3.3 hemos presentado los conceptos de integridad de identidades e integridad referencial, y en la Sección 3.2.1 hemos introducido los dominios, que también son un tipo de restricción. Desafortunadamente, muchos sistemas comerciales no soportan completamente estas restricciones y es nece- sario incluir1as dentro de las aplicaciones. Esto, por supuesto, resulta peligroso y puede conducir a una dupli- cación de esfuerzos o, todavíao'peor, a la aparición de incoherencias. Además, no hay soporte para las restric- ciones empresariales dentro del modelo relacional, lo que de nuevo significa que dichas restricciones tienen que incluirse en el SGBD o en la aplicación. Como hemos visto en los Capítulos 5 y 6, el estándar SQL ayuda a resolver en parte esta supuesta defi- ciencia permitiendo especificar algunos tipos de restricciones como parte del lenguaje DDL (Data Definition Language). Estructura de datos homogénea El modelo relacional asume una homogeneidad tanto horizontal como vertical. La homogeneidad horizontal significa que cada tupla de una relación debe estar compuesta por los mismos atributos. La homogeneidad ver- tical significa que los valores de una columna concreta de una relación deben provenir todos ellos del mismo dominio. Además, la intersección de una fila y de una columna debe ser un valor atómico. Esta estructura fija es demasiado restrictiva para muchos objetos del 'mundo real', que tienen una estructura compleja, y condu- ce a combinaciones poco naturales, que son muy ineficientes, como ya hemos mencionado. En defensa del modelo de datos relacional podría también argtiirse que su estructura simétrica es una de las fortalezas del modelo. Entre los ejemplos clásicos de datos complejos y relaciones interrelacionadas estaría el despiece con el que se representaría algún tipo de objeto, como por ejemplo una aeronave; dicho despiece está compuesto de pie- zas y piezas compuestas, que a su vez están formadas por otras piezas y por otras piezas compuestas, etc. Esta debilidad ha conducido a que se realicen numerosas investigaciones sobre sistemas de bases de datos para objetos complejos o sistemas que no están en primera forma normal (NF2), investigaciones reflejadas, por ejemplo, en los artículos de Jaeschke y Schek (1982) y Bancilhon y Khoshafian (1989). En este último artí- culo, los objetos se definen recursivamente de la siguiente forma: (1) Cada valor atómico (como, por ejemplo, un entero, un número en coma flotante o una cadena) es un objeto.
  • 159. Relación anidada Conjunto de tuplas Objetos atómicos Conjunto Tupla Tupla jerárquica 738 Sistemas de bases de datos (2) Si al' a2, .•• , an son nombres de atributos diferenciados y 0, O2, .•. , 0n son objetos, entonces [al :0, a2:02, ... , an:on] es un objeto tupla. (3) Si 01, O2, ... , 0n son objetos, entonces S = {O, O2, ... , on} es un objeto conjunto. En este modelo, tendríamos que los siguientes serían objetos válidos: B003, John, Glasgow {SG37, SG14, SGS} [branchNo: B003, street: 163 Main St, city: Glasgow] [branchNo: B003, street: 163 Main St, city: Glasgow, staff: {SG37, SG14, SGS}] {[branchNo: B003, street: 163 Main St, city: Glasgow], [branchNo: BOOS,street: 22 Deer Rd, city: London]} {[branchNo: B003, street: 163 Main St, city: Glasgow, staff: {SG37, SGI4, SGS}], [branchNo: BOOS,street: 22 DeerRd, city: London, staff: {SL21, SL41}]} Muchos SGBDR ahora permiten almacenar Objetos binarios de gran tamaño (BLOB, Binary Large Object). Un BLOB es un valor de datos que contiene información binaria que contiene una imagen, una secuencia de vídeo o de audio digitalizada, un procedimiento o algún tipo de objeto de gran tamaño no estruc- turado. El SGBD no tiene ningún conocimiento en lo que respecta al contenido del BLOB o a su estructura interna. Esto impide al SGBD realizar consultas y operaciones sobre tipos de datos que son inherentemente ricos y estructurados. Normalmente, la base de datos no gestiona esta información directamente, sino que sim- plemente contiene una referencia a un archivo. La utilización de objetos BLOB no es una solución elegante y almacenar esta información en archivos externos hace que se deniegue a esa información muchas de las pro- tecciones que el SGBD proporciona de forma natural. Además, y más importante, los objetos BLOB no pue- den contener otros objetos BLOB, así que no pueden adoptar la forma de objetos compuestos. Asimismo, los objetos BLOB ignoran generalmente los aspectos comportamentales de los objetos. Por ejemplo, podemos almacenar una imagen como un BLOB en algún SGBD relacional; sin embargo, la imagen únicamente puede almacenarse y visualizarse. No resulta posible manipular la estructura interna de la imagen ni es posible visua- lizar o manipular partes de la misma. En la Figura 18.12 se proporciona un ejemplo de la utilización de obje- tos BLOB. Operaciones limitadas El modelo relacional sólo tiene un conjunto fijo de operaciones, como por ejemplo operaciones de conjuntos y orientadas a tuplas, las cuales se detallan en la especificación del lenguaje SQL. Sin embargo, SQL no per- mite especificar nuevas operaciones. De nuevo, esto es demasiado restrictivo para modelar el comportamien- to de muchos objetos del 'mundo real'. Por ejemplo, una aplicación GIS utiliza normalmente puntos, líneas, grupos de líneas y polígonos, y necesita operaciones que permitan determinar cosas como la distancia, la inter- sección o el hecho de que un objeto esté contenido en otro. Dificultades para gestionar las consultas recursivas La atomicidad de los datos implica que no se permite que existan grupos repetitivo s en el modelo relacional. Como resultado, resulta extremadamente difícil gestionar consultas recursivas, es decir, consultas sobre rela- ciones que una tabla tenga consigo misma (directa o indirectamente). Considere la tabla simplificada Staff que se muestra en la Figura 2S.1(a), que almacena los números de empleados y el número de empleado del corres- pondiente jefe. ¿Cómo podemos encontrar todos los jefes que supervisan, directa o indirectamente, al núme- ro de empleado SOOS?Para encontrar los primeros dos niveles de la jerarquía, utilizaríamos: SELECT managerStaffNo FROM Staff WHERE staffNo = 'SOOS' UNION
  • 160. Cierre transitivo Capítulo 25 Introducción a los SGDB orientados a objetos 739 SELECT manager8taffNo FROM 8taff WHERE staffNo = (SELECT manager8taffNo FROM 8taff WHERE staffNo = '8005'); Podemos ampliar fácilmente esta técnica para hallar la respuesta completa a esta consulta. Para este ejem- plo concreto, esta técnica funciona porque sabemos cuántos niveles de jerarquía hay que procesar. Siñ embar- go, si quisiéramos realizar una consulta de carácter más general, como por ejemplo 'para cada empleado, hallar todos los jefes que supervisan directa o indirectamente a esa persona', esta técnica sería imposible de implementar utilizando SQL interactivo. Para resolver este problema, podemos incrustar SQL en un lenguaje de programación de alto nivel, que proporciona estructuras para facilitar la iteración (véase el Apéndice E). Adicionalmente, muchos SGBDR proporcionan una herramienta de escritura de informes con estructuras similares. En cualquiera de los dos casos, es la aplicación, más que las capacidades inherentes del sistema, lo que proporciona la funcionalidad requerida. Una ampliación del álgebra relacional que ha sido propuesta para gestionar este tipo de consulta es la ope- ración unaria de cierre transitivo o cierre recursivo (Merrett, 1984): El cierre transitivo de una relación R con atributos (A1, A2) definidos sobre el mismo dominio es la relación R ampliada con todas las tuplas que pueden reducirse por transitividad; es decir, si (a, b) y (b, e) son tuplas de R, la tupla (a, e) también se añade al resultado. Esta operación no puede realizarse con sólo un número fijo de operaciones del álgebra relacional, sino que requiere efectuar un bucle, además de utilizar las operaciones de combinación, proyección y unión. El resul- tado de esta operación sobre nuestra tabla 8taff simplificada se muestra en la Figura 25.1 (b). Desadaptación de impedancias En la Sección 5.1 hemos resaltado que SQL-92 carecía de completud computacional. Esto es cierto con la mayoría de los lenguajes de manipulación de datos (DML) de los SGBDR. Para resolver este problema y pro- porcionar flexibilidad adicional, el estándar SQL proporciona lo que se denomina SQL incrustado para ayu- dar a desarrollar aplicaciones de bases de datos más complejas (véase el Apéndice E). Sin embargo, esta téc- nica produce una des adaptación de impedancias porque estamos mezclando diferentes paradigmas de programación: • SQL es un lenguaje declarativo que gestiona filas de datos, mientras que un lenguaje de alto nivel tal como 'c' es un lenguaje procedimental que sólo puede gestionar una fila de datos cada vez. staffNo managerstaffNo 5005 5004 S004 5003 5003 5002 5002 5001 SOOI NULL (a) staffNo managerstaffNo S005 5004 5004 S003 5003 5002 5002 5001 5001 NULL 5005 5003 5005 5002 5005 5001 5004 5002 S004 SOOI S003 5001 (b) Figura 25.1. (a) Relación Staff simplificada; (b) cierre transitivo de la relación Staff.
  • 161. 740 Sistemas de bases de datos • SQL y los lenguajes 3GL utilizan modelos distintos para representar los datos. Por ejemplo, SQL pro- porciona los tipos de datos predefinidos Date e Interval, que no están disponibles en los lenguajes de programación tradicionales. Por tanto, es necesario que el programa de aplicación efectúe la conver- sión entre las dos representaciones, lo que resulta ineficiente tanto en términos del esfuerzo de progra- mación como el uso de recursos de procesamiento. Se ha estimado que se invierte hasta un 30% del esfuerzo de programación y del espacio de código en este tipo de conversiones (Atkinson et al., 1983). Además, puesto que estamos utilizando dos sistemas de tipado distintos, no es posible efectuar una comprobación automática de tipos de toda la aplicación. Algunos argumentan que la solución a estos problemas no es sustituir los lenguajes relacionales por len- guajes orientados a objetos de nivel de fila, sino introducir funcionalidades de nivel de conjuntos en los len- guajes de programación (Date, 2000). Sin embargo, el objetivo de los SGBDOO es proporcionar una integra- ción mucho más perfecta entre el modelo de datos del SGBD y el lenguaje de programación host. Volveremos sobre este tema en el siguiente capítulo. Otros problemas de los SGBDR • Las transacciones en las aplicaciones de procesamiento empresarial son generalmente de corta dura- ción y las primitivas y protocolos de control de concurrencia, como el bloqueo en dos fases, no resul- tan particularmente adecuados para las transacciones de larga duración, que suelen ser mucho más comunes para los objetos de diseño complejos (véase la Sección 20.4). • Los cambios en los esquemas son difíciles. Es necesario que intervengan los administradores de bases de datos para cambiar las estructuras de la base de datos y, normalmente, los programas que acceden a estas estructuras deben ser modificados para ajustarse a la nueva definición. Estos son procesos len- tos y pesados incluso con las tecnologías actuales. Como resultado, la mayoría de las organizaciones se encuentran prisioneras de sus propias estructuras de base de datos. Aunque quieran cambiar la forma en que actúan empresarialmente con el fin de adaptarse a nuevos requisitos, y aunque sean capaces de hacerlo, no pueden llevar a cabo estos cambios porque no pueden permitirse el tiempo y los costes requeridos para modificar sus sistemas de información (Taylor, 1992). Para satisfacer los requisitos de una mayor flexibilidad, necesitamos un sistema que permita una evolución natural de los esquemas. • Los SGBDR fueron diseñados para utilfzar un acceso asociativo basado en el contenido (es decir, ins- trucciones declarativas con selecciones basadas en uno o más predicados) y no son demasiado adecua- dos para el acceso navegacional (es decir, el acceso basado en el movimiento entre registros indivi- duales). El acceso navegacional es importante para muchas de las aplicaciones complejas de las que hemos hablado en la sección anterior. De estos problemas, los dos primeros son aplicables a muchos SGBD, no sólo a los sistemas relacionales. De hecho, no hay ningún problema subyacente al modelo relacional que impida que dichos mecanismos se implementen. La última versión del estándar SQL, SQL:2003, trata de resolver algunas de las deficiencias anteriores introduciendo muchas nuevas características, com