home

= FUNDAMENTOS DE BASES DE DATOS =

=** 1. SISTEMAS GESTORES DE BASES DE DATOS **= = =

1.1 OBJETIVO DE UNA BASE DE DATOS
1.INDEPENDENCIA DE LOS DATOS. La independencia de los datos consiste en hacer que los programas no dependan de la estructura de los datos que debe utilizar, que se pueda cambiar esa estructura sin tener que cambiar los programas relacionados con ella. Se han definido dos tipos de independencia: la independencia física: consiste en poder modificar parámetros de cómo está almacenada físicamente la información (por ejemplo cambiar el tipo de dato de un campo o cambiar la ubicación de la información de un disco a otro), sin que ello suponga una modificación de los programas existentes. la independencia lógica: consiste en poder cambiar la definición conceptual del sistema de información (por ejemplo añadir un nuevo campo a la información de los clientes) sin que ello suponga una modificación de los programas existentes.




 * 2. SEGURIDAD E INTEGRIDAD. Otro objetivo a lograr es el de la seguridad, que los usuarios no puedan acceder a datos sin autorización. Si juntamos toda la información de la empresa en un sólo sitio, el SGBD debe tener mecanismos para que cualquier usuario pueda tener acceso únicamente a la información que necesita de cara a la privacidad de esa información, incluso si tiene acceso a una información que se pueda decidir si además de visualizarla puede modificarla. Por ejemplo en un sistema en el que los alumnos pueden consultar sus notas, ¡deberá de existir algún mecanismo para que el alumno pueda ver sus notas pero no cambiarlas! La integridad se refiere a que la información almacenada en la base de datos esté libre de errores. Esto no siempre es posible ya que existen distintos tipos de errores que tienen diferentes soluciones: * fallos de hardware, estos errores sólo se pueden subsanar mediante copias de seguridad que pueden ser automáticas o manuales.2 * fallos del programador, puede que aparezcan datos erróneos en la base de datos como consecuencia de errores en el programa que genera estos datos. Para evitar al máximo este tipo de errores el sistema debe ser capaz de detectar automáticamente la mayor cantidad de errores para descargar los programas de comprobaciones rutinarias, el lenguaje de programación debe ser fácil de utilizar y si el sistema ofrece la posibilidad de utilizar juegos de ensayos bien definidos, será más fácil probar los programas. * fallos del usuario final, el usuario que introduce datos en la base de datos también puede cometer errores, el sistema debe permitir controlar al máximo la información que se introduce para limitar el número de estos errores, para ello se incluyen cláusulas de validación de los datos, validaciones de diferentes tipos que veremos con más detalle más adelante. * fallos derivados de la concurrencia, ya que toda la información está centralizada y los distintos usuarios acceden a ella de forma simultánea, pueden ocurrir problemas cuando dos usuarios quieren acceder al mismo dato a la vez. Por ello el SGBD debe tener establecidos mecanismos para evitar este tipo de problema, bloquear registros, abortar automáticamente transacciones etc...




 * 3. REDUNDANCIA MÍNIMA. La redundancia consiste en que existan datos idénticos repetidos en varios lugares. Por ejemplo si nos guardamos la dirección del cliente en la factura, en la cta. contable, y en los datos generales del cliente tendremos redundancia, el mismo dato repetido en varios sitios, pues esto nos produce varios problemas: * la información repetida ocupa espacio innecesario. * la variación de un domicilio supone el variar ese domicilio en todos los lugares donde esté almacenado => mayor tiempo de proceso => posibilidad de inconsistencia (el mismo cliente con dos domicilios ¿cuál es el bueno?) Por todo ello hay que intentar eliminar al máximo esa redundancia. 1.2.4 FACILIDAD DE RECUPERACIÓN DE LA INFORMACIÓN. Otro objetivo muy importante de un SGBD es el proporcionar al usuario (y al programador) unas herramientas potentes de manejo de datos para que pueda de manera sencilla y rápida, obtener toda la información que desea.



= = =1.2 Áreas de Aplicación de los Sistemas de Bases de datos. =

Se dividen prncipalmente en 5 areas:


 * 1.banca: información de clientes, cuentas, transacciones, préstamos, etc.




 * 2.líneas aéreas: inf. Clientes, horarios, vuelos, destinos, etc. (1ras bases distribuidas geográficamente)




 * 3.universidades: inf. Estudiantes, carreras, horarios, materias, etc.




 * 4.transacciones de tarjeta de crédito: para comprar con tarjetas de crédito y la generación de los extractos mensuales.



=
 * 5.telecomunicaciones: para guardar registros de llamadas realizadas, generar facturas mensuales, mantener el saldo de las tarjetas, telefónicas de prepago y almacenar información sobre las redes.

telecomunicaciones: para guardar registros de llamadas realizadas, generar facturas Para introducirnos en este tema, empezaremos definiendo que es un modelo. **//modelo://** Es una representación de la realidad que contiene las características generales de algo que se va a realizar. En base de datos, esta representación la elaboramos de forma gráfica.
 * // 1.3 Modelos de datos. //**

¿Qué es modelo de datos?

Es una colección de herramientas conceptuales para describir los datos, las relaciones que existen entre ellos, semántica asociada a los datos y restricciones de consistencia. Se usan para describir datos en los niveles conceptual y de visión, es decir, con este modelo representamos los datos de tal forma como nosotros los captamos en el mundo real, tienen una capacidad de estructuración bastante flexible y permiten especificar restricciones de datos explícitamente. Existen diferentes modelos de este tipo, pero el más utilizado por su sencillez y eficiencia es el modelo Entidad-Relación.
 * Los modelos de datos se dividen en tres grupos: Modelos lógicos basados en objetos. Modelos lógicos basados en registros. Modelos físicos de datos.
 * Modelos lógicos basados en objetos.

Las características de las entidades en base de datos se llaman **//atributos//,** por ejemplo el nombre, dirección teléfono, grado, grupo, etc. son atributos de la entidad alumno; Clave, número de seguro social, departamento, etc., son atributos de la entidad empleado. A su vez una entidad se puede asociar o relacionar con más entidades a través de **//relaciones.//** Pero para entender mejor esto, veamos; Consideremos una empresa que requiere controlar a los vendedores y las ventas que ellos realizan; de este problema determinamos que los objetos o entidades principales a estudiar son el empleado (vendedor) y el artículo (que es el producto en venta), y las características que los identifican son: Empleado: Artículo:
 * ** Modelo Entidad-Relación. ** Denominado por sus siglas como: E-R; Este modelo representa a la realidad a través de **entidades**, que son objetos que existen y que se distinguen de otros por sus características, por ejemplo: un alumno se distingue de otro por sus características particulares como lo es el nombre, o el numero de control asignado al entrar a una institución educativa, así mismo, un empleado, una materia, etc. Las entidades pueden ser de dos tipos:
 * Tangibles : Son todos aquellos objetos físicos que podemos ver,tocar o sentir.
 * Intangibles: Todos aquellos eventos u objetos conceptuales que no podemos ver, aun sabiendo que existen, por ejemplo: la entidad materia, sabemos que existe, sin embargo, no la podemos visualizar o tocar.

Nombre Descripción Puesto Costo Salario Clave R.F.C. La relación entre ambas entidades la podemos establecer como Venta. Bueno, ahora nos falta describir como se representa un modelo E-R gráficamente, la representación es muy sencilla, se emplean símbolos, los cuales son:
 * Símbolo Representa **

Así nuestro ejemplo anterior quedaría representado de la siguiente forma:

Existen más aspectos a considerar con respecto a los modelos entidad relación, estos serán considerados en el tema Modelo Entidad Relación.


 * MODELO LOGICO DE DATOS BASADOS EN REGISTROS

Se utilizan para describir datos en los niveles conceptual y físico.Estos modelos utilizan registros e instancias para representar la realidad, así como las relaciones que existen entre estos registros (ligas) o apuntadores. A diferencia de los modelos de datos basados en objetos, se usan para especificar la estructura lógica global de la base de datos y para proporcionar una descripción a nivel más alto de la implementación. Los tres modelos de datos más ampliamente aceptados son: Modelo Relacional Modelo de Red Modelo Jerárquico Considerando nuestro ejemplo del empleado y el artículo: Tabla del empleado
 * **Modelo relacional**. En este modelo se representan los datos y las relaciones entre estos, a través de una colección de tablas, en las cuales los renglones (tuplas) equivalen a los cada uno de los registros que contendrá la base de datos y las columnas corresponden a las características(atributos) de cada registro localizado en la tupla;

Ahora te preguntaras ** ¿ **** cómo se representan las relaciones entre las entidades en este modelo? ** Existen dos formas de representarla; pero para ello necesitamos definir que es una **llave primaria:** Es un atributo el cual definimos como atributo principal, es una forma única de identificar a una entidad. Por ejemplo, el RFC de un empleado se distingue de otro por que los RFC no pueden ser iguales. Ahora si, las formas de representar las relaciones en este modelo son:
 * //1. Haciendo una tabla que contenga cada una de las llaves primarias de las entidades involucradas en la relación.//** Tomando en cuenta que la llave primaria del empleado es su RFC, y la llave primaria del articulo es la Clave.


 * //2. Incluyendo en alguna de las tablas de las entidades involucradas, la llave de la otra tabla.//**

* Modelo de red.

Este modelo representa los datos mediante colecciones de registrosy sus relaciones se representan por medio de ligas o enlaces,los cuales pueden verse como punteros. Los registros se organizanen un conjunto de gráficas arbitrarias.

Para profundizar en este tema visitemos: [|Modelo de datos de red] **.**
 * // * //****// Modelo jerárquico //** . Es similar al modelo de red en cuanto a las relaciones y datos, ya que estos se representan por medio de registros y sus ligas. La diferencia radica en que están organizados por conjuntos de arboles en lugar de gráficas arbitrarias.

Para profundizar más en el tema visita: Modelo de datos jerárquico.

Modelo unificador Memoria de elementos
 * Modelos físicos de datos.** Se usan para describir a los datos en el nivel más bajo, aunque existen muy pocos modelos de este tipo, básicamente capturan aspectos de la implementación de los sistemas de base de datos. Existen dos clasificaciones de este tipo que son:

=**1.4 Arquitectura de los sistemas de bases de datos**= = = En 1975, el comité ANSI-SPARC (American National Standard Institute - Standards Planning and Requirements Committee) propuso una arquitectura de tres niveles para los SGBD cuyo objetivo principal era el de separar los programas de aplicación de la BD física. En esta arquitectura el esquema de una BD se define en tres niveles de abstracción distintos:


 * - Nivel interno o físico**: el más cercano al almacenamiento físico, es decir, tal y como están almacenados en el ordenador. Describe la estructura física de la BD mediante un esquema interno. Este esquema se especifica con un modelo físico y describe los detalles de cómo se almacenan físicamente los datos: los archivos que contienen la información, su organización, los métodos de acceso a los registros, los tipos de registros, la longitud, los campos que los componen, etcétera.


 * - Nivel externo o de visión**: es el más cercano a los usuarios, es decir, es donde se describen varios esquemas externos o vistas de usuarios. Cada esquema describe la parte de la BD que interesa a un grupo de usuarios en este nivel se representa la visión individual de un usuario o de un grupo de usuarios.

- **Nivel conceptual:** describe la estructura de toda la BD para un grupo de usuarios mediante un esquema conceptual. Este esquema describe las entidades, atributos, relaciones, operaciones de los usuarios y restricciones, ocultando los detalles de las estructuras físicas de almacenamiento. Representa la información contenida en la BD. En la Figura 1.1 se representan los niveles de abstracción de la arquitectura ANSI.



** 1.1. APLICACIONES DE LOS SISTEMAS DE BASES DE DATOS **

Las bases de datos son ampliamente usadas. Las siguientes son algunas de sus aplicaciones más representativas: • //Banca.// Para información de los clientes, cuentas y préstamos, y transacciones bancarias. • //Líneas aéreas.// Para reservas e información de planificación. Las líneas aéreas fueron de los primeros en usar las bases de datos de forma distribuida geográficamente (los terminales situados en todo el mundo accedían al sistema de bases de datos centralizado a través de las líneas telefónicas y otras redes de datos). • //Universidades.// Para información de los estudiantes, matrículas de las asignaturas y cursos. • //Transacciones de tarjetas de crédito.// Para compras con tarjeta de crédito y generación mensual de extractos. • //Telecomunicaciones.// Para guardar un registro de las llamadas realizadas, generación mensual de facturas, manteniendo el saldo de las tarjetas telefónicas de prepago y para almacenar información sobre las redes de comunicaciones. • //Finanzas.// Para almacenar información sobre grandes empresas, ventas y compras de documentos formales financieros, como bolsa y bonos. • //Ventas.// Para información de clientes, productos y compras. • //Producción.// Para la gestión de la cadena de producción y para el seguimiento de la producción de elementos en las factorías, inventarios de elementos en almacenes y pedidos de elementos. • //Recursos humanos.// Para información sobre los empleados, salarios, impuestos y beneficios, y para la generación de las nóminas. Como esta lista ilustra, las bases de datos forman una parte esencial de casi todas las empresas actuales. Alo largo de las últimas cuatro décadas del siglo veinte, el uso de las bases de datos creció en todas las empresas. En los primeros días, muy pocas personas interactuaron directamente con los sistemas de bases de datos, aunque sin darse cuenta interactuaron con bases de datos indirectamente (con los informes impresos como extractos de tarjetas de crédito, o mediante agentes como cajeros de bancos y agentes de reserva de líneas aéreas). Después vinieron los cajeros automáticos y permitieron a los usuarios interactuar con las bases de datos. Las interfaces telefónicas con los computadores (sistemas de respuesta vocal interactiva) también permitieron a los usuarios manejar directamente las bases de datos. Un llamador podía marcar un número y pulsar teclas del teléfono para introducir información o para seleccionar opciones alternativas, para determinar las horas de llegada o salida, por ejemplo, o para matricularse de asignaturas en una universidad. La revolución de Internet a finales de la década de 1990 aumentó significativamente el acceso directo delusuario a las bases de datos. Las organizaciones convirtieronmuchas de sus interfaces telefónicas a lasbases de datos en interfaces Web, y pusieron disponiblesen línea muchos servicios. Por ejemplo, cuandose accede a una tienda de libros en línea y se busca unlibro o una colección de música se está accediendo adatos almacenados en una base de datos. Cuando sesolicita un pedido en línea, el pedido se almacena enuna base de datos. Cuando se accede a un banco en unsitio Web y se consulta el estado de la cuenta y losmovimientos, la información se recupera del sistemade bases de datos del banco. Cuando se accede a unsitio Web, la información personal puede ser recuperadade una base de datos para seleccionar los anunciosque se deberían mostrar. Más aún, los datos sobrehanalmacenado la información usando tales sistemas.los accesos Web pueden ser almacenados en una basede datos. Así, aunque las interfaces de datos ocultan detalles del acceso a las bases de datos, y la mayoría de la gente ni siquiera es consciente de que están interactuando con una base de datos, el acceso a las bases de datos forma una parte esencial de la vida de casi todas las personas actualmente. La importancia de los sistemas de bases de datos se puede juzgar de otra forma: actualmente, los vendedores de sistemas de bases de datos como Oracle están entre las mayores compañías software en el mundo, y los sistemas de bases de datos forman una parte importante de la línea de productos de compañías más diversificadas, como Microsoft e IBM.

media type="youtube" key="SMeq0P2GAis" width="425" height="350" align="center"

** 1.2. SISTEMAS DE BASES DE DATOS FRENTE A SISTEMAS DE ARCHIVOS **

Considérese parte de una empresa de cajas de ahorros que mantiene información acerca de todos los clientes y cuentas de ahorros. Una manera de mantener la información en un computador es almacenarla en archivos del sistema operativo. Para permitir a los usuarios manipular la información, el sistema tiene un número de programas de aplicación que manipula los archivos, incluyendo: • Un programa para efectuar cargos o abonos en una cuenta. • Un programa para añadir una cuenta nueva. • Un programa para calcular el saldo de una cuenta. • Un programa para generar las operaciones mensuales. Estos programas de aplicación se han escrito por programadores de sistemas en respuesta a las necesidades de la organización bancaria. Si las necesidades se incrementan, se añaden nuevos programas de aplicación al sistema. Por ejemplo, supóngase que las regulaciones de un nuevo gobierno permiten a las cajas de ahorros ofrecer cuentas corrientes. Como resultado se crean nuevos archivos permanentes que contengan información acerca de todas las cuentas corrientes mantenidas por el banco, y puede ser necesario escribir nuevos programas de aplicación para tratar situaciones que no existían en las cuentas de ahorro, tales como manejar descubiertos. Así, sobre la marcha, se añaden más archivos y programas de aplicación al sistema. Este **sistema de procesamiento de archivos** típico que se acaba de describir se mantiene mediante un sistema operativo convencional. Los registros permanentes son almacenados en varios archivos y se escriben diferentes programas de aplicación para extraer registros y para añadir registros a los archivos adecuados. Antes de la llegada de los sistemas de gestión de bases de datos (SGBDs), las organizaciones normalmente han almacenado la información usando tales sistemas. Mantener información de la organización en un sistema de procesamiento de archivos tiene una serie de inconvenientes importantes: **• Redundancia e inconsistencia de datos.** Debido a que los archivos y programas de aplicación son creados por diferentes programadores en un largo período de tiempo, los diversos archivos tienen probablemente diferentes formatos y los programas pueden estar escritos en diferentes lenguajes. Más aún, la misma información puede estar duplicada en diferentes lugares (archivos). Por ejemplo, la dirección y número de teléfono de un cliente particular puede aparecer en un archivo que contenga registros de cuentas de ahorros y en un archivo que contenga registros de una cuenta corriente. Esta redundancia conduce a un almacenamiento y coste de acceso más altos. Además, puede conducir a **inconsistencia de datos;** es decir, las diversas copias de los mismos datos pueden no coincidir. Por ejemplo, un cambio en la dirección del cliente puede estar reflejado en los registros de las cuentas de ahorro pero no estarlo en el resto del sistema. **• Di****fi****cultad en el acceso a los datos.** Supóngase que uno de los empleados del banco necesita averiguar los nombres de todos los clientes que viven en el distrito postal 28733 de la ciudad. El empleado pide al departamento de procesamiento de datos que genere dicha lista. Debido a que esta petición no fue prevista cuando el sistema original fue diseñado, no hay un programa de aplicación a mano para satisfacerla. Hay, sin embargo, un programa de aplicación que genera la lista de //todos// los clientes. El empleado del banco tiene ahora dos opciones: bien obtener la lista de todos los clientes y obtener la información que necesita manualmente, o bien pedir al departamento de procesamiento de datos que haga que un programador de sistemas escriba el programa de aplicación necesario. Ambas alternativas son obviamente insatisfactorias. Supóngase que se escribe tal programa y que, varios días más tarde, el mismo empleado necesita arreglar esa lista para incluir sólo aquellos clientes que tienen una cuenta con saldo de 10.000 € o más. Como se puede esperar, un programa para generar tal lista no existe. De nuevo, el empleado tiene que elegir entre dos opciones, ninguna de las cuales es satisfactoria. La cuestión aquí es que el entorno de procesamiento de archivos convencional no permite que los datos necesarios sean obtenidos de una forma práctica y eficiente. Se deben desarrollar sistemas de recuperación de datos más interesantes para un uso general. **• Aislamiento de datos.** Debido a que los datos están dispersos en varios archivos, y los archivos pueden estar en diferentes formatos, es difícil escribir nuevos programas de aplicación para recuperar los datos apropiados. **• Problemas de integridad.** Los valores de los datos almacenados en la base de datos deben satisfacer ciertos tipos de **restricciones de consistencia.** Por ejemplo, el saldo de una cuenta bancaria no puede nunca ser más bajo de una cantidad predeterminada (por ejemplo 25 € ). Los desarrolladores hacen cumplir esas restricciones en el sistema añadiendo el código apropiado en los diversos programas de aplicación. Sin embargo, cuando se añaden nuevas restricciones, es difícil cambiar los programas para hacer que se cumplan. El problema es complicado cuando las restricciones implican diferentes elementos de datos de diferentes archivos. **• Problemas de atomicidad.** Un sistema de un computador, como cualquier otro dispositivo mecánico o eléctrico, está sujeto a fallo. En muchas aplicaciones es crucial asegurar que, una vez que un fallo ha ocurrido y se ha detectado, los datos se restauran al estado de consistencia que existía antes del fallo. Consideremos un programa para transferir 50 € desde la cuenta Aa la B. Si ocurre un fallo del sistema durante la ejecución del programa, es posible que los 50 € fueron eliminados de la cuena pero no abonados a la cuenta B, resultando un estado de la base de datos inconsistente. Claramente, es esencial para la consistencia de la base de datos que ambos, el abono y el cargo tengan lugar, o que ninguno tenga lugar. Es decir, la transferencia de fondos debe ser //atómica//: ésta debe ocurrir en ellos por completo o no ocurrir en absoluto. Es difícil asegurar esta propiedad en un sistema de procesamiento de archivos convencional. **• Anomalías en el acceso concurrente.** Conforme se ha ido mejorando el conjunto de ejecución de los sistemas y ha sido posible una respuesta en tiempo más rápida, muchos sistemas han ido permitiendo a múltiples usuarios actualizar los datos simultáneamente. En tales sistemas un entorno de interacción de actualizaciones concurrentes puede dar lugar a datos inconsistentes. Considérese una cuenta bancaria A, que contiene 500 €. Si dos clientes retiran fondos (por ejemplo 50 € y 100 € respectivamente) de la cuenta A en aproximadamente el mismo tiempo, el resultado de las ejecuciones concurrentes puede dejar la cuenta en un estado incorrecto (o inconsistente). Supongamos que los programas se ejecutan para cada retirada y escriben el resultado después. Si los dos programas funcionan concurrentemente, pueden leer ambos el valor 500 €, y escribir después 450 € y 400 € , respectivamente. Dependiendo de cuál escriba el último valor, la cuenta puede contener bien 450 € o bien 400 €, en lugar del valor correcto, 350 €. Para protegerse contra esta posibilidad, el sistema debe mantener alguna forma de supervisión. Sin embargo, ya que se puede acceder a los datos desde muchos programas de aplicación diferentes que no han sido previamente coordinados, la supervisión es difícil de proporcionar. **• Problemas de seguridad.** No todos los usuarios de un sistema de bases de datos deberían poder acceder a todos los datos. Por ejemplo, en un sistema bancario, el personal de nóminas necesita ver sólo esa parte de la base de datos que tiene información acerca de varios empleados del banco. No necesitan acceder a la información acerca de las cuentas de clientes. Como los programas de aplicación se añaden al sistema de una forma ad hoc, es difícil garantizar tales restricciones de seguridad. Estas dificultades, entre otras, han motivado el desarrollo de los sistemas de bases de datos. En este libro se verán los conceptos y algoritmos que han sido incluidos en los sistemas de bases de datos para resolver los problemas mencionados anteriormente. En la mayor parte de este libro se usa una empresa bancaria como el ejemplo de una aplicación corriente de procesamiento de datos típica encontrada en una empresa.

** 1.3. VISIÓN DE LOS DATOS **

Un sistema de bases de datos es una colección de archivos interrelacionados y un conjunto de programas que permitan a los usuarios acceder y modificar estos archivos. Uno de los propósitos principales de un sistema de bases de datos es proporcionar a los usuarios una visión //abstracta// de los datos. Es decir, el sistema esconde ciertos detalles de cómo se almacenan y mantienen los datos. Para que el sistema sea útil debe recuperar los datos eficientemente. Esta preocupación ha conducido al diseño de estructuras de datos complejas para la representación de los datos en la base de datos. Como muchos usuarios de sistemas de bases de datos no están familiarizados con computadores, los desarrolladores esconden la complejidad a los usuarios a través de varios niveles de abstracción para simplificar la interacción de los usuarios con el sistema: el nivel físico se describen en detalle las estructuras de datos complejas de bajo nivel. base de datos y qué relaciones existen entre esos datos. La base de datos completa se describe así en términos de un número pequeño de estructuras relativamente simples. Aunque la implementación de estructuras simples en el nivel lógico puede involucrar estructuras complejas del nivel físico, los usuarios del nivel lógico no necesitan preocuparse de esta complejidad. Los administradores de bases de datos, que deben decidir la información que se mantiene en la base de datos, usan el nivel lógico de abstracción. la variedad de información almacenada en una gran base de datos. Muchos usuarios del sistema de base de datos no necesitan toda esta información. En su lugar, tales usuarios necesitan acceder sólo a una parte de la base de datos. Para que su interacción con el sistema se simplifique, se define la abstracción del nivel de vistas. El sistema puede proporcionar muchas vistas para la misma base de datos.
 * 1.3.1. Abstracción de datos**
 * • Nivel físico:** El nivel más bajo de abstracción describe //cómo// se almacenan realmente los datos. En
 * • Nivel lógico:** El siguiente nivel más alto de abstracción describe //qué// datos se almacenan en la
 * • Nivel de vistas:** El nivel más alto de abstracción describe sólo parte de la base de datos completa. A pesar del uso de estructuras más simples en el nivel lógico, queda algo de complejidad, debido a

** 1.4. MODELOS DE LOS DATOS **

Bajo la estructura de la base de datos se encuentra el **modelo de datos**: una colección de herramientas conceptuales para describir los datos, las relaciones, la semántica y las restricciones de consistencia. Para ilustrar el concepto de un modelo de datos, describimos dos modelos de datos en este apartado: el modelo entidadrelación y el modelo relacional. Los diferentes modelos de datos que se han propuesto se clasifican en tres grupos diferentes: modelos lógicos basados en objetos, modelos lógicos basados en registros y modelos físicos. **1.4.1. Modelo entidad-relación** El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados //entidades//, y de //relaciones// entre estos objetos. Una entidad es una «cosa» u «objeto» en el mundo real que es distinguible de otros objetos. Por ejemplo, cada persona es una entidad, y las cuentas bancarias pueden ser consideradas entidades. Las entidades se describen en una base de datos mediante un conjunto de **atributos**. Por ejemplo, los atributos //número-cuenta// y //saldo// describen una cuenta particular de un banco y pueden ser atributos del conjunto de entidades //cuenta//. Análogamente, los atributos //nombre-cliente//, //calle-cliente// y //ciudad-cliente// pueden describir una entidad //cliente//. Un atributo extra, //id-cliente//, se usa para identificar unívocamente a los clientes (dado que puede ser posible que haya dos clientes con el mismo nombre, direccribe

**1.4.2. Modelo relacional** En el modelo relacional se utiliza un grupo de tablas para representar los datos y las relaciones entre ellos. Cada tabla está compuesta por varias columnas, y cada columna tiene un nombre único. En la Figura 1.3 se presenta un ejemplo de base de datos relacional consistente en tres tablas: la primera muestra los clientes de un banco, la segunda, las cuentas, y la tercera, las cuentas que pertenecen a cada cliente.



** 1.5. LENGUAJES DE BASES DE DATOS **

