Procedimientos almacenados..mañana

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:
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.

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.
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

Procedimientos almacenados..mañana

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Procedimientos almacenados..mañana

Más de ANilez Solrak

Procedimientos almacenados..mañana