sql >> Database >  >> RDS >> Database

Een gegevensmodel voor de marathontraining-app

Droom je ervan om een ​​marathon te lopen? Laten we eens kijken naar het datamodel voor een app die je van luie bankschroef tot marathonloper kan brengen.

Wat heb je nodig om een ​​marathon te lopen? Je hebt enthousiasme en vastberadenheid nodig. Een goed paar hardloopschoenen. En veel fysieke training! Stel dat u een app heeft waarmee u van een beginnende hardloper naar een marathonafmaker kunt gaan. Hoe zou het datamodel eruit zien?

In dit artikel onderzoeken we het datamodel achter een marathontraining-app.

Wat moet een Marathon Training-app doen?

Elke trainingsapp wordt meestal geleverd met enkele opties. In dit geval verwachten we dat de app training ondersteunt voor verschillende soorten hardloopsessies (een hele marathon, een halve marathon, een 5k) en voor verschillende trainingsschema's (van acht tot 24 weken). De app legt uw basisgegevens vast, waaronder leeftijd, geslacht en huidige hardloopstatus. Het moet u ook in staat stellen om een ​​doel en een startdatum in te stellen. De app gebruikt deze informatie om een ​​trainingsplan te maken voor je aanstaande hardloopevenement. Hoe meer je vordert met je plan, hoe dichter je bij je doel komt.

Laten we de belangrijkste vereisten van deze app eens doornemen. Het moet:

  • Vul een gebruikersnaam, leeftijd, geslacht, etc. vast tijdens het registratieproces.
  • Weergave van een lijst met doelen (bijv. wandelen, hardlopen, fietsen, etc.) met een bijbehorende doelafstand.
  • Laat gebruikers een doel, doelafstand en startdatum instellen.
  • Maak een gedetailleerd persoonlijk trainingsplan voor individuele gebruikers waarbij rekening wordt gehouden met hun leeftijd, geslacht en huidig ​​fitnessniveau. Dit trainingsplan omvat:
    • Activiteiten, zoals hardlopen.
    • Data voor activiteiten die moeten worden gestart en voltooid.
    • Afstanden (bijvoorbeeld 5 kilometer hardlopen)
    • Voorgesteld tempo (bijv. 5 km/u) en geschatte voltooiingstijden (1 uur).
    • Rustdagen. Het is belangrijk om deze in een fysiek fitnessplan op te nemen.
    • Einddatum van het doel, bijv. wanneer de gebruiker klaar zou zijn om het door hem gekozen evenement te organiseren.
  • De voortgang van activiteiten in het trainingsplan vastleggen, inclusief wanneer (of als) elke activiteit is gestart, hoe dicht de gebruiker bij het voltooien ervan is en wanneer deze is voltooid.
  • Pas indien nodig trainingsplannen aan. Een hardloper kan bijvoorbeeld ziek of geblesseerd worden en kan zijn oorspronkelijke schema niet volgen; in dat geval moet het oorspronkelijke plan worden verlengd of aangepast.
  • Capture titels verdiend door de gebruiker. Bij hardlopen zijn deze gebaseerd op succesvol voltooide gebeurtenissen, b.v. 5K-loper, 10K-loper, halve marathonloper of hele marathonloper. Deze titels worden verdiend naarmate hardlopers vooruitgang boeken met hun training.

Het gegevensmodel

Het datamodel dat een dergelijke app ondersteunt, bestaat uit drie vakgebieden:

  1. Gebruikers en titels
  2. Doelen en activiteiten
  3. Gebruikersdoelen en -overgangen

We bespreken elk onderwerp in de volgorde waarin het wordt vermeld.

Onderwerpgebied 1:Gebruikers en titels

Deze app zal door meer dan alleen beginnende hardlopers worden gebruikt. Hardloopevenementen zijn zeer veeleisend en inspannend; zelfs doorgewinterde marathonlopers moeten trainen voor aankomende marathons. Niemand loopt een hele marathon 's nachts of na een enkele training. Het is een geleidelijk proces.

Zoals we eerder vermeldden, verdienen hardlopers verschillende titels op basis van evenementen van verschillende lengte. Naarmate een hardloper vordert in zijn training, kunnen ze langere evenementen uitvoeren en meer titels verdienen. De tabellen in dit vakgebied zijn met dat in gedachten gedefinieerd.

De "registered_user ”-tabel bevat basisgegevens over gebruikers. Deze gegevens worden vastgelegd tijdens het registratieproces. Dit omvat twee belangrijke factoren die van invloed zijn op het ontwerp van het trainingsplan:leeftijd (afgeleid van date_of_birth ) en geslacht. Deze zijn belangrijk omdat verschillende geslachten en leeftijdsgroepen verschillend trainen, zelfs als ze aan hetzelfde evenement deelnemen. Een 19-jarige jongen heeft een ander trainingsplan nodig dan een 45-jarige vrouw.

