相乗り用のデータモデルの作成

今日、相乗りは世界中の人々によって受け入れられ、促進されています。それは確かに個人の二酸化炭素排出量を削減し、車を借りたり購入したりするよりも費用対効果が高くなる可能性があります。

相乗りも多くの作業を必要とします。適切に設計されたデータベースによって簡単に実行できる組織的な作業です。この記事では、相乗りのウェブサイトで使用できる詳細なデータモデルについて説明します。

データ設計、相乗りに会う

したがって、ライドシェア（別名カープーリング）Webサイトのデータモデルを設計する必要があります。

相乗りはレンタカーとは少し異なります。相乗りでは、車は1人の人が所有し、他の人に乗り物を提供します。共同旅行者は、燃料、道路通行料などの乗車料金を支払います。

プロジェクト要件：

• ウェブサイトはユーザーを許可する必要があります （別名ライドシェアメンバー）名前、電話番号、メールアドレス、運転免許証番号などを使用して登録します。
• メンバーは設定を設定できるようにする必要があります 乗り物や同行者について。
• ライドオーナーと呼ばれるメンバーは、ライドを作成できます 旅行の詳細（出発地と目的地、開始時間、乗客1人あたりの費用など）を入力することで
• 他のメンバーは、目的地の都市への利用可能な乗り物を検索できます 。
• 乗り物を探しているメンバーは、乗り物の所有者に連絡して予約を入れることができます 彼らの席のために。
• ライドの所有者は、予約リクエストを承認または拒否できる必要があります。
• 予約リクエストでライド​​オーナーが行ったアクションに基づいて、空席数を更新する必要があります。
• 乗り物の所有者は、出発地から目的地までの途中の都市である途中の都市にマークを付けることもできます。必要に応じて、乗り物の所有者は途中の都市の人々にも対応できる必要があります。

これらのパラメータを念頭に置いて、相乗りデータモデルの主要なエンティティと関係を特定しましょう。

エンティティと関係の特定

要件全体を見ると、主要なエンティティを簡単に把握できます。それらは：

• メンバー （ライダーの所有者を含む および共同旅行者 ）
• 車
• 設定
• 乗る
• 都市
• 乗車リクエスト

メンバー –このウェブサイトにアクセスするすべての人は、使用する前に登録する必要があります。このプロセスでは、first_nameなどの詳細を提供する必要があります 、last_name 、gender 、email 、およびcontact number 。共同旅行者の場合、これらのアイテムで十分です。おそらく運転しているライドの所有者は、driving_license_numberなどの追加の詳細を入力する必要があります およびdriving_license_valid_from また、含める必要があります。ライセンス情報は、同行者に乗車所有者の運転経験について何かを伝えます。これは、同行者が利用可能な最良の乗り物を選択するのに役立ちます。 member 必要なすべての列があります。

車 –ライドの所有者は、ライドを作成する前に、少なくとも1台の車の詳細を追加する必要があります。それでは、car 、この情報を保存します。 1人のメンバーが複数の車を所有できます。乗車はメンバーと車のペアに依存する可能性があるため、この関係を確立するには別のテーブルが必要です。このテーブルをmember_car 。このテーブルの主キーをride 乗車の詳細を保存するテーブル。また、comfort_levelという1つの列を追加します 、0から5までのスケールで車の快適レベルを保存します。このレベルは、他のメンバーが提供した車の詳細に基づいて、システムによって自動的に計算されます。

設定 –好みは誰にとっても重要です。このウェブサイトでは、メンバーは車とその同行者についての好みを入力できます。 これらの詳細は登録時にオプションのままですが、乗り物を作成する前に入力する必要があります 。乗り物の所有者は、誰もが快適に旅行できるように、同じような好みの人を探すでしょう。乗り物を探している人も同じことをします。

車での移動に関する基本的な設定は次のとおりです。

• 車内での喫煙は許可されていますか？
• ペットの同伴は許可されていますか？
• 乗り物の所有者はどのくらいおしゃべりですか？乗車中はどの程度のチャタリングが許容されますか？ （ここで考えられる応答には、なし、軽いチットチャット、ギャブフェストが含まれます。）
• 乗り物の所有者はどのような種類の音楽が好きですか？
• ライドオーナーはどのくらいの音量を許可していますか？

これらの詳細は登録時にオプションであるため、member_preference これらの詳細を保存します。 2つの追加のテーブルには、音楽の可能なオプションが格納されています（music_preference ）および車内での会話（chitchat_preference ）。

member およびmember_preference テーブルは、メンバーがサインアップ時にシステムにプリファレンスを設定する場合としない場合があり、メンバーごとにプリファレンスのレコードが1つしかないためです。

都市 – 1つのマスターテーブル、city 、ウェブサイトが提供するすべての都市のリストを保存するために必要です。各都市に関連する州および国の情報を含める必要があります。

乗る –メンバーは、自分が走行している車を埋めることで乗り物を作成できます。彼がどの都市から始めているか。彼が向かっている都市。旅の日時。利用可能な座席数。一人当たりの貢献。一人当たりの負担金は、各同行者が乗車費に対して支払わなければならない金額です。乗り物の所有者は、すべてが車に収まるように、同行者に期待している荷物の量についても言及できます。そこで、luggage_size_allowedという1つの列を追加します。 、このアイテムの場合。この列に指定できる値は、軽、中、重です。

ライドリクエスト –メンバーは、ある都市から別の都市への利用可能な乗り物のリストを確認したり、特定の旅行のリクエストを送信したりできます。このようなリクエストの詳細を保存するには、必ず1つのテーブルが必要です。 request 目的に合っています。リクエストは最初に「送信済み」リクエストとして入力され、ライドの所有者だけがそれを承認または拒否することができます。ライドテーブルの空席数は、承認または却下ごとに調整されます。

途中の都市 –ライドシェアリングは、出発地から目的地までまっすぐ進むことだけではありません。途中の都市でも他の人と乗り物を共有することができます。たとえば、男性がシカゴからマイアミに旅行している場合、彼はシカゴからナッシュビルに行きたい人に対応できます。ナッシュビルは彼がルートで通過する都市の1つであるため、途中の都市です。私たちのシステムでは、乗車所有者が目的地に到達するためにたどるルートに基づいて、途中の都市を設定できるようにする必要があります。共同旅行者が希望する場合は、途中のどの都市でも下車できます。彼らの旅費はそれに応じて比例配分されます。

enroute_city この目的のために。ライドの所有者が途中の都市をライドに追加すると、レコードが追加されます。その後、メンバーは途中の都市の1つに旅行するための予約をリクエストできます。したがって、このテーブルの主キーをrequest テーブル。

order_from_source enroute_city 表は、乗り物の所有者が旅のためにたどるコースを示しています。

ウェブサイトのレポート：

このウェブサイトに表示できるさまざまなレポート（データの抜粋）があります。それらのいくつかを説明させてください：

1. 特定の都市から別の都市への乗​​り物 –これは、このWebサイトの要点を示しているため、非常に頻繁に抽出されるレポートの1つです。メンバーのほとんどは、旅行の選択肢や乗り物のシェアを探すためにこのウェブサイトにアクセスします。このレポートを抽出するとき、メンバーは出発地と目的地の都市名を入力する必要があります。 SQLは次のとおりです。

   Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, seats_offered 
   from ride r, member_car mc, car c, member m, member_preference mp
   where r.member_car_id = mc.id and mc.member_id = u.id 
   and mc.car_id = c.id and m.id = mp.member_id
   and source_city_id = (select city_id from city where city_name = ‘CHICAGO’)
   and destination_city_id = (select city_id from city where city_name = ‘MIAMI’)
   and seats_offered > (select count(id) from request req, request_status reqs where req.request_status_id = reqs.id and upper(reqs.description) = ‘APPROVE’ and req.ride_id = r.id);
   

2. 提出/承認された乗車リクエストのリスト –このレポートはライドオーナーに表示されます。誰が乗車リクエストを送信したかが表示され、所有者はこのレポートからのリクエストに対してのみアクションを実行できます。このためのSQLは次のとおりです。

   select first_name || ‘ ‘ || last_name as “Submitter”,  req.created_on as “Submitted on”, rs.description as “Request Status” 
   from member m, request req, request_status rs
   where m.id = req.requester_id and rs.id = req.request_status_id
   and req.ride_id = ;
   

3. 提供された以前と現在の乗り物 –これらのレポートは、乗車所有者が自分のダッシュボードに表示されます。次のSQLを使用して、ライドの所有者が現在提供しているライドのリストを生成できます。

   Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
   where r.member_car_id = mc.id and mc.member_id = m.id 
   and mc.car_id = c.id and u.id = mp.member_id
   and r.travel_start_time >= sysdate
   and m.id = ;
   

   また、このSQLを使用して、以前に提供された乗り物のリストを抽出できます。

   Select m.first_name || ‘ ‘ || m.last_name as “Ride Owner”, c.name as “Car”, c.comfort_level as “Comfort Level”, mp.is_smoking_allowed, mp.is_pet_allowed, r.travel_start_time, r.contribution_per_head, decode(seats_offered,0,’FULL’, seats_offered || ‘ seats available‘) from ride r, member_car mc, car c, member m, member_preference mp
   where r.member_car_id = mc.id and mc.member_id = m.id 
   and mc.car_id = c.id and u.id = mp.member_id
   and r.travel_start_time < sysdate
   and m.id = ;
   

4. 乗車する共同旅行者のリスト –このレポートは、乗り物の所有者を含むすべての共同旅行者が利用できます。それらのすべては、過去または将来の乗り物のすべての共同旅行者のリストを生成できます。

   select first_name || ‘ ‘ || last_name 
   from member m, request req, request_status rs
   where m.id = req.requester_id and rs.id = req.request_status_id
   and rs.description = ‘APPROVED’
   and req.ride_id = 
   UNION
   select first_name || ‘ ‘ || last_name 
   from member m, member_car mc, ride r
   where m.id = mc.member_id and mc.id = r.member_car_id 
   and r.id = ;
   

最終データモデル

改善についてはどうですか？

このモデルをさらに改善できますか？はい、できます！まだ注意が必要な領域がいくつかあります。

定期的な乗車リクエストを作成したい場合はどうなりますか？ドライバーが毎週末にある都市から別の都市に移動し、常にこの乗り物を喜んで共有するとします。定期的なリクエストの方が便利です。

乗り物を提供している未知の男にどのように頼ることができますか？乗車をリクエストする前に、人々が他の人を評価するのを助ける何らかの方法があるはずです。実行可能なメカニズムの1つは、乗り物の所有者と共同旅行者に関するフィードバックを公開して共有することです。これらの詳細は、他の人が見知らぬ人との乗車をより自信を持って予約するのに確実に役立ちます。これを実現するには、データモデルにどのような変更が必要ですか？

このモデルに関するご意見をお気軽に共有してください。