Monografía: Bases de Datos Avanzadas

Comentarios

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 AV 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.

Documentos relacionados