Los procedimientos almacenados y los triggers permiten mejorar el rendimiento de .lasbases de datos en SQL Server, al tiempo que automatizan el proceso de actualización delaos datos siguiendo las decisiones y procesos de negocio.
Microsoft
ha apostado muy fuerte con SQL Server 6.5 paraofrecer una alternativa económica, potente, flexible y escalable para la gestión debases de datos relacionales cliente/servidor. Como todos sabéis SQL Server 6.5es parte integrante de la suite BackOffice, que se completa con, entre otrosproductos, el sistema operativo Windows NT, el servidor de correo ExchangeServer , o el producto de Microsoft para el acceso a entornos AS-400: SNAServer. Precisamente en estos días la empresa de Bill Gates está presentandoen España algunas novedades de la versión 2.5 de BackOffice, en la que el gestorde bases de datos objeto de este artículo se ha mantenido sin modificación.Entre las principales características de las que Microsoft hadeseado dotar a SQL Server 6.5 podríamos destacar su facilidad de administración,su casi íntima integración con Windows NT y sus excelentes rendimientos enentornos hardware relativamente modestos. Aquellas empresas que tengan WindowsNT como sistema operativo de red encontrarán que SQL Server 6.5 resultasin duda la alternativa más natural.
Microsoft presenta a su gestor de bases de datos como un productoque permite obtener grandes rendimientos en la gestión de los datos, pero, sobre todo,como un motor de bases de datos que es capaz de asumir las decisiones de negocio en laactualización de los datos, de manera que las aplicaciones cliente puedan simplificarseal no tener que contemplar las siempre complicadas tareas de validación y respuesta amodificaciones.
Integrar las decisiones de negocio en la base de datos
El párrafo anterior puede servir como barrera a algún lector a lahora de continuar leyendo este artículo, porque contiene algunos términos que resultan,cuando menos, confusos. ¿Qué significa que Microsoft recomienda incluir lasdecisiones de negocio en la base de datos?. ¿Qué es la lógica de negocio?
Podríamos decir, de manera coloquial, que la lógica de negocioaplicada a los datos son reglas de coherencia de los mismos que vienen determinadas por laactividad de la empresa que los utiliza. Pongamos como ejemplo una empresa que se dedica aactividades comerciales y desea incentivar a todos sus empleados con un aumento de sueldocuando se haya alcanzado una cifra determinada de ventas. Si la empresa almacena dichasventas y los sueldos de sus empleados en campos de su base de datos, la realización deuna determinada venta, la que hace el número deseado y que hará que los sueldos seaumenten, debería provocar la actualización de los sueldos de todos los empleados.
Tras añadir la nueva venta los sueldos de los empleados, sinactualizar, contienen datos que en principio pueden pensarse como perfectamente correctos,pero que desde el punto de vista de la empresa no lo son. Podemos decir que la dinámicadel negocio de la empresa ha impuesto, por sí misma, una cierta lógica que losdatos de la base de datos deben respetar para que la base de datos se mantengasintácticamente coherente.
La recomendación de Microsoft es que el cumplimiento de lalógica de los negocios que utilizan como gestor de bases de datos SQL Server 6.5no se consiga a través de aplicaciones cliente externas que comprueben las condicionesque deben cumplirse, bien a intervalos regulares o en cada modificación de los datos dela base. La filosofía que debe aplicarse es dotar a la base de datos de una serie demecanismos para que ella misma se mantenga siempre coherente, respondiendo de maneraautomática a las modificaciones de los datos y realizando las actualizaciones que seannecesarias.
Con esta manera de operar se obtienen entornos más autosuficientes ycon aplicaciones cliente mucho más sencillas. Sin embargo, la base de datos debedefinirse, o mejor, programarse, mediante un mecanismo que denominamos triggers.
Obtenerbuenos rendimientos
La clave de los buenos rendimientos de SQL Server 6.5 es quizásu estrecho vínculo con el sistema operativo que le lleva a sacar partido máximo delmismo y del hardware. Por otra parte, cualquier administrador de una gestor de basede datos sabe que para que una consulta se lleve a cabo de manera eficiente es necesarioque esté adecuadamente optimizada.
Este proceso de optimización es generalmente uno de los más costososen el ciclo de trabajo del gestor en la obtención de datos. En entornos cliente /servidorlas aplicaciones cliente enviarán consultas al gestor, que deberá optimizarlas,procesarlas y devolver los resultados.
Afortunadamente los usuarios de la base de datos no suelen serdemasiado imaginativos, de manera que muchas de las consultas u operaciones con los datossuelen obedecer a un patrón o modelo que se repite muy frecuentemente. Inmediatamentesurge la idea de que el admisnistrador cree por su cuenta las consultas más repetidas ylas ofrezca a los clientes, facilitando su operación y uniformando los formatos depeticiones de datos. Esta idea, si bien es interesante, no conlleva necesariamente unamejora en los rendimientos del gestor, sino simplemente una simplificación de losprocesos.
Para conseguir mejores rendimientos SQL Server incluye elconcepto de procedimientos almacenados como objetos de la base de datos querepresentan secuencias de sentencias SQL que se preoptimizan y preprocesan antes desu almacenamiento, de manera que estos costosos procesos se evitan en cada petición dedatos por parte de los usuarios.
En los siguientes apartados pasaremos a describir, a modo deintroducción, como iniciarse en el aprovechamiento de los triggers y losprocedimientos almacenados, es decir, daremos algunas claves introductorias a la programaciónde bases de datos en SQL Server 6.5
Qué es unprocedimiento almacenado
Como ya hemos comentado, un procedimiento almacenado (storedprocedure no es más que una colección de sentencias Transact SQL (eldialecto SQL de SQL Server 6.5) que se constituye como si de una función deun lenguaje estructurado (C, Pascal ) se tratase. Es decir, es posible llamarlomediante un identificador, puede recibir argumentos y devolver un valor deretorno.
Transact SQL, es una versión extendida del lenguaje ANSI SQL queposee características que hacen que puedan definirse pseudo funciones. Así, y amodo de ejemplo, es posible definir variables, posee estructuras de control de flujo, etc.
La característica primordial de los procedimientos almacenados es quese optimizan en el momento de su creación. Esto supone que, a diferencia de lo que sucedecon las sentencias SQL que se envían el gestor de manera interactiva, los procedimientosalmacenados pasan previamente por un proceso de normalización.
Cuando se crea un procedimiento almacenado el procesador de consultasdel gestor crea una versión del mismo con una cierta estructura normalizada, y laalmacena en una de las tablas de sistema. Las siguientes ejecuciones de dichoprocedimiento, no necesitarán consumir el tiempo necesario para llevar a cabo esteproceso de normalización, con lo que su ejecución será más rápida.
Por otra parte, cuando el procedimiento se ejecuta por vez primera, seproduce su compilación y la optimización del acceso del procedimiento a los datos. Esteproceso optimizado se mantiene en memoria para posteriores ejecuciones con el consiguienteahorro adicional de tiempo y recursos.
Qué es un trigger
Un trigger no es más que un tipo especial de procedimientoalmacenado. En lugar de ejecutarse como respuesta a una llamada, se ponen enfuncionamiento automáticamente como respuesta a ciertas modificaciones de los datos, cuyanaturaleza se especifica en el momento de la creación del trigger.
La utilidad de los triggers es múltiple. Quizá la másampliamente utilizada es la de establecer reglas de consistencia entre los datospresentes en las diferentes tablas de nuestra base de datos. Los triggers son unaherramienta poderosa para centralizar en la base de datos la toma de las decisiones denegocio que se asocian a los datos de la misma. De esta manera se descarga en gran medidaa las aplicaciones cliente de la tarea de revisar las acciones de actualización de datos.
Como hemos dicho, las acciones que motivarán que un trigger seponga en ejecución, es decir aquellas acciones que disparan el trigger, sonmodificaciones que puedan llevarse a cabo en los datos, tanto la adición de datos nuevoscomo la eliminación de datos existentes. Dichas modificaciones se llevan a cabo,evidentemente, mediante la ejecución de las sentencias UPDATE, DELETEo INSERT.
Supongamos el caso en el que existan dos tablas Existencias y Ventasde manera que cada vez que se produce una nueva venta deben actualizarse las unidadesque aún quedan en existencias. La solución a este problema, si se sigue la filosofía detoma de decisiones mediante triggers que Microsoft recomienda utilizar con SQLServer, es dejar que sea la propia base de datos la que se encargue de realizar lasactualizaciones de manera automática. Es posible definir un trigger que realicelas tareas descritas y que se ponga en ejecución inmediatamente después a la operaciónde borrado o inserción.
Así, cuando dicha acción de modificación se complete, el triggeradecuado se disparará. Pueden definirse triggers que respondan a una ovarias de estas acciones, es decir, puede definirse un trigger que responda tanto auna operación INSERT, como a una DELETE.
De este modo, los triggers pueden utilizarse pararesolver, entre otras, las siguientes situaciones:
Creación deprocedimientos almacenados
Exsiten dos maneras de crear procedimientos almacenados: utilizando lasentencia CREATE PROCEDURE y mediante Enterprise Manager
La sentencia CREATE PROCEDURE
La sentencia Transact-SQL que permite crear procedimientosalmacenados es CREATE PROCEDURE. Permite crear un procedimiento almacenado apartir de una determinada colección de sentencias SQL ligadas por sentencias adicionalesde control de flujo
La sintaxis de esta sentencia es la siguiente:
| CREATE PROCEDURE [propietario.] nombre de procedimiento[;número] [(lista de parámetros) ] [{FOR REPLICATION} | {WITH RECOMPILE} [{[WITH] | [,]} ENCRYPTION]] AS sentencias SQL |
Parámetros
Como hemos comentado anteriormente, los procedimientos almacenadospermiten que su ejecución pueda ser adaptada a la situación y ámbito en el que seanllamados. Para ello, al igual que las funciones y procedimientos en lenguajes deprogramación estructurada, pueden recibir parámetros. Así el procedimiento recibirdatos diversos en función de la situación en la que la llamada se realice.
La definición de parámetros se lleva a cabo en el momento de lacreación del procedimiento almacenado. Cuando el usuario solicite la ejecución de unprocedimiento definido con parámetros deberá suministrar valores para ellos
La sintaxis de definición de un parámetro es la siguiente:
Puede especificarse un valor por defecto para cada parámetro.La manera de especificar un valor por defecto es colocar después del nombre de parámetroel signo = seguido por la constante que se utilizará como valor.
De igual modo, también es posible definir ciertos parámetros como deretorno. Este tipo de parñametros se especifican como cualquier otro, con lasalvedad de que sus nombres aparecen seguidos por la palabra clave OUTPUT. Cuandoel procedimiento se ejecute devolverá en esos parámetros los valores que hayan tomado enel interior del mismo. Estos valores podrán ser almacenados en variables y utilizadosposteriormente.
RECOMPILE: Procedimientos de recompilación forzosa
Imaginemos que generamos un procedimiento almacenado cuyos parámetrospuedan ser de tipos muy diversos. Esto supondrá que sea común que la optimización quese ha llevado a cabo en primera instancia, no sea válida para otras ejecuciones delprocedimiento. Por otra parte, es común que frecuentemente se añadan nuevos índices quehagan que la optimización de la consulta deje también de ser válida.
El rendimiento en este tipo de situaciones no es el más adecuado, puesse ralentizan las operaciones. Es en estos casos necesario que el procedimiento almacenadose recompile cada vez que se ejecuta, desoyendo o deshabilitando la característica deoptimización única que antes hemos presentado. La cláusula que permite indicar que elprocedimiento debe ser recompilado en cada ejecución es WITH RECOMPILE
Sentencias SQL del procedimiento almacenado
El cuerpo del procedimiento estará integrado por un conjunto desentencias SQL que realizarán las tareas que esperamos del mismo y que se especificaránen la definición del procedimiento siguiendo a la cláusula AS
En general podemos decir que en un procedimiento almacenado puedenincluirse cualquier número y tipo de sentencias Transact SQL. Sin embargo, esnecesario comentar algunas restricciones respecto a la creación de objetos Nopueden incluirse las siguientes sentencias CREATE
Creación de procedimientos almacenados mediante Enterprise Manager
Hasta este momento hemos presentado la sintaxis de la sentencia TransactSQL que permite crear procedimientos almacenados. A continuación recordaremos elprocedimiento necesario para crear un procedimiento almacenado mediante EnterpriseManager
Para ello deberán seguirse los siguientes pasos:
Una vez creado el procedimiento, esto es, una vez definido, SQLServer generará el siguiente código.
| if exists (select * from sysobjects where id = object_id('dbo.infousuarios') and sysstat & 0xf = 4) drop procedure dbo.infousuarios GO CREATE PROCEDURE infousuarios AS SELECT * FROM sysusers GO |
Las líneas adicionales evitarán que se intenten crear dos procedimientos con el mismo nombre.
Eliminación de procedimientos almacenados
La sentencia DROP PROCEDURE sirve para eliminar delcatálogo un procedimiento almacenado y su sintaxis y uso resulta totalmente análogo alas que se utilizan para eliminar cualquier otro objeto de una base de datos
Ejecuciónde procedimientos almacenados
Una vez se ha creado un procedimiento almacenado, se encontrará endisposición de ser ejecutado. Si en la primera línea de una secuencia de sentencias Transact_SQLaparece el nombre de un procedimiento almacenado, SQL Server lo ejecutará. Enel resto de situaciones deberemos utilizar la sentencia EXECUTE
Esta sentencia se utiliza para la ejecución de todo tipo deprocedimientos almacenados, tanto de sistema, como de usuario. Por otra parte tambiénpermite la ejecución de una cadena de caracteres que contiene una cierta sentencia Transact_SQL
Su sintaxis es la siguiente:
| EXEC[ute] {[@valor de retorno =]{[[[nombreproc[;num]|@variablenombre} [[@parámetro =] {valor | @variable [OUTPUT]] [, [@parámetro =] {valor | @variable [OUTPUT]}]...] [WITH RECOMPILE]] |
El procedimiento que se ejecutará es el especificado en nombreproc.El nombre del procedimiento puede estar contenido en una variable como aquí @variablenombre.
Valor de retorno
Como hemos comentado anteriormente, los procedimientos almacenadospueden, opcionalmente devolver un valor. Si esto es así, este valor retornado deberá seralmacenado en una variable que en la sintaxis hemos presentado como @valor de retorno.
Informaciónretornada por un procedimiento almacenado
Los procedimientos almacenados pueden retornar información alprocedimiento que los llamó o al usuario que solicita su ejecución básicamente de dosmodos:
Valor de estado (status value)
Es una práctica común la mayoría de lenguajes de programación elhacer que los procedimientos o funciones retornen un valor que permita testear cual hasido el modo o resultado con el que la ejecución de dicha función ha concluido.
Generalmente dichos valores son definidos de antemano de manera que unmero análisis del valor de estado permita conocer qué ha sucedido.
Los procedimientos almacenados SQL Server devuelventambién un valor de estado o status value. Este valor puede ser almacenado en unavariable de manera que pueda examinarse posteriormente para valorar el éxito de suejecución o el motivo de su fracaso.
Veamos un ejemplo:
CREATE PROCEDURE aprobado @nombrealumno varchar(20) AS IF (SELECT nota FROM alumnos WHERE nombre = @nombrealumno) > 5 RETURN 100 ELSE RETURN 200 |
Podríamos definir un nuevo procedimiento almacenado que utilice a esteprimero
CREATE PROCEDURE mostrarestado @nombrealumno varchar(20) AS DECLARE @valorderetorno int EXECUTE @valorderetorno = aprobado @nombrealumno IF (@valorderetorno = 100 ) PRINT ‘Alumno aprobado’ ELSE PRINT ‘Alumno suspenso’ |
Retorno de parámetros
En el momento de la creación y definición de un procedimientoalmacenado puede especificarse que alguno, o todos, los parámetros que dichoprocedimiento aceptará sean considerados parámetros de retorno.
Veamos un ejemplo de uso de procedimiento almacenado con paso deparámetros
CREATE PROCEDURE suma @sum1 int, @sum2 int, @res int OUTPUT AS SELECT @res = @ sum1 + @sum2 RETURN 0 |
Veamos un ejemplo de utilización
DECLARE @resultado int DECLARE @retorno int EXECUTE @retorno = suma 2, 2, @resultado OUTPUT En este punto @retorno valdrá 0 y @resultado tendrá como valor 4. |
Creación detriggers
La sentencia Transact-SQL que permite crear triggers es CREATETRIGGER.
| CREATE TRIGGER [propiet.] nombretrigger ON [propiet.]nombretabla FOR {INSERT, UPDATE, DELETE} [WITH ENCRYPTION] AS sentenciasSQL |
Acciones que desatan la ejecución del trigger
El trigger se ejecuta como respuesta a la aplicación de ciertassentencias de modificación sobre la tabla asociada al mismo. Estas sentencias seespecifican en la cláusula FOR UPDATE/INSERTDELETE Cuando se lleven a cabo la olas acciones que se especifiquen en la definición del trigger sobre la tabla, lassentencias que lo conforman se ejecutarán.
De esta manera, pueden definirse hasta tres triggers diferentespara cada tabla, uno por cada acción INSERT, UPDATE o DELETE. En cualquier caso,es posible especificar en un sólo trigger, cualquier combinación de las tresacciones disponibles.
Sentencias SQL del trigger
El cuerpo del trigger constará de una serie de sentencias SQLque realizarán las tareas que esperamos del mismo y una serie de condiciones quedeterminarán de manera adicional si las acciones del trigger deben ser llevadas ono cabo.
En general podemos decir que en un trigger, como en cualquierprocedimiento almacenado, pueden incluirse cualquier número y tipo de sentencias TransactSQL. Sin embargo, y por su propia naturaleza, la de responder a una acción ejecutandootras, no es posible incluir en las sentencias del trigger la sentencia SELECT.
No son estas las únicas restricciones aplicables a las sentenciasejecutables en un trigger. Concretamente las siguientes sentencias no puedenutilizarse.
Veamos un ejemplo de un sencillo trigger que presenta un mensajecada vez que se añade un nuevo autor a la tabla authors de la base de datos pubs
Creación de triggers mediante Enterprise Manager
También es posible crear triggers mediante EnterpriseManager. A pesar de ser un objeto más de la base de datos, los triggers noaparecen en la ventana Server Manager, por lo que deberán ser creados utilizandoopciones de menú. Concreatamente deberán seguirse los siguientes pasos:
Eliminación de triggers
Para eliminar un trigger puede utilizarse la sentencia DROPTRIGGER, análogamente al resto de objetos. Puede eliminarse más de un triggerde manera simultánea pasando a la sentencia sus nombres separados por comas.
Utilizaciónde triggers para validar actualizaciones de tablas
Una de las principales utilidades de los triggers es la decontrolar que las operaciones de actualización que se llevan a cabo sobre una tabla seancoherentes. De este modo podemos centralizar en la base de datos los procesos devalidación de datos, tanto al añadir nuevos registros como en su eliminación.
Las tablas Inserted y Deleted
En multitud de ocasiones las operaciones de actualización de la tablaque suponen inserción y borrado de filas se llevan a cabo en cadena, normalmente por lapropia naturaleza de las sentencias implicadas.
En este tipo de situaciones el trigger que deba responder aestas acciones puede necesitar valorar qué cambios se han producido sobre la tabla demanera que se pueda obrar en consecuencia. Para ello se necesitaría disponer de algúnmodo de información del estado de la tabla antes y después de las modificacionesefectuadas. Para ello SQL Server proporciona dos tablas temporales denominadas
Para conocer el número de filas modificadas por una sentencia deactualización determinada es posible acudir a la variable global @@rowcount. Estavariable contiene el número de filas modificadas.
Inserción múltiple
La tabla inserted almacena una copia de las filas que se hanañadido durante la ejecución de una sentencia INSERT o UPDATE sobre unatabla que tiene asociado un trigger.
Borrado múltiple
La tabla deleted almacena una copia de las filas eliminadasdurante una sentencia DELETE o UPDATE. Evidentemente, una vez realizada laloperación de borrado, las filas desaparecerán de la tabla asociada al trigger ysólo aparecerán en la tabla deleted
Triggers y transacciones
Los triggers pueden descartar las transacciones en el marco delas cuales se ejecutan. Es decir, los triggers pueden ser ejecutados en respuesta auna acción que se haya inmersa en una transacción. Si uno de estos triggerscontiene la sentencia ROLLBACK TRANSACTION, que recordemos tiene como resultado eldescartar las operaciones realizadas en la transacción en curso, la transacción completaen la que dicho trigger se ejecuta será descartada.
Veamos un ejemplo en que la operación UPDATE tiene asociado un triggerque, por cualquier circunstancia que no nos detendremos a concretar, provoca que latransacción en curso sea descartada mediante ROLLBACK. En el ejemplo que sigue laoperación INSERT no se ejecutará, pues la transacción se dará por finalizadadespués de la sentencia UPDATE.
| BEGIN TRANSACTION UPDATE alumnos SET nota = nota + 1 WHERE notapracticas = 10 INSERT alumnos VALUES ('Javier Márquez', ‘Grupo3’, 5.5, 6.3, '6/11/96') END TRANSACTION |
Un ejemplocompleto
Para ilustrar los conceptos expuestos en este artículo vamos apresentar un pequeño ejemplo en el que se utilizan tanto procedimientos almacenados como triggers.
Nos proponemos informatizar una biblioteca creando una base de datosque mantenga información de los volúmenes existentes en su fondo, de los sociosinscritos y de los préstamos efectuados. Evidentemente, nuestro objetivo es simplementeilustrar el sentido y necesidad de procedimientos almacenados y triggers por lo queel diseño se ha simplificado al máximo evitando cualquier tipo de consideración sobreel modelo de datos.
Creación dela base de datos
El primer paso será definir siquiera burdamente las tablas necesarias.Del más sencillo análisis resulta que es necesario, al menos, definir una tabla libros,una segunda autores, una tercera socios, y una cuarta prestamos, queservirá para almacenar cada acción de préstamo que se lleve a cabo.
La definición de las tablas podemos realizarla mediante EnterpriseManager o utilizando sentencias Transact SQL. Por simplicidad haremos uso delas herramientas visuales de Enterprise Manager, tal y como podemos ver en lafigura A.6. Las sentencias Transact_Sql mínimas equivalentes serían
| CREATE TABLE libros (registro smallint signatura char(20), titulo varchar(50), nombreautor varchar(50) editorial varchar(20), fechaentrada datetime) |
| CREATE TABLE autores (idautor smallint nombreautor varchar(50), nacionalidad varchar(20)) |
| CREATE TABLE socios (idsocio smallint nombresocio varchar(50), edad smallint, direccion varchar(20), teléfono varchar(10)) |
| CREATE TABLE prestamos (idprestamo smallint idautor smallint, idsocio smallint, fechaprestamo datetime) |
Definiciónde procedimientos almacenados
Se supone que la base de datos estará disponible al público quevisite la biblioteca para que puedan consultar por su cuenta, por ejemplo, los libros deun determinado autor. La manera de hacer posibles estas consultas generalmente serámediante la programación de una pequeña aplicación cliente que enviará a SQL Serverlas peticiones de datos.
Parece evidente que la consulta Libros de un autor será muyfrecuente, de manera que será adecuado y adecuado definir en la base de datos unprocedimiento almacenado que reciba como argumento el nombre del autor del que se deseaconocer su obra completa. Este procedimiento se almacenará en SQL Server y suejecución será solicitada por las aplicaciones cliente, obteniendo un rendimiento mejoral que puede obtenerse con la simple realización de la consulta. Veamos una posibleimplementación de este procedimiento.
| CREATE PROCEDURE ObraPorAutor @nautor varchar(50) AS SELECT titulo, editorial, cantidad FROM libros WHERE nombreautor = @nautor |
Definiciónde triggers
Existen múltiples situaciones en las que en este ejemplo seríainteresante definir un trigger.
Una primera muestra sería la del control de préstamo. Imaginemos quedeseamos evitar que cada socio pueda tener más de un libro simultáneamente en su poder.Cada vez que se realiza un préstamo nuevo la aplicación cliente solicitará lainserción de una nueva fila en la tabla de préstamos. Podríamos escribir un triggerque tras cada inserción en esta tabla, buscase si existe alguna otra fila en la misma quecorresponda a un préstamo al mismo socio, y que eliminase el nuevo préstamo si yaexistía uno aún no terminado. La aplicación cliente podría recibir información en laque examinase si la inserción se había realizado correctamente y presentar, si así sedesea un mensaje explicativo. Pero, lo que es más importante, los datos de la base dedatos serían coherentes. Veamos este ejemplo:
| CREATE TRIGGERprestamocondicional ON prestamos FOR INSERT AS IF (SELECT COUNT(*) FROM prestamos, inserted WHERE prestamos.idsocio = inserted. idsocio ) <> @@rowcount BEGIN DELETE * FROM prestamos WHERE prestamos. idprestamo = inserted. idprestamoEND |
Otra posibilidad es la de gestionar la correspondencia entre la tabla librosy la tabla autores cuando se da de baja un ejemplar por pérdida, sustracción ocualquier otra circunstancia. En este caso el trigger deberá examinar, tras laeliminación de un libro, si existe el autor del libro eliminado tiene aún algún volumenen el fondo de la biblioteca, eliminando su entrada en la tabla autores si no esasí. El trigger sería similar al siguiente:
| CREATE TRIGGER comprobarautor ON libros FOR DELETE AS IF (SELECT COUNT(*) FROM libros WHERE libros.idautor = deleted. idautor ) > 0 BEGIN DELETE * FROM autores WHERE autores. idautor = deleted. idautorEND |
 |
