Monografía: Bases de Datos Avanzadas
Transcripción
Monografía: Bases de Datos Avanzadas
NOVATICA jul./ago. 1999 nº140 Novática, revista fundada en 1975, es el órgano oficial de expresión y formación continua de ATI (Asociación de Técnicos de Informática) ATI es miembro de CEPIS (Council of European P r o f e s s io n a l Infor matics Societies ) y tiene un acuerdo de colaboración con ACM (Association for Computing Machinery). Tiene asimismo acuerdos de vinculación o colaboración con AdaSpain, AII y ASTIC CONSEJO ASESOR DE MEDIOS DE COMUNICACION Pere Lluís Barbarà, Javier Bruna, Rafael Fernández Calvo, Francisco J. Forero, Nacho Navarro, Fernando Piera Gómez (Presidente), Fernando Sanjuán de la Rocha, Miquel Sarries, Carlos Sobrino Sánchez Coordinación Editorial Rafael Fernández Calvo <[email protected]> Ayudantes Editoriales Tomás Brunete, Jorge Llácer (autoedición) El servidor Web de ATI contiene información sobre Novática en la dirección http://www.ati.es/novatica SECCIONES TECNICAS: COORDINADORES Arquitecturas Antonio Gonzalez Colás (DAC-UPC) <[email protected]> Bases de Datos Mario G. Piattini Velthuis (EUI-UCLM) <[email protected]> Calidad del Software Juan Carlos Granja (Universidad de Granada) <[email protected]> Derecho y Tecnologías Isabel Hernando Collazos (Fac. Derecho de Donostia, UPV) <[email protected]> Enseñanza Universitaria de la Informática J.Angel Velázquez (ESCET, URJC) <[email protected]> Euro/Efecto 2000 Joaquín Ríos Boutín <[email protected]> Informática Gráfica Enric Torres <[email protected]> Roberto Vivó <[email protected]> (Eurographics, sección española) Ingeniería de Software Luis Fernández (PRIS-E.I./UEM) <[email protected]> Inteligencia Artificial Federico Barber,Vicente Botti (DSIC-UPV) <{vbotti, fbarber}@dsic.upv.es> Interacción Persona-Computador Julio Abascal González (FI-UPV) <[email protected]> Internet Alonso Alvarez García (TID) <[email protected]> Llorenç Pagés Casas (BIS) <[email protected]> Lengua y Tecnologías de la Información Javier Gómez Guinovart (Universidad de Vigo) <[email protected]> Manuel Palomar (Universidad de Alicante) <[email protected]> Libertades e Informática Alfonso Escolano (FIR-Universidad de La Laguna) <[email protected]> Metodologías Julián Marcelo Cocho (UPV) <[email protected]> Seguridad Javier Areitio (Redes y Sistemas, Bilbao) <[email protected]> Sistemas de Tiempo Real Alejandro Alonso, Juan Antonio de la Puente (DIT-UPM) <{aalonso,jpuente}@dit.upm.es> Software Libre Jesús M. González Barahona, Pedro de las Heras Quirós (GSYC, Universidad Carlos III) <{jgb,pheras}@gsyc.inf.uc3m.es> Tecnología de Objetos Esperanza Marcos (URJC) <[email protected]> Tecnologías para la Educación Benita Compostela (F. CC. PP.- UCM) <[email protected]> Josep Sales Rufí (ESPIRAL) <[email protected]> Tecnologías y Empresa Luis Álvarez Satorre (British Telecom) <[email protected]> Pablo Hernández Medrano (Meta4) <[email protected]> Las opiniones expresadas por los autores son responsabilidad exclusiva de los mismos. Novática permite la reproducción de todos los artículos, salvo los marcados con © o copyright, debiéndose en todo caso citar su procedencia y enviar a Novática un ejemplar de la publicación. Coordinación Editorial y Redacción Central (ATI Madrid) Padilla 66, 3º, dcha., 28006 Madrid Tlf.914029391; fax.913093685 <[email protected]> Composición, Edición y Redacción ATI Valencia Palomino 14, 2ª, 46003 Valencia Tlf./fax 963918531 <[email protected]> Administración y Redacción ATI Cataluña Via Laietana 41, 1º, 1ª, 08003 Barcelona Tlf.934125235; fax 934127713 <[email protected]> Redacción ATI Andalucía Isaac Newton, s/n, Ed. Sadiel, Isla Cartuja 41092 Sevilla Tlf./fax 954460779 <[email protected]> Redacción ATI Aragón Lagasca 9, 3-B, 50006 Zaragoza Tlf./fax 976235181 <[email protected]> Redacción ATI Galicia Recinto Ferial s/n, 36540 Silleda (Pontevedra) Tlf.986581413; fax 986580162 <[email protected]> Redacción ATI Asturias-Cantabria <[email protected]> Publicidad: Padilla 66, 3º, dcha., 28006 Madrid Tlf.914029391; fax.913093685 <[email protected]> Imprenta: Gráficas Sierra S.L., Atenas, 3, int. bajos, 08006 Barcelona. Depósito Legal: B 15.154-1975 ISBN: 0211-2124; CODEN NOVAEC Portada: Antonio Crespo Foix 1 SUMARIO Editorial Monografía: Bases de Datos Avanzadas Coordinada por Mario G. Piattini Velthuis Presentación Mario Piattini Sobre la evolución reciente de las bases de datos Félix Saltor Bases de datos: ¿medios o fines? César Pérez-Chirinos SQL:1999, hasta ahora conocido como SQL3 Jim Melton, Andrew Eisenberg Consultas sobre la Web J.F. Aldana Montes, M.I. Yagüe del Valle Calidad de esquemas conceptuales Mario Piattini, Marcela Genero, Coral Calero, Macario Polo, Francisco Ruiz Control de restricciones de cardinalidad en una metodología de desarrollo de bases de datos relacionales Dolores Cuadra, Carlos Nieto, Paloma Martínez, Adoración de Miguel Técnicas de Indexación para las Bases de Datos Orientadas a Objetos Ana Belén Martínez Prieto, J. Manuel Cueva Lovelle Una revisión de los métodos multidimensionales Miryam Salas, Antonio Polo, Elena Jurado /DOCS/ El Código de Ética y Práctica Profesional de Ingeniería del Software de la ACM / IEEE-Computer Society Introducción y traducción: Javier Dolado 2 4 5 8 12 18 23 28 34 40 48 Secciones técnicas Informática Gráfica Sustitución Geométrica Interactiva mediante Sistemas Paramétricos Aleatorios J. Lluch, M. Chover,R. Quirós, R. Vivó 52 Ingeniería de Software ¿Merece la pena usar los puntos de función? Javier Dolado, Luis Fernández Sanz 57 Metodologías Metodología METRICA Orientada a Objetos José R. Hilera 63 Referencias autorizadas 67 Sociedad de la Información Personal y transferible La Lengua Española en el contexto informático Antonio Vaquero 71 Asuntos Interiores Coordinación Editorial Programación de Novática Normas de publicación para autores Socios Institucionales 76 76 77 77 NOVATICA jul./ago. 1999 nº140 2 Editorial Un NO rotundo a los Colegios Profesionales excluyentes Desde hace unos meses nuestra asociación está teniéndose que ocupar de frenar la ofensiva que desde otra asociación, ALI (Asociación de Doctores, Licenciados e Ingenieros en Informática), se está llevando a cabo para tratar de imponer por vía legislativa unos Colegios Profesionales de Informáticos de carácter cerrado, excluyente y corporativista, altamente nocivos, en nuestra opinión, no solamente para los socios de ATI no titulados en Informática sino para el conjunto de los profesionales informáticos, titulados o no, y para la Sociedad en general. Primero fue una iniciativa legislativa de D. Antonio Luis Cárceles, diputado por Murcia del Grupo Parlamentario Popular en el Congreso de los Diputados, con el objeto de formar un Colegio Profesional de Ingenieros en Informática de ámbito estatal. Aparte de otros aspectos reprobables, la propuesta del diputado Cárceles ponía dicho Colegio directa y plenamente en manos de la ALI, sin ninguna consideración a las demás asociaciones representativas de los profesionales informáticos, como la nuestra, que es ampliamente mayoritaria en España, con 5.000 socios, o la AI2 (Asociación de Ingenieros en Informática). Esta última asociación, con la que ATI tiene excelentes relaciones, mantiene sobre el asunto de la colegiación una posición mucho más matizada y asumible por nosotros, como demuestra la Ley aprobada por la Comunidad de Murcia. Afortunadamente, la propuesta del diputado Cárceles (que, además, iba en contra de la Ley Estatal de Colegios, que determina que la creación de Colegios es competencia de las Comunidades Autónomas) quedó frenada, con la intervención de nuestro anterior Presidente, Alberto Llobet, que dirigió una carta al Portavoz del Grupo Parlamentario del Partido Popular, Sr. de Grandes. Pues bien, en Junio nos vimos sorprendidos por la presentación del anteproyecto de ley de creación del Colegio Oficial de Ingenieros en Informática de la Comunidad Valenciana, promovido también por ALI, en el que esta asociación, arrogándose la representatividad de una supuesta mayoría de los Ingenieros y Licenciados en Informática en dicha Comunidad, lleva al paroxismo la cerrazón, la exclusión y el corporativismo, como se puede demostrar por los siguientes artículos: Artículo 3, párrafo 1: "Para el ejercicio de la profesión de informático para la que habilitan los títulos universitarios de Ingeniero en Informática y Licenciado en Informática, en el ámbito territorial de la Comunidad Valenciana será obligatoria la previa incorporación al Colegio Oficial de Ingenieros en Informática de la Comunidad Valenciana …" Artículo 3, párrafo 2: "La incorporación al Colegio Oficial de Ingenieros en Informática de la Comunidad Valenciana, requiere estar en posesión del título universitario de Ingeniero en Informática o Licenciado en Informática …". De aprobarse la ley en estos términos, én la Comunidad Valenciana solamente podrían ejercer la profesión informática quienes, además de tener el título de Ingeniero Superior en Informática o de Licenciado en Informática, sean miembros del Colegio Oficial. ¿Qué pasaría con los titulados en Ingeniería Técnica Informática; o con los titulados superiores o medios de otras procedencias (Exactas, Físicas, Telecomunicaciones, Industriales, Estadística, etc) que han cursado materias o especialidades relacionadas con la Informática; o con los titulados superiores o medios de otras carreras no relacionadas con la Informática que han desarrollado su carrera profesional en esta disciplina (no pocos de los cuales obtuvieron su titulación en fechas anteriores a la creación de Centros Oficiales de Enseñanza Informática); o con quienes han cursado especialidades informáticas de Formación Profesional? ¿Qué pasaría finalmente con los profesionales informáticos sin titulación? Un efecto nocivo adicional de este anteproyecto, que sin duda provocará el rechazo de las empresas y organismos públicos, es que el profesional informático que tuviera que trabajar en la Comunidad Valenciana de forma temporal, aunque fuese una semana, tendría que darse de alta en el Colegio. Además de ir contra el sentido común, ello iría contra la legislación vigente en la Unión Europea sobre movilidad de los trabajadores. Para culminar el despropósito, la disposición transitoria primera del Anteproyecto de Ley determina que "La Demarcación en la Comunidad Valenciana de la Asociación de Doctores, Licenciados e Ingenieros en Informática (es decir, ALI), designará una Comisión Gestora que, en el plazo de seis meses desde la entrada en vigor de la presente Ley, aprobará unos estatutos provisionales del Colegio Oficial de Ingenieros en Informática de la Comunidad Valenciana, en los que se regule la convocatoria y el funcionamiento de la Asamblea Colegial Constituyente de la NOVATICA jul./ago. 1999 nº140 3 que formarán parte todos los profesionales inscritos en el censo de Ingenieros y Licenciados en Informática ejercientes en la Comunidad Valenciana. La convocatoria se publicará en el Diari Oficial de la Generalitat Valenciana". Consideramos como radicalmente contrario al principio constitucional de igualdad ante la ley el hecho de que la Generalitat Valenciana otorgue a la Demarcación territorial de ALI en dicha Comunidad, cuya representatividad mayoritaria está por acreditar y de la cual carece por las informaciones de que disponemos, la facultad de dirigir de forma monopolista un proceso constituyente en el que va a ser juez y parte. Pero incluso en el hipotético caso de que fuese mayoritaria, en la Comunidad Valenciana tienen presencia no sólo ALI, sino nuestra asociación ATI y otras Asociaciones minoritarias y más especializadas, a las que no se puede dejar apartadas de un proceso legislativo como éste, que nos afecta directamente. Además, ¿quién ha elaborado ese censo?, ¿quién garantiza su legalidad?, ¿quién ha definido legalmente qué es un "informático"? En el debido tiempo y plazo la Junta Directiva del Capítulo de ATI en Valencia, con el total respaldo de la Junta Directiva General, presentó en la Consellería de la Presidencia de la Generalitat Valenciana unas amplias y documentadas alegaciones (disponibles en nuestro sitio web http:www.ati.es), que fueron complementadas con los contactos políticos pertinentes, conducentes a exponer a los diversos estamentos públicos el despropósito que constituye el anteproyecto y a ofrecerles nuestra plena colaboración para la elaboración de una ley que regule de forma sensata esta delicada materia. Afortunadamente, ATI, que no es un Colegio ni pretende llegar a serlo, cuenta con un cuerpo de doctrina sobre este tema, elaborado en el curso de muchos años y que se ha actualizado y completado en el documento publicado en la sección /DOCS de Novática 139 (Mayo-Junio de 1999), en el que literalmente se dice lo siguiente: "... 2. ATI no debe oponerse a la creación de Colegios Profesionales de Informáticos siempre que su regulación legal cumpla las siguientes condiciones: a. Máximas facilidades de incorporación a los Colegios para el mayor número posible de profesionales informáticos que, sin ser titulados en Informática, cumplan determinadas condiciones (académicas y de ejercicio profesional continuado y demostrable) y deseen incorporarse a los mismos. b. Inexistencia de obstáculos al libre desempeño, por parte de los informáticos no titulados, del ejercicio profesional de la Informática o a su libre acceso al mismo. 3. ATI se opondrá resueltamente a que la regulación legal de los Colegios otorgue privilegios a cualquiera de las asociaciones de titulados informáticos existentes en la actualidad o que puedan crearse en el futuro." En sintonía con lo anterior, ATI, que no quiere entrar en guerras entre asociaciones porque las respeta a todas pero exige también de las demás ese mismo respeto, está dispuesta a dialogar con ALI de forma abierta y razonable sobre la colegiación de los informáticos porque cree que no es con la prepotencia, la exclusión y el corporativismo como este asunto debe abordarse. Pero a la vez va a hacer llegar su voz con claridad a los profesionales informáticos de todo el país (titulados o no, socios de ATI o no), para decirles que no está dispuesta a tolerar que la profesión informática se convierta en un reducto hermético en manos de un grupo que se atribuye la representatividad exclusiva de la misma. Les dirá también que, para impedir este desafuero, ha puesto en marcha todos los medios legales pertinentes, tanto en nuestro país como en el marco de la Unión Europea, llevando el caso también al conocimiento de CEPIS (Council of European Professional Informatic Societies), entidad de la que tanto ATI como ALI son miembros. A tal fin, ATI intentará contar con la colaboración de otras entidades que compartan nuestras posiciones. Y les dirá finalmente que asociarse a ATI es la mejor manera de defender sus, nuestros, legítimos intereses, en beneficio no sólo de los profesionales informáticos sino de la Sociedad en su conjunto, que se vería afectada negativamente por una regulación retrógrada e inadecuada de una profesión tan decisiva para una sociedad en la que las Tecnologías de la Información y de las Comunicaciones tienen un papel cada vez más relevante. ATI se organiza en Galicia, Asturias y Cantabria La Asamblea General de ATI, celebrada el 15 de Junio, aprobó la creación del Capítulo Territorial de ATI en Galicia <[email protected]>. Hasta la realización de las elecciones a la Junta Directiva territorial, será dirigido por los componentes del actual Grupo Promotor, cuyo coordinador es el socio José Gómez. El 23 de Junio se constituyó en Oviedo el Grupo Promotor de ATI en Asturias-Cantabria <[email protected]>, siendo elegido como coordinador del mismo Juan Manuel Cueva Lovelle. 4 MONOGRAFIA NOVATICA jul./ago. 1999 nº140 Bases de Datos Avanzadas Mario Piattini* Presentación <[email protected]> Se cumplen ya treinta años desde que el Dr. Codd propuso el modelo relacional, dando lugar a la "segunda generación" de productos de bases de datos: ORACLE, DB2, INGRES, INFORMIX, SYBASE, etc. que presentan una mayor independencia físico/lógica, mayor flexibilidad y lenguajes de especificación (que actúan sobre conjuntos de registros). Este tipo de productos se ha ido imponiendo en el mercado y ha sido uno de los principales focos de investigación durante las décadas de los setenta y ochenta. En los últimos años venimos asistiendo a un avance espectacular en la tecnología de bases de datos. Temas que hasta hace poco parecían exclusivos de laboratorios y centros de investigación, comienzan a aparecer en las últimas versiones de algunos SGBD y en nuevos productos: bases de datos multimedia, activas, deductivas, orientadas a objetos, seguras, temporales, móviles, paralelas, multidimensionales, etc. Esta nueva generación de bases de datos (la "tercera"), se caracteriza por proporcionar capacidades de gestión de datos, objetos y gestión de conocimiento y pretende responder a las necesidades de aplicaciones tales como: CASE (Ingeniería del software asistida por ordenador), CAD/CAM/CIM, SIG (sistemas de información geográfica), información textual, aplicaciones científicas, sistemas médicos, publicación digital, educación y formación, sistemas estadísticos, comercio electrónico, etc. Todas estas nuevas tecnologías afectan al proceso de diseño de bases de datos, que resulta cada día más difícil, así como a la administración de los sistemas. Por otra parte, también se propugna el desarrollo de nuevos estándares como el ODMG y el SQL:1999, que recojan las características de esta nueva generación. Esta monografía de Novática recoge algunos trabajos que se están desarrollando sobre estas bases de datos avanzadas. En primer lugar, se han incluido dos artículos invitados que representan puntos de vista distintos y complementarios, el profesor Félix Saltor de la UPC reflexiona sobre la evolución de las bases de datos, mientras que César Pérez-Chirinos de TransTOOLs, ofrece una visión más "heterodoxa" del tema. A continuación, Jim Melton y Andrew Eisenberg explican los cambios realizados en el próximo estándar para bases de datos objeto-relacionales, SQL:1999, hasta ahora conocido como SQL3. A continuación se incluyen cinco artículos técnicos que han sido seleccionados de un total de quince enviados por los principales investigadores nacionales. La revisión de estos artículos ha sido llevada a cabo por un amplio Comité Técnico compuesto por: Pedro Blesa (Univ. Politécnica de Valencia), Nieves Brisaboa (Univ. de A Coruña), Verónica Canivell (Univ. de Deusto), Julia Couto (Univ. Complutense de Madrid), Juan Manuel Cueva (Univ. de Oviedo), Adoración de Miguel (Univ. Carlos III de Madrid), Oscar Díaz (Univ. del País Vasco), Juan Garbajosa (Univ. Politécnica de Madrid), Jesús García Molina (Univ. de Murcia), Esperanza Marcos (Univ. Rey Juan Carlos de Madrid), Jesús Maudes (Univ. de Burgos), Oscar Pastor (Univ. Politécnica de Valencia), Estrella Pulido (Univ. Autónoma de Madrid), Francisco Ruiz (Univ. de Castilla-La Mancha), Alfredo Roy (Univ. de Zaragoza), Miryam Salas (Univ. de Extremadura), Ernest Teniente (Univ. Politécnica Cataluña), Ambrosio Toval (Univ. de Murcia) y Mariemma Yagüe del Valle (Univ. de Málaga). Actuaron también como revisores adicionales: Ángel Velázquez (Univ. Rey Juan Carlos de Madrid) y Mª José Ortín (Univ. de Murcia). Quiero agradecer a todos ellos el trabajo realizado, así como a todos los autores que han enviado trabajos para este monográfico. Los artículos abarcan diversos temas: bases de datos y web, calidad de esquemas conceptuales, control de restricciones en una metodología de desarrollo de bases de datos relacionales, técnicas de indexación para las bases de datos orientadas a objetos y una revisión de los métodos de acceso multidimensionales. Por supuesto, quedan muchos más temas interesantes por tratar que el lector puede encontrar en la sección técnica de Bases de Datos de esta revista, o en las actas de las "Jornadas de Bases de Datos" cuya cuarta edición se celebra este año en Cáceres del 24 al 26 de noviembre de 1999, organizadas por la Universidad de Extremadura. Sólo nos queda por desear que esta nueva generación de bases de datos vaya alcanzando su madurez en los tres planos posibles: en el plano científico, es decir, la investigación dedicada a la tecnología; en el plano industrial, esto es, en cuanto al desarrollo de productos que empleen la tecnología por parte de suministradores, y en el plano comercial, es decir, su aceptación y utilización por parte de los usuarios. Bibliografía básica Se vienen publicando, de manera regular, diversas referencias sobre bases de datos en la sección de "Referencias Autorizadas" de esta revista. También se publicó un artículo interesante sobre la formación en bases de datos, en la que se recogían varias fuentes bibliográficas (véase número Enero/febrero 1999, págs: pp. 60-63). A continuación algunos textos recientes. Fundamentos: Elmasri, R. y Navathe, S.B. (1997); Sistemas de Bases de Datos. Conceptos fundamentales. Addison-Wesley Iberoamericana. Silberschatz, A., Korth, H. y Sudarshan, S. (1998); Fundamentos de Bases de Datos (3ª edición). Mc Graw-Hill. De Miguel, A. y Piattini, M. (1999); Fundamentos y modelos de bases de datos (2ª edición). Editorial Ra-Ma. McFadden, F.R., Hoffer, J.A. y Prescott, M.B. (1999); Modern Database Management. Addison-Wesley. Date, C. J. (1997); Introducción a los sistemas de bases de datos (6º edición). Addison-Wesley Iberoamericana. Bases de Datos avanzadas: Kim, W. (ed.) (1995); Modern database Systems. The Object Model, Interoperability and Beyond. ACM Press. Stonebraker, M. y Brown, P. (1999); Object-Relational DBMSs tracking the next great wave. Morgan Kauffman Publishers. Piattini, M. y Díaz, O. (1999); Advanced Databases: Technology and Design. Artech House. Diseño de bases de datos: Batini, C., Ceri, S. y Navathe, S. (1994); Diseño Conceptual de bases de datos. Un enfoque de entidades-interrelaciones. Addison Wesley Iberoamericana. Connolly, T., Begg, C. y Strachan, A. (1999); Database Systems (2ª edición). Addison-Wesley. De Miguel, A., Piattini, M. y Marcos, E. (1999); Diseño de bases de datos relacionales. Editorial Ra-Ma. Blaha, M. y Premerlani, W. (1998); Object-oriented modeling and design for database applications. Prentice-Hall. Ceri, S. y Fraternali, P. (1997); Designing Database Applications with Objects and Rules: The IDEA Methodology. Addison-Wesley. Coordinador de la monografía * Mario Piattini Velthuis es Doctor Ingeniero en Informática por la Universidad Politécnica de Madrid. Master en Auditoría Informática (CENEI). Especialista en la Aplicación de Tecnologías de la Información a la Gestión Empresarial (CEPADE-UPM). Ha sido director del Departamento de Desarrollo de la empresa SiE, y sociofundador de Cronos Ibérica, S.A. y ha trabajado como consultor y profesor para numerosos organismos y empresas. Ha sido profesor asociado de los Departamentos de Informática y Automática de la Universidad Complutense de Madrid y del Departamento de Informática de la Universidad Carlos III de Madrid. Actualmente es Profesor Titular de Universidad en la Escuela Superior de Informática de la Universidad de Castilla-La Mancha en Ciudad Real, donde dirige el grupo de investigación Alarcos, especializado en Sistemas de Información, Bases de Datos e Ingeniería del Software. Coautor y/o coeditor de varios libros así como de un centenar de artículos en revistas nacionales e internacionales. Pertenece a diversas asociaciones profesionales (ACM, IEEE-CS, ISACA, PMI, ATI, ALI, AII, OAI, Ada-Spain, AEC, AENOR, etc.). NOVATICA jul./ago. 1999 nº140 MONOGRAFIA 5 Bases de Datos Avanzadas Fèlix Saltor Dept LSI, Universitat Politècnica de Catalunya 1. Introducción El tema de las bases de datos no es una novedad en Novática. En particular, le estuvieron dedicados los números 11 (del año 1976), 51-52 y 53 (del 83), y el 91 (del año 91, coincidente con el congreso VLDB’91 de Barcelona), además de artículos al respecto en diversos números, en particular en la Sección técnica de Bases de Datos, y de temas relacionados, como Data Mining/Data Warehousing en el número 137. En este breve artículo ofrezco mi opinión, subjetiva como todas, sobre la evolución de las bases de datos en estos últimos años. El lector interesado en los hitos más importantes de toda la historia de las bases de datos puede recurrir, por ejemplo, a [Stonebraker98]. Esta evolución reciente viene marcada, sobre todo, por el afianzamiento de las bases de objetos (sección 2), y por la extensibilidad de las relacionales (sección 3), sin olvidar otros temas (sección 4). La evolución continua su camino, y para los interesados es importante observarla (sección 5). Después de los dos famosos Manifestos, reproducidos en aquel número 91 de Novática, se ha producido, entre las bases de datos relacionales por un lado, y las bases de objetos por otro, una colaboración y una competencia: colaboración en el intento infructuoso de unificar los modelos en uno solo y de hacer convergir los lenguajes SQL y OQL, llegándose al menos a poder acceder en el futuro tanto a unas bases como a otras en cualquiera de los dos lenguajes; competencia en los intentos de mantener y ampliar las cuotas respectivas de un mercado tan activo y dinámico como el de los sistemas de gestión de bases de datos (SGBDs). 2. Bases de objetos Las bases de objetos (también conocidas como "bases de datos orientadas a objetos", "bases de datos orientadas al objeto", o "bases de datos obje(c)tuales"), no aparecieron por evolución de bases de datos anteriores, como pudieran ser las relacionales -de hecho se parecen más a las CODASYLsino por ruptura respecto a las precedentes, partiendo de lenguajes de programación orientados a objetos y dotándolos de persistencia. A sus sistemas de gestión los llamaremos SGBOs (Sistemas de gestión de bases de objetos), y para sus características puede consultarse [Cattell94] o [deMiguel99]. El esfuerzo llevado a cabo por los fabricantes de SGBOs estos últimos años ha sido realmente grande, y no sólo en la mejora de sus respectivos productos. Los más importantes de entre ellos constituyeron el ODMG (Object Database Management Group, hoy en día Object Data Management Group [ODMG]), desarrollaron un modelo de datos común (basado en el modelo del OMG) con su lenguaje OQL, se comprometieron a implementarlo en sus productos, y lo han ido mejorando hasta llegar al modelo ODMG 2.0 de [Cattell97]. Las bases de objetos resultan particularmente ventajosas en aplicaciones de CAD (Diseño asistido por ordenador), CAM (Fabricación asistida por ordenador), CAE (Ingeniería asis- Sobre la evolución reciente de las bases de datos tida por ordenador), CASE, etc. El peligro para los fabricantes de SGBOs de quedar limitados al nicho del mercado constituido por estas aplicaciones CAx me parece verse superado por tres razones, no directamente fruto de la tecnología de bases de datos: 1. Java. La versión 2.0 del modelo ODMG especifica interfaces no sólo a los lenguajes C++ y Smalltalk sino también a Java. Cuando los SGBOs soporten esta interfaz, el ascenso imparable de Java será un tanto a su favor; 2. UML. El uso creciente del Unified Modeling Language ([UML]) para la especificación y diseño de sistemas de información propicia que sus datos se gestionen en bases de objetos de una manera más natural -tecnología de objetos del principio al final- que en SGBDs. Aunque la naturalidad del diseño no es el único factor en la elección, y el diseño relacional a partir de UML no es más difícil que el clásico desde E-R; y 3. CORBA. Ante la creciente necesidad de datos/objetos distribuidos, la utilización de CORBA (Common Object Request Broker Architecture [CORBA]) resulta en muchos casos la más adecuada, y lo será más cuando los productos implementen todos los servicios especificados en la arquitectura: Persistence services, transaction services, etc. Incluso datos relacionales o en otros formatos pueden participar a través de "envoltorios" (wrappers) que los presenten como objetos. Entre los fabricantes de SGBOs hay, además de esta colaboración en ODMG, una feroz competencia, porque no todos sobrevivirán. 3. Bases de datos relacionales extendidas Las bases de datos relacionales, y sus SGBDs, por su parte, han ido evolucionando estos últimos años para soportar objetos y reglas, y para ampliar el lenguaje SQL y hacerlo extensible -nuevos tipos, nuevas operaciones- y computacionalmente completo. El soporte de los Persistent Stored Modules es una mejora importante, tanto para la productividad del desarrollo de aplicaciones y la seguridad, como para la eficiencia en entornos cliente/servidor. El desarrollo del nuevo estándar de SQL ha sido más largo de lo previsto (ver el artículo de Melton & Eisenberg en este mismo número de Novática), y no sólo por lo ambicioso de sus objetivos o como consecuencia directa de los intentos de convergencia con el modelo de ODMG y su lenguaje OQL. Indirectamente, estos intentos han obligado a profundizar en el entendimiento del propio modelo relacional, planteándose y resolviendo preguntas como: una variable que toma valores sobre tuplas de una relación, ¿de qué tipo (en el sentido de los lenguajes de programación) es? También aquí , además de esta colaboración en el desarrollo del nuevo estándar, ha habido una fuerte competencia, sobre todo entre los tres "grandes": DB2 de IBM con sus extenders, Informix con sus datablades, y Oracle con sus cartridges, en particular para soportar multimedia -gráficos, textos, imagen, sonido, vídeo-, o si se quiere entre los cinco mayores, añadiendo Sybase y SQL Server de Microsoft a aquellos tres. En esta evolución recente, cabe destacar que el impacto de Java da lugar a JDBC y al SQLJ. Por otra parte, a pesar del soporte de reglas, no ligadas a clases como en las bases de objetos, el campo de las bases de datos NOVATICA jul./ago. 1999 nº140 6 deductivas, tan prometedor hace pocos años, no ha eclosionado todavía. 4. Otros temas incompleta o incierta, y en bibliotecas digitales, entre otras técnicas, y han aparecido las bases de datos móbiles o nómadas. Las nuevas técnicas son tratadas en libros como [Zaniolo97] y [Yu98]. 4.1. La Web 5 La evolución prosigue La influencia de la World Wide Web lo impregna todo, y no solamente la información bibliográfica, y un ejemplo de ello son las referencias de este artículo. En su desarrollo se han ignorado las técnicas de bases de datos y se han repetido errores cometidos en las primeras generaciones de SGBDs. La Web puede verse como una nueva interfaz de acceso a bases de datos, y muchos SGBDs ya proporcionan herramientas para generar dinámicamente, a partir de sus datos, páginas virtuales en HTML. Pero la Web puede también ser considerada como una inmensa base de datos, o como una confederación de bases de datos -en los servidores-, o incluso como una plétora innúmera de páginas heterogéneas con datos semiestructurados; es un tema en investigación (véase el artículo de Aldana, Montes y Yagüe). Esta reciente evolución presagia cambios futuros del máximo interés y una de las mejores maneras de seguir estos cambios es mediante los congresos especializados en bases de datos, tanto internacionales como españoles. 5.1 Congresos internacionales 4.2. Data Warehouse 5.2. Las próximas Jornadas de Bases de Datos de Cáceres Aunque los "almacenes de datos" (Data Warehouse o DW) son un desarrollo reciente, ya han demostrado que, implantados convenientemente, pueden ser de gran ayuda en la toma de decisiones y en el "proceso analítico en tiempo real" (On Line Analytical Processing u OLAP). Sus datos, extraídos periódicamente de los sistemas operacionales o de otras fuentes e integrados, son no volátiles, relevantes para la empresa, agregados según diversas granularidades en el tiempo y en otras dimensiones. En la gestión de los DW existe una gran competencia entre extensiones de los SGBDs por un lado y productos específicos por otro. La reciente adquisición de Red Brick por Informix es una muestra de los posicionamientos en este campo. En diversos países tienen congresos especializados; en el caso español las JIDBD (Jornadas de Investigación y Docencia en Bases de Datos) comenzaron en 1996 en A Coruña, y siguieron en el 97 en Getafe/Madrid, y en el 98 en Valencia. Este año se van a celebrar en Cáceres, del 24 al 26 de noviembre, desprovistas de la parte de docencia (que ya tiene sus jornadas específicas en las JENUI), y conjuntamente, por primera vez, con las Jornadas de Ingeniería del Software. Estas JISBD’99 prometen ser muy interesantes técnicamente, tanto por las comunicaciones seleccionadas por los comités de programa, como por la conferencia invitada de S. Cannan sobre The New SQL Standard: Good, Bad or simply Ugly?, aparte de los atractivos indudables de la ciudad de Cáceres. Se pueden consultar todas las informaciones en: http://webepcc.unex.es/jisbd99/ 4.3. Minería de datos Llamamos "minería de datos" a lo que es conocido en inglés por Knowledge Discovery in Databases/Data Mining o KDD. Se trata de descubrir conocimientos útiles y previamente no conocidos a partir de grandes volúmenes de datos, análogamente a como en minería se obtienen pequeñas cantidades de metal por beneficio de grandes cantidades de mena. Integra técnicas no sólo de bases de datos, sino también de la estadística y de la inteligencia artificial. Las investigaciones se han plasmado rápidamente en productos comerciales, con un desarrollo reciente espectacular; prueba de ello son la progresión de participantes en los congresos KDD, que en 1998 en Nueva York superaron ya a los de VLDB, y la creación por la ACM de un Special Interest Group específico, el SIGKDD. 4.4. Semántica Aumentar el nivel semántico de los datos y de su tratamiento es importante, como ponen de manifiesto los congresos sobre Data Semantics ([Saltor96]). Un mayor nivel semántico ayuda a solucionar problemas de muchos tipos, incluyendo la ingeniería de sistemas de información federados ([Saltor99]), la gestión de flujos de trabajo (Workflow), la gestión de transacciones y el control de concurrencia, la seguridad y confidencialidad, o la evolución de esquemas. 4.5. Otras técnicas Ha habido progresos recientes en bases de datos activas y de tiempo real, en bases de datos espaciales, temporales y espacio-temporales, en bases de datos con información La participación en congresos internacionales especializados ha sido más fácil cuando se han acercado a nosotros: VLDB’91 en Barcelona, DEXA’92 en Valencia, EDBT’98 en Valencia. Por otra parte hemos tenido los Workshops internacionales DAISD en la costa catalana y BIWIT en Euskal Herría. Próximas convocatorias son E-R’99 en París, ICDE’00 en San Diego, EDBT’00 en Konstanz, SIGMOD/ PODS’00 en Dallas, VLDB’00 en El Cairo. 6. Referencias [Cattell94] R.Cattell: Object Data Management (rev. ed.). Addison Wesley, 1994. [Cattell97] R. Cattell & D. Barry (eds): The Object Database Standard: ODMG 2.0. Morgan Kaufmann, 1997. [CORBA] http://www.omg.org/corba/ [deMiguel99] A. de Miguel & M. Piattini: Fundamentos y modelos de Bases de Datos (2ª ed.), Ra-ma, 1999. [ODMG] http://www.odmg.org/ [Saltor96] F. Saltor: Semántica de datos. En J. Cuena (ed): Panorama informático. FESI, Madrid, 1996. [Saltor99] F. Saltor & E. Rodríguez: "On Semantic Issues in Federated Information Systems". En Engineering Federated Information Systems. infix 1999. [Stonebraker98] M. Stonebraker (ed): Readings in Database Systems (3rd ed). Morgan Kaufmann, 1998. [UML] http://www.rational.com/uml/ [Yu98] C. Yu & W. Meng: Principles of Database Query Processing for Advanced Applications. Morgan Kaufmann, 1998. [Zaniolo97] C. Zaniolo, S. Ceri, C. Faloutsos, R. Snodgrass, V. Subrahmanian & R. Zicari: Advanced Database Systems. Morgan Kaufmann, 1997. Nota Se han reflejado investigaciones subvencionadas por el proyecto TIC960903. Agradecimiento Agradezco la invitación de Mario Piattini a participar en este número especial de Novática. NOVATICA jul./ago. 1999 nº140 7 8 MONOGRAFIA NOVATICA jul./ago. 1999 nº140 Bases de Datos Avanzadas César Pérez-Chirinos Sanz Director de Proyectos Europeos TransTOOLs, S.A. Bases de datos: ¿medios o fines? <[email protected] "Perfección en los medios y confusión en los fines es lo que caracterizan nuestro tiempo". Frase atribuida a Albert Einstein 1. A modo de presentación De cuando en cuando recibo invitaciones a participar en mesas redondas, a dar charlas o poner por escrito mis opiniones sobre tal o cual tema relacionado con las Tecnologías de la Información y las Comunicaciones (TIC). Por alguna razón, parece que mis opiniones son suficientemente heterodoxas como para colorear un debate, pero no lo suficientemente absurdas como para no servir de acicate para que auténticos especialistas exploren alternativas que no habían considerado. Tengo que admitir que cuando algún colega me comenta que alguna de mis chanzas le puso tras la pista de algo útil, siento una mezcla de bochorno (cuando no recuerdo haber dicho tal cosa) y satisfacción de haber compartido con provecho mis experiencias, lo que me parece una obligación moral para con quienes me han enseñado de igual forma a lo largo de casi veinticinco años de trabajo en este sector. Por ello, al tiempo que suelo aceptar los retos verbales, pues no suele quedar constancia de mis opiniones improvisadas y puedo olvidarme de lo dicho sin sentirme atado por ellas, soy muy reacio a convertir en persistentes mis estados mentales que, por su propia naturaleza, debo aceptar como transitorios. Una de las pocas veces en que he sido inconsistente con mi propia regla lo hice ante otra invitación de Novática con ocasión del monográfico sobre Tecnología de Objetos publicado en abril de 19951. Tras la amable invitación del editor de este número especial de Bases de Datos, el Dr. Mario Piattini , he revisado aquel artículo y observo que, a pesar del ánimo polémico con qué lo escribí y el tiempo transcurrido, ha envejecido dignamente2, lo que me anima a recoger el guante que me lanza Mario, con quien he tenido el placer de coincidir en varios congresos y sesiones de trabajo en los últimos seis años, incluyendo la reunión en Madrid del comité de normalización del SQL en 1997. Él cree que mis opiniones sobre el tema, viniendo del sector industrial, pueden complementar las mas fundadas en la teoría que se recogen en este número especial. He aquí, pues, las opiniones de un escéptico sobre evolución y el futuro de las bases de datos. Por supuesto, sólo representan mi propio punto de vista y relevo expresamente a Mario (y a TransTOOLs) de cualquier responsabilidad, respaldo o relación con lo expresado a continuación. 2. ¿Para qué servían las bases de datos? Mucha gente del sector parece haber olvidado (o no haber sabido nunca) que las bases de datos, tal como hoy las conocemos, nacieron y crecieron con el propósito de dar soporte a las aplicaciones de negocio (todo lo más, de gestión administrativa) de las grandes organizaciones. Soy suficientemente veterano para haber perforado tarjetas personalmente y recordar la época en que los destinatarios de las bases de datos eran, principalmente, auxiliares administrativos avispados que habían recibido por toda formación informática los famosos cursos de "enseñanza programada" de IBM y que, con gran esfuerzo, habían hecho carrera en sus organizaciones acumulando a sus espaldas miles de líneas de código en RPG o COBOL en aplicaciones de proceso secuencial. Las entonces nacientes aplicaciones de "teleproceso"3, con sus ingentes inversiones asociadas, necesitaban una herramienta que pudiera ser utilizada por personal poco cualificado, cuya dificultad para entender las implicaciones del proceso interactivo y transacional resultaba un factor limitativo de la extensión del teleproceso. Esta herramienta adoptó el imponente nombre comercial de Sistema de Gestión de Bases de Datos y, posteriormente, encontró su aliado natural en los pomposamente denominados Lenguajes de cuarta generación, herederos de las herramientas de generación de informes tan queridas en los grandes centros de consumo de cajas de papel perforado, también conocidos como CPD. La alianza SGBD/4GL se tradujo en un aumento espectacular de la productividad de la programación de aplicaciones de negocio. En pocos años se acumuló una auténtica montaña de aplicaciones basada, en el mejor de los casos, en el culto a los métodos estructurados y al modelo relacional, que prometían el paraíso de la evolución sin restricciones, gracias a la independencia del modelo lógico del modelo físico. Todo el mundo, y su perro, quería una "base de datos" para su negocio y el mundo académico gozaba con las sutilezas y paradojas de la teoría avanzada de las formas normales. Por supuesto, ante esta demanda, los productos comercializados bajo la etiqueta SGBD crecieron en sofisticación y funcionalidad, asumiendo incluso funciones del sistema operativo, tales como gestionar el acceso físico a las unidades de almacenamiento persistente, e imponiendo herramientas y/o lenguajes de programación específicos, como extensión al SQL (modesta y prudentemente identificado como lenguaje de consulta). Los proveedores vivieron años NOVATICA jul./ago. 1999 nº140 de esplendor. Lenta, insidiosa, pero inexorablemente, los SGBD pasaron de ser un medio a un fin en sí mismo. 3. La nueva herramienta del emperador La montaña funcional, levantada a ritmo y con la ambición de una moderna Torre de Babel, pretendía alcanzar el cielo representado por El Modelo de Datos Inmutable de La Organización, universalmente válido, y del cual sólo sería necesario proporcionar unas vistas (tabulares, por supuesto) a los programadores, para que pudieran seguir pensando en la realidad como una colección de ficheros planos, manejables "como se había hecho siempre". Poco a poco, la montaña se ha convertido en un volcán, al que se arrojan en sacrificio ingentes cantidades de irrecuperable tiempo humano dedicado al mantenimiento, cada vez mas inviable, de aplicaciones basadas en modelos cuya anhelada inmutabilidad en el pasado se convierte en un pesado lastre para la rápida adaptación de las organizaciones, poniendo en riesgo su supervivencia. No me considero quién para dar lecciones a nadie, pero si puedo dormir tranquilo diciendo "ya me lo temía yo, y conste que compartí mis sospechas en su momento". Como el niño del cuento El traje nuevo del Emperador, era mi desconocimiento4 de lo que se suponía que debía ver en las bases de datos lo que me permitía entrever los problemas mal resueltos con toda su crudeza. 4. Síntomas que deberíamos haber atendido Omitiré los detalles para preservar la identidad de los afectados, pero la historia es rigurosamente cierta. Un buen amigo mío salvó in extremis un megaproyecto desarrollado por una de las grandes consultoras para la gestión integral de una eléctrica española. Llegado el momento de su puesta en explotación, con la base de datos cargada por primera vez con volúmenes de información realista, la transacción más importante y utilizada del sistema se empeñaba en demorar varios minutos su respuesta. Armado de sentido común, una herramienta de monitorización de rendimiento bastante simple y su profundo conocimiento de cómo estaba implementado el 4GL utilizado, mi amigo redujo el tiempo de respuesta a menos de cinco segundos, lo que permitió su puesta en explotación, sencillamente cambiando dos instrucciones del programa por otras dos muy parecidas. Deberíamos haber aprendido que nada bueno puede construirse sobre la ignorancia de los propios constructores sobre sus materiales y herramientas. En particular, los becarios sólo deberían ser autorizados a programar después de haber estudiado y revisado grandes cantidades de código de primera calidad5. Otro factor que debió haber despertado sospechas fue la figura del Administrador de La Base de Datos, predestinado a convertirse en el cuello de botella de toda instalación, en caso de ser competente, o en mero portavoz de su proveedor favorito, en caso de no serlo tanto. La pretensión de reunir en una sola persona los conocimientos técnicos y funcionales necesarios para asumir este cargo, tal como se definía hace un lustro, fue una ingenuidad y un exceso de optimismo del mismo tipo que la fe en la planificación económica en la extinta Unión Soviética. 9 Las bases de datos, como anteriormente la memoria virtual, en lugar de ser herramientas opcionales a aplicar con criterios profesionales, han ayudado a crear promociones de supuestos informáticos que no son conscientes de las limitaciones reales impuestas por los equipos físicos, o por el diseño, muchas veces desafortunado, de las capas de software que se interponen entre la máquina y el desarrollador para crear una máquina, ficticia por lo ilimitada, al alcance de su inadecuada formación6. 5. El comercio electrónico y el ocaso de las bases de datos clásicas Creo que los SGBD y sus aliados los 4GL hubieran tardado mucho tiempo en quedar con sus limitaciones al aire de no ser por el crecimiento explosivo del comercio electrónico. En contra de lo que se cree comúnmente, Internet se está usando más, en términos de volúmenes de facturación, para el comercio entre empresas que para venta a particulares. Este fenómeno, junto con otros más paradójicos de la economía virtual, es uno de los motivos por los que los directivos de las empresas creen que no podrán sobrevivir al margen de la Internet7. Bajo esta presión, todos urgen para poner en servicio nuevas aplicaciones, apropiadas para un mundo en que la competitividad sólo se consigue mediante redes de colaboración. Esto obliga a que, siendo desconocidos a priori los potenciales aliados, la adaptabilidad inmediata de las aplicaciones es el objetivo mas preciado. Dado que las posibilidades de negocio en este contexto duran pocas semanas, el plazo de adaptación se mide en pocos días. Y, de pronto, las insuficiencias del Modelo de Datos de La Organización se han vuelto patentes para todos8 y, muy en especial, para los directivos que habían estado dando por válido el razonamiento de que la base de datos corporativa era la clave de la empresa, y aceptando por ello todo tipo de menosprecio hacia las aplicaciones construidas con hojas de cálculo, al margen del modelo oficial, pero que son la clave de su productividad individual, y que aparentemente son más adaptables. Algunos de estos directivos, con hijos quinceañeros habituados al PC como compañero de juegos y capaces de conversar en línea sobre música pop y trucos informáticos con tecnólogos experimentados con los que comparten intereses lúdicos, comprueban asombrados como en un fin de semana "su chico/a" le monta un prototipo de la Web de su empresa, en el espacio que le cede su proveedor de acceso. La sospecha de que sus informáticos son unos aficionados con sueldos y presupuestos desmedidos es inevitable. Lo que ocurre en realidad es que pocos son los que no han sido pillados a contrapelo. En la búsqueda de un modelo de datos corporativo, blindado de toda influencia externa, han sido muchos los que no se han percatado que Internet está imponiendo a una velocidad sin precedentes la apertura y flexibilidad de las organizaciones, haciendo que el modelo de datos interno sea casi irrelevante. Sólo sirve la información que se puede compartir fácilmente, y siempre que sirva para construir procesos de creación de valor añadido de ahora en adelante. La información histórica ya no permite predecir un futuro basado en competir contra la inercia de los competidores y dar a los usuarios el derecho a cambiar 10 de hábitos (y de proveedores, por supuesto) cuando les parezca oportuno, y en el que la publicidad se contempla más como una forma de mecenazgo de artistas gráficos que como algo que uno se toma en serio a la hora de elegir. Por supuesto, siempre se puede argumentar que Internet es "sólo" una gigantesca colección de bases de datos multimedia federadas. Pero esta definición no es ningún consuelo si la respuesta a "¿cuándo podremos empezar a vender en Internet?" es "el año que viene" o, peor, "en cuanto terminemos el metamodelo de presentación de datos del grupo de empresas". NOVATICA jul./ago. 1999 nº140 de forma ciega y pesimista, como exige la hipótesis de diseño actual según la cual el programador está poco (o nada) cualificado14. El resultado es un reparto mas honrado de responsabilidades que permite mejorar el rendimiento de los SGBD, a costa de exigir más cuidado en la programación. A pesar de haber propuesto hace ya seis años este enfoque como la forma más sensata de implementar la norma de bases de objetos ODMG9315, me temo que, como en la leyenda de Pandora, al "abrir la caja", y dada la forma en que se utiliza actualmente el SQL, salgan todos los males de ella. Menos mal que detrás de todos ellos también salía la esperanza. 6. Un ejemplo verídico Durante la redacción de este artículo he tenido una experiencia que ilustra perfectamente mi escepticismo sobre la viabilidad de desplegar con coherencia la información almacenada en grandes bases de datos9 en Internet. Necesitaba encontrar un número de teléfono. Sorprendentemente, mi acceso a Internet a través de Infovía Plus estaba operativo, de forma que consulté http://www.paginas-amarillas.es. Allí estaba el número. Tras un buen rato sin que descolgaran el teléfono10, me animo a llamar al 1003. Una amabilísima operadora me explica que ese número corresponde a un fax, y me da los otros dos teléfonos "que figuran en la base de datos". Marco el primero de ellos y, ¡sorpresa!, escucho un mensaje sintético que me informa que el número ha cambiado y, finalmente, consigo hacerme con el número deseado. Es evidente que ni siquiera los grupos económicamente poderosos parecen capaces de mantener la integridad de sus datos (el mito que justificó la actual arquitectura de los SGBD), ni siquiera aunque su negocio consista básicamente en la construcción y gestión de un sistema informático complejo como en este caso. Pero, como Tom DeMarco y Timothy Lister comentan en su libro Peopleware11, parece que la gente ya ha dado por buenos este tipo de fallos y, simplemente, no existe aliciente económico real para mejorar la calidad de los servicios telemáticos. Menos aún cabría, por tanto, esperar respecto a la de las herramientas empleadas: gracias a los PCs, todo el mundo cree saber que los ordenadores fallan con frecuencia12. Lo único que importa es el time to market. Los fabricantes, aparentemente convencidos de que la venta de herramientas tiene un futuro dudoso, ya sólo buscan aumentar su facturación implicándose en proyectos13. 7. "Abriendo la caja" (¿de Pandora?) Entretanto, las tendencias tecnológicas parecen decantarse por las "bases de datos a la carta". En la sesión de clausura de la conferencia EDBT’98 se presentó una propuesta atractiva para hacer frente al rígido monolitismo de los SGBD actuales, bajo el lema opening the box. La idea es descomponer la funcionalidad actualmente proporcionada por estos productos en una serie de servicios opcionales que pueden ser solicitados por los programadores de forma expresa basándose en las necesidades específicas de las aplicaciones. De esta forma, la persistencia, búsqueda, atomicidad, trazabilidad de los cambios, auditoría, seguridad, etc. se convierten en servicios que no se proporcionan 8. Servidores de aplicaciones: el destino evolutivo de los SGBD Sigo sosteniendo, como en mi artículo anterior, que la complejidad creciente de los sistemas de información sólo es abordable si, desde el comienzo, se construyen mediante objetos, entendidos estos como unidades de mantenimiento y, por tanto, de descomposición y composición de los propios sistemas. Afortunadamente, hay síntomas esperanzadores de que el falso debate sobre si las bases de datos deben ser orientadas a objetos, relacionales extendidas u otras opciones más exóticas, incluyendo las activas y las temporales, va a terminar de una forma pacífica. Las bases de datos del futuro serán...irrelevantes. En este escenario, puede que incluso el SQL Server de Microsoft se convierta en el servidor de SQL del futuro... suponiendo que lo regalen como el Explorer. ¿Cómo que irrelevantes? -se preguntará usted, un tanto molesto, si ha tenido la amabilidad de leer hasta aquí. Pues sí. Sólo las aplicaciones son importantes para quien paga por ellas y sólo en la medida en que le sirvan para los objetivos de su organización, o se lo imponga la legislación vigente (imposición de la que viven realmente casi todos los fabricantes de ERP y paquetería similar). Lo demás son medios auxiliares sin interés estratégico y han de adaptarse a la tecnología disponible. Aunque son muy hermosos, ya no se hacen puentes de piedra. Aunque este monográfico lo sea sobre bases de datos, me han pedido una opinión sincera y ya la he escrito. Si duda de ello, reflexione sobre el desparpajo con que Oracle, tras imponer el PL/SQL a todos sus competidores en el SQL/PSM, se desentiende de él anunciándose como "la compañía 300% Java" (100% en cliente, middleware y servidor). Por supuesto, en el futuro, usted comprará Oracle 8i, o el Component Broker de IBM, o el WebLogic de BEA, en la partida presupuestaria "SGBD" o, quizá si los comerciales han entendido lo que le están vendiendo, en el de "Monitor de teleproceso". Puede que termine incluso oculto en la partida "Sistema Operativo" si opta por el MTS de Microsoft y se lo regalan con el NT, en un intento de diferenciarlo de Linux+GNOME o cosas así. En cualquier caso, si de verdad le interesan los fines y no los medios, lea la especificación de los componentes Java para el servidor, los Enterprise Java Beans y creo que entenderá (y compartirá) mi afirmación. En tal caso, solicite a Novática NOVATICA jul./ago. 1999 nº140 un monográfico sobre servidores de aplicaciones, y me comprometo, no sólo a explicar qué son y por qué no son bases de datos; también me comprometo a que un equipo que lleva trabajando desde enero de 1997 con componentes Java (quince días después de hacerse pública la especificación) le explique con todo detalle los diferentes disfraces que puede adoptar un servidor de aplicaciones, incluyendo el de SGBD. Parafraseando la célebre frase de Fermat, "lo siento, pero la demostración no cabe en este número". 9. Conclusiones (provisionales) Mis conclusiones son siempre provisionales: aunque me faltan aún más de veinte años antes de que la sociedad considere que he visto suficientes horrores profesionales para concederme la jubilación, soy suficientemente veterano como para haber tenido que usar cinta de papel perforada como almacenamiento intermedio. Así que hace ya tiempo que he dejado de asombrarme sobre la versatilidad de las TIC para ser empaquetadas para la venta, sin que realmente requieran mas innovación real que la que se produce en la mente de sus compradores. Esta versatilidad permite su continua reencarnación comercial bajo los más insospechados disfraces, de forma que no seré yo (al menos por ahora, y por mucho que me tiente hacerlo) quien ponga la fecha de caducidad a las bases de datos. En cualquier caso, y para honrar la sinceridad que se me pedía al solicitarme estas líneas, creo que, además de convertirse en irrelevantes: - Los SGBD tal como se conciben hoy seguirán enseñándose en el mundo académico mucho después de haber perdido interés práctico. No creo que esto sea especialmente nocivo, siempre que se haga en una asignatura de Historia de las TIC, o enfocado al difícil reciclaje de las aplicaciones de gestión actuales16. - En cualquier horizonte temporal previsible, siempre habrá algo que se comercialice bajo la etiqueta SGBD. Pero cualquier parecido con lo que hoy llamamos así será como el que existe entre los organismos unicelulares y los pluricelulares. No creo que una caja conteniendo implementaciones de servicios opcionales de proceso de transacciones, identificación por nombre/directorio, gestión de memoria y ciclo de vida de objetos de negocio, multitarea/multihilo, reparto dinámico de carga, búsqueda, seguridad y persistencia, destinados a la construcción por agregación de componentes, y su despliegue en entornos heterogéneos y distribuidos, de aplicaciones personalizables en extremo sea exactamente lo que se incluya en el programa de la asignatura en un futuro cercano17. Pero afirmo que tendrán el 50%, al menos, de cuota de mercado para cuando los alumnos que comienzan la carrera ahora la terminen. - Las tablas, como elemento de presentación visual de información, sobrevivirán al modelo relacional. Por supuesto, no puedo demostrar mis creencias. Pero la sonrisa cómplice con la que auténticos especialistas suelen recibir mis comentarios irónicos cuando compartimos unas cervezas tras alguna soporífera sesión pseudoespecializada en los congresos de rigor, me hacen pensar que: a) son más compartidas de lo que públicamente se admite o b) aún podría hacer carrera como cómico. Bien mirado, quizá el 31 de diciembre de este año, y el 29 de 11 febrero del próximo, los informáticos quedemos marcados por una larga temporada (después del ruido armado, ya tanto da si pasa algo como si no) como "esos bromistas incorregibles". En tal caso, ¡ambas opciones me pondrían en la peligrosa situación del pionero!... Notas 1 "Objetos contra complejidad", Novática, abril 1995. Todo lo más, resulta ingenuo: causa cierto asombro, y algo de pena, que hace tan solo cuatro años hubiera que defender la Tecnología de Objetos de cierto escepticismo académico. Claro que, entonces, Java no existía aún mas que como una útil herramienta del proyecto Oak, el precedente de JINI, escondido en los laboratorios de Sun. 3 Esta palabra no está en el diccionario de Word; sí lo está en cambio componentware. Curioso. 4 Probablemente, agnosticismo sería aquí una palabra más exacta. 5 En palabras de Alan Davis, "un mal ingeniero de software armado con una herramienta de programación de alta productividad se convierte en un ingeniero de software peligroso". 6 No será, en mi humilde opinión, un colegio profesional suficiente defensa para proteger a quienes, hasta ahora, no son capaces de explicar a la sociedad la diferencia entre el software profesional, el de consumo y el de código fuente abierto. Una pista: ¿hay mas densidad de defectos en las aplicaciones de un banco o en un videojuego de gama alta? Otra: ¿alguna compañía de seguros se atrevería a suscribir una póliza de responsabilidad civil para ese colegio, caso de existir, antes del 2 de marzo del año que viene? 7 Dado el carácter básicamente religioso y psicológico de las creencias económicas, ya expuesto por el filósofo Walter Benjamin hace más de 50 años, será difícil que esta profecía no se autocumpla. 8 Conste que el Dr. Codd ya había tenido el coraje (o la prudencia) de señalar las limitaciones del modelo relacional para su explotación práctica en las empresas, en relación con el OLAP. 9 Para los optimistas al respecto, les remito a la más autorizada opinión de Ken Orr, recientemente publicada en estas mismas páginas en el magnífico artículo "La calidad de los datos y la teoría de sistemas" (Novática, 136, NovDic., 1998). 10 Era fiesta en Barcelona, pero no lo sabía... este es otro interesante motivo de reflexión: ¿cuál es la complejidad mínima del modelo de información de un modesto calendario, apto para la época de la globalización de los negocios y el localismo multicultural? 11 Peopleware (Productive Projects and Teams), 2nd., Ed. Dorset House Publishing Co., ISBN 0-932633-43-9. Un libro que merece la pena leer, aunque sólo sea por la discusión que contiene sobre los motivos que pudieran justificar la observación experimental de que el único factor de correlación significativo entre la productividad y calidad de la producción de dos programadores es...¡la empresa para la que trabajan! ¿Dios los cría y ellos se juntan? ¿Las empresas reprograman a sus programadores? ¿No importa qué o donde estudiaron? 12 Tengo que admitir que, desde un punto de vista democrático, prefiero esta creencia errónea a la fe borreguil precedente según la cual el ordenador, igual que algunos políticos, tenía el monopolio de la certeza. 13 Algún importante proveedor de herramientas, con tal de que se le permita participar en proyectos TIC, está dispuesto a ir incluso de socio... ¡financiero! 14 Esta afirmación es políticamente incorrecta, pero es lo que implica asumir que, entre un BEGIN y un COMMIT, el cliente puede hacer cualquier cosa con los datos cuya protección encomendamos al SGBD. 15 No es que sea muy listo; es que esta arquitectura está calcada de la Object Management Architecture del Object Management Group (OMG). Además, yo pensaba en programadores de C++ avanzados al hacer esta propuesta. 16 Aunque reconozco que mucho más fácil que el de las aplicaciones en que el código de las reglas de negocio queda desperdigado por los elementos de la interfaz de usuario. Ya he sido bastante cruel con la compañía de Bill Gates como para poner aquí el nombre de la herramienta que usted y yo sabemos. 17 Al menos, mientras sigan dando clase personas que, cuando uno dice que se dedica al software distribuido, preguntan con curiosidad "¿Y qué compañía distribuye usted?". Auténtico. 2 Agradecimientos Quiero expresar mi gratitud a Mario Piattini por haberme dado la oportunidad de compartir mis dudas y opiniones con los lectores de este número especial de Novática, asumiendo el riesgo de que pudieran herir algunas susceptibilidades. 12 MONOGRAFIA NOVATICA jul./ago. 1999 nº140 Bases de Datos Avanzadas Andrew Eisenberg, Jim Melton Traducción: Esperanza Marcos y Mario Piattini SQL:1999, hasta ahora conocido como SQL3 © Andrew Eisenberg, Jim Melton En SIGMOD Record, Vol. 28, No. 1, Marzo 1999, pp. 131-138 1. Antecedentes Durante los últimos años hemos oído hablar y hemos leído acerca de un estándar emergente conocido por todos como SQL3, propuesto como una mejora importante del actual estándar para la segunda generación de SQL, denominada habitualmente SQL-92 debido al año de su publicación. La publicación del SQL3 estaba planificada, en un primer momento, para 1996... pero las cosas no se desarrollaron como estaba previsto. Como sabemos, el SQL3 se ha descrito como "SQL orientado a objetos" y constituye el fundamento de varios sistemas de gestión de bases de datos objetorelacionales (incluyendo, entre otros, ORACLE8 de Oracle, Universal Server de Informix, DB2 Universal Database de IBM y Cloudscape de Cloudscape). En general, esto se ha considerado como una "buena cosa", pero también ha tenido un gran inconveniente: se ha tardado casi 7 años en desarrollar el estándar en lugar de los 3 ó 4 planificados. Como veremos, el SQL:1999 es mucho más que una extensión del SQL-92 con tecnología de objetos. Incluye características adicionales que consideramos parte del legado del SQL relacional, así como una reestructuración total de los propios documentos de los estándares con vistas hacia una progresión más eficiente de los estándares en el futuro. 2. El Proceso de Desarrollo de los Estándares Las dos organizaciones 'de iure' activamente involucradas en la estandarización del SQL, y por tanto en el desarrollo del SQL:1999, son ANSI e ISO. Más concretamente, la comunidad internacional trabaja a través del ISO/IEC JTC1 (Join Technical Committee 1), un comité formado conjuntamente por la International Organization for Standarization y la International Electrotechnical Commission. El JTC1 es el responsable del desarrollo y mantenimiento de los estándares relacionados con la Tecnología de la Información (TI). Dentro del JTC1 se ha constituido el subcomité SC32, llamado Data Management and Interchange (Gestión e Intercambio de Datos) con el fin de abordar la estandarización relacionada con bases de datos y metadatos que ha sido llevada a cabo por otras organizaciones (como el recientemente disuelto SC21). El SC32, a su vez, está compuesto por varios Grupos de Trabajo (Working Groups) que se ocupan realmente del trabajo técnico -el WG3 (Database Languages) es responsable del estándar SQL, mientras que el WG4 está realizando el SQL/MM (SQL Multimedia, una colección de estándares que especifican bibliotecas de tipos utilizando las facilidades de orientación a objetos del SQL3). El Accredited Standards Development Committee (NCITS: National Committee for Information Technology Standarization, antiguamente conocido de forma más breve como X3) del American National Standards Institute es el encargado de gestionar en EE.UU. los estándares de TI. El NCITS Technical Committee H2 (antiguamente X3H2) es el responsable de varios estándares relacionados con la gestión de datos, incluyendo el SQL y el SQL/MM. Cuando se desarrolló la primera generación del SQL (SQL86 y su pequeña mejora SQL-89), mucho -quizá la mayor parte- del trabajo fue llevado a cabo en los EE.UU. por el X3H2, mientras que otros países participaron revisando y criticando el trabajo propuesto por ANSI. Cuando se publicó el SQL-89 la comunidad internacional ya era mucho más activa y escribía propuestas para lo que se convirtió en el SQL-92; este hecho no ha cambiado mientras que se desarrollaba el SQL:1999, ni creemos que sea probable que cambie en el futuro -ya que el SQL es verdaderamente un esfuerzo de colaboración internacional. Es conveniente explicar los nombres informales que estamos usando para las diferentes ediciones del estándar SQL. Las primeras versiones del estándar se conocen generalmente como SQL-86 (o SQL-87, ya que la versión ISO no fue publicada hasta principios de 1987), SQL-89, y SQL92, mientras que la versión que se acaba de finalizar debería llegar a ser conocida como SQL:1999. ¿Por qué esta diferencia?... ¿Por qué no "SQL-99"? Bien, simplemente porque hemos empezado a pensar cómo debería denominarse la siguiente generación, y "SQL-02" es muy probable que se confunda con "SQL2" (que fue el nombre del proyecto con el que se desarrollo el SQL-92)... sin mencionar el hecho de que "02" no es realmente mayor que "99". En otras palabras, ¡no queremos que ni siquiera el "nombre" del estándar SQL sufra el problema del año 2000! 3. El Contenido del SQL:1999 Después de estos antecedentes es el momento de dar una panorámica sobre el contenido actual del SQL:1999. A pesar de que la mayor parte de los lectores de este artículo podrían no conocer de manera precisa el contenido del SQL-92, las limitaciones de espacio nos impiden presentar todas las características del SQL:1999. Por tanto, restringiremos esta visión general a las nuevas características de esta nueva generación del estándar SQL. Las características del SQL:1999 pueden ser grosso modo divididas en "características relacionales" y "características orientadas a objetos", que serán tratadas en este orden. NOVATICA jul./ago. 1999 nº140 13 3.1. Características Relacionales Aunque denominemos a esta categoría de características "relacionales", se puede apreciar fácilmente que sería más apropiado denominarla "características relacionadas con el modelo de datos y el papel tradicional del SQL"... una frase un poco menos concisa. Las características de esta categoría no se limitan estrictamente al modelo relacional, sino que también incluyen aquellas no relacionadas con la orientación a objetos. Estas características se dividen, normalmente, en cinco grupos: nuevos tipos de datos, nuevos predicados, nueva semántica, seguridad adicional y base de datos activas. 3.1.1. Nuevos Tipos de Datos El SQL:1999 tiene cuatro nuevos tipos de datos (aunque alguno de ellos tiene diversas variantes). El primero de estos tipo es el tipo LARGE OBJECT (LOB), con sus variantes: CHARACTER LARGE OBJECT (CLOB) y BINARY LARGE OBJECT (BLOB). Los CLOB se comportan de forma muy parecida a las tiras de caracteres, pero no se admite su uso ni en claves primarias (PRIMARY KEY), ni en predicados de unicidad (UNIQUE), ni en claves ajenas (FOREIGN KEY), ni en comparaciones salvo en las comprobaciones de igualdad y desigualdad. Los BLOB tienen restricciones similares. Por tanto, los LOB no se pueden utilizar tampoco en cláusulas GROUP BY u ORDER BY. Normalmente, las aplicaciones no transferirán valores LOB completos desde y hacia la base de datos (después del almacenamiento inicial), sino que manipularán los valores LOB utilizando un tipo especial en el cliente denominado localizador de LOB (LOB locator). En el SQL:1999, un localizador es un valor binario único que actúa como una especie de subrogado para un valor que está en la base de datos; los localizadores se pueden utilizar en operaciones (tales como SUBSTRING) evitando la sobrecarga de transferir todo el valor LOB a través de la interfaz cliente/ servidor. mente permite almacenar información que puede ser descompuesta, así como la función SUBSTRING puede descomponer tiras de caracteres- y por tanto no se violaría realmente el espíritu de la primera forma normal. El tipo ROW en el SQL:1999 es una extensión del tipo row (anónimo) que el SQL siempre ha tenido y necesitaba tener, lo que proporciona a los diseñadores de bases de datos el poder adicional de almacenar valores estructurados en una única columna de la base de datos: CREATE TABLE empleado ( ID_EMP INTEGER, NOMBRE ROW ( N_DE_PILA VARCHAR(30), APELLIDO VARCHAR(30) ), DIRECCION ROW ( CALLE VARCHAR(50), CIUDAD VARCHAR(30), PROVINCIA CHAR(2) ), SALARIO REAL ) SELECT E.NOMBRE.APELLIDO FROM empleado E Aunque podría argumentarse que se viola la primera forma normal, la mayoría de los observadores lo consideran como otro tipo de datos "descomponible". El SQL:1999 añade además otra facilidad relacionada con los tipos de datos denominada "tipos distintos" (distinct types). Aún reconociendo que no es probable que una aplicación quisiera comparar directamente el número de zapatos que calza un empleado con su CI (coeficiente intelectual), el lenguaje permitiría a los programadores declarar NUMERO_ZAPATO y CI basados en un tipo INTEGER, pero prohibiría combinar directamente estos dos tipos en expresiones. Así, una expresión como: WHERE MI_NUMERO_ZAPATO > MI_CI Otro nuevo tipo de datos es el tipo BOOLEAN, que permite al SQL almacenar directamente los valores de verdad true (verdadero), false (falso) y unknown (desconocido). Se pueden expresar también combinaciones complejas de predicados de forma más amigables para el usuario de lo que se permite actualmente: WHERE COL1 > COL2 AND COL3 = COL4 OR UNIQUE(COL6) IS NOT FALSE El SQL:1999 tiene también dos nuevos tipos compuestos: ARRAY y ROW. El tipo ARRAY permite almacenar directamente colecciones de valores en una columna de una tabla de la base de datos. Por ejemplo: (donde el nombre de la variable implica su tipo de datos) se reconocería como un error de sintaxis. Cada uno de estos dos tipos puede ser "representado" como un INTEGER, pero el sistema SQL no permite combinarlos en expresiones – ni tampoco, por ejemplo, que sean multiplicados por un INTEGER: SET MI_CI = MI_CI * 2 En lugar de esto, los programas tienen que expresar explícitamente su intención de realizar estas combinaciones: WHERE MI_NUMERO_ZAPATO > CAST (MI_CI AS NUMERO_ZAPATO) SET MI_CI = MI_CI * CAST (2 AS CI) DIAS_SEMANA VARCHAR(10) ARRAY[7] permitiría almacenar directamente los nombres de los siete días de la semana en una única fila en la base de datos. ¿Significa esto que el SQL:1999 permite bases de datos que no satisfagan la primera forma normal? Ciertamente esto es posible, en el sentido de que permite "grupos repetitivos" prohibidos por la primera forma normal. Sin embargo, se ha argumentado que el tipo ARRAY del SQL:1999 simple- Además de estos tipos, el SQL:1999 también introduce tipos definidos por el usuario, que se encuentran en el conjunto de características orientadas a objetos. 3.1.2. Nuevos Predicados El SQL:1999 tiene tres nuevos predicados. Uno de ellos lo trataremos dentro de las características de orientación a NOVATICA jul./ago. 1999 nº140 14 objetos. Los otros dos son los predicados SIMILAR y DISTINCT. Desde la primera versión estándar del SQL, la búsqueda de tiras de caracteres ha estado limitada a comparaciones muy simples (como =, >, o <>) y a las capacidades, bastante rudimentarias, del patrón de comparación del predicado LIKE: WHERE NOMBRE LIKE ´ % PERE_´ sido su incapacidad para soportar recursión en aplicaciones, tales como el procesamiento de lista-de-materiales. Bien, el SQL:1999 ha proporcionado una facilidad denominada consulta recursiva (recursive query) para satisfacer justo este tipo de requisitos. Escribir una consulta recursiva comporta escribir la expresión de consulta que se quiere que sea recursiva y asignarle un nombre, que podrá ser usado en una expresión de consulta asociada: que casa con los valores de NOMBRE que tienen, cero o más caracteres antes de los cuatro caracteres 'PERE', y exactamente un carácter después de ellos (tales como PEREZ o RUPEREZ). WITH RECURSIVE Q1 AS SELECT...FROM...WHERE..., Q2 AS SELECT...FROM...WHERE... SELECT...FROM Q1, Q2 WHERE... Debido a que las aplicaciones requieren a menudo capacidades más sofisticadas, sin llegar a ser todavía operaciones de texto completo, el SQL:1999 ha introducido el predicado SIMILAR que proporciona a los programas expresiones regulares estilo UNIX para utilizarlas en el emparejamiento de patrones. Por ejemplo: Ya hemos hablado de los localizadores como valores del cliente que pueden representar un valor LOB almacenado en el servidor. Los localizadores se pueden utilizar de la misma manera para representar valores ARRAY, dado que (como los LOB) los ARRAY pueden ser a menudo demasiado largos para ser transferidos de forma adecuada entre una aplicación y la base de datos. Los localizadores se pueden utilizar también para representar valores de tipos definidos por el usuario -discutidos posteriormente- que también podrían ser grandes y difíciles de manejar. WHERE NOMBRE SIMILAR TO ´(SQL-(86| 89| 92| 99)) | (SQL (1| 2| 3))´ que casaría con los distintos nombres dados al estándar SQL a lo largo de los años. Es una lástima que la sintaxis de las expresiones regulares utilizadas en el predicado SIMILAR no correspondan exactamente con la sintaxis de las expresiones regulares de UNIX, debido a que algunos de los caracteres de UNIX se usaban ya en SQL con otros fines. El otro nuevo predicado, DISTINCT, es muy parecido al tradicional predicado UNIQUE del SQL; la diferencia importante es que dos valores nulos al considerarse distintos entre sí satisfacen el predicado UNIQUE, lo que, sin embargo, no es deseable en todas las aplicaciones. El predicado DISTINCT considera que dos valores nulos no son distintos (aunque no se consideran ni iguales ni no iguales entre ellos) y por tanto dos valores nulos no satisfarían el predicado DISTINCT. 3.1.3. Nueva Semántica del SQL:1999 Aunque es difícil delimitar con exactitud la presentación de la nueva semántica del SQL:1999, resaltaremos los nuevos aspectos de comportamiento del lenguaje que consideramos más importantes. Una de las tradicionales demandas de los creadores de aplicaciones es la capacidad de ampliar el número de tipos de vistas actualizables. Un gran número de entornos utilizan mucho las vistas como un mecanismo de seguridad y/o como un simplificador de las vistas de aplicaciones de la base de datos. Sin embargo, si la mayor parte de las vistas no son actualizables las aplicaciones se ven obligadas a "evitar" el mecanismo de vistas y depender directamente de la actualización de las tablas base subyacentes, solución nada satisfactoria. El SQL:1999 ha incrementado significativamente el rango de las vistas que se pueden actualizar directamente, utilizando únicamente las facilidades proporcionadas por el estándar. Las dependencias funcionales determinan qué vistas adicionales pueden ser actualizadas y cómo hacer los cambios de los datos de las tablas base subyacentes para efectuar dichas actualizaciones. Otra deficiencia muy criticada del SQL ha Finalmente, el SQL:1999 ha añadido el concepto de puntos de grabación (savepoints), muy implementados en productos. Un punto de grabación es algo parecido a una subtransacción, dado que una aplicación puede deshacer las acciones realizadas después del inicio de un punto de grabación sin deshacer todas las acciones de la transacción completa. El SQL:1999 permite ROLLBACK TO SAVEPOINT y RELEASE SAVEPOINT, que actúa de forma análoga a la grabación (commit) de una subtransacción. 3.1.4. Seguridad Mejorada La nueva facilidad de seguridad del SQL:1999 se basa en su capacidad de roles. Se pueden conceder privilegios a los roles, del mismo modo que a los identificadores de autorización individuales, y se pueden asignar roles a los identificadores de autorización y a otros roles. Esta estructura anidada puede simplificar en gran medida la tarea, a menudo difícil, de la gestión de la seguridad en un entorno de base de datos. Desde hace varios años, los productos SQL han implementado generalmente roles (aunque, en algunas ocasiones, bajo diferentes nombres); por fin, el estándar los ha recogido. 3.1.5. Bases de Datos Activas El SQL:1999 soporta el concepto de base de datos activa, aunque algunos años después de que lo hicieran las implementaciones. Esta facilidad es proporcionada por medio de una característica conocida como disparadores (triggers). Un disparador, como mucho lectores saben, es una facilidad que permite a los diseñadores instruir al sistema de base de datos para realizar ciertas operaciones todas y cada una de las veces que una aplicación realiza operaciones especificadas sobre determinadas tablas. Por ejemplo, se podrían usar disparadores para registrar todas las operaciones que modifican los salarios en una tabla empleados: NOVATICA jul./ago. 1999 nº140 CREATE TRIGGER reg_modsalario BEFORE UPDATE OF salary ON empleados REFERENCING OLD ROW as oldrow NEW ROW as newrow FOR EACH ROW INSERT INTO reg_tabla VALUES (CURRENT_USER, oldrow.salario, newrow.salario) Se pueden usar disparadores para otros muchos propósitos además de para registrar operaciones. Por ejemplo, se pueden escribir disparadores que mantengan un presupuesto equilibrado reduciendo las cantidades relativas a compras de capital, contratación de nuevos empleados... y lanzando una excepción si no hay dinero suficiente para hacerlo. 3.2. Orientación a Objetos Además de las características más tradicionales discutidas hasta el momento, el desarrollo del SQL:1999 se ha centrado en gran medida -algunos dirían que excesivamente- en añadir al lenguaje soporte para la orientación a objetos. Algunas de las características que se encuentran dentro de esta categoría fueron inicialmente definidas en el estándar SQL/PSM publicado en 1996 -concretamente, el soporte de funciones y procedimientos que pudieran ser invocados desde sentencias SQL. El SQL:1999 mejora esta capacidad, llamada rutinas invocadas por SQL, añadiendo una tercera clase de rutina conocida como método, que trataremos en el epígrafe 3.2.2. No profundizaremos en las funciones y procedimientos invocados por SQL en esta columna, sino que remitimos al lector a un número anterior de SIGMOD Record [6]. 3.2.1. Tipos estructurados definidos por el usuario La característica más importante del SQL:1999 para el soporte de la orientación a objetos son los tipos estructurados definidos por el usuario; la palabra "estructurado" distingue esta característica de los tipos distintos (que también son tipos "definidos por el usuario", pero que en SQL:1999 tienen que basarse en tipos predefinidos y que, por tanto, no tienen ninguna estructura asociada). Los tipos estructurados tienen una serie de características, las más importantes son: - Pueden tener uno o más atributos, de cualquier tipo SQL, incluyendo tipos predefinidos como INTEGER, tipos colección como ARRAY, u otros tipos estructurados (anidados tantas veces como se desee). - Todos los aspectos relativos a su comportamiento se proporcionan a través de métodos, funciones y procedimientos. - Sus atributos están encapsulados mediante funciones observadoras y mutadoras (funciones "get" y "set") generadas por el sistema, que proporcionan el único modo de acceso a sus valores. Sin embargo, estas funciones generadas por el sistema no pueden ser sobrecargadas; todas las demás funciones y métodos pueden ser sobrecargados. - Las comparaciones de sus valores se hacen sólo a través de las funciones definidas por el usuario. 15 - Pueden participar en jerarquías de tipos, en las cuales los tipos más especializados (subtipos) tienen todos los atributos de, y usan todas las rutinas asociadas con, los tipos más generales (supertipos), pudiendo añadir nuevos atributos y rutinas. Veamos un ejemplo de una definición de tipo estructurado: CREATE TYPE tipo_emp UNDER tipo_persona AS ( ID_EMP INTE GE R SALARIO REAL) INSTANTIABLE NOT FINAL REF (ID_EMP) INSTANCE METHOD AUMENTAR_SUELDO (ABS_O_PORC BOOLEAN CANTIDAD REAL) RETURNS REAL Este nuevo tipo es un subtipo de otro tipo estructurado que se puede usar para describir personas, incluyendo atributos comunes tales como el nombre y la dirección; los nuevos atributos de tipo_emp que "las personas mayores" no tienen, como un ID de empleado y un salario. Hemos declarado este tipo como instanciable y con posibilidad de tener subtipos definidos (NOT FINAL). Además, hemos dicho que cualquier referencia a este tipo (ver la discusión sobre tipos REF en el epígrafe 3.2.5) se deriva del valor del ID del empleado. Finalmente, hemos definido un método que puede ser aplicado a instancias de este tipo. SQL:1999, después de un largo coqueteo con la herencia múltiple (en la cual los subtipos pueden tener más de un supertipo directo), ahora proporciona un tipo de modelo cercano a la herencia simple de Java. Se pueden especificar tipos instanciables (en otras palabras, se pueden crear valores de este tipo especifico) o no instanciables (análogos a los tipos abstractos en otros lenguajes de programación). Y, naturalmente, en cualquier sitio -tal como una columnadonde se permite un valor de un tipo estructurado, puede aparecer un valor de uno de sus subtipos; esto proporciona exactamente el tipo de sustitutabilidad en el que se basan los lenguajes de programación orientados a objetos. Algunos lenguajes de programación orientados a objetos, tales como C++, permiten definir el grado de encapsulamiento de los tipos: un nivel de encapsulamiento PUBLIC (público) aplicado a un atributo significa que cualquier usuario del tipo puede acceder al atributo, PRIVATE (privado) significa que sólo el código utilizado para implementar los métodos del tipo puede acceder al atributo, y PROTECTED (protegido) significa que sólo los métodos del tipo y los métodos de cualquiera de sus subtipos pueden acceder al atributo. SQL:1999 no tiene este mecanismo, aunque hubo intentos de definirlos; anticipamos que se propondrá para una futura revisión del estándar. 3.2.2. Funciones vs Métodos SQL:1999 hace una importante distinción entre las "tradicionales" funciones invocadas por SQL y los métodos invocados por SQL. En resumen, un método es una función con varias restricciones y mejoras. NOVATICA jul./ago. 1999 nº140 16 Recapitulemos las diferencias entre los dos tipos de rutinas: - Los métodos están asociados a un solo tipo definido por el usuario; las funciones no. - El tipo definido por el usuario al cual está limitado un método es el tipo de datos de un argumento distinguido para el método (el primero, argumento no declarado); una función no tiene argumentos distinguidos en este sentido. - Las funciones pueden ser polimórficas (sobrecargadas), pero en tiempo de compilación se elige una función específica, examinando los tipos declarados de cada argumento en una invocación de función y escogiendo el "mejor emparejamiento" entre las funciones candidatas (que tienen el mismo nombre y el mismo número de argumentos). Los métodos también pueden ser polimórficos, pero el tipo más específico de sus argumentos distinguidos, determinado en tiempo de ejecución, permite diferir hasta la ejecución la selección del método concreto a invocar; todos los demás argumentos se resuelven en tiempo de compilación en base a los tipos declarados de los argumentos. - Los métodos deben ser almacenados en el mismo esquema en el cual se almacena la definición de sus tipos estructurados asociados; las funciones no están limitadas a un determinado esquema. - Ambos, funciones y métodos, pueden ser escritos en SQL (usando las sentencias computacionalmente completas del SQL/PSM) o en cualquiera de los diversos lenguajes de programación más tradicionales, incluyendo Java. 3.2.3. Notaciones Funcional y Punto El acceso a los atributos de los tipos definidos por el usuario puede hacerse usando cualquiera de las dos notaciones. En muchas situaciones, las aplicaciones pueden parecer más naturales si usan la "notación punto" (dot notation): WHERE emp.salario > 10000 mientras en otras situaciones, una notación funcional puede ser más natural: WHERE salario(emp) > 10000 El SQL:1999 soporta ambas notaciones; en realidad, están definidas como variaciones sintácticas -en el ejemplo, siempre que "emp" sea una entidad de almacenamiento (como una columna o variable) cuyo tipo declarado sea algún tipo estructurado con un atributo llamado "salario"... o exista una función llamada "salario" con un único argumento cuyo tipo de datos es el (apropiado) tipo estructurado emp. En este caso los métodos son un poco menos flexibles que las funciones: para la invocación a los métodos sólo se puede usar la notación punto -al menos con el propósito de especificar los argumentos distinguidos. Si salario es un método cuyo tipo asociado fuera, por ejemplo, empleado, que fuera, a su vez, el tipo declarado de una columna llamada emp, entonces el método sólo podría invocarse usando: emp.salario Un método diferente, por ejemplo aumentar_sueldo, puede combinar la notación punto y la notación funcional: emp.aumentar_sueldo (cantidad) 3.2.4. Por fin... Objetos Los lectores atentos habrán observado que hemos evitado utilizar la palabra "objeto" hasta el momento en la descripción de los tipos estructurados. Esto es debido a que, a pesar de ciertas características como la jerarquía de tipos, el encapsulamiento, etc., los ejemplares de los tipos estructurados del SQL:1999 son sencillamente valores, de la misma manera que los ejemplares de los tipos predefinidos del lenguaje. Por supuesto, un valor empleado es bastante más complejo (tanto en apariencia como en comportamiento) que un ejemplar de INTEGER, pero es todavía un valor sin ninguna otra identidad distinta de la que le proporciona su valor. Con el fin de lograr la última característica que permita a SQL proporcionar objetos, debe existir algún tipo de identidad que pueda ser referenciada en diversas situaciones. En el SQL:1999 dicha capacidad se proporciona permitiendo a los diseñadores de bases de datos especificar que ciertas tablas se definen como "tablas tipadas"..., es decir, sus definiciones de columnas se derivan de los atributos de un tipo estructurado: CREATE TABLE emps OF empleado Dichas tablas tienen un columna para cada atributo del tipo estructurado subyacente. ¡Las funciones, métodos y procedimientos definidos para operar sobre ejemplares del tipo lo hacen ahora sobre las filas de la tabla! Las filas de la tabla son, por tanto, valores (o ejemplares) del tipo. A cada fila se le asigna un identidad única que se comporta como un identificador de objeto (OID, object identifier)... es único en el espacio (es decir, en la base de datos) y en el tiempo (la vida de la base de datos). El SQL:1999 proporciona un tipo especial, denominado tipo REF, cuyos valores son esos identificadores únicos. Un tipo REF dado se encuentra siempre asociado a un determinado tipo estructurado. Por ejemplo, si fuéramos a definir una tabla que contenga una columna denominada "jefe" cuyos valores fueran referencias a filas de una tabla tipada de empleados, se haría algo parecido a esto: Jefe REF (tipo_empleado) Un valor de tipo REF identifica una fila de una tabla tipada (naturalmente, de un tipo estructurado) o nada, lo que significa que se trata de una "referencia colgada" como resultado de borrar la fila que identificaba. Todos los tipos REF tienen un ámbito de manera que la tabla que referencian se conoce en tiempo de compilación. Durante el desarrollo del SQL:1999 ha habido trabajos con el fin de permitir que los tipos REF fueran más generales que esto (por ejemplo, que cualquier tabla pudiera estar en el ámbito, o cualquier tabla de los tipos estructurados apropiados aunque la tabla fuera creada después del tipo REF); sin embargo, se encontraron varios problemas que no pudieron ser resueltos sin retraso adicional de la publicación del estándar, así que se adoptó esta restricción. Un efecto lateral de esta restricción, posiblemente beneficioso, es que los tipos REF ahora se comportan de forma mucho más parecida a la integridad referencial, facilitando posiblemente la tarea de implementación de esta facilidad en algunos productos. NOVATICA jul./ago. 1999 nº140 3.2.5. Utilización de los Tipos REF No debería sorprendernos el hecho de que los tipos REF se pueden usar de modos más sofisticados que simplemente almacenándolos y recuperándolos. El SQL:1999 proporciona una sintaxis para "seguir una referencia" que permite acceder a atributos de un valor de tipo estructurado: SELECT emp.jefe -> apellido La notación "puntero" (->) se aplica a un valor de algún tipo REF y se "sigue" dentro del valor identificado del tipo estructurado asociado -que, por supuesto, es realmente una fila de la tabla tipada del ámbito del tipo REF. Este tipo estructurado es a la vez, el tipo asociado con el tipo REF de la columna jefe en la tabla emps y el tipo de esta otra tabla (cuyo nombre ni es requerido ni aparece en esta expresión). Sin embargo, este tipo estructurado tiene que tener un atributo llamado apellido y la tabla tipada tiene una columna con este nombre. 4. Planificación y futuro El SQL:1999 no es todavía un estándar, aunque ya está en el buen camino para llegar a serlo. El año pasado se votó lo que se denomina FCD (Final Committee Draft) para cuatro partes de las especificaciones SQL (ver referencias [1], [2], [4] y [5]). En noviembre de 1998 se celebró la última reunión del Editing Meeting para estas partes. El editor (Jim Melton) ha aplicado los cambios a las especificaciones y están en estos momentos siendo revisados por los participantes del Editing Meeting. Cuando estas revisiones se hayan completado, estas cuatro especificaciones se someterán a una última votación (denominada votación del Final Draft International Standards, FDIS), cuyo resultado será "aprobar y publicar sin cambios" o "desaprobar y volver al estado FCD". Todos los participantes anticipan que el resultado será aprobar y publicar, lo que dará lugar a un estándar revisado aproximadamente a mediados 1999. Otra parte del SQL, SQL/CLI (ver referencia [3]), está también siendo revisada y acaba de someterse a una votación FCD. Se espera que se publique a finales de 1999 como una revisión del estándar CLI-95.Es difícil saber que nos deparará el futuro, pero tanto los grupos de ANSI como de ISO se han comprometidos a evitar el largo proceso del SQL:1999. Todos creemos que seis años es demasiado tiempo, especialmente en este mundo que trabaja cada vez más en "tiempo de web". Por el contrario, se están desarrollando planes que darán lugar a revisiones que se editen prácticamente cada tres años, incluso aunque las mejoras técnicas sean algo más modestas que las del SQL:1999. Además de hacer evolucionar las partes más importantes del estándar SQL:1999, se están desarrollando otras partes adicionales del SQL para abordar cuestiones como los datos temporales, la relación con Java (analizada en el número anterior del SIGMOD Record), y la gestión de datos externos junto con datos SQL. Reconocimientos Ha habido mucha gente involucrada en el desarrollo del SQL:1999 a lo largo de los años que ocupó su desarrollo. Aunque no tenemos espacio para mencionar a todos los que participaron en los comités durante su desarrollo, creemos adecuado mencionar por lo menos los nombres de las personas que 17 escribieron un número significativo de propuestas de cambios o que simplemente escribieron propuestas significativas: Minhea Andrei (Francia, Sybase), Jon Bauer (EEUU, Digital y Oracle), David Beech (EEUU, Oracle), Ames Carlson (EEUU, HP y Sybase), Stephen Cannan (Países Bajos, DCE Nederland y James Martin Consulting), Paul Cotton (Canadá, IBM), Hugh Darwen (Gran Bretaña, IBM), Linda deMichael (EEUU, IBM), Judy Dillman (EEUU, CA), Rüdiger Eisele (Alemania, Digital y consultor independiente), Andrew Eisenberg (EEUU, Digital, Oracle y Sybase), Chis Farrar (EEUU, Teradata y Compaq), Len Gallagher (EEUU, NIST), Luigi Giuri (Italia, Fondazione Ugo Bordoni), Keith Hare (EEUU, JCC), Bruce Horowitz (EEUU; Bellcore), Bill Kelly (EEUU, UniSQL), Bill Kent (EEUU, HP), Krishna Kulkarni (EEUU, Tandem, Informix e IBM), Nelson Mattos (EEUU, IBM), Jim Melton (EEUU, Digital y Sybase), Frank Pellow (Canadá, IBM y EEUU, Microsoft), Baba Piprani (Canadá, consultor independiente), Peter Pistor (Alemania, IBM), Mike Pizzo (EEUU, Microsoft), Jeff Richie (EEUU, Sybase e IBM), Phil Shaw (EEUU, IBM, Oracle y Sybase), Kohji Shibano (Japón, Tokyo International University y Tokyo University of Foreign Studies), Masashi Tsuchida (Japón, Hitachi), Mike Ubell (EEUU, Digital, Illustra e Informix), Murali Venkatrao (EEUU, Microsoft) y Fred Zemke (EEUU, Oracle). Todas estas personas contribuyeron de alguna manera significativa. Algunos de ellos diseñaron los principales aspectos de la arquitectura del SQL:1999, otros se centraron en tecnologías específicas como la interfaz de nivel de llamadas (SQL/CLI, Call level Interface), mientras que otros trabajaron sobre cuestiones muy específicas como la seguridad. Debemos felicitar a todos ellos, así como a otros colaboradores no mencionados aquí, por el gran trabajo bien realizado. Referencias [1] ISO/IEC 9075: 1999; Information technology-Database languages SQL-Part 1: Framework (SQL/Framework), a publicar en 1999. [2] ISO/IEC 9075: 1999; Information technology-Database languagesSQL-Part 2: Foundation (SQL/Foundation), a publicar en 1999. [3] ISO/IEC 9075: 1999; Information technology-Database languagesSQL-Part 3: Call-Level Interface (SQL/CLI), a publicar en 1999. [4] ISO/IEC 9075: 1999; Information technology-Database languagesSQL-Part 4: Persistent Stored Modules (SQL/PSM), a publicar en 1999. [5] ISO/IEC 9075: 1999; Information technology-Database languagesSQL-Part 5: Host Language Bindings /SQL/Bindings), a publicar en 1999. [6] New Standard for Stored procedures in SQL, Andrew Eisenberg, SIGMOD Record, Dic. 1996. Las especificaciones SQL se podrán adquirir en EEUU en: American National Standards Institute. Attn.: Customer Service. 11 West 42nd Street. New York, NY 10036. USA. Tel. + 1.212.642.4980. También se encontrarán disponibles a nivel internacional en cualquiera de los organismos oficiales de estandarización de cada país, o bien en la International Organization for Standarization. 1 rue de Varembé. Case postale 56. CH-1211 Ginebra 20, Suiza. Tel. + 41.22.749.0111. Referencias Web American National Standards Institute (ANSI), http://web.ansi,org International Organization for Standarization (ISO). http://www.iso.ch JTC1 SC32 - Data Management and Interchange. http://bwonote5. wdc.pnl.gov/SC32/JTC1SC32.nfs National Committee for Information Technology Standards (NCITS), http:/ /www.ncits.org www.ncits.org NCITS H2 - Database, http://www.ncits.org/tc_home/h2.htm Posdata Nos hemos puesto en contacto con Jim Melton que nos ha facilitado la siguiente información no incluida en el artículo original: a mediados de mayo empezó la votación del Final Draft International Standard (FDIS), que dura dos meses. Suponiendo que no haya votos negativos, y no se espera ninguno, a mediados de julio los estándares ISO/IEC 9075:1992 e ISO/IEC 90754:1996 serán reemplazados oficialmente por ISO/IEC 9075-1:1999, ISO/ IEC 9075-2:1999, ISO/IEC 9075-4:1999, e ISO/IEC 9075:1999. Además la votación del FDIS ballot para el SQL/CLI empezará dentro de muy poco tiempo, y cuando cierre dos meses más tarde, el estándar ISO/IEC 90753:1995 será reemplazado por el ISO/IEC 9075-3:1999. 18 MONOGRAFIA NOVATICA jul./ago. 1999 nº140 Bases de Datos Avanzadas J.F. Aldana Montes, M.I. Yagüe del Valle Consultas sobre la Web Dpto. Lenguajes y Ciencias de la Computación, Universidad de Málaga <{jfam, yague}@lcc.uma.es> Resumen: la Web es un sistema de información distribuido que proporciona acceso a grandes cantidades de información en Internet. Conforme aumenta el volumen de información depositado en la Web aumenta también la dificultad de recuperar información específica de interés para el usuario, debido sobre todo a la carencia de estructura y de contenido semántico en la información depositada en este medio. En este artículo presentamos una revisión de los distintos trabajos surgidos a raíz del problema de recuperación de la información presente en la Web. Además, exponemos cómo con la aparición del estándar XML (eXtensible Markup Language) se prevé la disponibilidad de grandes cantidades de datos XML sobre la Web en un futuro cercano. Concluimos con un resumen de las nuevas características que presenta éste frente a su antecesor, HTML, y los cambios que plantea en el desarrollo de un paradigma de consulta para la Web. En concreto, cómo las tendencias actuales para representar y consultar datos xml derivan de las bases de datos orientadas a objeto. Palabras Clave: Lenguajes de consulta, optimización de consultas, modelos de datos orientados a objeto, www, xml. 1. Introducción 1.1. Antecedentes El desarrollo de la Web, la aceptación de modelos de datos semánticamente más ricos (como los modelos orientados a objeto) y los logros obtenidos en el procesamiento de consultas con las técnicas de optimización de consulta relacionales ha motivado el desarrollo de una activa investigación sobre la consulta y actualización de datos con una fuerte estructura interna (p. ej., documentos electrónicos) pero que carecen de esquema. Un ejemplo lo encontramos en [1] donde se muestra cómo los ficheros de datos pueden ser consultados y actualizados mediante lenguajes de base de datos. Los primeros trabajos sobre cómo consultar la información presente en los documentos Web, como [2], contruyen una vista de base de datos de la información estructurada presente en dichos documentos, estableciendo una correspondencia entre documentos SGML (Standard Generalized Markup Language) y Bases de Datos Orientadas a Objeto (BDOO). Conforme aumenta el volumen de información depositado en la Web aumenta también la dificultad de recuperar información específica de interés para el usuario, debido sobre todo a la carencia de estructura en la información. Este problema es abordado hasta cierto punto por servidores de búsqueda o de índices (como Lycos, Alta Vista, Yahoo y otros) mediante motores de búsqueda o robots que exploran periódicamente la red construyendo índices basados en palabras clave. Este enfoque presenta deficiencias sustanciales, como pérdida de información estructural, limitación de la búsqueda al tipo de análisis realizado (aplicable exclusivamente al texto), y rapidez con que estos índices quedan obsoletos debido a la naturaleza dinámica de la Web. De igual manera, se pone de manifiesto el hecho de que los datos recogidos en la Web presentan diversos niveles de estructuración: sin estructura (imágenes, sonido, texto plano,...), con cierta estructura (hipertexto), o con una estructura completamente conocida (datos de sistemas de bases de datos). Además, el acceso a dichos datos se realiza mediante muy diversos interfaces, como navegadores Web, lenguajes de consulta de bases de datos, interfaces específicos de aplicación, formatos de intercambio de datos,... Aunque la integración de datos es un tema que ha sido bastante estudiado, la necesidad de integrar una variedad más amplia de formatos de datos y la difusión de la Web, motivan la investigación en este tema. El término datos semiestructurados es acuñado para describir aquellos datos que poseen cierta estructura pero para los que ésta es difícil de describir con un esquema rígido especificado explícitamente, debido a la irregularidad o a la rápida evolución de los datos, o a que la estructura está implícita y no es conocida por el usuario. En mayo de 1997, algunos investigadores en el área organizan el Workshop on Management of Semistructured Data. Surge así la idea del tratamiento de la Web como una base de datos con el fin de posibilitar consultas tanto sobre el contenido como sobre la propia estructura, además de introducir algún tipo de organización y facilitar el mantenimiento de la integridad. Se proponen distintos modelos formales de la Web, como [3] y [4], basados en una visión de ésta como una gran base de datos que es modelada como un conjunto de objetos semiestructurados, organizados como un grafo, con el fin de desarrollar nuevos lenguajes de consulta o bien adaptar lenguajes ya familiares como SQL o Datalog a este nuevo entorno distribuido. Estos modelos presentan como principales diferencias con relación a un sistema de base de datos la naturaleza navegacional del acceso y su carencia de control de la concurrencia. La repercusión de estas características de los datos Web es fundamental en problemas críticos como el de la optimización de consultas. NOVATICA jul./ago. 1999 nº140 En esta misma línea de trabajo y con el objetivo de restructurar la información de la Web, aparecen lenguajes de consulta sobre contenido y sobre la propia estructura del hipertexto. Distintos trabajos se enfocan a encontrar las propiedades estructurales de los datos semiestructurados. En [5] se muestra cómo extraer información sobre el esquema a partir de bases de datos OEM. Lore [6] es un completo sistema gestor de base de datos semiestructurados que utiliza resúmenes estructurales llamados dataguides [7]. Otro sistema orientado a datos semiestructurados es Strudel [8], sistema de gestión de nodos (sites) Web con el lenguaje de consulta StruQL y un modelo de datos similar a OEM. Todos estos modelos de datos, lenguajes y sistemas están enfocados a datos semiestructurados puros. La tendencia actual es que las organizaciones proporcionen acceso Web a sus sistemas de información y a sus bases de datos. Varios paquetes comerciales soportan ya la publicación en formato HTML (Hyper Text Markup Language) de datos procedentes de una base de datos. En este proceso se realiza una conversión de los objetos de la base de datos en páginas HTML que serán navegadas por los usuarios, de manera que estas páginas generadas reflejarán claramente las regularidades de la base de datos inicial. En la mayoría de los casos los usuarios sólo pueden acceder a los ficheros HTML, y no a la base de datos original. Con el fin de poder aplicar a las páginas Web técnicas de procesamiento de consultas similares a las usadas en un sistema gestor de base de datos (SGBD) un punto clave es identificar dentro del texto las piezas relevantes de información y extraerlas con el fin de construir una representación interna en algún modelo de datos que pueda ser manipulado por un lenguaje de consulta. Este proceso se conoce usualmente como wrapping y es un intento de decodificar los objetos de la base de datos original que ha sido codificada como ficheros HTML para su publicación. Las primeras aproximaciones para estructurar y extraer la información relevante de los nodos Web (wrapping) se basan esencialmente en técnicas manuales [9], de manera que un programador examina un nodo Web y codifica manualmente traductores (wrappers) que extraen las características lógicas de las páginas HTML y las almacenan en una base de datos local. En otros trabajos se estudia el problema de inferir automática o semiautomáticamente el esquema de una colección de páginas Web con cierta estructura. 1.2. El problema de la optimización de consultas La optimización de consultas sobre la Web difiere de la optimización sobre una base de datos debido a las dos características siguientes: 1. El modelo de costes: ya que los datos residen en nodos (sites) remotos, está basado en el número de accesos de red, en lugar de costes de CPU o I/O. Típicamente no se asigna ningún coste al procesamiento local, como por ejemplo a la operación de composición (join). 2. La carencia de control sobre el nodo: los nodos son autónomos y escapan del control del sistema de consulta; primero, no es posible influir en la organización de los 19 datos en el nodo; segundo, el administrador del nodo inserta, borra y modifica páginas sin que los usuarios remotos sean conscientes de esas actualizaciones. Estas características tienen implicaciones importantes en el procesamiento de consultas. Por ejemplo, impiden poder utilizar, con fines de optimización, estructuras de acceso auxiliares distintas a las construidas dentro de las páginas HTML. Así, para acelerar la evaluación de consultas se podría pensar en almacenar los URLS en algunas estructuras de datos locales y usarlas después en la evaluación de consultas. Sin embargo, esta solución no es factible debido a que una vez construidas las estructuras de datos éstas necesitan ser mantenidas. Como no conocemos las actualizaciones realizadas sobre las páginas dispersas por la Web, la única manera de mantener dichas estructuras es navegando durante la ejecución de la consulta para comprobar las actualizaciones, lo que en general tiene un coste comparable al coste de evaluar la consulta en sí misma. Entre los trabajos sobre optimización de consultas en la Web, destacamos [10], donde se toma el nº de páginas accedidas como una medida aproximada del coste de ejecución de la consulta y se presenta un optimizador de consultas que traduce una consulta declarativa a un plan de navegación eficiente. Utiliza un Algebra Navegacional (implementado en el lenguaje ulixes) como lenguaje para describir los planes de navegación, reglas de reescritura similares a las usadas en los optimizadores relacionales y tiene en cuenta las restricciones que permiten razonar sobre redundancias en un nodo (por ejemplo, múltiples caminos para acceder a los datos) para reducir el número de páginas accedidas para responder una consulta. 2. XML como sucesor de HTML 2.1. XML XML es un subconjunto de SGML, simplificado con el fin de ser utilizado en Internet y, fundamentalmente para el intercambio de datos, sin perder extensibilidad. Las etiquetas XML describen el contenido en vez de presentarlo (a diferencia de HTML). Además XML permite crear etiquetas propias así como los atributos de las mismas, con la única restricción de cumplir un conjunto de normas de sintaxis que garantizan la consistencia de los datos representados. Un documento XML es una secuencia de elementos, cada uno de los cuales consta de texto libre y/o otros elementos, con la única restricción de que para cada elemento marca (tag) de comienzo debe aparecer su correspondiente marca de cierre, y estos deben anidarse adecuadamente, construyendo un documento bien formado. Un DTD (Document Type Definition), concepto heredado de SGML, es una gramática para restringir las marcas y la estructura de un documento, especificando qué elementos pueden aparecer y cómo pueden anidarse en un documento XML que cumpla dicho DTD. Un documento que satisfaga la gramática de su DTD se dice que es válido. Los elementos de XML se pueden asimilar a objetos. En el ejemplo de la figura 1, el elemento <persona>...</persona> se correspondería con un objeto de la clase persona{...}. Los elementos XML anidados se corresponden a campos del objeto, por ejemplo, los elemen- 20 NOVATICA jul./ago. 1999 nº140 Figura 1 tos <Nombre>, <Apellido1> y <Afiliacion> serían los campos Nombre, Apellido1 y Afiliación de un objeto Persona. Así, los DTDS son similares a esquemas en una BDOO u objeto-relacional. Son, sin embargo, menos restrictivos al permitir la variación en los datos (por ejemplo, en un DTD se pueden especificar campos opcionales y campos que pueden ocurrir múltiples veces). 2.2. Lenguajes de consulta para XML La aplicación práctica y efectiva de XML como formato de intercambio para grandes conjuntos de datos requiere el desarrollo de un lenguaje de consulta para XML. En el Figura 2 Workshop desarrollado en Diciembre de 1998 sobre Lenguajes de Consulta para la Web, hubo distintas propuestas basadas en datos semiestructurados. Una de ellas es XMLQL [11], un lenguaje de consulta similar a SQL con una construcción select-where que, además, toma prestados algunas características de lenguajes desarrollados recientemente por la comunidad de bases de datos para datos semiestructurados. El enfoque elegido para su desarrollo es el de considerar un documento XML como una base de datos, y su DTD como el esquema de la base de datos. El modelo de datos propuesto en XML-QL es una variante del modelo de datos semies-tructurado propuesto en [12], de forma que un documento xml es modelado por un grafo NOVATICA jul./ago. 1999 nº140 21 Figura 3 XML. Este lenguaje permite consultar, construir, transformar e integrar datos XML (figura 2) y ha sido diseñado basándose en las experiencias previas de los autores con otros lenguajes de consulta (UnQl y StruQL) para datos semiestructurados. <inclusion path= "Depto.DProyecto" memberOf= "Proyecto"/> <constraint> Para cada elemento <Depto>, y cada uno de sus elementos <Dproyecto>, éstos son también un elemento <Proyecto> En el SGBD para datos semiestructurados Lore se han adaptado a XML su modelo de datos (OEM) y su lenguaje de consulta (Lorel). Un documento XML en este modelo se representa como un grafo dirigido y etiquetado con dos tipos distintos de arista: aristas de subelementos y aristas de enlaces. Las expresiones de camino son los constructores básicos del lenguaje de consulta lorel, de forma que una expresión de camino es, básicamente, una secuencia de etiquetas, como vldb97.Articulo.Autor.Apellido1 en la figura 3, que adicionalmente puede incluir etiquetas comodín y operadores de expresiones regulares. Existen otros trabajos cuyo objetivo es la integración de datos semiestructurados y estructurados, como el sistema Ozone [13], una extensión del modelo de datos ODMG [14] que usa OEM para representar porciones semiestructuradas de los datos, y que permite mezclar juntos en la misma base de datos física tanto datos estructurados como semiestructurados. El lenguaje de consulta para este sistema es OQLS, sintácticamente idéntico a OQL (Object Query Language) y con semántica sobre datos estructurados idéntica a OQL sobre datos ODMG estándar, extendiendo a éste con una semántica adicional (basada en su mayor parte en el lenguaje Lorel) para acceder a datos semiestructurados XML. OQL-S proporciona navegación de datos semiestructurados sin posibilidad de errores en tiempo de ejecución, proporcionando además comprobación completa de tipo para las porciones estructuradas de los datos. En la universidad de Pennsylvania se trabaja en algunas cuestiones independientes del lenguaje, como son modelos de ejecución y de datos para soportar XML y lenguajes de consulta para datos semiestructurados, herramientas para extraer datos de las fuentes de datos existentes presentándolos como XML, y el uso de esquemas y restricciones para la optimización con XML. Una clase de restricciones de integridad que consideran para la optimización son las restricciones de camino. Por ejemplo, una restricción de inclusión para una página departamental que tiene enlaces a proyectos desarrollados dentro de ese departamento, sería: <constraint> 3. Conclusiones Conforme aumenta el volumen de información recogida en la Web, mayor es la necesidad de un modelo de datos y un lenguaje de consulta y actualización adecuados a este entorno distribuido. Con la aplicación efectiva de XML como formato para los datos Web, hemos de considerar las nuevas características que presenta éste frente a su antecesor, HTML, y los cambios que plantea en el desarrollo de este NOVATICA jul./ago. 1999 nº140 22 paradigma de consulta para la Web. Pensamos que cualquier lenguaje de consulta desarrollado para la Web debería, en principio, cumplir las siguientes características: 1) Ser completo, es decir, no necesitar un procesamiento posterior sobre los datos. 2) Ofrecer resultados fiables. Sería aconsejable que dispusiese de un fuerte tipado y, simultáneamente, de extensibilidad de tipo (definiciones explícitas de conversión de tipo). 3) Permitir la integración de datos estructurados con XML. Debido a la creciente heterogeneidad de la información, las aplicaciones tienen una necesidad cada vez mayor de manejar información semiestructurada (datos XML) junto con información estructurada. 4) Capacidad de actualización. Las fuentes de información sobre Internet son compartidas por muchos usuarios, de forma que éstos mantienen, en ocasiones, copias locales de los documentos para optimizar sus consultas. En este caso, sería adecuado que los cambios en la fuente de datos original fueran propagados de una forma eficiente 5) Capacidad de almacenar información relativa a la evolución de los datos. XML presenta una sintaxis para anotar datos, que facilita el diseño de soluciones para capturar los cambios producidos sobre los datos XML. En la actualidad, los principales esfuerzos hacia una tecnología para XML van orientados a adoptar una plataforma consolidada y estándar (como el modelo ODMG, estándar para las DBOO, y su lenguaje de consulta OQL) enriqueciéndola con nuevas soluciones para tratar los cambios propuestos por XML, más que a definir la sintaxis y semántica de un nuevo lenguaje. 4. Referencias [1] Abiteboul, S., Cluet, S. and Milo, T.; Querying and Updating the File. 19th Int. Conference on Very Large Databases. 1993. [2] Christophides, V., Abiteboul, S., Cluet, S., Scholl, M.; From structured documents to novel query facilities. ACM SIGMOD Int. Conference on Management of Data, páginas 313-323. Minneapolis. 1994. [3] Mendelzon, A., Mihahila, G. and Milo, T.; Querying the World Wide Web. PDIS’96, páginas 80-91. ftp.db.toronto.edu/pub/papers/pdis96.ps.gz. Diciembre, 1996. [4] Abiteboul, S. and Vianu, V. Queries and Computation on the Web. ICDT’97, Enero, 1997. [5] Nestorov, S., Abiteboul, S. and Motwani, R. Extracting Schema from Semistructured Data. f tp://ftp.inia.fr/INRIA/Projects/verso/VersoReport152_ps.gz. 1998. [6] McHugh, J., Abiteboul, S., Goldman, R., Quass, D. and Widom, J. Lore: A Database Management System for Semistructured Data. SIGMOD Record 26(3):54-66. 1997. [7] Goldman, R. and Widom, J.; DataGuides: Enabling query formulation and optimization in semistructured databases. XXIII Int. Conference on Very Large Data Bases. 1997. [8] Fernandez, M., Florescu, D., Kang, J., Levy, A. and Suciu, D.; Strudel: A Web Site Management System. ACM-SIGMOD Int. Conference on Management of Data. 1997. [9] Atzeni, P., Mecca, G. and Merialdo, P.; Cut and Paste. PODS’97, XVI ACM SIGMOD Int. Symposium on Principles of Database Systems, páginas 144-153. 1997. [10] Mecca, G., Mendelzon, A. and Merialdo, P.; Efficient Queries over Web Views. VI Int. Conference on Extending Database Technology. March 1998. [11] Deutsch, A., Fernandez, M., Florescu, D., Levy, A. and Suciu, D.; XML-QL: A Query Language for XML. Submission to the World Wide Web Consortium. 19 de Agosto, 1998. http://www.w3.org/TR/NOTE-xml-ql/ [12] Buneman, P.; Semistructured Data. Tutorial. PODS’97, Sixth ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, páginas 117-121. Tucson, Arizona. May 1997. [13] Lahiri, T., Abiteboul, S. and Widom, J.; Ozone: Integrating Structured and Semistructured Data. http://www-db.stanford.edu/pub/papers/ ozone.ps. 1998. [14] Cattell, R.G.G.; The Object Database Standard: ODMG-93, Release 1.2. Morgan Kaufmann Publishers, Inc. San Francisco, 1996. http:// www.odmg.org 5. Notas 1 http://www.research.att.com/suciu/workshop-papers.html Acceso navegacional: las dos únicas maneras de recuperar un documento son a través de su URL o bien a través de algún otro documento que apunte a él. 3 Object Exchange Model, modelo de objetos de peso ligero en forma de grafo cuyos vértices son objetos y las aristas están etiquetadas. 4 Universal Resource Locator, dirección que permite acceder de forma unívoca a una página en Internet. 5 QL’98, W3C Workshop on Query Languages, http://www.w3.org/TandS/ QL/QL98. 2 NOVATICA jul./ago. 1999 nº140 MONOGRAFIA 23 Bases de Datos Avanzadas Mario Piattini, Marcela Genero, Coral Calero, Macario Polo y Francisco Ruiz Grupo ALARCOS. Departamento de Informática. Escuela Superior de Informática, Universidad de Castilla-La Mancha Calidad de esquemas conceptuales Este trabajo forma parte del proyecto MANTICA, parcialmente financiado por la CICYT y la Unión Europea (1FD97-0168) <{mgenero, mpiattin, mpolo, ccalero, fruiz}@inf-cr.uclm.es> Resumen: los temas relacionados con la calidad de los Sistemas de Información, y en particular de las bases de datos, adquieren cada día una mayor importancia. Sin embargo, la calidad en el modelado conceptual ha sido un área poco investigada. Recientemente, se han publicado algunos interesantes marcos de referencia para la calidad de esquemas conceptuales, incluyendo algunas métricas para distintas dimensiones de esta calidad. Palabras clave: esquemas conceptuales, calidad, métricas. 1. Introducción En la actualidad, en un mercado cada vez más competitivo y globalizado, los temas relacionados con la calidad han pasado a ocupar un primer plano en todos los ámbitos económicos y organizativos, y de modo particular en los Sistemas de Información. Sin embargo, la calidad en el modelado conceptual ha sido un área descuidada hasta hace relativamente poco tiempo, limitándose la mayoría de los trabajos a listar una serie de propiedades o características "deseables" para los esquemas conceptuales y a proponer una serie de transformaciones para mejorar la calidad de los mismos (Roman, 1985; Batini et al., 1992; Reingruber and Gregory, 1994; Simsion, 1994; Boman et al., 1997). Sin embargo, en estas listas muchas definiciones son vagas y complicadas, las propiedades se solapan, se mezclan características de la especificación con las del método y del lenguaje de modelado, se presupone la existencia de diseño/ implementación, y se presentan objetivos poco realistas o imposibles de alcanzar (Lindland et al., 1994). Recientemente, se han publicado algunos marcos de referencia que permiten abordar la calidad en el modelado conceptual de una manera más sistemática. Entre estos marcos destacan los propuestos por Moody y Shanks (Moody y Shanks, 1994; Moody et al., 1998), por el grupo de Lindland en la universidad de Trondheim en Noruega (Lindland et al., 1994; Krogstie et al., 1995), por Pohl (1994) y el de Schuette y Rotthowe (1998). A continuación describiremos los dos primeros marcos, que han tenido hasta el momento una mayor repercusión. Figura 1: Marco para la calidad del modelado conceptual, Krogstie et al. (1995) NOVATICA jul./ago. 1999 nº140 24 Tipos de calidad Objetivos Medios Propiedades modelo Actividades SINTÁCTICA Corrección sintáctica Sintaxis formal Verif. Sintáctica SEMÁNTICA Validez viable Semántica formal Verif. Consistencia Compleción viable Modificabilidad Inserción sentencias Borrado sentencias Percibida PRAGMÁTICA Comprensión viable Entrenamiento Economía expresiva Inspección Estética Visualización Filtrado Presentación diag. Parafrasear Explicación Entrenamiento Ejecutabilidad Ejecución Animación Simulación SOCIAL Acuerdo viable Modelado conflicto Análisis punto vista Resolución conflicto Fusión de modelos Tabla 1: Objetivos y medios para conseguir la calidad (Krogstie et al., 1995) 2. Marco de la Universidad de Trondheim Este marco, basado en teoría semiótica, se presentó en Lindland et al. (1994) con el objetivo de paliar las deficiencias detectadas en los enfoques de listas de propiedades, al mismo tiempo que se separan los objetivos de calidad de los medios para alcanzarlos y se utiliza un fundamento matemático en su descripción. En Krogstie et al. (1995) se ha extendido este marco con el fin de incorporar el concepto de acuerdo social de Pohl (1994), con lo que se pueden identificar los siguientes elementos (figura 1): - Público: unión del conjunto de actores individuales, el conjunto de actores sociales organizacionales y el conjunto de actores técnicos que necesitan relacionarse con el esquema. - Esquema: conjunto de todas las sentencias expresadas explícita o implícitamente. - Lenguaje: conjunto de todas las sentencias que se pueden expresar de acuerdo al vocabulario y la gramática de los "lenguajes de modelado" (modelos) utilizados. - Dominio: conjunto de todas las sentencias que serían correctas y relevantes acerca del problema. - Interpretación del público: conjunto de todas las sentencias de las que el público piensa que consta el modelo. - Conocimiento de los participantes: unión de los conjuntos de sentencias de todos los actores sociales individuales. Como es natural, consideraremos que un esquema tiene una mayor calidad semántica cuanto mejor sea la correspondencia entre el esquema conceptual que hemos diseñado y el dominio que pretendemos representar. Sin embargo, como señalan los autores de este marco, es imposible establecer o verificar directamente esta correspondencia, ya que para diseñar el esquema se debe acudir al conocimiento que tiene el público sobre el dominio y para verificarlo se debe emplear la interpretación que el público hace del esquema. En este marco se propone distinguir varios tipos de calidad: - Calidad sintáctica: que viene determinada por la correspondencia entre el esquema y el lenguaje (modelo), y cuyo objetivo es la corrección sintáctica. - Calidad semántica: (percibida), que comprende tanto la validez (lo expresado en el esquema es correcto y relevante para el problema) como la compleción (el esquema contie- NOVATICA jul./ago. 1999 nº140 25 Figura 2: Factores de calidad, Moody (1998) ne todas las sentencias acerca del dominio que son correctas y relevantes). - Calidad pragmática: cuyo objetivo es que el esquema sea comprendido. - Calidad social: que persigue distintos tipos de acuerdo tanto en la interpretación del esquema como respecto al conocimiento del dominio. Este marco propone además distintos medios para mejorar los diferentes tipos de calidad, que se resumen en la tabla 1. 3. Marco de Moody y Shanks Otro marco, con un enfoque más práctico que el anterior, fue presentado por Moody y Shanks (1994) y refinado recientemente en Moody et al. (1998). Pretende ayudar a los diseñadores a la hora de elegir entre distintas alternativas de diseño y de poder acomodar las distintas visiones de los distintos implicados (stakeholders) en el proceso de modelado de datos. Este marco presenta los siguientes elementos relacionados con el esquema: - Factor de calidad: propiedad deseable de un esquema conceptual - Implicado (stakeholder): persona involucrada en la construcción o utilización del esquema. - Estrategia de mejora: técnica para mejorar la calidad de los esquemas conceptuales. - Método de evaluación: modo sistemático de evaluar factores de calidad - Peso: que sirve para definir la importancia relativa de los factores de calidad - Valores: representan la valoración de un factor de calidad por alguno de los implicados. En la última revisión de este marco, Moody (1998), se proponen los ocho factores de calidad que aparecen en la figura 2. Para Moody estos factores significan: - Compleción: capacidad del modelo de tener toda la información necesaria para cumplir los requisitos del usuario. - Integridad: grado en el que las reglas del negocio que se aplican a los datos están definidas en el esquema conceptual. - Flexibilidad: facilidad con la que el esquema se puede adaptar a los cambios en los requisitos. - Comprensibilidad: facilidad con la que el esquema puede ser entendido. - Corrección: se refiere a si el esquema cumple las reglas de las técnicas de modelado utilizadas. - Simplicidad: significa que el esquema contiene los mínimos constructores posibles. - Integración: nivel de consistencia del esquema con el resto de los datos de la organización. - Implementabilidad: facilidad con la que el esquema puede ser implementado dentro de las restricciones de tiempo, presupuesto y tecnología del proyecto. Este marco se ha validado en varios casos prácticos, en los que también se ha estudiado la influencia que ejercen unos factores sobre otros; así, por ejemplo, aumentar la implementabilidad del esquema puede acarrear una disminución de su flexibilidad y compleción. Shanks y Darke (1997) han propuesto integrar este marco con el de la universidad de Trondheim, ya que ambos se complementan (este último desde un punto de vista más teórico, mientras que el de Moody y Shanks se enfoca más hacia la práctica) y además comparten conceptos: los implicados (stakeholders) podrían asimilarse al público, los objetivos y las propiedades a los factores de calidad y el concepto de modelo es compatible en los dos marcos. Los conceptos comunes son integrados en este marco, y los conceptos disjuntos son incorporados al mismo, como se muestra en la figura 3. En dicha figura se indican los conceptos referentes a la calidad en el modelado de datos basados en la teoría, y además los conceptos que soportan la evaluación de la calidad en la práctica. Los conceptos que NOVATICA jul./ago. 1999 nº140 26 Figura 3: Metamodelo del marco integrado propuesto por Shanks y Darke (1997) están basados tanto en la práctica como en la teoría se muestran en la parte central (sombreada con un color más oscuro) de la figura 3, la cual permite entender la relación entre ambos marcos y como uno informa al otro. Este marco integrado puede aplicarse en cualquier etapa del proceso de modelado conceptual, y tiene en cuenta el concepto de calidad tanto en el modelado del producto como en el proceso de modelado del mismo. 4. Métricas para medir la calidad de esquemas conceptuales A pesar del avance que suponen estos marcos, sólo constituyen el primer paso para asegurar la calidad de los esquemas conceptuales, ya que es necesario establecer métricas para valorar los diferentes factores de calidad. Como es sabido por las famosas citas de Tom de Marco y Norman Fenton, "no se puede controlar lo que no se puede medir", y "no se puede predecir lo que no se puede medir". De hecho, actualmente se reconoce que la medición del software es el medio más efectivo para comprender, monitorizar, controlar, predecir y mejorar el desarrollo del software (Briand et al., 1996a). La medición no se utiliza sólo para comprender y mejorar el desarrollo, sino también para determinar la mejor manera de ayudar a los profesionales y a los investigadores (Schneidewind, 1997). La Ingeniería del Software ha propuesto enormes cantidades de métricas para productos, procesos y recursos software (Fenton and Pflegger, 1997; Melton, 1996); sin embargo, prácticamente todas las métricas publicadas desde el número ciclomático de McCabe (Mc Cabe, 1976) hasta la fecha, se han centrado en características de los programas, descuidando las bases de datos (Sneed and Foshag, 1998). Sin embargo, la calidad de las bases de datos, y especialmente de los esquemas conceptuales, ejerce una gran influencia en la calidad del Sistema de Información en su conjunto, por lo que es importante disponer de métricas que permitan valorar la calidad de estos esquemas. Uno de los pocos trabajos publicados en este sentido es el de Moody (1998), que propone 25 métricas clasificadas según los factores de calidad de la figura 2; algunos calculados de forma objetiva (p. ej. número de entidades del esquema), mientras que otros resultan de la puntuación subjetiva de los implicados en el diseño. Nosotros también hemos propuesto algunas métricas para la calidad de esquemas conceptuales, como el ratio de minimalidad, la cohesión del esquema, la complejidad del esquema, la longitud interrelacional, etc. (Polo et al., 1998). De todas maneras, hay que tener cuidado al proponer métricas, ya que muchas veces no miden los atributos que NOVATICA jul./ago. 1999 nº140 pretenden medir (Briand et al, 1996b). Una medición efectiva de los esquemas conceptuales pasará por disponer de métricas definidas con rigor y validadas formalmente (Fenton, 1994; Morasca and Briand, 1997), además de que demuestren su validez empírica, tanto en experimentos controlados como en casos reales (Basili, 1999). 5. Conclusiones Creemos que es necesaria una mayor investigación en los aspectos relacionados con la calidad de los esquemas conceptuales y, especialmente, con la medida de su calidad. Hemos presentado el estado del arte sobre este tema, pero queda todavía mucho por hacer en lo relativo a los marcos de calidad propuestos así como en la elaboración y refinamiento de métricas, tanto desde el punto de vista teórico como práctico. Además, hay que tener en cuenta que la mayor parte de los estudios revisados en este artículo se centran en la calidad del producto (esquema conceptual) siendo necesaria una mayor investigación en la calidad del proceso de modelado. En estos momentos, en nuestro grupo estamos trabajando además en la definición de métricas para otros tipos de bases de datos: relacionales (Calero et al., 1999), objeto-relacionales (Piattini et al., 1998) y activas (Díaz y Piattini, 1999). 6. Referencias Basili, V. R. (1999). Using experiments to build a body of knowledge. Conferencia impartida en la U.P.M. Batini, C., Ceri, S. y Navathe, S. (1992). Conceptual database design. An entity relationship approach. Benjamin Cummings Publishing Company. Boman M, Bubenko J., Johannesson P. y Wangler B. (1997). Conceptual Modelling, Prentice Hall. Briand, L.C., Differding, C.M. y Rombach, D. (1996a). Practical Guidelines for Measurement-Based Process Improvement. Software ProcessImprovement and Practice 2, 253-280. Briand, L., Morasca, S. y Basili, V. (1996b). Property-Based Software Engineering Measurement. IEEE Transactions on Software Engineering, 22 (6), 68-86. Calero, C., Piattini, M., Polo, M. y Ruiz, F. (1999). Validating referential integrity as a database quality metric. Proceedings of the First International Conference on Enterprise Information Systems, Portugal, 45-50. Chidamber, S. y Kemerer, C. A metrics suite for object-oriented design, IEEE Trans. Software Eng., 20 (6), 476-493. Díaz, O. y Piattini, M. (1999). Metrics for active databases maintainability. Proc. CAISE’99. Heidelberg, June 16-18. Fenton, N. (1994). Software Measurement: A Necessary Scientific Basis. IEEE Transactions on Software Engineering, 20(3), 199-206. Fenton, N. y Pfleeger, S. L. (1997). Software Metrics: A Rigorous Approach, 2nd. edition. London, Chapman & Hall. Kesh, S. (1991). Evaluating the Quality of Entity Relationship Models. Information and Software Technology, 37 (12), 681-689. Krogstie, J., Lindland, O. I. y Sindre, G. (1995). Towards a Deeper Understanding of Quality in Requirements Engineering, Proceedings of the 7th International Conference on Advanced Information Systems Engineering (CAISE), Jyvaskyla, Finland, June, 82-95. Lindland, O., Sindre, G. y Solvberg, A. Understanding Quality in Conceptual Modelling, IEEE Software, Marzo, 42-49. McCabe, T. (1976). A complexity measure. IEEE Trans. Software Engineering, 2(5), 308-320. Melton, A. (ed.) (1996). Software Measurement. London, International Thomson Computer Press. Moody, L. (1998). Metrics For Evaluating the Quality of Entity Relationship 27 Models. Proceedings of the Seventeenth International Conference on Conceptual Modelling (E/R ´98), Singapore, November 16-19, 213-225. Moody, L. y Shanks G. (1994). What Makes A Good Data Model? Evaluating The Quality of Entity Relationships Models. Proceedings of the 13th International Conference on Conceptual Modelling (E/R ´94), Manchester, England, December 14-17, 94-111. Moody, L., Shanks G. y Darke P. (1998). Improving the Quality of Entity Relationship Models – Experience in Research and Practice. Proceedings of Seventeenth International Conference on Conceptual Modelling (E/R ´98), Singapore, November 16-19, 255-276. Morasca, S. y Briand, L.C. (1997). Towards a Theoretical Framework for measuring software attributes. Proceeding of the Fourth International, Software Metrics Symposium, 119-126. Piattini, M., Calero, C., Polo, M. y Ruiz, F. (1998). Maintainability in Object-Relational Databases. Proc of The European Software Measurement Conference FESMA 98, Antwerp, May 6-8, Coombes, Van Huysduynen and Peeters (eds.), 223-230. Pohl, K. The Three Dimensions of Requirements Engineering: A Framework and its Applications, Information Systems, 19, 243-258. Polo, M., Calero, C., Ruiz, F. y Piattini, M. (1998). Métricas de calidad y complejidad para bases de datos. Actas de las III Jornadas en Ingeniería del Software, Toval, A. y Nicolás, J. (eds.), 79-90. Reingruber, M. C. y Gregory, W. W. (1994): The Data Modelling Handbook. A best-practice approach to building quality data models. John Wiley & Sons, Inc. Roman, G. A Taxonomy of Current Issues in Requirements Engineering, Computer, April, 14-22. Schneidewind N.F. (1997). Software metrics for quality control. Proceedings of the fourth international software metrics symposium. IEEE Computer Society Technical Council on Software Engineering, 127-136 Schuette, R. y Rotthowe, T. (1998). The Guidelines of Modeling – An Approach to Enhance the Quality in Information Models. Proceedings of the Seventeenth International Conference on Conceptual Modelling (E/R ´98), Singapore, November 16-19, 240-254. Shanks, G. y Darke, P. (1997). Quality in Conceptual Modelling: Linking Theory and Practice. Proc. of the Pacific Asia Conference on Information Systems (PACIS’97), Brisbane, 805-814. Simsion, G.C. (1994). Data Modelling Essentials, Van Nostrand Reinhold. Sneed, H.M. y Foshag, O. (1998): Measuring Legacy Database Structures. Proc. of The European Software Measurement Conference FESMA’98, Coombes, Hooft and Peeters (eds.), 199-210. 28 MONOGRAFIA NOVATICA jul./ago. 1999 nº140 Bases de Datos Avanzadas Dolores Cuadra, Carlos Nieto, Paloma Martínez, Adoración de Miguel Depto. de Informática. Universidad Carlos III de Madrid <{dcuadra, cnieto, pmf, admiguel}@ inf.uc3m.es> Resumen: en el diseño de una base de datos (BD) nos enfrentamos, a lo largo de las distintas fases, con sucesivas pérdidas de semántica. Para evitar esta pérdida consideramos, además de las restricciones propuestas para el modelo relacional en el SQL92, la invocación a procedimientos en reglas ECA (evento, condición, acción) que puedan interactuar con el usuario de la BD. En este artículo aplicamos este enfoque a una de las restricciones semánticas ó de usuario más importantes del modelo E/R (Entidad/ Interrrelación), la restricción de cardinalidad. Keywords: diseño de BD, reglas ECA, restricciones de cardinalidad, herramientas CASE. 1. Introducción El modelado de BD es un problema complejo que aborda la concepción, comprensión, estructuración y descripción de una situación real (Universo de Discurso) mediante la creación, conforme a procesos de abstracción y modelos, de esquemas que sirvan como base para la realización de Sistemas de Información que usen BD como uno de sus elementos. Para ello es necesario el uso de Metodologías que guíen al diseñador en el proceso a seguir para la obtención de los diversos esquemas. Algunas metodologías tan sólo dan vagas indicaciones, o se limitan a proponer heurísticas, otras establecen unos pasos bien definidos e incluso formalizados (sirva como ejemplo el proceso de transformación de esquemas E/R a esquemas relacionales o el proceso de normalización de esquemas relacionales, De Miguel et al. (1999)). Tradicionalmente, en el proceso de diseño de BD, se han distinguido tres fases (Conceptual, Lógico y Físico). La fase de modelado conceptual constituye el nivel más abstracto, independiente de cualquier SGBD (sistema gestor de base de datos) y que por tanto resulta más cercano al Universo de Discurso que a su posible realización en un SGBD es al mismo tiempo el que recoge la mayor semántica del problema. En los últimos años han persistido múltiples intentos de dar un enfoque más sistemático a la resolución de problemas de modelado. Uno de tales intentos ha sido la mecanización mediante el empleo de herramientas CASE. Si bien es cierto que algunas de ellas adoptan enfoques más avanzados, también lo es que muchas no pasan de ser simples utilidades para dibujar. En general no disponen siquiera de un soporte metodológico o no son lo suficientemente estrictas en su aplicación, con lo cual el diseñador no encuentra el camino correcto para realizar su tarea, Atkins (1996). Además, los modelos que generalmente soportan son modelos lógicos, que suelen incluir bastantes consideraciones físicas, aunque la notación gráfica empleada sea un subconjunto del modelo E/R. Control de restricciones de cardinalidad en una metodología de desarrollo de bases de datos relacionales Centrándonos en la problemática de las lagunas metodológicas en el desarrollo de BD, en este artículo se propone un enfoque sistemático para el control de un tipo de restricciones, las restricciones de cardinalidad de un esquema E/R. Estudiaremos cómo realizar la transformación a un esquema relacional, recogiendo la mayor semántica, con el fin de que pueda implementarse en una herramienta CASE. Para ello, en el apartado 2 se justifica la necesidad de que la semántica de las restricciones se mantenga en el esquema de la BD y se proponen las reglas ECA como solución. En el apartado 3 fijamos la terminología de las cardinalidades y se expone la problemática del tratamiento de las cardinalidades a lo largo de las fases de modelado conceptual, diseño lógico. En el apartado 4 se describe la propuesta de control de las restricciones de cardinalidad en la transformación de un esquema conceptual a un esquema relacional y, por último, se exponen unas conclusiones. 2. SGBD activos y control de restricciones Tradicionalmente los SGBD, en general, han venido adoptando un comportamiento pasivo: la responsabilidad de crear, recuperar, modificar y eliminar datos suele recaer ó bien en los usuarios ó bien en los programas. Un SGBD pasivo siempre precisará de algún elemento ajeno al mismo (usuario o programa) que le indique qué operaciones hacer y cuándo hacerlas. Por tanto, el SGBD actuará sólo cuando estos elementos externos se lo pidan explícitamente y aunque el SGBD esté preparado para realizar ciertos controles, no es capaz de determinar qué operaciones ha de llevar a cabo ni el momento en que debe realizarlas. Es, por tanto, un sistema totalmente dependiente del entorno. La anterior afirmación puede matizarse si se tiene en cuenta el control que el SGBD usualmente realiza para mantener la integridad y la seguridad de los contenidos de la BD. Así, un SGBD puede impedir ciertas acciones indeseadas sobre los datos, como las que violen las restricciones de integridad, que en el caso de realizarse llevarían a la BD a un estado inconsistente. Por tanto, el SGBD puede rechazar operaciones que 'a priori' se sabe son incorrectas. El problema es la escasa flexibilidad para especificar estas restricciones, habitualmente limitadas a aquel, en general escaso, subconjunto de las mismas incluido en el modelo lógico. En un SGBD pasivo la semántica se encuentra distribuida, implícita en las distintas aplicaciones que acceden a la BD. Por ejemplo, una comprobación previa a una determinada inserción se debería repetir en todas las aplicaciones que la realizaran. Si la semántica cambia se producirán problemas de mantenimiento. NOVATICA jul./ago. 1999 nº140 Creemos pues, que resulta de vital importancia incorporar la máxima semántica en la BD. Esta idea no es sino la natural continuación de la ya común incorporación de restricciones dentro del esquema. En respuesta a esta necesidad de recoger más semántica, y hacerlo de manera flexible, se pueden aplicar ciertas facilidades que proporcionan los SGBD activos, por ejemplo los disparadores. A diferencia de un SGBD pasivo, un SGBD que desarrolle comportamiento activo es capaz de realizar sus funciones de manera autónoma, aunque no completamente independiente del entorno. El comportamiento activo en los SGBD es habitualmente de tipo reactivo, reacciona a los eventos producidos por algún elemento externo que actúe como fuente de eventos. Una vez que el SGBD detecta la aparición de un evento, analiza su entorno y, si procede, desencadenará autónomamente un comportamiento preestablecido. En respuesta a la necesidad de especificar este tipo de comportamiento, surgió el formalismo de reglas ECA. Una regla ECA (en ocasiones denominada disparador, trigger) consta de tres componentes: - Evento: provoca que la regla se active. - Condición: se comprueba cuando la regla se activa, i.e. se examina el contexto. - Acción: se ejecuta cuando la regla se ha activado y la condición se cumple. Existen diversas alternativas o grados de libertad que cada SGBD concreta para la especificación de estos componentes. Son ejemplos típicos de eventos las operaciones realizadas sobre la BD, el alcanzar un determinado momento en el tiempo, etc. Las condiciones se podrán referir a valores anteriores y posteriores de los atributos, se especificarán mediante un lenguaje específico que podría incluir un subconjunto del LMD (lenguaje de manipulación de datos), etc. Por último, las acciones podrán ser, entre otras, operaciones sobre la BD, el rechazo de la transacción que disparó la regla ó la invocación de un procedimiento, entre otras. En concreto, la invocación de procedimientos como acciones de disparadores es una posibilidad seductora. Esos procedimientos pueden o no almacenarse en la BD (sería preferible que sí se almacenarán), hacer uso o no de la BD y ser codificados en cualquier lenguaje, no estando limitados pues a las capacidades expresivas de los lenguajes proporcionados por el SGBD. El SGBD deberá proporcionar los medios para el manejo y ejecución de estos procedimientos. Esta capacidad está comenzando a llegar a los SGBD comerciales, por ejemplo, en DB2 los procedimientos almacenados son invocaciones a procedimientos (que pueden no formar parte de la BD) y existe un tipo especial de disparador alert (alerta) que tiene la capacidad de informar a una aplicación de un cambio de estado de la base de datos. Otros SGBD, como ORACLE, SYBASE, SQL Server, etc, proporcionan facilidades análogas. La invocación a procedimientos como acción de las reglas ECA se considera adecuada, ACT-NET Consortium (1996), para permitir que el SGBD pueda controlar el Sistema de Información en su conjunto. Por ejemplo, esta aproximación podría emplearse para el problema de mantener actualizados los formularios que un usuario está visualizando. En este artículo exploramos la invocación a procedimientos en reglas ECA como solución al control de las restricciones 29 de cardinalidad. Esto es ampliable a cualquier tipo de restricciones, en especial aquellas cuya conservación requiere la interacción con el usuario. Un problema potencial es que en algunos casos se haría depender de un usuario la duración de una transacción. Por ejemplo, si éste se ausentara del trabajo, los recursos empleados por la transacción quedarían bloqueados. Una posible solución sería establecer un temporizador para forzar su finalización. Por otra parte, se requeriría un modelo de transacción anidado1, Orfali et al. (1999), Gray et al.(1993), que permitiese reentrada en el caso de que un procedimiento inicie una transacción. Por último, figurarían los problemas de sincronización y la posibilidad de no terminación que pueden producirse por la interacción entre reglas y el funcionamiento normal del SGBD. Estos problemas requerirían el establecimiento de un modelo de ejecución concreto que no es objeto de este artículo. 3. El problemas de las cardinalidades Antes de exponer la aproximación seguida para el tratamiento de las restricciones de cardinalidad en un esquema E/R vamos a fijar la terminología. Chen (1976) define la cardinalidad máxima, también especificada como tipo de correspondencia en interrelaciones de grado dos, como el número máximo de ejemplares de un tipo entidad asociados a un ejemplar del otro tipo en el tipo de interrelación, que puede ser 1 o N. Tardieu (1989) define las cardinalidades máximas y mínimas como el máximo y mínimo número de veces que un ejemplar de un objeto participa en los ejemplares de la interrelación. Siguiendo la definición de Chen, nosotros definimos las cardinalidades máximas y mínimas de los tipos de entidad que participan en un tipo de interrelación de grado dos como el número máximo y mínimo de ejemplares de un tipo de entidad que puede relacionarse con un único ejemplar del otro, u otros tipos de entidad que participan en el tipo de interrelación, De Miguel et al. (1999). Gráficamente, las restricciones de cardinalidad se representan por una etiqueta, (0,1), (1,1), (0,N) o (1,N)2, situada en la línea que conecta el tipo de entidad con el rombo que representa el tipo de interrelación. En el paso de un esquema E/R a un esquema relacional estándar se produce una pérdida de semántica. Por ejemplo, tanto entidades como interrelaciones se transforman en relaciones. En el caso que nos ocupa de la transformación de la restricciones de cardinalidad no siempre son suficientes las opciones de clave ajena para controlar las cardinalidades mínimas y máximas. Con el fin de evitar esta pérdida de semántica, proponemos en este artículo recoger estas restricciones con el SQL-92, ISO (1992), más disparadores. 4. Control de restriccones de cardinalidad en la transformación al modelo relacional Para llevar a cabo la transformación de las cardinalidades del modelo E/R extendido al modelo relacional, sin que exista pérdida de semántica, debemos apoyarnos en las mecanismos que nos proporciona el modelo relacional para expresar restricciones semánticas. Estos mecanismos son la definición de clave ajena, las opciones de borrado y modificación de ésta, la obligatoriedad de atributos, las claves NOVATICA jul./ago. 1999 nº140 30 alternativas, las restricciones de verificación (CHECKS, ASSERTIONS) y los disparadores. tabla I pueden ser en cascada o restringido dependiendo de la semántica que queramos recoger. Nosotros en esta sección seguiremos para los disparadores una sintaxis similar a la propuesta en el SQL3, Melton et al.(1993), con la salvedad que podrán llamar a procedimientos que nos servirán como interfaz con el usuario en línea y de esta manera poder capturar los datos necesarios evitando pérdidas de semántica. 4.1.2 Cardinalidad (1,n) Para la entrada de datos se emplearán los procedimientos: · PEDIR_PK (tabla, clave_primaria), que muestra un formulario al usuario y le solicita la clave primaria de la relación que indicamos como parámetro. · PEDIR_RESTO (tabla, resto_atributos), que muestra un formulario al usuario y le pide todos los atributos de la relación "tabla", menos los que componen la clave primaria, y permite que el usuario deje en blanco aquellos atributos que no sean obligatorios. Los disparadores que vamos a manejar tienen la siguiente estructura: CREATE TRIGGER nombre_disparador {BEFORE/AFTER/INSTEAD OF} {INSERT/DELETE/UPDATE} ON referencia_tabla [FOR EACH ROW] BEGIN Cuerpo_disparador END; En este caso la restricción de cardinalidad mínima es más fuerte (véase la figura 1 con X=1), se pide que todo ejemplar de A tiene que estar forzosamente relacionado con uno o más ejemplares de B. Por una parte, como en la creación de la tabla I debemos expresar las opciones de borrado y modificación de la clave ajena cod_b (de forma similar el cod_a), definimos que ambas sean en cascada o restringidas. Pero esto no es suficiente para controlar la cardinalidad mínima, debemos asegurar que todo ejemplar de A este relacionado con al menos un ejemplar de B y por tanto hemos de cuidar que la BD no quede inconsistente cada vez que se inserte una nueva tupla en A ó se borre una tupla en I. Crearemos un disparador, que al insertar en A introduzca una tupla en I. Se nos presentan dos opciones que contemplaremos en el disparador: - Que el nuevo ejemplar de A se relacione con un ejemplar de B que ya se encuentre en la relación B. - Que el nuevo ejemplar de A se relacione con un ejemplar nuevo de B. 5. Create trigger inserción_NM_(1,N)_A BEFORE INSERT ON FOR EACH ROW A 4.1. Transformación de interrelaciones binarias N:M Una interrelación de tipo N:M (figura1) se transforma en una relación que tiene como clave primaria la concatenación de las claves primarias de las entidades que asocia (figura 2). Si la interrelación tiene atributos propios, éstos pasan a formar parte de la lista de atributos de la nueva relación a la que da lugar. Si estos atributos forman parte de un grupo repetitivo, entonces son necesarios para identificar una tupla de la relación y deberán formar parte de la clave primaria de ésta. Estudiamos las cardinalidades de uno de los lados de la interrelación por que el razonamiento para el otro es similar. Veamos, según las cardinalidades mínimas, cómo definimos la relación de enlace (I), las opciones de borrado y modificación de la clave ajena y, si es necesario crear algún disparador para controlar estas cardinalidades cuando realizamos inserciones, borrados o modificaciones en cada una de las relaciones. BEGIN PEDIR_PK (B,:Vcod_b); PEDIR_RESTO (I,:Vresto_atributos _i); IF NOT EXISTS(SELECT * FROM B WHERE cod_b=:Vcod_b) THEN BEGIN PEDIR_RESTO(:Vresto_atributos _b) INSERT INTO B ( cod_b, resto_atributos_b) VALUES (:Vcod_b, :Vresto_atributos_b) END; INSERT INTO I (cod_a, cod_b, resto_atributos_i) VALUES (:New.cod_a, :Vcod_b, :Vresto_atributos_i) END; Para controlar el borrado de tuplas en las relaciones I y B y la modificación en I, y de esta forma evitar que un ejemplar de A quede sin relacionarse con un ejemplar de B, creamos los siguientes disparadores: 4.1.1. Cardinalidad (0,n) El esquema E/R correspondiente se muestra en la figura 1 (donde X=0) y su transformación en la figura 2. Los borrados y las modificaciones de la clave ajena cod_b en la Figura 1: Interrelación N:M CREATE TRIGGER BORRADO_NM_(1,N)_B BEFORE DELETE ON B FOR EACH ROW Figura 2: Transformación al modelo relacional de la fig. 1 NOVATICA jul./ago. 1999 nº140 31 BEGIN IF :Old.cod_b IN (SELECT cod_b FROM I WHERE cod_a IN (SELECT cod_a FROM I GROUP BY cod_a HAVING COUNT(*)=1)) THEN ROLLBACK (*deshacemos la transacción*) END; cardinalidad, solo la opción de borrado (RESTRICT ó CASCADE) y de modificación (CASCADE). Tanto en este apartado como en el siguiente, no consideramos la opción SET NULL en el borrado ya que dependerá de la cardinalidad que nos encontremos en el otro extremo de la interrelación (estudio realizado en 4.2.3 y 4.2.4) y por supuesto de la semántica que queramos recoger. CREATE TRIGGER BORRADO_NM_(1,N)_I BEFORE DELETE ON I FOR EACH ROW 4.2.2. Cardinalidad (1,n) BEGIN IF :Old.cod_b IN (SELECT cod_b FROM I WHERE cod_a IN (SELECT cod_a FROM I GROUP BY cod_a HAVING COUNT(*)=1)) THEN ROLLBACK END; CREATE TRIGGER MODIFICACION_NM_(1,N)_I BEFORE UPDATE ON I FOR EACH ROW BEGIN IF :Old.cod_a<>:New.cod_a AND :Old.cod_b IN (SELECT cod_b FROM I WHERE cod_a IN (SELECT cod_a FROM I GROUP BY cod_a HAVING COUNT(*)=1)) THEN ROLLBACK END; 4.2. Transformación de interrelaciones binarias 1:N Para las interrelaciones binarias 1:N (figura 3) existen dos soluciones para la transformación al modelo relacional: (a) Propagar la clave de la entidad que tiene cardinalidad máxima 1 a la que tiene cardinalidad máxima N, desapareciendo el nombre de la interrelación (lo que conlleva pérdida de semántica, véase figura 4). Y si existen atributos en la interrelación éstos forman parte de la relación que posee la clave ajena. (b) Crear una nueva relación para la interrelación (como en el caso de las interrelaciones binarias N:M). Estudiaremos el caso (a), que es el caso más general, distinguiendo los diferentes tipos de cardinalidad mínima que puede haber. Esta cardinalidad nos indica que todo ejemplar de A tiene que estar relacionado con al menos un ejemplar de B (véase la figura 3 con Y=1 y X=0 ó 1), por lo que debemos controlar la inserción de nuevos ejemplares de A y si borro un ejemplar de B evitar que un elemento de A quede sin relacionarse con un elemento de B. Para recoger esta cardinalidad mínima tenemos que crear los siguientes disparadores: CREATE TRIGGER INSERCION_1N_(1,N)_A BEFORE INSERT ON A FOR EACH ROW BEGIN PEDIR_PK (B,:Vcod_b); IF NOT EXISTS(SELECT * FROM B WHERE cod_b=:Vcod_b) THEN (*se crea una nueva tupla en B que se relacione con el nuevo ejemplar de A*) PEDIR_RESTO (B,:Vresto_atributos _b); INSERT INTO B ( cod_b, resto_atributos_b, cod_a) VALUES (:Vcod_b, :Vresto_atributos_b,:New.cod_a) ELSE UPDATE B SET cod_a=:New.cod_a WHERE cod_b=:Vcod_b END; Para el borrado y modificación de tuplas en la relación B implementamos los siguientes disparadores: CREATE TRIGGER BORRADO_1N_(1,N)_B BEFORE DELETE ON B FOR EACH ROW Como los ejemplares de A pueden estar o no relacionados con los de B (véase la figura 3 con Y=0 y X=0 ó 1) no necesitamos agregar nada más para controlar esta BEGIN IF :Old.cod_b IN (SELECT cod_b FROM B WHERE cod_a IN (SELECT cod_a FROM B GROUP BY cod_a HAVING COUNT(*)=1)) THEN ROLLBACK END; CREATE TRIGGER MODIFICACION_1N_(1,N)_B Figura 3: Interrelación 1:N Figura 4: Transformación al modelo relacional de la fig.3 4.2.1. Cardinalidad (0,n) NOVATICA jul./ago. 1999 nº140 32 BEFORE UPDATE ON B FOR EACH ROW BEGIN IF :Old.cod_a<>:New.cod_a AND :Old.cod_b IN (SELECT cod_b FROM B WHERE cod_a IN (SELECT cod_a FROM B GROUP BY cod_a HAVING COUNT(*)=1)) THEN ROLLBACK END; propagación de la clave de la entidad con cardinalidad (1,1) a la relación resultante de la entidad con cardinalidad (0,1) (véase figura 4). No se admiten valores nulos en la clave ajena y además es clave alternativa (UNIQUE), de esta forma aseguramos que todo ejemplar de A esté relacionado con un ejemplar de B. Las opciones de borrado y modificación de la clave ajena pueden ser RESTRICT ó CASCADE. Tanto la opción de borrado como la de modificación de la clave ajena pueden ser RESTRICT ó CASCADE. Este tipo de interrelación aparece en la figura 7 (con X=Y=1). La transformación al modelo relacional se haría con propagación de la clave ajena como se observa en la figura 4. Otra alternativa (más simétrica) sería la propagación de ambas claves, lo que duplicaría los disparadores y ralentizaría las actualizaciones. Esta clave ajena es no nula (NOT NULL), única (UNIQUE), y la opción de borrado puede ser RESTRICT ó CASCADE así como la opción de modificación. Con estas restricciones semánticas del modelo relacional recogemos que todo ejemplar de B está relacionado con uno y sólo uno de A. Para reflejar que todo ejemplar de A está relacionado con uno y sólo un ejemplar de B debemos crearnos los siguientes disparadores: 4.2.3. Cardinalidad (0,1) Este caso se corresponde con la figura 3 (con X=0 e Y=0 ó 1). Para controlar que la cardinalidad mínima sea 0, la clave ajena cod_a (figura 4) debe admitir valores nulos. La opción de borrado, además de RESTRICT ó CASCADE, puede ser SET NULL, dependerá de la semántica. La opción de modificación CASCADE. 4.2.4. Cardinalidad (1,1) En este caso, al obligar a que todo ejemplar de A este relacionado con un ejemplar de B (véase figura 3 con X=1 e Y=0 ó 1), la clave ajena cod_a (véase figura 4) no puede admitir valores nulos y por lo tanto, las opciones de borrado y modificación no admitirán el SET NULL. 4.3. Transformación de interrelaciones binarias 1:1 Este tipo de interrelaciones pueden considerarse tanto un caso particular de las N:M como de las 1:N. Por lo tanto, su transformación al modelo relacional se realiza de diversas formas. Hemos optado por elegir aquella que evita la presencia de valores nulos, aunque se podrían haber tenido en cuenta otras consideraciones, por ejemplo, eficiencia en las actualizaciones ó en las consultas. 4.3.1. Cardinalidad (0,1), (0,1) La interrelación I (figura 5) se transforma en una relación. Ninguna de las dos claves ajenas admite nulos y una de ellas (en este caso cod_a, según la figura 6) actuará como clave primaria y la otra como clave alternativa (cod_b). Las opciones de borrado y modificación de las claves ajenas pueden ser RESTRICT ó CASCADE. No serán necesarios disparadores que refuercen la integridad de la base de datos. 4.3.3. Cardinalidad (1,1),(1,1) CREATE TRIGGER INSERCION_11_(1,1)_A BEFORE INSERT ON A FOR EACH ROW BEGIN PEDIR_PK (B,:Vcod_b); PEDIR_RESTO (B,:Vresto_atributos _b); *se crea una nueva tupla en B que se relacione con el nuevo ejemplar de A* INSERT INTO B ( cod_b, resto_atributos_b, cod_a) VALUES (:Vcod_b, :Vresto_atributos_b,:new.cod_a) END; Para controlar el borrado de tuplas en la relación B: CREATE TRIGGER BORRADO_11_(1,1)_B BEFORE DELETE ON B FOR EACH ROW BEGIN *borramos la tupla correspondiente en A* DELETE FROM A WHERE cod_a=:old.cod_a END; La figura 7 (con X=1 e Y=0) muestra una interrelación de este tipo. La transformación seleccionada ha sido la de En este apartado se han expuesto todos los tipos de cardinalidades que se pueden dar en una interrelación binaria con el fin de sistematizar el paso de un esquema E/R a un esquema relacional. Este estudio forma parte de un proyecto más amplio, PANDORA3 (Plataforma CASE para el Aprendizaje y Desarrollo de Bases de Datos y su Enseñanza vía Internet), que incorporará un conjunto de herramientas imple- Figura 5: Interrelación 1:1 Figura 6: Transformación al modelo relacional de la fig.5 4.3.2. Cardinalidad (1,1),(0,1) NOVATICA jul./ago. 1999 nº140 33 Notas 1 En el caso de los disparadores expuestos en este artículo, el evento que activa el disparador está incluido dentro de una transacción que puede englobar, a su vez, subtransacciones en el cuerpo del disparador. 2 Otras posibles restricciones de cardinalidad, no tratadas en este artículo, son (0, Num1), (1, Num1), (Num1, N), (Num1,Num2) con Numi = 2,3,.... 3 Proyecto presentado a la convocatoria de la CICYT (TIC99-0215) Figura 7: Interrelación 1:1 mentadas con distintas tecnologías (sistemas expertos, procesamiento de lenguaje natural, etc.) que podrán ser utilizadas siguiendo un conductor metodológico aunque también se posibilitará su uso independiente para la realización de tareas específicas del desarrollo de BD (creación de esquemas conceptuales E/R de BD, transformación de esquemas conceptuales E/R a esquemas relacionales, normalización de relaciones, generación de código SQL-92,etc.). 6. Conclusiones En la actualidad disponemos de un prototipo denominado PROTEUS, Fernández (1998),que realiza la transformación de un esquema E/R a un grafo relacional, así como la generación de código SQL92 necesario para la creación de la base de datos incluyendo disparadores en el pseudocódigo anteriormente descrito. En esta propuesta se busca que el control de las restricciones semánticas se lleve a cabo en el SGBD y no en las aplicaciones, de esta forma conseguimos que la base de datos sea portable. Aunque en el código de los disparadores no se han incluido rutinas de error, serían convenientes para informar al usuario de las causas por las que no se ha podido realizar una determinada operación. Por otro lado, en esta propuesta minimizamos la pérdida de semántica en el tratamiento de las restricciones de cardinalidad de las interrelaciones binarias que se produce al pasar del análisis al diseño y del diseño a la implementación. Aunque también se ha realizado un estudio de las restricciones de cardinalidad en interrelaciones ternarias, por falta de espacio se deja su exposición para un posterior trabajo. 7. Referencias ACT-NET Consortium (1996), The ActiveDatabase Management System Manifesto: A Rulebase Of ADBMS Features. A Joint Report by the ACT-NET Consortium. ACM Sigmod Record 25 (3): 40-49,1996. Atkins (1996), Atkins, C. Prescription or Description: Some observations on the conceptual modelling process. Proceedings of International Conference on Software Engineering: Education and Practice, 1996. Chen (1976), Chen, P. The entity-relationship model - Toward a unified view of data. ACM Transactions on Database Systems, Vol. 1, N.1, pp. 9-36, 1976. De Miguel et al. (1999), De Miguel, A., Piattini, M. y Marcos, E. Diseño de Bases de Datos Relationales. Rama Ed, en prensa, 1999. Fernández (1998), Fernández D. PROTEUS: Traductor del modelo E/R al modelo relacional. Trabajo fin de carrera. Gray et al. (1993), Gray J., Reuter A. Transactions processing, concepts and techniques. San Mateo: Morgan Kaufmann, cop. 1993. ISO (1992), Database Language SQL. ISO/IEC 9075. Melton et al. (1993), Melton, J. Y Simon, A.R. Understanding the New SQL: A Complete Guide. Morgan Kaufmann. Orfali et al. (1999), Orfali R., Harkey D., Edwards J. Essential Client/Server Survival Guide. John Wiley & Sons, Inc. 3ª Edición. Tardieu (1989), Tardieu, H. La METHODE Merise. Paris:Editions d’Organisation, cop. 1989. 34 MONOGRAFIA NOVATICA jul./ago. 1999 nº140 Bases de Datos Avanzadas Ana Belén Martínez Prieto, Juan Manuel Cueva Lovelle Área de Lenguajes y Sistemas Informáticos. Departamento de Informática. Universidad de Oviedo Técnicas de Indexación para las Bases de Datos Orientados a Objetos <{belen,cueva}@pinon.ccu.uniovi.es> Resumen: en este artículo se presenta una clasificación de las técnicas de indexación para las bases de datos OO atendiendo a las características del modelo de objetos a las que pretenden dar soporte (jerarquías de herencia, de agregación e invocación de métodos), haciendo una breve descripción de algunas de dichas técnicas: SC, CH-Tree, H-Tree, Nested, Path, MultiIndex, Nested Inherited y Method Materialization. 1. Introducción Los sistemas de gestión de bases de datos orientadas a objetos (SGBDOO) deben su aparición principalmente, al surgimiento de nuevos tipos de aplicaciones para las que el modelo de objetos representaba mejor la semántica de la nueva información a almacenar. Los SGBDOO ya clásicos como ObjectStore, O2, Poet, Versant y GemStone, proporcionan soporte para lenguajes de consulta declarativos de alto nivel, ya que como se demostró en el modelo relacional, dichos lenguajes reducían substancialmente el tiempo de desarrollo de las aplicaciones. De hecho, el propio intento de estandarización lanzado por ODMG [1] propone un lenguaje de consulta (OQL). En la actualidad, coexistiendo con estos SGBDOO ya clásicos se encuentran los motores de almacenamiento persistente como complemento a los lenguajes de programación OO (C++ y Java, principalmente), tales como PSE Pro para Java [2] y Jeevan [3], que permiten también de alguna forma que se realicen consultas a la base de datos. De esto se deduce que es necesario incluir en estos productos (tanto los clásicos como en los más modernos) mecanismos, como los índices, que permitan acelerar el procesamiento de las consultas. 1.1. Lenguajes de Consulta OO Si nos centramos en los lenguajes de consulta orientados a objetos, conviene resaltar tres características que vienen directamente impuestas por el modelo de objetos (y que marcarán claramente las diferencias con los lenguajes de consulta relacionales): a) El mecanismo de la herencia (Jerarquías de Herencia). La herencia provoca que una instancia de una clase sea también una instancia de su superclase. Esto implica que, el ámbito de acceso de una consulta sobre una clase en general incluye a todas sus subclases, a menos que se especifique lo contrario. b) Predicados con atributos complejos anidados (Jerar- quías de Agregación). Mientras que en el modelo relacional los valores de los atributos se restringen a tipos primitivos simples, en el modelo orientado a objetos el valor del atributo de un objeto puede ser un objeto o conjunto de objetos. Esto provoca que las condiciones de búsqueda en una consulta sobre una clase se puedan seguir expresando de la forma <atributo operador valor>, al igual que en el modelo relacional, pero con la diferencia básica de que el atributo puede ser un atributo anidado de la clase. c) Predicados con invocación de métodos. En el modelo de objetos los métodos definen el comportamiento de los objetos y, al igual que en el predicado de una consulta puede aparecer un atributo, también puede aparecer la invocación de un método. 1.2. Clasificación de las Técnicas de Indexación en OO Las características anteriormente mencionadas exigen técnicas de indexación que permitan un procesamiento eficiente de las consultas bajo estas condiciones. Así, son muchas las técnicas de indexación en orientación a objetos que se han propuesto y que clásicamente [4] se pueden clasificar en: a) Estructurales. Se basan en los atributos de los objetos. Estas técnicas son muy importantes porque la mayoría de los lenguajes de consulta orientados a objetos permiten consultar mediante predicados basados en atributos de objetos. A su vez se pueden clasificar en: · Técnicas que proporcionan soporte para consultas basadas en la Jerarquía de Herencia. Ejemplos de los esquemas investigados en esta categoría son SC [5], CH-Tree [5], HTree [6], Class Division [7], hcC-Tree [8], etc. · Técnicas que proporcionan soporte para predicados anidados, es decir, que soportan la Jerarquía de Agregación. Ejemplos de los índices de esta categoría [9] son, entre otros, Nested, Path y Multiindex. · Técnicas que soportan tanto la Jerarquía de Agregación como la Jerarquía de Herencia. Nested Inherited [4] es un ejemplo de esta categoría. b) De Comportamiento. Proporcionan una ejecución eficiente para consultas que contienen invocación de métodos. La materialización de métodos (method materialization [10]) es una de dichas técnicas. En este campo no existe una proliferación de técnicas tan grande como en los anteriores. En la sección 2 se describen algunas técnicas que proporcionan soporte para consultas centradas en la jerarquía de herencia. Las consultas centradas en la jerarquía de agregación pueden emplear técnicas como las descritas en la sección 3. Cuando en una consulta se vean implicados NOVATICA jul./ago. 1999 nº140 35 objetos anidados y jerarquías de herencia, y se desee realizar una búsqueda en un único índice, se puede emplear la técnica descrita en la sección 4. Finalmente, en la sección 5 se describe una técnica que pretende acelerar el procesamiento de consultas que permiten la invocación de métodos. 2. Técnicas basadas en la Jerarquía de Herencia Estas técnicas se basan en la idea de que una instancia de una subclase es también una instancia de la superclase. Como resultado, el ámbito de acceso de una consulta contra una clase generalmente incluye no sólo sus instancias sino también las de todas sus subclases. Con el fin de soportar las relaciones de subclase-superclase eficientemente, el índice debe cumplir dos objetivos: - la recuperación eficiente de instancias de una clase simple; - la recuperación eficiente de instancias de clases en una jerarquía de clases. 2.1. Single Class (SC) La técnica Single Class fue una de los primeras en emplearse [5]. En esta técnica, la creación de un índice para un atributo de un objeto requiere la construcción de un árbol B+ para cada clase en la jerarquía indexada. Es la más tradicional, ya que su estructura es la de un árbol B+ típico, y además, mantiene la idea del modelo relacional de un índice para cada relación y atributo indexado. 2.2. CH-Tree Kim et al. [5] proponen un esquema llamado "Árbol de Jerarquía de Clases" (Class Hierarchy Tree- CH Tree) que se basa en mantener un único árbol índice para todas las clases de una jerarquía de clases. El CH-Tree indexa una jerarquía de clases sobre un atributo común, típicamente uno de los atributos de la superclase, sobre una estructura de un árbol B+. 2.2.1. Estructura La estructura del CH-Tree está basada en los árboles B+, y de hecho, el nodo interno es similar al de éstos. La diferencia está en los nodos hoja. Éstos contienen (figura 1): · Para cada clase en la jerarquía, el número de elementos almacenados en la lista de identificadores de objetos (IDOs) que corresponden a los objetos que contienen el valor-clave en el atributo indexado · La lista de IDOs Figura 2: Estructura de un H-Tree · Un directorio clave que almacena el número de clases que contienen objetos con el valor-clave en el atributo indexado, y, para cada clase, el identificador de la misma y el desplazamiento en el registro índice, que indica donde encontrar la lista de IDOs de los objetos. Es decir, el nodo hoja agrupa la lista de IDOs para un valorclave en términos de las clases a las que pertenecen. La búsqueda en un CH-Tree es similar a la de los árboles B+, de tal manera que, cuando el nodo hoja es localizado, se comparan los valores clave almacenados en el registro índice con la clave buscada. Si se encuentra, entonces, si en la consulta se referencia la jerarquía de clases completa, se devuelven todos los IDOs que aparecen en el registro índice. Por el contrario, si en la consulta se referencia sólo una clase, se consulta el directorio clave del registro índice para localizar los IDOs asociados con la clase. Esta técnica es empleada, por ejemplo, en el sistema ORION [11]. 2.3. H-Tree Representan una alternativa al CH-Tree propuesta en [6]. Se basan también en los árboles B+, y pueden verse como los sucesores de los índices SC. Esta técnica, se basa en mantener un H-Tree para cada clase de una jerarquía de clases, y estos H-Trees se anidan de acuerdo a sus relaciones de superclase-subclase. Cuando se indexa un atributo, el HTree de la clase raíz de una jerarquía de clases, se anida con los H-Trees de todas sus subclases inmediatas, y los H-Trees de sus subclases se anidan con los H-Trees de sus respectivas subclases, y así sucesivamente. Indexando de esta manera se forma una jerarquía de árboles de índices. 2.3.1. Estructura La estructura del H-Tree presenta variaciones tanto en el nodo interno como en el nodo hoja, con relación a los árboles B+ (figura 2). El nodo hoja contiene un contador que índica el número de IDOs que hay en la lista de identificadores de objetos cuyo valor en el atributo indexado es el valor-clave, y la propia lista de IDOs. Figura 1: Nodo hoja de un CH-Tree El nodo interno, aparte de los valores clave discriminantes y los punteros a los nodos hijos, almacena punteros que apuntan a subárboles de H-Trees anidados. Para reducir el NOVATICA jul./ago. 1999 nº140 36 recorrido innecesario del subárbol anidado, los valores máximos y mínimos del subárbol anidado se mantienen junto con el puntero a dicho subárbol. El anidamiento de los H-Trees evita la búsqueda en cada HTree cuando se consultan un número de clases de la jerarquía [12]. Cuando se busca en los árboles de una clase y sus subclases, se hace una búsqueda completa en el H-Tree de la superclase, y una búsqueda parcial en los H-Trees de las subclases. Esta es la principal ventaja con relación a los índices SC. Además, un H-Tree puede ser accedido, independientemente del H-Tree de su superclase, ya que la clase consultada no tiene porque ser la clase raíz de la jerarquía de clases, y por tanto, buscar instancias dentro de una subjerarquía de clases puede comenzar en cualquier clase siempre que esté indexada por el mismo atributo. El mayor inconveniente de esta estructura es la dificultad para dinamizarla. 2.4. Comparación : SC, CH-Tree y H-Tree Para consultas realizadas únicamente contra una clase, el SC se comporta mejor que el CH-Tree. Si por el contrario, se ven implicadas todas las clases de la jerarquía (o al menos dos clases de la misma) el CH-Tree se comporta mejor que un conjunto de SC. En cuanto al tamaño de los índices generados, no hay estudios suficientes que permitan concluir que uno sea mejor que otro. Estudios realizados demuestran también que el H-Tree se comporta mejor que el CH-Tree para consultas de recuperación, especialmente cuando un pequeño número de clases en la jerarquía son referenciados por la consulta, ya que el CH-Tree emplea la misma estrategia para la recuperación de datos de una clase simple que de una jerarquía de clases. Figura 4 :Instancias para la jerarquía de la Figura 3 es el nombre de una clase en H, A(1) es un atributo de la clase C(1), y A(i) es un atributo de una clase C(i) en H, tal que C(i) es el dominio del atributo A(i-1) de la clase C(i-1), 1< i ≤ n. Un ejemplo de camino para el esquema de la figura 3 puede ser P1=Vehículo.Fabricante.Nombre. Instanciación de un camino Dado un camino P = C(1).A(1).A(2)...A(n), una instanciación de P se define como una secuencia de n+1 objetos, denotados como O(1).O(2)...O(n+1), donde, O(1) es una instancia de la clase C(1), y O(i) es el valor de un atributo A(i-1) del objeto O(i-1), 1< i ≤ n+1. Por ejemplo, para el camino P1 una instanciación sería Vehículo[i]. Compañía[j].Renault. Instanciación Parcial 3. Técnicas basadas en la Jerarquía de Agregación Estas técnicas se basan en la idea de que las consultas en orientación a objetos soportan predicados anidados. Para soportar dichos predicados, los lenguajes de consulta generalmente proporcionan alguna forma de expresiones de camino. Camino Un camino es una rama en una jerarquía de agregación o, dicho formalmente, un camino P para una jerarquía de clases H se define como C(1).A(1).A(2)...A(n), donde C(1) Dado un camino P= C(1).A(1).A(2)...A(n), una instanciación parcial de P es definida como una secuencia de objetos O(1).O(2)...O(j), j< n+1, donde O(1) es una instancia de una clase C(k) en Class (P) para k=n-j+2, y O(i) es el valor del atributo A(i-1) del objeto O(i-1), 1< i ≤ j, y siendo Class(P) = C(1) {C(i) tal que C(i) es el dominio del atributo A(i-1) de la clase C(i-1), 1 < i ≤ n}. Atendiendo a los datos de la figura 4, una instanciación parcial del camino P1 sería Compañía[i].Fiat. Dada una instanciación parcial p= O(1).O(2)...O(j) de P, p es no redundante, si no existe una instanciación p’=O’(1).O’(2)...O’(k), k>j, tal que O(i) = O’(k-j+i), 1≤ i ≤j. Una instanciación parcial no redundante para P1 sería Compañía[m].Mercedes. 3.1.Índice Path (PX) Figura 3 : Jerarquía de clases de ejemplo Dado un camino P= C(1).A(1).A(2)...A(n), un índice Path (PX) sobre P es definido como un conjunto de pares (O,S), donde O es el valor clave, y S={π<j-1>(p(i)) tal que, p(i)=O(1).O(2)...O(j) es una instanciación no redundante (parcial o no) de P, y O(j) = O}. π<j-1>(p(i)) denota la proyección de p(i) sobre los primeros j-1 elementos. De esto se deduce que, un índice PX almacena todos los objetos que finalizan con esa clave. NOVATICA jul./ago. 1999 nº140 37 de IDOs de los objetos que contienen el valor clave en el atributo indexado, y la lista de IDOs. 3.3. Multiindex (MX) Figura 5 : Nodo hoja para un Indice Path Por ejemplo, para el camino P1 el índice PX contendrá los siguientes pares: · (Fiat,{Vehículo[k].Compañía[i]}) ·(Renault,{[Vehículo[i].Compañía[j], · Vehículo[j].Compañía[j]}) · (Mercedes,{Compañía[m]}) Un PX almacena instanciaciones de caminos, y como se puede observar, puede ser empleado para evaluar predicados anidados sobre todas las clases a lo largo del camino. 3.1.1. Estructura La estructura de datos base para este índice puede ser un árbol B, al igual que para los Nested y Multiindex, y de hecho el formato de los nodos internos es idéntico en los tres casos. La variación está en el nodo hoja. En el caso del índice PX, el nodo hoja (figura 5) contiene, entre otra información, el número de elementos en la lista de instanciaciones que tienen como objeto final el valor clave y la propia lista de instanciaciones. 3.2. Índice Nested (NX) Dado un camino P= C(1).A(1).A(2)...A(n), un índice Nested (NX) sobre P se define como un conjunto de pares (O,S), donde O es el valor clave, y S es el conjunto de IDOs de objetos de C(1) tales que O y cada IDO en S, aparecen en la misma instancia del camino. Es decir, un índice NX proporciona una asociación directa entre el primer y el último objeto de un camino. A diferencia del índice Path que almacena todos los objetos que finalizan con ese valor clave, en un índice Nested, sólo se almacenan los objetos iniciales de las instanciaciones de los caminos. Por ejemplo para el camino P1, el NX contendrá los siguientes pares: · (Fiat,{Vehículo[k]}) · (Renault,{Vehículo[i],Vehículo[j]}) Como se puede observar cuando n=1, el NX y el PX son idénticos y son los índices empleados en la mayoría de los SGBD relacionales. 3.2.1. Estructura El nodo hoja para el índice Nested es similar al del Multiindex, y simplemente almacena la longitud del registro, la longitud de la clave, el valor clave, el número de elementos en la lista Dado un camino P= C(1).A(1).A(2)...A(n), un Multiindex (MX) se define como un conjunto de n índices Nested (NX), NX.1, NX.2,... NX.n, donde NX.i es un índice Nested definido sobre el camino C(i).A(i), 1≤ i ≤ n. Por ejemplo, para el camino P1 el Multiindex consta de dos índices Nested. El primero, sobre el subcamino Vehículo.Fabricante, y contendrá los siguientes pares: · (Compañía[i],{Vehículo[k]}) · (Compañía[j],{Vehículo[i], Vehículo[j]}) El segundo índice es sobre el subcamino Compañía.Nombre, y contendrá los siguientes pares: · (Fiat,{Compañía[i]}) · (Renault,{Compañía[j]}) · (Mercedes,{Compañía[m]}). Esta técnica es empleada en el sistema GemStone. La razón de dividir un camino en subcaminos, es principalmente, para reducir los costos de actualización del NX o del PX, pero permitiendo a la vez una recuperación eficiente. En [13] se propone un algoritmo que determina si un camino debe ser dividido en subcaminos y también a qué subcaminos se les debe asignar un índice, así como la organización (NX, PX, etc.) que éste debería tener. 3.4. Comparación : NX, PX y MX Atendiendo a los experimentos realizados y expuestos en [9], se puede concluir que en cuanto a requerimientos de espacio, el NX siempre tiene los requerimientos más bajos. El PX requiere siempre más espacio que el MX, excepto cuando hay pocas referencias compartidas entre objetos, o bien no hay ninguna. Esto es debido a que el mismo IDO puede aparecer en muchas instancias de camino, ocasionando que ese IDO sea almacenado muchas veces. Si se examina el rendimiento con relación a consultas de recuperación, el NX es el que mejor se comporta, ya que el PX tiene un gran tamaño, pero este último se comporta bastante mejor que el MX, ya que éste necesita acceder a varios índices. Para consultas de actualización, el que mejor se comporta es el MX, seguido del PX y finalmente el NX. Para concluir, se puede decir que teniendo en cuenta las diferentes clases de operaciones (recuperación, actualización, inserción y borrado) el PX se comporta mejor que las otras dos estructuras. 4. Técnicas basadas en la Jerarquía de Herencia y de Agregación Estas técnicas de indexación proporcionan soporte integrado para consultas que implican atributos anidados de objetos y jerarquías de herencia. Es decir, permiten que una consulta que contiene un predicado sobre un atributo anidado e implica varias clases en una jerarquía de herencia dada, se solucione con una búsqueda en un único índice. NOVATICA jul./ago. 1999 nº140 38 · Es caro invocar un método, ya que eso ocasiona la ejecución de un programa y si esto tiene que realizarse sobre un conjunto grande de objetos ralentizará el procesamiento de la consulta. · La implementación de cada método está oculta (por la encapsulación del modelo OO), por lo que es muy difícil estimar el coste de su invocación en una consulta. La materialización de métodos es una técnica que pretende aliviar estos problemas. La idea básica consiste en calcular los resultados de los métodos accedidos frecuentemente, 'a priori', y almacenar los resultados obtenidos para emplearlos más tarde. Estructura Figura 6 :Formato de la tabla que almacena los datos materializados 4.1. Nested Inherited Dado un camino P= C(1).A(1).A(2)...A(n), un índice Nested Inherited (NIX) asocia el valor v del atributo A(n) con los IDOs de las instancias de cada clase en el ámbito de P que tienen v como valor del atributo anidado A(n). Entendiéndose por ámbito de un camino el conjunto de todas las clases a lo largo de un camino y todas sus subclases. 4.1.1. Estructura El formato de un nodo no hoja tiene una estructura similar a los índices tradicionales basados en árboles B+. Sin embargo, la organización del registro de un nodo hoja es similar al del CH-Tree, en el sentido de que hay un directorio dentro del registro del nodo hoja que asocia a cada clase el desplazamiento, dentro del registro, donde son almacenados los IDOs de las instancias de la clase. Sin embargo, un NIX puede ser empleado para consultar todas las jerarquías de clases encontradas a lo largo de un camino, mientras que un CH-Tree sólo permite consultar una única jerarquía de clases. Para más detalle sobre el nodo hoja ver [4]. La organización del índice consta de dos índices. El primero, llamado indice primario, que es indexado sobre los valores del atributo A(n). Asocia con un valor v de A(n), el conjunto de IDOs de las instancias de todas las clases que tienen v como valor del atributo anidado A(n). El segundo índice, llamado índice secundario, tiene IDOs como claves de indexación. Asocia con el IDO de un objeto la lista de IDOs de sus padres. Los registros del nodo hoja en el índice primario contienen punteros a los registros del nodo hoja del índice auxiliar, y viceversa. El índice primario es utilizado para las operaciones de recuperación, mientras que el índice secundario es empleado, básicamente, para determinar todos los registros primarios donde son almacenados los IDOs de una instancia dada, con el fin de realizar eficientemente las operaciones de inserción y borrado. 5. Materialización de Métodos El uso de métodos es importante porque define el comportamiento de los objetos, sin embargo, tiene dos efectos negativos desde el punto de vista del procesamiento y optimización de consultas: El resultado materializado de un método puede ser almacenado en una tabla con la estructura mostrada en la figura 6. El tamaño de esta tabla puede llegar a ser muy grande, con lo que se pueden crear índices para acelerar la velocidad de acceso a la misma. Cuando varios métodos para la misma clase tengan el mismo conjunto de argumentos, los resultados materializados de estos métodos pueden ser almacenados en la misma tabla, con lo que se necesita menos espacio, y si además estos métodos son referenciados en la misma consulta, sólo sería necesario acceder a una tabla para evaluar estos métodos, lo que se traduciría en un coste de procesamiento más bajo. Si los resultados de cada método referenciado en una consulta han sido precalculados, será mucho más fácil para el optimizador de consultas generar un buen plan de ejecución para la consulta. Eficiencia en las consultas de recuperación y Mayor costo en las consultas de actualización La materialización de métodos permite un procesamiento más eficiente de las consultas de recuperación, pero supone un costo más alto para las consultas de actualización, ya que una operación de actualización puede ocasionar que el resultado precalculado llegue a ser inconsistente con los datos actualizados. Una cuestión importante a tener en cuenta en la materialización de métodos es el manejo eficiente de este problema de inconsistencia. Así, cuando se borra un objeto, todas las entradas materializadas que usan ese objeto deben ser borradas y cuando un objeto existente es modificado todos los resultados materializados que usen el objeto modificado necesitan ser recalculados. Este proceso puede ser inmediato, o retrasado hasta que el resultado de la instancia del método sea necesario para evaluar la consulta (lazy materialization). En [10] se presentan además varias técnicas que permiten reducir el costo de mantenimiento de los métodos materializados. 6. Conclusiones Los mecanismos de indexación son extremadamente importantes para el procesamiento de consultas en BDOO. El objetivo de este artículo era describir brevemente algunas de las técnicas de indexación en OO ya clásicas, clasificadas en función de las características del modelo de objetos a las que pretenden dar soporte (agregación, herencia, métodos). No NOVATICA jul./ago. 1999 nº140 39 JH SC, CH-Tree, H-Tree, Class Division, ... Nested, Path, Multiindex, ... Nested Inherited, ... Method Materialization,... JA IM X X X X X JH- Jerarquía de Herencia ; JA- Jerarquía de Agregación; IM- Invocación de métodos Tabla 1: Clasificación de las técnicas de Indexación en OO en función de las características que soportan obstante, al ser la indexación un tema clave dentro de las bases de datos, existen más recientes investigaciones sobre el tema que no son abarcadas en este artículo pero a las que se puede acceder desde [14]. De lo expuesto en el artículo se deduce que, a pesar de que la proliferación en técnicas de indexación en OO es grande, no se puede concluir que una de ellas sea mejor que las demás en todas las situaciones, o al menos bajo las condiciones en las que han sido probadas. 7. Referencias [1] Cattell R., Barry D., Bartels D. The Object Database Standard: ODMG 2.0. Morgan Kauffman, 1997. [2] ObjectStore PSE and PSE Pro for Java. User Guide. http://www.odi.com http://www.odi.com, Marzo 1999. [3] Jeevan User’s Guide. http://www.w3apps.com http://www.w3apps.com, Marzo 1999. [4] Bertino E. y Foscoli P. Index Organizations for Object-Oriented Database Systems. IEEE Transactions on Knowledge and Data Engineering. Vol.7, 1995. [5] Kim W., Kim K.C., Dale A. Indexing Techniques for Object-Oriented Databases. En W. Kim y F.H. Lochovsky (ed): Object-Oriented Concepts, Databases, and Applications. Addison-Wesley, 1989. [6] Chin C., Chin B., Lu H. H-trees: A Dinamic Associative Search Index for OODB. ACM SIGMOD, 1992. [7] Ramaswamy S. y Kanellakis C. OODB Indexing by Class Division. ACM SIGMOD, 1995. [8] Sreenath B. y Seshadri S. The hcC-Tree: An Efficient Index Structure for Object Oriented Databases. International Conference on VLDB, 1994. [9] Bertino E. y Kim W. Indexing Techniques for Queries on Nested Objects. IEEE Transactions on Knowledge and Data Engineering. Vol.1 nº2, 1989. [10] Kemper A., Kilger C. y Moerkotte G. Function Materialization in Object Bases: Design, Realization, and Evaluation. IEEE Transactions on Knowledge and Data Engineering, 1994. [11] Kim W.,Garza J.F., Ballou N and Woelk D. Architecture of the ORION Next-Generation Database System. IEEE Transactions on Knowledge and Data Engineering, Marzo, 1990. [12] Chin B., Han J., Lu H. y Lee K. Index nesting - an efficient approach to indexing in object-oriented databases. VLDB Journal, 1996. [13] Bertino E. Index Configuration in Object Oriented Databases. VLDB Journal ,3, 1994. [14] SGBDOO para Oviedo3.http://www.uniovi.es/~oviedo3/belen/ bdoviedo3.html, Junio 1999. 40 MONOGRAFIA NOVATICA jul./ago. 1999 nº140 Bases de Datos Avanzadas Miryam Salas, Antonio Polo, Elena Jurado Departamento de Informática, Universidad de Extremadura, Cáceres Una revisión de los métodos de acceso multidimensionales <{miryam, polo}@unex.es> Este trabajo ha sido desarrollado dentro del proyecto IPR98A072 Resumen: numerosas aplicaciones surgidas en las últimas décadas están demandando sistemas que sean capaces de gestionar eficientemente grandes volúmenes de datos de dimensionalidad alta y de dar respuesta a todo tipo de consultas complejas, en especial consultas que incluyen múltiples atributos, consultas en rango, así como de tipo espacial y temporal. Para resolver estos problemas, en los últimos años han aparecido un gran número de métodos de acceso multidimensionales, cuyo objetivo es obtener un rendimiento similar al que presenta el índice B+ para el caso unidimensional. En este trabajo presentamos una panorámica general de los principales métodos, describiendo con mayor detalle los que consideramos que en su momento aportaron las ideas más novedosas. métodos de acceso multidimensionales que han surgido en los últimos años que pueda aportar una panorámica global de cuáles son los mecanismos y las estructuras básicas utilizadas y cuál ha sido su evolución. Palabras clave: Métodos de acceso multidimensionales, Mecanismos de indexación, Bases de datos multidimensionales, Índices multiatributo. 1. Introducción En los últimos años, aplicaciones cuyo uso ya es habitual, como los sistemas de información geográfica (GIS), diseño asistido por ordenador (CAD), aplicaciones multimedia y, más recientemente, el tratamiento de almacenes de datos (Data Warehousing) o de datos de tipo temporal están exigiendo sistemas que sean capaces de gestionar de manera adecuada no sólo grandes volúmenes de datos sino datos que incluyan una alta dimensionalidad. Los métodos de acceso unidimensionales, como el árbol B o sus variantes o los mecanismos de tipo hashing, se muestran incapaces de dar una respuesta eficiente a este tipo de requerimientos. Las necesidades actuales exigen estructuras de almacenamiento que sean capaces de responder eficientemente a consultas asociativas, por múltiples atributos, sin necesidad de que haya una preferencia en el orden de los mismos, consultas parciales y/o en rango o consultas de proximidad o cercanía. Además, estas estructuras deben adaptarse dinámicamente al crecimiento o disminución de la información de manera adecuada y ser capaces de gestionar grandes volúmenes de datos de alta dimensionalidad, obteniendo un rendimiento lo más cercano posible al del árbol B+. El diseño de estos métodos de acceso multidimensionales, sin embargo, resulta bastante complejo y ello se debe principalmente a que no existe un orden total definido en el espacio multidimensional que nos permita mantener la relación de proximidad entre los objetos almacenados. El objetivo de este trabajo es presentar una visión general de los Es preciso señalar que muchas de las ideas recogidas, principalmente en lo que se refiere a su clasificación, proceden de un amplio estudio realizado en [GAE98] y del tutorial [BER98]. Además, con el fin de no extendernos en la bibliografía final, remitimos al lector interesado en un método particular a la información bibliográfica de estos mismos trabajos. 2. Métodos de Acceso Multidimensionales: las ideas básicas En [GAE98] se resumen una serie de requerimientos que debería cumplir todo método de acceso, entre los que cabe destacar la simplicidad, independencia del orden de entrada y distribución de los datos, escalabilidad, soporte de un amplio rango de operaciones, uso eficiente del espacio de almacenamiento, eficiencia en tiempo de acceso, soporte para almacenamiento en memoria secundaria y terciaria, acceso concurrente y recuperación, y fácil integración en un sistema de base de datos tradicional, con impacto mínimo para el resto del sistema. Evidentemente, muchos de los métodos propuestos cumplen sólo algunos de los requerimientos y es difícil que puedan ser implementados en sistemas reales, pero la mayoría han supuesto un paso más en las investigaciones proponiendo ideas y mecanismos que posteriormente han podido ser aplicados en la resolución de otros problemas. Todos los métodos de acceso multidimensionales tienen en común el considerar o bien tuplas (registros), o bien objetos almacenados en el espacio multidimensional, donde cada atributo o campo (que se desee indexar) corresponde a una dimensión. Además, la estructura se construye mediante divisiones recursivas de este espacio de almacenamiento, hasta obtener subespacios con un número de tuplas (u objetos) tal, que permita que puedan ser almacenadas en una página de datos. Los diferentes mecanismos para realizar estas divisiones del espacio y la implementación de los mismos da lugar a distintos métodos. Dada la gran cantidad de estructuras existentes y la imposibilidad de abarcar todas en esta revisión, se clasifican por grupos con características comunes y se describen un poco más en profundidad las representativas de cada grupo. NOVATICA jul./ago. 1999 nº140 41 Figura 1 La primera clasificación que puede realizarse da como resultado dos grandes grupos: métodos de acceso que representan las divisiones del espacio mediante una estructura que debe mantenerse en memoria principal para obtener un mecanismo eficiente, y métodos de acceso que paginan también la estructura que representa el particionamiento del espacio, de tal manera que puede almacenarse en memoria secundaria. Estos últimos serían los únicos que se podrían tener en cuenta desde el punto de vista de los sistemas comerciales. 3. Estructuras multidimensionales basadas en memoria principal Las primeras estructuras multidimensionales que surgieron están pensadas para ser almacenadas en memoria principal. Obviamente, este requerimiento las hace inservibles en muchas aplicaciones donde el volumen de datos hace necesario utilizar memoria secundaria. Sin embargo, la importancia de estas estructuras radica en haber sido las primeras en considerar la posibilidad de indexación multidimensional y de hecho, las ideas que las sustentan han sido la base para el desarrollo de casi todas las estructuras posteriores. La tabla 1 resume las características de las principales estructuras y la figura 1 muestra gráficamente sus diferencias. Como puede observarse, el particionamiento del espacio se realiza por distintos procedimientos, pero el mecanismo usado es en esencia el mismo: dividir hasta conseguir regiones con un número de tuplas tal que puedan almacenarse en una única página de datos. El árbol que se obtiene no tiene que ser necesariamente balanceado, dependerá de la distribución de los datos y del orden de llegada de los registros. Las consultas se realizan comparando los valores buscados con la información almacenada en cada nodo y decidiendo por qué subárbol debemos seguir buscando. Comparativamente podemos encontrar métodos más ventajosos que otros en algunos aspectos. Así el k-d-tree [BEN75] será más adecuado que el Quad-tree [FIN74] para distribuciones no uniformes, ya que éste último, en este caso, puede dar lugar a muchas regiones vacías y el número de hijos del árbol también puede ser un problema si la dimensionalidad es alta. Sin embargo, el quad-tree parece favorecer más el paralelismo que el k-d-tree. El BSP-tree es más flexible que los anteriores pero necesita más almacenamiento y el BDtree [OHS83] presenta como novedad la identificación de regiones mediante secuencias de bits lo que mejora la eficiencia del procesamiento pero, por el contrario, la división regular del espacio no favorece el particionamiento en caso de distribucciones sesgadas. 4. Métodos basados en almacenamiento secundario Los métodos que se presentan en este apartado han sido diseñados para poder ser almacenados en memoria secundaria, de forma que las estructuras que les dan soporte están paginadas. En la figura 2 puede observarse una clasificación general de los mismos y la tabla 2 presenta un resumen de los métodos principales. No se muestran los mecanismos basados en hashing ya que por sus características especiales tienen una estructura que no puede compararse con el resto mediante esta tabla. Inicialmente, distinguimos entre métodos de acceso a puntos (MAP), que se basan en considerar las tuplas como puntos en el espacio, y métodos de acceso espacial (MAS), que consideran no sólo puntos sino objetos en su extensión NOVATICA jul./ago. 1999 nº140 42 k-d-tree adaptivo (Bentley, 1975) BSP-tree (Fuchs y otros, 1980) BD-tree (Ohsawa, Sakauchi, 1983) División espacio Por medio de Tipo de partición Representación Regiones del mismo nivel Relación Forma Identificación Hiperplanos paralelos ejes Hiperplanos cualquier orientación Hiperplanos paralelos ejes Irregular Árbol binario Disjuntas Rectangular Dimensión:valor Irregular Árbol binario Disjuntas Poliédrica Hiperplano:valor Regular Árbol binario Anidadas Rectangular agujereada Irregular Árbol dimensión d Disjuntas Rectangular Expresión-DZ (secuencias de bits) Punto Quad-tree regiones Puntos (Finkel, Bentley, 1974) Tabla 1.Estructuras en memoria principal espacial. Los métodos de acceso a puntos, sin embargo, como explican sus diseñadores, pueden utilizarse también para direccionar objetos espaciales realizando una transformación, ya sea usando el centro del objeto, los vértices o alguna otra característica. Entre todos los métodos, independientemente de que sean MAP o MAS, se pueden a su vez observar puntos en común y diferencias generales que permiten de algún modo clasificarlos, principalmente respecto a las características de las regiones a las que da lugar la subdivisión del espacio. 4.1.2. Métodos de acceso jerárquicos La mayoría están basados en el k-d-tree. Su principal característica es que su estructura está representada por un árbol, sea éste binario o no. Organizan los puntos de datos en una serie de regiones. Generalmente cada región corresponde a una página de datos que está almacenada como una hoja del árbol. Los nodos interiores del árbol corresponden a páginas de índice, y contienen árboles tipo k-d-tree con la información que permite guiar los procesos de búsqueda de arriba hacia abajo en la estructura. 4.1 Métodos de acceso a puntos Algunos de los métodos de acceso que se presentan están basados en la utilización de funciones de distribución de registros y otros están más próximos a estructuras arbóreas. También hay otros métodos que toman ideas de ambos mecanismos. 4.1.1. Métodos basados en "hashing" Los métodos de este tipo no han resultado muy adecuados a las necesidades multidimensionales, principalmente porque todos ellos sufren en mayor o menor grado de un crecimiento superlineal de lo que llaman el directorio y de dificultades para paginarlo. El método más conocido es el Grid File [NIE84]. Representa la división del espacio mediante una rejilla de d dimensiones, cuyas celdas no siempre tienen el mismo tamaño. La estructura está formada por las páginas de datos, donde están almacenadas las tuplas, el directorio, que está compuesto por las celdas y permite relacionar una o varias celdas con la misma página de datos, y las escalas, de las cuales existe una por cada dimensión y que mantienen información de las divisiones que se han realizado del espacio. Mientras las páginas de datos y el directorio se mantienen en memoria secundaria, las escalas deberían estar en memoria principal para garantizar un rendimiento óptimo. La figura 3 muestra un ejemplo de esta estructura. El problema del crecimiento del directorio se presenta porque cada división por un hiperplano que se produce a causa de un desbordamiento divide a todas las celdas que corta. Sus variantes (Excell, Two-level Grid File, y Twin Grid File) pretenden solucionar los problemas planteados pero no lo consiguen totalmente o provocan otros nuevos. Las operaciones, en general, se realizan de manera similar a como se hacen en un árbol B+. Tanto la inserción como el borrado requieren primero un proceso de búsqueda en el árbol hasta llegar al nivel más bajo. Si el registro a insertar no cabe en la página correspondiente, se procederá a la división, lo que hace que haya que modificar la información en el nivel inmediatamente superior, que también puede desbordarse y así el proceso de división puede propagarse hacia arriba en el árbol. El mecanismo de división de las páginas de índice y los problemas que pueden producirse derivados del mismo es lo que distingue básicamente a los distintos métodos. En este sentido, el hB-tree [LOM89] soluciona los problemas pendientes del K-D-B-tree y LSD-tree, proponiendo un mecanismo de división basado en varios hiperplanos previamente definidos en la página desbordada (extracción de un subárbol), y garantizando una ocupación mínima de las páginas de un tercio respecto del número de descendientes. El árbol Q [BAR95], usando las ideas básicas del hB-tree, consigue una estructura más homogénea aunque no puede garantizar una ocupación mínima de las páginas en todas las situaciones. Como ejemplo de este grupo de estructuras, en la figura 4 se representa un hB-tree. Una estructura ligeramente diferente es el BV-tree [FREE95]. No es realmente un método de accceso concreto, sino que representa un intento de generalizar las características del B-tree al caso multidimensional, proponiendo una serie de conceptos que pueden ser aplicados a otros métodos de accesos multidimensionales. Como puede observarse en la figura 5, las páginas de índice no almacenan árboles tipo kd-tree, sino una secuencia de regiones que están ordenadas jerárquicamente. NOVATICA jul./ago. 1999 nº140 43 Antecedente Tipo particion Árbol balanceado Regiones del mismo nivel Relación Forma Algunos problemas detectados Cubren universo MÉTODOS DE ACCESO A PUNTOS Jerárquicos K-D-B-tree (1981) k-d-tree adaptativo Irregular Sí Disjuntas Rectangular Sí LSD-tree (1989) k-d-tree adaptativo Irregular Casi Disjuntas Rectangular Sí hB-tree (1989) k-d-tree adaptativo Irregular Sí Q-tree (1995) BV-tree (1995) Híbridos Bang File (1987) k-d-tree adaptativo B-tree Irregular Irregular Grid file, BD-tree Regular Sí No Sí Disjuntas anidadas Rectangulares agujereadas Sí Disjuntas anidadas Rectangulares agujereadas Sí Disjuntas anidadas Cualquier forma Sí Se trata de mecanismos conceptuales aplicables a otros métodos pero no es un método implementado realmente Disjuntas anidadas Rectangulares agujeradas Sí Búsquedas exactas pueden requerir seguir varios cami nos; solución en versión posterior pero sin garanti zar la ocupación de las páginas Actualización frecuente de los límites de las regiones; la garantía de ocupación es de 2 entradas por nodo Buddy-tree (1990) Grid file Regular No Disjuntas Rectangulares No MÉTODOS DE AC-CESOESPACIALES Baja dimensionalidad R-tree (1984) B-tree Irregular Sí Solapadas Rectangulares No R*-tree (1990) R-tree Irregular Sí Solapadas mínimo Rectangulares No P-tree (1990) R-tree Irregular Sí Solapadas Poliédricas No GBD-tree (1990) BD-tree Regular No Solapadas Rectangular No R+-tree (1986) R-tree Irregular Sí Disjuntas Rectangulares No Cell-tree (1988) BSP-tree Irregular Sí Disjuntas Poliédricas Sí Alta dimensionalidad X-tree (1996) R-tree Irregular Sí Solapadas Rectangulares No SS-tree (1996) R-tree Irregular Sí Solapadas Esféricas No SR-tree (1997) R-tree Irregular Sí Solapadas Interseción de esféricas con rectangulares No Pyramid-tree (1998) Tabla 2. Estructuras en memoria secundaria Irregular División en cascada; no ga rantiza ocupación páginas Algoritmo de paginación complejo; no garantiza ocupación Piramidales Poca homogeneidad de la estructura; presencia de nodos multipadre Presencia de nodos multipadre; no se garantiza la ocupación de las páginas Búsquedas exactas por va rios caminos; actualización de los límites de las regiones Coste de reinserción de al objetos antes de división; coste de minimizarsolapa miento; los mismos del Rtree aunque se supone que habrán disminuido mucho Nodos más grandes, el or den puede decrecer; hay que limitar el número de vértices de las regiones Actualización de los límites de la región; búsquedas exactas varios caminos Redundancia de objetos; di visión en cascada; modifi cación de límites de regio nes; no está claro que se garantice la ocupación de las páginas Redundancia de objetos y alto particionamiento; mayor cantidad de almacenamiento para hiperplanos de división; no está claro que se garanti ce la ocupación de las páginas Falta de homogeneidad de la estructura; nodos pueden tener gran tamaño; mayor complejidad de la estructura Alto grado de solapamiento; búsquedas exactas por múltiples caminos; comple jidad de la estructura Solapamiento, aunque más reducido; búsquedas exactas por múltiples caminos; complejidad de la estructura Aún no existe documenta ción suficiente para su eva luación 44 NOVATICA jul./ago. 1999 nº140 Figura 2 4.1.3. Métodos híbridos Presentan características propias de métodos basados en hashing pero a la vez utilizan una estructura arbórea como base para la representación de la información. El más representativo es el Bang File [FREE87]. Este método realiza la división del espacio en intervalos regulares a la manera de un grid file, pero representa el directorio mediante una estructura arbórea balanceada. En realidad, la filosofía de división y representación de regiones mediante secuencias binarias tiene grandes similitudes con el BD-tree. NOVATICA jul./ago. 1999 nº140 45 Figura 3 Las hojas de la estructura arbórea del Bang File corresponden a páginas de datos y los nodos internos almacenan secuencias de regiones que son disjuntas o están contenidas unas en otras, y ordenadas para facilitar el proceso de búsqueda. Cada región está identificada por una secuencia de bits que indican la orientación de la región respecto a los sucesivos hiperplanos de división (como en el BD-tree), o por un *, que indica la región restante de la que han sido extraídas otras regiones representadas en el mismo nodo. La figura 6 muestra un ejemplo de esta estructura. Figura 4 4.2. Métodos de acceso espaciales La mayoría de los métodos tradicionales de este tipo no fueron ideados para ser usados con más de 3 dimensiones y sólo recientemente han surgido estructuras pensadas para una alta dimensionalidad. Una primera clasificación de los métodos se realiza en base a este criterio. La característica común que presentan estos métodos es que agrupan los objetos en regiones minimales, es decir, ajustadas a los objetos. Ahora bien, las características de estas 46 NOVATICA jul./ago. 1999 nº140 Figura 5 regiones difieren de unos métodos a otros, principalmente en lo que se refiere a su forma y a la relación que mantienen las que pertenecen al mismo nivel. nodos internos representan una sucesión de regiones minimales, cada una de las cuales controla un nodo en el nivel inferior. Este último criterio nos permite clasificar los métodos entre aquellos que representan el espacio mediante regiones solapadas y los que lo representan mediante regiones disjuntas; y un último grupo, el de múltiples capas, que en realidad es una extensión del primero. Las regiones del mismo nivel pueden solaparse y su unión no necesariamente cubre el universo completo. El árbol está balanceado en altura y se garantiza una ocupación mínima de los nodos. En años posteriores han surgido muchas variantes de esta estructura y se le ha dotado de concurrencia mediante los mismos mecanismos usados en los B-trees. Ahora bien, la estructura presenta algunos problemas, que no son exclusivos de la misma. La estructura pionera es el R-tree [GUT84] que ha servido de base a otros muchos métodos que surgieron al tratar de mejorar algunos aspectos del mismo. Es una estructura arbórea balanceada que representa una jerarquía de regiones rectangulares. Cada nodo del árbol corresponde a una página de datos. En los nodos hoja están almacenados un identificador para cada objeto y el mínimo rectángulo que lo contiene y los Figura 6 Todos los métodos que manejan regiones solapadas, R-tree, R*-tree, P-tree, etc., tienen el problema de que una búsqueda exacta puede tener que seguir varios caminos, aunque en algunas estructuras como el el R*-tree y el X-tree, el solapamiento se ha disminuido mucho pero el proceso de inserción resulta más complejo. Los métodos que manejan NOVATICA jul./ago. 1999 nº140 47 Figura 7 regiones disjuntas, R+-tree y Cell-tree, tienen que resolver el problema de la redundancia en el almacenamiento de objetos y de evitar el solapamiento cuando algunas regiones deben ser ampliadas durante el proceso de inserción. Desde el punto de vista de los sistemas comerciales, muy pocos han incorporado alguno de estos métodos de acceso. Como ejemplo excepcional podemos citar a Informix, que en 1997 apostó por los R-trees. Y en general, todos los métodos de este tipo, excepto el Celltree, manejan regiones minimales por lo que nuevas inserciones de objetos pueden producir actualizaciones en los límites de las regiones, aún cuando no haya desbordamiento de páginas. 6. Referencias y bibliografía básica En los últimos años han surgido métodos de acceso basados en las ideas del R-tree pero ideados para dimensionalidades muy altas. Tal es el caso del X-tree, SS-tree, SR-tree, Pyramid-tree, etc. Además, algunos presentan como novedad la forma de las regiones, que ya no es rectangular: el SStree maneja regiones esféricas, el SR-tree intersecciones de esferas y rectángulos y el Pyramid-tree pirámides. 5. Conclusiones En este trabajo hemos pretendido mostrar el estado del arte en relación con los métodos de acceso multidimensionales. Por supuesto, debido a limitaciones de espacio se ha realizado una breve revisión y no ha sido posible profundizar en los métodos presentados. Como resumen, podemos decir que la mayoría de los mecanismos que utilizan los métodos de acceso, en uno u otro sentido, pretenden generalizar el árbol B para el caso multidimensional, si bien las estructuras y los mecanismos de acceso que resultan son mucho más complejos. Además, aunque han aparecido multitud de métodos, resulta altamente difícil encontrar uno de ellos que sea claramente superior al resto en todos los sentidos. Las comparaciones realizadas entre ellos no muestran resultados concluyentes, por el gran número de parámetros que pueden medirse, los diferentes tipos de datos que pueden tratarse, las consultas tan variadas que pueden hacerse y la influencia del hardware, la programación, etc. [BAR95] Barrena, M., Técnicas de particionamiento multidimensional basadas en índices multiatributo en Bases de Datos Paralelas. Tesis Doctoral. Universidad Politécnica de Madrid, 1995. [BEN75] Bentley, J.L., Multi-dimensional binary search trees used for associative searching. Commun. ACM. Vol 18, nº 9. Septiembre 1995. [BER98] Berchtold, S., D. A. Keim, High-Dimensional Index Structures Database Support for Next Decade´s Applications. Proc. ACM SIGMOD Conf., Seattle, Washington (USA) , June 1998. [FIN74] Finkel, R., Bentley, A., Quad trees : a data structure for retrieval on composite keys, Acta Informática 4, 1974. [FRE87] Freeston, M., The BANG file: a new kind of grid file, ACM, 1987. [FRE95] Freeston, M., A General Solution of the n-dimensional B-tree Problem. ACM SIGMOD Conf., San Jose, CA USA, 1995. [GAE98] Gaede, V., Günter, O., Multidimensional Access Methods, ACM Computing Surveys, 30, 2. Junio 1998. [GUT84] Guttman, A., R-trees : a dinamic index structure for partial searching. Proc. ACM SIGMOD Conf., Boston 1984, pp. 47-57. [LOM90] Lomet, D., Salzberg, B., The hB-tree : A Multi-attribute Indexing Method with Good Guaranteed Performance. ACM Transactions on Database Systems, Vol. 15, nº 4, Diciembre 1990. [NIE84] Nievergelt, Hinterberger and Sevick, The grid file : an adaptable, simetric multikey file structure. ACM Trans. Database System, Vol. 9, nº 1, Marzo 1984. [OHS83] Ohsawa, Y., Sakauchi, M., BD-tree: A new n-dimensional data structure with efficient dynamic characteristic. Proc. 9th World Computer Congress, IFIP 1983, pp. 593-544. NOVATICA jul./ago. 1999 nº140 48 /DOCS/ El Código de Ética y Práctica Profesional de Ingeniería del Software de la ACM / IEEE-Computer Society Traducción: Javier Dolado Facultad de Informática de San Sebastián Universidad del País Vasco - Euskal Herriko Unibertsitatea. Socio de ATI <[email protected]> Introducción A continuación se presenta la traducción del Código de Ética y Práctica Profesional de Ingeniería del Software en su versión 5.2 (http://www.acm.org/serving/se/code.htm), tal como la ha recomendado el grupo de trabajo conjunto de la IEEE Computer Society/ ACM sobre ética en ingeniería del software y prácticas profesionales, dirigido por Donald Gotterbarn. Esta versión ha sido aprobada por la ACM (Association for Computing Machinery) y por la IEEE-CS (IEEE Computer Society) como el estándar para la enseñanza y la práctica de la ingeniería del software. Conviene mencionar que este código se ha propuesto tras varias versiones y después de revisar códigos de otras sociedades, que se han tenido en cuenta las opiniones de las encuestas aparecidas en conocidas revistas de estas sociedades y que se ha seguido el proceso de revisión formal del IEEE. La ACM aprobó el código en noviembre de 1998 y la IEEE Computer Society, en diciembre del mismo año. Los códigos de ética tienen una función esencial para caracterizar una profesión, y para que una disciplina adquiera el carácter de profesión debe poseer un código de conducta. Se pueden resumir las principales funciones de los códigos de ética en los siguientes apartados [Bowyer, 1996]: 1) simbolizar una profesión; 2) proteger los intereses del grupo; 3) inspirar buena conducta; 4) educar a los miembros de tal profesión; 5) disciplinar a sus afiliados; 6) fomentar las relaciones externas; 7) enumerar los principios morales básicos; 8) expresar los ideales a los que se debe aspirar; 9) mostrar reglas básicas de comportamiento; 10) ofrecer guías de comportamiento; 11) enumerar derechos y responsabilidades. Los códigos de conducta van más allá de la pura normativa legal, puesto que ayudan a guiar el comportamiento en infinidad de situaciones para las que no existe ninguna referencia legal. En el caso de la disciplina de “ingeniería del software”, la existencia de un código de ética específico posee cada vez más importancia, dada la relevancia que las actividades relacionadas con el software tienen en nuestra vida diaria. Puesto que en estos momentos se está hablando sobre la creación de los colegios de ingenieros en infor-mática en España, es pertinente considerar los códigos de conducta que sean aplicables a tales colegios profesionales. Gran parte de las tareas de los ingenieros en informática están relacionadas con el software, por lo que el código de la ACM/IEEE-CS que a continuación se muestra puede ser de gran utilidad para orientar la profesión en nuestro país. Preámbulo Los ordenadores poseen hoy en día una función básica cada vez mayor en comercio, industria, administración, medicina, educación, entretenimiento, relaciones sociales y vida diaria. Son ingenieros del software quienes contribuyen, mediante participación directa o enseñanza, al análisis, la especificación, el diseño, el desarrollo, la certificación, el mantenimiento y pruebas de sistemas de software. Debido a su papel en el desarrollo de estos sistemas, tienen suficientes oportunidades para aportar beneficios u ocasionar daños, o para influir en otros o permitir a otros hacer esto mismo Para garantizar, en la medida de lo posible, que sus esfuerzos se utilizarán en buenos modos, los ingenieros del software deben obligarse a hacer de su disciplina una profesión respetada y beneficiosa. De acuerdo con tal cometido, se adherirán al siguiente Código de Ética y Práctica Profesional. El Código contiene ocho Principios clave, relacionados con el comportamiento y las decisiones tomadas por los ingenieros del software profesionales, tanto si son profesionales en ejercicio, educadores, gestores, directivos y responsables, como si se trata de educandos y estudiantes. Los Principios identifican las diferentes relaciones en las que los individuos, grupos y organizaciones participan, y las principales obligaciones de tales relaciones. Las Cláusulas de cada Principio son la imagen de los diferentes niveles de obligación incluidos en esas relaciones. Estas obligaciones se fundamentan en las características humanas del ingeniero del software, en el especial cuidado al que está obligado con las personas que se ven afectadas por su trabajo y en los elementos peculiares de la práctica de la ingeniería del software. El Código prescribe estas exigencias como obligaciones de cualquiera que se identifique como ingeniero del software o que aspire a serlo. No se pretende que se utilicen partes individuales del Código aisladamente, para justificar errores por omisión o comisión. La lista de Principios y Cláusulas no es exhaustiva. Las Cláusulas no deben leerse como la frontera separadora entre lo aceptable y lo inaceptable en todas las situaciones posibles de la conducta profesional. El Código no es un simple algoritmo ético que genera decisiones éticas. En algunas situaciones los estándares pueden entrar en conflicto entre sí o con estándares de otras fuentes. Estas situaciones requieren que el ingeniero del software haga uso de su juicio ético para actuar de la manera que resulte más coherente con el espíritu del Código de Ética y Práctica Profesional, teniendo en cuenta las circunstancias. Las tensiones éticas se pueden manejar mediante una valoración cuidadosa de los principios fundamentales, mejor que apoyándose ciegamente en reglamentos detallados. Los Principios deberían ayudar a los ingenieros del software a considerar extensamente quién se ve afectado por su trabajo; a examinar si él o sus compañeros tratan al resto de las personas con el debido respeto; a reflexionar sobre cómo la sociedad consideraría sus decisiones si NOVATICA jul./ago. 1999 nº140 estuviera bien informada; a analizar cómo el menos favorecido quedará afectado por su decisión; y a considerar si un profesional ideal que trabajara como ingeniero del software estimaría que sus actos son valiosos. En todas estas valoraciones, la preocupación principal es la de la seguridad, la salud y el bienestar públicos; esto es, el “Interés Público” es esencial en este Código. El contexto dinámico y exigente de la ingeniería del software requiere que el código sea relevante y adaptable a las nuevas situaciones a medida que surjan. Sin embargo, incluso con esta generalidad, el Código proporciona apoyo a los gestores e ingenieros del software que necesiten actuar positivamente, documentando la postura ética de la profesión. El Código aporta un fundamento ético al que los individuos de un grupo o el propio grupo pueden acudir. El Código también ayuda a definir cuestiones cuya solicitud a un ingeniero o grupos de ingenieros del software es éticamente impropia. El Código no está simplemente orientado a identificar la naturaleza de los actos cuestionables, sino que también tiene una función educativa. Puesto que este código representa el consenso de la profesión en cuestiones éticas, es un medio para educar, tanto a la sociedad como a los futuros profesionales, acerca de las obligaciones éticas de todos los ingenieros del software. Principio 1: Sociedad Los ingenieros del software actuarán de manera coherente con el interés general. En particular, deberán, según sea adecuado: 1.01. Aceptar la completa responsabilidad de su trabajo. 1.02. Mitigar sus propios intereses, los del empresario, los del cliente y los de los usuarios con los del bienestar público. 1.03. Dar el visto bueno al software sólo si se tiene fundada creencia de que es seguro, de que cumple las especificaciones, de que ha pasado las pruebas pertinentes y de que no disminuye la calidad de la vida, la confidencialidad ni daña el medio ambiente. El efecto último del trabajo debería ser el bienestar público. 1.04. Revelar a las personas o 49 autoridades correspondientes cualquier peligro real o potencial para el usuario, la sociedad o el medio ambiente, peligro que razonablemente consideren que está asociado con el software o con documentos relacionados. 1.05. Cooperar en las materias relacionadas con preocupaciones graves causadas por el software, su instalación, mantenimiento, soporte o documentación. 1.06. Ser justos y veraces en todas las afirmaciones, especialmente en las que sean públicas, relativas al software o a documentos, métodos y herramientas relacionados. 1.07. Considerar las cuestiones de discapacidades físicas, asignación de recursos, desventajas económicas y otros factores que puedan disminuir el acceso a los beneficios del software. 1.08. Estar dispuestos a utilizar las capacidades profesionales para buenas causas y contribuir a la educación del público en general con respecto a su disciplina. Principio 2: Cliente y empresario Los ingenieros del software deberán actuar de tal modo que se sirvan los mejores intereses para sus clientes y empresarios, y consecuentemente con el interés general. En particular, deberán, según sea adecuado: 2.01. Proporcionar servicios sólo en las áreas de su competencia, siendo honestos y francos acerca de cualquier limitación que haya en su experiencia o educación. 2.02. No utilizar conscientemente software obtenido o retenido de manera ilegal o no ética. 2.03. Utilizar la propiedad de un cliente o patrón sólo de maneras adecuadamente autorizadas, y con el conocimiento y el consentimiento de éste. 2.04. Garantizar que cualquier documento en el que se confía ha sido aprobado, cuando así se requiera, por alguien con autoridad para hacerlo. 2.05. Mantener como privada cualquier información confidencial obtenida mediante el trabajo profesional, siempre que tal confidencialidad no sea inconsistente con los aspectos de interés general ni con la ley. 2.06. Identificar, documentar, recoger evidencia e informar con prontitud al cliente o al empresario si, en su opinión, existe la probabilidad de que un proyecto fracase, resulte demasiado caro, viole la legislación sobre propiedad intelectual o sea proble- mático. 2.07. Identificar, documentar e informar al empresario o al cliente sobre cualquier asunto de interés social, o del que se tenga conocimiento, acerca del software o de documentos relacionados. 2.08. No aceptar trabajo externo que vaya en detrimento de aquél que desarrollen para su principal contratante. 2.09. No representar interés contrario al del empresario o al del cliente, a menos que se comprometa otro valor ético más elevado; en este último caso se informará al empresario o a otra autoridad competente acerca de esa preocupación ética. Principio 3: Producto Los ingenieros del software deberán garantizar que sus productos y las modificaciones relacionadas con ellos cumplen los estándares profesionales de mayor nivel más que sea posible. En particular, deberán, según sea adecuado: 3.01. Promover la máxima calidad, un coste aceptable y un plazo razonable, garantizando que los compromisos significativos al respecto quedan claros, que el empresario y el cliente los aceptan y que están disponibles para consideración del usuario y del público en general. 3.02. Garantizar objetivos adecuados y alcanzables para cualquier proyecto en el que trabajen o vayan a trabajar. 3.03. Identificar, definir y examinar temas éticos, económicos, culturales, legales y medioambientales relacionados con cualquier proyecto. 3.04. Garantizar, mediante una conveniente combinación de educación, adiestramiento y experiencia, que están cualificados para cualquier proyecto en el que trabajen o vayan a trabajar. 3.05. Garantizar una metodología adecuada para cualquier proyecto en el que trabajen o vayan a trabajar. 3.06. Trabajar para seguir los estándares de la industria, si están disponibles, que sean los más adecuados para las tareas, desviándose de los mismos sólo cuando esté justificado ética o técnicamente. 3.07. Esforzarse para entender completamente las especificaciones del software que están desarrollando. 3.08. Garantizar que las especificaciones para el software sobre el que trabajan han sido bien documentadas, satisfacen los requisitos del NOVATICA jul./ago. 1999 nº140 50 usuario y tienen las aprobaciones pertinentes. 3.09. Garantizar estimaciones cuantitativas realistas de coste, plazos, personal y resultados de cualquier proyecto en el que trabajen o vayan a trabajar, y proporcionar una evaluación de la incertidumbre de esas estimaciones. 3.10. Garantizar unas pruebas, depuraciones y revisiones adecuadas del software y de los documentos relacionados en los que trabajen. 3.11. Garantizar una correcta documentación, incluyendo problemas significativos descubiertos y las soluciones adoptadas, para cualquier proyecto en el que trabajen. 3.12. Trabajar para desarrollar software y documentos relacionados que respeten la confidencialidad de aquéllos que van a verse afectados por ese software. 3.13. Ser cuidadosos para manejar sólo datos precisos, obtenidos mediante medios legales y éticos, y utilizarlos sólo de maneras debidamente autorizadas. 3.14. Mantener la integridad de los datos, siendo sensibles a aquéllos que estén obsoletos o equivocados. 3.15. Tratar todas las formas del mantenimiento del software con la misma profesionalidad que los nuevos desarrollos. Principio 4. Juicio Los ingenieros del software deberán mantener integridad e independencia en su valoración profesional. En particular, deberán, según sea adecuado: 4.01. Moderar todos los juicios técnicos por la necesidad de amparar y mantener valores humanos. 4.02. Firmar sólo los documentos preparados bajo su supervisión o dentro de sus áreas de competencia, y con los que están de acuerdo. 4.03. Mantener objetividad profesional con respecto a cualquier software o documentos relacionados para los que se les pida evaluación. 4.04. No involucrarse en prácticas financieras engañosas, tales como sobornos, dobles facturaciones u otras prácticas impropias. 4.05. Comunicar a todas las partes los conflictos de intereses que no puedan evitarse razonablemente. 4.06. Rechazar la participación, como miembros o asesores, en organismos privados, gubernamentales o profesionales vinculados con temas de software, en los que ellos, o sus patronos o clientes, tengan potenciales conflictos de intereses no revelados. Principio 5. Gestión Los gestores y líderes en ingeniería del software suscribirán y promoverán un enfoque ético a la gestión del desarrollo y el mantenimiento del software. En particular, los ingenieros de software en funciones de dirección o liderazgo deberán, según sea adecuado: 5.01. Garantizar una buena gestión en cualquier proyecto en el que trabajen, incluyendo procedimientos efectivos para promover calidad y reducción del riesgo. 5.02. Garantizar que se informa a los empleados de los estándares antes de adherirse a ellos. 5.03. Garantizar que los empleados conocen las políticas y los procedimientos del empresario para la protección de las claves de acceso, ficheros y otra información que sea confidencial para el empresario o para otros. 5.04. Asignar trabajo sólo después de tener en cuenta la educación y la experiencia, teniendo en cuenta el deseo de mejorar tal educación y experiencia. 5.05. Garantizar unas estimaciones cuantitativas realistas de coste, plazo, personal, calidad y productos en cualquier proyecto en el que trabajen o tengan intención de trabajar, y proporcionar una valoración de la incertidumbre de esas estimaciones. 5.06. Atraer empleados sólo mediante una descripción completa y precisa de las condiciones del trabajo. 5.07. Ofrecer una remuneración adecuada y justa. 5.08. No impedir injustamente a otro obtener la posición que merece de acuerdo con su cualificación. 5.09. Garantizar que hay un acuerdo correcto en lo referente a la propiedad de cualquier software, proceso, investigación, escrito, u otra propiedad intelectual a la que el ingeniero del software haya contribuido. 5.10. Proporcionar los medios correspondientes en caso de alegaciones de incumplimiento de la política del empresario o de este Código. 5.11. No pedir a un ingeniero del software hacer algo inconsistente con este Código. 5.12. No castigar a nadie por expresar preocupaciones éticas sobre un proyecto. Principio 6. Profesión Los ingenieros del software deberán progresar en la integridad y la reputación de la profesión, coherentemente con el interés general. En particular, deberán, en la medida de lo posible: 6.01. Ayudar a desarrollar un ambiente organizativo favorecedor de un comportamiento ético. 6.02. Promover el conocimiento general de la ingeniería del software. 6.03. Diseminar el conocimiento de la ingeniería del software mediante la participación en organizaciones profesionales, reuniones y publicaciones. 6.04. Apoyar, como miembros de una profesión, a otros ingenieros que se esfuercen en seguir este Código. 6.05. No promover el interés propio a costa de la profesión, el cliente o el empresario. 6.06. Obedecer todas las leyes que gobiernen su trabajo, a menos que, en circunstancias excepcionales, tal cumplimiento sea inconsistente con el interés general. 6.07. Ser precisos en la descripción de las características del software en el que trabajan, evitando, no sólo falsas declaraciones, sino también aquéllas otras que razonablemente podrían suponerse especulativas, vacías, decepcionantes, engañosas o dudosas. 6.08. Tener la responsabilidad de detectar, corregir e informar errores en el software y documentos asociados en los que trabajen. 6.09. Asegurarse de que los clientes, patronos y gerentes conocen la obligación del ingeniero del software con respecto a este Código de ética, y las ramificaciones subsecuentes de tal obligación. 6.10. Evitar asociaciones con empresas y organizaciones que estén en conflicto con este código. 6.11. Considerar que las inobservancias de este Código son inconsistentes con ser un ingeniero del software profesional. 6.12. Expresar las preocupaciones a las personas implicadas cuando se detecten incumplimientos significativos de este Código, a menos que sea imposible, contraproducente o peligroso. 6.13. Informar sobre las vulneraciones de este Código a las autoridades pertinentes cuando esté claro que sea imposible, contraproducente o peligroso consultar a las personas implicadas en estas inobservancias. NOVATICA jul./ago. 1999 nº140 Principio 7. Compañeros Los ingenieros del software serán justos y apoyarán a sus compañeros. En particular, deberán, según sea apropiado: 7.01. Animar a los compañeros a adherirse a este Código. 7.02. Ayudar a los compañeros en el desarrollo profesional. 7.03. Reconocer completamente el trabajo de otros y abstenerse de atribuirse méritos que no son propios. 7.04. Revisar el trabajo de los demás de forma objetiva, sincera y convenientemente documentada. 7.05. Tratar justamente las opiniones, preocupaciones o quejas de un compañero. 7.06. Ayudar a los compañeros en el conocimiento completo de los estándares de trabajo, incluyendo políticas y procedimientos para proteger claves de acceso, ficheros y otra información confidencial, y medidas de seguridad en general. 7.07. No interferir injustamente en la carrera profesional de un compañero; sin embargo, la preocupación por el empresario, el cliente o el interés público puede exigir, con buena voluntad, a cuestionar la competencia de un compañero. 7.08. En las situaciones que quedan fuera de las áreas de competencia personales, consultar las opiniones de otros profesionales que tengan competencia en ese área. Principio 8. Persona Los ingenieros del software deberán participar en el aprendizaje continuo de la práctica de su profesión y promoverán un enfoque ético en ella. En particular, deberán continuamente preocuparse de: 8.01. Mejorar su conocimiento de los avances en el análisis, la especificación, el diseño, el desarrollo, el mantenimiento y pruebas del software y documentos relacionados, junto con la gestión del proceso de desarrollo. 8.02. Mejorar su capacitación para crear software de calidad, seguro, fiable y útil, con un coste y en un plazo razonables. 8.03. Mejorar su capacidad para producir documentación precisa informativa y correctamente escrita. 8.04. Mejorar su comprensión del software y documentos relacionados en los que trabajan y del entorno en el que se utilizarán. 51 8.05. Mejorar su conocimiento de los estándares pertinentes y de las leyes que regulan el software y los documentos relacionados en los que trabajan. 8.06. Mejorar su conocimiento de este Código, su interpretación y su aplicación al trabajo. 8.07. No dar un tratamiento injusto a nadie por prejuicios irrelevantes. 8.08. No influir a otros para emprender acción alguna que conlleve el incumplimiento de este Código. 8.09. Reconocer que las inobservancias personales de este Código son inconsistentes con ser un ingeniero del software profesional. Agradecimientos El autor de esta traducción agradece la revisión de Mª José Rueda y los comentarios de F. Javier Herrera. Parte de este trabajo se ha realizado bajo los proyectos UPV-EHU 141.226-EA083/ 98 y CICYT TIC 98 1179-E. Bibliografía Kevin W. Bowyer, Ethics and computing: living responsibly in a computerized world, IEEE Computer Society Press, Los Alamitos, California, 1996. D. Gotterbarn, “The ethical software engineer”, The Institute, vol. 23, nº. 2, p. 2, febrero de 1999. IEEE, The IEEE Ethics Committee, http://www.ieee.org/committee/ethics 52 SECCIONES TÉCNICAS NOVATICA jul./ago. 1999 nº140 Informática Gráfica J. Lluch, M. Chover**, R. Quirós**, R. Vivó * Dpto. de Sistemas Informáticos y Computación, Universidad Politécnica de Valencia **Dpto. de Informática, Universidad Jaume I <[email protected]> <[email protected]> Resumen: en todos los campos de la ciencia se utilizan los modelos para describir distintos aspectos de una entidad concreta o abstracta. Dentro de los distintos modelos usados habitualmente en informática gráfica, los modelos fractales y procedurales están experimentando un auge notable durante los últimos años. El presente trabajo se ubica en esta línea, mostrando la relación existente entre las técnicas de sustitución geométrica y los sistemas de reescritura. Para ello se ha diseñado una aplicación que permite generar patrones de textura aplicando distintas reglas de sustitución geométrica interactivamente. El usuario introduce un polígono de partida que define la base del patrón, añadiendo sobre él una serie de polígonos y sustituyendo unos por otros aplicando reglas de sustitución geométrica. Los diseños obtenidos pueden ser utilizados para la obtención de representaciones realistas de azulejos, productos textiles, cerámica, etc. Palabras clave: modelado geométrico, sustitución geométrica, sistemas de reescritura, texturas, diseño de patrones. Sustitución Geométrica Interactiva mediante Sistemas Paramétricos Aleatorios sencilla, intuitiva y compacta. Para una mayor información se puede consultar un interesante artículo [GLASS92] donde se describen los diferentes métodos de sustitución existentes. La idea consiste en crear un patrón inicial o base y añadirle nuevos detalles mediante la inclusión de una serie de polígonos que a su vez pueden ser sustituidos por otros. Para ello se aplican dos conceptos: sistemas de reescritura y sustitución geométrica. Los sistemas de reescritura, y en concreto los sistemas-l [LIND74] [PRUS90], permiten obtener una representación en forma de cadenas de caracteres de las acciones que provocan los cambios en los patrones al aplicarles reglas de reescritura. La sustitución geométrica define las reglas que se pueden aplicar a un patrón geométrico para que cambie su estructura. Este cambio se refleja en la composición y disponibilidad de los polígonos que lo integran. De esta manera, al aplicar sustituciones se pueden derivar nuevos patrones de formas geométricas muy variadas. La aplicación que se presenta permite la creación de un patrón que comienza a partir de un polígono base, al cual se le pueden añadir nuevos polígonos en su interior de dos formas distintas: conectando ciertos puntos clave o aplicando reglas de sustitución geométrica. Para facilitar la sustitución de unos polígonos por otros se permite el manejo de librerías de reglas. De esta modo, se puede escoger la regla de sustitución deseada y aplicarla, o bien crear nuevas reglas para utilizarlas posteriormente. Además se ha dotado a la aplicación de las siguientes características: visualización de una muestra del patrón y la posibilidad de almacenar su imagen en un fichero gráfico de modo que pueda ser utilizado, por ejemplo, como textura por otra aplicación. Todas estas características hacen que la aplicación desarrollada sea una herramienta muy útil para la comprensión del proceso de sustitución geométrica. 2. Conceptos básicos 1. Introducción Un importante problema de los gráficos por computador es la creación de modelos complejos y expresivos. Una de las formas de crear estos modelos es comenzar con uno simple y refinarlo hasta llegar al detalle deseado. Este concepto se puede aplicar también al diseño de patrones en 2D que posteriormente pueden ser utilizados para texturar superficies. El trabajo que se presenta utiliza los sistemas de sustitución geométrica consistentes en la aplicación de una serie de reglas a una geometría de entrada con el fin de obtener objetos más complejos o estéticos de una forma La aplicación de los sistemas de reescritura en el diseño de patrones se basa en la obtención de cadenas de símbolos, que posteriormente podrán ser interpretadas gráficamente para obtener una representación en pantalla. A continuación se introducen, brevemente, los conceptos de reescritura y sustitución geométrica. 2.1. Sistemas de reescritura Los sistemas de reescritura están basados en una técnica consistente en la definición de objetos complejos mediante NOVATICA jul./ago. 1999 nº140 la sustitución sucesiva de partes de un objeto simple inicial utilizando un conjunto de reglas de reescritura, también llamadas producciones. Se pueden utilizar para generar imágenes de dos formas distintas. En primer lugar, operando directamente sobre los objetos, tales como vectores, grafos o formas; en segundo lugar, las gramáticas pueden utilizarse para definir cadenas de símbolos que posteriormente se interpretan gráficamente para convertir las cadenas en imágenes. En este trabajo nos centraremos en este último concepto. Sistemas Paramétricos Aleatorios Los Sistemas Paramétricos Aleatorios [LLUC93] son una extensión de los Sistemas-L Paramétricos en los que se incluye la posibilidad de definir un conjunto de variables aleatorias que toman valores en un espacio de probabilidad según una función de distribución determinada [JONE91]. Utilizando expresiones aritméticas y lógicas que combinen los parámetros asociados a los símbolos del alfabeto con las variables aleatorias definidas se consigue que las cadenas generadas por un mismo sistema sean distintas, así como la posibilidad de controlar las variaciones que se produzcan. Al igual que en los Sistemas-L Paramétricos [LIND74] [PRUS86] [PRUS90] se van a utilizar cadenas paramétricas, que son una lista de módulos formados por símbolos con una serie de parámetros asociados. Los símbolos pertenecen al alfabeto V y los parámetros son números Reales. Un módulo cuyo símbolo sea AV y cuyos parámetros sean a1,a2,...,an ∑, donde ∑ es el conjunto de los números Reales, se denota por A(a1,a2,...,an). Cada módulo pertenece al conjunto M = Vx∑*, donde ∑* representa el conjunto de todas las secuencias finitas de los parámetros, por lo tanto el conjunto de todas las cadenas de módulos se representa por M* y el conjunto de las cadenas no vacías por M+. Si Σ es el conjunto de parámetros formales del sistema, ϑ es el conjunto de variables aleatorias diremos que C(Σ,ϑ) es una expresión lógica que contiene elementos de Σ y ϑ, y E(Σ,ϑ) es una expresión aritmética con elementos de Σ y ϑ. Ambas expresiones están formadas por parámetros formales, variables aleatorias y constantes numéricas, combinadas utilizando operadores aritméticos, relacionales, lógicos, paréntesis y funciones, evaluándose a cierto la expresión lógica vacía. Si C(Σ,ϑ) y E(Σ,ϑ) representan a los conjuntos de todas las expresiones lógicas y aritméticas respectivamente, se define un Sistema Paramétrico Aleatorio como: G<V,Σ,ω,P,ϑ>, donde: · V es el conjunto de símbolos del sistema. · Σ es el conjunto de parámetros formales. · ω M+ es una cadena no vacía llamada axioma. · P (V x Σ*) x C(Σ,ϑ) x ( V x E(Σ,ϑ)*)* es un conjunto finito de producciones. · ϑ es el conjunto de variables aleatorias. Los símbolos : y ♦ se utilizan para separar las tres componentes de una producción: el predecesor, la condición y el sucesor. Una producción coincide con un módulo de una cadena paramétrica si el carácter del módulo y el carácter del predecesor coinciden, el número de parámetros actuales del módulo coincide con el número de parámetros formales del 53 SYSTEM DECLARATIONS claseVariable nombreVariable = tipoVariable(parámetro[,parámetro...]) ... AXIOM axioma RULES predecesor : condicionLógica ® sucesor ... END. Figura1: Sintaxis de un SPA predecesor y la condición se evalúa a Cierto sustituyendo los parámetros actuales en los formales de la producción. Una producción que coincide puede aplicarse al módulo, generando la cadena de módulos definida por el sucesor de la producción. Los parámetros actuales se sustituyen en los formales de acuerdo a su posición. Al realizar esta sustitución se genera un valor real para cada una de las variables aleatorias implicadas en las expresiones correspondientes a los parámetros actuales. Cada variable se distribuye en un espacio de probabilidad de acuerdo a su función de distribución, mediante la cual se calcula su valor actual. Por ejemplo, la producción: A(t) : ε ♦ A(t+n) donde ε es la expresión lógica vacía (que se evalúa a cierto) y n una variable aleatoria continua, definida mediante una distribución Uniforme en el rango de extremo inferior -1.0 y extremo superior 1.0, puede aplicarse al módulo A(10.0) para generar el módulo A(10.0+r) donde r es el valor actual de la variable n, comprendido entre (-1.0,1.0). El valor final de r no es determinable a priori, pero se conoce la forma en que se distribuye.(Ver sintaxis figura 1) 2.2. Sustitución geométrica La sustitución geométrica se basa en la aplicación de reglas de reescritura que pueden ser locales o globales. Las reglas locales se dividen en dos tipos denominados de clonación y de mutación. Una regla de clonación sustituye la geometría de entrada por una o más formas geométricas, cada una de ellas similar a la de entrada (Ver figura 2). Las reglas de mutación pueden sustituir la geometría de entrada por cualquier polígono (Ver figura 3). En un contexto poligonal, como en este trabajo, que la estructura sea similar implica que el nuevo polígono tendrá el mismo número de aristas que el polígono de entrada. Las reglas de mutación consisten en la sustitución del polígono de entrada por una nueva geometría derivada de Figura 2: Reglas de clonación NOVATICA jul./ago. 1999 nº140 54 Figura 3: Reglas de mutación una plantilla. A diferencia de las reglas de clonación, la nueva geometría no tiene porque tener ninguna similitud con la inicial. Los resultados obtenidos al aplicarlos a un conjunto de polígonos conectados son sorprendentes y no parecen derivados de la plantilla. Los tipos de reglas analizados se pueden mezclar para obtener resultados muy atractivos visualmente. Se pueden combinar distintas reglas de clonación entre sí, o reglas de clonación y de mutación, etc. También se puede aplicar la misma regla a todos los polígonos de entrada a la vez o distintas reglas a cada polígono, obteniéndose resultados diferentes. 3. Sustitución geométrica mediante sistemas de reescritura Si partimos de un polígono que sería la base del patrón como cadena de entrada del sistema o axioma, podemos aplicar al patrón una serie de producciones definidas en una gramática. De esta forma, partiendo de la cadena de símbolos que forman el axioma, obtenemos otra en la que de forma simultánea se han sustituido aquellos símbolos de la cadena de entrada que coinciden con el predecesor de alguna regla. Si se realiza esta operación de forma sucesiva se puede obtener una cadena con aquellos símbolos resultantes de aplicar las distintas producciones en el orden deseado. El modelo utilizado para representar un patrón define a éste como un conjunto de polígonos y éstos a su vez vienen representados por una serie de vértices. Pues bien, son estos vértices los que se utilizan como parámetros actuales y cada uno de ellos está formado por unas coordenadas de la forma (xj,yj)∑ donde 1≤j≤n indica el número de vértice y n el número de vértices del polígono respectivamente. Tanto el axioma como el predecesor y sucesor son módulos [QUIR92] formados por un símbolo del alfabeto que lleva asociado más de un parámetro formal, separados por comas. Concretamente, el mínimo número de parámetros será de 6 ya que según lo expuesto, cada vértice implica dos coordenadas (x,y) y para crear un polígono cerrado se necesitan un mínimo de tres vértices. Por otra parte, tanto el axioma como el predecesor se compondrán de un solo módulo mientras que el sucesor podrá contener más de uno. El sucesor se compone de módulos formados por un símbolo del alfabeto al que se le asocian parámetros formales o expresiones que contengan a todos ellos (figura 4). 4. Implementación La aplicación se ha dividido en módulos de forma que cada uno Figura 4: Ejemplo de producción de ellos define el comportamiento de cada una de las clases desarrolladas, cuya estructura se muestra en la figura 5. La aplicación permite la creación de reglas mixtas, ya que es el propio usuario quien puede diseñarlas a su gusto. Este tipo de reglas sustituyen la geometría de entrada por otra geometría que puede tener cualquier forma, es decir son una mezcla de las reglas de clonación y mutación. Los patrones generados con esta aplicación se pueden almacenar en distintos formatos gráficos (BMP, TGA, etc.), para ser utilizados posteriormente como patrones de textura. Edición de reglas La edición de reglas se realiza interactivamente y de forma gráfica. El usuario define el polígono correspondiente al predecesor de la regla y posteriormente el o los polígonos en los que se sustituye, creando el sucesor de la regla. (Ver figura 6). Una vez se han introducido tanto el predecesor como el sucesor de la regla, la aplicación creará la cadena de caracteres correspondiente a la producción definida. Obtención de la subcadena predecesor El algoritmo que realiza esta tarea es el que se muestra a continuación, el cual recibe una lista de los vértices del polígono predecesor y devuelve una cadena que representa al predecesor. Funcion Predecesor (lVerts ListaVerticesPredecesor) nv Entero; pred Cadena; Comienzo nv = Número de vértices de polígono predecesor Inicializar cadena pred = “POL” + nv + “(“ Para cada vértice del polígono predecesor hacer · obtener cadena “xj,yj” con j el número de vértice · concatenar dicha cadena a la del predecesor pred · Si no es último vértice entonces concatenar a pred “,” fsi fpara concatenar a pred “)” devolver pred ffuncion Obtención de la subcadena sucesor (x2,y2) POL3(x1,y1,x2,y2,x3,y3) : (NumIt = 1) ♦ POL3((x1+x2)/2,(y1+y2)/2,(x2+x3)/2, (y2+y3)/2, (x1+x3)/2,(y1+y3)/2) (x1,y1) Figura 5 (x3,y3) El siguiente algoritmo muestra cómo se construye una cadena que representa la parte sucesor de una regla, el cual recibe como parámetros el polígono predecesor y una lista de polígonos que forman la parte sucesor y devuelve una cadena que representa al sucesor. NOVATICA jul./ago. 1999 nº140 55 Figura 6: Diálogos de edición y de carga de reglas de sustitución Funcion Sucesor (polPred Poligono, lPolSust ListaPolSuc) nv Entero; /* número de vértices de pPolInt */ pPolInt Poligono; /* polígono que se analiza de la lista de sucesores */ subregla, /* módulo obtenido en cada instante */ succRegla Cadena; /* cadena sucesor de la regla */ Comienzo succRegla = cadena vacía Para cada polígono sucesor Î lPolSust hacer pPolInt = polígono de la lista lPolSust nv = número de vértices de pPolInt Inicializar cadena subregla = “POL” + nv + “(“ Para cada vértice de pPolInt hacer · calcular ecuación de la recta del vértice respecto del polígono predecesor · convertir ecuación obtenida a una cadena · concatenar dicha cadena a subregla fpara concatenar “)” a subregla concatenar subregla a succRegla fpara devolver succRegla ffuncion Una vez que se tienen las dos subcadenas anteriores se concatenan en una sola que constituye una regla del Sistema-L Paramétrico. Entrada/Salida de reglas Las reglas generadas por la aplicación se pueden almacenar en librerías para su posterior utilización en la generación de patrones. (Ver figura 6) Generación de patrones Una vez generadas las reglas y almacenadas en la librería, estas pueden aplicarse en el orden que se desee para generar un patrón. El patrón obtenido puede almacenarse como una imagen o de forma más compacta mediante la descripción de su sistema paramétrico. La gramática resultante es determinista, ya que el usuario indica las reglas a aplicar en secuencia. Para obtener patrones aleatorios basados en el patrón diseñado en la aplicación, basta con incluir variables aleatorias y utilizar el derivador de cadenas definido en otros trabajos [QUIR92] [LLUC93]. Esta aleatoriedad se muestra como ruido o modificaciones en la secuencia de aplicación de las reglas. El algoritmo utilizado para realizar las sustituciones se muestra a continuación. Algoritmo AplicaRegla; polig Poligono; /* polígono a sustituir */ pLSust ListaPoligonos; /* lista de polígonos que sustituyen a polig */ nVertsPred Entero; /* número de vértices de polig */ Para todo polígono polig patrón hacer nVertsPred = número de vértices de polig Si nVertsPred = número de vértices del polígono predecesor de la regla entonces /* transformar coordenadas de políg. sucesores de la regla para que dependan del polígono a susti tuir*/ pLSust = lista vacia Para todo polígono pol Î sucesor de la regla hacer · transformar coordenadas de pol · insertar nuevo pol en pLSust fpara reemplazar polig por pLSust fsi fpara ffuncion 5. Resultados Con el fin de aplicar todos los aspectos teóricos comentados anteriormente y comprobar el correcto funcionamiento de la aplicación (Ver figura 7) se han realizado una serie de pruebas consistentes en la generación de varios patrones. En ellos se puede observar la diversidad de formas geométricas que se pueden crear así como la evolución que aparece al aplicar sucesivas reglas de sustitución. A continuación se presentan resultados obtenidos al aplicar a un patrón reglas de sustitución de distinto tipo (imágenes 1, 2 y 3) y la aplicación de estos patrones (imagen 4). 6. Conclusiones y trabajos futuros En el presente trabajo se ha podido comprobar el gran potencial de los sistemas de reescritura y de la sustitución NOVATICA jul./ago. 1999 nº140 56 · Inclusión de reglas de sustitución global que modifican completamente la estructura sin tener en cuenta las relaciones de conectividad entre los vértices involucrados (funciones de Ruido). · Posibilidad de utilizar los vértices de definición de los polígonos como puntos de control de curvas paramétricas. · Ampliación del modelo de sustitución geométrica a tres dimensiones para la representación de elementos naturales (estructuras de cristales, corales, etc.). 7. Bibliografía Figura 7: Partes de la ventana principal de la aplicación geométrica en el campo del diseño de patrones de textura. El proceso se realiza de forma intuitiva y amigable, y la representación interna de los patrones es muy compacta. La utilización de sistemas paramétricos aleatorios permite también obtener patrones irregulares asignando distintas probabilidades a la aplicación de reglas de sustitución. Entre las posibles ampliaciones que se podrían realizar a la aplicación es interesante destacar las siguientes: [GLASS92] Andrew S.Glassner, Geometric Substitution: A Tutorial, IEEE Computer Graphics and Applications, 1992, Enero, pag. 22-36. [JONE91] Huw Jones, D. Saupe, "Stochastic Methods and Natural Phenomena", Eurographics 91, Tutorial Notes. [LIND74] A.Lindenmayer. Adding continuous components to L-Systems. In G.Rozenberg and A.Salomaa, editors, L-Systems, lecture notes in Computer Science, 15: 53-68, 1974. [LLUC93] J.Lluch, R.Quirós y B.Castellanos, Aplicación de los Sistemas Paramétricos Aleatorios a la generación de árboles y plantas herbáceas, Actas CEIG 1993, Junio, pag. 67-78. [PRUS86] P.Prusinkiewicz, Graphical Applications of L-Systems, Visual Interface Graphics Interface 86. [PRUS90] P.Prusinkiewicz, J.Hanan. Visualization of botanical structures and processes using parametric L-Systems. In D.Thalmann, editor, Scientific visualization and Graphics simulations:183-201, 1990. [QUIR92] R.Quirós, J. Lluch, R. Vivó. Generación de árboles y plantas mediante Sistemas-L. Actas C.E.I.G. 1992. NOVATICA jul./ago. 1999 nº140 SECCIONES TÉCNICAS 57 Informática de Software Javier Dolado*, Luis Fernández Sanz** *Universidad del País Vasco, **Universidad Europea de Madrid ¿Merece la pena usar los puntos de función? <[email protected]> <[email protected]> Este trabajo se ha desarrollado gracias al apoyo de los proyectos CICYT TIC98 1179-E y UPV EHU 141.226-EA083/98. Asimismo, los autores desean expresar su agradecimiento a María José Rueda por la revisión ortotipográfica del presente texto. Resumen: la medición de una aplicación mediante los puntos de función (en adelante, PF) es una de las actividades que más auge está adquiriendo dentro de la ingeniería del software. Sin embargo, la introducción de esta técnica (como la de cualquier otra) se debería hacer con las suficientes garantías de que cumple determinadas propiedades que la dotan de validez, tanto en su estructura teórica como en su aplicación práctica. En este artículo se examinan estas dos cuestiones con respecto al empleo de los puntos de función en la ingeniería del software. mayor difusión, su ponencia de 1979 se publicó en un volumen colectivo del IEEE2 [Jones, 1981]. Según Albrecht, los PF se basan en un estudio de 22 proyectos (16 en COBOL, 4 en PL/I y 2 en DMS/VS) completados entre 1974 y 1979. En esta primera propuesta, se adopta ya el esquema básico de determinación de los PF: 1. Se calculan primero los puntos de función no ajustados (en adelante, PFNA) contando los elementos externos de la aplicación. 2. A continuación se aplica un ajuste de complejidad (en adelante, AC) según el grado de influencia de varios factores. 1. Los puntos de función en la gestión del software El hecho de cuantificar el tamaño previsto para una aplicación en las primeras fases del ciclo de vida es una preocupación recurrente para todos los jefes de proyecto, puesto que la previsión de esfuerzo suele apoyarse en una estimación previa del tamaño. El uso del número de líneas de código (LOC: lines of code) como unidad de medida implica que hay que estimar al comienzo del proyecto dicho número, normalmente de forma rudimentaria y poco precisa. Así, los jefes de proyecto tienen que realizar dos estimaciones, una para las LOC y, posteriormente, otra para el esfuerzo. La estimación de las LOC no es una tarea sencilla ya que se trata de una medida del producto final del proyecto que no es fácilmente perceptible hasta que el proyecto tiene un determinado grado de compleción. Aunque existen algunos métodos de estimación de las LOC que han logrado algunos éxitos, no son objeto del presente trabajo. Una alternativa que se ha explorado es la propuesta de otras medidas del tamaño de la aplicación al comienzo del proyecto. Los PF se han utilizado como alternativa a las LOC y se han convertido en la medida más empleada en la fase de análisis dentro del ciclo de vida de la aplicación. Tanto es así que, recientemente, se ha publicado en una de las revistas de divulgación científica más conocidas un artículo en el que se promociona el uso de PF para medir el tamaño del software [Jones, 1998]. Dada la gran difusión que está alcanzando esta técnica, conviene analizar los conceptos en los que se apoya. A continuación vamos a describir cómo aparecieron los PF y de qué modo se mide con ellos. 2. La propuesta inicial: los PF de Albrecht de 1979 La propuesta inicial de los PF fue presentada en un congreso por A. J. Albrecht en 1979 [Albrecht, 1979], si bien documentos internos de IBM parecen indicar que su concepción se remonta, al menos, a 19751 . En 1981, para lograr una En esta versión de 1979, los PFNA se obtienen mediante la cuenta de cuatro tipos de elementos: entradas, salidas, consultas (pares de diálogo entrada/respuesta) y ficheros maestro (ficheros o agrupaciones lógicas de datos). Lo normal es que elementos se cuenten a partir de la especificación de la aplicación. Sin embargo, no todos los tipos contribuyen al valor final por igual; para cada uno existe un peso que trata de reflejar su valor funcional para el usuario (Tabla 1). Albrecht indica que determinó dichos pesos "mediante debate y prueba" [Albrecht, 1979]. Variables significativas Pesos Total sin ajuste ___________________________________________________ Número de entradas ∞4 __________ Número de salidas ∞5 __________ Número de consultas ∞4 __________ Número de ficheros maestros ∞ 10 __________ ____________________________________________________ Puntos de Función No Ajustados PFNA = __________ Ajuste de Complejidad (± 25%) N = Factores AC = 0,75 + 0,01 ∞ N = __________ Puntos de función PF = PFNA ∞ AC = __________ _______________________________________________ Tabla 1: Esquema para calcular los PF de 1979 El AC sobre los PFNA se realiza mediante la valoración subjetiva del grado de influencia que tienen en la aplicación diez factores técnicos. La opinión puede oscilar desde el 0 (sin influencia) hasta el 5 (influencia esencial). 3. La versión clásica de más uso: los PF de Albrecht de 1983 Albrecht publicó un artículo en 1983 [Albrecht y Gaffney, 1983] en el que modifica su fórmula de cálculo de los PF. En cuanto a la identificación de elementos, el número de NOVATICA jul./ago. 1999 nº140 58 ficheros se desdobla en dos: número de ficheros lógicos internos y número de ficheros compartidos o pasados a través de la interfaz externa. Por lo tanto, las variables de los PF son ahora las entradas, las salidas, las consultas, los ficheros lógicos internos y los ficheros lógicos externos. Para comprender mejor el modo en que se identifican estos elementos, en la figura 1 se muestra un esquema sobre cómo se ve una aplicación (aplicación A) desde el punto de vista de los PF. La aplicación A se comunica con una o varias aplicaciones B a través de transacciones e, igualmente, puede compartir determinados ficheros. La aplicación A se desarrolla bajo unas determinadas características del entorno (características generales de la aplicación) y se comunicará con los usuarios finales mediante un conjunto de transacciones, que pueden ser entradas, salidas o consultas. Después de haber identificado los diferentes tipos de elementos, la versión de 1983 requiere asignar a cada uno un valor de "complejidad", que puede ser sencilla, media o compleja. En el artículo de 1983 simplemente se daban algunas guías para clasificar cada elemento. Así, una salida se considera sencilla si tiene "una o dos columnas" y hay "transformaciones sencillas de datos" [Albrecht y Gaffney, 1983]. Actualmente, tras muchos años de trabajo de especificación, estas guías han llegado a ser algo más objetivas después de elaborar tablas de clasificación [IFPUG, 1994]. Por ejemplo, la Tabla 2 permite clasificar una salida como sencilla, media o compleja según el número de ficheros y el número de campos de datos a los que hace referencia. En cualquier caso, se asume que la complejidad de cada elemento se mide en una escala ordinal simple de tres valores: sencilla, media o compleja. _______________________________________________ Salidas 1-5 ítems de datos 6-19 ítems 20 o más ítems referenciados de datos de datos referenciados referenciados _________________________________________________________ 0 o 1 fichero Sencilla Sencilla Media referenciado _________________________________________________________ 2 o 3 ficheros Sencilla Media Compleja referenciados __________________________________________________________ 4 o más ficheros Media Compleja Compleja referenciados _______________________________________________ Tabla 2: Guía de [IFPUG, 1994] para clasificar la complejidad de las salidas de una aplicación Una vez clasificados los elementos, a cada uno de ellos le corresponde un "factor de ponderación" según su tipo y complejidad (ver Tabla 3). No obstante, en ningún sitio (ni en [Albrecht y Gaffney, 1983] ni en otros trabajos) se explican o justifican con criterios objetivos los valores asignados a estos pesos. Usuarios finales TRANSACCIONES Salida Entrada Consulta Límite de la aplicación A Características generales de la aplicación: (ajuste de la complejidad) Límite de la aplicación B Características generales de la aplicación (ajuste de la complejidad) Interfaz Ficheros A Ficheros B Interfaz compartido Interfaz APLICACIÓN B APLICACIÓN A { Transacciones Figura 1: Relaciones entre usuarios, aplicaciones y funciones Entrada Salida Consulta } Transacciones NOVATICA jul./ago. 1999 nº140 59 Factor de Ponderación o Complejidad ____________________________________________________ Tipo de componente Simple o baja Medio Complejo o alta ____________________________________________________ Entradas Salidas Consultas Interfaces externas Ficheros internos 3 4 3 5 7 4 5 4 7 10 5 7 6 10 15 _______________________________________________ Tabla 3: Pesos para los diferentes componentes El cálculo de los PFNA es la suma ponderada de todos los elementos (según la Tabla 2, tenemos 15 posibilidades) y viene dada por la fórmula: PFNA= 15 i=1 (nº elementosdetipoi)↔(peso ) i Por último, la cuenta final de los PF supone multiplicar los PFNA por el ajuste de complejidad técnica (ACT). El ACT se calcula puntuando cada factor de la figura 4 en una escala con los siguientes valores: 0, 1, 2, 3, 4 o 5. El cero significa que el factor es irrelevante para la aplicación y el cinco, que es esencial. Entonces el ACT es: 14 ACT = 0,65+ 0,01 Fi i=1 Como puede verse, se amplía el número de factores de ajuste de los 10 de la versión de 1979 a los 14 de esta versión de 1983 (Tabla 4). La influencia máxima de cada factor sigue siendo del 5%, por lo que la variación que supone el ACT sobre los PFNA puede ser del ± 35%. _______________________________________________ Factores que contribuyen a la complejidad de procesamiento (ACT) F1: fiabilidad del back-up y recuperación F3: funciones distribuidas F5: configuración muy cargada F7: facilidad de operación F9: interfaz compleja F11: reusabilidad F13: localización múltiple F2: comunicaciones de datos F4: rendimiento F6: entrada de datos on-line F8: actualización on-line F10: procesamiento complejo F12: facilidad de instalación F14: facilidad de cambio _______________________________________________ Tabla 4: Factores que influyen en el ACT 3. Evolución de los PF: variantes y mejoras En 1985, la consultora SPR (Software Productivity Research) propuso una variante de los PF, la cual contenía las cinco variables de la versión de los PF de 1983, pero sin catalogar cada elemento en sencillo, medio o complejo. En el ACT se reducían los catorce factores a sólo dos (complejidad del problema y complejidad de los datos)3 , evaluados de uno a cinco. No obstante, el ACT puede suponer una variación del ± 40% (frente al 35% de la versión de 1983). En 1986, SPR lanzó su variante de los PF para software de tiempo real y de sistemas, variante denominada puntos de características (feature points). Lamentablemente, en 1991, la técnica estaba "aún en fase experimental y todavía en pruebas" [Jones, 1991]. Más significativa fue la creación en 1986 por parte de una serie de empresas (muchas de ellas, clientes de IBM) de una asociación llamada IFPUG4 (International Function Point User Group) para promover el uso y el intercambio de información sobre los PF. Además de organizar conferencias internacionales, el IFPUG publica documentos con los que se trata de estandarizar las reglas de cálculo de los PF y la terminología manejada. Actualmente se trabaja con la versión 4.0 del manual de cálculo, publicada en 1994 [IFPUG, 1994]. En 1988, C. Symons hizo una dura crítica a los PF de Albrecht [Symons, 1988]. Señaló la subjetividad en la cuenta de elementos, la arbitrariedad de los pesos asignados, la inconsistencia de cálculo de los PF al tratar sistemas divididos en susbsistemas, la ausencia de una cuantificación de la complejidad interna y la necesidad de revisar las 14 características que componen el ACT. Su solución consistió en aportar una nueva variante denominada PF de tipo II (MarkII Function Points). En ella se trabaja con el concepto de transacción lógica: una combinación de entrada, proceso y salida, disparada por un acontecimiento de interés para el usuario o por una necesidad de recuperar información. Para cada transacción hay que contar el número de elementos de entrada (EE) y de salida (ES) que implica, así como las entidades de datos (ED) tratadas o referenciadas (Tabla 5). A diferencia de Albrecht, Symons indicó que la ponderación (los pesos P1, P2 y P3) de cada variable se debe lograr por calibración en el entorno donde se va a aplicar si bien, en su libro de 1991 [Symons, 1991] ofrece una media de pesos obtenida en diversos proyectos: P1 = 0,58 , P2 = 1,66 y P3 = 0,26. _______________________________________________ Para cada transacción Ti PFNAi = P1· EEi + P2 · ESi + P3 · EDi PFNA total PFNAT = i PFNAi ACT: Symons indica que C debe calcularse por calibración (se recomienda 0,005) ACT = 0,65 + C · factores PF MKII = PFNA · ACT _______________________________________________ Tabla 5: Esquema de cálculo de los PF MarkII 4. Críticas y problemas de los PF Desde la propuesta inicial de Albrecht, las distintas versiones de los PF han intentado paliar tanto los problemas inherentes al cálculo como los relacionados con las capacidades predictivas de los mismos. Es curioso cómo los propios proponentes de los PF han ido planteando versiones y modificando matices en la técnica, a medida que se iban haciendo conscientes de algunos de sus problemas. También hemos comentado el caso de uno de los autores más críticos con los PF de Albrecht, Symons [Symons, 1988], quien, sorprendentemente, formuló un nuevo método que hereda muchos de los defectos de formulación atribuibles a los PF originales. 60 La razón por la cual no se ha mejorado la validez de los PF con las distintas propuestas radica en que en ningún caso se han seguido los postulados básicos de la teoría de la medición. Es sólo a partir del proyecto METKIT y de los trabajos de Fenton y sus colaboradores cuando se fundamentan las críticas hacia los PF [Fenton, 1997]. Estos autores demostraron con claridad que su proceso de construcción es matemáticamente incorrecto, hasta tal punto que, precisamente, una de sus principales referencias [Kitchenham et al., 1995] apareció cuando se estaba en proceso de estandarización de la metodología de PF. En dicha referencia trataban de advertir a la comunidad de ingeniería del software sobre los peligros de estandarizar medidas conceptualmente incorrectas. En estos momentos los PF no se han establecido en un estándar, a pesar de la idea que uno se puede formar tras la lectura de artículos como [Jones, 1998]. Lo que sí se está haciendo es estandarizar el proceso de definición de medidas funcionales, de lo que se encarga una parte del estándar ISO/IEC 14143-1 sobre medidas de tamaño funcional [ISO, 1998]. A continuación se describen las deficiencias de definición teórica y de aplicación práctica de las que adolecen los PF. 4.1. Validación teórica, o por qué los PF no miden bien Para poder medir y operar con los valores de una variable, ésta se debe haber definido de acuerdo con los postulados de la teoría de la medición. Brevemente indicaremos que una variable se puede medir en una escala nominal, ordinal, intervalo, ratio o absoluta. La escala nominal se utiliza con propósitos de identificación (colores, por ejemplo), mientras que en la escala absoluta podemos contar los objetos y establecer un origen o cero absoluto para la cuenta. Lo ideal es que una variable esté medida en una escala absoluta para poder sumar, restar, multiplicar y dividir sus valores. Por el contrario, en una escala nominal sólo cabe diferenciar los elementos; en una escala ordinal únicamente podemos ordenarlos y en una escala intervalo solamente podemos ver la diferencia en el orden establecido. Evidentemente, no está permitido operar con valores de diferentes escalas (por ejemplo, no se puede sumar el color rojo de un objeto con el número de objetos existente). Sin embargo, ya se ha visto anteriormente en la Sección 2 que en el cálculo de los PF utilizamos varios tipos de escala. Como se ha descrito en [Abran y Robillard, 1996] se puede apreciar que el uso de las escalas nominal, ordinal, ratio y absoluta es inconsistente en el cálculo de los PF, el cual constituye un popurrí de escalas que no es admisible desde el punto de vista teórico. Estos autores también indican que los pesos de los componentes no añaden mucha información al número final, aunque se pueden utilizar sin otros datos históricos en la predicción del esfuerzo. Por su parte, Kitchenham, Pfleeger y Fenton [Kitchenham et al., 1995] son más críticos con respecto a la validez de los PF e, incluso, proponen abandonar la técnica, dado que no se ajusta a los principios básicos de la teoría de la medida. Sin embargo, la aplicación de la técnica parece extenderse continuamente debido, sobre todo, a la gran base de usuarios de la misma. Esta amplia utilización parece transmitir una cierta confianza sobre su validez práctica a los posibles NOVATICA jul./ago. 1999 nº140 usuarios, aunque, como veremos en el siguiente apartado, la técnica también falla en este aspecto. 4.2. Validación práctica de los PF, o por qué la medida quizás no sirva para mucho Es probable que el argumento más importante para usar los PF es el de obtener predicciones del esfuerzo de desarrollo de una aplicación. Por otra parte, también se propone como una medida de tamaño funcional para la valoración económica de las aplicaciones, independientemente de la tecnología. En cuanto a la predicción del esfuerzo, debemos recordar que una técnica es útil en la medida en que es capaz de predecir ese esfuerzo con fiabilidad. Originalmente, y en palabras textuales de A. Albrecht "...se ha descubierto que los PF son una medida relativa efectiva del valor funcional entregado al usuario" [Albrecht, 1983]. Ahora bien, en este trabajo y en casi todos los posteriores, la bondad de tal efectividad se ha evaluado tanto con el coeficiente R2 como con el coeficiente de correlación. El R2 es un criterio de valoración de los modelos de regresión que representa el porcentaje de la varianza justificado por la variable independiente. Se puede interpretar como el cuadrado del coeficiente de correlación de Pearson entre las variables dependiente e independiente, o también como el cuadrado del coeficiente de correlación entre los valores reales de una variable y sus estimaciones. Si todas las observaciones están en la línea de regresión, el valor de R2 es 1, y si no hay relación lineal entre las variables dependiente e independiente, el valor de R2 es 0. El coeficiente R2 es una medida de la relación lineal entre dos variables. Los valores que se han obtenido para el coeficiente R2 en los diferentes estudios publicados sobre los PF varían desde 0,44 hasta 0,87. En uno de los últimos estudios [Jeffery and Stathis, 1996] el coeficiente R2 varía desde 0,559 hasta 0,662. Ante estos valores, algunos autores han reafirmado la validez de la técnica. Creemos, sin embargo, que es una conclusión que no se corresponde con la realidad por varios motivos. Tanto el R2 como el coeficiente de correlación no son las medidas más adecuadas para evaluar la predicción de un modelo; en el mejor de los casos se trata de medidas del ajuste de la ecuación a los datos, no de la capacidad predictiva del modelo. Desde este punto de vista, las variables más convenientes son PRED(0,25), nivel de predicción al 25%, y MMRE, magnitud media del error relativo, definidas en [Conte et al., 1986]. PRED(0,25) se define como el cociente del número de casos en los que las estimaciones están dentro del límite del 25% de los valores reales entre el número total de casos. Por ejemplo, PRED(0,25) = 0,9 quiere decir que el 90% de los casos tiene estimaciones dentro del 25% de sus valores. 1 El MMRE se define como MMRE= n n i =1 ) ei −ei e , donde e es el valor real de la variable, ê es su valor estimado y n es el número de proyectos. Así, si el MMRE es pequeño, entonces tenemos un buen conjunto de predicciones. Se NOVATICA jul./ago. 1999 nº140 considera que un modelo es aceptable si PRED(0,25) > 0,75 y MMRE < 0,25. Utilizando estos dos criterios la supuesta capacidad de predicción de los PF disminuye notablemente [Dolado y Fernández, 1998]. En algún caso incluso se ha descubierto que no existía correlación entre los PF y esfuerzo de desarrollo, debido principalmente a las diferencias de productividad, que no son compensadas por el entorno de desarrollo [Dolado, 1997]. Además, al manejar los PF, la predicción de esfuerzo tropieza con la ausencia de modelos generales, es decir, no hay una ecuación para cualquier entorno en la que introduciendo el valor de los PF y otros parámetros, obtengamos un valor de esfuerzo o de plazo de tiempo (excepto en el caso de los PF MarkII [Symons, 1991]). Por lo tanto, sería necesario construir un modelo para cada entorno; ni siquiera es posible calibrar uno general, ya que el esfuerzo requerido es equivalente al de construir un modelo nuevo. Esto se puede apreciar incluso en [Albrecht y Gaffney, 1983], donde aparecen ecuaciones diferentes para un entorno de COBOL y para otro de PL/I. Por el contrario, si se opta por convertir los PF a LOC mediante tablas de equivalencia [Jones, 1991] y se aplica un modelo de estimación general (por ejemplo, COCOMO [Boehm, 1981]), aparte de otras dificultades, surge el inconveniente de que existe un doble ajuste de complejidad: por una parte, el ACT de los PF y, por otra, los inductores de coste de COCOMO. A esto hay que añadir que, los modelos generales de estimación de costes están plagados de múltiples problemas: poca precisión, dificultades de operación debidas a una mala definición de sus elementos, deficiencias en su modo de construcción y muy poca flexibilidad para adaptarse a otros entornos, a pesar de la calibración y el uso de factores de coste [Fernández, 1997]. Lamentablemente, los problemas de la técnica de los PF no terminan aquí. Hemos de mencionar dificultades que aparecen, en especial, cuando se utilizan como criterio de valoración económica, pero también cuando sirven de base para la predicción [Fenton y Pfleeger, 1997]: a) La subjetividad en la aplicación del ACT. b) La doble cuenta de la complejidad según se ha explicado en el apartado anterior. c) Los valores anti-intuitivos que aparecen cuando se asigna el valor medio a los factores del ACT. d) La dificultad para su utilización cuando no existe una especificación completa. e) Las diferencias entre el valor de PF obtenido sobre la especificación original de un sistema y el obtenido cuando se aplica sobre el sistema ya terminado. f) Los PF sólo están destinados a aplicaciones de gestión ya que la efectividad de las variantes para otros tipos de software no se ha justificado suficientemente g) Diferentes personas obtienen valores distintos al contar los elementos para calcular los PF, a pesar de las guías de IFPUG. h) La correlación (colinealidad) entre los elementos constitutivos de los PF (entradas, salidas, etc.) cuestiona su utilidad; también se observa una escasa aportación del ACT a la predicción, puesto que los PFNA proporcionan valores de predicción similares a los obtenidos con los PF finales [Jeffery and Stathis, 1996]. 61 En definitiva, son demasiados problemas como para aceptar, sin más, la aplicación de la técnica de los PF. Por lo tanto, debemos ser cuidadosos al interpretar los valores sobre PF que aparecenen artículos como [Jones, 1998], puesto que esos datos pueden proporcionar una falsa sensación de seguridad sobre la capacidad de la técnica, sobre todo cuando, desde el punto de vista científico, exigimos en primer lugar una correcta definición del concepto para más tarde utilizarlo en la práctica. Desgraciadamente, esta cuestión se elude en un artículo de tan amplia repercusión como el ya mencionado [Jones, 1998]. 5. ¿Hay otras posibilidades? Una vez que hemos analizado los problemas que plantean los PF, se nos plantea la cuestión de cuál o cuáles pueden ser las alternativas válidas. A cualquier nueva propuesta se le debe pedir, al menos, las mismas propiedades matemáticas que las exigidas a los PF. Para ello, debemos emplear en todo momento una escala ratio, es decir, recurrir siempre a la cuenta de entidades o de elementos, sin utilizar tablas de valoración de los mismos. No son muchas las alternativas que se han publicado; incluso, alguna de ellas cae en los mismos errores que los cometidos en los PF, como es el caso de la de los Puntos Objeto (PO) [Boehm, 1995]. Se basan en definir unos objetos utilizados en un entorno determinado que, posteriormente, se pueden asociar a los componentes de los PF. Su principal utilidad consiste en contar con un "repositorio de objetos" que representan a los elementos del sistema de información. De este conjunto de objetos, para el cálculo de los PO hay que estimar el número de pantallas, de informes y de componentes 3GL (elementos procedimentales). Como en los PF, los elementos se clasifican en sencillos, medios o difíciles, y se les asigna un peso de complejidad. En [Dolado, 1998] se comentan otras alternativas posibles como el manejo de modelos generales de estimación de tamaño, la cuenta de diferentes elementos en la orientación a objetos, la medición sobre metamodelos, la medición basada en el recuento de diversos tipos de componentes, las medidas sobre los diagramas de flujo de datos, etc. Se puede afirmar, en definitiva, que es posible contar otros objetos identificables en una especificación de software con igual o mejor capacidad de predicción y medición que los PF. Por eso, recomendamos la elaboración específica de ecuaciones en cada entorno en el que se desee establecer una relación entre una medida de tamaño de la especificación del sistema y el esfuerzo preciso para su desarrollo. 6. Conclusión Supongamos que medimos habitualmente la misma clase de tela con la misma regla. Aunque el centímetro que usemos como unidad no coincida con el que se emplee oficialmente, siempre obtendremos una información interesante para comparar las diferentes telas medidas. Así, nos resultará posible tomar decisiones basándonos en esa información (por ejemplo, cuántas piezas de tela necesitamos para hacer un traje). El problema aparece cuando queremos comunicar a otra persona cuánto mide nuestra tela en "centímetros de NOVATICA jul./ago. 1999 nº140 62 verdad". Si nuestro centímetro no coincide con el de la otra persona, es imposible una correcta comparación. Tampoco es posible saber cuántos metros de tela tenemos si las telas están arrugadas y no las estiramos para medirlas. En términos de PF, estas analogías equivalen, en primer lugar, al hecho de contar o no contar determinados elementos y, en segundo, a la constatación de que dos analistas pueden valorar la misma especificación de distinta manera. Si el sastre mide las telas a ojo, aunque intente todos los días medir igual manera, es muy difícil que la medida sea siempre exactamente la misma. Por lo tanto, lo que mide un día puede diferir del valor obtenido al día siguiente para la misma pieza de tela. En relación con los PF, esto significa que un analista puede fácilmente pasar por alto alguno de los elementos necesarios para el cálculo de los PF. Utilizar los PF no resuelve los problemas de fondo de los proyectos. Lo que se debe hacer es establecer un plan de medición que defina las características de las especificaciones. Después, se ha de analizar en cada entorno y en cada proyecto si dichas propiedades son o no indicadores del esfuerzo de desarrollo o de cualquier otro atributo que se desee evaluar o predecir [Fernández, 1998]. 6. Referencias A. Abran y P.N. Robillard; Function points analysis: an empirical study of its measurement processes, IEEE Trans. on Software Engineering, vol. 22, nº 12, pp. 895-909, 1996. A.J. Albrecht; Measuring application development productivity, Proceedings of the Joint SHARE, GUIDE and IBM Application Development Symposium, octubre 1979, pp. 83-92. A.J. Albrecht y J.E.Gaffney; Software function, source lines of code, and development effort prediction: a software science validation, IEEE Transactions on Software Engineering, vol. 9, nº 6, noviembre 1983, pp. 639-647. B. Boehm et al.; Cost models for future software life cycle processes: Cocomo 2.0, Annals of Software Engineering, vol. 1, 1995, pp. 57-94. J.J. Dolado; A study of the relationships among Albrecht and Mark II function points, lines of code 4GL and effort, Journal of Systems and Software, vol. 37, pp. 161-173, 1997. J.J. Dolado; Medición de especificaciones de software, en I Cuaderno de Calidad, Novática, enero/febrero, 1999. J.J. Dolado y L. Fernández; Genetic programming, neural networks and linear regression in software project estimation, INSPIRE III, pp 157-171, 1998. N. Fenton y S.L. Pfleeger; Software Metrics. A rigurous and practical approach, PWS Publishing, 1997. L. Fernández; Medición y predicción de atributos de diseño en una metodología formalizada, tesis doctoral, Universidad del País Vasco, 1997. L. Fernández; Una revisión breve de la medición del software, en I Cuaderno de Calidad, Novática, enero/febrero, 1999. International Function Point User Group; Function point counting rules 4.0, IFPUG, enero, 1994. ISO; ISO/IEC 14143-1:1998. Information technology: Software measurement. Functional size measurement. Part 1: Definition of concepts, ISO, 1998. R. Jeffery y J. Stathis; Function Point sizing: structure, validity and applicability, empirical software engineering, vol. 1, pp. 11-30, 1996. C. Jones; Programming productivity-Issues for the Eigthies, IEEE Computer Society, 1981, pp. 35-44. C. Jones; Applied software measurement-Assuring productivity and quality, McGraw-Hill, 1991. C. Jones; "Sizing up software", Scientific American, diciembre 1998 (traducido en "Evaluación del tamaño del software", Investigación y Ciencia, febrero 1999). B.A. Kitchenham, , S.L. Pfleeger y N. Fenton; Towards a Framework for Software Measurement Validation, IEEE Transactions on Software Engineering, vol. 21, nº 12, pp. 929-944, 1995. C.R. Symons; Function point analysis: difficulties and improvements, IEEE Transactions on Software Engineering, vol. 14, nº 1, 1988, pp 2-11. C.R. Symons; Software sizing and estimating. MkII function point analysis, Wiley and Sons, 1991. Notas 1 Según se indica en [Jones, 1991], existen documentos de 1975 sobre los PF, como: IBM Corporation, DP services size and complexity factor estimator, DP Services Technical Council, 1975. 2 Institute of Electrical and Electronics Engineers. 3 Se incluye una tercera característica de complejidad de código cuando se aplica esta versión al software ya construido (backfire FP) con el propósito de realizar estudios históricos de productividad. 4 Para más información, se puede acceder al servidor de IFPUG en http://ifpug.org. NOVATICA jul./ago. 1999 nº140 SECCIONES TÉCNICAS 63 Metodologías José R. Hilera Dpto. de Ciencias de la Computación, Facultad de Ciencias de la Documentación, Departamento de Ciencias de la Computación, Universidad de Alcalá Metodología METRICA Orientada a Objetos <[email protected]> Resumen: Se describe una metodología de desarrollo de Sistemas de Información, denominada M2O, que puede considerarse una versión orientada a objetos de MÉTRICA v2.1. Esta metodología se ha elaborado para facilitar la transición del enfoque estructurado al enfoque orientado a objetos, por lo que se ha realizado la menor cantidad de cambios posibles en la versión original de MÉTRICA, manteniendo la estructura general de su ciclo de vida, aunque modificando algunas actividades y tareas, especialmente de los módulos de especificación funcional y diseño técnico. También se han sustituido las técnicas de análisis y diseño estructurado por las orientadas a objetos incluidas en el estándar UML. Palabras clave: Ingeniería del software, Orientación a objetos, MÉTRICA, UML. 1. Introducción Ante los repetidos retrasos en la aparición de la versión 3 de MÉTRICA, que, como se anuncia, incorporará el enfoque de la Orientación a Objetos [1]; y ante la necesidad de una metodología específica para el desarrollo de software orientado a objetos, en septiembre de 1997, el Grupo de Investigación en Ingeniería de la Información y de la Documentación (GI3D) de la Universidad de Alcalá, decidió elaborar su propia versión orientada a objetos de MÉTRICA. Así surgió M2O, una metodología que elimina de METRICA los aspectos relacionados con el enfoque estructurado, como las tradicionales técnicas de modelado: Diagrama de Flujo de Datos, Diagrama Entidad-Relación, Diagrama de Historia de la Vida de las Entidades, Diagrama de Estructura de Cuadros, Matriz de Procesos-Entidades; y las substituye por las técnicas incluidas en la norma UML [2]: Diagrama de Casos de Uso, Diagrama de Actividades, Diagrama de Clases, Diagrama de Estados, Diagrama de Secuencia, Diagrama de Colaboración, Diagrama de Componentes, Diagrama de Despliegue. Para la elaboración de M2O, se analizaron diferentes metodologías OO de segunda generación, como OBJETORY [3], FUSION [4], MOSES [5] y, especialmente, MAINSTREAM OBJECTS [6], por estar basada en un ciclo de vida similar al de MÉTRICA [7], el ciclo de vida en cascada. Aunque podría haberse considerado un modelo de ciclo de vida específico para OO [8], el objetivo de M2O era permitir una transición lo menos traumática posible para los usuarios de MÉTRICA, desde el enfoque estructurado al orientado a objetos, por lo que se decidió mantener este modelo. 2. M2O: MÉTRICA v2.1 orientada a objetos La metodología orientada a objetos M2O mantiene la misma estructura de ciclo de vida que MÉTRICA, incluso los nombres de las fases, módulos y actividades, excepto en el caso de las cuatro siguientes: - EFS 1. Construir el modelo de comportamiento del nuevo sistema - EFS 2. Construir el modelo de estructura de objetos del nuevo sistema - DTS 1. Diseñar la arquitectura lógica del sistema - DTS 2. Diseñar la arquitectura física del sistema Es, por tanto, en estas cuatro actividades donde se encuentran las principales diferencias entre ambas metodologías. Sin embargo, en otras actividades, aunque se ha mantenido el nombre de la actividad, el de algunas de sus tareas se ha modificado, así como el trabajo a llevar a cabo y técnicas a aplicar en cada caso. Se trata de las siguientes tareas de la metodología M2O: Módulo ARS - Tarea ARS 3.1: Construcción del modelo de comportamiento del sistema actual. - Tarea ARS 3.2: Construcción del modelo de estructura de objetos del sistema actual. Módulo EFS - Tarea EFS 3.1: Construcción de modelos de interacción y estados. - Tarea EFS 3.2: Consolidación de modelos de comportamiento y estructura de objetos. En el caso del módulo ARS, el cambio se debe a que el modelado del sistema actual que exige realizar MÉTRICA durante las actividades 3.1 y 3.2 es de tipo estructurado, por lo que en M2O se ha sustituido por un modelado Orientado a Objetos, utilizando las técnicas de UML: Diagrama de Casos de Uso, en la tarea 3.1; y Diagrama de Clases en la 3.2. Opcionalmente se podría completar el modelo de comportamiento con Diagramas de Interacción (Secuencia o Colaboración), Diagramas de Actividad y Diagramas de Estados. Precisamente estas técnicas se utilizan también en la tarea 64 EFS 3.1, y servirán para que en EFS 3.2 se pueda verificar la consistencia entre los objetos del modelo de estructura de objetos y los objetos de los modelos de interacción, así como comprobar que realmente se requiere su intervención para llevar a cabo los diferentes casos de uso. 2.1. Actividad EFS 1. Construir el modelo de comportamiento del nuevo sistema Descripción y objetivos El objetivo de esta actividad es la descripción de los posibles escenarios de utilización del sistema, lo cual deberá ayudar a la identificación de las funciones u operaciones asociadas a cada objeto particular implicado en cada uno de estos escenarios, que serán incluidas en el modelo de estructura de objetos. Si la complejidad del comportamiento de algunos de los objetos incluidos en el Modelo de Estructura de Objetos así lo aconseja, por ejemplo, por estar implicados en numerosos escenarios de utilización del sistema, también se describiría la secuencia de estados en los que podrá encontrarse tal objeto a lo largo de su existencia, así como el origen de las transición de un estado a otro y el efecto funcional (ejecución de acciones) que producen estas transiciones. Secuencia de tareas para esta actividad: - Tarea EFS 1.1: Diseño del Diagrama de Casos de Uso del Sistema. - Tarea EFS 1.2: Identificación y definición de subsistemas. - Tarea EFS 1.3: Especificación de interfaces con otros sistemas. - Tarea EFS 1.4: Descripción de procesos manuales. Se ha mantenido el mismo nombre que utiliza MÉTRICA para las dos últimas tareas. Productos a obtener - Diagrama de Casos de Uso, en el que se representan los principales escenarios de utilización del sistema. - Diagramas de Interacción, en los que se representa, en forma de interacción entre los objetos implicados, la secuencia de operaciones que se llevan a cabo durante la ejecución de cada uno de los casos de uso incluidos en el diagrama anterior. - Diagramas de Actividad (opcional), para documentar de forma estructurada la secuencia de operaciones de un diagrama de interacción. - Diagramas de Estados (opcional), para representar la funcionalidad asociada a una clase de objeto determinado durante su existencia en el sistema. - Descripción de los elementos los diagramas: casos de uso, estados, operaciones, eventos, actores. Técnicas Para el desarrollo del modelo de comportamiento se utilizarán las técnicas de UML: Diagrama de Casos de Uso, Diagrama de Interacción (en forma de secuencia o colaboración), Diagrama de Actividad y Diagrama de Estados. También pueden utilizarse técnicas estructuradas, como los Diagramas de Acción, el Pseudocódigo o las Tablas de decisión, para la descripción de las interacciones entre objetos incluidas en el Diagrama de Interacción. NOVATICA jul./ago. 1999 nº140 La información necesaria para el desarrollo completo del modelo de comportamiento, además de obtenerse del documento de requisitos, se conseguirá de los usuarios a través de entrevistas. 2.2. Actividad EFS 2. Construir el modelo de estructura de objetos del nuevo sistema Descripción y objetivos Esta actividad tiene como objetivo la realización del modelo abstracto (conceptual) donde se refleje, desde un punto de vista estático, la estructura de la información implicada en el sistema a desarrollar, completando así el aspecto dinámico de la misma contemplado en el modelo de comportamiento que se realiza de forma simultánea. Al tratarse de un modelo abstracto, es independiente de la implementación, que se decidirá en la fase de diseño, no considerando detalles físicos relacionados con el almacenamiento de los datos en los distintos soportes (modos de organización, tipos de acceso, etc.). El modelo incluirá: 1) las clases de objetos relevantes (objetos identificables sobre los que el sistema guarda información), 2) las relaciones entre clases, que garantizan la coherencia del conjunto del sistema de información y permiten el acceso a un objeto desde otro mediante procesos sencillos; y 3) los servicios que ofrecen los objetos de una clase, que pueden ser solicitados por otras. Se ha establecido únicamente una tarea para esta actividad: - Tarea EFS 2.1: Construcción del modelo de estructura de objetos. Productos a obtener - Diagramas de clases de objetos del sistema. - Descripción de los elementos que aparecen en los diagramas: clases, con sus atributos y servicios; y relaciones, con información sobre su cardinalidad. Técnicas La técnica de modelado de la estructura de objetos será el Diagrama de Clases, que podrá ser único para todo el sistema, o constituido por varios diagramas, cada uno de llos asociado a uno de los subsistema establecidos cuando la complejidad del sistema así lo aconseje. En estos diagramas, además de clases y relaciones, también se podrán incluir paquetes de clases agrupadas atendiendo a un determinado criterio. Para la descripción de los servicios ofrecidos por las clases, pueden utilizarse técnicas estructuradas, como los Diagramas de Acción, el Pseudocódigo o las Tablas de decisión. La información necesaria para el desarrollo completo del modelo de estructura de objetos, además de obtenerse del documento de requisitos, se conseguirá de los usuarios a través de entrevistas. 2.3. Actividad DTS 1. Diseñar la arquitectura lógica del sistema Descripción y objetivos En esta primera actividad del módulo DTS se realizará el di- NOVATICA jul./ago. 1999 nº140 seño global del sistema. Para ello, se considerarán las tareas: - Tarea DTS 1.1: Identificación de objetos de interfaz y control. - Tarea DTS 1.2: Identificación y especificación de operaciones. - Tarea DTS 1.3: Refinamiento del modelo de comportamiento. - Tarea DTS 1.4: Refinamiento del modelo de estructura de objetos. - Tarea DTS 1.5: Refinamiento de subsistemas. - Tarea DTS 1.6: Verificación del diseño de la arquitectura lógica. El punto de partida para llevar a cabo el diseño lógico, normalmente, se iniciará con los Diagramas de Casos de Uso. Examinando los Casos de Uso se puede identificar qué objetos de interfaz y control deberían añadirse al modelo de estructura de objetos. También, examinando el Diagrama de Interacción correspondiente a cada Caso de Uso, se pueden identificar qué operaciones deberían incluirse en las clases de objetos. Los Casos de Uso también proporcionan la base para decidir la funcionalidad que ha de incluirse en cada operación. La primera tarea del diseño lógico consiste en la identificación de objetos de interfaz y control. Los objetos de interfaz se utilizan para manejar la comunicación del sistema con el exterior. Por otro lado, los objetos de control se utilizan para contener las funciones que no pueden ubicarse de forma natural ni en los objetos de interfaz ni en los objetos de entidad. 65 La tarea DTS 1.5 consiste en la redefinición de los subsistemas identificados durante la fase de análisis. Es conveniente realizar una revisión en este punto del desarrollo, ahora que las clases de objetos y las operaciones han sido definidas completamente, para asegurar que los subsistemas representan de verdad unidades coherentes. Antes de concluir el diseño lógico de un sistema, hay que comprobar que los modelos obtenidos han sido correctamente realizados. Para ello se verificará el modelo de estructura de objetos, los casos de uso y diagramas de interacción, la definición de operaciones, los diagramas de estados y la división del sistema en subsistemas. Productos a obtener - Modelo de comportamiento (Diagramas de Interacción y de Estados) refinado. - Modelo de estructura de objetos (Diagramas de Clases) refinado. - Descripción de la semántica y parámetros de las operaciones asociadas a cada clase de objetos. - Definición de los subsistemas que componen el sistema a desarrollar. Técnicas Las mismas que se emplearon durante las actividades de análisis (EFS 1 y EFS 2), exceptuando las entrevistas. 2.4. Actividad DTS 2. Diseñar la arquitectura física del sistema Durante la segunda tarea se identifican y especifican las operaciones incluidas en las clases de objetos, para ello se debe: 1) Identificar y asignar las operaciones, 2) Nombrar las operaciones, 3) Describir la semántica (algoritmo) y parámtros de cada operación, 4) Revisar las operaciones identificadas, y 5) Redefinir las operaciones heredadas. Descripción y objetivos La tarea DTS 1.3 consiste en la comprobación de que se han definido todas las operaciones necesarias para soportar la funcionalidad descrita para los diferentes casos de uso del sistema, en los diagramas de interacción y en los diagramas de estado. El proceso de diseño ha de ser iterativo, con lo que esta revisión puede ayudar a identificar aspectos que habría que modificar en las operaciones ya definidas o, incluso, nuevas operaciones. El desarrollo orientado a objetos es de tipo incremental, ya que los componentes se van añadiendo a la arquitectura del sistema a lo largo de las fases de análisis y diseño. Durante el análisis se establecen las clases del dominio del problema, que constituyen el Componente del Dominio del Problema. Durante el diseño lógico, además de refinar el componente anterior, se añade el Componente de Interfaz con el Usuario y el Componente de Interfaz con Sistemas Externos, mediante las clases de interfaz y control. Durante el diseño físico, además de refinar los componentes anteriores, se añaden: el Componente de Gestión de Datos, que proporciona la infraestructura para el almacenamiento y acceso a los objetos persistentes en algún Sistema de Gestión de Base Datos; el Componente de Gestión de Tareas, que consta de los objetos necesarios para manejar la concurrencia (procesamiento paralelo) que pueda darse en el sistema; y el Componente de Servicios de Utilidad, que proporciona los servicios de utilidad general que pueden ser requeridos por el resto de componentes, tales como el manejo de la implementación de nuevos tipos de datos La cuarta tarea del diseño lógico consiste en el refinamiento del modelo de estructura de objetos. Se trata de incluir, en el Diagrama de Clases del Sistema, las clases de objetos de interfaz y control identificados durante esta etapa del diseño. También puede ocurrir que, ahora que se dispone de una descripción más detallada del sistema, se estime conveniente la introducción de algunos cambios en el diagrama. Otros aspectos que deben considerarse son: la definición de la persistencia de los objetos y el ajuste de la generalización (jerarquía de herencia). El objetivo del diseño físico es añadir, al modelo lógico obtenido en la etapa anterior, todos los detalles técnicos, dependientes de la plataforma en la que funcionará el sistema, necesarios para construir el sistema. Se trata de obtener la arquitectura física, es decir, la organización del software en módulos o componentes y su distribución en el hardware. NOVATICA jul./ago. 1999 nº140 66 Se ha establecido la siguiente secuencia de tareas para esta actividad: - Tarea DTS 2.1: Diseñar el componente del dominio del problema. - Tarea DTS 2.2: Diseñar el componente de interfaz con el usuario. - Tarea DTS 2.3: Diseñar el componente de interfaz son sistemas externos. - Tarea DTS 2.4: Diseñar el componente de gestión de datos. - Tarea DTS 2.5: Diseñar el componente de gestión de tareas. - Tarea DTS 2.6: Diseñar el componente de servicios de utilidad. - Tarea DTS 2.7: Diseñar el despliegue de los componentes software en el hardware del sistema. Productos a obtener - Modelo de estructura de objetos (Diagramas de Clases) completo, con todas las clases del sistema. Se puede estructurar mediante diagramas de componentes. - Diagramas de interacción entre objetos. - Diagramas de estado de los objetos de las nuevas clases que sean complejas. - Propiedades de las clases de objetos: tipos de datos de los atributos; punteros que implementan las relaciones entre objetos; atributos y operaciones que implementan los atributos y relaciones derivadas; y restricciones. - Especificación funcional de las nuevas operaciones definidas. - Descripción detallada de la interfaz de usuario. - Esquema de diseño de la Base de Datos, con descripción de las tablas en el caso de una Base de Datos Relacional, normalizando, si se estima conveniente, hasta tercera forma normal 3FN (no se contempla aún el uso de una Base de Datos Orientada a Objetos). - Diagrama de despliegue del sistema Técnicas Además de las empleadas en el diseño lógico, para describir la arquitectura física del sistema se utiliza la técnica de UML denominada «Diagrama de Componentes». El diseño de la distribución de los componentes software en el hardware se lleva a cabo utilizando la técnica de UML denominada «Diagrama de Despliegue». La normalización del diseño de las tablas de la base de datos (cuando se decida utilizar una del tipo relacional) se lleva a cabo aplicando las técnicas de transformación a primera y sucesivas formas normales 3. Conclusiones La principal ventaja que ofrece M2O respecto a otras metodologías orientadas a objeto es que se ha elaborado sobre la base de MÉTRICA v2.1 y, por tanto, facilita a los usuarios de ésta la transición del enfoque estructurado al de objetos. Por otra parte, se trata de una metodología con entidad propia, susceptible de ser utilizada sin conocimientos previos de MÉTRICA. Esto, de hecho, está sucediendo en la Universidad de Alcalá, donde los alumnos de la materia Ingeniería del Software primero conocen M2O y, posterior- mente, MÉTRICA. Esto es razonable si se tiene en cuenta que estos alumnos vienen de cursar varias asignaturas relacionadas con la programación orientada a objetos (especialmente en C++ y Java), por lo que es conveniente aprovechar esos conocimientos recientes para asimilar en primer lugar los principios y técnicas de una metodología orientada a objetos. Por otra parte, M2O ya ha sido aplicada con éxito en varios proyectos piloto de software orientado a objetos, y está siendo utilizada en el desarrollo de aplicaciones de gestión comerciales por parte de una empresa de software en colaboración con la Universidad de Alcalá. También se está utilizando esta metodología para la construcción de Sistemas de Información Documental. Actualmente, el Grupo de Investigación en Ingeniería de la Información y de la Documentación de la Universidad de Alcalá se ha planteado como objetivos inmediatos: el refinamiento de esta metodología, considerando otras posibles opciones de ciclo de vida; la publicación de la especificación completa de M2O; y la finalización de la construcción de una herramienta CASE que servirá de soporte a la metodología. Por supuesto, también habrá que estar pendientes de las novedades que ofrezca de la versión 3 de MÉTRICA en relación con el enfoque de orientación a objetos, lo que, seguramente, aportará nuevas ideas para M2O. 4. Referencias [1] Proyecto MÉTRICA Versión 3. Ministerio para las Administraciones Públicas. http://www.map.es/csi/pg5m42.htm [2] Unified Modeling Language Documentation. UML Resource Center, 1999. http://www.rational.com/uml/resources/documentation. [3] Jacobson, I., Booch, G., Rumbaugh, J.: The Objetory Software Development Process. Addison-Wesley, Menlo Park, 1999. [4] Coleman, D., Arnold, P., Bodoff, S., Dollin, C., Gilchrist, H., Hayes, F., Jeremaes, P. Object-Oriented Development: The FUSION Method. Prentice-Hall, Englewood Cliffs, 1994. [5] Henderson-Sellers, B., Edwards, J.M. BookTwo of Object-Oriented Knowledge: The Working Object. Prentice-Hall, Sydney, 1994. [6] Yourdon, E., Whitehead, K., Thomann, J., Oppel, K., Nevermann, P. Mainstream Objects: An Analysis and Design Approach for Business. Prentice-Hall, Upper Saddle River, 1995. [7] Metodología de Planificación y Desarrollo de Sistemas de Información. MÉTRICA Versión 2.1. Ministerio para las Administraciones Públicas, Madrid, 1995. http://www.map.es/csi/pg5m40.htm [8] Piattini, M. Ciclos de Vida para Sistemas Orientados a Objetos. Cuore, no. 7, pp. 6-11, 1995. NOVATICA jul./ago. 1999 nº140 SECCIONES TÉCNICAS 67 Referencias autorizadas Sección Derecho y Tecnologías (Isabel Hernando) Vinje, T.: Copyright Imperilled?, European Intellectual Property Review, vol. 21, Issue 4 april 1999, pages 192-207. K.Garnett, Q.C., J.R. James, Q.C., G.DavieS: Copinger and Skones James on Copyright, Sweet & Maxwell, 1998 A. Sterling: World Copyright Law, Sweet $ Maxwell, 1998. J. Scherer (Ed): Telecommunication Laws in Europe, Butterwoths, 1998 Sección Enseñanza Universitaria de la Informática (J. Angel Velázquez) Tema: Lenguajes de programación M. Ben-Ari, Understanding Programming Languages, John Wiley & Sons, 1996. Su enfoque es básicamente descriptivo, estudiando sucesivamente diversas construcciones de lenguajes de programación. Se basa principalmente en el paradigma imperativo, mostrando concurrencia, modularización y orientación a objetos como extensiones del paradigma básico. Dedica mucha atención a la implementación de las construcciones y menos a los paradigmas de programación. Se basa en 6 lenguajes (Ada, C, Ada 95, C++, ML y Prolog). Contiene algunos ejercicios al final de cada capítulo, seleccionados para que no sean solamente de programación, sino que ilustren cuestiones lingüísticas. También tiene un apéndice sobre obtención de software. Como guinda, la editorial tiene una página Web sobre el libro, en la que se incluye un capítulo nuevo sobre Java: http://www.wiley.com/college/benari H. L. Dershem y M. J. Jipping, Programming Languages: Structures and Models, PWS Publishing, 2ª ed., 1995. Es un libro bastante completo, que se estructura alrededor de los paradigmas de programación, con descripciones tanto de lenguajes concretos como de construcciones lingüísticas; como contrapartida, no incluye aspectos formales. Las exposiciones son breves pero completas. Se basa en 11 lenguajes (Pascal, Ada, C, Modula-2, FP, Scheme, ML, Prolog, Smalltalk, C++ y Occam) más dos lenguajes ideales (uno lógico, el otro orientado a objetos). Incluye orientaciones sobre cómo planificar una asignatura. Al final de cada capítulo contiene una lista de términos nuevos, preguntas para discusión, ejercicios y prácticas. A. E. Fischer y F. S. Grodzinsky, The Anatomy of Programming Languages, Prentice-Hall, 1993. Es un libro muy completo. Las ideas que guían toda su exposición son la semántica y la abstracción. Se basa en hacer descripciones lingüísticas con el paradigma imperativo. Incluye algunos elementos de paradigmas dispersos por todo el libro, con lo que la presentación de éstos queda algo desfigurada; no estudia la concurrencia. Incluye ejemplos de construcciones de 14 lenguajes, aunque pocos lenguajes se explican sistemáticamente (Miranda y Prolog). Incluye un índice de notas al margen y ejercicios al final de cada capítulo. L. W. Friedman, Comparative Programming Languages: Generalizing the Programming Function, Prentice-Hall, 1991. Tiene tres partes, una descriptiva de elementos de lenguajes de programación, otra de catálogo de lenguajes (donde se describen 6 lenguajes: COBOL, Pascal, Modula2, C, Prolog y Smalltalk) y una última de ampliación (herramientas, etc.). Su calidad es regular. No trata de forma general más paradigmas de programación que el imperativo, inconveniente que se nota en la parte descriptiva. Asimismo, la selección de los lenguajes está hoy en día un poco desfasada; no incluye ningún lenguaje concurrente. La parte tercera puede ser interesante como visión general para una asignatura sobre herramientas o entornos de programación. Al final de cada capítulo incluye un resumen y términos claves (parte I), o unos escasísimos ejercicios (parte II) o preguntas para discusión y términos claves (parte III). En la parte II, toma 4 programas de muestra para desarrollar con cada lenguaje. C. Ghezzi y M. Jazayeri, Programming Language Concepts, John Wiley & Sons, 3ª ed., 1998. Se basa en realizar descripciones de elementos de lenguajes, sobre todo con el paradigma imperativo (usa 6 lenguajes: C, C++, ML, Ada 95, Java, Eiffel), con algunos elementos de paradigmas. Tiene un formato incómodo para leer, con un tamaño de letra grande y un índice sin estructuración apenas (sin sangrado). (La portada, sin embargo, es afortunada, ya que reproduce la piedra Rosetta, que está escrita en tres lenguas.) El texto tiene pequeñas notas al margen sobre temas relacionados. El último capítulo da una breve panorámica de la evolución actual de los lenguajes de programación. Incluye muchos ejercicios al final de cada capítulo. Los autores tienen una página Web con información sobre el libro, incluyendo un intérprete de la máquina abstracta SIMPLESEM usada en el capítulo 2: http://www. infosys.tuwien.ac.at/pl-book Sección Informática Gráfica (Roberto Vivó) Tema: Actas del IX Congreso Español de Informática Gráfica (ISBN: 84-89869-81-2) Durante los pasados días 16,17 y 18 de Junio se celebró en Jaén el Congreso Español de Informática Gráfica (CEIG’99) en su novena edición. En él participaron ponentes de la mayoría de las universidades españolas destacando la alta participación y calidad de los artículos presentados. Durante el congreso tuvieron lugar tres conferencias invitadas a 68 cargo de los profesores D. Terzopoulus de la Universidad de Toronto sobre "Vida artificial", H.P. Seidel del Intituto Max Planck sobre "Simplificación y multirresolución de mallas" y D. Comas de la Universidad de Girona sobre "Internet e información geográfica de consumo". Además se presentaron un total de 23 ponencias y 25 comunicaciones cortas abarcando desde la investigación básica hasta el desarrollo de aplicaciones en los ámbitos de la síntesis de imagen, multimedia, informática gráfica médica, realidad virtual, internet, etc. Los resúmenes de las conferencias así como los 23 artículos completos y las 25 comunicaciones cortas se han publicado en las Actas del Congreso editadas conjuntamente por la Universidad de Jaén, la sección española de Eurographics y ATI. Las actas gozan de una gran calidad tanto de forma como de contenido y son el mejor vehículo para viajar por la investigación que hoy se desarrolla en el país sobre informática gráfica, descubriendo el interés despertado por esta materia en las diferentes universidades como respuesta a una demanda social cada vez más exigente. Por citar algunas aplicaciones presentadas cercanas al ámbito socio-industrial valgan como ejemplos las del simulador de helicóptero, el simulador de grúas pórtico, los entornos virtuales multiusuario, la aplicación de métodos de ingeniería inversa para el diseño o la visualización volumétrica de estructuras óseas. Sección Ingeniería de Software (Luís Fernández Sanz) 1.http://www.bcs.org.uk/sigist/index.html Éste es el sitio del grupo especial sobre pruebas de software de la BCS (British Computer Society), con interesantes vínculos a otros sitios sobre este tema y recursos sobre el tratamiento del año 2000. 2. http://www.omg.org/library/downinst.html El sitio del OMG (Object Management Group) que ya hemos mencionado anteriormente permite la descarga de algunos documentos sobre la tecnología de objetos referidos a temas como CORBA, UML, etc. tanto en forma de informes (whitepaperes) o de especificaciones formales de esta organización. Sección Interacción Persona-Computador (Julio Abascal) Tema: El curriculum de Interacción Persona-Computador (I) Hasta donde yo conozco, actualmente la Interacción Persona-Computador (IPC) no aparece como materia obligatoria de ningún curriculum universitario impartido en España. Sin embargo muchos de los nuevos planes de estudios de la Ingeniería Informática empiezan a incorporar alguna asignatura optativa que puede ser encuadrada en este campo. En NOVATICA jul./ago. 1999 nº140 la mayoría de los casos se hace énfasis en las herramientas y técnicas de programación de interfaces y se descuidan los aspectos metodológicos y de usuario: técnicas de interacción, métodos para caracterizar a los usuarios, ingeniería de la usabilidad, procedimientos de prueba y evaluación, etc. La falta de tradición en todo lo relacionado con la IPC crea dificultades a la hora de decidir el contenido y la orientación de este tipo de asignaturas. Vamos a repasar algunos materiales producidos por el ACM SIGCHI1 , de los que se puede echar mano para suplir esta carencia. Partamos de un documento básico, como es el ACM SIGCHI Curricula for Human-Computer Interaction2 , publicado en 1992, que ofrece una bien razonada propuesta para la creación de un curriculum completo en IPC, aunque resulte de poca aplicabilidad hoy en día entre nosotros. Sin embargo, también propone cuatro asignaturas del área de la IPC para ser impartidas en los estudios de Informática, que están más cerca de nuestras necesidades. Dos de estas asignaturas están más orientadas a la tecnología: "Diseño y desarrollo de la interfaz de usuario" y "Teorías y fenómenos de IPC" y las otras dos hacia los aspectos humanos: "Psicología de la IPC" y "Aspectos humanos de los sistemas de información". La primera y la última tienen un enfoque práctico y general mientras que la segunda y la tercera son más especializadas y orientadas a la investigación. A pesar de su notable interés, esta propuesta está pensada para el modelo de curriculum norteamericano y su aplicación en nuestro entorno requiere una profunda adecuación. Este mismo grupo de trabajo publica desde 1994 el ACM SIGCHI Education Survey3 de G. Perlman y J. Gasen, que consiste fundamentalmente en una actualizada compilación de programas, facultades y asignaturas del área de IPC impartidas en un gran número universidades de todo el mundo, pero especialmente norteamericanas. Con un enfoque más cuantitativo que cualitativo, carece de justificaciones del contenido y estructura de los cursos. Su mayor interés son las referencias a la bibliografía y las herramientas empleadas en las prácticas de cada asignatura. Por otro lado, la revista SIGCHI bulletin4 publica mensualmente una interesante columna dedicada a Educación en HCI. En ella aparecen discusiones, ideas, experiencias, grupos de trabajo en desarrollo de curricula, etc. Como ejemplo de los diversos enfoques, se pueden mencionar el artículo de J. A. Jacko5 que presenta la función de los estudios de IPC dentro de la Ingeniería industrial o el de M. Mantey6 sobre la enseñanza de los aspectos psicológicos que intervienen en la IPC. Por último, quisiera mencionar un intersante artículo de S. Greengberg, "Teaching Human-Computer Interaction to Programmers"7 , que describe en detalle un curso de IPC impartido en la Universidad de Calgary. Greengber argumenta sobre cómo dar a los estudiantes que pretenden ser programadores, los conocimientos necesarios para que puedan aplicar las técnicas de IPC en su trabajo de cada día. Tanto el artículo como el material de clase8 pueden ser muy útiles para quien quiera impartir un curso introductorio de IPC a los alumnos de los primeros años de Informática. NOVATICA jul./ago. 1999 nº140 Evidentemente el material disponible sobre enseñanza de la Interacción Persona Computador no se agota con estas notas. Dado el indudable interés que tiene el curriculum en IPC, en próximos números seguiremos tratando este tema desde otros ángulos. Sección Seguridad (Javier Areitio Bertolín) Kosiur, D. Building and Managing Virtual Private Networks. John Wiley & Sons, Ltd. Chichester. UK. 1998. Jeruchini, M.C., Balaban, P. and Shanmugan, K.S. Simulation of Communication Systems. Plenum Press. New York. 1999. Rowlett, F.B. and Kahn, D. The Story of Magic: Memoirs of an American Cryptologic Pioneer. Aegean Park Press. 1998. Walke, B.H. Mobile Radio Networks. John Wiley & Sons, Ltd. Chichester. UK. 1999. Salomaa, A. Public-Key Cryptography. Springer Verlag. 1996. Whitaker, R. The End of Privacy: How Total Surveillance Is Becoming a Reality. New Press. 1999. Gleason, A.M. Elementary Course In Probability for The Cryptanalyst. Aegean Park Press. 1998. Kovacich, G. The Information Systems Security Officer’s Guide: Establishing and Managing an Information Protection Program. Butterworth-Heinemann. 1998. Kippenhahn, R. Code Breaking: A History and Exploration. Overlook Press. 1999. Overly, M.R. E-Policy: How to Develop Computer, EPolicy and Internet Guidelines to Protect Your Company and Its Assets. Amacon. 1998. Langie, A. Cryptography: A Study on Secret Writings. Aegean Park Press. 1998. Erne, M. Digital Audio Compression. John Wiley & Sons, Ltd. Chichester. UK. 1999. Boni, W. and Kovacich, G.L. I-Way Robbery: Crime on the Internet. Butterworth-Heinemann. 1999. Beckett, B. Introduction to Cryptology and PC Security. McGraw-Hill Book Co. Ltd. 1997. Blake, I.F., Seroussi, G. and Smart, N.P. Elliptic Curves in Cryptography. Cambridge University Press. 1999. Sección Tecnología de Objetos (Esperanza Marcos) 69 desarrollo basado en componentes utilizando notación UML. El libro presenta una aproximación a la utilización de objetos, frameworks y notación UML, para el diseño, construcción y reutilización de componentes software. Sección Tiempo Real (Juan Antonio de la Puente, Alejandro Alonso) A. Burns, A. Wellings. Real-Time Systems and Programming Languages. 2nd ed., Addison-Wesley, 1997. Excelente libro de texto sobre programación de sistemas de tiempo real. El libro trata los conceptos más importantes relacionados con este tipo de sistemas, sobre todo los que se refieren a fiabilidad y tolerancia de fallos, concurrencia, planificación de tareas y análisis de tiempos, desde el punto de vista de su realización mediante varios lenguajes de programación: C, Ada 95 y Occam. También se estudian los servicios de sistemas operativos ofrecidos por las normas POSIX para sistemas de tiempo real. Los capítulos finales contienen una introducción a las técnicas de análisis de tiempos de respuesta en sistemas con prioridades fijas muy completa y actualizada. El libro resulta muy adecuado como texto básico para cursos de sistemas de tiempo real, y también como libro de referencia para profesionales interesados en estos temas. P. Laplante. Real-Time Systems Design and Analysis. An Engineer’s Handbook. 2nd. ed., IEEE Press, 1997. Como su título indica, se trata de un manual de tipo general sobre sistemas de tiempo real destinado a profesionales. Esta obra puede considerarse complementaria de la anterior, pues aunque su tratamiento de los lenguajes y técnicas de programación es muy superficial, contiene material muy interesante sobre otros temas de gran interés, como métodos de especificación y diseño, sistemas operativos, análisis de prestaciones mediante técnicas estadísticas, integración y pruebas. Hay que señalar, sin embargo, que algunos de los capítulos no están tan actualizados como sería de desear, y que el espacio dedicado a temas tan interesantes como el diseño mediante objetos y el análisis de tiempos de respuesta es muy reducido. Sección Software Libre (Jesús M. González Barahona, Pedro de las Heras Quirós) ESR escribe de nuevo M. Shaw y D. Garlan. Software Arquitecture. Perspectives on an Emerging Discipline. Prentice Hall, 1996. Este libro proporciona una visión general de los distintos estilos arquitectónicos, tanto desde un punto de vista teórico como práctico. Se analizan además aspectos de diseño, así como lenguajes y modelos de especificación formal para arquitecturas software. D. F. D’Souza y A. Cameron Wills. Objects, Components, and Frameworks with UML. The CatalysisSM Approach. Addison Wesley, 1999. Catalysis es un método para el Hay un nuevo artículo de Eric S. Raymond, sobre la economía del software libre: The Magic Cauldron. En este ensayo, Eric trata de explicar, desde varios puntos de vista, cómo funciona (y por qué funciona) el modelo de desarrollo del software libre.http://www.tuxedo.org/~esr/writings/magiccauldron/ Libro sobre Debian Ossama Othman y John Goerzen han terminado un libro NOVATICA jul./ago. 1999 nº140 70 sobre Debian, una de las distribuciones de GNU/Linux más utilizadas. El libro se titula Debian GNU/Linux: Guide to Installation and Usage. Será publicado (se espera que esté a la venta durante julio) por Macmillan Computer Press / New Riders. Un aspecto muy interesante es que el libro se distribuye bajo licencia GPL, lo que hace que pueda ser copiado libremente. Admás, la editorial donará a la FSF (Free Software Foundation) una parte de los ingresos debidos a su venta. Se espera que el libro esté íntegro en el WWW. http://www.newriders.com/0914-9.htm contrato con Intel, y se ha centrado en la optimización para el Pentium II". Sun libera código Java bajo licencia tipo Apache Sun Microsystems y el Apache Group han anunciado un acuerdo según el cual el código fuente del JavaServer y de los Servlet será distribuido bajo una licencia libre como la de Apache. Esta es la primera vez que Sun libera código fuente de Java bajo una licencia libre. El nuevo proyecto se ha llamado Jakarta. Más info en http://jakarta.apache.org Música libre Notas Jaron Lanier ha escrito un ensayo titulado Piracy is your friend (La piratería es tu amiga) que trata sobre música digital libre. Entre otras cosas, asegura que un músico puede ganar más dinero si su música se distribuye libremente con los medios digitales disponibles en la actualidad (por ejemplo, en formato MP3) que con los mecanismos clásicos que implican contratos con casas discográficas.http:// www.musicisum.com/manifesto.shtml Hardware Libre Richard M. Stallman, fundador de la Free Software Foundation y reconocido hacker (autor de GNU/C, GNU/ GDB, GNU/Emacs,...) ha publicado una columna en Linux Today, dedicada al tema del hardware libre, por similitud con el software libre. En ella dice: "Preguntarse acerca de la posibilidad de copiar el hardware no tiene sentido, ya que es una tarea difícil. Yo no veo que la copia de diseños hardware sea un imperativo social, como sí lo es el imperativo social del software libre. La libertad de copiar software es un derecho importante porque ahora es fácil copiarlo (cualquier ordenador puede hacerlo). Los chips actuales y la tecnología de fabricación de tarjetas se parecen a la tecnología de la imprenta. Copiar hardware es tan difícil como lo era copiar libros en la época de la imprenta, o incluso más. Por ello los aspectos éticos de la copia de hardware son como los aspectos éticos suscitados por la copia de libros hace 50 años, y no como los suscitados por la copia del software hoy día. Texto completo del artículo de Stallman: http:// linuxtoday.com/stories/6993.html Foro HispaLinux en la party de Benaguasil Por segundo año consecutivo se ha organizado una party en Benaguasil. La party tendrá lugar entre los días 23 y 25 de Julio y será multidisciplinar, al igual que la celebrada en la edición anterior. En el marco de esta party se celebra el III Foro Hispalinux, habilitándose zonas especiales para conferencias, debates, foros y cursos. http://party.benaguasil.org/ index3.html Intel y Cygnus donan un nuevo dorsal del compilador GNU/C En un mensaje enviado a las listas de la distribución egcs del compilador GNU/C, Richard Henderson, de la compañía Cygnus anunciaba: "En nombre de Cygnus, tengo el gusto de anunciar la donación de un nuevo dorsal (backend) para la arquitectura IA-32. El trabajo se realizó gracias a un 1 Grupo de Interés Especial en Interacción Persona-Computador (Special Interest Group on Computer-Human Interaction , SIGCHI) perteneciente a la Association for Computer Machinery (ACM) 2 T. Hewett et al. ACM SIGCHI Curricula for HumanComputer Interaction. Report of the ACM SIGCHI Curriculum Development Group. ACM, 1992. (también disponible en: http://www.acm.org/sigchi/cdg y en ftp:// archive.cis.ohio-state.edu./pub/hci/CDG) 3 Para que sea posible su actualización permanente, este estudio está disponible a través de Internet en la dirección http://www.acm.org/sigchi/educhi/ 4 http://www.acm.org/sigchi/bulletin 5 Julie A. Jacko. "HCI Education and Its Role in Industrial Engineering". Sigchi Bulletin, Vol. 30, No. 1, pp. 5-6 6 Marilyn Mantey-Tremaine. "A Psychologist Astray in Computer Science" Sigchi Bulletin, Vol. 30, No. 2, pp. 913 7 Saul Greenberg, "Teaching Human-Computer Interaction to Programmers". ACM Interactions Vol. III, No. 4, pp. 6272. 8 Todos los materiales de este curso están disponibles a través de Internet: http://www.cpsc.ucalgary.ca/~saul/481/ index.html NOVATICA jul./ago. 1999 nº140 SOCIEDAD DE LA INFORMACION 71 Personal y transferible Antonio Vaquero Escuela Superior de Informática,Universidad Complutense de Madrid; Computing Research Laboratory,New Mexico State University, Las Cruces, NM La Lengua Española en el contexto informático Programa de estancia de investigadores españoles en el extranjero del Ministerio de Educación y Ciencia de España. <[email protected]> <[email protected]> 1. La inquietud por el español Existe una inquietud permanente por nuestra lengua. Últimamente se ha agudizado una desazón debida al uso incorrecto de la misma, sobre todo cuando su difusión es masiva, como ocurre en los medios de comunicación: TV y prensa fundamentalmente. Dice Domingo Ynduráin que los medios reflejan simplemente la realidad de la cultura social imperante. Es cierto. Ahí está la realidad, detectada en encuestas sociológicas fiables cuyo resultado más alarmante es que una buena parte de nuestros jóvenes no saber leer comprensivamente con comodidad. No digamos escribir con corrección. Con el libro El dardo en la palabra Fernando Lázaro Carreter intenta que tomemos conciencia del alcance de ese fenómeno. Parece que esta preocupación va tomando cuerpo en el ámbito de nuestra comunidad lingüística. No es éste el lugar para analizar el desarrollo y los resultados de estas reuniones sobre nuestro idioma, sino constatar la importancia que se le está concediendo a nuestra lengua y la inquietud que suscita su uso. Siempre será poca. Los lingüistas están preocupados. El mundo de la Ciencia y la Tecnología no debe estar ausente de esa preocupación. Con esa intención se presentan estas líneas. La lengua es muy importante para que sólo esté al cuidado de los lingüistas. Cuidémosla entre todos. 2. Influencia de la informática en el lenguaje Los lingüistas están preocupados por nuestra lengua. Los científicos, en particular los informáticos, hemos de entonar un mea culpa porque la Informática corrompe el lenguaje. Hemos de hacer un esfuerzo para impedir esa corrupción, sobre todo por parte de los educadores. Y no solamente para impedir la corrupción del lenguaje, sino también para enriquecerlo. Hay muchos acontecimientos que parecen demostrarlo, tanto en España como en Hispanoamérica. Empezando por ésta,destaca el I Encuentro Internacional de la Lengua Española (Zacatecas, México, 7 al 12 de abril de 1997), especialmente dedicado al análisis del español empleado en los medios de comunicación, con atención al efecto que en él producen las nuevas tecnologías. La terminología informática es causa de frecuentes y apasionadas disputas, generalmente desde posiciones irreflexivas e intolerantes. Cuando la masificación de la Informática es innegable urge poner un poco de orden en un tema tan importante como el uso de nuevas palabras. También se han celebrado otras reuniones, seminarios y congresos recientemente en España sobre el español y su uso. En octubre del mismo año tuvo lugar otra actividad pública relevante sobre el tema que nos ocupa, la Mesa Redonda con el título El español en el Mundo. La lengua española ante el tercer milenio, en el marco del Club de Debate de la Universidad Complutense de Madrid. La Informática es una materia muy joven, aunque sus fundamentos son muy antiguos, pues están enraizados en la Matemática. La propia palabra Informática nació en la década de los 60. Es impresionante lo que ha crecido la Informática desde el nacimiento de la primera computadora moderna (de estructura Von Neumann).Apenas ha transcurrido medio siglo desde entonces y la realidad ha corrido mucho más que la imaginación. De ser un curioso objeto de laboratorio para iniciados se ha convertido en un fenómeno de masas. En noviembre de ese mismo año tuvo lugar un importantísimo ciclo de conferencias, organizado por la Fundación Ramón Areces, con el título El español en el mundo,en el que intervinieron miembros de la Real Academia Española y de otras Academias del mundo hispánico. En agosto de 1998 se desarrolló el curso El español en la sociedad de la información (hptt://www.ucm.es/info/ espasoci) como uno de los Cursos de Verano de la UCM. En él intervinieron representantes destacados de los sectores influyentes en el tratamiento, la presentación y la imagen de nuestro idioma en el mundo actual, con especial énfasis en los medios de comunicación, la Informática y las Comunicaciones, sobre todo en Internet. Muchas veces el lenguaje se corrompe con giros y palabras que incorporan la metáfora de la computadora inadecuadamente. "Tengo el chip cambiado" se dice cuando no se tiene claridad mental, por ejemplo. El fenómeno lingüístico inverso es lo que ocurría cuando a las computadoras se las llamaba "cerebros electrónicos". Es decir, se echó mano de la metáfora antropológica para hablar de las máquinas. De eso tuvo mucha culpa la prensa norteamericana de finales de los años 40 y durante los 50, que hablaba sensacionalistamente de los electronic brains. Felizmente esa época ya pasó. De cualquier manera, mediante la metáfora directa o la inversa, hay una tendencia a usar la Informática corrompiendo el lenguaje. 72 La ubicuidad de la Informática se manifiesta en los hábitos de la sociedad. Los modos de manifestarnos y comunicarnos en la llamada sociedad conectada (wired society) son nuevos. Particularmente la influencia de la Informática se percibe en el lenguaje de forma muy sensible. No sólo en el lenguaje técnico sino también en el lenguaje de la calle. Ciertas circunstancias relacionadas con la Informática pueden perjudicar el buen uso de la lengua materna. Existe un peligro cierto de inmadurez en el lenguaje con el uso intensivo de las computadoras. Los jóvenes usuarios fanáticos (hackers) en los EE. UU. de Norteamérica hablan una jerga que se llamó technobable. To bable es un verbo inglés para expresar cómo hablan los bebés. ¿Quiere decir ello que no debemos usar las computadoras so pena de empobrecer nuestro lenguaje? No. Ni mucho menos. Pero sí que debemos atender antes al lenguaje que a las computadoras. El lenguaje es lo más importante. Sin un dominio del lenguaje es imposible comunicarnos. Los lenguajes informáticos no son más que subconjuntos sencillos del lenguaje natural. Un gran informático, Egder W. Dijkstra, dejó dicho que para programador es preferible una persona con dominio de su lengua materna antes que un matemático sin esa habilidad. Por desgracia el índice de jóvenes que accede a la Universidad en nuestra comunidad lingüística sabiendo leer comprensivamente y escribir correctamente el español es bajo. Es imprescindible fijar como objetivo fundamental del cambio educativo la corrección de ese índice. Las demás consideraciones sobre la Enseñanza Secundaria son subsidiarias del objetivo antedicho. Es seguro que ese déficit no está provocado por el uso de la Informática. Pero es necesario que la Informática no perturbe el buen uso de la lengua. Y no sólo que no lo perturbe, sino que lo respete y enriquezca. Los responsables de la enseñanza y difusión de la Informática en la sociedad han de atender con sumo cuidado a ese respeto y enriquecimiento. El profesor en su clase, las interfaces persona-máquina de los sistemas informáticos y los medios de comunicación, que son los agentes difusores, han de obedecer al principio de respeto y enriquecimiento del lenguaje. Ello es difícil por la velocidad a que se generan nuevos conceptos, dispositivos, programas, lenguajes de programación, sistemas, etc. en Informática y, en general, en Tecnologías de la Información y de las Comunicaciones. Pero es exigible. La corrupción existe en cualquier lengua. Aquí intentamos poner de manifiesto ese fenómeno universal provocado por la rápida difusión de las nuevas tecnologías, en particular por la Informática y las Comunicaciones y vamos también a contemplarlo en el caso del español. Si no ¿de qué examen de conciencia ni de qué propósito de enmienda estamos hablando? 3. Cohesión contra corrupción Por lo que se refiere a nuestra lengua, de este tipo de cuestiones se ocupó el Encuentro de Zacatecas, del que tanto y tan alto se habló. Se dijo, entre otras muchas cosas, que una de las partes más débiles (?) del español es la tecnológica. NOVATICA jul./ago. 1999 nº140 Independientemente de lo que se entienda por débil, la comunidad científica debe hacer un examen de conciencia y quizás un propósito de enmienda. Es ésa la intención de estas líneas y no la de entrar en polémica, a favor o en contra de tales o cuales propuestas o contrapropuestas. El panorama observable parece muchas veces hacer caso omiso de la exigencia de respeto por nuestra lengua. La realidad cotidiana nos presenta muchos casos de flagrantes incorrecciones. ¿Quién no ha leído en la pantalla de su computadora la palabra 'comando'?, por ejemplo. 'Lenguaje de comandos' es la traducción habitual al español de command language en los sistemas castellanizados. Si nos tomamos la molestia de consultar el diccionario (¡ay!) veremos que comando no tiene ninguna acepción que pueda ser asociada, ni remotamente, al concepto command, que debe ser traducido por 'orden'. A la computadora se le comunica una 'orden' para que la interprete (la reconozca y la ejecute), no un 'comando', que es... Mírese en un diccionario, p.e. el DRAE, por favor. En cambio la acepción número 18 de la palabra 'orden', en ese mismo diccionario (edición de 1992, la última) es: Mandato que se debe obedecer, observar y ejecutar. Ese significado de 'orden' en la vida cotidiana es trasladable al ámbito de la Informática. Por tanto command debe ser traducido por 'orden' y no por 'comando'. 'Comando' es un ejemplo de traducción 'fonética', o sea, traduciendo por la palabra española que "suene" lo más parecido posible. De command, comando. De move, mover. De link, lincar (¿o linkar?). Etc. Eso no es serio. Eso es fácil, pero no es correcto. Esa funesta manía de "españolizar" sin mayores reflexiones corrompe innecesariamente nuestra lengua. A veces la culpa no es nuestra, sino de nuestras fuentes. Nuestras fuentes son dos, esencialmente. La principal es el inglés, pero también tenemos una fuerte influencia del francés. ¿Términos incorrectos de Informática en inglés? Sí. P.e. compiler, que nosotros traducimos por 'compilador'. Ni en inglés ni en español existían acepciones del verbo to compile (compilar) que significaran nada parecido a 'traducir' de un lenguaje informático (de alto nivel) a otro (de bajo nivel). Por tanto compiler debería cambiarse en inglés por translator o transducer o algo parecido y en español debería decirse 'traductor' y no 'compilador'. ¿Términos incorrectos de Informática en francés? Sí. P.e. ordinateur, que en España se traduce generalmente por 'ordenador', aunque la inmensa mayoría de hispanohablantes lo traducen por 'computador/a'. Conviene rastrear esta palabra desde sus orígenes. Habría que hacerlo con todas en las que existe discrepancia; es decir con todos los términos sinónimos. Veamos el motivo. Permítasenos invocar un paradigma lingüístico cuya fuente, para mí al menos, es el académico Gregorio Salvador. En síntesis, lo que se predica es hacer un esfuerzo por mantener la cohesión del lenguaje. Cohesión procede de "cohaesum", supino del verbo latino "cohaerere", que significa estar unido. De acuerdo a ese principio, parece claro que un mismo concepto u objeto informático no debe recibir nombres distintos dentro de una misma comunidad lingüística. NOVATICA jul./ago. 1999 nº140 No merecería la pena escribir estas líneas sin estar convencido de la importancia de intentar mantener, dentro de los límites razonables, un español cohesionado en estas parcelas nuevas de la cultura. Hay que propagar la inquietud por la cohesión del español cuando en el discurso está involucrada la Informática. Es oportuno porque los medios han tomado parte en ese discurso y, por tanto, la difusión del mismo se hace masiva. También es legítimo intentar transmitir esa inquietud a través de los mismos medios utilizados para difundir ese discurso. Las reflexiones terminológicas son necesarias, sobre todo en los ámbitos de difusión amplificadora como la docencia y los medios de comunicación masivos. Como muestra basta un botón. Parece lógico comenzar por el término 'ordenador'. Cualquier españolito de a pie se preguntará: ¿Quién no ha pronunciado esa palabra en español? ¿Pero es que hay otras? Veamos, veamos. Los términos 'ordenador' y 'computador/a' no son más que una muestra, aunque , eso sí, muy significativa, de la diversidad existente en nuestra comunidad lingüística sobre el uso de palabras nuevas debidas a la Informática y, en general, a la Ciencia y la Tecnología. Ante esta diversidad caben algunas preguntas. ¿Qué términos se deben usar? ¿ Se debe hacer algo para unificar la terminología informática? ¿Se puede hacer algo? ¿Tiene sentido hacerlo? Existe una preocupación real por defender el idioma de un uso irreflexivo y, por tanto, incorrecto del mismo. No es nuestro objetivo, aquí y ahora, analizar esta importante cuestión general, quizá la más importante cuestión actual de la cultura hispánica. Pero sí recalcar la importancia de la cohesión. Describamos en primer lugar el ámbito geográfico donde el término y sus homónimos son usados. En España el término 'ordenador' está muy extendido para designar a 'la máquina' por excelencia de la Informática. Hay una minoría, en general universitaria, que usa indistintamente los términos 'computadora' (o 'computador') y 'ordenador'. Muchos menos somos los que sólo usamos el término 'computadora'. Pero solamente en España se usa la palabra 'ordenador', que es absolutamente desconocida en América. La comunidad americana de habla española sólo usa la palabra 'computador' y también 'computadora', aunque esta última en menor medida. Aun no hemos aludido a todos los homónimos de 'ordenador' que se han usado en español. Antes que 'ordenador', en España se usó la palabra 'calculadora'. 'Calculator' aparece antes que 'computer' en la literatura germinal de las computadoras. Así, la máquina desarrollada en 1944, bajo la dirección del Profesor Aiken en la Universidad de Harvard, era referida como Mark I o Automatic Sequence Calculator. El Profesor García Santesmases (+ 1989) pasó un tiempo trabajando con el grupo de las Marks. Por él se introdujo en nuestro país la palabra 'calculadora', para designar lo que mucho después se llamaría 'ordenador'. 'Calculadora' fue pues el primer término con que se conocieron estas máquinas en España, termino que se usó extensamente en la década de los sesenta, como se comprueba más adelante, e incluso llega a la de los setenta. Desde entonces se aplica sólo a las máquinas de mano con teclas numéricas y funcionales. Vamos a rastrear ahora el origen de la palabra 'ordenador'. Trasladémonos a Francia. Hacia 1962 aparecen dos palabras nuevas en los ambientes universitarios franceses: 73 Informatique y Ordinateur. Ambas tienen una rápida difusión y aceptación en el país vecino. Por ejemplo en 1963 ya existía en la Facultad de Ciencias de la Universidad de Toulouse un Laboratoire d’Informatique. En España se adoptó rápidamente la palabra Informática, pero esa rapidez no se dio con la palabra 'ordenador'. Prueba de ello es la traducción del libro IFIP-ICC Vocabulary of Information Processing, Ed. North Holland, 1966. Dicha traducción fue hecha por un grupo mixto de informáticos procedentes de la Universidad, del C.S.I.C. y de la industria informática, por lo que representa fielmente el estado de la Informática española en aquel tiempo. Pues bien, computer se tradujo por 'calculadora'. La palabra 'ordenador' aparece escrita por primera vez en un diccionario de Informática en español en 1972. Es el Diccionario-Glosario de Proceso de Datos Inglés-Español, IBM, 1972. La adopción del galicismo tiene un éxito fulgurante, directamente proporcional al crecimiento de usuarios de Informática, influidos por los profesionales comerciales. En la Universidad y los Centros de Investigación el número de personas y los medios dedicados a la Informática no crecían al ritmo que requerían los tiempos. No dio tiempo a reparar en este fenómeno lingüístico. Bastante había con hacer lo que se podía, como para preocuparse, además, de los fenómenos sociolingüísticos. Todos adoptamos la palabra 'ordenador'. Pero ¡es tan apasionante la lengua! Sobre todo para un profesor. Es imposible sustraerse al impulso de reflexionar sobre la mejor forma de comunicar conocimiento. Y con el tiempo uno se va preguntando sobre el origen y la corrección de las palabras que emplea, así como de las que emplean los otros. El origen ya lo conocemos. Ahora bien, vamos al fondo. ¿Qué significa ordinateur? No se debe entrar al trapo de los que defienden el uso de la palabra ordenador porque éste realiza 'ordenaciones' (operaciones de ordenación). Puede hacer más, muchísimo más, que ordenar elementos ordenables. Admitir esa denominación por esa causa sería como admitir la designación del todo por una parte solamente. Tampoco es válido el argumento basado en la acepción de 'orden' como 'instrucción'. Ordinateur viene definido en francés así "...qui émite ordres". En definitiva, quien da órdenes, no quien las recibe. Por tanto el uso de la palabra ordenador es una incorrección semántica. No lo digo yo. Lo dicen los propios franceses. Los mismos que contribuyeron a la creación, difusión y aceptación del término. Danzin, Leprince-Ringuet, Mercourof, ... y muchos más estaban presentes en un debate durante un encuentro titulado Les jeunes, la technique et nous, celebrado en Estrasburgo en noviembre de 1984. Se presentó la ocasión de analizar el papel de la Terminología Técnica en la Enseñanza con medios informáticos. Yo aproveché la oportunidad para señalar, según mi criterio, aciertos (p.e. Informatique) y desaciertos (p.e. Ordinateur) en la creación de nuevos términos franceses. Pues bien, admitieron los argumentos aquí expuestos con respecto a ordinateur. La contestación, sintetizada por Mercourof, fue "le mot n’est pas bon, mais nous n’avons pas trouvé d’autre meilleur", muy aproximadamente, si no literalmente. ¿Qué se hace en España sobre la utilización de los diversos términos? Siendo conscientes de la incorrección del uso de 74 la palabra 'ordenador', cuando nos dirigimos genéricamente a destinatarios de la comunidad hispanohablante, o a un miembro no español de la misma, empleamos el término 'computador/a'. Sin embargo, cuando el destinatario es español, solemos usar el término 'ordenador'. Es decir, constatamos un hecho, el estado de descohesión lingüística, y lo mantenemos. Somos conscientemente incoherentes. Los hispanoparlantes de otros continentes no. Siempre usan 'computador/a', siempre. Y no van a cambiar. Tienen la razón de la fuerza numérica, pues son casi diez veces más que nosotros. Y nosotros, los españoles, carecemos de argumentos lingüísticos sólidos para convencerles. ¿Qué podemos hacer en España? Sería más lógico que, si hay que hacer algún cambio, lo hiciésemos nosotros, los españoles. Deberíamos hacerlo en aras de la cohesión de nuestra lengua. Sería hermoso el no seguir ejerciendo el españolísimo "sostenella y no enmendalla". En cuanto al género, éste carece de importancia. Un 'computador' (masculino) es un sistema (masculino) y una 'computadora' (femenino) es una máquina (femenino). Pero es curioso que sólo se diga 'ordenador' y no 'ordenadora', salvo en Gibraltar (los "llanitos" también pertenecen a nuestra comunidad lingüística). Estas curiosidades quedan para los estudiosos de los fenómenos sociolingüísticos. Antes de difundir términos nuevos, como 'ordenador' que pueden ser incorrectos, deberíamos pensárnoslo. Los fenómenos sociales tienen una inercia muy grande. Cuando se comete una incorrección lingüística de cierto arraigo social, cuesta mucho tiempo corregir el lenguaje. No lo corrompamos o, al menos, intentemos no corromperlo. El fenómeno de la difusión se amplifica enormemente hoy a través de Internet. Ahora bien la propia tecnología, correctamente usada, puede servir para remediar la situación. P.e. existe una lista de usuarios con este mismo interés común en el correo electrónico ([email protected]) de Internet. Se intercambian puntos de vista, con alto nivel técnico y lingüístico, personas de este y del otro lado del "charco", para que éste no represente barrera alguna al deseable enriquecimiento del español por la tecnología, intentando asegurar su cohesión y evitar su corrupción. También se mantienen en Internet otros foros sobre el español en general, como el del Instituto Cervantes y "el español urgente" de la agencia de noticias EFE. 4. Expresividad y eficacia Nuestra lengua es más fácilmente corruptible que otras, entre otras cosas porque nuestra comunidad no es fuente de referencia frecuente en Ciencia, mucho menos en Tecnología y muchísimo menos en la repercusión social de nuestra Ciencia y nuestra Tecnología. Quizá sea éste el "mea culpa" esencial, del que deriva la corrupción. Claro que este "mea culpa" histórico no es atribuible sólo a la comunidad científica. Pobrecita ella. Es una de las asignaturas pendientes más importantes de nuestra sociedad. Pero una vez hecha confesión de nuestros pecados, es hora también de que los científicos, en particular los informáticos, digamos lo que nos proporciona, o no nos proporciona, el lenguaje para expresar nuestras ideas. Nuestra lengua también nos preocupa. NOVATICA jul./ago. 1999 nº140 Muchos de los análisis y opiniones sobre esta preocupación se centran en la influencia del inglés sobre el español. Esa influencia se debe a una dominancia cultural, real y comprobable. Nosotros no inventamos. Nosotros traducimos. Y ni siquiera eso. Muchas veces nos traducen. Nos suplantan en la labor de traducción. Si se miran en las pantallas de las computadoras los mensajes de los programas castellanizados de uso extendido, se deduce que el traductor desconoce el español. Y lo que se dice de los sistemas informáticos se puede decir de los folletos comerciales. Otras veces es peor aún; es decir ni siquiera se traduce cuando el caso lo requiere. Es frecuente encontrar folletos comerciales y rótulos o mensajes públicos en el extranjero que están expresados en un conjunto de lenguas, excluida la española. ¿Qué defensa se ha hecho de nuestra lengua por nuestros poderes públicos y nuestras instituciones? ¿Cómo se puede estar aguantando impávidamente esos insultos y ese desprecio, por comisión u omisión, a nuestra lengua? En nuestra opinión, esa negligencia ha hecho y sigue haciendo mucho más daño que el "problema de la eñe" o las propuestas de Gabriel García Márquez sobre algunas modificaciones a las reglas ortográficas del español. Sin embargo, en cuantas ocasiones se presentan, las respuestas en "defensa" de nuestros sagrados intereses han sido fulminantes. Los cañones puestos en esa defensa son, en general, de tal envergadura y la munición de tal calibre que dejan a cualquiera anonadado. No a los científicos, al menos en lo que se refiere a nuestro contexto lingüístico. En particular los informáticos sentimos la conveniencia de ciertos cambios. Comencemos por alguna de las propuestas del autor de Cien años de soledad. Se dice, con sólidos argumentos y erudición lingüística, que es conveniente mantener la uniformidad del código ortográfico, como defienden Mª Rosa Alonso y el propio Domingo Ynduráin, entre otros muchos ilustres lingüistas. Bien, no sólo es conveniente. Es necesario. Pero quizás no sea tan conveniente el inmovilismo en este terreno, como en cualquier otro. La uniformidad debe ser compatible con los cambios que puedan mejorar las normas. Hagamos algunas reflexiones, aunque sean muy simples, mucho menos ambiciosas de las que ya hizo en su tiempo Andrés Bello, pero con el mismo propósito. Por cierto,la gramática de Andrés Bello se estuvo enseñando en los colegios públicos de Madrid, con el visto bueno de la Real Academia Española, hasta que fue prohibida por decreto del ministro de Instrucción Pública en tiempos del reinado de Isabel II.Ya ven ,la cultura y la política han estado reñidas desde tiempos inmemoriales. Sigamos con la cultura. Si admitimos la equivalencia entre distintas letras que representan el mismo contenido fonético, entonces aumenta la polisemia, es decir la ambigüedad del lenguaje escrito. Por ejemplo, no se podría distinguir entre 'vaca' y 'baca'. Sin embargo sí es posible distinguir entre banco (de sentarse) y banco (de dinero). Por lo que respecta a la tecnología, ésta aumenta la polisemia del lenguaje, puesto que crea acepciones nuevas para términos ya existentes. P. e. 'instrucción' (repertorio de instruc- NOVATICA jul./ago. 1999 nº140 ciones de una computadora). Es esto lo que se quiere decir cuando se dice que el español digerirá todo lo que le eche la tecnología (Antonio Gala). La cuestión es que se vaya absorbiendo correcta y coherentemente. Hay dos caminos para incorporar términos nuevos desde la tecnología. Los términos técnicos o bien se crean en la comunidad científica especializada o bien se trasvasan al contexto técnico si existían previamente en el lenguaje. Esto se hace mal a veces por la enorme velocidad de producción de ideas y productos, sobre todo en Informática y Comunicaciones. Pero si se hace bien, el contexto desambigua la polisemia. Cuando se habla de Informática, 'instrucción' tiene un significado, pero tiene otro muy distinto si se habla de Educación. Lo mismo se puede decir de la simplificación de la ortografía en muchos casos. Entre una vaca y una baca se puede distinguir por el contexto. Si la 'b' y la 'v' se confunden (funden) en una sola letra, el código ortográfico continuaría siendo uniforme y todos seguiríamos entendiéndonos. No habría confusión. La comunicación en lenguaje natural es tremendamente ambigua. El dominio de la lengua que tienen los buenos escritores es lo que les permite la precisión absoluta en la transmisión de los conceptos o los sentimientos más sutiles. Pero ¡qué difícil es atinar, cuando hay muchos caminos fáciles, con el auténtico! La eficacia. ¡Ah, la eficacia del lenguaje! La eficacia del lenguaje de tal o cual escritor. Está bien. Es muy meritorio. Pero la lengua ha de permitirlo. ¿En qué consiste esa eficacia? En poder comunicar las ideas con el mínimo de reglas y con la mínima cantidad de texto. En este sentido unas lenguas son más eficaces que otras. Es un fenómeno que estudió en profundidad el gran gramático danés Otto Jespersen (1860-1943). Con esta idea de eficacia Jespersen demostró la superioridad de las lenguas modernas frente a las muertas. Por lo que se refiere al latín, hay un rigor excesivo en la aplicación de reglas. Su ineficacia se traduce, entre otros efectos, en una innecesaria y pesada redundancia debida a la concordancia múltiple. Haciendo un inciso, estas observaciones ponen en cuestión la propuesta de aumentar la presencia del Latín en la enseñanza secundaria en detrimento de otras materias. ¿Cuáles? Y sobre todo, ¿cómo organizar el estudio integrado de las lenguas para conocer y dominar la materna? ¿Cuáles son las lenguas más eficaces? El inglés y el chino. ¡Qué casualidad! Las dos son habladas por un gran número de personas. Todo apunta a que continuarán siendo las dos grandes lenguas del mundo en el siglo XXI ¿Y el español? No lo estudió Jespersen. Pero es claro que no es tan eficaz como el inglés. Muchas veces echamos en falta la flexibilidad morfológica del inglés. Así en inglés se verbaliza ilimitadamente a partir de sustantivos. Por ejemplo to engineer del sustantivo engineer. También se crean con toda libertad nuevos nombres a partir de verbos. Ejemplo de esta otra facilidad es finder del verbo to find. El español, para verbalizar o sustantivar, es mucho más rígido. Así por ejemplo, el DRAE recoge la palabra 'buscador' pero no 'encontrador'. En el ámbito de Internet se usan términos como browser, de browse, o mailer, de mail. La cuestión es que en nuestra lengua se considera incorrecto el uso de las palabras que no registra el DRAE. Cuando llega 75 el caso se intenta construir una frase para resolver la situación. Creo que no se debería considerar incorrecto el uso de una palabra nueva, si es acertada. Es más, pienso que, en ese caso, se debería considerar como un hallazgo valioso. Es mejor una buena palabra que la mejor de las perífrasis. El inglés permite también construir palabras compuestas con bastante libertad. Así se dice "Peter’s team ‘reverseengineered’ the x system". La frase equivalente en español ha de ser necesariamente mucho más larga. Pero no es la longitud lo más importante, sino el esfuerzo de construcción. Se ponen en juego más reglas para expresar la misma idea. De aquí la menor eficacia. Aunque también hay que decir que no siempre es así, sino que, a veces,se produce el efecto inverso; es decir, menor número de palabras en español para expresar la misma idea. P.ej. cuando en inglés se dice take it yourself, basta decir en español un lacónico 'tómatelo'.La expresividad de la composición de palabras en español tiene una gran potencialidad. Hay que saber usar las posibilidades de expresión del español, pero se deberían suprimir los corsés que lo limitan. Se deben flexibilizar las reglas de nuestra lengua en beneficio de la potencialidad expresiva y la simplicidad de la misma. Es conveniente que la lengua también se adapte a los nuevos tiempos, como herramienta de comunicación que es, demostrando que ha servido, sirve y seguirá sirviendo para expresar cualquier pensamiento cómodamente. Frente a esa cierta falta de flexibilidad, el español presenta una fortaleza como lengua hablada mucho mayor que la inmensa mayoría de los idiomas. La adecuación de la palabra al texto es la propiedad que hace preciso al español, mientras que el inglés es el extremo opuesto, arquetipo de ambigüedad. Es muy difícil que una máquina pase eficientemente de inglés oral a inglés escrito, mientras que los programas comercializados que ya lo hacen para el español son bastante eficaces. Pero ¡ay! en este caso también tenemos que preguntarnos por los autores. No debemos dejar que nos hagan fuera nuestra Informática. Pero si no la hacemos nosotros, no debemos hacer como el burro del hortelano. Claro que, aunque quisiéramos que otros no la hicieran, tampoco podríamos impedirlo. Es más, la compramos con los ojos cerrados. 5. Conclusión La conclusión es que, con sus ventajas y sus inconvenientes, el español es una lengua con una gran salud, con una evidente fortaleza y en expansión. A pesar de todo. Quiero decir, a pesar de todos nosotros, los que lo hablamos. A pesar de nuestra idiosincrasia, nuestra dispersión y nuestras desavenencias. Preguntémonos si podríamos hacer algo más de lo que hasta ahora hemos hecho. 76 ASUNTOS INTERIORES NOVATICA jul./ago. 1999 nº140 Coordinación Editorial Programación de Novática Nuevas Secciones Técnicas de Novática 1999 A partir de este número se han creado dos nuevas Secciones Técnicas en nuestra revista: Los temas monográficos programados por el CAMCOM (Consejo Asesor de Medios de Comunicación) para el resto del presente año serán, salvo causas de fuerza mayor, los siguientes: Euro/Efecto 2000, cuyo coordinador es Joaquín Ríos Boutín <[email protected]>, socio senior de ATI y coordinador de las páginas sobre este mismo tema existentes en nuestro sitio Web. Esta sección tendrá una duración limitada a la vigencia de ambos fenómenos. Tecnología de Objetos, cuya coordinadora es Esperanza Marcos <[email protected]>, profesora de la Universidad Rey Juan Carlos I y coordinadora del Grupo de Trabajo sobre este mismo tema existente en el Capítulo de Madrid. Noticias de http://www.ati.es/novatica El web de ATI ha superado el medio millón de accesos brutos, más exactamente 505.699, en el mes de Junio, frente a 354.608 en Enero. Los accesos netos, descontando imágenes y otros elementos, han sido más de 150.000. En su conjunto, las páginas de Novática (que incluyen el Glosario de Internet) siguen siendo las más visitadas, con cerca de 25.000 accesos netos. El porcentaje de accesos desde países iberoamericanos supera el 10%. Todos estos datos aparecen con gran detalle en la IntrATInet (http://www.ati.es/socios), reservada a los socios de ATI. Septiembre-Octubre (Número 141) "Seguridad Informática" Fecha de publicación: segunda quincena de octubre Coordinador: Roberto Moya (<[email protected]>) Nota: Para esta monografía no habrá petición de artículos. Noviembre-Diciembre (Número 142) "Publicación Electrónica" Fecha de publicación: segunda quincena de diciembre Coordinador: Carlos Delgado Kloos (<[email protected]>) Nota: Para esta monografía no habrá petición de artículos. NOVATICA jul./ago. 1999 nº140 ASUNTOS INTERIORES Normas de publicación para autores Novática agradece su contribución desinteresada a los miles de autores que han elegido y elegirán sus páginas para presentar sus aportaciones al avance profesional y tecnológico de la Informática. Periodicidad: Novática tiene periodicidad bimestral y aparece los meses de Febrero, Abril, Junio, Septiembre, Octubre y Diciembre, salvo retrasos debidos a causas de fuerza mayor. El cierre de la edición es habitualmente un mes antes de la fecha de distribución (dos meses para los artículos del bloque monográfico). Normas de revisión: Con los artículos no solicitados se seguirán las siguientes reglas: en el caso de los bloques monográficos, serán los Coordinadores de los mismos los que decidan sobre su publicación o no; los artículos no destinados a monografías serán revisados al menos por un revisor. Excepto en el caso de las monografías, los artículos deberán ser enviados a la oficina de Coordinación Editorial (Novática-ATI. Calle Padilla 66, 3º dcha., 28006 Madrid, [email protected] (ver Soporte más abajo). Una vez aprobados por el revisor(es), serán publicados tan pronto como sea posible, si bien la publicación no está garantizada pues razones de exceso de material pueden hacerla imposible. Los autores serán informados del resultado de la revisión y de la publicación o no de los artículos remitidos. Tamaño de los artículos: Los artículos deberán tener un máximo de 3.000 palabras, lo que equivale a entre 8 y 10 páginas DIN A4 a doble espacio (fuente Times, tamaño 12), incluyendo resumen, figuras, bibliografía y notas. Sólo en casos excepcionales se aceptarán artículos superiores a dicho tamaño. Salvo excepciones, los artículos no deberán incluir más de cinco ecuaciones ni más de doce referencias bibliográficas o notas, y deberán incorporar título, resumen (máximo 20 líneas), nombre y afiliación del autor/a (es/as), así como su dirección postal y electrónica, y números de teléfono y fax. Soportes: Los artículos deberán ser enviados a Novática en formato digital, bien a través de la red bien en soporte magnético (disquete) mediante correo postal. En caso de envío por correo electrónico, si el fichero tiene un tamaño superior a los 150.000 bytes, es preciso enviar el fichero comprimido con el programa PKZIP e indicando qué procesador de texto entre los citados a continuación se ha utilizado. Novática se edita actualmente en PageMaker 6.0 para Windows. En ambos casos (correo electrónico o disquete) el artículo debe llegar en uno de los procesadores de texto más habituales para PC (Word, Word Perfect, Write, etc.), en HTML, RTF o, en último caso, en ASCII si se teme una difícil lectura o no se dispone de un procesador de texto estándar. También en ambos casos (correo electrónico o disquete) es preciso enviar una edición completa del artículo en papel para el cotejo de texto y gráficos. Estos se admitirán solamente en blanco y negro y con una buena resolución; además cada uno de los gráficos deberá enviarse en hoja aparte, tamaño DIN A4. Lengua: Aunque Novática admite artículos escritos en todas las lenguas reconocidas por la Constitución española y los Estatutos de las diferentes Comunidades Autonómas, dado que el ámbito de difusión de la revista conlleva su publicación en castellano, como lengua oficial común, los autores deberán presentar sus artículos en castellano y, si así lo desean, en otra lengua oficial de su elección. Novática enviará a los socios y suscriptores que lo soliciten una copia de la versión original de aquellos artículos que hayan sido escritos en una lengua oficial que no sea el castellano. Copyright: Novática da por supuesto que un autor acepta las presentes normas al enviar su original y que, en caso de que esté destinado a ser publicado en otro medio ajeno a ATI (o ya haya sido publicado) debe de aportar la autorización del editor del mismo para su reproducción por Novática (incluida la autorización para realizar traducciones). Novática por tanto no asume ninguna responsabilidad sobre derechos de propiedad intelectual si un texto se ha publicado en otro medio de comunicación, sea inadvertidamente o no, por parte del autor. Todo autor que publique un artículo en Novática debe saber que autoriza su reproducción, citando la procedencia, salvo que el autor declare explícitamente que desea proteger sus derechos con © o copyright. Asimismo, se entiende que el autor acepta que, además de en Novática, su artículo podrá ser también publicado y distribuido electrónicamente, mediante los medios habituales de difusión de ATI (servidor WWW, listas de distribución Internet, etc.) en su totalidad o parcialmente. Estilo: Si bien Novática respeta totalmente el estilo y contenido de cada artículo, da por supuesta la autorización del autor para retocar su ortografía, léxico, sintaxis, titulación y paginación, a fin de facilitar su comprensión por el lector y de subsanar posibles errores. Cualquier cambio que afecte al contenido será consultado con el autor. 77 SOCIOS INSTITUCIONALES de ATI Según los Estatutos de ATI, pueden ser socios institucionales de nuestra asociación "las personas jurídicas, públicas y privadas, que lo soliciten a la Junta Directiva General y sean aceptados como tales por la misma". Mediante esta figura, todos los profesionales y directivos informáticos de los socios institucionales pueden gozar de los beneficios de participar en las actividades de ATI, en especial cursos, conferencias, charlas, etc. Asimismo los socios institucionales pueden acceder en condiciones especiales a servicios ofrecidos por la asociación tales como Bolsa de Trabajo, cursos a medida, mailings, publicidad en Novática, servicio ATInet, etc. Para más información dirigirse a [email protected] o a cualquiera de las sedes de ATI. En la actualidad son socios institucionales de ATI las siguientes empresas y entidades: ·AIGÜES DEL TER LLOBREGAT ·ALMIRALL PRODESFORMA, S.A. ·ARCISA, S.A. ·ATOS ODS, S.A. ·BARCELONESA DE DROGAS DE PRODUCTOS QUIMICOS ·BBR INGENIERIA DE SERVICIOS, S.L. ·C.P. SISTEMAS DE PAGO, S.A. ·C.P. SOFTWARE, S.A. ·CESISA ·CINDOC (Centro de Información y Documentación Científica) ·CLINICA PLATO FUNDACIO PRIVADA ·COOPERS&LYBRAND AUDITORÍA Y CONSULTORIA ·ECONOCOM, S.A. ·ESTEVE QUIMICA, S.A. ·FUNDACION SAN VALERO ·GESTEVISION TELECINCO ·GS y C, Gabinete Sistemas y Consultoría, S.L. ·INFORMATION BUILDERS IBÉRICA, S.A. ·INSTITUT D’ESTUDIS CATALANS ·INVERAMA, S.A. ·JUNTA DE CASTILLA-LA MANCHA (Consejería de Administraciones Públicas) ·LABORATORIOS SERONO, S.A. ·M. SOFT, S.A. ·NORSISTEMAS, S.A. ·PRIMMA SOFTWARE, S.L. ·RAPIDA SISTEMAS INTEGRALES, S.A. ·SARA LEE DE ESPAÑA, S.A. ·SAS INSTITUTE, S.A. ·SEMA GROUP, SAE ·S.G. SOFTWARE DE GESTION, S.L. ·SIGMA SYSTEMS, S.A. ·SISTEMAS, SERVICIOS Y SOLUCIONES, S.A. ·TCP SISTEMAS DE INGENIERÍA, S.L. ·TELINDUS, S.A. ·UNIDE, S. COOP. ·UNIVERSIDAD DE EXTREMADURA (Dpto. de Informática) ·ZUGARTO EDICIONES, S.A.