Моделът на данните за важните дати

Забравяш ли нещо? Модел на данни, който да ви помогне да запомните важни дати – преди да се случат.

Случвало ли ви се е да забравите важна дата - рождения ден на майка ви или вашата годишнина? Или че изнасяш лекция? Да, такива неща се случват в реалния живот. Може би не за всички нас, но за някои от нас (включително мен) със сигурност го правят. За да предотвратим подобни бедствия, ще създадем модел на данни, който можете да използвате като фон за приложение, което ще ви уведомява точно навреме.

Време е да се сбогуваме с всички тези разочаровани и тъжни лица и с подаръците, които не са купени навреме. :)

Нека се потопим направо в модела.

Моделът на данните

Нашата цел е да създадем модел на данни за приложение, което да ни позволи да дефинираме бъдещи събития и всички действия, свързани с тях. Приложението трябва да уведомява потребителите, когато правят определено нещо в реалния живот и да маркира това нещо като направено, когато е завършено. Някои задачи се повтарят, напр. това събитие задейства бъдещо събитие в момент, който сме дефинирали.

Разбира се, ще трябва също да разработим уеб и мобилни приложения, за да направим тази система наистина полезна. Но засега нека се съсредоточим върху модела на данните.

Моделът се състои от три предметни области:

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

Ще опишем всяка от тези три тематични области в реда, в който са изброени.

Раздел 1:Потребителски акаунти и дати

Потребителите на нашето приложение могат да създават свои собствени потребителски профили и да съхраняват важни дати по техен избор. За да подкрепим това, ще използваме следните таблици.

user_account таблицата е подобна по структура на описаната в много статии за модели на данни, но нека я повторим още веднъж. За всеки потребител ще съхраняваме:

• first_name и last_name – Името и фамилията на потребителя.
• user_name – Избраното от потребителя потребителско име.
• password – Хеш стойността на паролата, която е избрал потребителят.
• mobile – Номерът на мобилния телефон, предоставен от потребителя.
• email – Имейлът, използван по време на процеса на регистрация.
• confirmation_code – Код за потвърждение, изпратен до потребителя, за да завърши своята регистрация.
• confirmation_time – Когато потребителят завърши процеса на потвърждение.
• insert_ts - Времевата марка, когато този запис е бил вмъкнат.

След като регистрацията приключи, потребителят ще може да избере своите важни дати. Този списък се съхранява в таблицата selected_date. Въпреки че говорим за дати, това, което потребителят всъщност избира, са правила, които ще обозначават датите. Първо ще опишем всички атрибути в тази таблица и след това ще обсъдим как потребителите могат да задават правила, използвайки тези атрибути. Атрибутите са:

• user_account_id – Идентификационният номер на потребителя, който е вмъкнал този запис.
• date_year , date_month и date_day – Целочислени стойности, представляващи частите от датата (година, месец и ден от месеца).
• date_weekday – Текстово представяне на поредния номер на деня от седмицата. Използваме текст, защото позволява на потребителите да избират по-сложни стойности – те могат да дефинират както деня от седмицата, така и седмицата в месеца, напр. втория понеделник на всеки месец.

Моля, обърнете внимание, че и четирите части за дата могат да бъдат NULL. Няма да разрешим записи с всички стойности NULL, така че програмно ще проверим дали поне една част от датата НЕ е NULL.

А сега няколко примера:

• Ако искаме да изберем точна дата, напр. 31.12.2018 г. ще зададем стойности на date_year =2018 г., date_month =12 и date_day =31. Това дефинира нещо, което ще се случи само веднъж, на тази единствена дата.
• Ако използваме комбинацията date_year =2019 г. и date_month =1, оставяйки останалите две стойности NULL, тогава дефинираме нещо, което ще се повтаря през целия януари 2019 г.
• Комбинацията date_year =2019 и date_day =2 ще задейства събитие на втория ден от всеки месец през 2019 г.
• Ако вмъкнем стойността , ние определяме нещо, което ще се случи на втория понеделник на всеки месец.

Раздел 2:Събития и действия (определение)

Споменах неясно „нещо“, но това нещо всъщност е събитие. Събитията и действията са причините да сме тук. Искаме да свържем времевата област с действителни събития и действия, които ще се случат в бъдеще. В тази тема ще съхраняваме дефинициите за всички събития и действия. Тези дефиниции по-късно ще бъдат използвани за създаване на действителни събития и действия.

event таблицата определено е централната таблица в тази тематична област, но преди да я опиша, искам да опиша два речника, event_catalog и recurrence_interval . И двете имат една и съща структура, с автоматично нарастващ първичен ключ (id ) и атрибута UNIQUE name.

event_catalog речникът ще съхранява стойности като „рожден ден“, „държавен празник“, „годишнина“ и „друго“. Това ще ни помогне да класифицираме нашите събития.

От друга страна, recurrence_interval ще съхранява стойности като „година“, „месец“, „седмица“ и „ден“. Тази стойност обозначава единицата от времето, което ще измине преди препоръчаното събитие/действие да се повтори (ако е дефинирано като повтарящо се събитие). Когато този период от време изтече, ще бъде генериран нов екземпляр на същото събитие/действие.

Сега сме готови да стигнем до сърцето на тази тематична област. В event таблица, потребителят дефинира всички събития, които са важни за него. За всяко събитие ще съхраняваме:

• selected_date_id – Позовава се на определението за дата.
• event_catalog_id – Означава вида на събитието.
• description – Допълнително текстово описание на това събитие.
• recurring – Флаг, обозначаващ дали събитието се повтаря.
• recurrence_interval_id – Определя колко често се повтаря събитието (година, месец и т.н.). Комбиниране на дефиницията за дата от selected_date с интервала на повторение ще ни позволи да дефинираме началната точка на събитието и колко събития след тази начална точка ще бъдат създадени автоматично. По този начин бихме могли да дефинираме нещо като:„Започвайки от 2 понеделник във всеки месец (selected_date таблица), автоматично насрочвате ежедневни срещи (event.recurrence_interval атрибут)” .
• recurring_frequency – Число, обозначаващо колко единици (дефинирано от recurrence_interval_id ) трябва да преминат, преди това събитие да се проведе отново (ако е повтарящо се събитие). За предишния пример (ежедневни срещи) бихме дефинирали тази стойност като 1.
• recurring_times – Броят на случаите на това събитие. За предишния пример това би било „5“ (ежедневни срещи от понеделник до петък).

След това ще трябва да свържем хората (познати от потребителя) със събития. Списък с всички хора, въведени от нашите потребители, се съхранява в person маса. За всяко лице потребителят ще определи пълно име и всякакви допълнителни подробности (ако е необходимо).

Сега тези хора могат да бъдат свързани със събитията на потребителя. В related_event таблица, ще съхраняваме препратки към event и person както и някои details от естеството на тази връзка. Моля, имайте предвид, че едно и също лице може да бъде добавено няколко пъти за едно и също събитие. Това може да има смисъл, ако искаме да запазим повече от един запис, за да посочим конкретно нещо специално (например „покани София на партито“; София е едновременно гост на партито и певец на групата на партито).

Останалите две таблици в тази тема са свързани с дефиниции на действия.

Действията могат да бъдат всичко, свързано със събитието. Например, ако искаме да си припомним рождения ден на мама, би било чудесно приложението да ни каже:„Започнете да мислите за подаръка, който искате да дадете на майка си“, „Купете подарък за рождения ден на мама“, „Подарете на мама я Подарък за Б-ден. И няколко целувки също“ и накрая „Ти го направи успешно отново тази година. Браво за теб (и за мен)!”

Добре, нека отново станем сериозни. Действията са набори от предварително дефинирани текстове, които трябва да уведомяват потребителите кога да направят нещо. Ще имаме речник с предварително дефинирани типове действия като „започнете да мислите“, „купете подарък“, „намерете музикант“ и т.н. Списък с всички такива УНИКАЛНИ действия се съхранява в action_catalog силно> маса. Когато дефинира събитие, потребителят ще избере едно или повече action s свързани с това събитие и дефинирайте следните стойности за всяко от тях:

• event_id – Идентификационният номер на свързаното събитие.
• action_catalog_id – Избрана стойност от action_catalog речник.
• description – Незадължително описание на това действие. Всеки път, когато това действие се задейства, нашето приложение ще разглежда този атрибут, ще чете командите и ще извърши това действие.
• action_code – Структурирана текстова дефиниция на това действие.
• starts_before – Определя колко избрани времеви единици ще изминат преди началото на това действие за избраното събитие (ако това е повтарящо се действие). Ако тази стойност не е дефинирана (т.е. е зададена на NULL), тогава действията ще започнат в същия момент, в който стартира събитието.
• send_message – Флаг, обозначаващ дали съобщението трябва да бъде изпратено до потребителя или не.
• recurring – Означава дали това действие се повтаря или не.
• recurring_interval_id – Означава интервала/единицата за повторението (ако това е повтарящо се действие).
• recurring_frequency – Означава броя на избраните единици, които трябва да изминат между две повторения на едно и също действие (ако това е повтарящо се действие).
• recurring_times – Колко екземпляра на това действие ще създадем?

Повторението на действието следва същия модел като повторението на събитието. Ако действието е дефинирано като повтарящо се, ще генерираме нов екземпляр на действие след определения период от време.

Раздел 3:Събития и действия (реални)

Досега създадохме модел на данни, който ще ни позволи да вмъкваме събития и да дефинираме действия. Сега ще преминем към по-интересна част от модела:реални събития и действия.

event_instance таблицата съдържа списък на всички събития, които са генерирани автоматично или вмъкнати ръчно. Въпреки че автоматичното генериране е доста очевидно – затова създадохме този модел – ръчното вмъкване на събитие също е възможност. Можем да очакваме, че събитие ще бъде вмъкнато автоматично в момента, в който трябва, така че обикновено ще имаме само действителни и минали събития в тази таблица. Все пак може да се случи, че вече сме се погрижили за някое бъдещо събитие, напр. подготвихме се за среща, която ще се проведе следващия месец. В този случай би трябвало да можем ръчно да вмъкнем бъдещо събитие (времената на събитията се предлагат според определени правила) и всичко свързано с това събитие в тази таблица. От друга страна, нашето приложение няма да презапише или дублира това събитие. Той ще разпознава събития, които вече сме вмъкнали, като използва event_time стойност. За всеки екземпляр на събитие ще дефинираме:

• event_id – Препраща към event определение.
• event_time – Действителното време на събитието, в структуриран текстов формат.
• insert_ts – Действителната марка за време, когато това събитие е било вмъкнато.
• event_completed – Булева стойност, обозначаваща дали събитието е завършено или не. Събитието автоматично се задава на „завършено“, ако всички свързани действия са завършени. Може също ръчно да се настрои на „завършено“ от потребителя.

event_id – event_time двойка е алтернативният/УНИКАЛЕН ключ на тази таблица.

Подобна логика се използва за action_instance маса. Действията също ще бъдат генерирани автоматично, когато са дължими. Ако дадено действие се повтаря, ще имаме повече от едно дефинирано действие за едно и също събитие. За всяко действие ще дефинираме:

• action_id – Препраща към свързаното action .
• event_instance_id – Препраща към свързания event_instance .
• action_time – Действителното време на действието, в структуриран текстов формат.
• insert_ts – Реално клеймо за време, когато това събитие е било вмъкнато.
• action_completed – Булева стойност, обозначаваща дали действието е завършено или не. Действието е настроено на „завършено“ ръчно от потребителя. Ако екземплярът на действие е настроен на „завършен“, новите екземпляри няма да бъдат генерирани (дори ако определението казва, че трябва да бъдат).

В тази таблица алтернативният/УНИКАЛЕН ключ е комбинацията от action_id – event_instance_id – action_time .

Последната таблица в нашия модел е message маса. Използва се за съхраняване на съобщенията, генерирани от действия. Тези съобщения се изпращат до потребителите. За всяко съобщение ще съхраняваме:

• action_instance_id – ИД на action_instance който генерира това съобщение.
• message_title – Заглавието на съобщението.
• message_text – Текстът на съобщението, който съдържа описание защо е генерирано това съобщение (т.е. текстови полета от свързаните таблици).
• insert_ts – Времевата марка, когато е генерирано това съобщение.
• message_read – Флаг, обозначаващ дали съобщението е прочетено от потребителя.

Споделете вашите мисли за модела на данни за важни събития

Надявам се, че сте харесали днешната статия. Случвало ли ви се е да забравите за важна дата? Мислите ли, че този модел може да ви помогне? Моля, кажете ни в коментарите по-долу.