Procesamiento de Transacciones y Arquitecturas de Distribución de datos

1. Administración de Objetos y Recursos

La Administración de objetos introducida al mundo de los sistemas de bases de datos se propuso para poder satisfacer las necesidades de las aplicaciones de bases de datos complejas y para añadir nuevas funcionalidades de bases de datos a los lenguajes de programación orientada a objetos. De forma concreta, las bases de datos orientadas a objetos están basadas en el concepto de encapsular los datos de un objeto y con él, el código con el que opera. Entre los conceptos más importantes que se utilizan en las bases de datos, son:

Diferenciación de objeto: Los objetos tienen identidades únicas que son independientes de sus valores de atributo

Creadores de tipo: Las estructuras de los objetos complejos se pueden construir si se aplican recursivamente un conjunto de constructores básicos (como lo son las tuplas, conjuntos, listas y bolsa).

Encapsulamiento de operaciones: Tanto la estructura del objeto como las operaciones que pueden aplicarse a ellos están incluidas en las definiciones de clase de objeto.

Utilización en el lenguaje de programación: Los objetos persistentes y transitorios se manipulan sin problemas. Los objetos se hacen persistentes adjuntándoles a una colección persistente o denominándolos explícitamente.

Jerarquía de tipos y herencia: Los tipos de objetos pueden especificarse utilizando una jerarquía de tipos, que permite heredar los atributos y los métodos de los tipos definidos anteriormente.

Extensiones: Todos los objetos persistentes de un tipo particular se pueden almacenar en una extensión. Las extensiones correspondientes a una jerarquía de tipos tienen implementadas restricciones de conjunto/subconjunto.

Soporte de objetos complejos: Los objetos complejos estructurados y no estructurados se pueden almacenar y manipular.

Polimorfismo y sobrecarga del operador: Los nombres de los métodos y las operaciones se pueden sobrecargar para que puedan aplicarse a diferentes tipos de objetos con implementaciones distintas.

Versiones: Algunos sistemas OO ofrecen soporte para conservar varias versiones del mismo objeto.

2. Integridad y Concurrencia

La integridad en una base de datos es la corrección y exactitud de la información que posee la misma. Además de ello, busca la seguridad en un sistema de bases de datos que permita el acceso a múltiples usuarios en tiempos paralelos.

Se puede clasificar en:

a)   Integridad de dominio:

Consiste en verificar que cada valor o instancia de un atributo esté en el dominio o conjunto de valores posibles para dicho atributo.

b)   Integridad de entidad:

Este tipo de integridad se encarga de vigilar que toda instancia de una entidad se distinga de las demás, inequívocamente. Las entidades dentro de una base de datos corresponden a entidades del mundo real donde sus instancias son completamente diferenciables; por ello, cada instancia debe poseer un identificador único y no nulo denominado clave primaria en el modelo relacional. El mecanismo empleado por casi todos los sistemas de gestión de base de datos para garantizar la integridad de entidad es la restricción impuesta a los atributos que forman parte del identificador único de la entidad con la cláusula Primary Key cuando se define una tabla.

c)    Integridad referencial:

Consiste en vigilar que un dato que sirva de referencia en una relación o tabla del modelo relacional, de verdad exista en la tabla referenciada. El dato o conjunto de datos es llamado clave foránea y es clave primaria en otra entidad.

d)   Integridad definida por el usuario:

Son reglas establecidas por el propio diseñador de la base de datos y que corresponden a políticas o normas de la empresa.

La concurrencia es un fenómeno que se presenta en varios contextos. Uno de ellos es la multiprogramación ya que el tiempo del procesador es compartido dinámicamente por varios procesos. Otro caso son las aplicaciones estructuradas, donde la programación estructurada se implementa como un conjunto de procesos concurrentes. Y por ultimo se tiene que la misma estructuración recién mencionada es utilizada en el diseño de los sistemas operativos, los cuales se implementan como un conjunto de procesos.

Métodos de control de concurrencia

·         Protocolos basados en técnicas de bloqueo:

Operación usada para restringir las operaciones que se pueden aplicar sobre la base de datos. Existen varios tipos de bloqueo: binarios, compartidos, exclusivos, y bloqueos de certificación.

·         Bloqueos binarios:

Existen dos valores posibles, bloqueados y desbloqueados. Cada elemento de la base de datos tiene un bloqueo distinto. El bloqueo señala si una transacción está en ejecución sobre el elemento o está libre para que se pueda operar con él.

·         Bloqueos de lectura/escritura:

Existe tres posibles posiciones: libre, bloqueado para lectura, y bloqueado para escritura. De esta forma, más de una transacción puede tener un mismo elemento de datos bloqueado para lectura, pero sólo una para escritura.

·         Problemas del bloqueo en dos fases: interbloqueo y espera indefinida

ü  Exclusión mutua.- Cada elemento está bloqueado o está libre por una transacción.

ü  Retención y espera.- Una transacción que ya ha bloqueado elementos puede solicitar un elemento adicional, y esperar que se le asigne, sin habilitar ninguno de los elementos anteriores.

ü  No apropiación.- La transacción sólo puede liberar un elemento que tenga asignado; no se lo puede quitar a otra transacción que tenga mayor prioridad.

ü  Espera circular.- Existe una cadena circular, compuesta por dos transacciones o más, y otros tantos elementos intercalados, de manera que cada proceso está esperando que se le asigne un elemento, el cual, a su vez, está asignado al siguiente proceso de la cadena.

ü  Bloqueo mutuo o deadlock.- Un proceso se encuentra en estado de deadlock si está esperando por un suceso que no ocurrirá nunca.

3. Seguridad de la Base de Datos

Existe la necesidad de manejar nuestros datos de forma segura, estratégica y confidencial (no todos los usuarios pueden ver toda la información disponible). Un error o una brecha en nuestra base de datos pueden ocasionar graves problemas a nuestro sistema y sobre todo a la empresa u organización para la cual estamos trabajando. Las recomendaciones que damos en base a seguridad es seguir con los siguientes puntos:

ü  Integridad.- Solo los usuarios autorizados podrán tener acceso a modificar algunos datos. Disponibilidad.- Los datos deben estar disponibles para usuarios y programas de actualización autorizados.

ü  Confidencialidad.- Este punto consiste básicamente de la protección de los datos de aquellos usuarios no autorizados.

ü  Requisitos legales.- Es importante que aquellas personas que pueden tener acceso a cierta información personal de los pacientes. Ellos no pueden cambiar información personal sin la previa autorización del paciente

Algunos de los elementos que pueden ser ocultos en nuestra base de datos para algunos usuarios son los siguientes:

·         Un atributo de la tabla

·         Un conjunto de columnas

·         Una tupla individual

·         Un conjunto de tuplas de una relación

·         Una relación en particular

·         Un conjunto de relaciones

·         La base de datos completa

Todo dependerá de casa caso particular y de la información que requiera la empresa u organización mantener en secreto.

4. Recuperación de la BD

Ante un eventual fallo en una transacción dentro de la BD, es necesario que la BD se restaure al estado más reciente, anterior al fallo y donde funcione plenamente. Para que esto suceda, el sistema debe guardar información sobre los cambios que se realizan en los elementos de los datos. El objetivo principal de la recuperación es la de garantizar la propiedad de la atomicidad de una transacción. Los conceptos relacionados con la recuperación son:

Almacenamiento en caché: Esto es que los elementos de datos que se van a actualizar se almacenan en caché en los búferes de la memoria principal, para luefo actualizarse en memoria antes de escribirse de nuevo en el disco. Esta función tradicionalmente es del sistema operativo, pero la BD se encarga de hacerlo para asegurar su información.

Imágenes anterior y posterios a la actualización: Son los valores antiguos (imagen anterior, BFIM) y los valores nuevos (imagen posterior, AFIM) de un elemento de datos.

Políticas robar/no-robar y forzar/no-forzar: Si una página en caché actualizada por una transacción no puede escribirse en disco antes de que la transacción se confirme, se denomina método no-robar. De lo contrario, si el protocolo permite escribir un búfer actualizado antes de que la transacción se confirme, se denomina robar. Si todas las páginas actualizadas por una transacción se escriben inmediatamente en disco cuando la transacción se confirma, se denomina método forzar. De lo contrario, no-forzar.

Puntos de control del sistema: La toma de un punto de control consiste en cuatro acciones, las cuales son suspender temporalmente la ejecución de las transacciones, forzar la escritura en disco de todos los búferes de memoria que se hayan modificado, escribir un registro checkpoint en el registro del sistema para luego forzar la escritura del registro en disco, y reanudar la ejecución de las transacciones.

Existen también otros tipos de recuperación, los cuales son actualización diferida y actualización inmediata.

Actualización diferida: Las técnicas de este tipo de recuperación pospone cualquier actualización real de la base de datos en disco hasta que la transacción alcanza su punto de confirmación. La transacción fuerza la escritura del registro del sistema en disco antes de grabar las actualizaciones en la BD. Este tipo de recuperación puede llegar a conducir a un algoritmo de recuperación llamado NO-DESHACER/REHACER.

Actualización inmediata: estás técnicas pueden aplicar cambios en la BD en disco antes de que la transacción termine, pero cualquier cambio realizado debe primero grabarse en el registro del sistema y escribirse en disco para que las operaciones puedan deshacerse si es necesario.

En caso de un fallo catastrófico, lo mejor es realizar copias de seguridad periódicamente de la BD y del registro del sistema.

5. BASES DE DATOS CENTRALIZADAS

Es una base de datos almacenada en su totalidad en un solo lugar físico, es decir, es una base de datos almacenada en una sola máquina y una sola CPU, y en donde los usuarios trabajan en terminales “tontas” que sólo muestran resultados.

Los sistemas de bases de datos centralizadas son aquellos que se ejecutan en un único sistema informático sin interaccionar con ninguna otra computadora. Tales sistemas comprenden el rango desde los sistemas de base de datos monousuario ejecutándose en computadoras personales hasta los sistemas  de bases de datos de alto rendimiento ejecutándose en grandes sistemas. 

Arquitectura:

El CPU y los controladores de dispositivos que pueden ejecutarse concurrentemente, compitiendo así por el acceso a la memoria. La memoria caché reduce la disputa por el acceso a la memoria, ya que el CPU necesita acceder a la memoria, compartida un numero de veces menor.

Se distinguen dos formas de utilizar las computadoras: como sistemas monousuario o multiusuario. En la primera categoría están las computadoras personales y las estaciones de trabajo. Un sistema monousuario típico es una unidad de sobremesa utilizada por una única persona que dispone de una sola CPU, de uno o dos discos fijos y que trabaja con un solo sistema operativo que

Solo permite un único usuario. Por el contrario, un sistema multiusuario típico tiene más discos y más memoria, puede disponer de varias CPU y trabaja con un sistema operativo multiusuario. 

Ventajas.

Se evita la redundancia. En sistemas que no usan Bases de Datos Centralizadas, cada aplicación tiene sus propios archivos privados o se encuentran en diferentes localidades. Esto a menudo origina enorme redundancia en los datos almacenados, así como desperdicio resultante del espacio de almacenamiento; por ejemplo, una aplicación de personal y otra de registros educativos pueden poseer cada una un archivo que contenga información de departamento de los empleados. Estos dos archivos pueden integrarse (para eliminar la redundancia) si el Administrador de la Base de Datos (DBA) está consciente de los requerimientos de información para ambas aplicaciones, es decir, si el DBA tiene el control global necesario.

Se evita la inconsistencia. Ya que si un hecho específico se representa por una sola entrada (es decir, si la redundancia se elimina), la no-concordancia de datos no puede ocurrir.

Pueden hacerse cumplir las normas establecidas. Con un control central de la base de datos, el DBA puede garantizar que se cumplan todas las formas aplicables a la representación de los datos.   Las normas aplicables pueden comprender la totalidad o parte de lo siguiente:   normas de la compañía, de instalación, departamentales, industriales, nacionales o internacionales. Es muy deseable unificar los formatos de los datos almacenados como ayuda para el intercambio o migración de datos entre sistemas.

Pueden aplicarse restricciones de seguridad.

Al tener jurisdicción completa sobre los datos de operación, el DBA puede:

a)      Asegurar que el único medio de acceder la base de datos sea a través de los canales establecidos y, por tanto,

b)      Definir controles de autorización para que se apliquen cada vez que se intente el acceso a datos sensibles.   Diferentes controles pueden establecerse para cada tipo de acceso (recuperación, modificación, supresión, etc.) a cada parte de la información de la base de datos.

Puede conservarse la integridad. El problema de la integridad es garantizar que los datos de la base de datos sean exactos.  El control centralizado de la base de datos, es decir, que los datos se encuentren en una sola máquina, ayuda a evitar la inconsistencia de los datos, por el mismo hecho de encontrarse en una sola máquina. Es conveniente señalar que la integridad de los datos es un aspecto muy importante en una base de datos, porque los datos almacenados se comparten y porque sin procedimientos de validación adecuados es posible que un programa con errores genere datos incorrectos que afecten a otros programas que utilicen esa información.

Pueden equilibrarse los requerimientos contradictorios. Cuando se conocen los requerimientos globales de la empresa,  en contraste con los requerimientos de cualquier usuario individual, el DBA puede estructurar el sistema de bases de datos para brindar un servicio que sea el mejor para la empresa en términos globales.  Por ejemplo, puede elegirse una representación de los datos almacenados que ofrezca rápido acceso a las aplicaciones más importantes a costa de un desempeño  de menor calidad en algunas otras aplicaciones.

El procesamiento de los datos ofrece un mejor rendimiento y resulta más confiable que en los sistemas distribuidos.

Desventajas

·         Los mainframes (computadora central) no ofrecen mejor proporción precio/rendimiento que los microprocesadores de los sistemas distribuidos.

·         Por lo general, cuando un sistema de Base de Datos Centralizada falla, se pierde toda la disponibilidad de procesamiento y sobre todo de la información confiada al sistema.

·         En caso de un desastre o catástrofe, la recuperación es difícil de sincronizar.

·         Las cargas de trabajo no se pueden difundir entre diferentes computadoras, ya que los trabajos siempre se ejecutarán en la misma máquina.

·         Un mainframe en comparación con un sistema distribuido no tiene mayor poder de cómputo.

·         No se puede añadir poder de cómputo en pequeños incrementos, debido a lo complicado de esta operación.

6. ARQUITECTURA CLIENTE/SERVIDOR

A.  CONCEPTO DE ARQUITECTURA CLIENTE / SERVIDOR.

La tecnología Cliente/Servidor es el procesamiento cooperativo de la información por medio de un conjunto de procesadores, en el cual múltiples clientes, distribuidos geográficamente, solicitan requerimientos a uno o más servidores centrales.

Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información de forma transparente aún en entornos multiplataforma. Se trata pues, de la arquitectura más extendida en la realización de Sistemas Distribuidos.

Las siguientes características:

·       Servicio: unidad básica de diseño. El servidor los proporciona y el cliente los utiliza.

·       Recursos compartidos: Muchos clientes utilizan los mismos servidores y, a través de ellos, comparten tanto recursos lógicos como físicos.

·       Protocolos asimétricos: Los clientes inician “conversaciones”. Los servidores esperan su establecimiento pasivamente.

·       Transparencia de localización física de los servidores y clientes: El cliente no tiene por qué saber dónde se encuentra situado el recurso que desea utilizar.

·       Independencia de la plataforma HW y SW que se emplee.

·       Sistemas débilmente acoplados. Interacción basada en envío de mensajes.

·       Encapsulamiento de servicios. Los detalles de la implementación de un servicio son transparentes al cliente.

·       Escalabilidad horizontal (añadir clientes) y vertical (ampliar potencia de los servidores).

·       Integridad: Datos y programas centralizados en servidores facilitan su integridad y mantenimiento.

El Esquema de funcionamiento de un Sistema Cliente/Servidor sería:

1.    El cliente solicita una información al servidor.

2.    El servidor recibe la petición del cliente.

3.    El servidor procesa dicha solicitud.

4.    El servidor envía el resultado obtenido al cliente.

5.    El cliente recibe el resultado y lo procesa.

B.  COMPONENTES DE LA ARQUITECTURA CLIENTE/SERVIDOR

De estas líneas se deducen los tres elementos fundamentales sobre los cuales se desarrollan e implantan los sistemas Cliente/Servidor: el proceso cliente que es quien inicia el diálogo, el proceso servidor que pasivamente espera a que lleguen peticiones de servicio y el middleware que corresponde a la interfaz que provee la conectividad entre el cliente y el servidor para poder intercambiar mensajes.

Para entender en forma más ordenada y clara los conceptos y elementos involucrados en esta tecnología se puede aplicar una descomposición o arquitectura de niveles. Esta descomposición principalmente consiste en separar los elementos estructurales de esta tecnología en función de aspectos más funcionales de la misma:

·      Nivel de Presentación: Agrupa a todos los elementos asociados al componente Cliente.

·      Nivel de Aplicación: Agrupa a todos los elementos asociados al componente Servidor.

·      Nivel de comunicación: Agrupa a todos los elementos que hacen posible la comunicación entre los componentes Cliente y servidor.

·      Nivel de base de datos: Agrupa a todas las actividades asociadas al acceso de los datos.

Este modelo de descomposición en niveles, como se verá más adelante, permite introducir más claramente la discusión del desarrollo de aplicaciones en arquitecturas de hardware y software en planos.

C.   ELEMENTOS PRINCIPALES

CLIENTE

Un cliente es todo proceso que reclama servicios de otro. Una definición un poco más elaborada podría ser la siguiente: cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor. Se lo conoce con el término front-end.

Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:

·       Administrar la interfaz de usuario.

·       Interactuar con el usuario.

·       Procesar la lógica de la aplicación y hacer validaciones locales.

·       Generar requerimientos de bases de datos.

·       Recibir resultados del servidor.

·       Formatear resultados.

 

SERVIDOR

Un servidor es todo proceso que proporciona un servicio a otros. Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se lo conoce con el término back-end. El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos. Las principales funciones que lleva a cabo el proceso servidor se enumeran a continuación:

·       Aceptar los requerimientos de bases de datos que hacen los clientes.

·       Procesar requerimientos de bases de datos.

·       Formatear datos para trasmitirlos a los clientes.

·       Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.

D.   TIPOS DE ARQUITECTURA CLIENTE / SERVIDOR

Uno de los aspectos claves para entender la tecnología Cliente/Servidor, y por tanto contar con la capacidad de proponer y llevar a cabo soluciones de este tipo, es llegar a conocer la arquitectura de este modelo y los conceptos o ideas asociados al mismo. Más allá de entender los componentes cliente/middleware/servidor, es preciso analizar ciertas relaciones entre éstos, que pueden definir el tipo de solución que se ajusta de mejor forma a las estadísticas y restricciones acerca de los eventos y requerimientos de información que se obtuvieron en la etapa de análisis de un determinado proyecto. De hecho el analista deberá conocer estos eventos o restricciones del proyecto para que a partir de ahí, se puedan hacer las consideraciones y estimaciones de la futura configuración, teniendo en cuenta aspectos como por ejemplo, la oportunidad de la información, tiempo de respuesta, tamaños de registros, tamaño de bases de datos, estimaciones del tráfico de red, distribución geográfica tanto de los procesos como de los datos, etc.

En tal sentido se presenta, en primer lugar, un esquema de clasificación basado en los conceptos de Fat Client/Thin Client, Fat Server/Thin Server, es decir, basado en el tamaño de los componentes. En segundo lugar tenemos una clasificación según la naturaleza del servicio que nos ofrecen.

 

D.1.- POR TAMAÑO DE COMPONENTES

Este tipo de clasificación se basa en los grados de libertad que brinda el modelo Cliente/Servidor para balancear la carga de proceso entre los niveles de presentación, aplicación y base de datos. Dependiendo de qué segmento de las capas de software tenga que soportar la mayor o menor carga de procesamiento, se habla de Fat Client (Thin Server) o Fat server (Thin Client). Consideraciones de este tipo son importantes en el momento de decidir una plataforma de desarrollo, al mismo tiempo que pueden definir la viabilidad o no de las mismas para enfrentar un cierto número de restricciones impuestas por una problemática a resolver.

a)   FAT CLIENT (THIN SERVER)

En este esquema de arquitectura el peso de la aplicación es ejecutada en el cliente, es decir, el nivel de presentación y el nivel de aplicación corren en un único proceso cliente, y el servidor es relegado a realizar las funciones que provee un administrador de base de datos.

En general este tipo de arquitectura tiene mejor aplicación en sistemas de apoyo de decisiones (DSS: Decision Support System) y sistemas de información ejecutiva (EIS: Executive Information System), y como se concluirá más adelante, tiene pocas posibilidades de aplicarse en sistemas de misión crítica.

b)   FAT SERVER (THIN CLIENT)

Este es el caso opuesto al anterior, el proceso cliente es restringido a la presentación de la interfaz de usuario, mientras que el peso de la aplicación corre por el lado del servidor de aplicación.

En general este tipo de arquitectura presenta una flexibilidad mayor para desarrollar una gran variedad de aplicaciones, incluyendo los sistemas de misión crítica a través de servidores de transacciones.

D.2.- POR NATURALEZA DE SERVICIO

a)   SERVIDORES DE FICHEROS

Con un servidor de archivos, un cliente lo que hace es requerimientos de los mismos sobre una red. Esta es una forma muy primitiva de servicios de datos, la cual necesita intercambio de muchos mensajes sobre una red para hallar el dato requerido. Los servidores de archivos usan recursos compartidos sobre la red y son necesarios para crear repositorios de documentos, imágenes y archivos grandes sobre la red.

b)   SERVIDORES DE BASES DE DATOS

Este análisis está elaborado desde el punto de vista del modelo Cliente/Servidor, y está directamente relacionado con la arquitectura en dos planos, que se describirá en el apartado siguiente.

Obviamente la creación de aplicaciones Cliente/Servidor está asociada a la utilización de servidores de bases de datos relacionales SQL, y dependiendo de los requerimientos y restricciones se debe elegir entre una arquitectura dos o tres planos. Pero para una arquitectura centrada en un servidor de bases de datos, cualquiera de las modalidades dos planos, permite que un proceso cliente solicite datos y servicios directamente a un servidor de bases de datos. Según las distintas normas de SQL (SQL-89, SQL-92, SQL3) el servidor debe proveer un acceso.

Los servidores de bases de datos actuales son una mezcla de SQL estándar más otras extensiones propias de

cada proveedor

c)      SERVIDORES DE TRANSACCIONES

Estos tipos de sistemas se pueden implementar con cualquiera de las modalidades Cliente/Servidor en dos o tres planos, pero incorporan un elemento principal sobre el cual se elabora y basa toda la fortaleza de este modelo, el concepto de transacción.

Con un servidor de transacciones el proceso cliente llama a funciones, procedimientos o métodos que residen en el servidor, ya sea que se trate de un servidor de bases de datos o un servidor de aplicaciones. Lo importante es que el intercambio a través de la red se realiza mediante un único mensaje de solicitud/respuesta, es decir, independientemente de que se necesite ejecutar una o más funciones, una o más instrucciones o sentencias SQL, éstas son agrupadas en una unidad lógica llamada transacción; evitando así el intercambio a través de la

red de un mensaje solicitud/respuesta por cada sentencia SQL, el cual es el caso de los sistemas Cliente/Servidor dos planos, implementados a través de SQL remoto. Estas aplicaciones denominadas OLTP (On Line Transaction Proccesing) están orientadas a dar soporte a los procedimientos y reglas de los sistemas de misión crítica.

d)      SERVIDORES DE OBJETOS

Con un servidor de objetos, las aplicaciones Cliente/Servidor son escritas como un conjunto de objetos que se comunican. Los objetos cliente se comunican con los objetos servidores usando un Object Request Broker (ORB). El cliente invoca un método de un objeto remoto. El ORB localiza el método del objeto en el servidor, y lo ejecuta para devolver el resultado al objeto cliente. Los servidores de objetos deben soportar concurrencia. La parte central de la comunicación en los servidores de objetos es el ORB:

·       Elemento central y principal de esta arquitectura.

·       Bus de objetos. Permite la comuniación entre ellos.

·       Middleware avanzado: Permite llamadas estáticas y dinámicas a objetos.

·       Lenguaje de descripción de interfaces independiente del lenguaje de programación.

e)      SERVIDORES WEB

La primera aplicación cliente servidor que cubre todo el planeta es el World Wide Web. Este nuevo modelo consiste en clientes simples que hablan con servidores Web. Un servidor Web devuelve documentos cuando el cliente pregunta por el nombre de los mismos. Los clientes y los servidores se comunican usando un protocolo basado en RPC, llamado HTTP. Este protocolo define un conjunto simple de comandos, los parámetros son pasados como cadenas y no provee tipos de datos. La Web y los objetos distribuidos están comenzando a crear un conjunto muy interactivo de computación Cliente/Servidor.

7. Bases de Datos Distribuidas: soluciones homogéneas y heterogéneas, integradas, federadas o multibase.

Son la que almacenan datos que pertenecen lógicamente a un sólo sistema, pero se encuentra físicamente esparcido en varios “sitios” de la red. Un sistema de base de datos distribuidos 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 sistema de base de datos en sí mismo.

•  Los sitios trabajan en conjunto si es necesario con el fin de que un usuario de cualquier sitio pueda obtener acceso a los datos de cualquier punto de la red tal como si todos los datos estuvieran almacenados en el sitio propio del usuario.

CARÁCTERÍSTICAS DE LAS BDD

·         Los datos deben estar físicamente en más de un ordenador (distintas sedes)

·         Las sedes deben estar interconectadas mediante una red (cada sede es un nodo de la red)

·         Los datos han de estar lógicamente integrados (recuperación y actualización) tanto en local como remoto (esquema lógico global y único)

·         En una única operación se puede acceder (recuperar o actualizar) datos que se encuentran en más de una sede (acceso a datos locales o remotos)

·         Todas las acciones que necesiten realizarse sobre más de una sede serán transparentes al usuario (transparencia de distribución para el usuario)

ALMACENAMIENTO DISTRIBUIDO

Dada una relación R:

·      RÉPLICA: copia de R en emplazamiento diferente

·      FRAGMENTACIÓN: R dividida en fragmentos  diferentes almacenados en sitios diferentes.

·      RÉPLICA Y FRAGMENTACIÓN: R dividida en fragmentos que son replicados en sitios diferentes

VENTAJAS DE LAS BDD (I)

·      ORGANIZATIVAS:

ü Adaptación a la organización de la institución (unión de compañías/descentralización), respondiendo a cambios

ü Almacenar los datos donde son generados y/o usados, la mayor parte locales

ü Proporcionar autonomía local, controlándose desde cada nodo. Política general contra política local.

·      ECONÓMICAS:

ü Costes de comunicación y de creación de pequeños sistemas

·      TÉCNICAS:

ü Flexibilidad, acceso desde distintos lugares y por distintas personas a la vez

ü Fiabilidad/disponibilidad, en un determinado momento / intervalo. Varios sitios, duplicaciones, evitan fallos

ü Modularidad

ü Mejora del rendimiento, BD más pequeñas, operaciones de menor volumen

ü Crecimiento incremental, añadiendo poder de procesamiento y almacenamiento

DESVENTAJAS DE LAS BDD

·         Complejidad del sistema, desarrollo de software más costoso, problemas de sincronización, dificultad para conocer la corrección de los algoritmos paralelos, detección de caídas de nodos

·         Dependencia de la red de comunicaciones, sobrecarga de procesamiento de mensajes

·         Dificultad de diseño, fases adicionales

·         Poca madurez de los productos comerciales, orientados a replicación

·         Funciones de administración compleja, sincronización y coordinación

·         Dificultad de cambio, inexistencia de metodologías

·         Personal especializado

COMPONENTES DE UNA BDD

·         BD locales

·         SGBDD

·         Red de comunicaciones

·         Diccionario o directorio global

TIPOLOGÍA DE LAS BDD

·         SEGÚN EL GRADO DE HOMOGENEIDAD DE LOS SGBD LOCALES:

Ø SGBDD homogéneos: todos los SGBD locales son iguales

Ø SGBDD heterogéneos: los SGBD locales son distintos

·         SEGÚN EL GRADO DE AUTONOMÍA FUNCIONAL:

Ø SGBDD federados: total autonomía funcional (multibase de datos)

Ø SGBDD sin ninguna autonomía funcional local

·         SEGÚN EL GRADO DE AUTONOMÍA ORGANIZATIVA:

Ø Autonomía total: las decisiones se toman a nivel local

Ø Organización centralizada

ESQUEMAS DE UNA BDD

·         Esquemas locales y esquema global

·         Diccionario global integrado

DISEÑO DE BDD – ESTRATEGIAS

·         TOP-DOWN (descendente)

Ø  En un principio el diseño no existe.

Ø  Diseñador necesita identificar tablas, pero también su ubicación y la necesidad de replicación.

·         BOTTOM-UP (ascendente)

Ø  Cuando existen diseños previos.

Ø  Integración de esquemas existentes (ELL) al esquema global (ELG).

DISEÑO DE BDD – FRAGMENTACIÓN

·         RAZONES PARA FRAGMENTAR

Ø Encontrar unidad de distribución más adecuada.

Ø Disminuir cantidad de accesos remotos.

Ø Incrementar el nivel de concurrencia.

·         DESVENTAJAS

Ø Degradación del rendimiento.

Ø Complejidad de mantenimiento de la integridad referencial.