Está en la página 1de 170

 

Profesor 
Verónica Canivell Castillo 
 
Asignatura  
Bases de Datos I 
Grado en Ingeniería Informática 
 
Curso 2012‐13 
 
 
INDICE
  Pg. 
1. Conceptos generales  1 
1.1. Conceptos básicos  1 
1.2. Procesamiento de ficheros  3 
1.3. Organizaciones y operaciones con ficheros  3 
1.4. Organización secuencial  5 
1.5. Organización directa  6 
1.6. Organizaciones indexadas  12 
   
2. Introducción a las bases de datos  17 
2.1. Introducción  17 
2.2. Concepto de base de datos  19 
2.3. Elementos de un sistema de BD  20 
2.4. El sistema de gestión de base de datos  22 
   
3. Diseño de base de datos  33 
3.1. Arquitectura ANSI/SPARC  33 
3.2. Etapas de diseño  38 
3.3. Modelos de datos  40 
3.4. Lenguajes y utilidades del SGBD  57 
3.5. El diccionario de datos  60 
   
4. Implementación de una base de datos  61 
4.1. Introducción  61 
4.2. Representación física de estructuras de datos  62 
4.3. Ejemplos sobre posibles representaciones  66 
4.4. Técnicas de acceso  73 
4.5. Técnicas opcionales para el almacenamiento de datos  74 
   
5. El modelo relacional  79 
5.1. Conceptos básicos. Estructura de datos relacional  80 
5.2. Algebra relacional  88 
5.3. Cálculo relacional  95 
5.4. Arquitectura de un sistema relacional  96 
5.5. Estructura de datos relacional. SQL de Oracle  98 
5.6. Manipulación de datos  102 
5.7. Nivel externo. Vistas  122 
5.8. SQL inmerso  128 
5.9. Nivel interno  131 
   
6. SGBD relacionales comerciales  134 
   
7. Recuperación y optimización de una base de datos  139 
7.1. Recuperación de la BD  139 
7.2. Modificación y optimización  142 
  145 
Ejercicios 
   
Bibliografía  166 
 
TEMA I
CONCEPTOS GENERALES

1.1. CONCEPTOS BÁSICOS

Antes de adentrarnos en el estudio de las estructuras avanzadas de la


información, es necesario definir una serie de conceptos que desarrollaremos a
continuación.

Por información entendemos la yuxtaposición de símbolos con los que se


representan convencionalmente hechos, objetos o ideas. Dentro de este
término podemos diferenciar entre representación y dato. Por ejemplo, si
tenemos la siguiente información, NOMBRE: JUAN, NOMBRE sería la
representación y JUAN sería el dato. Por lo tanto, un dato es un conjunto de
símbolos utilizados para expresar o representar un valor numérico, un hecho,
un objeto o una idea.

Esta información se representa en el ordenador por medio de caracteres,


utilizando un código binario, denominado así porque utiliza sólo dos valores: 1 y
0. A la unidad mínima de información se le denomina bit y a cada carácter le
corresponde un cierto número de bits. Un byte es el número de bits necesario
para almacenar un carácter. Este número depende del código utilizado por el
computador, siendo generalmente 8, por lo que habitualmente byte se utiliza
como sinónimo de 8 bits u octeto.

Un campo es un dato elemental. Los campos se agrupan formando registros,


de tal forma que un registro lógico es una colección de campos relacionados
que se pueden tratar como una unidad para su proceso. Un registro físico es
la unidad de datos que realmente se transfiere con una operación de E/S, entre
el fichero de usuario y la memoria principal. Un registro físico puede contener
uno o varios registros lógicos, esto es, podemos transferir varios registros
lógicos a la vez, empleando una operación de E/S. Este fenómeno recibe el

1
nombre de bloqueo de registros, y los registros físicos así constituidos se
denominan bloques; el número de registros lógicos de un bloque recibe el
nombre de factor de bloqueo.

Una de las ventajas de la agrupación de registros en bloques es la mejora el


tiempo de proceso de los registros. Por ejemplo, suponemos un fichero con 100
registros, si tenemos que leer todos los registros del fichero y el factor de
bloqueo es 10, deberemos realizar 10 operaciones de E/S. En la primera
leemos los 10 primeros registros y pasan al buffer, ahí se comienzan a
desbloquear y tratar uno a uno, pero como están en memoria, el tiempo
necesario es mucho más pequeño que si accediésemos al periférico. Si el
factor de bloqueo fuese de 1, deberíamos de realizar 100 operaciones de E/S.

Un fichero es un conjunto de información sobre un mismo tema tratado como


una unidad de almacenamiento y organizada de forma estructurada para la
búsqueda de un dato individual. Un fichero está compuesto de registros
homogéneos que contienen información sobre dicho tema. Si todos los
registros de un fichero son de idéntico tamaño, se dice que son registros de
longitud fija, en cambio, si el tamaño de cada registro del fichero puede ser
variable, se dice que los registros son de longitud variable. Un registro tiene
una clave compuesta por uno o varios campos cuyo contenido identifica a ese
registro dentro del fichero.

CAMPO NOMBRE Dato elemental

Conjunto de campos,
REG. LÓGICO DNI APELLIDOS NOMBRE unidad de proceso
para el usuario

REG. FÍSICO
Conjunto de registros
O BLOQUE RL1 RL2 RL3 RL4
lógicos. Depende del
factor de bloqueo

2
1.2. PROCESAMIENTO DE FICHEROS
El procesamiento de ficheros conlleva solicitar los registros del fichero. El
modo de acceso es la manera de localizar un registro. Existen dos formas de
acceder a los registros de un fichero:
• Modo Secuencial: Se lee la información de un fichero de registro en
registro teniendo que leer todos los que hay antes del que buscamos. Se
utiliza cuando se quieren procesar todos o muchos de los registros del
fichero, o cuando el soporte en el que está el fichero no permite otro
modo de acceso.
• Modo Directo: Se puede acceder a un registro directamente, sin tener
que leer todos los anteriores (basta con un pequeño número de
lecturas). Hay dos maneras:
• Cálculo: Cada registro tiene una clave sobre la que se aplica un
cálculo que indica el lugar de grabación (Hashing).
• Índices: existe un índice independiente o asociado al fichero en el
cual se busca el registro y se nos indica donde está.

1.3. ORGANIZACIÓN Y OPERACIONES CON


FICHEROS

Organización es el modo de disponer los registros del fichero en el dispositivo


de almacenamiento. Existen tres modos principales:

• Organización secuencial
Es la forma de organización de ficheros más antigua. Se basa en que la
disposición física de los registros coincida con su orden lógico, es decir, se
coloca un registro a continuación de otro. Se utiliza en aplicaciones de
procesos por lotes. Es la única organización que puede ser soportada tanto
en dispositivos de acceso secuencial como en dispositivos de acceso
directo.

3
• Organización directa
Los registros se almacenan en el soporte atendiendo a un algoritmo de
cálculo.. Para disponer los registros en el fichero se hace uso de técnicas de
dispersión sobre un campo denominado clave. Se usa cuando se hace
necesario un acceso muy rápido.

• Organización indexada
Los registros generalmente se almacenan secuencialmente y son apuntados
mediante un índice, que indica la situación del registro dentro del fichero en
función de su clave.

Las operaciones que se pueden hacer con los ficheros pueden utilizar todos
los registros del fichero o sólo una parte de ellos. Algunas de las operaciones
que utilizan todos los registros de los ficheros son siguientes:

- Creación. Consiste en la grabación, por primera vez, sobre un dispositivo de


almacenamiento de los registros de un fichero.

- Apertura y cierre. Para poder hacer cualquier operación con los registros de
un fichero ha de estar abierto. Cuando no se utilizan los datos que almacena el
fichero, éste debe permanecer cerrado para evitar problemas con la
información que almacena. Para empezar a trabajar con los datos de un fichero
la primera operación es abrirlo, y cuando se termine de trabajar con él, hay que
cerrarlo.

- Borrado. Consiste en la eliminación de todo el fichero.

- Extensión de un fichero. Esta operación permite a los programas de usuario


incrementar el tamaño de un fichero, asignándole más espacio en el
dispositivo. Para realizar esta operación se necesita conocer el identificador del
fichero, y el tamaño del espacio a añadir. Además en función de la
organización del fichero se deberá conocer si el espacio a asignar debe ser
contiguo al ya asignado al fichero o no.

4
Además de estas operaciones en las que se ven afectados todos los registros
del fichero se pueden realizar otras operaciones en las que sólo se utilicen una
parte de los registros. En estas operaciones será necesario, primero, localizar
el registro o los registro con los que queremos trabajar y luego realizar la
operación. Las operaciones mas utilizadas de este tipo son las de:

- Actualización o mantenimiento. Esta operación consiste en mantener


actualizados los datos almacenados en los registros del fichero, tecleando
nuevos datos cuando se conocen, modificando datos ya existente o eliminando
datos que ya no se necesitan. Las operaciones de actualización se conocen
con los nombres de:
• Altas: Consiste en añadir nuevos registros al fichero.
• Bajas: Consiste en eliminar registros del fichero, eliminando su
contenido, o simplemente, bloqueando el acceso a los datos que
contiene.
• Modificaciones: Consiste en cambiar el contenido de uno o más
campos de un registro del fichero.

- Recuperación. Consiste en acceder a la información almacenada en los


registros del fichero para su consulta.

1.4. ORGANIZACIÓN SECUENCIAL


Un fichero tiene una organización secuencial cuando el orden lógico de sus
registros coincide con su organización física. Para ello los registros se
almacenan en serie en el dispositivo. Por ello esta organización se puede
utilizar para ficheros que serán almacenados en dispositivos de acceso
secuencial o en dispositivos de acceso directo.

Para almacenar un fichero secuencial se reserva en el dispositivo de


almacenamiento un conjunto de bloques que irán albergando a los registros
lógicos del fichero.

5
El tamaño total de un fichero con organización secuencial será la suma del
tamaño de todos sus registros.

El tamaño de los registros lógicos lo determina el usuario en función de sus


necesidades, pero el tamaño del bloque o registro físico está determinado por
la forma en que el sistema gestiona el espacio de almacenamiento disponible
en cada dispositivo. La relación entre estos tamaños determina el factor de
bloqueo. Si dentro de un bloque queda espacio libre que no puede ser utilizado
para almacenar un registro lógico completo se dice que hay fragmentación
interna en el bloque. El sumatorio de las fragmentaciones internas de todos los
bloques utilizados en el fichero será la fragmentación interna total del fichero.
Los registros borrados en un fichero secuencial generan fragmentación
externa.

1.5. ORGANIZACIÓN DIRECTA


Esta organización se denomina organización directa, organización aleatoria u
organización calculada. La organización directa se define por la existencia de
una correspondencia entre la clave de identificación de cada registro lógico del
fichero y su dirección en el dispositivo de acceso directo.

En este tipo de organización la correspondencia entre claves y direcciones es


de tipo n-1, es decir a varios valores de clave les puede corresponder la misma
dirección.

Para hacer corresponder los valores de clave con el rango de direcciones


reservadas para el fichero se utiliza una función de correspondencia
denominada función de HASHING O FUNCIÓN DE DIRECCIONAMIENTO. Esta función
se aplicará a un valor de clave para obtener una dirección. Esta función
establece una correspondencia de “n” a “1” y por lo tanto para varias claves se
puede obtener la misma dirección. Así pues esta dirección obtenida no tiene
porqué ser la definitiva para el registro correspondiente a la clave, por tanto a la
dirección resultante se le denomina dirección probable. Todos los registros

6
para cuyas claves la función de hashing devuelve la misma dirección probable
se denominan sinónimos.

Los sinónimos que no caben en la dirección probable generan un problema


denominado colisión. Este problema se resuelve con un método de resolución
de colisiones, que a partir de las direcciones probables calcula las direcciones
de los bloques o de las pistas donde definitivamente se ubicarán los registros.

Por tanto la técnica denominada hashing consta de dos elementos:

ƒ la función de hashing
ƒ el método de resolución de colisiones

1.5.1. ALGORITMOS DE HASHING

Entendemos por rango el conjunto de claves posibles. Si se conoce la clave


más alta y la más baja, el rango es el conjunto de claves posibles entre las dos
conocidas. Si no, está definido por la longitud de la clave. Estos algoritmos
implementan la correspondencia entre el rango de claves (conjunto de claves
posibles) y otro de direcciones más reducido. Por lo tanto la correspondencia
entre ambos conjuntos es de tipo “n” a “1”. El objetivo de estos algoritmos es
que la correspondencia entre las ocurrencias de valores de clave y el rango de
direcciones sea de tipo “1” a “1”, siempre que al crear el fichero se haya
reservado espacio suficiente. Como esto no siempre es posible, los algoritmos
tratan de minimizar el número de sinónimos que producen, es decir distribuir
los registros adecuadamente en el espacio reservado para el fichero utilizando
toda la información suministrada en la clave.

Además de cumplir estos objetivos un buen algoritmo de hashing debe tener


una complejidad computacional mínima, porque se ejecuta cada vez que se
accede a los registros del fichero.

7
ALGORITMOS BÁSICOS

Estos algoritmos se basan en operaciones matemáticas por lo que trabajan


suponiendo que la clave es de tipo numérico. Si la clave utilizada es
alfanumérica debe convertirse previamente a un valor numérico, generalmente
utilizando los códigos ASCII, EBCDIC, etc.

División-Resto
Este algoritmo calcula la dirección probable tomando el resto de la división
entre la clave y el número de direcciones reservadas para el fichero. Una
ventaja de este algoritmo es que los valores devueltos siempre están entre 0 y
N-1, siendo N el número de direcciones reservadas.

Extracción de dígitos
Estos algoritmos se basan en seleccionar como dirección el número formado
por algunos de los dígitos de la clave. Para que el algoritmo produzca pocos
sinónimos se suelen seleccionar los dígitos que más varían. Si los dígitos
seleccionados son consecutivos el algoritmo también se denomina de
truncamiento. El número de dígitos a extraer viene determinado por el rango de
posibles direcciones.

Folding
Este algoritmo divide la clave en varias partes con las que se realiza una
operación aritmética o lógica. Si el resultado contiene más dígitos que la
máxima dirección posible se realiza un truncamiento. Este algoritmo es útil si la
clave contiene muchos dígitos. La complejidad computacional es mínima pero
produce muchos sinónimos.
Squaring
Consiste en elevar al cuadrado la clave y después realizar una extracción de
dígitos. Una variante de este algoritmo consiste en invertir el orden de las
operaciones, primero realiza una extracción de dígitos y luego eleva al
cuadrado el número formado.

8
Conversión de base
Este algoritmo considera que la clave esta en una base distinta de 10, es decir
que no es un número decimal. Para obtener la dirección transforma dicho
número a decimal. Si el número obtenido es mayor que el número máximo de
dirección se trunca por la izquierda.

COMPARACIÓN DE ALGORITMOS
Para evaluar los algoritmos de hashing, se realiza un análisis del número de
sinónimos producidos para un determinado conjunto de claves. En este caso
las claves están formadas por 5 dígitos y las direcciones a obtener están
formadas por 2 dígitos, por lo tanto habrá 100 posibles bloques, de 0 a 99.

En la siguiente tabla se muestra el conjunto de claves y las direcciones


obtenidas para cada una con los distintos algoritmos:

División Extracción de 5º Folding 1 Squaring 2 Conversión


Clave Resto y 3ºdígito de base 12
24964 64 49 13 16 56
25936 36 69 95 49 50
32179 79 91 0 89 25
38652 52 26 38 25 58
40851 51 18 59 25 57
53455 55 54 89 25 5
53758 58 87 95 25 0
54603 03 36 49 0 59
63388 88 83 21 44 36
81347 47 73 60 56 3
Sinónimos 0 0 2 4 0

1
Folding: sumar el número formado por 1º, 2º y 3º dígito con el formado
por 4º y 5º y truncamiento por la izquierda
2
Squaring: extracción del 2º, 3º y 4º dígito, elevar al cuadrado y truncar
por la izquierda

9
HASHING PERFECTO

La eficiencia de una función de direccionamiento se mide por el número de


excedentes que produce, no por el número de sinónimos que genera.

El objetivo de los algoritmos de hashing es no producir ningún excedente,


aunque en principio esto es imposible debido a que el conjunto de direcciones
reservado para el fichero siempre es menor que todas las posibles claves.

Sin embargo en un fichero no tienen por que aparecer todos los posibles
valores de clave. Si un algoritmo de hashing logra para un conjunto de claves
conocido, que será un subconjunto de todos los posibles valores de clave, no
generar ningún excedente se denomina algoritmo de hashing perfecto.

1.5.2. RESOLUCIÓN DE COLISIONES

Los algoritmos de hashing pueden generar sinónimos que se irán almacenando


en la dirección correspondiente. Si el algoritmo genera, por ejemplo,
direcciones relativas de bloque, el bloque correspondiente podrá albergar
tantos sinónimos como indique el factor de bloqueo. Sin embargo cuando el
número de sinónimos supera al factor de bloqueo se generan colisiones. Si el
algoritmo genera direcciones relativas de pista, se generan colisiones cuando
el número de sinónimos supere al número de registros que quepan en una
pista. Las técnicas de resolución de colisiones se encargan de buscar una
ubicación definitiva para los sinónimos que generan colisiones.

Existen dos clases de técnicas para la resolución de colisiones: técnicas de


direccionamiento abierto y de direccionamiento cerrado.

Una vez almacenados todos los registros sinónimos, en su dirección definitiva,


la recuperación de los mismos puede ser compleja, ya que supone la repetición
10
de todas las operaciones que han sido necesarias para su ubicación. Para
solucionar este problema, puede implementarse el HASHING LIGADO. Esta
técnica consiste en mantener una estructura de datos de tipo lista formada por
cada grupo de registros sinónimos entre sí. Esto supone que en el registro
debe incluirse un puntero, es decir el valor de la dirección definitiva donde se
encuentra el siguiente sinónimo, e incluso dos si la lista es doble, el del
sinónimo anterior y el del posterior. De esta forma para localizar un sinónimo
bastará con recorrer la lista a partir del sinónimo encontrado en la dirección
original.

En todas las operaciones sobre registros el método de acceso debe tener en


cuenta la existencia de las cadenas de sinónimos, manteniéndolas
adecuadamente.

TÉCNICAS DE DIRECCIONAMIENTO ABIERTO

Son aquellas técnicas de resolución de colisiones en las que los sinónimos que
generan colisiones pueden ser almacenados en cualquiera de los bloques o
pistas reservados para el fichero. Estas técnicas se basan en el cálculo
sucesivo de direcciones probables hasta encontrar un bloque o pista con
espacio libre para albergar el registro.

Prueba lineal
Consiste en obtener un nuevo bloque o pista probable a partir del original
generado por la función de hashing, sumando a este una cantidad constante. Si
se genera una nueva colisión se repite el proceso hasta obtener un bloque o
pista con espacio suficiente para ubicar el registro. El fichero es considerado
como una secuencia circular de bloques o pistas. El caso más simple es que la
constante valga 1, es decir si un registro genera una colisión se prueba en el
siguiente bloque o pista; al llegar al último bloque o pista volvemos al primero.

La recuperación consiste en hallar la dirección del bloque o pista probable


original, y si no se encuentra el registro pasar al siguiente bloque o pista, hasta
encontrar el registro.

11
TÉCNICAS DE DIRECCIONAMIENTO CERRADO

Son aquellas técnicas de resolución de colisiones en las que los sinónimos que
generan colisiones se almacenan en un subconjunto de las direcciones
reservadas para el fichero.

Áreas de overflow

En la creación del fichero se definen dos conjuntos de direcciones, el área


primaria y el área de overflow. En las direcciones del área primaria se
almacenarán únicamente aquellos registros que no causen colisiones. Todos
los registros sinónimos que causen colisiones se almacenarán en el área de
overflow. Para ubicar los registros en este área se pueden utilizar distintas
técnicas.

La primera consiste en almacenar los registros consecutivamente, es decir en


el primer bloque o pista con espacio suficiente. En este caso es necesaria la
utilización de la cadena de sinónimos, puesto que no hay ninguna relación
entre la clave del registro y su ubicación definitiva.

Otra posibilidad es distribuir los registros en el área de overflow a través de


funciones de hashing al igual que se puede hacer en un área primaria.

1.6. ORGANIZACIONES INDEXADAS

Las organizaciones secuenciales están orientadas a la recuperación secuencial


de los registros y las directas a la recuperación al azar de los mismos, pero la
mayoría de las aplicaciones realizan tanto accesos secuenciales como al azar.
Las organizaciones indexadas permiten que ambos modos de acceso tengan
un tiempo de respuesta satisfactorio, basándose en la utilización de índices.

12
Este tipo de organizaciones permiten acceder a un registro, suministrando su
clave. Con la clave, uno o varios datos contenidos en el registro, se accede a
un índice que permite obtener la ubicación del registro. Por tanto cada entrada
del índice contiene un valor de clave y la ubicación del registro
correspondiente. Una vez localizada la entrada de índice correspondiente a una
clave el acceso al registro debe ser inmediato.

El acceso al azar a los registros no presenta de esta forma ninguna dificultad.


Para realizar el acceso secuencial lo que realmente se hace es un acceso
aleatorio a todos los registros siguiendo el orden de las entradas del índice. Por
tanto normalmente los índices se almacenan en estructuras de datos que
mantienen ordenadas las entradas del índice utilizando como criterio de
ordenación la clave.

1.6.1. ÍNDICES

Los índices se implementan en estructuras de datos complejas, orientadas a la


búsqueda y ordenadas, que pueden ser almacenadas de diversas formas:
tablas, arrays n-dimensionales, arboles, etc. Estas estructuras de datos deben
ser almacenadas de forma permanente en el sistema. Por tanto este
almacenamiento se debe realizar en los dispositivos.

Existen dos posibilidades: almacenar la estructura de índices de cada fichero


dentro del mismo o en un fichero independiente relacionado con el que
contiene los datos. Si las estructuras de índices se almacenan en el mismo
fichero que los datos, los bloques asignados al fichero se dividen formando dos
zonas: la zona de datos y la zona de índices. Si los índices se almacenan en un
fichero independiente, se debe escoger para dicho fichero una organización
que permita acceder a los mismos de forma óptima. La ventaja de este sistema
es que para el mismo fichero pueden existir varios índices puesto que se
almacenarán en distintos ficheros.

13
DENSIDAD DE LOS ÍNDICES

Se dice que un índice es DENSO cuando tiene una entrada para cada valor de
clave que existe al menos una vez en los registros de datos del fichero y todos
los registros de datos están apuntados desde el índice. En este caso cada
entrada del índice, dependiendo de su implementación tiene que apuntar a uno
o varios registros del fichero.

Por el contrario se dice que un índice es NO DENSO cuando no tiene entradas


para todos los valores de clave existentes en los registros del fichero o cuando
teniendo entradas para todos los valores de clave quedan registros sin apuntar
desde el índice. En este caso para localizar un registro se busca en la
estructura de índices la clave que sea mayor o igual que la del registro a
localizar. En dicha entrada se encuentra el puntero al registro buscado o a un
registro del fichero tal que una vez posicionados en él nos permita el acceso al
registro buscado. Esto implica que el orden lógico del fichero mantiene como
criterio de ordenación el indicado por la clave.

JERARQUÍA DE ÍNDICES

Si el índice de un fichero es muy grande, la localización de la entrada


correspondiente a una clave requiere mucho tiempo, ya que es necesario
"recorrer" una estructura de datos compleja y realizar bastantes operaciones de
E/S. Esto supone una perdida de eficiencia en el acceso a los registros. Para
evitar estos problemas las estructuras de datos formadas por los índices
deben estar orientadas a la búsqueda, es decir, las entradas del índice deben
organizarse de forma que resulte sencillo encontrar cualquiera de ellas.

Para mejorar el tiempo de acceso a las entradas del índice se construye un


índice sobre las entradas del índice original. Esta técnica da lugar a un nuevo
índice en cuyas entradas tenemos como clave la misma que la de la entrada
del índice original correspondiente y un puntero a la misma. Este nivel superior
de índice deberá ser no denso, consiguiendo de esta forma un índice más
pequeño y por lo tanto menos costoso de manipular.
14
Si a pesar de todo este índice sigue siendo grande se crea otro nivel y así
sucesivamente. Esto da lugar a la construcción de una jerarquía de índices, de
los cuales el único que puede ser denso es el que apunta directamente a los
registros del fichero.

Todos los nuevos índices así como el original deben almacenarse en el


dispositivo, formando un nuevo fichero o como parte del fichero al que
corresponden. Por lo tanto a la hora de diseñar un sistema de índices habrá
que valorar la necesidad real de cada nuevo nivel teniendo en cuenta el
espacio de almacenamiento requerido por los mismos.

Para almacenar una jerarquía de índices se debe elegir una estructura de datos
fácil de manipular, es decir una estructura para la cual un recorrido de todos
sus elementos tenga una complejidad computacional pequeña. Las estructuras
de tipo árbol son las más apropiadas para el almacenamiento de las jerarquías
de índices.

1.6.2. EJEMPLO DE UN FICHERO CON


ORGANIZACIÓN INDEXADA

Un fichero con esta organización podría constar de:


• un conjunto de registros que se almacenan en secuencia lógica
ascendente o descendente a través de la clave primaria y que
conforman el área de datos primaria
• una estructura de índices que se almacena en el mismo fichero en un
espacio denominado área de índices
• una serie de bloques reservados como área de overflow

Siempre que se deseen realizar accesos al azar será necesaria la investigación


jerárquica de unos índices.

15
Área de datos primaria
Todos los bloques reservados para almacenar los registros del fichero deben
situarse en un conjunto consecutivo de pistas del disco que lógicamente
estarán distribuidas en varios cilindros. Todo este espacio de disco se
denomina área de datos primaria.
Este espacio se gestiona como un fichero secuencial, la ordenación física de
los registros coincide con su ordenación lógica. Los registros del fichero deben
contener la información identificada como clave. Inicialmente no se reservan
todos los bloques que posteriormente pueden ser necesarios para todos los
registros del fichero. Por tanto será necesario disponer de un espacio extra
donde se almacenarán los registros que son reubicados al insertarse nuevos
registros que deben almacenarse en una determinada pista para mantener la
secuencia de clave.

Área de overflow
Los registros que se almacenan en el área de overflow mantienen la secuencia
de clave mediante punteros que los relacionan, es decir, a diferencia de los
registros que se encuentran en el área primaria su ordenación física no
coincide con su ordenación lógica.

Un registro excedente es aquel que no se puede almacenar en su lugar


correspondiente, también se le denomina colisión. Cuando se produce un
excedente, se coloca en el área de overflow .

Área de índices
Contiene los registros índice generados según se van grabando los registros en
el área primaria. Tiene una estructura jerárquica, de tal forma que cada nivel de
índice apunta al nivel inmediatamente inferior, estando lo datos apuntados
desde el nivel más bajo de índice.

16
TEMA II
INTRODUCCIÓN A LAS BASES DE DATOS

2.1. INTRODUCCION

La era actual se caracteriza por generar, recopilar, y procesar información; más aún, el volumen
aumenta a un ritmo vertiginoso y se prevé que continúe así en el futuro. La piedra angular de
esta explosión de información estará constituida por dos áreas principales:
- Telecomunicaciones.
- Bases de Datos.

El concepto de Base de Datos no es un invento repentino en la tecnología de ordenador, sino que


más bien, ha evolucionado gradualmente a través de la experiencia y por la presión de las
exigencias.

El inicio de las bases de datos se puede remontar a 1880 cuando Dr. Herman Hollerit inventó las
tarjetas perforadas; necesitaba almacenar el censo de Estados Unidos y su tarea no estaría
terminada a tiempo con los métodos de cálculo manual. Así empezó la era de los ficheros de
tarjetas, que subsistieron como medio para el almacenamiento de la información durante los
siguientes sesenta años.

En 1950 empezaron a verse las limitaciones de los ficheros de tarjetas, ya que se necesitaba
tener un fichero de almacenamiento más rápido; era el nacimiento de los dispositivos. El
impacto de la cinta magnética fue abrumador; era mucho más ligera y fiable, y su capacidad de
almacenamiento y velocidad, comparada con el fichero de tarjetas, era enorme. Sin embargo, la
organización de los ficheros seguía siendo todavía secuencial.

Toda la terminología de los ficheros de tarjetas, como ficheros, registros y campos, se trasladó al
sistema de cinta magnética. Los sistemas de datos usados en los años 50 eran subsistemas muy
sencillos y con independencia de otros subsistemas relacionados. La situación cambió cuando

17
los analistas de sistemas introdujeron el concepto de ficheros integrados (ficheros compartidos
relativamente grandes).

La introducción de los discos magnéticos a mitad de los 60 dio el empujón final a esta
integración. Para acceder a un registro en un disco se podía hacer directamente, ganando así una
velocidad conjunta de 2 a 4 unidades de magnitud sobre la cinta magnética.

A mitad de los 60 fue ganando actualidad el concepto de Sistema de Información de Gestión


(MIS), pero pronto se encontró que para una gran organización, el número de ficheros de entrada
era excesivamente grande, con lo que aparecían problemas de ordenación y duplicación de
datos.

Uno de los productos más sobresalientes de la época fue el Integrated Data Store (IDS). Su
pionero, Charles W. Bachman, jugó un papel muy activo en el dasarrollo de la propuesta de base
de datos Codasyl, que incorporó muchas de las características del IDS.

Uno de los puntos más importantes de las primeras tecnologías de software para el manejo de
datos, fue el dasarrollo del lenguaje COBOL en 1960, logrado por la Conferencia sobre Sistemas
y Lenguajes para datos Codasyl (Conference on Data Systems and Languages). Pero los
problemas seguían apareciendo, y se encontraron con la necesidad de herramientas para ordenar
y clasificar, con aplicaciones que requerían sistemas de manejo de datos de mayor alcance, la
cantidad de información seguía en aumento ... En definitiva, se vió que hacían falta bases de
datos que tuvieran una colección integrada de datos, y que deberían ser independientes tanto del
programa como del lenguaje (se pretendía que sirvieran para todas las aplicaciones, y en
particular, que un cambio de datos no debiese requerir un cambio en el programa de aplicación).

El Codasyl se interesó por las bases de datos a finales de los sesenta, y creó un grupo de trabajo
para definir un modelo común de base de datos llamado ahora modelo Codasyl o modelo de red.
Desde la publicación de sus especificaciones en 1971, ha habido un notable movimiento
convergiendo muchos implementadores en este modelo. Paralelamente al desarrollo de Codasyl,
se fue desarrollando el modelo relacional debido al Dr. Edgar F. Codd, que fue propuesto por
primera vez en 1970. Este modelo es sencillo y muy potente, y durante años ha sido muy

18
utilizado en diversos ámbitos. A estos tipos de bases de datos (red y relacional) se les ha
denominado bases de datos tradicionales.

En los últimos años, los avances tecnológicos se han dirigido a nuevas y excitantes aplicaciones
de sistemas de base de datos, como son entre otros: bases de datos orientadas a objetos, bases de
datos multimedia, sistemas de información geográfica (GIS), almacenes de datos y sistemas de
proceso analítico on-line (OLAP), bases de datos activas y de tiempo real, etc..

2.2. CONCEPTO DE B.D.

Existen múltiples definiciones de "base de datos". Nosotros vamos a considerar la siguiente (C.J.
Date):

BASE DE DATOS: Es una estructura de datos que permite recibir y almacenar datos, así como
extraerlos a instancia de usuarios múltiples e independientes entre sí, y que en general es
'integrada' y 'compartida'.

Por integrada podemos entender que es la unificación de datos independientes donde se elimina
parcial o totalmente cualquier redundancia. Por ejemplo, si suponemos un sistema de ficheros
para la gestión de una sucursal bancaria, podíamos tener dos ficheros CLIENTES y CUENTAS
con la información relativa a los datos de los clientes y a las cuentas bancarias respectivamente,
con los siguientes campos:

CLIENTES: DNI-CLIENTE CUENTAS: NºCUENTA


NOMBRE DNI-CLIENTE
DIRECCION NOMBRE
TELEFONO SALDO

Obsérvese la redundancia existente (DNI-CLIENTE, NOMBRE). Una base de datos podría


incluir los mismos datos pero sin redundancias.

19
Por compartida podemos entender que varios usuarios pueden tener acceso a la misma parte de
la BD en la forma que le interese a cada uno y además pueden hacerlo concurrentemente.
Obsérvese que en el caso de los ficheros tradicionales, el usuario deberá ver los datos
exactamente igual a como están almacenados (el registro interno coincide con el registro
externo). Y sin embargo, en un sistema de bases de datos, cada usuario verá sólo aquellos datos
que le interesan y en la forma en que le interesan.

2.3. ELEMENTOS DE UN SISTEMA DE BD

Entre los elementos que componen un sistema de bases de datos podemos distinguir:

• Los datos almacenados en el sistema. Son los hechos básicos sobre los que se fundamentan
las necesidades de información y de procesamiento de una compañía. El factor esencial a
considerar es que los datos que conforman una base de datos tienen que ser cuidadosa y
lógicamente estructurados.

• El HARDWARE es el conjunto de dispositivos físicos sobre los que reside una base de
datos. Consiste en una o más computadoras, unidades de disco, video terminales,
impresoras, unidades de cinta magnética, cables de conexión y otros equipos auxiliares y de
conexión del equipamiento.

• El software, que recibe el nombre de Sistema de Gestión de Bases de Datos o DBMS, y


actúa como intermediario entre la base de datos física y los usuarios.

• Los usuarios. Son las personas que tienen acceso a la base de datos. Podemos considerar
tres clases de usuarios: los programadores de aplicaciones, los usuarios finales (en general
sólo realizan funciones de recuperación) y el administrador de bases de datos (control de los
datos).

20
¿Cuál es la diferencia entre los ficheros y las bases de datos? ¿En qué se diferencia el
trabajo con ficheros de la utilización de B.D.?

Consideraremos que un fichero es propio de un usuario o de una aplicación (por ejemplo, la


aplicación cuentas corrientes). Está diseñado en función de las necesidades del usuario o de la
aplicación concreta.

Cada aplicación tiene sus propios ficheros de modo que los datos de operación se hallan muy
dispersos y, por lo tanto, es probable que sean difíciles de controlar. Es una representación de
una sola concepción del mundo real.

Una B.D. tiene múltiples usuarios. Cada uno tiene su concepción de su punto de vista de la
realidad. Todas las concepciones han de estar representadas de alguna manera en la B.D.. Cada
usuario debe poder utilizar la B.D. desde su punto de vista, ignorando que hay otros usuarios
con otras vistas, es decir, independientemente de los demás.

Una B.D. se diseña, por tanto, no en función de un usuario o aplicación, ni de un grupo de ellos,
sino para todos, integrando todos los puntos de vista. Por tanto, proporciona un control
centralizado de los datos.

Este control centralizado de los datos va a poder solucionar algunos problemas que se plantean
en el caso de ficheros convencionales, tales como:

• La redundancia, que puede aumentar los costos de almacenamiento y acceso, y puede


provocar problemas de inconsistencia (Por ejemplo, si tenemos la dirección de un cliente
en varios ficheros y dicho cliente cambia de domicilio, habría que realizar
actualizaciones en todos aquellos ficheros donde aparezca el campo dirección. En caso
de olvidarse alguno, se produciría un problema de inconsistencia.)
• La compartición de los datos, que en el caso de los ficheros es difícil llevarla a cabo.
• La seguridad de los datos
• La integridad de los datos (hacer que ciertos campos cumplan determinadas normas, por
ejemplo, que el valor de un saldo no sea negativo).

21
• Los cambios de diseño en el modelo o en el almacenamiento podrían provocar la
necesidad de cambios en las aplicaciones. Por tanto, un objetivo será proporcionar la
independencia de los datos de forma que eso no ocurra.

Todos estos problemas deberán ser resueltos en el mayor grado posible por el S.G.B.D.

2.4. EL SISTEMA DE GESTION DE BASE DE DATOS (S.G.B.D.)

La solución a la mayoría de los problemas planteados en los sistemas de ficheros, se intentarán


solucionar en los sistemas de bases de datos mediante el aislamiento del almacenamiento de los
datos por medio del S.G.B.D.. (En inglés Data Base Management System - DBMS).

Para poder utilizar una B.D. se precisa del S.G.B.D. que se puede considerar como un conjunto
de programas y dispositivos físicos asociados que permiten gestionar una B.D. o modelar una
parte del mundo real. Es el intermediario entre la B.D. física y el mundo exterior.

2.4.1.- OBJETIVOS DEL S.G.B.D.

Los objetivos que pretende alcanzar todo S.G.B.D. son:

- Independencia física
- Independencia lógica
- Eficacia de los accesos a los datos
- Administración centralizada de los datos
- No redundancia de los datos
- Integridad de los datos
- Compartibilidad de los datos
- Seguridad de los datos

22
a) INDEPENDENCIA FISICA

Se refiere al almacenamiento de los datos. Uno de los objetivos primordiales de los S.G.B.D. es
conseguir la independencia entre las estructuras de almacenamiento y las estructuras de datos
del mundo real.

Las ventajas de la independencia física se comprenden fácilmente cuando se consideran los


inconvenientes de la no independencia física. Esta implicaría que la forma en la que están
organizados los datos en la memoria secundaria fuese una imagen directa de la organización de
los datos en el mundo real. Para poder conservar las posibilidades de optimización en los
sistemas informáticos, los conceptos de métodos de acceso, modos de ubicación, criterios de
clasificación, encadenamientos, codificación de los datos, etc, deberían aparecer directamente
en el mundo real y por tanto en las aplicaciones. Todo cambio informático repercutiría en la
vida de una empresa e implicaría una reconstrucción de las aplicaciones.

Desde luego esto no es práctico y de ahí surge la necesidad de independencia entre las
estructuras de almacenamiento y los datos del mundo real.

Por ejemplo, si en un sistema de ficheros dividimos un fichero en dos partes aún manteniendo la
misma información, será preciso modificar todos los programas que trabajen con él. Lo mismo
ocurriría si cambiásemos la organización del fichero; por ejemplo si reemplazásemos un fichero
secuencial indexado por uno aleatorio, sería preciso realizar modificaciones importantes en la
aplicación.

En una B.D. se pretende que al modificar el almacenamiento de los datos, no sea preciso
modificar las aplicaciones. Y por tanto, podemos definir la independencia de los datos como la
inmunidad de las aplicaciones a los cambios de la estructura de almacenamiento y de la
estrategia de acceso.

23
b) INDEPENDENCIA LOGICA

Hace referencia al modelo de datos y la podemos definir como la capacidad de modificar el


esquema conceptual sin obligar a que se vuelvan a escribir los programas de aplicación.

Cada grupo de trabajo encargado de desarrollar una aplicación debe de poder agrupar los datos
con arreglo a sus necesidades, para formar entidades y asociaciones. Además, cada grupo debe
poder concentrarse en aquellos elementos que constituyen su centro de interés, es decir, debe
poder trabajar conociendo solamente una parte de la semántica de los datos.

Además siempre que se altera la estructura lógica de la BD (por ejemplo, para añadir un nuevo
tipo de entidad, son necesarias modificaciones en el nivel conceptual.

En el caso de un sistema clásico de ficheros, si añadimos nuevos datos a un fichero concreto,


habrá que modificar todas las aplicaciones que trabajan con dicho fichero.

Se pretende que en un sistema de B.D. esto no ocurra, y para ello deberá permitirse cierta
independencia entre los datos vistos por las aplicaciones y la estructura canónica de los datos.
Las ventajas que esto supondría son:

- Permitir que cada grupo de trabajo vea los datos tal y como le interesan.
- Permitir la evolución de la visión de cada grupo y de la visión canónica (añadir,
suprimir, etc.) sin que sea preciso modificar la mayoría de las aplicaciones.

La independencia lógica de los datos es más difícil de lograr que la independencia física, ya que
los programas de aplicación dependen en alto grado de la estructura lógica de los datos a los que
tienen acceso.

24
c) EFICACIA DE LOS ACCESOS A LOS DATOS

En primer lugar, hay que tener en cuenta que determinados accesos a los datos son realizados
por informáticos expertos, que conocen la estructura del almacenamiento de los datos y que
deben contar con unos lenguajes de manipulación de datos muy eficaces que permitan acceder
rápidamente a los datos a través de los caminos de acceso definidos en la estructura del
almacenamiento. Se podrían utilizar estos lenguajes dentro de programas clásicos escritos en un
ensamblador o en lenguajes de más alto nivel como COBOL, PL/I, PASCAL, etc.

En segundo lugar, tanto los informáticos como los no informáticos que desconocen la estructura
de almacenamiento, deben tener posibilidad de utilizar un lenguaje no sujeto a procedimientos
cuya implantación tiene que ser muy eficaz, especialmente a nivel de los accesos a discos, que
siguen siendo el cuello de botella fundamental de los S.G.B.D.

Los grupos no informáticos verán los datos independientemente de cómo se haya realizado su
implantación en la máquina y, por tanto, podrán manipular los datos por medio de lenguajes no
sujetos a procedimientos, es decir, describiendo los datos que desean consultar (o actualizar) sin
necesidad de describir la forma en que hay que consultarlos (o actualizarlos), la cual es propia de
la máquina.

d) ADMINISTRACIÓN CENTRALIZADA DE LOS DATOS

Unas funciones esenciales de los S.G.B.D. son la definición de las estructuras de


almacenamiento y las estructuras de datos, y el seguimiento de sus evoluciones. Estas funciones
reciben el nombre de administración de los datos.

Con el fin de permitir un control eficaz de los datos, resolver los conflictos entre los diferentes
puntos de vista no siempre coherentes, poder optimizar los accesos a los datos y la utilización
de los medios informáticos, es esencial que la administración de los datos esté centralizada. La
persona que tiene este control es el administrador de bases de datos. Algunas de sus funciones
son:

25
- Definir el esquema original de la base de datos.
- Definir la estructura de almacenamiento y método de acceso.
- Modificación del esquema y de la organización física.
- Garantizar que los datos que requieran los usuarios estén disponibles y escribir los
esquemas externos necesarios.
- Conceder diferentes controles de autorización para el acceso a los datos, a los distintos
usuarios, y los procedimientos de validación.
- Especificar las reglas de integridad.
- Definir una estrategia de respaldo y recuperación.
- Controlar el rendimiento y responder a los cambios de requerimientos.

e) NO REDUNDANCIA DE LOS DATOS

En los sistemas clásicos de ficheros no integrados, cada aplicación tiene sus propios datos. Esto
conduce generalmente a numerosas duplicaciones de los datos con un importante desperdicio
de recursos humanos para capturar y actualizar los mismos datos varias veces, además de la
consiguiente pérdida de espacio en memoria secundaria.

En una B.D., los ficheros más o menos redundantes, se integran en un sólo fichero compartido
por las distintas aplicaciones. La administración coherente de los datos debe velar por la no
duplicación física de los datos, a fin de evitar las actualizaciones múltiples.

Sin embargo, hay que tener en cuenta que en algunos casos por razones comerciales o técnicas
es necesario mantener múltiples copias de los mismos datos. En dichos casos, la redundancia
debe controlarse para que no se produzcan inconsistencias.

f) INTEGRIDAD DE LOS DATOS

Un S.G.B.D. debe vigilar que las aplicaciones respeten ciertas reglas cuando se modifiquen los
datos (Ej. Mes entre 1 y 12, ó que un sueldo esté comprendido entre 600 y 3000 euros),
asegurando así su coherencia. Estas reglas se denominan restricciones de integridad.

26
Las restricciones de integridad pueden considerarse como un conjunto de aserciones para que se
obedezcan durante la actualización de una B.D., para la conservación de un estado sin errores.

Algunas restricciones pueden estar incorporadas como parte de la estructura de datos (como el
tipo de componente, en el tipo de registro y en las entradas del tipo de asociación del esquema
conceptual) mientras que otras requieren especificaciones especiales.

Vamos a analizar algunas pruebas de integridad importantes sobre requerimientos de integridad


como son:

a) Sobre datos elementales

- Prueba de tipo: Consiste en que el DBCS compruebe el tipo de los valores de los
datos elementales.
- Prueba de redundancia: Comprobar si existe redundancia directa (un valor es copia
de otro) o indirecta (un valor puede deducirse de uno o varios valores distintos).
- Prueba de rango: Asegura que un valor de un dato elemental único o un conjunto de
valores combinados, estén dentro de un rango especificado de valores permisibles. Por
ejemplo, la fecha 29/02/91 no es válida aunque el día 29, el mes 02 y el año 91, como
datos elementales, son válidos.
- Prueba de comparación: Se compara una función de un conjunto de valores de datos
elementales con otra. Por ejemplo, una restricción sería que el incremento salarial medio
de un grupo de trabajadores sea igual al de otro grupo.

b) Sobre registros

Un tipo de registro puede tener restricciones en su número total de ocurrencias o en las


inserciones y borrados. Por ejemplo, no borrar los registros de empleados que han dimitido hasta
final del mes, o bien que no puedan estar de vacaciones más de tres empleados de un
departamento a la vez.

27
c) Sobre asociaciones

Una cuestión interesante es si puede borrarse o no un registro propietario en presencia de los


registros miembro. En general, pueden establecerse tres opciones:

• No permitir eliminar un propietario en el caso de que tenga algún miembro


• Permitir eliminar el propietario, dejando sus miembros sin propietario
• Sustituir el propietario a eliminar por otro, de forma que los miembros no queden sin
propietario

g) COMPARTICION DE LOS DATOS

Su objetivo es permitir que las aplicaciones compartan los datos de la base simultáneamente sin
que se produzcan interferencias..

Cuando se aplica un tratamiento a una B.D., normalmente pasa por unos estados transitorios
durante los cuales ya no se verifican algunas restricciones de integridad. Con el fin de aislar
aquellas unidades de tratamiento que respetan la coherencia de la B.D., se introduce el concepto
de transacción:

Definimos como Transacción a la unidad de tratamiento secuencial ejecutada por un usuario


y que, aplicada a una B.D. coherente, devuelve una B.D. coherente. Una transacción está
compuesta por unidades de tratamiento más concretas llamadas acciones (mandatos indivisibles
tales como 'LEER X --> X1').

Hay que tener en cuenta, que uno de los conceptos más importantes en los sistemas modernos es
el de la multiprogramación. Si se ejecutan varias transacciones al mismo tiempo, pueden
compartir el procesador entre ellas. Normalmente, una transacción se ejecuta hasta un punto en
que debe esperar (casi siempre a que termine una operación de entrada/salida). En un sistema sin
multiprogramación el procesador permanecería ocioso. Con multiprogramación se intenta
aprovechar ese tiempo de manera productiva. En un momento dado, se dispone de varias

28
transacciones que deben ejecutarse. Cuando es preciso que una transacción espere, el sistema
saca el procesador de esa transacción y lo asigna a otra. Los beneficios que se obtienen son:
- un mejor aprovechamiento del procesador
- una productividad total de transacciones más alta (productividad es la cantidad de
trabajo realizado en un intervalo de tiempo dado)

El control de la concurrencia es la parte del S.G.B.D. que controla la ejecución simultánea de


transacciones de manera que se producen los mismos resultados que en la ejecución secuencial.
Es decir, el control de las concurrencias hace que la compartición de los datos sea
completamente transparente para el usuario.

Un sistema de B.D. ejecuta generalmente un conjunto de transacciones simultáneas para


diferentes usuarios. Los problemas de concurrencia surgen de las interferencias que puedan
producirse entre estas distintas transacciones como consecuencia de la compartición de los
datos.

Por ejemplo, el caso más típico de la pérdida de operaciones es la pérdida de actualizaciones.


Este problema surge porque una transacción, durante la ejecución de una acción ai, puede leer un
objeto de área temporal correspondiéndole después la modificación de dicho objeto durante la
acción aj a partir de los valores leídos anteriormente y mientras tanto se ha producido entre las
acciones ai y aj una actualización ak de ese objeto por otra transacción. En este caso la acción ak
se pierde (Véase la figura 1.1.).

El S.G.B.D. deberá disponer de mecanismos para evitar que se produzcan este tipo de errores.
Es decir, una aplicación debe poder acceder a los datos como si fuese la única que los está
utilizando, sin esperar y también sin necesidad de saber que cualquier otra aplicación puede
modificarlos concurrentemente.

29
ai: LEER X --> X1

ak: LEER X-->X2


X2+1-->X2
T2
T1 ESCRIBIR X2-->X

aj: X1+1--> X1

ESCRIBIR X1-->X

tiempo

Figura 1.1. T1 y T2 incrementan el valor de X en una unidad respectivamente.

h) SEGURIDAD DE LOS DATOS

El objetivo de las medidas de seguridad es proteger la base de datos contra fallos lógicos o
físicos. Puesto que se va a permitir la compartición de datos, éstos deben estar protegidos contra
los accesos no autorizados o malintencionados. La confidencialidad de la información en una
B.D. es de suma importancia. La información es poder que puede utilizarse para dañar a otros,
y por lo tanto deben existir mecanismos adecuados para controlar o retirar las autorizaciones de
acceso de cualquier usuario para cualquier conjunto de datos.

Resumiendo, el sistema deberá asegurar que a los datos que almacenados en la B.D. sólo puedan
acceder las personas autorizadas y en la forma autorizada.

Dentro de las técnicas relativas a la seguridad hay que considerar en primer lugar, las técnicas
para identificar al usuario, y en segundo lugar, las técnicas para determinar si un usuario está
autorizado a hacer el acceso que solicita.

30
- Identificación del Usuario

La identificación del usuario consiste en determinar quién es la persona que está solicitando
acceder a la B.D. desde un terminal. Dicha identificación se puede llevar a cabo según diversas
técnicas:

• Por medio de sus conocimientos, en general, una palabra de paso o bien preguntas cuyas
respuestas sólo conoce la persona autorizada (nombre de un abuelo, fecha de nacimiento de
un hermano, etc.)
• Por medio de instrumentos que lleva consigo, principalmente tarjetas perforadas o
magnéticas o por medio de llaves para los terminales.
• Por medio de las características físicas del individuo, tales como huellas digitales, geometría
de la mano, la voz, la firma (evolución y aceleración de la pluma, no la forma).

- Determinación de los Accesos Permitidos

Una primera alternativa que se plantea es la de que estén permitidos todos los accesos mientras
que no se diga lo contrario, o bien que estén prohibidos mientras no se diga lo contrario.

Cada autorización puede tener su propia lista de operaciones permitidas o bien puede ser que se
le asigne un nivel de autorización, lo que significa que todos los usuarios con el mismo nivel de
autorización pueden hacer las mismas operaciones.

Ejemplo de MATRIZ DE AUTORIZACIONES: Consideremos dos relaciones que describen los


objetos NOMBRE y CALIFICACIONES de unos estudiantes, y tres sujetos: estudiantes,
secretarias y profesores. Las operaciones que pueden llevar a cabo los sujetos sobre los objetos
son: lectura y escritura.

Las autorizaciones pueden codificarse con dos bits: permiso de escritura y permiso de lectura. Si
su valor es 0 el acceso está prohibido, y si es 1, el acceso está permitido.

Así, la matriz de autorizaciones podría ser:

31
NOMBRE CALIFICACIONES
ESTUDIANTE 00 01
SECRETARIA 11 01
PROFESOR 11 11

Esta matriz puede almacenarse por líneas, por columnas o por elementos sujeto-objeto.

Ejemplo de NIVELES DE AUTORIZACION: Consideremos que se asocia un nivel de


autorización a los sujetos y a los objetos. Entonces, un acceso está autorizado si y sólo si el nivel
del sujeto que accede es mayor o igual que el nivel del objeto accedido. Utilizando los mismos
sujetos y objetos del caso anterior, se podrían asignar los siguientes valores:

Estudiante (1) Nombre (1)


Secretaria (2) Calificación (3)
Profesor (3)

Otro aspecto relativo a la seguridad de la base de datos consiste en la recuperación de la misma


cuando se ha producido un fallo. Todo SGBD debe contar con recursos para recuperarse de
fallos de hardware o de software. El subsistema de copias de seguridad (backup) y
recuperación del SGBD es el responsable de llevar a cabo dicha recuperación. Por ejemplo, si
el sistema falla mientras se está ejecutando un complejo programa de actualización, el
subsistema de recuperación se encargará de asegurarse de que la base de datos se restaure al
estado en el que estaba antes de que comenzara la ejecución de dicho programa. Como
alternativa, el subsistema de recuperación puede asegurarse de que el programa reanude su
ejecución en el punto en que fue interrumpido, de modo que su efecto completo se registre en la
base de datos.

32
TEMA III
DISEÑO DE BASE DE DATOS

La arquitectura de una base de datos determina su capacidad para satisfacer las necesidades del
usuario de forma fiable, efectiva y eficiente.

3.1.- ARQUITECTURA ANSI/SPARC

La información que queremos almacenar en una base de datos se compone de cosas o entidades
y sus características estáticas y dinámicas. Las características de entidades que comprenden
datos, relaciones entre datos, y restricciones de uso constituyen el contenido de nuestra base de
datos.

A mediados de los 60 se realizó la propuesta de la comisión SPARC del American National


Standards Institute (Instituto Nacional Americano de Normas) para especificar un modelo para
la estandarización de las bases de datos. Dicha propuesta (conocida con el nombre de
ANSI/SPARC) que consistía en una arquitectura de base de datos a tres niveles (conceptual,
externo e interno) y un diccionario de datos integrado, recibió una amplia aceptación y puso las
bases del actual pensamiento sobre arquitectura de BD. En la figura 2.1 se muestran los
elementos básicos de la misma.

33
Programa Programa Programa
de de de
usuario 1 usuario 2 usuario 3
Nivel
externo

Esquema Esquema Esquema


externo 1 externo 2 externo 3

Percep- Nivel
ESQUEMA CONCEPTUAL
ción conceptual
Formalización

ESQUEMA INTERNO

Nivel
interno

BASE
DE
DATOS

Figura 3.1. Arquitectura ANSI/SPARC

34
3.1.1. NIVEL CONCEPTUAL

El primer paso para diseñar una base de datos es la descripción formal de los datos,
independientemente de cualquier consideración de almacenamiento. A esta descripción lógica
de los datos que representa el modelo de información que nos interesa se le denomina
"esquema conceptual". Como mínimo contiene las descripciones de:

- tipos de registro entidad


- tipos de asociación
- restricciones de integridad

Es importante tener en cuenta que un esquema conceptual no debe contener ninguna cláusula
dependiente del almacenamiento (independencia física). Por ejemplo, al describir un registro
entidad, se deberían especificar los tipos de datos de atributo (entero, real, caracter, ...) y su
longitud (número máximo de dígitos o caracteres) pero no características de almacenamiento,
como número de bytes ocupados.

3.1.2. NIVEL INTERNO O DE ALMACENAMIENTO

En el siguiente nivel se describe la estrategia de almacenamiento para los datos de la BD con


miras a optimizar el tiempo de ejecución y la utilización del espacio de almacenamiento. El
resultado final es una descripción que organiza el contenido del esquema conceptual en las
realidades de los ordenadores y se denomina "esquema interno o de almacenamiento".

Los conceptos básicos de un esquema interno son:

a) ESTRATEGIA DE ALMACENAMIENTO
- reparto del espacio de almacenamiento para datos e índices
- descripciones para almacenamiento de registros
- control de la redundancia de datos
- colocación de registros y estrategia para generar identificadores internos
- técnica para la implementación de asociaciones
35
- estrategia para manejo de desbordamientos

b) CAMINOS DE ACCESO
- especificación de claves (primaria y secundarias)
- índices y técnicas de hashing para claves, y punteros para encadenar registros en una
sucesión específica

c) DIVERSOS
- técnicas de compresión de datos, si las hay
- técnicas de encriptación de datos, si las hay
- mapeado del esquema de almacenamiento en el esquema conceptual (correspondencia
entre objetos conceptuales y objetos de almacenamiento)

3.1.3. NIVEL EXTERNO

En este nivel se especifica cómo pueden entrar los programas de usuario en la BD. Esto se hace
introduciendo "puertas" a través de un tercer nivel de descripciones, llamadas "vistas de
usuario" o "esquemas externos".

Un esquema externo describe los datos necesarios para una aplicación específica
proporcionando las siguientes funciones principales:

- selecciona un subconjunto lógico de datos que se necesita para la aplicación deseada


- el conjunto se representa de la forma más conveniente para el lenguaje de usuario
deseado
- restringiendo el acceso del usuario a ese subconjunto de datos, se contribuye a la
protección de la privacidad de los datos

El esquema externo podría contener:

- tipos de registro entidad (sólo los necesarios)


- tipos de asociación (sólo los necesarios)
36
- restricciones de integridad adicionales sobre las especificadas en el esquema
conceptual
- entradas para el mapeado del esquema externo en el conceptual

Sin embargo, dependiendo del lenguaje de usuario deseado, este subconjunto de datos puede
describirse mediante diferentes tipos de estructuras de datos.

Estos tres niveles, conceptual, interno y externo forman la base de la arquitectura de las
modernas bases de datos. Mientras que sólo existe un esquema conceptual y un esquema
interno, pueden existir muchos esquemas externos, uno para cada tipo de necesidad.

37
3.2. ETAPAS DE DISEÑO

A continuación, se comentan a grandes rasgos, las etapas que se siguen para llevar a cabo el
diseño de una base de datos, desde su concepción hasta el momento en que está disponible para
ser utilizada.

PRIMERA ETAPA: "ANALISIS"

Incluye la elección de los objetos, sus características, sus relaciones, etc. Es decir, en esta
etapa se trata de obtener una estructura conceptual. Para ello se precisa de un modelo de datos.

Un MODELO DE DATOS es un instrumento teórico que permite representar los datos a tratar.
Para ello incluye un conjunto de conceptos y reglas que permiten describir las diferentes
entidades, atributos, y relaciones existentes en una determinada parcela del mundo real. Una
ENTIDAD es un objeto real o abstracto con interés para la organización (clientes, artículos,
alumnos, países, vehículos, etc.). Un ATRIBUTO en una propiedad o característica de una
entidad (DNI del cliente, código del artículo, nombre del alumno, color del vehículo, etc.). Una
RELACION consiste en una asociación no trivial entre los componentes de un modelo, es decir,
es una asociación cuya no inclusión supone una pérdida de información.

SEGUNDA ETAPA

La segunda etapa se centra en los siguientes pasos:


- Elección del S.G.B.D. (jerárquico, red, relacional).
- Adaptación de la estructura conceptual a las características del modelo del S.G.B.D. elegido
(obtención del modelo canónico)
- Descripción del esquema conceptual (utilizando un lenguaje de definición de datos
conceptual).
- Diseño y descripción del esquema interno (utilizando un lenguaje de definición de datos
interno).

38
TERCERA ETAPA

La última etapa, incluye las siguientes tareas:


- Diseño y descripción de esquemas externos (definen los datos para una aplicación dada)
utilizando un lenguaje de definición de datos externo.
- Diseño y codificación de los programas de aplicación que actuarán sobre la base de datos.

39
3.3. MODELOS DE DATOS

Se ha comentado ya, que para poder representar el esquema conceptual se requiere la utilización
de un modelo de datos. Algunos modelos que habitualmente se usan para ello son:
• Entidad-Relación (más utilizado).
• Entidad-Relación extendido
• RM/T.
• Modelo de Abrial.

Nos limitaremos a comentar el primero de ellos.

3.3.1. MODELO ENTIDAD-RELACION

El modelo Entidad Relación (E-R) fue desarrollado por Peter P. Chen en 1976-77, aunque
posteriormente muchos autores han investigado y escrito sobre el modelo, proponiendo
importantes aportaciones.

Sus ideas básicas son las siguientes:

1.- Los seres se agrupan en conjuntos o tipos de ENTIDADES que se representan mediante un
rectángulo.
Una entidad es cualquier objeto, real o abstracto, sobre el que queremos tener información en la
base de datos, y que tiene existencia por sí mismo. Una entidad puede representar a un conjunto
de personas (como empleado, estudiante y paciente), a un conjunto de lugares (como región,
país o ciudad), a un conjunto de objetos (como máquina, edificio, automóvil), etc..

CLIENTE

Conjunto de entidades

40
2.- Los conjuntos de entidades se asocian creando RELACIONES que se representan por medio de
rombos y flechas.
Una relación es una asociación o correspondencia entre entidades.

Titularidad

Conjunto de relaciones

Las relaciones pueden ser de varios tipos:

Relación de 1 a 1 R

Relación de 1 a N R

Relación de N a M R

- de uno a uno: Dados dos conjuntos de entidades A y B, una entidad en A está relacionada con
una única entidad en B, y una entidad en B está relacionada con una única entidad en A.

a11 b1

a2 b2

a3
b3

41
- de uno a muchos (1-N): Una entidad en A está relacionada con cualquier número de entidades
en B, pero una entidad en B puede asociarse únicamente con una entidad en A.

a11 b1

a2 b2

a3
b3

- de muchos a uno (N-1): Una entidad en A está relacionada con una sola entidad en B, y una
entidad en B puede estar relacionada con cualquier número de entidades en A.

a11 b1

a2 b2

a3
b3

42
- de muchos a muchos (N-M): Una entidad en A está asociada con cualquier número de
entidades en B, y una entidad en B está asociada con cualquier número de entidades en A.

a11 b1

a2 b2

a3
b3

Por ejemplo, si consideramos dos entidades CLIENTE y CUENTA, sabemos que un cliente
puede tener varias cuentas en un banco y por lo tanto podemos concluir que:
• la relación TITULARIDAD establecida entre CLIENTE y CUENTA será de 1 a N en el
caso de que cada cuenta sólo pueda pertenecer a un cliente.
• la relación TITULARIDAD entre CLIENTE y CUENTA será de N a M en el caso de que
una determinada cuenta pueda pertenecer a varias personas.

Además las relaciones pueden ser de varios grados:

Grado 1: Se asocia un sólo tipo de entidad consigo misma.

TEMA consta

43
Grado 2 - BINARIA: Asocia dos tipos de entidad.

Escribe
AUTOR LIBRO

Grado 3 - TERNARIA: Asocia 3 tipos de entidad.


A veces, no es propiamente de tal grado, ya que puede descomponerse en varios tipos de
relación que asocien tipos de entidad dos a dos, es decir, en varios tipos de relación de grado 2.
Sin embargo, otras veces no es posible tal descomposición, ya que la semántica recogida en una
y otra solución no es la misma. Por ejemplo:

En la Figura 2.2, la relación ESCRIBE asocia tres entidades: un autor con el tema a cerca del
cual escribió en un determinado libro. Se supone que un libro puede estar escrito por varios
autores y cada uno puede tratar en él temas distintos.

AUTOR

Escribe-1 Escribe-2
escribe

TEMA trata LIBRO

Figura 3.2. Relación ternaria ESCRIBE.

Si sustituyo ESCRIBE por 'ESCRIBE-1', 'ESCRIBE-2' y 'TRATA', no se puede deducir qué tres
ocurrencias determinadas de las distintas entidades estaban asociadas en una ocurrencia de
relación concreta. Por tanto, no es posible la descomposición sin pérdida de semántica.

44
Sin embargo, en el siguiente ejemplo de la Figura 2.3., la relación PUBLICA puede ser
descompuesta en 'ESCRIBE', 'CONTRATA' y 'EDITA', ya que aportan la misma semántica.

AUTOR

Escribe contrata
publica

LIBRO edita EDITORIAL

Figura 3.3. Tres relaciones binarias.

3.- Las cualidades denominadas ATRIBUTOS, que se representan mediante círculos, pueden
enriquecer a entidades y relaciones.

nºcuenta

Por ejemplo, una entidad CUENTA puede tener como atributos nº cuenta y saldo; una
entidad CLIENTE puede tener como atributos DNI, nombre, dirección y teléfono; una
relación TITULARIDAD puede tener como atributo Fecha_participación

A los identificadores de los seres se les llama CLAVES de las entidades y relaciones. Cada
clave puede estar formada por uno o más atributos y se escoge una de ellas como CLAVE
PRIMARIA.

Las entidades con clave primaria, se denominan ENTIDADES REGULARES. Sin embargo,
pueden existir conjuntos de entidades que no tienen suficientes atributos para formar una clave
primaria. Estas entidades sin clave se llaman ENTIDADES DEBILES y se identifican a través
45
de alguna relación, es decir, por medio de la clave primaria de la entidad fuerte de la que
dependen, más un discriminador (nº). Se representan mediante dos rectángulos concéntricos.

HIJO

CLIENTE ............... Entidad regular o fuerte


HIJO DE CLIENTE ....... Entidad débil

46
EJERCICIOS

EJERCICIO 1

Construir un diagrama de Entidad-Relación para una compañía de seguros automovilísticos que


cuenta con un conjunto de personas cada una de los cuales posee cierto número de vehículos.
Cada automóvil está relacionado con un número de accidentes registrados. Nos interesa registrar
los datos de las personas, de los automóviles para los cuales han contratado seguro con la
compañía, así como de los accidentes que han sufrido dichos automóviles y que inciden en el
cálculo de la cuota anual del seguro.

EJERCICIO 2

Construir un diagrama Entidad-Relación para un hospital que tiene un conjunto de pacientes y


un conjunto de médicos. Nos interesa saber qué médico atendió al paciente en cada una de sus
visitas/ingresos en el hospital, así como el diagnóstico que se le realizó en cada ocasión.
También cada paciente tiene relación con un historial de los diferentes análisis que se le han
realizado en el hospital con indicación de la fecha, tipo de análisis y resultado del mismo.

EJERCICIO 3

Diseñar un esquema E/R que recoja la organización de un sistema de información sobre


municipios, viviendas y personas. Las viviendas se agrupan en edificios de diferentes tipos
(pisos, adosado, etc…). Cada persona sólo puede habitar en una vivienda, pero puede ser
propietaria de más de una. Nos interesa también la interrelación de las personas con su cabeza de
familia.

Hacer los supuestos semánticos complementarios que se consideren oportunos para justificar
todas las decisiones de diseño.

47
EJERCICIO 4

Se pretende diseñar una Base de Datos para gestionar toda la información de una empresa de
coches de alquiler. Esta empresa consta de cinco delegaciones ubicadas en Bilbao, San
Sebastián, Vitoria, Madrid y Barcelona.

Cada una posee una serie de coches para poder ser alquilados por los clientes.

De cada coche se requiere registrar al menos la siguiente información: número de matrícula,


marca, color y modelo.

Los clientes alquilan los coches durante un cierto período de tiempo, y aunque cada cliente
pertenezca a una delegación concreta (su información se gestiona desde una delegación),
puede alquilar coches de cualquiera de ellas.

Existen además una serie de concesionarios que revisan los coches independientemente de la
delegación a la que pertenecen y de la marca del coche.

Para mejorar la calidad del servicio prestado, los coches son revisados por uno de estos
concesionarios cuando han sido alquilados un número de veces determinado.

Este número de veces máximo se decide en la Junta General al principio de cada año.

Por ello, se debe poder obtener para cada coche los clientes que lo han alquilado durante un
período de tiempo y en qué fecha.

Las operaciones más habituales son:

• Dada una determinada delegación, obtener la dirección de sus clientes para poder enviarles
diferente información: propaganda, ofertas, facturas ...

• Obtener un listado de los coches de una delegación, con los nombres de los clientes que
han alquilado cada coche en una determinada fecha.

• Listado de los coches que necesitan revisión porque han sido alquilados el número
máximo de veces establecido.

48
• Listado de todas las revisiones efectuadas a un coche, la fecha en que se han realizado, y
en qué concesionario cada vez.

Se pide realizar el diseño de dicha Base de Datos utilizando el modelo Entidad-Relación


de forma que las consultas más habituales se realicen de la manera más óptima y añadiendo
toda la información que consideres necesaria.

EJERCICIO 5

Deseamos diseñar una BD que recoja la organización de una universidad. Se considera que:

• Dentro de la Universidad existen varias Facultades, cada una de las cuales se estructura en
varios departamentos. Consideraremos que un departamento pertenece a una sola Facultad.
• Los profesores pueden impartir varias asignaturas distintas pertenecientes a uno o más
departamentos de su Facultad o de otra, pero deberán tener adscripción primaria a un sólo
departamento. De entre los profesores con adscripción primaria a un determinado
departamento, se escoge uno como director del mismo.
• Cada departamento engloba a varias asignaturas de las titulaciones que se imparten en la
Facultad. Las asignaturas de un departamento se agrupan en áreas de conocimiento para una
mejor gestión. Por ejemplo, en el Departamento de Ingeniería del Software tenemos áreas
tales como Ciencias de la Computación e Inteligencia Artificial (Compiladores I,
Compiladores II, Inteligencia Artificial, etc.) y el área de Programación (Fundamentos de
Programación, Programación y Bases de Datos, etc.).

Algunas de las consultas más habituales a la BD son.


• Listado de profesores de una facultad determinada, agrupados por departamentos.
• Listado de profesores de la Universidad que son jefes de Departamento.
• Listado de Departamentos de una Facultad con indicación de áreas y asignaturas de cada una.
• Listado de asignaturas que imparte un determinado profesor.
• Listado de catedráticos de la universidad.
• Listado de asignaturas de una determinada titulación.

49
Se pide diseñar el diagrama de Entidad-Relación correspondiente.

EJERCICIO 6

Deseamos diseñar una base de datos para gestionar la información que se maneja en una
cadena de hoteles anualmente. Las características más relevantes que deseamos reflejar son
las siguientes:

• La cadena consta de varios hoteles, cada uno de ellos con un identificativo, un nombre, un
número de estrellas determinado y ubicado en una ciudad concreta.
• Cada hotel consta de varias plantas en las cuales tenemos habitaciones y/o salones. Las
habitaciones pueden ser de varios tipos (individual, doble, suite, ..) y los salones tienen
diversas características y capacidades.
• Los clientes que acuden al hotel pueden ser particulares o empresas que contratan una
habitación o un salón durante uno o varios días. Al finalizar su estancia o utilización,
abonan el importe correspondiente. En el caso de contratar un salón, deberá registrarse en
la BD el uso que se le ha dado (exposición, conferencias, congreso, cursillo, etc...)
• Todos los clientes, sean empresas o particulares se registran con un identificativo que es
el NIF, además de otros datos como nombre, dirección y teléfono.
• La factura que abona un cliente al final de su estancia consiste en el importe de la
habitación más el importe del teléfono.

Algunas de las operaciones más frecuentes son:

• Obtener las habitaciones que se ocuparon en un hotel durante un periodo de tiempo


determinado y el importe total que se facturó por cada una.
• Dado un cliente (empresa), obtener qué salones ha contratado durante un periodo
determinado, y que uso les ha dado.
• Dado un cliente (particular), obtener qué habitaciones ha contratado durante el año y en
qué fechas.
• Calcular el gasto telefónico de un cliente durante el año.
• Listar las habitaciones que hay en cada hotel de un determinado tipo, por ejemplo suite.

50
Se pide realizar el diseño conceptual utilizando el modelo Entidad-Relación.

EJERCICIO 7

Un farmacéutico decide diseñar una BD que le sirva para organizar su farmacia. Para ello desea
tener registrados todos los medicamentos que vende habitualmente con los síntomas que curan y
los laboratorios que los suministran.

Tener en cuenta que existen medicamentos genéricos que los suministran distintos laboratorios
con diferente nombre comercial pero que en esencia tienen la misma composición química.
Vamos a suponer que los médicos emiten las recetas indicando el medicamento genérico y no el
nombre comercial (Por ejemplo, el médico receta amoxicilina, y el paciente compra Clamoxyl,
que es uno de los medicamentos comerciales cuyo contenido es amoxicilina).

En cada receta aparecerá el número de colegiado y nombre del médico que la emite, el nºss y
nombre del paciente, así como el medicamento recetado con la dosis y forma en que debe
administrarse, y la fecha.

Teniendo en cuenta que la base de datos debe dar servicio a las siguientes aplicaciones, diseñar
el esquema conceptual utilizando el modelo Entidad-Relación:

• Obtener todos los medicamentos genéricos recomendados para un determinado síntoma (por
ejemplo, medicamentos que curan la irritación de garganta).
• Obtener todas las recetas que se han realizado de un medicamento genérico concreto durante
un periodo.
• Obtener todos los medicamentos que suministra un laboratorio.
• Obtener qué medicamentos comerciales se corresponden con un genérico determinado y sus
precios.
• Obtener la composición química de un medicamento genérico .
• Obtener a qué pacientes se les ha recetado un determinado medicamento genérico.

51
EJERCICIO 8

Nos visita el responsable de una conocida empresa dedicada a la realización de proyectos de


reforma y decoración en viviendas con el fin de estudiar la posibilidad de recoger en una base de
datos parte de la información que ellos manejan.

La empresa ofrece sus servicios a diferentes clientes a los que se deberá facturar una vez
finalizado el proyecto, teniendo por ello que llevar un control de los gastos (horas, materiales,
etc..). Suponemos que cada proyecto lo encarga un cliente a una delegación concreta.

Un trabajador puede participar en proyectos de su delegación o de otra delegación de la misma


empresa si hiciera falta. En cada caso se contabilizan las horas invertidas en el mismo, y la
actividad realizada.

Debido a la demanda existente la empresa cuenta con delegaciones en distintos lugares siendo
necesario llevar el control de la información que se genera en cada una.

Algunas de las preguntas interesantes:

1.- Lista de proyectos de reforma realizados en una cierta fecha por una delegación
concreta.

2.- Factura a un cliente por un determinado proyecto, incluyendo costo de materiales y


costo de mano de obra. El precio/hora de la mano de obra dependerá de la actividad
realizada (pinter, lacar, alicatar, etc.).

3.- Lista de proyectos de decoración realizados por un trabajador determinado.


4.- Lista de trabajadores de una cierta delegación.
5.- Proyectos encargados por un cierto cliente.
6. Utilización de un cierto material en los proyectos, indicando la cantidad empleada
en cada uno.

Realizar el diseño del ESQUEMA CONCEPTUAL utilizando el diagrama Entidad-Relación.


Explicitar las diferentes suposiciones realizadas.
52
EJERCICIO 9

Nos ha contratado una empresa de trabajo temporal que cuenta con un conjunto de sucursales
distribuidas por diferentes poblaciones del norte del país. Dichas sucursales realizan selección
de personal para las empresas que nos soliciten candidatos a puestos de trabajo.

Una empresa puede solicitar a la empresa de trabajo temporal un número determinado de


candidatos para uno o varios puestos de trabajo, indicando para cada puesto los temas que
deberían conocer los candidatos a dicho puesto, y el nivel (cualificación) y experiencia en
años que posee el candidato en cada tema relacionado con el puesto.

Además de cada candidato se desea guardar información sobre su curriculum: temas que
conoce, con qué nivel de profundidad y qué experiencia en años tiene en cada uno de ellos.
Cada candidato se inscribe en una única sucursal.

Por ejemplo, un informe de sucursales y curriculum de los candidatos inscritos en dicha


sucursal podría ser:

SUCURSAL NOMBRE TEMA NIVEL EXPERIENCIA


(años)
Ercilla 28 Juan Gómez Diseño de BD medio 0
Lenguajes prog. alto 2
Sonia Sanz Mantenimiento PC’s alto 3
Gran Vía 81 Arturo Fdez. Acuchillador alto 2
Sergio Mendibil Mantenimiento PC’s bajo 0.5
Lenguajes prog. medio 1
Miren Pérez Diseño de BD alto 2

Al menos deberían tenerse en cuenta los siguientes datos:


• Población: código y nombre.
• Sucursal: código, nombre, dirección.
• Empresa contratadora: código, nombre, dirección, teléfono de contacto.
• Candidato: DNI, nombre, apellidos, dirección, teléfono, edad, titulación
53
• Puesto de trabajo: código, descripción, fecha de oferta, número de candidatos
solicitados.
• Tema: código, descripción.

Aplicaciones más relevantes:


• Recepción de candidatos y obtención de su curriculum
• Recepción de empresas y planteamiento de sus necesidades en cuanto a puestos a cubrir y
perfil de los candidatos
• Respuesta mecanizada a la solicitud de las empresas
• Actualización periódica de los conocimientos del candidato (nuevos temas, incremento de
experiencia, etc.)

Se pide realizar el diseño conceptual de una base de datos que recoja toda la información de
la realidad comentada, utilizando el modelo Entidad-Relación. Seguidamente, realizar el
diseño Relacional equivalente con todos sus componentes.

EJERCICIO 10

Construir un diagrama de Entidad-Relación para la oficina de una Universidad que mantiene la


información de cada una de las clases impartidas, incluyendo el nombre del profesor, el número
de alumnos matriculados, y la hora y lugar de cada una de las sesiones. Por cada pareja
estudiante-asignatura se registra una calificación. Además se supone que cada asignatura la
imparte un solo profesor aunque haya varios grupos por curso.

54
EJERCICIO 11

La empresa SPEED S.A., empresa internacional dedicada a la comercialización de comidas


rápidas, tiene la intención de informatizar la gestión del negocio para dar mejor servicio a la
clientela. Esta empresa se dedica a la venta de diferentes productos alimenticios para comida
rápida, como son pizzas, bocadillos, refrescos, helados, etc. Se desea que en la BD se
registre la siguiente información:
• La empresa consta de varias sucursales en diversos países y ciudades de los mismos. En
una ciudad grande podría haber varias sucursales.
• Los productos se agrupan en tipos como pizza, bocadillo, refresco, etc... De cada tipo
puede haber variantes del producto en cuestión. Por ejemplo: de pizza: pizza margarita,
pizza 4 quesos, etc.; de refresco: coca-cola, agua, cerveza, etc.. Suponemos que en cado
caso hay un solo tamaño.
• De las comidas que se confeccionan al momento, se deben registrar sus ingredientes y
cantidades: Por ejemplo: bocadillo de jamón y queso: pan 20 gr, jamón jork 50 grs., queso
50 grs.
• De cada ingrediente se debe registrar además de su identificativo y nombre, el precio de
compra y las calorías.
• De los productos deberá registrarse el identificativo, nombre, y el precio de venta (tener
en cuenta que por ejemplo, las diferentes variedades de pizza tendrán diferente precio.
• De los clientes habituales de cada sucursal se registra un identificativo, nombre,
dirección, y teléfono, para enviarles ofertas cada cierto tiempo.
• Los clientes pueden solicitar la comida por teléfono o directamente en el local. En el
primer caso, se registran sus datos, pero en el segundo no, salvo que sea necesario por
otras razones.
• En la BD se registran todas las ventas, tanto las del local como las servidas a domicilio,
indicando, fecha, hora, importe total, cliente (si se ha identificado) y empleado que
atendió el pedido. Tener en cuenta que cada venta a un cliente puede suponer el servicio
de varios productos.
• La empresa cuenta con empleados con diferentes funciones dentro de cada sucursal
(cocinero, camarero, repartidor, encargado, etc. De cada empleado deberán registrarse sus

55
datos personales así como el código y denominación de la función que realiza en la
sucursal en la que trabaja.

Algunas de las consultas más habituales a la BD serán: obtener los productos que tienen un
contenido inferior a 500 calorías, obtener un listado de los clientes de una sucursal, obtener el
resumen de la facturación de la empresa en 1 mes, obtener qué empleado ha servido más
pedidos durante un periodo, etc..

Criticar el siguiente diseño de la base de datos utilizando el modelo Entidad-Relación,


estableciendo la solución correcta
cód nom cód deno

EMPRESA FUNCION

cód
realiza
posee
nom PAIS dni

nom

EMPLEADO
situada SUCURSAL

id tfno
cód
dir

nom CIUDAD atiende


tiene

precio calorías id
cant
nombre

INGREDIENTE compos COMIDA compra CLIENTE


dir

precio fecha Imp-tot


tf
id nombre hay
hora
id
56
deno
TIPO
precio
3.4. LENGUAJES Y UTILIDADES DEL S.G.B.D.

Un Sistema de Gestión de Bases de Datos requiere facilidades para el manejo de los datos por
los usuarios, lenguajes del sistema para las descripciones de los datos, así como controles y
utilidades para el mantenimiento de las bases de datos.

3.4.1. LENGUAJES

En el mundo de las bases de datos podemos distinguir dos tipos de lenguajes:

a) LENGUAJES DE MANIPULACION DE DATOS: El lenguaje que conecta los programas


de usuario y la BD se llama lenguaje de manipulación de datos (DML). Cualquier lenguaje de
usuario que utilice la BD debe incluir los comandos necesarios de manipulación de datos como
parte de sus elementos. Las funciones fundamentales de estos comandos de manipulación
navegacionales (navegan a través de la BD) son:

• Seleccionar un registro de BD siempre que satisfaga unas condiciones estipuladas.


• Presentar el registro al programa de aplicación por vía del esquema externo.
• Insertar nuevos registros y asociaciones en la BD.
• Modificar los registros y las asociaciones existentes en la BD.
• Borrar registros y asociaciones existentes en la BD.

Existen dos tipos de DML:

• PROCEDIMENTALES: Necesitan que el usuario especifique qué datos quiere y como


deben obtenerse.

• NO PROCEDIMENTALES: Necesitan que el usuario especifique qué datos quiere sin


especificar cómo obtenerlos. En general son más fáciles de aprender y utilizar, pero suelen
ser menos eficientes.

57
b) LENGUAJES DE DESCRIPCION DE DATOS: Son los lenguajes necesarios para la
creación y el mantenimiento de la B.D.:

1.- LENGUAJE DE DESCRIPCION DEL ESQUEMA CONCEPTUAL (DDL


Conceptual)
Su compilación produce cierto número de tablas y posiblemente procedimientos de
varios tipos, incluyendo una tabla de símbolos que mantiene una lista de objetos
conceptuales y sus códigos internos.

2.- LENGUAJE DE DESCRIPCION DEL ESQUEMA EXTERNO (DDL


Externo)
Podría haber un ESDL aparte para cada tipo de DML. Como un ESDL y su DML son
interdependientes, algunos expertos son contrarios a su división en dos sublenguajes.

3.- LENGUAJE DE DESCRIPCION DEL ESQUEMA INTERNO (DDL Interno)


Este lenguaje describe el almacenamiento interno o esquema de almacenamiento. Su
versión compilada podría incluir una lista de objetos del esquema conceptual en
códigos internos, características de almacenamiento, especificaciones de clave, técnicas
de indexación, etc.

4.- LENGUAJE DE MODIFICACION


Se necesitan dos lenguajes de modificación, uno para el DDL Conceptual y otro para el
DDL Interno, para cambiar los esquemas conceptual e interno respectivamente. En lugar
de lenguajes separados se pueden proporcionar funciones de modificación como parte
del DDL Conceptual y del DDL Interno.

5.- LENGUAJES DE CONTROL DE BASE DE DATOS (DBCL)


Este es equivalente a un lenguaje de control de trabajos pero para una B.D. y lo utiliza el
administrador de BD para iniciar las compilaciones y las modificaciones de esquemas,
así como para especificar parámetros de tiempo de ejecución tales como buffers internos,
esquemas de prioridad para uso concurrente, etc.

58
El resultado de la compilación de las proposiciones en DDL es un conjunto de tablas que se
almacenan en un fichero especial denominado Diccionario de Datos. Este fichero se consulta
antes de leer o modificar los datos reales en el sistema de B.D.

3.4.2. UTILIDADES

Una B.D. requiere para funcionar una gran cantidad de utilidades:

1.- Utilidades de respaldo, impresión y edición, para hacer copias de seguridad o


imprimir partes de la B.D. en determinado formato o para editar errores.

2.- Garbage collection (recogida de basuras) y rutina de reasignación, para


suprimir físicamente de los dispositivos de almacenamiento los registros borrados,
consolidar el espacio liberado y reasignarlo.

3.- Rutina de reorganización de índices, para reorganizar los índices y sus


desbordamientos.

4.- Rutinas de seguimiento y análisis, para recoger estadísticas de la B.D. y analizarlas


para la reorganización de la B.D.

59
3.5. EL DICCIONARIO DE DATOS

La clave para el uso eficaz de los datos en una B.D. es su propia documentación. Sin ella, un
usuario está destinado a perderse.

El concepto de diccionario de datos se introdujo originalmente como una manera para


proporcionar esta documentación, pero ahora se ha empleado como soporte de toda la
información necesaria para los usuarios y el sistema de control de B.D.

A continuación, se enumeran algunos posibles contenidos de un diccionario de datos:

1.- Número de usuarios permitidos y status de autorización


2.- Descripción de datos y explicación de su significado y uso, incluidos requisitos de
integridad.
3.- Los códigos fuente y objeto de programas y esquemas, con varios números de versión y
status de registros - por ejemplo, el programa de cada usuario podría registrarse para
recuperación, actualización o comprobación con una lista de sus usuarios.
4.- Facilidades de apoyo al sistema tales como procedimientos de B.D., utilidades y
herramientas de diseño. Los procedimientos de B.D. son llamados en tiempo de ejecución
cuando son necesarios.
5.- Datos de rendimiento: Todas las estadísticas de uso, su análisis e informes de evaluación.
6.- Información de copia de seguridad: Ficheros de seguridad, logs de los sistemas e
información de restablecimiento.
7.- JCL y parámetros de tiempo de ejecución. Por ejemplo, tamaño de búfer, estrategia de
recuperación, etc.

La facilidad de descripción de datos generalmente soportada en todos los diccionarios de datos


implementados, ayuda en los análisis de datos y también es una ayuda de documentación.

60
TEMA IV
IMPLEMENTACIÓN DE UNA BASE DE DATOS

4.1. INTRODUCCIÓN

En este capítulo vamos a ver como se pueden organizar los datos en


almacenamiento secundario, es decir, en medios de acceso actuales como
paquetes de disco, tambores, etc. Por lo tanto este capítulo se centra en el nivel
interno del sistema.

Las operaciones del usuario se expresan (por medio del D.M.L.) en términos de
registros externos, y el S.G.B.D. debe convertirlas en las operaciones
correspondientes sobre los registros internos o almacenados.

Estas últimas operaciones deben convertirse a su vez en operaciones al nivel


real del hardware, es decir, en operaciones sobre registros físicos o bloques. El
componente responsable de esta conversión interna/física se llama METODO
DE ACCESO, y está formado por un conjunto de rutinas cuya función es ocultar
al S.G.B.D. todos los detalles dependientes de los dispositivos y presentarle un
interface de registros almacenados.

El interface de registros almacenados permite al S.G.B.D. ver la estructura de


almacenamiento como un conjunto de ficheros almacenados, cada uno
compuesto de todas las ocurrencias de un tipo de registro almacenado.

En términos específicos, el S.G.B.D. conoce:

• Qué ficheros almacenados existen.


• La estructura del registro almacenado correspondiente.
• Los campos almacenados, si los hay, sobre los cuales están
secuenciados.

61
• Los campos almacenados, si los hay, que puedan usarse como
argumentos de búsqueda para el acceso directo.

Toda esta información se especificará como parte de la definición de la


estructura de almacenamiento.

4.2. REPRESENTACIÓN FÍSICA DE ESTRUCTURAS DE


DATOS
Las relaciones entre los datos pueden representarse físicamente de dos
formas:

• Representación intrarregistro.
• Representación interregistro.

4.2.1. REPRESENTACIÓN INTRARREGISTRO


Se basa en la contigüidad física de los datos relacionados. Permite pasar de un
valor al otro más rápidamente, porque la mayoría de las veces los dos valores
relacionados estarán en la misma página y no será necesario otro acceso a la
memoria periférica.

CURSO 1ºA Alumno 1 Alumno 2 ...... Alumno N

En este tipo de representación los registrospueden ser de longitud fija o variable.


Sin embargo, tiene la limitación de que sólo se pueden representar jerarquías.

62
4.2.2. REPRESENTACIÓN INTERREGISTRO
No existe contigüidad física pero se mantienen las relaciones a través de
apuntadores.

CURSO 1ºA

Alumno 1 Alumno 2

En este ipo de representación podemos tener un número variable de registros de


longitud fija y se puede representan cualquier tipo de estructura.

En la representación interregistro pueden usarse diversos tipos de estructuras


enlazadas. En las estructuras enlazadas, los registros pueden estar relacionados
por punteros lógicos o físicos. Los punteros soportan la secuencia lógica de los
registros. Vamos a ver algunas de las estructuras enlazadas que se pueden
manejar.

a) Cadenas y Anillos

Una cadena de una dirección es una lista de registros conectados por


punteros dirigidos hacia adelante (ascendente) o hacia atrás (descendentes).

Una cadena de dos direcciones es una lista en la que los registros están
conectados en ambas direcciones.

63
X

CADENA HACIA ADELANTE

CADENA HACIA ATRAS

X X

CADENA DE DOS DIRECCIONES

Los anillos son extensiones de las cadenas donde al último registro se le


permite tener un puntero hacia el primero. El proceso puede comenzar en
cualquier registro y continuar a través del anillo.

ANILLO DE UNA DIRECCION

64
ANILLO DE DOS DIRECCIONES

b) Arbol y Red

Un árbol se utiliza para representar una estructura de datos jerárquica en la


forma de nodos y ramas, siendo registros tanto los nodos como las ramas. A un
nodo se le llama propietario o padre. A sus ramas, miembros o hijos.

Al nodo más alto del árbol se le llama registro raíz. En un árbol una rama no
puede pertenecer a dos nodos diferentes. En una red esto sí puede suceder.

RAIZ A

B1 B2 B3

C1 C2 C3

D1 D2

ARBOL con 4 niveles de jerarquía

65
Pieza A

Pieza B Pieza C Pieza D

Pieza F Pieza C

Estructura en RED

Los registros pueden enlazarse por encadenamiento, tanto en sentido hacia


delante como hacia atrás.

4.3. EJEMPLOS SOBRE POSIBLES


REPRESENTACIONES
Se considera un conjunto sencillo de datos de muestra y algunas formas de
representación de los mismos en el almacenamiento:

P# NOMBRE ESTADO CIUDAD


P1 SALAZAR 20 LONDRES
P2 JARAMILLO 10 PARIS
P3 BERNAL 30 PARIS
P4 CAICEDO 20 LONDRES
P5 ALDAMA 30 ATENAS

66
Los datos de muestra incluyen información de 5 proveedores. Para cada
proveedor se desean registrar los datos:

• P#: Número de proveedor. Es único por proveedor.


• NOMBRE: Nombre del proveedor.
• ESTADO: Estado
• CIUDAD: Localización del proveedor

Vamos a comentar diferentes posibilidades para almacenar estos datos


físicamente.

1ª REPRESENTACION: Consiste en un sólo fichero almacenado que


contendrá 5 ocurrencias de registro almacenado.

VENTAJA: Sencillez
INCONVENIENTE: Puede ser inadecuado en la práctica. Por ejemplo, en el caso
de tener 10.000 proveedores localizados en 10 ciudades, tendríamos mucha
redundancia.

2ª REPRESENTACION: Se puede evitar la redundancia de la representación


anterior respecto a los nombres de ciudad. Si el espacio reservado para
almacenar el apuntador es inferior al necesario para almacenar el nombre de la
ciudad, podríamos considerar dos ficheros:

FICHERO PROVEEDOR FICH. CIUDAD


APUNTADOR
P# NOMBRE ESTADO CIUDAD
A CIUDAD
P1 SALAZAR 20 ATENAS
P2 JARAMILLO 10 LONDRES
P3 BERNAL 30 PARIS
P4 CAICEDO 20
P5 ALDAMA 30
Suponemos que los apuntadores son SRA (dirección de registro almacenado).

67
VENTAJA: Ahorro de espacio (si el espacio para almacenar el apuntador es
menor que el necesario para la ciudad).
INCONVENIENTE: Más accesos. Por ejemplo, para localizar las propiedades de
un proveedor concreto, necesitaremos dos accesos, y para buscar los
proveedores de una ciudad concreta, un montón de accesos.

3ª REPRESENTACION: En el caso de que sea importante "hallar los


proveedores de una ciudad", utilizar un fichero índice para localizar los
proveedores de una ciudad. Un INDICE es un fichero donde cada entrada
(registro) se compone de un valor del dato junto con uno o más apuntadores. El
índice puede usarse de dos formas: para acceso secuencial y para acceso
directo.

FICHERO CIUDAD FICHERO PROVEEDOR


APUNTADOR A
CIUDAD P# NOMBRE ESTADO
PROVEEDOR
ATENAS P1 SALAZAR 20
P2 JARAMILLO 10
LONDRES P3 BERNAL 30
P4 CAICEDO 20
PARIS P5 ALDAMA 40

Cada ocurrencia de registro del fichero CIUDAD contiene apuntadores a todas las
ocurrencias de los proveedores correspondientes a cada ciudad en cuestión.

VENTAJA: Acelera la recuperación, en el caso de buscar todos los proveedores


para una ciudad.
INCONVENIENTES:
- En el caso de querer recuperar todas las propiedades de un proveedor, se
tardaría más. Puede retardar la actualización. Por ejemplo, si el proveedor P2 se
traslada de París a Londres, en el caso 2º habría que modificar un puntero,
mientras que aquí sería preciso modificar dos punteros.

68
4ª REPRESENTACION: Utilizar un fichero índice con doble puntero. Es una
combinación de la 2ª y 3ª representaciones.

Fichero ATENAS LONDRES PARIS

CIUDAD

Fichero
P1 P2 P3 P4 P5
PROV.

VENTAJA: Posee las ventajas de 2º y 3º


.INCONVENIENTES:
- Desventaja de 3º (retarda las actualizaciones).
- Necesita espacio adicional de almacenamiento.
- Para el índice secundario se necesita un número variable de apuntadores en el
registro almacenado.

5ª REPRESENTACION: Uso de cadena de apuntadores, con el objeto de evitar


la desventaja anterior referente al número variable de apuntadores.

Cada ciudad apunta al primer proveedor de esa ciudad, éste al segundo, etc.,
hasta el último, que apunta de nuevo a la ciudad.

Fichero ATENAS LONDR PARIS


ES
CIUDAD

Fichero
PROVEEDOR P1 P2 P3 P4 P5

69
VENTAJA: Más fácil efectuar cambios.
INCONVENIENTE: Para acceder al n-ésimo proveedor hay que pasar por los
anteriores (más tiempo de acceso).

Se podría extender con punteros de proveedor a ciudad, o bien, haciendo que las
cadenas fueran de doble vía.

6ª REPRESENTACION: Organización invertida (un índice sobre cada campo


secundario).

Indice NOMBRE Indice ESTADO Indice P#


NOMPRE Apunt. ESTADO Apunt. P#
SALAZAR ↑ P1 10 ↑ P2 P1
JARAMILLO ↑ P2 20 ↑ P1 ↑ P4 P2
BERNAL ↑ P3 30 ↑ P3 ↑ P5 P3
CAICEDO ↑ P4 P4
ALDAMA ↑ P5 P5

Indice CIUDAD
CIUDAD Apuntador
ATENAS ↑ P5
LONDRES ↑ P1 ↑ P4
PARIS ↑ P2 ↑ P3

VENTAJA: Localiza el proveedor a partir de cualquier propiedad.


INCONVENIENTE: Más tiempo para localizar todas las propiedades de un
proveedor.

70
7ª REPRESENTACION: Organización jerárquica. En este caso tendremos un
fichero almacenado con 3 ocurrencias de registro almacenado, una por cada
ciudad. Cada registro se compone de una lista de longitud variable de entradas
para proveedores.

ATENAS LONDRES PARIS

P1 SALAZAR 20 P2 JARAMILLO 10 P3 BERNAL 30

P4 CAICEDO 20 P5 ALDAMA 30

8º REPRESENTACION: Organización de direccionamiento por hashing.


Consiste en el almacenamiento y recuperación mediante una función de hashing.
Suponiendo los valores de P#, P100, P200, etc. y SRA = resto de dividir la parte
numérica de P# entre 13:

0 1 2
P300 BERNAL

3 4 5
P200

6 7 8

P500 ALDAMA

9 10 11
P100 SALAZAR P400 CAICEDO

71
VENTAJA: Acceso directo muy rápido aplicando la función de hashing (no hay
que explorar índices).
DESVENTAJAS:
- En general, la secuencia de almacenamiento no coincide con la clave
primaria.
- Los desbordamientos.
- Pueden quedar huecos en el espacio almacenamiento si el reparto de los
registros es desigual.

CONCLUSION: No existe una estructura de almacenamiento óptima. Lo 'mejor'


depende de los intereses de cada caso. Puede tenerse en cuenta:

- el tiempo de acceso, es decir, el tiempo que lleva localizar un dato


determinado, empleando la técnica de que se trate.

- el tiempo de inserción o eliminación, que incluye el tiempo requerido para


localizar el dato a eliminar o el lugar de inserción, más el que se necesita
para actualizar la estructura de indexación

- el rendimiento,

- la dificultad de cambios,
- espacio disponible, considerando el espacio adicional que ocupa la
estructura de indexación. Siempre que la cantidad de espacio extra no sea
muy grande, generalmente valdrá la pena sacrificar el espacio, con el fin
de mejorar el rendimiento.

- la facilidad de reorganización,

- la frecuencia deseada de reorganización, etc.

72
4.4. TÉCNICAS DE ACCESO
Normalmente no basta recuperar los registros según su secuencia física sino que
es necesario hacer accesos según el valor de uno de sus campos o bien según
un orden establecido. Para ello, como en las memorias periféricas corrientes, el
acceso a las páginas es por posición, no por contenido, es necesario disponer de
una herramienta que determine la posición de los registros a partir de los valores
del conjunto de datos que sirven para acceder a ellos. Así, las dos formas
generales de atacar este problema (y que ya han sido explicadas con profundidad
en capítulos anteriores) son:

a) Direccionamiento calculado

Recordemos que las técnicas de direccionamiento calculado utilizan un


ALGORITMO DE ALEATORIZACION o FUNCION DE HASHING que determina
la posición de un registro en función del contenido de un campo o conjunto de
campos denominados CLAVE DE ALEATORIZACION. Su principal ventaja es
que permite acceder directamente a la posición donde debe estar el registro con
un sólo acceso (en el acceso por índices, hay que leer primero el índice).

b) Construcción de índices

Un FICHERO INDICE es un fichero auxiliar que sirve para acceder a los registros
de otro fichero llamado PRINCIPAL por el valor de un dato o conjunto de datos
denominados CLAVE DE INDEXACION. Para un mismo fichero principal puede
haber varios índices correspondientes a sendas claves.

COMPARACION ENTRE INDEXACION Y DIRECCIONAMIENTO


CALCULADO

Para tomar la decisión de qué forma usar, el diseñador puede tomar en cuenta
los siguientes factores:

73
- ¿Es aceptable el costo de reorganización periódica del índice o de la estructura
de cálculo de la dirección?

- ¿Cuál es la frecuencia relativa de inserciones y eliminaciones?

- ¿Es conveniente optimizar el tiempo de acceso promedio a expensas de


aumentar el tiempo de acceso en el peor de los casos?

- ¿Qué tipo de consultas harán normalmente los usuarios?. Por ejemplo, si la


mayor parte de las consultas son de la forma:

SELECT A1, A2, ... FROM R WHERE Ai=C

entonces puede ser más conveniente el direccionamiento calculado. Por otro


lado, si la mayoría de las consultas son del tipo:

SELECT A1, A2, ... FROM R WHERE Ai < C2 AND Ai > C1

entonces sería más apropiado utilizar índices.

4.5. TÉCNICAS OPCIONALES PARA EL


ALMACENAMIENTO DE DATOS

4.5.1. COMPACTACIÓN DE DATOS


Algunas medidas para que las B.D. ocupen el mínimo espacio son evitar
redundancias, utilizar registros de longitud variable, etc.

Las técnicas de compactación de datos permiten reducir la cantidad de


almacenamiento requerido para un conjunto específico de datos almacenados.
Normalmente se utilizan más para índices que para datos.

Algunas técnicas de compactación son:

1.- Compresión delantera: consiste en reemplazar los caracteres del principio de


cada entrada que sean idénticos a los de la entrada anterior por un número
adecuado. Por ejemplo, suponiendo nombres de 12 caracteres:

74
ROBERTONbbbb 0ROBERTONbbbb
ROBERTSONbbb 6SONbbb
ROBERTSTONEb 7TONEb
ROBINSONbbbb 3INSONbbbb

2.- Compresión trasera: igual que la compresión delantera pero eliminando los
caracteres por la derecha, por ejemplo los blancos.

3. Técnicas estadísticas:

a) Si suponemos una BD de clientes que tenga entre otros datos la población, y


la mayoría de ellos residen en Bilbao o Madrid, podríamos utilizar dos bits:

- el primer bit : = 0 --> Madrid o Bilbao


= 1 --> Otra población
- el segundo bit: = 0 --> Madrid
= 1 --> Bilbao

Así en la mayoría de los casos podríamos ahorrarnos almacenar el nombre de la


población, y sólo se almacenaría en el resto de los casos, es decir cuando el
primer bit es 1.

b) Cambiar de alfabeto: Si suponemos que sólo tenemos campos


alfabéticos, podemos cambiar el albabeto.

1 carácter = 1 octeto, pero con 5 bits obtenemos más de 27 combinaciones.


Podemos asignar 5 bits a cada letra:
00000 - A
00001 - B
00010 - C
con lo cual ahorramos bastante espacio.

Si tenemos letras y números podríamos utilizar 6 bits = 64 combinaciones.

75
c) Codificación de Huffman: Es una técnica de codificación que puede producir
una compresión significativa si todos los caracteres no ocurren con igual
frecuencia. La idea es que los caracteres más frecuentes se representen
mediante hileras de bits más cortas, y que no haya ningún caracter que tenga una
codificación (por ejemplo, de n bits) tal que esos n bits sean idénticos a los
primeros n bits de la codificación de otro caracter.

Por ejemplo, si sólo vamos a representar los caracteres A, B, C, D y E, y su


frecuencia relativa de aparición es la siguiente:
CARACTER FRECUENCIA CODIGO
E 35% 1
A 30% 01
D 20% 001
C 10% 0001
B 5% 0000

Con estas asignaciones, la longitud media esperada de un caracter codificado (en


bits) es:

0,35 * 1 + 0,30 * 2 + 0,20 * 3 + 0,10 * 4 + 0,05 * 4 = 2,15 bits

mientras que si a cada caracter se le asigna el mismo número de bits como en un


esquema de codificación convencional, se necesitarían 3 bits por caracter (para
permitir 5 caracteres diferentes (000, 001, 010, 011, 100).

lo que ocupa ahora


INDICE DE COMPRESION = ------------------------------ X 100
lo que ocupaba antes

es decir, un índice de compresión del 70% significa que lo que antes ocupaba
100 ahora ocupa 70.

76
4.5.2. ENCRIPTACIÓN DE DATOS
Las diversas medidas de control de autorización que protegen el acceso a la base
de datos pueden no ser adecuadas para datos altamente sensibles. En tales
casos puede ser deseable cifrar (to encrypt) los datos. Los datos cifrados no
pueden ser leídos por un intruso, a menos que conozca el método de cifrado. Se
han dedicado importantes investigaciones al estudio de estos métodos. Algunos
son tan simples que son fáciles de descifrar. Otros son muy difíciles y
proporcionan un alto nivel de protección. Veamos algunos ejemplos de muestra:

Método de sustitución simple.

Supongamos que deseamos cifrar el mensaje

THINK SNOW

Un método de sustitución simple podría ser el desplazamiento de cada letra a su


sucesor inmediato en el alfabeto. Se supone que el espacio aparece
inmediatamente antes de la letra a y que sigue a la letra z. Así “think snow” se
cifra:

UIJOLATOPX

Si un intruso únicamente ve el mensaje “uijolatopx” probablemente no tendría


información suficiente para romper el código. Sin embargo, si se examina un
número grande de palabras, estadísticamente es posible determinar la frecuencia
con que aparecen los caracteres y, por medio de ello, romper fácilmente el
código. Los mejores esquemas de cifrado utilizan una clave de cifrado, como se
muestra en el siguiente método.

77
Método de sustitución polialfabética.

Supongamos que queremos cifrar el mismo mensaje, pero ahora damos la clave
del cifrado, por ejemplo “securytise”. Procederemos de la siguiente forma:

1. Alineamos la clave debajo del texto legible, repitiéndola tantas veces como sea
necesario para “cubrirlo” completamente. En este ejemplo tendríamos
THINK SNOW
SECURYTISE

2. Supongamos que el espacio ocupa la vigésimo séptima, y última, posición en


el alfabeto. Para cada carácter sumamos la posición alfabética del carácter del
texto legible y la del carácter de la clave, dividimos por 27 y guardamos el resto.
Reemplazamos el carácter del texto legible con el carácter encontrado en la
posición calculada en el resto.

Para este ejemplo, la T se encuentra en el vigésimo lugar del alfabeto, mientras


que la S se encuentra en la decimonovena posición. Así, (20+19)=39. El resto de
la división por 27 es 12, que corresponde a la letra L en el alfabeto. Así la letra T
del texto legible se cifra como la letra L en el texto cifrado.

78
TEMA V

EL MODELO RELACIONAL

Introducción

Quizá no nos hayamos dado cuenta, pero nuestra vida cotidiana se ve afectada de forma
importante por la tecnología de base de datos (BD). Las bases de datos computarizadas son
vitales para el funcionamiento de las organizaciones modernas. Estamos en contacto con las
BD diariamente a través de actividades como comprar en el supermercado, retirar efectivo
del cajero automático, solicitar un libro en una biblioteca y matricularse en la universidad. En
todas estas acciones, de una forma u otra se requiere el almacenamiento de datos en una
estructura denominada base de datos. Por tanto, las comodidades de nuestra vida diaria, en
parte, se deben a la proliferación de las bases de datos y a su tecnología.
La tecnología de bases de datos no solo mejora las operaciones diarias de las empresas y de
cualquier organización, sino que también afecta a la calidad de las decisiones que afectan a
nuestras vidas. En las bases de datos se almacena información sobre nuestras preferencias de
consumo, uso de telecomunicaciones, historial de operaciones bancarias, hábitos televisivos,
etc. Los directivos de las empresas utilizan todos estos datos para tomar decisiones a largo
plazo como invertir en mejoras en el negocio, ubicar sucursales de la empresa, planificar las
campañas de marketing o iniciar nuevos negocios.
Un modelo muy extendido de bases de datos son las bases de datos relacionales, que han
triunfado en el mundo de las bases de datos por su simplicidad y eficiencia. En este capítulo
se abordará en profundidad el modelo relacional de bases de datos, desarrollándose las
siguientes competencias específicas:

1) Definir el concepto de Base de Datos y Sistema de Gestión de Base de Datos como


solución global a las limitaciones de los sistemas de ficheros.

2) Realizar un diseño conceptual de bases de datos, empleando el modelo Entidad-


Relación.

3) Identificar las funciones, características, estructura e implementación del modelo de


S.G.B.D. relacional.

4) Transformar el diseño conceptual de una base de datos representado mediante el


modelo Entidad-Relación, a un diseño para base de datos relacional.

5) Codificar y ejecutar las operaciones de creación, carga, consulta y modificación sobre


una base de datos Oracle, utilizando el lenguaje SQL.

79
5.1. CONCEPTOS BASICOS. ESTRUCTURA DE DATOS RELACIONAL

Los principios del modelo relacional fueron establecidos inicialmente por E.F. Codd en 1969-70
(1970) y han sido objeto de numerosos estudios y desarrollos posteriores.

El primer prototipo llevado a cabo según las especificaciones de Codd, fue el Sistema R (IBM
San José Research Laboratory, 1974-79). También INGRES surgió como prototipo en la
Universidad de Berkeley (California) a partir del modelo de datos definido por Codd.
Posteriormente, sistemas como DB2 (IBM) y ORACLE, aparecieron a partir del estudio de los
resultados obtenidos por el sistema R. Actualmente hay una gran cantidad de sistemas de gestión
de bases de datos relacionales en el mercado.

5.1.1. DEFINICION DE RELACION

De las múltiples definiciones de RELACION que se han dado, hemos elegido la de C.J. Date [2]:

Una relación R sobre un conjunto de dominios D1, D2, ..Dn, se compone de dos partes, una
cabecera y un cuerpo.

La cabecera estará formada por un conjunto fijo de atributos, o, en términos más precisos, de
pares atributo-dominio.

{ (A1:D1), (A2:D2), ... (An:Dn) }

tales que cada atributo Aj corresponde a uno y sólo uno de los dominios subyacentes Dj (j=1, 2,
..., n).

El cuerpo está formado por un conjunto de tuplas, el cual varía con el tiempo. Cada tupla a su
vez está formada por un conjunto de pares atributo-valor:

{ (A1:vi1), (A2:vi2), ... (An:vin) }

(i=1, 2, ...,m) donde m es el número de tuplas del conjunto.

En cada una de estas tuplas hay uno de estos pares atributo-valor (Aj:vij) para cada atributo Aj de
la cabecera.

Para cada par atributo-valor (Aj:vij), vij es un valor del dominio único Dj, asociado al atributo Aj.

m = cardinalidad (varía con el tiempo)


n = grado (no varía)

Por ejemplo, sea la relación PIEZA de la figura 5.1. que contiene la relación de las piezas que
gestiona una empresa.

80
P# NOMP COLOR PESO CIUDAD
P1 Tuerca Rojo 12 Londres
P2 Perno Verde 17 París
P3 Tornillo Azul 17 Roma
P4 Tornillo Rojo 14 Londres
P5 Leva Azul 12 París
P6 Rueda Rojo 19 Londres

Figura 5.1. Relación Pieza

Los dominios son: conjunto de valores de número de pieza posibles, conjunto de valores de
nombre de las pieza posibles, conjunto de colores de las piezas posibles, conjunto de pesos de las
piezas posibles y conjunto de sitios donde se almacenan las piezas posibles. El grado es de 5 (nº
columnas).

Cada fila de la tabla se llama tupla y el número de tuplas de una relación se llama cardinalidad.
En el ejemplo, la cardinalidad de la relación PIEZA es de 6.

Las relaciones de grado uno se denominan unarias, las de grado dos binarias y las de grado “n”
n-arias.

PROPIEDADES DE LAS RELACIONES

1.- En una relación no existen tuplas repetidas: Dado que una relación es un conjunto
matemático y por definición, los conjuntos no incluyen elementos repetidos.

2.- Las tuplas no están ordenadas. (de arriba hacia abajo).


Una relación es un conjunto matemático, y los conjuntos matemáticos no son ordenados.

3.- Los atributos no están ordenados (de izquierda a derecha).


En la segunda definición, la cabecera se define como un conjunto, y los conjuntos no tienen
orden.

4.- Todos los valores de los atributos son atómicos. Es decir, en cada intersección de una fila y
una columna de la tabla hay un único valor, nunca un conjunto de valores. Una relación que
satisfaga la condición anterior se dice que está NORMALIZADA. En el enfoque relacional sólo
se admiten relaciones normalizadas.

5.1.2. DOMINIOS Y ATRIBUTOS

Es importante apreciar la diferencia entre dominios y atributos (columnas).

El dominio es el conjunto de todos los valores legales para un atributo. Puede haber valores que
no aparezcan en la tabla, en un instante específico.

81
Un atributo representa el uso de un dominio, es decir, un valor que se extrae de un dominio.
Puede ocurrir que haya dos atributos y un solo dominio.

Por ejemplo, en la siguiente relación de la figura 5.2. existen tres atributos (nº de componente
principal, nº de componente secundaria y cantidad) mientras que sólo existen dos dominios (nº
de pieza y cantidad).

P#_PRINCIPAL P#_SECUNDARIA CANTIDAD


P1 P2 2
P1 P4 4
P5 P3 1
P3 P6 3
P6 P1 9
P5 P6 8
P2 P4 3

Figura 5.2. Relación Componente

5.1.3. CLAVES

Supongamos que K es un subconjunto de atributos de la relación R. K es una CLAVE


CANDIDATA de R si y sólo si cumple las siguientes propiedades:

- Unicidad: En ningún momento hay dos tuplas de R que tengan el mismo valor de K.
- Es mínima: Ningún subconjunto propio de K tiene la propiedad de unicidad.

S# NOMS ESTADO CIUDAD


S1 Salazar 20 Londres
S2 Jaramillo 10 París
S3 Bernal 30 París
S4 Caicedo 20 Londres
S5 Aldana 30 Atenas

Figura 5.3. Relación Proveedor

Por ejemplo, en la relación PROVEEDOR de la figura 5.3., que contiene la información de los
proveedores de una empresa, supondremos que no puede haber proveedores con el mismo
nombre. Entonces, puede haber dos claves claves candidatas:

- Número de proveedor (S#).


- Nombre (NOMS).

De entre las claves candidatas se elige una para identificar las tuplas de la relación. A ésta se le
llama CLAVE PRIMARIA (primary key). Por ejemplo, podríamos elegir el número de
proveedor como clave primaria de relación PROVEEDOR. De esta forma toda relación tiene
una clave primaria.

82
Una clave candidata que no es primaria, tal como NOMS, recibe el nombre de CLAVE
ALTERNA (o alternativa o secundaria).

Si una relación tiene varias claves candidatas, cualquiera de ellas puede ser designada como
primaria. Para elegir más convenientemente, el diseñador de la BD deberá tener en cuenta el
significado de la relación y sus atributos, y sopesar diversos factores como:
• Estabilidad: considerar aquí si algunas claves son menos propensas a sufrir modificaciones
en sus valores. Por ejemplo, el DNI será más estable que DIRECCION.
• Facilidad de uso: Será, más fácil de usar una clave numérica corta que otra alfanumérica con
muchos caracteres. Por ejemplo elegiremos un NºEMP antes que un NOM_EMP, que es más
largo y está más sujeto a errores de introducción de datos.
• Fiabilidad: Ver si alguna clave contiene dígitos de validación u otros mecanismos de
autodetección o corrección de errores (ej. dígitos de control).
• Universalidad: Puede haber claves cuyo uso y conocimiento esté muy extendido, por
ejemplo, el DNI.

5.1.4. REGLAS DE INTEGRIDAD

Las reglas de integridad son las normas que han de cumplir los datos que se almacenan o
modifican en la base de datos para asegurar la coherencia de la misma en cualquier instante.
Estas reglas las define el diseñador de la BD, se han de implementar en la creación de la misma,
y será el SGBD el encargado de vigilar que se cumplan cada vez que se realice una operación de
inserción o modificación de datos.

En una BD relacional además de las reglas de integridad sobre valores de los datos comúnmente
utilizadas en cualquier tipo de BD, se definen dos tipos de condiciones de integridad especiales:

- Integridad de la entidad.
- Integridad referencial.

5.1.4.1. Regla 1ª: Integridad de la Entidad

La regla de integridad de la entidad consiste en que ningún componente de la clave primaria


puede tener valor nulo. Un valor nulo significa carecer de valor (valor desconocido o
inaplicable).

Todas las entidades o tuplas deben ser distinguibles por definición, es decir, deben tener alguna
identificación única. Esta identificación única la realiza la clave primaria. El hecho de permitir
valores nulos en algún componente de la clave, implicaría la posibilidad de dos entidades no
distinguibles entre sí y por definición no serían dos entidades sino una.

Por ejemplo, veamos un caso de ambigüedad que podría surgir si no existiera esta regla.
Consideremos la relación:

83
EMP (NE, ND, SUELDO)

donde cada tupla representa un empleado de una empresa, NE es el número de empleado, ND


es el número de departamento y SUELDO es su sueldo. Tiene una sola clave candidata, NE, que
por tanto será la clave primaria.

Si NE pudiese tomar valores nulos, podrían existir en EMP las tuplas:

EMP ( NE ND SUELDO)
E1 D1 1000
? D1 1000

La segunda tupla se refiere a un empleado desconocido. ¿Tenemos por tanto un empleado o


dos?. Imposible saberlo con la información aportada por la relación solamente.

En conclusión, en toda relación debe designarse a una clave como primaria y sus atributos no
deben tomar valores nulos.

5.1.4.2. Regla 2ª: Integridad Referencial

Los atributos de una relación que son claves primarias en otras relaciones se llaman CLAVES
EXTRANJERAS o EXTERNAS o ajenas o foráneas (foreign key). Se puede definir la regla de
integridad referencial de la siguiente forma:

Sea D un dominio primario (aquel sobre el que se ha definido alguna clave primaria), y sea R1
una relación con un atributo A que se define sobre D, es decir, una clave externa. Entonces, en
cualquier instante dado cada valor de A en R1 debe ser nulo o bien igual a V, donde V es el
valor de la clave primaria de alguna relación R2 con clave primaria definida sobre D.

A esta regla se la conoce como integridad referencial porque los valores de la clave externa se
obtienen por referencia a los valores de clave primaria de otra relación. Esto significa que todo
valor de atributo A en una relación R1, debe existir en alguna tupla de la relación R2 de la que es
clave primaria. Por ejemplo, sean la relación EMP y DEP:

EMP (NE, NSS, ND, SUELDO)


DEP (ND, NOMBRE)

donde en la relación DEP cada tupla representa un departamento de nombre NOMBRE y con
clave primaria ND. ND es una clave extranjera en EMP y clave primaria en DEP.

Vemos que las tuplas de EMP hacen referencia a las de DEP por medio de la clave primaria de
DEP, ND. Estas referencias entre relaciones suelen implicar condiciones de existencia. En
nuestro ejemplo, no puede haber un empleado que trabaje en un departamento del que no
tenemos información, lógicamente. Dicho de otra forma, todo valor de ND en EMP debe existir
en DEP.

84
Por tanto, a la hora de actualizar las tablas habrá que tener en cuenta las acciones a tomar para
preservar la integridad referencial:

a) Si se borra una tupla de DEP, para mantener la integridad referencial, habrá que comprobar
que el departamento que borramos no tenga empleados. Si esto no fuese así, se podría optar por:
- Rechazar la petición de borrado. La operación de borrado se restringe al caso en que no
haya empleados.
- Aceptarla y propagarla a EMP, es decir, borrar también sus empleados de EMP. Este
borrado podría propagarse a su vez a otras relaciones que hagan referencia a EMP (ON
DELETE CASCADE).
- Aceptarla y anular la referencia, es decir, actualizar las tuplas de EMP correspondientes
poniendo el ND con valor nulo (ON UPDATE CASCADE).

b) Si se actualiza una tupla de DEP modificando el ND, acciones similares.

c) Inserción de una nueva tupla en EMP: Comprobar que el departamento de este nuevo
empleado existe en DEP ó es nulo. Si así no fuese, se rechazará la petición.

d) Borrado de una tupla de EMP: No hay que comprobar nada respecto al ND.

e) Actualización de una tupla de EMP modificando el atributo ND. Hay que comprobar que si el
nuevo valor de ND en EMP no es nulo, existe en DEP. Si no, se rechazará la petición.

Si en la creación de la BD se definen correctamente las claves externas y las opciones asociadas


a las operaciones de actualización, el SGBD mantendrá la integridad referencial preservando la
coherencia de la base de datos.

5.1.5. DISEÑO DEL ESQUEMA CONCEPTUAL RELACIONAL

En el modelo relacional, el esquema conceptual se compone de un conjunto de relaciones (con


sus correspondientes atributos) más las reglas de integridad establecidas.

Dado un esquema conceptual representado mediante el modelo Entidad-Relación, para realizar la


transformación al modelo relacional, se seguirán los siguientes pasos:

- Se incluye una tabla o relación por cada entidad en el modelo E-R, con una columna por cada
uno de los atributos de ésta.
- En cada tabla-relación se designan uno o más atributos como clave primaria.
- Cada asociación 1-N entre dos entidades se refleja introduciendo una clave externa en la
entidad dependiente (lado N de la asociación).
- Cada asociación M-N da lugar a una tabla-relación que es dependiente de las entidades
asociadas. En la nueva tabla-relación habrá que incluir una clave externa por cada entidad, más
los atributos correspondientes. Después será preciso elegir la clave primaria. A veces, es posible
tomar como clave primaria la combinación de claves externas, si tiene valor único para cada
tupla y si no se permiten valores nulos.

85
- Si hay alguna asociación 1-1, se tratará como el caso 1-N.
Para las claves externas introducidas habrá que especificar una serie de reglas de integridad
(sobre valores nulos, eliminación, etc..)

Por ejemplo, la figura 5.4. representa un posible modelo Entidad-Relación para una base de datos
que incluye información sobre las personas de una comunidad, los vehículos, y sus propietarios
en el tiempo.


dni nom prec mat tipo color pot id den
compra

PERSONA COCHE Hay MARCA

Propiedad

Figura 5.4. Diagrama Entidad-Relación para una BD de vehículos.

En el modelo relacional, las entidades PERSONA, COCHE y MARCA se representan mediante


relaciones. Además, dado que hay una relación de 1 a N entre MARCA y COCHE, es preciso
introducir en coche la clave externa ID_M:

PERSONA (DNI, NOMBRE)


COCHE (MAT, TIPO, POTENCIA, COLOR, ID_M)
MARCA (ID_M, DENOMINACION_M)

Ademas la asociación Propiedad que es de N a M se representaría mediante la relación:

PROPIEDAD (DNI, MAT, FECHA-COMPRA, PRECIO)

5.1.6. RESUMEN

Se puede definir una B.D. RELACIONAL como una B.D. que el usuario percibe como un
conjunto de relaciones normalizadas de diversos grados, que varían con el tiempo. En términos
tradicionales puede decirse que:

- Una relación se asemeja a un fichero.


- Una tupla se asemeja a un registro.
- Un atributo se asemeja a un campo.

Sin embargo, las principales características que distinguen a los ficheros relacionales de los
tradicionales son:

1.- Cada fichero relacional sólo contiene un tipo de registro.

86
2.- Cada ocurrencia de registro en un fichero específico tiene el mismo número de
campos (se prohíben los grupos de repetición).
3.- Cada ocurrencia de registro tiene un identificador único (clave primaria).
4.- Dentro de un fichero relacional las ocurrencias de registro tienen un orden sin
especificar o se ordenan según valores contenidos dentro de esas ocurrencias (no
necesariamente de la clave primaria).

87
5.2. ALGEBRA RELACIONAL

En una Base de Datos Relacional, existen dos tipos de lenguajes:

• Álgebra Relacional
• Cálculo Relacional

El álgebra relacional, es un conjunto de operaciones sobre las relaciones. Cada operación toma
una o más relaciones como sus operandos y produce otra relación como resultado. A esto se le
denomina propiedad de CIERRE.

El álgebra se compone de dos grupos de operadores:


• Los operadores tradicionales de la teoría de conjuntos: unión, intersección, diferencia y
producto cartesiano.
• Los operadores relacionales especiales: selección, proyección, reunión y división.

Algunos de los ejemplos que veremos se basan en la BD de proveedores y piezas1 que se muestra
en las figuras 5.5.a. y 5.5.b. y que consta de tres tablas: S (proveedores), P (piezas) y SP (envíos).

Tabla S:
S# NOMS ESTADO CIUDAD
S1 Salazar 20 Londres
S2 Jaramillo 10 París
S3 Bernal 30 París
S4 Caicedo 20 Londres
S5 Aldana 30 Atenas

Tabla P:
P# NOMP COLOR PESO CIUDAD
P1 Tuerca Rojo 12 Londres
P2 Perno Verde 17 París
P3 Tornillo Azul 17 Roma
P4 Tornillo Rojo 14 Londres
P5 Leva Azul 12 París
P6 Rueda Rojo 19 Londres

Figura 5.5.a. Base de Datos de Proveedores y Piezas

1
Ejemplo extraído de [2]

88
Tabla SP:
S# P# CTD
S1 P1 300
S1 P2 200
S1 P3 400
S1 P4 200
S1 P5 100
S1 P6 100
S2 P1 300
S2 P2 400
S3 P2 200
S4 P2 200
S4 P4 300
S4 P5 400

Figura 5.5.b. Base de Datos de Proveedores y Piezas

5.2.1. OPERADORES TRADICIONALES SOBRE CONJUNTOS

Para todos, con excepción del producto cartesiano, las dos relaciones operandos deben ser
compatibles con respecto a la unión, es decir, deben ser del mismo grado, por ejemplo n, y los j-
ésimos atributos de las dos relaciones (j en el rango de 1 a n) deben tener el mismo dominio
subyacente.

- Unión

La unión de dos relaciones A y B, "A U B", es una relación que incluye todas las tuplas de A y
todas las de B. A y B deben ser relaciones del mismo grado. Si hubiera alguna tupla repetida, se
elimina.

Por ejemplo, sea A el conjunto de las tuplas de proveedores para los proveedores situados en
Londres y B el conjunto de las tuplas para los proveedores que suministran la pieza P1, entonces
A U B es el conjunto de las tuplas de proveedores para los proveedores que se localizan en
Londres o que suministran la pieza P1 (o ambas cosas).

- Intersección

La intersección de dos relaciones A y B, "A ∩ B", es una relación que incluye todas las tuplas
que pertenecen a la vez a A y B.

Por ejemplo, sean A y B como en el ejemplo de la unión anterior. Entonces A ∩ B es el conjunto


de las tuplas de proveedores para los proveedores que se localizan en Londres y suministran la
pieza P1.

89
- Diferencia

La diferencia entre dos relaciones A y B, "A - B" es una relación que incluye todas las tuplas que
pertenecen a A y no a B.

Por ejemplo, sean A y B como en el ejemplo anterior. Entonces A - B, es la relación que incluye
las tuplas de proveedores para los proveedores que se localizan en Londres y no suministran la
pieza P1.

- Producto Cartesiano Extendido

El producto cartesiano extendido de dos relaciones A y B, "A x B", es una relación que
incluye todas las tuplas posibles que se obtienen concatenando una de A con una de B.

La concatenación de una tupla a=(a1,...,am) y de una tupla b=(bm+1,...,bm+n) es una tupla


t=(a1,...,am,bm+1,...,bm+n).

Por ejemplo, sea A el conjunto de todos los números de proveedor y B el conjunto de todos los
números de pieza. Entonces A x B es el conjunto de todos los pares posibles de número-de-
proveedor/número-de-pieza.

Las operaciones unión, intersección y producto cartesiano son asociativas, por lo que pueden
omitirse los paréntesis. Sin embargo, la diferencia no es asociativa.

5.2.2. OPERADORES RELACIONALES ESPECIALES

- Selección (ó Restricción): σcond(Relación)

El operador algebraico de selección produce un subconjunto "horizontal" de una relación


específica, es decir, el subconjunto de todas las tuplas de la relación dada para el cual se cumple
un predicado específico.

El predicado se expresa como una expresión booleana de términos. Por ejemplo, en la figura 5.6.
se muestran los resultados de tres operaciones de selección.

- Proyección: Πcol1, col2,..(Relación)

El operador de proyección produce un subconjunto "vertical" de una relación dada, es decir, el


subconjunto obtenido al seleccionar los atributos especificados en un orden especificado de
izquierda a derecha y eliminando luego las tuplas duplicadas. Por ejemplo, en la figuras 5.7 se
muestran los resultados de aplicar dos operaciones de proyección.

90
σ CIUDAD = "LONDRES" (S)
S# NOMS ESTADO CIUDAD
S1 Salazar 20 Londres
S4 Caicedo 20 Londres

σ PESO < 14 (P)


P# NOMP COLOR PESO CIUDAD
P1 Tuerca Rojo 12 Londres
P5 Leva Azul 12 París

σ S# = "S1" Y P# = "P1" (SP)


S# P# CTD
S1 P1 300

Figura 5.6. Operaciones de selección

Π CIUDAD (S)
CIUDAD
Londres
París
Atenas

Π NOMS, CIUDAD, ESTADO, S# (S)


NOMS CIUDAD ESTADO S#
Salazar Londres 20 S1
Jaramillo París 10 S2
Bernal París 30 S3
Caicedo Londres 20 S4
Aldana Atenas 30 S5

Figura 5.7. Operaciones de proyección

- División

El operador de división divide una relación dividendo A de grado m+n entre una relación divisor
B de grado n, y produce una relación resultado de grado m.

La relación resultado A/B es el conjunto de tuplas <x> de grado m tales que al concatenarlas con
las tuplas de B, <y>, producen tuplas contenidas en A, <x,y>: ((A/B)x B) ⊆ A.

91
Por ejemplo:
A: B: A/B B: A/B B: A/B
S# P# P# S# P# S# P# S#
S1 P1 P1 S1 P2 S1 P1 S1
S1 P2 S2 P4 S4 P2
S1 P3 P3
S1 P4 P4
S1 P5 P5
S1 P6 P6
S2 P1
S2 P2
S3 P2
S4 P2
S4 P4
S4 P5

- Reunión o Yunción (JOIN)

El resultado de la JOIN de dos relaciones A y B, es una relación que incluye todas las tuplas que
se obtienen concatenando una de A y otra de B, tales que cumplan una determinada condición
para los valores de un atributo de dominio común a ambas. La condición puede ser una
comparación del tipo: <, >, =, >=, <=, ¬=.

Hablamos de EQUIYUNCION o EQUIREUNION (EQUIJOIN) cuando la condición es una


comparación de igualdad (en base a igualdad de atributos en dominios comunes).

La JOIN NATURAL es el resultado de una equijoin con eliminación de atributo común (es
decir, de las columnas duplicadas). El proceso a seguir es el siguiente:

1.- Concatenar todas las tuplas de A y B (es decir, hallar A x B).


2.- Seleccionar de entre estas tuplas concatenadas las que tengan iguales valores en las
columnas consideradas.
3.- Suprimir una columna de cada dos homónimas en el resultado.

Por ejemplo, dadas las relaciones R y R’, se muestran los resultados de realizar una join genérica,
una equijoin y una join natural.

R (A, B) R'(B, C) Join natural: R"(A, B, C)


1 C C 02 1 C 02
3 B D 11 3 B 27
2 A B 27 3 B 11
2 C B 11 2 C 02

92
Join para R.B < R'.B Equijoin para R.B = R'.B
(A B B C) (A B B C)
1 C D 11 1 C C 02
3 B C 02 3 B B 27
3 B D 11 3 B B 11
2 A C 02 2 C C 02
2 A D 11
2 A B 27
2 A B 11
2 C D 11

EJERCICIOS

1. Utilizando la base de datos de Proveedores y Piezas, indica las operaciones de Álgebra


Relacional necesarias para ejecutar las siguientes consultas:
a) Obtener los datos de las piezas de color rojo.
b) Obtener los nombres y ciudades de todos los proveedores.
c) Obtener los S# de los proveedores que suministran la pieza P2.
d) Obtener los S# de los proveedores que suministran la pieza P2 y viven en Londres.
e) Obtener las piezas que sean de color rojo o que pesen más de 15.

2. Dadas las siguientes relaciones, realizar las operaciones de álgebra relacional que se indican:

R1 A B C S1 D E F
a b c b g a
d a f d a f
c b d

R2 A B C D S2 C D
a b c d c d
a b e f e f
b c e f
e d c d
e d e f
a b d e

R3 A B C S3 D E
1 2 3 3 1
4 5 6 6 2
7 8 9

93
R4 A B C S4 B C D T4 A C
a b c b c d a c
d b c b c e c d
b b f a d b
c a d

a) R1 ∪ S1
b) R1 ∩ S1
c) R1 x S1
d) R1 - S1
e) ΠA,C (R1)

f) σB=‘b’ (R1)
g) R2 / S2
h) R3 JOIN S3 para B<D
i) R4 |X|B,C S4 |X|A,C T4

94
5.3. CALCULO RELACIONAL

El cálculo relacional es un lenguaje basado en el cálculo de predicados de primer orden, es un


intento de reproducir las leyes del razonamiento humano y, por tanto, de captar una parcela
reducida del lenguaje natural.

Es un lenguaje no procedimental, es decir, se expresa en él, lo que se quiere obtener, y no las


operaciones que hay que realizar para obtenerlo. La forma de expresarlo es:

Relación: Predicado

que se interpreta como "seleccionar aquellas tuplas cuyo predicado es verdadero", y el predicado
permite las comparaciones { =, <>, <, >, <=, >= } entre una variable y una constante o entre dos
variables.

Por ejemplo: Dada la relación ESTUDIANTE (DNI, NOM, EDAD, DIR)

- Seleccionar las tuplas de estudiantes llamados JUAN:

ESTUDIANTE: NOM = 'JUAN'

- Seleccionar estudiantes que viven en Bilbao y tienen más de 23 años:

ESTUDIANTE: DIR = 'BILBAO' AND EDAD > 23

- Seleccionar DNI y NOM de los estudiantes de Bilbao:

ESTUDIANTE.DNI, ESTUDIANTE.NOM: DIR='BILBAO'

Hay dos tipos dentro del cálculo relacional:

- Cálculo relacional orientado a las tuplas: utiliza la noción de 'razonable de tupla'


(variable que varía sobre alguna relación con nombre). Se procesan básicamente tuplas
de una o más relaciones. El SQL está básicamente orientado a la tupla utilizando
nombres de relación y etiquetas como variables de tupla.
- Cálculo relacional orientado a los dominios: las variables de tupla se reemplazan por
variables de dominio. Se procesan dominios (no confundir con atributos) que alcanzan
una o más relaciones.

95
5.4. ARQUITECTURA DE UN SISTEMA RELACIONAL

Aunque existen muchos sistemas relacionales comerciales (ORACLE, INFORMIX, SQL


SERVER, INGRES, etc.) se escoge la arquitectura del sistema R como ejemplo principal de un
sistema relacional, ya que incorpora muchos de los principios que se desean analizar. El objetivo
es estudiar en general las ideas relacionales basándonos en dicho sistema.

El sistema R fue desarrollado por I.B.M. de 1.974 a 1.979 con la pretensión de hacer un sistema
operacionalmente completo es decir, demostrar que era posible construir un sistema relacional
utilizable en un ambiente real para solucionar problemas verdaderos, con un rendimiento al
menos comparable al de los sistemas existentes en aquel tiempo.

El sistema R proporciona no sólo los recursos básicos de las B.D. relacionales sino también
características adicionales como son:

- Recuperación de la B.D. en caso de fallos.


- Control automático de concurrencia.
- Mecanismo flexible de autorización.
- Independencia de datos.
- Definición dinámica de la B.D.
- Facilidad de manejo.

SQL Nivel
Externo

Vista V1 Vista V2

Tabla de Tabla de Tabla de Tabla de


base B1 base B2 base B3 base B4
Nivel
Conceptual

Fichero Fichero Fichero Fichero


almacenado almacenado almacenado almacenado
S1 S2 S3 S4 Nivel
Interno

Figura 5.8. Sistema R como lo ve el usuario individual

96
En la figura 5.8. se muestra la arquitectura del sistema R.

Vamos a ver la correspondencia entre el sistema R y los componentes de la arquitectura


ANSI/SPARC (arquitectura de referencia para sistemas de gestión de BD).

1.- El equivalente al tipo de registro conceptual es la tabla de base (que tiene existencia
independiente).

2.- En el nivel externo, la tabla que ve el usuario puede ser una tabla de base o una vista. Una
vista es una tabla que no tiene existencia propia, sino que se deriva de una o varias tablas de
base. Un usuario puede estar interactuando con varias vistas y tablas de base. Obsérvese la
diferencia con la vista externa de ANSI/SPARC que contemplaba la totalidad de los datos
vistos por el usuario.

3.- En el nivel interno cada tabla de base se almacena en un fichero almacenado. Una fila de la
tabla corresponde a una ocurrencia de registro almacenado en el fichero. Un fichero almacenado
puede tener cualquier número de índices asociados con él. Los usuarios pueden enterarse de la
existencia de esos índices pero no pueden referirse directamente a ellos en las solicitudes de
acceso a datos. Los índices pueden crearse o destruirse en cualquier momento sin afectar a los
usuarios.

4.- S.Q.L. (Structured Query Language) que significa Lenguaje de Consulta Estructurado es
el sublenguaje de datos del sistema R. Este lenguaje no sólo ofrece funciones de recuperación
sino también diversidad de operaciones de actualización y otros recursos. Incluye:

- Un lenguaje de definición de datos (D.D.L.) que sirve tanto para definir vistas (nivel
externo) como tablas (nivel conceptual) e índices (nivel interno).
- Un lenguaje de manipulación de datos (D.M.L.).

El nivel general del lenguaje es comparable al del álgebra relacional, es decir, sus operadores
funcionan casi siempre en términos de conjuntos y no de registros individuales, y tampoco
incluyen ninguna referencia a rutas de acceso explícitas.

5.- El SQL puede utilizarse tanto desde un terminal ON LINE como desde un programa de
aplicación. Es decir, los usuarios de programación de aplicaciones pueden acceder a la B.D.
desde PL/I o COBOL mediante proposiciones de S.Q.L. inmerso.

97
5.5. ESTRUCTURA DE DATOS RELACIONAL (en SQL de ORACLE)

5.5.1.- TABLAS

La estructura de datos primaria del sistema relacional es la tabla de base. A continuación se


comentarán las operaciones de creación, modificación y eliminación de tablas.

5.5.1.1. Creación de una tabla

La creación de una tabla se puede hacer en cualquier momento mediante la proposición D.D.L.
de S.Q.L.:

CREATE TABLE Nombre-Tabla


(Nombre-Columna Tipo-Datos [exp. DEFAULT] [restric-col], ...,
[restric-tabla])

donde:

- Nombre columna: Ha de ser único en la tabla

- Tipo-Datos: Los tipos de datos permitidos más comúnmente usados son:


CHAR(n): Cadena de caracteres de longitud fija
VARCHAR(n): Cadena de caracteres de longitud variable.
NUMBER (n,m): Numérico de longitud variable. n: nº dígitos totales, m: nº decimales
DATE: Fecha con formato de salida DD-MON-YY (Ej: 13-NOV-96). Se almacena
también la hora como parte de la fecha.

- Expresión DEFAULT: Valor que tomará el atributo por defecto. Por ejemplo DEFAULT 5
indicaría que en caso de no asignar ningún valor al atributo, éste tomaría por defecto el valor 5.

- Restricción de columna

[[CONSTRAINT nom-restricción] NOT NULL ]


[ [CONSTRAINT nom-restricción] {UNIQUE/PRIMARY KEY}]
[ [CONSTRAINT nom-restricción] REFERENCES nom-tabla (nom-colum)
[ON DELETE CASCADE] ]
[ [CONSTRAINT nom-restricción] CHECK (condición)]

Las restricciones de columna afectan a cada columna en cuestión. Puede especificarse que la
columna es una clave primaria (PRIMARY KEY), una clave alternativa (UNIQUE KEY), o una
clave externa (REFERENCES). En el caso de claves externas, la opción ON DELETE
CASCADE indica que al borrar el valor de la clave primaria referenciada, se eliminarán también
todas las tuplas que tengan ese valor como clave externa en la tabla dependiente.

98
Además, en caso de que una columna no pueda aceptar valores nulos deberá incluirse la opción
NOT NULL (obligatorio al menos para claves primarias y alternas, para mantener la integridad
de la entidad).

La cláusula CHECK sirve para especificar comprobaciones adicionales sobre los valores de la
columna.

- Restricciones de tabla

[ [CONSTRAINT nom-restricción] {UNIQUE / PRIMARY KEY} (col-1, col-2, ...) ]


[ [CONSTRAINT nom-restricción] FOREIGN KEY (col-1, col-2,...)
REFERENCES nom-tabla [(col-1, col-2, ...) [ON DELETE CASCADE] ]
[ [CONSTRAINT nom-restricción] CHECK (condición)]

A nivel de tabla también se pueden especificar algunas restricciones de integridad. Por ejemplo,
cuando las claves primarias, alternas o externas están formadas por varios atributos, la
especificación se hará a este nivel. Con la cláusula check podemos establecer comprobaciones
que afecten a valores de dos o más columnas.

Ejemplo: Creación de la siguiente tabla:

EMPLEADOS (N-EMP, NOM-EMP, PUESTO, N-JEFE, FECHA-ALTA, SUELDO,


COMISION, N-DPTO)

donde N-JEFE y N-DPTO son claves externas que referencian a las tablas EMPLEADOS y
DEPARTAMENTOS respectivamente, y NOM-EMP es una clave alternativa. Se desea que se
cumplan las reglas de integridad de la entidad e integridad referencial, y que el sistema
compruebe que todo valor de sueldo sea siempre superior a 500. Además, el valor por defecto de
la comisión deberá ser 0.

CREATE TABLE EMPLEADOS


(N-EMP NUMBER NOT NULL PRIMARY KEY,
NOM-EMP CHAR(10) NOT NULL UNIQUE,
PUESTO CHAR(9),
N-JEFE NUMBER REFERENCES EMPLEADOS(N-EMP),
FECHA DATE,
SUELDO NUMBER (10,2) CHECK (SUELDO>500),
COMISION NUMBER(9,0) DEFAULT 0,
N-DPTO NUMBER(2) NOT NULL REFERENCES DEPARTAMENTOS(N-DPTO))

5.5.1.2. Modificación de la estructura de una tabla

Una vez creada una tabla, se puede modificar su estructura para incluir alguna columna nueva o
para modificar las características de las columnas existentes. Para ello, se usarán las
instrucciones:

ALTER TABLE nom-tabla


ADD (nom-columna tipo datos [NOT NULL] ... , ...)

99
ALTER TABLE nom-tabla
MODIFY (nom-columna tipo datos [NOT NULL]... , ...)

5.5.1.3. Destrucción de una tabla

La destrucción de una tabla se puede hacer en cualquier instante mediante la proposición:

DROP TABLE Nombre-Tabla

Con lo cual se eliminan todos los registros, todos los índices y todas las vistas de la tabla,
liberándose su espacio de almacenamiento y eliminándose la definición de la tabla del
diccionario de datos.

A la hora de borrar las tablas es preciso tener en cuenta que no se pueden eliminar tablas
principales sin haber borrado primero todas sus tablas dependientes, ya que se violaría la
integridad referencial.

5.5.2. INDICES

Los índices son estructuras que permiten al servidor localizar rápidamente una fila en una tabla.
Las entradas de los índices en una BD Oracle se almacenan mediante árboles B*-tree, lo que
garantiza un trayecto de acceso corto hasta el valor clave. Los índices se utilizan para mejorar el
rendimiento, pero los usuarios no pueden hacer referencia a los mismos, sino que la decisión de
usar o no un índice la toma el sistema. En Oracle, se generan índices automáticamente sobre las
claves primarias, aunque el administrador puede crear índices adicionales sobre otros atributos, si
lo considera necesario para optimizar el acceso a los datos.

Para crear un índice:

CREATE [UNIQUE] INDEX Nombre-Indice


ON Nombre-Tabla
(Nombre-Columna [ASC/DEC], ...)

donde si no se especifica el orden para cada columna, se asume ASC por defecto.

La secuencia de izquierda a derecha de los campos corresponde al ordenamiento de mayor a


menor. Los valores nulos se consideran iguales entre sí y mayores que cualquier otro valor.

La opción UNIQUE KEY especifica que no puede haber dos registros en la tabla con el mismo
valor de índice. Se utiliza para claves primarias o alternativas. Por ejemplo, si consideramos que
en la B.D. de proveedores y piezas va a haber muchos accesos a través del nombre del
proveedor podemos crear un índice sobre el mismo para optimizar los accesos:

CREATE UNIQUE INDEX XNOM ON S (NOMS)

Una vez creado un índice, se mantiene automáticamente hasta su supresión.

100
Para suprimir un índice:

DROP INDEX Nombre-Indice

5.5.3. ANALISIS

Es preciso señalar ciertas diferencias existentes entre los sistemas relacionales comerciales y el
modelo relacional general:

- En general los dominios no están soportados.


- En la mayoría, la unicidad de las claves candidatas es opcional. Se puede mantener la unicidad
mediante la definición de índice único.
- En algunos, la regla de integridad 1ª (integridad de la entidad) es opcional. Se cumplirá la
restricción sólo si se especifica NOT NULL.
- En algunos, la regla de integridad 2ª (integridad referencial) no se hace cumplir.

5.5.4. EJERCICIO DE REPASO

Consideremos la siguiente tabla:

ASIGNATURAS (COD_A, NOM_A, CRED)

Se pide codificar las sentencias necesarias para:

1. Crear la tabla haciendo cumplir las reglas de integridad


2. Añadir una columna TIPO de asignatura, que indicará si la misma es troncal, optativa,
etc.
3. Aumentar la longitud del NOM_A a 5 caracteres
4. Crear un índice sobre el nombre de la asignatura

101
5.6. MANIPULACION DE DATOS (SQL para ORACLE)

5.6.1. OPERACIONES DE ACTUALIZACION

5.6.1.1. CONTROL DE LOS CAMBIOS

Una transacción es una serie de operaciones ejecutadas sobre un conjunto de datos y que
constituyen una unidad lógica de trabajo (ULT). Es decir, una ULT es una secuencia de
sentencias de SQL que son tratadas como una unidad. Todos los cambios realizados por estas
sentencias se hacen permanentes o se deshacen al mismo tiempo. Se pueden utilizar dos
sentencias:

- COMMIT WORK: Termina una ULT y hace permanentes los cambios.


- ROLLBACK WORK: Termina una ULT y deshace los cambios producidos durante la
transacción.

Una transacción comienza con la primera sentencia ejecutable tras una COMMIT, ROLLBACK
o una conexión a la BD. La transacción finaliza con una COMMIT, ROLLBACK o una
desconexión de la BD. Por defecto, una salida normal provoca una COMMIT.

5.6.1.2. Inserción: INSERT

Para insertar filas en una tabla de una en una se utiliza la proposición INSERT, cuyo formato es
el siguiente:

INSERT INTO <tabla> [(col-1, col-2, ...)]


VALUES (val-1, val-2, ...)

Por ejemplo, adicionar la pieza P7 (de nombre ARANDELA, color GRIS, peso 2, ciudad
ATENAS) a la tabla P.

INSERT INTO P
VALUES ('P7', 'ARANDELA', 'GRIS', 2, 'ATENAS')

Nótese que los valores han de tener el mismo orden que las columnas dentro de la tabla. En caso
de que algún valor fuese desconocido, habría que especificar los campos.

INSERT INTO P (P#, PESO, NOMP)


VALUES ('P7', 2, 'ARANDELA')

En este caso, la fila se creara con valores nulos para COLOR y CIUDAD.

102
5.6.1.3. MODIFICACION: UPDATE

Para modificar los valores de una tabla se utiliza la instrucción UPDATE, cuyo formato es el
siguiente:

UPDATE Nombre-Tabla SET Col-1 = Valor-1, Col-2=Valor-2 ...


WHERE Condición

Ejemplos:

1. Cambiar el color de la pieza P2 a amarillo, aumentar su peso en 5 libras y poner su ciudad a


NULL.

UPDATE P SET COLOR = 'AMARILLO',


PESO = PESO + 5,
CIUDAD = NULL
WHERE P# = 'P2'

2. Doblar el estado de todos los proveedores de Londres.

UPDATE S SET ESTADO = 2 * ESTADO WHERE CIUDAD = 'LONDRES'

3. Utilizando una subconsulta, poner la cantidad en cero para todos los envíos de todos los
proveedores de Londres.

UPDATE SP SET CTD = 0


WHERE S# = ANY (SELECT S # FROM S WHERE CIUDAD = 'LONDRES')

4. Para el proveedor S2, cambiar el número a S9.

UPDATE S SET S# = 'S9' WHERE S# = 'S2'


UPDATE SP SET S# = 'S9' WHERE S# = 'S2'

Puesto que no es posible actualizar más de una tabla con una proposición UPDATE, necesitamos
dos para mantener la integridad de la B.D., ya que el dato S# aparece en dos tablas.

Es preciso señalar que entre las dos proposiciones se incumple temporalmente integridad
referencial.

Algunos sistemas no permiten modificación de claves primarias para evitar complicaciones (en
estos casos, sería preciso una supresión seguida de una inserción).

5.6.1.4. SUPRESION: DELETE

Se pueden borrar filas de una tabla pero no columnas ni campos individuales de una fila.

Para suprimir filas en una tabla se utiliza la proposición DELETE, cuyo formato es el siguiente:

103
DELETE FROM <Tabla> WHERE <Condición>

Ejemplos:

1. Suprimir el proveedor S1.

DELETE FROM S WHERE S# = 'S1'


En caso de que el proveedor S1 tuviese algún envío, habrá que mantener la integridad
referencial.

2. Suprimir todos los envíos de la BD.

DELETE FROM SP

5.6.1.5. EJERCICIOS DE REPASO

Utilizando la base de datos de Proveedores y Piezas, codifica en SQL las siguientes operaciones:

1. Insertar en S un nuevo proveedor: S6, Aguirre, 50, París


2. Insertar en P, una nueva pieza: P8, Tornillo, 10
3. Modificar la ciudad del proveedor S3 y ponerle Madrid
4. Eliminar los proveedores cuyo estado sea menor que 30
5. Comentar si las siguientes operaciones se realizarían correctamente y por qué:

a) INSERT INTO P (NOMP, COLOR, CIUDAD)


VALUES (‘TORNILLO’, ‘ROJO’, ‘BILBAO’)

b) UPDATE P
SET CIUDAD=MADRID, PESO=20
WHERE P#=P3’

c) DELETE FROM P WHERE P#=’P1’


DELETE FROM SP WHERE P#=’P1’

5.6.2. OPERACIONES DE RECUPERACION

5.6.2.1. SELECCION DE COLUMNAS DE UNA TABLA

Formato:

SELECT nombre-columnas FROM nombre-tabla

donde 'nombre-columnas' son los nombres de las columnas que queremos visualizar separadas
por comas. Poniendo '*' se visualizarán todas.

104
Si utilizo una tabla cuyo propietario no soy yo (es decir, ha sido creada por otro usuario) debo
utilizar un prefijo para referirme a ella.

EJEMPLOS:

- Obtener los datos de todos los proveedores

SELECT * FROM S

Es equivalente a poner:

SELECT S#, NOMS, ESTADO, CIUDAD FROM S

Resultado:

S# NOMS ESTADO CIUDAD


S1 Salazar 20 Londres
S2 Jaramillo 10 París
S3 Bernal 30 París
S4 Caicedo 20 Londres
S5 Aldana 30 Atenas

- Obtener los números de pieza de todas las piezas suministradas:

SELECT P# FROM SP

Resultado:
P#
P1
P2
P3
P4
P5
P6
P1
P2
P2
P2
P4
P5

Si no se quieren valores repetidos:

SELECT DISTINCT P# FROM SP

105
Resultado:
P#
P1
P2
P3
P4
P5
P6

5.6.2.2. SELECCION DE FILAS DE UNA TABLA

Se obtienen todas aquellas filas que cumplan una determinada condición.

SELECT * FROM nombre-tabla WHERE condición

Para las condiciones se pueden utilizar los operadores:


= igual
<> , ┐= no igual
> mayor
>= mayor o igual
< menor
<= menor o igual
OR, AND para enlazar varias condiciones.
() para agrupar condiciones y expresar el orden de evaluación

Por ejemplo, obtener los datos de los proveedores de París con ESTADO > 20.

SELECT * FROM S WHERE CIUDAD = 'PARIS' AND ESTADO > 20

S# NOMS ESTADO CIUDAD


S3 Bernal 30 París

La selección de filas de una tabla puede realizarse de diferentes formas. Veamos algunas:

a) Selección de filas que contengan un valor contenido en una lista (IN)

Para seleccionar las filas de la tabla S correspondientes a proveedores de Londres o Atenas,


podemos usar la instrucción:

SELECT * FROM S
WHERE CIUDAD = ‘LONDRES’ OR CIUDAD = ‘ATENAS’
o bien:

106
SELECT * FROM S
WHERE CIUDAD IN (‘LONDRES’, ‘ATENAS’)

S# NOMS ESTADO CIUDAD


S1 Salazar 20 Londres
S4 Caicedo 20 Londres
S5 Aldana 30 Atenas

Si queremos establecer que las filas no contengan los valores de la lista, podemos utilizar NOT
IN (lista).

b) Selección de filas que contengan un valor dentro de un rango (BETWEEN)

Por ejemplo, seleccionar las piezas de P cuyo peso esté entre 12 y 15:

SELECT * FROM P
WHERE PESO BETWEEN 12 AND 15
(los extremos están incluídos)

En sentido opuesto, se puede utilizar: NOT BETWEEN X AND Y

c) Selección de filas que contengan una combinación especial de caracteres


(LIKE)

La función LIKE utiliza dos caracteres especiales:

% representa cualquier cadena de 0 o más caracteres.


_ representa una posición de caracter.

Por ejemplo, para seleccionar los datos de las piezas cuyo NOMP incluya una R:

SELECT *
FROM P
WHERE NOMP LIKE '%r%'

P# NOMP COLOR PESO CIUDAD


P1 Tuerca Rojo 12 Londres
P2 Perno Verde 17 París
P3 Tornillo Azul 17 Roma
P4 Tornillo Rojo 14 Londres

O bien, seleccionar de la tabla P, las filas cuyos nombres de pieza tengan 5 letras y comiencen
con la letra P:

107
SELECT *
FROM P
WHERE NOMP LIKE 'P_ _ _ _'

P# NOMP COLOR PESO CIUDAD


P2 Perno Verde 17 París

En sentido inverso puede utilizarse NOT LIKE.

d) Seleccionar filas que satisfagan una condición calculada:

En la cláusula WHERE se pueden establecer condiciones que impliquen un cálculo. Se pueden


utilizar los operadores: +, -, *, /

Suponiendo la tabla:

N_PROD PRECIO CANT


001 50 1
002 70 2
003 25 5
004 30 3

Seleccionar qué productos supondrán un importe total superior a 100.

SELECT * FROM PEDIDOS


WHERE PRECIO * CANT > 100

N_PROD PRECIO CANT


002 70 2
003 25 5

5.6.2.3. OTROS TIPOS DE SELECCION

SELECCION DE INFORMACION CALCULADA DE LOS DATOS DE UNA TABLA

La cláusula SELECT puede incluir la selección de columnas que se obtengan como resultado de
aplicar una expresiones aritmética a una o más columnas de la tabla.

Por ejemplo, obtener el número de pieza y el peso de la pieza en gramos (1 libra = 454 grs), para
todas las piezas, teniendo en cuenta que en la tabla P los pesos se dan en libras.

SELECT P#, PESO * 454 FROM P

108
Siendo el resultado:

P#
P1 5448
P2 7718
P3 7718
P4 6356
P5 5448
P6 8626

SELECCION DE INFORMACION UTILIZANDO FUNCIONES ESTÁNDAR

Las funciones estándar se clasifican en dos categorías:

- funciones de columna
- funciones escalares

a) FUNCIONES DE COLUMNA:

El S.Q.L. proporciona varias funciones integradas especiales para mejorar su poder básico de
recuperación. Se aplican sobre los datos recuperados de una tabla. Estas funciones son:

1. COUNT: Da el número de valores.


COUNT (col): devuelve el nº de filas donde la expresión no es NULL
COUNT (*): devuelve el nº de filas incluyendo NULLs
2. SUM(col): Da la suma de valores de la columna.
3. AVG(col): Da el promedio de los valores de la columna.
4. MAX(col): Da el valor máximo de los valores de la columna.
5. MIN(col): Da el valor mínimo de los valores de la columna.

Ejemplos

- Obtener el número total de proveedores:

SELECT COUNT (*) FROM S

Siendo el resultado igual a 5.

- Obtener el número total de proveedores que actualmente suministran piezas:

SELECT COUNT (DISTINCT S#) FROM SP

Siendo el resultado igual a 4. DISTINCT se emplea para eliminar los valores redundantes antes
que se aplique la función.

109
- Obtener el número de envíos para la pieza P2:

SELECT COUNT (*) FROM SP WHERE P# = 'P2'

Siendo el resultado igual a 4.

- Obtener la cantidad total suministrada de la pieza P2.

SELECT SUM (CTD) FROM SP WHERE P# = 'P2'

Siendo el resultado igual a 1.000.

- Obtener cuál es el estado máximo de los proveedores.

SELECT MAX (ESTADO) FROM S

b) FUNCIONES ESCALARES:

Son funciones que se aplican a valores individuales de cada fila y producen un resultado para
cada fila. A continuación se muestran algunas de ellas:

TO_CHAR (f): Convierte una fecha a un valor CHAR.


TO_DATE (s): Crea una fecha DD-MON-AA a partir de una cadena de caracteres.
TO_NUMBER(s): Convierte una cadena a valor numérico.
UPPER(s): Devuelve una cadena con letras mayúsculas.
SQRT (n): Devuelve la raíz cuadrada.

ORDENAR LAS FILAS OBTENIDAS COMO RESULTADO DE UNA CONSULTA

Podemos especificar que las filas que se van a visualizar como resultado de una consulta
aparezcan en un determinado orden. Para ello se utiliza la cláusula ORDER BY al final de la
instrucción SELECT. La sintaxis es:

ORDER BY col-1 {ASC/DESC}, col-2 {ASC/DESC}, . . .

La ordenación puede realizarse:

a) SEGUN EL VALOR DE UNA O MAS COLUMNAS: Por defecto la ordenación es en


ascendente. Si queremos orden descendente, añadir DESC.

Por ejemplo, obtener los números de proveedor y estado de los proveedores en París, en orden
descendente de estado.

SELECT S#, ESTADO FROM S WHERE CIUDAD = 'París'

110
ORDER BY ESTADO DESC

Siendo el resultado:
S# ESTADO
S3 30
S2 10

b) SEGUN UN RESULTADO CALCULADO: A cada columna del resultado se le puede


hacer referencia en el ORDER BY mediante un número que indica su posición (de izquierda a
derecha).

Por ejemplo, obtener los nº de producto e importes de los pedidos de la tabla PEDIDOS (N-
PROD, PRECIO, CANT) cuyo importe sea superior a 1000, y ordenar el resultado en
descendente por dicho importe.

SELECT N-PROD, PRECIO * CANT


FROM PEDIDOS
WHERE PRECIO * CANT > 1000
ORDER BY 2 DESC

EJERCICIOS DE REPASO DE CONSULTAS SENCILLAS

Utilizando la BD de Proveedores y Piezas codifica en SQL las siguientes operaciones e


indica cuál sería el resultado:

1. Obtener la información de los proveedores que no sean ni de Londres ni de París.


2. Obtener los datos de los proveedores que tengan al menos dos ‘A’ en su nombre.
3. Obtener los datos de los envíos cuya cantidad esté entre 100 y 300.
4. Obtener los datos de las piezas que no tengan una O en la 2ª posición de su NOMP.
5. Obtener el peso medio de las piezas
6. Obtener el S# y la raíz cuadrada del ESTADO de los 3. Obtener el P#, NOMP y PESO de
todas las piezas ordenando el resultado en descendente por NOMP y en ascendente por
P#.
7. Obtener cuántos colores distintos de piezas aparecen en la tabla P.

111
5.6.2.4. UTILIZACIÓN DE CONDICIONES DE BUSQUEDA AVANZADAS

- SELECCIÓN DE DATOS DE DOS O MÁS TABLAS

La función JOIN del SQL permite escribir una consulta que combine dos o más tablas. Para ello
es preciso:

- indicar FROM tabla-1, tabla-2...


- utilizar prefijos para los nombres de columna que indiquen a qué tabla pertenecen, en
caso de existir en varias de ellas.
- indicar en la cláusula WHERE las condiciones de emparejamiento de tablas

Para especificar a qué tabla pertenece un determinado campo, se utiliza como prefijo del campo
el nombre de la tabla y un punto.

Por ejemplo, por cada pieza suministrada obtengo el número de la pieza y los nombres de todas
las ciudades de proveedores que suministran la pieza:

SELECT DISTINCT P#, CIUDAD FROM SP, S WHERE SP.S# = S.S#

Siendo el resultado:

P# CIUDAD
P1 Londres
P1 París
P2 Londres
P2 París
P3 Londres
P4 Londres
P5 Londres
P6 Londres

En este caso, el modo de operación es el siguiente:

a) Se forma el producto cartesiano SP x S.


b) Se eliminan las filas que no cumplan la condición.
c) Se extraen las columnas especificadas en la SELECT.
d) Si se ha especificado DISTINCT, se eliminan los renglones duplicados.

112
USO DE ETIQUETAS

En algunos casos es engorroso escribir todos los prefijos. SQL permite definir una tabla de
etiquetas de forma que podamos identificar los nombres de las tablas con una etiqueta y así se
simplifiquen las consultas.

Por ejemplo, dadas las tablas:

PIEZA (N-PIEZA, DESCRIPCION, CANTIDAD)


PROVEEDOR (N-PROV, N-PIEZA, PRECIO)

La sentencia SQL para obtener los datos de las piezas suministradas por el proveedor nº54 y dar
el resultado ordenado por nº de pieza será:

SELECT P.N-PIEZA, DESCRIPCION, CANTIDAD


FROM PIEZA P, PROVEEDOR V
WHERE P.N-PIEZA = V.N-PIEZA
AND N-PROV = 54
ORDER BY P.N-PIEZA

Las etiquetas deben comenzar con una letra y pueden tener hasta un máximo de 18 caracteres.

COMBINAR INFORMACION EN LA MISMA TABLA

En ocasiones necesitamos combinar o relacionar información dentro de una misma tabla. En ese
caso podemos asignar dos etiquetas distintas a la misma tabla, de forma que la podemos usar
como si fueran dos tablas diferentes.

Por ejemplo, obtenga todas las parejas de número de proveedor tales que los dos proveedores
estén localizados en la misma ciudad.

SELECT PRIMERO.S#, SEGUNDO.S# FROM S PRIMERO, S SEGUNDO


WHERE PRIMERO.CIUDAD = SEGUNDO.CIUDAD
AND PRIMERO.S# < SEGUNDO.S#

Siendo el resultado:

S# S#
S1 S4
S2 S3

En este caso se han asignado dos nombres arbitrarios a la tabla (PRIMERO y SEGUNDO).

113
EJERCICIOS DE REPASO

Codificar las sentencias SQL para realizar las siguientes consultas:

1. Obtener los proveedores que suministran la pieza P1 indicando P#, S#, y NOMS
2. Obtener las piezas que suministran los proveedores de Londres indicando S#, NOMS, P#,
NOMP
3. Dada la siguiente tabla, obtener un listado en el que aparezca el NE, NOME y NOM de su
jefe.

EMP
NE NOME NE-JEFE
E1 ANA E1
E2 PEPE E1
E3 JON E1
E4 MAITE E4
E5 PABLO E4

ESPECIFICAR CONDICIONES DE BÚSQUEDA PARA GRUPOS

Consiste en hacer una selección de filas según una determinada condición, agruparlas según el
contenido de una/s determinada/s columna/s, y finalmente seleccionar aquellos grupos que
cumplan una condición específica (por cada grupo se obtendrá una fila en el resultado).

El formato completo de la SELECT tiene la forma:

SELECT <Campos-Selección> FROM <Tabla> WHERE <Condición-fila>


GROUP BY <Columnas-Agrupación>
HAVING <Condición-Grupo>
ORDER BY <Orden>

Donde el orden de aplicación es el siguiente:

1. FROM: Hace una copia de la tabla especificada.


2. WHERE: Elimina las filas que no satisfagan la condición.
3. GROUP BY: Agrupa las filas restantes según el valor del campo especificado.
4. HAVING: Elimina los grupos que no satisfagan una condición.
5. SELECT: Extrae las columnas especificadas (un valor por cada grupo).
6. ORDER BY: Ordena la tabla resultado según el orden especificado.

Ejemplo

- Por cada pieza suministrada, obtener el número de pieza y la cantidad total suministrada de la
misma:

114
SELECT P#, SUM (CTD) FROM SP GROUP BY P#

Es decir, agrupa todas las filas de la tabla SP con el mismo P# y calcula la suma de las CTD de
cada grupo. El resultado sería:

P#
P1 600
P2 1.000
P3 400
P4 500
P5 500
P6 100

- Obtener los números de pieza para todas las piezas suministradas por más de un proveedor:

SELECT P#
FROM SP
GROUP BY P#
HAVING COUNT (*) > 1

Es decir, primero se agrupan las filas de SP con igual P# y a continuación se seleccionan


aquellos con más de una fila.

Resultado:
P#
P1
P2
P4
P5

- Para todas las piezas tales que la cantidad total suministrada sea superior a 300 (excluyendo del
total todos los envíos para los cuales la cantidad sea menor o igual a 200), obtener el número de
la pieza y la cantidad máxima suministrada de la pieza, y arreglar el resultado en orden
ascendente de cantidad máxima y descendente de número de pieza.

SELECT P#, MAX (CTD)


FROM SP WHERE CTD > 200
GROUP BY P#
HAVING SUM (CTD) > 300
ORDER BY 2, P# DESC

Siendo el resultado:

115
P#
P1 300
P5 400
P3 400
P2 400

Es decir:
1. Se eliminan las filas de SP que no satisfagan CTD > 200.
2. Se agrupan las filas con igual P#.
3. Se eliminan los grupos cuyas sumas de cantidades no sea superior a 300.
4. Se extrae el número de parte y la cantidad máxima de cada grupo.
5. Se ordena el resultado en ascendente por el segundo campo de la SELECT (MAX
(CTD)) y en descendente por P#.

EJERCICIOS DE REPASO

Dada la siguiente tabla codifica en SQL las consultas que se indican y muestra el resultado de su
ejecución.

MATRICULA
DNI NOMA ASIG CURSO CALIF
1 A.A. PROG 1 5
1 A.A. EDA 1 3
1 A.A. BD 2 7
1 A.A. MP 2 5
1 A.A. TP 2 8
2 B.B. PROG 1 4
2 B.B. BD 2 9
2 B.B. MP 2 3
2 B.B. TP 2 10
3 C.C. PROG 1 2
3 C.C. BD 2 6
3 C.C. TP 2 7

1. Averiguar de cuántas asignaturas se ha matriculado cada alumno, indicando NOMA


y nº asignaturas.
2. Obtener la nota media de cada alumno en asignaturas de 2º, indicando NOMA y nota
media.
3. Obtener cuántos alumnos hay matriculados de cada asignatura, indicando ASIG y
nº alumnos.
4. Obtener en qué asignaturas hay más de 2 alumnos aprobados (CALIF>4) indicando
ASIG, número de alumnos aprobados y calificación más alta obtenida en dicha
asignatura.

116
USO DE SUBCONSULTAS

Consiste en realizar una selección a partir de los resultados obtenidos en otra consulta. Para ello
se pueden utilizar cualificadores como son:

- ANY: Compara un valor con cada valor devuelto en una subconsulta. Puede ir
precedido de los comparadores =, !=, >, <, >=, <=

- IN: Compara un valor con cada valor de una lista devuelta por una subconsulta. Es
equivalente a =ANY.

- =: Compara un valor con el valor devuelto en una subconsulta.

- EXISTS: Toma valor verdadero si el resultado de la subconsulta no es vacío. Es decir,


su misión consiste en comprobar la existencia o ausencia (NOT EXISTS) del valor
devuelto por una subconsulta.

Ejemplos:

- Obtenga los nombres de proveedor para proveedores que suministran la pieza P2. Una forma de
consulta sería:

SELECT DISTINCT NOMS FROM S,SP WHERE S.S# = SP.S#


AND SP.P# = 'P2'

Siendo el resultado:
NOMS
SALAZAR
JARAMILLO
BERNAL
CAICEDO

Otra forma sería utilizando el operador ANY:

SELECT NOMS FROM S WHERE S# = ANY (SELECT S# FROM SP


WHERE P# = 'P2')

En este caso:

a) Primero se toma el conjunto de números de proveedor de la tabla SP correspondiente a


la parte 'P2' es decir, el conjunto {'S1', 'S2', 'S3', 'S4'}.
b) A continuación se eligen aquellas filas de la tabla S cuyo S# pertenezca al conjunto
seleccionado, es decir, las que cumplan la condición S# = ANY ({'S1', 'S2', 'S3', 'S4'}).
c) De dichas filas se extrae el NOMS.

Lo mismo pero usando el operador IN, se haría:

117
SELECT NOMS FROM S WHERE S# IN (SELECT S# FROM SP
WHERE P# = 'P2')

La misma operación pero utilizando el operador EXISTS se codificaría:

SELECT NOMS FROM S WHERE EXISTS


(SELECT * FROM SP WHERE SP.S# = S.S# AND P# = 'P2')

El funcionamiento en esta caso es diferente: La subselect se ejecutará una vez por cada fila de la
tabla S. Si hay alguna fila en la tabla SP con el mismo S# y P#=’P2’, EXISTS devolverá valor
cierto y el nombre del proveedor pasará al resultado. Se suele poner * porque las columnas a
recuperar en la subselect son irrelevantes.

- Dar la información de los proveedores que suministran piezas en cantidad


superior a 300:

SELECT * FROM S
WHERE S# IN (SELECT DISTINCT S# FROM SP
WHERE CTD > 300)

El segundo comando SELECT (subconsulta) produce una lista de números de proveedor de la


tabla SP tal que suministren piezas en cantidad superior a 300. Este resultado es utilizado para
seleccionar de la tabla S todas las filas que tengan esos números de proveedor.
Se pueden utilizar hasta 16 subconsultas anidadas.

USO DE OPERADORES DE CONJUNTO

Los operadores de conjunto combinan los resultados de varias consultas obteniendo una
relación resultado. Son los siguientes:

UNION

Obtiene la unión de las filas resultado de varias consultas, eliminando duplicados.

... SELECT .....


UNION SELECT ....

INTERSECT

Obtiene como resultado el conjunto de filas que son la intersección de varias consultas.

... SELECT ...


INTERSECT SELECT ...

118
MINUS

Obtiene como resultado las filas que pertenecen al primer conjunto y no al segundo.

...SELECT
MINUS SELECT ...

EJERCICIOS DE REPASO

Codifica en SQL las siguientes consultas utilizando la BD de Proveedores y Piezas:


1. Obtener los S# de los proveedores que suministran piezas rojas (de 3 formas distintas).
2. Obtener los S# de los proveedores que viven en Londres y suministran la pieza P1 (de 4
formas distintas)

RECUPERACION QUE COMPRENDE A NULL

Para mencionar los valores nulos podemos usar:

nombre-column IS NULL
nombre-column IS NOT NULL

Los predicados se evalúan usando una lógica de tres valores: verdadero, falso y desconocido. El
resultado de una comparación donde interviene un valor nulo, es siempre desconocido, es decir,
ninguna de las siguientes comparaciones da verdadero:

Nulo > 25
Nulo < 25
Nulo = 25
Nulo <> 25
Nulo = Nulo

Por ejemplo, si el proveedor S5 tiene un estado nulo y hacemos la siguiente selección:

SELECT S# FROM S WHERE ESTADO > 25

El resultado sería:
S#
S3

Si quisiéramos incluir los proveedores con valor nulo, deberíamos poner:

SELECT S# FROM S WHERE ESTADO > 25 OR ESTADO IS NULL

En cuyo caso, el resultado sería:

119
S#
S3
S5

5.6.3. DICCIONARIO DE DATOS

El diccionario de datos o catálogo del sistema es el componente del SGBD que contiene la
descripción de los datos y otros objetos de la base de datos (relaciones, atributos, etc.), también
denominados metadatos (‘datos sobre datos’). Todo sistema relacional dispone de un diccionario
de datos soportado mediante un conjunto de relaciones de interés para el usuario y para el
administrador de base de datos.

Cualquier operación que modifique la estructura de una tabla provoca que el cambio se refleje
automáticamente en el diccionario. El diccionario de datos puede ser consultado por los usuarios
pero es gestionado por el sistema de gestión de la BD.

En ORACLE algunas de estas relaciones son:

• USER_CATALOG (CAT): Información sobre las tablas, vistas y sinónimos definidos por
el usuario.
• USER_TAB_COLUMNS (COLS): Información sobre las columnas de las tablas y vistas
definidas por el usuario.
• USER_INDEXES (IND): Información sobre los índices definidos (tanto los definidos por el
usuario como los creados automáticamente por el sistema).
• USER_TABLES (TABS): Información sobre las tablas definidas por el usuario.
• USER_CONSTRAINTS: Información sobre las restricciones de integridad definidas en las
diversas tablas.

Se puede utilizar la sentencia SELECT de SQL para consultar dicha información con la misma
sintaxis estudiada. Por ejemplo, para ver qué tablas y vistas me pertenecen:

SELECT TABLE_NAME FROM TABS

Para saber qué tablas tienen una columna llamada S#:

SELECT TABLE_NAME FROM COLS WHERE COLUMN_NAME = 'S#'

o bien, para conocer de qué columnas consta la tabla S:

SELECT COLUM_NAME FROM COLS WHERE TABLE-NAME='S'

120
5.6.4. VENTAJAS DEL DML DE SQL

Si comparamos el DML de SQL con DMLs de niveles más bajos podemos concluir las
siguientes ventajas:

- SENCILLEZ: Muchos problemas se pueden expresar con mayor facilidad. Además la sencillez
implica mayor productividad.
- COMPLETITUD: El lenguaje es relacionalmente completo, lo que significa que para un gran
número de consultas el usuario no necesita recurrir a ciclos o bifurcaciones (esto no se aplica al
SQL INMERSO, donde el programador a menudo tendrá que recurrir a la construcción de
ciclos).
- NO PROCEDIMENTALIDAD: Es un lenguaje no procedimental. Una proposición SELECT
por ejemplo, sólo especifica qué datos quiere y no el procedimiento para obtenerlos.
- INDEPENDENCIA DE DATOS: Las proposiciones DML de SQL no incluyen ninguna
referencia a rutas de acceso explícitas tales como índices o secuencia física.
- FACILIDAD DE AMPLIACION: Se puede ampliar el poder recuperación por medio de la
provisión de funciones integradas.
- SOPORTE DE LENGUAJES DE NIVEL SUPERIOR

121
5.7. NIVEL EXTERNO: VISTAS

5.7.1. CREACION DE VISTAS

Una vista externa de ANSI/SPARC es en el sistema relacional, un conjunto de tablas, algunas de


ellas tablas de base y otras vistas. El esquema externo se compone de definiciones de esas tablas
de base y vistas.

Una VISTA se puede considerar como una tabla virtual, es decir, una tabla que no existe en
realidad por derecho propio, sino que se deriva de una o más tablas de base. Por tanto, no hay un
fichero almacenado que represente de modo directo a la vista por sí misma. En cambio, en el
diccionario se almacena una definición de la vista. Una vista se crea al ejecutar la proposición:

CREATE VIEW <Nombre-de-Vista> [(Nombre-Columna, ...]


AS Proposición-SELECT

Por ejemplo, definir una vista que sea una proyección de un subconjunto horizontal de la tabla S.
La vista se llamará PROVEEDORES_LONDRES, y tendrá los campos S#, NOMS y ESTADO
de los proveedores de Londres:

CREATE VIEW PROVEEDORES_LONDRES


AS SELECT S#,NOMS,ESTADO
FROM S
WHERE CIUDAD='Londres'

Si se quiere dar nombre diferente a las columnas de la vista de los originales en la tabla:

CREATE VIEW PROVEEDORES_LONDRES (NUM_PROV, NOM_PROV, ESTADO)


AS SELECT S#,NOMS,ESTADO
FROM S
WHERE CIUDAD='Londres'

En el caso de definir una vista a partir de varias tablas donde los nombres no son únicos, deberá
especificarse su procedencia mediante un prefijo, por ejemplo:

CREATE VIEW PARES_CIUDAD (SCIUDAD,PCIUDAD)


AS SELECT DISTINCT S.CIUDAD,P.CIUDAD
FROM S, SP, P
WHERE S.S#=SP.S#
AND SP.P#=P.P.P#

Una vez que se define una vista el usuario puede utilizarla como si fuera una tabla de base real
con algunas restricciones. Por ejemplo, para obtener los proveedores de Londres con estado
menor que 30, se podría consultar la vista creada de la siguiente forma:

122
SELECT * FROM PROVEEDORES_LONDRES
WHERE ESTADO < 30
ORDER BY ESTADO

Para eliminar una vista se utiliza la sentencia:

DROP VIEW nombre-vista

5.7.2. OPERACIONES SOBRE VISTAS

Una vista es una 'ventana' sobre los datos reales, no una copia separada de esos datos. Los
cambios en los datos reales son visibles a través de la vista y las operaciones contra la vista se
convierten en operaciones sobre los datos reales.

Las operaciones de recuperación SELECT no presentan ningún problema. Sin embargo para que
una vista pueda aceptar actualizaciones debe satisfacer las restricciones siguientes:

1. Cada fila distinta de la vista debe corresponder a una fila diferente e identificable
de manera única en la tabla base.
2. Cada columna distinta de la vista debe corresponder a una columna diferente e
identificable de manera única en la tabla base.

Por tanto, para que una vista se considere actualizable, no puede ser una proyección genuina (con
los duplicados eliminados), ni una unión, ni el resultado de un GROUP BY, ni tener campos
calculados a partir de otros.

A continuación se muestran algunos ejemplos explicativos:

Ejemplo 1: Sea V1 una proyección de la tabla P sin los duplicados:

CREATE VIEW V1 AS SELECT DISTINCT COLOR,CIUDAD FROM P

La extensión de V1 sería:

COLOR CIUDAD Valores P# correspondientes


Rojo Londres P1, P4, P6
Verde París P2
Azul Roma P3
Azul París P5

Queda claro que V1 no puede soportar operaciones INSERT, puesto que se debería especificar
cuáles serían los valores de P# correspondientes (P# es clave primaria y no acepta valores nulos).

Las operaciones DELETE y UPDATE podrían definirse en teoría (para suprimir o actualizar las
filas correspondientes de P) pero sería mejor hacerlo directamente sobre P, ya que en algún caso
implicaría borrar o modificar varias filas de P.

123
Ejemplo 2: Sea la vista V2 que comprende una reunión (JOIN) de las tablas SP y S sobre S#:

CREATE VIEW V2 AS SELECT P#,CIUDAD FROM SP,S


WHERE SP.S#=S.S#

Su extensión correspondiente es:

P# CIUDAD Valores de S# correspondientes


P1 Londres S1
P2 Londres S1
P3 Londres S1
P4 Londres S1
P5 Londres S1
P6 Londres S1
P1 París S2
P2 París S2
P2 París S3
P2 Londres S4
P4 Londres S4
P5 Londres S4

V2 no puede admitir ninguna operación de actualización por los siguientes motivos:


- Insertar una pareja nueva (P#,CIUDAD) implicaría la inserción de una nueva fila de SP
para lo cual se necesitaría el valor de S#.
- Suprimir una pareja (P#,CIUDAD) requeriría la eliminación de alguna fila de SP, pero
no siempre es claro cual sería. Por ejemplo, la pareja (P2,PARIS) puede corresponder a
S2 o a S3.
- Actualizar una pareja (P#,CIUDAD), por ejemplo, cambiar (P2,PARIS) por
(P2,LONDRES), puede dar a entender que el proveedor en cuestión (¿Cual? ¿S2 ó S3?)
ha cambiado de localidad, o que la pieza ahora es suministrada por un proveedor
diferente (¿cual? ¿S1 ó S4?).

Ejemplo 3: Sea la vista V3 que incluye una GROUP BY y una función integrada:

CREATE VIEW V3(P#,SUMACTD) AS SELECT P#,SUM(CTD)


FROM SP GROUP BY P#

Contenido de la vista V3:

124
P# SUMACTD
P1 600
P2 1.000
P3 400
P4 500
P5 500
P6 100

Es obvio que no se puede realizar INSERT ni UPDATE, si se va a cambiar el campo


SUMACTD ya que dicho campo no existe en la tabla original. Las operaciones DELETE y
UPDATE sobre el campo P# podrían definirse en teoría, pero sería mejor realizarlas
directamente sobre la tabla SP, ya que pueden implicar a varias filas.

Ejemplo 4. Sea una vista que contiene los datos de las piezas de color rojo:

CREATE VIEW PIEZASROJAS


AS SELECT P#,NOMP,PESO,COLOR
FROM P
WHERE COLOR='ROJO'

Cuya extensión sería:

P# NOMP PESO COLOR


P1 Tuerca 12 Rojo
P4 Tornillo 14 Rojo
P6 Leva 19 Rojo

Esta vista satisface las restricciones, y es por tanto actualizable. Sin embargo vamos a comentar
tres situaciones adicionales que deben considerarse:

1. Una operación INSERT contra PIEZASROJAS supondrá generar un valor nulo


para CIUDAD en la tabla P (por tanto no deberá definirse con la opción NOT
NULL).

2. Según la vista, el usuario debería poder crear una nueva fila con un valor de
P#=P3. Este valor no es duplicado en lo que concierne a la vista, pero si lo es
respecto a la tabla de base y por tanto se debe rechazar.

3. Considérese la UPDATE:

UPDATE PIEZASROJAS SET COLOR='AZUL' WHERE P#='P1'

¿Puede aceptarse?. En caso de aceptarse tendrá el efecto de eliminar la pieza P1


de la vista dado que ya no satisface la definición.(En el sistema R se aceptan estas
actualizaciones y los registros si desaparecen, pero en cada sistema pueden
definirse este tipo de situaciones de forma distinta.)

125
NOTA: Hay algunos sistemas que no manejan correctamente la actualización de vistas y
permiten actualizar vistas que son subconjuntos de filas y columnas.

5.7.3. VISTAS E INDEPENDENCIA DE DATOS

Se dice que un sistema proporciona independencia lógica de los datos si los usuarios y sus
programas son independientes de la estructura lógica de la base de datos. Se va a considerar la
contribución de las vistas a la independencia de datos. En el esquema conceptual (estructura
lógica) pueden darse dos tipos de cambios:

- Crecimiento: añadir información a la BD.


- Reestructuración: cambiar la estructura del esquema conceptual.

- Crecimiento

A medida que se añade nuevos tipos de información a la BD, también el esquema conceptual
debe crecer en consecuencia. Hay dos tipos posibles de crecimiento que se pueden dar en el
esquema conceptual:

1. La expansión de una tabla existente para incluir una columna nueva (correspondiente a la
adición de nueva información, relativa a un tipo de entidad existente).
2. La inclusión de una tabla de base nueva, (correspondiente a la adición de un nuevo tipo de
entidad).

Sin embargo, ninguno de estos cambios debe tener efecto alguno sobre las vistas existentes, y por
definición esas vistas no pueden contener ninguna referencia a los campos o tablas nuevas. De
esta manera, el mecanismo de las vistas puede aislar a los usuarios de los efectos del crecimiento
de la BD. A esto se le denomina "inmunidad al crecimiento".

- Reestructuración

En ocasiones se hace necesario reestructurar el esquema conceptual de manera que, aunque el


contenido total de la información siga siendo el mismo, la colocación de la información dentro
del esquema cambia, es decir, se modifica la distribución de los campos en las tablas; tal
reestructuración a menudo es complicada, pero algunas veces es deseable.

Una clase importante de reestructuración, es el reemplazo de una tabla específica por dos de sus
proyecciones, de manera que la tabla original se puede recuperar tomando una join de esas
proyecciones; por ejemplo, la tabla de proveedores S, se puede reemplazar por las dos tablas
siguientes (por ejemplo, para simplificar el control de autorización):

SX (S#,NOMS,CIUDAD)
SY (S#,ESTADO)

La tabla original es la join natural de SX y SY sobre S# y puede definirse mediante una vista tal
como:

126
CREATE VIEW S (S#, NOMS, ESTADO, CIUDAD)
AS SELECT SX.S#, NOMS, ESTADO, CIUDAD
FROM SX, SY
WHERE SX.S# = SY.S#

El cambio no tendrá ningún efecto sobre la respuesta a los usuarios, en lo que respecta a la
recuperación. Cualquier referencia anterior a la tabla S, hará referencia ahora a la vista S.

5.7.4. VENTAJAS DE LAS VISTAS

Para finalizar, resumimos las ventajas de las vistas relacionales:


• Ofrecen un cierto grado de independencia lógica de los datos en casos de reestructuración de
la base de datos.
• Permiten a diferentes usuarios ver los mismos datos de distintas maneras.
• Se simplifica la percepción del usuario. Las vistas pueden utilizarse para definir y almacenar
en la BD consultas complejas que son utilizadas frecuentemente; de esta forma, se evita al
usuario enfrentarse a la complejidad de la consulta.
• Se cuenta con seguridad automática para datos ocultos, es decir, para los no visibles a través
de una determinada vista. Las vistas pueden utilizarse para aplicar políticas de seguridad
(privacidad) de los datos, es decir, para ocultar dichos datos a los usuarios de la BD.

127
5.8. S.Q.L. INMERSO

SQL también puede usarse junto con un lenguaje de programación de aplicación general
como C, ADA, PASCAL, COBOL o PL/I. El lenguaje de programación se denomina
lenguaje anfitrión. Cualquier instrucción de SQL - de definición de datos, consulta,
actualización o definición de vistas - se puede incorporar en un programa escrito en el
lenguaje anfitrión. La instrucción de SQL inmerso se distingue de las instrucciones del
lenguaje anfitrión anteponiéndole un carácter o una orden especial como prefijo para que el
precompilador pueda separar las instrucciones de SQL inmerso y el código del lenguaje
anfitrión. En SQL, las palabras reservadas EXEC SQL o la secuencia &SQL preceden a toda
sentencia de SQL inmerso, y dichas instrucciones pueden terminar con END-EXEC o con un
“;”.

En general, los diferentes sistemas siguen distintas convenciones a la hora de trabajar con
instrucciones de SQL inmerso. Con el fin de ilustrar los conceptos de SQL inmerso,
adoptaremos como lenguaje anfitrión el PASCAL y definiremos nuestra propia sintaxis.
Usaremos un signo “$” para identificar las instrucciones de SQL en el programa y “;” será el
carácter terminador. Dentro de una orden de SQL inmerso podemos hacer referencia a
variables del programa (variables host) , a las que antepondremos un signo “:”. Esto
permitirá que las variables del programa y los objetos del esquema de base de datos (los
atributos y las relaciones) tengan los mismos nombres sin que haya ambigüedad.

Supongamos que queremos escribir programas en PASCAL para procesar una BD que
incluye las siguientes tablas:

EMPLEADO
NOME APEL NSS FECHANT DIR SEXO SALARIO ND

DEPARTAMENTO
NOMD NUMD NSSJEF FªINIJEF

Necesitaremos declarar variables de programa con los mismos tipos que los atributos de la
BD que el programa va a procesar. Estas variables pueden o no tener nombres que sean
idénticos a los de sus atributos correspondientes. Usaremos las siguientes variables de
programa PASCAL y mostraremos los segmentos de programas sin declaraciones de
variables.

var NOMD: packed array[1...15] of char;


NUMD, AUMENTO: integer
E: record NOME, APEL: packed array [1...15] of char;
SEXO: char;
NSS, FECHANT: packed array [1...9] of char;
DIR: packed array [1...30] of char;
SALARIO, ND: integer
end;

Como primer ejemplo, escribiremos un segmento de programa repetitivo (ciclo) para leer un
NSS e imprimir cierta información de la tupla EMPLEADO correspondiente al mismo. El

128
código del programa se muestra en E1, en donde suponemos que en otro lugar se han
declarado las variables de programa apropiadas NUM_SEG_SOC y CICLO.

El programa lee un NSS mediante la orden de SQL inmerso. Las órdenes de obtención de
datos de SQL inmerso requieren una cláusula INTO (en) para especificar las variables de
programa en las que se colocarán los valores de atributo obtenidos de la base de datos. Las
variables de programa en PASCAL de la cláusula INTO llevan el prefijo “:”. He aquí el
segmento de programa E1:

E1: CICLO:=‘S’;
while CICLO=‘S’ do
begin
writeln (‘introduzca un número de seguridad social:’);
readln (NUM_SEG_SOC)
$SELECT NOME, APEL, DIR, SALARIO
INTO :E.NOME, :E.APEL, :E.DIR, :E.SALARIO
FROM EMPLEADO
WHERE NSS=:NUM_SEG_SOC;
writeln(E.NOME, E.APEL, E.DIR, E.SALARIO);
writeln(‘¿más números de seguridad social (S o N)?’);
readln(CICLO)
end;

En E1, la consulta de SQL inmerso selecciona una sola tupla; por eso podemos asignar
directamente los valores de sus atributos a variables del programa.

En general, una consulta de SQL puede obtener muchas tuplas, en cuyo caso el programa
PASCAL por lo regular examinará todas las tuplas obtenidas y las procesará una por una. Se
utiliza el concepto de cursor para que el programa escrito en el lenguaje anfitrión pueda
procesar las tuplas una por una.

Podemos concebir un cursor como un apuntador que apunta a una sola tupla (fila) del
resultado de una consulta. El cursor se declara cuando se declara la orden de consulta de SQL
en el programa. Más adelante, una orden OPEN (abrir) cursor obtiene de la base de datos el
resultado de la consulta y ajusta el cursor a una posición antes de la primera fila del
resultado de la consulta. Esta se convierte en la fila actual para el cursor. Posteriormente, se
emiten órdenes FETCH (traer) en el programa, y cada una avanza el cursor a la siguiente fila
del resultado de la consulta, convirtiéndola en la fila actual y copiando los valores de sus
atributos en las variables de programa de PASCAL especificadas en la orden FETCH. Esto es
similar al procedimiento de ficheros tradicional de registro por registro.

Para determinar si ya se procesaron todas las tuplas del resultado de la consulta se utiliza una
variable implícita, llamada SQLCODE, para comunicar al programa la situación de las
órdenes de SQL inmerso. Cuando se ejecuta con éxito una orden de SQL, se devuelve un
código de 0 en el SQLCODE; se devuelven códigos diferentes para indicar excepciones y
errores. Si se emite una orden FETCH que desplaza el cursor más allá de la última tupla del
resultado de la consulta, se devuelve un código especial END_OF_CURSOR. El
programador utiliza esto para terminar un ciclo de procesamiento con las tuplas del resultado
de la consulta. En general, es posible tener abiertos muchos cursores al mismo tiempo. Para

129
indicar que ya no vamos a utilizar el resultado de una consulta, se emite uan orden CLOSE
(cerrar) cursor.

En E2 se muestra un ejemplo del empleo de cursores, y en él se declara explícitamente el


cursor EMP. Suponemos que ya se declararon las variables de programa de PASCAL
apropiadas. El segmento de programa E2 lee un nombre de departamento y exhibe los
nombres de los empleados que trabajan en ese departamento, uno por uno. El programa lee
un importe de aumento para el salario de cada empleado y actualiza este último en esa
cantidad:

E2:
writeln(‘introduzca el nombre del departamento:’); readln (NOMD);
$SELECT NUMD INTO :NUMD
FROM DEPARTAMENTO
WHERE NOMD=:NOMD;
$DECLARE EMP CURSOR FOR
SELECT NSS, NOME, APEL, SALARIO
FROM EMPLEADO
WHERE ND=:NUMD
FOR UPDATE OF SALARIO;
$OPEN EMP;
$FETCH EMP INTO :E.NSS, :E.NOME, :E.APEL, :E.SALARIO;
while SQLCODE=0 do
begin
writeln(‘nombre del empleado:’, E.NOME, E.APEL);
writeln(‘introduzca aumento:’); readln(AUMENTO);
$UPDATE EMPLEADO SET SALARIO = SALARIO + :AUMENTO
WHERE CURRENT OF EMP;
$FETCH EMP INTO :E.NSS, :E.NOME, :E.APEL, :E.SALARIO;
end;
$CLOSE CURSOR EMP;

Cuando se define un cursor para filas que se van a modificar, hay que añadir la cláusula FOR
UPDATE OF (para modificación de) en la declaración del cursor y listar los nombres de
todos los atributos que el programa vaya a modificar. Si se van a eliminar filas, hay que
añadir las palabras FOR DELETE.

En la orden UPDATE (o DELETE) inmersa, la condición WHERE CURRENT OF (donde


actual de) cursor especifica que la tupla actual es la que se modificará (o eliminará)

130
5.9. NIVEL INTERNO

5.9.1. Organización de los datos en un SGBD Relacional


El nivel interno de la arquitectura de un SGBD se refiere a la organización física de los datos
almacenados que permita un acceso y manipulación eficiente de los mismos.

Aunque la mayoría de los SGBD relacionales comerciales sigan una filosofía parecida, cada
uno de ellos tiene unas características propias. En este caso, se va a considerar la
organización interna de los datos según el sistema Oracle, ya que es uno de los más
completos y más utilizados en el mercado.

5.9.2. Estructura de una base de datos Oracle


Oracle organiza la información de manera que aquellos datos que se van a recuperar de forma
conjunta (por ejemplo, las filas de una tabla) se encuentren físicamente cerca, es decir, en el
mismo bloque o en bloques contiguos del disco. De esta forma se ahorrarán accesos a disco y
mejorará el rendimiento.

En la figura 5.9 se muestra la estructura de una BD Oracle, que se puede dividir en estructura
física y lógica.

Base de datos

Tablespace Fichero Datos

Lógico Segmento Físico

Extensión

Bloque
Bloque E/S
Oracle

Figura 5.9. Estructura de una BD Oracle

A continuación se definen cada uno de los conceptos anteriores y la relación que hay entre ellos.

131
5.9.2.1. Tablespaces

Una bd Oracle puede ser dividida en áreas lógicas más pequeñas de almacenamiento conocidas
como tablespaces. Cada tablespace sólo puede pertenecer a una bd y consta de uno o más
ficheros del sistema operativo (ficheros físicos). A nivel lógico un tablespace contiene los
segmentos de la BD. El tablespace original se denomina SYSTEM y se forma cuando se crea la
BD. Este tablespace contiene como mínimo todas las tablas del diccionario de datos. Se
recomienda crear al menos un tablespace adicional para almacenar los datos de los usuarios y no
mezclar información de distinta naturaleza.

Dado que los tablespaces contienen datos de diferentes objetos, éstos se dividen en unidades
lógicas de almacenamiento de menor tamaño denominadas segmentos, con el fin de separarlos
convenientemente y facilitar así su recuperación.

Los tablespaces controlan la asignación del espacio a los objetos de las aplicaciones (segmentos
de tipo tablas o índice) y del sistema (segmentos de rollback y temporales), asignan cuotas de
espacio a los usuarios, también controlan la disponibilidad de los datos, ya que pueden ser
puestos on line y offline, y distribuyen el almacenamiento de datos entre los dispositivos para
mejorar el rendimiento de E/S.

5.9.2.2. Ficheros de Datos

Los ficheros son las unidades físicas de almacenamiento y contienen datos. Un fichero pertenece
a un único tablespace. El servidor Oracle crea al menos un fichero de datos (datafile) para un
tablespace dándole la cantidad de espacio especificada más una pequeña cabecera. El
rendimiento de la BD mejora si cada fichero está formado por espacio contiguo en disco.

En el caso de que se necesite ampliar el tamaño de un tablespace, el administrador de la base de


datos puede cambiar el tamaño de un fichero de datos después de su creación, puede especificar
que un fichero de datos crezca dinámicamente como lo hacen los objetos en el tablespace, o
puede añadir más ficheros de datos al tablespace.

5.9.2.3. Segmentos

Un segmento es un espacio reservado para un tipo específico de estructura de almacenamiento


lógico dentro de un tablespace. Todo lo que se escribe en una BD son segmentos que pueden ser
de tipo tabla, índice, temporal o de rollback. Los segmentos ayudan a clasificar y ordenar la
información contenida en un tablespace y permiten optimizar tanto su almacenamiento como su
posterior localización.

El segmento temporal lo crea Oracle para almacenar datos temporales cuando se realiza un order
by, una unión de dos tablas, cuando creamos un índice, etc.

El segmento de rollback da consistencia en lectura, ya que permite que hasta que no se realice la
commit ningún usuario vea los cambios. Los usuarios ven el valor que está en el segmento de
rollback. Este tipo de segmentos también dan la posibilidad de deshacer los cambios (con la

132
sentencia rollback) y también ayudan a la recuperación de la BD en un arraque forzoso ya que
primero se produce el volcado de los redologs (para lo que estaba confirmado) y después vuelca
la imagen anterior que está en los segmentos de rollback (lo no confirmado).

El único segmento que conserva su nombre es el segmento de rollback, al resto nos referimos
como tablas, índices,... y realmente todo son segmentos.

5.9.2.4. Extensiones

Una extensión es un grupo de bloques contiguos. Cada tipo de segmento está compuesto de una
o más extensiones. Una vez que la primera extensión está completa, el sistema irá reservando
tantas como vaya necesitando para almacenar el contenido del objeto en cuestión. Las
extensiones pertenecientes a un mismo segmento se van “enganchando” entre sí mediante
apuntadores, por lo que un segmento puede verse como una lista enlazada de extensiones.

5.9.2.5. Bloques de datos

El bloque es la unidad lógica de almacenamiento más pequeña y, por tanto, el nivel más bajo al
que el SGBD puede administrar sus datos. Debe dimensionarse con un tamaño múltiplo del
tamaño del bloque del S.O. para optimizar las operaciones de lectura/escritura en disco.

133
TEMA VI

S.G.B.D. RELACIONALES COMERCIALES

6.1. INGRES
INGRES es un sistema de gestión de bases de datos relacional que surgió como prototipo en
la Universidad de Berkley (California) a partir del modelo de datos definido por el Dr. E. F.
Codd en 1970. El producto comenzó a comercializarse a partir de 1980.

Comprende una serie de módulos o herramientas de trabajo, tanto para el usuario final como
para desarrollo. Estas herramientas incluyen los lenguajes de consulta SQL y QUEL

Actualmente INGRES está disponible en una amplia gama de plataformas hardware/software.

6.2. ORACLE
Oracle es un sistema de gestión de base de datos relacional fabricado por Oracle corporation.

ORACLE CORPORATION se funda en el año 1977 con el objetivo de implementar una base de
datos relacional basada en las especificaciones del ''SYSTEM R" desarrolladas por IBM San Jose
Research, aparecidas en el año 1976.

Tras dos años de trabajo se presenta en el año 1979, el primer SGBD relacional del mercado,
ORACLE VERSION 1, anterior inclusive al SGBDR, SQL/DS, presentado por IBM (1981).

Versiones posteriores, amplían y potencian las capacidades ofertadas por el SGBD ORACLE,
atendiendo en todo momento a las tendencias y necesidades urgentes en el mercado del
Tratamiento de la Información. Paralelamente aparecen herramientas de análisis, desarrollo y
usuario final, potentes y sofisticadas, que recubriendo al gestor de forma modular
proporcionan en conjunto una Solución ORACLE total e integradora para todo requerimiento
de un Sistema de Información.

Se considera a Oracle como uno de los sistemas de bases de datos más completos, destacando
su soporte de transacciones, estabilidad, escalabilidad y que es multiplataforma.

Aunque su dominio en el mercado de servidores empresariales ha sido casi total hasta hace
poco, recientemente sufre la competencia del Microsoft SQL Server de Microsoft y de la
oferta de otros SGBD con licencia libre como PostgreSQL, MySql o Firebird. Las últimas
versiones de Oracle han sido certificadas para poder trabajar bajo Linux.

6.3. PROGRESS
PROGRESS es un producto de P.S.C. (Bedford, Massachusetts). La primera versión de
PROGRESS se difundió a partir de 1984 en Estados Unidos.

134
PROGRESS constituye una herramienta de desarrollo de aplicaciones transaccionales de alto
rendimiento, integrada por un potente lenguaje de 4ª generación, un gestor de bases de datos
relacionales (multivolumen y distribuidas), un diccionario de datos (metaesquema), herramientas
de productividad (FAST-TRACK, RESULTS, REPORT WRITER), y módulos para portar
aplicaciones entre diferentes sistemas operativos y redes (Developer's Toolkit). PROGRESS se
encuentra disponible para la mayoría de entornos hardware y redes locales. Utiliza arquitectura
cliente/servidor y dispone de versión run-time para todos los entornos así como interface de
desarrollo con ORACLE y RDB o RMS de DEC y con otras bases de datos del mercado.

6.4. IBM DB2


Uno de los sistemas de bases de datos más reconocidos es DB2, que celebra durante este mes
de junio sus bodas de plata. La primera base de datos relacionales de IBM fue desarrollada
hace 25 años por un equipo de investigadores que trataba de crear una nueva arquitectura
para almacenar, gestionar e interactuar con datos digitales y liberar a los desarrolladores de
aplicaciones de la necesidad de saber cómo gestionar los datos. Un cuarto de siglo después,
DB2 se ha transformado en un producto muy útil y potente, en el que confían empresas de
todos los tamaños y sectores y que sigue siendo un catalizador de negocio para IBM. El
equipo de investigación de DB2 no sólo desarrolló los elementos matemáticos y científicos
que hacen posibles las bases de datos relacionales, sino que además hizo posible el
nacimiento de una categoría de software totalmente nueva. DB2 y el concepto de bases de
datos relacionales se convirtieron en la opción de almacenamiento de información preferida
por el mercado y continúa dando soporte a la economía mundial gestionando registros
financieros, información logística o datos de recursos humanos. Actualmente las soluciones
de software DB2 forman parte del núcleo de las aplicaciones empresariales de los 25 mayores
bancos del mundo, nueve de las diez mayores empresas de seguros de vida/salud del mundo y
23 de las 25 mayores cadenas de grandes almacenes de Estados Unidos.

Desde 1970, IBM ha desarrollado una amplia oferta de sistemas de gestión de bases de datos
relacionales en torno a la marca DB2, que juega un papel fundamental como servidor de
datos y durante todos estos años ha evolucionado para convertirse en un servidor “híbrido”
que gestiona tanto datos relacionales tradicionales como XML. Por otra parte, conviene
recordar las principales innovaciones tecnológicas que condujeron al nacimiento de DB2,
como el lenguaje SQL, la tecnología de optimización de consultas (Query Optimization) y los
algoritmos Aries de coincidencia simultánea permitieron a DB2 gestionar al mismo tiempo a
miles de usuarios y transacciones sin que se produjeran interferencias.

6.5. INFORMIX
Informix es una familia de productos RDBMS de IBM, adquirida en 2001 a una compañía
(también llamada Informix o Informix Software) cuyos orígenes se remontan a 1980.

El DBMS Informix fue concebido y diseñado por Roger Sippl a finales de los años 1970. La
compañía Informix fue fundada en 1980, salió a bolsa en 1986 y durante parte de los años
1990 fue el segundo sistema de bases de datos más popular después de Oracle. Sin embargo,
su éxito no duró mucho y para el año 2000 una serie de tropiezos en su gestión había
debilitado seriamente a la compañía desde el punto de vista financiero.

135
En 2001 IBM, impulsada por una sugerencia de Wal-Mart (el mayor cliente de Informix)
compró Informix. IBM tenía planes a largo plazo tanto para Informix como para DB2,
compartiendo ambas bases de datos tecnología de la otra. A principios de 2005, IBM lanzó la
versión 10 del Informix Dynamic Server (IDS).

6.6. SYBASE
La compañía SYBASE fue fundada en 1984 para tratar de cumplir los requisitos de las
empresas con aplicaciones ''on-line'' críticas a las que se califica como ''On-Line enterprises".
El termino ''On-line enterprises'' indica que la organización pretende integrar sistemas, redes,
bases de datos, recursos de información y aplicaciones heterogéneas.

El SGBDR SYSBASE, basado en una avanzada arquitectura Cliente/Servidor está en


condiciones de proporcionar el rendimiento y conectividad necesarios para las aplicaciones
on-line en tiempo real.

Con una base global y leal de clientes y una fuerte presencia en mercados verticales clave,
como servicios financieros, telecomunicaciones, salud y gobierno, Sybase ha permitido
materializar, a clientes de todos los tamaños, la “Empresa Desconectada”, en donde la
información fluye libremente y de manera segura dentro de una organización, así los
empleados lleven a cabo sus negocios dentro de la oficina, o fuera de ella.

Dentro de sus productos para la gestión de bases de destacan:


• Adaptive Server Enterprise (ASE), un motor de base de datos empresarial de alto
rendimiento y escalabilidad que permite:

o Almacenar datos de manera segura

o Tener acceso y procesar datos de manera inteligente

o Movilizar datos

• Adaptive Server Anywhere, una base de datos para computación móvil y departamental

• Sybase IQ, una base de datos para Inteligencia Empresarial y Almacenes de Datos

6.7. Microsoft SQLServer


Microsoft SQL Server es un sistema de gestión de bases de datos relacionales (SGBD)
basado en el lenguaje Transact-SQL, y específicamente en Sybase IQ, capaz de poner a
disposición de muchos usuarios grandes cantidades de datos de manera simultánea. Microsoft
SQL Server constituye la alternativa de Microsoft a otros potentes sistemas gestores de bases
de datos como son Oracle, Sybase ASE, PostgreSQL o MySQL.

Características:
• Soporte de transacciones.

• Escalabilidad, estabilidad y seguridad.

136
• Soporta procedimientos almacenados.

• Incluye también un potente entorno gráfico de administración, que permite el uso de


comandos DDL y DML gráficamente.

• Permite trabajar en modo cliente-servidor, donde la información y datos se alojan en


el servidor y las terminales o clientes de la red sólo acceden a la información.

• Además permite administrar información de otros servidores de datos.

6.8. MySQL
MySQL es la base de datos relacional de código libre más usada en el mundo. Su origen se
debió a la búsqueda por parte de los fundadores de crear un gestor de bases de datos que
fuera "rápido". Así surgió MySQL, primero como un producto de la empresa y después como
software de dominio público. El servidor MySQL fue desarrollado originalmente para
manejar grandes bases de datos mucho más rápido que las soluciones existentes y ha estado
siendo usado exitosamente en ambientes de producción sumamente exigentes por varios
años. Aunque se encuentra en desarrollo constante, el servidor MySQL ofrece hoy un
conjunto rico y útil de funciones. Su conectividad, velocidad, y seguridad hacen de MySQL
un servidor bastante apropiado para acceder a bases de datos en Internet.

La versión gratuita es el referente para personas y empresas que crean páginas web. En la
parte empresarial ofrece versiones con capacidades similares a las de costosas marcas como
IBM, Informix, Oracle y Microsoft. Hewlett-Packard ofrece soporte y garantía para esta base
de datos instalada en sus servidores Proliant. La versión Max DB es certificada para sistemas
SAP.

6.9 Postgresql
PostgreSQL es un servidor de base de datos relacional orientada a objetos de software libre,
liberado bajo la licencia BSD. Como muchos otros proyectos open source, el desarrollo de
PostgreSQL no es manejado por una sola compañía sino que es dirigido por una comunidad
de desarrolladores y organizaciones comerciales las cuales trabajan en su desarrollo. Dicha
comunidad es denominada el PGDG (PostgreSQL Global Development Group).

PostgreSQL se diseñó como una base de datos orientada a objetos, es decir, una ORDBMS.
Esto significa, que las tablas no son tablas, sino objetos, y las tuplas son instancias de ese
objeto. Permite crear nuevos tipos de datos y hacer herencias entre objetos. PostgreSQL
tiene transacciones, integridad referencial, vistas, y multitud de funcionalidades, pero es
lento y pesado.

137
PRODUCTO Distribución Comentarios
total del
mercado (2004)

Oracle 9i,10G 30,9% Domina el ambiente Unix; también con gran


rendimiento en el mercado Windows

IBM DB2, Informix 31,3% Domina los ambientes MVS y AS/400; adquirió
Informix en 2001; 25% de la distribución del
mercado de los ambientes UNIX

Microsoft SQL Server 12,1% Domina el Mercado Windows; no tiene


presencia en otros ambientes

Otros: Sybase, NCR 16,7%


Terradata, Progress
Software, MySQL,
PostgreSQL, Ingres,
etc.

Figura 6.1. Distribución del mercado de acuerdo con un estudio de la Sociedad Internacional de Datos
de 2004

138
TEMA VII

RECUPERACIÓN Y OPTIMIZACIÓN DE UNA BASE DE DATOS

7.1. RECUPERACION DE LA B.D.

7.1.1. CAUSAS DEL DETERIORO DE LA BASE DE DATOS

Una B.D. creada y mantenida correctamente puede llegar a ser incorrecta o no utilizable por
distintos motivos:

• Catástrofes: incendios, inundaciones, explosiones, etc.


• Interrupción en los procesos de actualización, debidas a fallos en el hardware, S.O., S.G.B.D.,
programas de aplicación, etc.
• Actualizaciones indebidas a causa de errores en programas, utilización incorrecta de datos de
entrada o restricciones mal hechas.

En algunos casos es fácil detectar la necesidad de una resconstrucción, por ejemplo en el caso de
catástrofes o bien en los procesos de actualización a través de los mensajes que emite el
S.G.B.D. o el monitor de T.P. En otros casos, como en las actualizaciones indebidas puede pasar
mucho tiempo hasta que se detecte el error.

La recuperación de fallos en las transacciones casi siempre equivale a una restauración de la base
de datos a algún estado anterior de modo que sea posible reconstruir un estado correcto -
cercano al momento del fallo - a partir de tal estado anterior. Para lograr esto, el sistema debe
conservar, fuera de la base de datos, información sobre las modificaciones hechas a los
elementos de información al ejecutarse las transacciones.

7.1.2. CLASES DE RECUPERACIÓN

Las clases de recuperación pueden ser de dos tipos:

1. Recuperación parcial: cuando sólo ha habido pérdidas en la memoria principal.


2. Recuperación total: cuando se ha perdido información en las memorias secundarias.

Los instrumentos básicos de que se dispone para llevarlas a cabo son:

• El fichero dietario o LOG.

139
• Los volcados de la B.D. o DUMP.
• La toma de puntos de control o CHECKPOINTS.

a) El Fichero LOG (diario o dietario)

Puede definirse como un fichero que recoge todos los cambios que se han producido en la B.D.
a lo largo de uno o varios procesos, más ciertas informaciones útiles para las restauraciones.

La información de los cambios puede describir dichos cambios:

• En forma lógica; por ejemplo, 'se ha añadido el registro X', 'se ha modificado el valor de
PV a 200', etc.
• En forma física, recogiendo el estado antes y el estado después del cambio de cada uno
de los registros o páginas afectadas.

Además, el fichero LOG puede contener también registros que indiquen el comienzo o fin de las
distintas transacciones (o la confirmación de las actualizaciones hechas por ellas) o los
mensajes de teleproceso de E/S.

Todos los registros deben llevar el indentificativo de la transacción y en muchos casos también
la fecha y hora en que se grabaron.

Identificador de transacción

Fecha/hora de modificación

Fichero modificado

Dirección de página modificada

Valor antes de la modificación

Valor después de la modificación

Figura 7.1. Ejemplo de registro de un fichero Log.

b) Los volcados de la B.D. (DUMP)

Un volcado de la B.D. es una copia, generalmente en cinta, de la B.D., tal como estaba en un
momento dado en el cual todas las actualizaciones estaban confirmadas.

140
Recuperación y Optimización de una Base de Datos

En caso de que se produzca un fallo, se vuelve a crear la base de datos a partir de la copia más
reciente disponible. Sin embargo, los volcados llevan tiempo y no pueden realizarse muy
frecuentemente.

c) Los Puntos de Control (Checkpoints)

Si una misma página es actualizada con mucha frecuencia por sucesivas transacciones, es
probable (si el algoritmo es LRU) que esté mucho tiempo en memoria sin ser regrabada en la
B.D.; en tal caso, la reconstrucción de ésta podría obligar regrabar muchas imágenes después de
los gránulos de dicha páginas.

El establecimiento de un punto de control consiste en las siguientes acciones:

1. Suspender temporalmente la ejecución de las transacciones


2. Forzar la escritura de todas las operaciones de actualización pertenecientes a transacciones
confirmadas del almacenamiento intermedio al disco.
3. Escribir un registro indicativo del punto de control en el fichero LOG.
4. Reanudar la ejecución de transacciones

Se graba en el fichero LOG un registro que marca el punto de control y en un pequeño fichero
aparte, el identificativo del último punto de control tomado. Así, en el caso de fallo, sólo habría
que realizar la reconstrucción desde el último punto de control.

Los puntos de control se toman periódicamente, con una periodicidad expresada en tiempo o en
número de actualizaciones hechas.

Reconstrucción Total

Se da cuando la pérdida de información ha afectado a la base de datos física. Se debe reconstruir


el contenido de toda la B.D., de algunos ficheros o de algunas páginas completamente.

Básicamente, consiste en grabar toda la B.D. a partir del último volcado y volver a hacer todas
las actualizaciones confirmadas posteriores al instante al que corresponde el volcado
(REHACER). Esto último se puede conseguir de dos maneras:

1. Ejecutando todas las transacciones pertinentes, tomando los mensajes del fichero de
entrada o del fichero LOG.
2. Regrabando las imágenes 'después' necesarias, que generalmente se tomaran del
fichero LOG.

141
Reconstrucción Parcial

Cuando la base de datos no presenta daños físicos pero se ha vuelto inconsistente debido a
fallos no catastróficos, la estrategia consiste en invertir los cambios que provocaron la
inconsistencia, deshaciendo algunas operaciones. También puede ser necesario rehacer
algunas operaciones a fin de restaurar un estado consistente de la base de datos. En este caso
no necesitamos una copia completa de la base de datos; durante la recuperación sólo se
consultan las entradas asentadas en el fichero LOG.

Podemos distinguir dos técnicas principales para recuperarse de fallos no catastróficos en las
transacciones.

Las técnicas de actualización diferida no actualizan en realidad la base de datos sino hasta
después de que una transacción llega a su punto de confirmación; en ese momento, las
actualizaciones se graban en la base de datos. Antes de ser confirmadas, todas las
actualizaciones se asientan en el espacio de trabajo local de la transacción. Durante la
confirmación, las actualizaciones se graban primero definitivamente en el fichero LOG y
luego se escriben en la base de datos. Si una transacción falla antes de llegar a su punto de
confirmación, no habrá modificado en absoluto la base de datos, por lo que no es preciso
DESHACER. Puede ser necesario REHACER a partir del fichero LOG, el efecto de las
operaciones de una transacción confirmada, ya que es posible que su efecto todavía no se
haya registrado en la base de datos.

En las técnicas de actualización inmediata, es posible que algunas operaciones de una


transacción actualicen la base de datos antes de que la transacción llegue a su punto de
confirmación. Sin embargo, estas operaciones casi siempre se asientan en el fichero LOG en
disco mediante escritura forzada antes de aplicarse a la base de datos, lo que hace posible la
recuperación. Si una transacción falla después de asentar algunos cambios en la base de datos
pero antes de llegar a su punto de confirmación, será preciso anular el efecto de sus
operaciones sobre la base de datos; es decir, la transacción deberá revertirse. En el caso de la
actualización inmediata, es preciso deshacer y rehacer durante la recuperación.

7.2. MODIFICACION Y OPTIMIZACION

Una vez construida la B.D. es muy difícil modificarla, excepto con la generación de nueva BD,
pero normalmente se necesitan modificaciones periódicas para:

1. Ajustarla con el fin de mejorar el rendimiento cuando cambia el uso de los datos.
2. Añadir nuevos sistemas a medida que se requieren.
3. Alterar el esquema conceptual cuando cambia la forma de ver los datos por parte de la
empresa.

Así pues, se necesitan facilidades para modificar una B.D. con el mínimo de inconvenientes.
Para ello pueden observarse varios aspectos:

142
Recuperación y Optimización de una Base de Datos

- Seguimiento del rendimiento.


- Reorganización de la B.D.
- Reestructuración de la B.D.

7.2.1. SEGUIMIENTO DEL RENDIMIENTO

Consiste en la recogida de estadísticas sobre el rendimiento de la B.D. y su análisis, con el


objeto de optimizarlo. Estas estadísticas pueden ser estáticas o dinámicas.

- Estadísticas Estáticas: Se refieren al estado general de la B.D. y pueden recogerse mediante


un programa de seguimiento cuando la B.D. está inactiva (por ejemplo, número de registros de
cada tipo, distribución de los registros sobre el espacio de almacenamiento, utilización del área
de desbordamientos para datos e índices, etc.)

- Estadísticas Dinámicas: Se refieren a las características en tiempo de ejecución y pueden


recogerse sólo cuando la B.D. esté actuando de un modo normal u otro deseado (frecuencia de
acceso y actualización de los datos, uso de cada tipo de comando de DM y tiempo de respuesta,
acceso a índices y desbordamiento, uso de claves y tipo de acceso, etc.)

7.2.2. REORGANIZACIÓN DE LA BASE DE DATOS

La reorganización de la B.D. se refiere a realizar cambios en el almacenamiento físico. Esto se


intentará, en teoría, después de que se recojan y analicen las estadísticas de uso, aunque en la
práctica podría basarse en una evaluación intuitiva.

La complejidad de la reorganización dependerá del número de cambios a realizar.

Teóricamente, una B.D. debería ser autorreorganizable, cambiando dinámicamente el esquema


de almacenamiento y los datos almacenados a medida que cambia el uso, y dando siempre el
rendimiento óptimo. En general, esto implicará un rediseño automático de un esquema de
almacenamiento, seguido de una conversión automática de la antigua B.D. en una nueva.

7.2.3. REESTRUCTURACIÓN DE LA BASE DE DATOS

La reestructuración de la B.D. se refiere a la realización de cambios a nivel lógico. Una


reestructuración de un esquema conceptual implica cambios en su contenido tales como:

• Inserción/Borrado de datos elementales.


• Inserción/Borrado de tipos de registro.
• División/Recombinación de tipos de registro.
• Inserción/Borrado/Modificación de asociaciones.

143
Un esquema conceptual reestructurado normalmente irá seguido por la reorganización de la
B.D., lo que implica un nuevo esquema de almacenamiento.

144
EJERCICIOS

EJERCICIO 1

El siguiente diagrama Entidad-Relación para una base de datos que mantiene la información sobre una
empresa que se dedica a la venta de piezas. La empresa recibe pedidos de los clientes y gestiona el
suministro de las piezas desde los almacenes. Cada pedido lo realiza un cliente sobre una pieza
específica y la empresa se seleccionará el almacén que realizará el suministro.
Además, cada pieza puede estar compuesta de otras piezas más sencillas, y una pieza sencilla
puede ser componente de otras piezas más complejas.

Se pide obtener un diseño relacional equivalente al modelo presentado.

id a no

CIUDAD id a no direc tl

stock
UBICACIÓN ALMACEN EXISTENCIAS
id.clte

nombr id p
CLIENTES PEDIDOS PIEZA
nom
dir
pieza

tlfn fech Nºped Cant. COMPOSICIÓ

can

145
EJERCICIO 2

Una empresa fabricante de juguetes desea crear una base de datos para gestionar toda la
información referente a los juguetes que fabrica y que luego suministra a jugueterías
distribuidas por todo el país, y para llevar el control de los pedidos servidos a lo largo del
año.
La empresa fabrica juguetes que pueden ser de varias clases (de construcción, de mesa, de
locomoción, deportivos, etc.). Cada juguete puede tener varios componentes, también
fabricados por la empresa. Por ejemplo, un coche puede estar formado por los siguientes
componentes: 2 ruedas, 1 volante, 4 asientos, etc.
La empresa sirve pedidos a varias juguetería. En cada pedido realizado por una juguetería
pueden figurar varios juguetes en distintas cantidades. Además por cada pedido se registrará
la fecha del pedido y la fecha en que se suministre.
También se almacenará en la base de datos información de los empleados de la empresa que
son responsables tanto de la fabricación de los juguetes como de los componentes de los
mismos. De cada empleado además de sus datos, se deberá conocer quién es su empleado
jefe.
Se parte del siguiente diagrama Entidad-Relación mostrado.

CLASE EMPLEADO Es-jefe

responsable responsable
hay

JUGUETE composición COMPONENTE

cant
Línea-pedido
cant

PEDIDO JUGUETERIA
solicita

ubicación

CIUDAD

146
Atributos:
CLASE: código, nombre
JUGUETE: código, nombre, precio venta
PEDIDO: número de pedido, fecha pedido, fecha suministro
EMPLEADO: DNI, nombre, fecha nacimiento, salario
COMPONENTE: código, nombre, precio costo
JUGUETERIA: NIF, nombre, dirección
CIUDAD: código, nombre, provincia

Se pide: Diseño relacional equivalente al modelo Entidad-Relación presentado

EJERCICIO 3

Se desea diseñar una base de datos para gestionar la información que se utiliza en la red
pública de hospitales de un país.
Cada hospital consta de varias secciones (urgencias, cardiología, pediatría, etc..) en las que
trabaja el personal sanitario, compuesto por médicos y enfermero/as.
Por cada ingreso de un paciente en un hospital se guarda la fecha de alta y la fecha baja en el
mismo, la habitación, el diagnóstico emitido y el médico que lo firmó. De cada paciente,
además de sus datos, se registra con qué otros pacientes tienen una relación familiar directa,
para poder avisarles en caso de un ingreso imprevisto.
Por otro lado, también se registra al información de los cursos de formación que ha ofrecido cada
hospital para los médicos especificando qué médico-profesor lo ha impartido y qué médicos han
asistido como alumnos, indicando en cada caso la calificación final que han obtenido en la
evaluación del mismo.
Se parte del diagrama Entidad-Relación mostrado.

Atributos:
HOSPITAL: código, nombre, dirección, ciudad
SECCIÓN: código, nombre
MEDICO: DNI, nombre, dirección, salario
ENFERMERO: DNI, nombre, dirección
CURSO: código, título, num_horas
ESPECIALIDAD: código, denominación
PACIENTE: NSS, nombre, fecha_ncto, dirección, teléfono
DIAGNÓSTICO: código, denominación

Se pide realizar el diseño relacional equivalente al modelo Entidad-Relación presentado.

147
consta trabaja
HOSPITAL SECCIÓN ENFERMERO

trabaja
ofrece

f-alta
profesor
MEDICO f-ingr
CURSO
hab
alumnos
DIAGNOSTICO
ingreso
calif tiene

ESPECIALIDAD PACIENTE

parentesco

tipo

EJERCICIO 4

En la residencia de los marqueses de Trujillo se realizan grandes banquetes con relativa


frecuencia. Los restaurantes que hasta ahora les proveían no han causado la admiración
esperada entre los comensales invitados, de modo que la marquesa ha decidido contratarnos
para que diseñemos una Base de Datos que le permita elaborar los banquetes por sí misma.

Después de mantener una larga entrevista con ella, hemos obtenido la siguiente información:

• Se guarda información de numerosos platos o recetas de cocina: código de plato (único),


nombre, características generales, código y nombre del país de procedencia.
• Un menú se compone de varios platos, y cada menú tiene un código de menú único.
• Cada uno de esos platos cumplirá una función diferente según el menú en el que se
incluya. Por ejemplo, un plato que en un menú determinado puede actuar como entrante
podrá ser primer plato de otro menú.
• Se desea confeccionar un menú para degustarlo en una fecha determinada, guardando la
descripción del acontecimiento por el que se realizó el banquete. De esta forma,
posteriormente se podría consultar el menú elaborado en una determinada fecha o
acontecimiento.

148
• Sabemos que en un mismo día sólo se realiza un banquete y que todos los menús son
diferentes (cambia algún plato y/o algún cocinero).
• Cada plato o receta se compone de una serie de ingredientes, cada uno de ellos en una
cantidad determinada, para ser cocinado. Además, sabemos que el modo de preparación de
cada ingrediente puede ser diferente según el plato en el que intervenga (troceado, rallado,
cocido, etc.).
• Por otro lado, la señora marquesa no es experta en el arte culinario, por lo que desea
contratar un cocinero diferente por cada plato seleccionado para el menú en cuestión. Para
ello, en la Base de Datos se desea mantener información sobre los mejores cocineros
procedentes de diversos países (identificativo y nombre del cocinero, código y nombre del
país de procedencia). De esta forma, en el futuro se podrá saber para un menú determinado
por su fecha o acontecimiento, qué platos lo compusieron junto con la información de su
correspondiente cocinero en dicho banquete.
• De cada cocinero interesa además de sus datos, el tipo de cocina que desarrolla (vasca,
francesa, mediterránea, ...) registrándose mediante un código y una denominación.
• Además se nos ha informado de que un plato del menú pensado para un futuro banquete,
puede quedar sin cocinero hasta el último momento, de forma que la marquesa pueda
elegir el cocinero en cualquier instante y asignárselo a dicho plato del menú.
• Se utilizará un código de menú que identificará a cada menú concreto preparado para un
acontecimiento específico.

Algunas de las operaciones más habituales que se realizan en la Base de Datos son:
a) Saber de qué se compuso el menú degustado en un acontecimiento concreto, así como
quién fue el cocinero que elaboró cada uno de los platos en aquel acontecimiento.
b) Listar los cocineros de un determinado país dado por su código, por ejemplo: obtener los
cocineros franceses (código 01) que tenemos en la Base de Datos.
c) Listado por orden alfabético de los cocineros del país que estén almacenados en la Base
de Datos cuyo nombre empiece por A, indicando mediante un mensaje si han cocinado
alguna vez para los marqueses.
d) Para un determinado acontecimiento, elegir los platos que compondrán el menú y
asignarles los cocineros.
e) Listado de los diferentes platos registrados en la BD con indicación de sus ingredientes y
forma de preparación, por ejemplo:

149
PLATO INGREDIENTE
COD. NOMBRE COD. NOMBRE CANTIDAD MODO_PREP
P01 Cocktail marisco Ι10 Gamba 12u. cocido
Ι88 Aceite oliva 20ml. crudo
Ι55 Vinagre 7ml. crudo
Ι20 Sal 5gr. crudo
Ι66 Lechuga 4 hojas. en juliana
P03 Gambas plancha Ι10 Gamba 6u. plancha
Ι77 Limón 1u. exprimido
Ι88 Aceite oliva 25ml. crudo
Ι20 Sal 20gr. crudo

f) Listado de los diferentes acontecimientos registrados en la BD, con los menús que se
prepararon y los cocineros que intervinieron en cada plato. Por ejemplo:

ACONTECIMIENTO FUNCIÓN PLATO COCINERO


Navidad 1995 entrante Cocktail marisco Arturo Fuentes
plato princ. Pimientos Rodrigo Ramírez
rellenos
postre Mousse limón Raúl Sanz
Cumpleaños Marqués 95 entrante Entremeses fríos Raúl Sanz
plato princ. Pimientos Arturo Fuentes
rellenos
postre Mousse limón Rodrigo Ramírez
...... ...... ...... ......

Se pide:
1. Realizar el diseño conceptual utilizando el modelo Entidad-Relación que recoja la realidad
comentada.
2. Diseño Relacional equivalente.

EJERCICIO 5

