Zum Hauptinhalt springen

Supabase-Schema

Supabase fungiert als Haupt-Backend der Anwendung. Die zugrunde liegende Datenbank ist PostgreSQL. Nachfolgend werden jede Tabelle, ihre Spalten und die Beziehungen zwischen ihnen beschrieben.

Tabelle: Benutzer​

Speichert die Daten der in der Anwendung registrierten Benutzer.

SpalteGeben Sieein EinschränkungenBeschreibung
idintegerPK, automatische InkrementierungEindeutige Benutzerkennung
nombrevarchar(100)NICHT NULLVollständiger Name des Benutzers
dnivarchar(20)EINZIGARTIGNationales Ausweisdokument. Es wird als Anmeldekennung
contraseniaHashvarchar(255)Gespeichertes Passwort (Klartext in aktueller Version)
emailvarchar(100)EINZIGARTIGE-Mail. Wird zur Passwortwiederherstellung verwendet
telefonovarchar(20)Kontakttelefonnummer
adminintegerSTANDARD 0Gibt an, ob der Benutzer eine Administratorrolle hat (0 = Benutzer, 1 = Administrator)
premiumbooleanDEFAULT falseGibt an, ob der Benutzer über ein aktives Premium-Abonnement verfügt
fecha_ini_premdateStartdatum des Premium-Abonnements
fecha_fin_premdateEnddatum des Premium-Abonnements
fototextBase64-codiertes Profilbild

Die entsprechende Datenklasse ist models/Usuario.kt.

Tabelle: Maschinen​

Speichert den Fitnessgerätekatalog.

SpalteGeben Sieein EinschränkungenBeschreibung
idintegerPK, automatische InkrementierungEindeutige Maschinenkennung
nombrevarchar(100)NICHT NULLAnzeigename der Maschine
tipovarchar(50)Übungskategorie (Cardio, Rücken, Bein, Brust usw.)
estadointegerSTANDARD 0Allgemeines Statusfeld
descripciontextAusführliche Maschinenbeschreibung
operativabooleanSTANDARD wahrZeigt an, ob die Maschine für Reservierungen verfügbar ist
mantenimiento_desdevarcharDatum und Uhrzeit des Beginns des Wartungszeitraums (yyyy-MM-dd HH:mm)
mantenimiento_hastavarcharDatum und Uhrzeit des Endes des Wartungszeitraums (yyyy-MM-dd HH:mm)

Die entsprechende Datenklasse ist models/Maquina.kt.

Tabelle: Reserven​

Speichert von Benutzern vorgenommene Maschinenreservierungen.

SpalteGeben Sieein EinschränkungenBeschreibung
idintegerPK, automatische InkrementierungEindeutige Reservierungskennung
id_usuariointegerFK → user.idBenutzer, der die Reservierung vorgenommen hat
id_maquinaintegerFK →machines.idReservierte Maschine
fechadateReservierungsdatum (yyyy-MM-dd)
hora_iniciotimeStartzeit des reservierten Slots
hora_fintimeEndzeit des reservierten Slots
estadobooleanSTANDARD wahrtrue = aktiv, false = abgebrochen

Die entsprechenden Datenklassen sind models/Reserva.kt und models/ReservaConDetalles.kt. Die zweite enthält die eingebetteten Objekte Usuario und Maquina, die über die PostgREST-Beziehungssyntax (*, usuarios(*), maquinas(*)) abgerufen werden.

Tisch: Geschirr​

Bewahren Sie nahrhafte Gerichte aus dem Katalog auf.

SpalteGeben Sieein EinschränkungenBeschreibung
idintegerPK, automatische InkrementierungEindeutige Gericht-ID
id_usuariointegerFK → user.idBenutzer, der das Gericht vorgeschlagen hat (nullable für Systemgerichte)
nombrevarchar(100)NICHT NULLName des Gerichts
descripciontextBeschreibung oder Rezept des Gerichts
caloriasdouble precisionKaloriengehalt pro Portion
imagen_urlvarchar(255)Bild-URL oder Base64-String des Plattenbilds
fecha_subidatimestampErstellungsdatum und -uhrzeit aufzeichnen
visibilidadbooleanSTANDARD wahrGibt an, ob das Gericht im Katalog sichtbar ist
tiempovarcharGeschätzte Vorbereitungszeit (zum Beispiel „30 Minuten“)
aceptadobooleanDEFAULT falseZeigt an, ob das Gericht von einem Administrator genehmigt wurde

Die entsprechende Datenklasse ist models/Plato.kt.

Tabelle: user_weight​

Speichert den Verlauf der Gewichtsaufzeichnungen für jeden Benutzer.

SpalteGeben Sieein EinschränkungenBeschreibung
idintegerPK, automatische InkrementierungEindeutiger Datensatzbezeichner
id_usuariointegerFK → user.idBenutzer, zu dem der Datensatz gehört
pesodouble precisionNICHT NULLGewicht in Kilogramm
fechadateRegistrierungsdatum (yyyy-MM-dd)

Die Anwendung sieht die Beschränkung einer einzigen Registrierung pro Tag auf UI-Ebene vor. Der Bildschirm prüft, ob für das aktuelle Datum bereits ein Datensatz vorhanden ist, bevor ein neuer hinzugefügt werden kann.

Die entsprechende Datenklasse ist models/PesoUsuario.kt.

Tabelle: Zahlungen​

Speichert den Transaktionsverlauf des Premium-Abonnements.

SpalteGeben Sieein EinschränkungenBeschreibung
idintegerPK, automatische InkrementierungEindeutige Zahlungskennung
id_usuariointegerFK → user.idBenutzer, der die Zahlung vorgenommen hat
montodouble precisionNICHT NULLTransaktionsbetrag in Euro
fecha_pagodateDatum der Zahlung
tipovarchar(50)Abonnementmodus (monatlich, halbjährlich, jährlich)
metodo_pagovarchar(25)Verwendete Zahlungsmethode (Karte, Bizum)

Die entsprechende Datenklasse ist models/Pago.kt.

Beziehungsdiagramm​

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

Die Beziehungen sind alle eins-zu-viele. Auf der Supabase-Dashboard-Ebene sind keine expliziten Fremdschlüssel definiert. Die referenzielle Integrität wird auf Anwendungsebene verwaltet.

Sicherheit auf Zeilenebene​

Supabase Row Level Security (RLS)-Richtlinien sind in dieser Version nicht konfiguriert. Der Datenzugriff erfolgt mit anon key, sodass jeder Client mit dem Schlüssel alle Tabellen lesen und schreiben kann. In einer Produktionsumgebung wäre es wichtig, entsprechende RLS-Richtlinien zu definieren oder service_role key ausschließlich von einem vertrauenswürdigen Backend aus zu verwenden.

Datenbankkonstanten​

Die Namen der Tabellen und Spalten werden in DbConstants.kt durch die Objekte DbTables und DbColumns zentralisiert, wodurch die Verwendung von im Code verstreuten Literalzeichenfolgen vermieden wird:

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"
// ...
}