Benemérita Universidad Autónoma de Puebla

Facultad de Ciencias de la Computación

Aplicaciones de

Bases de Datos

Cliente Servidor

Dr. Manuel Martín Ortíz

marzo 2004
 B D / C S : : 2 0 0 4 : : M M

Dedicatoria

Cada vez que alguien escribe algo que se expone a terceros, expone la manera en que ve las cosas y lo que
espera del mundo.
Hay quienes solo escriben una vez y es para despedirse de sus semejantes.
Hay otros que no sabemos si escribieron y solo nos queda el recuerdo de ellos; de sus ideas, ilusiones, pla-
nes y demás cosas que todo el tiempo pensaron y pensamos, pero no saben ni sabemos si se cumplirán.
Se puede dedicar a los vivos en cuerpo, a los vivos en recuerdo y a otras clases de vivos.

Quiero dedicar este esfuerzo a alguien que al igual que muchos de los lectores de éste material
se inició en los secretos y ardides de la programación
perdió más de una vez la paciencia tratando de entender como resolver un problema
no conoció la frontera entre la noche y el día muchas veces hasta hallar una solución
olvidó la tarea el día de entrega a pesar de haberla hecho
utilizó sus mejores oficios para satisfacer las exigencias de los demás
emprendió la gran tarea de poblar nuestro planeta, al margen de conocer el mañana
construyó una familia y amistades que a veces la entendieron y otras no
sembró su simiente para no pasar desapercibida
dibujó sonrisas, melancolías, tristezas y otros sentimientos sin quererlo muchas veces
nos ha heredado sin decirlo la responsabilidad de ser mejores
nos dejó la tarea de continuar construyendo lo que no pudo hacer, pero pensó
nos dejó caminando, soñando y estando, sin poder replicar

Para RITA de corazón (q.e.p.d).

Abril de 2004

Manuel Martín Ortíz

2
 B D / C S : : 2 0 0 4 : : M M

Introducción
Este material se ha desarrollado como guía de curso. Cubre los elementos básicos teóricos y prácticos
acerca de “Aplicaciones de Bases de Datos Cliente Servidor”.

El objetivo de éste material es mostrar los fundamentos para crear Aplicaciones de Bases de Datos en el
Modelo Cliente servidor, en particular se hará énfasis en el esquema concreto de Internet, el cual se puede
reutilizar en una Intranet Corporativa.

Para la parte práctica se utilizarán aplicaciones de corte “libre” robustas, multiplataforma, documentadas y
de uso generalizado.

Los capítulos que comprende el material son los siguientes:

1. Introducción al Modelo Cliente Servidor. En éste se explica el modelo, sus mecanismos de opera-
ción y los procesos involucrados en la ejecución de tareas.

2. Acceso Bases de Datos sobre la Web. Como contenido del tema se explican los detalles que deben
ser contemplados en el modelo cliente servidor para el caso de las Bases de Datos, los aspectos especí-
ficos relativos a la seguridad y las metodologías clásicas de operación.

3. Acceso a Bases de Datos Remotas con PHP/MySQL. En éste tema se hace un resumen de las
diferentes técnicas y herramientas de software que permiten el acceso a Bases de Datos Remotas.

Al final se incluye la Bibliografía sobre la cual se apoya éste material.

Este material se acompaña de un conjunto de materiales electrónicos compilados en un CD, en él se inclu-

ye las herramientas de trabajo, manuales, ejemplos y programas auxiliares complementarios.

Por último quiero decir que los errores en éste material son responsabilidad de quién lo presenta de mane-
ra exclusiva.

3
 B D / C S : : 2 0 0 4 : : M M

CONTENIDO

DEDICATORIA........................................................................................................................................................... 2

INTRODUCCIÓN ....................................................................................................................................................... 3

CAPÍTULO 1. INTRODUCCIÓN AL MODELO CLIENTE SERVIDOR ........................................................... 5

1.1. INTRODUCCIÓN ..................................................................................................................................................... 5
1.2. COMPONENTES BÁSICAS DEL MODELO CLIENTE SERVIDOR.................................................................................. 6
1.3. ELEMENTOS DE BASES DE DATOS DISTRIBUIDAS ................................................................................................. 9
1.4. SISTEMAS CLIENTE – SERVIDOR. ........................................................................................................................ 12
CAPÍTULO 2. ACCESO A BASE DE DATOS SOBRE LA WEB ....................................................................... 16
2.1. ARQUITECTURA DE UNA APLICACIÓN WEB CON ACCESO A BD. ......................................................................... 16
2.2. EL PROTOCOLO DE COMUNICACIÓN HTTP. ........................................................................................................ 17
2.2.1. URL.............................................................................................................................................................. 18
2.2.2. Protocolo HTTP........................................................................................................................................... 19
2.2.3. Lenguaje HTML........................................................................................................................................... 23
2.3. ESTÁNDARES DE INTERACCIÓN. .......................................................................................................................... 26
2.4. CATEGORIZACIÓN DE LA INTERFACES WEB/DBMS............................................................................................ 26
2.4.1. El Common Gateway Interface (CGI) ......................................................................................................... 27
2.4.2. Interfaz de Programación de Aplicaciones (API)........................................................................................ 27
2.4.3. Interfaz de Programación de Aplicaciones del Servidor Internet (ISAPI) .................................................. 28
2.4.4. Java y JDBC ................................................................................................................................................ 29
2.4.5. JavaScript .................................................................................................................................................... 30
2.4.6. Oracle [13, cap 7] ....................................................................................................................................... 31
2.4.7. Cold Fusion ................................................................................................................................................. 32
2.4.8. Perl .............................................................................................................................................................. 34
2.4.9. C# ................................................................................................................................................................ 36
2.4.10. PHP ........................................................................................................................................................... 37
- PHP/FI................................................................................................................................................................. 37
- PHP 3.................................................................................................................................................................... 38
- PHP 4.................................................................................................................................................................... 38
- PHP 5.................................................................................................................................................................... 39
CAPÍTULO 3. ACCESO A BD REMOTAS CON PHP/MYSQL ......................................................................... 40
3.1. ELEMENTOS DE LA APLICACIÓN .......................................................................................................................... 41
3.1.1. Formas en HTML ........................................................................................................................................ 42
3.1.2. Interfase de Usuario .................................................................................................................................... 44
3.1.3. Programas de atención................................................................................................................................ 45
3.1.4. Servidor de Web y Manejador de Base de Datos......................................................................................... 45
3.2. MYSQL .............................................................................................................................................................. 45
3.3. APACHE .............................................................................................................................................................. 46
3.4. PHP .................................................................................................................................................................... 47
3.5. CONSIDERACIONES PARA EL DESARROLLO DE APLICACIONES CS ....................................................................... 49
3.5.1. Tipos de acceso............................................................................................................................................ 50
3.5.2. Manejo del origen de los accesos ................................................................................................................ 51
3.5.3. Disponibilidad ............................................................................................................................................. 52
3.5.4. Colaboración y apoyo.................................................................................................................................. 52
3.6. CONSIDERACIONES FINALES ............................................................................................................................... 53
BIBLIOGRAFÍA........................................................................................................................................................ 54

4
 B D / C S : : 2 0 0 4 : : M M

Capítulo 1. Introducción al Modelo Cliente Servidor

El Modelo Cliente Servidor es una abstracción que nos permite separar conceptualmente los mecanismos
y procesos que realizan aplicaciones que de manera cooperativa resuelven una serie de problemas no loca-
les.

1.1. Introducción

Las aplicaciones locales son aquellas que para resolver un problema solo requieren de los recursos que un
sistema de cómputo aislado ofrece. El siguiente nivel lo forman las aplicaciones que para resolver un pro-
blema se apoyan en sistemas de cómputo auxiliares que brindan acceso a uno o más recursos de manera
negociada, de tal manera que sin esos recursos externos el problema no es soluble.

Una aplicación local en función del Sistema Operativo que se este utilizando tiene acceso a los recursos
locales conforme a las restricciones que se imponen a los usuarios o procesos, en la época moderna es
corriente que a cada usuario se le brinden permisos de acceso a los medios, por ejemplo se definen cuotas
de disco, procesador, memoria, ancho de banda para el acceso a la red y número de procesos en ejecución
concurrente. Por otro lado los archivos se organizan de tal manera que su acceso (lectura, escritura y ejecu-
ción) depende de los permisos que se dan a los usuarios o bien grupos de usuarios. Estas reglas si bien
limitan la operación libre incrementan la seguridad de los sistemas de cómputo. La imposición de dicho
esquema se vuelve prioritaria cuando a un sistema de cómputo tienen acceso varios usuarios y se busca
proteger la información de cada uno de ellos, es decir se genera un sistema de privacidad y compartimenta-
ción. En general en estos ambientes los usuarios pueden compartir datos y programas de manera volunta-
ria cambiando los permisos de acceso para uno o varios miembros de los grupos de trabajo en los cuales él
participa, donde el control sobre su información lo mantiene él de manera dinámica.

En los sistemas en red este esquema organizativo se extiende y especializa. Muchas de las reglas se impo-
nen a través de los servicios que el Sistema Operativo de Red ofrece y otras las definen las aplicaciones
concretas mediante archivos de configuración, a los cuales tiene acceso y administra cada usuario y dueño
de los datos y programas. Este modelo para ser operativo requiere de acuerdos y negociaciones entre los
usuarios y administradores. Entenderemos por administradores a aquella clase de usuarios que pueden
imponer restricciones y dar permisos de acceso a una o varias aplicaciones o bancos de información al
resto de usuarios.

Hace no muchos años el ámbito de los sistemas de cómputo cooperativos organizados en redes era un
poco restringido, pero con el desarrollo de las redes públicas y privadas de bajo costo estos sistemas se han
generalizado, de tal suerte que se han vuelto cotidianos y de gran impacto para compartir información
entre usuarios remotos. La expresión más impactante es el denominado de manera popular “Internet” o
“Web”. Los cambios que ha producido su amplio uso en las maneras de relación en los diferentes ámbitos
de la dinámica social y económica son relevantes e impactan en la toma de decisiones contemporánea.

El papel que tienen las personas involucradas en el desarrollo de estos sistemas es fundamental, ya sea
como creadores de herramientas de desarrollo o bien como usuarios de ellas. En particular recae sobre los

5
 B D / C S : : 2 0 0 4 : : M M

especialistas en Sistemas y Computación dicha responsabilidad, esperándose de ellos que sean capaces de
implementar soluciones en éste entorno.

Para este fin es necesario conocer y saber manejar los fundamentos teóricos - prácticos de los sistemas
distribuidos y sus variantes, donde el esquema tradicional más simple que resuelve esta clase de problemas
son las Aplicaciones de Cómputo Cliente – Servidor.

1.2. Componentes básicas del Modelo Cliente Servidor

Una aplicación cliente servidor se basa en el modelo de solicitud – respuesta, el caso más simple corres-
ponde a la situación en la cual una aplicación (el cliente) solicita un recurso y otra (el servidor) la atiende
para brindarle el servicio de ser posible. En el siguiente esquema (Fig. 1.1) se muestra dicho proceso.

Solicitud

Cliente Servidor

Respuesta

Fig. 1.1. Modelo Simple de interacción Cliente - Servidor

En los sistemas aislados se ha explotado este modelo para controlar y administrar algunos recursos, como
ejemplo podemos citar algunos componentes del SO (Sistema Operativo): el administrador de procesos, el
manejador de ventanas en ambientes orientados a ventanas en ambiente gráfico y el gestor de medios de
almacenamiento masivo (discos, duros, CD’s, DVD’s, etc.). Donde debemos recalcar que a pesar de tratar
el caso de sistemas modernos monousuario, ya que éstos ofrecen la opción de la multitarea, es necesario
controlar las acciones de los procesos que el usuario ejecuta en primer o segundo plano para evitar conflic-
tos e inconsistencias.

Para regular las relaciones entre el cliente y el servidor normalmente se definen reglas, las cuales se encap-
sulan en librerías que permiten la operación entre las entidades involucradas. Estas reglas conforman los
denominados protocolos de interacción. Y los procedimientos públicos habilitados para la interacción se
organizan en Interfaces de Programación de Aplicaciones (API). Este binomio permite a los desarro-
lladores conocer como utilizar los métodos de trabajo, las variables involucradas y sus tipos, así como el
alcance y restricciones de explotación.

En los sistemas de cómputo conectados en red local (LAN) o en redes amplias (WAN), además se deben
tomar en cuenta las facilidades que el Sistema Operativo de Red (NOS) ofrece, así como las restricciones

6
 B D / C S : : 2 0 0 4 : : M M

que impone. De aquí se puede inferir que es importante conocer y controlar no solo la dinámica de lo que
sucede en cada nodo de la red, sino como se deben coordinar los diferentes nodos y medios de enlace
entre ellos, es decir se deben considerar cada uno de los elementos involucrados en el sistema: locales, re-
motos e intermediarios.

Un ejemplo de aplicación cliente servidor corresponde a los denominados Sitios de Conversación (Chat),
analicemos su estructura general (Fig. 1.2): En la red se destina una máquina que sirve como nodo de con-
fluencia para los usuarios, para lograr la funcionalidad deseada se instala un “programa” que recibe los
textos de cada usuario y los publica colocando el “alias” de cada usuario como prefijo, este programa juega
el papel de Servidor de Chat. En los nodos de los usuarios de instala otra aplicación que envía – los textos
que escribe cada integrante del grupo – al servidor y recibe una actualización del pizarrón común cada vez
que hay un cambio en él.

Usuario A Usuario B Usuario N

(Cliente de Chat) (Cliente de Chat) (Cliente de Chat)

Servidor de Chat

Fig. 1.2. Modelo cliente servidor para un Chat

En el siguiente cuadro se muestran los procesos básicos que se ejecutan durante la operación del Chat.

T Servidor Cliente
T+0 El programa inicia y espera a que se conecte algún cliente.

T+1 El cliente inicia y el usuario envía un texto al servidor

T+2 El servidor recibe el mensaje y lo envía a todos los clientes

conectados

T+3 El cliente recibe una copia del pizarrón si hay cambios

Bajo este esquema cada vez que el servidor recibe un nuevo texto, dado que se produce un cambio en el
“pizarrón”, se envían a los clientes activos los cambios y en consecuencia todos pueden leer lo que los
demás escriben de manera local en sus terminales, incluyendo sus propios textos.

Es lógico esperar que si el servidor se apaga o se desconecta de la red, entonces los clientes perderán con-
tacto y para reanudarlo requieren que la rutina vuelva a comenzar. Este es uno de los cuellos de botella
típicos de los sistemas cliente – servidor, cuando falla la aplicación servidora o bien el enlace de red, el sis-

7
 B D / C S : : 2 0 0 4 : : M M

tema estero falla, a pesar que los clientes estén arriba. Esto se debe a que la aplicación es fuertemente de-
pendiente de la parte servidora.

Vamos a entender que las aplicaciones de esta clase se conforman al menos de tres partes:

El Servidor El Enlace El Cliente

Fig. 1.3. Elementos básicos de un Sistema Cliente Servidor

Donde en general puede haber muchos clientes operando, en este caso el servidor requiere emprender
acciones de conciliación, secuenciación y bloqueo, entre otras, para que los clientes sean atendidos de ma-
nera oportuna y expedita.

Cuando en el sistema opera un solo servidor y un solo cliente se dice que tenemos una Aplicación Cliente
Servidor Simple. Este modelo se puede desarrollar incluso en una misma estación de trabajo. En particular
es el caso de una Manejador de Base de Datos (DBMS) que se ejecuta en una máquina y en la misma má-
quina se ejecuta un programa que interactúa con el DBMS realizando una o varias tareas. En este modelo
que llamaremos “local”, la aplicación saca provecho de la capacidad de realizar transacciones del DBMS y
se centra en la lógica requerida para resolver los problemas particulares del problema específico. En general
en éste enfoque la aplicación brinda una interfase simple y amigable al usuario para realizar sus tareas, y del
lado del desarrollador, éste se orienta a desarrollar la(s) interfase(s) de la aplicación de manera manual o
mediante una herramienta de desarrollo, de tal manera que las necesidades del usuario final queden atendi-
das. Probablemente este esquema sea el más difundido en el mercado de las pequeñas aplicaciones de BD,
considerándose como la meta del desarrollador y el producto esperado por el cliente. En éste ejemplo po-
demos identificar como “servidor” al DBMS y como “cliente” a la aplicación del usuario.

Más en general el asunto no es tan simple como se planteó en el párrafo anterior. En general las necesida-
des en el proceso de negocios y servicios son más complejos y requieren de una arquitectura ampliada,
tanto a nivel de software como de hardware.

Éste modelo extendido en el ámbito de las Computación y la Informática se denomina Modelo de Bases
de Datos Distribuidas. En la siguiente sección se presenta un panorama general del tema.

8
 B D / C S : : 2 0 0 4 : : M M

1.3. Elementos de Bases de Datos Distribuidas

En el procesamiento distribuido una máquina, conectada en una red local (LAN) o amplia (WAN) a otras
máquinas, puede realizar una tarea de procesamiento de datos en ella y sobre el resto de las máquinas de la
red, de tal manera que los procesos y los datos se ejecuten de manera paralela, coherente y mediante ciertas
reglas en uno o varios nodos de la red.

Si los nodos se encuentran localizados en un sistema físico de cómputo compacto, tendremos un esquema
“estrictamente paralelo” y si los nodos están dispersos geográficamente entonces nos encaramos a un sis-
tema distribuido. La comunicación entre los nodos se garantiza mediante un SO de red o bien con un
componente de software de comunicaciones.

