SISTEMAS DE BASES DE DATOS THOMSON i [Australia = Canada » Espana © xtados Unidos» Mésco» Reine Unido Singapur ee‘Vicopresiden cecitoral y de produccién: Miguel Angel Toledo Castelsnos Editor da desarrollo: Pedro de la Garza Rosales ‘Tradueclén: Foodofo Navaro Salas ‘COPYRIGHT ©2004 por Intornational Thomson Editors, S.A. de. V, una dvsién de ‘Thomson Lenming, Ine. ‘Thomson Leaming™ es una marea tagisvada usada Bajo permiso. Impreso en México Printed in Mexico 1294050003, Para mayor informacion contéctenoe Séneca 53 Col Polanco Ménco, DF, 11580 Puede visitar nuestro sito en ‘tp swwetnemsonlaaring com me ‘Sistemas de bases de datos, 52. Ed. Oise implementacien y admisiacién Petar RobiCarios Coronel Gorente de produecién: Fons Garay Argueta Editor de producclén: ‘Ama Castején Alcocor ‘Supervisora de manufacture: Claudia Calderon Valderrama DERECHOS RESERVADOS. ‘Queda prohiida la reproducciin 0 transmisign total o parcial de texto e la presente otra alo ‘cualesquora formas, electrérica © ‘mecénica. inuyendo lotocopiado. ‘almacenamiento en algun sistema, ‘e recuparacién de Inlormacén, © ‘grabado sin et consersimionto revo y por escxto del edior. Divisién Iberonmertcana Revision técnlca: Marea Antonio Dorantes Gonzalez y Martha Rosa Cordero Lopez ‘Amos dol IPN-Escucla Superior ¢ Compute ‘Traducida dl ibro Database Systems ‘th, Design Implementation and ‘Management pubicado on inglés por Course Technology, © 2002 ISBN 0-619-06269-X Dios para caialogacion boliogiica: Reb, Petr. Coronel, Carlos. ‘Sistemas de bosas de datos, Sa. edb. Disef, implementa y adminstrecion ISBN 970-086-286-2 1. Sistemas da basos de datos 21 Disoto, mpiemartacion y adm ntractén. México y América Central ‘Thomson Learning Seneca 53 ot, Polanco Mérleo,D. F., 11560 “el (52 55) 5261 29 05 Fax (52 59) 5281 20 56 ‘ecitor@inamsonlearning com.mx Eicoribe “Thomson Learing 598 Aldebaran ‘Atami, San Juan Puerto Reo 2p Code 00920 Tel (787) 641 11 12 Fax (787) 641 1119, ‘Cono Sur Buenos Als, Argentina thomsen @thomsanlearning com.ar Améries del Sur ‘Thomson Learsng Cala 39 No, 24.03, La Soledad Bogolt, Colombia “al. (S71) 340 94 70 Fax (571) 340 94 75 Ciente@ thomsonleaming com.co Espana ‘Thomson Learning Cale Magatanes 25 28015 Mesna Expene Tel 34 (0101 446 33 50 Fax 24 (0)01 445 62 18 lentes @paraninto.es to obra se termine imprimir on agosto de 2003, €0 Litogrtiea Ingramex. 5.4, de CV. Centeno 162-1 Col. Granjas Esmeralda Mico, DAEen Para Anne, quien desputs de cuarenta afios de matrimonio sigue siendo mi mejor amiga. Para nuestro hijo, Peter Wiliam. que se convirtié en el hombre que esperdbamos legaria a ser y que demostré su sabiduria al convertir a ‘Sheena en vestra nuera que es un tesoro, Para nuestros nietos Adam Lee y Alan Henri, que van en camino de convertirse en los fnos sores humanos ‘que son sus padres. Para mis parientes politicos, Henri y Nini Fontein, cuyas ‘experienclas de vids en Europa y el Sureste Asitico llenarian un libro de his- toria, quienes me confaron el fururo de su hia, y quienes son una parte muy precads de nuestros vides. A la memoria de mis padres, Hendrick y Hermine Reb. que reconstruyeren sus vidas después de Jos horrores de {a Segunda Guerra Mundial, que lo volvieron a hacer después de una falda rebelion en Indonesia y que finalmente encontraron su tierra prometida en ‘estos Estdot Unidas. Y a la memoria de Heinz, que mo ensefé lecciones arias de leakad, acoptacién sin criicas y una iimitada comprension, les dedico este libro, con amor. Peter Rob Para mis padres por mi educacién. Para mi bella esposa, Victoria, quien siempre me allenta para que no desfallezca durante fas interminables horas de escritura. Gracias por se tan carifiosa y por estar alli en la mayoria de los ‘momentos de prueba. Para Carlos Anthony, mi hijo, que es el orgullo de su padre y que siempre me ensefia algo nuevo, Para Gabriela Victoria, mi hija, ta princesa de ta casa, Para Christian Javier: nuestro nuevo mativo de rego- Gio. A mis hijos, gracias por sus rsas, sus dulces voces, sus hermosas sonrisas y sus frecuentes abrazos. Los amo, ustedes son mi divino tesoro, Carlos CoronelGeter) PARTE |, CONCEPTOS OF BASES DE DATOS CCapleulo |: Sistemas de archivos y bases de datos Capitulo 2: Modelo de base de datos relacional PARTE Ili CONCEPTOS DE DISENO ¥ OE EJECUCION Capleulo 3: Modelado de Entidad-Relacién (E-R) ‘Capieulo 4: Normalizacion de tablas de bases de datos Capleulo 5: Lenguaje de Consulta Estructurado (SQL) PARTE lilt OISERO V EJECUCION AVANZADOS Capitulo 6: Disetio de bases de datos Capitulo 7: Laboratorio universitario: diseto concepaial Capitulo 8: Laboratorio universiario: vrificaclén del dsefo conceptual disoho logico y ejecucion. PARTE Iv: CONCEPTOS AVANZADOS DE OASE OF DATOS, CCapiuulo 9: Adminisracién de transacciones y control de concurrencia Capitulo 10: Sistemas de administracion de bases de datos dstribuidas PARTE Vi NUEVOS DESARROLLOS: ‘Capitulo 1: Bases de datos orientadas a objetos ‘Capieulo 12: Sistemas clientelservidor Capieulo 13: B almacén de datos CCapinulo 14: Bases de datos en el comercio electrénico Capieulo 15: Desarrollo de bases de datos en la web [Sener eSrSeRSen | PARTE Vii ADMINISTRACION OF BASES DE DATOS Capleulo 16: Administracién de bases de datos APENDICE GLOSARIO, Tnoicece PREFACIO xv! PARTE |: CONCEPTOS DE BASES DE DATOS SisTEMAs DE ARcHIVes ¥ BASES DE DATOS et 3 | Introducclén a las bases de datos & LLL Por qué es imporsance el dseiio de una base de datos? 9 [LZ Unacereamiento al diet de bases de datos 9 112 Races histérleas de Ia base de datos: archivos y sistemas de archivos 9 1.3 Critica al sistema de archivor 13 13.1 Admingwacion de dacos de ssomas de archivos 13 132. Dependencia estructural y en los datos. 1S 1.33 Definciones de campo y convenciones para dar nombre 15 134 Redondancl de éstos 16 1. Sistemas de bases de datos 17 TAL Ambiente del satema de bases de datos 18 142 Tipos de sisremas de administracion de base de datos 20 143. Funciones de.un sistema de administraclon de base de datos 21 1444 Adminiseracin dat sistema de base de datos 23 145 Diseto y modclado de bases de datos 23, 1.$ Modelos de base de datos 23 15.1 Modelo de base de datos jerirquico 24 1152 Modelo de base de dator de red 29 153 Modelo de base de datos relacional 32 154 Modelo de datos de relacign de entidad 36 155 Modelo de base de dator orientada a objecor 39 1.6 Conclusion: evolueién de los modelos de datos 42 16.1 Modelos de base de dhtos e internec 44 Resumen 45 ‘Términos clave 49 Preguntas de repaso 50 Prablemas 5! [EAPITULS2) MooELo oF BASE DE DATOS RELACIONAL Avance 57 2.1 Una visi6n Wigica de lor datos 58 DULL Endidades y atribucos 58 212 Toblasy sus caracteristeas 59 22Claves 62 123 Reglas de integridad revisitadas 68 24 Operadores de base de datos relacional 70 15 Diccionario de datos y el catdlogo de sistema 76 2.6 Relaciones dentro de la base de datos relacional 78 2.7 Redundancia de datos revisitada 88Términos clave 92 Preguntas de repaso 93 Problemas 95 PARTE 11: CONCEPTOS DE DISENO Y PUESTA EN EJECUCI [EAPITULG 3} © MoDeLADO DE LA RELACION DE ENTIDAD Avance 109 3.1 Conceptos de modelado bisieos 110 3.2 Modelos de datos: grados de abstraccién de datos 111 321 Elmodelo conceptual 111 322 modelo imerna 114 323 Bmodeloenerno 116 324 modelo fico 118 3.3 Modelo de Entidad-Relaclén (E-R) 119 331 Emeidades 119 332 Acrbutos 119 333° Relaciones 124 3.34 Conectividad y cardnabdad 124 335 Fuersadela recon 126 33.6 Partcipaclén de a relacién 130 337 Fuerza dela reacién 133 338 Grado dela roheién 135 33.9 Emidades compuestas 140 3.3.10 Supertiposy subupos de encdad 143 3.4 Comparacién de los simbolos de modelado E-R 146 3.8 Desarrollo de un diagrama E-R 149 3.6 El rato del disefio de bases do datos: objetivos conflictlvos 157 Resumen Términos clave 160 Preguntas de repaso 160 Problemas 163 NORMALIZACION OF TABLAS DE BAKE Of DATOS Avance 175 4.1 Tablas de base de datos yntormalizacion 176 All Lanacesdad de a normalzacion 176 4.12 Conversién 2 primera forma normaliada 179 4.13 Conversién a segunda forma normalizds 182 414 Conversién a tereera forma normallzads 183, 4.15 La forma normalzada de Boyce-Codd (BCN) 188 4.2 Normalizacion y disefio de bases de datos 191 3 Formas normalizadas de alto nivel 195 4A Desnormalizacién 196 Resumen 197Términos clave 200 Preguntas de repaso 201 Problemas 201 Lenauase € CONSULTA esTRUCTURADO ‘Avance 209 5.1 Introducelén a SQL_ 210 5:2 Comandos para deficién de datos 211 52.1 Modslode tate de dator 211 $2.2 La toblany Componentes 21) 523. Creacénde'a base de door y extuctras de bia 213 524 Creaclon de etructras de bla 213 525 Udlincon de dominios 219 526 Renrciones de Integdoden SQL 721 5. Comandes de manipulactin de datos 222 521 Emrads do dator 222 532 Guardando al contenido de una abla 224 5213 Poriendo en ita et contenido de una tbl 224 534 Hacienda una correcin 226 535 Rexavrande e contenido de ura tbls 226 5.26 Eiminando fits de abl 226 5A Consultas 227 SA. Lisae porches de comenido de una abla 227 542 Operadores l6gicos:And,Or y Not 233 543 Operadores especiales 235 55 Comandes de administracién de datos avanzados 238 55.1 Camblando el po de datos dew colin 238 552 Cambando ls cractertiess den arbi 239 553° liminando una columna 240 SSA Ieroducendo dos en fs neva cola 240 5.5.5 Operadores arieméticos y la regia de precedencia 242 556 Coplando parte de ales 243 55.7 Eliana una abla dea bate de dator 244 558 _Desigmcién de clveprari yextranjers 245 5.6 Consultas mas complejasyfunciones SQL 245 561 Ordenandolieas 245 542 Ponendo enlita alres dnicos 248 543 Funclones do apreacin en SQL. 249 S64 Agrupando ator 254 S45 Tabs vrtale Creando ura vita 256 566 Indes SQL 258 567 Uniendo bs de bases de dacos 258 5:7 Vistas actualzables 263 5.8 SQL de procedimientas 266 581 Actadores 267 582 Procedimienor uardados 275 583 Funciones ardhéss PUSOL 278 5,9 Conversién do un modelo E-R en una estructura de base de datos 278 5.10 Reglas bisicas que rigen las relaciones entre tablas 263 Resumen 293 Termings clave 298 Preguntas de repaso 299 Problemas 102PARTE I!1: DISENO AVANZADO Y PUESTA EN EJECUC! DiseRo OF Bases oF GATOS Avance 319 6.1 Conversién de datos en Informacién 320 6.2 E1 sistema de informacion 320 6.3 Ciclo de vida del desarrollo de sistemas 322 63 PhanMeacién 322 632 Anis 323 633 Disco de sistemas deullada 324 634 Pesta en elecucién 324 635 Mancenmienco 325 64 Cielo de vida de una base de datos (DBLC) 325, 64.1 Estudio incial de una base de datos 330 642 DlseRo de bases de datos 45 643 Puesta en elecuckin y carga 349 644 Pruebas evaluaciones 350 64S Operacién 350 646 —Mancenimienco y evohucién 350 65 Nota especial sobre estrategias de disefio de bases de datos 350 6.8 Diseo contralizado contra descentrallzado 351 Resumen 354 Términos clave 356 Preguntas de repaso 356 Problemas 358 EAPITULOT] EL LABORATORIO UNIVERSITARIO: DISERO CONCEPTUAL Avance 159 7.1 Estudio inical de una base de datos 360 ‘Objetios UCL 361 Estructura organizational 261 Deseripcion de operaciones 363 Probiemas y resvicciones 367 Objerivos de sistema 369 71.6 Alearceylimitaciones 370 7.2 Fase de diseflo de una base de datos disefio conceptual 372 72. Fuentes de intormacién y usuarios 372 722 Necesidades de informacin: requerimlentos de los usvarios 374 723 Desarrollo del modelo de relaci6n de entdad incial 376 Resumen 389 Términos clave 390 Preguntas de repaso 390 Problemas 391 EAPIFULOE] EL LABORATORIO UNIVERSITARIO: VERIFICACION DEL DISERO CONCEPTUAL, OISERO LOGICO Y PUESTA EN EJECUCION Avance 397 8.1 Terminacién de los disefios conceptual y léglco de bases de datos 3988.2 Terminacién del disefio conceptual: entidadet, atributos y normallzacién 399 B21 Médulo de sistema de administracién de un lboratorio 400 82.2 Médulo de administacién de invenarios 412 8.3 Verifeacién del modelo E-R 432 B.A Dis légico 439 B41 Tablas 439 842 — Indicesy visas 441 BS Disefo fsico 442 6 Puesta en ejecuclin 444 86.1 Creaclén de bases de datos 447 862 —Cargry comversién de bates de datos 447 863 Procedimientos de sistemas 447 8.7 Pruebas y evaluaciones 448 87.1 Medidis de desempeto. 448. 872 — Medidas de seguridad 448 87.3 Respaldo y procedimientos de recuperaciin 449 BB Operacin 449 8.8.1 Base de datos operauva 449 8.0.2 Procedimlentot de operacién 449 3 Adminstracin de bates de datos Resumen 450 Términos clave 451 Preguntas de repaso 451 Problemas 453 aneenimiento y eveliclén 450 PARTE IV: CONCEPTOS DE BASE DATOS AVANZADOS. [EAPITULO'S] © ADMINISTRACION OF TRANSACCIONES Y CONTROL DE CONCURRENCIA Avance 459 9.1 {Qué es una transaccion? 460 9.1.1 Evahueién de los resulados de una transaccién 461 9.12 Propicdades de una transaccién 462 9.13 Adminiseracion de trantacclones con SQL 463, 914 Regletro de ung eransacdén 463 9.2 Control de cuncurrencia 464 921 Actualzactones perdidas 465 92.2 Datos no compromeddes 466 923 Recuperaclones inconsstences 467 924 Elplanifcadar 468 9.3 Control de concurrencia con métodos de bloqueo 469. 93.1 Granulaidad de bloques 469, 932 — Tipos de bioqueo 472 93.3 Bloqueo bifislco para garantzar fs serlabildad 474 934 —Incerbloqueos 475 19.4 Control de concurrencia con métados de Impresién de hora 476 9.5 Control de concurrencia con métodos optimistas 476 19.6 Administracién de la reeuperacién de bate de dator 477. 9461 Recuperacién de transacciones 478Resumen 479 ‘Términos clave 481 Preguntas de repaso 481 Problemas 482 SISTEMAS DE ADMINISTRACION OE BASES OE OATOS OISTAIBUIOAS Avance 485 10.1 Evolueton de sistemas de administraclén de bases de datos distribuldas 486 0.1.1 Ventas de un DDBMS 487 10.12 Desventajas de un DDBMS 488 10.2 Procesamiento distribuido y bases deviatas distribuidas 488 10.3 Qué es un sisterna de bare de datos distribuida? 491, 10.4 Componentes de un DDBMS 493 10.5 Niveles de distribucion de tos datos y procesos 494 105.1 Procesamientos en un solo sho, dates en un solo sitio (SPSD) 494 1052 Procesamiento on varios sitios, datos on un solo slo (MPSD) 495. 1053 Procesamiento en varios sitios, datos en varlos sitios (MPMD) 497 10.6 Caracteristicas de transparencia de base de datos distribuida 498 10.7 Transparencia de una distribuctén 499 10.8 Transparencia de una transacclén 501 108.1 Soliciudes y transacelones dstribuldas $01 1082 Control de concurroncia distrbuida 505 1083 Protocolo Commi bifisico 508 10.9 Transparencia de desempefio y optimizacién de consultas $07 10.10 Disefo de una base de datos distribuida S08 10.11 Fragmentacién de datos $08 0.11.1 Fragmemacién horizoneal $09 10.1.2. Fragmenacion verdes! 510 0.11.3 Fragmentacion combinsda 510 10.12 Replicacién de datos 512 10.13 Colocacién de datos 513 10.14 Clientelservidor vs. BDBMS. 514 ¢ }$ Doce mandamientos de CJ. para bases de datos distribuidas 514 Resumen $15 Términos clave 516 Preguntas de repaso S17 Problemas 518 PARTE V: DESARROLLOS NUEVOS ‘Avance 525 I.E Orfentactin a objetos y sus beneficios 526 11.2 Evoluetén de los conceptos orientados a objetos 526 113 Conceptos orientados a objetos 527 113. Objetos: componentes y earacerstcas 527 32 Objeteridentdad $281133 Atibutos (variables de Insancia) 528 Estado de objeto $30 Mensajes y métodos 530 Chases 533 Prococolo 533 1138 Superclases, subeases y herencia 534 11.39 Anulacign de método y polimorfsmo 537 113.10. Tipos de datos abstractos 538 IBA Clasifiacion de ebjecos 539 11.4 Caracteristicas de un modelo de datos orientado a objetos 540 LAL Esqueras de objeto: representacién grifia de objetos $41 NA2 Relaciones clase-subclase 544 1143 Atributo de relaciones interobjeto: vinculos atrbuto-clase $45 1144 Asignacin tardia y antcipada: uso e imporancia 582 14S Soporte para determinacién de version 554 11.5 OODM y modelos de datos previos:similitudes y diferencias 554 115.1 Objero.encdad y tuple 554 1152 Chase,encidad,conjunco y abla 585 1153 Eneapsuldo y herencia 555 NNSA IDde objewo 556 , 15S Relaciones 556 : 1156 Acceso 556 1.6 Sistemas de administracién de bases de datos orlentados a objetos 557 116.1 Caraceerisias de un DBMS oriontado a abjotos 559° 11.7 Cémo afecea la orientacién a objetos el dizefio de una base de datos S61 11.8 OODBMS: ventajas y desventajas 562 1,9 Cémo han Influldo los conceptos de orlentacion a abjetos en el modelo relacional $64 11.10 La siguiente generacién de sistemas de administracion de bases de datos 565 Resumen 566 Términos clave 567 Preguntas de repaso S67 Problemas S68 EAPITULO Ta] SisTeMAs CLIENTE/SERVIDOR Avance $13 12.1 ;Qué es ta computacién clientelservidor? 574 12.2 Fuerzas que impulsan la tendencia a sistemas cllente/servidor 575 12.3 Evolucion de sistemas de informacién clientelservidor 576 I24 Expectativas admninistrativas de los sistemas clientelservidor $77 124.1 Expectacvas de la administracion de sistemas de informacién (MIS) sobre los benefcio elenteltervidor 578 1242 Expectativas organizaionales de los bencficioselienceservidor 576 125 Arquitectura clientelservidor $79 125.1 {Cémo inceractdan los componentes? 579 1252 Principios diencelservidor 581 1253 Componentes declente 582 1254 Componences de servidor 583 1255 Componente de middleware de comunicaciones 586 125.6 Protocolos dered $90 125.7 Componentes de middleware para bate de datos $91 1258 Chasfieaciones de middleware 595 12.6 Bésqueda de estindares 595 12.7 Bases de datos para cllentelservidor $97 12.8 Estilos de arquitectura clientelservidor 59812.9 Temas sobre puesta en elecucién clientelservidor 602 129.1 Clientalservidor contra procesamiento de datos tradicional 603 1292 Consideraciones gerencisles 604 129.3 Herramientas de desarrollo clentelservidor 606 1294 Enfoque incegrado 606 Resumen 607 Términos clave 608 Preguntas de repaso 609 EAPIFULO TS) ALmactn ve patos Avance 611 13.1 Necesidad det analisis de dator 612 13.2 Sistemas de soporte de decisiones 613 132.1 Datos operatvos conera datos para soporte de dacistones 613 13.22 Requerimientos de base de datos para sistema de soporte de decisiones (DSS) 615. 1333 Almacén de datos 622 133.1 Estilos arquteeténicos de sistemas de soporte de decisiones 626 1332 Doce reglas que definen un almacén de datos 626 134 Procesamiento analitice en linea (OLAP) 628 134.1 Arquitecura de OLAP. 631 1342 OLAP relacional 635 1343 OLAP mukidimersional 638 1344 OLAP relactonal vs. multidimensional 640 13.5 Esquemas en estrella 641 135.1 Hechos 641 1352 Dimensiones 642 1353 Atibutos 642 1354 Jerarquis de atributos 645 1355. Repreteneacién de exquema estratis 646 1256 Téenleas de mejors de dosempofo 649 13.6 Puesca en ejecucién de almacén de datos 652 , 136. Aimacén de datos como mareo de referenda de soporte de decisiones activo 652 1362. Esluerzo a nivel de coda la compari que requiere la intervencién de los usuarios y compromiso fen todos los nveles 652 1363. Sauisfacdén de la wilogia: dacs, anil y usuarios 652 1364 Apliacion de procecimnientos de diaeio de baso de datos 653 137 Laboreo de datos 654 Resumen 658 Términos clave 659 Preguntas de ropaso 660 Problemas 6 [CAPITULO 14] Bases De DATOS EN EL COMERCIO ELEcTRONICO Avance 667 14.1 {Qué es el comercio electrénico? 668 14.2 Camino al comerclo electrénico 669 143 Impacto del comercio electrénico 669 143.1 Boneficios del comercio electrénico 669 1432 Desventajas dl comercio electénico 670 144 Estilos de comercio electrénico 670 145 Arquitectura del comercio electrénico 671 145.1 Servicios bisicos de internet 673,14$2 Servicios que permiten transacclones de negocios 675 145.3 Servicios para lo reaizei6n de transacciones de negocios 677 146 Seguridad 677 147 Procesamiento de pages 679 147.1 fective digital 679 147.2 Procesamiento de erjeas de crédito 680 147.3 Bileeras electrénieas 681 14.8 Disefio de bases de datos para aplicaciones de comercio electrénico 681 149 Lenguale de marcado extensible (XML) 692 149.1 Defniciones de tipo de documento (DTD) y esquemas XML 694 1492. Preseatacién XML 656 1493 Aplicaciones XML_ 699 Ratumen 701 mings clave 702 Preguntas de repaso 702 Problemas 701 DESARROLLO DE BASES DE DATOS EN LA WEB Avance 705 ¢ 15.1 Tecnologias Internet y bases de datos 706 15.2 Usos tipicos de bases de datos en Internet 707 15.3 Middleware de web a base de datos: extensiones del lado del servidor 707 15.3. Incerfaces de servidor web 709 1532 Conecdvidad de base de datos ablerts (ODBC) 711 15.4 Explorador web 713 1S4.1 Excenslones del lado de! cliente 713 15,5 Utilizacién de una herramienta de produccién de web a base de datos: ColdFusion 714 155.1 ¢Cémo funciona ColdFusion! 715 155.2 Bate de datos RobCor de muestra 716 1553 Creacién de una consulta semple con CFQUERY y CFOUPUT 71 1554 Crencién de una consulta simples con CFQUERY y CFTABLE 722 ISS Creacién de una pigina de bisqueds dindmica 724 155.6 Laweb como un sistema sin estado 729 185.7 Interclén de datos 730 155.8 Actualzaclones de datos 735 1559 Eliminacion de daeos 741 15,6 Sistemas de bases de datos en internet:consideraciones especiales 746 15.6. {Qué tipos de datos son sopertados? 747 15.62 Seguridad de los datos 748 1563 Adminitracién de transacciones 748 1564 Dernormallzci6n de tblas de base de datos 749 Resumen 750 ‘Términos clave 750 Preguntas de repato 751 Problemas 751PARTE VI: ADMINISTRACION DE BASES DE DATOS ADMINISTRACION DE BASES DE DATOS Avance 755 16.1 Datos come active dena corporacién 756 16.2 Necesidad de y rol de las bases de datos.en una organizacion 757 16,3 Introduccién a una base de datos: consideraclones especiales 758 16.4 Evolucién de la funcién de administractén de las bases de dator 759 16,5 Componente humano en al amblente de las bases de datos 763, 16.1 Rol gorencial del DBA (administrador de base de datos) 766 1652 Rol theico del DBA (administrador de bate datos) 772 16,6 Herramientas de administracién de base de datos 778 7 166.1 Diccionario de datos 778 166.2. Herramientas ingenieria de software asistidas por computadora (CASE) 780 16.7 Desarrollo una estrategia de administracion de datos 783 16.8 1 DBA trabajando: utlizacién de Or la administracién de bases de datos 785 168.1 Herramiontas de administracion de bases de datos Oracle 786 1682 Inicio de sesién predeterminado 786 1683 Asegucamianto del inicio auromstico de un sistema de 2dmlniseracién de base de datos relzcional (RDBMS) 787 1684 Uslizaci6n det administrador de almacenamiento para crear espacios de tabla y archivos de datos 788, 1685 _Adminseracion de objetos de base de datos: tabas vistas, actvadores y procedimlemtos 790 1686 —Adminseracién de usuarios y establecimiento de seguridad 794 1687 Personalizacién de los parimetros de inkialaaci6n de una base de datos 795 1688 —Creaclén de una tase de datos nueva 795 Resumen 798 Términos clave 799 Preguntas de repaso 800 INPRARSTRUCTURA DE AED CLIENTE/SERVIDOR Avance 803 Cableado de redes 804 Topologia de redes 804 Tipos de redes 806 Dispositivos de comunicaciones de red 807 (ineiez] 829Garg) Esta quinta edicién continda el tema de las exitosas primeras cualro ediciones. Esto es. continuamos prove yendo fundanentes précticos y soldes para el disefo. puesta en cjecucién y administracién de sistemas de tuases de datos. Constniimos estos fundamentos sobre la nacin de que, si bien las buenas bases de datos son ‘muy précticas, su creacién exitosa depende del conoximienlo de los importantes conceptes que las definen. No es féei! conseguir la combinacién apropiada de teoria y préctica. no obslante, agradecemos los comen- taros de Jos usuarios de ediciones previas, nuestros estudiantes y muchas de las evehuaciones de lo quinta cedici6n sugieren que hemos alcanzado un gran &xito en nuestra bisqueda del equilrio apropiado. EE ICEE NIN) En esta quinta edicién, continuamos con Ia cobertura del disefo de bases de datos y de temas actuales detala- dos. Sin embargo, un sinntimero de sugerencias de usuarios de la cuaria edicién y nuestra propia experiencia como profesores y practicantes, han dictado cambios que van desde menores hasta sustanciales. E] impacto de internet en E6mo se disefian, ejecutan y ulilizar las bases de datos esté reflejado on los temas incluidos en esta edicién. Adems, algunas consideraciones de disefio de bases de datos précticas nos obligaron a adoptar el modelo de pata de Gallo para desarrollar disefos de bases de datos. EI nimero de problemas de disciio de bases de datos, importante en la cuarta edicién, sc ha incrementado y algunos de los problemas agrogados abren una pucrta a través de la cual podemos examinar algunos de los engorrosos temas de dlsefio del mundo real. Aunque se actualizaron todos los capiiulos, algunos se somcticron a revisiones mayores y agregamos tun capitulo nuevo para mantener la cobertura actuaizada. + Elcapitulo 5 "Lenguaje de consulta estructurado (SQL. incluye una cobertura mis amplia. En Ta cuarta ‘ediciSn agregamos activadores y procedimientos guardados, y sefialamos que estas funciones hacen que ‘SQL sea verdaderamente dil, Ein esta quinta edicién, agregamas una seccién sobre las reglas generales ‘que rigen las rclaciones entre tablas. También agregamos una seccion en la que exploramos como un. ‘modelo de entidad-relacién se transforma en ua estructura de base de datos. Sin embargo, nos asc- suramos de que la cobertura ampliada no afecte a los usuarios que prefieran paser por alto este capitulo para enfocar su atencién en otros aspectos de disefio, ejecucién y administracion de bases de datos, La Mlexibitdad de la cobertura continiéa siendo wn importante aspecto de este libro. + Elcaptulo 9 “Administracion de transacciones y control de concurrencie”. sulié varias revsiones int pportantes: por ejemplo, la nueva seccién 9.6.1 en la que se presentan los detalles de la recuperacién de transecciones. + Se agregé un nuevo capitulo el capitulo 14 “Bases de datos en el camercio electrénico”. Organizaciones ‘que van desde insttuciones educatives hasta firmas comerciales de todos los taniaitos v agencias guber ‘namentales en todos los niveles han abrazado el e-commerce como tna forma dle comercalizar ss pro" ductos y servicios. Por consiguiente, conviene examinar los componentes del ambiente de transacciones comerciales electr6nicas y explorar fa forma en que los requerimtentos para la tealizecién de trans: acciones electronicas comerciales afectan el disco de bases de datos de produccién. Esta adicién agrega un valor a la cobertura de bases de datos. + Elcapriio 14 de fa cuarta edicién se convitié en el capitulo 15 y fue renombrado “Desarrollo de bases de datos en la web” para reflelar su enfoque. Este capitulo explora el efecto que tiene Internet en el di sefio de bases de datos, asf como algunos temas de ¢jecucién, El capt 15 continia nuestra tradicion de bases de datos de intervencién directa. que le muestra cémo uilzar una poderosa, aunque facil de aprender y ttlizar, herramilenta de desarrallo de aplicaciones para internet conocila como ColdFusion + Aunque et capitulo 15 de la cuarta edicién, “Administracién de bases de datos”. fue renumerado como capitulo 16, su enfoque préctico se mantiene en la seccién 16,8. “El DBA trabajando: uso de Oracle ppara la administracién de bases de datos". En esa seccién, mostramos qué herramientas de adminis- {racién de bases de datos estén disponibles, cémo ullizar cl procedimiento de inicio de sesién. c6mo $2‘crean las estructuras de base de datos —espacios de tabla y archivos de datos— cémo se administran los objetos de base de datos, como se crea y administra cl amblente de seguridad, c6mo se personalizan los pardmetros de iniclalizacién de una base de datos y cémo se crea en realidad una base de datos. ‘Como la cobertura se ha ampliado significativamente, los detalles de varios temas se colocaron cn el sitio web Course Technology, wuw.course.com (busque el ISBN: 0-619-06269- de este libro). El icono de contenido en linea (Online Content) indica tal matertal. EEN ies Ear [Nuestra quinta edicion refleja comentarios y sugerenclas hechas por los usuarios de nuestra cuarta edicion y por varios revisores que examinaron nuesttos extensos esfuerzos de reescritura. Ademés, lenemos revisores ‘estudiantes muy importantes en quienes se puede confiar como retroalimentadores ‘tiles sobre qué es lo que 1da.0 no resitado en el salén de cases. Como profesores, continuamos descubriendo inajores maneras de lo- ‘grar nuestros objetivos y descubrimos que, a pesar de la edicién y revisién cuidadosas que precedieron a la cuarta edicién, huibo algunos errores de omisiém y comisién que requirieron soluci6n. El avance de la tecno- Togfa de base de datos requiri6 que abordéramos temas nuevos y que tratéramos algunos de los temas “viejos” de una manera diferente. Por titimo. con la puesta en prictica de nuestra pericia en bases de datos, encontra- ‘mos mejores maneras de desarrollary ojecutar algunos de los disetios y de explicarlas mejor a otros. En suma, la experiencia dict6 muchos cambios considerables en la cobertura y la adicion de soporte, Como su titulo lo sugiere, Sistemas de bases de datos: diseio, efecucién y administractén, trata tres amplios aspectos de ls sistemas de base de datos. Sin embargo, creemos que los aspectos précticos del dsefio y ejecu- cin de sistemas de base de datos merece una atencién especial por varias importantes razones: + La disponibilidad de excelente software de base de datos permite que. incluso. las personas sin expe- riencla en bases de datos creen bases de datos y aplicaciones de bases de datos. Desafortunedamente, el enfoque de “crear sin diseftar” en general provoca numerosos desastres de bases de datos. En nues- tra experiencia, muchos si no es que la mayoria de las fallas de sistemas de base de datos. son el resultado de un disefio deficiente y no pueden ser resueltos sin la ayuda de los mejores programadores y administradores. Ni el mejor software de DBMS puede vencer los problemas creados 0 magnifca- dos por un disefio deficiente. Utiizando una analogia, incluso los mejores albafiles y carpinteros rno pueden construir un buen edifcio con base en planos defectuosos. + La mayoria de los problemas de administracion de sistemas de base de datos realmente engorrosos, parecen ser provocados por bases de datos deficentemente disefados. Dificimente valdria la pena consumir los escasos recursos para desarrollar habilidades de administracion de sistemas de base de datos, para ejeritarlas en crisis que provocan las bases de datos mal diseadas, ‘+ Eldisero tambien proporciona un excelente medio de comunicacién. Es mucho mis probable que los lentes obtengan lo que necesitan cuando el disefio del sistema de base de datos se diseia con cuidado. inteligencia. De hecho, los clientes pueden descubrir c6mo funeionan en realidad sus orgenizactones tuna vez que se completa un ben disefo de base de datos. + El conocimiento de técnicas de disefio de base de datos promueve la comprensién de las teenologtas de base de datos actuales. Por ejemplo, como los almacenes de datos toman muchos de sus datos de bbases de datos operativas. los conceptos de almacén de datos, estructuras y procedimientos fienen _mis sentido si se entiende la estructura y ejecucién de la base de datos operativa.En summa. el disofio de bases de datos, de ser un refinamiento te6rico, es una actividad eminenterente précti- ‘ca que justiica fp cobertura a fondo que le hemos dado. Come se enfatizan los aspectos précticos del dsenho de bases de datos, hemos tratado a detalle los conceptos ¥ procedimientos de diseio y nos hemos asegurado de que los numarosos problemas al final de cada capinulo sean lo suficientemente desafiantes para que los estudiantes adquieran conocimicntos de disefio dtiles y reales. ‘También nos asequramos de que los estudiantes entiendan los conflictos potenciales y reales entre la elegancia dal disefio de bases de datos. los requerimientos de informactn y Ja velocidad de procesamientos de trans- acciones. Por ejemplo, no tiene mucho sentido discfar bases de datos que setisfagan estindares de elegancia sino satisfacan las necesidades de informacion del usuario final. Por consiqulente, exploramas el uso de cam bios cudadosamente definides para garantizar que las bases de datos scan capaces de satlsfacer los requert ‘myentos del usuario fnal, al mismo tiempo que satisfacen altos estindares de disci. CES Bi titulo de nuestro libro comienza con Sistemas de bases de datos: por consiquiente, examinemos los con- ceptos de base de datos y disefio en los capitulos del 1 al 5, como parte de un todo més grande. ya que los situamos dentro del marco de referencia del andlss de sistemas del capitulo 6. Creemos que los disehadores de bases de datos que no entienden que la base cle datos es una pieza de un s'steme mAs grande, probable riente pasen por alto los importantes requerimientos de disefio de bases de datos. De hecho, el capitulo 6 pro- porciona el mapa para el dsefio avanzado de bases de datos que desarrallamos en los capitulo 7 y 8. Dentro el marco de referencia de sistemas ms grandes, también exploramos temas tales como "Adminisiracién de transacciones y conltol de concurrencia” (capitulo 9), “Sistemas de administracion de hases de datos cistri- buidas" (capitulo 10), “El almacén de datos” (capitulo 13), "Bases de datos en el comercio electronica” (capitulo 14)y “Adeninistracion de bases de datos” (capitulo 16). El primer elemento en el subttulo del libro es Disefio. y nuestro examen de éste es amplio. Por ejemplo, of capitulo 1 ilustra la necesidad del disefo: el capitulo 2 sienta las bases para el modelo de base de datos re- lacional; el capitulo 3 proporciona una extensa y detalada cobertura del diserio préctico de bases de datos y ‘al capitulo 4 esta dedicado en su totalidad a temas de normalizacién crficos que alectan la eficiencia y efec~ tivided de las bases de datos. El capitulo 5 muestra cémo se ejecuta el disefto de bases de datos: of capitulo 6 ‘examina el disefio de bases de datos dentro del marco de referencia de sistemas y traza las actividades reque- ridas para diseftar y ejecular con éxito las complelas bases de datos del mundo real que desarrollamos en los capitulos 7 y 8. Estos antecedentes también permiten que el estudiante entienda Ia detallada cobertura del diseio de almacenes de datos en el capitulo 13, CConsiderando que ol modelo de base de datos afeca el dseio de bases de datos, examinamos a fondo los prin- cipales modelos de bases de dates: por ejemplo, nuesra cobertura del madelo relacional dominante comienza al final del capitulo 1 y se amplia en el capitulo 2. Los captuios 3 y 4 complelan las tecnicas de dsero y control de calidad que conducen a exitosos disiios de bases de datos. La cobertura del lenguafe de consulta estructura- doen el capitulo 5, demvestia el poder de consulta del modelo relacional. Hl captulo 10 se concentra en los sis- temas de administracién de bases de datos dstribuidos. Proporcionamos una cobertura detallada de las bases se dotos orientaias a objlos en el capitulo 12, mientras qv los sistemas cliente/servidor se tratan a foro en cl capitulo 12, El capitulo 13 explora el almacéu de datos a detalle y exarnina cémo sus funciones afectan los temas de diseho. El capitulo 14 se ocupa del dsefio bisico de bases de datos para el comerco elecirénic. La segunda parte del subtitulo es Ejecucién, Como uiiizamos los capitules 7 y 8 para demostrar el diseio de una bose de datos que realy totalmente fue ejecutada, nos vimos obligades a tratar una amplia varieded de temas de elecucién. Naturalmente, twvimos que enfrentarnos a objetivos de disefo conflitivos: elegancia del disefio, requerimientos de informacion y velocidad de operacién. Por consiguiente, audlitamos con euidado 1 disefo inicial del capftulo 7 para verificar su capacidad de satlslacer las necesidades del usuario final y para establecer protocolos de ejecucién apropiados. El resitado de esta aucitoria reditus el disefio ejecutablefinal desarrllado en el capitulo 8 (esta base de datos operativasirve de base para el primer problema de al- rmacén de datos en cl capitulo 13}. Los temas especiales encontrados en ambiente de base de datos de inter- net se abordaron ol capitulo 14 ("Bases de datos en et comercio electrénico”) y en el capitulo 15 ("Desarrollo de bases de datos en la web’) La parte final del subtitulo es Adminisiracién. En el capitulo 9 ("Administracion de transacciones y control de concurrencia"), capitulo 10 ("Sistemas de administracién de bases de datos distribuides”) y capitulo 16 ("Administracion de bases de datos") abordamos temas de administracion de bases de datos. ENE Ze rel ae er Dada la rqueza de la cobertura detllada, los instniclores pueden "combinar y ligar” capitulos para producir la cobertura deseada. Segén el lugar que los cursos de bases de datos ocupen en el curriculum, ls instructores pueden elegir enfalizar el diseio de bases de datos, las tecnologias de bases dle datos actuales o las rutas de ‘adiinisiracion de bases de datos. Por ejemplo, si el instructor desea enfocarse en los temas te diseiio y oje- cucion de bases de datos, puede vilizarse fa figura 1 como base para desarroliar el sumario del curso, Aunque Jas tres rutas comparten el fundamento de las bases de datos y el concepto de disefo. la ruta de diseiio lleva 2 los capitulos 6 a 8 en los cuales se crea. verilica y ejecula un detallado y complejo disefio de base de datos. {Esta cobertura se incrementa mediante los esquemas en estrella en el capitulo 13 y la exploracién préctica del impacio de internet en el disefio, desarrollo, uso y administracin de hases de datos en los capstulos 14 y 15. Ra } Rag fe Ueda tices Eooetleccureas 2, Coenen Coke se ~ Opcional Coan at ead Sr eT fone dasecsad Syne ae ease ratte Tish stesso See) eC ee Ce ee ce Ree Se ag Sy Cedars ce orienta pee eae FIGURA {_RUTAS DE TEMAS DE DISEIfO Y EJECUCION DE BASES DE DATOS La nanuraleza préctica de la ruta de diseo se presta muy bien para la realizacion de proyectos en los cuales los estudiantes utilzan ef software seleccionado por el instructor para crear un protolipo de sistema para el usuario final. Varios de los problemas al final de los capitulos son suficientemente complejos para que sinan como proyectos, o el instructor puede trabajar con empresas locales para que los estudiantes adquieran ex- periencia préctica,Los instructores que deseen enfocarse en tecnologias de bases de datos actuales, pucden ulilzar la figura 2 ‘como base para desarrollar ol sumario del curso. Si se sigue esta ruta, puede hiacerse caso omiso de los capt tulos 6 a 8 0 ser utiizados simplemente como lectura de apoyo, en tanto que ls capitulos 9 a 15 se convierten en el tema central de la cobertura del curso, Como es dificil comprender los detalles de las tecnologias de base de datos actuales sin un sélido fundamento en conceptos de bases de datos y disetio. la cobertura de los ‘eapitulos 1 a 5 se convierte en la base para el subsiquiente desarrollo del curso. Da) Smear remeber mieten ri TRIER le ne ee essis eomapenmtr (| en MTC EL Coord a Coa ort ao coor Se Pour ye ea a Te | rock) Carn DOUYecenenee ert Cee NG ea ore FIGURA 2 RUTAS DE TECNOLOGIAS DE BASES DE DATOS ACTUALES Si el instructor desea enfocarse en los temas de administracién de bases de datos, puede utilizarse la figura 3 como base para desarrollar el sumario del curso.Dee aR an ae Hipetnoece qxciivos y bases de colts Teoh Rt CEs 2 een Pieler MURATA ee ett ‘ Cr oad Ceo} Ceo eer rae ccs rend ot Ie Bech kort Soe eo Ce yee CP Sea Mu Comer nee rr e Coe Z en Sea ord FIGURA 3_RUTA DE TEMAS DE ADMINISTRACION DE BASES DE DATOS Observe que algunos elementos de las rutas de disefio de bases de datos v de las tecnologlas de beses de datos actuales, también se encuentran en la ruta de administracién de bases de datos. Esta inclusién se debe a la nocién de que es diel administra tecnologias de bases de datos que no se entienden. ARA Eien ESS Reconocemos que la ensofianza de sistemas de bases de datos es una tarea dificil. Sila cobertura de las bases de datos es amplia, préctica y detallada, el trabajo requerido Incluye la creacién real de los disefios y cjecu- isehos mediante la creacién de bases de datos, tablas y relaciones. Para facilitarles la vida a los profesores, nos hemos asegurado de que reciban todo el soporte necesario. [EM s« iwctuven eases ve oaros Esta quinta edicién incluye todas las estructuras de bases de datos y contenidos de tabla en sus recursos para cl instructor, Esta caracterfstica asegura que: * Los disefios de bases de datos desarrollados en el texto cumplirn con todos los requerimientos de cenicion + Los disefios serdn capaces de satisfacer los requerimientos de informacién establecidos. + Las asracones sempre lgsarsn el contenido del base de datos rel * Los profesores ne desperdiciarén su tlempo creando las estruciuras de bases de datos y el contenido de tablas para ilustrar los importantes principios de disefio ¢ informacisn. ‘Aunque utiizamos pantallas de visualizacion de Microsoft Access2000 para presentar el material de una manera més atractiva, Sistemas de bases de datos: diseio, Implementacién y adrinistracién no es libro de Access2000. Se utiliz6 Access2000 porque es muy flexible: las tablas Access2000 pueden ser exportadas en tina amplia\ariedad de formatos, inchido SQL. De hecho, para documentar algunas de las funciones de SQL en el capitulo 5, exportaros nuestrastablas Access2000 a Oracle y luego, ulllzamos la funcién SQL"Plus de Oracle pra producir los resultados de consulta deseados. EBB As ¥ mesones prostemas Hemos agregado muchos problemas nuevos y mejoredo en gran medida su potencial docente. Por ejemplo. et capitulo 1 contiene 29 problemas, los capitulos 2 y 3 contienen 30 problemas cada uno, muchos con opcior nes maitiples. Las descripciones o iustraciones de los problemas se reforzaron considerablemente. Conforme los estudiantes se abren camino,a través de los conjuntos de problemas, éstos se van volviendo més complejos al mismo tiempo que sacan provecho de las lecciones aprencidas al completar los problemas precedente. Fl desarrollo de tales conjuntos de problemas amplios y culdadosamente diseftados hace posible que los estu- diantes obiengen la experiencia necesaria para abordar el disefio del mundo real desarrollo en los capitulo 7 1y 8. Muchos de los problemas son lo suficientemente complejos para servir como casos © como proyectos de clase, en particular si se resteven sigulendo las clapas de ejecucién y desarrollo de aplicaciones. EIB sctuve et esrunio 01 ALMACEN DE DATOS ¥ LA MINERIA DE DATOS El capitulo 13 presenta el almacén de datos y como puede servir como base para actividades de soporte de decisiones, Cuando se realizan apropiadamenite. los sistemas de soporte de decisiones proporcionan una inter- face computarizada que permite 0 los que toman decisiones de negocios abordar, analzar y entender creativa- mente los problemas de negocios. En este capitulo, exploramos varias acercamientos ala ejecucion de sistemas de soporte de decisiones. + Procesamiento analitico en linea (OLAP, por sus siglas en inglés) mediante sistemas de administracion de bases de datos (DBMS, por sus sigs en inglés) * Bases de datos multidimensionales. ‘Cualquiera que sea el enfoque, se apoya en datos operatives que son extraidos, resumidlos quardados en algin tipo de almacén de datos. Como cubrimos el diseio y la ejecucién de bases de datos tipo transaccin (es decir ‘operativas) de una manera tan completa, pedemos proporcionar una cobertura préctica del ambiente de alma- cenamiento de datos sin que el esidiante se pierda en las complejidades del almacén dle datos. Dada la existencia del almacén de datos. las actividades ce minerfa de datos se convierten en un componente reciente de los muewos sistemas de soporte de decisiones. Estos sistemas proporcionan herramienias auto- méticas para extraer y analizar datos. Los procedimientos estén disehtados para Identifiar relaciones de datos, y ast crear la etapa de descubrimiento de los problemas y oportunidades de negocios. ‘Como nos enfocamos en un acercamiento préctico a la cobertura de las bases de datos, exarninamos los eri- lerios que forman la base para disefiar y canstnuir un almacén de datos. Por consiquiente, podemos avanzar ‘iis allé de los conceptos bésicos y demostrar cOmo se utilizan os “hechos y dimensiones” del almacén de datos como fundamento del esquema en estrella y cl cubo multidimensional. Con la presentacion de ejemplos pprécticos, ofrecemos a los estudiantes la oportunidad de realmente disefiar y ejecular un pequefio almacén de datos. ERM o's 8.05 DesARROLLADOS PARA ALCANZAR EL NIVEL DE EJECUCION Conforme desarrollamos bases de datos en nuestras propias clases, descubrimos que muchos estudiantes en- Contraron problemas cuando trataron de transforma algunos de los disefios en estructuras y relaciones de tabla apropiadas. Esos problemas fueron atribuidos al hecho de que nuestras relaciones en ocasiones fueron des- plegadas a nivel kigico, en lugar de a nivel de ejecucién. por ello nos hemos asegurado de corregir esta desven- taja. Las relaciones opcionales dentro del marco de referencia M:N fueron particularmente problematleas: aunque descompusimas la relacién M:N en relaciones 1:M con la ayuda de una entidad compuesta. a algunos estudiantes se les dificuté migrar la opcionalidad a la nueva estructura. Las ilustraciones de relacin de entidad‘evisodas del capitulo 3, acompaiadas de ejemplos, parecen haber sakvado ese obstéculo, Los profesores que Datos: el conjunto de hechos o de informacis 1.2 CRITICA AL SISTEMA DE ARCHIVOS: ‘Aunque en esta secci6n se crfica el desempeito del sistema de archivos, debemnos recordar que cumplié un propésito cil dur inte més de dos décadas, un lapso muy largo en la era de Ia computadora, La critica sirve para dos propésitos primordiaes: 1. La comprensién de las desventajas del sisterna de archivos permite entender las razones que condujeron al desa- rrollo de las bases de datos. 2 Muchos de los problemas que se catalogaron no son exclusivos de los sistemas de archivos. Sino se entienden tales problemas es probable que se duplique en un ambiente de base de datos, aunque la tecnologia de base de datos fos evita reativamente fécil 1.3.1 ADMINISTRACION DE DATOS DE UN SISTEMA DE ARCHIVOS cluso Is tarea de recuperacion de datos mas simple requeria programacion extensa en un lenguaje de tercera generacién (BGL). Un 3G necesita que el programador especifique qué y cémo se debe hacer. Algunos ejemplos de lenguajes de tercera generacién son Common Business Oriented Language (COBOL), Beginner's All-purpose Symbolic Instruction Code BASIC) y FORmula TRANSlation (FORTRAN).Gcrrivere La programacion en un 3GL puede ser una actividad (ediosa que requiere mucha hablidad. Como el archivo simple thstrado cn la figura 1.5 es muy diferente a la forma en la que la computadora quarda fsicamente los datos en disco, el programador. debe estar familirizado con la estructura fisica del archivo, esto es, Smo y dénde se guardan los archivos en la compu tadora. Por consiquiente, toda referencia al archivo en un programa requiere que el programador defina la rutas de acceso 2 os datos. Tales rutas ullizan cédigos complejos para establecer la ubicacion precisa de los dversos components dol ar- chivo y del sistema y las caracteristicas de sus datos. Conforme los sistemas de archivos se wielven més complejos, fa rutas de acceso se tornan difeles de manojar y ienden a provocar un mal funclonamiento del sistema, La necesidad de escribir programas en 3GL para producit, incluso los reportes mas simples, imposibilta las consultay ad hoe. Los atareados especialistas 0 gerentes en procesamiento de datos. que trabajan con sistemas de archivos maduros.. ‘a menudo reciben numerosas solicitudes de reportes nuevos. Frecuentemente se ven obligados a decir que el reporie esters listo la *préxima semana” o incluso el “mes siguiente”. Si se solicita alora la informacién, tenerla la siguiente semana 0 al siguionte mes no satisfard bien las necesidades de informacion. CConforine se incrementa el nimero de archivos en e! sistema. también su adminisiracin se vuelve mas dificil. Cade archivo debe tener su propio sistema de administracion, compuesto de programas que permitan al usuario: + Crear a estructura del archivo. . + Agregar datos al archivo, + Bliminar detes del archivo ‘+ Motficar los datos del archivo + Poner en lista el contenido del archivo Incluso, un sistema simple de 20 archivos requiere 5 x 20 = 100 programas de administracin. Si 10 diferentes programas de preparaci6n de reportes tienen acceso a cada uno de Ins archivos, se tendrén que escribir 20 x 10 = 200 progre- ‘mas adicionales. Como las consults ad hoc no son posites. los programas de preparacién de reportes se pueden mul tiplicar répidemente. ¥, como cada departamento en Ja organizacién posce sus datos para la creacién de sus propios. archivos, el nimero de archivos también se puede mukiplicar répidamenie. La planificacién cuidadosa de las estructuras de los archivos es muy’ importante para el gerente de procesamiento de da- tos, porque los cambios en una estructira pueden ser diliciles en un ambiente de sistemas de archivos. Por ejemplo, el cambio de un campo en el archivo original CUSTOMER requiere un programa que: 1. Cologue la estructura nueva del archivo en una parte especial de la memoria de la computadora conocida como “butler” (memoria intermedia). Abra el archivo original. mediante un buffer diferente. Lea un registro del archivo original. Transforme los datos originales para que se ajusten a los nuevos requerimientos de almacenamiento de la estructura SS. Escriba los datos transformados en la nueva estructura del archivo. A continuacién, se elimina el archivo original. Por titimo, todos los programas que utlicen el archivo CUSTOMER deben rmotificarse conforme a la estructura revisada. De hecho, cualquier cambio de la estructura del archivo, no importa que sea rminimo. obliga a modilicar todos los programas que utizen los datos de ese archivo. Probablemente las modilicaciones prochzcan errores (bugs) y pueden requerir més tiempo para localizarlos en un proceso de depuracién. El consejo “picnse antes de actuat” es valdo en el ambiente de sistemas de archivos. porque todos los programas de acceso a los datos estin sujelos a cambios, pese a que éstos sean minimos en la estructura de un archivo. sen Las lunciones de seguridad, como una eficaz proteccién de contrasefias blogueo de partes de archivos © partes del sistema, ¥ otras medidas diseftadas para proteger la confidencialidad de los datos son cifcles de. programar y, por consiguiente, casi. siempre se omiten. Inchiso, cuando se intenta mejorar ol sistem y la seguridad de los datos, los dispositivos de seguridad tiendon a ser limitados en cuanto a aleance y a efectividad. La estructura del sistema de archivos y la falta de seguridad difcultan la recopilacién de datos, La estructura organizacio~ nal promuove la propiedad de los datos. con lo que se promueve o} almacenamionto de los mismos en diferentes lugares. {Los profesionales de las bases de datos uilzan el término Islas de Informacion para designar tales ubicaciones dispersasde datos.) Como es poco probable que los datos guardados en diferentes lugares se acualicen constontemente, las islas de informacién a menudo contienen versiones diferentes de los mismos datos. El resutado es predecibl: aunque el sisterna de archivos es {sell de ejecutar en las etapas Inclales dol procesamiento de datos en computadora, es probable que un sistema de archivos en proceso de madurscién se salga de contol. El sistema de archivos, simplemente, no se adapla bien a los requerimientos modernos de informacion. 1.3.2: DEPENDENCIA ESTRUCTURAL Y DEPENDENCIA DE LOS DATOS. En la seccion anterior pudimos ver como un cambio en cualquier estructura de un archivo, por ejemplo. fa adicion o elimi= inacién de un campo, requicre la modificacién de todos los programas que ulilizan dicho archivo. Se requieren tales mo- ificaciones porque el sistema de archivos exhibe dependencia estructural, es decir, el acceso a un archivo depende de su estructura. Incluso los cambios de las caracieristicas de los datos de un archivo, como ol cambio de un campo de entero a decimal, re- {quieren modificaciones en todos los programas que tienen acceso al archivo. Como todos los programas de acceso a los. {0s estén sujetos a cambios, cuando cambia alguna de las caracteristcas de los datos, se dice que el sistema de archivos shibe dependencia de los datos. significado préctico de la dependencia de los datos es la diferencia entre el formato légico de los datos {emo ve el hn ‘mano los datos) y el formato fisico de los datos (amo los “ve” la computadora). Por consiguiente, cualquier programa ue tenga acceso a un archivo del sistema no s6lo debe decirle a la computadora qué hacer, sino también, cémo hacerlo. De fal forma que cada programa debe contenerlinaas que especifiquen la apertura de un tipo de archivo especifico, su re- ro y sus definiciones de campo. La dependencia de los datos hace que el sistema de archivos sea exiremadamente en- 217050 desde un punto de visa de programacion y de administracion de los datos. 1.3.3 DEFINICIONES DE CAMPO Y CONVENCIONES DE NOMINACION A primera vista el archivo CUSTOMER, mostrado en la figura 1.3, parece que cumplié bien con su propésito: los reportes = teitedos casi siempre se podian generar. Pero supongamos que se desea crear un directorio telef6nico de clientes @ par- de los datos guardados en el archivo CUSTOMER. EI almacenamiento del nombre de un cliente en un campo es a “e°g0 porque el directorio debe descomponer el contenido del campo para poner en lista los apsllidos, nombres ¢ iniciales = orden alfabético. O supongamos que se desea crear una lista de clientes por cédigo de érva. La inclusion del cédigo © 44a en el nimero telefénico es ineliciente. Por otro lado, la creacién de una Ista de clientes por ciudad es una tarea mucho més difil de lo necesario. Desde el punto © asia del usuario, una mejor delinicion de registro (mis flexible) seria aquella que anticipe los requerimientos de pre- S-ocién de reportes mediante la divisién de los campos en sus partes componentes. Por lo tanto, los campos de CUSTOMER podrian litarse de la siguiente manera: AMPO: ed Meee Apolo det clionte Rymas Primer none del et ‘i Incl cet A SS AREACODE Cig de ies det clene os GIS PHONES 72am le cliente nase Ss ApoREss emia decal w nm de bzbn det cere 218 Fork Rd. SAS CITY 27, Ciudad de resdoraa del cient tabs STATE Estado de resielencia del chente: Aten sa | _ Citgo postal el elemte : yousGB ctr too La seleccién de nombres de campo apropiados es muy importante. Por ejemplo, asegirese de que los nombres de campo sean razoneblemente descriptivos. Al examinar fa estructura del archivo mostrada en la figura 1.3, no es obvio que el nombre de ‘campo REN representa !a fecha de renovacién del sequro del cliente. uso del nombre de campo CUS_RENEW_DATE sera ‘mejor por dos razones. En primer lugar, el prefifo CUS puede utlizarse como indicador del origen del campo. ol cual es el ar- chivo CUSTOMER. Asi pues, se sabe que el campo en cuestiin da una propieded de cliente (CUSTOMER). En segurilo lugar. la parte RENEW_DATE del nombre de campo describe mejor el contenido de éste. Con nominaciones apropiadas, la ws: tructura de os archivos se vuelve autodocumentable; es decir. tan sélo con mirar los nombres de cempo se puede deterrinar ‘2 qué archivos corresponden los carnpos y qué informacién probablemente contengan los campos. ‘Algunos paquetes de software restringen el largo de tos nombres de campo. por lo que conviene que sean tan deserip- tivos como sea posible. cuidando sicinpre no sobrepasar los earacieres permitidos. Ademés, recuerde que los nombres ‘muy lacgos provocarian que sélo pucéramos colocar ullos cuanlos en una pagina y el intelinesdo de sada se convertria ‘en un problema. Por ejemplo, el nombre de campo CUSTOMER INSURANCE. RENEWAL DATE, si bien, es eutodo- ‘cumentable, es menos deseable que CUS_RENEW DATE. ‘Otro problema en el archivo CUSTOMER, de la figura 1 3. es que dicta la locaizacin eliciente de los datos. Observe ‘que en este momento el archivo CUSTOMER no cuenta con un identilicador de registro ‘nico. Por ejemplo. es posible tener varios chentes que se llamen Jon B. Smith, por lo tanto, seria apropiado agregar el campo CUS_ACCOUNT. ‘que contiene un niimero de cuenta de cionte dnico. ‘Aunque s6lo se han criticado las definiclones de campo y las convenciones de nominacién, mostradas en la estructura de archivo de la figura 1.3, los puntos que se acaban de iratar no son exclisivos de los sistemas de archivos. Puesto que mds adelante se demostraré que tales convenciones son importantes. decidimos anticipar su presentacién, Se revisarén. las definiciones de campo y convenciones de nominacién cuando se aprenda el dsefio de base de datos en el capitulor3 TTocaremos el tema de "Modelado de relacion de entided (E-R)". cuando se aborden temas de ¢jecucién en el capitulo 6, Disento de base de datos’, y cuando se vea un dlseiio de base de datos real ejecutado en los capitulos 7 y 8 ("El la- boratorio universitario” disefo y ejecucién). Haciendo caso omiso del ambiente de datos, el disefio—ya sea que implique. tun sistema de archivos 0 ima base de datos— siempre debe reflvjar las necesidades de documentacién del diseiador y. los requerimientos de procesamiento y presentacién de reportes del usuario inal. Ainbos tipos de necesidades serdn sar tislechas siempre y cuando nos apeguemos a las definiciones de campo y convenciones de nominaci6n apropiadas. ROR Oebemos tomar en cuenta quee ningune convencién ce nominacién puerte adaptarse « locos fow requ todos los sistemas. Algunas palabras 0 frases esin reservaclas para uso interno dle los sitemas cle adm de bases ke datos. Por ejemplo, el nombre ORDER yeneraria un ervor en algunos sistemas de aciminisiracion dle ba ss de datos. Asimismo, su sistema de acininitracim de bases de datoy podtfa integpeetar un guid (como un eo mando de resta. Por consiguienic, el campo CUS-NAME serfa interpretada camo un comands de restar ef campo NAME del campo CUS. Como ninguna de: los dos campos existe, se obtendria un mensaje de enor, Por otra parte, CCUS_NAME si funciondria bien, ya que utiliza un guidn bajo. istracion 1.3.4 REDUNDANCIA DE DATOS ‘Sil sistema de archivos dificulta compartir los datos, probablemente fos mismos datos estén quardados en diferentes ubica- clones, Por ejemplo, en las figuras 1.3,y 1.4, los nombre y los ndmeros telef6nicos de los agentes estén tanto en los archivos CUSTOMER como en los archivos AGENT, Se necesita sélo una copia correcta de los nombres y niimeros telefénicos de los agentes, Al hacer que ocurran en més de un lugar se produce redundancia de datos. |La redundancia incontroleda provoca: 1. Inconsistencia de los datos. Existe Inconsistencla de los datos cuando aparecen versiones diferentes y conflicts de los mismos datos en diferentes lugares: por ejemplo, suponga que se cambia el nero telafénico 0 el domictio del agente en el archivo AGENT. Si se olvida hacer los cambios correspondiente en CUSTOMER, ol archivo contiene: datos dilerentos del mismo agente. Los reportes darfan resultados inconsistentes, dependiendo la versién de los datos. ‘que se utlice. Los datos que exhiben inconsistencia también se conocen como datos que carecen de integridad.; Es amacho mis probable que ocurran errores al ingresar datos cuando se hacen entradas complejs (como riimeros {clefénicos de 10 diaitos) en varios archivos diferentes y/o recurren con frecuencia en uno o més archivos De hecho, el archivo CUSTOMER, mostrado en la figura 1.3. contiene un ingreso erténeo de ese tipo: el tercer registro cn el archivo CUSTOMER tiene un digito cambiado en el ntmero telefénico del agente (615-882-2144 en lugar de 615-882-1244), Es posible ingresar el nombre y el nimero telefénico de un agente inexistente en el archivo CUSTOMER, aunque ¢s improbable que los clientes se impresionen si la agencia de seguros proporciona el nombre y el nimero telelS- rico de un agente que no existe. ¥ ze gerente de recursos humanos deberta permilir que un agente que no existe obtenga comisiones y benelicios? De hecho, un ingreso de datos err6ne0, como un nombre mal deletreado un niimero telefénico incorrecto. produce la misma dase de problemas de integridad de los datos 2, Anomalias de fos datos. El diccionario define “anomalia” como una anormalidad. Klealmente, un cambio del valor de un campo deberia hacerse en un solo lugar. Sin embargo, la redundancia de datos alienta una condicién anor- mal porque obliga a que el valor de campo cambie en varios lugares diferentes. Observe el archivo CUSTOMER en la figura 1.3. Sila agente Leah F. Hahn decide casarse y cambiar de residencia, ef nombre del agente podria cambiar, incnso, también el domiciio y el telefono. En lugar de hacer s6lo un cambio de nombre o de telefono. o de ambos, en un archivo (AGENT), se debe hacer el cambio cada vee que ocurre el nombre, telefono y domiclio en el archivo CUSTOMER, también. ;Podra darse el caso de tener que realizar cientos de corecciones, uno por cada uno de los clientes atendidos por dicho agente! Ocurre e! mismo problema cuando un agente decide renunciar. ‘Cada cliente atendido por ese agente debe ser asignado a uno nuevo. Observe que se dan anomalias de los datos porque cuslguier cambio en cualquier campo debe hacerse correctainente en muchos lugares para mantener la integridad de los datos, Las anomalas de los datos. encontradas en la figura 1.3. comtinmente se definen como: + Anomalias por modificaciones. Sila agente Leah F, Hahn tiene un nimero telefénico nuewo, dicho nimero debe ingresarse en cada uno de los registros del archivo CUSTOMER en los cuales aparece cl niimero telef6- nico de Sra, Hahn. En este caso, s6lo deben hacerse tres cambios. En um sistema de archivos grande, tales camn- bios podrian ocurrir en cientos o incluso miles de regisitos. Claramente, el potencial de inconsistencias de los datos es grande. ‘+ Anomotias por Insercién Para agrogar cada cliente nuevo al archivo, también se deben introducir los datos dl agente correspondiente. Si se agregan clentos de cliantes nuevos, también se deben ingresar cientos de nombres y ndmeros telelGnicos de agentes. De nuevo, ta posibilidad de crear inconstsrencias de los datos s grande. ‘+ Anomnatias por eiiminacién, Si el agente Alex B. Alby renuncie y es eliminado de la némina. todos os chentes «en el archivo CUSTOMER quedan vinculados @ un agente inexistente. Para resolver este problema, deben mo- difcarse todos os registros en los que aparecen et nombre y el nimero telef6nico del Sr. Alby. 1.4 SISTEMAS DE GASES DE DATOS Los problemas inherentes a los sistemas de archivos originan que el nso de un sistema de base de datos sea ry desea- ble. A diferencia de los sistemas de archivos, con sus muchos archwos separados y no relacionados, la base de datos se ‘compone de dates logicamente relacionados guardedas en un s6lo depésio de datos. Por consiguiente, la base de datos representa un cambio en ta manera de guardar. introducir y manejar los datos para el usuario final. El sistema de admi- ristracién de base de dates. presentado en la seccién 1.1 y mostrado en la figura 1.6, brinda numerosas vontajas sobre 1b administracién de sistema de archivos, mostrada en la figura 1.5, porque permite oliminar la mayoria de los problemas. ‘provocados por inconsistencias de los datos, anomalias de los datos. dependencia de los datos y dependencia estructural. Es ms, la generacion actual de software de DBMS no sélo guarda las estructuras de fos datos, sino tambin las relaciones centre elles y las rutas de acceso a éstas, Lodas en una ubicaciGn central. La generacién actual de software de DBMS, tam- bin. se ccupa de defini, guardar y administrar todas las rutas de acceso a dichos componentes. ee[Blcarrrore 2 Sistema de base de dares, FIGURA 1.6 COMPARACION DE UNA BASE DE DATOS Y UN SISTEMA DE ARCHIVOS Recuerde que el DBMS es slo uno de varios componentes vitales de un sistema de bases de datos. Quizé lo mas apro~ plado sea referirse al DBMS como el corazbn de la base de datos y, ast como un organismo humane raguiere de algo ims que el coraz6n para “funcionat”. una base de datos necesita mas que un DBMS para trabajar. En la secctén 1.4.1 es- tudiaremos qué es nina base de datos. cusles son sus componentes y cémo se integra un DBMS en todo el sistema. 1.4.1 EL AMBIENTE DEL SISTEMA DE BASE DE DATOS El término sistema de base de datos se refiere a una organizacin de componentes que definen y regulan la recoleccién, almacenamiento, administracién y uso de los datos dentro de un ambiente de base de datos. Desde el punto de vista de aciministracion general, el sistema de base de datos se compone de las cinco partes principales mostradas en la figura 1.7: hardware, saltware, personas, procedimientos y datos, 1, Harcware: hardware se refiere a todos los cispositivoslisicos del sistema. El hardware principal y mis fil de identi ficar del sistema de hase de datos es la compuradora, la cual podrfa ser una ricrocomputadora, una minicomps- tadora o una maxicomputadora (mainframe) E] hardware también inckiye todos los perléticos de ls computadora, los cuales son los dispositos isicos que contralan la entrada ylasalida de a computadora, Dicho de otra manera los periféricos Incluyen teclados, ratones, modems e impresoras; también incliyen cualquier dispositive electrénica utlizado para conectar dos 0 més computadoras, con lo que se produce una red de computadoras. Tales redes son importantes para las bases de datos, ya que permiten el acceso a datos desde lugares remot, tales como sltemnas de reservaciones aéreas y cajeros aulomaticosCoen peri Aatnsnador de Adminshosor Dlsetadoxay base Ge datos de sistema “Analiso8 ne c ee i me Ley. io FIGURA 1.7_ AMBIENTE DE SISTEMA DE BASES DE DATOS 2, Software: software se reflere al conkinto de programas ulfizados por las computadoras dentro del sistema de base de datos, Aunque el software més {él de identilicar es el DBMS, se requieren tres tipos de software para hacer que la base de datos funcione a plenitud: software del sistema operative. software de DBMS, programas de aplicacién y ulleias. * El software de sistema operative mancia todos los companentes de hardware y hace posible que todos los dems programas {uncionen en la computadora. Algunos ejemplos de soltware de sistema operativo inchwyen sistemas operatives de disco (DOS). OS/2 y Windows 2000 utlizados por microcomputadoras; UNIX y VMS utilzados por minicomputadoras; y MVS utlizado por computadores mainframe IBM, + Bi softwore de DBMS maneja la base de datos dentro del sistema de base de dalos. Algunos ejemplos son ‘Access y SQL Server de Microsoft. Oracle de Oracle Corporation y DBZ de IBM. *+ Los programas de oplicocién y las utileros se utlzan para tener acceso y manipula los datos contenidos en cl DBMS y para maneiar el ambiente de la computadora donde se lleva 2 ¢abo el acceso y la manipulacién de fos datos. Los programas de aplicacién comtinmente se utlzan para acceder a los datos de la bose de datos ppara generar teportes. tabulaciones y otra informacion que puede facltar la toma de decisiones. Las utilerias son las herramientas de software utilzadas para manejar los componentes de la computadora que intervie- nen en el DBMS. Personas: este componente inchiye a todos los usuarios del sistema de base de datos. Con base en la funcién prin- pal de puesto de trabajo. se pueden identificar cinco tipos de usuarios en un sistema de base de datos: adminis- tradores de sistemas, administradores de base de datos. disefadores de base de datos, analists © programadores de sistemas, o ambos, y usuarios finales. Los mlemibros de cada tipo de usuario realizan tanto funeiones Gnicas como complementarias + Los administradores de sistemas supervisan las operaciones generales del sistema de base de datos. + Los admintstradores de base de datos, también conocidos como DBA. administran el uso del DBMS y ge- rentizan que la base de datos esté funcionando apropiadamente, El rol de administracién de la base de datos del DBA es lo suficientemente importante como para jusificar una exploracién detalada en el capitulo 16. ~Administracion de bases de datos”. + Los disefiadores de base de datos disefian la estructura de ta. Eilos son. en realidad, los arquitectos de las ‘bases de datos. Si el disefio de la base de datos es deficient, incluso los mejores programadores de aplicaciones y los DBA més dedicados no serian capaces de producir un ambiente de base de datos itil. Podemos iustrar ‘mejor esio al ulizar una vieja analog’a, los mejores albariles y carpinteros no podrian erigir un buen edificio ‘con un plano de ejccucion incorrecto. Como las organizaciones se esluerzan por optimizar sus recursos de da tos, la descripcion det puesto (relaivemente nuevo) de disefiador de base de datos se ha ampliado hasta abarcar ‘nuevas dimensiones y més responsabilidades.cariruco 4 ‘+ Los anaitstas de sistemas y programadores diseftan y ejecutan los programas de aplicacién. Disefan y crean los filtros de entrada de datos. reportes y procedimientos mediante Jos cuales los usuarios finales acceden ¥ ‘manipulan los datos de fa base de datos. + Los usuarios finales son las personas que utlizan los programas de aplicacién para realizar las operaciones diarias de la organizaci6n. Por ejemplo, los vendedores. los superisores, los gerentes y los directores. todos estén clasificadas como usuarios finales. Los usuarios de alto nivel emplean la informacion obtenida de la base de datos para tomar decisiones téctcas y estratégicas. 4. Procedimientas: los procedimientos son las instrucciones y reglas que rigen el disefio y ol uso del sistema de base. de datos. Los procedimientos son un componente crilco, aunque ocaslonalmente olvdado. det sistema. Deser- pehan un rol importante en una compafia, porque hacen cumpli los estindares mediante los cuales se conduce el negocio dentro de la organizacion y con los clentes. Estos también se utllzan para garantizar que existe una for ma de motitorear y auditar tanto los datos que entran en la base de datos coma la informacién que se genera con ellos. 5. Datos: la palabra “datos” comprende el conjunto de hechos guardados en la base de datos. Como éstos son la ma- teria prima con la cual se genera la informecién, determiner cudles deben introducirse y cémo debe organizarse es tuna parle vital del trabajo del diseRador de la base de datos. Es evidente que la existencia de un sistema de base de datos le proporciona una nueva dimensién a la estructura adm nisiativa de una organizacién, La compleidad de esta estructura administrativa depende del tamario de la orgenizacién, de sus funciones y de su cultura corporativa. Por consiguiente, los sistemas de base de datos pueden crearse y manejatse a. partir de diferentes niveles de complejidad y con adherencia variable a esténdares precisos. Por ojemplo, compare un sis: tema de renta de peliculas local con un sistema de reclamacién de seguros nacional. El sistema de renta de peliculas podria. ser manejado por dos personas, el hardware ublizado probablemente seria una microcomputadora, los procedimientos pProbablemente serian simples y el volumen de datos seria bajo. Por otro lado, probablemente el sistema de reclomo de Seguros tendria por los menos un administrador de sistemas. varios administradores de base de datos de tiempo completa. 1y muchos disefadores y programadores: el hardware probablemente incliria varias computadoras mainframe en mil piles lugares de Estados Unidos; los procedimientos podrian ser numerosos, complejos y rigurosos y c) volumen de datos seria enorme. ‘Ademés dlel hecho de que los diferentes niveles de complejidad de un sistema de base de datos son dictados por las acti- vidades organizacionales y por el ambiente en el que ocurren, los gerentes también deben tomar en cuenta otto hecho itnpontante: las soluciones de base de datos deben ser efectivas en cuanto a costes, asi como en cuenlo a técticas y esre teglas. Una solucién de un millén de délares a un problema de mil délares diffe mente es un ejemplo de un buen sistema de base de datos o de un buen disco y administracion de éstas. Finalmente, la tecnologia de base de datos existente obliga a considerar opciones en la seleccién de un sistema de base de datos. Dada la amplia variedad de requerimientos y tecno~ logfas, es aproplado examinar a continuacién algunos tipos de sistemas de base de datos. 1.4.2 TIPOS DE SISTEMAS DE ADMINISTRACION DE BASES DE DATOS EI DBMS, basado en el sistema de base de datos, se puede clasificar de acuerdo con el nfimero de usuarios, la 0 las ubiea cones de la base de datos y el tipo y el grado de usos esperados. El mimero de usuarios determina si el DBMS se clasfica como de usuario tinico 0 de usuarios miltiples. Un DBMS para. usuario nico soporta séto in usuario a la vez. En otres palabras, si el usuario A est utizando la base de datos, los usua- ios B y C tienen que esperar hasta que éste haya forminado su trabajo. SI una base de datos de usuerio snlco corre en ‘una computadora personal, también se llama base de datos de escritorio, En contraste, un DBMS para usuarios ri- ples soporta a varios al mismo tiempo. Sila base de datos para usuarios miltiples soporte un niimero relativemente pe- ‘quefio de usuarios (por lo general menos de 50) 0 un departamento especitico dentro de una organizacién, se lama, base de datos de grupo de trabajo. Si la base de datos es utlizada por foda la organizacién y soporta muchos usuarios. (ims de 50, por lo general cientos) a través de muchos departamentos. la base de datos se conoce como base de datos ‘empresarial.8 DBMS tambien puede clasficarse de acuerdo con la ubicacién de la base de datos: por ejemplo, un DBMS que sopor ta una base de datos localizada en un solo silio se lina DBMS centralizado: y el que soporta una base de datos distr buida en varios sitios se lama DBMS distribuido. El grado al que una base de datos puede distribuirse y la manera en fa que se maneja tal distribucion serén trelados a detalle en el capitulo 10, “Sistemas de administracion de bases de datos distibuidos”. QuizAs el tipo de uso y el grado de éste proporcionan el método de clasificacion de DBMS més pertinante y més acep- tado en la actuaidad. Por ejemplo. transacciones como ventas de productos © servicios. pago y compres de materiales, re- flelen las operaciones crficas dlarias. Tales transacciones son crticas en cuanto al tiempo y deben regkstrarse precisa ¢ Inmediatamente —Ia venta de un producto debe registrarse y reflejarse Inmediatamente en el inventario. Un DBMS que ‘acciona una base de datos. principalmente disefiada para soportan transacciones que requieren una "respuesta inmediata”, s¢ casifica como DBMS transacclonal o DBMS de produccién. En contraste, una base de datos de soporte de decisio- nes se ocupa principalmente de le produccion de la informacion necesaria para tomar decisiones téctieas y estratégicas 2 niveles gerenciales medics y altos. El soporte de decislones provsto por un sistema de soporte de decisiones (DSS, por sus silas en inglés). generalmente requlere de un Intenso “masaje de datos” (manipulacién de los datos) para extraer informacién de datos histéricos que nos permitan fijar precios, predecir ventas, posicionarnos en el mercado, eteétera Pucsto que la mayorta de la informacion de las bases de datos de soporte de decisién esté basada en datos histéricos, pro- bablemente el facior tiempo de recuperacion de los dates no sea tan erftco como lo es para la base de datos transaccional ‘Ademés, la informacién de las bases de datos de soporte de decisiones tiende a basarse en datos complejos provenien- tes de muchas fuentes, Para hacer que tales datos sean més féciles de recuperar, fa estructura de una base de datos de porte de decisiones es bastante diferente de la de una base de datos orientada a transacciones. De hecho, el térmk ss almacén de datos se utiliza para describir el disefio de una base de datos favorecida por los sistemas de soporte de versiones, evidente que para realizar el diseiio de una base de datos, el disefador debe identificar con precisién el uso que se le 1 dor a ésta. El diserio de una base de datos transacclonal enfatiza el uso de datos histéricos y agregados. El disefio de una = de datos que se va a utilizar en un aribiente de usuario Gnico centralizado es diferente al que se utiliza para una base = datos do usuarios miitiples distribuidos. En este libro se haré hincapié en el diseio de bases de datos para usuarios mi pes, para un usuario, centralizadas y transaccionales. Sin embargo, también se examinarén temas crticos que suelen pre- ‘eniérsele al disefador de bases de datos de soporte de decisiones y distribuidas en los capitulos 10 y 13. §-4.3 FUNCIONES DE UN Dams. DBMS realiza varias funciones importantes que garantizan la integridad y la consistencia de los datos de una base de La mayoria de estas funciones son transparentes para los ustiarios finales, y casi todas pueden reallzarse s6lo me- snie un DBMS, Estas funciones incluyen la administracién de un diccionario de datos, la administracién del almacene- esto de datos, transformacién y presentacion de los datos, administracién de la seguridad, control de acceso a usuarios ‘tuples. administracién de respoldos y recuperaci6n. administracion de la integridad de los datos. lenguales de acceso @ sase de datos ¢ interfaces de progremacién de aplicaciones e interfaces de comunicacién con base de datos. 1. Administracton de! diccionario de datos: el DBMS necesita que las definiciones de los elementos de datos y sus relaciones (metadatos) se guarden en un diccionario de datos. A su vez. todos los programas que tienen acceso a Jos datos de la base de datos funcionan a través del DBMS. Este utliza el diccionario de datos para buscar ls estruc- turas y elaciones del componente de datos requeridos, lo que libera al usuario de tener que codificar esas comple jas relaciones en cada programa. “demas, cualquier cambio que se realice en la estructura de una base de datos, autométicamente queda registrado en el dicclonatio de datos, por lo que el usuario no tiene que modiliar todos Jos programas que tlenen acceso a la estructura moxificada, En otras palabras, el DBMS proporciona abstraccién de los datos y elimina la dependencia estructural y de los datos del sistema. 2, Administracién del almacenamiento de datos: el DBMS crea las estructuras complejas necesarias para el alma- cenamiento de datos. con lo que se libera al usuario de la dif tarea de definir y programar las caracterslcas fis cas de los datos. Un DBMS moderno permite almacenar no s6lo datos. sino también. formularios de ingroso 0 y condiciones del mundo real. Por ejemplo, tales abstracciones permiten explorar las caracteristicas de entidades y las “slaciones que se pueden crear entre ellas. Si los modelos no son Iégicamente buenos. no se lograrén disefios de bases de Sos funcionales que nos permitan oblener informacién atl. Por lo tanto. en este libro nos eslorzaremos por desarro~ “Sr buenas técnicas de modelado. Los modelos bnienos dan como resultado disefios de bases de datos buenos que son la “ss para buenas aplicaciones. En el caso contrario, no se puede esperar construir buenas aplicaciones con disefios de base e datos malos basados en modelos deficientes. 1.8 MODELOS DE BASES DE DATOS: [La bisquede de una mejor administracion de datos condujo a dilerentes maneras de resolver las desventajascrflicas del sis- sema de archivos. Las ideas tebricas de bases de datos estén representadas por varios modelos de bases de datos. ‘Un modelo de bases de datos es un conjunto de ideas logicas utlizadas pora representar Ia estructura de datos y las re- leciones entre ellos dentro de la base de datos. Estos modelos se pueden agrupar en dos categorias: modelos conceptuales » modclos de ejecucion,a cartrure 4 + El modelo conceptual se enfoca en la naturaleza logica de la representacién de datos. Por consiguiente, este delo esté comprometido con lo que esté representado en la base de datos. y 190 en céino esté representado. | modelos conceptual incliyen el modelo de Entidad Relacién (E-R), analizado en el capitulo 3, y el modelo tado a objetos. examinado en cl capitulo 11 + En contraste con el modelo conceptual, un madelo de ejecuctén hace énfasis en cémo los datos estén represei tados en la bose de datos o en eémo se ejecutan les estructuras de datos para represeniar lo que es{é modelado Los modelos de ejecuctén inchiyen el modelo de base de datos jerérquico, el de base de datos de red, el modelo de ‘base de datos relacional y el modelo de base de datos orientada a objetos. Cada uno de estos modelos de ejecucién seré examinado brevemente de la seccién 1.5.1 a la 1.5.3. El modelo de baer de datos relacional se irataré del eapfiuio 2 al 8, Los disenadores de bases de datos utilizan un modelo de base ce dati conceptual como base para el dibujo de ejecucion de la base de datos. Los madilos concepluaes ulizan tres lipos de relaciones para describir asociaciones entre los datos: uno a muchos, mu ‘chos a muchos y uno a uno. Los disefadores de bases de datos generalmente ufiizan las notaciones taquigrAficas 1:M, M:N 1y 1:1 para elas, respectivamente, (Aunque la notaciém MN es una etiqueta esténdar para la relacién muchos a muchos también se utliza le etiqueta M:M.) Los sigulentes ejemplos isstan las diferencias que existen entre las tres. 1. Relaci6n uno a muchos: un pintor pinta varios cuadros dilerentes. pero enda uno de ellos ¢s pintado rinicamente| por 6k por lo tanto, el pintor {e! “uno") esté relacionado con los cuadros (los “muchios"). Los disefiadores de ‘base datos designan fa relacién “PAINTER paints PAINTING” (PINTOR pinta CUADROS) como 1:M. Asimismo tuna cuenta de cliente la “una") podria contener muchas facturas. pero las facturas (las “muchas") est relacionadas solamente con una cuenta de cliente, La relacién CUSTOMER genera INVOICE (CLIENTE genera FACTURA, tambien se designaria como 1:M. 2. Relacion muchos a muchos: un empleado podria aprender varias especialidades de trabajo y cada una pourar aprenderla muchos empleados. Los dlsefiadores dt la base de datos designan Ia relacién “EMPLOYEE learns SKILL. {EMPLEADO aprende ESPECIALIDAD} como MIN. Asimismo. un estudiante puede tomar muchas cursos y cada ‘curso pueden tomarlo muchos estudiantes. con lo ue se tlene la designacién de M:N para la relacién expresado por “STUDENT takes COURSE” (ESTUDIANTE toma CURSO). 3. Relacién uno a uno: una estructura de administracion de una compaia al menudeo puede necesitar que cada una de sus tiendas sea adininistrada solamente por un empleado. A su vez, cada gerente de tienda (que es un empleado| s6lo administra una tienda, Por consiguiente, la relacién “EMPLOYEE manages STORE” (EMPLEADO administra TIENDA) se designa como 1:1, ‘Como cada modelo de base de datos evohicioné de sus predecesores, se examinarén breverente todos los diferentes mo- delos en esta seccién. La experiencia ha demostrado que se lendré un mejor conocimiento de los temas de dhisefio, ejecu- con y administracién de bases de datos, una vez que se conozcan los aspeclos elementales de cada marco de referencia conceptual del modelo de base de datos. De hecho, se descubriré que muchos de los conceptos y estructuras de bases de datos “nuevos” guardan una notable semejanza entre algunos de los conceptos del models de base de datos jerércuico § Jos encontrados en las estructuras de disefio y cJecucion de bases de datos orientadas a cbjetos en el capitulo 11, 1.5.1 MODELO DE BASES DE DATOS JERARQUICO North American Roclavell fe el principal contratista en el proyecto Apolo, e! cual culmind con el alunizaje en 1969. Para concluir con &4ito un proyecto tan complejo como éste se necesit6 manejar millones de piezas. La informacion relacio nada con las piezes fue generads por un complejo sistema de archivos manejado per computadora. Sin embargo, como 1a se vo al principio de este capitulo, los sistemas de archivos pueden provocar redundancia de datos, junto con todas sus anomalias subsecuentes. ‘Cuando North American Rockwell comenzé a desarrollar su propio sistema de base de datos, una auditoria de cintas de computadora revels que més de 60% de los datos cran redundantes. Los problemas provocados por la redundancia de da- 10s obligé a North American Rockwell a desarrolar una estrategia alterna para manejar estas grandes centidades de datos, Utlizando algunas partes de los conceptos de bases de datos que ya existian, desarrllaron un software conocido comoGUAM (Método de acceso a actualizaciones generalizadc), el cual estaba basado en el hecho de que todas las partes [equetias se reunirfan como piezas de componentes atin més grandes y ast sucosivamente, hasta que todos los componen- tes se reunieron en una unidad final. ‘A mediadlos de los afios 60, IBM se uni6 a North American Rockwell para ampliar la capacidad de GUAM y reemplaz6 cl almacenamiento en cinta de computadora por uno en disco de computadora més actualizado, el cual permitié la intro duccion de sistemas indicadores complejos. Un indicador es un dispostivo tle referencia que “indica” ta ubicacién de datos expects en ef area de abmace- Fent0: esto es anslogo a la referencia de pagina en el indice de un libro, cual permite buscar un tema en cular en el ‘ndice que esté alfabéticamente ordenado, encontrar el tema y luego utilizar la referencia de pagina placa para ir a consultarla, Aunque un sistema indicadar de computaciora es mucho ms compleja, bésica- funclona de ls misma manera. Los resullados del esfuerz0 conjunto RockwelHBM se llegé conocer como sistema de adminlstracién de la informa- ‘eign (IMS, por sus siglas on Inglés). Dado ol poder de desarrollo y comercialzacién de IBM, el IMS legé a ser el sistema de bases de datos jerérqulco para computadoras “mainframe” lider a nivel mundial en los afios 70 y a principios de los 80. ‘Aunque el modelo de bases de datos ya no es im actor importante en el mercado actual. se deberén entender por lo menos algunas de sus caracterisicas, por las siguientes razones: + Sus conceptos basicos son la base de los desarrollas de las bases de datos subsiguientes, ‘= Ses limitactones condujeron a una forma diferente de considerar el dsefio de bases de datos. + Algunos de sus conceptos bésicos aparacen en modelos de base de datos actuales. ESTRUCTURA BAsiICA Dada su herencia de manulactura, la estructura logica bésica del modelo jerdrquico se entiende mejor cuando se examina un proceso de manufactura. Por ejemplo, a continiacion se examina un proceso de produccién de un archivero: 1. Un archivero tiene muchos componentes: un armazén, un conjunto de cajones y barras deslizantes para éstos, 2, Un componente puede estar integrado por muchos ensambles més pequefios. Por ejemplo, cada cajén tiene una rmanija con una cerradura, un conkinto de rodillos que encajan en las barras deslizantes del bastidor y una hoja divisor. 3. Un ensamble puede contener muchas piezas: por ejemplo, cada rodilo se compone de una pequefia rueda, un ie y un anclaje. 4. El proceso de produceién se basa en relaciones de datos que no cambian con el tiempo. Ya sea que se haga un archivero hoy o mariana, las mismas piezas se arman de dilerentes maneras para produeir los mismos ensambles {que se combinen para lograr los mismos componentes que se ensamblan de la misma manera para crear el archivero, I seguimtento de las plezas, ensambles y los componentes que acabamos de describir se faciita si se entiende el proceso logico representado por el “érbol” invertido, conocido como estructura jerdrqulca, mostrada en la figura 1.8, Se rotularon los componentes de la estructura como ayuda para entender el vocabulario de base de datos jerérquica.Cr ano} Segment ratz ‘Segmontos de nivel 1 ‘hijos de raiz) ot Fests | See | Gee) menos de nivel 2 {nos de nivel 1) FIGURA 1.8 ESTRUCTURA JE! 1QUICA ‘Al exeminar la figura 1.8 se observa que e! usuario percibe la base de datos jerdrquica como una jerarquia de seqfhent Un segmento es el equhalente a un tipo de registro de sistema, En otras polabras, la base de datos jerérquica es un c= junto de registtos Kogicamente organizados de conformidad con la estructura de Arbol invertido Gerérquica) mosirada = Ja figura 1.8, Dentro de la Jerarquia, el nivel superior (la raiz) se percibe como el padre del segmento directamenic de bajo de 61. Por ojemplo. en la figura 1.8 el segmento rafz es el padre de los segmentos del nivel 1, los que a su vez, § Jos padres de los segmentos del nivel 2, y asi sucesivamente. A su ver, los segmentos debajo de olros son los hijos que esté arriba de ellos. En sume: ‘+ Cada padre puede tener muchos hijos. + Cada hijo tiene sla un padre. Dada esta estructura jerdrquica, es fécil entre ellos jastrear tanto los componentes de la base de datos como las relaciones 1M Debemos tomar en cuenta que la estractura de Srbol, mostrada en la figura 1.8, no puede duplicarse en el érea de alm cenamiento de la conputadora. La computadora no “ve” la estructura de érbol Idgica como la ven os humanos. En s/ lugar, "ve" ol drbol que esté definido por una ruta que rastrea los segmentos padtes hacia los segmentos hijos, comenzan do por la lzquierda. Esta secuencla ordenada de segmentos, que treza la estructura jerdquica, se lana ruta fordrquica, Pos ejemplo, la ruta jerérquica del seamento designado “Parte D”, en la figura 1.8, puede rastrearse de la siguiente forma: Ensamble final —> Componente A —> Fnsamble A > Parte A > Parte B > Componente B > Componente C > Ensamble B -> Parte C —> Parte D Observe que la ruta rastrea todos los segmentos desde la rai, a partir del segmento situado més ala izquierda. Esta ruta “en forma de fista iequierda” se conoce como ruta preordenada o secuencia jerirquica, Considerando esta ruta los di sefalores de bases de datos debon asoqurarse de que los segmentos accesados con més frecuencla y sus componentes estén Jocatizados lo més cerca posible del lado iaquierdo del érbol, para garantizar un acceso mds eficente a los datos. En la igus 1@ 1.8, por ejemplo, sila Parte D es ol componente mas accesado y actualizado, convendria cambiar a estructura dela base. de datos para colocar el Componente C en el lado inwierdo de los segmentos del nivel 1. Logo, dentro de esta “rains” reubicada, se debe cambiar la Parte D a la posicién acttuimente ocupada por la Parte C. Estos cambios permiten acortat 12 secuencia jerrgica Ensamble final > Componente C > Ensamble B > Parte D Por otra parte, no pretendemos decir que el modelo de base de datos jerérquico estélimitado @ procesos de fabricacién, més bien To que queremos dar a entender es que el modelo jerérquico es efectvo siempre que se tengan muchas trans-acciones que impliquen tina serie de relaciones 1:M que permanezcan siempre fiias. Por elemplo, un sistemas de cuentas bancarias de ciontes se adapta muy bien al modelo jerérquico. + Cada cuenta de cliente puede estar sujeta a muchas transacciones {relacion uno @ muclios). ‘+ Una transaccién de cuenta implica cargar © acreditar: por consiguiente, fa relacién basica entre fa cuenta de cliente xls transacciones de la cuenta no cambian. ‘+ Probablemenie el banco maneje muchas cuentas de clientes, y cada una de éstas puedo estar sujeta a snuchas transacciones: por lo tanto, seguramente el ntimero total de transacciones seré muy grande. Considerando lo anterior. no es raro que muchos bancos hayan adoptado el modelo de base de datos jerérquico. VENTAsAS 1a caracteristicas sobresalientes del modelo de base de datos jeréirquico ofreci6 muchas ventajas sobre el modelo de sistema de archivos. De hecho. muchas de las caracteristicas sobresalientes del modelo de base de datos jerérauico ayudaron a formar el fundamento de fos modelos de base de datos actuales. y muchas de sus ventajas de aplicacién se replicaron ‘aunque de forma diferente, en ambientes actuales de bases de datos. A continuacién, resumimos las ventajas ms impor antes de este modelo: 1. Simplicidad conceptual: dada esta estructura jerérquica del modelo de base cle datos. la relacion entre los diversos niveles es logicamente simple; por consiguiente. es més fécil ver a base de datos conceptualnente, lo que simpl- fica su proceso de disco. 2. Seguridad de la buse de datos: la seguridad de la base de datos es provista y ejecutada por el DBMS, de modo que Ja seguridad se ejecuta uniformemente por todo el sistema, sin tener que depender de los esfuerzos de lox pro- gramadores para realizar aplicaciones individuales que pueden (ener ideas muy diferentes sobre el grado y el tipo de sogurided requerida. 3. Independencia de fos datos: el DIBMS crea un ambiente en ef que la independencia de los datos puede muante: rnerse, con lo que disminuye sustancialmente ei esfuerzo de programactén y el mantenimienio del programa. (Existe Independencia de fos datos cuando un eambio en el tipo de dato se aplica automaticamente en cascada a través de la base de datos por el DBMS, con lo que ve elimina la necesidad de realizar cambios en los segmentos del pro- sgrama que hacen referencia al tipo de datos cambiado.) 4. Integridad de lo base de datos: dada la relacién padre/hijo, siempre hay un vinculo entre el segmento padre y sus) segmentots)hijls). Como el segmento hijo siempre esté automatcamente relacionado con su padre. el ino- _delo jerérquico promucve la integridad de la base de datos. 5. Efclenclo: el modelo de base de datos jerarquico es muy eficiente cuando una base de datos contiene un gran vo- Jumen de datos en relaciones 1:M y cuando los usuarios requieren muchas transacciones en las que utlizan da- tos cuyas relaciones se mantienen fjas con el tiempo. “Gricias a su inherente superioridad sobre los sistemas de archivos. la base de datos jerdrquica se convirti6 rpidamente en el “ stema dominante en los afios 70. Tal dominio generé una gran base instalada (mainframes) la que. a su vez. cre6 un equipo © progremedores que conacian los sistemas y desarrollaban numerosas aplicaciones de negocios probadas y efectives. Desventasas ‘Aunque Ins bases jerarquicas y ss aplicaciones atin enisten, este madclo cayé en desgracia a finales de los 70 y principios 62 los 80. por varias razones: 1. Ejecucién compieja. eunque el DBMS del modelo jerérquico liber6 al disefador y programadar de los problemas de dependencia de los dalos, atin debian tener tin conocimiento detalado de las caracteristlcas de almacenamien- {0 de datos fisico: por lo tanto, la ejecucion de un disefio de base de datos podia complcarse mucho, 2. Difici! de adminastrar: cualquier camblo en la estructura de la base de datos, como la reubicacién de segmentos requiere un cambio en todos fos programas de aplicacién que tiene acceso ala base de datos. ce modo que la admi- islracign de la base de datos puede llegar @ ser una tarea muy dificil. ¥, si blen, fa estructura jeréraquica fornenta fa integridad de In base de datos. esta estructura también hace posible eliminar un segmento que conduzca @ la el rminacién invohintaria de todos los segmentos debajo de él, jun error que puede ser extremadamente costoso!3. Carece de Independencia estructural: existe independencia estructural cuando los cambios en la estructura de la base de datos no afectan la capacidad del DBMS de tener acceso a los datos. La base de datos jerérquica se conoce ‘como sistema navegacional porque el acceso a los datos requiere utlizacién de la ruta de almacenamiento fisico ppara “navegar” en direccion a los segmentos apropiados. Dentro de un sisterna de base de datos navegacional, el pprogramador debe conocer las ruias de acceso a segmentos pertinentes (el registro padre debe ser accesado pri: ‘mero, para tener acceso a los registros hijos) para recuperar datos de la base de datos. Las modificaciones en la estructura de la base de datos puede conducir a problemas con programas de aplicacién que estaban operando correclamente antes de que los cambios fueran hechos: los beneficios de fa independencia de los datos se ven limitados por lo tanto por la dependencia estructural. 4. Complejidad de fa programacién y uso de las aplicaciones: debido a la estructura del sistema de base de datos. navegacional, los programadores de aplicacidtes'y los usuarios finales deben conocer con precision cémo estan distribuidos lisicamente los datos en la base de datos para tener acceso a ellos. Aunque conozcan las rulas de 2¢- .ce50 a los datos, la oblencion de éstos requiore el conocimiento de sistemas indicadores complejos. Por Io tanto, se dice que las bases de datos jerérquicas fueron escritas por los programadores y para los programadores. 5. Limitactones de ejecucion: muchas relaciones comunes no se ajustan al estindar 1:M requeride por el modelo Jerdrquico. Por ejemplo, digamos que usted es un estudiante inserto en una universidad. Cada curso pueda contener muchos estudiantes y cada estudlante puede tomar muchos cursos. Esa relacién comin (M:N) es dificil de ejecutar cen un modelo jerérquico, Ademés, muy pocas retactones del mundo real estén basadas en un hijo con padres milk tiples. Por ejemplo. observe que la relacion mostrada en la figura 1.9 claramente ilustra un ORDER_LINE (LINEA _PEDIDO) que tlene dos padres ORDER (PEDIDO) y PART (PARTE). raeao ay FIGURA 1.9 Hio CON PADRES MOLTIPLES Cuando un cliente genera un pedido, la linea de pedido generalmente contiene datos tanto del segmento ORDER ‘como del segmento PART: Pedido: 10012 Cliente: 89221 Namero de parte: M-2W113 Esa relacién comtin de dos padres no puede ejecutarse fécilmente en un ambiente jerérquico. 6. Falta de esténdares: aunque el modelo jerérquico bésico esté incorporado a todo el software de base de datos Jerérquica, no hay un conjunto preciso de conceptos esténdar, ni la ejecuclén del modelo se ajusta a un esténdar cespecitico. Los problemas de ejecucién eran especialmente enfadosos porque el component de administracisn da la base de datos jerérquica carecia de un lenguaje de definicion de datos estandar (DDL, por sus siglas en inglés) para detinir los componentes de la base de datos, ni contaba con un lenguaje de manipulacién de datos (DML, por suis siglas en inglés) para manipulor el contenido de fa base datos. Aunque el software del sistema de administracion de la informacién (MS), desarrollado conjuntamente por IBM y North American Rockwell, legé a ser el DBMS jerr-ar i 0 P — quico predominante a finales de los aos 60 y en los 70, otros programas de software jerénquicos operaban fuera dal concepto y de los limites de la tecnologia creada por los sistemas de aciministracin de la informacién, Por lo tanto, el paso de un DBMS jerdrquico a otro fue dificil: es deci, su portatbilided fue limitada. En los afos 70, los profesionales cle las bases de datos convocaron a una serie de reuniones que culminaron con la pu bilicacién de un conjinto de estindares de bases de datos que a la postre condujeron al desarrollo de modelos alternos. El ‘mAs notable de ellos es el modelo de base de datos de red. 1.5.2 MODELO DE BASE DE DATOS DE RED EI modelo de base de datos de red fue creado para representar relaciones de datos complejas mas eficientes de lo que ‘al modelo jerérquico podta, para mejorar el desompotio de las bases de datos y para imponer un esténdar de base de da tos. La carencla de esténdares de bases de datos ponia en aprietos a los programadores y a los diseriadores de aplicacio~ res porque disefiaban bases de datos y aplicaciones menos portatiles. Ademds, la falta incluso de conceptos de bases de datos impedia la bisqueda de mejores modelos de base de datos. La desorganizacién a menudo rara vez promuave el progreso, Para tratar de establecer estindares de bases de datos, la Conference on Data Systems Languages (CODASYL) (Con ferencia sobre lenguajes para sistemas de datos) convocé a una reunién. El grupo CODASYL originalmente fue forma- do por usuarios y fabricantes de computadoras para crear un esténdar de"COBOL. Las recomendaciones de CODASYL. para COBOL, posteriormente, fueron acepladas por el American National Standards Institute (ANSI) como la especif cacién COBOL esténdar y de esa manera se cre6 el COBOL ANSI. Dado su éxito en ol desarrollo de esténdares COBOL. cl grupo CODASYL se dio a la tarea de presiar un servicio similar en la arena de las bases de datos, y cve6 el Database ‘Task Group (DBTG) (Grupo de tarea de base de datos}. EI DBTG se encargé de definir especificaciones esténdar para lun ambiente que facililara la creacion de bases de datos y la manipulacién de los datos. El reporte final del DBTG contenla especiiiaciones para tres componentes cruciales de una base de datos: 1. El esquema de red, la organizacion conceptual de toda la base de datos vista por su administrador. El esquema incluye una definicién del nombre de base de datos, el tipo de cada registro y los componentes que integran di- chos registros, 2. El subesquema, que define una parte de la base de datos “vista” por lo programas de aplicacién que en realidad producen la informacién deseada a partir de los datos contenidos dentro de le base de datos. La existencia de def- niciones de subesquema permite que todos los programas de apllcacién solamente invoquen el subesquema reque- ido para tener acceso al archivols) apropiado de la base de datos. 3. Un lenguaje de administracién de datos para defini las caracteristicas y estructura de éstos para manipulattos. Para producir la estandarizacién deseada para cada uno de los tres componentes. el DBTG especifis tres componentes de longuaje de administracton de datos. Un lenguafe de definicién del esquema (DDL, por sus sglas en inglés), que permite qua el administrador de la base de datos defina los componentes del esquema 2, Un lenguaje de definici6n del subesquema (DML, por sus siglas en inglés) para manipular el contenido de la base de datos. 3. Un Jenguaje de manipulacién de datos (DML) para manipular los datos de las bases, En 1975 el ANSI Standards Planning and Requirements Committee (SPARC) (Comité de requerimientos y planificacion de esténdares ANSI) increment6 los esténdares de bases de datos. Se esperaba que todo el software de las bases de da- {os de red de compuiadoras “mainframe” se ajustaran al esténdar del DBTG, Por consiguiente, si se cumpian los estin- dares, los diseiadores y usuarios fendian pocos problemas al cambior de una aplicacién comercial a otra cuando operabn ‘al nivel conceptual o de esquema. Desafortunadamente, los esténdares a menudo se “ampliaban” para satisfacer las me joras de software del vendedor.ESTRUCTURA BASICA En muchos aspectos ol modelo de bases de datos de red se parece al modelo jerérquico. Por ejemplo, ast como en el delo jerérquico, e! usuario percibe la base de datas de red como un canjunto de registros en relaciones 1:M. Sin em: a diferencia del modelo jerdrquico, el de red permite que un registro tenga més de un padre. Por consiguiente, las rela: comiénmente encontradas en la figura 1.9 pueden manejarse (écilmente por el modelo de base de datos de red, En la terminologia de bases de dates de red, una relacin se lama conjunto, Cada conjunto se compone de por fo m=: dos tipos de resist: un registro propietario que equivale al padre del modelo jerérauico y un registro mlembro que = vole al hijo del modelo jerd:quico. La diferencia entre el modelo jerdrquico y el de red es que éste podria incluir una dicién en la que un registro puede aparecer (como miembro) en mas dz un conjunto. En otras palabras, unt mew puede (ener varios propietarios. Un conjunto representa iina relacién 7:M entre el propietario y ef miembro, En ura 1.10 se iustra una relacién como ésta, CUSTORER at FIGURA 1.10 MODELO DE BASES DE DATOS DE RED La figura 1.10 ilustra un ejemplo de un modelo de bases de datos de red de una organizcion de ventas representa En este modelo, CUSTOMER, SAI.ESREP, INVOICE, INV_LINE, PRODUCT y PAYMENT represenian tipos de rogistro ‘Al examinar la ligura 1.10, se observa que INVOICE es “propiedad’ tanto de SALESREP como de CUSTOMER. Asimisina INV_LINE tiene dos propietarios, PRODUCT e INVOICE. Pero observe que el modelo de red atin puede incluir relac ‘uno-propiatario (por ejemplo, CUSTOMER makes PAYMENT [CLIENTE hace PAGO)) (que son propias de un modelo de bbases de datos jerdrquico. La base de datos de red, en l figura 1.10, tstra transacciones basadas en una serie de relaciones uno a muchos. 1. Un (REPVENTAS} SALESREP podria haber escrito muchas notas de FACTURA INVOICE tickets). pero cada nota de FACTURA (INVOICE ticket) era escrita por un REPVENTAS (SALESREP). Por lo tanto, existe una relaci6m: 1:M entre REPVENTAS (SALESREP) y FACTURA (INVOICE). 2, Un CLIENTE (CUSTOMER) podria haber realizado compras en varias ocasiones. Cada que se hace una compra. s@ ‘escribe una nueva nota de FACTURA (INVOICE ticket); es decir, un CLIENTE (CUSTOMER) puede haber genera~ do muchas notas de FACTURA (INVOICE tickets) con el tiempo, pero cada FACTURA (INVOICE) pertenece so lamente a un CLIENTE (CUSTOMER). Por consiguizme, existe una relacién 1:M entre CLIENTE (CUSTOMER) y FACTURA dNVOICE) 3. Cada producto adquiride se pone en lista en una de las lineas de facturacién. Como un cliente puede adquirir més de un producto a la vez —por ejemplo, usted puede comprar un desarmador, una caja de tornillos y una lata de pintura durante su visila a una tienda— cada factura puede tener una o mds jineas en ella. Pere cada INV_LINE(LINEA_FAC) que ocurre en una FACTURA (INVOICE) en particular “pertenece” a dicha factura. Por consigulente, existe una relacién 1:M entre INVOICE e INV_LINE. 4. Cada linea de fachrracién se reliere a un producto, Pero. como una tiende puede vender muchos desarmadores durante cunkquier época, un producto puede aparecer en varias lineas de lacturacién dilerentes. Por consiguiente, existe una relacion 1:M entre PRODUCT ¢ INV_LINE. 5. Un cliente puede realizar muchos pagos durante un determinado tiempo: pero sélo un ellonte realza cada pago. Por consiguiente, existe una relaci6n 1:M entre CUSTOMER y PAYMENT. VENTAIAS © modelo de bases de red consena muchas de las ventajas del jerérquico, y al mismo tiempo comrige muchos de sus ecto Simplicided conceptual: al igual que e! modelo de bases de datos yerérquico. la vista conceptual de fa base de da- t05 es simple y por lo tanto simplifica el dseiio. ‘Moneja més tipos de refaciones: las relaciones M:N son mas féciles de ejecutar en el modelo de bases de datos de ted que en el jerérquico. Observe. por ejemplo, que el modelo de bases de datos de ted mangja faciimente la relacin expresada por “un producto puede ser vendido a mucho clientes. y un cliente puede comprar muchos pro- dductos’ en el ambiente de propietarios mitiples de la figura 1.10, 2 Flexibilidad de acceso a los datos: la flexibiidad de acceso a los datos es superior que la del modelo erérquico y la de sistemas de archivos. Una aplicacién puede tener acceso a un registro propietatio y a todos los regisros miem- bro dentro de conjunto. Por consiguientc, si un registro miembro tiene dos © més propielarios, como en la figura 1.10, puede pasarse directamente de un propictario a otro. (En suma. iva no se requiere la ruta preordenada!) Promueve la integridad de la boses de datos: el modelo de bases de daos de red hace que se cumpla la integridad de la base de datos. yo que el usuario primero debe definir el registro propietario y luego el miembro. (Un miem- bro no puede existir sin un propietario.) Independence de los datos: el modelo de bases de datos de red ofrece una independencia Suliciente de los datos para. por lo menos. aishr parciaimente los programas de los detalles de almacenamiento fisco complejos. Por con siguiente, los cambios en las caracterstcas de los datos no requeren cambios en las partes de acceso a los datos de los programas de aplicacion Cumpliniento de esténdares: la existencia de la base de datos de red se remonta parcialmente a los esténdares de base de datos impuesia en los 70. Estos esténdares incluyen un DDL y un DML. por lo que se facilita en gran medida la administracion y portatibiidad de las bases de datos. DEsvENTAsAS ue el modelo de bases de datos de red ofreci6 ventajas importantes comparadas con el modelo jerdrquico, ain estaba “10 2 desventajas significatives: 1 ‘Complejidad del sistema: el control de la integrided de la base de datos y la eficiencia con la que el modelo de red ‘mane las relaciones, en ocasiones se ve anulada por la complejidad del sistema. Al igual que el modelo jerérauico, " sseiiadenes de dagyames de EntidathRelacign uilzan “entilad” camo un substitute de “conjunto de entitlades", ¥ “= sexuitd esa prdctica cuanclo se analice cualquier diagrama de Eniidad-Relacin y sus componente. ‘enlidad se describe mediante un conjunto de atributos. Un atributo describe una caracteristica en particular de la en- Por ejemplo. la entidad EMPLOYEE tendré atrbutos como nimero de seguro social apellido y un primer nombre, + Una relackin describe una asociacién entre los datos. La mayorta de las relaciones deseriben asociaciones entre dos centidades. Cuando s2 introdujeron los modelos de base de datos, se ihstraron tres tipos de relaciones posibles entre fos datos: uno a muchos (I:M), muchos a muchos (M:N] y uno a uno (1:1). Los modelistas de diagramas Entidad- Relaci6n ullizan el término conectividad para designar las clasificaciones de relacin. {Las conectividades se es- criben Junto a cada cuadro de entidad.) Las relaciones se representan por modio de un diamante conectado a las entidades relacionadas. El nombre de la relacién. un verbo activo © pasivo, se escribe adentro del diamante. Por ‘ejemplo, cada uno de Jos DEPARTAMENTOS de Ja compatia tiene muchos EMPLEADOS y un PINTOR pinta ‘muchos CUADROS. 4 “figura 1.13 se tustra el uso de diagramas de relacién de entidades. mediante las relaciones que se analizaron cuando “-roxujeron los modelos de base de datos en la seccién 1.5. Relocién uno © muchas (I:M): un PINTOR puede pltar ‘ucts CUADROS; cada cuadro ws pitada por un PINTOR. Relocién muchas a muchos (M:N): un EMPLEADO puede ‘aprender muchos HABILIDADES; cada HABILIDAD ‘puede Ser oprencid par muchos EMPLEADOS [ee Se] Retocién uno a uno. ): un EMPLEADO manejo una tendo; ‘cada TIENDA ¢s monejada por un EMPLEADO pesar de la representacion del modelo E-R, el ERD se ha convertido en la herratnienta favorita en el arsenal de disetio “> bases dle datos de produccién, aunque los diseftadores adn tienen alguna reservas sobre su uso. 1. Representacién de resirleclones limitada: el modelo muestra {écilmente las restricclanes que estén directamente vinculadas a las conectividades. Por ejemplo, la resiriecién “un profesor puede ensefiar fan poco como ninguna dase” —an profesor investigador— , pero no més de cuatro” puede tisrarse[aclmente. Desgraciadamente, oxsten ‘muchas restricclones importantes relacionadas con datos que no pueden ser modelados, Por ejemplo, restrcciones como “la calificactén promedio de un estudiante oscila entre 0.0 y 4.0” y “un piloto no puede ser programado para miss de 10 horas consecutivas de trabajo”, no pucden ser representadas. En su lugar. estas restricciones deben ser meancjadas al nivel de la aplicacion. 2, Representacion de relaciones limttada: las relaciones se representan tal como ocurren entre las entidades. Por lo tanto, las relaciones entre atibuios dentro de entidades no pueden representarse. Por ejemplo, no hay forma de representar la relacin entre la clasficacién de un estudiante y st total de horas acreditadas. Ademss, cuando las entidades tienen mditiples relaciones con otras entidades, cl significado de dichas relaciones puede obscurecerse. 3. Ningan lenguaje de manipulacién de datos: los proponentes del modelo relacional generalmente seftlen Ia ca- rencia de comendos de manipuiacién de datos en el modelo de datos Entided-Relacién. Debido a esto, el modelo ER no esté “completo”, 4. Pérdida de contenido de informacién: los modelos tienden a “apretujirse” cuando los atributos se representan. Por lo tanto, los disefadores de bases de datos generalmente evilan el mapeo de los atributos, con lo que disminuye el contenido de informacién del modelo. © ocasiones, las desventajas del modelo diticultan el modelado de los tipos de datos y de las relaciones complejas que cada ‘== son mis comunes en el ambiente de bases de dates. Sin embargo, a pesar de sus desventajas, la herramienta de mode- “= del modelo E-R, el ERD ha sobrevivido y prosperado. De hecho, los vendedores han agregado tantas extensiones a la “Serentacién bésica del ERD. que sigue siendo la herramienta dominante de disefio de bases de datos. No obstante, la bis: ‘so de mejores herramientas de modelado de datos contintia. a medida que ol ambiente de datas sigue evoluclonando. 95:5 MODELO DE BASES DE DATOS ORIENTADA A OBJETOS. "== cada vez més complejos problemas del mundo real demostraron que se requiere un modclo de datos diferente que re- ‘Sresente con mas fidelidad el mundo real. El primero de estos modelos fue el modelo de datos seméntico (SDM, por ‘= sialas en inglés), desarrollado por M. Hammer yD. McLeod y publicado en 1981 en su “Database Description with DM. A Seméntica Database Model” (ACM Transactions Database Systems 6:3). © SDM model6 tanto datos como sus relacones en una sola estructura conockda como objeto. Debido a que su estructura “tsca de modelo es un objeto, se dice que el SDM es un modelo de datos orlentado a objetos (OODM, por sus siglas = inglés. A su vez, ol OODM se convierte en la base del modelo de base de datos orlentado a objetos (OODBM, por “= siglas en inglés), el cual es manejado por un sistema de administracién de base de datos orientado a objetos {O0DBMS). {En esta scin se inroducirin solo ures cuantos “Tundamentos” de orientaciin a objetos que nos ayudarin a enten- | deel impacto de los conceptos de anentacidn a ubjetos en les sistemas de madclid de datos y en fo sistemas de "_adiminksracién de base de datos. Tendremos la oportunidad dle examinar a detalle ls conceptos y principios de oren- tacién a objetos en e! capitulo 11: “Bases de datos oriontadas a objetos". in CODM refleja una manera muy diferente de definir y utilizar las entidades. Al igual que la entidad de un modelo de ‘ase de datos relacional, un objeto es descrilo por su contenido de hechos. Pero, completamente distinto a una entidad. ‘un objeto incluye informacién sobre la relacién entre los hechos dentro del objeto, lo misma que informacién sobre sus re- Ibciones con otros objetos. Por lo tanto, a los hechos dentro del objeto se les otorga un mayor significado.(carirvce 5 La palabra semintica incliea significado. Por consiguiente, en téiminos de hase de datos orienta a objetes, se dice que 1 objeta tiene contenido seméntica. Es por eso que Hammer y McLeod nombraron a su ceacién, modelo dle base do dates seménticn. El subsiguiente desarrollo del OODM permitié que un objeto también inchiyera todas las operaciones que pueden sor re zada en él, por ejemplo, cambiar el valor de sus datos, localizar un valor de un dato especifico e imprimir valores de dat ‘Como los objetos incliyen datos, varios tipos de relaciones y procedimientos operatives, el objeto llega a ser aut6nor: por lo que el objeto —por lo menos potencialmenté— ge convier'e en el bloque de construccién de estructuras aulénon ‘Aunque los conceptos de orientacién a objetos (00) se han utlizado desde los afos 70, por lo menos cuatro desarrol: impulsaron el abasto del modelo de datos orientado a objetos en los afios 90. 1, El costo creciente le generar y mantener los programas de computadora cada vez més complejos, agreg6 valor la reutizacion del cédigo. La manera més eficente de alentar la reutiizacién del codigo es aseauréndose de que programas se escriban en médulos auténomos que realicen funciones especifcas. Tales médulos prieden, entone ser “dispuestos" de diferentes maneras para crear una amplia variedad de aplicaciones. Las caracterstcas del dclo de datos orientado a objetos resultaron sor particularmente promisorias en el érea del concepto modblar. 2. Es probable que las bases de datos modemas incluyan gréficos, video y sonido, ademés de texto y niimeros. Los querimientos de sistema y de tipos de datos cada ver més complojos comenzaron a agobiar a los procedimientos procesos de elecucion de la base de datos relacional. Como los tipos de datos complejos son el enfaque del mod de datos orientado a objetos, este modelo se convitié en fundamento natural del modelo de base de datos orientado objotos. 3. A medida que el ambiente de datos se volvia més complejo, fue posible soportar los requerimentos de transaccio ¢ informactén cada vez més dificles. Por ejemplo, a una compaiia de transporte de carga ahora le era posible a= nerar mapas ad hoc en los cuales se podia mostrar la ubicacién de sus camiones. el destino de cada uno, su cor tenido y su hora estimada de Iegada. Una compaitia de ingenieria podria desear generar vistas de cada una de piezas de un producto para.repararlo mientras el cliente esté al teléfono, 4. El poder de compulacién cada vex mayor permitié solventar los grandes gastos indirectos necesarios para soport los complejos procesos y procedimientos de datos orientados a los objetos. —FRGTR £1 modelo de ditos orienta 4 tos objetos iene sus raices en el trabajo realivalo en fos hos 70 en ol conto de inves a rere a ee |i computacién que sctualmente se dan por sentado: interfaces gfcas te usuario el ratdin de la cumpotatora, correo electrSnica y los lenguajes de programacién orientadls a los objetos. ESTRUCTURA BASICA El modelo de datos orientados a Jos objelos esté basado en por los inenies los siguientes components: + Los objetos del modelo de datos son abstracciones de entidades 0 eventos del mundo real. En términos generales, objeto puede considerarse como equivalente a una entidad del modelo E-R: ws decir. un objeto representa s6lo uni ‘ocurrencia individual de una entidad, (El contenido semdntico del objeto se define mediante varias elementos de esta lista.) nee eee ee ‘ndmero de seguro socal y fecha de nacimionto.* Los objetos que comparten caracteristicas similares se agrupan en clases. Una clase es un conjunto de objetos si- milares con estructura (aributos) y comportamiento {métodos) compartides. En un sentido general una clase se pare- ce al conjunto de entidades del modelo E-R: sin embargo, una clase es diferente de una entidad en que contiene una serie de procedimientes conocidos como métodos. Un método de clase representa una accién del mundo real tal ‘como localizar el nombre de una PERSONA, cambiar el nombre de una PERSONA o imprimir el nombre de una PERSONA. En otra palabras, los métodos equivalen a los procedimientos en lenguajes de programacién tra dlelonales. En términos de orientacién a los objetos, los métodos definen el comportamiento de un objeto, (Algunas variantes del modelo de datos orientade a abjetos —como el modelo de objetos seméntico— no ineluyen métodos en su representacion.) *+ Las cases se organizan en una Jerarquia de clase. La jerarquia de clase se parece a un Arbol invertido donde cada estructura de archivo mostrada en la figura P.1, responda las preguntas de la 1 a la 6. x : ‘1609.40000 {21s cw Nar, 12000000 |r2e pier erent igs | aa 000 [Putian Ganervie L123 szte3.94c0 10ar4 54600 FIGURA PI.1 ESTRUCTURA DE ARCHIVO DE LOS PROBLEMAS 1A 6 “Cuintos registros contlene el archivo y cusntos campos hay por registro? Que problema encontraria si deseara producit una lista por ciudad? ¢Céino resolverta este problema modiicando “estructura de! archivo? * deseara elaborar una lista del contenido del archivo por apelido, cédligo de rea, ciudad, estado 0 cédigo postal, “mo modiicara la estructura del archivo? Qué redundancia de datos detect6 y explique cémo éstas podrian conducir a anomalies? "Hlzando dos tablas de bases de datos relacional, PROJECT y MANAGER, elimine las redundancies descublertas = el problema 4. Asegirese de utilizar las convenciones de nominackén presentadas en la seccién 1.3.3 y conecte “dos tablas mediante un vinculo apropizdo, (Sugerencia: use la figura 1.11 como efemplo) -Pealice el esquema relacional para demostrar cémo estén vinculadas las dos tablas de bases de datos en el problema 5. ‘estructura del archivo mostrado en la figura P1.7. rasuelva los problemas del 7 al 13. FIGURA P1.7 ESTRUCTURA DE ARCHIVO DE LOS PROBLEMAS 7 A 13 “Wentifique y analice los serios problemas de redundancia de datos exhibidos por la estructura de arehivo mostrada en figura PLT Cuanias fuentes de datos diferentes podrian ser utilizadas por el archivo que examiné en el problema 7? ‘Dados sus hallazgos en los problemas 7 y 8, c6mo ayudaria el ambiente de bases de datos relacional a eliminar los problemas de redundancia de datos? ‘Dada su respuesta al problema 9, ;cu‘inlas tablas utilizarfa para ellminar sustancialmente los problemas de redundancia de datos? {Qué estructuras de tabla recomendaria? Dadas sus respuestas al problema 10, muestre el contenido de cada tabla.Bc + 12, 13, 14, Ientifique los tipos de relaciones (I:1, 1:M 0 M:N) entre las tablas definidas en los problemas 10 y 11. (Nota: te las relaciones en la forma de los dlagramas mostrados en la seccién 1.5, “Modelos de bases de datos",) Realice un esquema relacional, como el dela figura 1.11, para el problema 12. Dada la estructura de la tabla mostrada en la figura P1.14, zqué problemals) podria enfrentar si elimina el de edificio KOM? FIGURA P1.14 ESTRUCTURA DE TABLA DEL PROBLEMA 14 15, Uiiice la representacion jerirquica mostrada en la figura P1.15 y responds los incisos a, by c. 16. Nombre Nombre de tribute anie PAINTER PT_NUMBER (RES) PLNAME Me prpwone Eee) PAINTING —_PTG_NUMBER PIG_ITLE Fe) Pree) ord oc bi FIGURA P1.15 ESTRUCTURA JERARQUICA DEL PROBLEMA 15, fa. Identifique los tipos de segment, 1b, dentifique los componentes equivalentes a los campos del sistema de archivos. ¢. Describa la ruta jerérquica para la ocurrencia del tercer segmento PAINTING. El diagrama de red, mostrado en la figura P1.16, iustra la ocurrencia de un registro de la paciente Judy D. Johan En general, un paciente hospitaizado recibe medicamentos que han sido prescritos por un doctor en part ‘Como el paciente a menudo recibe varios medicamentos al dia, existe una relacién 1:M entre PATIENT (PACI» y ORDER (PRESCRIPCION). Asimismo, cada prescripcién puede inclulr varios medicamentos, lo que crea una rolacién 12M entre ORDER (PRESCRIPCION) y MEDICATION (MEDICAMENTO). pe PATIENT moors PAT_NUMBER aise 3 PAT NAME er ORDER s ORD_NUMBER 3291233 oRD_pATE Pea) oro.ooctor = ewe} Rr) in pete Seen MEDICATION (MED_NUMBER Urea sis (MED_OOSAGE eee “ash Peers slant Taree Sey) FIGURA P1.16 ESTRUCTURA DE LA RED PARA EL PROBLEMA 16 ‘ada la estructura mostrada en la figura P1.1 . a, _ Sdentifique los tipos de segmento. 'b. Identifique los componentes que equivalen a los campos de sistema de archivos. Deseriba la ruta'jerérquica para la ecurrencia del segundo segmento MEDICATION. 17 Expanda el modelo del problema 16 para incluir un segmento DOCTOR, luego, dibuje su estructura jerarquica, (Iden- tifique todos los segmerntos.) (Sugerencia: un paciente puede tener varlos doctores asignados al caso, pero la paciente Judy D. Johansen ocurre dnicamente una vez en cada uno de los registros de esos doctores.) +3. Suponga que desea escribir un reporte que muestre: hy a. Todos los pacientes tratados por cada doctor. b. Todos los doctores que trataron a cada paciente Evalie la estructura jerérquica que dibujé en el problema 17 en funcién de su eficiencia de basqueda para producir el reporte. 19. La compaiiia PYRAID desea dar seguimiento a cada PARTE (PART) utilizada en una pieza de EQUIPO (EQUIP- MENT) espeeifica: cada PARTE (PART) es surtida por un PROVEEDOR (SUPPLIER) en particular. Con esta des- cripeidn. dibuje la estructura de red ¢ identifique los conjuntos para la base de datos de la comparifa PYRAID. . (Sugerencta: una pieza de equipo se compone de muchas partes, pero cada una se utiliza solamente en una pieza per de equipo determinada. Un proveedor puede surtir muchas partes, pero cada una ha sido surtida tinicamente por Pe tun proveedor)