Los primeros SGBD –en los años sesenta todavía no se les denominaba así estaban orientados a facilitar la utilización de grandes conjuntos de datos en los que las interrelaciones eran complejas. El arquetipo de aplicación era el Bill of materials o Parts explosion, típica en las industrias del automóvil, en la construcción de naves espaciales y en campos similares. Estos sistemas trabajaban exclusivamente por lotes (batch).

Al aparecer los terminales de teclado, conectados al ordenador central mediante una línea telefónica, se empiezan a construir grandes aplicaciones on-line transaccionales (OLTP). Los SGBD estaban íntimamente ligados al software de comunicaciones y de gestión de transacciones.

Aunque para escribir los programas de aplicación se utilizaban lenguajes de alto nivel como Cobol o PL/I, se disponía también de instrucciones y de subrutinas especializadas para tratar las BD que requerían que el programador conociese muchos detalles del diseño físico, y que hacían que la programación fuese muy compleja.

Puesto que los programas estaban relacionados con el nivel físico, se debían modificar continuamente cuando se hacían cambios en el diseño y la organización de la BD. La preocupación básica era maximizar el rendimiento: el tiempo de respuesta y las transacciones por segundo.

Los ordenadores minis, en primer lugar, y después los ordenadores micros, extendieron la informática a prácticamente todas las empresas e instituciones.

Esto exigía que el desarrollo de aplicaciones fuese más sencillo. Los SGBD de los años setenta eran demasiado complejos e inflexibles, y sólo los podía utilizar un personal muy cualificado.

Todos estos factores hacen que se extienda el uso de los SGBD. La estandarización, en el año 1986, del lenguaje SQL produjo una auténtica explosión de los SGBD relacionales.

Los ordenadores personales

Durante los años ochenta aparecen y se extienden muy rápidamente los ordenadores personales. También surge software para estos equipos monousuario (por ejemplo, dBase y sus derivados, Access), con los cuales es muy fácil crear y utilizar conjuntos de datos, y que se denominan personal data bases. Notad que el hecho de denominar SGBD estos primeros sistemas para PC es un poco forzado, ya que no aceptaban estructuras complejas ni interrelaciones, ni podían ser utilizados en una red que sirviese simultáneamente a muchos usuarios de diferentes tipos. Sin embargo, algunos, con el tiempo, se han ido convirtiendo en auténticos SGBD.

Al acabar la década de los ochenta, los SGBD relacionales ya se utilizaban prácticamente en todas las empresas. A pesar de todo, hasta la mitad de los noventa, cuando se ha necesitado un rendimiento elevado se han seguido utilizando los SGBD prerrelacionales.

A finales de los ochenta y principios de los noventa, las empresas se han encontrado con el hecho de que sus departamentos han ido comprando ordenadores departamentales y personales, y han ido haciendo aplicaciones con BD. El resultado ha sido que en el seno de la empresa hay numerosas BD y varios SGBD de diferentes tipos o proveedores. Este fenómeno de multiplicación de las BD y de los SGBD se ha visto incrementado por la fiebre de las fusiones de empresas.

Esta distribución ideal se consigue cuando las diferentes BD son soportadas por una misma marca de SGBD, es decir, cuando hay homogeneidad. Sin embargo, esto no es tan sencillo si los SGBD son heterogéneos. En la actualidad, gracias principalmente a la estandarización del lenguaje SQL, los SGBD de marcas diferentes pueden darse servicio unos a otros y colaborar para dar servicio a un programa de aplicación. No obstante, en general, en los casos de heterogeneidad no se llega a poder dar en el programa que los utiliza la apariencia de que se trata de una única BD.

Figura 1

Además de esta distribución “impuesta”, al querer tratar de forma integrada distintas BD preexistentes, también se puede hacer una distribución “deseada”, diseñando una BD distribuida físicamente, y con ciertas partes replicadas en diferentes sistemas. Las razones básicas por las que interesa esta distribución son las siguientes:

1) Disponibilidad. La disponibilidad de un sistema con una BD distribuida puede ser más alta, porque si queda fuera de servicio uno de los sistemas, los demás seguirán funcionando. Si los datos residentes en el sistema no disponible están replicados en otro sistema, continuarán estando disponibles. En caso contrario, sólo estarán disponibles los datos de los demás sistemas.

2) Coste. Una BD distribuida puede reducir el coste. En el caso de un sistema centralizado, todos los equipos usuarios, que pueden estar distribuidos por distintas y lejanas áreas geográficas, están conectados al sistema central por medio de líneas de comunicación. El coste total de las comunicaciones se puede reducir haciendo que un usuario tenga más cerca los datos que utiliza con mayor frecuencia; por ejemplo, en un ordenador de su propia oficina o, incluso, en su ordenador personal.

Por ejemplo, un programa de aplicación que un usuario ejecuta en su PC (que está conectado a una red) pide ciertos datos de una BD que reside en un equipo UNIX donde, a su vez, se ejecuta el SGBD relacional que la gestiona. El programa de aplicación es el cliente y el SGBD es el servidor.

Un proceso cliente puede pedir servicios a varios servidores. Un servidor puede recibir peticiones de muchos clientes. En general, un proceso A que hace de cliente, pidiendo un servicio a otro proceso B puede hacer también de servidor de un servicio que le pida otro proceso C (o incluso el B, que en esta petición sería el cliente). Incluso el cliente y el servidor pueden residir en un mismo sistema.

Figura 2

La facilidad para disponer de distribución de datos no es la única razón, ni siquiera la básica, del gran éxito de los entornos C/S en los años noventa. Tal vez el motivo fundamental ha sido la flexibilidad para construir y hacer crecer la configuración informática global de la empresa, así como de hacer modificaciones en ella, mediante hardware y software muy estándar y barato.

El éxito de las BD, incluso en sistemas personales, ha llevado a la aparición de los Fourth Generation Languages (4GL), lenguajes muy fáciles y potentes, especializados en el desarrollo de aplicaciones fundamentadas en BD. Proporcionan muchas facilidades en el momento de definir, generalmente de forma visual, diálogos para introducir, modificar y consultar datos en entornos C/S.

Los tipos de datos que se pueden definir en los SGBD relacionales de los años ochenta y noventa son muy limitados. La incorporación de tecnologías multimedia –imagen y sonido– en los SI hace necesario que los SGBD relacionales acepten atributos de estos tipos.

Sin embargo, algunas aplicaciones no tienen suficiente con la incorporación de tipos especializados en multimedia. Necesitan tipos complejos que el desarrollador pueda definir a medida de la aplicación. En definitiva, se necesitan tipos abstractos de datos: TAD. Los SGBD más recientes ya incorporaban esta posibilidad, y abren un amplio mercado de TAD predefinidos o librerías de clases.

Esto nos lleva a la orientación a objetos (OO). El éxito de la OO al final de los años ochenta, en el desarrollo de software básico, en las aplicaciones de ingeniería industrial y en la construcción de interfaces gráficas con los usuarios, ha hecho que durante la década de los noventa se extendiese en prácticamente todos los campos de la informática.

En los SI se inicia también la adopción, tímida de momento, de la OO. La utilización de lenguajes como C++ o Java requiere que los SGBD relacionales se adapten a ellos con interfaces adecuadas.

La rápida adopción de la web a los SI hace que los SGBD incorporen recursos para ser servidores de páginas web, como por ejemplo la inclusión de SQL en guiones HTML, SQL incorporado en Java, etc. Notad que en el mundo de la web son habituales los datos multimedia y la OO

Durante estos últimos años se ha empezado a extender un tipo de aplicación de las BD denominado Data Warehouse, o almacén de datos, que también produce algunos cambios en los SGBD relacionales del mercado.

A lo largo de los años que han trabajado con BD de distintas aplicaciones, las empresas han ido acumulando gran cantidad de datos de todo tipo. Si estos datos se analizan convenientemente pueden dar información valiosa*.

Por lo tanto, se trata de mantener una gran BD con información proveniente de toda clase de

aplicaciones de la empresa (e, incluso, de fuera). Los datos de este gran almacén, el Data Warehouse, se obtienen por una replicación más o menos elaborada de las

que hay en las BD que se utilizan en el trabajo cotidiano de la empresa. Estos almacenes de datos se utilizan exclusivamente para hacer consultas, de forma especial para que lleven a cabo estudios* los analistas financieros, los analistas de mercado, etc.

Actualmente, los SGBD se adaptan a este tipo de aplicación, incorporando, por ejemplo, herramientas como las siguientes:

a) La creación y el mantenimiento de réplicas, con una cierta elaboración de los datos.

b) La consolidación de datos de orígenes diferentes.

c) La creación de estructuras físicas que soporten eficientemente el análisis multidimensional.

El objetivo fundamental de los SGBD es permitir que se hagan consultas no predefinidas (ad hoc) y complejas.

Consultas que afectan a más de una entidad tipo

• Se quiere conocer el número de alumnos de más de veinticinco años y con nota media superior a siete que están matriculados actualmente en la asignatura Bases de datos

• De cada alumno matriculado en menos de tres asignaturas, se quiere obtener el nombre, el número de matrícula, el nombre de las asignaturas y el nombre de profesores de estas asignaturas.

El usuario debe formular la consulta con un lenguaje sencillo (que se quede, obviamente, en el nivel lógico), que el sistema debe interpretar directamente. Sin embargo, esto no significa que no se puedan escribir programas con consultas incorporadas (por ejemplo, para procesos repetitivos).

La solución estándar para alcanzar este doble objetivo (consultas no predefinidas y complejas) es el lenguaje SQL, que explicaremos en otro módulo didáctico.

La complejidad de las BD y la necesidad de irlas adaptando a la evolución del SI hacen que un objetivo básico de los SGBD sea dar flexibilidad a los cambios.

Interesa obtener la máxima independencia posible entre los datos y los procesos usuarios para que se pueda llevar a cabo todo tipo de cambios tecnológicos y variaciones en la descripción de la BD, sin que se deban modificar los programas de aplicación ya escritos ni cambiar la forma de escribir las consultas (o actualizaciones) directas.

En el mundo de los ficheros ya había independencia física en un cierto grado, pero en el mundo de las BD acostumbra a ser mucho mayor.

Ejemplos de independencia lógica

1) El personal administrativo de secretaría podría tener una visión de la entidad alumno sin que fuese necesario que existiese el atributo nota. Sin embargo, los usuarios profesores (o los programas dirigidos a ellos) podrían tener una visión en la que existiese el atributo nota pero no el atributo fecha de pago.

2) Decidimos ampliar la longitud del atributo nombre y lo aumentamos de treinta a cincuenta caracteres, pero no sería necesario modificar los programas que ya tenemos escritos

si no nos importa que los valores obtenidos tengan sólo los primeros treinta caracteres del nombre.

En el mundo de los ficheros tradicionales, cada aplicación utilizaba su fichero. Sin embargo, puesto que se daba mucha coincidencia de datos entre aplicaciones, se producía también mucha redundancia entre los ficheros. Ya hemos dicho que uno de los objetivos de los SGBD es facilitar la eliminación de la redundancia.

Seguramente pensáis que el problema de la redundancia es el espacio perdido. Antiguamente, cuando el precio del byte de disco era muy elevado, esto era un problema grave, pero actualmente prácticamente nunca lo es. ¿Qué problema hay, entonces? Simplemente, lo que todos hemos sufrido más de una vez; si tenemos algo apuntado en dos lugares diferentes no pasará demasiado tiempo hasta que las dos anotaciones dejen de ser coherentes, porque habremos modificado la anotación en uno de los lugares y nos habremos olvidado de hacerlo en el otro.

