Michel A. Fajardo Mera / michel.fajardo@grm.jovenclub.cu
Al leer el titulo de este artículo cualquiera pensaría que el nombre disparadores viene sacado de una de estas películas del oeste que nos brinda el cine hollywoodense, pero para muchos informáticos en el mundo, disparadores viene estrechamente ligado con el uso de los Sistemas Gestores de Base de Datos (SGBD). El termino disparador, trigger, o desencadenador como es conocido por muchos de los diseñadores y programadores de bases de datos, es un tipo especial de procedimiento almacenado que entra en vigor antes, después o en lugar (BEFORE, AFTER, INSTEAD OF) de efectuarse una operación DELETE, INSERT o UPDATE. En el caso de SQL Server no se pueden definir disparadores que se ejecuten antes o después de una operación de actualización de tablas de la Base de Datos (BD).
Los desencadenadores pueden consultar otras tablas e incluir instrucciones SQL complejas. Son especialmente útiles para exigir reglas o requisitos complejos. También son útiles para exigir la integridad referencial, que conserva las relaciones definidas entre tablas cuando se agregan, actualizan o eliminan filas en esas tablas. No obstante, la mejor manera de exigir la integridad referencial es definiendo restricciones de clave principal y de clave externa en las tablas relacionadas.
Una tabla puede tener varios desencadenadores de un tipo determinado, siempre que tengan nombres distintos. Todo desencadenador puede llevar a cabo numerosas funciones. Sin embargo, sólo se puede aplicar a una tabla.
Los desencadenadores tienen varias utilidades:
– Los desencadenadores son automáticos: se activan al efectuarse modificaciones en los datos de la tabla, como una entrada manual o una acción de la aplicación.
– Pueden realizar cambios en cascada a través de tablas relacionadas de la base de datos, al igual que cuando se define las cláusulas ON DELETE y ON UPDATE al definir restricciones de integridad referencial al crear tablas.
– Los desencadenadores pueden exigir restricciones más complejas que las definidas con restricciones CHECK.
Puede eliminar un desencadenador cuando ya no lo necesite. El hecho de eliminar un desencadenador no afecta a la tabla ni a los datos en los que está basado. Si se elimina una tabla, se eliminarán automáticamente todos los desencadenadores que contenga.
Si cambia el nombre de un objeto al que hace referencia un desencadenador, deberá modificar este último para que el texto refleje el nuevo nombre. Por lo tanto, antes de cambiar el nombre de un objeto, fíjese en las dependencias del mismo para determinar si algún desencadenador va a verse afectado por el cambio propuesto.
CREATE TRIGGER
CREATE TRIGGER trigger_name ON { table | view } { { { FOR | AFTER | INSTEAD OF } { [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE ] } AS sql_statement } }
trigger_name: Es el nombre del desencadenador.
Table | view: Es la tabla o vista que se ejecuta el desencadenador.
{ [DELETE] [,] [INSERT] [,] [UPDATE] } :
Especifica qué instrucciones de modificación de datos activa el desencadenador. En la definición del desencadenador se permite cualquier combinación de éstas, en cualquier orden. Si especifica más de una opción, sepárelas con comas.
AS: Son las acciones que va a llevar a cabo el desencadenador.
sql_statement: Son las condiciones y acciones del desencadenador.
Los desencadenadores pueden incluir cualquier número y clase de instrucciones SQL. Un desencadenador está diseñado para comprobar o cambiar los datos; no debe devolver datos al usuario.
En las instrucciones CREATE TRIGGER se utilizan unas cuantas tablas especiales:
deleted e inserted : Son tablas lógicas (conceptuales). Guarda los valores antiguos o nuevos de las filas que la acción del usuario puede cambiar tomando el formato del registro en cuestión.
Desencadenadores recursivos
– SQL permite también la invocación recursiva de desencadenadores.
Desencadenadores anidados
– Los desencadenadores pueden anidarse. Si un desencadenador cambia una tabla en la que hay otro desencadenador, el segundo se activa y puede, entonces, llamar a un tercero, y así sucesivamente. Si algún desencadenador de la cadena causa un bucle infinito se cancela el desencadenador.
Ejemplo:
Supongamos el caso en que insertemos una nueva llamada para un cliente en la tabla “Llamada”, siempre que se especifiqué que el tipo de llamada es local debemos insertar ese mismo código de llamada en la tabla “Local”. Creemos un trigger para esto, este quedaría como sigue:
CREATE TRIGGER Insertar_Llamada_Local ON Llamada
FOR INSERT
AS
DECLARE @cod_llamada INTEGER
DECLARE @tipo_llamada char(10)
SET @cod_llamada = (SELECT codllamada FROM inserted)
SET @tipo_llamada = (SELECT tipo_llamada FROM inserted)
IF @tipo_llamada = ‘local’
INSERT INTO Local VALUES(@cod_llamada) MANUAL DEL PROFESOR
Los triggers son objetos de la BD, por lo tanto además del CRETE TRIGGER se les puede aplicar el ALTER TRIGGER para modificar un desencadenador y el DROP TRIGGER para eliminarlo.
Disparadores en MySQL
Los disparadores son soportados en MySQL a partir de la versión 5.0.2. Algunos de los soportes existentes son los disparadores para las sentencias INSERT, UPDATE y DELETE
El estándar SQL:2003 requiere que los disparadores den a los programadores acceso a las variables de un registro utilizando una sintaxis como REFERENCING NEW AS n. Por ejemplo, si un disparador está monitoreando los cambios en la columna salario, podría escribirse un disparador como:
CREATE TRIGGER ver_salario
BEFORE UPDATE ON empleados
REFERENCING NEW ROW AS n, OLD ROW AS o
FOR EACH ROW
IF n.salario <> o.salario THEN
END IF;
Como en MySQL las sentencias se ejecutan luego de escribir el signo punto y coma (;), cabe destacar que para crear un disparador en MySQL, antes se escribe la sentencia DELIMITER seguida de un carácter tal como |, la cual asigna la función del punto y coma (;) a otro carácter permitiendo que el disparador sea escrito usando los punto y comas sin que se ejecute mientras se escribe; después de escrito el disparador se escribe nuevamente la sentencia DELIMITER; para asignar al punto y coma su función habitual.
Disparadores en PostgresQL
Desde 1997 PostgresQL soporta el uso de disparadores, estos pueden anexarse a las tablas pero no a las vistas; aunque a las vistas se les pueden crear reglas. Al igual que en MySQL los disparadores de PostgresQL se pueden activar luego de sentencias INSERT, UPDATE o DELETE. Cuando hay varios disparadores, se activan en orden alfabético.
Además de permitir el uso de funciones en el lenguaje nativo de PostgresQL, PL/PgSQL, los disparadores también permiten invocar funciones escritas en otros lenguajes como PL/Perl.
En Postgres un disparador ejecuta una función la cual contiene el código de lo que se requiere, esto difiere del método expuesto anteriormente para MySQL que escribe el código a ejecutarse dentro del mismo disparador.
El siguiente es un ejemplo de disparador creado con su respectiva función:
CREATE OR REPLACE FUNCTION actualizar() RETURNS TRIGGER AS $ejemplo$
BEGIN
NEW.nombre := NEW.nombres || ‘ ‘ || NEW.apellidos ;
RETURN NEW;
END;
$ejemplo$ LANGUAGE plpgsql;
CREATE TRIGGER ejemplo
BEFORE INSERT OR UPDATE ON tabla
FOR EACH ROW EXECUTE PROCEDURE actualizar();
Con lo que sabemos ahora, podemos incluso programar la mayor parte de la lógica del negocio de un sistema en un lenguaje propio de cualquier SGBD. Sin embargo esto tiene sus inconvenientes: si nos vemos obligados a migrar de un sistema de gestión a otro puede ser que parte del código generado no lo podamos utilizar y tengamos que regenerarlo.
La tendencia en el mundo es utilizar cada vez más las Bases de Datos solo como repositorios de información y dejar la implementación de la manipulación de los datos a otros lenguajes (C++, C#, VB, Object Pascal). Se debe crear al menos una capa intermedia entre la BD y la interfaz de usuario final, en esta capa se programa todas la funciones para trabajar con la BD. De esta forma se aíslan los cambios que puedan ocurrir en la base de datos de los cambios de la aplicación del usuario, se puede incluso migrar de Sistema Gestor de Base de Datos sin que se afecte la lógica de negocio de un sistema que utilice esa base de datos.
Referencias
1-Guía Lan TIMES de SQL (Incluye SQL2), James R. Groff, Paul N. Weinberg. Mc Graw Hill, 1998.
2-http://dev.mysql.com/doc/refman/5.0/es/triggers.html
3-http://dev.mysql.com/doc/refman/5.0/es/using-triggers.html
4-http://dev.mysql.com/doc/refman/5.0/es/create-triggers.html