Database
 sql >> Base de données >  >> RDS >> Database

Construire un modèle de données pour un système de gestion de parking

Les recherches montrent que les voitures restent garées pendant 95 % de leur durée de vie, ce qui suggère que les systèmes de gestion des parkings doivent être intelligents, efficaces et robustes. Dans cet article, nous allons construire un modèle de données pour un tel système.

Présentation

Avant de commencer à construire notre modèle de données, nous devons d'abord comprendre comment les parkings sont structurés et comment ils fonctionnent. Examinons brièvement ces deux domaines clés.

  1. Comment les parkings sont-ils structurés ?

    Un parking typique se compose d'un ou plusieurs blocs qui sont ensuite subdivisés en étages. Chaque étage contient plusieurs ailes qui aident les conducteurs à s'orienter et à se souvenir de leurs places de stationnement. Ceux-ci sont généralement étiquetés avec des lettres, telles que "A", "B", "C", etc. Un étage a généralement une limite de hauteur qui empêche certains véhicules d'entrer dans le parking. De plus, un étage contient plusieurs emplacements de stationnement numérotés de manière unique. Certains de ces créneaux sont réservés aux personnes handicapées; d'autres peuvent être réservées par les visiteurs réguliers moyennant un certain coût.

  2. Comment fonctionnent les parkings ?

    Pour comprendre le fonctionnement des parkings, nous devons en savoir plus sur les types de personnes qui fréquentent les parkings. Les clients qui entrent dans les parkings appartiennent à l'un des groupes suivants :

    • Un client régulier qui a acheté un pass bihebdomadaire, mensuel ou annuel.
    • Un client prépayé qui a réservé un créneau à distance (par téléphone ou en ligne).
    • Un client sans rendez-vous qui n'a pas de pass ni réservé de créneau à distance. Un créneau sera attribué à un tel client en fonction de la disponibilité.

    Les clients réguliers reçoivent généralement des cartes/autocollants à placer à un endroit visible sur leur tableau de bord ou leur pare-brise afin que la direction du parking puisse facilement déterminer que les clients n'enfreignent aucune règle de stationnement. Contrairement aux visiteurs occasionnels, les clients réguliers ne se voient jamais délivrer quotidiennement de vignettes de stationnement. Un parking réserve généralement un bloc ou un étage entier à ses visiteurs réguliers pour s'assurer qu'ils ont toujours des places pour se garer. Les clients réguliers peuvent également réserver des créneaux pour eux-mêmes afin de pouvoir garer leurs véhicules dans les mêmes créneaux désignés tous les jours, mais cela coûte généralement plus cher.

    Ceux qui effectuent des réservations de stationnement à distance ne peuvent généralement utiliser leurs créneaux désignés que pendant une fenêtre de temps limitée de quelques heures, après quoi les créneaux sont libérés. Lorsque ces visiteurs entrent dans le parking, ils doivent stationner sur leurs emplacements réservés. Une pénalité est facturée aux clients qui ne quittent pas le parking après l'expiration de leur créneau horaire, mais les clients peuvent certainement partir avant l'expiration de leur réservation. Certains parkings ont une plage horaire minimale fixe (par exemple, le client peut avoir à réserver un créneau pour trois heures même s'il ne s'absente qu'une heure).

    Les clients sans rendez-vous reçoivent des bordereaux de stationnement lorsqu'ils entrent dans un parking. Une place de stationnement est ensuite attribuée au client au fur et à mesure que le bordereau est généré, en fonction des préférences qu'il a spécifiées. Le processus de réservation ici est essentiellement le même que celui des clients prépayés. Cependant, une réservation sans rendez-vous dépend entièrement de la disponibilité. Un créneau peut vous coûter plus cher que si vous deviez réserver une place à l'avance, surtout si la disponibilité est limitée et la demande élevée.

Modèle de données




Avec ces exigences à l'esprit, allons-y et créons notre modèle de données. Cette fois, nous allons travailler avec trois sections principales :

  • Parking
  • Client
  • Réservation de stationnement

Examinons de plus près chacun de ces domaines de notre modèle de données.

Section 1 :Parking

La section Parc de stationnement capture non seulement toutes les informations importantes sur le parking lui-même, mais simplifie également la manière dont la plus petite unité du parking (un emplacement) peut être gérée par l'entreprise. Certaines colonnes de tableau ont été ajoutées dans le seul but de rendre les réservations de stationnement et les opérations plus efficaces dans les sections ultérieures.

Conformément à la structure du parking dont nous avons parlé dans l'introduction, nous avons créé les tableaux suivants pour capturer chaque détail dont nous aurons besoin.

parking_lot – stocke des informations de base sur un parking. Les colonnes de ce tableau sont :

  • id – la clé primaire de cette table. Il attribue un numéro unique à chaque parking.
  • number_of_blocks - suit le nombre de blocs dans un parking.
  • is_slot_available – indique si le parking a actuellement des emplacements disponibles.
  • address – stocke l'adresse complète d'un parking.
  • zip - stocke le code postal d'un parking, permettant aux clients de rechercher plus facilement les parkings disponibles dans une certaine zone en interrogeant simplement leur code postal souhaité.
  • is_reentry_allowed – signifie si un client peut sortir du parking et y rentrer avec le même ticket de parking. Notez que de nombreux parkings ne permettent généralement pas aux clients de le faire. Dans ces parcs de stationnement, vous devez acheter un nouveau bordereau chaque fois que vous y entrez un jour donné.
  • operating_company_name – stocke le nom de la société qui exploite le parking.
  • is_valet_parking_available – indique si le parking propose des services de voiturier.

block – un parking est divisé en un ou plusieurs blocs. Cette table stocke des informations sur chaque bloc d'un parking. Les colonnes de ce tableau sont les suivantes :– un parking est divisé en un ou plusieurs blocs. Cette table stocke des informations sur chaque bloc d'un parking. Les colonnes de ce tableau sont :

  • id – la clé primaire de cette table.
  • parking_lot_id – la colonne référencée du parking_lot table qui identifie le parking auquel appartient le bloc.
  • block_code – stocke le code associé à ce bloc. Les blocs reçoivent généralement des codes d'identification uniques, tels que « A », « B », « C », « 11 », « 22 », « 33 », etc.
  • number_of_floors – stocke le nombre d'étages dans ce bloc. Le chiffre "1" indique qu'il s'agit d'un bloc au rez-de-chaussée sans étage.
  • is_block_full – indique si le bloc est actuellement plein.

floor – dans les parkings à plusieurs niveaux, les blocs peuvent avoir plus d'un étage. Cependant, cette table peut également être référencée par des blocs au niveau du sol. Les colonnes de ce tableau sont :

  • id – la clé primaire de cette table.
  • block_id – identifie le bloc auquel appartient un étage.
  • floor_number – représente le numéro d'un étage (où 1 =niveau du sol).
  • max_height_in_inch – dans un parking à plusieurs niveaux, chaque étage a une contrainte de hauteur. Cette colonne stocke la hauteur maximale autorisée pour les véhicules sur un sol.
  • number_of_wings – un étage est en outre divisé en ailes, ce qui aide les clients à se rappeler où ils se sont garés. Cette colonne stocke le nombre d'ailes qui existent sur un étage.
  • number_of_slots – stocke le nombre d'emplacements qui existent sur un étage.
  • is_covered – identifie si un sol est couvert. Le dernier étage d'un parking à plusieurs niveaux ou d'un parking au rez-de-chaussée ne sera jamais couvert.
  • is_accessible – indique si le sol est facilement accessible, notamment par les personnes handicapées. Si un terrain à plusieurs niveaux dispose d'un ascenseur opérationnel, chacun de ses étages est considéré comme accessible.
  • is_floor_full – indique si un étage est entièrement occupé.
  • is_reserved_reg_cust – indique si un étage est strictement réservé aux clients réguliers.

parking_slot – cette table stocke toutes les informations sur les emplacements de stationnement d'un parking. Les colonnes de ce tableau sont :

  • id – clé primaire pour cette table.
  • floor_id – identifie l'étage auquel appartient un emplacement.
  • slot_number – stocke l'identifiant unique de l'emplacement à un étage particulier.
  • wing_code – identifie l'aile dans laquelle se trouve une fente.

Section 2 :Clients

Passant à autre chose, nous allons maintenant commencer à détailler toutes les informations pertinentes sur les clients. Notez que les parkings ne sont pas concernés par la capture et le stockage d'informations personnelles telles que les noms, les adresses, etc., car ils peuvent accéder à leurs portails DMV locaux à tout moment pour obtenir ces informations, si nécessaire.

customer – stocke tous les détails pertinents sur tous les types de clients qui peuvent visiter le parking (réguliers, ponctuels et prépayés). Les colonnes de ce tableau sont :

  • id – identifiant unique pour le client.
  • vehicle_number – stocke le numéro de plaque d'immatriculation du véhicule d'un client.
  • registration_date – stocke la date à laquelle le véhicule a été enregistré pour la première fois avec le parking.
  • is_regular_customer – indique si un client a un laissez-passer régulier. Si la colonne stocke une valeur true, alors il doit exister une entrée valide dans le regular_pass table. Une fois qu'un laissez-passer expire et que le client ne l'a pas encore renouvelé, la valeur de cette colonne est mise à jour sur faux.
  • contact_number – stocke le numéro de contact d'un client. Étant donné que certaines personnes hésitent à partager leurs numéros de contact avec les parkings, nous avons gardé cette colonne nullable.

regular_pass – stocke des informations sur les laissez-passer réguliers délivrés aux clients. Les colonnes de ce tableau sont :

  • id – clé primaire pour cette table.
  • customer_id – une colonne référencée de la table client.
  • purchase_date – stocke la date à laquelle le pass a été acheté.
  • start_date – stocke la date à laquelle le pass sera considéré comme valide, qui n'est pas nécessairement la date d'achat, car certains clients achètent des pass à l'avance.
  • duration_in_days – stocke le nombre de jours pendant lesquels un pass est valable. Un pass mensuel reste généralement valable 30 jours.
  • cost – stocke le coût, en devise locale, qu'un client doit payer pour acheter un pass.

Section 3 :Réservations

Notre dernière section est consacrée à détailler le processus de réservation d'un emplacement de parking. Lors de la réservation, un client doit généralement fournir certains détails, tels que la date et l'heure d'arrivée prévues, la durée pour laquelle il souhaite réserver le créneau, etc. Nous discutons des deux tableaux principaux de cette section ci-dessous.

parking_slot_reservation – conserve les détails de la réservation. Les colonnes de ce tableau sont :

  • id – attribue un numéro de référence unique à une demande de réservation individuelle.
  • customer_id – référence à l'identifiant du client qui effectue cette réservation.
  • start_timestamp – stocke la date et l'heure prévues de l'arrivée du client.
  • duration_in_minutes – stocke la durée pour laquelle la réservation a été effectuée.
  • booking_date – stocke la date à laquelle la réservation a été effectuée.
  • parking_slot_id – colonne interne qui attribue une place de parking à un client une fois sa demande saisie et le paiement effectué.

parking_slip – stocke des informations sur les heures d'entrée et de sortie du client, ainsi que sur les frais applicables. Nous avons créé ce tableau pour les parkings qui autorisent plusieurs entrées et sorties sous la même réservation. Les colonnes de ce tableau sont :

  • id – la clé primaire de cette table.
  • parking_slot_reservation_id – colonne référencée qui identifie la demande de réservation associée.
  • actual_entry_time – stocke la date d'arrivée et l'horodatage du client.
  • actual_exit_time – stocke la date et l'horodatage de départ (sortie) du client.
  • basic_cost – stocke le coût de base de la réservation.
  • penalty – stocke une valeur de 0 par défaut. Si un client retarde sa sortie, des frais de pénalité seront appliqués et la valeur dans cette colonne sera mise à jour.
  • total_cost – cette colonne ajoute simplement les valeurs du basic_cost et les colonnes de pénalité.
  • is_paid – la rentrée n'est généralement autorisée que lorsqu'un client a payé ses frais de stationnement. Cette colonne indique si ce paiement a été effectué.

Conclusion

Dans cet article, nous avons présenté un aperçu d'un modèle de données pour un système de gestion de parking. Il existe de nombreuses applications qui aident les utilisateurs à trouver des places de stationnement en extrayant, traitant et compilant des données (telles que la disponibilité et les coûts) pour les parkings dans un voisinage spécifié. Ceci est particulièrement utile pour les personnes visitant de grandes villes comme New York, Los Angeles et d'autres où trouver un parking peut être un cauchemar si vous ne planifiez pas soigneusement votre visite. Ces applications s'appuient sur des modèles de données et des API de bases de données bien conçus pour récupérer ces informations.

Dans notre prochain article, nous transformerons notre modèle de données actuel en une solution pour un système de disponibilité de stationnement en temps réel. N'hésitez pas à poster vos réflexions, commentaires et recommandations dans la section des commentaires ci-dessous.