Stored Procedures

Integridad de datos
SQL Server ofrece dos alternativas para asegurar la integridad de datos,
la integridad:

1. DECLARATIVA, mediante el uso de restricciones (constraints), valores

predeterminados (defaults) y reglas (rules).

2. PROCEDIMENTAL, mediante la implementación de procedimientos

almacenados y desencadenadores (triggers).
Constraints
• NOT NULL: Indica que una columna no puede almacenar un valor nulo.
• UNIQUE: Asegura que cada fila de una columna debe tener un valor único.
• PRIMARY KEY : Una combinación de un valor no nulo y único. Asegura que una
columna (o combinación de dos o más columnas) tienen una identidad única que
ayuda a encontrar un registro en particular en una tabla más fácil y rápidamente.
• FOREIGN KEY : Asegurar la integridad referencial de los datos en una tabla para
que coincida con los valores de otra tabla.
• CHECK : Asegura que el valor de una columna cumple una condición específica.
• DEFAULT : Especifica un valor por defecto para una columna.
• IDENTITY: Regularmente se utiliza esta propiedad para los IDs de las tablas, que
tienen que ser valores únicos y auto incrementables.
Check
La restricción "check" especifica los valores que acepta un campo,
evitando que se ingresen valores inapropiados.

La sintaxis básica es la siguiente:

ALTER TABLE Nombre

ADD CONSTRAINT <Nombre_Constraint>
CHECK <Condicion>;
Sintaxis
ALTER TABLE libros
ADD CONSTRAINT CK_libros_precio_positivo
CHECK (preciomin>=0 AND preciomay>=0);

• Este tipo de restricción verifica los datos cada vez que se ejecuta una sentencia
"insert" o "update", es decir, actúa en inserciones y actualizaciones.
• Si la tabla contiene registros que no cumplen con la restricción que se va a
establecer, la restricción no se puede establecer, hasta que todos los registros
cumplan con dicha restricción.
• La condición puede hacer referencia a otros campos de la misma tabla.
Las condiciones para restricciones "check" también pueden pueden
incluir un patrón o una lista de valores. Por ejemplo establecer que
cierto campo conste de 4 caracteres, 2 letras y 2 dígitos:
CHECK (CAMPO like '[A-Z][A-Z][0-9][0-9]');
O establecer que cierto campo asuma sólo los valores que se listan:
CHECK (CAMPO in ('lunes','miercoles','viernes'));
No se puede aplicar esta restricción junto con la propiedad "identity".
Default
La restricción "default" especifica un valor por defecto para un campo cuando no se inserta explícitamente
en un comando "insert".

Anteriormente, para establecer un valor por defecto para un campo empleábamos la cláusula "default" al
crear la tabla, por ejemplo:
CREATE TABLE libros(
... autor VARCHAR(30) DEFAULT 'Desconocido', ... );
Cada vez que establecíamos un valor por defecto para un campo de una tabla, SQL Server creaba
automáticamente una restricción "default" para ese campo de esa tabla.
Podemos agregar una restricción "default" a una tabla existente con la sintaxis básica siguiente:
ALTER TABLE NombreTabla
ADD CONSTRAINT <Nombre_Constraint>
DEFAULT <ValorPorDefecto>
FOR Campo;
Stored Procedures
• Son un grupo de sentencias de T-SQL
• Aceptan parámetros de entrada y devuelven valores como parámetro
de salida.
• Contienen conjunto de instrucciones para realizar operaciones en la
base de datos. Permiten encapsular tareas repetitivas.
• Pueden incluir llamadas a otros SPs.
Beneficios
• Reduce el tráfico de red
• Fortalece la seguridad
• Reutilización de código
• Facilidad de mantenimiento al ser independiente de la aplicación
• Ayuda al rendimiento de la ejecución
Tipos de Stored Procedures
• Del sistema: están almacenados en la base de datos "master" y llevan el prefijo "sp_"; permiten
recuperar información de las tablas del sistema y pueden ejecutarse en cualquier base de datos.
• Locales: los crea el usuario (Los que veremos en el curso).
• Temporales: pueden ser locales, cuyos nombres comienzan con un signo numeral (#), o globales,
cuyos nombres comienzan con 2 signos numeral (##). Los procedimientos almacenados
temporales locales están disponibles en la sesión de un solo usuario y se eliminan
automáticamente al finalizar la sesión; los globales están disponibles en las sesiones de todos los
usuarios.
• Extendidos: se implementan como bibliotecas de vínculos dinámicos (DLL, Dynamic-Link
Libraries), se ejecutan fuera del entorno de SQL Server. Generalmente llevan el prefijo "xp_". No
los estudiaremos.
Un procedimiento almacenados puede hacer referencia a objetos que no existen al momento de
crearlo. Los objetos deben existir cuando se ejecute el procedimiento almacenado
Sintaxis Creación SP
CREATE PROCEDURE <Nombre>
-- Parámetros
<@Param1> Tipo de Dato= <Valor por Default>
<@Param1> Tipo de Dato= <Valor por Default>
…
AS
BEGIN
SET NOCOUNT ON;
-- sentencias T-SQL
-- Consultas
-- inserts
-- updates
-- deletes
…
END
Sintaxis Modificación SP
ALTER PROCEDURE <Nombre>
-- Parámetros
<@Param1> Tipo de Dato= <Valor por Default>
<@Param1> Tipo de Dato= <Valor por Default>
…
AS
BEGIN
SET NOCOUNT ON;
-- sentencias T-SQL
-- Consultas
--inserts
-- updates
-- deletes
…
END
Sintaxis Borrado SP

IF OBJECT_ID(<Nombre>,’P’) IS NOT NULL

DROP PROCEDURE <Nombre>;
Visualizar definición de SP

• Sp_helptext <Nombre>

• SELECT OBJECT_DEFINITION (OBJECT_ID (<Nombre>))

• SELECT definition
FROM sys.sql_modules
WHERE object_id = ( OBJECT_ID (<Nombre>))
Ejecución
Sintaxis

EXEC <nombre_SP> @param1 = <valor1> , @param2 = <valor2>

o
EXEC <nombre_SP> <valor1>, <valor2>
 Stored Procedures (Información)
• "sp_help": sin parámetros nos muestra todos los objetos de la base de datos
seleccionada, incluidos los procedimientos. En la columna "Object_type" aparece
"stored procedure" si es un procedimiento almacenado. Si le enviamos como
argumento el nombre de un procedimiento, obtenemos la fecha de creación e
información sobre sus parámetros.
• "sp_helptext": seguido del nombre de un procedimiento almacenado nos muestra el
texto que define el procedimiento, excepto si ha sido encriptado.
• "sp_stored_procedures": muestra todos los procedimientos almacenados, los
propietarios, etc. Este procedimiento almacenado puede recibir 3 parámetros:
@sp_name (nombre, nvarchar, admite comodines para búsqueda de patrones),
@sp_owner (propietario, nvarchar, admite comodines) y @qualifier (nombre de la
base de datos). Por ejemplo, podemos ver todos los procedimientos almacenados
creados por nosotros con esta sentencia:
exec sp_stored_procedures @sp_name='pa_%';
"sp_depends": seguido del nombre de un objeto, nos devuelve 2 resultados:

1. nombre, tipo, campos, etc. de los objetos de los cuales depende el objeto
enviado y
2. nombre y tipo de los objetos que dependen del objeto nombrado. Por
ejemplo, ejecutamos "sp_depends" seguido del nombre de un
procedimiento:
exec sp_depends pa_autor_promedio;
aparecen las tablas (y demás objetos) de las cuales depende el procedimiento,
es decir, las tablas referenciadas en el mismo. Podemos ejecutar el
procedimiento seguido del nombre de una tabla:
exec sp_depends libros;
Aparecen los procedimientos (y demás objetos) que dependen de ella.
Try
Catch
Sintaxis
BEGIN TRY
{ sentencia T-SQL}
END TRY
BEGIN CATCH
[ {sentencia T-SQL}]
[RAISERROR]
END CATCH
Recuperar información de errores
• ERROR_NUMBER() – Devuelve el número interno del error

• ERROR_SERVERITY() – Devuelve la información sobre cualquier cosa, desde errores

informativos hasta errores que el usuario de DBA puede corregir, etc.

• ERROR_STATE() – Devuelve la información sobre la fuente

• ERROR_PROCEDURE() – Devuelve el nombre del procedimiento almacenado o la función

• ERROR_LINE() – Devuelve el número de línea en el que ocurrió un error

• ERROR_MESSAGE() – Devuelve la información más esencial y ese es el mensaje de texto del

error
Transacciones
Transacciones

• Una transacción es una unidad única de trabajo

• Si tiene éxito todas las sentencias se confirman en la base de datos.

• Si falla, todas las sentencias se revierten de la base de datos.

Gráfico Temporal de la Ejecución de una
transacción
BD en estado consistente BD en estado consistente
BD temporalmente en un
estado inconsistente durante
la ejecución de la transacción

Inicio de Transacción Ti Ejecución de Transacción Ti Fin de Transacción Ti

Transacciones
BEGIN {TRAN | TRANSACTION}
[ { transaction_name} | @tran_name_variable]

Sentencias T-SQL

COMMIT/ROLLBACK [ {TRAN | TRANSACTION} [ transaction_name |

@tran_name_variable] ]

• @@TRANCOUNT se incrementa en uno al entrar en una transacción.

Autorización de Ejecución de SP
GRANT EXECUTE | EXEC ON <nombre de SP> TO <usuario>

GRANT SELECT ON <nombre de Tabla> TO <usuario>

GRANT INSERT ON <nombre de Tabla> TO <usuario>

GRANT DELETE ON <nombre de Tabla> TO <usuario>

GRANT UPDATE ON <nombre de Tabla> TO <usuario>

Triggers
TRIGGERS
¿Qué son?
Una clase de procedimiento almacenado que se ejecuta
automáticamente cuando se produce un evento a nivel tabla.

DML INSERT, UPDATE, DELETE

DDL CREATE, ALTER , DROP

Diferencias con Stored Procedures
Los Triggers:
• 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.
Los disparadores, a diferencia de las restricciones "check", pueden hacer referencia
a campos de otras tablas.
Ejemplo:
Puede crearse un trigger de inserción en la tabla "ventas" que compruebe el campo
"stock" de un artículo en la tabla "artículos".
El disparador controlaría que, cuando el valor de "stock" sea menor a la cantidad
que se intenta vender, la inserción del nuevo registro en "ventas" no se realice.

Los disparadores se ejecutan DESPUÉS 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.
Consideraciones generales
• “CREATE TRIGGER" debe ser la primera sentencia de un bloque y sólo se puede
aplicar a una tabla.
• Un disparador se crea solamente en la base de datos actual pero puede hacer
referencia a objetos de otra base de datos.
• Las siguientes instrucciones no están permitidas en un desencadenador: create
database, alter database, drop database, load database, restore database, load log,
reconfigure, restore log, disk init, disk resize.
• Se pueden crear varios triggers para cada evento, es decir, para cada tipo de
modificación (inserción, actualización o borrado) para una misma tabla.
Por ejemplo, se puede crear un "insert trigger" para una tabla que ya tiene otro
"insert trigger".
Trigger DML
Cuando se lanza un trigger DML se generan las siguientes tablas.

INSERTED DELETED
INSERT, UPDATE DELETE,UPDATE
Trigger DML
CREATE TRIGGER Nombre
ON Tabla
{AFTER | INSTEAD OF}
{ [INSERT] [,] [UPDATE][,][DELETE]}
AS
BEGIN
Sentencias T-SQL
Uso de tablas
inserted, deleted
END
Trigger DML Ejemplo
ALTER TRIGGER ValidaFechaRegistro
ON Cliente
AFTER INSERT
AS
BEGIN
DECLARE @dtFechaRegistro DATETIME
SELECT @dtFechaRegistro = fecharegistro
FROM inserted
IF @dtFechaRegistro > GETDATE ()
BEGIN
RAISERROR (‘La fecha de registro del cliente no puede ser posterior al día de hoy’,16,1);
ROLLBACK TRANSACTION;
END;
END
Habilitar /Deshabilitar Trigger
-- Desactivar trigger
DISABLE TRIGGER nombre_trigger ON tabla
-- Activar trigger
ENABLE TRIGGER nombre_trigger de una tabla
-- Desactivar todos los trigger de una tabla
ALTER TABLE nombre_tabla DIABLE TRIGGER ALL
-- Activar todos los trigger de una tabla
ALTER TABLE nombre_tabla ENABLE TRIGGER ALL
Trigger DDL Creación
CREATE TRIGGER Nombre
ON {ALL SERVER | DATABASE}
{FOR | AFTER} {event_type | event_group}

AS
BEGIN
Sentencias T-SQL
END
Trigger DDL Ejemplo
CREATE TRIGGER seguridad
ON DATABASE
FOR DROP_TABLE, ALTER_TABLE
AS
BEGIN
RAISERROR (‘Debe deshabilitar el trigger antes de poder realizar
una modificación’, 16,1);
ROLLBACK TRANSACTION;
END
Trigger Instead Off y After
También podemos especificar el momento de disparo del trigger. 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.
Sintaxis
CREATE TRIGGER Nombre
ON [Tabla | Vista]
{AFTER | INSTEAD OF} -- Momento de disparo DESPUÉS | EN LUGAR DE
{ [INSERT] [,] [UPDATE][,][DELETE]} -- Acción a ejecutar
AS
BEGIN
Sentencias T-SQL
Uso de tablas
inserted, deleted
END
a) "after": el trigger se dispara cuando las acciones especificadas (insert, delete
y/o update) son ejecutadas; todas las acciones en cascada de una restricción
"foreign key" y las comprobaciones de restricciones "check" deben
realizarse con éxito antes de ejecutarse el trigger. Es la opción por defecto si
solamente colocamos "for" (equivalente a "after").
b) "instead of": Se ejecutan en lugar de la acción desencadenante, es decir,
cancelan la acción desencadenante (suceso que disparó el trigger)
reemplazándola por otras acciones. Se puede definir solamente un
disparador de este tipo para cada acción (insert, delete o update) sobre una
tabla o vista.
Consideraciones
• Se pueden crear disparadores "instead of" en vistas y tablas.
• No se puede crear un disparador "instead of" en vistas definidas "with check option".
• No se puede crear un disparador "instead of delete" y "instead of update" sobre
tablas que tengan una "foreign key" que especifique una acción "on delete cascade"
y "on update cascade" respectivamente.
• No pueden crearse disparadores "after" en vistas ni en tablas temporales; pero
pueden referenciar vistas y tablas temporales.
• Si existen restricciones en la tabla del disparador, se comprueban DESPUÉS de la
ejecución del disparador "instead of" y ANTES del disparador "after". Si se infringen
las restricciones, se revierten las acciones del disparador "instead of"; en el caso del
disparador "after", no se ejecuta.