INTRODUCCIÓN

Una capa de acceso a datos o DAL (del inglés data access layer) en los programas informáticos, es una capa de un programa informático que proporciona acceso simplificado a los datos almacenados en el almacenamiento persistente de algún tipo, tal como una entidad-relación de base de datos. Este acrónimo se usa predominantemente en entornos Microsoft ASP.NET.

Por ejemplo, el DAL podría devolver una referencia al objeto (en términos de programación orientada a objetos) completo con sus atributos en lugar de un registro de campos de una tabla de la base de datos. Esto permite que los módulos del cliente (o usuario) se crearan con un mayor nivel de abstracción. Este tipo de modelo puede ser implementado mediante la creación de una clase de métodos de acceso a datos que hacen referencia directamente a un conjunto correspondiente de procedimientos almacenados de base de datos. Otra aplicación potencial podría recuperar o escribir registros hacia o desde un sistema de archivos. El DAL esconde esa complejidad del almacén de datos subyacente del mundo externo.

CAPA DE ACCESO A DATOS

En la capa de datos se gestiona el acceso a los datos de la aplicación. Se emplean gestores de bases de datos que realizan la recuperación y el almacenamiento físico de los datos a partir de solicitudes de la capa de negocio.

En esta capa se puede hacer uso de una propiedad denominada persistencia de objetos, que permite vincular objetos de bases de datos relacionales a objetos de lenguajes de programación como Java, para aumentar el nivel de abstracción y facilitar el acceso a los datos desde la capa de negocio. Existen varias implementaciones tecnológicas sobre persistencia que deberán emplearse atendiendo a las necesidades de cada aplicación.

(REPOSITORY)

En esta capa debemos distinguir dos tipos de accesos:

· Acceso a datos del modelo de datos propio del sistema que se hará mediante acceso DAO (Data Access Object). Para este tipo de acceso, usaremos el framework JPA (Java Persistence API) mediante Spring Data.

· Acceso a sistemas externos mediante conectores (webservices, APIs, etc.)

ACCESO DAO

En primer lugar, será necesario configurar la Base de Datos a la que debe acceder. Para ello, debemos definir el archivo de configuración de Spring,applicationContext.xml, añadiendo lo siguiente:

</bean>

</property>

</bean>

</property>

</bean>

</bean>

<jdbc:embedded-database id="dataSource" type="[TIPO_BD]" />

<jdbc:initialize-database data-source="dataSource">

<jdbc:script location="classpath:cargaInicial.sql" />

</jdbc:initialize-database>

<jpa:repositories base-package="com.ayesa.fg.cloud.repository" />

Los valores entre corchetes deberán ser definidos explícitamente para cada entorno de ejecución (desarrollo, preproducción, pruebas, explotación, etc.). Pasemos a describir cada uno de ellos:

· [BD_DRIVER]: Aquí se indicará la clase con el driver de conexión a la BD, según el tipo (HSQLDB. MySQL, Oracle, etc.). Algunos ejemplos de drivers:

o org.hsqldb.jdbcDriver para bases de datos HQSLDB

o com.mysql.jdbc.Driver para MySQL

o oracle.jdbc.OracleDriver para Oracle

· [URL_CONEXION_BD]. Cadena de conexión a la BD. Por ejemplo, para una base de datos de prueba HSQLDB en memoria, la cadena de conexión sería:

jdbc:hsqldb:mem:mibd

donde mibd será el identificador de la BD en memoria.

· [USER]. Nombre del usuario de conexión a la BD

· [PASSWD]. Contraseña de conexión para el usuario de la BD

· [NOMBRE_JNDI]. Nombre de la unidad de persistencia con la que se registra la BD para acceder mediante JPA. Esta unidad de persistencia se definirá en el archivo /src/main/resources/META-INF/persistence.xml de la siguiente manera:

<persistence xmlns="http://java.sun.com/xml/ns/persistence"

xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd"

version="2.0">

<persistence-unit name="[NOMBRE_JNDI]" transaction-type="RESOURCE_LOCAL">

<provider>org.hibernate.ejb.HibernatePersistence</provider>

</persistence-unit>

</persistence>

· [TIPO_BD] Tipo de la BD. Los posibles valores son HSQL, MYSQL, ORACLE, etc.

Una vez configurado el sistema para acceder a la BD, a través de la capa DAO, se deben definir los beans que forman parte de la interfaz.

Por un lado, se definirán las clases que modelan la BD. Para ello, usamos JPA y sus anotaciones para definir dichas clases, que llamaremos DTO (Data Table Objects). Por otro, las interfaces con los métodos para acceder a los datos que llamaremos interfaces DAO (Data Access Objects). Usamos Spring Data y las facilidades que nos da este framework.

OBJETOS DEL MODELO (DTO)

@Entity

@Table(name = "MyObject")

public class MyObjectDTO implements Serializable {

private static final long serialVersionUID = 1L;

@Id

@Column(name = "id")

@GeneratedValue

private Integer id;

@Column(name = "name", length = 100)

private String name;

@Column(name = "value", length = 50)

private String value;

[Getters y Setters]

}

Como podemos observar, a los objetos DTO les aplicamos dos anotaciones:

· @Entity, para indicarle al sistema que será una entidad “manejable” por JPA.

· @Table, indica que el objeto se mapeará con la tabla del modelo de datos (Base de datos) que se indica con el parámetro ‘name’.

· Los atributos de la clase se mapean como columnas de la tabla mediante la anotación @Column.

INTERFACES DE ACCESO A DATOS (DAO)

Para el diseño de las interfaces de acceso a datos vamos a usar el framework Spring Data sobre JPA ya que nos ofrece mucha mayor facilidad en su definición y nos descarga de la tarea de desarrollar sus implementaciones ya que se diseñan de manera declarativa, mediante anotaciones y con lenguaje para las queries JPQL, lenguaje propio de JPA que permite aislarnos de la implementación elegida para la BD.

@Repository(value = "ejemploDao")

public interface EjemploDAO extends JpaRepository<MyObjectDTO, Integer> {

@Query("from MyObjectDTO obj where obj.name = :name")

List findByName(@Param("name") String name);

@Query("from MyObjectDTO obj where obj.value = :value")

List findByValue(@Param("value") String value);

}

Nota: A pesar de que el mismo Spring Data permite declarar directamente, a través de la interfaz JpaRepository, los métodos como findByXXXX (donde XXXX es el nombre del atributo) sin necesidad de definir la query con la anotación @Query, en el ejemplo lo he indicado así para mostrar las diferentes posibilidades que ofrece Spring Data. Esto lo podremos ver en un posterior artículo específico sobre ello.

A continuación, detallamos las características en el diseño y desarrollo de esta capa:

· Las interfaces heredan de la interfaz JpaRepository. En ella se le indica el tipo del objeto DTO base y el tipo del índice (Integer, Long, etc.). Esta interfaz proporciona los métodos básicos de tipo CRUD (Create, Read, Update y Delete) con lo que nos ahorramos tener que realizar implementaciones explícitas así como características propias de JPA.

· Como se puede observar, las interfaces se definen con la anotación @Repository. Al contrario que con la anotación @Service, en esta capa se anota en la misma interfaz y no en la implementación. Como hemos indicado, estas interfaces no requieren de una implementación específica con lo que la anotación la hacemos en la misma interfaz, en ausencia de dicha imlementación.

· La interfaz JpaRepository proporciona los métodos básicos de acceso a datos pero se pueden añadir métodos de acceso específicos con queries más complejas gracias a la anotación @Query. Con esta anotación, se permite diseñar queries más complejas (con joins, consultas con varios parámetros, etc.). El lenguaje utilizado para las Queries es JPQL, propio de JPA que permite aislar del tipo de BD utilizado lo que facilita la migración de un sistema a otro aunque se pueden usar queries en lenguaje nativo (MySQL, Oracle, etc.) mediante el atributo nativeQuery (por defecto tiene el valor false).

1	@Query("from MyObjectDTO obj where obj.name = :name")
1	@Query("select count(*) from MyObject obj where obj.name = :name", nativeQuery=true)

En la construcción de las Queries en JPQL podemos observar varias características:

1. No es necesario construir la ‘select‘ completa.

2. En la parte del ‘from‘, debemos poner el nombre de la entidad java (@Entity) y no el nombre de la tabla asociada del modelo de datos (@Table).

3. El parámetro ‘:name‘ se corresponde con el parámetro definido en la interfaz del método que lleva la anotación @Param.

USAR LA CREACIÓN DE REFLEJO DE LA BASE DE DATOS (JDBC)

La creación de reflejo de la base de datos es un solución de software destinada a aumentar la disponibilidad de la base de datos y la redundancia de los datos. El Controlador JDBC de Microsoft para SQL Server ofrece compatibilidad implícita con la creación de reflejo de la base de datos, por lo que el desarrollador no necesita escribir código ni realizar ninguna otra acción una vez configurado para la base de datos.

La creación de reflejo de la base de datos, implementada para cada base de datos, conserva una copia de una base de datos de producción de SQL Server en un servidor en espera. Este servidor puede ser un servidor en estado de espera activa o semiactiva, dependiendo de la configuración y del estado de la sesión de creación de reflejo de la base de datos. Un servidor en estado de espera activa admite una conmutación por error rápida sin que se produzca una pérdida de las transacciones confirmadas y un servidor en estado de espera semiactiva admite el forzado del servicio (con una posible pérdida de datos).

La base de datos de producción se llama base de datos principal y la copia en espera se llama base de datos reflejada. La base de datos principal y la base de datos reflejada deben residir en instancias independientes de SQL Server (instancias de servidor) y en equipos distintos si es posible.

La instancia del servidor de producción, llamado servidor principal, se comunica con la instancia del servidor en espera, llamado servidor reflejado. Los servidores principal y reflejado actúan como asociados en la sesión de creación de reflejo de la base de datos. Si el servidor principal genera un error, el servidor reflejado puede convertir su base de datos en la base de datos principal a través de un proceso denominado conmutación por error. Por ejemplo, Partner_A y Partner_B son dos servidores asociados, con la base de datos principal inicialmente en Partner_A como servidor principal y la base de datos reflejada en Partner_B como servidor reflejado. Si Partner_A se queda sin conexión, la base de datos de Partner_B puede realizar la conmutación por error para convertirse en la base de datos principal actual. Cuando Partner_A se vuelve a unir a la sesión de creación de reflejo, se convierte en el servidor reflejado y su base de datos pasa a ser la base de datos reflejada.

En caso de que el servidor Partner_A se dañe de forma irreparable, se puede poner en línea un servidor Partner_C para que actúe como un servidor reflejado para Partner_B, que es ahora el servidor principal. No obstante, en este escenario, la aplicación cliente debe incluir una lógica de programación para asegurarse de que las propiedades de la cadena de conexión se actualizan con los nombres de servidor nuevos usados en la configuración de la creación de reflejo de la base de datos. En caso contrario, es posible que la conexión con los servidores no se realice.

Las configuraciones alternativas de creación de reflejo de la base de datos proporcionan diferentes niveles de rendimiento y de seguridad de los datos, y admiten varias formas de conmutación por error. Para obtener más información, vea "Información general sobre la creación de reflejos de la base de datos" en los Libros en pantalla de SQL Server.

CONCLUSIONES

1. Se diseña el sistema de manera que se desarrolla un núcleo principal y luego se le van agregando módulos adicionales agrupados por funcionalidad

2. Se establecen dos niveles de capa de negocio:

1. Capa de negocio principal. Esta capa formará parte del núcleo de la aplicación

2. Capa de negocio secundaria. Será la que usen los distintos módulos. Desde esta capa secundaria se delegará en la capa de negocio principal para resolver lógica de negocio básica o llamará directamente a los distintos conectores disponibles.

3. En la capa de datos se consideran dos alternativas que pueden ser complementarias:

1. Acceso DAO a un modelo de datos propio

2. Acceso a sistemas externos mediante webservices, APIs, etc.

CONFIGURACION MYSQL PARA EL PROYECTO DE NETBEANS

Proyecto Librerías Propiedades Se debe descargar el driver que se Compile encarga de comunicar una aplicación java con mysql. Después se configura el archivo .jar al conjunto de librerías así: Seleccionamos el proyecto y damos clic derecho y luego clic en propiedades Luego vamos a la sección librerías dentro de las propiedades. Seleccionamos la carpeta compile y luego el botón Add library. En la ventana emergente Add Library hacemos clic en el botón Manage Libraries. Add Library Manage Libraries

En la venta Library Manager hacemos clic Nombre en el botón New Library En la ventana emergente damos el nombre de la librería y en el tipo se deja el valor predeterminado y damos clic en ok New Library ok

En la ventana Library Manager seleccionamos la librería recién creada y hacemos clic en el botón Add JAR/Fólder. Ubicación del conector Add JAR/Fólder •Seleccionamos la ubicación del conector de Mysql-Java y hacemos clic en el botón Add JAR/Fólder. •Clic en el botón Ok, clic en el botón Add Library y finalmente clic en el botón Ok. Librería Mysql ok

En la ventana anterior nos ubicamos en RUNTIME y seleccionamos database y lo desplegamos, nos ubicamos en Drivers clic derecho y seleccionamos New Drivers. Runtime Drivers New Drivers

Aparece la siguiente ventana y damos clic en Add y buscamos nuevamente el conector mysql utilizado en los anteriores pasos

Finalmente nos aparece en la carpeta de Drivers el conector a Mysql, nos ubicamos en el y damos clic derecho se despliega una ventana y damos clic en connect using

En la ventana que nos aparece se digita la información, activamos la casilla de verificación y damos clic en OK. Nombre de la base creada en Mysql usuario Contraseña

En esta ventana damos clic en OK

Finalmente nos aparece la conexión con las tablas creadas en mysql

Conectividad de Bases de Datos con Java.

Por:

Aleksandr Paúl Quito Pérez.

Paso 6:

Ahora procedemos a crear un evento, para que genere la acción, esto se hace posicionándose sobre el botón “Buscar”, clic derecho, tal como se muestra: Luego de esto aparecerá el siguiente código: Dentro del método del botón necesitamos, que al hacer clic en el botón, este obtenga el valor de la cajita

