Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Procedimiento-Almacenado OK PDF
Procedimiento-Almacenado OK PDF
RESUMEN
El presente laboratorio consiste en indagar sobre procedimientos almacenados desde su generalidad hasta
ejemplos específicos, partiendo de una base teórica conceptual para afianzar los conocimientos previos que
tengan los participantes
Para ello el equipo encargado del desarrollo del presente laboratorio está conformado por 7 personas cuyos
roles se han definidos para mejor desarrollo del laboratorio.
En el proceso de desarrollo de investigación y ejecución del laboratorio se usara como recursos el gestor de
base de datos SQL Server 2008, el tiempo recomendado para el desarrollo del laboratorio es de 10 minutos
por laboratorio y el tiempo que ud requiera para asimilar bien la teoría. Dicho punto es fundamental para
poder proseguir con los ejercicios, lea atentamente cada indicación y teoría, no intente avanzar a otro punto
sin antes haber asimilado el punto anterior.
Con respecto a los recursos financieros y el gasto que implica desarrollar el laboratorio solo será de que Ud.
cuente con la licencia necesaria para ejecutar el SQL Sever
Desde que el hombre comenzó a utilizar medios digitales para almacenar su información
comenzó a enfrentarse con problemas para hacer mas práctico este proceso, es lógico pensar
que desde la utilización de los archivos ( que son los antecesores de las bases de datos ) se
les fueron integrando algunas mejoras hasta llegar a la concepción que actualmente se
tienen de base de datos, al paso del tiempo las empresas de la industria de software en
especial la relacionada con las bases de datos incorporaron mecanismos como los
mencionados en el sección 2.2 hasta llegar paulatinamente a incorporar, los procedimientos
almacenados.
Los procedimientos almacenados no son nuevos en la industria de las bases de datos, como referencia
se tiene a ORACLE, que presentó PL/SQL 2, su implementación de un lenguaje procedimental para SQL,
esto por el año de 1991, SYBASE, PROSTGRESSQL Y DB2 están entre los otros DBMS que en breve
siguieron este tan socorrido lenguaje procedimental para sentencias SQL.
Cubrir las diferentes necesidades de los usuarios de un DBMS debe de ser la filosofía a seguir de la
industria de las bases de datos y este comentario es seguro que no pasó desapercibido por los
desarrolladores ya que la totalidad de las bases de datos están haciendo o hicieron esfuerzos por
incorporar los procedimientos almacenados a su software. Y se menciona de esta manera porque en
realidad en estos tiempos en los que gran parte de la información del mundo se encuentra alojada en
BD esto fue una necesidad, como lo pueden corroborar los capítulos que continúan.
La tendencia de las bases de datos actualmente va encaminada a darle más conocimiento a las bases
de datos que a la aplicación, esto quiere decir que el cliente esté enterado lo menos posible de la
estructura lógica de la DB, o al menos esto muestra la clara incorporación de algunos elementos como
la integridad referencial, actualización y eliminación en cascada, disparadores, UDF´S y ahora
procedimientos almacenados, los cuales realizan labores que antes eran propias de las aplicaciones
cliente.
Los procedimientos almacenados son una herramienta que todo desarrollador debe tener en cuenta
siempre, ya que proporcionan un rendimiento en términos de velocidad e incrementan la seguridad en
su sistema de base de datos, es por ello que su empleo en los diferentes proyectos incrementa la
calidad del desarrollo de software. Ahora se muestra la definición de un procedimiento almacenado.
2. OBJETIVOS
Un procedimiento es un subprograma que ejecuta una acción específica y que no devuelve ningún
valor. Un procedimiento tiene un nombre, un conjunto de parámetros (opcional) y un bloque de
código.
Debemos especificar el tipo de datos de cada parámetro. Al especificar el tipo de dato del
parámetro no debemos especificar la longitud del tipo.
Los parámetros pueden ser de entrada (IN), de salida (OUT) o de entrada salida (IN OUT). El valor
por defecto es IN, y se toma ese valor en caso de que no especifiquemos nada.
CREATE OR REPLACE
PROCEDURE Actualiza_Saldo(cuenta NUMBER,
new_saldo NUMBER)
IS
-- Declaracion de variables locales
BEGIN
-- Sentencias
UPDATE SALDOS_CUENTAS
SET SALDO = new_saldo,
FX_ACTUALIZACION = SYSDATE
WHERE CO_CUENTA = cuenta;
END Actualiza_Saldo;
También podemos asignar un valor por defecto a los parámetros, utilizando la clausula DEFAULT
o el operador de asiganción (:=) .
CREATE OR REPLACE
PROCEDURE Actualiza_Saldo(cuenta NUMBER,
new_saldo NUMBER DEFAULT 10 )
IS
-- Declaracion de variables locales
BEGIN
-- Sentencias
UPDATE SALDOS_CUENTAS
SET SALDO = new_saldo,
FX_ACTUALIZACION = SYSDATE
WHERE CO_CUENTA = cuenta;
END Actualiza_Saldo;
Una vez creado y compilado el procedimiento almacenado podemos ejecutarlo. Si el sistema nos
indica que el procedimiento se ha creado con errores de compilación podemos ver estos errores de
compilación con la orden SHOW ERRORS en SQL *Plus.
Notación posicional: Se pasan los valores de los parámetros en el mismo orden en que el procedure
los define.
BEGIN
Actualiza_Saldo(200501,2500);
COMMIT;
END;
BEGIN
Actualiza_Saldo(cuenta => 200501,new_saldo => 2500);
COMMIT;
END;
Rendimiento
Cada vez que un comando Transact-SQL, o conjunto de comandos, es enviado el servidor para
su procesamiento, el servidor debe determinar si el remitente tiene suficientes privilegios para
ejecutar esos comandos y si los comandos son válidos. Una vez que los permisos y la sintaxis de
los comandos se han verificado, SQL Server construye un plan de ejecución para procesar el
pedido.
La relativa pérdida de rendimiento producida por ubicar los planes de ejecución de los
procedimientos almacenados en el caché de procedimiento se reduce ya que los planes de
ejecución para todos los comandos SQL se guardan ahora en el caché de procedimientos. Por
lo que un comando Transact-SQL tratará de utilizar un plan de ejecución ya existente en todos
casos posibles.
Marco de programación
Una vez que se crea un procedimiento almacenado, puede ser llamado todas las veces que sea
necesario. Esta capacidad provee modulación y habilita la reutilización del código. La
reutilización del código mejora el mantenimiento de la base de datos al aislar la base de datos
de los cambios en las prácticas del negocio. Si las reglas de negocios cambian en una
organización, se puede modificar a los procedimientos almacenados para cumplir con las
nuevas reglas de negocio. Todas las aplicaciones que llaman a esos procedimientos
almacenados cumplirán con la nuevas reglas, sin tener que ser directamente modificados.
Tal y como otros lenguajes de programación, los procedimientos almacenados pueden aceptar
parámetros de ingreso, retornar parámetros de salida, producir información de
retroalimentación de la ejecución en la forma de códigos de estatus y texto descriptivo, y
llamar a otros procedimientos. Por ejemplo, un procedimiento almacenado puede retornar un
código de estatus a un procedimiento que lo llamó para que este procedimiento realice una
operación según el código recibido.
Los desarrolladores de software pueden escribir sofisticados en un lenguaje como el C++;
luego, se puede utilizar un tipo especial de procedimiento almacenado, denominado
procedimiento almacenado extendido, para invocar al programa desde dentro del SQL Server.
Ante cualquier tarea simple, se debería escribir un procedimiento almacenado. Mientras más
genérico sea el procedimiento más útil será para muchas bases de datos. Por ejemplo; el
procedimiento almacenado sp_rename cambia el nombre de un objeto creado por el usuario,
tal como una tabla, una columna o un tipo de datos definido por el usuario en la base de datos
actual, pudiéndose aplicar a cualquier base de datos.
Seguridad
En la actualidad existes cinco categorías de procedimientos almacenados, entre los que podemos
mencionar:
Procedimientos almacenados del sistema
Procedimientos almacenados locales
Procedimientos almacenados temporarios
Procedimientos almacenados extendidos
Procedimientos almacenados remotos.
Usan un programa externo, compilado como un DLL para expandir las capacidades de un
procedimiento almacenado. La mayoría de los procedimientos almacenados extendidos usan el
prefijo xp_ como un convención de nombre. Sin embargo, hay algunos procedimientos
almacenados extendidos que comienzan con el prefijo sp_, y hay algunos procedimientos
almacenados del sistema que no son procedimientos extendidos y usan el prefijo xp_. Por lo
tanto, no se puede depender sobre convención de nombres para identificar procedimientos
almacenados del sistema y procedimientos almacenados extendidos.
--Operacion.
--Nota: Se puede hacer uso de SELECT y/o SET para la asignacion de valores a las variables.
SELECT @Resultado = ISNULL(@Numero1, 0) + ISNULL(@Numero2, 0)
SET @Operacion = CAST(@Numero1 AS VARCHAR) + ' + ' + CAST(@Numero2 AS VARCHAR) + '
= ' + CAST(@Resultado AS VARCHAR)
GO
b. Procedimiento con parámetros de entrada. Como su nombre lo dice son
procedimientos que no necesitan algún parámetro extra para ser ejecutado como una
variable de entrada.
Ejemplo:
CREATE PROCEDURE spSumaConParametros @Numero1 FLOAT,
@Numero2 FLOAT AS
--Declaracion de variables
DECLARE
@Resultado FLOAT,
@Operacion NVARCHAR(25)
--Operacion.
--Nota: Se puede hacer uso de SELECT y/o SET para la asignacion de valores a las
variables.
SELECT @Resultado = ISNULL(@Numero1, 0) + ISNULL(@Numero2, 0)
SET @Operacion = CAST(@Numero1 AS VARCHAR) + ' + ' + CAST(@Numero2 AS
VARCHAR) + ' = ' + CAST(@Resultado AS VARCHAR)
AS
--Declaracion de variables
DECLARE @Operacion NVARCHAR(25)
--Operacion.
--Nota: Se puede hacer uso de SELECT y/o SET para la asignacion de valores a las variables.
SELECT @Resultado = ISNULL(@Numero1, 0) + ISNULL(@Numero2, 0)
SET @Operacion = CAST(@Numero1 AS VARCHAR) + ' + ' + CAST(@Numero2 AS VARCHAR) + '
= ' + CAST(@Resultado AS VARCHAR)
Pasos a seguir:
a) Leer la base teórica del ejercicio , ayudarse del manual o de información que encuentre en intenet
b) Ejecutar las demos planteadas
c) Verificar que el resultado sea igual al planteado
d) Verificar que se cumplan los objetivos
Mejoras:
Para sugerencias y mejoras de los procedimientos colgar su respuesta o publicación en nuestro blog y/o
wikispace:
http://jhacs.blogspot.com
http://jhacs.wikispaces.com
5) LABORATORIOS
Al finalizar el código usamos: exec ejemplo01 el cual indicara que el procedimiento a sido realizado
correctamente…
Lab 1.1 Ahora crearemos y ejecutaremos un nuevo Procedimiento usando parámetros: Usando
tabla Empleado
Para modificar un procedimiento almacenado después haber sido creado se usa la sentencia:
BEGIN
[Consulta SQL]
END
Ahora mostramos un procedimiento almacenado con parámetros lo cual vamos a enseñarles a
modificar a continuación.
Para mostrar el cliente según su código lo cual vamos a modificar para que nos muestre todos los
cliente según el código de ciudad
[@parametros]
BEGIN
[Consulta SQL]
END
Laboratorio 03 (Lab Intermedio): Creando un procedimiento almacenado para insertar registros
Vamos a crear un procedimiento almacenado para insertar empleados.
Dando un visto a Todos Los registros antes de poder eliminar lo que queremos.
Podremos crear Procedimientos Almacenados de 2 maneras:
Ejecutamos el Procedimiento
Nos queda de esta manera:
Ahora si no por “x” motivos no ingresamos un valor pues nos mostrara un mensaje así:
if (@cod is null)
begin
print 'debe ingresar codigo de empleado'
return 1
end
--- verificamos que el codigo exista entre los empleados
return 0
go
-----------------Hasta aqui el procedimienteto
---Ahora lo ejecutamos
Al Declarar variables es Transact SQL no hay distincion entre los nombres de las variables por
MAYUSCULAS y MINUSCULAS
Una variable es un valor identificado por un nombre (identificador) sobre el que podemos realizar
modificaciones.
En Transact SQL los identificadores de variables deben comenzar por el caracter @, es decir, el
nombre de una variable debe comenzar por @. Para declarar variables en Transact SQL debemos
utilizar la palabra clave declare, seguido del identificador y tipo de datos de la variable.
if (@vch_cliepaterno is null or
@vch_cliematerno is null or
@chr_cliedni is null or
@vch_clieciudad is null or
@vch_cliedireccion is null )
begin
print 'debe ingresar los parametros'
return 1
end
begin transaction
--declaramos la variable @int_contitem para almcenar el contador
de --clientes que se lleva en la tabla contador
set
@chr_cliecodigo=RIGHT('00000'+CONVERT(varchar(5),@int_contitem),5)
begin transaction
insert into
Cliente(chr_cliecodigo,vch_cliepaterno,vch_cliematerno,vch_clienomb
re,
chr_cliedni,vch_clieciudad,vch_cliedireccion,vch_clietelefono,vch_c
lieemail)
values(@chr_cliecodigo,@vch_cliepaterno,@vch_cliematerno,@vch_clien
ombre,
@chr_cliedni,@vch_clieciudad,@vch_cliedireccion,@vch_clietelefono,@
vch_clieemail)
if(@@error<>0)
begin
rollback transaction
return 3
end
commit transaction
return 0
go
Así como en el ejemplo del punto 13 nos ayudaremos de variables para ejecutar de
manera más sencilla el procedimiento y mostrar los resultados
execute @rtn=usp_insertarcliente
@pat,@mat,@nom,@dni,@ciudad,@direccion,@telefono,@email,@cod output
end,[codigo]=@cod
6) CONCLUSIONES
Con los laboratorios antes realizados ,se ha podido notar la manera de encapsular sentencias SQL para
operaciones frecuentes en sistemas de información y su utilidad que ello conlleva.
Si bien en estos laboratorios no se ha podido mostrar una comparativa con respecto a tiempos de ejecución,
pues con esta clase de consultas y la cantidad de datos los tiempos de respuestas son cortos. Se deja en
claro que si adecuamos esto al tiempo y frecuencia de uso de dichas sentencias, además del tráfico y
cantidad de usuarios, usar un procedimiento almacenado resulta en un código más limpio, rapidez y eficacia
en resultados
Esto es especialmente útil cuando es imposible mediante una sentencia SQL el rescatar toda la información
que el usuario requiere, como por ejemplo en una factura del servicio telefónico que está sujeta a
promociones, tipos de cliente, tipos de llamadas, localidades, horarios pico y no pico etc, para lo cual es
necesario consultar varias tablas. La factura del recibo telefónico puede llegar a su realización mediante dos
diferentes caminos, el caso A, en el cual la aplicación cliente solicitaría al DBMS cada consulta que considere
necesaria para formar la factura o el caso B en el que en el DBMS se almacenaría la rutina para que se
ejecutarán todas las sentencias SQL necesarias y enviaría como respuesta una estructura de información en
la cual la aplicación cliente tendría todas los datos necesarios para imprimir dicha factura.
Es necesario realizar una diferencia en el uso de los procedimientos almacenados y las UDF (funciones
definidas por el usuario) ya que los dos actúan de manera muy parecida, esta diferencia consiste en que los
procedimientos almacenados aceptan una entrada múltiple y múltiples parámetros de salida, mientras que
una UDF al igual que el procedimiento acepta una entrada múltiple pero solamente un único valor de salida,
son fáciles de diferenciar ya que las UDF son compiladas en el servidor y se incrustan principalmente en
sentencias SQL similares a sum(),count() etc.. Mientras que los procedimientos no es necesario compilarlos,
y se utilizan sobretodo sentencias SQL.
Los estándares se hacen presentes en este tema, y es lógico, ya que con ellos se logra la unificación,
convencionalidad y posibilidad de utilización de diferentes bases de datos con las mismas sentencias SQL al
menos en los procedimientos almacenados, los DBMS mas robustos como ORACLE, SQL SERVER y MYSQL se
encuentran regidos bajo el estándar SQL:2003, aunque con algunas excepciones cada uno de ellos.
7) REFERENCIAS
1. http://www.wikilearning.com/monografia/procedimientos_almacenados_mysql_5/25854-5
2. http://sanchez-soft.blogspot.com/2006/11/sql-crear-un-procedimiento-almacenado.html
3. http://www.sqlmax.com/centro/ModuloIV_1.asp?MX=