Database
 sql >> Teknologi Basis Data >  >> RDS >> Database

Model Data Aplikasi Pelatihan Marathon

Apakah Anda bermimpi berlari maraton? Mari kita lihat model data untuk aplikasi yang dapat membawa Anda dari pemalas ke pelari maraton.

Apa yang Anda butuhkan untuk lari maraton? Anda akan membutuhkan antusiasme dan tekad. Sepasang sepatu lari yang bagus. Dan banyak latihan fisik! Katakanlah Anda memiliki aplikasi yang membantu Anda beralih dari pelari pemula ke pelari maraton. Seperti apa model datanya?

Dalam artikel ini, kami akan memeriksa model data di balik aplikasi pelatihan maraton.

Apa yang Harus Dilakukan Aplikasi Pelatihan Marathon?

Aplikasi pelatihan apa pun biasanya dilengkapi dengan beberapa opsi. Dalam hal ini, kami mengharapkan aplikasi untuk mendukung pelatihan untuk berbagai jenis lari (maraton penuh, setengah maraton, 5k) dan untuk jadwal pelatihan yang berbeda (mulai dari delapan hingga 24 minggu). Aplikasi akan menangkap detail dasar Anda, termasuk usia, jenis kelamin, dan status lari saat ini. Ini juga harus memungkinkan Anda untuk menetapkan tujuan dan tanggal mulai. Aplikasi akan menggunakan informasi ini untuk membuat rencana pelatihan untuk acara lari Anda yang akan datang. Semakin Anda maju dengan rencana Anda, semakin dekat Anda dengan tujuan Anda.

Mari kita bahas persyaratan utama aplikasi ini. Seharusnya:

  • Catat nama pengguna, usia, jenis kelamin, dll. selama proses pendaftaran.
  • Tampilan daftar tujuan (misalnya berjalan, berlari, bersepeda, dll.) dengan jarak target yang terkait.
  • Izinkan pengguna menetapkan tujuan, jarak target, dan tanggal mulai.
  • Buat rencana pelatihan pribadi yang mendetail untuk pengguna individu yang mempertimbangkan usia, jenis kelamin, dan tingkat kebugaran mereka saat ini. Rencana pelatihan ini mencakup:
    • Aktivitas, seperti berlari.
    • Tanggal untuk memulai dan menyelesaikan aktivitas.
    • Jarak (mis. berlari sejauh 5 kilometer)
    • Kecepatan yang disarankan (misalnya 5 km/jam) dan perkiraan waktu penyelesaian (1 jam).
    • Hari istirahat. Hal ini penting untuk dimasukkan ke dalam rencana kebugaran fisik.
    • Tanggal akhir sasaran, mis. saat pengguna siap menjalankan acara yang mereka pilih.
  • Catat kemajuan aktivitas rencana pelatihan, termasuk kapan (atau jika) setiap aktivitas dimulai, seberapa dekat pengguna untuk menyelesaikannya, dan kapan selesai.
  • Sesuaikan rencana pelatihan sesuai kebutuhan. Misalnya, seorang pelari mungkin sakit atau cedera dan mungkin tidak mengikuti jadwal aslinya; dalam hal ini, rencana awal perlu diperpanjang atau dimodifikasi.
  • Tangkap judul yang diperoleh pengguna. Dalam menjalankan, ini didasarkan pada peristiwa yang berhasil diselesaikan, mis. Pelari 5K, pelari 10K, pelari setengah maraton, atau pelari maraton penuh. Gelar-gelar ini diperoleh seiring kemajuan pelari dengan pelatihan mereka.

Model Data

Model data yang mendukung aplikasi semacam itu terdiri dari tiga bidang subjek:

  1. Pengguna dan Judul
  2. Sasaran dan Kegiatan
  3. Sasaran dan Transisi Pengguna

Kami akan membahas setiap bidang subjek sesuai urutannya.

Area Subjek 1:Pengguna dan Judul

Aplikasi ini akan digunakan oleh lebih dari sekadar pelari pemula. Acara lari sangat menuntut dan berat; bahkan pelari maraton berpengalaman perlu berlatih untuk maraton mendatang. Tidak ada yang menjalankan maraton penuh dalam semalam atau setelah satu kursus pelatihan. Ini adalah proses bertahap.

Seperti yang kami sebutkan sebelumnya, pelari mendapatkan berbagai gelar berdasarkan acara dengan durasi yang berbeda. Saat pelari maju dalam pelatihan mereka, mereka akan dapat menjalankan acara yang lebih lama dan mendapatkan lebih banyak gelar. Tabel di area subjek ini ditentukan dengan mempertimbangkan hal itu.

registered_user ” tabel menyimpan detail dasar tentang pengguna. Rincian ini ditangkap selama proses pendaftaran. Ini mencakup dua faktor utama yang memengaruhi desain rencana pelatihan:usia (berasal dari date_of_birth ) dan jenis kelamin. Ini penting karena jenis kelamin dan kelompok usia yang berbeda berlatih secara berbeda, bahkan jika mereka berkompetisi di acara yang sama. Seorang anak laki-laki berusia 19 tahun akan membutuhkan rencana pelatihan yang berbeda dari seorang wanita berusia 45 tahun.

running_event ” table menyimpan daftar semua acara lari resmi. Ini bisa termasuk acara internasional. Semua bidang cukup jelas.

title ” tabel terutama menyimpan “kredensial” pelari:jarak yang mereka tempuh dan waktu yang dibutuhkan selama acara resmi. Poin-poin penting tentang judul dan distribusinya adalah:

  • Setiap acara maraton memiliki daftar judulnya sendiri.
  • Biasanya gelar ini diberikan kepada pelari di akhir pencapaian (di trek) atau saat mereka selesai (misalnya, melewati garis finis maraton).
  • Judul yang sama dapat diberikan kepada beberapa pelari, asalkan semuanya memenuhi persyaratannya. Ini termasuk (1) jarak minimum yang harus ditempuh, dan (2) waktu maksimum untuk menempuh jarak ini.
  • Jika gelar ditentukan pada pencapaian menengah di trek, pelari mempertahankan satu-satunya gelar tertinggi yang telah mereka peroleh.

Dengan pemahaman judul ini, kolom dalam tabel “judul” harus cukup jelas.

user_title ” tabel menyimpan semua judul yang diperoleh pengguna. Satu-satunya perbedaan adalah bahwa di sini kami menangkap waktu pelari dalam hitungan detik, bukan menit.

Area Subjek 2:Sasaran dan Kegiatan

Tidak ada yang bisa memotivasi Anda untuk lari maraton jika Anda tidak mau. Anda harus meningkatkan semangat Anda sendiri. Salah satu cara untuk tetap termotivasi adalah dengan menetapkan dan mencapai tujuan. Dua bidang subjek berikutnya berurusan dengan penetapan dan pencapaian tujuan.

Pertama, kita akan melihat Goals and Activities bidang studi. Ini berisi tiga tabel:

  1. goal ” menyimpan detail tentang tujuan yang ditentukan dalam aplikasi.
  2. activity ” menyimpan informasi tentang berbagai jenis aktivitas pelatihan, seperti jalan kaki, jalan cepat, lari, berenang, bersepeda, dll.
  3. goal_activity ” menyimpan detail tentang aktivitas yang diperlukan untuk mencapai tujuan.

Penting untuk dipahami bahwa tujuan yang sama dicapai secara berbeda oleh pengguna yang berbeda. Sekali lagi, seorang gadis berusia 15 tahun akan memiliki rencana pelatihan dan serangkaian kegiatan yang berbeda dari seorang pria berusia 40 tahun. Mempertimbangkan fakta-fakta ini, kami telah menempatkan kolom berikut di “goal ” tabel:

  • distance_to_run – Jarak yang harus ditempuh seorang pelari di akhir tujuan ini.
  • target_time_in_min – Waktu maksimum yang diperlukan untuk menempuh jarak ini.
  • gender – Untuk jenis kelamin apa tujuan ini.

Gol dapat dibuat untuk kelompok usia, katakanlah 15-20 atau 35-40. Cara kami berlatih sedikit berubah seiring bertambahnya usia, jadi kami menambahkan dua kolom lagi ke “goal ”:

  • starting_age – Usia minimum untuk tujuan ini.
  • closing_age – Usia maksimum untuk tujuan ini.

Orang bisa bermimpi besar, tetapi satu-satunya cara untuk benar-benar mewujudkannya adalah dengan maju secara bertahap. Aplikasi ini membatasi cara pengguna membuat tujuan; mereka harus menyelesaikan tujuan yang lebih kecil dan dapat dicapai sebelum mencoba yang lebih besar. Kentang sofa dapat bermimpi berlari maraton penuh 26,2 mil\42.2km, tetapi mereka harus mulai bekerja untuk lari 5K terlebih dahulu.

goal ” tabel menangani pembatasan melalui kolom berikut:

  • current_run_distance_per_week – Jarak lari minimum yang dicapai sebelum pengguna dapat menetapkan tujuan tertentu; dan
  • current_min_title_id – Judul minimum yang harus dimiliki pengguna untuk menetapkan tujuan ini.

Jika prasyarat ini tidak terpenuhi, tujuan itu tidak akan tersedia bagi pengguna. Namun, kedua kolom ini tidak dapat dibatalkan; akan ada beberapa tujuan yang tidak memiliki persyaratan kebugaran prasyarat.

Mari kita beralih ke “goal_activity " meja. Sebagian besar kolom ini memiliki tujuan yang jelas. Saya hanya akan mengomentari dua, dimulai dengan seq_of_day kolom. Ini adalah kolom angka yang menyimpan nilai yang menandakan hari ketika suatu aktivitas akan dilakukan. Jelas, urutan ini dimulai dari 1 untuk tujuan apa pun. Itu tidak akan pernah menjadi NOL atau NULL. Angka tidak boleh berurutan untuk sebuah gol; ini berarti hari istirahat telah ditetapkan. Hari di mana tidak ada catatan dalam tabel ini sebenarnya adalah hari istirahat.

Selanjutnya, kita memiliki distance_to_cover kolom. Ini tidak dapat dibatalkan, karena ada aktivitas (seperti yoga, peregangan, dan angkat besi) di mana jarak tidak menjadi masalah. Setelah mengatakan ini, perhatikan bahwa min_pace dan max_pace kolom di “activity ” tabel juga dapat dibatalkan.

Area Subjek #3:Sasaran dan Transisi Pengguna

Area subjek ini adalah semua tentang tujuan yang dibuat pengguna dan rencana aktivitas yang dibuat aplikasi. Tanggal sebenarnya penting di sini, dan seq_of_day kolom di “goal_activity ” tabel memainkan peran utama dalam merender tanggal rencana, seperti halnya start_date dipilih oleh pengguna untuk tujuan mereka.

user_goal ” dan “transition_plan ” tabel keduanya sebagian besar cukup jelas. Hanya ada beberapa kolom yang harus kita soroti.

Dalam “user_goal ” tabel:

  • is_active – Menunjukkan jika pengguna masih melanjutkan tujuan ini. Semua tujuan yang sedang berlangsung akan memiliki 'Y' di kolom ini. Kolom ini memungkinkan aplikasi membatasi pengguna untuk menetapkan satu tujuan dalam satu waktu.
  • create_date – Tanggal saat gol dibuat.
  • start_date – Tanggal ketika tujuan sebenarnya dimulai. Ini mungkin tidak sama dengan create_date.
  • expected_end_date – Tanggal akhir, dihitung oleh aplikasi setelah membuat rencana transisi untuk pengguna.
  • actual_end_date – Ketika tujuan benar-benar selesai. Mungkin ada penyimpangan dari rencana pelatihan, jadi kami membutuhkan kolom ini untuk menangkap tanggal akhir yang sebenarnya. Aplikasi dapat memberikan opsi untuk melewati satu hari atau memajukan jadwal pelatihan sekitar satu hari. Dalam kasus seperti itu, actual_end_date pasti akan berbeda dari expected_end_date .

Dalam “transition_plan ” tabel:

  • is_complete – Menunjukkan apakah suatu aktivitas dilewati, belum dimulai, atau sudah selesai. Ini akan menampung 'Y', 'N', atau kosong.
  • start_timestamp – Stempel waktu saat aktivitas dimulai.
  • end_timestamp – Stempel waktu saat aktivitas selesai.

Karena kami memahami bahwa mungkin ada jeda dalam pelatihan (karena sakit, cedera, atau kurangnya motivasi), tabel ini berisi tiga tanggal yang berbeda:

  • original_calendar_date – Tanggal kalender yang menunjukkan kapan suatu aktivitas perlu dilakukan. Nilai ini diisi saat aplikasi membuat rencana pelatihan.
  • planned_calendar_date – Awalnya, kolom ini tetap kosong. Tanggal diisi saat dan saat perubahan dibuat dalam rencana pelatihan.
  • actual_calendar_date – Kolom ini diisi segera setelah pengguna menandai aktivitas sebagai selesai. Ini adalah tanggal saat aktivitas benar-benar selesai.

planned_calendar_date dan actual_calendar_date kolom tidak dapat dibatalkan; mereka tidak diisi selama pembuatan rencana awal.

Tiga kolom lainnya dalam tabel ini dapat dibatalkan sehingga model data ini dapat menangani semua kemungkinan skenario untuk aktivitas yang sedang berlangsung. Berikut beberapa contohnya:

  • Aktivitas yang belum dimulai –
    • is_complete – NULL
    • start_timestamp – NULL
    • end_timestamp - NULL
  • Aktivitas yang dimulai tetapi belum selesai –
    • sudah_lengkap – NULL
    • stempel waktu_mulai – VALUE
    • stempel waktu_akhir - NULL
  • Aktivitas yang dilewati –
    • sudah_lengkap – 'N'
    • start_timestamp – NULL
    • stempel waktu_akhir - NULL
  • Aktivitas yang telah selesai –
    • sudah_lengkap – 'Y'
    • stempel waktu_mulai –VALUE
    • stempel waktu_akhir - VALUE

Apa yang Akan Anda Ubah Tentang Model Data Ini?

Pelatihan untuk maraton lebih dari sekadar olahraga. Pelari maraton harus mengubah setiap aspek gaya hidup mereka, mulai dari asupan makanan sehari-hari, kekuatan mental, dan bahkan jumlah tidur yang mereka dapatkan.

Aplikasi yang efektif harus dapat mengatur, merencanakan, dan melacak semua aspek pelatihan. Apakah model data kami memenuhi semua aspek ini? Perubahan apa yang diperlukan untuk menjadikannya aplikasi pelatihan yang lengkap?

Silakan bagikan pandangan dan saran Anda di bagian komentar.


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Model Data Pengiriman Bahan Makanan

  2. Bagaimana Rencana Paralel Memulai – Bagian 2

  3. Pemantauan Log Transaksi

  4. Menyelami NoSQL:Daftar lengkap database NoSQL

  5. Bagaimana cara menambahkan kolom dalam tabel di SQL?