自動車修理店のデータモデル

自動車/自動車修理店を経営することは本当に複雑なビジネスです。一部の顧客が車で来て、何時間も待たせたくない場合は、予約をする必要があります。また、従業員の整理、修理、資材の追跡、顧客への請求などが必要になります。ITソリューションと、もちろん、バックグラウンドでのデータモデルが必ず必要になります。今日は、そのようなモデルの1つについて説明します。

アイデア

このビジネスモデルは非常に複雑であることはすでに述べました。したがって、私はすべてをカバーしようとはしません。追跡資料とスペアパーツを意図的に省略し、モデルの一部のパーツも簡略化しました。その理由は非常に単純です。私が本当にすべてを含めたとしたら、モデルは単純に大きすぎて妥当なサイズの記事にはなりません。それでは、始めましょう。

データモデル

モデルは5つのサブジェクトエリアで構成されています：

修理店と従業員
顧客と連絡先
車両
サービスとオファー および
訪問

これらの5つの主題分野のそれぞれについて、記載されている順序で説明します。

セクション1：修理店と従業員

最初の主題分野は、修理店と従業員です。サブジェクトエリア。顧客にオファーをする前に、私たちが自由に使えるものを知る必要があることは明らかです。

都市 辞書は、修理店がある、または顧客の出身地であるすべての異なる都市を格納するために使用されます。各都市は、 postal_codeのペアによって一意に定義されます。 – city_name 。その都市に複数の郵便番号がある場合でも、各都市に1つのエントリのみを設定することを決定できます。その場合、その都市の「主要な」郵便番号のみを使用します。それでも、必要に応じて、同じ都市と異なる郵便番号に対して複数のエントリを設定するオプションがあります。

