Model danych ważnych dat

Zapominasz o czymś? Model danych, który pomoże Ci zapamiętać ważne daty – zanim one nastąpią.

Czy kiedykolwiek zapomniałeś o ważnej dacie – urodzinach mamy lub rocznicy? Albo że wygłaszasz wykład? Tak, takie rzeczy zdarzają się w prawdziwym życiu. Może nie dla nas wszystkich, ale dla niektórych (w tym dla mnie) na pewno. Aby zapobiec takim katastrofom, stworzymy model danych, którego możesz użyć jako tła dla aplikacji, która powiadomi Cię na czas.

Czas pożegnać się z tymi wszystkimi rozczarowanymi i smutnymi twarzami oraz z prezentami, które nie zostały kupione na czas. :)

Przejdźmy od razu do modelu.

Model danych

Naszym celem jest stworzenie modelu danych dla aplikacji, który pozwoli nam zdefiniować przyszłe zdarzenia i wszelkie działania z nimi związane. Aplikacja powinna powiadamiać użytkowników, gdy zrobią pewną rzeczywistą rzecz i oznaczać tę czynność jako wykonaną po jej zakończeniu. Niektóre zadania się powtarzają, m.in. to zdarzenie wyzwala przyszłe zdarzenie w określonym przez nas czasie.

Oczywiście będziemy też musieli tworzyć aplikacje internetowe i mobilne, aby ten system był naprawdę użyteczny. Ale na razie skupmy się na modelu danych.

Model składa się z trzech obszarów tematycznych:

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

Opiszemy każdy z tych trzech obszarów tematycznych w kolejności, w jakiej są wymienione.

Sekcja 1:Konta użytkowników i daty

Użytkownicy naszej aplikacji mogą tworzyć własne profile użytkowników i przechowywać wybrane przez siebie ważne daty. Aby to wesprzeć, użyjemy poniższych tabel.

user_account tabela ma podobną strukturę do tych opisanych w wielu artykułach dotyczących modeli danych, ale powtórzmy to jeszcze raz. Dla każdego użytkownika przechowujemy:

• first_name i last_name – Imię i nazwisko użytkownika.
• user_name – Wybrana nazwa użytkownika.
• password – Wartość skrótu hasła wybranego przez użytkownika.
• mobile – Numer telefonu komórkowego podany przez użytkownika.
• email – Adres e-mail użyty podczas procesu rejestracji.
• confirmation_code – Kod potwierdzający wysłany do użytkownika w celu zakończenia rejestracji.
• confirmation_time – Kiedy użytkownik zakończył proces potwierdzenia.
• insert_ts – Znacznik czasu wstawienia tego rekordu.

Po zakończeniu rejestracji użytkownik będzie mógł wybrać własne ważne daty. Ta lista jest przechowywana w tabeli selected_date. Chociaż mówimy o datach, to, co w rzeczywistości wybiera użytkownik, to reguły, które będą oznaczać daty. Najpierw opiszemy wszystkie atrybuty w tej tabeli, a następnie omówimy, jak użytkownicy mogą ustawiać reguły przy użyciu tych atrybutów. Atrybuty to:

• user_account_id – Identyfikator użytkownika, który wstawił ten rekord.
• date_year , date_month i date_day - Wartości całkowite reprezentujące części daty (rok, miesiąc i dzień miesiąca).
• date_weekday – Tekstowa reprezentacja liczby porządkowej dnia tygodnia. Używamy tekstu, ponieważ pozwala on użytkownikom na wybór bardziej złożonych wartości – mogą zdefiniować zarówno dzień tygodnia, jak i tydzień w miesiącu, np. w drugi poniedziałek każdego miesiąca.

Proszę zauważyć, że wszystkie cztery części daty mogą być NULL. Nie zezwalamy na rekordy ze wszystkimi wartościami NULL, więc programowo sprawdzimy, czy co najmniej jedna część daty NIE ma wartości NULL.

A teraz kilka przykładów:

• Jeśli chcemy wybrać dokładną datę, np. 31.12.2018 ustawimy wartości na date_year =2018, date_month =12 i date_day =31. To definiuje coś, co wydarzy się tylko raz, w tym jednym dniu.
• Jeśli użyjemy kombinacji date_year =2019 i date_month =1, pozostawiając pozostałe dwie wartości NULL, to definiujemy coś, co będzie się powtarzać przez cały styczeń 2019 r.
• Kombinacja date_year =2019 i date_day =2 wywoła zdarzenie drugiego dnia każdego miesiąca w 2019 r.
• Jeśli wstawimy wartość , definiujemy coś, co będzie się działo w drugi poniedziałek każdego miesiąca.

Sekcja 2:Wydarzenia i działania (definicja)

Wspomniałem o niejasnym „czymś”, ale to coś jest tak naprawdę wydarzeniem. Wydarzenia i akcje to powody, dla których tu jesteśmy. Chcemy powiązać domenę czasu z rzeczywistymi wydarzeniami i działaniami, które będą miały miejsce w przyszłości. W tym obszarze tematycznym będziemy przechowywać definicje wszystkich zdarzeń i działań. Te definicje będą później używane do tworzenia rzeczywistych wydarzeń i działań.

event tabela jest zdecydowanie centralną tabelą w tym obszarze tematycznym, ale zanim ją opiszę, chcę opisać dwa słowniki, event_catalog i recurrence_interval . Oba mają tę samą strukturę, z automatycznie zwiększającym się kluczem podstawowym (id ) i atrybut UNIQUE name.

event_catalog słownik będzie przechowywać wartości takie jak „urodziny”, „święto państwowe”, „rocznica” i „inne”. Pomoże nam to sklasyfikować nasze wydarzenia.

Z drugiej strony recurrence_interval będzie przechowywać wartości takie jak „rok”, „miesiąc”, „tydzień” i „dzień”. Ta wartość oznacza jednostkę czasu, która upłynie, zanim odnośne zdarzenie/akcja się powtórzy (jeśli jest zdefiniowane jako zdarzenie cykliczne). Po upływie tego czasu zostanie wygenerowana nowa instancja tego samego zdarzenia/akcji.

Teraz jesteśmy gotowi, aby przejść do sedna tej tematyki. W event tabeli, użytkownik definiuje wszystkie zdarzenia, które są dla niego ważne. Dla każdego wydarzenia przechowujemy:

• selected_date_id – Odwołuje się do definicji daty.
• event_catalog_id – Wskazuje rodzaj wydarzenia.
• description – Dodatkowy opis tekstowy tego wydarzenia.
• recurring – Flaga informująca, czy wydarzenie się powtarza.
• recurrence_interval_id – Określa, jak często wydarzenie się powtarza (rok, miesiąc itp.). Łączenie definicji daty z selected_date z interwałem powtarzalności pozwoli nam zdefiniować punkt początkowy zdarzenia oraz ile zdarzeń po tym punkcie początkowym zostanie utworzonych automatycznie. W ten sposób możemy zdefiniować coś takiego:„Od 2 poniedziałku każdego miesiąca (selected_date tabeli), automatycznie planuj codzienne spotkania (event.recurrence_interval atrybut)” .
• recurring_frequency – Liczba oznaczająca ile jednostek (zdefiniowana przez recurrence_interval_id ) muszą minąć, zanim to wydarzenie się powtórzy (jeśli jest to wydarzenie cykliczne). W poprzednim przykładzie (codzienne spotkania) określilibyśmy tę wartość jako 1.
• recurring_times – Liczba wystąpień tego wydarzenia. W poprzednim przykładzie byłoby to „5” (codzienne spotkania od poniedziałku do piątku).

Następnie musimy powiązać osoby (znane użytkownikowi) ze zdarzeniami. Lista wszystkich osób wstawionych przez naszych użytkowników jest przechowywana w person stół. Dla każdej osoby użytkownik zdefiniuje pełne imię i nazwisko oraz wszelkie dodatkowe szczegóły (w razie potrzeby).

Teraz te osoby mogą być powiązane z wydarzeniami użytkownika. W related_event tabeli, będziemy przechowywać odniesienia do event i person jak również kilka details charakteru tego związku. Pamiętaj, że ta sama osoba może zostać dodana wielokrotnie do tego samego wydarzenia. Może to mieć sens, jeśli chcemy zachować więcej niż jedną płytę, aby wskazać coś wyjątkowego (np. „zaproś Sofię na imprezę”; Sofia jest zarówno gościem imprezy, jak i wokalistką zespołu na imprezie).

Pozostałe dwie tabele w tym obszarze tematycznym dotyczą definicji działań.

Akcje mogą być dowolne, związane z wydarzeniem. Na przykład, jeśli chcemy przypomnieć sobie urodziny mamy, dobrze by było, gdyby aplikacja powiedziała nam:„Zacznij myśleć o prezencie, który chcesz dać mamie”, „Kup prezent na urodziny mamy”, „Daj mamie ją”. Prezent na urodziny. I jeszcze kilka pocałunków”, a na koniec „W tym roku znowu udało ci się to pomyślnie. Brawo dla Ciebie (i dla mnie)!”

Dobra, znowu potraktujmy poważnie. Akcje to zestawy predefiniowanych tekstów, które powinny informować użytkowników, kiedy coś zrobić. Będziemy mieli słownik z predefiniowanymi typami działań, takimi jak „zacznij myśleć”, „kup prezent”, „znajdź muzyka” itp. Lista wszystkich takich UNIKALNYCH działań jest przechowywana w action_catalog stół. Podczas definiowania zdarzenia użytkownik wybierze jedną lub więcej action związanych z tym wydarzeniem i dla każdego z nich zdefiniuj następujące wartości:

• event_id – Identyfikator powiązanego wydarzenia.
• action_catalog_id – Wybrana wartość z action_catalog słownik.
• description – Opcjonalny opis tej akcji. Za każdym razem, gdy ta akcja jest uruchamiana, nasza aplikacja będzie sprawdzać ten atrybut, odczytywać polecenia i wykonywać tę akcję.
• action_code – Ustrukturyzowana tekstowa definicja tego działania.
• starts_before – Określa, ile wybranych jednostek czasu upłynie przed rozpoczęciem tej akcji dla wybranego zdarzenia (jeśli jest to akcja cykliczna). Jeśli ta wartość nie jest zdefiniowana (tzn. jest ustawiona na NULL), akcje rozpoczną się w tym samym momencie, w którym rozpoczyna się zdarzenie.
• send_message – Flaga wskazująca, czy wiadomość powinna zostać wysłana do użytkownika, czy nie.
• recurring – Wskazuje, czy ta akcja się powtarza, czy nie.
• recurring_interval_id – Oznacza interwał/jednostkę powtarzania (jeśli jest to akcja cykliczna).
• recurring_frequency – Oznacza liczbę wybranych jednostek, które muszą upłynąć między dwoma powtórzeniami tej samej akcji (jeśli jest to akcja cykliczna).
• recurring_times – Ile wystąpień tej akcji mamy stworzyć?

Cykl akcji jest zgodny z tym samym wzorcem, co cykl zdarzeń. Jeśli akcja jest zdefiniowana jako cykliczna, wygenerujemy nową instancję akcji po określonym czasie.

Sekcja 3:Wydarzenia i działania (rzeczywiste)

Do tej pory stworzyliśmy model danych, który umożliwiałby nam wstawianie zdarzeń i definiowanie działań. Teraz przejdziemy do bardziej interesującej części modelu:rzeczywistych wydarzeń i działań.

event_instance tabela zawiera listę wszystkich zdarzeń, które zostały wygenerowane automatycznie lub wstawione ręcznie. Chociaż automatyczne generowanie jest dość oczywiste – dlatego stworzyliśmy ten model – możliwe jest również ręczne wstawianie zdarzeń. Możemy spodziewać się, że wydarzenie zostanie wstawione automatycznie w wyznaczonym terminie, więc normalnie w tabeli znajdują się tylko aktualne i przeszłe wydarzenia. Może się jednak zdarzyć, że zajęliśmy się już jakimś przyszłym wydarzeniem, m.in. przygotowaliśmy się na spotkanie, które odbędzie się w przyszłym miesiącu. W takim przypadku powinniśmy być w stanie ręcznie wstawić przyszłe wydarzenie (czasy wydarzeń są proponowane zgodnie ze zdefiniowanymi regułami) i wszystko, co jest związane z tym wydarzeniem do tej tabeli. Z drugiej strony nasza aplikacja nie nadpisze ani nie zduplikuje tego zdarzenia. Rozpozna zdarzenia, które już wstawiliśmy za pomocą event_time wartość. Dla każdej instancji zdarzenia zdefiniujemy:

• event_id – Odwołuje się do event definicja.
• event_time – Rzeczywisty czas wydarzenia, w ustrukturyzowanym formacie tekstowym.
• insert_ts – Faktyczny znacznik czasu, kiedy to wydarzenie zostało wstawione.
• event_completed – Wartość logiczna oznaczająca, czy zdarzenie zostało zakończone, czy nie. Zdarzenie jest automatycznie ustawiane na „zakończone”, jeśli wszystkie powiązane działania zostaną zakończone. Użytkownik może również ręcznie ustawić go jako „ukończony”.

event_id – event_time para jest kluczem alternatywnym/UNIKALNYM tej tabeli.

Podobna logika jest używana w przypadku action_instance stół. Działania będą również generowane automatycznie w terminie. Jeśli akcja się powtarza, będziemy mieć więcej niż jedną akcję zdefiniowaną dla tej samej instancji zdarzenia. Dla każdej akcji zdefiniujemy:

• action_id – Odwołuje się do powiązanej action .
• event_instance_id – Odwołuje się do powiązanego event_instance .
• action_time – Rzeczywisty czas akcji w ustrukturyzowanym formacie tekstowym.
• insert_ts – Faktyczny znacznik czasu, kiedy to wydarzenie zostało wstawione.
• action_completed – Wartość logiczna oznaczająca, czy akcja została zakończona, czy nie. Akcja jest ustawiona na „zakończone” ręcznie przez użytkownika. Jeśli instancja akcji jest ustawiona na „zakończono”, nowe instancje nie zostaną wygenerowane (nawet jeśli definicja mówi, że powinny być).

W tej tabeli klucz alternatywny/UNIKALNY jest kombinacją action_id – event_instance_id – action_time .

Ostatnia tabela w naszym modelu to message stół. Służy do przechowywania wiadomości generowanych przez akcje. Te wiadomości są wysyłane do użytkowników. Dla każdej wiadomości przechowujemy:

• action_instance_id – Identyfikator action_instance który wygenerował tę wiadomość.
• message_title – Tytuł wiadomości.
• message_text – Tekst wiadomości, który zawiera opis, dlaczego ta wiadomość została wygenerowana (tj. pola tekstowe z powiązanych tabel).
• insert_ts – Znacznik czasu wygenerowania tej wiadomości.
• message_read – Flaga wskazująca, czy wiadomość została przeczytana przez użytkownika.

Podziel się przemyśleniami na temat modelu danych ważnych wydarzeń

Mam nadzieję, że podobał się Wam dzisiejszy artykuł. Czy kiedykolwiek zapomniałeś o ważnej randce? Czy myślisz, że ten model może ci pomóc? Powiedz nam w komentarzach poniżej.