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
Top Related