Jak zaprojektować model bazy danych dla systemu rezerwacji kin?

Lubisz chodzić do kina? Czy zastanawiałeś się kiedyś, jak wygląda projekt bazy danych stojący za ich systemem rezerwacji? W tym artykule przygotujemy przykładowy model bazy danych dla kina.

Należy pamiętać o kilku założeniach:

współczesne kino multipleksowe może mieć jedną lub więcej sal w obrębie większego kompleksu,
każda sala może mieć inną liczbę miejsc,
miejsca są ponumerowane numerem rzędu i pozycją siedzenia w rzędzie,
film może mieć wiele pokazów w różnym czasie lub może być wyświetlany jednocześnie w innym audytorium,
na każdy seans miejsce można zarezerwować/sprzedać tylko raz,
Chcemy śledzić, kto wprowadził każdą rezerwację/sprzedaż do systemu.

Przyjrzyjmy się jednemu możliwemu projektowi bazy danych, aby rozwiązać ten problem (model został stworzony za pomocą Vertabelo dla bazy danych MySQL):

Krótkie opisy struktury tabeli podano poniżej:

movie tabela zawiera dane o filmach, które będą pokazywane w kinie. Kluczem podstawowym jest id , który jest automatycznie inkrementowany jak wszystkie klucze podstawowe we wszystkich innych tabelach. Jedyne obowiązkowe dane to title .

Wszystkie pola mają znaczenie zgodne z ich nazwą. Kolumna duration_min może być użyty do wyłączenia wstawiania nowego pokazu lub wyświetlenia komunikatu ostrzegawczego w przypadku, gdy chcemy wejść na pokaz w audytorium, w którym poprzednie nadal trwa:
previous screening start time + duration_min of it > this screening start time
auditorium tabela identyfikuje wszystkie audytorium w teatrze. Wszystkie dane są obowiązkowe.

seats_no Pole może służyć do obliczenia procentu dostępności sal dla wybranego zakresu projekcji/filmu/audytorium/dat. To jest przykład nadmiarowości danych ponieważ mogliśmy uzyskać liczbę miejsc dla każdego audytorium, licząc je w seat stół. W tym przykładzie może nie poprawić znacząco wydajności. Pokazuję to tutaj jako pomysł, który mógłby pomóc w projektowaniu bardziej skomplikowanych modeli. Jeśli w ten sposób skonfigurujemy bazę danych, musimy pamiętać, że jeśli zmieniamy jedną część danych, to musimy również zmienić inne. Jeśli dodamy lub usuniemy dane z seat tabela musimy dostosować wartości seats_no w auditorium stół.
screening tabela zawiera dane wszystkich przeglądów, a wszystkie pola są obowiązkowe. Projekcja musi mieć powiązany film, audytorium i godzinę rozpoczęcia. Nie możemy mieć dwóch pokazów w tym samym audytorium w tym samym czasie. Możemy zdefiniować unikalny klucz składający się z auditorium_id i screening_start . Ta konfiguracja jest lepsza niż definiowanie unikalnego klucza składającego się z movie_id , auditorium_id i screening_start ponieważ pozwoliłoby to nam wejść na projekcje dwóch różnych filmów w tym samym audytorium.

Kod podglądu Vertabelo SQL dla tej tabeli wygląda tak (uwaga Screening_ak_1):
```
-- Tables
-- Table screening
CREATE TABLE screening (
   id int    NOT NULL  AUTO_INCREMENT,
   movie_id int    NOT NULL ,
   auditorium_id int    NOT NULL ,
   screening_start timestamp    NOT NULL ,
   UNIQUE INDEX Screening_ak_1 (movie_id,auditorium_id,screening_start),
   CONSTRAINT Screening_pk PRIMARY KEY (id)
);
```
seat tabela zawiera listę wszystkich miejsc, jakie posiadamy w salach, przy czym każde miejsce jest przypisane do ściśle jednej sali. Wszystkie pola są obowiązkowe.
reservation_type tabela jest słownikiem wszystkich rodzajów rezerwacji (telefonicznie, online, osobiście). Wszystkie pola są obowiązkowe.
employee tabela zawiera listę wszystkich pracowników korzystających z systemu. Wszystkie pola są obowiązkowe.

W złożonych systemach jest zwykle więcej ról, więc potrzebujemy słownika ról i połączenia pracownik/użytkownik-rola. W naszym przykładzie mamy tylko jedną rolę:ta sama osoba wstawia rezerwacje i sprzedaje bilety.
reservation i seat_reserved stoły to główne stoły naszego systemu. Dlatego wymieniłem je na końcu. Wszystkie inne tabele mogą istnieć bez tabel rezerwacji, ale bez tabel rezerwacji stracilibyśmy powód do projektowania całej bazy danych.

reservation tabela przechowuje dane o rezerwacji i/lub sprzedaży biletów. Jeśli mamy rezerwację, atrybut reserved zostanie ustawiony na True, reservation_type_id zostanie ustawiony zgodnie z pochodzeniem rezerwacji i employee_reserved_id zawierałby id_employee wartość osoby, która wprowadziła dane (była pusta, gdyby rezerwacja została dokonana online przez klienta). W ten sam sposób, jeśli bilety zostały sprzedane, employee_paid_id zostanie wypełniony id_employee wartości osoby, która sprzedała bilety, zapłacony atrybut byłby ustawiony na True. Aktywny atrybut określa, czy rekord jest nadal ważny. Jeśli bilety zostałyby sprzedane, ten atrybut zawsze miałby wartość True, a rezerwacja bez sprzedaży byłaby aktywna do 30 minut przed rozpoczęciem seansu

seat_reserved stolik umożliwia nam dokonanie rezerwacji lub jednorazową opłatę za wiele miejsc. Po sprawdzeniu przez pracownika kilku wolnych miejsc w interfejsie, do tej tabeli zostanie dodany jeden rekord dla każdego z nich. Jeśli chcemy sprawdzić, które miejsca są wolne lub zajęte, możemy sprawdzić wartości w tej tabeli połączonej z reservation tabela, w której reservation.active = True .

Warto wspomnieć:

employee_reserved_id nie jest obowiązkowa, ponieważ rezerwacja miejsca może nie istnieć (bilet na miejsce jest sprzedawany bez wcześniejszej rezerwacji) lub odbywa się online
reservation_type_id jest kluczem obcym odwołującym się do „id” typu rezerwacji. Nie jest to obowiązkowe, ponieważ rezerwacja może nie istnieć (w przypadku, gdy dokonaliśmy sprzedaży bez wcześniejszej rezerwacji)
reservation_contact to pole tekstowe do przechowywania danych osoby, która dokonała rezerwacji, nie jest obowiązkowe, ponieważ rezerwacja może nie istnieć (w przypadku, gdy dokonaliśmy sprzedaży bez wcześniejszej rezerwacji)
employee_paid_id dotyczy użytkownika, który dokonał sprzedaży, nie jest to obowiązkowe, ponieważ sprzedaż mogła nie mieć miejsca (miejsce zostało zarezerwowane, rezerwacja została automatycznie anulowana, miejsce nie zostało sprzedane)
paid to flaga wskazująca, że płatność miała miejsce i jest obowiązkowa (wartości mogą być Tak/Prawda lub Nie/Fałsz)

Na koniec pamiętaj, że nikt nie lubi znajdować kogoś innego na swoim miejscu: