Ein Event-Management-Datenmodell

Ein Event zu organisieren ist eine Menge Arbeit! In diesem Artikel untersuchen wir das Datenmodell hinter einer Eventorganisations-App.

Wenn Sie jemals versucht haben, eine Veranstaltung für mehr als zehn Personen zu organisieren (und Partys oder Geschäftstreffen hier nicht zählen), wissen Sie, wie kompliziert Veranstaltungsmanagement sein kann! Haben wir alle eingeladen? Haben sie bestätigt, ob sie kommen? Ist der Veranstaltungsort gebucht und vorbereitet? Wer wird die Veranstaltung ausrichten? Wer wird an den verschiedenen Teilen teilnehmen? Es gibt viele andere Fragen zu beantworten, und es könnte leicht etwas schief gehen.

Sie können Ihre gesamte Planung mit Papier und Stift erledigen, aber warum nicht eine App verwenden? Es ist bequemer! Jede App benötigt einen Ort, an dem alle erforderlichen Ereignisinformationen gespeichert werden können. Hier kommt unser Event-Management-Datenmodell ins Spiel. Holen Sie sich einen Kaffee, machen Sie es sich in Ihrem Lieblingssessel bequem und wir sehen uns an, was nötig ist, um ein Event-Management-Datenmodell zu erstellen.

Häufig gestellte Fragen zur Veranstaltungsverwaltung

Bevor wir das Modell erklären und beschreiben, wie wir die Daten speichern, lassen Sie uns zunächst einige Grundlagen der Ereignisverwaltung durchgehen:

1. Was könnte als Ereignis betrachtet werden?

   In diesem Zusammenhang ist eine Veranstaltung ein Anlass, bei dem viele Menschen, die sich oft nicht kennen, zusammenkommen, um etwas zu lernen oder sich an etwas zu beteiligen. Einige beliebte Veranstaltungen sind Musikfestivals oder Konzerte, IT-Konferenzen, Sportveranstaltungen wie Fußballspiele, Gesundheits- und Medizinkonferenzen usw.

2. Was haben alle Veranstaltungen gemeinsam?

   Die zuvor genannten Veranstaltungsbeispiele unterscheiden sich stark in Inhalt, Zweck und Zielgruppe. Dennoch haben sie viele Gemeinsamkeiten, insbesondere in ihrer Organisation.

   Betrachten Sie zunächst den Inhalt der Veranstaltung. Einige Veranstaltungen (z. B. ein Konzert oder ein Fußballspiel) bieten nur eine Art von Inhalt und finden an einem Ort statt. Andere Ereignisse umfassen viele verschiedene, aber verwandte „Unterereignisse“, die an verschiedenen Orten stattfinden können.

   Nehmen Sie als Beispiel für den zweiten Veranstaltungstyp eine IT-Konferenz. Es gibt Vorträge, Präsentationen, Workshops und Wettbewerbe. Die Teilnehmer werden wahrscheinlich von Raum zu Raum gehen oder sogar zwischen verschiedenen Gebäuden reisen, wenn sie zu verschiedenen Unterveranstaltungen gehen. Einige dieser Unterveranstaltungen finden gleichzeitig statt, aber jede Unterveranstaltung bezieht sich immer noch auf die IT und hat einen oder mehrere Gastgeber.

3. Was braucht es, um eine Veranstaltung erfolgreich zu machen?

   Zunächst einmal gibt es viele Mitarbeiter von Veranstaltungsorten, die im Hintergrund hart arbeiten:Audio- und Videotechniker, Ticketverkäufer, Platzanweiser, Reinigungs- und Wartungsarbeiter und Verwaltungspersonal. Viele Menschen in vielen verschiedenen Rollen werden viele Stunden damit verbringen, hart zu arbeiten, um die Bühne für die „Stars“ und andere Teilnehmer vorzubereiten, aber keiner von ihnen wird viel Anerkennung erhalten.

   Natürlich erfordern alle Veranstaltungen eine Art Infrastruktur. Wenn wir eine Konferenz an einem physischen Ort abhalten, sprechen wir über Räume und Sitze, ein Soundsystem, Beleuchtung, vielleicht Videos usw IT-Setup erforderlich, um sich mit virtuellen Teilnehmern zu verbinden.

   Veranstaltungen haben in der Regel Mediensponsoren und Partner, die bei der Organisation und Bewerbung helfen. Diese Sponsoren sind meist Unternehmen und Verbände mit Bezug zum Veranstaltungsthema; gelegentlich sind es andere Unternehmen, die nach guter Publicity suchen; und seltener tritt eine Privatperson als Sponsor oder Partner auf.

4. Was ist Eventmanagement?

   Eventmanagement ist ein Prozess, der verwendet wird, um Events und alles, was damit zusammenhängt, effektiv zu verwalten. Es könnte als eine Art Projektmanagement betrachtet werden. Wir haben in diesem Artikel ein Projektmanagement-Datenmodell besprochen. Es ist keine schlechte Idee, ein Gantt-Diagramm zu verwenden, um den Fortschritt des Ereignisses, den aktuellen Status und zukünftige Aktionen anzuzeigen.

   Wir möchten wahrscheinlich, dass unsere Event-Management-Anwendung nach Möglichkeit auf einen Bildschirm passt. Die meisten Aktionen – wie das Erstellen einer neuen Show, das Zuweisen von Mitarbeitern und Ressourcen zu einer Aufgabe oder das Schätzen von Kosten – sollten per Drag-and-Drop erfolgen.

Das Datenmodell

Das Datenmodell besteht aus drei Hauptthemenbereichen:

• Events and Partners
• Shows, Performers and Equipment
• Employees

Wir werden uns die einzelnen Themenbereiche in der angegebenen Reihenfolge genauer ansehen.

Abschnitt 1:Veranstaltungen und Partner

Die Events and Partners Themenbereich ist der zentrale Teil unseres Modells. In diesen fünf Tabellen speichern wir die wichtigsten Details zu unseren Veranstaltungen. Wir werden auch Ereignisse mit Partnern verknüpfen.

Beginnen wir mit dem event Tisch. Hier sind alle Veranstaltungen aufgelistet, die wir organisiert haben, und alle Veranstaltungen, die wir planen zu organisieren. Die Attribute in dieser Tabelle sind:

• event_name – Der Name eines Ereignisses. Es ist nicht EINZIGARTIG, da wir möglicherweise zwei oder mehr Ereignisse mit demselben Namen haben – z. ein Konzert derselben Band hätte denselben Veranstaltungsnamen. Der event_name – start_time Paar sollte EINZIGARTIG sein.
• event_type_id – Referenziert den event_type Wörterbuch.
• event_location – Beschreibt den Ort, an dem die Veranstaltung stattfinden wird. Durch die Verwendung eines beschreibenden Attributs können wir vermeiden, ein komplexeres Modell mit Tabellen wie „Land“ und „Stadt“ und Attributen wie „Adresse“ und „Beschreibung“ zu erstellen.
• event_description – Eine detaillierte Beschreibung der Veranstaltung und aller damit verbundenen Shows oder Aktivitäten. Bei einem Konzert würden wir hier Informationen über den Vorband, den Hauptdarsteller, zusätzliche Entertainer und die Aufführungsreihenfolge speichern.
• start_time – Wann die Veranstaltung beginnt. Es ist obligatorisch, weil wir dies in der Planungsphase wissen sollten.
• end_time – Wenn die Veranstaltung endet. Wir könnten dieses Attribut verwenden, um die erwartete oder tatsächliche Endzeit des Ereignisses zu speichern. Da wir diesen genauen Zeitpunkt möglicherweise nicht im Voraus wissen (z. B. wenn ein Sportspiel in die Verlängerung geht), ist dieses Attribut optional.

Der event_type Wörterbuch klassifiziert die von uns behandelten Ereignisse. Wir speichern alle möglichen Arten von Veranstaltungen entsprechend ihrer Nische:Konzert, Fußballspiel, Basketballspiel, IT-Konferenz usw. Jede Veranstaltungsart wird eindeutig durch ihren type_name definiert .

