Definición de Trigger Un trigger es una clase que implementa una interfaz que dispone de un método Run (...), en el cual se implementa la tarea que debe ser llevada a cabo, y un método Error (...), en el cual se implementa la tarea que debe ser llevada a cabo en caso de Que se produzca algún problema, en la mayoría de casos debería deshacer las Acciones llevadas a cabo en el método run (). Un trigger (o disparador) en una Base de datos, es un procedimiento que se ejecuta cuando se cumple una condición establecida al realizar una operación. Dependiendo de la base de datos, los triggers pueden ser de inserción (INSERT), actualización (UPDATE) o borrado (DELETE). Algunas bases de datos pueden ejecutar triggers al crear, borrar o editar usuarios, tablas, bases de datos u otros objetos. Activación de los triggers Dentro del fichero isum.xml se especifica si isum debe gestionar triggers. También puede cambiar el nombre del fichero donde se registran y definen los Triggers.... <Trigger> <Enabled>false<enabled> <definition_file_name>triggers.xml<definition_file_n Ame> <Trigger>... Tipos de evento Se entiende como evento la llamada a un método de un objeto de persistencia. Puede definir una tarea para que se lleve a cabo cuando se produzca un evento, pero La tarea asociada al evento puede ser ejecutada antes o después de que se produzca Dicho evento. Insert: Se produce cuando se intenta guardar el objeto por primera vez. Update: Se produce cuando se intenta modificar algún dato del objeto. Remove: Se produce cuando se intenta eliminar el objeto. Características de un trigger
Puesto que los trigger se establecen sobre objetos de persistencia, cada objeto de Persistencia que soporte la gestión de triggers tiene asociado un tipo de trigger. Cada trigger implementa una interfaz concreta, así pues para gestionar un trigger Sobre un objeto que implemente la interfaz Device dispone de una interfaz DeviceTrigger la cual define los siguientes métodos. Public void run (Device device); Public void error (Device device); Como puede observar los dos métodos proporcionan un objeto, este objeto es el Objeto sobre el cual se produjo el evento. No aceptan parámetros o argumentos (pero podrían almacenar los datos afectados en tablas temporales) No pueden ejecutar las operaciones COMMIT o ROLLBACK por que estas son parte de la sentencia SQL del disparador (únicamente a través de transacciones autónomas) Pueden causar errores de mutaciones en las tablas, si se han escrito de manera deficiente. DROP FUNCTION inc_aux (); EJEMPLOS: 1. Este es un ejercicio para realizar auditorías almacenando en una tabla los eventos de instrucciones DDL que se realicen en la base de datos: Create or replace trigger DDLTrigger AFTER DDL ON DATABASE insert into ADM VALUES ( ora_login_user, sysdate, ora_sysevent, ora_dict_obj_type, ora_dict_obj_owner, ora_dict_obj_name ); 2. En este ejercicio obtendremos la sumatoria y el promedio de los saldos de los artículos:
SET SERVEROUTPUT ON; CREATE OR REPLACE TRIGGER ESTA_ARTICULO AFTER INSERT OR DELETE OR UPDATE ON ARTICULO DECLARE CURSOR C_ESTADISTICO IS SELECT CODTIPO, AVG(SALDO) PROMEDIO,SUM(SALDO) SUMATORIA FROM ARTICULO GROUP BY CODTIPO; FOR V_ESTADISTICA IN C_ESTADISTICO LOOP UPDATE ESTA_ARTICULO SET PROM= V_ESTADISTICA.PROMEDIO, SUMATORIA=V_ESTADISTICA.SUMATORIA WHERE CODTIP=V_ESTADISTICA.CODTIPO; IF SQL%NOTFOUND THEN INSERT INTO ESTA_ARTICULO VALUES(V_ESTADISTICA.CODTIPO,V_ESTADISTICA.PROMEDIO, V_ESTADISTICA.SUMATORIA); END LOOP; 3. En este ejercicio trabajamos con los disparadores de sustitucion que trabajan solamente con vistas y la instruccion instead of: CREATE VIEW V_CLIENTE AS SELECT CODCLI,NOMCLIEFROM CLIENTE; SET SERVEROUTPUT ON;
CREATE OR REPLACE TRIGGER V_CLIENTE INSTEAD OF DELETE OR INSERT OR UPDATE ON V_CLIENTE FOR EACH ROW IF DELETING THEN DELETE FROM CLIENTE WHERE CODCLI=:OLD.CODCLI; DBMS_OUTPUT.PUT_LINE('SE BORRO EL REGISTRO'); ELSIF INSERTING THEN DBMS_OUTPUT.PUT_LINE('SE INSERTO UN REGISTRO'); ELSE DBMS_OUTPUT.PUT_LINE('SE ACTUALIZO UN REGISTRO'); 4. Ahora en el ejercicio que sigue trabajaremos con paquetes, y usaremos dos disparadores Para mane jar las inserciones y actualizaiones de la tabla venta, que esta relacionada con la tabla cliente: CREATE OR REPLACE PACKAGE PVENTA AS V_CODCLI VENTA.CODCLI%TYPE; V_FORMAPAGO VENTA.FORMADEPAGO%TYPE; CREATE OR REPLACE TRIGGER C_VENTA BEFORE INSERT OR UPDATE ON VENTA
FOR EACH ROW PVENTA.V_CODCLI:=:NEW.CODCLI; PVENTA.V_FORMAPAGO:=:NEW.FORMADEPAGO; SET SERVEROUTPUT ON; CREATE OR REPLACE TRIGGER D_VENTA BEFORE INSERT OR UPDATE ON VENTA FOR EACH ROW DECLARE CURSOR CLIEN IS SELECT *FROM CLIENTE; IF INSERTING THEN IF PVENTA.V_FORMAPAGO='CREDITO' THEN FOR V_LOOP IN CLIEN LOOP IF V_LOOP.CODCLI = PVENTA.V_CODCLI THEN UPDATE CLIENTE SET SALDOCLIE=(SALDOCLIE*1.05) WHERE CODCLI= PVENTA.V_CODCLI; DBMS_OUTPUT.PUT_LINE('BIEN'); END LOOP; ELSE IF PVENTA.V_FORMAPAGO='EFECTIVO' THEN FOR V_LOOP IN CLIEN LOOP IF V_LOOP.CODCLI = PVENTA.V_CODCLI THEN UPDATE CLIENTE SET SALDOCLIE = 0 WHERE CODCLI= PVENTA.V_CODCLI;
DBMS_OUTPUT.PUT_LINE('BIEN ACTUALIZADO'); END LOOP; PVENTA.V_CODCLI:=NULL; PVENTA.V_FORMAPAGO:=NULL; Las ventajas de usar los Disparadores son: La entrada en vigor automática de restricciones de los datos, hace que los usuarios entren sólo valores válidos. El mantenimiento de la aplicación se reduce, los cambios a un disparador se refleja automáticamente en todas las aplicaciones que tienen que ver con la tabla sin la necesidad de recompilar o relinquear. Logs automáticos de cambios a las tablas. Una aplicación puede guardar un registro corriente de cambios, creando un disparador que se active siempre que una tabla se modifique. La notificación automática de cambios a la Base de Datos con alertas de evento en los disparadores. Las desventajas de usar los disparadores son: Hay que definir con anticipación la tarea que realizara el trigger Peligro de pérdida en Reorganizaciones Hay que programarlos para cada DBMS Un Trigger nunca se llama directamente. Los triggers no se desarrollan pensando en un solo registro, los mismos deben funcionar en conjunto con los datos ya que se disparan por operación y no por registro
. Por funcionalidad, no hay que poner en uno solo las funciones de INSERT,UPDATE y DELETE. Utilizar moderadamente los triggers. No se pueden utilizar en tablas temporales USOS: Registrar, auditar y monitorear la actividad de cambio de datos Validar datos, cambiando o negando acciones como INSERT, UPDATE, DELETE en una tabla Preservar la consistencia y claridad de los datos ejecutando acciones relacionadas con otras tablas. Se puede usar mediante scripts del desarrollador en situaciones Complejas y condicionales en las que los ficheros de disparadores, o la Declaración de la directiva actívate en el fichero de control, no son Suficientemente informativos. También se puede usar para comprobaciones y administradores de sistemas (pero tenga en cuenta que dpkg-trigger no Accionara los disparadores). La sintaxis no reconocida de nombres de disparadores son un error para Dpkg-trigger. 'ORDENES --check-supported Revisa si la versión de dpkg en ejecución es compatible con Disparadores (habitualmente invocados mediante una
Post-instalación). Cierra con 0 si dpkg es compatible con los Disparadores, o 1 con un mensaje de error por la salida estándar En caso de fallo. Por otra parte, en general es mejor activar Solo el disparador deseado con dpkg-trigger. -h, --help Muestra el modo de uso y termina. --versión Muestra la versión y termina. OPCIONES --admindir=directorio Cambia el directorio con la base de datos de dpkg. Por omisión es varlibdpkg. --by-package=paquete Invalida la espera al inicio del disparador (habitualmente definido con dpkg a través de la variable de entorno <<DPKG_MAINTSCRIPT_PACKAGE>> en los scripts del desarrollador, Nombrando el paquete al que el script pertenece. Este es el Comportamiento por omision.)
--No-await Esta opción define que la invocación al paquete T (de existir) No necesita esperar al procesamiento de este disparador; el Paquete(s) interesado I no se añadirá a la lista de espera del Procesado del disparador, sin cambiar el estado de T. Puede que Se considere que T está instalado aunque no se haya procesado el Disparador. --no-act Realiza un simulacro sin cambios en el sistema. 5 BASES MAS USADAS 1. World Data Centre for Climate El WDCC (Centro Mundial de datos para el clima) es la base de datos más grande del mundo. Almacena unos 220 terabytes de información y 6 peta bytes de información adicional, incluyendo datos sobre el clima, predicciones y simulaciones. 2. National Energy Research Scientific Computing Center El NERSC se dedica a investigar sobre distintos tipos de energía. Su base de datos tiene 2.8 Peta bytes. 3. AT&T Se trata de una compañía de telecomunicaciones que almacena 323 terabytes de información. 4. Google Aunque se desconoce el verdadero tamaño de su base de datos, sí se puede estimar. La compañía recibe unos 91 millones de consultas al día, consultas que son almacenadas por la compañía. Se supone que almacena cientos de terabytes de información. 5. Sprint Con 53 millones de clientes, Sprint es una de las mayores compañías de telecomunicaciones del mundo. Guarda los detalles de 365 millones de llamadas al día.
Procedimiento almacenado Un procedimiento almacenado (stored procedure en inglés) es un programa (o procedimiento) el cual es almacenado físicamente en una base de datos. Su implementación varía de un gestor de bases de datos a otro. La ventaja de un procedimiento almacenado es que al ser ejecutado, en respuesta a una petición de usuario, es ejecutado directamente en el motor de bases de datos, el cual usualmente corre en un servidor separado. Como tal, posee acceso directo a los datos que necesita manipular y sólo necesita enviar sus resultados de regreso al usuario, deshaciéndose de la sobrecarga resultante de comunicar grandes cantidades de datos salientes y entrantes. Usos típicos para procedimientos almacenados incluyen la validación de datos siendo integrados a la estructura de base de datos (los procedimientos almacenados utilizados para este propósito a menudo son llamados disparadores; triggers en inglés), o encapsular un proceso grande y complejo. El último ejemplo generalmente ejecutará más rápido como un procedimiento almacenado que de haber sido implementado como, por ejemplo, un programa corriendo en el sistema cliente y comunicándose con la base de datos mediante el envío de consultas SQL y recibiendo sus resultados. Los procedimientos pueden ser ventajosos: Cuando una base de datos es manipulada desde muchos programas externos. Al incluir la lógica de la aplicación en la base de datos utilizando procedimientos almacenados, la necesidad de embeber la misma lógica en todos los programas que acceden a los datos es reducida. Esto puede simplificar la creación y, particularmente, el mantenimiento de los programas involucrados. Podemos ver un claro ejemplo de estos procedimientos cuando requerimos realizar una misma operación en un servidor dentro de algunas o todas las bases de datos y a la vez dentro de todas o algunas de las tablas de las bases de datos del mismo. Para ello podemos utilizar a los Procedimientos almacenados auto creables que es una forma de generar ciclos redundantes a través de los procedimientos almacenados. Implementación Estos procedimientos, se usan a menudo, pero no siempre, para realizar consultas SQL sobre los objetos del banco de datos de una manera abstracta, desde el punto de vista del cliente de la aplicación. Un
procedimiento almacenado permite agrupar en forma exclusiva parte de algo específico que se desee realizar o, mejor dicho, el SQL apropiado para dicha acción. CORRECTO Usos Los usos 'típicos' de los procedimientos almacenados se aplican en la validación de datos, integrados dentro de la estructura del banco de datos. Los procedimientos almacenados usados con tal propósito se llaman comúnmente disparadores, o triggers. Otro uso común es la 'encapsulación' de un API para un proceso complejo o grande que podría requerir la 'ejecución' de varias consultas SQL, tales como la manipulación de un 'data set' enorme para producir un resultado resumido. También pueden ser usados para el control de gestión de operaciones, y ejecutar procedimientos almacenados dentro de una transacción de tal manera que las transacciones sean efectivamente transparentes para ellos. El siguiente es un ejemplo de procedimiento almacenado en MySQL: DELIMITER CREATE PROCEDURE autos (IN velocidad INT, IN marca VARCHAR (50)) IF velocidad < 120 THEN INSERT INTO familiares VALUES (velocidad, marca); ELSE INSERT INTO deportivos VALUES (velocidad, marca);