Download universidad inca garcilaso de la vega
Document related concepts
Transcript
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: