Base de datos II - udb.edu.sv · Base de datos II. Guía 3 5 Tema: Entornos WEB/Introducción...

2

Base de datos II Facultad de Ingeniería.

Escuela de computación.

Base de datos II. Guía 3

3

Este manual ha sido elaborado para orientar al estudiante de Bases de datos II en el desarrollo de sus prácticas de laboratorios, haciendo uso de este antes, durante y después de la práctica, de tal forma que ofrece un método facilitador en su proceso de enseñanza/aprendizaje durante esta asignatura. En el desarrollo de esta asignatura se ha designado realizar las prácticas en 16 sesiones semanales de laboratorios, los que incluyen 11 prácticas, dos parciales y un proyecto final durante los cuales, el estudiante aplicará los conceptos y las técnicas fundamentalmente necesarias para el dominio de programas para el uso, configuración y administración de ORACLE. Todas las guías de laboratorio están estructuradas de la siguiente forma: - Objetivos - Materiales y equipos - Introducción teórica - Procedimiento - Bibliografía - Hoja de evaluación( En caso de que la actividad sea evaluada ) La asignatura Base de Datos II,está dividida en cinco unidades durante el ciclo. La unidad 1 Administración avanzada de bases de datos tendrá 3 laboratorios prácticos, la unidad 2 Arquitectura de bases de datos tendrá 2 laboratorios prácticos y la unidad 3 Diseño de un Datawarehuse tendrá 4 laboratorios prácticos. La unidad 4 Minería de datos tendrá 3 laboratorios prácticos. Y finalmente la Unidad 5 Calidad de datos y auditoria de bases de datos tendrá 3 laboratorios prácticos.

Introducción

Base de datos II, Guía 4

4

Pág

Contenido ----------------------------------------------------------------------------------------------- 5

Objetivos ------------------------------------------------------------------------------------------------ 5

Materiales y equipos --------------------------------------------------------------------------------- 5

Introducción teórica ---------------------------------------------------------------------------------- 5

Procedimiento ----------------------------------------------------------------------------------------- 13

Investigación ------------------------------------------------------------------------------------------- 14

Bibliografía ---------------------------------------------------------------------------------------------- 14

Facultad: Ingeniería. Escuela: Computación. Asignatura: Base de datos II.

Tabla de Contenido

Guía 4. Entornos WEB/Introducción PL/SQL

Guía 6

a 1


5

Tema: Entornos WEB/Introducción PL/SQL

En la presente guía de laboratorio se desarrollaran ejercicios básicos de conexión con una base de datos Oracle, utilizando Java como lenguaje de desarrollo y utilizando el API de conexión JDBC THIN. Así mismo se presentarán conceptos de PL/SQL y se desarrollaran ejercicios prácticos para ejemplificar dichos conceptos. Conocer los requisitos de conexión a una base de datos. Conocer el funcionamiento del driver JDBC THIN. Realizar un procedimiento almacenado. Realizar un

ORACLE 11g.

Virtual de Windows 2003 server.

JDK.

Netbeans

Servidor Java.

JDBC JDBC es un conjunto de clases e interfaces Java que permiten la manipulación de sentencias SQL de una fuente de datos (base de datos). La interface Java (API de JDBC) proporciona a las aplicaciones Java un mecanismo estándar e independiente de la plataforma para el acceso a la mayoría de las bases de datos existentes.

Objetivo Específico

Materiales y Equipo

Introducción Teórica

Contenidos


6

La API de JDBC define un conjunto de clases e interfaces que proporcionan toda la funcionalidad que el acceso a base de datos requiere, tal como la ejecución de consultas SQL o el tratamiento de los resultados. Cada fabricante de base de datos se encargara de proporcionar un driver JDBC específico para su base de datos. Las actividades básicas de programación que se utilizan en JDBC:

Conectarse a una fuente de datos, como una base de datos.

Enviar Querys y Updates a la base de datos.

Recuperar y procesar los resultados obtenidos de la base de datos en respuesta al Query obtenido.

Todo el conjunto de clases e interfaces que constituyen JDBC se encuentran dentro del paquete java.sql principalmente pero también existe el paquete javax.sql. Un driver JDBC es una implementación de varias interfaces especificadas en los paquetes java.sql y javax.sql. Es una capa de software intermediario que traduce las llamadas JDBC a las APIs específicas de cada vendedor. PL/SQL El lenguaje de programación de Oracle, llamado PL/SQL, es un lenguaje portable, procedural y de transacción muy potente y de fácil manejo, con las siguientes características fundamentales: 1. Incluye todos los comandos de SQL: - SELECT - INSERT - UPDATE - DELETE 2. Es una extensión de SQL, ya que este es un lenguaje no completo dado que no incluye las herramientas clásicas de programación. Por eso, PL/SQL amplia sus posibilidades al incorporar las siguientes sentencias: IF ... THEN ... ELSE ... ENDIF - Ciclos FOR ... LOOP WHILE ... LOOP 3. Incorpora opciones avanzadas en: - Control y tratamiento de errores llamado excepciones. - Manejo de cursores. - Variedad de procedimientos y funciones empaquetadas incorporadas en el módulo - SQL*Forms para la programación de disparadores (Trigger) y procedimientos del usuario.


7

- (Procedure). Procedimientos Almacenados Un procedimiento es un subprograma que ejecuta una acción específica y que no devuelve ningún valor. Un procedimiento tiene un nombre, un conjunto de parámetros (opcional) y un bloque de código.

El uso de OR REPLACE permite sobrescribir un procedimiento existente. Si se omite, y el procedimiento existe, se producira, un error. La sintaxis es muy parecida a la de un bloque anónimo, salvo porque se reemplaza la sección DECLARE por la secuencia PROCEDURE ... IS en la especificación del procedimiento. Debemos especificar el tipo de datos de cada parámetro. Al especificar el tipo de dato del parámetro no debemos especificar la longitud del tipo. Los parámetros pueden ser de entrada (IN), de salida (OUT) o de entrada salida (IN OUT). El valor por defecto es IN, y se toma ese valor en caso de que no especifiquemos nada. Una vez creado y compilado el procedimiento almacenado podemos ejecutarlo. Si el sistema nos indica que el procedimiento se ha creado con errores de compilación podemos ver estos errores de compilación con la orden SHOW ERRORS en SQL *Plus. Existen dos formas de pasar argumentos a un procedimiento almacenado a la hora de ejecutarlo (en realidad es valido para cualquier subprograma). Estas son: •Notación posicional: Se pasan los valores de los parametros en el mismo orden en que el procedure los define. •Notación nominal: Se pasan los valores en cualquier orden nombrando explícitamente el parámetro. Manejo de cursores. El conjunto de filas resultantes de una consulta con la sentencia SELECT, puede estar compuesto por ninguna, una o varias filas, dependiendo de la condición que define la


8

consulta. Para poder procesar individualmente cada fila de la consulta debemos definir un cursor (que es un área de trabajo de memoria) que contiene los datos de las filas de la tabla consultada por la sentencia SELECT. Los pasos para el manejo de cursores son:

1. Definir el cursor, especificando la lista de parámetros con sus 2. correspondientes tipos de 3. datos y estableciendo la consulta a realizar con la sentencia SELECT. 4. Abrir el cursor para inicializarlo, siendo esté el momento en que se realiza la 5. consulta. 6. Leer una fila del cursor, pasando sus datos a las variables locales definidas a tal 7. efecto. 8. Repetir el proceso fila a fila hasta llegar a la última. 9. Cerrar el cursor una vez que se terminó de procesar su última fila.

