SQL

1. Una simple gramtica sintctica

La gramtica sintctica utilizada en las diferentes lecciones para explicar la sintaxis de las instrucciones SQL.

2. Web, Base de datos y DBMS

Las caractersticas y funciones principales segn las cuales se clasifican normalmente los DBMS.

3. El modelo relacional
Historia y panormica de las bases de datos relacionales.

4. Breve historia de SQL

Historia y desarrollo de SQL desde 1974 hasta hoy

5. Una base de datos de ejemplo

Presentacin de la estructura de la base de datos que ser utilizada para los ejemplos de las siguientes lecciones.

6. Instrumentos para interactuar con un DBMS

Las dos modalidades de interaccin con DBMS: invocacin interactiva e invocacin a travs de un programa aplicativo

7. Crear la base de datos

La creacin de la base de datos consiste en la creacin de las tablas que lo componen

8. Poblar la base de datos

Con la expresin "poblacin de la base de datos" se entiende la actividad de inclusin de los datos en ella.

9. Interrogar a la base de datos

Las instrucciones necesarias para extraer de una base de datos relacional los datos que interesan.

10. Actualizar la base de datos

Cmo modificar los datos ya incluidos en las tablas de la base de datos.

11. Modificar la estructura de la base de datos

A veces no es suficiente modificar los datos, sino que hay que actualizar la estructura misma de la base de datos para hacer que puedan representarse
nuevas informaciones

12. Uso multiusuario de una base de datos

Normalmente, el acceso a los datos se da de manera colectiva por parte de varios usuarios la mismo tiempo

11. Referencias bibliogrficas y web

Sitios Web y libros de profundizacin sobre SQL.

Una simple gramtica sintctica

La gramtica sintctica utilizada en las diferentes lecciones para explicar la sintaxis

de las instrucciones SQL es muy simple:
El texto en mayscula tiene que aparecer como es. El lenguaje SQL no es
case-sensitive, por lo que despus, en los ejemplos, aparecern tanto letras
maysculas como minsculas, de manera que aumenta la legibilidad.
El texto en minscula indica elementos que tienen que ser especificados
despus. Por ejemplo, si aparece vnculos_de_columna no significa que en
esa posicin haya que escribir correctamente la secuencia de caracteres, sino
que encontrarn sitio los vnculos de la columna, especificados con su sintaxis
concreta, que se explica en otro lugar.
Los corchetes ([]) indican elementos opcionales y que por tanto no tienen por
qu aparecer.
Los puntos suspensivos (...) indican elementos que se pueden repetir. Por
ejemplo:
[ , [ vnculo_de_tabla ] ... ]
indica que el elemento ", [vnculo_de_tabla]" se puede repetir tantas veces
como sea necesario.
Elementos separados por el carcter "|", y eventualmente agrupados entre
llaves ({}), indican elementos que alternativos. Por ejemplo:
{ elemento1 | elemento2 }
indica que en esa posicin habr que escribir o elemento1 o elemento2.
El texto escrito entre comillas simples (') o dobles (") se escribe exactamente

como est indicado (comillas, maysculas y minsculas incluidas).

Los dems caracteres (por ejemplo las comas(,) o las comillas dobles("))
tienen que aparecer como son.

Web, Base de datos y DBMS

El World Wide Web quiz sea una de las mayores fuentes de informacin a la que
hoy podemos dirigirnos: teniendo a disposicin una conexin a Internet y un
navegador Web, un software comn de cualquier ordenador, tenemos la posibilidad
de consultar un patrimonio de cientos de millones de pginas a propsito de cualquier
argumento que nos interese.
A menudo, estas pginas no son documentos estticos, sino que se crean
dinmicamente cuando las invocamos, y las informaciones que contienen se extraen
de una base de datos. Si se trata de una base de datos relacional(veremos a
continuacin qu significa esto), es probable que el lenguaje usado para recuperar
las informaciones que se nos muestran sea SQL (Structured Query Language).
Antes de ocuparnos de qu es y cmo se usa SQL intentemos entender qu se
entiende con la expresin database, que a menudo en espaol se traduce como
"base de datos".
Una base de datos es una coleccin de datos que es gestionada y organizada por un
software especfico, el DBMS (DataBase Management System, Sistema de Gestin
de DataBase). Un DBMS es sustancialmente un software que se coloca entre el
usuario y los datos como tales. Gracias a este estrato intermedio el usuario y las
aplicaciones no acceden a los datos tal y como se memorizan efectivamente, es decir
a su representacin fsica, sino que se ve slo una representacin lgica. Esto
permite un grado elevado de independencia entre las aplicaciones y la memorizacin
fsica de los datos. El administrador de la base de datos, si lo necesita, puede decidir
memorizar los datos de un modo diferente o incluso cambiar el DBMS sin que las
aplicaciones, es decir los usuarios, se resientan. Lo importante es que no cambie la
representacin lgica de esos datos, que es la nica cosa que los usuarios conocen.
Esta representacin lgica se conoce como 'Esquema de la base de datos' y es la
forma de representacin de los datos de ms bajo nivel a la que un usuario de la
base de datos puede acceder. Por ejemplo, en la Figura 1 est representada una
situacin en la que el administrador de la base de datos ha decidido que, por motivos
de eficacia, era necesario cambiar el disco en el que se haban memorizado algunos
datos, repartindolos, adems, en ms discos para permitir accesos paralelos a
subconjuntos de datos independientes. Desde el punto de vista del usuario, no ha
cambiado absolutamente nada y probablemente ni siquiera conoce el cambio que se
ha producido.

La caracterstica principal segn la cual los DBMS se clasifican es la representacin

lgica de los datos que muestran a sus usuarios. Con el paso de los aos, se han
adoptado numerosos modelos para los datos, al frente de los cuales existen diversos
tipos de bases de datos. Los ms comunes son:
Bases de datos jerrquicos: los datos se organizan en grupos unidos entre ellos
por relaciones de "posesin", en las que un conjunto de datos puede tener otros
conjuntos de datos, pero un conjunto puede pertenecer slo a otro conjunto. La
estructura resultante es un rbol de conjuntos de datos.
Bases de datos reticulares: el modelo reticular es muy parecido al jerrquico, y de
hecho nace como una extensin de este ltimo. Tambin en este modelo conjuntos
de datos estn unidos por relaciones de posesin, pero cada conjunto de datos
puede pertenecer a uno o ms conjuntos. La estructura resultante es una red de
conjuntos de datos.
Bases de datos relacionales: las bases de datos que pertenecen a esta categora
se basan en el modelo relaciones, cuya estructura principal es la relacin, es decir
una tabla bidimensional compuesta por lneas y columnas. Cada lnea, que en
terminologa relacional se llama tupla, representa una entidad que nosotros
queremos memorizar en la base de datos. las caractersticas de cada entidad estn
definidas por las columnas de las relaciones, que se llaman atributos. Entidades con
caractersticas comunes, es decir descritas por el mismo conjunto de atributos,
formarn parte de la misma relacin.
Base de datos por objetos (object-oriented): el esquema de una base de datos por

objetos est representado por un conjunto de clases que definen las caractersticas y
el comportamiento de los objetos que poblarn la base de datos. La diferencia
principal respecto a los modelos examinados hasta ahora es la no positividad de los
datos. En efecto, con una base de datos tradicional (entendiendo con este trmino
cualquier base de datos no por objetos), las operaciones que se tienen que efectuar
en los datos se les piden a las aplicaciones que los usan. Con una base de datos
object-oriented, al contrario, los objetos memorizados en la base de datos contienen
tanto los datos como las operaciones posibles con tales datos. En cierto sentido, se
podr pensar en los objetos como en datos a los que se les ha puesto una inyeccin
de inteligencia que les permite saber cmo comportarse, sin tener que apoyarse en
aplicaciones externas.
Los primeros dos tipos de bases de datos, los jerrquicos y reticulares, hoy ya casi
pertenecen a la historia de la informtica.
La mayor parte de las bases de datos que hoy se usan pertenece a la categora de
las bases de datos relacionales. Los motivos de este xito (tambin comercial) hay
que buscarlos en el rigor matemtico y en la potencialidad expresiva del modelo
relacional en que se basan, en su facilidad de uso y, ltimo pero no menos
importante, en la disponibilidad de un lenguaje de interrogacin estndar, el SQL,
que, al menos potencialmente, permite que se desarrollen aplicaciones
independientes del DBMS concreto relacional que se use.
Las bases de datos por objetos son la nueva frontera en la investigacin sobre las
bases de datos; efectivamente, sus caractersticas de extendibilidad, que se derivan
de la posibilidad de definir nuevos tipos de datos y comportamientos, las hacen
particularmente apetecibles para todas las aplicaciones que usan datos complejos,
como por ejemplo imgenes, sonidos o ambos coordinados. Por desgracia, la falta de
un modelo universalmente aceptado para los objetos, as como que no exista un
lenguaje de interrogacin estndar, hace que cada productor implemente la propia
visin especfica, a menudo absolutamente incompatible con las otras.
Recientemente, han aparecido en el mercado algunas bases de datos definidas como
object-relational, que intentan introducir en el modelo relacional las caractersticas de
extendibilidad propias de las bases de datos object-oriented.
Independientemente del tipo de base de datos, las funciones principales que se
pueden esperar de un DBMS son:
permitir el acceso a los datos a travs de un esquema conceptual, en vez de
hacerlo a travs de un esquema fsico;
compartir e integrar los datos entre aplicaciones diferentes;
controlar el acceso compartido a los datos;
garantizar la seguridad e integridad de los datos;
Gracias a estas caractersticas, las aplicaciones que se desarrollan pueden contar
con una fuente de datos segura, fiable y generalmente escalabale. Estas propiedades
son deseables para aplicaciones que usan la red Internet como infraestructura y que
por tanto tienen evidentes problemas de seguridad y de escala.

El modelo relacional

Las bases de datos relacionales son el tipo de bases de datos actualmente ms

difundido. Los motivos de este xito son fundamentalmente dos:
1. ofrecen sistemas simples y eficaces para representar y manipular los datos
2. se basan en un modelo, el relacional, con slidas bases tericas
El modelo relacional fue propuesto originariamente por E.F. Codd en un ya famoso
artculo de 1970. Gracias a su coherencia y facilidad de uso, el modelo se ha
convertido en los aos 80 en el ms usado para la produccin de DBMS.
La estructura fundamental del modelo relacional es precisamente esa, "relacin", es
decir una tabla bidimensional constituida por lneas (tuple) y columnas (atributos). Las
relaciones representan las entidades que se consideran interesantes en la base de
datos. Cada instancia de la entidad encontrar sitio en una tupla de la relacin,
mientras que los atributos de la relacin representarn las propiedades de la entidad.
Por ejemplo, si en la base de datos se tienen que representar personas, se podr
definir una relacin llamada "Personas", cuyos atributos describen las caractersticas
de las personas(Figura 2). Cada tupla de la relacin "Personas" representar una
persona concreta.

En realidad, siendo rigurosos, una relacin es slo la definicin de la estructura de la

tabla, es decir su nombre y la lista de los atributos que la componen. Cuando se
puebla con las tuplas, se habla de "instancia de relacin". Por eso, la anterior Figura
2 representa una instancia de la relacin persona. Una representacin de la
definiticn de esa relacin podra ser la siguiente:
Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil)
A continuacin, se indicarn ambas (relacin e instancia de relacin) con el trmino
"relacin", a no ser que no quede claro por el contexto a qu acepcin se refiere.
Las tuplas en una relacin son un conjunto en el sentido matemtico del trmino, es
decir una coleccin no ordenada de elementos diferentes. Para distinguir una tupla
de otra, se recurre al concepto de "llave primaria", o sea a un conjunto de atributos
que permiten identificar unvocamente una tupla en una relacin. Naturalmente, en
una relacin puede haber ms combinaciones de atributos que permitan identificar
unvocamente una tupla ("llaves candidatas"), pero entre stas se elegir una sola
para utilizar como llave primaria. Los atributos de la llave primaria no pueden asumir
el valor nulo (que significa un valor no determinado), en tanto que ya no permitiran

identificar una tupla concreta en una relacin. Esta propiedad de las relaciones y de
sus llaves primarias est bajo el nombre de integridad de las entidades (entity
integrity).
A menudo, para obtener una llave primaria "econmica", es decir compuesta de
pocos atributos fcilmente manipulables, se introducen uno o ms atributos ficticios,
con cdigos identificativos unvocos para cada tupla de la relacin.
Cada atributo de una relacin se caracteriza por un nombre y por un dominio. El
dominio indica qu valores pueden ser asumidos por una columna de la relacin. A
menudo un dominio se define a travs de la declaracin de un tipo para el atributo
(por ejemplo diciendo que es una cadena de diez caracteres), pero tambin es
posible definir dominios ms complejos y precisos. Por ejemplo, para el atributo
"sexo" de nuestra relacion "Personas" podemos definir un dominio por el cual los
nicos valores vlidos son 'M' y 'F'; o bien por el atributo "fecha_nacimiento"
podremos definir un dominio por el que se consideren vlidas slo las fechas de
nacimiento despus del uno de enero de 1960, si en nuestra base de datos no est
previsto que haya personas con fecha de nacimiento anterior a esa. El DBMS se
ocupar de controlar que en los atributos de las relaciones se incluyan slo los
valores permitidos por sus dominios. Caracterstica fundamental de los dominios de
una base de datos relacional es que sean "atmicos", es decir que los valores
contenidos en las columnas no se puedan separar en valores de dominios ms
simples. Ms formalmente se dice que no es posible tener atributos multivalor
(multivalued). Por ejemplo, si una caracterstica de las personas en nuestra base de
datos fuese la de tener uno o ms hijos, no sera posible escribir la relacin Personas
de la siguiente manera:
Personas (nombre, apellido, fecha_nacimiento, sexo, estado_civil, hijos)
En efecto, el atributo hijos es un atributo no-atmico, bien porque una persona puede
tener ms de un hijo o porque cada hijo tendr diferentes caractersticas que lo
describen. Para representar estas entidades en una base de datos relacional hay que
definir dos relaciones:
Personas (*nmero_persona, nombre, apellido, fecha_nacimiento, sexo, estado_civil)
Hijos(*nmero_persona, *nombre_apellido, edad, sexo)
En las relaciones precedentes, los asteriscos (*) indican los atributos que componen
sus llaves primarias. Ntese la introduccin en la relacin Personas del atributo
nmero_persona, a travs del cual se asigna a cada persona un identificativo
numrico unvoco que se usa como llave primaria. Estas relaciones contienen slo
atributos atmicos. Si una persona tiene ms de un hijo, stos se representarn en
tuplas diferentes de la relacin Hijos. Las diferentes caractersticas de los hijos las
representan los atributos de la relacin Hijos. La unin entre las dos relaciones est
constituida por los atributos nmero_persona que aparecen en ambas relaciones y
que permiten que se asigne cada tupla de la relacin hijos a una tupla concreta de la
relacin Personas. Ms formalmente se dice que el atributo nmero_persona de la
relacin Hijos es una llave externa (foreign key) hacia la relacin Personas. Una llave
externa es una combinacin de atributos de una relacin que son, a su vez, una llave
primaria para otra relacin. Una caracterstica fundamental de los valores presentes
en una llave externa es que, a no ser que no sean null, tienen que corresponder a
valores existentes en la llave primaria de la relacin a la que se refieren. En nuestro
ejemplo, esto significa que no puede existir en la relacin Hijos una tupla con un valor
del atributo nmero_persona sin que tambin en la relacin Personas exista una

tupla con el mismo valor para su llave primaria. Esta propiedad va bajo el nombre de
integridad referencial (referential integrity)
Una de las grandes ventajas del modelo relacional es que define tambin un lgebra,
llamada "lgebra relacional". Todas las manipulaciones posibles sobre las relaciones
se obtienen gracias a la combinacin de tan slo cinco operadores: RESTRICT,
PROJECT, TIMES, UNION y MINUS. Por comodidad, se han definido tambin tres
operadores adicionales que de todos modos se pueden obtener aplicando los cinco
fundamentales: JOIN, INTERSECT y DIVIDE. Los operadores relacionales reciben
como argumento una relacin o un conjunto de relaciones y restituyen una nica
relacin como resultado.
Veamos brevemente estos ocho operadores:
RESTRICT: restituye una relacin que contiene un subconjunto de las tuplas de la
relacin a la que se aplica. Los atributos se quedan como estaban.
PROJECT: restituye una relacin con un subconjunto de los atributos de la relacin a
la que viene aplicado. Las tuplas de la relacin resultado se componen de las tuplas
de la relacion original, de manera que siguen siendo un conjunto en sentido
matemtico.
TIME: se aplica a dos relaciones y efecta el producto cartesiano de las tuplas. Cada
tupla de la primera relacin est concatenada con cada tupla de la segunda.
JOIN: se concatenan las tuplas de dos relaciones de acuerdo con el valor de un
conjunto de sus atributos.
UNION: aplicando este operador a dos relaciones compatibles, se obtiene una que
contiene las tuplas de ambas relaciones. Dos relaciones son compatibles si tienen el
mismo nmero de atributos y los atributos correspondientes en las dos relaciones
tienen el mismo dominio.
MINUS: aplicado a dos relaciones compatibles restituye una tercera que contiene las
tuplas que se encuentran slo en la primera relacin.
INTERSECT: aplicado a dos relaciones compatibles restituye una relacin que
contiene las tuplas que existen en ambas.
DIVIDE: aplicado a dos relaciones que tengan atributos comunes, restituye una
tercera que contiene todas las tuplas de la primera relacin que se puede hacer que
correspondan con todos los valores de la segunda relacin.
En las siguientes tablas, a ttulo de ejemplo, se representan los resultados de la
aplicacin de algunos operadores relacionales a las relaciones Personas e Hijos.
Como nombres para las relaciones resultado se han utilizado las expresiones que las
producen.
Personas
nmero_persona
2
1
3

nombre
Mario

apellido fecha_nacimiento sexo stado_civil

Rossi
29/03/1965
M
Casado

Giuseppe
Russo
Alessandra Mondella

15/11/1972
13/06/1970

M
F

Soltero
Soltera

Hijos
nmero_persona nombre_apellido edad sexo

Maria Rossi

Gianni Rossi

RESTRICT (Personas)
sesso='M'
nmero_persona nombre apellido fecha_nacimiento sexo estado_civil
2
Mario
Rossi
29/03/1965
M
Casado
1

Giuseppe

Russo

15/11/1972

Soltero

PROJECT sexo (Personas)

sexo
M
F
RESTRICT (Personas)
sexo='M'
n.
nombre apellido nacimiento sexo stado_civil
nombre
edad sexo
Mario Rossi apellido 29/03/1965 M
Csado
Maria Rossi
3
F
Mario

Rossi

Apellido 29/03/1965

Casado

Gianni Rossi

Las bases de datos relacionales efectan todas las operaciones en las tablas usando
el lgebra relacional, aunque normalmente no le permiten al usuario usarla. El
usuario interacciona con la base de datos a travs de una interfaz diferente el
lenguaje SQL, un lenguaje declarativo que permite escribir conjuntos de datos. Las
instrucciones SQL vienen descompuestas por el DBMS en una serie de operaciones
relacionales.

Breve historia de SQL

La historia de SQL (que se pronuncia deletreando en ingls las letras que lo

componen, es decir "ese-cu-ele" y no "siquel" como se oye a menudo) empieza en
1974 con la definicin, por parte de Donald Chamberlin y de otras personas que
trabajaban en los laboratorios de investigacin de IBM, de un lenguaje para la
especificacin de las caractersticas de las bases de datos que adoptaban el modelo
relacional. Este lenguaje se llamaba SEQUEL (Structured English Query Language) y
se implement en un prototipo llamado SEQUEL-XRM entre 1974 y 1975. Las
experimentaciones con ese prototipo condujeron, entre 1976 y 1977, a una revisin
del lenguaje (SEQUEL/2), que a partir de ese momento cambi de nombre por
motivos legales, convirtindose en SQL. El prototipo (System R), basado en este
lenguaje, se adopt y utiliz internamente en IBM y lo adoptaron algunos de sus
clientes elegidos. Gracias al xito de este sistema, que no estaba todava
comercializado, tambin otras compaas empezaron a desarrollar sus productos
relacionales basados en SQL. A partir de 1981, IBM comenz a entregar sus
productos relacionales y en 1983 empez a vender DB2. En el curso de los aos
ochenta, numerosas compaas (por ejemplo Oracle y Sybase, slo por citar algunos)
comercializaron productos basados en SQL, que se convierte en el estndar
industrial de hecho por lo que respecta a las bases de datos relacionales.
En 1986, el ANSI adopt SQL (sustancialmente adopt el dialecto SQL de IBM) como
estndar para los lenguajes relacionales y en 1987 se transfom en estndar ISO.
Esta versin del estndar va con el nombre de SQL/86. En los aos siguientes, ste
ha sufrido diversas revisiones que han conducido primero a la versin SQL/89 y,
posteriormente, a la actual SQL/92.
El hecho de tener un estndar definido por un lenguaje para bases de datos
relacionales abre potencialmente el camino a la intercomunicabilidad entre todos los
productos que se basan en l. Desde el punto de vista prctico, por desgracia las
cosas fueron de otro modo. Efectivamente, en general cada productor adopta e
implementa en la propia base de datos slo el corazn del lenguaje SQL (el as
llamado Entry level o al mximo el Intermediate level), extendindolo de manera
individual segn la propia visin que cada cual tenga del mundo de las bases de
datos.
Actualmente, est en marcha un proceso de revisin del lenguaje por parte de los
comits ANSI e ISO, que debera terminar en la definicin de lo que en este momento
se conoce como SQL3. Las caractersticas principales de esta nueva encarnacin de
SQL deberan ser su transformacin en un lenguaje stand-alone (mientras ahora se
usa como lenguaje hospedado en otros lenguajes) y la introduccin de nuevos tipos
de datos ms complejos que permitan, por ejemplo, el tratamiento de datos
multimediales.

Una base de datos como ejemplo

Presentaremos ahora la estructura de la base de datos que se utilizar para los

ejemplos de las siguientes lecciones. No se describirn las fases de anlisis ni los
modelos conceptuales y lgicoa que han sido necesarios para alcanzar tal estructura,
desde el momento en que esto se apartara de los objetivos de este curso. La
estructura de la base de datos est representada en el diagrama relacional de la
Figura 3. Cada rectngulo representa una relacin. El nombre de la relacin est en
la seccin ms oscura de la parte alta del rectngulo. El resto del rectngulo est
subdividido en tres columnas, en las cuales estn definidas las caractersticas de los
atributos que componen la relacin. La columna central contiene los nombres de los
atributos; la de la derecha, su tipo (han sido utilizados los tipos del SQL/92), y la de la
izquierda sus propiedades, Las propiedades de los atributos se indican con las siglas
"PK" y "FK", que significan respectivamente que los correspondientes atributos
forman parte de la llave primaria de la relacin (Primary Key) o de una llave externa
(Foreign Key). Las flechas hacen converger las llaves externas con las primarias a
las que se refieren. Los nombres de los atributos en negrita indican que stos no
pueden tomar el valor NULL, o sea que no pueden ser indeterminados.

La finalidad de la base de datos consiste en contener las informaciones bibliogrficas

de un conjunto de publicaciones, a fin de poderlas consultar fcilmente y utilizarlas
para la construccin de otras bibliografas. sta se ha modelado en la falsa lnea del
sistema bibliogrfico del sistema LaTeX, para contar con un ambiente consolidado al
que referirse y facilitar la realizacin de programas de conversin entre un sistema y
otro.
El significado de las relaciones que componen la base de datos es el siguiente:
Publication: Una publicacin genrica. Normalmente, esta relacin se usa slo para
asignarles un identificativo unvoco a todas las publicaciones presentes en la base de
datos, dejando la especificacin de las dems caractersticas en relaciones
especficas para cada tipo de publicacin. Adems, se usa para implementar uniones
complejas entre las publicaciones y otras relaciones. Por ejemplo, la que existe entre
una publicacin y su autor. Gracias a la estructura adoptada, se puede contar con
publicaciones escritas de muchos autores y con autores que escriben diferentes tipos

de publicaciones.
Author: Representa al autor de una publicacin. La llave primaria est compuesta
por el identificativo de la publicacin y por el de la persona, lo que grantiza la unidad
de la asociacin entre las dos entidades.
Editor: Representa al coordinador de una publicacin. La estructura es idntica a la
de la tabla Author.
Person: Representa a una persona (por ejemplo, un autor) en la base de datos.
Actualmente, las informaciones consideradas interesantes son slo el apellido y el
nombre.
Publisher: La casa editorial de una publicacin.
Institution: La institucin (por ejemplo una universidad o una software house)
responsable de una publicacin.
Book: Un libro con una casa editorial precisa.
InBook: Una parte de un libro. La parte puede caracterizarse por un ttulo, por el
nmero del captulo o por el de la pgina. Las informaciones a propsito del libro y,
por tanto, comunes a sus diferentes partes, se memorizan en la relacin Book.
Proceedings: Las actas de un congreso o de una conferencia.
InProceedings: Una parte de las actas de un congreso. Las informaciones referidas
a la publicacin que contiene esa parte estn en la relacin Proceedings.
Article: Un artculo publicado en un peridico o en una revista.
Manual: Una publicacin de documentacin tcnica.
Techreport: Un informe tcnico publicado por una escuela u otra institucin.
Thesis: Una tesina o una tesis.
Misc: Una publicacin que no puede englobarse en ninguna de las categoras
anteriores.
No voy a explicar el significado de los atributos que componen las diferentes
relaciones, puesto que sus nombres se explican por s mismos. Slo una anotacin
sobre el atributo "pub_month": se ha definido como de tipo CHAR(3), es decir una
cadena con una longitud fija de tres caracteres que incluir las abreviaturas de los
nombres de los meses (las primeras tres letras de los nombres ingleses).
Los lazos entre las relaciones deberan ser bastante fciles de entender. Como
ejemplo para todos, usaremos el que conecta la relacin Book con la relacin
Publisher. Este lazo sirve para describir la la editorial de un libro. En la relacin Book
no estn presentes todos los datos de la editorial, sino slo un identificativo numrico
para ella. El nmero ser la llave primaria de la relacin Publisher y como tal
permitir identificar una editorial precisa. En la relacin Book el atributo publisher es

una llave externa hacia la relacin Publisher.

Una situacin ms compleja es la que afecta a las relaciones Publication, Author y
Person; efectivamente, en Author estn presentes dos llaves externas: una que
identifica la publicacin a la que la instancia de relacin se refiere, y otra que permite
remontarse a los datos de la persona que desempea el papel de autor. Se podra
preguntar cul es la utilidad de la relacin Publication y por qu no se ha establecido
directamente un nexo entre la relacin Author y las relaciones que representan los
tipos de publicacin concretos. La respuesta es que el modelo relacional no permite
hacerlo. En efecto, desde el momento en que un autor puede escribir diferentes tipos
de publicacin, el atributo pubblicationID debera ser una llave externa hacia todas
las relaciones de las publicaciones, pero esto no est permitido desde el momento en
que contradice la definicin misma de llave externa.
En las siguientes lecciones se implementar la base de datos de ejemplo usando el
lenguaje SQL estndar. El DBMS especfico usado ser PostgresSQL, pero se podr
sustituir con cualquier DBMS que soporte l'Entry level del SQL/92.

Interactuar con un DBMS

Como ya se ha dicho, la interaccin con una base de datos relacional se da

normalmente empleando instrucciones SQL. El envo de las instrucciones a la DBMS
se puede dar de dos maneras:
llamada interactiva
llamada a travs de un programa de aplicacin
En el primer caso, se usa un programa cuya finalidad consiste en recibir en input las
instrucciones SQL, transmitirlas a la DBMS y mostrar los resultados al usuario.
Normalmente, todas las DBMS ponen a disposicin un programa de tipo textual con
dichas funciones.
En el caso de PostgreSQL, la DBMS que usar para implementar la base de datos
que sirve de ejemplo, el programa se llama "psql". La sintaxis que hay que utilizar
para convocarlo en la modalidad interactiva es la siguiente:
psql [ dbname [ user ] ]
"dbname" es el nombre de la base de datos a la que se quiere acceder, mientras que
"user" es el nombre dek usuario con con el que se quiere acceder a la base de datos.
Por ejemplo, la orden:
psql mydb benfante
activa el programa psql, accediendo a la base de datos mydb como usuario benfante.
Si todo ha ido bien, en concreto si la base de datos existe y el usuario cuenta con los
permisos necesarios para entrar, psql muestra un prompt parecido al siguiente:
mydb=>
Llegados a este punto, se pueden digitar las rdenes SQL (terminndolas con un ";" o
con la meta-orden "\g" (go) para hacer que se ejecuten) y leer en la pantalla los
resultados que producen.
Normalmente, los programas como psql se pueden utilizar tambin de modo no
interactivo. Por ejemplo, invocando psql con la siguiente orden:
psql -f instrucciones.sql mydb benfante
el programa ejecuta las instrucciones SQL que estn en el archivo instrucciones.sql y
acaba inmediatamente despus. De este modo es posible automatizar operaciones
que se tienen que repetir frecuentemente o, en todo caso, que estn compuestas por
largas secuencias de rdenes SQL, sin tener que escribirlas manualmente cada vez.
En el caso en que se invoquen las instrucciones SQL a travs de un programa
aplicativo, stas se ejecutan durante la ejecucin de dicho programa, que usar los

resultados para producir su output. En esta situacin, el usuario no usa directamente

las rdenes SQL y podra incluso no saber que el programa que est utilizando
accede a una base de datos relacional: lo nico que ve es el interfaz que la aplicacin
le ofrece. Sustancialmente, tenemos dos sistemas para escribir aplicaciones de este
tipo:
usar una biblioteca que gestiones la comunicacin con la DBMS, transmita las
instrucciones SQL y nos permita manipular los resultados producidos.
Bibliotecas de este tipo son, por ejemplo, JDBC y ODBC. A menudo, los
productores de las DBMS ofrecen bibliotecas propietarias, que son especficas
para su producto. Por ejemplo, en el caso de PostgreSQL la biblioteca para el
lenguaje C se llama "libpq". Con frecuencia se intentan usar bibliotecas
propietarias porque las aplicaciones resultan absolutamente especficas
(funcionan slo con la base de datos para la que la biblioteca se ha
construido). Sin embargo, usando bibliotecas "standard", como JDBC o ODBC,
las aplicaciones funcionarn con cualquier DBMS que exponga la interfaz
solicitada por la biblioteca (a no ser que se empleen funciones especficas del
DBMS).
usar Embedded SQL (ESQL). En este caso, el cdigo SQL est englobado en
el cdigo de un lenguaje husped y se usan los mecanismos normales del
lenguaje para el paso de los parmetros y el uso de los resultados.
Normalmente, el cdigo resultante es convertido antes por un pre-procesador y
despus compilado por el compilador del lenguaje husped. Una ventaja
ulterior si se usa ESQL reside en el hecho de que existe un estndar ANSI que
describe cmo tendra que funcionar. De este modo, es posible que un
programa escrito para una determinada DBMS pueda recompilarse y funcionar
tambin para otro. PostgreSQL pone a disposicin un pre-procesador ESQL
para el lenguaje C (ecpg).
En las siguientes lecciones usaremos psql para enviar las instrucciones SQL que
implementarn, poblarn e interrogarn a la base de datos ejemplificada. En la ltima
leccin, se presentar, sin embargo, un applet Java que emplear la biblioteca JDBC
para consultar la base de datos bibliogrfica.

Crear la base de datos

Una base de datos en un sistema relacional est compuesta por un conjunto de

tablas, que corresponden a las relaciones del modelo relacional. En la terminologa
usada en SQL no se alude a las relaciones, del mismo modo que no se usa el
trmino atributo, pero s la palabra columna, y no se habla de tupla, sino de lnea. A
continuacin se usarn indistintamente ambas terminologas, por lo que tabla estar
en lugar de relacin, columna en el de atributo y lnea en el de tupla, y viceversa.
Prcticamente, la creacin de la base de datos consiste en la creacin de las tablas
que la componen. En realidad, antes de poder proceder a la creacin de las tablas,
normalmente hay que crear la base de datos, lo que a menudo significa definir un
espacio de nombres separado para cada conjunto de tablas. De esta manera, para
una DBMS se pueden gestionar diferentes bases de datos independientes al mismo
tiempo sin que se den conflictos con los nombres que se usan en cada una de ellas.
El sistema previsto por el estndar para crear los espacios separados de nombres
consiste en usar las instrucciones SQL "CREATE SCHEMA". A menudo, dicho
sistema no se usa (o por lo menos no con los fines y el significado previstos por el
estndar), pero cada DBMS prev un procedimiento propietario para crear una base
de datos. Normalmente, se ampla el lenguaje SQL introduciendo una instruccin no
prevista en el estndar: "CREATE DATABASE".
La sintaxis empleada por PostgreSQL, pero tambin por las DBMS ms difundidas,
es la siguiente:
CREATE DATABASE nombre_base de datos
Con PostgreSQL est a disposicin una orden invocable por shell Unix (o por shell
del sistema usado), que ejecuta la misma operacin:
createdb nombre_base de datos
Para crear nuestra base de datos bibliogrfica, usaremos pues la orden:
createdb biblio
Una vez creada la base de datos, se pueden crear las tablas que la componen. La
instruccin SQL propuesta para este fin es:
CREATE TABLE nombre_tabla (
nombre_columna tipo_columna [ clusula_defecto ] [ vnculos_de_columna ]
[ , nombre_columna tipo_columna [ clusula_defecto ] [ vnculos_de_columna ] ... ]
[ , [ vnculo_de tabla] ... ] )
nombre_columna: es el nombre de la columna que compone la tabla. Sera mejor
no exagerar con la longitud de los identificadores de columna, puesto que SQL Entry
Level prev nombres con no ms de 18 caracteres. Consltese, de todos modos, la
documentacin de la base de datos especfica. Los nombres tienen que comenzar
con un carcter alfabtico.
tipo_columna: es la indicacin del tipo de dato que la columna podr contener. Los

principales tipos previstos por el estndar SQL son:

CHARACTER(n)
Una cadena de longitud fija con exactamente n caracteres. CHARACTER se
puede abreviar con CHAR
CHARACTER VARYING(n)
Una cadena de longitud variable con un mximo de n caracteres.
CHARACTER VARYING se puede abreviar con VARCHAR o CHAR VARYING.
INTEGER
Un nmero estero con signo. Se puede abreviar con INT. La precisin, es decir
el tamao del nmero entero que se puede memorizar en una columna de este
tipo, depende de la implementacin de la DBMS en cuestin.
SMALLINT
Un nmero entero con signo y una precisin que no sea superior a INTEGER.
FLOAT(p)
Un nmero con coma mvil y una precisin p. El valor mximo de p depende
de la implementacin de la DBMS. Se puede usar FLOAT sin indicar la
precisin, empleando, por tanto, la precisin por defecto, tambin sta
dependiente de la implementacin. REAL y DOUBLE PRECISION son
sinnimo para un FLOAT con precisin concreta. Tambin en este caso, las
precisiones dependen de la implementacin, siempre que la precisin del
primero no sea superior a la del segundo.
DECIMAL(p,q)
Un nmero con coma fija de por lo menos p cifras y signo, con q cifras
despus de la coma. DEC es la abreviatura de DECIMAL. DECIMAL(p) es una
abreviatura de DECIMAL(p,0). El valor mximo de p depende de la
implementacin.
INTERVAL
Un periodo de tiempo (aos, meses, das, horas, minutos, segundos y
fracciones de segundo).
DATE, TIME y TIMESTAMP
Un instante temporal preciso. DATE permite indicar el ao, el mes y el da. Con
TIME se pueden especificar la hora, los minutos y los segundos. TIMESTAMP
es la combinacin de los dos anteriores. Los segundos son un nmero con
coma, lo que permite especificar tambin fracciones de segundo.
clusula_defecto: indica el valor de defecto que tomar la columna si no se le
asigna uno explcitamente en el momento en que se crea la lnea. La sintaxis que hay
que usar es la siguiente:
DEFAULT { valor | NULL }
donde valor es un valor vlido para el tipo con el que la columna se ha definido.

vnculos_de_columna: son vnculos de integridad que se aplican a cada atributo

concreto. Son:
NOT NULL, que indica que la columna no puede tomar el valor NULL.
PRIMARY KEY, que indica que la columna es la llave primaria de la tabla.
una definicin de referencia con la que se indica que la columna es una llave
externa hacia la tabla y los campos indicados en la definicin. La sintaxis es la
siguiente:
REFERENCES nombre_tabla [ ( columna1 [ , columna2 ... ] ) ]
[ ON DELETE { CASCADE | SET DEFAULT | SET NULL } ]
[ ON UPDATE { CASCADE | SET DEFAULT | SET NULL } ]
Las clusulas ON DELETE y ON UPDATE indican qu accin hay que ejecutar
en el caso en que una tupla en la tabla referenciada sea eliminada o
actualizada. De hecho, en dichos casos en la columna referenciante (que es la
que se est definiendo) podra haber valores inconsistentes. Las acciones
pueden ser:
CASCADE: eliminar la tupla que contiene la columna referenciante (en
el caso de ON DELETE) o tambin actualizar la columna referenciante
(en el caso de ON UPDATE).
SET DEFAULT: asignar a la columna referenziante su valor de defecto.
SET NULL: asignar a la columna referenciante el valor NULL.
un control de valor, con el que se permite o no asignar un valor a la columna
en funcin del resultado de una expresin. La sintaxis que se usa es:
CHECK (expresin_condicional)
donde expresin_condicional es una expresin que ofrece verdadero o falso.
Por ejemplo, si estamos definiendo la columna COLUMNA1, con el siguiente
control:
CHECK ( COLUMNA1 < 1000 )
en dicha columna se podrn incluir slo valores inferiores a 1000.
vnculo_de_tabla: son vnculos de integridad que se pueden referir a ms columnas
de la tabla. Son:
la definicin de la llave primaria:
PRIMARY KEY ( columna1 [ , columna2 ... ] ) Vase que en este caso, a
diferencia de la definicin de la llave primaria como vnculo de columna, sta
se puede formar con mas de un atributo.
las definiciones de las llaves externas:
FOREIGN KEY ( columna1 [ , columna2 ... ] ) definiciones_de_referencia

La definicin_de_referencia tiene la misma sintaxis y significado que la que

puede aparecer como vnculo de columna.
un control de valor, con la misma sintaxis y significado que el que se puede
usar como vnculo de columna.
Para aclarar mejor el uso de la instruccin CREATE TABLE, veamos algunas rdenes
que implementan la base de datos bibliogrfica ejemplificada.
CREATE TABLE Publication (
ID INTEGER PRIMARY KEY,
type CHAR(18) NOT NULL
);
La instruccin anterior crea la tabla Publication, formada por las dos columna ID de
tipo INTEGER, y type de tipo CHAR(18). ID es la llave primaria de la relacin. En el
atributo type hay un vnculo de no nulidad.
CREATE TABLE Book (
ID INTEGER PRIMARY KEY REFERENCES Publication(ID),
title VARCHAR(160) NOT NULL,
publisher INTEGER NOT NULL REFERENCES Publisher(ID),
volume VARCHAR(16),
series VARCHAR(160),
edition VARCHAR(16),
pub_month CHAR(3),
pub_year INTEGER NOT NULL,
note VARCHAR(255)
);
Crea la relacin Book, formada por nueve atributos. La llave primaria es el atributo ID,
que es tambin una llave externa hacia la relacin Publication. Sobre los atributos
title, publisher y pub_year hay vnculos de no nulidad. Adems, el atributo publisher
es una llave externa hacia la tabla Publisher.
CREATE TABLE Author (
publicationID INTEGER REFERENCES Publication(ID),
personID INTEGER REFERENCES Person(ID),
PRIMARY KEY (publicationID, personID)
);
Crea la relacin Author, compuesta por dos atributos: publicationID y personID. La
llave primaria en este caso est formada por la combinacin de los dos atributos,
como est indicado por el vnculo de tabla PRIMARY KEY. PublicationID es una llave
externa hacia la relacin Publication, mientras que personID lo es hacia la relacin
Person.
El archivo create_biblio.sql contiene todas las rdenes necesarias para crear la
estructura de la base de datos bibliogrfica ejemplificada.
NOTA SOBRE POSTGRESQL
En PotgreSQL, por lo menos hasta la versin 6.5.1, no se han implementado todava
los vnculos sobre las llaves externas. El parser acepta, de todos modos, las sintaxis

SQL que le afectan, y por tanto los constructos FOREIGN KEY y REFERENCES no
producen un error, sino slo un warning.

Poblar la base de datos

Con la expresin "poblacin de la base de datos" se entiende la actividad de inclusin de los datos
dentro de ella. En una base de datos relacional esto corresponde a la creacin de las lneas que
componen las tablas que constituyen la base de datos. Normalmente, la memorizacin de una
informacin concreta corresponde a la inclusin de una o ms lneas en una o ms tablas de la base
de datos. Tmese, por ejemplo, la siguiente informacin bibliogrfica:
M. Agosti, L. Benfante, M. Melucci. OFAHIR: "On-the-Fly" Automatic Authoring of Hypertexts for
Information Retrieval. In S. Spaccapietra, F. Maryansky (Eds), Searching for Semantics: Data Mining,
Reverse Engineering. Proc. of the 7th IFIP 2.6 Working Conference on Database Semantics (DS-7),
Leysin, Switzerland, October 1997, 129-154.
Suponiendo que en la base de datos no est ya presente ninguna de las informaciones que le afectan
(como por ejemplo alguno de los autores o las actas del congreso al que se refiere), su inclusin en
nuestra base de datos de ejemplo corresponde a la inclusin de las siguientes lneas:
cinco lneas en la tabla Person, que corresponden a cada uno de los autores y de los
coordinadores;
una lnea en la tabla Institution;
dos lneas en la tabla Publication: una para las actas del congreso y una para el artculo
contenido en esas actas;
una lnea en la tabla Proceedings;
una lnea en la taba InProceedings;
tres lneas en la tabla Author, una para cada autor de la publicacin.
dos lneas en la tabla Editor, una para cada coordinador de la publicacin.
El orden de las operaciones anteriores no es puramente casual; de hecho, la insercin de las
lneas tiene que hacerse de modo que se respeten los vnculos impuestos en las tablas. Por
ejemplo, dado que no podr existir una llave externa sin que antes se haya incluido la lnea a
la que se refiere, antes de poder meter una lnea en la tabla InProceedings se tendr que
haber puesto la lnea correspondiente en la tabla Proceedings. En el caso en que un vnculo
sea violado, la DBMS impedir la operacin de inclusin abortndola. Vase la leccin anterior
(Crear la base de datos) para la descripcin de los vnculos que se les pueden imponer a una
tabla y a sus columnas.
La instruccin SQL que lleva a cabo la inclusin de una nueva lnea en una tabla es INSERT.
La sintaxis con la que sta se usa comunmente es:
INSERT INTO nombre_tabla [ ( lista_campos ) ]
VALUES ( lista_valores )
nombre_tabla es el nombre de la tabla en la que se tiene que incluir la nueva lnea.
lista_campos es la lista de los nombres de los campos a los que hay que asignar un valor,
separados entre s por una coma. Los campos no incluidos en la lista tomarn su valor por
defecto o NULL si no lo tienen por defecto. Es un error no incluir en la lista un campo que no
tenga un valor por defecto y que no pueda tomar el valor NULL. En el caso en que no se

especifique la lista, habr que especificar los valores de todos los campos de la tabla.
lista_valores es la lista de los valores que se les darn a los campos de la tabla en el orden y
nmero especificados por la lista_campos o en la de la definicin de la tabla (si no se
especifica lista_campos). Los valores pueden ser una expresin escalar del tipo apropiado
para el campo o las keyword DEFAULT o NULL, si el campo prev un valor por defecto o
admite el valor NULL.
El ejemplo anterior de inclusin se ejecuta a travs de las siguientes instrucciones SQL:
INSERT INTO Person VALUES ( 1, 'Agosti', 'Maristella' );
INSERT INTO Person VALUES ( 2, 'Benfante', 'Lucio' );
INSERT INTO Person VALUES ( 3, 'Melucci', 'Massimo' );
INSERT INTO Person VALUES ( 4, 'Spaccapietra', 'S.' );
INSERT INTO Person VALUES ( 5, 'Maryansky', 'F.' );
INSERT INTO Institution ( ID, name, city, country )
VALUES ( 1, '7th IFIP 2.6 Working Conference on Database Semantics (DS-7)',
'Leysin', 'Switzerland' );
INSERT INTO Publication VALUES ( 1, 'Proceedings' );
INSERT INTO Publication VALUES ( 2, 'InProceedings' );
INSERT INTO Proceedings ( ID, title, organization, pub_month, pub_year )
VALUES ( 1, 'Searching for Semantics: Data Mining, Reverse Engineering',
1, 'Oct', 1997 );
INSERT INTO InProceedings ( ID, proceedingsID, title, pages )
VALUES ( 2, 1,
'OFAHIR: "On-the-Fly" Automatic Authoring of Hypertexts for Information Retrieval', '129-154' );
INSERT INTO Author VALUES ( 2, 1 );
INSERT INTO Author VALUES ( 2, 2 );
INSERT INTO Author VALUES ( 2, 3 );
INSERT INTO Editor VALUES ( 1, 4 );
INSERT INTO Editor VALUES ( 1, 5 );
Otra forma bastante usada de la instruccin INSERT sigue la siguiente sintaxis:
INSERT INTO nombre_tabla [ ( lista_campos ) ]
instruccin_select
La nica diferencia con la sintaxis anterior consiste en la sustitucin de la clusula VALUES
por la instruccin SELECT.
La instruccin SELECT se examinar con detalle en la siguiente leccin (Interrogar a la base
de datos). Por el momento, es suficiente saber que SELECT permite extraer de las tablas de la
base de datos datos que se organizan en una nueva relacin.
La anterior instruccin INSERT permite incluir en la tabla y en los campos especificados datos
provenientes de otras tablas. Obviamente, para que la instruccin se ejecute con xito, los
datos producidos por la instruccin SELECT tendrn que ser compatibles con los vnculos y
los dominios de los campos de la tabla en la que se esta efectuando la insercin.
En el archivo poblad_biblio.sql estn presentes las instrucciones SQL que pueblan la base de
datos bibliogrfica con los datos que se usarn en los ejemplos de las siguientes lecciones.

Interrogar a la base de datos

En la leccin anterior se han examinado los constructos que el lenguaje SQL pone a
disposicin para incluir los datos en una base de datos relacional. Vamos a ver ahora, sin
embargo, las instrucciones necesarias para extraer de ella los datos que nos interesen. La
instruccin SQL que se propone para dicho fin es SELECT. Desde el momento en que la
interrogacin es quiz la funcin ms usada de una base de datos, las opciones de la
instruccin SELECT son numerosas y a veces bastante complicadas. Por esta razn
vamos a describirlas simplificadas, utilizando ejemplos para la presentacin de las
caractersticas ms complejas, en concreto las que se refieren a la especificacin de las
expresiones condicionales.
La sintaxis con que la instruccin SELECT se tiene que usar es la siguiente:
SELECT [ ALL | DISTINCT ] lista_elementos_seleccin
FROM lista_referencias_tabla
[ WHERE expresin_condicional ]
[ GROUP BY lista_columnas ]
[ HAVING expresin_condicional ]
[ ORDER BY lista_columnas ]
La instruccin SELECT produce una tabla que se obtiene aplicando el siguiente
procedimiento (por lo menos desde el punto de vista lgico, cada DBMS optimiza la
ejecucin de las interrogaciones segn las propias estrategias):
produce una tabla que se obtiene como producto cartesiano de las tablas
especificadas en la clusula FROM. Cada elemento de la lista_referencias_tabla
sigue la siguiente sintaxis:
referencia_tabla [ [ AS ] alias_tabla ]
La referencia puede ser el nombre de una tabla o una expresin (puesta entre
parntesis) cuyo resultado es una tabla, y por lo tanto incluso otra SELECT. El alias
es un nombre que sirve para indicar brevemente una referencia de tabla. En el caso
en que la referencia de tabla sea una expresin, es obligatorio especificar un alias.
de la tabla anterior elimina todas las lneas que no satisfacen la expresin
condicional (es decir las lneas por las cuales la expresin condicional devuelve falso
como resultado) de la clusula WHERE.
(si est presente la clusula GROUP BY) las lneas de la tabla resultante del paso 2
se reagrupan segn los valores presentes en las columnas especificadas en la
clusula GROUP BY. Lneas con valores iguales se unen en una nica lnea. Las
columnas no comprendidas en la clusula tienen que comprender expresiones con
funciones de agregacin (como por ejemplo AVG, que calcula la media) que, por
tanto, se calculan produciendo un nico valor para cada grupo.
(si est presente la clusula HAVING) del resultado del punto 3 se eliminan las

lneas que no satisfacen la expresin condicional de la clusula HAVING.

Se claculan las columnas presentes en la clusula SELECT (las de la
lista_elementos_seleccin). En concreto, se calculan las columnas con las funciones
de agregacin que derivan del reagrupamiento que se ha producido en el punto 3.
Cada elemento de la lista_elementos_seleccin sigue la siguiente sintaxis:
expresin_escalar [ [ AS ] alias_columna ]
Una expresin escalar es una expresin que produce como resultado un valor
escalar. Los tipos de datos escalares del lenguaje SQL son principalmente los
descritos en la leccin 6 (Crear la base de datos), excepto INTERVAL, DATE, TIME y
TIMESTAMP.
Las expresiones escalares de los elementos de SELECT normalmente afectan a las
columnas de la tabla resultante del punto 4. En el caso en que se den
ambigedades, por la presencia de columnas con los mismos nombres en dos o
ms tablas incluidas en la clusula FOR, se pueden resolver prefijando el nombre o
el alias de la columna con el nombre o el alias de la tabla, separados por un punto.
Por ejemplo, T.C indica la columna C de la tabla T. El alias de columna es el nombre
que se le da a la columna.
Toda la lista de las columnas de una tabla puede especificarse usando el carcter '*'.
(si est presente la opcin DISTINCT) se eliminan las lneas que resultan
duplicadas. En el caso en que no estn presentes ni ALL ni DISTINCT, se asume
ALL.

(si est presente la clusula ORDER BY) las lneas de la tabla se ordenan segn
los valores presentes en las columnas especificadas en la clusula. La sintaxis que
hay que usar es la siguiente:
ORDER BY nombre_columna [ ASC | DESC ] [ , nombre_columna [ ASC | DESC ] ...
]
El orden por defecto es ascendente. En el caso en que se quiera efectuar el decreciente
hay que especificar la opcin DESC. Si no se especifica la clusula ORDER BY, hay que
considerar la tabla sin ningn orden; de hecho, para la definicin de relacin del modelo
relacional, las lneas de la tabla forman un conjunto: en el sentido matemtico y para los
elementos de un conjunto no se ha definido ninguna propiedad de orden. En la prctica, sin
embargo, el orden que se obtiene no especificando la clusula de orden es casi siempre el
que refleja su memorizacin fsica y por tanto, a menudo, al que se debe que las lneas
hayan sido incluidas en la tabla.
La secuencia de operaciones que acabamos de presentar hay que considerarla vlida slo
desde el punto de vista conceptual. Efectivamente, no est escrito que se ejecuten
exactamente de este modo y en este orden, sobre todo desde el momento en que cada
DBMS optimizar las interrogaciones segn las estrategias ms oportunas.
Examinaremos ahora algunos ejemplos de la instruccin SELECT. Se supone que los datos
presentes en la base de datos de ejemplo son slo los que se han incluido gracias al
archivo [poblad_biblio.sql] presentado en la leccin 7 (Poblar la base de datos). En caso
contrario, las interrogaciones ofrecern resultados diferentes.

EJEMPLO 1
SELECT surname FROM Person
ORDER BY surname
Extrae de la tabla Person los apellidos y los ordena alfabticamente. En nuestro caso, el
resultado es el siguiente:
surname
-------------------------------Agosti
Batini
Bayer
Benfante
Carey
Cochowsky
DeWitt
Kim
Knuth
Lenzerini
Maryansky
McCreight
McGill
Melucci
Richardson
Salton
Santucci
Shekita
Spaccapietra
de Petra
Vase el orden errado de la ltima lnea, debido a que se ha usado el carcter ASCII
minsculo.
La query anterior devolvera lneas duplicadas en el caso en que en la tabla estuviesen
presentes personas con el mismo apellido. Para evitarlo hay que especificar la opcin
DISTINCT:
SELECT DISTINCT surname FROM Person
ORDER BY surname
ESEMPIO 2
SELECT * FROM Person
WHERE surname LIKE 'B%'

Produce una tabla que tiene todas las columnas de la tabla Person. Las lneas se filtran
para que estn presentes slo las que tienen el apellido que empieza con el carcter 'B'. El
operador LIKE permite una comparacin entre cadenas de caracteres usando pattern
construidos con los caracteres '%' e '_'. El primero sustituye un nmero no precisado de
caracteres (tambin 0), mientras que el segundo sustituye uno solo.
ESEMPIO 3
SELECT PUB.*, PER.surname AS S, PER.given_names
FROM Publication PUB, Author AUT, Person PER
WHERE PUB.ID = AUT.publicationID
AND AUT.personID = PER.ID
AND PUB.type = 'Book'
ORDER BY S

En este caso, la tabla resultante contiene todas las columnas de la tabla Publication
(indicada con el alias PUB definido en la clusula FROM) y las columnas surname y
given_names de la tabla Person. La clusula FROM genera el producto cartesiano de las
tablas Publication, Author y Person, de las que se seleccionan slo las lneas en que el
identificativo de la publicacin y el del autor se corresponden. Adems, se limita a
considerar slo las publicaciones del tipo 'Book'. Para acabar, la tabla se ordena segn los
apellidos del autor, indicado mediante el alias S, definido en la clusula SELECT.
ESEMPIO 4
SELECT title, volume, pub_year
FROM Book
WHERE ID IN
( SELECT PUB.ID
FROM Publication PUB, Author AUT, Person PER
WHERE PUB.ID = AUT.publicationID
AND AUT.personID = PER.ID
AND PUB.type = 'Book'
AND PER.surname = 'Knuth' )

En este ejemplo, se ve el uso de una expresin condicional que contiene el operador IN,
que devuelve el valor verdadero si el valor del operando a su izquierda est incluido en la
tabla resultado de la expresin a su derecha. La query entre parntesis produce una tabla
de una nica columna, que contiene los identificativos de las publicaciones del tipo 'Book'
de las que Knuth es autor. La query ms externa extrae, por tanto, de la tabla Book las
informaciones de los libros con esos identificativos.
EJEMPLO 5
SELECT COUNT(*) FROM Publication
count
----12
Cuenta el nmero de lneas presentes en la tabla Publication.
ESEMPIO 6
SELECT type, COUNT(ID) FROM Publication
GROUP BY type

Cuenta el nmero de publicaciones presentes en la base de datos subdividindolas por

tipos.
Las funciones de agregacin previstas por el estndar SQL son COUNT, SUM, AVG, MAX y
MIN, las cuales calculan respectivamente los nmeros, la suma, la media aritmtica, el
mximo y el mnimo de los valores escalares presentes en la columna a la que se aplican.

Actualizar la base de datos

Normalmente, las informaciones presentes en una base de datos no son estticas, sino que
evolucionan en el tiempo. Existe, por tanto, la necesidad no slo de aadir nuevos datos, sino de
modificar los que estn ya incluidos en las tablas de la base de datos. Las instrucciones SQL que se
usan para este fin son UPDATE y DELETE. La primera modifica los valores presentes en una o ms
columnas de una o ms lneas de una tabla. La segunda elimina una o ms lneas de una tabla.
La sintaxis de UPDATE es la siguiente:
UPDATE nombre_tabla
SET lista_asignaciones
[ WHERE expresin_condicional ]
Las asignaciones se especifican del modo:
nombre_columna = expresin_escalar
La instruccin UPDATE actualiza las columnas de la tabla que se han especificado en la clusula SET,
utilizando los valores que son calculados por las correspondientes expresiones escalares. Si se
expresa tambin la clusula WHERE, se actualizan slo las lneas que satisfacen la expresin
condicional. Vase que la expresin escalar usada para actualizar una columna puede ser tambin el
resultado de una query escalar, es decir una query que devuelve una sola lnea y una sola columna.
Veamos un ejemplo:
UPDATE Person
SET given_names = 'Stefano'
WHERE surname = 'Spaccapietra'
La instruccin anterior cambia el valor de la columna given_name de la tabla Person en las lneas (en
nuestro caso es una sola) en que la columna surname tiene valor 'Spaccapietra'.
La sintaxis de DELETE es:
DELETE FROM nombre_tabla
[ WHERE expresin_condicional ]
La instruccin delete elimina de una tabla todas las lneas que satisfacen la expresin condicional de
la clusula WHERE. Si WHERE no se especifica, se cancelan todas las lneas de la tabla.
Si en la definicin de la tabla se han especificado las clusulas ON UPDATE u ON DELETE, en el
momento en que se ejecutan estas operaciones tambin se ejecutan las que haban estado previstas
en las columnas referenciadas (CASCADE, SET DEFAULT o SET NULL).

Modificar la estructura de la base de datos

En el curso de la leccin anterior, se ha visto cmo modificar los datos ya presentes

en la base de datos. A veces, sin embargo, no basta con modificar los datos, sino que
es necesario actualizar la estructura misma de la base de datos para conseguir que
se puedan representar nuevas informaciones. Desde el momento en que la
estructura de la base de datos se da sustancialmente por la unin de las tablas que la
componen, su actualizacin corresponde a la eliminacin de tablas o al cambio de
sus caractersticas.
Para eliminar una tabla de una base de datos la orden SQL que hay que usar es
DROP TABLE:
DROP TABLE nombre_tabla { RESTRICT | CASCADE }
nombre_tabla es el nombre de la tabla que tiene que se eliminada.
Si se especifica la clusula CASCADE, se eliminan automticamente los vnculos de
integridad y las vistas (view) en que la tabla est implicada. Y viceversa: si se
especifica la clusula RESTRICT y existen vnculos de integridad o vistas que se
refieran a la tabla, la operacin fracasa.
Por ejemplo, se han definido las dos siguientes tablas:
CREATE TABLE Prueba1 (
Id INTEGER PRIMARY KEY,
Nombre VARCHAR(50))
CREATE TABLE Prueba2 (
Id INTEGER PRIMARY KEY,
Nombre VARCHAR(50),
toPrueba1 INTEGER REFERENCES Prueba1(Id))
Si se quiere eliminar la tabla Prueba1, la instruccin:
DROP TABLE Prueba1 RESTRICT
fracasar desde el momento en que existe un vnculo de integridad que liga una llave
externa de la tabla Prueba2 con la tabla Prueba1.
Sin embargo, la instruccin:
DROP TABLE Prueba1 CASCADE
se ejecutar con xito y producir tambin la eliminacin del vnculo de integridad
referencial presente en la tabla Prueba2.
En el caso en que se quiera modificar una tabla existente en la base de datos, la
instruccin que se tiene que usar es ALTER TABLE. Desde el momento en que la
sintaxis de esta instruccin resulta ms bien complicada, se explicar
descomponindola de acuerdo a las funciones que se quieren obtener:
Adicin de una nueva columna a la tabla

ALTER TABLE nombre_tabla ADD [ COLUMN ] definicin_columna

nombre_tabla es el nombre de la tabla que se quiere modificar.
La definicin de la columna sigue la misma sintaxis que se ha visto en la leccin
"Crear la base de datos" en la explicacin de la instruccin CREATE TABLE. Por lo
tanto, habr que especificar el nombre de la columna, su tipo y, eventualmente, su
valor por defecto y los vnculos impuestos en la columna.
La la palabra clave COLUMN se puede omitir (aqu y en todos los casos sucesivos).
Eliminacin de una columna de la tabla
ALTER TABLE nombre_tabla
DROP [ COLUMN ] nombre_columna { RESTRICT | CASCADE }
nombre_columna es el nombre de la columna que se quiere eliminar. Las clusulas
RESSTRIC y CASCADE se comportan exactamente como en la instruccin DROP
TABLE que se ha visto anteriormente.
La instruccin fallar, adems de en los casos ya vistos para RESTRICT, si se intenta
eliminar una columna que es la nica de una tabla.
Cambio del valor por defecto de una columna
ALTER TABLE nombre_tabla
ALTER [ COLUMN ] nombre_columna { SET clusula_defecto | DROP DEFAULT }
La sintaxis y el significado de la clusula que define el nuevo valor de defecto son
idnticos a los de la clusula_defecto que se usa en la orden CREATE TABLE.
Eliminacin de un vnculo de la tabla
ALTER TABLE nombre_tabla
DROP CONSTRAINT nombre_vnculo { RESTRICT | CASCADE }
Elimina el vnculo identificado por el nombre especificado. La operacin falla si se ha
especificado la clusula RESTRICT y existen otros vnculos que dependen del que se
intenta eliminar. Especificando la clusula CASCADE la operacin se completar
siempre con xito, borrando adems los vnculos que dependen de que se ha
eliminado.
A menudo se quiere eliminar un vnculo al que no se le ha dado un nombre
explcitamente, poniendo antes de la definicin del vnculo la clusula opcional
[CONSTRAINT nombre_vnculo]. En ese caso, desde el momento que la DBMS
habr asignado de todos modos un nombre al vnculo para poderlo identificar, ser
necesario interrogar a las tablas de sistema de la DBMS y que nos d su nombre. La
particular interrogacin solicitada depende de la DBMS especfica que se haya
usado.
Adicin de un vnculo a la tabla
ALTER TABLE nombre_columna
ADD vnculo_de_tabla
La sintaxis que hay que usar para la definicin del vnculo es la misma que se usa en
la orden CREATE TABLE para los vnculos de tabla.

Utilizacin multiusuario de una base de datos

Hasta ahora hemos examinado las caractersticas del lenguaje SQL que se refieren a la definicin y a
la manipulacin de los datos presentes en una base de datos, sin preocuparnos del hecho de que
normalmente el acceso a tales datos se produce al mismo tiempo por parte de muchos usuarios.
Los mecanismo que hay que tener en cuenta para este mtodo de acceso se refieren principalmente a
la seguridad de los datos, la gestin de las transacciones y la posibilidad de definir las vistas en las
tablas de la base de datos.
1. Seguridad
La ejecucin de una operacin en los datos de la base de datos por parte de un usuario est
supeditada a la posesin por parte del usuario de los privilegios necesarios para la operacin concreta
ejecutada en el conjunto de datos especfico.
En general, los privilegios se asignan del siguiente modo:
Un usuario que crea una tabla o cualquier otro objeto de la base de datos es el propietario y se
le garantizan automticamente todos los privilegios aplicables a dicho objeto, con la
posibilidad de darles tambin a otros usuarios dichos privilegios (privilegio de concesin).
Un usario que tenga un privilegio y posea adems sobre l el privilegio de concesin puede
asignarle tal pricilegio a otro usuario y pasarle tambin el privilegio de concesin.
Los privilegios los concede quien tiene el permiso (es decir el propietario del objeto y quien
tiene el privilegio de concesin) mediante la orden GRANT, y los revoca mediante la orden
REVOKE.
La sintaxis de la orden GRANT es la siguiente:
GRANT lista_privilegios ON objeto TO lista_usuarios [ WITH GRANT OPTION ]
Esto asigna al usuario los privilegios presentes en la lista_privilegios sobre el objeto
especificado.
Los privilegios asignables son los siguientes (con sus respectivas sintaxis):
USAGE
Privilegio para usar un dominio especfico u otro objeto de la base de datos.
SELECT
Privilegio para acceder a todas las columnas de una tabla o de una vista.
INSERT [ (nombre_columna) ]
Si se especifica la opcin nombre_columna, es el privilegio para incluir valores en la columna
indicada de una tabla o de una vista. Sin el nombre_columna es el privilegio para aadir
valores a todas las columnas, incluidas las que se aadirn a continuacin.
UPDATE [ (nombre_columna) ]
Si se especifica la opcin nombre_columna, se trata del privilegio para actualizar el valor en la
columna indicada de una tabla o de una vista. Si no, permite actualizar el valor de todas las
columnas, incluidas las que se aadirn a continuacin.
DELETE
Privilegio para eliminar lneas de una tabla o de una vista.
REFERENCES [ (nombre_columna) ]

Si se especifica la opcin nombre_columna, es el privilegio de referirse a la columna indicada

de una tabla o de una vista en la definicin de un vnculo de integridad. Sin la opcin, concede
dicho privilegio para todas las columnas, incluidas las que se aaden a continuacin.
El objeto al que se refiere el privilegio es generalmente una tabla o una vista. La sintaxis para
su especificacin es en ese caso:
[TABLE] nombre_tabla
En el caso de otros objetos, sigue la sintaxis:
tipo_objeto nombre_objeto
donde tipo_objeto puede ser DOMAIN, CHARACTER SET, COLLATION o TRANSLATION
(vase C.J. Date - "A Guide to The SQL Standard" para una explicacin de tales objetos).
En el caso de objetos que no sean tablas o vistas, el nico privilegio aplicable es el de
USAGE.
La lista_usuarios es una lista de identificativos de usuarios o grupos de usuarios. Puede
usarse tambin la palabra clave PUBLIC, que indica todos los usuarios y los grupos coocidos
en el sistema.
Si est presente la opcin [ WITH GRANT OPTION ], se asigna adems el privilegio de
concesin, que permite a los usuarios transferir ulteriormente los privilegios que se les han
asignado.
Por ejemplo:
GRANT SELECT, INSERT, UPDATE(nombre) ON persona TO benfante WITH GRANT
OPTION
le asigna al usuario benfante los privilegios de SELECT e INSERT sobre todas las columnas
de la tabla persona y el de UPDATE sobre la columna nombre de dicha tabla. Se les garantiza,
adems, el privilegio de asignar estos permisos a otros usuarios.
Para quitarles los privilegios a los usuarios se usa REVOKE:
REVOKE [ GRANT OPTION FOR ] lista_privilegios ON objeto FROM lista_usuarios
{ RESTRIC | CASCADE }
lista_privilegios, objeto y lista_usuarios tienen el mismo significado que las correspondientes
opciones de GRANT. La opcin GRANT OPTION FOR revoca el privilegio de concesin. Si se
especifica la clusula RESTRICT, la orden REVOKE puede fallar si el usuario al que se le han
revocado los privilegios se los ha concedido posteriormente a otros. Si est presente la
clusula CASCADE, la instruccin se completar siempre con xito y se revocarn tambin los
privilegios de esos usuarios y de todos aquellos a quienes a su vez se les han concedido (...y
as hasta que no haya ms privilegios "abandonados", es decir concedidos sin que quien los
ha concedido los posea todava). Se destruirn, adems, los objetos de la base de datos
construidos gracias a dichos permisos.
2. Gestin de las transacciones
Las transacciones SQL son conjuntos de instrucciones que hay que tratar como unidades
atmicas, es decir no descomponibles en las instrucciones individuales de las que estn
formadas. Gracias a esta atomicidad, las transacciones permiten que se ejecuten operaciones
complejas en la base de datos, manteniendo la integridad. Efectivamente, una transaccin se
ejecuta con xito si y slo si todas las operaciones que la componen terminan con xito. Si no,
es decir si una de las operaciones falla, o si la transaccin se anula explcitamente, todas las
operaciones anteriores son tambin anuladas. Las operaciones de una transaccin no tienen
ningn efecto sobre la base de datos hasta que la transaccin no se completa con xito.
Desde el momento en que a una base de datos pueden acceder diferentes usuarios al mismo
tiempo, en cada instante podremos tener distintas transacciones que manipulen la base de
datos a la vez. El estndar SQL prev que normalmente las transacciones se ejecuten en el

"nivel de aislamiento serializable" (isolation level SERIALIZABLE), o sea en una modalidad de

ejecucin que garantice la "serializabilidad" de las transacciones. El hecho de que las
transacciones se puedan serializar significa que su efecto global sobre la base de datos es el
que se obtendra si aqullas se ejecutasen no al mismo tiempo, sino una despus de otra.
En el lenguaje SQL estndar, no existe una instruccin que haga iniciar explcitamente una
transaccin. Las instrucciones se dividen en dos clases: las que pueden empezar una
transaccin y las que no la hacen empezar. En el momento en que se intenta ejecutar una
instruccin del primer tipo, si no est ya en marcha una transaccin, empieza una. La
transaccin contina hasta que una de las instrucciones falla, provocando la anulacin de toda
la transaccin, o hasta que se ejecuten las instrucciones COMMIT WORK o ROLLBACK
WORK. La instruccin COMMIT WORK termina la transaccin confirmndola, convirtiendo en
definitivos los efectos de sus instrucciones sobre la base de datos. Sin embargo, la instruccin
ROLLBACK WORK acaba anulndola.
A menudo, las DBMS que se encuentran en el mercado implementan la gestin de las
transacciones de modo distinto a como est previsto en el estndar (al menos en sus
colocaciones por defecto). En este caso, normalmente est prevista una orden que empieza
explcitamente una transaccin (BEGIN TRANSACTION, START WORK u otro). Si una
transaccin no se ha empezado explcitamente, las instrucciones concretas componen una
cada una.
Para entender mejor cules podran ser las consecuencias de la manipulacin concurrente de
los datos de una base de datos sin usar transacciones, veamos un ejemplo. Supongamos que
tenemos una base de datos con la que gestionamos los pedidos de los productos que
vendemos. En concreto, cuando un cliente nos solicita un producto, comprobamos la
disponibilidad y, en el caso en que podamos satisfacer el pedido, restamos a la cantidad que
tenemos la cantidad que se nos ha pedido. Traduciendo todo esto a SQL, obtenemos la
cantidad almacenada con la instruccin (instruccin A):
SELECT almacenamiento FROM productos
WHERE productoID=1453
La actualizacin del almacenamiento, una vez comprobada la disponibilidad se obtiene con la
siguiente instruccin (instruccin B):
UPDATE productos
SET almacenamiento=almacenamiento-1
WHERE productoID=1453
Si dos usuarios intentan ejecutar esta operacin, sin que las dos instrucciones que la
componen se hayan reagrupado en una transaccin, podra suceder que las instrucciones se
ejecuten en el orden y con los resultados siguientes:
Instruccin A, ejecutada por el usuario 1: se devuelve un almacenamiento del producto
equivalente a 1, por lo que el pedido ser aprobado.
Instruccin A, ejecutada por el usuario 2: como antes, el almacenamiento es 1 y tambin en
este caso el pedido se aprobar.
Instruccin B, ejecutada por el usuario 1: en este punto, en la base de datos el
almacenamiento para el producto vale 0.
Instruccin B, ejecutada por el usuario 2: ahora el almacenamiento vale -1, que, obviamente,
es un valor equivocado.
Como se ve, el resultado final es que uno de los dos clientes no podr recibir (al menos no
inmediatamente) la mercanca, dado que no tenamos en almacn una cantidad suficiente para ambos
clientes. Si las dos instrucciones se hubieran incluido en una transaccin, el problema no se habra
producido, dado que la transaccin del segundo usuario no habra podido leer el valor del
almacenamiento hasta que no se hubiese completado la transaccin del primer usuario. En ese
momento, el almacenamiento habra tenido valor 0 y el pedido no habra estado errneamente
aprobado.
3. Vistas
Hasta ahora las nicas tablas de las que nos hemos ocupado han sido las definidas con la orden
CREATE TABLE. El lenguaje SQL tambin pone a disposicin la posibilidad de definir tablas

"virtuales", las vistas, calculadas a partir de otras tablas. Son virtuales en el sentido que no ocupan
espacio en el disco, pero son el resultado de interrogaciones sobre otras tablas y, por lo tanto, siempre
estn alineadas con los valores contenidos en dichas tablas.
La instruccin SQL para definir una vista es la siguiente:
CREATE VIEW nombre_vista [ ( lista_nombres_columnas ) ]
AS expresin_tabla
Crea una vista llamada nombre_vista definitda por la expresin_tabla. Tpicamente, expresin_tabla es
una instruccin select que producir la tabla que interesa. La lista_nombres_columnas se puede usar
para asignar nombres a las columnas de la vista. Esto es til en el caso en que las columnas que
derivan de la expresin_tabla sean resultado de un clculo (por ejemplo COUNT(nombre_columna)) y
por ello no tengan un nombre explcito. Una vez creada, una vista se puede utilizar como una tabla
normal. Las unicas limitaciones se refieren a las operaciones que cambian los datos contenidos en
ella. En efecto, no todas las vistas pueden actualizarse. Las reglas que discriminan entre una vista
actualizable y una no actualizable son ms bien complejas, y no es este el lugar para describirlas
(vanse los libros en la bibliografa, concretamente el de C.J. Date). Aqu vamos a limitarnos a intentar
entender, mediante un ejemplo, por qu sucede esto.
Hagamos la prueba usando la siguiente vista en nuestra base de datos bibliogrfica:
CREATE VIEW book_publisher89
AS SELECT B.title, P.name
FROM Book B, Publisher P
WHERE B.publisher = P.ID
AND B.pub_year=1989
sta nos permite ejecutar la query que la define simplemente utilizando la instruccin:
SELECT * FROM book_publisher89
Podemos tambin introducir ulteriores condiciones (o hacer que el resultado se ordene segn una
columna concreta de la vista, etc...):
SELECT title FROM book_publisher89
WHERE name = "ACM Press"
Esta ltima interrogacin nos ofrece la lista de los ttulos de los libros publicados por ACM Press en
1989.
Como se ve, por lo que respecta a las operaciones de interrogacin, una vista se comporta como una
tabla normal. Las diferencias aparecen cuando se intentan aplicar a una vista operaciones de
actualizacin. Por ejemplo, si intentamos ejecutar la siguiente instruccin:
INSERT INTO book_publisher89
VALUES( "Nuevo libro", "publisher")
La DBMS no conseguir ejecutarla, devolviendo un error del tipo "No INSERT permission". El motivo
es que no es capaz de crear las lneas correspondientes a nuestro nuevo rcord en las dos tablas
"reales" en las que se ha originado la vista (los problemas son varios: tiene que crear slo una lnea en
la tabla Book y conectarla a una lnea concreta de la tabla Publisher, o crear una lnea en ambas
tablas; cmo decidir qu valores darles a las llaves primarias de los eventuales nuevos rcords; qu
valores darles a los otros campos de las dos tablas, etc...)
Gracias a las vistas (y a la asignacin prudente de los permisos a los usuarios) es posible conseguir
que diferentes usuarios tengan una percepcin de la estructura de la base de datos, si bien muy
diferentes de la que tiene realmente, e impedir que algunas categoras de usuarios puedan acceder a
informaciones que no les competen.
Por ejemplo, supongamos que contamos con una tabla en la que se han memorizado los datos
personales de los empleados de una empresa, as como las cantidades que conforman sus
respectivos sueldos. Obviamente, habra que evitar la consulta de los datos relativos a los sueldos por
parte de los usuarios, excepto quienes se tienen que ocupar de su erogacin/administracin. Un
sistema para hacerlo consiste en definir una vista que contenga slo las columnas de los datos
personales. As, todos los usuarios autorizados a acceder a dichos datos, pero no a los de los sueldos,

podrn entrar slo a travs de dicha vista. Ulteriores particiones podran hacerse en sentido horizontal,
creando por ejemplo una vista que slo contenga las informaciones sobre los directivos y otra con los
datos del resto de los dependientes. Adems, las vistas a menudo contribuyen a facilitar la
independencia entre aplicaciones y estructura de los datos, lo que hace que las bases de datos de los
instrumentos sean tan tiles. Efectivamente, si en un momento determinado fuese necesario cambiar
la estructura de la base de datos (descomponiendo, por ejemplo, una tabla en dos por motivos de
eficacia), no habra que modificar todas las aplicaciones adaptndolas a la nueva estructura, sino que
sera suficiente crear las vistas pertinentes, de modo que, desde el punto de vista de las aplicaciones,
nada haya cambiado.