Sådan designes en databasemodel til et biografreservationssystem

Kan du lide at gå i biografen? Har du nogensinde overvejet, hvordan databasedesignet bag deres reservationssystem ser ud? I denne artikel udarbejder vi et eksempel på en databasemodel til en biograf.

Der er et par antagelser, vi skal huske på:

moderne multiplex-biografer kan have et eller flere auditorier i et større kompleks,
hvert auditorium kan have et forskelligt antal pladser,
Sæder er nummereret med rækkenummer og sædeposition inden for en række,
en film kan have flere visninger på forskellige tidspunkter, eller den kan vises samtidigt i et andet auditorium,
for hver fremvisning kan et sæde kun reserveres/sælges én gang,
vi ønsker at spore, hvem der har indtastet hver reservation/salg i systemet.

Lad os se på et muligt databasedesign til at løse dette problem (modellen blev oprettet med Vertabelo til MySQL-database):

Korte tabelstrukturbeskrivelser er givet nedenfor:

movie tabel indeholder data om film, som vil blive vist i biografen. Den primære nøgle er id , som er auto_incremented ligesom alle primære nøgler i alle andre tabeller. De eneste obligatoriske data er title .

Alle felter har betydninger i henhold til deres navn. Kolonnen duration_min kan bruges til at deaktivere indsættelse af en ny screening eller til at vise en advarselsmeddelelse, hvis vi ønsker at gå ind i en screening i et auditorium, hvor den tidligere screening stadig er i gang:
previous screening start time + duration_min of it > this screening start time
auditorium tabel identificerer alle auditorier i teatret. Alle data er obligatoriske.

seats_no feltet kan bruges til at beregne procentdelen af tilgængeligheden af auditorier for en valgt visning/film/auditorium/datointerval. Dette er et eksempel på dataredundans fordi vi kunne få antallet af pladser til hvert auditorium ved at tælle dem i seat bord. I dette eksempel forbedrer det muligvis ikke ydeevnen væsentligt. Jeg viser det her som en idé, der kunne hjælpe med at designe mere komplekse modeller. Hvis vi opretter databasen på denne måde, skal vi huske på, at hvis vi ændrer et stykke data, skal vi også ændre andre. Hvis vi tilføjer eller sletter data fra seat tabel skal vi justere værdierne seats_no i auditorium bord.
screening tabel indeholder data for alle screeninger og alle felter er obligatoriske. En fremvisning skal have en relateret film, auditorium og starttidspunkt. Vi kan ikke have to fremvisninger i samme auditorium på samme tid. Vi kan definere en unik nøgle bestående af auditorium_id og screening_start . Denne opsætning er bedre end at definere en unik nøgle bestående af movie_id , auditorium_id og screening_start fordi det ville give os mulighed for at deltage i visninger af to forskellige film på samme tid i det samme auditorium.

Vertabelo SQL preview-kode for denne tabel ser sådan ud (bemærk 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 tabel indeholder en liste over alle pladser, vi har i auditorier med hver plads tildelt strengt taget ét auditorium. Alle felter er obligatoriske.
reservation_type table er en ordbog over alle reservationstyper (via telefon, online, personligt). Alle felter er obligatoriske.
employee tabel viser alle medarbejdere, der bruger systemet. Alle felter er obligatoriske.

I komplekse systemer er der normalt flere roller, så vi skal have en rolleordbog og medarbejder/bruger-rolle forbindelse. I vores eksempel har vi kun én rolle:den samme person indsætter reservationer og sælger billetter.
reservation og seat_reserved tabeller er hovedtabellerne i vores system. Det er derfor, jeg listede dem sidst. Alle andre tabeller kan eksistere uden reservationstabeller, men uden reservationstabellerne ville vi miste grunden til at designe hele databasen i første omgang.

reservation tabel gemmer data om en billetreservation og/eller salg. Hvis vi har en reservation, er attributten reserved ville blive sat til True, reservation_type_id ville blive indstillet i henhold til oprindelsen af reservationen og employee_reserved_id ville indeholde id_employee værdien af den person, der indtastede data (den ville være tom, hvis reservationen var foretaget online af kunden). På samme måde, hvis billetter blev solgt, employee_paid_id ville være udfyldt med id_employee værdien af den person, der solgte billetter, ville den betalte egenskab blive sat til True. Den aktive attribut identificerer, om en post stadig er gyldig. Hvis billetter blev solgt, ville denne egenskab altid være sand, og reservationen uden salg ville være aktiv indtil 30 minutter før visningen starter

seat_reserved bordet gør det muligt for os at foretage en reservation eller én betaling for flere pladser. Efter at medarbejderen har tjekket et par ledige pladser på grænsefladen, vil der blive tilføjet en post til denne tabel for hver af dem. Hvis vi ønsker at kontrollere, hvilke pladser der er ledige eller optaget, kan vi tjekke værdierne i denne tabel sammen med reservation tabel hvor reservation.active = True .

Det er værd at nævne:

employee_reserved_id er ikke obligatorisk, fordi en reservation muligvis ikke eksisterer for en plads (en billet til en plads sælges uden forudgående reservation) eller foretages online
reservation_type_id er en fremmednøgle, der refererer til reservationstypens "id". Det er ikke obligatorisk, fordi en reservation muligvis ikke eksisterer (i tilfælde af, at vi foretog et salg uden en forudgående reservation)
reservation_contact er et tekstindtastningsfelt til lagring af data om en person, der har foretaget en reservation, det er ikke obligatorisk, fordi en reservation muligvis ikke eksisterer (i tilfælde af at vi har foretaget et salg uden en forudgående reservation)
employee_paid_id er relateret til en bruger, der har foretaget et salg, er det ikke obligatorisk, fordi et salg muligvis ikke er sket (sædet blev reserveret, reservationen blev annulleret automatisk, pladsen er ikke blevet solgt)
paid er et flag, der angiver, at betaling er sket og er obligatorisk (værdier kan være Ja/Sandt eller Nej/False)

I sidste ende skal du huske på, at ingen kan lide at finde en anden i hans sæde: