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

de Borrado y en la de Actualización (ver másadelante) por los triggers.Otra observación interesante es que vdel comotabla, ya tiene su propio OID, por ello es necesarioque su único campo, que contiene los OIDs de lasfilas borradas/modificadas, tenga un nombredistinto de OID. En nuestro cado hemos elegidocomo nombre DOID, que también se utiliza en lasReglas de Borrado y Actualización.Regla de actualización:Implementa los Casos 3 y 5 del apartadoanterior.CREATE RULE versionClientes_upd ASON UPDATE TO versionClientesDO INSTEAD(//Caso 3INSERT INTO vadd_CLIENTES(CIF, nombre, telefono)select NEW.CIF, NEW.nombre, etc…FROM ClientesWHERE old._OID = Clientes.OID;INSERT INTO vdel_Clientes(DOID)SELECT oid FROM ClientesWHERE old._oid = Clientes.oid;//Caso 5UPDATE vadd_ClientesSET CIF=NEW.CIF, nombre=NEW.nombre,telefono=NEW.telefonoWHERE vadd_Clientes.oid=OLD._oid;);Ilustración 4. Regla de ActualizaciónLa implementación mostrada sólo concierne auna de las tablas y a uno de los usuarios. Para queel entorno sea eficaz, deberá de crearautomáticamente las vistas y triggerscorrespondientes para cada alumno y versión detabla del profesor. Este proceso se puedeautomatizar a través de scripts del sistemaoperativo que consulten el catálogo de la base dedatos del profesor. Estos scripts se ejecutarían aldar de alta a cada usuario alumno, al principio delcurso.Así, para una tabla Clientes del profesor, estescript crearía automáticamente la versiónClientes_1 al dar de alta al alumno 1, Clientes_2 aldar de alta el alumno 2, etc… De esta forma elalumno n puede disponer de la versión delprofesor –Clientes- y de la suya propia –Clientes_n.Un problema que hemos pasado por alto es elde las restricciones. En principio, parece que paraque las versiones tengan las mismas restriccionesque sus tablas base, basta con volver a declarardichas restricciones en vadd. Sin embargo, esto noes así para las restricciones SQL de PRIMARYKEY, UNIQUE y FOREIGN KEY. Las clavesprimarias y candidatas han de mantener suunicidad no sólo en la tabla base y en vadd porseparado, sino que deben tener valores únicos parala unión de las extensiones de ambas tablas. Conlas claves foráneas ocurre lo mismo. Si porejemplo una fila de la tabla Pedidos referencia a latabla Clientes, no basta con declarar quevadd_Pedidos referencie a vadd_Clientes, puesdebe poder referenciar además a un cliente de latabla base Cientes.La solución a estos problemas es controlar lasviolaciones de estas restricciones, nuevamente através de triggers declarados, en esta ocasión,sobre eventos en vadd. En el caso de las clavesforáneas los triggers controlaran que lasinserciones y modificaciones de Pedidos y laseliminaciones de Clientes no dejan a los pedidossin cliente asociado. Esta implementaciónmediante triggers es muy flexible, permitiendoimplementar distintas semánticas (rechazos,acciones en cascada etc.). En el caso de las clavesprimarias y candidatas, los triggers controlaránque las inserciones y modificaciones de la clave envadd no generen duplicados.Todos estos triggers también pueden sercreados directamente en el script de creación deusuario. Aunque las malas noticias son que todosestos controles por trigger acaban por degradar elrendimiento del sistema, las buenas noticias sonque con el escaso número de filas que suelen tenerlas bases de datos de docencia, este efecto no esapreciable.Parte de la materia de SQL interactivo, es eltrabajo con vistas actualizables. Un problema de laversión actual de PostgreSQL es que las vistas quedefinan los alumnos no son actualizables, a no serque se especifiquen vía triggers, las accionesasociadas a la propagación de las modificacionessobre la vista a las tablas base. Sin embargo, este