repair_shop テーブルは、すべての修理店のリストを保存する場所です。ある時点で複数のオペレーションを行うことが期待できます。各ショップは、その shop_nameによって一意に定義されますおよびそれが属する都市のID（ city_id ）。ショップの住所と追加の詳細も保存しますある場合はテキスト形式で。

 
 位置  辞書は、一意の position_namesを格納するために使用されます それは私たちの従業員に割り当てることができます。ほとんどのポジションはコアビジネスに関連するものですが、コアビジネスの一部ではない（技術的な役割/ポジション）だけでなく、不可欠なもの（管理、営業など）もあります。
 
 すべての従業員のリストは、従業員に保存されます  テーブル。従業員ごとに、次の情報を保存します：
    first_name  ＆ last_name  –従業員の名前と名前。
   employee_start_date  ＆ employee_end_date  –会社での従業員の開始日と終了日。終了日には、定義できるまでNULL値を含める必要があります。
   position_id  –会社の現在の位置への参照。
   city_id  –従業員が現在住んでいる都市への参照。
   is_active  –従業員が現在アクティブであるかどうかを示すフラグ。
 
 
 このサブジェクトエリアの最後のテーブルは、スケジュールです。  テーブル。この表には、すべての従業員の正確なスケジュールが毎日表示されます。同じ日に同じ従業員の複数の間隔を保存するオプションもあります。これを実現するために、次の属性を使用します。
    repair_shop_id  –関連する修理店への参照。
   employee_id  –関連する従業員への参照。
   position_id  –関連するポジションへの参照。定義された期間中に従業員が持つことになります。ほとんどの場合、これが彼の現在の位置になりますが、ここで他の位置を割り当てる柔軟性があります。
   schedule_date  –このエントリが関連する日付。
   time_from  ＆ time_to  –このペアは、このエントリが関連する期間を定義します。
 計画 –これが計画されたエントリであるかどうかを示すフラグ。アドホックに挿入した場合のみ、エントリーは計画されません。
 実際 –このフラグは、このエントリが実現されたかどうかを示します。ほとんどの場合、planとactualの両方のフラグがTrueに設定されることに注意してください。これは、私たちがその計画を計画し、実際に実現したことを示しています。
   insert_ts  –このレコードがテーブルに挿入された瞬間を示すタイムスタンプ。
 
 
  repair_shop_idの組み合わせ - employee_id  - schedule_date  - time_from  このテーブルのUNIQUE/代替キーを形成します。新しいレコードを挿入する前に、新しい間隔 time_fromも確認する必要があります –  time_to  同じ従業員と日付の既存の間隔と重複しません。
 セクション2：顧客と連絡先
 
 これで、モデルの顧客関連の部分に移動する準備が整いました。
   
 
   customer に、以前に協力した、または連絡したすべての顧客を保存します  テーブル。お客様ごとに、以下を保存します：
    first_name  ＆ last_name  –お客様が個人の場合は、お客様の姓名。
   company_name  –会社名。場合によっては、顧客は会社であり、個人ではありません。
 アドレス –顧客の住所。
 モバイル –お客様の携帯電話番号。
 メール –お客様のメール
 詳細 –追加の顧客の詳細（ある場合）はすべてテキスト形式です。
   insert_ts  –このレコードがテーブルに挿入された瞬間を示すタイムスタンプ。
 
 
 このテーブルのほとんどの属性は、一部と一部（ first_name ）がない可能性があるため、null許容です。 ＆ last_name  対company_name ）他の人を除外します。
 
 各顧客とのすべての連絡を追跡する必要があります。そのために、2つのテーブルを使用します。 1つ目は、  contact_type   表は、UNIQUE  type_nameのみを含む単純な辞書です。 値。
 
 実際の連絡先データは連絡先に保存されます  テーブル。その連絡先のタイプ（ contact_type_id ）への参照を保存します ）、連絡した顧客（ customer_id  ）、その連絡を行った従業員（ schedule_id  ）、連絡先の詳細とこのレコードがテーブルに挿入された時刻も保存します（ insert_ts  。
 セクション3：車両
 
 リソースと顧客を知った後、使用する車両を保管する必要があります。データの追跡と内部レポートの作成に加えて、ほとんどの国では、規制当局、保険会社、警察のレポートも作成する必要があります。
   
 
 まず、車両のモデルを定義します。これを実現するために3つのテーブルを使用します。   make   辞書、一意の make_namesを一覧表示します すべての自動車/車両メーカー/メーカー向け。さらに、車両の種類を知る必要があるため、 type_nameという1つの一意の値属性のみを持つ辞書をもう1つ使用します。 。使用される3つの辞書はmodel   辞書。これには、私たちのドアを通り抜けたすべてのモデルのリストが含まれています。モデルごとに、 model_nameの一意の組み合わせを定義します –  make_id  –  vechicle_type_id  。 
 
 この主題分野の説明は、車両で終了します。  テーブル。これは、このサブジェクト領域で「実際の」データを含む唯一のテーブルです。このテーブルを使用して、次の詳細を保存します。
    vin  –この車両を一意に定義する車両識別番号。
   license_plate  –現在のナンバープレート番号。
   customer_id  –この車両が属する顧客への参照。車両が所有者を変更した場合は、新しいレコードとして挿入しますが、これはシリアル番号に基づいて同じ車両であることがわかります。
   model_id  –モデルディクショナリへの参照。
  manufactured_year  ＆manufactured_month  –この車両が製造された年と月を示します。
 詳細 –テキスト形式のすべての追加詳細。
   insert_ts  –このレコードがテーブルに挿入された瞬間を示すタイムスタンプ。
 
 セクション4：サービスとオファー
 
 次の大きな一歩を踏み出す準備ができています。 （潜在的な）顧客に何を提供するかを定義する必要があります。これらは、単一のタスクまたは一連のタスク（サービス）の場合があります。
   
 
 すべてのサービスのリストは、  service_catalogに保存されます  辞書。各サービスはいくつかのタスクで構成され、 service_nameによって一意に定義されます。 。名前のほかに、説明がある場合は、 service_discountの割合も保存します。 およびis_active 国旗。サービス割引は、このサービスに含まれるすべてのタスクに使用されます。
 
 次に、タスクを定義します。タスクは私たちのサービスの一部です。これらは、スタンドアロンで実行できる基本的なアクションです。各タスクは、  task_catalogのこれらの値によって定義されます  テーブル：
    task_name  ＆ service_catalog_id  –このタスクとそれが属するサービスを説明するために使用する名前。この属性ペアは、テーブルの一意のキーを形成します。
 説明 –このタスクを説明するために使用される、追加のテキストによる説明（ある場合）。
   ref_interval  –このタスクの間隔を測定するかどうかを示すフラグ。
   ref_interval_min  ＆ ref_interval_max  –参照範囲の最小および最大境界。
 説明 –このタスクにテキストコメントを追加する必要があるかどうかを示すフラグ。
   task_price  –このタスクの現在の価格（サービス割引なし）。
   is_active  –タスクが現在アクティブであるかどうかを示すフラグ（オファー内）。
 
 
 お客様との接触後、お客様にオファーを行います。オファーは、すべてのタスクまたは一連のタスクを含む完全なサービスである可能性があります。すべてのオファーはオファーに保存されます  テーブル。オファーごとに、以下を保存します：
    customer_id  –関連する顧客のID。
   contact_id  –関連する連絡先がある場合はそのID。これは、以前の連絡の結果として提供されたオファーの数を判断するための重要な情報になる可能性があります。
   offer_description  –このオファーの追加のテキストによる説明。
   service_catalog_id  –お客様に提供したサービスのID。完全なサービスを提供していない場合、このIDはNULLになる可能性がありますが、サービスの一部ではない1つ以上のタスクがあります。
   service_discount  –オファーが作成された時点でのサービス割引。オファーがサービスに関連していない場合、この値にはNULLが含まれます。
   offer_price  –そのオファーの最終価格。これは、すべてのタスクの合計からサービス割引を差し引いたものとして計算できます。
   insert_ts  –このレコードがテーブルに挿入された瞬間を示すタイムスタンプ。
 
 
 このサブジェクト領域の最後のテーブルは、  offer_taskです。  テーブル。オファーごとに、完全なサービスを提供したかどうかに関係なく、すべてのタスクのセットを保存します。次の詳細を保存する必要があります：
    offer_id  –関連するオファーのID。
   task_catalog_id  –関連するタスクのID。  offer_idと一緒に 、このテーブルの一意の/代替キーを形成します
   task_price  –このレコードが挿入された時点でのそのタスクの現在の価格。
   insert_ts  -このレコードがテーブルに挿入された瞬間を示すタイムスタンプ。
 
 セクション5：訪問
 
 モデルの最後のサブジェクト領域は、修理店への実際の顧客の訪問を保存するために使用されます。複雑に見えますが、ここには2つの新しいテーブルしかありません。  visit   およびvisit_task   。
   
 
 顧客が私たちの申し出に同意するか、またはちょうど私たちの店に来るとき、私たちはそれを訪問として扱います  。そのようなイベントごとに、次の詳細を保存します：
    repair_shop_id  –関連する修理店への参照。
   customer_id  –今回の訪問に関連する顧客への言及。
   Vehicle_id  –今回の訪問に関連する車両への参照。
   visit_start_date  –訪問開始日（予定）。
   visit_start_time  –訪問開始時間（予定）。
   visit_end_date  –訪問開始日（実際）。この値は、訪問が実際に終了したときに設定されます。
   visit_end_time  –訪問開始時間（実際）。この値は、訪問が実際に終了したときに設定されます。
   license_plate  –訪問が発生した時点でのナンバープレート番号。ナンバープレートは時間の経過とともに変化することに注意してください。
   offer_id  –関連するオファーのID（ある場合）。
   service_catalog_id  –関連するサービスのID（ある場合）。
   service_discount  –このレコードが追加された時点で、完全なサービスを提供する場合の割引率。
   visit_price  –顧客がその訪問に対して支払う必要のある合計金額。
   invoice_created  –請求書が生成されたときのタイムスタンプ。
   invoice_due  –請求書の期日が到来したときのタイムスタンプ。
   invoice_charged  –請求書が請求されたときのタイムスタンプ。
   insert_ts  –このレコードがテーブルに挿入された瞬間を示すタイムスタンプ。
 
 
 モデルの最後のテーブルはvisit_task です  テーブル。これは、実際にその訪問の一部であったすべてのタスクを保存する場所です。ここのレコードごとに、次の値を保存します。
    visit_id  –その訪問への参照。
   task_catalog_id  –関連するタスクへの参照
   value_measured  –タスクで測定が必要な場合は、このタスク中に測定された値。
   task_description  –タスクに説明が必要な場合は、そのタスクに関連する説明。
 パス –このタスクが予想された間隔内にあったかどうかを示すフラグ。
   task_price  –この表に挿入されている現時点でのそのタスクの実際の価格。
   insert_ts  –このレコードがテーブルに挿入された瞬間を示すタイムスタンプ。
 
 
 このモデルはかなり単純化されていますが、その周りに完全なモデルを構築するために必要なすべての要素が含まれています。改善が必要な部品は間違いなく使用材料と支払い処理です。このモデルにさらに何かを追加しますか？