1.

FUNCIONES EN LAS BASES DE DATOS

Las funciones de agrupación son utilizadas por sistemas gestores de bases de datos de manera
que operen sobre conjuntos de filas para dar un resultado por grupo.
Existen dos tipos de funciones:

La diferencia fundamental es que mientras las primeras realizan la acción sobre una única fila cada
vez, las de agrupación obtienen un resultado a partir de un conjunto de elementos. Se trata de
seleccionar un conjunto de elementos, filtrarlos por las condiciones que creamos oportunas y
obtener un resultado a partir de él.
Las funciones son habilidades poderosas de SQL. Pueden ser usadas para lo siguiente:

• Desarrollar cálculos en los datos.

• Modificar datos individuales.

• Manipular la salida de grupos de filas.

• Dar formato a fechas y números.

• Convertir tipos de datos de columnas.

Las funciones SQL algunas veces reciben argumentos pero siempre retornan un valor.

1.1 Funciones de fila única

Estas funciones operan solo en una única fila y retorna un valor por cada una. Hay diferentes tipos
de funciones de fila única:

• Carácter
• Numérica
• Fecha
• Conversión
• General
Las funciones de fila única son usadas para manipular elementos de datos. Ellas aceptan uno o más
argumentos y retorna un valor por cada fila que es retornada por la consulta. Un argumento puede
ser alguno de los siguientes:

• Constantes.
• Valores variables.
• Nombres de columnas.
• Expresiones.

Algunas características de funciones de fila única son:

• Actúan por cada fila retornada por la consulta.

• Retornan un valor por cada fila.
• Posibilitan el retorno de un valor de dato de un tipo diferente de que es originalmente
referenciado.
• Posibilidad de esperar uno o más argumentos.
• Pueden ser usadas en las cláusulas SELECT, WHERE y ORDER BY; pueden ser
anidadas.

En el caso de las funciones de fila única, cada sistema gestor de base de datos proporciona sus
propias funciones. Por ello, se recomienda buscar en la documentación técnica de cada gestor de
base de datos, las funciones existentes para el tratamiento de cadenas, fechas, etc.
Veamos a continuación algunas de estas funciones:

Descripción de algunas funciones para Oracle.

De cadenas:

• CONCAT: une valores en uno solo (está limitado a dos valores).

• SUBSTR: extrae una cadena de determinada longitud.
• LENGTH: muestra la longitud de una cadena como un valor numérico.
• INSTR: encuentra la posición numérica de un carácter específico.
• LPAD: retorna una cadena con un formato de n caracteres adicionales a la izquierda
de la cadena original.
• RPAD: retorna una cadena con un formato de n caracteres adicionales a la derecha de
la cadena original.
• REPLACE: reemplaza en una cadena original un carácter específico por otro carácter
específico.
• TRIM: elimina un carácter específico al inicio, o al final o en ambos lados de una
cadena.

De fechas:

• MONTHS_BETWEEN: número de meses entre dos fechas. Puede ser negativo si la

primera fecha es menor que la segunda.
• ADD_MONTHS: agregar meses a una fecha. El número de meses a agregar puede
ser negativo.
• NEXT_DAY: próximo día de la fecha especificada.
• LAST_DAY: último día del mes de la fecha.
 • ROUND: redondea una fecha según el formato especificado.
• TRUNC: trunca una fecha según el formato especificado.
• TO_CHAR: convierte a caracteres una fecha según el formato.
• TO_DATE: convierte a fecha una cadena de caracteres válida.

Ejemplo aplicando funciones de fila única

SELECT employee_id, CONCAT(firt_name, last_name) NAME

LENGTH(last_name), INSTR(last_name,'a') "Constains 'a'?"

FROM employees

WHERE SUBSTR(last_name, -1, 1) = 'n';

1.2 Funciones de agregación primitivas

A diferencia de las funciones de fila única, las de agrupamiento son estándar en todos los gestores
de bases de datos, el SQL nos ofrece las siguientes funciones de agregación para efectuar varias
operaciones sobre los datos de una base de datos:

• avg calcula la media aritmética de un atributo o una expresión numérica.

• min devuelve el mínimo de un atributo o expresión numérica.
• max calcula el valor máximo de un atributo o expresión numérica.
• sum devuelve la suma total de atributos o expresiones numéricas.
• count (*) contador de tuplas.
• count(distinct) es un contador de tuplas parcial, no tiene en cuenta valores nulos ni
duplicados.

En general, las funciones de agregación se aplican a una columna, excepto la función de agregación
COUNT, que normalmente se aplica a todas las columnas de la tabla o tablas seleccionadas. Por lo
tanto, COUNT (*) contará todas las filas de la tabla o las tablas que cumplan las condiciones. Si se
utilizara COUNT (distinct columna), sólo contaría los valores que no fuesen nulos ni repetidos, y si
se utilizara COUNT (columna), sólo contaría los valores que no fuesen nulos.

Ejemplo de utilización de la función COUNT (*)

Veamos un ejemplo de uso de la función COUNT, que aparece en la cláusula SELECT, para hacer
la consulta “¿Cuántos departamentos están ubicados en la ciudad de Santa Ana?”:

SELECT COUNT(*) AS numero_dep

FROM departamentos

WHERE ciudad_dep = 'Santa Ana';

2. FUNCIONES ALMACENADAS EN LAS BASES DE DATOS

Las funciones pueden ser llamadas dentro de sentencias SQL como SELECTs, INSERTs, etc.
Las funciones son iguales que los procedimientos pero además devuelven un valor, por lo que la
llamada a una función debe realizarse dentro de una expresión.

Sintaxis para la creación de una función almacenada

El uso de OR REPLACE permite sobrescribir una función existente. Si se omite, y la función existe,
se producirá, un error.
La sintaxis de los parámetros es la misma que en los procedimientos almacenados, exceptuando
que solo pueden ser de entrada.
La orden RETURN dentro de una función devuelve el valor que la función debe devolver, el cual se
convierte al tipo especificado en la cabecera de la función. Puede haber más de una instrucción
RETURN, pero solo se ejecutará la primera que se encuentre dentro de la lógica del programa.

Ejemplo de creación de una función almacenada:

Un ejemplo para MySQL sería:

Ejemplo más complejo, utilizando instrucciones de decisión:

SUB CONSULTAS

Una sub consulta es una consulta incluida dentro de una cláusula WHERE o HAVING de otra
consulta. En ocasiones, para expresar ciertas condiciones no hay más remedio que obtener el
valor que buscamos como resultado de una consulta.
Una sub consulta es una sentencia SELECT que aparece dentro de otra sentencia SELECT.
Normalmente se utilizan para filtrar una cláusula WHERE o HAVING con el conjunto de resultados
de la sub consulta, aunque también pueden utilizarse en la lista de selección.