Het “running_event ”-tabel bevat een lijst met alle officiële hardloopevenementen. Dit kunnen internationale evenementen zijn. Alle velden spreken voor zich.

De "title ”-tabel slaat voornamelijk de "referenties" van lopers op:de afstand die ze afleggen en de tijd die nodig is tijdens een officieel evenement. Kernpunten over titels en hun distributie zijn:

  • Elk marathonevenement heeft zijn eigen lijst met titels.
  • Meestal worden deze titels aan lopers gegeven aan het einde van een mijlpaal (op een baan) of wanneer ze finishen (bijvoorbeeld de finishlijn van een marathon overschrijden).
  • Dezelfde titel kan aan meerdere lopers worden gegeven, op voorwaarde dat ze allemaal aan de voorwaarden voldoen. Deze omvatten (1) de minimaal af te leggen afstand en (2) de maximale tijd om deze afstand af te leggen.
  • Als titels worden gedefinieerd op tussenliggende mijlpalen op een baan, behoudt de loper de enige hoogste titel die ze hebben verdiend.

Met dit begrip van titels zouden de kolommen in de "titel" -tabel voor zichzelf moeten spreken.

De "user_title ”-tabel slaat alle titels op die gebruikers hebben verdiend. Het enige verschil is dat we hier de tijd van de loper in seconden vastleggen in plaats van minuten.

Onderwerpgebied 2:Doelen en activiteiten

Niemand kan je motiveren om een ​​marathon te lopen als je dat niet wilt. Je moet je eigen ijver aanwakkeren. Een manier om gemotiveerd te blijven, is door doelen te stellen en te bereiken. De volgende twee onderwerpen gaan over het stellen en behalen van doelen.

Eerst kijken we naar de Goals and Activities gebied. Het bevat drie tabellen:

  1. goal ” bevat details over de doelen die in de app zijn gedefinieerd.
  2. activity ” slaat informatie op over verschillende soorten trainingsactiviteiten, zoals wandelen, snelwandelen, hardlopen, zwemmen, fietsen, enz.
  3. goal_activity ” slaat details op over activiteiten die nodig zijn om een ​​doel te bereiken.

Het is belangrijk om te begrijpen dat hetzelfde doel door verschillende gebruikers op verschillende manieren wordt bereikt. Nogmaals, een 15-jarig meisje heeft een trainingsplan en een reeks activiteiten die anders zijn dan een 40-jarige man. Gezien deze feiten hebben we de volgende kolommen in het "goal ” tabel:

  • distance_to_run – De afstand die een hardloper moet kunnen lopen aan het einde van dit doel.
  • target_time_in_min – De maximale tijd die nodig is om deze afstand te overbruggen.
  • gender – Voor welk geslacht dit doel is.

Er kan een doel worden gemaakt voor een leeftijdsgroep, bijvoorbeeld 15-20 of 35-40. Hoe we trainen verandert een beetje naarmate we ouder worden, daarom hebben we nog twee kolommen toegevoegd aan "goal ”:

  • starting_age – De minimumleeftijd voor dit doel.
  • closing_age – De maximale leeftijd voor dit doel.

Mensen kunnen groot dromen, maar de enige manier om dingen echt te laten gebeuren, is door geleidelijk vooruitgang te boeken. Deze app beperkt hoe gebruikers doelen stellen; ze moeten kleinere, haalbare doelen bereiken voordat ze de grotere proberen. Een couch potato kan dromen van het lopen van een volledige marathon van 26,2 mijl / 42,2 km, maar ze zouden eerst moeten werken aan een run van 5K.

Het “goal ” tabel behandelt beperkingen door middel van de volgende kolommen:

  • current_run_distance_per_week – De minimale afgelegde afstand voordat een gebruiker een bepaald doel kan stellen; en
  • current_min_title_id – De minimale titel die gebruikers moeten hebben om dit doel te stellen.

Als niet aan deze vereisten wordt voldaan, is dat doel niet beschikbaar voor de gebruiker. Beide kolommen zijn echter nullable; er zullen enkele doelen zijn waarvoor geen fitnessvereisten gelden.

Laten we verder gaan met de "goal_activity " tafel. De meeste van deze kolommen hebben een duidelijk doel. Ik zal alleen commentaar geven op twee, te beginnen met de seq_of_day kolom. Dit is een cijferkolom die waarden bevat die de dag aangeven waarop een activiteit moet worden uitgevoerd. Uiteraard begint deze reeks bij 1 voor elk doel. Het kan nooit NUL of NULL zijn. Nummers mogen niet opeenvolgend zijn voor een doel; dit zou betekenen dat er rustdagen zijn ingesteld. Dagen waarvoor er geen gegevens in deze tabel zijn, zijn eigenlijk rustdagen.

Vervolgens hebben we de distance_to_cover kolom. Dit is nul, omdat er activiteiten zijn (zoals yoga, stretching en gewichtheffen) waarbij afstand er niet toe doet. Dit gezegd hebbende, merk op dat de min_pace en max_pace kolommen in de "activity ”-tabel zijn ook nullable.

Onderwerpgebied #3:Gebruikersdoelen en overgangen

Dit onderwerp gaat helemaal over door gebruikers gemaakte doelen en door apps gemaakte activiteitenplannen. Werkelijke datums zijn hier belangrijk, en de seq_of_day kolom in de "goal_activity ”-tabel speelt een belangrijke rol bij het weergeven van plandatums, net als de start_date gekozen door gebruikers voor hun doelen.

De "user_goal ” en “transition_plan ” tabellen zijn beide meestal zelfverklarend. Er zijn slechts een paar kolommen die we moeten markeren.

In de "user_goal ” tabel:

  • is_active – Geeft aan of een gebruiker nog steeds vooruitgang boekt op dit doel. Alle lopende doelen hebben een 'Y' in deze kolom. Met deze kolom kan de app gebruikers beperken tot het instellen van één doel tegelijk.
  • create_date – De datum waarop een doel is gemaakt.
  • start_date – De datum waarop een doelpunt daadwerkelijk is gestart. Het is misschien niet hetzelfde als de create_date.
  • expected_end_date – Een einddatum, berekend door de app nadat deze een overgangsplan voor de gebruiker heeft gemaakt.
  • actual_end_date – Wanneer het doel daadwerkelijk is bereikt. Er kunnen afwijkingen zijn van het trainingsplan, daarom hebben we deze kolom nodig om de werkelijke einddatum vast te leggen. De app kan een optie geven om een ​​dag over te slaan of om het trainingsschema met een dag of zo te vervroegen. In dergelijke gevallen wordt de actual_end_date zal zeker verschillen van de expected_end_date .

In het “transition_plan ” tabel:

  • is_complete – Geeft aan of een activiteit is overgeslagen, nog niet is gestart of is voltooid. Het zal een 'Y', 'N' of een spatie bevatten.
  • start_timestamp – Het tijdstempel waarop een activiteit is gestart.
  • end_timestamp – Het tijdstempel waarop de activiteit is voltooid.

Omdat we begrijpen dat er hiaten in de training kunnen zijn (door ziekte, blessure of gebrek aan motivatie), bevat deze tabel drie verschillende data:

  • original_calendar_date – Een kalenderdatum die aangeeft wanneer een activiteit moet worden uitgevoerd. Deze waarde wordt ingevuld wanneer de app een trainingsplan genereert.
  • planned_calendar_date – In eerste instantie blijft deze kolom leeg. Er wordt een datum ingevuld wanneer er een wijziging wordt aangebracht in het trainingsplan.
  • actual_calendar_date – Deze kolom wordt gevuld zodra de gebruiker een activiteit als voltooid markeert. Dit is de datum waarop de activiteit daadwerkelijk is afgelopen.

De planned_calendar_date en actual_calendar_date kolommen zijn nullable; ze worden niet ingevuld tijdens de eerste generatie van het plan.

Nog drie kolommen in deze tabel zijn nullable zodat dit datamodel alle mogelijke scenario's voor een lopende activiteit aankan. Hier zijn enkele voorbeelden:

  • Een activiteit die nog niet is gestart –
    • is_complete – NULL
    • start_timestamp – NULL
    • end_timestamp - NULL
  • Een activiteit die is gestart maar niet is voltooid –
    • is_complete – NULL
    • start_timestamp – WAARDE
    • end_timestamp - NULL
  • Een activiteit die is overgeslagen –
    • is_complete – ‘N’
    • start_timestamp – NULL
    • end_timestamp - NULL
  • Een activiteit die is voltooid –
    • is_complete – 'Y'
    • start_timestamp –VALUE
    • end_timestamp - VALUE

Wat zou u veranderen aan dit gegevensmodel?

Trainen voor een marathon is meer dan alleen sporten. Marathonlopers moeten elk aspect van hun levensstijl aanpassen, te beginnen met hun dagelijkse voedselinname, hun mentale kracht en zelfs de hoeveelheid slaap die ze krijgen.

Een effectieve app moet alle aspecten van training kunnen organiseren, plannen en volgen. Houdt ons datamodel rekening met al deze aspecten? Welke veranderingen zijn nodig om er een volwaardige trainingsapp van te maken?

Deel uw mening en suggesties in het opmerkingengedeelte.


  1. DAY() Voorbeelden in SQL Server (T-SQL)

  2. Lange strings in N-Hibernate met Oracle veroorzaken fout

  3. NULLIF() Functie in Oracle

  4. MySQL-opdracht invoegen versus T-SQL-querysyntaxis met voorbeelden