ペットケアデータモデル

所有者 表には、過去、現在、および潜在的なすべてのクライアントのリストが保存されます。個人的には、「飼い主」という言葉は好きではありません。ペットと一緒に暮らすと、ペットは家族の一員のようになるからです。ただし、データモデルで使用しても問題ありません。そのため、所有者ごとに、 first_nameを保存します およびlast_name 、連絡先の詳細（私たちが知っているので、すべてを知っているとは限りません）および notesの追加の詳細 属性。

pet_ownerを使用して飼い主とペットを関連付けます テーブル。 1人の飼い主が多くのペットを飼うことができ、1匹のペットが2匹の飼い主を持つことができるため、ここに多対多の関係を挿入する必要があります。レコードごとに、一意の pet_idを保存します – owner_id ペア。

このサブジェクトエリアの3番目で最後のテーブルは種です 辞書。主キー属性idに加えて 、UNIQUE species_nameのみが含まれています 価値。この辞書を使用して、ビジネスに必要なレベルで種の情報を保存します。 「猫」、「犬」、「馬」、「鳥」などの単純な値のセットを使用できます。または、「猫–メインクーン」、「猫–マンチカン」など、よりわかりやすい値を使用することもできます。より複雑な構造を採用することもできます。つまり、種用に1つのテーブルを使用し、品種用に別のテーブルを使用することもできますが、このアプローチは考えられません。モデルに新しいものをもたらします。

セクション2：施設とサービス

このモデルで2番目に重要なことは、提供するサービスです。ペットの飼い主に何を提供しても、施設も必要です。これは、ペットホテルなどの1つの場所でも、ペットを乗せたり降ろしたりする場所（犬の散歩代行者が使用する場所など）でもかまいません。この情報は施設とサービスに保存されます サブジェクトエリア。

サービスから始めましょう テーブル。これは、クライアントに提供するすべてのサービスのリストを保存するために使用する辞書です。サービスごとに、次のものが必要です。

• service_name –サービスを一意に定義する名前。
• has_limit –このサービスに制限があるかどうかを示す値（ペットホテルの「ベッド」の数など）。
• unit_id –そのサービスを測定するために使用する単位。それは、私たちが提供するサービスの種類と、それが時間または材料（あるいはその両方）を必要とするかどうかによって異なります。ほとんどの場合、時間について心配します。たとえば、犬がペットホテルに滞在する場合、使用される単位は「日」である必要があります。一方、犬の散歩をしている場合、単位は「時間」または「分」である必要があります。時間単位に加えて、他の手段を使用することもできます。犬に「提供」されるおやつの数を定義したい場合。
• cost_per_unit –そのサービスのユニットあたりの現在のコスト。

ユニット 辞書は、UNIQUE unit_nameのリストを格納するために使用されます 値。このディクショナリの値は、 serviceでのみ参照されます 表ですが、計画段階や、提供されたサービスの料金をクライアントに請求する際に非常に重要です。

サービスごとに、受け入れられるすべての種を定義する必要もあります。たとえば、ペットホテルサービスは猫のみに提供し、犬には提供しない場合があります。これは、犬の散歩や手入れを提供しているという事実に関係なく当てはまる可能性があります。すべての一意のservice_idを保存します – speices_id available_forのペア テーブル。

すべてのサービスとその詳細を説明した後、次に、これらのサービスを提供する施設（場所）について説明します。

複数の施設を運営し、複数のサービスを提供する可能性は十分にあります。そのため、すべての施設とそれに関連する詳細を保存する必要があります。 施設を使用します 追跡するテーブル：

• facility_name –その施設を一意に示すために内部で使用する名前。
• アドレス 、 phone 、 email およびcontact_person –場所と連絡先情報。これらはほとんど自明です。

施設ごとに、提供するサービスを保存します。猫専用の施設と犬専用の施設があります。または、一方の施設に獣医技術者を配置し、もう一方の施設には配置しないこともできます。いずれの場合も、各施設で提供できるすべてのサービスを保存する必要があります。 提供 テーブルには、UNIQUE facility_idを保存します - service_id ペア。そのserviceの場合 。has_limit 参照されるサービスがtrueの場合、 service_limitも定義する必要があります その施設についてもcurrently_used 量。その値は、その施設でもう1匹のペットにサービスを提供し始めるたびに（たとえば、ペットホテルでもう1つの場所を利用する場合）、またはペットへの提供を停止するたびに（たとえば、ホテルで利用可能なペット用ベッドの数）、再計算する必要があります。 1つ増えました。

セクション3：ケース

ケース サブジェクトエリアは、訪問またはセッションに関連するすべてのデータを説明および保存する場所です（つまり、1回の訪問は、犬のホテルでの1回の滞在、1回のグルーミング、1回の散歩など）

ケース テーブルには、セッション、通話、訪問に関連するペットや施設が保管されています。ここでは訪問のみを保存できない場合があるため、テーブルの名前として「ケース」を使用することにしました。通話やその他の連絡先を保存したい場合があります。いずれの場合も、以下を保存します：

• facility_id –関連施設のID。それは、ペットが（ホテルに）滞在した場所、またはこのケースに関連する電話を受けた施設である可能性があります。
• pet_id –関係するペットのID。
• start_time –そのケースが開始されたときの実際のタイムスタンプ。
• end_time –そのケースが終了したときの実際のタイムスタンプ。ケースがクローズされるまでNULLになります。
• メモ –そのケースに関連するテキスト形式の追加のメモ。
• クローズ –このケースがクローズされているかどうか。 end_time の場合、「True」に設定されます 設定されています。

facility_idの組み合わせを使用します – pet_id – start_time このテーブルのUNIQUEキーとして。

各ケースには、1つ以上のステータスが割り当てられます。割り当てられた最初のステータスは、ケースがいつ開始されたかを示すことが期待できます。その後、ケースが解決（クローズ）されるまで、必要に応じて新しいステータスを割り当てます。

ここでの最初の辞書はstatus_category です 辞書。 UNIQUE status_category_nameのリストが含まれています 値。これらは、タイプ別のグループステータスです。 「身体的状態」、「食欲」、または「一般的状態」。

可能なすべてのステータスは、 statusに保存されます 辞書。ステータスごとに、その status_nameを保存します 、それが属するステータスカテゴリのID、および is_closing_status 価値。 is_closing_statusの場合 値が「True」の場合、このステータスを割り当てると、ケースはクローズとしてマークされます。 status_name – status_category_id ペアは、このテーブルのUNIQUEキーを形成します。

case_status テーブルには、実際にケースに割り当てられたすべてのステータスが保存されます。この表の各レコードについて、 caseへの参照を保存します およびステータス テーブル、追加の notes 、および insert_time そのステータスの。たとえば、ペットの現在の体調や食欲を、ペットが施設に入ったときのステータスとして保存することができます。これらのステータスは、状態の変化に気付いた場合に変更されます。一方、各ケースに関するステータスも保存します（例：「犬が歩いた」）。そのステータスに関する追加の詳細は、 notesに記載します。 属性。これらのステータスは、a）その時点でのペットの現在のステータス、またはb）セッションまたは訪問中に実行されたアクションに関連しているため、「クローズ」ステータスにはなりません。 「閉店」ステータスの例としては、ペットホテルの「犬のチェックアウト」があります。

このセクションの最後の表は、注です。 テーブル。このテーブルを使用して、新しいステータスを挿入する必要がない場合に関連するすべてのメモを保存します。レコードごとに、 note_textを保存します 、関連するケースのID、および insert_time そのメモが作成されたとき。

セクション4：計画および提供

最後の主題分野は、計画および提供です。 サブジェクトエリア。このサブジェクトエリアの3つのテーブルには、提供する予定のサービス、実際に提供されたサービス、およびケースに関連するすべての請求書に関するデータが格納されています。

service_planned 表には、クライアントに提案した、またはクライアントが予約したすべてのサービスのリストが含まれています。各レコードには次のものが含まれます：

• case_id –関連するケースのID。
• service_id –関連サービスのID。
• planned_start_time ＆ planned_end_time –このサービスを開始および終了する予定の場合。開始時刻を定義する必要がありますが、終了時刻はNULLにすることができます。
• planned_units –計画されているサービスユニットの数。例：ペットホテルで3日間。
• cost_per_unit –その時点でのユニットあたりのコスト。 service に値が保存されるため、この値を保存することが重要です。 。cost_per_unit 予約が行われた時間と実行された時間の間で変更される可能性があります。
• planned_price –そのサービスの見積もり価格。これはplanned_unitsと同じである必要があります * cost_per_unit 。
• メモ –計画されたサービスに関連する追加のメモ。

service_provided テーブルの構造はservice_plannedとほぼ同じです。 テーブル。唯一の違いは、 units およびprice_charged 属性にはNULL値を含めることができます。これは、サービスの提供を開始したとき（たとえば、ペットがペットホテルに入ったとき）にこのテーブルにレコードを挿入でき、サービスの提供を停止したとき（たとえば、所有者がペットの家）。

モデルの最後のテーブルは請求書です テーブル。すべてのケースに対して生成されたすべての請求書のリストが保持されます。請求書ごとに、以下を保存します：

• invoice_code –請求書ごとに生成された内部UNIQUE番号。
• case_id –関連するケースのID。
• time_generated –請求書が生成されたとき。
• invoice_amount –クライアントに請求する元の金額。この金額は、 price_chargedのすべての値の合計と同じである必要があります service_providedの場合 。
• 割引 –クライアントに与えられる割引（たとえば、クーポン、ポイントカードなどのため。理由は実際には重要ではありません。）
• time_charged –クライアントが実際にその請求書に対して請求されたとき。この属性には、支払いが行われるまでNULL値が含まれます。
• amount_charged –その請求書に対してクライアントに請求された実際の金額。
• メモ –その請求書に関連する追加のメモ。

何を追加しますか？

今日は、ペットケアビジネスの可能なデータモデルについて話しました。このモデルは基本的な機能をカバーしていますが、改善の余地があります。コメントセクションで私たちとあなたの提案を共有してください。ありがとう！