Text Fields, para luego pasarlo al método de la clase proceso:private void Buscar por Código ActionPerformed(java.awt.event.ActionEvent evt) { //

TODO add your handling code here

Conectividad de Bases de Datos con Java.

Por:

Aleksandr Paúl Quito Pérez.

La codificación completa para el formulario de este programa se muestra acontinuación: Se puede observar que hemos creado objetos de la clase

DefaultTableModel

Proceso (importando sus librerías)

. Luego dentro del constructor por defecto de la Clase

Formulario

, estamos agregando las columnas con sus respectivos nombres que deseamos apreciar en la tabla. Recordemos que la variable “

tabla1 ” es el que asignamos a la tabla.

Conectividad de Bases de Datos con Java.

Por:

Aleksandr Paúl Quito Pérez.

En el método

BuscarXCodigo, estamos capturando el código ingresado por teclado con:

String cod=tcod.getText();

Luego dt.setRowCount(0);

- se utiliza esto para limpiar la tabla cada vez que hagamos un listado nuevo. Luego estamos utilizando un

for

del tipo iterativo, Este

for

que pertenece a la clase

Alumnos, recorrerá el listado de la clase proceso al recibir un código por teclado. Por ultimo dentro del for, agregaremos el contenido de las filas dentro de un Objeto[] el cual no tiene una longitud limite de datos, esto se hace con: dt.addRow(new Object[]

{

x.getCodigo(),x.getApellido(),x.getCurso(),x.getExaParcial(),x.getExaFinal(),x.Promedio(),x.Observacion()

});

si observamos estamos agregando los datos en cada filas de la columnas que hemos creado en el método constructor por defecto de la clase

Formulario

.Al Ejecutar esta aplicación, dando en

RUN Sobre la clase Formulario se obtiene el siguiente resultado:

Recordemos:

Que para este problema hemos utilizado, como manejador de base de datos a

Ms Sql Server

, para el cual hemos hecho la conexión en este ejemplo. En la siguientes paginas planteo, el mismo problema pero ahora trabajando con My Sql, o su parte Visual de

MySQL Front

.Lo que debemos de considerar que el trabajo con

My sql

es mas rápido que eltrabajo con

Ms Sql Server

. Por lo antes ya expuesto sobre conexión directa e indirecta.

Para la gente del mundo Windows, JDBC es para Java lo que ODBC es para Windows. Windows en general no sabe nada acerca de las bases de datos, pero define el estándar ODBC consistente en un conjunto de primitivas que cualquier driver o fuente ODBC debe ser capaz de entender y manipular. Los programadores que a su vez deseen escribir programas para manejar bases de datos genéricas en Windows utilizan las llamadas ODBC.

Con JDBC ocurre exactamente lo mismo: JDBC es una especificación de un conjunto de clases y métodos de operación que permiten a cualquier programa Java acceder a sistemas de bases de datos de forma homogénea. Lógicamente, al igual que ODBC, la aplicación de Java debe tener acceso a un driver JDBC adecuado. Este driver es el que implementa la funcionalidad de todas las clases de acceso a datos y proporciona la comunicación entre el API JDBC y la base de datos real.

La necesidad de JDBC, a pesar de la existencia de ODBC, viene dada porque ODBC es un interfaz escrito en lenguaje C, que al no ser un lenguaje portable, haría que las aplicaciones Java también perdiesen la portabilidad. Y además, ODBC tiene el inconveniente de que se ha de instalar manualmente en cada máquina; al contrario que los drivers JDBC, que al estar escritos en Java son automáticamente instalables, portables y seguros.

Toda la conectividad de bases de datos de Java se basa en sentencias SQL, por lo que se hace imprescindible un conocimiento adecuado de SQL para realizar cualquier clase de operación de bases de datos. Aunque, afortunadamente, casi todos los entornos de desarrollo Java ofrecen componentes visuales que proporcionan una funcionalidad suficientemente potente sin necesidad de que sea necesario utilizar SQL, aunque para usar directamente el JDK se haga imprescindible. La especificación JDBC requiere que cualquier driver JDBC sea compatible con al menos el nivel «de entrada» de ANSI SQL 92 (ANSI SQL 92 Entry Level).

ACCESO DE JDBC A BASES DE DATOS

El API JDBC soporta dos modelos diferentes de acceso a Bases de Datos, los modelos de dos y tres capas.

Modelo de dos capas

Este modelo se basa en que la conexión entre la aplicación Java o el applet que se ejecuta en el navegador, se conectan directamente a la base de datos.

Esto significa que el driver JDBC específico para conectarse con la base de datos, debe residir en el sistema local. La base de datos puede estar en cualquier otra máquina y se accede a ella mediante la red. Esta es la configuración de típica Cliente/Servidor: el programa cliente envía instrucciones SQL a la base de datos, ésta las procesa y envía los resultados de vuelta a la aplicación.

Modelo de tres capas

En este modelo de acceso a las bases de datos, las instrucciones son enviadas a una capa intermedia entre Cliente y Servidor, que es la que se encarga de enviar las sentencias SQL a la base de datos y recoger el resultado desde la base de datos. En este caso el usuario no tiene contacto directo, ni a través de la red, con la máquina donde reside la base de datos.

Este modelo presenta la ventaja de que el nivel intermedio mantiene en todo momento el control del tipo de operaciones que se realizan contra la base de datos, y además, está la ventaja adicional de que los drivers JDBC no tienen que residir en la máquina cliente, lo cual libera al usuario de la instalación de cualquier tipo de driver.

DEFINICION DE JDBC

JDBC es una API de Java para ejecutar sentencias SQL. (Como punto de interés, JDBC es nombre de una marca registrada y no es un acrónimo, a pesar de todo, JDBC es a menudo interpretado como “Java DataBase Connectivity”). Consta de un conjunto de clases e interfaces escrito en lenguaje de programación Java. Usando JDBC es fácil enviar sentencias SQL a virtualmente cualquier base de datos relacional. En otras palabras, con la API JDBC no es necesario escribir un programa para acceder a una base de datos tipo Access, otro programa para acceder a una base de datos tipo Oracle y así para cada tipo de base de datos. Uno puede escribir un solo programa usando la API JDBC y el programa será capaz de enviar sentencias SQL a la base de datos apropiada. Y, con una aplicación escrita en Java, uno no tiene por qué preocuparse por escribir diferentes programas para diferentes plataformas. La combinación de JDBC permite al programador escribir una vez y ejecutar en cualquier sitio. 74 Informática III Java, siendo robusto, seguro, fácil de usar, fácil de entender, y automáticamente descargable en una red, es un excelente lenguaje base para aplicaciones con bases de datos. Lo que es necesario es una forma para que las aplicaciones Java puedan entenderse con bases de datos de diferentes tipos. JDBC es el mecanismo para hacer esto. JDBC extiende lo que puede hacerse con Java. Por ejemplo, con Java y la API de JDBC, es posible publicar una página web que usa información obtenida de una base de datos remota. O una compañía puede usar JDBC para conectar todos sus empleados (incluso si estos están usando un conglomerado de máquinas Windows, Macintosh y UNÍS) a una o más bases de datos internas vía una intranet. De una forma simple, JDBC posibilita hacer tres cosas:

• Establecer una conexión con una base de datos

• Enviar sentencias SQL

• Procesar los resultados

TIPOS

Existen 4 tipos de driver JDBC que se detallan a continuación.

Dependiendo del DBMS y del tipo de acceso a la base de datos que se utilice, puede ser necesario obtener uno u otro tipo de driver JDBC. Generalmente se utilizan los drivers de tipo 4, que se presentan a continuación junto con otros tipos de driver.

Los números de tipos de driver corresponden a una numeración que fijó SUN.

Tipo 1: Java -> ODBC

Esta arquitectura, tiene como ventaja importante que permite la utilización de drivers ODBC existentes, pero la desventaja de que hay que instalarlos en cada máquina, así como el cliente de DBMS.

De esta forma, en el cliente se requiere:

· DRIVERS JDBC

· DRIVERS ODBC (se crea un Data Source con la información de conexión)

· CLIENTE DBMS

La aplicación GeneXus-Java se comunica con los DRIVERS JDBC. A los DRIVERS JDBC se les configura un parámetro para indicar que la conexión es a cierto Data Source. Y finalmente con la información definida en el Data Source, se establece la conexión del cliente con el Servidor Manejador de Base de Datos (DBMS).

Las implementaciones actuales de estos drivers no son muy fiables, por lo que no se recomienda su utilización en ambientes de producción. Sin embargo, existe un caso por el cual utilizar el driver tipo 1: algunas versiones de AS/400 no soportan los dirvers JDBC, de modo que la única forma de implementar una aplicación Java en 2 capas, en esos casos, sería mediante este tipo de driver llamado también Bridge JDBC-ODBC.

Tipo 2: Java -> Protocolo DBMS

Con esta implementación, en el cliente se tienen los DRIVERS JDBC que se comunican directamente (en forma nativa) con el CLIENTE Oracle, Sybase, Informix, DB2, o cualquier otro DBMS.

De esta forma, entonces, al igual que el driver de tipo 1, este también requiere que se instale en cada máquina cliente, los DRIVERS JDBC y CLIENTE DBMS.

En general los drivers tipo 2, también llamados Native-API Partly-Java,se comunican muy rápido con la base de datos, siendo en teoría, los más performantes. Salvo por ésto, este tipo de driver no presenta demasiadas ventajas con respecto a las otras alternativas.

Tipo 3: Java -> Servidor JDBC

Esta clase de driver traduce llamadas JDBC en un protocolo de red independiente del DBMS y luego, a un protocolo de DBMS.

Un Servidor JDBC, realiza la tarea de middleware, siendo capaz de conectar un cliente Java a diferentes bases de datos.

La implementación del Servidor JDBC se realiza mediante la instalación de un software que sabe “escuchar” los requerimientos del CLIENTE JDBC y traducirlos a llamadas nativas para los DBMSs.

Una ventaja que posee el driver tipo 3, también conocido como net-protocol all-Java, es que no requiere instalación en los clientes, según el DBMS. Como contrapartida, este driver requiere la instalación del Servidor JDBC.

Merant DataDirect SequeLink Java Edition es un driver de tipo 3 que se ha probado para SQL Server y Oracle.

Nota: Para ejecutar Applets, en 2 capas, si se utiliza el driver tipo 3, el Servidor JDBC deberá encontrarse en el mismo host que el Servidor Web, por ser el Servidor JDBC el que resolvería la conexión. En este caso, sería posible efectuar conexión con un DBMS que no se encuentre en el mismo host que el Servidor Web.

Tipo 4: Java -> DBMS

El driver tipo 4 convierte llamadas JDBC directamente en el protocolo de red usado por el DBMS. Esto permite llamadas directas desde la máquina del cliente al servidor del DBMS y es una solución práctica para el acceso a Intranets.

Requieren más código, por lo que si se usa en 2 capas hay que bajar más código al cliente, y la performance suele ser algo menor que la de los otros drivers (esto puede depender mucho del driver, de la cantidad de conexiones simultaneas, etc). De todas formas, este es el tipo de driver más común, y el que se usa más en general.

Dado que muchos de estos protocolos son propietarios, los proveedores de bases de datos son la principal fuente de este tipo de driver.

Algunos ejemplos son:

· I-net Software

· WebLogic jDriver

· AsToolBox

· Merant

El driver tipo 4, también denominado native-protocol all-Java, no requiere instalación en los clientes, según el DBMS.

Nota: Para ejecutar Applets, en 2 capas, si se utiliza el driver tipo 4, el DBMS deberá encontrarse en el mismo host que el Servidor Web pues no se permite a un Applet establecer una conexión con otra máquina que no sea el servidor de donde provino.

USO DE LAS CLASES CONNECTION, DRIVERMANAGER

Connection

Un objeto Connection representa una conexión a una base de datos. Una sesión con una conexión incluye las sentencias SQL que son ejecutadas y los resultados que son devueltos a través de dicha conexión. Una misma aplicación puede tener una o más conexiones con una sola base de datos o puede tener conexiones con varias bases de datos diferentes. La forma estándar de establecer una conexión con una base de datos es llamando al método DriverManager.getConnection. Este método toma como parámetro una cadena de caracteres que contiene una URL. La clase DriverManage trata de localizar el driver que pueda conectar con la base de datos representada por esa URL. El siguiente código ejemplifica cómo abrir una conexión a una base de datos localizada en la URL “jdbc:odbc:wombat”: String url = jdbc:odbc:wombat; Connection con = DriverManager.getConnection(url); Una URL de JDBC facilita una forma de identificar una base de datos de forma que el driver apropiado la reconozca y establezca una conexión con ella. La sintaxis estándar para URLs de JDBC es la siguiente: Una URL de JDBC tiene tres partes separadas por dos puntos: jdbc es el protocolo. El protocolo en una URL JDBC es siempre jdbc. subclasses subclasses Connection Statement PreparedStatement CallableStatement ResultSet Data Types createStatement prepareStatement prepareCall executeQuery executeQuery executeQuery getXXX getMoreResults getResultSet 78 Informática III es usualmente el driver o el mecanismo de conectividad de la base de datos, el cual debe ser soportado por uno o más drivers. Un ejemplo de un subprotocolo es odbc, que ha sido reservado para URLs que especifican fuentes de datos de ODBC. Por ejemplo, para acceder a una base de datos a través del Puente JDBC-ODBC se usará una URL como la siguiente: jdbc:odbc:fred donde el subprotocolo es odbc y el subnombre es fred, una fuente de datos ODBC. es una forma de identificar la base de datos. Puede variar dependiendo del subprotocolo y puede tener un subsubnombre con cualquier sintaxis interna que el programador del driver haya elegido. La función del es dar la suficiente información para localizar la base de datos.

Clase drivermanager

Implementa la capa de gestión de JDBC, y trabaja como intermediaria entre el usuario y los drivers. Guarda la lista de los drivers que están disponibles y establece la conexión entre la base de datos y el driver apropiado. Además la clase DriverManager se ocupa de cosas cómo gestionar los límites de tiempo de ‘login’ en el driver y de la salida de los mensajes de traza y log.

Para aplicaciones simples, el único método en esta clase que necesita un programador general para su uso directamente es DriverManager.getConnection. Como su nombre indica, este método establece una conexión con la base de datos. JDBC permite al usuario llamar a los métodos de DriverManager getDriver, getDrivers y registerDriver así como al método de Driver connect, pero en la mayoría de los casos es preferible dejar que la clase DriverManager gestione los detalles al establecer la conexión.

Mantenimiento de la lista de drivers disponibles.

La clase DriverManager mantiene una lista de clases disponibles que han sido registrados mediante el método DriverManager.registerDriver. Todas las clases Driver deben escribirse con una sección estática que cree una instancia de la clase y luego la registre en la clase DriverManager cuando se cargue. Además el usuario normalmente no debería llamar a DriverManager.registerDriver directamente; debería llamarse automáticamente por el driver cuando esté se carga,. Una clase Driver se carga, y por tanto se registra, de dos formas diferentes:

1 Mediante una llamada al método Class.forName. Este carga explícitamente la clase driver. Dado que no depende de ningún ‘setup’ externo, esta forma de cargar drivers es la recomendada. El siguiente código carga la clase acme.db.Driver:

Class.forName("acme.db.Driver");

Si acme.db.Driver se ha escrito para que al cargar produzca una instancia y llame al método DriverManager.registerDriver con esta instancia como argumento (es lo que debería hacer), entonces este estará en la lista de drivers disponibles para efectuar la conexión.

2 Mediante la adición del driver a la propiedad jdbc.drivers de java.lang.System- Esta es una lista de nombres de clases de drivers, separadas por dos puntos, que es la que carga la clase DriverManager. Cuando la clase DriverManager se inicializa, mira en la propiedad jdbc.drivers, y si el usuario ha introducido uno o más drivers, la clase DriverManager intenta cargarlos. El siguiente código ilutsra como un programador debería introducir estas tres clases en ~/.hotjava/properties

jdbc.drivers=foo.bah.Driver:wombat.sql.Driver:bad.test.ourDriver;

La primera llamada al método DriverManager hará que estos drivers se carguen automáticamente.

Notese que en esta segunda manera de cargar los drivers es necesario una preparación del entorno que es persistente. Si existe alguna duda sobre esto es preferible y más seguro llamar al método Class.forName para cargar explicitamente cada driver. Este es también el método que se usa para traer un driver particular puesto que una vez que la clase DriverManager ha sido inicializada no chequeará la lista de propiedades jdbc.drivers.

En ambos casos, es responsabilidad de la clase Driver recién cargada registrarse a si misma mediante una llamada a DriverManager.registerDriver. Como se ha mencionado anteriormente, esto debería hacerse automáticamente al cargar la clase.

Por razones de seguridad, la capa de gestión de JDBC guardará traza de que clases de cargadores provee cada driver. Entonces cuando la clase DriverManager abre una conexión solo usará los drivers que vienen desde el sistema de ficheros local o desde las mismas clases cargadoras como el código que solicita la conexión.

Establecer una conexión

Una vez que la clase Driver ha sido cargada y registrada con la clase DriverManager, se está en condiciones de establecer la conexión con la base de datos. La solicitud de la conexión se realiza mediante una llamada al método DriverManager.getConnection, y DriverManager testea los drivers regsitrados para ver si puede establecer la conexión.

A veces puede darse el caso de que más de un driver JDBC pueda establecer la conexión para una URL dada. Por ejemplo, cuando conectamos con una base de datos remota, podría ser posible usar un driver puente JDBC-ODBC, o un driver JDBC de protocolo genérico de red, o un driver suministrado por el vendedor.

En tales casos, el orden en que los driver son testeados es significante porque DriverManager usará el primer driver que encuentre que pueda conectar con éxito a la base de datos.

Primero DriverManager intenta usar cada driver en el orden en que ha sido registrado ( los drivers listados en la propiedad jdbc.drivers son siempre los registrados primero). Saltará cualquier driver con código ‘untrusted’, a menos que se cargue desde el mismo código fuente que el código que intenta abrir la conexión.

Testea los drivers mediante la llamada al método Driver.connect cada uno por turno, pasándole como argumento la URL que el usuario ha pasado originalmente al método DriverManager.getConnection. El primer driver que reconozca la URL realiza la conexión.

Una primera ojeda puede parecer insuficiente, pero son necesarias solo unas pocas llamadas a procedimientos y comparaciones de cadena por conexión puesto que no es probable que haya docenas de drivers se carguen concurrentemente.

es usualmente el driver o el mecanismo de conectividad de la base de datos, el cual debe ser soportado por uno o más drivers. Un ejemplo de un subprotocolo es odbc, que ha sido reservado para URLs que especifican fuentes de datos de ODBC. Por ejemplo, para acceder a una base de datos a través del Puente JDBC-ODBC se usará una URL como la siguiente: jdbc:odbc:fred donde el subprotocolo es odbc y el subnombre es fred, una fuente de datos ODBC. es una forma de identificar la base de datos. Puede variar dependiendo del subprotocolo y puede tener un subsubnombre con cualquier sintaxis interna que el programador del driver haya elegido. La función del es dar la suficiente información para localizar la base de datos.

EJEMPLOS

En el siguiente ejemplo, el código muestra establece varias propiedades de conexión en la URL de conexión y, a continuación, llama al método getConnection de la clase DriverManager para devolver un objeto SQLServerConnection.

Después, el código muestra usa el método createStatement del objeto SQLServerConnection para crear un objeto SQLServerStatement y, a continuación, se llama al método executeQuery para ejecutar la instrucción SQL.

Finalmente, el ejemplo usa el objeto SQLServerResultSet devuelto por el método executeQuery para procesar una iteración mediante los resultados devueltos por la instrucción SQL.

import java.sql.*;

public class connectURL {

   public static void main(String[] args) {

      // Create a variable for the connection string.

      String connectionUrl = "jdbc:sqlserver://localhost:1433;" +

         "databaseName=AdventureWorks;user=UserName;password=*****";

      // Declare the JDBC objects.

      Connection con = null;

      Statement stmt = null;

      ResultSet rs = null;

      try {

         // Establish the connection.

         Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");

         con = DriverManager.getConnection(connectionUrl);

         // Create and execute an SQL statement that returns some data.

         String SQL = "SELECT TOP 10 * FROM Person.Contact";

         stmt = con.createStatement();

         rs = stmt.executeQuery(SQL);

         // Iterate through the data in the result set and display it.

         while (rs.next()) {

            System.out.println(rs.getString(4) + " " + rs.getString(6));

      // Handle any errors that may have occurred.

      catch (Exception e) {

         e.printStackTrace();

      finally {

         if (rs != null) try { rs.close(); } catch(Exception e) {}

         if (stmt != null) try { stmt.close(); } catch(Exception e) {}

         if (con != null) try { con.close(); } catch(Exception e) {}

RESUMEN

Una capa de acceso a datos o DAL en los programas informáticos, es una capa de un programa informático que proporciona acceso simplificado a los datos almacenados en el almacenamiento persistente de algún tipo, tal como una entidad-relación de base de datos.

La creación de reflejo de la base de datos, implementada para cada base de datos, conserva una copia de una base de datos de producción de SQL Server en un servidor en espera.

La base de datos de producción se llama base de datos principal y la copia en espera se llama base de datos reflejada.

Si el servidor principal genera un error, el servidor reflejado puede convertir su base de datos en la base de datos principal a través de un proceso denominado conmutación por error.

Por ejemplo, Partner_A y Partner_B son dos servidores asociados, con la base de datos principal inicialmente en Partner_A como servidor principal y la base de datos reflejada en Partner_B como servidor reflejado.

Con la API JDBC no es necesario escribir un programa para acceder a una base de datos tipo Access, otro programa para acceder a una base de datos tipo Oracle y así para cada tipo de base de datos.

Uno puede escribir un solo programa usando la API JDBC y el programa será capaz de enviar sentencias SQL a la base de datos apropiada.

JDBC extiende lo que puede hacerse con Java.

Por ejemplo, con Java y la API de JDBC, es posible publicar una página web que usa información obtenida de una base de datos remota.

La clase Driver Manager trata de localizar el driver que pueda conectar con la base de datos representada por esa URL. El siguiente código ejemplifica como abrir una conexión a una base de datos localizada en la URL jdbc:odbc:wombat : String url = jdbc:odbc:wombat; Connection con = Driver Manager.get Connection ; Una URL de JDBC facilita una forma de identificar una base de datos de forma que el driver apropiado la reconozca y establezca una conexión con ella.

La sintaxis estándar para URL de JDBC es la siguiente: Una URL de JDBC tiene tres partes separadas por dos puntos: jdbc es el protocolo.

El protocolo en una URL JDBC es siempre jdbc.

Subclasses Connection Statement Prepared Statement Callable Statement Result Set Data Types create Statement prepare Statement prepare Call execute Query execute Query execute Query get XXX get More Results get Result Set 78 Informatica III es usualmente el driver o el mecanismo de conectividad de la base de datos, el cual debe ser soportado por uno o más drivers.

JDBC permite al usuario llamar a los métodos de Driver Manager get Driver, get Drivers y register Driver asi como al método de Driver connect, pero en la mayoria de los casos es preferible dejar que la clase Driver Manager gestione los detalles al establecer la conexión.

La clase Driver Manager mantiene una lista de clases disponibles que han sido registrados mediante el método Driver Manager. register Driver.

SUMMARY

A data access layer or DAL in computer software, is a layer of software that provides simplified access to the data stored in persistent storage of some access, as an entity-relationship database.

Mirroring of the database, implemented for each database retains a copy of a production database SQL Server on a standby server.

The production database is called primary database and the standby copy is called mirror database.

If the primary server fails, the mirror server can turn your database into the principal database through a process called failover.

For example, Partner_A and Partner_B are two associated servers, initially based on primary data in Partner_A as the primary server and the mirror database in Partner_B as a mirror server.

With the JDBC API is not necessary to write a program to access a database type Access database, another program to access an Oracle data type and so for each type of database.

One can write a single program using the JDBC API and the program will be able to send SQL statements to the appropriate database.

JDBC extends what can be done with Java.

For example, Java and JDBC API, you can publish a Web page that uses information obtained from a remote database.

The Driver Manager class tries to locate the driver that can connect to the database represented by that URL. The following code illustrates how to open a connection to a database located at the URL jdbc: odbc: wombat: String url = jdbc: odbc: wombat; Connection con = Driver Manager.get Connection; A JDBC URL provides a way of identifying a database so that the appropriate driver will recognize and establish a connection with it.

The standard syntax for JDBC URL is: A JDBC URL has three parts separated by colons: jdbc is the protocol.

The protocol in a JDBC URL is always jdbc.

Subclasses Connection Statement Prepared Statement Callable Statement Result Set Data Types create Statement prepared Statement prepared Call Execute Query Execute Query Execute Query get XXX get More Results get Result September 78 Informatica III is usually the driver or the connectivity mechanism of the database, the which it must be supported by one or more drivers.

JDBC allows the user to call methods Driver Manager get Driver, get Drivers and register Driver as well as the method of Driver connect, but in most cases it is preferable to let the Driver Manager class manage the details to establish the connection.

The Driver Manager class maintains a list of available classes that have been registered by the Driver Manager method. Driver register.

RECOMENDACIONES

Evitar consultas SQL SELECT *

SELECT * FROM... es una forma muy habitual de establecer una consulta en SQL. Sin embargo, muchas veces no es necesario consultar todos los campos. Para cada columna que hay que devolver, el controlador JDBC tiene que hacer el trabajo adicional de enlazar y devolver la fila. Aún en el caso de que la aplicación no llegue a utilizar nunca una columna concreta, el controlador JDBC debe tenerla presente y reservar espacio por si se utiliza. Esta cuestión no supone una actividad general significativa si son pocas las columnas que no se utilizan de las tablas. Sin embargo, si son numerosas las columnas no utilizadas, la actividad general puede llegar a ser significativa. En tal caso, sería mejor listar individualmente las columnas que a la aplicación le interesa consultar, como en este ejemplo:

SELECT COL1, COL2, COL3 FROM...

Utilizar getXXX(int) en vez de getXXX(String)

Utilice los métodos getXXX de ResultSet que toman valores numéricos, en vez de las versiones que toman nombres de columna. Si bien la libertad que supone utilizar nombres de columna en vez de constantes numéricas parece ser una ventaja, la base de datos propiamente dicha solo sabe manejar los índices de las columnas. Por ello, cada vez que se llama a un método getXXX utilizando el nombre de una columna, el controlador JDBC lo debe resolver para que el método se pueda pasar a la base de datos. Normalmente, a los métodos getXXX se les suele llamar dentro de bucles que se pueden ejecutar millones de veces, y ello provocaría rápidamente la acumulación de la pequeña actividad general que supone la resolución de cada uno de los nombres de columna.

Evitar llamadas a getObject para tipos Java primitivos

Cuando de la base de datos se obtienen valores de tipos primitivos (int, long, float, etc.), es más rápido utilizar el método get específico del tipo primitivo (getInt, getLong, getFloat) que utilizar el método getObject. La llamada a getObject realiza el trabajo de obtener el tipo primitivo y luego crea un objeto para devolverlo. Normalmente, esto se hace en los bucles, lo que supone crear millones de objetos de corta vida. Si se emplea getObject para los mandatos de primitivos, existe el inconveniente adicional de que se activa con frecuencia el colector de basura, lo que aún reduce más el rendimiento.

Utilizar el nivel de compromiso correcto para la aplicación

JDBC proporciona varios niveles de compromiso, que determinan cómo se afectan mutuamente varias transacciones con respecto al sistema.El valor predeterminado es utilizar el nivel de compromiso más bajo. Esto implica que las transacciones pueden ver parte del trabajo de cada una de ellas a través de los límites del compromiso. También implica la posibilidad de que se produzcan ciertas anomalías de base de datos. Algunos programadores aumentan el nivel de compromiso para no tener que preocuparse de si se produce este tipo de anomalías. Tenga en cuenta que los niveles de compromiso más altos implican que la base de datos se cuelgue en bloqueos más bastos. Esto limita la cantidad de concurrencia que el sistema puede tener, disminuyendo en gran medida el rendimiento de algunas aplicaciones. A menudo, las condiciones de anomalía no se pueden producir debido en primer lugar al diseño de la aplicación. Tómese su tiempo para comprender lo que está tratando de lograr y limite el nivel de aislamiento de las transacciones al mínimo que pueda emplear sin arriesgarse.

Utilizar SQL eficaz

Dado que JDBC se construye encima de SQL, cualquier técnica que mejore la eficacia de SQL mejorará también la eficacia de JDBC. Por tanto, JDBC se beneficia de las consultas optimizadas, de los índices acertadamente elegidos y de otros aspectos que mejoren el diseño de SQL.

onsiderar la posibilidad de utilizar la agrupación de sentencias PreparedStatement

La agrupación de sentencias funciona de manera muy parecida a la agrupación de conexiones. En vez de poner en la agrupación tan solo las conexiones, en ella se pone un objeto que contenga la conexión y las sentencias PreparedStatement. Luego se recupera ese objeto y se accede a la sentencia concreta que se desea utilizar. Esta estrategia puede aumentar drásticamente el rendimiento.

Utilizar procedimientos almacenados

El uso de procedimientos almacenados está permitido en Java. El rendimiento de los procedimientos almacenados puede ser mayor al permitir que el controlador JDBC ejecute SQL estático en vez de SQL dinámico. No cree procedimientos almacenados para cada sentencia SQL individual que ejecute en el programa. No obstante, cuando sea posible, cree un procedimiento almacenado que ejecute un grupo de sentencias SQL.

Cerrar explícitamente los recursos JDBC cuando ya no se necesitan

La aplicación debe cerrar explícitamente los objetos ResultSet, Statement y Connection cuando ya no se necesitan. Así se hace una limpieza de recursos del modo más eficaz posible, y el rendimiento puede aumentar. Además, los recursos de base de datos que no se cierran de manera explícita pueden provocar fugas de recursos, y los bloqueos de base de datos se pueden prolongar más de lo debido. Ello puede producir anomalías de aplicación o reducir la concurrencia en las aplicaciones.

CONCLUSIÓN

Utilizar JDBC implica construir y ejecutar repetidamente sentencias SELECT, INSERT, UPDATE y DELETE.

Por lo tanto:

Creamos mucho código que además estará muy acoplado a la base de datos que estemos usando.

Tenemos que iterar manualmente sobre las propiedades de objetos como ResultSet cada vez que consultemos algo en la base de datos.

A su vez es muy costoso crear PreparedStatements en cada caso por el mismo motivo de las iteraciones, pero en este caso sería sobre los POJO’s para Inserts, Updates y Deletes.

Tendríamos que gestionar manualmente el orden de las inserciones, actualizaciones y borrados para que no hubiese problemas con la integridad referencial.

APRECIACIÓN DEL GRUPO

Bueno hemos comprendido según este trabajo que con la ayuda de JDBC, la habilidad de java para integrarse con DBMS comerciales y su naturaleza orientada al manejo de la red, es posible crear un ambiente ideal tipo cliente-servidor

Tambien Hemos comprendido que el API JDBC hace posible la realización de las siguientes tareas, Establecer una conexión con una base de datos. Enviar sentencias SQL. Manipular los datos.Procesar los resultados de la ejecución de las sentencias.

GLOSARIO

DAL (data access layer). capa de acceso de datos

DAO (Data Access Object). Acceso a datos de objetos

Driver : es un programa que controla un dispositivo. Cada dispositivo, ya sea una impresora, un teclado, etc., debe tener un programa controlador.

JDBC: Java Database Connectivity.

API: La interfaz de programación de aplicaciones, Se trata del conjunto de llamadas a ciertas bibliotecas que ofrecen acceso a ciertos servicios desde los procesos y representa un método para conseguir abstracción en la programación, generalmente (aunque no necesariamente) entre los niveles o capas inferiores y los superiores del software.

ODBC: Open DataBase Connectivity , 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.

DBMS: Los sistemas de gestión de bases de datos (SGBD) del inglés "Database Management System" (DBMS) son un tipo de software muy específico, dedicado a servir de interfaz entre la base de datos, el usuario y las aplicaciones que la utilizan.

Middleware :es un software que asiste a una aplicación para interactuar o comunicarse con otras aplicaciones, o paquetes de programas, redes, hardware y/o sistemas operativos.

LINCOGRAFIA

http://library.gxtechnical.com/gxdlsp/pub/genexus/java/docum/manuals/8.0/mjavab2-2.htm

http://www.euskalnet.net/jaoprogramador/j2ee/JDBC/jdbc16.htm

https://msdn.microsoft.com/es-es/library/aa342339(v=sql.110).aspx

https://es.wikipedia.org/wiki/Capa_de_acceso_a_datos

http://profesores.elo.utfsm.cl/~agv/elo330/2s09/lectures/JDBC/JDBC.html

http://www.juntadeandalucia.es/servicios/madeja/contenido/subsistemas/arquitectura/capa-acceso-datos

Para más ayuda que te podemos brindar te dejamos el link de nuestra página donde podrás encontrar las diapositivas de este trabajo…

http://es.slideshare.net/ErlinDarwinHerreraCieza/jdbc-66099067

Espero sea de su Agrado.

Desarrollo de Software l

viernes, 16 de septiembre de 2016

TEMA: JDBC

USAR LA CREACIÓN DE REFLEJO DE LA BASE DE DATOS (JDBC)

Utilizar getXXX(int) en vez de getXXX(String)

Evitar llamadas a getObject para tipos Java primitivos

Utilizar el nivel de compromiso correcto para la aplicación

Utilizar SQL eficaz

onsiderar la posibilidad de utilizar la agrupación de sentencias PreparedStatement

Utilizar procedimientos almacenados

Cerrar explícitamente los recursos JDBC cuando ya no se necesitan

CONCLUSIÓN

1 comentario:

Bloger