So entwerfen Sie ein Datenbankmodell für ein Kinoreservierungssystem

Magst du ins Kino zu gehen? Haben Sie jemals darüber nachgedacht, wie das Datenbankdesign hinter ihrem Reservierungssystem aussieht? In diesem Artikel bereiten wir ein Beispiel-Datenbankmodell für ein Kino vor.

Es gibt ein paar Annahmen, die wir berücksichtigen müssen:

• Zeitgenössische Multiplex-Kinos können einen oder mehrere Säle innerhalb eines größeren Komplexes haben
• Jedes Auditorium kann eine unterschiedliche Anzahl an Sitzplätzen haben,
• Sitzplätze sind mit Reihennummer und Sitzposition innerhalb einer Reihe nummeriert,
• Ein Film kann zu unterschiedlichen Zeiten mehrfach oder gleichzeitig in einem anderen Zuschauerraum gezeigt werden
• Für jede Vorführung kann ein Platz nur einmal reserviert/verkauft werden,
• Wir möchten nachverfolgen, wer die einzelnen Reservierungen/Verkäufe in das System eingegeben hat.

Schauen wir uns ein mögliches Datenbankdesign an, um dieses Problem zu lösen (das Modell wurde mit Vertabelo für die MySQL-Datenbank erstellt):

Kurze Beschreibungen der Tabellenstruktur finden Sie unten:

1. Der movie Tabelle enthält Daten über Filme, die im Kino gezeigt werden. Der Primärschlüssel ist id , die wie alle Primärschlüssel in allen anderen Tabellen automatisch_inkrementiert wird. Die einzigen Pflichtangaben sind title .

   

   Alle Felder haben eine Bedeutung entsprechend ihrem Namen. Die Spalte duration_min könnte verwendet werden, um das Einfügen einer neuen Vorführung zu deaktivieren oder um eine Warnmeldung anzuzeigen, falls wir eine Vorführung in einem Auditorium betreten möchten, in dem die vorherige Vorführung noch läuft:
   previous screening start time + duration_min of it > this screening start time

2. Das auditorium Tabelle identifiziert alle Auditorien im Theater. Alle Angaben sind Pflichtangaben.

   

   Die seats_no Das Feld kann verwendet werden, um den Prozentsatz der Verfügbarkeit von Auditorien für eine ausgewählte Vorführung/Film/Auditorium/Datumsbereich zu berechnen. Dies ist ein Beispiel für Datenredundanz weil wir die Anzahl der Sitzplätze für jedes Auditorium erhalten könnten, indem wir sie im seat Tisch. In diesem Beispiel wird die Leistung möglicherweise nicht wesentlich verbessert. Ich zeige es hier als eine Idee, die beim Entwerfen komplexerer Modelle helfen könnte. Wenn wir die Datenbank auf diese Weise einrichten, müssen wir bedenken, dass wir, wenn wir ein Datenelement ändern, auch andere ändern müssen. Wenn wir Daten zum seat hinzufügen oder löschen Tabelle müssen wir die Werte seats_no anpassen im auditorium Tisch.

3. Das screening Tabelle enthält Daten aller Screenings und alle Felder sind Pflichtfelder. Eine Vorführung muss einen zugehörigen Film, ein Auditorium und eine Startzeit haben. Wir können nicht zwei Vorführungen gleichzeitig im selben Auditorium haben. Wir können einen eindeutigen Schlüssel definieren, der aus auditorium_id besteht und screening_start . Diese Einrichtung ist besser als die Definition eines eindeutigen Schlüssels bestehend aus movie_id , auditorium_id und screening_start denn das würde es uns ermöglichen, zwei verschiedene Filme gleichzeitig im selben Auditorium vorzuführen.

   

   Vertabelo SQL-Vorschaucode für diese Tabelle sieht so aus (Hinweis 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)
   );
   

4. Der seat Tabelle enthält eine Liste aller Sitzplätze, die wir in Auditorien haben, wobei jeder Sitz genau einem Auditorium zugeordnet ist. Alle Felder sind Pflichtfelder.

   

5. Der reservation_type table ist ein Wörterbuch aller Reservierungsarten (telefonisch, online, persönlich). Alle Felder sind Pflichtfelder.

   

6. Der employee Tabelle listet alle Mitarbeiter auf, die das System verwenden. Alle Felder sind Pflichtfelder.

   

   In komplexen Systemen gibt es normalerweise mehr Rollen, daher brauchen wir ein Rollenwörterbuch und eine Mitarbeiter/Benutzer-Rollen-Verbindung. In unserem Beispiel haben wir nur eine Rolle:dieselbe Person gibt Reservierungen ein und verkauft Tickets.

7. Die reservation und seat_reserved Tabellen sind die Haupttabellen unseres Systems. Deshalb habe ich sie zuletzt aufgeführt. Alle anderen Tabellen können ohne Reservierungstabellen existieren, aber ohne die Reservierungstabellen würden wir den Grund verlieren, die gesamte Datenbank überhaupt zu entwerfen.

   

   Die reservation Tabelle speichert Daten über eine Ticketreservierung und/oder einen Ticketverkauf. Wenn wir eine Reservierung haben, das Attribut reserved auf True gesetzt würde, die reservation_type_id entsprechend der Herkunft der Reservierung und der employee_reserved_id gesetzt werden würde den id_employee enthalten Wert der Person, die Daten eingegeben hat (es wäre leer, wenn die Reservierung vom Kunden online vorgenommen worden wäre). Ebenso, wenn Tickets verkauft wurden, die employee_paid_id würde mit dem id_employee gefüllt werden Wert der Person, die Tickets verkauft hat, würde das Attribut Paid auf True gesetzt werden. Das aktive Attribut gibt an, ob ein Datensatz noch gültig ist. Wenn Tickets verkauft würden, wäre dieses Attribut immer True und die Reservierung ohne Verkauf wäre bis 30 Minuten vor Beginn der Vorführung aktiv

   

   Der seat_reserved Tisch ermöglicht es uns, eine Reservierung oder eine Zahlung für mehrere Sitzplätze vorzunehmen. Nachdem der Mitarbeiter einige freie Plätze auf der Schnittstelle überprüft hat, würde dieser Tabelle für jeden von ihnen ein Datensatz hinzugefügt werden. Wenn wir überprüfen möchten, welche Plätze frei oder belegt sind, können wir die Werte in dieser Tabelle zusammen mit dem reservation Tabelle, in der reservation.active = True .

Erwähnenswert ist:

• employee_reserved_id ist nicht obligatorisch, da möglicherweise keine Sitzplatzreservierung vorliegt (ein Ticket für einen Sitzplatz wird ohne vorherige Reservierung verkauft) oder online erfolgt
• reservation_type_id ist ein Fremdschlüssel, der auf die „ID“ des Reservierungstyps verweist. Es ist nicht obligatorisch, da möglicherweise keine Reservierung besteht (falls wir einen Verkauf ohne vorherige Reservierung getätigt haben)
• reservation_contact ist ein Texteingabefeld zum Speichern von Daten einer Person, die eine Reservierung vorgenommen hat, es ist nicht obligatorisch, da möglicherweise keine Reservierung vorliegt (falls wir einen Verkauf ohne vorherige Reservierung getätigt haben)
• employee_paid_id sich auf einen Benutzer bezieht, der einen Verkauf getätigt hat, ist dies nicht obligatorisch, da ein Verkauf möglicherweise nicht stattgefunden hat (Sitzplatz wurde reserviert, Reservierung wurde automatisch storniert, Sitzplatz wurde nicht verkauft)
• paid ist ein Flag, das anzeigt, dass die Zahlung erfolgt und obligatorisch ist (Werte können Ja/Wahr oder Nein/Falsch sein)

Denken Sie am Ende daran, dass niemand gerne jemand anderen auf seinem Platz findet: