El modelo de datos de fechas importantes

¿Estás olvidando algo? Un modelo de datos para ayudarte a recordar fechas importantes, antes de que sucedan.

¿Alguna vez has olvidado una fecha importante:el cumpleaños de tu madre o tu aniversario? ¿O que estás dando una conferencia? Sí, cosas así pasan en la vida real. Tal vez no para todos nosotros, pero para algunos de nosotros (incluyéndome a mí), ciertamente lo hacen. Para evitar tales desastres, crearemos un modelo de datos que podría usar como fondo para una aplicación que le notificará a tiempo.

Es hora de despedirse de todas esas caras decepcionadas y tristes y de los regalos que no se compraron a tiempo. :)

Profundicemos directamente en el modelo.

El modelo de datos

Nuestro objetivo es crear un modelo de datos para una aplicación que nos permita definir eventos futuros y todas las acciones relacionadas con ellos. La aplicación debe notificar a los usuarios cuando hacen algo en la vida real y marcarlo como hecho cuando se haya completado. Algunas tareas se repiten, p. ese evento desencadena un evento futuro en el momento que hemos definido.

Por supuesto, también necesitaremos desarrollar aplicaciones web y móviles para que este sistema sea realmente útil. Pero por ahora, centrémonos en el modelo de datos.

El modelo consta de tres áreas temáticas:

User accounts & dates
Events & actions (definition)
Events & actions (real)

Describiremos cada una de estas tres áreas temáticas en el orden en que aparecen.

Sección 1:Cuentas de usuario y fechas

Los usuarios de nuestra aplicación pueden crear sus propios perfiles de usuario y almacenar fechas importantes de su elección. Para respaldar eso, usaremos las siguientes tablas.

La user_account table tiene una estructura similar a las descritas en muchos artículos de modelos de datos, pero repitámoslo una vez más. Para cada usuario, almacenaremos:

first_name y last_name – El nombre y apellido del usuario.
user_name – El nombre de usuario seleccionado por el usuario.
password – El valor hash de la contraseña que seleccionó el usuario.
mobile – El número de teléfono móvil facilitado por el usuario.
email – El correo electrónico utilizado durante el proceso de registro.
confirmation_code – Un código de confirmación enviado al usuario para completar su registro.
confirmation_time – Cuando el usuario completó el proceso de confirmación.
insert_ts - La marca de tiempo cuando se insertó este registro.

Una vez completado el registro, el usuario podrá seleccionar sus propias fechas importantes. Esta lista se almacena en la tabla selected_date. Aunque estamos hablando de fechas, lo que el usuario está seleccionando en realidad son reglas que denotarán fechas. Primero describiremos todos los atributos en esta tabla y luego discutiremos cómo los usuarios pueden establecer reglas usando esos atributos. Los atributos son:

user_account_id – El ID del usuario que insertó este registro.
date_year , date_month y date_day - Valores enteros que representan las partes de la fecha (año, mes y día del mes).
date_weekday – Una representación textual del número ordinal del día de la semana. Usamos texto porque permite a los usuarios seleccionar valores más complejos:pueden definir tanto el día de la semana como la semana del mes, p. el segundo lunes de cada mes.

Tenga en cuenta que las cuatro partes de la fecha podrían ser NULL. No permitiremos registros con todos los valores NULL, por lo que verificaremos mediante programación que al menos una parte de la fecha NO sea NULL.

Y ahora algunos ejemplos:

Si queremos seleccionar una fecha exacta, p. 31.12.2018, estableceremos los valores en date_year =2018, date_month =12 y date_day =31. Esto define algo que sucederá solo una vez, en esa única fecha.
Si usamos la combinación date_year =2019 y date_month =1, dejando los dos valores restantes NULL, entonces estamos definiendo algo que se repetirá durante todo enero de 2019.
La combinación date_year =2019 y date_day =2 activaría un evento el segundo día de cada mes en 2019.
Si insertamos el valor , estamos definiendo algo que sucederá el segundo lunes de cada mes.

Sección 2:Eventos y Acciones (Definición)

He estado mencionando un "algo" vago, pero ese algo es en realidad un evento. Los eventos y las acciones son las razones por las que estamos aquí. Queremos relacionar el dominio del tiempo con eventos y acciones reales que sucederán en el futuro. En esta área temática, almacenaremos las definiciones de todos los eventos y acciones. Estas definiciones se usarán más tarde para crear eventos y acciones reales.

