Módulo 4.

SQL avanzado y NoSQL

En el módulo 4 veremos conceptos avanzados de SQL, como son los

procedimientos almacenados, funciones, SQL dinámico y múltiples ejemplos
relacionados. Aprenderemos cómo crear un disparador y qué son los cursores para
terminar el tema SQL con el manejo de errores. Por último, aprenderemos qué es
una base de datos NoSQL, los tipos existentes y algunos ejemplos con MongoDB.
A modo de cierre, presentaremos una comparativa entre bases SQL y NoSQL.

Mejorando nuestro proyecto

Unidad 4.1. SQL avanzado

Unidad 4.2. Bases NoSQL

Video de habilidades

¡Vamos a practicar!

Cierre
Referencias
Lección 1 de 7

Mejorando nuestro proyecto

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

C O NT I NU A R
Lección 2 de 7

Unidad 4.1. SQL avanzado

Video de inmersión

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

4.1.1 Procedimiento almacenado y función

La tendencia es que las bases de datos asuman un papel cada vez más
importante en la arquitectura general del procesamiento de datos. Así es
que el DBMS asumió más responsabilidad, lo cual le proporcionó un control
más centralizado y redujo la posibilidad de corrupción de datos originados a
partir de errores de programación de las aplicaciones. Tres características
han sido parte de esta tendencia: procedimientos almacenados, funciones y
disparadores.

Los procedimientos almacenados pueden realizar tanto el procesamiento de

datos como la lógica de aplicación dentro de la misma base de datos. Por
ejemplo, un procedimiento almacenado podría implementar la lógica para
aceptar una orden del cliente o para transferir dinero de una cuenta bancaria
a otra.

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

Las funciones son programas SQL almacenados que devuelven un solo

valor para cada fila de datos. A diferencia de los procedimientos
almacenados, las funciones se invocan haciendo referencia a ellas en
sentencias SQL en casi cualquier cláusula en la que se pueda utilizar un
nombre de columna. Esto los hace ideales para realizar cálculos y
transformaciones de datos en los datos que se muestran en los resultados
de la consulta o utilizados en las condiciones de búsqueda. Casi todos los
productos DBMS relacionales vienen con un conjunto de funciones
suministradas por el proveedor para uso general y, por lo tanto, las
funciones añadidas por los usuarios de la base de datos local a menudo se
denominan “funciones definidas por el usuario”.

Los disparadores se utilizan para invocar automáticamente la capacidad de

procesamiento de un procedimiento almacenado en función de las
condiciones que surgen dentro de la base de datos. Por ejemplo, un
disparador puede transferir fondos automáticamente de una cuenta de
ahorros a una cuenta corriente si la cuenta corriente se convierte en
sobregiro.

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms
Con procedimientos almacenados, el lenguaje SQL se amplía en varias
capacidades normalmente asociadas con lenguajes de programación. Las
secuencias de sentencias SQL se agrupan para formar programas o
procedimientos SQL. Tanto para los procedimientos como para las
funciones, se utiliza una extensión de SQL denominada PL/SQL.

Se proporcionan las siguientes capacidades:

Ejecución condicional: una estructura IF... THEN ... ELSE

permite un uso de un procedimiento SQL para probar una
condición y llevar a cabo diferentes operaciones dependiendo del
resultado.

Bucle: un ciclo WHILE o FOR o una estructura similar permiten

realizar una secuencia de operaciones SQL repetidamente hasta
que se cumpla alguna condición de terminación. Algunas
implementaciones proporcionan una estructura de bucle especial
con base en cursor para procesar cada fila de resultados de
consulta.

Estructura de bloques: una secuencia de sentencias SQL puede

agruparse en un solo bloque y utilizarse en otras construcciones
de flujo de control como si el bloque de instrucciones fuera una
sola sentencia.
 Variables nombradas: un procedimiento SQL puede almacenar
un valor que ha calculado, recuperado de la base de datos o
derivado de alguna otra forma en una variable de programa, y
recuperar posteriormente el valor almacenado para su uso en
cálculos subsiguientes.

Procedimientos con nombre: una secuencia de sentencias SQL

puede agruparse, asignar un nombre y asignar parámetros
formales de entrada y salida, como una subrutina o una función en
un lenguaje de programación convencional. Una vez definido de
esta manera, el procedimiento puede ser llamado por nombre y
pasar los valores apropiados para sus parámetros de entrada. Si
el procedimiento es una función que devuelve un valor, puede
utilizarse en expresiones de valor de SQL

Colectivamente, las estructuras que implementan estas capacidades forman

un lenguaje procedimental almacenado (SPL).

Hacé clic en este botón para realizar ahora los ejercicios 4.1 y 4.2

¡A PRACTICAR!

Ejemplo de procedimiento almacenado

Considere el proceso de agregar un cliente a la base de datos. Los pasos

que pueden estar involucrados son los siguientes:
 1 Obtenga el número de cliente, nombre, límite de crédito y cantidad
de ventas objetivo para el cliente, así como el vendedor y la oficina
asignados.

2 Agregue una fila a la tabla de cliente que contiene los datos del
cliente.

3 Actualice la fila del vendedor asignado, aumentando el objetivo de

cuota en la cantidad especificada.

4 Actualice la fila de la oficina, aumentando la meta de ventas en la

cantidad especificada.

5 Confirme los cambios en la base de datos, si todas las

declaraciones anteriores tuvieron éxito.

Hacé clic en este botón para realizar ahora los ejercicios 4.3, 4.4 y 4.5

¡A PRACTICAR!

Sin una capacidad de procedimiento almacenado, aquí hay una secuencia

de instrucciones SQL que hace este trabajo para XYZ Corporation, el nuevo
número de cliente 2137, con un límite de crédito de $30.000 y ventas de
$50.000 para asignar a Paul Cruz (empleado nro. 103) de la oficina de
Chicago:
INSERT INTO CUSTOMERS (CUST_NUM, COMPANY, CUST_REP,
CREDIT_LIMIT) VALUES (2137, 'XYZ Corporation', 103, 30000.00);

UPDATE SALESREPS SET QUOTA = QUOTA + 50000.00 WHERE

EMPL_NUM = 103; UPDATE OFFICES SET TARGET = TARGET +
50000.00 WHERE CITY = 'Chicago'; COMMIT;

Con un procedimiento almacenado, todo este trabajo se puede integrar en

una única rutina SQL definida.

Tabla 1. Procedimiento almacenado básico en PL/SQL

Procedimiento almacenado básico en PL/SQL

Create Procedure Add_Cust Cabecera y Nombre

(c_Name In Varchar2, c_Num In

Integer, Cred_Lim In Number,
Tgt_Sls In Number, c_Rep In
Parámetros
Integer, c_Offc In Varchar2,
c_quota Out Integer,
c_target Out Varchar2 )

As

new_cuota number(16,2); Variables

new_target number(16,2);
 Procedimiento almacenado básico en PL/SQL

Begin

Insert Into Customers

(Cust_Num, Company, Cust_Rep,
Credit_Limit)
Values
(c_Num, c_Name, c_Rep,
Cred_Lim); New_quota := Quota * Cuerpo
0.25;
Update Salesreps
Set Quota = New_quota +
Tgt_Sls
Where Empl_Num = c_Rep;

Select Quota Into c_quota From

Salesreps
Where Empl_Num = c_Rep;
New_target := Target * 0.75;
Update Offices
Set Target = New_Target +
Tgt_Sls
Where City = c_Offc;

Select Target Into c_Target From

Offices
Where City = c_Offc;

Commit;
 Procedimiento almacenado básico en PL/SQL

End; Fin

Fuente: elaboración propia.

Creación de un procedimiento almacenado

Nombre del procedimiento

La instrucción CREATE PROCEDURE le asigna un nombre al

procedimiento recién definido, que se utiliza luego para invocarlo.

Parámetros

Acepta cero o más parámetros como argumentos.

Se debe especificar el nombre de los parámetros y sus tipos de

datos, soportados por el DBMS.

Pueden ser los siguientes:

Entrada [IN];

Salida [OUT];
 Entrada-salida [IN-OUT].

Cuando se llama al procedimiento, se asignan a los parámetros los valores

especificados en la llamada de procedimiento, y las instrucciones en el
cuerpo del procedimiento comienzan a ejecutarse.

Los nombres de los parámetros pueden aparecer dentro del cuerpo del
procedimiento, dondequiera que pueda aparecer una constante. Cuando
aparece un nombre de parámetro, el DBMS utiliza su valor actual.

Además de los parámetros de entrada, algunos lenguajes SPL también

admiten parámetros de salida. Esto permite que un procedimiento
almacenado devuelva valores que calcula durante su ejecución. Los
parámetros de salida proporcionan una capacidad importante para pasar
información de un procedimiento almacenado a otro procedimiento
almacenado que lo llama, y también puede ser útil para depurar
procedimientos almacenados utilizando SQL interactivo.

Algunos lenguajes SPL admiten parámetros que funcionan como

parámetros de entrada y salida. En este caso, el parámetro pasa un valor al
procedimiento almacenado y cualquier cambio en el valor durante la
ejecución del procedimiento se refleja en el procedimiento de llamada.

Variables
Se declaran al principio del cuerpo del procedimiento, justo después del
encabezado del procedimiento y antes de la lista de sentencias SQL. Los
tipos de datos de las variables pueden ser cualquiera de los tipos de datos
SQL soportados como tipos de datos de columna por el DBMS.

Las variables locales dentro de un procedimiento almacenado pueden

utilizarse como fuente de datos dentro de las expresiones SQL en cualquier
lugar en que pueda aparecer una constante. El valor actual de la variable se
utiliza en la ejecución de la sentencia. Además, las variables locales pueden
ser destinos para datos derivados de expresiones o consultas SQL.

Llamando a un procedimiento almacenado

Una vez definido por la instrucción CREATE PROCEDURE, el

procedimiento se puede utilizar. Un programa de aplicación puede solicitar
la ejecución del procedimiento almacenado si utiliza la instrucción SQL
adecuada. Otro procedimiento almacenado puede llamar para realizar una
función específica. El procedimiento almacenado también se puede invocar
a través de una interfaz interactiva de SQL.

Tabla 2. Llamando y eliminando un procedimiento almacenado en

PL/SQL

Llamando a un procedimiento almacenado en PL/SQL

 Llamando a un procedimiento almacenado en PL/SQL

Llama al procedimiento almacenado y le pasa los seis valores

especificados como sus parámetros. El DBMS ejecuta el procedimiento
almacenado y lleva a cabo cada sentencia SQL en la definición del
procedimiento una por una. Si el procedimiento ADD_CUST completa
su ejecución con éxito, se ha llevado a cabo una transacción confirmada
dentro del DBMS. Si no, el código de error devuelto y el mensaje indican
qué fue lo que falló.

Los valores que se deben utilizar

EXECUTE ADD_CUST
para los parámetros del
('XYZ Corporation', 2137,
procedimiento se especifican, por
30000.00, 50000.00,
orden, en una lista que está
103,'Chicago');
encerrada entre paréntesis.

Cuando se llama desde dentro de

ADD_CUST ('XYZ
otro procedimiento o un
Corporation', 2137, 30000.00,
disparador, se puede omitir la
50000.00, 103,'Chicago');
instrucción EXECUTE.

EXECUTE ADD_CUST (c_name El procedimiento también se

= 'XYZ puede llamar mediante los
Corporation', c_num = 2137, parámetros nombrados, en cuyo
cred_lim = 30000.00, c_offc = caso los valores de parámetro se
'Chicago', c_rep = 103, tgt_sales pueden especificar en cualquier
= 50000.00); secuencia.

Eliminando un procedimiento almacenado en PL/SQL

 Llamando a un procedimiento almacenado en PL/SQL

DROP PROCEDURE
ADD_CUST;

Fuente: elaboración propia.

Funciones

Además de los procedimientos almacenados, la mayoría de los lenguajes

SPL soporta funciones almacenadas. La diferencia es que una función
devuelve una sola cosa (como un valor de datos, un objeto o un documento
XML) cada vez que se invoca, mientras que un procedimiento almacenado
puede devolver muchas cosas o nada. El soporte para los valores devueltos
varía según el lenguaje SPL. Las funciones se utilizan comúnmente como
expresiones de columna en sentencias SELECT y, por lo tanto, se invocan
una vez por fila en el conjunto de resultados, lo cual permite que la función
realice cálculos, conversión de datos y otros procesos para producir el valor
devuelto para la columna. A continuación, se muestra un ejemplo sencillo de
una función almacenada.

Tabla 3. Una función PL/SQL de Oracle

Una función PL/SQL de Oracle

 Una función PL/SQL de Oracle

SELECT COMPANY, NAME FROM CUSTOMERS, SALESREPS

WHERE CUST_REP = EMPL_NUM

AND GET_TOT_ORDS(CUST_NUM) > 10000.00;

/* Return total order amount for a customer */ create function

get_tot_ords(c_num in number) return number

as

/* Declare one local variable to hold the total */ tot_ord number(16,2);

begin

/* Simple single-row query to get total */ select sum(amount) into tot_ord

from orders

where cust = c_num;

/* return the retrieved value as fcn value */ return tot_ord;

end;
Fuente: elaboración propia.

Suponga que desea definir un procedimiento almacenado y que, dado un

número de cliente, calcula la cantidad total de pedido actual para ese
cliente. Si define el procedimiento SQL como una función, la cantidad total
se puede devolver como su valor. La Tabla 3 muestra una función de Oracle
que calcula la cantidad total de pedidos actuales para un cliente, dado el
número de cliente. La cláusula RETURN en la definición del procedimiento
le indica al DBMS el tipo de datos del valor que se devuelve. En la mayoría
de los productos DBMS, si introduce una llamada de función a través de la
capacidad interactiva de SQL, el valor de la función se muestra en
respuesta. Dentro de un procedimiento almacenado, puede llamar a una
función almacenada y utilizar su valor devuelto en los cálculos o
almacenarla en una variable. Muchos lenguajes SPL también le permiten
utilizar una función como una función definida por el usuario dentro de
expresiones de valor de SQL.

A medida que el DBMS evalúa la condición de búsqueda para cada fila de

resultados de la consulta, utiliza el número de cliente de la fila candidata
actual (CUST_NUM) como un argumento a la función GET_TOT_ ORDS y
comprueba si supera el umbral de $10 000. Esta misma consulta podría
expresarse como una consulta agrupada, con la tabla ORDERS también
incluida en la cláusula FROM y los resultados agrupados por el cliente y el
vendedor. En muchas implementaciones, el DBMS lleva a cabo la consulta
agrupada más eficientemente que la precedente, lo que probablemente
obliga al DBMS a procesar la tabla de pedidos una vez para cada cliente.
4.1.2 SQL dinámico

El concepto central de SQL dinámico es simple: no codifique una sentencia

SQL incrustada en el código fuente del programa. En su lugar, deje que el
programa construya el texto de una instrucción SQL en una de sus áreas de
datos en tiempo de ejecución. A continuación, el programa pasa el texto de
la sentencia al DBMS para su ejecución sobre la marcha. Aunque los
detalles se vuelven bastante complejos, todo el SQL dinámico se basa en
este concepto simple, y es una buena idea tenerlo en cuenta.

En SQL dinámico la situación es muy diferente. La instrucción SQL que se

ejecutará no se conoce hasta el tiempo de ejecución, por lo que el DBMS no
puede prepararse para la declaración de antemano. Cuando el programa se
ejecuta realmente, el DBMS recibe el texto de la sentencia para ser
ejecutado dinámicamente (esto es conocido como “la cadena de
instrucción”). Como es de esperar, el SQL dinámico es menos eficiente que
el SQL estático. Sin embargo, el SQL dinámico ha crecido en importancia.

Ejecución dinámica de instrucciones (EXECUTE IMMEDIATE)

La forma más simple de SQL dinámico es proporcionada por la instrucción

EXECUTE IMMEDIATE. Esta sentencia pasa el texto de una instrucción
SQL dinámica al DBMS y le pide al DBMS que ejecute la instrucción
dinámica de inmediato. Para usar esta instrucción, el programa pasa por los
siguientes pasos:
EXECUTE IMMEDIATE cadena de texto

1 El programa construye una sentencia SQL como una cadena de

texto en una de sus áreas de datos y la almacena en la memoria
como una variable con nombre. La sentencia puede ser casi
cualquier sentencia SQL que no recupera datos.

2 El programa pasa la instrucción SQL al DBMS con la instrucción

EXECUTE IMMEDIATE.

3 El DBMS ejecuta la sentencia y establece los valores SQLCODE /

SQLSTATE para indicar el estado de finalización, exactamente
como si la sentencia hubiera sido codificada mediante SQL
estático.

La instrucción EXECUTE IMMEDIATE es la forma más simple de SQL

dinámico, pero es muy versátil. Puede utilizarla para ejecutar
dinámicamente la mayoría de las sentencias DML, incluidas INSERT,
DELETE, UPDATE, COMMIT y ROLLBACK. También puede utilizar
EXECUTE IMMEDIATE para ejecutar dinámicamente la mayoría de las
sentencias DDL, incluidas las instrucciones CREATE, DROP, GRANT y
REVOKE.

Sin embargo, la instrucción EXECUTE IMMEDIATE tiene una limitación

significativa: no puede utilizarla para ejecutar dinámicamente una sentencia
SELECT, ya que no proporciona un mecanismo para procesar los resultados
de la consulta. Así como SQL estático requiere cursores y declaraciones de
propósito especial (DECLARE CURSOR, OPEN, FETCH y CLOSE) para
consultas programáticas, SQL dinámico utiliza cursores y algunas nuevas
instrucciones de propósito especial para manejar consultas dinámicas.

Es importante advertir que la entrada del usuario no debe colocarse

directamente en sentencias SQL (como se muestra en los ejemplos
simplificados anteriores) sin analizarlas primero. Hacerlo le permitiría a un
hacker incluir caracteres en la entrada, que terminaría la sentencia SQL
deseada y añadiría otra al final de ella, lo cual permitiría el acceso no
autorizado a otros datos en la base de datos, una técnica conocida como
“inyección de SQL”.

4.1.3 Disparadores (triggers)

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms
Cursores

Una necesidad común para la repetición de sentencias dentro de un

procedimiento almacenado surge cuando el procedimiento ejecuta una
consulta y necesita procesar los resultados de la consulta, fila por fila. Todos
los lenguajes principales proporcionan una estructura para este tipo de
procesamiento. Conceptualmente, las estructuras son paralelas a las
instrucciones DECLARE CURSOR, OPEN CURSOR, FETCH y CLOSE
CURSOR en SQL incorporado o en las llamadas de la API SQL
correspondientes. Sin embargo, en lugar de buscar los resultados de la
consulta en el programa de aplicación, en este caso se están obteniendo en
el procedimiento almacenado, que se ejecuta dentro del propio DBMS. En
lugar de recuperar los resultados de la consulta en variables de programa
de aplicación (variables de host), el procedimiento almacenado los recupera
en variables de procedimiento almacenadas locales. Para ilustrar esta
capacidad, asuma que desea rellenar dos tablas con datos de la tabla
ORDERS. Una tabla, llamada BIGORDERS, debe contener el nombre del
cliente y el tamaño del pedido para cualquier pedido de más de $10.000. El
otro, SMALLORDERS, debe contener el nombre del vendedor y el tamaño
de la orden para cualquier orden inferior a $1.000. La mejor y más eficiente
manera de hacerlo sería utilizar dos sentencias SQL INSERT
independientes con subconsultas, pero con fines de ilustración. Considere el
siguiente método en su lugar:
 1 Ejecute una consulta para recuperar el importe de la orden, el
nombre del cliente y el nombre del vendedor para cada pedido.

2 Para cada fila de resultados de la consulta, compruebe el monto

de la orden para corroborar que caiga en el rango adecuado para
incluir en las tablas BIGORDERS o SMALLORDERS.

3 Dependiendo de la cantidad, debe INSERTAR la fila apropiada en

la tabla BIGORDERS o SMALLORDERS.

4 Repita los pasos 2 y 3 hasta que se agoten todas las filas de los
resultados de la consulta.

5 Confirme las actualizaciones a la base de datos.

Tabla 4. Un bucle FOR basado en el cursor PL/SQL

Un bucle FOR basado en el cursor PL/SQL

create procedure sort_orders()

/* Cursor for the query */ cursor o_cursor is

select amount, company, name from orders, customers, salesreps where

cust = cust_num

and rep = empl_num;

 Un bucle FOR basado en el cursor PL/SQL

/* Row variable to receive query results values */ curs_row

o_cursor%rowtype;

begin

/* Loop through each row of query results */ for curs_row in o_cursor

loop

/* Check for small orders and handle */ if (curs_row.amount < 1000.00)

then insert into smallorders

values (curs_row.name, curs_row.amount);

/* Check for big orders and handle */ elsif (curs_row.amount > 10000.00)
then insert into bigorders

values (curs_row.company, curs_row.amount); end if;

end loop; commit; end;

Fuente: elaboración propia.

La tabla 4 muestra un procedimiento almacenado de Oracle que realiza este
método. El cursor que define la consulta se define temprano en el
procedimiento y se le asigna el nombre O_CURSOR. La variable
CURS_ROW se define como un tipo de fila de Oracle. Es una variable de
fila estructurada de Oracle con componentes individuales (como una
estructura en lenguaje C). Al declarar que tiene el mismo tipo de fila que el
cursor, los componentes individuales de CURS_ROW tienen los mismos
tipos de datos y nombres que las columnas de resultados de la consulta del
cursor.

La consulta descrita por el cursor se realiza, en realidad, mediante el bucle

FOR con base en el cursor. Básicamente, le dice al DBMS que realice la
consulta descrita por el cursor (equivalente a la instrucción OPEN en SQL
incorporado) antes de iniciar el procesamiento de bucle. El DBMS,
entonces, ejecuta el bucle FOR repetidamente, busca una fila de resultados
de consulta en la parte superior del bucle, coloca los valores de columna en
la variable CURS_ROW y luego ejecuta las instrucciones en el cuerpo del
bucle. Cuando no se busquen más filas de resultados de consulta, el cursor
se cierra y el procesamiento continúa después del bucle.

Disparadores

A diferencia de los procedimientos almacenados, un disparador no se activa

