イベント管理データモデル

イベントの企画は大変です！この記事では、イベント組織アプリの背後にあるデータモデルを検証します。

10人以上のイベントを開催しようとしたことがある場合（ここではパーティーやビジネス会議は数えません）、イベント管理がいかに複雑になるかをご存知でしょう。みんなを招待しましたか？彼らは彼らが来るかどうかを確認しましたか？会場は予約され、準備されていますか？誰がイベントを主催しますか？誰がさまざまな部分に参加しますか？答えるべき質問は他にもたくさんあり、物事は簡単にうまくいかない可能性があります。

紙とペンですべての計画を立てることができますが、アプリを使ってみませんか？もっと便利です！どのアプリにも、必要なすべてのイベント情報を保存する場所が必要です。ここで、イベント管理データモデルがこのストーリーに入ります。コーヒーを飲み、お気に入りの椅子に腰を下ろしてください。イベント管理データモデルを構築するために必要なことを見ていきます。

イベント管理に関するFAQ

モデルを説明し、データを保存する方法を説明する前に、まずイベント管理の基本を確認しましょう。

イベントと見なすことができるものは何ですか？

この文脈では、イベントとは、お互いを知らないことが多い多くの人々が集まって、何かについて学んだり、何かに参加したりする機会です。人気のあるイベントには、音楽祭やコンサート、IT会議、サッカーゲームなどのスポーツイベント、健康と医療の会議などがあります。
すべてのイベントに共通するものは何ですか？

前述のイベントの例は、内容、目的、対象者の点で大きく異なります。それでも、特に組織では、多くの類似点があります。

まず、イベントの内容を検討します。一部のイベント（コンサートやサッカーの試合など）では、1種類のコンテンツのみが提供され、1か所で開催されます。他のイベントには、さまざまな場所で発生する可能性のある、多くの異なるが関連する「サブイベント」が含まれます。

2番目のタイプのイベントの例としてIT会議を取り上げます。講義、プレゼンテーション、ワークショップ、および競技会があります。参加者はおそらく部屋から部屋へと移動したり、さまざまなサブイベントに移動するときに異なる建物間を移動したりすることもあります。これらのサブイベントの一部は同時に実行されますが、各サブイベントは引き続きITに関連しており、1つ以上のホストがあります。
イベントを成功させるには何が必要ですか？

まず第一に、バックグラウンドで一生懸命働く多くのイベント会場の人員がいます：オーディオとビジュアルの技術者、チケット売り手、案内係、清掃とメンテナンスの人員、そして管理人員。さまざまな役割の多くの人々が、「スター」や他の参加者のためにステージを準備するために何時間も懸命に取り組んでいますが、誰もあまり認知されません。

明らかに、すべてのイベントには何らかのインフラストラクチャが必要です。物理的な場所で会議を開催する場合は、部屋や座席、サウンドシステム、照明、ビデオなどについて話します。ウェビナーなどのオンラインイベントでも、コンテンツやコンテンツを制作する場所が必要です。仮想参加者と接続するために必要なITセットアップ。

イベントには通常、イベントの開催と宣伝を支援するメディアスポンサーとパートナーがいます。これらのスポンサーは主に、イベントのトピックに関連する企業や団体です。時々彼らはいくつかの良い宣伝を探している他の会社です。まれに、個人がスポンサーまたはパートナーとして機能することもあります。
イベント管理とは何ですか？

イベント管理は、イベントとそれに関連するすべてのものを効果的に管理するために使用されるプロセスです。これは、一種のプロジェクト管理と見なすことができます。この記事では、プロジェクト管理データモデルについて説明しました。ガントチャートを使用してイベントの進行状況、現在のステータス、および将来のアクションを表示することは悪い考えではありません。

可能であれば、イベント管理アプリケーションを1つの画面に収めたいと思うでしょう。新しいショーの作成、タスクへの従業員とリソースの割り当て、コストの見積もりなど、ほとんどのアクションはドラッグアンドドロップで行う必要があります。

データモデル

データモデルは、次の3つの主要な主題領域で構成されています。

イベントとパートナー
ショー、パフォーマー、機器
従業員

リストされている順序で、各サブジェクト領域を詳しく見ていきます。

セクション1：イベントとパートナー

イベントとパートナー サブジェクトエリアはモデルの中心部分です。これらの5つの表には、イベントに関する最も重要な詳細が格納されています。また、イベントをパートナーと関連付けます。

イベントから始めましょう テーブル。これには、私たちが開催したすべてのイベントと、私たちが開催する予定のすべてのイベントが一覧表示されます。この表の属性は次のとおりです。

event_name –イベントの名前。同じ名前のイベントが2つ以上ある可能性があるため、一意ではありません。同じバンドによるコンサートは同じイベント名になります。ただし、 event_name – start_time ペアは一意である必要があります。
event_type_id – event_typeを参照します 辞書。
event_location –イベントが行われる場所について説明します。記述属性を使用すると、「国」や「都市」などのテーブルと「住所」や「説明」などの属性を使用して、より複雑なモデルを構築する必要がなくなります。
event_description –イベントとそれに関連するすべてのショーまたはアクティビティの詳細な説明。コンサートの場合、ここにオープニングアクト、メインアクト、追加のエンターテイナー、パフォーマンスの順序に関する情報を保存します。
start_time –イベントが開始される時期。計画段階でこれを知っておく必要があるため、必須です。
end_time –イベントが終了したとき。この属性を使用して、予想されるイベントまたは実際のイベントの終了時刻を保存できます。この正確な時刻が事前にわからない場合があるため（たとえば、スポーツゲームが時間外になる場合）、この属性はオプションです。

event_type 辞書は、処理するイベントを分類します。コンサート、サッカーの試合、バスケットボールの試合、IT会議など、考えられるすべての種類のイベントをニッチに応じて保存します。各イベントの種類は、 type_nameによって一意に定義されます。。

前述したように、イベントには通常パートナーがいます。ほとんどのイベントには少なくともメディアパートナーがいますが、スポンサーや他のパートナーもいるイベントもあります。同じパートナーが、同じイベントで複数の異なる「パートナーの役割」を持つ可能性があります。たとえば、テレビ放送会社は、メディアパートナーであり、同時にイベントのジェネラルスポンサーになることができます。これが、イベントをパートナーと関連付けるために3つのテーブルを使用する理由です。

すべてのイベントの利害関係者がその情報にタイムリーにアクセスできるように、計画フェーズでパートナーを追加できることが重要です。また、新しいイベントを計画する際に過去のデータを使用する場合があります。定期的なイベントや同じ種類の新しいイベントを開催するときに、同じパートナーに連絡することができます。昨年、企業が技術会議の一般スポンサーだった場合、今年もそれを行うことに興味があるかもしれません。

それでは、3つのパートナーシップテーブルを見てみましょう。 1つ目はパートナーです カタログ。パートナーごとに、partner_nameを保存しますおよびその住所、連絡先情報、その他のpartner_details 。 partner_nameに注意してください属性は一意ではありません。同じ名前の2人のパートナーがいる場合があります。たとえば、同じ名前と姓の2人の個人、または同じ会社名の2つの会社などです。この場合、partner_detailsに保存されている情報を使用してそれらを区別します属性。

2番目のテーブルはpartner_role 辞書。パートナーが持つ可能性のあるさまざまな役割をすべて一覧表示します。 role_name 属性にはUNIQUE値のみが含まれます。予想される役割名には、「メディアパートナー」、「一般スポンサー」、「スポンサー」があります。

このサブジェクトエリアの最後の表は、パートナーとイベントを関連付けています。 is_partner テーブルには、パートナーをイベントに関連付け、役割またはパートナーシップタイプを定義する外部キーのみが含まれます。これらの外部キーの組み合わせは、テーブルのUNIQUEキーを形成します。必要に応じて、一部のパートナーがイベントの一部でのみ役割を果たす場合に備えて、開始日と終了日を追加できます。また、イベント全体ではなく、単一のサブイベントにパートナーを関連付けることもできます。それでも、これらは比較的まれな状況であるため、モデルのこの部分はそのままにしておきます。

セクション2：ショー、パフォーマー、設備

はじめに述べたように、各イベントにはいくつかのサブイベントを含めることができます。このモデルでは、サブイベントを「ショー」と呼ぶことにしました。ショーは、1つのトピックに焦点を当て、少なくとも1人のパフォーマーがいるなど、単一のサブイベントです。IT会議イベントでは、1つのショーがプロジェクト管理の原則に関する講義になる場合があります。別のショーは、データウェアハウジングのベストプラクティスのパネルディスカッションである可能性があります。両方とも同時に、異なる場所で行われ、異なるプレゼンターによってホストされる可能性があります。ショーは続行する必要があるため（いずれの場合も☺）、ショーを実行するために必要なすべてのものも定義します。

このセクションの中心となるテーブルは、 show テーブル。これにより、過去、現在、および将来のイベントに関連するショーの記録が保持されます。イベントを計画しているときは、出演者（講師、スピーカー、プレゼンター、ロックスターなど）がイベントに参加することに同意したらすぐに、新しいショーを追加する必要があります。テーブルの属性の説明を見ると、テーブルがどのように機能するかを理解するのに役立ちます。

show_name –ショーの名前。
show_location –ショーが行われる場所について説明します。
show_description –そのショーの詳細な説明。
start_time –予想される開始時間。
end_time –予想される終了時間。予想される終了時間ではなく、実際の終了時間（ショーが終了した後）を入力する可能性があるため、NULLになる可能性があります。
event_id –ショーが含まれるイベント。