El event table es definitivamente la tabla central en esta área temática, pero antes de describirla, quiero describir dos diccionarios, el event_catalog y el recurrence_interval . Ambos tienen la misma estructura, con una clave principal de incremento automático (id ) y el atributo de nombre ÚNICO.

El event_catalog El diccionario almacenará valores como "cumpleaños", "día festivo", "aniversario" y "otro". Esto nos ayudará a clasificar nuestros eventos.

Por otro lado, el recurrence_interval almacenará valores como "año", "mes", "semana" y "día". Este valor denota la unidad de tiempo que pasará antes de que se repita el evento/acción referido (si se define como un evento recurrente). Cuando pase ese período de tiempo, se generará una nueva instancia del mismo evento/acción.

Ahora estamos listos para llegar al corazón de esta área temática. En el event tabla, el usuario define todos los eventos que son importantes para él. Para cada evento, almacenaremos:

selected_date_id – Hace referencia a la definición de fecha.
event_catalog_id – Indica el tipo de evento.
description – Una descripción textual adicional de ese evento.
recurring – Una bandera que indica si el evento es recurrente.
recurrence_interval_id – Define la frecuencia con la que se repite el evento (año, mes, etc). Combinando la definición de fecha de selected_date con el intervalo de recurrencia nos permitirá definir el punto de inicio del evento y cuantos eventos después de ese punto de inicio se crearán automáticamente. De esta forma podríamos definir algo como:“A partir del 2 lunes de cada mes (el selected_date tabla), programe reuniones diarias automáticamente (el event.recurrence_interval atributo)” .
recurring_frequency – Un número que indica cuántas unidades (definido por recurrence_interval_id ) tienen que pasar antes de que este evento vuelva a ocurrir (si es un evento recurrente). Para el ejemplo anterior (reuniones diarias), definiríamos este valor como 1.
recurring_times – El número de instancias de este evento. Para el ejemplo anterior, esto sería "5" (reuniones diarias de lunes a viernes).

A continuación, necesitaremos relacionar personas (conocidas por el usuario) con eventos. Una lista de todas las personas insertadas por nuestros usuarios se almacena en el person mesa. Para cada persona, el usuario definirá un nombre completo y cualquier detalle adicional (si es necesario).

Ahora, estas personas pueden estar relacionadas con los eventos del usuario. En el related_event tabla, almacenaremos referencias al event y person así como algunos details de la naturaleza de esa relación. Tenga en cuenta que la misma persona podría agregarse varias veces para el mismo evento. Esto podría tener sentido si queremos mantener más de un registro para señalar específicamente algo especial (por ejemplo, "invitar a Sofía a la fiesta"; Sofía es tanto una invitada a la fiesta como la cantante de la banda en la fiesta).

Las dos tablas restantes en esta área temática están relacionadas con las definiciones de acción.

Las acciones pueden ser cualquier cosa relacionada con el evento. Por ejemplo, si queremos recordarnos el cumpleaños de mamá, sería genial que la aplicación nos dijera:“Empieza a pensar en el regalo que le quieres dar a tu mamá”, “Compra un regalo para el cumpleaños de mamá”, “Dale a mamá Regalo de cumpleaños. Y unos besos también” y finalmente “Lo has vuelto a hacer con éxito este año. ¡Bravo por ti (y por mí)!”.

Bien, pongámonos serios de nuevo. Las acciones son conjuntos de textos predefinidos que deberían notificar a los usuarios cuándo hacer algo. Tendremos un diccionario con tipos de acciones predefinidas como "empezar a pensar", "comprar un regalo", "encontrar un músico", etc. Una lista de todas estas acciones ÚNICAS se almacena en el action_catalog mesa. Al definir un evento, el usuario elegirá una o más action s relacionados con ese evento y defina los siguientes valores para cada uno de ellos:

event_id – El ID del evento relacionado.
action_catalog_id – Un valor seleccionado del action_catalog diccionario.
description – Una descripción opcional de esa acción. Cada vez que se active esta acción, nuestra aplicación observará este atributo, leerá los comandos y realizará esa acción.
action_code – Una definición textual estructurada de esa acción.
starts_before – Define cuántas unidades de tiempo seleccionadas transcurrirán antes del inicio de esta acción para el evento seleccionado (si se trata de una acción recurrente). Si este valor no está definido (es decir, está establecido en NULL), las acciones comenzarán en el mismo momento en que comienza el evento.
send_message – Una bandera que indica si se debe enviar un mensaje al usuario o no.
recurring – Indica si esta acción es recurrente o no.
recurring_interval_id – Indica el intervalo/unidad para la recurrencia (si se trata de una acción recurrente).
recurring_frequency – Indica el número de unidades seleccionadas que deben transcurrir entre dos recurrencias de la misma acción (si se trata de una acción recurrente).
recurring_times – ¿Cuántas instancias de esta acción crearemos?

La recurrencia de acciones sigue el mismo patrón que la recurrencia de eventos. Si la acción se define como recurrente, generaremos una nueva instancia de acción después del período de tiempo definido.

Sección 3:Eventos y Acciones (Reales)

Hasta ahora, hemos creado un modelo de datos que nos permitiría insertar eventos y definir acciones. Ahora pasaremos a una parte más interesante del modelo:eventos y acciones reales.

La event_instance La tabla contiene una lista de todos los eventos que se generaron automáticamente o se insertaron manualmente. Si bien la generación automática es bastante obvia, es por eso que creamos este modelo, la inserción manual de eventos también es una posibilidad. Podemos esperar que un evento se inserte automáticamente en el momento de su vencimiento, por lo que normalmente solo tenemos eventos actuales y pasados en esta tabla. Aún así, podría suceder que ya nos hayamos ocupado de algún evento futuro, p. nos hemos preparado para una reunión que tendrá lugar el próximo mes. En ese caso, deberíamos poder insertar manualmente un evento futuro (los tiempos de los eventos se propondrán de acuerdo con las reglas definidas) y todo lo relacionado con ese evento en esta tabla. Por otro lado, nuestra aplicación no sobrescribirá ni duplicará ese evento. Reconocerá los eventos que ya hemos insertado usando el event_time valor. Para cada instancia de evento, definiremos:

event_id – Hace referencia al event definición.
event_time – La hora real del evento, en formato de texto estructurado.
insert_ts – La marca de tiempo real cuando se insertó este evento.
event_completed – Un valor booleano que indica si el evento se completó o no. El evento se configura automáticamente como "completado" si se completan todas las acciones relacionadas. El usuario también puede configurarlo manualmente como "completado".

El event_id – event_time par es la clave alternativa/ÚNICA de esta tabla.

Se utiliza una lógica similar para action_instance mesa. Las acciones también se generarán automáticamente cuando venzan. Si una acción es recurrente, tendremos más de una acción definida para la misma instancia de evento. Para cada acción, definiremos:

action_id – Hace referencia a la action .
event_instance_id – Hace referencia al event_instance .
action_time – El tiempo real de la acción, en formato textual estructurado.
insert_ts – Una marca de tiempo real cuando se insertó este evento.
action_completed – Un valor booleano que indica si la acción se completó o no. El usuario configura la acción como "completada" manualmente. Si la instancia de acción se establece en "completada", no se generarán nuevas instancias (incluso si la definición dice que deberían).

En esta tabla, la clave alternativa/ÚNICA es la combinación de action_id – event_instance_id – action_time .

La última tabla de nuestro modelo es el message mesa. Se utiliza para almacenar los mensajes generados por las acciones. Estos mensajes se envían a los usuarios. Para cada mensaje, almacenaremos:

action_instance_id – El ID de la action_instance que generó este mensaje.
message_title – El título del mensaje.
message_text – El texto del mensaje, que contiene una descripción de por qué se generó este mensaje (es decir, campos de texto de las tablas relacionadas).
insert_ts – La marca de tiempo cuando se generó este mensaje.
message_read – Una bandera que indica si el mensaje ha sido leído por el usuario.

Comparta sus opiniones sobre el modelo de datos de eventos importantes

Espero que hayas disfrutado el artículo de hoy. ¿Alguna vez te has olvidado de una fecha importante? ¿Crees que este modelo podría ayudarte? Cuéntanos en los comentarios a continuación.