Jak navrhnout databázový model pro rezervační systém kina

Chodíte rádi do kina? Přemýšleli jste někdy nad tím, jak vypadá návrh databáze za jejich rezervačním systémem? V tomto článku připravíme příklad databázového modelu pro kino.

Existuje několik předpokladů, které musíme mít na paměti:

současná multikina mohou mít jedno nebo více hledišť v rámci většího komplexu,
každé hlediště může mít jiný počet sedadel,
místa jsou očíslována číslem řady a pozicí sedadla v řadě,
film může mít více projekcí v různých časech nebo může být promítán současně v jiném sále,
pro každé promítání lze místo rezervovat/prodat pouze jednou,
chceme sledovat, kdo zadal jednotlivé rezervace/prodeje do systému.

Podívejme se na jeden možný návrh databáze k vyřešení tohoto problému (model byl vytvořen pomocí databáze Vertabelo for MySQL):

Stručný popis struktury tabulky je uveden níže:

movie tabulka obsahuje údaje o filmech, které se budou promítat v kině. Primární klíč je id , který je automaticky_inkrementován jako všechny primární klíče ve všech ostatních tabulkách. Jediným povinným údajem je title .

Všechna pole mají význam podle svého názvu. Sloupec duration_min lze použít k deaktivaci vkládání nového promítání nebo k zobrazení výstražné zprávy v případě, že chceme vstoupit na promítání v hledišti, kde předchozí promítání stále probíhá:
previous screening start time + duration_min of it > this screening start time
auditorium tabulka identifikuje všechna hlediště v divadle. Všechny údaje jsou povinné.

seats_no pole lze použít k výpočtu procenta dostupnosti hledišť pro vybrané promítání/film/hlediště/období. Toto je příklad redundance dat protože bychom mohli získat počet sedadel pro každé hlediště jejich započítáním do seat stůl. V tomto příkladu to nemusí výrazně zlepšit výkon. Ukazuji to zde jako nápad, který by mohl pomoci při navrhování složitějších modelů. Pokud nastavíme databázi tímto způsobem, musíme mít na paměti, že když změníme jeden údaj, musíme změnit i ostatní. Pokud přidáme nebo odstraníme data z seat tabulky musíme upravit hodnoty seats_no v auditorium stůl.
screening tabulka obsahuje údaje o všech projekcích a všechna pole jsou povinná. Promítání musí mít související film, hlediště a čas začátku. Nemůžeme mít dvě představení ve stejném hledišti současně. Můžeme definovat jedinečný klíč skládající se z auditorium_id a screening_start . Toto nastavení je lepší než definování jedinečného klíče skládajícího se z movie_id , auditorium_id a screening_start protože to by nám umožnilo vstupovat na promítání dvou různých filmů současně ve stejném hledišti.

Náhledový kód Vertabelo SQL pro tuto tabulku vypadá takto (všimněte si 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 tabulka obsahuje seznam všech míst, která máme v posluchárnách, přičemž každé místo je přiřazeno výhradně jednomu sálu. Všechna pole jsou povinná.
reservation_type table je slovník všech typů rezervací (telefonicky, online, osobně). Všechna pole jsou povinná.
employee tabulka uvádí všechny zaměstnance používající systém. Všechna pole jsou povinná.

Ve složitých systémech je obvykle více rolí, takže potřebujeme mít slovník rolí a propojení zaměstnanec/uživatelská role. V našem příkladu máme pouze jednu roli:stejná osoba vkládá rezervace a prodává vstupenky.
reservation a seat_reserved tabulky jsou hlavní tabulky našeho systému. Proto jsem je uvedl jako poslední. Všechny ostatní tabulky mohou existovat bez rezervačních tabulek, ale bez rezervačních tabulek bychom v první řadě ztratili důvod navrhovat celou databázi.

reservation tabulka ukládá data o rezervaci a/nebo prodeji vstupenek. Pokud máme rezervaci, atribut reserved by bylo nastaveno na True, reservation_type_id bude nastaveno podle původu rezervace a employee_reserved_id bude obsahovat id_employee hodnotu osoby, která údaje zadala (bylo by prázdné, pokud by rezervaci provedl zákazník online). Stejným způsobem, pokud byly vstupenky prodány, employee_paid_id bude vyplněno id_employee hodnotu osoby, která vstupenky prodala, atribut zaplaceno by byl nastaven na True. Atribut active určuje, zda je záznam stále platný. Pokud by byly vstupenky prodány, tento atribut by byl vždy True a rezervace bez prodeje by byla aktivní do 30 minut před začátkem promítání

seat_reserved stůl nám umožňuje provést rezervaci nebo jednu platbu za více míst. Poté, co zaměstnanec zkontroluje několik volných míst na rozhraní, bude do této tabulky přidán jeden záznam pro každé z nich. Pokud chceme zkontrolovat, která místa jsou volná nebo obsazená, můžeme zkontrolovat hodnoty v této tabulce spojené s reservation tabulka, kde reservation.active = True .

Za zmínku stojí:

employee_reserved_id není povinné, protože rezervace na místo nemusí existovat (vstupenka na místo se prodává bez předchozí rezervace) nebo se provádí online
reservation_type_id je cizí klíč odkazující na „id“ typu rezervace. Není to povinné, protože rezervace nemusí existovat (v případě, že jsme provedli prodej bez předchozí rezervace)
reservation_contact je textové vstupní pole pro uložení dat osoby, která provedla rezervaci, není povinné, protože rezervace nemusí existovat (v případě, že jsme provedli prodej bez předchozí rezervace)
employee_paid_id souvisí s uživatelem, který provedl prodej, není povinný, protože k prodeji nemuselo dojít (místo bylo rezervováno, rezervace byla automaticky zrušena, místo nebylo prodáno)
paid je příznak, který označuje, že platba proběhla, a je povinný (hodnoty mohou být Ano/True nebo Ne/False)

Nakonec mějte na paměti, že nikdo nemá rád, když na svém místě najde někoho jiného: