• Author / Uploaded
• Jose Velasco

• Categories
• Servidor SQL de Microsoft
• Bases de datos
• Servidor (Computación)
• Red de computadoras
• Gestión de datos

Citation preview

Ministerio de Educación Superior de la República de Cuba Centro Universitario Vladimir Ilich Lenin

Monografía

Bases de Datos Distribuidas

Autor: Lic. Maidel de la Rosa Téllez. Administrador de la Red del CULT. Facultad de Ciencias Técnicas

Las Tunas, 2005.

© Editorial Universitaria, 2005 Calle 23 No. 667, e/ D y E El Vedado, Ciudad de La Habana, Cuba

ISBN: 959-16-0336-3.

2

Bases de Datos Distribuidas El continuo y creciente desarrollo de la alta tecnología y la disminución de los costos del Hardware han sido las principales causas que han motivado a los programadores la implementación de los Sistemas de Bases de Datos Distribuidas (SBDD). El tema de las bases de datos distribuidas (BDD) constituye por sí mismo un tema amplio, donde encontramos los SBDD. El principal objetivo de los SBDD es que el manejo de los datos realice como una única colección global de los datos. Debido a que los SBDD son aún un área en desarrollo, están jugando un papel importante en operaciones de negocios. Con los extraordinarios avances que ocurren a diario en los sistemas de comunicaciones, la tecnología de los SBDD será necesaria para todas las organizaciones.

Definición La base de datos consiste en dos o más ficheros de datos almacenados en diferentes localidades de una red que pueden estar geográficamente separadas y conectadas por enlaces de comunicación[1]. Cuando las bases de datos son distribuidas, diferentes usuarios tienen acceso sin interferir unos con otros. Sin embargo, el sistema de gestión de bases de datos distribuidas (SGBBD) debe sincronizar periódicamente las bases de datos dispersas, para asegurar que todas tengan sus datos uniformes[2]. El acceso a los datos en los SBDD se realiza mediante los enlaces de comunicación que conformen la red en la que se encuentren los sitios que contengan alguna de las partes los datos. Los sitios pueden estar en una habitación o geográficamente separados, cada uno de ellos tiene capacidad de procesamiento autónomo y de ejecución de aplicaciones locales. Los sistemas de bases de datos distribuidas heredan algunas cuestiones negativas de los sistemas centralizados, la distribución de los datos incorpora un nuevo nivel de complejidad, que a su vez añade beneficios adicionales que se trataran posteriormente en este documento. Es importante destacar que las bases de datos distribuidas no son implementaciones distribuidas de bases de datos centralizadas. El procesamiento de bases de datos distribuidas es el procesamiento de bases de datos en el cual la ejecución de transacciones y la recuperación y actualización de los datos acontece a través de dos o más computadoras independientes, que pueden estar separadas geográficamente. Cuando diseñamos un sistema de base de dato distribuida debemos tener en cuanta algunas características claves que caracterizan este tipo de sistemas, como son:

3

ƒ

Permitir que cada sitio almacene y mantenga su propia BD facilita el acceso inmediato y eficaz de sus datos que se usan más frecuente.

ƒ

Mejora la fiabilidad si la computadora de un sitio se cae, el resto de la red sigue funcionando.

ƒ

Permitir el control local de los datos en un sitio mejora el grado de satisfacción de los usuarios con relación al sistema de BD.

ƒ

Cuando cada sitio procesa sus datos locales se elimina un poco el tráfico de la red, pero si los sitios usan frecuentemente datos almacenados en otros sitios las comunicaciones pueden convertirse en un cuello de botella.

Un sistema gestión de bases de datos distribuida no es más que el software que permite la administración de la base de dato distribuida y hace que tanto como la distribución y el control de concurrencia de las transacciones, las fallas, sean transparente para el usuario que opera con el sistema. Un SBDD está formado por una colección de sitios, cada uno de los cuales opera un sistema de bases de datos para el procesamiento de las actividades que solo requieran datos locales. Los SGBDD están compuestos por varios SGBDs operando en sitios locales y que están conectados mediante la trasmisión de mensajes, transacciones, datos desde el sitio local hacia remostos y viceversa, etc.

Arquitectura Distribuida de base de datos. La tecnología y prototipo de los sistemas de gestión de bases de datos distribuidas se han desarrollado de uno a otro y cada sistema adopta una arquitectura particular propia.

4

Nodo W

ABDW

BDw

ATX

ABDx

BDX

ATY

ABDY

Nodo X Programa de consulta o transacción Nodo Y Programa de consulta o transacción

BDY

Nodo X DDB Programa de consulta o transacción

ATZ

Interfaz de solicitud

Interfaz de acción SGBDD

Fig 1. Arquitectura de Bases de Datos Distribuidas.

En la figura 1 mostramos un sistema de base de datos distribuida donde participan 4 computadoras. El nodo W es un nodo de bases de datos ejecutando un administrador de datos DBMW y almacenando la BDW. El nodo X es tanto nodo de transacción como de base de datos ejecutando un administrador de transacciones DTMX y un administrador de base de datos DBMX almacenado BDX, el nodo Y de forma similar es tanto un nodo de transacciones, como de datos ejecutando DTMY, DBMx y almacenando la BDY, pero el nodo Z es solo de transacciones ejecutando DTMZ. La independencia de los datos puede entenderse como la fortaleza de las aplicaciones ante los cambios que pueda tener la estructura lógica de almacenamiento de los datos y la ubicación física de los mismos. En las bases de datos distribuidas la redundancia es necesaria por varios motivos, entre los cuales se encuentran:

5

1. Los datos deben estar localizados lo más cerca posible de los sitio donde sean utilizado, es decir, utilizando réplicas de los datos. 2. Aumenta la disponibilidad del sistema. Las transacciones son unidades de la ejecución ACID que terminan exitosamente o abortan. Programadores de aplicación, administradores recurso, y administradores de la transacción cooperan para llevar a cabo las propiedades del ÁCID. Miremos el papel de cada una de estas propiedades participantes. Atomic (Atomicidad) Si una transacción completa exitosamente, sus efectos son durables, en caso contrario la transacción aborta y sus efectos se deshacen (rollback). Por ejemplo, cuando actualizamos un registro, el registro cambia de valor y el antiguo valor se anula (cuando termina exitosamente), o no cambia nada (cuando aborte). Consistency (Consistencia) Una transacción es una transformación correcta del estado del sistema. Una transacción producirá siempre los mismos resultados si se aplican más de una vez (es decir, deben ser consistentes y reproducibles). Por ejemplo, cuando agregando un elemento a una lista doblemente enlazada, los cuatro indicadores (dos delanteros y los dos dirigidos hacia atrás) son puestos al día. Isolation (Aislamiento). Se aíslan transacciones concurrentes de las actualizaciones de otras transacciones incompletas. Estas actualizaciones no constituyen un estado consistente, los datos deben protegerse de cambios hasta haber completado la transacción a través de todos los nodos. Esta propiedad es llamada a menudo seriabilidad. Por ejemplo, una segunda transacción, cruzando la lista doblemente enlazada mencionada en el ejemplo de consistencia, verá la lista antes o después de la inserción, pero solo verá cambios completos. Durability (Durabilidad) Una vez una transacción completa exitosamente, sus efectos persistirán aun cuando hay fracasos del sistema. Por ejemplo, después de la actualización en el ejemplo de atomicidad, el registro tendrá el nuevo valor aun cuando el sistema falla y cuando el sistema se inicie nuevamente se corrigen después de haber completado la transacción comprometa completa. Hoy esta tecnología muestra sus limites y los grandes vendedores de bases de datos (Oracle, Infomix, Sysbase), a fin de satisfacer las necesidades emergentes de negocio, hacen posible otro adelanto tecnológico en la gestión de bases de datos. Este enfoque relativamente nuevo usualmente se conoce bajo términos como: Almacenaje de Datos, Repetición, DSS-R (Sistemas de apoyo de DecisiónRepetición).

6

Los sistemas de datos distribuidos se dividen en dos tipos basados en filosofía totalmente diferentes[3]: Sistemas de gestión de bases de datos distribuidas homogéneas. Sistemas de gestión de bases de datos distribuidas heterogéneas. SGBDD homogéneos: Un DDBMS homogéneo tiene recaudos múltiples de datos; integra recursos múltiples de datos. Las bases de datos distribuidas homogéneas son similares a las bases de datos centralizadas, pero en vez de almacenar todos los datos en un sitio, los datos se distribuyen en diferentes sitios de una red. Si nosotros queremos partir de una arquitectura conceptual estándar para los DDBMS, debemos conocer que partir de la arquitectura de ANSI-SPARC, nosotros podríamos incluir un DBMS local y esquemas locales recordando que estos no tienen que estar explícitamente presentes en ninguna implementación particular. Para manejar la distribución de otros aspectos, nosotros debemos agregar dos niveles adicionales, a la arquitectura estándar tercer - nivel ANSI-SPARC, los que nombramos fragmentación y localización de schemas. SGBDD heterogéneos: Esta clase se caracteriza por el uso de diferentes DBMS en los nodos locales. Hay dos subclases principales: los que hacen su integración totalmente dentro del sistema, y los más simples “hooks” o los apéndices externos llamados gateways, para permitir enlace a sistemas ajenos. La anterior subclase puede ser adicionalmente refinada en una subclase que provee un subconjunto importante de funciones que uno esperaría desde cualquier SGBD, y que enfatiza en los aspectos más pragmáticos del manejo de datos colectivos , tales como conversiones entre sistemas y algún aspecto básico de desempeño(sistemas multidatabase). Los sistemas multidatabase (SGBDMs) tienen múltiples SGBD, posiblemente de diferentes tipos, y múltiples, DBs preexistentes. La integración es desempeñada por lo tanto por múltiples software de subsistemas.

Ventajas en la arquitectura de las BDD. ƒ

Expandibilidad Al crecer una organización por la adición una nueva unidad, el nuevo nodo o unidad de localización de dato pasa a formar parte de la base de datos distribuida sin reconfigurar la BD completamente – el nuevo nodo casi automáticamente forma parte de la BD global.

ƒ

Confiabilidad o Disponibilidad. Fácil conexión entre los datos de varias localizaciones sin tener en cuenta los Sistemas Operativos y/o el hardware y software utilizados. La capacidad que tiene el sistema para seguir trabajando, a pesar del fallo de una localidad, da como resultado una mayor disponibilidad. Para aplicaciones

7

ƒ

de solo – lectura si se almacenan múltiples copias de la misma información de forma que el sistema tenga alternativas de solución para asegurar que siempre alguna de ellas esté disponible. La disponibilidad es fundamental para los sistemas de base de datos que se utilizan en aplicaciones de tiempo real. Por ejemplo, si una línea aérea no puede tener acceso a la información, es posible que pierda clientes a favor de la competencia. Flexibilidad. Al realizar un movimiento en un dato de un lugar a otro o algún cambio en una localización física de ciertos nodos requeridos no hay que realizar cambios en la BD o su arquitectura.

ƒ

Distribución de la carga de trabajo: La distribución de la carga de trabajo sobre los sitios se hace sobre la base de utilizar la potencia de las computadoras de cada sitio y maximizar paralelismo en la ejecución de las aplicaciones. Como que la distribución de la carga puede afectar la localidad del procesamiento, es necesario correlacionar ambos objetivos.

ƒ

Sharing o Compartición. Los datos pueden ser compartidos por sucursales o usuarios diferentes de la misma organización u organizaciones diferentes, permitiendo así comunicación eficiente entre usuarios distantes. La ventaja principal de compartir los datos por medio de la distribución es que cada localidad puede tener mejor control de sus datos almacenados localmente. En los sistemas centralizados existe un administrador global de la base de datos, mientras que en un SBDD existe un administrador global de base de datos que se descompone en los administradores de base de datos locales donde reside cada base de datos. Dependiendo del diseño del sistema distribuido, cada administrador de base de datos local podrá tener un grado de autonomía diferente, que se conoce como autonomía local. La posibilidad de contar con autonomía local es en muchos casos una ventaja importante de las bases de datos distribuidas.

ƒ

Confiabilidad. La confiabilidad se logra al tener replicas de los datos, pues es posible recuperar una copia dañada o destruida a partir de otra. Por supuesto, que como los daños pueden obedecer a catástrofes físicas, deben tenerse copias en lugares geográficamente separadas.

ƒ

Razones económicas. Cuando se maximiza el acceso local de las aplicaciones a los datos se disminuye el tráfico en las comunicaciones. Hoy en día podemos adquirir computadoras personales a precios considerados, comparado con el equivalente a una supercomputadora o MainFrame.

Desventajas de BDD.

8

ƒ

Complejidad. Un sistema distribuido, que oculta su naturaleza distribuida al usuario, es más complejo que el sistema centralizado. Las consideraciones adicionales tales como el control de concurrencia y la seguridad deberían tenerse en cuenta, no para mencionar la complejidad alta de la optimización de consultas, comparado con una base de datos centralizada, sino que las actualizaciones se complican proporcionalmente con el aumento de replicas en el sistema.

ƒ

La confiabilidad /Eficiencia. Se deben implementar mecanismos que garanticen la consistencia y permitan detectar fallas en el sistema y su posterior recuperación. Al ocurrir alguna falla en sitios distintos, el sitio que contenga una réplica de esa base de datos, y además sea operable debe garantizar la consistencia y actualización de su base de datos. Al reponerse los diferentes sitios el sistema de gestión de base de datos debe granizar la actualización de esos sitios que estaban sin operar. AL estar particionada la red que une los diferentes sitios es un poco más difícil garantizar las actualizaciones de las bases de datos. Puesto que las localidades del sistema distribuido operan en paralelo, es más difícil garantizar que los algoritmos sean correctos. Existe la posibilidad de errores extremadamente sutiles. (Profundizar)

ƒ

Mayor tiempo extra de procesamiento. El intercambio de mensajes y los cálculos adicionales que se requieren para coordinar las localidades son una forma de tiempo extra que no existe en los sistemas centralizados.

ƒ

Costo. La complejidad aumentada significa que los costos de mantenimiento y adquisición del sistema son mucho más altos que los de un DBMS centralizado. La capacidad de almacenamiento de cada sitio debe tenerse en cuenta, usualmente el costo de almacenamiento no es importante comparado con otros costos, no obstante, las limitaciones de almacenamiento deben ser consideradas.

ƒ

Aumento del trafico de comunicación. Cuando un sitio accede frecuentemente a los datos de otros sitios, aumenta el tráfico de mensaje y transacciones en la red, y por tanto las comunicaciones, lo que puede convertirse en un cuello de botella.

ƒ

Integridad. Debido a que no todos los datos se ubican en un lugar centralizado - una estación (nodo) - el fracaso podría ocasionar una pérdida de datos para otros nodos.

9

Los usuarios interactúan con los SGBDD mediante transacciones. Cada transacción comunica solo sus lecturas y escrituras a un único administrador de transacciones, el AT recibe solicitudes de procesamiento de consulta o de transacciones y las traduce en acciones para el planificador, este comunica cada lectura y escritura al planificador. La selección del planificador se determina por un algoritmo de control concurrente, aunque el planificador que se escoge más a menudo está en el mismo sitio que los datos que se están operando. El AD puede ser un subconjunto de un producto SGBDD, este ejecuta cada lectura y escritura que recibe. Para cada lectura el AD recorre su base de datos local y retorna el valor solicitado. Para cada escritura el AD modifica la BD y retorna un reconocimiento al planificador que lo envía de regreso al AT y este a la transacción. El planificador controla la secuencia según la cual los administradores de datos (ADs) procesan las órdenes de lectura y escrituras y mantiene el control de las comunicaciones.

Diseño de un sistema de bases de datos distribuidas A los problemas que presentamos en el diseño de las Bases de Datos Centralizadas(BDC) se le añaden otros nuevos cuando diseñamos Bases de Datos Distribuidas(BDD) entre los cuales se destacan la distribución óptima de datos y de las aplicaciones en los diferentes sitios. Cuando pensamos en el diseño de las bases de datos distribuidas debemos tener en cuenta la ubicación de los programas que accederán a las bases de datos y sobre los propios datos que constituyen la base de datos, en diferentes puntos de una red. Sobre la ubicación de los programas supondremos que tenemos una copia de ellos en cada maquina donde se necesite acceder a la base de datos. Sin embargo el problema radica en como ubicaremos los datos en la red, existen diferentes formas de repartir los datos: En solo una maquina que almacene todos los datos y se encargue de responder a todas las consultas del resto de la red (sistema centralizado), ubicaríamos la base de dato en cada maquina donde se utilice, o pensaríamos en repartir las relaciones por toda la red. La organización de los sistemas de bases de datos distribuidos se ha clasificado tradicionalmente sobre el nivel de compartición, características de acceso y nivel de conocimiento de los datos: 1. Inexistencia. Los datos y programas se ejecutan en un ordenador sin que exista comunicación entre ellos. 2. Se comparten datos y no programas.

10

