以前のブログ投稿で作成したデータモデルにさらに変更を加えましょう。たとえば、インストラクターと車両をレッスンに割り当てたり、顧客に請求したり、追跡したりするための自動化されたアプローチがあります。
まず、実際に行われる前に、インストラクターと車両をレッスンに割り当てるために、アプリケーション側でロジックを構築する必要があります。ここで確認する主なことは、可用性です。つまり、インストラクターまたは車両は、両方がレッスンのスケジュールされた時間に利用可能である場合にのみ、レッスンに割り当てることができます。
インストラクターと車両の占有率をそれぞれ追跡するために、2つの別々のテーブルを作成する必要があります。なぜ私が空室状況ではなく占有率を追跡するつもりなのか疑問に思われるかもしれません。答えは、空き状況ではなく占有状況を追跡する場合、インストラクターによって計画された休暇や車両の定期サービスのためにリソースが利用できないことを保存するために、テーブルを追加する必要がないということです。計画的に利用できない場合は、それに応じてレコードが占有テーブルに挿入されます。
ここでは、インストラクターと車両は、学校が定義する営業日の午前8時から午後6時までの営業時間内にのみ利用可能であると想定しています。したがって、staff_occupancy テーブル。
テーブルstaff_occupancyの構造 は次のとおりです：
必要に応じて、いくつかのバリエーションを入れることができます。たとえば、インストラクターの後続の2つのレッスンの間には少なくとも15分のギャップが必要です。
テーブルvehicle_occupancy は次のとおりです：
インストラクターと車両の割り当ては、reservation テーブル。すでに2つの列staff_idを追加しました およびvehicle_id 、このテーブルに。これらの割り当ては、明らかに、可用性に基づいて行われます。
さらに、reservation_idを保持します staff_occupancyで およびvehicle_occupancy テーブル、レッスンのキャンセルの場合に、スタッフと車両の関連する占有を簡単に解放することができます。ただし、これらの列は両方とも nullableとして保持します。 インストラクターと車両の占有は必ずしも予約のためではないので。インストラクターが休暇をとった場合はどうなりますか？または、車両の1台が1日サービスセンターに入りますか？
このようなシナリオでソフト削除を許可するために、is_activeという列を1つ追加します。 これらの表の両方で。
請求
請求要件については、1つのテーブル、つまりinvoice 、customer_idを含む請求の詳細を保持する およびreservation_id 。ここでは、請求は顧客に対して行われますが、顧客のために実施されたレッスンに基づいています。したがって、reservation_idが必要です 請求書テーブルの列も同様に表示されるため、任意の時点で、顧客の予約に基づいて詳細な請求に関するレポートを取得できます。また、1つの列、つまりinvoice_status_idを作成します。 、請求書のステータスを保存するテーブルに。
データベースモデル
Vertabeloで設計された更新されたデータベース構造は次のとおりです。
結論
これまでに、自動車教習所の予約システムのデータモデリングは、運転を学ぶのと同じくらい面白くて魅力的だと信じ始めたに違いありませんか？
記事に関するご質問やご提案をお気軽に投稿してください。私はそれらに答えて、あなたの提案を私の次の記事に取り入れることをとてもうれしく思います。