マラソントレーニングアプリのデータモデル

マラソンをすることを夢見ていますか？怠惰なカウチポテトからマラソンに連れて行くことができるアプリのデータモデルを見てみましょう。

マラソンを走るには何が必要ですか？熱意と決意が必要です。ランニングシューズの良いペア。そしてたくさんの体育！初心者ランナーからマラソンフィニッシャーに移行するのに役立つアプリがあるとします。データモデルはどのようになりますか？

この記事では、マラソントレーニングアプリの背後にあるデータモデルを検証します。

マラソントレーニングアプリは何をすべきですか？

通常、トレーニングアプリにはいくつかのオプションがあります。この場合、アプリはさまざまな種類の実行（フルマラソン、ハーフマラソン、5k）およびさまざまなトレーニングスケジュール（8〜24週間）のトレーニングをサポートすることが期待されます。このアプリは、年齢、性別、現在の実行状況など、基本的な詳細をキャプチャします。また、目標と開始日を設定できるようにする必要があります。アプリはこの情報を使用して、今後のランニングイベントのトレーニングプランを作成します。計画を進めれば進めるほど、目標に近づくことができます。

このアプリの主な要件を見ていきましょう。すべきこと：

登録プロセス中にユーザーの名前、年齢、性別などを取得します。
目標距離（ウォーキング、ランニング、サイクリングなど）と関連する目標距離のリストを表示します。
ユーザーが目標、目標距離、開始日を設定できるようにします。
年齢、性別、現在のフィットネスレベルを考慮した、個々のユーザー向けの詳細なパーソナルトレーニングプランを作成します。このトレーニングプランには次のものが含まれます。

実行などのアクティビティ。
活動を開始および完了する日付。
距離（例：5 km走行）
推奨ペース（例：時速5 km）とおおよその完了時間（1時間）。
休息日。これらを体力計画に組み込むことが重要です。
目標の終了日（例：ユーザーが選択したイベントを実行する準備ができたとき。

各アクティビティがいつ開始されたか（または開始されたかどうか）、ユーザーがどのくらい近くで完了したか、いつ終了したかなど、トレーニング計画アクティビティの進捗状況をキャプチャします。
必要に応じてトレーニング計画を調整します。たとえば、ランナーが病気やけがをしたり、元のスケジュールに従わなかったりする場合があります。その場合、元の計画を延長または変更する必要があります。
ユーザーが獲得したタイトルをキャプチャします。実行中、これらは正常に完了したイベントに基づいています。 5Kランナー、10Kランナー、ハーフマラソンランナー、またはフルマラソンランナー。これらのタイトルは、ランナーがトレーニングを進めるにつれて獲得できます。

データモデル

このようなアプリをサポートするデータモデルは、次の3つのサブジェクト領域で構成されています。

ユーザーとタイトル
目標と活動
ユーザーの目標と移行

各主題分野について、記載されている順序で説明します。

サブジェクトエリア1：ユーザーとタイトル

このアプリは、初心者のランナーだけでなく、それ以上の人に使用されます。実行中のイベントは非常に要求が厳しく、大変です。ベテランのマラソン選手でさえ、次のマラソンのためにトレーニングする必要があります。一晩または単一のトレーニングコースの後にフルマラソンを実行する人は誰もいません。それは段階的なプロセスです。

先に述べたように、ランナーはさまざまな長さのイベントに基づいてさまざまなタイトルを獲得します。ランナーがトレーニングを進めるにつれて、より長いイベントを実行し、より多くのタイトルを獲得できるようになります。このサブジェクトエリアのテーブルは、それを念頭に置いて定義されています。

「registered_user 」の表には、ユーザーに関する基本的な詳細が含まれています。これらの詳細は、登録プロセス中に取得されます。これには、トレーニング計画の設計に影響を与える2つの重要な要素が含まれます。年齢（date_of_birthから派生））と性別。同じイベントで競争している場合でも、性別や年齢層が異なればトレーニングも異なるため、これらは重要です。 19歳の男の子は、45歳の女性とは異なるトレーニングプランが必要になります。

「running_event 」テーブルには、すべての公式実行イベントのリストが格納されます。これには国際的なイベントが含まれる可能性があります。すべてのフィールドは自明です。

「title 」の表には、主にランナーの「クレデンシャル」が格納されています。つまり、ランナーがカバーする距離と、公式イベント中にかかった時間です。タイトルとその配布に関する重要なポイントは次のとおりです。

各マラソンイベントには、独自のタイトルのリストがあります。
通常、これらのタイトルは、マイルストーンの終了時（トラック上）または終了時（マラソンのフィニッシュラインを通過する場合など）にランナーに付与されます。
すべてのランナーが条件を満たしていれば、複数のランナーに同じタイトルを付けることができます。これには、（1）カバーされる最小距離、および（2）この距離をカバーする最大時間が含まれます。
タイトルがトラックの中間マイルストーンで定義されている場合、ランナーは獲得した最高のタイトルのみを保持します。

タイトルをこのように理解すると、「タイトル」テーブルの列は自明である必要があります。 ☺

「user_title 」テーブルには、ユーザーが獲得したすべてのタイトルが格納されます。唯一の違いは、ここではランナーの時間を分ではなく秒でキャプチャすることです。

サブジェクトエリア2：目標と活動

あなたが望まないのなら、誰もあなたにマラソンを走らせる動機を与えることはできません。あなたはあなた自身の熱意を働かせる必要があります。やる気を維持する1つの方法は、目標を設定して達成することです。次の2つの主題分野は、目標の設定と達成を扱います。

まず、Goals and Activitiesを見ていきます。サブジェクトエリア。 3つのテーブルが含まれています：

「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.2kmのフルマラソンを走ることを夢見ることができますが、最初に5Kの走りに向けて作業を開始する必要があります。

「goal 」テーブルは、次の列を使用して制限を処理します。

current_run_distance_per_week –ユーザーが特定の目標を設定する前に達成される最小走行距離。および
current_min_title_id –この目標を設定するためにユーザーが保持する必要のある最小タイトル。

これらの前提条件が満たされていない場合、その目標はユーザーが利用できません。ただし、これらの列は両方ともnull許容です。前提条件となるフィットネス要件のない目標がいくつかあります。

「goal_activity " テーブル。これらの列のほとんどは、明らかな目的を果たします。 seq_of_dayから始めて、2つについてコメントします。桁。これは、アクティビティが実行される日を示す値を保持する数値列です。明らかに、このシーケンスはどの目標でも1から始まります。ゼロまたはNULLになることはできません。ゴールの数字は連続していない場合があります。これは、休憩日が設定されていることを意味します。この表にレコードがない日は、実際には休憩日です。

次に、distance_to_coverがあります桁。距離が問題にならないアクティビティ（ヨガ、ストレッチ、ウェイトリフティングなど）があるため、これは無効です。そうは言っても、min_paceに注意してください。およびmax_pace 「activity 」テーブルもnull許容です。

サブジェクトエリア＃3：ユーザーの目標と移行

この主題分野はすべて、ユーザーが作成した目標とアプリが作成した活動計画に関するものです。ここでは実際の日付が重要であり、seq_of_day 「goal_activity 」テーブルは、start_dateと同様に、計画日のレンダリングで主要な役割を果たします。ユーザーが目標のために選択します。

「user_goal 」と「transition_plan 」の表はどちらもほとんどの場合自明です。強調すべき列がいくつかあります。

「user_goal 」表：

is_active –ユーザーがまだこの目標を達成しているかどうかを示します。進行中のすべての目標には、この列に「Y」が表示されます。この列を使用すると、アプリはユーザーが一度に1つの目標を設定するように制限できます。
create_date –目標が作成された日付。
start_date –目標が実際に開始された日付。 create_dateと同じではない場合があります。
expected_end_date –終了日。ユーザーの移行計画を作成した後にアプリによって計算されます。
actual_end_date –目標が実際に完了したとき。トレーニング計画から逸脱する可能性があるため、実際の終了日を取得するためにこの列が必要です。アプリには、1日スキップするか、トレーニングスケジュールを1日ほど進めるオプションがあります。このような場合、actual_end_date 確かにexpected_end_dateとは異なります。

「transition_plan 」表：

is_complete –アクティビティがスキップされたか、まだ開始されていないか、または終了したかを示します。「Y」、「N」、または空白を保持します。
start_timestamp –アクティビティが開始されたときのタイムスタンプ。
end_timestamp –アクティビティが完了したときのタイムスタンプ。

トレーニングにはギャップがある可能性があることを理解しているため（病気、怪我、または意欲の欠如が原因）、この表には3つの異なる日付が含まれています。

original_calendar_date –アクティビティを実行する必要がある時期を示すカレンダーの日付。この値は、アプリがトレーニングプランを生成するときに入力されます。
planned_calendar_date –最初は、この列は空白のままです。トレーニングプランに変更が加えられると、日付が入力されます。
actual_calendar_date –この列は、ユーザーがアクティビティを完了としてマークするとすぐに入力されます。これは、アクティビティが実際に終了した日付です。

planned_calendar_date およびactual_calendar_date 列はnull許容です。これらは、最初のプランの生成中には入力されません。

このテーブルの別の3つの列はnull許容であるため、このデータモデルは進行中のアクティビティのすべての可能なシナリオを処理できます。次にいくつかの例を示します。

まだ開始されていないアクティビティ–

is_complete – NULL
start_timestamp – NULL
end_timestamp -NULL

開始されたが完了していないアクティビティ–

is_complete – NULL
start_timestamp –値
end_timestamp-NULL

スキップされたアクティビティ–

is_complete –「N」
start_timestamp – NULL
end_timestamp-NULL

完了したアクティビティ–

is_complete –「Y」
start_timestamp –VALUE
end_timestamp-値

このデータモデルについて何を変更しますか？

マラソンのトレーニングは、単なる運動以上のものです。マラソン選手は、毎日の食事の摂取量、精神的な強さ、さらには睡眠の量に至るまで、ライフスタイルのあらゆる側面を微調整する必要があります。

効果的なアプリは、トレーニングのすべての側面を整理、計画、追跡できる必要があります。私たちのデータモデルはこれらすべての側面に対応していますか？本格的なトレーニングアプリにするには、どのような変更が必要ですか？

コメントセクションであなたの意見や提案を共有してください。