Een databasemodel ontwerpen voor een bioscoopreserveringssysteem

Ga je graag naar de film? Heb je er ooit over nagedacht hoe het databaseontwerp achter hun reserveringssysteem eruitziet? In dit artikel zullen we een voorbeelddatabasemodel voor een bioscoop voorbereiden.

Er zijn een paar aannames die we in gedachten moeten houden:

hedendaagse multiplex-bioscopen kunnen een of meer zalen hebben binnen een groter complex,
elk auditorium kan een ander aantal zitplaatsen hebben,
stoelen worden genummerd met rijnummer en stoelpositie binnen een rij,
een film kan meerdere vertoningen op verschillende tijdstippen hebben, of deze kan tegelijkertijd in een ander auditorium worden vertoond,
voor elke vertoning kan slechts één keer een stoel worden gereserveerd/verkocht,
we willen bijhouden wie elke reservering/verkoop in het systeem heeft ingevoerd.

Laten we eens kijken naar een mogelijk databaseontwerp om dit probleem op te lossen (het model is gemaakt met Vertabelo voor MySQL-database):

Korte beschrijvingen van de tabelstructuur worden hieronder gegeven:

De movie tabel bevat gegevens over films die in de bioscoop zullen worden vertoond. De primaire sleutel is id , die auto_incremented is zoals alle primaire sleutels in alle andere tabellen. De enige verplichte gegevens zijn title .

Alle velden hebben een betekenis volgens hun naam. De kolom duration_min kan worden gebruikt om het invoegen van een nieuwe screening uit te schakelen of om een waarschuwingsbericht te tonen in het geval we een screening willen betreden in een auditorium waar de vorige screening nog aan de gang is:
previous screening start time + duration_min of it > this screening start time
Het auditorium tabel identificeert alle auditoria in theater. Alle gegevens zijn verplicht.

De seats_no veld kan worden gebruikt om het percentage van de beschikbaarheid van zalen te berekenen voor een geselecteerde vertoning/film/auditorium/datumbereik. Dit is een voorbeeld van gegevensredundantie omdat we het aantal stoelen voor elk auditorium konden krijgen door ze te tellen in de seat tafel. In dit voorbeeld verbetert het de prestaties mogelijk niet significant. Ik laat het hier zien als een idee dat kan helpen bij het ontwerpen van complexere modellen. Als we de database op deze manier opzetten, moeten we er rekening mee houden dat als we één stuk gegevens wijzigen, we ook andere moeten veranderen. Als we gegevens toevoegen aan of verwijderen uit de seat tabel moeten we waarden aanpassen seats_no in de auditorium tafel.
De screening tabel bevat gegevens van alle screenings en alle velden zijn verplicht. Een vertoning moet een gerelateerde film, auditorium en starttijd hebben. We kunnen niet twee voorstellingen tegelijkertijd in dezelfde zaal hebben. We kunnen een unieke sleutel definiëren die bestaat uit auditorium_id en screening_start . Deze instelling is beter dan het definiëren van een unieke sleutel die bestaat uit movie_id , auditorium_id , en screening_start want dat zou ons in staat stellen om vertoningen van twee verschillende films tegelijkertijd in hetzelfde auditorium binnen te gaan.

Vertabelo SQL-voorbeeldcode voor deze tabel ziet er als volgt uit (let op 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)
);
```
De seat tabel bevat een lijst van alle stoelen die we in auditoria hebben, waarbij elke stoel strikt aan één auditorium is toegewezen. Alle velden zijn verplicht.
Het reservation_type table is een woordenboek van alle soorten reserveringen (telefonisch, online, persoonlijk). Alle velden zijn verplicht.
De employee tabel geeft een overzicht van alle medewerkers die het systeem gebruiken. Alle velden zijn verplicht.

In complexe systemen zijn er meestal meer rollen, dus we hebben een rollenwoordenboek en een werknemer/gebruiker-rolverbinding nodig. In ons voorbeeld hebben we maar één rol:dezelfde persoon plaatst reserveringen en verkoopt tickets.
De reservation en seat_reserved tabellen zijn de hoofdtabellen van ons systeem. Daarom heb ik ze als laatste vermeld. Alle andere tafels kunnen bestaan zonder reserveringstafels, maar zonder de reserveringstabellen zouden we de reden verliezen om de hele database te ontwerpen.

De reservation table slaat gegevens op over een ticketreservering en/of -verkoop. Als we een reservering hebben, is het kenmerk reserved zou worden ingesteld op True, de reservation_type_id zou worden ingesteld op basis van de oorsprong van de reservering en de employee_reserved_id zou de id_employee . bevatten waarde van de persoon die gegevens heeft ingevoerd (deze zou leeg zijn als de reservering online was gedaan door de klant). Op dezelfde manier, als tickets werden verkocht, de employee_paid_id zou worden gevuld met de id_employee waarde van de persoon die tickets heeft verkocht, wordt het kenmerk betaald ingesteld op True. Het actieve kenmerk geeft aan of een record nog geldig is. Als er tickets werden verkocht, zou dit kenmerk altijd waar zijn en zou de reservering zonder verkoop actief zijn tot 30 minuten voordat de screening begint

De seat_reserved tafel stelt ons in staat om een reservering te maken of een betaling te doen voor meerdere stoelen. Nadat de werknemer een paar vrije stoelen op de interface heeft gecontroleerd, zou voor elk van hen één record aan deze tabel worden toegevoegd. Als we willen controleren welke stoelen vrij of bezet zijn, kunnen we de waarden in deze tabel controleren, samen met de reservation tabel waar reservation.active = True .

Het is het vermelden waard:

employee_reserved_id is niet verplicht omdat er mogelijk geen reservering voor een stoel bestaat (een ticket voor een stoel wordt verkocht zonder voorafgaande reservering) of online wordt gedaan
reservation_type_id is een externe sleutel die verwijst naar de "id" van het reserveringstype. Het is niet verplicht omdat een reservering mogelijk niet bestaat (in het geval we een verkoop hebben gedaan zonder een eerdere reservering)
reservation_contact is een tekstinvoerveld voor het opslaan van gegevens van een persoon die een reservering heeft gemaakt, het is niet verplicht omdat een reservering mogelijk niet bestaat (in het geval we een verkoop hebben gedaan zonder een eerdere reservering)
employee_paid_id is gerelateerd aan een gebruiker die een verkoop heeft gedaan, het is niet verplicht omdat er mogelijk geen verkoop heeft plaatsgevonden (stoel is gereserveerd, reservering is automatisch geannuleerd, stoel is niet verkocht)
paid is een vlag die aangeeft dat de betaling heeft plaatsgevonden en verplicht is (waarden kunnen Ja/Waar of Nee/Onwaar zijn)

Houd er uiteindelijk rekening mee dat niemand graag iemand anders op zijn stoel vindt: