sql >> Base de Datos >  >> RDS >> Database

Un modelo de datos de la aplicación de entrenamiento Marathon

¿Sueñas con correr una maratón? Veamos el modelo de datos de una aplicación que podría llevarlo de holgazán adicto a la televisión a maratoniano.

¿Qué necesitas para correr un maratón? Necesitarás entusiasmo y determinación. Un buen par de zapatillas para correr. ¡Y mucho entrenamiento físico! Supongamos que tiene una aplicación que lo ayuda a pasar de corredor novato a finalista de maratón. ¿Cómo sería el modelo de datos?

En este artículo, examinaremos el modelo de datos detrás de una aplicación de entrenamiento para maratones.

¿Qué debe hacer una aplicación de entrenamiento para maratones?

Cualquier aplicación de entrenamiento suele venir con algunas opciones. En este caso, esperaríamos que la aplicación admitiera el entrenamiento para diferentes tipos de carreras (maratón completo, medio maratón, 5 km) y para diferentes programas de entrenamiento (de ocho a 24 semanas). La aplicación capturaría sus detalles básicos, incluidos la edad, el sexo y el estado actual de funcionamiento. También debería permitirle establecer una meta y una fecha de inicio. La aplicación utilizará esta información para crear un plan de entrenamiento para su próximo evento de carrera. Cuanto más progreses con tu plan, más cerca estarás de tu objetivo.

Repasemos los requisitos clave de esta aplicación. Debería:

  • Capture el nombre, la edad, el sexo, etc. de un usuario durante el proceso de registro.
  • Visualización de una lista de objetivos (por ejemplo, caminar, correr, andar en bicicleta, etc.) con una distancia objetivo asociada.
  • Permitir a los usuarios establecer un objetivo, una distancia objetivo y una fecha de inicio.
  • Cree un plan de entrenamiento personal detallado para usuarios individuales que tenga en cuenta su edad, sexo y estado físico actual. Este plan de formación incluye:
    • Actividades, como correr.
    • Fechas de inicio y finalización de las actividades.
    • Distancias (por ejemplo, correr 5 kilómetros)
    • Ritmo sugerido (por ejemplo, 5 km/h) y tiempos aproximados de finalización (1 hora).
    • Días de descanso. Es importante incluirlos en un plan de acondicionamiento físico.
    • Fecha de finalización del objetivo, p. ej. cuándo el usuario estaría listo para ejecutar el evento elegido.
  • Capture el progreso de las actividades del plan de capacitación, incluido cuándo (o si) se inició cada actividad, qué tan cerca está el usuario de completarla y cuándo terminó.
  • Ajuste los planes de capacitación según sea necesario. Por ejemplo, un corredor puede enfermarse o lesionarse y no seguir su programa original; en ese caso, será necesario ampliar o modificar el plan original.
  • Capturar títulos ganados por el usuario. En ejecución, estos se basan en eventos completados con éxito, p. Corredor de 5K, corredor de 10K, corredor de medio maratón o corredor de maratón completo. Estos títulos se ganan a medida que los corredores avanzan en su entrenamiento.

El modelo de datos

El modelo de datos que respalda una aplicación de este tipo consta de tres áreas temáticas:

  1. Usuarios y Títulos
  2. Objetivos y actividades
  3. Objetivos de usuario y transiciones

Hablaremos de cada área temática en el orden en que aparecen.

Área temática 1:Usuarios y títulos

Esta aplicación será utilizada por algo más que corredores novatos. Los eventos de carrera son muy exigentes y extenuantes; incluso los corredores de maratón experimentados necesitan entrenarse para los próximos maratones. Nadie corre un maratón completo de la noche a la mañana o después de un solo curso de entrenamiento. Es un proceso gradual.

Como mencionamos anteriormente, los corredores ganan varios títulos en función de eventos de diferente duración. A medida que un corredor avanza en su entrenamiento, podrá correr eventos más largos y ganar más títulos. Las tablas en esta área temática se definen con eso en mente.

El “registered_user La tabla ” contiene detalles básicos sobre los usuarios. Estos detalles se capturan durante el proceso de registro. Esto incluye dos factores clave que influyen en el diseño del plan de formación:edad (derivada de date_of_birth ) y género. Estos son importantes porque los diferentes géneros y grupos de edad entrenan de manera diferente, incluso si compiten en el mismo evento. Un chico de 19 años necesitará un plan de entrenamiento diferente al de una mujer de 45 años.

El “running_event La tabla almacena una lista de todos los eventos oficiales en ejecución. Esto podría incluir eventos internacionales. Todos los campos se explican por sí mismos.

El “title La tabla almacena principalmente las "credenciales" de los corredores:la distancia que recorren y el tiempo que les tomó durante un evento oficial. Los puntos clave sobre los títulos y sus distribuciones son:

  • Cada evento de maratón tiene su propia lista de títulos.
  • Por lo general, estos títulos se otorgan a los corredores al final de un hito (en una pista) o cuando terminan (por ejemplo, cruzar la línea de meta de un maratón).
  • Se puede otorgar el mismo título a múltiplos de corredores, siempre que todos cumplan con sus condiciones. Estos incluyen (1) la distancia mínima a cubrir y (2) el tiempo máximo para cubrir esta distancia.
  • Si los títulos se definen en hitos intermedios en una pista, el corredor conserva el único título más alto que haya ganado.

Con esta comprensión de los títulos, las columnas en la tabla de "títulos" deberían explicarse por sí mismas. ☺

El “user_title La tabla almacena todos los títulos que los usuarios han ganado. La única diferencia es que aquí capturamos el tiempo del corredor en segundos en lugar de minutos.

Área Temática 2:Metas y Actividades

Nadie puede motivarte a correr un maratón si tú no quieres. Tienes que desarrollar tu propio celo. Una forma de mantenerse motivado es establecer y alcanzar metas. Las siguientes dos áreas temáticas tratan sobre el establecimiento y el cumplimiento de objetivos.

Primero, veremos los Goals and Activities área temática. Contiene tres tablas:

  1. goal ” contiene detalles sobre los objetivos definidos en la aplicación.
  2. activity ” almacena información sobre varios tipos de actividades de entrenamiento, como caminar, caminar rápido, correr, nadar, andar en bicicleta, etc.
  3. goal_activity ” almacena detalles sobre las actividades necesarias para lograr un objetivo.

Es importante comprender que diferentes usuarios alcanzan el mismo objetivo de manera diferente. Una vez más, una niña de 15 años tendrá un plan de entrenamiento y un conjunto de actividades diferentes a las de un hombre de 40 años. Teniendo en cuenta estos hechos, hemos puesto las siguientes columnas en el “goal ” tabla:

  • distance_to_run – La distancia que un corredor debería poder correr al final de esta meta.
  • target_time_in_min – El tiempo máximo necesario para cubrir esta distancia.
  • gender – Para qué género es este objetivo.

Se puede crear una meta para un grupo de edad, digamos 15-20 o 35-40. La forma en que entrenamos cambia un poco a medida que envejecemos, por lo que hemos agregado dos columnas más a "goal ”:

  • starting_age – La edad mínima para este objetivo.
  • closing_age – La edad máxima para este objetivo.

La gente puede soñar en grande, pero la única forma de hacer que las cosas realmente sucedan es progresar gradualmente. Esta aplicación restringe cómo los usuarios hacen metas; deben completar objetivos más pequeños y alcanzables antes de intentar alcanzar los más grandes. Un adicto a la televisión puede soñar con correr un maratón completo de 26,2 millas/42,2 km, pero primero debe comenzar a trabajar para lograr una carrera de 5 km.

El “goal La tabla ” maneja las restricciones por medio de las siguientes columnas:

  • current_run_distance_per_week – La distancia mínima de carrera alcanzada antes de que un usuario pueda establecer un objetivo determinado; y
  • current_min_title_id – El título mínimo que los usuarios deben tener para establecer este objetivo.

Si no se cumplen estos requisitos previos, ese objetivo no estará disponible para el usuario. Sin embargo, ambas columnas aceptan valores NULL; habrá algunos objetivos que no tienen requisitos de condición física previa.

Pasemos a la “goal_activity " mesa. La mayoría de estas columnas tienen un propósito obvio. Solo comentaré dos, comenzando con seq_of_day columna. Esta es una columna de números que contiene valores que significan el día en que se realizará una actividad. Obviamente, esta secuencia comienza desde 1 para cualquier objetivo. Nunca puede ser CERO o NULL. Los números pueden no ser consecutivos para un gol; esto significaría que se han establecido días de descanso. Los días para los que no hay registros en esta tabla son en realidad días de descanso.

A continuación, tenemos la distance_to_cover columna. Esto es anulable, ya que hay actividades (como yoga, estiramiento y levantamiento de pesas) en las que la distancia no importa. Habiendo dicho esto, observe que el min_pace y max_pace columnas en la “activity ” tabla también son anulables.

Área temática n.° 3:Metas y transiciones del usuario

Esta área temática tiene que ver con los objetivos creados por el usuario y los planes de actividad creados por la aplicación. Las fechas reales son importantes aquí, y el seq_of_day columna en "goal_activity La tabla ” juega un papel importante en la representación de las fechas del plan, al igual que la start_date elegido por los usuarios para sus objetivos.

El “user_goal ” y “transition_plan Las tablas ” se explican por sí mismas en su mayoría. Solo hay algunas columnas que debemos resaltar.

En el “user_goal ” tabla:

  • is_active – Muestra si un usuario todavía está progresando en este objetivo. Todos los objetivos en progreso tendrían una 'Y' en esta columna. Esta columna permite que la aplicación restrinja a los usuarios a establecer un objetivo a la vez.
  • create_date – La fecha en que se creó un objetivo.
  • start_date – La fecha en que se inició realmente un objetivo. Puede que no sea lo mismo que create_date.
  • expected_end_date – Una fecha de finalización, calculada por la aplicación después de hacer un plan de transición para el usuario.
  • actual_end_date – Cuándo se completó realmente el objetivo. Puede haber desviaciones del plan de capacitación, por lo que necesitamos esta columna para capturar la fecha de finalización real. La aplicación puede ofrecer la opción de saltarse un día o adelantar el programa de entrenamiento un día más o menos. En tales casos, la actual_end_date ciertamente diferirá de la expected_end_date .

En el “transition_plan ” tabla:

  • is_complete – Indica si una actividad se omitió, aún no se ha iniciado o ha finalizado. Contendrá una 'Y', 'N' o un espacio en blanco.
  • start_timestamp – La marca de tiempo cuando se inició una actividad.
  • end_timestamp – La marca de tiempo cuando se completó la actividad.

Como entendemos que puede haber huecos en los entrenamientos (por enfermedad, lesión o falta de motivación), esta tabla contiene tres fechas diferentes:

  • original_calendar_date – Una fecha del calendario que indica cuándo se debe realizar una actividad. Este valor se completa cuando la aplicación genera un plan de entrenamiento.
  • planned_calendar_date – Inicialmente, esta columna permanece en blanco. Se completa una fecha a medida que se realiza un cambio en el plan de capacitación.
  • actual_calendar_date – Esta columna se completa tan pronto como el usuario marca una actividad como completa. Esta es la fecha en que la actividad realmente finaliza.

La planned_calendar_date y actual_calendar_date las columnas son anulables; no se rellenan durante la generación del plan inicial.

Otras tres columnas de esta tabla admiten valores NULL para que este modelo de datos pueda manejar todos los escenarios posibles para una actividad en curso. Estos son algunos ejemplos:

  • Una actividad que aún no ha comenzado –
    • is_complete – NULO
    • start_timestamp – NULO
    • end_timestamp - NULO
  • Una actividad que se inició pero no se completó:
    • es_completo – NULO
    • start_timestamp – VALOR
    • end_timestamp - NULO
  • Una actividad que se omitió:
    • es_completo – 'N'
    • start_timestamp – NULO
    • end_timestamp - NULO
  • Una actividad que se completó –
    • es_completo – 'Y'
    • start_timestamp –VALUE
    • end_timestamp - VALOR

¿Qué cambiaría de este modelo de datos?

Entrenar para un maratón es algo más que ejercicio. Los corredores de maratón tienen que modificar todos los aspectos de su estilo de vida, desde la ingesta diaria de alimentos, su fortaleza mental e incluso la cantidad de sueño que duermen.

Una aplicación eficaz debe poder organizar, planificar y realizar un seguimiento de todos los aspectos del entrenamiento. ¿Nuestro modelo de datos cubre todos estos aspectos? ¿Qué cambios se requieren para convertirla en una aplicación de capacitación completa?

Comparta sus opiniones y sugerencias en la sección de comentarios.