ほとんどの場合、ショーには機器とパフォーマーが必要です。（理論的にはパフォーマーなしでショーを開催することもできますが、ここでは気にしません。）設備が限られているため、イベントの計画段階で必要なものをすべて予約することが重要です。これを適切に行うには、いつ何が起こるかを知る必要があります。たとえば、2つのプロジェクターと2つのショーで、同時にスケジュールされたプロジェクターが必要な場合、より多くの機器を入手しない限り、その時間に3つ目のプロジェクターが必要なショーを追加することはできません。これは、計画段階で必要な種類の情報です。

次に、実行者がいます。 テーブル。これは、私たちが一緒に仕事をした、またはどんなイベントでも一緒に仕事をするすべてのパフォーマーの簡単なカタログです。出演者ごとに、 full_nameを保存します。バンドや講師などの名前かもしれません。ジャンル 属性は、さまざまなタイプのパフォーマーを区別するためにここにあります。彫刻家のロックバンド。このテーブルの最後の属性には、パフォーマーの contact_detailsが格納されます。テキストデータタイプを使用してロットを保存しますが、連絡先の詳細をいくつかの個別のフィールドに分割することもできます。

participateを介してショーとパフォーマーを関連付けます テーブル。この表の属性は次のとおりです。

show_id およびperformer_id –関連するショーとパフォーマーへの参照。このペアはテーブルの代替（一意）キーである可能性がありますが、私はそれを使用しないことにしました。 1人のパフォーマーが2つの異なる時間に同じショーに参加する場合があります。
start_time およびend_time –そのパフォーマーがいつそのショーに参加したかを定義する正確な時間。
cost_planned およびcost_actual –パフォーマーに支払うと予想される費用/料金と実際に支払った金額。

残りの3つの表は、ショーに必要なすべての機器を定義するために使用されます。

equipment_type 辞書は機器を分類します。コンサートの場合、これらのカテゴリには、「照明器具」、「楽器」、「ステージ建設」などがあります。 type_name 属性にはUNIQUE値のみが含まれます。

機器 表は、機器のアイテムと数量を示しています。その名前属性は、 equipment_typeよりも具体的に機器を定義します。type_name 。ディスコボールの場合、その「equipment」。「name」の値は「disco ball」になりますが、「equipment_type」。「type_name」は「lightingequipment」になります。利用可能属性は、利用可能なアイテムの数量を定義します。水や電気など、列挙できない「アイテム」を使用する可能性があるため、10進数です。

 
 このセクションの最後の表は、機器とショーに関するものです。これは、計画段階で機器を整理するのに役立ちます。また、後で機器のコストに関するレポートを作成することもできます。機器の使用量とコストを計画している場合、この情報は、特に定期的な（または非常に類似した）イベントに非常に役立ちます。 必須の属性  表は次のとおりです：
    show_id  およびequipment_id –関連するショーと機器を指します。このペアは、テーブルのUNIQUEキーを形成します。
 数量 –必要な機器の数。
   cost_planned  およびcost_actual –機器の設置またはレンタルに支払うと予想される金額と、実際に支払った金額。
 
 セクション3：従業員
   
 
 このモデルの主題分野は、従業員とその役割に関するものです。私は常に、人々とその時間はプロジェクトの最も重要な部分であることを指摘するのが大好きです。それ以外のものは、仕事をするための単なるツールです。 （そして、そのツールも人々が時間を使って作ったものです。☺）
 
 従業員については説明しません  、役割  およびhas_role   ここにテーブル。たとえば、この記事では、これまで何度も行ってきました。必要に応じて確認してください。
 
 モデルの最後の表は、従業員と役割をショーに関連付けています。資格のある従業員の数は限られていると予想されるため、必要なときに確実に対応できるようにする必要があります。明らかに、同じ人が同時に2つの異なる場所にいることはできません。 エンゲージメントの属性  表は次のとおりです：
    show_id  およびhas_role_id –関連するショーと従業員の役割を参照します。
   start_time  –従業員がその役割を開始することを期待する場合。
   end_time  –その役割が終了したとき。ほとんどの場合、従業員が役割を終えた後に値を割り当てるため、これはnull可能です。ただし、ここに予想終了時刻を入力する場合があります。
   cost_planned  およびcost_actual –その役割を処理するために従業員に支払うと予想される金額と、実際に支払った金額。
 
 
 繰り返しになりますが、この履歴データは、繰り返しのイベントや過去のイベントに類似したイベントを整理するときに非常に役立つ可能性があることを指摘しておきます。
 
 今日は、イベント管理データベースの可能なデータモデルについて説明しました。イベントの説明、パフォーマーのスケジュール設定、イベントへの従業員とリソースの割り当てなど、非常に重要なことについて説明しました。このモデルでのコストの処理は単純化されていますが、それでも、カテゴリ、イベント、ショー、または機器のタイプごとに計画および実際のコストを計算する機能が提供されます。 
 
 私はイベントマネージャーではありません。もしそうなら、この記事が非常に役立つことを願っています。ただし、実際の状況でどのような追加または変更が役立つ可能性があるかについて、フィードバックをお聞かせください。 
 
 もちろん、コメントセクションで提案やアイデアを提出することは誰でも歓迎します。