En datamodell för Marathon Training App

Drömmer du om att springa ett maraton? Låt oss titta på datamodellen för en app som kan ta dig från lat soffpotatis till maratonåkare.

Vad behöver du för att springa ett maraton? Du behöver entusiasm och beslutsamhet. Ett par bra löparskor. Och mycket fysisk träning! Låt oss säga att du har en app som hjälper dig att gå från nybörjare till maratonlöpare. Hur skulle datamodellen se ut?

I den här artikeln kommer vi att undersöka datamodellen bakom en maratonträningsapp.

Vad ska en Marathon Training App göra?

Varje träningsapp kommer vanligtvis med några alternativ. I det här fallet förväntar vi oss att appen stöder träning för olika typer av löpningar (ett helmaraton, ett halvmaraton, ett 5k) och för olika träningsscheman (allt från åtta till 24 veckor). Appen skulle fånga dina grundläggande detaljer, inklusive ålder, kön och aktuell löpstatus. Det bör också tillåta dig att sätta ett mål och ett startdatum. Appen kommer att använda denna information för att skapa en träningsplan för ditt kommande löparrangemang. Ju mer du gör framsteg med din plan, desto närmare ditt mål skulle du vara.

Låt oss gå igenom de viktigaste kraven för denna app. Det bör:

Fånga en användares namn, ålder, kön etc. under registreringsprocessen.
Visning av en lista över mål (t.ex. promenader, löpning, cykling, etc.) med tillhörande måldistans.
Tillåt användare att ställa in ett mål, målavstånd och startdatum.
Skapa en detaljerad personlig träningsplan för enskilda användare som tar hänsyn till deras ålder, kön och nuvarande konditionsnivå. Denna utbildningsplan innehåller:

Aktiviteter, som att springa.
Datum för aktiviteter som ska startas och slutföras.
Avstånd (t.ex. löpning i 5 kilometer)
Föreslagen takt (t.ex. 5 km/h) och ungefärliga sluttider (1 timme).
Vilodagar. Det är viktigt att bygga in dessa i en fysisk konditionsplan.
Slutdatum för mål, t.ex. när användaren skulle vara redo att köra sin valda händelse.

Fånga utvecklingen av träningsplanaktiviteter, inklusive när (eller om) varje aktivitet startades, hur nära användaren är att slutföra den och när den var klar.
Justera träningsplanerna efter behov. Till exempel kan en löpare bli sjuk eller skadad och kanske inte följa sitt ursprungliga schema; i så fall måste den ursprungliga planen utökas eller ändras.
Fånga titlar som användaren tjänat in. I löpning baseras dessa på framgångsrikt genomförda evenemang, t.ex. 5K-löpare, 10K-löpare, halvmaratonlöpare eller helmaratonlöpare. Dessa titlar tjänas in i takt med att löpare utvecklas med sin träning.

Datamodellen

Datamodellen som stöder en sådan app består av tre ämnesområden:

Användare och titlar
Mål och aktiviteter
Användarmål och övergångar

Vi kommer att diskutera varje ämnesområde i den ordning det är listat.

Ämnesområde 1:Användare och titlar

Denna app kommer att användas av mer än bara nybörjare. Löparevent är mycket krävande och ansträngande; även rutinerade maratonåkare behöver träna för kommande maratonlopp. Ingen springer ett helmaraton över natten eller efter en enda träningsbana. Det är en gradvis process.

Som vi nämnde tidigare tjänar löpare olika titlar baserat på evenemang av olika längd. När en löpare går framåt i sin träning kommer de att kunna springa längre evenemang och tjäna fler titlar. Tabellerna i detta ämnesområde är definierade med detta i åtanke.

"registered_user ”-tabellen innehåller grundläggande information om användare. Dessa uppgifter fångas upp under registreringsprocessen. Detta inkluderar två nyckelfaktorer som påverkar träningsplanens design:ålder (härledd från date_of_birth ) och kön. Dessa är viktiga eftersom olika kön och åldersgrupper tränar olika, även om de tävlar i samma tävling. En 19-årig pojke kommer att behöva en annan träningsplan än en 45-årig kvinna.

