Bases de datos

Mapas Conceptuales como primera fase del Diseño de Bases de Datos

Héctor Gómez Gauchía Facultad de Informática

Universidad Complutense de Madrid 28040 Madrid

hector@sip.ucm.es

Resumen En nuestra asignatura de Bases de Datos los alumnos no entienden el proceso de diseño de bases de datos fácilmente. Hemos descubierto que es un problema previo a donde empieza el diseño de base de datos habitual, el problema está en la fase de formación de conceptos. Nuestra propuesta consiste en incluir, en el proceso, el uso de mapas conceptuales. Y, así, representar conocimiento declarativo a un nivel muy bajo, usando conceptos relacionados con frases de enlace. Hemos definido un proceso de construcción de mapas específico, una estrategia de enseñanza y algunas técnicas adhoc para evaluación del impacto en los alumnos.

1. Motivación

Los enfoques en la enseñanza de las bases de datos están basados, en general, en la creencia de que los alumnos y los diseñadores tienen una idea clara del dominio, sus conceptos y la funcionalidad que necesitan. En nuestra experiencia esta creencia es falsa en muchas ocasiones. El desarrollo profesional de bases de datos se realiza usando las especificaciones del análisis de requisitos. Sin embargo, frecuentemente, las especificaciones no son muy claras y, a veces, simplemente no existen. Entonces, las fuentes alternativas de información son los expertos del dominio, que suelen ser imprecisos al describir el dominio y, como es lógico, no hablan en términos de modelos de bases de datos, tales como entidades o atributos. En estas situaciones, hemos encontrado muy útil el uso de herramientas que ayuden en el proceso de conceptualización. Nos referimos al proceso de describir explícitamente los elementos que forman

el dominio, i.e.: conceptos y relaciones entre ellos.

Por otra parte, hemos encontrado que, para nuestros alumnos como diseñadores, es difícil entender el proceso de conceptualización necesario para obtener un modelo de datos de la base de datos, p. e.: el diagrama del modelo de Entidad / Relación Extendido (EER) o el modelo de objetos de UML. Los alumnos tienen dudas principalmente con estos temas:

• Qué es un concepto y qué es una relación

entre conceptos. • Entender el significado de cada relación

dentro de un dominio desconocido para ellos. • Diferenciar conceptos, atributos y valores. • Cómo hacer corresponder los términos del

dominio con los elementos de los diagramas EER: entidades, relaciones, claves, cardinalidad, participación o cobertura.

• Encontrar qué relaciones son necesarias para la funcionalidad requerida.

• Cómo navegar a través de los conceptos y las relaciones en el diagrama EER

• Los diagramas EER que obtienen son: ambiguos, incompletos e incluso incorrectos, no reflejando la funcionalidad requerida.

Podemos resumir el problema desde los puntos de vista de los dos participantes: para un experto del dominio, explicar el dominio es una tarea complicada en sí y para los diseñadores de bases de datos, entender un dominio nuevo también es complicado.

Esta situación tiene varias razones concretas. Nos hemos centrado en dos importantes: la primera es que el lenguaje natural es ambiguo y hay una tendencia a usar verbos y conceptos genéricos en la descripción oral del dominio. La consecuencia directa de esta tendencia es que es

290 Bases de datos difícil pensar y razonar con precisión sobre el dominio usando esos elementos genéricos. La segunda es que los alumnos, durante la conceptualización, están desbordados con los detalles del dominio y tienden a olvidar el propósito de la base de datos. Entendemos por propósito la funcionalidad y los datos que se necesitan para el proyecto a realizar en ese dominio. Es importante el propósito porque es muy diferente el modelo de datos resultante para propósitos diferentes. La solución propuesta es modificar el proceso de diseño de la base de datos añadiendo fases nuevas para incluir una herramienta que ayude a pensar sobre el dominio, i.e. el proceso de formación de conceptos. En la siguiente sección presentamos una lista de las teorías que hemos analizado y pueden servir para este propósito. Entre ellas, hemos escogido los mapas conceptuales (cmaps) como la más adecuada. A continuación se expone una breve descripción de los elementos básicos de los cmaps. En la siguiente sección se describe el proceso de construcción de cmaps que hemos creado como paso previo a hacer los diagramas EER. A continuación se presenta un caso de estudio, la estrategia de enseñanza que hemos aplicado a nuestros alumnos, la evaluación informal y los resultados.

2. Mejorar la etapa de formación de conceptos

Para la ayuda a pensar sobre un dominio se han desarrollado varias herramientas. Algunas son para la elaboración de ideas abstractas y la agrupación de éstas, como los Diagramas de Afinidad o método KJ [10] muy usado en Japón como herramienta para estructurar las tormentas de ideas. Para nuestro objetivo necesitamos representar conceptos a varios niveles de abstracción, incluyendo los de muy bajo nivel, algo que no se puede con esta herramienta.

Otras herramientas, tales como los mapas cognitivos se centran en el proceso mental en sí y de cómo el dominio es afectado en su evolución a lo largo del tiempo. Se basan en la teoría de la construcción personal [7], que ha evolucionado hacia los mapas difusos [8]. En nuestro problema no representamos la evolución en el tiempo.

Otras herramientas aunque son conceptuales, están orientadas a resolver problemas, como los

diagramas en uve [6]. En ellos, hay una descripción conceptual de un problema sobre un dominio y unos pasos metodológicos para resolver el problema. Aquí la descripción no es detallada ni exhaustiva, solo es general y orientada a explicar el problema. Nosotros necesitamos una descripción del dominio en un nivel de detalle grande.

Otras herramientas se centran más en la representación visual y las razones cognitivas del uso de dibujos e imágenes. Entre ellas están los mapas mentales[2], muy usadas para organización del conocimiento de un modo jerárquico. Partiendo de una idea central, salen ramas en forma de estrella con ideas en las que se divide la idea central. Cada rama tiene subramas con ideas que se relacionan con la idea de esa rama. Es todavía un nivel muy abstracto para usarlo en el diseño de bases de datos, y no se definen claramente las relaciones entre las ideas que participan en mapa.

Otras herramientas se centran en los conceptos y en las relaciones entre ellos. Por ejemplo los mapas conceptuales [9], que se usan mucho en la conceptualización para la enseñanza de muy diferentes disciplinas, como se puede observar en el último congreso sobre ellos [3]. Los mapas conceptuales son los más adecuados para nuestros objetivos, porque en la herramienta necesitamos:

Flexibilidad, para poder hacer conceptualización a varios niveles de abstracción, desde el concepto más elemental a frases complejas que describan un tema muy abstracto. Los cmaps permiten esto porque sus diferentes componentes son pocos y con muy pocas restricciones comparados con otras herramientas, p. e. los diagramas de afinidad, que tienen unos pasos muy concretos a seguir con unos elementos complejos como son las tarjetas.

Simplicidad, para poder enseñarla y usarla rápidamente. Los cmaps tienen unas directrices fácilmente asimilables [1] y de uso inmediato, como hemos comprobado en otro de nuestros trabajos en un dominio distinto [5].

2.1. Elementos básicos de los Cmaps

Los cmaps representan conocimiento declarativo. Contienen proposiciones significativas llamadas tripletas, que se representan gráficamente con un concepto origen, una frase de enlace y un concepto destino. En la Figura 1 hay un ejemplo.

XI Jornadas de Enseñanza Universitaria de la Informática 291

Los conceptos se escriben dentro de un rectángulo y pueden ser nombres comunes o frases descriptivas de un objeto. Las frases de enlace se escriben sobre una línea terminada en flecha hacia

el concepto destino y son verbos o frases que describen una acción hecha por el concepto origen que afecta al concepto destino. Los cmaps pueden ser jerarquías de conceptos o redes. Como implementación de los cmaps destaca un programa muy completo llamado CmapTools [3], desarrollado por el IHMC (Institute for Human & Machine Cognition). Incluye la gestión de servidores de mapas en internet de libre acceso. Los cmaps de este artículo están hechos con ese programa.

3. Extendiendo el proceso de diseño de bases de datos

Hemos encontrado mejoras en el aprendizaje al apoyar el proceso de diseño con un cmap, cuando las especificaciones no están claras. Creamos el cmap interactuando con los expertos del dominio para explicitar los conceptos y sus relaciones de una forma visual. Definimos cuatro fases, que se muestran, junto a los resultados que generan, en la Figura 2:

• Fase 1: Construir el cmap. • Fase 2: Restringir los elementos de cmap para

aproximarlos a los elementos del diagrama EER.

• Fase 3: Crear el diagrama EER usando el cmap anterior.

• Fase 4: Transformar el diagrama EER en el esquema del Modelo Relacional.

No describimos en este artículo la Fase 4 porque no hay ninguna innovación, puesto que usamos el proceso habitual, ver [4] para detalles.

3.1. Fase 1: Construir el CMAP

No hay una metodología clara definida para construir cmaps, solo hay algunas directrices. Hemos diseñado un proceso para construir los cmaps de una forma sistemática basado en las directrices aplicables de las herramientas mencionadas. Lo hemos pulido basándonos en los comentarios que han hecho nuestros alumnos después de usarlo. Es un ciclo de refinamiento con los siguientes pasos: 1. Construir una lista de conceptos conocidos en el

dominio a modelar. Un concepto se refiere a cualquier elemento que sea nombrable. No se crean frases de enlace en este paso. El dominio se ve sólo desde el punto de vista del propósito de la base de datos.

2. Marcar, como puntos de comienzo para el siguiente paso, los conceptos más generales de la lista.

292 Bases de datos 3. Hacer grupos de los conceptos seleccionados en

el paso 2. Para ello se usa, como criterio, algún aspecto común a varios conceptos, que sea relevante para el propósito de la Base de Datos. Esos conceptos formarán un grupo. Se crea un concepto nuevo, que describa dicho criterio, y se conecta a cada uno de los conceptos del grupo mediante líneas con flecha que apunten a dichos conceptos. Por ejemplo, un experto está describiendo un tratamiento, separado del cliente, de los conceptos sueldo y título sin mencionar ningún concepto que los agrupe. En esta situación, hay que crear un nuevo concepto, puesto, que agrupe sueldo y título, como se muestra en la Figura 1 de la sección anterior.

4. Crear frases de enlace para conectar el resto de los conceptos seleccionados en el paso 2. Cada frase debe contestar a la pregunta: ¿qué criterio tienen en común esos conceptos a conectar?. La respuesta es la frase de enlace que estará en la línea que los conecta. Conforme se agrupan los conceptos, se van quitando de la lista inicial.

5. Aplicar el paso 4 a los conceptos que quedan en la lista inicial. Se hace uno a uno para colocarlo en el cmap, allí donde haya una frase de enlace con otro concepto que está ya en el cmap. Si el concepto no tiene relación con ninguno de los que está en el cmap se marca y se continúa con los demás. Si después de enlazar todos quedan algunos marcados sin conectar, es muy probable que no se necesiten en el modelo de datos, así que se pueden eliminar en el paso 6.

6. Verificar y validar el cmap obtenido con expertos en el dominio o fuentes documentales. En esta fase pueden aparecer elementos nuevos o bien eliminar elementos antiguos volviendo al punto 1 si es necesario.

En la Figura 1, está un ejemplo del cmap obtenido. Normalmente, en esta fase, el cmap tiene varios problemas que serán tratados en la fase siguiente.

3.2. Fase 2: Refinando el cmap

El objetivo de esta fase es acercar el cmap, obtenido en la fase anterior, a los elementos que participan en el diagrama EER mediante la transformación de los términos en lenguaje natural usados en el cmap. Esta transformación es muy dependiente del lenguaje natural aplicado y el modo de usarlo específico de cada diseñador de

bases de datos. Por ejemplo, en inglés, el sujeto de una frase es obligatorio, esto simplifica la composición de las frases. Mientras que en español no lo es, necesitando una atención especial para determinar cuál es el sujeto en cada frase a crear. Otro ejemplo de transformación es el uso de verbos genéricos, como haber, tener, ser, en vez de verbos específicos. Para hacer la transformación hemos definido una serie de directrices. Nos basamos en el análisis del lenguaje que usan nuestros alumnos cuando hablan sobre el dominio que han escogido ellos para hacer una base de datos. A continuación mostramos las directrices y después un ejemplo de su aplicación:

1. Quitar ambigüedades: En todo el cmap los

mismos conceptos deben tener el mismo significado y diferentes conceptos, diferentes significados.

2. Dar precisión a las frases de enlace y a los verbos: Se quitan verbos genéricos del tipo de tener, ser, haber, etc. Se transforman en verbos precisos de acción, o, si se puede, en lo que hemos llamado verbos especiales, que corresponden a elementos del diagrama EER. En la lista siguiente, para cada verbo especial se describe cuál debe ser el segundo concepto de la frase que se forma con ese verbo: o Tiene-parte: para un componente físico. o Tiene-subclase para subtipo o subclase. o Tiene-valor para un posible valor. o Tiene-propiedad para una característica.

3. Transformar preposiciones en verbos de acción. Esto se hace cuando aparece una preposición sola como frase de enlace, en vez de un verbo.

4. Transformar dos frases de enlace en una, cuando las dos frases forman parte de una sola acción. Por ejemplo, en la situación del paso 3, la preposición puede ser, en realidad, parte de la frase de enlace que la precede. En tal caso también se unen los conceptos que participan para formar uno más amplio.

5. Validar el mapa refinado, que obtenemos después de estos pasos, con los expertos en el dominio.

Estas directrices las hemos aplicado al cmap de la Figura 1. El resultado es el mapa refinado de la Figura 3. Aunque es un ejemplo simple se incluyen las transformaciones más relevantes. En

XI Jornadas de Enseñanza Universitaria de la Informática 293

la Figura 1, el verbo genérico ‘tiene’ se refiere a tres acciones diferentes: tiene-propiedad en la frase que se forma ‘cliente tiene nombre’, invierte en ‘cliente tiene inversiones’ y trabaja-en-un en ‘cliente tiene un puesto’. En la misma figura, la preposición que está sola y que forma la frase ‘cliente tiene inversiones con compañía’ se refiere a la frase de enlace ‘tiene’ que esta antes de ‘inversiones’. Podemos transformarla, siguiendo la última directriz, en ‘cliente invierte-en compañía’.

3.3

Eninfdomsobtreapl

1.

2.

3.

que no existen en los mapas conceptuales, tales como las claves primarias y las distinciones entre entidades fuertes y débiles.

Elementos EER Usa el cmap refinado Relación………………… depende del verbo especial:Atributo ………………... Relación es-un ………… Valor (no hay en EER).. Atributo o Entidad ………. (según casos particulares)

Frase de enlace Conceptos precedidos de: ..Tiene-parte ..Tiene-subclase ..Tiene-valor ..Tiene-propiedad

. Fase 3: Obtener el diagrama EER

esta fase se usan, como fuentes de ormación, el mapa refinado, los expertos del

inio y las descripciones escritas que existan re el dominio. A continuación se describen las

s tareas de esta fase y después un ejemplo de su icación: Clasificar elementos del cmap refinado. Para ello se usa la correspondencia entre los elementos del cmap y del diagrama EER de la Tabla 1. La correspondencia se hace poniendo etiquetas a los diversos elementos del cmap, con nombres de los elementos del diagrama EER, incluyendo la cardinalidad y la participación o cobertura. Construir el diagrama EER preliminar haciendo las correspondencias indicadas por las etiquetas creadas en la tarea anterior. Verificar el diagrama EER preliminar comprobando si faltan elementos, si hay elementos incorrectos o si hay elementos inútiles que se pueden eliminar. En esta tarea también se completan los elementos del EER

R

Tabla 1: Correspondencia elementos Cmap y de EE

En la Figura 4 está el diagrama EER que se

obtiene usando el cmap de la Figura 3 después de la presente fase. Esta fase puede llegar a ser complicada, porque la transformación de algunos elementos depende de los otros elementos que les rodean. En estos casos solo queda aplicar la teoría del modelo EER directamente. En la Figura 5 hay un ejemplo de estos casos donde tenemos dos conceptos apuntados por una frase de enlace has-part. Aunque parece la misma situación, cada uno es transformado de forma diferente: se crea un atributo tipo-motor del coche porque no tenemos mas información sobre ‘motor’. Sin embargo creamos una entidad ruedas porque sabemos, sobre ellas, la marca y el tamaño. Y creamos una sola relación tiene-parte para conectar ruedas y coche.

En la Tarea 1 se dan también casos particulares. Por ejemplo, si del concepto apuntado por un verbo tiene-parte cuelga, a su vez, otro verbo tiene-parte, entonces se crea una entidad con dicho concepto, en vez de un atributo como sería de esperar según las directrices indicadas.

4. Caso de estudio

Para hacer la evaluación de esta propuesta, primero hemos desarrollado una estrategia para enseñarla a nuestros alumnos de 3º de Ingeniería Informática. Posteriormente hemos aplicado cuatro técnicas informales para evaluar el impacto en los alumnos en comparación con el método habitual que veníamos usando hasta ahora.

294 Bases de datos

Después de cada paso, se les pide a los alumnos que escriban una lista de problemas del alumno con aquellas dificultades que han encontrado en ese paso. Al escribir la lista asimilan cuáles han sido sus dificultades principales. Sin estas listas tienden a olvidar

DNI Nombre

4.1. Estrategia de enseñanza

La estrategia está basada en el paradigma de aprender haciendo y es guiada por ejercicios que tienen que hacer los alumnos. Empleamos seis horas para enseñarles los fundamentos de cmaps. Los alumnos trabajan en grupos de dos. En primer lugar, tienen que crear pequeños cmaps, asistidos por el profesor. Para enseñarles el enfoque propuesto de diseño de bases de datos empleamos tres horas en cada fase. Los alumnos aplican cada fase a los cmaps que han creado previamente, también asistidos por el profesor. En la siguiente etapa se les pide que hagan todo el proceso de diseño sobre su dominio favorito, creando una base de datos de tamaño medio. En esta etapa está incluida su implementación, empleando doce horas para ello. En este tiempo no se incluye las dieciocho horas que usamos para enseñar la teoría sobre el modelo EER, el modelo relacional, la fase 4 y el lenguaje SQL.

muchas de las soluciones que han encontrado. Con las listas evitan, en sucesivas ocasiones, volver a explorar alternativas que han descrito ya en su lista de problemas, ahorrando tiempo en la clásica estrategia de prueba y error que usan los alumnos en general. Estas listas también sirven para la evaluación del proceso, así como para que el profesor resuelva los temas más relevantes que no han sido solucionados.

COMPRA

EMPRESA

CLIENTE

PUESTO

TRABAJAINVIERTE

Direcc.

Telefo.

Salario

Figura 4: Diagrama EER

Título

OBJETO

Figura 5: Transformación de tiene-parte

4.2. Evaluación y resultados

Para comparar resultados tomamos, como grupo de referencia, los alumnos del año anterior que no habían visto cmaps. Así como las encuestas sobre sus dificultades en el aprendizaje del diseño de bases de datos. Establecimos un proceso de evaluación basado en cuatro técnicas diseñadas adhoc para nuestro caso de estudio. Cada técnica mide uno de nuestros objetivos de evaluación, en comparación con las del grupo de referencia: 1. Para medir la comprensión global del

proceso de diseño: comparamos las dificultades actuales de las listas de problemas del alumno.

2. Para medir la comprensión de los conceptos y del propósito de la base de datos: comparamos las preguntas sobre el dominio que hacen los alumnos a los profesores durante el proceso de desarrollo.

3. Para medir la desviación final del modelo pedido: comparamos la importancia de los cambios hechos del diseño que creían definitivo en relación con lo que se implementó finalmente. Estos cambios son motivados por los comentarios hechos por expertos en el dominio al ver los modelos preliminares implementados.

4. Para medir la satisfacción de nuestros alumnos, con todo el proceso: comparamos la encuesta sobre la facilidad de comprensión, de desarrollo y de corrección de errores. La valoración de los alumnos no puede considerarse como un criterio definitivo, ya que los estudiantes no son capaces de

XI Jornadas de Enseñanza Universitaria de la Informática 295

evaluar, con perspectiva, sus propias mejoras en un dominio que están aprendiendo y solo conocen una parte de él.

El resultado cualitativo de este proceso indica una mejora apreciable en la comprensión de la teoría de base de datos y en los elementos del dominio sobre el que se crea la base de datos. Los alumnos muestran facilidad en el aprendizaje de la nueva herramienta, cmaps. Además de las encuestas y listas de problemas, como evaluación cualitativa, también hemos comparado las notas obtenidas para una evaluación cuantitativa. Ha habido una mejora general, que destaca en el porcentaje de las notas más bajas que han mejorado alrededor de un 20%, mientras que las medias y altas se mantienen similares.

5. Conclusiones

Después de enseñar varios años diseño de bases de datos, descubrimos un problema serio: los alumnos no entienden fácilmente el proceso de conceptualización necesario para obtener el diseño de una base de datos. Y este problema sucede antes de donde empieza la enseñanza actual del diseño. Es decir, en el modo de pensar sobre el dominio y comprender sus elementos.

Nuestra propuesta es modificar el proceso de diseño de base de datos para incluir fases previas al proceso habitual que ayuden en el proceso de formación de conceptos, usando la herramienta de mapas conceptuales o cmaps. Estos representan conocimiento declarativo a diferentes niveles de abstracción, usando conceptos y frases de enlace entre ellos para componer proposiciones sobre el dominio.

En la propuesta definimos una técnica de construcción de cmaps específica como fase previa para el diseño de bases de datos. Definimos el proceso de diseño de la base de datos que incluye los cmaps, con tareas de aproximación sucesiva al diagrama EER. Definimos una estrategia de enseñanza de este proceso, que está basada en el paradigma de aprendizaje haciendo. Aplicamos la propuesta a un caso de estudio: nuestros alumnos de ingeniería de informática. Y desarrollamos algunas técnicas adhoc para la evaluación del impacto en los alumnos.

6. Trabajo futuro

Como trabajo futuro, en el curso próximo haremos una evaluación más formal con encuesta detalladas para extraer estadísticas. Una vez validada la aproximación propuesta se planea hacer una herramienta que asista al alumno en el proceso de diseño. También planeamos introducir la propuesta del proceso de diseño en una empresa de desarrollo de software para evaluar los resultados en desarrollo profesional.

7. Agradecimientos

Financiado por la Comisión Interministerial de Ciencia y Tecnología (TIC2002-01961)

Referencias

[1] Ahlberg, M. Varieties of concept mapping in Concept Maps: Theory, Methodology, Technology, Proc. of the First Int. Conference on Concept Mapping A. J. Cañas, J. D. Novak, F. M. González (Eds.) Pamplona, Spain. 2004.

[2] Buzan, T., Buzan, B. The mind map book (Millenium ed.). London: BBC Books. 2000.

[3] Cañas, A. J., Hill, G., Carff, R., Suri, N., Lott, J., Gómez, G., Eskridge, T. C., Arroyo, M., Carvajal, R. CmapTools: a knowledge modeling and sharing environment In Concept Maps: Theory, Methodology, Technology Proc. of the First Int. Conference on Concept Mapping A. J. Cañas, J. D. Novak, F. M. González (Eds.) Pamplona, Spain. 2004.

[4] Elmasri, R., Navathe, S.R. Fundamentals of Database Systems. 3ª Ed. 1997. Addison-Wesley. 2000.

[5] Gómez-Gauchía, H., Díaz-Agudo, B., González-Calero, P.A., A Pragmatic Methodology for Conceptualization with two layered Knowledge Representation: a case study. In Conceptual Structures at Work, Contributions to 12th International Conference on Conceptual Structures. ICCS2004. Pfeiffer, H.D., Wolff, K.E., Delugach, H.S. (Eds.) Shaker Verlag. 2004.

[6] Gowin, B. Educating, Ithaca, NY: Cornell University Press. 1981/1987.

296 Bases de datos [7] Kelly, G., S. The Psychology of Personal

Constructs. Ed. Norton, New York, 1955. [8] Kosko, B. Fuzzy cognitive maps International

Journal of Man-Machine studies 1986,24, 65-75

[9] Novak, J. D., Gowin, D. B.. Learning how to learn. New York: Cambridge University Press. 1984.

[10] Ohiwa, H. KJ Editor for Creative Work Support and Collaboration in Proceedings of the First Conference on Creating, Connecting and Collaborating through Computing (C5’03) 2003.

Comparativa de herramientas para la enseñanza de lenguajes relacionales

Javier J. Gutiérrez, María J. Escalona, Darío Villadiego, Manuel Mejías Dpto. de Lenguajes y sistemas Informáticos

Universidad de Sevilla Avd. Reina Mercedes s/n

41012 Sevilla e-mail: {javierj, escalona, risoto}@lsi.us.es

Resumen El estudio del modelo relacional aplicado a las bases de datos es una parte fundamental en los estudios de toda Ingeniería Informática, tanto técnica como superior. Los lenguajes de consulta relacionales forman una parte importante de este estudio. Nuestra experiencia nos ha mostrado que, para los alumnos, es difícil conocer cuándo las consultas expresadas en un papel en términos de estos lenguajes son correctas y responden satisfactoriamente a los enunciados planteados.

En este trabajo se describe una herramienta de apoyo que permite realizar consultas expresadas en lenguajes relacionales sobre cualquier base de datos. Esta herramienta se ha desarrollado siguiendo el modelo del software libre Además este trabajo expone los resultados de un estudio comparativo entre esta herramienta y otras herramientas que se puede descargar libremente de Internet.

1. Motivación

Actualmente el modelo relacional para organizar y gestionar sistemas de bases de datos sigue estando de plena vigencia. Por ello, cobran una importancia vital a la hora de la enseñanza de sistemas de bases de datos los fundamentos de este modelo. Estos fundamentos incluyen sus lenguajes relacionales, ya que son la base teórica sobre la que se han desarrollado todas las herramientas de bases de datos que los alumnos van a manipular en sus profesiones [13]. La importancia del aprendizaje del modelo relacional ha sido expuesta en varios trabajos como [7], [9] y [13].

Es muy importante, en este proceso de aprendizaje de los lenguajes relaciones, disponer de herramientas que permitan ejecutar expresiones

y mostrar sus resultados. Con herramientas de este tipo es posible motivar a los alumnos a que investiguen por ellos mismos las posibilidades de los lenguajes relacionales, facilitar el entendimiento de los operadores relacionales, desarrollar nuevas expresiones y comparar las ventajas de utilizar diversas expresiones relacionales. En resumen, mejorar las técnicas de autoaprendizaje de la materia [9].

Este trabajo se divide en dos partes. En la primera se presenta una herramienta libre de código abierto llamada RelationalQuery o RQuery [12]. El objetivo principal de esta herramienta es ofrecer a los alumnos la posibilidad de poder ejecutar consultas en los lenguajes relacionales clásicos. En la segunda aparte se realiza un análisis comparativo entre herramientas para ejecutar consultas en lenguajes relacionales.

La sección 2 ofrece una breve introducción al modelo relacional y la los lenguajes relacionales. La sección 3 detalla las características de la herramienta RQuery. La sección 4 muestra el análisis comparativo. Por último, la sección 5 exponen las conclusiones y los futuros trabajos.

2. Introducción al modelo relacional y a los lenguajes relacionales

El modelo de datos relacional fue presentado por Tedd Codd en 1.970 [3]. Este modelo está basado en el concepto de relación matemática y el conjunto de manipulaciones que es posible llevar a cabo sobre estas relaciones. La base de las manipulaciones permitidas sobre el modelo la ofrecen los lenguajes relacionales. Originalmente Codd definió dos lenguajes relacionales: álgebra relacional y cálculo relacional como la base de los modelos relacionales.

Lenguaje Consulta Álgebra relacional project nombre (empleado) Cálculo relacional orientado a tuplas X : empleado / X.nombre Cálculo relacional orientado a predicados empleado(x: nombre) SQL SELECT nombre FROM empleado;

Tabla 1. Ejemplo de consulta en los distintos lenguajes relacionales y SQL.

El álgebra relacional es un lenguaje procedural o de alto nivel, mientras que el cálculo relacional es un lenguaje no procedural. Sin embargo, ambos lenguajes son equivalentes. Para cada expresión del álgebra, se puede encontrar una expresión equivalente en el cálculo, y viceversa.

El cálculo relacional tradicionalmente se ha dividido en dos lenguajes: el cálculo relacional orientado a tuplas y el cálculo relacional orientado a predicados, según el tipo de variables que se manejan. El cálculo relacional orientado a tuplas (CRT) emplea variables-tupla, las cuales pueden tomar el valor de cualquier tupla de la relación. En el cálculo relacional de dominios (CRD) se utilizan variables-dominio, que toman valores de los dominios asociados a los campos de las relaciones.

En la tabla 1, se muestra una consulta para obtener los nombres de los empleados, tanto en álgebra relacional, como en los cálculos relacionales y SQL.

Tanto el álgebra relacional como los cálculos relacionales son lenguajes formales, muy matemáticos y poco amigables. Sin embargo deben estudiarse porque sirven para ilustrar las operaciones básicas que todo lenguaje de manejo de datos debe ofrecer. Además, han sido la base para otros lenguajes relacionales de manejo de datos de más alto nivel [7], [13].

En la siguiente sección se describe brevemente nuestra herramienta creada para facilitar el aprendizaje y práctica con estos lenguajes.

3. Descripción de la herramienta RelationalQuery

3.1. ¿Por qué una nueva herramienta?

Para contestar correctamente a esta pregunta sería necesario estudiar las herramientas existentes en

la actualidad. Este estudio se ha pospuesto para la sección 4 con el fin de incluir en él a esta herramienta. Sí se puede adelantar que, como se verá con mayor detalle en la siguiente sección, no se ha encontrado ninguna herramienta que cumpla todas las siguientes características. Estas características se describirán con más detalle en la comparativa y conclusiones. • Herramienta libre con código fuente

disponible libremente por Internet. • Multiplataforma. • En español. Siguiendo las recomendaciones de [5], esta herramienta se plantea para el marco concreto de facilitar el aprendizaje en carreras universitarias.

3.2. Descripción de la arquitectura

RQuery se ha desarrollado siguiendo el modelo del software libre [11]. Una de las ideas principales de este modelo es reutilizar tantos componentes como sea posible. En la figura 1 se muestran los distintos componentes libres. Esta reutilización acorta el tiempo de desarrollo y aumenta la calidad del mismo al emplear código ya probado y depurado.

RelationalQuery

ApacheCommons CLI

Apache Log4J

JLex

Hipersonic SQLDatabase

ApacheCommons i18n

Figura 1. Componentes libres utilizados en

RelationalQuery.

XI Jornadas de Enseñanza Universitaria de la Informática 299

Usuario

SELECT nombre FROMempleado;

PROJECT nombre(empleado);

Servidor de datos

Consulta en lenguajerelacional

Traducción

Ejecución

Resultados

Figura 2. Proceso de traducción y ejecución de una consulta.

Las referencias a los componentes utilizados

se pueden encontrar en [2] y [8]. Para el desarrollo de esta herramienta se ha

optado por delegar todas las operaciones de consulta sobre un servidor de bases de datos relacionales. La aplicación realiza una traducción de expresiones en lenguaje relacional a consultas SQL. Estas son ejecutadas en el servidor de bases de datos. Como se puede ver en la figura 1, la base de datos seleccionada ha sido Hipersonic SQL [8] por estar escrita íntegramente en Java, soportar SQL-92 y disponer de una versión con licencia libre.

Las ventajas de esta aproximación respecto de codificar directamente las consultas sobre los datos, se enumeran a continuación. • Es posible utilizar cualquier base de datos que

disponga de un conector o driver JDBC • Es posible utilizar cualquier herramienta de

administración de bases de datos. • Es posible aprovechar toda la información

almacenada en bases de datos ya existentes. • Ayuda a los alumnos a prácticas tareas de

gestión de bases de datos en SQL. • Ofrece un conjunto de dominios muy ricos

(todos los tipos de datos soportados por SQL-92).

• Permite reutilizar componentes ya creados, como herramientas de bases de datos, o herramientas para análisis léxico y semántico.

El proceso de traducción y ejecución de una consulta se muestra en la figura 2. A la hora de implementar los distintos lenguajes relacionales se ha optado por una arquitectura modular donde cada uno de los lenguajes tiene su propio conjunto de módulos, y comparte otros módulos comunes con el resto de la aplicación. Los módulos propios de cada lenguaje son el analizador léxico, sintáctico y traductor a sentencias SQL, ya que cada lenguaje tienes unas reglas de traducción distintas. Las interfaces gráficas, factorías, y módulos de ejecución de consultas y acceso a bases de datos son compartidos por todos los lenguajes. En la figura 3 se muestran los componentes comunes a todos los lenguajes y los componentes dependientes de cada uno de los lenguajes relacionales soportados. En las dos siguientes secciones se describe con más detalle las características más importantes de RQuery.

Bases de datos 300

Interfaz Gráfica

Analizadorléxico

Analizadorsintáctico

Analizadorléxico

Analizadorsintáctico

Analizadorléxico

Analizadorsintáctico

Ejecución de consultas

Base de datos

Traductor a SQL Traductor a SQL Traductor a SQL

Figura 3. Estructura modular de la aplicación.

3.3. Traducción sistemática de expresiones de lenguajes relacionales a SQL

Como se ha visto en la sección anterior, el corazón de RQuery es el traductor de consultas de lenguajes relacionales a SQL. No ha sido el objetivo de este trabajo crear ningún método formal, simplemente crear algo práctico que se pudiera implementar y de utilidad para la comunidad educativa.

Cada lenguaje ha sido estudiado de manera independiente y se ha desarrollado un mecanismo sistemático y automatizable para obtener un equivalente en SQL de cualquier consulta

expresable en cualquiera de los tres lenguajes relacionales.

Actualmente está completamente implementada la traducción desde álgebra relacional a SQL con la excepción del operador división. Respecto a los lenguajes del cálculo relacional, ya se ha desarrollado los mecanismos de traducción, pero aún no han sido implementados.

3.4. Interfaces de usuario.

RelationalQuery ofrece varias interfaces de usuario en función de la preferencia de cada usuario o de la potencia de la máquina. La más básica es una interfaz de línea de comandos que permite ejecutar en modo de proceso por lotes un archivo de texto con consultas. Una captura de esta interfaz se muestra en la figura 4. RelationalQuery también incluye dos interfaces gráficas escritas en Java/SWING. La primera es una interfaz extremadamente sencilla y adecuada para equipos menos potentes. Esta interfaz divide la ventana en dos áreas, en el área superior se ejecutan las consultas mientras que el área inferior se muestran los resultados. Una captura de ejemplo se muestra en la figura 5. Tanto en esta, como en la interfaz anterior, es necesario indicar el lenguaje a utilizar desde la línea de comandos, por lo que no es posible cambiar de lenguaje sin salir de la aplicación y volver a ejecutarla.

Figura 4. Interfaz de línea de comandos de RQuery.

XI Jornadas de Enseñanza Universitaria de la Informática 301

Figura 5. Interfaz gráfica básica.

La tercera interfaz gráfica es una versión evolucionada de la anterior y ofrece más opciones, como la posibilidad de almacenar y recuperar consultas o la opción de cambiar de lenguaje sin necesidad de abandonar la aplicación. Una captura de ejemplo se muestra en la figura 6.

El componente de interfaces gráficas es uno de los aspectos más activos dentro del proyecto RelationalQuery. En futuras interfaces está previsto incorporar más opciones que faciliten la edición y depuración de consultas, así como una interfaz multiventana (MDI) para poder tener varias consultas activas al mismo tiempo.

4. Comparativa de herramientas de lenguajes relacionales

En este apartado se analizan y comparan brevemente tres herramientas que permiten la ejecución de consultas en álgebra relacional. Las tres herramientas seleccionadas son LEAP [10], RelationalQuery [12] y WinRDBI [14]. Se han elegido estas herramientas porque cumplen dos condiciones: la primera que es cualquiera pueda

descargarlas de Internet y la segunda que estén lo suficientemente desarrolladas para poder ser utilizadas. No se han podido incluir en esta comparativa herramientas españolas como [7] por no estar disponibles para descarga.

4.1. Breve presentación de las herramientas

RQuery [12] ya ha sido comentada con detalle en los apartados anteriores, por lo que esta sección va a describir brevemente las otras dos herramientas.

WinRDBI [14] consta de una interfaz de usuario escrita en Java, la cual ejecuta las consultas mediante una librería Prolog implementada con librerías dinámicas DLL, lo cual no permite se utilización en una plataforma distinta de Windows. Existe también una versión para Linux disponible para descarga. Esta herramienta soporta SQL, álgebra relacional y los lenguajes del cálculo relacional. En la figura 7 se muestra una captura de esta herramienta.

Figura 6. Interfaz gráfica avanzada.

Bases de datos 302

Figura 7. Herramienta WinRDBI en acción.

LEAP [10] se ha desarrollado en C, por lo que debe ser compilado en cualquier plataforma donde se quiera utilizar. Actualmente solo se distribuye una versión compilada para entornos Windows. Esta herramienta sólo soporta álgebra relacional. Una captura de esta herramienta se muestra en la figura 8. En la tabla 4 se recogen las versiones de las herramientas analizadas en esta comparativa. En el apartado 4.2 se detallan las características analizadas de cada herramienta así como los resultados de la comparativa. Herramienta Versión LEAP 1.2.5 WinRDBI 3.10 RelationalQuery 0.010

Tabla 2. Versiones de las herramientas empleadas en la comparativa.

4.2. Comparativa de herramientas

Se han establecido 14 características para ser analizadas en cada una de las herramientas. Estas características están centradas en describir la utilidad pedagógica de la herramienta y las facilidades de uso que ofrecen a los alumnos. Se ha establecido una clasificación donde, para cada categoría, se indica la herramienta que más la satisface con un primer puesto, la que queda en un nivel intermedio y la que más pobremente la satisface, o no la satisface en absoluto, con un tercer puesto. En la tabla 4 se muestran las 14 características analizadas para cada una de las herramientas en esta comparativa.

Figura 8. Interfaz gráfica de la herramienta

XI Jornadas de Enseñanza Universitaria de la Informática 303

LEAP.Característica 1º puesto 2º puesto 3º puesto Calidad de la documentación

RelationalQuery / LEAP WinRDBI X

Cantidad de ejemplos WinRDBI LEAP RelationalQuery Cantidad de interfaces de usuario disponibles

RelationalQuery LEAP WinRDBI

Código fuente disponible RelationalQuery / LEAP WinRDBI X Facilidad de descarga RelationalQuery / LEAP WinRDBI X Facilidad de administración WinRDBI RelationalQuery LEAP Idiomas de la interfaz de usuario

RelationalQuery LEAP WinRDBI

Lenguajes de consultas WinRDBI RelationalQuery LEAP Licencia más libre RelationalQuery LEAP WinRDBI Multiplataforma RelationalQuery LEAP WinRDBI Opciones de configuración LEAP RelationalQuery WinRDBI Operadores de álgebra relacional

LEAP RelationalQuery WinRDBI

Sencillez de uso WinRDBI RelationalQuery LEAP Servidor centralizado RelationalQuery LEAP WinRDBI

Tabla 3. Categorías analizadas.

Las herramientas RelationalQuery y LEAP han obtenido el primer puesto de calidad de la documentación ya que ambas cuentan con un manual extenso y actualizado. La documentación de WinRDBI, en cambio, es pobre y obsoleta. Sin embargo, aunque el número de ejemplos que se incluyen en LEAP es el mayor de todas las herramientas, WinRDBI se alza con el primer puesto ya que se distribuye con un completo ejemplo implementado en los cuatro lenguajes que soporta LEAP, al igual que RelationalQuery, ofrece también una interfaz gráfica y otra de línea de comandos. Sin embargo su interfaz gráfica es muy pobre y no ofrece distintas alternativas para equipos más o menos potentes. Tanto RelationalQuery como LEAP pueden descargarse libremente de sus respectivos sitios web incluido su código fuente. Para descargar WinRDBI, en cambio, es necesario registrarse en un formulario y esperar a recibir el enlace adecuado a través del correo electrónico. Tanto LEAP como WinRDBI solo están disponibles en inglés. Sin embargo al estar disponible el código fuente de LEAP sería posible traducirla al español. Al estar los mensajes de la aplicación incrustados en el código sería necesario recompilar la herramienta. RelationalQuery es la herramienta mejor preparada para soportar nuevos idiomas ya que todos los mensajes del sistema se

almacenan en archivos XML externos fácilmente modificables. En el número de lenguajes de consultas disponibles, actualmente WinRDBI es un claro ganador. RelationalQuery actualmente sólo soporta álgebra relacional y SQL, mientras que LEAP sólo soporta álgebra relacional. La licencia que otorga más libertad es la licencia de RelationalQuery [1], ya que tanto herramienta como sus componentes pueden reutilizarse en proyectos libres o propietarios. La licencia de LEAP [6] sólo permite reutilizarla en programas libres con la misma licencia o compatible, mientras que WinRDBI se distribuye bajo una licencia propietaria que no permite su redistribución, lo cual es un serio inconveniente en entornos educativos. Al estar desarrollada en Java, RelationalQuery puede ejecutarse en cualquier plataforma que disponga de una maquina virtual Java sin ninguna modificación. LEAP puede ejecutarse en cualquier plataforma que disponga de compilador de lenguaje C, pero es necesario compilar el código para cada plataforma específica. WinRDBI solo distribuye versiones para sistemas Windows y Linux. LEAP es la herramienta que más operadores del álgebra relacional implementa, ya que incluye todos los operadores definidos. RelationalQuery incluye todos los operadores del álgebra relacional

Bases de datos 304

menos la división, y WinRDBI no incluye división ni intersección. Una característica importante en una herramienta pedagógica es permitir que el conjunto de datos esté situado en un único ordenador, y diversas copias de la aplicación puedan acceder a estos datos. Con esto se consigue que todos los alumnos tengan un conjunto consistente de datos de prueba, facilitar la instalación y minimizar el mantenimiento. La herramienta que mejor implementa esta característica es RQuery, ya que la tecnología JDBC aísla tanto de la marca del servidor de bases de datos como de su ubicación. LEAP también proporciona esta característica aunque debe realizarse una configuración especial de la herramienta, mientras que WinRDBI no la soporta. La clasificación final de las herramientas, según el número de puestos de cada tipo obtenidos, se muestra en la tabla 5. Herramienta 1º puesto 2º puesto 3º puesto RelationalQuery 8 5 1 LEAP 5 6 3 WinRDBI 4 3 7

Tabla 4. Clasificación final de las herramientas.

En la siguiente sección se exponen las conclusiones que se pueden extraer de esta comparativa.

5. Conclusiones Como planteamos en la sección 3.1, esta comparativa justifica la creación de una nueva herramienta. Sin embargo, a pesar de los buenos resultados obtenidos en la comparativa, RelationalQuery no es aún la herramienta definitiva. Su éxito en la comparativa se debe a que ha podido partir de la base de los errores de las anteriores herramientas. Tampoco ninguna de las otras dos herramientas analizadas es la herramienta definitiva. A pesar de todas sus carencias, WinRDBI es actualmente la única herramienta que ofrece soporte para todos los lenguajes relacionales y la internaz de usuario más sencilla. RQuery espera ofrecer todos los lenguajes en un corto periodo de tiempo. LEAP ha sido diseñado y construido solo para álgebra relacional, por lo que es muy improbable que incorpore otros lenguajes en un futuro. Uno de factores principales en los buenos resultados de RQuery ha sido la filosofía de código abierto [11] que ha permitido reutilizar muchos componentes

ya existentes para ahorrar tiempo y esfuerzo en la construcción. Creemos muy interesante hacer un llamamiento a otras universidades, departamentos e instituciones que disponen, o están desarrollando, herramientas similares para que las liberen a las comunidad, aunque mantengan el código propietario. Además la liberación del código ha servido de base para otra herramienta libre para extraer volcados de tablas de bases de datos y que puede ser utilizada para generar archivos SQL, o archivos en formato WinRDBI [4]. Esta herramienta ha sido muy útil para la comparativa de la sección 4.

Referencias [1] Apache Software Foundation License.

www.apache.org/licenses/. [2] Apache Project. www.apache.org/. [3] Codd. E. F. 1970. A Relational Model of Data

for Large Shared Databanks. Communications of the ACM, June 1970.

[4] DumpTable. http://javahispano.net/dumptable/ [5] Gewerc, A. 2002. Diseño de entornos de

aprendizaje. www.quadernsdigitals.net/ [6] GNU General Public Licence.

www.gnu.org/copyleft/gpl.html [7] Hernández, C., et-al. 2002. Una Herramienta

para el Aprendizaje del Álgebra Relacional. VIII Jornadas de Enseñanza Universitaria de la Informática. Cáceres.

[8] Hipersonic SQLDB. http://hsqldb.sourceforge.net

[9] Jordá, P. A., et-al. 2001. Mejoras en el aprendizaje de la informática en otras escuelas universitarias. VII Jornadas de Enseñanza Universitaria de Informática.

[10] LEAP. http://leap.sourceforge.net/ [11] Raymenod, Eric S. The Cathedral and the

Bazaar. http://es.tldp.org/ catedral-bazar/. [12] RelationalQuery. relationalquery.dev.java.net [13] Sosa, A.R., et-al. 2002. Enseñanza de la parte

estática del modelo relacional de bases de datos basada en las Nuevas Tecnologías de la Información y las Comunicaciones. www.ucf.edu.cu/publicaciones/anuario2002/NTIC/articulo22.pdf

[14] WinRDBI. www.eas.asu.edu/~winrd

Estudio de experiencias en aprendizaje virtual en bases de datos

M. Elena Rodríguez, Francesc Mayoral, Toni Tassani, Maite Vidal Estudios de Informática y Multimedia

Universitat Oberta de Catalunya Av. Tibidabo, 39-43. E-08035 Barcelona

e-mail: {mrodriguezgo, fmayorals, atassani, mvidalmarti}@uoc.edu

Resumen En esta ponencia se presentan algunas experiencias docentes en el área de bases de datos (BD) en el contexto de la Universitat Oberta de Catalunya (UOC). Estas experiencias muestran una nueva temporización de los contenidos de aprendizaje y un nuevo diseño de las actividades evaluables, conjuntamente con un análisis de los resultados obtenidos como consecuencia de los cambios introducidos. Asimismo se muestra un estudio de la carga de trabajo de los estudiantes de acuerdo al concepto de crédito ECTS del nuevo Espacio Europeo de Educación Superior (EEES).

1. Introducción

La asignatura de Bases de datos II forma parte del plan de estudios de todas las titulaciones en informática, tanto de primer como de segundo ciclo, que ofrece la UOC a través de los Estudios de Informática y Multimedia ([9]). Por lo tanto, forma parte de las titulaciones de Ingeniería Técnica en Informática de Sistemas y de Gestión, así como la titulación de Ingeniería Informática. Constituye una asignatura optativa que tiene asociada una carga lectiva de 6 créditos. En el contexto de la UOC, dada su naturaleza virtual, sin clases presenciales, y dejando al margen el nuevo EEES (ver [6]), se entiende que cada crédito requiere, por parte del estudiante, de 15 horas de estudio de los conceptos teóricos asociados a la asignatura (serían las horas lectivas de teoría en el contexto de una universidad tradicional). La asignatura constituye la continuación natural de Bases de datos I que es la asignatura troncal del área de BD de las ingenierías técnicas. Mientras que Bases de datos I constituye una asignatura con una importante base teórica-conceptual, donde se explican, entre otros, los fundamentos teóricos del modelo relacional,