Así pues, el verdadero problema es el grave riesgo de inconsistencia o incoherencia de los datos; es decir, la pérdida de integridad que las actualizaciones pueden provocar cuando existe redundancia.

Por lo tanto, convendría evitar la redundancia. En principio, nos conviene hacer que un dato sólo figure una vez en la BD. Sin embargo, esto no siempre será cierto. Por ejemplo, para representar una interrelación entre dos entidades, se suele repetir un mismo atributo en las dos, para que una haga referencia a la otra.

Otro ejemplo podría ser el disponer de réplicas de los datos por razones de fiabilidad, disponibilidad o costes de comunicaciones.

La duplicación de datos es el tipo de redundancia más habitual, pero también tenemos redundancia cuando guardamos en la BD datos derivados (o calculados) a partir de otros datos de la misma BD. De este modo podemos responder rápidamente a consultas globales, ya que nos ahorramos la lectura de gran cantidad de registros.

En los casos de datos derivados, para que el resultado del cálculo se mantenga consistente con los datos elementales, es necesario rehacer el cálculo cada vez que éstos se modifican. El usuario (ya sea programador o no) puede olvidarse de hacer el nuevo cálculo; por ello convendrá que el mismo SGBD lo haga automáticamente.

Nos interesará que los SGBD aseguren el mantenimiento de la calidad de los datos en cualquier circunstancia. Acabamos de ver que la redundancia puede provocar pérdida de integridad de los datos, pero no es la única causa posible. Se podría perder la corrección o la consistencia de los datos por muchas otras

razones: errores de programas, errores de operación humana, avería de disco, transacciones incompletas por corte de alimentación eléctrica, etc.

En el subapartado anterior hemos visto que podremos decir al SGBD que nos lleve el control de las actualizaciones en el caso de las redundancias, para garantizar la integridad. Del mismo modo, podremos darle otras reglas de integridad –o restricciones– para que asegure que los programas las cumplen cuando efectúan las actualizaciones.

Aparte de las reglas de integridad que el diseñador de la BD puede definir y que el SGBD entenderá y hará cumplir, el mismo SGBD tiene reglas de integridad inherentes al modelo de datos que utiliza y que siempre se cumplirán. Son las denominadas reglas de integridad del modelo. Las reglas definibles por parte del usuario son las reglas de integridad del usuario. El concepto de integridad de los datos va más allá de prevenir que los programas usuarios almacenen datos incorrectos. En casos de errores o desastres, también podríamos perder la integridad de los datos. El SGBD nos debe dar las herramientas para reconstruir o restaurar los datos estropeados.

Cuando los accesos concurrentes son todos de lectura (es decir, cuando la BD sólo se consulta), el problema que se produce es simplemente de rendimiento, causado por las limitaciones de los soportes de que se dispone: pocos mecanismos de acceso independientes, movimiento del brazo y del giro del disco demasiado lentos, buffers locales demasiado pequeños, etc.

Cuando un usuario o más de uno están actualizando los datos, se pueden producir problemas de interferencia que tengan como consecuencia la obtención de datos erróneos y la pérdida de integridad de la BD.

Para tratar los accesos concurrentes, los SGBD utilizan el concepto de transacción de BD, concepto de especial utilidad para todo aquello que hace referencia a la integridad de los datos, como veremos a continuación.

Ejemplos de transacciones

1) Imaginemos un programa pensado para llevar a cabo la operación de transferencia de dinero de una cuenta X a otra Y. Supongamos que la transferencia efectúa dos operaciones: en primer lugar, el cargo a X y después, el abono a Y. Este programa se debe ejecutar de forma que se hagan las dos operaciones o ninguna, ya que si por cualquier razón (por ejemplo, por interrupción del flujo eléctrico) el programa ejecutase sólo el cargo de dinero a X sin abonarlos a Y, la BD quedaría en un estado incorrecto. Queremos que la ejecución de este programa sea tratada por el SGBD como una transacción de BD.

2) Otro ejemplo de programa que querríamos que tuviera un comportamiento de transacción podría ser el que aumentara el 30% de la nota de todos los alumnos. Si sólo aumentara la nota a unos cuantos alumnos, la BD quedaría incorrecta.

Para indicar al SGBD que damos por acabada la ejecución de la transacción, el programa utilizará la operación de COMMIT. Si el programa no puede acabar normalmente (es decir, si el conjunto de operaciones se ha hecho sólo de forma parcial), el SGBD tendrá que deshacer todo lo que la transacción ya haya hecho. Esta operación se denomina ROLLBACK.

Acabamos de observar la utilidad del concepto de transacción para el mantenimiento de la integridad de los datos en caso de interrupción de un conjunto de operaciones lógicamente unitario. Sin embargo, entre transacciones que se ejecutan concurrentemente se pueden producir problemas de interferencia que hagan obtener resultados erróneos o que comporten la pérdida de la integridad de los datos.

Consecuencias de la interferencia entre transacciones

1) Imaginemos que una transacción que transfiere dinero de X a Y se ejecuta concurrentemente con una transacción que observa el saldo de las cuentas Y y X, en este orden, y nos muestra su suma. Si la ejecución de forma concurrente de las dos transacciones casualmente es tal que la transferencia se ejecuta entre la ejecución de las dos lecturas de la transacción de suma, puede producir resultados incorrectos. Además, si los decide escribir en la BD, ésta quedará inconsistente (consultad la figura 3).

2) Si simultáneamente con el generoso programa que aumenta la nota de los alumnos en un 30%, se ejecuta un programa que determina la nota media de todos los alumnos de una determinada asignatura, se podrá encontrar a alumnos ya gratificados y a otros no gratificados, algo que producirá resultados erróneos.

Estos son sólo dos ejemplos de las diferentes consecuencias negativas que puede tener la interferencia entre transacciones en la integridad de la BD y en la corrección del resultado de las consultas.

Figura 3

Cuando se provocan bloqueos, se producen esperas, retenciones y, en consecuencia, el sistema es más lento. Los SGBD se esfuerzan en minimizar estos efectos negativos.

Recordad que esta asignatura es sólo introductoria y que más adelante, en otras asignaturas, estudiaréis con más detalle los temas que, como el de la concurrencia, aquí sólo introducimos.

El término seguridad se ha utilizado en diferentes sentidos a lo largo de la historia de la informática.

Estas cuestiones siempre han sido importantes en los SI militares, las agencias de información y en ámbitos similares, pero durante los años noventa han ido adquiriendo importancia en cualquier SI donde se almacenen datos sobre personas. Recordad que en el Estado español tenemos una ley*, que exige la protección de la confidencialidad de estos datos.

Los SGBD permiten definir autorizaciones o derechos de acceso a diferentes niveles: al nivel global de toda la BD, al nivel entidad y al nivel atributo.

Estos mecanismos de seguridad requieren que el usuario se pueda identificar. Se acostumbra a utilizar códigos de usuarios (y grupos de usuarios) acompañados de contraseñas (passwords), pero también se utilizan tarjetas magnéticas, identificación por reconocimiento de la voz, etc.

Nos puede interesar almacenar la información con una codificación secreta; es decir, con técnicas de encriptación (como mínimo se deberían encriptar las contraseñas). Muchos de los SGBD actuales tienen prevista la encriptación.

Prácticamente todos los SGBD del mercado dan una gran variedad de herramientas para la vigilancia y la administración de la seguridad. Los hay que, incluso, tienen opciones (con precio separado) para los SI con unas exigencias altísimas, como por ejemplo los militares.

Acabamos de ver los objetivos fundamentales de los SGBD actuales. Sin embargo, a medida que los SGBD evolucionan, se imponen nuevos objetivos adaptados a las nuevas necesidades y las nuevas tecnologías. Como ya hemos visto, en estos momentos podríamos citar como objetivos nuevos o recientes los siguientes:

1) Servir eficientemente los Data Warehouse.

2) Adaptarse al desarrollo orientado a objetos.

3) Incorporar el tiempo como un elemento de caracterización de la información.

4) Adaptarse al mundo de Internet.

 Para trabajar con nuestras BD, los SGBD necesitan conocer su estructura (qué entidades tipo habrá, qué atributos tendrán, etc.).

El esquema de la BD es un elemento fundamental de la arquitectura de un SGBD que permite independizar el SGBD de la BD; de este modo, se puede cambiar el diseño de la BD (su esquema) sin tener que hacer ningún cambio en el SGBD.

Anteriormente, ya hemos hablado de la distinción entre dos niveles de representación informática: el nivel lógico y el físico.

El nivel lógico nos oculta los detalles de cómo se almacenan los datos, cómo se mantienen y cómo se accede físicamente a ellos. En este nivel sólo se habla de entidades, atributos y reglas de integridad.

Por cuestiones de rendimiento, nos podrá interesar describir elementos de nivel físico como, por ejemplo, qué índices tendremos y qué características presentarán, cómo y dónde (en qué espacio físico) queremos que se agrupen físicamente los registros, de qué tamaño deben ser las páginas, etc.

En el periodo 1975-1982, ANSI intentaba establecer las bases para crear estándares en el campo de las BD. El comité conocido como ANSI/SPARC recomendó que la arquitectura de los SGBD previese tres niveles de descripción de la BD, no sólo dos*.

De este modo, de acuerdo con ANSI/SPARC, habría los tres niveles de esquemas que mencionamos a continuación:

a) En el nivel externo se sitúan las diferentes visiones lógicas que los procesos usuarios (programas de aplicación y usuarios directos) tendrán de las partes de

la BD que utilizarán. Estas visiones se denominan esquemas externos.

b) En el nivel conceptual hay una sola descripción lógica básica, única y global, que denominamos esquema conceptual, y que sirve de referencia para el resto de los esquemas.

c) En el nivel físico hay una sola descripción física, que denominamos esquema interno.

Figura 4

El esquema conceptual corresponde a las necesidades del conjunto de la empresa o del SI, por lo que se escribirá de forma centralizada durante el denominado diseño lógico de la BD.

Sin embargo, cada aplicación podrá tener su visión particular, y seguramente parcial, del esquema conceptual. Los usuarios (programas o usuarios directos) verán la BD mediante esquemas externos apropiados a sus necesidades. Estos esquemas se pueden considerar redefiniciones del esquema conceptual, con las partes y los términos que convengan para las necesidades de las aplicaciones (o grupos de aplicaciones). Algunos sistemas los denominan subesquemas.

Ejemplo de esquema externo

Imaginemos una BD que en el esquema conceptual tiene definida, entre muchas otras, una entidad alumno con los siguientes atributos: numatri, nombre, apellido, numDNI, direccion, fechanac, telefono. Sin embargo, nos puede interesar que unos determinados programas o usuarios vean la BD formada de acuerdo con un esquema externo que tenga definidas dos entidades, denominadas estudiante y persona.
a) La entidad estudiante podría tener definido el atributo numero-matricula (definido como derivable directamente de numatri), el atributo nombrepila (de nombre), el atributo apellido y

el atributo DNI (de numDNI).

b) La entidad persona podría tener el atributo DNI (obtenido de numDNI), el atributo nombre (formado por la concatenación de nombre y apellido), el atributo direccion y el atributo edad

(que deriva dinámicamente de fechanac).

El esquema de nivel interno responde a las cuestiones de rendimiento (espacio y tiempo) planteadas al hacer el diseño físico de la BD y al ajustarlo* posteriormente a las necesidades cambiantes.

De acuerdo con la arquitectura ANSI/SPARC, para crear una BD hace falta definir previamente su esquema conceptual, definir como mínimo un esquema externo y, de forma eventual, definir su esquema interno. Si este último esquema no se define, el mismo SGBD tendrá que decidir los detalles de la organización física. El SGBD se encargará de hacer las correspondencias (mappings) entre los tres niveles de esquemas.

Esquemas y niveles en los SGBD relacionales

En los SGBD relacionales (es decir, en el mundo de SQL) se utiliza una terminología ligeramente diferente. No se separan de forma clara tres niveles de descripción. Se habla de un solo esquema –schema–, pero en su interior se incluyen descripciones de los tres niveles. En el schema se describen los elementos de aquello que en la arquitectura ANSI/SPARC se denomina esquema conceptual (entidades tipo, atributos y restricciones) y las vistas –view–, que corresponden aproximadamente a los esquemas externos.

El modelo relacional en que está inspirado SQL se limita al mundo lógico. Por ello, el estándar ANSI-ISO de SQL no habla en absoluto del mundo físico o interno; lo deja en manos de los SGBD relacionales del mercado. Sin embargo, estos SGBD proporcionan la posibilidad de incluir dentro del schema descripciones de estructuras y características físicas (índice, tablespace, cluster, espacios para excesos, etc.).

En este subapartado veremos cómo la arquitectura de tres niveles que acabamos de presentar nos proporciona los dos tipos de independencia de los datos:la física y la lógica.

De acuerdo con la arquitectura ANSI/SPARC, habrá independencia física cuando los cambios en el esquema interno no afecten al esquema conceptual ni a los esquemas externos.

Figura 5

Es obvio que cuando cambiemos unos datos de un soporte a otro, o los cambiemos de lugar dentro de un soporte, no se verán afectados ni los programas de aplicación ni los usuarios directos, ya que no se modificará el esquema conceptual ni el externo. Sin embargo, tampoco tendrían que verse afectados si cambiásemos, por ejemplo, el método de acceso a unos registros determinados*, el formato o la codificación, etc. Ninguno de estos casos debería afectar al

mundo exterior, sino sólo a la BD física, el esquema interno, etc.

Si hay independencia física de los datos, lo único que variará al cambiar el esquema interno son las correspondencias entre el esquema conceptual y el interno. Obviamente, la mayoría de los cambios del esquema interno obligarán a rehacer la BD real (la física).

* Programas de aplicacióno usuarios directos.

Figura 6

Dados los dos niveles lógicos de la arquitectura ANSI/SPARC, diferenciaremos las dos situaciones siguientes:

1) Cambios en el esquema conceptual. Un cambio de este tipo no afectará a los esquemas externos que no hagan referencia a las entidades o a los atributos modificados.

2) Cambios en los esquemas externos. Efectuar cambios en un esquema externo afectará a los usuarios que utilicen los elementos modificados. Sin embargo, no debería afectar a los demás usuarios ni al esquema conceptual, y tampoco, en consecuencia, al esquema interno y a la BD física.

Usuarios no afectados por los cambios

Notad que no todos los cambios de elementos de un esquema externo afectarán a sus usuarios. Veamos un ejemplo de ello: antes hemos visto que cuando eliminábamos el atributo apellido del esquema conceptual, debíamos modificar el esquema externo donde definíamos nombre, porque allí estaba definido como concatenación de nombre y apellido. Pues bien, un programa que utilizase el atributo nombre no se vería afectado si modificásemos el esquema externo de modo que nombre fuese la concatenación de nombre y una cadena constante (por ejemplo, toda en blanco). Como resultado, habría desaparecido el apellido de nombre, sin que hubiera sido necesario modificar el programa.

Los SGBD actuales proporcionan bastante independencia lógica, pero menos de la que haría falta, ya que las exigencias de cambios constantes en el SI piden grados muy elevados de flexibilidad. Los sistemas de ficheros tradicionales, en cambio, no ofrecen ninguna independencia lógica.

Para entender el funcionamiento de un SGBD, a continuación veremos los principales pasos de la ejecución de una consulta sometida al SGBD por un programa de aplicación. Explicaremos las líneas generales del flujo de datos y de control entre el SGBD, los programas de usuario y la BD.

Recordad que el SGBD, con la ayuda del SO, lee páginas (bloques) de los soportes donde está almacenada la BD física, y las lleva a un área de buffers o memorias caché en la memoria principal. El SGBD pasa registros desde los buffers hacia el área de trabajo del mismo programa.

Supongamos que la consulta pide los datos del alumno que tiene un determinado DNI. Por lo tanto, la respuesta que el programa obtendrá será un solo registro y lo recibirá dentro de un área de trabajo propia*.

Figura 7

El proceso que se sigue es el siguiente:

a) Empieza con una llamada (1) del programa al SGBD, en la que se le envía la operación de consulta. El SGBD debe verificar que la sintaxis de la operación recibida sea correcta, que el usuario del programa esté autorizado a hacerla, etc. Para poder llevar a cabo todo esto, el SGBD se basa (2) en el esquema externo con el que trabaja el programa y en el esquema conceptual.

b) Si la consulta es válida, el SGBD determina, consultando el esquema interno (3), qué mecanismo

debe seguir para responderla. Ya sabemos que el programa usuario no dice nada respecto a cómo se debe hacer físicamente la consulta. Es el SGBD el que lo debe determinar. Casi siempre hay varias formas y diferentes caminos para responder a una consulta*. Supongamos que ha elegido aplicar un hashing al valor del DNI, que es el parámetro de la consulta, y el resultado es la dirección de la página donde se encuentra (entre muchos otros) el registro del alumno buscado.

c) Cuando ya se sabe cuál es la página, el SGBD comprobará (4) si por suerte esta página ya se encuentra en aquel momento en el área de los buffers (tal vez como resultado de una consulta anterior de este usuario o de otro). Si no está, el SGBD, con la ayuda del SO, la busca en disco y la carga en los buffers (5). Si ya está, se ahorra el acceso a disco.

d) Ahora, la página deseada ya está en la memoria principal. El SGBD extrae, de entre los distintos registros que la página puede contener, el registro buscado, e interpreta la codificación y el resultado según lo que diga el esquema interno.

e) El SGBD aplica a los datos las eventuales transformaciones lógicas que implica el esquema externo (tal vez cortando la dirección por la derecha) y las lleva al área de trabajo del programa (6).

f) A continuación, el SGBD retorna el control al programa (7) y da por terminada la ejecución de la consulta.

En primer lugar, presentaremos el concepto de relación de manera informal. Se puede obtener una buena idea intuitiva de lo que es una relación si la visualizamos como una tabla o un fichero. En la figura 1 se muestra la visualización tabular de una relación que contiene datos de empleados. Cada fila de la tabla contiene una colección de valores de datos relacionados entre sí; en nuestro ejemplo, son los datos correspondientes a un mismo empleado. La tabla tiene un nombre (EMPLEADOS) y también tiene un nombre cada una de sus columnas (DNI, nombre, apellido y sueldo). El nombre de la tabla y los de las columnas ayudan a entender el significado de los valores que contiene la tabla. Cada columna contiene valores de un cierto dominio; por ejemplo, la columna DNI contiene valores del dominio númerosDNI.

Figura1

Si definimos las relaciones de forma más precisa, nos daremos cuenta de que presentan algunas características importantes que, en la visión superficial que hemos presentado, quedan ocultas. Estas características son las que motivan que el concepto de relación sea totalmente diferente del de fichero, a pesar de que, a primera vista, relaciones y ficheros puedan parecer similares.

A continuación definimos formalmente las relaciones y otros conceptos que están vinculados a ellas, como por ejemplo dominio, esquema de relación, etc.

Los dominios pueden ser de dos tipos:

1) Dominios predefinidos, que corresponde a los tipos de datos que normalmente proporcionan los lenguajes de bases de datos, como por ejemplo los enteros, las cadenas de caracteres, los reales, etc.

2) Dominios definidos por el usuario, que pueden ser más específicos. Toda definición de un dominio debe constar, como mínimo, del nombre del dominio y de la descripción de los valores que forman parte de éste.

Si consideramos la representación tabular anterior (figura 1), el esquema correspondería a la cabecera de la tabla y la extensión correspondería al cuerpo:

Figura 2

Nombre y conjunto de atributos de la relación EMPLEADOS

Si tomamos como ejemplo la figura 1, el nombre de la relación es EMPLEADOS y el conjunto de atributos es {DNI, nombre, apellido, sueldo}.

Tomaremos la convención de denotar el esquema de la relación de la forma siguiente: R(A1, A2, ..., An), donde R es el nombre la relación y A1, A2, ..., An es una ordenación cualquiera de los atributos que pertenecen al conjunto {A1, A2, ..., An}.

Denotación del esquema de la relación EMPLEADOS

El esquema de la relación de la figura 1 se podría denotar, por ejemplo, como EMPLEADOS(DNI, nombre, apellido, sueldo), o también, EMPLEADOS(nombre, apellido, DNI, sueldo), porque cualquier ordenación de sus atributos se considera válida para denotar el esquema de una relación.

Dominio del atributo DNI

Según la figura 1, el atributo DNI corresponde al papel que ejerce el dominio númerosDNI en el esquema de la relación EMPLEADOS y, entonces, dominio(DNI) = númerosDNI. 

Conviene observar que cada atributo es único en un esquema de relación, porque no tiene sentido que un mismo dominio ejerza dos veces el mismo papel en un mismo esquema. Por consiguiente, no puede ocurrir que en un esquema de relación haya dos atributos con el mismo nombre. En cambio, sí que se puede repetir un nombre de atributo en relaciones diferentes. Los dominios de los atributos, por el contrario, no deben ser necesariamente todos diferentes en una relación.

Ejemplo de atributos diferentes con el mismo dominio 

Si tomamos como ejemplo el esquema de relación PERSONAS(DNI, nombre, apellido, telcasa, teltrabajo), los atributos telcasa y teltrabajo pueden tener el mismo dominio: dominio(telcasa)=

= teléfono y dominio(teltrabajo) = teléfono. 

En este caso, el dominio teléfono ejerce dos papeles diferentes en el esquema de relación: el de indicar el teléfono particular de una persona y el de indicar el del trabajo.

Para simplificar, tomaremos la convención de referirnos a una tupla ti = {<A1:vi1>, <A2:vi2>, ..., <An:vin>} que pertenece a la extensión del esquema denotado como R(A1, A2, ..., An), de la forma siguiente: ti = <vi1, vi2, ..., vin>.

Si denotamos el esquema de la relación representada en la figura 1 como EMPLEADOS(DNI, nombre, apellido, sueldo), el conjunto de tuplas de su extensión será el de la figura siguiente:

Figura 3

en una tupla ti = <vi1, vi2, ..., vin>, el valor vij es un valor nulo, entonces el valor del atributo Aj es desconocido para la tupla ti de la relación, o bien no es aplicable a esta tupla. 

Ejemplo de valor nulo

Podríamos tener un atributo telcasa en la relación EMPLEADOS y se podría dar el caso de que un empleado no tuviese teléfono en su casa, o bien que lo tuviese, pero no se conociese su número. En las dos situaciones, el valor del atributo telcasa para la tupla correspondiente al empleado sería el valor nulo. 

Grado de la relación EMPLEADOS 

El grado de la relación de esquema EMPLEADOS(DNI, nombre, apellido, sueldo), es 4. 

Cardinalidad de la relación EMPLEADOS 

Observando la figura 3 se deduce que la cardinalidad de la relación EMPLEADOS es 3.

A primera vista, relaciones y ficheros resultan similares. Los registros y los campos que forman los ficheros se parecen a las tuplas y a los atributos de las relaciones, respectivamente.

A pesar de esta similitud superficial, la visión formal de relación que hemos presentado establece algunas características de las relaciones que las hacen diferentes de los ficheros clásicos. A continuación describimos estas características: 

1) Atomicidad de los valores de los atributos: los valores de los atributos de una relación deben ser atómicos; es decir, no deben tener estructura interna. Esta característica proviene del hecho de que los atributos siempre deben tomar un valor de su dominio o bien un valor nulo, y de que se ha establecido que los valores de los dominios deben ser atómicos en el modelo relacional. 

El objetivo de la atomicidad de los valores es dar simplicidad y uniformidad al modelo relacional. 

2) No-repetición de las tuplas: en un fichero clásico puede ocurrir que dos de los registros sean exactamente iguales; es decir, que contengan los mismos datos. En el caso del modelo relacional, en cambio, no es posible que una relación contenga tuplas repetidas. Esta característica se deduce de la misma definición de la extensión de una relación. La extensión es un conjunto de tuplas y, en un conjunto, no puede haber elementos repetidos. 

3) No-ordenación de las tuplas: de la definición de la extensión de una relación como un conjunto de tuplas se deduce también que estas tuplas no estarán ordenadas, teniendo en cuenta que no es posible que haya una ordenación entre los elementos de un conjunto.

La finalidad de esta característica es conseguir que, mediante el modelo relacional, se puedan representar los hechos en un nivel abstracto que sea independiente de su estructura física de implementación. Más concretamente, aunque los SGBD relacionales deban proporcionar una implementación física que almacenará las tuplas de las relaciones en un orden concreto, esta ordenación no es visible si nos situamos en el nivel conceptual.

Ejemplo de no-ordenación de las tuplas

En una base de datos relacional, por ejemplo, no tiene sentido consultar la “primera tupla” de la relación EMPLEADOS. 

4) No-ordenación de los atributos: el esquema de una relación consta de un nombre de relación R y un conjunto de atributos {A1, A2, ..., An}. Así pues, no hay un orden entre los atributos de un esquema de relación, teniendo en cuenta que estos atributos forman un conjunto.

Como en el caso anterior, el objetivo de esta característica es representar los hechos en un nivel abstracto, independientemente de su implementación física. 

Ejemplo de no-ordenación de los atributos 

El esquema de relación EMPLEADOS(DNI, nombre, apellido, sueldo) denota el mismo esquema de relación que EMPLEADOS(nombre, apellido, DNI, sueldo).

... si se almacena información sobre los empleados de una empresa, es preciso tener la posibilidad de distinguir qué datos corresponden a cada uno de los diferentes empleados. Toda la información que contiene una base de datos debe poderse identificar de alguna forma. En el caso particular de las bases de datos que siguen el modelo relacional, para identificar los datos que la base de datos contiene, se pueden utilizar las claves candidatas de las relaciones. A continuación definimos qué se entiende por clave candidata, clave primaria y clave alternativa de una relación. Para hacerlo, será necesario definir el concepto de superclave. 

Una superclave de una relación de esquema R(A1, A2, ..., An) es un subconjunto de los atributos del esquema tal que no puede haber dos tuplas en la extensión de la relación que tengan la misma combinación de valores para los atributos del subconjunto.

Una superclave, por lo tanto, nos permite identificar todas las tuplas que contiene la relación. 

Algunas superclaves de la relación EMPLEADOS

En la relación de esquema EMPLEADOS(DNI, NSS, nombre, apellido, teléfono), algunas de las superclaves de la relación serían los siguientes subconjuntos de atributos: {DNI, NSS, nombre, apellido, teléfono}, {DNI, apellido}, {DNI} y {NSS}. 

Una clave candidata de una relación es una superclave C de la relación que cumple que ningún subconjunto propio de C es superclave.

Es decir, C cumple que la eliminación de cualquiera de sus atributos da un conjunto de atributos que no es superclave de la relación. Intuitivamente, una clave candidata permite identificar cualquier tupla de una relación, de manera que no sobre ningún atributo para hacer la identificación. 

Claves candidatas de EMPLEADOS 

En la relación de esquema EMPLEADOS(DNI, NSS, nombre, apellido, teléfono), sólo hay dos claves candidatas: {DNI} y {NSS}.

Habitualmente, una de las claves candidatas de una relación se designa clave primaria de la relación. La clave primaria es la clave candidata cuyos valores se utilizarán para identificar las tuplas de la relación.

 El diseñador de la base de datos es quien elige la clave primaria de entre las claves candidatas.

Las claves candidatas no elegidas como primaria se denominan claves alternativas.

Utilizaremos la convención de subrayar los atributos que forman parte de la clave primaria en el esquema de la relación. Así pues, R(A1, A2, ..., Ai, ..., An) indica que los atributos A1, A2, ..., Ai forman la clave primaria de R. 

Elección de la clave primaria de EMPLEADOS 

En la relación de esquema EMPLEADOS(DNI, NSS, nombre, apellido, teléfono), donde hay dos claves candidatas, {DNI} y {NSS}, se puede elegir como clave primaria {DNI}. Lo indicaremos subrayando el atributo DNI en el esquema de la relación EMPLEADOS(DNI, NSS, nombre, apellido, teléfono). En este caso, la clave {NSS} será una clave alternativa de EMPLEADOS. 

Es posible que una clave candidata o una clave primaria conste de más de un atributo. 

Clave primaria de la relación DESPACHOS 

En la relación de esquema DESPACHOS(edificio, número, superficie), la clave primaria está formada por los atributos edificio y número. En este caso, podrá ocurrir que dos despachos diferentes estén en el mismo edificio, o bien que tengan el mismo número, pero nunca pasará que tengan la misma combinación de valores para edificio y número.

Clave foránea

Hasta ahora hemos estudiado las relaciones de forma individual, pero debemos tener en cuenta que una base de datos relacional normalmente contiene más de una relación, para poder representar distintos tipos de hechos que suceden en el mundo real. Por ejemplo, podríamos tener una pequeña base de datos que contuviese dos relaciones: una denominada EMPLEADOS, que almacenaría datos de los empleados de una empresa, y otra con el nombre DESPACHOS, que almacenaría los datos de los despachos que tiene la empresa.

Debemos considerar también que entre los distintos hechos que se dan en el mundo real pueden existir lazos o vínculos. Por ejemplo, los empleados que trabajan para una empresa pueden estar vinculados con los despachos de la empresa, porque a cada empleado se le asigna un despacho concreto para trabajar.

En el modelo relacional, para reflejar este tipo de vínculos, tenemos la posibilidad de expresar conexiones entre las distintas tuplas de las relaciones. Por ejemplo, en la base de datos anterior, que tiene las relaciones EMPLEADOS y DESPACHOS, puede ser necesario conectar tuplas de EMPLEADOS con tuplas de DESPACHOS para indicar qué despacho tiene asignado cada empleado.

En ocasiones, incluso puede ser necesario reflejar lazos entre tuplas que pertenecen a una misma relación. Por ejemplo, en la misma base de datos anterior puede ser necesario conectar determinadas tuplas de EMPLEADOS con otras tuplas de EMPLEADOS para indicar, para cada empleado, quién actúa como su jefe. 

El mecanismo que proporcionan las bases de datos relacionales para conectar tuplas son las claves foráneas de las relaciones. Las claves foráneas permiten establecer conexiones entre las tuplas de las relaciones. Para hacer la conexión, una clave foránea tiene el conjunto de atributos de una relación que referencian la clave primaria de otra relación (o incluso de la misma relación).

 Claves foráneas de la relación EMPLEADOS 

En la figura siguiente, la relación EMPLEADOS(DNI, nombre, apellido, teléfono, DNIjefe, edificiodesp, númerodesp), tiene una clave foránea formada por los atributos edificiodesp y númerodesp que se refiere a la clave primaria de la relación DESPACHOS(edificio, número, superficie). Esta clave foránea indica, para cada empleado, el despacho donde trabaja. Además, el atributo DNIjefe es otra clave foránea que referencia la clave primaria de la misma relación EMPLEADOS, e indica, para cada empleado, quien es su jefe.

Las claves foráneas tienen por objetivo establecer una conexión con la clave primaria que referencian. Por lo tanto, los valores de una clave foránea deben estar presentes en la clave primaria correspondiente, o bien deben ser valores nulos. En caso contrario, la clave foránea representaría una referencia o conexión incorrecta. 

Ejemplo

En la relación de esquema EMPLEADOS(DNI, nombre, apellido, DNIjefe, edificiodesp, númerodesp), la clave foránea {edificiodesp, númerodesp} referencia la relación DESPACHOS(edificio, número, superficie). De este modo, se cumple que todos los valores que no son nulos de los atributos edificiodesp y númerodesp son valores que existen para los atributos edificio y número de DESPACHOS, tal y como se puede ver a continuación:

 • Relación DESPACHOS: 

DESPACHOS
edificio	número	superficie
Marina	120	10
Marina	122	15
Marina	230	20
Diagonal	120	10

• Relación EMPLEADOS 

EMPLEADOS
DNI	nombre	apellido	DNIjefe	edificiodesp	númerodesp
40.444.255	Juan	García	NULO	Marina	120
33.567.711	Marta	Roca	40.444.255	Marina	120
55.898.425	Carlos	Buendía	40.444.255	Diagonal	120
77.232.144	Elena	Pla	40.444.255	NULO	NULO

Supongamos que hubiese un empleado con los valores <55.555.555, María, Casagran, NULO, París, 400>. Puesto que no hay ningún despacho con los valores París y 400 para edificio y número, la tupla de este empleado hace una referencia incorrecta; es decir, indica un despacho para el empleado que, de hecho, no existe. 

Es preciso señalar que en la relación EMPLEADOS hay otra clave foránea, {DNIjefe}, que referencia la misma relación EMPLEADOS, y entonces se cumple que todos los valores que no son nulos del atributo DNIjefe son valores que existen para el atributo DNI de la misma relación EMPLEADOS.

 A continuación estableceremos de forma más precisa qué se entiende por clave foránea. 

Una clave foránea de una relación R es un subconjunto de atributos del esquema de la relación, que denominamos CF y que cumple las siguientes condiciones: 1)  Existe una relación S (S no debe ser necesariamente diferente de R)que tiene por clave primaria CP. 2)  Se cumple que, para toda tupla t de la extensión de R, los valores para CF de t son valores nulos o bien valores que coinciden con los valores para CP de alguna tupla s de S. Y entonces, se dice que la clave foránea CF referencia la clave primaria CP de la relación S, y también que la clave foránea CF referencia la relación S.

De la noción que hemos dado de clave foránea se pueden extraer varias consecuencias: 

1) Si una clave foránea CF referencia una clave primaria CP, el número de atributos de CF y de CP debe coincidir. 

Ejemplo de coincidencia del número de atributos de CF y CP 

En el ejemplo anterior, tanto la clave foránea {edificiodesp, númerodesp} como la clave primaria que referencia {edificio, número} tienen dos atributos. Si no sucediese así, no sería posible que los valores de CF existieran en CP. 

2) Por el mismo motivo, se puede establecer una correspondencia (en concreto, una biyección) entre los atributos de la clave foránea y los atributos de la clave primaria que referencia.

Ejemplo de correspondencia entre los atributos de CF y los de CP 

En el ejemplo anterior, a edificiodesp le corresponde el atributo edificio, y a númerodesp le corresponde el atributo número. 

3) También se deduce de la noción de clave foránea que los dominios de sus atributos deben coincidir con los dominios de los atributos correspondientes a la clave primaria que referencia. Esta coincidencia de dominios hace que sea posible que los valores de la clave foránea coincidan con valores de la clave primaria referenciada. 

Ejemplo de coincidencia de los dominios 

En el ejemplo anterior, se debe cumplir que dominio(edificiodesp) = dominio(edificio) y también que dominio(númerodesp) = dominio(número). 

Observad que, de hecho, esta condición se podría relajar, y se podría permitir que los dominios no fuesen exactamente iguales, sino que sólo fuesen, y de alguna forma que convendría precisar, dominios “compatibles”. Para simplificarlo, nosotros supondremos que los dominios deben ser iguales en todos los casos en que, según Date (2001), se aceptarían dominios “compatibles”. 

Ejemplo de atributo que forma parte de la clave primaria y de una clave foránea 

Puede suceder que algún atributo de una relación forme parte tanto de la clave primaria como de una clave foránea de la relación. Esto se da en las relaciones siguientes: EDIFICIOS(nombreedificio, dirección), y DESPACHOS(edificio, número, superficie), donde {edificio} es una clave foránea que referencia EDIFICIOS.

En este ejemplo, el atributo edificio forma parte tanto de la clave primaria como de la clave foránea de la relación DESPACHOS.

Hemos visto que una base de datos relacional consta de varias relaciones. Cada relación tiene varios atributos que toman valores de unos ciertos dominios; también tiene una clave primaria y puede tener una o más claves foráneas. Los lenguajes de los SGBD relacionales deben proporcionar la forma de definir todos estos elementos para crear una base de datos. 

Más adelante se verá con detalle la sintaxis y el significado de las sentencias de definición de la base de datos para el caso concreto del lenguaje SQL

La regla de integridad de unicidad está relacionada con la definición de clave primaria. Concretamente, establece que toda clave primaria que se elija para una relación no debe tener valores repetidos.

Ejemplo

Tenemos la siguiente relación:

DESPACHOS
edificio	número	superficie
Marina	120	10
Marina	122	15
Marina	230	20
Diagonal	120	10

En esta relación, dado que la clave primaria está formada por edificio y número, no hay ningún despacho que repita tanto edificio como número de otro despacho. Sin embargo, sí se repiten valores de edificio (por ejemplo, Marina); y también se repiten valores de número (120). A pesar de ello, el edificio y el número no se repiten nunca al mismo tiempo.

A continuación explicamos esta regla de forma más precisa.

Un SGBD relacional deberá garantizar el cumplimiento de esta regla de integridad en todas las inserciones, así como en todas las modificaciones que afecten a atributos que pertenecen a la clave primaria de la relación.

Ejemplo

Tenemos la siguiente relación:

DESPACHOS
edificio	número	superficie
Marina	120	10
Marina	122	15
Marina	230	20
Diagonal	120	10

En esta relación no se debería poder insertar la tupla <Diagonal, 120, 30>, ni modificar la tupla <Marina, 122, 15>, de modo que pasara a ser <Marina, 120, 15>.

La regla de integridad de unicidad está relacionada con la definición de clave primaria. Concretamente, establece que toda clave primaria que se elija para una relación no debe tener valores repetidos.

Ejemplo

Tenemos la siguiente relación:

DESPACHOS
edificio	número	superficie
Marina	120	10
Marina	122	15
Marina	230	20
Diagonal	120	10

En esta relación, dado que la clave primaria está formada por edificio y número, no hay ningún despacho que repita tanto edificio como número de otro despacho. Sin embargo, sí se repiten valores de edificio (por ejemplo, Marina); y también se repiten valores de número (120). A pesar de ello, el edificio y el número no se repiten nunca al mismo tiempo.

A continuación explicamos esta regla de forma más precisa.

Un SGBD relacional deberá garantizar el cumplimiento de esta regla de integridad en todas las inserciones, así como en todas las modificaciones que afecten a atributos que pertenecen a la clave primaria de la relación.

Ejemplo

Tenemos la siguiente relación:

DESPACHOS
edificio	número	superficie
Marina	120	10
Marina	122	15
Marina	230	20
Diagonal	120	10

En esta relación no se debería poder insertar la tupla <Diagonal, 120, 30>, ni modificar la tupla <Marina, 122, 15>, de modo que pasara a ser <Marina, 120, 15>.

 La regla de integridad de entidad de la clave primaria dispone que los atributos de la clave primaria de una relación no pueden tener valores nulos.

Ejemplo

Tenemos la siguiente relación:

En esta relación, puesto que la clave primaria está formada por edificio y número, no hay ningún despacho que tenga un valor nulo para edificio, ni tampoco para número.

Esta regla es necesaria para que los valores de las claves primarias puedan identificar las tuplas individuales de las relaciones. Si las claves primarias tuviesen valores nulos, es posible que algunas tuplas no se pudieran distinguir.

Ejemplo de clave primaria incorrecta con valores nulos

En el ejemplo anterior, si un despacho tuviese un valor nulo para edificio porque en un momento dado el nombre de este edificio no se conoce, por ejemplo <NULO, 120, 30>, la clave primaria no nos permitiría distinguirlo del despacho <Marina, 120, 10> ni del despacho <Diagonal, 120,10>. No podríamos estar seguros de que el valor desconocido de edificio no es ni Marina ni Diagonal.

A continuación definimos esta regla de forma más precisa.

Un SGBD relacional tendrá que garantizar el cumplimiento de esta regla de integridad en todas las inserciones y, también, en todas las modificaciones que afecten a atributos que pertenecen a la clave primaria de la relación.

Ejemplo

En la relación DESPACHOS anterior, no se debería insertar la tupla <Diagonal, NULO, 15>. Tampoco debería ser posible modificar la tupla <Marina, 120, 10> de modo que pasara a ser <NULO, 120, 10>.

La regla de integridad referencial está relacionada con el concepto de clave foránea. Concretamente, determina que todos los valores que toma una clave foránea deben ser valores nulos o valores que existen en la clave primaria que referencia.

Ejemplo

Si tenemos las siguientes relaciones:

•Relación DESPACHOS:

DESPACHOS
edificio	número	superficie
Marina	120	10
Marina	122	15
Marina	230	20
Diagonal	120	10

 •Relación EMPLEADOS:

EMPLEADOS
DNI	nombre	apellido	edificiodesp	númerodesp
40.444.255	Juan	García	Marina	120
33.567.711	Marta	Roca	Marina	120
55.898.425	Carlos	Buendía	Diagonal	120
77.232.144	Elena	Pla	NULO	NULO

donde edificiodesp y númerodesp de la relación EMPLEADOS forman una clave foránea que referencia la relación DESPACHOS. Debe ocurrir que los valores no nulos de edificiodesp y númerodesp de la relación EMPLEADOS estén en la relación DESPACHOS como valores de edificio y número. Por ejemplo, el empleado <40.444.255, Juan García, Marina, 120> tiene el valor Marina para edificiodesp, y el valor 120 para númerodesp, de modo que en la relación DESPA CHOS hay un despacho con valor Marina para edificio y con valor 120 para número.

La necesidad de la regla de integridad relacional proviene del hecho de que las claves foráneas tienen por objetivo establecer una conexión con la clave primaria que referencian. Si un valor de una clave foránea no estuviese presente en la clave primaria correspondiente, representaría una referencia o una conexión incorrecta.

Referencia incorrecta

Supongamos que en el ejemplo anterior hubiese un empleado con los valores <56.666.789, Pedro, López, Valencia, 325>. Ya que no hay un despacho con los valores Valencia y 325 para edificio y número, la tupla de este empleado hace una referencia incorrecta; es decir, indica un despacho para el empleado que, de hecho, no existe.

A continuación explicamos la regla de modo más preciso.

Un SGBD relacional tendrá que hacer cumplir esta regla de integridad. Deberá efectuar comprobaciones cuando se produzcan las siguientes operaciones:

a)  Inserciones en una relación que tenga una clave foránea.

b)  Modificaciones que afecten a atributos que pertenecen a la clave foránea de una relación.

c)  Borrados en relaciones referenciadas por otras relaciones.

d)  Modificaciones que afecten a atributos que pertenecen a la clave primaria de una relación referenciada por otra relación.

Ejemplo

Retomamos el ejemplo anterior, donde edificiodesp y númerodesp de la relación EMPLEADOS forman una clave foránea que referencia la relación DESPACHOS:

•Relación DESPACHOS:

DESPACHOS
edificio	número	superficie
Marina	120	10
Marina	122	15
Marina	230	20
Diagonal	120	10

 •Relación EMPLEADOS:

EMPLEADOS
DNI	nombre	apellido	edificiodesp	númerodesp
40.444.255	Juan	García	Marina	120
33.567.711	Marta /td>	Roca	Marina /td>	120
55.898.425	Carlos	Buendía	Diagonal	120
77.232.144	Elena	Pla	NULO	NULO

Las siguientes operaciones provocarían el incumplimiento de la regla de integridad referencial:

•   Inserción de <12.764.411, Jorge, Puig, Diagonal, 220> en EMPLEADOS.

•   Modificación   de   <40.444.255,   Juan,   García,   Marina,   120>   de   EMPLEADOS   por
<40.444.255, Juan, García, Marina, 400>.

•   Borrado de <Marina, 120, 10> de DESPACHOS.

•   Modificación de <Diagonal, 120, 10

Un SGBD relacional debe procurar que se cumplan las reglas de integridad del modelo.  Una forma habitual  de  mantener  estas reglas  consiste en  rechazar toda operación de actualización que deje la base de datos en un estado en el que alguna regla no se cumpla. En algunos casos, sin embargo, el SGBD tiene la posibilidad de aceptar la operación y efectuar acciones adicionales compensatorias, de modo que el estado que se obtenga satisfaga las reglas de integridad, a pesar de haber ejecutado la operación.

Esta última política se puede aplicar en las siguientes operaciones de actualización que violarían la regla de integridad:

a)  Borrado de una tupla que tiene una clave primaria referenciada.

b)  Modificación de los valores de los atributos de la clave primaria de una tupla que tiene una clave primaria referenciada.

En los casos anteriores, algunas de las políticas que se podrán aplicar serán las siguientes: restricción, actualización en cascada y anulación. A continuación explicamos el significado de las tres posibilidades mencionadas.

La regla de integridad de dominio está relacionada, como su nombre indica, con la noción de dominio. Esta regla establece dos condiciones.

Esta condición implica que todos los valores no nulos que contiene la base de datos para un determinado atributo deben ser del dominio declarado para dicho atributo.

Ejemplo

Si en la relación EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no podremos insertar, por ejemplo, ningún empleado que tenga por DNI el valor “Luis”, que no es un entero.

Recordemos que los dominios pueden ser de dos tipos: predefinidos o definidos por el usuario. Observad que los dominios definidos por el usuario resultan  muy  útiles,  porque  nos  permiten  determinar  de  forma  más  específica cuáles serán los valores admitidos por los atributos.

Ejemplo

Supongamos ahora que en la relación EMPLEADOS(DNI, nombre, apellido, edademp) hemos declarado que dominio(edademp) es el dominio definido por el usuario edad. Supongamos también que el dominio edad se ha definido como el conjunto de los enteros que están entre 16 y 65. En este caso, por ejemplo, no será posible insertar un empleado con un valor de 90 para edademp.

La segunda condición de la regla de integridad de dominio es más compleja, especialmente en el caso de dominios definidos por el usuario; los SGBD actuales no la soportan para estos últimos dominios. Por estos motivos sólo la presentaremos superficialmente.

Ejemplo

Analizaremos esta segunda condición de la regla de integridad de dominio con un ejemplo concreto. Si en la relación EMPLEADOS(DNI, nombre, apellido, edademp) se ha declarado que dominio(DNI) es el dominio predefinido de los enteros, entonces no se permitirá consultar todos aquellos empleados cuyo DNI sea igual a ‘Elena’ (DNI = ‘Elena’). El motivo es que no tiene sentido que el operador de comparación = se aplique entre un DNI que tiene por dominio los enteros, y el valor ‘Elena’, que es una serie de caracteres.

De este modo, el hecho de que los operadores que se pueden aplicar sobre los valores dependan del dominio de estos valores permite detectar errores que se podrían cometer cuando se consulta o se actualiza la base de datos. Los dominios definidos por el usuario son muy útiles, porque nos permitirán determinar de forma más específica cuáles serán los operadores que se podrán aplicar sobre los valores.

Ejemplo

Veamos otro ejemplo con dominios definidos por el usuario. Supongamos que en la conocida relación EMPLEADOS(DNI, nombre, apellido, edademp) se ha declarado que dominio(DNI) es el dominio definido por el usuario númerosDNI y que dominio(edademp) es el dominio definido por el usuario edad. Supongamos que númerosDNI corresponde a los enteros positivos y que edad corresponde a los enteros que están entre 16 y 65. En este caso, será incorrecto,por ejemplo, consultar los empleados que tienen el valor de DNI igual al valor de edademp. El motivo es que, aunque tanto los valores de DNI como los de edademp sean enteros, sus dominios son diferentes; por ello, según el significado que el usuario les da, no tiene sentido compararlos.

Sin embargo, los actuales SGBD relacionales no dan apoyo a la segunda condición de la regla de integridad de dominio para dominios definidos por el usuario. Si se quisiera hacer, sería necesario que el diseñador tuviese alguna forma de especificar, para cada operador que se desease utilizar, para qué combinaciones de dominios definidos por el usuario tiene sentido que se aplique.

Las operaciones conjuntistas del álgebra relacional son la unión, la intersección, la diferencia y el producto cartesiano.

Las operaciones específicamente relacionales son la selección, la proyección y la combinación.

Ejemplo de utilización de secuencias de operaciones

Para obtener el nombre y el apellido de los empleados, tanto de administración como de producción, es necesario hacer una unión de EMPLEADOS_ADM yEMPLEADOS_PROD, y después  hacer  una  proyección  sobre  los  atributos  nombre  y  apellido.  La operación  se  puede expresar de las formas siguientes:

a) Se puede utilizar una sola expresión:

R := (EMPLEADOS_ADM EMPLEADOS_PROD) [nombre, apellido].

b) O bien podemos expresarlo en dos pasos:

•   EMPS := EMPLEADOS_ADMEMPLEADOS_PROD;

•   R := EMPS[nombre, apellido]

En los casos en que una consulta requiere efectuar muchas operaciones, resulta más sencilla la segunda alternativa, porque evita expresiones complejas.

Otros ejemplos de consultas formuladas con secuencias de operaciones

Veamos algunos ejemplos de consultas en la base de datos formuladas con secuencias de operaciones del álgebra relacional.

1) Para obtener el nombre del edificio y el número de los despachos situados en edificios en los que la superficie media de estos despachos es mayor que 12, podemos utilizar la siguiente secuencia de operaciones:

•   A := EDIFICIOS_EMP(supmediadesp > 12);
•   B := DESPACHOS * A;
•   R := B[edificio, número]

2) Supongamos ahora que se desea obtener el nombre y el apellido de todos los empleados
(tanto de administración como de producción) que están asignados al despacho 120 del edificio Marina. En este caso, podemos utilizar la siguiente secuencia:

•   A := EMPLEADOS_ADM ? EMPLEADOS_PROD;
•   B := A(edificiodesp = Marina y númerodesp = 120);
•   R := B[nombre, apellido].

3) Si queremos consultar el nombre del edificio y el número de los despachos que ningún empleado de administración tiene asignado, podemos utilizar esta secuencia:

•   A := DESPACHOS [edificio, número];
•   B := EMPLEADOS_ADM[edificiodesp, númerodesp];
•   R := A – B.

4) Para obtener el DNI, el nombre y el apellido de todos los empleados de administración que tienen despacho, junto con la superficie de su despacho, podemos hacer lo siguiente:

•   A[DNI, nombre, apellido, edificio, número] := EMPLEADOS_ADM[DNI, nombre, apellido, edificiodesp, númerodesp];
•   B := A * DESPACHOS;
•   R := B[DNI, nombre, apellido, superficie].

Para finalizar el tema del álgebra relacional, analizaremos algunas extensiones útiles de la combinación.

Las combinaciones que se han descrito obtienen las tuplas del producto cartesiano de dos relaciones que satisfacen una condición de combinación. Las tuplas de una de las dos relaciones que no tienen en la otra relación una tupla como mínimo con la cual, una vez concatenadas, satisfagan la condición de combinación, no aparecen en el resultado de la combinación, y podríamos decir que sus datos se pierden.

Por ejemplo, si hacemos la siguiente combinación natural (con una redenominación previa): D(edificiodesp, númerodesp, superficie) := DESPACHOS (edificio, número, superficie),

R := EMPLEADOS_PROD * D.

Puesto que se trata de una combinación natural, se considera que la condición de combinación es edificio = edificio y número = número, y la relación R resultante será:

Notad que en esta relación R no están los empleados de producción que no tienen despacho asignado (con valores nulos en edificiodesp y númerodesp), y tampoco los despachos que no tienen ningún empleado de producción, porque no cumplen la condición de combinación.

Conviene destacar que las tuplas que tienen un valor nulo para alguno de los atributos que figuran en la condición de combinación se pierden siempre, porque en estos casos la condición de combinación siempre se evalúa a falso.

En algunos casos, puede interesar hacer combinaciones de los datos de dos relaciones sin que haya pérdida de datos de las relaciones de partida. Entonces,
se utilizan las combinaciones externas.

Estas extensiones también se aplican al caso de la combinación natural entre dos relaciones, T * S, concretamente: 

a)  La combinación natural externa izquierda entre dos relaciones T y S, que
se indica como T *_[ S, conserva en el resultado todas las tuplas de la relación T.

b)  La combinación natural externa derecha entre dos relaciones T y S, que se indica como T *_D S, conserva en el resultado todas las tuplas de la relación S.

c)  Finalmente, la combinación natural externa plena entre dos relaciones T y S, que se indica como T *_P S, conserva en el resultado todas las tuplas de T y todas las tuplas de S.

Las tuplas de una relación T que se conservan en el resultado R de una combinación externa con otra relación S, a pesar de que no satisfacen la condición de combinación, tienen valores nulos en el resultado R para todos los atributos que provienen de la relación S.

Ejemplos de combinaciones naturales externas

1) Si hacemos la siguiente combinación natural derecha (con una redenominación previa): D(edificiodesp, númerodesp, superficie) := DESPACHOS (edificio, número, superficie),

R := EMPLADOS_PROD *_D D,

la relación R resultante será:

Ahora obtenemos todos los despachos en la relación resultante, tanto si tienen un empleado de producción asignado como si no. Notad que los atributos DNI, nombre y apellido para los despachos que no tienen empleado reciben valores nulos.

2) Si hacemos la siguiente combinación natural izquierda (con una redenominación previa): D(edificiodesp, númerodesp, superficie) := DESPACHOS(edificio, número, superficie),

R := EMPLEADOS_PROD *^[ D,

entonces la relación R resultante será:

Esta combinación externa nos permite obtener en la relación resultante a todos los empleados de producción, tanto si tienen despacho como si no. Observad que el atributo superficie para los empleados que no tienen despacho contiene un valor nulo.

3) Finalmente, si hacemos la siguiente combinación natural plena (con una redenominación previa):

D(edificiodesp, númerodesp, superficie) := DESPACHOS(edificio, número, superficie),

R:= EMPLEADOS_PROD *_P D,

entonces la relación R resultante será:

En este caso, en la relación resultante obtenemos a todos los empleados de producción y también todos los despachos.

El estándar SQL92 no dispone de ninguna sentencia de creación de bases de datos. La idea es que una base de datos no es más que un conjunto de tablas y, por lo tanto, las sentencias que nos ofrece el SQL92 se concentran en la creación, la modificación y el borrado de estas tablas.

En cambio, disponemos de una sentencia más potente que la de creación de bases de datos: la sentencia de creación de esquemas denominada CREATE SCHEMA. Con la creación de esquemas podemos agrupar un conjunto de elementos de la base de datos que son propiedad de un usuario. La sintaxis de esta sentencia es la que tenéis a continuación:

La nomenclatura utilizada en la sentencia es la siguiente:

•    Las palabras en negrita son palabras reservadas del lenguaje:

•    La notación [...] quiere decir que lo que hay entre los corchetes se podría poner o no.

•    La notación {A|  ... |B} quiere decir que tenemos que elegir entre todas las opciones que hay entre las llaves, pero debemos poner una obligatoriamente.

La sentencia de creación de esquemas hace que varias tablas (lista_de_ele- mentos_del_esquema)  se  puedan  agrupar  bajo  un  mismo  nombre  (nom- bre_esquema) y que tengan un propietario (usuario). Aunque todos los parámetros de la sentencia CREATE SCHEMA son opcionales, como mínimo se debe dar o bien el nombre del esquema, o bien el nombre del usuario propietario de la base de datos. Si sólo especificamos el usuario, éste será el nombre del esquema.

La creación de esquemas puede hacer mucho más que agrupar tablas, porque lista_de_elementos_del_esquema puede, además de tablas, ser también dominios, vistas, privilegios y restricciones, entre otras cosas.

Para borrar una base de datos encontramos el mismo problema que para crearla. El estándar SQL92 sólo nos ofrece la sentencia de borrado de esquemas DROP SCHEMA, que presenta la siguiente sintaxis:

Donde tenemos lo siguiente:

•    La opción de borrado de esquemas RESTRICT hace que el esquema sólo se pueda borrar si no contiene ningún elemento.

•    La opción CASCADE borra el esquema aunque no esté completamente vacío.

Como ya hemos visto, la estructura de almacenamiento de los datos del modelo relacional son las tablas. Para crear una tabla, es necesario utilizar la sentencia CREATE TABLE. Veamos su formato:

Donde definición_columna es:

El proceso que hay que seguir para crear una tabla es el siguiente:

1)  Lo primero que tenemos que hacer es decidir qué nombre queremos poner a la tabla (nombre_tabla).

2)  Después, iremos dando el nombre de cada uno de los atributos que formarán las columnas de la tabla (nombre_columna).

3)  A cada una de las columnas le asignaremos un tipo de datos predefinido o bien un dominio definido por el usuario. También podremos dar definiciones por defecto y restricciones de columna.

4)  Una vez definidas las columnas, sólo nos quedará dar las restricciones de tabla.

Para modificar una tabla es preciso utilizar la sentencia ALTER TABLE. Veamos su formato:

En este caso, tenemos que:

•    acción_modificar_columna puede ser:

•    acción_modif_restricción_tabla puede ser:

Si queremos modificar una tabla es que queremos realizar una de las siguientes
operaciones:

1)  Añadirle una columna (ADD columna).

2)  Modificar las definiciones por defecto de la columna (ALTER columna).

3)  Borrar la columna (DROP columna).

4)  Añadir alguna nueva restricción de tabla (ADD restricción).

5)  Borrar alguna restricción de tabla (DROPCONSTRAINT restricción). Para borrar una tabla es preciso utilizar la sentencia DROP TABLE:

En este caso tenemos que:

•    Si utilizamos la opción RESTRICT, la tabla no se borrará si está referenciada, por ejemplo, por alguna vista.

•    Si usamos la opción CASCADE, todo lo que referencie a la tabla se borrará con ésta.

Como hemos observado, la arquitectura ANSI/SPARC distingue tres niveles, que se describen en el esquema conceptual, el esquema interno y los esquemas externos. Hasta ahora, mientras creábamos las tablas de la base de datos, íbamos describiendo el esquema conceptual. Para describir los diferentes esquemas externos utilizamos el concepto de vista del SQL.

Para crear una vista es necesario utilizar la sentencia CREATE VIEW. Veamos su formato:

Lo primero que tenemos que hacer para crear una vista es decidir qué nombre le queremos poner (nombre_vista). Si queremos cambiar el nombre de las columnas, o bien poner nombre a alguna que en principio no tenía, lo pode- mos hacer en lista_columnas. Y ya sólo nos quedará definir la consulta que formará nuestra vista.

Las vistas no existen realmente como un conjunto de valores almacenados en la base de datos, sino que son tablas ficticias, denominadas derivadas (no materializadas). Se construyen a partir de tablas reales (materializadas) almacenadas en la base de datos, y conocidas con el nombre de tablas básicas (o tablas de base). La no-existencia real de las vistas hace que puedan ser actualizables o no.

Creación de una vista en BDUOC

Creamos una vista sobre la base de datos BDUOC que nos dé para cada cliente el número de proyectos que tiene encargados el cliente en cuestión.

Si tuviésemos las siguientes extensiones:

•   Tabla clientes:

•   Tabla proyectos:

Y mirásemos la extensión de la vista proyectos_por_clientes, veríamos lo que encontramos en el margen.

En las vistas, además de hacer consultas, podemos insertar, modificar y borrar filas.

Actualización de vistas en BDUOC

Si alguien insertase en la vista proyectos_por_cliente, los valores para un nuevo cliente 60 con tres proyectos encargados, encontraríamos que estos tres proyectos tendrían que figurar realmente en la tabla proyectos y, por lo tanto, el SGBD los debería insertar con la información que tenemos, que es prácticamente inexistente. Veamos gráficamente cómo quedarían las tablas después de esta hipotética actualización, que no llegaremos a hacer nunca, ya que iría en contra de la teoría del modelo relacional:

•   Tabla clientes:

•   Tabla proyectos: 

El SGBD no puede actualizar la tabla básica clientes si sólo sabe la clave primaria, y todavía menos la tabla básica proyectos sin la clave primaria; por lo tanto, esta vista no sería actualizable.

En cambio, si definimos una vista para saber los clientes que tenemos en Barcelona o en Girona, haríamos:

Si queremos asegurarnos de que se cumpla la condición de la cláusula WHERE, debemos poner la opción WHITH CHECK OPTION. Si no lo hiciésemos, podría ocurrir que alguien incluyese en la vista clientes_Barcelona_Girona a un cliente nuevo con el código 70, de nombre JMB, con el NIF 36.788.224-C, la dirección en NULL, la ciudad Lleida y el teléfono NULL.

Si consultásemos la extensión de la vista clientes_Barcelona_Girona, veríamos:

Esta vista sí podría ser actualizable. Podríamos insertar un nuevo cliente con código 50, de nombre CEA, con el NIF 38.226.777-D, con la dirección París 44, la ciudad Barcelona y el teléfono 93.422.60.77. Después de esta actualización, en la tabla básica clientes encontraríamos, efectivamente:

Para borrar una vista es preciso utilizar la sentencia DROP VIEW, que presenta el formato:

 Si utilizamos la opción RESTRICT, la vista no se borrará si está referenciada, por ejemplo, por otra vista. En cambio, si ponemos la opción CASCADE, todo lo que referencie a la vista se borrará con ésta.

Borrar una vista en BDUOC

Para borrar la vista clientes_Barcelona_Girona, haríamos lo siguiente:

Veamos cómo se crearía la base de datos BDUOC, utilizando, por ejemplo, un SGBD relacional que disponga de la sentencia CREATE DATABASE:

Al crear una tabla vemos que muchas restricciones se pueden imponer de dos formas: como restricciones de columna o como restricciones de tabla. Por ejem- plo, cuando queremos decir cuál es la clave primaria de una tabla, tenemos las dos posibilidades. Esto se debe a la flexibilidad del SQL:

•    En el caso de que la restricción haga referencia a un solo atributo, podemos elegir la posibilidad que más nos guste.

•    En el caso de la tabla departamentos, tenemos que elegir por fuerza la op- ción de restricciones de tabla, porque la clave primaria está compuesta por más de un atributo.

En general, lo pondremos todo como restricciones de tabla, excepto NOT NULL y CHECK cuando haga referencia a una sola columna.

Antes de poder consultar los datos de una base de datos, es preciso introducirlos con la sentencia INSERT INTO VALUES, que tiene el formato:

Los valores v1, v2, ..., vn se deben corresponder exactamente con las columnas que hemos dicho que tendríamos con el CREATE TABLE y deben estar en el mismo orden, a menos que las volvamos a poner a continuación del nombre de la tabla. En este último caso, los valores se deben disponer de forma coherente con el nuevo orden que hemos impuesto. Podría darse el caso de que quisiéramos que algunos valores para insertar fuesen valores por omisión, definidos previamente con la opción DEFAULT. Entonces pondríamos la palabra reservada DEFAULT. Si se trata de introducir valores nulos, también podemos utilizar la palabra reservada NULL.

Inserción de una fila en BDUOC

La forma de insertar a un cliente en la tabla clientes de la base de datos de BDUOC es:

o bien:

Para borrar valores de algunas filas de una tabla podemos utilizar la sentencia DELETE FROM WHERE. Su formato es el siguiente:

En cambio, si lo que quisiéramos conseguir es borrar todas las filas de una tabla, entonces sólo tendríamos que poner la sentencia DELETE FROM, sin WHERE. 

Borrar todas las filas de una tabla en BDUOC

Podemos dejar la tabla proyectos sin ninguna fila:

En nuestra base de datos, borrar los proyectos del cliente 2 se haría de la forma que mostramos a continuación:

Si quisiéramos modificar los valores de algunas filas de una tabla, tendríamos que utilizar la sentencia UPDATE SET WHERE. A continuación presentamos su formato:

 Modificación de los valores de algunas filas en BDUOC

Supongamos que queremos incrementar el sueldo de todos los empleados del proyecto 2 en 1.000 euros. La modificación a ejecutar sería:

Antes de empezar a hacer consultas a la base de datos BDUOC, habremos introducido unas cuantas filas en sus tablas con la sentencia INSERT INTO. De esta forma, podremos ver reflejado el resultado de las consultas que iremos haciendo, a partir de este momento, sobre cada extensión; esto lo podemos observar en las tablas correspondientes a cada extensión, que presentamos a continuación:

•    Tabla departamentos:  

•    Tabla clientes:

•    Tabla empleados:

•    Tabla proyectos

Para hacer consultas sobre una tabla con el SQL es preciso utilizar la sentencia SELECT FROM, que tiene el siguiente formato: 

La opción AS nos permite renombrar las columnas que queremos seleccionar o las tablas que queremos consultar que en este caso, es sólo una. Dicho de otro modo, nos permite la definición de alias. Fijémonos en que la palabra clave AS es opcional, y es bastante habitual poner sólo un espacio en blanco en lugar de toda la palabra.

 Consultas a BDUOC

A continuación presentamos un ejemplo de consulta a la base de datos BDUOC para conocer todos los datos que aparece en la tabla clientes: 

El * después de SELECT indicaque queremos ver todos los atributos que aparecen en la tabla.

La respuesta a esta consulta sería:

Si hubiésemos querido ver sólo el código, el nombre, la dirección y la ciudad, habríamos hecho:

Y habríamos obtenido la respuesta siguiente:

 Con la sentencia SELECT FROM podemos seleccionar columnas de una tabla, pero para seleccionar filas de una tabla es preciso añadirle la cláusula WHERE. El formato es:

La cláusula WHERE nos permite obtener las filas que cumplen la condición especificada en la consulta.

Consultas a BDUOC seleccionando filas

Veamos un ejemplo en el que pedimos “los códigos de los empleados que trabajan en el proyecto número 4”:

La respuesta a esta consulta sería la que podéis ver en el margen. 

Para definir las condiciones en la cláusula WHERE, podemos utilizar alguno de los operadores de los que dispone el SQL, que son los siguientes:

 Si queremos que en una consulta nos aparezcan las filas resultantes sin repeticiones, es preciso poner la palabra clave DISTINCT inmediatamente después de SELECT. También podríamos explicitar que lo queremos todo, incluso con repeticiones, poniendo ALL (opción por defecto) en lugar de DISTINCT. El formato de DISTINCT es:

Consulta a BDUOC seleccionando filas sin repeticiones

Por ejemplo, si quisiéramos ver qué sueldos se están pagando en nuestra empresa, podríamos hacer:

La respuesta a esta consulta, sin repeticiones, sería la que aparece en el margen.

La mayoría de las transacciones se inician de forma implícita al utilizar alguna sentencia  que  empieza  con  CREATE, ALTER, DROP, SET, DECLARE,  GRANT o REVOKE, aunque existe la sentencia SQL para iniciar transacciones, que es la siguiente:

Si queremos actualizar la base de datos utilizaremos la opción READ WRITE, y si no la queremos actualizar, elegiremos la opción READ ONLY.

Sin embargo, en cambio, una transacción siempre debe acabar explícitamente con alguna de las sentencias siguientes:

La diferencia entre COMMIT y ROLLBACK es que mientras la sentencia COMMIT confirma todos los cambios producidos contra la BD durante la ejecución de la transacción, la sentencia ROLLBACK deshace todos los cambios que se hayan producido en la base de datos y la deja como estaba antes del inicio de nuestra transacción.

La palabra reservada WORK sólo sirve para aclarar lo que hace la sentencia, y es totalmente opcional.

Ejemplo de transacción

A continuación proponemos un ejemplo de transacción en el que se quiere disminuir el sueldo de los empleados que han trabajado en el proyecto 3 en 1.000 euros. y aumentar el sueldo de los empleados que han trabajado en el proyecto 1 también en 1.000 euros.

Todos los privilegios sobre la base de datos los tiene su propietario, pero no es el único que accede a ésta. Por este motivo, el SQL nos ofrece sentencias para autorizar y desautorizar a otros usuarios.

1)  Autorizaciones

Para autorizar, el SQL dispone de la siguiente sentencia:

Donde tenemos que:

a)  privilegios puede ser:

•    ALL PRIVILEGES: todos los privilegios sobre el objeto especificado.

•    USAGE: utilización del objeto especificado; en este caso el dominio.

•    SELECT: consultas.

•    INSERT [(columnas)]: inserciones. Se puede concretar de qué columnas.

•    UPDATE [(columnas)]: modificaciones. Se puede concretar de qué columnas.

•    DELETE: borrados.

•    REFERENCES [(columna)]: referencia del objeto en restricciones de integridad. Se puede concretar de qué columnas.

b)  Objeto debe ser:

•    DOMAIN: dominio

•    TABLE: tabla.

•    Vista.

c)  Usuarios puede ser todo el mundo: PUBLIC, o bien una lista de los identificadores de los usuarios que queremos autorizar.

d)  La opción WITH GRANT OPTION permite que el usuario que autoricemos pueda, a su vez, autorizar a otros usuarios a acceder al objeto con los mismos privilegios con los que ha sido autorizado.

2)  Desautorizaciones

Para desautorizar, el SQL dispone de la siguiente sentencia:

Donde tenemos que:

a)  privilegios, objeto y usuarios son los mismos que para la sentencia GRANT.

b)  La opción GRANT OPTION FOR se utilizaría en el caso de que quisiéramos eliminar el derecho a autorizar (WITH GRANT OPTION).

c)  Si un usuario al que hemos autorizado ha autorizado a su vez a otros, que al mismo tiempo pueden haber hecho más autorizaciones, la opción CASCADE hace que queden desautorizados todos a la vez.

d)  La opción RESTRICT no nos permite desautorizar a un usuario si éste ha autorizado a otros.

Para crear y manipular una base de datos relacional necesitamos SQL. Además, si la tarea que queremos hacer requiere el poder de procesamiento de un lenguaje de programación como Java, C, Cobol, Fortran, Pascal, etc., podemos utilizar el SQL hospedado en el lenguaje de programación elegido. De este modo, podemos utilizar las sentencias del SQL dentro de nuestras aplicaciones, poniendo siempre delante la palabra reservada EXEC SQL*.

Para poder compilar la mezcla de llamadas de SQL y sentencias de programación, antes tenemos que utilizar un precompilador. Un precompilador es una herramienta que separa las sentencias del SQL y las sentencias de programación. Allá donde en el programa fuente haya una sentencia de acceso a la base de datos, se debe insertar una llamada a la interfaz del SGBD. El programa fuente resultante de la precompilación ya está únicamente en el lenguaje de programación, preparado para ser compilado, montado y ejecutado.

En  la  figura  que  encontraréis  en  la  página  siguiente  podéis  observar  este funcionamiento.

Todas las sentencias de definición, manipulación y control que hemos visto para el SQL se pueden utilizar en el SQL hospedado, pero precedidas de la cláusula EXEC SQL. Sólo habrá una excepción: cuando el resultado de una sentencia  SQL obtenga más  de  una fila o  haga  referencia también a  más de  una, deberemos trabajar con el concepto de cursor.

Un cursor se tiene que haber declarado antes de su utilización (EXEC SQL DECLARE nombre_cursor CURSOR FOR). Para utilizarlo, se debe abrir (EXEC SQL OPEN nombre_cursor),  ir  tomando  los  datos  uno  a  uno,  tratarlos  (EXEC SQL FETCH nombre_cursor INTO),  y  finalmente,  cerrarlo  (EXEC SQL CLOSE nombre_cursor).

Las SQL/CLI (SQL/Call-Level Interface), denominadas de forma abreviada CLI, permiten que aplicaciones desarrolladas en un cierto lenguaje de programación (con sólo las herramientas disponibles para este lenguaje y sin el uso de un precompilador) puedan incluir sentencias SQL mediante llamadas a librerías. Estas sentencias SQL se deben interpretar en tiempo de ejecución del programa, a diferencia del SQL hospedado, que requería el uso de un precompilador.

La interfaz ODBC (Open Database Connectivity) define una librería de funciones que permite a las aplicaciones acceder al SGBD utilizando el SQL. Las rutinas SQL/CLI están fuertemente basadas en las características de la interfaz ODBC, y gracias al trabajo desarrollado por SAG-X/Open (SQL Access Group-X/Open), fueron añadidas al estándar ANSI/ISO SQL92 en 1995.

Las SQL/CLI son simplemente rutinas que llaman al SGBD para interpretar las sentencias SQL que pide la aplicación. Desde el punto de vista del SGBD, las SQL/CLI se pueden considerar, simplemente, como otras aplicaciones.

1.
SELECT apellido_empl, nombre_empl, codigo_empl FROM empleados ORDER BY apellido_empl DESC, nombre_empl DESC;

2.

Con el SQL92 introductorio, la solución sería:
SELECT p.codigo_proyec, p.nombre_proyec FROM proyectos p, clientes c WHERE c.ciudad = ‘Barcelona’ and c.codigo_cli = p.codigo_cliente;
Con el SQL92 intermedio o con el completo, la solución sería:
SELECT p.codigo_proyec, p.nombre_proyec FROM proyectos p JOIN clientes c ON c.codigo_cli = p.codigo_cliente WHERE c.ciudad = ‘Barcelona’;

3.
SELECT DISTINCT e.nombre_dep, e.ciudad_dep FROM empleados e WHERE e.num_proyec IN (3,4);

4.

Con el SQL92 introductorio, la solución sería:
SELECT e.codigo_empl, p.nombre_proyec FROM empleados e, proyectos p WHERE e.sueldo BETWEEN 5.0E+4 AND 8.0E+4 and e. num_proyec = p.codigo_proyec;

Con el SQL92 intermedio o con el completo, la solución sería:
SELECT e.codigo_empl, p.nombre_proyec FROM empleados e JOIN proyectos p ON e.num_proyec = p.codigo_proyec WHERE e.sueldo BETWEEN 5.0E+4 AND 8.0E+4;

5.

Con el SQL92 introductorio, la solución sería:
SELECT DISTINCT d.* FROM departamentos d, empleados e, proyectos p WHERE p. nombre_proyec = ‘GESCOM’ and d.nombre_dep = e.nombre_dep AND d.ciudad_dep = e.ciudad_dep and e. num_proyec = p.codigo_proyec;

Con el SQL92 intermedio o con el completo, la solución sería:
SELECT DISTINCT d.nombre_dep, d.ciudad_dep, d.telefono FROM (departamentos dNATURAL JOIN empleados e) JOIN proyectos p ON e.num_proyec = p.codigo_proyec WHERE p.nombre_proyec = ‘GESCOM’;

6.

Con el SQL92 introductorio, la solución sería:
SELECT e.codigo_empl, e.nombre_empl, e.apellido_empl FROM proyectos p, empleados e WHERE e.num_proyec = p.codigo_proyec and p.precio = (SELECT MAX(p1. precio)                                                     FROM proyectos p1);

Con el SQL92 intermedio o con el completo, la solución sería:
SELECT e.codigo_empl, e.nombre_empl, e.apellido_empl FROM empleados e JOIN proyectos p ON e.num_proyec = p.codigo_proyec WHERE p.precio = (SELECT MAX(p1.precio)                   FROM proyectos p1);

7.
SELECT nombre_dep, ciudad_dep, MAX(sueldo) AS sueldo_maximo FROM empleados GROUP BY nombre_dep, ciudad_dep;

8.

Con el SQL92 introductorio, la solución sería:
SELECT c.codigo_cli, c.nombre_cli FROM proyectos p, clientes c WHERE c.codigo_cli = p.codigo_cliente GROUP BY c.codigo_cli, c.nombre_cli HAVING COUNT(*) > 1;

Con el SQL92 intermedio o con el completo, la solución sería:
SELECT c.codigo_cli, c.nombre_cli FROM proyectos p JOIN clientes c ON c.codigo_cliente = p.codigo_cliente GROUP BY c.codigo_cli, c.nombre cli HAVING COUNT(*) > 1;

9.

Con el SQL92 introductorio, la solución sería:
SELECT p.codigo_proyec, p.nombre_proyec FROM proyectos p, empleados e WHERE e.num_proyec = p.codigo_proyec GROUP BY p.codigo_proyec, p.nombre_proyec HAVING MIN(e.sueldo) > 3.0E+4;

Con el SQL92 intermedio o con el completo, la solución sería:
SELECT p.codigo_proyec, p.nombre_proyec FROM empleados e JOIN proyectos p ON e.num_proyec = p.codigo_proyec GROUP BY p.codigo_proyec, p.nombre_proyec HAVING MIN(e.sueldo)>3.0E+4;

10.

SELECT d.nombre_dep, d.ciudad_dep FROM departamentos d WHERE NOT EXISTS (SELECT *                   FROM empleados e                   WHERE e.nombre_dep = d.nombre_dep AND                   e.ciudad_dep = d.ciudad_dep);
o bien:
SELECT nombre_dep, ciudad_dep FROM departamentos EXCEPT SELECT nombre_dep, ciudad_dep FROM empleados;

El diseño de una base de datos no es un proceso sencillo. Habitualmente, la complejidad de la información y la cantidad de requisitos de los sistemas de información hacen que sea complicado. Por este motivo, cuando se diseñan bases de datos es interesante aplicar la vieja estrategia de dividir para vencer.

Por lo tanto, conviene descomponer el proceso del diseño en varias etapas; en cada una se obtiene un resultado intermedio que sirve de punto de partida de la etapa siguiente, y en la última etapa se obtiene el resultado deseado. De este modo no hace falta resolver de golpe toda la problemática que plantea el diseño, sino que en cada etapa se afronta un solo tipo de subproblema. Así se divide el problema y, al mismo tiempo, se simplifica el proceso.

Descompondremos el diseño de bases de datos en tres etapas:

1)  Etapa del diseño conceptual: en esta etapa se obtiene una estructura de la información de la futura BD independiente de la tecnología que hay que emplear. No se tiene en cuenta todavía qué tipo de base de datos se utilizará –relacional, orientada a objetos, jerárquica, etc.–; en consecuencia, tampoco se tiene en cuenta con qué SGBD ni con qué lenguaje concreto se implementará la base de datos. Así pues, la etapa del diseño conceptual nos permite concentrarnos únicamente en la problemática de la estructuración de la información, sin tener que preocuparnos al mismo tiempo de resolver cuestiones tecnológicas.

El resultado de la etapa del diseño conceptual se expresa mediante algún modelo de datos de alto nivel. Uno de los más empleados es el modelo entidadinterrelación (entity-relationship), que abreviaremos con la sigla ER.

2)  Etapa del diseño lógico: en esta etapa se parte del resultado del diseño conceptual, que se transforma de forma que se adapte a la tecnología que se debe  emplear.  Más  concretamente,  es  preciso  que  se  ajuste  al  modelo  del SGBD con el que se desea implementar la base de datos. Por ejemplo, si se trata de un SGBD relacional, esta etapa obtendrá un conjunto de relaciones con sus atributos, claves primarias y claves foráneas.

Esta etapa parte del hecho de que ya se ha resuelto la problemática de la estructuración de la información en un ámbito conceptual, y permite concentrarnos en las cuestiones tecnológicas relacionadas con el modelo de base de datos.

Más adelante explicaremos cómo se hace el diseño lógico de una base de datos relacional, tomando como punto de partida un diseño conceptual expresado con el modelo ER; es decir, veremos cómo se puede transformar un modelo ER en un modelo relacional.

3)  Etapa del diseño físico: en esta etapa se transforma la estructura obtenida en la etapa del diseño lógico, con el objetivo de conseguir una mayor eficiencia; además, se completa con aspectos de implementación física que dependerán del SGBD.

Por ejemplo, si se trata de una base de datos relacional, la transformación de la estructura puede consistir en lo siguiente: tener almacenada alguna relación que sea la combinación de varias relaciones que se han obtenido en la etapa del diseño lógico, partir una relación en varias, añadir algún atributo calculable a una relación, etc. Los aspectos de implementación física que hay que completar consisten normalmente en la elección de estructuras físicas de implementación de las relaciones, la selección del tamaño de las memorias intermedias (buffers) o de las páginas, etc.

La forma de elaborar un diseño conceptual expresado con el modelo ER se explica en el apartado 2 de esta unidad.

El resultado del diseño lógico

El resultado del diseño lógico se sitúa ya en el mundo de las representaciones.

El diseño lógico de una base
de datos relacional se explica en el
apartado 3 de esta unidad didáctica.

En la etapa del diseño físico –con el objetivo de conseguir un buen rendimiento de la base de datos–, se deben tener en cuenta las características de los procesos  que  consultan  y  actualizan  la  base  de  datos,  como  por  ejemplo  los caminos de acceso que utilizan y las frecuencias de ejecución. También es necesario considerar los volúmenes que se espera tener de los diferentes datos que se quieren almacenar.