1. UNIVERSIDAD FEDERICO SRNTA MARIA3 5G09 01S25 2859Introduccin a losSISTEMAS DEBASES DE DATOSPrenticeHallC .JA T E

2. V V# PROVEEDOR ESTADO CIUDAD VP v# P# CANTV1 Smith 20 Londres V1 P1 300V2 Jones 10 Pars V1 P2 200V3 Blake 30 Pars V1 P3 400V4 Clark 20 Londres V1 P4 200V5 Adams 30 Atenas V1 P5 100V1 P6 100V2 P1 300V2 P2 400p P# PARTE COLOR PESO CIUDAD V3V4P2P2200200P1 Tuerca Rojo 12 Londres V4 P4 300P2 Perno Verde 17 Pars V4 P5 400P3 Tornillo Azul 17 RomaP4 Tornillo Rojo 14 LondresP5 Leva Azul 12 ParsP6 Engrane Rojo 19 LondresLa base de datos de proveedores y partes (valores de ejemplo)v#PROVEEDOR ESTADO CIUDADV1 Smith 20 LondresV2 Jones 10 ParsV3 Blake 30 ParsV4 Clark 20 LondresV5 Adams 30 Atenasp# PARTE COLOR PESO CIUDADP1 Tuerca Rojo 12.0 LondresP2 Perno Verde 17.0 ParsP3 Tornillo Azul 17.0 RomaP4 Tornillo Rojo 14.0 LondresP5 Leva Azul 12.0 ParsP6 Engrane Rojo 19.0 LondresY# PROYECTO CIUDADY1 Clasificador ParsY2 Monitor RomaY3 OCR AtenasY4 Consola AtenasY5 RAID LondresY6 EDS OsloY7 Cinta LondresV# P# Y# CANTV1 P1 Y1 200V1 P1 Y4 700V2 P3 Y1 400V2 P3 Y2 200V2 P3 Y3 200V2 P3 Y4 500V2 P3 Y5 600V2 P3 Y6 400V2 P3 Y7 600V2 P5 Y2 100V3 P3 Y1 200V3 P4 Y2 500V4 P6 Y3 300V4 P6 Y7 300V5 P2 Y2 200V5 P2 Y4 100V5 P5 Y5 500V5 P5 Y7 100V5 P6 Y2 200V5 P1 Y4 100V5 P3 Y4 200V5 P4 Y4 800V5 P5 Y4 400V5 P6 Y4 500VPYLa base de datos proveedores, partes y proyectos (valores de ejemplo) 3. INTRODUCCIN ALOSSistemasde bases dedatosSPTIMAEDICINC. J. DateTRADUCCIN:I. Q. Sergio Luis Mara Ruiz FaudnIngeniero Qumico, Analista de SistemasSergio Kourchenko BarrenaREVISIN TCNICA:Dr. Felipe Lpez GaminoInstituto Tecnolgico Autnomo de MxicoPearsonEducacinMXICO ARGENTINA BRASIL COLOMBIA COSTA RICA CHILEESPAA GUATEMALA PER PUERTO RICO VENEZUELA 4. Datos de catalogacin bibliogrficaDATE, C. J.Introduccin a los sistemas debases de datosPEARSON EDUCACIN, Mxico, 2001ISBN: 968-444-419-2rea: UniversitariosFormato: 18.5 x 23.5 cmVersin en espaol de la obra titulada An introduction to datbase systems. Seventh Edition, de C. J. Date, publicada original-menteen ingls por Addison Wesley Longman, Inc., Reading Massachusetts. E.U.A.Esta edicin en espaol es la nica autorizada.Original English language title byAddison Wesley Longman, Inc.Copyright 2000 All rightsreserved ISBN 0-201-38590-2Edicin en espaolEditor: Jos Luis VzquezSupervisor de traduccin: Antonio Nez RamosSupervisor de produccin: Enrique Trejo HernndezEdicin en ingls:Acquisitions Editor: Maite Suarez-RivasAssociate Editor: Katherine HarutunianProduction Services: Solar Script, Inc.Composition: Publishers' Design and Production Services, Inc.Cover Design: Night & Day DesignSPTIMA EDICIN, 2001D.R. 2001 por Pearson Educacin de Mxico, S.A. de C.V.Atlacomulco Nm. 500-5 Piso Col. Industrial Atoto53519, Naucalpan de Jurez, Edo. de MxicoCmara Nacional de la Industria Editorial MexicanaReg. Nm. 1031Reservados todos los derechos. Ni la totalidad ni parte de esta publicacin pueden reproducirse, registrarse o transmitirse, porun sistema de recuperacin de informacin, en ninguna forma ni por ningn medio, sea electrnico, mecnico, fotoqumico,magntico o electroptico, por fotocopia, grabacin o cualquier otro, sin permiso previo por escrito del editor.El prstamo, alquiler o cualquier otra forma de cesin de uso de este ejemplar requerir tambin la autorizacin del editor ode sus representantes.PearsonEducacinISBN 968-444-419-2Impreso en Mxico. Printed in Mxico1 2 3 4 5 6 7 8 9 0 - 03 02 01 00Pginas: 960 5. Este libro est dedicado a mi esposa Lindyy ala memoria de mi madre Rene 6. Ac< 7. Acerca del autorC.J. Date es autor, conferencista, investigador y consultor independiente, especializado enla tecnologa de bases de datos. Reside en Healdsburg, California.En 1967, despus de varios aos como programador matemtico e instructor de pro-gramacinen Leo Computers Ltd. (Londres, Inglaterra), el seor Date se cambi a los La-boratoriosde Desarrollo de IBM (Reino Unido), donde trabaj en la integracin de lafuncionalidad de base de datos dentro de PL/I. En 1974 se traslad al Centro de Desarrollode Sistemas de IBM en California, donde fue responsable del diseo de un lenguaje debase de datos conocido como UDL (Lenguaje Unificado de Bases de Datos) y trabaj en laplaneacin tcnica, as como en el diseo externo de los productos SQL/DS y DB2 de IBM.Dej IBM en mayo de 1983.El seor Date ha estado activo en el campo de las bases de datos por ms de 30 aos.Fue uno de los primeros en reconocer la importancia del trabajo pionero de Codd sobre elmodelo relational. Ha dado muchas conferencias sobre aspectos tcnicos principalmentesobre temas de bases de datos y, en especial, sobre bases de datos relacinales en todoel territorio norteamericano y tambin en Europa, Australia, Amrica Latina y el LejanoOriente. Adems de este libro, es autor o coautor de varios otros libros sobre bases de datos,incluyendo Foundation for Object/Relational Databases: The Third Manifesto (1998), unapropuesta detallada de la direccin futura del campo; Database: A Primer (1983), queaborda los sistemas de bases de datos desde el punto de vista de un no especialista; una seriede libros: Relational Database Writings (1986, 1990, 1992, 1995, 1998), que tratan a pro-fundidadlos diversos aspectos de la tecnologa relational; y otra serie de libros sobre sistemasy lenguajes en particular: A Guide to DB2 (cuarta edicin, 1993), A Guide to SYBASE andSQL Server (1992), A Guide to SQL/DS (1988), A Guide to INGRES (1987) y A Guide tothe SQL Standard (cuarta edicin, 1997). Sus libros se han traducido a muchos idiomas, in-cluyendochino, holands, francs, alemn, griego, italiano, japons, coreano, polaco, por-tugus,ruso, espaol y Braille.El seor Date tambin ha producido ms de 300 artculos y documentos de investi-gaciny ha hecho diversas contribuciones originales a la teora de las bases de datos. Escolumnista regular de las revistas Database Programming & Design e Intelligent Enterprise.Sus seminarios profesionales sobre tecnologa de bases de datos (que ofrece tanto enNorteamrica como en el extranjero), se consideran ampliamente como los ms importantespor la calidad de los temas y la claridad en la exposicin.El seor Date posee un grado de Honor en Matemticas de la Universidad de Cam-bridge,Inglaterra (BA 1962, MA 1966) y el grado honorario de Doctor de Tecnologa de laUniversidad de Montfort, Inglaterra (1994). 8. Co1CAPTUICAPITUl 9. ContenidoPrefacio a la sptima edicin xviiPARTE I PRELIMINARESCAPTULO 1 Panorama general de la administracin de bases de datos1.1 Introduccin 21.2 Qu es un sistema de base de datos ? 51.3 Qu es una base de datos? 91.4 Por qu una base de datos? 151.5 La independencia de los datos 191.6 Los sistemas relacinales y otros sistemas 251.7 Resumen 27Ejercicios 28Referencias y Bibliografa 30Respuestas a ejercicios seleccionados 30CAPTULO 2 Arquitectura de los sistemas de bases de datos 332.1 Introduccin 332.2 Los tres niveles de la arquitectura 332.3 El nivel externo 372.4 El nivel conceptual 392.5 El nivel Interno 402.6 Transformaciones 402.7 El administrador de base de datos 412.8 El sistema de administracin de base de datos 432.9 El administrador de comunicaciones de datos 472.10 Arquitectura cliente-servidor 482.11 Utileras 502.12 El procesamiento distribuido 502.13 Resumen 54Vii 10. viii ContenidoEjercicios 55Referencias y Bibliografa 56CAPTULO 3 Una introduccin a las bases de datos relacinales3.1 Introduccin 583.2 Una mirada informal al modelo relacional 583.3 Relaciones y variables de relacin 633.4 Qu significan las relaciones 653.5 Optimizacin 673.6 El catlogo 693.7 Variables de relacin base y vistas 713.8 Transacciones 753.9 La base de datos de proveedores y partes 763.10 Resumen 78Ejercicios 80Referencias y Bibliografa 81Respuestas a ejercicios seleccionados 8258CAPTULO 4 Introduccin a SQL 834.1 Introduccin 834.2 Generalidades 844.3 El Catlogo 874.4 Vistas 884.5 Transacciones 894.6 SQL incustrado 894.7 SQL no es perfecto 984.8 Resumen 98Ejercicios 99Referencias y Bibliografa101Respuestas a ejercicios seleccionados 106PARTE II EL MODELO RELACIONAL 109CAPITULO 5 Dominios, relaciones y varrels5.1 Introduccin 111 base5.2 Dominios 1125.3 Valores de relacin 1235.4 Variables de relacin 129111 11. Contenido ix5.5 Propiedades de SQL 1345.6 Resumen 137Ejercicios 139Referencias y Bibliografa 141Respuestas a ejercicios seleccionadosCAPTULO 6 lgebra relacional 1506.1 Introduccin 1506.2 Revisin de la propiedad de cierre6.3 Sintaxis 1546.4 Semntica 1566.5 Ejemplos 1676.6 Para qu sirve el lgebra? 1696.7 Operadores adicionales 1716.8 Agrupamiento y desagrupamiento6.9 Comparaciones relacinales 1826.10 Resumen 184144152179Ejercicios 184Referencias y Bibliografa 187Respuestas a ejercicios seleccionados 190CAPTULO 7 Clculo relacional 1987.1 Introduccin 1987.2 Clculo de tupias 2007.3 Ejemplos 2087.4 El clculo frente al lgebra 2107.5 Posibilidades computacionales 2157.6 Clculo de dominios 2167.7 Propiedades de SQL 2187.8 Resumen 228Ejercicios 229Referencias y Bibliografa 231Respuestas a ejercicios seleccionados 233CAPTULO 8 Integridad 2498.1 Introduccin 2498.2 Restricciones de tipo 2518.3 Restricciones de atributo 2528.4 Restricciones de varrel 253 12. xii Contenido14.3 Recuperacin de transacciones 45714.4 Recuperacin del sistema 46014.5 Recuperacin del medio 46214.6 Confirmacin de dos fases 46214.7 Propiedades de SQL 46414.8 Resumen 465Ejercicios 466Referencias y Bibliografa 466Respuestas a ejercicios seleccionados 471CAPTULO 15 Concurrencia 47315.1 Introduccin 47315.2 Tres problemas de concurrencia 47415.3 Bloqueo 47715.4 Otra vez los tres problemas de concurrencia15.5 Bloqueo mortal 48115.6 Seriabilidad 48215.7 Niveles de aislamiento 48415.8 Bloqueo por aproximacin 48615.9 Propiedades de SQL 48815.10 Resumen 490Ejercicios 491Referencias y Bibliografa 493Respuestas a ejercicios seleccionados 499478PARTE V TEMAS ADICIONALES 503CAPTULO 16 Seguridad 50416.1 Introduccin 50416.2 Control de acceso discrecional 50616.3 Control de acceso obligatorio 51216.4 Bases de datos estadsticas 51516.5 Cifrado de datos 52016.6 Propiedades de SQL 52516.7 Resumen 528Ejercicios 529Referencias y Bibliografa 530Respuestas a ejercicios seleccionados 532 13. CAPTULO 17 Optimizacin 53717.1 Introduccin 53717.2 Un ejemplo motivador 53917.3 Un panorama general del procesamiento de consultas 54017.4 Transformacin de expresiones 54417.5 Estadsticas de la base de datos 55017.6 Una estrategia de divide y vencers 55117.7 Implementacin de los operadores relacinales 55417.8 Resumen 560Ejercicios 561Referencias y Bibliografa 564Respuestas a ejercicios seleccionados 582CAPTULO 18 Informacin faltante 58418.1 Introduccin 58418.2 Un panorama general de la lgica 3VL 58518.3 Algunas consecuencias del esquema anterior 59118.4 Los nulos y las claves 59518.5 La junta externa (una observacin) 59718.6 Valores especiales 60018.7 Propiedades de SQL 60118.8 Resumen 604Ejercicios 606Referencias y Bibliografa 608Respuestas a ejercicios seleccionados 611CAPTULO 19 Herencia de tipo 61319.1 Introduccin 61319.2 Jerarquas de tipos 61719.3 El polimorfismo y la sustituibilidad 62019.4 Variables y asignaciones 62419.5 Especializacin por restriccin 62819.6 Comparaciones 63019.7 Operadores, versiones y signaturas 63519.8 Un crculo es una elipse? 63919.9 Revisin de la especializacin por restriccin 64319.10 Resumen 645Ejercicios 646Referencias y Bibliografa 648Respuestas a ejercicios seleccionados 649Contenido xiii 14. ContenidoCAPTULO 20 Bases de datos distribuidas 65120.1 Introduccin 65120.2 Algunos puntos preliminares 65120.3 Los doce objetivos 65620.4 Problemas de los sistemas distribuidos20.5 Sistemas cliente-servidor 67520.6 Independencia de DBMS 67820.7 Propiedades de SQL 68320.8 Resumen 684Ejercicios 685Referencias y Bibliografa 686664CAPTULO 21 Apoyo para la toma de decisiones 69421.1 Introduccin 69421.2 Aspectos del apoyo para la toma de decisiones 69521.3 Diseo de bases de datos de apoyo para la toma de decisiones21.4 Preparacin de los datos 70621.5 data warehouses y data marts 70921.6 Procesamiento analtico en lnea 71521.7 Minera de datos 72221.8 Resumen 724Ejercicios 725Referencias y Bibliografa 726Respuestas a ejercicios seleccionados 729697CAPTULO 22 Bases de datos temporales 73022.1 Introduccin 73022.2 Datos temporales 73122.3 Cul es el problema? 73622.4 Intervalos 74222.5 Tipos de intervalo 74422.6 Operadores escalares sobre intervalos 74622.7 Operadores de totales sobre intervalos 74722.8 Operadores relacinales que involucran intervalos22.9 Restricciones que involucran intervalos 75422.10 Operadores de actualizacin que involucran intervalos22.11 Consideraciones de diseo de bases de datos 75922.12 Resumen 762Ejercicios 763748757 15. Contenido xvReferencias y Bibliografa 764 Respuestasa ejercicios seleccionados 766CAPTULO 23 Bases de datos basadas en la lgica 76923.1 Introduccin 76923.2 Panorama general 76923.3 Clculo proposicional 77223.4 Clculo de predicados 77723.5 Las bases de datos desde la perspectiva de la teora de demostraciones 78423.6 Sistemas de bases de datos deductivas 78723.7 Procesamiento de consultas recursivas 79323.8 Resumen 798Ejercicios 801Referencias y Bibliografa 802Respuestas a ejercicios seleccionados 808PARTE VI BASES DE DATOS DE OBJETOSY DE OBJETOS/RELACINALES 811CAPTULO 24 Bases de datos de objetos 81224.1 Introduccin 81224.2 Objetos, clases, mtodos y mensajes 81624.3 Una mirada ms cercana 82124.4 Un ejemplo de inicio a fin 82924.5 Aspectos varios 83924.6 Resumen 847Ejercicios 850Referencias y Bibliografa 851Respuestas a ejercicios seleccionados 859CAPTULO 25 Bases de datos de objetos/relacinales 86225.1 Introduccin 86225.2 El primer gran error garrafal 86525.3 El segundo gran error garrafal 87225.4 Cuestiones de implementacin 87525.5 Beneficios de un acercamiento verdadero 87725.6 Resumen 879Referencias y Bibliografa 880 16. ContenidoAPNDICES 887APNDICE A Expresiones SQL 888A.l Introduccin 888A.2 Expresiones de tabla 888A.3 Expresiones condicionalesA.4 Expresiones escalares 898894APNDICE B Una panormica de SQL3 900B.l Introduccin 900B.2 Nuevos t ipos de datos 901B.3 Herencia de tipo 906B.4 Tipos de referencia 907B.5 Subtablas y supertablas 910B.6 Otras caractersticas 912APNDICE c Abreviaturas, acronimos y smbolos 916Indice 921 17. Prefacio a la sptima edicinEste libro es una amplia introduccin al ahora muy extendido campo de los sistemas de basesde datos. Proporciona una base slida en los fundamentos de las tecnologas de bases de datosy ofrece cierta idea sobre cmo podra desarrollarse este campo en el futuro. El libro est con-cebidoprincipalmente como un libro de texto, no como una referencia de trabajo (aunque creoque tambin puede ser til, hasta cierto grado, como referencia); a todo lo largo del mismo, sehace nfasis en la profundidad y en la comprensin, no slo en los formalismos.PRERREQUISITOSEl libro en su conjunto est destinado para todo aquel que est de alguna forma interesado pro-fesionalmentey que desee comprender de qu se tratan los sistemas de bases de datos. Doy porhecho que usted tiene por lo menos un conocimiento bsico de: Las posibilidades de almacenamiento y administracin de archivos (indexacin, etctera)de un sistema moderno de computadora; Las caractersticas de uno o ms lenguajes de programacin de alto nivel (por ejemplo, C,Java, Pascal, PL/I, etctera).ESTRUCTURAEl libro est dividido en seis partes principales:I. PreliminaresII. El modelo relacionalIII. Diseo de bases de datosIV. Administracin de transaccionesV. Temas adicionalesVI. Bases de datos de objetos y de objetos/relacinalesCada parte est dividida a su vez en diversos captulos:xvii 18. xviii Prefacio a la sptima edicin La parte I (cuatro captulos) ofrece una amplia introduccin al concepto de los sistemas debases de datos en general y a los sistemas relacinales en particular. Tambin presenta ellenguaje estndar de base de datos, SQL. La parte II (cinco captulos) consiste en una descripcin detallada y muy cuidadosa delmodelo relacional, que no solamente es el fundamento terico subyacente de los sistemasrelacinales sino que de hecho es el fundamento terico del campo de las bases de datos ensu conjunto. La parte III (cuatro captulos) expone la cuestin general del diseo de bases de datos; trescaptulos estn dedicados a la teora del diseo, el cuarto considera el modelado de lasemntica y el modelo entidad/vnculo. La parte IV (dos captulos) se refiere a la administracin de transacciones (es decir, loscontroles de recuperacin y concurrencia). La parte V (ocho captulos) es un poco como un popurr. Sin embargo, muestra en generalque los conceptos relacionales son relevantes para una variedad de aspectos adicionales dela tecnologa de bases de datos seguridad, bases de datos distribuidas, datos temporales, apoyo a la toma de decisiones, etctera. Por ltimo, la parte VI (dos captulos) describe el impacto de la tecnologa de objetos enlos sistemas de bases de datos. En particular, el captulo 25 el ltimo del libro considera la posibilidad de una aproximacin entre las tecnologas de objetos y relacional y expone sistemas de objetos/relacinales.Tambin hay tres apndices: uno que ofrece detalles adicionales de SQL, otro sobre"SQL3" (una nueva versin de SQL que probablemente para cuando este libro est impreso, yahaya sido ratificada como estndar) y un tercero que presenta una lista de abreviaturas y acr-nimosimportantes.Nota: Tambin est disponible un manual en lnea del instructor (en ingls), que ofrece unagua sobre cmo utilizar este libro como base de un curso de enseanza sobre bases de datos.Consta de una serie de notas, consejos y sugerencias sobre cada parte, captulo y apndice, ascomo las respuestas a los ejercicios que no estn incluidas en el propio libro y otros materialesde apoyo. Para instrucciones sobre cmo acceder al manual, enve un mensaje de correo elec-trnicoa la siguiente direccin: luis.vazquez@pearsoned.com.COMO LEER ESTE LIBROEn general, el libro est destinado para ser ledo bsicamente siguiendo la secuencia en la quefue escrito, aunque si usted lo prefiere, puede saltarse los ltimos captulos o las ltimas sec-cionesdentro de los captulos. Un plan sugerido para una primera lectura sera: Leer los captulos 1 y 2 "a la ligera"; Leer los captulos 3 y 4 muy detenidamente; Leer los captulos 5, 6, 8 y 9 con detenimiento, pero saltando el captulo 7 (excepto la seccin 7.7); Leer el captulo 10 "a la ligera"; Leer los captulos 11 y 13 detenidamente, saltando el captulo 12; Leer los captulos 14 y 15 detenidamente; Leer los captulos subsiguientes de manera selectiva, de acuerdo con su gusto e intereses. 19. Prefacio a la sptima edicin xixCada captulo inicia con una introduccin y termina con un resumen; adems, la mayorade los captulos incluyen un conjunto de ejercicios, con sus respectivas respuestas en la mayo-rade los casos (a menudo las respuestas dan informacin adicional sobre el tema del ejercicio).La mayora de los captulos tambin incluyen una amplia lista de referencias bibliogrficas, muchasde ellas comentadas. Esta estructura permite tratar los temas por importancia, presentando losconceptos y resultados ms importantes dentro del cuerpo principal del texto y dejando variospuntos suplementarios y aspectos ms complejos para las secciones de ejercicios, respuestas oreferencias, segn corresponda. Nota: Las referencias se identifican mediante dos nmeros entrecorchetes. Por ejemplo, la referencia "[3.1]" indica el primer elemento de la lista de referenciasal final del captulo 3; o sea, un documento de E. F. Codd publicado en CACM, Vol. 25 Nm. 2,en febrero de 1982 (consulte el apndice C para una explicacin de las abreviaturas comoCACM empleadas en las referencias).COMPARACIN CON EDICIONES ANTERIORESA continuacin describimos las diferencias principales entre esta edicin y su predecesora in-mediata. Parte I: Los captulos 1 a 3 cubren ms o menos el mismo terreno que sus correspondientesen la edicin anterior, aunque fueron reescritos mejorando y ampliando el tratamiento de varios temas. El captulo 4 es nuevo (aunque est basado parcialmente en el anterior captulo8); y ofrece una introduccin a SQL, abordando aspectos que no pertenecen de manera lgica a ninguna otra parte del libro (en particular, los enlaces del lenguaje anfitrin y el SQLincrustado). Parte II: Los captulos 5 al 9 (sobre el modelo relacional) representan una versin reescrita,considerablemente ampliada y muy mejorada de los captulos 4 al 7 y 17 de la edicin anterior. En particular, las secciones sobre tipos (dominios), valores contra variables derelacin, integridad, predicados y vistas fueron revisadas de manera drstica.Nota: Cabe aqu un comentario. Las ediciones anteriores utilizaban SQL para ilustrarideas relacinales, en la creencia de que es ms fcil mostrar al estudiante lo concreto antesque lo abstracto. Sin embargo, por desgracia la brecha entre SQL y el modelo relacional hacrecido tanto que ahora creo que sera francamente engaoso usar SQL para dicho fin. Dehecho, SQL en su forma actual est muy lejos de ser una verdadera representacin de losprincipios relacinales presenta demasiadas faltas tanto de accin como de omisinque habra preferido relegarlo a un apndice; pero el lenguaje es tan importante desde elpunto de vista comercial (y todo profesional de base de datos necesita tener una cierta fa-miliaridadcon l) que no sera apropiado tratarlo de manera tan discriminatoria. Por lotanto, establec un acuerdo: un captulo en la parte I del libro y en secciones de otros cap-tulos(segn corresponda) que describen aquellos aspectos de SQL que son especficos parael tema del captulo en cuestin. Parte III: Los captulos 10 al 13 son una importante revisin de los captulos 9 al 12 anteriores, con material nuevo sobre los atributos valuados por relacin, la desnormalizacin,el diseo ortogonal y los enfoques alternos al modelado semntico (incluyendo las "reglasdel negocio").Nota: Una vez ms, vale la pena profundizar un poco aqu. Algunos revisores de edi-cionesanteriores se quejaron de que los aspectos de diseo de base de datos fueron trata- 20. xx Prefacio a la sptima edicindos ya avanzado el libro. Pero mi idea personal es que los estudiantes no estn listos paradisear bases de datos en forma adecuada ni para apreciar totalmente los aspectos de diseohasta que hayan entendido lo que son las bases de datos y cmo se usan; en otras palabras,creo que es importante dedicar algn tiempo al modelo relacional y aspectos afines, antesde exponer al estudiante a las cuestiones de diseo. Por lo tanto, sigo creyendo que la parteIII est en la posicin correcta dentro del libro. Parte IV: Los dos captulos de esta parte son versiones ligeramente revisadas y ampliadasde los captulos 13 y 14 de la edicin anterior. Parte V: Los captulos 19 (sobre la herencia de tipos), 21 (sobre el apoyo a la toma de decisiones) y 22 (sobre las bases de datos temporales), son completamente nuevos. Los captulos 16 (sobre la seguridad), 17 (sobre la optimizacin), 18 (sobre la informacin faltante)y 20 (sobre las bases de datos distribuidas) son versiones revisadas y ampliadas de maneraimportante de los captulos anteriores 15, 18, 20 y 21, respectivamente. El captulo 23(sobre las bases de datos basadas en la lgica o deductivas) es una versin revisada delapndice C anterior. Parte VI: El captulo 24 es una versin totalmente revisada y muy mejorada de los captulos 22 al 24 anteriores. El captulo 25 es nuevo en su mayora.Por ltimo, el apndice A est basado en parte del antiguo captulo 8, el apndice B es nuevo yel apndice C es una versin actualizada del apndice D anterior.Adems de los cambios sealados arriba, en esta edicin se incluyeron los temas siguientes: Estructuras de almacenamiento y mtodos de acceso (apndice A anterior); Exposicin detallada de DB2 (apndice B anterior).QU HACE A ESTE LIBRO DIFERENTE?Todo libro de base de datos en el mercado tiene sus propias fortalezas y debilidades, y todo es-critortiene sus propios intereses personales. Uno se concentra en los aspectos de administracin;otro subraya el modelado entidad/vnculo; un tercero ve todo a travs de un lente de SQL; otroms toma un punto de vista de "objeto" puro; otro ve el campo exclusivamente desde el puntode vista de los productos comerciales; y as sucesivamente. Y por supuesto, yo no soy la excep-cina esa regla; tambin tengo un inters personal: que podra llamar el inters por los funda-mentos.Yo creo firmemente que debemos tener las bases adecuadas y comprenderlas bien, antesde intentar cualquier tipo de construccin sobre ellos. Esta creencia de mi parte explica el grannfasis que pone este libro en el modelo relacional. En particular, esto explica lo extenso de laparte II la parte ms importante del libro donde presento mi propia percepcin del modelorelacional, tan detenidamente como puedo. Estoy interesado en los fundamentos, no en lasnovedades y modas.En este nimo, debo decir que me doy cuenta perfectamente de que el tono general de estelibro ha cambiado a travs de los aos. Las primeras ediciones fueron en su mayora de natu-ralezadescriptiva: describan el campo como en realidad era en la prctica, "con todo y defec-tos".En contraste, esta edicin es mucho ms prescriptiva; habla de la forma en que debera serel campo y en la que deber desarrollarse en el futuro, si hacemos bien las cosas (en otras pa-labras,ste es un libro de texto con un sentido! Y lo primero de "hacer bien las cosas" significa 21. Prefacio a la sptima edicin xxien realidad educarse a uno mismo en lo que son las cosas correctas. Espero que esta edicinpueda ayudar en ese esfuerzo.Y otro punto: algunos de ustedes tal vez sepan que, junto con mi colega Hugh Darwen,publiqu recientemente otro libro "prescriptivo" sobre la tecnologa de base de datos, cuyo t-tulo(abreviado) es The Third Manifesto [3.3]. Ese libro se basa en el modelo relacional para ofre-ceruna propuesta tcnica detallada para los futuros sistemas de base de datos (es el resultado demuchos aos de enseanza y reflexin acerca de dichos aspectos, tanto por parte de Hugh comode la ma propia). Y sin que sea una sorpresa, las ideas del Manifesto anuncian el presente libroa todo lo largo. Lo cual no quiere decir que el Manifesto sea un prerrequisito para este libro; nole es, aunque s es relevante de manera directa para gran parte de ste, y en l puede encontrarinformacin adicional pertinente.UN ULTIMO COMENTARIOQuisiera cerrar estas notas introductorias con el siguiente extracto de otro prefacio; el del mismoBertrand Russell a The Bertrand Russell Dictionary of Mind, Mater and Morals (ed., Lester E.Dennon), Citadel Press, 1993, reproducido aqu con autorizacin:Se me ha acusado de tener el hbito de cambiar de opinin... De ninguna manera meavergenzo [de ese hbito]. Qu fsico que estuviera activo en 1900 soara con jactarsede que sus opiniones no han cambiado durante el ltimo medio siglo?... [La] clase de fi-losofaque valoro y me he esforzado por perseguir es cientfica, en el sentido de que existecierto conocimiento definido por alcanzar y que esos nuevos descubrimientos pueden hacerinevitable la admisin de un error previo a cualquier mente candida. Por lo que he dicho,antes o despus, yo no proclamo el tipo de verdad con la que los telogos proclaman suscredos. Slo afirmo, en el mejor de los casos, que la opinin expresada era una opinin sen-siblea sostener en ese momento... Me sorprendera mucho si la investigacin posterior nomostrara que era necesario que fuera modificada. [Dichas opiniones no fueron] emitidascomo pronunciamientos pontificios, sino como lo mejor que pude hacer en el momentopor la promocin de un pensamiento claro y preciso. La claridad ha sido mi objetivo porencima de todo.Si compara las primeras ediciones de mi libro con esta sptima edicin, encontrar que yotambin he cambiado de opinin en muchos aspectos (y sin duda seguir hacindolo). Esperoque usted acepte los comentarios arriba citados como una justificacin adecuada para este es-tadode las cosas. Comparto la percepcin de Bertrand Russell en relacin con el campo de lainvestigacin cientfica, pero l expresa esa percepcin con mucha ms elocuencia de lo que yopodra hacerlo.RECONOCIMIENTOSUna vez ms, es un placer reconocer mi deuda con las muchas personas que participaron, enforma directa o indirecta, en la produccin de este libro. En primer lugar, debo agradecer a misamigos David McGovern y Hugh Darwen por su importante colaboracin en esta edicin:David aport el primer borrador del captulo 21 sobre el apoyo para la toma de decisiones, yHugh contribuy con el primer borrador del captulo 22 sobre bases de datos temporales. Hugh 22. xxii Prefacio a la sptima edicinrealiz tambin un minucioso trabajo de revisin en gran parte del manuscrito, incluyendo enparticular todos los captulos del tema relacional y el apndice sobre SQL3. En segundo lugar.el texto se benefici con los comentarios de muchos estudiantes de los seminarios que he venidimpartiendo durante los ltimos aos. Tambin se benefici en gran medida de los comentario ydiscusiones con diversos amigos y revisores, incluyendo a Charley Bontempo, Declan Brady.Hugh Darwen (de nuevo), Tim Hartley, Adrian Larner, Chung Lee, David Livingstone, NikosLorentzos, Hizha Lu, Ramon Mata-Toledo, Nelson Mattos, David McGoveran (otra vez), FabianPascal, Suda Ram, Rick van der Lans, Yongdong Wang, Colin White y Qiang Zhu. Cada unade estas personas revisaron por lo menos una parte del manuscrito, pusieron a mi disposicin ma-terialtcnico o me ayudaron a encontrar las respuestas a mis mltiples preguntas tcnicas, porlo que les estoy muy agradecido. Por ltimo, deseo (como siempre) dar las gracias a todos enAddison-Wesley en especial a Maite Suarez-Rivas y a Katherine Harutunian por su incen-tivoy apoyo a lo largo de este proyecto, y a mi editora, Elydia Davis, por su excelente trabajode siempre.Healdsburg, California1999C. J. Date 23. PARTEPRELIMINARESILa parte I consta de cuatro captulos introductorios: El captulo 1 prepara el escenario explicando qu es una base de datos y por qu son necesarios los sistemas de bases de datos. Tambin explica brevemente la diferencia entre lossistemas de bases de datos relacinales y otros. A continuacin, el captulo 2 presenta una arquitectura general para sistemas de bases dedatos, denominada arquitectura ANSI/SPARC. Dicha arquitectura sirve como una estructura sobre la cual se basar el resto del libro. Despus, el captulo 3 presenta un panorama general de los sistemas relacinales (el objetivo es que sirva como introduccin para las explicaciones mucho ms amplias de este temaque aparecen en la parte II y posteriores). Tambin presenta y explica el ejemplo que va aser utilizado en todo el libro, la base de datos de proveedores y partes. Por ltimo, el captulo 4 presenta el lenguaje relacional estndar SQL. 24. CAPITULO 1Panorama general de la administracinde bases de datos1.1 INTRODUCCINUn sistema de bases de datos es bsicamente un sistema computarizado para llevar registros.Es posible considerar a la propia base de datos como una especie de armario electrnico paraarchivar; es decir, es un depsito o contenedor de una coleccin de archivos de datos computari-zados.Los usuarios del sistema pueden realizar una variedad de operaciones sobre dichos archivos.por ejemplo: Agregar nuevos archivos vacos a la base de datos; Insertar datos dentro de los archivos existentes; Recuperar datos de los archivos existentes; Modificar datos en archivos existentes; Eliminar datos de los archivos existentes; Eliminar archivos existentes de la base de datos.La figura 1.1 muestra una base de datos reducida que contiene un solo archivo, denominadoCAVA, el cual contiene a su vez datos concernientes al contenido de una cava de vinos. LaNICHO# VINO PRODUCTOR AO BOTELLAS LISTO2 Chardonnay Buena Vista 1997 1 19993 Chardonnay Geyser Peak 1997 5 19996 Chardonnay Simi 1996 4 199612 Joh. Riesling Jekel 1998 1 199921 Fum Blanc Ch. St. Jean 1997 4 199922 Fum Blanc Robt. Mondavi 1996 2 199830 Gewurztraminer Ch. St. Jean 1998 3 199943 Cab. Sauvignon Windsor 1991 12 200045 Cab. Sauvignon Geyser Peak 1994 12 200248 Cab. Sauvignon Robt. Mondavi 1993 12 200450 Pinot Noir Gary Farrel 1996 3 199951 Pinot Noir Fetzer 1993 3 200052 Pinot Noir Dehlinger 1995 2 199858 Merlot Clos du Bois 1994 9 200064 Zinfandel Cline 1994 9 200372 Zinfandel Rafanelli 1995 2 2003Figura 1.1 La base de datos de la cava de vinos (archivo CAVA). 25. Captulo 1 / Panorama general de la administracin de bases de datosRecuperacin:SELECT VINO, NICHO#, PRODUCTORFROM CAVAWHERE LISTO = 2000Resultado (por ejemplo, como se muestra en una pantalla demonitor):VINO NICHO# PRODUCTORCab. SauvignonPinot NoirMerlot435158Windsor FetzerClos du BoisFigura 1.2 Ejemplo de recuperacin.figura 1.2 muestra una operacin de recuperacin desde la base de datos, junto con los datosdevueltos por dicha operacin. Nota: Para una mayor claridad, a lo largo del libro mostramos enmaysculas las operaciones de base de datos, los nombres de archivo y otro material similar.En la prctica es a menudo ms conveniente escribir este material en minsculas. La mayora delos sistemas aceptan ambas denominaciones.La figura 1.3 muestra ejemplos de operaciones de insercin, modicacin y eliminacinde la base de datos anterior que prcticamente se explican por s mismos. Ms adelante, en loscaptulos 3,4,5, y en algunas otras partes, proporcionar ejemplos de la incorporacin y elimina-cinde archivos completos.Insercin de datos nuevos:INSERTINTO CAVA ( NICHO*, VINO, PRODUCTOR, AO, BOTELLAS, LISTO )VALUES ( 53, 'Pinot Noir', 'Saintsbury', 1997, 6, 2001 ) ;Modificacin de datos existentes:UPDATE CAVASET BOTELLAS 4WHERE NICHO# = 3 ;Eliminacin de datos existentes:DELETEFROM CAVAWHERE NICHO# = 2 ;Figura 1.3 Ejemplos de insercin, modificacin y eliminacin. 26. Parte I / PreliminaresPuntos importantes de estos ejemplos:1. Por razones obvias, a los archivos computarizados como el de CAVA de la figura 1.1.amenudo se les llama tablas (con ms precisin, tablas relacinales. Vea las secciones 1.3y 1-6).2. Podemos pensar en las filas de dicha tabla como los registros del archivo y en las columnas como los campos de dichos registros. En este libro, emplearemos la terminologa deregistros y campos cuando hablemos de sistemas de base de datos en general (principalmente en los dos primeros captulos); usaremos la terminologa de filas y columnas cuandohablemos de sistemas relacinales especficos (nuevamente, vea las secciones 1.3 y 1.6).Nota: En realidad, cuando abordemos explicaciones ms formales en las partes posterioresdel libro, cambiaremos a trminos ms formales.3. Por razones de simplicidad, en el ejemplo anterior hicimos la suposicin tcita de quelas columnas VINO y PRODUCTOR contienen datos de tipo cadena de caracteres y que lasdems columnas contienen datos enteros. Consideraremos con ms detalle la cuestin delos tipos de datos de las columnas en los captulos 3, 4 y en particular en el 5.4. La columna NICHO# constituye la clave primaria de la tabla CAVA (lo que significaque no es posible que dos filas de CAVA contengan el mismo valor de NICHO#). A menudo usamos un subrayado doble para sealar las columnas de clave primaria, como en lafigura 1.1.5. Las operaciones de ejemplo o "instrucciones" de las figuras 1.2 y 1.3 SELECT, INSERT,UPDATE, DELETE estn expresadas en un lenguaje denominado.SQL. SQL es el lenguaje estndar para interactuar con bases de datos relacinales y es soportado por prcticamente todos los productos de base de datos actuales. Nota: El nombre "SQL" significabaoriginalmente "Lenguaje estructurado de consultas" y se pronunciaba "sikuel". Sin embargo, ahora que el lenguaje se ha convertido en un estndar, el nombre es solamente representativo no es oficialmente la abreviatura de nada y la balanza se inclin en favor dela pronunciacin "es-kiu-el". En el libro tomaremos esta ltima pronunciacin.6. Observe que SQL utiliza la palabra clave UPDATE para indicar especficamente un "cambio". Este hecho puede causar confusin, debido a que este trmino tambin sola referirsea las tres operaciones INSERT, UPDATE y DELETE como grupo. En este libro, usaremosla palabra "actualizar", en minsculas, cuando nos refiramos al significado genrico yel operador UPDATE, en maysculas, cuando se trate de la operacin especfica de modificacin.7. Como es probable que ya sepa, la gran mayora de sistemas de bases de datos actuales sonrelacinales (o de todos modos deberan serlo vea el captulo 4, seccin 4.7). En parte poresta razn, este libro hace nfasis en dichos sistemas.Una ltima observacin preliminar: la comprensin del material de este captulo y el si-guientees fundamental para una apreciacin completa de las caractersticas y capacidades de unsistema moderno de base de datos. Sin embargo, no puede negarse que el material es en ciertomodo abstracto y un poco rido en ciertas partes, y que tiende a abarcar un gran nmero de con-ceptosy trminos que podran ser nuevos para usted. En las partes posteriores del libro enespecial en los captulos 3 y 4 encontrar material mucho menos abstracto y por lo tanto qui-zsms comprensible. De ah que tal vez prefiera, por el momento, dar a estos dos primeros 27. Captulo 1 / Panorama general de la administracin de bases de datoscaptulos una "leda ligera" y volverlos a leer con ms detenimiento cuando sean ms relevantes paralos temas que est abordando.1.2 QU ES UN SISTEMA DE BASE DE DATOS?Para repetir lo que mencionamos en la seccin anterior, un sistema de base de datos es bsica-menteun sistema computarizado para guardar registros; es decir, es un sistema computarizadocuya finalidad general es almacenar informacin y permitir a los usuarios recuperar y actualizaresa informacin con base en peticiones. La informacin en cuestin puede ser cualquier cosa quesea de importancia para el individuo u organizacin; en otras palabras, todo lo que sea necesariopara auxiliarle en el proceso general de su administracin.Nota: en este libro los trminos "datos" e "informacin" los trato como sinnimos. Algunosautores prefieren distinguir entre ambos, utilizando "datos" para referirse a lo que est en reali-dadalmacenado en la base de datos e "informacin" para referirse al significado de esos datoscomo lo entiende algn usuario. La diferencia es importante; tan importante que parece preferi-blehacerla explcita donde sea necesario, en vez de depender de una diferenciacin un tanto ar-bitrariaentre dos trminos que son en esencia sinnimos.La figura 1.4 es una imagen simplificada de un sistema de base de datos. Pretende mostrarque un sistema de base de datos comprende cuatro componentes principales: datos, hardware,software y usuarios. A continuacin consideramos brevemente estos cuatro componentes. PorSistema de administracin de base dedatos (DBMS)Programasde aplicacinBase de datosUsuarios finalesFigura 1.4 Imagen simplificada de un sistema de base de datos. 28. Parte I / Preliminaressupuesto, ms delante explicaremos cada uno con ms detalle (con excepcin del componentede hardware, cuyos detalles exceden en su mayora el alcance de este libro).DatosLos sistemas de bases de datos estn disponibles en mquinas que van desde las computadoraspersonales ms pequeas hasta las mainframes ms grandes. Sobra decir que las facilidades queproporciona un sistema estn determinadas hasta cierto punto por el tamao y potencia de lamquina subyacente. En particular, los sistemas que se encuentran en mquinas grandes ( s i stemas grandes") tienden a ser multiusuario, mientras que los que se ejecutan en mquinas pequeas ("sistemas pequeos") tienden a ser de un solo usuario. Un sistema de un solo usuarioes aquel en el que slo un usuario puede tener acceso a la base de datos en un momento dado;un sistema multiusuario es aquel en el cual mltiples usuarios pueden tener acceso simultneoa la base de datos. Como sugiere la figura 1.4, en este libro generalmente tomaremos el ltimocaso; aunque de hecho la distincin es irrelevante en lo que respecta a la mayora de los usua-rios:En general, el objetivo principal en los sistemas multiusuario es precisamente permitir quecada usuario se comporte como si estuviera trabajando en un sistema de un solo usuario. Losproblemas especiales de los sistemas multiusuario son en su mayora problemas internos del sis-temay no aquellos que son visibles al usuario (vea la parte IV de este libro, en especial el cap-tulo15).Nota: Para efectos de simplicidad, es conveniente suponer que la totalidad de los datos delsistema est almacenada en una sola base de datos, y en este libro haremos constantemente estasuposicin (ya que materialmente no afecta ninguna de nuestras explicaciones posteriores). Sirembargo, en la prctica podra haber buenas razones (incluso en un sistema pequeo) para quelos datos sean separados en diferentes bases de datos. Abordaremos algunas de estas razones masadelante, en el captulo 2 y en otras secciones.En general, los datos de la base de datos por lo menos en un sistema grande sern tantointegrados como compartidos. Como veremos en la seccin 1.4, los aspectos de integracin ycompartimiento de datos representan una ventaja importante de los sistemas de bases de datosen el entorno "grande"; y al menos, tambin la integracin de datos puede ser importante en losentornos "pequeos". Por supuesto, hay muchas ventajas adicionales (que abordaremos des-pus),aun en el entorno pequeo. Pero antes permtanos explicar lo que queremos decir con 1trminos integrado y compartido. Por integrada, queremos decir que podemos imaginar a la base de datos como unaunifi-cacinde varios archivos que de otro modo seran distintos, con una redundancia entre elloseliminada al menos parcialmente. Por ejemplo, una base de datos dada podra contener unarchivo EMPLEADO que proporcionara los nombres de los empleados, domicilios, departamentos, sueldos, etc. y un archivo INSCRIPCIN que representara la inscripcin de losempleados a los cursos de capacitacin (consulte la figura 1.5). Suponga ahora que, a fude llevar a cabo el proceso de administracin de cursos de capacitacin, es necesario saberel departamento de cada estudiante inscrito. Entonces, resulta claro que no es necesario incluir esa informacin de manera redundante en el archivo INSCRIPCIN, debido a quesiempre puede consultarse haciendo referencia al archivo EMPLEADO. Por compartida, queremos decir que las piezas individuales de datos en la base pueden scompartidas entre diferentes usuarios y que cada uno de ellos puede tener acceso a la mismapieza de datos, probablemente con fines diferentes. Como indiqu anteriormente, distintos 29. Captulo 1 / Panorama general de la administracin de bases de datosEMPLEADOINSCRIPCINNOMBRE DOMICILIO DEPARTAMENTO SUELDONOMBRE CURSOFigura 1.5 Los archivos EMPLEADO e INSCRIPCIN.usuarios pueden en efecto acceder a la misma pieza de datos al mismo tiempo ("acceso con-currente").Este compartimiento, concurrente o no, es en parte consecuencia del hecho deque la base de datos est integrada. En el ejemplo citado arriba, la informacin de departa-mentoen el archivo EMPLEADO sera tpicamente compartida por los usuarios del De-partamentode personal y los usuarios del Departamento de capacitacin; y como ya suger,estas dos clases de usuarios podran emplear esa informacin para fines diferentes. Nota:en ocasiones, si la base de datos no es compartida, se le conoce como "personal" o como"especfica de la aplicacin".Otra consecuencia de los hechos precedentes que la base de datos sea integrada y (por loregular) compartida es que cualquier usuario ocupar normalmente slo una pequea parte dela base de datos total; lo que es ms, las partes de los distintos usuarios se traslaparn de diver-sasformas. En otras palabras, una determinada base de datos ser percibida de muchas formasdiferentes por los distintos usuarios. De hecho, aun cuando dos usuarios tengan la misma por-cinde la base de datos, su visin de dicha parte podra diferir considerablemente a un nivel de-tallado.Este ltimo punto lo explico en forma ms completa en la seccin 1.5 y en los captulos2, 3 y en especial el 9.En la seccin 1.3 tendremos ms qu decir con respecto a la naturaleza del componente dedatos del sistema.HardwareLos componentes de hardware del sistema constan de: Los volmenes de almacenamiento secundario principalmente discos magnticos quese emplean para contener los datos almacenados, junto con los dispositivos asociados deE/S (unidades de discos, etc.), los controladores de dispositivos, los canales de E/S, entreotros; y Los procesadores de hardware y la memoria principal asociada usados para apoyar la ejecucin del software del sistema de base de datos (vea la siguiente subseccin).Este libro no hace mucha referencia a los aspectos de hardware del sistema, por las siguien-tesrazones (entre otras): Primero, estos aspectos conforman un tema importante por s mismos;segundo, los problemas que se encuentran en esta rea no son exclusivos de los sistemas de basede datos; y tercero, dichos problemas han sido investigados en forma minuciosa y descritos enotras partes. 30. Parte 1 / PreliminaresSoftwareEntre la base de datos fsica es decir, los datos como estn almacenados fsicamenteusuarios del sistema, hay una capa de software conocida de manera indistinta como el adminis-tradorde base de datos o el servidor de base de datos; o ms comnmente como el sistemade administracin de base de datos (DBMS). Todas las solicitudes de acceso a la base de datosson manejadas por el DBMS; las caractersticas que esbozamos en la seccin 1.1 para agreeliminar archivos (o tablas), recuperar y almacenar datos desde y en dichos archivos, etcterason caractersticas que proporciona el DBMS. Por lo tanto, una funcin general que ofreceDBMS consiste en ocultar a los usuarios de la base de datos los detalles al nivel de har (enforma muy parecida a como los sistemas de lenguajes de programacin ocultan a los pro-gramadoresde aplicaciones los detalles a nivel de hardware). En otras palabras, el DBMS ofrece alos usuarios una percepcin de la base de datos que est, en cierto modo, por encima del nivel delhardware y que maneja las operaciones del usuario (como las operaciones SQL explicadbrevemente en la seccin 1.1) expresadas en trminos de ese nivel ms alto de percepcin. A lolargo de este libro explicaremos con mayor detalle sta y otras funciones del DBMS.Algunos aspectos adicionales: El DBMS es, por mucho, el componente de software ms importante del sistema en general, aunque no es el nico. Otros comprenden las utileras, herramientas de desarrollo deaplicaciones, ayudas de diseo, generadores de informes y (el ms importante) el adminis-tradorde transacciones o monitor PT. Para una mayor explicacin de estos componentes.consulte los captulos 2 y 3 y (en especial) la parte IV. El trmino DBMS se usa tambin para referirse en forma genrica a un producto determinde algn fabricante; por ejemplo, el producto "DB2 Universal Database" de IBM paraOS/390. El trmino ejemplar de DBMS se usa entonces para referirse a una copia de dichoproducto que opera en alguna instalacin de computadora determinada. Como seguramnotar, en ocasiones es necesario distinguir cuidadosamente entre estos dos conceptos.Nota: Debemos advertirle que en la industria de las computadoras la gente amenudo usa el trmino base de datos cuando en realidad se refieren al DBMS (encualquiera de lo sentidos anteriores). He aqu un ejemplo tpico: "El fabricante de la basede datos X super al fabricante de la base de datos Y en proporcin de dos a uno." Esteuso es engaoso y no es correcto, aunque es mucho muy comn. (Por supuesto, elproblema es que si al DBMS lo llamamos base de datos, entonces cmo llamaremos a labase de datos?) Advertencia para el lector.UsuariosConsideramos tres grandes clases de usuarios (y que en cierto modo se traslapan): Primero, hay programadores de aplicaciones responsables de escribir los programasde aplicacin de base de datos en algn lenguaje de programacin como COBOL. PL/1.C++ Java o algn lenguaje de alto nivel de la "cuarta generacin" (vea el captulo 2).Estos pro-gramas acceden a la base de datos emitiendo la solicitud apropiada al DBMS(por lo regu lar una instruccin SQL). Los programas en s pueden ser aplicacionesconvenciona por lotes o pueden ser aplicaciones en lnea, cuyo propsito es permitir alusuario final el acceso a la base de datos desde una estacin de trabajo o terminal enlnea (vea el parrafo siguiente). Las aplicaciones ms modernas pertenecen a estavariedad. 31. Captulo 1 / Panorama general de la administracin de bases de datos 9 En consecuencia, la segunda clase de usuarios son los usuarios finales, quienes interactancon el sistema desde estaciones de trabajo o terminales en lnea. Un usuario final puede acceder a la base de datos a travs de las aplicaciones en lnea mencionadas en el prrafo anterior, o bien puede usar una interfaz proporcionada como parte integral del software delsistema de base de datos. Por supuesto, las interfaces proporcionadas por el fabricante estnapoyadas tambin por aplicaciones en lnea, aunque esas aplicaciones estn integradas; esdecir, no son escritas por el usuario. La mayora de los sistemas de base de datos incluyenpor lo menos una de estas aplicaciones integradas, digamos un procesador de lenguaje deconsulta, mediante el cual el usuario puede emitir solicitudes a la base de datos (tambinconocidas como instrucciones o comandos), como SELECT e INSERT, en forma interactiva con el DBMS. El lenguaje SQL mencionado en la seccin 1.1 es un ejemplo tpico deun lenguaje de consulta de base de datos.Nota: El trmino "lenguaje de consulta", a pesar de ser comn, no es muy preciso, yaque el verbo "consultar" en lenguaje normal sugiere slo una recuperacin, mientras quelos lenguajes de consulta por lo regular (aunque no siempre) ofrecen tambin actualizaciny otras operaciones.La mayora de los sistemas proporcionan adems interfaces integradas adicionales enlas que los usuarios no emiten en absoluto solicitudes explcitas a la base de datos, comoSELECT, sino que en vez de ello operan mediante (por ejemplo) la seleccin de elementosen un men o llenando casillas de un formulario. Estas interfaces controladas por menus opor formularios tienden a facilitar el uso a personas que no cuentan con una capacitacin for-malen IT (Tecnologa de la informacin; la abreviatura IS, de Sistemas de informacin,tambin es muy usada con el mismo significado). En contraste, las interfaces controladaspor comandos (por ejemplo, los lenguajes de consulta) tienden a requerir cierta experien-ciaprofesional en IT, aunque tal vez no demasiada (obviamente no tanta como la que esnecesaria para escribir un programa de aplicacin en un lenguaje como COBOL). Por otraparte, es probable que una interfaz controlada por comandos sea ms flexible que una con-troladapor menus o por formularios, dado que los lenguajes de consulta por lo regular in-cluyenciertas caractersticas que no manejan esas otras interfaces. El tercer tipo de usuario, que no aparece en la figura 1.4, es el administrador de base dedatos o DBA. La funcin del DBA, y la funcin asociada (muy importante) del administrador de datos, se abordar en la seccin 1.4 y en el captulo 2 (seccin 2.7).Con esto concluimos nuestra descripcin preliminar de los aspectos ms importantes de unsistema de base de datos. Ahora continuaremos con la explicacin de estas ideas con un pocoms de detalle.1.3 QUE ES UNA BASE DE DATOS?Datos persistentesEs una costumbre referirse a los datos de la base de datos como "persistentes" (aunque en realidadstos podran no persistir por mucho tiempo!). Por persistentes queremos decir, de manera intuiti-va,que el tipo de datos de la base de datos difiere de otros datos ms efmeros, como los datos deentrada, los datos de salida, las instrucciones de control, las colas de trabajo, los bloques de controlde software, los resultados intermedios y de manera ms general, cualquier dato que sea de naturalezatransitoria. En forma ms precisa, decimos que los datos de la base de datos "persisten" debido 32. 10 Parte I / Preliminaresen primer lugar a que una vez aceptados por el DBMS para entrar en la base de datos, en lo suce-sivoslo pueden ser removidos de la base de datos por alguna solicitud explcita al DBMS, nocomo un mero efecto lateral de (por ejemplo) algn programa que termina su ejecucin. Por lo tanto,esta nocin de persistencia nos permite dar una definicin ms precisa del trmino "base de datos": Una base de datos es un conjunto de datos persistentes que es utilizado por los sistemas deaplicacin de alguna empresa dada.Aqu, el trmino "empresa" es simplemente un trmino genrico conveniente para identificar acualquier organizacin independiente de tipo comercial, tcnico, cientfico u otro. Una empresapodra ser un solo individuo (con una pequea base de datos personal), toda una corporacin oun gran consorcio similar (con una gran base de datos compartida) o todo lo que se ubique entreestas dos opciones. Aqu tenemos algunos ejemplos:1. Una compaa manufacturera2. Un banco3. Un hospital4. Una universidad5. Un departamento gubernamentalToda empresa necesariamente debe mantener una gran cantidad de datos acerca de su opera-cin.Estos datos son los "datos persistentes" a los que nos referimos antes. En forma caracterstica,las empresas que acabamos de mencionar incluiran entre sus datos persistentes a los siguientes:1. Datos de produccin2. Datos contables3. Datos de pacientes4. Datos de estudiantes5. Datos de planeacinNota: Las primeras ediciones de este libro utilizaban el trmino "datos operacionales" en lu-garde "datos persistentes". El primer trmino reflejaba el nfasis original en los sistemas de basede datos con aplicaciones operacionales o de produccin; es decir, aplicaciones rutinarias al-tamenterepetitivas que eran ejecutadas una y otra vez para apoyar la operacin cotidiana de laempresa (por ejemplo, una aplicacin para manejar los depsitos o retiros de efectivo en un siste-mabancario). Para describir este tipo de entorno, se ha llegado a utilizar el trmino procesa-mientode transacciones en lnea. Sin embargo, ahora las bases de datos se utilizan cada vez mstambin para otro tipo de aplicaciones (por ejemplo, aplicaciones de apoyo a la toma de deci-siones)y el trmino "datos operacionales" ya no es del todo apropiado. De hecho, hoy en das lasempresas mantienen generalmente dos bases de datos independientes; una que contiene los da-tosoperacionales y otra, a la que con frecuencia se le llama almacn de datos (data warehouse),que contiene datos de apoyo para la toma de decisiones. A menudo el almacn de datos incluyeinformacin de resumen (por ejemplo, totales, promedios...) y dicha informacin a su vez se ex-traeperidicamente de la base de datos operacional; digamos una vez al da o una vez por sema-na.Para una explicacin ms amplia de las bases de datos y las aplicaciones de apoyo a la tomade decisiones, consulte el captulo 21. 33. Capitulo 1 / Panorama general de la administracin de bases de datos 11Entidades y vnculosAhora consideraremos el ejemplo de una compaa manufacturera ("KnowWare Inc.") con unpoco ms de detalle. Por lo general, una empresa as desea registrar la informacin sobre losproyectos que maneja, las partes que utiliza en dichos proyectos, los proveedores que suminis-tranesas partes, los almacenes en donde guardan esas partes, los empleados que trabajan en esosproyectos, etctera. Por lo tanto los proyectos, partes, proveedores, etctera, constituyen las en-tidadesbsicas de informacin que KnowWare Inc. necesita registrar (el trmino "entidad" esempleado comnmente en los crculos de bases de datos para referirse a cualquier objeto dis-tinguibleque va a ser representado en la base de datos). Vea la figura 1.6.Adems de las propias entidades bsicas (como los proveedores, las partes, etctera, en elejemplo), habr tambin vnculos que asocian dichas entidades bsicas. Estos vnculos estn re-presentadospor los rombos y las lneas de conexin de la figura 1.6. Por ejemplo, existe un vnculo("VP") entre proveedores y partes: cada proveedor suministra ciertas partes y de manerainversa, cada parte es suministrada por ciertos proveedores (para ser ms precisos, cada provee-dorsuministra ciertos tipos de partes y cada tipo de parte es suministrado por ciertos proveedo-res).En forma similar, las partes son utilizadas en proyectos y de manera inversa, los proyectosutilizan partes (vnculo PY); las partes son guardadas en almacenes y los almacenes guardan par-tes(vnculo AP); y as sucesivamente. Observe que todos estos vnculos son bidireccionales; esdecir, pueden ser recorridos en ambas direcciones. Por ejemplo, el vnculo VP entre proveedoresy partes puede ser usado para responder las dos siguientes preguntas: Dado un proveedor, obtener las partes que ste suministra. Dada una parte, obtener los proveedores que la suministran.Proveedores ProyectosVL > Almacenes < APLocalidades DepartamentosFigura 1.6 Diagrama de entidad/vnculo (E/R) para KnowWare Inc. 34. - y12 Parte I / PreliminaresEl punto importante con respecto a este vnculo (y por supuesto, con respecto a todos losvnculos de la figura) es que son parte de los datos tanto como lo son las entidades bsicas. Porlo tanto, deben estar representados en la base de datos al igual que las entidades bsicas. Nota:Como veremos en el captulo 3, especficamente en un sistema relacional, tanto las entidadesbsicas como los vnculos que las conectan sern representados por medio de tablas como la quese muestra en la figura 1.1.Observemos de paso que la figura 1.6 es un ejemplo de lo que se denomina (por razonesobvias) diagrama de entidad/vnculo (diagrama E/R para abreviar). En el captulo 13 conside-raremosestos diagramas con un poco ms de detalle.La figura 1.6 ilustra adems otros puntos importantes:1. Aunque la mayora de los vnculos de la figura comprenden dos tipos de entidad (es decir.son vnculos binarios) no significa que todos los vnculos deban ser necesariamente binarios en este aspecto. En el ejemplo hay un vnculo ("VPY") que involucra tres tipos de entidad (proveedores, partes y proyectos): un vnculo ternario. La interpretacin que pretendodar es que ciertos proveedores suministran ciertas partes para ciertos proyectos. Observecon cuidado que este vnculo ternario ("los proveedores suministran partes para proyectos")normalmente no equivale a la combinacin de tres vnculos binarios "los proveedores suministran partes", "las partes se usan en proyectos" y "los proyectos son abastecidos por losproveedores". Por ejemplo, la declaracin de que(a) Smith suministra llaves inglesas para el proyecto Manhattan,nos dice ms de lo que expresan las tres declaraciones siguientes:(b) Smith suministra llaves inglesas,(c) Las llaves inglesas se usan en el proyecto Manhattan y(d) El proyecto Manhattan es abastecido por SmithNo podemos (de manera vlida!) inferir (a) conociendo nicamente (b). (c) y (d). Paraser ms precisos, si conocemos (b), (c) y (d) entonces podramos inferir que Smith sumi-nistrallaves inglesas para algn proyecto (digamos el proyecto Yz), que cierto proveedor (di-gamosVX) suministra llaves inglesas al proyecto Manhattan, y que Smith suministra algunaparte (digamos la parte Py) al proyecto Manhattan, pero no podemos inferir en forma vlidaque Vx sea Smith ni que Py sean llaves inglesas ni que Yz sea el proyecto Manhattan.Falsas inferencias como stas son ejemplos de lo que a veces se denomina trampa deconexin.2. La figura tambin muestra un vnculo (PP) que comprende slo un tipo de entidad (partes).El vnculo aqu es que ciertas partes incluyen a otras partes como componentes inmediatos(el tan mencionado vnculo de lista de materiales); por ejemplo, un tornillo es un componente de una bisagra, que tambin es considerada una parte y podra ser a su vez parte deun componente de un nivel superior como una tapa. Observe que el vnculo sigue siendobinario; slo que los dos tipos de entidad que estn vinculados (partes y partes) vienen a serla misma entidad.3. En general, un conjunto determinado de tipos de entidad podra vincularse entre s encualquier cantidad de vnculos distintos. En el ejemplo de la figura 1.6, hay dos vnculosdistintos que involucran a proyectos y empleados: Uno (EY) representa el hecho de que losempleados estn asignados a proyectos, el otro (MY) representa el hecho de que los empleados administran proyectos. 35. Captulo 1 / Panorama general de la administracin de bases de datos 13Ahora observamos que un vnculo puede considerarse como una entidad por derecho propio.Si tomamos nuestra definicin de entidad como "cualquier objeto acerca del cual queremos re-gistrarinformacin", entonces un vnculo se ajusta perfectamente a la definicin. Por ejemplo,"la parte P4 est guardada en el almacn A8" es una entidad acerca de la cual bien querramosregistrar informacin (por ejemplo, la cantidad correspondiente). Ms an, podemos obtenerventajas definitivas (que exceden el alcance de este captulo) no haciendo distinciones innece-sariasentre entidades y vnculos. Por lo tanto, en este libro trataremos en su mayora a los vncu-losslo como una clase especial de entidad.PropiedadesComo acabamos de sealar, una entidad es cualquier objeto acerca del cual queremos registrarinformacin. De donde se desprende que las entidades (incluidos los vnculos) poseen propie-dadesque corresponden a la informacin que deseamos registrar sobre ellas. Por ejemplo, losproveedores tienen localidades; las partes tienen pesos; los proyectos tienen prioridades; las asig-naciones(de empleados a proyectos) tienen fechas de inicio, etctera. Por lo tanto, dichaspropiedades deben estar representadas en la base de datos. Por ejemplo, la base de datos podraincluir una tabla denominada V que represente a los proveedores y esa tabla podra incluir unacolumna de nombre CIUDAD que represente a las localidades de los proveedores.En general, las propiedades pueden ser tan simples o tan complejas como queramos. Porejemplo, la propiedad "localidad del proveedor" es supuestamente bastante simple, ya que sloconsiste en un nombre de ciudad y puede ser representada en la base de datos por una simple cade-nade caracteres. En contraste, un almacn podra tener una propiedad "plan de piso", que podraser bastante compleja, consistir tal vez en todo un dibujo arquitectnico y en el texto descriptivoasociado. Al momento de la publicacin de este libro, la mayora de los productos de basesde datos estaban apenas logrando manejar propiedades complejas como el dibujo y el texto. Re-gresaremosa este tema ms delante (en especial en el captulo 5 y en la Parte VI); mientras tanto,en la mayora de los casos (en donde signifique una diferencia) daremos por hecho que laspropiedades son "simples" y que pueden ser representadas mediante tipos de datos "simples".Los ejemplos de dichos tipos "simples" incluyen nmeros, cadenas de caracteres, fechas, horas,etctera.Datos y modelos de datosExiste otra importante forma de pensar sobre lo que en realidad son los datos y las bases de datos.La palabra datos se deriva del vocablo latn para "dar"; por lo tanto, los datos en realidad sonhechos dados, a partir de los cuales es posible inferir hechos adicionales. (Inferir hechos adi-cionalesa partir de hechos dados es exactamente lo que hace el DBMS cuando responde a unaconsulta de un usuario.) Un "hecho dado" corresponde a su vez a lo que en lgica se denominaproposicin verdadera;* por ejemplo, el enunciado "El proveedor V1 se ubica en Londres" po-draser una de estas proposiciones verdaderas. De aqu se desprende que una base de datos esen realidad una coleccin de tales proposiciones verdaderas [1.2].*En lgica, una proposicin es algo que se evala ya sea como verdadero o como falso en forma ine-quvoca.Por ejemplo, "William Shakespeare escribi Pride and Prejudice" es una proposicin (por cierto,una falsa). 36. 14 Parte I / PreliminaresUna razn por la que los sistemas de bases de datos relacinales se han vuelto tan dominan-tes,tanto en el mundo industrial como en el acadmico, es que manejan en forma muy directa (dehecho casi trivial) la interpretacin precedente de los datos y las bases de datos. Los sistemasrelacinales estn basados en una teora formal denominada el modelo de datos relacional, deacuerdo con el la cual: En tablas, los datos son representados por medio de filas y estas filas pueden interpretarsedirectamente como proposiciones verdaderas. Por ejemplo, en la figura 1.1, la fila NICHO#72 puede interpretarse en forma obvia como la siguiente proposicin verdadera:"El nicho nmero 72 contiene dos botellas de Zinfandel Rafanelli 1995, y estarn listas parasu consumo en el ao 2003." Se proporcionan operadores para operar sobre las columnas de las tablas, y estos operadoressoportan directamente el proceso de inferir proposiciones verdaderas adicionales a partir delas ya dadas. Como ejemplo sencillo, el operador relacional proyectar (vea la seccin 1.6)nos permite inferir, a partir de la proposicin verdadera que acabamos de citar, la siguienteproposicin verdadera, entre otras:"Algunas botellas de Zinfandel estarn listas para su consumo en el ao 2003."(para ser ms precisos: "Algunas botellas de Zinfandel, en algn nicho, producidas poralgn productor en algn ao, estarn listas para su consumo en el ao 2003.")Sin embargo, el modelo relacional no es el nico modelo de datos. Existen otros (vea la sec-cin1.6), aunque la mayora de ellos difieren del modelo relacional en que son hasta cierto gradoespecficos, en vez de estar basados firmemente en la lgica formal. Sea lo que fuere, surge lapregunta: En general qu es un modelo de datos? Podemos definir el concepto como sigue:Un modelo de datos es una definicin lgica, independiente y abstracta de los objetos, ope-radoresy dems que en conjunto constituyen la mquina abstracta con la que interactanlos usuarios. Los objetos nos permiten modelar la estructura de los datos. Los operadores nospermiten modelar su comportamiento.Entonces, de manera til, podemos distinguir al modelo de su implementacion: La implementacin de determinado modelo de datos es una realizacin fsica, en una mquina real, de los componentes de la mquina abstracta que en conjunto constituyen ese modelo.Resumiendo: El modelo es aquello que los usuarios tienen que conocer; la implementacin eslo que los usuarios no tienen que conocer.Nota: Como puede ver, la distincin entre modelo e implementacin es en realidad slo uncaso especial (uno muy importante) de la conocida distincin entre lgico y fsico. Sin embargo,por desgracia muchos de los sistemas de bases de datos actuales (incluso aquellos que dicen serrelacinales) no hacen estas distinciones con tanta claridad como debieran. De hecho, parece nohaber un buen entendimiento de estas distinciones y de la importancia de hacerlas. Como con-secuencia,a menudo hay una brecha entre los principios de las bases de datos (la forma en quelos sistemas de bases de datos deberan funcionar) y la prctica de las bases de datos (la formaen que realmente funcionan). En este libro nos enfocamos principalmente en los principios; aun-quees justo advertirle que cuando comience a utilizar un producto comercial, podra llevarse al-gunassorpresas desagradables. 37. Captulo 1 / Panorama general de la administracin de bases de datos 15Para concluir esta seccin, debemos mencionar el hecho de que en realidad el trmino mo-delode datos es utilizado en la literatura con dos significados muy distintos. El primero es comose describi anteriormente. El segundo es como un modelo de los datos persistentes de algunaempresa en particular (por ejemplo, la compaa manufacturera KnowWare Inc. que menciona-mosanteriormente en esta seccin). La diferencia entre ambos significados puede ser caracteri-zadacomo sigue: En el primer sentido, un modelo de datos es como un lenguaje de programacin (aunqueen cierto modo abstracto) cuyos elementos pueden ser usados para resolver una amplia variedad de problemas especficos, pero que en s y por s mismos no tienen una conexin directa con ninguno de estos problemas especficos. En el segundo sentido, un modelo de datos es como un programa especfico escrito en eselenguaje. En otras palabras, un modelo de datos que toma las caractersticas que ofrece algn modelo como el primero y las aplica a cierto problema especfico. Puede ser visto comouna aplicacin especfica de algn modelo con el primer significado.De aqu en adelante, en este libro usaremos el trmino modelo de datos slo en el primersentido, excepto cuando se indique lo contrario.1.4 POR QU UNA BASE DE DATOS?Por qu utilizar un sistema de base de datos? Cules son las ventajas? Hasta cierto punto, larespuesta a estas preguntas depende de si el sistema en cuestin es de un solo usuario o multi-usuario(o para ser ms precisos, existen muchas ventajas adicionales en el caso del sistemamultiusuario). Consideraremos primero el caso de un solo usuario.Vuelva a ver el ejemplo de la cava de vinos de la figura 1.1, el cual puede ser ilustrativopara el caso de un solo usuario. Ahora bien, esa base de datos es tan reducida y sencilla que lasventajas podran no ser tan obvias. Pero imagine una base de datos similar para un gran restau-rante,con una existencia tal vez de miles de botellas y cambios muy frecuentes a dichas exis-tencias;o piense en una tienda de licores, tambin con una gran existencia y una mayor rotacinen la misma. Tal vez en estos casos sea ms fcil apreciar las ventajas de un sistema de basede datos sobre los mtodos tradicionales basados en papel, para llevar un registro. He aqualgunas: Compactacin: No hay necesidad de archivos en papel voluminosos. Velocidad: La mquina puede recuperar y actualizar datos ms rpidamente que un humano.En particular, las consultas especficas sin mucha elaboracin (por ejemplo, "Tenemosms Zinfandel que Pinot Noir?") pueden ser respondidas con rapidez, sin necesidad debsquedas manuales o visuales que llevan tiempo. Menos trabajo laborioso; Se puede eliminar gran parte del trabajo de llevar los archivos amano. Las tareas mecnicas siempre las realizan mejor las mquinas. Actualidad: En el momento que la necesitemos, tendremos a nuestra disposicin informa-cinprecisa y actualizada.Desde luego, los beneficios anteriores se aplican an con ms fuerza en un entorno multi-usuario,donde es probable que la base de datos sea mucho ms grande y compleja que en el caso 38. Parte I / Preliminaresde un solo usuario. No obstante, en el entorno multiusuario hay una ventaja adicional, que ex-presaremosas: El sistema de base de datos ofrece a la empresa un control centralizado de susdatos (los cuales, como se habr dado cuenta a estas alturas, constituyen uno de sus activos msvaliosos). Esta situacin contrasta en gran medida con la que se encuentra en una empresa queno cuenta con un sistema de base de datos, en donde por lo general cada aplicacin tiene sus pro-piosarchivos privados (a menudo tambin sus propias cintas y discos) de modo que los datosestn muy dispersos y son difciles de controlar de una forma sistemtica.Administracin de datos y administracin de bases de datosExplicaremos brevemente este concepto del control centralizado. El concepto implica que enla empresa habr alguna persona identificable que tendr esta responsabilidad central sobrelos datos. Esa persona es el administrador de datos (o DA) que mencionamos brevemente alfinal de la seccin 1.2. Ya que (repitiendo) los datos son uno de los activos ms valiosos de laempresa, es imperativo que exista una persona que los entienda junto con las necesidades dela empresa con respecto a esos datos, a un nivel de administracin superior. Esa persona esel administrador de datos. Por lo tanto, es labor del administrador de datos decidir en primerlugar qu datos deben ser almacenados en la base de datos y establecer polticas para mantenery manejar esos datos una vez almacenados. Un ejemplo de estas polticas podra ser una queindicara quin puede realizar qu operaciones sobre ciertos datos y bajo qu circunstancias.En otras palabras, una poltica de seguridad de los datos (vea la siguiente subseccin).Hay que destacar que el administrador de datos es un administrador, no un tcnico (aunquees cierto que necesita tener cierta idea de las posibilidades que tienen los sistemas de base de datosen el mbito tcnico). El tcnico responsable de implementar las decisiones del administradorde datos es el administrador de base de datos (o DBA). Por lo tanto, el DBA, a diferencia deladministrador de datos, es un profesional IT. El trabajo del DBA consiste en crear la base dedatos real e implementar los controles tcnicos necesarios para hacer cumplir las diversas deci-sionesde las polticas hechas por el administrador de datos. El DBA tambin es responsablede asegurar que el sistema opere con el rendimiento adecuado y de proporcionar una variedad deotros servicios tcnicos. Por lo regular, el DBA tendr un equipo de programadores de sistemasy otros asistentes tcnicos (es decir, en la prctica la funcin del DBA normalmente es realizadapor un equipo de personas, no por una sola); sin embargo, para fines de simplicidad, es conve-nientesuponer que el DBA es de hecho un solo individuo. En el captulo 2 abordaremos con msdetalle la funcin del DBA.Beneficios del enfoque de base de datosEn esta subseccin identificaremos algunas de las ventajas especficas que surgen de la nocinanterior de control centralizado. Los datos pueden compartirseExplicamos este punto en la seccin 1.2, pero para complementar lo mencionaremos denuevo aqu. Compartir no slo significa que las aplicaciones existentes puedan compartirla informacin de la base de datos, sino tambin que sea posible desarrollar nuevas apli-cacionespara operar sobre los mismos datos. En otras palabras, es posible satisfacer los 39. Captulo 1 / Panorama general de la administracin de bases de datos 17requerimientos de datos de aplicaciones nuevas sin tener que agregar informacin a la basede datos.Es posible reducir la redundanciaEn sistemas que no son de bases de datos, cada aplicacin tiene sus propios archivos ex-clusivos.A menudo este hecho puede conducir a una redundancia considerable de los datosalmacenados, con el consecuente desperdicio de espacio de almacenamiento. Por ejemplo,una aplicacin de personal y una aplicacin de registro de escolaridad podran tener un ar-chivoque tuviera informacin departamental de los empleados. Sin embargo, como sugeren la seccin 1.2, estos dos archivos pueden integrarse y eliminar as la redundancia, en tantoel administrador de datos est consciente de los requerimientos de datos de ambas aplicacio-nes;es decir, en tanto la empresa tenga el control general necesario.Por cierto, no pretendemos sugerir que toda la redundancia pueda o deba necesaria-menteser eliminada. En ocasiones hay razones slidas, tcticas o del negocio, para man-tenervarias copias distintas de los mismos datos. Sin embargo, s pretendemos sugerir quecualquier redundancia de este tipo debe ser controlada cuidadosamente; es decir, el DBMSdebe estar al tanto de ella, si es que existe, y debe asumir la responsabilidad de "propagarlas actualizaciones" (vea el siguiente punto).Es posible (hasta cierto grado) evitar la inconsistenciaste es en realidad el corolario del punto anterior. Suponga que un hecho ms real diga-mosque el empleado E3 trabaja en el departamento D8 est representado por dos enti-dadesdistintas en la base de datos. Suponga tambin que el DBMS no est al tanto de estaduplicidad (es decir, la redundancia no est controlada). Entonces necesariamente habrocasiones en las que las dos entidades no coincidan: digamos, cuando una de ellas ha sidoactualizada y la otra no. En esos momentos, decimos que la base de datos es inconsistente.Resulta claro que una base de datos en un estado inconsistente es capaz de proporcionar asus usuarios informacin incorrecta o contradictoria.Por supuesto, si el hecho anterior es representado por una sola entrada (es decir, si seelimina la redundancia), entonces no puede ocurrir tal inconsistencia. Como alternativa; sino se elimina la redundancia pero se controla (hacindola del conocimiento del DBMS),entonces el DBMS puede garantizar que la base de datos nunca ser inconsistente a los ojosdel usuario, asegurando que todo cambio realizado a cualquiera de las dos entidades seraplicado tambin a la otra en forma automtica. A este proceso se le conoce como propa-gacinde actualizaciones.Es posible brindar un manejo de transaccionesUna transaccin es una unidad de trabajo lgica, que por lo regular comprende varias opera-cionesde la base de datos (en particular, varias operaciones de actualizacin). El ejemplocomn es el de transferir una cantidad de efectivo de una cuenta A a otra cuenta B. Es claroque aqu se necesitan dos actualizaciones, una para retirar el efectivo de la cuenta A y la otrapara depositarlo en la cuenta B. Si el usuario declara que las dos actualizaciones son partede la misma transaccin, entonces el sistema puede en efecto garantizar que se hagan ya seaambas o ninguna de ellas, aun cuando el sistema fallara (digamos por falta de suministroelctrico) a la mitad del proceso.Nota: La caracterstica de atomicidad de las transacciones que acabamos de ilustrar noes el nico beneficio del manejo de transacciones, pero a diferencia de las otras caractersti- 40. 18 Parte I / Preliminarescas, sta se aplica aun en el caso de un solo usuario.* En los captulos 14 y 15 aparece unadescripcin completa de las diversas ventajas del manejo de transacciones y de cmopueden ser logradas.Es posible mantener la integridadEl problema de la integridad es el de asegurar que los datos de la base de datos estn co-rrectos.La inconsistencia entre dos entradas que pretenden representar el mismo "hecho" esun ejemplo de la falta de integridad (vea antes la explicacin de este punto, en esta subsec-cin);desde luego, este problema en particular puede surgir slo si existe redundancia enlos datos almacenados. No obstante, aun cuando no exista redundancia, la base de datos po-draseguir conteniendo informacin incorrecta. Por ejemplo, un empleado podra aparecercon 400 horas laboradas durante la semana, en lugar de 40; o como parte de un departa-mentoque no existe. El control centralizado de la base de datos puede ayudar a evitar estosproblemas (en la medida de lo posible) permitiendo que el administrador de datos defina yel DBA implemente las restricciones de integridad (tambin conocidas como reglas delnegocio) que sern verificadas siempre que se realice una operacin de actualizacin.Vale la pena sealar que la integridad de los datos es an ms importante en un siste-made base de datos que en un entorno de "archivos privados", precisamente porque los datosson compartidos. Sin los controles apropiados sera posible que un usuario actualizara labase de datos en forma incorrecta, generando as datos malos e "infectando" a otros usua-rioscon esos datos. Tambin debemos mencionar que actualmente la mayora de los pro-ductosde bases de datos son mas bien dbiles con respecto al manejo de las restriccionesde integridad (aunque ha habido algunas mejoras recientes en esta rea). ste es un hechodesafortunado, ya que (como veremos en el captulo 8) las restricciones de integridad sonfundamentales y de crucial importancia, mucho ms de lo que por lo regular apreciamos.Es posible hacer cumplir la seguridadAl tener la completa jurisdiccin sobre la base de datos, el DBA (por supuesto, bajo la di-reccinapropiada del administrador de datos) puede asegurar que el nico medio de accesoa la base de datos sea a travs de los canales adecuados y por lo tanto puede definir las reglaso restricciones de seguridad que sern verificadas siempre que se intente acceder a datossensibles. Es posible establecer diferentes restricciones para cada tipo de acceso (recupera-cin,insercin, eliminacin, etctera) para cada parte de la informacin de la base de datos.Sin embargo, observe que sin dichas restricciones la seguridad de los datos podra de hechoestar en mayor riesgo que en un sistema de archivos tradicionales (dispersos); es decir, lanaturaleza centralizada de un sistema de base de datos requiere, en cierto sentido, que tam-binsea establecido un buen sistema de seguridad.Es posible equilibrar los requerimientos en conflictoAl conocer los requerimientos generales de la empresa (a diferencia de los requerimientosde los usuarios individuales), el DBA puede estructurar los sistemas de manera que ofrez-canun servicio general que sea "el mejor para la empresa" (de nuevo bajo la direccin deladministrador de datos). Por ejemplo, es posible elegir una representacin fsica de los datos* Por otra parte, los sistemas de un solo usuario a menudo no proporcionan ningn tipo de manejo detransacciones sino que simplemente dejan el problema al usuario. 41. Captulo 1 / Panorama general de la administracin de bases de datos 19almacenados que proporcione un acceso rpido para las aplicaciones ms importantes (posi-blementea costa de un acceso ms lento para otras aplicaciones).Es posible hacer cumplir los estndaresCon el control central de la base de datos, el DBA (una vez ms, bajo la direccin del ad-ministradorde datos) puede asegurar que todos los estndares aplicables en la repre-sentacinde los datos sean observados. Estos estndares podran incluir alguno o todos lossiguientes: departamentales, de instalacin, corporativos, de la industria, nacionales e in-ternacionales.Es conveniente estandarizar la representacin de datos, en particular comoun auxiliar para el intercambio de datos o para el movimiento de datos entre sistemas (estaconsideracin se ha vuelto particularmente importante con el advenimiento de los sistemasdistribuidos; vea los captulos 2 y 20). En forma similar, los estndares en la asignacin denombres y en la documentacin de los datos tambin son muy convenientes como unaayuda para compartir y entender los datos.Es probable que la mayora de las ventajas mencionadas arriba sean bastante obvias. Sinembargo, es necesario agregar a la lista un punto que podra no ser tan obvio (aunque de hechoest implcito en otros); se trata de dar independencia a los datos. (Estrictamente hablando, stees un objetivo de los sistemas de bases de datos, en vez de una ventaja). El concepto de la inde-pendenciade los datos es tan importante que le dedicamos una seccin aparte.1.5 LA INDEPENDENCIA DE LOS DATOSComenzaremos por observar que existen dos clases de independencia de los datos, fsica y lgi-ca[1.3-1.4]; sin embargo, por el momento nos concentraremos slo en la clase fsica. Por lotanto, mientras no se diga otra cosa, el trmino no calificado "independencia de datos" deberentenderse especficamente como independencia fsica de los datos. En los captulos 2, 3 y enespecial en el 9, abordaremos la independencia lgica de los datos. Nota: Tal vez tambin de-bamosdecir que el trmino "independencia de los datos" no es muy adecuado (no capta muybien la naturaleza de lo que en realidad est sucediendo); sin embargo, es el trmino utilizadotradicionalmente y nos apegaremos a l en este libro.Podemos entender ms fcilmente la independencia de los datos considerando a su opuesto.Las aplicaciones implementadas en sistemas ms antiguos (los sistemas anteriores a los rela-cinaleso incluso anteriores a las bases de datos) tienden a ser dependientes de los datos. Estosignifica que la forma en que fsicamente son representados los datos en el almacenamiento se-cundarioy la tcnica empleada para su acceso, son dictadas por los requerimientos de la apli-cacinen consideracin, y ms an, significa que el conocimiento de esa representacin fsicay esa tcnica de acceso estn integrados dentro del cdigo de la aplicacin. Ejemplo: Suponga que tenemos una aplicacin que utiliza el archivo EMPLEADO de lafigura 1.5 y suponga que se decidi, por motivos de rendimiento, que el archivo estara in-dexadoen su campo "nombre del empleado". En un sistema antiguo, la aplicacin encuestin generalmente estara al tanto del hecho de que existe el ndice, as como de la se-cuenciade registros que define ese ndice; y la estructura de la aplicacin estara construi-daalrededor de ese conocimiento. En particular, la forma exacta de los diversos accesos adatos y rutinas de verificacin de excepciones dentro de la aplicacin, depender en gran 42. 20 Parte I / Preliminaresmedida de los detalles de la interfaz que el software de administracin de datos presenta ala aplicacin.Decimos que una aplicacin como la del ejemplo es dependiente de los datos, debido a quees imposible modificar la representacin fsica (la forma en que los datos estn fsicamente re-presentadosen el almacenamiento) o la tcnica de acceso (la forma en que son accedidos fsi-camente)sin afectar a la aplicacin de manera drstica. Por ejemplo, no sera posible reemplazarel ndice del ejemplo por un esquema de dispersin sin hacer modificaciones mayores a la apli-cacin.Lo que es ms, las partes de la aplicacin que requieren de alteracin en dicha situacinson precisamente las partes que se comunican con el software de administracin de datos; lasdificultades implicadas son irrelevantes para el problema que originalmente debera resolver laaplicacin; es decir, son dificultades presentadas por la naturaleza de la interfaz de administra-cinde datos.Sin embargo, en un sistema de base de datos, sera en extremo inconveniente permitir quelas aplicaciones fuesen dependientes de los datos en el sentido descrito; por lo menos por las dosrazones siguientes:1. Las distintas aplicaciones requerirn visiones diferentes de los mismos datos. Por ejemplo,suponga que antes de que la empresa introduzca su base de datos integrada hay dos aplicaciones A y B que poseen cada una un archivo privado con el campo "saldo del cliente". Sinembargo, suponga que la aplicacin A almacena dicho campo en formato decimal, mientras que la aplicacin B lo almacena en binario. An sera posible integrar los dos archivosy eliminar la redundancia, suponiendo que el DBMS est listo y sea capaz de realizar todaslas conversiones necesarias entre la representacin almacenada elegida (la cual podra serdecimal o binaria, o quiz alguna otra) y la forma en que la aplicacin desea verla. Por ejemplo, si se decide almacenar el campo en decimal, entonces todo acceso por parte de B requerir una conversin hacia o desde el formato binario.ste es un ejemplo muy trivial del tipo de diferencias que podran existir en un sistemade base de datos entre los datos como los ve una aplicacin dada y los datos como estn alma-cenadosfsicamente. Ms adelante en esta seccin, consideraremos muchas otras posiblesdiferencias.2. El DBA debe tener la libertad de cambiar las representaciones fsicas o la tcnica de accesoen respuesta a los requerimientos cambiantes, sin tener que modificar las aplicaciones existentes. Por ejemplo, es posible incorporar nuevos tipos de datos a la base de datos, adoptarnuevos estndares, cambiar las prioridades (y por lo tanto los requerimientos de rendimientorelativo), tener nuevos dispositivos disponibles, etctera. Si las aplicaciones son dependientes de los datos, estos cambios necesitarn por lo regular cambios correspondientes en losprogramas, ocupando as un esfuerzo de programacin que de otro modo estara disponiblepara la creacin de nuevas aplicaciones. Aun en la actualidad, es muy comn encontrar queuna parte importante del esfuerzo de programacin disponible, est dedicada a este tipo demantenimiento (imagine el "problema del ao 2000"!), lo cual por supuesto no es el mejoruso de un recurso escaso y valioso.De aqu que dar independencia a los datos sea un objetivo principal de los sistemas de basede datos. Podemos definir la independencia de los datos como la inmunidad de las aplicacionesa cambios en la representacin fsica y en la tcnica de acceso; lo que implica desde luego quelas aplicaciones involucradas no dependan de ninguna representacin fsica o tcnica de acceso 43. Captulo 1 / Panorama general de la administracin de bases de datos 21en particular. En el captulo 2 describimos la arquitectura de los sistemas de bases de datos queproporciona el fundamento para lograr este objetivo. Sin embargo, antes de eso consideremoscon mayor detalle algunos ejemplos de los tipos de cambios que el DBA deseara hacer y antelos cuales, por lo tanto, quisiramos que las aplicaciones fuesen inmunes.Comenzaremos por definir tres trminos: campo almacenado, registro almacenado y archivoalmacenado (consulte la figura 1.7).Un campo almacenado es, en general, la unidad ms pequea de datos almacenados. Labase de datos contendr muchas ocurrencias (o ejemplares) de los diversos tipos de cam-posalmacenados. Por ejemplo, una base de datos que contiene informacin sobre los dife-rentestipos de partes podra incluir un tipo de campo almacenado con el nombre "nmerode parte" y luego podra existir una ocurrencia de ese campo almacenado para cada tipo departe (tornillo, bisagra, tapa, etctera).Nota: En la prctica es comn omitir los calificadores "tipo" y "ocurrencia" y depen-derdel contexto para indicar a cul se hace referencia. Aunque existe un ligero riesgo deOtros archivosalmacenadosArchivo almacenado de"Partes", ARCHPBase de datos almacenada PesoNo. NombreColorde de departe partepartedeparteP1 Tuerca Rojo 12Dos ocurrenciasdel tipo de registroalmacenado "parte"Ocurrencias de campo almacenadoP2 Perno Verde 17No. Nombre Colorde de departe parte parteFigura 1.7 Archivos, registros y campos almacenados. 44. 22 Parte I / Preliminaresconfusin, esta prctica es conveniente y nosotros mismos la adoptaremos de vez en cuandoen el libro. (Esta observacin se aplica tambin a los registros almacenados. Vea el siguienteprrafo.) Un registro almacenado es un conjunto de campos almacenados relacionados. Una vezms distinguimos entre tipo y ocurrencia. Una ocurrencia (o ejemplar) de registro almace-nadoconsta de un grupo de ocurrencias de campos almacenados relacionados. Por ejemplo,una ocurrencia de registro almacenado dentro de la base de datos "partes" podra consistiren una ocurrencia de cada uno de los siguientes campos almacenados: nmero de parte,nombre de parte, color de parte y peso de parte. Decimos que la base de datos contiene mu-chasocurrencias del tipo de registro almacenado "parte" (una vez ms, una ocurrencia porcada clase de parte). Por ltimo, un archivo almacenado es la coleccin de todas las ocurrencias existentes ac-tualmentepara un tipo de registro almacenado. Nota: Por simplicidad damos por hecho quetodo archivo alm