タクシーサービスのデータベースモデル

それらをタクシーまたはタクシーと呼んでください。これらの便利なレンタル乗り物は何世紀にもわたって存在しています。今日では、タクシーサービスを実行することははるかに複雑です。この記事では、タクシー会社のニーズを満たすように設計されたデータベースモデルを見ていきます。

「タクシーを呼ぶ」の歴史は17世紀のロンドンで始まりました。ほとんどの場所で、タクシーはこれまで以上に手頃な価格です。また、アクセスしやすくなっています。電話、モバイルアプリケーション、またはWebでタクシーを注文できます。または、何百年もの間機能してきたのと同じ手法を使用することもできます。タクシーの駅に並ぶか、路上で旗を立てます。

タクシーのビジネスモデルは決して停滞していません。 UberやLyftのような新しいコンセプトが人気を集めており、タクシーサービスの将来に確かに影響を与えるでしょう。もちろん、これらすべてがタクシー会社を経営する人々の生活を複雑にします。タクシー会社が整理整頓に使用できるデータモデルの関連部分を見てみましょう。

このCabデータベースモデルで何を達成したいですか？

この記事で紹介するモデルは、次のことができるようになります。

ドライバースケジュールを作成する
ドライバーの可用性をリアルタイムで追跡
潜在的な乗り物のリストをドライバーに提供する
ドライバーがリストから乗り物を選択できるようにする
ドライバーの労働時間と収入を計算する
さまざまな統計情報を保存します（たとえば、キャンセルした乗車の割合、1か月あたりのドライバーあたりの支払いなど）

タクシー会社について知っておくべきこと

タクシー会社のデータモデルを設計する前に、次の質問に答えられるはずです。

ドライバーはいつ動作しますか？
ほとんどのタクシー会社では、運転手は事前に定義されたスケジュールを持っています。ドライバーがシフトを開始および終了する正確な時刻がわかります。場合によっては、シフトの開始時間と終了時間が事前に定義されていません。たとえば、タクシー協会のメンバーは、いつでもログインして作業を開始できます。また、ログアウトして、選択したときにシフトを終了することもできます。私たちのモデルは両方のオプションをサポートできるはずです。
ドライバーは同じ日に複数のシフトで作業できますか？
運転手がタクシー協会の会員である場合、彼らは朝に働き、家に帰り、そして同じ夜に再び働くことができるかもしれません。ただし、一部の地域（ニューヨーク市など）では、シフトの長さやタクシーの運転手が1日に何時間働くことができるかについて法的な制限があります。
3。誰が乗車を開始しますか？
ほとんどの場合、顧客はタクシーのコールセンターに連絡し、コーディネーターがシステムにリクエストを入力します。別のシナリオは、顧客がタクシーを直接（たとえば、モバイルアプリを介して）注文し、そのプロセスにコールセンターの従業員が関与していない場合に発生します。 3番目のオプション（これもコールセンターをバイパスします）は、顧客が駅でタクシーを利用するか、路上でタクシーを呼ぶときに発生します。

データモデル

このモデルには、2つの主要なセクションと3つの未分類のテーブルがあります。それぞれについて詳しく見ていきます。

セクション1：タクシー、ドライバー、シフト

すべてはタクシーと運転手から始まります。タクシー会社には車が必要であり、運転手が必要です。（将来的には、自動運転車のモデルを調整する必要があるかもしれません。ただし、今は現在にとどまりましょう。）

driver テーブル。この表には、名前、名前、生年月日などの通常の属性が含まれています。このモデルに非常に固有の属性もいくつかあります：

driving_licence_number –これは、政府発行のライセンスに通常見られるID番号または英数字コードです。このIDは実世界で一意であるため、データベースでも一意になります。（一部の地域では、タクシーの運転手は特別な種類の運転免許を持っている必要があります。私たちは彼らがそれを持っていると想定します。）
expiry_date –これは、運転免許証が法的に有効でなくなった日付です。ライセンス履歴は保存されないため、driving_licence_numberを上書きするだけであることに注意してください。およびexpiry_date 必要に応じて新しいデータを使用します。ライセンス履歴を保存する場合は、モデルに別のテーブルを追加する必要があります。
working –これは、ドライバーがシステムにログインするときにオンとオフを切り替えるだけのブール値です。この属性はデフォルトで「はい」（値1）に設定され、ドライバーがシステムへのログインを許可されなくなった場合にのみ「いいえ」に変更されます。

データベースに保存できるドライバー関連の詳細は他にもたくさんあります。ユーザー名とパスワード、各ドライバーが働き始めた日付、各ドライバーの現在の雇用タイプです。これらはこのモデルに特に関連していないため、ここでは詳しく説明しません。ほとんどのシステムで同じであるユーザー管理の下でそれらを分類します。

それでは、cab およびcar_model テーブル。ここに、当社が運営する車のリストを保管します。また、各車両に関する特定の詳細も保存します。これら2つの表の最も重要な属性は次のとおりです。

model_description –これは、特定のタイプの車の会社指定の説明を保持するテキスト属性です。たとえば、タクシー会社は、車が運ぶことができる乗客の数、トランク（ブーツ）スペース、およびその他の事実を保存したい場合があります。
license_plate –ナンバープレート（車両登録プレートまたはナンバープレート）の番号は、企業と政府の両方の目的で、自動車を一意に定義します。もちろん、車を売買する場合はナンバープレート情報の変更が必要になる場合があります。この表では、会社の現在の車両のみを保存します。履歴を保持する必要がある場合は、モデルにもう1つのテーブルを追加できます。
owner_id –この属性は、driver テーブル。ドライバーがキャブを所有している場合にのみ使用するため、オプションです。（これは通常、タクシー協会の場合です。）
active –これは、会社がまだ車を使用しているかどうかを示すブール値です。

最後に、このセクションで最も重要な表であるshift テーブル。このテーブルの背後にある考え方は、実際の労働時間と車とドライバーのスケジュールシフトを保存することです。各シフトには、少なくとも1つのキャブ（cab_id ）と1つのドライバー（driver_id ）。一意のシフトID番号である主キーを除いて、これらはこのテーブルの唯一の必須属性です。

shift_start_time およびshift_end_time 属性は、シフトが開始および終了する実際の瞬間です。多くの場合、これらは事前設定されています。タクシーの関連付けのようにスケジュールがない場合、これらの時間はlogin_timeと同じになります。およびlogout_time それぞれ属性。 login_time およびlogout_time ドライバーが実際にログインする時間です（車内のモバイルデバイスまたはタクシー会社が使用する方法を使用して）。ドライバーがシステムにログインすると、利用可能な乗り物のリストが表示され、ドライバーはそのうちの1つを選択します。もちろん、コーディネーターには、ドライバーが現在機能していることも通知されます。

セクション2：乗り物

このセクションは2つのテーブルのみで構成されていますが、これらはこのモデルの真の核心です。

cab_ride テーブルでは、乗車の可能性ごとに1つのレコードを保存します。何が起こったかに応じて、このレコードを更新します。属性の概要を簡単に見てみましょう：

shift_id –これはshift テーブル;特定の乗車の運転手とタクシーの詳細を提供します。
ride_start_time およびride_end_time –これらは、ドライバーが現在ビジー状態（ライド開始）であり、その後再び利用可能（ライド終了）であることを通知すると更新されます。
address_starting_point およびaddress_destination –これらはライドの開始と終了の場所です。ドライバーはおそらく両方の場所を検索してタブレットまたはGPSでナビゲーションを取得するため、これら2つの属性を更新する可能性があります。
GPS_starting_point およびGPS_destination –これらは上記の開始位置と終了位置のGPS座標です。これらの値は、データがある場合にのみ更新されるため、オプションです。
canceled –これは、乗車がキャンセルされたかどうかを示す単純なはい/いいえの値です。その乗車の記録はすでにテーブルにあるので、乗車をキャンセル済みとしてマークするだけです。
payment_type_id およびprice –これらは、乗車に支払われた金額と顧客が使用した支払い方法に関する情報を提供します。

cab_ride テーブルにはNULL値を含めることができます。これには2つの理由があります：

乗車はキャンセルされます。つまり、これらのフィールドにはデータが入力されません。
最終的にすべてのデータが得られたとしても、レコードが最初に挿入されたときにはすべてのデータが得られるわけではありません。各レコードを数回更新します。少なくとも、ライドの開始時と終了時（またはキャンセル時）に更新します。

このセクションの2番目の表は、cab_ride_status テーブル。ここでは、1回のライドに関連するすべての変更のレコードが追加されます。コーディネーターがシステムに新しい乗り物を入力すると、cab_ride テーブルですが、関連するレコードもcab_ride_status テーブル（対応するステータスとともに）。そのライドに関連する各変更の後に、もう1つのレコードがこのテーブルに追加されます。属性は次のとおりです。

cab_ride_id およびstatus_id –これらは、ride status テーブル（以下で説明します）。どちらも必須です。
status_time –これは、レコードが挿入された実際の時刻を格納します。また、必須です。
cc_agent_id およびshift_id –これらはステータス更新を挿入した従業員への参照です。ディスパッチャーまたはドライバーのいずれかです。おそらく、ディスパッチャは初期ステータスを挿入し、ドライバは次のすべてのステータスを挿入します。
status_details –これは、追加情報を格納するために使用できるテキスト属性です。たとえば、コーディネーターはこの属性を使用して、乗車に関する特別な指示を記録できます。

未分類のテーブル

最後に、分類されていないテーブルを簡単に見ていきましょう。

cc_agent テーブルには、cab_ride およびcab_ride_status テーブル。

status 辞書には、ライドに割り当てることができるすべての可能なステータスのリストが保存されます。一部の値には、「新しい乗り物」が含まれます、「ドライバーに割り当てられた乗車」 、「ライド開始」 、「ライド終了」 、または「乗車がキャンセルされました」 。

Payment_type 別のディクショナリテーブルです。その内容は、payment_type_idを更新するために使用されます cab_ride テーブル。一般的な値は「cash」です。および「クレジットカード」 。

タクシーデータモデルをどのように改善しますか？

この記事で紹介するタクシー/タクシーのデータベースモデルは、最も重要な機能にのみ焦点を当てています。私たちが行うことができる多くの改善があります。ルートは私が考えることができるものにすぎません。

将来的には、ドライバーレスのタクシーができるでしょう。その場合、モデルからドライバーを削除し、充電時間や修理時間などに置き換えます。

コメントして、アイデアを追加してください。