CREACIONES DE

FUNCIONES DEFINIDAS
POR EL USUARIO
DEFINICIÓN
¿Qué significa función definida por el usuario?

Una función definida por el usuario (UDF) es un elemento común en los lenguajes de
programación y la principal herramienta de los programadores para crear aplicaciones con
código reutilizable. Dado que los programas se componen principalmente de código que
proviene del programador, o en este caso del usuario, la mayor parte se compone de funciones
definidas por el usuario puntuadas ocasionalmente por funciones integradas.

Las funciones definidas por el usuario (UDF) son extensiones o adiciones a las funciones
incorporadas existentes del lenguaje SQL.

Una función definida por el usuario puede ser una función escalar, que devuelve un solo valor
cada vez que se invoca; una función agregada, a la que se pasa un conjunto de valores
similares y devuelve un solo valor para el conjunto; una función de fila, que devuelve una fila o
una función de tabla, que devuelve una tabla.
FUNCIONALIDAD Y
VENTAJAS DEL
USO DE
FUNCIONES
En los esquemas SYSFUN y SYSPROC se proporcionan varias funciones definidas por el usuario.

Una función definida por el usuario (UDF) sólo puede ser una función agregada si su fuente es una
función agregada existente. Se hace referencia a una UDF mediante un nombre de función calificado o
no calificado, seguido de paréntesis que encierran los argumentos de la función (si los hay). Una
función de columna escalar definida por el usuario registrada con la base de datos puede aludirse en
los mismos contextos en que pueda aparecer cualquier función incorporada. Una función de fila
definida por el usuario sólo puede aludirse implícitamente cuando está registrada como función de
transformación para un tipo definido por el usuario. Una función de tabla definida por el usuario
registrada en la base de datos sólo puede aludirse en la cláusula FROM de una sentencia SELECT.

El resultado de la función es el especificado en la cláusula RETURNS. La cláusula RETURNS, definida

cuando se registró la UDF, determina si una función es una función de tabla o no lo es. Si se especifica
(o se toma como valor por omisión) la cláusula RETURNS NULL ON NULL INPUT al registrar la
función, el resultado es nulo si algún argumento es nulo. En el caso de las funciones de tabla, esto se
interpreta como una tabla de retorno sin filas (es decir, una tabla vacía).
FUNCIONES
ESCALARES
Una función escalar acepta opcionalmente argumentos y devuelve un único valor escalar cada
vez que se llama a la función.

Una función escalar se puede utilizar siempre que se pueda utilizar una expresión. No obstante,
las restricciones que se aplican al uso de expresiones y funciones agregadas, también se aplican
cuando una expresión o función agregada se utiliza dentro de una función escalar. Por ejemplo,
el argumento de una función escalar puede ser una función agregada sólo si se permite una
función agregada en el contexto en el que se utiliza la función escalar.

Las restricciones sobre el uso de funciones agregadas no se aplican a las funciones escalares,
ya que una función escalar se aplica a un único valor en vez de aplicarse a un conjunto de
valores.

El resultado de la siguiente sentencia SELECT contiene un mismo número de filas igual al

número de empleados que hay en el departamento D01:

SELECT EMPNO, LASTNAME, YEAR(CURRENT DATE - BRTHDATE) FROM EMPLOYEE

WHERE WORKDEPT = 'D01'
IMPLEMENTACIÓN
DE LAS
FUNCIONES
DENTRO DE UNA
CONSULTA
En función del entorno de QMF, QMF ofrece una cantidad distinta de métodos de consulta para
ayudarle a acceder y a manipular los datos que necesita.

Cuando se devuelven los resultados de la consulta, puede formatear los datos y convertirlos en
informes, diagramas, gráficos, correlaciones o paneles de instrumentos.

• Consultas analíticas
Con las consultas analíticas, puede combinar datos de varias consultas que abarcan desde
los mismos orígenes de datos u orígenes de datos diferentes en un conjunto de resultados.

• Consultas relacionales
QMF ofrece distintos métodos de consulta en función del nivel de conocimientos de SQL que
tiene el usuario.

• Consultas multidimensionales
QMF para Workstation y QMF para WebSphere dan soporte al análisis multidimensional
mediante el uso de consultas OLAP.
 USO DE ROLES Y
PERMISOS DE ACCESO
ROLES DE NIVEL DE BASE
DE DATOS
DEFINICIÓN
Los roles fijos de base de datos se definen en el nivel de base de datos y existen en
cada una de ellas. Los miembros de los roles de base de datos db_owner pueden
administrar la pertenencia a roles fijos de base de datos. También hay algunos roles de
base de datos con fines especiales en la base de datos msdb.

Puede agregar cualquier cuenta de la base de datos y otros roles de SQL Server a los
roles de nivel de base de datos.

Los permisos de los roles de base de datos definidos por el usuario se pueden
personalizar con las instrucciones GRANT, DENY y REVOKE. Para más información,
consulte Permisos (motor de base de datos).
FUNCIONES DE
SEGURIDAD
Amenazas potenciales
Los clientes que tienen agentes con cifrado activado se preocupan fundamentalmente por lo siguiente:

• Divulgación de información por incumplimiento de políticas

• Pérdida o destrucción de datos
• Demora inaceptable en la restauración de los datos en caso de fallo catastrófico (por ejemplo, en un
sitio donde la continuidad comercial se vea afectada)
• Modificación de datos no detectada

Objetivos de las funciones de seguridad

Los objetivos de las funciones de seguridad de Oracle Key Manager son los siguientes:

• Proteger datos cifrados contra la divulgación.

• Minimizar la exposición a ataques.
• Proporcionar suficiente fiabilidad y disponibilidad.
El modelo de seguridad
En esta sección de la guía de seguridad, se intenta ofrecer una visión general de las amenazas
contra las que el sistema está diseñado para proteger y del modo en que se combinan las
funciones de seguridad individuales para evitar ataques.

• Las funciones de seguridad críticas que brindan estas protecciones son:

• Autenticación: garantiza que solo las personas autorizadas puedan acceder al sistema y a los
datos.
• Autorización: privilegios y datos de control de acceso al sistema; este control de acceso
complementa la autenticación para garantizar que solo las personas adecuadas tengan acceso.
• Auditoría: permite a los administradores detectar los intentos de violación del mecanismo de
autenticación y los intentos de violación o las violaciones del control de acceso.

Control de acceso
El control de acceso puede ser de los siguientes tipos:

• Control de acceso basado en roles y usuarios

• Protección por quórum
FUNCIONES DE
CIFRADO
Protección para sus datos

El cifrado utiliza la ciberseguridad para defenderse de la fuerza bruta y los ciberataques, incluidos
el malware y el ransomware. El cifrado de datos funciona asegurando los datos digitales
transmitidos en la nube y los sistemas informáticos.

Tipos de cifrado de datos:

• Métodos de cifrado asimétrico:

El cifrado asimétrico, también conocido como criptografía de clave pública, cifra y descifra los
datos utilizando dos claves asimétricas criptográficas independientes. Estas dos claves se
conocen como "clave pública" y "clave privada".

• Métodos de cifrado simétrico:

El cifrado simétrico es un tipo de cifrado en el que solo se utiliza una clave simétrica secreta
para cifrar el texto sin formato y descifrar el texto cifrado.
 CONTROL DE ERRORES
EN TRANSACT SQL.
FUNCIONES ESPECIALES
DE ERROR.
DEFINICIÓN
el desarrollo y programación de Control de Errores con Transact-SQL (TSQL) en SQL Server
2000 y SQL Server 2005 (y superiores), una práctica muy recomendada y necesaria para el
desarrollo y programación de procedimientos almacenados y transacciones con SQL Server. Se
describe la utilización de la función del sistema @@ERROR, la opción del sistema
XACT_ABORT, la sentencia RAISERROR, la utilización de errores definidos por el usuario
(sp_addmessage), y los bloques TRY/CATCH (disponible desde SQL Server 2005).

SQL Server incorpora diferentes alternativas de Control de Errores para el desarrollo y

programación en Transact-SQL, algunas más conocidas (ej: la función del sistema @@ERROR
o la sentencia RAISERROR), otras más desconocidas (ej: la opción de configuración
XACT_ABORT), y otras relativamente nuevas al incorporarse en la versión SQL Server 2005 (ej:
bloques TRY/CATCH).
 UTILIZAR
@@ERROR PARA
PROGRAMAR EL
CONTROL DE
ERRORES
Esta función del sistema debe utilizarse inmediatamente después de cada sentencia, de tal
modo, que devuelve un cero o bien el código de error que se pueda haber producido.
Habitualmente, se suelen utilizar bloques del tipo IF @@ERROR<>0. El principal
inconveniente es que requiere realizar este control de errores después de cada sentencia.
Por ejemplo, si tenemos un procedimiento almacenado con siete sentencia DML (ej: INSERT,
UPDATE, etc.), deberemos realizar la comprobación de @@ERROR siete veces, una vez
después de cada sentencia DML, lo cual complica y hace más pesado nuestro código.
Incluso en ocasiones, nos encontraremos sentencias tipo IF @@ERROR<> GOTO TrataError
(dios! utilizando incluso saltos incondicionales, como con el Spectrum y el Amstrad CPC, jeje
;-). Por desgracia, es una forma de control de errores algo habitual en procedimientos
almacenados de SQL Server 2000 (bueno, en procedimientos almacenados y en cualquier
bloque de código Transact-SQL).

Un problema típico, es cuando se necesitan consultar varias funciones del sistema, como
@@ERROR y @@ROWCOUNT. En éste caso, NO se deben consultar las dos variables en
sentencias diferentes (recordar que tienen efecto en la consulta inmediatamente anterior), por
lo que habrá que declarar y utilizar algunas variables temporales, y depositar en ellas el
resultado de consultar estas variables del sistema, de forma similar a:

SELECT @TMP_ERROR=@@ERROR, @TEMP_ROWCOUNT=@@ROWCOUNT

Seguidamente, podremos consultar dichas variables temporales, que almacenarán el valor
deseado. Si no lo hacemos de este modo, tendremos un problema. Imaginemos el siguiente
código:

SELECT @TEMP_ROWCOUNT=@@ROWCOUNT
SELECT @TMP_ERROR=@@ERROR

La segunda línea de código estará haciendo referencia a si la línea anterior ha generado algún
error. La confusión de esto viene dada, porque en ocasiones se ponen estas dos líneas detrás
de un bloque de código, y se piensa que la segunda sentencia (la de @@ERROR) tiene efecto
sobre el bloque de código previo, cuando NO es así, tiene efecto sobre la línea de código
inmediatamente anterior (la del @@ROWCOUNT), por lo tanto dicha gestión de errores
simplemente no funcionará ¿visto? Sigamos.
 UTILIZAR SET
XACT_ABORT
PARA
PROGRAMAR
TRANSACCIONES
Resulta muy cómodo utilizar la opción XACT_ABORT para la programación de transacciones. Al
activar esta opción (SET XACT_ABORT ON), si se produce un error en tiempo de ejecución, SQL
Server deshará completamente todas las transacciones abiertas. Esto simplifica enormemente la
programación de transacciones, y además, está disponible desde SQL Server 2000 (toma ya ;-),
y así evitamos tener que hacer la tediosa tarea de comprobar el valor de @@ERROR después
de cada sentencia para poder deshacer la transacción correctamente, y que en caso de errores
no se confirmen resultados parciales.

Sin activar XACT_ABORT, que es el comportamiento por defecto de SQL Server (SET
XACT_ABORT OFF), sería necesario comprobar @@ERROR sucesivas veces (ojo, que estoy
descartando el uso de TRY/CATCH para ahora, y que veremos después), como en el siguiente
ejemplo:
Sin embargo, utilizando XACT_ABORT activado resulta mucho más sencillo, teniendo la garantía
de que se confirmará o deshará la transacción por completo sin necesidad de programar las
comprobaciones de la función del sistema @@ERROR:

El principal caso de uso de XACT_ABORT es el ejemplo anterior, para el manejo de

transacciones, eso sí, cuando NO es necesario realizar una gestión más completa de los errores,
ya que si se desea programar un Control de Errores más complejo (ej: registrar el error
producido, imprimir - print - mensajes personalizados para cada error, etc.), al menos hasta SQL
Server 2000 es necesario sufrir del uso de la función de sistema @@ERROR (claro, que desde
SQL Server 2005, podemos utilizar TRY/CATCH).
 UTILIZAR
TRY/CATCH PARA
PROGRAMAR EL
CONTROL DE
ERRORES
La gestión de errores a través de bloques TRY/CATCH está disponible desde SQL Server 2005,
simplificándose enormemente la gestión de errores en código Transact-SQL (como en el caso de
la programación de procedimientos almacenados). Cualquier error que se produzca dentro del
bloque TRY provocará que se salte a la ejecución del bloque CATCH sin enviar ningún error al
cliente, mientras, que cualquier error que se produzca dentro del bloque CATCH SI se enviará al
cliente (excepto que anidemos estructuras TRY/CATCH). Así, la ejecución de sentencias
RAISERROR dentro de bloques TRY fuerza que se salte la ejecución al correspondiente bloque
CATCH.
De éste modo, dentro del bloque CATCH podemos hacer uso de nuevas funciones del sistema
para registrar el error producido o lanzar el error (RAISERROR) a la aplicación cliente. En
particular, podemos utilizar las siguientes funciones:

ERROR_NUMBER().
ERROR_MESSAGE().
ERROR_SEVERITY().
ERROR_STATE().
ERROR_PROCEDURE().
ERROR_LINE()

Un problema de la utilización de RAISERROR, es que no es posible lanzar (o re-lanzar) un error

del sistema desde el bloque CATCH. Esto es, si se produce un error dentro de nuestro bloque
TRY, la ejecución se pasará al bloque CATCH, sin embargo, NO es posible desde el bloque
CATCH re-lanzar el error original (ya que este intento, provocará un nuevo error ;-), por lo cual,
como mucho podremos lanzar un error personalizado, he incluir en el texto del error la
información que deseemos.
 LA VARIABLE DE
SISTEMA @@ERROR.
DEFINICIÓN
 @@ERROR debe comprobarse o guardarse
después de cada instrucción de Transact-SQL
porque un programador no puede predecir qué
instrucción puede generar un error. Esto dobla el
número de instrucciones de Transact-SQL que
deben codificarse para implementar un fragmento
de lógica dado. Podemos usar directamente
@@ERROR o cargarla en una @variable para su
posterior tratamiento, vamos a ver un par de
ejemplos. Es interesante cargar el valor de
@@ERROR en una @variable, justo después de la
consulta que deseamos verificar si se ha producido
error, ya que si no lo hacemos, cualquier otra
ejecución puede modificar el valor de @@ERROR y
perderíamos ese control del error sobre la consulta
que deseemos.
EJEMPLOS
A. Utilizar @@ERROR para detectar un error específico
En el ejemplo siguiente se utiliza @@ERROR para comprobar si se infringe una restricción CHECK
(error nº 547) en una instrucción UPDATE.
B. Utilizar @@ERROR para salir
condicionalmente de un procedimiento
En el ejemplo siguiente se utilizan las
instrucciones IF...ELSE para probar
@@ERROR después de una instrucción
DELETE en un procedimiento almacenado. El
valor de la variable @@ERROR determina el
código devuelto enviado al programa que llamó,
lo que indica si el procedimiento se realizó
correcta o incorrectamente.
C. Utilizar @@ERROR con @@ROWCOUNT
En el ejemplo siguiente se utiliza @@ERROR con
@@ROWCOUNT para validar la operación de una
instrucción UPDATE. Se comprueba el valor de
@@ERROR para ver si hay un error y se utiliza
@@ROWCOUNT para asegurarse de que la
actualización se aplica correctamente a una fila de la
tabla.