Existe una réplica de los programas de aplicación en cada maquina y los datos viajan a través de la red. 3. Se comparten datos y programas. Los datos y programas se reparten por los diferentes sitios de la red, dado un programa ubicado en un determinado sitio puede acceder a un servicio a otro programa de segundo sitio solicitando acceder a los datos ubicados en un tercero. Duplicación de los datos. La duplicación de los datos ocurre si el sistema mantiene varias copias de una relación, R, con cada copia almacenada en un sitio diferente. Existen dos modelos básicos de replica: 1. Consistencia estrecha. Este modelo que garantiza que todas las réplicas sean constantemente idénticas a la original, requiere una red de alta velocidad, disminuye la disponibilidad de la base de datos[5]. 2. Consistencia ancha. El modelo de consistencia ancha permite un retardo entre el momento en que los datos originales son modificados y las copias de los mismos son actualizadas, lo que permite que la base de datos esté disponible más tiempo que el modelo de consistencia estrecha. Permite conexiones tanto rápidas como lentas soportadas en WANs o LANs. La duplicación se introduce para aumentar la disponibilidad del sistema: cuando una copia no está disponible debido a un fallo de un sitio sería posible tener acceso a otra copia. Con la duplicación también se mejora el rendimiento puesto que las transacciones tienen mayor probabilidad de encontrar una copia localmente. El inconveniente está en el costo extra del almacenamiento adicional y del mantenimiento de la consistencia mutua entre las copias cuando tenemos replicación. Réplica en SQL Server 6.5. La réplica en SQL Server se basa en un modelo de consistencia ancha. Con la duplicación, se puede distribuir automáticamente copias de transacciones de datos desde un servidor fuente a uno o varios servidores destinos o a una o varias localizaciones remotas. La duplicación en SQL Server 6.x está basada en el log de transacciones: las transacciones son marcadas como duplicación, estas leen el log de transacciones de la base de datos fuente y aplican lo ocurrido en la base de datos destino. La duplicación usa terminología que es basada en una metáfora de publicación/subscripción. La duplicación emplea servidores en tres papeles diferentes: publicador, distribuidor, y subscriptor.

11

Servidor de publicación. Servidor que contiene la base de datos que se va a replicar, también almacena la base de datos de publicación, hace los datos públicos desde las bases de datos disponibles para replicar, envía copias de todos los cambios a los datos públicos para el servidor de distribución[5]. Servidor de distribución. Este servidor almacena la base de datos de distribución, recibe los cambios de los datos públicos, almacena los cambios en su base de datos de distribución y trasmite los cambios a los servidores de subscripción. La computadora que hace la función de servidor de subscripción puede ser o no también servidor de publicación[5]. Servidor de suscripción. Servidor que mantiene las bases de datos destinos, recibe y mantiene copias de datos públicos[5]. Los servidores de publicación y subscripción no son exclusivos, este es el caso en que una computadora almacena la BD original X y una copia de la DB Y, y a su vez tenemos otra computadora que su BD original es Y, y también posee una copia de la BD X. La duplicación en bases de datos SQL Server dedicadas utilizan una cola fiable para los datos duplicados, también ofrece flexibilidad en los datos seleccionados para la réplica en todas las bases de datos destino. Y, incrementa la seguridad, limitando que los usuarios pueden preparar y administrar duplicación, y qué los servidores destino pueden ver y recibir tablas que estén disponibles para ser duplicadas. Los movimientos de los datos duplicados se realizan en una dirección del publicador al subscriptor. El proceso de lectura del log mueve las transacciones que son marcadas para la duplicación del log de transacciones del publicador a la base de datos del distribuidor, donde las transacciones esperan por la distribución a los subscriptores. El proceso de la sincronización prepara archivos de sincronización iniciales que contienen la tabla de esquema y datos publicados, almacena los archivos en el directorio de trabajo del distribuidor del Servidor de SQL, y en el registros de trabajos de sincronización en la base de datos de la distribución. La sincronización sólo afecta a los nuevos subscriptores[6]. Los movimientos de proceso de distribución de las transacciones y los trabajos de la sincronización iniciales que se mantienen en la tabla de la base de datos de distribución a los subscriptores. Para abordar el diseño de las bases de datos distribuidas podemos optar por dos tipos de estrategias: Bottom – Up y. Ambas no son excluyentes, es decir que cuando estemos trabajando en un determinado proyecto podemos usar en diferentes partes del mismo una u otra estrategia. La estrategia Bottom – Up se puede utilizar sistemas ya instalados con pequeñas bases de datos existentes con el fin de integrarlas en una única BDD. Este problema se nos presenta en BD *heterogéneas. En la vida real este caso se nos puede presentar con facilidad,

12

pero se prefiere partir de cero y se avanza en el desarrollo del trabajo siguiendo la estrategia Top – Down. En la estrategia Top – Down es adecuada cuando creamos un sistema de BD por vez primera sin restricciones de otros sistemas ya instalados y que deban ser integrados al sistema distribuido, es decir, primero elaboramos el esquema conceptual global del proyecto y trabajamos en función de resolver las diferentes parte de dicho proyecto. Proceso de Diseño Top – Down. Un esquema de este proceso puede observarse en la siguiente figura: Análisis de requerimientos

Objetivos del sistema

Diseño conceptual

Diseño de las vistas

Información sobre Accesos

Esquema conceptual global

Diseño de la distribución

Esquemas conceptuales locales

Diseño físico

Esquema físico

Observación y monitoreo

El diseñó de una BDD involucra 4 pasos: 1. Diseño del esquema conceptual donde se describe la BD integral.

Esquema Externo

13

2. Diseño de fragmentación. 3. Diseño de la asignación de los fragmentos. 4. Diseño de la BD física (transformar los esquemas locales en áreas de almacenamiento y determinar métodos de acceso apropiados). La fragmentación y asignación de los datos caracterizan el diseño de BDD. La fragmentación se ocupa fundamentalmente de los criterios lógicos que motivan la división de relaciones globales en fragmentos, mientras que la asignación se ocupa de los aspectos físicos de su ubicación y réplicas en sitios; aunque hay una diferencia entre ambos procesos, su interrelación es importante para obtener un diseño óptimo. En caso que también se distribuyan las aplicaciones debemos tener en cuenta el diseño de los esquemas, los requerimientos más importantes de las aplicaciones tenemos las siguientes: 1. Sitio que comparte una aplicación. 2. Frecuencia de activación de la aplicación 3. Cantidad, tipo y distribución estadística de los accesos de cada aplicación a cada dato requerido. En el diseño de un sistema de bases de datos distribuidas debemos tener en cuenta algunas estrategias y objetivos y se deben en paralelo tomar decisiones sobre cómo hay que distribuir los datos entre los sitios de la red.

Estrategias y objetivos. Desde el punto de vista conceptual la transparencia en un sistema de gestión de bases de datos distribuida se refiere a la división del nivel semántico y la implementación del sistema. El objetivo de la transparencia es ocultar al usuario los detalles de diseño, es decir, el usuario no tiene conocer que se encuentra trabajando sobre un sistema distribuido, y menos como se encuentra distribuidos los dato del sistema. El nivel de transparencia tiene que garantizar un compromiso en dos extremos: la facilidad de uso y el grado de dificultad más el costo de proporcionar un alto nivel de transparencia. Los objetivos que son comunes en la implementación de los sistemas de bases de datos distribuidas son los siguientes: Transparencia de ubicación. Permite a los usuarios acceder a los datos sin tener en cuenta la ubicación de los mismos. Esta transparencia se puede conseguir cuando los administradores de transacciones distribuidas (ATD) son capaces de determinar la localización de los datos y de emitir acciones a los ADs apropiados, lo cual puede ejecutarse cuando los ATs poseen acceso a los directorios de localizaciones de los datos. Si los datos cambian de lugar, solo el ATs necesita

14

conocer lo ocurrido. Todas las transacciones ignoran la modificación en la localización. Transparencia de duplicación. Para que la transparencia de duplicación sea posible, los administradores de transacciones deben traducir las solicitudes de procesamiento de transacción en acciones para el administrador de datos. Para las lecturas el ATs selecciona uno de los nodos que almacena los datos y ordena la lectura. Para facilitar esta selección el ATs debe conservar estadísticas sobre el tiempo que se requiere para leer datos de varios nodos, y seleccionar el de mejor rendimiento. La escritura de datos duplicados suelen ser más complicadas, porque el ATs debe emitir una acción de escritura para cada uno de los ADs que almacena una copia de dichos datos. Para mayor información ver la sección de log de transacciones de SQL Server. Las actualizaciones afectan las columnas que tienen datos de longitud variable o nulos, esto se puede resolver combinando los DELETES y INSERT, aun cuando la longitud física de los datos no varia. En SQL Server para Windows NT ahora se ejecutan todas las actualizaciones sin modificar el tamaño físico de los datos, a pesar que el tipo de dato sea afectado Transparencia de concurrencia. Cuando múltiples transacciones que involucre la base de datos distribuida se ejecuten al mismo tiempo, los resultados de las transacciones no deberán afectarse. La trasparencia de concurrencia se logra si los resultados de todas las transacciones concurrentes son consistentes de manera lógica con los resultados que se habrían obtenido si las transacciones se hubieran ejecutado una por una, en un orden serial arbitrario. Transparencia de fallas. Significa que a pesar de fallas en la transacción, en el SGBDD, en la red y en la computadora, las transacciones sean procesadas de un modo correcto. Frente a una falla, las transacciones deben ser atómicas, significa que se procesen todas o ninguna de ellas. Para este tipo de problemas es importante tener resguardo(Backup) de la base de datos, y así poder restaurarla cuando sea conveniente. El sistema debe detectar cuándo falla una localidad y tomar las medidas necesarias para recuperarse del fallo. El sistema no debe seguir utilizando la localidad que falló. Por último, cuando se recupere o repare esta localidad, debe contarse con mecanismos para reintegrarla al sistema con el mínimo de complicaciones. En un SBDD pueden surgir uno o varios problemas imprevistos, los cuales hay que solucionar de inmediato, de modo que la afectación de la disponibilidad del sistema sea mínima. Dentro de estos problemas encontramos los siguientes: ™ Fallo de disco. Cuando una o más de las unidades de disco donde se almacena la base de datos falla, nos encontramos ante una pérdida completa de los datos, esto se puede resolver, restaurando la base de datos con el respaldo más actualizado.

15

™ Errores del usuario En caso que un usuario o una determinada aplicación haga un gran número de modificaciones inválidas involuntariamente o malévolamente a los datos, la mejor manera de resolver este problema puede ser restaurar los datos en el punto antes de que se efectuaran estas modificaciones. ™ Pérdida permanente de un servidor. Cuando un servidor queda fuera de servicio, ya sea por rotura o por alguna otra razón es necesario activar un servidor de reserva o restaurar una copia de la base de datos en otro servidor.

Localidad del procesamiento. Los datos se deben distribuir lo más cerca posible de las aplicaciones que los usan para maximizar la localidad del procesamiento, este principio responde a minimizar el acceso remoto a los datos. Diseñar una distribución que maximice localidad del procesamiento puede hacerse añadiendo la cantidad de referencias locales y remotas correspondientes a cada fragmentación candidata y asignar la fragmentación eligiendo la mejor solución. Independencia de configuración. La independencia de configuración permite añadir o reemplazar hardware sin tener que cambiar componentes de software existentes en el SGBBD. SGBDD no homogéneos. Posibilita integrar bases de datos mantenidas por diferentes SGBDD sobre computadoras diferentes. Existen numerosos SGBDD que son suministrados por diferentes fabricantes. Para solucionar este problema se realizó esta amplia interfaz Particionamiento de la Base de Datos. La base de datos se distribuye de modo que no haya solapamiento o duplicación de los datos mantenidos en las diferentes localidades, como no hay duplicaciones de los datos, se evitan los costos asociados con el almacenamiento y mantenimiento de datos redundantes. Si un mismo segmento de datos se usa en más de una localidad se ve limitada la disponibilidad de los datos. La fiabilidad también puede verse limitada cuando se produce un fallo en el sistema de cálculo de una localidad se afecta la disponibilidad de los datos de esa localidad no estén disponible para los usuarios en cualquier parte del sistema. Fragmentación de datos. Consiste en subdividir las relaciones, figura 3a y distribuirlas entre los sitios de la red, tiene como objetivo buscar formas alternativas de dividir una las instancias (tablas) de relaciones en otras más pequeñas. La fragmentación se puede realizar por tuplas individuales (fragmentación horizontal), por atributos individuales (fragmentación vertical) o una combinación de ambas (fragmentación híbrida)

16

El principal problema de la fragmentación radica en encontrar la unidad apropiada de distribución. Una relación no es una buena unidad por muchas razones. Normalmente las vistas de una relación están formadas por subconjuntos de relaciones. Además, las aplicaciones acceden localmente a subconjuntos de relaciones. Por ello, es necesario considerar a los subconjuntos de relaciones como unidad de distribución. Al descomponer de una relación en fragmentos, tratados cada uno de ellos como una unidad de distribución, permite el proceso concurrente de las transacciones. El conjunto de estas relaciones, provocará la ejecución paralela de una consulta al ser dividida en una serie de subconsultas que operará sobre los fragmentos. Cuando las vistas definidas sobre una relación son consideradas como unidad de distribución que se ubican en diferentes sitios de la red, podemos optar por dos alternativas diferentes: La relación no estará replicada y se almacena en un único sitio, o existe réplica en todos o algunos de los sitios en los cuales reside la aplicación. Las consecuencias de esta estrategia son la generación de un volumen de accesos remotos que pueden ser innecesarios con un mal manejo de estas replicas. Además, las réplicas innecesarias pueden causar problemas en la ejecución de las actualizaciones y puede no ser deseable si el espacio de almacenamiento está limitado. Los inconveniente de la fragmentación están dados en que si las pueden estar definidas por fragmentos mutuamente exclusivos y al recuperar los datos de dos fragmentos situados en sitios diferentes es necesario trasmitir los datos de un sitio a otro y realizar sobre ellos la operación de unión (Join), lo cual puede ser costoso. El control semántico cuando los atributos implicados en una dependencia una relación se descompone en diferentes fragmentos y estos se ubican en sitios diferentes puede ser muy costos porque es necesario hacer búsquedas en un gran número de sitio. Fragmentación horizontal. La fragmentación horizontal es la división en tuplas de una relación en fragmentos, vea figura 3c. Estos fragmentos pueden ser disjuntos y pueden estar duplicados. Del concepto la fragmentación horizontal se desprende el de fragmentación horizontal primaria (FHP) utilizando predicados definidos en la relación y el de fragmentación horizontal derivada (FHD) que resulta de los predicados definidos en otra relación[8]. Fragmentación vertical. Es la división de un conjunto de atributos de un objeto en subconjuntos que pueden solaparse, figura 3b. Cuando se proyecta la relación original sobre un conjunto de atributos se obtienen los fragmentos. Fragmentación mixta. Es el resultado de aplicar los dos tipos fragmentaciones mencionados anteriormente, este tipo de fragmentación puede llevarse a cabo de tres formas diferentes:

17

1. Es el resultado de aplicar la fragmentación vertical y, posteriormente el fraccionamiento horizontal sobre los fragmentos verticales (denominada VH), figura 3e. 2. Es el resultado de realizar la división horizontal, para posteriormente aplicar sobre los fragmentos generados la fragmentación vertical (llamada HV) figura 3d. 3. Este enfoque es relativamente nuevo [2] consiste en aplicar de forma simultánea, y no secuencial sobre una relación, la fragmentación horizontal y la vertical; en este caso, se generara una rejilla y los fragmentos formaran las celdas de esa rejilla, cada celda será exactamente un fragmento vertical y un fragmento horizontal (nótese que en este caso el grado de fragmentación alcanzado es máximo, y no por ello la descomposición resultará más eficiente) figura 3f.

a) Relación R

d) Fragmentación HV

b) Fragmentación Vertical

c) Fragmentación Horizontal

e) Fragmentación VH

f) Celdas

Figura 3. Distintos tipos de fragmentación Reglas de corrección de la fragmentación. A continuación se enuncian tres reglas que se deben cumplir durante el proceso de fragmentación, estas asegurarán que no se produzcan cambios semánticos en la base de datos durante el proceso. 1. Compleción. Al decomponerse una relación Si una relación R en una serie de fragmentos R1, R2, ..., Rn, cada elemento de datos que pueda encontrarse en R deberá poder encontrarse en uno o varios fragmentos Ri. Esta propiedad

18

extremadamente importante asegura que los datos de la relación global se proyectan sobre los fragmentos sin pérdida alguna. Es necesario aclarar que en el caso de la fragmentación horizontal los elementos o fragmentos son tuplas, mientras que en el caso vertical los fragmentos o elementos de datos son atributos. 2. Reconstrucción. Si una relación R se descompone en una serie de fragmentos R1, R2, ..., Rn, puede definirse un operador relacional ∇ tal que R = ∇ Ri, ∀Ri ∈ FR El operador ∇ será diferente en dependencia de la forma de fragmentación. La reconstrucción de la relación a partir de sus fragmentos asegura la preservación de las restricciones definidas sobre los datos en forma de dependencias. 3.

Disyunción. Esta regla garantiza que cuando una relación R se descompone en fragmentos R1, R2, ..., Rn, horizontales y un elemento de datos di se encuentra en algún fragmento Rj, entonces no se encuentra en otro fragmento Rk (k ≠ j). Esta regla asegura que los fragmentos horizontales sean disjuntos. Si una relación R se descompone verticalmente, sus atributos primarios clave normalmente se repiten en todos sus fragmentos.

Alternativas de asignación Partiendo de que la base de datos ha sido fragmentada correctamente, es necesario ubicar los diferentes fragmentos en varios sitios de la red, una vez que los fragmentos son asignados es necesario pensar en la posibilidad de duplicar algunos de ellos para mantener una copia. Las razones para mantener varias copias están en lograr incrementar de la seguridad, mayor disponibilidad, mayor paralelismo, mayor independencia de las unidades de procesamiento, menor tráfico de datos en la red. Las solicitudes de actualizaciones se complican un poco ya que el sistema tiene que asegurar que todas las copias de los datos se actualicen garantizando que sean consistentes. Por otra parte, la ejecución de consultas de actualización, de escritura, implicaría la actualización de todas las copias que existan en la red, cuyo proceso puede resultar problemático y complicado. Por tanto, un buen parámetro para afrontar es el grado de réplica, que consistiría en sopesar la cantidad de consultas de lectura que se efectuarán, así como el número de consultas de escritura que se llevarán a cabo. En una red donde las consultas que se procesen sean mayoritariamente de lectura, se podría alcanzar un alto grado de réplica, no así en el caso contrario. Con respecto a la duplicación de fragmentos se pueden seguir tres tendencias básicas:

19

1. Un extremo es replicar la base de datos completamente en cada sitio del

sistema distribuido, en este caso la base de datos distribuida estaría completamente replicada. En este caso se mejora la disponibilidad e incrementa rapidez de las recuperaciones para solicitudes globales, pero retrasa drásticamente las operaciones de actualización y encarece los métodos de control de concurrencia y recobrado. 2. El otro extremo se refiere a las bases de datos no replicadas; o sea, cada

fragmento es asignado a solo un sitio. En este caso todos los fragmentos deben ser disjuntos, excepto para la réplica de la llave primaria en la fragmentación vertical o mixta. Esta variante también se nombra localización no redundante. 3. En las bases de datos parcialmente replicada algunos de los fragmentos de la base de datos son replicados, se ubicaran copias de algunos fragmentos en diferentes sitio de la red. En la figura 4 se muestra las tres alternativa de réplicas con respecto a distintas funciones de bases de datos distribuido Réplica total

Réplica Parcial

No Replicada

Procesamiento de Consultas

Fácil

Dificultad similar

Manipulación de Directorios

Fácil o inexistente

Dificultad similar

Control de Concurrencia

Moderado

Difícil

Fácil

Seguridad y confiabilidad

Muy alta

Alta

Baja

Aplicación

Posible

Real

Posible

Figura 4. Comparación entre las alternativas de réplicas. Fragmentación de los Datos. Para ejemplicar los diferentes tipos de fragmentación tomamos las siguientes relaciones:

Id_Estudiante E1 E2 E3 E4

Relación Estudiantes Nombre_E Dirección Pablo Peña C/ maceo no 33 Enrique Ortega C/ martí no 45 Juan Escobar C/ 39 no 34 Miguel Suárez Edif. 23 apto 5

Edad 19 22 21 20

20

E5

Id_Profesor P1 P2 P3 P4 P5

Pedro Alcina

C/ maceo no 21

Relación Profesores Nombre_P Facultad Pedro R. Cont Alicia A. Cont Juan R. Agro Enrique M. Agro Edecio P. CF

Relación Asignaturas Id_Asignatura Nombre_Asignatura AM1 Análisis Matemático 1 CC Contabilidad de Costos NA Nutrición Animal HC Horticultura VB Voleibol

Id_Grupo 1ro Agro 4to Agro

Relación Grupos Nombre_Grupo 1er año Agronomía 4to año Agronomía

3ro Cont

3er año Contabilidad

2do Cont

2do año Contabilidad

1ro CF

1er año Cultura física

18

Salario 380.00 340.00 380.00 360.00 330.00

Relación Imparte Id_Asignatura Id_Profesor Id_Grupo AM1 P1 1ro Cont CC P2 2do Cont NA HC VB

Facultad Agronomía Agronomía Contabilidad y Finanzas Contabilidad y Finanzas Cultura Física

P3 P4 P5

3ro Agro 4to Agro 1ro CF

Relación Pertenece Id_Estudiante Id_Grupo E1 1ro Agro E2 4to Agro E3

3ro Cont

E4

2do Cont

E5

1ro CF

Figura 5. Relaciones de las bases de datos empleadas para los ejemplos. Este esquema de fragmentación es ventajoso porque proporciona pequeños tiempos de respuesta y bajo costo de procesamiento para solicitudes locales, lo que se justifica porque existen grandes sistemas (por ejemplo dentro de las universidades tenemos, facultades, bibliotecas, etc.) que por sus estructuras es conveniente aplicar la una fragmentación horizontal debido a la complejidad y tamaño de sus. Su principal objetivo es producir fragmentos con máxima localidad respecto a las aplicaciones. Para la fragmentación necesitamos tanto información cualitativa como cuantitativa. La información cualitativa guiará la fragmentación, mientras que la cuantitativa se necesitará en los modelos de asignación. La principal información de carácter

21

cualitativo esta basada en las consultas generadas por los usuarios y las aplicaciones. Debemos investigar cuales son las principales aplicaciones en caso que no fuese posible investigarlas todas para determinar estos predicados. Para guiarnos en este análisis nos podemos auxiliar en la regla de que el xx% de las consultas acceden al yy% de los datos. Llegados a este punto, sería interesante determinar los predicados simples. Dada una relación R(A1, A2, ..., An), donde Ai es un atributo definido sobre el dominio Di, un predicado simple pj definido sobre R es de la forma pj : Ai θ Valor donde θ es un operador relacional y Valor se escoge de entre el dominio de Ai. Usaremos Pri para notar al conjunto de todos los predicados simples definidos sobre una relación Ri. Los miembros de Pri se notan por pij. Ejemplo F1. En la relación Profesores de la figura 5, podemos definir como predicados simples los siguientes: p1: Facultad = “Agro” p2: Salario ≥ 360.00 También podemos formar predicados complejos que estarían formados por combinaciones booleanas de predicados simples. Se obtiene como predicado mintérmino a la conjunción de los predicandos simples tanto en su forma natural como negada. Partiendo de que siempre es posible transformar una expresión lógica en su forma normal conjuntiva, usaremos los predicados mintérmino en los algoritmos para no causar ninguna pérdida de generalidad. Dado un conjunto de predicados simples de una relación R, Pri = {pi1, pi2, ..., pim}, el conjunto de predicados mintérmino Mi = {mi1, mi2, ..., miz} se define como

M i = {mij | mij =

∧

p * ik },1 ≤ k ≤ m,1 ≤ j ≤ z

pik ∈Pri

donde p ik = pik o p ik = ¬pik. Es decir, cada predicado mintérmino puede ser igual a la forma natural o a la forma negada del predicado simple. Es importante señalar que la referencia a la negación de un predicado es significativa para predicados de igualdad de la forma *

*

Atributo = Valor Cuando se trata de predicados de desigualdad la negación es complemento del predicado del predicado simple. ¬(Atributo ≤ Valor)

es

Atributo > Valor

22

En caso de que los predicados sean de la forma Límite_inferior ≤ Atributo_1 ≤ Límite_superior Esto se traduce como Límite_inferior ≤ Atributo_1 Atributo_1 ≤ Límite_superior Y sus complementos son

¬(Límite_inferior ≤ Atributo_1) ¬(Atributo_1≤ Límite_superior) Que se traduce como: ¬( Límite_inferior ≤ Atributo_1 ≤ Límite_superior) Ejemplo F2: Dada la relación Profesores de la figura 5 tomaremos una muestra de los predicados simples definidos como: p1: Facultad = “Cont” p2: Facultad = “Agro” p3: Salario ≤ 360.00 p4: Salario ≥ 380.00 Los predicados definidos anteriormente tienen como significado la pertenencia de los profesores a las facultades Cont y Agro, así como los profesores con salarios menores o iguales 360.00 y mayores o iguales a 380.00. Podemos definir los siguientes predicados mintérminos: m1: (Facultad=“Cont”) ∧ (p3: Salario ≤ 360.00) m2: (Facultad=“Cont”) ∧ (p3: Salario ≥ 380.00) m3: ¬ (Facultad=“Cont”) ∧ (p3: Salario ≤ 360.00) m4: ¬ (Facultad=“Cont”) ∧ (p3: Salario ≥ 380.00) m5: (Facultad=“Agro”) ∧ (p3: Salario ≤ 360.00) m6: (Facultad=“Agro”) ∧ (p3: Salario ≥ 380.00) m7: (Facultad=“Agro”) ∧ ¬ (p3: Salario ≤ 360.00) m8: (Facultad=“Agro”) ∧ ¬ (p3: Salario ≥ 380.00) Estos 8 predicados mintérminos no son todos los que se pueden definir, estos son solo una muestra de todos los posibles a definir. A partir de los predicados simples o de selección se determinan los predicados minterminos, que determinan el proceso de fragmentación deben poseer las

23

propiedades de Completitud fragmentación correcta y eficiente.

y

Minimalidad

para

garantizar

una

Para que un conjunto de predicado {Pr} sea completo debe garantizar que, para cada aplicación del conjunto de aplicaciones, accedan con igual probabilidad a dos tuplas cualquiera de un mismo fragmento. El conjunto de predicados {Pr} es minimal si todos loa predicados son releventes en la determinación de la fragmentación, es decir, si para cada predicado Pj, que causa que la relación R se divida en dos fragmentos Ri y Rj, exista una aplicación que acceda de forma diferente a ambos fragmentos. De aquí podemos afirmar que un conjunto minimal siempre es completo, pero lo contrario no siempre es verdadero. Log de Transacciones en SQL Server Los cambios en el log de transacciones no son colocados en el cache, las escrituras en él son operaciones intensivas del SGBD, por medio de nuevas paginas que son asignadas y liberadas al mismo tiempo, esto incrementa la eficiencia en el log. El SQL Server para Windows NT ha reducido los gastos e incrementado el funcionamiento[6] ya que el log de asignación y liberación de paginas ocurre en grupos de 8 paginas en cada tiempo. La mayoría de los servidores SQL procesan sus anotaciones en el syslogs de la tabla de log de transacciones. Cada una de las base de datos tienen su propia tabla de log de transacciones, el log de transacciones es truncado mediante la sentencia DUMP TRANSACTION o automáticamente con la opción trunc. log on chkpt[7]. Al comenzar la ejecución de una transacción se almacena en el log de transacciones el evento o identificador de dicha transacción, este evento o identificador es usado en la recuperación y determina el punto de partida de cada transacción. En el log también se almacena el valor de los datos antes de la ejecución de alguna de las sentencias INSERT, DELETE o UPDATA. Cuando se realiza una modificación siempre se almacena en el log antes de ser almacenada en la base de datos. El tipo de log es llamado log de escritura hacia delante (write-ahead). Al terminar la transacción se almacena el commit en el registro de transacciones. Este dato nos sirve para determinar si la transacción terminó con éxito y también nos permite la recuperación automática del registro de transacciones. Es indispensable que el Servidor SQL conozca que las escrituras se han completado. La escritura en cache del controlador de disco compromete la habilidad del Servidor SQL de manejar transacciones haciendo que parezca que

24

ha completado las anotaciones en el write-ahead, aunque no la tiene. Esto puede producir errores como error 605 y también puede causar corrupción en la base de datos. Por esta razón, no se debe usar escritura en cache del controlador de disco con Servidor de SQL a menos que se pueda garantizar que se puedan completar las escrituras[7]. El log de transacción es compartido por todos los usuarios de la base de datos. Frecuentemente se graban múltiples cambios cada vez que una página del log escribe al dispositivo de la base de datos. Este proceso mejora grandemente la entrada/salida del sistema. entrada/salida del sistema.

Distribución de archivos no fragmentados. La distribución de archivos no fragmentados es el caso en que relaciones completas se ubican en los sitios. La razón principal es que la mayoría de los archivos son no fragmentados porque hay muchos accesos importantes que lo que necesitan es recuperar todos los registros de los archivos. Esto es una cuestión central en el diseño e implementación de los SBDD. Uno de los métodos que se destaca para determinar la asignación de archivos es el de Bell y Grimson. La función objetivo de este método es maximizar el acceso local, sujeto a las restricciones de almacenamiento. Este algoritmo consiste en maximizar el acceso local, ya que el acceso remoto es más costoso. La función objetiva intenta poner los archivos en la localidad donde tengan más acceso. Veamos el siguiente ejemplo. La capacidad de almacenamiento de cada sitio es de 25 Mb En la tabla 1 se muestra el acceso de las transacciones a los 8 archivos. En la Tabla 2 tenemos la frecuencia en que se generan las transacciones desde los cinco sitios de la red. En la tabla 3 muestra el resultado de multiplicar el número de filas accedidas por transacción por el número de transacciones generadas en cada sitio.

Trans. 1 2 3 4

1 (8) 10 0 0 0

2 (8) 9 0 0 0

Archivo (tamaño). 3 4 5 (16) (9) (10) 0 0 0 0 0 0 0 60 70 0 6 5

6 (7) 10 20 140 15

7 (4) 0 0 16 10

8 (5) 20 9 0 0

25

5 6 7 8 9 10

0 4 9 6 2 0

0 10 2 5 2 0

0 0 0 0 0 0

4 6 3 2 0 0

4 1 4 4 0 0

0 0 0 0 0 0

0 0 0 0 0 0

10 15 0 0 0 0

Tabla 1. Razón de transacciones a los archivos.

Sitio Trans. 1 2 3 4 5 6 7 8 9 10

1 0 12 0 0 0 20 2 18 4 0

2 25 30 3 0 0 150 100 32 2 4

3 0 0 5 10 12 100 0 12 0 0

4 0 0 4 10 8 2 30 12 0 0

5 0 0 5 10 4 2 40 10 0 0

Tabla 2. Frecuencia de las transacciones en los sitios.

214 1946 472 350 428

302 2089 1060 140 150

0 0 0 0 0

162 1444 1032 458 528

100 888 596 532 618

240 1270 850 710 850

0 48 180 164 180

408 3020 1620 110 70

Tabla 3. Ficheros accedidos por transacciones generadas en cada sitio. Paso1: Para cada archivo identificar el sitio que requiere mayor número de acceso. Significa buscar el máximo de cada columna de la tabla 3, de esta forma tenemos en que sitio se generaron más transacciones para cada fichero.

1 2 3 4

1 214 1946 472 350

2 302 2089 1060 140

3 0 0 0 0

4 162 1444 1032 458

5 100 888 596 532

6 240 1270 850 710

7 0 48 180 164

8 408 3020 1620 110

26

5

428

150

0

528

618

850

180

70

Tabla 4. Máximo de acceso de cada sitio a cada archivo. Paso 2: Asignar a la variable de decisión dij = 1 para todas las entradas en negritas y dij = 0 para los demás casos. Paso 3: Comprobar que no se haya excedido la capacidad de almacenamiento del sitio. Ej. Al sitio 2 se le asignaron archivos con una totalidad de 47 Mb y solo disponemos de 25 Mb. Paso 4: Calcular el máximo de los archivos que se puedan almacenar sin que se exceda la capacidad de almacenamiento. Ej el máximo se logra almacenando los archivos 1,2 y 8, se elimina la fila 2 y las columnas 1, 2 y 8, Y regresamos al paso 2.

1 3 4 5

3 0 0 0 0

4 162 1032 458 528

5 100 596 532 618

6 240 850 710 850

7 0 48 164 180

Tabla 5. Máximo de acceso de los sitios 1,3,4,5 a los ficheros 3,4,5,6,7. Paso 2’: Se le asigna dij = 1 para todas las entradas en negritas y dij = 0 para los demás casos. Paso 3’: Comprobar que no se exceda la capacidad de almacenamiento en sitio, ej. En sitio 3 se le asignaron 16 Mb y su capacidad es de 25, en este caso los máximos de los acceso a los ficheros 4 y 6 no se encuentran el sitio 3 por tanto en el sitio 5 se almacena los ficheros 5 y 7 con capacidad total de 14 Mb, el fichero 3 no es accedido, por tanto no se distribuye. La asignación quedaría como lo muestra la tabla 6: Sitio 1 2 3 4 5

Archivos 1,2,8 4,6 5,7

Mbyte usados 0 21 16 0 14

Tabla 6. Asignación distribuida de archivos.

Procesamiento distribuido de las consultas. Existen algunos sistemas de bases de datos que soportan bases de datos cuyas partes están físicamente separadas. Las relaciones pueden estar ubicadas en sitos diferentes, pueden existir múltiples copias de una misma relación en sitios

