Модел на данни за детско парти

Организирането на детски партита не е лесна работа:всичко трябва да бъде перфектно планирано и доставено. В противен случай настъпва хаос. От възрастните – по-конкретно от организаторите на партита – зависи да се погрижат за всичко и да го направят както трябва.

Има ли по-добър начин да направите това, отколкото да организирате всичко в база данни? Ние не мислим така!

Детските партита варират много. Някои са прости, като партита за рожден ден, които включват само покани, храна (закуски, напитки и торта) и може би клоун или магьосник, който да забавлява децата. Други партии са много по-сложни. Може да изискват пътуване извън града, нощувка и много други дейности. Колкото по-сложно е партито, толкова по-малко място за грешки. Докато клоун, който закъснява с 10 минути, не е голяма работа, никой не иска да чака с група отегчени деца автобус, който закъснява с два часа!

Нека видим какво може да направи моделът на данни, за да помогне на организаторите на партита да останат организирани.

Какво ни трябва в нашия модел на данни?

Да предположим, че управляваме бизнес за планиране на партита. Ще имаме списък с услугите, които предлагаме на клиентите. Тези услуги може да се предоставят от нас или да използваме партньори (например наемаме клоуна).

Ние комбинираме тези услуги и ги предлагаме на клиентите като парти пакет. Всеки пакет има начална и крайна точка или график. Това включва не само самото парти, но и организирането на партито и почистването след това. Може също да имаме няколко места (например партито започва с пица в ресторант, след което се премества на плажа за плуване).

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

Моделът на данни за детско парти

Нашият модел на данни за детски партита се състои от четири тематични области:

• Countries & cities
• Partners & services
• Employees & roles
• Party

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

Раздел 1:Държави и градове

Тази тематична област съдържа само две таблици. Те не са специфични за този модел, но ще ги използваме в други предметни области.

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

country речникът съдържа само УНИКАЛНОТО country_name стойност. За всеки city , ще съхраняваме УНИКАЛНАТА комбинация от postal_code – city_name – country_id .

Раздел 2:Партньори и услуги

След това нека опишем подробно услугите, които ще предоставим на нашите клиенти.

В service речник. Той съдържа само УНИКАЛНОТО service_name атрибут.

В този модел на данни всички услуги се предоставят от партньори. Дори когато нашата компания действително предоставя услугата, ние ще я третираме като partner услуга (а ние сме партньор). Партньорският речник ще съхранява всички партньори, с които работим, включително и нас. За всеки партньор ще съхраняваме УНИКАЛНО partner_name . details Атрибутът съхранява всякакви допълнителни подробности, свързани с този партньор, като използва неструктуриран или структуриран формат (напр. използвайки двойки име-стойност, разделени с предварително дефиниран разделител).

provides таблицата е последната и най-важна таблица в този раздел. За всеки запис ще съхраняваме:

• partner_id – partner която предоставя услуга.
• service_id – service този партньор предоставя.
• city_id – Препраща city където тази услуга се предоставя от този партньор.
• date_from – Датата, на която партньорът е започнал да предлага тази услуга.
• date_to – Датата, на която партньорът е спрял да предлага тази услуга. Тази стойност може да бъде NULL, ако връзката между услугата и партньора все още е в ход.
• details – Всички допълнителни подробности, свързани с тази услуга, като описание на услугата, цена и т.н. Можем да очакваме, че всички подробности ще бъдат в структуриран текстов формат, използвайки двойки ключ-стойност.

Комбинацията от partner_id – service_id – city_id – date_from формира УНИКАЛНИЯ ключ в тази таблица. Когато въвеждаме нов запис, трябва да проверим дали той не се припокрива със съществуващи записи.

Раздел 3:Служители и роли

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

Централната таблица в тази предметна област е employee маса. За всеки служител ще съхраняваме неговото first_name , last_name , user_name и password . Те ще използват последните два атрибута за достъп до нашето приложение.

Списък с всички възможни роли се съхранява в role речник. Всяка роля е УНИКАЛНО дефинирана от своя role_name . Ролите са свързани с действия, които всеки служител извършва по време на парти. Ето защо тук можем да очакваме стойности като „парти мениджър“ или „асистент“.

Ролите могат да бъдат присвоени на служителите чрез has_role маса. employee_id – role_id двойка ще обозначава активните роли, които всеки служител има в този момент.

Раздел 4:Парти

Party предметната област е централната част на този модел. Ще го използваме за свързване на таблици от други тематични области, а също така ще имаме нова информация тук.

Централната маса тук е party маса. За всяко парти ще съхраняваме:

• city_id – city където ще се проведе партито.
• client_id – client това парти е организирано за.
• details – Подробно текстово описание на партито.
• start_time_planned и end_time_planned – Времето, което сме насрочили за това парти, включително настройка и почистване.
• start_time_actual и end_time_actual – Действителните времена на провеждане на партито (и свързаните с него услуги).
• price_offered – Цената, която посочихме, за да организираме това парти за този клиент.
• time_offered – Когато е направена офертата.
• price_paid – Реалната сума, която клиентът е платил за това парти.
• time_paid – Кога е извършено плащането.

Всяка страна е свързана с клиент. Вече споменахме client таблица, но сега ще видим какво се съхранява там. Отидох само с основни данни:client_name , данни за контакт (address , email , phone , mobile ) и всякакви допълнителни подробности в текстов формат.

Всяка страна ще има и списък с услуги, свързани с нея. Този списък се съхранява в service_included маса. За всеки запис ще ни трябва:

• party_id – Препраща към свързаната party .
• service_id – Препраща към service включени в партито.
• provides_id – Препраща към provider на тази услуга, както и самата услуга. Този атрибут може да бъде NULL, тъй като ще го актуализираме, когато изберем конкретния доставчик.
• details – Всички допълнителни текстови подробности, свързани с тази услуга в тази страна.
• start_time_planned и end_time_planned – Планираните часове, в които услугата трябва да бъде предоставена по време на партито.

Ще трябва също да проследим напредъка на всяка страна. Ще използваме две таблици, за да направим това.

status таблицата ще изброи всички възможни статуси, които могат да бъдат присвоени на страна. За всеки запис ще съхраняваме УНИКАЛНО status_name и три флага:

• successful – Всичко ли мина добре? Или имаше проблеми с нашите услуги?
• paid – Партито платено ли е?
• final – Това ли е крайният статус за това парти?

Ще присвоим статуси на услугите, като добавим нови записи към party_status маса. За всеки запис ще съхраняваме препратки към party и service таблици и timestamp когато този статус е бил присвоен.

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

• client_name – Името на клиента към момента на издаване на фактурата.
• party_id – party свързани с тази фактура.
• client_id – ИД на client се фактурира.
• invoice_amount , discount , vat_amount , total_amount – Финансовите данни на фактурата.
• time_issued - Когато тази фактура е била издадена или добавена към базата данни.
• time_paid - Кога е платена тази фактура.

Какво бихте направили с този модел на данни?

Този модел е доста ясен, но виждам няколко начина да го подобрим. Какви промени бихте предложили? Има ли нещо, което можем да организираме по различен начин? Може би трябва да добавим или премахнем функция. Моля, кажете ни в коментарите.