Una organización diferencial posible para los sistemas distribuidos se compone por cuatro categorías, a
saber:

1. Sistema Dorsal o Arquitectura Centralizada. Hay un solo servidor y varios clientes, en el servi-
dor se encuentra instalado el DBMS y residen las BD para diversas aplicaciones. Los clientes me-
diante su poder local de cómputo, presentan las interfases a los usuarios y preparan las transaccio-
nes solicitadas, las cuales son enviadas al servidor para su procesamiento. Este modelo tiene la
ventaja de repartir el trabajo en partes (en paralelo), lo cual mejora el tiempo de respuesta y reduce
la latencia en las comunicaciones.

a. El servidor puede ser una máquina especializada de alto rendimiento para el manejo de
BD, por ejemplo contener un arreglo de discos duros de alta velocidad y rendimiento
(SCSI) y un sistema operativo estable multitarea, multiusuario y con seguridad.

b. El cliente puede ser una estación de trabajo personal (PC) con software y hardware adap-
tado a las necesidades del usuario final, con alta disponibilidad, respuesta rápida y autono-
mía local para procesos internos.

De esta manera varias máquinas cliente podrán acceder a la misma máquina que juega el rol de
servidor. Por lo cual una base de datos puede ser compartida entre distintos clientes.

Este modelo se acopla en términos formales al mecanismo que utilizan las empresas e institucio-
nes. Por ejemplo es común que una empresa operen muchas computadoras, donde algunas juegan
el papel de servidores y el resto (la mayoría) de clientes. Más no se descarta que alguna de ellas jue-
gue el doble rol, es decir ser servidor para algunas y cliente para otras. Podemos decir que al menos
en los servidores se puede afirmar que cada uno de ellos soporta un sistema de bases de datos completo,
en el sentido de las BD distribuidas.

2. Arquitectura Distribuida. El sistema se conforma por varios servidores y varios clientes. Cada
servidor contiene su DBMS y una o varias BD’s. Los clientes dependiendo de las necesidades del
usuario se conectan a uno o varios servidores para satisfacer sus demandas. EL acceso puede ser
proporcionado de dos maneras:

9
 B D / C S : : 2 0 0 4 : : M M

a. Un cliente puede acceder a cualquier servidor, pero solo a uno a la vez. De tal forma que
el cliente conoce donde debe solicitar la información. En este esquema no es posible
combinar datos de dos o más servidores en una misma petición.

b. El cliente puede acceder a varios servidores a la vez, de tal forma que una petición de base
de datos puede combinar información de varios servidores. Este modelo tiene la ventaja
de que el usuario no tiene que saber en qué servidor se encuentran ubicados los datos.

El soporte de una base de datos distribuida implica que las aplicaciones deben operar de manera
transparente sobre los datos que están dispersos sobre la red, donde es posible que los manejado-
res de BD locales (en cada servidor) utilicen una representación diferente para los datos, es decir
los DBMS no tienen que ser iguales, así como los Sistemas Operativos (SO) en cada servidor. Al
referirnos a “transparencia” debemos entender que la aplicación opera como si los datos fueran
manejados por un solo DMBS y en una sola máquina donde reside un servidor virtual. Una carac-
terística extra de este modelo es que un servidor puede atender a muchos clientes o bien servidores
a la vez.

Para que un sistema distribuido trabaje adecuadamente además es necesario contar con un sistema
de comunicaciones (red) robusto, estable y oportuno. Lo cual incluye un ingrediente más a la ar-
quitectura de los sistemas distribuidos.

En la siguiente figura se muestra la topología de los sistemas antes mencionados.

Fig. 1.4. Esquema de Arquitecturas Centralizada (izquierda) y Distribuida (derecha).

El principio fundamental de una Base de Datos Distribuida (BDD) es que: Ante un usuario, un sistema distri-
buido se comporta exactamente igual que uno no distribuido. Entonces los problemas de los sistemas distribuidos
son problemas internos o en el nivel de implementación, y no externos o en el nivel del usuario [2: cap.
20].

Los sistemas de BDD operan sobre 12 reglas u objetivos interrelacionados, a continuación se presenta un
resumen de estos, para mayor detalle ver [2: cap. 20, secc. 3].

1. Autonomía local. Los sitios deben ser autónomos, es decir las operaciones en un sitio X están
controladas por él; de tal suerte que la operación satisfactoria de X no depende de otro sitio Y. Es-

10
 B D / C S : : 2 0 0 4 : : M M

to implica que los datos locales son propiedad del sitio y son administrados por él. Debido a esto
la seguridad, integridad y representación de almacenamiento de los datos locales permanecen bajo
el control y jurisdicción del sitio local.

2. Independencia de un sitio central. No debe haber un sitio “maestro” central para algún servicio
central de tal manera que todo el sistema dependa de ese sitio central. La existencia de sitios maes-
tros conlleva al problema de vulnerabilidad de todo el sistema por una falla de éste.

3. Operación continua. El sistema no debe interrumpir de manera aleatoria sus servicios. Esto se
refleja en la confiabilidad y disponibilidad: la primera implica que la respuesta del sistema debe ser sos-
tenida a pesar que uno o varios sitios fallen; y la segunda debe garantizar que casi todo el tiempo el
sistema responda a las solicitudes. Estos objetivos se alcanzan mediante la replicación y la redun-
dancia, juntos forma el esquema de tolerancia a fallas.

4. Independencia de la Ubicación. Esta también se conoce como transparencia de ubicación y consis-

te en el hecho de que los usuarios no tienen que saber dónde se encuentran almacenados física-
mente los datos, sino que deben ser capaces de comportarse, al menos desde el punto de vista ló-
gico, como si estuvieran almacenados de forma local.

5. Independencia de fragmentación. También llamada transparencia de fragmentación. Los datos, a

nivel de registros o tablas, pueden estar fragmentados, es decir distribuidos en diferentes sitios para
efectos de almacenamiento físico. Normalmente la fragmentación se provoca para localizar los da-
tos en los sitios donde son utilizados con mayor frecuencia, esto reduce el uso de la red para reali-
zar las transacciones y aumenta la velocidad de respuesta del sistema de BDD. Existen dos tipos
de fragmentación: horizontal y vertical. La primera se refiera a partir las tablas en partes con registros
íntegros; y la segunda corresponde a separar los campos de los registros en dos o mas sub-tablas,
donde cada una de éstas contiene las llaves para la localización del registro. Un principio básico
que se debe cumplir es que todos los fragmentos deben ser independientes, es decir que ninguno
de ellos podrá ser derivado a partir de los otros ni existen restricciones o proyecciones que puedan
ser derivadas a partir de otros.

6. Independencia de replicación. Esto significa que una tabla o un fragmento distribuido de ella
que se encuentra almacenado en algún sitio puede ser representado por otras copias (réplicas) al-
macenadas en diferentes sitios. Esta propiedad se denomina redundancia controlada. La principal des-
ventaja de la replicación radica en que al hacer un cambio en algún registro, éste se debe propagar
a los demás sitios que contengan copias sin violar la integridad del sistema completo de la BDD.
En general será responsabilidad del encargado del sistema de definir cuáles réplicas deben ser ac-
cedidas físicamente para satisfacer una solicitud de usuario dada.

7. Procesamiento distribuido de consultas. Este criterio implica que el sistema debe optimizar las
transacciones de tal manera que se reduzca el tráfico en la red y se acceda a la réplica más cercana o
bien al sitio de menor tiempo de respuesta. Esto implica que el modelo a utilizarse para realizar las
transacciones debe ser al menos relacional.

8. Administración de transacciones distribuidas. Dada la característica distribuida del sistema, se

deben tomar las previsiones necesarias para garantizar el control de la recuperación de los datos y
el control de concurrencia. El mecanismo natural que se utiliza es de agentes, es decir dado que se

11
 B D / C S : : 2 0 0 4 : : M M

pueden realizar varias transacciones de forma concurrente en diferentes sitios, los agentes se en-
cargarán de realizar las transacciones en cada sitio representando la transacción original del usuario.

9. Independencia del hardware. Esta regla define que debe ser posible ejecutar el mismo DBMS
en diferentes plataformas de hardware, de tal manera que cada máquina participe como un socio
igualitario ene l sistema distribuido.

10. Independencia del Sistema Operativo. Este criterio implica que cada sitio puede funcionar con
un sistema operativo diferente (tanto de versión como de tecnología). Y a pesar de esto el DBMS
debe operar en cada sitio de la misma manera.

11. Independencia de la red. Esto implica que algunos nodos pueden trabajar sobre redes de co-
municación diferentes, pero el sistema en general puede comunicar a un nodo con otro en todo
momento. Esto se logra mediante dispositivos de traducción e interfase, los cuales hacen compati-
bles los mensajes de entrada y salida.

12. Independencia del DBMS. En todos los sitios de tipo servidor no necesariamente opera el
mismo DBMS, sino que se requiere que cada DBMS local soporte la misma interfase para las tran-
sacciones. Este principio completa el esquema heterogéneo de un sistema de BDD.

En general el problema principal que debe resolverse para la operación correcta de un sistema de BDD es
la reducción del uso de la red, es decir se debe minimizar la cantidad y volumen de los mensajes entre sitios. Los
aspectos donde impacta más este aspecto son los siguientes:

• Procesamiento de consultas • Control de recuperación

• Administración de catálogos. • Control de concurrencia
• Propagación de las actualizaciones • Procesos de mantenimiento
En particular cada DBMS para ambientes distribuidos ofrece diferentes mecanismos para atender éstas
problemáticas.

1.4. Sistemas Cliente – Servidor.

Como es natural ahora podemos afirmar que los sistemas cliente – servidor (CS) son un caso particular de
un sistema distribuido. De tal manera que en el sistema distribuido:

a. Algunos sitios juegan el papel de servidores y otros de clientes.

b. Todos los datos residen en los sitios servidores
c. Las aplicaciones de usuario son ejecutadas en los sitios clientes
d. No existe una independencia total de ubicación.

12
 B D / C S : : 2 0 0 4 : : M M

Donde en los servidores (S) se encuentran los datos y su correspondiente DBMS y en los clientes (C) las
aplicaciones o interfases. Podemos definir un Sistema CS mediante las siguientes reglas [3]:

a. Un sistema CS es una relación entre procesos corriendo en máquinas separadas:

El servidor es un proveedor de servicios.
El cliente es un consumidor de servicios.

b. El Cliente y el Servidor interactúan mediante un mecanismo de paso de mensajes:

Petición de servicio.
Respuesta a la petición.

Retomando las doce características de los sistemas distribuidos, mínimamente un sistema CS debe tener las
siguientes propiedades:

• Control de los recursos. Esto implica que un S puede atender a muchos C y mantener el control
local de sus recursos.

• Transparencia. Debe haber transparencia de ubicación, hardware y plataforma (SO).

• Encapsulamiento. Una petición hecha por un C o S indicará claramente qué servicio se desea y
entonces un S se encargará de cómo resolverla. En general deberá ser posible modificar a los S
sin afectar a los C.

• Escalabilidad. Se pueden realizar acciones de escalamiento (upgrade) sin afectar a otros

componentes, se manejan dos tipos:
Horizontal : se agregan otros C y S.
Vertical : se cambia un S por otro más potente
o se distribuye su trabajo entre varios.
• Integridad. Las funciones y datos del S son manejadas en forma centralizada. Eso beneficia
el mantenimiento e integridad de los datos.

A pesar de que el modelo de sistema distribuido es más poderoso que el cliente – servidor, a nivel comer-
cial se utiliza mas el segundo, pero a mediano plazo éstos serán reemplazados por los primeros.

Dependiendo de la complejidad y tipo de aplicación a desarrollarse los sistemas CS se organizan en tres

clases, a saber:

1. Modelo de dos capas. Un cliente se localiza en un sitio físico bien definido y lo mismo sucede
con el servidor. Donde la lógica de aplicación puede organizarse en tres formas:

Interfase Interfase Interfase CLIENTE

Lógica de la Aplicación Lógica de la Aplicación.

Lógica de la Aplicación. Lógica de la Aplicación.

SERVIDOR
DBMS DBMS DBMS

13
 B D / C S : : 2 0 0 4 : : M M

En el primero modelo, el cliente juega el papel de manejar la interfase de la aplicación simplemente

y la lógica de la aplicación y el DMBS residen en el servidor. En el segundo caso la lógica de la
aplicación se comparte entre el cliente y el servidor; y en el último caso la lógica de la aplicación se
localiza en el lado del cliente.

Esta división del trabajo imprime las siguientes características dependiendo donde se ubica la lógi-
ca de la aplicación:.

En el lado del Cliente

La semántica está dividida entre los programas

Cada programa solo maneja un parte del problema

Los controles están embebidos en el código de los programas

Existen fuertes problemas de mantenimiento, duplicidad de es-

fuerzos y de integridad

En el lado del Servidor

La lógica está centralizada y en general es consistente

Aumenta la seguridad e integridad

Algunos controles se pueden expresar de manera simple en SQL y

otros pueden ser rutinas complejas (procedimientos almacenados)

Aumenta el trabajo en el servidor y su complejidad

2. Modelo de tres capas. En este modelo se separa la lógica de la aplicación de la interfase ubicada
en el lado del cliente y del DBMS situado en el lado del servidor. El esquema se muestra en el dia-
grama adjunto. Este modelo se aplica en los siguientes ca-
Cliente: Interfase
sos:

a. Cuando se ofrecen muchos servicios en el lado del

server.
b. Si las aplicaciones que se ejecutan en el server se
Lógica de la Aplicación operan con diferentes lenguajes (tipo intérprete).
c. Se manejan sistemas de BD heterogéneos.
d. Hay muchas transacciones por unidad de tiempo.
e. Hay muchos usuarios conectados simultáneamente.
Servidor: DBMS f. Existe mucha comunicación entre las aplicaciones.

14
 B D / C S : : 2 0 0 4 : : M M

3. Modelo de N capas. Este esquema se utiliza principalmente cuando la operación se realiza me-
diante la colaboración de varios servidores de software en el lado del server o bien los clientes ac-
ceden a varios servicios según sea su necesidad.

En el siguiente diagrama se muestra un ejemplo de esta arquitectura:

Cliente Cliente Cliente Interfases

Red

Servidor de Servidor de Servidor de

WEB FTP Aplicaciones

Lado de server
Servidor de
Aplicaciones

Servidor BD
DBMS

Fig. 1.5. Esquema del Modelo de N capas.

Este modelo se utiliza cuando se tiene una arquitectura compleja compuesta por varios servicios seria-
lizados que de manera conjunta resulten algunos problemas específicos. Tenemos como ejemplos de
esta arquitectura:

• Sistemas de acceso a BD mediante interfases WEB.

• Sistemas que utilizan Proxies y Firewalls.
• Sistemas de manejo remoto de archivos con derecho a ejecución.

15
 B D / C S : : 2 0 0 4 : : M M

Capítulo 2. Acceso a Base de Datos sobre la Web

En éste capítulo se presentarán los conceptos y elementos que permiten crear aplicaciones que acceden a
Bases de Datos usando un cliente de Web como interfase.

2.1. Arquitectura de una Aplicación Web con acceso a BD.

Utilizando los conceptos de las arquitecturas cliente servidor podemos decir que una aplicación de base de
datos que utiliza a un navegador de Web (browser) como interfase para acceder a una BD, la cual puede
realizar diferentes tareas en general, corresponde a un modelo de 3 capas. El esquema operativo de dicho
modelo se presenta a continuación (Fig. 2.1).

Cliente Cliente Cliente Cliente

Navegador Navegador Navegador Navegador

de Web de Web de Web de Web

Servidor de Web
(HTTP)

DBMS 1 DBMS 2

BD X BD Y

Fig. 2.1. Arquitectura de acceso a BD mediante clientes Web

16
 B D / C S : : 2 0 0 4 : : M M

En el modelo se puede observar como diferentes clientes (parte superior) acceden mediante un navegador
a la red y realizan un operación sobre una BD que se encuentra en algún server (parte inferior). Quién re-
cibe la petición es el servidor de Web, luego éste la dirige a un DBMS específico - en general pueden estar
operando varios de manera simultánea – y mediante un programa escrito en cierto lenguaje se realiza la
operación pedida, el DBMS la procesa y manda la respuesta al programa intermediario, éste debe producir
una página de Web válida, la cual es enviada por el servidor de Web al cliente que realizó la solicitud.

Debe ser claro que el servidor de Web, al menos del lado del server, debe ser multitarea para poder atender
a varios clientes a la vez por un lado, por otro lado el servidor de Web debe contener mecanismos que
permitan interpretar la solicitud como algo más que una simple página de Web, es decir el servidor de Web
debe ser capaz de ejecutar programas en uno o varios lenguajes, los cuales mediante bibliotecas especiales y
dedicadas se han de comunicar con el DBMS para que éste realice la tarea de BD solicitada y finalmente el
proceso, una vez hecha la tarea, se revierte para producir la respuesta y enviarla al cliente solicitante a través
de la red.

A continuación se presenta un detalle de estos mecanismos.

2.2. El Protocolo de comunicación HTTP.

