ManualBDInternet

Las bases de datos son una herramienta útil en el crecimiento de cualquier organización, el cúmulo y control de la información permite conocer índices y puntos neurálgicos, la información está disponible en momentos precisos y claves para el desarrollo de la misma, para la toma de decisiones debe ser oportuna y confiable. El llegar a este punto implica el implantar políticas y estrategias respecto a la información, y el Administrador de la base de datos es quien debe poner en práctica estas decisiones.

Las ventajas principales de las bases de datos como son de todos conocidas involucran la recuperación y manejo rápido y eficiente de la información, el control de la redundancia, evitar la inconsistencia de la información y el tener una mayor integridad de ella. Aunado a lo anterior podemos recalcar el poder de las aplicaciones Distribuidas y los sistemas cliente-servidor.

En una base de datos la información se encuentra en diversos archivos (tablas) y a su vez estos pueden alojarse en diversos dispositivos de almacenamiento (discos), incluso en diferentes servidores, sin embargo la información se maneja como un todo, de hecho se dice que la información es integrada, la mayor ventaja de esto es el compartir información, como resultado varios usuarios pueden acceder al mismo tiempo a la base de datos, incluso desde diferentes terminales y la transparencia del sistema evita que el usuario perciba la trascendencia y alcance de la aplicación.

Otro de los factores que sin duda alguna ha ayudado al desarrollo de las bases de datos son las nuevas tecnologías de almacenamiento y acceso a la información a través de diferentes medios, así como la madurez de los sistemas operativos que han creado bases sólidas para este tipo de aplicaciones.

Este concepto es un objetivo primordial en los sistemas de bases de datos. Se dice que un sistema es independiente de los datos cuando "los requerimientos de la aplicación no determinan la forma de organizar los datos y la técnica de acceder a ellos", la ventaja que nos ofrece es poder modificar la estructura de los datos sin afectar gravemente la aplicación. En un sistema independiente el conocimiento de la organización de los datos y la técnica de acceso a ellos no forma parte integral de la lógica y el código de la aplicación.

Todos los DBMS deben cumplir con la independencia de los datos, de esta manera la información es global para todos, al ser independientes no importa qué manejador sea el que acceda a la información, estos simplemente son datos y pueden visualizarse y manipularse desde cualquier DBMS. La ventaja que ofrece la independencia de los datos es que si se cambia la estructura de los datos, esta no afecte el código de programación del sistema, haciendo conversiones o validaciones innecesarias.

Así, podemos describir la independencia de los datos como la inmunidad de programas de aplicación a cambios en la organización lógica o física de los datos y viceversa, como decíamos anteriormente, el DBMS debe ser capaz de permitir cambiar la estructura de los archivos de información, cambiar los tipos de datos y longitudes de registros, hacer una administración optima de la información, permitir crear campos nuevos en base a información existente, importar o exportar datos a formatos estándar sin tener que alterar los programas de la aplicación.

Sin duda alguna muchos de los manejadores de bases de datos comerciales son robustos a estas variaciones, incluso los cambios se realizan en muchos de ellos sobre una interfaz gráfica y cada vez esta independencia se hace mas transparente e implícita en el DBMS.

La mayoría de los productos comerciales de bases de datos están enfocados al modelo relacional, de hecho este modelo representa la tendencia dominante en el mercado actual de estos sistemas y se dice que constituye el avance más importante en el campo de los estudios sobre las mismas. Esta es una de las razones por las cuales gran número de sistemas están basados en él, además de que la tecnología relacional cuenta con bases sólidas en ciertos aspectos de las matemáticas, esto refiere a que la parte manipulativa del modelo relacional está sustentado en el álgebra relacional. Esta ofrece un conjunto de operaciones explícitas como unión, reunión, restricción, intersección, proyección, producto, división y diferencia, que sirven para indicar al sistema como constituir alguna relación deseada partiendo de las relaciones dadas en la base de datos. De echo, el álgebra relacional en su descripción se acerca a un lenguaje de programación, la cual se sustenta matemáticamente en la lógica de conjuntos. Existe otra relación similar entre el álgebra relacional y el SQL, ciertamente dentro de la historia del modelo relacional él SQL ha tenido un papel fundamental en la evolución de éste. En 1985 aparece el Manejo de bases de datos por Ejemplos (QBE) y en 1986 el Instituto Nacional Americano de Normas (ANSI) y la Organización Internacional para la Estandarización (ISO) coinciden en adoptar el dialecto SQL como interfaz "oficial" para sistemas relacionales. A continuación describiremos los principios básicos del modelo relacional.

La integridad de la información es un punto básico en los sistemas de bases de datos, que nos garantiza que la información que acumulamos es confiable. Existen reglas de integridad que son específicas a la información de la base de datos. Estas implican que lo que trata de hacer el usuario es correcto, es decir que los datos introducidos tengan una relación con el mundo real (que sean válidos). Para esto se especifican rangos de valores que puedan aceptar los datos o si estos se obtendrán de una lista de valores y cual debe ser esa lista. Esta integridad la marca la naturaleza de la información que se maneja en el sistema. Por otro lado el modelo relacional incluye dos reglas generales de integridad. Generales en el sentido en que se aplican a toda las bases de datos. Estas dos reglas se refieren generalmente a las claves primarias y a las claves ajenas.

La regla de integridad de las entidades hace referencia especialmente a las claves primarias y dice así:

* Ningún componente de la clave primaria de una relación base puede aceptar nulos.

Entiéndase por nulos como información faltante por alguna razón, de esta forma en la práctica no se puede registrar información si se carece de una clave primaria, esto se justifica con la simple razón de que en una base de datos no registraremos información de algo que no podamos identificar.

La regla de integridad referencial está orientada a las claves ajenas y dice así:

De este modo si los valores de las claves primarias representan identificadores a Entidades, así los valores de clave ajena representan referencias a Entidades, una expresión lógica sería de la siguiente manera: Si B hace referencia a A, entonces A debe existir. Con esto advertimos que la integridad referencial exige concordancia de las claves ajenas, muy especialmente con las claves primarias.

Esta regla se formula en términos de estados de la base de datos, con lo cual derivamos que se puede incurrir en estados no validos que irrumpan dicha regla. Un caso puede ser el eliminar una tupla con clave primaria que sea parte de una relación dada, es decir que tenga correspondencia de claves ajenas en otra entidad.

Para prevenir este problema si eliminamos la tupla de clave primaria debemos de eliminar de igual manera las tuplas correspondientes a la relación en otras entidades, es decir hacer una eliminación en cascada, otra forma de irrumpir la regla podría ser el insertar una tupla de una relación asignándole una clave ajena sin tener esta una correspondencia en la entidad correspondiente a la clave primaria, como por ejemplo hacer un pedido con un proveedor no registrado.

Entiéndase por redundancia a la información que está repetida dentro de la base de datos. Ciertamente en una base de datos existe información que se encuentra más de una vez, pero esto debe ser en una expresión mínima, el motivo fundamental de la relación entre entidades dentro del modelo relacional es el evitar la redundancia de la información, pues con tan solo conocer la clave de una tupla se puede conocer el resto de la información correspondiente. El que en una base de datos exista redundancia de información implica el riesgo de tener datos inconsistentes si no se toman las medidas pertinentes. Sin embargo en modelos distribuidos la redundancia es una técnica de mejora al sistema, como lo veremos en capítulos posteriores.

Cabe recalcar que otro punto fundamental dentro de los sistemas es la seguridad. Entendiendo por seguridad de la base de datos a la protección de la información contra una revelación, alteración o destrucción no autorizada. De esta forma el sistema debe estar al tanto de ciertas restricciones que no deben ser violadas por los usuarios. Para esto debe existir un catálogo de usuarios y su correspondiente alcance. El administrador de la base de datos debe asignar los permisos correspondientes a cada grupo de usuarios, con esto se restringen derechos por cada grupo dependiendo del nivel y responsabilidad de cada uno de ellos dentro de la empresa, existen restricciones de aspecto legal, social o ético que deben ser aplicados en las políticas de seguridad del sistema e implantados en el alcance a los usuarios, de esta forma cada grupo ve el sistema desde un punto diferente, así se protege la información dentro del mismo.

Pero también se debe contemplar la seguridad de la información fuera del sistema de base de datos por eso esta administración va de la mano con la administración de los recursos de la red. Se puede tener un sistema de base de datos en un ambiente muy seguro, pero si fuera del sistema se puede copiar y editar la información, de nada serviría, para evitar un incidente se deben planear los directorios en donde se alojará la información y asignar de esta forma derechos sobre ellos a cada usuario en coordinación con el administrador la de red, para evitar un dolor de cabeza se deben plantear políticas a niveles empresa y de sistema ya que la seguridad debe ser global.

Son una colección de bases de datos múltiples, lógicamente interrelacionadas en una red de computadoras. Un sistema de manejo de base de datos distribuida (DBMS distribuido) es el software de sistema que permite el manejo de la base de datos distribuidas y hace la distribución transparente a los usuarios.

1. Los datos se almacenan en varios sitios. Se supone que cada sitio consiste lógicamente de un solo procesador. Incluso cuando algunos sitios son máquinas multiprocesadoras, la DBMS distribuida nada tiene que ver con el almacenamiento y manejo de los datos en estas máquinas.

2. Los procesadores están interconectados por una red de computadoras y no por la configuración de un multiprocesador. El punto importante aquí es la pérdida de interconexión de procesadores que tienen sus propios sistemas operativos y que funcionan independientemente.

3. La base de datos distribuida es pues una base de datos, no una mera colección de archivos que pueden ser almacenados individualmente en cada nodo de la red. Esto señala la distinción entre una base distribuida y un sistema de archivos distribuidos. Para hacer una base de datos distribuida, los datos distribuidos deberían estar lógicamente relacionados de acuerdo con algunos formalismos estructurales, y el acceso a los datos debiera ser a un nivel alto por medio de una interface común. De hecho, casi toda la investigación sobre sistemas de base de datos da por hecho este sistema de relaciones.

4. El sistema tiene la funcionalidad completa de un DBMS. No es ni un sistema de archivos distribuidos ni un sistema procesador de transacciones. El procesamiento de transacción no es sólo un tipo de aplicación distribuida, sino que también es una de las funciones entre muchas de las que otorga un DBMS distribuido. Sin embargo, un DBMS distribuido provee otras funciones, como el procesamiento y la organización de los datos. Lo que los sistemas de transacción no necesariamente hacen.

Estas definiciones son válidas en la tecnología actual de las bases de datos. Los sistemas distribuidos más recientes son construidos en redes de áreas locales en las que cada sitio es una sola computadora. La base de datos es distribuida así que cada sitio maneja una sola base de datos local. La siguiente generación será diseñada de manera distinta por el desarrollo de la tecnología, especialmente el surgimiento de multiprocesadores baratos y redes de alta velocidad. El diseño del sistema también se verá afectado por el aumento del uso de la tecnología de base de datos en la aplicación dentro de dominios que son más complejos que el procesamiento de datos comerciales y por la adopción amplia del modelo cliente-servidor, junto con la estandarización de la interfaz cliente-servidor. Así, los DBMS distribuidos incluirán servidores de base de datos con multiprocesadores conectados a redes de alta velocidad que los una a las máquinas de los clientes que corren un código de aplicación y participan en la ejecución de los requerimientos de las bases de datos.

Una base de datos distribuida como la que hemos definido es sólo una forma de proveer un apoyo al manejo de la base de datos. Hemos creado una clasificación de trabajo de alternativas de diseño posible a través de tres dimensiones:

Autonomía: se refiere a controlar la distribución e indica el grado en que un DBMS puede operar independientemente. Esto implica una serie de factores que toman en cuenta si los sistemas componentes que intercambian información pueden ejecutar independientemente transacciones, y si uno está permitido a modificarlos. Dos tipos de autonomía son la completa integración, la semi-autonomía y la autonomía total. Los sistemas completamente integrados, una sola imagen de la base total está disponible para los usuarios que quieren compartir la información en diversas bases de datos. Los sistemas semi-autónomos consisten de un DBMS que puede (y usualmente lo hace) operar independientemente pero que ha sido diseñado para participar de tal forma que hace la base de datos compartida. Sin embargo, en una base de datos autónoma, los componentes individuales existen independientemente del DBMS y no saben de la existencia de otros DBMS ni de cómo comunicarse con ellos.

Distribución: tiene que ver con los datos. Consideramos dos casos, ya sea que los datos estén distribuidos físicamente en sitios múltiples que se comunican entre sí o en alguna forma por un medio de comunicación o que están almacenados solo en un sitio.

Heterogeneidad: Se da en varias formas en los sistemas distribuidos, van de la heterogeneidad del disco duro y las diferencias de los protocolos de las redes hasta las variaciones de los manejadores locales.

Las formas importantes de heterogeneidad desde la perspectiva de los sistemas de base de datos son las diferencias en los modelos de los datos, interfaces, protocolos del manejo de transacciones. La taxonomía clasifica a las DBMS como homogéneos o heterogéneos.

El manejo transparente de datos distribuidos y replicados: Los sistemas de base de datos centralizados nos han llevado de un paradigma del procesamiento de base de datos, en el que la definición de datos y mantenimiento estaban implicados en cada aplicación, a un paradigma en el que tales funciones son abstraídas de las aplicaciones y colocadas bajo el control de un servidor llamado el DBMS. Esta nueva orientación da como resultado lo que conocemos como independencia de los datos. La tecnología de bases de datos intenta extender el concepto e independencia de datos a ambientes en los que los datos son distribuidos y replicados en un número de máquinas conectadas por medio de una red. La independencia de los datos está dada por una serie de formas de transparencia: transparencia de la red (y por lo tanto, la distribución), réplica de la transparencia, y la fragmentación de la transparencia.

El acceso transparente a los datos separa un sistema de más alto nivel de uno de bajo nivel en la implementación en otros asuntos. Así, los usuarios de la base de datos verían una sola imagen, lógicamente integrada, aun cuando estuviera físicamente distribuida, permitiéndoles el acceso como si se tratara de una base de datos centralizada.

La mayoría de los DBMS distribuidos comerciales no proveen un nivel suficiente de transparencia. Parte del problema es la falta de apoyo del manejo de datos replicados. Algunos sistemas no permiten la réplica de los datos a través de bases de datos múltiples; los sistemas que no lo permiten requieren que el usuario esté físicamente conectado a una de las bases de datos en un determinado momento. Algunos DBMS distribuidos intentan establecer sus propios esquemas de nombramiento transparentes, usualmente con resultados insatisfactorios. Un aspecto importante del problema es la falta de apoyo de un sistema operativo apropiado para la transparencia. La red de transparencia puede ser fácilmente asistida por un mecanismo de nombramiento transparente en el sistema operativo. El sistema operativo puede a su vez ayudar con la reproducción de la transparencia, dejando la tarea de la fragmentación de la transparencia al DBMS distribuido.

La transparencia total no es un objetivo universalmente aceptado. Grey argumenta que ésta hace más difícil el manejo de los datos y añade que " los códigos de aplicación con acceso transparente a las bases de datos geográficamente distribuidas tienen una manejabilidad pobre, pobre modularidad y un desempeño deficiente del mensaje". Propone un mecanismo de llamado del mecanismo remoto (RPC) entre los usuarios solicitantes y el servidor del DBMS donde los usuarios enviarían sus preguntas a un DBMS específico.

El manejo de base de datos es más difícil si el acceso transparente es proporcionado a los usuarios, y que la arquitectura del cliente-servidor con la comunicación basada en RPC sea el enfoque apropiado. De hecho, algunos DBMS distribuidos comercialmente están organizados en este estilo (por ejemplo, Sybase). Sin embargo, la meta original no debía abandonarse por tales dificultades. La cuestión es determinar quién, si la aplicación del usuario o la base de datos distribuida, debería tomar la responsabilidad de los datos reproducidos y del manejo de éstos. En nuestra opinión, le corresponde al BMS distribuido, ya que sus componentes pueden organizarse en un modelo cliente-servidor.

Confiabilidad a través de las transacciones distribuidas: Las bases de datos distribuidas pretenden mejorar la confiabilidad, ya que tienen componentes replicados y por lo tanto eliminan puntos únicos de fallo. El fallo de un solo sitio, o el fallo en la unión de la comunicación que hace de uno o más sitios inalcanzables, no es suficiente para bajar el sistema completo. En una base de datos distribuida esto significa que algunos de los datos son inalcanzables, pero con el cuidado adecuado, los usuarios pueden acceder a otras partes de la base. Este cuidado especial viene a formar apoyo para las transacciones distribuidas. Una transacción consiste de una secuencia de operaciones ejecutada como una acción atómica que transforma una base de datos de un estado consistente a otro, aun cuando un número no determinado de tales transacciones es ejecutado concurrentemente (a veces llamadas transparencia concurrente), y aun cuando las fallas suceden (atomicidad de fallo). Entonces, un DBMS provee garantías de apoyo de las transacciones que la ejecución concurrente de las transacciones del usuario no violen la consistencia de la base de datos en el aspecto del fallo de los sistemas siempre y cuando cada transacción sea correcta, esto es, que obedezca las reglas específicas para las bases de datos.

Las transacciones distribuidas actúan en sitios diversos, donde acceden a la base de datos local.

Con el apoyo total para las transacciones distribuidas, las aplicaciones del usuario pueden acceder una sola imagen lógica de la base de datos y confiar en el DBMS distribuido para asegurarse que sus peticiones serán ejecutadas correctamente sin importar lo que ocurra en el sistema. Correctamente significa que las aplicaciones del usuario no deben estar relacionadas con la coordinación de sus accesos a bases de datos locales individuales, es necesario preocuparse acerca de la posibilidad de fallos en la comunicación durante la ejecución de sus transacciones. Existe una relación entre las transacciones distribuidas y la transparencia, ya que ambas implican el nombramiento distribuido y el manejo del directorio.

El apoyo en la transacción requiere la implementación del control de concurrencia distribuido y los protocolos de confiabilidad distribuidos, los cuales son mucho más complicados que sus contrapartes centralizadas. El algoritmo de control de concurrencia distribuida típico es alguna variación del bien conocido control de la fase de cierre 2 (2Pl), dependiendo de la colocación de las tablas de cierre y de la asignación de las responsabilidades del manejo del cierre. Los protocolos de confiabilidad distribuida consisten en protocolos de compromiso y procedimientos de recuperación.

Los protocolos de ejecución obligan la atomicidad de transacciones distribuidas asegurando que una transacción determinada tenga el mismo efecto (ejecutar o abortar) en cada sitio donde éste exista, mientras que los protocolos de recuperación especifican cómo la consistencia de la base de datos global va a ser restaurada después de las fallas. En el ambiente distribuido, los protocolos de ejecución son de dos fases. En la primera fase establecen un acuerdo entre los diversos sitios tomando en cuenta el destino de una transacción. La acción acordada se lleva acabo en la segunda fase.

La reproducción de los datos incrementa la disponibilidad de la base de datos, ya que las copias de los datos almacenados en el sitio de un fallo o inalcanzable existen en otros sitios operacionales. Para llevar a cabo el copiado o reproducción es necesaria la implementación de protocolos de control. El procedimiento más común es el de la equivalencia de una copia, la que se lleva a cabo por medio del protocolo ROWA (léelo, escríbelo todo). En ROWA, una operación de lectura lógica de un dato reproducido se convierte en una operación de lectura física en cualquiera de sus copias, pero una operación de escritura lógica es convertida en una operación física en todas las copias.

El control concurrente y los protocolos de ejecución están dentro de los temas más estudiados en la investigación de las bases de datos distribuidas. Sin embargo, su implementación en los sistemas comerciales no está ampliamente difundida.

Mejor desempeño: el caso del desempeño superior para las bases de datos distribuidas está basado en dos puntos:

Primero, un DBMS distribuido fragmenta la base de datos conceptual, permitiendo a los datos sean almacenados en el lugar más próximo a su punto de uso. Esta característica, llamada localización de los datos, tiene dos ventajas potenciales:

1. Ya que cada sitio maneja solo una porción de la base de datos, la contención para el CPU y el servicio I/O no es tan difícil como el las bases de datos centralizadas.

2. La localización reduce la demora al acceso remoto, lo que generalmente ocurre en redes de área grande (por ejemplo, la tardanza en la propagación del mensaje de ida y vuelta mínimo en sistemas de satélite, es de un segundo aproximadamente).

La mayoría de los sistemas de base estructurada están diseñados para ganar el máximo beneficio en la localización de los datos. Los beneficios útiles de contención reducida y por lo tanto comunicación reducida pueden obtenerse solamente por medio de la fragmentación apropiada y la distribución de la base de datos.

Segundo, el paralelismo inherente de los sistemas distribuidos puede ser explotado por el inter-cuestionamiento (interquering) y el paralelismo de intra-cuestinamiento (intraquery). El paralelismo de inter-cuestionamiento es el resultado de la ejecución de múltiples consultas al mismo tiempo. El paralelismo de intra-cuestionamiento se logra cuando se rompe una consulta en varias peticiones (sub-peticiones), cada una realizada o ejecutada en sitios diferentes, entrando a una parte diferente de la base de datos distribuida.

Si el usuario entra a la base de datos solo para consultas (acceso de lectura), entonces el paralelismo de inter-cuestionamiento e intra-cuestionamiento implicaría que se reprodujera la información tanto como fuera posible. Sin embargo, debido a que la mayoría de los accesos no son sólo de lectura, la mezcla de lectura y de actualización, estas operaciones requieren la implementación de protocolos elaborados de ejecución y de control de concurrencia.

Actualmente los sistemas comerciales usan dos modelos de ejecución para llevar a cabo el mejoramiento en el desempeño:

La primera alternativa consiste en tener la base de datos abierta sólo para consultas (acceso sólo de lectura) durante las horas de operación regular, mientras que la información reciente es archivada. Entonces la base de datos se cierra a la actividad de las consultas durante las horas que no se trabaja, cuando la nueva información es corrida secuencialmente.

La segunda alternativa está basada en la multiplicación de la base de datos: dos copias, una para propósitos de consulta y la otra para actualizaciones o Updates por la aplicación de programas (llamada la base de datos de producción). A intervalos regulares, esta última es copiada en la de consultas. Esta alternativa no elimina la necesidad de implementar los protocolos del control en la concurrencia y de la confiabilidad para la base de datos de producción, ya que éstos son precisamente para sincronizar las operaciones de escritura en las mismas. Sin embargo, mejora el desempeño de las consultas, ya que pueden ejecutares sin la manipulación de la transacción.

Las características del funcionamiento de los sistemas de base de datos distribuida no son bien entendidas por que no hay suficientes aplicaciones verdaderas que provean una base sólida para los juicios prácticos. Además, los modelos de desempeño no están lo suficientemente desarrollados.

En un ambiente distribuido, la acomodación de los tamaños de la base de datos debería ser más fácil. Los exámenes en el sistema mayor pocas veces son necesarios, generalmente la expansión puede llevarse a cabo añadiendo poder de procesamiento y almacenamiento al sistema. Llamamos a esto el incremento a escala del tamaño de la base de datos. Tal vez no sea posible lograr un incremento lineal del poder, pero se han obtenido logros importantes que buscan hacerlo.

Muchos DBMS distribuidos comerciales operan en mini-computadoras y estaciones de trabajo porque son más baratas. Además, la mayoría de los DBMS distribuidos comerciales operan dentro de redes locales, para lo cual la tecnología de las estaciones de trabajo es la mas indicada.

Por otra parte, los futuros DBMS distribuidos pueden apoyar a las organizaciones jerárquicas en las que los sitios consisten en grupos de computadoras que se comunican en una red de área local, con una alta velocidad de conexión entre ellas.

Otro factor económico es la reducción de los costos. Consideremos una aplicación (control del inventario) que necesita llevarse a cabo en varias ocasiones. Si esta aplicación accede a la base de datos frecuentemente la distribución de los datos y su procesamiento a nivel local puede ser más económico que la ejecución de la aplicación en varios sitios y haciendo que los datos remotos ingresen en una base de datos central almacenada en otro sitio. Esta parte del argumento económico todavía causa controversia.

La comunidad de la base de datos todavía no tiene un entendimiento completo sobre las implicaciones del desempeño de todas las alternativas de diseño distribuido. Específicamente, se han planteado algunas preguntas sobre el agrandamiento o ampliación de algunos protocolos y algoritmos según los sistemas se distribuyan geográficamente o según cómo el número de componentes del sistema aumenta. Una inquietud es la conveniencia de los mecanismos de procesamiento-transacción distribuidos (el protocolo 2Pl y en particular el 2PC) en los sistemas de base de datos distribuidos basados en una amplia área de redes. Un avance importante está asociado con estos protocolos, y el implementarlos sobre un área de la red amplia y lenta puede traer dificultades.

Los problemas en el aumento del tamaño solo son parte de un problema más general, no tenemos un buen manejo del papel de las redes estructurales y de los protocolos en el desempeño de las bases de datos distribuidas. Casi todos los estudios sobre el desempeño que conocemos asumen un modelo simple de red de bajo costo. Lo inadecuado de estos modelos puede demostrarse fácilmente. Consideremos, por ejemplo, una base de datos distribuida que corre en una red de área local de tipo Ethernet. El mensaje se retrasa en Ethernet cuando la carga de la red incrementa y generalmente no puede ser agilizada. Entonces los modelos de desempeño real de un sistema de base de datos distribuida de tipo Ethernet no puede verdaderamente ser un retraso en la red constante o incluso una función de atraso que no considera la carga de la red. En general, el desempeño del algoritmo propuesto y de los protocolos en diferentes estructuras de la red en el área local, deja solo su comportamiento comparativo al moverse de las redes de área local a redes de áreas amplia.

La manera apropiada para tratar el problema de la ampliación es el desarrollado de modelos de desempeño generales y lo suficientemente poderosos, herramientas y metodología de medición. Tal trabajo se ha llevado a cabo durante algún tiempo para las bases de datos centralizadas pero todavía no se han extendido lo suficientemente para las bases de datos distribuidas.

Los diseñadores de las aplicaciones de las bases de datos distribuidas están enfrentando un nuevo problema:

¿Cómo distribuir los datos y programas en diferentes computadoras para obtener el desempeño deseado, la confiabilidad y la disponibilidad?

De esta manera el diseño de la distribución se convierte en un nuevo problema el cual requiere su propia teoría, metodología de diseño, y herramientas de apoyo.

El grado de sofisticación de los sistemas de manejo de bases de datos distribuidos (DBMS) se mide a menudo por el grado de la transparencia de distribución otorgado a los usuarios.

En una situación ideal, el usuario no necesita estar pendiente de la distribución de los datos, y el sistema toma la responsabilidad de distribuir las operaciones de acceso a las bases de datos en diversos sitios. Sin embargo, la distribución actual de los datos afecta todo el desempeño o funcionamiento del sistema: el tiempo y el costo requerido para acceder a los objetos de datos múltiples difieren grandemente dependiendo de si todos los objetos de los datos están almacenados en el mismo lugar o si se encuentran en varios sitios.

La reproducción o copiado de los datos afecta la confiabilidad y disponibilidad del sistema, ya que varias copias de la misma información se vuelven disponibles a modos o formas de fallo independientes. Al mismo tiempo, la reproducción de los datos afecta el funcionamiento debido al requerimiento de mantener la consistencia de las copias. Así, el diseñador de la base de datos debe considerar cuidadosamente la distribución de los datos, aún cuando el sistema tiene un alto grado de transparencia.

Un principio clave en el diseño de la investigación es alcanzar la localidad máxima de los datos y las aplicaciones. Mientras que las bases de datos distribuidas permiten una comunicación más sofisticada entre los sitios, la motivación principal para desarrollarlas es la de reducir la comunicación colocando a los datos tan cerca como sea posible de las aplicaciones que los usan. De este modo en una base de datos bien diseñada "el 90% de los datos deberían ser encontrados en el sitio local, y solo 10% en un sitio remoto".

Sin embargo, esto raramente sucede, más a menudo el diseñador se enfrenta con los intercambios porque varias aplicaciones necesitan acceder a los mismos datos desde diferentes lugares. En este caso, el diseño más efectivo es el que asegura la localidad al número más grande de aplicaciones. Una suposición básica de este trabajo es que el diseñador de la base de datos es capaz de predecir ambas propiedades lógicas que caracterizan la "localidad " de los datos con respecto a las aplicaciones e información cuantitativa mide la carga" de aplicaciones, en términos de frecuencia de la ejecución de las peticiones en cada sitio. De hecho, la dificultad del diseño de la distribución de la base de datos reside en la interferencia de consideraciones lógicas y cuantitativas.

La metodología del diseño de la base de datos distribuida varía de acuerdo con la estructura del sistema. Para las bases totalmente integradas, el diseño procede de abajo hacia arriba (Top-Down): desde el análisis de los requerimientos y diseño lógico global al diseño físico de cada base local. Para sistemas multidistribuidos, el proceso de diseño es Bottom-Up e implica la integración de las bases de datos existentes.

El paso de interés para nosotros en el proceso Top-Down es el diseño de distribución, el cual comprende el diseño de esquemas conceptuales locales por la distribución de entidades globales sobre los sitios del sistema distribuido. Las entidades globales están especificadas dentro del esquema conceptual global. En el modelo relacional, ambas identidades globales y locales son relaciones, y el diseño de la distribución considera las relaciones globales como locales. El asunto de investigación importante que requiere de atención es el desarrollo de una metodología de diseño de distribución práctica y su integración dentro del proceso general de modelado de los datos.

Los dos aspectos del diseño de distribución son la fragmentación y colocación. La fragmentación es la división de cada relación global en una serie de fragmentos relacionados. La colocación se centra en la distribución (posiblemente replicada) de estas relaciones a través de los sitios distribuidos del sistema.

La investigación sobre este aspecto se ha concentrado en la fragmentación vertical (proyectar) y horizontal (seleccionar) de la fragmentación de las relaciones globales. También se han procesado numerosos algoritmos de colocación basados en la formulación de optimizaciones matemáticas.

Ninguna metodología de diseño que combine las técnicas de división horizontal y vertical, y algoritmos verticales u horizontales han sido desarrollados completamente independiente. Si uno comienza con una relación global, hay algoritmos que descomponen de manera horizontal y otros de forma vertical en una serie de relaciones de fragmentos. Sin embargo, no existen algoritmos que fragmenten una relación global en una serie de relaciones fragmentadas en donde algunas están descompuestas horizontalmente y otras verticalmente. Los investigadores han señalado siempre que las fragmentaciones más cercanas a la vida real deberían estar mezcladas, pero la investigación sobre cómo sería esto posible aun no se realiza. Necesitamos una metodología de diseño que una a ambas.

La segunda parte del diseño de distribución, típicamente es considerada independiente de la fragmentación. El proceso, entonces, es lineal; la producción de la fragmentación es básica o materia de la colocación. A primera vista, el aislamiento de la fragmentación y los pasos de la colocación parecen simplificar la formulación del problema reduciendo el espacio de decisión. Sin embargo, un análisis más cuidadoso revela que aislando los dos pasos contribuye a la complejidad de los modelos de colocación.

Ambos modelos tienen procesos similares, difiriendo únicamente en los trabajos de fragmentación en las relaciones globales mientras que la colocación considera la relación de fragmentos. Ambas requieren información acerca de las aplicaciones del usuario (como la frecuencia con que éste accede a los datos y cuál es la interrelación de los datos), pero cada uno ignora cómo otros usan estos input.

El resultado es que los algoritmos de fragmentación deciden cómo dividir una relación en parte sobre la base de cómo una aplicación accede, pero los modelos de colocación ignoran la parte que este input tiene dentro de la fragmentación. Por lo tanto, los modelos de colocación tienen que incluir una vez más una especificación detallada de las relaciones entre las relaciones de los fragmentos y cómo el usuario tiene acceso a ellos. Un enfoque más prometedor es extender la metodología discutida arriba de modo que refleje la interdependencia de la fragmentación y las decisiones para la colocación.

Reconocemos que la metodología como la que proponemos puede ser compleja. Pero la combinación de estos dos pasos pueden tener efectos sinérgicos permitiendo el desarrollo de métodos aceptables de solución heurística. Algunos estudios realizados nos dan las esperanzas de que esto sea posible. En estos estudios, los investigadores construyeron un modelo de simulación de la base de datos distribuida, tomando como input un diseño de la base de datos específico y midieron su efectividad. El usar tales métodos para desarrollos herramientas que ayuden a los diseñadores humanos en vez de intentar reemplazarlos. Es quizás la forma más apropiada de resolver el problema del diseño.

Los procesadores de consultas distribuidas automáticamente llevan una consulta de alto nivel en una base de datos, el cual es visto como una sola base de datos por los usuarios, a un plan eficiente de ejecución de bajo nivel expresado en las bases de datos locales. Tal traslado o traducción implica dos condiciones importantes. Primero, el traslado debe ser una transformación correcta de la pregunta consulta de modo que el plan de ejecución realmente produzca el resultado esperado.

La base formal para esta tara es la equivalencia entre el cálculo relacional y el álgebra relacional, y la transformación de las reglas asociadas con el álgebra relacional. Segundo, la ejecución del plan debe ser óptima, esto es, debe minimizar la función de costo que incluye el consumo de los recursos. Así, el procesador de consulta debe investigar planes alternativos equivalentes para seleccionar el mejor.

Debido a la dificultad de referirse a los dos aspectos juntos, éstos se separan típicamente en dos pasos secuenciales: la localización de los datos y la optimización global. Estos pasos están generalmente precedidos por la descomposición de la consulta, la que simplifica la consulta de entrada y lo re escribe en álgebra relacional. La localización de los datos transforma una consulta algebraica de input expresada en la base de datos distribuida en una consulta fragmentada equivalente (una consulta expresada en fragmentos de la base de datos almacenados en varios sitios), los cuales pueden ser más adelante simplificados por transformaciones algebraicas. La optimización global de la consulta genera un plan de ejecución óptimo para la consulta fragmentada por medio de decisiones relacionadas con el ordenamiento de la operación, el movimiento de los datos entre los sitios, y la selección de ambos algoritmos locales y distribuidos para las operaciones de las bases de datos. La optimización global implica un sin número de problemas.

Estos tienen que ver con las restricciones impuestas en el costo del modelo, el enfoque en un sub-grupo del lenguaje de consulta, el intercambio entre los costos de optimización y los de la ejecución, y el intervalo de optimización y re optimización.

El modelo de costo es importante para la optimización global de consultas porque provee la abstracción necesaria del sistema de ejecución de la base de datos en términos de los métodos de acceso, y una abstracción de los términos de la base de datos distribuida en términos de esquemas físico de información y estadísticas relacionadas. El modelo del costo es utilizado para predecir el costo de ejecución de los planes de ejecución alternativos.

Aunque los lenguajes de consultas se han vuelto cada día más poderosos, la optimización de la consulta se enfoca comúnmente en un sub-grupo del lenguaje de consultas, seleccionado principalmente con predicados conjuntivos. Esta es una clase importante de consultas para la que existen buenas oportunidades de optimización. Como resultado, se ha desarrollado una buena cantidad de teoría para el ordenamiento de unión y semi-unión. Sin embargo, otros procesos de consultas importantes garantizan la optimización, como las consultas de disyunciones, uniones, puntos fijos, agregaciones. Una solución prometedora es separar la comprensión del lenguaje de la optimización misma, la cual puede ser dedicada a otros módulos de optimización.

Los costos de optimización más altos probablemente aceptables para producir mejores planes para consultas repetitivas, ya que estos planes reducirán el costo de ejecución de consultas y amortiguarían los costos de optimización sobre muchas ejecuciones. Sin embargo, los costos mas altos son inaceptables para las ejecuciones por una sola vez de las consultas. El costo de optimización se obtiene principalmente al buscar el espacio de solución para los planes de ejecución alternativa. En un sistema distribuido, el espacio de solución puede ser grande por el rango amplio de las estrategias de ejecución distribuida. Por lo tanto, el desarrollo de estrategias eficientes que eviten la búsqueda exhaustiva es importante.

La optimización del proceso de consulta global es comúnmente realizada antes de la ejecución del mismo (también llamada optimización estadística). Un problema más grande con este enfoque es el modelo de costo de optimización que pude resultar inexacto por los cambios en le tamaño del fragmento o la reorganización de la base de datos, la que es importante para equilibrar la carga.

El problema, entonces, es determinar los intervalos de optimización de recopilación de la consulta y la reoptimización, tomando en consideración el intercambio entre el costo de optimización y el de ejecución.

A principios de los años setenta, en proyectos de investigación, IBM ideó un lenguaje denominado Structured English Query Language (SEQUEL) para construir un sistema de gestión de base de datos relacional. Este lenguaje evolucionó hasta convertirse en SEQUEL/2 y finalmente en Structured Query Language (SQL, Lenguaje de consulta estructurado). Además hubo otras empresas que se interesaron por el concepto de bases de datos relacionales y la interfaz SQL que había surgido. Relational Software, Inc. (actualmente Oracle Corporation) creó un producto denominado Oracle en el año 1979. En 1981, IBM lanzó su primer producto, denominado SQL, Data System (SQL/DS).

En 1982, el American National Standards Institute (ANSI), dándose cuenta del significado potencial del modelo relacional, comenzó a trabajar en un estándar denominado Relational Database Language (RDL, Lenguaje de base de datos relacionales). La aceptación surgida 1984 en el mercado de productos tales como Oracle, SQL/DS y DB2 de IBM hizo que el comité ANSI pusiese su atención en SQL como la bases para el nuevo Estándar RDL. La primera versión de este estándar, SQL-86, fue adoptada tanto para ANSI como por el International Standards Organization (ISO) en octubre de 1986. En 1989, se adoptó una actualización de SQL-86 que abarcó las mejoras de la integridad. El estándar actual, al que en numerosas ocasiones se hace referencia como SQL2 o SQL-92, refleja el esfuerzo intenso llevado a cabo por las personas de los estándares internacionales para mejorar el lenguaje y corregir muchas características ambiguas, confusas y perdidas del estándar original de 1986.

El estándar existente actualmente representa tanto un subconjunto de las principales implementaciones comunes como un superconjunto de casi todas las implementaciones, es decir, el núcleo del estándar consta de características que podemos encontrar virtualmente en cada implementación comercial del lenguaje, aunque el estándar completo incluye características mejoradas que muchos vendedores ya han implementado.

Tal vez la cláusula más importante dentro del lenguaje sea la cláusula SELECT, su función es seleccionar de una tabla un conjunto de información en base a una condición específica, su sintaxis es la siguiente:

SELECT (Lista de campos) FROM (nombre de la tabla o tablas) WHERE (condición de fila)

Los comandos que están entre corchetes son optativos y se utilizan cuando deseamos que la información sea agrupada, desplegada si existe en un determinado grupo o si queremos ordenarla de alguna forma.

Para ejemplificar la cláusula SELECT tomemos en cuenta que tenemos una tabla llamada Municipios con los campos siguientes Clv_Municipio, Municipio, P_municipal, edad, Domicilio

y necesitamos conocer los nombres de los presidentes municipales mayores de 40 años, ordenado por municipio

En la lista de campos a seleccionar siempre son separados por una coma, al igual que la lista de tablas a utilizar, si existe más de una condición, esta debe ser agrupada utilizando los signos de agrupación, que por lo general son paréntesis.

Si traducimos a un lenguaje natural este enunciado, podría decirse de esta forma.

SELECCIONA el municipio, nombre del presidente, edad DE la tabla Municipios EN DONDE el promedio la edad del presidente sea mayor a 40

La cláusula para insertar un nuevo registro es INSERT y la sintaxis es la siguiente:

INSERT INTO (nombre de la tabla) VALUES (valor campo1, valorcampo2, valorcampo3)

Si insertamos un nuevo registro en nuestra tabla el enunciado sería el siguiente:

Otra cláusula importante es Update para actualizar grupos de registros en base a una condición o selección anidada.

UPDATE (nombre de la tabla a actualizar) SET (campo1=valor, campo2=valor, campo3=valor) WHERE [(condición de fila) o SELECT ()] .

Para ejemplificar la cláusula UPDATE, tomemos como ejemplo la tabla anterior modifiquemos los datos del presidente municipal de la ciudad de oaxaca.

La evolución que ha tenido el lenguaje a través de los años ha servido para ofrecer una amplia versatilidad en su uso, pues en versiones recientes se realizan conexiones ODBC, resguardo de seguridad en la base de datos, implantación de reglas de seguridad, creación de grupos de usuarios y demás herramientas que demanda un DBMS.

En las bases de datos distribuidas reproducidas las operaciones están especificadas en objetos de datos lógicos. Los protocolos de control de las réplicas son responsables de señalar una operación en un objeto de datos lógicos a una operación de copias físicas múltiples a este objeto de datos. Al hacerlo así, ellos aseguran la consistencia mutua de la base de datos copiada. La regla del ROWA mencionada con anterioridad es el método más usado para el refuerzo de la consistencia mutua, por lo tanto una base de datos copiada o reproducida está en un estado consistente mutuamente si todas las copias de cada objeto de datos tienen valores idénticos.

El campo de la réplica de datos necesita de futuras investigaciones y la experimentación en la reproducción de los métodos para computación y comunicación y sobre la aplicación sistemática de la aplicación de propiedades específicas. La experimentación es requerida para evaluar los argumentos hechos por los diseñadores de algoritmos y sistemas. Una de las dificultades de la evaluación cuantitativa de las técnicas de reproducción es la ausencia de modelos de incidencia de fallos comúnmente aceptados.

Por ejemplo, los modelos de Markov, a veces utilizados para analizar la disponibilidad alcanzada, asume la independencia estadística de los eventos de fallo individuales y la rareza de la división en la red en los sitios de las fallas. Actualmente no sabemos si cualquiera de estas suposiciones es sostenible, tampoco sabemos qué tanto los modelos de Markov son sensibles a ellas. La validación de los modelos de Markov por simulación no puede ser confiable en la ausencia de mediciones empíricas ya que las simulaciones a menudo implican las mismas suposiciones del análisis de Markov.

El uso de la medición empírica es importante para monitorear patrones de fallo en los sistemas de producción de la vida real, con el propósito de construir un modelo simple de cargas de fallo típicas.

Para alcanzar las metas gemelas de la reproducción de los datos disponibles y desempeño necesitamos proveer sistemas integrados en los que la reproducción de los datos va mana a mano con la reproducción de computación y comunicación (incluyendo I/O). Sólo la reproducción de los datos ha sido estudiada de forma intensa, relativamente poco se ha hecho en la reproducción o copiado de la computación y comunicación. La reproducción de la computación ha sido estudiada en varios contextos, incluyendo la ejecución de procesos duplicados sincrónicos, y la implementación de versiones diferentes del mismo software para salvaguardarlo en contra de los errores de diseño humano.

La reproducción de los mensajes de comunicación se ha estudiado en el contexto de proveer una distribución confiable de dicho mensaje, y sólo unos cuantos trabajos reportan la aplicación de los mensajes de I/O para mejorar la disponibilidad de los sistemas transaccionales.

Además de la reproducción o copiado, pero con relación a ésta, necesitamos más modelos transaccionales, especialmente modelos que exploten la semántica de aplicación para alcanzar un desempeño y disponibilidad más altos, así como en la concurrencia.

Como una primera aproximación, los modelos de transacción pueden clasificarse en dos dimensiones: La estructura de las transacciones y la estructura de los objetos en las que esa transacción opera. Junto con la dimensión de la estructura de transacción reconocemos las transacciones planas, las transacciones encerradas las transacciones abiertas como las sagas, y las estructuras que la incluyeran ambas abiertas y cerradas, en orden creciente de complejidad junto con la dimensión de la estructura del objeto, identificamos objetos simples (como las páginas) objetos como ejemplos de tipos de datos abstractos, y objetos complejos, otra vez en complejidad creciente.

Distinguimos los dos últimos para indicar que los objetos como ejemplos de tipos de datos abstractos apoyan la encapsulación (y por lo tanto son más difíciles de correr en las transacciones que los objetos sencillos), y sus tipos no participan en una jerarquía heredada.

Dentro de este contexto, la mayoría de trabajo del modelo de transacción en los sistemas distribuidos se ha concentrado en la ejecución de transacciones planas en objetos simples. Este punto en el espacio de diseño es bien entendido. Mientras poco trabajo se ha hecho en la aplicación de transacciones anidadas en objetos simples, mucho queda por hacer, especialmente en bases de datos distribuidas. Similarmente, se ha hecho un poco de trabajo en aplicar las transacciones simples a los objetos como ejemplos de tipos de datos abstractos y en objetos complejos. Estos son algunos intentos que deben seguirse atentamente para determinar o especificar su semántica total, su incorporación a la base de datos distribuida, su interacción con los manejadores de recuperación, y sus propiedades de distribución.

Los modelos de transacción complejos son muy importantes en los sistemas distribuidos por varias razones:

1. El procesamiento de la transacción en sistemas múltiples de bases de datos distribuidas pueden beneficiarse de la semántica reflejada de estos modelos.

2. La nueva aplicación que el DBMS distribuido apoyará en el futuro, requiere de modelos de transacción incorporando a operaciones más abstractas que se ejecuten en datos complejos.

Además estas aplicaciones tiene un paradigma en común diferente del acceso a la típica base de datos a la que estamos acostumbrados.

Se ha reconocido ampliamente el rechazo a correr un sistema de bases de datos distribuido o centralizado como una aplicación de un usuario ordinario en la cima de un sistema operativo huésped. Hay una diferencia entre los requerimientos del sistema de base de datos y las funciones de los sistemas operativos actuales. Esto es aun más cierto en el caso de los DBMS distribuidos, los cuales requieren funciones que los sistemas operativos distribuidos integrados no proveen. Además, las DBMS necesitan modificaciones en cómo los sistemas operativos distribuidos realizan sus funciones tradicionales (la programación en las actividades, nombramiento).

En esta sección, se resaltan los asuntos básicos de la integración en los sistemas y bases de datos distribuidos: arquitectura del sistema, el nombramiento transparente de los recursos, manejo persistente, comunicación remota, y el apoyo y transacción. Una consideración arquitectónicamente importante, es la conexión en el DBMS distribuido y los sistemas operacionales distribuidos, estos no son asunto de integración binaria. Los protocolos de la comunicación de la red deben ser considerados, aumentando la complejidad del problema. De este modo, el paradigma arquitectónico debe ser flexible como para acomodar las funciones de los DBMS distribuidos, los servicios de los sistemas operativos distribuidos, y los estándares de los protocolos de comunicación como el modelo ISO/OSI (interconexión de los Sistemas Abiertos) o el modelo IEEE 802. En este contexto, los esfuerzos que incluyen muchas funciones de la base de datos dentro del sistema operativo kernel o en aquellos que modifican los sistemas operativos fuertemente cerrados probablemente resultaran un fracaso. Los sistemas de operación deberían implementar solo los servicios esenciales del sistema operativo y aquellas funciones del DBMS que pueda implementar eficientemente.

El mejor modelo que se amolda a este requisito parece ser la arquitectura cliente-servidor con un kernel pequeño que provee las funciones de la base de datos que puedan ser proveídas eficientemente y que no limitan a la base de datos en la implementación eficiente de otros servicios al nivel del usuario. La orientación puede tener mucho que ofrecer como una estructura de sistema que facilita esta integración.

El nombramiento es el mecanismo fundamental disponible al sistema de operación para proporcionar un aspecto transparente a los recursos del sistema. Un asunto que todavía se discute es si que el acceso se da o no a los objetos distribuidos, ya que éste deberá ser transparente al nivel del sistema operativo. Para los DBMS distribuidos, la transparencia es importante. Como lo señalamos anteriormente, muchos DBMS distribuidos intentan establecer su propio esquema de nombramiento transparente sin mucho éxito. Se requieren investigaciones del asunto del nombramiento y la relación entre los directorios distribuidos y los servidores de nombres de los sistemas operativos. Dentro de este contexto vale la pena poner un poco de atención al concepto de capacidad, el cual ha sido usado por sistemas más viejos como Hidra y que esta siendo utilizado en sistemas operativos más modernos tales como Amoeba.

Datos que permanecen después de la ejecución del programa que los manipula es la función primaria de los sistemas de manejo de las bases de datos. Los sistemas operacionales tradicionalmente tienen que ver con los datos persistentes por medio de los sistemas de archivos. Si un paradigma exitoso de cooperación se encontrara, puede ser posible el uso de los sistemas de bases de datos como el sistema de archivos operante. Aun nivel más general, la cooperación entre los lenguajes de programación, los DBMS, el sistema operativo para el manejo los datos persistentes requiere de más investigaciones.

Los sistemas de archivos distribuidos no se refieren a las cuestiones de los DBMS porque no proveen un acceso concurrente a los datos o porque la granularidad de compartimento es muy grande.

Dos paradigmas que han sido ampliamente estudiados son el procedimiento de llamamiento remoto y el pase de los mensajes (lógico no físico). Los méritos relativos de estos planteamientos han sido discutidos ampliamente, pero la semántica simple del RPC (bloqueo, ejecución de una sola vez) ha estado inquietando a los diseñadores de los sistemas distribuidos. Como lo discutido con anterioridad, un acceso a los datos distribuidos basado en el RPC en el nivel del usuario aveces ha sido propuesto en lugar del acceso de transparencia total.

Pero la implementación de un mecanismo RPC para un ambiente computacional heterogéneo no es nada fácil. El problema reside en que los diferentes vendedores de los sistemas RPC no interoperan. Puede ser necesario ver a la comunicación en un nivel más alto de abstracción para superar la heterogeneidad y en los niveles más bajos de abstracción para lograr un mayor paralelismo. Este intercambio requiere de una investigación más amplia.

En los DBMS actuales, el manejador de la transacción está implementado como una parte del DBMS. La cuestión de que si las transacciones debiesen y pueden ser implementadas como parte de los servicios de los sistemas operativos ha sido largamente discutida. Existen argumentos fuertes en ambos lados, pero una clara resolución del asunto requiere más investigación así como más experiencia con los diversos servicios de manejo de transacciones con propósitos generales.

La organización de los sistemas múltiples es una alternativa a las bases de datos distribuidas lógicamente integradas. La diferencia fundamental entre los dos enfoques es a nivel de autonomía que cada uno tiene en los componentes de los manejadores de datos en cada sitio.

Mientras que los componentes de los sistemas de base de datos integrados están diseñados para trabajar juntos, los sistemas de manejo de bases de datos múltiples están integrados por componentes que pueden no tener noción de la cooperación. Específicamente, estos componentes son independientes en le DBMS, lo cual significa, por ejemplo, que aunque ellos pueden tener facilidades para ejecutar las transacciones, son incapaces de ejecutar transacciones distribuidas. En eta sección nos referimos a los problemas abiertos relacionados con el procesamiento de consultas y el manejo de la transacción en los sistemas de bases de datos múltiples. También mencionamos los asuntos de estandarización y su papel en la interoperabilidad.

La autonomía y la heterogeneidad potencial de los sistemas componentes crean problemas en el procesamiento de consulta y especialmente en la optimización de ellas. El problema básico es la dificultad de la optimización global cuando las funciones del costo global no son conocidas y cuando los valores de costo locales no pueden ser comunicadas a los multi-DBMS. Se ha sugerido que la optimización semántica basada solo en la información cualitativa pude ser lo mejor que podamos hacer, pero el procesamiento de consulta semántico tampoco es completamente entendido. Puede ser posible desarrollar optimizadores de consulta jerárquicos que lleven a cabo alguna cantidad de la optimización de consulta global y luego permita a cada sistema local realizar una optimización futura en la sub-consulta localizada. Esto puede no proveer una solución óptima pero puede permitir la optimización. Los estándares emergentes también pueden compartir alguna información de los costos más fácilmente.

La autonomía de los DBMS hace el procesamiento de la transacción en sistemas multi base de datos autónomos más difícil. Ya que son autónomos, tienen sus propios servicios de procesamiento de transacciones (manejador de la transacción, horarios, manejador de recuperación) y son capaces de aceptar transacciones locales y de correrlas completamente.

La base de datos múltiple tiene sus propios componentes de procesamiento de la transacción, a cargo de aceptar y de coordinar las transacciones globales que tienen acceso a las bases de datos múltiples. Una transacción global esta dividida en sub-transacciones, cada una de la cual está sometida a uno de los componentes del DBMS. Sin embargo, ya que el DBMS múltiple no está pendiente de las transacciones locales, no puede controlar los conflictos locales ni controla conflictos indirectos entre las transacciones globales causadas por la interferencia de las transacciones locales.

Varias soluciones se han propuesto para enfrentar el procesamiento de la transacción de las bases de datos múltiples concurrentes. Algunos usan la seriabilidad global de las transacciones como sus criterios de corrección; otros descartan la seriabilidad. La mayoría de este trabajo debería tratarse como intentos preliminares para entender y formalizar los asuntos. Un área de investigación es la revisión en el modelo de transacción y el criterio de corrección. El modelo de transacción integrada que parece particularmente prometedor para los sistemas multi bases de datos, y su semántica, basados en el conocimiento acerca del comportamiento de la transacción. En este contexto es necesario reconsiderar el significado de la consistencia en los sistemas de base de datos múltiples.

Otro asunto difícil que requiere de más investigación es la confiabilidad y los aspectos de recuperación de los sistemas de base de datos múltiples. La autonomía de los DBMS individuales hace difícil incorporar al 2 PC en el proceso de transacciones globales, de este modo haciendo difícil la atomicidad de la transacción distribuida. Los protocolos de confiabilidad y recuperación para los sistemas de bases de datos múltiples necesitan desarrollarse y ser integrados con los mecanismos de control de concurrencia.

La autonomía es un contribuyente importante a la complejidad adicional de los sistemas de base de datos múltiples. Uno de los mayores obstáculos para el desarrollo futuro de estos sistemas es la falta de la comprensión de la naturaleza de la autonomía. Lo que llamamos autonomía está probablemente compuesta por varios factores. Por lo tanto la naturaleza de la autonomía debe estar clara y muy precisamente caracterizada. Algunos investigadores consideran a la autonomía como si no fuera una característica del todo. Incluso la taxonomía que hemos considerado indicaba solo tres puntos en cuanto a esta dimensión. El espectro entre la no-autonomía y la autonomía total probablemente contiene muchos puntos diferentes. Es esencial en nuestra opinión definir lo que precisamente se entiende por "autonomía", delinear y definir los diferentes niveles de autonomía, e identificar el grado de la consistencia de la base de datos posible para cada nivel. Hasta ese momento tendrá sentido discutir los diferentes modelos de transacción y la semántica de ejecución apropiada para cada nivel.

Además este proceso debería permitir la identificación de una estructura en capas, similar a la del modelo ISO/OSI, para la ínteroperabilidad de sistemas de base de datos autónomos y posiblemente heterogéneos. El estructurar nos permitiría especificar los estándares que se interconectarán en niveles diferentes. Se está realizando un trabajo sobre el estándar de acceso a los datos remotos (RDA) y esta línea de trabajo hará contribuciones prácticas a la solución de los problemas posibles de la interoperabilidad.

Una de las características más comunes de la siguiente generación de los sistemas de base de datos es que necesitarán un modelo de datos más poderoso que el modelo relacional sin comprometer sus ventajas (independencia de los datos y alto nivel de los lenguajes de consulta). Cuando se utilizan en aplicaciones más complejas, los modelos de base de datos interrelacionales presentan limitaciones en términos de apoyo de los objetos complejos, el tipo del sistema, y la norma de manejo.

Para enfrentar estos problemas, se dos tecnologías bases de conocimiento y bases de datos orientadas al objetos están siendo investigadas. Otro asunto importante va a ser el desempeño del sistema según se añada más funcionalidad. Explotar el paralelismo disponible en los multiprocesadores de las computadoras es una forma prometedora de proveer un alto desempeño. Las técnicas diseñadas para las bases de datos distribuidas pueden ser útiles pero necesitan estar significativamente extendidas para implementar sistemas de base de datos paralelos.

Los sistemas de manejo de las basas de datos orientadas a los objetos (OODBMS) combinan la programación orientada en el objeto y las tecnologías de las bases de datos para proveer un mayor poder de modelado y flexibilidad a los programadores de las aplicaciones intensivas de los datos. Sin embargo, todavía es necesaria la realización de los estudios sobre este tipo de sistemas, ya que los ambientes distribuidos harán más difíciles los problemas. Además en esto también tienen que ver el manejo de los diccionarios y el manejo distribuido del objeto. No obstante, la distribución es esencial, ya que la aplicación que requiere la tecnología de OODBMS típicamente se levanta sobre ambientes de estaciones de trabajo conectadas por una red. Los primeros OODBMS comerciales (por ejemplo Gemstone) usaron una arquitectura cliente-servidor en la que múltiples estaciones de trabajo pueden acceder la base de datos centralizada en un servidor. Sin embargo, la base de datos distribuida orientada en el objeto dentro de una red de estaciones de trabajo (y servidores) se esta volviendo muy atractiva. De hecho, algunos OODBMS ya contienen alguna forma de transparencia de la distribución de los datos (Onto y Orion).

Los sistemas de manejo sobre la base del conocimiento intentan hacer al manejo de la base de datos más inteligente al manejar el conocimiento además de los datos. El capturar el conocimiento en la forma de reglas ha sido ampliamente estudiado en un tipo particular de sistema en base del conocimiento llamado una base de datos deductiva. Los sistemas de base deductivos manejan y procesan las reglas especificadas sobre grandes cantidades de datos dentro del DBMS en vez de un subsistema separado.

Las reglas pueden ser declarativas (aserciones) o imperativas (órdenes): el manejo de la regla es esencial, ya que provee un paradigma uniforme para poder desenvolverse en el control de la integridad semántica, panoramas, protección, deducción y órdenes. Mucho del trabajo en las bases de datos deductivas se han concentrado en la semántica de los programas de reglas y en las consultas deductivas de procesamiento, particularmente en la presencia de predicados negados y recursivos. Pero todavía ser requiere de mucho trabajo para combinar el apoyo de las reglas con capacidades orientadas hacia el objeto.

Por razones similares a las de las aplicaciones de los OODBMS, las aplicaciones con base en el conocimiento son muy probables que se constituyan en un ambiente de estaciones de trabajo. Estas aplicaciones pueden también resultar en ambientes paralelos computacionales cuando la base de datos es manejada por un servidor multiprocesador. En cualquier caso, nosotros podemos simplificar un sin número de asuntos al confiar en la tecnología de base de datos relacional distribuida.

Lo mismo que la mayoría de las OODBMS, que tratan de extender un lenguaje de programación orientado al objeto, esta similitud es una fuerte ventaja a la implementación de las bases de conocimientos en los ambientes distribuidos. Por lo tanto, los nuevos problemas tienen que ver más con el manejo de los conocimientos distribuidos, el procesamiento y la eliminación de virus de las bases de conocimiento y no tanto el manejo de los datos distribuidos.

Los sistemas de base de datos paralelos están diseñados para explotar las estructuras en la computadora de los multiprocesadores recientes para construir un alto desempeño y servidores tolerantes a las fallas. Por ejemplo, fragmentando la base de datos en varios nodos, podemos obtener más interconsultas y paralelismo. Por obvias razones tales como un procesamiento orientado en los grupos y utilidad de la aplicación, la mayoría del trabajo en esta área se ha enfocado en apoyar al SQL. La discusión continua en cuanto si una memoria compartida o un multiprocesador de memoria distribuida es más apropiado para el manejo de los datos. La respuesta a esta pregunta requiere de más estudios experimentales.

Los problemas de diseño de los sistemas de base de datos paralelos, tales como un sistema operativo de apoyo, y la compilación paralela son común a ambos tipos de arquitectura. Silos servidores de datos paralelos se vuelven dominantes, entonces podemos buscar un ambiente en el que varios de ellos estén colocados en una red principal, dando lugar a los sistemas distribuidos consistentes de grupos de procesadores. También los programas de consultas se tendrían que optimizar no solo para la ejecución en paralelo sobre un grupo de servidores, sino para la ejecución en toda una red.

Las promesas iniciales de los sistemas de base de datos distribuidas fueron el manejo transparente de los datos distribuidos y reproducidos o copiados, la confiabilidad mejorada del sistema por medio de las transacciones distribuidas, el desempeño mejorado del sistema por medio del paralelismo interconsultas e intraconsultas, y una expansión del sistema más fácil y económica, se pueden encontrar en varios grados en los productos comerciales actuales.

La realización plena de estas promesas depende no solo de que la tecnología comercial se actualice según los resultados de las investigaciones sino que también nosotros debemos resolver varios problemas.

1. Los modelos de desempeño, metodologías para medir la sensibilidad de los algoritmos propuestos y los mecanismos de la tecnología involucrada.

2. El procesamiento de consulta distribuido para manejar los métodos más complejos, el procesamiento de múltiples de consultas para guardar en trabajo común, y la optimización de los modelos de costo para determinar cuándo el procesamiento de consulta múltiple está siendo benéfico.

3. Los modelos de transacción avanzados que difieren de los definidos por el negocio del procesamiento de datos, reflejan mejor el modo común de procesamiento (compartición cooperativa, interacción del usuario, larga duración) en las aplicaciones de la tecnología de bases de datos distribuida van a apoyar.

4. Análisis de la reproducción y su impacto en los sistemas de base distribuidos y algoritmos, y el desarrollo de los protocolos de control de replicado eficiente que mejoren la disponibilidad del sistema.

5. La implementación de estrategias de los DBMS distribuidos que enfaticen mejor la interface y cooperación con los sistemas operativos distribuidos.

6. metodologías de diseño prácticas, correctas y completas para las bases de datos distribuidas.

7. La serie de problemas completa relacionada con la interconexión de los sistemas autónomos de procesamiento de la información.

La naturaleza cambiante de la tecnología de los DBMS distribuidos hará a los servidores de bases paralelas factible. Esto afectará de dos maneras los sistemas de base de datos distribuidos.

Primero, la implementación de los DBMS distribuidos en estos servidores de base paralelas requerirá la revisión de la mayoría de los algoritmos existentes y los protocolos para operar en las máquinas paralelas.

Segundo, los servidores de bases paralelas estarán conectados como servidores a las redes, requiriendo el desarrollo del DBMS distribuido que tendrán que ver con una jerarquía de maneadores de bases de datos. Además, como la tecnología de las bases distribuidas se infiltra en los dominios del procesamiento de datos no comerciales, las capacidades requeridas de estos sistemas cambiarán, obligando al cambio en el énfasis de los sistemas relacionales hacia modelos más poderosos. La investigación actual sobre estos asuntos se concentra en los sistemas de base de conocimiento y de orientación en el objeto.

El enfoque top-down es típico de las bases de datos distribuidas desarrolladas desde una planeación previa, mientras que el enfoque bottom-up es típico del desarrollo de los sistemas de base de datos múltiples como una agregación a los sistemas de bases ya existentes.

El primer enfoque supone que el diseñador entiende los requerimientos de un a aplicación de la base de datos del usuario, y la transforma en especificaciones formales. Durante este proceso, el diseñador lleva a cabo fases de diseño conceptuales, lógicas y físicas, las que progresivamente mejoran las especificaciones de alto nivel e independientes del sistema a la base de datos dentro de las especificaciones de bajo nivel y dependientes del sistema. Durante el diseño conceptual, el diseñador ignora cualquier detalle que tiene que ver con la implementación física (en particular, la distribución de los datos). El resultado es un esquema de base de datos global que incorpora, en un nivel abstracto, todos de los elementos de los datos de la base y los patrones de su uso.

Una fase de diseño específica de las bases distribuidas, llamada el diseño de distribución, indica el esquema global a varias, posiblemente encimando varios sub-esquemas, cada una representando el subgrupo de información que esta asociado con cada sitio. Luego el diseño de cada base de datos individual es completado.

En cambio el modelo bottom-up asume que una especificación de las bases de datos ya existe, ya sea por que hay bases de datos que tiene que ser interconectadas a un sistema de bases múltiples, o porque la especificación conceptual de las bases ha sido hecha para cada sitio independientemente. En cualquiera de los dos casos, las especificaciones de los sitios tienen que estar integradas para generar una especificación global.

Mientras que ambos enfoques parecen representar dos extremos opuestos, en muchos casos prácticos el diseñador procede usando ambos modelos.

La Web es un medio para localizar/enviar/recibir información de diversos tipos, aun con las bases de datos. En el ámbito competitivo, es esencial ver las ventajas que esta vía electrónica proporciona para presentar la información, reduciendo costos y el almacenamiento de la información, y aumentando la rapidez de difusión de la misma.

Internet provee de un formato de presentación dinámico para ofrecer campañas y mejorar negocios, además de que permite acceder a cada sitio alrededor del mundo, con lo cual se incrementa el número de personas a las cuales llega la información.

Alrededor de 14 millones de personas alrededor del mundo hacen uso de Internet, lo cual demuestra el enorme potencial que esta red ha alcanzado, con lo cual se puede decir que en un futuro no muy lejano, será el principal medio de comunicación utilizado para distintos fines.

Pero, no sólo es una vía para hacer negocios, sino también una gran fuente de información, siendo éste uno de los principales propósitos con que fue creada. Una gran porción de dicha información requiere de un manejo especial, y puede ser provista por Bases de datos.

En el pasado, las Bases de datos sólo podían utilizarse al interior de las instituciones o en redes locales, pero actualmente la Web permite acceder a bases de datos desde cualquier parte del mundo. Estas ofrecen, a través de la red, un manejo dinámico y una gran flexibilidad de los datos, como ventajas que no podrían obtenerse a través de otro medio informativo.

Con estos propósitos, los usuarios de Internet o Intranet pueden obtener un medio que puede adecuarse a sus necesidades de información, con un costo, inversión de tiempo, y recursos mínimos. Asimismo, las Bases de datos serán usadas para permitir el acceso y manejo de la variada información que se encuentra a lo largo de la red.

Como podemos ver, en base a temas anteriores, un servidor Web es un programa que se ejecuta en una computadora conectada a Internet, donde su trabajo es escuchar en un puerto TCP/IP predefinido las solicitudes de cliente y luego responder a navegadores Web con contenido basado en esas solicitudes. Cuando se escribe una dirección URL en el navegador, es proyectado en una dirección y puerto IP correspondiente a un servidor Web específico, Después de haber establecido una conexión, el cliente y el servidor se comunican con el Protocolo de transferencia de Hipertexto (HTTP). Por lo general el servidor Web envía un bloque de texto HTML en el navegador, mismo que analiza el HTML y puede solicitar contenido adicional como información gráfica. El modelo trabaja bien para la información estática, sin embargo si queremos hacer que nuestra página presente información en base a las peticiones tecleadas por el usuario, CGI (COMMON GATEWAY INTERFACE) es la respuesta. El servidor ejecuta un programa CGI como un proceso por separado para satisfacer las solicitudes de los usuarios, como puede ser una consulta a una bases de datos. Dado que un programa CGI es externo al navegador Web, puede ser escrito casi en cualquier lenguaje, ya sea compilado o interpretado. Los lenguajes populares de CGI son Perl, C, e incluso el shell de UNIX. Algunos servidores Web ofrecen bibliotecas e intérpretes para JAVA y Visual Basic para ser utilizados por programas CGI.

En la actualidad existen diferentes tipos de herramientas para implantar una base de datos en la World Wide Web. La capacidad y alcance del software disponible depende directamente del hardware con que se cuente para la implantación de la base de datos, del sistema operativo en función y del diseño de la misma. Este puede ser centralizado o distribuido. El servidor de base de datos puede alojarse junto con el servidor que atiende al navegador o en un servidor o servidores de bases de datos diferentes, en la misma red o en diversas redes. Otro factor importante es el número de usuarios esperados para consultar la base de datos y determinar un rango de usuarios contemplado, así como un crecimiento a futuro de la misma ya que del tamaño de las tablas dependerá también la rapidez de consulta. La calidad de los dispositivos de comunicación y la capacidad del servidor tienen gran relevancia para ofrecer un buen servicio a los usuarios.

Sin duda alguna el factor más importante para un buen desempeño en el rendimiento, es el sistema operativo. Esto determina la posible potencia de la base de datos. Los sistemas operativos han desarrollado base sólidas para este tipo de aplicaciones. Existen en el mercado sistemas UNIX, Windows, OS/2 con grandes capacidades y con un alto grado de estabilidad. En los últimos años se han desarrollado sistemas operativos experimentales con herramientas de comunicación.

Un ejemplo de ellos es Linux que se ha convertido en el sistema operativo para PC con capacidades Internet, pues configura todos los servicios en una computadora sin exigir gran requerimiento de hardware. Las máquinas UNIX que corren SunOS, Solaris, HP-UX o cualquier otra variedad de UNIX son las plataformas preferidas para bases de datos de gran tamaño. No olvidemos también la aceptación que Windows NT ha tenido en el mercado de los sistemas operativos de red y la madurez que ha alcanzando en los últimos Resource Kit.

Al elegir una base de datos se debe considerar no solo el tipo de dato, si no la cantidad de datos que va a almacenar. Si la cantidad de registros está en la escala de los cientos de millones el espacio de almacenamiento se vuelve crucial.

Para esto se deben considerar los controladores nativos del disco duro, controladores SCSI (Small Computer Systems Interface) y reflejo de datos. Los controladores SCSI son la norma en equipos Macintosh y UNIX. Estos pueden manejar hasta siete dispositivos cada uno y es posible utilizar varios controladores simultáneamente. Los discos duros también pueden utilizarse para reflejar datos (el reflejo es una técnica de resguardo de información) en más de una unidad. Si el motor de la base de datos acepta el reflejo de datos, estos pueden escribirse en dos discos diferentes para mayor seguridad. Si un disco falla, la base de datos se cambia automáticamente al otro, cuando la unidad original se devuelve al servicio, la base actualizará los datos en el disco reparado, o en uno nuevo, para que concuerde con el disco reflejado. Cuando el disco nuevo está completamente actualizado, la base conmuta al disco original y continúa reflejando la información en el disco alternativo.

Hoy en día existen otros métodos de resguardo de información. La tecnología Raid 5 (Independient Disk Array) es una de ellas. Este es un sistema de discos independiente con integración de códigos de error mediante una paridad. Los datos y la paridad son guardados en los mismos discos, por lo que se consigue aumentar la velocidad de demanda, ya que cada disco puede satisfacer una demanda independientemente de los demás. En el Raid 5 guarda la paridad del dato dentro de los discos y no hace falta un disco para guardar dichas paridades. La paridad se genera haciendo un XOR de los datos A0,B0,C0,D0 creando la zona de paridad PAR0. La paridad nunca se guarda en los discos que contienen los datos que han generado dicha paridad, ya que en el caso en que uno de ellos se estropeara como por ejemplo el dato A0, bastaría con regenerar la banda B0, C0,DO,PAR0 para que el dato vuelva a reestablecerse.

Un gateway es una conexión con el sistema operativo externo, la acción de llamar un programa CGI desde un navegador Web es muy sencilla para el usuario, lo cual es uno de los principales atractivos del Common Gateway Interface, el tener acceso a una base de datos a través de un programa CGI tiene una metodología propia, comúnmente el usuario hace clic sobre un botón predeterminado o sobre un vínculo, en este momento el navegador envía una solicitud de ejecutar el programa CGI al servidor Web, el servidor Web revisa la configuración y los archivos de acceso para asegurarse que se cuenta con el permiso de ejecución del programa CGI y se asegura de que este exista , cualquier resultado producido por el programa CGI se devuelve al navegador Web que despliega el resultado.

Los programas CGI son un gateway de doble sentido. Los datos pueden transferirse al programa CGI para su procesamiento, al igual los programas CGI pueden devolver información al servidor Web.

Con esto la información introducida por el usuario puede afectar el comportamiento del programa CGI, y los resultados devueltos por el programa son resultado directo de lo que introduce el usuario. En algunos casos los programas CGI se ejecutan al cargar la página y los resultados se despliegan como parte de la misma.

La interfaz proporciona un método para interactuar con una base de datos. Los proveedores de bases de datos pueden proporcionar una interfaz de varios niveles de complejidad dependiendo de las necesidades. Los gateway reciben datos transferidos desde un navegador Web mediante un servidor de HTTP y los convierten a un formato que la base de datos pueda entender. La información convertida se transfiere a la interfaz de la base de datos y esta la ejecuta. Los resultados se devuelven al programa de gateway, el cual los convierte a un formato de manera que el navegador los pueda desplegar.

Un gateway no puede trabajar solo, requiere de un tipo de canal para hacer contacto con la base de datos, este canal lo proporciona la interfaz de la base de datos, el cual es un software especial que suministra el proveedor. El gateway se comunica con la interfaz, la cual se pone en contacto con la base de datos.

Dependiendo de las necesidades de la aplicación, el diseño de base de datos puede o no tener capacidades de redes, esto lo determina el software del proveedor, el método más sencillo se alcanza con una base de datos sin capacidad de red, pues el servidor de HTTP, los programas CGI y el servidor de la base de datos están ubicados en la misma máquina, de esta forma los programas CGI tienen acceso a cualquier programa de interfaz que deseen utilizar, las consultas y los resultados devueltos no van y vienen a los programas CGI a través de la red, de esta manera se optimiza el tiempo de respuesta.

Sin embargo se supone que los navegadores están accediendo a la información de manera remota, si la base de datos es de mediano o gran tamaño, y hay muchos usuarios, no es buena idea tener el servidor de base de datos, el servidor de HTTP en la misma computadora. Si la base de datos incluye capacidades interconstruidas de redes tiene la opción de correr el servidor de HTTP en una máquina remota y acceder a la base de datos utilizando el software de bases para red, muchas veces es preferible ubicar en el servidor de HTTP los programas CGI y tener una máquina dedicada al servidor de la base de datos para evitar problemas potenciales y proteger los datos tanto como sea posible, este método funciona bien si se tiene más de un servidor de base de datos, un solo servidor de HTTP puede acceder a varias máquinas con bases de datos mediante programas CGI.

Este método aligera la carga de una base de datos y se refleja un notable incremento en el rendimiento, sin embargo esto sólo vale la pena en el caso de bases de datos verdaderamente grandes.

Cuando alguien usa un navegador Web para acceder a una base de datos hay varios componentes que intervienen para transferir la consulta del usuario a la base de datos y devolver los resultados al navegador, la acción se desarrolla de la siguiente manera: 1. El usuario llama a un programa gateway que utiliza CGI, haciendo clic en un Hipervínculo u oprimiendo un botón del formulario.

2. El navegador reúne toda la información escrita por el usuario para enviarla al programa CGI.

3. El navegador contacta al servidor de HTTP en la máquina donde reside el programa CGI, pidiéndole que localice a este último y le transfiere la información.

4. El servidor de HTTP corrobora si la máquina solicitante tiene autorización de acceso al programa CGI.

5. Si el usuario tiene acceso, el servidor de HTTP localiza el programa gateway y transfiere a este la información del navegador Web.

7. El proceso Gateway convierte la información recibida a un formato que la base de datos sea capaz de entender.

8. El Gateway usa el módulo de la base de datos para transferir la consulta a la interfaz de la base.

9. La interfaz de la base de datos analiza la sintaxis de la consulta para asegurar que sea precisa.

10. Si la interfaz encuentra un error de sintaxis en la consulta, se envía un mensaje de error al programa Gateway.

11. El mensaje de error se envía al servidor de HTTP, el cual lo transfiere al navegador Web para que este lo despliegue al usuario.

13. La base de datos atiende la consulta y devuelve los resultados al programa gateway a través de la interfaz.

14. El programa gateway formatea los resultados y los envía al servidor, por medio del CGI, para su envío al navegador Web.

Hacer inserciones, actualizaciones y eliminaciones requiere de un procedimiento más complejo que el necesario para hacer simples consultas. El código de inserción debe verificar si existen los datos en la base de datos, con el fin de evitar duplicidad en la información, el código de actualización debe asegurarse que la información exista, antes de modificarla, en caso contrario debe originarse un error. Las acciones de eliminación y edición debe de asignarse a un grupo reducido y confiable para evitar la eliminación de datos necesarios.

Para procesar algo mas que una simple consulta en un ambiente de esta naturaleza, es necesario algún tipo de control de acceso como lo pueden ser el comparar el identificador de conexión del usuario contra una lista de usuarios autorizados para determinada acción, asignar a cada tipo usuario un identificador de conexión y asignar a cada tipo nivel un nivel de acceso basándose en las funciones que tienen permitidas o utilizar la autenticación de clave de acceso de la base de datos destino para validar los niveles de acceso a los usuarios. En definitiva, el método que utilice depende de como planee utilizar el programa de gateway.

DBMS	PLATAFORMA
DBMS	UNIX	WINDOWS
Access		Cold Fusion dbCGI db-Connector dbWeb Extensiones ODBC para Perl-Win32 Internet Database Connector WebDBC West Wind Web Connection X-Works
Btrieve		Cold Fusion dbCGI db-Connector dbWeb Extensiones ODBC para Perl-Win32 Internet Database Connector WebDBC
Dbase		Cold Fusion DbCGI db-Connector dbWeb Extensiones ODBC para Perl-Win32 Internet Database Connector WebDBC
FoxPro		Cold Fusion DbCGI db-Connector dbWeb Extensiones ODBC para Perl-Win32 FoxWeb Internet Database Connector WebDBC West Wind Web Connection X-Works
Informix		Cold Fusion DbCGI db-Connector dbWeb Extensiones ODBC para Perl-Win32 Internet Database Connector WebDBC
Ingres	DbCGI	.
MINISIS	WebQuery	Interfaz WWW MINISIS
Micro CDS/ISIS	IsisWWW Iquery WWWIsis	IsisWWW Iquery WWWIsis
MiniSQL	Biblioteca API de MiniSQL W3-mSQL WDB
Oracle	DbCGI db-Connector Oraperl WDB WebDBC	Cold Fusion DbCGI db-Connector dbWeb Extensiones ODBC para Perl-Win32 Internet Database Connector WebDBC X-Works
Paradox		Cold Fusion DbCGI db-Connector dbWeb Extensiones ODBC para Perl-Win32 Internet Database Connector WebDBC
Progress	DbCGI	.
SQL Server		Cold Fusion dbCGI db-Connector dbWeb Extensiones ODBC para Perl-Win32 Internet Database Connector WebDBC West Wind Web Connection X-Works
Sybase	DbCGI WDB WebDBC Web.sql	Cold Fusion dbCGI db-Connector dbWeb Extensiones ODBC para Perl-Win32 Internet Database Connector WebDBC Web SQL X-Works

Lenguaje Estructurado de Consultas (SQL)