Diseno conceptual de bases de datos UN ENFOQUE DE ENTIDADES-INTERRELACIONES BATINI CERI NAVATHE Som ADDISON-WESLEY/DIAZ DE SANTOSDisefio conceptual de bases de datos Un enfoque de entidades-interrelaciones Carlo Batini Université di Roma «La Sapienza» Stefano Ceri Politecnico di Milano Shamkant B. Navathe Georgia Institute of Technology Version en espaitol de Victor Martin Garcia Diego Romero Ibancos Universidad Pontificia de Salamanca Campus de Madrid. Espana Con la colaboracién de: Luis Joyanes Aguilar Universidad Pontificia de Salamanca ‘Campus de Madrid, Esparia Américo Vargas Villazon Heuresis, SRL La Paz, Bolivia ADDISON-WESLEY/DIAZ DE SANTOS Argentina - Brasil - Chile - Colombia - Ecuador - Espanta Estados Unidos - México - Peri: Puerto Rico» VenezuelaVersién en espanol de la obra titulada Conceptual Database Design: An Entity-Rela- tionship Approach, de Carlo Batini, Stefano Ceri, Shamkant B.Navathe, publicada ori ginalmente en inglés por Addison-Wesley Publishing Company, Inc., Reading, Massachusetts, E.U.A. © 1992 Esta edicién en espafiol es Ia tinica autorizada. Copublicacién de Addison-Wesley Iberoamericana, S.A. y Ediciones Diaz de Santos, S.A. © 1994 por Addison-Westey Iberoamericana, S.A. Wilmington, Delaware. E.U.A Reservados todos los derechos. «No esté permitida la reproduccisn total o parcial de este libro, su tratamiento informatico, ni la transmisién de ninguna forma o por cualquier medio, ya sea electronico, meedinico, por fotocopia, por registro u otros métodos, sin el permiso previo y por escrito de los titulares del Copyright» Impreso en Estados Unidos de América. Printed in USA. ISBN: 0-201-60120-6 123456789 10-MA-99 98 97 96 95 94A mis padres: Curzio, fallecido en 1975, y Laura, fallecida quince aftos después. CaRLo Barint A mis padres: Luciana Arcidiacono y Mauro Ceri. STEFANO CERI A mis padres: Bhalchandra y Vijaya Navathe, por su aliento y apoyo, SHAMKANT B, NAVATHEContenido Primera parte. Disefio conceptual de bases de datos......... 1 L_Una introduccisn al disefto de basesde datos 0D 2. Conceptos sobre el modelado de datos .. wae 17 3. Metodologia para el disefto conceptual cee OF Di Si Integracion de vistas... esse . 137 6. Como mejorar la calidad de un esquema de base de datos 159) 7. Documentacién y mantenimiento de esquemas . 193 Segunda parte. Analisis funcional en el diseiio de bases de datos soscseeseesacessenee 221 8._Anilisis funcional usando el modelo de flujo de datos. 2 223 ‘Tercera parte. Disefo l6gico y herramientas de disefio 307 LL. Diseno logico de alto nivel usando el modelo de entidades-interre- Taciones 15, Herramientas de diseho de bases de datos 465 Indice on0mSti00 eS Ses oniIndice general Primera parte. Disefio conceptual de bases de datos ....... 1 Interaccion entre el diseno de bases de datos y el andlisis funcio- [| ESESESSEUSEESSESLSSEESUSSUSSSSESUESNSSUCSNESUNCUENEE] Modelos y herramientas para el disefio de bases de datos y el and- isis funcional Por que es valioso el disefto conceptual? . severe 12 Resumen 2. Conceptos sobre el modelado de datos 17 Abstracciones en el diseo conceptual de bases de datos........ 17 Propiedades de las correspondencias entre las c Lectura de un diagrama de entidades-interrelaciones .......... 54 ROM SS 3._ Metodologia para el disefo conceptual... 2. ee 65 Resumen 93 4. Disco de vistas Diseio de vistas a partir de requerimientos expresados en len- guaje natural coe a 100 Diseto de vistas a partir de formularios ..... 107INDICE GENERAL Diseo de vistas a partir de formatos de registros 7 Analisis y resoluci6n deconflictos..0 18? Fusion de vistas ak Resumen pe LH 6. Como mejorar la calidad de un esquema de base de datos ........ 159 ‘Cualidades de un esquema de base de datos... 160 Transformaciones de esquemas 165 ‘Transformaciones para lograr minimalidad ......... 166 Transformaciones para lograr expresividad y autoexplicacion ... 169 Transformaciones para lograr normalizaciOn .......0..cs:..02 172 Ejemplo de reestructuracién de un esquema ........ 185 ReSUMEN eee teen eeeeennennesneteneeneeeneeneeneee 188 7. Documentacién y mantenimiento de esquemas ...2...2.c002. 193 ‘Una metodok ra document 4 Mantenimiento de esquemas conceptuales 203 Estructura y disefo de un diccionario de datos ................ 209 ReSUMON eee 216 Segunda parte. Analisis funcional en el diseho de bases de 221 El modelo de flujo de datos para el andlisis funcional .......... 224 Primitivas para el andlisis funcional... 227 Cualidades de un esquema funcional . wees. 239 Documentacién y mantenimiento de un esquema funcional... 242 ReSUMEN oe cetcsecceecteseeessecsserressasesersesaees 243 Apéndice. Repaso de modelos para el andlisis funcional .........._ 247 9. Analisis conjunto de datos y funciones .- soe perrer 257 ‘Esquemas externos para los diagramas de flujo de datos 258 Ina metodologia para el andlisis conjunto de datos y funcional __260 Sg ncias para refinamientos mutuos .............+ 1 267 Esquemas de navegacin para operaciones con bases de datos ..__ 270 ResumenINDICE GENERAL x LO Estudio de un C50 eect eee e tte teteeeeesen 277 Requerimientos cose 27 Esquemas de armazén 279 Primer refinamiento....-.....---+ 282 ‘Segundo refinamiento . 291 296 vtsetetseneaes terse 298 RESUMEM oe ese ceseeeectresensertcsensessossessesss 303 Verificacion de compl Tercera parte. Disefio légico y herramientas de disefio ......__307 L1._Diseno ligico de alto nivel usando el modelo de entidades-interre- laciones poets 309 Un enfoque global del diseno l6gico ............. Modelado de la carga de bases de datos... ss. 313, Decisiones sobre datos derivados Eliminacién de jerarquias de generalizacién 320 Particidn de entidades ....... veveeeeee 327 Eusiin de entidades ¢ interrelacionss os 331 SelecciGn de claves primarias 20.2.0... seseeeee 332 Disefto l6gico de alto nivel en el caso de estudio... 334 Resumen vecseseeee ve 344 12._Disefio légico en el modelo relacional a sees 351 ELmodelo relational Correspondencia de esquemas del modelo ER al modelo relacio- Correspondencia de operaciones de! modelo Ex al modelo rela- cional ... ceeceecses : 369 Base de datos del caso de estudio en el modelo relacional 369 Retroingenieria de los esquemas relacionales a esquemas ER... 374 Resumen RR 13. Diseito ldgico en ef modelo de redes .........e sss sa 395 El modelo de redes 396 Correspondencia de esauemas del modelo ex al modelo de redes . 401 (Correspondencia de operaciones del modelo ER al modelo de re- ES tet te en eeettenneeetnetnnennee lL Base de datos del caso de estudio en el modelo de redes .... 414 Retroingenieria de los esquemas de redes a esquemas ER 418 Resumenx INDICE GENERAL Correspondencia de esquemas del modelo ER al modelo jerér- quico . settee 437 Correspondencia de operaciones del modelo rx al modelo jerir- Base de datos del caso de estudio en el modelo jerdrquico ....... 450 Retroingenieria de esquemas jerdrquicos a esquemas ER ....... 455 Resumen ee et BSD 15. Herramientas de disefto de bases de datos 00. 465 Ingenierfa de software asistida por computador ....- see 466 C $ 3 AOS ee AOD Falta de concordancia entre metodologias y herramientas ....... 473 Herramientas hasicas para el disefio conceptual 475 Herramientas basicas para el disefio logico . 481 Herramientas actuales de diseio de bases de datos orientadas a la investigaciOn ......sseescesessesseesesseessaseseneeseses 482 Herramientas actuales de disefio de hases de datos comerciales. 488 Herramientas Case comerciales actuales que permiten disenar bases de datos . : Resumen de herramientas comerciales... Limitaciones de los entornos de disco automatizado de bases de datos . 505 ‘Tendencias en los entornos de disefio automatizado de bases de AOS 62sec cece ceseeteeeeeeteeeseteeseseseteessesss 506 Vocabulario técnico bilingte a sevseseeis SITPrefacio Antecedentes Site mucho tiempo, el disefio de bases de datos fue considerado tuna tarea para expertos: mas un arte que una ciencia, Sin embargo, se ha pro- aresado mucho en cl disefto de bases de datos y éste se considera ahora una dis- ciplina estable, con métodos y técnicas propios. Debido a la creciente acepta- cin de las bases de datos por parte de la industria y el gobierno en el plano comercial, y @ una variedad de aplicaciones cientificas y técnicas, el diseiio de bases de datos desempefia un papel central en el empleo de los recursos de in- formacién de la mayoria de las organizaciones. El disenio de bases de datos ha pasado a constituir parte de la formacidn general de los informaticos, en el mismo nivel que la capacidad de construir algoritmos usando un lenguaje de programacidn convencional El diseto de bases de datos se realiza por lo general en tres fases. La primera fase, llamada de diseflo conceptual, produce una represemtacién abstracta y de alto nivel de la realidad, La segunda fase, llamada de diserio ldgico, convierte esta representacién en especificaciones que pueden implantarse en un sistema de cémputo y ser procesadas por él. La tercera fase, llamada de disero fisico, determina las estructuras de almacenamiento fisico y los métodos de consulta requeridos para un acceso eficaz a los contenidos de una base de datos a partir de dispositivos de almacenamiento secundario. Este libro trata las dos primeras fases del diseno de bases de datos, con una ‘marcada orientacién hacia los asuntos relacionados con el usuario y con la apli- cacién, més que hacia un sistema y entorno especificos de software/hardware. Las fases del disefto logico y conceptual pueden desarrollarse independiente- ‘mente de \a eleccién de un sistema de administracion de bases de datos (DBMS, database management system) espeetfico. Por tanto, se supone el conocimiento de los conceptos generales de bases de datos, o bien que la mayorfa de los lee- tores tienen alguna experiencia con los DBMS,xv PREFACIO Propésito Creemos que una ejecucién sistematica y minuciosa de estas primeras fases de disefio rinde un gran beneficio a largo plazo. En realidad, muchas organiza- dando cuenta de la necesidad de crear un diseio I6gico y con- ceptual, al mismo tiempo que se inclinan hacia la tecnologia de bases de datos, relacional y orientada a objetos. En este libro se usa el modelo entidades-interrelaciones (£1) de Chen, con algunas afadiduras necesarias para una mejor representacion conceptual. Este ‘modelo se usa ampliamente en muchas metodologias de disefio como una re- presentacién grafica eficaz, y es el estdndar «de facto» para la mayoria de las, herramientas automaticas de apoyo al diseno de bases de datos. Si bien este li- bro se centra en el disenio conceptual de bases de datos, se muestra una meto- dologia para la realizacién conjunta del diseno conceptual de bases de datos y el analisis funcional. Este enfoque mixto se basa en técnicas bien conocidas, co- munes a ambos enfoques, del libro Los objetivos principales de este libro son los siguientes: * Offecer un tratamiento minucioso y sistematico del disefio légico y con- ceptual. ‘* Basar este tratamiento en el muy acogido modelo de entidades-interrela- ciones. ‘* Recomendar que el disefio conceptual y el andlisis funcional se desarro- len a la par. ‘© Tratar de manera completa la conversion del disefio conceptual en el mo- delo de entidades-interrelaciones a los tres modelos populares de bases de datos: relacional, de redes y jerarquico. Asimismo, se presenta la proble- matica de la retroingenieria desde estos tres modelos al modelo ER ‘ Ilustrar los conceptos mediante un caso de estudio realista y extenso, © Ofrecer una vision general de la ultima tecnologia en el campo de las he- rramientas de disefo. ‘* Offecer suficiente apoyo pedagogico para los estudiantes de este tema, en terminos de ejercicios y notas bibliograficas sobre la literatura pertinente. A quien va dirigido La actividad mas importante en el diseto conceptual es entender y modelar la realidad; esta tarea es dificil y cominmente s6lo es desarrollada por expertos. Una vez asimilada, la labor del disento logico es bastante simple y directa. El objetivo principal de este libro es tratar el diseto conceptual, no sélo para be-Perfil del PREFACIO xv neficio de los expertos, sino para introducirlo a un publico mas amplio com- puesto de: 1. Estudiantes, que reclaman un tratamiento preciso y riguroso del diseao conceptual y ldgico de bases de datos para completar un primer curso s0- bre modelos y sistemas de bases de datos. 2. Profesionales en ejercicio (administradores de bases de datos, analistas, consultotes y programadores de bases de datos), quienes haran uso de este material para formalizar y resolver problemas de disedo de bases de da- tos, con frecuencia mal definidos. Ciertamente, la metodologia presen- tada en este libro puede apticarse a a mayoria de los diseftos y, ast, ay dar a los disehadores a resolver sus problemas de disefio de forma sistematica 3. Usuarios de bases de datos, quienes necesitan una cultura bdsica sobre el tema para comunicarse con el personal de administracidn de bases de da- tos y poder especificar sus necesidades, Asimismo, sera capaces de ob- servar y controlar el proceso de diseno y entender el significado y la es- tructura de la base de datos almacenada en su sistema de informacién Los contenidos de este libro son auténomos: todos los conceptos se definen antes de ser usados. Sin embargo, el librono incluye una descripcién de las car racteristicas de los sistemas de bases de datos o de las lenguajes que pueden usarse en la programacion de sistemas de bases de datos, Por esto, e5 requisite previo algin conocimiento sobre sistemas de bases de datos, obtenido de un primer curso o dé la experiencia en el empleo concreto de las bases de datos. Se reco- mienda el uso del libro Fundamentals of Database Systems, de Elmasti y Na- vathe (Benjamin/Cummings, 1989), como una fuente completa de material de referencia. Los capitulos 12, 13 y 14 proporcionan introducciones que resumen, los modelos de datos relacional, de redes y jerdrquico, respectivamente. libro E! libro se divide en tres partes, precedidas por un capitulo introductorio, La ultima parte concluye con un capitulo de David Reiner sobre herramientas de diseno. La primera parte sigue un enfogue orientado a los datos y trata el diseno conceptual de bases de datos como independiente del disefio de aplicaciones. El primer capitulo ilustra el papel del disefio de bases de datos dentro del ciclo de vida de los sistemas de informacién, y la diferencia entre e1 enfoque orientado a los datas y el orientado a las funciones en ef diseno de sistemas de informacion. El capitulo 2 presenta los conceptos de modelado de datos y, es pecificamente, e! modelo ER. para que, despues de completatlo, el lector sea ca- paz de entender los esquemas ER. El capitulo 3 muestra primitivas de diseiho yx PREFACIO cstrategias para diseftar esquemas ER. Al final de este capitulo, el lector debe ser ‘capaz de construir pequetios esquemas ER. El capitulo 4 se divide en tres apartados; cada uno ilustra enfoques espec ficos del disetto conceptual basados en las diferentes formas de expresién inici de los requerimientos: descripciones textuales, formularios y formatos de regis tro en Cobol. Cada apartado puede leerse independientemente. El capitulo 5 describe cémo diferentes esquemas deben integrarse para generar un Unico es quema global. El capitulo 6 muestra cémo un esquema conceptual debe rees- ‘nceturarse para perfeccionar sus propiedades (incluidas complecion o integri- dad, minimatidad, expresividad, legibilidad y normalizacion). El capitulo 7 muestra cOmo se debe documenar el disetio conceptual, reuniendo diversas descripciones de diseiio, y cémo esa documentacién puede utilizarse en cl man- tenimiento de una base de datos y en la integracién del diccionario de datos. La segunda parte sigue un enfoque conjunto orientado a los datos y a las, funciones, ¢ integra el modelado conceptual con el analisis funcional. El capi- tulo 8 trata el andlisis funcional, al introducir e! modelo de flujo de datos y al mostrar primitivas y estrategias de disefto. El capitulo 9 ilustra el enfogue con: Junto orientado a datos y funciones para el diseho conceptual de datos y funcio- nes; este método produce una especificacién de alto nivel de las operaciones de bases de datos que servira como guia para el consiguiente diserio légico y fisico de las bases de datos. El capitulo 10 contiene un extenso estudio de caso. Se presenta un ejemplo bastante realista de una compafia de autobuses que ofrece una variedad de ex- ccursiones. Se ha procurado exponer los aspectos de la compaiiia de autobuses {que son pertinentes en el diseiio de la base de datos. La tercera parte del libro se refiere al disco I6gico, que es el proceso de con- vertr el disefto conceptual en una estructura de base de datos realizable dentro de un sistema especifico de gestiGn de bases de datos. Primero se muestra el di- sefio independiente del modelo, es decir, se consideran transformaciones que simplifican el esquema conceptual sin tener en cuenta el modelo de datos que constituye el objetivo final. Después se considera la correspondencia entre el es- quema conceptual y cada uno de los tres modelos de datos mas destacados: re- Jacional, de redes y jerarquico. El capitulo 11 estudia el disento logico independiente del modelo, usando el modelo entidades-interrelaciones, y describe las transformaciones iniciales del esquema conceptual en un esquema simplificado, intermedio, entre conceptual logico. Los proximos tres capitulos usan este esquema simplificado como punto {de partida de transformaciones subsecuentes para adaptarlo a las familias pre- dominantes de Dams, implantadas comercialmente. Los capttulos 12 al 14 convierten un esquema conceptual del modelo ER en un esquema relacional, un esquema de redes (DBTG 0 CoDAsYL) y un esquema jerdrquico, respectivamente. En estos tres capitulos se han resumido las carac- teristicas, limitaciones y lenguajes esenciales asociados con estos modelos. En cada uno de esos capitulos se examinan dos problemas adicionales. Primero, se considera la traduccién de las operaciones del esquema conceptual a lenguajesPREFACIO xu apropiados de manipulacion de datos para el modelo de datos objetivo (relacio- nal, de redes o jerdirquico). Estos se aclaran mediante ejemplos de operaciones sobre la base de datos del caso de estudio. En segundo lugar, se aborda el pro- blema de la reiroingenieria (0 ingenieria inversa) para cada modelo, de modo aque los esquemas de bases de datos existentes en los respectivos modelos pue- dan abstraerse 0 ser analizados para obtener un esquema conceptual El capitulo 15; sobre las herramientas de diseio de bases de datos, lo aporta David Reiner. Primero se analizan los asuntos generales, incluyendo la arqui- tectura y las caracteristicas deseadas de Tas herramientas de disefto y, Iuego se deseriben algunas de las herramientas para el disefio de bases de datos asistide por computador actualmente disponibles como prototipos de investigacién o en el mercado, La estructura del libro, representada en el cuadro anexo, indica las relacio- nes de precedencia entre 1os capitulos y sugiere varias secuencias de lectura, Reconocimientos Nuestro enfoque hacia el discfio de bases de datos acusa una marcada influen- cia del Proyecto Dataid, desarrollado en Italia entre los anos 1980 ¥ 1985, y pa- trocinado por el Consejo Nacional de Investigacidn, Damos las gracias a Los co- legas que participaron activamente en el proyecto, particularmente a Antonio Albano, Valeria de Antonellis y Antonio di Leva, Cada uno de los tres autores ha investigado, por separado, sobre el diseho de bases de datas, junto con otros colegas. En particular, Carlo Batini desea dar las gracias a Maurizio Lenzerini, Giuseppe Di Battista y Giuseppe Santuc Stefano Ceri desea reconocer la cooperacién de Giampio Bracchi, Giuseppe Pelagatti, Barbara Pernici, Paola Mostacci y Federico Barbic durante los aitos de actividad del Proyecto Dataid, patrocinado por el Consejo Nacional de In- vestigacion y por la Fundacion Nacional de Ciencias. Varios estudiantes del Po- litecnico di Milano han investigado sobre el diseno de bases de datos con él, como parte de sus tesis; desea mencionar de forma especial a Alessandro Rive- Ila, Paolo Pellegrini, Corrado Luppi, Marco Spizzi y Giovanni Zorzino. Asi- mismo, da las gracias por su cooperacion a Gio Wiederhold por el acerca- miento, junto con Sham Navathe y Barbara Pernici, hacia algunos temas de investigacion sobre el diseno de bases de datos, como por ejemplo el disetto de fragmentacién y localizacién de datos; y reconoce tambien la cooperacidn de Barbara Pernici, Giampio Bracchi, Letizia Tanca, Fabio Schreiber, Giuseppe Pelagatti y Licia Sabattella en el ofrecimiento de cursos avanzados de diseito de bases de datos. Sham Navathe desea reconocer la colaboracién de Jim Larson, Ramez El ‘masti, Amit Sheth, Skip Pumfrey y Alan Simon en proyectos conjuntos de di sefio de bases de datos y herramientas de disefio, que realiz6 con las corporacio- nes Honeywell, Bellcore y Digital. Desea agradecer a la Fundacién Nacional dexv PREFACIO Primera parte ean concoptal ce baaoe : men ‘ates — y Cieemncnas ain Stns Team [——_.| emma ions sotne a name funcens en et | _ "union! Y ésopo do bones ¥ du 8. Andes corp de datos hanes m 1a Eswae co caso re ogco 1. Bano geo 6 7 yheramerise ‘rt oranco erode co “edceto ‘odedernerasonse > 12 Dito gio pre 15, tooo pare "4. Dato geo pra ‘mos robcra mood erase rose recuce y 15 neraments cea it tase 08 Relaciones de precedencia entre los capitulos de este libroPREFACIO ES Ciencias el otorgamiento de las subvenciones de investigacion EE.UU. Italia que facilitaron la colaboracion con cientificositalianos, incluido el desarrollo de este libro, Aparte de a los coautores de esta obra, desea expresar su agradeci miento a Maurizio Lenzerini, Tiziana Catarci, Giuseppe Di Battista, Giampio Bracchi, Barbara Demo y Barbara Pernici, ast como a otros miembros del Pro- yecto Dataid. Entre los estudiantes graduados de la University of Florida, desca mencionar la influencia del trabajo de Tarck Anwar, Aloysius Cometio, Sunit Gala y Ashoka Savasere sobre sus propios trabajos en el campo del diseno de bases de datos, Versiones preliminares de este libro han sido analizadas a lo largo de varias ediciones de talleres, cursos y conferencias didacticas; las metodologfas se han usado en un contexto profesional. En particular, Stefano Ceri dio un curso en el Centro de Investigacion de IBM en Rio de Janeiro en 1987; Carlo Batini pre- sent una introduceion al tema en la Conierencia Internacional sobre Tecno- logia Ampliada de Bases de Datos (EDBT) en Venecia en 1988; Stefano Ceri y Sham Navathe presentaron una introdueci6n en la Conferencia Internacional sobre Grandes Bases de Datos (VLDB) en Los Angeles en 1989. Varios colegas han contribuido en la preparacién del manuscrito. Agrade- cemos en particular a Jim Larson, quien ha hecho comentarios eficaces sobre las dos primeras partes del libro; sus observaciones detalladas han influido mu- cho en la organizacién de esta revision, Mary Loomis aporto indicaciones utiles para la expansion y mejora de la primera version, Agradecemos también a Maurizio Lenzerini, Mike Mannino y Ashok Malhotra sus utiles comentarios, Young-chul Oh ayud6 en la conversi6n de manuscritos. Kalamakar Karlapa- lem y Magdi Morsi colaboraron en Ja correccién de pruebas. Se agradece mu- cho ia temprana cooperacién de Alan Apt y Mary Ann Telatnik en el desarrollo de este libro. Nick Murray hizo un trabajo espléndido como editor. Cierta- mente, todos los errores y omisiones del libro son sélo responsabilidad de los autores, quienes se presentan en orden alfabético. Para terminar, Sham Navathe desca reconocer el apoyo y sacrificio de su es posa Aruna y de sus hijos Manisha y Amol en todo el proceso de ereacién de este libro, Se agradece enormemente la ayuda de ellos en la preparacién del in- dice, Stefano Ceri desea dar las gracias a Teresa y Paolo por su animo y apoyo durante la preparacion del libro.Primera parte Disefio conceptual de bases de datos* serio de bases de datos se presentan por medio de la descripcion de leans de ara: pos imentales mediante los cuales nos concentramos en las propiedades comunes de los datos, sin arenes deialee na pacino Luego se presenta el mo- delo de isado a lo largo del libro, y se muestra como este modelo utiliza los mecanismos de abstraccién. A cominsacion se deseriben as RAMGURKSME MERE proceso de diseBo, se propone tomar todas las decsiones de disco de forma estructurada mediante la aplicacion sistematica de las pri- tmitivas de refinamiento. Cada primitiva se aplica a una descripcion inicial de la realidad y la transforma en una nueva y mas rica des- cripcién; las primitivas se clasifican en descendentes y ascendentes. Las estrategias para el refinamiento de un esquema emplean indis- tintamente las primitivas descendentes, ascendentes o un enfoque mixto. Asi, una descripcién inicial del esquema, llamada esquema de armazén, evoluciona hasta el esquema conceptual final. EI disefto de un esquema esta, asimismo, influido por los tipos de requerimientos iniciales disponibles. Como recursos alternativos, se considera is dsrplones estuaes en lengua natural, hs oP El ermine ardaonship e ha taducdo or einterasons sng en Exp et ambien my exten 8 care informatica el termine reac ‘fo lar celeste conserva ns sg ER ongials en ings po su ampli so en la comunidad infor: fatal pa bea ae EnanaRean), pe ge coe a cDDISENO CONCEPTUAL DE BASES DE DATOS GRMGROSIOS Yormatos de VegistrOs en COPOP para cada uno de ellos se sugieren diferentes enfoques de disefto. Las consideraciones anteriores suponen que el dominio global de la aplicacién puede modelarse mediante un tinico esquema. Para las, aplicaciones de grandes bases de datos, es conveniente dividir el do- minio de la aplicacion en varios subesquemas ofis/a. Una vista es tun subconjunto del dominio de la aplicacion asociado con el punto de vista de un usuario especifico. Si se disefta cada vista indepen- dientemente, entonces los diferentes subesquemas conceptuales re- sultantes de cada diseito deben integrarse. Los problemas de la in- GERMBIRRBTERDDS ceten a conics ene eae vias que een erspectivas distintas de los mismos datos en diferentes contextos. El esquema conceptual final puede ser sometido a reesructra- (G@GHAas cualidades de un esquema conceptual estén formalmente definidas; incluyen compleci6n, correccién, minimalidad, expresi- vidad, legibilidad, autoexplicacién y extensibilidad. Ademés, inclu- yen cma una propiedad que ha sido definida formalmente en el contexto del modelo de datos relacional y que se generaliza para los esquemas de entidades-interrelaciones. Cada caracteristica se analiza por separado y se sugieren transformaciones para mejorarla. Después de completar el disefto conceptual, se sugiere la crea- cion de una(@ociumientacion Completa, que incluya varios esquemas y especificaciones; estos documentos pueden usarse durante la ope- tacién con la base de datos para el mantenimiento de esquemas y programas, y también se incluyen en el diccionario integrado de da- tos.Las ultimas dos décadas se han caracterizado por un fuerte crecimiento en el nimero e importancia de las aplicaciones de bases de datos. Las bases de datos son componentes esenciales de los sistemas de informacion, usadas rutinaria~ mente en todos los computadores, desde los supercomputadores intercomuni« cados hasta los computadores medianos 0 pequetios. El disefio de bases de datos se ha convertido en una actividad popular, desarroliada no s6lo por profesio- nales sino tambien por no especialistas. A finales de la década de 1960, cuando las bases de datos entraron por pri- ‘mera vez en el mercado de software, los disefiadores de bases de datos actuaban como artesanos, con herramientas muy primitivas: diagramas de bloques y es- tructuras de registros eran los formatos comunes para las especificaciones, y el diseno de bases de datos se confundia frecuentemente con la implantacién de las bases de datos, Esta situacién ahora ha cambiado: los métodos y modelos de diseno de bases de datos han evolucionado paralelamente con el progreso de la tecnologia en los sistemas de bases de datos. Se ha entrado en la era de los sis- temas relacionales de bases de datos, que ofreven poderosos lenguajes de con- sulta, herramientas para el desarrollo de aplicaciones ¢ interfaces amables con los usuarios. La tecnologia de bases de datos cuenta ya con un marco tedrico, que incluye la teoria relacional de datos, procesamiento y optimizacion de con- sultas, control de concurrencia, gestién de transacciones y recuperacién, etc. Seguin ha avanzado la tecnologia de bases de datos, asi se han desarrollado las metodologias y técnicas de dise’io. Se ha alcanzado un consenso, por ejem= pplo, sobre la descomposicion del proceso de diserio en fases, sobre los principa- les objetivos de cada fase y sobre las técnicas para conseguir estos objetivos. Este libro se origina a partir de nuestra creencia de que la mayoria de los conceptos relevantes en el diseiio de bases de datos se han establecido con firmeza, y es tiempo de que estos conceptos tengan mayor divulgacién, Desafortunadamente, las metodologias de diseiio de bases de datos no sonDISERIO CONCEPTUAL DE BASES DE DATOS ‘muy populares; la mayoria de las organizaciones y de los disefiadores individua- Jes confia muy poco en las metodologias para llevar a cabo el diseiio y esto se considera, con frecuencia, una de las principales causas de fracaso en el desarro- Ho de los sistemas de informacion. Debido a Ia falta de enfoques estructurados ‘para el disetto de bases de datos, a menudo se subestiman el tiempo 0 los recur- 05 necesarios para un proyecto de bases de datos, las bases de datos son ina- 0, se dice que la clase C; tiene una participacién obligatoria en la agre- mn, ya que cada elemento de la clase C, debe corresponder, al menos, a un elemento de la clase C2. En los cjemplos antes citados, la participacion de la en- tidad EDIFICIO en Ia relacion USA es opcional; la participacion de la entidad EDI- FiCIO en la relacién PoseE es obligatoria. Cardinalidad maxima (card-max), Considérese la agregaci6n A entre las clases C, y Cp. La cardinalidad maxima de C, en A, que se representa como card-max (C;,A), ¢s el mayor niimero de correspondencias en las que cada ele- mento de C, puede participar. Asimismo, la cardinalidad maxima de C3 en A, denotada por card-méx (C2,A), ¢s el mayor niimero de correspondencias en las que puede participar cada elemento de C2. Consideremos de nuevo las agregaciones USA y POSEE entre PERSONA y EDI- Ficio: 1. Si se supone que cada persona usa varios edificios, card-max (PERSONA,USA) = n, Por n se enticnde «infinito»! 0 «ilimitadon, 2, Si se supone que cada EDIFICIO puede tener varios habitantes, entonces, card- max (EDIFICIO.USA) = n. El mero estar cn realidad limitado al nimero de ocurensas dela clase eouncto en la base de dato,CONCEPTOS SOBRE EL MODELADO DE DATOS 2% 3. Si se supone que cada persona puede poseer varios edificios, entonces, card- ‘max (PERSONA,POSEE) = n. 4, Si se supone que cada edificio pertenece slo a una persona, entonces, card- ‘min (EDIFICIO.POSEE) = 1 y card-max (EDIFICIO POSES). Estos ejemplos muestran que los valores importantes para card-max (C\,A) son | y n; n representa cualquier nimero e indica que cada elemento de C; puede pertenecer a un numero arbitrariamente grande de correspondencias. Card-max pocas veces adopta un valor fijo, pero puede darse el caso. Por ejemplo, si se considera la correspondencia binaria FIESTAS_OFICIALES entre PERSONA DIAS_DE_LA_SEMANA, y se supone que cada persona cuenta con no mas de dos dias de fiesta oficiales por semana, entonces, card-max (PERSONA, FIESTAS_OFI- CIALES) = 2. Si card-méx (C\,A) = | y card-méx (C2,A) = 1, se dice que la agregacidn es de uno a uno, Si card-max (C,,A) = ny card-max (C,,A) = 1, 1a agregacion de Ca.a Ci es de uno a muchos. Si card-max (C),A) = 1 y card-méx (C,,A) = 0, la agregacién de C, a C2 es de muchos a uno; por wltimo, si card-max (C,,A) = m y card-max (C2,A) = n (donde m y n representan valores superiores a 1), la agre- gacion es de muchos a muchos. Estos conceptos se aplican’ampliamente en el disefio de bases de datos, a veces de manera incorrecta. La figura 2.10 muestra un ejemplo para cada uno de los cuatro tipos de correspondencias entre las clases C, y C3. Se caracteriza por completo cada participacién de una clase en una agregacién al indicar los dos valores de minima y maxima cardinalidad, Esto se representa como sigue: sea A una agregacién binaria de las clases C, y C2, con card-min (C,,A) =m, y card-max (C\,A) = My; entonces, se dice que la cardinalidad de C, en A es el par (my,M,): card (Cy,A) = (m),M,). De igual modo, si card-min (C2,A) = m3 y eard-max (C2,A) = Mz, card (C2,A) = (mzMp). Estos conceptos seran muy utiles en el analisis que se hace mas adelante sobre las caracteristicas de las interrela- ciones en el modelo ER. 2.2.2. Agregacién nearia Una agregacién n-aria es una correspondencia establecida entre tres 0 mas cla- ses. Por ejemplo, SE_IMPARTE es una agregacién ternaria entre las clases CURSO, DIA y AULA. Expresa la idea de que un determinado curso se imparte un cierto dia en un aula determinada. Igual que ocurre con las relaciones binarias, es im- portante describir las propiedades de cardinalidad de esta correspondencia. Re- sulta que las cardinalidades minima y maxima se definen exactamente de la misma manera. (Cardinalidad minima (card-min). Considérese la agregacion A entre las cla- ses C), C>,..Cy. La cardinalidad minima de C; en A, representada por card-min (C,,A), es el numero minimo de correspondencias en las que cada elemento de G puede participar.DISENO CONCEPTUAL DE BASES DE DATOS (©) Uno a muchos (@) Muchos a uno (6) Muchos a muchos Figura 2.10. Ejemplos de correspondencias de uno a uno, uno a muchos, muchos a Uno y muchos a muchos. Cardinalidad maxima (card-mix). Considérese la agregaciGn A entre las clases C,, Cz). Cy. La cardinalidad maxima de C, en A, denotada por card-max (C;,A), es el ntimero maximo de correspondencias en las que cada elemento de C; puede participar. ‘Considérese la agregacién ternaria Se IMPARTE entre las clases curso, dia y aula, representada en la figura 2.11. 1. Si se supone que cada curso puede impartirse entre una y tres veces por se- mana, entonces ccard:min (CURSO,SE_IVPARTE) = 1 ‘card: max (CURSO,SE_MPARTE) ~ 3 2. Si se supone que en cada dia de la semana puede impartirse cualquier nu- mero de cursos, entoncesCONCEPTOS SOBRE EL MODELADO DE DATOS a SELIMPARTE J\\ CURSO (OIA AULA (#) SE_IMPARTE como una agregacién ternaria TERVAN 107 AUDITORIO SKILLING DIA (©) Correspondencias an ta agragacion SE_IMPARTE Figura 2.11. Representacién de la agregacién ternaria sanPane,Ey 2.2.3. Generalizac DISENO CONCEPTUAL DE BASES DE DATOS cardimin (O1A.SE_IMPARTE) ‘card-max (DIA SE_IMPARTE) = ni? 3. Si se supone que en cada aula puede haber como maximo cuarenta reunio- nes por semana (ocho reuniones por dia, cinco dias por semana), entonces ccarc:min (AULA,SE_MPARTE) = 0 ccarc:max (AULA,SE_IMPARTE) = 40 ‘Como en el caso de las agregaciones binarias, se caracteriza por completo cada participacion de una clase en una agregacién al indicar los dos valores de Ja minima y maxima cardinalidad. Por consiguiente: card (CURSO,SE_IMPARTE) = (1,3) card (DIA SE_IMPARTE) = (0.9) card (AULA,SE_IMPARTE) = (0,40) nes Una abstraccién de generalizacién establece una correspondencia entre la clase geneérica (raiz) y la clases subconjunto. Considérese la clase PERSONA como una generalizacion de las clases VARON y HEMBRA; cada elemento de éstas corres- onde exactamente a un elemento de la clase PERSONA. En esta generalizacion, cada persona corresponde también a un elemento de la clase VARON o a un ele- mento de la clase HEMBRA; sin embargo, esto no ocurre en todas las generali- zaciones. Estas observaciones se refieren a las propiedades de cobertura de la ge- neralizacion, que se describen formalmente a continuacién. Cobertura total o parcial, La cobertura de una generalizacién es total (t) si cada elemento de la clase genérica corresponde a! menos a un elemento de las clases subconjunto; es parcial (p) si existe alguin elemento de la clase genérica que no corresponde a ningtin elemento de las clases subconjunto. Cobertura exclusiva o superpuesta. La cobertura de una generalizacién es exclusiva (¢) si cada elemento de la clase genérica corresponde, a lo maximo, a un elemento de las clases subconjunto; es superpuesta (s) si, al contrario, existe algin elemento de la clase genérica que corresponde a elementos de dos 0 mas clases subconjunto diferentes. La figura 2.12 muestra todas las combinaciones de valores de cobertura representando ejemplos de clases como conjuntos ¢ in- dicando cémo se superponen. 1, La cobertura de una generalizacién PERSONA de las clases VARON y HEMBRA ¢s total y exclusiva: (te). * EL mumeroagul también est imitado; en ete caso, ocho veces el mimeo de ausCONCEPTOS SOBRE EL MODELADO DE DATOS 2 PERSONA (@) Total, exclusiva PERSONA Ce) (© Parcal, superpuesta, VEHICULO (€) Tota, superpuesta Figura 2.12. Valores de cobertura en las abstracciones de generalizacién. 2. La cobertura de una generalizacion PERSONA de las clases VARON y EM- PLEADO es parcial y superpuesta: (p.s). 3. La cobertura de una gencralizacién VEHICULO de las clases BICICLETA y CO- CHE es parcial y exclusiva: (p,2).x DISENO CONCEPTUAL DE BASES DE DATOS 4, La cobertura de una generalizacién SUGADOR de las clases JUGADOR_DE- FUTBOL y JUGADOR_DE-TENIS, en un club que requiere que el socio prac- tique al menos dos de estos deportes, es total y superpuesta: (ts). Una generalizacién total y exclusiva comresponde a una particién, en el sen- tido matematico, de la clase genética La anterior exposiciOn sobre las abstracciones de datos y las propiedades de las correspondencias ha mostrado los instrumentos necesarios para el estudio de los modelos de datos y, en particular, del modelo de entidades-interrelaciones. 2.3. Modelos de datos Un modelo de datos es una serie de conceptos que puede utilizarse para descri- bir un conjunto de datos y operaciones para manipular los mismos. Cuando un modelo de datos describe un conjunto de conceptos de una realidad determi- nada, se llama modelo conceptual de datos. Los conceptos de un modelo de da- 10s se construyen por lo regular usando mecanismos de abstracciGn y se descri- ben mediante representaciones linguisticas y graficas; es decir, puede definirse una sintaxis y puede desarrollarse una notacién grafica como partes de un mo- delo de datos. Hay dos tipos de modelos de datos: modelos conceptuales, usados en el di- seio de bases de datos, y modelos légicos, apoyados por los sistemas de gestion de bases de datos (DBM), que son grandes paquetes de software que crean, mo- difican y mantienen bases de datos. Los modelos conceptuales son instrumentos para representar la realidad a un nivel alto de abstraccidn. Utilizando los mo- delos conceptuales, podemos construir una descripcion de la realidad, facil de entender ¢ interpretar. Los modelos légicos apoyan descripciones de datos pro- cesables por un computador; incluyen el modelo jerdrquico, el modelo coossvt (0 de redes) y el modelo relacional. Estos modelos tienen una correspondencia sencilla con la estructura fisica de la base de datos. En este capitulo se presentan los modelos conceptuales y en especial el modelo de entidades-interrelaciones. Los modelos logicos se presentardn en la tercera parte de este libro. En el diseito de bases de datos se usan primero los modelos conceptuales para lograr una descripcién de alto nivel de la realidad; después se transforma el es- quema conceptual en un esquema logico. La raz6n de este enfoque radica en la dificultad de abstraer la estructura de bases de datos complejas. Un esquema es ‘una representaci6n de una parte especifica de la realidad, creada usando un de- terminado modelo de datos. Dicho con mayor propiedad, un esquema es un conjunto estético de representaciones linguisticas o graficas, invariables en el tiempo, que describen la estructura de los datos de interés, como por ejemplo Jos de una organizacion. Tustraremos los conceptos de modelo y esquema construyendo un modelo de datos y un esquema de muestra, usando un subconjunto de las estructurasCONCEPTOS SOBRE EL MODELADO DE DATOS a owes] $60 | RECCON | NUMERO De SEGURO_SOCIAL cooKe ware. [ waanca | coon Pose NUMERO_D&.ceauRO.socAL | NATRC. Figura 2.13. Esquema de muestra. de datos que proporciona el lenguaje de programacién Pascal. E1 modelo de da- tos de muestra contiene los conceptos de campo y registro. Cada campo del mo- delo de muestra puede pertenecer a uno de los siguientes tipos: entero, real, ca- Facter o array" de caracteres. Los entcros, caracteres y reales son tipos basicos de Pascal, mientras que los arrays son conjuntos de elementos del mismo tipo; se toma en consideraci6n sélo arrays de caracteres, Cada registro en el modelo de datos de muestra es, simplemente, un conjunto de campos; éste es un concepto mis simple que el de tipo de registro en Pascal, porque en ese lenguaje es posi- ble definir registros de registros. El esquema de muestra de la figura 2.13 describe una realidad en la que las personas poscen coches: abarca tres registros (PERSONA, POSEE. COCHE) y sicte campos (NOMBRE, SEXO, DIRECCION, NUMERO_DE_SEGURO SOCIAL, MATRI- CULA, MARCA, COLOR). Este esquema corresponde a dos clases, modeladas por los tipos de registro PERSONA y COCHE, y una agregacidn binaria entre las dos clases, modelada por el tipo de registro POSEE. Cada caso de un esquema es una coleccién de datos dindmica, variable en el tiempo, que se ajusta a la estructura de datos que define el esquema. Cada esquema puede tener miiltiples casos; el estado de la base de datos en un mo- mento determinado corresponde a uno de esos casos. La evolucion de la base de datos puede verse como la transicién de un caso a otro, originada por alguna operacion de modificacion de datos. Se aplica el termino caso tambien a un ele- mento del esquema para denotar la coleccién de datos que se refieren a ese ele- mento en particular. El contexto permite entender cuando el término se refiere al esquema en general y cuando a un solo elemento. El caso del esquema de la figura 2.13, mostrado en la figura 2.14a, repre- senta tres personas y cuatro coches. Cada coche pertenece a una persona. No- tese que la figura 2.14a representa un estado particular de la realidad in em- » En la comunidad ltinoarercana, cl termine orginal warray se taduce normalmente por sara. En el texto se mantien el fémino orgDISENO CONCEPTUAL DE BASES DE DATOS PERSONA John Smith | | 17 Woot 126% Ft. Lauderdale 367-6710.962 May Smith | F | 11 West 12St Ft Lausordae 309-4816.981 semoce | m_| 1102 Ramone St. Pao Ato 397-3673.192 COCHE POSE cats7i8 | Maserai | Blanco ge7-rr3-962 | FL iemal Fuiemia | Porsche | aru ssr-sris-a62 | FL Teese CACATAIT | Datsun Banco sorsers-ise | carsrie Fuirieos | Ford Roo 391-978-132 | CACATAIT (9) 0880.00 muesia COcHE POSEE caqari6 ‘Maserat | Banco ‘sererisaee | FL IEMA FLIEMAL Posae | Ant sersrisae2 | FL 176868 cacatat7 | Datun | Blanco serseratee | carsTi8 FL 71099 Tod Roe 9e1-9873-122 | CACATAIT NyBABYBLUE | Ferad | Rao 3604816381 | NY BABVOLUE (©) Caso co muesira dospuds do un ineercicn Figura 2.14, Casos del esquema de muestra. bargo, es posible modificar ese estado. Por ejemplo, es posible que John Smith compre otro coche, un Ferrari rojo. Aqui aftadimos un caso del registro COCHE ara representar ¢l coche nucvo y un caso del registro POSEE para representar la posesidn de ese coche. El nuevo caso resultante del esquema de muestra aparece en la figura 2.14b. Una forma de interpretar la relacion entre esquema y caso es considerar el primero como una limitacion para el segundo. De esta forma, entre todas las colecciones posibles de datos que pueden describir una realidad determinada slo algunas de ellas son validas con respecto al esquema; se dice que son casos v4- lidos de ese esquema. Si se adopta este punto de vista, un objetivo importante del disefio conceptual de bases de datos es hacer una descripcion semantica- mente rica de! esquema, que haga de filtro eficaz para casos no validos de las bases de datos. Otra forma de ver las diferencias entre esquema y caso es con- siderar el esquema como un conocimiento infensivo y el caso como un com miento extensivo; el primero denota las propiedades estructurales de los datos; el segundo denota una asignacion de valores a los datos. La figura 2.15 representa las interrelaciones de modelo, esquema y caso. Se presentardn varios ejemplos de modelo, esquema y caso conforme se avance en el analisis de los modelos de datos.CONCEPTOS SOBRE EL MODELADO DE DATOS 33 Modelo Elmoceto ees ros —_ ‘para estructurar ‘a ion Peers Esquema Geta eorvcura <—> se eequr dole eaiced rece rags | Se Desapoén sevii colareaides «> [ Cooo srinmonerto ‘eee Figura 2.15. Las interrelaciones de modelo, esquema y caso, Niveles miltiples de un sistema de bases de datos EI disefto de una base de datos no es el nico campo para la aplicacién de los modelos conceptuales. Un desarrollo significativo, a mediados de los aftos se- tenta, fue la propuesta de la Comision sparc del American National Standards Institute (Instituto Nacional Americano de Normas), popularmente conocida como propuesta ANSI/PARC. En la recomendacion ANSI/SPARC cada sistema de bases de datos se organiza de acuerdo con tres niveles de descripcién de datos: externo, conceptual e interno. El nivel externo describe los puntos de vista de grupos especificos de usuarios de la base de datos; presenta la informacién que es relevante para un grupo especifico de usuarios. El nivel conceptual, también llamado esquema de empresa, ofrece una representacion independiente de la maquina y de alto nivel de toda la base de datos. El nivel interno ofrece una descripeién dependiente de 1a maquina de la implantacion fisica de la base de datos. En esta arquitectura los modelos conceptuales son Ienguajes para plas- mar el nivel conceptual. Al ser ésta una arquitectura DBMS, los modelos concep- tuales son «procesables», es decir, son comprendidos por el computador, el cual necesita varios traductores para establecer las correspondencias entre el nivel externo y los niveles conceptual e interno. La importancia dada a esta aplicacién de los modelos conceptuales ha dis- minuido con el tiempo. Si bien se han desarrollado prototipos importantes se- atin las recomendaciones de ANst/PARC, la tendencia actual de los DBMS comer ciales ha sido, de alguna manera, contraria. Los nuevos DBMS comerciales no incluyen arquitecturas de niveles multiples con complejas correspondencias en- ‘tre los modelos; se inclinan por el uso de un modelo légico simple, con lo que se alcanza mayor eficiencia. Sin embargo, cabe senalar que los DRMS comercia- les oftecen caracteristicas de nivel externo o interno dentro de modelos I6gicos. En los afos ochenta, los modelos conceptuales han encontrado otro campo importante de aplicacién en los lamados sistemas de diccionarios de datos. Un diccionario de datos es un sistema de proposito especial, cuya funcién es definir34 DISENIO CONCEPTUAL DE BASES DE DATOS el contenido de la base de datos y de los programas de aplicacién dentro de los sistemas de informaci6n. Puesto que la facilidad de lectura y la expresividad del modelo de datos son caracteristicas importantes para el diccionario de datos, no sorprende el uso extenso de los modelos conceptuales en estos sistemas, Mas adelante se hard hincapié en la importancia del uso de los modelos conceptuales para la documentacién de las bases de datos. 2.3.2. Cualidades de los modelos conceptuales Los modelos conceptuales deben ser buenas herramientas para representar la realidad; por esta raz6n, deben poseer las siguientes cualidades: 1, Expresividad. Los modelos conceptuales difieren en la eleccién y numero de las distintas estructuras de modelado que offecen. En general, la disponibi- lidad de una amplia gama de conceptos hace posible una representacion mas cextensa de la realidad; por este motivo, los modelos mas ricos en conceptos son también muy expresivos. Por ejemplo, la mayoria de los modelos con- ceptuales de datos hacen uso frecuente de la abstraccién de generalizacién, Jo que permite la representacion directa en el esquema de una gran variedad de restricciones de integridad, es decir, aserciones que permiten la scleccién de casos validos del esquema de base de datos. 2, Simplicidad. Un modelo conceptual debe ser simple, para que un esquema creado con ese modelo sea facil de entender por los disefadores y usuarios de la aplicacin de bases de datos. Obsérvese, sin embargo, que la simplici dad y la expresividad son objetivos en conflicto; si un modelo es seméntica- mente rico, es probable que no sea simple. 3. Minimalidad. Esta propicdad se consiguc si cada concepto presente en el modelo tiene un significado distinto con respecto a todos los demas (en otras palabras, si ningdin concepto puede expresarse mediante otros conceptos). 4, Formalidad. Los esquemas creados usando modelos conceptuales de datos epresentan una especificacién formal de los datos, La formalidad requiere que todos los conceptos del modelo tengan una interpretacién tinica, precisa y bien definida. Los conceptos formales pueden manipularse matematica- mente. En general, un modelo no es capaz de expresar todas las propiedades de una realidad determinada; algunas de estas propiedades deben expresarse mediante aserciones que complementen el esquema. Sin embargo, el nimero de asercio- res necesarias puede hacerse arbitrariamente pequeito, al incorporar conceptos mas expresivos en el modelo. La seleccién del nivel apropiado de complejidad para un modelo es una decisién dificil: seria conveniente el uso de un modelo conceptual que incorporase varios ingredientes sin detrimento de su simplici- dad y manejabilidad. El grado de minimalidad de un modelo implica también un equilibrio, porque la disponibilidad de un mayor y mas rico conjunto de(CONCEPTOS SOBRE EL MODELADO DE DATOS 5 conceptos, posiblemente superpuestos, ayuda al analista a percibir y modelar la realidad. 23.3. Propiedades de las representaciones gréficas Los modelos de datos suelen describirse mediante representaciones linguisticas y gréficas. En el apartado anterior se mostré una representacién grafica de! mo- elo de muestra. El éxito de un modelo depende con frecuencia del éxito de su representacién gréfica, que debe poser las siguientes cualidad 1. Complecion grifica. Un modelo es graficamente completo si todos sus con- ceptos poseen una representaciGn gréfica; de otro modo, la representacién srafica tiene que complementarse con una representacion linguistica 2. Facilidad de lectura, Un modelo es facil de leer si cada concepto se repre- senta con un simbolo grafico claramente distinguible del resto de los sim- bolos erficos. Obsérvese que se tratan ahora las propiedades de los modelos y no de los esquemas; es responsabilidad del analista crear esquemas legibles. Se abordard este tema mas adelante. 2.4. El modelo de entidades-interrelaciones Este libro se concentra en el modelo de entidades-interrelaciones (ER), el mo- delo de datos mas ampliamente usado para el disefio conceptual de bases de da- tos, El modelo fue introducido por Peter Chen en 1976, y se ha hecho cada vez més popular. Se han organizado varias conferencias sobre las aplicaciones del modelo ER en ef disefio de bases de datos y en el de software en general. En 1988 el ANSI seleccion6 e! modelo ER como el modelo estandar para los siste- mas de diccionarios de recursos de informacién (IRDs, Information Resource Dictionary Systems). Originalmente, el modelo ER incluia slo los conceptos de entidad, interre- lacion y atributos; mas tarde, otros conceptos, como los atributos compuestos y las jerarquias de generalizaciGn, se agregaron como componentes del modelo FR mejorado. Se respetara este desarrollo cronoldgico y se presentaran elementos basicos y caracteristicas avanzadas del modelo ER en dos apartados posteriores. Después de presentar el modelo ER, se mostrara cémo se representan las abs- tracciones en él y se ofrecera una exposicién critica de sus cualidades. 2.4.1, Elementos basicos del modelo ER Los conceptos basicos previstos por el modelo ER son entidades, interrelaciones y atributos. Notese el uso de los términos entidad e interrelacion para denotarDISENO CONCEPTUAL DE BASES DE DATOS: ViVE_EN PERSONA (600 E> ‘CIUDAD Figura 2.16. Parte de un esquema En que representa las entidades PERSONA y CLLOAD y las interrelaciones NACID0_EN y ViVE_EN. clases de objetos; en la literatura, algunos z diemtes tipo de entidad y tipo de interrelaci 1ores usan los términos correspon Entidades. Las entidades representan clases de objetos de la realidad. PER. SONA, HOMBRE, MUJER, EMPLEADO y CIUDAD son ejemplos de entidades para una base de datos de personal. Las entidades se representan graficamente por medio de rectangulos, como muestra la figura 2.16. Interrelaciones. Las interrelaciones representan agregaciones de dos 0 mas entidades. Un ejemplo de interrelacién binaria en la base de datos de personal 8 NACIDO_EN, que relaciona PERSONA y CIUDAD de nacimiento. Otra interre- laci6n binaria entre las mismas entidades es VIVE_EN, que indica la ciudad donde Ja persona vive en la actualidad. Las interrelaciones se representan gréficamente ‘con rombos, como se aprecia en la figura 2.16. Las interrelaciones n-arias conectan més de dos entidades; por ejemplo, la interrelacion SE_IMPARTE de la figura 2.17 es una interrelacion ternaria que une las entidades CURSO, DIA y AULA, segiin se explicé en el apartado 2.2. Los anillos son interrelaciones binarias que conectan una entidad consigo misma. Se conocen también como interrelaciones recursivas. Por ejemplo, la interrelacién DinIGE de la figura 2.18 conecta los directores con sus subordina- dos, ambos representados por la entidad EMPLEADO. Para distinguir entre los dos papeles de la entidad en la interrelaciOn, se asocian dos rétulos con la enti- dad; en la figura 2.18 los dos rétulos son DIRECTOR_DE y SUBORDINADO.A. ‘CURSO Evens AULA DA Figura 2.17, Interrelacién n-aria se_waare.CONCEPTOS SOBRE EL MODELADO DE DATOS Ed DIRECTOR_DE EMPLEADO ce ‘SUBORDINADO_A Figura 2.18. La intertelacién de anilo orice. Cada interrelaci6n tiene un significado especifico; de ahi la necesidad de se- leccionar nombres significativos para las interrelaciones. Por ejemplo, si el nombre EN fuese usado para nombrar una interrelacién que conecta las enti- dades PERSONA y CIUDAD, el esquema no expresaria sila interrelacion se refiere al lugar de nacimiento o la ciudad de residencia. Considérese de nuevo el esquema en la figura 2.16, Un caso del esquema es como sigue: PERSONA = {p,, Po, Ps) CIUDAD = {65 Ca, Ca} VIVELEN = {, , ) NACIDO_EN = (. ) La entrada para p: en NACIDO_EN puede faltar sila persona p» nacié en una ciudad diferente de cy, c» ¥ cs. Adviértase que después de la introduccién de las entidades e interrelaciones sélo se puede indicar casos de ellas; no se puede des- cribir las propiedades de cada caso. Esto serd posible después de introducir los atributos. Las interrelaciones se caracterizan en términos de cardinalidad minima y ‘maxima, como se traté en el apartado 2.2. En el ejemplo anterior, card:min (PERSONA, VIVE_EN) = ‘card: max (PERSONA, VIVE_EN) ccard:min (CUDAD, VIVE_EN) = Oy ccard:max (CUDAD, VIVE_EN) = 1. Con base en las cardinalidades antes expuestas, VIVE_EN es una interrelacion de uno a muchos entre PERSONA y CIUDAD. La participacién de PERSONA en la interrelacién es obligatoria, mientras que la participacién de ciudad en la inte- rrelaciOn es opcional. Se resume la cardinalidad minima y maxima en un par de valores: card (PERSONA, VIVE_EN) = (1,1) y card (CIUDAD, VIVEEN) = (0,n). ‘Cada par estd representado en el esquema (Fig. 2.19a), cerca de la conexién en- tre la entidad (recténgulo) y la interrelacion (rombo). Otras representaciones sgraficas en la literatura usan Iineas dobles que inciden en el rombo para repre- sentar card-max = n y una linea sencilla que incide en el rombo para represen-CISENO CONCEPTUAL DE BASES DE DATOS: PERSONA [OY “ie >" F cupan (@) La interelacién VIVE_EN 3) ‘CURSO (La interrelactén SE_IMPARTE DIRECTOR_DE ay ewPeno | << one > (On) ‘SUBORDINADO_A (©)La tnerrlacion DIRIGE. oy (1.9) [TARIETADE- PEDIOC Ceara 0 e EMBARGUE. (6) La interrelacién EMBARQUE Figura 2.19, Ejemplos de interrelaciones en el modelo en. tar card-max = 1; semejantes representaciones gréficas no incluyen cardinali- dades minimas. La figura 2.19 describe algunas interrelaciones y senala las correspondientes cardinalidades mfnimas y maximas para: 1. La interrelaci6n vive_eN (ya mencionada). 2. La interrelacidn s&iMPARTE (tratada en el apartado 2.2.2). 3. La interrelaci6n piriGe (una interrelacin de uno a muchos, puesto que cada director dirige a varios empleados y cada empleado tiene solo un director, la participacion en la interrelacidn es opcional) 4. La interrelacién EMBARQUE entre un PEDIDO y la correspondiente TARIE- TA.DE_EMBARQUE (una interrelaci6n de uno a uno, puesto que cada pedidoCONCEPTOS SOBRE EL MODELADO DE DATOS 2 G CAMBIO DE_DOMICILO NOMBRE NOMBRE PERSONA © ALTTUD NUMERO_DE_! 8 ‘SEGURO_SOGIA NUMERO_De_, O FECHADE_NACIMIENTO. HABITANTES PROFESION, en tro oF Figura 2.20. Un esquema en con entidades, interrelaciones y atributos. estd relacionado opcionalmente con una tarjeta y cada tarjeta esté obligato- riamente relacionada con un pedido). Atributos. Los atributos representan las propiedades basicas de las entida- des o interrelaciones. Toda la informacién extensiva es portada por los atribu- tos. ‘Se puede anadir atributos al esquema de la figura 2.16. Los atributos de PER. SONA SOM: NOMBRE, NUMERO_DE_SEGURO.SOCIAL, PROFESION, TITULO. Los atributos de CIUDAD son: NOMBRE, ALTITUD, NUMERO_DE_HABITANTES, El tinico atributo de VIVE_EN es FECHA_DE_CAMBIO_DE_DOMICILIO, con la fecha en que Ja persona se mudo a la ciudad. El \inico atributo de NACIDO_EN ¢s FECHA_DE- -NACIMIENTO. El esquema ER fesultante se muestra en la figura 2.20. Como las interrelaciones, los atributos se caracterizan por su cardinalidad minima y maxima, La cardinalidad minima indica el nimero minimo de va- lores de atributos asociados con cada caso de entidad o interrelacion. Sea A un atributo de la entidad E; si card-min (A,E) = 0, el atributo es opcional y puede estar no especificado (nulo) en algunos casos de la entidad. Si, por el contrario, card-min (A,E) = 1, el atributo es obligatorio y al menos un valor del atributo debe especificarse para todos los casos de la entidad, Las mismas definiciones se aplican a atributos de interrelaciones. En el ejemplo, NOMBRE, NUMERO_DE- -SEGURO_SOCIAL ¥ PROFESION son atributos obligatorios; por ende, no se acep- tara la inclusion de una persona en la base de datos cuyo NOMBRE, NUMERO. .-DE_SEGURO_SOCIAL ¥ PROFESION no s¢ especifiquen. TITULO, en cambio, ¢s opcional y se aceptard la insercion de una persona cuyo titulo no se especifique (sea nulo). La cardinalidad maxima indica el mimero maximo de valores de atributos asociados con cada entidad o interrelacion. Sea A. un atributo de la entidad E; si card- mix (A.E)=1, el atributo ¢s monovalente; si card-max (A.E) > 1, el atri- buto es polivalente. Las mismas definiciones se aplican a los atributos de las in- terrelaciones. En el ejemplo, NOMBRE, NUMERO_DE_SEGURO_SOCIAL y PROFE- SION Son monovalentes, pues cada PERSONA tiene un NOMBRE, un NUMERO_DE_SEGURO-SOCIAL Y Una PROFESION. El atributo TITULO es poliva-DISENO CONCEPTUAL DE BASES DE DATOS lente, porque cada persona puede tener multiples grados: ds (diploma de secun- daria), bh (bachiller en humanidades), mc (maestro en ciencias) en fisica, d (doctor), en informatica, etcétera. La cardinalidad de los atributos es el par (card-min, card-max); como en el caso de las interrelaciones, se representa en el esquema junto al atributo. El va- Jor que se da con més frecuencia es (1,1), que se toma como valor por omisién ¥, POF tanto, se omite en las figuras. Cada atributo se asocia 2 un dominio particular, es decir, el conjunto de va- lores legitimos para ese atributo. Las declaraciones de dominio se asemejan a las declaraciones de tipo en los lenguajes convencionales de programacion. Un atributo simple se define sobre un dominio. Un ejemplo de caso del esquema de base de datos de la figura 2.20 es el si- guiente: PERSONA = {o,:< JOHN, 345-8798:564, ESTUDIANTE, ()>. Pe: , Ps: } QUDAD = {ox , cg , 6; } YINE_EN = ( >, Pics <72383> >, >} NACIDO_EN = {9,.0;: <10555> >, PoC < 614-355) Obsérvese que los valores de los atributos polivalentes estén encerrados en- tre paréntesis; ¢l estudiante John no esta asociado con ningin titulo. El esquema de la figura 2.20 modela una realidad que incluye personas, ciu- dades, nacimientos y residencias. En particular, el disefiador ha percibido las ciudades como datos primarios de interés y ha decidido modelarlos por medio de una entidad. Supéngase ahora una nueva situacién, en la que no interesan las caracteristicas de las ciudades, como el numero de habitantes o la altitud, pero sf se consideran, en cambio, la ciudad de nacimiento y de residencia como dos propiedades clementales de la persona. Entonces, todo el esquema de la fi- gura 2.20 se reducira a una sola entidad, PERSONA, con los atributos NOMBRE, NUMERO_DE_SEGURO_SOCIAL, PROFESION, TITULO, CIUDAD_DE_NACIMIENTO, FECHA_DE_NACIMIENTO, CIUDAD DERESIDENCIA y FECHA_DE_CAMBIO_DE- -DOMICILO. Este ejemplo muestra que la decision de usar entidades, interrela- ciones 0 atributos para modelar algunos aspectos de la realidad es bastante de- licada: existen muchos esquemas similares que modelan diferentes vistas de la misma realidad. En este libro no s6lo se presentan los modelos de datos, sino también metodologias que ayudan al lector a seleccionar el esquema mas con- veniente para describir la realidad, de entre todas las representaciones alterna- tivas,CONCEPTOS SOBRE EL MODELADO DE DATOS 4 Esquema: PERSONAL Entidad: PERSONA ‘Atrbutos: NOMBRE: toxto(60) NUMERO_DE_SEGURO_SOCIAL: texto(12) PROFESION: texto(20) {O.n\TITULO: texio(20) Enmidad: CIUDAD Atributos; NOMBRE: texto(30) ALTITUD: entero NUMERO_DE_HABITANTES: entero Interolacién: VIVE_EN Entidades conectadas: (0,n)CIUDAD (5,1)PERSONA Aributos: FECHA_DE_CAMBIO_DE_DOMICILIO: fecha Intereiacén: NACIDO_EN Entidades conectadas: (0,r1CIUDAD (0.1)PERSONA ‘Atributos: FECHA_DE_NACIMIENTO: fecha Figura 2.21. Definicion linguistica de un esquema conceptual. Se concluye este apartado mostrando en la figura 2.21 una representacién lingutstica para todos los conceptos presentados. La notacién se explica por sf misma; se presentard una gramética BNF (forma de Backus-Naur) para este len- uaje de definicion de esquemas en el proximo apartado. 2.4.2. Otros elementos del modelo ER Entre los demas elementos del modelo Er estan las jerarquias de generalizacién, los subconjuntos, los atributos compuestos y los identificadores. Jerarquias de generalizacién. En el modelo ER es posible establecer jerar- quias de generalizacién entre las entidades. Una entidad E es una generaliza- cin de un grupo de entidades Ey, E2, «En si cada objeto de las clases E), E>, a es también un objeto de Ia clase E. Una generalizacion en el modelo ER expresa la abstraccién de gencralizacién expucsta en el apartado 2.1.3. La re~ presentacién esquematica de las generalizaciones se muestra en la figura 2.22. La flecha seftala la entidad generalizada. Cada entidad puede participar en multiples generalizaciones, posiblemente en el papel de entidad genérica con respecto a una generalizacién y en el papel de entidad subconjunto con respecto a otra generalizaciGn. La figura 2.23 pre- senta una jerarquia de generalizacion compleja para la entidad PERSONA. Lo opuesto a ja generalizacién se denomina especializacion, Las jerarquias de generalizacion se caracterizan por la propiedad de cober-2 DSENO CONCEPTUAL DE BASES DE DATOS PERSONA ARON EMORA ‘OIRECTOR ‘SECRETARIA EMPLEADO g, & E, DIRECTOR TECNICO Figura 2.22. Representacién de una generalizacién en el modelo EA tura, la cual se explicd en el apartado 2.2.3. Recuérdese que cada generalizacion puede ser total (1) o parcial (p) y exclusiva (e) 0 superpuesta (s). El par que se da con mids frecuencia es (t,e), que se considera como el valor por omisiOn y, por tanto, se omite en las figuras, En el ejemplo de la figura 2.23, la cobertura de la generalizacion es como sigue: 1. La generalizacién basada en el sexo es total y exclusiva. Con frecuencia se nombra la generalizacién en terminos de lo que le sirve como base de defi- nicin. Segin esto, tal generalizacion puede llamarse SEXO, y se usard este nombre en la descripcién linguistica (Fig. 2.30). 2. Si se supone que el dominio de aplicacién incluye personas que no son em- pleados ni secretarias ni directores, la generalizacién basada en el papel de- sempeftado es parcial y exclusiva. 3. Si se supone que los empleados pueden tener mas de un tipo de trabajo y que algunos tienen un tipo de trabajo distinto de los que se representan ex- PERSONA t ( fox varon || Hemera |[ omecton |{ secrerania |[ ewpuzan0 7 foo ) DIRECTOR. DIRECTOR. eweLe00 |[ewPLean0 TecNico” || ApMinisTaaTivo | |PROGRAMADOR |) Oe ventas |! oe puBLiCIDAD Figura 2.23. Jerarquia de generalzacién para la entidad Pensona,CONCEPTOS SOBRE EL MODELADO DE DATOS 4 plicitamente, la generalizacién que sc basa en ¢l tipo de trabajo ¢s parcial y superpuesta, 4. Si se supone que todos los directores tienen un papel directivo pero también que algunos pueden tener papeles tanto técnicos como administrativos, la generalizacion basada en el papel administrativo es total y superpuesta Recuérdese la propiedad fundamental de la abstraccién de generalizacién’ todas las propiedades de la entidad genérica son heredadas por las entidades subconjunto. En términos del modelo ER, esto significa que cada atributo, in- terrelaci6n o generalizacion definido para la entidad genérica serd heredado au- tomaticamente por todas las entidades subconjunto de la generalizacién. Esta propiedad es importante, porque permite construir jerarquias de generalizacién estructuradas. Considérese la figura 2.24a. La propiedad de herencia establece que los atri- butos NOMBRE y DIRECCION de PERSONA son también atributos de VARON y HEMBRA; luego, pueden ser eliminados de las entidades subconjunto, simplifi- cando el esquema, como muesira la figura 2.24c. Por otro lado, considérese el esquema de la figura 2.24b: éste representa una colocacién impropia de los atributos dentro de la generalizacion. Ciertamente,el atributo comin NOMBRE, que es una propiedad general de PERSONA, debe si- tuarse mds arriba en la jerarquia. En cambio, es obvio que SITUACION_MILITAR Y APELLIDO Y APELLIDO_DE_SOLTERA alaiten a VARON y HEMBRA, respectiva- mente, y deben situarse mds abajo, como muestra el esquema de la figura 2.24c. Hay que hacer notar que la cardinalidad minima de los dos atributos era 0 por la colocacién incorrecta de los atributos en la generalizacion; se convierte en 1 despues de la modificaci6n. Subconjuntos. Un subconjunto es un caso particular de jerarquia de gene- ralizaci6n, con una sola entidad subconjunto. Trataremos por separado los sub- conjuntos porque la cobertura de un subconjunto es claramente parcial y exclu- siva y no necesita definirse. Se representan los subconjuntos con una flecha que une la entidad genérica a la entidad subconjunto y apunta hacia le entidad ge~ nérica, como en la figura 2.25. Una entidad subconjunto puede tener atributos adicionales, como FECHA_DE_CONFIRMACION para TRABAJADOR_FUO. Atributos compuestos. Los atributos compuestos son grupos de atributos que tienen afinidad en cuanto a su significado 0 a su uso. Por ejemplo, el atri- buto compuesto DIRECCION abarca el grupo de atributos CALLE, CIUDAD, PRO- VINCIA, CODIGO_POSTAL y PAIS, Los atributos compuestos se representan con ovalos, como muestra la figura 2.26. Las cardinalidades minima y maxima se aplican a los atributos compuestos con las mismas definiciones dadas para los atributos simples. Notese, empero, que asignar cardinalidades minimas y maximas a los atributas compuestos agrega mas capacidades de modelado en comparacion con la asignacién de cardinali- dades a cada atributo individual. En el ejemplo de la figura 2.26, se afirma que una misma persona puede tener varias direcciones, y que cada direccién estaDISENO CONCEPTUAL. DE BASES DE DATOS Lo nomene PERSONA [9 DiRECCION NOMBRE of jo NOMBRE ORECCION 0] VARON Hemera [5 OIRECCION STUACION.MILITAR O-| [6 aPELLIOO_De_SOLTERA (a) Representacién ncorecta jo DIRECCION PERSONA [9 STUAGION MUITAR,O.1 [FS nPet1i00-De SOLTERAG.1) NowaRE Lo Nowe ARON Hemara [© SOMBRE {) Representacién incorrecta Lo nomen PERSONA [9 oiRECCION SITUACION.MUITAR Of LTERA Ea an pewreseecesn (6) Representacion corecta Figura 2.24, Transformaciones de las jerarquias de generaiizacién debido a la propie- dad de herencia compuesta por una calle, una ciudad, una provincia, un pais y, opcionalmente, tun cédigo postal, En cambio, si se usan cinco atributos independientes, sélo se podrd afirmar que cada uno de tales atributos es polivalente de manera inde- pendiente, y se tendra una menor capacidad expresiva. Tdentificadores. Un identificador de una entidad E es un grupo de atribu- tos o de entidades relacionados con E, que tienen la propiedad de determinarCONCEPTOS SOBRE EL MODELADO DE DATOS 45 TRABAJADOR ! TRABAJADOR +O FECHA_DE_CONFIRMACION FLO Figura 2.25. Ejemplo de subconjunto en forma tinica todos los casos de E. Desde un punto de vista terminoldgico, los identificadores se aman a veces en la literatura claves 0 claves candidatas. De un modo mas formal, sea E una entidad, sean A,....Ay atributos mono- valentes obligatorios de E, sean E,....E,, otras entidades vinculadas a E por in- terrelaciones binarias obligatorias, de uno a uno o de muchos a uno, Ris..Rim (es decir, tales que card-min (E,R,) = card-max (E.R) = 1). Considérese como tun posible identificador el conjunto I = {Aj...An, EinEm, n> 0, m > 0, n+ m > 1, El valor del identificador para un caso particular de la entidad e se de- fine como el conjunto de todos los valores de los atributos Aj, i = 1,2,..., y to- dos los casos de las entidades Ej, j~ 1,2,...m, vinculadas a e, con i < n,j 1 2. Un identificador es interno si m = 0; es externo sin = 0. 3. Un identificador es mixto sin > Oy m > 0. Por lo general, se prefiere los identificadores internos a los externos porque son més simples de entender y usar. Por la misma raz6n se prefiere los identi- ficadores simples a los compuestos. Al final del proceso de disefto, se requiere que cada entidad sca provista de al menos un identificador. Es importante evitar la circularidad en la definicion de los identificadores (por cjemplo, el uso de la entidad E; en la identificacién de la entidad Ej y dela entidad Ej en la identificacion de la entidad E). A fin de evitar la circularidad, siempre que una entidad E; esté implicada en la identificacion de la entidad E, Ej deberd poseer un identificador adecuado que no dependa de E. Esto se con- sigue en la practica comenzando el proceso de identificacién con las entidades que puedan identificarse internamente (estas entidades sc llaman a veces enti- dades fuertes) y creando después identificadores para las entidades que solo po- sean identificadores externos (a veces llamadas entidades débiles). La figura 2.27 presenta varios ejemplos de identificadores. En todos los ca- s0s, el simbolo gréfico para la identificacion es un circulo negro; sin embargo, cada tipo de identificador requiere una representacion grafica diferente. En la figura 2.27a, NUMERO_DF_SEGURO_SOCIAL es un identificador simple e interno de PERSONA, lo que se representa coloreando en negro el simbolo del atributo correspondiente. En la figura 2.27b, NOMBRE, FECHA_DE_NACIMIENTO, NOMBRE_DEL_PADRE Y CIUDAD_DE_RESIDENCIA forman un identificador compuesto e interno de PERSONA. Los identificadores compucstos estén representados gréficamente por un segmento de linea que une los dos o més elementos que confieren identifi- cacién, Un circulo negro seftala la interseccién entre el segmento y cada ele- mento del identificador. Si al identificador se le asigna un nombre, uno de los extremos del segmento tiene un circulo negro y un nombre. En este ejemplo, el nombre es IDENTIFICADOR_DE_PERSONA. Considérese la entidad EMPLEADO (Fig, 2.27c), conectada a la entidad de- partamento por la interrelacién TRABAJA_EN, con card-mdéx (EMPLEADO, TRA- BAJALEN) = 1. Entonces, la entidad DEPARTAMENTO y el atributo NUMERO- -DE_EMPLEADO_POR_DEPARTAMENTO constituyen un identificador externo, ‘compuesto y mixto de EMPLEADO. Ahora considérese la entidad DETALLE_PEDIDO (Fig. 2.274). Supéngase que cada DETALLE_PEDIDO esta conectado a la entidad PRODUCTO mediante la in- terrelacién Para y ala entidad CABECERA_PEDIDO mediante la interrelacion DE, con card (DETALLE_PEDIDO,DE) = card (DETALLE_PEDIDO,PARA) = (1,1), Se su- pone también que dos DETALLE_PEDIDO no pueden relacionarse con el mismo producto dentro del mismo pedido. Entonces, el par de entidades CABECERA-CONCEPTOS SOBRE EL MODELADO DE DATOS PERSONA (0 \oonticador EPAATAVENTO| CL |e numeno_be_secuno.socia (@) Kdeniticador simple e interno penoow EES “© NOMBAE_OEL_PAORE NowaRe FECHA_DE_NACIMENTO (CIUDAD_DE_RESIDENCIA ¢¢ WDENTIFICADOF_DE_PERSONA compuesto e interno © NUMERO_DE_EMPLEADO_. POR_DEPARTANENTO {€) Kdentitcador compuesto, externo y moxto CABECERA, PEDDO PRODUCTO (@) Woentiticadores de la entad DETALLE_PEDIOO Figura 2.27. Identificadores en el modelo cA. -PEDIDO (mediante DE) y producto (mediante PARA) componen un identifica- dor externo y compuesto, llamado A, de DETALLE_PEDIDO. Como aiternativa para la entidad DETALLE PEDIDO, supOngase que cada DETALLE_PEDIDO se nu- mera progresivamente dentro de cada pedido por el atributo NUMERO_DE_LI- NEA; entonces, el par CABECERA_PEDIDO (mediante DE) y NUMERO_DE_LINEA e un identificador externo, mixto y compuesto, llamado B, de DETALLEPEDIDO.48 DSENIO CONCEPTUAL DE BASES DE DATOS NOMBRE PERSONA NUMERO_DE_SEGURO_SOGAL teers wo t tow t | non ewan exraco || seenean | econ | san Temncon Sareuno. Swmera, J sumo 3 wineno.060 MUG” ° GeESoPRtta ” el eweteAne cunt ©ranco Figura 2.28. Jerarquias de generaiizacién, atrbutos compuestos @ kdentiicacor en ‘modelo en. Puesto que la identificacion es una propiedad de las entidades, es una de las propiedades heredadas en las generalizaciones 0 subconjuntos: el identificador de la entidad genérica es, asimismo, un identificador de las entidades subcon- junto. Las entidades subconjunto pueden tener identificadores adicionales. En la figura 2.28, cada persona se identifica por el niimero de seguro social; cada empleado se identifica por un ntimero de empleado, asignado dentro de la com- paitia; cada militar se identifica por el nombre de la divisién y cl mimero de identificacion dentro de la division. ‘Concluimos este apartado mostrando una representacién lingifstica del mo- delo ER. La figura 2.29 muestra la gramatica BNF’ completa para el lenguaje de definicién de esquemas. Se usan estas convenciones: los corchetes denotan op- ci6n, las claves indican repeticién, el prefijo lisia_de indica una secuencia de elementos separados por comas y el prefijo nombre_de denota los identificado- res. Las reglas para los no terminales ENTERO y VALOR se omiten. Cada defini- cién de esquema se divide en una secuencia de definiciones de emtidades, defi- niciones de jerarquias de generalizacién y definiciones de interrelaciones. Cada definicién se explica por sf misma. Obsérvese que una generalizacion se define en términos de padre (entidad) ¢ hijos (entidades); el padre representa la entidad superconjunto. La figura 2.30 presenta una definicién linguistica, de acuerdo con la gra- miatica BNF del lenguaje CsDL dada en la figura 2.29, del esquema de la figura 2.28. La figura 2.21 contiene otro ejemplo de definicién lingdistica de un es- quema, de acuerdo con la gramatica BNF de la figura 2.29. Para finalizar, la fi- gura 2.31 resume los simbolos gréficos usados en cl modelo ER. * En la convescin avr una gramética se describe com ua conjunto de eat o wpoduccioness. Los trminos «que aperecen ene ado izquierdo deal menos wna rgla se Maman no trminales los que o aparecen en el lado laquierd de ninguna reason terminates. Las barras vercalesen el ado derecho de una rea muestran formes alteratvas de satisfacer el no-terminal det lado inquierdo. Si se desea mayores detalles acerca de como ler una ammtica wr, consltese un texto sobre lenguaes de progzamacicn o compladoss.