Hablar de Web es ahora algo cotidiano, más debemos hacer una serie se precisiones para entender mejor el
proceso. Cuando se empezó a generalizar el uso de las redes en la década de 1980 el esquema TCP/IP
dominó en mercado público y privado como estándar de comunicaciones, los primeros protocolos que se
introdujeron correspondieron a los de las capas bajas, en particular se normalizaron los protocolos que
permitían la comunicación entre aplicaciones, los más notables son el ip, UDP, TCP, ARP y el RARP.
Luego se crearon los primarios para la transferencia de archivos (FTP), la creación de terminales remotas
(TELNET) y los correspondientes a la administración de las comunicaciones y el enrutamiento de los
datos sobre Internet. Estos permiten conexiones simples y se basan en la tecnología de sockets. A finales
de la década se presentó la necesidad de contar con un mecanismo que permitiera acceder con facilidad a
información en forma de texto formateado almacenada en servidores, de tal manera que al darse el nom-
bre del archivo y el sitio donde éste se encuentra se realizará la transferencia del servidor al cliente. En 1989
Tim Berners Lee presentó un proyecto al CERN (Centre Européen de Recherche Nucléaire) para la recu-
peración de información basado en hipertexto, concepto propuesto por Ted Nelson que permite incrustar
objetos como imágenes, sonidos, videos y referencias o ligas dentro de ésta clase de documentos. El
proyecto fue apoyado y nacieron los primeros navegadores y servidores de hipertexto.

La propuesta de Tim Berners consistía en un lenguaje sencillo, amigable, que permitiera insertar dentro de
un documento de texto instrucciones, que al ser interpretadas por un programa intérprete (el navegar o
browser) permitiera variar los estilos de presentación del documento y relacionarlo con otros tipos de in-
formación, localizada en general en cualquier computadora conectada a Internet.

En 1993 el tráfico de información con éste modelo apenas era del 1% del total y había escasos 500 servi-
dores que brindaban información de éste tipo. Ese año se puso al público por parte del NCSA (National
Center for Supercomputing Applications) un programa llamado Mosaic de manera gratuita y vino la expan-
sión del fenómeno Internet.

17
 B D / C S : : 2 0 0 4 : : M M

Como núcleo de éste paradigma hay tres conceptos clave: URL, HTTP y HTML. Comentemos cada uno
de ellos para aclarar la situación.

2.2.1. URL

La manera en que se buscaba información en Internet en sus inicios era bastante compleja, ya que las inter-
faces eran de texto simple y uno debía conocer muy bien el terreno para realizar las tareas de consulta y
recuperación de información. Para simplificar el proceso se introdujo un esquema llamado URL (Uniform
Resource Locator) o localizador uniforme de recursos, éste permite localizar de manera unívoca un documento
dentro de la red. Su estructura es técnicamente simple:

protocolo://servidor[:puerto]/ruta/recurso

donde,

protocolo : indica que protocolo (conjunto de reglas para que una aplicación se coordine con otra pa-
ra realizar alguna tarea) se utilizará para la comunicación.
servidor : se refiere a la dirección ip o por nombre del equipo al cual uno se desea conectar.
puerto : indica un puesto alternativo al estándar para realizar la conexión. Normalmente se defi-
nen puertos por defecto para hacer la conexión, pero es posible configurar los servicios
en otros puertos para crear ambientes con privacidad, seguridad o bien habilitar varias
instancias de servidores de la misma clase que atienden servicios especializados y dedica-
dos.
ruta: indica la ruta en el árbol de directorios del nodo base del servidor. En general se define
un sitio por defecto que funge como nodo raíz de la aplicación y a partir de éste se puede
construir una estructura de archivos que facilite la administración de la información y res-
tringa en caso necesario el acceso a la misma por parte de los usuarios. Esto permite in-
troducir mecanismos de privacidad y seguridad.
recurso: hace referencia al archivo que se desea acceder. Y dependiendo del protocolo utilizado se
realizará la tarea correspondiente con él.
Los protocolos primitivos en Internet que operan bajo éste esquema son los siguientes:

Protocolo Descripción
ftp File Transfer Protocol: Tiene como propósito la transferencia de archivos.
malito Se utiliza para envío de correo electrónico.
news Sirve para la lectura de noticias (news) sobre USENET.
telnet Habilita establecer sesiones de trabajo remotas.
http Hiper Text Transfer Protocol: Permite la transferencia de hipertexto.

18
 B D / C S : : 2 0 0 4 : : M M

Por ejemplo para solicitar el archivo “plan.html” ubicado en la carpeta “/users/paco” del servidor
www.ps.uar.mx en el puerto “8010” usando el protocolo “http”, el URL correspondiente tendrá la forma:

http://www.ps.uar.mx:8010/users/paco/plan.html.

2.2.2. Protocolo HTTP

Este es un protocolo de aplicación de la suite TCP/IP, probablemente el más utilizado en la navegación

sobre Internet, éste envía los datos como texto ASCII, por debajo del protocolo HTTP debe haber una
conexión TCP segura entre el cliente y el servidor cada vez que se realice un intercambio de datos. Por
defecto el puerto de enlace es el 80 como punto de conexión.

El protocolo HTTP consiste de dos elementos: el grupo de solicitudes de los visualizadores a los servido-
res y el grupo de respuestas en sentido inverso [4: cap. 7, pag. 690-691].

Grupo de solicitudes. Todas las versiones de HTTP reconocen dos tipos de solicitud: sencillas y comple-
tas. Una solicitud sencilla es una sola línea GET que nombra la página deseada, sin la versión del protocolo.
La respuesta es una página en bruto, sin cabecera, sin MIME y sin codificación. Una solicitud completa se
indica por la presencia de la versión del protocolo en la línea de solicitud del GET. Las solicitudes puedes
consistir en múltiples líneas, seguidas de una línea en blanco que indica el final de la solicitud. La primera
línea de una solicitud completa contiene el comando (por ejemplo GET), la página deseada y el protocolo
con su versión.

Grupo de respuestas. Una respuesta simple puede ser una línea simple que indica el resultado de la petición
o un error de acceso. Y una respuesta completa es un conjunto de líneas que contienen una página Web y sus
encabezados para ser correctamente interpretada.

Acerca de las MIME. Cuando se crearon las primeras aplicaciones de correo electrónico, los mensajes es
simples archivos de texto en inglés en ASCII restringido (7 bits). Este modelo limitaba las posibilidades
para mandar mensajes en otros idiomas, por ejemplo aquellos que requieren de acentos (español, francés y
alemán), idiomas que no están basados en caracteres latinos (ruso, hebreo y árabe), idiomas carentes de
alfabeto (chino y japonés) y mensajes que no contienen texto (imagen, audio o video). Se propusieron va-
rias soluciones que se están sintetizadas en los RFC (Request For Coment) 1341 y 1521. Esta solución
llamada MIME (Multipurpose Internet Mail Extensions – extensiones multipropósito de correo In-
ternet) propone mantener la compatibilidad de los mensajes de correo especificados en el RFC 822, pero
agrega una estructura al cuerpo de los mensajes y define reglas de codificación para los mensajes no ASCII.
Para interpretar de forma adecuada los mensajes se debe especificar de que MIME se trata y utilizar pro-
gramas transmisores y receptores adecuados a cada MIME.

El MIME define 5 nuevas cabeceras para los mensajes, éstas son: Mime-Version: la cual identifica la versión
del MIME; Content-Description: que es una cadena de texto que describe el contenido; Content-Id: que es un
identificador único; Content-Transfer-Encoding: Indica como se ha codificado el mensaje (envoltura) para su
transmisión; y Content-Type: se refiere a la naturaleza del mensaje.

En general cualquier mensaje que no contenga una cabecera MIME-Version se debe interpretar como un
mensaje de texto normal en inglés [4: cap.7 pag. 650 - 657].

19
 B D / C S : : 2 0 0 4 : : M M

El protocolo HTTP fue diseñado para usarse en la Web, pero en su modelo se encuentra la filosofía de la
Orientación a Objetos. Un elemento que refleja éste hecho consiste en que la primera palabra de la línea de
solicitud completa corresponde al nombre del método a ser ejecutado con la página de Web considerada
como un objeto. Los métodos predefinidos son los siguientes:

Método Descripción
GET Solicita al servidor que envíe un objeto, pe. una página de Web, codificado según el
MIME especificado. Si a la solicitud GET le sigue la cabecera If-Modified-Since, el servi-
dor enviará los datos si fueron modificados después de la fecha indicada.
HEAD Pide la cabecera del mensaje sin incluir la página u objeto. Este método se utiliza para
obtener la hora de la última modificación del objeto para recolectar información con
fines de indexación o para validar un URL.
PUT Es la inversa de GET, es decir, en vez de leer un objeto lo escribe. Éste método permi-
te construir un conjunto de páginas de Web en un servidor remoto. El cuerpo de la
solicitud contiene la página y puede codificarse usando un MIME, en ese caso las lí-
neas que siguen al método PUT pueden incluir cabeceras de la clase Content-Type y la
validación de la identificación, esto tiene como propósito verificar que el solicitante
tiene los permisos para ejecutar la operación solicitada.
POST Adiciona un recurso dado. En general lleva un URL, donde en vez de sustituir los da-
tos existentes los anexa (apendiza) en un sentido generalizado. Una aplicación común
son los grupos de noticias y boletines electrónicos.
DELETE Elimina una página u objeto de Web. Permite la validación del usuario y revisión de
los permisos. En general no hay garantía de que el método logre su propósito ya que a
pesar que el servidor remoto esté dispuesto a borrar el objeto, el archivo puede tener
un modo que prohíba al servidor de HTTP su modificación o eliminación.
LINK Conecta dos recursos existentes como páginas u otra instancia válida.
UNLINK Rompe una conexión existente entre dos recursos.

Tabla 2.1. Métodos habilitados en el protocolo HTTP.

Los elementos que pueden estar presentes en la cabecera de una petición HTTP realizada por una aplica-
ción cliente tiene la siguiente estructura:

Método URI versión

[cabecera]
[datos]

El método es alguno de la Tabla 2.1.; La cabecera y los datos son opcionales y ene general están compues-
tos por varios elementos. Entre la cabecera y los datos debe haber un espacio en blanco (línea), este sirve
como separador. En la Tabla Siguiente se presenta una descripción de las componentes más usuales para
una cabecera.

20
 B D / C S : : 2 0 0 4 : : M M

Campo Descripción
URI Identificador Universal del Recurso (Universal Resource Identifier). Especifica la ruta y
el nombre del objeto que desea recuperar.
Versión Indica la versión del protocolo HTTP utilizado, las más frecuentes son: 1.0 y 1.1.

Cabecera Son pares [Campo:Valor] que brindan información sobre la petición.

Datos Cadena de caracteres que siguen un MIME.

Tabla 2.2. Elementos de una petición HTTP.

Algunas de las parejas utilizadas en la cabecera son las siguientes:

Campo Descripción
Accept Tipo de documentos que el cliente puede aceptar. El servidor lo debe tner en cuen-
ta al momento de generar la respuesta.
Accept-Charset Indica el juego de caracteres que el cliente utiliza para manejar la información.

Accept-Language Indica el lenguaje (idioma) preferente en el cual el cliente desea recibir el documento
solicitado.
Accept-Encoding El cliente indica si acepta recibir documentos codificados en algún(os) formato(s).

User-Agent Indica el nombre y versión del Navegador (Browser) que usa el cliente.

From Indica el nombre del usuario que utiliza el programa cliente.

Referer El cliente indica la dirección a partir de la cual conoce de la existencia del documen-
to solicitado.
If-Modified-Since Indica que se envíe el documento si ha sufrido cambios desde cierta fecha.

Tabla 2.3. Campos de una cabecera HTTP.

A continuación se presenta un cuadro con una petición GET típica:

GET info.html HTTP/1.0

Connection: Keep-Alive
User-Agent: Mozilla/4.04[en][Win95:I]
Host: 10.228.150.22
Accept: image:gif,image/x-xbitmap,image/jpeg
Accept-Language: ES
Accept-Encoding: x-gzip
Accept-Charset: iso-8859,utf-8
From: Juan Sanchez jsanchez@hotmail.com
If-Modified-Since: Mon, 19 Apr 2004 18:05:33 GMT

21
 B D / C S : : 2 0 0 4 : : M M

Como puede verse la información que viene en la petición permite identificar al usuario, el sitio donde esta
conectado y otros parámetros que serán importantes cuando se produzca la respuesta.

Por otro lado debemos citar las posibles respuestas del servidor al cliente, la primera corresponde a una
página o recurso existente, en este caso el objeto es enviado al cliente precedida por el protocolo, su ver-
sión y el código “200 OK” que indica éxito, en general podría haber mas elementos en la cabecera de res-
puesta. La sintaxis de una respuesta tiene la forma:

Protocolo/Versión Estado Descripción

[cabecera general | cabecera de respuesta | cabecera entidad]
[cuerpo de la entidad]

La tabla siguiente presenta un resumen de “Estados” de una respuesta:

Código Descripción
200 Acción realizada con éxito.
201 Se devuelve después de enviar un POST cuando el documento se ha creado con
éxito.
202 Se ha recibido la consulta, pero se ejecutará mas tarde.
204 Acción realizada con éxito, pero no se devuelve algún objeto.
301 El objeto solicitado está en otro lugar en el servidor, se regresa la nueva dirección
del objeto
302 El objeto solicitado se encuentra temporalmente en la dirección indicada en la res-
puesta.
304 Respuesta a una solicitud GET cuando no se regresa algún objeto debido a que no
existe una nueva versión de él.
400 Error de sintaxis en la petición del cliente.
401 Se necesita una identificación por parte del cliente, ya que está ausente.
403 Acceso denegado para el objeto solicitado.
404 El recurso solicitado no está en el servidor.
500 Error interno del servidor.
501 El servidor no acepta la acción especificada.
502 Este código lo regresa un Proxy o Gateway cuando el servidor al que se ha dirigido
la solicitud no responde.
503 El servidor no puede responder por estar sobrecargado de trabajo.
Tabla 2.4. Códigos de Estado enviados por el servidor
La cabecera general puede ser de dos tipos:

Date: Indica la fecha en la que se creó la consulta enviada por el cliente, pe.
Date: Sun, 18 Apr 2004 20:55:03 GMT
Pragma: Inicia el intercambio de información de datos entre el cliente y el servidor no estandariza-
dos y específicos del programa, pe. Esta directiva solicita el archivo original y no el que se
encuentre en el caché del servidor.
Pragma: no-cache

22
 B D / C S : : 2 0 0 4 : : M M

Las cabeceras de respuesta permiten enviar información complementaria que la que aparece en la línea
de estado. Hay cuatro tipos:
Location. En este campo el servidor indica la nueva dirección del recurso solicitado por el cliente.
Server: Indica el nombre y versión del programa que opera como servidor de HTTP.
Content-Language. El servidor muestra al cliente el idioma en el que está escrito el documento solici-
tado.
WWW-Authenticate. Este campo aparece junto al código de respuesta 401, cuando el servidor solici-
ta al cliente que se autentique.

La cabecera de entidad muestra información adicional sobre el cuerpo de la entidad o sobre el recurso,
existen siete tipos:
Allow. Indica el conjunto de métodos de petición admitidos por el servidor.
Content-Encoding. Indica la codificación utilizada en el objeto referenciado.
Content-Length. Indica el tamaño en bytes del documento anexo en el cuerpo de la solicitud.
Content-Type. Tipo de documento enviado según un MIME.
Expires. Indica la fecha y hora a partir de la cual el objeto entregado deja de tener validez.
Last-Modified. Indica la fecha de la última vez en que se modificó el recurso solicitado.

Y finalmente el cuerpo de la entidad que es opcional (cuando no hay respuesta por ejemplo está ausente)
contiene los datos solicitados por la aplicación cliente. Para mayor información se pueden consultar los
RFC 1945 para el protocolo HTTP/1.0 y el RFC 2068 para el HTTP/1.1.

2.2.3. Lenguaje HTML

Este es un lenguaje para la composición de documentos y especificación de ligas de hipertexto que define
una sintaxis adaptada al Web. Esta basado en el estándar ISO 8879 que corresponde al SGML (Standard
Generalized Markup Language : Lenguaje de Marcas Estándar Generalizado).

Los modelos de descripción de documentos se crearon como base de los procesadores de texto y tienen
como propósito indicar la manera en que los documentos serán presentados por parte del visualizador y
eventualmente por los subsistemas de impresión. Un lenguaje que ha sido ejemplo persistente es TEX
creado por Donald Knuth para crear documentos científicos y sus Macro Lenguajes asociados como es
LATEX.

El elemento central de éstos lenguajes es la marca, ésta indica la manera en que una palabra, párrafo o
grupo de líneas será tratado. Normalmente los documentos se escriben en ASCII con herramientas sim-
ples y son interpretados por un visualizador, en el caso del Web el visualizador es el Navegador de Web.

En el caso de HTML se incluyen marcas para incluir ligas (links) a otros documentos o recursos que no
son de tipo texto, de tal manera que no se habla de documentos sueltos, sino de grupos de documentos

23
 B D / C S : : 2 0 0 4 : : M M

organizados en un grafo navegable a través de las ligas. Esto produce un concepto de nivel superior, el cual
permite describir documentos estructurados como lo son: Libros, Manuales y Propaganda. Las ligas que
permite incluir HTML habilitan la navegación dentro y fuera de un servidor, es decir la información en
general está distribuida en un conjunto de servidores. Esto marca el modelo como un modelo por excelen-
cia distribuido desde el punto de vista de la computación.
El lenguaje HTML se ha estandarizado para que los desarrolladores de Navegadores ofrezcan a sus usua-
rios una interfase regular y compatible. La organización que define ésta norma es un consorcio formado
por instituciones privadas y públicas [5]. Este esfuerzo es parte de un grupo más amplio conocido como
“Grupo de Trabajo de Ingeniería de Internet” (IEFT) [6], el cual no solo norma al HTML sino define y
administra cada aspecto de la tecnología asociada a Internet., los documentos ofiales que éste grupo genera
se denominan RFC (Request For Comment), estos se numeran y se publican en el sitio oficial del Grupo.
Actualmente la versión liberada del Lenguaje HTML es la 4.0 y es utilizada por la mayoría de los Navega-
dores de Web. Existe una amplia gama de literatura relacionada con este lenguaje [7,8], en particular se
puede visitar un pequeño tutorial creado en la FCC [9].
Las extensiones para los archivos HTML son htm y html y se crean y modifican con un editor ASCII simple
o mediante herramientas visuales especializadas, pero debe recordarse que en todos los casos el archivo
debe ser salvado como ASCII simple.
Entrando en detalle podemos decir que un documento en HTML se compone de dos partes: la cabecera y el
cuerpo. La primera se engloba entre las etiquetas <head>cabecera<</head> y el cuerpo se identifica por
estar contenido entre las etiquetas <body>cuerpo</body>. De tal suerte que la cabecera y cuerpo se en-
marcan entre las etiquetas <html> y </html>. El lenguaje HTL no distingue entre mayúsculas y minúscu-
las al manejar sus etiquetas, pero algunos elementos si pueden ser dependientes del tipo, principalmente la
inclusión de archivos en el caso de operar sobre SO que hacen la distinción como es el caso de UNIX y
sus implementaciones (Linux, AIX, HPUX, IRIX, etc.).

GET home.html HTTP/1.0

200 OK
content-type: text/html
Cliente Servidor
Usa: Navegador Usa: Servidor HTTP
<html>
<body>
Estos son sus datos …
</body>
</html>

Fig. 2.2. Proceso simple de petición respuesta entre un cliente y un servidor de Web

Originalmente HTML se diseño junto con los servidores de Web y sus correspondientes Navegadotes
como un lenguaje para presentar páginas estáticas. Es decir se diseña el documento, se codifica en HTML
y se coloca en una ruta específica en el servidor, entonces algún navegador realiza su petición del docu-
mento y es enviado por el servidor al cliente, luego el navegador lo interpreta y muestra en la terminal del
cliente, normalmente recuperando los diferentes elementos que conforman al documento. En la figura 2.2
se muestra el flujo de datos y tareas de éste proceso.

24
 B D / C S : : 2 0 0 4 : : M M

A pesar que ese fue el diseño original surgió la necesidad de que el servidor no solo regresara páginas de
Web planas y estáticas, sino que tuviera la capacidad de regresar páginas producidas como resultado de la
ejecución de un programa en el lado del servidor con base a una petición que incluyera datos del lado del
cliente. Se realizaron las adecuaciones correspondientes en el servidor y se ofertó la facilidad. A ésta tecno-
logía se le denominó CGI (Common Gateway Interface), éste modelo lo que habilita es que dentro de una
página de Web se incorpore una petición de ejecución de un programa en el lado del servidor.
En resumen podemos decir que el CGI es la parte del servidor de Web/HTTP que se puede comunicar
con otros programas que están corriendo en el servidor. Mediante un CGI, el servidor de Web puede lla-
mar a un programa pasándole los datos especificados por el usuario (en el lado del cliente), donde el pro-
grama procesará los datos y el servidor enviará la respuesta del programa de regreso al Web browser en el
sitio donde fue hecha la solicitud (en el lado del cliente demandante) [10].
El mecanismo establecido dentro de HTML para pasar los datos a un programa mediante el modelo CGI
son los formularios o formas (FORMS), estos introducen una serie de marcas especiales que permiten el
ingreso de datos de manera natural en una página escrita en HTML. En el cuerpo de la forma se indica el
programa y su ruta en el lado del servidor que atenderá la petición. Los parámetros para la ejecución del
programa se pueden manejar como es clásico mediante el esquema que ofrecen las variables argvc y argv[ ]
al estilo C o C++, o bien mediante el mecanismo que el lenguaje de programación utilizado ofrezca. En la
siguiente figura (Fig. 2.3) se muestra esquemáticamente la forma de interacción.

Ejecuta
4
Navegador de Web/Cliente Aplicación
2 3

Envía la Forma Llama al CGI

completa (petición) CGI

Página Servidor
Servidor
(FORMA) de Web
HTML El programa CGI res- El Programa CGI res-
ponde al cliente a través ponde al servidor
1 7 del servidor
6 5
Usuario

Fig. 2.4. Esquema de comunicación de los programas CGI

Dado que la aplicación que se ejecuta en el lado del servidor puede ser cualquier programa, en particular se
puede llamar a un Sistema Manejador de Bases de Datos (DBMS), por lo cual el modelo de comunicación
entre el cliente y el servidor mediante el CGI permite que se trabaje con Bases de Datos remotas ubicadas
en uno o varios servidores (tanto físicos como lógicos) utilizando una red (sobre una Intranet o Internet).
A pesar de tratarse de un modelo simple, se requiere estudiar sus detalles de operación, paso de paráme-
tros, creación de las formas y los esquemas de seguridad correspondientes.

25
 B D / C S : : 2 0 0 4 : : M M

2.3. Estándares de interacción.

En general uno puede recurrir a cualquier mecanismo para realizar la comunicación entre el cliente y el
servidor, y luego entre el servidor y el DBMS. El nivel más bajo para la primera fase se puede hacer utili-
zando sockets sobre TCP/IP, pero no es en general una alternativa sencilla de implementar puesto que se
requiere conocer su funcionamiento detallado y además para cada problema se debe crear una pareja de
aplicaciones: una en el lado del cliente y otra en el lado del servidor. Este modelo prevaleció por muchos
años habilitando a los desarrolladores ofrecer soluciones, pero con el conocido crecimiento de Internet se
aprovechó su estandarización y se crearon modelos que requiriesen menos esfuerzo y fueran independien-
tes de los SO’s, las plataformas físicas – es decir se creo una corriente de simplificación – y las particulari-
dades de los problemas. Esto fue unificando los esfuerzos corporativos e institucionales y ha llevado a
varias propuestas operativas transparentes y sencillas de manejar, donde se ha incluido la interacción con
los DBMS. Ocasionando que las épocas en las cuales cada compañía ofertaba “la mejor solución” se redu-
jese y se normalizarán los mecanismos, permitiendo la interoperatividad entre plataformas físicas y lógicas,
lo cual es uno de los imperativos de los Sistemas Distribuidos.

Dentro del esquema se considera el hecho que en la mayor parte de los sistemas de cómputo que se utili-
zan ya incluyen Navegadores de Web, lo cual ofrece de manera directa una parte de la solución, es decir la
Interfase de Usuario, de donde sólo resta regular el resto de mecanismos. Con esto debemos entender que ya
no será necesario escribir programas dedicados en el lado del cliente, que deban ser distribuidos y actualizados,
sino que se aprovecha el Navegador y sus características para montar sobre él las interfases de usuario.
Esto reduce de manera natural los costos, los problemas de distribución y de mantenimiento del software.

Con la adopción de la idea de forma masiva, diversas compañías y grupos de trabajo han creado aplicacio-
nes con sus mecanismos de instalación, operación y distribución correspondientes. Podemos decir que el
modelo es el mismo, pero existen alternativas para implantar éste tipo de soluciones. Cada caso tiene sus
bemoles y no se debe hacer a un lado, más bien se debe contemplar como lo que es: una opción. A conti-
nuación se hace un resumen de diferentes modelos, el cual no agota la variedad de soluciones que hay.

2.4. Categorización de la interfaces Web/DBMS

Las aplicaciones de usuario para la interacción de bases de datos con el Web son simplemente modelos del
ambiente cliente/servidor, con una capa adicional para crear resultados HTML que puedan ser visualiza-
dos a través del Navegador de Web, por medio del procesamiento de los datos obtenidos en la forma que
han sido introducidos por el usuario/cliente. Además, al usar estas interfaces se puede crear el programa
principal de la aplicación. Como puede observarse, estas herramientas permiten construir poderosas apli-
caciones en el Web, pero se requiere que programadores experimentados logren un desarrollo a gran esca-
la. También, el mantenimiento de las mismas es significativamente más complejo y extenso.
Una de las estrategias básicas para la creación de aplicaciones de interacción con el Web, es la de descargar
del Web aplicaciones o componentes funcionales que se ejecutarán dentro del Navegador (plugins). Con
ellas se realiza un procesamiento complejo del lado del cliente, lo cual requiere un gran esfuerzo para crear
las componentes de la aplicación. Estas estrategias poseen dos características principales: garantizan la se-
guridad tanto en los sistemas de distribución como en la comunicación que se establece con tales aplica-
ciones, a través de Internet.

26
 B D / C S : : 2 0 0 4 : : M M

También han aparecido bibliotecas que incluyen motores propios en el lado del servidor que corren de
forma conjunta con el Servidor de Web, lo cual facilita el desarrollo de nuevas aplicaciones.
Una aplicación que posibilita interconectar al Web con una base de datos tiene muchas ventajas, además de
que las funciones que cumplen actualmente los Servidores Web y las herramientas de desarrollo de aplica-
ciones Web, hacen más fácil que nunca la construcción de aplicaciones más robustas. Tal vez el mayor
beneficio del desarrollo de estas aplicaciones en el Web sea la habilidad de que funcionen para plataformas
múltiples, sin el costo de distribuir múltiples versiones del software como se mencionó anteriormente.
Cada una de las interfaces para comunicar al Web con bases de datos, ha sido creada basándose en una
tecnología de integración especial, a través de procesos de interconexión especiales.
Cuando se utiliza una interfaz para lograr la integración del Web con cierta base de datos, se puede verifi-
car que los procesos seguidos varían, dependiendo de la tecnología que se esté utilizando. Entre estas tec-
nologías se tienen las siguientes [11]:

2.4.1. El Common Gateway Interface (CGI)

Actualmente, ésta es la solución que más se está utilizando para la creación de interfaces Web/DBMS. Fue
probada por primera vez en el servidor que distribuye de manera gratuita la NCSA.
Se ha comprobado que si el Servidor Web recibe un URL con una solicitud, para devolver un documento
HTML como respuesta, tendrá que cargar el servicio (programa) que le indique las variables de ambiente y
de la forma HTML. La mayoría de las veces dicha llave es el "cgi-bin".
Entre las ventajas de la programación CGI, se tiene su sencillez, ya que es muy fácil de entender, además
de ser un lenguaje de programación independiente, ya que los escritos CGI pueden elaborarse en varios
lenguajes.
También es un estándar para usarse en todos los servidores Web, y funcionar bajo una arquitectura inde-
pendiente, ya que ha sido creado para trabajar con cualquier arquitectura de servidor Web.
Como la aplicación CGI se encuentra funcionando de forma independiente, no pone en peligro al servi-
dor, en cuanto al cumplimiento de todas las tareas que éste se encuentre realizando, o al acceso del estado
interno del mismo.
Pero el CGI presenta cierta desventaja en su eficiencia, debido a que el Servidor Web tiene que cargar el
programa CGI: luego conectarse y desconectarse con la base de datos cada vez que se recibe una requisi-
ción. Además, no existe un registro del estado del servidor, sino que todo hay que hacerlo manualmente.
2.4.2. Interfaz de Programación de Aplicaciones (API)
Es un conjunto de rutinas, protocolos y herramientas para construir aplicaciones de usuario. Una buena
API hace más fácil el trabajo de desarrollo de un programa, ya que debe proveer componentes bien docu-
mentados y estables para construirlo. El programador lo único que hace es poner todos los bloques en el
orden que se requieran en base a un diseño particular.
Las API’s están diseñadas especialmente para los programadores, ya que garantizan que todos los progra-
mas que la utilizan, tendrán interfaces similares. Asimismo, esto le facilita al usuario aprender la lógica de
nuevos programas y las especificaciones básicas en los manuales de usuario se reducen.

27
 B D / C S : : 2 0 0 4 : : M M

Cuando se realiza una requisición, el servidor llamará al API, brindando la ventaja de disponer de una ma-
yor cantidad de servicios. Y cuando estas se organizan como Bibliotecas de Ligado Dinámico (DLL’s)
reducen la carga en el servidor por tratarse de recursos compartidos por las diversas aplicaciones que los
utilizan.
2.4.3. Interfaz de Programación de Aplicaciones del Servidor Internet
(ISAPI)
Es la interfase propuesta por Microsoft como una alternativa más rápida que el modelo simple CGI y está
incluida en el servidor de Web que la empresa vende o distribuye con su SO, el producto se llama: Internet
Information Server (IIS).
Así como los programas CGI, los programas escritos usando ISAPI habilitan un usuario remoto con per-
misos adecuados para ejecutar un programa, busca, modifica o actualiza la información dentro de una base
de datos, o intercambia información con otro software localizado en el servidor.
El estándar ODBC (Open Data Base Connectivity) es una interfaz propuesta por Microsoft para facilitar
el desarrollo de aplicaciones sobre entornos de bases de datos distribuidas. La mayoría de las bases de da-
tos comerciales soportan este estándar y existe una versión adaptada a Java, llamada JDBC. Más concreta-
mente ODBC es una versión restringida de SQL que contiene los comandos más comúnmente utilizados.
Bajo esta arquitectura, la conexión entre una aplicación y un servidor de datos requiere la utilización de una
librería que oculta las diferencias de interacción debidas al sistema de gestión de bases de datos, el sistema
operativo y el protocolo de red utilizados.
Estas librerías son proporcionadas por los fabricantes de sistemas de gestión de bases de datos. El acceso a
una base de datos remota desde una aplicación requiere los siguientes pasos:
• La aplicación formula las consultas SQL en el lenguaje de ODBC.
• Un gestor de librerías proporcionado por Microsoft se encarga de arrancar la librería adecuada,
dependiendo del servidor al que vaya dirigido la consulta.
• La librería traduce la consulta al lenguaje específico del sistema de gestión de base de datos del ser-
vidor que la debe ejecutar.
• El servidor optimiza y ejecuta la consulta.

Fig. 2.5. Esquema de comunicación ODBC

Los programas escritos usando la interfaz ISAPI son compilados como bibliotecas de enlace dinámico
(DLL - Dynamic Link Library), ya que son cargados por el servidor Web cuando éste se inicia. Dichos
programas se vuelven residentes en memoria, por lo que se ejecutan mucho más rápido que las aplicacio-
nes CGI, debido a que requiere menos consumo de CPU al no iniciar procesos separados para cada servi-

28
 B D / C S : : 2 0 0 4 : : M M

cio solicitado. Uno de los programas ISAPI más usados es el HTTPODBC.DLL que se usa para enviar
y/o devolver información hacia y desde las bases de datos, a través del modelo ODBC.
Además, ISAPI permite realizar un procesamiento previo de la solicitud y uno posterior de la respuesta,
con lo cual controla el par: solicitud/respuesta sobre el protocolo HTTP. Los filtros ISAPI pueden utili-
zarse para aplicaciones tales como autenticación, acceso o apertura de sesión también.
2.4.4. Java y JDBC
Java ofrece un ambiente de programación muy sencillo, robusto, dinámico, de propósito general, orientado
a objetos y funcional en múltiples plataformas, es un producto distribuido por Sun MicroSystems de ma-
nera libre, al menos las versiones ligeras y académicas [12].
Java opera en un ambiente controlado denominado Máquina Virtual (VM), funcionando como compila-
dor y como lenguaje interpretado. El código fuente de Java es convertido en instrucciones binarias simples,
el cual es compilado para cada plataforma física en base a su código intermedio llamado bytecode.
El Compilador realiza todas las actividades de un procesador real en un ambiente virtual seguro. Es decir,
ejecuta instrucciones, crea y manipula información, carga y hace referencia a bloques de código nuevos. El
Intérprete, que es pequeño y muy útil, es capaz de ser implantado en cualquier forma que se desee para un
sistema operativo particular. Este puede correr como una aplicación independiente, o como una parte de
otro software, tal como son los Navegadores de Web.
El concepto de Java es diferente al de CGI, ya que el CGI se ejecuta en el servidor, mientras que Java se
ejecuta en el cliente o bien el lado del servidor (servlets).
Aplicaciones Java
Los programadores pueden desarrollar, ya sea, pequeñas aplicaciones, las cuales permiten tener sitios Web
con una gran funcionalidad en cuanto a: animación, actualización en vivo, interacción bidireccional y más.
Al integrarse en una página Web, las aplicaciones de Java tienen acceso a:
• Creación y recreación de gráficos avanzados.
• Interacción en tiempo real con los usuarios.
• Actualización en vivo de la información.
• Interacción instantánea con los servidores a través de la red.
Las aplicaciones de Java pueden obtenerse de manera libre y funcionan de forma segura bajo cualquier
plataforma o arquitectura de CPU compatibles y con los requerimientos básicos, permitiendo introducirlas
en páginas HTML. Es posible crear aplicaciones independientes y ejecutarlas como Frames dentro de la
máquina virtual instalada localmente, es decir puede uno abstraerse del Navegador como interfase.
Procesamiento Cliente/Servidor con Java
Por lo general, las aplicaciones Web son procesadas completamente en el lado del servidor, lo cual no es
precisamente lo más apropiado, ya que significa un uso excesivo de memoria, manteniendo al usuario en la
espera mientras termina de ejecutarse. Pero los Navegadores que incorporan Java (del lado del usuario)
pueden ejecutar aplicaciones, y no sólo desplegar documentos HTML, poniendo a correr el proceso en el
lugar apropiado.

29
 B D / C S : : 2 0 0 4 : : M M

