駐車場管理システムのデータモデルの構築

調査によると、車は生涯の95％の間駐車されたままであり、駐車場管理システムはスマートで効率的かつ堅牢でなければならないことが示唆されています。この記事では、そのようなシステムのデータモデルを構築します。

はじめに

データモデルの構築を開始する前に、まず駐車場の構造と運用方法を理解する必要があります。これら2つの重要な領域を簡単に見てみましょう。

駐車場はどのように構成されていますか？

一般的な駐車場は、1つまたは複数のブロックで構成されており、さらにフロアに分割されています。各フロアには、ドライバーが向きを変えて駐車場を覚えるのに役立つ複数の翼があります。これらは通常、「A」、「B」、「C」などの文字でラベル付けされています。床には通常、特定の車両が駐車場に入るのを制限する高さ制限があります。さらに、フロアにはいくつかの一意の番号の駐車スロットがあります。これらのスロットのいくつかは、障害者のために予約されています。その他は、定期的な訪問者が一定の費用で予約できます。
駐車場はどのように機能しますか？

駐車場がどのように機能するかを理解するには、駐車場を訪れる人々のタイプについてもっと知る必要があります。駐車場に入る顧客は、次のいずれかのグループに属します。
- 隔週、月次、または年次パスを購入した常連客。
- スロットをリモートで（電話またはオンラインで）予約したプリペイドの顧客。
- パスを持っておらず、リモートでスロットを予約していない持ち込み客。スロットは、可用性に基づいてそのような顧客に割り当てられます。
通常の顧客には、ダッシュボードやフロントガラスのどこかに見える場所に配置するためのカード/ステッカーが渡されます。これにより、駐車場の管理者は、顧客が駐車規則に違反していないことを簡単に判断できます。たまに訪れる人とは異なり、常連客には毎日駐車券が発行されることはありません。駐車場は通常、定期的な訪問者が常に駐車できる場所を確保するために、ブロック全体またはフロア全体を予約します。通常のお客様は、自分でスロットを予約して、毎日同じ指定のスロットに車を駐車できるようにすることもできますが、これには通常、追加料金がかかります。

遠隔駐車場の予約をする人は、通常、指定されたスロットを数時間の限られた時間枠でのみ使用できます。その後、スロットは解放されます。これらの訪問者が駐車場に入るとき、彼らは彼らの予約されたスロットに駐車しなければなりません。時間枠を過ぎて駐車場を離れなかったお客様にはペナルティが課せられますが、予約が切れる前に必ず離れることができます。一部の駐車場には、固定の最小時間枠があります（たとえば、1時間しか駐車しない場合でも、顧客は3時間のスロットを予約する必要がある場合があります）。

持ち込みのお客様は、駐車場に入ると駐車券が渡されます。次に、顧客が指定した設定に基づいて、伝票が生成されるときに駐車スロットが顧客に割り当てられます。ここでの予約プロセスは、基本的にプリペイドのお客様の場合と同じです。ただし、持ち込み予約は完全に空室状況に依存します。スロットは、事前にスポットを予約する場合よりもコストがかかる場合があります。特に、可用性が限られていて需要が高い場合はそうです。

データモデル

これらの要件を念頭に置いて、先に進んでデータモデルを作成しましょう。今回は、3つの主要なセクションで作業します。

駐車場
お客様
駐車予約

データモデルのこれらの各領域を詳しく見ていきましょう。

セクション1：駐車場

駐車場セクションは、駐車場自体に関するすべての重要な情報を収集するだけでなく、駐車場の最小単位（スロット）を会社が管理する方法を簡素化します。後のセクションで駐車場の予約と操作をより効率的にすることを唯一の目的として、いくつかのテーブル列が追加されました。

はじめに説明した駐車場の構造に従って、必要なすべての詳細をキャプチャするために次の表を作成しました。

parking_lot –駐車場に関する基本情報を保存します。このテーブルの列は次のとおりです。

id –このテーブルの主キー。各駐車場に一意の番号を割り当てます。
number_of_blocks –駐車場のブロック数を追跡します。
is_slot_available –駐車場に現在利用可能なスロットがあるかどうかを示します。
アドレス –駐車場の完全な住所を保存します。
zip –駐車場の郵便番号を保存します。これにより、顧客は希望の郵便番号を照会するだけで、特定のエリア内で利用可能な駐車場をより簡単に検索できます。
is_reentry_allowed –顧客が駐車場を出て、同じ駐車伝票で再入場できるかどうかを示します。多くの駐車場では通常、お客様がこれを行うことを許可していないことに注意してください。このような駐車場では、特定の日に再入場するたびに新しい伝票を購入する必要があります。
operating_company_name –駐車場を運営している会社の名前を保存します。
is_valet_parking_available –駐車場がバレーパーキングサービスを提供しているかどうかを示します。

ブロック –駐車場は1つ以上のブロックに分割されています。このテーブルには、駐車場の各ブロックに関する情報が格納されています。この表の列は次のとおりです。–駐車場は1つ以上のブロックに分割されています。このテーブルには、駐車場の各ブロックに関する情報が格納されています。このテーブルの列は次のとおりです。

     id   –このテーブルの主キー。
   parking_lot_id  –   parking_lotから参照される列  ブロックが属する駐車場を識別するテーブル。
   block_code  –このブロックに関連付けられたコードを格納します。ブロックには通常、「A」、「B」、「C」、「11」、「22」、「33」などの一意の識別コードが付けられます。
   number_of_floors  –このブロックのフロア数を格納します。数字の「1」は、これが床のない地上のブロックであることを示しています。
   is_block_full  –ブロックが現在いっぱいかどうかを示します。
 
 
 フロア  –マルチレベルの駐車場では、ブロックに複数のフロアを含めることができます。ただし、このテーブルは地上レベルのブロックからも参照できます。このテーブルの列は次のとおりです。
    id  –このテーブルの主キー。
   block_id  –フロアが属するブロックを識別します。
   floor_number  –フロアの数を表します（1 =地上レベル）。
   max_height_in_inch  –マルチレベルの駐車場では、各フロアに高さの制約があります。この列には、床にある車両の最大許容高さが格納されます。
   number_of_wings  –フロアはさらにウィングに分割されており、顧客が駐車した場所を思い出すのに役立ちます。この列には、床に存在する翼の数が格納されます。
   number_of_slots  –フロアに存在するスロットの数を格納します。
   is_covered  –床が覆われているかどうかを識別します。マルチレベルの駐車場または1階の駐車場の最上階が覆われることはありません。
   is_accessible  –特に障害者が床に簡単にアクセスできるかどうかを示します。マルチレベルの区画に稼働中のエレベーターがある場合、その各フロアはアクセス可能であると見なされます。
   is_floor_full  –フロアが完全に占有されているかどうかを示します。
   is_reserved_reg_cust  –フロアが常連客のために厳密に予約されているかどうかを示します。
 
 
   parking_slot   –このテーブルには、駐車場の駐車スロットに関するすべての情報が格納されます。このテーブルの列は次のとおりです。
    id  –このテーブルの主キー。
   floor_id  –スロットが属するフロアを識別します。
   slot_number  –特定のフロアのスロットの一意の識別子を格納します。
   wing_code  –スロットが配置されているウィングを識別します。
 
 セクション2：顧客
   
 
 次に、顧客に関するすべての関連情報の詳細を説明します。駐車場は、名前や住所などの個人情報を取得して保存する必要がないため、必要に応じていつでもローカルDMVポータルにアクセスしてそのような情報を取得できることに注意してください。 
 
 顧客  –駐車場を訪れる可能性のあるすべての種類の顧客に関するすべての関連情報を保存します（通常、1回限り、前払い）。このテーブルの列は次のとおりです。
    id  –顧客の一意の識別子。
   Vehicle_number  –顧客の車両のナンバープレート番号を保存します。
   register_date  –車両が最初に駐車場に登録された日付を保存します。
   is_regular_customer  –顧客が通常のパスを持っているかどうかを示します。列にtrueの値が格納されている場合は、  regular_passに有効なエントリが存在する必要があります  テーブル。パスの有効期限が切れ、顧客がまだパスを更新していない場合、この列の値はfalseに更新されます。
   contact_number  –顧客の連絡先番号を保存します。連絡先番号を駐車場と共有することを躊躇する人もいるため、この列は無効にしています。
 
 
   regular_pass   –顧客に発行される通常のパスに関する情報を格納します。このテーブルの列は次のとおりです。
    id  –このテーブルの主キー。
   customer_id  –顧客テーブルからの参照列。
   Purchase_date  –パスを購入した日付を保存します。
   start_date  –パスが有効であると見なされる日付を保存します。これは、一部の顧客が事前にパスを購入するため、必ずしも購入日であるとは限りません。
   duration_in_days  –パスが有効な日数を格納します。毎月のパスは通常30日間有効です。
 コスト –顧客がパスを購入するために支払う必要のあるコストを現地通貨で保存します。
 
 セクション3：予約
   
 
 最後のセクションでは、駐車場の予約プロセスについて詳しく説明します。予約の際、顧客は通常、到着予定日時、スロットの予約時間など、特定の詳細を提供する必要があります。このセクションの2つの主要な表について以下で説明します。
 
 parking_slot_reservation   –予約の詳細を維持します。このテーブルの列は次のとおりです。
    id  –個々の予約リクエストに一意の参照番号を割り当てます。
   customer_id  –この予約を行っている顧客の識別子への参照。
   start_timestamp  –顧客の到着予定日時を保存します。
   duration_in_minutes  –予約が行われた期間を保存します。
   booking_date  –予約が行われた日付を保存します。
   parking_slot_id  –顧客の要求がキャプチャされ、支払いが行われると、顧客に駐車スロットを割り当てる内部列。
 
 
   parking_slip   –顧客の入場時間と退場時間、および関連する料金に関する情報を保存します。このテーブルは、同じ予約で複数の出入りが可能な駐車場用に作成されました。このテーブルの列は次のとおりです。
    id  –このテーブルの主キー。
   parking_slot_reservation_id  –関連する予約リクエストを識別する参照列。
   actual_entry_time  –顧客の到着日とタイムスタンプを保存します。
   actual_exit_time  –顧客の出発（出口）の日付とタイムスタンプを保存します。
   basic_cost  –予約の基本コストを保存します。
 ペナルティ –デフォルトで値0を格納します。顧客が退出を遅らせると、ペナルティ料金が適用され、この列の値が更新されます。
   total_cost  –この列は、 basic_costの値を追加するだけです。 とペナルティ列。
   is_paid  –再入場は通常、顧客が駐車料金を支払った場合にのみ許可されます。この列は、この支払いが行われたかどうかを示します。
 
 結論
 
 この記事では、駐車場管理システムのデータモデルの概要を説明しました。特定の周辺の駐車場のデータ（空き状況や費用など）を抽出、処理、編集することで、ユーザーが駐車スペースを見つけるのに役立つアプリはたくさんあります。これは、ニューヨークやロサンゼルスなどの大都市を訪れる人々にとって特に便利です。ここでは、慎重に訪問を計画しないと、駐車場を見つけることが悪夢になる可能性があります。このようなアプリケーションは、適切に設計されたデータモデルとデータベースAPIを使用して、この情報を取得します。 
 
 次の記事では、現在のデータモデルをリアルタイムの駐車場利用可能性システムのソリューションに変換します。以下のコメントセクションに、ご意見、フィードバック、推奨事項をお気軽に投稿してください。