mediante una instrucción CALL o EXECUTE, sino que se asocia con una
tabla de base de datos. Cuando los datos de la tabla cambian por una
instrucción INSERT, DELETE o UPDATE, se lanza el disparador, lo que
significa que el DBMS ejecuta las instrucciones SQL que forman el cuerpo
del disparador. Algunas marcas de DBMS permiten la definición de
actualizaciones específicas que provocan un disparo, y algunas de estas
marcas, especialmente Oracle, permiten que los disparadores tengan base
en eventos del sistema, como los usuarios que se conectan a la base de
datos o la ejecución de un comando de apagado de la base de datos.

Los disparadores se pueden utilizar para provocar actualizaciones

automáticas de la información dentro de una base de datos. Por ejemplo,
supongamos que desea configurar la base de datos para que cada vez que
se inserte un nuevo vendedor en la tabla SALESREPS, el objetivo de ventas
de la oficina donde trabaja el vendedor se actualice por la cuota del nuevo
vendedor. A continuación le presentamos un disparador de Oracle PL/SQL
que logra este objetivo:

CREATE OR REPLACE Disparador upd_tgt before insert on salesreps

for each row begin

if :[Link] is not null then

update offices

set target = target + [Link]; END IF;

END;
El cuerpo de este disparador le dice al DBMS que, para cada nueva fila
insertada en la tabla, debería ejecutar la instrucción UPDATE especificada
para la tabla OFFICES. El valor QUOTA de la fila SALESREPS recién
insertada se denomina [Link] dentro del cuerpo del disparador.

¿Las funciones y los procedimientos almacenados difieren solo en la

cantidad de parámetros?

Verdadero.

Falso.

SUBMIT

Before update

create Disparador bef_upd_ord before update on orders

begin

/* Calculate order total before changes */ old_total = add_orders();

end;

create Disparador aft_upd_ord after update on orders

begin

/* Calculate order total after changes */ new_total = add_orders();

end;

create Disparador dur_upd_ord before update of amount on orders

referencing old as pre new as post

/* Capture order increases and decreases */ for each row

when (:[Link] != :[Link]) begin

if [Link] != :[Link]) then

if (:[Link] < :[Link]) then

/* Write decrease data into table */ insert into ord_less

values (:[Link],

:pre.order_date,
:[Link],

:[Link]);

elsif (:[Link] > :[Link]) then

/* Write increase data into table */ insert into ord_more

values (:[Link],

:pre.order_date,

:[Link],

:[Link]); end if;

end if; end;

Hacé clic en este botón para realizar ahora el ejercicio 4.6

¡A PRACTICAR!

4.1.4 Manejo de errores

Cuando escribe una instrucción SQL interactiva que causa un error, el

programa de SQL interactivo mostrará un mensaje de error, anulará la
instrucción y le pedirá que escriba una nueva instrucción.

Tipos de errores

Errores en tiempo de compilación: las comillas mal colocadas, las

palabras clave de SQL mal escritas y los errores similares en
sentencias de SQL embebido son detectados por el precompilador
de SQL e informados al programador.

Errores en tiempo de ejecución: el intento de insertar un valor de

datos no válido o la falta de permisos para actualizar una tabla
solo se puede detectar en tiempo de ejecución. Estos errores
deben ser detectados y manejados por el programa de aplicación.
En los programas de SQL embebido, el DBMS informa al
programa de aplicación de errores de ejecución a través de un
código de error devuelto. Si se detecta un error, están disponibles
una descripción más detallada del error y otra información sobre la
sentencia que acaba de ejecutarse a través de información de
diagnóstico adicional.

Tratamiento de errores con SQLCODE

A medida que el DBMS ejecuta cada sentencia de SQL embebido,

establece el valor de la variable SQLCODE en el SQLCA (área de
comunicaciones de SQL) para indicar el estado de la sentencia:
 Un SQLCODE de cero indica la finalización satisfactoria de la
sentencia, sin errores ni advertencias.

Un valor SQLCODE negativo indica un error grave que impidió que

la instrucción se ejecutará correctamente. Por ejemplo, un intento
de actualizar una vista de solo lectura produciría un valor
SQLCODE negativo.

Un valor SQLCODE positivo indica una condición de advertencia.

Por ejemplo, el truncamiento o redondeo de un elemento de datos
recuperado por el programa produciría una advertencia.

La advertencia más común, con un valor de +100 en la mayoría de las

implementaciones y en el estándar SQL, es el aviso de ausencia de datos,
que es devuelto cuando un programa intenta recuperar la siguiente fila de
resultados de consulta y no quedan más filas para recuperar. Debido a que
cada sentencia SQL embebido puede, potencialmente, generar un error, un
programa bien escrito comprobará el valor de SQLCODE después de cada
sentencia de SQL embebido ejecutable.

C O NT I NU A R
Lección 3 de 7

Unidad 4.2. Bases NoSQL

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms

Son muchas las aplicaciones web que utilizan algún tipo de bases de datos
para funcionar.

Hasta ahora estábamos acostumbrados a utilizar bases de

datos SQL, pero desde hace ya algún tiempo han aparecido
 otras que reciben el nombre de NoSQL (Not only SQL – No sólo
SQL) y que han llegado con la intención de hacer frente a las
bases relacionales utilizadas por la mayoría de los usuarios.

Se puede decir que la aparición del término NoSQL aparece

con la llegada de la web 2.0 ya que hasta ese momento sólo
subían contenido a la red aquellas empresas que tenían un
portal, pero con la llegada de aplicaciones como Facebook,
Twitter o Youtube, cualquier usuario podía subir contenido,
provocando así un crecimiento exponencial de los datos
(Acens, 2014, [Link]

Es en este momento cuando empiezan a aparecer los primeros problemas

de la gestión de toda esa información almacenada en bases de datos
relacionales. En un principio, para solucionar estos problemas de
accesibilidad, las empresas optaban por utilizar un mayor número de
máquinas, pero pronto se dieron cuenta de que esto no solucionaba el
problema, además de que resultaba ser una solución muy cara.

La otra solución era la creación de sistemas pensados para un

uso específico que con el paso del tiempo han dado lugar a
soluciones robustas, apareciendo así el movimiento NoSQL.
 Por lo tanto, hablar de bases de datos NoSQL es hablar de
estructuras que nos permiten almacenar información en
aquellas situaciones en las que las bases de datos relacionales
generan ciertos problemas debido principalmente a problemas
de escalabilidad y rendimiento de las bases de datos
relacionales donde se dan cita miles de usuarios concurrentes y
con millones de consultas diarias. Además de lo comentado
anteriormente, las bases de datos NoSQL son sistemas de
almacenamiento de información que no cumplen con el
esquema entidad–relación. Tampoco utilizan una estructura de
datos en forma de tabla donde se van almacenando los datos
sino que para el almacenamiento hacen uso de otros formatos
como clave–valor, mapeo de columnas o grafos (ver epígrafe
‘Tipos de bases de datos NoSQL’) (Acens, 2014,
[Link]

4.2.1 Tipos de bases NoSQL

Dependiendo de la forma en la que almacenen la información, podemos

encontrar varios tipos distintos de bases de datos NoSQL. Veamos los tipos
más utilizados.

Bases de datos clave–valor

 Son el modelo de base de datos NoSQL más popular, además
de ser el más sencillo en cuanto a funcionalidad. En este tipo
de sistema, cada elemento está identificado por una llave única,
lo que permite la recuperación de la información de forma muy
rápida, información que habitualmente está almacenada como
un objeto binario (BLOB). Se caracterizan por ser muy
eficientes tanto para las lecturas como para las escrituras. Este
concepto es el mismo que vimos en el módulo 1 de Tablas
Hash. Algunos ejemplos de este tipo de bases son Cassandra,
BigTable o HBase (Acens, 2014, [Link]

Bases de datos documentales

Verify to continue
We detected a high number of errors from your
connection. To continue, please confirm that
you’re a human (and not a spambot).

I'm not a robot

reCAPTCHA
Privacy - Terms
 Se almacena la información como un documento, generalmente
utilizando para ello una estructura simple como JSON o XML y
donde se utiliza una clave única para cada registro. Este tipo de
implementación permite, además de realizar búsquedas por
clave–valor, realizar consultas más avanzadas sobre el
contenido del documento. Son las bases de datos NoSQL más
versátiles. Se pueden utilizar en gran cantidad de proyectos,
incluyendo muchos que tradicionalmente funcionarían sobre
bases de datos relacionales. Algunos ejemplos de este tipo son
MongoDB o CouchDB (Acens, 2014, [Link]

En el siguiente tema veremos algunos ejemplos con MongoDB, pero para

adelantarnos podemos ver en la siguiente figura (figura 1) cómo es que se
almacena la información en este tipo de bases.

Figura 1. Bases de datos documentales

Fuente: Acens, 2014, [Link]

Bases de datos en grafo

En este tipo de bases de datos, la información se representa

como nodos de un grafo y sus relaciones con las aristas del
mismo, de manera que se puede hacer uso de la teoría de
grafos para recorrerla. Para sacar el máximo rendimiento a este
tipo de bases de datos, su estructura debe estar totalmente
normalizada, de forma que cada tabla tenga una sola columna y
cada relación dos. Este tipo de bases de datos ofrece una
navegación más eficiente entre relaciones que en un modelo
relacional (Acens, 2014, [Link]

Algunos ejemplos de este tipo son Neo4j, InfoGrid o Virtuoso. Veamos un

ejemplo gráfico de cómo sería este tipo de bases en la figura 2.

Figura 2. Bases de datos en grafo

 Fuente: Acens, 2014, [Link]

Bases de datos orientadas a objetos

En este tipo, la información se representa mediante objetos, de la misma

forma que son representados en los lenguajes de programación orientada a
objetos (POO), como ocurre en JAVA, C# o Visual Basic .NET. Algunos
ejemplos de este tipo de bases de datos son Zope, Gemstone o Db4o.

4.2.2. Creación y consultas en BD NoSQL

En el siguiente tema veremos algunos ejemplos de interacción con una BD

No SQL. Todos estos ejemplos corresponden a los casos en los que se usa
el motor mongoDB.
 En MongoDB no existe ningún comando estilo create
database o algo parecido. Lo que hace mongodb es crear una
colección (base de datos) en el momento que se le inserta un
objeto o documento (registro de una tabla, por llamarlo de
alguna forma) a dicha colección.

Para crear una base de datos en MongoDB hay que usar, con
la sentencia use, una base de datos o colección que todavía no
existe.

use peliculas;

Ahora vamos a insertar una película en la colección y en ese

momento se creará la misma

[Link]({titulo:'Batman el caballero oscuro'});

Ahora hemos creado un registro y la base de datos a la vez,

aunque en mongo realmente lo que creamos son colecciones y
guardamos documentos json.

Podemos hacer una consulta para ver que hay dentro de la

colección:
 [Link]();

Podemos ver el resto de base de datos creadas con el

comando

show dbs;

(Robles, V. 2016, [Link]

4.2.3 Comparativas SQL vs NoSQL

S Q L (RE L ACI O NAL E S ) NO S L Q

Ventajas

Está más adaptado su uso y los perfiles que las conocen son
mayoritarios y más baratos.

Debido al largo tiempo que llevan en el mercado, estas herramientas

tienen un mayor soporte y mejores suites de productos y add-ons para
gestionar estas bases de datos.

Hay atomicidad en las operaciones en la base de datos. Esto quiere

decir que en estas bases de datos o se hace la operación entera o no
se hace utilizando la famosa técnica del rollback.

Los datos deben cumplir requisitos de integridad tanto en tipo de dato

como en compatibilidad.
Desventajas

La atomicidad de las operaciones juega un papel crucial en el

rendimiento de las bases de datos.

Tiene una escalabilidad, que aunque probada en muchos entornos

productivos, suele, por norma, ser inferior a las bases de datos NoSQL.

S Q L (RE L ACI O NAL E S ) NO S L Q

Ventajas

Su escalabilidad y su carácter descentralizado son una de sus ventajas.

Soportan estructuras distribuidas.

Suelen ser bases de datos mucho más abiertas y flexibles. Permiten

adaptarse a necesidades de proyectos mucho más fácilmente que los
modelos de Entidad Relación.

Se puede hacer cambios de los esquemas sin tener que parar bases de
datos.

Tienen escalabilidad horizontal: son capaces de crecer en número de

máquinas, en lugar de tener que residir en grandes máquinas.

Se pueden ejecutar en máquinas con pocos recursos.

Permiten una optimización de consultas en base de datos para grandes

cantidades de datos.

Desventajas
 No todas las bases de datos NoSQL contemplan la atomicidad de las
instrucciones y la integridad de los datos. Soportan lo que se llama
“consistencia eventual”.

Existen problemas de compatibilidad entre instrucciones SQL. Las

nuevas bases de datos utilizan sus propias características en el
lenguaje de consulta y no son 100% compatibles con el SQL de las
bases de datos relacionales. El soporte a problemas con las queries de
trabajo en una base de datos NoSQL es más complicado.

Falta de estandarización. Hay muchas bases de datos NoSQL y aún no

hay un estándar como sí lo hay en las bases de datos relacionales. Se
presume un futuro incierto en estas bases de datos.

Soporte multiplataforma. Aún quedan muchas mejoras en algunos

sistemas para que soporten sistemas operativos que no sean Linux.

Suelen tener herramientas de administración no muy usables o se

accede por consola.

Fuente: elaboración propia en base a Pandorafms, 2015

NoSQL vs SQL: cuándo utilizar qué tipo de base de datos

Cuando los datos deben ser consistentes sin dar posibilidad al

error de utilizar una base de datos relacional, SQL.

Cuando nuestro presupuesto no se puede permitir grandes

máquinas y debe destinarse a máquinas de menor rendimiento,
 NoSQL.

Cuando las estructuras de datos que manejamos son variables,

NoSQL.

Análisis de grandes cantidades de datos en modo lectura, NoSQL.

Captura y procesado de eventos, NoSQL.

Tiendas online con motores de inteligencia complejos, NoSQL.

¿Cuáles de las siguientes son tipos de bases de datos NoSQL?

Clave-valor.

Documentales.

Dibujadas.

Grafo.

Pictóricas.
 SUBMIT

C O NT I NU A R
Lección 4 de 7

Video de habilidades

En el video podemos ampliar y conocer más sobre las diferentes

características que poseen las bases SQL y las NoSQL. Rendimiento,
capacidad, seguridad y disponibilidad. Tener claridad sobre estas diferencias
es muy importante ya que nos permitirá elegir en qué situaciones utilizar
cada tipo de base.

Video 1. ¿Qué es sql y nosql?

que es sql y nosql? cuales son sus diferencias y cuando de…

Fuente: HolaMundo (s.f.). que es sql y nosql? cuales son sus diferencias y cuando deberías utilizarlos. [Video

de YouTube]. Recuperado de [Link]

1. Dos de las siguientes son características de las bases NoSQL:

Flexibilidad (no hay esquema).

Atomicidad.

Escalabilidad.

Inseguridad.

SUBMIT

2. Dos de las siguientes son características de las bases SQL:

Confiabilidad.
 Velocidad.

Escalabilidad.

Integridad/consistencia.

SUBMIT

3. Las bases de datos documentales son un tipo de bases relacional (SQL).

Verdadero.

Falso.

SUBMIT
4. Las bases de datos NoSQL, a diferencia de las ……. no poseen una
estructura definida.

Documentales.

Relacionales.

SiSQL.

Grafo.

SUBMIT

5. Las bases de datos NoSQL son más eficientes en las ……. de grandes
cantidades de datos, respecto de las relacionales.

Escrituras.
Eliminación.

Actualización.

Lecturas.

SUBMIT

C O NT I NU A R
Lección 5 de 7

¡Vamos a practicar!

Para realizar los ejercicios, recordá leer el Manual de uso de PostgreSQL:

Manual [Link]
311.8 KB

Al final de este apartado, encontrarás un archivo descargable con las

respuestas de cada ejercicio. Estas respuestas te van a servir como guía
para que revises si realizaste correctamente los ejercicios.

Introducción
Si utilizás pgAdmin, todas las tablas, datos, funciones, procedimientos
almacenados y triggers, serán guardados en tu computadora. De esta
forma, podrás acceder a ellos, indiferentemente si cerrás el programa o
reiniciás tu sistema.
Si no puedes usar pgAdmin, utilizá la herramienta online. En este
caso, deberás guardar las consultas que vayas realizando. Esto sucede
porque al cerrar el navegador se perderán todos los datos y se deberán
copiar, pegar y ejecutar las consultas que ya habías ejecutado. De tal
manera, podrás avanzar en los próximos ejercicios sin necesidad de volver
a escribirlas una a una nuevamente.

Situación
En el recorrido de todos los ejercicios vas a tener que crear y trabajar sobre
un sistema para una universidad.

Desde la universidad Puls-ar te solicitan llevar el registro de los alumnos y

las materias que ellos cursan. Cuando los alumnos se inscriben se les pide
su DNI, nombre, apellido e e-mail.

Dados de alta en la universidad, ellos ya están en condiciones de anotarse a

las materias disponibles, teniendo en cuenta que las materias tienen un
nombre y un año de cursado.

Requerimientos
Utilización de la plataforma de PostgreSQL.

Enunciados
Ejercicio 4.1
Creá la función cantidad_inscriptos. Al momento de pasar el identificador de
materia, retornará la cantidad de inscriptos en ella (el valor de retorno debe
ser del tipo de datos bigint, ya que en algún momento es posible tener
muchos alumnos inscriptos a una materia).

Ejercicio 4.2
Probá la función anterior para encontrar la cantidad de alumnos inscriptos a
la materia 1 (escribí la consulta realiza).

Tabla 1. Cantidad/inscriptos

Fuente: elaboración propia

Ejercicio 4.3
Creá una tabla que se llame alumnos_logs. Ídem para alumnos, pero
agregando un campo que se llame fecha para registrar un tipo de datos de
fecha y hora. Esta tabla, a su vez, no debe tener un identificador único. La
utilidad de esta tabla será definida más adelante para poder registrar los
cambios realizados sobre los alumnos.

Ejercicio 4.4
Creá un procedimiento almacenado, que luego deberá utilizarse para llamar
desde un trigger. La idea de este procedimiento almacenado es registrar
las modificaciones ocurridas sobre la tabla alumnos cuando sus registros
se actualicen. Deberás guardar estas modificaciones dentro de tu nueva
tabla alumnos_logs. El procedimiento almacenado debe llamarse
alumnos_update_trigger_fnc().

Ejercicio 4.5
Creá el trigger que monitoree tu tabla alumnos. En caso de actualización
de algún registro, deberás llamar al procedimiento almacenado anterior para
ir agregando los registros en la tabla alumnos_logs.

Ejercicio 4.6
Modificá la tabla de alumnos de forma tal que se completen mediante el
trigger (automáticamente) los registros en la tabla alumnos_logs, para
obtener el esquema que se muestra a continuación.

Recordá que la columna fecha tendrá otros valores, porque se registrará la

fecha y hora del momento en que ejecuten las actualizaciones.
Tabla 2. Datos

Fuente: elaboración propia

Ejemplo de resolución - [Link]

30.7 KB

C O NT I NU A R
Lección 6 de 7

Cierre

Para finalizar este módulo, repasemos los conceptos más importantes.

Procedimiento almacenado y función

–
Los procedimientos almacenados pueden realizar tanto el procesamiento
de datos cómo lógica de aplicación dentro de la propia base de datos. Por
ejemplo, un procedimiento almacenado podría implementar la lógica para
aceptar una orden de cliente o para transferir dinero de una cuenta
bancaria a otra.

SQL dinámico
–
El concepto central de SQL dinámico es simple: no codifique una sentencia
SQL incrustada en el código fuente del programa. En su lugar, deje que el
programa construya el texto de una instrucción SQL en una de sus áreas
de datos en tiempo de ejecución. A continuación, el programa pasa el texto
de la sentencia al DBMS para su ejecución sobre la marcha. Aunque los
detalles se vuelven bastante complejos, todo el SQL dinámico se basa en
este concepto simple, y es una buena idea tenerlo en cuenta.
En SQL dinámico la situación es muy diferente. La instrucción SQL que se
ejecutará no se conoce hasta el tiempo de ejecución, por lo que el DBMS
no puede prepararse para la declaración de antemano. Cuando el
programa se ejecuta realmente, el DBMS recibe el texto de la sentencia
para ser ejecutado dinámicamente (llamado la cadena de instrucción) y
pasa por los cinco pasos en tiempo de ejecución. Como es de esperar, el
SQL dinámico es menos eficiente que el SQL estático. Sin embargo, el
SQL dinámico ha crecido en importancia.

Manejo de errores
–
Cuando escribe una instrucción SQL interactiva que causa un error, el
programa de SQL interactivo mostrará un mensaje de error, anulará la
instrucción y le pedirá que escriba una nueva instrucción.

Dos tipos de errores pueden surgir:

1. Errores en tiempo de compilación

2. Errores en tiempo de ejecución

Tipos de bases NoSQL

–

Bases de datos clave–valor: son el modelo de base de datos NoSQL

más popular, además de ser la más sencilla en cuanto a funcionalidad.
En este tipo de sistema, cada elemento está identificado por una llave
única, lo que permite la recuperación de la información de forma muy
rápida, información que habitualmente está almacenada como un
objeto binario (BLOB).

Bases de datos documentales: se almacena la información como un

documento, generalmente utilizando para ello una estructura simple
como JSON o XML y donde se utiliza una clave única para cada
registro.

Bases de datos en grafo: en este tipo de bases de datos, la

información se representa como nodos de un grafo y sus relaciones
con las aristas del mismo, de manera que se puede hacer uso de la
teoría de grafos para recorrerla. Para sacar el máximo rendimiento a
este tipo de bases de datos, su estructura debe estar totalmente
normalizada, de forma que cada tabla tenga una sola columna y cada
relación dos. Este tipo de bases de datos ofrece una navegación más
eficiente entre relaciones que en un modelo relacional.

Bases de datos orientadas a objetos: en este tipo, la información se

representa mediante objetos, de la misma forma que son
representados en los lenguajes de programación orientada a objetos
(POO) como ocurre en JAVA, C# o Visual Basic .NET. Algunos
ejemplos de este tipo de bases de datos son Zope, Gemstone o Db4o.

C O NT I NU A R
Lección 7 de 7

Referencias

Acens White Papers. (2014). Bases de datos NoSQL. Qué son y tipos
que nos podemos encontrar. Recuperado de [Link]
content/images/2014/02/[Link]

Pandorafms. (2015). NoSQL vs SQL; principales diferencias y cuándo

elegir cada una de ellas. Recuperado de
[Link]
cada-una/

Robles, V. (2016). Crear una base de datos en MongoDB. Recuperado de

[Link]

C O NT I NU A R