Datamodellen for vigtige datoer

Glemmer du noget? En datamodel, der hjælper dig med at huske vigtige datoer – før de sker.

Har du nogensinde glemt en vigtig dato - din mors fødselsdag eller dit jubilæum? Eller at du holder et foredrag? Ja, sådan noget sker i det virkelige liv. Måske ikke for os alle, men for nogle af os (inklusive mig) gør de det bestemt. For at forhindre sådanne katastrofer opretter vi en datamodel, du kan bruge som baggrund for en applikation, der giver dig besked til tiden.

Det er tid til at sige farvel til alle de skuffede og triste ansigter og til gaver, der ikke blev købt til tiden. :)

Lad os dykke direkte ned i modellen.

Datamodellen

Vores mål er at skabe en datamodel for en applikation, der giver os mulighed for at definere fremtidige begivenheder og alle handlinger relateret til dem. Appen skal underrette brugerne, når de gør en bestemt ting i det virkelige liv, og markere den ting som udført, når den er afsluttet. Nogle opgaver går igen, f.eks. denne hændelse udløser en fremtidig hændelse på et tidspunkt, vi har defineret.

Selvfølgelig skal vi også udvikle web- og mobilapplikationer for at gøre dette system virkelig nyttigt. Men for nu, lad os fokusere på datamodellen.

Modellen består af tre fagområder:

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

Vi vil beskrive hvert af disse tre emneområder i den rækkefølge, de er anført.

Afsnit 1:Brugerkonti og datoer

Brugere af vores applikation kan oprette deres egne brugerprofiler og gemme vigtige datoer efter eget valg. For at understøtte det bruger vi følgende tabeller.

user_account tabel ligner i strukturen dem, der er beskrevet i mange datamodelartikler, men lad os gentage det igen. For hver bruger gemmer vi:

first_name og last_name – Brugerens for- og efternavn.
user_name – Brugerens valgte brugernavn.
password – Hashværdien af den adgangskode, som brugeren valgte.
mobile – Mobilnummeret oplyst af brugeren.
email – Den e-mail, der blev brugt under registreringsprocessen.
confirmation_code – En bekræftelseskode sendt til brugeren for at fuldføre deres registrering.
confirmation_time – Når brugeren fuldførte bekræftelsesprocessen.
insert_ts - Tidsstemplet, da denne post blev indsat.

Efter registreringen er gennemført, vil brugeren være i stand til at vælge deres egne vigtige datoer. Denne liste er gemt i tabellen valgte_dato. Selvom vi taler om datoer, er det, som brugeren faktisk vælger, regler, der vil angive datoer. Vi vil først beskrive alle attributterne i denne tabel, og derefter vil vi diskutere, hvordan brugere kan angive regler ved hjælp af disse attributter. Attributterne er:

user_account_id – ID'et på den bruger, der indsatte denne post.
date_year , date_month og date_day - Heltalsværdier, der repræsenterer datodelene (år, måned og dag i måneden).
date_weekday – En tekstlig gengivelse af ugedagens ordenstal. Vi bruger tekst, fordi det giver brugerne mulighed for at vælge mere komplekse værdier - de kan definere både ugedagen og ugen i måneden, f.eks. den anden mandag i hver måned.

Bemærk, at alle fire datodele kan være NULL. Vi tillader ikke poster med alle NULL-værdier, så vi kontrollerer programmatisk, at mindst én datodel IKKE er NULL.

Og nu et par eksempler:

Hvis vi vil vælge en nøjagtig dato, f.eks. 31.12.2018 indstiller vi værdierne til date_year =2018, date_month =12 og date_day =31. Dette definerer noget, der kun vil ske én gang, på den enkelte dato.
Hvis vi bruger kombinationen date_year =2019 og date_month =1, efterlader de resterende to værdier NULL, så definerer vi noget, der gentages i hele januar 2019.
Kombinationen date_year =2019 og date_day =2 ville udløse en begivenhed den anden dag i hver måned i 2019.
Hvis vi indsætter værdien , vi definerer noget, der vil ske den anden mandag i hver måned.

Afsnit 2:Hændelser og handlinger (definition)

Jeg har nævnt et vagt "noget", men at noget faktisk er en begivenhed. Begivenheder og handlinger er grundene til, at vi er her. Vi ønsker at relatere tidsdomænet med faktiske begivenheder og handlinger, der vil ske i fremtiden. I dette emneområde gemmer vi definitionerne for alle begivenheder og handlinger. Disse definitioner vil senere blive brugt til at skabe faktiske begivenheder og handlinger.

