3 El lenguaje SQL

Structured Query Language

Lenguaje Estructurado de Consulta
 Introducción
• El SQL es el lenguaje estándar ANSI/ISO
de definición, manipulación y control de
bases de datos relacionales.
• Lenguaje declarativo: Indicar que se
quiere hacer
• Parecido al lenguaje natural
• Se puede acceder a todos los sistemas
relacionales comerciales
 Introducción
• Principios de los 70 Proyecto System R de
IBM para implementar un prototipo de
SGBDR
• Mediados de los 70: SEQUEL (Structured
English Query Language), más adelante
SQL (Structured Query Language)
• Finales de los 70: uso generalizado de
SQL
• 1982: Comité X3H2 de ANSI (American
National Standards Institute) estudia el
SQL
 Introducción
• 1986: El Comité X3H2 adopta el SQL como
estándar
• 1987: SQL estándar de ISO
• 1989: Revisión y ampliación de SQL dando
como resultado el SQL1 o SQL89
• 1992: Revisión y ampliación de SQL89 dando
como resultado el SQL2 o SQL92 con 3 niveles:
– El nivel introductorio (entry), que incluye el SQL89 y
las definiciones de llave primaria y llave foránea al
crear una tabla.
– El nivel intermedio (intermediate), que, además del
SQL89, añade algunas ampliaciones del SQL92
– El nivel completo (full), que ya tiene todas las
ampliaciones del SQL92
 Introducción
• Al trabajar SQL cambia la terminología
– RELACION = TABLA
– ATRIBUTOS = COLUMNA
– TUPLA = FILA o REGISTRO

• Las operaciones de SQL reciben el nombre de

sentencias formadas por cláusulas
 Introducción
• Para utilizar SQL desde un lenguaje de
programación (PHP, Java, C, etc.)
necesitaremos sentencias especiales que
nos permitan distinguir entre las
instrucciones del lenguaje de
programación (anfitrión) y las sentencias
de SQL (huésped)
 Introducción
• El SQL no refleja toda la teoría
del modelo relacional
establecida por Edgar Frank
Codd
• Ya existe SQL:1999 o SQL3
que tiene a SQL2 e incorpora
nuevas prestaciones (véase:
http://www.unalmed.edu.co/~
mstabare/sql3.htm)
 Objetivos
• Conocer el lenguaje estándar ANSI/ISO SQL92
• Definir una base de datos relacional, incluyendo
dominios, aserciones y vistas
• Saber introducir, borrar y modificar datos
• Ser capaz de plantear cualquier tipo de consulta
a la base de datos
• Saber utilizar sentencias de control
• Conocer los principios básicos de la utilización
del SQL desde un lenguaje de programación.
Antes de empezar, una BD ejemplo
• Para los siguientes ítems, tomaremos como ejemplo el
siguiente problema:
Olimpíadas (Adaptado de la GUÍA DE EJERCICIOS: Modelo Entidad/Relación y conversión a
Modelo Relacional de los Profesores: Claudio Gutiérrez, Gonzalo Navarro)
Las sedes olímpicas se dividen en complejos deportivos. Los complejos deportivos se subdividen en
aquellos en los que se desarrolla un único deporte y en los polideportivos. Los complejos
polideportivos tienen áreas designadas para cada deporte con un indicador de localización
(ejemplo: centro, esquina-NE, etc.). Un complejo tiene una localización, un jefe de organización
individual y un área total ocupada. Los dos tipos de complejos (deporte único y polideportivo)
tendrán diferentes tipos de información. Para cada tipo de sede, se conservará el número de
complejos junto con su presupuesto aproximado.
Cada complejo celebra una serie de eventos (ejemplo: la pista del estadio puede celebrar muchas
carreras distintas.). Para cada evento está prevista una fecha, duración medido en días, número
de participantes, número de comisarios. Una lista de todos los comisarios se conservará junto
con la lista de los eventos en los que esté involucrado cada comisario ya sea cumpliendo la
tarea de juez u observador.
Igualmente, a cada complejo debe hacérsele mantenimientos de los que interesa saber la fecha y
una descripción del mantenimiento.
Tanto para cada evento como para el mantenimiento se necesitará cierto equipamiento (ejemplo:
arcos, pértigas, barras paralelas, etc).
Antes de empezar, una BD ejemplo
• Una posible solución al problema descrito:
Antes de empezar, una BD ejemplo
• La solución propuesta se implementará en el
Motor de Base de Datos PostgreSQL, por ello la
sintaxis del SQL estándar puede variar un poco
 1 Sentencias de definición
