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

Управлението на автомобилен/автосервиз е наистина сложен бизнес. Ще трябва да си уговорите срещи, докато някои клиенти ще дойдат и не искате да ги карате да чакат с часове. Освен това ще трябва да организирате служители, да проследявате ремонти, материали, да таксувате клиенти и т.н. Определено ще имате нужда от ИТ решение и, разбира се, модел на данни във фонов режим. Днес ще говорим за един такъв модел.

Идеята

Вече споменах, че този бизнес модел е наистина сложен. Затова няма да се опитвам да обхвана всичко. Умишлено пропуснах материали за проследяване и резервни части, а също така опростих някои части от модела. Причината за това е доста проста. Ако включих наистина всичко, моделът просто би бил твърде голям за артикул с разумен размер. И така, да започнем.

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

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

• Repair shops & employees
• Customers & contacts
• Vehicles
• Services & offers и
• Visits

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

Раздел 1:Сервизи и служители

Първата тема, с която ще започнем, е Repair shops & employees предметна област. Съвсем очевидно е, че трябва да знаем с какво разполагаме, преди да можем да правим оферти на клиентите.

city речникът се използва за съхраняване на всички различни градове, където имаме сервизи или от които идват нашите клиенти. Всеки град е уникално дефиниран от двойката postal_code – city_name . Можем да решим да имаме само един запис за всеки град, дори ако този град има няколко пощенски кода. В този случай ще използваме само „основния“ пощенски код за този град. Все пак имаме възможност да имаме множество вписвания за един и същ град и различни пощенски кодове – в случай че искаме това.

repair_shop таблицата е мястото, където ще съхраняваме списък на всички наши сервизи. Можем да очакваме, че ще оперираме повече от един в даден момент. Всеки магазин е уникално дефиниран от своя shop_name и идентификатора на града, към който принадлежи (city_id ). Също така ще съхраняваме адреса на магазина и допълнителни details в текстов формат, ако има такъв.

position речникът се използва за съхраняване на уникални position_names които могат да бъдат възложени на нашите служители. Въпреки че повечето позиции ще бъдат свързани с основния ни бизнес, ние също ще имаме някои, които не са част от основния бизнес (технически роли/позиции), но също са от съществено значение (администрация, продажби и т.н.).

Списък с всички наши служители се съхранява в employee маса. За всеки служител ще съхраняваме неговите:

• first_name &last_name – Името и фамилията на служителя.
• employment_start_date &employment_end_date – Начална и крайна дата на служителя в компанията. Крайната дата трябва да съдържа стойност NULL, докато не можем да я дефинираме.
• position_id – Препратка към текущата позиция в компанията.
• city_id – Препратка към града, в който служителят живее в момента.
• is_active – Флаг, обозначаващ дали служителят е активен в момента или не.

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

• repair_shop_id – Препратка към съответния сервиз.
• employee_id – Препратка към свързания служител.
• position_id – Препратка към съответната позиция, която служителят би имал през определения период от време. В повечето случаи това би била текущата му позиция, но ние имаме гъвкавостта да назначим друга позиция тук.
• schedule_date – Дата, с която е свързан този запис.
• time_from &time_to – Тази двойка определя периода от време, за който е свързан този запис.
• plan – Флаг, обозначаващ дали това е планирано влизане. Влизането няма да бъде планирано само ако сме го добавили ad hoc.
• actual – Този флаг обозначава дали този запис е бил реализиран. Обърнете внимание, че в повечето случаи и двата флага, планов и действителен, ще бъдат зададени на True. Това би посочило, че сме планирали и реално реализирали този план.
• insert_ts – Времева марка, обозначаваща момента, в който този запис е бил вмъкнат в таблицата.

Комбинацията repair_shop_id - employee_id - schedule_date - time_from формира УНИКАЛНИЯ/алтернативен ключ на тази таблица. Преди да вмъкнем нов запис, трябва също да проверим този нов интервал time_from – time_to не се припокрива с съществуващ интервал за същия служител и дата.

Раздел 2:Клиенти и контакти

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

Ще съхраняваме всички клиенти, с които сме работили преди или с които сме имали контакт, в customer маса. За всеки клиент ще съхраняваме:

• first_name &last_name – Името и фамилията на клиента, в случай че наш клиент е физическо лице.
• company_name – Име на фирма, в случай клиент е фирма, а не частно лице.
• address – Адрес на клиента.
• mobile – Номер на мобилния телефон на клиента.
• email – Имейл на клиента
• details – Всички допълнителни подробности за клиента, ако има такива, в текстов формат.
• insert_ts – Времева марка, обозначаваща момента, в който този запис е бил вмъкнат в таблицата.

Повечето от атрибутите в тази таблица са нулеви, защото вероятно няма да имаме някои от тях и някои (first_name &last_name спрямо company_name ) изключва други.

Ще трябва да проследим всички контакти, които направихме с всеки клиент. За да направим това, ще използваме две таблици. Първият, contact_type table, е прост речник, съдържащ само УНИКАЛНО type_name стойност.

Реалните данни за контакт се съхраняват в contact маса. Ще съхраняваме препратки към типа на този контакт (contact_type_id ), клиент, с когото имахме контакт (customer_id ), служител, осъществил този контакт (schedule_id ), както и да съхранява данни за контакт и времето, когато този запис е бил вмъкнат в таблицата (insert_ts ).

Раздел 3:Превозни средства

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

Първо, ще дефинираме моделите на нашите превозни средства. Ще използваме 3 таблици, за да постигнем това. В make речник, ще изброим уникални make_names за всички производители/производители на автомобили/превозни средства. Освен това ще трябва да знаем типовете превозни средства, така че ще използваме още един речник само с един уникален атрибут за стойност – type_name . Използваният 3 речник е model речник. Този ще съдържа списък на всички модели, които са минали през нашите врати. За всеки модел ще дефинираме уникалната комбинация model_name – make_id – vechicle_type_id .

Ще приключим с описанието на тази тематична област с vehicle маса. Това е единствената таблица в тази тематична област, съдържаща „реални“ данни. Ще използваме тази таблица, за да съхраняваме следните подробности:

• vin – Идентификационен номер на превозното средство, уникално дефиниращ това превозно средство.
• license_plate – Текущ номер на регистрационния номер.
• customer_id – Препратка към клиента, на когото принадлежи това превозно средство. В случай, че превозното средство смени собственика, ще го вмъкнем като нов запис, но ще знаем, че това е същото превозно средство въз основа на серийния номер.
• model_id – Препратка към речника на модела.
• manufactured_year &manufactured_month – Отбележете годината и месеца, когато е произведено това превозно средство.
• details – Всички допълнителни подробности в текстов формат.
• insert_ts – Времева марка, обозначаваща момента, в който този запис е бил вмъкнат в таблицата.

Раздел 4:Услуги и оферти

Готови сме да направим следващата голяма стъпка. Трябва да дефинираме какво предлагаме на нашите (потенциални) клиенти. Това могат да бъдат отделни задачи или набор от задачи – услуги.

Списъкът с всички услуги се съхранява в service_catalog речник. Всяка услуга се състои от няколко задачи и е уникално дефинирана от своя service_name . Освен името, ще съхраняваме и описание, ако имаме такова, процента на service_discount и is_active флаг. Отстъпката за услугата ще се използва за всички задачи, включени в тази услуга.

След това ще дефинираме задачите. Задачите са част от нашите услуги. Те са основното действие, което може да се извърши самостоятелно. Всяка задача се дефинира от тези стойности в task_catalog таблица:

• task_name &service_catalog_id – Име, което ще използваме, за да опишем тази задача и услугата, към която принадлежи. Тази двойка атрибути формира уникалния ключ на таблицата.
• description – Допълнителното текстово описание, ако има такова, използвано за описание на тази задача.
• ref_interval – Флаг, обозначаващ дали ще измерим интервал за тази задача.
• ref_interval_min &ref_interval_max – Минималната и максималната граница на референтния диапазон.
• describe – Флаг, обозначаващ дали трябва да добавим текстов коментар за тази задача.
• task_price – Актуална цена, без отстъпки за услуги, за тази задача.
• is_active – Флаг, обозначаващ дали задачата е активна в момента (в нашата оферта) или не.

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

• customer_id – Идентификатор на свързания клиент.
• contact_id – Идентификатор на свързания контакт, ако е имало такъв. Това може да е важна информация, за да определите колко оферти са дошли в резултат на предишни контакти.
• offer_description – Допълнително текстово описание на тази оферта.
• service_catalog_id – Идентификация на услугата, която сме предложили на клиента. Този идентификатор може да е NULL, в случай че не сме му предложили пълна услуга, а една или повече задачи, които не са част от услугата.
• service_discount – Отстъпката за услугата към момента е създадена. Тази стойност трябва да съдържа NULL, в случай че офертата не е свързана с услугата.
• offer_price – Крайна цена на тази оферта. Може да се изчисли като сбор от всички задачи минус отстъпка за обслужване.
• insert_ts – Времева марка, обозначаваща момента, в който този запис е бил вмъкнат в таблицата.

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

• offer_id – Идентификатор на свързаната оферта.
• task_catalog_id – Идентификатор на свързаната задача. Заедно с offer_id , той формира уникалния/алтернативен ключ на тази таблица
• task_price – Текуща цена на тази задача към момента, в който този запис е вмъкнат.
• insert_ts - Времева марка, обозначаваща момента, в който този запис е бил вмъкнат в таблицата.

Раздел 5:Посещения

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

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

• repair_shop_id – Препратка към съответния сервиз.
• customer_id – Препратка към клиента, с който е свързано това посещение.
• vehicle_id – Препратка към превозното средство, с което е свързано това посещение.
• visit_start_date – Начална дата на посещение (планирана).
• visit_start_time – Начален час на посещението (планирано).
• visit_end_date – Начална дата на посещението (действителна). Тази стойност се задава, когато посещението действително приключи.
• visit_end_time – Начален час на посещението (действителен). Тази стойност се задава, когато посещението действително приключи.
• license_plate – Регистрационен номер в момента на посещението. Забележете, че регистрационните табели се сменят с течение на времето.
• offer_id – Идентификатор на свързаната оферта, ако има такава.
• service_catalog_id – Идентификатор на свързаната услуга, ако има такава.
• service_discount – Процентна отстъпка към момента на добавяне на този запис и в случай, че предлагаме цялостна услуга.
• visit_price – Обща цена, която клиентът трябва да плати за това посещение.
• invoice_created – Печат за време, когато е генерирана фактурата.
• invoice_due – Печат за време, когато фактурата е станала дължима.
• invoice_charged – Печат за време, когато фактурата е била таксувана.
• insert_ts – Времева марка, обозначаваща момента, в който този запис е бил вмъкнат в таблицата.

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

• visit_id – Препратка към това посещение.
• task_catalog_id – Препратка към свързаната задача
• value_measured – Стойност, която е измерена по време на тази задача, ако задачата изисква измерване.
• task_description – Описание, свързано с тази задача, ако задачата изисква описание.
• pass – Флаг, обозначаващ дали тази задача е била в очаквания интервал или не.
• task_price – В тази таблица е вмъкната действителна цена на тази задача към момента.
• insert_ts – Времева марка, обозначаваща момента, в който този запис е бил вмъкнат в таблицата.

Въпреки че този модел е доста опростен, той съдържа всички необходими елементи, които ще ви трябват, за да изградите пълен модел около него. Частите, които изискват подобрения, определено са използвани материали и обработка на плащанията. Бихте ли добавили нещо повече към този модел?