VIII Jornadas de Enseñanza Universitaria de la Informática Cáceres ...

esquemas y privilegios en función del tipo decontenidos. En el apartado 3 describiremos laaproximación basada en versiones de tablas,adecuada para prácticas guiadas. En el apartado 4,describiremos los puntos más notables de unaimplementación real en PostgreSQL de laaproximación basada en versiones de tablas.Finalmente, en el apartado 5 se comentarán lasconclusiones y trabajos futuros.2. Planteamiento del Esquema de Base deDatos y Permisos en función de losContenidosLos contenidos posibles de SQL interactivo en unaasignatura introductoria a las Bases de Datosdeben de cubrir el DML por completo, y el DDL anivel de definición de tablas y vistas. Laexperimentación con concurrencia y con vistasactualizables también debe de estar amparada. Eneste apartado mostraremos cómo plantear losesquemas y privilegios de la base de datos paracada uno de estos contenidos.2.1. Las Consultas SELECTLa configuración más habitual para una prácticaguiada sobre consultas SELECT es hacer quetodos los alumnos compartan las tablas delprofesor, desde un usuario distinto de forma quelos alumnos no puedan modificar su contenido,sino que tan solo puedan consultarlo. Las tablasdel profesor tendrían únicamente permiso delectura para los usuarios alumnos. Los alumnospodrían acceder perfectamente desde un únicousuario del sistema para facilitar el mantenimiento.Este usuario alumno no necesitaría privilegios quele permitiesen crear objetos de la base de datoscomo tablas o vistas. En esta situación el alumnopuede experimentar consultas con las tablas delprofesor:1 Sin temor a que el alumno cree algún tipo deproblema por excederse en la ocupación dedisco, pues no puede crear tablas, ni modificarlas del profesor.2 Sin temor a que bloquee las operaciones deotros compañeros, pues todos estánaccediendo en modo consulta.3 El profesor puede cambiar la extensión de lastablas sobre la marcha para conseguir efectosparticulares en las consultas (introducirvalores nulos para ver comportamientosatípicos etc …) teniendo la certeza de queesos efectos son inmediatamente visibles atodos los alumnos. Dado que los alumnos y elprofesor acceden a los mismos datos, esconveniente que el sistema admita relajar elcontrol de la concurrencia de forma que en lamisma transacción del alumno se puedanobtener distintas lecturas de las tablas delprofesor, las cuales pueden ir cambiando poracción de transacciones cometidas de éste.Este nivel de concurrencia relajado es elconocido como Read Commited en el estándarSQL/ISO[6]. Esta configuración vieneactivada por defecto en algunos sistemascomo Oracle. Otra solución posible al mismoproblema, es que los alumnos tengan activadala opción de autocommit, habitual en casitodos los sistemas, de forma que cada una desus consultas sea una transacción en sí misma.Desde el punto de vista estético, esteplanteamiento puede resultar feo en sistemas comoOracle [5] que tienen un espacio de nombre detablas distinto para cada usuario. Esto obliga a queel alumno para referenciar a la tabla X del usuarioprofesor, tenga que escribir profesor.X. Esteproblema puede ocultarse definiendo una vista 4con el mismo nombre que la tabla (X) en elalumno (CREATE VIEW X AS SELECT *FROM Profesor.X).Desde el punto de vista funcional, el principalinconveniente de esta aproximación, es que elalumno no puede experimentar por si sólo,creando sus propios casos (crear sus propiastablas, modificar la extensiones de las tablasexistentes) para ver cómo varían las respuestas auna misma consulta.Esta aproximación sólo es válida para cuandoel profesor explica sin que el alumno participe, y –aparentemente- para la clase de prácticas guiada.Nótese que si en una clase guiada el profesor, en4 O bien un sinónimo (SYNONYM) de la tabla delprofesor en el usuario alumno en el caso de aquellossistemas que dispongan de este tipo de objetos, como porejemplo Oracle [5].