Wbudujmy dalsze zmiany w modelu danych, który stworzyłem we wcześniejszym poście na blogu, takie jak automatyczne przypisywanie instruktora i pojazdu do lekcji, wystawianie faktur klientom i śledzenie ich.
Po pierwsze, muszę zbudować logikę po stronie aplikacji, aby przypisać instruktora i pojazd do lekcji, zanim faktycznie się odbędą. Najważniejsze, aby zapewnić tutaj dostępność, tzn. instruktor lub pojazd można przypisać do lekcji tylko wtedy, gdy obaj są dostępni w zaplanowanym czasie lekcji.
Muszę zbudować dwa oddzielne stoły, aby śledzić zajętość odpowiednio instruktorów i pojazdu. Być może zastanawiasz się, dlaczego zamierzam śledzić obłożenie zamiast dostępności. Odpowiedź jest taka, że jeśli śledzimy obłożenie zamiast dostępności, to nie musimy tworzyć więcej tabel do przechowywania niedostępności zasobów z powodu planowanego przez instruktorów wyjazdu lub jakiejś zaplanowanej usługi dla pojazdów. W przypadku planowanej niedostępności rekordy są odpowiednio wstawiane do tabel obłożenia.
Zakładam tutaj, że instruktorzy i pojazdy są dostępne tylko w godzinach pracy, powiedzmy od 8:00 do 18:00, w dni robocze określone przez szkołę. Dlatego mogę powiedzieć, że instruktor jest dostępny o określonej godzinie w dniu roboczym, jeśli nie znajdę informacji o jego zajętości w określonym czasie i dniu w staff_occupancy tabela.
Struktura tabeli staff_occupancy wygląda następująco:
Niektóre warianty można wprowadzić w razie potrzeby. Na przykład między dwiema kolejnymi lekcjami dla instruktora powinna być co najmniej 15-minutowa przerwa.
Struktura tabeli vehicle_occupancy wygląda następująco:
Przydział instruktora i pojazdu jest rejestrowany w reservation stół. Dodałem już dwie kolumny, staff_id i vehicle_id , do tej tabeli. Te alokacje będą oczywiście odbywać się w zależności od ich dostępności.
Ponadto zachowam reservation_id w staff_occupancy i vehicle_occupancy tabele, aby w przypadku odwołania lekcji można było łatwo zwolnić odpowiednie obłożenie personelu i pojazdu. Ale zachowam obie te kolumny jako nullable ponieważ obłożenie instruktorów i pojazdów niekoniecznie będzie spowodowane rezerwacjami. Co się stanie, jeśli instruktor pójdzie na urlop? A może jeden z pojazdów wjeżdża na jeden dzień do centrum serwisowego?
Aby umożliwić miękkie usuwanie w takich scenariuszach, dodam jedną kolumnę o nazwie is_active w obu tych tabelach.
Fakturowanie
Na potrzeby fakturowania stworzę jedną tabelę, a mianowicie invoice , aby przechowywać szczegóły faktury, w tym customer_id i reservation_id . Tutaj fakturowanie ma być wykonywane dla klientów, ale na podstawie lekcji przeprowadzonych dla klienta. Dlatego potrzebujemy reservation_id również kolumnę w tabeli faktur, dzięki czemu w dowolnym momencie można pobrać raport dotyczący szczegółowego wystawienia faktury na podstawie rezerwacji dla klienta. Stworzę również jedną kolumnę, a mianowicie invoice_status_id , w tabeli do przechowywania statusu faktur.
Model bazy danych
Oto zaktualizowana struktura bazy danych zaprojektowana w Vertabelo:
Wniosek
Do tej pory pewnie zacząłeś wierzyć, że modelowanie danych dla systemu rezerwacji szkoły nauki jazdy jest równie interesujące i urocze jak nauka jazdy?
Zapraszam do publikowania pytań i sugestii dotyczących artykułu. Z przyjemnością odpowiem na nie i uwzględnię Twoje sugestie w moim następnym artykule.
