CURSO QNAP - Configuración de usuarios locales, grupos y cuotas

3 BASE DE DATOS DISTRIBUIDAS HETEROGÉNEAS

3.1 TIPO DE HETEROGENEIDADES 

Los tipos de heterogeneidades en los sistemas de bases de datos pueden ser clasificadas

en

- las debidas a las diferencias en el SGBD

- las debidas a las diferencias en la semántica de los datos.

La heterogeneidad debida a la utilización de diversos SGBDs es común e organizaciones que crecen sin una planificación en cuanto a sus sistemas de información. Dichos sistemas evolucionan paulatinamente en diferentes SGBDs o diferentes modelos de conceptualización tales como: jerárquico, de red, relacional u orientado a objetos. Diferentes departamentos dentro de la empresa pueden tener requerimientos diferentes y pueden seleccionar diferentes SGBDs. También los SGBDs adquiridos a lo largo de un período de tiempo pueden ser diferentes debido a los cambios en la tecnología. Cada SGBD tiene un modelo de datos subyacente utilizado para definir estructuras de datos y las restricciones. Tanto los aspectos de representación (estructura y restricciones) como de lenguaje pueden dar lugar a la heterogeneidad.

Diferencias en la estructura:

Diferentes modelos de datos proporcionan diferentes primitivas estructurales. Pueden darse cuatro tipos de conflictos: de tipo, de dependencia, de clave o de comportamiento.

Los conflictos de tipo se producen cuando el mismo objeto es representado por un atributo en un esquema y por una entidad en otro.

Los problemas de dependencia se Diseñó y Construcción de Bases de Datos Distribuidas Heterogéneas sobre Oracle Y SQL Server

producen cuando los distintos modos de relación (por ejemplo, una relación uno a uno frente a una de muchos a muchos) se usan para representar lo mismo en diferentes esquemas. Los conflictos de clave se producen cuando existen varias claves candidatas disponibles y se seleccionan claves primarias diferentes en distintos esquemas. Los

conflictos de comportamiento están implícitos en los mecanismos de modelado. Por ejemplo, borrar el último elemento de una BD puede provocar la eliminación de la entidad que contiene (es decir, la eliminación del último empleado puede causar la disolución del departamento). Si el contenido de la información no es el mismo, puede ser muy difícil solventar las diferencias.

Diferencias en las restricciones:

Dos modelos de datos pueden soportar diferentes restricciones. Esto quiere decir que puede ser que en un modelo de datos existan x tipos de restricciones y en otro modelo y, que posiblemente sean diferentes. Los disparadores (o algún otro mecanismo) deben ser utilizados en los sistemas relacionales para captar la semántica de estos.

Diferencias en los lenguajes de consulta:

Como por ejemplo cuando se utilizan diferentes lenguajes de consulta para manipula los datos representados en modelos de datos diferentes. Incluso cuando dos SGBDs se basan en el mismo modelo de datos, las diferencias en los lenguajes de consulta (por ejemplo, Quel1 y SQL) o las diferentes versiones de SQL soportado por dos SGBDs relacionales pueden contribuir a la heterogeneidad.

Heterogeneidades debido a diferencias semánticas

La heterogeneidad semántica es un término bastante cargado, sin una definición clara. Básicamente se refiere a las diferencias entre las BBDD que se relacionan con el significado, la interpretación y el uso previsto de los datos. Sin duda, los aspectos más importantes de la heterogeneidad semántica se revelan como conflictos de nombres. El

problema fundamental de nombres es el de los sinónimos y los homónimos. Dos entidades idénticas que tienen diferentes nombres son sinónimos, y dos entidades diferentes que tienen nombres idénticos son homónimas. La detección de la heterogeneidad semántica es un problema difícil. Normalmente, los esquemas de los SGBD no proporcionan la semántica suficiente para interpretar los datos de forma coherente. La heterogeneidad debida a diferencias en los modelos de

datos también contribuye a la dificultad en la identificación y resolución de la heterogeneidad semántica. También es difícil descomponer la heterogeneidad debida a diferencias en el SGBD de los resultantes de la heterogeneidad semántica