Por ejemplo, podríamos consultar el alquiler último de un cliente:

En este caso, la sub consulta se ejecuta en primer lugar, obteniendo el valor de la máxima fecha
de alquiler y, posteriormente, se obtienen los datos de la consulta principal.
Una sub consulta tiene la misma sintaxis que una sentencia SELECT normal exceptuando que
aparece encerrada entre paréntesis. La sub consulta se puede encontrar en la lista de selección,
en la cláusula WHERE o en la cláusula HAVING de la consulta principal.
Tiene las siguientes restricciones:

• No puede contener la cláusula ORDER BY.

• No puede ser la UNION de varias sentencias SELECT.

• Si la sub consulta aparece en la lista de selección, o está asociada a un operador igual

"=" solo puede devolver un único registro.

Referencias externas

A menudo, es necesario, dentro del cuerpo de una sub consulta, hacer referencia al valor de una
columna de la fila actual en la consulta principal, ese nombre de columna se denomina referencia
externa. Una referencia externa es un campo que aparece en la sub consulta pero se refiere a una
de las tablas designadas en la consulta principal. Cuando se ejecuta una consulta que contiene
una sub consulta con referencias externas, la sub consulta se ejecuta por cada fila de la consulta
principal.

En este ejemplo la sub consulta aparece en la lista de selección, ejecutándose una vez por cada
fila que devuelve la consulta principal.

Anidar sub consultas

Las sub consultas pueden anidarse de forma que una sub consulta aparezca en la cláusula
WHERE (por ejemplo) de otra sub consulta que a su vez forma parte de otra consulta principal:

Los resultados que se obtienen con sub consultas normalmente pueden conseguirse a través de
consultas combinadas (JOIN):

Podrá escribirse como:

Normalmente es más rápido utilizar un JOIN en lugar de una sub consulta, aunque esto depende
sobre todo del diseño de la base de datos y del volumen de datos que tenga.

Utilización de sub consultas con UPDATE

Podemos utilizar sub consultas también en consultas de actualización conjuntamente con
UPDATE. Normalmente se utilizan para "copiar" el valor de otra tabla:

La función EXISTS

EXISTS es una función SQL que devuelve verdadero cuando una sub-consulta retorna al menos
una fila:

La función EXISTS puede ser utilizada en cualquier sentencia SQL válida, SELECT, UPDATE,
INSERT o DELETE.

4. OTROS PREDICADOS

4.1 Predicado BETWEEN

Para expresar una condición que quiere encontrar un valor entre unos límites concretos, podemos
utilizar BETWEEN:

SELECT nombre_columnas_a_seleccionar

FROM tabla_a_consultar

WHERE columna BETWEEN límite1 AND limite2;

Ejemplo de uso del predicado BETWEEN

Un ejemplo en el que se pide “Los códigos de los empleados que ganan entre 20.000 y 50.000
euros anuales” sería:

SELECT codigo_empl

FROM empleados

WHERE sueldo BETWEEN 2.0E+4 and 5.0E+4;

La respuesta sería:

4.2 Predicado IN

Para comprobar si un valor coincide con los elementos de una lista utilizaremos IN, y para ver si no
coincide, NOT IN:

SELECT nombre_columnas_a_seleccionar

FROM tabla_a_consultar

WHERE columna [NOT] IN (valor1, ..., valorN);

Ejemplo de uso del predicado IN:

“Queremos saber el nombre de todos los departamentos que se encuentran en las ciudades de
Lleida o Tarragona”:

SELECT nombre_dep, ciudad_dep

FROM departamentos

WHERE ciudad_dep IN ('Lleida', 'Tarragona');

La respuesta sería:
4.3 Predicado LIKE

Para comprobar si una columna de tipo carácter cumple alguna propiedad determinada, podemos
usar LIKE:
SELECT nombre_columnas_a_seleccionar FROM tabla_a_consultar WHERE columna LIKE
característica;
Los patrones del SQL92 para expresar características son los siguientes:

a. Pondremos un carácter “_” para cada carácter individual que queramos considerar.
b. Pondremos un carácter “%” para expresar una secuencia de caracteres, que puede no
estar formada por ninguno.

Ejemplo de uso del predicado LIKE:

A continuación, presentamos un ejemplo en el que buscaremos los nombres de los empleados que
empiezan por J, y otro ejemplo en el que obtendremos los proyectos que comienzan por S y tienen
cinco letras:
Nombres de empleados que empiezan por la letra J:

SELECT codigo_empl, nombre_empl

FROM empleados

WHERE nombre_empl LIKE 'J%';

La respuesta a esta consulta sería:

Proyectos que empiezan por S y tienen cinco letras:

SELECT codigo_proyec

FROM proyectos

WHERE nombre_proyec LIKE 'S_ _ _ _';

Y la respuesta a esta otra consulta sería:

4.4 Predicado IS NULL

Para comprobar si un valor es nulo utilizaremos IS NULL, y para averiguar si no lo es, IS NOT
NULL. El formato es:

SELECT nombre_columnas_a_seleccionar

FROM tabla_a_consultar

WHERE columna IS [NOT] NULL;

Ejemplo de uso del predicado IS NULL:

Un ejemplo de uso de este predicado sería “Queremos saber el código y el nombre de todos los
empleados que no están asignados a ningún proyecto”:

SELECT codigo_empl, nombre_empl

FROM empleados

WHERE num_proyec IS NULL;

Obtendríamos la respuesta:

4.5 Predicados ANY/SOME y ALL

Para ver si una columna cumple que todas sus filas (ALL) o algunas de sus filas (ANY/SOME)
satisfagan una condición, podemos hacer:

SELECT nombre_columnas_a seleccionar

FROM tabla_a_consultar

WHERE columna operador_comparación {ALL|ANY|SOME} subconsulta;

Ejemplo de uso de los predicados ALL y ANY/SOME

Veamos un ejemplo de aplicación de ALL para encontrar los códigos y los nombres de los
proyectos en los que los sueldos de todos los empleados asignados son menores que el precio del
proyecto:

SELECT codigo_proyec, nombre_proyec

 FROM proyectos

WHERE precio > ALL (SELECT sueldo

FROM empleados

WHERE codigo_proyec = num_proyec);

Fijémonos en la condición de WHERE de la sub consulta, que nos asegura que los sueldos que
observamos son los de los empleados asignados al proyecto de la consulta.

La respuesta a esta consulta sería:

A continuación, presentamos un ejemplo de ANY/SOME para buscar los códigos y los nombres de
los proyectos que tiene algún empleado que gana un sueldo más elevado que el precio del
proyecto en el que trabaja:

SELECT codigo_proyec, nombre_proyec

FROM proyectos

WHERE precio < ANY (SELECT sueldo

FROM empleados

WHERE codigo_proyec = num_proyec);

La respuesta a esta consulta está vacía, como se ve a continuación:

CONTROL DE LECTURA
 Lea, analice y responda las siguientes preguntas:

1. El contenido colocado en el predicado IN, podría ser sustituido por un

subquery.
.
Verdadero.

2. ¿A cuál tipo de función corresponde INSTR?

Función de fila única.

3. De los predicados que son utilizados en las instrucciones SQL, la que permite
hacer búsqueda en cadenas de caracteres que cumplan la posesión de algún
carácter en particular es:

LIKE.
De este modo si tuviéramos una tabla de ventas con un campo cliente, dicho campo contendría el
código del cliente de la tabla de cliente.
Sin embargo, esta forma de almacenar la información no resulta muy útil a la hora de consultar los
datos. SQL nos proporciona una forma fácil de mostrar la información repartida en varias tablas, las
consultas combinadas o JOINS.

Las consultas combinadas pueden ser de tres tipos:

• Combinación interna.

• Combinación externa.

• Uniones.
Consideremos una tabla de coches, en la que tenemos referenciada la marca a través del código
de marca. Para realizar la consulta combinada entre estas dos tablas debemos escribir una
consulta SELECT en cuya cláusula FROM escribiremos el nombre de las dos tablas, separados
por comas, y una condición WHERE que obligue a que el código de marca de la tabla de coches
sea igual al código de la tabla de marcas.

Lo más sencillo es ver un ejemplo directamente:

Démonos cuenta que hemos antepuesto el nombre de cada tabla al nombre del campo, esto no es
obligatorio si los nombres de campos no se repiten en las tablas, pero es aconsejable para evitar
conflictos de nombres entre campos. Por ejemplo, si para referirnos al campo marca no
anteponemos el nombre del campo la base de datos no sabe si queremos el campo marca de la
tabla tCoches, que contiene el código de la marca, o el campo marca de la tabla tMarcas, que
contiene el nombre de la marca.
Otra opción es utilizar la cláusula INNER JOIN. Su sintaxis es idéntica a la de una consulta
SELECT habitual, con la particularidad de que en la cláusula FROM sólo aparece una tabla o vista,
añadiéndose el resto de tablas a través de cláusulas INNER JOIN.

La sintaxis general utilizando INNER JOIN es la siguiente:

El ejemplo anterior escrito utilizando la cláusula INNER JOIN quedaría de la siguiente manera:

La cláusula INNER JOIN permite separar completamente las condiciones de combinación con otros
criterios, cuando tenemos consultas que combinan nueve o diez tablas esto realmente se
agradece. Sin embargo, muchos programadores no son amigos de la cláusula INNER JOIN, la
razón es que uno de los principales gestores de bases de datos, ORACLE, no la soportaba. Si
nuestro programa debía trabajar sobre bases de datos ORACLE no podíamos utilizar INNER JOIN.
A partir de la versión ORACLE 9i oracle soporta la cláusula INNER JOIN.

Según la naturaleza de nuestra consulta esto puede ser una ventaja, pero en otros casos significa
un serio problema. Para modificar este comportamiento SQL pone a nuestra disposición la
combinación externa. La combinación externa no es excluyente.

La sintaxis es muy parecida a la combinación interna:

La combinación externa puede ser diestra o siniestra, LEFT OUTER JOIN o RIGHT OUTER JOIN.
Con LEFT OUTER JOIN obtenemos todos los registros en la tabla que situemos a la izquierda de
la cláusula JOIN, mientras que con RIGHT OUTER JOIN obtenemos el efecto contrario.

Como mejor se ve la combinación externa es con un ejemplo:

Esta consulta devolverá todos los registros de la tabla tCoches, independientemente de que tengan
marca o no. En el caso de que el coche no tenga marca se devolverá el valor null para los campos
de la tabla tMarcas.

El mismo ejemplo con RIGHT OUTER JOIN:

Esta consulta devolverá los registros de la tabla tCoches que tengan marca relacionada y todos los
registros de la tabla tMarcas, tengan algún registro en tCoches o no.
Hay tres tipos de combinaciones externas: "left outer join", "right outer join" y "full outer join"; se
pueden abreviar con "left join", "right join" y "full join", respectivamente.
Se emplea una combinación externa izquierda para mostrar todos los registros de la tabla de la
izquierda. Si no encuentra coincidencia con la tabla de la derecha, el registro muestra los campos
de la segunda tabla seteados a "null".

En el siguiente ejemplo solicitamos el título y nombre de la editorial de los libros:

El resultado mostrará el título y nombre de la editorial; las editoriales de las cuales no hay libros, es
decir, cuyo código de editorial no está presente en "libros" aparece en el resultado, pero con el
valor "null" en el campo "titulo".
Es importante la posición en que se colocan las tablas en un "left join", la tabla de la izquierda es la
que se usa para localizar registros en la tabla de la derecha.
Entonces, un "left join" se usa para hacer coincidir registros en una tabla (izquierda) con otra tabla
(derecha); si un valor de la tabla de la izquierda no encuentra coincidencia en la tabla de la
derecha, se genera una fila extra (una por cada valor no encontrado) con todos los campos
correspondientes a la tabla derecha seteados a "null". La sintaxis básica es la siguiente:
En el siguiente ejemplo solicitamos el título y el nombre a la editorial, la sentencia es similar a la
anterior, la diferencia está en el orden de las tablas

El resultado mostrará el título del libro y el nombre de la editorial; los títulos cuyo código de editorial
no está presente en "editoriales" aparecen en el resultado, pero con el valor "null" en el campo
"nombre".
Un "left join" puede tener cláusula "where" que restrinja el resultado de la consulta considerando
solamente los registros que encuentran coincidencia en la tabla de la derecha, es decir, cuyo valor
de código está presente en "libros":

También podemos mostrar las editoriales que NO están presentes en "libros", es decir, que NO
encuentran coincidencia en la tabla de la derecha:
La sintaxis corresponde a la de varias SELECT unidas a través de UNION.
Para utilizar la cláusula UNION debemos cumplir una serie de normas:

• Las consultas a unir deben tener el mismo número campos, y además los campos
deben ser del mismo tipo.

• Sólo puede haber una única cláusula ORDER BY al final de la sentencia SELECT.

El siguiente ejemplo muestra el uso de UNION:

Puede observarse el uso de la constante cero en la segunda lista de selección para hacer coincidir
el número y tipo de campos que devuelve la consulta UNION.

3. CRITERIOS PARA OPTIMIZAR ACCESOS A BD

Cada día se necesita procesar mayor cantidad de datos y obtener de manera más rápida y precisa
la información. Muchos de los problemas de rendimiento se deben entre otras cosas al hardware,
al software, al motor de base de datos y por sobre todo al diseño, índices y mala formulación de
consultas SQL.
En este apartado nos centraremos en estos últimos en donde siguiendo algunas recomendaciones
veremos que se puede mejorar el tiempo de respuesta de nuestro motor de BD significativamente.

3.1 A la hora de diseñar la base de datos

• Las tablas normalizadas permiten reducir al mínimo el espacio ocupado por nuestra
base y permiten asegurar la consistencia de la información al mismo tiempo que son
muy rápidas para la realización de transacciones, pero generan un mayor tiempo de
demora a la hora de consultarlas, ya que se deben realizar generalmente la unión de
varias tablas, por lo que en caso de necesidad de altas velocidades de respuesta con
grandes volúmenes de datos, un modelo desnormalizado es más que conveniente
teniendo en cuenta todas las implicancias del caso.
• Ajustar al máximo el tamaño de los campos ayuda a no desperdiciar espacio.
• Eliminar todo campo que no sea de utilidad, ya que por más que no contenga datos
genera retrasos.

3.2 ¿Qué pasa con los índices?

Los índices son campos que permiten la búsqueda a partir de dicho campo a una velocidad
notablemente superior. Sin embargo, cuentan con la desventaja que hace más lenta la actualización,
carga y eliminación de los registros, ya que por cada modificación en la tabla se deberá modificar
también el índice, además se debe tener en cuenta el hecho de que los índices también ocupan
espacio en disco. Es por esto que no es factible indexar todos los campos de la base y se hace
necesario seleccionarlos cuidadosamente. Cabe destacar que por defecto las tablas no contienen
índices por lo que la introducción de estos puede llegar a producir mejoras de más del 100% en
algunos casos. Los campos que se recomiendan indexar son:

• Claves Primarias.
• Claves Foráneas.
• Campos por los cuales se realizarán búsquedas.
• Campos por los cuales se va a ordenar.

Siempre conviene indexar tablas con gran cantidad de registros y que van a ser consultadas
intensamente.

3.3 Donde escribir las sentencias

• Siempre es preferible utilizar consultas almacenadas dentro del motor de base de

datos y no dentro de la aplicación, una consulta almacenada en un procedimiento
 almacenado, por ejemplo, se ejecuta mucho más rápido y directamente sobre el motor
que cualquier consulta externa.
• Muchas de las aplicaciones sobre todo de reporte permiten unir y realizar los joins y
consultas directamente en la herramienta produciendo una baja de performance
realmente considerable. Lo correcto y más eficiente sería generar la consulta en un
procedimiento almacenado con todos los joins y guardar el resultado en una tabla
temporal, de donde posteriormente, el reporte solo deberá mostrar los datos sin
necesidad de trabajarlos primero. Dependiendo los joins que intervengan y los
registros involucrados se puede mejorar drásticamente la performance, han habido
casos en que reportes que duraban 3 minutos en generarse pasaron a 30 segundos,
usando esta técnica.

3.4 Acerca de la formulación de las consultas

A la hora de ejecutar una consulta SQL la forma en que esta es expresada afecta directamente al
motor de BD, pequeños cambios pueden significar la ganancia de muchos segundos o minutos que
el usuario debe esperar al momento de ejecutar la consulta. Algunas recomendaciones son:

• No utilizar SELECT * porque el motor debe leer primero la estructura de la tabla antes
de ejecutar la sentencia.
• Seleccionar solo aquellos campos que se necesiten. Cada campo extra genera tiempo
extra.
• Utilizar Inner Join , left join , right join, para unir las tablas en lugar del where, esto
permite que a medida que se declaran las tablas se vayan uniendo mientras que si
utilizamos el where el motor genera primero el producto cartesiano de todos los
registros de las tablas para luego filtrar las correctas, un trabajo definitivamente lento.
• Especificar el alias de la tabla delante de cada campo definido en el select, esto le
ahorra tiempo al motor de tener que buscar a cuál tabla pertenece el campo
especificado.
• Evitar el uso de Cast y fórmulas dentro de las consultas, cada fórmula y casteo
retrasan el motor considerablemente.

El orden de ubicación de las tablas en el from debería ir en lo preferible de menor a mayor según el
número de registros, de esta manera reducimos la cantidad de revisiones de registros que realiza el
motor al unir las tablas a medida que se agregan.

3.5 Sólo consulte lo que realmente necesite

Filtre tanto como pueda, la cláusula WHERE es la más importante a la hora de la optimización;
NUNCA use “SELECT *;” debe especificar los campos que necesita, esto hará su consulta más
rápida y llevará a ahorrar ancho de banda (recuerde que Ud. está enviando paquetes por una red,
¿por qué habrá de enviar lo que no necesita?).
Sea cuidadoso con el JOIN, las expresiones JOIN son caras en términos de tiempo, asegúrese de
que está usando todas las claves relativas a las tablas que refiere y no aplique JOIN en tablas que
no necesita, siempre trate de unir campos indexados.
El tipo de JOIN usado es muy importante también; familiarícese con los tipos (INNER, OUTER, LEFT,
RIGHT….)
Las consultas son rápidas, generalmente podrá recuperar cantidad de información en menos de un
segundo, incluso usando los joins, ordenando y calculando. Una regla de oro es que si su consulta
toma más de un segundo, deberá optimizarla.
El trabajo comenzará con las consultas más necesarias o más usadas, y luego proceder con las que
más tiempo toman.

3.6 Agregue, remueva o modifique índices

Si las consultas realizan búsquedas de tablas completas, deberá pensar en el uso de índices para
sus tablas, el uso de ellos y de un filtrado adecuado que pueden resolver la mayor parte de las
consultas que toman demasiado tiempo.
Todas las claves primarias precisan de índices para realizar los joins más rápidamente, esto también
significa que todas las tablas precisan de clave primaria. Se pueden agregar índices en campos que
usa seguido para el filtrado con cláusulas de tipo WHERE.
Especialmente usted precisa usar índices en campos de tipo entero, booleano y numérico; en cambio
no le será de mucha ayuda en campos de tipo Blob, VarChar y Long String.
El lado negativo de los índices es que se debe tener mucho cuidado con su uso en tablas que se
actualizan muy seguido, en estos casos el mantenimiento de los índices puede consumir más tiempo
del que realmente ahorran.
Otra herramienta excelente en el mundo de Internet son las tablas de tipo read-only allí los índices
funcionan en su mayor potencial, ya que raramente necesitará realizar mantenimiento.

