あなたはあなたの最後の休暇で車を借りたかもしれません。オンラインで車を予約し、以前に合意した料金をすべて支払った後、指定された場所から車を受け取りました。完了したら、それを代理店に返却し、おそらく追加料金を支払いました。これらすべてを実現するシステムについて考えたことはありますか?この記事では、レンタカーシステムのデータモデルを見ていきます。
別のレンタカーデータモデルを構築する理由
国際的なレンタカー会社のために、完全に機能するシステムのデータモデルを設計したいと思います。同社は、さまざまなセグメント(ミニ、エコノミー、中間、SUV、貨物、リムジン)で車両をレンタルし続けています。複数の国のさまざまな都市で事業を展開しています。同社は、顧客が1つの場所(ピックアップ場所)からレンタカーを借りて、別の場所(ドロップオフ場所)に降車することを許可しています。
この時点で、簡単なレンタカー会社のモデルについて説明している以前の記事を参照してみましょう。このモデルは、レンタカー会社が提供するすべての基本的なサービスに対応しています。
新しい関数を追加する前に、このモデルにいくつかの小さな変更を組み込みたいと思います。つまり、次のとおりです。
-
city
を追加するlocation
テーブル、および都市テーブルを完全に削除します。 -
zip
という列を1つ追加します (郵便番号または郵便番号のように)、location
テーブル。このシステムは、郵便番号によってピックアップ/ドロップオフの場所を識別します。郵便番号が英数字である国はたくさんあるので、この列はvarchar列として保持します。 -
driving license issue date
を追加customer
テーブル。最高速度制限がドライバーにライセンスが発行された時期によって異なる国がいくつかあります。 category
car_category
、その内容をより正確に説明します。- 集荷場所が空港の近くにある場合は、顧客のフライト情報を保存します。これにより、システムは、フライトの遅延やキャンセルが発生した場合に、顧客の予約リクエストに適切な変更を加えることができます。これを行うには、
flight_detail
reservation
テーブル。
顧客の請求書情報の追加
請求には、自動車や設備を含む各在庫品目のレンタル価格を保存する必要があります。予約プロセスは個々の車ではなくカテゴリを扱うため、レンタル費用は各カテゴリに割り当てられます。
rental_value
を追加しましょう car_category
およびequipment_category
テーブル。
同様の路線では、保険に関連する費用が必要です。この費用は保険会社が決定します。今のところ、insurance
テーブル。
請求のために、すべての請求書の詳細を保存するための別のテーブルを作成します。このようにして、これらの同じ詳細を必要なときにいつでも簡単に取得できます。これらの値の計算は少し難しいので、請求書に対して何度も繰り返すことはしません。 1つのテーブル、つまりrental_invoice
、これは主にrental
テーブル。
rental_invoice
表には次の列が含まれています:
-
id
–このテーブルの主キー。 -
rental_id
–rental
テーブル。この列に1つの一意の制約を追加します。レンタルごとに1つのレコードしか存在できません。 -
car_rent
–この列は、レンタル車両のレンタル費用を示します。 -
このコストは、次のSQLを使用して決定できます。
select a.rental_value from car_category a, car b, rental c where c.car_id = b.car_id and b.category_id = a.id and c.id =
; -
equipment_rent_total
–この列には、顧客に貸し出された機器の請求額が表示されます -
総コストは、次のSQLを使用して決定できます。
select sum(a.rental_value) from equipment_category a, equipment b, car_equipment c, car d, rental e where a.id = b.equipment_category_id and b.id = c.equipment_id and c.car_id = d.id and d.id = e.car_id and e.id =
; -
insurance_cost_total
–この列は、顧客の保険費用の合計です。これは、次のSQLを使用して判別できますselect sum(a.cost) from insurance a, rental_insurance b, rental c where a.id = b.insurance_id and b.rental_id = c.id and c.id =
; -
service_tax
およびVAT
–名前が示すように、これらの列には、該当するサービス税とVATの値が格納されます。 -
total_amount_payable
–この列には、請求書の合計金額の値が含まれます。これは、次の列の合計になります。total_amount_payable =car_rent + Equipment_rent_total + Insurance_cost_total
-
waiver_amount
およびnet_amount_payable
–これらの列には、免除額(ある場合)と支払期日が到来する正味額の値が格納されます。waiver_amount
請求書の合計からいくら免除されるかです。レンタカー会社が顧客に割引を提供するときに一般的に使用されます。net_amount_payable
を決定するための式 次のようになります:net_amount_payable =total_amount_payable – waiver_amount
モバイルインベントリ –レンタカー会社の場合、ある場所から別の場所に移動するため、在庫は常に移動可能です。オンラインで車を予約するときに「別の場所に戻る?」というチェックボックスに気付いた場合は、その動作を確認しています。返却場所が集荷場所と同じでない場合、システムはリクエストを少し異なる方法で処理します。システムは、貸し出されて返却されたときに、常に在庫を追跡します。
たとえば、ある顧客がシカゴから車を借りて、降車場所が異なることを確認し、セントルイスの目的地まで車で移動します。明らかに、彼は会社のセントルイスの場所に車を降ろします。この場合、彼がシカゴの場所から車を運転するとすぐに、在庫のこの部分はそのオフィスに縛られなくなります。車は、彼がそれを使い終えるとすぐに、今度はセントルイスのオフィスに再び登録されます。
このメカニズムを組み込むために、1つの列、つまりcurrent_location_id
を追加します。 、car
テーブルとequipment
テーブル。この列には、location
テーブル。
したがって、上記の例では、車の最初の場所はシカゴです。お客様が目的のオフィスに車を返却した後に更新されます。
給油オプションの設定
ほとんどのレンタカー会社は、次の種類の給油オプションを提供しています。- 燃料サービスの進歩 –顧客は燃料の満タンの料金を前払いし、空のタンクで車を返却します。
- 燃料サービス料 –顧客は満タンの燃料で車を手に入れますが、燃料の使用量に基づいて料金を支払います。
- 燃料セルフサービス –顧客は、燃料が満タンの車を受け取り、満タンの車を返却します。これは、3つの中で最も広く受け入れられているオプションです。
ここでは、お客様がどのオプションを選択するかは関係ありません。私たちが望んでいるのは、レンタルリクエストの処理中に彼らの選択を登録することです。
このニーズを満たすために、fuel_option
、車に燃料を供給するためのすべての可能なオプションを保存します。レンタルリクエストとfuel_option
、レンタル予約時にお客様のご選択をお願いしておりますので。
最終的なレンタカーデータモデル
多くの地域で、レンタカー会社は顧客のためにキーレスのセルフサービスのレンタル体験を利用する方向にシフトしています。彼らは、事務処理を完了して車のキーを受け取るためだけに顧客をカウンターで待たせたくありません。現在のデータモデルはそのような要件に対応できますか?それを実現するには、データモデルにどのような変更が必要ですか?
レンタカーのデータモデルについて何か考えはありますか?話し合いを始めましょう!コメントセクションでご意見をお聞かせください。