Bibliografia: 
Laura Martínez M.. (2010). Ventajas de las BBDD en sistemas heterogéneos. Diseño y Construcción de BD Distribuidas Heterogéneas sobre Oracle y SQLSERVER(39). Madrid: Santillas.

3.2 VENTAJAS DE LAS BBDD EN SISTEMAS HETEROGÉNEOS

La llegada de los sistemas heterogéneos ha traído tanto beneficios como problemas. Las ventajas son por supuesto muchas.

1. El tradicional procesamiento de los datos está siendo rápidamente reemplazado por la gestión de modernas BBD.
2. Nuevas capacidades tales como la actualización en línea, consultas ad-hoc, y la integridad de los datos son fácilmente disponibles en SGBD modernos. 
3. Para todas las aplicaciones posibles de uso intensivo y grandes volúmenes de datos, existe un SGBD para la aplicación.
4. Para una organización con diversas aplicaciones, un gran número de SGBD monomodelo y monolenguaje pueden ser utilizados para cada aplicación distinta. 

Bibliografia: 
Laura Martínez M.. (2010). Ventajas de las BBDD en sistemas heterogéneos. Diseño y Construcción de BD Distribuidas Heterogéneas sobre Oracle y SQLSERVER(39). Madrid: Santillas.

3.3 PROBLEMAS DE BBDD EN SISTEMAS HETEROGÉNEOS

Existen problemas que pueden afectar a la eficacia y la eficiencia de la utilización de SGBD modernos en una organización, como pueden ser:

• ·      Difícil intercambio, control y utilización global de datos. Si una organización tiene diferentes bases datos, con diferentes SGBD y diferentes modelos de datos, a la hora de acceder a la información es posible que los usuarios no sean expertos en diferentes modelos y SGBD. De hecho, lo general es encontrarse con profesionales en un modelo y en un lenguaje concreto.

• ·         Alto Coste de mantenimiento y soporte. Los SGBD heterogéneos en una gran organización tienden a ser muchos y sus BD de gran volumen, cada SGBD monomodelo y monolenguaje requiere el apoyo de un conjunto exclusivo de los ordenadores, un sistema separado de las unidades de disco, y un equipo dedicado de profesionales. Ya sea centralizado o distribuido, el conjunto de equipos, el sistema de discos, y el equipo de profesionales suponen una inversión importante y pesada para un SGBD monomodelo y monolenguaje. Como el número de estos SGBD monomodelo y monolenguaje aumentan, los gastos se multiplican. Además, los costos de la actualización de equipos, SGBD mejora del rendimiento, y la capacidad de crecimiento de la base de datos puede tener que ser multiplicada también. Desde el punto de vista de mantenimiento y actualización, siempre es más caro y requiere mayor esfuerzo mantener o actualizar los sistemas múltiples que actualizar un sistema único.

• ·       Las similitudes y la multiplicidad de SGBD heterogéneos. En resumen, los SGBD heterogéneos nos ofrecen soluciones informatizadas para aplicaciones de datos voluminosos e intensivos. En consecuencia, el procesamiento de los datos tradicionales y las nuevas aplicaciones de datos intensivos y voluminosos han llevado a la proliferación y la introducción de muchos SGBD monomodelo y monolingües. Si bien esta proliferación e introducción son gratificantes y probablemente continuarán, los SGBD monomodelos y monolingües, sin embargo, presentan nuevos problemas e introducen otras cuestiones. Estos problemas y cuestiones son intrínsecas a la similitud de SGBD monomodelo y monolingües. Son identificados como:  

1.       El primer problema, en el intercambio global de los datos, el control y la utilización es lo más fundamental, ya que impide que el usuario de un SGBD monomodelo y monolingüe utilice las BBDD de otros SGBD monomodelo y monolingües. En consecuencia, la carga se encuentra en la parte de los usuarios que deben aprender los otros modelos y lenguajes para tener acceso a otras BBDD y para la utilización de otros SGBD monomodelo y monolingües. 

2.       El segundo problema es el coste. A medida que la popularidad y la funcionalidad de los SGBD son cada vez más evidentes, el uso de SGBD en una determinada organización se hará más frecuente. En consecuencia, habrá muchos SGBDs heterogéneos en una organización. Como SGBDs separados, monomodelos, y monolingües, que requieren apoyos por separado y hardware más potente que soporte este tipo de sistemas, lo que se traduce en más costes.

BIBLIOGRAFIA
Laura Martínez M.. (2010). Problemas de BBDD en sistemas Heterogéneos. Diseño y Construcción de BD Distribuidas Heterogéneas sobre Oracle y SQLSERVER(40). Madrid: Santillas.

3.4 INTEGRACIÓN DE LAS BBDD.

La integración de BBDD implica un proceso por el cual la información de las BBDD fragmentadas puede ser conceptualmente integrada de forma coherente en una única BD.

La integración de BD puede darse en dos pasos:

· Esquema de traducción

· Esquema de integración   

•     Esquema de traducción.

El esquema de traducción es la tarea de asignación de un esquema a otro. Los esquemas de los componentes de BD se traducen en una representación canónica intermedia común (InS1, InS2,...,InSn). El uso de una representación canónica facilita los procesos de traducción por reducción del número de traductores que necesitan ser escritos.

El paso de traducción es necesario sólo si los componentes de BBDD son heterogéneos y cada esquema local puede definirse mediante un modelo de datos diferente y aun así, puede no ser necesario en una BD heterogénea, si puede llevarse a cabo durante la etapa de integración.

• Esquema de integración.

El esquema de integración es el proceso de identificación de los componentes de una BD que están relacionados entre sí, de la selección de la mejor representación para el ECG y, por último, de la integración de los componentes de cada esquema intermedio. Dos componentes pueden estar relacionados como equivalentes, uno está contenido en otro, o como disjunto.

Las metodologías de integración pueden ser clasificadas como mecanismos binarios o n-arios.

Taxónomias de metodologías de la integración

Las metodologías de integración binarias implican la manipulación de dos esquemas a la vez.

Se puede producir creando esquemas intermedios para la integración con los esquemas posteriores o de una manera puramente binaria.

Métodos de integración binarios

Los mecanismos n-arios de integración integran más de dos esquemas en cada iteración. Un paso de integración se produce cuando todos los esquemas se integran a la vez, produciendo el ECG después de una iteración.

Métodos de Integración n-aria

El mecanismo iterativo n-ario de integración ofrece más flexibilidad y es más general (el número de esquemas pueden variar en función de las preferencias de los integradores).

Los modelos binarios son un caso especial de iterativos n-arios.

La integración de esquemas implica dos tareas:

· La homogeneización

· La integración

• Homogeneización

Durante esta fase, se resuelven los problemas de la heterogeneidad semántica y de la heterogeneidad estructural.

Respecto a la heterogeneidad semántica, hay una serie de métodos alternativos para hacer frente a los conflictos de nombres.

Respecto a la heterogeneidad estructural, la transformación de las entidades y atributos / relaciones entre unos y otros es una manera de manejar los conflictos estructurales.

Muestra los posibles escenarios de transformación atómica. Las líneas punteadas indican que un atributo dado es un identificador (clave) de la entidad asociada.

Alternativas de Conformación Atómica

• Integración

La integración supone la fusión de los esquemas intermedios y su reestructuración.

Todos los esquemas se fusionan en un esquema de BD único y reestructurado para crear el "mejor" esquema integrado. La fusión requiere que la información contenida en los esquemas de participación se mantenga en el esquema integrado.

Bibliografía: Diseño y Construcción de Bases de Datos Distribuidas

Heterogéneas sobre Oracle Y SQL Server Páginas 41-44.

3.5 PROCESAMIENTO DE CONSULTAS EN BBDD HETEROGÉNEAS.

La naturaleza de los sistemas que integran varias BBDD requiere pasos ligeramente diferentes a los necesarios en el procesamiento de consultas distribuidas

Cada SGBD tiene sus propios procesadores de consulta y es más complejo por las siguientes razones:

• La capacidad de los componentes del SGBD pueden ser diferentes, lo que impide un tratamiento uniforme de las consultas a través de múltiples SGBD y sitios.
• Del mismo modo, el coste de tramitación de las consultas puede ser diferente en diferentes SGBD. Esto aumenta la complejidad de las funciones de costes que deben ser evaluadas.
• Puede haber dificultades en el movimiento de datos entre SGBDs ya que pueden diferir en su capacidad para leer datos "movidos".
• La capacidad de optimización local de cada SGBD puede ser muy diferente.

El SGBD heterogéneo, recibe la consulta global. Cuando una consulta es recibida en un nodo, lo primero que necesita hacer es “dividirla” en subconsultas basadas en la distribución de datos a través de múltiples sitios. En este paso, sólo es necesario preocuparse de la ubicación de los datos a través de los sitios, más que de su almacenamiento a través de varias BDs.

La primera alternativa consiste en descomponer una consulta global en el menor número de subconsultas posible, cada una de ellas es ejecutada por un componente del SGBD.

Ventajas: La descomposición es relativamente simple, y hay más oportunidades de optimización en el nivel de consulta optimizador global.

Desventaja: El procesador de consultas a nivel global y el optimizador hace más trabajo, y hay más mensajes que se transmiten para ejecutar la consulta.

La segunda heurística alternativa es descomponer la consulta global en el mayor número de subconsultas posible, cada una de ellas es ejecutada por un SGBD.

Ventajas: el procesador de consultas a nivel global y el optimizador hace menos trabajo, ya que entre el espacio de procesamiento se reduce al mínimo.

Desventaja: Esto se traduce en menos mensajes, pero en los procesadores de interfaz de componentes más sofisticados (CIPS, component interface processors). 

*Consulta global de múltiples bases de datos en múltiples sitios*

*Estructura de un sistema gestor de una base de datos distribuidas*

Bibliografia: Diseño y Construcción de Bases de Datos Distribuidas

Heterogéneas sobre Oracle Y SQL Server Página 45-47.

3.6 GESTIÓN DE TRANSACCIONES

3.6.1 Modelo de transacción y computación.

La arquitectura de un SGBD heterogéneo implica una serie de SGBDs, cada uno con su propio administrador de transacciones (llamados gestores locales de transacciones o LTMs) y una capa de SGBD heterogénea en la parte superior. El administrador de transacciones de la capa del SGBD heterogénea de varios SGBD se llama administrador de transacciones globales (GTM), ya que gestiona la ejecución de operaciones globales.

En un sistema heterogéneo, hay dos tipos de operaciones:

• Las transacciones locales, que se envían a cada SGBD y se ejecutan en una única

BD

• Las transacciones globales, que tienen acceso a múltiples BDs que se envían a la capa de múltiples SGBD. Una transacción global se divide en una serie de subtransacciones globales, cada una de los cuales se ejecuta en una BD.

3.6.2 Control de concurrencia en sistemas heterogéneos.

Dos transacciones son conflictivas si tienen una operación que accede al mismo dato y al menos una de ellas es de escritura. No es sencillo para el gestor de Transacciones Globales (TG) determinar los conflictos en un sistema heterogéneo. Supóngase que dos transacciones globales que se manejan por el gestor de TG no parecen estar en conflicto en absoluto. Sin embargo, la existencia de transacciones locales puede provocar conflictos en los componentes de BD a través de transacciones, los conflictos indirectos de este tipo no pueden ser detectados por el gestor de TG y son un origen de dificultades significativas en múltiples SGBD.

Una serie de condiciones han sido definidas para especificar cuándo se pueden actualizar las transacciones globales de forma segura en un sistema heterogéneo. Estas condiciones son útiles para determinar la funcionalidad mínima requerida de los diversos gestores de transacciones.

• La primera condición para proporcionar el control de concurrencia global es que los DBA individuales sean responsables de la correcta ejecución de las operaciones en sus respectivas BBDD.

• La segunda condición requiere que cada gestor local de transacciones (LTM) mantenga el orden de ejecución relativa de las subtransacciones determinadas por el GTM. El GTM, entonces, se encarga de coordinar la sumisión de las

subtransacciones globales al LTM y la coordinación de su ejecución.

• Por otra parte, el GTM es el responsable de tratar con interbloqueos globales que se producen en las transacciones globales.

 

Bibliografia: Diseño y Construcción de Bases de Datos Distribuidas

Heterogéneas sobre Oracle Y SQL Server Página 48.