event tabel er absolut den centrale tabel i dette emneområde, men før jeg beskriver den, vil jeg beskrive to ordbøger, event_catalog og recurrence_interval . Begge har den samme struktur med en auto-inkrementerende primærnøgle (id ) og attributten UNIQUE name.

event_catalog ordbogen vil gemme værdier som "fødselsdag", "helligdag", "jubilæum" og "andet". Dette vil hjælpe os med at klassificere vores begivenheder.

På den anden side er recurrence_interval vil gemme værdier som "år", "måned", "uge" og "dag". Denne værdi angiver enheden for den tid, der vil gå, før den omtalte hændelse/handling gentages (hvis den er defineret som en tilbagevendende hændelse). Når denne tidsperiode er gået, vil en ny forekomst af den samme hændelse/handling blive genereret.

Nu er vi klar til at komme ind til kernen af dette fagområde. I event tabel, definerer brugeren alle de begivenheder, der er vigtige for dem. For hver begivenhed gemmer vi:

selected_date_id – Refererer til datodefinitionen.
event_catalog_id – Angiver begivenhedens type.
description – En yderligere tekstbeskrivelse af den begivenhed.
recurring – Et flag, der angiver, om begivenheden er tilbagevendende.
recurrence_interval_id – Definerer, hvor ofte begivenheden gentages (år, måned osv.). Kombinerer datodefinitionen fra selected_date med gentagelsesintervallet vil gøre det muligt for os at definere startpunktet for begivenheden, og hvor mange begivenheder efter dette startpunkt vil blive oprettet automatisk. På denne måde kunne vi definere noget som:“Startende fra den 2 mandag i hver måned (den selected_date tabel), planlægger automatisk daglige møder (event.recurrence_interval attribut)" .
recurring_frequency – Et tal, der angiver, hvor mange enheder (defineret ved recurrence_interval_id ) skal bestå, før denne begivenhed finder sted igen (hvis det er en tilbagevendende begivenhed). For det foregående eksempel (daglige møder) ville vi definere denne værdi som 1.
recurring_times – Antallet af tilfælde af denne begivenhed. For det foregående eksempel ville dette være "5" (daglige møder fra mandag til fredag).

Dernæst skal vi relatere personer (kendt af brugeren) til begivenheder. En liste over alle personer, der er indsat af vores brugere, er gemt i person bord. For hver person vil brugeren definere et fulde navn og eventuelle yderligere detaljer (hvis nødvendigt).

Nu kan disse personer relateres til brugerens begivenheder. I related_event tabel, gemmer vi referencer til event og person samt nogle details af arten af dette forhold. Bemærk venligst, at den samme person kan tilføjes flere gange til den samme begivenhed. Dette kunne give mening, hvis vi vil beholde mere end én plade for specifikt at pege på noget særligt (f.eks. "inviter Sofia til festen"; Sofia er både festgæst og sangerinde for bandet til festen).

De resterende to tabeller i dette emneområde er relateret til handlingsdefinitioner.

Handlinger kan være alt relateret til begivenheden. Hvis vi for eksempel vil minde os selv om mors fødselsdag, ville det være fantastisk, hvis applikationen fortæller os:"Begynd at tænke på den gave, du vil give din mor", "Køb en gave til mors fødselsdag", "Giv mor hende B-dags gave. Og et par kys også" og til sidst "Du har gjort det med succes igen i år. Bravo for dig (og for mig)!"

Okay, lad os blive seriøse igen. Handlinger er sæt af foruddefinerede tekster, der skal give brugerne besked, når de skal gøre noget. Vi har en ordbog med foruddefinerede handlingstyper som "begynd at tænke", "køb en gave", "find en musiker" osv. En liste over alle sådanne UNIKKE handlinger er gemt i action_catalog bord. Når brugeren definerer en begivenhed, vælger en eller flere action s relateret til den hændelse og definere følgende værdier for hver af dem:

event_id – ID'et for den relaterede hændelse.
action_catalog_id – En valgt værdi fra action_catalog ordbog.
description – En valgfri beskrivelse af den pågældende handling. Hver gang denne handling udløses, vil vores applikation se på denne attribut, læse kommandoerne og udføre den handling.
action_code – En struktureret tekstmæssig definition af den handling.
starts_before – Definerer, hvor mange valgte tidsenheder, der vil gå før starten af denne handling for den valgte hændelse (hvis dette er en tilbagevendende handling). Hvis denne værdi ikke er defineret (dvs. er indstillet til NULL), vil handlingerne starte i samme øjeblik, begivenheden starter.
send_message – Et flag, der angiver, om en besked skal sendes til brugeren eller ej.
recurring – Angiver, om denne handling er tilbagevendende eller ej.
recurring_interval_id – Angiver intervallet/enheden for gentagelsen (hvis dette er en tilbagevendende handling).
recurring_frequency – Angiver antallet af valgte enheder, der skal gå mellem to gentagelser af den samme handling (hvis dette er en tilbagevendende handling).
recurring_times – Hvor mange forekomster af denne handling skal vi oprette?

Gentagelse af handlinger følger det samme mønster som gentagelse af begivenheder. Hvis handlingen er defineret som tilbagevendende, genererer vi en ny handlingsforekomst efter den definerede tidsperiode.

Afsnit 3:Begivenheder og handlinger (rigtige)

Indtil videre har vi lavet en datamodel, der ville gøre os i stand til at indsætte begivenheder og definere handlinger. Nu vil vi gå til en mere interessant del af modellen:faktiske begivenheder og handlinger.

event_instance tabel indeholder en liste over alle hændelser, der er blevet genereret automatisk eller indsat manuelt. Selvom autogenerering er ret indlysende - det er derfor, vi har skabt denne model - er manuel hændelsesindsættelse også en mulighed. Vi kan forvente, at en begivenhed vil blive indsat automatisk på det tidspunkt, den er forfalden, så vi har normalt kun faktiske og tidligere begivenheder i denne tabel. Alligevel kan det ske, at vi allerede har taget os af en eller anden fremtidig begivenhed, f.eks. vi har forberedt et møde, der finder sted i næste måned. I så fald skulle vi være i stand til manuelt at indsætte en fremtidig hændelse (hændelsestidspunkter foreslås i henhold til definerede regler) og alt relateret til den hændelse i denne tabel. På den anden side vil vores applikation ikke overskrive eller duplikere denne begivenhed. Den genkender begivenheder, vi allerede har indsat ved at bruge event_time værdi. For hver begivenhedsforekomst definerer vi:

event_id – Henviser til event definition.
event_time – Den faktiske begivenhedstid i struktureret tekstformat.
insert_ts – Det faktiske tidsstempel, da denne begivenhed blev indsat.
event_completed – En boolsk værdi, der angiver, om hændelsen blev gennemført eller ej. Hændelsen indstilles automatisk til 'fuldført', hvis alle relaterede handlinger er gennemført. Den kan også manuelt indstilles til 'fuldført' af brugeren.

event_id – event_time par er den alternative/UNIKKE nøgle i denne tabel.

Lignende logik bruges til action_instance bord. Handlinger vil også blive genereret automatisk, når de forfalder. Hvis en handling er tilbagevendende, har vi mere end én handling defineret for den samme hændelsesinstans. For hver handling definerer vi:

action_id – Henviser til den relaterede action .
event_instance_id – Refererer til den relaterede event_instance .
action_time – Det faktiske tidspunkt for handlingen i struktureret tekstformat.
insert_ts – Et faktisk tidsstempel, da denne begivenhed blev indsat.
action_completed – En boolsk værdi, der angiver, om handlingen blev fuldført eller ej. Handlingen indstilles til 'fuldført' manuelt af brugeren. Hvis handlingsforekomsten er indstillet til "fuldført", vil nye forekomster ikke blive genereret (selvom definitionen siger, at de burde være det).

I denne tabel er den alternative/UNIQUE-nøgle kombinationen af action_id – event_instance_id – action_time .

Den sidste tabel i vores model er message bord. Det bruges til at gemme meddelelser genereret af handlinger. Disse beskeder sendes til brugerne. For hver besked gemmer vi:

action_instance_id – ID'et for action_instance der genererede denne besked.
message_title – Meddelelsens titel.
message_text – Meddelelsesteksten, som indeholder en beskrivelse af, hvorfor denne besked blev genereret (dvs. tekstfelter fra de relaterede tabeller).
insert_ts – Tidsstemplet, da denne meddelelse blev genereret.
message_read – Et flag, der angiver, om meddelelsen er blevet læst af brugeren.

Del dine tanker om datamodellen for vigtige begivenheder

Jeg håber, du har nydt dagens artikel. Har du nogensinde glemt en vigtig date? Tror du, at denne model kan hjælpe dig? Fortæl os venligst i kommentarerne nedenfor.