Le modèle de données des dates importantes

Vous oubliez quelque chose ? Un modèle de données pour vous aider à vous souvenir des dates importantes - avant qu'elles ne surviennent.

Avez-vous déjà oublié une date importante - l'anniversaire de votre mère ou votre anniversaire? Ou que vous donnez une conférence? Oui, des choses comme ça arrivent dans la vraie vie. Peut-être pas pour nous tous, mais pour certains d'entre nous (dont moi), ils le font certainement. Pour éviter de tels désastres, nous créerons un modèle de données que vous pourrez utiliser comme arrière-plan pour une application qui vous avertira à temps.

Il est temps de dire au revoir à tous ces visages déçus et tristes et aux cadeaux qui n'ont pas été achetés à temps. :)

Plongeons-nous directement dans le modèle.

Le modèle de données

Notre objectif est de créer un modèle de données pour une application qui nous permettrait de définir les événements futurs et toutes les actions qui y sont liées. L'application doit avertir les utilisateurs lorsqu'ils font une certaine chose dans la vie réelle et marquer cette chose comme terminée lorsqu'elle est terminée. Certaines tâches se répètent, par ex. cet événement déclenche un événement futur à un moment que nous avons défini.

Bien sûr, nous devrons également développer des applications Web et mobiles pour rendre ce système vraiment utile. Mais pour l'instant, concentrons-nous sur le modèle de données.

Le modèle se compose de trois domaines :

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

Nous décrirons chacun de ces trois domaines dans l'ordre dans lequel ils sont répertoriés.

Section 1 :Comptes d'utilisateurs et dates

Les utilisateurs de notre application peuvent créer leurs propres profils d'utilisateurs et stocker les dates importantes de leur choix. Pour soutenir cela, nous utiliserons les tableaux suivants.

Le user_account table est similaire dans sa structure à celles décrites dans de nombreux articles sur les modèles de données, mais répétons-le encore une fois. Pour chaque utilisateur, nous stockerons :

first_name et last_name – Le prénom et le nom de l'utilisateur.
user_name – Le nom d'utilisateur sélectionné par l'utilisateur.
password – La valeur de hachage du mot de passe sélectionné par l'utilisateur.
mobile – Le numéro de téléphone portable fourni par l'utilisateur.
email – L'e-mail utilisé lors du processus d'inscription.
confirmation_code – Un code de confirmation envoyé à l'utilisateur pour finaliser son inscription.
confirmation_time – Lorsque l'utilisateur a terminé le processus de confirmation.
insert_ts - L'horodatage auquel cet enregistrement a été inséré.

Une fois l'inscription terminée, l'utilisateur pourra sélectionner ses propres dates importantes. Cette liste est stockée dans la table selected_date. Bien que nous parlions de dates, ce que l'utilisateur sélectionne en fait, ce sont des règles qui indiqueront les dates. Nous décrirons d'abord tous les attributs de ce tableau, puis nous expliquerons comment les utilisateurs peuvent définir des règles à l'aide de ces attributs. Les attributs sont :

user_account_id – L'identifiant de l'utilisateur qui a inséré cet enregistrement.
date_year , date_month , et date_day - Valeurs entières représentant les parties de date (année, mois et jour du mois).
date_weekday – Une représentation textuelle du nombre ordinal du jour de la semaine. Nous utilisons du texte car il permet aux utilisateurs de sélectionner des valeurs plus complexes - ils peuvent définir à la fois le jour de la semaine et la semaine du mois, par ex. le deuxième lundi de chaque mois.

Veuillez noter que les quatre parties de date peuvent être NULL. Nous n'autoriserons pas les enregistrements avec toutes les valeurs NULL, nous allons donc vérifier par programme qu'au moins une partie de date est NOT NULL.

Et maintenant quelques exemples :

Si nous voulons sélectionner une date exacte, par ex. 31.12.2018, nous définirons les valeurs sur date_year =2018, date_month =12, et date_day =31. Cela définit quelque chose qui ne se produira qu'une seule fois, à cette seule date.
Si nous utilisons la combinaison date_year =2019 et date_month =1, en laissant les deux valeurs restantes NULL, alors nous définissons quelque chose qui se répétera pendant tout le mois de janvier 2019.
La combinaison date_year =2019 et date_day =2 déclencherait un événement le deuxième jour de chaque mois en 2019.
Si nous insérons la valeur , nous définissons quelque chose qui se produira le deuxième lundi de chaque mois.

Section 2 :Événements et actions (définition)

J'ai mentionné un vague "quelque chose", mais ce quelque chose est en fait un événement. Les événements et les actions sont les raisons pour lesquelles nous sommes ici. Nous voulons relier le domaine temporel aux événements et actions réels qui se produiront dans le futur. Dans ce domaine, nous stockerons les définitions de tous les événements et actions. Ces définitions seront ensuite utilisées pour créer des événements et des actions réels.

L'événement event table est définitivement la table centrale dans ce domaine, mais avant de la décrire, je veux décrire deux dictionnaires, le event_catalog et le recurrence_interval . Les deux ont la même structure, avec une clé primaire auto-incrémentée (id ) et l'attribut de nom UNIQUE.

Le event_catalog dictionnaire stockera des valeurs telles que "anniversaire", "jour férié", "anniversaire" et "autre". Cela nous aidera à classer nos événements.

D'autre part, le recurrence_interval stockera des valeurs telles que "année", "mois", "semaine" et "jour". Cette valeur indique l'unité de temps qui s'écoulera avant que l'événement/l'action référencé ne se répète (s'il est défini comme un événement récurrent). Une fois cette période écoulée, une nouvelle instance du même événement/action sera générée.

Nous sommes maintenant prêts à entrer dans le vif du sujet. Dans l'événement event tableau, l'utilisateur définit tous les événements qui sont importants pour lui. Pour chaque événement, nous stockerons :

selected_date_id – Fait référence à la définition de la date.
event_catalog_id – Indique le type d'événement.
description – Une description textuelle supplémentaire de cet événement.
recurring – Un indicateur indiquant si l'événement est récurrent.
recurrence_interval_id – Définit la fréquence de répétition de l'événement (année, mois, etc.). Combinaison de la définition de date de selected_date avec l'intervalle de récurrence nous permettra de définir le point de départ de l'événement et combien d'événements après ce point de départ seront créés automatiquement. De cette façon, nous pourrions définir quelque chose comme :« À partir du 2 lundi de chaque mois (le selected_date table), planifier automatiquement des réunions quotidiennes (le event.recurrence_interval attribut)" .
recurring_frequency – Un nombre indiquant le nombre d'unités (défini par recurrence_interval_id ) doivent passer avant que cet événement ne se reproduise (s'il s'agit d'un événement récurrent). Pour l'exemple précédent (réunions quotidiennes), nous définirions cette valeur comme 1.
recurring_times – Le nombre d'instances de cet événement. Pour l'exemple précédent, ce serait "5" (réunions quotidiennes du lundi au vendredi).

Ensuite, nous devrons associer des personnes (connues de l'utilisateur) à des événements. Une liste de toutes les personnes insérées par nos utilisateurs est stockée dans le person table. Pour chaque personne, l'utilisateur définira un nom complet et des détails supplémentaires (si nécessaire).

Maintenant, ces personnes peuvent être liées aux événements de l'utilisateur. Dans le related_event table, nous stockerons les références à l'event et person ainsi que quelques details de la nature de cette relation. Veuillez noter qu'une même personne peut être ajoutée plusieurs fois pour le même événement. Cela peut avoir du sens si nous voulons conserver plus d'un enregistrement pour indiquer spécifiquement quelque chose de spécial (par exemple, "inviter Sofia à la fête" ; Sofia est à la fois une invitée à la fête et la chanteuse du groupe à la fête).

Les deux autres tableaux de ce domaine sont liés aux définitions d'action.

Les actions peuvent être n'importe quoi lié à l'événement. Par exemple, si nous voulons nous rappeler l'anniversaire de maman, ce serait bien si l'application nous disait :"Commencez à penser au cadeau que vous voulez offrir à votre maman", "Achetez un cadeau pour l'anniversaire de maman", "Offrez-lui à maman Cadeau du jour B. Et quelques bisous aussi » et enfin « Tu as encore réussi cette année. Bravo pour vous (et pour moi) !”

Bon, revenons au sérieux. Les actions sont des ensembles de textes prédéfinis qui doivent avertir les utilisateurs quand faire quelque chose. Nous aurons un dictionnaire avec des types d'action prédéfinis comme "commencer à réfléchir", "acheter un cadeau", "trouver un musicien", etc. Une liste de toutes ces actions UNIQUES est stockée dans le action_catalog table. Lors de la définition d'un événement, l'utilisateur choisira une ou plusieurs action s liés à cet événement et définissez les valeurs suivantes pour chacun d'eux :

event_id – L'identifiant de l'événement associé.
action_catalog_id – Une valeur sélectionnée dans le action_catalog dictionnaire.
description – Une description facultative de cette action. Chaque fois que cette action est déclenchée, notre application examinera cet attribut, lira les commandes et effectuera cette action.
action_code – Une définition textuelle structurée de cette action.
starts_before – Définit le nombre d'unités de temps sélectionnées qui s'écouleront avant le début de cette action pour l'événement sélectionné (s'il s'agit d'une action récurrente). Si cette valeur n'est pas définie (c'est-à-dire qu'elle est définie sur NULL), les actions démarreront au même moment que l'événement.
send_message – Un indicateur indiquant si un message doit être envoyé à l'utilisateur ou non.
recurring – Indique si cette action est récurrente ou non.
recurring_interval_id – Indique l'intervalle/l'unité de la récurrence (s'il s'agit d'une action récurrente).
recurring_frequency – Indique le nombre d'unités sélectionnées qui doivent s'écouler entre deux répétitions de la même action (s'il s'agit d'une action récurrente).
recurring_times – Combien d'instances de cette action allons-nous créer ?

La récurrence des actions suit le même schéma que la récurrence des événements. Si l'action est définie comme récurrente, nous générerons une nouvelle instance d'action après la période définie.

Section 3 :Événements et actions (réels)

Jusqu'à présent, nous avons créé un modèle de données qui nous permettrait d'insérer des événements et de définir des actions. Passons maintenant à une partie plus intéressante du modèle :les événements et actions réels.

Le event_instance table contient une liste de tous les événements qui ont été générés automatiquement ou insérés manuellement. Bien que la génération automatique soit assez évidente - c'est pourquoi nous avons créé ce modèle - l'insertion manuelle d'événements est également une possibilité. Nous pouvons nous attendre à ce qu'un événement soit inséré automatiquement au moment où il est dû, donc nous n'aurions normalement que des événements actuels et passés dans ce tableau. Pourtant, il peut arriver que nous nous soyons déjà occupés d'un événement futur, par ex. nous avons préparé une réunion qui aura lieu le mois prochain. Dans ce cas, nous devrions pouvoir insérer manuellement un événement futur (les horaires des événements étant proposés selon des règles définies) et tout ce qui concerne cet événement dans cette table. D'autre part, notre application n'écrasera ni ne dupliquera cet événement. Il reconnaîtra les événements que nous avons déjà insérés en utilisant le event_time valeur. Pour chaque instance d'événement, nous définirons :

event_id – Fait référence à l'event définition.
event_time – L'heure réelle de l'événement, dans un format textuel structuré.
insert_ts – L'horodatage réel auquel cet événement a été inséré.
event_completed – Une valeur booléenne indiquant si l'événement s'est terminé ou non. L'événement est automatiquement défini sur "terminé" si toutes les actions associées sont terminées. Il peut également être défini manuellement sur "terminé" par l'utilisateur.

Le event_id – event_time paire est la clé alternative/UNIQUE de cette table.

Une logique similaire est utilisée pour action_instance table. Les actions seront également générées automatiquement lorsqu'elles sont dues. Si une action est récurrente, plusieurs actions seront définies pour la même instance d'événement. Pour chaque action, nous définirons :

action_id – Référence l'action .
event_instance_id – Référence le event_instance .
action_time – L'heure réelle de l'action, dans un format textuel structuré.
insert_ts – Un horodatage réel lorsque cet événement a été inséré.
action_completed – Une valeur booléenne indiquant si l'action s'est terminée ou non. L'action est définie sur "terminée" manuellement par l'utilisateur. Si l'instance d'action est définie sur "terminée", de nouvelles instances ne seront pas générées (même si la définition indique qu'elles devraient l'être).

Dans ce tableau, la clé alternative/UNIQUE est la combinaison de action_id – event_instance_id – action_time .

Le dernier tableau de notre modèle est le message table. Il est utilisé pour stocker les messages générés par les actions. Ces messages sont envoyés aux utilisateurs. Pour chaque message, nous stockerons :

action_instance_id – L'ID de l'action_instance qui a généré ce message.
message_title – Le titre du message.
message_text – Le texte du message, qui contient une description de la raison pour laquelle ce message a été généré (c'est-à-dire les champs textuels des tables associées).
insert_ts – L'horodatage auquel ce message a été généré.
message_read – Un indicateur indiquant si le message a été lu par l'utilisateur.

Partagez vos réflexions sur le modèle de données des événements importants

J'espère que vous avez apprécié l'article d'aujourd'hui. Avez-vous déjà oublié une date importante ? Pensez-vous que ce modèle pourrait vous aider ? Veuillez nous le dire dans les commentaires ci-dessous.