Datový model Důležitá data

Zapomínáš na něco? Datový model, který vám pomůže zapamatovat si důležitá data – dříve, než k nim dojde.

Zapomněli jste někdy na důležité datum – narozeniny vaší maminky nebo vaše výročí? Nebo že děláš přednášku? Ano, takové věci se v reálném životě stávají. Možná ne nám všem, ale některým z nás (včetně mě) určitě ano. Abychom takovým katastrofám předešli, vytvoříme datový model, který byste mohli použít jako pozadí pro aplikaci, která vás včas upozorní.

Je čas rozloučit se se všemi těmi zklamanými a smutnými tvářemi a s dárky, které nebyly nakoupeny včas. :)

Pojďme se ponořit přímo do modelu.

Datový model

Naším cílem je vytvořit datový model pro aplikaci, který by nám umožnil definovat budoucí události a všechny akce s nimi související. Aplikace by měla upozornit uživatele, když udělají určitou věc v reálném životě, a po dokončení ji označit jako hotovou. Některé úkoly se opakují, např. tato událost spustí budoucí událost v čase, který jsme definovali.

Samozřejmě budeme také muset vyvinout webové a mobilní aplikace, aby byl tento systém opravdu užitečný. Nyní se ale zaměřme na datový model.

Model se skládá ze tří tematických oblastí:

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

Každou z těchto tří tematických oblastí popíšeme v pořadí, v jakém jsou uvedeny.

Část 1:Uživatelské účty a data

Uživatelé naší aplikace si mohou vytvářet vlastní uživatelské profily a ukládat důležitá data dle vlastního výběru. Abychom to podpořili, použijeme následující tabulky.

user_account tabulka je svou strukturou podobná těm, které jsou popsány v mnoha článcích o datových modelech, ale zopakujme si to ještě jednou. Pro každého uživatele uložíme:

• first_name a last_name – Jméno a příjmení uživatele.
• user_name – Uživatelovo vybrané uživatelské jméno.
• password – Hodnota hash hesla, které uživatel zvolil.
• mobile – Číslo mobilního telefonu poskytnuté uživatelem.
• email – E-mail použitý během procesu registrace.
• confirmation_code – Potvrzovací kód odeslaný uživateli k dokončení registrace.
• confirmation_time – Když uživatel dokončí proces potvrzení.
• insert_ts - Časové razítko, kdy byl tento záznam vložen.

Po dokončení registrace si uživatel bude moci vybrat svá vlastní důležitá data. Tento seznam je uložen v tabulce selected_date. Ačkoli mluvíme o datech, uživatel ve skutečnosti vybírá pravidla, která budou označovat data. Nejprve popíšeme všechny atributy v této tabulce a poté probereme, jak mohou uživatelé nastavit pravidla pomocí těchto atributů. Atributy jsou:

• user_account_id – ID uživatele, který vložil tento záznam.
• date_year , date_month a date_day - Celočíselné hodnoty představující části data (rok, měsíc a den v měsíci).
• date_weekday – Textové vyjádření pořadového čísla dne v týdnu. Text používáme, protože umožňuje uživatelům vybrat složitější hodnoty – mohou definovat jak den v týdnu, tak týden v měsíci, např. druhé pondělí v každém měsíci.

Všimněte si prosím, že všechny čtyři části data mohou mít hodnotu NULL. Nepovolíme záznamy se všemi hodnotami NULL, takže programově zkontrolujeme, zda alespoň jedna část data NENÍ NULL.

A teď pár příkladů:

• Pokud chceme vybrat přesné datum, např. 31.12.2018 nastavíme hodnoty na date_year =2018, date_month =12 a date_day =31. Toto definuje něco, co se stane pouze jednou, v dané datum.
• Pokud použijeme kombinaci date_year =2019 a date_month =1, zbývající dvě hodnoty ponecháme NULL, pak definujeme něco, co se bude opakovat během celého ledna 2019.
• Kombinace date_year =2019 a date_day =2 spustí událost druhý den každého měsíce v roce 2019.
• Pokud vložíme hodnotu , definujeme něco, co se stane každé druhé pondělí v měsíci.

Část 2:Události a akce (definice)

Zmínil jsem vágní „něco“, ale to něco je ve skutečnosti událost. Události a akce jsou důvody, proč jsme tady. Chceme spojit časovou oblast se skutečnými událostmi a akcemi, které se stanou v budoucnu. V této předmětové oblasti uložíme definice všech událostí a akcí. Tyto definice budou později použity k vytvoření skutečných událostí a akcí.

event tabulka je rozhodně ústřední tabulkou v této oblasti, ale než ji popíšu, chci popsat dva slovníky, event_catalog a recurrence_interval . Oba mají stejnou strukturu s automaticky se zvyšujícím primárním klíčem (id ) a atribut UNIQUE name.

event_catalog slovník bude ukládat hodnoty jako „narozeniny“, „svátky“, „výročí“ a „jiné“. To nám pomůže klasifikovat naše události.

Na druhou stranu recurrence_interval uloží hodnoty jako „rok“, „měsíc“, „týden“ a „den“. Tato hodnota označuje jednotku času, která uplyne, než se uvedená událost/akce opakuje (pokud je definována jako opakující se událost). Po uplynutí tohoto časového období se vygeneruje nová instance stejné události/akce.

Nyní jsme připraveni dostat se k jádru této oblasti. V event uživatel definuje všechny události, které jsou pro něj důležité. Pro každou událost uložíme:

• selected_date_id – Odkazuje na definici data.
• event_catalog_id – Označuje typ události.
• description – Dodatečný textový popis této události.
• recurring – Příznak označující, zda se událost opakuje.
• recurrence_interval_id – Definuje, jak často se událost opakuje (rok, měsíc atd.). Kombinace definice data z selected_date s intervalem opakování nám umožní definovat počáteční bod události a kolik událostí po tomto počátečním bodu bude automaticky vytvořeno. Tímto způsobem bychom mohli definovat něco jako:„Počínaje 2. pondělím v každém měsíci (selected_date tabulky), automaticky plánují denní schůzky (event.recurrence_interval atribut)” .
• recurring_frequency – Číslo udávající počet jednotek (definováno pomocí recurrence_interval_id ) musí projít, než se tato událost znovu uskuteční (pokud se jedná o opakující se událost). Pro předchozí příklad (denní schůzky) bychom tuto hodnotu definovali jako 1.
• recurring_times – Počet výskytů této události. V předchozím příkladu by to bylo „5“ (denní schůzky od pondělí do pátku).

Dále budeme muset spojit lidi (uživatele známé) s událostmi. Seznam všech osob vložených našimi uživateli je uložen v person stůl. Pro každou osobu uživatel definuje celé jméno a případné další podrobnosti (pokud jsou potřeba).

Nyní mohou být tyto osoby spojeny s událostmi uživatele. V related_event tabulky, uložíme odkazy na event a person stejně jako některé details o povaze toho vztahu. Vezměte prosím na vědomí, že stejná osoba může být pro stejnou událost přidána několikrát. To by mohlo dávat smysl, pokud si chceme ponechat více než jednu desku, abychom konkrétně poukázali na něco speciálního (např. „pozvěte Sofii na večírek“; Sofia je na party hostem i zpěvačkou kapely).

Zbývající dvě tabulky v této oblasti se týkají definic akcí.

Akce může být cokoli související s událostí. Pokud si například chceme připomenout narozeniny maminky, bylo by skvělé, kdyby nám aplikace řekla:„Začněte přemýšlet o dárku, který chcete dát své mamince“, „Kupte dárek k narozeninám maminky“, „Dejte mamince ji B-day dárek. A taky pár polibků“ a nakonec „Letos se ti to zase povedlo. Bravo pro vás (a pro mě)!“

Dobře, pojďme znovu vážně. Akce jsou sady předdefinovaných textů, které by měly uživatele upozornit, když mají něco udělat. Budeme mít slovník s předdefinovanými typy akcí jako „začněte přemýšlet“, „kupte dárek“, „najděte hudebníka“ atd. Seznam všech takových UNIKÁTNÍCH akcí je uložen v action_catalog stůl. Při definování události si uživatel vybere jednu nebo více action s související s danou událostí a pro každou z nich definujte následující hodnoty:

• event_id – ID související události.
• action_catalog_id – Vybraná hodnota z action_catalog slovník.
• description – Volitelný popis této akce. Při každém spuštění této akce se naše aplikace podívá na tento atribut, přečte příkazy a provede tuto akci.
• action_code – Strukturovaná textová definice této akce.
• starts_before – Definuje, kolik vybraných časových jednotek uplyne před zahájením této akce pro vybranou událost (pokud se jedná o opakovanou akci). Pokud tato hodnota není definována (tj. je nastavena na NULL), akce začnou ve stejný okamžik, kdy událost začne.
• send_message – Příznak označující, zda má být zpráva odeslána uživateli či nikoli.
• recurring – Označuje, zda se tato akce opakuje nebo ne.
• recurring_interval_id – Označuje interval/jednotku pro opakování (pokud se jedná o opakovanou akci).
• recurring_frequency – Označuje počet vybraných jednotek, které musí uplynout mezi dvěma opakováními stejné akce (pokud se jedná o opakující se akci).
• recurring_times – Kolik instancí této akce vytvoříme?

Opakování akce má stejný vzor jako opakování události. Pokud je akce definována jako opakovaná, vygenerujeme novou instanci akce po definovaném časovém období.

Část 3:Události a akce (skutečné)

Zatím jsme vytvořili datový model, který by nám umožnil vkládat události a definovat akce. Nyní přejdeme k zajímavější části modelu:skutečným událostem a akcím.

event_instance tabulka obsahuje seznam všech událostí, které byly vygenerovány automaticky nebo vloženy ručně. I když je automatické generování docela zřejmé – to je důvod, proč jsme vytvořili tento model – ruční vkládání událostí je také možnost. Můžeme očekávat, že událost bude vložena automaticky v době, kdy je splatná, takže normálně bychom v této tabulce měli pouze skutečné a minulé události. Přesto se může stát, že jsme se již postarali o nějakou budoucí událost, např. jsme připravili schůzku, která se bude konat příští měsíc. V takovém případě bychom měli být schopni do této tabulky ručně vložit budoucí událost (časy událostí jsou navrženy podle definovaných pravidel) a vše, co s touto událostí souvisí. Na druhou stranu naše aplikace tuto událost nepřepíše ani nezduplikuje. Rozpozná události, které jsme již vložili, pomocí event_time hodnota. Pro každou instanci události definujeme:

• event_id – Odkazuje na event definice.
• event_time – Skutečný čas události ve strukturovaném textovém formátu.
• insert_ts – Skutečné časové razítko, kdy byla tato událost vložena.
• event_completed – Booleovská hodnota označující, zda byla událost dokončena nebo ne. Po dokončení všech souvisejících akcí se událost automaticky nastaví na „dokončeno“. Uživatel jej může také ručně nastavit na „dokončeno“.

event_id – event_time pár je alternativní/UNIQUE klíč této tabulky.

Podobná logika se používá pro action_instance stůl. Akce budou také generovány automaticky, když nastanou. Pokud se akce opakuje, budeme mít pro stejnou instanci události definováno více akcí. Pro každou akci definujeme:

• action_id – Odkazuje na související action .
• event_instance_id – Odkazuje na související event_instance .
• action_time – Skutečný čas akce ve strukturovaném textovém formátu.
• insert_ts – Skutečné časové razítko, kdy byla tato událost vložena.
• action_completed – Booleovská hodnota označující, zda byla akce dokončena nebo ne. Akce je nastavena na „dokončeno“ ručně uživatelem. Pokud je instance akce nastavena na „dokončeno“, nové instance se nevygenerují (i když definice říká, že by měly být).

V této tabulce je alternativní/UNIQUE klíč kombinací action_id – event_instance_id – action_time .

Poslední tabulkou v našem modelu je message stůl. Používá se k ukládání zpráv generovaných akcemi. Tyto zprávy jsou odesílány uživatelům. U každé zprávy uložíme:

• action_instance_id – ID action_instance který vygeneroval tuto zprávu.
• message_title – Název zprávy.
• message_text – Text zprávy, který obsahuje popis, proč byla tato zpráva vygenerována (tj. textová pole ze souvisejících tabulek).
• insert_ts – Časové razítko, kdy byla tato zpráva vygenerována.
• message_read – Příznak označující, zda byla zpráva přečtena uživatelem.

Podělte se o své názory na datový model důležitých událostí

Doufám, že se vám dnešní článek líbil. Zapomněli jste někdy na důležité datum? Myslíte, že by vám tento model mohl pomoci? Řekněte nám to prosím v komentářích níže.