Disparadores Un disparador (o trigger) es un procedimiento almacenado asociado a una tabla que se ejecuta al realizar una operación “básica” (INSERT, un DELETE o un UPDATE) sobre esta. La operación básica que despierta al trigger es conocida como sentencia disparadora. La ejecución del disparador puede ser antes o después de llevar a cabo la sentencia disparadora. Es posible especificar condiciones adicionales para la ejecución del disparador (restrictores). Dado que una sentencia disparadora puede afectar una o más filas de una tabla, es necesario especificar si se quiere que el disparador se ejecute para cada una de las filas afectadas o para el bloque en general. Diseño de disparadores Los disparadores pueden ser utilizados para cumplir con alguna de las siguientes tareas: • Evitar la ejecución de transacciones inválidas • Garantizar el cumplimiento de restricciones de integridad • Garantizar el cumplimiento de reglas del negocio • Generar, automáticamente, valores de columnas derivadas Cuando se diseñan disparadores es necesario tomar en cuenta las siguientes consideraciones: • El disparador no debe ser utilizado para garantizar el cumplimiento de restricciones de integridad que puedan ser definidas a nivel de esquema. Por ejemplo, no tiene sentido implementar un disparador para verificar que al insertar una tupla en la tabla Empleado que su tipo debe ser ‘A’, si es administrativo, ‘O’, si es obrero o ‘D’, si es docente. Esta restricción puede garantizarse al definir el atributo tipo_empleado de la tabla Empleado. La manera de hacerlo es colocando la restricción CHECK (tipo_empleado IN (‘A’,’O’,’D’)).


9

• Hay que evitar crear disparadores recursivos. Por ejemplo, el crear un disparador que se active después de actualizar la tabla Empleado, que a su vez realiza una actualización de la tabla Empleado, provoca una ejecución recursiva del disparador que agota la memoria. • Dado que los disparadores son compilados la primera vez que se activan, se recomienda que la cantidad de instrucciones de un disparador no sea muy grande (máximo 60 líneas). De esta manera, el efecto que tiene la primera ejecución sobre el rendimiento del sistema sera menor. Si un trigger tiene demasiadas líneas es preferible incluir el código de este en un procedimiento almacenado (que se almacena ya compilado). De esta forma, el trigger puede llamar al procedimiento, reduciendo así el tiempo de compilación al momento de ejecución. • Para diseñar un trigger es necesario identificar cada uno de los elementos definidos para el (sentencia disparadora, etc). Aspectos generales en la definición de Disparadores. • Los nombres de los triggers deben ser únicos dentro de un esquema dado. Los nombres no tienen por que ser únicos con respecto a otros objetos del esquema (por ejemplo, tablas, vistas, etc.). Sin embargo, se recomienda usar nombres distintos para evitar confusiones. • Alguna de las dos, BEFORE o AFTER, debe ser utilizada en el CREATE TRIGGER. De esta manera se especifica exactamente cuando se despierta el disparador, en relación con la ejecución de la sentencia activadora. La opción BEFORE o AFTER se especifica justo antes de especificar la sentencia activadora. El trigger BUpCUOTA es un before trigger. • En algunos casos da lo mismo si el trigger se ejecuta antes o despues de realizar la sentencia activadora. En estos casos, un after trigger es ligeramente más eficiente que un before trigger, pues con estos últimos los registros de datos afectados son leídos (lógicamente) dos veces: una para el disparador y otra para la sentencia disparadora. Con los after triggers se leen los registros de datos solo una vez. • La sentencia activadora especifica el tipo de operación que despierta el disparador (DELETE, INSERT o UPDATE). Una, dos o incluso las tres operaciones pueden ser incluidas en la especificación de la sentencia activadora. • En la sentencia activadora se especifica la tabla asociada al trigger. Puede especificarse exactamente una tabla (no una vista) en la sentencia activadora. • Si la sentencia activadora especifica un UPDATE se puede incluir una lista de columnas en dicha sentencia. Si se incluye la lista de columnas, el trigger se activa por un UPDATE solo si una de las columnas especificadas es actualizada. Si se omite la lista, el trigger se


10

activa cuando cualquier columna de la tabla se actualiza. No se puede especificar lista de columnas para INSERT o DELETE. • La presencia o ausencia de la opción FOR EACH ROW determina si el disparador es a nivel de filas (row trigger) o a nivel de sentencia activadora (statement trigger). Si esta presente, esta opción especifica que el cuerpo del trigger se ejecuta individualmente para cada una de las filas de la tabla que haya sido afectada por la sentencia activadora. La ausencia de la opción FOR EACH ROW implica que el trigger se ejecuta una sola vez, para la ejecución de una sentencia activadora. • Opcionalmente, se pueden incluir restricciones en la definición de un row trigger. Para ello se especifica, en una cláusula WHEN, una expresión booleana de SQL. Si se incluye una cláusula WHEN, la expresión se evalúa para cada una de las filas que el disparador afecta. Si el resultado de la evaluación es TRUE, se ejecuta el cuerpo del trigger sobre la fila que hizo cierta la expresión. Si el resultado de la evaluación es FALSE o NOT TRUE (desconocido, como con los valores nulos) para una fila dada, el cuerpo del trigger no se ejecuta para dicha fila. La expresión en una cláusula WHEN no puede incluir subqueries. • Solo se puede definir un trigger de cada tipo por tabla. Lo cual nos d alas siguientes combinaciones: BEFORE UPDATE row AFTER UPDATE row BEFORE DELETE row AFTER DELETE row BEFORE INSERT row AFTER INSERT row BEFORE UPDATE statement AFTER UPDATE statement BEFORE DELETE statement AFTER DELETE statement BEFORE INSERT statement AFTER INSERT statement • Cada tabla puede tener hasta cuatro UPDATE triggers (BEFORE/AFTER, statement/row), sin importar si los triggers son disparados sólo cuando se actualizan algunas columnas de la tabla. • Orden en la Ejecución de Disparadores. Una tabla puede tener distintos Tipos de Disparadores asociados a una misma orden DML.:

1. Ejecutar, si existe, el disparador tipo BEFORE a nivel de sentencia. 2. Para cada fila a la que afecte la orden: (esto es como un bucle, para cada fila)

a) Ejecutar, si existe, el disparador BEFORE a nivel de fila, sólo si dicha fila cumple la condición de la cláusula WHEN (si existe).

b) Ejecutar la propia orden. c) Ejecutar, si existe, el disparador AFTER a nivel de fila, sólo si dicha fila

3. cumple la condición de la cláusula WHEN (si existe). 4. Ejecutar, si existe, el disparador tipo AFTER a nivel de orden.


11

Contenido del disparador. • El cuerpo de un trigger es un bloque de PL/SQL que puede incluir instrucciones de PL/SQL y de SQL. Este bloque de instrucciones se realiza si se ejecuta la sentencia activadora especificada para el trigger y, si existe una clausula WHEN esta es TRUE. La instrucción CREATE TRIGGER falla si hay algún error en el bloque PL/SQL. • Si un trigger puede ser activado por mas de un tipo de operación (por ejemplo, "INSERT OR DELETE OR UPDATE OF Cuota"), el cuerpo del trigger puede utilizar los predicados condicionales INSERTING, DELETING y UPDATING para ejecutar bloques específicos de código, dependiendo del tipo de operación que activó el disparador. Por ejemplo, si se tiene INSERT OR UPDATE ON Cuota • dentro del código del trigger se pueden incluir las siguientes condiciones: IF INSERTING THEN . . . END IF; IF UPDATING THEN . . . END IF; la primera condición es cierta sólo si la operación que disparó el trigger es un INSERT. La segunda condición es cierta sólo si la operación que disparó el trigger es un UPDATE. • En un UPDATE, se puede especificar el nombre de una columna en un predicado condicional UPDATING para determinar si la columna especificada ha sido actualizada. Por ejemplo: CREATE TRIGGER . . . . . . UPDATE OF sal, comm ON emp . . . BEGIN . . . IF UPDATING ('sal') THEN . . . END IF; END; • El cuerpo de un row trigger puede incluir ciertos elementos especiales: nombres de correlación y los predicados condicionales INSERTING, DELETING y UPDATING. • En el cuerpo de un disparador, el código PL/SQL y las instrucciones de SQL tienen acceso a los valores nuevos y viejos de las columnas de la fila actual afectada por la sentencia activadora. Existen dos nombres de correlación para cada columna de la tabla que esta siendo modificada: uno para el valor viejo y otro para el valor nuevo. Los valores nuevos son referenciados utilizando “:new.” antes del nombre de la columna, mientras que los viejos utilizan “:old.” (los “:” son necesarios dentro del bloque de PL/SQL para indicar que es un valor que viene de afuera de la expresión SQL). • Si se produce una excepción o condición de error (predefinida o definida por el usuario) durante la ejecución del cuerpo del disparador, se hace ROLLBACK de todos los efectos del cuerpo del trigger y de la sentencia activadora (a menos que se haga un manejo especifico de la excepción). Por lo tanto, el cuerpo de un trigger puede evitar la ejecución de una sentencia activadora produciendo una excepción.


12

• El cuerpo de un trigger puede incluir cualquier instrucción del DML SQL, incluyendo SELECT (que debe ser un SELECT-INTO o un SELECT en la definición de un cursor), INSERT, UPDATE y DELETE. No se permiten instrucciones del DDL ni instrucciones para el control de transacciones (ni ROLLBACK, ni COMMIT ni SAVEPOINT). • Una instrucción SQL dentro de un trigger puede insertar datos en una columna de tipo LONG o LONG RAW. Sin embargo, no se pueden declarar variables de estos tipos en el cuerpo del disparador. Además, ni :NEW ni :OLD pueden ser usados con columnas de tipo LONG o LONG RAW. No se deben crear triggers que dependan del orden en el cual las filas sean procesadas. Recuerde que una BD relacional no garantiza el orden de las filas al ser procesadas por una instrucción SQL. Cuando una instrucción de un trigger produce que se dispare otro trigger, se dice que estos estan “en cascada”. ORACLE permite hasta 32 triggers en cascada.


13

Conexión con Oracle.

1. Cree un proyecto web en Netbeans.

2. En la página web generada por defecto digite lo siguiente (index.jsp):

<%@page import = "java.io.*,java.sql.*" %>

<%

String BASEDATOS = "orcl";

String USUARIO = "SYSTEM";

String PASSWORD = "123456";

String Driver1 = "oracle.jdbc.driver.OracleDriver";

String Url1 = "jdbc:oracle:thin:@localhost:1521:" + BASEDATOS;

String Url2 = "jdbc:oracle:oci8:@"+BASEDATOS;

String UsuBase = USUARIO;

String Pass = PASSWORD;

String v_server = "";

String v_server2 = "";

Connection CON1 = null;

java.sql.Statement STMT1 = null;

ResultSet RS1 = null;

Class.forName(Driver1).newInstance();

CON1 = DriverManager.getConnection(Url1,UsuBase,Pass);

STMT1 = CON1.createStatement();

RS1=STMT1.executeQuery("SELECT TO_CHAR(SYSDATE) FROM DUAL");

while (RS1.next())

v_server = RS1.getString(1);

CON1 = null;

STMT1 = null;

RS1 = null;

%>

<html> <head>

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">

<title>Practica de laboratorio 4</title> </head>

<body> <h1><%=v_server%></h1> </body>

</html>

3. Ejecute la pagina web en el navegador

4. Explique cuál fue el resultado.

_________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________

Procedimiento

Bibliografía

Guía 1


14

Creación de Store Procedure

1. Abrir SQL Plus

2. Crear la tabla operador

3. Crear el siguiente procedimiento almacenado

4. Ejecutar el procedimiento almacenado con el siguiente código:

5. Observar el contenido de la tabla involucrada


_________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________


15

Creación de TRIGGER

1. Abrir SQL Plus

2. Crear la tabla de auditoria:

3. Crear el siguiente trigger:

4. Ejecutar el siguiente código:

5. Verifique el contenido de la tabla de auditoria


_________________________________________________________________________

_________________________________________________________________________

_________________________________________________________________________

Investigue las diferencias entre los driver JDBC OCI y THIN

Desarrolle un procedimiento almacenado para modificar el campo NOMBRE de la tabla OPERADOR_TBL dado un BILLING_OPERATOR.

Desarrolle una trigger que para cada nuevo registro realizado en la tabla OPERADOR_TBL, se registre un control en una tabla, con los siguientes campos: BILLING_OPERATOR, USUARIO y la FECHA (del servidor de la base de datos en donde se ejecuta la transacción).

ORACLE 11g. Curso práctico. Teaching Soft Group. ORACLE 9i. Manual del administrador. Técnicas de gestión de datos Oracle robustas y de alto

rendimiento. Kevin Loney/ Marlene Thenault.

Investigación Complementaria

Guía 3

Guía 4

fía

Bibliografía

Guía 3

Guía 4

fía

Base de datos II - udb.edu.sv · Base de datos II. Guía 3 5 Tema: Entornos WEB/Introducción...

Documents

Transcript of Base de datos II - udb.edu.sv · Base de datos II. Guía 3 5 Tema: Entornos WEB/Introducción...