Datamodellen för viktiga datum

Glömmer du något? En datamodell som hjälper dig komma ihåg viktiga datum – innan de inträffar.

Har du någonsin glömt ett viktigt datum - din mammas födelsedag eller din årsdag? Eller att du håller en föreläsning? Ja, sådana saker händer i verkligheten. Kanske inte för oss alla, men för några av oss (inklusive mig) gör de det verkligen. För att förhindra sådana katastrofer skapar vi en datamodell som du kan använda som bakgrund för en applikation som kommer att meddela dig i tid.

Det är dags att säga hejdå till alla dessa besvikna och ledsna ansikten och till presenter som inte köptes i tid. :)

Låt oss dyka rakt in i modellen.

Datamodellen

Vårt mål är att skapa en datamodell för en applikation som skulle tillåta oss att definiera framtida händelser och alla åtgärder relaterade till dem. Appen bör meddela användare när de gör en viss sak i verkligheten och markera den saken som klar när den är klar. Vissa uppgifter går igen, t.ex. den händelsen utlöser en framtida händelse vid en tidpunkt som vi har definierat.

Naturligtvis måste vi också utveckla webb- och mobilapplikationer för att göra det här systemet riktigt användbart. Men låt oss nu fokusera på datamodellen.

Modellen består av tre ämnesområden:

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

Vi kommer att beskriva vart och ett av dessa tre ämnesområden i den ordning de är listade.

Avsnitt 1:Användarkonton och datum

Användare av vår applikation kan skapa sina egna användarprofiler och lagra viktiga datum som de själva väljer. För att stödja det använder vi följande tabeller.

user_account Tabellen liknar strukturen de som beskrivs i många datamodellartiklar, men låt oss upprepa det igen. För varje användare lagrar vi:

first_name och last_name – Användarens för- och efternamn.
user_name – Användarens valda användarnamn.
password – Hashvärdet för lösenordet som användaren valde.
mobile – Mobilnumret som användaren angett.
email – E-postadressen som användes under registreringsprocessen.
confirmation_code – En bekräftelsekod som skickas till användaren för att slutföra sin registrering.
confirmation_time – När användaren slutfört bekräftelseprocessen.
insert_ts - Tidsstämpeln när denna post infogades.

Efter att registreringen är klar kommer användaren att kunna välja sina egna viktiga datum. Denna lista lagras i tabellen select_date. Även om vi pratar om datum, vad användaren faktiskt väljer är regler som kommer att beteckna datum. Vi kommer först att beskriva alla attribut i den här tabellen och sedan diskuterar vi hur användare kan ställa in regler med dessa attribut. Attributen är:

user_account_id – ID för användaren som infogade denna post.
date_year , date_month och date_day - Heltalsvärden som representerar datumdelarna (år, månad och dag i månaden).
date_weekday – En textuell representation av veckodagens ordningsnummer. Vi använder text eftersom det tillåter användare att välja mer komplexa värden – de kan definiera både veckodag och vecka i månaden, t.ex. andra måndagen i varje månad.

Observera att alla fyra datumdelarna kan vara NULL. Vi tillåter inte poster med alla NULL-värden, så vi kontrollerar programmatiskt att minst en datumdel INTE är NULL.

Och nu några exempel:

Om vi vill välja ett exakt datum, t.ex. 31.12.2018 ställer vi in värden till date_year =2018, date_month =12 och date_day =31. Detta definierar något som bara kommer att hända en gång, på det enda datumet.
Om vi använder kombinationen date_year =2019 och date_month =1, lämnar de återstående två värdena NULL, då definierar vi något som kommer att upprepas under hela januari 2019.
Kombinationen date_year =2019 och date_day =2 skulle utlösa en händelse den andra dagen i varje månad under 2019.
Om vi infogar värdet , vi definierar något som kommer att hända den andra måndagen i varje månad.

Avsnitt 2:Händelser och åtgärder (definition)

Jag har nämnt ett vagt "något", men det är faktiskt en händelse. Händelser och handlingar är anledningarna till att vi är här. Vi vill relatera tidsdomänen med faktiska händelser och handlingar som kommer att hända i framtiden. I detta ämnesområde kommer vi att lagra definitionerna för alla händelser och åtgärder. Dessa definitioner kommer senare att användas för att skapa faktiska händelser och handlingar.

event tabellen är definitivt den centrala tabellen i detta ämnesområde, men innan jag beskriver den vill jag beskriva två ordböcker, event_catalog och recurrence_interval . Båda har samma struktur, med en auto-inkrementerande primärnyckel (id ) och attributet UNIQUE name.

event_catalog ordboken kommer att lagra värden som "födelsedag", "allmän helgdag", "årsdag" och "annat". Detta kommer att hjälpa oss att klassificera våra evenemang.

Å andra sidan, recurrence_interval kommer att lagra värden som "år", "månad", "vecka" och "dag". Detta värde anger enheten för tiden som kommer att gå innan den refererade händelsen/åtgärden upprepas (om den definieras som en återkommande händelse). När den tidsperioden går kommer en ny instans av samma händelse/åtgärd att genereras.

Nu är vi redo att komma till hjärtat av detta ämnesområde. I event tabell, definierar användaren alla händelser som är viktiga för dem. För varje evenemang lagrar vi:

selected_date_id – Refererar till datumdefinitionen.
event_catalog_id – Anger typen av händelse.
description – En ytterligare textbeskrivning av den händelsen.
recurring – En flagga som anger om händelsen är återkommande.
recurrence_interval_id – Definierar hur ofta händelsen upprepas (år, månad, etc). Kombinera datumdefinitionen från selected_date med upprepningsintervallet kommer vi att kunna definiera startpunkten för händelsen och hur många händelser efter den startpunkten som kommer att skapas automatiskt. På så sätt kan vi definiera något i stil med:“Från och med den 2 måndagen i varje månad (den selected_date tabell), schemalägga dagliga möten automatiskt (event.recurrence_interval attribut)” .
recurring_frequency – Ett tal som anger hur många enheter (definieras av recurrence_interval_id ) måste passera innan denna händelse äger rum igen (om det är en återkommande händelse). För det föregående exemplet (dagliga möten) skulle vi definiera detta värde som 1.
recurring_times – Antalet tillfällen av denna händelse. För det föregående exemplet skulle detta vara "5" (dagliga möten från måndag till fredag).

Därefter måste vi relatera personer (kända av användaren) med händelser. En lista över alla personer som infogats av våra användare lagras i person tabell. För varje person kommer användaren att definiera ett fullständigt namn och eventuella ytterligare detaljer (om det behövs).

Nu kan dessa personer relateras till användarens händelser. I related_event tabell lagrar vi referenser till event och person samt några details av det förhållandets natur. Observera att samma person kan läggas till flera gånger för samma evenemang. Detta kan vara vettigt om vi vill behålla mer än en skiva för att specifikt peka på något speciellt (t.ex. "bjud in Sofia till festen"; Sofia är både festgäst och sångerska för bandet på festen).

De återstående två tabellerna i detta ämnesområde är relaterade till åtgärdsdefinitioner.

Åtgärder kan vara vad som helst relaterat till händelsen. Till exempel, om vi vill påminna oss själva om mammas födelsedag, skulle det vara bra om applikationen säger till oss:"Börja tänka på presenten du vill ge din mamma", "Köp en present till mammas födelsedag", "Ge mamma henne B-dagspresent. Och några kyssar också" och till sist "Du har gjort det framgångsrikt i år igen. Bravo för dig (och för mig)!"

Okej, låt oss bli seriösa igen. Åtgärder är uppsättningar av fördefinierade texter som ska meddela användarna när de ska göra något. Vi kommer att ha en ordbok med fördefinierade handlingstyper som "börja tänka", "köpa en gåva", "hitta en musiker" etc. En lista över alla sådana UNIKA åtgärder finns lagrade i action_catalog tabell. När användaren definierar en händelse kommer användaren att välja en eller flera action s relaterade till den händelsen och definiera följande värden för var och en av dem:

event_id – ID för den relaterade händelsen.
action_catalog_id – Ett valt värde från action_catalog ordbok.
description – En valfri beskrivning av den åtgärden. Varje gång den här åtgärden utlöses kommer vår applikation att titta på det här attributet, läsa kommandona och utföra den åtgärden.
action_code – En strukturerad textdefinition av den åtgärden.
starts_before – Definierar hur många valda tidsenheter som ska förflyta innan den här åtgärden startar för den valda händelsen (om detta är en återkommande åtgärd). Om detta värde inte är definierat (dvs. är satt till NULL), kommer åtgärderna att starta i samma ögonblick som händelsen startar.
send_message – En flagga som anger om ett meddelande ska skickas till användaren eller inte.
recurring – Anger om denna åtgärd är återkommande eller inte.
recurring_interval_id – Anger intervallet/enheten för upprepningen (om detta är en återkommande åtgärd).
recurring_frequency – Anger antalet valda enheter som måste förflyta mellan två upprepningar av samma åtgärd (om detta är en återkommande åtgärd).
recurring_times – Hur många instanser av den här åtgärden ska vi skapa?

Återkommande åtgärder följer samma mönster som återkommande händelser. Om åtgärden definieras som återkommande genererar vi en ny åtgärdsinstans efter den definierade tidsperioden.

Avsnitt 3:Händelser och handlingar (riktiga)

Hittills har vi skapat en datamodell som skulle göra det möjligt för oss att infoga händelser och definiera åtgärder. Nu går vi till en mer intressant del av modellen:faktiska händelser och handlingar.

event_instance Tabellen innehåller en lista över alla händelser som har genererats automatiskt eller infogats manuellt. Även om automatisk generering är ganska uppenbart – det är därför vi har skapat den här modellen – är manuell händelseinfogning också en möjlighet. Vi kan förvänta oss att en händelse kommer att infogas automatiskt vid den tidpunkt den är beräknad, så vi har normalt bara faktiska och tidigare händelser i den här tabellen. Ändå kan det hända att vi redan har tagit hand om någon framtida händelse, t.ex. vi har förberett oss för ett möte som kommer att äga rum nästa månad. I så fall bör vi manuellt kunna infoga en framtida händelse (händelsetider föreslås enligt definierade regler) och allt relaterat till den händelsen i denna tabell. Å andra sidan kommer vår applikation inte att skriva över eller duplicera den händelsen. Den känner igen händelser som vi redan har infogat genom att använda event_time värde. För varje händelseinstans kommer vi att definiera:

event_id – Refererar till event definition.
event_time – Den faktiska händelsetiden, i strukturerat textformat.
insert_ts – Den faktiska tidsstämpeln när denna händelse infogades.
event_completed – Ett booleskt värde som anger om händelsen slutfördes eller inte. Händelsen ställs automatiskt in på "avslutad" om alla relaterade åtgärder har slutförts. Det kan också manuellt ställas in på "slutfört" av användaren.

event_id – event_time par är den alternativa/UNIKA nyckeln för denna tabell.

Liknande logik används för action_instance tabell. Åtgärder kommer också att genereras automatiskt när de förfaller. Om en åtgärd är återkommande har vi mer än en åtgärd definierad för samma händelseinstans. För varje åtgärd kommer vi att definiera:

action_id – Refererar till den relaterade action .
event_instance_id – Refererar till den relaterade event_instance .
action_time – Den faktiska tiden för åtgärden, i strukturerat textformat.
insert_ts – En faktisk tidsstämpel när den här händelsen infogades.
action_completed – Ett booleskt värde som anger om åtgärden slutfördes eller inte. Åtgärden ställs in på "avslutad" manuellt av användaren. Om åtgärdsinstansen är inställd på "slutförd" kommer nya instanser inte att genereras (även om definitionen säger att de borde vara det).

I den här tabellen är den alternativa/UNIQUE-nyckeln kombinationen av action_id – event_instance_id – action_time .

Den sista tabellen i vår modell är message tabell. Den används för att lagra meddelanden som genereras av åtgärder. Dessa meddelanden skickas till användare. För varje meddelande lagrar vi:

action_instance_id – ID för action_instance som genererade detta meddelande.
message_title – Meddelandets titel.
message_text – Meddelandetexten, som innehåller en beskrivning av varför detta meddelande genererades (dvs. textfält från de relaterade tabellerna).
insert_ts – Tidsstämpeln när detta meddelande genererades.
message_read – En flagga som anger om meddelandet har lästs av användaren.

Dela dina tankar om datamodellen för viktiga händelser

Jag hoppas att du gillade dagens artikel. Har du någonsin glömt en viktig dejt? Tror du att den här modellen kan hjälpa dig? Berätta för oss i kommentarerna nedan.