TRIGGER O DISPARADOR Un Disparador o Trigger es una rutina autnoma asociada con una tabla o vista que automticamente realiza

una accin cuando una fila en la tabla o la vista se inserta (INSERT), se actualiza (UPDATE), o borra (DELETE). Un Disparador nunca se llama directamente, en cambio, cuando una aplicacin o usuario intenta insertar, actualizar, o anular una fila en una tabla, la accin definida en el disparador se ejecuta automticamente (se dispara).

Las ventajas de usar los Disparadores son:

La entrada en vigor automtica de restricciones de los datos, hace que los usuarios entren slo valores vlidos. El mantenimiento de la aplicacin se reduce, los cambios a un disparador se refleja automticamente en todas las aplicaciones que tienen que ver con la tabla sin la necesidad de recompilar o relinquear. Logs automticos de cambios a las tablas. Una aplicacin puede guardar un registro corriente de cambios, creando un disparador que se active siempre que una tabla se modifique. La notificacin automtica de cambios a la Base de Datos con alertas de evento en los disparadores.

Los Disparadores tienen dos palabras clave, OLD y NEW que se refieren a los valores que tienen las columnas antes y despus de la modificacin. Los INSERT permiten NEW, los DELETE slo OLD y los UPDATE ambas. Un ejemplo de un disparador seria uno asociado a la sentencia DELETE en una tabla de clientes, para impedir que se elimine uno que tenga un saldo distinto de cero. Otro disparador seria guardar los datos que se modifican de un cliente en otra base de datos que servira de auditoria. VENTAJAS DE LOS TRIGGER Seguridad de los datos mejorada Ofrecen chequeos de seguridad basada en valores ,Integridad de los datos mejorada Fuerzan restricciones dinmicas de integridad de datos yde integridad referencial.

Aseguran que las operaciones relacionadas se realizan juntas de forma implcita Respuesta instantnea ante un evento auditado Ofrece un mayor control sobre la B.D.

DESVENTAJAS Hay que definir con anticipacin la tarea que realizara el trigger Peligro de prdida 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 operacin 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. Adems, la funcin puede ser utilizada para disparar distintas relaciones (estas funciones son llamadas "general trigger funcions"). Como ejemplo de utilizacin de lo descrito, se puede hacer una funcin general que toma como argumentos dos nombres de campo e inserta el nombre del usuario y la fecha (timestamp) actuales en ellos. Esto permite, por ejemplo, utilizar los triggers en los eventos INSERT para realizar un Guia del Programador de PostgreSQL CREATE TRIGGER <trigger name> <BEFORE|AFTER> <INSERT|DELETE|UPDATE> ON <relation name> FOR EACH <ROW|STATEMENT> EXECUTE PROCEDURE <procedure name> (<function args>); Triggers (disparadores) Pgina 1 de 2 http://lucas.hispalinux.es/Postgresql-es/web/navegable/programmer/triggers.html 20/10/2002 seguimiento automtico de la creacin de registros en una tabla de transacciones. Se podra utilizar tambin para registrar actualizaciones si es utilizado en un evento UPDATE.

Las funciones trigger retornan un rea de tuplas (HeapTuple) al ejecutor. Esto es ignorado para trigger lanzados tras (AFTER) una operacin INSERT, DELETE o UPDATE, pero permite lo siguiente a los triggers BEFORE: - retornar NULL e ignorar la operacin para la tupla actual (y de este modo la tupla no ser insertada/actualizada/borrada); - devolver un puntero a otra tupla (solo en eventos INSERT y UPDATE) que sern insertados (como la nueva versin de la tupla actualizada en caso de UPDATE) en lugar de la tupla original. Notar que no hay inicializacin por parte del CREATE TRIGGER handler. Esto ser cambiado en el futuro. Adems, si ms de un trigger es definido para el mismo evento en la misma relacin, el orden de ejecucin de los triggers es impredecible. Esto puede ser cambiado en el futuro. Si una funcin trigger ejecuta consultas SQL (utilizando SPI) entonces estas funciones pueden disparar nuevos triggers. Esto es conocido como triggers en cascada. No hay ninguna limitacin explicita en cuanto al nmero de niveles de cascada. Si un trigger es lanzado por un INSERT e inserta una nueva tupla en la misma relacin, el trigger ser llamado de nuevo (por el nuevo INSERT). Actualmente, no se proporciona ningn mecanismo de sincronizacin (etc) para estos casos pero esto puede cambiar. Por el momento, existe una funcin llamada funny_dup17() en los tests de regresin que utiliza algunas tcnicas para parar la recursividad (cascada) en si misma. EJEMPLOS DE TRIGGER 1.Triggers DML: INSTEAD OF Los TRIGGERS de tipo Instead OF son TRIGGERS que se disparan en lugar de la operacin que los produce, es decir, una operacin de borrado de registros con la instruccin delete sobre una tabla que tiene un TRIGGER de tipo INSTEAD OF no se llega a realizar realmente, sino que SQL Server 2005 cuando detecta esta operacin invoca al TRIGGER que es el responsable de actuar sobre los registros afectados, en el ejemplo que estamos siguiendo, el TRIGGER sera el responsable de borrar los registros de la tabla que ha disparado el evento. Si el TRIGGER no se encarga de esta tarea, el usuario tendr la sensacin de que SQL Server no hace caso a sus comandos ya que por ejemplo una instruccin DELETE no borrar los registros.

Como ejemplo de TRIGGER de tipo INSTEAD OF vamos a ver como se implementara la siguiente regla: no se pueden borrar los clientes cuyo Crdito Total sea mayor que cero, sin embargo si dentro de una operacin de borrado hay clientes con Riesgo Total cero y otros con Riesgo Total distinto de cero, los que tengan cero si deben resultar eliminados. El TRIGGER que implementara esa regla sera el siguiente. CREATE TRIGGER TR_BorradoSelectivo on Clientes INSTEAD OF DELETE AS BEGIN DELETE c FROM Clientes C INNER JOIN DELETED d ON C.idCliente=D.idCliente WHERE C.CreditoTotal=0 END 2.Triggers DML: AFTER Todos los TRIGGERS sirven en general para implementar restricciones de negocio avanzadas, como ejemplo vamos a ver como se construira un TRIGGER que impidiese que se aumentase el Crdito total de un cliente que tenga pagos pendientes, para ello vamos a suponer una tabla de clientes con identificador idCliente y con un campo llamado CreditoTotal y una tabla de recibos conteniendo el idcliente y el estado del recibo (estos son solamente los campos que son relevantes para nuestro ejemplo). CREATE TRIGGER TR_CompruebaCreditoTotal ON Clientes AFTER UPDATE AS BEGIN IF UPDATE(CreditoTotal) -- Se est actualizando el campo crdito total, comprobemos

-- las restricciones. BEGIN IF EXISTS( SELECT IdCliente FROM RECIBOS WHERE Estado=PEN AND idCliente IN (SELECT idCliente FROM DELETED) ) BEGIN ROLLBACK -- Deshacemos la transaccin impidiendo que se actualize RAISERROR (No se pueden actualizar el crdito de clientes con recibos pendientes,16,1) END END END

3.Triggers DDL: a nivel de base de datos Los TRIGGERS DML (Data Manipulation Language) responden a la necesidad de garantizar la integridad y consistencia de los datos dentro de nuestras tablas de usuario, sin embargo no ayudan a mantener las reglas de diseo de nuestra base de datos. El nombre coincide pero el propsito es distinto, los triggers DDL (Data Definition Language) nos proporcionarn mecanismos para garantizar que nuestra base de datos est diseada e implementada de acuerdo a los estndares que hayamos definido.

Los TRIGGERS DDL tienen dos alcances diferenciados, a nivel de servidor y a nivel de base de datos. Estos alcances estn enlazados con el tipo de evento que los dispare, en esta primera parte los eventos que vamos a ver son a nivel de Base de datos y algunos ejemplos de ellos son:

CREATE / ALTER /DROP View

CREATE / ALTER /DROP Table CREATE / ALTER /DROP Schema

Aunque hay muchos ms, relacionados con estadsticas, sinnimos, usuarios (no confundir con logins que son a nivel de servidor), procedimientos, etc. Puede consultar los libros en pantalla de SQL Server 2005 para obtener una relacin completa de todos los eventos a los que puede responder.

Los TRIGGERS DDL tiene una particularidad adicional sobre los de tipo DML y es que no tiene mucho sentido las tablas inserted y deleted ya que el tipo de operaciones que disparan los triggers son radicalmente diferentes. Sin embargo, como ellos necesitan recibir informacin acerca del evento que ha ocasionado que el trigger se dispare, para ello existe la funcin EVENTDATA(), esta funcin devuelve un valor XML que responde al siguiente esquema: <EVENT_INSTANCE> <EventType>type</EventType> <PostTime>date-time</PostTime> <SPID>spid</ SPID> <ServerName>name</ServerName> <LoginName>name</LoginName> <UserName>name</UserName> <DatabaseName>name</DatabaseName> <SchemaName>name</SchemaName> <ObjectName>name</ObjectName> <ObjectType>type</ObjectType> <TSQLCommand>command</TSQLCommand> </EVENT_INSTANCE>

PROCEDIMIENTOS ALMACENADOS

Los procedimientos almacenados y funciones son nuevas funcionalidades de la versin de MySQL 5.0. Un procedimiento almacenado es un conjunto de comandos SQL que pueden almacenarse en el servidor. Una vez que se hace, los clientes no necesitan relanzar los comandos individuales pero pueden en su lugar referirse al procedimiento almacenado. Algunas situaciones en que los procedimientos almacenados pueden ser particularmente tiles:

Cuando mltiples aplicaciones cliente se escriben en distintos lenguajes o funcionan en distintas plataformas, pero necesitan realizar la misma operacin en la base de datos. Cuando la seguridad es muy importante. Los bancos, por ejemplo, usan procedimientos almacenados para todas las operaciones comunes. Esto proporciona un entorno seguro y consistente, y los procedimientos pueden asegurar que cada operacin se loguea apropiadamente. En tal entorno, las aplicaciones y los usuarios no obtendran ningn acceso directo a las tablas de la base de datos, slo pueden ejectuar algunos procedimientos almacenados.

Los procedimientos almacenados pueden mejorar el rendimiento ya que se necesita enviar menos informacin entre el servidor y el cliente. El intercambio que hay es que aumenta la carga del servidor de la base de datos ya que la mayora del trabajo se realiza en la parte del servidor y no en el cliente. Considere esto si muchas mquinas cliente (como servidores Web) se sirven a slo uno o pocos servidores de bases de datos.