Mirá, técnicamente hablando, la cosa es extremadamente simple:
En un trigger sólo hay parámetros de entrada, y todos los parámetros son los campos del registro que se inserta, se modifica o se borra. Pero no se puede acceder a ellos en forma directa sino a través de una o dos estructuras propias de los TRIGGER. Estas estructuras son dos pseudovariables NEW (INSERT y UPDATE) y OLD (UPDATE y DELETE).
El NEW es un especie de "puntero" hacia el bloque de un registro entrante, sea nuevo como en el INSERT o actualizando como el UPDATE. En ambos casos, si alguno de los campos no está siendo enviado por la sentencia, su valor de entrada es NULL (las restricciones de NOT NULL operan diferente en los distintos DBMS).
El OLD apunta al registro que ya existe y que se está accediendo, pero dependiendo de su situación, ese registro puede ser de lectura/escritura o de sólo lectura.
¿De qué depende?
De si en TRIGGER es AFTER o BEFORE.
En otras palabras, un registro accedido por OLD no puede modificarse en un AFTER, porque para ese momento la inserción o actualización ya terminaron, ergo, es de sólo lectura.
¿Se entiende la lógica?
Entonces, para tu caso hay algunos detalles a cumplir:
1) El TRIGGER es BEFORE UPDATE.
2) Los valores a sumar o restar provienen de campos apuntados por NEW.
3) El campo a actualizar se apunta por OLD.
3)
El UPDATE no debe incluir el campo a actualizar.
El código, en general contendría algo como:
Código SQL:
Ver originalSET OLD.camposuma = OLD.camposuma + NEW.campo_a_sumar;
Nota final:
Realmente me asombra que un profesor haya pedido para un modelo dado un campo calculable. En las clases de BBDD I que cursé, ese ejercicio hubiera debido ser respondido como
"El ejercicio no se puede resolver, porque no deben existir campos calculables."
Si el profesor Vinjoy hubiese encontrado un alumno que escribiera el código que te piden, ese alumno hubiese reprobado sin necesidad de seguir leyendo el examen... Por lo menos, porque significaría que ni prestó atención en clase.