Il modello di dati delle date importanti

Stai dimenticando qualcosa? Un modello di dati per aiutarti a ricordare le date importanti, prima che accadano.

Hai mai dimenticato una data importante:il compleanno di tua madre o il tuo anniversario? O che stai tenendo una lezione? Sì, cose del genere accadono nella vita reale. Forse non per tutti noi, ma per alcuni di noi (me compreso), lo fanno sicuramente. Per prevenire tali disastri, creeremo un modello di dati che potresti utilizzare come sfondo per un'applicazione che ti avviserà in tempo.

È tempo di dire addio a tutte quelle facce deluse e tristi e ai regali che non sono stati acquistati in tempo. :)

Entriamo subito nel modello.

Il modello dei dati

Il nostro obiettivo è creare un modello di dati per un'applicazione che ci consenta di definire gli eventi futuri e tutte le azioni ad essi correlate. L'app dovrebbe avvisare gli utenti quando fanno una determinata cosa nella vita reale e contrassegnarla come completata quando è stata completata. Alcune attività si ripetono, ad es. quell'evento attiva un evento futuro in un momento che abbiamo definito.

Naturalmente, dovremo anche sviluppare applicazioni web e mobili per rendere questo sistema davvero utile. Ma per ora, concentriamoci sul modello di dati.

Il modello si compone di tre aree tematiche:

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

Descriveremo ciascuna di queste tre aree tematiche nell'ordine in cui sono elencate.

Sezione 1:Account utente e date

Gli utenti della nostra applicazione possono creare i propri profili utente e memorizzare date importanti a loro scelta. Per supportarlo, utilizzeremo le seguenti tabelle.

Il user_account La tabella è simile nella struttura a quelle descritte in molti articoli sui modelli di dati, ma ripetiamola ancora una volta. Per ogni utente memorizzeremo:

first_name e last_name – Il nome e il cognome dell'utente.
user_name – Il nome utente selezionato dall'utente.
password – Il valore hash della password selezionata dall'utente.
mobile – Il numero di cellulare fornito dall'utente.
email – L'e-mail utilizzata durante il processo di registrazione.
confirmation_code – Un codice di conferma inviato all'utente per completare la registrazione.
confirmation_time – Quando l'utente ha completato il processo di conferma.
insert_ts - Il timestamp in cui è stato inserito questo record.

Una volta completata la registrazione, l'utente potrà selezionare le proprie date importanti. Questo elenco è memorizzato nella tabella select_date. Anche se stiamo parlando di date, ciò che l'utente sta effettivamente selezionando sono regole che indicheranno le date. Descriveremo prima tutti gli attributi in questa tabella e poi discuteremo di come gli utenti possono impostare regole utilizzando tali attributi. Gli attributi sono:

user_account_id – L'ID dell'utente che ha inserito questo record.
date_year , date_month e date_day - Valori interi che rappresentano le parti della data (anno, mese e giorno del mese).
date_weekday – Una rappresentazione testuale del numero ordinale del giorno della settimana. Utilizziamo il testo perché consente agli utenti di selezionare valori più complessi:possono definire sia il giorno della settimana che la settimana del mese, ad es. il secondo lunedì di ogni mese.

Si prega di notare che tutte e quattro le parti della data potrebbero essere NULL. Non consentiremo record con tutti i valori NULL, quindi verificheremo a livello di codice che almeno una parte della data NON sia NULL.

E ora alcuni esempi:

Se vogliamo selezionare una data esatta, ad es. 31.12.2018, imposteremo i valori su date_year =2018, date_month =12 e date_day =31. Questo definisce qualcosa che accadrà solo una volta, in quella singola data.
Se utilizziamo la combinazione date_year =2019 e date_month =1, lasciando i restanti due valori NULL, allora stiamo definendo qualcosa che si ripeterà per tutto gennaio 2019.
La combinazione date_year =2019 e date_day =2 attiverebbe un evento il secondo giorno di ogni mese nel 2019.
Se inseriamo il valore , stiamo definendo qualcosa che accadrà il secondo lunedì di ogni mese.

Sezione 2:Eventi e azioni (Definizione)

Ho menzionato un vago "qualcosa", ma quel qualcosa è in realtà un evento. Eventi e azioni sono i motivi per cui siamo qui. Vogliamo mettere in relazione il dominio del tempo con eventi e azioni reali che accadranno in futuro. In questa area tematica, memorizzeremo le definizioni per tutti gli eventi e le azioni. Queste definizioni verranno successivamente utilizzate per creare eventi e azioni reali.

L'event table è sicuramente la tabella centrale in questa area tematica, ma prima di descriverla voglio descrivere due dizionari, il event_catalog e il recurrence_interval . Entrambi hanno la stessa struttura, con una chiave primaria a incremento automatico (id ) e l'attributo del nome UNIQUE.

Il event_catalog il dizionario memorizzerà valori come "compleanno", "festa nazionale", "anniversario" e "altro". Questo ci aiuterà a classificare i nostri eventi.

D'altra parte, il recurrence_interval memorizzerà valori come "anno", "mese", "settimana" e "giorno". Questo valore indica l'unità di tempo che trascorrerà prima che l'evento/azione riferito si ripeta (se è definito come evento ricorrente). Trascorso tale periodo di tempo, verrà generata una nuova istanza dello stesso evento/azione.

Ora siamo pronti per entrare nel vivo di questa area tematica. Nell'event tabella, l'utente definisce tutti gli eventi che sono importanti per lui. Per ogni evento memorizzeremo:

selected_date_id – Fa riferimento alla definizione della data.
event_catalog_id – Indica il tipo di evento.
description – Una descrizione testuale aggiuntiva di quell'evento.
recurring – Un flag che indica se l'evento è ricorrente.
recurrence_interval_id – Definisce la frequenza con cui l'evento si ripete (anno, mese, ecc.). Combinando la definizione della data da selected_date con l'intervallo di ricorrenza ci consentirà di definire il punto di inizio dell'evento e quanti eventi dopo tale punto di inizio verranno creati automaticamente. In questo modo potremmo definire qualcosa del tipo:"A partire dal 2 lunedì di ogni mese (il selected_date table), programma automaticamente le riunioni giornaliere (il event.recurrence_interval attributo)” .
recurring_frequency – Un numero che indica quante unità (definite da recurrence_interval_id ) devono passare prima che questo evento si ripeta (se si tratta di un evento ricorrente). Per l'esempio precedente (riunioni giornaliere), definiremmo questo valore come 1.
recurring_times – Il numero di istanze di questo evento. Per l'esempio precedente, questo sarebbe "5" (riunioni giornaliere dal lunedì al venerdì).

Successivamente, dovremo mettere in relazione le persone (conosciute dall'utente) con gli eventi. Un elenco di tutte le persone inserite dai nostri utenti è memorizzato nella person tavolo. Per ogni persona, l'utente definirà un nome completo ed eventuali dettagli aggiuntivi (se necessari).

Ora, queste persone possono essere correlate agli eventi dell'utente. Nel related_event tabella, memorizzeremo i riferimenti all'event e person così come alcuni details della natura di quel rapporto. Tieni presente che la stessa persona può essere aggiunta più volte per lo stesso evento. Questo potrebbe avere senso se vogliamo conservare più di un record per indicare in modo specifico qualcosa di speciale (ad es. "invita Sofia alla festa"; Sofia è sia un'ospite della festa che la cantante della band alla festa).

Le restanti due tabelle in questa area tematica sono relative alle definizioni di azioni.

Le azioni possono essere qualsiasi cosa correlata all'evento. Ad esempio, se vogliamo ricordarci il compleanno della mamma, sarebbe fantastico se l'applicazione ci dicesse:"Inizia a pensare al regalo che vuoi fare a tua madre", "Compra un regalo per il compleanno di mamma", "Dalla mamma lei Regalo di compleanno. E anche qualche bacio” e infine “Ci sei riuscito anche quest'anno con successo. Bravo per te (e per me)!”

Va bene, torniamo seri. Le azioni sono insiemi di testi predefiniti che dovrebbero avvisare gli utenti quando devono fare qualcosa. Avremo un dizionario con tipi di azioni predefiniti come "inizia a pensare", "compra un regalo", "trova un musicista", ecc. Un elenco di tutte queste azioni UNICHE è memorizzato nel action_catalog tavolo. Quando si definisce un evento, l'utente sceglierà una o più action s relativi a quell'evento e definire i seguenti valori per ciascuno di essi:

event_id – L'ID dell'evento correlato.
action_catalog_id – Un valore selezionato da action_catalog dizionario.
description – Una descrizione facoltativa di tale azione. Ogni volta che questa azione viene attivata, la nostra applicazione esaminerà questo attributo, leggerà i comandi ed eseguirà quell'azione.
action_code – Una definizione testuale strutturata di tale azione.
starts_before – Definisce quante unità di tempo selezionate trascorreranno prima dell'inizio di questa azione per l'evento selezionato (se si tratta di un'azione ricorrente). Se questo valore non è definito (cioè è impostato su NULL), le azioni inizieranno nello stesso momento in cui inizia l'evento.
send_message – Un flag che indica se un messaggio deve essere inviato o meno all'utente.
recurring – Indica se questa azione è ricorrente o meno.
recurring_interval_id – Indica l'intervallo/unità per la ricorrenza (se si tratta di un'azione ricorrente).
recurring_frequency – Indica il numero di unità selezionate che devono trascorrere tra due ricorrenze della stessa azione (se si tratta di un'azione ricorrente).
recurring_times – Quante istanze di questa azione creeremo?

La ricorrenza dell'azione segue lo stesso schema della ricorrenza dell'evento. Se l'azione è definita come ricorrente, genereremo una nuova istanza di azione dopo il periodo di tempo definito.

Sezione 3:Eventi e azioni (reali)

Finora abbiamo creato un modello di dati che ci permetterebbe di inserire eventi e definire azioni. Passiamo ora a una parte più interessante del modello:eventi e azioni reali.

Il event_instance tabella contiene un elenco di tutti gli eventi che sono stati generati automaticamente o inseriti manualmente. Sebbene la generazione automatica sia abbastanza ovvia, ecco perché abbiamo creato questo modello, anche l'inserimento manuale di eventi è una possibilità. Possiamo aspettarci che un evento venga inserito automaticamente al momento della scadenza, quindi normalmente avremmo solo eventi attuali e passati in questa tabella. Tuttavia, potrebbe succedere che ci siamo già occupati di qualche evento futuro, ad es. ci siamo preparati per un incontro che avrà luogo il mese prossimo. In tal caso, dovremmo essere in grado di inserire manualmente un evento futuro (gli orari degli eventi vengono proposti secondo regole definite) e tutto ciò che riguarda quell'evento in questa tabella. D'altra parte, la nostra applicazione non sovrascriverà né duplicherà quell'evento. Riconoscerà gli eventi che abbiamo già inserito utilizzando il event_time valore. Per ogni istanza di evento, definiremo:

event_id – Fa riferimento all'event definizione.
event_time – L'orario effettivo dell'evento, in formato testuale strutturato.
insert_ts – Il timestamp effettivo in cui è stato inserito questo evento.
event_completed – Un valore booleano che indica se l'evento è stato completato o meno. L'evento viene automaticamente impostato su "completato" se tutte le azioni correlate vengono completate. Può anche essere impostato manualmente su "completato" dall'utente.

Il event_id – event_time pair è la chiave alternativa/UNICA di questa tabella.

Una logica simile viene utilizzata per action_instance tavolo. Anche le azioni verranno generate automaticamente alla scadenza. Se un'azione è ricorrente, avremo più di un'azione definita per la stessa istanza di evento. Per ogni azione definiremo:

action_id – Fa riferimento all'action .
event_instance_id – Fa riferimento al relativo event_instance .
action_time – Il tempo effettivo dell'azione, in formato testuale strutturato.
insert_ts – Un timestamp effettivo quando è stato inserito questo evento.
action_completed – Un valore booleano che indica se l'azione è stata completata o meno. L'azione è impostata su "completata" manualmente dall'utente. Se l'istanza dell'azione è impostata su "completata", le nuove istanze non verranno generate (anche se la definizione dice che dovrebbero esserlo).

In questa tabella, la chiave alternativa/UNIQUE è la combinazione di action_id – event_instance_id – action_time .

L'ultima tabella nel nostro modello è il message tavolo. Viene utilizzato per memorizzare i messaggi generati dalle azioni. Questi messaggi vengono inviati agli utenti. Per ogni messaggio memorizzeremo:

action_instance_id – L'ID del action_instance che ha generato questo messaggio.
message_title – Il titolo del messaggio.
message_text – Il testo del messaggio, che contiene una descrizione del motivo per cui questo messaggio è stato generato (es. campi testuali delle relative tabelle).
insert_ts – Il timestamp in cui è stato generato questo messaggio.
message_read – Un flag che indica se il messaggio è stato letto dall'utente.

Condividi le tue opinioni sul modello di dati sugli eventi importanti

Spero che l'articolo di oggi ti sia piaciuto. Ti sei mai dimenticato di una data importante? Pensi che questo modello possa aiutarti? Per favore, dicci nei commenti qui sotto.