Wie wir bereits erwähnt haben, haben Events normalerweise Partner. Die meisten Veranstaltungen haben mindestens einen Medienpartner, während einige auch Sponsoren und andere Partner haben. Derselbe Partner könnte mehrere unterschiedliche „Partnerrollen“ auf derselben Veranstaltung haben. Beispielsweise könnte ein Fernsehsender gleichzeitig Medienpartner und Generalsponsor der Veranstaltung sein. Aus diesem Grund verwenden wir drei Tabellen, um Ereignisse mit Partnern in Beziehung zu setzen.

Es ist wichtig, in der Planungsphase Partner hinzufügen zu können, damit alle Beteiligten der Veranstaltung rechtzeitig auf diese Informationen zugreifen können. Außerdem können wir vergangene Daten verwenden, wenn wir neue Veranstaltungen planen – z. Wir könnten denselben Partner kontaktieren, wenn wir eine wiederkehrende Veranstaltung oder eine neue Veranstaltung der gleichen Art organisieren. Wenn ein Unternehmen letztes Jahr Generalsponsor einer Tech-Konferenz war, ist es möglicherweise daran interessiert, dies dieses Jahr erneut zu tun.

Schauen wir uns nun die drei Partnerschaftstabellen an. Der erste ist der partner Katalog. Für jeden Partner speichern wir den partner_name und ihre Adresse, Kontaktinformationen und andere partner_details . Beachten Sie, dass der partner_name Attribut ist nicht eindeutig. Wir können zwei Partner mit demselben Namen haben, wie z. B. zwei Privatpersonen mit demselben Vor- und Nachnamen oder zwei Unternehmen mit demselben Firmennamen. In diesem Fall unterscheiden wir sie anhand der in den partner_details gespeicherten Informationen Attribut.

Die zweite Tabelle ist die partner_role Wörterbuch, das alle möglichen Rollen eines Partners auflistet. Der role_name -Attribut enthält nur EINZIGARTIGE Werte. Einige erwartete Rollennamen sind „Medienpartner“, „Hauptsponsor“ und „Sponsor“.

Die letzte Tabelle in diesem Themenbereich verknüpft Partner mit Veranstaltungen. Der is_partner Tabelle enthält nur Fremdschlüssel, die Partner mit Ereignissen verknüpfen und Rollen oder Partnerschaftstypen definieren. Die Kombination dieser Fremdschlüssel bildet den UNIQUE-Schlüssel der Tabelle. Wenn wir wollten, könnten wir ein Startdatum und ein Enddatum hinzufügen, falls ein Partner seine Rolle nur für einen Teil der Veranstaltung ausfüllt. Wir könnten Partner auch mit einzelnen Teilereignissen und nicht mit ganzen Ereignissen in Beziehung setzen. Da dies jedoch relativ ungewöhnliche Situationen sind, belassen wir diesen Teil des Modells unverändert.

Abschnitt 2:Shows, Künstler und Ausrüstung

Wie in der Einleitung erwähnt, kann jedes Ereignis mehrere Unterereignisse haben. In diesem Modell habe ich mich entschieden, die Unterveranstaltungen „Shows“ zu nennen. Eine Show ist eine einzelne Unterveranstaltung, die sich auf ein Thema konzentriert, mindestens einen Künstler hat usw. Bei einer IT-Konferenzveranstaltung könnte eine Show ein Vortrag über Projektmanagementprinzipien sein; Eine andere Veranstaltung könnte eine Podiumsdiskussion über bewährte Vorgehensweisen im Bereich Data Warehousing sein. Beide könnten gleichzeitig an verschiedenen Orten stattfinden und von verschiedenen Moderatoren moderiert werden. Wir definieren auch alles, was für eine Show benötigt wird, denn die Show muss weitergehen (auf jeden Fall ☺ ).

Die zentrale Tabelle dieses Abschnitts ist show Tisch. Dadurch werden Aufzeichnungen über alle Shows im Zusammenhang mit vergangenen, gegenwärtigen und zukünftigen Ereignissen geführt. Wenn wir eine Veranstaltung planen, müssen wir neue Shows hinzufügen, sobald der Darsteller (d. h. Dozent, Redner, Moderator, Rockstar) zugestimmt hat, an einer Veranstaltung teilzunehmen. Ein Blick auf die Beschreibung der Attribute der Tabelle hilft uns zu verstehen, wie sie funktioniert:

• show_name – Der Name der Sendung.
• show_location – Beschreibt, wo die Show stattfinden wird.
• show_description – Eine detaillierte Beschreibung dieser Show.
• start_time – Die erwartete Startzeit.
• end_time – Die erwartete Endzeit. Es kann NULL sein, da wir möglicherweise die tatsächliche Endzeit (nach Ende der Show) anstelle der erwarteten Endzeit eingeben.
• event_id – Zu welcher Veranstaltung die Show gehört.

In den meisten Fällen benötigen Shows Ausrüstung und Darsteller. (Theoretisch könnten wir eine Show ohne Darsteller haben, aber darauf verzichten wir hier.) Da die Ausstattung begrenzt ist, ist es wichtig, alles Nötige in der Planungsphase der Veranstaltung zu reservieren. Um dies richtig zu tun, müssen wir wissen, was zu welcher Zeit passieren wird. Wenn wir beispielsweise zwei Projektoren und zwei Shows haben, die Projektoren erfordern, die für dieselbe Zeit geplant sind, können wir für diese Zeit keine dritte Projektor-erfordernde Show hinzufügen, es sei denn, wir besorgen mehr Ausrüstung. Dies ist die Art von Informationen, die wir in der Planungsphase haben müssen.

Weiter geht es mit dem performer Tisch. Dies ist ein einfacher Katalog aller Künstler, mit denen wir bei einer Veranstaltung zusammengearbeitet haben oder mit denen wir zusammenarbeiten werden. Für jeden Darsteller speichern wir seinen full_name . Das kann der Name einer Band, eines Dozenten etc. sein. Das genre Das Attribut dient dazu, zwischen den verschiedenen Arten von Darstellern zu unterscheiden – z. Rockbands von Bildhauern. Das letzte Attribut in dieser Tabelle speichert die contact_details der Darsteller . Wir verwenden den Textdatentyp, um das Los zu speichern, aber wir könnten die Kontaktdaten auch in einige separate Felder aufteilen.

Wir werden Shows und Darsteller über den participate Tisch. Die Attribute in dieser Tabelle sind:

• show_id und performer_id – Verweise auf die zugehörige Show und den Darsteller. Dieses Paar könnte ein alternativer (eindeutiger) Schlüssel der Tabelle sein, aber ich habe mich entschieden, ihn nicht zu verwenden; wir haben vielleicht einen Künstler, der zu zwei verschiedenen Zeiten Teil derselben Show ist.
• start_time und end_time – Genaue Zeiten, die definieren, wann dieser Darsteller Teil dieser Show war.
• cost_planned und cost_actual – Die Kosten/Honorare, die wir einem Künstler voraussichtlich zahlen werden, und was wir ihnen tatsächlich gezahlt haben.

Die verbleibenden drei Tabellen werden verwendet, um die gesamte Ausrüstung zu definieren, die für eine Show benötigt wird.

Der equipment_type Wörterbuch kategorisiert Ausrüstung. Bei einem Konzert könnten diese Kategorien „Lichttechnik“, „Musikinstrumente“, „Bühnenbau“ usw. sein. Der type_name -Attribut enthält nur EINZIGARTIGE Werte.

Die equipment Tabelle beschreibt Ausrüstungsgegenstände und Mengen. Sein name -Attribut definiert die Ausrüstung spezifischer als equipment_type .type_name . Bei einer Diskokugel wäre der Wert „equipment“.“name“ „disco ball“, aber ihr „equipment_type“.“type_name“ wäre „lighting equipment“. Der available Das Attribut definiert, welche Menge des Artikels uns zur Verfügung steht. Es ist eine Dezimalzahl, weil wir vielleicht einige „Elemente“ verwenden, die nicht aufgezählt werden können, wie Wasser und Strom.

Die letzte Tabelle in diesem Abschnitt bezieht sich auf Ausrüstung und Shows. Dies kann uns helfen, die Ausrüstung in der Planungsphase zu organisieren; Es ermöglicht uns auch, später Berichte über die Ausrüstungskosten zu erstellen. Wenn wir die Gerätenutzung und -kosten planen, können diese Informationen sehr nützlich sein, insbesondere bei wiederkehrenden (oder sehr ähnlichen) Ereignissen. Die Attribute im required Tabelle sind:

• show_id und equipment_id – Bezieht sich auf die zugehörige Show und Ausrüstung. Dieses Paar bildet den UNIQUE-Schlüssel der Tabelle.
• quantity – Die Menge der benötigten Ausrüstung.
• cost_planned und cost_actual – Was wir voraussichtlich für die Installation oder Anmietung von Geräten zahlen werden und was wir tatsächlich bezahlt haben.

Abschnitt 3:Mitarbeiter

Der Themenbereich dieses Modells dreht sich um Mitarbeiter und ihre Rollen. Ich weise immer wieder darauf hin, dass Menschen und ihre Zeit der wichtigste Teil eines jeden Projekts sind. Alles andere ist nur ein Werkzeug, um einen Job zu machen. (Und dieses Werkzeug wurde auch von Menschen gemacht, die ihre Zeit nutzten. ☺ )

Ich werde den employee , role und has_role Tabellen hier. Ich habe es schon oft gemacht, zum Beispiel in diesem Artikel. Bitte überprüfen Sie es bei Bedarf.

Die letzte Tabelle in unserem Modell verknüpft Mitarbeiter und Rollen mit Shows. Wir können mit einer begrenzten Anzahl qualifizierter Mitarbeiter rechnen und müssen sicher sein, dass sie bei Bedarf verfügbar sind. Natürlich kann dieselbe Person nicht gleichzeitig an zwei verschiedenen Orten sein. Die Attribute im engaged Tabelle sind:

• show_id und has_role_id – Verweist auf die zugehörige Sendung und Mitarbeiterrolle.
• start_time – Wenn wir erwarten, dass ein Mitarbeiter diese Rolle übernimmt.
• end_time – Wenn diese Rolle endet. Dies ist nullable, da wir in den meisten Fällen einen Wert zuweisen, nachdem der Mitarbeiter seine Rolle beendet hat. Möglicherweise geben wir hier jedoch eine erwartete Endzeit ein.
• cost_planned und cost_actual – Was wir von einem Mitarbeiter für die Übernahme dieser Rolle erwarten und was wir tatsächlich bezahlt haben.

Ich möchte noch einmal darauf hinweisen, dass diese historischen Daten sehr hilfreich sein können, wenn Sie eine Wiederholungsveranstaltung oder eine Veranstaltung organisieren, die einer vergangenen Veranstaltung ähnlich ist.

Heute haben wir ein mögliches Datenmodell für eine Event-Management-Datenbank besprochen. Wir haben die wirklich wichtigen Dinge behandelt, wie die Beschreibung der Veranstaltung, die Planung von Darstellern und die Zuweisung von Mitarbeitern und Ressourcen für die Veranstaltung. Die Handhabung der Kosten in diesem Modell ist vereinfacht, bietet uns aber dennoch die Möglichkeit, geplante und tatsächliche Kosten nach Kategorie, Veranstaltung, Show oder Gerätetyp zu berechnen.

Ich bin kein Eventmanager. Wenn ja, hoffe ich, dass Sie diesen Artikel sehr hilfreich fanden. Aber ich würde gerne Ihr Feedback dazu hören, welche Ergänzungen oder Änderungen in realen Situationen nützlich sein könnten.

Natürlich ist jeder willkommen, seine Vorschläge und Ideen im Kommentarbereich einzureichen.