Comment concevoir un modèle de base de données pour un système de réservation de salle de cinéma

Vous aimez aller au cinéma ? Avez-vous déjà pensé à quoi ressemble la conception de la base de données derrière leur système de réservation ? Dans cet article, nous allons préparer un exemple de modèle de base de données pour une salle de cinéma.

Il y a quelques hypothèses que nous devons garder à l'esprit :

les cinémas multiplex contemporains peuvent avoir un ou plusieurs auditoriums dans un complexe plus grand,
chaque auditorium peut avoir un nombre de places différent,
les sièges sont numérotés avec le numéro de rangée et la position du siège dans une rangée,
un film peut avoir plusieurs projections à des moments différents, ou il peut être projeté simultanément dans une salle différente,
pour chaque projection, une place ne peut être réservée/vendue qu'une seule fois,
nous voulons savoir qui a saisi chaque réservation/vente dans le système.

Examinons une conception de base de données possible pour résoudre ce problème (le modèle a été créé avec Vertabelo pour la base de données MySQL) :

De courtes descriptions de la structure du tableau sont données ci-dessous :

Le movie table contient des données sur les films qui seront projetés au cinéma. La clé primaire est id , qui est auto_incremented comme toutes les clés primaires de toutes les autres tables. La seule donnée obligatoire est title .

Tous les champs ont une signification selon leur nom. La colonne duration_min pourrait être utilisé pour désactiver l'insertion d'une nouvelle projection ou pour afficher un message d'alerte au cas où nous voudrions entrer une projection dans un auditorium où la projection précédente est toujours en cours :
previous screening start time + duration_min of it > this screening start time
L'auditorium tableau identifie tous les auditoriums du théâtre. Toutes les données sont obligatoires.

Le seats_no peut être utilisé pour calculer le pourcentage de disponibilité des auditoriums pour une projection/un film/un auditorium/une plage de dates sélectionnée. Ceci est un exemple de redondance des données car nous pourrions obtenir le nombre de places pour chaque auditorium en les comptant dans le seat table. Dans cet exemple, cela n'améliorera peut-être pas les performances de manière significative. Je le montre ici comme une idée qui pourrait aider à concevoir des modèles plus complexes. Si nous configurons la base de données de cette manière, nous devons garder à l'esprit que si nous modifions une donnée, nous devons également en modifier d'autres. Si nous ajoutons ou supprimons des données du seat table, nous devons ajuster les valeurs seats_no dans l'auditorium table.
Le screening Le tableau contient les données de tous les dépistages et tous les champs sont obligatoires. Une projection doit avoir un film, un auditorium et une heure de début associés. Nous ne pouvons pas avoir deux projections dans le même auditorium en même temps. Nous pouvons définir une clé unique composée de auditorium_id et screening_start . Cette configuration est préférable à la définition d'une clé unique composée de movie_id , auditorium_id , et screening_start car cela nous permettrait d'entrer des projections de deux films différents en même temps dans la même salle.

Le code d'aperçu Vertabelo SQL pour cette table ressemble à ceci (notez 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)
);
```
Le seat Le tableau contient une liste de tous les sièges que nous avons dans les auditoriums, chaque siège étant attribué à un seul auditorium. Tous les champs sont obligatoires.
Le reservation_type table est un dictionnaire de tous les types de réservation (par téléphone, en ligne, en personne). Tous les champs sont obligatoires.
Le employee Le tableau répertorie tous les employés utilisant le système. Tous les champs sont obligatoires.

Dans les systèmes complexes, il y a généralement plus de rôles, nous avons donc besoin d'un dictionnaire de rôles et d'une connexion employé/utilisateur-rôle. Dans notre exemple, nous n'avons qu'un seul rôle :la même personne insère les réservations et vend les billets.
La reservation et seat_reserved les tables sont les tables principales de notre système. C'est pourquoi je les ai listés en dernier. Toutes les autres tables peuvent exister sans tables de réservation, mais sans les tables de réservation, nous perdrions la raison de concevoir toute la base de données en premier lieu.

La reservation table stocke des données sur une réservation et/ou une vente de billets. Si nous avons une réservation, l'attribut reserved serait défini sur True, le reservation_type_id serait défini en fonction de l'origine de la réservation et du employee_reserved_id contiendrait le id_employee valeur de la personne qui a saisi les données (elle serait vide si la réservation avait été effectuée en ligne par le client). De la même manière, si des billets ont été vendus, le employee_paid_id serait rempli avec le id_employee valeur de la personne qui a vendu des billets, l'attribut payé serait défini sur Vrai. L'attribut actif identifie si un enregistrement est toujours valide. Si des billets étaient vendus, cet attribut serait toujours Vrai et la réservation sans vente serait active jusqu'à 30 minutes avant le début de la projection

Le seat_reserved table nous permet de faire une réservation ou un paiement pour plusieurs sièges. Une fois que l'employé a vérifié quelques places libres sur l'interface, un enregistrement est ajouté à ce tableau pour chacun d'eux. Si nous voulons vérifier quelles places sont libres ou occupées, nous pouvons vérifier les valeurs dans ce tableau joint à la reservation table où reservation.active = True .

Il convient de mentionner :

employee_reserved_id n'est pas obligatoire car une réservation peut ne pas exister pour une place (un billet pour une place est vendu sans réservation préalable) ou se fait en ligne
reservation_type_id est une clé étrangère référençant l'"id" du type de réservation. Ce n'est pas obligatoire car une réservation peut ne pas exister (dans le cas où nous avons fait une vente sans réservation préalable)
reservation_contact est un champ de saisie de texte pour stocker les données d'une personne qui a effectué une réservation, il n'est pas obligatoire car une réservation peut ne pas exister (dans le cas où nous avons effectué une vente sans réservation préalable)
employee_paid_id est lié à un utilisateur qui a effectué une vente, ce n'est pas obligatoire car une vente n'a peut-être pas eu lieu (le siège a été réservé, la réservation a été annulée automatiquement, le siège n'a pas été vendu)
paid est un indicateur qui indique que le paiement a eu lieu et est obligatoire (les valeurs peuvent être Oui/Vrai ou Non/Faux)

Au final, gardez à l'esprit que personne n'aime trouver quelqu'un d'autre à sa place :