Modulo 4
Modulo 4
Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,
reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico,
químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escrita
de los titulares del copyright.
© FUOC • PID_00171669 El lenguaje SQL I
Índice
Introducción............................................................................................... 5
Objetivos....................................................................................................... 9
Resumen....................................................................................................... 51
Actividades.................................................................................................. 53
© FUOC • PID_00171669 El lenguaje SQL I
Ejercicios de autoevaluación.................................................................. 53
Solucionario................................................................................................ 54
Bibliografía................................................................................................. 57
Anexos........................................................................................................... 58
© FUOC • PID_00171669 5 El lenguaje SQL I
Introducción
Empecemos con una breve explicación sobre el modo en que SQL ha llegado
a ser el lenguaje estándar de las BD relacionales:
3) En 1989, el estándar fue objeto de una revisión y una ampliación que die-
ron lugar al lenguaje que se conoce con el nombre de SQL1 o SQL:1989. En
1992, el estándar volvió a ser revisado y ampliado considerablemente para cu-
brir carencias de la versión anterior. Esta nueva versión de SQL se conoce con
el nombre de SQL2 o SQL:1992. En 1999, apareció la esperada versión SLQ3
o SQL:1999, en la que, entre otras cosas, se definía formalmente uno de los
componentes lógicos de control más útiles: los disparadores.
© FUOC • PID_00171669 6 El lenguaje SQL I
En este módulo didáctico, aunque aparezca sólo la sigla SQL, siempre nos re-
feriremos a la última�versión, ya que tiene como subconjunto todas las ante-
riores y, por lo tanto, todo lo que era válido en la anterior lo continuará siendo
en la siguiente. Sólo especificaremos el año de una versión de SQL cuando,
por ejemplo, queramos enfatizar que fue concretamente en ésta en la que se
hizo una aportación determinada.
Con SQL se puede definir y manipular una BD relacional. Acto seguido vere-
mos, aunque sólo de manera introductoria, cómo se podría hacer tal cosa:
1) Habría que crear una tabla que contuviera los datos de los productos de
nuestra empresa:
Y muchas más cosas que iremos viendo, punto por punto, en los siguientes
apartados.
Fijémonos en la estructura de todo lo que hemos hecho hasta ahora con SQL.
Las operaciones de SQL se llaman sentencias y están formadas por diferentes
partes que denominamos cláusulas, tal como podemos ver en el ejemplo si-
guiente:
Los dos primeros apartados de este módulo tratan de un tipo de SQL llamado
SQL�interactivo, que permite acceder directamente a una BD relacional. En
el primer apartado, definiremos las llamadas sentencias�de�definición, en las
que crearemos la BD, las tablas que la compondrán, los dominios y las asercio-
nes que queramos. En el segundo apartado, aprenderemos a manipular la BD,
introduciendo valores en las filas, modificándolos o borrándolos, o haciendo
consultas.
Objetivos
Una vez finalizado el estudio de los materiales didácticos de este módulo, ten-
dréis las herramientas indispensables para alcanzar los siguientes objetivos:
Para poder trabajar con BD relacionales, lo primero que tenemos que hacer es
definirlas. Veremos las sentencias de SQL estándar para crear y borrar una BD
relacional y para crear, borrar y modificar las diferentes tablas que la compo-
nen. En este apartado, también veremos cómo se definen los dominios y las
aserciones (restricciones).
La adecuación de estas sentencias en cada caso nos dará diferencias que iremos
perfilando al hacer la descripción individual de cada una.
Para ilustrar la aplicación de las sentencias de SQL que iremos viendo, utiliza-
remos una�BD�de�ejemplo muy sencilla de una pequeña empresa con sede en
Barcelona, Gerona, Lérida y Tarragona, que se encarga de desarrollar proyectos
informáticos. La información que nos interesará almacenar de esta empresa,
que llamaremos BDUOC, será la siguiente:
SQL estándar no dispone de ninguna sentencia de creación de BD. La idea es La instrucción CREATE
que una BD no es nada más que un conjunto de tablas y, por lo tanto, las DATABASE
sentencias que SQL nos ofrece se concentran en la creación, la modificación Muchos de los sistemas re-
y el borrado de estas tablas. la-cionales comerciales (como
es el caso de Informix, DB2,
SQL Server y otros) han incor-
pora-do sentencias de creación
En cambio, disponemos de una sentencia más potente que la de creación de de BD con la siguiente sintaxis:
BD: la sentencia�de�creación�de�esquemas llamada CREATE SCHEMA. CREATE DATABASE
<nombre_BD>;
• La notación [...] quiere decir que lo que hay entre los corchetes se podría
poner o no.
• La notación {A|...|B} quiere decir que tenemos que escoger entre todas las
opciones que hay entre las llaves. Pero tenemos que poner una obligato-
riamente.
Si sólo especificamos al usuario, éste será el escogido como nombre del esque-
ma.
La creación de esquemas puede hacer mucho más que agrupar tablas, porque
lista_elementos_esquema puede ser, además de tablas y dominios, otros
componentes.
© FUOC • PID_00171669 13 El lenguaje SQL I
Para borrar una BD encontramos el mismo problema que para crearla. SQL nos
ofrece sólo la sentencia�de�borrado�de�esquemas�DROP SCHEMA, que tiene
la siguiente sintaxis:
La sentencia DROP
DATABASE
El proceso que hay que seguir para crear una tabla es el siguiente:
2) Dar nombre a cada uno de los atributos que formarán las columnas de la
tabla (nombre_columna).
4) Una vez definidas las columnas, sólo habrá que dar las restricciones de tabla.
Para cada columna tenemos que escoger entre algún dominio definido por el
usuario o alguno de los tipos de datos predefinidos que se describen a conti-
nuación:
© FUOC • PID_00171669 14 El lenguaje SQL I
YEAR (0001..9999)
MONTH (01..12)
DAY (01..31)
HOUR (00..23)
MINUT (00..59)
SECOND (00..59.precisión)
De todas maneras, los SGBD comerciales disponen de diferentes formatos, entre los cua-
les podemos escoger cuándo tenemos que trabajar con columnas temporales.
© FUOC • PID_00171669 15 El lenguaje SQL I
• La columna fecha_nacimiento podría ser de tipo DATE y podría tener como valor
'1978-12-25'.
• La columna inicio_partido podría ser de tipo TIME y podría tener como valor
'17:15:00.000000'.
• La columna entrada_trabajo podría ser de tipo TIMESTAMP y podría tener como
va-lor '1998-7-8 9:30:05'.
La sentencia CREATE DOMAIN de SQL:1992 hay pocos SGBD comerciales que permitan
usarla. De todos modos, SQL:1999 ofrece los USER DEFINED TYPES como una nueva
posibilidad para la creación de dominios definidos para el usuario más potente que la
propuesta por SQL:1992.
Además de los dominios dados por los tipos de datos predefinidos, SQL nos Ved también
ofrece la posibilidad de trabajar con dominios definidos por el usuario.
Explicaremos la construcción
de condiciones más adelante,
Para crear�un�dominio hay que utilizar la sentencia CREATE DOMAIN: en el subapartado 2.5, cuando
hablemos de cómo se hacen
consultas en una BD. Veremos
def_defecto en el subapar-
tado 1.2.3 de este módulo.
Aunque dar nombre a la res-
tricción sea opcional, normal-
mente se le da para poderla re-
donde restricciones_dominio tiene el siguiente formato: ferenciar posteriormente.
Si quisiéramos definir un dominio para las ciudades donde se encuentran los depar-
ta-mentos de la empresa BDUOC, haríamos:
Por ejemplo, si tenemos una columna con los nombres de los empleados definida sobre
el tipo de datos CHAR(20), SQL nos permite compararla con la columna ciudad, aunque
semánticamente no tenga sentido. En cambio, según el modelo relacional, esta compa-
ración no se tendría que haber permitido.
Si quisiéramos borrar el dominio que hemos creado antes para las ciudades donde se
encuentran los departamentos de la empresa BDUOC, haríamos:
En este caso, nos aseguraríamos de que ninguna columna está definida sobre
dom_ciudades antes de borrar el dominio.
Si quisiéramos añadir una ciudad nueva (Mataró) en el dominio que hemos creado an-
tes para las ciudades donde se encuentran los departamentos de la empresa BDUOC,
haríamos:
Con ello, hemos eliminado la restricción de dominio antigua. Y ahora tenemos que in-
troducir la nueva restricción:
Ejemplo
Para un empleado del cual todavía no se ha decidido cuánto ganará, se puede escoger que,
de momento, tenga un sueldo de 0 euros (DEFAULT 0.0), o bien que tenga un sueldo
con un valor nulo (DEFAULT NULL).
Hay que tener en cuenta, sin embargo, que si escogemos la opción DEFAULT
NULL la columna para la cual daremos la definición por defecto de valor nulo
tendría que admitir valores nulos. La opción DEFAULT tiene el siguiente for-
mato:
Función Descripción
En cada una de las columnas de la tabla, una vez les hemos dado un nombre y
hemos definido el dominio, podemos imponer ciertas restricciones que siem-
pre se tendrán que cumplir. Las restricciones que se pueden dar son las que
aparecen en la tabla que tenéis a continuación:
Restricciones de columna
Restricción Descripción
Restricciones de columna
Restricción Descripción
Una vez hemos dado un nombre, hemos definido un dominio y hemos im-
puesto ciertas restricciones para cada una de las columnas, podemos aplicar
restricciones sobre toda la tabla, las cuales siempre se tendrán que cumplir. Las
restricciones que se pueden dar son las siguientes:
Restricciones de tabla
Restricción Descripción
CONSTRAINT [<nombre_restriccion>] CHECK (<condiciones>) La tabla tiene que cumplir las condiciones especifi-
cadas.
Sabemos que hay tres políticas aplicables a los casos de borrado y modificación
de filas que tienen una clave primaria referenciada por claves foráneas. Estas
políticas eran la restricción, la actualización en cascada y la anulación..
SQL nos ofrece la posibilidad de especificar, definiendo una clave foránea, qué
política queremos seguir. Veamos el formato:
1.2.7. Aserciones
Una aserción es una restricción general que hace referencia a una o más co-
lumnas de una o más tablas. Para definir� una� aserción se usa la sentencia
CREATE ASSERTION y tiene el siguiente formato:
Creamos una aserción sobre la BD BDUOC que nos asegure que no hay ningún empleado
con un sueldo superior a 80000 asignado al proyecto SALSA:
Para borrar�una�aserción, hay que utilizar la sentencia DROP ASSERTION, que Aserciones
presenta este formato:
Aunque SQL ofrezca la senten-
cia CREATE ASSERTION, no
existen productos comerciales
que permitan usarla. La alter-
nativa a las aserciones son los
disparadores (triggers). Los dis-
Borrar un aserción en BDUOC paradores fueron introducidos
con SQL:1999 y, a diferencia
Para borrar la aserción restriccion1, utilizaríamos la sentencia DROP ASSERTION de de las aserciones, la gran ma-
la siguiente manera: yoría de productos comerciales
los ofrecen.
Si queremos modificar una tabla, es que queremos hacer una de las siguientes
operaciones:
Lo primero que tenemos que hacer para crear una vista es decidir qué nombre
le queremos poner (nombre_vista). Si queremos cambiar el nombre de las
columnas, o bien poner nombre a alguna que en principio no tenía, lo pode-
mos hacer en lista_columnas. Y ya sólo nos quedará definir la consulta que
formará nuestra vista.
Creamos una vista sobre la BD BDUOC que nos dé para cada cliente el número de pro-
yectos que tiene encargados el cliente en cuestión.
• Tabla clientes:
• Tabla proyectos:
proyectos_por_clientes
codigo_cli numero_proyectos
10 2
20 1
30 1
© FUOC • PID_00171669 22 El lenguaje SQL I
• Tabla clientes
• Tabla proyectos:
El SGBD no puede actualizar la tabla básica clientes si sólo sabe la clave primaria, y
todavía menos la tabla básica proyectos sin la clave primaria; por lo tanto, esta vista
no sería actualizable.
En cambio, si definimos una vista para saber los clientes que tenemos en Barcelona o en
Gerona, haríamos:
Esta vista sí podría ser actualizable. Podríamos insertar un nuevo cliente con código 50,
de nombre CEA, con el NIF 38.226.777-D, con la dirección París 44, la ciudad Barcelona
y el teléfono 93.422.60.77. Después de esta actualización, en la tabla básica clientes
encontraríamos, efectivamente:
Para borrar una vista es preciso utilizar la sentencia�DROP VIEW, que presenta
el formato:
Orden de creación
Nota
PRIMARY KEY
Una vez creada la BD con sus tablas, habrá que poder insertar, modificar y
borrar los valores de las filas de las tablas. Para poder hacer eso, SQL nos ofre-
ce las siguientes sentencias: INSERT, para insertar; UPDATE, para modificar, y
DELETE, para borrar. Una vez hemos insertado valores en las tablas, tenemos
que poder consultarlos. La sentencia para hacer consultas a una BD con SQL
es SELECT FROM. Veamos, acto seguido, estas sentencias.
Antes de poder consultar los datos de una BD, hay que introducir los datos
con la sentencia INSERT INTO VALUES, que tiene el siguiente formato:
del nombre de la tabla. En este último caso, los valores se deben disponer de
manera coherente con el nuevo orden que hemos impuesto. Podría ser que
quisiéramos que algunos valores a insertar fueran valores por omisión, defi-
nidos previamente con la opción DEFAULT. Entonces pondríamos la palabra
reservada DEFAULT. Si se trata de introducir valores nulos también podemos
usar la palabra reservada NULL.
o bien:
• Tabla departamentos:
© FUOC • PID_00171669 27 El lenguaje SQL I
• Tabla clientes:
• Tabla empleados:
• Tabla proyectos:
Para hacer consultas sobre una tabla con SQL, hay que utilizar la sentencia
SELECT FROM, que tiene el siguiente formato:
© FUOC • PID_00171669 28 El lenguaje SQL I
Consultas en BDUOC
SELECT
A continuación, presentamos un ejemplo de consulta con la BD BDUOC para conocer
todos los datos que hay en la tabla clientes El asterisco (*) después de SE-
LECT indica que queremos ver
todos los atributos que hay en
la tabla.
SELECT * FROM clientes;
La cláusula WHERE nos permite obtener las filas que cumplen la condición
especificada en la consulta.
Veamos un ejemplo en el que pedimos “los códigos de los empleados que trabajan en
el proyecto número 4”:
SELECT codigo_empl
FROM empleados
WHERE num_proy = 4;
codigo_empl
Operadores de comparación
= Igual
< Menor
> Mayor
<> Diferente
Operadores lógicos
Si queremos que en una consulta nos aparezcan las filas resultantes sin repe-ti-
ciones, hay que poner la palabra clave DISTINCT inmediatamente después de
SELECT. También podríamos explicitar que lo queremos todo, incluso con re-
peticiones, poniendo ALL (opción por defecto) en lugar de DISTINCT. El for-
mato de DISTINCT es el siguiente:
© FUOC • PID_00171669 30 El lenguaje SQL I
sueldo
30000.0
40000.0
70000.0
90000.0
100000.0
SQL ofrece las siguientes funciones� de� agregación para efectuar diferentes
operaciones con los datos de una BD:
Funciones de agregación
Función Descripción
numero_dept
2.5.2. Subconsultas
Ved también
Una subconsulta es una consulta incluida dentro de una cláusula WHERE
o HAVING de otra consulta. A veces, para expresar ciertas condiciones Veremos la cláusula HAVING
en el subapartado 2.5.5 de es-
no hay otro remedio que obtener el valor que buscamos como resultado te módulo didáctico.
de una consulta.
Si quisiéramos saber los códigos y los nombres de los proyectos de precio más alto, en Si en lugar de los códigos y los
nombres de los proyectos de
primer lugar tendríamos que encontrar los proyectos que tienen el precio más alto. Lo
precio más alto hubiéramos
haríamos de la siguiente manera: querido saber los de precio
más bajo, habríamos aplicado
la función de agregación MIN.
SELECT codigo_proy, nombre_proy FROM proyectos
WHERE precio = (SELECT MAX(precio)
FROM proyectos);
codigo_proy nombre_proy
4 TINELL
1)�Predicado�BETWEEN
Para expresar una condición que quiere encontrar un valor entre unos límites
concretos podemos utilizar BETWEEN:
© FUOC • PID_00171669 32 El lenguaje SQL I
Se piden “Los códigos de los empleados que ganan entre 20.000 y 50.000 euros anuales”.
SELECT codigo_empl
FROM empleados
WHERE sueldo BETWEEN 20000.0 and 50000.0;
codigo_empl
2)�Predicado�IN
Para ver si un valor coincide con los elementos de una lista utilizaremos IN,
y para ver si no coincide, NOT IN:
“Queremos saber el nombre de todos los departamentos que se encuentran en las ciuda-
des de Lérida o Tarragona.”
nombre_dpt ciudad_dpt
DIS Lerida
PROG Tarragona
3)�Predicado�LIKE
Para ver si una columna de tipo carácter cumple alguna característica deter-
minada podemos utilizar LIKE:
© FUOC • PID_00171669 33 El lenguaje SQL I
codigo_empl nombre_empl
4 Jorge
SELECT codigo_proy
FROM proyectos
WHERE nombre_proy LIKE "S_ _ _ _";
codigo_proy
4)�Predicado�IS NULL
“Queremos saber el código y el nombre de todos los empleados que no están asignados
a ningún proyecto.”
codigo_empl nombre_empl
8 Sergio
5)�Predicados�ANY/SOME i ALL
Para ver si una columna cumple que todas sus filas (ALL) o alguna de sus filas Los predicados ANY/SOME
(ANY/SOME) satisfagan una condición, podemos hacer:
Podemos escoger cualquiera
de los dos predicados para pe-
dir alguna fila que satisfaga
una condición.
a) Un ejemplo de utilización de ALL para encontrar los códigos y los nombres de los
proyectos en que los sueldos de todos los empleados asignados son más pequeños que
el precio del proyecto.
Fijémonos en la condición de WHERE de la subconsulta, que nos asegura que los sueldos
que miramos son los de los empleados asignados al proyecto de la consulta. La respuesta
a esta consulta sería la siguiente:
codigo_proy nombre_proy
1 GESCOM
2 PESCI
3 SALSA
4 TINELL
© FUOC • PID_00171669 35 El lenguaje SQL I
codigo_proy nombre_proy
6)�Predicado�EXISTS
Para ver si una subconsulta produce alguna fila de resultados, podemos utilizar
la sentencia llamada test de existencia: EXISTS. Para comprobar si una subcon-
sulta no produce ninguna fila de resultados, podemos utilizar NOT EXISTS.
Se buscan los códigos y los nombres de los empleados que están asignados a algún pro-
yecto.
codigo_empl nombre_empl
1 Maria
2 Pedro
3 Ana
4 Jorge
5 Clara
6 Laura
7 Roger
© FUOC • PID_00171669 36 El lenguaje SQL I
Si se quiere que, al hacer una consulta, los datos aparezcan en un orden de-
terminado, hay que utilizar la cláusula�ORDER BY en la sentencia SELECT,
que tiene el siguiente formato:
Se quiere consultar los nombres de los empleados ordenados según el sueldo que ganan,
y si ganan el mismo sueldo, ordenados alfabéticamente por el nombre:
a) La cláusula�GROUP BY nos sirve para agrupar filas según las columnas que
indique esta cláusula.
Fijémonos que en las sentencias SQL se van añadiendo cláusulas a medida que
la dificultad o la exigencia de la consulta lo requiere.
La cláusula GROUP BY podríamos decir que empaqueta a los empleados de la tabla em-
pleados según el departamento en que están asignados. En la siguiente figura, podemos
ver los grupos que se formarían después de agrupar:
num_proy
Muchas veces queremos consultar datos de más de una tabla haciendo com-
binaciones de columnas de tablas diferentes. En SQL es posible listar más de
una tabla especificándolo en la cláusula FROM.
1)�Combinación
La combinación consigue crear una sola tabla a partir de las tablas especifica-
das en la cláusula FROM, haciendo coincidir los valores de las columnas rela-
cionadas de estas tablas.
© FUOC • PID_00171669 39 El lenguaje SQL I
Se quiere saber el NIF del cliente y el código y el precio del proyecto que se desarrolla
para el cliente número 20:
3 1000000.0 38.123.898-E
Si trabajamos con más de una tabla, puede pasar que la tabla resultante tenga
dos columnas con el mismo nombre. Por eso, es obligatorio especificar a qué
tabla corresponden las columnas a las que nos referimos, nombrando a la tabla
a la que pertenecen, antes de ponerlas (por ejemplo, clientes.codigo_cli).
Para simplificarlo se utilizan los alias, que, en este caso, se definen en la cláu-
sula FROM.
c podría ser el alias de la tabla clientes. De esta manera, para indicar a qué tabla perte-nece
codigo_cli sólo habría que poner c.codigo_cli.
Veamos cómo quedaría la consulta anterior expresada mediante alias, aunque en este
ejemplo no serían necesarios porque las columnas de las dos tablas tienen nombres di-
ferentes. Pediremos, además, las columnas c.codigo_cli y p.codigo_cliente.
3 1000000.0 38.123.898-E 20 20
Advertimos que en el WHERE necesitamos expresar el vínculo que hay entre las dos ta-blas,
en este caso codigo_cli de clientes y codigo_cliente de proyectos. Expresado
en operaciones del álgebra relacional, esto quiere decir que hacemos una combinación
en lugar de un producto cartesiano.
Fijémonos en que, igual que en el álgebra relacional, la operación que acabamos de hacer
es una equicombinación (equi-join) y, por lo tanto, nos aparecen dos columnas idénticas:
c.codigo_cli y p.codigo_cliente.
Con esta operación, se obtendría el mismo resultado que con el método an-
terior.
También podemos utilizar una misma tabla dos veces con alias diferentes, para
poder distinguirlas.
Se piden los códigos y los apellidos de los empleados que ganan más que el empleado
que tiene por código el número 5.
Se ha tomado la tabla e2 para fijar la fila del empleado con código número 5, de mane-ra
que se pueda comparar el sueldo de la tabla e1, que contiene a todos los empleados, con
el sueldo de la tabla e2, que contiene sólo al empleado 5.
e1.codigo_empl e1.apellido_empl
1 Puig
2 Mas
3 Ros
4 Roca
2)�Combinación�natural
© FUOC • PID_00171669 41 El lenguaje SQL I
Se quiere saber el código y el nombre de los empleados que están asignados al departa-
mento que tiene por teléfono 977.333.852.
La combinación natural también se podría hacer con la cláusula USING, sólo aplicando
la palabra reservada JOIN:
codigo_empl nombre_empl
5 Clara
6 Laura
8 Sergio
3)�Combinación�interna�y�externa
La combinación�interna (inner join) sólo se queda con las filas que tienen va-
lores idénticos en las columnas de las tablas que compara. Esto puede hacer
que se pierda alguna fila interesante de alguna de las dos tablas, por ejemplo,
porque se encuentra NULL en el momento de hacer la combinación. Su for-
mato es el siguiente:
Combinación interna
4)�Combinaciones�con�más�de�dos�tablas
Si se quieren combinar tres tablas o más con SQL:1989 sólo hay que añadir
todas las tablas en el FROM y los vínculos necesarios en el WHERE. Si se vuelven
a combinar con SQL:1992 hay que ir haciendo combinaciones por parejas de
tablas y la tabla resultante se convertirá en la primera pareja de la siguiente.
Veamos ejemplos de los dos casos, suponiendo que se quieran combinar las tablas em-
pleados, proyectos y clientes:
SELECT *
FROM empleados, proyectos, clientes
WHERE num_proy = codigo_proy AND codigo_cliente = codigo_cli;
o bien:
SELECT *
FROM (empleados JOIN proyectos ON num_proy = codigo_proy)
JOIN clientes ON codigo_cliente = codigo_cli;
2.5.7. La unión
Si se utiliza la opción ALL, aparecen todas las filas obtenidas al hacer la unión.
No se escribirá esta opción si se quieren eliminar las filas repetidas. Lo más
importante de la unión es que somos nosotros los que tenemos que vigilar que
se haga entre columnas definidas sobre dominios compatibles; es decir, que
tengan la misma interpretación semántica. Como ya se ha dicho, SQL no ofre-
ce herramientas para asegurar la compatibilidad semántica entre columnas.
© FUOC • PID_00171669 45 El lenguaje SQL I
Si se quieren saber todas las ciudades que hay en la BD se puede hacer lo siguiente:
SELECT ciudad
FROM clientes
UNION
SELECT ciudad_dpt
FROM departamentos;
ciudad
Barcelona
Gerona
Lerida
Tarragona
2.5.8. La intersección
Para hacer la intersección entre dos o más sentencias SELECT FROM, se puede
utilizar la cláusula INTERSECT, cuyo formato es el siguiente:
Si se utiliza la opción ALL aparecen todas las filas obtenidas al hacer la in-
ter-sección. No se escribirá esta opción si se quieren eliminar las filas repetidas.
Lo más importante de la intersección es que somos nosotros los que tenemos
que vigilar que se haga entre columnas definidas sobre dominios compatibles;
es decir, que tengan la misma interpretación semántica.
© FUOC • PID_00171669 46 El lenguaje SQL I
Se quieren saber todas las ciudades donde hay departamentos en los cuales se puede
encontrar algún cliente.
SELECT ciudad
FROM clientes
INTERSECT
SELECT ciudad_dpt
FROM departamentos;
ciudad
Barcelona
Gerona
Lerida
Tarragona
SELECT ciudad
FROM clientes
WHERE ciudad IN (SELECT ciudad_dpt
FROM departamentos);
SELECT c.ciudad
FROM clientes c
WHERE EXISTS (SELECT *
FROM departamentos d
WHERE c.ciudad = d.ciudad_dpt);
© FUOC • PID_00171669 47 El lenguaje SQL I
2.5.9. La diferencia
Para encontrar la diferencia entre dos o más sentencias SELECT FROM podemos
utilizar la cláusula EXCEPT, que tiene este formato:
Si se utiliza la opción ALL, aparecen todas las filas obtenidas al hacer la dife-
rencia. No se escribirá esta opción si se quieren eliminar las filas repetidas. Lo
más importante de la diferencia es que somos nosotros los que tenemos que
vigilar que se haga entre columnas definidas sobre dominios compatibles.
codigo_cli
40
La diferencia es, junto con la intersección, una de las operaciones de SQL que
se puede hacer de más maneras diferentes:
SELECT codigo_cli
FROM clientes
WHERE codigo_cli NOT IN (SELECT codigo_cliente FROM proyectos);
SELECT c.codigo_cli
FROM clientes c
WHERE NOT EXISTS (SELECT *
FROM proyectos p
WHERE c.codigo_cli = p.codigo_cliente);
© FUOC • PID_00171669 49 El lenguaje SQL I
1)Autorizaciones
• DOMAIN: dominio
• TABLE: tabla.
• Vista.
c)�Usuarios puede ser todo el mundo: PUBLIC, o bien una lista de los identi-
ficadores de los usuarios que queremos autorizar.
2)�Desautorizaciones
Resumen
En este módulo, hemos presentado las sentencias más utilizadas del lenguaje
estándar SQL de definición y manipulación de BD relacionales. Como ya he-
mos comentado en la introducción, SQL es un lenguaje muy potente y eso
hace que haya más sentencias y opciones de las que hemos explicado en este
módulo. También es cierto, sin embargo, que hemos visto más sentencias de
las que algunos sistemas relacionales comerciales ofrecen actualmente. Hemos
intentado seguir con la mayor fidelidad el estándar, incluyendo comentarios
sólo cuando en la mayoría de SGBD comerciales alguna operación se hacía de
manera diferente.
Si se conoce SQL se puede trabajar con cualquier SGBD comercial; sólo habrá
que dedicar unas cuantas horas a identificar las variaciones respecto del están-
dar.
2) Definir las tablas, los dominios, las aserciones y las vistas que formarán la
BD.
Actividades
1. A buen seguro que siempre habéis querido saber dónde teníais aquellos apuntes que nunca
encontrabais. Os proponemos crear una BD para organizar los apuntes y localizarlos rápida-
mente cuando os apetezca utilizarlos. Tendréis que crear la BD y las tablas; decidir las claves
primarias y las foráneas, e insertar filas.
Para almacenar los apuntes tendremos que crear las siguientes tablas:
Ejercicios de autoevaluación
Con la actividad hemos insertado filas y, si nos hubiéramos equivocado, también habríamos
borrado y modificado alguna fila. Con los ejercicios de autoevaluación practicaremos la parte
de sentencias de manipulación que todavía no hemos tratado: las consultas. Los ejercicios
que proponemos se harán sobre la BD relacional BDUOC que ha ido saliendo en todo este
módulo.
1. Obtened los códigos y los nombres y apellidos de los empleados ordenados alfabéticamente
de manera descendente por apellido y, en caso de repeticiones, por nombre.
2. Consultad el código y el nombre de los proyectos de los clientes que son de Barcelona.
3. Obtened los nombres y las ciudades de los departamentos que trabajan en los proyectos
número 3 y 4.
4. De todos los empleados que perciben un sueldo de entre 50.000 y 80.000 euros, buscad
los códigos de empleado y los nombres de los proyectos que tienen asignados.
5. Buscad el nombre, la ciudad y el teléfono de los departamentos donde trabajan los em-
pleados del proyecto GESCOM.
6. Obtened los códigos y los nombres y apellidos de los empleados que trabajan en los pro-
yectos de precio más alto.
7. Averiguad cuál es el sueldo más alto de cada departamento. Concretamente, hay que dar
el nombre y la ciudad del departamento y el sueldo mayor.
8. Obtened los códigos y los nombres de los clientes que tienen más de un proyecto contra-
tado.
9. Averiguad los códigos y los nombres de los proyectos en que todos los empleados que
están asignados tienen un sueldo superior a 30.000 euros.
10. Buscad los nombres y las ciudades de los departamentos que no tienen ningún empleado
asignado.
© FUOC • PID_00171669 54 El lenguaje SQL I
Solucionario
1.
3.
7.
10.
o bien:
Bibliografía
El SLQ:1992 se define, según si lo buscáis en ISO o en ANSI, en cualquiera de los siguientes
documentos:
Date, C. J. (2001). Introducción a los sistemas de bases de datos (7.ª ed.). Madrid: Prentice-Hall.
Tenéis incluso una versión más resumida de uno de los mismos autores del libro anterior
en el capítulo 4 de este libro. Además, en el apéndice B podéis encontrar una panorámica
de SQL:1999.
Date, C. J.; Darwen, H. (1997). A Guide to the SQL Standard (4.ª ed.). Reading (Massachu-
setts): Addison-Wesley.
Los libros que contienen la descripción del estándar ANSI/ISO SQL: 1992 son bastante gruesos
y pesados de leer. Este libro es un resumen del oficial.
Otros libros traducidos al castellano de SQL: 1992 que os recomendamos son los siguientes:
Groff, J. R.; Weinberg, P. N. (1998). LAN Times. Guía de SQL. Osborne: McGraw-Hill.
Os recomendamos su consulta por su claridad y por los comentarios sobre la manera en que
se utiliza el estándar en los diferentes sistemas relacionales comerciales.
Silberschatz, A.; Korth, H. F.; Sudarshan, S. (1998). Fundamentos de bases de datos. (3.ª
ed.). Madrid: McGraw-Hill.
Podéis encontrar una lectura rápida, resumida, pero bastante completa de SQL en el capítulo
4 de este libro.
Melton, J.; Simon, A. R. (2002). SQL: 1999. Understanding Relational Language Components.
San Francisco: Morgan Kaufmann.
Para manteneros informados de las publicaciones de nuevas versiones del estándar, podéis
consultar la dirección web de ANSI:
Anexos
Anexo�1.�Sentencias�de�definición�de�datos
1) Creación de esquemas:
2) Borrado de esquemas:
5) Creación de tablas:
• definicion_columna es:
7) Borrado de tablas:
8) Creación de dominios:
9) Modificación de un dominio:
Anexo�2.�Sentencias�de�manipulación�de�datos
Anexo�3.�Sentencias�de�concesión�y�revocación�de�privilegios
© FUOC • PID_00171669 61 El lenguaje SQL I
1) Autorizaciones:
2) Desautorizaciones: