Definición de Trigger Activación de los triggers Tipos de evento

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
BEGIN
insert into ADM
VALUES ( ora_login_user, sysdate, ora_sysevent, ora_dict_obj_type,
ora_dict_obj_owner, ora_dict_obj_name );
END;
/
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;
BEGIN
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 IF;
END LOOP;
END;
/
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
BEGIN
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');
END IF;
END;
/
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;
END;
/
CREATE OR REPLACE TRIGGER C_VENTA
BEFORE INSERT OR UPDATE ON VENTA
FOR EACH ROW
BEGIN
PVENTA.V_CODCLI:=:NEW.CODCLI;
PVENTA.V_FORMAPAGO:=:NEW.FORMADEPAGO;
END;
/
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;
BEGIN
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 IF;
END LOOP;
END IF;
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 IF;
END LOOP;
END IF;
END IF;
PVENTA.V_CODCLI:=NULL;
PVENTA.V_FORMAPAGO:=NULL;
END;
/
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 /var/lib/dpkg.
--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))
BEGIN
IF velocidad < 120 THEN
INSERT INTO familiares VALUES (velocidad, marca);
ELSE
INSERT INTO deportivos VALUES (velocidad, marca);
END IF;
END;