TEMA 03 FUNCIONES, VISTAS Y DESENCADENADORES Paquete SCORM

"Definamos las funciones, vistas y desencadenadores"

TEMA 03 : FUNCIONES, VISTAS Y DESENCADENADORES
TEMA 03 : FUNCIONES, VISTAS Y DESENCADENADORES

Introducción al tema
Anteriormente vimos todo lo referente a los procedimientos almacenados y
como implementarlos. Los temas de esta semana complementan debido a
que están estrechamente ligados y son una solución diseñada
principalmente para optimizar la obtención de datos, de modo que las
aplicaciones clientes que se conecten al Servidor solo se preocupe por la
presentación de los datos para el usuario final, y su lógica de procesos se
maneja en el propio servidor.

En este marco, esta semana tiene por finalidad conocer y adquirir los
conocimientos para la implementación de funciones, vistas y
desencadenadores a través del SGBD Microsoft SQL Server. Asimismo, les
permitirá a Uds. señores estudiantes analizar las posibles alternativas de
solución de problemas presentados en las organizaciones que requieran el
uso de este tipo de herramientas.

Si analizamos detenidamente veremos que las funciones de SQL Server

definidas por los usuarios y los procedimientos almacenados ofrecen
funcionalidades similares. Ambos nos permiten crear paquetes de
sentencias SQL que son almacenadas en un servidor para futuro uso. Esto nos ofrece el gran beneficio de la eficiencia ya que podemos
ahorrar tiempo programando a través de la reutilización de código de un programa en otro lo que permite recortar el tiempo de desarrollo
de un programa. Además, es posible esconder detalles de SQL, permitiéndoles a los desarrolladores de bases de datos preocuparse
de SQL y a los desarrolladores de aplicaciones tratar únicamente con lenguajes de alto nivel y por último centralizar el mantenimiento,
permitiendo crear cambios en la lógica de negocio en un solo lugar que automáticamente afecta a todas las aplicaciones dependientes.

Aprendizajes esperados
Conozcamos ahora las capacidades y actitudes a desarrollar en este primer tema:
Capacidades
 Analiza los parámetros en la utilización de funciones para la devolución del resultado como un valor.
 Identifica la simplicidad estructurada de los datos a través de las vistas.
 Utiliza desencadenadores al generarse algún evento en el servidor de base de datos.
Actitudes
 Participa activamente aportando ideas en la TAV planteando las interrogantes que crea conveniente posterior a la revisión del
material de la semana 4

1
Mapa conceptual referido al tema
Observa detenidamente el siguiente esquema, en el encontrarás de un “vistazo” de manera sintetizada los
principales concepto de la temática que abordaremos. ¿Qué conceptos o categorías te llaman la atención?

3.1. Funciones
El gestor SQL Server proporciona numerosas funciones integradas y además permite crear funciones definidas por el
usuario con una finalidad específica.

SQL Server proporciona al usuario la posibilidad

de definir sus propias funciones, conocidas como
UDF (user defined functions).
Exisiten tres tipos de funciones. Estas son:

Funciones escalares.
Funciones en línea.
Funciones en línea de multiples sentencias

3.1.1. Definición de
función
Cuando debemos definir a las funciones debemos referenciar
a Elmasri (2005) que dice que “son rutinas que permiten
encapsular sentencias TRANSACT-SQL que se ejecutan
frecuentemente”. Es importante indicar que existen funciones
propias del TRANSACT SQL las cuales se utilizan frecuentemente
en la construcción de sentencias SQL y a las que se les conoce
como funciones de agregación.

Asimismo, existen funciones pueden definidas por el usuario, en

tiempo de ejecución de lenguaje TRANSACT-SQL o común (CLR),
que soportan parámetros, realiza una acción específica(o varias
acciones) y devuelven un resultado que es propio de esa acción. El
valor retornado puede ser un escalar (único) valor o una tabla.

3.1.2. Funciones de agregación

Las funciones agregadas permiten el cálculo de valores sumarios a partir de datos de una columna concreta de una base de datos.
Estas funciones tienen la característica de que se pueden aplicar a todas las filas de una tabla, a un subconjunto de filas de la tabla
especificada, condicionada por la cláusula WHERE o a uno o más grupos de filas de la tabla. De cada conjunto de filas al que se aplica
una función agregada se genera un solo valor.
Es decir, en concreto podemos aseverar, que las funciones de agregación son funciones que toman una colección de valores y
devuelven como resultado un único valor.
Las funciones de agregado se usan dentro de una cláusula SELECT en grupos de registros para devolver un único valor que se aplica
a un grupo de registros.

Veamos que funciones agregadas más importantes que existen:

Función Descripción
AVG Utilizada para calcular el promedio de los valores de un campo determinado
COUNT Utilizada para devolver el número de registros de la selección
2
SUM Utilizada para devolver la suma de todos los valores de un campo determinado
MAX Utilizada para devolver el valor más alto de un campo especificado
MIN Utilizada para devolver el valor más bajo de un campo especificado
Ahora describámoslas:
A) AVG
AVG es la función que calcula la media aritmética de un conjunto de valores en un campo específico de la consulta.
La función AVG no considera ningún campo NULL en el cálculo.

Ejemplo:
Mostrar el promedio de créditos de las asignaturas del plan N° 01:

USE BDUniversidad
SELECT AVG(Ncreditos) as [Promedio Creditos]
FROM Asignatura
WHERE IDPlan = 1
GO

B) COUNT
COUNT(*) está diseñado para contabilizar el número de “valores” específicos de un atributo, se utiliza junto con la cláusula
DISTINCT

Ejemplo
Cuantas personas se han matricula entre las el 01 al 31 de enero del 2014
USE BDUniversidad
SELECT COUNT( DISTINCT P.IDpersona) AS [N° Matriculados]
FROM Persona AS P INNER JOIN Matricula as M
ON P.IDPersona = M.IDPersona
WHERE M.FechaMat BETWEEN '01/01/2014' AND '01/31/2014'
GO

C) SUM
SUM es una función que retorna la suma de valores contenido en un campo específico de una consulta.
Es necesario indicar que campo es el que contiene los datos que desean sumarse o una expresión que realiza un cálculo
utilizando los datos de dichos campos.

Ejemplo
Cuantos créditos tiene el plan de estudios A de ingeniería de sistemas
USE BDUniversidad
SELECT SUM (NCreditos) as [N° Creditos]
FROM EscuelaProf AS EP INNER JOIN PlanEstudios as PE
ON EP.IDEscuelaProf = PE.IDescuela
INNER JOIN Asignatura AS A ON PE.IDPlan = A.IDplan
WHERE EP.IDEscuelaProf = 1 AND PE.Nombre = 'A'
GO

D) MAX y MIN
Las funciones MAX y MIN devuelven el máximo o mínimo valor respectivamente, de un conjunto de valores contenidos en un
campo específico de una consulta.

Ejemplo
Mostrar cual es la longitud máxima y mínima del campo usuario de la tabla persona
USE BDUniversidad
SELECT max(len(Usuario)), MIN (len(Usuario))
FROM Persona
GO

Consideraciones
 Las funciones SUM y AVG sólo pueden utilizarse con columnas numéricas:
 Las funciones MIN y MAX no pueden usarse con tipos de datos bit
 Las funciones agregadas distintas de COUNT(*) no pueden utilizarse con los tipos de datos text e image.
 La palabra clave DISTINCT es opcional con SUM, AVG y COUNT, y no se permite con MIN, MAX ni COUNT (*). Si utiliza
DISTINCT, el argumento no puede incluir una expresión aritmética, sólo debe componerse de un nombre de columna, esta
palabra clave aparece entre paréntesis y antes del nombre de la columna.

Veamos el siguiente video sobre funciones de agregado que nos

ampliará los conocimientos:
3
3.1.3. Funciones definidas por el usuario
Como ya indicamos las funciones definidas por el usuario realizan una acción específica y devuelve el resultado de esa acción como
un valor. El valor de retorno puede ser un escalar (único) valor o una tabla.
Las funciones de usuario son definidas para crear rutinas reutilizables que se pueden utilizar en las siguientes maneras:

 En TRANSACT-SQL como SELECT

 En las aplicaciones de llamar a la función
 En la definición de otra función definida por el usuario
 Para parametrizar una vista o mejorar la funcionalidad de una vista indizada
 Para definir una columna en una tabla
 Para definir una restricción CHECK en una columna
 Para reemplazar a un procedimiento almacenado

Al diseñar una función definida por el usuario, primero es preciso determinar el tipo de función que mejor se ajuste a sus necesidades.
Así pues, es necesario determinar si la función:
 Devolverá un valor escalar (un solo valor)
 Devolverá una tabla (varias filas)
 Realizará un cálculo complejo
 Si tendrá acceso principalmente a los datos de SQL Server
Las funciones definidas por el usuario escritas en Transact-SQL o .NET Framework pueden devolver valores escalares y de tabla.

3.1.3.1. Funciones escalares

Gabillaud (2011), nos indica que son aquellas funciones donde retornan un valor único: tipo de datos como int, Money, varchar, real,
etc. Pueden ser utilizadas en cualquier lugar, incluso, incorporada dentro de las sentencias SQL.

SINTAXIS DE FUNCIONES
CREATE FUNCTION [PROPIETARIO.] Nombre_Función
([{@Parametro Tipo_De_Dato [=Default]} [,..N]])
RETURNS Valor
[AS]
BEGIN
Cuerpo De La Funcion
RETURN Expresion
END
Ejemplo N° 01
Cree una función que calcule el promedio de edades de todas las personas

CREATE FUNCTION dbo.CalcularPromedioEdad() Returns Decimal

AS
BEGIN
DECLARE @Promedio as Decimal
SELECT @Promedio = AVG(CAST(DATEDIFF(DD, P.FechaNac, GETDATE()) / 365.25 AS INT))
FROM Persona as P
Return @Promedio
END
GO

Ahora veamos una función que tenga como parámetro un valor

Ejemplo N° 02
Construya una función que devuelva la cantidad de personas matriculadas en la escuela de ingeniería de sistemas.

CREATE FUNCTION dbo.NroMatriculadosIS() Returns Integer

AS
BEGIN
DECLARE @Mat as Integer
SELECT @MAt = COUNT( DISTINCT P.IDpersona)
FROM Persona AS P INNER JOIN Matricula as M
ON P.IDPersona = M.IDPersona
IF @Mat IS NULL
SET @Mat = 0
Return @Mat
END
GO

4
3.1.3.2. Funciones de tabla en línea
Son aquellas funciones que devuelven la salida de una simple declaración SELECT. El resultado se puede utilizar dentro de los JOINS
o consultas como si fuera una tabla estándar.

Sintaxis
CREATE FUNCTION [propietario.] Nombre_Funcion
([{ @parameter Tipo_de_Dato [ = Default]} [,..n]])
RETURNS Table
[AS]
RETURN [(] Sentencia SQL [)]

Ejemplo N° 01
Construya una función que liste a los alumnos

CREATE FUNCTION dbo.ListaAlumnosIS()

RETURNS TABLE
AS
RETURN
(SELECT P.IDPersona, P.CodigoUni, P.ApellidoPat, P.ApellidosMat, Nombre, P.TipoDoc, P.NumeroDoc
FROM Persona AS P INNER JOIN TipoPersona AS TP ON P.IDTipoPer = TP.IDTipoPer
WHERE TP.IDTipoPer = 1)

Ejecutemos ahora la función:

SELECT * FROM dbo.ListaAlumnosIS()

Ejemplo N° 02
Listar las asignaturas del plan de estudios de ingeniería de sistemas
CREATE FUNCTION dbo.ListaAsignaturasPEIS()
RETURNS TABLE
AS
RETURN
(SELECT A.IDAsignatura, A.Nombre AS [Curso], A.Codigo, A.NCreditos, A.HTeoria, A.HPractica, A.Estado, PE.IDPlan,
PE.Nombre
FROM Asignatura AS A INNER JOIN PlanEstudios AS PE ON A.IDPlan = PE.IDPlan
WHERE PE.IDEscuela = 1 )
GO

Ejecutemos ahora la función:

SELECT * FROM dbo.ListaAsignaturasPEIS()

3.1.3.3. Funciones de tabla de multisentencias

Este tipo de funciones son similares a los procedimientos almacenados excepto que devuelven una tabla. Se usan frecuentemente en
situaciones donde es necesario más lógica y proceso.

SINTAXIS
CREATE FUNCTION [propietario.] Nombre_Funcion
([{@parameter Tipo_Dato [ = Default]} [,..n]])
RETURNS TABLE
[AS]
BEGIN
Contenido de la funció
RETURN
END

Ejemplo N° 01
Cree una función que devuelva una tabla con los dato de las personas (email, dirección y teléfono)
CREATE FUNCTION dbo.DatosPersonas()
RETURNS @Tabla
TABLE(IDPersona Integer,
ApellidoPat varchar(20),
ApellidosMat varchar(20),
Nombres varchar(50),
Direccion varchar(512),
Email varchar(150),
NumeroTel varchar(50))
AS
BEGIN
INSERT INTO @Tabla
SELECT P.IDPersona, P.ApellidoPat, P.ApellidosMAt, P.Nombres, D.Direccion, E.Email, T.NumeroTel
FROM Persona AS P INNER JOIN Direccion as D ON P.IDPersona = D.IDpersona INNER JOIN Email as E ON
P.IDPersona = E.IDPersona INNER JOIN Telefono as T ON P.IDPersona = T.IDPersona
RETURN

5
 END
GO
Ejecutemos la función:
Select * from dbo.DatosPersonas()

3.2. Vistas
Una vista no viene a ser más que una tabla virtual cuyo contenido es el producto de una consulta. Una vista consta de un conjunto
definido de columnas y filas de datos las cuales tienen un nombre tan idéntico como una tabla real.

Sin embargo, a menos que la vista esté indexada, no existe como conjunto de valores de datos almacenados en una base de datos.
Las filas y las columnas de datos se producen en forma dinámica cuando se referencia la vista y proceden de tablas a las que se hace
referencia en la consulta que define.

Debemos indicar que una vista actúa como como filtro de las tablas subyacentes a las que se hace referencia en ella.

La consulta SQL que define la vista puede involucrar una o varias tablas, o también pueden originarse de otras vistas, tanto de la base
de datos actual como de otras bases de datos. Asimismo, es posible utilizar las consultas distribuidas para definir vistas que utilicen
datos de orígenes heterogéneos.

No existen restricciones a la hora de consultar vistas y existen muy pocas a la hora de modificar los datos de éstas

Consideraciones para crear las vistas

Según Microsoft (2009) antes de crear una vista, considere las siguientes indicaciones:

 Sólo puede crear vistas en la base de datos actual. Sin embargo, las tablas y las vistas a las que se haga referencia desde la
nueva vista pueden encontrarse en otras bases de datos e, incluso, en otros servidores, si la vista se define mediante
consultas distribuidas.

 Los nombres de las vistas deben seguir las reglas que se aplican a los identificadores y ser únicos para cada esquema.
Además, el nombre debe ser distinto del de las tablas incluidas en ese esquema.

 Es posible generar vistas dentro de otras vistas. Microsoft SQL Server permite anidar vistas. El anidamiento no debe superar
los 32 niveles. Es posible que el límite real del anidamiento de vistas sea inferior en función de la complejidad de la vista y de
la memoria disponible.

 No puede asociar con las vistas reglas ni definiciones DEFAULT.

 Los desencadenadores AFTER no se pueden asociar con las vistas; sólo se pueden asociar los desencadenadores
INSTEAD OF.
 La consulta que define la vista no puede incluir las cláusulas COMPUTE ni COMPUTE BY, y tampoco puede incluir la palabra
clave INTO.
 La consulta que define la vista no puede incluir la cláusula ORDER BY, a menos que también haya una cláusula TOP en la
lista de selección de la instrucción SELECT.
 La consulta que define la vista no puede incluir la cláusula OPTION que especifica una sugerencia de consulta.
 La consulta que define la vista no puede incluir la cláusula TABLESAMPLE.
 No se pueden definir definiciones de índice de texto completo en las vistas.
 No se pueden crear vistas temporales, ni vistas dentro de tablas temporales.
 Las vistas, las tablas o las funciones que participan en una vista creada con la cláusula SCHEMABINDING no se pueden
quitar, a menos que se quite o cambie esa vista de forma que deje de tener un enlace de esquema. Además, las
instrucciones ALTER TABLE sobre tablas que participan en vistas que tienen enlaces de esquemas provocarán un error si
estas instrucciones afectan a la definición de la vista.
 Si una vista no se crea con la cláusula SCHEMABINDING, debe ejecutarse sp_refreshview cuando se realicen cambios en
los objetos subyacentes de la vista que afecten a la definición de ésta. De lo contrario, la vista puede generar resultados
inesperados cuando se realiza una consulta.
 No puede emitir consultas de texto completo en una vista, aunque una definición de vista puede incluir una consulta de texto
completo si ésta hace referencia a una tabla configurada para la indización de texto completo.
 Debe especificar el nombre de todas las columnas de la vista en el caso de que:
- I. Alguna de las columnas de la vista derive de una expresión aritmética, una función integrada o una constante.
- II. Dos o más columnas de la vista tuviesen, en caso contrario, el mismo nombre (normalmente, debido a que la definición
de la vista incluye una combinación y las columnas de dos o más tablas diferentes tienen el mismo nombre).

6
 - III. Desee darle a una columna de la vista un nombre distinto del de la columna de la que deriva. (También puede cambiar
el nombre de las columnas en la vista). Una columna de una vista hereda los tipos de datos de la columna de la que deriva,
aunque no cambie su nombre.
3.2.1. Definición de Vistas
En concreto, las vistas se emplean para representar los datos que están almacenados en una tabla. Una vista tiene más ventajas
aparte de mirar los datos almacenados en una tabla
Según Escofet (2009) Una vista en el modelo relacional no es sino una tabla virtual derivada de las tablas reales de nuestra base de
datos, un esquema externo puede ser un conjunto de vistas.

Cuando usaremos las vistas

Las principales razones por las que podemos crear vistas son:
Seguridad, nos pueden interesar que los usuarios tengan acceso a una parte de la información que hay en una tabla, pero no a toda
la tabla.
Comodidad, como hemos dicho el modelo relacional no es el más cómodo para visualizar los datos, lo que nos puede llevar a tener
que escribir complejas sentencias SQL, tener una vista nos simplifica esta tarea.
SINTAXIS
CREATE VIEW <Nombre_vista>
AS
(<sentencia_select>)

Ejemplo N° 01
Cree una vista que muestre la lista de facultades con sus escuelas profesionales
CREATE VIEW dbo.ListaEscuelas
AS
SELECT F.IDFacultad, F.Nombre, EP.IDEscuelaProf, EP.Nombre AS [Escuela Profesional]
FROM Facultad as F INNER JOIN EscuelaProf as EP ON F.IDFacultad = EP.IDFacultad

Para llamar a la vista creada:

SELECT * FROM ListaEscuelas

Modificar una vista

Para modificar una vista utilizaremos la instrucción ALTER
Ejemplo
ALTER VIEW dbo.ListaEscuelas
AS
SELECT F.IDFacultad, F.Nombre, F.FechaCrea, EP.IDEscuelaProf, EP.Nombre AS [Escuela Profesional]
FROM Facultad as F INNER JOIN EscuelaProf as EP ON F.IDFacultad = EP.IDFacultad
3.2.2. Vistas indizadas
Según DataPrix(2014) “Una vista indizada se diferencia de una normal básicamente en que sobre la primera creamos un índice (el
primero clusterizado). En el momento en que lo hacemos estamos persistiendo en la base de datos una referencia que abre la veda a
posibles optimizaciones que no se pueden hacer con una vista simple. También es cierto que si nos hace falta y realmente nos aporta
algo también es posible es crear más de un índice (a partir del segundo ya no pueden ser clústerizados, crear uno clústerizado es
obligado).

Una de los beneficios que también da la vista indizada es que aporta una nueva perspectiva en el momento del cálculo para el plan de
ejecución de una SELECT sobre las tablas que implica. El optimizador de consultas puede seleccionar la vista si determina que ésta
puede sustituirse por parte o por toda la consulta del plan de consultas si es de un coste menor. En el segundo caso, la vista indizada
se utiliza en lugar de las tablas subyacentes y sus índices. No es necesario hacer referencia a la vista en la consulta para que el
optimizador de consultas la utilice durante la ejecución. Esto incluso permite que las aplicaciones existentes se beneficien de las vistas
indizadas recién creadas sin cambiar directamente código en dichas aplicaciones.”

Microsoft technet (2014) indica que una vista indizada es una vista que se ha materializado. Esto significa que se ha calculado y
almacenado. Se puede indizar una vista creando un índice agrupado único en ella. Las vistas indizadas mejoran de forma
considerable el rendimiento de algunos tipos de consultas. Las vistas indizadas funcionan mejor para consultas que agregan muchas
filas. No son adecuadas para conjuntos de datos subyacentes que se actualizan frecuentemente.

Donde debemos usar las vistas indizadas

Marques(2013) Una de las ventajas de las vistas indexadas radica en que mejoran el rendimiento de operaciones de combinación y
agregación. Si realizamos frecuentemente este tipo de operaciones, la vista indexada por su naturaleza nos permite tener el resultado
obtenido de forma directa sin ningún cálculo, en contraposición a una consulta que tuviera que realizar todas esas operaciones en el
momento
Las vistas indizadas aportan un beneficio aunque también un coste. Puede tener el mismo “defecto” que puede producir la indexación
masiva de una tabla transaccional con inserciones/modificaciones masivas.
Considerando lo indicado anteriormente, debemos evaluar siempre el beneficio en base al coste que suponga. Realmente con las
vistas indizadas (clusterizada o no) seguro que notaremos una mejora si las usamos en datawarehouses, data marts, bases de datos
OLAP, en procesos de minería de datos y similares. En estos escenarios son candidatas las consultas gigantes sobre diferentes
tablas, con particiones verticales u horizontales, agregaciones y sin pensarlo demasiado, las particiones de tablas de hechos.
Una de los requisitos para poder indizar una vista es que tenemos que crear la vista con la opción WITH SCHEMABINDING. Esta
opción tiene su lado positivo, si el propietario de cualquiera de las tablas incluidas en el SELECT intenta hacer un cambio en la
estructura no podrá. Esto es importante y muy seguro debido a que nos protege de cualquier cambio a traición de las tablas.
SINTAXIS

7
 CREATE VIEW [Propietario.] NombreVista WITH SCHEMABINDING
AS
Consulta
GO
[WITH CHECK OPTION]

Luego creamos el índice sobre la vista

