Трябва да проектирам модел на данни за система за резервации за автошкола. Темата изглежда доста ясна, но все още има сложности. Трябва да проследявате всички заявки от клиенти и да следите ресурсите (превозно средство, време и инструктор), изразходвани по време на уроците.
Въведение
Обичам да използвам подход, управляван от домейна за проектиране на модел на данни. Това ме кара да оставя технологичната мания настрана и да се концентрирам предимно върху моделирането на предметната област, въртяща се около свързаните с нея образувания и взаимоотношения помежду си.
Изисквания накратко
Нека първо напиша изискването на обикновен английски.
Имам нужда от модел на данни за автошкола, за да допускам клиенти за да направитерезервации зауроци на линия. Автошколата може да има повече от едининструктор и повече от едно превозно средство . Инструкторът се назначава за урока при резервация. Системата трябва да позволява на клиентите да анулират резервация/и по всяко време преди насрочения ден. Превозното средство, определено за урока, също трябва да бъде записано, ако урокът се проведе.
Включени субекти и връзки
Когато мисля за темата, обектите, които ми идват на първо място, са „Клиент“ , „Инструктор“ , „Урок по шофиране“ , „Заявка за резервация“ и „Превозно средство“ . Нека започна с първата ми таблица за този модел и това е customer . Той е за съхраняване на основни данни за клиенти. Вероятно ще ми трябва друга таблица, за да съхранявам подробности за инструктора, но вместо да създавам таблица с името на инструктора, ще създам обща таблица, наречена staff за подробности за персонала и запазете „Инструктор“ като длъжност. Това ще направи моя модел на данни разширяем, за да обслужва и други области на обслужване, като административна и правна работа, на автошкола.
Смятам за „шофьорски курс“ като една от услугите, по този начин създавам друга таблица, наречена service . Услуга, „шофьорски курс“ в този случай може да има няколко урока. За да се справя с това изискване, със сигурност имам нужда от друга основна таблица, а именно lesson , и една таблица на връзките, а именно service_lesson , за да управлявате много към много отношения между двете от тези главни обекти, т.е. една услуга определено може да има множество уроци, но от друга страна, един урок може също да бъде част от повече от една услуга.
Когато някой подаде заявка за резервация, той/тя е помолен да попълни своите данни и предварителни предпочитания като вид услуга, която желае, избор на превозно средство и начална дата. Данните за клиента се съхраняват в таблицата на клиентите. Впоследствие в request таблица и всички предпочитания се съхраняват срещу заявката в същата таблица. Има определени състояния, свързани с всяка заявка, като „изпращане“, „в процес“, „отказ“ и „завършено“. Ще създам една поддържаща таблица за нея, наречена request_status .
В момента на подаване на заявката се дава предпочитание за превозно средство, тоест тип превозно средство. Въпреки това, превозното средство всъщност ще бъде назначено на урок, когато се проведе. Затова запазвам vehicle_type_id като една от колоните в request таблица за сега.
Когато заявка бъде обработена, се правят резервации за всеки урок от заявката за услуга. В допълнение, инструктори и превозни средства са назначени за всеки урок въз основа на наличността на инструктори и предпочитанията на клиентите за превозни средства. Уроците са насрочени за бъдещи дати със статус „Отворено“. Всички тези подробности се записват в друга таблица с транзакции, наречена reservation . Откроих всички таблици за транзакции с цвят, различен от всички главни таблици.
Една главна таблица, reservation_status , е създаден, за да съхранява всички възможни стойности за статуси на резервация като „отворено“, „в процес“, „отказ“ и „завършено“.
Този модел позволява на клиент да отмени отделен урок, както и заявката за услуга като цяло. Ако клиентът анулира заявката за услуга, всички останали уроци, които са насрочени за клиента, се анулират в таблицата за резервации.
Моля, направете справка с модела на данни, създаден от мен с помощта на Vertabelo, за подробности на ниво колона за всички тези таблици. Няколко точки относно създаването на колони:
- Колона с флаг с име
is_activeсе добавя към всички главни таблици, за да позволи меко изтриване на записи. Така например, ако някой инструктор напусне училището, ние ще обърнем флага на „N“, за да направим записа му неактивен. - Определени колони като
created_date,created_by,last_modified_dateиlast_modified_byсе добавят във всички таблици с транзакции, за да се даде възможност за одитна пътека за промени в записите. Таблиците с транзакции са маркирани в синьо в модела на данни, създаден във Vertabelo. - Може би се чудите какво е
address_idколона вstaffмасата е за. Нарочно поставих тази колона вstaffтаблица, така че да мога да разширя моя модел на данни, за да поддържам автоматизиран процес за назначаване на инструктор към заявка въз основа на неговото или нейното местоположение. Например, да предположим, че в Ню Йорк идва заявка от White Plains. Моята система първо трябва да потърси наличен инструктор в същата или най-близка близост. Моята система никога не трябва да назначава инструктор, който остава в Манхатън, който е на почти 50 мили от мястото на заявителя.
Отличителни характеристики на този модел
- Този модел позволява на клиентите да подават заявки за резервация според предпочитанията си за начална дата и превозно средство.
- Това им позволява да отменят един или повече уроци от курса си или целия курс.
- Този модел улавя подробности за инструктора и превозното средство за всеки урок.
- Този модел е разширяем, за да обслужва всички възможни услуги, предоставяни от автошкола.
- Това ни позволява да проектираме курсове за обучение и ефективно да планираме уроци.
Модел на базата данни
Ето дизайна на базата данни за нашата система за резервации. Моделът е създаден във Vertabelo за база данни на Oracle, но същият дизайн може да бъде приложен за други машини за бази данни без значителни промени.
Заключение
Има определени тематични области, които не сме обхванали в тази статия, като например:
- Можем ли да изградим автоматизиран подход за разпределяне на превозни средства и инструктори към уроците?
- Какво ще кажете за фактуриране на клиенти? Ами ако клиентът не иска да плати за целия курс, а за няколко урока от него? Можем ли да му предоставим тези уроци?
Нашият съществуващ модел поддържа ли такива функции? Отговорът е НЕ. Вероятно ще покрия тези тематични области в следващата си статия.