• Sentencias para:
– Crear (CREATE DATABASE) y borrar (DROP
DATABASE) una BD
– Crear (CREATE TABLE), borrar (DROP
TABLE) y modificar (ALTER TABLE) las
tablas que componen la BD
– Definir dominios (CREATE DOMAIN),
restricciones (CONSTRAINT, CHECK,
ASSERTION) y vistas (CREATE VIEW tabla
virtual derivada de tablas reales)
 1.1. Creación y borrado de una BDR
• CREATE SCHEMA {[nombre_esquema]} |
[AUTHORIZATION usuario]}
[lista_de_elementos_del_esquema];
• Comercialmente CREATE DATABASE

• Se puede agrupar un conjunto de elementos

(tablas, dominios, vistas, privilegios,
restricciones, etc) de la BD propiedad de un
usuario
 1.1. Creación y borrado de una BDR

• DROP SCHEMA nombre_esquema

{RESTRICT|CASCADE};
• Comercialmente DROP DATABASE
 1.2. Creación de tablas
• CREATE TABLE nombre_tabla
(nombre_columna {tipo_datos|dominio}
[val_defecto] [restric_col]
[, nombre_columna {tipo_datos|dominio}
[val_defecto] [restric_col]...]
[, restricciones_tabla]
);
 1.2.1. Tipos de datos
• CHARACTER (longitud) Cadenas de caracteres de longitud fija.
• CHARACTER VARYING (longitud) Cadenas de caracteres de longitud
variable.
• BIT (longitud) Cadenas de bits de longitud fija.
• BIT VARYING (longitud) Cadenas de bits de longitud variables.
• NUMERIC (precisión, escala) Número decimales con tantos dígitos como
indique la precisión y tantos decimales como indique la escala.
• DECIMAL (precisión, escala) Número decimales con tantos dígitos como
indique la precisión y tantos decimales como indique la escala.
• INTEGER Números enteros.
• SMALLINT Números enteros pequeños.
• REAL Números con coma flotante con precisión predefinida.
• FLOAT (precisión) Números con coma flotante con la precisión especificada.
• DOUBLE PRECISION Números con coma flotante con más precisión
predefinida que la del tipo REAL.
• DATE Fechas. Están compuestas de: YEAR año, MONTH mes, DAY día.
• TIME Horas. Están compuestas de HOUR hora, MINUT minutos, SECOND
segundos.
• TIMESTAMP Fechas y horas. Están compuestas de YEAR año, MONTH
mes, DAY día, HOUR hora, MINUT minutos, SECOND segundos.
 1.2.2. Creación, modificación y
borrado de dominios
• CREATE DOMAIN nombre_dominio [AS]
tipos_datos [def_defecto]
[restricciones_dominio];
• Donde restricciones_dominio:
[CONSTRAINT nombre_restricción] CHECK
(condiciones)

• También: DROP DOMAIN y ALTER DOMAIN

 1.2.3. Definiciones por defecto
• DEFAULT (literal|función|NULL)
• Al definirlo NULL la columna debe permitir
nulos
• Funciones: USER, SESSION_USER,
SYSTEM_USER, CURRENT_DATE,
CURRENT_TIME,
CURRENT_TIMESTAMP
1.2.4. Restricciones de columna
• NOT NULL
• UNIQUE
• PRIMARY KEY
• REFERENCES tabla ([columna])
• CHECK (condiciones)
 1.2.5. Restricciones de tabla
• UNIQUE (columna, [columna]),
• FOREIGN KEY(columna [, columna. . .])
REFERENCES tabla[(columna2 [,
columna2. . .])]
• CHECK(condiciones)
 1.2.6 Modificación y borrado de llaves
primarias con llaves foráneas que hacen
referencia a éstas
• Políticas de borrado y modificación: Restricción (NO ACTION),
Actualización en cascada (CASCADE), Anulación (SET NULL)
• CREATE TABLE nombre_tabla
( definición_columna
[, definición_columna. . .]
[, restricciones_tabla] );
• Donde las restricciones de tabla son:
FOREIGN KEY llave_foranea REFERENCES tabla
[(llave_primaria)]
[ON DELETE {NO ACTION | CASCADE | SET DEFAULT | SET
NULL}]
[ON UPDATE {NO ACTION | CASCADE | SET DEFAULT | SET
NULL}]
 1.2.7. Aserciones
• Restricción general que hace referencia a
una o más columnas de más de una tabla
• Para crear:
CREATE ASSERTION
nombre_aserción CHECK (condiciones);
• Para borrar:
DROP ASSERTION nombre_aserción
 1.2.7. Aserciones
• Ej.: Ningún complejo deportivo de la sede Paipa
debe tener presupuesto > $30’

• Pero en PostgreSQL aún no está implementado

1.3. Modificación y borrado de tablas

• ALTER TABLE nombre_tabla

{acción_modificar_columna|
acción_modif_restricción_tabla};
• acción_modificar_columna
{ADD [COLUMN] columna def_columna |
ALTER [COLUMN] columna {SET
def_defecto|DROP DEFAULT}{TYPE
nuevo_tipo}| DROP [COLUMN ] columna
{RESTRICT|CASCADE}}
1.3. Modificación y borrado de tablas
• acción_modif_restricción_tabla
{ADD restricción| DROP CONSTRAINT restricción
{RESTRICT|CASCADE}}
• Modificar una tabla significa:
– Añadirle una columna (ADD COLUMN).
– Modificar las definiciones de la columna (ALTER
COLUMN).
– Borrar la columna (DROP COLUMN).
– Añadir alguna nueva restricción de tabla (ADD
CONSTRAINT).
– Borrar alguna restricción de tabla (DROP
CONSTRAINT).
1.3. Modificación y borrado de tablas
• Añadir una columna (ADD COLUMN)
– Ej.: Se desea mantener la especialidad de los
comisarios, es decir, el deporte en el cual son
especialistas. Tendríamos que agregar el campo
especialidad en la tabla comisario:
1.3. Modificación y borrado de tablas
• Modificar las definiciones de la columna
(ALTER COLUMN)
– Ej.: Se necesita que la especialidad del
comisario sea un campo obligatorio, entonces
una vez ingresados los datos de las
especialidades de los comisarios se ejecuta:
1.3. Modificación y borrado de tablas
• Borrar la columna (DROP COLUMN)
– Ej.: Ya no se hace necesario mantener la
información de la especialidad del comisario,
se ejecuta:
1.3. Modificación y borrado de tablas
• Añadir alguna nueva restricción de tabla
(ADD CONSTRAINT)
– Ej.: Ahora se requiere que algunos comisarios
supervisen a otros, para ello se necesita
hacer una relación RECURSIVA así:
1.3. Modificación y borrado de tablas
– Esta relación RECURSIVA requiere que
agreguemos un nuevo atributo a la tabla
comisario, donde se almacene el identificador
del comisario quien supervisa, esto ya lo
sabemos hacer con ADD COLUMN, así:
1.3. Modificación y borrado de tablas
– Y ahora si, agregamos la restricción (ADD
CONSTRAINT) con el nombre c_supervisor_fkey
para que éste nuevo atributo (id_supervisor) haga
referencia (REFERENCES) al id del comisario
supervisor. Éste tipo de restricción es FK que
se asegura que no ingresemos el id de un
comisario que no existe, así:
1.3. Modificación y borrado de tablas
• Borrar restricción (DROP CONSTRAINT)
– Ej.: Si quisiéramos eliminar la restricción
creada anteriormente, ingresamos:
1.3. Modificación y borrado de tablas

• Eliminar una tabla de la BD:

