sistemas de gestión de bases de datos

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
Índice
BASES DE DATOS Y SISTEMAS DE GESTIÓN DE BASES DE DATOS
3
BASES DE DATOS
Bases de datos y sistemas de gestión de bases de datos (SGBD)
Ventajas e inconvenientes de un SGBD
Tipos de sistemas de gestión de bases de datos
Bases de datos jerárquicas
Bases de datos en red
Bases de datos orientadas a objetos
Bases de datos relacionales
DISEÑO DE BASES DE DATOS RELACIONALES
Definiciones y características
Normalización de una base de datos relacional
Integridad referencial
Modelos Entidad – Relación (E-R)
EL LENGUAJE CONCEPTUAL DE GESTIÓN DE BASES DE DATOS RELACIONALES SQL
Características
Instrucciones de manipulación de tablas
SELECT
DELETE, INSERT Y UPDATE
Instrucciones de creación y administración de la base de datos
SQL embebido en lenguajes de programación
REFERENCIAS BIBLIOGRÁFICAS
3
3
5
5
6
6
7
7
7
7
9
12
12
13
13
14
14
16
16
18
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.
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008
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 informático, organizados de forma independiente de su utilización y accesibles simultáneamente por distintos 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 aplicaciones.
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.
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008
APLICACION
USUARIO
APLICACION
USUARIO
APLICACION
USUARIO
FICHERO
FICHERO
Figura 1.
SGBD
FICHERO
FICHERO
Banco de datos
USUARIO
USUARIO
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
o
o
o
creación, modificación o eliminación de tablas, registros, campos, índices, etc.
creación de relaciones,
validación de campos, valores, etc.
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.
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008
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
o
o
o
o
o
o
figura del administrador de la base de datos, con privilegios para otorgar los permisos de
acceso y uso.
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.
realización de copias de seguridad y recuperación del sistema en caso de desastre.
migración del sistema a nuevas versiones o incluso a diferentes sistemas de gestión.
comunicación con otros sistemas de gestión externos (remotos o en la misma máquina).
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.
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 gestió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 enormes:
•
•
•
•
•
•
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.
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008
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 muchos, 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 ‘propietarios’ 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.
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008
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 pertenecientes 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 sistemas 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
DATOS RELACIONALES
DE
Definiciones y características
La base de datos relacional supuso un gran avance frente a las base de datos jerárquicas y en red porque, así como en estas las relaciones están fijadas en la estructura de los datos, en el enfoque relacional 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 dominios 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 ‘atributos’ 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.
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008
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 columnas
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 siempre 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 intentarse 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 determinado 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.
Master en Ingeniería Medioambiental y Gestión del Agua 2007/2008
Una de las características más sobresalientes de las bases de datos relacionales es que se pueden establecer interrelaciones entre tablas. No se debe confundir el concepto de interrelación con el de relació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 campo 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
TABLA DE RIOS
CDR1
03011809
Figura 6.
NOMBRE
TAJUNA
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 “normalizado”. 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 Tercera 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 Normal 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 campos), 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 cualquiera 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
©: 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
Nº PEDIDO FECHA
1 01/10/2005
2 20/10/2005
3 20/10/2005
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
3 IBM
1.200
10
12000
5 BASF
27 PC
5 DVD
1,5
200
300
5 BASF S.A.
5 CDROM
0,7
600
420
12000
7 CDROM
0.7
1000
700
1000
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 campos 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
©: 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
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 aparecer 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
©: 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
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
©: 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
Instrucciones de manipulación de tablas
Las instrucciones para manipulación de los registros de las tablas y los valores de sus campos se reducen 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 ‘condició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
©: 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
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 comunes).
Existen una serie de funciones agregadas:
o
o
COUNT(campo) número de registros con un campo
SUM(campo)
suma de los valores del campo
Página 15 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
o
o
o
MAX(campo)
MIN(campo)
AVG(campo)
valor máximo de un campo
valor mínimo de un campo
valor medio de un campo
Como es lógico debe definirse el criterio para agrupar los registros con los que se va a efectuar 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 16 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
•
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
©: 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
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. Pueden 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 variables 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
©: 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
1
2
SET temed = :temed
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
#define
#define
#define
#define
#define
OK 0
Notfound 100
Multiple -10002
Deadlock -14024
True 1
False 0
EXEC SQL include sqlca;
EXEC SQL BEGIN DECLARE SECTION;
int indroea;
short indroeaind;
int fecha;
int naa;
short naaind;
int tot_es, tot, tot_esc;
int ano;
short anoind;
/* Indicativo estación */
/* Fecha */
/* No. años con precipitación */
/* Total estaciones */
EXEC SQL END DECLARE SECTION;
main(argc,argv)
int argc;
char *argv[];
{
int es1;
int es2;
int cont, i, j, n;
/* Estación inicial: argv[2] */
/* Estación final: argv[3] */
/* 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
©: 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
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
©: 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
<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á.
Página 21 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.