Un Modelo Conceptual para Aprender Bases de Datos Gálvez-Rojas S. 1, Caro-Herrero J.L.2, Guevara-Plaza A. 2, Aguayo-Maldonado A. 2 1

ETSI Informática, Univ. de Málaga, España, UNED. C.A. de Málaga, España, [email protected] http://www.uma.es 2 EU de Turismo, Univ. de Málaga, España, @lcc.uma.es

Resumen. La docencia sobre modelado de bases de datos suele basarse en la utilización de modelos conceptuales, de los que el Entidad/Relación (E/R) es el más extendido. Sin embargo, la evolución de los Sistemas Gestores de Bases de Datos (SGBD) hacía filosofías casi exclusivamente relacionales hace que los modelos construidos en base al E/R (de más alto nivel) acaben fuertemente sesgados fusionándose sus conceptos con los de los esquemas relacionales. El presente trabajo aporta un modelo de alto nivel nuevo, basado en formularios electrónicos (llamados diseños) que se alejan de las estructuras basadas en tablas propias del modelo relacional. Con ello conseguimos, por una parte, suministrar a los alumnos menos experimentados de un mecanismo de modelado adaptado a su mentalidad, al utilizar conceptos tan simples como: formularios, campos y líneas de detalle. Y por otro lado, se evita el mencionado sesgo durante la fase de diseño conceptual de una base de datos. El modelo propuesto se apoya en una definición formal (MSF-Modelo Semántico de Formularios), en una implementación práctica (SGF-Sistema Gestor de Formularios) y en una interfaz gráfica (CBD-CASE Bases de Datos), lo que permite a los usuarios-diseñadores describir los formularios en el ordenador y ponerlos a prueba en una fase de prototipado.

1 Introducción Las bases de datos relacionales o basadas en tablas copan la práctica totalidad del panorama internacional en lo que a software de gestión se refiere (más del 85% de la cuota de mercado se reparte entre Oracle, DB2 de IBM y SQL Server de Microsoft) [7]. El aprendizaje de cómo gestionar bases de datos ha sido una tarea que ha sufrido, en esencia, poca evolución en las dos últimas décadas, ya que a finales de los 70 el modelo teórico relacional estándar se encontraba plenamente estabilizado y contaba ya con algunas implementaciones importantes. Pero esta estabilización del modelo no implica una fácil asimilación por parte de aquéllos que se intentan adentrar en sus entresijos, ya sea en estudios universitarios, secundarios o en enseñanzas no regladas. Los que alguna vez han impartido docencia sobre algún paquete ofimático saben que resulta mucho más fácil para un alumno desenvolverse con una hoja de cálculo que con una tabla de una base de datos.

Esta situación obliga a los docentes a trabajar con una dualidad enfrentada; de un lado un sistema ineludible de almacenamiento masivo de datos basado en tablas y completamente establecido; de otro lado, una complejidad conceptual difícil de superar para los no iniciados. Desde el grupo SICUMA (Sistemas de Información Cooperativos de la Univ. de Málaga; TIC-160 de la Junta de Andalucía, España) presentamos en este trabajo una aproximación pedagógica que permite, a los alumnos de cursos introductorios, asimilar los conceptos preliminares propios de bases de datos. Para dejar clara la importancia de la visión aportada, se introduce en el apartado 2 los métodos más extendidos para el aprendizaje de los fundamentos de bases de datos relacionales, y se discuten sus ventajas e inconvenientes. También se aborda brevemente el ejemplo que utilizaremos a lo largo de toda la exposición. El apartado 3 explica los fundamentos del modelo que se propone, tanto desde el punto de vista teórico como práctico, así como las herramientas desarrolladas para fomentar el interés de los alumnos. Por último, el punto 4 expone nuestras experiencias en la aplicación de este sistema en distintos entornos docentes, y algunas ventajas colaterales que su empleo ha demostrado. Finalmente en el apartado 5 se resumen las principales conclusiones y las próximas líneas de investigación de nuestro equipo.

2 Enseñanza tradicional de bases de datos Ya en el famoso artículo de Peter Chen en 1976 [1] puede apreciarse un leve sesgo hacia el modelo de tablas, cuando propone el modelo E/R (Entidad/Relación) como mecanismo de unificación de los modelos de bases de datos más extendidos de la época: relacional, jerárquico y en red. Y es que la orientación del mercado se veía venir desde hacía ya varios años y el potencial de un modelo basado en tablas ya era, de por sí, lo suficientemente general como para aglutinar a los otros dos de manera elegante y eficiente. Hoy día, el modelo E/R es el más utilizado para abstraer las necesidades de datos en el análisis de un sistema de información, y la idea es que sea totalmente independiente de cualquier implementación. A pesar de que la mayoría de cursos y asignaturas que versan sobre bases de datos incluyen uno o varios temas dedicados al diseño conceptual -esto es, desde un punto de vista abstracto y al margen de una base de datos concreta- tarde o temprano confluyen en un modelo relacional que permita poner en práctica las necesidades de datos propuestas en ejercicios y enunciados más o menos reales. La verdadera necesidad de un modelo conceptual, como el ampliamente extendido E/R, completamente independiente de uno lógico -podemos llamar así al modelo relacional- sólo puede percibirse con la experiencia, lo que hace que los alumnos nunca lleguen a comprender su necesidad vital pues no se han enfrentado con situaciones reales de suficiente envergadura como para echarlo de menos. En ocasiones esto mismo les sucede a los propios docentes, quienes abordan el modelo E/R desde una perspectiva sesgada y fuera de contexto, acercándola peligrosamente al modelo relacional, y desvirtuando su objetivo de ser, en esencia, una abstracción alejada de cualquier connotación de implementación. Este hecho se ve aumentado por la utilización de herramientas informáticas de diseño de modelos E/R, pero que han sido creadas, a su vez, por los mismos desarrolladores de los Sistemas Gestores de Bases de Datos Relacionales (SGBDR). En definitivas cuentas, se

trata de sucedáneos o “extensiones” del modelo E/R con una clara intención propagandística y “cercana” a su propuesta relacional. Y es que hay que reconocer que, a primera vista, resulta paradójico el emplear esfuerzo y tiempo de estudio en un modelo que va a acabar siendo implementado mediante un único mecanismo: las tablas. A pesar de ello, hoy por hoy, casi nadie discute sobre la necesidad de realizar una abstracción previa a la implementación del modelo de la realidad cuya información se desea guardar en una base de datos. Sí cabe más discusión, sin embargo, sobre la forma de construir las tablas del modelo relacional destinadas a almacenar los datos reales. Básicamente puede hablarse de dos aproximaciones: ascendente y descendente. La ascendente consiste en producir una lista de campos sobre los que se desea almacenar información -a la que se llama diccionario de datos- y agruparlos de manera consistente mediante dependencias funcionales. Obviamente, este mecanismo es inviable ante casos prácticos de cierta envergadura y sólo suele usarse en los inicios del aprendizaje. Un mecanismo parecido a este también puede utilizarse para obtener el modelo E/R en lugar de las tablas. La descendente requiere un mayor control de las características del modelo relacional. Con una visión global del dominio del problema que se pretende modelar, consiste en realizar agrupaciones preliminares de los datos en tablas y, posteriormente mediante refinamientos sucesivos, asegurar que las distintas relaciones entre los datos se cumplen mediante las adecuadas restricciones. Si se parte de un modelo E/R esta fase no resulta demasiado complicada de abordar. De la explicación anterior se desprende que lo verdaderamente complicado en el diseño de bases de datos es la creación de un modelo E/R que de una visión de conjunto de los datos. Y es que construir, e incluso sólo validar, un diagrama E/R resulta demasiado abstracto para quien carece de una formación sobre la importancia de estos modelos. La figura 1 ilustra un ejemplo de estos diagramas. En él se ha modelado parte del sistema de información de un Hotel. Los rectángulos representan las entidades de las que se quieren guardar datos, y los rombos establecen relaciones entre ellas. Bajo ciertas circunstancias, una relación puede hacer las veces de entidad (un rombo inscrito en un rectángulo) con objeto de relacionarse, a su vez, con otras entidades; es lo que se llama una reinterpretación. Los rectángulos pequeños constituyen los datos que se desean almacenar sobre cada entidad. 0..n

Nombre Apellidos NIF Dirección Teléfono

Clientes

1..n

0..n

Estancia 0..n

Cobros

Habitaciones

Hoteles

Precio

0..n

Servicios

Número Características

Código Nombre Dirección Localidad País Cupo Precio simple Precio doble Recargo temporada

Nombre Precio

Fig. 1. Impacto visual de las abstracciones empleadas en un diagrama E/R de ejemplo

2.1 El modelo de objetos semánticos Conscientes de esta situación, algunos autores han propuesto modelos conceptuales pedagógicos radicalmente distintos al E/R ([11, 8, 10]). De entre estos podemos destacar al Modelo de Objetos Semánticos (MOS), verdadero centro neurálgico en el diseño de bases de datos del libro de texto de Kroenke [8] y que está traducido al español. Este modelo tiene una concepción centrada en el alumno y reduce sensiblemente la complejidad de la notación, aún a costa de disminuir su potencia expresiva. El modelo se basa en entidades (objetos con semántica propia) que poseen información y que pueden estar relacionados con otras entidades. En función del tipo de relación, los objetos semánticos se clasifican en simples, compuestos, combinados, híbridos, de asociación, padre/subtipo, etc. en base a ciertos conceptos sumamente claros. Pero lo que hace de MOS un modelo comprensible es la existencia de una herramienta de apoyo llamada Tabledesigner y que permite que el diseño conceptual de bases de datos sea algo así como “coser y cantar”, (las primeras versiones de Tabledesigner se llamaron “Salsa”). Esta herramienta posee una gran cantidad de componentes de uso muy extendido y que el usuario puede reutilizar en sus propios diseños. Esta reutilización en las fases más tempranas del diseño (y del aprendizaje), hace que el alumno/usuario se centre exclusivamente en los aspectos propios de dicha labor, y que no se pierda en un mar de detalles insignificantes. Además, el tener una herramienta electrónica de apoyo facilita la corrección de los modelos mucho más que si se tienen en papel. La figura 2 ilustra parte del diseño del sistema de información de un Hotel modelado mediante diagramas MOS. Por desgracia este modelo no se encuentra ampliamente extendido dado que el E/R, pese a sus carencias pedagógicas, se encuentra infinitamente más afianzado en el mercado, tanto docente como de producción empresarial.

Fig. 2. Apariencia de Tabledesigner, en el que pueden apreciarse los objetos semánticos y la paleta de campos predefinidos que permite seleccionar y crear nuevos componentes

3 El modelo de formularios Somos conscientes de que proponer un nuevo modelo conceptual, por muy bueno que sea, está condenado al fracaso debido a la arrolladora inercia de la maquinaria ya establecida: el modelo E/R. Por ello, no trataremos de sustituir a éste en aquellos entornos donde ya ha echado raíces, pero sí en aquellos lugares en donde se muestra incapaz de establecerse: la docencia de bases de datos para alumnos no especialistas en informática. Nuestra idea surgió en una asignatura de bases de datos de la Diplomatura de Turismo en la Universidad de Málaga. Es una asignatura orientada a alumnos no especialistas que, a pesar de ello, quieren profundizar en sus estudios de informática aplicada en el campo de las bases de datos. Inicialmente se diseñó un programa que introducía levemente el modelo E/R; el resultado fue poco exitoso: la mayoría de los alumnos no sólo no comprendían sus fundamentos sino, mucho menos, su necesidad, y los diseños eran verdaderamente arbitrarios. Sin embargo, observamos que los diseños de tablas que los alumnos creaban eran más cercanos a lo que se pretendía modelar. O sea, los alumnos ignoraban sistemáticamente el modelo E/R a la hora de producir las tablas finales, y comprendían mejor el modelo relacional si se olvidaban del E/R. Finalmente se concluyó que este hecho se debía a dos motivos principales: • El tamaño de los problemas propuestos era lo suficientemente pequeño como para abarcar globalmente la comprensión de las tablas construidas. A medida que los problemas se hacían más grandes, los errores del modelo relacional se acercaban a los desbarros cometidos en el E/R. • El modelo E/R se diseñaba exclusivamente en papel, mientras que el modelo relacional se implantaba realmente mediante un SGBDR real (en nuestro caso Access), lo que les permitía realizar comprobaciones y correcciones del modelo. Nuestro objetivo se centró en obtener un mecanismo por el cual los alumnos fueran capaces de producir modelos viables ante problemas más grandes y para ello era evidente que se les debía suministrar alguna herramienta electrónica con una potente interfaz gráfica que les permitiese interaccionar y validar dichos modelos. La solución fue construir un modelo que no se basa en entidades ni en objetos, como el E/R o el MOS, sino en el elemento más extendido en cualquier sistema de información: el documento o formulario. Así surgió el modelo semántico de formularios: MSF. 3.1 Fundamentos No nos centraremos en este epígrafe en los fundamentos teóricos y formales que subyacen al modelo SMF, lo que superaría con creces el espacio de que disponemos (en [4] puede encontrarse el estudio completo), sino que nos centraremos sólo en las características que posee de cara al usuario/alumno que lo va a utilizar. Como modelo, MSF se centra en el concepto de diseño. Un diseño no es más que un tipo de formularios, o sea, un formulario vacío con huecos por rellenar. Como otros autores ya han propuesto [9], un diseño tiene una estructura jerárquica, ya que puede contener tanto campos planos como líneas de detalles que, a su vez, también tienen estructura de diseño. El aspecto más interesante que se propone en MSF es la compartición de datos, que consiste sencillamente en no tener que repetir campos en distintos diseños, sino escribirlos en un

