La fragmentación es el proceso encargado de dividir una relación en otras subrelaciones de menor tamaño, y su objetivo es encontrar la unidad apropiada de distribución. Existe una serie de razones por las que llevar a cabo la fragmentación:
Utilización: En general, las aplicaciones funcionan con vistas que normalmente son subconjuntos de relaciones; por lo tanto, es lógico considerar como unidad de distribución a esos subconjuntos de relaciones.
Eficiencia: Los datos se almacenan cerca del lugar en que son utilizados con mayor frecuencia; además, los datos que las aplicaciones locales no necesitan no se almacenan en ese nodo.
Paralelismo: La descomposición de una relación en fragmentos permite que una transacción pueda ser dividida en subconsultas; cada subconsulta operará sobre el fragmento adecuado. En definitiva, se aumenta el grado de concurrencia.
Seguridad: Los datos no requeridos por las aplicaciones locales no se almacenan en ese nodo, por lo que no están disponibles para los usuarios no autorizados.
La fragmentación también tiene inconvenientes, los cuales son los siguientes:
Rendimiento: El rendimiento de las aplicaciones globales, cuyas vistas están definidas sobre más de un fragmento y que, además, dichos fragmentos pueden estar ubicados en distintos nodos, puede degradarse debido a que habrá que recuperar dichos fragmentos y aplicar operaciones de unión sobre los mismos para satisfacer la consulta que lanzó la aplicación global.
Integridad: Como resultado de la fragmentación los atributos implicados en una dependencia se descomponen en diferentes fragmentos, los cuales pueden destinarse a nodos distintos. Debido a ello el control de integridad puede ser más difícil, pues puede que haya que buscar datos en varios nodos.
Cuando se va a fragmentar una base de datos debe pensarse seriamente el grado de fragmentación que se va a alcanzar, ya que éste será un factor que influirá notablemente en el desarrollo de la ejecución de las consultas.
El grado de fragmentación puede variar desde una ausencia de la división, considerando a las relaciones unidades de fragmentación; o bien, fragmentar a un grado en el que cada tupla o atributo forme un fragmento. 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.
Reglas de corrección de la fragmentación
Las tres reglas que han de cumplirse durante el proceso de fragmentación son las siguientes:
Con este tipo de fragmentación los atributos que forman parte de la clave primaria tienen que repetirse en todos los fragmentos verticales para permitir la reconstrucción de la relación. Esta regla garantiza una redundancia mínima de los datos.
Antes de decidir cómo distribuir los datos, hay que determinar las unidades lógicas de las bases de datos que se van a distribuir; las unidades lógicas de la base de datos son las relaciones, es decir, cada relación completa se almacenará en un sitio específico.
Tipos de fragmentación
Existen tres tipos de fragmentación: vertical, horizontal y mixta. Los dos primeros son los principales y todos cumplen las reglas de corrección de la fragmentación.
Fragmentación horizontal
Un fragmento horizontal de una relación es un subconjunto de las tuplas de la relación. Las tuplas que pertenecen al fragmento horizontal se especifican mediante una condición sobre uno o más de los atributos de la relación, normalmente sólo interviene un atributo.
La fragmentación horizontal divide la relación horizontalmente agrupando filas para crear subconjuntos de tuplas, donde cada subconjunto tiene cierto significado lógico y éstos pueden asignarse a diferentes sitios en el sistema distribuido.
Existen dos variantes de fragmentación horizontal:
Primaria: Se define como una operación de selección (σ) sobre una relación del esquema de la base de datos: Dada una relación R, un fragmento horizontal primario sería σPredicado (R).
Derivada: Intuitivamente este tipo de fragmentación consiste en dividir una relación R en subconjuntos de tuplas a partir de otra relación ya fragmentada P; además, R hace referencia a P mediante una clave ajena. Formalmente, dada una relación hija R y otra padre S, la fragmentación derivada de R se define como R f Si (operación de semicombinación), y donde f es el atributo de combinación, y Si es un fragmento de S.
Fragmentación horizontal, se puede representar en álgebra relacional con σci(R), en donde R es una relación. El conjunto de fragmentos horizontales cuyas condiciones C1, C2..., Cn incluye todas las tuplas de R y se denomina fragmentación horizontal completa de R.
Fragmentación vertical
La fragmentación vertical divide una relación verticalmente en columnas. Un fragmento vertical de una relación mantiene sólo ciertos atributos de la relación. En la fragmentación vertical es necesario incluir el atributo de clave primaria o clave candidata en todo fragmento vertical para que sea posible reconstruir la relación completa a partir de los fragmentos.
Un fragmento vertical de una relación R puede especificarse con una operación ПLi(R) del álgebra relacional; al conjunto de fragmentos verticales cuyas lista de proyección L1, L2 ..., Ln incluye todos los atributos de R pero sólo comparten el atributo clave primaria de R, se le llama fragmentación vertical completa de R.
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.
Primero, las vistas de la aplicación normalmente son subconjuntos de relaciones; además, la localidad de los accesos de las aplicaciones no está definida sobre relaciones enteras pero sí sobre subconjuntos de las mismas. Por ello, sería normal considerar como unidad de distribución a estos subconjuntos de relaciones.
Segundo, si las aplicaciones tienen vistas definidas sobre una determinada relación (considerándola ahora una unidad de distribución) que reside en varios sitios de la red, se puede optar por dos alternativas.
Por un lado, 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 innecesario. Además, se pueden realizar réplicas innecesarias que causen problemas en la ejecución de las actualizaciones y puede no ser deseable si el espacio de almacenamiento está limitado.
Tercero, la descomposición de una relación en fragmentos, tratados cada uno de ellos como una unidad de distribución, permite el proceso concurrente de las transacciones. También la relación de estas relaciones, normalmente, provocará la ejecución paralela de una consulta al dividirla en una serie de subconsultas que operará sobre los fragmentos.
Inconvenientes de la fragmentaciónSi las aplicaciones tienen requisitos tales que prevengan la descomposición de la relación en fragmentos mutuamente exclusivos, estas aplicaciones cuyas vistas estén definidas sobre más de un fragmento pueden sufrir una degradación en el rendimiento; por lo tanto, puede ser necesario recuperar los datos de dos fragmentos y llevar a cabo sobre ellos operación de unión y yunto, lo cual es costoso.
Un segundo problema se refiere al control semántico. Como resultado de la fragmentación los atributos implicados en una dependencia se descomponen en diferentes fragmentos, los cuales pueden destinarse a sitios diferentes. En este caso, la sencilla tarea de verificar las dependencias puede resultar una tarea de búsqueda de los datos implicados en un gran número de sitios.
Réplica de datos
La replicación es útil para mejorar la disponibilidad de los datos. La réplica de datos ocurre si el sistema mantiene copias de una relación R en dos o más sitios. Si se guarda una réplica en cada sitio, se tiene una réplica completa, también mejora el rendimiento de la recuperación en globales, porque el resultado de la consulta se puede obtener localmente en cualquier sitio.
Ventajas de la réplica de datosMejor desempeño: Si la réplica es completa, las aplicaciones pueden operar sobre copias locales en vez de tener que comunicarse con sitios remotos, minimizando el tráfico de datos.
Disponibilidad: Si se produce un fallo en un sitio, es posible que los demás sitios puedan seguir trabajando. Una transacción que requiere un dato específico puede encontrarlo en más de una localidad.
Hay que propagar las actualizaciones. Se puede reducir drásticamente la rapidez de las operaciones de actualizaciones.