Procedimientos almacenados

Un procedimiento almacenado de SQL Server es un grupo de una o varias instrucciones Transact-SQL o una referencia a un método de Common Runtime Language (CLR) de Microsoft .NET Framework. Los procedimientos se asemejan a las construcciones de otros lenguajes de programación, porque pueden:

Aceptar parámetros de entrada y devolver varios valores en forma de parámetros de salida al programa que realiza la llamada.

Contener instrucciones de programación que realicen operaciones en la base de datos. Entre otras, pueden contener llamadas a otros procedimientos.

Devolver un valor de estado a un programa que realiza una llamada para indicar si la operación se ha realizado correctamente o se han producido errores, y el motivo de estos.

Ventajas de usar procedimientos almacenados En la siguiente lista se describen algunas de las ventajas que brinda el uso de procedimientos. Tráfico de red reducido entre el cliente y el servidor

Los comandos de un procedimiento se ejecutan en un único lote de código. Esto puede reducir significativamente el tráfico de red entre el servidor y el cliente porque únicamente se envía a través de la red la llamada que va a ejecutar el procedimiento. Sin la encapsulación de código que proporciona un procedimiento, cada una de las líneas de código tendría que enviarse a través de la red.

Mayor seguridad

Varios usuarios y programas cliente pueden realizar operaciones en los objetos de base de datos subyacentes a través de un procedimiento, aunque los usuarios y los programas no tengan permisos directos sobre esos objetos subyacentes. El procedimiento controla qué procesos y actividades se llevan a cabo y protege los objetos de base de datos subyacentes. Esto elimina la necesidad de conceder permisos en cada nivel de objetos y simplifica los niveles de seguridad. La cláusula EXECUTE AS puede especificarse en la instrucción CREATE PROCEDURE para habilitar la suplantación de otro usuario o para permitir que los usuarios o las aplicaciones puedan realizar ciertas actividades en la base de datos sin necesidad de contar con permisos directos sobre los objetos y comandos subyacentes. Por ejemplo, algunas acciones como TRUNCATE TABLE no tienen permisos que se puedan conceder. Para poder ejecutar TRUNCATE TABLE, el usuario debe tener permisos ALTER en la tabla especificada. Puede que la concesión de permisos ALTER a un usuario en una tabla no sea lo ideal, pues en realidad el usuario tendrá permisos muy superiores a la posibilidad de truncar una tabla. Si se incorpora la instrucción TRUNCATE TABLE en un módulo y se especifica la ejecución del módulo como un usuario con permisos para modificar la tabla,

se pueden ampliar los permisos para truncar la tabla al usuario al que se concedan permisos EXECUTE para el módulo. Al llamar a un procedimiento a través de la red, solo está visible la llamada que va a ejecutar el procedimiento. Por lo tanto, los usuarios malintencionados no pueden ver los nombres de los objetos de base de datos y tabla, incrustados en sus propias instrucciones Transact-SQL, ni buscar datos críticos. El uso de parámetros de procedimientos ayuda a protegerse contra ataques por inyección de código SQL. Dado que la entrada de parámetros se trata como un valor literal y no como código ejecutable, resulta más difícil para un atacante insertar un comando en la instrucción Transact-SQL del procedimiento y comprometer la seguridad. Los procedimientos pueden cifrarse, lo que ayuda a ofuscar el código fuente. Para obtener más información, vea Cifrado de SQL Server.

Reutilización del código

El código de cualquier operación de base de datos redundante resulta un candidato perfecto para la encapsulación de procedimientos. De este modo, se elimina la necesidad de escribir de nuevo el mismo código, se reducen las inconsistencias de código y se permite que cualquier usuario o aplicación que cuente con los permisos necesarios pueda acceder al código y ejecutarlo.

Mantenimiento más sencillo

Cuando las aplicaciones cliente llaman a procedimientos y mantienen las operaciones de base de datos en la capa de datos, solo deben actualizarse los cambios de los procesos en la base de datos subyacente. El nivel de aplicación permanece independiente y no tiene que tener conocimiento sobre los cambios realizados en los diseños, las relaciones o los procesos de la base de datos.

Rendimiento mejorado

De forma predeterminada, un procedimiento se compila la primera vez que se ejecuta y crea un plan de ejecución que vuelve a usarse en posteriores ejecuciones. Como el procesador de consultas no tiene que crear un nuevo plan, normalmente necesita menos tiempo para procesar el procedimiento. Si ha habido cambios importantes en las tablas o datos a los que se hace referencia en el procedimiento, el plan precompilado podría hacer que el procedimiento se ejecutara con mayor lentitud. En este caso, volver a crear el procedimiento y forzar un nuevo plan de ejecución puede mejorar el rendimiento.

Tipos de procedimientos almacenados Definidos por el usuario

Un procedimiento definido por el usuario se puede crear en una base de datos definida por el usuario o en todas las bases de datos del sistema excepto en la base de datos Resource. El procedimiento se puede

desarrollar en Transact-SQL o como una referencia a un método de Common Runtime Language (CLR) de Microsoft .NET Framework.

