Het datamodel voor belangrijke data

Vergeet je iets? Een gegevensmodel om u te helpen belangrijke datums te onthouden - voordat ze plaatsvinden.

Ben je ooit een belangrijke datum vergeten - de verjaardag van je moeder of je trouwdag? Of dat je een lezing geeft? Ja, dat soort dingen gebeuren in het echte leven. Misschien niet voor ons allemaal, maar voor sommigen van ons (inclusief ik) zeker wel. Om dergelijke rampen te voorkomen, maken we een datamodel dat u als achtergrond kunt gebruiken voor een applicatie die u tijdig op de hoogte stelt.

Het is tijd om afscheid te nemen van al die teleurgestelde en verdrietige gezichten en van cadeaus die niet op tijd zijn gekocht. :)

Laten we direct in het model duiken.

Het gegevensmodel

Ons doel is om een datamodel te creëren voor een applicatie waarmee we toekomstige gebeurtenissen en alle daarmee verband houdende acties kunnen definiëren. De app moet gebruikers op de hoogte stellen wanneer ze een bepaald real-life ding doen en dat ding markeren als voltooid wanneer het is voltooid. Sommige taken herhalen zich, b.v. die gebeurtenis activeert een toekomstige gebeurtenis op een door ons gedefinieerd tijdstip.

Natuurlijk moeten we ook web- en mobiele applicaties ontwikkelen om dit systeem echt nuttig te maken. Maar laten we ons nu concentreren op het datamodel.

Het model bestaat uit drie vakgebieden:

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

We zullen elk van deze drie onderwerpgebieden beschrijven in de volgorde waarin ze worden vermeld.

Sectie 1:Gebruikersaccounts en datums

Gebruikers van onze applicatie kunnen hun eigen gebruikersprofielen maken en belangrijke data naar keuze opslaan. Om dat te ondersteunen, gebruiken we de volgende tabellen.

Het user_account tabel is qua structuur vergelijkbaar met degene die in veel artikelen over gegevensmodellen worden beschreven, maar laten we het nog een keer herhalen. Voor elke gebruiker slaan we op:

first_name en last_name – De voor- en achternaam van de gebruiker.
user_name – De door de gebruiker geselecteerde gebruikersnaam.
password – De hash-waarde van het wachtwoord dat de gebruiker heeft geselecteerd.
mobile – Het mobiele telefoonnummer dat door de gebruiker is verstrekt.
email – Het e-mailadres dat is gebruikt tijdens het registratieproces.
confirmation_code – Een bevestigingscode die naar de gebruiker wordt gestuurd om de registratie te voltooien.
confirmation_time – Wanneer de gebruiker het bevestigingsproces heeft voltooid.
insert_ts - Het tijdstempel waarop dit record is ingevoegd.

Nadat de registratie is voltooid, kan de gebruiker zijn eigen belangrijke datums selecteren. Deze lijst wordt opgeslagen in de tabel selected_date. Hoewel we het over datums hebben, selecteert de gebruiker eigenlijk regels die datums aangeven. We zullen eerst alle attributen in deze tabel beschrijven en daarna bespreken hoe gebruikers regels kunnen instellen met behulp van die attributen. De attributen zijn:

user_account_id – De ID van de gebruiker die deze record heeft ingevoegd.
date_year , date_month , en date_day - Integer-waarden die de datumdelen vertegenwoordigen (jaar, maand en dag van de maand).
date_weekday – Een tekstuele weergave van het volgnummer van de dag van de week. We gebruiken tekst omdat het gebruikers in staat stelt complexere waarden te selecteren - ze kunnen zowel de weekdag als de week in de maand definiëren, b.v. de tweede maandag van elke maand.

Houd er rekening mee dat alle vier de datumdelen NULL kunnen zijn. We staan geen records toe met alle NULL-waarden, dus we zullen programmatisch controleren of ten minste één datumgedeelte NIET NULL is.

En nu een paar voorbeelden:

Als we een exacte datum willen selecteren, b.v. 31.12.2018, zullen we waarden instellen op date_year =2018, date_month =12, en date_day =31. Dit definieert iets dat maar één keer zal gebeuren, op die ene datum.
Als we de combinatie date_year gebruiken =2019 en date_month =1, waarbij de resterende twee waarden NULL blijven, dan definiëren we iets dat zich gedurende heel januari 2019 zal herhalen.
De combinatie date_year =2019 en date_day =2 zou een gebeurtenis activeren op de tweede dag van elke maand in 2019.
Als we de waarde invoegen , we definiëren iets dat elke tweede maandag van de maand zal gebeuren.

Sectie 2:Gebeurtenissen en acties (definitie)

Ik heb een vaag "iets" genoemd, maar dat iets is eigenlijk een gebeurtenis. Evenementen en acties zijn de redenen waarom we hier zijn. We willen het tijdsdomein relateren aan feitelijke gebeurtenissen en acties die in de toekomst zullen plaatsvinden. In dit onderwerp zullen we de definities voor alle gebeurtenissen en acties opslaan. Deze definities zullen later worden gebruikt om daadwerkelijke gebeurtenissen en acties te creëren.

