子供たちのパーティーを開催するのは簡単な仕事ではありません。すべてが完璧に計画され、提供されなければなりません。そうでなければ、混乱が起こります。すべての面倒を見て適切に行うのは、大人、より具体的にはパーティープランナー次第です。
データベース内のすべてを整理するよりも、これを行うためのより良い方法はありますか？そうは思いません！
子供たちのパーティーは大きく異なります。招待状、食べ物（スナック、飲み物、ケーキ）だけを含む誕生日パーティーのように、子供たちを楽しませるためのピエロや魔術師など、シンプルなものもあります。他の当事者ははるかに複雑です。彼らは町からの旅行、宿泊施設の睡眠、および他の多くの活動を必要とするかもしれません。パーティーが複雑になればなるほど、間違いの余地は少なくなります。 10分遅れるピエロは大したことではありませんが、退屈な子供たちと一緒に2時間遅れるバスを待つ人は誰もいません！
パーティープランナーが整理された状態を維持するためにデータモデルで何ができるか見てみましょう。
データモデルには何が必要ですか？
パーティープランニング事業を営んでいるとしましょう。お客様に提供するサービスのリストを用意します。これらのサービスは私たちが提供することも、パートナーを利用することもできます（たとえば、ピエロを雇う）。
これらのサービスを組み合わせて、パーティーパッケージとしてお客様に提供しています。各パッケージには、開始点と終了点、またはスケジュールがあります。これには、パーティー自体だけでなく、パーティーの設定とその後の片付けも含まれます。複数の場所がある場合もあります（たとえば、パーティーはレストランでピザから始まり、その後、水泳のためにビーチに移動します）。
また、活動を従業員と関連付け、当事者の進捗状況を追跡し、サービスの料金を請求する必要があります。これがどのように行われるか見てみましょう。
子供たちのパーティーのデータモデル
私たちの子供たちのパーティーデータモデルは、4つの主題分野で構成されています。
国と都市パートナーとサービス従業員と役割パーティー
各サブジェクトエリアは、リストされているのと同じ順序で表示されます。
セクション1：国と都市
このサブジェクトエリアには、2つのテーブルのみが含まれています。これらはこのモデルに固有のものではありませんが、他の分野で使用します。
私たちは複数の都市で、そしておそらくいくつかの国でさえも活動することを期待することができます。したがって、さまざまな都市を参照する必要があります。これは、パーティーがどこにあるか、また各場所でどのようなサービスを提供しているかを追跡するのに役立ちます。
国 辞書には、UNIQUE country_nameのみが含まれています 価値。 都市ごとに 、 postal_codeの一意の組み合わせを保存します – city_name – country_id 。
セクション2：パートナーとサービス
次に、クライアントに提供するサービスについて詳しく説明します。
可能なすべてのサービスのリストは、 serviceに保存されます 辞書。 UNIQUE service_nameのみが含まれています 属性。
このデータモデルでは、すべてのサービスがパートナーによって提供されます。当社が実際にサービスを提供している場合でも、パートナーとして扱います。 サービス（そして私たちはパートナーです）。パートナー辞書には、私たちを含む、私たちが協力するすべてのパートナーが保存されます。パートナーごとに、一意のpartner_nameを保存します 。 詳細 属性は、非構造化または構造化形式を使用して、そのパートナーに関連する追加の詳細を格納します（たとえば、事前定義された区切り文字で区切られた名前と値のペアを使用します）。
提供 表は、このセクションの最後の最も重要な表です。レコードごとに、以下を保存します：
-
partner_id–パートナーサービスを提供します。 -
service_id–サービスこのパートナーが提供します。 -
city_id–cityを参照しますこのサービスがそのパートナーによって提供される場合。 -
date_from–パートナーがそのサービスの提供を開始した日付。 -
date_to–パートナーがそのサービスの提供を停止した日付。そのサービスとパートナーの関係がまだ継続している場合、この値はNULLになる可能性があります。 詳細 –サービスの説明、価格など、そのサービスに関連するすべての追加の詳細。すべての詳細は、キーと値のペアを使用して、構造化されたテキスト形式になると予想されます。
partner_idの組み合わせ – service_id – city_id – date_fromは、このテーブルのUNIQUEキーを形成します。新しいレコードを入力するときは、既存のレコードと重複していないことを確認する必要があります。
セクション3：従業員と役割
モデルの中心的で最も重要な部分に移る前に、従業員とその役割に関連する表を確認する必要があります。
このサブジェクトエリアの中央のテーブルは、従業員です。 テーブル。従業員ごとに、 first_nameを保存します 、 last_name 、 user_name およびpassword 。これらの最後の2つの属性を使用して、アプリケーションにアクセスします。
可能なすべての役割のリストは、 roleに保存されます 辞書。各ロールは、その role_nameによって一意に定義されます 。役割は、各従業員がパーティー中に実行するアクションに関連しています。したがって、ここでは「パーティマネージャー」や「アシスタント」などの値を期待できます。
役割は、 has_roleを使用して従業員に割り当てることができます テーブル。 employee_id – role_id ペアは、各従業員がその時点で持っているアクティブな役割を示します。
セクション4：パーティー
パーティー サブジェクトエリアは、このモデルの中心部分です。これを使用して、他の主題分野のテーブルを関連付けます。また、ここにもいくつかの新しい情報があります。
ここでの中心的なテーブルはparty テーブル。パーティーごとに、以下を保存します：
-
city_id–都市パーティーが行われる場所。 -
client_id–クライアントこのパーティーはのために組織されています。 詳細 –パーティーの詳細なテキストによる説明。-
start_time_plannedおよびend_time_planned–セットアップとクリーンアップを含む、このパーティーに予定されている時間。 -
start_time_actualおよびend_time_actual–パーティー（およびその関連サービス）が実際に行われた時間。 -
price_offered–このクライアントのためにこのパーティーを開催するために見積もった価格。 -
time_offered–オファーが行われたとき。 -
price_paid–クライアントがこのパーティーに支払った実際の金額。 -
time_paid–支払いが行われたとき。
各パーティはクライアントに関連しています。すでにクライアントを参照しています テーブルですが、ここに何が格納されているかを確認します。基本データのみを使用しました： client_name 、連絡先の詳細（ address 、 email 、 phone 、 mobile ）、およびテキスト形式の追加の詳細。
各パーティには、関連するサービスのリストもあります。そのリストはservice_includedに保存されます テーブル。レコードごとに、次のものが必要です。
-
party_id–関連するパーティを参照します。 -
service_id–サービスを参照しますパーティーに含まれています。 -
provides_id–プロバイダーを参照しますそのサービスだけでなく、サービス自体の。この属性は、特定のプロバイダーを選択したときに更新されるため、NULLにすることができます。 詳細 –そのパーティのそのサービスに関連する追加のテキストの詳細。-
start_time_plannedおよびend_time_planned–パーティー中にサービスを提供する予定の時間。
また、各パーティの進捗状況を追跡する必要があります。これを行うには、2つのテーブルを使用します。
ステータス 表には、パーティーに割り当てることができるすべての可能なステータスが一覧表示されます。レコードごとに、一意の status_nameを保存します および3つのフラグ：
成功–すべてうまくいきましたか？または、サービスに問題がありましたか？有料–パーティーの料金は支払われましたか？最終–これはこのパーティーの最終的なステータスですか？
party_status に新しいレコードを追加して、サービスにステータスを割り当てます テーブル。レコードごとに、 partyへの参照を保存します およびサービス テーブルとtimestamp このステータスが割り当てられたとき。
モデルの最後のテーブルは請求書です テーブル。このモデルに固有のものではありませんが、請求書を保存するための基本的な構造が必要です。請求書ごとに、以下を記録します：
-
client_name–請求書が発行されたときのクライアントの名前。 -
party_id–パーティーこの請求書に関連しています。 -
client_id–クライアントのID請求されます。 -
invoice_amount、割引、vat_amount、total_amount–請求書の財務詳細。 -
time_issued-この請求書が発行されたとき、またはデータベースに追加されたとき。 -
time_paid-この請求書が支払われたとき。
このデータモデルで何をしますか？
このモデルは非常に単純ですが、改善できる方法がいくつかあります。どのような変更を提案しますか？別の方法で整理できるものはありますか？機能を追加または削除する必要があるかもしれません。コメントで教えてください。