Database
 sql >> Baza danych >  >> RDS >> Database

Model danych aplikacji szkoleniowej Marathon

Marzysz o przebiegnięciu maratonu? Przyjrzyjmy się modelowi danych dla aplikacji, która może przenieść Cię od leniwego kanapowca do maratończyka.

Czego potrzebujesz, aby przebiec maraton? Będziesz potrzebować entuzjazmu i determinacji. Dobra para butów do biegania. I dużo treningu fizycznego! Załóżmy, że masz aplikację, która pomoże Ci przejść od początkującego biegacza do osoby, która ukończyła maraton. Jak wyglądałby model danych?

W tym artykule przyjrzymy się modelowi danych stojącemu za aplikacją do treningu maratonu.

Co powinna zrobić aplikacja do treningu maratonów?

Każda aplikacja szkoleniowa zwykle zawiera kilka opcji. W tym przypadku spodziewalibyśmy się, że aplikacja będzie wspierać treningi dla różnych rodzajów biegów (pełny maraton, półmaraton, 5 km) i dla różnych harmonogramów treningowych (od 8 do 24 tygodni). Aplikacja przechwyci Twoje podstawowe dane, w tym wiek, płeć i aktualny stan biegania. Powinno również umożliwić ustalenie celu i daty rozpoczęcia. Aplikacja wykorzysta te informacje do stworzenia planu treningowego na nadchodzące wydarzenie biegowe. Im bardziej postępujesz w realizacji swojego planu, tym bliżej jesteś swojego celu.

Przyjrzyjmy się kluczowym wymaganiom tej aplikacji. Powinien:

  • Przechwyć imię i nazwisko użytkownika, wiek, płeć itp. podczas procesu rejestracji.
  • Wyświetlanie listy celów (np. chodzenie, bieganie, jazda na rowerze itp.) z powiązanym dystansem docelowym.
  • Pozwól użytkownikom ustawić cel, odległość docelową i datę rozpoczęcia.
  • Utwórz szczegółowy osobisty plan treningowy dla poszczególnych użytkowników, uwzględniający ich wiek, płeć i aktualny poziom sprawności. Ten plan treningowy obejmuje:
    • Aktywności, takie jak bieganie.
    • Daty rozpoczęcia i zakończenia działań.
    • Odległości (np. bieganie na 5 kilometrów)
    • Sugerowane tempo (np. 5 km/h) i przybliżone czasy ukończenia (1 godzina).
    • Dni odpoczynku. Ważne jest, aby wbudować je w plan sprawności fizycznej.
    • Data zakończenia celu, np. kiedy użytkownik będzie gotowy do uruchomienia wybranego wydarzenia.
  • Uchwyć postęp działań planu treningowego, w tym kiedy (lub czy) każde działanie zostało rozpoczęte, jak blisko jest jego ukończenie i kiedy zostało zakończone.
  • Dostosuj plany treningowe do potrzeb. Na przykład biegacz może zachorować lub kontuzjować i może nie przestrzegać swojego pierwotnego harmonogramu; w takim przypadku pierwotny plan będzie musiał zostać rozszerzony lub zmodyfikowany.
  • Przechwytywanie tytułów zdobytych przez użytkownika. W bieganiu opierają się one na pomyślnie zakończonych wydarzeniach, m.in. Biegacz 5 km, biegacz 10 km, półmaraton lub biegacz pełny maraton. Te tytuły są zdobywane w miarę postępów biegaczy w treningu.

Model danych

Model danych obsługujący taką aplikację składa się z trzech obszarów tematycznych:

  1. Użytkownicy i tytuły
  2. Cele i działania
  3. Cele i przejścia użytkowników

Omówimy każdy obszar tematyczny w kolejności, w jakiej jest wymieniony.

Obszar tematyczny 1:Użytkownicy i tytuły

Ta aplikacja będzie używana nie tylko przez początkujących biegaczy. Imprezy biegowe są bardzo wymagające i żmudne; nawet doświadczeni maratończycy muszą trenować do nadchodzących maratonów. Nikt nie biegnie pełnego maratonu w nocy lub po jednym szkoleniu. Jest to proces stopniowy.

Jak wspomnieliśmy wcześniej, biegacze zdobywają różne tytuły na podstawie wydarzeń o różnej długości. W miarę postępów w treningu biegacz będzie mógł prowadzić dłuższe zawody i zdobywać więcej tytułów. Mając to na uwadze, zdefiniowano tabele w tym obszarze tematycznym.

registered_user Tabela zawiera podstawowe informacje o użytkownikach. Dane te są rejestrowane podczas procesu rejestracji. Obejmuje to dwa kluczowe czynniki, które wpływają na projektowanie planu treningowego:wiek (pochodzący z date_of_birth ) i płci. Są to ważne, ponieważ różne płcie i grupy wiekowe trenują inaczej, nawet jeśli rywalizują w tej samej imprezie. 19-latek będzie potrzebował innego planu treningowego niż 45-letnia kobieta.

running_event W tabeli znajduje się lista wszystkich oficjalnych imprez biegowych. Może to obejmować wydarzenia międzynarodowe. Wszystkie pola są oczywiste.

title Tabela zawiera przede wszystkim „legitymacje” biegaczy:dystans, który pokonują i czas, jaki zajęło im oficjalne zawody. Kluczowe punkty dotyczące tytułów i ich dystrybucji to:

  • Każde wydarzenie maratonu ma swoją własną listę tytułów.
  • Tytuły te są zwykle przyznawane biegaczom na końcu kamieni milowych (na torze) lub po ich zakończeniu (np. przekroczeniu linii mety maratonu).
  • Ten sam tytuł może otrzymać wielu biegaczy, o ile wszyscy spełniają warunki. Obejmują one (1) minimalną odległość do pokonania i (2) maksymalny czas na pokonanie tej odległości.
  • Jeśli tytuły są zdefiniowane na pośrednich etapach na torze, biegacz zachowuje jedyny najwyższy tytuł, jaki zdobył.

Przy takim zrozumieniu tytułów kolumny w tabeli „tytuł” ​​nie wymagają wyjaśnień.

user_title ” tabela przechowuje wszystkie tytuły, które zdobyli użytkownicy. Jedyną różnicą jest to, że tutaj rejestrujemy czas biegacza w sekundach zamiast minutach.

Obszar tematyczny 2:Cele i działania

Nikt nie może Cię zmotywować do biegu, jeśli nie chcesz. Musisz wypracować własną gorliwość. Jednym ze sposobów na utrzymanie motywacji jest wyznaczanie i osiąganie celów. Kolejne dwa obszary tematyczne dotyczą wyznaczania i realizacji celów.

Najpierw przyjrzymy się Goals and Activities Tematyka. Zawiera trzy tabele:

  1. goal ” zawiera szczegółowe informacje o celach zdefiniowanych w aplikacji.
  2. activity ” przechowuje informacje o różnego rodzaju aktywnościach treningowych, takich jak chodzenie, szybki marsz, bieganie, pływanie, jazda na rowerze itp.
  3. goal_activity ” przechowuje szczegółowe informacje o działaniach potrzebnych do osiągnięcia celu.

Ważne jest, aby zrozumieć, że ten sam cel jest osiągany w różny sposób przez różnych użytkowników. Ponownie, 15-letnia dziewczyna będzie miała plan treningowy i zestaw działań, które różnią się od 40-letniego mężczyzny. Biorąc pod uwagę te fakty, umieściliśmy następujące kolumny w „goal ” tabela:

  • distance_to_run – Dystans, który biegacz powinien być w stanie przebiec na końcu tej bramki.
  • target_time_in_min – Maksymalny czas potrzebny na pokonanie tego dystansu.
  • gender – Dla jakiej płci jest ten cel.

Można stworzyć cel dla grupy wiekowej, powiedzmy 15-20 lub 35-40. Sposób, w jaki trenujemy, zmienia się nieco wraz z wiekiem, dlatego dodaliśmy dwie dodatkowe kolumny do „goal ”:

  • starting_age – Minimalny wiek dla tego celu.
  • closing_age – Maksymalny wiek dla tego celu.

Ludzie mogą marzyć o wielkich rzeczach, ale jedynym sposobem na to, aby coś się wydarzyło, jest stopniowy postęp. Ta aplikacja ogranicza sposób, w jaki użytkownicy wyznaczają cele; muszą osiągnąć mniejsze, osiągalne cele, zanim spróbują osiągnąć te większe. Ziemniak kanapowy może marzyć o przebiegnięciu pełnego 26,2 mili\42,2 km maratonu, ale najpierw powinien zacząć pracować nad biegiem na 5 km.

goal Tabela obsługuje ograniczenia za pomocą następujących kolumn:

  • current_run_distance_per_week – Minimalny dystans biegu osiągnięty przed wyznaczeniem przez użytkownika określonego celu; i
  • current_min_title_id – Minimalny tytuł, który użytkownicy muszą posiadać, aby ustawić ten cel.

Jeśli te warunki wstępne nie zostaną spełnione, cel nie będzie dostępny dla użytkownika. Jednak obie te kolumny dopuszczają wartość null; będą pewne cele, które nie będą miały wstępnych wymagań dotyczących kondycji.

Przejdźmy do „goal_activity " stół. Większość z tych kolumn służy oczywistemu celowi. Skomentuję tylko dwa, zaczynając od seq_of_day kolumna. Jest to kolumna liczbowa, która zawiera wartości oznaczające dzień, w którym czynność ma zostać wykonana. Oczywiście ta sekwencja zaczyna się od 1 dla dowolnego gola. Nigdy nie może być ZERO lub NULL. Liczby nie mogą być kolejnymi bramkami; oznaczałoby to, że ustalono dni odpoczynku. Dni, dla których nie ma wpisów w tej tabeli, są w rzeczywistości dniami odpoczynku.

Następnie mamy distance_to_cover kolumna. Jest to nieważne, ponieważ istnieją czynności (takie jak joga, rozciąganie i podnoszenie ciężarów), w których odległość nie ma znaczenia. Powiedziawszy to, zauważ, że min_pace i max_pace kolumny w „activity ” również mogą mieć wartość null.

Obszar tematyczny 3:Cele i przejścia użytkowników

Ten obszar tematyczny dotyczy celów stworzonych przez użytkowników i planów działań tworzonych przez aplikacje. Ważne są tutaj rzeczywiste daty, a seq_of_day kolumna w „goal_activity ” tabela odgrywa główną rolę w datach planu renderowania, podobnie jak start_date wybrane przez użytkowników ze względu na ich cele.

user_goal ” i „transition_plan Tabele są w większości oczywiste. Jest tylko kilka kolumn, które powinniśmy podkreślić.

W „user_goal ” tabela:

  • is_active – Pokazuje, czy użytkownik nadal realizuje ten cel. Wszystkie cele w toku miałyby w tej kolumnie „Y”. Ta kolumna umożliwia aplikacji ograniczenie użytkowników do wyznaczania jednego celu naraz.
  • create_date – Data utworzenia celu.
  • start_date – Data faktycznego rozpoczęcia gola. Może nie być tym samym co data_utworzenia.
  • expected_end_date – Data zakończenia obliczana przez aplikację po utworzeniu planu przejścia dla użytkownika.
  • actual_end_date – Kiedy cel został faktycznie zrealizowany. Mogą wystąpić odchylenia od planu treningowego, więc potrzebujemy tej kolumny, aby uchwycić rzeczywistą datę zakończenia. Aplikacja może dać opcję pominięcia dnia lub przesunięcia harmonogramu treningu o dzień lub dwa. W takich przypadkach actual_end_date z pewnością będzie się różnić od expected_end_date .

W „transition_plan ” tabela:

  • is_complete – Wskazuje, czy czynność została pominięta, nie została jeszcze rozpoczęta lub została zakończona. Będzie zawierać „Y”, „N” lub spację.
  • start_timestamp – Sygnatura czasowa rozpoczęcia aktywności.
  • end_timestamp – Znacznik czasu zakończenia działania.

Ponieważ rozumiemy, że mogą istnieć luki w treningu (z powodu choroby, kontuzji lub braku motywacji), ta tabela zawiera trzy różne daty:

  • original_calendar_date – Data kalendarzowa oznaczająca, kiedy czynność musi zostać wykonana. Ta wartość jest wypełniana, gdy aplikacja generuje plan treningowy.
  • planned_calendar_date – Początkowo ta kolumna pozostaje pusta. Data jest wypełniana w momencie wprowadzenia zmiany w planie treningowym.
  • actual_calendar_date – Ta kolumna jest wypełniana, gdy tylko użytkownik oznaczy działanie jako zakończone. Jest to data faktycznego zakończenia aktywności.

planned_calendar_date i actual_calendar_date kolumny mogą mieć wartość null; nie są one wypełniane podczas początkowego generowania planu.

Kolejne trzy kolumny w tej tabeli dopuszczają wartość null, dzięki czemu ten model danych może obsługiwać wszystkie możliwe scenariusze dla działania w toku. Oto kilka przykładów:

  • Działanie, które jeszcze się nie rozpoczęło –
    • is_complete – NULL
    • start_timestamp – NULL
    • end_timestamp - NULL
  • Działanie, które zostało rozpoczęte, ale nie zakończone –
    • is_complete – NULL
    • start_timestamp – WARTOŚĆ
    • end_timestamp – NULL
  • Aktywność, która została pominięta –
    • is_complete – „N”
    • start_timestamp – NULL
    • end_timestamp – NULL
  • Działanie, które zostało ukończone –
    • jest_kompletne – „T”
    • start_timestamp –VALUE
    • end_timestamp – VALUE

Co byś zmienił w tym modelu danych?

Trening do maratonu to coś więcej niż tylko ćwiczenia. Maratończycy muszą dostosować każdy aspekt swojego stylu życia, zaczynając od codziennego spożycia pokarmu, siły psychicznej, a nawet ilości snu, jaką mają.

Skuteczna aplikacja musi być w stanie organizować, planować i śledzić wszystkie aspekty treningu. Czy nasz model danych uwzględnia wszystkie te aspekty? Jakie zmiany są wymagane, aby stała się pełnoprawną aplikacją szkoleniową?

Podziel się swoimi opiniami i sugestiami w sekcji komentarzy.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. TABELA SQL

  2. SQL Azure:baza danych XXXYYY na serwerze jest obecnie niedostępna

  3. Progi optymalizacji — grupowanie i agregowanie danych, część 2

  4. Wskazówki dotyczące blokad odczytu/zapisu w zależności od poziomu izolacji transakcji w MSSQL

  5. Model danych płacowych