3.7 Procedimientos almacenados

Los procedimientos almacenados son una alternativa rápida y mejor a las consultas por las
siguientes razones:

• Los procedimientos almacenados son compilados (el código SQL es interpretado)

haciéndolas una opción mucho más rápida.
• El ahorro de ancho de banda es importante, pues se pueden realizar varias consultas
en un mismo procedimiento, además el procedimiento se mantiene en el servidor
hasta que el resultado final es obtenido, y es esto únicamente lo que se envía al
cliente.
• Los procedimientos almacenados corren dentro del servidor, que usualmente es más
rápido.
• Los cálculos en código (VB, Java, C++) no son tan rápidos como en PA en la mayoría
de los casos.
• Mantiene el código de acceso a la BD separado de la capa de presentación, lo que la
hace más fácil de mantener (modelo de 3 capas) y muchísimo más segura ante
ataques como inyección SQL, pues no se tiene acceso directo al código.

Se puede afinar una BD de varias formas, usando estadísticas de optimización, corriendo opciones
de optimización, realizando tablas de sólo lectura, etc. Usualmente este trabajo lo realiza un
administrador de BD. En la mayoría de los sistemas gestores de bases de datos existen
herramientas de optimización. MySQL tiene la herramienta “MySQL query analyzer”, que le
permitirá ejecutar consultas y observar su incidencia, para determinar lo que el SGBD hace con sus
consultas.
4. La optimización en la práctica

Para comprender mejor el concepto de la optimización, veremos a continuación una serie de

ejemplos que se aplican en instrucciones SQL, mostrando en primer lugar el código no optimizado
y luego el código aplicando los criterios de mejora en la instrucción SQL. Si se quiere consultar el
nombre y el salario de los empleados del departamento de ventas:

Ejemplo 1

Consulta original:

Select * from Empleados;

Corregido:

Select Nombre, Salario

From Empleados

Where Dept='Ventas';

En la versión corregida, se filtra la información en la BD lo que resulta más rápido, además sólo se
solicita la información necesaria, lo que enviará sensiblemente menos información y, por lo tanto,
mejorará la performance.

Ejemplo 2

Consulta original:

Select Nombre, Salario

From Empleados

Where Dept='Ventas'

Order By Salario;

¿Realmente necesita la cláusula Order by? A menudo se utiliza esta opción para revisar si los
datos retornados son correctos, remuévala si no la necesita, ahora si es necesaria úsela en la
consulta no en la página.

Ejemplo 3

Original:

For i=1 to 2000 call query : Select Salario From Empleados Where EMpID= Parametro(i)

Corregido:

Select Salario From Empleados Where EmpID >=1 and EmpID <= 2000;

La primera opción involucra gran transmisión de datos lo que hará más lento el sistema completo,
siempre debe realizar el trabajo en la consulta o el procedimiento almacenado, si obliga al sistema
a llevar y traer información pierde valioso tiempo. No importa si se piensa que el proceso es tan
complicado que es mejor manejarlo en el código de su aplicación, pero rara vez lo es.
Ejemplo 4

Se tienen 2 tablas Ordenes y Clientes. Los Clientes pueden tener varias órdenes.

Original:

Select O.Precio, C.Nombre

From Ordenes O, Clientes C;

Corregido:

Select O.Precio, C.Nombre

From Ordenes O INNER JOIN Clientes C ON O.ClienteID=C.ClienteID;

Conclusión

CONTROL DE LECTURA

Lea, analice y responda las siguientes preguntas:

1. Una consulta combinada interna es excluyente.

.
Verdadero.

2. ¿Cuántos tipos de consultas combinadas existen?

.
Tres.

3. El join que se usa para hacer coincidir registros en una tabla (izquierda) con
otra tabla (derecha) es:
Le
ft
joi
n.
1. ¿QUÉ SON LOS PROCEDIMIENTOS ALMACENADOS?

Generalmente son escritos en un lenguaje de bases de datos propietario, es decir,

cada gestor de base de datos posee su propio lenguaje, por lo que es recomendable
revisar el manual del SGBD para conocer la sintaxis a ser utilizada.
Una vez creado un procedimiento almacenado, se puede invocar directamente desde
una aplicación, o sustituir el nombre de una tabla o vista, por el nombre de
procedimiento en cláusulas SELECT.

Ventajas de usar procedimientos almacenados

Ventajas de usar procedimientos almacenados

• Compilación: la primera vez que se invoca un SP, el motor lo compila y a

partir de ahí, se sigue usando la versión compilada del mismo, hasta que
se modifique o se reinicie el servicio de SQL. Esto significa que se tendrá
un mejor rendimiento que las consultas directas que usan cadenas con
las instrucciones T-SQL, que se compilan cada vez que se invocan.
• Automatización: si tenemos un conjunto de instrucciones T-SQL, las
cuales queremos ejecutar de manera ordenada, un SP es la mejor
manera de hacerlo.
• Administración: cuando realizamos aplicaciones con un gran número de
líneas de código, y queremos hacer cambios, solo implica modificar un
SP y no toda la aplicación, lo que significa solo cambiamos los SP en el
servidor y no tenemos que actualizar la aplicación en todos los equipos
cliente.
 • Seguridad: una parte importante es que a los usuarios de nuestra
aplicación, sólo les proporcionamos los permisos para ejecutar los
procedimientos almacenados y no el acceso a todos los objetos de la
base, es decir, si en nuestra aplicación encuentran una vulnerabilidad
como “SQL Injection” no se podrá explotar ejecutando SQL directamente.
• Programabilidad: los SP admiten el uso de variables y estructuras de
control como IF, Bucles, Case, etc., además del manejo de transacción.
Permite controlar excepciones.
• Tráfico de Red: pueden reducir el tráfico de la red, debido a que se
trabaja sobre el motor (en el servidor), y si una operación incluye hacer
un trabajo de lectura primero y con base a eso realizar algunas
operaciones, esos datos que se obtienen no viajan por la red.

2. ELEMENTOS DE LOS PROCEDIMIENTOS ALMACENADOS

Los procedimientos almacenados están compuestos por algunos de estos elementos:

• Parámetros de entrada.

• Parámetros de salida.

• Declaración de variables.

• Cuerpo del procedimiento.

Un procedimiento almacenado también se puede ejecutar mediante la instrucción

EXECUTE PROCEDURE o CALL (según el SGBD que se esté utilizando). Esto lo
veremos a detalle más adelante.

¿Dónde utilizarlos?

Los procedimientos almacenados son muy útiles cuando no se requiere cargar de

tráfico la red.
A continuación, se muestran algunos de los posibles usos que pueden darse a estos
objetos de la base de datos.
Por ejemplo:

• Si deseamos obtener un reporte complejo que incluya instrucciones

condicionales y cálculos complejos con datos obtenidos de varias tablas,
un procedimiento almacenado es nuestro mejor aliado.

• También podemos ejecutar complejos procesos que a veces tardan

horas cuando son ejecutados desde el cliente, ya que en tales casos la
 información debe pasar del servidor al cliente y viceversa. Cuando
utilizamos un procedimiento almacenado, este es ejecutado por el SGBD
que a su vez es ejecutado en la computadora servidor. Casi siempre las
computadoras servidores son poderosas máquinas con mucha memoria,
discos rápidos y uno o más procesadores también muy rápidos. Por lo
tanto, al ejecutar los procesos mediante procedimientos almacenados
estamos aprovechando toda esa capacidad de cómputo disponible en el
hardware del servidor.

Ventajas de los procedimientos almacenados

A continuación, se muestran algunas ventajas que poseen los procedimientos

almacenados:
Principal desventaja
Esclavitud:

• Los procedimientos almacenados nos esclavizan al motor de base de

datos.

• Una base de datos con muchos procedimientos almacenados, es

prácticamente imposible de migrar a otro motor.
Lo anterior se debe, principalmente, a que los lenguajes de procedimientos
almacenados de distintos fabricantes no son compatibles entre sí.

3. CREACIÓN DE PROCEDIMIENTOS ALMACENADOS

Como se mencionó, los procedimientos almacenados si bien son guardados en la

base de datos, estos son de código propietario. Esto significa que si tenemos Oracle
la sintaxis podría diferir de un MS SQL Server, MySQL y otros gestores de base de
datos. Por ello se mostrará a continuación un formato genérico para crear un
procedimiento almacenado, enfatizando que en nuestro caso lo importante será el
concepto y no la sintaxis, pues para ellos deberá referirse a los manuales
correspondientes del SGBD que posea.

En términos generales la sintaxis podría ser:

Donde:

• <procedure_name>: Corresponde al nombre del procedimiento.

• <param1..n>: Nombre del parámetro que será utilizado dentro del

procedimiento.

• <type>: Cualquier tipo de dato válido para la base de datos.

Aclaración de los componentes de los procedimientos

El uso de OR REPLACE permite sobrescribir un procedimiento existente. Si se omite,
y el procedimiento existe, se producirá, un error.
La sintaxis es muy parecida a la de un bloque anónimo, salvo porque se reemplaza la
sección DECLARE por la secuencia PROCEDURE ... IS en la especificación del
procedimiento. En otros casos no es especificada la secuencia “IS”, y se define la
secuencia “DECLARE” dentro del segmento BEGIN – END.
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.

4. IMPLEMENTACIÓN DE LA LÓGICA EN LOS PROCEDIMIENTOS

Segmento de código

La utilización de estas dos instrucciones en conjunto dan lugar al cuerpo del

procedimiento, donde se almacenan la o las diferentes instrucciones que componen
a esta rutina.
Ejemplo:

Nota: el símbolo @ a la izquierda de la variable es equivalente a decir que es una

variable global o pública como es conocida en otros lenguajes.
Creación de variables

Esta sentencia se utiliza para:

• La declaración de variables dentro del procedimiento almacenado, así

como handlers y cursores.

• Esta instrucción puede usarse dentro de las etiquetas begin y end las
cuales engloban el cuerpo de instrucciones del procedimiento, también
es posible asignar un tipo de variable y un valor default.

INSTRUCCIÓN SELECT - INTO

Esta sentencia es especialmente útil, ya que inserta en las variables que se le indican
los resultados del SELECT. Es importante tener en cuenta que no almacena una
estructura bidimensional, sino solamente una o varias variables, es por ello que es
necesario que las consultas tengan un solo registro como el ejemplo siguiente:

La variable x fue creada en la secuencia DECLARE.

SENTENCIA IF

• IF implementa un constructor condicional básico.

• Si condition se evalúa a cierto, el comando SQL correspondiente

sentencias1 se ejecuta.

• Si no coincide ninguna condición se ejecuta el comando listado en la

cláusula ELSE.

• Sentencias2 puede consistir en varios comandos.

Ejemplo:

Este procedimiento recibe un dato por el parámetro parameter1, si el valor es 17

entonces asigna a la variable variable1 el valor “bird” sino será el valor “beasts”,
luego lo agrega en la tabla1.

SENTENCIA CASE
 • El comando CASE para procedimientos almacenados implementa un
constructor condicional complejo.

• Si una condition se evalúa a cierto, el comando SQL correspondiente se

ejecuta.

• Si no coincide ninguna condición de búsqueda, el comando en la

cláusula ELSE se ejecuta.

Ejemplo:

SENTENCIA WHILE
 • Los DBMS soportan varios tipos de bucles y con ellos muchos tipos de
control sobre ellos.

• Los comandos dentro del WHILE se repiten mientras la condición

condition es cierta.

Ejemplo:

OTROS EJEMPLOS:
Instrucción REPEAT
En este caso, la instrucción INSERT se hace por lo menos una vez.

Instrucción LOOP LABEL

En este caso usamos la instrucción LOOP, pero en este caso se le ha asignado un

nombre de etiqueta. Si la condición se cumple, entonces el lazo se interrumpe.

5. EL COMANDO CALL

Los procedimientos almacenados pueden hacer referencia a tablas, vistas, a

funciones definidas por el usuario, a otros procedimientos almacenados. Un
procedimiento almacenado puede incluir cualquier cantidad y tipo de instrucciones
DML (de manipulación de datos, como insert, update, delete), no instrucciones DDL
(de definición de datos, como create..., drop... alter...).

Ejemplo 1
Asumamos que se ha creado un procedimiento llamado p_libros_aumentar, no se
requiere parámetro alguno, por lo que la invocación sería:

• execute pa_libros_aumentar;

• exec pa_libros_aumentar;

• Call pa_libros_aumentar;
Ejemplo 2
En este caso, si el procedimiento llamado p_libros_aumentar, requiere parámetros,
entonces la forma de invocarlos podría ser:

• execute pa_libros_aumentar miVariable;

• exec pa_libros_aumentar(miVariable);

• Call pa_libros_aumentar(miVariable);

Debemos aclarar, que “miVariable” podría ser una constante o una variable provista
por el lenguaje de programación que se esté utilizando.

CONTROL DE LECTURA

Lea, analice y responda las siguientes preguntas:

1. El código utilizado en un procedimiento almacenado, puede ser migrado

transparentemente a cualquier SGBD.
Falso.

2. Cuando realizamos aplicaciones con un gran número de líneas de código, y

queremos hacer cambios, solo implica modificar un procedimiento almacenado,
estamos en presencia de una ventaja de los procedimientos almacenados
llamada:

Administración.

3. La secuencia llamada DECLARE es utilizada para:

Definir
las
variables
que
serán
utilizada
 s en el
procedim
iento.

1. ¿QUÉ SON LOS DISPARADORES?

Si un evento ocurre, el administrador de disparadores dentro del

gestor de bases de datos llama a la función adecuada para
procesar el evento, por lo que cuando ejecutamos un INSERT,
DELETE o UPDATE, es posible que se desencadene la ejecución
de disparadores, cosa que hay que tener muy en cuenta al
desarrollar y evaluar aplicaciones.
En ocasiones es necesario mantener restricciones en la base de
datos que no pueden expresarse directamente con las sentencias
de creación de tablas como CREATE TABLE.

Por ejemplo, en una aplicación bancaria, si un cliente se queda sin

saldo para un pago en una cuenta (es decir, entra en “números
rojos”), se deberá crear automáticamente un crédito personal para
el descubierto. Si en la base de datos teníamos una tabla
CUENTAS con la información de las cuentas bancarias (incluyendo
un atributo saldo), entonces deberíamos “observar” la tabla, y
cuando se ejecutase una sentencia UPDATE sobre la misma,
habría que comprobar si se cumple la condición saldo<0, en cuyo
caso, habría que crear una tupla en la tabla PRESTAMOS. Esta
idea de observar cambios es la que se implementa en el concepto
de disparador (trigger).

2. TIPOS DE TRIGGERS

Para crear un disparador (trigger) en una tabla, el usuario con el

que accedamos al SGBD deberá ser propietario de la misma,
teniendo así el privilegio ALTER para la tabla o ALTER ANY
TABLE. Además, dicho usuario, debe disponer del privilegio
CREATE TRIGGER.

Existen varios tipos de disparadores, dependiendo del tipo de

transacción de disparo y el nivel en el que se ejecuta el disparador
(trigger):

TIPOS DE DISPARADORES

• Disparadores de nivel de fila: se ejecutan una vez para

cada fila afectada por una instrucción DML. Los
disparadores de nivel de fila se crean utilizando la
cláusula for each row en el comando CREATE
TRIGGER.
• Disparadores de nivel de instrucción: se ejecutan una
vez para cada instrucción DML. Por ejemplo, si una
única instrucción INSERT inserta 500 filas en una tabla
un disparador de nivel de instrucción, para dicha tabla
sólo se ejecutará una vez. Los disparadores de nivel de
instrucción son el tipo predeterminado que se crea con
el comando CREATE TRIGGER.
• Disparadores Before y After: puesto que los
disparadores son ejecutados por sucesos, puede
establecerse que se produzcan inmediatamente antes
(before) o después (after) de dichos sucesos.
• Disparadores Instead Of: puede utilizar INSTEAD OF
para indicar al SGBD lo que tiene que hacer en lugar de
realizar las acciones que invoca el disparador. Por
ejemplo, podría usar un disparador INSTEAD OF en
una vista para gestionar las inserciones en una tabla o
para actualizar múltiples tablas que son parte de una
vista.
 • Disparadores de esquema: puede crear disparadores
sobre operaciones en el nivel de esquema tales como
create table, alter table, drop table, audit, rename,
truncate y revoke. Puede incluso, crear disparadores
para impedir que los usuarios eliminen sus propias
tablas. En su mayor parte, los disparadores de nivel de
esquema proporcionan dos capacidades: impedir
operaciones DDL y proporcionar una seguridad
adicional que controle las operaciones DDL cuando
estas se producen.
• Disparadores en nivel de base de datos: puede crear
disparadores que se activen al producirse sucesos de
la base de datos, incluyendo errores, inicios de sesión,
conexiones y desconexiones. Puede utilizar este tipo de
disparador para automatizar el mantenimiento de la
base de datos o las acciones de auditoría.

3. CARACTERÍSTICAS DE LOS TRIGGERS

Los triggers permiten “disparar” (ejecutar) procedimientos

almacenados cada vez que se realice una acción sobre los datos de
una tabla. Esta acción puede consistir en la inserción, modificación
o eliminación de un registro. De esta manera, podemos indicar que
se ejecuten acciones sobre los datos de la tabla o de otras tablas,
cada vez que se modifican, agregan o eliminan datos de una tabla.

EJEMPLOS

3.1 Ventajas de los triggers

Algunos usos de los triggers son:

• Generación automática de valores derivados de una

columna.
• Prevención de transacciones inválidas.
• Proporciona auditorías sofisticadas.
• Mantener la sincronía en tablas replicadas.
• Generación de estadísticas de acceso.
• Publicar información de los eventos generados por la
base de datos, las actividades de los usuarios o de las
estructuras SQL que se han ejecutado.
 • Actualizar totales de la suma de campos de una tabla
en otra.
• El mantenimiento de la aplicación se reduce, los
cambios a triggers se reflejan automáticamente en
todas las aplicaciones que tienen que ver con la tabla
sin necesidad de recompilar.

3.2 Consideraciones sobre triggers

• Los triggers no tienen parámetros de entrada. Los

únicos valores de entrada con los que pueden trabajar
son los del registro que han insertado, modificado o
eliminado.
• Los triggers no devuelven valores como los
procedimientos almacenados. Sólo pueden modificar
otras tablas o los mismos valores del registro agregado
o modificado (obviamente, el eliminado no).
• Hay que tener especial cuidado con los triggers
recursivos, es decir, aquellos que puedan realizar
operaciones que lancen nuevos triggers.

3.3. Tipos y sub tipos

Dependiendo de la acción sobre la cual queremos que actúen, se

pueden crear tres tipos de triggers:

• Al insertar un registro.
• Al modificar un registro.
• Al eliminar un registro.

Cada uno de estos tipos se puede dividir a su vez en dos subtipos:

antes y después de la acción.

• BEFORE
Este tipo de trigger se debe ejecutar cuando:
La acción del trigger debe determinar si le permite
finalizar a la sentencia de disparo.
Si se deben verificar valores específicos de columnas
antes de completar una sentencia de disparo INSERT o
UPDATE.
• AFTER
Se debe emplear este tipo de trigger cuando:
Se quiere completar la sentencia de disparo antes de
ejecutar la acción del trigger.
Si ya existe un trigger BEFORE un AFTER puede
 realizar diferentes acciones con la misma sentencia de
disparo.

En consecuencia, podemos disponer de hasta seis tipos distintos de

triggers:

• BEFORE INSERT. Antes de insertar un registro.

• AFTER INSERT. Después de insertar un registro.
• BEFORE UPDATE. Antes de modificar un registro.
• AFTER UPDATE. Después de modificar un registro.
• BEFORE DELETE. Antes de eliminar un registro.
• AFTER DELETE. Después de eliminar un registro.

4. CREACIÓN DE TRIGGERS

Trigger a tablas Un trigger es un bloque de código que se

almacena en la base de datos. Los bloques de código de los
triggers están asociados a una tabla y se ejecutan automáticamente
cuando se producen ciertos eventos asociados a la tabla.
Se suelen utilizar para prevenir transacciones erróneas y nos sirven
también para implementar restricciones de integridad o seguridad.
Su formato básico es el siguiente:

Elementos de un trigger
 • before / after: elemento que dispara el trigger

• nombre_trigger: nombre del trigger que tiene que ser

único.

• for each: nivel del disparo del trigger que por defecto
es statement que significa que se dispara una sola vez
por cada operación independientemente del número de
filas afectadas.

• for each row: salta por cada fila afectada.

Variables posibles para update:

• :old que hace referencia a los valores anteriores.

• :new que hace referencia a los nuevos valores de

actualización de la fila.

Debemos de tener en cuenta algunos aspectos:

Vamos a crear un trigger que se dispare automáticamente después

de la modificación del salario de la tabla empleado y pase un
comentario a la tabla auditar.
Orden de ejecución de los trigger

Una misma tabla puede tener varios triggers y el orden de disparo

sería el siguiente:

1. Antes de comenzar a ejecutar la orden que provoca el

disparo se ejecutarán los triggers del tipo before.... for
each statement

2. Para cada fila afectada por la orden:

a. Se ejecutan los triggers del tipo before for

each row.

b. Se ejecuta la actualización de la fila.

c. Se ejecutan los triggers after... for each

row.

3. Una vez realizada la operación se ejecuta el after for

each statement.

Cuando se dispara un trigger este forma parte de la operación que

lo disparó de manera que si el trigger falla, Oracle dará por fallida la
operación completa. Aunque el fallo sea a nivel de fila se hará
rollback a toda la operación.
Ejemplo:
Disparadores de sustitución

Podemos crear triggers que no se ejecutan antes ni después de una

instrucción sino en lugar de (instead of).
Solo podemos utilizar estos triggers si están asociados a vistas,
además actúan siempre a nivel de fila.
La sintaxis de este tipo de trigger es la siguiente:

Sobre una vista podemos hacer un select pero si hacemos un

insert, delete o update puede darnos problemas y no dejar
ejecutarse la orden correctamente.
Los trigger sobre vistas van a sustituir a estas operaciones por las
correspondientes en las tablas que forman la vista.
Un ejemplo de trigger de sustitución sería el siguiente:

Disparadores de sistema

Estos triggers se disparan cuando se arranca o para la base de

datos, entra o sale un usuario, cuando se crea, modifica o elimina
un objeto, etc. En Oracle para crear este tipo de trigger debemos de
tener privilegios de Administer database trigger.
La sintaxis de este trigger sería la siguiente:

Donde la lista de eventos de definición puede tener uno o más

eventos DDL separados por or y la lista de eventos del sistema
igualmente separados por or.
Al asociar un disparador a un evento debemos indicar el momento
en que se dispare.
Oracle tiene algunas funciones que permiten acceder a los atributos
del evento del disparo ORA_YSEVENT, ORA_LOGIN, etc. Estas
funciones pueden usarse en la cláusula WHEN o en el cuerpo del
disparador. En el manual de Oracle podéis encontrar el listado de
todas estas funciones.
Un ejemplo sería un trigger que nos guarda los datos de un usuario
al hacer login en la base de datos:

5. USO DE LOS TRIGGERS

Auditoría de las bases de datos

Consiste en el control de acceso, de actualización, de integridad y

calidad de los datos.
En esto encontramos utilidad en los TRIGGERS.

CONTROL DE LECTURA

Lea, analice y responda las siguientes preguntas:

1. Antes de crear y utilizar triggers de base de datos, debe efectuarse un análisis
del impacto negativo que podría ocurrir.
Verdadero.

2. ¿En cuáles eventos pude utilizarse el parámetro: OLD?

Update y Delete.

3. ¿Cuál de los siguientes tipos de triggers es el más

frecuentemente utilizado?
Trig
ger
de
tabl
a.

1. Existen 2 tipos de funciones básicas utilizadas en los SGBD. Las

que obtienen un resultado a partir de un conjunto de elementos se llama:
b) Funciones de agregación.

2. Las funciones de agregación pueden ser usadas en las cláusulas SELECT,

WHERE y ORDER BY.
b) Falso.

3. La función que permite cambiar de una cadena original un carácter específico

por otro carácter específico en el SGBD Oracle es:
c) Replace.

4. De las siguientes funciones, ¿cuál corresponde a una agregación primitiva?

b) Sum.

5. Las funciones almacenadas en las bases de datos siempre devuelven un

valor
a) Verdadero.
6. Es obligatorio colocar el argumento “REPLACE” en una función de base de
datos.
b) Falso.

7. Dentro de una función almacenada, aparece el argumento “RETURNS”, el

cual es utilizado para:
b) Indicar el tipo de valor a devolver como respuesta.

8. ¿En cuál de las siguientes cláusulas no puede colocarse una sub consulta?
c) Order by.

9. Cuando se utiliza la cláusula UNION en dos queries A y B, las columnas que

posee la instrucción SELECT, deben ser:
b) El mismo número de columnas y mismo tipos de datos.

10. ¿En cuál tipo de JOIN pueden colocarse las tablas separadas por una
coma?
a) En un INNER JOIN.

11. El join que se usa para hacer coincidir registros en una tabla (derecha) con
otra tabla (izquierda) es:
b) Right join.

12. Existen varias ventajas en el uso de procedimientos almacenados, ¿cuál de

ellas indica que si tenemos un conjunto de instrucciones T-SQL, las cuales
queremos ejecutar de manera ordenada, el procedimiento almacenado lo hace
mejor?
c) Automatización.

13. Un procedimiento almacenado siempre devuelve un valor.

b) Falso.

14. Cuando se utilizan parámetros en un procedimiento almacenado, ¿cuál de los

parámetros debe utilizarse para indicar que un valor puede ser modificado en el
proceso?
c) INOUT.

15. Existen algunas variables en los disparadores de bases de datos que son
utilizados para el manejo de los valores con los que deberá trabajar los eventos.
¿En cuál de las instrucciones que se muestra a continuación, se utiliza la variable
:OLD?
b) DELETE, UPDATE.