Модел на данни за приложение за маратонско обучение

Мечтаете ли да бягате маратон? Нека разгледаме модела на данни за приложение, което би могло да ви отведе от мързелив диван до маратонец.

Какво ви е необходимо, за да бягате маратон? Ще ви трябва ентусиазъм и решителност. Добър чифт маратонки. И много физическа подготовка! Да приемем, че имате приложение, което ви помага да преминете от начинаещ бегач към маратонец. Как би изглеждал моделът на данни?

В тази статия ще разгледаме модела на данни зад приложение за обучение на маратон.

Какво трябва да прави приложението за маратонско обучение?

Всяко приложение за обучение обикновено идва с някои опции. В този случай бихме очаквали приложението да поддържа тренировки за различни видове бягания (пълен маратон, полумаратон, 5k) и за различни тренировъчни графици (от осем до 24 седмици). Приложението ще улови основните ви данни, включително възраст, пол и текущо състояние на работа. Освен това трябва да ви позволи да зададете цел и начална дата. Приложението ще използва тази информация, за да създаде тренировъчен план за предстоящото ви събитие по бягане. Колкото повече напредвате с плана си, толкова по-близо ще сте до целта си.

Нека да разгледаме основните изисквания на това приложение. Трябва:

Заснемате името, възрастта, пола и т.н. на потребителя по време на процеса на регистрация.
Показване на списък с цели (напр. ходене, бягане, колоездене и др.) със свързано целево разстояние.
Позволете на потребителите да задават цел, целево разстояние и начална дата.
Създайте подробен личен план за обучение за отделни потребители, който взема предвид тяхната възраст, пол и текущо ниво на фитнес. Този план за обучение включва:

Дейности, като бягане.
Дати за започване и завършване на дейностите.
Разстояния (напр. бягане на 5 километра)
Предложено темпо (напр. 5 км/ч) и приблизително време за завършване (1 час).
Дни за почивка. Важно е да ги вградите в план за физическа подготовка.
Крайна дата на целта, напр. когато потребителят ще бъде готов да стартира избраното от него събитие.

Уловете напредъка на дейностите на плана за обучение, включително кога (или ако) е започнала всяка дейност, колко близо е потребителят до завършването й и кога е завършена.
Коригирайте плановете за обучение според нуждите. Например, бегач може да се разболее или да се нарани и може да не следва първоначалния си график; в този случай първоначалният план ще трябва да бъде разширен или променен.
Заснемане на заглавия, спечелени от потребителя. При бягане те се основават на успешно завършени събития, напр. 5K бегач, 10K бегач, полумаратонец или пълен маратонец. Тези титли се печелят, докато бегачите напредват с обучението си.

Моделът на данните

Моделът на данни, поддържащ такова приложение, се състои от три предметни области:

Потребители и заглавия
Цели и дейности
Потребителски цели и преходи

Ще обсъдим всяка тематична област в реда, в който е изброен.

Тема област 1:Потребители и заглавия

Това приложение ще се използва не само от начинаещи бегачи. Събитията по бягане са много взискателни и натоварващи; дори опитните маратонци трябва да тренират за предстоящи маратони. Никой не бяга пълен маратон за една нощ или след единичен тренировъчен курс. Това е постепенен процес.

Както споменахме по-рано, бегачите печелят различни титли въз основа на събития с различна продължителност. Докато бегачът напредва в обучението си, те ще могат да провеждат по-дълги събития и да печелят повече титли. Таблиците в тази предметна област са определени с това предвид.

„registered_user ” таблицата съдържа основни подробности за потребителите. Тези подробности се улавят по време на процеса на регистрация. Това включва два ключови фактора, които влияят върху дизайна на тренировъчния план:възраст (извлечена от date_of_birth ) и пол. Те са важни, защото различните полове и възрастови групи тренират по различен начин, дори ако се състезават в едно и също събитие. 19-годишно момче ще се нуждае от различен тренировъчен план от 45-годишна жена.

„running_event ” таблицата съхранява списък с всички официални събития. Това може да включва международни събития. Всички полета се обясняват сами.

„title ” таблицата съхранява предимно „идентификационните данни“ на бегачите:разстоянието, което изминават, и времето, необходимо по време на официално събитие. Ключови точки за заглавията и тяхното разпространение са:

Всяко маратонско събитие има свой собствен списък със заглавия.
Обикновено тези титли се дават на бегачи в края на етап (на писта) или когато завършат (напр. пресичат финалната линия на маратон).
Едно и също заглавие може да бъде дадено на множество бегачи, при условие че всички отговарят на условията. Те включват (1) минималното разстояние, което трябва да се измине, и (2) максималното време за изминаване на това разстояние.
Ако заглавията са определени на междинни етапи на пистата, бегачът запазва единственото най-високо заглавие, което е спечелил.

С това разбиране на заглавията, колоните в таблицата „заглавие“ трябва да са разбираеми. ☺

„user_title ” таблицата съхранява всички заглавия, които потребителите са спечелили. Единствената разлика е, че тук улавяме времето на бегача в секунди вместо минути.

Предметна област 2:Цели и дейности

Никой не може да те мотивира да тичаш маратон, ако не искаш. Трябва да проявите собственото си усърдие. Един от начините да останете мотивирани е да си поставите и постигнете цели. Следващите две предметни области се занимават с поставяне и постигане на цели.

Първо, ще разгледаме Goals and Activities предметна област. Съдържа три таблици:

„goal ” съдържа подробности за целите, определени в приложението.
„activity ” съхранява информация за различни видове тренировъчни дейности, като ходене, бързо ходене, бягане, плуване, колоездене и др.
„goal_activity ” съхранява подробности за дейности, необходими за постигане на цел.

Важно е да се разбере, че една и съща цел се постига по различен начин от различните потребители. Отново 15-годишно момиче ще има тренировъчен план и набор от дейности, които са различни от 40-годишен мъж. Предвид тези факти сме поставили следните колони в „goal ” таблица:

distance_to_run – Разстоянието, което бегачът трябва да може да избяга в края на тази цел.
target_time_in_min – Максималното време, необходимо за изминаване на това разстояние.
gender – За кой пол е тази цел.

Може да се създаде цел за възрастова група, да речем 15-20 или 35-40. Начинът, по който тренираме, се променя малко с напредването на възрастта, така че добавихме още две колони към „goal ”:

starting_age – Минималната възраст за тази цел.
closing_age – Максималната възраст за тази цел.

Хората могат да мечтаят голямо, но единственият начин наистина да се случат нещата е да се напредва постепенно. Това приложение ограничава начина, по който потребителите си поставят цели; те трябва да изпълнят по-малки, постижими цели, преди да опитат по-големите. Един диван може да мечтае да пробяга пълни 26,2 мили\42,2 км маратон, но първо трябва да започне да работи за бягане на 5K.

„goal ” таблицата обработва ограничения посредством следните колони:

current_run_distance_per_week – Постигнатото минимално разстояние за бягане, преди потребителят да може да си постави определена цел; и
current_min_title_id – Минималното заглавие, което потребителите трябва да притежават, за да зададат тази цел.

Ако тези предпоставки не са изпълнени, тази цел няма да бъде достъпна за потребителя. И двете колони обаче са нулеви; ще има някои цели, които нямат предварителни изисквания за фитнес.

Нека да преминем към „goal_activity ” таблица. Повечето от тези колони служат за очевидна цел. Ще коментирам само две, като се започне с seq_of_day колона. Това е числова колона, която съдържа стойности, които означават деня, в който трябва да се извърши дадена дейност. Очевидно тази последователност започва от 1 за всяка цел. Никога не може да бъде НУЛА или НУЛА. Числата може да не са последователни за гол; това би означавало, че са определени почивни дни. Дните, за които няма записи в тази таблица, всъщност са почивни дни.

След това имаме distance_to_cover колона. Това е нулево, тъй като има дейности (като йога, стречинг и вдигане на тежести), при които разстоянието няма значение. След като каза това, забележете, че min_pace и max_pace колони в „activity ” също са нулеви.

Предметна област №3:Потребителски цели и преходи

Тази предметна област е свързана с цели, създадени от потребителите, и създадени от приложения планове за дейност. Тук са важни действителните дати и seq_of_day колона в „goal_activity ” таблицата играе основна роля при изобразяването на планови дати, както и start_date избрани от потребителите за техните цели.

„user_goal ” и „transition_plan ” и двете таблици обикновено се обясняват сами. Има само няколко колони, които трябва да подчертаем.

В „user_goal ” таблица:

is_active – Показва дали потребителят все още напредва към тази цел. Всички текущи цели ще имат „Y“ в тази колона. Тази колона позволява на приложението да ограничава потребителите да задават една цел в даден момент.
create_date – Датата, на която е създадена цел.
start_date – Датата, на която действително е започнал гол. Може да не е същото като create_date.
expected_end_date – Крайна дата, изчислена от приложението, след като направи план за преход за потребителя.
actual_end_date – Когато целта наистина беше изпълнена. Възможно е да има отклонения от плана за обучение, така че тази колона ни е необходима, за да уловим действителната крайна дата. Приложението може да даде опция за пропускане на ден или за напредване на графика за обучение с около ден. В такива случаи actual_end_date със сигурност ще се различава от expected_end_date .

В „transition_plan ” таблица:

is_complete – Показва дали дадена дейност е била пропусната, все още не е започнала или е завършена. Ще съдържа „Y“, „N“ или празно.
start_timestamp – клеймото за време, когато е започнала дейност.
end_timestamp – Клеймото за време, когато дейността е завършена.

Тъй като разбираме, че може да има пропуски в обучението (поради заболяване, нараняване или липса на мотивация), тази таблица съдържа три различни дати:

original_calendar_date – Календарна дата, обозначаваща кога трябва да се извърши дадена дейност. Тази стойност се попълва, когато приложението генерира план за обучение.
planned_calendar_date – Първоначално тази колона остава празна. Датата се попълва, когато и когато се направи промяна в плана за обучение.
actual_calendar_date – Тази колона се попълва веднага щом потребителят маркира дейност като завършена. Това е датата, на която дейността действително е завършена.

planned_calendar_date и actual_calendar_date колоните са нулеви; те не се попълват по време на първоначалното генериране на план.

Други три колони в тази таблица са нулеви, така че този модел на данни може да обработва всички възможни сценарии за текуща дейност. Ето няколко примера:

Дейност, която все още не е започнала –

is_complete – NULL
start_timestamp – NULL
end_timestamp - NULL

Дейност, която е започнала, но не е завършена –

е_завършено – NULL
start_timestamp – VALUE
end_timestamp – NULL

Дейност, която е била пропусната –

е_завършено – „N“
start_timestamp – NULL
end_timestamp – NULL

Завършена дейност –

е_завършено – „Y“
start_timestamp –VALUE
end_timestamp – VALUE

Какво бихте променили относно този модел на данни?

Обучението за маратон е нещо повече от просто упражнение. Маратонците трябва да променят всеки аспект от начина си на живот, като се започне от ежедневния прием на храна, умствената им сила и дори количеството сън, което получават.

Едно ефективно приложение трябва да може да организира, планира и проследява всички аспекти на обучението. Нашият модел на данни обслужва ли всички тези аспекти? Какви промени са необходими, за да стане пълноценно приложение за обучение?

Моля, споделете вашите мнения и предложения в секцията за коментари.