Het event tafel is zeker de centrale tafel in dit onderwerpgebied, maar voordat ik het beschrijf, wil ik twee woordenboeken beschrijven, de event_catalog en de recurrence_interval . Beiden hebben dezelfde structuur, met een automatisch oplopende primaire sleutel (id ) en het UNIQUE name-attribuut.

De event_catalog woordenboek slaat waarden op zoals "verjaardag", "feestdag", "jubileum" en "overig". Dit zal ons helpen onze evenementen te classificeren.

Aan de andere kant, de recurrence_interval slaat waarden op zoals "jaar", "maand", "week" en "dag". Deze waarde geeft de eenheid aan van de tijd die verstrijkt voordat de bedoelde gebeurtenis/actie wordt herhaald (als deze is gedefinieerd als een terugkerende gebeurtenis). Wanneer die tijdsperiode verstrijkt, wordt een nieuwe instantie van dezelfde gebeurtenis/actie gegenereerd.

Nu zijn we klaar om tot de kern van dit onderwerp te komen. In het event tabel definieert de gebruiker alle gebeurtenissen die voor hem belangrijk zijn. Voor elk evenement slaan we op:

selected_date_id – Verwijst naar de datumdefinitie.
event_catalog_id – Geeft het type evenement aan.
description – Een aanvullende tekstuele beschrijving van die gebeurtenis.
recurring – Een vlag die aangeeft of de gebeurtenis zich herhaalt.
recurrence_interval_id – Bepaalt hoe vaak de gebeurtenis wordt herhaald (jaar, maand, enz.). De datumdefinitie combineren van selected_date met het herhalingsinterval kunnen we het startpunt van de gebeurtenis definiëren en hoeveel gebeurtenissen na dat startpunt automatisch worden aangemaakt. Op deze manier zouden we iets kunnen definiëren als:“Vanaf de 2e maandag van elke maand (de selected_date tabel), automatisch dagelijkse vergaderingen plannen (de event.recurrence_interval attribuut)” .
recurring_frequency – Een getal dat aangeeft hoeveel eenheden (gedefinieerd door recurrence_interval_id ) moeten passeren voordat dit evenement opnieuw plaatsvindt (als het een terugkerend evenement is). Voor het vorige voorbeeld (dagelijkse vergaderingen) zouden we deze waarde definiëren als 1.
recurring_times – Het aantal instanties van deze gebeurtenis. Voor het vorige voorbeeld zou dit "5" zijn (dagelijkse vergaderingen van maandag tot vrijdag).

Vervolgens moeten we mensen (bekend bij de gebruiker) in verband brengen met gebeurtenissen. Een lijst van alle mensen die door onze gebruikers zijn ingevoegd, wordt opgeslagen in de person tafel. Voor elke persoon definieert de gebruiker een volledige naam en eventuele aanvullende details (indien nodig).

Nu kunnen deze personen worden gerelateerd aan de gebeurtenissen van de gebruiker. In het related_event tabel, slaan we verwijzingen op naar het event en person evenals enkele details van de aard van die relatie. Houd er rekening mee dat dezelfde persoon meerdere keren kan worden toegevoegd voor hetzelfde evenement. Dit kan zinvol zijn als we meer dan één plaat willen bewaren om specifiek naar iets speciaals te verwijzen (bijvoorbeeld "Nodig Sofia uit voor het feest"; Sofia is zowel een feestgast als de zangeres van de band op het feest).

De overige twee tabellen in dit onderwerpgebied hebben betrekking op actiedefinities.

Acties kunnen van alles zijn met betrekking tot het evenement. Als we onszelf bijvoorbeeld willen herinneren aan mama's verjaardag, zou het geweldig zijn als de applicatie ons vertelt:"Begin na te denken over het cadeau dat je je moeder wilt geven", "Koop een cadeau voor mama's verjaardag", "Geef mama haar B-dag cadeau. En ook een paar kusjes' en tot slot 'Je hebt het dit jaar weer met succes gedaan. Bravo voor jou (en voor mij)!”

Oké, laten we weer serieus worden. Acties zijn sets van vooraf gedefinieerde teksten die gebruikers moeten informeren wanneer ze iets moeten doen. We zullen een woordenboek hebben met vooraf gedefinieerde actietypes zoals "begin met nadenken", "koop een cadeau", "vind een muzikant", enz. Een lijst van al dergelijke UNIEKE acties wordt opgeslagen in de action_catalog tafel. Bij het definiëren van een evenement kiest de gebruiker een of meer action s gerelateerd aan die gebeurtenis en definieer de volgende waarden voor elk van hen:

event_id – De ID van de gerelateerde gebeurtenis.
action_catalog_id – Een geselecteerde waarde uit de action_catalog woordenboek.
description – Een optionele beschrijving van die actie. Elke keer dat deze actie wordt geactiveerd, kijkt onze applicatie naar dit kenmerk, leest de opdrachten en voert die actie uit.
action_code – Een gestructureerde tekstuele definitie van die actie.
starts_before – Bepaalt hoeveel geselecteerde tijdseenheden verstrijken voordat deze actie voor de geselecteerde gebeurtenis begint (als dit een terugkerende actie is). Als deze waarde niet is gedefinieerd (d.w.z. is ingesteld op NULL), starten de acties op hetzelfde moment dat de gebeurtenis begint.
send_message – Een vlag die aangeeft of een bericht naar de gebruiker moet worden verzonden of niet.
recurring – Geeft aan of deze actie terugkerend is of niet.
recurring_interval_id – Geeft het interval/de eenheid voor de herhaling aan (als dit een terugkerende actie is).
recurring_frequency – Geeft het aantal geselecteerde eenheden aan dat moet verstrijken tussen twee herhalingen van dezelfde actie (als dit een terugkerende actie is).
recurring_times – Hoeveel exemplaren van deze actie zullen we maken?

De herhaling van een actie volgt hetzelfde patroon als de herhaling van een gebeurtenis. Als de actie is gedefinieerd als terugkerend, genereren we een nieuwe actie-instantie na de gedefinieerde tijdsperiode.

Sectie 3:Gebeurtenissen en acties (echt)

Tot nu toe hebben we een gegevensmodel gemaakt waarmee we gebeurtenissen kunnen invoegen en acties kunnen definiëren. Nu gaan we naar een interessanter deel van het model:feitelijke gebeurtenissen en acties.

De event_instance tabel bevat een lijst van alle gebeurtenissen die automatisch zijn gegenereerd of handmatig zijn ingevoegd. Hoewel automatisch genereren vrij duidelijk is - daarom hebben we dit model gemaakt - is het handmatig invoegen van gebeurtenissen ook een mogelijkheid. We kunnen verwachten dat een evenement automatisch wordt ingevoegd op het moment dat het moet, dus normaal gesproken hebben we alleen actuele en eerdere evenementen in deze tabel. Toch kan het gebeuren dat we al een toekomstige gebeurtenis hebben verzorgd, b.v. we hebben ons voorbereid op een vergadering die volgende maand zal plaatsvinden. In dat geval zouden we in staat moeten zijn om handmatig een toekomstige gebeurtenis (gebeurtenistijden worden voorgesteld volgens gedefinieerde regels) en alles met betrekking tot die gebeurtenis in deze tabel in te voegen. Aan de andere kant zal onze applicatie die gebeurtenis niet overschrijven of dupliceren. Het herkent gebeurtenissen die we al hebben ingevoegd met behulp van de event_time waarde. Voor elk evenement zullen we het volgende definiëren:

event_id – Verwijst naar de event definitie.
event_time – De werkelijke tijd van het evenement, in gestructureerd tekstueel formaat.
insert_ts – De werkelijke tijdstempel waarop deze gebeurtenis is ingevoegd.
event_completed – Een Booleaanse waarde die aangeeft of de gebeurtenis is voltooid of niet. De gebeurtenis wordt automatisch op 'voltooid' gezet als alle gerelateerde acties zijn voltooid. Het kan ook handmatig worden ingesteld op 'voltooid' door de gebruiker.

De event_id – event_time pair is de alternatieve/UNIEKE sleutel van deze tabel.

Soortgelijke logica wordt gebruikt voor de action_instance tafel. Acties worden ook automatisch gegenereerd wanneer ze moeten worden uitgevoerd. Als een actie terugkerend is, hebben we meer dan één actie gedefinieerd voor dezelfde gebeurtenisinstantie. Voor elke actie definiëren we:

action_id – Verwijst naar de gerelateerde action .
event_instance_id – Verwijst naar de gerelateerde event_instance .
action_time – De werkelijke tijd van de actie, in gestructureerd tekstueel formaat.
insert_ts – Een actuele tijdstempel wanneer deze gebeurtenis is ingevoegd.
action_completed – Een Booleaanse waarde die aangeeft of de actie is voltooid of niet. De actie wordt door de gebruiker handmatig op 'voltooid' gezet. Als de actie-instantie is ingesteld op 'voltooid', worden er geen nieuwe instanties gegenereerd (zelfs als de definitie zegt dat ze dat wel zouden moeten zijn).

In deze tabel is de alternatieve/UNIQUE-sleutel de combinatie van action_id – event_instance_id – action_time .

De laatste tabel in ons model is het message tafel. Het wordt gebruikt om de berichten op te slaan die door acties worden gegenereerd. Deze berichten worden naar gebruikers verzonden. Voor elk bericht slaan we op:

action_instance_id – De ID van de action_instance die dit bericht heeft gegenereerd.
message_title – De titel van het bericht.
message_text – De berichttekst, die een beschrijving bevat van waarom dit bericht is gegenereerd (d.w.z. tekstvelden uit de gerelateerde tabellen).
insert_ts – Het tijdstempel waarop dit bericht is gegenereerd.
message_read – Een vlag die aangeeft of het bericht is gelezen door de gebruiker.

Deel uw mening over het datamodel voor belangrijke gebeurtenissen

Ik hoop dat je genoten hebt van het artikel van vandaag. Ben je ooit een belangrijke datum vergeten? Denk je dat dit model je kan helpen? Vertel het ons in de reacties hieronder.