Se quiere diseñar una base de datos para manejar la información de una cadena de gabinetes
de estética que se dedican a tratar a personas que desean perder o ganar peso. Se desea que en
la BD se registre la siguiente información:
• Se dispone de un conjunto de médicos que pueden trabajar en varios gabinetes pero en
fechas distintas. De cada gabinete deseamos almacenar un código, nombre, dirección,
teléfono y los médicos que están trabajando en él en un momento determinado. Así
mismo, de cada médico almacenaremos su DNI, nombre, nº de colegiado y teléfono.
• Se considera paciente a la persona que va a uno de nuestros gabinetes. A cada paciente se
le asigna un único médico, que será el que le ponga una de las dietas diseñadas (que
tenemos almacenadas en la base de datos) dependiendo del peso del paciente. Además, a

150
cada paciente se le realiza un estudio de los nutrientes que su metabolismo necesita y en
qué cantidad. Cada persona puede acudir a uno de nuestros gabinetes (siempre al mismo)
en varias épocas de su vida.
• De cada paciente deseamos almacenar su DNI, nombre, dirección, teléfono, peso, así
como las dietas que ha seguido (si es que ha visitado el gabinete en varias ocasiones), la
fecha de comienzo de cada dieta y su duración.
• Cada dieta consta de un conjunto de alimentos agrupados en tomas (desayuno, almuerzo,
comida, merienda y cena). De cada dieta deseamos almacenar un código, una descripción,
así como de qué alimentos consta y en cuanta cantidad en cada una de sus tomas.
• De cada toma deseamos almacenar un código, un nombre (comida, cena...) y la hora de
toma.
• De cada alimento almacenaremos un identificativo, el nombre y todos los nutrientes que
aporta dicho alimento junto con la cantidad aportada de cada nutriente.

Algunas de las consultas más frecuentes a la bd son:


• Listado de pacientes de cada gabinete junto con el médico que les atiende.
• Dietas que ha seguido un determinado paciente a lo largo de los 3 últimos años.
• Listado de una dieta determinada indicando por cada toma los alimentos que se deben
comer y en qué cantidad.
• Listado de alimentos que contienen un determinado nutriente en cantidad superior al
50%.

Se pide :
1. Realizar el diseño conceptual utilizando el modelo Entidad-Relación que recoja la realidad
comentada con el menor número de redundancias.
2. Realizar el diseño relacional equivalente.

EJERCICIO 6

Deseamos diseñar una base de datos para gestionar la información anual que se maneja en un
conjunto de museos. Estos museos están situados en diversas ciudades del país (puede haber más
de uno en la misma ciudad). De cada museo nos interesa conocer el identificativo y nombre del
museo y el identificativo y nombre de la ciudad a la que pertenece.

En cada museo se exponen una serie de obras durante un período de tiempo determinado.
Además disponemos de un conjunto de empleados cada uno de los cuales trabaja un mes en cada
museo. Para cada obra expuesta en un museo encargamos a uno de nuestros empleados (que esté
trabajando ese mes en el museo) que sea responsable del cuidado y mantenimiento de una o
varias obras. Además de este tipo de empleados disponemos de otros que no se encargan de las
obras sino de la limpieza y seguridad del museo. De cada empleado nos interesa saber su dni,
nombre, quién es su jefe, en qué museo está trabajando en una fecha determinada, así como de

151
qué obras ha sido el responsable (si es que ha sido responsable de alguna). De cada obra nos
interesa saber el código de la obra (que es único), la denominación, el código del género al que
pertenece, la denominación de ese género (pintura, escultura,...), así como quién es el encargado
de esa obra en un museo en una fecha concreta y quién es el autor de la misma, las técnicas en las
que está especializado cada autor (óleo, barro, acuarela,...) y el identificativo y nombre de la
ciudad a la que pertenece.

Algunas de las consultas que se realizarán sobre la base de datos son:


• Museos en los que se han expuesto obras de un determinado autor.
• Qué autores están especializados en una determinada técnica.
• Dada una determinada obra, obtener para cada uno de los museos en los que ha sido
expuesta, el empleado responsable de su mantenimiento.
• Autores y museos de una ciudad determinada.

Se pide :
1. Realizar el diseño conceptual utilizando el modelo Entidad-Relación que recoja la
realidad comentada con el menor número de redundancias.
2. Realizar el diseño relacional equivalente.

EJERCICIO 7

Sea la siguiente base de datos:

AGENCIA (COD_AG, NOM_AG, DIR, TF)


CLIENTE (DNI, NOM, DIR, CIUDAD,TF)
RESERVA (DNI, COD_AG, DESTINO, COD_VIAJE, FECHA_SALIDA, IMPORTE,
SEÑAL)

que representa las reservas de viajes de ciertos clientes a una serie de agencias de viajes para
un periodo largo de tiempo. Se pide:

a) Suponiendo que la tabla AGENCIA ya está creada, codificar en SQL la creación de las
tablas CLIENTE y RESERVA teniendo en cuenta los siguientes requisitos:
• Deben hacerse cumplir las reglas de integridad referencial e integridad de la entidad.
• La señal que deja el cliente cuando reserva el viaje ha de ser como mínimo el 20% del
importe del viaje.
• En el caso de que un cliente se elimine de la BD, deberán eliminarse automáticamente
todas sus reservas.
• La ciudad del cliente por defecto será BILBAO.
b) Codificar en SQL el alta de un cliente con tus datos personales, y a continuación reservar
un viaje con destino a Madrid. Inventa los datos que necesites.

152
c) Codifica en SQL la siguiente operación: Obtener un listado de los clientes que han
reservado algún viaje con la agencia de nombre ‘VIAJES ECUADOR’ durante el año
2000, indicando DNI, y nombre.
d) Obtener quién es el cliente que más reservas de viajes ha realizado de todos los que hay
en la BD, indicando su nombre y el número de reservas.

EJERCICIO 8

Consideremos la siguiente base de datos:

ARQUITECTO(DNI, NOMBRE, DIR,CIUDAD, TF)


EDIFICIO(COD_E, NOM_E, DIR, Nº_PLANTAS, FECHA_C)
DISEÑA(DNI, COD_E, SALARIO, TIEMPO)

que representa los arquitectos que han diseñado los edificios de Bilbao. Cada edificio puede
haber sido diseñado entre varios arquitectos. La relación DISEÑA indica el tiempo que ha
invertido cada arquitecto en diseñar cada edificio así como lo que cobró por ello.
Se pide:

a) Suponiendo que la tabla ARQUITECTO ya está creada, codificar en SQL la creación de


las tablas EDIFICIO y DISEÑA, teniendo en cuenta los siguientes requisitos:
• Deben hacerse cumplir las reglas de integridad de la entidad e integridad referencial.
• El nº de plantas de cada edificio ha de ser como mínimo 1.
• El salario por defecto será 1200 euros.
• Al eliminar un edificio de la BD, deberán eliminarse automáticamente todas sus
tuplas en DISEÑA.
b) Codifica en SQL la siguiente operación: Obtener un listado en el que aparezca por cada
arquitecto su DNI, nombre y su salario total (que será la suma de todos los salarios
obtenidos en sus diseños).
c) Codifica en SQL: Actualizar el salario correspondiente a los diseños en los que se haya
invertido más de 6 meses, en un 10%.
d) Codifica en SQL: Obtener cuál es el salario medio cobrado por diseño en edificios
construidos durante el último año.

EJERCICIO 9

Consideremos la siguiente BD que contiene la información de las ventas mensuales de un


pequeño comercio. El campo OFERTA puede llevar el valor SI o NO según el artículo esté o
no en oferta. En el primer caso, se le aplica un descuento del 10%. En la tabla de VENTAS,
el atributo CANT refleja el número total de unidades vendidas de un artículo por un
empleado un determinado día.

EMPLEADO(COD-E, NOM-E, CARGO, COD-E-JEFE)

153
ARTICULO(COD-A, DESC, PV, OFERTA)
VENTAS(COD-A, COD-E, FECHA, CANT)

Se pide la codificación SQL para:


a) Creación de las tablas EMPLEADO y VENTAS, suponiendo que ARTICULO ya está
creada, teniendo en cuenta las siguientes pautas:
• Deben hacerse cumplir las reglas de integridad de la entidad e integridad referencial.
• Al insertar una nueva fila en VENTAS, la cantidad por defecto será 1.
• Deberá comprobarse que la cantidad sea mayor que 0.
• Al eliminar un empleado de la BD, deberán eliminarse automáticamente todas las
ventas relacionadas con el mismo.
b) Obtener mediante una subconsulta el código y descripción de los artículos vendidos por
el empleado de código 111, el día 10/6/99.
c) Obtener el código y la descripción de los artículos de los cuales el día 10/6/99 se
vendieron más de 10 unidades en total (teniendo en cuenta las unidades vendidas por
todos los empleados).
d) Obtener los nombres de los empleados cuyo jefe es Jon Acha.
e) Actualizar la tabla ARTICULO y poner en oferta el artículo RAQUETA de TENIS.

EJERCICIO 10

Dada la siguiente base de datos con información de los médicos que trabajan en los diferentes
servicios de una red de hospitales, codifica en SQL las operaciones que se indican.

HOSPITAL (COD_H, NOM_H, CIUDAD)


SERVICIO (COD_H, COD_S, NOM_S)
MEDICO (COD_H, COD_S, DNI, NOM_M, FECHA_NCTO, ESPECIALIDAD,
NUM_HIJOS)

1. Creación de la tabla MEDICO teniendo en cuenta:


• Deberán hacerse cumplir las reglas de integridad de la entidad e integridad
referencial.
• En caso de eliminar un servicio, se eliminarán todos los médicos que actualmente
trabajen en él.
• El valor de ESPECIALIDAD por defecto será ‘medicina general’.
• Deberá comprobarse que el valor de número de hijos sea 0 o superior.
2. Indica datos de muestra para las 3 tablas (entre 2 y 5 filas por tabla).
3. Crear un índice sobre el campo nombre del médico. ¿Para qué sería útil?
4. Insertar un nuevo médico en la BD (tú mismo) inventando los datos que sea
necesario.

154
5. Obtener los médicos que trabajan en el hospital 007 y que tienen más de 2 hijos.
6. Modificar el número de hijos del Dr. Juan López a 3.
7. Obtener los nombres y especialidad de aquellos médicos del hospital 007 que tengan
la especialidad de Pediatría, Medicina Interna o Traumatología.
8. Obtener la media de hijos que tienen los médicos del hospital.
9. Obtener los DNI y nombres de los médicos cuyo nombre empiece por J ordenando el
resultado en ascendente por DNI.

EJERCICIO 11

Dada la siguiente base de datos con información de los hoteles de un territorio y las reservas
realizadas sobre los mismos:

HOTEL (COD-H, NOM-H, ESTRELLAS, MUNICIPIO)


HABITACIÓN (COD-H, NUM-HAB, PRECIO, TIPO)
RESERVAS (COD-H, NUM-HAB, FECHA, NUM_DIAS, NOM_CLTE)

Codificación en SQL de las siguientes operaciones:

1. Creación de la tabla RESERVAS teniendo en cuenta:


• Deberán hacerse cumplir las reglas de integridad de la entidad e integridad
referencial.
• El valor de NUM_DIAS por defecto será 1 y deberá comprobarse que sea siempre
mayor que 0.
• En el caso de eliminar una habitación de la BD, se eliminarán todas las reservas
asociadas a la misma.
2. Indica datos de muestra para las 3 tablas (entre 2 y 5 filas por tabla).
3. Modificar la estructura de la tabla RESERVAS, añadiéndole una columna para el teléfono
del cliente.
4. Obtener los datos de los hoteles que tengan entre 3 y 4 estrellas, ordenando el resultado
por municipio y por número de estrellas en descendente.
5. Insertar una nueva habitación de tipo suite en uno de los hoteles y haz una reserva para el
próximo fin de semana a tu nombre. Inventa los datos que consideres oportuno.
6. Elimina de la BD la reserva realizada en el punto anterior.
7. Obtén cuál es el precio medio de las habitaciones registradas en la BD.
8. Obtén, cuántas habitaciones de tipo DOBLE hay en la BD cuyo precio sea inferior a 50€.
9. Obtener las reservas realizas por los clientes cuyo nombre empiece por C.
10. Obtener los clientes que se alojaron en algún hotel del Bilbao en diciembre de 2007,
indicando el nombre del cliente y el nombre del hotel y ordenando el resultado por hotel
(sin filas repetidas).

155
11. Obtener mediante subconsultas los nombres de los clientes que se han alojado en algún
hotel de 5 estrellas durante el mes pasado.
12. Obtener por cada cliente de la tabla RESERVAS, el nombre del cliente y el número total
e días que ha pasado en hoteles durante el año 2007.
13. Obtener el número de habitaciones que tienen los hoteles de Bilbao, para aquellos que
tengan más de 20 habitaciones, indicando el nombre del hotel y el número de habitaciones
14. Obtener los datos de las habitaciones cuyo precio sea inferior a la media de precios de
habitaciones

EJERCICIO 12

Realizar a partir de las tablas AUTORES y LIBROS de la figura, las siguientes consultas en
SQL:
a) Nombre de los autores que trabajan en la F.I.M.
b) Libros escritos por autores de nacionalidad italiana.
c) Instituciones en las que trabajan autores que no hayan publicado libros en la editorial
Addison Wesley.

AUTORES ( NOMBRE NACIONALIDAD INSTITUCION)


DATE C.J. NORTEAM. RELATIONAL INS.
DE MIGUEL A. ESPAÑOLA F.I.M.
SALTOR F. ESPAÑOLA F.I. DE U.P.M.
CERI S. ITALIA POLITEC. MILAN

LIBROS ( LIBRO AUTOR EDITORIAL)


DB SYSTEMSDATE C.J. ADDISON-W
BASI DI DATI CERI S. CLUP
SQL STAND. DATE C.J. ADDISON-W
DISEÑO BD DE MIGUEL A. RAMA

156
EJERCICIO 13

Dadas las siguientes tablas, realizar las consultas indicadas utilizando SQL.

Tabla VUELOS:
NUM_VUELO ORIGEN DESTINO HORA_SALIDA TIPO_AVION

IB600 MADRID LONDRES 10:30 320


BA467 MADRID LONDRES 20:40 73S
IB0640 MADRID BARCELONA 06:45 320
IB3742 MADRID BARCELONA 09:15 72S
LH1349 COPENHAGUE FRANCFORT 10:20 320
AF577 BILBAO PARIS 10:10 737
IB3709 DUBLIN BARCELONA 14:35 D9S
IB778 BARCELONA ROMA 09:45 72S
IB721 BARCELONA SEVILLA 16:40 72S
IB327 MADRID SEVILLA 18:05 72S
IB023 MADRID TENERIFE 21:20 72S
IB368 MALAGA BARCELONA 22:25 D9S
IB610 MALAGA LONDRES 15:05 73S
IB510 SEVILLA MADRID 07:45 72S
IB318 SEVILLA MADRID 10:45 72S

Tabla AVIONES:
IPO CAPACIDAD LONGITUD ENVERGADURA VELOCIDAD_CRUCERO
D9S 110 38.30 28.50 815
320 187 42.15 32.60 853
72S 160 36.20 25.20 820
73S 185 44.10 30.35 815
737 172 38.90 29.00 793

Tabla RESERVAS:
NUM_VUELO FECHA_SALIDA PLAZAS_LIBRES
IB600 20/02/08 46
IB600 21/02/08 80
IB600 22/02/08 91
BA467 20/02/08 32
BA467 21/02/08 49
BA467 22/02/08 79
IB0640 20/02/08 15
IB0640 21/02/08 21
IB0640 22/02/08 39
IB3709 20/02/08 60
IB3709 21/02/08 72
IB3709 22/02/08 85
IB510 20/02/08 19
IB510 21/02/08 31
IB510 22/02/08 40

157
1. Obtener el origen, destino y hora de salida para todos los vuelos.
2. Obtener las ciudades de donde sale algún vuelo.
3. Obtener el nº de vuelo y la hora de los vuelos que hacen el trayecto Madrid-Londres.
4. Obtener todos los vuelos que salgan de Madrid y lleguen a Barcelona o a Sevilla.
5. Obtener todos los vuelos que salgan de Madrid, Barcelona o Sevilla.
6. Recuperar los vuelos que salgan desde las 6 hasta las 12 de la mañana.
7. Obtener todos los vuelos de la compañía IBERIA.
8. Obtener cual es la velocidad máxima de crucero.
9. Obtener a qué hora sale el primer vuelo de Madrid.
10. Obtener cuántas reservas permanecen con más de 50 plazas libres.
11. Determinar el número de destinos distintos en la tabla VUELOS.
12. Dar el número de plazas que quedan en total en todos los vuelos del día 20 de Febrero de
1992.
13. Obtener para todas las ciudades de origen a qué hora sale el primer vuelo.
14. Mostrar el número total de plazas libres existentes para cada vuelo de Iberia
(independientemente de la fecha).
15. Ver qué vuelos de Iberia tienen en total más de 150 plazas libres.
16. Mirar si hay plazas libres en el vuelo Madrid-Londres del 21/2/1992 a las 20:40.
17. Obtener los tipos de aviones y sus capacidades para aquellos en los que queden menos de 30
plazas libres para alguno de sus vuelos.
18. Recuperar los aviones cuya longitud sea mayor que la envergadura máxima.
19. Recuperar las plazas libres que hay en cada uno de los vuelos Madrid-Londres para el
20/2/92.

EJERCICIO 14

Dadas las siguientes tablas, realizar las consultas indicadas utilizando el lenguaje SQL.

Tabla S (Proveedores)
S# NOMS ESTADO CIUDAD
S1 SALAZAR 20 LONDRES
S2 JARAMILLO 10 PARIS
S3 BERNAL 30 PARIS
S4 CAICEDO 20 LONDRES
S5 ALDANA 30 ATENAS

158
Tabla P (Piezas)
P# NOMP COLOR PESO CIUDAD
P1 TUERCA ROJO 12 LONDRES
P2 PERNO VERDE 17 PARIS
P3 TORNILLO AZUL 17 ROMA
P4 TORNILLO ROJO 14 LONDRES
P5 LEVA AZUL 12 PARIS
P6 RUEDA ROJO 19 LONDRES

Tabla J (Proyectos)
J# NOMJ CIUDAD
J1 CLASIFICADOR PARIS
J2 PERFORADORA ROMA
J3 LECTORA ATENAS
J4 CONSOLA ATENAS
J5 COMPAGINADOR LONDRES
J6 TERMINAL OSLO
J7 CINTA LONDRES

Tabla SPJ (Envíos)


S# P# J# CANT
S1 P1 J1 200
S1 P1 J4 700
S2 P3 J1 400
S2 P3 J2 200
S2 P3 J3 200
S2 P3 J4 500
S2 P3 J5 600
S2 P3 J6 400
S2 P3 J7 800
S2 P5 J2 100
S3 P3 J1 200
S3 P4 J2 500
S4 P6 J3 300
S4 P6 J7 300
S5 P2 J2 200
S5 P2 J4 100
S5 P5 J5 500
S5 P5 J7 100
S5 P1 J4 100
S5 P3 J4 200
S5 P4 J4 800
S5 P5 J4 400

Envíos: Un proveedor específico suministra la pieza especificada al proyecto especificado en la


cantidad especificada.

1.- Obtener los detalles de todos los proyectos de Londres.

159
2.- Obtener los números de proveedor que suministran piezas al proyecto J1 ordenados por S#.
3.- Obtener todos los envíos en los cuales la cantidad está en el intervalo de 300 a 750.
4.- Obtener las tripletas S#/P#/J# tales que el proveedor, la pieza y el proyecto indicados estén
todos en la misma ciudad (cosituados)
5.- Obtener los números de la piezas suministradas por un proveedor de Londres a un proyecto
de Londres.
6.- Obtener el número total de proyectos a los cuales suministra piezas el proveedor S1.
7.- Obtener los números de las piezas suministradas a algún proyecto tales que la cantidad media
de cada pieza en cada proyecto sea mayor que 320.
8.- Obtener todos los envíos para los cuales la cantidad no sea nula.
9.- Obtener los números de proyecto y ciudad en los cuales la segunda letra del nombre de la
ciudad sea una 'o'.
10.- Obtener los nombres de los proyectos a los cuales suministra piezas el proveedor S1.
11.- Obtener los colores de las piezas suministradas por el proveedor S1.
12.- Obtener los números de las piezas suministradas a cualquier proyecto de Londres.
13.- Obtener los números de los proveedores cuyo estado sea inferior al del proveedor S1.
14.- Obtener los números de los proyectos a los cuales se suministras la pieza P1 en una cantidad
promedio mayor que la cantidad máxima en la cual se suministra alguna pieza al proyecto J1.

EJERCICIO 15

Una empresa consultora realiza trabajos, también llamados proyectos, para sus clientes,
utilizando un equipo de personas, o consultores, de su plantilla; dentro de dicho equipo se
nombra un consultor responsable, que es el encargado de supervisar el proyecto para realizarlo
en el plazo fijado y con la calidad que caracteriza a los trabajos de esta empresa.

Un consultor puede trabajar simultáneamente en varios proyectos y el responsable lo puede ser


también de varios de ellos por lo que su actividad diaria puede quedar repartida.

En caso de fuerza mayor el responsable de un proyecto puede cambiar, en cuyo caso nos
olvidamos de quién fue el anterior responsable y solamente queremos saber quién es el actual.

Entre los datos que habitualmente se manejan en la documentación utilizada en la gestión de los
trabajos figuran los siguientes:

(C#)="del consultor"; (Pº)="del proyecto"; (Cte)="del cliente"

Nombre (C#): Apellidos (C#); DNI (C#); Categoría (C#);


Precio/hora (C#); Código (Pº); Responsable (Pº); Descripción (Pº);
Fecha inicio (Pº); Fecha final prevista (Pº); %realizado (Pº);
Costo presupuestado (Pº); Costo real acumulado (Pº); Nombre (Cte);
Dirección (Cte); Importe recibido (Cte);

160
(En el diseño de la estructura de datos de esta aplicación seguramente tu sentido común te
empujará a introducir datos adicionales).

El costo real acumulado se calcula en base a las horas que cada consultor, incluido el
responsable, dedica a cada proyecto; esta información se consigue a través de un parte diario de
actividad que, supervisado por el responsable del proyecto, indica las horas invertidas por cada
consultor en cada proyecto con expresión del lugar donde se ha estado trabajando y de la
actividad realizada.

Debe tenerse en cuenta que el precio/hora de un consultor no depende de su categoría, y que cada
proyecto es encargado siempre por un sólo cliente.

Se pide:

1.- Obtener el esquema canónico relacional de la base de datos que sustente el sistema de
información enunciado.
2.- Codificación SQL que facilite el detalle de la actividad del consultor Abad durante los
tres primeros meses de 1991. Por ejemplo:

Sr. ABAD

PROYECTO DIA HORAS ACTIVIDAD LUGAR

A 2/1/91 3 X M
B 2/1/91 5 Y N
A 3/1/91 8 X M
C 4/1/91 8 W M

EJERCICIO 16

Disponemos de una base de datos que contiene las tablas CLIENTES, AGENTES, PRODUCTOS y
PEDIDOS. Esta base de datos la utiliza una compañía de ventas al por mayor para registrar la información de
sus clientes, los productos que vende, y los agentes que se encargan de los pedidos. Los clientes detallados
son, en sí mismos, comerciantes al por menor que hacen pedidos de grandes cantidades de varios productos a
la compañía mayorista, para luego revenderlos. Los distintos clientes en la tabla de CLIENTES se identifican
de manera única por los valores de la columna ID_CL (identificador de cliente). Los clientes realizan los
pedidos a los agentes (identificados de manera única por el valor de ID_A en la tabla AGENTES) con base en
ciudades de distintos países, con el objeto de adquirir algunos productos (identificados por ID_P en la tabla de
PRODUCTOS). Cada vez que se realiza un pedido, se inserta una nueva línea en la tabla de pedidos,
identificable de manera única por NO_P. Por ejemplo, el pedido identificado en la tabla de PEDIDOS por el
NO_P 1011 fue realizado en el mes de Enero (ene) por el cliente c001 al agente a01 con una cantidad de 1000
unidades del producto p01 con un costo de 450$.

161
A continuación se muestra una explicación detallada de los datos contenidos en cada tabla:

CLIENTES:
ID_CL: Identificador único de clientes.
NOM_CL: Nombre del cliente
CIUDAD: Ciudad donde está localizado el cliente.
DESCUENTO: Descuento negociado por cada cliente.

AGENTES:
ID_A: Identificador único de agentes.
NOM_A: Nombre del agente
CIUDAD: Ciudad donde el agente trabaja.
PORCENTAJE: Porcentaje que recibe el agente en cada venta.

PRODUCTOS:
ID_P: Identificador único de productos.
NOM_P: Nombre descriptor del producto.
CIUDAD: Ciudad donde el producto está almacenado.
CANTIDAD: Cantidad en stock para ser vendida, en Ud. estándar.
PRECIO: Precio de cada unidad.

NOTA: El nombre de la columna CIUDAD aparece en las tres tablas. No es una coincidencia.
A continuación se muestra el posible contenido de las tablas:

PEDIDOS:
NO_P Identificador único para cada pedido.
MES Mes en el que el pedido fue realizado. Comienza en Enero.
ID_CL Este cliente ...
ID_A ... adquirió a través de este agente ...
ID_P ... este producto específico ...
CANT ... en esta cantidad total ...
DOLARES ... con este coste en dólares.

CLIENTES
ID_CL NOM_CL CIUDAD DESCUENTO
C001 TipTop Duluth 10.00
C002 Basics Dallas 12.00
C003 Allied Dallas 8.00
C004 ACME Duluth 8.00
C006 ACME Kyoto 0.00

162
AGENTES
ID_A NOM_A CIUDAD PORCENTAJE
A01 Smith New York 6
A02 Jones Newwark 6
A03 Brown Tokyo 7
A04 Gray New York 6
A05 Otasi Duluth 5
A06 Smith Dallas 5

PRODUCTOS
ID_P NOM_P CIUDAD CANTIDAD PRECIO
p01 comb Dallas 111400 0.50
p02 brush Newark 203000 0.50
p03 razor Duluth 151600 1.00
p04 pen Duluth 125300 1.00
p05 pencil Dallas 221400 1.00
p06 folder Dallas 123100 2.00
p07 case Newark 100500 1.00

PEDIDOS
NO_P MES ID_CL ID_A ID_P CANT EUROS
1011 ene c001 a01 p01 1000 450.00
1012 ene c001 c01 p01 1000 450.00
1019 feb c001 a02 p02 400 180.00
1017 feb c001 a06 p03 600 540.00
1018 feb c001 a03 p04 600 540.00
1023 mar c001 a04 p05 500 450.00
1022 mar c001 a05 p06 400 720.00
1025 abr c001 a05 p07 800 720.00
1013 ene c002 a03 p03 1000 880.00
1026 may c002 a05 p03 800 704.00
1015 ene c003 a03 p05 1200 1104.00
1014 ene c003 a03 p05 1200 1104.00
1021 feb c004 a06 p01 1000 460.00
1016 ene c006 a01 p01 1000 500.00
1020 feb c006 a03 p07 600 600.00
1024 mar c006 a06 p01 800 400.00

SE PIDE: Confeccionar las sentencias SQL necesarias para los siguientes casos:

1 .- Para cada agente que suministra algún pedido, listar el identificativo del agente, el
identificativo del producto (ID_P) y la cantidad total pedida de ese producto por todos los clientes
de ese agente.
2 .- Seleccionar los ID_A de agentes que no reciban pedidos de ningún cliente en Duluth para
ningún producto en Dallas.

163
3 .- Listar ID_A de agentes que pidan un producto a algún cliente que tenga base en Duluth o
Tokio.
4 .- Mostrar los ID_CL de clientes hagan pedidos solamente a través del a03 o a05.
5 .- Seleccionar los ID_P de los productos que son pedidos por todos los clientes en Dallas.
6 .- Encontrar agentes con el mas alto porcentaje, usando la función max.
7 .- En la tabla de agentes, borrar la línea del agente llamado Gray, mostrar la tabla resultante y
después volver a poner a Gray utilizando la sentencia Insert.
8 .- Usa la sentencia Update para cambiar el porcentaje de Gray a 11. Después restablece el valor
original.
9 .- Usa una sentencia Update para subir el precio de todos los productos almacenados en Duluth
o Dallas en un 10%.
10.- Escribe la sentencia SQL para coger los valores id_cl de los clientes que han cursado al
menos un pedido, pero solamente a través del agente a04. En la misma línea deberá aparecer
junto a id_cl el total en dólares de cada pedido.
11.- Escribe la sentencia SQL para coger los valores id_a de los agentes que cogen pedidos de
los clientes que viven en Duluth. Los id_a deberán listarse en orden decreciente de porcentaje.
12.- Escribe la sentencia SQL para coger los valores id_p de productos pedidos por algún cliente
que viva en la misma ciudad que al agente que recibe el pedido.
13.- Encontrar todas las combinaciones de ternas de cliente, agente y producto (ID_CL, ID_A,
ID_P) que están todos en la misma ciudad. No tener en cuenta los pedidos.

14.- Encontrar todas las combinaciones de ternas de cliente, agente y producto (ID_CL, ID_A,
ID_P) que no están todos en la misma ciudad (dos de ellos si pueden estarlo).

15.- Encontrar todas las combinaciones de ternas de cliente, agente y producto (ID_CL, ID_A,
ID_P) que dos de ellos no estén en la misma ciudad .

16.- Seleccionar las ciudades de agentes que tengan inscrito un pedido del cliente c002.
17.- Seleccionar los nombres de productos pedidos al menos por un cliente de Dallas a través de
un agente de Tokio.
18.- Seleccionar los ID_P de productos pedidos a través de cualquier agente que haga al menos
un pedido para algún cliente de Kyoto. NOTA: Esta consulta no es la misma que preguntar por
ID_P de productos pedidos por un cliente en Kyoto.

19.- Mostrar todos los pares de ID_A para agentes que viven en la misma ciudad.
20.- Encontrar ID_CL de clientes que no mandaron un pedido a través del agente a03.
21.- Encontrar ID_P de productos pedidos a través del agente a03 pero no a través del agente a06.
22.- Seleccionar los NOM_P y los ID_P de productos que estén almacenados en la misma CIUDAD
en la que alguno de los agentes venda estos productos.
23.- Encontrar ID_A y NOM_A de agentes cuyo NOM_A empiece por la letra "N" y que no tengan
pedido para ningún producto en Newark.
24.- Seleccionar los ID_CL de los clientes que tienen pedido el producto p01 y el producto p07.
25-. Seleccionar ID_P de productos pedidos por todos los clientes que realizan algún pedido a
través del agente a03.

164
26-. Mostrar los ID_A de agentes que tengan pedidos individuales de valor superior a 500.000 $
de clientes que vivan en Kyoto.

165
BIBLIOGRAFÍA

Para la confección del presente material didáctico, se ha utilizado la siguiente bibliografía:

[1] CONNOLLY, T.M. & BEGG, C.E., 2005. Sistemas de Bases de


Datos. Un enfoque práctico para diseño, implementación y gestión, 4ª
edición. Pearson Addison-Wesley.

[2] DATE, C.J. 2001. Introducción a los sistemas de Bases de Datos.


Volumen 1, 7ª edición. Ed. Addison-Wesley Iberoamericana, E.U.A.

[3] ELMASRI R.A. & NAVATHE, S.B., 2002. Fundamentos de Sistemas


de Bases de Datos, 3ª edición. Addison-Wesley

[4] MANNINO, M.V., 2007. Administración de Bases de Datos. Diseño y


Desarrollo de Aplicaciones, 3ª edición. Ed. McGraw Hill.

[5] PÉREZ, C., 2002. Oracle 9i. Administración y Análisis de Bases de


Datos. Ed. RA-MA.

[6] PONS, O. et al. 2005. Introducción a las Bases de Datos. El modelo


Relacional. Thomson, España.

[7] PONS. O. et al. 2008. Introducción a los Sistemas de Bases de Datos.


Ed. Paraninfo, CENGAGE Learning.

[8] RAMAKRISHNEN & GEHRKE. Sistemas de Gestión de Bases de


Datos, 3ª edición. Ed. McGraw Hill.

[9] RIVERO, E., MARTÍNEZ, L, REINA, L., BENAVIDES, J.,


OLAIZOLA, J.M., 2002. Introducción al SQL para Usuarios y
Programadores. Ed. Thomson.

[10] ROB, P. & CORONEL, C., 2004. Sistemas de Bases de Datos. Diseño,
Implementación y Administración. Thomson

[11] SILVERSCHATZ, KORTH & SUDARSHAN, 2006. Fundamentos


de Bases de Datos. 5ª edición. McGraw-Hill.

166