Ejercicio: (difícil) Web adopción de mascotas

Enunciado #

PawMatch permite que protectoras publiquen mascotas y que las personas soliciten su adopción. La aplicación incluye chat por solicitud, visitas domiciliarias, acogidas temporales, adopciones, historial veterinario, microchips, eventos, favoritos, reseñas, pagos y sanciones. Diseña un modelo relacional que cubra todo ese proceso.

El documento deja abiertos los atributos concretos. Se propone la siguiente estructura de referencia, con direcciones reutilizables, roles múltiples y relaciones independientes para acogida y adopción.

Datos que debes almacenar #

Se usan identificadores internos salvo que se indique una clave natural. Los campos opcionales deben admitir NULL. La lista fija nombres y tipos para poder comparar tu diseño con la solución del challenge.

Identidad, direcciones y protectoras #

• Direccion: id_direccion (entero), calle (texto), ciudad (texto), provincia (texto), codigo_postal (texto), pais (texto).
• Usuario: id_usuario (entero), nombre (texto), email (texto, único), contrasena_hash (texto), id_direccion (entero).
• Rol: id_rol (entero), nombre (texto, único).
• UsuarioRol: id_usuario (entero), id_rol (entero).
• Protectora: id_protectora (entero), nombre (texto), email (texto), telefono (texto), id_direccion (entero).
• GestionProtectora: id_usuario (entero), id_protectora (entero).

Publicaciones y proceso de adopción #

• Mascota: id_mascota (entero), id_protectora (entero), nombre (texto), especie (texto), raza (texto), edad_meses (entero), estado (enum).
• FotoMascota: id_foto (entero), id_mascota (entero), url (texto), orden (entero).
• Solicitud: id_solicitud (entero), id_usuario (entero), id_mascota (entero), fecha (fechahora), estado (enum), motivacion (texto).
• MensajeSolicitud: id_mensaje (entero), id_solicitud (entero), id_autor (entero), fecha (fechahora), texto (texto).
• VisitaDomiciliaria: id_solicitud (entero), id_direccion (entero), id_evaluador (entero), fecha_programada (fechahora), resultado (enum), observaciones (texto, opcional).
• Acogida: id_acogida (entero), id_mascota (entero), id_usuario (entero), fecha_inicio (fecha), fecha_fin (fecha, opcional).
• Adopcion: id_adopcion (entero), id_solicitud (entero, único), fecha (fecha).

Salud y participación #

• Vacuna: id_vacuna (entero), nombre (texto).
• Vacunacion: id_mascota (entero), id_vacuna (entero), fecha (fechahora), lote (texto), veterinario (texto).
• Tratamiento: id_tratamiento (entero), id_mascota (entero), fecha (fechahora), descripcion (texto), veterinario (texto).
• Microchip: numero_chip (texto), id_mascota (entero, único), fecha_implantacion (fecha).
• Favorito: id_usuario (entero), id_mascota (entero).
• Resena: id_adopcion (entero), puntuacion (entero), comentario (texto), fecha (fechahora).

Cobros, eventos y sanciones #

• DonacionPago: id_movimiento (entero), id_usuario (entero), id_protectora (entero), id_solicitud (entero, opcional), fecha (fechahora), importe (decimal), tipo (enum), estado (enum).
• Evento: id_evento (entero), id_protectora (entero), id_direccion (entero), nombre (texto), fecha_inicio (fechahora), fecha_fin (fechahora).
• InscripcionEvento: id_evento (entero), id_usuario (entero), fecha (fechahora).
• SancionUsuario: id_sancion (entero), id_usuario (entero), motivo (texto), inicio (fechahora), fin (fechahora, opcional).

Claves, relaciones y reglas del negocio #

Identificación y relaciones N:N #

1. Usa como PK el primer campo identificador de cada tabla, excepto UsuarioRol, GestionProtectora, Favorito e InscripcionEvento, cuyas PK son sus dos primeros campos. Vacunacion tiene PK (id_mascota, id_vacuna, fecha), para admitir varias dosis de una vacuna en fechas distintas.
2. UsuarioRol resuelve los roles N:N. Rol.nombre admite admin, shelter_manager y adopter; un usuario puede tener varios. Se guarda un hash de contraseña, nunca la contraseña en claro.
3. Un usuario y una protectora tienen una dirección obligatoria; varias personas o entidades pueden reutilizarla, así que sus FK de dirección no son únicas. Las visitas y eventos también referencian direcciones. Una dirección ya usada en una visita histórica no debe alterarse para representar otro lugar: crea una nueva versión/fila.
4. GestionProtectora relaciona usuarios gestores y protectoras N:N. El rol shelter_manager habilita la función, pero pertenecer a una protectora concreta requiere esa relación. Los evaluadores de visitas y autores que actúan por la protectora deben estar autorizados para ella.

Mascotas, solicitudes, acogida y adopción #

5. Cada mascota pertenece a una protectora actual. Su estado admite adoptable, reservado, adoptado, en_foster o no_disponible. Sus fotos están en filas de FotoMascota, no en una lista dentro de la mascota; orden controla su presentación. La edad se expresa en meses.
6. Cada solicitud pertenece a una persona y a una mascota. Se permiten solicitudes históricas repetidas de la misma pareja en momentos diferentes. Sus estados son pendiente, en_revision, rechazada, aprobada y finalizada.
7. Cada mensaje pertenece a una solicitud y tiene un autor usuario. El autor debe ser la persona solicitante o un gestor autorizado de la protectora correspondiente; esto exige validar el contexto de la solicitud.
8. VisitaDomiciliaria usa id_solicitud como PK y FK: una solicitud puede tener como máximo una visita en este alcance. Registra dirección, evaluador, fecha programada y resultado pendiente, apta o no_apta; las observaciones son opcionales. Si se reprograma, se actualiza esa visita; no se pide historial de reprogramaciones.
9. Acogida registra periodos temporales de una mascota con un usuario. El acogedor puede ser distinto de quien solicita o termina adoptando. No derives la acogida de una solicitud ni marques la mascota como única en todo su historial. No puede haber dos acogidas simultáneas de la misma mascota.
10. Adopcion.id_solicitud es obligatorio y único. La persona, mascota y protectora se obtienen de la solicitud; no se duplican esos campos. Solo una solicitud aprobada puede finalizar en adopción, y una mascota no puede tener dos adopciones simultáneas. No se pide gestionar devoluciones: en este alcance, una mascota solo puede tener una adopción finalizada. Impedir varias adopciones de la misma mascota a través de solicitudes distintas requiere una validación transaccional adicional.

Salud, reseñas y favoritos #

11. Una vacuna puede administrarse a muchas mascotas y una mascota recibir muchas vacunas. Cada fila de Vacunacion registra una dosis, su lote y el veterinario como texto. Los tratamientos son filas históricas propias, también con veterinario y fecha. No se crea una tabla de profesionales porque el documento no pide sus perfiles.
12. El microchip es opcional por mascota: la ausencia se representa sin fila en Microchip. numero_chip es PK de texto y id_mascota es FK obligatoria y única. Una mascota tiene como máximo un microchip y un chip identifica una sola mascota.
13. Los favoritos son N:N entre usuarios y mascotas. Una reseña usa id_adopcion como PK y FK: hay como máximo una por adopción. Su autor y protectora evaluada se deducen de la adopción y su solicitud. Solo la persona adoptante puede publicarla, después de finalizar la adopción.

Movimientos, eventos y controles adicionales #

14. Cada DonacionPago pertenece a un usuario y a una protectora. Puede enlazarse a una solicitud, que debe corresponder a esa persona y protectora. tipo admite donacion o tasa_adopcion y estado, pendiente, confirmado o fallido. El importe debe ser positivo. Para este challenge no se contemplan donaciones anónimas.
15. Cada evento tiene una protectora organizadora y una dirección. La inscripción relaciona usuarios y eventos N:N, sin duplicar una persona en un mismo evento.
16. Las sanciones pertenecen a un usuario y pueden tener fin nulo mientras estén vigentes. Deben aplicarse al autorizar solicitudes, mensajes y otras acciones según la política de la plataforma.
17. La coherencia de estados, los permisos, la ausencia de acogidas solapadas y la exclusividad de una adopción se controlan mediante restricciones adicionales y transacciones. El diagrama no comprueba esas operaciones por sí solo.

Diseña las veintitrés tablas. Justifica la separación entre una solicitud, una acogida y una adopción, y las comprobaciones que evitan que varias personas adopten la misma mascota.

CHECK que debes configurar #

Escribe cada expresión exactamente en el campo indicado; los demás CHECK se dejan vacíos.

En Resena, campo puntuacion:

1puntuacion BETWEEN 1 AND 5

En Acogida, campo fecha_fin:

1fecha_fin IS NULL OR fecha_fin >= fecha_inicio

En Evento, campo fecha_fin:

1fecha_fin >= fecha_inicio

En SancionUsuario, campo fin:

1fin IS NULL OR fin >= inicio

Criterios para el challenge #

Conserva los nombres y tipos indicados. Todos los campos son obligatorios (NN) salvo los marcados como opcionales. Marca PK y FK según las reglas y las restricciones de unicidad indicadas. Una PK compuesta identifica por la combinación; no marques cada componente como único por separado.

Dibuja cada conexión desde el campo referenciado hacia la FK. Usa extremos 1 y n, o 1 y 1 para las relaciones de uno a uno. La opcionalidad se expresa con NN desmarcado en la FK. Si una FK es compuesta, dibuja una conexión por cada componente; en SQL todas esas columnas deben formar una única FOREIGN KEY hacia la misma fila.

Deja desactivados autoincremento, clave alternativa e índice. Deja vacíos valor por defecto, ON DELETE, ON UPDATE y CHECK, salvo los CHECK indicados expresamente. Las restricciones compuestas adicionales, los índices de explotación y las reglas entre varias filas se documentan aparte: el corrector del diagrama no ejecuta operaciones del negocio ni sustituye esas validaciones.