Esquema de fragmentación y distribución de una BDD
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: Sitio que comparte una aplicación. Frecuencia de activación de la aplicación 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 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 transparencia 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.
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, 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)
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. 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. Fragmentación vertical. Es la división de un conjunto de atributos de un objeto en subconjuntos que pueden solaparse. 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:
Es el resultado de aplicar la fragmentación vertical y, posteriormente el fraccionamiento horizontal sobre los fragmentos verticales (denominada VH). Es el resultado de realizar la división horizontal, para posteriormente aplicar sobre los fragmentos generados la fragmentación vertical (llamada HV) . Este enfoque es relativamente nuevo 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)
a) Relación R
b) Fragmentación Vertical
c) Fragmentación Horizontal
d) Fragmentación HV
e) Fragmentación VH
f) Celdas
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. 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 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.
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:
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. Se muestra las tres alternativa de réplicas con respecto a distintas funciones de bases de datos distribuido.
