En Marathon Training App Data Model

Drømmer du om at løbe et maraton? Lad os se på datamodellen for en app, der kan tage dig fra doven sofakartoffel til maratonløber.

Hvad skal du bruge for at løbe et maraton? Du har brug for entusiasme og beslutsomhed. Et par gode løbesko. Og masser af fysisk træning! Lad os sige, at du har en app, der hjælper dig med at gå fra begynderløber til maratonløber. Hvordan ville datamodellen se ud?

I denne artikel vil vi undersøge datamodellen bag en maratontræningsapp.

Hvad skal en Marathon-træningsapp gøre?

Enhver træningsapp kommer normalt med nogle muligheder. I dette tilfælde ville vi forvente, at appen understøtter træning til forskellige typer løb (et helt maraton, et halvt maraton, et 5 km) og til forskellige træningsplaner (alt fra otte til 24 uger). Appen vil fange dine grundlæggende detaljer, herunder alder, køn og nuværende løbestatus. Det bør også give dig mulighed for at sætte et mål og en startdato. Appen vil bruge disse oplysninger til at oprette en træningsplan for din kommende løbebegivenhed. Jo mere du gør fremskridt med din plan, jo tættere vil du være på dit mål.

Lad os gennemgå de vigtigste krav til denne app. Det skal:

• Fang en brugers navn, alder, køn osv. under registreringsprocessen.
• Visning af en liste over mål (f.eks. gang, løb, cykling osv.) med en tilhørende måldistance.
• Tillad brugere at angive et mål, målafstand og startdato.
• Opret en detaljeret personlig træningsplan for individuelle brugere, der tager hensyn til deres alder, køn og aktuelle konditionsniveau. Denne træningsplan omfatter:
• Aktiviteter, såsom løb.
• Datoer for aktiviteter, der skal startes og afsluttes.
• Afstande (f.eks. løb i 5 kilometer)
• Foreslået tempo (f.eks. 5 km/t) og omtrentlige gennemførelsestider (1 time).
• Hviledage. Det er vigtigt at indbygge disse i en fysisk konditionsplan.
• Målets slutdato, f.eks. hvornår brugeren ville være klar til at køre deres valgte begivenhed.
• Fang status for træningsplanaktiviteter, herunder hvornår (eller hvis) hver aktivitet blev startet, hvor tæt brugeren er på at fuldføre den, og hvornår den var færdig.
• Juster træningsplanerne efter behov. For eksempel kan en løber blive syg eller såret og følger muligvis ikke deres oprindelige tidsplan; i så fald skal den oprindelige plan udvides eller ændres.
• Fang titler optjent af brugeren. I løbet er disse baseret på gennemførte begivenheder, f.eks. 5K-løber, 10K-løber, halvmaratonløber eller helmaratonløber. Disse titler optjenes, efterhånden som løbere udvikler sig med deres træning.

Datamodellen

Datamodellen, der understøtter en sådan app, består af tre emneområder:

1. Brugere og titler
2. Mål og aktiviteter
3. Brugermål og overgange

Vi diskuterer hvert emneområde i den rækkefølge, det er angivet.

Emneområde 1:Brugere og titler

Denne app vil blive brugt af mere end blot nybegyndere. Løbebegivenheder er meget krævende og anstrengende; selv garvede maratonløbere skal træne til kommende maratonløb. Ingen løber et helt maraton natten over eller efter et enkelt træningsforløb. Det er en gradvis proces.

Som vi nævnte tidligere, tjener løbere forskellige titler baseret på begivenheder af forskellig længde. Efterhånden som en løber udvikler sig i deres træning, vil de være i stand til at køre længere begivenheder og tjene flere titler. Tabellerne i dette emneområde er defineret med det i tankerne.

"registered_user ” tabel indeholder grundlæggende detaljer om brugere. Disse detaljer registreres under registreringsprocessen. Dette inkluderer to nøglefaktorer, der påvirker træningsplanens design:alder (afledt af date_of_birth ) og køn. Disse er vigtige, fordi forskellige køn og aldersgrupper træner forskelligt, selvom de konkurrerer i det samme arrangement. En 19-årig dreng har brug for en anden træningsplan end en 45-årig kvinde.

"running_event ” tabel gemmer en liste over alle officielle løbebegivenheder. Dette kunne omfatte internationale begivenheder. Alle felter er selvforklarende.

"title Tabellen gemmer primært løbernes "legitimationsoplysninger":den distance, de tilbagelægger, og den tid, det tog under en officiel begivenhed. Nøglepunkter om titler og deres distributioner er:

• Hver maratonbegivenhed har sin egen liste over titler.
• Som regel gives disse titler til løbere ved slutningen af ​​en milepæl (på en bane), eller når de slutter (f.eks. krydser målstregen på et maraton).
• Den samme titel kan gives til flere løbere, forudsat at de alle opfylder betingelserne. Disse omfatter (1) den minimumsafstand, der skal tilbagelægges, og (2) den maksimale tid til at tilbagelægge denne distance.
• Hvis titler er defineret ved mellemliggende milepæle på en bane, beholder løberen den eneste højeste titel, de har optjent.

Med denne forståelse af titler bør kolonnerne i "title"-tabellen være selvforklarende. ☺

"user_title ”-tabellen gemmer alle de titler, som brugerne har optjent. Den eneste forskel er, at vi her fanger løberens tid i sekunder i stedet for minutter.

Emneområde 2:Mål og aktiviteter

Ingen kan motivere dig til at løbe et maraton, hvis du ikke vil. Du skal oparbejde din egen iver. En måde at forblive motiveret på er at sætte og nå mål. De næste to fagområder omhandler opstilling og opfyldelse af mål.

Først vil vi se på Goals and Activities emneområde. Den indeholder tre tabeller:

1. “goal ” indeholder detaljer om de mål, der er defineret i appen.
2. “activity ” gemmer information om forskellige former for træningsaktiviteter, som f.eks. gåture, hurtiggang, løb, svømning, cykling osv.
3. “goal_activity ” gemmer detaljer om aktiviteter, der er nødvendige for at nå et mål.

Det er vigtigt at forstå, at det samme mål nås forskelligt af forskellige brugere. Igen vil en 15-årig pige have en træningsplan og et sæt aktiviteter, der er anderledes end en 40-årig mand. I betragtning af disse fakta har vi sat følgende kolonner i "goal ” tabel:

• distance_to_run – Den distance, en løber skal kunne løbe ved slutningen af ​​dette mål.
• target_time_in_min – Den maksimale tid, der er nødvendig for at tilbagelægge denne distance.
• gender – Hvilket køn dette mål er til.

Et mål kan oprettes for en aldersgruppe, f.eks. 15-20 eller 35-40. Hvordan vi træner ændrer sig lidt, efterhånden som vi bliver ældre, så vi har tilføjet yderligere to kolonner til "goal ”:

• starting_age – Minimumsalderen for dette mål.
• closing_age – Den maksimale alder for dette mål.

Folk kan drømme stort, men den eneste måde at virkelig få tingene til at ske er at udvikle sig gradvist. Denne app begrænser, hvordan brugere laver mål; de skal nå mindre, opnåelige mål, før de prøver på de større. En sofakartoffel kan drømme om at løbe hele 26,2 mile\42,2 km marathon, men de bør begynde at arbejde hen imod et 5K-løb først.

"goal ” tabel håndterer begrænsninger ved hjælp af følgende kolonner:

• current_run_distance_per_week – Den mindste løbedistance opnået, før en bruger kan sætte et bestemt mål; og
• current_min_title_id – Den mindste titel, brugere skal have for at sætte dette mål.

Hvis disse forudsætninger ikke er opfyldt, vil dette mål ikke være tilgængeligt for brugeren. Begge disse kolonner kan dog nulstilles; der vil være nogle mål, der ikke har nogen forudsætninger for konditionskrav.

Lad os gå videre til "goal_activity " bord. De fleste af disse kolonner tjener et åbenlyst formål. Jeg vil lige kommentere to, begyndende med seq_of_day kolonne. Dette er en talkolonne, der indeholder værdier, der angiver den dag, hvor en aktivitet skal udføres. Denne sekvens starter naturligvis fra 1 for ethvert mål. Det kan aldrig være NUL eller NULL. Tal må ikke være fortløbende for et mål; dette ville betyde, at der er fastsat hviledage. Dage, hvor der ikke er nogen registreringer i denne tabel, er faktisk hviledage.

Dernæst har vi distance_to_cover kolonne. Dette er ugyldigt, da der er aktiviteter (som yoga, udspænding og vægtløftning), hvor afstanden ikke betyder noget. Når dette er sagt, skal du bemærke, at min_pace og max_pace kolonner i "activity ”-tabeller kan også nulstilles.

Emneområde #3:Brugermål og overgange

Dette fagområde handler om brugerskabte mål og app-skabte aktivitetsplaner. Faktiske datoer er vigtige her, og seq_of_day kolonnen i "goal_activity ”-tabellen spiller en stor rolle ved gengivelse af plandatoer, ligesom start_date gør valgt af brugerne til deres mål.

"user_goal ” og “transition_plan ” tabeller er begge for det meste selvforklarende. Der er blot nogle få kolonner, som vi bør fremhæve.

I "user_goal ” tabel:

• is_active – Viser, om en bruger stadig gør fremskridt med dette mål. Alle igangværende mål vil have et "Y" i denne kolonne. Denne kolonne gør det muligt for appen at begrænse brugere til at sætte ét mål ad gangen.
• create_date – Datoen, hvor et mål blev oprettet.
• start_date – Datoen, hvor et mål faktisk blev startet. Det er muligvis ikke det samme som create_date.
• expected_end_date – En slutdato, beregnet af appen, efter at den har lavet en overgangsplan for brugeren.
• actual_end_date – Hvornår målet faktisk var gennemført. Der kan være afvigelser fra træningsplanen, så vi skal bruge denne kolonne til at fange den faktiske slutdato. Appen kan give mulighed for at springe en dag over eller for at fremskynde træningsplanen med en dag eller deromkring. I sådanne tilfælde er actual_end_date vil helt sikkert afvige fra expected_end_date .

I "transition_plan ” tabel:

• is_complete – Angiver, om en aktivitet blev sprunget over, ikke er startet endnu eller er afsluttet. Den vil indeholde et 'Y', 'N' eller et tomt.
• start_timestamp – Tidsstemplet, når en aktivitet blev startet.
• end_timestamp – Tidsstemplet for, hvornår aktiviteten blev afsluttet.

Da vi forstår, at der kan være huller i træningen (på grund af sygdom, skade eller manglende motivation), indeholder denne tabel tre forskellige datoer:

• original_calendar_date – En kalenderdato, der angiver, hvornår en aktivitet skal udføres. Denne værdi udfyldes, når appen genererer en træningsplan.
• planned_calendar_date – Til at begynde med forbliver denne kolonne tom. En dato udfyldes, efterhånden som der foretages en ændring i træningsplanen.
• actual_calendar_date – Denne kolonne udfyldes, så snart brugeren markerer en aktivitet som fuldført. Dette er den dato, hvor aktiviteten faktisk er afsluttet.

planned_calendar_date og actual_calendar_date kolonner er nullbare; de er ikke befolket under den indledende plangenerering.

Yderligere tre kolonner i denne tabel er nullable, så denne datamodel kan håndtere alle mulige scenarier for en igangværende aktivitet. Her er nogle eksempler:

• En aktivitet, der ikke er startet endnu –
• is_complete – NULL
• start_timestamp – NULL
• end_timestamp - NULL
• En aktivitet, der er startet, men ikke afsluttet –
• er_fuldstændig – NULL
• starttidsstempel – VALUE
• sluttidsstempel - NULL
• En aktivitet, der blev sprunget over –
• er_fuldstændig – 'N'
• starttidsstempel – NULL
• sluttidsstempel - NULL
• En aktivitet, der blev gennemført –
• er_komplet – 'Y'
• starttidsstempel –VÆRDI
• sluttidsstempel - VALUE

Hvad ville du ændre ved denne datamodel?

Træning til et maraton handler om mere end bare motion. Marathonløbere er nødt til at tilpasse alle aspekter af deres livsstil, startende fra deres daglige madindtag, deres mentale styrke og endda mængden af ​​søvn, de får.

En effektiv app skal være i stand til at organisere, planlægge og spore alle aspekter af træning. Tager vores datamodel højde for alle disse aspekter? Hvilke ændringer er nødvendige for at gøre det til en fuldgyldig træningsapp?

Del venligst dine synspunkter og forslag i kommentarfeltet.