Passer au contenu principal

Schéma Supabase

Supabase agit comme le backend principal de l'application. La base de données sous-jacente est PostgreSQL. Chaque tableau, ses colonnes et les relations entre elles sont décrites ci-dessous.

Tableau : utilisateurs​

Stocke les données des utilisateurs enregistrés dans l'application.

ColonneTapezRestrictionsDescriptif
idintegerPK, incrémentation automatiqueIdentifiant unique de l'utilisateur
nombrevarchar(100)PAS NULLNom complet de l'utilisateur
dnivarchar(20)UNIQUEDocument d'identité nationale. Il est utilisé comme identifiant de connexion
contraseniaHashvarchar(255)Mot de passe stocké (texte brut dans la version actuelle)
emailvarchar(100)UNIQUEE-mail. Utilisé pour la récupération de mot de passe
telefonovarchar(20)Numéro de téléphone du contact
adminintegerPAR DÉFAUT 0Indique si l'utilisateur a un rôle d'administrateur (0 = utilisateur, 1 = admin)
premiumbooleanPAR DÉFAUT fauxIndique si l'utilisateur dispose d'un abonnement Premium actif
fecha_ini_premdateDate de début de l'abonnement Premium
fecha_fin_premdateDate de fin de l'abonnement Premium
fototextImage de profil encodée en Base64

La classe de données correspondante est models/Usuario.kt.

Tableau : machines​

Stocke le catalogue des machines de gym.

ColonneTapezRestrictionsDescriptif
idintegerPK, incrémentation automatiqueIdentifiant unique de la machine
nombrevarchar(100)PAS NULLNom convivial de la machine
tipovarchar(50)Catégorie d'exercice (Cardio, Dos, Jambe, Poitrine, etc.)
estadointegerPAR DÉFAUT 0Champ de statut générique
descripciontextDescription détaillée de la machine
operativabooleanPAR DÉFAUT vraiIndique si la machine est disponible pour les réservations
mantenimiento_desdevarcharDate et heure de début de la période de maintenance (yyyy-MM-dd HH:mm)
mantenimiento_hastavarcharDate et heure de fin de la période de maintenance (yyyy-MM-dd HH:mm)

La classe de données correspondante est models/Maquina.kt.

Tableau : réserves​

Stocke les réservations de machines effectuées par les utilisateurs.

ColonneTapezRestrictionsDescriptif
idintegerPK, incrémentation automatiqueIdentifiant unique de réservation
id_usuariointegerFK → utilisateurs.idUtilisateur ayant effectué la réservation
id_maquinaintegerFK → machines.idMachine réservée
fechadateDate de réservation (yyyy-MM-dd)
hora_iniciotimeHeure de début du créneau réservé
hora_fintimeHeure de fin du créneau réservé
estadobooleanPAR DÉFAUT vraitrue = actif, false = annulé

Les classes de données correspondantes sont models/Reserva.kt et models/ReservaConDetalles.kt. Le second comprend les objets Usuario et Maquina intégrés, obtenus via la syntaxe de relation PostgREST (*, usuarios(*), maquinas(*)).

Tableau : plats​

Conservez les plats nutritionnels du catalogue.

ColonneTapezRestrictionsDescriptif
idintegerPK, incrémentation automatiqueIdentifiant unique du plat
id_usuariointegerFK → utilisateurs.idUtilisateur qui a suggéré le plat (nullable pour les plats système)
nombrevarchar(100)PAS NULLNom du plat
descripciontextDescription ou recette du plat
caloriasdouble precisionTeneur en calories par portion
imagen_urlvarchar(255)URL de l'image ou chaîne Base64 de l'image de la plaque
fecha_subidatimestampDate et heure de création de l'enregistrement
visibilidadbooleanPAR DÉFAUT vraiIndique si le plat est visible dans le catalogue
tiempovarcharTemps de préparation estimé (par exemple, "30 minutes")
aceptadobooleanPAR DÉFAUT fauxIndique si le plat a été approuvé par un administrateur

La classe de données correspondante est models/Plato.kt.

Tableau : poids_utilisateur​

Stocke l’historique des enregistrements de poids pour chaque utilisateur.

ColonneTapezRestrictionsDescriptif
idintegerPK, incrémentation automatiqueIdentifiant unique de l'enregistrement
id_usuariointegerFK → utilisateurs.idUtilisateur auquel appartient l'enregistrement
pesodouble precisionPAS NULLPoids en kilogrammes
fechadateDate d'inscription (yyyy-MM-dd)

L'application impose la restriction d'une seule inscription par jour au niveau de l'UI. L'écran vérifie si un enregistrement existe déjà pour la date actuelle avant de permettre l'ajout d'un nouveau.

La classe de données correspondante est models/PesoUsuario.kt.

Tableau : paiements​

Stocke l’historique des transactions de l’abonnement Premium.

ColonneTapezRestrictionsDescriptif
idintegerPK, incrémentation automatiqueIdentifiant unique de paiement
id_usuariointegerFK → utilisateurs.idUtilisateur ayant effectué le paiement
montodouble precisionPAS NULLMontant de la transaction en euros
fecha_pagodateDate de paiement
tipovarchar(50)Mode d'abonnement (Mensuel, Semestriel, Annuel)
metodo_pagovarchar(25)Mode de paiement utilisé (Carte, Bizum)

La classe de données correspondante est models/Pago.kt.

Diagramme de relation​

usuarios (id)
|
|--< reservas (id_usuario) >-- maquinas (id)
|
|--< peso_usuario (id_usuario)
|
|--< platos (id_usuario)
|
|--< pagos (id_usuario)

Les relations sont toutes de un à plusieurs. Aucune clé étrangère explicite n'est définie au niveau du tableau de bord Supabase ; L'intégrité référentielle est gérée au niveau de l'application.

Sécurité au niveau des lignes​

Les politiques Supabase Row Level Security (RLS) ne sont pas configurées dans cette version. L'accès aux données se fait avec le anon key, de sorte que tout client disposant de la clé peut lire et écrire sur toutes les tables. Dans un environnement de production, il serait essentiel de définir des politiques RLS appropriées ou d'utiliser service_role key exclusivement à partir d'un backend fiable.

Constantes de base de données​

Les noms des tables et des colonnes sont centralisés dans DbConstants.kt à travers les objets DbTables et DbColumns, évitant ainsi l'utilisation de chaînes littérales disséminées dans le code :

object DbTables {
const val USUARIOS = "usuarios"
const val MAQUINAS = "maquinas"
const val PLATOS = "platos"
const val PAGOS = "pagos"
const val RESERVAS = "reservas"
const val PESO_USUARIO = "peso_usuario"
}

object DbColumns {
const val ID = "id"
const val DNI = "dni"
const val NOMBRE = "nombre"
// ...
}