CREATE UNIQUE CLUSTERED INDEX CampoIndice ON [Propietario.] NombreVista (Campo)
Ejemplo N° 01
Crear una vista con el plan de estudios de ingeniería de sistemas que muestre sus asignaturas y sus requisitos.
CREATE VIEW dbo.CreditosPorCiclo
WITH SCHEMABINDING
AS
SELECT PlanEstudios.Nombre, Asignatura.Ciclo, COUNT_BIG(*) AS NumeroCursos
FROM dbo.PlanEstudios INNER JOIN dbo.Asignatura ON PlanEstudios.IDPlan = Asignatura.IDPlan
WHERE PlanEstudios.IDPlan = 1
GROUP BY Asignatura.Ciclo, PlanEstudios.Nombre

Creemos ahora el indice

CREATE UNIQUE CLUSTERED INDEX Ciclo ON
DBO.CreditosPorCiclo(Ciclo)

Mostremos la vista ahora con:

SELECT * FROM DBO.CreditosPorCiclo
3.2.3. Vistas con particiones
Una vista con particiones junta datos horizontales con particiones de un conjunto de tablas miembro en uno o más servidores. Esto
hace que los datos aparezcan como si fueran de una tabla.
Las vistas con particiones permiten repartir los datos de las tablas grandes en tablas miembro más pequeñas. Los datos se dividen
entre las tablas miembros en función de los intervalos de valores de datos de una de las columnas. Los intervalos de datos de cada
tabla miembro se definen en una restricción CHECK especificada en la columna que marca la partición.

Una vista con partición local que junta tablas miembro en la misma instancia de SQL Server.
Una vista con particiones distribuida es cuando una vista junta datos de tablas de servidores. Las vistas con particiones
distribuidas se usan para implementar una federación de servidores de bases de datos. Una federación es un grupo de servidores que
se administran independientemente, pero que colaboran para compartir la carga de proceso de un sistema. Formar una federación de
servidores de base de datos mediante la partición de datos es el mecanismo que permite ampliar horizontalmente un conjunto de
servidores para admitir los requisitos de procesamiento de sitios Web de varios niveles y de gran tamaño

SINTAXIS

SELECT <select_list1>
FROM Tabla1
UNION ALL
SELECT <select_list2>
FROM Tabla2
UNION ALL
...
SELECT <select_listn>
FROM Tn;

Ejemplo N° 01
Para el ejemplo de este tipo de vistas crearemos unas tablas previamente con la finalidad que se comprenda su utilidad:
CREATE TABLE VentasOctubre
( IDVenta INT,
IDpersona INT NOT NULL,
FechaVenta DATETIME NULL
CHECK (DATEPART(yy, FechaVenta) = 2000),
MesVenta INT
CHECK (MesVenta = 10),
FechaEntrega DATETIME NULL
CHECK(DATEPART(mm, FechaEntrega) > 10)
CONSTRAINT IDMesVenta PRIMARY KEY(IDVenta, MEsVenta))

CREATE TABLE VentasNoviembre

( IDVenta INT,
IDpersona INT NOT NULL,
FechaVenta DATETIME NULL
CHECK (DATEPART(yy, FechaVenta) = 2000),
MesVenta INT
CHECK (MesVenta = 11),
FechaEntrega DATETIME NULL
CHECK(DATEPART(mm, FechaEntrega) > 11)
CONSTRAINT IDMesVenta PRIMARY KEY(IDVenta, MEsVenta))
8
Acabamos de crear una tabla con restricciones en los campos. Si intentamos insertar registros con valores en el campo FechaVenta
diferente al año 2000, o el mes diferente a 5, se mostrará un mensaje restrictivo y no se nos permitirá el registro.
Probemos:
INSERT INTO ventas VALUES(1, 1, '10/10/2005', 4, '05/10/2007')

Vemos que se nos muestra el mensaje:

The INSERT statement conflicted with the CHECK constraint "CK__Ventas__MesVenta__3864608B". The conflict occurred in
database "BDUniversidad", table "dbo.Ventas", column 'MesVenta'.
The statement has been terminated.

Ahora probemos con:

INSERT INTO ventas VALUES(1, 1, '10/10/2000', 5, '05/10/2007')

Creemos la vista con particiones ahora:

CREATE VIEW VentasOctNov
AS
SELECT * FROM VentasOctubre
UNION ALL
SELECT * FROM VentasNoviembre

3.3. Desencadenadores (TRIGGERS)

Es necesario reconocer que una de las cosas más importantes en toda organización son los datos. Asimismo, debemos reconocer son
las base de datos de una organización, sobre la que interactúan concurrentemente muchos usuarios a través de distintas aplicaciones,
web o de escritorio.

Chinkes & Regolini & Coronel & Contreras & Goldman (2008) aseverar que los triggers pueden tener varias utilidades entre las
cuales mencionaremos las siguientes:

 Evitar el almacenamiento de información errónea en la base de datos. Aumentar la integridad referencial o conseguir una
seguridad adicional
 Controlar restricciones de usuario: por ejemplo, una regla de negocio de una empresa puede especificar que un empleado no
puede ganar más que su jefe. Mediante el uso de triggers, si se intenta incluir en la base de datos una información que
incumpla esa regla, es la propia base de datos la que no lo permite.
 Mantenimiento de valores deducidos: Si tenemos una tabla con valores parciales de ventas y otra con totales, al insertar,
borrar o modificar un valor parcial, automáticamente se actualizará el valor total.
 Mantener coherentes las tablas replicadas en una BD distribuida.
 Registrar en tablas de auditoria las actualizaciones de la base de datos.
 El uso de triggers nos proporciona ventajas, como son una mayor facilidad en la codificación de las aplicaciones que se
ejecutan contra la base de datos, así como una mayor consistencia de los datos al no tener que realizar las mismas
comprobaciones cada vez que se intentan modificar los datos.

3.3.1. Definición de desencadenadores

Cuando nos referimos a los triggers (o desencadenadores) nos referimos 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 se denominan también reglas ECA (Evento-Condición-Acción), dado que estos son los tres elementos básicos
de un trigger:
 Evento: Es la modificación de datos que se controla con el trigger, y hará que este se dispare. Esta modificación puede ser
una inserción (INSERT), un borrado (DELETE) o una actualización (UPDATE).
 Condición: La condición que debe verificarse para que el trigger se dispare.
 Acción: La acción (normalmente una modificación de datos o evitar que la operación en curso se realice) que se produce
como reacción de la BD ante el cambio (el evento, cuando se da la condición).

SINTAXIS
CREATE TRIGGER Nombre
ON{ tabla| vista}
{
{{
FOR | AFTER | INSTEAD OF } { [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE] }
[ NOT FOR REPLICATION ]
AS
[ { IF UPDATE ( campo)
[ { AND | OR } UPDATE (campo) ]
[ ...n ]
9
 }]
instrucciones_sql[ ...n ]
}
}
En donde:
 nombre: es el nombre del desencadenador que se va a crear.
 tabla/vista: es el nombre de una tabla/vistas obre la que se crea.
 Campo: campo de la tabla o vista afectada por el desencadenador.
 Instrucciones_sql: reglas de negocio que se requieren especificar por medio de SQL

Modificar un trigger
Para modificar un disparador usaremos el Alter table
ALTER TRIGGER Nombre
ON{ tabla| vista}
{
{{
FOR | AFTER | INSTEAD OF } { [ INSERT ] [ , ] [ UPDATE ] [ , ] [ DELETE] }
[ NOT FOR REPLICATION ]
AS
[ { IF UPDATE ( campo)
[ { AND | OR } UPDATE (campo) ]
[ ...n ]
}]
instrucciones_sql[ ...n ]
}
}

Eliminar un trigger
Para eliminar un trigger usaremos la siguiente sintaxis:
DROP TRIGGER Nombre
Inhabilitar un trigger
Para inhabilitar un disparador usaremos la siguiente estructura:
ALTER TABLE NombreTabla DISABLE TRIGGER NombreDisparador

Por ejemplo inhabilitemos el disparador anterior:

ALTER TABLE Persona DISABLE TRIGGER Tx_RegistraPersona

Inhabilitar todos los disparadores asociados en la tabla persona

DISABLE TRIGGER ALL ON Persona

Inhabilitar todos los disparadores asociados a la base de datos

DISABLE TRIGGER ALL ON DATABASE

Inhabilitar todos los disparadores asociados al servidor

DISABLE TRIGGER ALL ON ALL SERVER

Habilitar un trigger
Para habilitar un disparador usaremos la siguiente estructura:
ALTER TABLE NombreTabla ENABLE TRIGGER NombreDisparador

Por ejemplo habilitemos el disparador anterior:

ALTER TABLE Persona ENSABLE TRIGGER Tx_RegistraPersona

Habilitar todos los disparadores asociados en la tabla persona

ENABLE TRIGGER ALL ON Persona

Habilitar todos los disparadores asociados a la base de datos

ENABLE TRIGGER ALL ON DATABASE

Habilitar todos los disparadores asociados al servidor

ENABLE TRIGGER ALL ON ALL SERVER
Limitaciones de los triggers.
Ricardo (2009) nos refiere que si bien es cierto hemos reconocido la utilidad de los desencadenadores también es cierto que hay
algunas limitaciones que debemos tener en cuenta:
 Solo se pueden aplicar a una tabla específica, es decir, un trigger no sirve para dos o más tablas
 El trigger se crea en la base de datos actual (en la que se está trabajando) pero desde un trigger puedes hacer referencia a
otras bases de datos.
 Un Trigger puede devolver resultados al programa que lo desencadena de la misma forma que un procedimiento almacenado
aunque no es lo más idóneo. Para impedir que una instrucción de asignación devuelva un resultado se puede utilizar la
sentencia SET NOCOUNT al principio del Trigger.
10
  Las siguientes instrucciones no se pueden utilizar en los triggers :
- ALTER DATABASE CREATE DATABASE
- DISK INIT DISK RESIZE
- DROP DATABASE LOAD DATABASE
- LOAD LOG RECONFIGURE
- RESTORE DATABASE RESTORE LOG

3.3.2. Desencadenadores DML

Los 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.
Las instrucciones de desencadenadores DML utilizan dos tablas especiales 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 primera tabla (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. Es decir, los datos insertados. INSERTED estará vacía en una operación DELETE.
En la segunda (DELETED), disponible en las operaciones UPDATE y DELETE, están los valores anteriores a la ejecución de la
actualización o borrado. Es decir, los datos que serán borrados. DELETED estará vacía en una operación INSERT.
¿No existe una tabla UPDATED? No, hacer una actualización es lo mismo que borrar (DELETED) e insertar los nuevos (INSERTED).
La sentencia UPDATE es la única en la que INSERTED y DELETED tienen datos simultáneamente.
Ejemplo N° 01
Veamos un ejemplo muy sencillo llamado Tx_Matricula que muestre un mensaje cuando se intente insertar, actualizar o borrar
registros de la tabla matricula
CREATE TRIGGER Tx_Matricula
ON dbo.MAtricula
FOR INSERT, UPDATE, DELETE
AS
PRINT 'Actualización de los registros de Productos'

Ejemplo N° 02
Cree un disparador que me avise e impida el registro de personas que ya existan en la base datos, para ello compare sus apellidos y
nombres.
CREATE TRIGGER Tx_RegistraPersona
ON Persona
FOR INSERT
AS
IF (SELECT COUNT (*) FROM INSERTED, Persona
WHERE INSERTED.ApellidoPat = Persona.ApellidoPat
AND INSERTED.ApellidosMat = Persona.ApellidosMat
AND INSERTED.Nombres = Persona.Nombres ) >1
BEGIN
ROLLBACK TRANSACTION
PRINT 'La persona ya exsite'
END
ELSE
PRINT 'Se registro correctamente'
GO

3.3.3. Desencadenadores DDL

Los 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.

3.3.4. Tipos de Desencadenadores

Queda claro ya que un trigger se crea sobre una tabla específica para un evento (inserción, eliminación o actualización). Pero también
es posible especificar el momento de disparo del trigger (momento en que se produce la ejecución). El momento de disparo indica que
las acciones (sentencias) del trigger se ejecuten luego de la acción (insert, delete o update) que dispara el trigger o en lugar de la acción.
CREATE TRIGGER NombreDisparador
on NombreTabla o Vista
MomentoDelDisparo-- AFTER O INSTEAD OF
Accion -- insert, update o delete
AS
SentenciasSQL
Los tipos de desencadenadores existentes podemos resumirlo en:
a) Desencadenador AFTER
 Se activa después de la acción desencadenadora y tras haber procesado cualquier restricción
 Aplicada sólo a tablas
 Varios por cada acción de desencadenamiento
 Produce el mismo efecto que especificar FOR
11
b) Desencadenador INSTEAD OF
 Se activa en lugar de la acción desencadenadora y antes del procesamiento de restricciones
 Aplicada a tablas y vistas
 Uno por cada acción de desencadenamiento
Ejemplo N° 01
CREATE TRIGGER Tx_ControlRegistro
ON Persona
AFTER UPDATE
AS
BEGIN
SET NOCOUNT ON
INSERT INTO Temporal (IDpersona, Codigo, ApellidoPat, ApellidoMat, Nombres, Fecha)
SELECT IDPersona, Codigo, APellidoPat, ApellidoMat, Nombres, getdate() FROM INSERTED
END

Ejemplo N° 02
Crear un trigger que en vez de dar de baja físicamente a las personas, lo haga lógicamente cambiando el valor en un campo de la
tabla.
USE BDUniversidad
ALTER TABLE Persona ADD Baja BIT DEFAULT 0
GO
UPDATE Persona SET Baja = 0
USE BDUniversidad
IF OBJECT_ID('TX_BajaPersonas','TR') IS NOT NULL DROP TRIGGER TX_BajaPersonas
GO
CREATE TRIGGER TX_BajaPersonas
ON Persona INSTEAD OF DELETE
AS
BEGIN
UPDATE Persona SET Baja = 1
FROM Persona INNER JOIN Deleted ON empleados.IDPersona = DELETED.IDPersona
END
GO

12