Un modèle de données d'application d'entraînement Marathon

Vous rêvez de courir un marathon ? Examinons le modèle de données d'une application qui pourrait vous faire passer du paresseux du canapé au marathonien.

De quoi avez-vous besoin pour courir un marathon ? Vous aurez besoin d'enthousiasme et de détermination. Une bonne paire de chaussures de course. Et beaucoup d'entraînement physique ! Disons que vous avez une application qui vous aide à passer de coureur novice à finisseur de marathon. À quoi ressemblerait le modèle de données ?

Dans cet article, nous examinerons le modèle de données derrière une application d'entraînement de marathon.

Que devrait faire une application d'entraînement au marathon ?

Toute application de formation est généralement livrée avec certaines options. Dans ce cas, nous nous attendons à ce que l'application prenne en charge l'entraînement pour différents types de courses (un marathon complet, un semi-marathon, un 5 km) et pour différents programmes d'entraînement (de huit à 24 semaines). L'application capturera vos informations de base, y compris l'âge, le sexe et l'état de fonctionnement actuel. Il devrait également vous permettre de fixer un objectif et une date de début. L'application utilisera ces informations pour créer un plan d'entraînement pour votre prochain événement de course à pied. Plus vous progressez dans votre plan, plus vous vous rapprochez de votre objectif.

Passons en revue les principales exigences de cette application. Il devrait :

Capturez le nom, l'âge, le sexe, etc. d'un utilisateur pendant le processus d'inscription.
Affichage d'une liste d'objectifs (par exemple, marche, course, vélo, etc.) avec une distance cible associée.
Autoriser les utilisateurs à définir un objectif, une distance cible et une date de début
Créez un plan d'entraînement personnel détaillé pour chaque utilisateur en tenant compte de son âge, de son sexe et de son niveau de forme physique actuel. Ce plan de formation comprend :

Activités, telles que la course.
Dates de début et de fin des activités.
Distances (par exemple, courir pendant 5 kilomètres)
Allure suggérée (par exemple, 5 km/h) et temps de réalisation approximatifs (1 heure).
Jour de repos. Il est important de les intégrer dans un plan de conditionnement physique.
Date de fin de l'objectif, par ex. lorsque l'utilisateur serait prêt à exécuter l'événement de son choix.

Capturer la progression des activités du plan de formation, y compris quand (ou si) chaque activité a commencé, à quel point l'utilisateur est sur le point de la terminer et quand elle a été terminée.
Ajuster les plans de formation selon les besoins. Par exemple, un coureur peut tomber malade ou se blesser et ne pas suivre son horaire initial; dans ce cas, le plan d'origine devra être prolongé ou modifié.
Capturez les titres gagnés par l'utilisateur. En course à pied, ceux-ci sont basés sur des événements terminés avec succès, par ex. Coureur de 5 km, coureur de 10 km, coureur de semi-marathon ou coureur de marathon complet. Ces titres sont gagnés au fur et à mesure que les coureurs progressent dans leur entraînement.

Le modèle de données

Le modèle de données prenant en charge une telle application se compose de trois domaines :

Utilisateurs et titres
Objectifs et activités
Objectifs utilisateur et transitions

Nous aborderons chaque sujet dans l'ordre dans lequel il est répertorié.

Domaine 1 :Utilisateurs et titres

Cette application sera utilisée par plus que des coureurs novices. Les événements de course à pied sont très exigeants et ardus; même les marathoniens chevronnés doivent s'entraîner pour les prochains marathons. Personne ne court un marathon complet du jour au lendemain ou après un seul entraînement. C'est un processus graduel.

Comme nous l'avons mentionné précédemment, les coureurs gagnent divers titres en fonction d'événements de différentes longueurs. Au fur et à mesure qu'un coureur progresse dans son entraînement, il pourra organiser des événements plus longs et gagner plus de titres. Les tableaux de ce domaine sont définis dans cet esprit.

Le "registered_user ” Le tableau contient des informations de base sur les utilisateurs. Ces détails sont capturés au cours du processus d'inscription. Cela inclut deux facteurs clés qui influencent la conception du plan de formation :l'âge (dérivé de date_of_birth ) et le sexe. Ceux-ci sont importants parce que les différents sexes et groupes d'âge s'entraînent différemment, même s'ils participent à la même épreuve. Un garçon de 19 ans aura besoin d'un plan d'entraînement différent de celui d'une femme de 45 ans.

Le "running_event ” Le tableau stocke une liste de tous les événements de course officiels. Cela pourrait inclure des événements internationaux. Tous les champs sont explicites.

Le "title Le tableau stocke principalement les "informations d'identification" des coureurs :la distance qu'ils parcourent et le temps qu'ils ont mis lors d'un événement officiel. Les points clés concernant les titres et leurs distributions sont :

Chaque marathon a sa propre liste de titres.
Généralement, ces titres sont attribués aux coureurs à la fin d'un jalon (sur une piste) ou lorsqu'ils finissent (par exemple, franchir la ligne d'arrivée d'un marathon).
Le même titre peut être attribué à plusieurs coureurs, à condition qu'ils remplissent tous ses conditions. Celles-ci incluent (1) la distance minimale à parcourir et (2) le temps maximal pour parcourir cette distance.
Si des titres sont définis à des étapes intermédiaires sur une piste, le coureur conserve le seul titre le plus élevé qu'il a gagné.

Avec cette compréhension des titres, les colonnes du tableau "titre" devraient être explicites. ☺

Le "user_title ” La table stocke tous les titres que les utilisateurs ont gagnés. La seule différence est qu'ici nous capturons le temps du coureur en secondes au lieu de minutes.

Domaine 2 :objectifs et activités

Personne ne peut vous motiver à courir un marathon si vous ne le souhaitez pas. Vous devez travailler votre propre zèle. Une façon de rester motivé est de se fixer et d'atteindre des objectifs. Les deux domaines suivants traitent de l'établissement et de l'atteinte d'objectifs.

Tout d'abord, nous examinerons les Goals and Activities Domaine. Il contient trois tables :

"goal ” contient des détails sur les objectifs définis dans l'application.
"activity ” stocke des informations sur divers types d'activités d'entraînement, comme la marche, la marche rapide, la course, la natation, le vélo, etc.
"goal_activity ” stocke des détails sur les activités nécessaires pour atteindre un objectif.

Il est important de comprendre que le même objectif est atteint différemment par différents utilisateurs. Encore une fois, une fille de 15 ans aura un plan d'entraînement et un ensemble d'activités différents de ceux d'un homme de 40 ans. Compte tenu de ces faits, nous avons mis les colonnes suivantes dans le "goal ” tableau :

distance_to_run – La distance qu'un coureur devrait pouvoir parcourir à la fin de cet objectif.
target_time_in_min – Le temps maximum nécessaire pour parcourir cette distance.
gender – À quel sexe cet objectif est-il destiné ?

Un objectif peut être créé pour un groupe d'âge, disons 15-20 ou 35-40. La façon dont nous nous entraînons change un peu avec l'âge, nous avons donc ajouté deux colonnes supplémentaires à "goal ” :

starting_age - L'âge minimum pour cet objectif.
closing_age – L'âge maximum pour cet objectif.

Les gens peuvent rêver grand, mais la seule façon de vraiment faire bouger les choses est de progresser progressivement. Cette application limite la façon dont les utilisateurs se fixent des objectifs ; ils doivent atteindre des objectifs plus petits et réalisables avant d'essayer les plus grands. Une patate de canapé peut rêver de courir un marathon complet de 26,2 miles \ 42,2 km, mais elle devrait commencer par travailler pour une course de 5 km.

Le "goal ” table gère les restrictions au moyen des colonnes suivantes :

current_run_distance_per_week – La distance de course minimale atteinte avant qu'un utilisateur puisse se fixer un certain objectif; et
current_min_title_id – Le titre minimum que les utilisateurs doivent détenir pour définir cet objectif.

Si ces conditions préalables ne sont pas remplies, cet objectif ne sera pas disponible pour l'utilisateur. Cependant, ces deux colonnes acceptent les valeurs NULL ; certains objectifs n'auront pas d'exigences préalables en matière de condition physique.

Passons au "goal_activity " table. La plupart de ces colonnes ont un but évident. Je vais juste en commenter deux, en commençant par le seq_of_day colonne. Il s'agit d'une colonne numérique contenant des valeurs indiquant le jour où une activité doit être effectuée. Évidemment, cette séquence commence à partir de 1 pour n'importe quel but. Il ne peut jamais être ZERO ou NULL. Les numéros ne peuvent pas être consécutifs pour un but; cela signifierait que des jours de repos ont été fixés. Les jours pour lesquels il n'y a pas d'enregistrements dans ce tableau sont en fait des jours de repos.

Ensuite, nous avons la distance_to_cover colonne. Ceci est nullable, car il existe des activités (comme le yoga, les étirements et l'haltérophilie) dans lesquelles la distance n'a pas d'importance. Cela dit, notez que le min_pace et max_pace colonnes dans le champ "activity ” table sont également nullables.

Domaine n° 3 :Objectifs et transitions de l'utilisateur

Ce domaine concerne les objectifs créés par l'utilisateur et les plans d'activité créés par l'application. Les dates réelles sont importantes ici, et le seq_of_day colonne dans la colonne "goal_activity ” la table joue un rôle majeur dans le rendu des dates du plan, tout comme la start_date choisis par les utilisateurs pour leurs objectifs.

Le "user_goal » et « transition_plan ” Les tableaux sont tous les deux pour la plupart explicites. Il y a juste quelques colonnes que nous devons mettre en évidence.

Dans le "user_goal ” tableau :

is_active – Indique si un utilisateur progresse toujours sur cet objectif. Tous les objectifs en cours auront un « Y » dans cette colonne. Cette colonne permet à l'application de limiter les utilisateurs à la définition d'un objectif à la fois.
create_date – La date à laquelle un objectif a été créé.
start_date – La date à laquelle un objectif a effectivement commencé. Il se peut que ce ne soit pas le même que le create_date.
expected_end_date – Une date de fin, calculée par l'application après avoir établi un plan de transition pour l'utilisateur.
actual_end_date – Quand l'objectif a été atteint. Il peut y avoir des écarts par rapport au plan de formation, nous avons donc besoin de cette colonne pour saisir la date de fin réelle. L'application peut donner la possibilité de sauter une journée ou d'avancer le programme d'entraînement d'un jour ou deux. Dans de tels cas, la actual_end_date sera certainement différent de la expected_end_date .

Dans le "transition_plan ” tableau :

is_complete – Indique si une activité a été ignorée, n'a pas encore commencé ou est terminée. Il contiendra un "Y", un "N" ou un espace.
start_timestamp – L'horodatage du démarrage d'une activité.
end_timestamp – L'horodatage de la fin de l'activité.

Étant donné que nous comprenons qu'il peut y avoir des interruptions d'entraînement (en raison d'une maladie, d'une blessure ou d'un manque de motivation), ce tableau contient trois dates différentes :

original_calendar_date – Une date calendaire indiquant quand une activité doit être effectuée. Cette valeur est renseignée lorsque l'application génère un plan d'entraînement.
planned_calendar_date – Initialement, cette colonne reste vide. Une date est renseignée au fur et à mesure de la modification du plan de formation.
actual_calendar_date – Cette colonne est renseignée dès que l'utilisateur marque une activité comme terminée. Il s'agit de la date à laquelle l'activité est réellement terminée.

La planned_calendar_date et actual_calendar_date les colonnes acceptent les valeurs NULL ; ils ne sont pas renseignés lors de la génération initiale du plan.

Trois autres colonnes de ce tableau acceptent les valeurs NULL afin que ce modèle de données puisse gérer tous les scénarios possibles pour une activité en cours. Voici quelques exemples :

Une activité qui n'a pas encore commencé –

is_complete – NUL
start_timestamp – NUL
end_timestamp - NUL

Une activité qui a commencé mais n'est pas terminée –

is_complete – NULL
start_timestamp – VALUE
end_timestamp - NULL

Une activité qui a été ignorée :

est_complet - 'N'
start_timestamp – NULL
end_timestamp - NULL

Une activité terminée :

est_complet - 'O'
start_timestamp –VALUE
end_timestamp - VALUE

Que changeriez-vous à propos de ce modèle de données ?

S'entraîner pour un marathon, c'est bien plus qu'un simple exercice physique. Les marathoniens doivent modifier chaque aspect de leur mode de vie, à commencer par leur apport alimentaire quotidien, leur force mentale et même la quantité de sommeil qu'ils obtiennent.

Une application efficace doit pouvoir organiser, planifier et suivre tous les aspects de la formation. Notre modèle de données répond-il à tous ces aspects ? Quels changements sont nécessaires pour en faire une application de formation à part entière ?

S'il vous plaît partager vos points de vue et suggestions dans la section des commentaires.