Temporales Los procedimientos temporales son una forma de procedimientos definidos por el usuario. Los procedimientos temporales son iguales que los procedimientos permanentes salvo porque se almacenan en tempdb. Hay dos tipos de procedimientos temporales: locales y globales. Se diferencian entre sí por los nombres, la visibilidad y la disponibilidad. Los procedimientos temporales locales tienen como primer carácter de sus nombres un solo signo de número (#); solo son visibles en la conexión actual del usuario y se eliminan cuando se cierra la conexión. Los procedimientos temporales globales presentan dos signos de número (##) antes del nombre; son visibles para cualquier usuario después de su creación y se eliminan al final de la última sesión en la que se usa el procedimiento.

Sistema Los procedimientos del sistema se incluyen con SQL Server. Están almacenados físicamente en la base de datos interna y oculta Resource y se muestran de forma lógica en el esquema sys de cada base de datos definida por el sistema y por el usuario. Además, la base de datos msdb también contiene procedimientos almacenados del sistema en el esquema dbo que se usan para programar alertas y trabajos. Dado que los procedimientos del sistema empiezan con el prefijo sp_, le recomendamos que no use este prefijo cuando asigne un nombre a los procedimientos definidos por el usuario. Para obtener una lista completa de los procedimientos del sistema, vea Procedimientos almacenados del sistema (Transact-SQL). SQL Server admite los procedimientos del sistema que proporcionan una interfaz de SQL Server a los programas externos para varias actividades de mantenimiento.Estos procedimientos extendidos usan el prefijo xp_. Para obtener una lista completa de los procedimientos extendidos, vea Procedimientos almacenados extendidos generales (Transact-SQL).

Extendidos definidos por el usuario Los procedimientos extendidos permiten crear rutinas externas en un lenguaje de programación como C. Estos procedimientos son archivos DLL que una instancia de SQL Server puede cargar y ejecutar dinámicamente.

http://msdn.microsoft.com/es-es/library/ms190782.aspx

definición de sistemas de seguridad

jj

j

jerarquía de Seguridad

Entidades de seguridad: Usuarios windows, usuarios sql server, Usuarios de BD. Asegurables : recursos que pueden ser protegidos. Modos de autenticación de SQL Server 2008 Para poder acceder a los datos de una base de datos, un usuario tiene que pasar a través de 2 niveles de autenticación: uno en el nivel de SQL Server y el otro enel nivel de base de datos. Estos 2 niveles son implementados usando nombres delogias y cuentas de usuario, respectivamente. Un login valido es requerido paraconectarse al SQL Server y una cuenta de usuario valido es requerida paraacceder a una base de datos.

Login:

Un nombre de login válido es necesario para conectarse a unainstancia de SQL Server. Un login puede ser:

Un login de Windows NT/2000/2003 que ha sido concedido el accesoa SQL Server.

Un login de SQL Server, que es manejado dentro del SQL Server.Estos nombres de login son manejados dentro de la base de datos master.

User: Una cuenta de usuario válida dentro de una base de datos esrequerida para acceder a esta base de datos. Las cuentas de usuario sonespecíficas a una base de datos. Todos los permisos y los propietarios delos objetos son controlados por la cuenta de usuario. Los logins de SQLServer son asociados con estas cuentas de usuarios. Un login puede tener usuarios asociados en diferentes bases de datos, pero únicamente unusuario por base de datos.

Autenticación de Windows. Cuando un usuario se conecta a través deuna cuenta de usuario de Microsoft Windows, SQL Server valida el nombrede cuenta y la contraseña con el token de la entidad de seguridad deWindows del sistema operativo. Éste es el modo de autenticaciónpredeterminado, y es mucho más seguro que el modo mixto. Laautenticación de Windows utiliza el protocolo de seguridad Kerberos,cumple la directiva de contraseñas en lo que respecta a la validación de lacomplejidad de las contraseñas seguras y permite el bloqueo de lascuentas y la expiración de las contraseñas Autenticación de SQL Server. Modo de autenticación de SQL Server. Sufinalidad es ofrecer compatibilidad con versiones anteriores a aplicaciones yusuarios que necesiten acceso a SQL Server con una cuenta de usuario ycontraseña específica. Es el modo menos seguro.

Modo Mixto: Permite a los usuarios conectarse con la autenticación deWindows o la autenticación de SQL Server. Los usuarios que se conectanmediante una cuenta de usuario de Windows pueden usar conexiones deconfianza validadas por Windows. Si tiene que elegir el modo deautenticación mixto y necesita utilizar inicios de sesión de SQL para incluir aplicaciones heredadas, debe establecer contraseñas seguras para todaslas cuentas de SQL Server. Escribir contraseña Escriba y confirme el inicio de sesión del administrador del sistema (sa). Lascontraseñas son la primera línea de defensa contra los intrusos, así

queestablecer contraseñas seguras es esencial para la seguridad del sistema. Noestablezca nunca una contraseña en blanco o no segura.

Un esquema es un conjunto lógico de objetos (tablas, vistas, sinónimos, índices,

procedimientos, funciones, etc). Por defecto,cada usuario de una base de datos crea y

tiene acceso a todos los objetos en su correspondiente esquema . Asociado con cada

usuario de la base de datos existe un esquema con el mismo nombre.

El objetivo de un esquema de seguridad, es:

●

Prevenir accesos no autorizados a la base de datos.

Prevenir accesos no autorizados a objetos (tablas, vistas, índices, procedimientos,

etc)pertenecientes a un usuario.

Monitorear las acciones de los usuarios.

UNIDAD IV: TECNOLOGIAS DE CONECTIVIDAD DE BASE DE DATOS

4.1 ODBC

INTRODUCCION

Es un estándar de acceso a las bases de datos desarrollado por SQL Access Group en 1992. El

objetivo de ODBC es hacer posible el acceder a cualquier dato desde cualquier aplicación, sin

importar qué sistema de gestión de bases de datos (DBMS) almacene los datos. ODBC logra esto

al insertar una capa intermedia (CLI) denominada nivel de Interfaz de Cliente SQL, 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 estándar soporta SAG y SQL.

El software funciona de dos modos, con un software manejador en el cliente, o una filosofía cliente-

servidor. En el primer modo, el driver interpreta las conexiones y llamadas SQL y las traduce desde

el API ODBC hacia el DBMS. En el segundo modo 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 conexión según los

datos que solicite el creador o fabricante.

SIGNIFICADO

Open Database Connectivity (ODBC) es la interfaz estratégica de Microsoft para obtener acceso a

datos en un entorno heterogéneo de relacionales y no - relacionales sistemas de administración de

la base de datos. Basado en la especificación de interfaz de nivel de llamada del grupo de acceso

de SQL, ODBC proporciona una forma abierta, independiente del proveedor de acceso a datos

almacenados en una gran variedad de propietario equipo personal, minicomputadoras y las bases

de datos de mainframe.

ODBC alivia la necesidad de aprender múltiples interfaces de programación de aplicaciones para los

programadores corporativos y fabricantes independientes de software. ODBC proporciona ahora una

interfaz de acceso de datos universal. Con ODBC, los desarrolladores de aplicaciones pueden

permitir que una aplicación al mismo tiempo tener acceso, ver y modificar los datos procedentes de

múltiples bases de datos diferentes.

ODBC es un componente básico de la arquitectura de servicios abiertos de Microsoft Windows.Apple

ha respaldado ODBC como una clave de habilitación de la tecnología de anuncio de soporte en

System 7 en el futuro. Con soporte de la industria cada vez más, ODBC está rápidamente

emergiendo como un sector importante estándar para el acceso a datos para las aplicaciones de

Windows y Macintosh.

REQUERIMIENTOS

Para utilizar ODBC, se requieren los tres componentes siguientes:

Ejemplos de cliente - un ODBC front-end (también llamado ODBC cliente habilitado) - ODBC:

Microsoft Access, una aplicación creada con Access, una aplicación creada con Microsoft Visual

Basic, una aplicación creada con C + Win SDK + ODBC SDK o las aplicaciones basadas en ODBC

de otros proveedores (como Lotus).

CONTROLADOR ODBC - un controlador ODBC para el servidor ODBC. El catálogo de controladores

ODBC contiene una lista extensa de los controladores ODBC. Por ejemplo, Microsoft ODBC Driver

Pack es una colección de los siete controladores ODBC listo para su uso o se incluye con los clientes

ODBC. Un controlador de ODBC de SQL Server se incluye con Access y Informix está trabajando

en un controlador ODBC para Informix.

EJEMPLOS:

Front-end al tener acceso a datos de Access desde un fondo Oracle utilizando el

controlador ODBC para Oracle, que se suministra con Access 1.1.

Acceso de Visual Basic front-end a los datos de un back-end dBASE usando el

controlador de ODBC, que forma parte del paquete de controladores de base de datos de

MS ODBC dBASE.

Escrito con C + ODBC SDK de SDK + ganar acceso a datos desde un sistema

Autónomo de aplicación de C / 400 mediante el AS / 400 de Rochester Software de

controlador de ODBC

4.2 ADO.NET

INTRODUCCION

ADO.NET es un conjunto de clases que exponen servicios de acceso a

datos para el programador de .NET. ADO.NET ofrece abundancia de componentes para la creación

de aplicaciones de uso compartido de datos distribuidas. Constituye una parte integral de .NET

Framework y proporciona acceso a datos relacionales, XML y de aplicaciones. ADO.NET satisface

diversas necesidades de desarrollo, como la creación de clientes de base de datos de aplicaciones

para usuario y objetos empresariales de nivel medio que utilizan aplicaciones, herramientas,

lenguajes o exploradores de Internet.

ADO .NET es la nueva versión del modelo de objetos ADO (ActiveX Data Objects), es decir,

la estrategia que ofrece Microsoft para el acceso a datos. ADO .NET ha sido ampliado para cubrir

todas las necesidades que ADO no ofrecía, ADO .NET está diseñado para trabajar con conjuntos de

datos desconectados, lo que permite reducir el tráfico de red. ADO .NET utiliza XML como formato

universal de transmisión de los datos.

ADO .NET posee una serie de objetos que son los mismos que aparecen en la versión anterior de

ADO, como pueden ser el objeto Connection o Command, e introduce nuevos objetos tales como el

objeto DataReader, DataSet o DataView.

ADO .NET se puede definir como:

Un conjunto de interfaces, clases, estructuras y enumeraciones

Que permiten el acceso a los datos desde la plataforma .NET de Microsoft

Que permite un modo de acceso desconectado a los datos que pueden provenir de

múltiples fuente de datos de diferente arquitectura de almacenamiento.

SIGNIFICADO ADO.NET es un conjunto de componentes del software que pueden ser usados por los

programadores para acceder a datos y a servicios de datos. Es una parte de la biblioteca de clases

base que están incluidas en el Microsoft .NET Framework. Es comúnmente usado por los

programadores para acceder y para modificar los datos almacenados en un Sistema Gestor de

Bases de Datos Relacionales, aunque también puede ser usado para acceder a datos en fuentes no

relacionales. ADO.NET es a veces considerado como una evolución de la tecnología ActiveX Data

Objects (ADO), pero fue cambiado tan extensivamente que puede ser concebido como un producto

enteramente nuevo.

Componentes de ADO.NET

Existen dos componentes de ADO.NET que se pueden utilizar para obtener acceso a datos y

manipularlos:

Proveedores de datos de .NET Framework

El DataSet

En el diagrama siguiente se ilustra la relación entre un proveedor de datos de .NET Framework y

un DataSet

Proveedores de datos de .NET Framework

Los proveedores de datos de .NET Framework son componentes diseñados explícitamente para la

manipulación de datos y el acceso rápido a datos de sólo lectura y sólo avance. El

objeto Connection proporciona conectividad a un origen de datos. El objeto Command permite tener

acceso a comandos de base de datos para devolver datos, modificar datos, ejecutar procedimientos

almacenados y enviar o recuperar información sobre parámetros. El objetoDataReader proporciona

una secuencia de datos de alto rendimiento desde el origen de datos. Por último, el

objeto DataAdapter proporciona el puente entre el objeto DataSet y el origen de datos.

El DataAdapter utiliza objetos Command para ejecutar comandos SQL en el origen de datos tanto

para cargar el DataSet con datos como para reconciliar en el origen de datos los cambios aplicados

a los datos incluidos en el DataSet.

DataSet

El DataSet de ADO.NET está expresamente diseñado para el acceso a datos independientemente

del origen de datos. Como resultado, se puede utilizar con múltiples y distintos orígenes de datos,

con datos XML o para administrar datos locales de la aplicación. El DataSet contiene una colección

de uno o más objetos DataTable formados por filas y columnas de datos, así como información sobre

claves principales, claves externas, restricciones y relaciones relativa a los datos incluidos en los

objetos DataTable.

ARQUITECTURA ADO.NET

REQUERIMIENTOS

Al trabajar con ADO.NET no se utiliza la dll de acceso ODBC de GX

(gxdata.dll), sino que toda la lógica se encuentra en la gxclasses.dll.

En el caso de los DBMSs, cada uno utiliza un Data Provider para acceder a la

base de datos, cada DBMS tiene su propio Data Provider para acceso

ADO.NET.

Por el momento los DBMSs que soportan el acceso ADO.NET son:

SQL Server Oracle DB2 Universal Database

DB2 UDB for iSeries

Los requerimientos necesarios en cada caso son:

SQL Server

ADO.NET utiliza el Data Provider de Microsoft para SQL Server (el cual se instala con el

framework).

Oracle

Se debe tener el Cliente de Oracle versión 8.1.7 o superior, de esta forma se instala el Data

Provider correspondiente.

El valor “Server Name” de las Dbms option hace referencia al Service Name definido en la

instancia del Oracle.

La implementación utiliza el Data provider de Microsoft para Oracle

(System.Data.OracleClient)

DB2 UDB for iSeries

Se necesita la V5R3 del iSeries Access, que es una versión beta y está solo en inglés.

Además cuando se crea un modelo se debe copiar la dll IBM.Data.DB2.iSeries.dll al

directorio gxnet/bin si la aplicación es web o gxnetwin/bin win.

La versión V5R3 del iSeries Access se puede obtener de la URL: http://www-

1.ibm.com/servers/eserver/iseries/access/windows/beta.html.

Nota:

- El Data provider para DB2 UDB for iSeries no soporta BLOBs por ahora.

- Una limitación del driver client acces V5 R3 no permite el llamado objetos remotos en el

Iseries (RPC). Esto implica store procedures (programas RPG o Cobol) u objetos externos

en el Iseries (programas CL)

DB2 Universal Database

Se necesita tener instalada la versión 8.1.3 o superior.

La dll es IBM.Data.DB2.dll, también se debe copiar a los directorios gxnet/bin si la aplicación

es web o gxnetwin/bin win.

4.3 JDBC

INTRODUCCIÓN Java proporciona una plataforma completa, flexible y segura para el desarrollo de aplicaciones,

incluyendo la conectividad con una base de datos. Esta conectividad o acceso a base de datos

relacionales con Java es posible gracias a la API JDBC (Java DataBase Connectivity).

Este API es parte de la plataforma Java desde la versión 1.0 de JDK. Con el paso del tiempo se ha

ido mejorando y aumentando su funcionalidad.

JDBC es ODBC extendido para toda la plataforma Java. Mientras que ODBC es una interfaz escrita

en lenguaje C, que tiene que ser instalado manualmente en cada maquina, JDBC, al estar escrito en

Java, posee todas las propiedades y ventajas del mismo.

ODBC es un estandar para las plataformas MS Windows. JDBC es capaz de trabajar con MS

Windows y otras plataformas.

El API JDBC puede definirse como un conjunto de clases, métodos e interfaces escritos en lenguaje

Java, que permiten el acceso a sistemas de bases de datos relacionales utilizando instrucciones

SQL.

¿ que necesitamos ?

- El API JDBC con dos paquetes principale, java.sql y javax.sql

- Un controlador de acceso a una base de datos

El controlador servirá para conectar la aplicación con la API JDBC, proporcionando comunicación

con la base de datos.

En definitiva, lo que el estándar JDBC hace posible es:

Establecer una conexión.

Lanzar sentencias SQL.

Capturar conjuntos resultado (resulset) de las consultas.

Capturar información de la base de datos.

Manipular los datos.

Puesto que JDBC está implementado en Java, posee la ventaja de serindependiente de la

plataforma e independiente de la base de datos. En esencia, podrá ejecutarse en cualquier

sistema que posea una Máquina Virtual de Java.

SIGNIFICADO JDBC es un API (Application programming interface) que describe o define una librería

estándar para acceso a fuentes de datos, principalmente orientado a Bases de Datos

relacionales que usan SQL (Structured Query Language). JDBC no sólo provee un

interfaz para acceso a motores de bases de datos, sino que también define una

arquitectura estándar, para que los fabricantes puedan crear los drivers que permitan a

las aplicaciones java el acceso a los datos.

Filosofía y Objetivos de JDBC

Cuando SUN se puso a trabajar en este tema, decidió seguir una serie de normas a seguir

para la definición del interfaz, y que han condicionado en gran manera el resultado final. Algunas de

estas características son:

API A NIVEL SQL. JDBC es un API de bajo nivel, es decir, que está orientado a

permitir ejecutar comandos SQL directamente, y procesar los resultados obtenidos. Esto

supone que será tarea del programador crear APIs de más alto nivel apoyándose

directamente sobre JDBC.

COMPATIBLE CON SQL. Cada motor de Base de Datos implementa una amplia

variedad de comandos SQL, y muchos de ellos no tienen porque ser compatibles con el

resto de motores de Base de Datos. JDBC, para solventar este problema de

incompatibilidad, ha tomado la siguiente posición

JDBC permite que cualquier comando SQL pueda ser pasado al driver directamente, con lo que una aplicación Java puede hacer uso de toda la funcionalidad que provea el motor de Base de Datos, con el riesgo de que esto pueda producir errores o no en función del motor de Base de Datos.

Con el objetivo de conseguir que un driver sea compatible con SQL (SQL compliant), se obliga a que al menos, el driver cumpla el Estándar ANSI SQL 92.

JDBC debe ser utilizable sobre cualquier otro API de acceso a Bases de

Datos, o más en particular ODBC (Open Database Connectivity)

JDBC debe proveer un interfaz homogéneo al resto de APIs de Java.

JDBC debe ser un API simple, y desde ahí, ir creciendo.

JDBC debe ser fuertemente tipado, y siempre que sea posible de manera

estática, es decir, en tiempo de compilación, para evitar errores en tiempo de ejecución.

JDBC debe mantener los casos comunes de acceso a Base de Datos lo

más sencillo posible:

Mantener la sencillez en los casos más comunes (SELECT, INSERT, DELETE y UPDATE)

Hacer realizables los casos menos comunes: Invocación de procedimientos almacenados...

Crear múltiples métodos para múltiple funcionalidad. JDBC ha preferido

incluir gran cantidad de métodos, en lugar de hacer métodos complejos con gran

cantidad de parámetros.

REQUERIMIENTOS

Para tener acceso a los datos desde una base de datos de SQL Server mediante el controlador

JDBC de Microsoft SQL Server, debe tener los siguientes componentes instalados en el equipo:

Controlador de JDBC de Microsoft SQL Server

Java Runtime Environment

3. Procedimiento de Conexión y acceso a datos con JDBC.

Consideraciones previas.

El proceso de acceso a una Base de Datos a través de JDBC, exige dar una serie de pasos

previos antes de crear la conexión al motor de Base de Datos. El primer paso es determinar el

entorno en el que el proyecto va a ser instalado, y más en concreto, que parámetros del entorno

afectan directamente a JDBC:

Debemos considerar las características específicas de una base de datos, como por ejemplo, como

mapear los tipos de datos SQL a Java.

Es probable encontrarnos varios drivers distintos para la misma fuente de datos. Debemos saber

detectar cual es el driver más adecuado para nuestra aplicación, por ejemplo, si elegimos un driver

ODBC/JDBC, tendremos más flexibilidad para elegir distintas fuentes de datos, pero si por ejemplo

trabajamos con una Base de Datos Oracle, un driver JDBC diseñado específicamente para esta base

de datos será mucho más eficiente.

En función de donde se encuentre el driver físicamente, debemos considerar aspectos de

rendimiento y seguridad. Por ejemplo, si cargamos el driver desde un servidor remoto tendremos

que considerar aspectos sobre seguridad de Java.

Procedimiento de conexión.

1. Cargar el driver. Cualquier driver JDBC, independientemente del tipo debe implementar el interfaz java.sql.Driver. La carga del driver se puede realizar de dos maneras distintas:

Definiendo los drivers en la variable sql.driver (variable que mantiene todos las clases de

los drivers separados por comas) Cuando la clase DriverManager se inicializa, busca esta

propiedad en el sistema.

El programador puede forzar la carga de un driver específico, usando el método Class.forName(driver).

2. Registro del driver. Independientemente de la forma de carga del driver

que llevemos a cabo, será responsabilidad de cada driver registrarse a sí mismo,

usando el método DriverManager.registerDriver. Esto permite a la clase

DriverManager, usar cada driver para crear conexiones con el controlador de Base

de Datos. Por motivos de seguridad, la capa que gestiona JDBC, controlará en

todo momento que driver es el que se está usando, y cuando se realicen

conexiones, sólo se podrán usar drivers que estén en el sistema local de ficheros

o que usen el mismo ClassLoader que el código que está intentando crear la

conexión.

3. Crear una conexión. El objetivo es conseguir un objeto del tipo java.sql.Connection a través del método DriverManager.getConnection(String url). La capa de gestión, cuando este método es invocado, tratará de encontrar un driver adecuado para conectar a la base de datos especificada en la URL, intentándolo por el orden especificado en la variable sql.driver. Cada driver debería examinar si ellos proveen el “subprotocolo” que especifica la URL. (Ver anexo)

3. Tipos de conectores (drivers) JDBC

Tipo 1. JDBC-ODBC bridge más driver ODBC:

“BRIDGE” Ventajas: Buena forma de aprender JDBC. También puede ser buena

idea usarlo, en sistemas donde cada máquina cliente tenga ya instalado los drivers

ODBC. También es posible que sea la única forma de acceder a ciertos motores de Bases

de Datos. Inconvenientes: No es buena idea usar esta solución para aplicaciones que

exijan un gran rendimiento, ya que la transformación JDBC-ODBC es costosa. Tampoco

es buena solución para aplicaciones con alto nivel de escalabilidad.

Tipo 2. Driver Java parciales: “NATIVE” Ventajas: Mejor

rendimiento que el anterior. Quizá puede ser buena solución para entornos controlados

como intranets. Ejemplo OCI oracle. Inconvenientes:Principalmente la escalabilidad, ya

que estos drivers exigen que en la máquina cliente librerías del cliente de la Base de

Datos.

Tipo 3. Driver JDBC a través de Middleware: “NETWORK” Ventajas: Buena solución cuando necesitamos acceder a Bases de

Datos distintas y se quiere usar un único driver JDBC para acceder a las mismas. Al

residir la traducción en el servidor del middleware, los clientes no necesitan librerías

específicas, tan solo el driver. Inconvenientes: La desventaja principal reside en la

configuración del servidor donde se encuentra el middleware. Necesitará librerías

específicas para cada motor de base de datos distinto, etc.

Tipo 4: Driver java puro (acceso directo a Base de Datos): “THIN”. Ventajas: 100 % portable. Buen rendimiento. El cliente sólo

necesita el driver. Inconvenientes: Al ser independiente de la plataforma, no aprovecha

las características específicas del S.O

5. Arquitecturas JDBC

Aplicaciones standalone

Applets comunicando con un servidor Web

Aplicaciones y applets comunicando con una base de datos a través de un puente

JDBC/ODBC.

Aplicaciones accediendo a recursos remotos usando mecanismos como Java RMI

El procedimiento de conexión con el controlador de la base de datos, independientemente de la

arquitectura es siempre muy similar.

En el primero de los casos (a través de la propiedad sql.driver), JDBC usará el primer driver

que permita conectarse correctamente a la Base de Datos.

Los conectores o drivers JDBC, se pueden dividir en cuatro tipos principalmente:

Permite el acceso a Base de Datos JDBC mediante un driver ODBC. Cada máquina cliente

que use el puente, debe tener librerías clientes de ODBC(dll propias del S.O)

Traducen las llamadas al API de JDBC Java en llamadas propias del motor de Base de

Datos (Oracle, Informix...). Al igual que el tipo anterior, exige en las máquinas clientes código

binario propio del cliente de la Base de datos específica y del sistema operativo

Traduce las llamadas al API JDBC en llamadas propias del protocolo específico del broker.

Éste se encargará de traducirlas de nuevo en sentencias propias del motor de Base de Datos de

cada caso.

Convierte o traduce las llamadas al API JDBC en llamadas al protocolo de red usado por el

motor de bases de datos, lo que en realidad es una invocación directa al motor de bases de datos.

S.O donde vaya a correr.

La arquitectura básica de JDBC (ya la hemos visto) es simple. Una clase llamada

DriverManager provee un mecanismo para controlar un conjunto de drivers JDBC. Esta clase intenta

cargar los drivers especificados en la propiedad del sistema jdbc.drivers. También podemos cargar

un driver explicitamente usando Class.forName(). Durante la carga, el driver intentará registrarse a

si mismo usando el método clase DriverManager.registerDriver(). Cuando se invoque al método

DriverManager.getConnection(), ésta buscará el primer driver de los registrados que pueda manejar

una conexión como la descrita en la URL y retornará un objeto que implemente el interfaz

java.sql.Connection.

Sin embargo, en función de la localización de la base de datos, el driver, la aplicación y el

protocolo de comunicación usado, nos podemos encontrar distintos escenarios que accedan a Base

de Datos a través de JDBC:

Todos ellos se pueden agrupar en dos tipos distintos de arquitecturas:

La aplicación que accede a la base de datos reside en el mismo lugar que el driver de la base de

datos. El driver accederá al servidor donde corra el motor de base de datos.

En este caso, será el driver el encargado de manejar la comunicación a través de la red.

En el ejemplo, una aplicación java corriendo en una máquina cliente que usa el driver

también local. Toda la comunicación a través de la red con la base de datos será manejada por el

driver de forma transparente a la aplicación Java.

REFERENCIAS:

https://sites.google.com/site/conceptoprogramacion/Home/jdbc1

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=introjdbc

https://sites.google.com/site/conceptoprogramacion/Home/jdbc1

http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=introjdbc

ODBC (Open Data Base Connectivity): Esta tecnología proporciona una interfaz común para tener acceso a bases de datos SQL heterogéneas. ODBC está basado en SQL (Structured Query Language) como un estándar para tener acceso a datos. ODBC permite la conexión fácil desde varios lenguajes de programación y se utiliza mucho en el entorno Windows. Sobre ODBD Microsoft ha construido sus extensiones OLE DB y ADO. Los OCBD se pueden clasificar en 3 categorías:

o Los ODBC's que permitan la realización de consultas y actualizaciones. o Los ODBC's que mediante ellos se pueda llegar a la creación de tablas en la base

de datos. o Los ODBC's propios de los DBMS, los cuales se pueden llegar a manipular ciertas

herramientas de administración. CGI (Common Gateway Interface): es una de las soluciones que se está utilizando más

para la creación de interfaces Web/DBMS. Entre las ventajas de la programación CGI, destaca la 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 independiente, 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 servidor, 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 al que el servidor Web tiene que cargar el programa CGI y conectar y desconectar con la base de datos cada vez que se recibe una requisición. Además, no existe un registro del estado del servidor, sino que todo hay que hacerlo manualmente.

ISAPI (Internet Server Application Programming Interface): Es la interfaz propuesta por Microsoft como una alternativa más rápida que el CGI, y está incluida en el Servidor Microsoft Internet Information (IIS). Así como los escritos CGI, los programas escritos usando ISAPI habilitan un usuario remoto para ejecutar un programa, busca información dentro de una base de datos, o intercambia información como otro software localizado en el servidor. Los programas escritos usando la interfaz ISAPI son compilados como bibliotecas de enlace dinámico (DLL - Dinamic 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 aplicaciones CGI, debido a que requieren menos tiempo de uso de CPU al no iniciar procesos separados. 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 de ODBC. Además, ISAPI permite realizar un procesamiento previo de la solicitud y uno posterior de la respuesta, con lo cual manipula la solicitud/respuesta HTTP. Los filtros ISAPI pueden utilizarse para aplicaciones tales como autenticación, acceso o apertura de sesión.

NSPAI. es la API propuesta por Netscape para extender la funcionalidad de sus servidores.

DBI (PERL): Perl es uno de los lenguajes más utilizados para programación en la Web y proporciona su propia interfaz de acceso a datos, llamada DBI (DataBase Interface). Es especialmente utilizado bajo plataformas Linux/Unix, solucionando las complejidades de ODBC en estos sistemas. DBI actúa como una abstracción para un conjunto de módulos DBD (DataBase Driver). Cada módulo DBD actúa como manejador de un sistema gestor de base de datos distinto. Existen módulos para prácticamente cualquier SGBD (Oracle, Informix, MySQL, etc.) y puentes hacia otras tecnologías como ADO, JDBC ...

JDBC (Java Data Base Connectivity): se trata del estándar para la conectividad entre el lenguaje Java y un amplio rango de sistemas gestores de bases de datos. Los JDBC pueden desenvolverse tanto en un nivel cliente, esto es, trabajando del lado de la aplicación, o en el servidor directamente relacionado con la base de datos. Cuando se encuentre a nivel cliente, trabajará con la tecnología ODBC para acceso a los datos. Hay diversos tipos de controladores JDBC:

o El puente JDBC-OBDC: fue uno de los primeros controladores disponibles, implementa un enlace para utilizar un controlador ODBC desde Java. Con el tiempo han surgido controladores JDBC específicos para cada base de datos que mejoran el rendimiento del puente JDBC-ODBC.

o Controladores Java parcialmente nativos: usan tanto código Java como binario específico de cada plataforma.

o Controladores JDBC-Net de Java puro: son controladores escritos completamente en Java que entienden un protocolo de red estándar (HTTP, etc.) y permiten comunicarse con un servidor de acceso a bases de datos, que es el que finalmente provee el acceso al SGBD específico (posiblemente con ODBC).

o Controladores de protocolo nativo en Java puro: escritos en Java puro, utilizan el protocolo específico de la marca del SGBD.

SQL LINKS: se trata de controladores que se encargan de realizar la comunicación remota entre la aplicación y los servidores remotos de bases de datos, permitiendo una comunicación casi directa y muy rápida. Los ha desarrollado la empresa Inprise y permiten conexiones con otros servidores de bases de datos como Interase, Oracle, Sybase, Informix, Microsoft SQL Server, etc.

Las 2 tecnologías más importantes de conectividad a la la base de datos son ADO y JDBC.

ADO:

Existen varios niveles o interfaces para lograr la comunicación o acceso a la base de datos a través de la aplicación. El siguiente esquema muestra 2 de los principales niveles, dentro de los cuales se encuentra ADO.

Fuente: Taller de Base de Datos. http://www.itver.edu.mx/comunidad/material/tallerbd/apuntes/index.html

Por lo general, las interfaces de objetos de datos son más fáciles de usar que las APIS, aunque las APIs ofrecen más funcionalidades. ADO (ActiveX Data Objects) es la interfaz de objetos de datos para OLE DB, y RDO (Remote Data Objects) es la interfaz para el objeto ODBC.

ADO encapsula el API OLE DB en un modelo objeto simple que reduce el desarrollo, mantenimiento y costo de la aplicación. Es muy fácil de usar, utiliza lenguajes de programación como Visual Basic, Java, C++, VBScript y JScript, puede accesar datos desde cualquier recurso OLE DB y además, es extensible. Es la interfaz utilizada por Microsoft.

El modelo ADO, basado en el modelo de objetos, define una jerarquía de objetos programables que pueden ser usados por desarrolladores de páginas Web para acceder a la información almacenada en una base de datos. Una jerarquía es un grupo de objetos relacionados que trabajan juntos para un mismo propósito. Por ejemplo, en la siguiente figura, cada caja representa un objeto, y cada línea representa una asociación directa entre ellos.

ADO está compuesto de siete objetos, algunos de alto nivel como Connection, Command y Recordset, que pueden ser creados y eliminados por el usuario y otros con distintas funcionalidades como designar propiedades de conexión, definir sentencias y ejecutarlas, optimización de consultas, etc. Estos elementos se representan en la siguiente figura:

Fuente: Taller de Base de Datos. http://www.itver.edu.mx/comunidad/material/tallerbd/apuntes/index.html

Cada uno de los objetos anteriores contiene una colección de objetos Property. El objeto Property permite a ADO mostrar dinámicamente las capacidades de un objeto específico.

ADO permite diseñar sitios web que pueden acceder repetidamente a la misma base de datos usando una misma búsqueda u otra similar. Se pueden compartir conexiones y esto significa una menor carga de trabajo para el servidor de la base de datos, un tiempo de respuesta más rápida y más accesos a página con éxito.

Existe un componente llamado RDS (Remote Data Service) que ofrece el ambiente de Acceso Universal a Datos, ya sea desde Internet o la World Wide Web, creando un marco de trabajo que permite una interacción fácil y eficiente con los datos fuente OLE DB tanto en Intranets corporativas o en Internet. RDS ofrece la ventaja de obtener por el lado del cliente resultados de datos, actualización y soporte para controles ADO y ofrece el modelo de programación OLE DB/ADO para manipular datos de las aplicaciones del cliente.

JDBC

JDBC o Java Data Base Connectivity, creado por la empresa Sun, es la API estándar de acceso a bases de datos con Java. Sun optó por crear una nueva API en lugar de utilizar ODBC, porque esta última presentaba algunos problemas desde ciertas aplicaciones Java. ODBC es una interfaz escrita en lenguaje C, que al no ser un lenguaje portable, hacía que las aplicaciones Java también perdiesen la portabilidad. Además, ODBC ha de instalarse manualmente en cada máquina, mientras que los controladores (drivers) JDBC que están escritos en Java son automáticamente instalables y portables. El nivel de abstracción al que trabaja JDBC es más alto que el de ODBC y, de esta forma, se pueden crear librerías de más alto nivel,

Para trabajar con JDBC es necesario tener controladores que permitan acceder a las distintas bases de datos. Sin embargo, ODBC sigue siendo hoy en día la API más popular para acceso a Bases de Datos, por lo que: Sun se ha visto obligada a diseñar un puente que permite utilizar la API de JDBC en combinación con controladores ODBC.

Fuente: Taller de Base de Datos. http://www.itver.edu.mx/comunidad/material/tallerbd/apuntes/index.html

Las tecnologías que se emplea para la conectividad entre los datos y la aplicación, se ha convertido en un factor muy importante a la hora de desarrollar un proyecto web que cuente con funcionalidad de acceso a datos. A continuación se muestra un cuadro comparativo de las dos tecnologías más importantes en este sentido: ActiveX Data Objects (ADO) y Java Data Base Connectivity (JDBC).

ADO JDBC

Tecnología elaborada por Microsoft Tiene la principal función de realizar la solicitud

de los datos a la base de datos. Esta solicitud la realizará mediante la

tecnología OLE DB, la cual estará en contacto de manera directa con la base de datos.

La tecnología OLE DB sólo se empleará cuando el DBMS pertenece de igual manera a Microsoft, como es SQL Server.

ADO encapsulará a ciertos objetos de OLE DB, para que de ésta manera se realice la conexión con la base de datos.

Para realizar la gestión de acceso a bases de datos heterogéneas por parte de ADO, éste hará uso de ciertos objetos de la tecnología RDO (Remote Data Objects).

RDO dependerá de los ODBC’s para poder efectuar la conexión a la base de datos y con esto el acceso a la información.

ADO podrá encontrarse trabajando en una página web en conjunto con código HTML; esto será posible mediante un mecanismo de introducción de instrucciones como es el VBscript.

Los objetos que conforman al ADO, no son compatibles con otros lenguajes, solo por aquellos que pertenecen a la empresa Microsoft como son: Visual C++, Visual Basic, Visual Java, etc.

Tecnología hecha por Sun Microsistems. Tiene la función de ser un gestor para la

aplicación con respecto a la base de datos. Por primera vez el JDBC fue empleado,

tomando como intermediario entre él y la base de datos al ODBC.

Como modelo cliente/servidor, el JDBC se encontrará trabajando en el equipo cliente, conectándose directamente con la base de datos.

Como modelo de tres capas, el JDBC se encontrará en una capa intermedia, donde todos los usuarios pasarán por él para poder accesar a la base de datos.

Existen módulos JDBC que son propios de los fabricantes de DBMS, que son utilizados para el rápido acceso a la información de las bases de datos de los mismos.

JDBC no se encontrará ligado a trabajar con alguna tecnología en específica, ya que se elaboró con la finalidad de ser portable.

En aplicaciones Web, JDBC se encontrará laborando en conjunto con código HTML, mediante el mecanismo del Java script.

JDBC se elaboró con la finalidad de poder ser compatible y portable para poder ser empleado en aplicaciones y para la conexión con bases de datos.

Fuente: Taller de Base de Datos. http://www.itver.edu.mx/comunidad/material/tallerbd/apuntes/index.html

Por último, hay que destacar también una tecnología llamada Web DB utilizada por algunos servidores de bases de datos, con la cual, un usuario puede solicitar la información que requiera y visualizarla a modo

de respuesta en una página Web, que será creada y elaborada por el propio servidor de base de datos.

El proceso que comprende desde la solicitud a la visualización de la información, puede ser representado de la siguiente manera:

En este esquema anterior destacan:

Navegador (browser): es la aplicación mediante la cual, se tiene acceso libre a los servicios de Internet, y el medio que permite al usuario introducir la solicitud para visualizar la información, empleando el URL para especificar detalladamente el proceso que se desea ejecutar.

Interfaz de Web: proporciona una interfaz para que un programa que se ejecute en el servidor genere como salida el código HTML, en lugar de leer simplemente un archivo estático de texto. Con ésta interfaz se podrán crear las páginas Web de forma dinámica y/o utilizar la implementación de formularios HTML. Esta interfaz permite tecnologías como los CGI’s o aquellas otras que son propias del servidor de base de datos.

Agente PL/SQL: es el eslabón final del proceso entre un navegador cliente y el servidor de base de datos. El agente ejecutará una llamada a un procedimiento almacenado en el servidor. Este procedimiento creará una página HTML dinámica como salida, y el agente devolverá dicha salida al cliente a través del navegador empleando de igual manera la Interfaz de Web.

Base de Datos (BD). En ella se mantendrá almacenada la información; se encargará de proporcionar los datos que le hayan solicitado previamente, al momento de la ejecución de un procedimiento por parte del Agente PL/SQL.

http://www.hipertexto.info/documentos/b_datos.htm