Independencia De Hardware y S.O.

Independencia De Fragmentacion

Fragmentación

El problema de fragmentación se refiere al particionamiento de la información para distribuir cada parte a los diferentes sitios de la red

Objetivos de la fragmentación

El objetivo de la fragmentación consiste en  la relación en un  de relaciones más pequeñas tal que algunas de las aplicaciones de usuario sólo hagan uso de un fragmento.

Sobre este marco, una fragmentación óptima es aquella que produce un esquema de división que minimiza el tiempo de ejecución de las aplicaciones que emplean esos fragmentos.

La unidad de fragmentación  no es la tabla sino una subdivisión de ésta.

Esto es debido a:

• Las aplicaciones usan vistas definidas sobre varias relaciones, es decir, se forman a partir de "trozos" de varias tablas. Si conseguimos que cada una de las vistas esté definida sobre subtablas locales (o en su defecto lo mas "cerca" posible) a cada aplicación, es de esperar un incremento en el rendimiento.
• Si múltiples vistas de diferentes aplicaciones están definidas sobre una tabla no fragmentada, se tiene :

• Si la tabla no está replicada entonces se produce generación de  por accesos remotos.
• Si la tabla está replicada en todos o algunos de los sitios donde residen cada una de las aplicaciones entonces la generación de trafico innecesario es producida por la necesidad de la actualización de las copias.

Al descomponer una relación en fragmentos (unidades de distribución) :

• Permitimos el procesamiento concurrente de transacciones ya que no se bloquean tablas enteras sino subtablas, por lo que dos consultas pueden acceder a la misma tabla a fragmentos distintos.
• Permitimos la paralelización de consultas al poder descomponerlas en subconsultas, cada una de la cuales trabajará con un fragmento diferente incrementándose así el rendimiento.

Desventajas

• Degradación del rendimiento en vistas definidas sobre varios fragmentos ubicados en sitios distintos (es necesario realizar operaciones con esos trozos lo cual es costoso)
• El control semántico se dificulta y el rendimiento se degrada debido que la verificación de restricciones de integridad (claves ajenas, uniques, etc) implican buscar fragmentos en múltiples localizaciones.

Por lo tanto división y ubicación de los fragmentos no es trivial.

Tipos de fragmentación de datos

Existen tres tipos de fragmentación:

• Fragmentación horizontal
• Fragmentación vertical
• Fragmentación híbrida

Para que una la fragmentación de una relación sea correcta debe satisfacer las siguientes condiciones:

• Condición de completitud.

La descomposición de una relación R en los fragmentos R1, R2, ..., Rn es completa si y solamente si cada elemento de datos en R se encuentra en alguno de los fragmentos Ri.

• Condición de Reconstrucción.

La descomposición de una relación R en los fragmentos R1, R2, ..., Rn es completa si y solamente si cada elemento de datos en R se encuentra en alguno de los fragmentos Ri.

• Condición de Fragmentos Disjuntos.

Si la relación R se descompone en los fragmentos R1, R2, ..., Rn, y el dato di está en Rj, entonces, no debe estar en ningún otro fragmento Rk (k?j).

Fragmentación horizontal

La fragmentación horizontal de una relación R produce una serie de fragmentos R1, R2, ..., Rr, cada uno de los cuales contiene un subconjunto de las tuplas de R que cumplen determinadas propiedades (predicados)

Fragmentación horizontal primaria y derivada

La Fragmentación Horizontal Primaria (FHP) de una relación se obtiene usando predicados que están definidos en esa relación.

La Fragmentación Horizontal Derivada (FHD) por otra parte, es el particionamiento de una relación como resultado de predicados que se definen en otra relación.

Fragmentación vertical

La fragmentación vertical de una relación R produce una serie de fragmentos R1, R2, ..., Rr cada uno de los cuales contiene un subconjunto de los atributos de R así como la clave primaria de R.

Complejidad de la fragmentación Vertical

La fragmentación vertical resulta más complicada que la horizontal. En el caso vertical, si una relación tiene m atributos clave no primarios, el número de posibles fragmentos es igual a B(m), es decir el m-ésimo número de Bell [3]. Para valores grandes de m, B(m)(mm; por ejemplo, para m = 10, B(m) ( 115.000, para m = 15, B(m) ( 109, para m = 30, B(m) = 1023.

Estos valores indican que la obtención de una solución óptima de la fragmentación vertical resultará una tarea imposible, sino nos apoyamos en el uso de heurísticas.

El problema de la asignación de fragmentos

Asumamos que hay un conjunto de fragmentos F = { F1, F2, ..., Fn } y una red que consiste de los sitios S = { S1, S2, ..., Sm } en los cuales un conjunto Q = { q1, q2, ..., qq } de consultas se van a ejecutar.

El problema de asignación consiste en determinar la distribución "óptima" de F en S.

La optimalidad puede ser definida de acuerdo a dos medidas:

• Costo mínimo. Consiste del costo de comunicación de datos, del costo de almacenamiento, y del costo procesamiento (lecturas y actualizaciones a cada fragmento). El problema de la asignación, es encontrar un esquema de asignación o ubicación que minimiza la función de costo combinada.
• Rendimiento: La estrategia de asignación se diseña para mantener una métrica de rendimiento. Las dos métricas más utilizadas son el tiempo de respuesta y el "throughput" (número de trabajos procesados por unidad de tiempo).

Asignación de fragmentos

Asignación

Proceso mediante el cual se decide donde se ubicaran los fragmentos de la etapa anterior y si se harán replicas de los mismos.

Hacer replicas tiene sentido por :

• Confiabilidad : Mayor seguridad ante perdida de datos
• Disponibilidad : Mayor tolerancia a fallos ante caídas de los computadores
• Aumento del paralelismo : Mayor eficiencia en las consultas de lectura al posibilitarse su descomposición en subconsultas y la paralelización de éstas.

Pero presenta el inconvenientes de las consultas de escritura, que conllevan las actualización de todas las copias de la red.

En la práctica : Sopesar lecturas vs escrituras

• Mas lecturas que escrituras : Replicación es buena idea
• Mas escrituras que lecturas : No replicamos.

Según el grado de replicación, distinguimos entre :

• BD fragmentada : Fragmentos disjuntos, cada uno en un nodo (no hay replicas)
• BD totalmente replicada : Se encuentra una copia de toda la BD en cada nodo
• BD parcialmente replicada : Mezcla las anteriores. Algunos fragmentos están replicados.

Como se ve las técnicas de fragmentación y replicación se combinan en la práctica.

Replicación de fragmentos

El problema de la replicación de segmentos asignación consiste en la determinación de que fragmentos se replicarán en diferentes sitios a pesar de los problemas que acarrea la actualización.

Distribución de Datos

Una de las decisiones más importantes que el diseñador de bases de datos distribuidas debe tomar es el posicionamiento de la data en el sistema y el esquema bajo el cuál lo desea hacer. Para esto existen cuatro alternativas principales: centralizada, replicada, fragmentada, e híbrida. La forma centralizada es muy similar al modelo de Cliente/Servidor en el sentido que la BDD está centralizada en un lugar y los usuarios están distribuidos. Este modelo solo brinda la ventaja de tener el procesamiento distribuido ya que en sentido de disponibilidad y fiabilidad de los datos no se gana nada.

Replicadas

El esquema de BDD de replicación consiste en que cada nodo debe tener su copia completa de la base de datos. Es fácil ver que este esquema tiene un alto costo en el almacenamiento de la información. Debido a que la actualización de los datos debe ser realizada en todas las copias, también tiene un alto costo de escritura, pero todo esto vale la pena si tenemos un sistema en el que se va a escribir pocas veces y leer muchas, y dónde la disponibilidad y fiabilidad de los datos sea de máxima importancia.

Particionadas

Este modelo consiste en que solo hay una copia de cada elemento, pero la información está distribuida a través de los nodos. En cada nodo se aloja uno o más fragmentos disjuntos de la base de datos. Como los fragmentos no se replican esto disminuye el costo de almacenamiento, pero también sacrifica la disponibilidad y fiabilidad de los datos. Algo que se debe tomar en cuenta cuando se desea implementar este modelo es la granularidad de la fragmentación. La fragmentación se puede realizar también de tres formas:

Horizontal: Los fragmentos son subconjuntos de una tabla (análogo a un restringir)

Vertical: Los fragmentos son subconjuntos de los atributos con sus valores (análogo a un proyectar)

Mixto: Se almacenan fragmentos producto de restringir y proyectar una tabla.

Una ventaja significativa de este esquema es que las consultas (SQL) también se fragmentan por lo que su procesamiento es en paralelo y más eficiente, pero también se sacrifica con casos especiales como usar JUNTAR o PRODUCTO, en general casos que involucren varios fragmentos de la BDD.

Para que una fragmentación sea correcta esta debe cumplir con las siguientes reglas:

Debe ser Completa: Si una relación R se fragmenta en R1,R2, ... , Rn, cada elemento de la data de R debe estar en algún Ri.

Debe ser Reconstruible: Debe ser posible definir una operación relacional que a partir de los fragmentos obtenga la relación.

Los fragmentos deben ser Disjuntos: Si la fragmentación es horizontal entonces si un elemento e está en Ri este elemento no puede estar en ningún Rk (para k distinto a i). En el caso de fragmentación vertical es necesario que se repitan las llaves primarias y esta condición solo se debe cumplir para el conjunto de atributos que no son llave primaria.

Híbrida

Este esquema simplemente representa la combinación del esquema de partición y replicación. Se particiona la relación y a la vez los fragmentos están selectivamente replicados a través del sistema de BDD.

Criterios para escoger la distribución

Localidad de la data: la data debería ser colocada donde ésta se accede más seguido. El diseñador debe analizar las aplicaciones y determinar cómo colocar la data de tal forma que se optimicen los accesos a la data locales.

Fiabilidad de la data: Almacenando varias copias de la data en lugares geográficamente apartados se logra maximizar la probabilidad de que la data va a ser recuperable en caso de que ocurra daño físico en cualquier sitio.

Disponibilidad de la data: como en la fiabilidad, almacenar varias copias asegura que los usuarios tengan a su disponibilidad los elementos de la data, aún si el nodo al que usualmente acceden no está disponible o falla.

Capacidades y costos de almacenamiento: a pesar de que los costos de almacenamiento no son tan grandes como los de transmisión, los nodos pueden tener diferentes capacidades de almacenamiento y procesamiento. Esto se debe analizar cuidadosamente para determinar dónde poner la data. El costo de almacenamiento se disminuye significativamente minimizando la cantidad de copias de la data.

Distribución de la carga de procesamiento: una de las razones por la cual se escoge un sistema de BDD es porque se desea poder distribuir la carga de procesamiento para hacer este más eficiente.

Costo de comunicación: el diseñador debe considerar también el costo de usar las comunicaciones de la red para obtener data. Los costos de comunicación se minimizan cuando cada sitio tiene su propia copia de la data, por otro lado cuando la data es actualizada se debe actualizar en todos los nodos.

Uso del sistema: debe tomarse en consideración cual será el tipo principal de uso del sistema de BDD. Factores como la importancia en la disponibilidad de la data, la velocidad de escritura y la capacidad de recuperación de daños físicos deben tomarse en cuenta para escoger el esquema correcto.

Base de Batos Heterogénea

Las BDs Heterogéneas o Multibase de Datos son aquellas donde Sitios diferentes utilizan diferentes DBMSs, siendo cada uno esencialmente autónomo. Es posible que algunos sitios no sean conscientes de la existencia de los demás y quizás proporcionen facilidades limitadas para la cooperación en el procesamiento de transacciones.

En las bases de datos distribuidas heterogéneas puede que los diferentes sitios utilicen esquemas y software de gestión de sistemas de bases de datos diferentes. Puede que algunos sitios no tengan información de la existencia del resto y que sólo proporcionen facilidades limitadas para la cooperación en el procesamiento de las transacciones.

La heterogeneidad se debe a que los datos de cada BD son de diferentes tipos o formatos. El enfoque heterogéneo es más complejo que el enfoque homogéneo y favorece el enfoque ascendente. Es una tecnología reciente y aún existen pocas en

el mercado.

Hoy en día existe la tendencia a crear software que permita tener acceso a diversas bases de datos autónomas preexistentes almacenadas en SGBD heterogéneos. La Heterogeneidad de las BD es inevitable cuando diferentes tipos de BD coexisten en una organización que trata de compartir datos entre éstas. Investigadores han enfocado sus esfuerzos en la exploración de un esquema global que trate de resolver los problemas de la Heterogeneidad, la definición de Protocolos Ínter operables y la integración de las BD.

Las Bases de Datos Distribuidas Heterogéneas se componen de un conjunto de localidades, cada una de las cuales mantiene un SBD local, éstas pueden procesar transacciones locales (aquellas que se realizan sobre esa localidad).

Ejemplo:

El tratamiento de la información ubicada en bases de datos distribuidas heterogéneas exige una capa de software adicional por encima de los sistemas de bases de datos ya existentes. Esta capa de software se denomina sistema de bases de datos múltiples. Puede que los sistemas locales de bases de datos empleen modelos lógicos y lenguajes de definición y de tratamiento de datos diferentes, y que difieran en sus mecanismos de

control de concurrencia y de administración de las transacciones. Los sistemas de bases de datos múltiples crean la ilusión de la integración lógica de las bases de datos sin necesidad de su integración física. La integración completa de sistemas heterogéneos en una misma base de datos distribuida homogénea suele resultar difícil o imposible. 

Base de Batos Homogéneas

En los sistemas de bases de datos distribuidas homogéneas todos los sitios emplean idéntico software de gestión de bases de datos, son conscientes de la existencia de los demás sitios y acuerdan cooperar en el procesamiento de las solicitudes de los usuarios.

En estos sistemas, los sitios locales renuncian a una parte de su autonomía en cuanto a su derecho a modificar los esquemas o el software de gestión de bases de datos. Ese software también debe cooperar con los demás sitios en el intercambio de la información sobre las transacciones para hacer posible su procesamiento entre varios sitios.

Características

Desde el punto de vista del usuario, un sistema distribuido deberá ser idéntico a un sistema no distribuido.

En términos de SQL, la lógica de las operaciones SELECT, INSERT, UPDATE y DELETE no deberá sufrir cambios.

1. Autonomía Local

Los sitios de un sistema distribuido deben ser autónomos.

Ningún sitio X deberá depender de un sitio Y para su buen funcionamiento.

Existencia de un propietario y administración local de los datos.

2. No dependencia de un sitio central.

No debe haber dependencia de un sitio central “maestro” para obtener un servicio.

El sitio central podría ser un cuello de botella.

Si el sitio central sufriera un desperfecto, todo el sistema dejaría de funcionar.

3. Operación continua

Idealmente nunca debería haber necesidad de apagar a propósito el sistema, por ejemplo, para añadir un nuevo sitio o instalar una versión mejorada del DBMS en un sitio ya existente.

4. Independencia con respecto a la localización

No debe ser necesario que los usuarios sepan dónde están almacenados físicamente los datos.

Simplifica los programas de los usuarios.

Permite modificar la distribución de los datos dentro de la red.

5. Independencia respecto a la fragmentación

Dos clases de fragmentación: Horizontal y Vertical. Los usuarios deberán poder comportarse como si los datos no estuvieran fragmentados en realidad.

6. Independencia de Réplica

Un sistema maneja réplica de datos si una relación dada se puede representar físicamente mediante varias copias almacenadas en muchos sitios distintos.

7. Procesamiento distribuido de consultas

En una consulta distribuida, habrá muchas maneras de trasladar los datos en la red para satisfacer la solicitud.

Importancia crucial de la optimización.

8. Manejo distribuido de transacciones.

Control de Recuperación: el sistema debe asegurar que cada transacción sea atómica (todo o nada).

Control de Concurrencia: basada en el bloqueo.

9. Independencia

Respecto al Equipo: máquinas diferentes. Respecto al Sistema Operativo. Respecto a la Red.

Respecto al DBMS: comunicación mediante SQL.

Definición

 

Un SBD Distribuido se compone de un conjunto de sitios, conectados entre sí mediante algún tipo de red de comunicaciones, en el cual cada sitio es un SBD en sí mismo.