Un sistema de bases de datos proporciona un **lenguaje de de****fi****nición de datos** para especificar el esquema de la basede datos y un **lenguaje de manipulación de datos** paraexpresar las consultas a la base de datos y las modificaciones.En la práctica, los lenguajes de definición y manipulaciónde datos no son dos lenguajes separados; en sulugar simplemente forman partes de un único lenguaje de bases de datos, tal como SQL, ampliamente usado. **1.5.1. Lenguaje de definición de datos** Un esquema de base de datos se especifica mediante unconjunto de definiciones expresadas mediante un lenguajeespecial llamado **lenguaje de de****fi****nición de datos****(LDD)**. Por ejemplo, la siguiente instrucción en el lenguaje SQL define la tabla //cuenta//: **create table** //cuenta// (//número-cuenta// **char**(10), //saldo// **integer**) La ejecución de la instrucción LDD anterior crea la tabla //cuenta//. Además, actualiza un conjunto especial de tablas denominado **diccionario de datos** o **directorio** **de datos**. Un diccionario de datos contiene **metadatos**, es decir, datos acerca de los datos. El esquema de una tabla es un ejemplo de metadatos. Un sistema de base de datos consulta el diccionario de datos antes de leer o modificar los datos reales. Especificamos el almacenamiento y los métodos de acceso usados por el sistema de bases de datos por un conjunto de instrucciones en un tipo especial de LDD denominado lenguaje de **almacenamiento y de****fi****nición****de datos**. Estas instrucciones definen los detalles de implementación de los esquemas de base de datos, que se ocultan usualmente a los usuarios. Los valores de datos almacenados en la base de datos deben satisfacer ciertas **restricciones de consistencia**. Por ejemplo, supóngase que el saldo de una cuenta no debe caer por debajo de 100 €. El LDD proporciona facilidades para especificar tales restricciones. Los sistemas de bases de datos comprueban estas restricciones cada vez que se actualiza la base de datos. **1.5.2. Lenguaje de manipulación de datos** La **manipulación de datos** es: • La recuperación de información almacenada en la base de datos. • La inserción de información nueva en la base de datos. • El borrado de información de la base de datos. • La modificación de información almacenada en la base de datos. Un **//lenguaje de manipulación de datos//** **(LMD)** es un lenguaje que permite a los usuarios acceder o manipular los datos organizados mediante el modelo de datos apropiado. Hay dos tipos básicamente: **• LMDs procedimentales.** Requieren que el usuario especifique //qué// datos se necesitan y //cómo// obtener esos datos. **• LMDs declarativos** (también conocidos como LMDs **no procedimentales**). Requieren que el usuario especifique //qué// datos se necesitan //sin// especificar cómo obtener esos datos. Los LMDs declarativos son más fáciles de aprender y usar que los LMDs procedimentales. Sin embargo, como el usuario no especifica cómo conseguir los datos, el sistema de bases de datos tiene que determinar un medio eficiente de acceder a los datos. El componente LMD del lenguaje SQL es no procedimental.

** 1.6. USUARIOS Y ADMINISTRADORES DE LA BASE DE DATOS **

Un objetivo principal de un sistema de bases de datos es recuperar información y almacenar nueva información en la base de datos. Las personas que trabajan con una base de datos se pueden catalogar como usuarios de bases de datos o como administradores de bases de datos. **1.6.1. Usuarios de bases de datos e interfaces** **de usuario** Hay cuatro tipos diferentes de usuarios de un sistema de base de datos, diferenciados por la forma en que ellos esperan interactuar con el sistema. Se han diseñado diferentes tipo de interfaces de usuario para diferentes tipos de usuarios. **• Usuarios normales.** Son usuarios no sofisticados que interactúan con el sistema mediante la invocación de alguno de los programas de aplicación permanentes que se ha escrito previamente. Por ejemplo, un cajero bancario que necesita transferir 50 € de la cuenta //A// a la cuenta //B// invoca un programa llamado //transferir//. Este programa pide al cajero el importe de dinero a transferir, la cuenta de la que el dinero va a ser transferido y la cuenta a la que el dinero va a ser transferido. Como otro ejemplo, considérese un usuario que desee encontrar su saldo de cuenta en World Wide Web. Tal usuario podría acceder a un formulario en el que introduce su número de cuenta. Un programa de aplicación en el servidor Web recupera entonces el saldo de la cuenta, usando el número de cuenta proporcionado, y pasa la información al usuario. La interfaz de usuario normal para los usuarios normales es una interfaz de formularios, donde el usuario puede rellenar los campos apropiados del formulario. Los usuarios normales pueden también simplemente leer //informes// generados de la base de datos. **• Programadores de aplicaciones.** Son profesionales informáticos que escriben programas de aplicación. Los programadores de aplicaciones pueden elegir entre muchas herramientas para desarrollar interfaces de usuario. Las herramientas de **desarrollo rápido de aplicaciones (DRA)** son herramientas que permiten al programador de aplicaciones construir formularios e informes sin escribir un programa. Hay también tipos especiales de lenguajes de programación que combina estructuras de control imperativo (por ejemplo, para bucles for, bucles while e instrucciones ifthen- else) con instrucciones del lenguaje de manipulación de datos. Estos lenguajes, llamado veces //lenguajes de cuarta generación//, a menudo incluyen características especiales para facilitar lageneración de formularios y la presentación de datos en pantalla. La mayoría de los sistemas de bases de datos comerciales incluyen un lenguaje de cuarta generación. **• Los usuarios so****fi****sticados** interactúan con el sistema sin programas escritos. En su lugar, ellos formansus consultas en un lenguaje de consulta de bases de datos. Cada una de estas consultas se envíaal //procesador de consultas//, cuya función es transformar instrucciones LMD a instrucciones que elgestor de almacenamiento entienda. Los analistas que envían las consultas para explorar los datos en la base de datos entran en esta categoría. Las herramientas de **procesamiento analítico****en línea (OLAP, Online Analytical Processing)** simplifican la labor de los analistas permitiéndoles ver resúmenes de datos de formas diferentes. Por ejemplo, un analista puede ver las ventas totales por región (por ejemplo, norte, sur, este y oeste), o por producto, o por una combinación de la región y del producto (es decir, las ventas totales de cada producto en cada región). Las herramientas también permiten al analista seleccionar regiones específicas, examinar los datos con más detalle (por ejemplo, ventas por ciudad dentro de una región) o examinar los datos con menos detalle (por ejemplo, agrupando productos por categoría). Otra clase de herramientas para los analistas son las herramientas de **recopilación de datos**, que les ayudan a encontrar ciertas clases de patrones de datos. **• Usuarios especializados.** Son usuarios sofisticados que escriben aplicaciones de bases de datos especializadas que no son adecuadas en el marco de procesamiento de datos tradicional. Entre estas aplicaciones están los sistemas de diseño asistido por computador, sistemas de bases de conocimientos y sistemas expertos, sistemas que almacenan los datos con tipos de datos complejos (por ejemplo, datos gráficos y datos de audio) y sistemas de modelado del entorno. **1.6.2. Administrador de la base de datos** Una de las principales razones de usar SGBDs es tener un control centralizado tanto de los datos como de los programas que acceden a esos datos. La persona que tiene este control central sobre el sistema se llama **administrador****de la base de datos (ABD)**. Las funciones del ABD incluyen las siguientes: **• De****fi****nición del esquema.** El ABD crea el esquema original de la base de datos escribiendo un conjunto de instrucciones de definición de datos en el LDD. **• De****fi****nición de la estructura y del método de acceso.** **• Modi****fi****cación del esquema y de la organización** **física.** Los ABD realizan cambios en el esquema y en la organización física para reflejar las necesidades cambiantes de la organización, o para alterar la organización física para mejorar el rendimiento. **• Concesión de autorización para el acceso a los** **datos.** La concesión de diferentes tipos de autorización permite al administrador de la base de datos determinar a qué partes de la base de datos puede acceder cada usuario. La información de autorización se mantiene en una estructura del sistema especial que el sistema de base de datos consulta cuando se intenta el acceso a los datos en el sistema. **• Mantenimiento rutinario.** Algunos ejemplos de actividades rutinarias de mantenimiento del administrado de la base de datos son: — Copia de seguridad periódica de la base de datos, bien sobre cinta o sobre servidores remotos, para prevenir la pérdida de datos en caso de desastres como inundaciones.



** 1.7. GESTIÓN DE TRANSACCIONES ** Varias operaciones sobre la base de datos forman a menudo una única unidad lógica de trabajo. Un ejemplo que se vio en el Apartado 1.2 es la transferencia de fondos, en el que una cuenta (//A//) se carga y otra cuenta (//B//) se abona. Claramente es esencial que, o bien tanto el cargo como el abono tengan lugar, o bien no ocurra ninguno. Es decir, la transferencia de fondos debe ocurrir por completo o no ocurrir en absoluto. Este requisito de todo o nada se denomina **atomicidad**. Además, es esencial que la ejecución de la transferencia de fondos preserve la consistencia de la base de datos. Es decir, el valor de la suma //A// + //B// se debe preservar. Este requisito de corrección se llama **consistencia**. Finalmente, tras la ejecución correcta de la transferencia de fondos, los nuevos valores de las cuentas //A// y //B// deben persistir, a pesar de la posibilidad de fallo del sistema. Este requisito de persistencia se llama **durabilidad**. Una **transacción** es una colección de operaciones que se lleva a cabo como una única función lógica en una aplicación de bases de datos. Cada transacción es una unidad de atomicidad y consistencia. Así, se requiere que las transacciones no violen ninguna restricción de consistencia de la base de datos. Es decir, si la base de datos era consistente cuando la transacción comenzó, la base de datos debe ser consistente cuando la transacción termine con éxito. Sin embargo, durante la ejecución de una transacción, puede ser necesario permitir inconsistencias temporalmente, ya que o el cargo de //A// o el abono de //B// se debe realizar uno antes que otro. Esta inconsistencia temporal, aunque necesaria, puede conducir a dificultades si ocurre un fallo. Es responsabilidad del programador definir adecuadamente las diferentes transacciones, de tal manera que cada una preserve la consistencia de la base de datos. Por ejemplo, la transacción para transferir fondos de la cuenta //A// a la cuenta //B// se podría definir como compuesta de dos programas separados: uno que carga la cuenta A y otro que abona la cuenta B. La ejecución de estos dos programas uno después del otro preservará realmente la consistencia. Sin embargo, cada programa en sí mismo no transforma la base de datos de un estado consistente en otro nuevo estado consistente. Así, estos programas no son transacciones. Asegurar las propiedades de atomicidad y durabilidad es responsabilidad del propio sistema de bases de datos, específicamente del **componente de gestión de****transacciones**. En ausencia de fallos, toda transacción completada con éxito y atómica se archiva fácilmente. Sin embargo, debido a diversos tipos de fallos, una transacción puede no siempre completar su ejecución con éxito. Si se asegura la propiedad de atomicidad, una transacción que falle no debe tener efecto en el estado de la base de datos. Así, la base de datos se restaura al estado en que estaba antes de que la transacción en cuestión comenzara su ejecución. El sistema de bases de datos debe realizar la **recuperación de fallos**, es decir, detectar los fallos del sistema y restaurar la base de datos al estado que existía antes de que ocurriera el fallo. Finalmente, cuando varias transacciones actualizan la base de datos concurrentemente, la consistencia de los datos puede no ser preservada, incluso aunque cada transacción individualmente sea correcta. Es responsabilidad del **gestor de control de concurrencia** controlar la interacción entre las transacciones concurrentes para asegurar la consistencia de la base de datos. Los sistemas de bases de datos diseñados para uso sobre pequeños computadores personales pueden no tener todas las características vistas. Por ejemplo, muchos sistemas pequeños imponen la restricción de permitir el acceso a un único usuario a la base de datos en un instante de tiempo. Otros dejan las tareas de copias de seguridad y recuperación a los usuarios. Estas restricciones permiten un gestor de datos más pequeño, con menos requisitos de recursos físicos, especialmente de memoria principal. Aunque tales enfoques de bajo coste y prestaciones son suficientes para bases de datos personales pequeñas, son inadecuadas para satisfacer las necesidades de una empresa de media a gran escala.

** 1.8. ESTRUCTURA DE UN SISTEMA DE BASES DE DATOS **

Un sistema de bases de datos se divide en módulos que se encargan de cada una de las responsabilidades del sistema completo. Los componentes funcionales de un sistema de bases de datos se pueden dividir a grandes rasgos en los componentes gestor de almacenamiento y procesador de consultas. El gestor de consultas es importante porque las bases de datos requieren normalmente una gran cantidad de espacio de almacenamiento. Las bases de datos corporativas tienen un tamaño de entre cientos de gigabytes y, para las mayores bases de datos, terabytes de datos. Un gigabyte son 1.000 megabytes (1.000 millones de bytes), y un terabyte es 1 millón de megabytes (1 billón de bytes). Debido a que la memoria principal de los computadores no puede almacenar esta gran cantidad de información, esta se almacena en discos. Los datos se trasladan entre el disco de almacenamiento y la memoria principal cuando es necesario. Como la transferencia de datos a y desde el disco es lenta comparada con la velocidad de la unidad central de procesamiento, es fundamental que el sistema de base de datos estructure los datos para minimizar la necesidad de movimiento de datos entre el disco y la memoria principal. El procesador de consultas es importante porque ayuda al sistema de bases de datos a simplificar y facilitar el acceso a los datos. Las vistas de alto nivel ayudan a conseguir este objetivo. Con ellas, los usuarios del sistema no deberían ser molestados innecesariamente con los detalles físicos de implementación del sistema. Sin embargo, el rápido procesamiento de las actualizaciones y de las consultas es importante. Es trabajo del sistema de bases de datos traducir las actualizaciones y las consultas escritas en un lenguaje no procedimental, en el nivel lógico, en una secuencia de operaciones en el nivel físico. **1.8.1. Gestor de almacenamiento** Un //gestor de almacenamiento// es un módulo de programa que proporciona la interfaz entre los datos de bajo nivel en la base de datos y los programas de aplicación y consultas emitidas al sistema. El gestor de almacenamiento es responsable de la interacción con el gestor de archivos. Los datos en bruto se almacenan en disco usando un sistema de archivos, que está disponible habitualmente en un sistema operativo convencional. El gestor de almacenamiento traduce las diferentes instrucciones LMD a órdenes de un sistema de archivos de bajo nivel. Así, el gestor de almacenamiento es responsable del almacenamiento, recuperación y actualización de los datos en la base de datos. Los componentes del gestor de almacenamiento incluyen: **• Gestor de autorización e integridad**, que comprueba que se satisfagan las restricciones de integridady la autorización de los usuarios para acceder a los datos. **• Gestor de transacciones**, que asegura que la base de datos quede en un estado consistente (correctoa pesar de los fallos del sistema, y que las ejecuciones de transacciones concurrentes ocurran sconflictos. **• Gestor de archivos**, que gestiona la reserva de espacio de almacenamiento de disco y las estructuras de datos usadas para representar la información almacenada en disco  **• Gestor de memoria intermedia**, que es responsable de traer los datos del disco de almacenamiento  a memoria principal y decidir qué datos tratar en memoria caché. El gestor de memoria intermedia es una parte crítica del sistema de bases de datos, ya que permite que la base de datos maneje tamaños de datos que son mucho mayores que el tamaño de la memoria principal.  El gestor de almacenamiento implementa varias estructuras de datos como parte de la implementación  física del sistema:  **• Archivos de datos**, que almacenan la base de datos en sí. **• Diccionario de datos**, que almacena metadatos acerca de la estructura de la base de datos, en particular, el esquema de la base de datos. **• Índices**, que proporcionan acceso rápido a elementos de datos que tienen valores particulares. **1.8.2. Procesador de consultas** Los componentes del procesador de consultas incluyen: **• Intérprete del LDD**, que interpreta las instrucciones del LDD y registra las definiciones en el diccionario de datos. **• Compilador del LMD**, que traduce las instrucciones del LMD en un lenguaje de consultas a un plan de evaluación que consiste en instrucciones de bajo nivel que entiende el motor de evaluación de consultas. Una consulta se puede traducir habitualmente en varios planes de ejecución alternativos que proporcionan el mismo resultado. El compilador del LMD también realiza **optimización de consultas**, es decir, elige el plan de evaluación de menor coste de entre todas las alternativas. **• Motor de evaluación de consultas**, que ejecuta las instrucciones de bajo nivel generadas por el compilador del LMD.

** 1.9. ARQUITECTURAS DE APLICACIONES **

La mayoría de usuarios de un sistema de bases de datos no están situados actualmente junto al sistema de bases de datos, sino que se conectan a él a través de una red. Se puede diferenciar entonces entre las máquinas **cliente**, en donde trabajan los usuarios remotos de la base de datos, y las máquinas **servidor**, en las que se ejecuta el sistema de bases de datos. Las aplicaciones de bases de datos se dividen usualmente en dos o tres partes, como se ilustra en la Figura 1.5. En una **arquitectura de dos capas**, la aplicación se divide en un componente que reside en la máquina cliente, que llama a la funcionalidad del sistema de bases de datos en la máquina servidor mediante instrucciones del lenguaje de consultas. Los estándares de interfaces de programas de aplicación como ODBC y JDBC se usan para la interacción entre el cliente y el servidor. En cambio, en una **arquitectura de tres capas**, la máquina cliente actúa simplemente como frontal y no contiene ninguna llamada directa a la base de datos. En su lugar, el cliente se comunica con un **servidor de aplicaciones**, usualmente mediante una interfaz de formularios. El servidor de aplicaciones, a su vez, se comunica con el sistema de bases de datos para acceder a los datos. La **lógica de negocio** de la aplicación, que establece las acciones a realizar bajo determinadas condiciones, se incorpora en el servidor de aplicaciones, en lugar de ser distribuida a múltiples clientes. Las aplicaciones de tres capas son más apropiadas para grandes aplicaciones, y para las aplicaciones que se ejecutan en World Wide Web.

** 1.10. HISTORIA DE LOS SISTEMAS DE BASES DE DATOS **

El procesamiento de datos impulsa el crecimiento de los computadores, como ocurriera en los primeros días de los computadores comerciales. De hecho, la automatización de las tareas de procesamiento de datos precede a los computadores. Las tarjetas perforadas, inventadas por Hollerith, se usaron en los principios del siglo xx para registrar los datos del censo de los EE.UU., y se usaron sistemas mecánicos para procesar las tarjetas y para tabular los resultados. Las tarjetas perforadas posteriormente se usaron ampliamente como medio para introducir datos en los computadores. Las técnicas del almacenamiento de datos han evolucionado a lo largo de los años: • **Década de 1950 y principios de la década de 1960.** Se desarrollaron las cintas magnéticas para el almacenamiento de datos. Las tareas de procesamiento de datos tales como las nóminas fueron automatizadas, con los datos almacenados en cintas. El procesamiento de datos consistía en leer datos de una o más cintas y escribir datos en una nueva cinta. Los datos también se podían introducir desde paquetes de tarjetas perforadas e impresos en impresoras. Por ejemplo, los aumentos de sueldo se procesaban introduciendo los aumentos en las tarjetas perforadas y leyendo el paquete de cintas perforadas en sincronización con una cinta que contenía los detalles maestros de los salarios. Los registros debían estar igualmente ordenados. Los aumentos de sueldo tenían que añadirse a los sueldos leídos de la cinta maestra, y escribirse en una nueva cinta; esta nueva cinta se convertía en la nueva cinta maestra. Las cintas (y los paquetes de tarjetas perforadas) sólo se podían leer secuencialmente, y los tamaños de datos eran mucho mayores que la memoria principal; así, los programas de procesamiento de datos tenían que procesar los datos según un determinado orden, leyendo y mezclando dato de cintas y paquetes de tarjetas perforadas. • **Finales de la década de 1960 y la década de** **1970.** El amplio uso de los discos fijos a finales de la década de 1960 cambió en gran medida el escenario del procesamiento de datos, ya que los discos fijos permitieron el acceso directo a los datos. La ubicación de los datos en disco no era importante, ya que a cualquier posición del disco se podía acceder en sólo decenas de milisegundo. Los datos se liberaron de la tiranía de la secuencialidad. Con los discos pudieron desarrollarse las bases de datos de red y jerárquicas, que permitieron que las estructuras de datos tales como listas y árboles pudieran almacenarse en disco. Los programadores pudieron construir y manipular estas estructuras de datos. Un artículo histórico de Codd [1970] definió el modelo relacional y formas no procedimentales de consultar los datos en el modelo relacional, y nacieron las bases de datos relacionales. La simplicidad del modelo relacional y la posibilidad de ocultar completamente los detalles de implementación al programador fueron realmente atractivas. Codd obtuvo posteriormente el prestigioso premio Turing de la ACM (Association of Computing Machinery, asociación de maquinaria informática) por su trabajo. • **Década de 1980.** Aunque académicamente interesante, el modelo relacional no se usó inicialmente en la práctica debido a sus inconvenientes por el rendimiento; las bases de datos relacionales no pudieron competir con el rendimiento de las bases de datos de red y jerárquicas existentes. Esta situación cambió con System R, un proyecto innovador en IBM Research que desarrolló técnicas para la construcción de un sistema de bases de datos relacionales eficiente. En Astrahan et al. [1976] y Chamberlin et al. [1981] se pueden encontrar excelentes visiones generales de System R. El prototipo de System R completamente funcional condujo al primer producto de bases de datos relacionales de IBM: SQL/DS. Los primeros sistemas de bases de datos relacionales, como DB2 de IBM, Oracle, Ingres y Rdb de DEC, jugaron un importante papel en el desarrollo de técnicas para el procesamiento eficiente de consultas declarativas. En los principios de la década de 1980 las bases de datos relacionales llegaron a competir con los sistemas de bases de datos jerárquicas y de red incluso en el área de rendimiento. Las bases de datos relacionales fueron tan sencillas de usar que finalmente reemplazaron a las bases de datos jerárquicas y de red; los programadores que usaban estas bases de datos estaban forzados a tratar muchos detalles de implementación de bajo nivel y tenían que codificar sus consultas de forma procedimental. Aún más importante, debían tener presente el rendimiento durante el diseño de sus programas, lo que implicaba un gran esfuerzo. En cambio, en una base de datos relacional, casi todas estas tareas de bajo nivel se realizan automáticamente por la base de datos, liberando al programador en el nivel lógico. Desde su escalada en el dominio en la década de 1980, el modelo relacional ha conseguido el reinado supremo entre todos los modelos de datos.La década de 1980 también fue testigo de unagran investigación en las bases de datos paralelasy distribuidas, así como del trabajo inicial en las bases de datos orientadas a objetos. • **Principios de la década de 1990.** El lenguaje SQL se diseñó fundamentalmente para las aplicaciones de ayuda a la toma de decisiones, que son intensivas en consultas, mientras que el objetivo principal de las bases de datos en la década de 1980 fue las aplicaciones de procesamiento de transacciones, que son intensivas en actualizaciones. La ayuda a la toma de decisiones y las consultas reemergieron como una importante área de aplicación para las bases de datos. Las herramientas para analizar grandes cantidades de datos experimentaron un gran crecimiento de uso. Muchos vendedores de bases de datos introdujeron productos de bases de datos paralelas en este periodo, así como también comenzaron ofrecer bases de datos relacionales orientadas a objeto. • **Finales de la década de 1990.** El principal acontecimiento fue el crecimiento explosivo de World Wide Web. Las bases de datos se implantaron mucho más extensivamente que nunca antes. Los sistemas de bases de datos tienen ahora soporte para tasas de transacciones muy altas, así como muy alta fiabilidad y disponibilidad 24 × 7 (disponibilidad 24 horas al día y 7 días a la semana, que significa que no hay tiempos de inactividad debidos a actividades de mantenimiento planificadas). Los sistemas de bases de datos también tuvieron interfaces Web a los datos.

media type="youtube" key="jiX5y9G8RAI" width="425" height="350" align="center"

MODELOS DE DATOS

Un modelo de datos es una colección de herramientas conceptuales para la descripción de datos, relaciones entre datos, semántica de los datos y restricciones de consistencia. En esta parte se estudiarán dos modelos de datos —el modelo entidad-relación y el modelo relacional. El modelo entidad-relación (E-R) es un modelo de datos de alto nivel. Está basado en una percepción de un mundo real que consiste en una colección de objetos básicos, denominados entidades, y de relaciones entre estos objetos. El modelo relaciona es un modelo de menor nivel. Usa una colección de tablas para representar tanto los datos como las relaciones entre los datos. Su simplicidad conceptual ha conducido a su adopción general; actualmente, una vasta mayoría de productos de bases de datos se basan en el modelo relacional. Los diseñadores formulan generalmente el diseño del esquema de la base de datos modelando primero los datos en alto nivel, usando el modelo E-R, y después traduciéndolo al modelo relacional. Se estudiarán otros modelos de datos más tarde en este libro. El modelo de datos orientado a objetos, por ejemplo, extiende la representación de entidades añadiendo nociones de encapsulación, métodos (funciones) e identidad de objeto. El modelo de datos relacional orientado a objetos combina características del modelo de datos orientado a objetos y del modelo de datos relacional.

MODELO ENTIDAD-RELACIÓN

EL modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real consistente en objetos básicos llamados entidades y de relaciones entre estos objetos. Se desarrolló para facilitar el diseño de bases de datos permitiendo la especificación de un esquema de la empresa que representa la estructura lógica completa de una base de datos. El modelo de datos E-R es uno de los diferentes modelos de datos semánticos; el aspecto semántico del modelo yace en la representación del significado de los datos. El modelo E-R es extremadamente útil para hacer corresponder los significados e interacciones de las empresas del mundo real con un esquema conceptual. Debido a esta utilidad, muchas herramientas de diseño de bases de datos se basan en los conceptos del modelo E-R.

Un esquema de desarrollo E-R puede definir ciertas restricciones a las que los contenidos de la base de datos se deben adaptar. En este apartado se examina la correspondencia de cardinalidades y las restricciones de participación, que son dos de los tipos más importantes de restricciones.

2.2.1. Correspondencia de cardinalidades

La correspondencia de cardinalidades, o razón de cardinalidad, expresa el número de entidades a las que otra entidad puede estar asociada vía un conjunto de relaciones. La correspondencia de cardinalidades es la más útil describiendo conjuntos de relaciones binarias, aunque ocasionalmente contribuye a la descripción de conjuntos de relaciones que implican más de dos conjuntos de entidades. Este apartado se centrará en conjuntos de relaciones binarias únicamente. Para un conjunto de relaciones binarias R entre los conjuntos de entidades A y B, la correspondencia de cardinalidades debe ser una de las siguientes:

Uno a uno. Una entidad en A se asocia con a lo sumo una entidad en B, y una entidad en B se asocia con a lo sumo una entidad en A director de la sucursal Navacerrada. Santos también podría actuar como auditor de la sucursal Centro, que estaría representado por otra relación. Podría haber otra relación entre Gómez, Centro y cajero, indicando que Gómez actúa como cajero en la sucursal Centro. El número de conjuntos de entidades que participan en un conjunto de relaciones es también el grado del conjunto de relaciones. Un conjunto de relaciones binario tiene grado 2; un conjunto de relaciones ternario tiene grado 3.

• Uno a varios. Una entidad en A se asocia con cualquier número de entidades en B (ninguna o varias). Una entidad en B, sin embargo, se puede asociar con a lo sumo una entidad en A.

• Varios a uno. Una entidad en A se asocia con a lo sumo una entidad en B. Una entidad en B, sin embargo, se puede asociar con cualquier número de entidades (ninguna o varias) en A

• Varios a varios. Una entidad en A se asocia con cualquier número de entidades (ninguna o varias) en B, y una entidad en B se asocia con cualquier número de entidades (ninguna o varias) en A

**TEMARIO**

**Unidad 1** **Sistemas Gestores de Bases de Datos.**

** --1.3 Modelos de datos. **


 * Modelo de programación consistente:** A todos los servicios y facilidades ofrecidos Por CLR se accede de la misma forma: a través de un modelo de programación orientado a objetos. Esto es una diferencia importante respecto al modo de acceso a los servicios ofrecidos por algunos sistemas operativos actuales (por ejemplo, los de la familia Windows), en los que a algunos servicios se accede a través de llamadas a funciones globales definidas en DLL y a otros a través de objetos (objetos COM en el caso de la familia Windows).


 * Modelo de programación sencillo:** Con CLR desaparecen muchos elementos complejos incluidos en los sistemas operativos actuales (registro de Windows, GUIDs, HRESULTS, IUnknown, etc.). CLR no es que abstraiga al programador de estos conceptos, sino que son conceptos que no existen en la plataforma .NET.


 * modelo de datos**: una colección de herramientas conceptuales para describir los datos, las relaciones, la semántica y las restricciones de consistencia. Para ilustrar el concepto de un modelo de datos, describimos dos modelos de datos en este apartado: el modelo entidadrelación y el modelo relacional. Los diferentes modelos de datos que se han propuesto se clasifican en tres grupos diferentes: modelos lógicos basados en objetos, modelos lógicos basados en registros y modelos físicos.

**Modelo entidad-relación** El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real que consta de una colección de objetos básicos, llamados //entidades//, y de //relaciones// entre estos objetos. Una entidad es una «cosa» u «objeto» en el mundo real que es distinguible de otros objetos. Por ejemplo, cada persona es una entidad, y las cuentas bancarias pueden ser consideradas entidades. Las entidades se describen en una base de datos mediante un conjunto de **atributos**. Por ejemplo, los atributos //número-cuenta// y //saldo// describen una cuenta particular de un banco y pueden ser atributos del conjunto de entidades //cuenta//. Análogamente, los atributos //nombre-cliente//, //calle-cliente// y //ciudad-cliente// pueden describir una entidad //cliente//. Un atributo extra, //id-cliente//, se usa para identificar unívocamente a los clientes (dado que puede ser posible que haya dos clientes con el mismo nombre, dirección y ciudad. Se debe asignar un identificador único de cliente a cada cliente. En los Estados Unidos, muchas empresas utilizan el número de la seguridad social de una persona (un número único que el Gobierno de los Estados Unidos asigna a cada persona en los Estados Unidos) como identificador de cliente*. Una **relación** es una asociación entre varias entidades. Por ejemplo, una relación //impositor// asocia un cliente con cada cuenta que tiene.

El conjunto de todas las entidades del mismo tipo, y el conjunto de todas las relaciones del mismo tipo, se denominan respectivamente **conjunto de entidades** y **conjunto de relaciones**. La estructura lógica general de una base de datos se puede expresar gráficamente mediante un //diagrama// ER, que consta de los siguientes componentes:
 * • Rectángulos**, que representan conjuntos de entidades.
 * • Elipses**, que representan atributos.
 * • Rombos**, que representan relaciones entre conjuntos de entidades.
 * • Líneas**, que unen los atributos con los conjuntos de entidades y los conjuntos de entidades con las relaciones.

Cada componente se etiqueta con la entidad o relación que representa. Como ilustración, considérese parte de una base de datos de un sistema bancario consistente en clientes y cuentas que tienen esos clientes



**Modelo relacional** En el modelo relacional se utiliza un grupo de tablas para representar los datos y las relaciones entre ellos. Cada tabla está compuesta por varias columnas, y cada columna tiene un nombre único. En la Figura 1.3 se presenta un ejemplo de base de datos relacional consistente en tres tablas: la primera muestra los clientes de un banco, la segunda, las cuentas, y la tercera, las cuentas que pertenecen a cada cliente.

La primera tabla, la tabla //cliente//, muestra, por ejemplo, que el cliente cuyo identificador es 19.283.746 se llama González y vive en la calle Arenal sita en La Granja. La segunda tabla, //cuenta//, muestra que las cuentas C-101 tienen un saldo de 500 € y la C-201 un saldo de 900 € respectivamente. La tercera tabla muestra las cuentas que pertenecen a cada cliente. Por ejemplo, la cuenta C-101 pertenece al cliente cuyo identificador es 19.283.746 (González), y los clientes 19.283.746 (González) y 01.928.374 (Gómez) comparten el número de cuenta A-201 (pueden compartir un negocio). El modelo relacional es un ejemplo de un modelo basado en registros. Los modelos basados en registros se denominan así porque la base de datos se estructura en registros de formato fijo de varios tipos. Cada tabla contiene registros de un tipo particular. Cada tipo de registro define un número fijo de campos, o atributos. Las columnas de la tabla corresponden a los atributos del tipo de registro. No es difícil ver cómo se pueden almacenar las tablas en archivos. Por ejemplo, un carácter especial (como una coma) se puede usar para delimitar los diferentes atributos de un registro, y otro carácter especial (como un carácter de nueva línea) se puede usar para delimitar registros. El modelo relacional oculta tales detalles de implementación de bajo nivel a los desarrolladores de bases de datos y usuarios. El modelo de datos relacional es el modelo de datos más ampliamente usado, y una amplia mayoría de sistemas de bases de datos actuales se basan en el modelo relacional. Los Capítulos 3 a 7 tratan el modelo relacional en detalle. El modelo relacional se encuentra a un nivel de abstracción inferior al modelo de datos E-R. Los diseños de bases de datos a menudo se realizan en el modelo E-R, y después se traducen al modelo relacional;. Por ejemplo, es fácil ver que las tablas //cliente// y //cuenta// corresponden a los conjuntos de entidades del mismo nombre, mientras que la tabla //impositor// corresponde al conjunto de relaciones //impositor//. Nótese también que es posible crear esquemas en el modelo relacional que tengan problemas tales como información duplicada innecesariamente. Por ejemplo, supongamos que se almacena //número cuenta// como un atributo del registro //cliente//. Entonces, para representar el hecho de que las cuentas C-101 y C-201 pertenecen ambas al cliente González (con identificador de cliente 19.283.746) sería necesario almacenar dos filas en la tabla //cliente//. Los valores de //nombre-cliente//, //calle-cliente// y //ciudadcliente// de González estarían innecesariamente duplicados en las dos filas.




 * --1.4 Arquitectura del Sistema Gestor de Bases de datos. **


 * Modelo general**

Cliente-servidor

Servidor: gestiona la base de datos

Cliente: permite enviar comandos al servidor


 * Otras arquitecturas**

Múltiples capas para llegar al servidor

Distribuía

Paralela

etc.



** --1.5 Niveles de abstracción. **

Para que el sistema sea útil debe recuperar los datos eficientemente. Esta preocupación ha conducido al diseño de estructuras de datos complejas para la representación de los datos en la base de datos. Como muchos usuarios de sistemas de bases de datos no están familiarizados con computadores, los desarrolladores esconden la complejidad a los usuarios a través de varios niveles de abstracción para simplificar la interacción de los usuarios con el sistema:

**• Nivel físico:** El nivel más bajo de abstracción describe //cómo// se almacenan realmente los datos. En el nivel físico se describen en detalle las estructuras de datos complejas de bajo nivel. **• Nivel lógico:** El siguiente nivel más alto de abstracción describe //qué// datos se almacenan en la base de datos y qué relaciones existen entre esos datos. La base de datos completa se describe así en términos de un número pequeño de estructuras relativamente simples. Aunque la implementación de estructuras simples en el nivel lógico puede involucrar estructuras complejas del nivel físico, los usuarios del nivel lógico no necesitan preocuparse de esta complejidad. Los administradores de bases de datos, que deben decidir la información que se mantiene en la base de datos, usan el nivel lógico de abstracción.

**• Nivel de vistas:** El nivel más alto de abstracción describe sólo parte de la base de datos completa. A pesar del uso de estructuras más simples en el nivel lógico, queda algo de complejidad, debido a la variedad de información almacenada en una gran base de datos. Muchos usuarios del sistema de base de datos no necesitan toda esta información. En su lugar, tales usuarios necesitan acceder sólo a una parte de la base de datos. Para que su interacción con el sistema se simplifique, se define la abstracción del nivel de vistas. El sistema puede proporcionar muchas vistas para la misma base de datos. Una analogía con el concepto de tipos de datos en lenguajes de programación puede clarificar la distinción entre los niveles de abstracción. La mayoría de lenguajes de programación de alto nivel soportan la estructura de tipo registro. Por ejemplo, en un lenguaje tipo Pascal, se pueden declarar registros como sigue:

//nombre-cliente// : string; //id-cliente// : string; //calle-cliente// : string; //ciudad-cliente// : string;
 * type** //cliente// = **record**
 * end**;



Este código define un nuevo registro llamado //cliente// con cuatro campos. Cada campo tiene un nombre yun tipo asociado a él. Una empresa bancaria puede tenervarios tipos de registros, incluyendo • //cuenta//, con campos //número-cuenta// y //saldo// • //empleado//, con campos //nombre-empleado// y //sueldo// En el nivel físico, un registro //cliente//, //cuenta// o //empleado// se puede describir como un bloque de posicionesalmacenadas consecutivamente (por ejemplo, palabraso bytes). El compilador del lenguaje esconde este nivelde detalle a los programadores. Análogamente, el sistemade base de datos esconde muchos de los detallesde almacenamiento de nivel inferior a los programadoresde bases de datos. Los administradores de bases dedatos pueden ser conscientes de ciertos detalles de laorganización física de los datos.En el nivel lógico cada registro de este tipo se describemediante una definición de tipo, como se ha ilustradoen el fragmento de código previo, y se define larelación entre estos tipos de registros. Los programadores,cuando usan un lenguaje de programación, trabajanen este nivel de abstracción. De forma similar, losadministradores de bases de datos trabajan habitualmenteen este nivel de abstracción. Finalmente, en el nivel de vistas, los usuarios de computadores ven un conjunto de programas de aplicación que esconden los detalles de los tipos de datos. Análogamente, en el nivel de vistas se definen varias vistas de una base de datos y los usuarios de la misma ven única y exclusivamente esas vistas. Además de esconder detalles del nivel lógico de la base de datos, las vistas también proporcionan un mecanismo de seguridad para evitar que los usuarios accedan a ciertas partes de la base de datos. Por ejemplo, los cajeros de un banco ven únicamente la parte de la base de datos que tiene información de cuentas de clientes; no pueden acceder a la información referente a los sueldos de los empleados.

** --1.6 Tipos de usuarios. **

Un objetivo principal de un sistema de bases de datos es recuperar información y almacenar nueva información en la base de datos. Las personas que trabajan con una base de datos se pueden catalogar como usuarios de bases de datos o como administradores de bases de datos.

**Usuarios de bases de datos e interfaces de usuario** Hay cuatro tipos diferentes de usuarios de un sistemade base de datos, diferenciados por la forma en que ellos esperan interactuar con el sistema. Se han diseñado diferentes tipo de interfaces de usuario para diferentes tipos de usuarios.

**• Usuarios normales.** Son usuarios no sofisticados que interactúan con el sistema mediante la invocación de alguno de los programas de aplicación permanentes que se ha escrito previamente. Por ejemplo, un cajero bancario que necesita transferir 50 € de la cuenta //A// a la cuenta //B// invoca un programa llamado //transferir//. Este programa pide al cajero el importe de dinero a transferir, la cuenta de la que el dinero va a ser transferido y la cuenta a la que el dinero va a ser transferido. Como otro ejemplo, considérese un usuario que desee encontrar su saldo de cuenta en World Wide Web. Tal usuario podría acceder a un formulario en el que introduce su número de cuenta. Un programa de aplicación en el servidor Web recupera entonces el saldo de la cuenta, usando el número de cuenta proporcionado, y pasa la información al usuario. La interfaz de usuario normal para los usuarios normales es una interfaz de formularios, donde el usuario puede rellenar los campos apropiados del formulario. Los usuarios normales pueden también simplemente leer //informes// generados de la base de datos.

**• Programadores de aplicaciones.** Son profesionales informáticos que escriben programas de aplicación. Los programadores de aplicaciones pueden elegir entre muchas herramientas para desarrollar interfaces de usuario. Las herramientas de **desarrollo rápido de aplicaciones (DRA)** son herramientas que permiten al programador de aplicaciones construir formularios e informes sin escribir un programa. Hay también tipos especiales de lenguajes de programación que combinan estructuras de control imperativo (por ejemplo, para bucles for, bucles while e instrucciones ifthen- else) con instrucciones del lenguaje de manipulación de datos. Estos lenguajes, llamados a veces //lenguajes de cuarta generación//, a menudo incluyen características especiales para facilitar la generación de formularios y la presentación de datos en pantalla. La mayoría de los sistemas de bases de datos comerciales incluyen un lenguaje de cuarta generación.

**• Los usuarios so****fi****sticados** interactúan con el sistema sin programas escritos. En su lugar, ellos forman sus consultas en un lenguaje de consulta de bases de datos. Cada una de estas consultas se envía al //procesador de consultas//, cuya función es transformar instrucciones LMD a instrucciones que el gestor de almacenamiento entienda. Los analistas que envían las consultas para explorar los datos en la base de datos entran en esta categoría. Las herramientas de **procesamiento analítico****en línea (OLAP, Online Analytical Processing)** simplifican la labor de los analistas permitiéndoles ver resúmenes de datos de formas diferentes. Por ejemplo, un analista puede ver las ventas totales por región (por ejemplo, norte, sur, este y oeste), o por producto, o por una combinación de la región y del producto (es decir, las ventas totales de cada producto en cada región). Las herramientas también permiten al analista seleccionar regiones específicas, examinar los datos con más detalle (por ejemplo, ventas por ciudad dentro de una región) o examinar los datos con menos detalle (por ejemplo, agrupando productos por categoría). Otra clase de herramientas para los analistas son las herramientas de **recopilación de datos**, que les ayudan a encontrar ciertas clases de patrones de datos. En el Capítulo 22 se estudiarán las herramientas de recopilación de datos.

**• Usuarios especializados.** Son usuarios sofisticados que escriben aplicaciones de bases de datos especializadas que no son adecuadas en el marco de procesamiento de datos tradicional. Entre estas aplicaciones están los sistemas de diseño asistido por computador, sistemas de bases de conocimintos y sistemas expertos, sistemas que almacenan los datos con tipos de datos complejos (por ejemplo, datos gráficos y datos de audio) y sistemas de modelado del entorno. **Administrador de la base de datos** Una de las principales razones de usar SGBDs es tener un control centralizado tanto de los datos como de los programas que acceden a esos datos. La persona que tiene este control central sobre el sistema se llama **administrador****de la base de datos (ABD)**. Las funciones del ABD incluyen las siguientes:

**• De****fi****nición del esquema.** El ABD crea el esquema original de la base de datos escribiendo un conjunto de instrucciones de definición de datos en el LDD. **• De****fi****nición de la estructura y del método de acceso.** **• Modi****fi****cación del esquema y de la organización física.** Los ABD realizan cambios en el esquemay en la organización física para reflejar las necesidadescambiantes de la organización, o para alterar la organización física para mejorar el rendimiento.

**• Concesión de autorización para el acceso a los datos.** La concesión de diferentes tipos de autorizaciónpermite al administrador de la base de datosdeterminar a qué partes de la base de datos puedeacceder cada usuario. La información de autorizaciónse mantiene en una estructura del sistema especialque el sistema de base de datos consulta cuandose intenta el acceso a los datos en el sistema.

**• Mantenimiento rutinario.** Algunos ejemplos de actividades rutinarias de mantenimiento del administrador de la base de datos son: — Copia de seguridad periódica de la base de datos, bien sobre cinta o sobre servidores remotos, para prevenir la pérdida de datos en caso de desastres como inundaciones.

** --1.7 Tipos de lenguajes. **

Un sistema de bases de datos proporciona un **lenguaje de de****fi****nición de datos** para especificar el esquema de la basede datos y un **lenguaje de manipulación de datos** paraexpresar las consultas a la base de datos y las modificaciones.En la práctica, los lenguajes de definición y manipulaciónde datos no son dos lenguajes separados; en sulugar simplemente forman partes de un único lenguaje debases de datos, tal como SQL, ampliamente usado.

**Lenguaje de definición de datos** Un esquema de base de datos se especifica mediante un conjunto de definiciones expresadas mediante un lenguaje especial llamado **lenguaje de de****fi****nición de datos****(LDD)**. Por ejemplo, la siguiente instrucción en el lenguaje SQL define la tabla //cuenta//: **create table** //cuenta// (//número-cuenta// **char**(10), //saldo// **integer**) La ejecución de la instrucción LDD anterior crea latabla //cuenta//. Además, actualiza un conjunto especial detablas denominado **diccionario de datos** o **directorio****de datos**. Un diccionario de datos contiene **metadatos**, es decir, datos acerca de los datos. El esquema de una tabla es un ejemplo de metadatos. Un sistema de base de datos consulta el diccionario de datos antes de leer o modificar los datos reales. Especificamos el almacenamiento y los métodos de acceso usados por el sistema de bases de datos por un conjunto de instrucciones en un tipo especial de LDD denominado lenguaje de **almacenamiento y de****fi****nición****de datos**. Estas instrucciones definen los detalles de implementación de los esquemas de base de datos, que se ocultan usualmente a los usuarios. Los valores de datos almacenados en la base de datos deben satisfacer ciertas **restricciones de consistencia**. Por ejemplo, supóngase que el saldo de una cuenta no debe caer por debajo de 100 €. El LDD proporciona facilidades para especificar tales restricciones. Los sistemas de bases de datos comprueban estas restricciones cada vez que se actualiza la base de datos.

**Lenguaje de manipulación de datos** La **manipulación de datos** es: • La recuperación de información almacenada en la base de datos. • La inserción de información nueva en la base de datos. • El borrado de información de la base de datos. • La modificación de información almacenada en la base de datos. Un **//lenguaje de manipulación de datos//** **(LMD)** es un lenguaje que permite a los usuarios acceder o manipular los datos organizados mediante el modelo de datos apropiado. Hay dos tipos básicamente:

**• LMDs procedimentales.** Requieren que el usuario especifique //qué// datos se necesitan y //cómo// obtener esos datos.

**• LMDs declarativos** (también conocidos como LMDs **no procedimentales**). Requieren que el usuario especifique //qué// datos se necesitan //sin// especificar cómo obtener esos datos. Los LMDs declarativos son más fáciles de aprender y usar que los LMDs procedimentales. Sin embargo, como el usuario no especifica cómo conseguir los datos, el sistema de bases de datos tiene que determinar un medio eficiente de acceder a los datos. El componente LMD del lenguaje SQL es no procedimental.

media type="youtube" key="SyOPFbJOyOI" width="425" height="350" align="center"

**Unidad 2** **Diseño de Bases de Datos y el modelo E-R.**

** --2.1 El Proceso de Diseño. ** En otras unidades hemos aprendido cómo es una base de datos relacional y hemos estudiado un lenguaje, el SQL, que nos proporciona mecanismos para crear estas bases de datos, así como para actualizarlas y consultarlas. Sin embargo, todavía debemos resolver algunas cuestiones fundamentales para poder emplear la tecnología de las bases de datos relacionales; por ejemplo, cómo se puede decidir qué relaciones debe tener una base de datos determinada o qué atributos deben presentar las relaciones, qué claves primarias y qué claves foráneas se deben declarar, etc. La tarea de tomar este conjunto de decisiones recibe el nombre de //diseñar la base de datos//. Una base de datos sirve para almacenar la información que se utiliza en un sistema de información determinado. Las necesidades y los requisitos de los futuros usuarios del sistema de información se deben tener en cuenta para poder tomar adecuadamente las decisiones anteriores. Si recordáis los tres mundos presentados –el real, el conceptual y el de las representaciones observaréis que el diseño de una base de datos consiste en la obtención de una representación informática concreta a partir del estudio del mundo real de interés.

**1.1. Etapas del diseño de bases de datos** 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. En resumen, el diseño de una base de datos consiste en definir la estructura de los datos que debe tener la base de datos de un sistema de información determinado. En el caso relacional, esta estructura será un conjunto de esquemas de relación con sus atributos, dominios de atributos, claves primarias, claves foráneas, etc. 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 entidad interrelació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.

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.

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.

** --2.2 Modelo Entidad-Relación. ** El modelo de datos **entidad-relación (E-R)** está basado en una percepción del mundo real consistente en objetos básicos llamados //entidades// y de //relaciones// entre estos objetos. Se desarrolló para facilitar el diseño de bases de datos permitiendo la especificación de un //esquema de la empresa// que representa la estructura lógica completa de una base de datos. El modelo de datos E-R es uno de los diferentes modelos de datos semánticos; el aspecto semántico del modelo yace en la representación del significado de los datos. El modelo E-R es extremadamente útil para hacer corresponder los significados e interacciones de las empresas del mundo real con un esquema conceptual. Debido a esta utilidad, muchas herramientas de diseño de bases de datos se basan en los conceptos del modelo E-R.

** --2.3 Restricciones. ** Un esquema de desarrollo E-R puede definir ciertas restricciones a las que los contenidos de la base de datos se deben adaptar. En este apartado se examina la correspondencia de cardinalidades y las restricciones de participación, que son dos de los tipos más importantes de restricciones. **Correspondencia de cardinalidades** La **correspondencia de cardinalidades**, o razón de cardinalidad, expresa el número de entidades a las que otra entidad puede estar asociada vía un conjunto de relaciones. La correspondencia de cardinalidades es la más útil describiendo conjuntos de relaciones binarias, aunque ocasionalmente contribuye a la descripción de conjuntos de relaciones que implican más de dos conjuntos de entidades. Este apartado se centrará en conjuntos de relaciones binarias únicamente. Para un conjunto de relaciones binarias //R// entre los conjuntos de entidades //A// y //B,// la correspondencia de cardinalidades debe ser una de las siguientes: • **Uno a uno**. Una entidad en //A// se asocia con //a lo sumo// una entidad en //B//, y una entidad en //B// se asocia con //a lo sumo// una entidad en //A// • **Uno a varios**. Una entidad en //A// se asocia con cualquier número de entidades en //B// (ninguna o varias). Una entidad en //B//, sin embargo, se puede asociar con //a lo sumo// una entidad en //A// • **Varios a uno**. Una entidad en //A// se asocia con //a lo sumo// una entidad en //B//. Una entidad en //B//, sin embargo,se puede asociar con cualquier número de entidades(ninguna o varias) en //A// • **Varios a varios**. Una entidad en //A// se asocia con cualquier número de entidades (ninguna o varias) en //B//, y una entidad en //B// se asocia con cualquier número de entidades (ninguna o varias) en //A//



**Restricciones de participación**

La participación de un conjunto de entidades //E// en un conjunto de relaciones //R// se dice que es **total** si cada entidad en //E// participa al menos en una relación en R//.// Si sólo algunas entidades en //E// participan en relaciones en //R//, la participación del conjunto de entidades //E// en la relación //R// se llama **parcial**. Por ejemplo, se puede esperar que cada entidad //préstamo// esté relacionada con al //Prima//menos un cliente mediante la relación //prestatario//. Por lo tanto, la participación de //préstamo// en el conjunto de relaciones //prestatario// es total. En cambio, un individuo puede ser cliente de un banco tenga o no tenga un préstamo en el banco. Así, es posible que sólo algunas de las entidades //cliente// estén relacionadas con el conjunto de entidades //préstamo// mediante la relación //prestatario//, y la participación de //cliente// en el conjunto de relaciones //prestatario// es por lo tanto parcial.

** --2.4 Diagramas E-R. ** En este apartado trataremos el diseño conceptual de una base de datos mediante el modelo ER. Lo que explicaremos es aplicable al diseño de cualquier tipo de bases de datos –relacional, jerárquica, etc.–, porque, como ya hemos dicho, en la etapa del diseño conceptual todavía no se tiene en cuenta la tecnología concreta que se utilizará para implementar la base de datos. El modelo ER es uno de los enfoques de modelización de datos que más se utiliza actualmente por su simplicidad y legibilidad. Su legibilidad se ve favorecida porque proporciona una notación diagramática muy comprensiva. Es una herramienta útil tanto para ayudar al diseñador a reflejar en un modelo conceptual los requisitos del mundo real de interés como para comunicarse con el usuario final sobre el modelo conceptual obtenido y, de este modo, poder verificar si satisface sus requisitos. El modelo ER resulta fácil de aprender y de utilizar en la mayoría de las aplicaciones. Además, existen herramientas informáticas de ayuda al diseño (herramientas CASE*) que utilizan alguna variante del modelo ER para hacer el diseño de los datos. El nombre completo del modelo ER es //entity-relationship//, y proviene del hecho de que los principales elementos que incluye son las entidades y las interrelaciones (//entities// y //relationships//). Traduciremos este nombre por ‘entidad-interrelación’. El origen del modelo ER se encuentra en trabajos efectuados por Peter Chen en 1976. Posteriormente, muchos otros autores han descrito variantes y/o extensiones de este modelo. Así pues, en la literatura se encuentran muchas formas diferentes del modelo ER que pueden variar simplemente en la notación diagramática o en algunos de los conceptos en que se basan para modelizar los datos. Cuando se quiere utilizar el modelo ER para comunicarse con el usuario, es recomendable emplear una variante del modelo que incluya sólo sus elementos más simples –entidades, atributos e interrelaciones– y, tal vez, algunas construcciones adicionales, como por ejemplo entidades débiles y dependencias de existencia. Éstos eran los elementos incluidos en el modelo original propuesto por Chen. En cambio, para llevar a cabo la tarea de modelizar propiamente dicha, suele ser útil usar un modelo ER más completo que incluya construcciones más avanzadas que extienden el modelo original. Según la noción de //modelo de datos// que hemos utilizado en los otros módulos, un modelo de datos tiene en cuenta tres aspectos de los datos: la estructura, la manipulación y la integridad. Sin embargo, el modelo ER habitualmente se

**El modelo entidadinterrelación** Algunos autores denominan //entidad-relación// al modelo ER, pero en nuestro caso hemos preferido traducir //relationship// por ‘interrelación’ y no por ‘relación’, con el objetivo de evitar confusiones entre este concepto y el de //relación// que se utiliza en el modelo relacional. utiliza para reflejar aspectos de la estructura de los datos y de su integridad,pero no de su manipulación.

Como se vio brevemente en el Apartado 1.4, la estructura lógica general de una base de datos se puede expresar gráficamente mediante un **diagrama E-R**. Los diagramas son simples y claros, cualidades que pueden ser responsables del amplio uso del modelo E-R. Tal diagrama consta de los siguientes componentes principales:

**• Rectángulos**, que representan conjuntos de entidades. **• Elipses**, que representan atributos. **• Rombos**, que representan relaciones. **• Líneas**, que unen atributos a conjuntos de entidades y conjuntos de entidades a conjuntos de relaciones. **• Elipses dobles**, que representan atributos multivalorados. **• Elipses discontinuas**, que denotan atributos derivados. **• Líneas dobles**, que indican participación total de una entidad en un conjunto de relaciones. **• Rectángulos dobles**, que representan conjuntos de entidades débiles

Considérese el diagrama entidad-relación de la Figura 2.8, que consta de dos conjuntos de entidades, //cliente// y //préstamo//, relacionadas a través de un conjunto de relaciones binarias //prestatario//. Los atributos asociados con //cliente// son //id-cliente//, //nombre-cliente//, //calle-cliente//, y //ciudad-cliente//. Los atributos asociados con //préstamo// son //número-préstamo// e //importe//. Como se muestra en la Figura 2.8, los atributos de un conjunto de entidades que son miembros de la clave primaria están subrayados. El conjunto de relaciones //prestatario// puede ser varios a varios, uno a varios, varios a uno o uno a uno. Para distinguir entre estos tipos, se dibuja o una línea dirigida (→) o una línea no dirigida (—) entre el conjunto de relaciones y el conjunto de entidades en cuestión. **•** Una línea dirigida desde el conjunto de relaciones //prestatario// al conjunto de entidades //préstamo// espevarios.



** --2.5 Diseño con diagramas E-R. ** **•** Una línea no dirigida desde el conjunto de relaciones //prestatario// al conjunto de relaciones //préstamo// especifica que //prestatario// es o bien un conjunto de relaciones varios a varios, o bien uno a varios, desde //cliente// a //préstamo//. Volviendo al diagrama E-R de la Figura 2.8, se ve que el conjunto de relaciones //prestatario// es varios a varios. Si el conjunto de relaciones //prestatario// fuera uno a varios, desde //cliente// a //préstamo//, entonces la línea desde //prestatario// a //cliente// sería dirigida, con una flecha apuntando al conjunto de entidades //cliente// (Figura 2.9a). Análogamente, si el conjunto de relaciones //pres-tatario// fuera varios a uno desde //cliente// a //préstamo//, entonces la línea desde //prestatario// a //préstamo// tendría una flecha apuntando al conjunto de entidades //préstamo// (Figura 2.9b). Finalmente, si el conjunto de relaciones //prestatario// fuera uno a uno, entonces ambas líneas desde //prestatario// tendrían flechas: una apuntando al conjunto de entidades //préstamo// y otra apuntando al conjunto de entidades //cliente// (Figura 2.9c). Si un conjunto de relaciones tiene también algunos atributos asociados a él, entonces se unen esos atributos a ese conjunto de relaciones. Por ejemplo, en la Figura 2.10, se tiene el atributo descriptivo //fecha-acceso// unido al conjunto de relaciones //impositor// para especificar la fecha más reciente en la que un cliente accedió a esa cuenta. La Figura 2.11 muestra cómo se pueden representar atributos compuestos en la notación E-R. Aquí, el atributo compuesto //nombre//, con atributos componentes //nombre-pila//, //primer-apellido// y //segundo-apellido// reemplaza al atributo simple //nombre-cliente// de //cliente//. También se muestra el atributo compuesto //dirección//, cuyos atributos componentes son //calle//, //ciudad//, //provincia// y //código-postal//, que reemplaza a los atributos //calle-cliente// y //ciudad-cliente// de //cliente//. El atributo //calle// es por si mismo un atributo compuesto cuyos atributos componentes son //número-calle//, //nombre-calle// y //número-piso//. La Figura 2.11 también muestra un atributo multivalorado, //número-teléfono//, indicado por una elipse doble, y un atributo derivado //edad//, indicado por una elipse discontinua. En los diagramas E-R se indican papeles mediante etiquetas en las líneas que unen rombos con rectángulos. En la Figura 2.12 se muestran los indicadores de papeles //director// y //trabajador// entre el conjunto de entidades //empleado// y el conjunto de relaciones //trabaja para//. Los conjuntos de relaciones no binarias se pueden especificar fácilmente en un diagrama E-R. La Figura 2.13 consta de tres conjuntos de entidades //cliente//, //trabajo// y //sucursal//, relacionados a través del conjunto de relaciones //trabaja-en//. Se pueden especificar algunos tipos de relaciones varios a uno en el caso de conjuntos de relaciones no binarias. Supóngase un empleado que tenga a lo sumo un trabajo en cada sucursal (por ejemplo, Santos no puede ser director y auditor en la misma sucursal). Esta restricción se puede especificar con una flecha apuntando a //trabajo// en el borde de //trabaja-en//.



** --2.6 Conjunto de entidades débiles. ** Un conjunto de entidades puede no tener suficientes atributos para formar una clave primaria. Tal conjunto de entidades se denomina **conjunto de entidades débiles**. Un conjunto de entidades que tiene una clave primaria se denomina **conjunto de entidades fuertes**. Como ilustración, considérese el conjunto de entidades //pago//, que tiene los tres atributos: //número-pago,////fecha-pago// e //importe-pago//. Los números de pago son generalmente números secuenciales, empezando por 1, generados por separado por cada préstamo. Así, aunque cada entidad //pago// es distinta, los pagos para diferentes préstamos pueden compartir el mismo número de pago. Así, este conjunto de entidades no tiene una clave primaria; es un conjunto de entidades débiles. Para que un conjunto de entidades débiles tenga sentido, debe estar asociada con otro conjunto de entidades, denominado el **conjunto de entidades identi****fi****cadoras** o **propietarias**. Cada entidad débil debe estar asociada con una entidad identificadora; es decir, se dice que el conjunto de entidades débiles **depende existencialmente** del conjunto de entidades identificadoras. Sedice que el conjunto de entidades identificadoras es **propietaria** del conjunto de entidades débiles que identifica.La relación que asocia el conjunto de entidades débilescon el conjunto de entidades identificadoras sedenomina **relación identi****fi****cadora**. La relación identificadoraes varios a uno del conjunto de entidades débilesal conjunto de entidades identificadoras y la participacióndel conjunto de entidades débiles en la relaciónes total. En nuestro ejemplo, el conjunto de entidades identificador para //pago// es //préstamo//, y la relación //préstamo-////pago// que asocia las entidades //pago// con sus correspondientes entidades //préstamo// es la relación identificadora. Aunque un conjunto de entidades débiles no tiene clave primaria, no obstante se necesita conocer un medio para distinguir todas aquellas entidades del conjunto de entidades que dependen de una entidad fuerte particular. El **discriminante** de un conjunto de entidades débiles es un conjunto de atributos que permite que esta distinción se haga. Por ejemplo, el discriminante del conjunto de entidades débiles //pago// es el atributo //número-pago//, ya que, para cada préstamo, un número de pago identifica de forma única cada pago para ese préstamo. El discriminante de un conjunto de entidades débiles se denomina la //clave parcial// del conjunto de entidades. La clave primaria de un conjunto de entidades débiles se forma con la clave primaria del conjunto de entidades identificadoras, más el discriminante del conjunto de entidades débiles. En el caso del conjunto de entidades //pago//, su clave primaria es {//número-préstamo//, //número-pago//}, donde //número-préstamo// es la clave primaria del conjunto de entidades identificadoras, es decir, //préstamo//, y //número-pago// distingue las entidades //pago// dentro del mismo préstamo. El conjunto de entidades identificadoras no debería tener atributos descriptivos, ya que cualquier atributo requerido puede estar asociado con el conjunto de enti//nombre-e//dades débiles Un conjunto de entidades débiles puede participar en relaciones distintas de relaciones identificadoras. Por ejemplo, la entidad //pago// podría participar en una relación con el conjunto de entidades con el conjunto de entidades //cuenta//, identificando la cuenta desde la que se realizó el pago. Un conjunto de entidades débiles puede participar como propietario en una relación identificadora con otro conjunto de entidades débiles. También es posible tener un conjunto de entidades débiles con más de un conjunto de entidades identificadoras. Una entidad débil en concreto podría ser identificada por una combinación de entidades, una de cada conjunto de entidades identificadoras. La clave primaria de la entidad débil consistiría de la unión de las claves primarias de los conjuntos de entidades identificadoras más el discriminante del conjunto de entidades débiles. Un conjunto de entidades débiles se indica en los diagramas E-R mediante un rectángulo dibujado con una línea doble y la correspondiente relación de identificación mediante un rombo dibujado con línea doble. En la Figura 2.16, el conjunto de entidades débiles //pago// es dependiente del conjunto de entidades fuertes //préstamo// a través del conjunto de relaciones //pago-préstamo//. La figura ilustra también el uso de líneas dobles para indicar //participación total//; la participación del conjunto de entidades (débiles) //pago// en la relación //pago-préstamo// es total, significando que cada pago debe estar relacionando a través de //pago-préstamo// con alguna cuenta. Finalmente, la flecha desde //pago-préstamo// a //préstamo// indica que cada pago es para un único préstamo. El discriminante del conjunto de entidades débiles también está subrayado, pero con un línea discontinua, en lugar de una continua. En algunos casos, el diseñador de la base de datos puede elegir expresar un conjunto de entidades débiles como un atributo compuesto multivalorado del conjunto de entidades propietarias. En el ejemplo, esta alternativa requeriría que el conjunto de entidades //préstamo// tuviera un atributo compuesto y multivalorado //pago//, que constara de //número-pago//, //fecha-pago// e //importepago//. Un conjunto de entidades débiles se puede modelar más adecuadamente como un atributo si sólo participa en la relación identificadora y si tiene pocos atributos. Alternativamente, una representación de conjunto de entidades débiles será más adecuada para modelar una situación en la que el conjunto participe en otras relaciones además de la relación identificadora y donde el conjunto de entidades débiles tenga muchos atributos. Como otro de un conjunto de entidades que se puede modelar como un conjunto de entidades débiles considérense las ofertas de asignaturas en una universidad. La misma asignatura se puede ofrecer en diferentes cursos y dentro de un curso puede haber varios grupos para la misma asignatura. Así, se crea un conjunto de entidades débiles //oferta-asignatura//, que depende existencialmente de //asignatura//; las diferentes ofertas de la misma asignatura se identifican por un //curso// y un //número-grupo//, que forma un discriminante pero no una clave primaria.



** --2.7 Modelo E-R extendido. ** Aunque los conceptos básicos de E-R pueden modelar la mayoría de las características de las bases de datos, algunos aspectos de una base de datos pueden ser más adecuadamente expresados mediante ciertas extensiones del modelo E-R básico. En este apartado se discuten las características E-R extendidas de especialización, generalización, conjuntos de entidades de nivel más alto y más bajo, herencia de atributos y agregación.




 * Especialización**

Un conjunto de entidades puede incluir subgrupos de entidades que se diferencian de alguna forma de las otras entidades del conjunto. Por ejemplo, un subconjunto de entidades en un conjunto de entidades puede tener atributos que no son compartidos por todas las entidades del conjunto de entidades. El modelo E-R proporciona una forma de representación de estos grupos de entidades distintos. Considérese el conjunto de entidades //persona// con atributos //nombre//, //calle// y //ciudad//. Una persona puede clasificarse además como: • //cliente// • //empleado// Cada uno de estos tipos de persona se describen mediante un conjunto de atributos que incluyen los atributos del conjunto de entidades //persona// más otros posibles atributos adicionales. Por ejemplo, las entidades //cliente// se pueden describir además mediante el atributo //id-cliente//, mientras que las entidades //empleado// se pueden describir además mediante los atributos //idempleado// y //sueldo//. El proceso de designación de subgrupos dentro de un conjunto de entidades se denomina **especialización**. La especialización de //persona// permite distinguir entre las personas basándose en si son empleados o clientes. Como otro ejemplo supóngase que el banco desea dividir las cuentas en dos categorías: cuentas corrientes y cuentas de ahorro. Las cuentas de ahorro necesitan un saldo mínimo, pero el banco establece diferentes tasas de interés a cada cliente, ofreciendo mejores tasas a los clientes favorecidos. Las cuentas corrientes tienen una tasa fija de interés, pero permiten los descubiertos; el importe de descubierto de una cuenta corriente se debe registrar. El banco podría crear dos especializaciones de //cuenta//, denominadas //cuenta-ahorro// y //cuenta-corriente//. Como se vio anteriormente, las entidades //cuenta// se describen por los atributos //número-cuenta// y //saldo//. El conjunto de entidades //cuenta-ahorro// tendría todos los atributos de //cuenta// y un atributo adicional denominado //tasa-interés.// El conjunto de entidades //cuenta-corriente// tendría todos los atributos de //cuenta// y un atributo adicional //importe-descubierto//. Se puede aplicar repetidamente la especialización para refinar el esquema de diseño. Por ejemplo, los empleados del banco se pueden clasificar en uno de los siguientes: • //o////fi////cial// • //cajero// • //secretaria// Cada uno de estos tipos de empleado se describe por un conjunto de atributos que incluye todos los atributos del conjunto de entidades //empleado// más otros adicionales. Por ejemplo, las entidades //o////fi////cial// se puede describir por el atributo //número-despacho//, las entidades //cajero// por los atributos //número-sección// y //horas-semana//, y las entidades //secretaria// por el atributo //horas-semana//. Además, las entidades //secretaria// pueden participar en una relación //secretaria-de//, que identifica al empleado ayudado por una secretaria. Un conjunto de entidades se puede especializar por más de una característica distintiva. En el ejemplo, la característica distintiva entre entidades //empleado// es el trabajo que realiza el empleado. Otra especialización coexistente podría estar basada en si la persona es un trabajador temporal o fijo, resultado en los conjuntos de entidades //empleado-temporal// y //empleado-////fi////jo//. Cuando se forma más de una especialización de un conjunto de entidades, una entidad en particular puede pertenecer a varias especializaciones. Por ejemplo, una empleada dada puede ser una empleada temporal y secretaria. En términos de un diagrama E-R, la especialización se representa mediante un componente //triangular// etiquetado ES, como se muestra en la Figura 2.17. La etiqueta ES representa, por ejemplo, que un cliente «es» una persona. La relación ES se puede llamar también relación **superclase-subclase**. Los conjuntos de entidades de nivel más alto y más bajo se representan como conjuntos de entidades regulares, es decir, como rectángulos que contienen el nombre del conjunto de entidades.

**Generalización**

El refinamiento a partir de un conjunto de entidades inicial en sucesivos niveles de subgrupos de entidades representa un proceso de diseño **descendente** en el que las distinciones se hacen explícitas. El proceso de diseño puede ser también de una forma **ascendente**, en el que varios conjuntos de entidades se sintetizan en un conjunto de entidades de nivel más alto basado en características comunes. El diseñador de la base de datos puede haber identificado primero el conjunto de entidades //cliente// con los atributos //nombre//, //calle//, //ciudad// e //id-cliente//, y el conjunto de entidades //empleado// con los atributos //nombre//, //calle//, //ciudad//, //id-empleado// y //sueldo//. Hay similitudes entre el conjunto de entidades //cliente// y el conjunto de entidades //empleado// en el sentido de que tienen varios atributos en común. Esta similitud se puede expresar mediante la **generalización**, que es una relación co tenedora que existe entre el conjunto de entidades de //nivel más alto// y uno o más conjuntos de entidades de //nivel más bajo//. En el ejemplo, //persona// es el conjunto de entidades de nivel más alto y los conjuntos de entidades //cliente// y //empleado// son de nivel más bajo. Los conjuntos de entidades de nivel más alto y nivel más bajo también se pueden llamar **superclase** y **subclase**, respectivamente. El conjunto de entidades //persona// es la superclase de las subclases //cliente// y //empleado//.

Para todos los propósitos prácticos, la generalización es una inversión simple de la especialización. Se aplicarán ambos procesos en combinación en el curso del diseño del esquema E-R para una empresa. En términos del propio diagrama E-R no se distingue entre especialización y generalización. Los niveles nuevos de representación de entidades serán distinguidos (especialización) o sintetizados (generalización) cuando el esquema de diseño llegue a expresar completamente la aplicación de base de datos y los requisitos de uso de la base de datos. Las diferencias entre los dos enfoques se pueden caracterizar mediante su punto de partida y el objetivo global. La especialización parte de un conjunto de entidades simple; enfatiza las diferencias entre las entidades dentro del conjunto mediante la creación de distintos conjuntos de entidades de nivel más bajo. Estos conjuntos de entidades de nivel más bajo pueden tener atributos, o pueden participar en relaciones que no se aplican a todas las entidades del conjunto de entidades de nivel más alto. Realmente, la razón de que el diseñador aplique la especialización es representar tales características diferentes. Si //cliente// y //empleado// no tuvieran cada una atributos únicos que no tuvieran las entidades //persona// en la que participan, no habría necesidad de especializar el conjunto de entidades //persona//. La generalización procede de observar que varios conjuntos de entidades que comparten algunas características comunes (se describen mediante los mismos atributos y participan en los mismos conjuntos de relaciones). Basada en sus similitudes, la generalización sintetiza estos conjuntos de entidades en uno solo, el conjunto de entidades de nivel más alto. La generalización se usa para resaltar las similitudes entre los conjuntos de entidades de nivel más bajo y para ocultar las diferencias; también permite economizar la representación para que los atributos compartidos no estén repetidos.



**Herencia de atributos**

Una propiedad crucial de las entidades de nivel más alto y más bajo creadas mediante especialización y generalización es la **herencia de atributos**. Los atributos de los conjuntos de entidades de nivel más alto se dice que son **heredados** por los conjuntos de entidades de nivel más bajo. Por ejemplo, //cliente// y //empleado// heredan los atributos de //persona//. Así, //cliente// se describe mediante sus atributos //nombre, calle y ciudad// y adicionalmente por el atributo //id-cliente//; //empleado// se describe mediante sus atributos //nombre, calle y ciudad// y adicionalmente por los atributos //id-empleado// y //sueldo//. Un conjunto de entidades de nivel más bajo (o subclase) también hereda la participación en los conjuntos de relaciones en los que su entidad de nivel más alto (o superclase) participa. Ambos conjuntos de entidades //o////fi////cial//, //cajero// y //secretaria// participan en el conjunto de relaciones //trabaja-para//. La herencia de atributos se aplica en todas las capas de los conjuntos de entidades de nivel más bajo. Los conjuntos de entidades anteriores pueden participar cualquier relación en que participe el conjunto de entidades //persona//. Si se llega a una porción dada de un modelo E-R mediante especialización o generalización, el resultado es básicamente el mismo: • Un conjunto de entidades de nivel más alto con atributos y relaciones que se aplican a todos los conjuntos de entidades de nivel más bajo. • Conjuntos de entidades de nivel más bajo con características distintivas que se aplican sólo en un conjunto de entidades particular. En lo que sigue, aunque a menudo se hará referencia sólo a la generalización, las propiedades que se discuten pertenecen a ambos procesos. En la Figura 2.17 se describe una **jerarquía** de conjuntos de entidades. En la figura, //empleado// es un conjunto de entidades de nivel más bajo de //persona// y un conjunto de entidades de nivel más alto de los conjuntos de entidades //o////fi////cial//, //cajero// y //secretaria//. En una jerarquía, un conjunto de entidades dado puede estar implicado como un conjunto de entidades de nivel más bajo sólo en una única relación ES. Si un conjunto de entidades es un conjunto de entidades de nivel más bajo enmás de una relación ES, entonces el conjunto de entidades tiene **herencia múltiple**, y la estructura resultante se denomina //retículo//.

**Restricciones sobre las generalizaciones**

Para modelar una empresa más exactamente, el diseñador de la base de datos puede elegir colocar ciertas restricciones en una generalización particular. Un tipo de restricción implica determinar qué entidades pueden ser miembros de un conjunto de entidades de nivel más bajo dado. Tales relaciones de miembros pueden ser algunas de los siguientes:

• **De****fi****nido por condición.** En los conjuntos de entidades de nivel más bajo, la relación miembro se evalúa en función de si una entidad satisface o no una condición explícita o predicado. Por ejemplo, asúmase que el conjunto de entidades de nivel más alto //cuenta// tiene el atributo //tipo-cuenta//. Todas las entidades //cuenta// se evalúan según la definición del atributo //tipo-cuenta//. Sólo aquellas entidades que satisfagan la condición //tipo-cuenta// = «cuenta de ahorro» podrán pertenecer al conjunto de entidades de nivel más bajo //cuenta-ahorro//. Todas las entidades que satisfagan la condición //tipo-cuenta// = «cuenta corriente» estarán incluidas en //cuentacorriente//. Como todas las entidades de nivel más bajo se evalúan en función del mismo atributo (en este caso, //tipo-cuenta//), este tipo de generalización se denomina **de****fi****nido por atributo**.

• **Definido por el usuario.** Los conjuntos de entidades de nivel más bajo definidos por el usuario no están restringidos mediante una condición de miembro; en cambio, las entidades se asignan a un conjunto de entidades dado por el usuario de la base de datos. Por ejemplo, asúmase que, después de tres meses de empleo, se asignan los empleados del banco a uno de los cuatro grupos de trabajo. Los grupos se representan, por tanto, como cuatro conjuntos de entidades de nivel más bajo del conjunto de entidades de nivel más alto //empleado//. Un empleado dado no se asigna a una entidad grupo automáticamente en términos de una condición que lo defina explícitamente. En su lugar, la asignación al grupo se hace de forma individual por el usuario a cargo de la decisión. Las asignación se implementa mediante una operación que añade una entidad a un conjunto de entidades. Un segundo tipo de restricciones se define según si las entidades pueden pertenecer a más de un conjunto de entidades de nivel más bajo en una generalización simple. Los conjuntos de entidades de nivel más bajo pueden ser uno de los siguientes:

• **Disjunto.** Una //restricción sobre el carácter disjunto// requiere que una entidad no pertenezca a másde un conjunto de entidades de nivel más bajo. Enel ejemplo, una entidad //cuenta// puede satisfacer sólo una condición para el atributo //tipo-cuenta//; una entidad puede ser bien una cuenta de ahorro o bien una cuenta corriente, pero no ambas cosas a la vez. • **Solapado.** En las //generalizaciones solapadas//, la misma entidad puede pertenecer a más de un conjunto de entidades de nivel más bajo en una generalización simple. Como ilustración, tomando el ejemplo del grupo de trabajo del empleado, asúmase que ciertos directores participen en más de  un grupo de trabajo. Un empleado dado puede, por lo tanto, aparecer en más de uno de los conjuntos de entidades grupo que son conjuntos de entidades de nivel más bajo de //empleado//. Así, la generalización es solapada. Como otro ejemplo, supóngase la generalización aplicada a los conjuntos de entidades //cliente// y //empleado// conduce a un conjunto de entidades de nivel más alto //persona//. La generalización está solapada si un empleado también puede ser un cliente. La entidad de nivel más bajo solapada es el caso predeterminado; la restricción sobre el carácter disjunto se debe colocar explícitamente en una generalización (o especialización). Se puede identificar una restricción sobre el carácter disjunto en un diagrama E-R añadiendo la palabra //disjunto// en el símbolo del triángulo. Una restricción final, la **restricción de completitud** en una generalización o especialización, especifica siun conjunto de entidades de nivel más alto debe pertenecero no a al menos a uno de los conjuntos de entidadesde nivel más bajo en una generalización/especialización.Esta restricción puede ser una de las siguientes:

• **Generalización** o **especialización total.** Cada entidad de nivel más alto debe pertenecer a un conjunto de entidades de nivel más bajo. • **Generalización** o **especialización parcial.** Algunas entidades de nivel más alto pueden no pertenecer a algún conjunto de entidades de nivel más bajo. La generalización parcial es la predeterminada. Se puede especificar una generalización total en un diagrama E-R usando una línea doble para conectar el rectángulo que representa el conjunto de entidades de nivel más alto con el símbolo del triángulo (esta notación es similar a la notación de participación total en una relación). La generalización de //cuenta// es total: todas las entidades //cuenta// deben ser o bien cuentas de ahorro o bien cuentas corrientes. Debido a que el conjunto de entidades de nivel más alto alcanzado a través de la generalización está generalmente compuesta únicamente por aquellas entidades del conjunto de entidades de nivel más bajo, la restricción de completitud para un conjunto de entidades de nivel más alto generalizado es habitualmente total. Cuando la restricción es parcial, la entidad de nivel más alto no aparece necesariamente en el conjunto de entidades de nivel más bajo. Los conjuntos de entidades grupo de trabajo ilustran una especialización parcial. Como los empleados se asignan a grupos sólo después de llevar tres meses en el trabajo, algunas entidades //empleado// pueden no ser miembros de ningún conjunto de entidades grupo de nivel más bajo. Los conjuntos de entidades equipo se pueden caracterizar más completamente como una especialización de //empleado// parcial y solapada. La generalización de //cuenta-corriente// y //cuenta-ahorro// en //cuenta// es una generalización total y disjunta. Las restricciones de completitud y sobre el carácter disjunto, sin embargo, no dependen una de la otra. Los patrones de restricciones pueden ser también parcial-disjunta y total-solapada. Se puede ver que ciertos requisitos de inserción y borrado son consecuencia de las restricciones que se aplican a una generalización o especialización dada. Por ejemplo, cuando se coloca una restricción de completitud total, una entidad insertada en un conjunto de entidades de nivel más alto se debe insertar en al menos uno de los conjuntos de entidades de nivel más bajo. Con una restricción de definición por condición, todas las entidades de nivel más alto que satisfacen la condición se deben insertar en el conjunto de entidades de nivel más bajo. Finalmente, una entidad que se borra de un conjunto de entidades de nivel más alto, también se debe borrar de todos los conjuntos de entidades de nivel más bajo asociados a los que pertenezca.

**Agregación**

Una limitación del modelo E-R es que no resulta posible expresar relaciones entre relaciones. Para ilustrar la necesidad de tales construcciones considérese la relación ternaria //trabaja-en//, que se vio anteriormente, entre //empleado//, //sucursal// y //trabajo// (véase la Figura 2.13). Supóngase ahora que se desean registrar los directores para las tareas realizadas por un empleado en una sucursal; es decir, se desean registrar directores por combinaciones (//empleado//, //sucursal//, //trabajo//). Asúmase que existe una entidad //director//. Una alternativa para representar esta relación es crear una relación cuaternaria //dirige// entre //empleado//, //sucursal//, //trabajo// y //director// (se necesita una relación cuaternaria; una relación binaria entre //director// y //empleado// no permitiría representar las combinaciones [//sucursal//, //trabajo//] de un empleado que están dirigidas por un director). Al usar los constructores básicos del modelado E-R se obtiene el diagrama E-R de la Figura 2.18 (por simplicidad se han omitido los atributos). Parece que los conjuntos de relaciones //trabaja-en// y //dirige// se pueden combinar en un único conjunto de relaciones. No obstante, no se deberían combinar, dado que algunas combinaciones //empleado//, //sucursal//, //trabajo// puede que no tengan director. Hay información redundante en la figura resultante, ya que cada combinación //empleado//, //sucursal//, //trabajo// en //dirige// también lo está en //trabaja-en//. Si el director fuese un valor en lugar de una entidad //director//, se podría hacer que //director// fuese un atributo multivalorado de la relación //trabaja-en//. Pero esto implica que es más difícil (tanto lógicamente como en coste de ejecución) encontrar, por ejemplo, los triples empleado-sucursaltrabajo de los que un director es responsable. Como el director es una entidad //director//, se descarta esta alternativa en cualquier caso. La mejor forma de modelar una situación como ésta es usar la agregación. La **agregación** es una abstracción a través de la cual las relaciones se tratan como entidades de nivel más alto. Así, para este ejemplo, se considera el conjunto de relaciones //trabaja-en// (que relaciona los conjuntos de entidades //empleado//, //sucursal// y //trabajo//) como un conjunto de entidades de nivel más alto denominado //trabaja-en//. Tal conjunto de entidades se trata de la misma forma que cualquier otro conjunto de entidades. Se puede crear entonces una relación binaria //dirige// entre //trabaja-en// y //director// para representar

** --2.8 Otros aspectos del diseño de bases de datos. ** El procesamiento de datos impulsa el crecimiento de los computadores, como ocurriera en los primeros días de los computadores comerciales. De hecho, la automatización de las tareas de procesamiento de datos precede a los computadores. Las tarjetas perforadas, inventadas por Hollerith, se usaron en los principios del siglo xx para registrar los datos del censo de los EE.UU., y se usaron sistemas mecánicos para procesar las tarjetas y para tabular los resultados. Las tarjetas perforadas posteriormente se usaron ampliamente como medio para introducir datos en los computadores. Las técnicas del almacenamiento de datos han evolucionado a lo largo de los años: • **Década de 1950 y principios de la década de 1960.** Se desarrollaron las cintas magnéticas para el almacenamientode datos. Las tareas de procesamientode datos tales como las nóminas fueron automatizadas,con los datos almacenados en cintas. El procesamientode datos consistía en leer datos de unao más cintas y escribir datos en una nueva cinta. Losdatos también se podían introducir desde paquetesde tarjetas perforadas e impresos en impresoras. Porejemplo, los aumentos de sueldo se procesabanintroduciendo los aumentos en las tarjetas perforadasy leyendo el paquete de cintas perforadas en sincronizacióncon una cinta que contenía los detalles maestros de los salarios. Los registros debían estar igualmente ordenados. Los aumentos de sueldo tenían que añadirse a los sueldos leídos de la cinta maestra, y escribirse en una nueva cinta; esta nueva cinta se convertía en la nueva cinta maestra. Las cintas (y los paquetes de tarjetas perforadas) sólo se podían leer secuencialmente, y los tamaños de datos eran mucho mayores que la memoria principal; así, los programas de procesamiento de datos tenían que procesar los datos según un determinado orden, leyendo y mezclando datos de cintas y paquetes de tarjetas perforadas. • **Finales de la década de 1960 y la década de** **1970.** El amplio uso de los discos fijos a finales de la década de 1960 cambió en gran medida el escenario del procesamiento de datos, ya que los discos fijos permitieron el acceso directo a los datos. La ubicación de los datos en disco no era importante, ya que a cualquier posición del disco se podía acceder en sólo decenas de milisegundo. Los datos se liberaron de la tiranía de la secuencialidad. Con los discos pudieron desarrollarse las bases de datos de red y jerárquicas, que permitieron que las estructuras de datos tales como listas y árboles pudieran almacenarse en disco. Los programadores pudieron construir y manipular estas estructuras de datos. Un artículo histórico de Codd [1970] definió el modelo relacional y formas no procedimentales de consultar los datos en el modelo relacional, y nacieron las bases de datos relacionales. La simplicidad del modelo relacional y la posibilidad de ocultar completamente los detalles de implementación al programador fueron realmente atractivas. Codd obtuvo posteriormente el prestigioso premio Turing de la ACM (Association of Computing Machinery, asociación de maquinaria informática) por su trabajo. • **Década de 1980.** Aunque académicamente interesante, el modelo relacional no se usó inicialmente en la práctica debido a sus inconvenientes por el rendimiento; las bases de datos relacionales no pudieron competir con el rendimiento de las bases de datos de red y jerárquicas existentes. Esta situación cambió con System R, un proyecto innovador en IBM Research que desarrolló técnicas para la construcción de un sistema de bases de datos relacionales eficiente. En Astrahan et al. [1976] y Chamberlin et al. [1981] se pueden encontrar excelentes visiones generales de System R. El prototipo de System R completamente funcional condujo al primer producto de bases de datos relacionales de IBM: SQL/DS. Los primeros sistemas de bases de datos relacionales, como DB2 de IBM, Oracle, Ingres y Rdb de DEC, jugaron un importante papel en el desarrollo de técnicas para el procesamiento eficiente de consultas declarativas. En los principios de la década de 1980 las bases de datos relacionales llegaron a competir con los sistemas de bases de datos jerárquicas y de red incluso en el área de rendimiento. Las bases de datos relacionales fueron tan sencillas de usar que finalmente reemplazaron a las bases de datos jerárquicas y de red; los programadores que usaban estas bases de datos estaban forzados a tratar muchos detalles de implementación de bajo nivel y tenían que codificar sus consultas de forma procedimental. Aún más importante, debían tener presente el rendimiento durante el diseño de sus programas, lo que implicaba un gran esfuerzo. En cambio, en una base de datos relacional, casi todas estas tareas de bajo nivel se realizan automáticamente por la base de datos, liberando al programador en el nivel lógico. Desde su escalada en el dominio en la década de 1980, el modelo relacional ha conseguido el reinado supremo entre todos los modelos de datos. La década de 1980 también fue testigo de una gran investigación en las bases de datos paralelas y distribuidas, así como del trabajo inicial en las bases de datos orientadas a objetos. • **Principios de la década de 1990.** El lenguaje SQL se diseñó fundamentalmente para las aplicaciones de ayuda a la toma de decisiones, que son intensivas en consultas, mientras que el objetivo principal de las bases de datos en la década de 1980 fue las aplicaciones de procesamiento de transacciones, que son intensivas en actualizaciones. La ayuda a la toma de decisiones y las consultas reemergieron como una importante área de aplicación para las bases de datos. Las herramientas para analizar grandes cantidades de datos experimentaron un gran crecimiento de uso. Muchos vendedores de bases de datos introdujeron productos de bases de datos paralelas en este periodo, así como también comenzaron ofrecer bases de datos relacionales orientadas a objeto. • **Finales de la década de 1990.** El principal acontecimiento fue el crecimiento explosivo de World Wide Web. Las bases de datos se implantaron mucho más extensivamente que nunca antes. Los sistemas de bases de datos tienen ahora soporte para tasas de transacciones muy altas, así como muy alta fiabilidad y disponibilidad 24×7 (disponibilidad 24 horas al día y 7 días a la semana, que significa que no hay tiempos de inactividad debidos a actividades de mantenimiento planificadas). Los sistemas de bases de datos también tuvieron interfaces Web a los datos. 2.9 La Notación E-R con UML.

media type="youtube" key="Afg_nxcaIdY" width="425" height="350" align="center"

**Unidad 3** **Modelo relacional.**

** 3.1 Estructura básica. ** Este modelo permite representar la información del mundo real de una manera intuitiva, introduciendo conceptos cotidianos y fáciles de entender por cualquier inexperto. Asimismo, mantiene información sobre las propias características de la base de datos (metadatos), que facilitan las modificaciones, disminuyendo los problemas ocasionados en las aplicaciones ya desarrolladas. Por otro lado, incorpora mecanismos de consulta muy potentes, totalmente independientes del S.G.B.D., e incluso de la organización física de los datos; el propio S.G.B.D. es el encargado de optimizar estas preguntas en formato estándar, a sus características propias de almacenamiento. El modelo relacional fue propuesto por E.F. Codd en los laboratorios de IBM en California. Se trata de un modelo lógico [Irene Luque Ruiz- Ed. Ra-ma], que establece una estructura sobre los datos, aunque posteriormente éstos puedan ser almacenados de múltiples formas para aprovechar características físicas concretas de la máquina sobre la que se implante la base de datos realmente. Es algo así como guardar unos libros en una biblioteca; dependiendo del número de salas de la biblioteca, del tamaño y forma de cada una de ellas, su número de estanterías, y en definitiva, de las características físicas del recinto, podremos disponer los libros de una forma u otra para hacer más cómoda y fácil su consulta y acceso. Los libros son los mismos, pero pueden ubicarse de muy distintas formas. Vamos a estudiar entonces, las características concretas de este modelo de datos, sin entrar para nada en cómo los almacena físicamente cada ordenador, o cada S.G.B.D. Estructura general. El nombre de modelo //relacional// viene de la estrecha relación que existe entre el elemento básico de este modelo, y el concepto matemático de relación. Podemos decir que una relación R sobre los conjuntos D1, D2, .., Dn, se define como: R 􀁉 D1 × D2 × ... × Dn donde los conjuntos D1, D2, .., Dn pueden ser cualesquiera, e incluso estar repetidos. Los conjuntos pueden ser cualesquiera, aunque en el momento en que se trabaja con ordenadores, hay que imponer ciertas restricciones de discretización. Si nos fijamos en el dibujo adjunto, podemos ver que una de estas relaciones no es más que una lista de líneas, donde cada línea está dividida en trozos. Para observar bien el porqué ha surgido el método relacional, pensemos en cómo almacenaríamos las líneas de la lista anterior, si los ordenadores no existiesen. Para almacenar estas líneas, tendríamos que emplear papel, de manera que en un folio escribiríamos todas las líneas de la lista, empezando por la primera y continuando en el folio secuencialmente; si el folio se acaba, cogemos otro, y hacemos la misma operación, de forma que, al final, la lista está escrita o almacenada en varios folios. Este método, que es el más directo, tiene el problema de qué ocurre cuando se desean introducir nuevas líneas. Inicialmente, la tarea parece fácil, pues nos basta con seguir escribiendo líneas tras la última línea de la última página, e ir tomando nuevos folios a mediada que las páginas se vayan llenando. No obstante, este método sólo es adecuado si las líneas no están ordenadas según un criterio. Si las líneas ya están ordenadas, y deseamos introducir una nueva, ¿cómo lo hacemos?, ¿escribiendo una línea por enmedio con letra más pequeña?, o bien ¿escribiendo de nuevo todas las líneas, pero esta vez con la que se desea insertar? Está claro que ninguna de estas posibilidades es una solución factible. Otra posibilidad de registrar esas líneas es utilizando una ficha de cartón para cada una de ellas. Cada ficha de cartón será parecida a las que el alumno rellena para el profesor de cada asignatura a la que asiste, con la variante de que en lugar de poner el nombre, apellidos, dirección, etc. del alumno, se pondrá la información que nos interese guardar. de esta manera cada línea queda almacenada en una ficha de cartón. Si se desea insertar una nueva ficha basta con rellenarla y meterla en su posición adecuada. De la misma forma se puede proceder a la hora de eliminar alguna ficha. Pues bien, este último método es el que, a grandes rasgos, intenta utilizar el modelo relacional. El modelo relacional representa las listas de líneas mediante registros o fichas cada una de las cuales puede ser manejada individualmente y con independencia de las demás. No obstante, a efectos de facilitar la visualización, puede ser posible ver todas las líneas juntas como si de una lista se tratase. Ver figura. De esta manera, tendremos varios tipos de fichas: fichas de clientes, de proveedores, de facturas, de albaranes, de reservas, de empleados, de apuntes contables, etc., cada una de las cuales podemos almacenar en un cajón o en un fichero independiente. De cada tipo de ficha tendremos un montón de fichas rellenas: 100 ó 200 clientes, 4 ó 5 proveedores, miles de facturas, etc. Por tanto, es interesante distinguir entre un tipo de ficha, que no hace referencia a ninguna ficha rellena en concreto (p.ej. una ficha de clientes), y una ficha concreta, rellena con unos datos concretos (la ficha de Juan el Cocinero). Pues bien, el modelo relacional plasma en un ordenador este mismo esquema, aprovechando las enormes características de computación y almacenamiento de las máquinas actuales.

Concepto de tabla. Dominios y atributos. Una tabla en el modelo relacional viene a ser como una de las listas descritas anteriormente. Una **tabla** o **relación** es una matriz rectangular que almacena líneas con una estructura concreta: • La primera línea de una tabla, es una cabecera que indica el nombre de cada columna. O sea, cada columna tiene asignado un nombre único, e indica que los ítemes almacenados en esa columna deben pertenecer a un conjunto de valores concreto: Números, Letras, Frases, etc. • Cada línea (excepto la primera) recibe el nombre de **tupla**, y almacena ítemes concretos para cada columna. • Todas las filas deben ser diferentes entre sí. • El orden de las filas y de las columnas carece de importancia a efectos del S.G.B.D. Este hecho es el que verdaderamente diferencia las tablas relacionales del concepto matemático de relación, en el que el orden de las columnas es fundamental


 * 3.2 Esquema de las bases de datos. **

Concepto de tabla. Dominios y atributos.

Una tabla en el modelo relacional viene a ser como una de las listas descritas anteriormente. Una **tabla** o **relación** es una matriz rectangular que almacena líneas con una estructura concreta: • La primera línea de una tabla, es una cabecera que indica el nombre de cada columna. O sea, cada columna tiene asignado un nombre único, e indica que los ítemes almacenados en esa columna deben pertenecer a un conjunto de valores concreto: Números, Letras, Frases, etc. • Cada línea (excepto la primera) recibe el nombre de **tupla**, y almacena ítemes concretos para cada columna. • Todas las filas deben ser diferentes entre El orden de las filas y de las columnas carece de importancia a efectos del S.G.B.D. Este hecho es el que verdaderamente diferencia las tablas relacionales del concepto matemático de relación, en el que el orden de las columnas es fundamental. En la figura aparece una tabla de Platos. Toda tabla debe poseer al menos la primera línea, que identifica el nombre de la columna. En este caso, nuestra tabla o relación contiene las columnas Código, Nombre, Precio y Menú (que indica si ese plato pertenece o no a las opciones del menú del día). El ** grado ** de esta tabla es el número de campos que posee, en nuestro caso 4. La ** cardinalidad ** es el número de tuplas concretas que almacena: 7. Nótese que el grado de una tabla es independiente del momento en que observemos la tabla (el número de columnas es invariable, y queda definido en el momento en que se crea la tabla), mientras que la cardinalidad depende de la situación real que represente la tabla y puede variar en el tiempo; p.ej., la lista de platos puede cambiar todos los meses, o según la estación del año, para adecuarse a los gustos propios de cada una de ellas. La primera fila de una t abla es la más importante, ya que nos da su estructura. Esta columna identifica los nombres de campo o ** atributos ** de que consta cada tabla. En otras palabras, cada tupla está formada por un conjunto de información estructurada en elementos más simples llamados atributos. El nombre del atributo debe describir el significado de la información que representa. En la tabla // Platos, // el atributo // Precio // tendrá como cometido almacenar el valor en pesetas con el que ese plato se vende al público. A menudo suele ser necesario añadir una pequeña descripción a cada atributo que aclare su naturaleza: ¿el precio lleva I.V.A. o no? En el atributo // Menú // no está claro que es lo que se almacena. Una descripción del mismo aclararía más las cosas: // Indica si el cliente puede pedir este plato o no en el menú del día. // Por otro lado, está claro que un atributo en una tupla no puede tomar un valor cualquiera, p.ej., no tiene sentido que en el precio del // Ajo blanco con uvas // se guarde una palabra como pueda ser // Gerente //. Para evitar este tipo de situaciones anómalas en la medida de lo posible, obligaremos a que cada atributo sólo pueda tomar los valores pertenecientes a un conjunto de valores previamente establecido, o sea, un atributo tiene asociado un ** dominio ** de valores. En el caso anterior se tiene que el atributo // Precio // sólo puede tomar valores numéricos, mientras que el // Nombre // sólo puede contener frases textuales. Los dominios a que puede pertenecer un atributo, suelen depender de los que proporcione el S.G.B.D. que empleemos. Suelen ser comunes dominios como: Texto Texto, , N ú úm e e r r o o e e n n t t e e r r o o , , N ú úm e e r r o o d de e c c i im a a l l , , F F e e c c h h a a , , H o o r r a a , , S S í í / /N o o , etc. Por otro lado, un dominio como pueda ser N ú úm e e r r o o e e n n t t e e r ro o, es un dominio cuyo conjunto de valores es infinito, y dado que trabajamos con ordenadores, es imprescindible poner un límite que permita almacenar un valor concreto debido a las limitaciones de memoria, y sobre todo al hecho de que toda tupla debe poseer el mismo tamaño. Tomemos como ejemplo el // Nombre // del // Plato, // que es evidentemente del tipo T Te ex x t t o o; las limitaciones del ordenador nos impiden almacenar nombres ilimitadamente largos, como puedan ser «Magret de pato al vinagre de grosella con guarnición de higos malagueños al vino moscatel Pedro Ximénez». Es neces ario, p or tanto, establecer una cota al número máximo de letras que podemos teclear, por lo que el dominio del atributo // Nombre // puede ser T T e e x x t t o o d d e e 2 2 0 0 c c a a r r a a c c t t e e r r e e s s.



Así, la estructura completa de la tabla // Platos // quedaría como sigue: Platos: Código. Número ente Número ente r r o o. .  Número con el que el plato aparece en la carta. Nombre. T T e e x x t t o o d d e e 2 2 0 0 c c a a r r a a c c t t e e r r e e s s. .  Nombre del plato. Precio. N ú úm e e r r o o d d e e c c i im a a l l s s i im p p l l e e. .  Precio del plato. no incluye I.V.A. ni descuentos, etc. Menú. S S í í / /N o o. .

Indica si ese plato puede ser consumido dentro del precio del menú del día. La información anterior son los metadatos que definen la estructura de la tabla. Algunos S.G.B.D. simplifican la tarea de indicar el dominio de un atributo, asignando un  dominio por defecto, o estableciendo una jerarquía de dominios. P.ej., M icrosoft Access® toma como dominio por defecto el T Te ex x t t o o, y en concreto d d e e 5 5 0 0 c c a a r r a a c c t t e e r r e e s s. Se pueden cambiar los dominios a uno cualquiera dentro de las siguientes posibilidades: T T e e x x t t o o, , N u um é é r r i i c c o o , , F F e e c c h h a a / /H o o r r a a , , M o o n n e e d d a a , , S S í í / /N o o , , M e em o o , , A u u t t o o n n u um é é r r i i c c o o , , O b b j j e e t t o o O L L E E , , o H i i p p e e r rv v í í n n c c u u l l o o. A su vez, cada uno de estos tipos se puede dividir en otras clases, una de las cuales es la que se toma por defecto; p.ej. el tipo N u um é é r r i i c c o o tiene a su vez los subtipos: B y y t t e e, , E E n n t t e e r r o o , , E E n n t t e e r r o o l l a a r r g g o o , , S S i im p p l l e e y D o o b b l l e e. . Si sólo escogemos Nu u m é é r ri i c c o o, por defecto se toma el subtipo E En n t t e e r r o o l l a a r r g g o o , que permite guardar números enteros (sin parte decimal) desde el -2.147.483.648 hasta el 2.147.483.647. Si el subtipo por defecto no es el que se quiere puede especificarse otro. Independientemente del dominio a que pertenezca un atributo, cualquier atributo puede tomar un valor especial que designa la ausencia de dato; es el valor NULO (en inglés // NULL // o // NIL) //. Cuando, por cualquier circunstancia, se desconoce el valor de un atributo, como p.ej. la dirección de un cliente, o bien ese atributo carece de sentido (el atributo Teléfono de un empleado que no tiene teléfono en su casa), podemos asociar a dicho atributo este valor especial, común a cualquier dominio. El equivalente en nuestro símil de las fichas de cartón sería dejar ese hueco en blanco. Hay que hacer notar la diferencia entre el valor NULO, y el valor «espacios en blanco»; el ordenador considera un espacio en blanco como cualquier otro carácter, por lo que a efectos computacionales, la introducción de caracteres «espacios en blanco» es distinta al concepto de «ausencia de información». Los espacios en blanco sí son datos, y pertenecen al dominio T T e e x x t t o o. Restricciones. En el apartado anterior observamos que cada atributo está obligado a tomar un valor perteneciente a un dominio concreto, siendo imposible el que guarde otro distinto. Esto supone una restricción sobre los atributos Otras restricciones ya comentadas son: • La imposibilidad de repetir tuplas en una misma tabla. • La imposibilidad de establecer un orden en las tuplas, aunque algunos S.G.B.D. relajen un poco esta restricción. En este apartado vamos a introducir otras restricciones más importantes que posee el modelo relacional, así como los conceptos implicados. Por último veremos las posibilidades que tiene el usuario para definir restricciones en función de las características propias de su trabajo.

** --3.3 Claves. **

Reglas fundamentales. Claves. El modelo relacional intenta representar con una tabla a un tipo de objetos de la vida real, como puedan ser // Empleados, Clientes, // etc., e incluso considera las relaciones entre estos objetos como objetos en sí mismos. Para ello, designa cada tipo de objetos por un conjunto de atributos que son los que darán la «forma particular» a cada objeto. Volvamos al caso de nuestra tabla de // Platos. // Para representar a un // Plato, // hemos escogido los atributos: // Código, Nombre, Precio // y // Menú //. Un plato concreto puede ser p.ej., (17, «Migas con chocolate», 850, Sí). Este plato concreto, como cualquier otro objeto distinguible del mundo real posee unas características que lo distinguen de los demás de su mismo tipo, tal y como lo hace el ADN de una persona. El ADN conforma la esencia o clave de toda persona. Es más, todo objeto posee algo concreto que lo hace diferente; incluso puede poseer más de una cosa por la que se le puede diferenciar: una persona puede distinguirse también por su nacionalidad y su D.N.I., lo que conforma otra clave de esa persona. Como en una tabla, las tuplas pueden estar en cualquier orden, no podemos referenciar una tupla concret a mediante su posición entre las demás, y necesitamos alguna forma de seleccionar una tupla concreta. La forma de hacerlo es mediante una clave. Una ** clave ** es un atributo o conjunto de atributos cuyo valor es único y diferente para cada tupla. Cada tabla puede poseer más de una clave. P.ej., en nuestro caso de la tabla // Platos //, la clave puede ser tanto el atributo // Código // , como el atributo // Nombre //. Tenemos dos claves potenciales, también llamadas ** claves candidatas **. De entre todas las claves candidatas, el administrador, cuando define la tabla, debe decidir cuál de ellas va a ser la ** clave principal o clave primaria **, mientras que el resto de las claves pasan a denominarse ** claves alternativas o claves alternas **. La distinción entre clave principal y claves alternativas, es sólo a efectos de acceso interno a los datos, y para que el S.G.B.D. adopte ciertas decisiones sobre cómo almacenar esos datos en los sistemas de almacenamiento masivos. Por otro lado, la clave de una tabla debe ser ** propia **, o sea, ninguno de los atributos que la forman debe ser superfluo. Siguiendo con la tabla de // Platos //, si tomamos el grupo de atributos ( // Código, Precio // ), vemos que posee todas las características necesarias para considerarlo como una clave candidata. sin embargo, el atributo // Código // por sí sólo ya es una clave candidata, con lo cual el hecho de añadir el atributo // Precio // y crear una clave nueva, no aporta información de identificación, ya que el resto de los atributos (el // Código // en este caso) identifica por sí sólo a una tupla de la tabla de // Platos //. Así pues, el atributo // Precio // es superfluo en el grupo de atributos ( // Código, Precio // ), con lo que dicho grupo no es una clave candidata. Para distinguir cuando un grupo de atributos es clave o no, basta con probar con ir eliminando uno a uno cada uno de los atributos del grupo; si los atributos restantes s iguen poseyendo las propiedades de clave, el atributo eliminado es superfluo, por lo que el grupo de atributos de partida no es clave propia. Más adelante veremos como esta situación se deriva del hecho de que el valor del atributo que sobra (el superfluo) viene determinado por los valores de los otros atributos (la clave propia), en lo que se ha dado en llamar ** dependencia funcional **. El concepto de ** clave ** es t an importante, que da lugar a una serie de restricciones fundamentales sobre la base de datos. Son la ** regla de identificación única ** y la ** regla de **** integridad referencial **. Regla de identificación única. Esta restricción ya fue estudiada en el tema de los diagramas E-R. En esencia, los conceptos de clave de una entidad en el diagrama E-R, y de clave de una tabla coinciden plenamente. Así pues, al igual que en aquel momento, podemos enunciar esta regla de la misma forma: «En ninguna tupla de una tabla, ninguno de los atributos que formen parte de la clave primaria de una relación podrá tomar un valor nulo. El valor de la clave será único para cada tupla de la tabla». Esta regla nos dice que una vez escogida la clave primaria de una tabla, y dado que ninguno de los atributos que la componen es superfluo, no podemos dejar de lado el valor de ninguno de ellos para identificar unívocamente a una tupla. O sea, el que todos los atributos de la tabla sean necesarios está en contradicción con que alguno de ellos pueda carecer de valor. Ningún atributo de la clave puede ser vacío porque en tal caso no sería una característica identificativa propia del objeto a que pertenece. ** --3.4 Lenguajes de consulta. **

media type="youtube" key="Afg_nxcaIdY" width="425" height="350" align="center"

**Unidad 5** **Algebra Relacional**

** 5.1 Operaciones fundamentales del algebra relacional. **

El álgebra relacional es un lenguaje de consulta //procedimental//. Consta de un conjunto de operaciones que toman como entrada una o dos relaciones y producen como resultado una nueva relación. Las operaciones fundamentales del álgebra relacional son //selección//, //proyección//, //unión//, //diferencia de conjuntos//, //producto cartesiano// y //renombramiento//. Además de las operaciones fundamentales hay otras operaciones, por ejemplo, intersección de conjuntos, reunión natural, división y asignación. Estas operaciones se definirán en términos de las operaciones fundamentales.

**Operaciones fundamentales** Las operaciones selección, proyección y renombramiento se denominan operaciones //unarias// porque operan sobre una sola relación. Las otras tres operaciones operan sobre pares de relaciones y se denominan, por lo tanto, operaciones //binarias//.

**//La operación selección//** La operación **selección** selecciona tuplas que satisfacen un predicado dado. Se utiliza la letra griega sigma minúscula (σ) para denotar la selección. El predicado aparece como subíndice de σ. La relación del argumento se da entre paréntesis a continuación de σ. Por tanto, para seleccionar las tuplas de la relación //préstamo// en que la sucursal es «Navacerrada» hay que escribir

σ//nombre-sucursal = «//Navacerrada//»// (//préstamo//)

Si la relación //préstamo// es como se muestra en la Figur 3.6, la relación que resulta de la consulta anterior es como se muestra en la Figura 3.10. Se pueden buscar todas las tuplas en las que el importe prestado sea mayor que 1.200 € escribiendo σ//importe>//1200 (//préstamo//) En general, se permiten las comparaciones que utilizan =, ≠, <, ≤, > o ≥ en el

predicado de selección. Además, se pueden combinar varios predicados en uno mayor utilizando las conectivas //y// (∧) y //o// (∨). Por tanto, para encontrar las tuplas correspondientes a préstamos de más de 1.200 € concedidos por la sucursal de Navacerrada, se escribe

σ//nombre-sucursal = «//Navacerrada//»// ∧ //importe>//1200 (//préstamo//)



El predicado de selección puede incluir comparaciones entre dos atributos. Para ilustrarlo, considérese la relación //responsable-préstamo//, que consta de tres atributos: //nombre-cliente//, //nombre-banquero// y //númeropréstamo//, que especifica que un empleado concreto es el responsable del préstamo concedido a un cliente. Para hallar todos los clientes que se llaman igual que su responsable de préstamos se puede escribir

σ//nombre-cliente = nombre-banquero// (//responsable-préstamo//)

Dado que el valor especial //nulo// indica «valor desconocido o inexistente», cualquier comparación que implique a un valor nulo se evalúa como **falsa**.

**//La operación proyección//** Supóngase que se desea hacer una lista de todos los números de préstamo y del importe de los mismos, pero sin que aparezcan los nombres de las sucursales. La operación **proyección** permite producir esta relación. La operación proyección es una operación unaria que devuelve su relación de argumentos, excluyendo algunos argumentos. Dado que las relaciones son conjuntos, se eliminan todas las filas duplicadas. La proyección se denota por la letra griega mayúscula pi (Π). Se crea una lista de los atributos que se desea que aparezcan en el resultado como subíndice de Π. La relación de argumentos se escribe a continuación entre paréntesis. Por tanto, la consulta para crear una lista de todos los números de préstamo y del importe de los mismos puede escribirse como

Π//número-préstamo, importe// (//préstamo//)

La relación que resulta de esta consulta se muestra en la Figura

**//Composición de operaciones relacionales//**

Es importante el hecho de que el resultado de una operación relacional sea también una relación. Considérese la consulta más compleja «Encontrar los clientes que viven en Peguerinos». Hay que escribir:

Π//nombre-cliente// (σ//ciudad-cliente = «//Peguerinos//»// (//cliente//))



Téngase en cuenta que, en vez de dar en el argumento de la operación proyección el nombre de una relación, se da una expresión que se evalúa como una relación. En general, dado que el resultado de una operación del álgebra relacional es del mismo tipo (relación) que los datos de entrada, las operaciones del álgebra relacional pueden componerse para formar una **expresión****del álgebra relacional**. La composición de operaciones del álgebra relacional para formar expresiones del álgebra relacional es igual que la composición de operaciones aritméticas (como +, –, * y ÷) para formar expresiones aritméticas. La definición formal de las expresiones de álgebra relacional se estudia en el Apartado

**//La operación unión//**

Considérese una consulta para averiguar el nombre de todos los clientes del banco que tienen una cuenta, un préstamo o ambas cosas. Obsérvese que la relación //cliente// no contiene esa información, dado que los clientes no necesitan tener ni cuenta ni préstamo en el banco. Para contestar a esta consulta hace falta la información de la relación //impositor// (Figura 3.5) y la de la relación //prestatario// (Figura 3.7). Se conoce la manera de averiguar los nombres de todos los clientes con préstamos en el banco:

Π//nombre-cliente// (//prestatario//)

También se conoce la manera de averiguar el nombre de los clientes con cuenta en el banco:

Π//nombre-cliente// (//impositor//)

Para contestar a la consulta hace falta la **unión** de estos dos conjuntos; es decir, hacen falta todos los nombres de clientes que aparecen en alguna de las dos relaciones o en ambas. Estos datos se pueden averiguar mediante la operación binaria unión, denotada, como en la teoría de conjuntos, por ∪. Por tanto, la expresión buscada es

Π//nombre-cliente// (//prestatario//)∪Π//nombre-cliente// (//impositor//)

La relación resultante de esta consulta aparece en la Figura 3.10. Téngase en cuenta que en el resultado hay diez tuplas, aunque hay siete prestatarios y seis impositores distintos. Esta discrepancia aparente se debe a que Gómez, Santos y López son a la vez prestatarios e impositores. Dado que las relaciones son conjuntos, se eliminan los valores duplicados. Obsérvese que en este ejemplo se toma la unión de dos conjuntos, ambos consistentes en valores de //nombre- cliente//. En general, se debe asegurar que las unionesse realicen entre relaciones //compatibles//. Porejemplo, no tendría sentido realizar la unión de las relaciones//préstamo// y //prestatario//. La primera es una relacióncon tres atributos, la segunda sólo tiene dos. Másaún, considérese la unión de un conjunto de nombresde clientes y de un conjunto de ciudades. Una unión asíno tendría sentido en la mayor parte de los casos. Portanto, para que una operación unión //r// ∪ //s// sea válida hayque exigir que se cumplan dos condiciones:

1. Las relaciones //r// y //s// deben ser de la misma aridad. Es decir, deben tener el mismo número de atributos. 2. Los dominios de los atributos //i//-ésimos de //r// y de //s// deben ser iguales para todo //i//. Téngase en cuenta que //r// y //s// pueden ser, en general, relaciones temporales que sean resultado de expresiones del álgebra relacional.

**//La operación diferencia de conjuntos//**

La operación **diferencia de conjuntos**, denotada por –, permite buscar las tuplas que estén en una relación pero no en la otra. La expresión //r// – //s// da como resultado una relación que contiene las tuplas que están en //r// pero no en //s//. Se pueden buscar todos los clientes del banco que tienen abierta una cuenta pero no tienen concedido ningún préstamo escribiendo

Π//nombre-cliente// (//impositor//) //–// Π//nombre-cliente// (//prestatario//)

La relación resultante de esta consulta aparece en la Figura 3.13. Como en el caso de la operación unión, hay que asegurarse de que las diferencias de conjuntos se realicen entre relaciones //compatibles//. Por tanto, para que una

operación diferencia de conjuntos //r// – //s// sea válida hay que exigir que las relaciones //r// y //s// sean de la misma aridad y que los dominios de los atributos //i//-ésimos de //r// y //s// sean iguales.



**//La operación producto cartesiano//**

La operación **producto cartesiano**, denotada por un aspa (×), permite combinar información de cualesquiera dos relaciones. El producto cartesiano de las relaciones //r//1 y //r//2 como //r//1 × //r//2. Recuérdese que las relaciones se definen como subconjuntos del producto cartesiano de un conjunto de dominios. A partir de esta definición ya se debe tener una intuición sobre la definición de la operación producto cartesiano. Sin embargo, dado que el mismo nombre de atributo puede aparecer tanto en //r//1 como en //r//2, hay que crear un esquema de denominaciones para distinguir entre ambos atributos. En este caso se logra adjuntando al atributo el nombre de la relación de la que proviene originalmente. Por ejemplo, el esquema de relación de //r// = //prestatario// × //préstamo// es

(//prestatario.nombre-cliente, prestatario.númeropréstamo, préstamo.nombre-sucursal, préstamo.// //número-préstamo, préstamo.importe//)

Con este esquema se puede distinguir entre //prestatario//. //número-préstamo// y //préstamo//.//número-préstamo//. Para los atributos que sólo aparecen en uno de los dos esquemas se suele omitir el prefijo con el nombre de la relación. Esta simplificación no genera ambigüedad alguna. Por tanto, se puede escribir el esquema de relación de //r// como

(//nombre-cliente, prestatario.número-préstamo, nombre-sucursal, préstamo.número-préstamo, importe//)

El acuerdo de denominaciones precedente //exige// que las relaciones que sean argumentos de la operación producto cartesiano tengan nombres diferentes. Esta exigencia causa problemas en algunos casos, como cuando se desea calcular el producto cartesiano de una relación consigo misma. Se produce un problema similar si se utiliza el resultado de una expresión del álgebra relacional en un producto cartesiano, dado que hará falta un nombre para la relación para poder hacer referencia a sus atributos. En el Apartado 3.2.1.7 se verá la manera de evitar estos problemas utilizando una operación renombramiento. Ahora que se conoce el esquema de relación de //r// = //prestatario// × //préstamo// hay que averiguar las tuplas que aparecerán en //r//. Como se podía imaginar, se crea una tupla de //r// a partir de cada par de tuplas posible: una de la relación //prestatario// y otra de la relación //préstamo//. Por tanto, //r// es una relación de gran tamaño, como se puede ver en la Figura 3.14, donde sólo se ha incluido una parte de las tuplas que forman parte de //r//. Supóngase que se tienen //n//1 tuplas en //prestatario// y //n//2 tuplas en //préstamo//. Por tanto, hay //n//1 * //n//2 maneras de escoger un par de tuplas, una tupla de cada relación; por lo que hay //n//1 * //n//2 tuplas en //r//. En concreto, obsérvese que para algunas tuplas //t// de //r// puede ocurrir que //t//[//prestatario//. //número-préstamo//] ≠ //t//[//préstamo//.//número-préstamo//]. En general, si se tienen las relaciones //r//1 (//R//1) y //r//2 (//R//2), //r//1 × //r//2 es una relación cuyo esquema es la concatenación de //R//1 y de //R//2. La relación //R// contiene todas las tuplas //t// para las que hay unas tuplas //t//1 en //r//1 y //t//2 en //r//2 para las que //t//[//R//1] = //t//1[//R//1] y //t//[//R//2] = //t//2[//R//2]. Supóngase que se desea averiguar los nombres de todos los clientes que tienen concedido un préstamo en la sucursal de Navacerrada. Se necesita para ello información de las relaciones //préstamo// y //prestatario//. Si se Escribe

σnombre-sucursal = «Navacerrada» (//prestatario// × //préstamo//)

entonces el resultado es la relación mostrada en la Figura 3.15. Se tiene una relación que sólo atañe a la sucursal de Navacerrada. Sin embargo, la columna //nombrecliente// puede contener clientes que no tengan concedido ningún préstamo en la sucursal de Navacerrada. (Si no se ve el motivo por el que esto es cierto, recuérdese que el producto cartesiano toma todos los emparejamientos posibles de una tupla de //prestatario// con una tupla de //préstamo//.) Dado que la operación producto cartesiano asocia //todas// las tuplas de //préstamo// con todas las tuplas de //prestatario//, se sabe que, si un cliente tiene concedido un préstamo en la sucursal de Navacerrada, hay alguna tupla de //prestatario// × //préstamo// que contiene su nombre y que //prestatario//.//número-préstamo// = //préstamo//.//número-////préstamo//. Por tanto, si escribimos

σ//prestatario.número-préstamo = préstamo.número-préstamo// (σ//nombre-sucursal = «//Navacerrada//»// (//prestatario// × //préstamo//))

sólo se obtienen las tuplas de //prestatario// × //préstamo// que corresponden a los clientes que tienen concedidoun préstamo en la sucursal de Navacerrada.Finalmente, dado que sólo se desea obtener //nombrecliente//,se realiza una proyección:

Π//nombre-cliente// (σ//prestatario.número-préstamo = préstamo.número-préstamo// (σ//nombre-sucursal = «//Navacerrada//»// (//prestatario// × //préstamo//)))

El resultado de esta expresión se muestra en la Figura 3.16 y es la respuesta correcta a la consulta formulada.

**//La operación renombramiento//**

A diferencia de las relaciones de la base de datos, los resultados de las expresiones de álgebra relacional no tienen un nombre que se pueda utilizar para referirse a ellas. Resulta útil poder ponerles nombre; el operador

** --5.2 Otras operaciones del algebra relacional. **

**3.2.3. Otras operaciones** Las operaciones fundamentales del álgebra relacional son suficientes para expresar cualquier consulta del álgebra relacional1. Sin embargo, si uno se limita únicamente a las operaciones fundamentales, algunas consultas habituales resultan de expresión intrincada. Por tanto, se definen otras operaciones que no añaden potencia al álgebra, pero que simplifican las consultas habituales. Para cada operación nueva se facilita una expresión equivalente utilizando sólo las operaciones fundamentales.

**//La operación intersección de conjuntos//**

La primera operación adicional del álgebra relacional que se definirá es la **intersección de conjuntos** (∩). Supóngase que se desea averiguar todos los clientes que tienen un préstamo concedido y una cuenta abierta. Utilizando la intersección de conjuntos se puede escribir

Π//nombre-cliente// (//prestatario//)∩Π//nombre-cliente// (//impositor//)

La relación resultante de esta consulta aparece en la Figura 3.20. Obsérvese que se puede volver a escribir cualquier expresión del álgebra relacional utilizando la intersección de conjuntos sustituyendo la operación intersección por un par de operaciones de diferencia de conjuntos, de la manera siguiente:

//r// ∩ //s = r –// (//r – s//)

Por tanto, la intersección de conjuntos no es una operación fundamental y no añade potencia al álgebra relacional. Sencillamente, es más conveniente escribir //r// ∩//s// que //r// – (//r// – //s//).

**//La operación reunión natural//** Suele resultar deseable simplificar ciertas consultas que exigen un producto cartesiano. Generalmente, las consultas que implican un producto cartesiano incluyen un operador selección sobre el resultado del producto cartesiano. Considérese la consulta «Hallar los nombres de todos los clientes que tienen concedido un préstamo en el banco y averiguar el importe del mismo». En primer lugar se calcula el producto cartesiano de las relaciones //prestatario// y //préstamo//. Luego, se seleccionan las tuplas que sólo atañen al mismo //número-préstamo//, seguidas por la proyección de //nombre-cliente//, //número-préstamo// e //importe// resultantes: Π//nombre-cliente, préstamo.número-préstamo, importe// (σ//prestatario.número-préstamo = préstamo.número-préstamo// (//prestatario// × //préstamo//))

La //reunión natural// es una operación binaria que permite combinar ciertas selecciones y un producto cartesiano en una sola operación. Se denota por el símbolo de la «reunión». La operación reunión natural forma un producto cartesiano de sus dos argumentos, realiza una selección forzando la igualdad de los atributos que aparecen en ambos esquemas de relación y, finalmente, elimina los atributos duplicados. Aunque la definición de la reunión natural es compleja, la operación es sencilla de aplicar. Como ilustración, considérese nuevamente el ejemplo «Averiguar los nombres de todos los clientes que tienen concedido un préstamo en el banco y averiguar su importe». Esta consulta puede expresarse utilizando la reunión natural de la manera siguiente:

Π//nombre-cliente, número-préstamo, importe// (//prestatario préstamo//)

Dado que los esquemas de //prestatario// y de //préstamo// (es decir, //Esquema-prestatario// y //Esquema-préstamo//)tienen en común el atributo //número-préstamo//, la operaciónreunión natural sólo considera los pares de tuplasque tienen el mismo valor de //número-préstamo//. Estaoperación combina cada uno de estos pares en una solatupla en la unión de los dos esquemas (es decir, //nombre- cliente//, //nombre-sucursal//, //número-préstamo//, //importe//).Después de realizar la proyección, se obtiene larelación mostrada en la Figura 3.21 Considérense dos esquemas de relación //R// y //S// queson, por supuesto, listas de nombres de atributos. Si seconsideran los esquemas como //conjuntos//, en vez decomo listas, se pueden denotar los nombres de los atributosque aparecen tanto en //R// como en //S// mediante //R// ∩ //S//, y los nombres de los atributos que aparecen en //R//, en //S// o en ambos mediante //R// ∪ //S//. De manera parecida, losnombres de los atributos que aparecen en //R// pero no en //S// se denotan por //R// – //S//, mientras que //S// – //R// denota los nombres de los atributos que aparecen en //S// pero no en //R//. Obsérvese que las operaciones unión, intersección y diferencia aquí operan sobre conjuntos de atributos, y no sobre relaciones. Ahora se está preparado para una definición formal de la reunión natural. Considérense dos relaciones //r//(//R//) y //s//(//S//). La **reunión natural** de //r// y de //s//, denotada por //r////s// es una relación del esquema //R// ∪ //S// definida formalmente de la manera siguiente:

//r// s = Π//R// ∪ //S// (σ//r//.//A//1 = //s//.//A//1 ∧ //r//.//A//2 = //s//.//A//2 ∧… ∧ //r//.//A//n = //s//.//A//n //r// × //s//) donde //R// ∩ //S// = {//A//1, //A//2, …, //An//}.

Como la reunión natural es fundamental para gran parte de la teoría y de la práctica de las bases de datos relacionales, se ofrecen varios ejemplos de su uso. • Hallar los nombres de todas las sucursales con clientes que tienen una cuenta abierta en el banco y que viven en Peguerinos.

Π//nombre-sucursal// (σ//ciudad-cliente// = «Peguerinos» (//cliente cuenta impositor//))

La relación resultante de esta consulta aparece en la Figura 3.22. Obsérvese que se escribió //cliente cuenta////impositor// sin añadir paréntesis para especificar el orden en que se deben ejecutar las operaciones reunión natural de las tres relaciones. En el caso anterior hay dos posibilidades: — (//cliente cuenta//) //impositor — cliente// (//cuenta impositor//)No se especificó la expresión deseada porque lasdos son equivalentes. Es decir, la reunión naturales **asociativa**.• Hallar todos los clientes que tienen una cuentaabierta //y// un préstamo concedido en el banco.

Π//nombre-cliente// (//prestatario impositor//)

Obsérvese que en el Apartado 3.2.3.1 se escribió una expresión para esta consulta utilizando la intersección de conjuntos. Aquí se repite esa expresión.

Π//nombre-cliente// (//prestatario//)∩Π//nombre-cliente// (//impositor//)

**//La operación división//**

La operación **división**, denotada por ÷, resulta adecuada para las consultas que incluyen la expresión «para todos». Supóngase que se desea hallar a todos los clientes que tengan abierta una cuenta en //todas// las sucursales ubicadas en Arganzuela. Se pueden obtener todas las sucursales de Arganzuela mediante la expresión //r//1 //=// Π//nombre-sucursal// (σ//ciudad-sucursal = «//Arganzuela//»// (//sucursal//)) La relación resultante de esta expresión aparece en la Figura 3.23. Se pueden encontrar todos los pares (//nombre-cliente//, //nombre-sucursal//) para los que el cliente tiene una cuenta en una sucursal escribiendo

//r//2 //=// Π//nombre-cliente, nombre-sucursal// (//impositor cuenta//)

La Figura 3.24 muestra la relación resultante de esta expresión. Ahora hay que hallar los clientes que aparecen en //r//2 con los nombres de //todas// las sucursales de //r//1. La operación que proporciona exactamente esos clientes es la operación división. La consulta se formula escribiendo

Π//nombre-cliente, nombre-sucursal// (//impositor cuenta//) ÷ Π//nombre-sucursal// (σ//ciudad-sucursal = «Arganzuela»// (//sucursal//))

El resultado de esta expresión es una relación que tiene el esquema (//nombre-cliente//) y que contiene la tupla

** --5.3 Algebra relacional extendida. **

Las operaciones básicas del álgebra relacional se han ampliado de varias maneras. Una ampliación sencilla es permitir operaciones aritméticas como parte de la proyección. Una ampliación importante es permitir //operaciones////de agregación//, como el cálculo de la suma de los elementos de un conjunto, o su media. Otra ampliación importante es la operación //reunión externa//, que permite a las expresiones del álgebra relacional trabajar con los valores nulos que modelan la información que falta.

**Proyección generalizada**

La operación **proyección generalizada** amplía la operación proyección permitiendo que se utilicen funciones aritméticas en la lista de proyección. La operación proyección generalizada tiene la forma Π//F//1, //F//2, …, //Fn// (E) donde //E// es cualquier expresión del álgebra relacional y //F//1, //F//2, …, //Fn// son expresiones aritméticas que incluyen constantes y atributos en el esquema de //E//. Como caso especial la expresión aritmética puede ser simplemente un atributo o una constante. Por ejemplo, supóngase que se dispone de una relación //información-crédito//, como se muestra en la Figura 3.25, que da el límite de crédito y el importe dispuesto hasta el momento presente (el //saldo-crédito// de la cuenta). Si se desea averiguar el importe disponible por cada persona, se puede escribir la expresión siguiente:

Π//nombre-cliente, límite - saldo-crédito// (//información-crédito//)

El atributo resultante de la expresión //límite// – //saldo-crédito// no tiene un nombre. Se puede aplicar la operaciónrenombramiento al resultado de la proyección generalizadapara darle un nombre. Como conveniencia notacional,el renombramiento de atributos se puedecombinar con la proyección generalizada como se ilustraa continuación:

Π//nombre-cliente,// (//límite – saldo-crédito//) **as** //crédito-disponible// (//información-crédito//)

Al segundo atributo de esta proyección generalizada se le ha dado el nombre //crédito-disponible//. En la Figura 3.26 se muestra el resultado de aplicar esta expresión a la relación de la Figura 3.25.

**Funciones de agregación**

Las **funciones de agregación** son funciones que toman una colección de valores y devuelven como resultado un único valor. Por ejemplo, la función de agregación



**sum** toma un conjunto de valores y devuelve la suma de los mismos. Por tanto, la función **sum** aplicada a la colección {1, 1, 3, 4, 4, 11} devuelve el valor 24. La función de agregación **avg** devuelve la media de los valores. Cuando se aplica al conjunto anterior devuelve el valor 4. La función de agregación **count** devuelve el número de elementos del conjunto, y devolvería 6 en el caso anterior. Otras funciones de agregación habituales son **min** y **max**, que devuelven el valor mínimo y el máximo de la colección; en el ejemplo anterior devuelven 1 y 11, respectivamente. Las colecciones en las que operan las funciones de agregación pueden tener valores repetidos; el orden en el que aparezcan los valores no tiene importancia. Estas colecciones se denominan **multiconjuntos**. Los conjuntos son un caso especial de los multiconjuntos, en los que sólo hay una copia de cada elemento. Para ilustrar el concepto de agregación se utilizará la relación //trabajo-por-horas// descrita en la Figura 3.27, que muestra los empleados a tiempo parcial. Supóngase que se desea averiguar la suma total de los sueldos de los empleados del banco a tiempo parcial. La expresión del álgebra relacional para esta consulta es:

//G//**sum**(//sueldo//) (//trabajo-por-horas//)

El símbolo //G// es la letra G en el tipo de letra caligráfico; se lee «G caligráfica». La operación del álgebra relacional //G// significa que se debe aplicar agregación, y el subíndice indica la operación de agregación a aplicar. El resultado de la expresión anterior es una relación con un único atributo, que contiene una sola fila con un valor correspondiente a la suma de los sueldos de todos los trabajadores que trabajan en el banco a tiempo parcial. Hay casos en los que se deben borrar los valores repetidos antes de calcular una función de agregación. Si se desean borrar los valores repetidos hay que utilizar los mismos nombres de funciones que antes, con la cadena de texto «**distinct**» precedida de un guión añadida al final del nombre de la función (por ejemplo, **count-distinct**). Un ejemplo se da en la consulta «Averiguar el número de sucursales que aparecen en la relación //trabajo-// //por-horas//». En este caso, el nombre de cada sucursal sólo se cuenta una vez, independientemente del número de empleados que trabajen en la misma. Esta consulta se escribe de la manera siguiente:

//G//**count-distinct**(nombre//-sucursal//) (//trabajo-por-horas//)

Para la relación mostrada en la Figura 3.27 el resultado de esta consulta es el valor 3. Supóngase que se desea hallar la suma total de sueldos de todos los empleados a tiempo parcial en cada sucursal del banco por separado, en lugar de hallar la suma de sueldos de todo el banco. Para ello hay que dividir la relación //trabajo-por-horas// en **grupos** basados en la sucursal y aplicar la función de agregación a cada grupo. La expresión siguiente obtiene el resultado deseado utilizando el operador de agregación //G//: //nombre-sucursal// //G//**sum**(//sueldo//) (//trabajo-por-horas//)

El atributo //nombre-sucursal// subíndice a la izquierda de //G// indica que la relación de entrada //trabajo-porhoras// debe dividirse en grupos de acuerdo con el valor de //nombre-sucursal//. Los grupos resultantes se muestran en la Figura 3.28. La expresión **sum**(//sueldo//) en el subíndice derecho de //G// indica que, para cada grupo de tuplas (es decir, para cada sucursal) hay que aplicar la función de agregación **sum** al conjunto de valores del atributo //sueldo//. La relación resultante consiste en las tuplas con el nombre de la sucursal y la suma de los sueldos de la sucursal, como se muestra en la Figura 3.29. La forma general de la **operación de agregación** //G// es la siguiente:

//G//1//, G//2//, …, Gn// //G////F//1(//A//1)//, F//2(//A//2)//, …, Fm// (//Am//) (//E//) donde //E// es cualquier expresión del álgebra relacional; //G//1, //G//2, …, //Gn// constituye una lista de atributos que indican cómo se realiza la agrupación, cada //Fi// es una función de agregación y cada //Ai// es el nombre de un atributo. El significado de la operación se define de la manera siguiente. Las tuplas en el resultado de la expresión //E// se dividen en grupos tales que

** --5.4 Valores nulos. **

En este apartado se define la forma en que las diferentes operaciones del álgebra relacional tratan los valores nulos y las complicaciones que surgen cuando los valores nulos participan en las operaciones aritméticas o en las comparaciones. Como se verá, a menudo hay varias formas de tratar los valores nulos y, como resultado, las siguientes definiciones pueden ser a veces arbitrarias. Las operaciones y las comparaciones con valores nulos se deberían evitar siempre que sea posible. Dado que el valor especial //nulo// indica «valor desconocido o no existente», cualquier operación aritmética (como +, –, * y /) que incluya valores nulos debe devolver un valor nulo. De manera similar, cualquier comparación (como <, <=, >, >= y ≠) que incluya un valor nulo se evalúa al valor especial desconocido; no se puede decir si el resultado de la comparación es cierto o falso, así que se dice que el resultado es el nuevo valor lógico //desconocido//. Las comparaciones que incluyan nulos pueden aparecer dentro de expresiones booleanas que incluyan las operaciones y (conjunción), o (disyunción) y no (negación). Se debe definir la forma en que estas operaciones tratan el valor lógico //desconocido//.

• y: (//cierto// y //desconocido//) = //desconocido//; (//falso// y //desconocido//) = //falso//; (//desconocido// y //desconocido//) = //desconocido//. • o: (//cierto// o //desconocido//) = //cierto//; (//falso// o //desconocido//) = //desconocido//; (//desconocido// o //desconocido//) = //desconocido//. • no: (no //desconocido//) = //desconocido.// Ahora es posible describir la forma en que las diferentesoperaciones del álgebra relacional tratan los valoresnulos. Nuestras definiciones siguen las usadas en el lenguaje SQL. • select: la operación selección evalúa el predicado //P// en σ//P//(//E//) sobre cada tupla de //E//. Si el predicado devuelve el valor //cierto//, se añade //t// al resultado. En caso contrario, si el predicado devuelve //desconocido// o //falso//, //t// no se añade al resultado. • reunión: las reuniones se pueden expresar como un producto cartesiano seguido de una selección. Por tanto, la definición de la forma en que la selección trata los nulos también define la forma en que la operación reunión trata los nulos. En una reunión natural //r s//se puede observar de la definición anterior que si dos tuplas, //tr// ∈ //r// y //ts// ∈ //s//, tienen un valor nulo en un atributocomún, entonces las tuplas no casan. • proyección: la operación proyección trata los nulos como cualquier otro valor al eliminar duplicados. Así, si dos tuplas del resultado de la proyección son exactamente iguales, y ambos tienen nulos en los mismos campos, se tratan como duplicados. La decisión es un tanto arbitraria porque sin saber cuál es el valor real no se sabe si los dos valores nulos son duplicados o no. • unión, intersección, diferencia: estas operaciones tratan los valores nulos al igual que la operación proyección; tratan las tuplas que tienen los mismos valores en todos los campos como duplicados incluso si algunos de los campos tienen valores nulos en ambas tuplas. El comportamiento es un tanto arbitrario, especialmente en el caso de la intersección y la diferencia, dado que no se sabe si los valores reales (si existen) representados por los nulos son los mismos. • proyección generalizada: se describió la manera en que se tratan los nulos en las expresiones al principio del Apartado 3.3.4. Las tuplas duplicadas que contienen valores nulos se tratan como en la operación proyección. Cuando hay nulos en los atributos agregados, la operación borra los valores nulos del resultado antes de aplicar la agregación. Si el multiconjunto resultante está vacío, el resultado agregado es nulo. Obsérvese que el tratamiento de los valores nulos aquí es diferente que en las expresiones aritméticas ordinarias; se podría haber definido el resultado de una operación de agregación como nulo si incluso sólo uno de los valores agregados es nulo. Sin embargo, esto significaría que un único valor desconocido en un gran grupo podría hacer que el resultado agregado sobre el grupo fuese nulo, y se perdería una gran cantidad de información útil. • reunión externa: las operaciones de reunión externa se comportan como las operaciones reunión, excepto sobre las tuplas que no aparecen en el resultado. Estas tuplas se pueden añadir al resultado (dependiendo de si la operación es, o ) añadiendo nulos.

--5.5 Operaciones de modificación a la base de datos.

Hasta ahora hemos centrado la atención en la extracción de información de la base de datos. En este apartado se abordará la manera de insertar, borrar o modificar información de la base de datos. Las modificaciones de la base de datos se expresan utilizando la operación asignación. Las asignaciones a las relaciones reales de la base de datos se realizan utilizando la misma notación que se describió para la asignación en el Apartado 3.2.3.

Borrado Las solicitudes de borrado se expresan básicamente igual que las consultas. Sin embargo, en lugar de mostrar las tuplas al usuario, se eliminan de la base de datos las tuplas seleccionadas. Sólo se pueden borrar tuplas enteras; no se pueden borrar valores de atributos concretos. En el álgebra relacional los borrados se expresan mediante //r// ← //r – E// donde //r// es una relación y //E// es una consulta del álgebra relacional. He aquí varios ejemplos de solicitudes de borrado del álgebra relacional:

• Borrar todas las cuentas de Gómez. //impositor// ← //impositor –// σ//nombre-cliente// = «Gómez» (//impositor//) • Borrar todos los préstamos con importes entre 0 y 50. //préstamo// ← //préstamo// – σ//importe// ≥ 0 and //importe// ≤ 50 (//préstamo//) • Borrar todas las cuentas de las sucursales sitas en Getafe. r1 ←σ//ciudad-sucursal// = «Getafe» (//cuenta sucursal//) //r//2← Π//nombre-sucursal, número-cuenta, saldo// (//r//1) //cuenta// ← //cuenta// – r2

Obsérvese que en el último ejemplo se simplificó la expresión utilizando la asignación a las relaciones temporales (//r//1 y //r//2).

Inserción Para insertar datos en una relación hay que especificar la tupla que se va a insertar o escribir una consulta cuyo resultado sea un conjunto de tuplas que vayan a insertarse. Evidentemente, el valor de los atributos de las tuplas insertadas deben ser miembros del dominio de cada atributo. De manera parecida, las tuplas insertadas deben ser de la aridad correcta. En el álgebra relacional las inserciones se expresan mediante

//r// ← //r// ∪ //E//

donde //r// es una relación y //E// es una expresión del álgebra relacional. La inserción de una sola tupla se expresa haciendo que //E// sea una relación constante que contiene una tupla. Supóngase que se desea insertar el hecho de que Gómez tiene 1.200 € en la cuenta C-973 en la sucursal de Navacerrada. Hay que escribir //cuenta// ← //cuenta// ∪ {(C-973, «Navacerrada», 1200)} //impositor// ← //impositor// ∪ {(«Gómez», C-973)} De forma más general, puede que se desee insertar tuplas de acuerdo con el resultado de una consulta. Supóngase que se desea ofrecer una nueva cuenta de ahorro con 200 € como regalo a todos los clientes con préstamos concedidos en la sucursal de Navacerrada. Sea el número de préstamo el que se utilice como número de cuenta de esta cuenta de ahorro. Hay que escribir

r1←(σ//nombre-sucursal// = «Navacerrada» (//prestatario préstamo//)) //r//2←Π//nombre-sucursal, número-préstamo// (//r//1) //cuenta// ← //cuenta// ∪ (//r//2 {(200)}) //impositor// ← //impositor// ∪Π//nombre-cliente, número-préstamo// (//r//1)

En lugar de especificar las tuplas como se hizo anteriormente, se especifica un conjunto de tuplas que se insertan en las relaciones //cuenta// e //impositor//. Cada tupla de la relación //cuenta// tiene el //nombre-sucursal// (Navacerrada), un //número-cuenta// (que es igual que el número de préstamo) y el saldo inicial de la nueva cuenta (200 €). Cada tupla de la relación //impositor// tiene como //nombre-cliente// el nombre del prestatario al que se le da la nueva cuenta y el mismo número de cuenta que la correspondiente tupla de //cuenta//.

Actualización Puede que, en algunas situaciones, se desee modificar un valor de una tupla sin modificar //todos// los valores de la tupla. Se puede utilizar el operador proyección generalizada para realizar esta tarea: //r//←Π//F//1, //F//2, …, //Fn// (//r//) donde cada //Fi// es el //i//-ésimo atributo de //r//, si el //i//-ésimo atributo no está actualizado, o, si hay que actualizar el atributo, una expresión, que sólo implica constantes y los atributos de //r//, que da el nuevo valor del atributo. Si se desea seleccionar varias tuplas de //r// y sólo actualizar esas mismas tuplas, se puede utilizar la expresión siguiente, donde //P// denota la condición de selección que escoge las tuplas que hay que actualizar:

//r// ← Π//F//1, //F//2, …, //Fn// (σ//P// (//r//)) ∪ (//r –// σ//P// (//r//))

Para ilustrar el uso de la operación actualización supóngase que se realiza el pago de los intereses y que hay que aumentar todos los saldos en un 5 por ciento. Hay que escribir

//cuenta// ←Π//nombre-sucursal, número-cuenta, saldo, saldo *// 1.05 (//cuenta//)

Supóngase ahora que las cuentas con saldos superiores a 10.000 € reciben un interés del 6 por ciento, mientras que los demás reciben un 5 por ciento. Hay que escribir

//cuenta// ←Π//NS, NC, saldo *// 1.06 (σ//saldo// > 10000 (//cuenta//)) ∪ //cuenta// ←Π//NS, NC, saldo *// 1.05 (σ//saldo// ≤ 10000 (//cuenta//))

donde las abreviaturas //NS// y //NC// sustituyen a //nombresucursal// y a //número-cuenta//, respectivamente.

media type="youtube" key="bk9VqT7--oE" width="425" height="350" align="center"

**Unidad 6** **Lenguaje SQL.**

** --6.1 Introducción. **

IBM desarrolló la versión original en su Laboratorio de Investigación de San José (//San José Research Center//, actualmente Centro de Investigación de Almadén, //Almadén////Research Center//). IBM implementó el lenguaje, originalmente denominado Sequel, como parte del proyecto System R, a principios de 1970. El lenguaje Sequel ha evolucionado desde entonces y su nombre ha pasado a ser SQL (//Structured Query Language//, Lenguaje estructurado de consultas). Actualmente, numerosos productos son compatibles con el lenguaje SQL. SQL se ha establecido como //el// lenguaje estándar de bases de datos relacionales.

En 1986, ANSI (//American National Standards Institute//, Instituto Nacional Americano de Normalización) e ISO (//International Standards Organization//, Organización Internacional de Normalización), publicaron una norma SQL, denominada SQL-86. En 1987, IBM publicó su propia norma de SQL corporativo, Interfaz de bases de datos para arquitecturas de aplicación a sistemas

(//Systems Application Architecture Database Interface//, SAA-SQL). En 1989 se publicó una norma extendida para SQL denominada SQL-89 y actualmente los sistemas de bases de datos son normalmente compatibles al menos con las características de SQL-89. La siguiente versión de la norma fue SQL-92 y la versión más reciente es SQL:1999. Las notas bibliográficas proporcionan referencias a esas normas.

En este apartado se presenta una visión general de SQL basada en la norma SQL-92 ampliamente implementada. La norma SQL:1999 es un superconjunto de la norma SQL-92; en este capítulo se tratan algunas características de SQL:1999 y se proporciona un estudio más detallado en el Capítulo 9. Muchos sistemas de bases de datos soportan algunas de las nuevas constructoras de SQL:1999, aunque ningún sistema de bases datos actual soporta todas las nuevas constructoras. También hay ser consciente de que algunos sistemas de bases de datos ni siquiera soportan todas las características de SQL-92 y de que muchas bases de datos proporcionan características no estándar que no se tratan aquí. El lenguaje SQL tiene varios componentes:

• **Lenguaje de de****fi****nición de datos** (LDD). El LDD de SQL proporciona órdenes para la definición de

esquemas de relación, borrado de relaciones, creación de índices y modificación de esquemas de

relación.

• **Lenguaje interactivo de manipulación de datos** (LMD). El LMD de SQL incluye un lenguaje de

consultas, basado tanto en el álgebra relacional como en el cálculo relacional de tuplas. Incluye también órdenes para insertar, borrar y modificar tuplas de la base de datos.

• **Definición de vistas.** El LDD de SQL incluye órdenes para la definición de vistas.

• **Control de transacciones.** SQL incluye órdenes para la especificación del comienzo y final de transacciones.

• **SQL incorporado** y **SQL dinámico.** SQL dinámico e incorporado define cómo se pueden incorporar

las instrucciones SQL en lenguajes de programación de propósito general, tales como C, C++, Java, PL/I, Cobol, Pascal y Fortran.

• **Integridad.** El LDD de SQL incluye órdenes para la especificación de las restricciones de integridad

que deben satisfacer los datos almacenados en la base de datos. Las actualizaciones que violen las restricciones de integridad se rechazan.

• **Autorización.** El LDD de SQL incluye órdenes para especificar derechos de acceso para las relaciones

y vistas. En este capítulo se estudia el LMD y las características básicas del LDD de SQL. También se describe brevemente SQL incorporado y dinámico, incluyendo las normas ODBC y JDBC para la interacción con una base de datos desde programas escritos en lenguajes C y Java. Las características de SQL que dan soporte a la integridad y autorización se describen en el Capítulo 6, mientras que el Capítulo 9 esboza las extensiones orientadas a objeto de SQL. Los ejemplos de este capítulo y posteriores se basarán en una empresa bancaria, con los siguientes esquemas de relación:

Una base de datos relacional consiste en un conjunto de relaciones, a cada una de las cuales se le asigna un nombre único. Cada relación tiene una estructura similar a la presentada en el Capítulo 3. SQL permite el uso de valores nulos para indicar que el valor o bien es desconocido, o no existe. Se fijan criterios que permiten al usuario especificar a qué atributos no se puede asignar valor nulo, como estudiaremos en el Apartado 4.11. La estructura básica de una expresión SQL consiste en tres cláusulas: **select**, **from** y **where**.

** --6.2 Definición de datos. **

1. COMANDOS

Existen dos tipos de comandos **SQL**:

1.1 Comandos DLL
 * **DLL:** permiten crear y definir nuevas bases de datos, campos e índices.
 * **DML:** permiten generar consultas para ordenar, filtrar y extraer datos de la base de datos.

1.2 Comandos DML
 * **CREATE** Crea nuevas tablas, campos e índices
 * **DROP** Elimina tablas e índices
 * **ALTER** Modifica las tablas agregando campos o cambiando la definición de los campos.


 * **SELECT** Consulta registros de la base de datos que satisfagan un criterio determinado
 * **INSERT** Carga lotes de datos en la base de datos en una única operación.
 * **UPDATE** Modifica los valores de los campos y registros especificados
 * **DELETE** Elimina registros de una tabla de una base de datos

2. CLÁUSULAS

Son condiciones de modificación utilizadas para definir los datos que desea seleccionar o manipular.

2.1 Comando Descripción

3. OPERADORES
 * **FROM** Especifica la tabla de la cual se van a seleccionar los registros.
 * **WHERE** Especifica las condiciones que deben reunir los registros que se van a seleccionar.
 * **GROUP BY** Separa los registros seleccionados en grupos específicos.
 * **HAVING** Expresa la condición que debe satisfacer cada grupo.
 * **ORDER BY** Ordena los registros seleccionados de acuerdo con un orden específico.

3.1 Operadores Lógicos

3.2 Operadores de Comparación
 * **AND** Es el "y" lógico. Evalúa dos condiciones y devuelve un valor de verdad sólo si ambas son ciertas.
 * **OR** Es el "o" lógico. Evalúa dos condiciones y devuelve un valor de verdad si alguna de las dos es cierta.
 * **NOT** Negación lógica. Devuelve el valor contrario de la expresión.


 * **<** Menor que
 * **>** Mayor que
 * **< >** Distinto de
 * **<=** Menor ó Igual que
 * **>=** Mayor ó Igual que
 * **BETWEEN** Especifica un intervalo de valores.
 * **LIKE** Comparación de un modelo
 * **In** Especifica registros de una base de datos

4. FUNCIONES DE AGREGADO

Las funciones de agregado se usan dentro de una cláusula **SELECT** en grupos de registros para devolver un único valor que se aplica a un grupo de registros.


 * **AVG** Calcula el promedio de los valores de un campo determinado
 * **COUNT** Devuelve el número de registros de la selección
 * **SUM** Devuelve la suma de todos los valores de un campo determinado
 * **MAX** Devuelve el valor más alto de un campo especificado
 * **MIN** Devuelve el valor más bajo de un campo especificado

5. CONSULTAS

5.1 Consultas de Selección

Las consultas de selección se utilizan para indicar al motor de datos que devuelva información de las bases de datos, esta información es devuelta en forma de conjunto de registros que se pueden almacenar en un objeto recordset. Este conjunto de registros es modificable.

5.1.1 Consultas básicas

La sintaxis básica de una consulta de selección es la siguiente:

//SELECT Campos FROM Tabla;//

En donde campos es la lista de campos que se deseen recuperar y tabla es el origen de los mismos, por ejemplo:

//SELECT Nombre, Teléfono FROM Clientes;//

Esta consulta devuelve un recordset con el campo nombre y teléfono de la tabla clientes.

5.1.2 Ordenar los registros

Se puede especificar el orden en que se desean recuperar los registros de las tablas mediante la cláusula ORDER BY Lista de Campos. En donde Lista de campos representa los campos a ordenar.

5.2 Consultas con Predicado

El predicado se incluye entre la cláusula y el primer nombre del campo a recuperar, los posibles predicados son:


 * **ALL** Devuelve todos los campos de la tabla
 * **TOP** Devuelve un determinado número de registros de la tabla
 * **DISTINCT** Omite los registros cuyos campos seleccionados coincidan totalmente
 * **DISTINCROW** Omite los registros duplicados basándose en la totalidad del registro y no sólo en los campos seleccionados.

6. ALIAS

En determinadas circunstancias es necesario asignar un nombre a alguna columna determinada de un conjunto devuelto. Para ello se tiene la palabra reservada **AS** que se encarga de asignar el nombre que deseamos a la columna deseada. Podemos hacer que la columna devuelta por la consulta, en lugar de llamarse apellido (igual que el campo devuelto) se llame Empleado.

En este caso procederíamos de la siguiente forma:

//SELECT DISTINCTROW Apellido AS Empleado FROM Empleados;//

** --6.3 Estructura básica de las consultas. **

Una base de datos relacional consiste en un conjunto de relaciones, a cada una de las cuales se le asigna un nombre único. Cada relación tiene una estructura similar a la presentada en el Capítulo 3. SQL permite el uso de valores nulos para indicar que el valor o bien es desconocido, o no existe. Se fijan criterios que permiten al usuario especificar a qué atributos no se puede asignar valor nulo, como estudiaremos en el Apartado 4.11. La estructura básica de una expresión SQL consiste en tres cláusulas: **select**, **from** y **where**.

• La cláusula **select** corresponde a la operación proyección del álgebra relacional. Se usa para listar los

atributos deseados del resultado de una consulta.

• La cláusula **from** corresponde a la operación producto cartesiano del álgebra relacional. Lista las relaciones que deben ser analizadas en la evaluación de la expresión.

• La cláusula **where** corresponde al predicado selección del álgebra relacional. Es un predicado que engloba a los atributos de las relaciones que aparecen en la cláusula **from**. Un hecho histórico desafortunado es que el término //select// tiene un significado diferente en SQL que en el álgebra relacional. A continuación se resaltan las diferentes interpretaciones, a fin de minimizar la posible confusión.

Una consulta típica en SQL tiene la forma **select** //A//1, //A//2,…, //An//**from** //r//1, //r//2,…, //rm//**where** //P// Cada //Ai// representa un atributo, y cada //ri// una relación. //P// es un predicado. La consulta es equivalente a la expresión del álgebra relacional Π //A//1, //A//2,…, //An// (σ//P// (//r//1 × //r//2 ×… × //rm// )) Si se omite la cláusula **where**, el predicado P es **cierto**. Sin embargo, con diferencia a la expresión del álgebra relacional, el resultado de la consulta SQL puede contener varias copias de algunas tuplas; este aspecto se analizará de nuevo en el Apartado 4.2.8. SQL forma el producto cartesiano de las relaciones incluidas en la cláusula **from**, lleva a cabo la selección del álgebra relacional usando el predicado de la cláusula **where** y entonces proyecta el resultado sobre los atributos de la cláusula **select**. En la práctica, SQL puede convertir la expresión en una forma equivalente que puede ser procesada más eficientemente. Las cuestiones relativas a la eficiencia se analizan en los Capítulos 13 y 14.

**La cláusula select**

El resultado de una consulta SQL es, por supuesto, una relación. Considérese una consulta simple, usando el ejemplo bancario, «Obtener los números de todas las sucursales en la relación //préstamo//»:

**select** //nombre-sucursal// **from** //préstamo// El resultado es una relación consistente en el único atributo

//nombre-sucursal//.

Los lenguajes formales de consulta están basados en la noción matemática de que una relación es un conjunto. Así, nunca aparecen tuplas duplicadas en las relaciones. En la práctica, la eliminación de duplicados consume tiempo. Sin embargo, SQL (como la mayoría de los lenguajes de consulta comerciales) permite duplicados en las relaciones, así como en el resultado de las expresiones SQL. Así, la consulta anterior listará cada //nombre-sucursal// una vez por cada tupla en la que aparece en la relación //préstamo.// En aquellos casos donde se quiera forzar la eliminación de duplicados, se insertará la palabra clave **distinct** después de **select**. Por lo tanto, se puede reescribir la consulta anterior como **select distinct** //nombre-sucursal//**from** //préstamo// si se desean eliminar los duplicados. Es importante resaltar que SQL permite usar la palabra clave **all** para especificar explícitamente que no se eliminan los duplicados:

**select all** //nombre-sucursal// **from** //préstamo//

Como de manera predeterminada se realiza la retención de duplicados, de ahora en adelante no se usará la palabra clave **all** en los ejemplos. Para asegurar la eliminación de duplicados en el resultado de los ejemplos de consultas, se usará la cláusula **distinct** siempre que sea necesario. En la mayoría de las consultas donde no se utiliza **distinct**, el número exacto de copias duplicadas de cada tupla que resultan de la consulta no es importante.

Sin embargo, el número es importante en ciertas aplicaciones; este aspecto se volverá a tratar en el Apartado 4.2.8. El símbolo asterisco «*» se puede usar para denotar «todos los atributos». Así, el uso de //préstamo//.* en la cláusula **select** anterior indicaría que todos los atributos de préstamo serían seleccionados. Una cláusula **select** de la forma **select** * indica que se deben seleccionar todos los atributos de todas las relaciones que aparecen en la cláusula **from**.

La cláusula **select** puede contener también expresiones aritméticas que contengan los operadores, +, –,

* y / operando sobre constantes o atributos de la tuplas. Por ejemplo, la consulta

**select** //nombre-sucursal//, //número-préstamo//, //importe// * 100 **from** //préstamo//

devolverá una relación que es igual que la relación //préstamo//, salvo que el atributo //importe// está multiplicado por 100. SQL también proporciona tipos de datos especiales, tales como varias formas del tipo //fecha// y permite varias funciones aritméticas para operar sobre esos tipos.

**La cláusula where**

A continuación se ilustra con un ejemplo el uso de la cláusula **where** en SQL. Considérese la consulta «Obtener todos los números de préstamo para préstamos hechos en la sucursal con nombre Navacerrada, en los que el importe sea superior a 1.200 €». Esta consulta puede escribirse en SQL como

**select** //número-préstamo// **from** //préstamo//**where** //nombre-sucursal// = ‘Navacerrada’ **and** //importe// > 1200

SQL usa las conectivas lógicas **and**, **or** y **not** (en lugar de los símbolos matemáticos ∧, ∨ y ¬) en la cláusula **where**. Los operandos de las conectivas lógicas pueden ser expresiones que contengan los operadores de comparación <, <=, >, >=, = y <>. SQL permite usar los operadores de comparación para comparar cadenas y expresiones aritméticas, así como tipos especiales, tales como el tipo fecha.

SQL incluye un operador de comparación **between** para simplificar las cláusulas **where** que especifica queun valor sea menor o igual que un valor y mayor o igualque otro valor. Si se desea obtener el número de préstamode aquellos préstamos por importes entre 90.000€y 100.000 €, se puede usar la comparación **between** para escribir **select** //número-préstamo//

**from** //préstamo// **where** //importe// **between** 90000 **and** 100000en lugar de**select** //número-préstamo//

**from** //préstamo// **where** //importe// <= 100000 **and** //importe// >= 90000De forma análoga, se puede usar el operador de comparación**not between**.

**La cláusula from**

Finalmente, se estudia el uso de la cláusula **from**. La cláusula **from** define por sí misma un producto cartesiano de las relaciones que aparecen en la cláusula. Escribir una expresión SQL para la reunión natural es una tarea relativamente fácil, puesto que la reunión natural se define en términos de un producto cartesiano, una selección y una proyección. La expresión del álgebra relacional se escribe como sigue:

Π//nombre-cliente//, //número-préstamo//,//importe// (//prestatario préstamo//)

para la consulta «Para todos los clientes que tienen un préstamo en el banco, obtener los nombres, números de préstamo e importes». Esta consulta puede escribirse en SQL como

**select** //nombre-cliente//, //prestatario.número-préstamo//, //importe//**from** //prestatario//, //préstamo//**where** //prestatario.número-préstamo = préstamo.número-préstamo// Nótese que SQL usa la notación //nombre-relación//.//nombre-////atributo//, como lo hace el álgebra relacional, para evitar ambigüedad en los casos en que un atributo aparece en el esquema de más de una relación. También se podría haber escrito //prestatario.nombre-cliente// en lugar de //nombre-cliente//, en la cláusula **select**. Sin embargo, como el atributo //nombre-cliente// aparece sólo en una de las relaciones de la cláusula **from**, no existe ambigüedad

al escribir //nombre-cliente//. Se puede extender la consulta anterior y considerar un caso más complicado en el que se pide además qué clientes poseen un préstamo en la sucursal Navacerrada: «Obtener los nombres, números de préstamo e importes de todos los clientes que tienen un préstamo en la sucursal Navacerrada». Para escribir esta consulta será necesario establecer dos restricciones en la cláusula

**where**, relacionadas con la conectiva lógica **and**:

**select** //nombre-cliente//, //prestatario.número-préstamo//, //importe//**from** //prestatario//, //préstamo//

**where** //prestatario.número-préstamo = préstamo.número-préstamo// **and** //nombre-sucursal= ‘//Navacerrada’

SQL-92 incluye extensiones para llevar a cabo reuniones naturales y reuniones externas en la cláusula

**from**. Esto se estudiará en el Apartado 4.10.

**La operación renombramiento**

SQL proporciona un mecanismo para renombrar tanto relaciones como atributos. Para ello utiliza la cláusula **as**, que tiene la forma siguiente:

//nombre-antiguo// **//as//** //nombre-nuevo// la cláusula **as** puede aparecer tanto en **select** como en**from**.

Considérese de nuevo la consulta anterior: **select distinct** //nombre-cliente//, //prestatario.númeropréstamo//,

//Importe// **from** //prestatario//, //préstamo// **where** //prestatario.número-préstamo = préstamo.número-préstamo//

El resultado de esta consulta es una relación con los atributos siguientes:

//nombre-cliente//, //número-préstamo//, //importe.//

Los nombres de los atributos en el resultado se derivan de los nombres de los atributos de la relación que aparece en la cláusula **from**. Sin embargo, no se pueden derivar siempre los nombres de este modo. En primer lugar, dos relaciones que aparecen en la cláusula **from** pueden tener atributos con el mismo nombre, en cuyo caso, un nombre de atributo se duplica en el resultado. En segundo lugar, si se incluye una expresión aritmética en la cláusula **select**, los atributos resultantes no tienen el mismo nombre.

Y en tercer lugar, incluso si un nombre de atributo se puede derivar de las relaciones base, como en el ejemplo anterior, se puede querer cambiar el nombre del atributo en el resultado. Para todo ello, SQL proporciona una forma de renombrar los atributos de una relación resultado.

Por ejemplo, si se quisiera renombrar el atributo //número-préstamo//, asociándole el nombre de //id-préstamo//,

se podría reescribir la consulta anterior del siguiente modo

**select** //nombre-cliente//, //prestatario.número-préstamo// **as** //id-préstamo, importe// **from** //prestatario//, //préstamo//

**where** //prestatario.número-préstamo = préstamo.número-préstamo//

**Variables tupla**

La cláusula **as** es particularmente útil en la definición del concepto de variables tupla, como se hace en el

cálculo relacional de tuplas. Una variable tupla en SQL se debe asociar con una relación concreta. Las variables tupla se definen en la cláusula **from** mediante el uso de la cláusula **as**. Como ejemplo, a continuación se reescribe la consulta «Obtener los nombres y números de préstamo de todos los clientes que tienen un préstamo en el banco» como sigue

**select** //nombre-cliente//, //T.número-préstamo//, //S.importe// **from** //prestatario// **as** //T//, //préstamo// **as** //S// **where** //T.número-préstamo = S.número-préstamo// Nótese que se define la variable tupla en la cláusula**from**,

colocándola después del nombre de la relación ala cual está asociada y detrás de la palabra clave **as** (lapalabra clave **as** es opcional). Al escribir expresionesde la forma //nombre-relación.nombre-atributo//, el nombrede la relación es, en efecto, una variable tupla definida

implícitamente. Las variables tupla son de gran utilidad para comparar dos tuplas de la misma relación. Hay que recordar que, en los casos de este tipo, se puede usar la operación renombramiento del álgebra relacional. Si se desea formular la consulta «Obtener los nombres de todas las sucursales que poseen un activo mayor que al menos una sucursal situada en Barcelona», se puede escribir la siguiente expresión SQL

**select distinct** //T.nombre-sucursal//

**from** //sucursal// **as** //T//, //sucursal// **as** //S//

**where** //T.activo > S.activo// **and** //S.ciudad-sucursal =// ‘Barcelona’

Obsérvese que no se puede utilizar la notación //sucursal. activo//, puesto que no estaría claro a qué apariciónde //sucursal// se refiere.SQLpermite usar la notación (//v//1, //v//2,…, //vn//) para designaruna tupla de aridad //n// que contiene los valores //v//1, //v//2,…, //vn//. Los operadores de comparación se pueden utilizar

sobre tuplas, y el orden se define lexicográficamente. Por ejemplo (//a//1, //a//2) ≤ (//b//1, //b//2) es cierto si (//a//1 //< b//1) o si se cumple que (//a//1 //= b//1) ∧ (//a//2 //≤// //b//2); análogamente, dos tuplas son iguales si lo son todos sus atributos.

**Operaciones sobre cadenas**

SQL especifica las cadenas encerrándolas entre comillas simple, como ‘Navacerrada’, como se vio anteriormente. Un carácter comilla que sea parte de una cadena se puede especificar usando dos caracteres comilla; por ejemplo, la cadena «El carácter ‘ se puede ver en esta cadena» se puede especificar como ‘El carácter ‘’ se puede ver en esta cadena’. La operación más usada sobre cadenas es el encaje de patrones, para el que se usa el operador **like**. Para la descripción de patrones se utilizan los dos caracteres especiales siguientes:

• Tanto por ciento (%): El carácter % encaja con cualquier subcadena.

• Subrayado (_): El carácter _ encaja con cualquier carácter.

Los patrones son muy sensibles, esto es, los caracteres en mayúsculas no encajan con los caracteres en

minúscula, o viceversa. Para ilustrar el encaje de patrones, considérense los siguientes ejemplos:

• ‘Nava%’ encaja con cualquier cadena que empiece con «Nava».

• ‘%cer%’ encaja con cualquier cadena que contenga «cer» como subcadena, por ejemplo ‘Navacerrada’,

‘Cáceres’ y ‘Becerril’.

• ‘_ _ _’ encaja con cualquier cadena de tres caracteres.

• ‘_ _ _%’ encaja con cualquier cadena de al menos tres caracteres.

Los patrones se expresan en SQL utilizando el operador de comparación **like**. Considérese la consulta

siguiente: «Obtener los nombres de todos los clientes cuyas calles contengan la subcadena ‘Mayor’». Esta consulta se podría escribir como sigue **select** //nombre-cliente//

**from** //cliente// **where** //calle-cliente// **like** ‘%Mayor%’Para que los patrones puedan contener los caracteres

especiales patrón (esto es, % y _ ), SQL permite la especificación de un carácter de escape. El carácter de escape se utiliza inmediatamente antes de un carácter especial patrón para indicar que ese carácter especial va a ser tratado como un carácter normal. El carácter de escape para una comparación **like** se define utilizando la palabra clave **escape**. Para ilustrar esto, considérense los siguientes patrones, los cuales utilizan una barra invertida (\) como carácter de escape:

• **like** ‘ab\%cd%’ **escape** ‘\’ encaja con todas las cadenas que empiecen por ab%cd.

• **like** ‘ab\\cd%’ **escape** ‘\’ encaja con todas las cadenas que empiecen por ab\cd. SQL permite buscar discordancias en lugar de concordancias utilizando el operador de comparación **not like**. SQL también proporciona una variedad de funciones que operan sobre cadenas de caracteres, tales como la concatenación (usando «||»), la extracción de subcadenas, el cálculo de la longitud de las cadenas, la conversión a mayúsculas y minúsculas, etc. SQL:1999 también ofrece una operación **similar to** que proporciona un encaje de patrones más potente que la operación **like**; la sintaxis para especificar patrones es similar a la usada en Unix para expresiones regulares.

**Orden en la presentación de las tuplas**

SQL ofrece al usuario cierto control sobre el orden en el cual se presentan las tuplas de una relación. La cláusula **order by** hace que las tuplas resultantes de una consulta se presenten en un cierto orden. Para listar en orden alfabético todos los clientes que tienen un préstamo en la sucursal Navacerrada se escribirá:

**select distinct** //nombre_cliente//

**from** //prestatario//, //préstamo//

**where** //prestatario.número-préstamo//

//= préstamo.número-préstamo// **and**

//nombre-sucursal =// ‘Navacerrada’

**order by** //nombre-cliente//

** --6.4 Operaciones sobre conjuntos. **

operan sobre relaciones y corresponden a las operaciones del álgebra relacional ∪, ∩ y –. Al igual que la unión, intersección y diferencia de conjuntos en el álgebra relacional, las relaciones que participan en las operaciones han de ser //compatibles//; esto es, deben tener el mismo conjunto de atributos.

A continuación se demuestra cómo se pueden formular en SQL varias de las consultas de ejemplo consideradas en el Capítulo 3 utilizando consultas que incluyen las operaciones **union**, **intersect** y **except** de dos conjuntos. Los dos conjuntos utilizados serán: el conjuntos de todos los clientes que tienen una cuenta en el banco, que puede obtenerse con:

**select** //nombre-cliente//

**from** //impositor// y el conjunto de todos los clientes que tienen un préstamoen el banco, que puede obtenerse con:

**select** //nombre-cliente//

**from** //prestatario//

Apartir de ahora, las letras //i// y //p// se utilizarán para hacer referencia a las relaciones obtenidas como resultado de las dos consultas anteriores.

**La operacion unión**

Para encontrar todos los clientes que poseen un préstamo, una cuenta o las dos cosas en el banco, se escribirá:

(**select** //nombre-cliente// **from** //impositor//) **unión** (**select** //nombre-cliente//**from** //prestatario//)

A diferencia de la cláusula **select**, la operación **unión** (unión) elimina duplicados automáticamente. Así, en laconsulta anterior, si un cliente —por ejemplo, Santos—tiene varias cuentas o préstamos (o ambas cosas) en elbanco, entonces Santos aparecerá sólo una vez en elresultado.

Para conservar los duplicados, se utilizará **union all** en lugar de **union**:

(**select** //nombre-cliente// **from** //impositor//)**union all**(**select** //nombre-cliente// **from** //prestatario//)

El número de tuplas duplicadas en el resultado es igual al número total de duplicados que aparecen en //i// y //p//. Así, si Santos tuviese tres cuentas y dos préstamos en el banco, entonces en el resultado aparecerían cinco tuplas con el nombre de Santos.

**La operación intersección**

Para encontrar todos los clientes que tienen tanto un préstamo como una cuenta en el banco, se escribirá: (**select distinct** //nombre-cliente// **from** //impositor//)**intersect**

(**select distinct** //nombre-cliente// **from** //prestatario//)

La operacion **intersect** (intersección) elimina duplicados automáticamente. Así, en la consulta anterior, si un cliente —por ejemplo, Santos— tiene varias cuentas préstamos (o ambas cosas) en el banco, entonces Santos aparecerá solo una vez en el resultado. Para conservar los duplicados se utilizará **intersect****all** en lugar de **intersect**:

(**select** //nombre-cliente// **from** //impositor//)**intersect all**(**select** //nombre-cliente//**from** //prestatario//)

El número de tuplas duplicadas en el resultado es igual al mínimo número de duplicados que aparecen en //i// y //p//. Así, si Santos tuviese tres cuentas y dos préstamos en el banco, entonces en el resultado de la consulta aparecerían dos tuplas con el nombre de Santos.

**La operación excepto**

Para encontrar todos los clientes que tienen cuenta pero no tienen ningún préstamo en el banco se escribirá: (**select distinct** //nombre-cliente// **from** //impositor//)**except**(**select distinct** //nombre-cliente// **from** //prestatario//)

La operacion **except** (excepto) elimina duplicados automáticamente. Así, en la consulta anterior, una tupla con el nombre de Santos aparecerá en el resultado (exactamente una vez), sólo si Santos tiene una cuenta en el banco, pero no tiene ningún préstamo en el mismo. Para conservar los duplicados, se utilizará **except all** en lugar de **except**:

(**select** //nombre-cliente// **from** //impositor//)**except all**(**select** //nombre-cliente// **from** //prestatario//)

El número de copias duplicadas de una tupla en el resultado es igual al número de copias duplicadas de dicha tupla en //i// menos el número de copias duplicadas de la misma tupla en //p//, siempre que la diferencia sea positiva. Así, si Santos tuviese tres cuentas y un préstamo en el banco, entonces en el resultado aparecerían dos tuplas con el nombre de Santos. Si, por el contrario, dicho cliente tuviese dos cuentas y tres préstamos en el banco, no habrá ninguna tupla con el nombre de Santos en el resultado.

** --6.5 Funciones de agregación. **

Las funciones de agregación son funciones que toman una colección (un conjunto o multiconjunto) de valores como entrada y producen un único valor como salida. SQL proporciona cinco funciones de agregación primitivas:

• Media: **avg** • Mínimo: **min** • Máximo: **max** • Total: **sum** • Cuenta: **count**

La entrada a **sum** y **avg** debe ser una colección de números, pero los otros operadores pueden operar sobre colecciones de datos de tipo no numérico, tales como las cadenas.

Como ejemplo, considérese la consulta «Obtener la media de saldos de las cuentas de la sucursal Navacerrada ». Esta consulta se puede formular del modo siguiente:

**select avg** (//saldo//) **from** //cuenta// **where** //nombre-sucursal// = ‘Navacerrada’

El resultado de esta consulta será una relación con un único atributo, que contendrá una única fila con un valor numérico correspondiente al saldo medio de la sucursal Navacerrada. Opcionalmente se puede dar un nombre al atributo resultado de la relación, usando la cláusula **as**. Existen situaciones en las cuales sería deseable aplicar las funciones de agregación no sólo a un único conjunto de tuplas sino también a un grupo de conjuntos de tuplas; esto se especifica en SQL usando la cláusula **group by**. El atributo o atributos especificados en la cláusula **group by** se usan para formar grupos. Las tuplas con el mismo valor en todos los atributos especificados en la cláusula **group by** se colocan en un grupo. Como ejemplo, considérese la consulta «Obtener el saldo medio de las cuentas de cada sucursal». Dicha consulta se formulará del modo siguiente

**select** //nombre-sucursal//, **avg** (//saldo//) **from** //cuenta//**group by** //nombre-sucursal//

La conservación de duplicados es importante al calcular una media. Supóngase que los saldos de las cuentas en la (pequeña) sucursal de nombre «Galapagar» son 1.000 €, 3.000 €, 2.000 € y 1.000 €. El saldo medio es 7.000/4 =1.750 €. Si se eliminasen duplicados se obtendría un resultado erróneo (6.000/3 = 2.000 €). Hay casos en los que se deben eliminar los duplicados antes de calcular una función de agregación. Para eliminar duplicados se utiliza la palabra clave **distinct** en la expresión de agregación. Como ejemplo considérese la consulta «Obtener el número de impositores de cada sucursal». En este caso un impositor sólo se debe contar una vez, sin tener en cuenta el número de cuentas que el impositor pueda tener. La consulta se formulará del modo siguiente:

**select** //nombre-sucursal//, **count** (**distinct** //nombrecliente//) **from** //impositor//, //cuenta//**where** //impositor.número-cuenta// = //cuenta.númerocuenta//**group by** //nombre-sucursal//

A veces es más útil establecer una condición que se aplique a los grupos que una que se aplique a las tuplas. Por ejemplo, podemos estar interesados sólo en aquellas sucursales donde el saldo medio de cuentas es superior a 1.200 €. Esta condición no es aplicable a una única tupla; se aplica a cada grupo construido por la cláusula **group****by**. Para expresar este tipo de consultas se utiliza la cláusula **having** de SQL. Los predicados de la cláusula **having** se aplican después de la formación de grupos, de modo que se pueden usar las funciones de agregación. Esta consulta se expresa en SQL del modo siguiente:

**select** //nombre-sucursal//, **avg** (//saldo//) **from** //cuenta//**group by** //nombre-sucursal//**having avg** (saldo) > 1200

A veces se desea tratar la relación entera como un único grupo. En casos de este tipo no se usa la cláusula **group by**. Considérese la consulta «Obtener el saldo medio de todas las cuentas». Esta consulta se formulará del modo siguiente:

**select avg** (//saldo//) **from** //cuenta//

Con mucha frecuencia se usa la función de agregación **count** para contar el número de tuplas de una relación. La notación para esta función en SQL es **count** (*). Así, para encontrar el número de tuplas de la relación //cliente//, se escribirá

**select count** (*) **from** //cliente//

SQL no permite el uso de **distinct** con **count** (*). Sí se permite, sin embargo, el uso de **distinct** con **max** y **min**, incluso cuando el resultado no cambia. Se puede usar la palabra clave **all** en lugar de **distinct** para especificar la retención de duplicados, pero como **all** se especifica de manera predeterminada, no es necesario incluir dicha cláusula. Si en una misma consulta aparece una cláusula **where** y una cláusula **having**, se aplica primero el predicado de la cláusula **where**. Las tuplas que satisfagan el predicado de la cláusula **where** se colocan en grupos según la cláusula **group by**. La cláusula **having**, si existe, se aplica entonces a cada grupo; los grupos que no satisfagan el predicado de la cláusula **having** se eliminan. La cláusula **select** utiliza los grupos restantes para generar las tuplas resultado de la consulta. Para ilustrar el uso de la cláusula **where** y la cláusula **having** dentro de la misma consulta considérese el ejemplo «Obtener el saldo medio de cada cliente que vive en Madrid y tiene como mínimo tres cuentas».

**select** //impositor.nombre-cliente//, **avg**

**avg** (//saldo//) **from** //impositor//, //cuenta//, //cliente//**where** //impositor.número-cuenta////= cuenta.número-cuenta// **and**//impositor.nombre-cliente////= cliente.nombre-cliente// **and**//ciudad-cliente// = ‘Madrid’ **group by** //impositor.nombre-cliente//**having count** (**distinct** //impositor.número-cuenta//) >= 3

** --6.6 Valores nulos. **

SQL permite el uso de valores nulos para indicar la ausencia de información sobre el valor de un atributo. En un predicado se puede usar la palabra clave especial **null** para comprobar si un valor es nulo. Así, para encontrar todos los números de préstamo que aparecen en la relación //préstamo// con valores nulos para //importe// se escribe

**select** //número-préstamo// **from** //préstamo// **where** //importe// **is nul**

El predicado **is not null** pregunta por la ausencia de un valor nulo. El uso de un valor nulo en las operaciones aritméticas y de comparación causa varias complicaciones. En el Apartado 3.3.4 se vio cómo se manejan los valores nulos en el álgebra relacional. Ahora se describe cómo maneja SQL los valores nulos. El resultado de una expresión aritmética (incluyendo por ejemplo +,–,* o /) es nulo si cualquiera de los valores de entrada es nulo. SQL trata como **desconocido** el resultado de cualquier comparación que implique un valor //nulo// (aparte de **is null** e **is not null**). Dado que el predicado en una cláusula **where** puede incluir operaciones booleanas tales como **and**, **or** y **not** sobre los resultados de las comparaciones, las definiciones de estas operaciones se extienden para manejar el valor **desconocido**, como se describe en el Apartado3.3.4.

• **and**: el resultado de //cierto// **and** //desconocido// es //desconocido//, //falso// **and** //desconocido// es //falso//, mientras que //desconocido// **and** //desconocido// es //desconocido//. • **or**: el resultado de //cierto// **or** //desconocido// es //cierto//, //falso// **or** //desconocido// es //desconocido//, mientras que //desconocido// **or** //desconocido// es //desconocido//. SQL define el resultado de una instrucción SQL de la forma **select … from** //R//1//,// …//., Rn// **where** //P// para contener (proyecciones de) tuplas en //R//1 × … × //Rn// para las que el predicado //P// se evalúa a **cierto**. Si el predicado se evalúa a **falso** o **desconocido** para una tupla de //R//1 × … × //Rn// (la proyección de) la tupla no se añade al resultado. SQL también permite determinar si el resultado de una comparación es desconocido en lugar de cierto o falso usando las cláusulas **is unknown** (es desconocido) e **is not unknown** (no es desconocido) La existencia de valores nulos también complica el procesamiento de los operadores de agregación. Supóngase que algunas tuplas en la relación //préstamo// tienen valor nulo para el atributo //importe.// Considérese en ese caso la siguiente consulta, que calcula el total de todas las cantidades prestadas:

**select sum** (//importe//) **from** //préstamo//

Los valores que van a ser sumados en la consulta anterior incluyen valores nulos, puesto que algunas tuplas tienen valor nulo para el atributo //importe//. En lugar de decir que la suma total es nula, la norma SQL establece que el operador **sum** debería ignorar los valores nulos de su entrada. En general, las funciones de agregación tratan los valores nulos según la regla siguiente: todas las funciones de agregación excepto **count(*)** ignoran los valores nulos de la colección de datos de entrada. Como resultado de ignorar los valores nulos, la colección de valores de entrada puede resultar vacía. El cálculo de **count** de una colección vacía se define como 0 y todas las demás operaciones de agregación devuelven un valor nulo cuando se aplican sobre una colección de datos vacía. El efecto de los valores nulos en algunas de las construcciones más complicadas de SQL puede ser más sutil. En SQL:1999 se introdujo un tipo de datos **boolean**, que puede tomar los valores **cierto**, **falso** y **desconocido**. Las funciones de agregación **some** (algún) y **every** (cada), que significan exactamente lo que se espera de ellas, se pueden aplicar a una colección de valores booleanos.

** --6.7 Consultas anidadas. **

media type="youtube" key="bHLkkuE3RqE" width="425" height="350" align="center"

**Unidad 7** **Bases de Datos Orientadas a objetos.**

** --7.1 Visión general. **

Los lenguajes de programación persistentes añaden la persistencia y otras características de las bases de datos a los lenguajes de programación existentes con sistemas de tipos orientados a objetos. Por el contrario, los //modelos de datos relacionales orientados a////objetos// extienden el modelo de datos relacional proporcionando un sistema de tipos más rico e incluyendo tipos de datos complejos y la programación orientada a objetos. Los lenguajes de consulta relacionales como SQL también necesitan ser extendidos para trabajar con el sistema de tipos enriquecido. Estas extensiones intentan conservar los fundamentos relacionales —en concreto, el acceso declarativo a los datos— al tiempo que extienden la capacidad de modelado. Los sistemas de bases de datos relacionales orientados a objetos (es decir, los sistemas de bases de datos basados en el modelo objeto-relación) proporcionan un modo de cambio adecuado para los usuarios de las bases de datos relacionales que deseen utilizar características orientadas a objetos. En primer lugar, se presenta la motivación del modelo relacional anidado, que permite relaciones que no cumplen la primera forma normal y permite la representación directa de las estructuras jerárquicas. Posteriormente se muestra la manera de extender SQL añadiendo varias Características relacionales orientadas a objetos. El estudio se basa en la norma SQL:1999. Finalmente se analizan las diferencias entre los lenguajes de programación persistentes y los sistemas relacionales orientados a objetos y se mencionan los criterios para la elección entre unos y otros

** --7.2 Tipos de datos complejos. **

Las relaciones anidadas son sólo un ejemplo de las extensiones del modelo relacional básico. Otros tipos de datos no atómicos, como los registros anidados, también se han mostrado útiles. El modelo de datos orientado a objetos ha creado la necesidad de características como la herencia y las referencias a los objetos. Los sistemas de tipos complejos y la programación orientada a objetos permiten que los conceptos del modelo E-R, como la identidad de las entidades, los atributos multivalorados y la generalización y la especialización, se representen directamente sin haga falta una compleja traducción al modelo relacional. En este apartado se describen las extensiones de para que permita los tipos complejos, incluyendo relaciones anidadas y las características orientadas objetos. La presentación se basa en la norma SQL: pero también se describen características que no actualmente en la norma pero que pueden ser introducidas en futuras versiones de la norma SQL.
 * Tipos colección y tipos de objetos de gran tamaño**

Considérese este fragmento de código. ... //lista-palabras-clave// **setof**(**varchar**(20)) ...)
 * create table** //libros// (

Esta definición de tabla es diferente de las definiciones en las bases de datos relacionales normales, ya que permite que los atributos sean **conjuntos**, permitiendo que los atributos multivalorados de los diagramas E-R se representen directamente. Los conjuntos son ejemplares de los **tipos colección**. Otros ejemplares son los **arrays** y los **multiconjuntos** (es decir, colecciones sin orden donde un elemento puedeaparecer varias veces). Las siguientes definicionesde atributos ilustran la declaración de un //array//://array-autores// **varchar**(20) **array** [10]//array-autores// es un //array// de hasta 10 nombres de autor. Se puede acceder a los elementos del //array// especificando el índice del //array//, por ejemplo, //array-autores//[1]. Los //arrays// son el único tipo colección soportado en SQL:1999; la sintaxis usada es como en la declaración precedente. SQL:1999 no da soporte a conjuntos sin orden o multiconjuntos, aunque es posible que aparezcan en versiones futuras de SQL1. Muchas aplicaciones actuales de bases de datos necesitan almacenar atributos grandes (del orden de varios kilobytes), tales como la fotografía de una persona, o muy grandes (del orden de varios megabytes o incluso gigabytes), tales como imágenes médicas de alta resolución o clips de vídeo. SQL:1999 proporciona por tanto nuevos tipos de datos para objetos de gran tamaño para datos de caracteres (**clob**) y binarios (**blob**). Las letras «lob» en estos tipos de datos son acrónimos de «Large OBject» (objeto grande). Por ejemplo, se pueden declarar los siguientes atributos:

//crítica-libro// **clob**(10KB) //imagen// **blob**(10MB) //película// **blob**(2GB)

Los objetos grandes se usan normalmente en aplicaciones externas, y tiene poco sentido extraerlos completamente en SQL. En su lugar, una aplicación conseguiría un «localizador» de un objeto grande y lo usaría para manipularlo desde el lenguaje anfitrión. Por ejemplo, JDBC permite al programador extraer un objeto grande en pequeños trozos, en lugar de todo a la vez, de forma muy parecida a la extracción de datos de un archivo del sistema operativo.

Los tipos estructurados se pueden declarar y usar en SQL:1999 como en el siguiente ejemplo:
 * Tipos estructurados**

(//nombre// **varchar**(20), //sucursal// **varchar**(20)) (//título// **varchar**(20), //array-autores// **varchar**(20) **array** [10], //fecha-pub// **date**, //editorial Editorial//, //lista-palabras-clave// **setof**(**varchar**(20)))
 * create type** //Editorial// **as**
 * create type** //Libro// **as**
 * create table** //libros// **of type** //Libro//

La primera instrucción define el tipo //Editorial//, que tiene dos componentes: un nombre y una sucursal. La segunda instrucción define el tipo //Libro//, que contiene //título//, //array-autores//, que es un //array// de autores, una fecha de publicación, una editorial (de tipo //Editorial//) y un conjunto de palabras clave. (La declaración de //lista-palabrasclave// como un conjunto usa la sintaxis extendida y no está soportada en la norma SQL:1999.) Los tipos ilustrados se denomina **tipos estructurados** en SQL:1999. Finalmente, se crea la tabla //libros// que contiene tuplas del tipo //Libro//. La tabla es similar a la relación anidada //libros// de la Figura 9.1, excepto en que se ha decidido crear un //array// de nombres de autores en lugar de un conjunto. El //array// permite registrar el orden de los nombres de autores. Los tipos estructurados permiten la representación directa de atributos compuestos de los diagramas E-R. También se pueden usar **tipos fila** en SQL:1999 para definir atributos compuestos. Por ejemplo, se podría haber definido un atributo //editorial1// como //editorial1// **row** (//nombre// **varchar**(20), //sucursal// **varchar**(29)) en lugar de crear un tipo con nombre //Editorial//. Por supuesto se pueden crear tablas sin crear un tipo intermedio para la tabla. Por ejemplo, la tabla //libros// se podría también definir como: **create table** //libros// (//título// **varchar**(20), //array-autores// **varchar**(20) **array** [10], //fecha-pub// **date**, //editorial Editorial//, //lista-palabras-clave// **setof**(**varchar**(20))) Con esta declaración no hay un tipo explícito para las filas de la tabla2. Un tipo estructurado puede tener **métodos** definidos sobre él. Los métodos se declaran como parte de la definición de tipos de un tipo estructurado. **create type** //Empleado// **as** ( //nombre// **varchar**(20), //sueldo// **integer**) **method** //incrementar//(//porcentaje// **integer**) El cuerpo del método se crea separadamente: **create method** //incrementar//(//porcentaje// **integer**) **for** //Empleado//**begin****set selft**.sueldo = **self**.sueldo + (**self**.sueldo* porcentaje)/100 **end** La variable **self** se refiere al ejemplar del tipo estructurado sobre el que se invoca el método. El cuerpo del método puede contener instrucciones procedimentales, que se estudiarán en el Apartado 9.6.


 * Creación de valores de tipos complejos**

En SQL:1999 se usan las **funciones constructoras** para crear valores de tipos estructurados. Una función con el mismo nombre que un tipo estructurado es una función constructora para el tipo estructurado. Por ejemplo, se podría declarar una constructora para el tipo //Editorial// como:


 * create function** //Editorial// (//n// **varchar**(20), //s// **varchar**(20))
 * returns** //Editorial//
 * begin**
 * set** //nombre = n//;
 * set** //sucursal// = //s//;
 * end**

Se puede usar entonces //Editorial//(‘McGraw-Hill’, ‘Nueva York’) para crear un valor del tipo //Editorial//. SQL:1999 también soporta otras funciones además de las constructoras, como se verá en el Apartado 9.6; los nombres de estas funciones deben ser diferentes de cualquier tipo estructurado. Nótese que en SQL:1999, a diferencia de en las bases de datos orientadas a objetos, un constructor crea un valor del tipo, no un objeto del tipo. Es decir, el valor que crea el constructor no tiene identidad de objeto. Los objetos en SQL:1999 se corresponden con tuplas de una relación, y se crean insertando tuplas en las relaciones. De manera predeterminada, cada tipo estructurado tiene un constructor sin argumentos, que establece los atributos a sus valores predeterminados. Cualquiera otra constructora tiene que crearse explícitamente. Puede haber más de una constructora para el mismo tipo estructurado; aunque tengan el mismo nombre, tienen que ser distinguibles por el número de argumentos y sus tipos. En SQL:1999 se puede crear un //array// de valores como:


 * array**[‘Silberschatz’, ‘Korth’, ‘Sudarsan’]

Se puede construir un valor de fila listando sus atributos entre paréntesis. Por ejemplo, si se declara un atributo //editorial1// como un tipo fila (como en el Apartado 9.2.2), se puede construir el siguiente valor para él: (‘McGraw-Hill’, ‘Nueva York’) sin usar una constructora. Los atributos de tipo conjunto, tales como //lista-palabras-////clave//, se crean enumerando sus elementos entre paréntesis siguiendo a la palabra clava **set**. Se pueden crear valores de tipo multiconjunto al igual que con los valores de tipo conjunto, reemplazando **set** por **multiset**3. Así, se puede crear una tupla del tipo definido por la relación //libros// como: (‘Compiladores’,**array**[‘Gómez’, ‘Santos’], //Editorial//(‘McGraw-Hill’, ‘Nueva York’), **set**(‘ traducción, análisis’)) Aquí se ha creado un valor para el atributo //Editorial// invocando a la función //constructora// de //Editorial// con argumentos apropiados. Si se desea insertar la tupla anterior en la relación //libros//, se podría ejecutar la instrucción:


 * insert into** //libros//
 * values** (‘Compiladores’,**array**[‘Gómez’, ‘Santos’],//Editorial//(‘McGraw-Hill’, ‘Nueva York’),
 * set**(‘ traducción, análisis’))

media type="youtube" key="f156-2ZmxPw" width="425" height="350" align="center"