Muszę zaprojektować model danych dla systemu rezerwacji dla szkoły nauki jazdy. Tematyka wygląda dość prosto, ale zawiłości wciąż są w to zamieszane. Musisz śledzić wszystkie prośby klientów i śledzić zasoby (pojazd, czas i instruktor) wykorzystane podczas lekcji.
Wprowadzenie
Lubię używać podejścia opartego na domenie do projektowania modelu danych. To sprawia, że odkładam na bok obsesję na punkcie technologii i skupiam się przede wszystkim na modelowaniu tematu krążącego wokół powiązanych z nim podmiotów i relacji między nimi.
Wymagania w skrócie
Najpierw pozwól, że opiszę to wymaganie w prostym języku angielskim.
Potrzebuję modelu danych dla szkoły jazdy, aby umożliwić klientom dokonywać rezerwacji na lekcje online. Szkoła jazdy może mieć więcej niż jednego instruktora i więcej niż jeden pojazd . Instruktor zostaje przydzielony do lekcji po dokonaniu rezerwacji. System powinien umożliwiać klientom anulowanie rezerwacji w dowolnym momencie przed zaplanowanym dniem. Pojazd przypisany do lekcji powinien być również nagrany, jeśli lekcja się odbywa.
Zaangażowane podmioty i relacje
Kiedy myślę o tym temacie, najpierw przychodzi mi do głowy „Klient” , „Instruktor” , „Lekcja jazdy” , „Prośba o rezerwację” i „Pojazd” . Zacznę od mojego pierwszego stołu dla tego modelu, którym jest customer . Służy do przechowywania danych podstawowych dla klientów. Prawdopodobnie potrzebowałbym innej tabeli do przechowywania danych instruktora, ale zamiast tworzyć tabelę z nazwiskiem instruktora, stworzę ogólną tabelę o nazwie staff aby uzyskać szczegółowe informacje na temat personelu i zachować „Instruktor” jako tytuł stanowiska. Dzięki temu mój model danych będzie rozszerzalny, aby obsłużyć również inne obszary usług, takie jak praca administracyjna i prawna szkoły jazdy.
Rozważam „kurs jazdy” jako jedna z usług, dlatego tworzę kolejną tabelę o nazwie service . Usługa „kurs jazdy” w tym przypadku może mieć wiele lekcji. Aby sprostać temu wymaganiu, z pewnością potrzebuję innej tabeli głównej, a mianowicie lesson i jedną tabelę relacji, a mianowicie service_lesson , aby zarządzać relacjami od wielu do wielu między obydwoma tymi jednostkami głównymi, tj. jedna usługa może z pewnością zawierać wiele lekcji, ale z drugiej strony jedna lekcja może być również częścią więcej niż jednej usługi.
Podczas składania wniosku o rezerwację proszony jest o podanie swoich danych i wstępnych preferencji, takich jak rodzaj usługi, wybór pojazdu i data rozpoczęcia. Dane klienta przechowywane są w tabeli klientów. Następnie jedno żądanie jest tworzone w request tabeli, a wszystkie preferencje są przechowywane względem żądania w tej samej tabeli. Z każdym żądaniem są powiązane pewne statusy, takie jak „prześlij”, „w trakcie”, „anuluj” i „zakończono”. Stworzę dla niego jedną tabelę pomocniczą o nazwie request_status .
W momencie składania wniosku wybiera się pojazd, czyli rodzaj pojazdu. Jednak pojazd faktycznie zostałby przydzielony do lekcji, kiedy się ona odbędzie. Dlatego trzymam vehicle_type_id jako jedna z kolumn w request na razie stół.
Kiedy wniosek jest przetwarzany, rezerwacje są dokonywane na każdą lekcję zgłoszenia serwisowego. Ponadto do każdej lekcji przypisani są instruktorzy i pojazdy w oparciu o dostępność instruktorów i preferencje klientów dotyczące pojazdów. Lekcje są zaplanowane na przyszłe terminy ze statusem „Otwarte”. Wszystkie te szczegóły są rejestrowane w innej tabeli transakcji o nazwie reservation . Zaznaczyłem wszystkie tabele transakcji innym kolorem niż wszystkie tabele główne.
Jedna tabela główna, reservation_status , jest tworzony w celu przechowywania wszystkich możliwych wartości dla statusów rezerwacji, takich jak „otwarta”, „w trakcie”, „anuluj” i „zakończona”.
Ten model umożliwia klientowi anulowanie pojedynczej lekcji, a także całego zgłoszenia serwisowego. Jeśli klient anuluje zgłoszenie serwisowe, wszystkie pozostałe lekcje zaplanowane dla klienta zostaną anulowane w tabeli rezerwacji.
Proszę zapoznać się z modelem danych utworzonym przeze mnie przy użyciu Vertabelo, aby uzyskać szczegółowe informacje na poziomie kolumn wszystkich tych tabel. Kilka punktów dotyczących tworzenia kolumn:
- Kolumna flagi o nazwie
is_activejest dodawany do wszystkich tabel głównych, aby umożliwić miękkie usuwanie rekordów. Na przykład, jeśli jakikolwiek instruktor opuści szkołę, przełączymy flagę na „N”, aby jego rekord był nieaktywny. - Niektóre kolumny, takie jak
created_date,created_by,last_modified_dateilast_modified_bysą dodawane we wszystkich tabelach transakcji, aby umożliwić śledzenie zmian w rekordach. Tabele transakcji są podświetlone na niebiesko w modelu danych utworzonym w Vertabelo. - Możesz się zastanawiać, jaki jest
address_idkolumna wstaffstół jest dla. Celowo umieściłem tę kolumnę wstafftabeli, abym mógł rozszerzyć mój model danych o obsługę zautomatyzowanego procesu przypisywania instruktora do żądania na podstawie jego lokalizacji. Załóżmy na przykład, że w Nowym Jorku przychodzi prośba z White Plains. Mój system powinien najpierw poszukać dostępnego instruktora w tym samym lub najbliższym sąsiedztwie. Mój system nigdy nie powinien przypisywać instruktora przebywającego na Manhattanie, który znajduje się prawie 50 mil od miejsca zgłaszającego.
Istotne cechy tego modelu
- Ten model umożliwia klientom składanie wniosków o rezerwację zgodnie z ich preferencjami dotyczącymi daty rozpoczęcia i pojazdu.
- Pozwala im anulować jedną lub więcej lekcji z ich kursu lub cały kurs.
- Ten model rejestruje szczegóły instruktora i pojazdu dla każdej lekcji.
- Ten model można rozszerzyć o obsługę wszystkich możliwych usług świadczonych przez szkołę jazdy.
- Pozwala nam efektywnie projektować kursy szkoleniowe i planować lekcje.
Model bazy danych
Oto projekt bazy danych dla naszego systemu rezerwacji. Model został stworzony w Vertabelo dla bazy danych Oracle, ale ten sam projekt można zaimplementować dla innych silników baz danych bez znaczących zmian.
Wniosek
Istnieją pewne obszary tematyczne, których nie omówiliśmy w tym artykule, takie jak:
- Czy możemy zbudować zautomatyzowane podejście do przydzielania pojazdów i instruktorów na lekcje?
- Co powiesz na fakturowanie klientów? Co jeśli klient nie chce płacić za cały kurs, ale za kilka jego lekcji? Czy możemy udostępnić mu te lekcje?
Czy nasz istniejący model obsługuje takie funkcje? Odpowiedź brzmi nie. Prawdopodobnie omówię te tematy w następnym artykule.
