Diverses applications promettent de rendre votre recherche de stationnement indolore. Examinons ce type d'application à l'aide de nos lunettes de modélisation de données. À quoi ressemble le modèle sous-jacent ?
Dans un article précédent, nous avons expliqué comment un parking est structuré et comment un modèle de données peut être conçu pour en gérer un. Dans cet article, nous examinons le modèle de données d'une application de stationnement. Vous connaissez ces applications :elles répertorient les possibilités de stationnement à proximité, vous indiquent les tarifs, et vous permettent de réserver ou de réserver une place ou d'acheter un pass de stationnement.
Cette application rend votre recherche de stationnement relativement indolore. Je dirais que le facteur le plus important dans le choix d'une place de parking est le prix. Une promenade de cinq minutes qui permet d'économiser quelques dollars en vaut toujours la peine. Cela étant dit, enfilons nos lunettes de modélisation de données et examinons de près le monde des applications de parking.
Que devons-nous savoir sur les parkings et les applications de stationnement ?
Les applications de stationnement sont assez simples :on peut s'attendre à des fonctions permettant de suivre la disponibilité et le prix des places de stationnement en temps réel, de réserver lesdites places et de payer les frais.
Outre l'emplacement, qui est relativement facile à gérer pour un modélisateur de données, le facteur clé des parkings est le prix. La stratégie de tarification des places de stationnement est assez simple et certaines méthodes ou règles sont pratiquement universelles :
- Les parkings ont souvent des prix différents selon les périodes. Une journée est généralement divisée en trois parties :le matin (de 6 h 00 à 11 h 00), le midi (de 11 h 00 à 17 h 00) et le soir (de 17 h 00 à 22 h 00).
- Les soirées et les matinées ont généralement des prix plus élevés, car plus de voitures sont susceptibles d'avoir besoin d'une place pendant ces heures.
- Les tarifs peuvent également varier en fonction des jours de la semaine. Par exemple, un parking à proximité d'un centre-ville facturera plus le week-end (samedi et dimanche), car c'est à ce moment-là que les visiteurs sont les plus nombreux.
- La plupart du temps, les lots utilisent leurs prix standards. Cependant, il y a des jours où ils peuvent facturer plus - par ex. les parkings à proximité des stades de baseball peuvent facturer plus lorsqu'un match ou un événement a lieu dans le stade.
- Les parkings à proximité des centres de transport (aéroports, gares et arrêts de bus) peuvent autoriser le stationnement 24 heures ou une semaine. Ils auront probablement un tarif spécial pour le stationnement de longue durée.
- Certains parkings émettent des laissez-passer mensuels à un coût fixe. Les détenteurs d'un pass mensuel paient le montant fixe chaque mois au lieu de payer des frais quotidiens.
Le modèle de données
Comme vous pouvez le voir, il y a trois domaines :
- "Parc de stationnement"
- "Client"
- « Réservation de stationnement »
Prenons d'abord le sujet le plus important - celui qui gère les parkings et leur tarification.
Parking
Ce domaine concerne le parking_lot table, qui stocke les détails de chaque parking dans notre système. Ce tableau est expliqué en détail dans notre article précédent sur un modèle de données de gestion de parking. Cependant, nous rappellerons ici quelques colonnes importantes :
zip– Un code postal; cela joue un rôle majeur dans la fonction de recherche.is_slot_available- Mis à jour par les opérateurs de parking et indique si l'espace est actuellement disponible.is_reentry_allowed– Si un client peut se garer à nouveau dans le parking après l'avoir quitté. Si la rentrée n'est pas autorisée, le client qui revient devra acheter un autre espace.is_valet_parking_available– Le service de voiturier coûte plus cher, mais les gens le préfèrent souvent, surtout lorsqu'ils sont en rendez-vous. 😉operational_in_night– Si le parking est ouvert la nuit. Ces informations deviennent très importantes lorsque votre voiture est garée près d'un aéroport et que votre vol arrive à minuit !minimum_hr_pay– Le tarif minimum pour garer votre voiture dans un parking. Par exemple, certains parkings ont un minimum de trois heures, ce qui signifie que vous payez pour trois heures même si vous n'êtes garé que pendant 30 minutes.is_monthly_pass_allowed–Si un lot offre des laissez-passer mensuels.
Nous avons déjà discuté des facteurs qui entrent dans la fixation des tarifs de stationnement. Voyons maintenant comment nous allons gérer la tarification dans notre modèle. Nous utiliserons le parking_pricing tableau pour conserver un enregistrement des prix réguliers et de l'pricing_exception table pour enregistrer toutes les exceptions. Les deux tableaux ont une structure similaire et les colonnes sont explicites. Les seules différences sont :
- Le
parking_pricingla table a une colonne (day_of_week) qui stocke le jour de la semaine correspondant à un prix. Lepricing_exceptionla table a unecalendar_datecolonne qui contient la date réelle à laquelle le prix spécial était applicable. - Lorsque l'application affiche les prix, le
pricing_exceptiontable a priorité sur leparking_pricingtable. Ainsi, si le tarif normal d'aujourd'hui est de 5 $ de l'heure, mais qu'un tarif spécial est en vigueur pour 7 $, l'application affichera 7 $ de l'heure.
Le tableau final dans ce domaine est offers . Il contient des enregistrements de coupons de réduction et leurs détails associés. Nous avons expliqué le modèle de données derrière les offres, les offres et les remises dans un article précédent. Ce tableau est basé sur la même théorie, et toutes les colonnes doivent être explicites.
Client
Lorsque nous pensons à une application de stationnement, nous pensons généralement à ces trois éléments :
- Clients - Cela inclut un identifiant client unique et des informations de base sur les utilisateurs de l'application, telles que leur nom et leur numéro de téléphone. De plus, il serait bon d'avoir leur adresse de facturation.
- Véhicules - Une personne peut avoir plusieurs voitures, nous devrions donc avoir la possibilité d'établir une relation un à plusieurs entre un utilisateur de l'application et ses véhicules. Évidemment, nous aurions besoin d'un moyen d'identifier les véhicules, par exemple par leur numéro d'immatriculation.
- Modes de paiement – Étant donné que cette application permet aux clients de réserver une place de parking et de la payer, nous avons besoin d'un moyen de stocker les méthodes de paiement. Encore une fois, il devrait y avoir un moyen d'avoir plusieurs méthodes de paiement par utilisateur.
Ce modèle comporte une table pour chacune de ces entités. Le customer_id l'attribut est référencé dans le vehicle et payment_method les tables; il relie les utilisateurs aux véhicules et aux méthodes de paiement.
Réservation de stationnement
Ce domaine ne contient que deux tableaux. Des deux, la table « parking_one_time_reservation » stocke les détails de la réservation. Certaines de ses colonnes sont explicites; les autres sont :
start_timestamp– La date et l'heure de début de la période de réservation.pay_for_min_hr– Tient un « N » si la réservation est pour un nombre d'heures spécifique (par exemple de 9 h à midi). Sinon, cet attribut aura un "Y".booking_for_hr– Le nombre d'heures d'une réservation. Il s'agit d'un champ nullable ; il n'aura de valeur que lorsquepay_for_min_hrest réglé sur « N ». Dans l'exemple ci-dessus, il serait défini sur "3" pour les trois heures qui s'écoulent entre 9h00 et midi.basic_parking_cost– Le coût de stationnement de base, en monnaie locale.offer_code– Un code promo, le cas échéant. Étant donné que l'application d'un code d'offre est facultative et soumise à disponibilité, cette colonne est nulle.net_cost– Le montant réel que les clients paient à la caisse (lorsqu'ils quittent le terrain).is_paid– Si les frais de stationnement ont été payés. Cela devient une colonne importante lorsque la rentrée est autorisée sur le même bordereau de stationnement. Dans de tels cas, les paiements sont généralement réglés lors du premier paiement (c'est-à-dire la première fois que la voiture quitte le parking).
Le parking_monthly_pass table enregistre des informations sur tous les laissez-passer mensuels délivrés aux clients via cette application. Les pass mensuels peuvent être achetés à tout moment, même pour des dates futures. Nous avons donc deux colonnes distinctes, purchase_date et start_date , qui permettent aux utilisateurs de l'application d'acheter des pass valables à l'avenir. Les autres colonnes sont explicites.
Que pouvons-nous encore ajouter au modèle de données de l'application Parking ?
Les parkings modernes sont équipés de toutes sortes de technologies, telles que des lecteurs de plaques d'immatriculation, des capteurs, des systèmes de contrôle d'accès automatisés et des parcmètres intelligents. Ces systèmes avancés rendent les parkings plus faciles à gérer et plus faciles à utiliser pour les automobilistes.
De quelles modifications supplémentaires ce modèle de données a-t-il besoin pour prendre en charge les parkings entièrement équipés ? S'il vous plaît dites-nous ce que vous en pensez dans la section des commentaires.