DROP TABLE nombre_tabla
{RESTRICT|CASCADE};
• Si la tabla a borrar esta relacionada con
otra y utilizamos el modificador
CASCADE, el cual elimina la tabla a
borrar sin importar sus relaciones.
1.3. Modificación y borrado de tablas
– Ej.: Si se intenta borrar la tabla SEDE no se
puede ya que ésta esta relacionada con la
tabla COMPLEJO_DEPORTIVO
1.3. Modificación y borrado de tablas
– ¡Cuidado! Recuerde la Integridad
Referencial. Si esta seguro que quiere eliminar
definitivamente la tabla SEDE, ejecute:
1.4. Creación y borrado de vistas
 1.4. Creación y borrado de vistas
• La arquitectura ANSI/SPARC distingue tres
niveles, que se describen en el esquema
conceptual, el esquema interno y los esquemas
externos
• Al crear tablas se describe el esquema
conceptual
• Al crear vistas se describen los esquemas
externos
 1.4. Creación y borrado de vistas
• CREATE VIEW nombre_vista
[(lista_columnas)] AS (consulta) [WITH
CHECK OPTION];
– Ej.: Si existe un proceso de usuario que
constantemente este consultado las áreas deportivas
y los eventos que se desarrollan en ellas, podría
generarse una vista para ello, así:
–
1.4. Creación y borrado de vistas
–
 2. Sentencias de manipulación
• Creada la base de datos con sus tablas,
debemos poder insertar, modificar y borrar los
registros de las tablas.
• Esto se hace con las siguientes sentencias:
– INSERT para insertar
– UPDATE para modificar
– DELETE para borrar
– SELECT para consultar
 2.1. Inserción de registros en una
tabla
• Antes de poder consultar los datos de una base
de datos, es preciso introducirlos
• Esto se hace con la sentencia INSER INTO
VALUES:
• Ej.: Insertar datos a la tabla SEDE:
 2.1. Inserción de registros en una
tabla
• O de estas dos formas, anteponiendo el nombre
de los atributos de la tabla a la cláusula
VALUES (tenga en cuenta el orden de los
valores):
•
 2.1. Inserción de registros en una
tabla
• Habiendo ya insertado valores en las tablas,
tenemos que poder consultarlos.
• Esto se hace con la sentencia SELECT FROM,
como ya se ha visto
• Por ejemplo, para ver los registros de la tabla
sede cuyo atributo nro_complejos = 0, sería:
 2.2. Borrado de registros de una
tabla
• Para borrar algunos registros de una tabla
podemos utilizar la sentencia DELETE FROM
WHERE
• Por ejemplo, para borrar la sede cuyo nombre
es Boyacá, sería:
 2.2. Borrado de registros de una
tabla
• Para borrar todos los registros de una tabla
podemos utilizar la sentencia DELETE FROM
sin la cláusula WHERE
• Por ejemplo para borrar todos los registros de la
tabla sede, sería así:
 2.3. Modificación de registros de
una tabla
• Para modificar los valores de algunos registros
de una tabla, tendríamos que utilizar la
sentencia UPDATE SET WHERE.
• Ej.: Actualizar el número de complejos de la
sede IDRD a 2.
 2.4. Consultas a una BDR
• 2.4.1. Funciones de agregación: Para efectuar
operaciones sobre los datos.
FUNCIÓN DESCRIPCIÓN
COUNT Devuelve el número total de
registros seleccionados
SUM Suma los valores de un
campo o atributo
MIN Devuelve el valor mínimo de
un campo o atributo
MAX Devuelve el valor máximo de
un campo o atributo
AVG Devuelve el valor promedio
de un campo o atributo
EJEMPLO
SELECT COUNT(*)
FROM complejo_deportivo
WHERE SEDE_idSEDE = 1
SELECT SUM(duracion)
FROM evento
WHERE
AREA_DEPORTIVA_idAREA_DEPORTIVA = 10
SELECT MIN(duracion)
FROM evento
SELECT MAX(duracion)
FROM evento
SELECT AVG(duracion)
FROM evento
 2.4. Consultas a una BDR
• 2.4.2. Subconsultas: Una subconsulta es una
consulta incluida dentro de una cláusula
WHERE o HAVING de otra consulta
• Véase 9. Functions and Operators – 9.22.
Subquery Expressions de la documentación en
línea de PostgreSQL
• Ej.: Determinar el nombre del evento de menor
duración: SELECT nombre, duracion
FROM evento
WHERE duracion = (
SELECT MIN(duracion)
FROM EVENTO)
 2.4. Consultas a una BDR
• Antes:

• Después:
 2.4. Consultas a una BDR
• 2.4.3. Otros predicados
– BETWEEN: Para expresar una condición que quiere
encontrar un valor entre dos límites concretos, p.e.
entre dos fechas
– IN / NOT IN: Para comprobar si un valor coincide o no
con los elementos de una lista, la lista puede ser fija o
el resultado de una subconsulta (véase numeral
2.4.2)
– LIKE: Para buscar en una columna de tipo caracter
datos que cumplan con un patrón determinado, p.e.
que empiecen por ‘A’ o tengan cierta cantidad de
caracteres.
 2.4. Consultas a una BDR
• 2.4.3. Otros predicados
– IS NULL / IS NOT NULL: Para comprobar si un valor
es nulo o no.
– ANY / SOME / ALL: Para ver si una columna cumple
que todos sus registros (ALL) o algunos de sus
registros (ANY/SOME) satisfagan una condición
– EXIST / NOT EXIST: Para comprobar si una
subconsulta produce algún registro de resultados o
no.

Repasemos y veamos ejemplos de cada uno:

 2.4. Consultas a una BDR
– BETWEEN: Para expresar una condición que quiere
encontrar un valor entre dos límites concretos, p.e.
entre dos fechas
– Ej. Eventos con duración entre 10 y 20 días
 2.4. Consultas a una BDR
– IN / NOT IN: Para comprobar si un valor coincide o no
con los elementos de una lista, la lista puede ser fija o
el resultado de una subconsulta (véase numeral
2.4.2)
– Ej.: Sedes cuyos nombres estén en lista conformada
por Hunza y San Antonio
 2.4. Consultas a una BDR
– LIKE: Para buscar en una columna de tipo caracter
datos que cumplan con un patrón determinado, p.e.
que empiecen por ‘A’ o tengan cierta cantidad de
caracteres.
– Ej.: Eventos que empiecen por la letra ‘C’ sin importar
la extensión del nombre (%)
 2.4. Consultas a una BDR
– IS NULL / IS NOT NULL: Para comprobar si un valor
es nulo o no.
– Ej.: Equipamiento que no ha sido asignado a ningún
evento
 2.4. Consultas a una BDR
– ANY / SOME / ALL: Para ver si una columna cumple
que todos sus registros (ALL) o algunos de sus
registros (ANY/SOME) satisfagan una condición
– Ej.: Determinar si hay eventos cuya fecha de
realización coincida con la fecha de realización de
algún mantenimiento
 2.4. Consultas a una BDR
– EXIST / NOT EXIST: Para comprobar si una
subconsulta produce algún registro de resultados o
no.
– Ej.: buscan los nombres de los comisarios que están
asignados a algún evento
 2.4. Consultas a una BDR
• 2.4.4. Ordenación de los datos obtenidos en
respuestas a consultas
• Ej.: Ordenar los eventos por duración y luego
descendentemente por el numero de
participantes
 2.4. Consultas a una BDR
• 2.4.5. Consultas con agrupación de registros de
una tabla:
– Son cláusulas que se agregan a la instrucción SELECT
– Organizan en grupos los registros retornados por el
SELECT
– GROUP BY: Agrupa los registros según las
columnas que se indiquen
– HAVING: Filtra, de acuerdo a las condiciones
que se indique, los grupos de registros
obtenidos
– Repasemos y veamos ejemplos:
 2.4. Consultas a una BDR
– GROUP BY: Agrupa los registros según las
columnas que se indiquen
– Ej.: Determinar el total del área que ocupan
los complejos agrupados por sede
 2.4. Consultas a una BDR
– HAVING: Filtra, de acuerdo a las condiciones
que se indique, los grupos de registros
obtenidos
– Ej.: Determinar el total del área que ocupan
los complejos agrupados por sede, pero solo
mostrar los que ocupan mas de 5 mil m2
 2.4. Consultas a una BDR
