Tap and Park：駐車場アプリのデータモデル

さまざまなアプリが駐車場の検索を簡単にすることを約束します。データモデリングメガネを使用して、このタイプのアプリを調べてみましょう。基礎となるモデルはどのように見えますか？

以前の記事では、駐車場の構造と、駐車場を管理するためのデータモデルの設計方法について説明しました。この記事では、駐車場アプリのデータモデルを調べています。あなたはこれらのアプリを知っています：それらは近くの駐車オプションをリストし、あなたに価格を教え、そしてあなたがスペースを予約または予約するか、駐車パスを購入することを可能にします。

このアプリケーションは、駐車場の検索を比較的簡単にします。駐車場を選ぶ上で最も重要な要素は価格だと思います。数ドル節約できる徒歩5分は常に価値があります。そうは言っても、データモデリングメガネを着用して、駐車場アプリの世界を詳しく見てみましょう。

駐車場と駐車アプリについて知っておくべきこと

駐車アプリは非常にシンプルです。駐車スペースの空き状況と価格をリアルタイムで追跡し、そのスペースを予約し、料金を支払う機能が期待できます。

データモデラーが比較的扱いやすい場所を除けば、駐車場の主な推進要因は価格です。駐車スペースの価格戦略は非常に単純であり、特定の方法またはルールは実質的に普遍的です：

駐車場は、時間によって価格が異なることがよくあります。 1日は通常、朝（6:00から11:00 am）、正午（11:00amから5:00pm）、夕方（5:00から10:00 pm）の3つの部分に分けられます。
通常、夕方と朝は料金が高くなります。これは、これらの時間帯により多くの車がスペースを必要とする可能性があるためです。
料金は曜日によって異なる場合があります。たとえば、市内中心部近くの駐車場は、週末（土曜日と日曜日）に多くの人が訪れるため、料金が高くなります。
ほとんどの場合、ロットは標準価格を使用します。ただし、追加料金が発生する日もあります。野球場の近くの駐車場は、競技場で試合やイベントが行われると、より多くの料金がかかる場合があります。
交通機関のハブ（空港、駅、バス停）の近くに駐車場があると、1日24時間または1週間駐車できる場合があります。長期駐車には特別料金がかかる可能性があります。
一部の駐車場では、固定費で月額パスを発行しています。月額パスの所有者は、日額料金を支払う代わりに、毎月定額を支払います。

データモデル

ご覧のとおり、3つの主題分野があります。

「駐車場」
「お客様」
「駐車予約」

最初に最も重要な主題分野、つまり駐車場とその価格設定を扱う分野を取り上げましょう。

駐車場

このサブジェクトエリアは、parking_lot システム内の各駐車場の詳細を格納するテーブル。この表は、駐車場管理データモデルに関する以前の記事で詳しく説明されています。ただし、ここでいくつかの重要な列を繰り返します：

zip –郵便番号。これは検索機能で主要な役割を果たします。
is_slot_available –駐車場の運営者によって更新され、現在空きがあるかどうかを示します。
is_reentry_allowed –顧客がその区画を離れた後、その区画に再び駐車できるかどうか。再入場が許可されていない場合、リピーターは別のスペースを購入する必要があります。
is_valet_parking_available –バレーパーキングは追加料金がかかりますが、人々はしばしばそれを好みます–特に彼らがデートしているとき。 😉
operational_in_night –駐車場が夜間に開いているかどうか。この情報は、車が空港の近くに駐車していて、飛行機が深夜に到着するときに非常に重要になります。
minimum_hr_pay –車をたくさん駐車するための最低料金。たとえば、一部の区画では最低3時間です。つまり、30分間しか駐車していなくても、3時間支払うことになります。
is_monthly_pass_allowed –多くが月額パスを提供しているかどうか。

駐車料金の設定に影響する要素については、すでに説明しました。次に、モデルで価格設定をどのように処理するかを見てみましょう。 parking_pricing 通常価格とpricing_exception 例外を記録するためのテーブル。どちらのテーブルも同様の構造であり、列は一目瞭然です。唯一の違いは次のとおりです。

parking_pricing テーブルには列があります（day_of_week ）価格に関連する曜日を格納します。 pricing_exception テーブルにはcalendar_dateがあります特別価格が適用された実際の日付を保持する列。
アプリが価格を表示しているとき、pricing_exception テーブルはparking_pricing テーブル。したがって、今日の通常料金が1時間あたり5ドルで、7ドルの特別料金が有効になっている場合、アプリには1時間あたり7ドルが表示されます。

このサブジェクトエリアのファイナルテーブルは、offers 。割引クーポンとそれに関連する詳細の記録を保持します。以前の記事で、オファー、取引、割引の背後にあるデータモデルについて説明しました。この表は同じ理論に基づいており、すべての列は自明である必要があります。

お客様

駐車場アプリについて考えるとき、通常、次の3つの要素について考えます。

お客様 –これには、一意の顧客IDと、名前や電話番号など、アプリユーザーに関する基本的な詳細が含まれます。また、請求先住所を知っておくとよいでしょう。
車両 – 1人が複数の車を所有できるため、アプリユーザーとその車両の間で1対多の関係を築くことができる必要があります。明らかに、ライセンス番号などで車両を識別する方法が必要です。
支払い方法 –このアプリケーションでは、顧客が駐車スロットを予約して支払いを行うことができるため、支払い方法を保存する方法が必要です。繰り返しになりますが、ユーザーごとに複数の支払い方法を設定する方法が必要です。

このモデルには、これらのエンティティごとに1つのテーブルがあります。 customer_id 属性はvehicle およびpayment_method テーブル;ユーザーを車両と支払い方法にリンクします。

駐車予約

このサブジェクトエリアには、2つのテーブルのみが含まれています。 2つのうち、「parking_one_time_reservation」テーブルには予約の詳細が格納されます。その列のいくつかは自明です。その他は：

start_timestamp –予約期間が開始する日時。
pay_for_min_hr –予約が特定の時間数（たとえば、午前9時から正午まで）の場合は「N」を保持します。それ以外の場合、この属性には「Y」が付きます。
booking_for_hr –予約の時間数。これはnull許容フィールドです。 pay_for_min_hrの場合にのみ値があります「N」に設定されています。上記の例では、午前9時から正午までの3時間は「3」に設定されます。
basic_parking_cost –基本的な駐車料金（現地通貨）。
offer_code –該当する場合は、クーポンコード。オファーコードの適用はオプションであり、空き状況によりますので、この列はnull許容です。
net_cost –顧客がチェックアウト時に支払う実際の金額（ロットを離れるとき）。
is_paid –駐車料金が支払われているかどうか。同じ駐車場で再入場が許可されている場合、これは重要な列になります。このような場合、支払いは通常、最初のチェックアウト時（つまり、車が最初にロットを離れるとき）に決済されます。

parking_monthly_pass 表には、このアプリケーションを通じて顧客に発行されたすべての月間パスに関する情報が記録されています。マンスリーパスは、将来の日付であっても、いつでも購入できます。したがって、purchase_dateという2つの別個の列があります。およびstart_date 、アプリユーザーが将来有効なパスを購入できるようにします。他の列は自明です。

駐車場アプリのデータモデルに他に何を追加できますか？

最新の駐車場には、ライセンスプレートリーダー、センサー、自動駐車アクセス制御システム、スマートパーキングメーターなど、あらゆる種類のテクノロジーが搭載されています。これらの高度なシステムにより、駐車場の運営が容易になり、ドライバーが使いやすくなります。

このデータモデルは、設備の整った駐車場をサポートするためにどのような追加の変更が必要ですか？コメント欄で感想をお聞かせください。