27

diferentes, o una relación puede estar particionada y cada subparticion estar distribuida en sitios diferentes. Para realizar una consulta en un sitio dado pudiera ser necesario transferir datos entre varios sitios. La consideración más importante aquí es que el tiempo requerido para realizar una consulta está estrechamente comprometido con el tiempo que se emplea en la transmisión de los datos entre los sitios. Si la ejecución de una consulta sobre la base de dato, y estos están distribuidos en diferentes localidades podemos dividirla en varias subconsultas que se ejecuten en paralelo en cada una de las localidades.

Integridad de los datos en sistemas de bases de datos distribuidas. En los sistemas de bases de datos distribuidas las transacciones dejan de ser secuencias lineales y ordenadas de las acciones sobre los datos, quiere decir que como los datos están distribuidos, las actividades de la transacción pueden tener lugar en diferentes sitios y puede ser difícil mantener un orden de tiempo entre las acciones. El problema más común lo tenemos cuando dos (o más) transacciones se ejecutan al mismo tiempo y ambas requieren acceso al mismo registro de datos con vistas a completar su procesamiento. El problema de concurrencia en sistemas distribuidos es mayor que en sistemas centralizados, puesto que puede haber varias copias de un mismo registro, y todas las copias deben tener los mismos valores o de lo contrario las transacciones trabajarían con datos imprecisos. Para implementar el control de concurrencia se debe conocer lo siguiente[3]: 1. El tipo de algoritmo de planificación utilizado. 2. La localización del planificador. 3. Cómo se controlan los datos duplicados.

Anomalías de procesamiento concurrente. Cuando se ejecutan transacciones concurrentes en bases de datos distribuidas pueden interferir unas con otras, lo que puede afectar la integridad y consistencia de la base de datos. Los diferentes problemas que se pueden presentar son los siguientes: 1. Problema de actualización perdidas. 2. Violación de integridad. 3. Lectura o recuperación inconsistente.

28

Problema de actualización perdidas ocurre cuando un usuario aparentemente completa una actualización con éxito y puede ser sobre escrita por otro usuario, es decir cuando dos o más transacciones acceden concurrentemente sobre un mismo registro de datos, una transacción actualiza un registro de datos y otra transacción escribe este mismo registro. En el siguiente ejemplo se ejecutan 2 transacciones T1 y T2 de forma concurrente, la transacción T1 resta 500 unidades de registro X y la transacción T2 incrementa 200 unidades del registro X, como podemos observar se pierde la actualización de la transacción T2. Ej. Actualizaciones perdidas.

T1

Valor del Registro X 500

Begin T1 Read X Dec(X,500) Write X Commit T1

700 0

T2 Begin T2 Read X Inc(X,200) Write(X) Commit T2

Violación de integridad Se obtiene de violación de integridad en el manejo de la base de datos, cuando se permite la ejecución de dos transacciones concurrentemente sin previo sincronismo. Para el siguiente ejemplo tenemos una base profesores con los campos: nombre, departamento, asignatura. También otra base con la información de un grupo de una facultad que le llamaremos Grupo_1 que posee los campos: turno, asignatura, nombre_P. Inicialmente estas bases se encuentran en siguiente estado: Profesores Nombre Pepe Pepe Juan

Departamento Computación Computación Computación

Asignatura DDB DB DB

Grupo_1 Turno 1er 2da 3ra

Asignatura DB Análisis MOC

Nombre_P Pepe Pedro Tomas

Tenemos una transacción T4 que decide cambiar la asignatura DB por DDB y actualiza el nombre del profesor en la base Grupo_1, Por razones de trabajo Pepe no puede impartir la asignatura DB en el 1er turno y la transacción T5 cambia el profesor que imparte esa asignatura por Juan.

29

T4 Select Asignatura From Grupo_1 Where Turno = 1er Select Nombre From Profesores Where Asignatura_I = DDB Asignatura = DDB Nombre_P = Nombre

T5 Select Asignatura From Grupo_1 Where Nombre_P = Pepe AND Turno= 1er Select Nombre_P From Profesores Where Asignatura_I = Asignatura AND Nombre_P Pepe Nombre = Nombre_P

Donde finalmente la base de datos Grupo_1 quedaría en el siguiente estado: Grupo_1 1er 2da 3ra

DDB Análisis MOC

Juan Pedro Tomas

Que sería una violación de integridad Problemas de recuperaciones inconsistentes. La mayoría del trabajo de control de concurrencia se concentra en las transacciones que actualizando la base de datos pueden interferir unas con otras y provocar datos erróneos. Sin embargo, transacciones que solo lean la base de datos pueden obtener resultados inexactos si se permite leer resultados parciales de transacciones incompletas que actualizan la base de datos, lo que algunas veces se hace, obteniéndose lecturas erróneas. Veamos el siguiente ejemplo: Tenemos un base de datos S con los salarios de los profesores de la universidad y la referencia al mismo se hace mediante la siguiente forma para Pepe es S_Pepe, para Juan es S_Juan, La transacción T5 actualiza los salarios de los profesores que han cambiado de categoría, en este caso S_Juan, T6 suma el salario de todos los profesores para sacar del BPA para pagar en la Universidad. El resultado final es que a Juan no le pagarán el salario correcto. Ej Problemas de recuperaciones inconsistente. T5

Begin T5 Read (S, S_Juan) Inc(S_juan, 15$) Write(S, S_juan) Commit T5

T6 Begin T6 Total = 0 Do while not end_S Read S_juan Inc(total, S_Juan) : :

30

Read S_Pepe Inc(Total, S_Pepe) : : Commit T6

Estos factores proporcionan las bases para la construcción de reglas que determinen cuándo un algoritmo de control de concurrencia es correcto. Las reglas se basan en la teoría de la serialización(Theory of serializability). Una transacción consiste en una secuencia de lecturas y escrituras en la base de datos.

El objetivo del algoritmo de control de concurrencia usado en los SGBD es el horario de las transacciones para evitar interferencia. Si el SGBD permite que solo una transacción se ejecute en un mismo tiempo no habrá problema alguno, o sea para que una transacción pueda comenzar su proceso debemos esperar que termine otra que esté ejecutándose. Una transacción consiste en una secuencia de lecturas y escrituras en la base de datos Serialización en sistemas distribuidos. El concepto básico de seriabilidad es el mismo para SGBD pero distribuidas, pero se le añade la complejidad generada por la distribución. Considere dos transacciones globales T1 y T2 con dos agentes a a o sub-transacciones en los sitos A y B. T 1 es el agente de T1 en A y T 2 es el B B agente T2 en A y T 1 es el agente T1 en B y T 2 es el agente T2 en B. Suponemos que Ta1 precede a Ta2 en el sito A, y TB2 precede a TB1 en el sitio B. Supongamos que cada agente hace una lectura seguido de una escritura en los sitios A y B respectivamente , entonces SA y SB quedarían de la siguiente forma: A

a

a

S = [R1(x), W1(x), R2(x), W2(x)] ==> T 1 < T 2 SB = [R2(y), W2(y), R1(y), W1(y)] ==> TB2 < TB1 Donde SA y SB denotan en horario de las lecturas y escrituras de cada registro en los sitos A y B. Globalmente, dos transacciones no se ejecutan de forma serial pero sus agentes sí se ejecutan de forma serial en cada sitio. Para transacciones distribuidas, se requiere el manejo de la seriabilidad de todos los horarios locales, y la serialización global para todas las transacciones globales. [3] El orden de las solicitudes conflictivas deberá ser una imagen de espejo del orden de las transacciones independiente de donde procedan e independiente de cuantas veces se procesen. De alguna forma los mecanismos de control de

31

concurrencia deben asegurar que las solicitudes conflictivas se procesen en el orden de las transacciones que la generaron[4].

