Dos nuevas Tablas: wiki_evaluation y wiki_evaluation_edition

Aún tengo que solucionar algunos problemas técnicos que tengo con Moodle 1.9 y Nwiki, mientras, sigo trabajando en Moodle 1.8.

Mi primer idea es crear dos nuevas tablas auxiliares que sirvan para valorar páginas wiki y versiones de una misma página wiki.

Para la primera parte, evaluar páginas wiki, la llamaré wiki_evaluation, y será una tabla nueva que relacionará la tabla usuario, páginas wiki y notas (grades). Aparte de relacionar dichas tablas también servirá para almacenar un comentario y la nota (gradesid). En caso de que se modifiqué repetidas veces una nota, siempre podremos recuperar la nota inicial o las sucesivas a partir de los historiales de las tablas de grades (history tables, que básicamente tienen los mismos campos más tres extra). Todas las tablas de se utilizan para gestionar los grades posen su respectiva tabla historial y con ella se pude reconstruir las notas en cualquier punto en el tiempo.

Destacar, que para asociar una página wiki (wiki_pages) con la tabla wiki_evaluation, utilizaré en vez del identificador de la página wiki (id), los cuatro campos principales para diferenciar páginas wiki, estos son pagename (nombre de la página wiki), dfwiki (a que wiki pertenece), ownerid (el propietario de la página wiki) y groupid (grupo al que pertenece). Creo que para evitar constantemente que la relación entre las páginas wiki y las evaluaciones tengan que actualizarse siempre que se modifica una página wiki, es decir, se añade una nueva versión, es coger estos cuatro campos. Si solo utilizaremos el campo id de la tabla wiki_pages, estaríamos valorando versiones en vez de la página wiki y si buscáramos que la nota fuera a parar a la última versión disponible, tendríamos que actualizar al nuevo valor del campo id de wiki_pages.

La estructura en UML sería la siguiente (no confundir con el condensador de flujo...XD):

En sql:

CREATE TABLE mdl_wiki_evaluation
(
id BIGINT(10) unsigned NOT NULL auto_increment,
pagename VARCHAR(160) NOT NULL DEFAULT '',
wikiid* BIGINT(10) unsigned NOT NULL DEFAULT 0,
groupid BIGINT(10) unsigned NOT NULL DEFAULT 0,
ownerid BIGINT(10) unsigned NOT NULL DEFAULT 0,
userid BIGINT(10) unsigned NOT NULL DEFAULT 0,
gradeid BIGINT(10) unsigned NOT NULL,
comment MEDIUMTEXT,

PRIMARY KEY (id),
UNIQUE (pagename, wikiid, groupid, ownerid,
userid, gradeid),
FOREIGN KEY (wikiid) REFERENCES wiki(id),
FOREIGN KEY (userid) REFERENCES user(id),
FOREIGN KEY (gradeid) REFERENCES grade_grades(id)
);

* Más conocido como Dfwiki, pero para ahorrar cambios y mantenimiento en el código, he preferido nombrarlo así.


Para evaluar las versiones de las páginas wiki, habrá una nueva tabla con el nombre de wiki_evaluation_edition. A diferencia de la anterior, hay que destacar que será una clase asociativa propiamente dicha. Esto implica que el identificador esta vez si será el identificador de la página wiki, que representa la edición que vamos a evaluar. Por lo tanto la nueva tabla que añadiremos a la base de datos estará compuesta por el identificador del usuarios, de la página wiki y el del la respectiva nota. Además almacenará los caracteres +, - o = dependiendo de la valoración del usuario respecto a la versión.

La estructura en UML sería la siguiente:

En sql:

CREATE TABLE wiki_evaluation_edition
(
id BIGINT(10) unsigned NOT NULL auto_increment,
wiki_pageid BIGINT(10) unsigned NOT NULL,
userid BIGINT(10) unsigned NOT NULL DEFAULT 0,
gradeid BIGINT(10) unsigned NOT NULL,
valoration VARCHAR(10) NOT NULL DEFAULT '',

PRIMARY KEY(id),
UNIQUE (wiki_pageid, userid, gradeid) **
FOREIGN KEY (wiki_pageid) REFERENCES wiki_page(id),
FOREIGN KEY (userid) REFERENCES user(id),
FOREIGN KEY (gradeid) REFERENCES grade_grades(id)
);

** Deviation from SQL standards: A FOREIGN KEY constraint that references a non-UNIQUE key is not standard SQL. It is an InnoDB extension to standard SQL. (http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html)

Aunque, nuestra idea inicial es crear una clase asociativa en Moodle, en realidad, a efectos prácticos no podremos realizar dicho concepto. Esto se debe a que las nuevas tablas de Moodle que incorporemos, deben de reunir unos requisitos mínimos. Algunos de estos requisitos son, que todas las tabla nuevas deberán de tener como clave primaria un identificador numérico autoincremental, este hecho rompe el concepto de clase asociativa, ya que una clases asociativa, su clave primaria se compone de las claves primarias de la relación de las demás clases. La solución es crear la tabla con el identificador y posteriormente crear nuestra clave única para evitar repeticiones no deseadas.