• 2.4.6. Consultas a más de una tabla
– En los ejemplos anteriores (GROUP BY y HAVING)
solo podíamos ver el id de la sede, pero sería bueno
ver el nombre y sus complejos deportivos.
– Recordemos la clasificación de las operaciones del
Álgebra Relacional (ítem 3.5 de El Modelo Relacional)
• Conjuntistas: Se parecen a la teoría de conjuntos:
Unión, Intersección, Diferencia y Producto
Cartesiano
• Específicamente relacionales: Selección,
Proyección y (especialmente) Combinación
 2.4. Consultas a una BDR
• Combinación (JOIN):
– Devuelve los registros de
las tablas especificadas en
la cláusula FROM,
haciendo coincidir los
valores de las columnas
relacionadas de estas
tablas, es decir, la PK y la
FK.
– Ej.: Mostrar el nombre de
las sedes y el nombre de
sus complejos deportivos
 2.4. Consultas a una BDR
• Al hacer un JOIN, puede ocurrir que se
repitan nombres de atributos en tablas
diferentes, por ejemplo localizacion en
AREA_DEPORTIVA y COMPLEJO_DEPORTIVO
 2.4. Consultas a una BDR
• Entonces se debe especificar a qué tabla
corresponden los atributos, anteponiendo
al nombre del atributo el nombre de la
tabla a la que pertenece (así:
AREA_DEPORTIVA. localizacion y
COMPLEJO_DEPORTIVO. localizacion).
• Para simplificarlo, se utilizan los alias que
se definen en la cláusula FROM.
 2.4. Consultas a una BDR
– Ej: Mostrar el nombre y localización del
complejo deportivo junto con sus deportes y
la localización de las áreas deportivas
correspondientes
 2.4. Consultas a una BDR
– Alternativamente, el ejemplo anterior puede
resolverse usando SQL92
 2.4. Consultas a una BDR
• NATURAL JOIN: Es un JOIN en el que
automáticamente se igualan atributos de
nombres iguales de dos tablas diferentes,
usando SQL92.
• Ya que en nuestra BD de Olimpiadas no
se presenta el caso, cambiemos por un
momento de ejemplo
2.4. Consultas a una BDR
 2.4. Consultas a una BDR
– Ejemplo de NATURAL JOIN: Combinar la
tabla ESTUDIANTE con INSCRIPCION: El motor lo
hace igualando los campos ESTUDIANTE.id_estud
e INSCRIPCION.id_estud
 2.4. Consultas a una BDR
– Combinación Interna (INNER JOIN):
Devuelve los registros de la combinación
que tengan valores idénticos en las
columnas de las tablas que compara
– Se obtiene el mismo resultado que utilizando
solo JOIN como vimos anteriormente en las
Olimpiadas
– Veamos el ejemplo resuelto ahora con
INNER JOIN
 2.4. Consultas a una BDR
– Ej: Mostrar el nombre y localización del
complejo deportivo junto con sus deportes y
la localización de las áreas deportivas
correspondientes (usando INNER JOIN)
 2.4. Consultas a una BDR
– Usando INNER JOIN o simplemente JOIN
podríamos no ver información que puede ser de
interés, por ejemplo qué complejos deportivos
aún no se les ha ingresado áreas o viceversa
– Para resolver esto se tiene la COMBINACIÓN
EXTERNA tanto Derecha (RIGHT OUTER
JOIN), Izquierda (LEFT OUTER JOIN) y Plena
(FULL OUTER JOIN), las cuales también fueron
explicadas en el tema de El Algebra Relacional
 2.4. Consultas a una BDR
– Ej.: Mostrar el nombre y localización de los complejos
deportivos y deportes y la localización de las áreas
deportivas correspondientes incluyendo los complejos
que aún no se les ha asignado áreas deportivas
 2.4. Consultas a una BDR
• 2.4.7. La unión (UNION):
Une consultas de dos o
más sentencias SELECT
FROM
– Ej.: ¿Cuáles son los nombres
de las personas registradas
en la BD?
– Observando el MER, existen
dos atributos de nombres de
personas
– Los campos deben tener la
misma interpretación
semántica
2.4. Consultas a una BDR
 2.4. Consultas a una BDR