Las aplicaciones clásicas proveen de información acerca de los tipos de formato (tipos MIME). Los brow-
ser del Web rápidos son capaces de aprender cómo tratar con nuevos protocolos y dar formato dinámica-
mente a los datos.
Seguridad
Java está diseñado para proveer la máxima seguridad posible en redes públicas, con múltiples formas de
seguridad ante virus, posibles invasiones o accesos incorrectos y archivos basura. Java debe entenderse que
opera como C++, es decir es un Lenguaje Orientado a Objetos completo, en la cual se puede causar cual-
quier daño. Es funcional como C y modular como C++.
Conectividad de Bases de Datos de Java (JDBC)
Se considera el primer producto estándar de Java con capacidades de un DBMS, creado y ofrecido por
primera vez en marzo de 1996. JDBC ofrece una interfase de programación que permite comunicarse con
las bases de datos mediante un concepto similar al de componentes ODBC, el cual se ha convertido en el
estándar que se utiliza en computadoras personales o en redes locales.
El estándar de JDBC está basado en un nivel de interfase con instrucciones SQL X/Open, que es básica-
mente lo mismo que en ODBC.
Las clases de objetos para iniciar la transacción con la base de datos, están escritas completamente en Java,
lo cual permite mantener la seguridad, robustez y portabilidad de este ambiente.
El puente JDBC-ODBC manipula la traducción de llamadas JDBC a aquellas que puedan ser entendidas
por el cliente ODBC a un nivel de lenguaje funcional.
2.4.5. JavaScript
Es un lenguaje muy poderoso y especialmente diseñado para la creación de scripts (programas que operan
en un ambiente interpretado), que se alojan dentro de un documento HTML. Dicho lenguaje es creación y
propiedad de la compañía Netscape, la cual distribuye un Navegador de código abierto.
Es un API programable que permite crear scripts para el manejo de eventos, objetos y acciones, bajo cual-
quier plataforma. Gracias a que JavaScript es parte de la conexión en vivo, se puede usar para construir
formas interactivas entre documentos HTML, Plug-ins (aplicaciones que corren dentro del browser del
Web) y Java.
Las conexiones en vivo habilitan:
• Navegación con Plug-ins, que se cargan en una página para interactuar con JavaScript y se encuen-
tran activos dentro de la misma página.
• Aplicaciones de Java cargadas en la misma página para comunicarse con los scripts hechos con Ja-
vaScript activos dentro de la misma página, y viceversa.
Mediante el uso de JavaScript se pueden enviar respuestas ante una variedad de eventos, objetos y accio-
nes, permitiendo cambiar imágenes o activar sonidos ante determinados eventos, tales como entrar o salir
de una página y sensar los eventos del ratón como medio de la interfase de usuario (GUI).
JavaScript es un lenguaje compacto, basado y orientado a objetos, para el desarrollo de aplicaciones Inter-
net Cliente/Servidor. Las instrucciones JavaScript que reconocen y responden ante eventos, pueden ser
introducidas directamente en una página Web. Por ejemplo, se puede escribir una función JavaScript que

30
 B D / C S : : 2 0 0 4 : : M M

verifique la correcta entrada de datos a una forma, sin necesidad de transmisión de datos a través de la red.
Así, una página HTML con código JavaScript puede interpretar el texto introducido y alertar al usuario si
por ejemplo hay un dato inválido antes de ser enviada la petición al servidor.
2.4.6. Oracle [13, cap 7]
Oracle forma parte de la última generación de sistemas de gestión de base de datos relacionales que hay
disponibles en el mercado. La principal novedad de este sistema es que su modelo de datos se puede defi-
nir como objeto-relacional, en el sentido de que admite muchas de las características de las bases de datos
orientadas a objeto. Cada servidor de Oracle está constituido por una base de datos y una instancia.

La base de datos es el “lugar” donde se almacenan los datos, mientras que la instancia constituye el “meca-
nismo” que permite su manipulación. Este tema se dedica a analizar profundamente estas dos componen-
tes.

Una base de datos Oracle se compone de una estructura física y una estructura lógica, es decir, los datos son
almacenados dentro de unas estructuras físicas, y se acceden por medio de unas estructuras lógicas. Gracias
a esta separación entre lo físico y lo lógico, podemos realizar modificaciones en la estructura física sin que
afecte a las estructuras lógicas de la base de datos. La estructura lógica está compuesta por uno o más ta-
blespaces (espacios de tabla) y un conjunto de objetos de esquema que pueden ser: tablas, vistas, índices,
clusters, procedimientos, etc. En la estructura física aparecen tres tipos de ficheros:
• uno o más ficheros de datos,
• dos o más ficheros redo log, y
• uno o más ficheros de control.

Como muestra la siguiente figura, una instancia de Oracle consta de un área de memoria denominada SGA
(System Global Area) y una serie de procesos en background de dos tipos:
• Procesos de Usuario. Ejecutan el código de una aplicación.
• Procesos de Oracle. Atienden a los procesos de usuario y realizan el mantenimiento de la base
de datos.

Fig. 2.6. Organización del Sistema Global de Oracle

31
 B D / C S : : 2 0 0 4 : : M M

Oracle soporta clientes/servidores con entornos heterogéneos, donde cliente y servidor pueden usar dife-
rentes juegos de caracteres. El juego de caracteres de cada cliente es definido por el valor de la variable
NLS_LANG de su sesión. Para facilitar la conexión entre las bases de datos individuales de una base de
datos distribuida, Oracle usa database links, los cuales definen trayectorias (paths) a las bases de datos remo-
tas.

2.4.7. Cold Fusion

Este modelo para el manejo de bases de datos sobre Internet introdujo un concepto revolucionario, éste
consistió en extender al Lenguaje HTML, de tal manera que dentro de su código se incluyesen instruccio-
nes para el manejo de las BD. Posteriormente muchas compañías y grupos tomaron este camino.
Cold Fusion centra su potencialidad en la confiabilidad y el control del manejo de datos. Reconoce la
complejidad del manejo e interacción de escritos CGI, ofreciendo una potente seguridad, veloz carga de
datos, procesamiento rápido de escritos CGI que posibilita el cumplimiento de tareas de entrada o devolu-
ción de datos [11].
Utiliza fuentes de datos ODBC de 32-bits, las cuales deberán cumplir con el nivel 1 de los ODBC API y
soportar las sentencias SQL.
Entre las funciones de Cold Fusion están:
• Sirve a cualquier requisición de datos una vez cuente con la instalación y configuración de las fuen-
tes de datos ODBC de 32-bits.
• Detecta errores producidos por la mala configuración o por el registro completo de la bitácora del
servidor SQL.
• Funciona correctamente en una máquina remota. Se ejecuta sin problemas en el Microsoft Inter-
net Information Server (IIS), aún teniendo gran cantidad de solicitudes. Gracias a ello brinda un
correcto funcionamiento tanto en Internet como en Intranets.
• Provee de ayuda para la configuración que permita generar páginas HTML en forma dinámica.
• Crea estructuras condicionales dinámicamente para personalizar la solicitud de datos y el envío de
los mismos hacia el cliente. Así mismo, diseña cadenas de datos para crear dinámicamente menús
desplegables y para llenar listas de selección y listas de documentos.
Para crear aplicaciones de Cold Fusion, se necesita del conocimiento previo de sentencias SQL para la
generación de código en la selección de la correcta información alojada en una base de datos. Gracias a las
sentencias SQL se tiene un control completo sobre qué, dónde y por qué desplegar los datos dentro de
un sitio Web.
Funcionamiento de Cold Fusion

Una vez se ha realizado la instalación de este paquete, se pueden realizar requisiciones a través de un URL,
las cuales son enviadas al servidor Web, y éste a su vez la hace a la interfaz de Cold Fusion, la que se conec-
ta a una fuente de datos ODBC, a la cual solicita los datos que requiere extraer de la base de datos.
Como puede verse, Cold Fusion utiliza fuentes de datos ODBC, de las que incluye una versión dentro del
software de instalación, para poder manipular la información dentro de las bases de datos.

32
 B D / C S : : 2 0 0 4 : : M M

Una vez se ha obtenido la información que se ha solicitado, la interfaz envía los datos hacia el Servidor
Web y éste al browser, en donde los mismos son desplegados gráficamente.
En la siguiente figura se muestra el proceso que sigue Cold Fusion al momento de recibir y responder a
una requisición.

Fig. 2.5. Arquitectura de Cold Fusion para acceder bases de datos en el Web.
Entrada y Despliegue de datos

Cold Fusion hace uso de formas HTML estándar con validación de datos de los campos, para realizar la
inserción y actualización de registros dentro de una tabla en una base de datos.
Para la entrada de datos se especificará el tipo de dato a introducir en un campo específico. Este tipo de
datos puede ser de valor entero, flotante, de fecha o en un rango especial de fechas. Además, se puede
registrar la hora de introducción del valor de un campo, la dirección IP (Protocolo Internet) desde la que se
hace una solicitud, el nombre del cliente y el tipo de browser que éste utiliza para acceder los datos, todo
ello sin necesidad de escribir una línea de código.
En cuanto al despliegue de datos, Cold Fusion solamente recibe la solicitud del cliente y realiza la presenta-
ción de los mismos de una manera muy sencilla.
Cold Fusion posee un control completo del formato de despliegue de datos, permite colocar enlaces entre
los mismos datos extraídos de la base, en las páginas HTML que han sido generadas al vuelo.
Gracias a esta flexibilidad, se puede realizar cualquier tipo de selección de despliegue de datos, y el software
se acomodará a las especificaciones realizadas. Como puede observarse, Cold Fusion realiza todo el proce-
dimiento necesario, desde la recolección de información en un servidor de base de datos SQL, hasta el
despliegue de la misma. Así mismo, Cold Fusion permite alojar procedimientos y pasar datos a ellos muy
fácilmente.

33
 B D / C S : : 2 0 0 4 : : M M

2.4.8. Perl
Probablemente este sea uno de los lenguajes mas utilizados para el manejo de BD en sitios Web en los
ambientes del Software Libre. La razón es simple: nació en los entornos UNIX, se ha mejorado en los
Linux, existe mucha documentación [16, 17] y soporte a través de los grupos y por ser gratuito. Su manejo
para los programadores de C, C++ y scripts en shell es simple, no así para los programadores acostumbra-
dos a las interfaces visuales de desarrollo. Respecto a esto último en los ambientes Linux se ha desarrollado
reciente mente una plataforma visual (privada) en modo gráfico llamada VisualPerl.
Las siglas Perl son un acrónimo de “Practical Extraction Report Language”, fue desarrollado por Larry
Wall en 1986 sobre sistemas UNIX como una herramienta para la generación de reportes en forma de
textos de manera automática. Es una herramienta desarrollada en C y se distribuye para diferentes plata-
formas en binario y se puede bajar su código fuente y adaptarlo a nuevas necesidades [14].
Algunas de las ventajas que Perl ofrece son [11]:
o Portabilidad de código en diversas plataformas.
o Existencia de operadores extremadamente robustos para manipular cadenas de caracteres,
así como funciones para tratar con datos binarios.
o Métodos simples para la construcción y manipulación de objetos definidos por el usuario.
o Ejecución de programas de forma interpretada.
o Facilidad para invocar comandos y funciones shell del sistema operativo.
o Habilidad para acceder variables de entorno.
o Existencia de numerosas extensiones o módulos para interactuar con otro tipo de pro-
gramas, como bases de datos.
A partir de estas y otras ventajas que Perl ofrece, así como también de la existencia de extensiones para
ODBC/Windows, es posible construir aplicaciones que permitan acceder diversas bases de datos a través
del Web.
Estas extensiones fueron desarrolladas por Dave Roth [16], y posibilitan que un escrito Perl haga uso de
una serie de funciones para comunicarse con una base de datos. Las extensiones de Roth permiten que un
escrito Perl acceda una base de datos a través de sentencias SQL. Estas extensiones funcionan únicamente
para la versión Perl de 32 bits y que trabajan solo con aquellas bases de datos que posean manejador (dri-
ver) ODBC de 32 bits.
Características y Funciones
Por lo general, un programa CGI se invoca desde el atributo ACTION de un formulario. Este programa
tiene por objetivo generar información dinámica a partir de los criterios especificados por el usuario en los
campos del formulario.
Como ya se dijo, Perl posee todas las características para actuar como CGI entre el Web y una base de
datos. En particular para plataformas Windows de 32 bits, Perl puede cumplir con esta tarea efectivamente
ya que existen una serie de extensiones que permiten establecer conexiones con diversos tipos de bases de
datos vía ODBC. Estas extensiones permiten incrustar sentencias SQL en un escrito Perl a través de las

34
 B D / C S : : 2 0 0 4 : : M M

cuales serán enviadas a la base de datos. Las principales funciones que las extensiones ODBC ofrecen a un
escrito Perl son:
o new(): Crea una instancia del objeto que establece conexión con una base de datos.
o sql(): Envía sentencias SQL a la base de datos, vía ODBC.
o fieldnames(): Genera los nombres de los campos obtenidos a partir de una sentencia SELECT.
o fetchrow(): Recupera hacia el buffer, una fila del conjunto de resultados obtenidos por una senten-
cia SELECT.
o data(): De cada fila de resultados , se obtienen los respectivos campos seleccionados.
o error(): Si existe algún error en las llamadas a las anteriores funciones , informa del tipo del error.
Para usar las extensiones ODBC de Perl-Win32, en un escrito que actúe como CGI deben incluirse:
o Llamada a módulo ODBC al principio de escrito Perl.
o Descodificar entrada proveniente del formulario.
o Imprimir Tipo de Contenido a desplegar en el Browser (Texto ó HTML).
o Crear una instancia para cada base de datos con la que se desea establecer comunicación.
o Construir dinámicamente sentencia SQL, en base a los datos ingresados por el usuario.
o Ejecución de sentencia SQL.
o Si la sentencia SQL es un SELECT deben manipularse los datos provenientes de la base de datos,
para luego desplegarse al usuario en el formato adecuado.
Arquitectura
Las extensiones ODBC deben ser llamadas desde un escrito Perl que pueda comportarse como aplicación
CGI 1.1. Tales extensiones permiten que desde un escrito Perl se pueda establecer comunicación con una
base de datos a través de ODBC; lo cual implica que los criterios que un usuario ha especificado en un
formulario se procesen y se conviertan en sentencias SQL, para que el ODBC las intérprete y sean envia-
das a la base de datos, con el objetivo de obtener los resultados esperados de la misma.
Este procedimiento se ilustra en la Figura 2.6.
Las extensiones ODBC para Perl constan de dos archivos:
1. ODBC.PLL: Es la extensión Perl para ODBC, escrita y compilada en Lenguaje C. Un archivo con
extensiones .PLL no es más que un .DLL, que será cargado dinámicamente por Perl cada vez que
se requieran los módulos o extensiones dentro de un escrito Perl.
2. ODBC.PM : Archivo que provee al programador de una interfaz sencilla para hacer uso de las
funciones contenidas en ODBC.PLL.

35
 B D / C S : : 2 0 0 4 : : M M

Fig. 2.6. Arquitectura de de Extensiones ODBC para Perl Win32.

En los ambientes Linux Perl viene incluido en la mayoría de la distribuciones y forma parte de muchas de
las aplicaciones que el SO realiza.

2.4.9. C#
Hay una corriente que no debemos dejar fuera ya que a nivel comercial tiende a ser una gran ola en las
aplicaciones para el Web y se trata de una propuesta de Microsoft llamada C# (C sharp). Este lenguaje es
una síntesis que trata de unificar los esfuerzos de la mencionada empresa para contar con una plataforma
uniforme de desarrollo en Internet y lo propone como una alternativa a futuro para ASP.
Microsoft en el mercado de ambientes para desarrollar aplicaciones Web introdujo diversas clases y biblio-
tecas a sus lenguajes de batalla, a saber: Visual Basic y Visual C++, las adiciones incorporadas trataron de
darles a éstos la funcionalidad para crear aplicaciones en éste entorno. Dado que otras opciones, como lo
es Java, empezaban a desplazar a sus producto en ese ambiente se formuló una alternativa que pudiera
competir y esa es este lenguaje. Toma el esquema general de la POO, elimina los apuntadores, como Java
lo hizo, usa un clon entre C y Basic como gramática y se ofrece inicialmente como software libre. Luego se
incorpora en una plataforma uniforme para crear programas para Internet llamada .NET (punto net). Y se
crea la ola que ha hecho que las diversas empresas de su clase la incluyan en sus propuestas de herramien-
tas de desarrollo.
Se entiende que C# es el lenguaje nativo para el ambiente de ejecución .NET (Common Language Runti-
me), está basado en el paradigma de componentes, es decir los objetos se escriben como componentes y
las componentes son el centro de acción de las aplicaciones [18].
Los conceptos relativos a las componentes, tales como: propiedades, método y eventos; son los ciudada-
nos de primera clase del lenguaje así como del ambiente de ejecución asociado. La información declarativa
(conocida como atributos o propiedades) puede ser aplicada a los componentes para pasar información a
los ambientes de diseño y ejecución acerca de ellos a otras partes del sistema. La documentación puede
escribir dentro de la componente y puede ser exportada a XML. Los objetos en C# no requieren de archi-
vos de encabezado (como sucede con ASP) o bibliotecas de tipos (como es el caso de Visual C++) para
ser creados o usados. Los componentes creados en C# se autodescriben y pueden ser usados sin procesos
de registro.
Microsoft arguye que C# es auxiliado en la creación de componentes por los ambientes de ejecución y
trabajo de la plataforma .NET, lo cual ofrece un tipo unificado de sistema en el cual todo puede ser tratado
como un objeto, pero sin la incidencia en el rendimiento asociada a los sistemas formados por objetos
“puros”, como es el caso de Smalltalk.

36
 B D / C S : : 2 0 0 4 : : M M

En lo relativo al manejo de errores C# ofrece el esquema de manejo de excepciones dentro de su ambien-

te y tiende a proteger la aplicación cuando se utilizan variables no inicializadas, casts inseguros y otros ero-
res típicos de programación, éste control se realiza en tiempo de diseño bajo las herramientas de Microsoft,
cabe mencionar que éste modelo fue introducido por Borland – Inprise en un producto heredero de Pas-
cal llamado Delphi.
Éste lenguaje permite la reutilización de códigos existentes de la misma empresa o desarrollados con
herramientas de ella. Objetos de tipo COM pueden ser utilizados como si fueran objetos .NET, los códi-
gos nativos creados en C e inmersos en Bibliotecas de Ligado Dinámico (DLL’s) pueden ser llamados
desde C#. El acceso de bajo nivel es seleccionado por su máquina virtual. Existe un modo llamado unsafe
(inseguro) que permite que se usen apuntadores en aquellos casos donde la eficiencia sea importante o
cuando son requeridos por una DLL que se ha invocado.
Fuera del ambiente MS Windows se ha credo un grupo que ha trasladado el concepto de C# a un modelo
abierto con la misma funcionalidad para adaptar principalmente los Navegadores y los sistemas con esa
parte del mundo de Internet, la iniciativa lleva el nombre Open Conectivity Over NET.

2.4.10. PHP
Este lenguaje ha ganado un espacio especial en los entornos de desarrollo de aplicaciones para Internet
también. Los créditos los ha ganado por ser Open Source (código abierto), estar muy bien documentado,
ligero, multiplataforma y simple de utilizar.
La siguiente referencia ha sido tomada del sitio oficial del Lenguaje [18,19].
- PHP/FI
PHP es el heredero de un producto anterior, llamado PHP/FI. PHP/FI fue creado por Rasmus Lerdorf
en 1995, inicialmente como un simple conjunto de scripts de Perl para controlar los accesos a su trabajo
online. Llamó a ese conjunto de scripts 'Personal Home Page Tools'. Según se requería más funcionalidad,
Rasmus fue escribiendo una implementación C mucho mayor, que era capaz de comunicarse con bases de
datos, y permitía a los usuarios desarrollar sencillas aplicaciones Web dinámicas. Rasmus eligió liberar el
código fuente de PHP/FI para que cualquiera pudiese utilizarlo, así como arreglar errores y mejorar el
código.
PHP/FI, que se mantuvo para páginas personales y como intérprete de formularios, incluía algunas de las
funcionalidades básicas de PHP tal y como lo conocemos hoy. Tenía variables como las de Perl, interpre-
tación automática de variables de formulario y sintaxis embebida HTML. La sintaxis por sí misma era simi-
lar a la de Perl, aunque mucho más limitada, simple y algo inconsistente.
Por 1997, PHP/FI 2.0, la segunda escritura de la implementación en C, tuvo un seguimiento estimado de
varios miles de usuarios en todo el mundo, con aproximadamente 50.000 dominios informando que lo
tenían instalado, sumando alrededor del 1% de los dominios de Internet. Mientras había mucha gente con-
tribuyendo con bits de código a este proyecto, era todavía en su mayor parte el proyecto de una sola per-
sona.
PHP/FI 2.0 no se liberó oficialmente hasta Noviembre de 1997, después de gastar la mayoría de su vida
en desarrollos beta. Fue sucedido en breve tiempo por las primeras versiones alfa de PHP 3.0.

37
 B D / C S : : 2 0 0 4 : : M M

- PHP 3
PHP 3.0 era la primera versión que se parecía fielmente al PHP tal y como lo conocemos hoy en día. Fue
creado por Andi Gutmans y Zeev Zuraski en 1997 rescribiéndolo completamente, después de que encon-
traran que PHP/FI 2.0 tenía pocas posibilidades para desarrollar una aplicación comercial que estaban
desarrollando para un proyecto universitario. En un esfuerzo para cooperar y empezar a construir sobre la
base de usuarios de PHP/FI existente, Andi, Rasmus y Zeev decidieron cooperar y anunciar PHP 3.0 co-
mo el sucesor oficial de PHP/FI 2.0, interrumpiéndose en su mayor parte el desarrollo de PHP/FI 2.0.
Una de las mejores características de PHP 3.0 era su gran extensibilidad. Además de proveer a los usuarios
finales de una sólida infraestructura para muchísimas bases de datos, protocolos y APIs, las características
de extensibilidad de PHP 3.0 atrajeron a docenas de desarrolladores a unirse y enviar nuevos módulos de
extensión. Sin duda, ésta fue la clave del enorme éxito de PHP 3.0. Otras características clave introducidas
en PHP 3.0 fueron el soporte de sintaxis orientado a objetos y una sintaxis de lenguaje mucho más potente
y consistente.
Todo el nuevo lenguaje fue liberado bajo un nuevo nombre, que borraba la implicación de uso personal
limitado que tenía el nombre PHP/FI 2.0. Se llamó 'PHP' a secas, con el significado de ser un acrónimo
recursivo - PHP: Hypertext Preprocessor.
A finales de 1998, PHP creció hasta una base de instalación de decenas de millares de usuarios (estimados)
y cientos de miles de sitios Web informando de su instalación. En su apogeo, PHP 3.0 estaba instalado en
aproximadamente un 10% de los servidores Web en Internet. PHP 3.0 se liberó oficialmente en Junio de
1998, después de haberse esperado unos 9 meses en pruebas públicas.
- PHP 4
En el invierno de 1998, poco después del lanzamiento oficial de PHP 3.0, Andi Gutmans y Zeev Suraski
comenzaron a trabajar en la reescritura del núcleo de PHP. Los objetivos de diseño fueron mejorar la eje-
cución de aplicaciones complejas, y mejorar la modularidad del código base de PHP. Estas aplicaciones se
hicieron posibles por las nuevas características de PHP 3.0 y el apoyo de una gran variedad de bases de
datos y API´s de terceros, pero PHP 3.0 no fue diseñado para el mantenimiento tan complejo de apli-
caciones eficientemente.
El nuevo motor, apodado 'Motor Zend' (comprimido de sus apellidos, Zeev y Andi), alcanzó estos objeti-
vos de diseño satisfactoriamente, y se introdujo por primera vez a mediados de 1999. PHP 4.0, basado en
este motor, y acoplado con un gran rango de nuevas características adicionales, fue oficialmente liberado
en Mayo de 2000, casi dos años después que su predecesor, PHP 3.0. Además de la mejora de ejecución de
esta versión, PHP 4.0 incluía otras características clave como el soporte para la mayoría de los servidores
Web, sesiones HTTP, buffers de salida, formas más seguras de controlar las entradas de usuario y muchas
nuevas construcciones de lenguaje.
PHP 4 es actualmente la última versión liberada de PHP. Ya se está trabajando en modificar y mejorar el
motor Zend para integrar las características que se diseñarían para PHP 5.0.
Hoy, se estima que PHP es usado por cientos de miles de programadores y muchos millones de sitios in-
forman que lo tienen instalado, sumando más del 20% de los dominios en Internet.
El equipo de desarrollo de PHP incluye docenas de programadores, así como otras docenas de personas
trabajando en proyectos relacionados con PHP como PEAR y el proyecto de documentación.

38
 B D / C S : : 2 0 0 4 : : M M

- PHP 5
El futuro de PHP está dirigido por su núcleo, el motor Zend. PHP 5 incluirá el nuevo motor Zend 2.0.
Para obtener más información sobre este motor, consultar su página Web [21].
Características.[22]
El siguiente es un script en PHP:

<html>
<head>
<title>Example</title>
</head>
<body>

<?php
echo "Hi, I'm a PHP script!";
?>

</body>
</html>

Podemos ver que no es lo mismo que un script escrito en otro lenguaje de programación como Perl o C
++ En vez de escribir un programa con muchos comandos para crear una salida en HTML, escribimos el
código HTML con cierto código PHP embebido (introducido) en el mismo, que producirá cierta salida (en
nuestro ejemplo, producir un texto). El código PHP se incluye entre etiquetas especiales de comienzo y final que
nos permitirán entrar y salir del modo PHP.
Lo que distingue a PHP de la tecnología Javascript, la cual se ejecuta en la máquina cliente, es que el código
PHP es ejecutado en el servidor. Si tuviésemos un script similar al de nuestro ejemplo en nuestro servidor,
el cliente solamente recibiría el resultado de su ejecución en el servidor, sin ninguna posibilidad de determinar que
código ha producido el resultado recibido. El servidor Web puede ser incluso configurado para que procese todos
los archivos HTML con PHP.
Lo mejor de usar PHP es que es extremadamente simple para el principiante, pero a su vez, ofrece muchas
características avanzadas para los programadores profesionales. Aunque el desarrollo de PHP está concen-
trado en la programación de scripts en la parte del servidor, se puede utilizar para muchas otras tareas, en
general se puede considerar un lenguaje de propósito general. Su estructura es tipo C, más no requiere de
declaración de variables, para el lenguaje todas son cadenas, en caso de ser números las cadenas, éstos se
pueden operar aritmética y lógicamente de manera normal. Tiene manejo de archivos locales, se pueden
declarar funciones, es posible utilizar el paradigma de programación orientada a objetos y crear clases [27,
parte II], en esta referencia se presentan los siguientes temas:

Síntaxis básica Operadores

Tipos Estructuras de Control
Variables Funciones
Constantes Clases y Objetos
Expresiones Explicando las Referencias

39
 B D / C S : : 2 0 0 4 : : M M

Capítulo 3. Acceso a BD remotas con PHP/mySQL

PHP puede hacer cualquier cosa que se pueda hacer con un script CGI, como procesar la información de
formularios, generar páginas con contenidos dinámicos, o mandar y recibir cookies, entre otras acciones.
Existen tres campos en los que scripts escritos en PHP son usados:
• Scripts en la parte del servidor. Este es el campo más tradicional y el principal campo de trabajo.
Se necesitan tres cosas para que esto funcione. El analizador PHP (CGI ó módulo), un servidor
Web y un Navegador. Se necesita correr el servidor Web con PHP instalado. El resultado del pro-
grama PHP se puede obtener a través del navegador, conectando con el servidor Web.
• Scripts en línea de comandos. Se pueden crear scripts en PHP y correrlos sin echar mano de un
servidor Web ó Navegador. Solamente se necesita el parser PHP para usarlo de esta manera. Este
tipo de uso es ideal para scripts ejecutados regularmente desde cron (en *nix ó Linux) ó el Planifi-
cador de tareas (en Windows). Estos scripts también pueden ser usados para tareas simples de
procesado de texto.
• Escribir aplicaciones gráficas clientes. PHP no es probablemente el mejor lenguaje para escri-
bir aplicaciones gráficas, pero si uno explota adecuadamente las capacidades de PHP, y se utilizan
algunas características avanzadas en programas clientes, es posible utilizar PHP-GTK para escribir
dichos programas. Es también posible escribir aplicaciones independientes de una plataforma.
PHP-GTK es una extensión de PHP [23].
PHP puede ser utilizado en cualquiera de los principales sistemas operativos del mercado, incluyendo
Linux, muchas variantes Unix (incluido HP-UX, Solaris y OpenBSD), Microsoft Windows, Mac OS X,
RISC OS y probablemente alguno más. PHP soporta la mayoría de servidores web de hoy en día, inclu-
yendo Apache, Microsoft Internet Information Server, Personal Web Server, Netscape y iPlanet, Oreilly
Website Pro server, Caudium, Xitami, OmniHTTPd y muchos otros. PHP tiene módulos disponibles para
la mayoría de los servidores, para aquellos otros que soporten el estándar CGI, PHP puede usarse como
procesador CGI.
Así que, con PHP se tiene la libertad de escoger el sistema operativo y el servidor más apropiado o bien
disponible. También se tiene la posibilidad de usar programación de procedimientos ó programación
orientada a objetos. Aunque no todas las características estándares de la programación orientada a objetos
están implementadas en la versión actual de PHP, muchas librerías y aplicaciones grandes (incluyendo la
librería PEAR) están escritas íntegramente usando programación orientada a objetos.
Con PHP no está uno limitado a resultados en HTML. Entre las habilidades de PHP se incluyen, creación
de imágenes, ficheros PDF y películas Flash (usando libswf y Ming) en tiempo de ejecución. También se
pueden presentar otros resultados, como XHTM y ficheros XML. PHP puede generar estos archivos y
grabarlos en el sistema de archivos en vez de presentarlos en la pantalla.

40
 B D / C S : : 2 0 0 4 : : M M

Quizás la característica más potente y destacable de PHP es su soporte para una gran cantidad de bases de
datos. Escribir un interfaz vía Web para una base de datos es una tarea simple con PHP. Las siguientes
bases de datos están soportadas actualmente:
Adabas D Ingress Oracle (OCI7 and OCI8)
dBase InterBase Ovrimos
Empress FrontBase PostgreSQL
FilePro (read-only) mSQL Solid
Hyperwave Direct MS-SQL Sybase
IBM DB2 MySQL Veloces
Informix ODBC Unix dbm

Tabla 3.1. Bases de datos soportadas por PHP

También se tiene una extensión DBX de abstracción de base de datos que permite usar de forma transpa-
rente cualquier base de datos soportada por la extensión. Adicionalmente, PHP soporta ODBC (The
Open Database Connection Standard), así que se puede realizar una conexión a cualquier base de datos
que soporte este estándar.
PHP también tiene soporte para comunicarse con otros servicios usando protocolos tales como LDAP,
IMAP, SNMP, NNTP, POP3, HTTP, COM (en Windows) y muchos otros. Además se pueden crear raw
sockets. PHP soporta WDDX para intercambio de datos entre lenguajes de programación en Web. Y
hablando de interconexión, PHP puede utilizar objetos Java de forma transparente como objetos PHP Y
la extensión de CORBA puede ser utilizada para acceder a objetos remotos.
PHP tiene unas características muy útiles para el proceso de texto, desde expresiones regulares POSIX
Extended ó Perl y contiene un parser de documentos XML. Para parsear y acceder documentos XML, se
soportan los estándares SAX y DOM. Se puede utilizar la extensión XSLT para transformar documentos
XML.
En el campo del comercio electrónico, tiene las funciones Cybercash, CyberMUT, VeriSign Payflow Pro y
CCVS que pueden ser incluidos en los programas de pago en línea sobre Internet.
Para terminar, tenemos muchas otras extensiones muy interesantes, las funciones del motor de búsquedas
mnoGoSearch, funciones para pasarelas de IRC, utilidades de compresión (gzip, bz2), conversión de ca-
lendarios, traducción y otras.

3.1. Elementos de la aplicación

Para crear una ambiente de BD en un ambiente de red bajo PHP se requiere de un manejador de bases de
datos y un servidor de Web como se mencionó en el Capítulo anterior. Se podrá utilizar cualquier servidor
de Web que maneje a PHP como módulo o bien en un rol de CGI y de la lista anterior (Tabla 3.1.) se pue-
de elegir algún manejador de BD compatible.

La dinámica de interacción es la corriente y se compone de las fases conocidas para un modelo de 3 capas.
Como primer elemento vamos a discutir los elementos de HTML que permiten darle interactividad me-
diante la introducción de datos en una página de Web, la cual será visualizada por un Navegador que ma-
neje el estándar de HTML 4.

41
 B D / C S : : 2 0 0 4 : : M M

3.1.1. Formas en HTML

Una forma se declara mediante el par

<FORM> contenido </FORM>,

donde dentro del contenido se introducirán elementos activos que permitan la introducción de informa-
ción.

Los parámetros de la etiqueta <FORM> son los siguientes:

<FORM METHOD="cómo hacer el envío" ACTION="URL del script">

...form data...
</FORM>

El atributo METHOD acepta dos valores: POST y GET. El método POST es el más utilizado ya que permite
el envío de grandes volúmenes de datos. El método GET es más fácil de manejar y se utiliza para el manejo
de respuestas simples.

El segundo atributo es ACTION, que se utiliza para especificar el URL del script que procesará los da-
tos de la forma. Eventualmente se utiliza un directorio específico con cierto nivel de seguridad en el
lado del servidor para almacenar los scripts, normalmente la ruta es bin/ o cgi-bin/ como igual en je-
rarquía del directorio htdocs/ (conocido como nodo raíz del sitio de Web) donde está ubicado el Web
Server. En el caso de PHP, se hará referencia al archivo que contiene el programa escrito en éste
lenguaje. Normalmente se hace uso del esquema de rutas relativas para facilitar la reubicación de las
aplicaciones entre un server y otro.
El URL del script debe especificar le programa que se ejecutará al enviar la forma al servidor de Web,
algunos de los objeto que se encuentran dentro de la forma serán enviados como datos al servidor,
ésta es la parte que corresponde a la Interfase de Usuario (UI) que uno diseña para interactuar con
los usuarios del sistema. En general el sistema en el modelo Cliente/Servidor (CS) se conformará por
una serie de UI’s, las cuales forman la parte visible de la aplicación; unas serán de entrada y otras de
salida.
Si bien de manera primitiva con HTML no hay una gran variedad de elementos para interaccionar
con los usuarios los existentes son suficientes en general. Para ampliar este espacio se puede utilizar
un entorno de desarrollo diferente como es el de ActiveX, Delphi, Visual C++, Java Script, Java,
Visual Basic, C# o bien entornos dedicados como los que ofrece Oracle, Sybase, Progress, Clarion y
otros de su clase.
La etiqueta <input> tiene como propósito definir elementos activos de la forma, ésta tiene varios
argumentos los principales son:

type Define el tipo de objeto de entrada

name Declara el nombre del objeto
[value] Define el valor de la variable
[maxlength] Indica la longitud máxima del objeto, pe. para cadenas.
[size] Indica el tamaño del objeto

Existen otros atributos para <input> que dependen del tipo de objeto que se maneja.

