Problema trigger

[thomas_2417]

BUENAS TARDES TENGO UN PROBLEMA CON UNA BASE DE DATOS... TENGO ESTAS 3 TABLAS:

Código SQL:

CREATE TABLE libros(
cod_libro INTEGER NOT NULL,
nombre VARCHAR(20)NOT NULL,
estado VARCHAR(20) NOT NULL,
CONSTRAINT PK_libros PRIMARY KEY (cod_libro)
);
 
CREATE TABLE PRESTAMOS(
codi_prestamo INTEGER NOT NULL,
codi_libro INTEGER  NOT NULL,
codi_alumno INTEGER NOT NULL,
FECHA_INICIO DATE DEFAULT SYSDATE,
FECHA_FIN DATE DEFAULT SYSDATE+3,
CONSTRAINT PK_prestam PRIMARY KEY (codi_prestamo),
CONSTRAINT fk_libro FOREIGN KEY (codi_libro) REFERENCES libros (cod_libro),
CONSTRAINT fk_alum FOREIGN KEY (codi_alumno) REFERENCES alumnos (cod_alumno)
);
 
CREATE TABLE DEVOLUCIONES(
codi_prestam INTEGER NOT NULL,
fec_fin DATE DEFAULT sysdate,
(codI_PRESTAMO)
);
 

YA HICE UN TRIGGER PARA QUE CADA VEZ QUE PRESTE UN LIBRO ME CAMBIEN EL ESTADO DE LA TABLA LIBROS A 'NO DISPONIBLES'. PERO EL PROBLEMA QUE TENGO ES QUE NO SE COMO HACER EL TRIGGER PARA QUE CADA VEZ QUE DEVUELVA EL LIBRO ME CAMBIEN EL ESTADO A DISPONIBLE NUEVAMENTE...
LES AGRADESCO QUE ME AYUDEN CON ESTA DUDA... LO NECESITO LO MAS PRONTO POSIBLE...

[Aoshy]

Hola Thomas tambien utilizo un campo estado el cual m sirve como FLAG o bandera para cambiar de estado '1' que significaria disponible, que es por defecto, a '0' no disponible

en mi opinión no utilizaría un trigger para realizar la actualización del campo estado prueba con esto:

El siguiente SP "actualiza_estado" realiza la actualización del estado de '1' a '0'

Código:

CREATE PROCEDURE `actualiza_estado`(OUT estado VARCHAR(20))
BEGIN
    UPDATE libros SET  estado =  '0' 
    WHERE  libros.cod_libro = '1';
END

CALL actualiza_estado(@a);

Recuerda que el estado por defecto es 1 que significa DISPONIBLE

[thomas_2417]

Aoshy me puedes decir en que gestor lo hiciste porq no me funciona en oracle... Se lo agradeceria...

[gnzsoloyo]

thomas_2417: ¿Te has dado cuenta que estás posteando en el Foro de MySQL, y que MySQL no es Oracle, sino que pertenece a la empresa Oracle.
No es la misma cosa.
Si estás trabajando en Oracle no deberías haber posteado en todos los Foros, sino que debiste especificar en cuál DBMS estabas trabajando.

Para tu mejor información: Las rutinas almacenadas (stored procedures, stored funcions, triggers, etc), no tienen un estándar, por lo que cada DBMS hace lo que quiere con su sintaxis. Tampoco las funciones nativas de cada versión de SQL son iguales, sino que cada uno le mete y le saca cosas como se les ocurre. Por ello los scripts no son portables.
Si bien existe un estándar de SQL, esto abarca las consultas y las estructuras generales, y no el PL/SQL.
Por tanto: ¿Vas a trabajar en Oracle o en MySQL?
En el primer caso, te reactivo el tema allá y lo enlazo con este thread. Sino, tu me dirás...

Saludos.

[thomas_2417]

Si claro reactivalo alla... Me avisa en cuanto lo reactiven...

[gnzsoloyo]

REstaurado y recombinado.

[gnzsoloyo]

En principio, yo te sugeriría que si es posible, modifiques un poco las tablas para hacer un sistema algo mas sencillo y eficiente.
Me explico: Según yo veo, hay un defecto conceptual que es lo que genera la necesidad de hacer ese trigger, pero que en realidad no deberías necesitar.
Si tienes una tabla prestamos, y cada préstamo a su vez sólo puede tener una unica devolución, entonces la devolución del prestamo es un atributo de la entidad Prestamo, yno necesita tener una tabla independiente para administralo.
En ese contexto, la tabla Préstamo debería tener un campo adicional de fecha_devolución con un valor por defecto NULL. De ese modo saber qué libros no han sido devueltos sólo requiere realizar un LEFT JOIN buscando los registros donde ese campo es NULL.
Pero además, también con ese contexto, tu problema podría ser que ni siquiera requiera la existencia ni del >TRIGGER y ni siquiera necesitaría el campo "estado", por cuando se puede definir como regla de negocio que para que un libro esté disponible, no debe tener un prestamo en devolución pendiente.
¿Se entiende la logica?
Con sólo agregar un campo, puedes darle al sistema la simplicidad y flexibilidad de poder responder a esas consultas sin ni siquiera crear el TRIGGER.
Yo creo que deberías considerarlo...

[thomas_2417]

Gazsoloyo gracias por la ayuda... Pero tengo un poco de dudas porque en la base de datos que tengo hasta ahora tenia la tabla de devoluciones aparte porque segun yo la devolucion no se haria al mismo tiempo que el prestamo entonces no se como haria para ingresar el o los datos de la fecha_devolucion que me sugieres como en principios lo ingresaria como null, como sabria que dia fue devuelto.. Gracias te agradeceria la ayuda nuevamente lo as pronto que puedas me urge...

[gnzsoloyo]

como sabria que dia fue devuelto

Miralo como una especificación de caso de uso, de este modo:

1) El actor una devolución (en la aplicación).
2) El sistema recupera la lista de pendientes de devolución, en un listado que contiene:
- ID de prestamo (no necesita ser visible en pantalla)
- ID de libro
- Nombre de la obra.
- Fecha del prestamo.
- Fecha de retorno esperada.
3) El actor selecciona el libro que está siendo devuelto.
4) El sistema muestra los datos del préstamo de esa obra.
5) El actor indica "Devuelto".
6) El sistema registra en la tabla Préstamo la fecha actual en el campo "fecha_devolucion", realizando el UPDATE en base al ID del préstamo en la tabla.
7) Termina el caso de uso.

Con solo esa columna hay mucha información adicional que puedes obtener:
- Si ha superado o no los días máximos de préstamo (que te sugiero que sean configurables y no fijos).
- Si amerita sanciones (por acumulación de retrasos).
- Si ha ganado preferencias o beneficios por cumplimiento.
- Puedes estimar (por el tipo de libro), la media de cuando lo devolverá.
- Puedes determinar qué tipo de libros lleva más y tarda mas en devolver, definiendo esquema de preferencias del alumno.
Y como esa, muchísima información más...

tenia la tabla de devoluciones aparte porque segun yo la devolucion no se haria al mismo tiempo que el prestamo

Eso es totalmente irrelevante. Jamás se puede producir un conflicto, porque para que haya una devolución, debe haber primero un préstamo. Si usas DATETIME en lugar de DATE incluso puedes validar que la devolución no pueda realizarse ni siquiera en una hora anterior a la entrada del préstamo. Y de todos modos, si la relación es 1:1... y siempre habrá una devolución de un único préstamo, es un atributo de la entidad y no una entidad independiente.
Por otro lado, como la planteas puede terminar existiendo más de una devolución para un mismo préstamo:

Código SQL:

CREATE TABLE DEVOLUCIONES(
codi_prestam INTEGER NOT NULL,
fec_fin DATE DEFAULT sysdate,
(codI_PRESTAMO)
);
 

Si ver la tabla, no has puesto una relación de tipo UNIQUE en ella, que sería necesario para que una única devolución se relacione con un único préstamo, y ni siquiera una dependencia funcional, ya que no tienes FK definidas.
A mi entender, esa tabla es superflua si sólo agregas la columna que te sugiero.

[thomas_2417]

Muchas gracias ya solucione mis dudas... Muy buen explicacion...

[thomas_2417]

Disculpa me salio otro pequeñisimo problema en la base datos como ya dije de anticipacion estaba utilizando el campo estado de "disponible" y "no disponible" de los libros como haria para hacer si el libro es no disponible no pueda ser prestado?... Gracias de antemano ya esto es lo ultimo que me hace falta para terminar mi base de datos...

[gnzsoloyo]

Eso es lógica de controlador de entidades (programación), no de BBDD.
Es evidente que lo que tienes que hacer es precisamente inhabilitar a nivel de vista de aplicación el que un libro que ya has determinado en la consulta que está prestado, pueda ser solicitado antes de que sea devuelto.
No todo se resuelve en la base de datos.
Para algo existe el modelo MVC..

[thomas_2417]

No me esta entendiendo mucho, lo que quiero hacer es la base de datos completa sin interaz grafica ni nada de eso todo a pura sentencia de base de dato y esto que le estoy pidiendo es una de esas sentencias... Que al momento de ingresar o al momento de volver a prestar el mismo libro si no a sido devuelto y su estado es "no disponible" no se pueda prestar...

[gnzsoloyo]

¿Me estás diciendo que todas las ABM (alta - baja - modificación) se harán a mano?



Como quieras, pero te advierto que eso no es nada práctico, y muchas cosas no las podrás hacer por triggers...
Ten en cuenta que una validación como la que quieres generará una excepción al momento de ser rechazada el alta de un prestamo no válido, y que de algún modo tendrás que adminsitrar esa condición.
SI no lo haces en la programación de la aplicación, lo tendrás que hacer en stored procedures de todos modos, que para el caso es lo mismo que lo anterior, porque estamos hablando de la capa de datos del modelo MVC (Data Access Control).

Dejame verlo y te contesto. Ahora es muy tarde aquí.

[thomas_2417]

Si todo es hara a mano... Es que la materia es base de datos y el docente no los pidio todo a mano y no puedo hacer ninguna aplicacion... Te agradesco la ayuda gracias...