Нека вградим допълнителни промени в модела на данни, който създадох в по-ранната си публикация в блога, като например автоматизиран подход за назначаване на инструктор и превозно средство към урок, фактуриране на клиенти и проследяване на тях.
Първо, трябва да изградя логика от страната на приложението, за да назнача инструктор и превозно средство на уроците, преди те действително да се проведат. Основното нещо, което трябва да се гарантира тук, е наличността, т.е. инструктор или превозно средство могат да бъдат назначени на урок само ако и двамата са на разположение в предвиденото време на урока.
Трябва да създам две отделни таблици, за да следя заетостта съответно за инструктори и превозно средство. Може би се чудите защо възнамерявам да следя заетостта вместо наличността. Отговорът е, ако проследяваме заетостта вместо наличността, тогава не е необходимо да създаваме повече таблици, за да съхраняваме липсата на ресурси поради отпуск, планиран от инструктори, или някаква планирана услуга за превозни средства. В случай на планирана липса, записи се вмъкват съответно в таблиците за заетост.
Тук предполагам, че инструкторите и превозните средства са достъпни само в работно време, да речем от 8:00 до 18:00 часа, в работни дни, определени от училището. Следователно мога да кажа, че инструкторът е наличен в определено време в работен ден, ако не намеря подробности за неговата заетост за посочения час и ден в staff_occupancy таблица.
Структурата за таблица staff_occupancy е както следва:
Някои вариации могат да се добавят според нуждите. Например, трябва да има поне 15 минути интервал между два следващи урока за инструктор.
Структурата за таблица vehicle_occupancy е както следва:
Разпределението на инструктор и превозно средство се записва в reservation маса. Вече бях добавил две колони, staff_id и vehicle_id , в тази таблица. Тези разпределения очевидно ще се случат въз основа на тяхната наличност.
Освен това ще запазя reservation_id в staff_occupancy и vehicle_occupancy таблици, така че в случай на отмяна на урок, съответната заетост на персонала и превозното средство може лесно да бъде освободена. Но ще запазя и двете колони като нулеви тъй като заетостта на инструктори и превозни средства не е задължително да се дължи на резервации. Ами ако инструктор отиде в отпуск? Или едно от превозните средства отива в сервиза за един ден?
За да позволя меко изтриване в такива сценарии, ще добавя една колона, наречена is_active в двете от тези таблици.
Фактуриране
За изискването за фактуриране ще създам една таблица, а именно invoice , за съхраняване на данни за фактуриране, включително customer_id и reservation_id . Тук фактурирането трябва да се извършва на клиентите, но въз основа на уроците, проведени за клиента. Следователно имаме нужда от reservation_id колона и в таблицата с фактури, така че във всеки даден момент от време може да се изтегли отчет за подробно фактуриране въз основа на резервация за клиент. Ще създам и една колона, а именно invoice_status_id , в таблицата за съхраняване на състоянието на фактурите.
Модел на базата данни
Ето актуализираната структура на базата данни, проектирана във Vertabelo:
Заключение
Досега сигурно сте започнали да вярвате, че моделирането на данни за системата за резервации на автошкола е толкова интересно и очарователно, колкото и да се научите да шофирате?
Чувствайте се свободни да публикувате вашите въпроси и предложения относно статията. С удоволствие ще им отговоря и ще включа вашите предложения в следващата си статия.