• 2.4.8. La intersección
(INTERSECT): Intersecta
consultas de dos o más
sentencias SELECT FROM
– Ej.: ¿Cuáles son los nombres
de jefes de complejos que
también son comisarios?
– Los campos deben tener la
misma interpretación
semántica
– También puede hacerse
intersección con IN y EXIST
 2.4. Consultas a una BDR
• 2.4.9. La diferencia
(EXCEPT): Halla la
diferencia entre consultas
de dos o más sentencias
SELECT FROM
– Ej.: ¿Cuáles son los nombres
de jefes de complejos que no
son comisarios?
– Los campos deben tener la
misma interpretación
semántica
– También puede hacerse
intersección con NOT IN y
NOT EXIST
 3 Sentencias de control
• Además de definir y manipular una BDR, es
importante que se establezcan mecanismos de
control para resolver problemas de concurrencia
de usuarios y garantizar la seguridad de los
datos.
• Para la concurrencia de usuarios utilizaremos el
concepto de transacción
• Para la seguridad veremos cómo se puede
autorizar y desautorizar a usuarios a acceder a la
BD
 3.1 Transacción
• En SQL, una transacción es un conjunto de
sentencias que se ejecutan como si fuesen una
sola unidad
• Se interrelacionan, y no tiene sentido que se
ejecute una sin que se ejecuten las demás
• En otras palabras si se ejecuta una de las
sentencias debe garantizarse que se ejecuten las
demás.
• Si esto ultimo no ocurre entonces debe deshacerse
las sentencias que ya se hayan ejecutado
 3.1 Transacción
• Las sentencias deben encerrarse entre otras
dos sentencias (BEGIN WORK o BEGIN
TRANSACTION y COMMIT WORK) para
indicarle al motor desde donde hasta donde va
la transacción
 3.1 Transacción

• Ejemplo: Al realizar una transferencia de dinero

entre dos cuentas se debe asegurar dos cosas:
– Descontar el dinero de la cuenta fuente
– Abonar el dinero en la cuenta destino
• Si no se lleva a cabo las dos operaciones no se
debe llevar a cabo ninguna de ellas
• Desde el punto de vista del SQL éstas dos
operaciones son una transacción en la que
utilizaríamos dos sentencias:
 3.1 Transacción
– Un UPDATE para disminuir el saldo de la cuenta fuente
– Un UPDATE para aumentar el saldo de la cuenta
destino
• La transacción podría quedar como algo así:
BEGIN WORK;
UPDATE cuenta
SET saldo = saldo – valor_a_transferir
WHERE nro_cuenta = nro_cuenta_origen;
UPDATE cuenta
SET saldo = saldo + valor_a_transferir
WHERE nro_cuenta = nro_cuenta_destino;
COMMIT WORK;
 3.1 Transacción
• Otro ejemplo en nuestra BD de Olimpiadas
• Suponga que para agregar una Sede de las
Olimpiadas se debe asegurar que al mismo
tiempo se agreguen sus Complejos Deportivos y
a la vez las Áreas Deportivas y que además se
vaya incrementando el campo nro_complejos de la
sede
• En este caso sería necesario varios INSERT y
un UPDATE para lograr que todo quede en una
transacción
3.1 Transacción
3.1 Transacción
 3.1 Transacción
• Podemos ver el resultado de la
transacción haciendo la siguiente consulta
 3.2 Autorizaciones
• Por seguridad se deben otorgar (GRANT) o
retirar (REVOKE) permisos sobre diferentes
elementos de la BD de acuerdo al perfil de los
usuarios
• Por ejemplo si el usuario ‘auxiliar1’ requiere
consultar la tabla EQUIPAMIENTO de nuestra BD
de Olimpiadas debemos darle la autorización de
la siguiente forma:

GRANT SELECT ON equipamiento TO auxiliar1

 3.2 Autorizaciones
• Si el usuario ‘auxiliar1’ ya no requiere consultar
la tabla EQUIPAMIENTO de nuestra BD de
Olimpiadas debemos retirarle la autorización de
la siguiente forma:

REVOKE SELECT ON equipamiento FROM

auxiliar1