lenguajes de consulta (álgebra relacional y SQL) y aspectos de diseño conceptual y lógico de BD, Bases de datos II, sin olvidar fundamentos teóricos, constituye una asignatura donde priman contenidos de carácter más práctico. Entre los contenidos de Bases de datos II, se incluyen, entre otros, componentes lógicos de datos y de control (como serían disparadores y procedimientos almacenados en una BD), implementación de métodos de acceso a una BD, transacciones y acceso desde programas de aplicación a BD (SQL hospedado, SQL/CLI y JDBC). El modelo de evaluación de la asignatura, atendiendo al modelo pedagógico de la UOC (para más información, consultar [2]), se fundamenta en la realización de actividades evaluables que se proponen de manera continuada a lo largo del semestre. Existen actividades de carácter optativo, denominadas Pruebas de Evaluación Continuada (PEC), y actividades de carácter obligatorio para la superación de la asignatura, esto es, prácticas. La actividad docente de la asignatura de Bases de datos II se estructura alrededor de dos tipos de aulas (virtuales), una de teoría y otra de laboratorio, con personal docente especializado. Mientras que el objetivo del aula de laboratorio es asistir a los estudiantes en la instalación y uso del software requerido en la asignatura, el aula de teoría es la que concentra la actividad docente a desarrollar. El objetivo de esta ponencia es presentar los motivos (sección 2) que han impulsado al equipo docente de la asignatura a diseñar una nueva temporización de los contenidos de aprendizaje de la asignatura, y el impacto que estos cambios han tenido en el diseño y contenido de las actividades evaluables que se proponen a los estudiantes. También se incluye un análisis de los resultados obtenidos (sección 3), tanto desde un punto de vista de rendimiento académico como de satisfacción, no únicamente del equipo docente de la asignatura, sino también de los estudiantes. A

306 Bases de datos continuación (sección 4), se presenta cómo el nuevo diseño ayuda, al menos en relación a las actividades evaluables, a medir la carga de trabajo real del estudiante, de acuerdo al nuevo EEES. Finalmente, se presentan algunas conclusiones (sección 5) y se esbozan líneas de trabajo futuro.

2. Motivaciones para el cambio

Desde el primer semestre que se empezó a impartir la asignatura de Bases de datos II, y hasta el primer semestre del curso académico 2003-2004 (2003/04-1) inclusive, los contendidos de aprendizaje de la asignatura estaban temporizados de la siguiente manera:

• Tema 1 (T1): Componentes lógicos de BD. • Tema 2: (T2): Programación con SQL. • Tema 3 (T3): Componentes de almacena-

miento de una BD. • Tema 4 (T4): Implementación de los métodos

de acceso. • Tema 5 (T5): Optimización de consultas. • Tema 6 (T6): Gestión de transacciones. • Tema 7 (T7): BD distribuidas y

cliente/servidor. En relación al modelo de evaluación, se proponían 3 PEC (a resolver de manera individual) y una práctica (con opción a ser resuelta en grupos de dos estudiantes) estructurada en dos etapas. Los temas tratados en cada PEC eran los siguientes:

• PEC 1: T1 y T2. Se proponían ejercicios de

complejidad media, consistentes en la implementación de disparadores, procedimientos almacenados y vistas. Adicionalmente se evaluaba la comprensión, a nivel de lectura, del T2.

• PEC 2: T3, T4 y T5. Se proponían ejercicios de carácter teórico-práctico sobre espacios virtuales, implementación de los accesos por valor (índices), y optimización de consultas.

• PEC 3: T6 y T7. Se proponían ejercicios teórico-prácticos de gestión de transacciones, tanto desde un punto de vista externo (visión de usuario) como interno (serializabilidad, recuperabilidad y técnicas basadas en reservas para el control de concurrencia). Adicionalmente, se evaluaba la comprensión a nivel de lectura, del T7.

Por su parte, la práctica presentaba un caso que requería el diseño, creación y manipulación de una BD, tanto con SQL interactivo, como desde un programa de aplicación.

Inicialmente (desde el semestre 1999/00-1, hasta el semestre 2000/01-1), el lenguaje de programación era C y la técnica era SQL/CLI, pero desde el semestre 2000/01-2 el lenguaje de programación ha pasado a ser Java y la técnica el JDBC ([5]). En [4] se presenta la experiencia en la implantación de estos nuevos contenidos en la asignatura. El sistema gestor de la BD utilizado era (y continua siendo) Informix. La práctica estaba estructurada en dos etapas, que trataban los siguientes contenidos:

• PRA 1: T1 y T2. Diseño y creación de la BD,

implementación de disparadores para la comprobación de reglas de negocio y de procedimientos almacenados. Pequeños programas Java destinados a ilustrar, por ejemplo, el uso de sentencias preparadas contra sentencias de ejecución única.

• PRA 2: T2, T4 y T6. Programas Java de más envergadura, destinados a practicar conceptos de transacciones (identificación lógica de unidades de ejecución atómica) y de recuperación de datos de la BD (resultado de consultas SQL), e impacto de la existencia de índices en la resolución de consultas.

Estudio y actividadesevaluables PRA 1 PRA 2

PEC 1 PEC 2 PEC 3

T1 T2 T3 T4 T5 T6 T7

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Semanas Semestre Figura 1. Temporización inicial

En la figura 1 se muestra la temporización del estudio de los diferentes temas, y de las actividades de evaluación continua en un semestre de 15 semanas. Con esta temporización el equipo docente pretendía los objetivos que se describen a continuación. En primer lugar, posibilitar que los estudiantes pudieran repasar conocimientos adquiridos en la asignatura de Bases de datos I; de ahí surge tratar aspectos como el diseño y

XI Jornadas de Enseñanza Universitaria de la Informática 307

creación de la BD en la PRA 1. Esto es particularmente importante en el caso de los estudiantes de la Ingeniería informática. Dado que la titulación está concebida como un segundo ciclo, es posible que haya pasado cierto tiempo entre la obtención del título ingeniero técnico y el inicio de los estudios de segundo ciclo. En segundo lugar, garantizar que los estudiantes llegasen en las condiciones de aprendizaje óptimas a la realización de la práctica (obligatoria), sobre todo aquellos estudiantes que realizan las PEC las cuales, como ya se ha comentado, son de realización voluntaria. Sin embargo, la sensación, compartida tanto por el equipo docente como por los estudiantes, era una sobrecarga de trabajo importante, con repetición de actividades. Esto, en el caso de estudiantes de las ingenierías técnicas, y a efectos de repaso de conocimientos de Bases de datos I, era particularmente importante. Es necesario pensar, por un lado, que los semestres están muy ajustados en tiempo. Por otro lado, es importante tener en cuenta el perfil de estudiante de la UOC; éste acostumbra a ser un estudiante con una edad media superior a los 30 años, plenamente integrado en el mercado laboral y, en general, con cargas familiares asociadas. Por estos motivos, es necesario que el equipo docente de cualquier asignatura diseñe una estrategia de aprendizaje que permita regular el esfuerzo a realizar por parte del estudiante, sin que ello signifique sacrificar el nivel de adquisición de conocimientos que se pretende que el estudiante alcance en la asignatura.

Adicionalmente, el equipo docente de la asignatura detectó otras limitaciones. A pesar de la sensación de repetición, la calidad de las prácticas entregadas no era la esperada. Como ejemplo clásico, en la implementación de reglas de negocio mediante disparadores, en general, los estudiantes no detectaban todos los acontecimientos sobre la BD que pudiesen comprometer el cumplimiento de dichas reglas de negocio.

También se detectaron en la realización de la práctica, problemas relacionados con el concepto de transacción. Una buena parte de los estudiantes eran incapaces de detectar las unidades de ejecución atómicas del caso práctico propuesto por el equipo docente.

Finalmente, se detectó que una parte de los estudiantes tenían problemas con conceptos ajenos

a los objetivos de aprendizaje de la asignatura. Básicamente, estos problemas estaban relacionados con el desconocimiento de conceptos fundamentales de programación orientada al objeto. Estos estudiantes, en general, son los estudiantes de la Ingeniería informática, muchos de los cuales no han recibido formación universitaria en programación orientada al objeto. A pesar que la UOC ofrece un taller Java (de realización optativa y de un mes de duración) para estos estudiantes previamente al inicio de cada semestre, éste resulta escaso, aunque es útil como adaptación a nuevo lenguaje de programación.

Por todos los motivos argumentados, el equipo docente diseñó una nueva temporización de los contenidos de la asignatura, a la vez que acometió un nuevo diseño de las actividades evaluables que se proponen a los estudiantes. Estos cambios se produjeron en el semestre 2003/04-2. En las dos subsecciones siguientes se comentan en detalle todos estos cambios.

2.1. Temporización de contenidos

Los cambios introducidos en la temporización se fundamentan en reforzar el objetivo de garantizar que los estudiantes, antes de acometer la realización de la práctica obligatoria, tengan un dominio teórico suficiente de los conceptos que se pretenden poner en práctica. Una de las limitaciones mencionadas en la sección anterior tenía que ver con el uso de transacciones. Los conceptos relacionados a este tema llegaban tarde en el tiempo. En consecuencia, muchos estudiantes ni siquiera se planteaban la necesidad de su utilización, de tal manera que trabajaban siempre con la confirmación automática de transacciones (una sentencia SQL, una transacción). Es más, era posible que estos mismos estudiantes tuviesen una buena calificación en la realización de la PEC donde se tratan aspectos más teóricos de gestión de transacciones, como serían conceptos de serializabilidad y recuperabilidad. Desde la perspectiva del equipo docente, parecía que los estudiantes, o bien únicamente estudiaban el capítulo de gestión de transacciones para la realización de la PEC (con lo cual no seguían la temporización propuesta por el equipo docente), o bien eran incapaces de transferir aquellos conocimientos a un plano más práctico,

308 Bases de datos de diseño de transacciones, esto es, eran incapaces de detectar las unidades mínimas de ejecución atómicas que se proponían en la práctica. Para solucionar estas deficiencias el equipo docente decidió avanzar el estudio del tema de gestión de transacciones, de tal manera que constituye, tras un breve tema de introducción (que no se ha indicado en la sección previa), el primer capítulo de la asignatura. En consecuencia, los contenidos de la asignatura quedan temporizados de la siguiente manera: • Tema 6 (T6): Gestión de transacciones. • Tema 1 (T1): Componentes lógicos de BD. • Tema 2: (T2): Programación con SQL. • Tema 3 (T3): Componentes de almacena-

miento de una BD. • Tema 4 (T4): Implementación de los métodos

de acceso. • Tema 5 (T5): Optimización de consultas. • Tema 7 (T7): BD distribuidas y

cliente/servidor. En la figura 2 se muestra esta nueva temporización de contenidos y de actividades evaluables. Estudio y actividadesevaluables PRA 1 PRA 2

PEC 1 PEC 2 PEC 3

T6 T1 T2 T3 T4 T5 T7

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Semanas Semestre Figura 2. Nueva temporización

2.2. Actividades evaluables

En relación a las PEC (de realización individual), los cambios introducidos son los siguientes: • PEC 1: T6, T1 y T2. Se mantienen los

ejercicios teórico-prácticos de gestión de transacciones, así como la evaluación, a nivel de lectura del T2. En relación a T1, los ejercicios de implementación han quedado substituidos por otro tipo de ejercicios que invitan a la reflexión sobre alternativas de solución, y el análisis de soluciones.

• PEC 2: T3 y T4. La tipología de ejercicios no ha cambiado. Las variaciones vienen determinadas por la temporización.

• PEC 3: T5 y T6. La tipología de ejercicios tampoco ha cambiado. Las variaciones son consecuencia de la nueva temporización.

Básicamente, la idea subyacente en los cambios de tipología de ejercicios del T1 de la PEC 1, es la de proveer a los estudiantes de estrategias que les permitan elaborar soluciones de calidad en la práctica; éstas se podrían resumir en “pensar antes de actuar”. Además, se evita la sensación de repetición, quedando todos los aspectos de implementación concentrados en la práctica. En el caso de la práctica los cambios introducidos son de más profundidad. En primer lugar, el caso que se propone en la práctica está basado en la práctica realizada durante el semestre inmediatamente anterior en la asignatura de Bases de datos I. Además, los estudiantes reciben conjuntamente con el enunciado de la práctica de Bases de datos II, el enunciado y solución de la práctica de Bases de datos I. De esta manera, los estudiantes de segundo ciclo tienen una idea clara del nivel de conocimientos que de ellos se espera, pasando a ser su responsabilidad garantizar esos conocimientos de mínimo. Si están por debajo del nivel esperado, pueden de manera individual resolver la práctica de Bases de datos I, y autoevaluarse a continuación, dado que se suministra su solución. En el caso de los estudiantes de primer ciclo, éstos salen claramente beneficiados. Si realizan la asignatura en semestres consecutivos, ya conocen el universo de discurso del caso de la práctica. Es más, en Bases de datos I se avanzan situaciones que no saben resolver hasta que no cursen la asignatura de Bases de datos II, e incluso se repiten ejercicios. Un ejemplo sería implementar la misma regla de negocio en la práctica de Bases de datos I y Bases de datos II. Mientras que en Bases de datos I se haría mediante una aserción de SQL estándar, en Bases de datos II se realizaría ese mismo ejercicio mediante disparadores. Finalmente, el segundo gran cambio introducido en la práctica ha consistido en proporcionar a los estudiantes un esqueleto del código Java a implementar debidamente estructurado en clases y ampliamente documentado. Buena parte del código se proporciona, quedando únicamente pendiente de

XI Jornadas de Enseñanza Universitaria de la Informática 309

implementación todas aquellas funcionalidades que implican un acceso a la BD. De esta manera todos los estudiantes pueden concentrar sus esfuerzos en aspectos que son propios de la asignatura. Adicionalmente este procedimiento facilita, a la vez que sirve de aprendizaje, la realización de la práctica a aquellos estudiantes de segundo ciclo con escasos conocimientos en el paradigma de la orientación a objetos. Así pues, la práctica (a ser resuelta de manera individual o en grupos de dos personas) queda estructurada en las dos siguientes etapas: • PRA 1: T6, T1 y T2. Implementación de

disparadores y procedimientos almacenados. Programas Java que ilustran el uso de sentencias preparadas, de sentencias de ejecución única, de tratamiento de nulos, etc.

• PRA 2: T2, T4 y T6. Programas Java que elaboran informes que implican consultas de cierta complejidad, consultas de metadatos del catálogo, impacto de la existencia de índices en la BD, etc.

0102030405060708090

100

superan/matrícula 79,4 68,9 71 77

superanEC/matrícula

75,7 64,1 69,49 70,5

2002/03 2 2003/04 1 2003/04 2 2004/05 1

Figura 3. Rendimientos académicos

Es importante notar que la parte de diseño y creación de la BD ha quedado eliminada, o alternativamente, pasa a formar parte del propio enunciado de la práctica, dado que se basa en la BD que ha sido diseñada y creada en la práctica de Bases de datos I. También se debe destacar que no se hace explícito el concepto de transacción en el enunciado de la práctica. Éste debe surgir de manera natural, dado que no es específico del JDBC, sino del propio acceso, ya sea para consulta o modificación, a la BD, independientemente de la técnica empleada. En cualquier caso, obviamente, constituye un aspecto de evaluación fundamental, y el equipo docente incide en su importancia al finalizar la PRA 1, de manera que aquellos estudiantes que han tenido

dificultades con este concepto lo tengan en cuenta en la PRA 2. En la antigua planificación era complicado realizar este tipo de acciones dado que, como ya se ha explicado, en el tiempo, el estudio del tema estaba previsto a la finalización del semestre.

3. Análisis de resultados obtenidos

En esta sección se muestran algunos indicadores relevantes de la asignatura, correspondientes a los últimos semestres. En este período de tiempo, el equipo docente se ha mantenido invariable; el número de estudiantes matriculados ha ido creciendo desde los 106 estudiantes del semestre 2002/03-2 hasta los 163 estudiantes de este último semestre 2004/05-1. Como ya se ha argumentado, los cambios en la temporización de contenidos y diseño de actividades de evaluación continuada se realizaron en el semestre 2003/04-2. La figura 3 muestra el rendimiento académico en este período de tiempo sobre el total de estudiantes matriculados. Como se puede observar, la asignatura tiene un buen rendimiento académico, como suele corresponder a una asignatura optativa de especialización. La figura también muestra que la superación de las actividades de evaluación continua (las PEC, dado que la práctica es obligatoria), constituye un aspecto clave en la superación final de la asignatura. A pesar del decremento en el rendimiento registrado en el semestre 2003/04-1 (para el cual no se dispone de una explicación objetiva), se puede observar que éste se recupera en los semestres posteriores, volviendo a alcanzar valores similares en el semestre 2004/05-1. Aunque no se puede afirmar que los cambios introducidos hayan ayudado a mejorar cuantitativamente el rendimiento académico, el equipo docente ha observado una mejora en la calidad de las actividades evaluables entregadas, lo cual tiene un reflejo inmediato en la distribución de las notas finales de los estudiantes que superan la asignatura. A pesar de que por razones de espacio no se muestra esta distribución de notas finales, se ha observado un desplazamiento de calificaciones finales del aprobado al notable. Aunque tampoco se muestran datos del seguimiento parcial de cada PEC, los abandonos

310 Bases de datos en el seguimiento de la evaluación continua se concentran en la PEC 1, mientras que en los semestres previos a los cambios, los abandonos se distribuían de manera más uniforme. Posiblemente, la explicación es la presencia en la PEC 1 del tema de gestión de transacciones (T6), el cual es particularmente difícil.

Por su parte, la figura 4 muestra dos de los indicadores que se obtienen a partir de las respuestas de los estudiantes a las encuestas que la UOC realiza a la finalización de cada semestre (en el caso de la asignatura de Bases de datos II alrededor del 30% de los estudiantes responden la encuesta). Son indicadores relacionados con la valoración del equipo docente y la valoración de los contenidos de la asignatura.

0102030405060708090

100

equipo docente 68,4 85,3 90

contenidos 68,4 75,8 89

2002/03 2 2003/04 1 2003/04 2

Figura 4. Resultados encuestas

Lo más significativo en ambos indicadores es la tendencia al alza en la valoración de los estudiantes; a pesar del decremento en el rendimiento académico el semestre 2003/04-1, la valoración del equipo docente y de los contenidos de la asignatura mejoró. En el momento de escribir esta ponencia, los datos relativos a este semestre que acaba de concluir no estaban disponibles. Al margen de las encuestas, los estudiantes también han hecho llegar sus valoraciones, vía mensajes, al equipo docente. Los estudiantes han agradecido significativamente el cambio de enfoque dado a la asignatura, principalmente en el caso de la práctica. El presentar un modelo orientado a objetos ya resuelto además de facilitar la comprensión del enunciado, contribuye a ofrecer al estudiante una visión confortable e integradora de sus estudios, de modo que el objetivo de aprendizaje en esta asignatura se ve ampliamente satisfecho al centrar y limitar el espacio de trabajo. Un modelo como el que se ha seguido ha supuesto un esfuerzo considerable para

el equipo docente en la preparación de la práctica, además de comprometer la visión del diseño orientado a objetos del enunciado. Este compromiso el estudiante no sólo lo ha entendido favorablemente, sino que también lo ha valorado de forma muy positiva, pues le ha supuesto una extensión de sus conocimientos en programación. Por otra parte, este esfuerzo del equipo docente se ha visto recompensado por lo que a la corrección de la práctica supone, puesto que se ha optimizado considerablemente el tiempo de dedicación.

Finalmente, la introducción en primer lugar del T6 ha supuesto un cambio estratégico altamente valorado por el equipo docente. La respuesta de los estudiantes ha sido positiva, pues les ha permitido conocer de buen principio las principales características del entorno transaccional, dando lugar a unas primeras discusiones en el aula de teoría que han permitido al equipo docente desde buen principio promover y motivar la participación de los estudiantes en la misma.

4. Adecuación al nuevo espacio europeo de educación superior

El sistema de créditos ECTS (European Transfer Credit System) es una de las piedras angulares de la Declaración de Bolonia de 1999 ([6]) y constituye, por tanto, un aspecto clave en el proceso de diseño del nuevo EEES. Este sistema de créditos se caracteriza por contabilizar el número de horas teniendo en cuenta el trabajo realizado por el estudiante en la adquisición de los conocimientos, capacidades y habilidades asociados a una asignatura. Por lo tanto, incluye las horas correspondientes a horas lectivas (sean de teoría o de laboratorio), las de estudio, las dedicadas a la realización de prácticas u otros trabajos que se puedan proponer, así como las horas exigidas para la preparación y realización de exámenes.

El número de horas que un estudiante necesita para adquirir un conjunto de conocimientos, capacidades y habilidades depende de diversos factores como, por ejemplo, de la propia destreza del estudiante, pero también depende en gran medida de los métodos de enseñanza y de aprendizaje, de los recursos utilizados por la propia institución y de los recursos suministrados por el equipo docente de cada asignatura.

XI Jornadas de Enseñanza Universitaria de la Informática 311

En este sentido, la nueva planificación de la

asignatura, sobretodo en lo relacionado con el nuevo diseño de actividades evaluables, y especialmente en el diseño de la práctica, ha ayudado al equipo docente de la asignatura a determinar el número de horas que un estudiante necesita para alcanzar un conjunto de resultados de aprendizaje y competencias.

La determinación de la carga de trabajo del estudiante medio tiene en cuenta el contexto y la metodología de educación a distancia virtual de la UOC ([2]), y se basa en el trabajo liderado por el área de Desarrollo del Modelo Educativo ([1]) que contó con la participación, entre otros, de profesores, personal docente colaborador y estudiantes de los diversos estudios de la UOC. El trabajo define cuatro grandes ámbitos de medida para cada asignatura vinculados al tipo de actividad que realiza el estudiante. Cada ámbito queda subdividido en diversas tareas. Finalmente, para realizar cada una de estas tareas, el estudiante realiza una secuencia de acciones que variará, tanto en tipo como en número, de la tarea y de las condiciones específicas de cada asignatura.

A continuación se muestra la aplicación del trabajo previamente descrito al caso particular de Bases de datos II:

• Ámbito 1: Planificación y organización de la

asignatura. Incluye tareas de preparación del material y recursos de la asignatura (con acciones de descarga e instalación de software), y de gestión del tiempo y de organización del trabajo de acuerdo con el plan (o guía) docente de la asignatura.

• Ámbito 2: Aprendizaje. Incluye tareas de trabajo sobre el material y módulos didácticos ([7]) de la asignatura (con acciones de lectura y estudio), la realización de ejercicios y actividades de aprendizaje (con acciones de consulta y resolución de ejercicios propuestos en PEC, prácticas y exámenes de semestres anteriores), y la utilización de software (incluye acciones como la consulta puntual de manuales, y la prueba de ejercicios, por ejemplo, los propuestos en el material didáctico o en las prácticas de semestres anteriores).

• Ámbito 3: Aprendizaje evaluable. Incluye tareas como la realización de las 3 PEC propuestas en la asignatura, las dos partes de la práctica obligatoria, y la realización de

pruebas de evaluación final presencial (exámenes o pruebas de validación). Las dos primeras tareas incluyen acciones como la propia elaboración de la actividad evaluable (incluyendo el uso de software en la práctica), y la revisión crítica del trabajo realizado, comparándolo con la solución oficial propuesta por el equipo docente de la asignatura.

• Ámbito 4: Interacción y comunicación. Incluye tareas de participación y seguimiento de buzones y espacios de comunicación compartidos de la asignatura (aulas de teoría o de laboratorio), con acciones de lectura y escritura de mensajes acerca de dudas sobre los contenidos y actividades evaluables.

La figura 5 muestra la distribución de las 162,50 horas de trabajo real por parte del estudiante que el equipo docente ha estimado para la asignatura de Bases de datos II en cada uno de los ámbitos identificados. En el ámbito 2, el total de horas dedicadas a las acciones de estudio del material didáctico se distribuyen por temas de la siguiente manera: T6, T1 y T2 30 horas (10 por tema), T3 3 horas, T4 6 horas, T5 3 horas y T7 3 horas. En esta distribución se tiene en cuenta aspectos como el carácter más práctico o teórico de cada tema concreto, la importancia que le otorga el equipo docente (independientemente de la extensión en páginas que tenga el material didáctico dedicado a cada tema) y la experiencia docente en asignaturas afines en universidades presenciales de parte del equipo docente de la asignatura. El resto de horas de este ámbito se dedican a la realización de ejercicios y a la familiarización del estudiante con el software a utilizar en la asignatura. Es importante destacar que el número de horas estipulado en este ámbito coincide, prácticamente, con el creditaje asignado previo al nuevo EEES, el cual se ha mencionado en la introducción. En relación al ámbito 3, se ha estimado un total 15 horas de trabajo para la realización de las 3 PEC propuestas en la asignatura (8 horas para la PEC 1 (T6, T1 y T2), 4 horas para la PEC 2 (T3 y T4) y 3 horas para la PEC 3 (T5 y T6)), y 20 horas de trabajo para la realización de la práctica. El resto de horas se dedican a la revisión del trabajo realizado en base a la solución oficial proporcionada por equipo docente, y a la realización del examen presencial.

312 Bases de datos

4,00

92,00

40,50

26,00

0,00

20,00

40,00

60,00

80,00

100,00

Ámbito 1 Ámbito 2 Ámbito 3 Ámbito 4

Figura 5. Distribución carga de trabajo

El total de horas dedicadas a cada PEC refleja la importancia relativa que a cada tema otorga el equipo docente. También es necesario destacar que el hecho de concentrar exclusivamente aspectos de implementación en la práctica, conjuntamente con el hecho de proporcionar una práctica parcialmente implementada, previamente desarrollada en su totalidad por el equipo docente, facilita la estimación de horas que el estudiante debe dedicar a su elaboración. Finalmente, es importante remarcar que el total de horas a dedicar para la realización de una actividad no es contradictorio con la planificación semanal que muestra la figura 2. Por ejemplo, el hecho que se otorgue una duración total de 9 semanas para la realización de la práctica, significa que el estudiante tiene más grados de libertad y, en consecuencia, deberá autoorganizar su tiempo de acuerdo a ésa y otras actividades que se le puedan haber propuesto en otras asignaturas.

5. Conclusiones y trabajo futuro

Como conclusiones, destacar que la respuesta positiva de los estudiantes ante el cambio estratégico en la asignatura ha supuesto una alta motivación para el equipo docente. Además, se ha conseguido vertebrar adecuadamente el proceso de aprendizaje, y obtener una consolidación firme de conocimientos teóricos y prácticos. Adicionalmente, se ha obtenido un compromiso integrador en la formación del estudiante dentro del plan de estudios, permitiendo un acercamiento seguro y controlado a los contenidos de aprendizaje, además de facilitar al equipo docente la estimación de la carga de trabajo de los estudiantes. Como trabajo futuro, para la práctica, el equipo docente pretende entregar pruebas unitarias, basadas en JUnit ([3]), que permitan que los estudiantes validen su código. El fin último es

permitir la corrección semiautomática de la práctica. También se pretende corroborar con los estudiantes las estimaciones realizadas en relación a la carga de trabajo de la asignatura. Finalmente, y en relación a las líneas de investigación en e-learning basadas en estándares desarrolladas en la UOC, se desea avanzar en la posibilidad de establecer diferentes itinerarios de aprendizaje, de acuerdo a diferentes perfiles de estudiantes.

Agradecimientos

Los autores quieren agradecer a los revisores los comentarios recibidos, los cuales han ayudado a elaborar la versión final de esta ponencia.

Referencias

[1] Desarrollo del Modelo Educativo (DeME). Instrument de mesura de la càrrega de treball de l’estudiant. Criteris i pautes d’aplicació. Informe de trabajo interno. UOC, 2004.

[2] Duart, J.M., Sangrà, A. (coord.). Aprender en la virtualidad. Gedisa, 2000.

[3] Portal de JUnit.org. http://www.junit.org. [Último acceso Febrero de 2005].

[4] Marcó Simó, J.M. SQL Programado desde Java: profundización en el diseño y acceso a bases de datos consolidando el conocimiento del lenguaje. Actas de las VIII Jornadas de Enseñanza Universitaria de la Informática, págs. 179-186. Departamento de Informática, Universidad de Extremadura. Cáceres, 2002.

[5] Melton, J., Eisenberg, A. Understanding SQL and Java together: a guide to SQLJ, JDBC, and related technologies. Morgan Kaufmann, 2000.

[6] Ministerio de Educación y Ciencia. Portal de Universidades. http://wwwn.mec.es/univ/. [Último acceso Febrero de 2005].

[7] Sistac J. (coord.). Bases de datos II. EDIUOC, 2004. También disponible una primera edición, en lengua catalana, en [8].

[8] Sistac J. (coord.), Camps R., Costal, D., Mallafré, X., Rodríguez M.E., Segret, R. (autores). Tècniques avançades en bases de dades. EDIUOC colección manuales número 39, 2000.

[9] Portal de la Universitat Oberta de Catalunya. http://www.uoc.edu/web/esp/. [Último acceso: Febrero de 2005].

DerEditor4GL: Software para la docencia en el diseño de Bases de Datos

Piedad Garrido Picazo, Manuel Coll Villalta, Francisco J. Martínez Domínguez Departamento de Informática e Ingeniería de Sistemas (DIIS)

Escuela Universitaria Politécnica de Teruel, Universidad de Zaragoza E-mail:{piedad@unizar.es, mhvcoll@gmail.com, F.Martinez@unizar.es}

Resumen El presente trabajo presenta el desarrollo de una herramienta CASE (Computer-Aided Software Engineering) llamada DerEditor4GL [11], que genera lenguaje lógico conceptual y lenguaje SQL (Structured Query Language). Esta herramienta está pensada para su uso en la enseñanza de la asignatura Bases de Datos II, impartida a los alumnos de tercer curso de Ingeniería Técnica en Informática, especialidad Gestión.

Los objetivos de esta aplicación gráfica son por un lado, facilitar la compresión de las distintas fases de diseño por las que pasa un sistema de información antes de ser procesado en un computador, por otro, permitir la visualización del esquema conceptual y lógico, y finalmente, la generación del código asociado a cada uno de los objetos de representación, en tiempo real y de forma transparente al usuario.

Esta herramienta CASE va a ser utilizada en las prácticas de la asignatura Bases de Datos II dentro de la titulación de Ingeniería Técnica en Informática de Gestión de la Escuela Universitaria Politécnica de Teruel.

1. Introducción

En el actual plan de estudios para la obtención del título de Ingeniero Técnico en Informática de Gestión en la Universidad de Zaragoza, el estudio de la disciplina de Bases de Datos se divide en dos asignaturas de carácter troncal y obligatorio, respectivamente: Bases de Datos I y Bases de Datos II [9, 10] ubicadas en quinto y sexto semestre de la titulación, respectivamente.

En la asignatura Bases de Datos I se definen conceptos tales como: qué es un Sistema de Información, sus componentes y funciones, qué se entiende por Sistema Gestor de Bases de Datos, así como qué es una Base de Datos. Posteriormente, se presenta una panorámica del modelo relacional de datos, se habla de la organización física de las bases de datos, y se trata en profundidad el SQL (Structured Query Language)[4] haciendo especial hincapié en cómo se ha ido adaptando a la evolución del modelo relacional de datos.

La asignatura de Bases de Datos II es una continuación de Bases de Datos I, cuyo principal objetivo es presentar una metodología de diseño de bases de datos relacionales basada en el modelo Entidad-Relación.

La docencia de ambas asignaturas se organiza en (4+2), 4 créditos de teoría y problemas y 2 créditos de trabajo en el laboratorio. Este trabajo consiste en la realización, de modo coordinado con las clases de teoría y problemas, de una serie de prácticas que refuerzan la comprensión de los conceptos estudiados y permiten su correcta aplicación.

En la presente ponencia se presenta una herramienta CASE (Computer-Aided Software Engineering) que asesorará al alumno a lo largo de la segunda y la tercera práctica de la asignatura Bases de Datos II, que versan sobre el análisis y diseño del esquema conceptual y lógico, respectivamente.

Previamente, el alumno ya habrá trabajado de forma teórica el aprendizaje de los distintos módulos y objetos que participan en el diseño.

El contenido del presente trabajo está organizado de la siguiente manera: en el segundo apartado se presenta en detalle la herramienta que ayuda al diseño de bases de datos.

314 Bases de datos

En el tercer apartado se presenta la arquitectura software de DerEditor4GL y comentan los resultados y ficheros que genera.

En el apartado número 4, se explica el trabajo a realizar por los alumnos matriculados en la asignatura.

Finalmente, se enumeran una serie de posibles ampliaciones y mejoras para las futuras versiones de la herramienta.

2. Descripción de la herramienta

DerEditor4GL permite a los alumnos implementar de forma sencilla y atractiva, el modelo relacional teórico de cualquier base de datos.

De esta forma, los alumnos pueden hacerlo sin tener que entrar a comprender los detalles específicos y propios de cada uno de los editores gráficos que proporcionan los diferentes administradores corporativos de los sistemas gestores de bases de datos relacionales existentes

en el mercado, lo que en terminología de esta disciplina se conoce como esquema físico.

Cuando se plantean las prácticas de toda asignatura perteneciente a esta disciplina, hay que tener en cuenta que el alumno tiene doble tarea a realizar; por un lado, aún no ha terminado de asimilar el modelo estudiado en el módulo teórico de la asignatura, cuando por otro lado, se encuentra con que parte de los objetos de información que ha ido aprendiendo en clase, no se implementan de igual forma si se trabaja con diferentes gestores como MySQL, PostgreSQL, Oracle, SQLServer, etc.

DerEditor4GL permite al alumno realizar el diseño del esquema conceptual, ciñéndose a las pautas presentadas en las horas teóricas de la asignatura, y así obtener de forma sencilla e instantánea el pseudocódigo correspondiente al esquema lógico, para simultáneamente obtener su homólogo en SQL.

Características DBDesigner DeZign xCase DEREditor4GL

Plataformas soportadas Windows/Linux Windows Windows Windows/Linux Unix/MacOS/PowerOS

Licencia de uso GPL Propietario/Trial Propietario/Trial GPL

Capacidad de la interfaz Alta Alta/Adaptable Exhaustiva Sencilla

Formato y aspecto del diagrama No No Sí Sí

Generación de código SQL Múltiples SQL Descriptivo / Pseudo / SQL

Inserción manual de código Sí No No No

Ingeniería inversa Sí Sí Sí No

Formatos de exportación XML HTML/Doc/Jpeg HTML/Rtf Doc/Jpeg

Motor integrado de consultas Sí No No No

Conocimientos necesarios Muy altos Altos Altos Muy bajos

Simbología de diagramas No estándar No estándar No estándar Estándar

Uso de teoría diagramas E-R No Sí Sí Sí

Nuevos tipos de datos, dominios No No Sí Sí

Gestión de relaciones n-arias No Sí No Sí

Modelos jerárquicos y débiles No Sí No Sí

Chequeo automático de diseño No No No Sí

Figura 1. Comparativa de diferentes herramientas de diseño de Bases de Datos

XI Jornadas de Enseñanza Universitaria de la Informática 315

Además, para verificar el correcto funcionamiento del diseño, la herramienta desarrollada incorpora un manejador de errores, guiando al usuario en todo momento hacia la obtención de la solución correcta.

La principal contribución de esta herramienta es precisamente la posibilidad de, no sólo obtener en un único paso el esquema conceptual, el esquema lógico y el código SQL asociado, sino también realizar su implementación de una forma sencilla y rápida, ya que el tiempo disponible para la realización de la práctica es de dos sesiones de dos horas cada una.

DerEditor4GL se trata de software libre adhoc, desarrollado una vez revisados otros productos significativos que perseguían objetivos similares, habiendo realizado previamente una comparativa y viendo las posibles carencias y oportunidades de mejora que ofrecían.

Los resultados de dicha comparativa se muestran en la Figura 1. Cabe destacar que este análisis ha sido llevado a cabo teniendo en cuenta tanto herramientas propietarias como herramientas de software libre existentes en el mercado.

De la interpretación de los parámetros escogidos para llevar a cabo la comparativa, presentados en la tabla, se deduce que DerEditor4GL soporta todas las características básicas.

Sin embargo, no proporciona funcionalidad de ingeniería inversa, inserción manual de código y motor integrado de consultas. Características que no afectan al buen funcionamiento y expectativas de la herramienta, pero que se deben considerar como posibles ampliaciones de la aplicación en las futuras versiones.

Por otro lado, es la única herramienta que cumple los requisitos en todos los aspectos teóricos de diseño. Además, es una aplicación flexible, que puede ser utilizada por cualquier tipo de usuario, ya sea novel o experto.

Finalmente, destacar que permite la definición de nuevos tipos de datos o dominios, gestiona relaciones n-arias, implementa agregaciones, relaciones reflexivas, entidades débiles, generalizaciones/especializaciones y chequea de forma automática el diseño.

3. Arquitectura y funcionamiento

En la siguiente figura se muestra la organización de la aplicación en módulos, y su interconexión.

El corazón de la aplicación es el módulo central DEREditor. Es el constructor de la aplicación y el encargado de iniciar los módulos Config, DERGrafo, y los módulos de E/S: Archivador, Impresor y Visual.

Figura 2. Arquitectura de la aplicación

Visual

ConfigArchivad

Impresor

Usuario

Soporte físico

DEREdito

Soporte en papel

Converso

Corrector

Codigen

DERGrafo

Aplicación

Logic

316 Bases de datos

Una vez los ha iniciado, carga la configuración y se mantiene en espera de recibir información del módulo Visual.

Por otro lado, se encuentran las librerías Logic, que permiten mantener un diagrama acorde a la teoría de los diagramas E-R, y el módulo Corrector, que es el encargado de realizar un análisis del diseño en busca de posibles errores que puedan generar código erróneo. Este análisis es realizado sobre cada elemento del diagrama, examinando sus datos mediante las librerías Logic. También analiza las asociaciones entre elementos, en busca de incompatibilidades.

4. Trabajo del alumno

De acuerdo con Kendall & Kendall [7], la ingeniería de sistemas asistida por ordenador es la aplicación de tecnología informática a las

actividades, las técnicas y las metodologías propias de desarrollo. Su objetivo es acelerar el proceso para el que han sido diseñadas.

En el caso de las herramientas CASE, se utilizan para automatizar o apoyar una o más fases del ciclo de vida del desarrollo de sistemas.

Cuando se hace la planificación de la base de datos, la primera etapa del ciclo de vida de aplicaciones que acceden a un repositorio de información, se puede escoger una herramienta CASE que permita llevar a cabo el resto de tareas del modo más eficiente y efectivo posible.

El principal objetivo de esta herramienta es el de ofrecer al alumno la posibilidad de analizar de una forma muy sencilla y visual el correcto diseño y funcionamiento de las fases de todo diseño de base de datos que se precie.

Figura 3. Ejemplo de Esquema Conceptual generado con DerEditor4GL

XI Jornadas de Enseñanza Universitaria de la Informática 317

Se trata de una herramienta de software libre que ha sido implementada íntegramente en Java, por lo que es multiplataforma y se distribuye, bajo licencia GPL, actualmente en sourceforge.net [11] y próximamente en freshmeat.net.

Tal y como se ha demostrado en la comparativa previa, herramientas tales como el DBDesigner, Dezign, Xcase, etc., poseen dos claros inconvenientes: por un lado, no se ajustan a la teoría de diagramas entidad-relación, y por otro, la mayoría de estas herramientas generan código dependiente de los lenguajes de alto nivel predominantes en el mercado.

Si a esto le añadimos que para la utilización de los mismos se requiere tener unos elevados conocimientos teóricos de la materia, nos encontramos con que resulta complicada su utilización en un entorno educativo, sobretodo en sus primeras fases de aprendizaje.

El trabajo de los alumnos consiste en representar las entidades, atributos y relaciones, y sus peculiaridades, siempre ciñéndose a la información extraída en una fase de análisis previa del sistema de información real a procesar.

Todo objeto gráfico que necesitan, ya sea un rombo nominado, un arco, un rectángulo o una elipse, lo tienen disponible en una paleta de herramientas (ver figura 3), creada expresamente para esta aplicación, y cuyo contenido les va a ser muy familiar ya que se ajusta fielmente a la representación vista en clase.

En la primera sesión de prácticas, de dos horas de duración, los alumnos se dedicarán a analizar en detalle el sistema de información a implementar, con el resto de componentes de su grupo.

En la práctica 2, los alumnos deberán familiarizarse un poco con el entorno de trabajo e interactuar con él, para así obtener el esquema conceptual de su sistema de información.

En la práctica 3, deberán proceder a la interpretación del pseudocódigo que se irá generando de forma automática (ver algoritmo 1) mientras ellos van construyendo de forma gráfica, la estructura de su repositorio de información.

Este código se corresponderá con la notación vista en clase para la obtención del esquema lógico, lo que facilitará enormemente la comprensión y el repaso de los conceptos por parte de los alumnos.

-Inicio de pseudocodigo -- Dominio dom_cadena Dominio dom_nif="00000000A" ( V x(Dom x=dom_nif) -> (xdom_nif <= "99999999Z" ^

xdom_nif >= "00000000A") ) Dominio dom_prodcod="A000" ( V x(Dom x=dom_prodcod) -> (xdom prodcod <= "Z999" ^

xdom_prodcod >= "A000") ) /* Entidad Empresa: */ Empresa (nif:dom_nif, domicilio:dom_cadena, nombre:dom_cadena ) Clave Primaria { nif } Valor No Nulo { domicilio } Valor No Nulo { nombre } /* Entidad Empleado: */ Empleado (dni:dom_nif, nombre:dom_cadena, domicilio:dom_cadena ) Clave Primaria { dni } Valor No Nulo { nombre } /* Relacion Trabajan: */ Trabajan (nif:dom_nif, dni:dom_nif ) Clave Primaria { dni } Valor No Nulo { nif } Clave Ajena { nif } hace referencia a Empresa Clave Ajena { dni } hace referencia a Empleado /* Relacion Jerarquia: */ Jerarquia (dni1:dom_nif, dni2:dom_nif ) Clave Primaria { dni1 } Valor No Nulo { dni2 } Clave Ajena { dni1 } hace referencia a Empleado Clave Ajena { dni2 } hace referencia a Empleado /* Entidad Producto: */ Producto (prodcod:dom_prodcod, nombre:dom_cadena, Descripcion:dom_cadena ) Clave Primaria { prodcod } Unico { nombre }

318 Bases de datos /* Relacion Elaboran: */ Elaboran (nif:dom_nif, prodcod:dom_prodcod ) Clave Primaria { prodcod } Valor No Nulo { nif } Clave Ajena { nif } hace referencia a Empresa Clave Ajena { prodcod } hace referencia a Producto -- Fin de pseudocodigo --

Algoritmo 1. Pseudocódigo del ejemplo de la Figura 3

La interpretación del código es esencial, ya

que antes de proceder a la elección de un gestor físico y exportar el código SQL generado al analizador de consultas, el esquema debe pasar lo que en base de datos se conoce como teoría de la normalización.

Este proceso no se realiza automáticamente, por razones obvias de complejidad y de diversidad de soluciones, quedando en manos del diseñador.

Los resultados que se generan por la aplicación, pueden volcarse en ficheros textuales o gráficos, dependiendo de la fase de diseño de la que se quiera obtener la información.

En el caso de llevarse a cabo una acción incorrecta, el sistema posee un sistema manejador de errores a nivel de cada módulo, y un módulo denominado Corrector, que es el encargado de realizar un análisis del diseño en busca de posibles errores que puedan derivar en código erróneo.

Todo ello, resulta muy útil para el alumno, ya que le permite profundizar de forma sencilla en el estudio y comprensión de las pautas a seguir para la obtención del código, y poder comprobar de forma visual cualquier situación teórica.

La evaluación de la práctica se realizará a través de una entrevista con los distintos grupos de alumnos, con preguntas relativas a los resultados obtenidos con DerEditor4GL.

La idea es ponerlo en práctica este curso académico para la realización de las prácticas de la asignatura, y poder así hacer una comparativa con los resultados previos obtenidos, cuando el alumno se tenía que enfrentar directamente al administrador corporativo de cualquier gestor de bases de datos comercial o libre disponible en el mercado.

Si la experiencia resulta positiva, también se espera incorporarlo como herramienta para la

evaluación de la asignatura, añadiendo algunos aspectos de seguridad.

Figura 4. Cuadro de diálogo Preferencias

5. Análisis de ampliaciones y mejoras

Como se ha comentado anteriormente, para las futuras versiones de la herramienta, se sopesarán posibles ampliaciones de la herramienta en aspectos tales como: - Ingeniería inversa. De esta forma, la

aplicación podrá crear un diagrama Entidad-Relación, a partir de cualquier código escrito en alguno de los lenguajes soportados por el software DerEditor4GL.

- Inserción manual de código. Para que los alumnos puedan modificar el código directamente, y que dichos cambios queden reflejados en el diseño generado por la aplicación.

- Motor integrado de consultas. De esta forma los alumnos podrán introducir y probar diferentes consultas, en la base de datos creada.

- Soporte de dominios universales. Se puede modificar la aplicación para que incorpore una serie de tipos de datos universales y válidos para cualquier SGBD basado en SQL, evitando así la tarea de crear los dominios necesarios para cada diagrama, que puede acarrear un buen esfuerzo por parte del usuario.

- Autocolocación de elementos. Facilitando así el uso de la herramienta, al seleccionar

XI Jornadas de Enseñanza Universitaria de la Informática 319

ésta de forma automática la mejor ubicación de los diferentes elemento y permitir una correcta visualización.

- Aumento de los formatos de exportación. Para ampliar las posibilidades de uso de la aplicación.

Por otro lado, dado que su implementación ha

sido llevada a cabo a lo largo de siete meses, han aparecido diversas actualizaciones de algunas de las tecnologías aplicadas: por ejemplo Java 1.5 en lugar de 1.4.2, o JGraph 5.3.1 en lugar de 5.0.

Por lo que será necesario estudiar si alguna de las mejoras aparecidas puede ser utilizada en las nuevas versiones.

6. Conclusiones

DerEditor4GL es una aplicación capaz de facilitar el diseño y la gestión de diagramas, así como la generación de código, de manera limpia, efectiva, y que resuelve varios problemas detectados durante el uso de herramientas en las prácticas de este tipo de asignaturas por parte de los alumnos: su utilización no requiere grandes conocimientos previos, su manejo es muy intuitivo y la simbología utilizada se ajusta con la teoría impartida en clase.

Por otro lado, soporta modelos jerárquicos y de relaciones múltiples, aspectos que casi ninguna otra aplicación del sector soporta, entre otras prestaciones ventajosas.

Al generar código SQL (ver figura 4), ciñéndose estrictamente al estándar, es compatible con casi todos los gestores de bases de datos actuales.

Además, ya que se distribuye con licencia GPL (General Public License), se espera que sea una herramienta útil y bien aceptada por la comunidad universitaria. Animamos a sus futuros usuarios a contribuir en la obtención de versiones mejoradas, más robustas y seguras de la aplicación.

Referencias

[1] Celma, Matilde, Casamayor, J. C., Mota, Laura. Bases de Datos Relacionales. Prentice Hall, 2003

[2] Date, C. J. Introducción a los sistemas de Bases de Datos. Prentice Hall, 2001

[3] Elmasri, Ramez A., Navathe, Shamkant B. Fundamentos de Sistemas de Bases de Datos. Addison Wesley, 2002

[4] Groff, James R., Weinberg, Paul N. SQL: Manual de Referencia. Mc-Graw Hill, 2003

[5] Hansen, Gary W., Hansen, James V. Diseño y administración de Bases de Datos. Prentice Hall, 2000

[6] Harrington, Jan L. Relational database design. Morgan Kaufmann Publishers, 2002

[7] Kendall, Kenneth, Kendall, Julie. Análisis y Diseño De Sistemas. Prentice Hall, 1997

[8] Ullman, Jeffrey D., Widom, Jennifer. Introducción a los sistemas de Bases de Datos. Pearson, 1999

[9] http://eupt2.unizar.es/bd1. Apuntes de la asignatura Base de Datos I

[10] http://eupt2.unizar.es/bd2. Apuntes de la asignatura Base de Datos II

[11] http://dereditor.sourceforge.net. Página web de DerEditor.

[12] http://www.fabforce.net/dbdesigner4. Página web de DBDesigner 4.0.

[13] http://www.datanamic.com. Página web de DeZign for Databases 3.

[14] http://Java.sun.com. Página web de Java de Sun Microsystems.

[15] http://www.jgraph.com. Página web de JGraph.

[16] http://www.xcase.com. Página web de xCase Database Design.