42
 B D / C S : : 2 0 0 4 : : M M

Los elementos básicos (type) que pueden ser utilizados dentro la etiqueta <input> son los siguientes:
1. text: Campo de Texto (TextEdit). Se utiliza para la introducción de cadenas (texto)
2. password: Es una clase que campo de texto que de forma visual sustituye los caracteres de
entrada por asteriscos, con el propósito de esconder lo que el usuario introduce.
3. file: Permite la inserción de un archivo almacenado en el cliente y enviarlo al servidor.
4. radio: Se utiliza para definir una casilla de opción única o excluyente con otras de su tipo. Pa-
ra formar un grupo de selección el nombre (name) de las casillas debe ser el mismo y éstas se
discriminarán por su valor definido en value. Se enviará al servidor solo aquella que haya sido
seleccionada (cheked). De cada grupo se podrá seleccionar solo una.
5. checkbox: Se utiliza para definir una casilla de opción complementaria, puede haber marcada
ninguna, varias o todas. Estas se pueden manejar a través del atributo name como un grupo:
aquellas que llevan el mismo nombre; o como independientes, si cada una tiene un nombre
diferente, se enviará el valor de cada chekbox seleccionada. Si éstas se agrupan y se marca mas
de una se enviarán todas las marcadas con el mismo nombre (name) y diferentes valores (va-
lue).
6. Botón de acción. Presenta un botón de respuesta inmediata no cancelable que aceptan todo
el contenido de la forma. Hay tres tipos:
a. submit: Botón de envío. Manda el contenido de la forma al servidor desde el nave-
gador. Puede colocarse más de un botón de envío, para diferenciarlos se utilizan los
atributos name y value.
b. reset: Botón de restauración. Limpia o restaura los campos de la forma, en el primer
caso los borra y en el segundo les asigna los valores predeterminados (defaults). Este
no envía datos al servidor, es de acción local, acepta el atributo value.
c. image: Botón personalizado. Se construye junto con el atributo src, el cual indica el
origen (source) de la imagen que contendrá el botón. Cuando se hace Click en él por
parte del usuario el Navegador envía la forma al servidor (como es el caso del submit)
e incluye las coordenadas X-Y del cursor del ratón donde se encuentra la imagen.
Acepta los atributos: name, align y border.
Cuando se incluyan varios botones en el seno de una forma, para distinguirlos uno debe in-
cluir el atributo value con un valor determinado y diferente para cada botón. Normalmente si
se trata de botones de envío se suele asignar el mismo nombre (name) a cada botón para que
el programa que atiende la forma en el servidor de Web diferencie lo que usuario eligió y mo-
dificar el flujo de la aplicación. Se debe tener cuidado con los botones de imagen, ya que es-
tos no aceptan el atributo value, entonces para distinguirlos se debe manejar el atributo name.
7. hidden. Campos Ocultos. Este es un tipo singular de campo, ya que no es interactivo con el
usuario, es decir no es visible en el Navegador. Se utiliza para incluir información en las for-
mas que no debe ser ignorada o alterada por el navegador o el usuario. Se deben incluir los
atributos name y value de la etiqueta <input>. Los valores de estos campos se enviarán al ser-
vidor como es usual. Algunos usos que se le da a éste campo son:
a. Clasificación de Formas.
b. Identificación de la versión de una forma.

43
 B D / C S : : 2 0 0 4 : : M M

c. Administrar las interacciones CS. Por ejemplo se puede incluir información del solici-
tante cuando el servidor produce la página con la forma e identificar a quién pertene-
ce esa petición y en consecuencia hacer un seguimiento.
d. Selector de acciones en el lado del servidor. Dependiendo de uno o varios campos
ocultos el programa en el lado del servidor que atiende a la forma puede cambiar su
proceder dependiendo de los valores de las variables ocultas.
Otros elementos que pueden incluirse dentro de una forma son los siguientes:
1. <textarea>: Crea un área de texto multilínea en la ventana del navegador. En ella se puede
introducir información. Al ser enviadas al server se agrupan en una cadena, donde cada línea
de texto se separa por el código CR-LF (“%0D0A”) la cadena se asigna al atributo name del
área de texto. Pueden utilizarse los atributos cols, que regula el número de columnas y rows que
define el número de renglones visibles, a ambas se les asigna un entero. En el caso que se ex-
ceda el número de renglones aparecerá una barra se scroll vertical. Se acepta también el atri-
buto warp que sirve para hacer rompimiento automático de líneas, si su valor es virtual, se en-
viarán códigos de salto (CR-LF) sólo si el usuario los inserta y si se define Physical, se enviarán
códigos de salto en cada rompimiento que se produzca en el área de texto aunque el usuario
no los haya insertado.
2. <select>: Se utiliza para crear listas de elementos seleccionables (comboBox). Los atributos
que acepta son:
a. multiple: Habilita una selección múltiple.
b. size: Determina el número de opciones que el usuario podrá ver a la vez. SU valor
debe ser un entero positivo. El valor predeterminado es uno.
c. name: Indica el nombre del selector.
d. <option>: Define una componente de una lista de selección. Requiere el atributo va-
lue asociado a un valor, éste es que enviará la forma en caso de ser seleccionado. tex-
to-simple: Es una cadena que se introduce para que visualizada por el usuario dentro
de la lista. Se debe escribir a la derecha
Es posible mejorar la apariencia, funcionalidad y presentación de las formas usando JavaScript. Pue-
de consultarse más información sobre los elementos de una forma en la literatura relacionada con
HTML [7, 8, 10].

3.1.2. Interfase de Usuario

Una Interfase de Usuario en una aplicación Web directa es de tipo gráfico, por lo cual se le asigna la cate-
goría de Interfase Gráfica de Usuario (GUI), siempre que el navegador opere en ésta modalidad, recuerde
que existen Navegadores de Web en modo texto como es el caso Lynx de Linux, estos no serán operativos
para el manejo de las formas.

Ésta se genera mediante las etiquetas antes mencionadas, la funcionalidad debe estar determinada por el
tipo de acción que se desea realizar. La acción será realizada por el programa asociado a manera de URL en
la forma mediante el atributo action. Dicho programa recibirá la información recolectada por la forma co-
mo se mencionó anteriormente dependiendo del método (GET o POST). Dentro de la GUI se pueden
incluir otros elementos de HTML pasivos para guiar al usuario en el manejo de la forma, tales como: tex-
tos, tablas (<table>) y líneas de división (<hr>).

44
 B D / C S : : 2 0 0 4 : : M M

Existen herramientas como es el caso de HomeSite, Dreamweaver y Flash distribuidos comercialmente

por Macromedia, entre otras, que permiten crear dichas GUI con más elementos tales como menús, barras
de botones gráficos y paneles. El uso de éstas embellece la interfase y la hace más amigable al usuario final,
y obviamente requieren de algunas bibliotecas en el lado del cliente conectadas al Navegador generalmente
como Plugins.

Otros modelos han sido propuestos para generar interfases locales dentro del navegador como las Formas
ActiveX que ofrece Microsoft a través de Visual Basic, Visual C++ y C#, así como Borland mediante
Delphi, Builder C++ y Architect.. O bien las llamadas soluciones .NET ofertadas ahora por varias empre-
sas.

Otro modelo para realizar interfases ricas y versátiles lo ofrece Java mediante las clases que lo componen,
tanto a nivel de Applets como de Frames.

3.1.3. Programas de atención

Estos como se mencionó anteriormente se pueden elaborar con diferentes lenguajes, siempre que el Servi-
dor de Web los pueda invocar, así como realizar conexiones de entrada y salida con ellos. Cada servidor de
Web acepta diferentes Lenguajes. Algunos servidores, como es el caso de Apache, permiten incluir a los
Lenguajes de programación como módulos dentro de ellos. Otros se restringen a los aceptados por cons-
trucción. Éstos últimos eventualmente resultan limitantes.

3.1.4. Servidor de Web y Manejador de Base de Datos

Es posible elegir dentro de una amplia gama de opciones. Depende mucho del rendimiento esperado en
función del tipo de aplicación que se desarrolla, la seguridad, el tipo de equipo que se usa como plataforma,
el número de usuarios que se atenderá por unidad de tiempo, el sistema operativo sobre el que trabaja, el
presupuesto asignado y el lenguajes o lenguajes de programación que se usarán para el desarrollo del siste-
ma o sistemas sobre demanda. En general se pueden elegir servidores comerciales o públicos, cada uno
tendrá sus ventajas y desventajas. Para tomar una decisión debe analizarse el entorno de operación existen-
te, el tipo de problema(s) que se desea atacar y las aplicaciones a futuro que se desean desarrollar. Este
compromiso debe permitir elegir una suite conveniente a la medida del problema: actual y a futuro.

3.2. MySQL
Dentro de los DBMS que permiten la creación de aplicaciones CS, el ambiente de MySQL ofrece una
solución integral, es un sistema con seguridad y opera bajo el modelo de Open Source. Esto hace del ma-
nejador una opción atractiva e interesante para la creación de aplicaciones CS sobre Internet. La documen-
tación pública [24] y privada [25] sobre el DBMS es amplia y existe soporte para el producto. Inclusive se
puede hacer una suscripción a un entorno comercial para la venta de productos basados en él. El producto
cumple con los estándares SQL-92 y ODBC niveles 0-3.51. E incorpora elementos de SQL-99 mante-
niendo un compromiso con su eficiencia y estabilidad. Un elemento no soportado y que ofrecen otros
DBMS es el de procedimientos almacenados hasta la versión liberada (4.0.16), se ofrece en la versión 5.0
incluirlos. UN procedimiento almacenado es un conjunto de instrucciones SQL que pueden ser compiladas y
almacenadas en el lado del servidor y posteriormente invocadas según sea necesario. El manejo de llaves
foráneas es limitado, esto ocasiona que el diseño de las BD sea mas fino debido a la restricción.

Existen versiones para diversas plataformas y SO’s (MS Windows, Linux, Mac OS X, varias versiones de
UNIX y Netware: revisar sección 2.2.5 del manual oficial), distribuidas como binarios o en código fuente.

45
 B D / C S : : 2 0 0 4 : : M M

Los procedimientos de instalación y configuración son claros y generalmente si la plataforma cumple los
requerimientos solicitados el sistema es funcional y estable.

Las carpetas que crea el proceso de instalación de los archivos binarios son típicamente las siguientes:

Carpeta Contenido
‘bin’ Programas cliente y mysqld server
`data’ Sitio para las Bases de Datos y archivos de registro (logs)
`docs’ Documentación
`include’ Archivo Include (header)
`lib’ Bibliotecas
`scripts’ mysql_install_db
`share/mysql’ Archivos con mensajes de error en diferentes idiomas
`bench’ Benchmarks
‘examples’ Ejemplos
‘doc’ Documentación en texto y HTML del sistema
‘embebed’ Bibliotecas estáticas y DLL’s
‘scripts’ Scripts de ejemplo y sitio para nuevos scripts

Tabla 3.1. Carpetas de MySQL típicas

El sistema ofrece diferentes API para realizar aplicaciones sobre el DBMS, algunas de ellas corresponden
a: C, C++, Java, Delphi, Pitón, PHP, Perl, Tcl y Eiffel. En el manual oficial [24] se puede encontrar infor-
mación detallada de su uso.

3.3. Apache
Apache es un servidor de Web también bajo el esquema de Open Source que tiene soporte para una gran
variedad de plataformas, algunas de éstas son:

AUX 3.1 IRIX 5.3 SolarisX86 2.5 UnixWare 1.1.

BSDI 2.0 Linux Solaris 2.4 Netware
FreeBSD 2.1 NetBSD 1.1 Solaris 2.5 MS Windows
HP-UX 9.07 NEXTSTEP SunOS 4.1.3 Mac OS X

El servidor opera como uno normal y contiene las siguientes extensiones:

• Autenticación basada en Cookies

• Soporte para definir el UID y GID al ejecutarse scripts CGI
• Autenticación de usuarios usando el sistema de BD de cuentas de UNIX
• Módulos mejorados en el lado del servido: Server Side Include (SSI)
• Intérprete incrustado de Perl
• Autentificación basada en Kerberos

46
 B D / C S : : 2 0 0 4 : : M M

• Traductores de conjuntos de caracteres

• Módulos de autentificación de usuarios para BD Postgres95 y mSQL
• Contadores de páginas Web
• Formatos de registro extendidos (logs)
• Autenticación NIS
• Módulos de reescritura de URI/URL
• Procesador de scripts para Tcl
• Diferentes alternativas para módulos CGI, pe. FastCGI

La documentación del servidor es bastante completa e indica cómo instalarlo y configurarlo, éste se puede
levantar automáticamente o de manera manual. Se ofrece en algunas plataformas una interfase para moni-
torearlo y administrarlo.
En las secciones 5 y 6 del manual se discuten las diferentes maneras para ejecutar CGI, así como los len-
guajes soportados por defecto, algunas extensiones y funciones, en particular es interesante el apéndice C
que contiene la interfase de programación para el esquema mejorado de CGI’s llamada FastCGI.. En la
sección 10 del manual se explican los módulos que se pueden utilizar, cómo levantarlos y configurarlos.
Este material se puede encontrar en el CD adjunto a estas notas en la carpeta de Apache [26].

3.4. PHP
Como se explicó en el capítulo anterior PHP es un lenguaje de propósito general que es posible usar para
el desarrollo de aplicaciones en lado del servidor sobre la Web. Al incluir el manejo de PHP dentro del
servidor de Web Apache 2.0 uno logra la funcionalidad completa del lenguaje, en particular PHP habilita
un conjunto muy completo de funciones y métodos para acceder a BD sobre MySQL, a continuación se
enlistan:

FUNCION PHP DESCRIPCIÓN

mysql_affected_rows Devuelve el número de filas afectadas de la última operación MySQL

mysql_change_user Cambia el usuario conectado en la conexión activa
mysql_client_encoding Devuelve el nombre del juego de caracteres
mysql_close Cierra el enlace con MySQL
mysql_connect Abre una conexión a un servidor MySQL
mysql_create_db Crea una base MySQL
mysql_data_seek Mueve el puntero interno
mysql_db_name Obtener datos de resultado
mysql_db_query Envía una sentencia MySQL al servidor
mysql_drop_db Borra una base de datos MySQL
mysql_errno Devuelve el número del mensaje de error de la última operación MySQL
mysql_error Devuelve el texto del mensaje de error de la última operación MySQL
mysql_escape_string Cadena de escape para su uso en mysql_query.
mysql_fetch_array Extrae la fila de resultado como una matriz asociativa
mysql_fetch_assoc Recupera una fila de resultado como una matriz asociativa
mysql_fetch_field Extrae la información de una columna y la devuelve como un objeto.
mysql_fetch_lengths Devuelve la longitud de cada salida en un resultado

47
 B D / C S : : 2 0 0 4 : : M M

FUNCION PHP DESCRIPCIÓN

mysql_fetch_object Extrae una fila de resultado como un objeto

mysql_fetch_row Devuelve una fila de resultado como matriz
mysql_field_flags Devuelve las banderas (flags) asociadas con el campo especificado en un resultado
mysql_field_len Devuelve la longitud del campo especificado
mysql_field_name Devuelve el nombre del campo especificado en un resultado
mysql_field_seek Asigna el apuntador del resultado al offset del campo especificado
mysql_field_table Devuelve el nombre de la tabla donde esta el campo especificado
mysql_field_type Devuelve el tipo del campo especificado en un resultado
mysql_free_result Libera la memoria del resultado
mysql_get_client_info Obtener información del cliente MySQL
mysql_get_host_info Obtener información de la máquina anfitriona MySQL
mysql_get_proto_info Obtener información del protocolo MySQL
mysql_get_server_info Obtener información del servidor MySQL
mysql_info Obtiene información sobre la consulta más reciente
mysql_insert_id Devuelve el identificador generado en la última llamada a INSERT
mysql_list_dbs Lista las bases de datos disponibles en el servidor MySQL
mysql_list_fields Lista los campos del resultado de MySQL
mysql_list_processes Lista los procesos MySQL
mysql_list_tables Lista las tablas en una base de datos MySQL
mysql_num_fields Devuelve el número de campos de un resultado
mysql_num_rows Devuelve el número de filas de un resultado
mysql_pconnect Abre una conexión persistente al servidor MySQL
mysql_ping Efectuar un chequeo de respuesta (ping) sobre una conexión de servidor o reconectarse si no
hay conexión
mysql_query Envía una sentencia SQL a MySQL
mysql_real_escape_string Cadena de escape para reales para su uso en una sentencia SQL, tomando en
cuenta el juego de caracteres actual de la conexión.
mysql_result Devuelve los datos de un resultado
mysql_select_db Selecciona un base de datos MySQL
mysql_stat Obtiene el status actual del sistema
mysql_tablename Devuelve el nombre de la tabla de un campo
mysql_thread_id Devuelve el ID del hilo actual
mysql_unbuffered_query Envía una consulta SQL a MySQL, sin recuperar ni colocar en un búfer las filas de resultado

En general estás funciones permiten realizar desde PHP diferentes tareas sobre una BD de MySQL usan-
do como server a Apache. En la Sección LXIII intitulada: Funciones de MySQL en el manual de PHP,
parte V [27] hay ligas a cada función donde se explica de manera pormenorizada cada una y se exponen
ejemplos de código en PHP para cada caso.

Una virtud que tiene PHP es que si el código del CGI referido en el atributo METHOD de la forma en la
GUI se encapsula en un archivo independiente (normalmente con extensión php) no es visible para el
usuario. Esto permite esconder la manera en que operan los métodos implementados, lo cual imprime un
nivel de seguridad a las aplicaciones.

En el capítulo 17 del mismo manual se explica el manejo de las cookies, que como se comentó antes sir-
ven para dejar rastros en el lado del cliente de las acciones realizadas en el pasado por él. Lo cual introduce
un modelo de memoria referencial para que las aplicaciones CS desarrolladas respondan a las trazas guar-
dadas en las máquinas cliente por cada usuario. Este modelo permite crear aplicaciones reactivas naturales
en caso necesario.

48
 B D / C S : : 2 0 0 4 : : M M

Y como referencias al lenguaje existe documentación que incluye la manera de crear y manejar PHP para
ofrecer soluciones de manejo de BD sobre MySQL [28, 29, 30].

3.5. Consideraciones para el desarrollo de aplicaciones CS

Debe ahora quedar claro que el modelo de aplicación sobre la Web define desde el inicio el servidor que se
utilizará como suministrador de servicio, esto está implícito en el URL que elige el usuario al solicitar una
página definida.

La aplicación que atiende al usuario estará contenida en el código de la página de Web demandada, es decir
está incrustado en ella. Por tanto la conexión refleja la intención del usuario conteniendo el dúo: servidor -
aplicación. Esto debe reflejar que el usuario es conciente de lo que está haciendo y no es una casualidad que
ingrese a ese servidor solicitando cierta página.

Solicita Página Procesa los 3

1 datos y emite
Activa
respuesta
Usuario
5
Página 4

Recibe Respuesta DBMS

Navegador de Web: Cliente

Servidor de Web

Fig. 3.1. Interacciones entre el cliente y servidor.

Como puede concluirse se trata de un sistema de tres capas, ya que en el proceso intervienen tres niveles:

1. Del lado del cliente está Browser.

2. Del lado del servidor la petición la atiende el Servidor de Web, que envía la petición al DBMS.
3. Si el DBMS puede resolver la solicitud, el Servidor de Web responde de manera estructurada con
los datos recibidos del DBMS al cliente.
Este es un modelo que esconde las bases de datos y procesos internos al cliente, el cual solo sabe que hace
una petición y recibe una respuesta a ella.

En general en el lado del cliente se pueden realizar procesos ligeros de verificación, los cuales pueden alige-
rar la carga del servidor. Para esto se pueden usar alguna clase de páginas activas locales. Y del lado del
servidor además del servidor de Web y el DBMS pueden actuar otras aplicaciones en la solución del pro-
blema, entre otras podemos apoyarnos de manera natural en las funciones que ofrece el SO, rutinas de
validación, manejo de archivos locales fuera de la BD y otros elementos que ayuden al servidor a brindar
una mejor atención.

49
 B D / C S : : 2 0 0 4 : : M M

3.5.1. Tipos de acceso

Un elemento básico en el proceso es determinar el tipo de acceso al sistema o partes de él, se pueden dis-
tinguir al menos dos esquemas:

1. Acceso libre. Cualquier usuario que conozca la dirección del servidor y una página activa puede
ingresar al sistema, donde las tareas que puede hacer las determina el sistema mismo. Esta clase de
esquema normalmente corresponde a la realización de solo consultas.

2. Acceso Restringido. Un usuario puede conocer el sitio y la página activa, pero requiere de una
autentificación para ingresar al uso del sistema. Normalmente para lograr esto se le debe asignar a
los usuarios permisos de acceso mediante un esquema de identificación, el más simple consiste en
asignarle a cada usuario reconocido un nombre (login) y clave de acceso (password). Esta informa-
ción se almacena en el lado del servidor en una BD de usuarios registrados y cada vez que el usua-
rio requiere acceder a alguna aplicación debe dar sus datos, luego el servidor lo valida y de ser co-
rrecta la información dada por el usuario se le da permiso de realizar las tareas que su rango le con-
fieren. Esto quiere decir que en general los permisos de cada usuario pueden ser diferentes y de-
pendiendo de su clase se le habilitará a realizar una u otra tarea.

Cada vez que uno hace una aplicación CS debe definir el tipo de usuarios que la explotarán y crear una
tabla con al menos cuatro elementos:

Campo Tipo
login cadena
passwd cadena encriptada
tipo_usuario clave_interna
estado (activo, inactivo)

Dependiendo del tipo_usuario el sistema o sistemas definirán a que tiene acceso el usuario que ha dado el
par: login – password correctos. El campo de estado se utiliza para inhabilitar a un usuario por periodos
y controlar su acceso según se requerido sin borrarlo de la tabla. Este mecanismo permite por ejemplo:
cerrar el sistema a algunos usuarios temporalmente mientras se realizan tareas de mantenimiento o modifi-
cación y luego abrirlo cuando éstas se han finalizado, o bien deshabilitar a usuarios por razones administra-
tivas y de seguridad.

Este modelo facilita que se organicen los usuarios en clases y según sea su tipo sean tratados de la misma
manera por parte de la aplicación como usuarios genéricos, lo cual simplifica el diseño y mantenimiento de
la aplicación

Otra forma de controlar el acceso es mediante la asignación de permisos a nivel del DBMS, esto involucra
que a cada usuario se le deben dar permisos específicos para cada recurso del sistema. Normalmente esto
se hace mediante scripts que administran los permisos para cada usuario y cada recurso que maneja el
DBMS.

A nivel de programación de las aplicaciones frontales bajo HTML se puede utilizar un campo <input> de
tipo hidden que plasme en la página que contiene la aplicación información que permita dar seguimiento al
usuario. Algunos elementos comunes de éste método es incluir cadenas encriptadas con información del

50
 B D / C S : : 2 0 0 4 : : M M

usuario y tiempo de expiración de las páginas para evitar que las páginas que se dejen abiertas por descuido
sean utilizadas de manera indebida. Al recibirse la siguiente petición mediante las funciones de desencrip-
tado y fecha-hora se valida la información oculta y se toman las decisiones convenientes. A éste modelo se
le llama modelo de boletos y permite darle un boleto a la terna usuario – origen – hora, de tal manera que si
se salva la página y se trata de ejecutar en otra máquina o por otro usuario o en un momento posterior al
válido se pueda detectar la suplantación y pedir en consecuencia que el ejecutante se vuelva a validar, lo
cual permite rechazar solicitudes espurias. Se puede proponer como mecanismo organizar la información
de la terna de validación en una cadena, encriptarla e incluirla en las páginas subsiguientes que son enviadas
al usuario en el proceso de operación de la aplicación. Este modelo puede presentar el inconveniente de
presentar vacíos en el caso que el usuario elija una secuencia de navegación ajena a la lógica de la aplica-
ción, en estos casos se requerirá volver a pedir que el usuario se autentique y volver a incrustar la informa-
ción de control en las páginas de respuesta. Para la implantación de estos métodos PHP ofrece funciones
de criptografía directa e inversa.

3.5.2. Manejo del origen de los accesos

Otra situación que se debe contemplar es la limitación de los accesos en función del sitio desde donde se
conectan los usuarios. Es común pedir restricciones de acceso – incluso al libre – por dominios de Inter-
net. Por ejemplo, una institución puede requerir que todos los empleados que laboran en ella puedan acce-
der a ciertos sistemas sin necesidad de autentificación, simplemente si lo hacen desde una máquina ubicada
en algún(os) dominio(s) específico(s), esto se puede resolver construyendo una tabla dentro del sistema de
base de datos o mediante archivos de configuración de las aplicaciones mismas que definan como serán los
accesos en función de la máquina que los solicita y no solo se tome la decisión validando al usuario. Este
modelo ayuda a evitar que se realicen accesos indebidos desde ciertas máquinas o dominios específicos,
restringir el acceso a ciertas aplicaciones a máquinas dentro de la institución y abrir el acceso a otras aplica-
ciones para equipos fuera de la institución.

Acceso libre

INSTITUCION
APLICACIONES
Acceso libre

Acceso restringido
Equipo de Red

Acceso restringido

Concha de la institución

Fig. 3.2. Esquema de acceso libre y restringido, interno y externo

Este esquema construye un cascarón que protege la información de la institución de intrusiones externas e
internas, dándole seguridad a los sistemas y a los datos. Para que el modelo funcione se deben definir polí-
ticas mixtas preferentemente, es decir además que la aplicaciones las traten de resolver de forma autónoma
incluir algunas de forma complementaria en los equipo de entrega y distribución de datos sobre la red
(switches y routers).

51
 B D / C S : : 2 0 0 4 : : M M

Este modelo jerárquico ayuda a delimitar las funciones de cada usuario y equipo en el mar de sistemas que
pueden existir dentro de una institución. Los sistemas pueden ubicarse en una o varias máquinas que ope-
ren como servidores dentro de la institución y cada una puede colaborar con otras para la solución de los
problemas.

3.5.3. Disponibilidad
En un ambiente tradicional que se pretenda sea tolerante a fallas, al menos deberán estar presentes los
servidores de respaldo, que deben entrar a operar si los servidores primarios llegasen a fallar o entrar en
fase de servicio. Se pueden escribir aplicaciones que mantengan estos sitios de respaldo actualizados o
aprovechar herramientas de respaldo automático ya construidas.

Para verificar si un sistema está activo se pueden escribir pequeñas aplicaciones que verifique su estado de
manera periódica y en caso de determinarse que algún servidor ha dejado de funcionar o no hay enlace a él
sobre la red – falla en el sistema de comunicaciones – mediante un sistema de suplantación o un portal de
acceso reconfigurable se levanta el servidor auxiliar y restablece el servicio mientras se resuelve el problema
con el servidor primario. A estos sistemas se les conoce como de alta disponibilidad.

Otro caso que debemos comentar es el de sistemas auxiliares de apoyo cuando se presenta saturación de
algún servidor por exceso de carga por los usuarios o los procesos internos. Para restaurar el rendimiento
de los sistemas se puede utilizar un ‘cluster’ funcionando con un SO que realice el balance de carga y que
vaya activando nuevos nodos en función de la demanda, haciendo una reubicación de procesos de manera
automática entre sus nodos. Y al momento de reducirse la carga volver a hacer un reacomodo y liberar
nodos ociosos. Para una implantación de ésta clase existen SO’s creados ex profeso, a estos se les llama
sistemas operativos distribuidos. Estos sistemas incluyen mecanismos de balance y migración de procesos.
Una manera de medir la carga del sistema o sistemas es mediante una estadística de tiempo de respuesta a
los clientes locales y remotos, así mediante la definición de reglas para los tiempos de atención máximos y
medios se activan los servidores o nodos auxiliares en función de la arquitectura y SO disponibles.

3.5.4. Colaboración y apoyo

Las aplicaciones de BD bajo PHP/MySQL son por naturaleza colaborativas ya que es posible que un
script en PHP haga una petición a una BD ubicada en un servidor (físicamente) diferente a aquel donde se
ha recibido la petición por parte del Servidor de Web. Esto se refleja en el hecho de cómo se realiza la
conexión a la BD de MySQL, analicemos la sintaxis del método de conexión de PHP:

int mysql_connect([string host [: int puerto] [, string usr [, string passwd] ] ])

el primer parámetro host es una cadena que indica la dirección del servidor, la cual en general puede ser
remota o local.

Por lo tanto una aplicación que se ejecuta en un nodo puede conectarse a otro nodo donde se encuentra
una instancia de MySQL ejecutiva. Al abrirse la conexión el manejador que devuelve el método
mysql_connect, contiene la información necesaria para interactuar en ese nodo y el MySQL que atiende
remotamente.

En caso de omitirse los parámetros del método se tomarán los parámetros por defecto que corresponden
a: host ='localhost', usr = el propietario del proceso del servidor y password vacío.

52
 B D / C S : : 2 0 0 4 : : M M

Algunos modelos de sistemas piden que se ejecute más de una instancia de MySQL en cierto nodo, esto se
puede hacer cambiando el puerto donde el DBMS escucha. No en todos los sistemas operativos es posi-
ble hacer esto se debe consultar el manual para determinar la viabilidad y configuración. El rendimiento de
las aplicaciones puede mejorar o verse afectado dependiendo de los recursos físicos disponibles y la admi-
nistración de los mismos por parte del SO.

El modelo de conexión persistente modelado por la función mysql_pconnect(), también puede ser utilizado,
las diferencias que tiene respecto a la conexión simple son:

1. Durante la conexión, la función intenta primero encontrar un enlace persistente abierto con el
mismo host, usuario y password. Si lo encuentra, devuelve el identificador de enlace en lugar de
abrir otra conexión.
2. La conexión no será cerrada cuando acabe la ejecución del script. El enlace permanecerá abierto
para ser usado en el futuro (mysql_close() no cierra el enlace establecido con mysql_pconnect()).
Los parámetros del método de conexión persistente son los mismos de los del método de conexión sim-
ple.
3.6. Consideraciones finales
Para terminar este tema debemos mencionar que los procesos que se pueden ejecutar de manera local se
podrán realizar de manera remota, lo que se requiere para el éxito de las aplicaciones es que la configura-
ción de cada elemento debe ser correcta y los servicios de red deben ser estables, accesibles y de alta dispo-
nibilidad.

Los factores anteriores definirán la respuesta y eficiencia de una aplicación CS. Pero también el diseño, la
programación del sistema, el diseño de la estructura de la Base o Bases de Datos, la manera en que se dis-
tribuyan los fragmentos de la información y el tráfico entre las aplicaciones son factores determinantes en
el rendimiento, seguridad y robustez de las aplicaciones.

Los respaldos de las aplicaciones y las bases de datos se deben hacer de manera periódica. Deben crearse,
además de la documentación de los sistemas y las BD’s, reglas y procedimientos para la migración, trans-
porte y respaldo de las aplicaciones/BD’s, ya que las aplicaciones clientes servidor montadas sobre siste-
mas de cómputo híbridos y homogéneos los problemas de integración pueden ser complejos y sin manua-
les de operación claros se pueden generar problemas de otra índole e impropios a las aplicaciones mismas.

La organización de los Administradores debe revisarse e incrementarse mediante la definición del alcance
de las responsabilidades de cada uno. Normalmente para sistemas complejos se deben diferenciar los ad-
ministradores de la red de los de las BD’s y los de las aplicaciones. Esto permite fincar responsabilidades
específicas y formar expertos en cada tipo de problema.

53
 B D / C S : : 2 0 0 4 : : M M

Bibliografía

[1] Dittrich, Object Oriented Data Model Concepts, Proceedings of the NATO – Advanced Study In-
stitute on OODBS, Springer – Verlag, 1994.
[2] Date, Introducción a los Sistemas de Bases de Datos, Prentice hall, 7ª. Ed. ,2001.
[3] Peralta Verónica, Taller de Sistemas de Información, http://proa.ei.uvigo.es/.
[4] Tanenbaum Andrew, Redes de Computadoras, 3ª Ed. , Prentice Hall, 1997.
[5] Consorcio World Wide Web (W3C), http://www.w3c.org/
[6] Grupo de Trabajo de Ingeniería de Internet (IEFT), http://www.ieft.org/
[7] HTML 4.0 Especification, W3C, http:/www.w3c.org/
[8] Soria, Ramón. Diseño y creación de páginas Web, HTML 4. Alfaomega –Rama, 1999.
[9] Martín, Manuel. Tutorial de HTML. FCC – BUAP, http://www.cs.buap.mx/~mmartin, 2000.
[10] Gundavaram Shishir. CGI Programming on the WWW. O’Reilly, 1996.
[11] Cortés C., Meléndez J. y Tobar M. Interfaz CGI para Servidores Web y Sistemas de Administración
de Bases de Datos, Tesis de la Universidad Centroamericana José Simeón Cañas, El Salvador,
1997
[12] Sitio oficial de Sun Microsystems, http//www.sunsite.com
[13] Aramburu y García. Curso de diseño de Bases de Datos. Universitat Jaime I, Departamento de In-
geniería y Ciencia de los Computadores. http://www3.uji.es /~aramburu
[14] Sitio oficial de Perl. http://www.perl.com
[15] Roth Dave. Sitio para el Manejo de Perl sobre Windows. http://www.roth.net/ODBC
[16] Larry Wall and Randal L. Schwartz, Programming Perl, O'Reilly & Associates, Inc. 1991
[17] Comprehensive Perl Archive Network, http://www.cpan.org
[18] Gunnerson Eric, A programme’rs introduction to C#. Apress, 2000.
[19] Sitio Oficial de PHP. http://www.php.net
[20] Museo de PHP, http://museum.php.net

54
 B D / C S : : 2 0 0 4 : : M M

[21] Tendencia de PHP, http://www.zend.com/zend/future.php

[22] Grupo de Documentación de PHP, Manual de PHP, http://www.php.net , 2003
[23] Proyecto GTK-PHP. http://gtk.php.net
[24] Sitio Oficial de MySQL. http://www.mysql.com/, http://www.mysql.com/documentation
[25] Maslakowski, Butcher. Aprendiendo MySQL en 21 días. SAMS - Prentice Hall, 2001.
[26] Apache Server Survival Guide. Ubicada en el CD adjunto.
[27] Bakken, Aulbach, Schmid, Winstead, Torben Wilson, Lerdorf, Zmievski, Ahto. Manual Oficial de
PHP 4. Editado por Rafael Martínez, Angela Pardo, Federico Finos, Pablo Daniel Rigazzi, Robert
Sánchez y Leonardo Boshell. http://www.opencontent.org/openpub/ , 2003.
[28] Meloni, PHP Fase & Easy web development, 2ª Edición, Premier Press, 2002.
[29] Gutiérrez y Bravo. PHP 4 a través de ejemplos. Alfaomega – Rama, 2004.
[30] Pineda, Ivo H. Aplicaciones de Bases de Datos Locales. FCC – BUAP, 2004.

55