INSTITUTO TECNOLÓGICO UNIVERSITARIO
INGENIERIA EN DESARROLLO DE SOFTWARE
DASC
BASE DE DATOS III
INVESTIGACIÓN DE DESENCADENADORES
PRESENTADO POR:
ALFREDO ALEJANDRO ESPINOSA AGUILAR ID19018
DOCENTE:
JOSÉ GERARDO GÓMEZ VELÁZQUEZ
PUEBLA-PUEBLA-MÉXICO
2020-09-30
1 INDICE
Trigger................................................................................................................................3
La estructura básica de un trigger es:..................................................................................3
Características:...................................................................................................................3
Usos....................................................................................................................................4
Ventajas y desventajas:......................................................................................................4
Sintaxis básica:...................................................................................................................5
Ejemplos de triggers:..........................................................................................................5
DISPARADORES...................................................................................................................5
Necesidad de los disparadores............................................................................................6
Disparadores en SQL...........................................................................................................7
Cuándo no deben usarse los disparadores.........................................................................10
Desencadenadores o Disparadores...................................................................................11
Tipos de trigger que existen..............................................................................................12
¿Qué es un trigger, desencadenador o disparador y cómo crearlo?...................................13
* Definición de DML..........................................................................................................13
Bibliografía.......................................................................................................................16
Webgrafía........................................................................................................................16
Trigger
Un trigger(o desencadenador) es una clase especial de procedimiento almacenado que se ejecuta
automáticamente cuando se produce un evento en el servidor de bases de datos.
Los triggers o disparadores son objetos de la base de datos que ejecutan acciones cuando se
producen ciertos eventos (tanto DML como DDL) (inserciones, modificaciones, borrados,
creación de tablas, etc.).
Trigger DML, se ejecutan cuando un usuario intenta modificar datos mediante un
evento de lenguaje de manipulación de datos (DML). Los eventos DML son
instrucciones INSERT, UPDATE o DELETE de una tabla o vista.
Trigger DDL, se ejecutan en respuesta a una variedad de eventos de lenguaje de
definición de datos (DDL). Estos eventos corresponden principalmente a instrucciones
CREATE, ALTER y DROP de Transact-SQL, y a determinados procedimientos
almacenados del sistema que ejecutan operaciones de tipo DDL.
La estructura básica de un trigger es:
Llamada de activación: es la sentencia que permite "disparar" el código a ejecutar.
Restricción: es la condición necesaria para realizar el código. Esta restricción puede ser de tipo
condicional o de tipo nulidad.
Acción a ejecutar: es la secuencia de instrucciones a ejecutar una vez que se han cumplido las
condiciones iniciales.
Existen dos tipos de disparadores que se clasifican según la cantidad de ejecuciones a realizar:
Row Triggers (o Disparadores de fila): son aquellas que se ejecutaran n-veces si se llama n-veces
desde la tabla asociada al trigger
Statement Triggers (o Disparadores de secuencia): son aquellos que sin importar la cantidad de
veces que se cumpla con la condición, su ejecución es única.
Características:
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.
Usos
Son usados para mejorar la administración de la Base de datos, sin necesidad de contar con que
el usuario ejecute la sentencia de SQL.
Además, pueden generar valores de columnas, previene errores de datos, sincroniza tablas,
modifica valores de una vista, etc.
Permite implementar programas basados en paradigma lógico (sistemas expertos, deducción).
Ventajas y desventajas:
- No pueden ser invocados directamente; al intentar modificar los datos de una tabla para la
que se ha definido un disparador, el disparador se ejecuta automáticamente.
- No reciben y retornan parámetros.
- Son apropiados para mantener la integridad de los datos, no para obtener resultados de
consultas.
-Pueden hacer referencia a campos de otras tablas.
-Los disparadores se ejecutan DESPUES de la ejecución de una instrucción "insert", "update"
o "delete" en la tabla en la que fueron definidos. Las restricciones se comprueban ANTES de
la ejecución de una instrucción "insert", "update" o "delete". Por lo tanto, las restricciones se
comprueban primero, si se infringe alguna restricción, el desencadenador no llega a
ejecutarse.
-Mejor utilización de la CPU
-Menor necesidad de limpieza de las memorias intermedias durante el procesamiento de las
transacciones
-Puntos de verificación más rápidos
-Menor tiempo de recuperación
-SQL Server registra las transacciones de tal modo que las actualizaciones en una de ellas
siempre se puedan recuperar o reducir al último estado consistente si el equipo cliente o
servidor falla.
Aunque el motor de base de datos Microsoft Jet y los archivos .mdb también proporcionan
transacciones, éstas no se administran mediante un registro de transacciones separado en los
archivos .mdb y pueden fallar sin posibilidad de recuperación si se daña el archivo de la base
de
datos.
Sintaxis básica:
create trigger NOMBREDISPARADOR on NOMBRETABLA
for EVENTO- insert, update o delete
as SENTENCIAS
Ejemplos de triggers:
1.-
CREATE TRIGGER TR_CUENTAS ON CUENTAS
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;
INSERT INTO HCO_SALDOS (IDCUENTA, SALDO, FXSALDO)
SELECT IDCUENTA, SALDO, getdate() FROM INSERTED
END
2.-
CREATE TRIGGER TR_RESULTADO ON RESULTADO
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON;
IF UPDATE (SALDO) -- Solo si se actualiza SALDO BEGIN
INSERT INTO HCO_SALDOS
(IDCUENTA, SALDO, FXSALDO)
SELECT IDCUENTA, SALDO, getdate() FROM INSERTED
END
3.-
CREATE TRIGGER TR_SEGURIDAD
ON DATABASE FOR DROP_TABLE, ALTER_TABLE
AS
BEGIN
RAISERROR ('No está permitido borrar ni modificar tablas!’, 16, 1) ROLLBACK TRANSACTION
END
DISPARADORES
Un disparador es una orden que el sistema ejecuta de manera automática como efecto secundario
de la modificación de la base de datos. Para diseñar un mecanismo disparador hay que cumplir
dos requisitos:
1. Especificar las condiciones en las que se va a ejecutar el disparador. Esto se descompone
en un evento que causa la comprobación del disparador y una condición que se debe
cumplir para ejecutar el disparador.
2. Especificar las acciones que se van a realizar cuando se ejecute el disparador.
Este modelo de disparadores se denomina modelo evento-condición-acción.
La base de datos almacena disparadores como si fuesen datos normales, por lo que son
persistentes y accesibles para todas las operaciones de la base de datos. Una vez se almacena un
disparador en la base de datos, el sistema de base de datos asume la responsabilidad de ejecutarlo
cada vez que ocurra el evento especificado y se satisfaga la condición correspondiente.
Necesidad de los disparadores
Los disparadores son mecanismos útiles para alertar a los usuarios o para realizar de manera
automática ciertas tareas cuando se cumplen determinadas condiciones. A modo de ejemplo
supóngase que, en lugar de permitir saldos de cuenta negativos, el banco trata los descubiertos
dejando a cero el saldo de las cuentas y creando un préstamo por el importe del descubierto. Este
préstamo recibe un número de préstamo idéntico al número de cuenta que ha tenido el
descubierto. En este ejemplo la condición para ejecutar el disparador es una actualización de la
relación cuenta que dé lugar a un valor negativo de saldo. Supóngase que Santos retiró cierta
cantidad de dinero de una cuenta que dio lugar a que el saldo de la cuenta fuera negativo. t
denota la tupla de la cuenta con un valor negativo de saldo. Las acciones que hay que emprender
son las siguientes:
• Insertar una nueva tupla s a la relación préstamo con
s[nombre-sucursal] = t[nombre-sucursal]
s[número-préstamo] = t[número-cuenta]
s[importe] = – t[saldo]
(Obsérvese que, dado que t[saldo] es negativo, hay que cambiar el signo de t[saldo] para obtener
el importe del préstamo – un número positivo).
Insertar una nueva tupla u a la relación prestatario con
u[nombre-cliente] = «Santos»
u[número-préstamo] = t[número-cuenta]
Hacer que t[saldo] sea 0.
Como otro ejemplo del uso de disparadores, supóngase un almacén que desee mantener un
inventario mínimo de cada producto; cuando el nivel de inventario de un producto cae por debajo
del nivel mínimo, se debería solicitar un pedido automáticamente. Para implementar con
disparadores esta regla de negocio se haría: al modificar el nivel de inventario de un producto, el
disparador debería comparar el nivel con el mínimo y si el nivel es inferior al mínimo, se
añadiría un nuevo pedido a la relación pedido.
Obsérvese que los sistemas de disparadores en general no pueden realizar actualizaciones
fuera de la base de datos, y por lo tanto, en este último ejemplo, no se puede usar un disparador
para realizar un pedido en el mundo externo. En su lugar se añade un pedido a la relación
pedidos como en el ejemplo del inventario. Se debe crear un proceso del sistema separado que se
esté ejecutando constantemente que explore periódicamente la relación pedidos y solicite los
pedidos. Este proceso del sistema anotaría las tuplas de la relación pedidos que se han procesado
y cuándo se ha procesado cada pedido. El proceso también llevaría cuenta del despacho de
pedidos y alertaría a los gestores en caso de condiciones excepcionales tales como retrasos en las
entregas.
Disparadores en SQL
Los sistemas de bases de datos SQL usan ampliamente los disparadores, aunque antes de
SQL:1999 no fueron parte de la norma. Por desgracia, cada sistema de bases de datos
implementó su propia sintaxis para los disparadores, conduciendo a incompatibilidades. En la
Figura 1. se describe la sintaxis SQL:1999 para los disparadores (que es similar a la sintaxis de
los sistemas de bases de datos DB2 de IBM y de Oracle).
create trigger descubierto after update on cuenta
referencing new row as nfila
for each row
when nfila.saldo < 0
begin atomic
insert into prestatario
(select nombre-cliente, número-cuenta
from impositor
where nfila.número-cuenta = impositor.número-cuenta);
insert into préstamo values
(nfila.número-cuenta, nfila.nombre-sucursal, – nfila.saldo)
update cuenta set saldo = 0
where cuenta.número-cuenta = nfila.número-cuenta
end
Figura 1. Ejemplo de la sintaxis de SQL:1999 para los disparadores.
Esta definición de disparador especifica que el disparador se inicia después (after) de cualquier
actualización de la relación cuenta. Una instrucción de actualización SQL podría actualizar
múltiples tuplas de la relación, y la cláusula for each row en el código del disparador se iteraría
explícitamente por cada fila actualizada. La cláusula referencing new row as crea una variable
nfila (denominada variable de transición) que almacena el valor de una fila actualizada después
de la actualización.
La instrucción when especifica una condición, en este caso nfila.saldo < 0. El sistema ejecuta el
resto del cuerpo del disparador sólo para las tuplas que satisfacen la condición. La cláusula begin
atomic ... end sirve para encuadrar varias instrucciones SQL en una única instrucción
compuesta. Las dos instrucciones insert en la estructura begin ... end realizan las tareas
específicas para la creación de nuevas tuplas en las relaciones prestatario y préstamo para
representar el nuevo préstamo. La instrucción update sirve para establecer en 0 el saldo de la
cuenta.
El evento del disparador puede tener varias formas:
• El evento del disparador puede ser insert o delete en lugar de update.
Por ejemplo, la acción sobre el borrado (delete) de una cuenta podría comprobar si los tenedores
de la cuenta tienen otras cuentas y, si no las tienen, borrarlas de la relación impositor.
Como otro ejemplo, si se inserta un nuevo impositor, la acción del disparador podría ser enviar
una carta de bienvenida al impositor. Obviamente, un disparador no puede causar directamente
esta acción fuera de la base de datos, pero en su lugar sí puede insertar una nueva tupla a una
relación que almacene las direcciones a las que se deben enviar las cartas de bienvenida. Un
proceso separado examinaría esta relación e imprimiría las cartas a enviar.
• Para las actualizaciones el disparador puede especificar columnas cuya actualización cause
la ejecución del disparador. Por ejemplo, si la primera línea del disparador de descubiertos se
reemplazase por
create trigger descubierto after update of saldo on cuenta
entonces el disparador se ejecutaría sólo cuando se actualizase saldo; las actualizaciones del
resto de atributos no causarían su ejecución.
La cláusula referencing old row as se puede usar para crear una variable que almacene
el valor anterior de una fila actualizada o borrada. La cláusula referencing new row as se
puede usar con las inserciones además de las actualizaciones.
Los disparadores se pueden activar antes(before) del evento (insert/delete/update) en
lugar de después (after) del evento.
Estos disparadores pueden servir como restricciones extras que pueden evitar actualizaciones no
válidas. Por ejemplo, si no se desea permitir descubiertos, se puede crear un disparador before
que retroceda la transacción si el nuevo saldo es negativo.
Como otro ejemplo, supóngase que el valor del campo de número telefónico de una tupla
insertada está vacío, que indica la ausencia de un número de teléfono. Se puede definir un
disparador que reemplace el valor por el valor null. Se puede usar la instrucción set para realizar
estas modificaciones.
create trigger poner-nulo before update on r
referencing new row as nfila
for each row
when nfila.número-teléfono = ′ ′
set nfila.número-teléfono = null
En lugar de realizar una acción por cada fila afectada, se puede realizar una acción única
para la instrucción SQL completa que causó la inserción, borrado o actualización. Para
hacerlo se usa la cláusula for each statement en lugar de for each row.
Las cláusulas referencing old table as o referencing new table as se pueden usar entonces
para hacer referencia a tablas temporales (denominadas tablas de transición) conteniendo todas
las filas afectadas. Las tablas de transición no se pueden usar con los disparadores before, pero sí
con los after, independientemente de si son disparadores de instrucciones (statement) o de filas
(row).
Una instrucción SQL única se puede usar entonces para realizar varias acciones en términos de
las tablas de transición.
Volviendo al ejemplo de inventario del almacén, supóngase que se tienen las siguientes
relaciones:
inventario(producto, nivel), que denota la cantidad actual (número/peso/volumen) del
producto en el almacén.
nivelmínimo(producto, nivel), que denota la cantidad mínima a mantener de cada
producto.
nuevopedido(producto, cantidad), que denota la cantidad de producto a pedir cuando su
nivel cae por debajo del mínimo.
pedidos(producto, cantidad), que denota la cantidad de producto a pedir.
Se puede usar entonces el disparador mostrado en la Figura 6.4 para solicitar un nuevo pedido
del producto. Obsérvese que se ha sido cuidadoso a la hora de realizar un pedido sólo cuando su
cantidad caiga desde un nivel superior al mínimo a otro inferior. Si sólo se comprobase si el
nuevo valor después de la actualización está por debajo del mínimo, se podría realizar
erróneamente un pedido cuando el producto ya se ha pedido. Muchos sistemas de bases de datos
proporcionan implementaciones no estándar de disparadores, o implementan sólo algunas de las
características de los disparadores. Por ejemplo, muchos de los sistemas de bases de datos no
implementan la cláusula before, y usan la palabra clave on en lugar de after. Puede que no
implementen la cláusula referencing. En su lugar, pueden especificar tablas de transición usando
las palabras clave inserted o deleted. La Figura 2. ilustra cómo se escribiría el disparador de los
descubiertos de las cuentas en SQLServer de Microsoft. Consúltese el manual del sistema de
bases de datos que se esté usando para obtener más información sobre las características de los
disparadores que soporta.
Cuándo no deben usarse los disparadores
Hay muchos buenos usos de los disparadores, como los que se acaban de ver en el Apartado
DISIPADORES EN SQL, pero algunos usos se manejan mejor con otras técnicas. Por ejemplo,
anteriormente, los diseñadores de sistemas usaban los disparadores para realizar resúmenes de
datos. Por ejemplo, usaban disparadores bajo la inserción, borrado o actualización de una
relación empleado que contiene los atributos sueldo y dept para mantener el sueldo total de cada
departamento. Sin embargo, muchos sistemas de bases de datos actuales soportan las vistas
materializadas, que proporcionan una forma mucho más sencilla de mantener los datos de
resumen. Los diseñadores también usaban ampliamente los disparadores para las réplicas de las
bases de datos; usaban disparadores bajo la inserción, borrado o actualización de las relaciones
para registrar los cambios en relaciones cambio o delta. Un proceso separado copia- ba los
cambios a la réplica (copia) de la base de datos, y el sistema ejecutaba los cambios sobre la
réplica. Sin embargo, los sistemas de bases de datos modernos pro- porcionan características
incorporadas para la réplica de bases de datos, haciendo innecesarios a los dispara- dores para la
réplica en la mayoría de los casos.
De hecho, muchas aplicaciones de disparadores, incluyendo el ejemplo de descubiertos, se
pueden sus- tituir por las características de «encapsulación» intro- ducidas en SQL:1999. La
encapsulación se puede usar para asegurar que las actualizaciones del atributo saldo de cuenta se
hagan sólo mediante un procedimiento especial. Este procedimiento comprobaría un saldo nega-
tivo y realizaría las acciones de disparador de descu- biertos. Las encapsulaciones pueden
reemplazar el dis- parador de nuevos pedidos de forma similar.
create trigger nuevopedido after update of cantidad on inventario
referencing old row as ofila, new row as nfila
for each row
when nfila.nivel <= (select nivel
from nivelmínimo
where nivelmínimo.producto = ofila.producto)
and ofila.nivel <= (select nivel
from nivelmínimo
where nivelmínimo.producto = ofila.producto)
begin
insert into pedidos
(select producto, cantidad
from nuevopedido
where nuevopedido.producto= ofila.producto);
end
figura 2. Ejemplo de un disparador para hacer un nuevo pedido de un producto.
define trigger descubierto on cuenta
for update
as
if nfila.saldo < 0
begin
insert into prestatario
(select nombre-cliente, número-cuenta
from impositor, inserted
where inserted.número-cuenta = impositor.número-cuenta)
insert into préstamo values
(inserted.número-cuenta, inserted.nombre-sucursal, – inserted.saldo)
update cuenta set saldo = 0
from cuenta, inserted
where cuenta.número-cuenta = inserted.número-cuenta))
end
figura 3. Ejemplo de disparador en la sintaxis de SQL Server de Microsoft.
Los disparadores se deberían escribir con sumo cuidado, dado que un error de un disparador
detectado en tiempo de ejecución causa el fallo de la instrucción de inserción, borrado o
actualización que inició el disparador. En el peor de los casos esto podría dar lugar a una cadena
infinita de disparos. Por ejemplo, supóngase que un disparador de inserción sobre una relación
realice otra (nueva) inserción sobre la misma relación. La acción de inserción dispara otra acción
de inserción, y así hasta el infinito. Generalmente, los sistemas de bases de datos limitan la
longitud de las cadenas de disparado res (por ejemplo, hasta 16 o 32), y consideran que las
cadenas mayores son erróneas.
Los disparadores (desencadenadores en terminología de Microsoft) se denominan a veces reglas
o reglas activas, pero no se deben confundir con las reglas Datalog, que son realmente
definiciones de vistas.
La palabra clave new utilizada delante de T.saldo indica que debe utilizarse el valor de T.saldo
posterior a la actualización; si se omite, se utilizará el valor previo a la actualización.
[ CITATION Sil02 \l 3082 ].
Desencadenadores o Disparadores
Un trigger, desencadenador 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 y otros objetos.
Características de los triggers:
Se definen para una tabla (o vista) específica.
Se crean para conservar la integridad referencial y la coherencia entre los datos entre
distintas tablas.
Si se intenta modificar (agregar, actualizar o eliminar) datos de una tabla en la que se
definió un trigger para alguna de estas acciones (inserción, actualización y
eliminación), el trigger se ejecuta (se dispara) en forma automática.
Un trigger se asocia a un evento (inserción, actualización o borrado) sobre una tabla.
La diferencia con los procedimientos almacenados del sistema es que los triggers:
o no pueden ser invocados directamente; al intentar modificar los datos de una
tabla para la que se ha definido un disparador, el disparador se ejecuta
automáticamente.
o no reciben y retornan parámetros.
o son apropiados para mantener la integridad de los datos, no para obtener
resultados de consultas.
Los triggers pueden realizar cambios en cascada mediante tablas relacionadas de la
base de datos; sin embargo, estos cambios pueden ejecutarse de manera más eficaz
con restricciones de integridad referencial en cascada. Las restricciones llaves
foráneas (FOREIGN KEY) solo pueden validar un valor de columna si coinciden
exactamente con un valor de otra columna, a menos que la cláusula REFERENCES
defina una acción referencial en cascada.
Varios triggers del mismo tipo (INSERT, UPDATE o DELETE) en una tabla
permiten realizar distintas acciones en respuesta a una misma instrucción de
modificación.
Tipos de trigger que existen
AFTER triggers.
Los triggers AFTER se ejecutan después de llevar a cabo una acción de las instrucciones
INSERT, UPDATE, MERGE o DELETE. Los triggers AFTER no se ejecutan nunca si se
produce una infracción de restricción; por tanto, no se puede usar estos triggers para ningún
procesamiento que pueda impedir infracciones de restricciones. Para cada acción INSERT,
UPDATE o DELETE especificada en una instrucción MERGE, se activa el triggers
correspondiente para cada operación.
INSTEAD OF triggers
Los triggers INSTEAD OF pasan por alto las acciones estándar de la instrucción de
desencadenamiento. Por lo tanto, se pueden usar para realizar comprobación de errores o
valores en una o más columnas y, a continuación, realizar acciones adicionales antes de
insertar, actualizar o eliminar la fila o las filas. Por ejemplo, cuando el valor que se actualiza
en una columna de tarifa de una hora de trabajo de una tabla de nómina supera un valor
específico, se puede definir un trigger para producir un error y revertir la transacción, o
insertar un nuevo registro en un registro de auditoría antes de insertar el registro en la tabla de
nómina. La principal ventaja de los triggers INSTEAD OF es que habilitan las vistas que no
serían actualizables para admitir actualizaciones. Por ejemplo, las vistas que contengan varias
tablas base deben usar un trigger INSTEAD OF para permitir inserciones, actualizaciones y
eliminaciones que hagan referencia a datos de más de una tabla. Otra ventaja de los triggers
INSTEAD OF es que permiten codificar la lógica para rechazar partes de un lote y, al mismo
tiempo, aceptar otras partes del mismo.
Los triggers se crean con la instrucción "create trigger". Esta instrucción especifica la tabla en
la que se define el disparador, los eventos para los que se ejecuta y las instrucciones que
contiene.
[ CITATION est \l 3082 ]
¿Qué es un trigger, desencadenador o disparador y cómo crearlo?
Un trigger es una clase especial de procedimiento almacenado que se ejecuta automáticamente
cuando se produce un evento en el servidor de bases de datos. Los trigger se ejecutan cuando
un usuario intenta modificar datos mediante un evento de lenguaje de manipulación de datos
(DML*). Los eventos DML son instrucciones INSERT, UPDATE o DELETE de una tabla o
vista. Estos triggers se activan cuando se desencadena cualquier evento válido, con
independencia de que las filas de la tabla se vean o no afectadas.
* Definición de DML
Un lenguaje de manipulación de datos (Data Manipulation Language, o DML en inglés) es un
lenguaje proporcionado por el sistema de gestión de base de datos que permite a los usuarios
llevar a cabo las tareas de consulta o manipulación de los datos, organizados por el modelo de
datos adecuado.
El lenguaje de manipulación de datos más popular hoy día es SQL, usado para recuperar y
manipular datos en una base de datos relacional.
[ CITATION sit \l 3082 ]
La sentencia que se utiliza para añadir triggers al esquema de base de datos es CREATE
TRIGGER.
La sintaxis general de un trigger es la siguiente:
CREATE TRIGGER <Schema_Name, sysname, Schema_Name>.<Trigger_Name, sysname,
Trigger_Name>
ON <Schema_Name, sysname, Schema_Name>.<Table_Name, sysname, Table_Name>
AFTER <Data_Modification_Statements, , INSERT,DELETE,UPDATE>
AS
BEGIN
-- SET NOCOUNT ON added to prevent extra result sets from
-- interfering with SELECT statements.
SET NOCOUNT ON;
-- Insert statements for trigger here
END
Los triggers utilizan dos tablas virtuales denominadas inserted y deleted. SQL Server crea y
administra automáticamente ambas tablas. La estructura de las tablas inserted y deleted es la
misma que tiene la tabla que ha desencadenado la ejecución del trigger.
La tabla virtual Inserted solo está disponible en las operaciones INSERT y UPDATE y en ella
están los valores resultantes después de la inserción o actualización.
La tabla Deleted está disponible en las operaciones UPDATE y DELETE, los valores que
tiene esta tabla son los anteriores a la ejecución de la actualización o borrado. Es decir, los
datos que serán borrados.
No existe una tabla Updated ya que la actualización reside en Deleted e Inserted.
1. Abrimos el Microsoft SQL Server Management Studio
2. Vamos a nuestra base de datos y extendemos el árbol hasta la tabla que queremos
agregar el trigger.
3. En la carpeta Triggers damos botón derecho de nuestro mouse y damos clic en “New
Trigger.
4. Se abrirá una pestaña con la estructura básica de un Trigger y lo modificamos de
acuerdo a nuestras necesidades. En el siguiente ejemplo puedes ver cada una de las
instrucciones comentadas para que puedas ver que es lo que hace.
--Crea un trigger llamado AddCines
CREATE TRIGGER AddCines
--Se ejecutara en la tabla Cinemex_Ciudades
ON Cinemex_Ciudades
--Se ejecutara despues de un Insert o un Update a la tabla
AFTER INSERT,UPDATE
AS
BEGIN
-- SET NOCOUNT ON impide que se generen mensajes de texto con cada instrucción
SET NOCOUNT ON;
-- Se crea un Insert: cuando se inserten valores en la tabla Cinemex_Ciudades, el trigger insertara un
registro en la tabla Cinemex_Cines
INSERT INTO Cinemex_Cines
(ID, IDCiudad, Cine, Direccion)
SELECT '500', ID, 'Cinemex ' + Ciudad, 'Prueba'
FROM INSERTED
--Los valores que se insertaran, seran los que esten almacenados en la tabla virtual Inserted
END
GO
[ CITATION est1 \l 3082 ]
Bibliografía
FUNDAMENTOS DE BASES DE DATOS, Cuarta edición, Abraham Silberschatz
(Bell Laboratories), Henry F. Korth (Bell Laboratories), S. Sudarshan (Instituto Indio de
Tecnología, Bombay)
DERECHOS RESERVADOS © 2002, respecto a la cuarta edición en español, por
McGRAW-HILL/INTERAMERICANA DE ESPAÑA, S. A. U. a
Edificio Valrealty, 1. planta Basauri, 17, 28023 Aravaca (Madrid)
Webgrafía
https://www.estradawebgroup.com/Post/Que-es-un-Trigger-o-Desencadenador/1031
https://estradawebgroup.com/Post/Cómo%20crear%20un%20trigger%20o
%20desencadenador/1032
https://sites.google.com/site/sqlismysin/home/lenguaje-de-manipulacion-de-datos-dml-
data-manipulation-language
https://www.academia.edu/31208981/TRIGGERS_Y_PROCEDIMIENTO_ALMACENAD
O