Módulo VII: Sistemas de Información Geográfica y …api.eoi.es/api_v1_dev.php/fedora/asset/eoi:45500/componente45499.pdf · Las bases de datos orientadas a objetos son las más

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).


©: 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



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.



Página 4 de 21

FICHEROFICHERO

APLICACION

APLICACION

APLICACION

USUARIO

USUARIO

USUARIO

Figura 1. Banco de datos

FICHEROFICHERO

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:



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 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 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



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).



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 transitiva cuando el valor de B tiene dependencia funcional de A y C dependencia funcional de B.



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



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:



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 PEDIDO1 01/10/2005 3 IBM 27 PC 1.200 10 12000 120002 20/10/2005 5 BASF 5 DVD 1,5 200 300 7 CDROM 0.7 1000 700 10003 20/10/2005 5 BASF S.A. 5 CDROM 0,7 600 420 420



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 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 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.



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



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



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 para administrar su explotación. A continuación se exponen las más importantes:



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:



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



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;



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>



Página 21 de 21

<body background="../backgrnd.gif"> <h1 align="CENTER">Base de datos HIDRO</h1> <p> </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á.

Documents

Módulo VII: Sistemas de Información Geográfica y …api.eoi.es/api_v1_dev.php/fedora/asset/eoi:45500/componente45499.pdf · Las bases de datos orientadas a objetos son las más