Técnicas para el control concurrente Existen tres técnicas básicas que permiten que las transacciones concurrentes se ejecuten en paralelo sin que se generen datos erróneos en la base de datos. Estas técnicas son las siguientes: 1. Métodos de bloqueos. 2. Métodos de marcas de tiempos. 3. Métodos optimistas. Los métodos de bloqueo y los de marcas de tiempo son métodos esencialmente conservativos. Ellos causan que las transacciones entren en espera en caso que haya alguna transacción que entre en conflicto con otra en un futuro. Sin embargo los métodos optimistas, son basados en la premisa de que el conflicto es raro y además permite que las transacciones se procesen sin sincronismo alguno, estos métodos solo chequean los conflictos al final cuando la transacción termina (commit). Protocolo de cierre de dos-fases. En los sistemas de bases de datos distribuidas el mantenimiento de la integridad de los datos requiere del procesamiento automatizado de las transacciones. Antes de cerrar las actualizaciones de una transacción T, cada subtransacción debe mostrar que está preparada para el cierre. De lo contrario, se abortará la transacción y todos sus cambios. Las subtransacciones que se ejecutan en el sitio local se denotan por Ci (coordinadora) y las otras se denominan participantes Ti. En la primera fase Ci envía un mensaje a las subtransacciones que están preparadas para el cierre en todos los sitios donde se esté ejecutándo Ti. Cada Ti le responde a Ci con voto de cierre o voto de aborto. En la segunda fase Ci determina, con los resultados de la primera fase, si T puede cerrarse o no y envía a todos los Ti un mensaje de cerrar T o abortar T. Bloque distribuido. En cada localidad el SGBDD mantiene un administrador de bloqueo que administra la demanda de bloqueo y desbloqueo de los datos almacenados en cada sitio. Estos bloqueos se pueden aplicar de dos modos: compartido y exclusivo. Si una transacción bloquea un registro en modo compartido, puede leer este registro pero no actualizarlo. Cuando una transacción bloquea un registro en modo exclusivo, solo ella puede acceder a este ya sea para leerlo y/o actualizarlo. Varias transacciones pueden bloquear un registro en modo compartido. Sin embargo solo una puede bloquear un registro en modo exclusivo. Bloqueo distribuido de dos-fases. A través de este método, los ATs son requeridos para realizar bloqueos antes de leer y de escribir datos. Estos bloqueos

32

se realizan de dos formas: modo de lectura o compartido y modo de escritura o exclusivo. Una vez que ATs libera un bloqueo, no se le puede volver a conceder otro bloqueo. A partir de este punto lo único que se puede hacer es liberar bloqueos[4]. El término de dos-fases proviene de esta última limitación. Eswaran y sus colegas probaron que los bloqueos de lectura y escritura generarán programas consistentes si y solo si las transacciones se procesan en dos fases. En la primera fase, se les permite adquirir bloqueos sin liberar ninguno(se denomina fase de crecimiento). Cuando una transacción libera un bloqueo, en un punto llamado el punto de bloqueo, las transacciones entran en la segunda fase o de encogimiento. Durante esta fase, las transacciones pueden liberar bloqueos pero no adquirirlos. Marcas de Tiempo. Método para identificar mensajes con la hora de transmisión. A cada transacción Ti que entra al sistema se le asocia una marca de tiempo ST(Ti). Si ST(Ti) entra al sistema antes que ST(Tj) entonces ST(Ti) < ST(Tj). Hay dos métodos principales de asignar marcas tiempo únicas[3]: 1. Método descentralizado. Se da en un único sitio sin la responsabilidad de asignar marcas de tiempo a las transacciones. 2. Método centralizado. A cada sitio se le permite asignar una única marca de tiempo local. Una marca de tiempo global se obtiene al concatenar los sellos de tiempos locales con un identificador único del sitio. Las marcas de tiempo de las transacciones pueden crearse haciendo que el AT lleve la cuenta del número de transacciones que ha planificado y asigne estos números en orden creciente a la nueva transacción que entre al sistema, de esta manera el orden relativo es consistente con el orden con que se inician las transacciones. Otro enfoque de asignar las marcas de tiempo es usar el reloj interno de la máquina en el momento que se inicie la transacción. Métodos optimistas Cuando una transacción desea terminar, el sistema chequea si hay conflictos con otras transacciones, en caso de que se detecte algún conflicto la transacción debe comenzar nuevamente desde el principio. Para asegurar la atomicidad de la transacción todas las actualizaciones se realizan en copias locales de los datos y solo se actualiza la base de datos en caso de que no se detecten conflictos.

Recuperación de la base de datos. Como ya hemos enunciado, la transparencia de fallas deben ser atómicas; quiere decir que se procesará toda la transacción, o ninguna parte de ella. Al comprometerse una transacción sus efectos deberán ser permanentes. La realidad es que esta atomicidad no siempre se puede conseguir. Si una parte demasiado sustancial de la red falla o porciones criticas fallan en momentos

33

críticos, la recuperación con atomicidad no pudiera ser posible. El administrador de recuperación de SDD-1, se reconoce con la definición de catástrofes del sistema. En cada sitio se debe llevar un diario o bitácora donde se registren todas las acciones de las transacciones. Existen momentos en que es importante contar con la garantía de que el diario se encuentre en perfecto estado en caso de fallas. Los SGBDD deben tener mecanismos para detectar las fallas y restablecer el estado del sistema. El diario debe contener cuáles transacciones fueron iniciadas y no terminaron en el sitio.

Arquitectura multiusuario. Sistema de teleprocesamiento Es sistema de teleprocesamiento se basa en una computadora central en la que se ejecutan los programas de aplicaciones, o microcomputadoras emulando terminales, desde donde los usuarios interactúan con la base de datos. La porción de control de las comunicaciones del sistema operativo recibe los mensajes y los datos y los envía al programa de aplicación apropiado. Luego el programa solicita los servicios al sistema de administración y el mismo utiliza la porción de administración de datos del sistema operativo y se procesa la base de datos. Terminada la transacción los resultados se devuelven a los usuarios en las terminales a través de la porción de controles de comunicaciones del sistema operativo. Estos sistemas basan su nombre en que todas las entradas y las salidas son comunicadas a la macrocomputadora para su procesamiento a distancia, de ahí la palabra "tele". Por lo general la interfaz de usuario está orientada a caracteres y es primitiva. Como conclusión se puede señalar que los sistemas de teleprocesamiento han sido la alternativa más común para sistemas de base de datos multiusuario, pero con la dramática reducción de los costos de las microcomputadoras se han implementado nuevas soluciones.

Sistema Cliente Servidor. Los sistemas cliente/servidor involucran varias computadoras conectadas a una red. Las computadoras que procesan programas de aplicaciones se conocen como clientes y las que procesan bases de datos se conocen como servidor.

Arquitectura Cliente Servidor

34

Usuario 1

AP 1 AP 2

OS net

Cliente 1 Usuario 2

AP2

Red de área local

OS net

Cliente 2 OS net DBMS OSdm AP 2 Usuario n AP 3

DB

Servidor de bases de datos OS net

Cliente N

Un sistema cliente servidor puede tener varios servidores de procesamiento de bases de datos, cuando esto ocurre cada servidor debe procesar una base de datos distinta. Cuando dos o más servidores procesan una misma base de datos, el sistema no es considerado cliente servidor, más bien, es conocido como sistema de base de datos distribuido. Funciones del cliente: ƒ Administrar la interfaz de usuario. ƒ Aceptar datos del usuario. ƒ Procesar la lógica de la aplicación. ƒ Generar las solicitudes para la base de datos. ƒ Trasmitir las solicitudes de la base de datos al servidor. ƒ Recibir los resultados del servidor. ƒ Dar formatos a los resultados.

Funciones del servidor: ƒ Aceptar las solicitudes de la base de datos de los clientes. ƒ Procesar las solicitudes de los clientes. ƒ Dar formato a los resultados y trasmitirlos al cliente. ƒ Llevar a cabo la verificación de integridad. ƒ Mantener los datos generales de la base de datos. ƒ Proporcionar control de acceso concurrente. ƒ Llevar a cabo la recuperación. ƒ Optimizar el procesamiento de consulta/actualización. Una desventaja de los sistemas cliente servidor es el control. Las computadoras clientes operan en forma simultánea y procesan las aplicaciones en paralelo, lo

35

cual hace más difícil el control de los problemas de pérdidas por actualización y otros problemas que provoca el control multiusuario.

36

Bibliografía 1. Silberschatz, A.; Korth, H. F.; Sudarshan S. "Fundamentos de Bases de Datos". (3ª Edición), Mc.Graw-Hill, 1998. 2. Ceri, S.; Pelagatti, G. "Distributed Database. Principles and Systems". Mc.GrawHill, 1985

3.

Thomas M. Connolly, Carolyn E. Begg “SISTEMAS DE BASES DE DATOS 4/E”

Pearson Educación

4. García González Carlos, “La réplica en SQL Server y las aplicaciones distribuidas.”, GIGA, No. 2, 1999, pp 29-35. 5. Microsoft Developer Network (MSDN) CDs. Enero 98, Microsoft Corporations. 6. SQL Server 6.5 Books Online. 7. Lic. Ileana Zamora González, MsC. Abel Rodríguez Morffi, Dra. Luisa Ma. González González, “Distribución de los datos en Sistemas de Bases de Datos Distribuidas.”, GIGA, No. 1, 1999, pp 28-35.