diseño principal y “copiarlos” en todos los diseños en los que deba aparecer. Por ejemplo, dado que en una Factura aparecen los datos de un Cliente, no tiene sentido tener que reescribir estos datos en la Factura, sino que se pueden copiar desde una ficha de Clientes. Pero no se trata de un simple copy&paste (copiar y pegar). Nuestro modelo interpreta estas “copias” de datos como referencias a los datos originales, estableciéndose de esta forma las interrelaciones propias del modelo relacional. Con un mecanismo tan sencillo como son los diseños jerárquicos y la interconexión de datos es posible obtener en formato electrónico cualquier formulario en papel propio de un Sistema de Información. Téngase en cuenta que es posible insertar referencias a datos incluso dentro de las líneas de detalles, con lo que la combinación de estos dos mecanismos es sumamente rica desde el punto de vista de la expresividad. Finalmente, aunque MSF incorpora el concepto de relación en toda su envergadura, desde el punto de vista del que hace el diseño, sólo habrá de utilizar (y en raras ocasiones), el concepto de nombre de relación. Un ejemplo de esta situación aparece cuando, siguiendo con el caso de las Facturas y los Clientes, se desea que el formulario de un Cliente contenga una lista con todos los números de Facturas y el importe de cada una de ellas. Nótese la existencia de una relación cruzada que debe tener el mismo nombre: una Factura contiene datos de Clientes y un Cliente tiene datos de Facturas. Dado que lo que tenemos entre manos es un modelo conceptual (y no un oráculo), de alguna manera es necesario indicar que se trata de los mismos datos cruzados, y no de datos distintos (lo que podría suceder si, por ejemplo, se quisiera que en el formulario de Clientes sólo apareciesen determinadas Facturas y no todas, como puedan ser tan sólo las pendientes de pago). Facturas

Hoteles m

m Campañas

m

Clientes

n m

m m

Servicios

Fig. 3. Ejemplo de diagrama Formulario/Relación en el que puede apreciarse la utilización de secciones de círculo coloreadas para facilitar su comprensión. Este tipo de diagrama no contempla los atributos de cada diseño, que son enumerados en un catálogo aparte. El área sombreada se corresponde con el diagrama E/R de la figura 1, excepto porque aquí no han sido modeladas las Habitaciones

La idea es que mediante un mecanismo sistemático, que parte de los diseños, se obtengan diagramas similares a los E/R y a partir de estos se generen las tablas del modelo relacional. En la figura 3 puede verse uno de estos diagramas que, al igual que la figura 1, modela parte del sistema de información de un Hotel. En estos diagramas se han sustituido los rombos propios del E/R por círculos seccionados en colores, que también representan relaciones. Cada diseño construido posee un color distinto, y constituye una entidad que se representa por un rectángulo, al igual que en el E/R. Se asume que cuando una entidad se conecta con

un círculo, le transfiere su color. El color de las líneas que conectan un diseño con una relación se asigna en función de los datos que dicho diseño contenga de otros diseños. Por ejemplo, si Servicios es azul, Hoteles es rosa, y el diseño de Servicios contiene datos de Hoteles, entonces la conexión entre Servicios y su relación con Hoteles es rosa. Un ejemplo parecido, pero más desarrollado que éste puede encontrarse en [5]. Para poder poner todo esto en práctica es necesaria una herramienta que facilite a los alumnos los cambios de diseño para observar cómo influyen en el comportamiento del modelo producido. 3.2 La interfaz gráfica No resulta nada fácil crear un modelo conceptual de la nada, formalizarlo adecuadamente, adaptarlo a las necesidades de usuarios poco experimentados y, además, dotarlo de una herramienta que permita trabajar electrónicamente con sus componentes. A pesar de ello, nuestro grupo ha creado una primera versión de interfaz gráfica (llamada CBD -herramienta CASE para el Diseño de Bases de Datos), en el marco de un proyecto más ambicioso de construcción de bases de datos mediante métodos cooperativos. Esta herramienta también se ha mostrado eficaz para el diseño conceptual de bases de datos en sistemas monousuario.

Fig. 4. Aspecto de la interfaz de diseños CBD

La figura 4 muestra el aspecto de CBD durante la creación de un diseño de Hoteles. Básicamente se trata de una interfaz desarrollada en Java para construir diseños de formularios, pero que incorpora la posibilidad de incluir líneas de detalles (llamadas grupos de repetición) y facilitar la compartición de datos mediante unos códigos de colores (permite asociar un color a cada diseño de manera que al copiar campos de un diseño a otro éstos mantengan su color y se sepa de dónde proceden). En la figura 4 los Clientes han sido coloreados en celeste.

Resulta fácil recapacitar en este punto sobre un hecho de fundamental importancia. En los sistemas tradicionales de bases de datos, primero se diseñan las tablas y luego los formularios. Lo que nosotros proponemos no es hacerlo al revés. Lo que aquí se propone es construir los formularios y ya está, puesto que el diseño de tablas se produce de manera automática siguiendo mecanismos de generación de diagramas conceptuales y, a partir de ellos, obteniéndose directamente las tablas. La interfaz que se presenta en la figura 4 es una de las varias propuestas que estamos barajando actualmente (puede consultarse [2, 3] para estudiar otras alternativas) pero resulta más que suficiente para los ejercicios y problemas típicos que un alumno no experimentado puede afrontar durante su vida profesional.

Fig. 5. La interfaz CBD en plena fase de pruebas

3.3 Prototipado CBD representa por sí sólo un importante salto en lo que se refiere a abstracción en el proceso de diseño, ya que acerca el modelo a la mentalidad del alumno/usuario, y no al revés. Sin embargo, dado que nuestro grupo de investigación ha formalizado matemáticamente a MSF, resulta posible establecer una correspondencia entre un conjunto de diseños y unas tablas del modelo relacional (con o sin un paso previo por diagramas intermedios). Esta traslación la realiza automáticamente un sistema Gestor de Formularios (SGF) quien, en conjunción con CBD, permite manipular los diseños introduciéndoles información real y convirtiéndolos realmente en formularios de pleno derecho. SGF también está desarrollado en Java, y se comunica con una base de datos relacional Oracle, encargada de almacenar la metainformación relativa a los diseños del usuario. Cuando un usuario da por concluido sus diseños puede pasar a la fase de pruebas (ver figura 5), en la que inserta datos reales y puede analizar si, efectivamente, el diseño que ha construido se adapta a sus necesidades de datos o no. Una vez realizadas las comprobaciones necesarias puede pasar de nuevo a la fase de diseño. Mediante

refinamientos sucesivos, el alumno aprende progresivamente a realizar diseños-prototipos cada vez más depurados, de manera que, ante cada nuevo supuesto práctico, el número de ciclos de refinamiento es menor. Como puede entenderse, SGF implementa la lógica del modelo, mientras que CBD realiza funciones de interfaz, por lo que es posible utilizar el modelo de formularios con múltiples interfaces, incluso adaptables a cada usuario y/o a cada tipo de problemas propuestos. A este respecto, SGF permite mantener un registro de las operaciones más realizadas por los alumnos, con el objetivo de poner a punto futuras funcionalidades de la interfaz. Por último, dado que SGF ignora cualquier característica estética de los diseños (colores, rótulos, posiciones de los campos, etc.), es necesario incluir una capa de presentación al nivel de la interfaz, representada por documentos XFA (XML Forms Architecture). CBD interconecta la capa de presentación XFA con la capa de datos que le suministra SGF y proporciona una visión concreta de los diseños al usuario.

4 Experiencias con los usuarios Las experiencias proporcionadas por este modelo varían enormemente en función del tipo de alumnos y/o profesionales a los que les es presentada. Básicamente nos centraremos en usuarios no especialistas, representados por los alumnos de la Diplomatura de Turismo antes mencionada, y alumnos de Informática en un curso de posgrado. Los diagramas Formulario/Relación mencionados en el apartado 3.1 han sido muy útiles durante el proceso de revisión y evaluación de la calidad de los resultados producidos por ambos tipos de usuarios. 4.1 Usuarios no especialistas Enfrentados a MSF, los alumnos no especialistas han mostrado un comportamiento muy diferente según dispusieran o no de CBD para expresar sus modelos. En otras palabras, cuando se les pedía construir un modelo de formularios con lápiz y papel, los resultados no diferían demasiado con respecto al modelo E/R. Este hecho resulta curioso, por cuanto lo que debían producir era, ni más ni menos, que los documentos preimpresos que habría que solicitar a una imprenta caso de no existir medios informáticos. Esto demuestra que, en las más de las ocasiones, el enunciado no se comprende si no se aplica a algo tangible. Por otro lado, enfrentados a CBD los resultados han sido mucho más satisfactorios, ya que el proceso de refinamiento les ha permitido dilucidar sin duda alguna qué es lo que se pretendía con cada enunciado y aplicar un mecanismo de resolución bien definido, como es que permite MSF. No obstante, la interfaz CBD actual ha demostrado ser excesivamente lenta e inadecuada ante casos prácticos de elevada complejidad (líneas de detalles dentro de líneas de detalles). En general, estos alumnos se encontraban mucho más satisfechos al final de la docencia.

4.2 Usuarios especialistas Resulta curiosa la tenaz resistencia de los alumnos que ya conocen el modelo E/R a adaptarse al modelo de formularios. Pero lo más insólito es que, a pesar de mantener su preferencia por el modelo E/R, ante supuestos prácticos para ser resueltos mediante dicho modelo, producen esquemas incorrectos y que no se ajustan a la filosofía E/R. No queremos decir con esto que las tablas relacionales resultantes las construyeran mal, sino que el esquema E/R que producen suele tener un sesgo evidente hacia el modelo de tablas. Todo esto evidencia que, después de todo, el modelo E/R ha sido desvirtuado por los profesionales del mañana. Para dejar claro los motivos de esta resistencia, este tipo de alumnos también fue aleccionado en otros modelos (como el ORM [6] o el MOS). A medida que el modelo es más parecido al E/R va obteniendo más simpatía por parte de los alumnos, lo que denota un sesgo por los conocimientos ya adquiridos. Es más, dado que siguen aplicando mal el propio modelo E/R, se evidencia que tampoco les queda clara la verdadera naturaleza y utilidad de un modelo conceptual, sea éste el que sea.

5 Conclusiones El hecho de que la práctica totalidad de los SGBD actuales sean relacionales ha desvirtuado la utilidad real de un modelo conceptual como el E/R. Numerosas “extensiones” a dicho modelo se desvían de su filosofía inicial y lo acercan a modelos relacionales concretos en función de los intereses particulares de cada fabricante. Ante este panorama desolador, los alumnos se encuentran desorientados por la utilización de un modelo que “parece no aportarles nada” produciendo esquemas sumamente sesgados hacia el modelo relacional actualmente imperante. En este trabajo hemos propuesto una idea radicalmente distinta, especialmente orientada a usuarios no especialistas, en el sentido de que el sistema de tablas subyacentes es generado de manera automática. Usuarios especialistas pueden utilizar dicho sistema de tablas como punto de partida para un refinamiento posterior desde el punto de vista de la eficiencia. No obstante, el aprendizaje previo del modelo E/R por parte de estos alumnos sesga profundamente su visión de lo que es una base de datos y les hace ser reticentes a utilizar cualquier otro modelo. Finalmente, en nuestros experimentos resulta curioso cómo muchos alumnos han afirmado que la herramienta CBD supera con creces las posibilidades a priori de otras herramientas como Access y que, si no fuera por la lentitud de respuesta al usuario y porque no es un sistema ni mucho menos extendido, optarían por su uso en detrimento de otras herramientas ofimáticas. Este hecho nos ha llamado mucho la atención por cuanto no era nuestra intención preliminar, y denota que muchos usuarios ni siquiera han atendido demasiado a que el objetivo principal era generar tablas de un modelo relacional mediante un modelo conceptual previo. La reflexión nos lleva a comprender esta idea: el objetivo de un usuario no especialista es almacenar información y recuperarla de forma organizada. Y CBD les da la oportunidad de hacerlo con poco esfuerzo y centrándose principalmente en el problema a tratar.

