Download - Capitulo 1- Introducion

8/2/2019 Capitulo 1- Introducion

http://slidepdf.com/reader/full/capitulo-1-introducion 1/38

Fundamentos de diseño de bases de datos

Quinta edición

ABRAHAM,SILBERSCHATZ Universidad de Yale

HENRYF.KORTH

Universidad de Lehigh

S. SUDARSHAN

Instituto tecnológico indio, Bombay

Traducción

FERNANDO SÁENZ PÉREZANTONIO GARCÍA CORDEROJESÚS CORREAS FERNÁNDEZ

Universidad Complutense de Madrid

Revisión técnica

LUIS GRAU FERNÁNDEZ

Universidad Nacional de Educación a Distancia

MADRID BOGOTÁ BUENOS AIRES CARACAS GUATEMALA LISBOAMÉXICO NUEVA YORK PANAMÁ SAN JUAN SANTIAGO SAO PAULO

AUCKLAND HAMBURGO LONDRES MILÁN MONTREAL NUEVA DELHl PARÍSSAN FRANCISCO SIDNEY SINGAPUR ST. LOUIS TOKIO TORONTO

■■'■!' .



Contenido

Prefacio XIII

Capítulo 1 Introducción 1.1 Aplicaciones de los sistemas de bases de datos 11.91.2 Propósito de los sistemas de bases de datos 2 1.101.3 Visión de los datos 4 1.111.4 Lenguajes de bases de datos 7 1.121.5 Bases de datos relaciónales 9 1.131.6 Diseño de bases de datos 11 1.141.7 Bases de datos basadas en objetos y

semiestructuradas 151.8 Almacenamiento de datos y consultas 16

Gestión de transacciones 17 Minería y análisisde datos 18 Arquitectura de las bases de datos19 Usuarios y administradores de bases de datosHistoria de los sistemas de bases de datos 22Resumen 24 Ejercicios 25 Notasbibliográficas 26

PARTE 1 BASES DE DATOS RELACIÓNALES

Capítulo 2 El modelo relacional 2.1 La estructura de las bases de datos relaciónales 292.2 Operaciones fundamentales del álgebra

relacional 362.3 Otras operaciones del álgebra relacional 442.4 Operaciones del álgebra relacional extendida 48

2.5 Valores nulos 532.6 Modificación de la base de datos2.7 Resumen 56

Ejercicios 57Notas bibliográficas 59

54

Capítulo 3 SQL

3.1 Introducción 613.2 Definición de datos 623.3 Estructura básica de las consultas SQL3.4 Operaciones sobre conjuntos 713.5 Funciones de agregación 733.6 Valores nulos 753.7 Subconsultas anidadas 76

3.8 Consultas complejas 803.9 Vistas 8165 . 3.10 Modificación de la base de datos

3.11 Reunión de relaciones** 903.12 Resumen 94


84



Contenido

Capítulo 4 SQL avanzado

4.1 Tipos de datos y esquemas 1014.2 Restricciones de integridad 1054.3 Autorización 111

4.4 SQL incorporado 1124.5 SQL dinámico 1144.6 Funciones y procedimientos** 121

4.7 Consultas recursivas** 126 4.8 Características avanzadas

de SQL 129

4.9 Resumen 132Ejercicios 133 Notas bibliográficas 133

Capítulo 5 Otros lenguajes relaciónales

5.1 El cálculo relacional de tupias 1375.2 El cálculo relacional de dominios 1415.3 Query-by-Example 144

5.4 Resumen 151 Ejercicios152 Notas bibliográficas153

PARTE 2 DISEÑO DE BASES DE DATOS

6.1 Visión general del proceso de diseño 1576.2 El modelo entidad-relación 1596.3 Restricciones 1646.4 Diagramas entidad-relación 1686.5 Aspectos del diseño entidad-relación 172

6.6 Conjuntos de entidades débiles 1776.7 Características del modelo E-R extendido 178

6.8 Diseño de una base de datospara banco6.9 Reducción a esquemasrelacionales

6.10 Otros aspectos del diseño de

datos6.11 El lenguaje de modelado UML6.12 Resumen 200


Capítulo 7 Diseño de bases de datos relaciónales

7.1 Características de los buenos diseñosrelaciónales 207

7.2 Dominios atómicos y la primera forma normal7.3 Descomposición mediante dependencias

funcionales 2127.4 Teoría de las dependencias funcionales 2197.5 Algoritmos de descomposición 227

7.6 Descomposición mediantedependencias: multivaloradas 232 2117.7 Más formas normales 236

7.8 Proceso de diseño de las basse

de datos7.9 Modelado de datos temporales.

7.10 Resumen 241

Ejercicios 242 Notas bibliográficas 245

Capítulo 8 Diseño y desarrollo de aplicaciones

8.2 Interfaces de usuario y herramientas 147 8.7 Autorización en SQL266 8.2 Interfaces Web para bases de datos 250 8.8 Seguridad de las aplicaciones

Capítulo 6 Diseño de bases de datos y el modelo E-R

6.8 Diseño de una base de datos



8.3 Fundamentos de Web 251 8.9 Resumen 2798.4 Servlets y JSP 255 Ejercicios2818.5 Creación de aplicaciones Web de gran tamaño 259 Notas bibliográficas 2858.6 Disparadores 261



Contenido x¡

PARTE 3 BASES DE DATOS ORIENTADAS A OBJETOS Y XML

Capítulo 9 Bases de datos basadas en objetos

9.1 Visión general 289

9.2 Tipos de datos complejos 2909.3 Tipos estructurados y herencia en SQL 2919.4 Herencia de tablas 2969.5 Tipos array y multiconjunto en SQL 2979.6 Identidad de los objetos y tipos de referencia en SQL

301

Capítulo 10 XML

10.1 Motivación 31710.2 Estructura de los datos XML 32010.3 Esquema de los documentos XML 32310.4 Consulta y transformación 328

10.5 La interfaz de programación de aplicaciones deXML 337

10.6 Almacenamiento de datos XML10.7 Aplicaciones XML 34210.8 Resumen 346

Ejercicios 348

Notas bibliográficas 350

338

ALMACENAMIENTO DE DATOS

Almacenamiento y estructura de archivos

11.1 Visión general de los medios físicos de 11.6 Organización de los archivos374 almacenamiento 355 11.7 Organización de los registros en archivos 378

11.2 Discos magnéticos 358 11.8 Almacenamiento con diccionarios de datos11.3 RAID 363 11.9 Resumen 38311.4 Almacenamiento terciario 370 Ejercicios 384

11.5 Acceso al almacenamiento 371 Notas bibliográficas 386

381

Capítulo 12 Indexación y asociación

12.1 Conceptos básicos 38912.2 índices ordenados 39012.3 Archivos de índices de árbol B+ 39612.4 Archivos de índices de árbol B 40512.5 Accesos bajo varias claves 40612.6 Asociación estática 40912.7 Asociación dinámica 414

12.8 Comparación de la indexación ordenada y laasociación 419

12.9 índices de mapas de bits 420

12.10 Definición de índices en SQL 42312.11 Resumen 424


PARTE 5 OTROS TEMAS

Capítulo 13 Transacciones

13.1 Concepto de transacción 43313.2 Estados de una transacción 43613.3 Implementación de la atomicidad y la

durabilidad 43813.4 Ejecuciones concurrentes 43913.5 Secuencialidad 442

13.6 Recuperabilidad 44613.7 Implementación del aislamiento 44813.8 Comprobación de la secuencialidad 44813.9 Resumen 449

Ejercicios451Notas bibliográficas 453

9.7 Implementación de las características O-R 3039.8 Lenguajes de programación persistentes 3049.9 Sistemas orientados a objetos y sistemas

relaciónales orientados a objetos 3109.10 Resumen 311 Ejercicios

312 Notas bibliográficas315

PARTE 4

Capítulo 11



XII Contenido

Capítulo 14 Análisis y minería de datos

14.1 Sistemas de ayuda a la toma de decisiones 455 14.5 Resumen 47914.2 Análisis de datos y OLAP 456 Ejercicios 481

14.3 Almacenes de datos 466 Notas bibliográficas 48214.4 Minería de datos 469

Capítulo 15 Tipos de datos avanzados y nuevas aplicaciones

15.1 Motivación 485 15.5 Computadoras portátiles y bases de datos15.2 El tiempo en las bases de datos 486 personales 49915.3 Datos espaciales y geográficos 488 15.6 Resumen 50415.4 Bases de datos multimedia 497 Ejercicios 505

Notas bibliográficas 507

Bibliografía 509

índice 517



Este libro es una versión abreviada de la quinta edición de Fundamentos de bases de datos (publicada porMcGraw-Hill/Interamericana de España a principios de 2006) y orientada a cursos de diseño de bases de datos,

en el que se han omitido los aspectos avanzados y de implementación de los sistemas gestores de bases de datosque se pueden encontrar en la versión completa.

La gestión de las bases de datos ha evolucionado desde una aplicación informática especializada hastaconvertirse en parte esencial de los entornos informáticos modernos. Por tanto, el conocimiento acerca de lossistemas de bases de datos se ha convertido en una parte imprescindible de la formación en informática. En estetexto se presentan los conceptos fundamentales de la gestión de las bases de datos. Estos conceptos incluyenaspectos del diseño de bases de datos y de los lenguajes.

Este libro está orientado a un primer curso de bases de datos para los niveles técnicos y superiores. Ademásdel material básico para un primer curso, el texto también contiene material avanzado que se puede usar comocomplemento del curso o como material introductorio de un curso avanzado.

En este libro se asume que se dispone de conocimientos básicos sobre estructuras de datos básicas, or-ganización de computadoras y un lenguaje de programación de alto nivel (tipo Pascal). Los conceptos sepresentan usando descripciones intuitivas, muchas de las cuales están basadas en el ejemplo propuesto de una

entidad bancaria. Se tratan los resultados teóricos importantes, pero se omiten las demostraciones formales. Enlugar de las demostraciones se usan figuras y ejemplos para sugerir su justificación. Las descripciones formalesy las pruebas pueden hallarse en los artículos de investigación y en los textos avanzados a los que se hacereferencia en las notas bibliográficas.

Los conceptos y algoritmos fundamentales tratados en este libro suelen basarse en los usados en sistemas debases de datos comerciales o experimentales ya existentes. El objetivo es presentar esos conceptos y algoritmosen un marco general que no esté vinculado a ningún sistema de bases de datos en concreto.

En esta versión abreviada de la quinta edición de Fundamentos de bases de datos se ha mantenido el estiloglobal de las ediciones anteriores, mientras que su contenido y organización han evolucionado para reflejar lasmodificaciones que se están produciendo en el modo en que las bases de datos se diseñan, se gestionan y seusan. También se han tenido en cuenta las tendencias en la enseñanza de los conceptos de bases de datos y sehan hecho adaptaciones para facilitar esas tendencias donde ha resultado conveniente. Antes de describir elcontenido del libro con detalle, se destacarán algunas de las características de la quinta edición.

• Tratamiento precoz de SQL. Muchos profesores usan SQL como componente principal de susproyectos de fin de curso (visítese el sitio Web http://www.mhe.es/silberschatz5 para ver proyectos deejemplo). Con objeto de proporcionar a los estudiantes tiempo suficiente para realizar los proyectos,especialmente en universidades que trabajen por trimestres, resulta fundamental enseñar SQL tan prontocomo sea posible. Con esto en mente se han llevado a cabo varias modificaciones en la organización dellibro:

XIII

http://www.mhe.es/silberschatz5

http://www.mhe.es/silberschatz5



1. Aplazar la presentación del modelo entidad-relación hasta la Parte 2, titulada "Diseño de bases dedatos".

2. Racionalizar la introducción del modelo relacional mediante el aplazamiento del tratamiento delcálculo relacional hasta el Capítulo 5, mientras se mantiene el tratamiento del álgebra relacional enel Capítulo 2.

3. Dedicar dos de los primeros capítulos a SQL. El Capítulo 3 trata las características básicas de SQL,

incluidas la definición y la manipulación de los datos. El Capítulo 4 trata características másavanzadas, como las restricciones de integridad, SQL dinámico y los constructores procedimentales.Entre el material nuevo de este capítulo figura un tratamiento más amplio de JDBC, de losconstructores procedimentales en SQL, de la recursión en SQL y de las nuevas características deSQL:2003. Este capítulo también incluye una breve visión general de las autorizaciones, aunque sutratamiento detallado se pospone hasta el Capítulo 8.

Estas modificaciones permiten que los estudiantes comiencen a escribir consultas de SQL en unaetapa inicial del curso y que se familiaricen con el empleo de los sistemas de bases de datos. Estotambién permite a los estudiantes desarrollar una intuición sobre el diseño de bases de datos que facilitala enseñanza de las metodologías de diseño en la Parte 2 del texto. Se ha descubierto que los estudiantesaprecian mejor los aspectos del diseño de bases de datos con esta organización.

• Una parte nueva (la Parte 2) que está dedicada al diseño de las bases de datos. La Parte 2del texto contiene tres capítulos dedicados al diseño de las bases de datos y de las aplicaciones para basesde datos. Aquí se incluye un capítulo (el Capítulo 6) sobre el modelo entidad-relación que contiene todoel material del capítulo correspondiente de la cuarta edición (el Capítulo 2), además de variasactualizaciones significativas. También se presenta en el Capítulo 6 una breve visión general del procesode diseño de las bases de datos. Los profesores que prefieran comenzar el curso con el modelo E-Rpueden empezar por este capítulo sin pérdida de continuidad, ya que se ha hecho todo lo posible paraevitar las dependencias con cualquier capítulo anterior salvo con el Capítulo 1.

El Capítulo 7, sobre el diseño relacional, presenta el material tratado en el Capítulo 7 de la cuartaedición, pero con un estilo nuevo y más legible. Los conceptos de diseño del modelo E-R se usan paracrear una visión general intuitiva de los aspectos del diseño relacional, adelantándose a la presentacióndel enfoque formal al diseño mediante dependencias funcionales y multivalo-radas y la normalizaciónalgorítmica. Este capítulo también incluye un apartado nuevo sobre los aspectos temporales del diseño de

bases de datos.La Parte 2 concluye con un nuevo capítulo, el Capítulo 8, que describe el diseño y el desarrollo de lasaplicaciones de bases de datos, incluidas las aplicaciones Web, los servlets, JSP, los disparadores y losaspectos de seguridad. Para atender a la creciente necesidad de proteger el software de ataques, eltratamiento de la seguridad ha aumentado significativamente respecto de la cuarta edición.

• Tratamiento completamente revisado y actualizado de las bases de datos basadas en objetos yde XML. La Parte 3 incluye un capítulo profundamente revisado sobre las bases de datos basadasen objetos que pone el énfasis en las características relaciónales de objetos de SQL y sustituye alos capítulos independientes sobre bases de datos orientadas a objetos y bases de datos relaciónales de objetos de la cuarta edición. Se ha eliminado parte del material introductorio sobre laorientación a objetos de cursos anteriores con el que los estudiantes están familiarizados, al igualque los detalles sintácticos del ahora obsoleto estándar ODMG. No obstante, se han conservado

conceptos importantes subyacentes a las bases de datos orientadas a objetos, incluyendo nuevomaterial sobre el estándar JDO para añadir persistencia a Java.

La Parte 3 incluye también un capítulo sobre el diseño y la consulta de datos XML, que se ha revisadoa fondo respecto del capítulo correspondiente de la cuarta edición. Contiene un tratamiento mejorado deXML Schema y de XQuery, tratamiento del estándar SQL/XML y más ejemplos de aplicaciones XML,incluyendo servicios Web.



Prefacio xv

• Material reorganizado sobre la minería de datos. La minería de datos y el procesamiento analítico en conexión son actualmente usos extremadamente importantes de las bases de datos — yano sólo "temas avanzados". En la Parte 5 se incluye un capítulo sobre minería y análisis de datos.

El tratamiento de los temas que no se han mencionado anteriormente, como las estructuras de alma-

cenamiento, se ha actualizado respecto de sus equivalentes de la cuarta edición, aunque su organización generalpermanezca relativamente intacta. El tratamiento de QBE en el Capítulo 5 se ha revisado, eliminando los detallessintácticos de la agregación y de las actualizaciones que no corresponden a ninguna implementación real, pero sehan conservado los conceptos fundamentales de QBE.

Organización

El texto está organizado en cinco partes principales y tres apéndices.

• Visión general (Capítulo 1). En el Capítulo 1 se proporciona una visión general de la naturaleza ypropósito de los sistemas de bases de datos. Se explica cómo se ha desarrollado el concepto de sistemade bases de datos, cuáles son las características usuales de los sistemas de bases de datos, lo queproporciona al usuario un sistema de bases de datos y cómo se comunican los sistemas de bases de datos

con los sistemas operativos. También se introduce un ejemplo de aplicación de las bases de datos: unaentidad bancaria que consta de muchas sucursales. Este ejemplo se usa a lo largo de todo el libro. Estecapítulo es de naturaleza justificativa, histórica y explicativa.

• Parte 1: Bases de datos relaciónales (Capítulos 2 a 5). El Capítulo 2 introduce el modelo relacional dedatos y trata de conceptos básicos y del álgebra relacional. Este capítulo también ofrece una breveintroducción a las restricciones de integridad. Los Capítulos 3 y 4 se centran en el más influyente de loslenguajes relaciónales orientados al usuario: SQL. Mientras que el Capítulo 3 ofrece una introducciónbásica a SQL, el Capítulo 4 describe características de SQL más avanzadas, incluido el modo deestablecer comunicación entre un lenguaje de programación y una base de datos que soporte SQL. ElCapítulo 5 trata de otros lenguajes relaciónales, incluido el cálculo relacional y QBE.

Los capítulos de esta parte describen la manipulación de los datos: consultas, actualizaciones,inserciones y eliminaciones, y dan por supuesto que se ha proporcionado un diseño de esquema. Los

aspectos del diseño de esquemas se posponen hasta la Parte 2.• Parte 2: Diseño de bases de datos (Capítulos 6 a 8). El Capítulo 6 ofrece una visión general del

proceso de diseño de las bases de datos, con el énfasis puesto en el diseño mediante el modelo de'datos entidad-relación. Este modelo ofrece una vista de alto nivel de los aspectos del diseño delas bases de datos y de los problemas que se hallan al capturar la semántica de las aplicacionesrealistas en las restricciones de un modelo de datos. La notación de los diagramas de clase UMLtambién se trata en este capítulo.

El Capítulo 7 introduce la teoría del diseño de las bases de datos relaciónales. Se tratan la teoría de lasdependencias funcionales y de la normalización, con el énfasis puesto en la motivación y la comprensiónintuitiva de cada forma normal. Este capítulo comienza con una visión general del diseño relacional y sebasa en la comprensión intuitiva de la implicación lógica de las dependencias funcionales. Esto permiteintroducir el concepto de normalización antes de haber tratado completamente la teoría de la dependenciafuncional, que se presenta más avanzado el capítulo. Los profesores pueden decidir usar únicamente este

tratamiento inicial de los Apartados 7.1 a 7.3 sin pérdida de continuidad. Los profesores que empleentodo el capítulo conseguirán que los estudiantes tengan una buena comprensión de los conceptos denormalización para justificar algunos de los conceptos más difíciles de comprender de la teoría de ladependencia funcional.

El Capítulo 8 trata del diseño y del desarrollo de las aplicaciones. Este capítulo pone énfasis en lacreación de aplicaciones de bases de datos con interfaces basadas en Web. Además, el capítulo trata de laseguridad de las aplicaciones.

• Parte 3: Bases de datos basadas en objetos y XML (Capítulos 9 y 10). El Capítulo 9 trata de lasbases de datos basadas en objetos. Este capítulo describe el modelo de datos relacional orientado



Prefacio

a objetos, que amplía el modelo de datos relacional para dar soporte a tipos de datos complejos, laherencia de tipos y la identidad de los objetos. Este capítulo también describe el acceso a las bases dedatos desde lenguajes de programación orientados a objetos.

El Capítulo 10 trata del estándar XML para la representación de datos, que está experimentando unuso creciente en el intercambio y el almacenamiento de datos complejos. Este capítulo también describe

los lenguajes de consultas para XML.

• Parte 4: Almacenamiento de datos (Capítulos 11 y 12). El Capítulo 11 trata de la estructura de disco,de archivos y del sistema de archivos. En el Capítulo 12 se presenta una gran variedad de técnicas deacceso a los datos, incluidos los índices asociativos y de árbol B+.

• Parte 5: Otros temas (Capítulos 13 a 15). El Capítulo 13 se centra en los fundamentos de los sistemasde procesamiento de transacciones, incluidas la atomicidad, la consistencia, el aislamiento y ladurabilidad de las transacciones, así como la noción de la secuencialidad.

El Capítulo 14 introduce el concepto de almacén de datos y explica la minería de datos y elprocesamiento analítico en conexión (oníine analytical processing, OLAP), incluido el soporte de OLAPy del almacenamiento de datos por SQL:1999.

El Capítulo 15 trata de los tipos de datos avanzados y de las nuevas aplicaciones, incluidos los datostemporales, los datos espaciales y geográficos, y los aspectos de la gestión de bases de datos móviles ypersonales.

• Apéndices en Internet. Aunque la mayor parte de las nuevas aplicaciones de bases de datosusan el modelo relacional o el modelo relacional orientado a objetos, los modelos de datos de redy jerárquico se siguen usando en algunas aplicaciones heredadas. Para los lectores interesadosen estos modelos de datos se ofrecen apéndices que describen los modelos de datos de red y jerárquico, en los Apéndices A y B respectivamente; los apéndices sólo se encuentran disponiblesen la dirección http://www.mhe.es/silberschatz5'. Estos apéndices sólo están disponibles en inglés.

El Apéndice C describe el diseño avanzado de bases de datos relaciónales, incluida la teoría de lasdependencias multivaloradas, las dependencias de reunión y las formas normales de proyección-reunióny de dominio-clave. Este apéndice está pensado para quienes deseen estudiar la teoría del diseño de basesde datos relaciónales con más detalle y para los profesores que deseen hacerlo en sus cursos. De nuevo,este apéndice está disponible únicamente en la página Web del libro.

La quinta edición

La producción de esta quinta edición ha estado guiada por los muchos comentarios y sugerencias que se hanrecibido relativos a ediciones anteriores, por nuestras propias observaciones al ejercer la docencia en laUniversidad de Yale, la Universidad de Lehigh y el IIT de Bombay y por nuestro análisis de las direccioneshacia las que está evolucionando la tecnología de las bases de datos.

El procedimiento básico fue reescribir el material de cada capítulo, actualizando el material antiguo,añadiendo explicaciones sobre desarrollos recientes de la tecnología de las bases de datos y mejorando lasdescripciones de los temas que los estudiantes hallaban difíciles de comprender. Al igual que en la cuartaedición, cada capítulo tiene una lista de términos de repaso que puede ayudar a los lectores a repasar los temasprincipales que se han tratado en él. La mayor parte de los capítulos también contiene al final una sección que

ofrece información sobre las herramientas de software relacionadas con el tema del capítulo. También se hanañadido ejercicios nuevos y referencias actualizadas.

Nota para los profesores

Este libro contiene material tanto básico como avanzado, que puede que no se abarque en un solo semestre. Sehan marcado varios apartados como avanzados mediante el símbolo **. Estos apartados pueden omitirse, si sedesea, sin pérdida de continuidad. Los ejercicios que son difíciles (y pueden omitirse) también están marcadosmediante el símbolo "**".

http://www.mhe.es/silberschatz5'

http://www.mhe.es/silberschatz5'



Prefacio xvn

Es posible diseñar los cursos usando varios subconjuntos de los capítulos. A continuación se esbozan variasde las posibilidades:

• Los apartados del Capítulo 4 desde el Apartado 4.6 en adelante pueden omitirse en los cursosintroductorios.

• El Capítulo 5 puede omitirse si los estudiantes no van a usar el cálculo relacional ni QBE como parte delcurso.

• Los Capítulos 9 (Bases de datos orientadas a objetos) y 10 (XML) pueden omitirse en los cursosintroductorios.

• El Capítulo 14, que trata de la minería de datos, puede usarse como material para estudio individual uomitirse en los cursos introductorios.

Cómo entrar en contacto con los autores y otros usuarios

Se ha hecho todo lo posible por eliminar del texto las erratas y errores. Pero, como en los nuevos desarrollos desoftware, probablemente queden fallos. En la página Web del libro se puede obtener una lista de erratas

actualizada. Se agradecerá que se notifique cualquier error u omisión del libro que no se encuentre en la lista deerratas actual.Nos alegrará recibir sugerencias de mejoras para el libro. También son bienvenidas las contribuciones para la

página Web del libro que puedan resultar útiles para otros lectores, como ejercicios de programación,sugerencias de proyectos, laboratorios y tutoriales en línea, y ayudas a la docencia.

El correo electrónico debe dirigirse a [email protected]. El resto de la correspondencia debe enviarse aAvi Silberschatz, Department of Computer Science, Vale University, 51 Prospect Street, P.O. Box 208285, NewHaven, CT 06520-8285, EE.UU.

También se dispone de una lista de correo mediante la cual los usuarios del libro pueden comunicarse entre sí y con los autores, y recibir actualizaciones del libro y otra información relacionada. La lista está moderada, porlo que en ella no se recibe correo basura. Se ruega seguir el enlace a la lista de correo de la página Web del libropara suscribirse.

Agradecimientos

Esta edición se ha beneficiado de los muchos y útiles comentarios que nos han proporcionado los estudiantesque han usado las cuatro ediciones anteriores. Además, muchas personas nos han escrito o hablado acerca dellibro, y nos han ofrecido sugerencias y comentarios. Aunque no podemos mencionarlos aquí a todos, damos lasgracias especialmente a los siguientes:

• A Hani Abu-Salem, Universidad DePaul; Jamel R. Alsabbagh, Universidad Grand Valley State; RamziBualuan, Universidad Notre Dame; Zhengxin Chen, Universidad de Nebraska en Omaha; Jan Chomick,Universidad SUNY Buffalo; Qin Ding, Universidad Penn State en Harrisburg; Fran-tisek Franek,Universidad McMaster; Shashi K. Gadia, Universidad Iowa State; William Hankley, Universidad KansasState; Randy M. Kaplan, Universidad Drexel; Mark Llewellyn, Universidad de Central Florida; MartyMaskarinec, Universidad Western Illinois; Yiu-Kai Dermis Ng, Universidad Brigham Young; Sunil

Prabhakar, Universidad Purdue; Stewart Shen, Universidad Oíd Dominion; Anita Whitehall, FoothillCollege; Christopher Wilson, Universidad de Oregón; Weining Zhang, Universidad de Texas en SanAntonio; todos ellos revisaron el libro y sus comentarios nos ayudaron mucho a formular esta quintaedición.

• A Anastassia Ailamaki, Sailesh Krishnamurthy, Spiros Papadimitriou y Bianca Schroeder (UniversidadCarnegie Mellon) por escribir el apéndice que describe el sistema de bases de datos PostgreSQL.

• A Hakan Jakobsson (Oracle) por el apéndice sobre el sistema de bases de datos Oracle.

• A Sriram Padmanabhan (IBM) por el apéndice que describe el sistema de bases de datos DB2 de IBM.

mailto:[email protected]

mailto:[email protected]



xviii Prefacio

• A Sameet Agarwal, José A. Blakeley, Thierry D'Hers, Gerald Hinson, Dirk Myers, Vaqar Pirzada BillRamos, Balaji Rathakrishnan, Michael Rys, Florian Waas y Michael Zwilling (todos ellos de Microsoft)por el apéndice sobre el sistema de bases de datos Microsoft SQL Server. A José Blakeley también porcoordinar y editar el Capítulo 29, y a César Galindo-Legaria, Goetz Graefe, Kalen. Delaney y ThomasCasey (todos ellos de Microsoft) por sus aportaciones a la edición anterior del capítulo sobre SQL Serverde Microsoft.

• A Chen Li y a Sharad Mehrotra por ofrecer material sobre JDBC y sobre seguridad que nos ha ayudadoa actualizar y ampliar el Capítulo 8.

• A Valentín Dinu, Goetz Graefe, Bruce Hiilyer, Chad Hogg, Nahid Rahman, Patrick Schmid, Jen Storey,Prem Thomas, Liu Zhenming y, especialmente, a N.L. Sarda por su respuesta, que nos ayudó a prepararla quinta edición.

• A Rami Khouri, Nahid Rahman y Michael Rys por su respuesta a las versiones de borrador de loscapítulos de la quinta edición.

• A Raj Ashar, Janek Bogucki, Gavin M. Bierman, Christian Breimann, Tom Chappell, Y. C. Chir.Laurens Damen, Prasanna Dhandapani, Arvind Hulgeri, Zheng Jiaping, Graham J. L. Kemp, Hae ChoonLee, Sang-Won Lee, Thanh-Duy Nguyen, D. B. Phatak, Juan Altmayer Pizzorno, Rajarshi Rakshit, GregRiccardi, N. L. Sarda, Max Smolens, Nikhil Sethi y Tim Wahls por señalar errores en la cuarta edición.

• A Marilyn Turnamian, cuya excelente ayuda como secretaría fue esencial para la finalización a tiempode esta quinta edición.

La editora fue Betsy Jones. La editora patrocinadora fue Kelly Lowery. La editora de desarrollo fue MelindaD. Bilecki. La directora del proyecto fue Peggy Selle. El director ejecutivo de mercadotecnia fue Michael Weitz.La directora de mercadotecnia fue Dawn Bercier. La ilustradora y diseñadora de la cubierta fue JoAnneSchopler. El editor de copia autónomo fue George Watson. La correctora de pruebas autónoma fue JudyGantenbein. La diseñadora fue Laurie Janssen. El indexador autónomo fue Tobiah Waldron.

Esta edición se basa en las cuatro ediciones anteriores, por lo que volvemos a dar las gracias a las muchaspersonas que nos ayudaron con las cuatro primeras ediciones, como R. B. Abhyankar, Don Ba-tory, PhilBernhard, Harán Boral, Paul Bourgeois, Phil Bohannon, Robert Brazile, Yuri Breitbart, Michael Carey, Soumen

Chakrabarti, J. Edwards, Christos Faloutsos, Homma Farian, Alan Fekete, Shashi Ga-dia, Jim Gray, LeGruenwald, Eitan M. Gurari, Ron Hitchens, Yannis Ioannidis, Hyoung-Joo Kim, Won Kim, Henry Korth (padrede Henry F.), Carol Kroll, Gary Lindstrom, Irwin Levinstein, Ling Liu, Da-ve Maier, Keith MarzuUo, FletcherMattox, Sharad Mehrotra, Jim Melton, Alberto Mendelzon, Héctor Garcia-Molina, Ami Motro, BhagirathNarahari, Añil Nigam, Cyril Orji, Meral Ozsoyoglu, Bruce Porter. Jim Peterson, K.V. Raghavan, KrithiRamamritham, Mike Reiter, Odinaldo Rodriguez, Mark Roth, Marek Rusinkiewicz, Sunita Sarawagi, N.L.Sarda, S. Seshadri, Shashi Shekhar, Amit Sheth, Nandit Soparkar. Greg Speegle, Dilys Thomas y MarianneWinslett.

Marilyn Turnamian y Nandprasad Joshi ofrecieron ayuda como secretarias para la cuarta edición y Marilyntambién preparó un primer borrador del diseño de la cubierta para la cuarta edición. Lyn Dupré editó la copia dela tercera edición y Sara Strandtman editó el texto de la tercera edición. Nilesh Dalvi, Sumit Sanghai, GauravBhalotia, Arvind Hulgeri K.V. Raghavan, Prateek Kapadia, Sara Strandtman, Greg Speegle y Dawn Bezvinerayudaron a preparar el manual para los profesores de ediciones anteriores. La nueva cubierta es una evolución

de las cuatro primeras ediciones. La idea de usar barcos como parte del concepto de la cubierta nos la sugirióinicialmente Bruce Stephan.Finalmente, Sudarshan quiere agradecer a su esposa, Sita, su amor y su apoyo, y a su hijo Madhur su amor.

Hank quiere agradecer a su mujer, Joan, y a sus hijos, Abby y Joe, su amor y su comprensión. Avi quiereagradecer a Valerie su amor, su paciencia y su apoyo durante la revisión de este libro.

A.S. H.F. K.S.S.



C A P I T U L O 1

Un sistema gestor de bases de datos (SGBD) consiste en una colección de datos interrelacionados y unconjunto de programas para acceder a dichos datos. La colección de datos, normalmente denominada base dedatos, contiene información relevante para una empresa. El objetivo principal de un SGBD es proporcionar unaforma de almacenar y recuperar la información de una base de datos de manera que sea tanto práctica comoeficiente.

Los sistemas de bases de datos se diseñan para gestionar grandes cantidades de información. La gestión de losdatos implica tanto la definición de estructuras para almacenar la información como la provisión de mecanismospara la manipulación de la información. Además, los sistemas de bases de datos deben garantizar la fiabilidad dela información almacenada, a pesar de las caídas del sistema o de los intentos de acceso no autorizados. Si losdatos van a ser compartidos entre diferentes usuarios, el sistema debe evitar posibles resultados anómalos.

Dado que la información es tan importante en la mayoría de las organizaciones, los científicos informáticoshan desarrollado una gran cuerpo de conceptos y técnicas para la gestión de los datos. Estos conceptos y técnicasconstituyen el objetivo central de este libro. En este capítulo se presenta una breve introducción a los principios

de los sistemas de bases de datos.

1.1 Aplicaciones de los sistemas de bases de datos

Las bases de datos se usan ampliamente. Algunas de sus aplicaciones representativas son:

• Banca: para información de los clientes, cuentas, préstamos y transacciones bancarias.

Líneas aéreas: para reservas e información de horarios. Las líneas aéreas fueron de las primeras en usarlas bases de datos de forma distribuida geográficamente.

Universidades: para información de los estudiantes, matrículas en las asignaturas y cursos.

Transacciones de tarjetas de crédito: para compras con tarjeta de crédito y la generación de los extractosmensuales.

• Telecomunicaciones: para guardar un registro de las llamadas realizadas, generar las facturas mensuales,mantener el saldo de las tarjetas telefónicas de prepago y para almacenar información sobre las redes decomunicaciones.

• Finanzas: para almacenar información sobre compañías tenedoras, ventas y compras de productosfinancieros, como acciones y bonos; también para almacenar datos del mercado en tiempo real parapermitir a los clientes la compraventa en línea y a la compañía la compraventa automática.

• Ventas: para información de clientes, productos y compras.

i

o

o



2 Capítulo 1 Introducción

• Comercio en línea: para los datos de ventas ya mencionados y para el seguimiento de los pedidos Web,generación de listas de recomendaciones y mantenimiento de evaluaciones de productos en línea.

• Producción: para la gestión de la cadena de proveedores y para el seguimiento de la producción deartículos en las factorías, inventarios en los almacenes y pedidos.

o Recursos humanos: para información sobre los empleados, salarios, impuestos sobre los sueldos yprestaciones sociales, y para la generación de las nóminas.

Como muestra esta lista, las bases de datos forman una parte esencial de casi todas las empresas actuales.Durante 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 interactuaban directamente con los sistemas de bases de datos, aunquesin darse cuenta interactuaban indirectamente con bases de datos — con informes impresos como los extractos delas tarjetas de crédito, o mediante agentes como los cajeros de los bancos y los agentes de reservas de las líneasaéreas. Después vinieron los cajeros automáticos y permitieron a los usuarios interactuar directamente con lasbases de datos. Las interfaces telefónicas con las computadoras (sistemas de respuesta vocal interactiva) tambiénpermitieron a los usuarios tratar directamente con las bases de datos — la persona que llamaba podía marcar unnúmero y pulsar las teclas del teléfono para introducir información o para seleccionar opciones alternativas, paraconocer las horas de llegada o salida de los vuelos, por ejemplo, o para matricularse de asignaturas en unauniversidad.

La revolución de Internet a finales de los años noventa aumentó significativamente el acceso directo delusuario a las bases de datos. Las organizaciones convirtieron muchas de sus interfaces telefónicas a las bases dedatos en interfaces Web, y dejaron disponibles en línea muchos servicios. Por ejemplo cuando se accede a unalibrería en línea y se busca en una colección de libros o de música, se está accediendo a datos almacenados enuna base de datos. Cuando se realiza un pedido en línea, el pedido se almacena en una base de datos. Cuando seaccede al sitio Web de un banco y se consultan el estado de la cuenta y los movimientos, la información serecupera del sistema de bases de datos del banco. Cuando se accede a un sitio Web, puede que se recupereinformación personal de una base de datos para seleccionar los anuncios que se deben mostrar. Más aún, losdatos sobre los accesos Web pueden almacenarse en una base de datos

Así, aunque las interfaces de usuario ocultan los detalles del acceso a las bases de datos, y la mayoría de lagente ni siquiera es consciente de que están interactuando con una base de datos, el acceso a las bases de datosforma actualmente una parte esencial de la vida de casi todas las personas.

La importancia de los sistemas de bases de datos se puede juzgar de otra forma — actualmente, los fabricantesde sistemas de bases de datos como Oracle están entre las mayores compañías de software del mundo, y lossistemas de bases de datos forman una parte importante de la línea de productos de compañías másdiversificadas como Microsoft e IBM.

1.2 Propósito de los sistemas de bases de datos

Los sistemas de bases de datos surgieron en respuesta a los primeros métodos de gestión informatizada de losdatos comerciales. A modo de ejemplo de dichos métodos, típicos de los años sesenta, considérese parte de unaentidad bancaria que, entre otros datos, guarda información sobre todos los clientes y todas las cuentas deahorro. Una manera de guardar la información en la computadora es almacenarla en archivos del sistemaoperativo. Para permitir que los usuarios manipulen la información, el sistema tiene varios programas deaplicación que gestionan los archivos, incluyendo programas para:

• Efectuar cargos o abonos en las cuentas.

• Añadir cuentas nuevas.

• Calcular el saldo de las cuentas.

• Generar los extractos mensuales.



1.2 Propósito de los sistemas de bases de datos 3

Estos programas de aplicación los han escrito programadores de sistemas en respuesta a las necesidades delbanco.

Se añaden nuevos programas de aplicación al sistema según surgen las necesidades. Por ejemplo, supóngaseque una caja de ahorros decide ofrecer cuentas corrientes. En consecuencia, se crean nuevos archivospermanentes que contienen información acerca de todas las cuentas corrientes abiertas en el banco y puede que

haya que escribir nuevos programas de aplicación para afrontar situaciones que no se dan en las cuentas deahorro, como los descubiertos. Así, con el paso del tiempo, se añaden más archivos y programas de aplicación alsistema.

Los sistemas operativos convencionales soportan este sistema de procesamiento de archivos típico. Elsistema almacena los registros permanentes en varios archivos y necesita diferentes programas de aplicaciónpara extraer y añadir a los archivos correspondientes. Antes de la aparición de los sistemas gestores de bases dedatos (SGBDs), las organizaciones normalmente almacenaban la información en sistemas de este tipo.

Guardar la información de la organización en un sistema de procesamiento de archivos tiene una serie deinconvenientes importantes:

• Redundancia e inconsistencia de los datos. Debido a que los archivos y programas de aplicación loscrean diferentes programadores en el transcurso de un largo período de tiempo, es probable que losdiversos archivos tengan estructuras diferentes y que los programas estén escritos en varios lenguajes de

programación diferentes. Además, puede que la información esté duplicada en varios lugares (archivos).Por ejemplo, la dirección y el número de teléfono de un cliente dado pueden aparecer en un archivo quecontenga registros de cuentas de ahorros y en un archivo que contenga registros de cuentas corrientes.Esta redundancia conduce a costes de almacenamiento y de acceso más elevados. Además, puede darlugar a la inconsistencia de los datos; es decir, puede que las diferentes copias de los mismos datos nocoincidan. Por ejemplo, puede que el cambio en la dirección de un cliente esté reflejado en los registrosde las cuentas de ahorro pero no en el resto del sistema.

• Dificultad en el acceso a los datos. Supóngase que uno de los empleados del banco necesita averiguarlos nombres de todos los clientes que viven en un código postal dado. El empleado pide al departamentode procesamiento de datos que genere esa lista. Debido a que esta petición no fue prevista por losdiseñadores del sistema original, no hay un programa de aplicación a mano para satisfacerla. Hay, sinembargo, 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 extraer manualmente la informaciónque necesita, o bien pedir a un programador de sistemas que escriba el programa de aplicación necesario.Ambas alternativas son obviamente insatisfac-torias. Supóngase que se escribe el programa y que, variosdías más tarde, el mismo empleado necesita reducir esa lista para que incluya únicamente a aquellosclientes que tengan una cuenta con saldo igual o superior a 10.000 €. Como se puede esperar, no existe

ningún programa que genere tal lista. De nuevo, el empleado tiene que elegir entre dos opciones, ningunade las cuales es satisfactoria.

La cuestión aquí es que los entornos de procesamiento de archivos convencionales no permitenrecuperar los datos necesarios de una forma práctica y eficiente. Hacen falta sistemas de recuperación dedatos más adecuados para el uso general.

• Aislamiento de datos. Como los datos están dispersos en varios archivos, y los archivos pueden estar endiferentes formatos, es difícil escribir nuevos programas de aplicación para recuperar los datoscorrespondientes.

• Problemas de integridad. Los valores de los datos almacenados en la base de datos deben satisfacerciertos tipos de restricciones de consistencia. Por ejemplo, el saldo de ciertos tipos de cuentas bancariasno puede nunca ser inferior a una cantidad predeterminada (por ejemplo, 25 €). Los de -sarrolladoreshacen cumplir esas restricciones en el sistema añadiendo el código correspondiente en los diversosprogramas de aplicación. Sin embargo, cuando se añaden nuevas restricciones, es difícil cambiar losprogramas para hacer que se cumplan. El problema se complica cuando las restricciones implicandiferentes elementos de datos de diferentes archivos.



Capítulo 1 Introducción

• Problemas de atomicidad. Los sistemas informáticos, como cualquier otro dispositivo mecánico oeléctrico, está sujeto a fallos. En muchas aplicaciones es crucial asegurar que, si se produce algún fallo,los datos se restauren al estado consistente que existía antes del fallo. Considérese un programa paratransferir 50 € desde la cuenta A a la B. Si se produce un fallo del sistema durante la ejecución del programa, es posible que los 50 € fueran retirados de la cuenta A pero no abonados en la cuenta B, dando

lugar a un estado inconsistente de la base de datos. Evidentemente, resulta esencial para la consistenciade la base de datos que tengan lugar tanto el abono como el cargo, o que no tenga lugar ninguno. Esdecir, la transferencia de fondos debe ser atómica — debe ocurrir en su totalidad o no ocurrir en absoluto.Resulta difícil asegurar la atomicidad en los sistemas convencionales de procesamiento de archivos.

• Anomalías en el acceso concurrente. Para aumentar el rendimiento global del sistema y obtener unarespuesta más rápida, muchos sistemas permiten que varios usuarios actualicen los datos si-multáneamente. En realidad, hoy en día, los principales sitios de comercio electrónico de Internet puedentener millones de accesos diarios de compradores a sus datos. En tales entornos es posible la interacciónde actualizaciones concurrentes y puede dar lugar a datos inconsistentes. Considérese una cuentabancaria A, que contenga 500 €. Si dos clientes retiran fondos (por ejemplo, 50 € y 100 €,

respectivamente) de la cuenta A aproximadamente al mismo tiempo, el resultado de las ejecucionesconcurrentes puede dejar la cuenta en un estado incorrecto (o inconsistente). Supóngase que los

programas que se ejecutan para cada retirada leen el saldo anterior, reducen su valor en el importe que seretira y luego escriben el resultado. Si los dos programas se ejecutan concurrentemente, pueden leer elvalor 500 €, y escribir después 450 € y 400 €, respectivamente. Dependiendo de cuál escriba el valor enúltimo lugar, la cuenta puede contener 450 € o 400 €, en lugar del valor correcto, 350 €. Para protegersecontra esta posibilidad, el sistema debe mantener alguna forma de supervisión. Pero es difícil ofrecersupervisión, ya que muchos programas de aplicación diferentes que no se han coordinado conanterioridad pueden tener acceso a los datos.

• Problemas de seguridad. No todos los usuarios de un sistema de bases de datos deben poder acceder atodos los datos. Por ejemplo, en un sistema bancario, el personal de nóminas sólo necesita ver la parte dela base de datos que contiene información acerca de los diferentes empleados del banco. No necesitantener acceso a la información acerca de las cuentas de clientes. Pero, como los programas de aplicaciónse añaden al sistema de procesamiento de datos de una forma ad hoc, es difícil hacer cumplir talesrestricciones de seguridad.

Estas dificultades, entre otras, motivaron el desarrollo de los sistemas de bases de datos. En el resto del librose examinarán los conceptos y los algoritmos que permiten que los sistemas de bases de datos resuelvan losproblemas de los sistemas de procesamiento de archivos. En general, en este libro se usa una entidad bancariacomo ejemplo de aplicación típica de procesamiento de datos que puede encontrarse en una empresa.

1.3 Visión de los datos

Un sistema de bases de datos es una colección de datos interrelacionados y un conjunto de programas quepermiten a los usuarios tener acceso a esos datos y modificarlos. Una de las principales finalidades de lossistemas de bases de datos es ofrecer a los usuarios una visión abstracta de los datos. Es decir, el sistema ocultaciertos detalles del modo en que se almacenan y mantienen los datos.

1.3.1 Abstracción de datos

Para que el sistema sea útil debe recuperar los datos eficientemente. La necesidad de eficiencia ha llevado a losdiseñadores a usar estructuras de datos complejas para la representación de los datos en la base de datos. Dadoque muchos de los usuarios de sistemas de bases de datos no tienen formación en informática, losdesarrolladores ocultan esa complejidad a los usuarios mediante varios niveles de abstracción para simplificar lainteracción de los usuarios con el sistema:



Figura 1.1 Los tres niveles de abstracción de datos.

• Nivel físico. El nivel más bajo de abstracción describe cómo se almacenan realmente los datos. El nivelfísico describe en detalle las estructuras de datos complejas de bajo nivel.

• Nivel lógico. El nivel inmediatamente superior de abstracción describe qué datos se almacenan en labase de datos y qué relaciones existen entre esos datos. El nivel lógico, por tanto, describe toda la basede datos en términos de un número pequeño de estructuras relativamente simples. Aunque laimplementación de esas estructuras simples en el nivel lógico puede involucrar estructuras complejas delnivel físico, los usuarios del nivel lógico no necesitan preocuparse de esta complejidad. Losadministradores de bases de datos, que deben decidir la información que se guarda en la base de datos,usan el nivel de abstracción lógico.

• Nivel de vistas. El nivel más elevado de abstracción sólo describe parte de la base de datos. Aunque elnivel lógico usa estructuras más simples, queda algo de complejidad debido a la variedad de informaciónalmacenada en las grandes bases de datos. Muchos usuarios del sistema de bases de datos no necesitantoda esta información; en su lugar sólo necesitan tener acceso a una parte de la base de datos. El nivel de

abstracción de vistas existe para simplificar su interacción con el sistema. El sistema puede proporcionarmuchas vistas para la misma base de datos.

La Figura 1.1 muestra la relación entre los tres niveles de abstracción.Una analogía con el concepto de tipos de datos en lenguajes de programación puede clarificar la diferencia

entre los niveles de abstracción. La mayoría de los lenguajes de programación de alto nivel soportan el conceptode tipo estructurado. Por ejemplo, en los lenguajes tipo Pascal se pueden declarar registros de la manerasiguiente:

type cliente = record id_cliente: string;nombre_cliente: string;calle_cliente: string;ciudad_cliente: string; end;

Este código define un nuevo tipo de registro denominado cliente con cuatro campos. Cada campo tiene unnombre y un tipo asociados. Una entidad bancaria puede tener varios tipos de estos registros, incluidos:

cuenta, con los campos número_cuenta y saldo.

o, con los campos nombre_empleado y sueldo.

En el nivel físico, los registros cliente, cuenta o empleado se pueden describir como bloques de posicionesconsecutivas de almacenamiento (por ejemplo, palabras o bytes). El compilador oculta este nivel

1.3 Visión de los datos




de detalle a los programadores. De manera parecida, el sistema de base de datos oculta muchos de los detalles dealmacenamiento de los niveles inferiores a los programadores de bases de datos. Los administradores de basesde datos, por otro lado, pueden ser conscientes de ciertos detalles de la organizador, física de los datos.

En el nivel lógico cada registro de este tipo se describe mediante una definición de tipo, como en elfragmento de código anterior, y también se define la relación entre estos tipos de registros. Los programadores

que usan un lenguaje de programación trabajan en este nivel de abstracción. De manera parecida, losadministradores de bases de datos suelen trabajar en este nivel de abstracción.

Finalmente, en el nivel de vistas, los usuarios de computadoras ven un conjunto de programas de aplicaciónque ocultan los detalles de los tipos de datos. De manera parecida, en el nivel de vistas se definen varias vistasde la base de datos y los usuarios de la base de datos pueden verlas. Además de ocultar los detalles del nivellógico de la base de datos, las vistas también proporcionan un mecanisme de seguridad para evitar que losusuarios tengan acceso a ciertas partes de la base de datos. Por ejemplo los cajeros de un banco sólo ven la partede la base de datos que contiene información de las cuentas de los clientes; no pueden tener acceso a lainformación referente a los sueldos de los empleados.

1.3.2 Ejemplares y esquemas

Las bases de datos van cambiando a lo largo del tiempo conforme la información se inserta y se elimina La

colección de información almacenada en la base de datos en un momento dado se denomina ejemplar de la basede datos. El diseño general de la base de datos se denomina esquema de la base de datos. Los esquemas semodifican rara vez, si es que se modifican.

El concepto de esquemas y ejemplares de las bases de datos se puede comprender por analogía con losprogramas escritos en un lenguaje de programación. El esquema de la base de datos se corresponde con lasdeclaraciones de las variables (junto con las definiciones de tipos asociadas) de los programas Cada variabletiene un valor concreto en un instante dado. Los valores de las variables de un programa en un instante dado secorresponden con un ejemplar del esquema de la base de datos.

Los sistemas de bases de datos tiene varios esquemas divididos según los niveles de abstracción. El esquemafísico describe el diseño de la base de datos en el nivel físico, mientras que el esquema lógico describe sudiseño en el nivel lógico. Las bases de datos también pueden tener varios esquemas en el nivel de vistas, a vecesdenominados subesquemas, que describen diferentes vistas de la base de datos

De éstos, el esquema lógico es con mucho el más importante en términos de su efecto sobre los programas de

aplicación, ya que los programadores crean las aplicaciones usando él esquema lógico. El esquema físico estáoculto bajo el esquema lógico, y generalmente puede modificarse fácilmente sin afectar a los programas deaplicación. Se dice que los programas de aplicación muestran independencia física respecto de los datos si nodependen del esquema físico y, por tanto, no hace falta volver a escribirlos si se modifica el esquema físico.

Se estudiarán los lenguajes para la descripción de los esquemas, después de introducir el concepto demodelos de datos en el apartado siguiente.

1.3.3 Modelos de datos

Bajo la estructura de las bases de datos se encuentra el modelo de datos: una colección de herramientasconceptuales para describir los datos, sus relaciones, su semántica y las restricciones de consistencia Losmodelos de datos ofrecen un modo de describir el diseño de las bases de datos en los niveles físicc lógico y devistas.

En este texto se van a tratar varios modelos de datos diferentes. Los modelos de datos pueden clasificarse encuatro categorías diferentes:

• Modelo relacional. El modelo relacional usa una colección de tablas para representar tanto los datoscomo sus relaciones. Cada tabla tiene varias columnas, y cada columna tiene un nombre único. Elmodelo relacional es un ejemplo de un modelo basado en registros. Los modelos basados en registros sedenominan así porque la base de datos se estructura en registros de fórmate fijo de varios tipos. Cadatabla contiene registros de un tipo dado. Cada tipo de registro define un número fijo de campos, oatributos. Las columnas de la tabla se corresponden con los atribute;



1.4 Lenguajes de bases de datos 7

del tipo de registro. El modelo de datos relacional es el modelo de datos más ampliamente usado, y unagran mayoría de sistemas de bases de datos actuales se basan en el modelo relacional. Los Capítulos 2 al7 tratan el modelo relacional en detalle.

• El modelo entidad-relación. El modelo de datos entidad-relación (E-R) se basa en una percepción del

mundo real que consiste en una colección de objetos básicos, denominados entidades, y de las relacionesentre ellos. Una entidad es una "cosa" u "objeto" del mundo real que es distinguible de otros objetos. Elmodelo entidad-relación se usa mucho en el diseño de bases de datos y en el Capítulo 6 se examinadetalladamente.

• Modelo de datos orientado a objetos. El modelo de datos orientado a objetos es otro modelo de datosque está recibiendo una atención creciente. El modelo orientado a objetos se puede considerar como unaextensión del modelo E-R con los conceptos de la encapsulación, los métodos (funciones) y la identidadde los objetos. En el Capítulo 9 se examina este modelo de datos.

• Modelo de datos semiestructurados. El modelo de datos semiestructurados permite la especificaciónde datos donde los elementos de datos individuales del mismo tipo pueden tener diferentes conjuntos deatributos. Esto lo diferencia de los modelos de datos mencionados anteriormente, en los que cadaelemento de datos de un tipo particular debe tener el mismo conjunto de atributos. El lenguaje de

marcas extensible ( XML, eXtensible Markup Language) se emplea mucho para representar datossemiestructurados. Se estudia en el Capítulo 10.

El modelo de datos de red y el modelo de datos jerárquico precedieron cronológicamente al relacional.Estos modelos estuvieron íntimamente ligados a la implementación subyacente y complicaban la tarea delmodelado de datos. En consecuencia, se usan muy poco hoy en día, excepto en el código de bases de datosantiguas que sigue estando en servicio en algunos lugares. Se describen brevemente en los Apéndices A y B paralos lectores interesados.

1.4 Lenguajes de bases de datos

Los sistemas de bases de datos proporcionan un lenguaje de definición de datos para especificar el esquema dela base de datos y un lenguaje de manipulación de datos para expresar las consultas y las modificaciones de la

base de datos. En la práctica, los lenguajes de definición y manipulación de datos no son dos lenguajesdiferentes; en cambio, simplemente forman parte de un único lenguaje de bases de datos, como puede ser el muyusado SQL.

_ 1.4.1 Lenguaje de manipulación de datos

Un lenguaje de manipulación de datos (LMD) es un lenguaje que permite a los usuarios tener acceso a losdatos organizados mediante el modelo de datos correspondiente o manipularlos. Los tipos de acceso son:

• La recuperación de la información almacenada en la base de datos.

• La inserción de información nueva en la base de datos.

• El borrado de la información de la base de datos.

• La modificación de la información almacenada en la base de datos.

Hay fundamentalmente dos tipos:

• Los LMDs procedimentales necesitan que el usuario especifique qué datos se necesitan y cómo obteneresos datos.

• Los LMDs declarativos (también conocidos como LMDs no procedimentales) necesitan que el usuarioespecifique qué datos se necesitan sin que haga falta que especifique cómo obtener esos datos.




Los LMDs declarativos suelen resultar más fáciles de aprender y de usar que los procedimentales. Sinembargo, como el usuario no tiene que especificar cómo conseguir los datos, el sistema de bases de datos tieneque determinar un medio eficiente de acceso a los datos.

Una consulta es una instrucción que solicita que se recupere información. La parte de los LMDs implicada enla recuperación de información se denomina lenguaje de consultas. Aunque técnicamente sea incorrecto, resulta

habitual usar las expresiones lenguaje de consultas y lenguaje de manipulación de datos como sinónimas.Existen varios lenguajes de consultas de bases de datos en uso, tanto comercial como experimen-talmente. El

lenguaje de consultas más ampliamente usado, SQL, se estudiará en los Capítulos 3 y 4. También se estudiaránotros lenguajes de consultas en el Capítulo 5.

Los niveles de abstracción que se trataron en el Apartado 1.3 no sólo se aplican a la definición o es-tructuración de datos, sino también a su manipulación. En el nivel físico se deben definir los algoritmos quepermitan un acceso eficiente a los datos. En los niveles superiores de abstracción se pone el énfasis en lafacilidad de uso. El objetivo es permitir que los seres humanos interactúen de manera eficiente con el sistema. Elcomponente procesador de consultas del sistema de bases de datos (que se estudia en los Capítulos 13 y 14)traduce las consultas LMD en secuencias de acciones en el nivel físico del sistema de bases de datos.

1.4.2 Lenguaje de definición de datos

Los esquemas de las bases de datos se especifican mediante un conjunto de definiciones expresadas mediante unlenguaje especial denominado lenguaje de definición de datos (LDD). El LDD también se usa para especificarmás propiedades de los datos.

La estructura de almacenamiento y los métodos de acceso usados por el sistema de bases de datos seespecifican mediante un conjunto de instrucciones en un tipo especial de LDD denominado lenguaje dealmacenamiento y definición de datos. Estas instrucciones definen los detalles de implementación de losesquemas de las bases de datos, que suelen ocultarse a los usuarios.

Los valores de los datos almacenados en la base de datos deben satisfacer ciertas restricciones deconsistencia. 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 las comprueban cadavez que se modifica la base de datos. En general, las restricciones pueden ser predicados arbitrarios relativos a labase de datos. No obstante, los predicados arbitrarios pueden resultar costosos de comprobar. Por tanto, lossistemas de bases de datos se concentran en las restricciones de integridad que pueden comprobarse con unasobrecarga mínima:

• Restricciones de dominio. Se debe asociar un dominio de valores posibles a cada atributo (por ejemplo,tipos enteros, tipos de carácter, tipos fecha/hora). La declaración de un atributo como parte de undominio concreto actúa como restricción de los valores que puede adoptar. Las res-tricciones de dominioson la forma más elemental de restricción de integridad. El sistema las comprueba fácilmente siempreque se introduce un nuevo elemento de datos en la base de datos.

• Integridad referencial. Hay casos en los que se desea asegurar que un valor que aparece en una relaciónpara un conjunto de atributos dado aparece también para un determinado conjunto de atributos en otrarelación (integridad referencial). Las modificaciones de la base de datos pueden causar violaciones de laintegridad referencial. Cuando se viola una restricción de integridad, el procedimiento normal esrechazar la acción que ha causado esa violación.

• Asertos. Un aserto es cualquier condición que la base de datos debe satisfacer siempre. Las

res-tricciones de dominio y las restricciones de integridad referencial son formas especiales de aser-tos.No obstante, hay muchas restricciones que no pueden expresarse empleando únicamente esas formasespeciales. Por ejemplo: "Cada préstamo tiene como mínimo un cliente tenedor de una cuenta con unsaldo mínimo de 1.000,00 €" debe expresarse en forma de aserto. Cuando se crea un aserto, el sistema

comprueba su validez. Si el aserto es válido, cualquier modificación futura de la base de datos se permiteúnicamente si no hace que se viole ese aserto.

• Autorización. Puede que se desee diferenciar entre los usuarios en cuanto al tipo de acceso que se lespermite a diferentes valores de los datos de la base de datos. Estas diferenciaciones se



1.5 Bases de datos relaciónales 9

expresan en términos de autorización, cuyas modalidades más frecuentes son: autorización de lectura,que permite la lectura pero no la modificación de los datos; autorización de inserción, que permite lainserción de datos nuevos, pero no la modificación de los datos ya existentes; autorización deactualización, que permite la modificación, pero no la eliminación, de los datos; y la autorización deeliminación, que permite la eliminación de datos. A cada usuario se le pueden asignar todos, ninguno o

una combinación de estos tipos de autorización.

El LDD, al igual que cualquier otro lenguaje de programación, obtiene como entrada algunas instrucciones ygenera una salida. La salida del LDD se coloca en el diccionario de datos, que contiene metadatos — es decir,datos sobre datos. El diccionario de datos se considera un tipo especial de tabla, a la que sólo puede tener accesoy actualizar el propio sistema de bases de datos (no los usuarios normales). El sistema de bases de datos consultael diccionario de datos antes de leer o modificar los datos reales.

1.5 Bases de datos relacionales

Las bases de datos relaciónales se basan en el modelo relacional y usan un conjunto de tablas para representar

tanto los datos como las relaciones entre ellos. También incluyen un LMD y un LDD. La mayor parte de lossistemas de bases de datos relaciónales comerciales emplean el lenguaje SQL, que se trata en este apartado y quese tratará con gran detalle en los Capítulos 3 y 4. En el Capítulo 5 se estudiarán otros lenguajes influyentes.

1.5.1 Tablas

Cada tabla tiene varias columnas, y cada columna tiene un nombre único. En la Figura 1.2 se presenta unejemplo de base de datos relacional consistente en tres tablas: una muestra detalles de los clientes de un banco,la segunda muestra las cuentas y la tercera muestra las cuentas que pertenecen a cada cliente.

La primera tabla, la tabla cliente, muestra, por ejemplo, que el cliente identificado por id_cliente 19.28-3.746se llama González y vive en la calle Arenal en La Granja. La segunda tabla, cuenta, muestra, por ejemplo, que la

cuenta C-101 tiene un saldo de 500 € y la C-201 un saldo de 900 €. La tercera tabla muestra las cuentas que pertenecen a cada cliente. Por ejemplo, la cuenta C-101 pertenece alcliente cuyo id_cliente 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 C-201 (pueden compartir un negocio).

El modelo relacional es un ejemplo de modelo basado en registros. Los modelos basados en registros sedenominan así porque la base de datos se estructura en registros de formato fijo de varios tipos. Cada tablacontiene registros de un tipo dado. Cada tipo de registro define un número fijo de campos, o atributos. Lascolumnas de la tabla se corresponden con los atributos del tipo de registro.

No es difícil ver cómo se pueden almacenar las tablas en archivos. Por ejemplo, se puede usar un carácterespecial (como la coma) para delimitar los diferentes atributos de un registro, y otro carácter especial (como elcarácter de nueva línea) para delimitar los registros. El modelo relacional oculta esos detalles de implementaciónde bajo nivel a los desarrolladores de bases de datos y a los usuarios.

El modelo de datos relacional es el modelo de datos más ampliamente usado, y una gran mayoría de los

sistemas de bases de datos actuales se basan en el modelo relacional. Los Capítulos 2 al 7 tratan el modelorelacional con detalle.Obsérvese también que en el modelo relacional es posible crear esquemas que tengan problemas tales como

información duplicada innecesariamente. Por ejemplo, supóngase que se almacena número_cuenta comoatributo de un registro cliente. Entonces, para representar el hecho de que tanto la cuentas C-101 como la cuentaC-201 pertenece al cliente González (con idjzliente 19.283.746) sería necesario almacenar dos filas en la tablacliente. Los valores de nombre_cliente, calle_cliente y ciudad_cliente de González estarían innecesariamenteduplicados en las dos filas. En el Capítulo 7 se estudiará el modo de distinguir los buenos diseños de esquema delos malos.




id_cliente nombre-cliente calle_cliente ciudad_cliente

19.283.746 González Arenal, 12 La Granja67.789.901 López Mayor, 3 Peguerinos18.273.609 Abril Preciados, 123 Valsaín32.112.312 Santos Mayor, 100 Peguerinos

33.666.999 Rupérez Ramblas, 175 León01.928.374 Gómez Carretas, 72 Cerceda

(a) La tabla cliente

número_cuenta saldo

C-101 500C-215 700C-102 400C-305 350C-201 900C-217 750C-222 700

(b) La tabla cuenta

Id_cliente número_cuenta

19.283.746 C-10119.283.746 C-20101.928.374 C-21567.789.901 C-10218.273.609 C-30532.112.312 C-21733.666.999 C-22201.928.374 C-201

(c) La tabla impositor

Figura 1.2 Un ejemplo de base de datos relacional.

1.5.2 Lenguaje de manipulación de datos

El lenguaje de consultas de SQL no es procedimental. Usa como entrada varias tablas (posiblemente sólo una) ydevuelve siempre una sola tabla. A continuación se ofrece un ejemplo de consulta SQL que halla el nombre detodos los clientes que residen en Peguerinos:

select cliente.nombre_cliente from cliente where cliente.ciudad_cliente = 'Peguerinos'

La consulta especifica que hay que recuperar (select) las filas de (from) la tabla cliente en las que (where laciudad_cliente es Peguerinos, y que sólo debe mostrarse el atributo nombre_cliente de esas filas. Másconcretamente, el resultado de la ejecución de esta consulta es una tabla con una sola columna denomi-nadanombre_cliente y un conjunto de filas, cada una de las cuales contiene el nombre de un cliente cuyaciudad_cliente es Peguerinos. Si la consulta se ejecuta sobre la tabla de la Figura 1.2, el resultado constará dedos filas, una con el nombre López y otra con el nombre Santos.

Las consultas pueden involucrar información de más de una tabla. Por ejemplo, la siguiente consulta buscatodos los números de cuenta y sus saldos del cliente con id_cliente 19.283.746.



1.6 Diseño de bases de datos 11

select cuenta.número_cuenta, cuenta.saldo from ímvositor, cuenta where impositor.id_cliente = '19.283.746' and

impositor.número_cuenta = cuenta.número_cuenta

Si la consulta anterior se ejecutase sobre las tablas de la Figura 1.2, el sistema encontraría que las dos cuentasdenominadas C-101 y C-201 pertenecen al cliente 19.283.746 y el resultado consistiría en una tabla con doscolumnas (número_cuenta, saldo) y dos filas (C-101,500) y (C-201,900).

1.5.3 Lenguaje de definición de datos

SQL ofrece un LDD elaborado que permite definir tablas, restricciones de integridad, asertos, etc. Porejemplo, la siguiente instrucción del lenguaje SQL define la tabla cuenta:

créate table cuenta (número_cuenta char(10),saldo integer)

La ejecución de esta instrucción LDD crea la tabla cuenta. Además, actualiza el diccionario de datos, que

contiene metadatos (1.4.2). Los esquemas de las tablas son ejemplos de metadatos.

1.5.4 Acceso a las bases de datos desde los programas de aplicación

SQL no es tan potente como la máquina universal de Turing; es decir, hay algunos cálculos que no pue-denobtenerse mediante ninguna consulta SQL. Esos cálculos deben escribirse en un lenguaje anfitrión, como Cobol,C, C++ o Java. Los programas de aplicación son programas que se usan para interactuar de esta manera con lasbases de datos. Algunos de los ejemplos de un sistema bancario serían los progra-mas que generan las nóminas,realizan cargos en las cuentas, realizan abonos en las cuentas o transfieren fondos entre las cuentas.

Para tener acceso a la base de datos, las instrucciones LMD deben ejecutarse desde el lenguaje anfitrión. Haydos maneras de conseguirlo:

• Proporcionando una interfaz de programas de aplicación (conjunto de procedimientos) que se

pueda usar para enviar instrucciones LMD y LDD a la base de datos y recuperar los resultados.El estándar de conectividad abierta de bases de datos (ODBC, Open Data Base Connectivity) definidopor Microsoft para su empleo con el lenguaje C es un estándar de interfaz de programas de aplicaciónusado habitualmente. El estándar de conectividad de Java con bases de datos (JDBC, Java Data BaseConnectivity) ofrece las características correspondientes para el lenguaje Java.

• Extendiendo la sintaxis del lenguaje anfitrión para que incorpore las llamadas LMD dentro delprograma del lenguaje anfitrión. Generalmente, un carácter especial precede a las llamadas LMDy un preprocesador, denominado precompilador LMD, convierte las instrucciones LMD en llamadas normales a procedimientos en el lenguaje anfitrión.

1.6 Diseño de bases de datos

Los sistemas de bases de datos se diseñan para gestionar grandes cantidades de información. Esas grandescantidades de información no existen aisladas. Forman parte del funcionamiento de alguna empresa, cuyoproducto final puede que sea la información obtenida de la base de datos o algún dispositivo o servicio para elque la base de datos sólo desempeña un papel secundario.

El diseño de bases de datos implica principalmente el diseño del esquema de las bases de datos. El diseño deun entorno completo de aplicaciones para la base de datos que satisfaga las necesidades de la empresa que seestá modelando exige prestar atención a un conjunto de aspectos más amplio. Este texto se centrará inicialmenteen la escritura de las consultas a la base de datos y en el diseño de los esquemas de las bases de datos. En elCapítulo 8 se estudia el proceso general de diseño de las aplicaciones.




1.6.1 Proceso de diseño

Los modelos de datos de alto nivel resultan útiles a los diseñadores de bases de datos al ofrecerles un marcoconceptual en el que especificar, de manera sistemática, los requisitos de datos de los usuarios de las bases dedatos y la manera en que se estructurará la base de datos para satisfacer esos requisitos. La fase inicial del diseño

de las bases de datos, por tanto, es caracterizar completamente los requisitos de datos de los hipotéticos usuariosde la base de datos. Los diseñadores de bases de datos deben interac-tuar ampliamente con los expertos yusuarios del dominio para llevar a cabo esta tarea. El resultado de esta fase es la especificación de los requisitosde los usuarios.

A continuación, el diseñador escoge un modelo de datos y, mediante la aplicación de los conceptos delmodelo de datos elegido, traduce esos requisitos en un esquema conceptual de la base de datos. El esquemadesarrollado en esta fase de diseño conceptual ofrece una visión general detallada de la empresa. El diseñadorrevisa el esquema para confirmar que todos los requisitos de datos se satisfacen realmente y no entran enconflicto entre sí. El diseñador también puede examinar el diseño para eliminar cualquier característicaredundante. En este punto, la atención se centra en describir los datos y sus relaciones, más que en especificarlos detalles del almacenamiento físico.

En términos del modelo relacional, el proceso de diseño conceptual implica decisiones sobre qué atributos sedesea capturar en la base de datos y cómo agruparlos para formar las diferentes tablas. La parte "qué" es,

esencialmente, una decisión conceptual, y no se seguirá estudiando en este texto. La parte del "cómo" es,esencialmente, un problema informático. Hay dos vías principales para afrontar el problema. La primera suponeusar el modelo entidad-relación (Apartado 1.6.3); la otra es emplear un conjunto de algoritmos (denominadoscolectivamente como normalización) que toma como entrada el conjunto de todos los atributos y genera unconjunto de tablas (Apartado 1.6.4).

Un esquema conceptual completamente desarrollado también indica los requisitos funcionales de la empresa.En la especificación de requisitos funcionales los usuarios describen el tipo de operaciones (o transacciones)que se llevarán a cabo con los datos. Un ejemplo de estas operaciones es modificar o actualizar los datos, buscary recuperar datos concretos y eliminar datos. En esta etapa del diseño conceptual el diseñador puede revisar elesquema para asegurarse de que satisface los requisitos funcionales.

El proceso de pasar de un modelo de datos abstracto a la implementación de la base de datos continúa condos fases de diseño finales. En la fase de diseño lógico el diseñador relaciona el esquema conceptual de altonivel con el modelo de implementación de datos del sistema de bases de datos que se va a usar. El diseñador usa

el esquema de bases de datos específico para el sistema resultante en la fase de diseño físico posterior, en la quese especifican las características físicas de la base de datos. Entre esas características están la forma deorganización de los archivos y las estructuras de almacenamiento interno; se estudian en el Capítulo 11.

1.6.2 Diseño de la base de datos para una entidad bancaria

Para ilustrar el proceso de diseño, examinemos el modo en que puede diseñarse una base de datos para unaentidad bancaria. La especificación inicial de los requisitos de los usuarios puede basarse en entrevistas con losusuarios de la base de datos y en el análisis de la entidad realizado por el propio diseñador. La descripción quesurge de esta fase de diseño sirve como base para especificar la estructura conceptual de la base de datos. Éstasson las principales características de la entidad bancaria:

• El banco está organizado en sucursales. Cada sucursal se ubica en una ciudad determinada y quedaidentificada por un nombre único. El banco supervisa los activos de cada sucursal.

• Los clientes quedan identificados por el valor de su id_cliente. El banco almacena el nombre de cadacliente y la calle y la ciudad en la que vive. Los clientes pueden abrir cuentas y solicitar préstamos. Cadacliente puede asociarse con un empleado del banco en concreto, que pued¿ actuar como prestamista ocomo asesor personal para ese cliente.

• El banco ofrece dos tipos de cuenta: de ahorro y corriente. Las cuentas pueden tener como titular a másde un cliente, y cada cliente puede abrir más de una cuenta. A cada cuenta se le asigna un número decuenta único. El banco guarda un registro del saldo de cada cuenta y de la fecha



1.6 Diseño de bases de datos 13

más reciente en que cada cliente titular de esa cuenta tuvo acceso a ella. Además, cada cuenta de ahorrotiene una tasa de interés y se registran los descubiertos de las cuentas corrientes.

• El banco ofrece préstamos a sus clientes. Cada préstamo se origina en una sucursal concreta y puedetener como titulares a uno o más clientes. Cada préstamo queda identificado por un número de préstamo

único. De cada préstamo el banco realiza un seguimiento del importe del préstamo y de sus pagos.Aunque el número de pago del préstamo no identifica de manera única un pago concreto entre todos losdel banco, el número de pago identifica cada pago concreto de un préstamo dado. Se registran la fecha yel importe de cada pago.

• Los empleados del banco quedan identificados por el valor de su id_empleado. La administración delbanco almacena el nombre y número de teléfono de cada empleado, el nombre de las personasdependientes de cada empleado y el número de id_empleado del jefe de cada empleado. El bancotambién realiza un seguimiento de la fecha de contratación y, por tanto, de la antigüedad de cadaempleado.

En las entidades bancarias reales, el banco realizaría un seguimiento de los depósitos y de los reinte-gros delas cuentas de ahorro y corrientes, igual que realiza un seguimiento de los pagos de las cuentas de crédito. Dadoque los requisitos de modelado para ese seguimiento son parecidas y nos gustaría que la aplicación de ejemplo

no tuviera un tamaño excesivo, en nuestro modelo no se realiza el seguimiento de esos depósitos y reintegros.

1.6.3 El modelo entidad-relación

El modelo de datos entidad-relación (E-R) está basado en una percepción del mundo real que consiste en unconjunto de objetos básicos, denominados entidades, y de las relaciones entre esos objetos. Una entidad es una"cosa" u "objeto" del mundo real que es distinguible de otros objetos. Por ejemplo, cada persona es una entidad,y las cuentas bancarias pueden considerarse entidades.

Las entidades se describen en las bases de datos mediante un conjunto de atributos. Por ejemplo, losatributos número_cuenta y saldo pueden describir una cuenta concreta de un banco y constituyen atributos delconjunto de entidades cuenta. Análogamente, los atributos nombre_cliente, calle_cliente y ciudad_cliente

pueden describir una entidad cliente. Se usa un atributo extra, id_cliente, para identificar unívocamente a los clientes (dado que es posible que haya

dos clientes con el mismo nombre, calle y ciudad). Se debe asignar un identificador de cliente único a cadacliente. En Estados Unidos, muchas empresas usan el número de la seguridad social de cada persona (un númeroúnico que el Gobierno de Estados Unidos asigna a cada persona) como identificador de cliente.

Una relación es una asociación entre varias entidades. Por ejemplo, la relación impositor asocia un clientecon cada cuenta que tiene. El conjunto de todas las entidades del mismo tipo, y el conjunto de todas lasrelaciones del mismo tipo se denominan, respectivamente, conjunto de entidades y conjunto de relaciones.

La estructura lógica general (esquema) de la base de datos se puede expresar gráficamente mediante undiagrama E-R, que está constituido por los siguientes componentes:

• Rectángulos, que representan conjuntos de entidades.

• Elipses, que representan atributos.

• Rombos, que representan conjuntos de relaciones entre miembros de varios conjuntos de entida-des.

• Líneas, que unen los atributos con los conjuntos de entidades entre sí, y también los conjuntos deentidades con las relaciones.

Cada componente se etiqueta con la entidad o relación que representa.Como ilustración, considérese parte de un sistema bancario de bases de datos consistente en los clien-tes y las

cuentas que tienen esos clientes. La Figura 1.3 muestra el diagrama E-R correspondiente. El



Figura 1.3 Un ejemplo de diagrama E-R.

id_cliente número_cuenta saldo

19.283.746 C-101 50019.283.746 C-201 90001.928.374 C-215 70067.789.901 C-102 40018.273.609 C-305 350

32.112.312 C-217 75033.666.999 C-222 70001.928.374 C-201 ■900

Figura 1.4 La tabla impositor'.

diagrama E-R indica que hay dos conjuntos de entidades, cliente y cuenta, con los atributos descritosanteriormente. El diagrama también muestra la relación impositor entre cliente y cuenta.

Además de entidades y relaciones, el modelo E-R representa ciertas restricciones que los contenidos de labase de datos deben cumplir. Una restricción importante es la correspondencia de cardinalidades, que expresael número de entidades con las que otra entidad se puede asociar a través de un conjunto de relaciones. Porejemplo, si cada cuenta sólo debe pertenecer a un cliente, el modelo puede expresar esa restricción.

El modelo entidad-relación se usa ampliamente en el diseño de bases de datos, y en el Capítulo 6 se exploraen detalle.

1.6.4 Normalización

Otro método de diseño de bases de datos es usar un proceso que suele denominarse normalización. El objetivo esgenerar un conjunto de esquemas de relaciones que permita almacenar información sin redundanciasinnecesarias, pero que también permita recuperar la información con facilidad. El enfoque es diseñar esquemasque se hallen en la forma normal adecuada. Para determinar si un esquema de relación se halla en una de lasformas normales deseadas, hace falta información adicional sobre la empresa real que se está modelando con labase de datos. El enfoque más frecuente es usar dependencias funcionales, que se tratan en el Apartado 7.4.

Para comprender la necesidad de la normalización, obsérvese lo que puede fallar en un mal diseño de base dedatos. Algunas de las propiedades no deseables de un mal son:

• Repetición de la información.• Imposibilidad de representar determinada información.

Se examinarán estos problemas con la ayuda de un diseño de bases de datos modificado para el ejemplobancario.

Supóngase que, en lugar de tener las dos tablas separadas cuenta e impositor, se tiene una sola tabla,impositor', que combina la información de las dos tablas (como puede verse en la Figura 1.4). Obsérvese quehay dos filas de impositor' que contienen información sobre la cuenta C-201. La repetición de información eneste diseño alternativo no es deseable. La repetición de información malgasta espacio.




1.7 Bases de datos basadas en objetos y semiestructuradas 15

id_cliente nombre-diente calle-cliente ciudad-cliente número_cuenta

19.283.746 González Arenal, 12 La Granja C-10119.283.746 González Arenal, 12 La Granja C-20167.789.901 López Mayor, 3 Peguerinos C-10218.273.609 Abril Preciados, 123 Valsaín C-305

32.112.312 Santos Mayor, 100 Peguerinos C-21733.666.999 Rupérez Ramblas, 175 León C-22201.928.374 Gómez Carretas, 72 Cerceda C-201

Figura 1.5 La tabla cliente'.

Además, complica las actualizaciones de la base de datos. Supóngase que se desea modificar el saldo de lacuenta C-201 de 900 a 950 €. Esta modificación debe reflejarse en las dos filas; compárese con el diseño

original, en el que esto daría lugar a la actualización de una sola fila. Por tanto, las actualizaciones resultan máscostosas bajo el diseño alternativo que bajo el diseño original. Cuando se lleva a cabo la actualización de la basede datos alternativa, hay que asegurarse de que todas las tupias que afectan a la cuenta C-201 se actualicen, o labase de datos mostrará dos valores de saldo diferentes para la cuenta C-201.

Examínese ahora el problema de la "imposibilidad de representar determinada información". Supóngase que,en vez de tener las dos tablas separadas cliente e impositor, se tuviera una sola tabla, cliente', que combinara lainformación de esas dos tablas (como puede verse en la Figura 1.5). No se puede re-presentar directamente lainformación relativa a los clientes (id_diente, nombre_cliente, calle_cliente, ciudad _cliente) a menos que elcliente tenga, como mínimo, una cuenta en el banco. Esto se debe a que las filas de cliente' necesitan valores denúmero_cuenta.

Una solución de este problema es introducir valores nulos. Los valores nulos indican que el valor no existe (oes desconocido). Los valores desconocidos pueden ser valores ausentes (el valor existe, pero no se tiene lainformación) o valores desconocidos (no se sabe si el valor existe realmente o no). Como se verá más adelante,los valores nulos resultan difíciles de tratar, y es preferible no recurrir a ellos. Si no se desea tratar con valoresnulos, se puede crear un elemento concreto de información del cliente sólo si el cliente tiene cuenta en el banco(obsérvese que los clientes pueden tener un préstamo pero no tener ninguna cuenta). Además, habría queeliminar esa información cuando el cliente cerrara la cuenta. Claramente, esta situación no es deseable ya que,

bajo el diseño original de la base de datos, la información de los clientes estaría disponible independientementede si el cliente tiene cuenta en el banco o no, y sin necesidad de recurrir a los valores nulos.

1.7 Bases de datos basadas en objetos y semiestructuradas

Varias áreas de aplicaciones de los sistemas de bases de datos están limitadas por las restricciones del modelo dedatos relacional. En consecuencia, los investigadores han desarrollado varios modelos de datos para tratar conestos dominios de aplicación. Los modelos de datos que se tratarán en este texto son el orientado a objetos y elrelacional orientado a objetos, representativos de los modelos de datos basados en objetos, y XML,representativo de los modelos de datos semiestructurados.

1.7.1 Modelos de datos basados en objetos

El modelo de datos orientado a objetos se basa en el paradigma de los lenguajes de programación orientados aobjetos, que actualmente se usa en gran medida. La herencia, la identidad de los objetos y la encapsulación(ocultación de la información), con métodos para ofrecer una interfaz para los objetos, están entre los conceptosprincipales de la programación orientada a objetos que han encontrado aplicación en el modelado de datos. Elmodelo de datos orientado a objetos también soporta un sistema elaborado de tipos, incluidos los tiposestructurados y las colecciones. El modelo orientado a objetos puede considerarse una extensión del modelo E-Rcon los conceptos de encapsulación, métodos (funciones) e identidad de los objetos.




El modelo de datos relacional orientado a objetos extiende el modelo relacional tradicional con granvariedad de características como los tipos estructurados y las colecciones, así como la orientación a objetos.

En el Capítulo 9 se examinan las bases de datos relacionales orientadas a objetos (es decir, las bases de datosconstruidas según el modelo relacional orientado a objetos), así como las bases de datos orientadas a objetos (esdecir, las bases de datos construidas según el modelo de datos orientado a objetos).

1.7.2 Modelos de datos semiestructurados

Los modelos de datos semiiestructurados permiten la especificación de los datos en los que cada elemento dedatos del mismo tipo puede tener conjuntos de atributos diferentes. Esto los diferencia de los modelos de datosmencionados anteriormente, en los que todos los elementos de datos de un tipo dado deben tener el mismoconjunto de atributos.

El lenguaje XML se diseñó inicialmente como un modo de añadir información de marcas a los documentosde texto, pero se ha vuelto importante debido a sus aplicaciones en el intercambio de datos. XML ofrece unmodo de representar los datos que tienen una estructura anidada y, además, permite una gran-flexibilidad en la estructuración de los datos, lo cual es importante para ciertas clases de datos no tradicionales.En el Capítulo 10 se describe el lenguaje XML, diferentes maneras de expresar las consultas sobre datosrepresentados en XML y la transformación de los datos XML de una forma a otra.

1.8 Almacenamiento de datos y consultas

Los sistemas de bases de datos están divididos en módulos que tratan con cada una de las responsabilidades delsistema general. Los componentes funcionales de los sistemas de bases de datos pueden dividirse grosso modoen los componentes gestor de almacenamiento y procesador de consultas.

El gestor de almacenamiento es importante porque las bases de datos suelen necesitar una gran can-tidad deespacio de almacenamiento. Las bases de datos corporativas tienen un tamaño que va de los centenares degigabytes hasta, para las bases de datos de mayor tamaño, los terabytes de datos. Un gigabyte sonaproximadamente 1.000 megabytes (1.000 millones de bytes), y un terabyte es aproxima-damente un millón demegabytes (1 billón de bytes). Debido a que la memoria principal de las computadoras no puede almacenar todaesta información, la información se almacena en discos. Los datos se intercambian entre los discos dealmacenamiento y la memoria principal cuando sea necesario. Como el intercambio de datos con el disco es

lento comparado con la velocidad de la unidad central de procesamiento, es fundamental que el sistema de basede datos estructure los datos para minimizar la necesidad de intercambio de datos entre los discos y la memoriaprincipal.

El procesador de consultas es importante porque ayuda al sistema de bases de datos a simplificar y facilitar elacceso a los datos. Las vistas de alto nivel ayudan a conseguir este objetivo; con ellas, los usua-rios del sistemano se ven molestados innecesariamente con los detalles físicos de la implementación del sistema. Sin embargo,el rápido procesamiento de las actualizaciones y de las consultas es importante Es función del sistema de basesde datos traducir las actualizaciones y las consultas escritas en lenguajes no procedimentales, en el nivel lógico,en una secuencia eficiente 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 almacenados en la base de datos y los programas de aplicación y las consultas remitidas al sistema. Elgestor de almacenamiento es responsable de la interacción con el gestor de archivos. Los datos en bruto sealmacenan en el disco mediante el sistema de archivos que suele proporcionar un sistema operativoconvencional. El gestor de almacenamiento traduce las diferentes instrucciones LML a comandos de bajo niveldel sistema de archivos. Así, el gestor de almacenamiento es responsable de almacenamiento, la recuperación yla actualización de los datos de la base de datos. Entre los componentes del gestor de almacenamiento seencuentran:

• Gestor de autorizaciones e integridad, que comprueba que se satisfagan las restricciones de integridady la autorización de los usuarios para tener acceso a los datos.



1.9 Gestión de transacciones 17

• Gestor de transacciones, que garantiza que la base de datos quede en un estado consistente (correcto) apesar de los fallos del sistema, y que la ejecución concurrente de transacciones transcurra si conflictos.

• Gestor de archivos, que gestiona la asignación de espacio de almacenamiento de disco y las estructurasde datos usadas para representar la información almacenada en el disco.

• Gestor de la memoria intermedia, que es responsable de traer los datos desde el disco dealmacenamiento a la memoria principal y decidir los datos a guardar en la memoria caché. El gestor de lamemoria intermedia es una parte fundamental de los sistemas de bases de datos, ya que permite que labase 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 implementa-ción físicadel sistema:

• Archivos de datos, que almacenan la base de datos en sí misma.

• Diccionario de datos, que almacena metadatos acerca de la estructura de la base de datos; en particular,su esquema.

• índices, que pueden proporcionar un acceso rápido a los elementos de datos. Como el índice de este libro

de texto, los índices de las bases de datos facilitan punteros a los elementos de datos que tienen un valorconcreto. Por ejemplo, se puede usar un índice para buscar todos los registros cuenta con unnúmero_cuenta determinado. La asociación es una alternativa a la indexación que es más rápida enalgunos casos, pero no en todos.

Se estudiarán los medios de almacenamiento, las estructuras de archivos y la gestión de la memoria intermediaen el Capítulo 11. Los métodos de acceso eficiente a los datos mediante indexación o asociación se explican enel Capítulo 12.

1.8.2 El procesador de consultas

Entre los componentes del procesador de consultas se encuentran:

• Intérprete del LDD, que interpreta las instrucciones del LDD y registra las definiciones en eldiccionario de datos.

• Compilador del LMD, que traduce las instrucciones del LMD en un lenguaje de consultas a un plan deevaluación que consiste en instrucciones de bajo nivel que entienda el motor de evalua-ción de consultas.

Las consultas se suelen poder traducir en varios planes de ejecución alternativos, todos los cualesproporcionan 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 opciones posibles.

• Motor de evaluación de consultas, que ejecuta las instrucciones de bajo nivel generadas por elcompilador del LMD.

1.9 Gestión de transacciones

A menudo, varias operaciones sobre la base de datos forman una única unidad lógica de trabajo. Un ejemplo sonlas transferencia de fondos, como se vio en el Apartado 1.2, en las que se realiza un cargo en una cuenta(llámese A) y un abono en otra cuenta (llámese B). Evidentemente, resulta fundamental que, o bien tengan lugartanto el cargo como el abono, o bien que no se produzca ninguno. Es decir, la transferencia de fondos debe tenerlugar por completo o no producirse en absoluto. Este requisito de todo o nada se denomina atomicidad.Además, resulta esencial que la ejecución de la transferencia de fondos preserve la consistencia de la base dedatos. Es decir, el valor de la suma A + B se debe




preservar. Este requisito de corrección se denomina consistencia. Finalmente, tras la ejecución correcta de latransferencia de fondos, los nuevos valores de las cuentas A y B deben persistir, a pesar de la posibilidad de fallodel sistema. Este requisito de persistencia se denomina durabilidad.

Una transacción es un conjunto de operaciones que lleva a cabo una única función lógica en una aplicaciónde bases de datos. Cada transacción es una unidad de atomicidad y consistencia. Por tanto, se exige que las

transacciones no violen ninguna restricción de consistencia de la base de datos. Es decir, si la base de datos eraconsistente cuando la transacción comenzó, debe ser consistente cuando la transacción termine con éxito. Sinembargo, durante la ejecución de una transacción, puede ser necesario permitir inconsistencias temporalmente,ya que el cargo a A o el abono a B se debe realizar en primer lugar. Esta inconsistencia temporal, aunquenecesaria, puede conducir a dificultades si ocurre un fallo.

Es responsabilidad del programador definir adecuadamente las diferentes transacciones, de tal manera quecada una preserve la consistencia de la base de datos. Por ejemplo, la transacción para transferir fondos de lacuenta A a la cuenta B puede definirse como si estuviera compuesta de dos programas diferentes: uno que realizael cargo en la cuenta A y otro que realiza el abono en la cuenta B. La ejecución de estos dos programas unodespués del otro preservará realmente la consistencia. Sin embargo, cada programa en sí mismo no transforma labase de datos de un estado consistente a otro nuevo. Por tanto, estos programas no son transacciones.

Garantizar las propiedades de atomicidad y de durabilidad es responsabilidad del propio sistema de bases dedatos — concretamente del componente de gestión de transacciones. A falta de fallos, todas las transacciones

se completan con éxito y la atomicidad se consigue fácilmente. Sin embargo, debido a diversos tipos de fallos,puede que las transacciones no siempre completen su ejecución con éxito. Si se va a asegurar la propiedad deatomicidad, las transacciones fallidas no deben tener ningún efecto sobre el estado de la base de datos. Por tanto,la base de datos debe restaurarse al estado en que estaba antes de que la transacción en cuestión comience aejecutarse. El sistema de bases de datos, por tanto, debe realizar la recuperación de fallos, es decir, detectar losfallos del sistema y restaurar la base de datos al estado que tenía antes de que ocurriera el fallo.

Finalmente, cuando varias transacciones actualizan la base de datos de manera concurrente, puede que no sepreserve la consistencia de los datos, aunque cada una de las transacciones sea correcta. Es responsabilidad delgestor de control de concurrencia controlar la interacción entre las transacciones concurrentes para garantizarla consistencia de la base de datos. Los conceptos básicos del procesamiento de transacciones se tratan en elCapítulo 13.

Puede que los sistemas de bases de datos diseñados para su empleo en computadoras personales pequeños notengan todas estas características. Por ejemplo, muchos sistemas pequeños sólo permiten que un usuario tenga

acceso a la base de datos en cada momento. Otros no ofrecen copias de seguridad ni recuperación, y dejan esastareas a los usuarios. Estas restricciones permiten un gestor de datos de menor tamaño, con menos requisitos derecursos físicos — especialmente de memoria principal. Aunque tales enfoques de bajo coste y bajas prestacionesson adecuados para bases de datos personales pequeñas, resultan inadecuados para empresas medianas ygrandes.

El concepto de transacción se ha aplicado ampliamente en los sistemas y en las aplicaciones de bases dedatos. Aunque el empleo inicial de las transacciones se produjo en las aplicaciones financieras, el concepto seusa ahora en aplicaciones de tiempo real de telecomunicaciones, así como en la gestión de las actividades delarga duración como el diseño de productos o los flujos de trabajo administrativos.

1.10 Minería y análisis de datos

El término minería de datos se refiere en líneas generales al proceso de análisis semiautomático de grandesbases de datos para descubrir patrones útiles. Al igual que el descubrimiento de conocimiento en inteligenciaartificial (también denominado aprendizaje de la máquina) o el análisis estadístico, la minería de datos intentadescubrir reglas y patrones en los datos. Sin embargo, la minería de datos se diferencia del aprendizaje de lamáquina y de la estadística en que maneja grandes volúmenes de datos, almacenados principalmente en disco.Es decir, la minería de datos trata del "descubrimiento de conocimiento en las bases de datos".

Algunos tipos de conocimiento descubiertos en las bases de datos pueden representarse mediante un conjuntode reglas. Lo que sigue es un ejemplo de regla, definida informalmente: "las mujeres jóvenes



1.11 Arquitectura de las bases de datos 19

con ingresos anuales superiores a 50.000 € son las personas con más probabilidades de comprar cochesdeportivos pequeños". Por supuesto, esas reglas no son universalmente ciertas, sino que tienen grados de"apoyo" y de "confianza". Otros tipos de conocimiento se representan mediante ecuaciones que relacionandiferentes variables, o mediante otros mecanismos para la predicción de los resultados cuando se conocen losvalores de algunas variables.

Hay gran variedad de tipos posibles de patrones que pueden resultar útiles y se emplean diferentes técnicaspara descubrir tipos de patrones diferentes. En el Capítulo 14 se estudian unos cuantos ejemplos de patrones y seve la manera en que pueden obtenerse de las bases de datos de forma automática.

Generalmente hay un componente manual en la minería de datos, que consiste en el preprocesamiento de losdatos de una manera aceptable para los algoritmos, y el postprocesamiento de los patrones descubiertos paradescubrir otros nuevos que puedan resultar útiles. Puede haber también más de un tipo de patrón que puedadescubrirse en una base de datos dada, y puede ser necesaria la interacción manual para escoger los tipos depatrones útiles. Por este motivo, la minería de datos es, en realidad, un proceso semiautomático en la vida real.No obstante, en nuestra descripción se concentra la atención en el aspecto automático de la minería.

Las empresas han comenzado a explotar la creciente cantidad de datos en línea para tomar mejo-resdecisiones sobre sus actividades, como los artículos de los que hay que tener existencias y la mejor manera dellegar a los clientes para incrementar las ventas. Muchas de sus consultas son bastante complicadas, sinembargo, y ciertos tipos de información no pueden extraerse ni siquiera usando SQL.

Se dispone de varias técnicas y herramientas para ayudar a la toma de decisiones. Varias herramientas para elanálisis de datos permiten a los analistas ver los datos de diferentes maneras. Otras herramientas de análisisrealizan cálculos previos de resúmenes de grandes cantidades de datos, con objeto de dar respuestas rápidas a laspreguntas. El estándar SQL:1999 contiene actualmente constructores adicionales para soportar el análisis dedatos.

Los datos textuales también han crecido de manera explosiva. Estos datos carecen de estructura, a diferenciade los datos rígidamente estructurados de las bases de datos relaciónales. La consulta de datos textuales noestructurados se denomina recuperación de la información. Los sistemas de recuperación de la informacióntienen mucho en común con los sistemas de bases de datos — en especial, el almacena-miento y recuperación dedatos en medios de almacenamiento secundarios. Sin embargo, el énfasis en el campo de los sistemas deinformación es diferente del de los sistemas de bases de datos, y se concentra en aspectos como las consultasbasadas en palabras clave; la relevancia de los documentos para la consulta, y el análisis, clasificación eindexación de los documentos. En el Capítulo 14 se trata la ayuda a la toma de decisiones, incluyendo el

procesamiento analítico en línea y la minería de datos.

1.11 Arquitectura de las bases de datos

Ahora es posible ofrecer una visión única (Figura 1.6) de los diversos componentes de los sistemas de bases dedatos y de las conexiones existentes entre ellos.

La arquitectura de los sistemas de bases de datos se ve muy influida por el sistema informático sub-yacentesobre el que se ejecuta el sistema de bases de datos. Los sistemas de bases de datos pueden estar centralizados oser del tipo cliente-servidor, en los que una máquina servidora ejecuta el trabajo en nom-bre de multitud demáquinas clientes. Los sistemas de bases de datos pueden diseñarse también para aprovechar las arquitecturas decomputadoras paralelas. Las bases de datos distribuidas se extienden por varias máquinas geográficamente

separadas.Hoy en día la mayor parte de los usuarios de los sistemas de bases de datos no está presente en el lugar físicoen que se encuentra el sistema de bases de datos, sino que se conectan a él a través de una red. Por tanto, sepuede diferenciar entre los sistemas clientes, en los que trabajan los usuarios remotos de la base de datos, y lossistemas servidores, en los que se ejecutan los sistemas de bases de datos.

Las aplicaciones de bases de datos suelen dividirse en dos o tres partes, como puede verse en la Fi-gura 1.7.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 servidora mediante instrucciones dellenguaje de consultas. Los estándares de interfaces de programas de aplicación como ODBC y JDBC se usanpara la interacción entre el cliente y el servidor.



Figura 1.6 Arquitectura del sistema.

En cambio, en una arquitectura de tres capas, la máquina cliente actúa simplemente como una par visibleal usuario y no contiene ninguna llamada directa a la base de datos. En vez de eso, el extremo cliente secomunica con un servidor de aplicaciones, generalmente mediante una interfaz de formularios. El servidor deaplicaciones, a su vez, se comunica con el sistema de bases de datos para tener acceso a los datos. La lógica de

negocio de la aplicación, que establece las acciones que se deben realizar según las condiciones reinantes, seincorpora en el servidor de aplicaciones, en lugar de estar distribuida entre múltiples clientes. Las aplicacionesde tres capas resultan más adecuadas para aplicaciones de gran tamaño y para las aplicaciones que se ejecutanen World Wide Web.

1.12 Usuarios y administradores de bases de datos

Uno de los objetivos principales de los sistemas de bases de datos es recuperar información de la base de datosy almacenar en ella información nueva. Las personas que trabajan con una base de datos pueden clasificarcomo usuarios o administradores de bases de datos.




1.12 Usuarios y administradores de bases de datos21

cliente

servidor

(a) Arquitectura de dos capas

(b) Arquitectura de tres capas

Figura 1.7 Arquitecturas de dos y tres capas.

1.12.1 Usuarios de bases de datos e interfaces de usuario

Hay cuatro tipos diferentes de usuarios de los sistemas de bases de datos, diferenciados por la forma en queesperan interactuar con el sistema. Se han diseñado diferentes tipos de interfaces de usuario para los diferentestipos de usuarios.

• Los usuarios normales son usuarios no sofisticados que interactúan con el sistema invocandoalguno de los programas de aplicación que se han escrito previamente. Por ejemplo, un cajero bancario que necesita transferir 50 € de la cuenta A a la cuenta B invoca un programa llamadotransferencia. Ese programa le pide al cajero el importe de dinero que se va a transferir, la cuentadesde la que se va a transferir el dinero y la cuenta a la que se va a transferir el dinero.

Como ejemplo adicional, considérese un usuario que desea averiguar el saldo de su cuenta en WorldWide Web. Ese usuario puede acceder a un formulario en el que introduce su número de cuenta. Unprograma de aplicación en el servidor Web recupera entonces el saldo de la cuenta, usando el número decuenta proporcionado, y devuelve la información al usuario.

La interfaz de usuario habitual para los usuarios normales es una interfaz de formularios, donde elusuario puede rellenar los campos correspondientes del formulario. Los usuarios normales tambiénpueden limitarse a leer informes generados por la base de datos.

o Los programadores de aplicaciones son profesionales informáticos que escriben programas deaplicación. Los programadores de aplicaciones pueden elegir entre muchas herramientas para desarrollarlas interfaces de usuario. Las herramientas de desarrollo rápido de aplicaciones (DRA) sonherramientas que permiten al programador de aplicaciones crear formularios e informes con un mínimoesfuerzo de programación.

• Los usuarios sofisticados interactúan con el sistema sin escribir programas. En su lugar, formulansus consultas en un lenguaje de consultas de bases de datos. Remiten cada una de las consultasal procesador de consultas, cuya función es dividir las instrucciones LMD en instrucciones queel gestor de almacenamiento entienda. Los analistas que remiten las consultas para explorar losdatos de la base de datos entran en esta categoría.

o Los usuarios especializados son usuarios sofisticados que escriben aplicaciones de bases de datosespecializadas que no encajan en el marco tradicional del procesamiento de datos. Entre estasaplicaciones están los sistemas de diseño asistido por computadora, los sistemas de bases deconocimientos y los sistemas expertos, los sistemas que almacenan datos con tipos de datos complejos(por ejemplo, los datos gráficos y los datos de sonido) y los sistemas de modelado del entorno. En elCapítulo 9 se estudian varias de estas aplicaciones.




1.12.2 Administrador de bases de datos

Una de las principales razones de usar SGBD es tener un control centralizado tanto de los datos como de losprogramas que tienen acceso a esos datos. La persona que tiene ese control central sobre el sistema se denominaadministrador de bases de datos (ABD). Las funciones del ABD incluyen:

• La definición del esquema. El ABD crea eí esquema original de la base de datos mediante la ejecuciónde un conjunto de instrucciones de definición de datos en el LDD.

• La definición de la estructura y del método de acceso.

• La modificación del esquema y de la organización física. El ABD realiza modificaciones en elesquema y en la organización física para reflejar las necesidades cambiantes de la organización, o paraalterar la organización física a fin de mejorar el rendimiento.

• La concesión de autorización para el acceso a los datos. Mediante la concesión de diferentes tipos deautorización, el administrador de bases de datos puede regular las partes de la base de datos a las quepuede tener acceso cada usuario. La información de autorización se guarda en una estructura especial delsistema que el SGBD consulta siempre que alguien intenta tener acceso a los datos del sistema.

• El mantenimiento rutinario. Algunos ejemplos de las actividades de mantenimiento rutinario deladministrador de la base de datos son:

D Copia de seguridad periódica de la base de datos, bien sobre cinta o sobre servidores remotos paraimpedir la pérdida de datos en caso de desastres como las inundaciones.

D Asegurarse de que se dispone de suficiente espacio libre en disco para las operaciones nor-males yaumentar el espacio en disco según sea necesario.

D Supervisar los trabajos que se ejecuten en la base de datos y asegurarse de que el rendimiento no sedegrade debido a que algún usuario haya remitido tareas muy costosas.

1.13 Historia de los sistemas de bases de datos

El procesamiento de datos impulsa el crecimiento de las computadoras, como lo ha hecho desde lo primerosdías de las computadoras comerciales. De hecho, la automatización de las tareas de procesa miento de datos

precede a las computadoras. Las tarjetas perforadas, inventadas por Hermán Hollerith se emplearon a principiosdel siglo XX para registrar los datos del censo de Estados Unidos, y se usaron sistemas mecánicos paraprocesar las tarjetas y para tabular los resultados. Las tarjetas perforadas se usaron posteriormente conprofusión como medio para introducir datos en las computadoras.

Las técnicas de almacenamiento y de procesamiento de datos han evolucionado a lo largo de los año:

• Años cincuenta y primeros años sesenta: se desarrollaron las cintas magnéticas para el alma-cenamiento de datos. Las tareas de procesamiento de datos como la elaboración de nóminas seautomatizaron, con los datos almacenados en cintas. El procesamiento de datos consistía en leerdatos de una o varias cintas y escribir datos en una nueva cinta. Los datos también se podíaintroducir desde paquetes de tarjetas perforadas e imprimirse en impresoras. Por ejemplo, losaumentos de sueldo se procesaban introduciendo los aumentos en las tarjetas perforadas y le-yendo el paquete de cintas perforadas de manera sincronizada con una cinta que contenía los

detalles principales de los salarios. Los registros debían estar en el mismo orden. Los aumentosde sueldo se añadían a los sueldos leídos de la cinta maestra y se escribían en una nueva cintaesa 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 el tamaño dedatos era mucho mayor que la memoria principal; por tanto, los programas de procesarniento de datos seveían obligados a procesar los datos en un orden determinado, leyendo mezclando datos de las cintas yde los paquetes de tarjetas perforadas.

• Finales de los años sesenta y años setenta: el empleo generalizado de los discos duros a finalde los años sesenta modificó en gran medida la situación del procesamiento de datos, ya que



1.13 Historia de los sistemas de bases de datos 23

permitieron el acceso directo a los datos. La ubicación de los datos en disco no era importante, ya que sepodía tener acceso a cualquier posición del disco en sólo unas decenas de milisegundos. Los datos seliberaron así de la tiranía de la secuencialidad. Con los discos pudieron crearse las bases de datos de redy las bases de datos jerárquicas, que permitieron que las estructuras de datos como las listas y los árbolespudieran almacenarse en disco. Los programadores pudieron crear y manipular estas estructuras de datos.

El artículo histórico de Codd [1970] definió el modelo relacional y las formas no procedimentales deconsultar los datos en el modelo relacional, y así nacieron las bases de datos relaciónales. La simplicidaddel modelo relacional y la posibilidad de ocultar completamente los detalles de implementación a losprogramadores resultaron realmente atractivas. Codd obtuvo posteriormente el prestigioso premio Turingde la ACM (Association of Computing Machinery, asociación de maquinaria informática) por su trabajo.

• Años ochenta: aunque académicamente interesante, el modelo relacional no se usó inicialmenteen la práctica debido a sus inconvenientes en cuanto a rendimiento; las bases de datos relacióna-les no podían igualar el rendimiento de las bases de datos de red y jerárquicas existentes. Estasituación cambió con System R, un proyecto innovador del centro de investigación IBM Researchque desarrolló técnicas para la construcción de un sistema de bases de datos relaciónales eficien-te. En Astrahan et al. [1976] y Chamberlin et al. [1981] se pueden encontrar excelentes visionesgenerales de System R. El prototipo de System R completamente funcional condujo al primer

producto de bases de datos relaciónales de IBM: SQL/DS. Los primeros sistemas comerciales debases de datos relaciónales, como DB2 de IBM, Oracle, Ingres y Rdb de DEC, desempeñaron unimportante papel en el desarrollo de técnicas para el procesamiento eficiente de las consultasdeclarativas. En los primeros años ochenta las bases de datos relaciónales habían llegado a sercompetitivas frente a los sistemas de bases de datos jerárquicas y de red incluso en cuanto a ren-dimiento. Las bases de datos relaciónales eran tan sencillas de usar que finalmente remplazarona las bases de datos jerárquicas y de red; los programadores que usaban esas bases de datos seveían obligados a tratar muchos detalles de implementación de bajo nivel y tenían que codificarsus consultas de forma procedimental. Lo que era aún más importante, tenían que tener presenteel rendimiento durante el diseño de los programas, lo que suponía un gran esfuerzo. En cambio,en las bases de datos relaciónales, casi todas estas tareas de bajo nivel las realiza de manera au-tomática el sistema de bases de datos, lo que libera al programador para que se centre en el nivellógico. Desde su obtención de liderazgo en los años ochenta, el modelo relacional ha reinado sin

discusión entre todos los modelos de datos.Los años ochenta también fueron testigos 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.

• Primeros años noventa: el lenguaje SQL se diseñó fundamentalmente para las aplicaciones deayuda a la toma de decisiones, que son intensivas en consultas, mientras que el objetivo prin-cipal de las bases de datos en los años ochenta eran las aplicaciones de procesamiento de tran-sacciones, que son intensivas en actualizaciones. La ayuda a la toma de decisiones y las consultasvolvieron a emerger como una importante área de aplicación para las bases de datos. El uso delas herramientas para analizar grandes cantidades de datos experimentó un gran crecimiento.

En está época muchas marcas de bases de datos introdujeron productos de bases de datos paralelas.Las diferentes marcas de bases de datos también comenzaron a añadir soporte relacional orientado aobjetos a sus bases de datos.

• Finales de los años noventa: el principal acontecimiento fue el crecimiento explosivo de WorldWide Web. Las bases de datos se implantaron mucho más ampliamente que nunca. Los sistemasde bases de datos tenían que soportar tasas de procesamiento de transacciones muy elevadas,así como una habilidad muy alta y tener disponibilidad 24 x 7 (disponibilidad 24 horas al día y7 días a la semana, lo que significa que no hay momentos de inactividad debidos a actividadesde mantenimiento planificadas). Los sistemas de bases de datos también tenían que soportarinterfaces Web para los datos.




• Principios del siglo XXI: los principios del siglo XXI han sido testigos de la emergencia de XMLy de su lenguaje de consultas asociado, XQuery, como nueva tecnología de las bases de datos.Todavía es pronto para decir el papel que XML desempeñará en las bases de datos futuras. Eneste periodo también se ha podido presenciar el crecimiento de las técnicas de "informática au-tónoma/administración automática" para la minimización del esfuerzo de administración.

1.14 Resumen

• Un sistema gestor de bases de datos (SGBD) consiste en un conjunto de datos interrelacionados y enun conjunto de programas para tener acceso a esos datos. Los datos describen una empresa concreta.

• El objetivo principal de un SGBD es proporcionar un entorno que sea tanto conveniente como eficientepara las personas que lo usan para la recuperación y almacenamiento de información.

• Los sistemas de bases de datos resultan ubicuos hoy en día, y la mayor parte de la gente interactúa,directa o indirectamente, con bases de datos muchas veces al día.

• Los sistemas de bases de datos se diseñan para almacenar grandes cantidades de información. La gestiónde los datos implica tanto la definición de estructuras para el almacenamiento de la información como la

provisión de mecanismos para la manipulación de la información. Además, los sistemas de bases dedatos deben preocuparse de la seguridad de la información almacena-da, en caso de caídas del sistema ode intentos de acceso sin autorización. Si los datos deben compartirse entre varios usuarios, el sistemadebe evitar posibles resultados anómalos.

• Uno de los propósitos principales de los sistemas de bases de datos es ofrecer a los usuarios una visiónabstracta de los datos. Es decir, el sistema oculta ciertos detalles de la manera en que los datos sealmacenan y mantienen.

• Por debajo de la estructura de la base de datos se halla el modelo de datos: un conjunto de herramientasconceptuales para describir los datos, las relaciones entre los datos, la semántica de los datos y lasrestricciones de los datos.

• Un lenguaje de manipulación de datos (LMD) es un lenguaje que permite a los usuarios tener acceso a

los datos o manipularlos. Los LMDs no procedimentales, que sólo necesitan que el usuario especifiquelos datos que necesita, sin especificar exactamente la manera de obtenerlos, se usan mucho hoy en día.

• Un lenguaje de definición de datos (LDD) es un lenguaje para la especificación del esquema de la basede datos y otras propiedades de los datos.

• El modelo de datos relacional es el más implantado para el almacenamiento de datos en las bases dedatos. Otros modelos de datos son el modelo de datos orientado a objetos, el modelo relacional orientadoa objetos y los modelos de datos semiestructurados.

• El diseño de bases de datos supone sobre todo el diseño del esquema de la base de datos. El modelo dedatos entidad-relación (E-R) es un modelo de datos muy usado para el diseño de bases de datos.Proporciona una representación gráfica conveniente para ver los datos, las relaciones y las restricciones.

• Cada sistema de bases de datos tiene varios subsistemas:

D El subsistema gestor de almacenamiento proporciona la interfaz entre los datos de bajo nivelalmacenados en la base de datos y los programas de aplicación y las consultas remitidas al sistema.

D El subsistema procesador de consultas compila y ejecuta instrucciones LDD y LMD.

• El gestor de transacciones garantiza que la base de datos permanezca en un estado consistente(correcto) a pesar de los fallos del sistema. El gestor de transacciones garantiza que la ejecuciónde las transacciones concurrentes se produzca sin conflictos.



Ejercicios 25

Las aplicaciones de bases de datos suelen dividirse en una fachada que se ejecuta en las máquinasclientes y una parte que se ejecuta en segundo plano. En las arquitecturas de dos capas la fachada secomunica directamente con una base de datos que se ejecuta en segundo plano. En las arquitecturas detres capas la parte en segundo plano se divide a su vez en un servidor de aplicaciones y un servidor debases de datos.

Los usuarios de bases de datos se pueden dividir en varias clases, y cada clase de usuario suele usar untipo diferente de interfaz para la base de datos.

Términos de repaso

• Sistema gestor de bases de datos (SGBD).

• Aplicaciones de sistemas de bases de datos.

• Sistemas de archivos.

• Inconsistencia de datos.

• Restricciones de consistencia.

• Vistas de datos.

• Abstracción de datos.

• Ejemplar de la base de datos.

• Esquema.

D Esquema de la base de datos. DEsquema físico.□ Esquema lógico.

• Independencia física de los datos.

• Modelos de datos.

□ Modelo entidad-relación.

* Modelo de datos relacional. * Modelo dedatos orientado a objetos. * Modelo de datosrelacional orientado a objetos.

• Lenguajes de bases de datos.

* Lenguaje de definición de datos. *Lenguaje de manipulación de datos. *

Lenguaje de consultas.• Diccionario de datos.

• Metadatos.

• Transacciones.

• Concurrencia.

• Programa de aplicación.

• Administrador de bases de datos (ABD).

• Máquinas cliente y servidor.

Ejercicios prácticos 1.1 En este capítulo se han descrito varias ventajas importantes de los sistemas gestores de bases de datos.

¿Cuáles son sus dos inconvenientes?

1.2 Indíquense siete lenguajes de programación que sean procedimentales y dos que no lo sean. ¿Qué grupo esmás fácil de aprender a usar? Expliquese la respuesta.

1.3 Indíquense seis pasos importantes que se deben dar para configurar una base de datos para una empresadada.

1.4 Considérese un array de enteros bidimensional de tamaño n x m que se va a usar en el lenguaje deprogramación preferido del lector. Usando el array como ejemplo, ilústrese la diferencia (a) entre los tresniveles de abstracción de datos y (b) entre el esquema y los ejemplares.

Ejercicios

1.5 Indíquense cuatro aplicaciones que se hayan usado que sea muy posible que utilicen un sistema de bases dedatos para almacenar datos persistentes.

1.6 Indíquense cuatro diferencias significativas entre un sistema de procesamiento de archivos y un SGBD.

1.7 Explíquese la diferencia entre independencia de datos física y lógica.

1.8 Indíquense cinco responsabilidades del sistema gestor de bases de datos. Para cada responsabilidad,explíquense los problemas que surgirían si no se asumiera esa responsabilidad.




1.9 Indíquense al menos dos razones para que los sistemas de bases de datos soporten la manipulación de datosmediante un lenguaje de consultas declarativo como SQL, en vez de limitarse a ofrecer una biblioteca defunciones de C o de C++ para llevar a cabo la manipulación de los datos.

1.10 Explíquense los problemas que causa el diseño de la tabla de la Figura 1.5.

1.11 ¿Cuáles son las cinco funciones principales del administrador de bases de datos?

Notas bibliográficas

A continuación se ofrece una relación de libros de propósito general, colecciones de artículos de investigación ysitios Web sobre bases de datos. Los capítulos siguientes ofrecen referencias a material sobre cada tema descritoen ese capítulo.

Codd [1970] es el artículo histórico que introdujo el modelo relacional.Entre los libros de texto que tratan los sistemas de bases de datos están Abiteboul et al. [1995], Date [2003],

Elmasri y Navathe [2003], O'Neil y O'Neil [2000], Ramakrishnan y Gehrke [2002], Garcia-Molina et al. [2001]y Ullman [1988]. El tratamiento del procesamiento de transacciones en libros de texto se puede encontrar en

Bernstein y Newcomer [1997] y Gray y Reuter [1993].Varios libros incluyen colecciones de artículos de investigación sobre la gestión de las bases de datos. Entreéstos se encuentran Bancilhon y Buneman [1990], Date [1986], Date [1990], Kim [1995], Zaniolo et al. [1997] yHellerstein y Stonebraker [2005].

Un repaso de los logros en la gestión de bases de datos y una valoración de los desafíos en la inves-tigaciónfutura aparece en Silberschatz et al. [1990], Silberschatz et al. [1996], Bernstein et al. [1998] y Abiteboul et al.[2003]. La página inicial del grupo de interés especial de la ACM en gestión de datos (www.acm.org/sigmod) ofrece gran cantidad de información sobre la investigación en bases de datos. Los sitios Web de los fabricantesde bases de datos (véase a continuación el apartado Herramientas) pro-porciona detalles acerca de susrespectivos productos.

Herramientas

Hay gran número de sistemas de bases de datos comerciales actualmente en uso. Entre los princi-pales están:DB2 de IBM (www.IBM.com/software/data), Oracle (www.oracle.com), SQL Server de Mi-crosoft(www.microsoft.com/SQL), Informix (www.informix.com) (ahora propiedad de IBM) y Sybase(www.sybase.com). Algunos de estos sistemas están disponibles gratuitamente para uso personal o nocomercial, o para desarrollo, pero no para su implantación real.

También hay una serie de sistemas de bases de datos gratuitos o de dominio público; los más usados sonMySQL (www.mySQL.com) y PostgreSQL (www.postgreSQL.org).

Una lista más completa de enlaces a sitios Web de fabricantes y a otras informaciones se encuentradisponible en la página inicial de este libro, en http://www.mhe.es/universidad/informatica/fundamentos

http://www.acm.org/sigmod

http://www.ibm.com/software/data

http://www.oracle.com/

http://www.microsoft.com/SQL

http://www.informix.com/

http://www.sybase.com/

http://www.mysql.com/

http://www.postgresql.org/

http://www.mhe.es/universidad/informatica/fundamentos

http://www.mhe.es/universidad/informatica/fundamentos

http://www.postgresql.org/

http://www.mysql.com/

http://www.sybase.com/

http://www.informix.com/

http://www.microsoft.com/SQL

http://www.oracle.com/

http://www.ibm.com/software/data

http://www.acm.org/sigmod

Download - Capitulo 1- Introducion

Top Related