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,
galvez@lcc.uma.es
http://www.uma.es
2 EU de Turismo, Univ. de Málaga, España,

<jlcaro, Guevara, aguayo>@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 Número
Características
Habitaciones

Nombre
Apellidos
NIF Código
Dirección 1..n 0..n Nombre
Teléfono
Clientes Estancia Hoteles Dirección
Localidad
País
Cupo
Precio simple
Precio doble
0..n Precio Recargo temporada

0..n Nombre
Cobros Servicios 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 n m

m m

m
Campañas m Clientes 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 pseudo-
asistentes 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/