5.1 Trabajo futuro Las posibilidades que nos brinda CBD en el futuro son múltiples, especialmente por el camino abierto por los propios alumnos en lo referente a que CBD junto con SGF pudiera convertirse en un gestor más de bases de datos, a la altura de Access o Fox Pro (guardando las diferencias), pero con una interfaz claramente orientada al usuario. Actualmente nos encontramos en pleno desarrollo del sistema IGO (Interfaz Guiada por Objetivos), que pretende utilizar un mecanismo de aprendizaje rápido en base a pseudoasistentes no agresivos. En los primeros escarceos de un usuario con MSF se enfrentaría a una interfaz de tipo IGO, cuya vida útil sería muy corta. Una vez aprendidos los conceptos básicos, podría pasar directamente a trabajar con CBD. Este mecanismo podría disminuir la fase de formación previa que un usuario requiere sobre MSF. Por último, y para poder evaluar realmente hasta qué punto influye el conocimiento del modelo E/R en la opinión que los usuarios expertos tienen de CBD, resultaría interesante que éstos comenzasen su aprendizaje profesional con CBD y ver cómo evolucionan en asignaturas posteriores. Sin embargo, poner en práctica este experimento resulta sumamente complicado sin influir en la formación de los alumnos (probablemente de forma negativa, ya que el modelo E/R sigue siendo el modelo conceptual más extendido).

Referencias 1. Peter Pin-Shan Chen: “The E-R Model.Toward a Unified View of Data”. ACM Transactions on Database Systems. vol. 1, nº 1: pgs. 9-36. Marzo, 1976. 2. A.Carrillo, A.Guevara, S.Galvez, J.Falgueras:,” Análisis de tareas básicas en CBD: Herramienta orientada al usuario para el diseño cooperativo de bases de datos”. Actas del II Congreso Internacional de Interacción Persona-Ordenador, pgs. 261-272. Salamanca, 2001. 3. A.Carrillo, A.Guevara, S.Galvez, J.L. Caro: “Interacción Guiada por Objetivos”. Actas de INTERACCION 2002, pgs. 68-75. Leganés, 2002. 4. S. Gálvez: “Participación del usuario en el diseño cooperativo de bases de datos. Metodología y herramientas”. Tesis doctoral. Universidad de Málaga, 1999. 5. S.Galvez, A.Guevara, J.L. Caro, A.Aguayo: “Cooperative techniques and tools to increase the quality of the software in tourism companies”. Actas de Information and Communication Technologies in Tourism 2000, pgs. 178-188. Austria, 2000. 6. T.A. Halpin: “Object Role Modeling (ORM/NIAM)”. Handbook on Information Systems Architectures, Springer-Verlag. 1998. 7. IDC noticias. Marzo, 2003. http://www.noticiasdot.com/publicaciones/2003/ 0303/1404/noticias140403/noticias140403-20.htm 8. D.M. Kroenke: “Database Processing: Fundamentals, Design, and Implementation”. Prentice Hall. 2003. 9. P. Mogin, I. Lukovic: “A New Approach to Database Design”. International Journal of Industrial Systems, Novi Sad, Yugoslavia, vol. 1, nº 2, pgs. 59-68. Diciembre, 1999. 10. D. Moody: “Graphical Entity Relationship Models: Towards a More User Understandable Representation of Data”. LNCS Conceptual Modeling ER’96, pgs. 227-244. Eds. B. Thalheim.. 1996. 11 V. Ovchinnikov: “A Semantically Complete Conceptual Modeling Technique”. Journal of Conceptual Modelling, Mayo, 2004. http://www.inconcept.com/jcm/