componente base datos

Vista previa del material en texto

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: LUIS QUINTAS RIPOLL
©: Quedan reservados todos los derechos. (Ley de Propiedad Intelectual del 17 de noviembre de 1987 y Reales Decretos). 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 2 de 21
Í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 
 
 
 
 
 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 3 de 21
 
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. 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 4 de 21
FICHEROFICHERO
APLICACION
APLICACION
APLICACION
USUARIO
USUARIO
USUARIO
 
Figura 1. Banco de datos 
FICHERO
FICHERO
USUARIO
USUARIO
USUARIO
SGBD
 
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: 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 5 de 21
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 sencillezy 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. 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 6 de 21
Bases de datos jerárquicas 
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 
 Bases de datos 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 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 7 de 21
 
Bases de datos orientadas a objetos 
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. 
Bases de datos relacionales 
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). 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 8 de 21
TABLA (ENTIDAD)
CAMPO
(ATRIBUTO)
REGISTRO
(TUPLA)
 
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 transitivacuando el valor de B tiene dependencia funcional de A y C dependencia funcional de B. 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 9 de 21
 
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
INDROEA LUGAR CDR1
03082 ORUSCO 03011809
TAJUNA
NOMBRECDR1
TABLA DE RIOS
03011809
 
Figura 6. Interrelación entre tablas en un sistema relacional 
Esta propiedad permite obtener tablas virtuales, llamadas ‘vistas’, en las que se forma una 
nueva tabla con atributos de varias tablas interrelacionadas. 
 
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 
 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 10 de 21
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: 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 11 de 21
 
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: 
Nº PEDIDO FECHA Nº PROV NOMBRE PROV. Nº PROD 1 NOM PROD 1PRECIO 1 CANT 1TOT PROD 1Nº PROD 2 NOM PROD 2PRECIO 2CANT 2TOT PROD 2 TOTAL PEDIDO
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
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 12 de 21
 
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 esevalor 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. 
 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 13 de 21
 
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. 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 14 de 21
 
 
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. 
 
 SELECT 
 
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 
 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 15 de 21
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 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 16 de 21
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, INSERT Y UPDATE 
 
• 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 paraadministrar su 
explotación. A continuación se exponen las más importantes: 
 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 17 de 21
• 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: 
 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 18 de 21
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 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 19 de 21
 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; 
 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 20 de 21
 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> 
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008 
 
 
©: 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. 
 Página 21 de 21
<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á.