"running_event ”-tabellen lagrar en lista över alla officiella löparevenemang. Detta kan innefatta internationella evenemang. Alla fält är självförklarande.

"title ”-tabellen lagrar i första hand löparnas ”referenser”:sträckan de tillryggalägger och tiden det tog under ett officiellt evenemang. Viktiga punkter om titlar och deras distributioner är:

Varje maratonevenemang har sin egen lista med titlar.
Vanligtvis ges dessa titlar till löpare i slutet av en milstolpe (på en bana) eller när de slutar (t.ex. korsar mållinjen på ett maraton).
Samma titel kan ges till flera löpare, förutsatt att alla uppfyller dess villkor. Dessa inkluderar (1) det minsta avståndet som ska tillryggaläggas och (2) den maximala tiden för att tillryggalägga detta avstånd.
Om titlar definieras vid mellanliggande milstolpar på en bana, behåller löparen den enda högsta titeln de har tjänat.

Med denna förståelse av rubriker bör kolumnerna i tabellen "titel" vara självförklarande. ☺

"user_title ”-tabellen lagrar alla titlar som användare har tjänat. Den enda skillnaden är att här fångar vi löparens tid i sekunder istället för minuter.

Ämnesområde 2:Mål och aktiviteter

Ingen kan motivera dig att springa ett maraton om du inte vill. Du måste arbeta upp din egen iver. Ett sätt att hålla sig motiverad är att sätta upp och nå mål. De följande två ämnesområdena handlar om att sätta upp och uppfylla mål.

Först ska vi titta på Goals and Activities ämnesområde. Den innehåller tre tabeller:

"goal ” innehåller information om målen som definierats i appen.
"activity ” lagrar information om olika typer av träningsaktiviteter, som promenader, snabba promenader, löpning, simning, cykling, etc.
"goal_activity ” lagrar information om aktiviteter som behövs för att uppnå ett mål.

Det är viktigt att förstå att samma mål nås på olika sätt av olika användare. Återigen kommer en 15-årig tjej att ha en träningsplan och en uppsättning aktiviteter som är annorlunda än en 40-årig man. Med tanke på dessa fakta har vi lagt följande kolumner i "goal ” tabell:

distance_to_run – Distansen en löpare ska kunna springa i slutet av detta mål.
target_time_in_min – Den maximala tid som krävs för att klara detta avstånd.
gender – Vilket kön detta mål är för.

Ett mål kan skapas för en åldersgrupp, säg 15-20 eller 35-40. Hur vi tränar förändras lite när vi åldras, så vi har lagt till ytterligare två kolumner i "goal ”:

starting_age – Minimiåldern för detta mål.
closing_age – Den maximala åldern för detta mål.

Människor kan drömma stort, men det enda sättet att verkligen få saker att hända är att utvecklas gradvis. Denna app begränsar hur användare gör mål; de måste slutföra mindre, uppnåeliga mål innan de försöker för de större. En soffpotatis kan drömma om att springa hela 26,2 mil\42,2 km maraton, men de bör börja jobba mot en 5K-löpning först.

"goal Tabellen hanterar begränsningar med hjälp av följande kolumner:

current_run_distance_per_week – Minsta löpsträcka som uppnås innan en användare kan sätta ett visst mål; och
current_min_title_id – Den minsta titeln användare måste ha för att sätta detta mål.

Om dessa förutsättningar inte är uppfyllda kommer det målet inte att vara tillgängligt för användaren. Men båda dessa kolumner är nullbara; det kommer att finnas några mål som inte har några förutsättningskrav för kondition.

Låt oss gå vidare till "goal_activity ” tabell. De flesta av dessa kolumner tjänar ett uppenbart syfte. Jag kommer bara att kommentera två, börjar med seq_of_day kolumn. Detta är en talkolumn som innehåller värden som anger dagen då en aktivitet ska utföras. Uppenbarligen börjar denna sekvens från 1 för alla mål. Det kan aldrig vara NOLL eller NULL. Siffror kanske inte är på varandra följande för ett mål; detta skulle innebära att vilodagar har fastställts. Dagar för vilka det inte finns några poster i denna tabell är faktiskt vilodagar.

Därefter har vi distance_to_cover kolumn. Detta är nullbart, eftersom det finns aktiviteter (som yoga, stretching och tyngdlyftning) där avståndet inte spelar någon roll. Efter att ha sagt detta, lägg märke till att min_pace och max_pace kolumner i "activity ”-tabeller är också nullbara.

Ämnesområde #3:Användarmål och övergångar

Detta ämnesområde handlar om användarskapade mål och appskapade aktivitetsplaner. Faktiska datum är viktiga här, och seq_of_day kolumnen i "goal_activity ”-tabellen spelar en viktig roll vid rendering av plandatum, liksom start_date valt av användarna för deras mål.

"user_goal ” och “transition_plan ” tabeller är båda oftast självförklarande. Det finns bara några kolumner som vi bör lyfta fram.

I "user_goal ” tabell:

is_active – Visar om en användare fortfarande går vidare med detta mål. Alla pågående mål skulle ha ett "Y" i den här kolumnen. Den här kolumnen gör det möjligt för appen att begränsa användare till att ställa in ett mål i taget.
create_date – Datumet då ett mål skapades.
start_date – Datumet då ett mål faktiskt startade. Det kanske inte är samma som create_date.
expected_end_date – Ett slutdatum, beräknat av appen efter att den gjort en övergångsplan för användaren.
actual_end_date – När målet faktiskt var avklarat. Det kan finnas avvikelser från utbildningsplanen, så vi behöver den här kolumnen för att fånga det faktiska slutdatumet. Appen kan ge ett alternativ att hoppa över en dag eller att flytta fram träningsschemat med någon dag. I sådana fall, actual_end_date kommer säkert att skilja sig från expected_end_date .

I "transition_plan ” tabell:

is_complete – Indikerar om en aktivitet hoppades över, inte har påbörjats ännu eller är avslutad. Den kommer att hålla ett "Y", "N" eller ett tomt.
start_timestamp – Tidsstämpeln när en aktivitet startade.
end_timestamp – Tidsstämpeln när aktiviteten slutfördes.

Eftersom vi förstår att det kan finnas luckor i träningen (på grund av sjukdom, skada eller bristande motivation), innehåller den här tabellen tre olika datum:

original_calendar_date – Ett kalenderdatum som anger när en aktivitet behöver utföras. Detta värde fylls i när appen genererar en träningsplan.
planned_calendar_date – Till en början förblir denna kolumn tom. Ett datum fylls i när en ändring görs i träningsplanen.
actual_calendar_date – Den här kolumnen fylls i så snart användaren markerar en aktivitet som slutförd. Detta är datumet då aktiviteten faktiskt är klar.

planned_calendar_date och actual_calendar_date kolumner är nullbara; de är inte befolkade under den första plangenereringen.

Ytterligare tre kolumner i den här tabellen är nullbara så att denna datamodell kan hantera alla möjliga scenarier för en pågående aktivitet. Här är några exempel:

En aktivitet som inte har startat ännu –

is_complete – NULL
start_timestamp – NULL
end_timestamp - NULL

En aktivitet som startades men inte slutfördes –

är_fullständig – NULL
start_tidsstämpel – VALUE
sluttidsstämpel - NULL

En aktivitet som hoppades över –

är_fullständig – 'N'
start_tidsstämpel – NULL
sluttidsstämpel - NULL

En aktivitet som slutfördes –

är_fullständig – 'Y'
starttidsstämpel –VÄRDE
sluttidsstämpel - VALUE

Vad skulle du ändra med den här datamodellen?

Träning inför ett maraton handlar om mer än bara träning. Maratonlöpare måste justera varje aspekt av sin livsstil, med början från deras dagliga matintag, deras mentala styrka och till och med mängden sömn de får.

En effektiv app måste kunna organisera, planera och spåra alla aspekter av träning. Tillgodoser vår datamodell alla dessa aspekter? Vilka ändringar krävs för att göra det till en fullfjädrad träningsapp?

Vänligen dela dina synpunkter och förslag i kommentarsfältet.