Download universidad inca garcilaso de la vega

UNIVERSIDAD INCA GARCILASO DE LA VEGA
FACULTAD DE INGENIERIA ADMINISTRATIVA
ESCUELA PROFESIONAL DE INGENIERIA
ADMINISTRATIVA
“NUEVOS TIEMPOS NUEVAS IDEAS”
Presentado por:
ERICK MAYHUAY VALENTIN
LIMA – PERÚ
2006
Presentación
Una vez demostrado que como servidor de ficheros Linux no tiene rival, y que como
servidor de InterNet no tiene nada que envidiar a los grandes sistemas, hoy vamos a
tratar un otro apartado en el que linux se desenvuelve sin problemas: el de los servidores
de bases de datos para redes de PC's
Introducción
Los usuarios de MS-Windows en entornos ofimáticos se encuentran con frecuencia con
el problema del acceso remoto a bases de datos. Efectivamente MS-Dos y Windows
nunca fueron pensados como sistemas de red. Incluso, cuando no hubo mas remedio, las
soluciones no dejaron de ser sino un parche... Del mismo modo las bases de datos eran
locales, con soluciones propietarias.
Por otro lado, los grandes sistemas llevan trabajando desde hace años con servidores de
bases de datos. Accesos concurrentes, transacciones, bloqueos, rollback, etc, son
procesos largamente conocidos y estudiados. El acceso de la informatica personal a las
redes locales trajo al mundo ofimático los mismos problemas a los que los grandes
mainframes se habían enfrentado hacia años. Solo había un problema: El sistema
operativo. En efecto: todas las aplicaciones desarrolladas partíian de la base de un
sistema operativo monotarea monousuario, sin servicios de red, y casi sin ningún tipo de
control de acceso a los recursos. Incluso en la actualidad, Windows 95 tiene problemas
con el accesso a recursos entre aplicaciones ( o si no, probad a abrir un documento con
Word97 y -sin cerrar el documento- abriendo una ventana de MS-Dos intentad hacer
alguna operación con dicho documento. !!Haced primero un backup!! )
Los primeros intentos de acceso concurrente a bases de datos desde PC's se realizan
mediante recursos de compartición de archivos. Se utilizan los controles de acceso de
NetBIOS para salvaguardar la consistencia de datos... falta todavía un paso: el convertir
los programas de gestión de bases de datos a una arquitectura cliente-servidor, donde un
proceso maestro es el que controla cada petición de acceso a la base de datos, y nuestro
dBase, Paradox o Access no son sino user-interfaces de visualizacion de datos.
Tenemos pues diferentes enfoques, en función de la separación entre la aplicación y los
ficheros de datos y de la relación que se establece entre ellos:



Cliente y servidor son la misma aplicación, siendo los datos referidos a un
fichero con formato propietario, y usado éste en monousuario. Ejemplo: un
usuario que crea y maneja un fichero de dBase
Cliente y servidor son la misma aplicación, pero los datos son compartidos a
través del sistema de ficheros. Ejemplo: una red de usuarios de dbase que
acceden via NetBIOS a mismo fichero de datos
El Cliente constituye un user interface, pero los datos provienen de una database
"genérica", residente en la misma maquina, y que son accedidos a traves de un
driver que convierte los datos de la database en algo que el cliente entiende: por

ejemplo, cuando desde Access, vinculamos una base de datos con otra escrita,
por ejemplo en dBase
Cuando el vínculo no se realiza no a traves del sistema de ficheros sino con un
servidor remoto, via red local, tenemos un sistema servidor de bases de datos.
¿Cómo se establecen estos vínculos? En los grandes sistemas, y en las redes UNIX,
desde el primer momento los clientes son aplicaciones independientes del servidor,
hablan su lenguaje y se entienden de tú a tú con él. En sistemas basados en MS-Dos ( ej.
Windows ) se hace necesario el proveer un interfaz entre la aplicación y los servidores.
Del mismo modo, en los sistemas UNIX todo el mundo habla el mismo lenguaje de
bases de datos -SQL-, mientras que los PC's están plagados de soluciones propietarias,
en función de la aplicación y del fabricante. Se hace pues necesaria una arquitectura en
capas para realizar las siguientes tareas:




Una capa para que la aplicación sea capaz de hablar con el Sistema Operativo a
través de un API común
Una capa en el Sistema Operativo que se encarga de discernir el tipo de acceso a sistema de ficheros, a databases de otro proveedor, a un servidor remoto...- y
de invocar al driver adecuado
Un driver que se encarga del acceso a los datos, y de su conversión al API
común del sistema operativo
Si el acceso se efectúa vía red local hacia un servidor remoto, todavía hace falta
una capa nueva en el lado del servidor: la que convierte las peticiones del cliente
al API de programación que este provee.
Para conseguir esta funcionalidad Microsoft definió en su día un API denominado
Open DataBase Conectivity ( ODBC ). Toda aplicación de bases de datos que se
precie para el mundo Windows debe ser capaz de implementar y manejar el API de
acceso a la base de datos
Microsoft ha hecho público el API de programación por lo que -en teoría- cualquiera
puede escribir un driver ODBC, las aplicaciones de databases que hablen ODBC puedan
comunicarse con un servidor, bien sea local, remoto, fichero, aplicación o incluso otro
programa de bases de datos que se esté ejecutando en la misma máquina ( esta es la
teoría. Microsoft, siguiendo su política habitual, tiene la mala costumbre de saltarse sus
propios estándares, y algunas aplicaciones suyas manejan extensiones al ODBC propias
y no documentadas... )
Rizando el rizo, y puesto que ODBC es un estandard "de facto", el cliente de la base de
datos no tiene siquiera por que ser un sistema de Microsoft. De hecho, existe un
proyecto de colaboración en la comunidad InterNet para proveer a los sistemas UNIX
de un API de acceso ODBC unificado para sus bases de datos. Uno podría preguntarse
cúal es el sentido de todo esto, pues SQL tiene ya un API definido, y todos los UNIX
saben hablar en SQL, pero se entiende fácilmente si pensamos que si el API de acceso a
la base de datos es el mismo en Windows y en UNIX, el trabajo de porting se reduce
considerablemente. Es mucho mas fácil convencer a los desarrolladores de bases de
datos en Windows para que porten a Linux sus aplicaciones si se les proporciona el
mismo API de programación, de manera que solo tengan que teclear "make"
ODBC no es sino un API de
conectividad entre aplicaciones
de bases de datos cliente y
servidor. Dicho API esta
organizado en varias capas: de
aplicacion, de sistema, y de
acceso.
En resumen: ODBC no es sino un API de conectividad entre aplicaciones de bases de
datos cliente y servidor. Dicho API esta organizado en varias capas: de aplicacion, de
sistema, y de acceso.
Hemos dividido este tema en dos partes:


En este artículo, hacemos una pequeña introduccóon al API ODBC, y
emprendemos la instalación de una de las bases de datos mas conocidas en el
mundo Linux: PostGreSQL, asi como de las bibliotecas y drivers de ODBC
para UNIX.
En el próximo número de LINUX ACTUAL, haremos una descripción mas
detallada del API de ODBC, incluyendo ejemplos que podemos compilar y
ejecutar desde Linux, y emprenderemos la tarea de utilizar una base de datos
remota desde sistemas MS-Windows conectados en red con nuestro servidor. En
breve, nuestro jefe ya no tendrá más excusas para mantener un servidor NT en la
oficina... ;-)
Todos los ejemplos, gráficos y listados de estos artículos han sido realizados con
PostGreSQL 6.3.2 en una Sparc-SLC con RedHat 4.2 SparcLinux y un Pentium
166MMX con Linux RedHat 5.0 , Windows 95 OSR2 y Office 97, conectados en red.
En el CD-Rom se incluyen los fuentes y paquetes instalables de las últimas releases
oficiales de los programas que aquí se explican, existentes en el momento de escribir el
articulo
Instalación de PostGreSQL-6.3.2 bajo Linux
En el número 2 de Linux Actual se describió la instalación de MySQL como servidor
de bases de datos. En este artículo se describe la instalación de PostGreSQL 6.3.2, con
lo que los lectores tendrán así ocasión de poder establecer criterios para seleccionar su
servidor favorito.
Si utilizamos una distribución tipo RedHat tendremos los siguientes paquetes:
postgresql-6.3.2-3.i386.rpm
Paquete básico
postgresql-devel-6.3.2-3.i386.rpm API de programación PostGreSQL
postgresql-clients-6.3.2Clientes bajo Linux
3.i386.rpm
postgresql-data-6.3.2-3.i386.rpm Templates para bases de datos
Interfaz con Java Database Conectivity
postgresql-jdbc-6.3.2-3.i386.rpm
(JDBC)
postgresql-perl-6.3.2-3.i386.rpm Interfaz con Perl
Para instalarlos, no tendremos más que montar el CDROM y ejecutar:
root@cochito:/mnt/cdrom# rpm -v -i ${path_to_rpms}/postgresql*i386.rpm
En el caso de que ya tengamos una versión pre-instalada, es recomendable hacer el
upgrade a ésta, por lo que deberemos añadir la opción --upgrade a la línea de comandos
En el caso de que no dispongamos de las utilidades de paquetería rpm, procederemos a
coger el paquete .tar.gz y compilarlo. Para ello procederemos de la siguiente forma:
1. Creamos un usuario "postgres" bajo cuyo uid se ejecutará todo el software de
gestión de la database. ! Bajo ningún concepto ejecutaremos nunca dicho
software con permisos de root !. Asimismo creamos el directorio de spool donde
se van a guardar las databases del sistema:
2.
3.
4.
5.
6.
7.
8.
9.
[root@sparky /root]# grep postgres /etc/passwd /etc/group
/etc/passwd:postgres:!:100:101:PostGreSQL
Server:/var/lib/pgsql:/bin/bash
/etc/group:postgres::101:
[root@sparky /root]# ls -la /var/lib/pgsql
total 3
drwxr-xr-x
2 postgres postgres
1024 May 23 20:40 .
drwxr-xr-x
8 root
root
1024 May 23 20:13 ..
-rw-r--r-1 postgres postgres
18 May 23 20:40
.bash_history
10. Como root descomprimimos el paquete en el directorio deseado. ( normalmente
/usr/local/src ).
11. En el caso de que ya tuviéramos una versión de PostGreSQL instalada
anteriormente, deberemos hacer un backup de las bases de datos existentes en el
sistema. Remitimos al lector a los ficheros "INSTALL" que acompañan al
paquete
12. Ejecutamos:
13. [root@sparky /usr/local/src/postgresql-6.3.2/src]# ./configure
14. [root@sparky /usr/local/src/postgresql-6.3.2/src]# make
15. Es posible que deseemos modificar alguno de los parámetros de compilacion El
comando "configure --help" y la documentación nos indican las diversas
opciones. Especial mención merecen las opciones "--template", "--php", y "-perl". Consultar el fichero INSTALL para escoger los parámetros adecuados.
16. El programa debería compilar sin problemas. Una vez finalizada la compilación
"make install" nos instalará PostGreSQL en los directorios escogidos.
En el caso de que no hayamos desactivado expresamente su generacisóon, se
habrá creado la librería libpq.so.x.x . Deberemos añadir en el fichero
/etc/ld.so.conf el path donde la hayamos instalado, y acto seguido ejecutaremos
ldconfig para actualizar el cache del cargador de librerías dinámicas
17. En los ficheros /etc/profile.d/postgresql.sh y /etc/profile.d/postgresql.csh
instalamos los paths y las variables de entorno apropiadas:
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
[root@sparky /root]# cat /etc/profile.d/postgresql.sh
PATH=$PATH:/usr/local/pgsql/bin
MANPATH=$MANPATH:/usr/local/pgsql/man
PGLIB=/usr/local/pgsql/lib
PGDATA=/var/lib/pgsql/data
export PATH MANPATH PGLIB PGDATA
[root@sparky /root]# cat /etc/profile.d/postgresql.csh
setenv PATH $PATH:/usr/local/pgsql/bin
setenv MANPATH $MANPATH:/usr/local/pgsql/man
setenv PGLIB /usr/local/pgsql/lib
setenv PGDATA /var/lib/pgsql/data
30. Creamos los "esqueletos" de la database. Para ello hacemos "su - postgres" y
ejecutamos "initdb"
31. configuramos adecuadamente los ficheros de control de PostGreSQL,
especialmente el fichero de control de accesos pg_hba.conf . De nuevo, nos
remitimos al manual..
32. El manual recomienda, antes de empezar a trabajar, ejecutar los programas de
testing. Para ello deberemos arrancar el servidor en modo test, y ejecutar make
en el directorio de testing. ( Leer fichero INSTALL )
33. Finalmente, creamos el fichero /etc/rc.d/init.d/postgresql y configuramos con el
"runlevel editor" el arranque en power-on del servidor de la base de datos. El
listado 1 nos muestra un ejemplo de script de arranque para RedHat-5.0:
#! /bin/sh
# chkconfig: 345 85 15
# description: Starts and stops the PostgreSQL
#
backend daemon that handles
#
all database requests.
# Source function library.
. /etc/rc.d/init.d/functions
# Get config.
. /etc/sysconfig/network
# Check that networking is up.
# Pretty much need it for postmaster.
[ ${NETWORKING} = "no" ] && exit 0
[ -f /usr/bin/postmaster ] || exit 0
# See how we were called.
case "$1" in
start)
echo -n "Starting postgresql service: "
su postgres -c \
'/usr/bin/postmaster -S -i -D/var/lib/pgsql'
sleep 1
pid=`pidof postmaster`
echo -n "postmaster [$pid]"
touch /var/lock/subsys/postmaster
echo
;;
stop)
echo -n "Stopping postgresql service: "
killproc postmaster
sleep 2
rm -f /var/lock/subsys/postmaster
echo
;;
status)
status postmaster
;;
restart)
$0 stop
$0 start
;;
*)
echo "Usage: postgres.init {start|stop|status|restart}"
exit 1
esac
exit 0
Listado 1: fichero de arranque en power-on de PostGreSQL
34. Arrancamos el sistema con "/etc/rc.d/init.d/postgresql start"
35. Como usuario "postgres" vamos a crear una cuenta de acceso para i poder
trabajar con el servidor de base de datos. Estas cuentas son exclusivas de la base
de datos, y no hacen referencia a usuarios reales del sistema, aunque es bastante
común tener una cuenta generica "sqluser" sin login, para uso exclusivo de
PostGreSQL. Esto lo haremos con el comando
36. [postgres@sparky:/var/lib/pgsql]$ createuser sqluser
El programa createuser nos irá preguntando por los diversos privilegios de dicho
usuario, su uid ( que -de nuevo-, no tiene por qué coincidir con el de un usuario
real, aunque así sea en nuestro ejemplo ). Los diversos ficheros de
configuración, indicarán qué usuarios tienen permiso para hacer qué cosas. De
nuevo, para una descripción detallada, nos remitimos al manual
En el caso de que nuestra base de datos vaya a ser utilizada desde el servidor de
Web, mediante PHP, deberemos añadir un nuevo usuario "nobody", con el
mismo userid y groupid que el usuario real. Recordemos que el servidor Apache
se ejecuta como dicho usuario
37. Si estabamos realizando un upgrade, éste es el momento de hacer un restore de
las diversas databases que tuviéramos procedentes de una release anterior
38. Creamos una base de datos para "jugar". El sistema trae ya una database
generica "template1" pero ya se sabe que Murphy anda suelto, y no esta de más
un poco de precaución. La denominaremos "odbctest"
39. [postgres@sparky:/var/lib/pgsql]$ createdb odbctest
El Concepto de base de
datos relacional va más alla
de la simple tabla: una RDB
engloba tablas, indices,
operadores, funciones, etc,
bajo un nombre común,
definiendo las
interrelaciones entre los
diversos elementos de dicha
base de datos
40. El concepto de base de datos en PostGreSQL, y en general en todas las bases de
datos relacionales es mucho mas amplio que el tradicional de conjunto de
registros, cada uno con "n" campos de diversos tipos. Aquí por database se
entiende una agrupación de objetos, tales como tablas, indices, funciones
operadores, etc, bajo un nombre común
Ahora, dentro de la database "odbctest" vamos a crear una tabla con la que
trabajar. Por el momento vamos a obviar la sintaxis SQL, dejandola para un
articulo posterior, y vamos a introducir ciegamente los datos. Al final del
articulo se indican referencias sobre manuales de SQL, ( si los lectores lo
estiman oportuno, incluiremos en Linux Actual una serie sobre dicho lenguaje
). Simplemente indicar que PostGreSQL se acompaña de un interfaz de entrada
directa de comandos SQL, denominado psql, que utilizaremos para introducir
los datos en la database. El listado 2 muestra los datos que introduciremos en la
database:
create table telefonos (
nombre char(25),
direccion char(40),
telefono int
);
insert into telefonos
values ( 'E.T.S.I.Teleco','C. Universitaria s/n',5495700 );
insert into telefonos
values ( 'Linux Actual','Alfonso Gomez 42',3040622 );
insert into telefonos
values ( 'Juan Antonio','Mi Casa',12345678 );
insert into telefonos
values ( 'Emergencias','Comunidad de Madrid',112 );
Listado 2: programa de ejemplo de creacion de base de datos
41. Para aquellos que no quieran introducir a mano los comandos, se incluye dicho
listado en el CDROM, de manera, que en lugar de teclearlo, se puede cargar
directamente desde psql con la secuencia de escape \i (include file)
42. [postgres@sparky:/var/lib/pgsql]$ psql odbctest
43. Welcome to the POSTGRESQL interactive sql monitor:
44.
Please read the file COPYRIGHT for copyright terms of
POSTGRESQL
45.
46.
type \? for help on slash commands
47.
type \q to quit
48.
type \g or terminate with semicolon to execute query
49. You are currently connected to the database: odbctest
50.
51. odbctest=> \i
/path/to/cdrom/sample/sql/include/file/telefonos.sql
52. create table telefonos (
53.
nombre char(25),
54.
direccion char(40),
55.
telefono int
56. );
57. CREATE
58.
59. insert into telefonos
60.
values ( 'E.T.S.I.Teleco','C. Universitaria
s/n',5495700 );
61. INSERT 17584 1
62. insert into telefonos
63.
values ( 'Linux Actual','Alfonso Gomez 42',3040622 );
64. INSERT 17585 1
65. insert into telefonos
66.
values ( 'Juan Antonio','Mi Casa',12345678 );
67. INSERT 17586 1
68. insert into telefonos
69.
values ( 'Emergencias','Comunidad de Madrid',112 );
70. INSERT 17587 1
71.
72. EOF
73. odbctest=> select nombre,direccion from telefonos
74.
where telefono=5495700;
75. nombre
|direccion
76. -------------------------+--------------------------------------77. E.T.S.I.Teleco
|Ciudad Universitaria s/n
78. (1 row)
79. odbctest=> \q
80. [postgres@sparky:/var/lib/pgsql]$
81. Ya tenemos nuestro servidor de databases instalado y funcionando, y hemos
creado una pequeña base de datos para empezar a trabajar. A continuación se
describirá cómo instalar las librerías ODBC y el driver ODBC para
PostGreSQL en Linux, haciendo previamente una breve introducción al
funcionamiento del API ODBC.
Un primer paseo por el API de ODBC
Antes de emprender la instalación de ODBC es preciso aclarar algunos conceptos de
funcionamiento del API de ODBC.
Como hemos explicado en la introdución, ODBC es un API de interfaz entre clientes de
bases de datos y servidores de bases de datos. La figura 1 ilustra este esquema:
</TD<
tr>
figura 1: Estructura en capas del API ODBC
La primera capa constituye la librería del API que utilizan las diversas aplicaciones que
"hablan" ODBC. Microsoft proporciona para sus sistemas el fichero ODBC32.DLL, que
contienen el API y el interfaz con el sistema operativo, permitiendo a los
desarrolladores de controladores ODBC incluír dicha librería en sus distribuciones ( de
la misma manera que para la DLL de controles Visual Basic VBRUN.DLL ). Para
sistemas UNIX, el proyecto FreeODBC, ha desarrollado su propia librería GPL
libodbc.so.x.x que es totalmente compatible con las especificaciones descritas por
Microsoft
El administrador de orígenes de datos es el responsable del "rutado" de peticiones de
ODBC desde la librería hasta los controladores. Para ello se discriminan tres tipos de
orígenes de datos: de usuario, de archivo y de sistema. Esta nomenclatura es motivo
frecuente de confusión: cuando desde Windows se abre desde el panel de control el
menú de "controladores ODBC" se encuentra con esta clasificación, y cuando abre cada
una de las ventanas se encuentra con los mismos contenidos... Vamos a explicarlo un
poco:




Los orígenes de datos de usuario, realmente se refieren a las operaciones que
realiza el usuario con su base de datos desde la aplicación nativa para la que han
sido desarrollados, y sin realizar ningún tipo de compartición con otros usuarios.
En cristiano: cuando se trabaja con MS-Access, y no compartes la base de datos
( en UNIX y en Win-NT esta disgresión tiene sentido; en Win95 es cuando
menos discutible )
Cuando se comparte la base de datos mediante un servidor de ficheros
compartiendo físicamente los datos almacenados en un fichero determinado
hablamos de orígenes de datos de archivo. Este método permite, por ejemplo a
un usuario de dBase manejar una database de MS-Access, o bien que varios
usuarios puedan compartir una misma database
Cuando no se comparte un fichero, sino que se trabaja con la database a través
de un sistema cliente-servidor, hablamos de un origen de datos de sistema.
Las aplicaciones ofimáticas mas comunes, ofrecen drivers para orígenes de datos
de usuario y de archivo, para permitir a los usuarios el poder trabajar, importar y
exportar datos entre diversas aplicaciones de gestión. Las aplicaciones de
servidores de bases de datos, por contra, proporcionan drivers para orígenes de
datos de sistema
PostODBC y los drivers de PostGreSQL para iODBC pertenecen a esta última
categoría
Por último, cada origen de datos tiene asociado un controlador, que actúa de "pasarela"
entre el API y el acceso físico a los datos
El API de ODBC en Linux
Llegados a este punto preguntamos: ¿Cómo funciona de cara al programador la librería
ODBC?. La respuesta es ridículamente sencilla: el API ODBC consiste en un interfaz
que implementa un método de pasar peticiones en lenguaje SQL a través de una serie de
funciones. Con ODBC podemos:







Obtener un puntero de descripción del entorno de programacion ( algo parecido
al XOpenDisplay() de X-Windows )
Crear punteros de conexión, especificando origen de datos y controlador
Efectuar conexiones con la database (en nuestro lenguaje: abrir un socket)
Crear punteros de peticiones SQL ( básicamente, obtener estructuras de datos
que nos permitan insertar nuestras peticiones )
Ejecutar peticiones sobre la base de datos
Recoger resultados de nuestras peticiones
Liberar y cerrar todos los recursos previamente asignados
En la práctica, ni todas las aplicaciones, ni todos los controladores de orígenes de datos
son capaces de gestionar todas las funcionalidades previstas por el API. Por ello se
establecen los denominados "niveles de conformidad SQL" en la aplicación así como
"niveles de conformidad del controlador", que permiten al administrador de orígenes de
datos saber qué puede hacer tanto con el driver como con la aplicación.
Remitimos al lector a la literatura indicada en las referencias para buscar las
especificaciones y descripciones de cada nivel de compatibilidad
El proyecto FreeODBC ha
desarrollado una librería,
denominada iODBC, que
cumple con las especificaciones
del API ODBC 2.0 de
Microsoft, y que integra las
funciones de API y de
administrador de orígenes de
datos.
¿Cómo se aplica ésto en sistemas UNIX? El proyecto FreeODBC ha desarrollado una
librería, denominada iODBC, que cumple con las especificaciones del API ODBC 2.0
de Microsoft, y que integra las funciones de API y de administrador de orígenes de
datos. Cada servidor de bases de datos provee un driver que hace las funciones de
controlador de orígenes de datos y de origen de datos de sistema específico de cada
servidor de bases de datos.
Existe un fichero ${HOME}/.iodbc.ini, que indica a la librería libodbc.so.x.x, los
controladores de que dispone cada sistema, y cómo se accede a ellos. Todo el interfaz
esta implementado mediante librerías dinámicas. El resultado de todo esto, es que el
programador se encuentra con un API virtualmente idéntico al que se encontraría si
estuviera trabajando en una maquina M$-Windows
En el CD-Rom que se acompaña a esta revista, bajo el directorio odbc/iodbc
encontramos los siguientes ficheros:


iodbc-2.12.shar.Z Código fuente de la librería del API de ODBC para UNIX
proveniente del Proyecto FreeODBC
pgodbc-0.03.tgz Código fuente del driver UNIX para conectar el API iODBC
con el servidor PostGreSQL
Buceando por las paginas web, podremos encontrar drivers de iODBC para casi todas
las bases de datos disponibles en Linux. De hecho, Los desarrolladores de iODBC han
decidido incluír en sus nuevas releases todos los drivers de aquellas bases de datos que
libremente los provean, incluyendo además de serie la pasarela JDBC-ODBC.
Conclusión
En este primer artículo dedicado a la conectividad ODBC, se han introducido los
conceptos básicos de dicho sistema. Asimismo hemos aprendido a instalar y configurar
Uno de los servidores de bases de datos más conocidos: PostGreSQL, así como los
drivers y librerías ODBC para UNIX.
En el próximo número de Linux Actual, profundizaremos en el API de ODBC, dando
algunos ejemplos de programación, y se explicará la forma en que debemos instalar los
drivers ODBC para PostGreSQL en sistemas Microsoft Windows-3.XX y Windows95, con ejemplos de utilización desde MS-Access-97.
ODBC
ODBC son las siglas de Open DataBase Connectivity, que es un estándar de acceso a
Bases de Datos desarrollado por Microsoft Corporation, el objetivo de ODBC es hacer
posible el acceder a cualquier dato de cualquier aplicación, sin importar qué Sistema
Gestor de Bases de Datos (DBMS por sus siglas en inglés) almacene los datos, ODBC
logra esto al insertar una capa intermedia llamada manejador de Bases de Datos, entre la
aplicación y el DBMS, el propósito de esta capa es traducir las consultas de datos de la
aplicación en comandos que el DBMS entienda. Para que esto funcione tanto la
aplicación como el DBMS deben ser compatibles con ODBC, esto es que la aplicación
debe ser capaz de producir comandos ODBC y el DBMS debe ser capaz de responder a
ellos. desde la versión 2.0 el estandar soporta SAG y SQL.
Para conectarse a la Base de Datos se crea una DSN dentro del ODBC que define los
parámetros, ruta y características de la conexion según los datos que solicite el
fabricante.
JDBC es el acrónimo de Java Database Connectivity, un API que permite la ejecución
de operaciones sobre bases de datos desde el lenguaje de programación Java
independientemente del sistema de operación donde se ejecute o de la base de datos a la
cual se accede utilizando el dialecto SQL del modelo de base de datos que se utilice.
El API JDBC se presenta como una colección de interfaces Java y métodos de gestión
de manejadores de conexión hacia cada modelo específico de base de datos. Un
manejador de conexiones hacia un modelo de base de datos en particular es un conjunto
de clases que implementan interfaces Java y que utilizan los métodos de registro para
declarar los tipos de localizadores a base de datos (URL) que pueden manejar. Para
utilizar una base de datos particular, el usuario ejecuta su programa junto con la librería
de conexión apropiada al modelo de su base de datos, y accede a ella estableciendo una
conexión, para ello provee en localizador a la base de datos y los parámetros de
conexión específicos. A partir de allí puede realizar con cualquier tipo de tareas con la
base de datos a las que tenga permiso: consultas, actualizaciones, creado modificado y
borrado de tablas, ejecución de procedimientos almacenados en la base de datos, etc.
Qué es el ODBC?
Open Data Base Conectivity
O lo que es lo mismo, conectividad abierta de bases de datos. Si escribimos una
aplicación para acceder a las tablas de una DB de Access, ¿qué ocurrirá si después
queremos que la misma aplicación, y sin reescribir nada, utilice tablas de SQL Server u
otra DB cualquiera? La respuesta es sencilla: no funcionará. Nuestra aplicación,
diseñada para un motor concreto, no sabrá dialogar con el otro. Evidentemente, si todas
las DB funcionaran igual, no tendríamos este problema.... aunque eso no es probable
que ocurra nunca.
Pero si hubiera un elemento que por un lado sea siempre igual, y por el otro sea capaz
de dialogar con una DB concreta, solo tendríamos que ir cambiando este elemento, y
nuestra aplicación siempre funcionaría sin importar lo que hay al otro lado... algo así
como ir cambiando las boquillas de una manguera. A esas piezas intercambiables las
llamaremos orígenes de datos de ODBC
Casi todas las DB actuales tienen un ODBC. Debido a que este elemento impone ciertas
limitaciones, ya que no todo lo que la DB sabe hacer es compatible con la aplicación,
como velocidad de proceso, tiempos de espera, máxima longitud de registro, número
máximo de registros, versión de SQL, etc., está cayendo en desuso a cambio de otras
técnicas de programación, pero aún le quedan muchos años de buen servicio.
Todo lo referido aquí funciona con Windows NT Server 4.0 con el Service Pack 4 o
superior instalado (actualmente existe el 6). El Option Pack 4 para actualizar el IIS y las
extensiones ASP. SQL Server 6.5 y Access 97.
Esas otras técnicas de programación antes mencionadas, se utilizan ya en el nuevo
Windows 2000, Office 2000 y SQL Server 7.0, que además de ODBC pueden utilizar....
pero esa es otra historia.
Esta es la idea: por un lado el ODBC provee de unas caracteríisticas siempre
homogéneas, y por el otro permite distintos controladores que aseguran la conectividad
de la aplicación con diferentes bases de datos.
Ahora que ya sabemos qué es y para lo que sirve, procedamos a su instalación: es un
proceso sencillo, pero según la base de datos elegida sea Access 97 o SQL Server,
cambian un poco, y como no podía ser menos, hay algunos trucos que conviene
conocer.
Mario Martínez
odbc
Creación de orígenes de datos
300499. ODBC es un intermediario entre bases de datos y aplicaciones, cuya tarea es
sostener una conversación de preguntas y respuestas entre dos "sujetos" que no hablan
el mismo idioma y que gestionan sus recursos de forma diferente. Bueno, estoy
abstrayendo un tanto un concepto muy tecnificado, pero cuento con que habrá usuarios
finales leyendo esto, que no necesitan envolverse en la jerga de los programadores y sus
semejantes. Concretando, tu puedes tener un CAD, una hoja de calculo, un editor de
texto, etc..., cuyas finalidades son las que tu quieras menos gestionar datos en la forma
que lo hace un sistema de base de datos; estas aplicaciones no saben como se obtienen y
se guardan datos en, por ejemplo, un archivo MDB de Microsoft Access, o en un DBF,
o en SQL Server, o en algún otro. Por otra parte, pero en lo mismo, que tal si un usuario
de Paradox quiere extraer información de SQL Pato, un nuevo sistema de lo más
avanzado que nadie conoce pero que alguien uso para guardar información que resulta
necesaria (no sabes cuántas veces sucede), ambos son sistemas de bases de datos,
Paradox conoce la forma de leer los archivos de los sistemas conocidos, pero no los de
SQL Pato.
En el ambiente Windows, Microsoft creó la tecnología ODBC pensando en este
problema. No es una solución de la comunidad informática del orbe, es de Microsoft, y
por eso se basa en los impulsos estomacales del corazón de Microsoft; quiero decir que
no estoy recomendando esta tecnología, sino que digo que mientras sea en Windows,
hay que usarla cuando no hay algo mejor, punto. ODBC es un armatoste que alberga
controladores. El armatoste sirve para gestionar los controladores, y los controladores
son los que saben "hablar" con las bases de datos. Entonces el "acuerdo" entre Microsoft
y los fabricantes de software para Windows fue: "Ustedes, que hacen software no
especifico para bases de datos, enseñen, si quieren, a sus aplicaciones a comunicarse
con el armatoste llamado ODBC; y ustedes, fabricantes de bases de datos, hagan
controladores de sus sistemas para ponerlos en el armatoste, si quieren que otras
aplicaciones puedan accesar su información".
Listo, mas o menos. Es así que Excel puede leer una base de datos en Access o SQL
Server, incluso SQL Pato (si es que alguien fabricó un controlador de ODBC). Pero te
voy a ser sincero, esas no son todas las razones ni los intereses por los que ODBC fue
implementado, hay cierta oscuridad por ahí, por lo menos para los que no andan en el
negocio del desarrollo de software; el asunto es que para la finalidad de este articulo,
hasta ahí voy a dejar la narración de los antecedentes de ODBC y voy a pasar a lo
nuestro, ¿cómo se usa?.
En ODBC no se tiene que hacer gran cosa, es una simple tarea, se llama crear un origen
de datos, otros le denominan fuente en vez de origen, pero ya lo sabes ahora. Un origen
o fuente de datos consiste en el nombre, el controlador y la base de datos. Por ejemplo,
si un usuario quiere tener acceso a una base de datos de Access, digamos que se llama
Negocio.mdb, desde una hoja de cálculo de Excel para consultar su volumen de ventas
por país, este usuario crea un nuevo origen de datos en ODBC llamado
Volumen_Ventas (este es, pues, el nombre), después selecciona un controlador para
Microsoft Access e indica el archivo de base de datos está en
"c:\LaEmpresa\Administración\Negocio.mdb". Eso es básicamente de lo que se trata.
Ahora vamos a verlo gráficamente. Soy usuario de una aplicación que se llama
MicroStation Geographics que usa bases de datos externas para crear mapas, esta
aplicación trabaja directamente con Oracle, Informix, Dbase y algún otro, pero mi
intención es tener una conexión con una base de datos de Microsoft Access, porque es
fácil para hacer prototipos e incluso aplicaciones terminadas que no son muy grandes;
MicroStation Geographics no trabaja directamente con Access, pero puede entenderse
con él usando ODBC de por medio. Necesito crear un origen de datos en ODBC para
que MicroStation Geographics sepa a qué base de datos me refiero cuando le solicite
información.
Primero vamos a buscar a ODBC, que está en el Panel de Control.
Las aplicaciones creadas específicamente para Windows 95, 98 y NT usan el ODBC de
32 bits; pero algunos sistemas conservan un ODBC de 16 bits para las aplicaciones de
legado que corrían o corren en Windows 3.11.
Bueno, y ahora, ante ti, ¡el armatoste!. ¡El famoso Data Source Administrator del
Open DataBase Conectivity, u ODBC. Lo que sigue es crear una fuente u origen de
datos, pero antes unas explicaciones:
Vas a notar que las primeras tres solapas se refieren a User DSN, System DSN y File
DSN. Perdón, pero tengo la versión en inglés, voy a traducir un poco:
User DSN, nombre del origen de datos para el usuario. A veces, una máquina es
utilizada por más de un usuario (espero que a ti no te pase que compartes tu
computadora porque la empresa donde trabajas es tan espléndida que gratifica a sus
computadoras con más de un usuario), los orígenes de datos declarados aquí son
exclusivos del usuario.
System DSN, nombre del origen de datos para el sistema. Todos los usuarios de la
máquina tienen acceso a estos orígenes de datos.
User DSN, nombre del origen de datos en archivo. Se crea un archivo con la
extensión DSN, que sirve como origen de datos y puede ser distribuido a otros usuarios.
Este origen es el que usa Excel por omisión cuando hace consultas, cuidado con eso.
Está otra solapa importante que es ODBC Drivers u Controladores ODBC. Aquí se
ven todos los controladores disponibles en la máquina. De está forma puedes consultar
si dispones del controlador que necesitas y si es la versión conveniente. Regularmente
los controladores de bases de datos vienen con un programa SETUP que los instala y
quedan dados de alta en esta lista.
Las otras solapas merecen artículos aparte pues sirven más a los administradores y
desarrolladores de sistemas. Para el fin de crear un origen de datos, con lo que hemos
visto tenemos. Lo siguiente:
Seleccionar la solapa de DSN, nombre de origen de datos, que mejor se ajuste a mis
requerimientos. MicroStation Geographics no da muestras de trabajar con archivos
DSN, pero si con orígenes de usuario y de sistema, no seamos envidiosos así que,
seleccionamos la solapa System DSN, nombre de origen de datos del sistema y
presionamos el botón Add.., agregar..
Luego señalamos el controlador o driver del tipo de base de datos que queremos
accesar: Microsoft Access Driver (o controlador, en la versión en español) y
presionamos Finalizar; pero fíjate que todavía no acabamos, eso de Finalizar es algo
que.. ni hablar.
Lo que tenemos ahora bautizar al nuevo origen de datos con un nombre peculiar y
distintivo, como estamos creando un origen de datos para una base de datos que se
llama MyTown.mdb pues le llamo MiPueblo y le damos una descripción (que en
realidad no es necesaria).
Eso es todo, ahora solamente se debe cerrar el administrador de ODBC presionado el
botón Aceptar. Tenemos un origen de datos nuevo que le será útil a aplicaciones que de
otra forma no podrían leer una base de datos Access. Una recomendación, cuando
quieras un origen de datos ODBC para usarlo con Excel, créalo en la solapa de File
DSN o Archivo DSN. También puedes contar con que Excel tiene un asistente que te
ayuda a crear el origen de datos dentro de Excel (te requiere el programa Microsoft
Query instalado en tu máquina).
El controlador de ODBC de Microsoft Access se puede instalar, si es que no lo tienes,
desde el CD de Office o de Access sí lo tienes como versión independiente.
Para más información y recursos respecto a ODBC puedes visitar: