自動車教習所の予約システムのデータモデルを設計する必要があります。主題分野は非常に単純に見えますが、それでも複雑さが関係しています。クライアントからのすべてのリクエストを追跡し、レッスン中に消費されたリソース（車両、時間、インストラクター）を追跡する必要があります。
はじめに
ドメイン駆動アプローチを使用するのが好きです データモデルを設計するため。それは私にテクノロジーへの執着を脇に置き、主に関連するエンティティとそれらの間の関係を中心に展開するサブジェクトエリアのモデリングに集中させます。
一言で言えば要件
まず、要件を平易な英語で書き留めておきましょう。
顧客を許可するために自動車教習所のデータモデルが必要です 予約を行う レッスンの場合 オンライン。自動車教習所には複数のインストラクターがいる場合があります および複数の車両 。インストラクターは予約時にレッスンに割り当てられます。システムは、顧客が予定日の前であればいつでも予約をキャンセルできるようにする必要があります。レッスンが行われる場合は、レッスンに割り当てられた車両も記録する必要があります。
関連するエンティティと関係
主題について考えるとき、最初に頭に浮かぶのは、「顧客」です。 、「インストラクター」 、「運転レッスン」 、「予約リクエスト」 および「車両」 。このモデルの最初のテーブルから始めましょう。それはcustomer 。得意先のマスタデータを保存することです。インストラクターの詳細を格納するために別のテーブルが必要になる可能性がありますが、インストラクターの名前でテーブルを作成する代わりに、staff スタッフの詳細については、役職として「インストラクター」を保持してください。これにより、私のデータモデルは、自動車教習所の管理業務や法務業務など、他のサービス分野にも対応できるように拡張可能になります。
「運転コース」を検討します サービスの1つとして、service 。サービス、「運転コース」 この場合、複数のレッスンを行うことができます。この要件を処理するには、確かに別のマスターテーブル、つまりlesson 、および1つの関係テーブル、つまりservice_lesson 、これらのマスターエンティティの両方の間の多対多の関係を管理するために、つまり、1つのサービスに複数のレッスンを確実に含めることができますが、一方で、1つのレッスンを複数のサービスの一部にすることもできます。
予約リクエストを送信すると、詳細と、希望するサービスの種類、車両の選択、開始日などの予備的な設定を入力するように求められます。顧客の詳細は顧客テーブルに保存されます。その後、request テーブル、およびすべての設定は、同じテーブルのリクエストに対して保存されます。各リクエストには、「送信」、「処理中」、「キャンセル」、「完了」などの特定のステータスが関連付けられています。 request_status 。
リクエストの送信時に、車両、つまり車両のタイプを優先します。ただし、実際には、車両はそれが行われるときにレッスンに割り当てられます。したがって、vehicle_type_idを保持します request 今のところテーブル。
リクエストが処理されると、サービスリクエストのレッスンごとに予約が行われます。さらに、インストラクターと車両は、インストラクターの空き状況と顧客の車両の好みに基づいて、各レッスンに割り当てられます。レッスンは、ステータスが「オープン」の将来の日付にスケジュールされています。これらの詳細はすべて、reservation 。すべてのマスターテーブルとは異なる色ですべてのトランザクションテーブルを強調表示しました。
1つのマスターテーブル、reservation_status は、「オープン」、「処理中」、「キャンセル」、「完了」などの予約ステータスのすべての可能な値を格納するために作成されます。
このモデルを使用すると、顧客は個々のレッスンだけでなく、サービスリクエスト全体をキャンセルできます。 顧客がサービスリクエストをキャンセルすると、顧客に予定されている残りのすべてのレッスンが予約テーブルでキャンセルされます。
これらすべてのテーブルの列レベルの詳細については、Vertabeloを使用して作成したデータモデルを参照してください。列の作成に関するいくつかのポイント：
-
is_activeという名前のフラグ列 レコードのソフト削除を有効にするために、すべてのマスターテーブルに追加されます。したがって、たとえば、インストラクターが学校を辞めた場合は、フラグを「N」に切り替えて、彼の記録を非アクティブにします。 -
created_dateなどの特定の列 、created_by、last_modified_dateおよびlast_modified_byレコードの変更の監査証跡を有効にするために、すべてのトランザクションテーブルに追加されます。 Vertabeloで作成されたデータモデルでは、トランザクションテーブルが青色で強調表示されています。 -
address_idが何であるか疑問に思われるかもしれません。staffテーブルはです。この列を意図的にstaffデータモデルを拡張して、インストラクターの場所に基づいてインストラクターをリクエストに割り当てる自動化されたプロセスをサポートできるようにします。たとえば、ニューヨーク市でホワイトプレーンズからのリクエストが届いたとします。私のシステムでは、最初に同じまたは最も近い場所で利用可能なインストラクターを探す必要があります。私のシステムでは、リクエスターの場所から約50マイル離れたマンハッタンに滞在するインストラクターを割り当てることはできません。
このモデルの顕著な特徴
- このモデルでは、顧客は開始日と車両の好みに応じて予約リクエストを送信できます。
- コースの1つ以上のレッスン、またはコース全体をキャンセルできます。
- このモデルは、各レッスンのインストラクターと車両の詳細をキャプチャします。
- このモデルは、自動車教習所が提供するすべての可能なサービスを処理するために拡張可能です。
- トレーニングコースを設計し、レッスンを効果的に計画することができます。
データベースモデル
これが私たちの予約システムのデータベース設計です。モデルはVertabeloforOracleデータベースで作成されましたが、同じ設計を他のデータベースエンジンに大幅な変更なしで実装できます。
結論
この記事では取り上げなかった特定の分野があります。たとえば、次のとおりです。
- 車両とインストラクターをレッスンに割り当てるための自動化されたアプローチを構築できますか？
- 顧客への請求はどうですか？顧客がコース全体ではなく、コースの2、3レッスンの料金を支払いたくない場合はどうなりますか？これらのレッスンを彼が利用できるようにすることはできますか？
既存のモデルはそのような機能をサポートしていますか？答えはいいえだ。これらの主題分野については、次の記事で取り上げます。