Hur man designar en databasmodell för ett biobokningssystem

Gillar du att gå på bio? Har du någonsin tänkt på hur databasdesignen bakom deras bokningssystem ser ut? I den här artikeln förbereder vi en exempeldatabasmodell för en biograf.

Det finns några antaganden vi måste ha i åtanke:

moderna multiplexbiografer kan ha en eller flera salar inom ett större komplex,
varje auditorium kan ha olika antal platser,
Sätena numreras med radnummer och platsposition inom en rad,
en film kan ha flera visningar vid olika tidpunkter, eller så kan den visas samtidigt i en annan auditorium,
för varje visning kan en plats endast reserveras/säljas en gång,
vi vill spåra vem som gjorde varje bokning/försäljning i systemet.

Låt oss titta på en möjlig databasdesign för att lösa detta problem (modellen skapades med Vertabelo för MySQL-databas):

Korta tabellstrukturbeskrivningar ges nedan:

movie Tabellen innehåller data om filmer som kommer att visas på bio. Den primära nyckeln är id , som auto_inkrementeras som alla primärnycklar i alla andra tabeller. Den enda obligatoriska informationen är title .

Alla fält har betydelser enligt deras namn. Kolumnen duration_min kan användas för att inaktivera infogning av en ny visning eller för att visa ett varningsmeddelande om vi vill gå in i en visning i ett auditorium där den tidigare visningen fortfarande pågår:
previous screening start time + duration_min of it > this screening start time
auditorium tabell identifierar alla auditorier i teatern. Alla uppgifter är obligatoriska.

seats_no fältet kan användas för att beräkna andelen tillgänglighet av auditorier för en vald visning/film/auditorium/datumintervall. Det här är ett exempel på dataredundans eftersom vi kunde få antalet platser för varje auditorium genom att räkna dem i seat tabell. I det här exemplet kanske det inte förbättrar prestandan avsevärt. Jag visar det här som en idé som kan hjälpa till med att designa mer komplexa modeller. Om vi ställer in databasen på detta sätt måste vi komma ihåg att om vi ändrar en del av data måste vi också ändra andra. Om vi lägger till eller tar bort data från seat tabell måste vi justera värdena seats_no i auditorium tabell.
screening Tabellen innehåller data för alla visningar och alla fält är obligatoriska. En visning måste ha en relaterad film, auditorium och starttid. Vi kan inte ha två föreställningar i samma auditorium samtidigt. Vi kan definiera en unik nyckel som består av auditorium_id och screening_start . Denna inställning är bättre än att definiera en unik nyckel som består av movie_id , auditorium_id och screening_start eftersom det skulle tillåta oss att gå in i visningar av två olika filmer samtidigt i samma auditorium.

Vertabelo SQL-förhandsgranskningskod för den här tabellen ser ut så här (notera 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 Tabellen innehåller en lista över alla platser vi har i auditorier med varje plats tilldelad strikt en auditorium. Alla fält är obligatoriska.
reservation_type table är en ordbok över alla bokningstyper (per telefon, online, personligen). Alla fält är obligatoriska.
employee Tabellen listar alla anställda som använder systemet. Alla fält är obligatoriska.

I komplexa system finns det oftast fler roller så vi måste ha en rollordbok och anställd/användarroll-koppling. I vårt exempel har vi bara en roll:samma person lägger in reservationer och säljer biljetter.
reservation och seat_reserved tabeller är huvudtabellerna i vårt system. Det är därför jag listade dem sist. Alla andra tabeller kan existera utan reservationstabeller men utan reservationstabellerna skulle vi förlora anledningen till att designa hela databasen i första hand.

reservation tabellen lagrar data om en biljettreservation och/eller försäljning. Om vi har en reservation, attributet reserved skulle sättas till True, reservation_type_id skulle ställas in enligt ursprunget för reservationen och employee_reserved_id skulle innehålla id_employee värdet på personen som angett data (den skulle vara tom om bokningen hade gjorts online av kunden). På samma sätt, om biljetter såldes, employee_paid_id skulle fyllas med id_employee värdet för personen som sålde biljetter, skulle attributet som betalades sättas till True. Det aktiva attributet identifierar om en post fortfarande är giltig. Om biljetter såldes skulle detta attribut alltid vara sant och bokningen utan försäljning skulle vara aktiv fram till 30 minuter innan visningen startar

seat_reserved bordet gör det möjligt för oss att göra en reservation eller en betalning för flera platser. Efter att den anställde kontrollerat några lediga platser i gränssnittet, skulle en post läggas till denna tabell för var och en av dem. Om vi vill kontrollera vilka platser som är lediga eller tagna kan vi kontrollera värdena i den här tabellen som är kopplad till reservation tabell där reservation.active = True .

Det är värt att nämna:

employee_reserved_id är inte obligatoriskt eftersom en reservation kanske inte existerar för en plats (en biljett till en plats säljs utan föregående reservation) eller görs online
reservation_type_id är en främmande nyckel som refererar till reservationstypens "id". Det är inte obligatoriskt eftersom en reservation kanske inte existerar (i fall vi gjorde en försäljning utan en tidigare reservation)
reservation_contact är ett textinmatningsfält för att lagra data om en person som har gjort en reservation, det är inte obligatoriskt eftersom en reservation kanske inte existerar (om vi gjorde en försäljning utan en tidigare reservation)
employee_paid_id är relaterad till en användare som gjorde en försäljning, är det inte obligatoriskt eftersom en försäljning kanske inte har skett (plats reserverades, bokning avbröts automatiskt, plats har inte sålts)
paid är en flagga som indikerar att betalning har skett och är obligatorisk (värdena kan vara Ja/Sant eller Nej/False)

Till slut, kom ihåg att ingen gillar att hitta någon annan i sin plats: