Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

Módulo VII: Sistemas de Información

Geográfica y Teledetección

SISTEMAS DE GESTIÓN DE
BASES DE DATOS
AUTOR: Jose Eduardo Garrido
Gonzalez
 Base de datos 2

Índice
BASES DE DATOS Y SISTEMAS DE GESTIÓN DE BASES DE DATOS 3
BASES DE DATOS 3
Bases de datos y sistemas de gestión de bases de datos (SGBD) 3
Ventajas e inconvenientes de un SGBD 5
Tipos de sistemas de gestión de bases de datos 5
Bases de datos jerárquicas 6
Bases de datos en red 6
Bases de datos orientadas a objetos 7
Bases de datos relacionales 7
DISEÑO DE BASES DE DATOS RELACIONALES 7
Definiciones y características 7
Normalización de una base de datos relacional 9
Integridad referencial 12
Modelos Entidad – Relación (E-R) 12
EL LENGUAJE CONCEPTUAL DE GESTIÓN DE BASES DE DATOS RELACIONALES SQL 13
Características 13
Instrucciones de manipulación de tablas 14
SELECT 14
DELETE, INSERT Y UPDATE 16
Instrucciones de creación y administración de la base de datos 16
SQL embebido en lenguajes de programación 18
REFERENCIAS BIBLIOGRÁFICAS 21

Página 2 de 21

©: Quedan reservados todos los derechos. (Ley de Propiedad Intelectual del 17 de noviembre de 1987 y Reales
Decretos). Documentación elaborada por el autor/a para EOI.
Prohibida la reproducción total o parcial sin autorización escrita de EOI.
 Base de datos 2

SISTEMAS GESTORES DE BASES SE DATOS

BASES DE DATOS Y SISTEMAS DE GESTIÓN DE BASES DE DATOS

BASES DE DATOS
Se entiende por base de datos un conjunto de datos no redundantes, almacenados en un soporte infor-
mático, organizados de forma independiente de su utilización y accesibles simultáneamente por distin-
tos usuarios y aplicaciones.

Las bases de datos deben cumplir pues tres requisitos básicos:

 No redundancia: Los datos se almacenan una sola vez, aunque se utilicen para varias aplicacio-
nes.
 Independencia: Los datos se organizan de una manera estructurada independientemente de la
aplicación que se vaya a utilizar para tratarlos.
 Concurrencia: varios usuarios pueden acceder simultáneamente a los datos sin interferirse.

Bases de datos y sistemas de gestión de bases de

datos (SGBD)
Tradicionalmente, para manipular grandes cantidades de datos aparecieron en primer lugar las bases
de datos o "bancos de datos", cumpliendo de manera aproximada con la definición presentada en el
apartado anterior. Se trataba de almacenar ordenadamente datos en un juego de ficheros, y, mediante
unas aplicaciones informáticas y un sistema de índices, gestionarlas adecuadamente (Figura 1).

Al aumentar la complejidad de estos bancos de datos (elevado número de ficheros y usuarios, acceso
múltiple y simultáneo a los ficheros, aumento del número de registros, etc.) se producen problemas
cada vez más graves para asegurar la consistencia, la integridad y la accesibilidad de los datos,
produciendo problemas de eficiencia en el tratamiento de los datos.

Para resolver estos problemas aparecen en el mercado los Sistemas de Gestión de Bases de Datos
(SGBD), que convierten el acceso a los datos y su gestión en una aplicación cerrada ("caja negra"),
interponiéndose entre los usuarios y los ficheros, y haciéndose cargo de todos los problemas de
explotación, mantenimiento y comprobación de los datos (Figura 2). De esta manera el usuario pierde
de vista todos los detalles relativos al almacenamiento físico de los de los datos tratando con ellos sólo
a través de un lenguaje conceptual sencillo.

Página 3 de 21

©: Quedan reservados todos los derechos. (Ley de Propiedad Intelectual del 17 de noviembre de 1987 y Reales
Decretos). Documentación elaborada por el autor/a para EOI.
Prohibida la reproducción total o parcial sin autorización escrita de EOI.
 Base de datos 2

APLICACION
USUARIO

FIC HERO
F ICHERO
APLICACION USUARIO

APLICACION USUARIO

Figura 1. Banco de datos

SGBD USUARIO

FI CHERO
USUARIO
F ICHERO

USUARIO

Figura 2. Sistemas de Gestión de Bases de Datos

De acuerdo con los estudios de un grupo de trabajo de ANSI (TSICHRITZIS, Dennis & KLUG,
Anthony C., 1978) los sistemas de gestión de bases de datos se organizan en tres niveles:

 nivel interno: manipulación física de los datos. El usuario pierde de vista totalmente cómo y
dónde se almacenan los datos, ocupándose el motor del sistema de gestión de todas estas
tareas
 nivel externo: visión del usuario: manipulación lógica de los datos. El usuario maneja la base
de datos a través de un entorno organizado mediante menús o aplicaciones informáticas que
le guían sin necesidad de conocimientos de la estructura de la base de datos
 nivel intermedio: descripción de la base de datos mediante un lenguaje conceptual que
permiten una visión abstracta del sistema. Se entiende por lenguaje conceptual un lenguaje
formado por palabras (comandos) de fácil memorización que permiten efectuar todas las
tareas de acceso y manipulación de los datos, así como las tareas de mantenimiento de todo el
sistema de gestión.

El lenguaje conceptual del sistema de gestión permite abordar de manera todas las tareas para el
mantenimiento y explotación del sistema de gestión. Pueden agruparse en tres clases:

 Funciones de definición:

o creación, modificación o eliminación de tablas, registros, campos, índices, etc.

o creación de relaciones,
o validación de campos, valores, etc.
o funciones de manipulación:

Página 4 de 21

©: Quedan reservados todos los derechos. (Ley de Propiedad Intelectual del 17 de noviembre de 1987 y Reales
Decretos). Documentación elaborada por el autor/a para EOI.
Prohibida la reproducción total o parcial sin autorización escrita de EOI.
 Base de datos 2

o acceso a los datos mediante operaciones de búsqueda condicionada con uso de

operadores lógicos ( = , <>, <, >, and, or, etc.) para la presentación, modificación o
eliminación de registros.

 Funciones de administración:

o figura del administrador de la base de datos, con privilegios para otorgar los permisos de
acceso y uso.
o organización del sistema de permisos de acceso a las tablas, registros, campos ,etc. En
los sistemas de gestión de bases de datos aparece la figura del “administrador” de la base
de datos, usuario especial, propietario del sistema, que decide quién conecta a la base de
datos, quién accede a las diferentes tablas y qué puede hacer en ellas (sólo leer, insertar,
modificar o borrar registros, campos, índices, tablas, etc.). Esta figura es de una enorme
importancia para la preservación de la integridad de los datos.
o realización de copias de seguridad y recuperación del sistema en caso de desastre.
o migración del sistema a nuevas versiones o incluso a diferentes sistemas de gestión.
o comunicación con otros sistemas de gestión externos (remotos o en la misma máquina).
o preprocesadores para la inclusión del lenguaje conceptual en el código fuente de
programas de ordenador como FORTRAN, C, etc. para la programación de tareas
sofisticadas.
o lenguaje de 4ª generación para la creación de interfaces gráficas de usuario (menús)

Hoy en día hay una preponderancia del lenguaje SQL (Structured Query Language).
(CHAMBERLAIN & BOICE, 1974), materialmente presente en todos los sistemas de ges-
tión de gran difusión. La explicación de esta preponderancia se encuentra en la gran sencillez
y potencia de este lenguaje, que se describirá más adelante.

Ventajas e inconvenientes de un SGBD

Las ventajas del uso de un SGBD cuando han de manipularse grandes cantidades de datos son enor-
mes:

 Se eliminan las inconsistencias en los datos debido al fuerte control que se establece.
 Se comparten los datos entre diferentes aplicaciones sin complicaciones, permitiendo una rápida
adaptación a nuevas aplicaciones.
 Se ahorra espacio de almacenamiento.
 Se accede a los datos con extraordinaria rapidez.
 Se asegura la protección de los datos frente a malos usos o desastres.
 Permiten la creación de entornos personalizados de alta disponibilidad.

Tienen sin embargo algunas desventajas:

 La puesta en funcionamiento es larga, ya que se necesita una planificación muy detallada de la

estructura de datos.
 Se necesita personal especializado para su administración y mantenimiento.

Tipos de sistemas de gestión de bases de datos

Existen fundamentalmente 4 tipos de sistemas de gestión, que se diferencian por la estructura de datos
que ofrecen: SGBD jerárquicos, en red, relacionales y orientados a objetos.
Página 5 de 21

©: Quedan reservados todos los derechos. (Ley de Propiedad Intelectual del 17 de noviembre de 1987 y Reales
Decretos). Documentación elaborada por el autor/a para EOI.
Prohibida la reproducción total o parcial sin autorización escrita de EOI.
 Base de datos 2

Las bases de datos jerárquicas organizan la información en forma de árbol. Los datos dependen todos
de una entidad raíz, ‘padre’. Los datos dependientes del raíz son ‘hijos’ suyos. A su vez estos hijos
tienen hijos y así sucesivamente (figura 3). La relación entre padre e hijos es siempre de uno a mu-
chos, de manera que un hijo siempre tienen un solo padre, pero un padre puede tener varios hijos. Para
acceder a una entidad, se parte siempre del raíz y se recorren los hijos según un orden preestablecido.
Cuando se elimina un padre, se eliminan todos sus hijos también.

Estas bases de datos son muy apropiadas para datos que se prestan bien a una estructura ramificada.
Se utilizan en buscadores de INTERNET, donde son muy eficientes.

Figura 3. Estructura de una base de datos jerárquica

tos en red
El gran problema de las bases de datos jerárquicas es cuando es necesario definir una relación entre
entidades de muchos a muchos. Para casos de este tipo se crearon las base de datos en red o
CODASYL, nombre de la agrupación que presentó las normas para su desarrollo. Es una extensión
de la base de datos jerárquica, en que un hijo puede tener varios padres, denominándose estos ‘propie-
tarios’ y aquellos ‘miembros’.

Figura 4. Base de datos en red

Página 6 de 21

©: Quedan reservados todos los derechos. (Ley de Propiedad Intelectual del 17 de noviembre de 1987 y Reales
Decretos). Documentación elaborada por el autor/a para EOI.
Prohibida la reproducción total o parcial sin autorización escrita de EOI.
 Base de datos 2

Las bases de datos orientadas a objetos son las más modernas y siguen hoy en día en desarrollo. La
estructura de datos se basa en los conceptos de la orientación a objetos: objetos encapsulados pertene-
cientes a clases que heredan sus propiedades unas de otras.

Por su sencillez y su potencia, son hoy en día las bases de datos más extendidas. Casi todos los siste-
mas de gestión de bases de datos comerciales de gran difusión tienen estructura relacional (ORACLE,
INFORMIX, MSSQLSERVER, MSACCESS, etc.). Por ello se tratan a continuación con detalle.

DISEÑO DE BASES DE
DATOS RELACIONALES
Definiciones y características
La base de datos relacional supuso un gran avance frente a las base de datos jerárquicas y en red por-
que, así como en estas las relaciones están fijadas en la estructura de los datos, en el enfoque relacio-
nal las relaciones se establecen de una manera mucho más libre. El esquema relacional fue pensado
por Codd a finales de los años sesenta a partir de la teoría de conjuntos.

Los datos que han de almacenarse en una base de datos pueden agruparse en conjuntos de datos de la
misma naturaleza. El conjunto de todos los datos de un mismo tipo se denomina ‘dominio’. Los do-
minios son conjuntos finitos de datos.

Dado unos dominios D1, D2,....Dn, se define una ‘relación’ o ‘entidad’ como cualquier conjunto de
datos d1, d2,....dn, tales que d1  D1, d2  D2,..........dn  Dn. Este conjunto de datos se define como una
‘tupla’. Cada uno de los componentes de la relación pertenecientes a los dominios se denominan ‘atri-
butos’ de la relación. Se define como ‘grado’ de la relación el número de atributos (n). La relación
estará formada por un cierto número de tuplas, que se define como ‘cardinalidad’ de la relación.

Este lenguaje teórico puede sustituirse por otro más matemático:

Una relación o entidad es una tabla rectangular formada por filas y columnas, donde cada columna
contiene un tipo de dato. Cada fila o registro es una tupla, y cada columna o campo es un atributo. El
número de columnas es el grado y el número de registros es la cardinalidad (figura 5).

Página 7 de 21

©: Quedan reservados todos los derechos. (Ley de Propiedad Intelectual del 17 de noviembre de 1987 y Reales
Decretos). Documentación elaborada por el autor/a para EOI.
Prohibida la reproducción total o parcial sin autorización escrita de EOI.
 Base de datos 2

TABLA (ENTIDAD)

REGISTRO
(TUPLA)

CAMPO
(ATRIBUTO)

Figura 5. Tablas de un sistema de gestión de base de datos relacional

Para que una tabla pueda considerarse relación de una base de datos relacional tiene que cumplir una
serie de requisitos:

 debe haber un único valor en cada elemento de las filas (intersección fila – columna)
 los valores de todos los elementos de una columna deben ser del mismo tipo (deben pertenecer al
mismo dominio)
 no puede haber dos filas con todos los elementos iguales
 el nombre de cada columna (atributo) debe ser distinto dentro de la tabla
 el valor de los elementos dentro de cada columna debe ser independiente del orden de las colum-
nas
 el valor de los elementos de las filas debe ser independiente del orden de las filas

Como todas las filas de una tabla tienen que ser distintas, cualquiera de ellas puede identificarse siem-
pre por el valor de uno o varios campos. A este conjunto de campos se le llama ‘clave primaria’, que
puede ser simple, si la constituye un solo campo, o compuesta, si la constituyen varios . Ha de inten-
tarse que este grupo sea mínimo por motivos de eficiencia. Los campos que no pertenecen a la clave
primaria se llaman campos pertenecientes a clave ajena, o campos ‘no clave’. Obviamente una clave
primaria nunca puede tener un valor nulo.

Dentro de una relación o tabla se pueden hacer algunas operaciones básicas:

 Proyección. Se realiza una proyección cuando se extrae un cierto número de columnas de una
tabla
 Selección. Se realiza una selección cuando se extrae un cierto número de filas de una tabla.
Entre tablas, también se pueden efectuar operaciones algebráicas:
 Unión. Se pueden unir dos tablas con el mismo grado (número de columnas) y mismos atributos:
el resultado es una tabla única con los registros de ambas.
 Diferencia. Se obtiene una tabla con los registros que no coinciden en ambas.
 Intersección. Se obtiene una tabla con los registros comunes.
 Producto. Se puede realizar con dos tablas con los mismos atributos Se obtiene una tabla con el
producto cartesiano de los atributos.

Se dice que dos campos A y B tienen dependencia funcional cuando el valor del campo A es determi-
nado de manera única por el valor de B. Se dice que dos campos A y C tienen dependencia transitiva
cuando el valor de B tiene dependencia funcional de A y C dependencia funcional de B.
Página 8 de 21

©: Quedan reservados todos los derechos. (Ley de Propiedad Intelectual del 17 de noviembre de 1987 y Reales
Decretos). Documentación elaborada por el autor/a para EOI.
Prohibida la reproducción total o parcial sin autorización escrita de EOI.
 Base de datos 2

Una de las características más sobresalientes de las bases de datos relacionales es que se pueden esta-
blecer interrelaciones entre tablas. No se debe confundir el concepto de interrelación con el de rela-
ción (la confusión proviene de los términos ingleses relationship y relation). Para poder interrelacionar
tablas basta con que compartan algún campo clave. La interrelación se produce siempre entre un cam-
po clave en una tabla el mismo campo, pero no clave, en otra tabla (figura 6)

TABLA DE ESTACIONES DE AFORO TABLA DE RIOS

INDROEA LUGAR CDR1 CDR1 NOMBRE

03082 ORUSCO 03011809

03011809 TAJUNA

Figura 6.Interrelación entre tablas en un sistema relacional

propiedad permite obtener tablas virtuales, llamadas ‘vistas’, en las que se forma una nueva tabla con atributos de varias tablas interrelac

Figura 7. Vista en una base de datos relacional

Normalización de una base de datos relacional

Para asegurar la perfecta coherencia de los datos, un sistema de gestión relacional debe estar “norma-
lizado”. La normalización de una base de datos relacional (CODD, E. F., 1971) es fundamental para
un buen diseño de una base de datos relacional.

Las ventajas de la normalización son:

 se evitan las dependencias entre modificaciones en tablas distintas relacionadas entre sí

 se mejora la independencia de los datos entre sí, permitiendo un mejor crecimiento
 evita la aparición de restricciones artificiales en la estructura de los datos
 se evita la redundancia de los datos

Página 9 de 21

©: Quedan reservados todos los derechos. (Ley de Propiedad Intelectual del 17 de noviembre de 1987 y Reales
Decretos). Documentación elaborada por el autor/a para EOI.
Prohibida la reproducción total o parcial sin autorización escrita de EOI.
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

La normalización se efectúa en tres fases, de manera que para normalizar una base de datos se ha
pasar de una a otra completándose las anteriores. Según se completan estas fases de normalización se
dice que el sistema cumple sucesivamente la Primera Forma Normal, la Segunda y finalmente la Ter-
cera Forma Normal.

Una relación o tabla cumple la Primera Forma Normal cuando “sus dominios no tienen elementos que
a su vez sean conjuntos”. Esto quiere decir en esencia que no existen repeticiones en los campos de la
tabla y que todos los atributos pertenecen a dominios distintos. El cumplimiento sólo de la Primera
Forma Normal plantea problemas a la hora de insertar, modificar o borrar valores en los campos.

Por ello se debe cumplir la Segunda Forma Normal. Para ello debe cumplirse la Primera Forma Nor-
mal y además que “todos los campos que no son clave dependen funcionalmente de la clave completa
y no de parte”. Esto es aplicable sólo a tablas con claves compuestas (combinaciones de varios cam-
pos), de manera que una tabla con un campo clave único siempre cumple la Segunda Forma Normal.
La Segunda Formal Normal resuelve gran parte de los problemas de la Primera.

La Tercera Forma Normal es una extensión de la Segunda, eliminando las dependencias respecto a las
claves parciales. Se dice que una tabla cumple la Tercera Forma Normal si, además de cumplir la
Segunda Forma Normal, se cumple que “ninguno de sus campos que no son claves tiene dependencias
transitivas”. Como se definió anteriormente, se entiende que dos campos A y C tienen dependencia
transitiva cuando A depende de B y B depende de C.

Para explicar mejor la normalización de una base de datos relacional, veamos un ejemplo sencillo:
Supongamos que tenemos un negocio de material informático. En el almacén se dispone de una serie
de productos informáticos suministrados por unos proveedores. De tiempo en tiempo hay que efectuar
un pedido a los proveedores para pedir nuevas partidas de material. El formato de un pedido cualquie-
ra es el siguiente:

Se pretende informatizar todos los pedidos existentes, que son muy numerosos, en una base de datos.
Para ello se han codificado, es decir, se les ha otorgado una clave numérica, los distintos elementos:
los pedidos, los proveedores y los productos.
Una persona sin experiencia carga todos los datos en una sola tabla:

Página 10 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

Nº PEDIDO FECHA Nº PROVNOMBRE PROV. Nº PROD 1NOM PROD PRECIO 1CANT TOT PROD Nº PROD NOM PROD PRECIO 2CANT TOT PROD 2TOTAL PEDIDO
2
1 01/10/2005 3 IBM 27 PC 1.200 10 12000 12000

2 20/10/2005 5 BASF 5 DVD 1,5 200 300 7 CDROM 0.7 1000 700 1000
3 20/10/2005 5 BASF S.A. 5 CDROM 0,7 600 420 420

El campo clave es el número de pedido.

¿Cumple con las formas normales?
La primera forma normal dice que no pueden existir conjuntos de dominios pertenecientes al mismo
dominio (realmente la definición de relación indica que cada campo pertenece a un dominio distinto).
En este caso, los campos ‘nº prod1’ y ‘nº prod2’ pertenecen al dominio de los números de producto.
Igualmente ‘nom_prod1 y nom_prod2 pertenecen al dominio de los nombres de producto, etc. Deben
eliminarse y colocarse en tabla aparte:

De esta manera se elimina la restricción de que sólo se puedan informatizar pedidos con un máximo
de dos pedidos (ahora no hay límite) y se obtiene una estructura más eficiente (no existen tantos cam-
pos vacíos, en los casos en que sólo hay un producto en el pedido).
Esta nueva tabla tiene una clave compuesta por dos campos, el nº de pedido y el nº de producto.
La segunda forma normal dice que se cumple si se cumple la primera y si todos los campos no clave
dependen de la clave completa. Sólo se aplica a tablas con claves compuestas, como la que se acaba
de crear. Si se revisa de qué dependen los campos no clave de esta tabla, se comprueba que el nombre
del producto, así como su precio, sólo dependen del nº de producto, y no del pedido (no cambian para
cada pedido del mismo producto), no así la cantidad y el coste total, que dependen del nº de producto
y del pedido. Esta forma nos obliga a crear una tabla de productos.

De esta manera se eliminan redundancias con los nombre de los pedidos y eliminamos la restricción
de que para entrar un producto en la base de datos forzosamente tenía que haber un pedido suyo.
Finalmente la tercera forma normal se cumple si se cumple la segunda y si ninguno de los campos no
clave tienen dependencias transitivas. Si observamos la tabla de pedidos, vemos que el nombre del
proveedor depende del nº de proveedor, que a su vez depende del nº de pedido. Se debe pues crea una
tabla de proveedores:

Página 11 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

Con este esquema, todos los datos están informatizados, sin redundancias ni limitaciones.

Integridad referencial
Un concepto de una gran importancia es la integridad referencial de la base de datos. Una base de
datos mantiene su integridad referencial cuando, si se modifica o elimina un valor de un campo clave,
se modifican o eliminan todas las apariciones de ese valor en las otras tablas. Es decir, no puede apa-
recer un valor en una clave ajena de una tabla que no coincida con el mismo valor en una tabla como
clave primaria.

Modelos Entidad – Relación (E-R)

Los modelos Entidad-Relación son una herramienta útil para el diseño de bases de datos relacionales.
Permiten poner de manifiesto la estructura conceptual de la base de datos.

Simplificando mucho, se puede decir que se utilizan sólo un reducido grupo de conceptos semánticos
básicos:

 Entidad: cualquier objeto distinguible relevante

 Propiedades: información que describe a las entidades de alguna manera. Si representa un campo
clave, se subrraya
 Relación: relación entre entidades

Para representar estos elementos se utilizan unos elementos gráficos dentro de un diagrama:

 Entidad: rectángulo
 Propiedad: óvalo
 Relación: rombo

El tipo de relación, que puede ser de uno a uno, de uno a muchos o de muchos a muchos, se representa
con un 1 o una M.

Cualquier estructura de base de datos relacionales puede representarse con un diagrama de este tipo
(figura 8). La diferencia con un organigrama es que el diagrama E-R no tiene principio ni final, ya que
representa un estado y no un proceso.

Página 12 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

Figura 8. Ejemplo de modelo E-R

EL LENGUAJE
CONCEPTUAL DE GESTIÓN
DE BASES DE DATOS
RELACIONALES SQL
Características
Hasta que no aparecieron los lenguajes conceptuales, para interrogar a una base de datos había que ser
programador. En el año 1971 Codd define para IBM el lenguaje SQL (Structured Query Language)
(CODD, 1971), llamado inicialmente SEQUEL (Structured English Query Language). En 1986 ANSI
normaliza el lenguaje, de manera que actualmente es el universalmente utilizado e incorporado en
todos los grandes sistemas de gestión de bases de datos relacionales: ORACLE, INFORMIX,
SYBASE, MS-SQLSERVER, etc.

SQL es un lenguaje conceptual, no procedural, de manera que indica qué se hace, pero no cómo se
hace. El SQL se expresa con instrucciones en inglés simplificado para ser fácilmente memorizable. Se
escribe indistintamente en mayúsculas o minúsculas y los blancos no son significativos. Dispone de
instrucciones para manipular los registros y sus valores e instrucciones para construir y administrar la
base de datos.

Página 13 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

Instrucciones de manipulación de tablas

Las instrucciones para manipulación de los registros de las tablas y los valores de sus campos se redu-
cen a cuatro: SELECT, DELETE, INSERT y UPDATE.

Esta instrucción permite seleccionar los registros de una tabla con todos o parte de sus campos.
La forma general es:

SELECT * FROM tabla

selecciona todos los campos de todos los registros de la tabla ‘tabla’

SELECT campo1, campo2,.......FROM tabla

selecciona los campos ‘campo1’ campo2’.....de todos los registros de la tabla ‘tabla’

Pueden ponerse condiciones a la selección:

SELECT campo1, campo2,.......FROM tabla WHERE condición

Selecciona los campos ‘campo1’ ‘campo2’.....de la tabla ‘tabla’ que cumplan la condición ‘condi-
ción’.

Las condiciones pueden ser muy variadas:

WHERE campo1 = valor

buscará aquellos registros en que campo1 = valor

Se pueden utilizar todos los operadores matemáticos habituales:

= igual
< menor
> mayor
<= menor o igual
>= mayor o igual
<> distinto

También se pueden utilizar los operadores lógicos:

WHERE campo1 = valor1 AND campo2 = valor2

OR
NOT

Existe el operador BETWEEN (entre):

WHERE campo1 BETWEEN valor1 AND valor2

NOT BETWEEN

Página 14 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

También se puede comparar con una lista de valores:

WHERE campo1 IN (valor1, valor2, ...valorn)

O que no esté en la lista:

WHERE campo1 NOT IN (valor1, valor2, ...valorn)

Se puede exigir que sea el valor nulo o no nulo:

WHERE campo1 IS NULL

WHERE campo1 IS NOT NULL

Si el campo es alfanumérico se pueden buscar subgrupos de caracteres:

WHERE campo1 LIKE expresión%

NOT LIKE

Donde % significa cualquier cosa (comodín)

Se pueden efectuar selecciones encadenadas:

WHERE campo1 = ( SELECT campo2 FROM tabla2 WHERE condición)

O seleccionar sólo si existe otra selección:

WHERE EXISTS (SELECT campo2 FROM tabla2 WHERE condición)

O seleccionar si está en otra selección:

WHERE campo1 IN ( SELECT campo2 FROM tabla2 WHERE condición)

NOT IN
Se pueden seleccionar registros con campos con valore siempre distintos:

SELECT DISTINCT campo FROM tabla WHERE condición

Se pueden hacer selecciones compuestas de varias tablas:

SELECT tabla1.campo1, tabla2.campo3 ... FROM tabla1, tabla2

WHERE tabla1.campo1 condición AND tabla2.campo3 condición

Se pueden unir dos selecciones siempre que los campos unidos sean del mismo tipo:

SELECT campo1 FROM tabla1 WHERE condición

UNION SELECT campo3 FROM tabla2 WHERE condición

También existen INTERSECT (busca sólo los comunes) y EXCEPT (se queda sólo con los no comu-
nes).

Existen una serie de funciones agregadas:

o COUNT(campo) número de registros con un campo

o SUM(campo) suma de los valores del campo
Página 15 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

o MAX(campo) valor máximo de un campo

o MIN(campo) valor mínimo de un campo
o AVG(campo) valor medio de un campo

Como es lógico debe definirse el criterio para agrupar los registros con los que se va a efec-
tuar la operación: es la cláusula GROUP BY:

SELECT SUM(campo1) FROM tabla WHERE condicion GROUP BY campo2

Todavía se le puede imponer condiciones a la selección con la cláusula HAVING:

SELECT SUM(campo1) FROM tabla WHERE condicion GROUP BY campo1

HAVING campo1 condición

 DELETE

La cláusula DELETE permite borrar registros. La forma general es:

DELETE FROM tabla WHERE condición

donde condición incluye todas las posibilidades descritas para la cláusula SELECT

Si no se pone condición, DELETE borra todos los registros de la tabla

 INSERT

La cláusula INSERT inserta registros nuevos en una tabla:

INSERT INTO tabla (campo1, campo2 , ...campon) VALUES (valor1, valor2, .

..valorn)

Para insertar un valor nulo se utiliza la palabra NULL

 UPDATE

Esta cláusula modifica valores de registros ya existentes:

UPDATE tabla SET campo1 = valor1, campo2 = valor2, ...campon = valorn

WHERE condición

donde condición incluye todas las posibilidades descritas para la cláusula SELECT

Instrucciones de creación y administración de la base

de datos

El SQL dispone de instrucciones específicas para construir la base de datos y para administrar su
explotación. A continuación se exponen las más importantes:

Página 16 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

 CREATE

Permite crear tablas, índices y vistas

CREATE TABLE tabla (campo1 tipo1 (NOT) NULL, campo2 tipo2 (NOT) NULL,
....campon tipon (NOT) NULL)

Los tipos son:

INTEGER entero
SMALLINT entero corto
FLOAT decimal corto
DECIMAL p,q decimal con p dígitos y g decimales
CHAR(n) alfanumérico de n caracteres
VARCHAR(n) alfanumérico de hasta n caracteres
DATE fecha
TIME tiempo
BLOB objetos binarios

Para crear índices:

CREATE (UNIQUE) INDEX índice ON tabla (campo1, campo2 ...)

También se pueden crear tablas virtuales (vistas):

CREATE VIEW vista AS selección

Donde selección es una cláusula SELECT completa

 DROP

Permite borrar tablas, índices y vistas:

Borra una tabla:

DROP TABLE tabla

Borra un índice:

DROP INDEX índice

Borra una vista:

DROP VIEW vista

 ALTER

Modifica tablas:

ALTER TABLE tabla ADD (campo1 tipo1 (NOT) NULL,.....)

ALTER TABLE tabla DROP (campo1, campo2....)

 GRANT

Esta cláusula establece los permisos de acceso a todos los niveles de la base de datos:

Página 17 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

Para permitir conectarse a la base de datos a un usuario:

GRANT CONNECT ON base_datos TO usuario

Otros permisos:

GRANT SELECT ON tabla TO usuario

DELETE
INSERT
UPDATE
ALTER
ALL

Permite hacer selecciones, inserciones, borrados o modificaciones en la tabla a un usuario. Pue-

den especificarse campos:

GRANT SELECT campo1,campo2, ... ON tabla TO usuario

 REVOKE

Elimina permisos concedidos

:
REVOKE CONNECT ON base_datos FROM usuario

REVOKE SELECT ON tabla FROM usuario

DELETE
INSERT
UPDATE
ALTER
ALL

SQL embebido en lenguajes de programación

Una interesantísima posibilidad es utilizar SQL ‘embebido’ en el código fuente de un lenguaje de
programación. Para ello se necesita disponer del preprocesador correspondiente. A continuación
se muestran dos listados correspondientes a extractos de programas con SQL embebido en
FORTRAN y en lenguaje C. El paso de valores de campos de la base a variable se efectúa con va-
riables precedidas de el símbolo “:”.

 FORTRAN

EXEC SQL BEGIN DECLARE SECTION

CHARACTER*7 indctv
CHARACTER*6 fecha
DOUBLE PRECISION temed
CHARACTER*120 SQLMessage
EXEC SQL END DECLARE SECTION

C (* End Host Variable Declarations *)

n=0
do while (.true.)
read(5,'(a7,a6,f6.1)',end=100)indctv,fecha,temed
n=n+1

EXEC SQL UPDATE root.pluvio

Página 18 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

1 SET temed = :temed

2 WHERE indctv = :indctv AND fecha = :fecha

IF (SQLCode .EQ. 100) THEN

CALL Insert(indctv,fecha,temed)
SQLCode = OK
ENDIF
IF (SQLCode .NE. OK) THEN
CALL SQLStatusCheck
CALL RollBackWork
ELSE
CALL CommitWork
ENDIF
end do

100 close(5)
Modificar=.TRUE.
RETURN
END

 LENGUAJE C
#include <stdio.h>

#define OK 0
#define Notfound 100
#define Multiple -10002
#define Deadlock -14024
#define True 1
#define False 0

EXEC SQL include sqlca;

EXEC SQL BEGIN DECLARE SECTION;

int indroea; /* Indicativo estación */

short indroeaind;
int fecha; /* Fecha */
int naa; /* No. años con precipitación */
short naaind;
int tot_es, tot, tot_esc; /* Total estaciones */
int ano;
short anoind;

EXEC SQL END DECLARE SECTION;

main(argc,argv)

int argc;
char *argv[];

{
int es1; /* Estación inicial: argv[2] */
int es2; /* Estación final: argv[3] */
int cont, i, j, n; /* Contador */

EXEC SQL CONNECT TO 'base';

if(sqlca.sqlcode != OK) error();

EXEC SQL BEGIN WORK;

EXEC SQL DECLARE indicursor CURSOR FOR

SELECT indroea
INTO :indroea INDICATOR :indroeaind
FROM estaf;

Página 19 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

cont = 0;

EXEC SQL OPEN indicursor;

for(;;) {
EXEC SQL FETCH indicursor;
if(strncmp(SQLSTATE,"02",2) == 0) break;
if(sqlca.sqlcode != OK && sqlca.sqlcode != Notfound) error();

naa = 0;

EXEC SQL SELECT count(ano_hidr)

INTO :naa INDICATOR :naaind
FROM resum_a
WHERE indroea = :indroea
AND ano_hidr NOT BETWEEN 1931 and 1942;

if(sqlca.sqlcode != OK && sqlca.sqlcode != Notfound) error();

printf("%d) estacion: %d naa = %d\n",cont,indroea,naa);

EXEC SQL UPDATE estaf

SET naa = :naa
WHERE indroea = :indroea;
cont++;
}

EXEC SQL CLOSE indicurdor;

EXEC SQL FREE indicursor;

fin();
}

/********* Fin de lecturas en la base de datos ****/

fin()

EXEC SQL COMMIT WORK;

EXEC SQL DISCONNECT CURRENT;

}
/*************** Función error SQL ***************************************/

error()

printf("\n%s %d\n","ERROR de INFORMIX SQL No. ",sqlca.sqlcode);

exit();
}

 BASIC (ASP)

<html>
<head>
<base href="http:/HIDRO/estmt_coord.asp" fptype="TRUE">
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="GENERATOR" content="Microsoft FrontPage 6.0">
<title>Estaciones meteorológicas por coordenadas</title>
</head>
Página 20 de 21
 Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008

<body background="../backgrnd.gif">
<h1 align="CENTER">Base de datos HIDRO</h1>
<p>&nbsp;</p>
<h2><%@ LANGUAGE="VBScript" %><!--webbot bot="HTMLMarkup" StartSpan
</div><%Set Connection = Server.CreateObject("ADODB.Connection")
Connection.Open "DSN=hidro"
SQLStmt = "SELECT estmt.indctv,estmt.nap,estmt.nat,estmt.nac, estmt.lugar, muni.munombre
, cdr.corriente, estmt.xutm30, estmt.yutm30 "
SQLStmt = SQLStmt & "FROM hidro:informix.cdr cdr, hidro:informix.muni muni, hidro:
informix.estmt estmt "
SQLStmt = SQLStmt & "WHERE estmt.muni_id=muni.muni_id AND estmt.num_cuenca=cdr.
num_cuenca AND (estmt.xutm30 >= " & xmin & " and estmt.xutm30 <= " & xmax & " and estmt.
yutm30 >= " & ymin & " and estmt.yutm30 <= " & ymax & " ) "
SQLStmt = SQLStmt & "ORDER BY cdr.corriente, estmt.indctv "
Set RS = Connection.Execute(SQLStmt)
</body>
</html

REFERENCIAS
BIBLIOGRÁFICAS
 CHAMBERLAIN, H & BOICE., 1974.” Language SEQUEL 2”. IBM.
 CODD E. F., 1971: “Normalized Data Structure: A Brief Tutorial”. IBM Research Report RJ 935.
San José. California. 1971
 CODASYL, 1971.” Informe CODASYL DBTG (Data Base Task Group)”.
 TSICHRITZIS, Dennis & KLUG, Anthony C., 1978. “The ANSI/X3/SPARC DBMS Framework
Report of the Study Group on Dabatase Management Systems”. IS 3(3): 173-191 (1978). Univ.
de Toronto. Canadá.

Página 21 de 21