Datenmodell der Hochzeitsorganisation

Hochzeiten werden oft von Fröhlichkeit und Feier begleitet, mit zahlreichen Gästen, Speisen, Getränken, Musik und Tanz. Aber all das geht nicht ohne die richtige Vorbereitung und Koordination. Sehen wir uns einmal genauer an, wie uns die Datenmodellierung dabei helfen kann, eine Hochzeit besser zu organisieren, damit alles reibungslos abläuft.

Vorläufiger Hintergrund

Obwohl wir uns größtenteils bewusst sind, wie eine typische Hochzeitszeremonie aussieht, kann es nicht schaden, kurz einige Aspekte zu betrachten, die sich möglicherweise auf unser Datenmodell auswirken könnten.

Hochzeitspartner

Obwohl die meisten traditionellen Kulturen Zeremonien zwischen Mann und Frau haben, finden gleichgeschlechtliche Ehen auch in anderen Gesellschaften statt. Unser Datenmodell sollte so gestaltet sein, dass es alle Möglichkeiten berücksichtigt.

Umfang und Komplexität

Hochzeitszeremonien unterscheiden sich stark in ihrer Größe, Dauer und Komplexität. Einige sind kleine, bescheidene Anlässe, aber andere sind große Feiern. In Kroatien können Sie beispielsweise eine einfache Hochzeitszeremonie abhalten, bei der ein Paar im Rathaus heiratet, seine Ringe und Gelübde vor seinen Gästen tauscht und entweder an einem Abendessen nach der Zeremonie teilnimmt oder nach Hause geht. In anderen Ländern können Hochzeiten ziemlich aufwändig sein:Sie können Junggesellenabschiede, Verhandlungen, Abendessen, mehrere Zeremonien und so weiter umfassen. In einigen Fällen können diese Zeremonien mehrere Tage dauern und an verschiedenen Orten stattfinden! Auch hier sollte unser Datenmodell darauf vorbereitet sein, mit diesen Situationen umzugehen.

Endergebnis und Ausgaben

In den meisten Fällen heiratet das Paar nach der Feier und erhält eine Rechnung über alle Kosten (Miete, Essen und Getränke, Band etc.). Sie können sich entscheiden, eine Agentur zu beauftragen, die sich um all diese Kosten für sie kümmert, oder sie können sich dafür entscheiden, alles selbst zu erledigen. In jedem Fall sollten wir diese Situationen berücksichtigen.

Das Datenmodell:Übersicht

Unser Datenmodell für diesen Artikel besteht aus fünf Abschnitten:

1. Standorte
2. Partner, Produkte und Dienstleistungen
3. Hochzeiten
4. Teilnehmer
5. Rechnungen

Wir werden jeden dieser Bereiche in der oben aufgeführten Reihenfolge ausführlich besprechen. Während wir an der Entwicklung unseres Datenmodells arbeiten, übernehmen wir die Rolle der Agentur, die die Hochzeit organisiert.

Abschnitt 1:Standorte

Die Locations Abschnitt enthält universelle Tabellen, die in vielen anderen Datenmodellen verwendet werden können. Wie bereits erwähnt, kann die gesamte Hochzeitszeremonie an nur einem einzigen Ort stattfinden oder sich möglicherweise über mehrere Orte erstrecken. Lassen Sie uns die Tabellen dieses Abschnitts genauer besprechen.

Das country Tabelle speichert Informationen über das Land, in dem die Hochzeit stattfindet. In den meisten Fällen entspricht dieses Land dem Standort unserer Agentur, aber das ist möglicherweise nicht der Fall, wenn wir international tätig sind. Jedes Land in dieser Tabelle wird eindeutig durch seinen country_name definiert .

Als nächstes müssen wir die Liste aller Städte und/oder Dörfer speichern, in denen die Hochzeit organisiert wird. Diese Informationen werden in der city Tisch. Für jede Stadt speichern wir den Namen und die Postleitzahl sowie das Land, in dem sie sich befindet.

Die letzte Tabelle in diesem Themenbereich ist location . Orte sind spezifischer, z. B. Rathäuser, Kirchen, Parks usw. Für jeden Standort speichern wir seinen Namen und einen Verweis auf die ID der Stadt, in der er sich befindet. Die Kombination dieser beiden Attribute bildet den eindeutigen Schlüssel für diese Tabelle.

Beachten Sie bei den Orten, dass wir hier einen konservativen Ansatz gewählt haben, um die ungewöhnlichen Fälle zu vermeiden, in denen die Zeremonie beispielsweise in einem Zug oder Flugzeug stattfindet (in diesem Fall kann der „Ort“ mehrere Städte umfassen). Wenn wir diese Fälle abdecken möchten, müssten wir einige Änderungen an unserem Modell vornehmen.

Abschnitt 2:Partner, Produkte und Dienstleistungen

Bevor wir zum zentralen Teil unseres Datenmodells übergehen, müssen wir die Liste aller Partner, mit denen wir zusammenarbeiten, sowie die von ihnen angebotenen Produkte und Dienstleistungen speichern. Um dies zu erreichen, verwenden wir fünf Tabellen.

Zunächst einmal ist die Liste aller Partner, mit denen wir zusammenarbeiten, im partner Wörterbuch. Für jeden Partner speichern wir seinen eindeutigen partner_code und partner_name .

Natürlich bieten unsere Partner hochzeitsbezogene Dienstleistungen an, die Catering, die Organisation von Bands, die Einrichtung von Audio- und Videogeräten, Mietunterstützung und vieles mehr umfassen können. Im Grunde kann alles, was Sie sich vorstellen können, in irgendeiner Weise mit einer Hochzeit zusammenhängen. Wir speichern diese Liste von Diensten im service Wörterbuch. Für jeden Dienst speichern wir:

• service_code – ein Wert, den wir intern verwenden, um einen bestimmten Dienst eindeutig zu kennzeichnen.
• service_name – Name des Dienstes. Beachten Sie, dass verschiedene Dienste denselben Namen haben können. Dies würde passieren, wenn zwei unserer Partner den gleichen Service anbieten, was sehr wahrscheinlich ist. Es wäre sogar wünschenswert, wenn sie den gleichen Namen für den gleichen Servicetyp verwenden, da dies den Vergleich der Preise für die gleichen Services viel einfacher machen würde.
• description – eine optionale Textbeschreibung des Dienstes.
• picture – einen Link zu dem Ort, an dem das zugehörige Dienstbild gespeichert ist.
• price – der aktuelle Preis für diese Dienstleistung. Es kann einen Wert von NULL enthalten, wenn der Preis nicht bestimmt werden kann, ohne zuerst verschiedene Faktoren zu bewerten, z. B. wie viele Personen an der Zeremonie teilnehmen möchten.

Der provides_service Die Tabelle bezieht Partner auf die Liste der von ihnen bereitgestellten Dienste. Für jede eindeutige Kombination von partner_id und service_id , speichern wir eine detaillierte Textbeschreibung der Art des vom Partner bereitgestellten Dienstes und ob der Dienst derzeit verfügbar ist.

Wir brauchen auch Tabellen zum Speichern von Informationen über Produkte und deren Beziehungen zu Partnern. Das product table folgt der gleichen Logik wie der service Tabelle, außer, wie der Name schon sagt, es ist spezifisch für Produkte. In dieser Tabelle speichern wir alle möglichen Produkte, die für die meisten Hochzeitszeremonien unerlässlich sind, wie Ringe, Outfits, Dekorationen, Blumen, Möbel und mehr.

Die letzte Tabelle in diesem Abschnitt ist provides_product Tisch. Es funktioniert genauso wie der provides_service Tabelle, außer dass es spezifisch für Produkte und nicht für Dienstleistungen ist. Sie gibt an, welcher unserer Partner das betreffende Produkt anbietet.

Abschnitt 3:Hochzeiten

Endlich sind wir beim Kern unseres Datenmodells angelangt – den Weddings Sektion. Es enthält fünf neue Tabellen, die auf die Tabellen anderer Abschnitte verweisen. Beachten Sie, dass die eigenen Tabellen dieses Abschnitts auch in zukünftigen Teilen unseres Modells referenziert werden.

In der wedding Tabelle speichern wir die vollständige Liste aller Hochzeiten, an deren Organisation wir beteiligt sind/waren. Jeder Hochzeit wird ein eigener wedding_code zugewiesen . Wir speichern auch die geplanten Start- und Endzeiten für die gesamte Zeremonie und aktualisieren die tatsächlichen Start- und Endzeiten, sobald diese Informationen verfügbar sind. Zusätzlich speichern wir das budget_planned wert, sodass wir zumindest eine Schätzung haben, wie viel das alles kosten wird. Alle anderen Details im Zusammenhang mit der Hochzeit werden in anderen Bereichen des Datenmodells gespeichert, also ist das alles, was wir jetzt wirklich brauchen.

Die Idee dabei ist, jede Hochzeit als eine Reihe von Ereignissen zu behandeln. Ereignisse wiederum beziehen sich auf Angebote für gewünschte Produkte/Dienstleistungen, abgelehnte und akzeptierte Angebote und andere relevante Details. Um Ihnen eine bessere Vorstellung davon zu geben, wie das alles funktioniert, könnten wir die gesamte Hochzeit in die folgenden Ereignisse aufteilen:Planungsphase, Junggesellen-/Junggesellenabschied, Zeremonie und After-Party/Dinner. Dies sind natürlich nur einige der häufigsten Hochzeitsveranstaltungen. Alle Hochzeitsereignisse werden in der Ereignistabelle gespeichert. Ein event wird eine eindeutige ID haben.

Jede Veranstaltung ist mit einer einzelnen Hochzeit verbunden, und sie wird entweder mit einem Ort oder keinem verbunden sein. Der letztere Fall tritt auf, wenn das Ereignis eher konzeptionell ist , wie z. B. die Planungsphase (da es keinen einzelnen Ort gibt, an dem sie stattfinden muss). Wie bei der eigentlichen Hochzeitszeremonie selbst hat eine Veranstaltung geplante und tatsächliche Start-/Endzeiten sowie ein geplantes Budget. Beachten Sie, dass wir die Dinge hier in Bezug auf die Standorte einfach gehalten haben. Wenn Veranstaltungen mehrere Standorte umfassen, müssen wir unser Datenmodell anpassen.

Als nächstes möchten wir alle Dienstleistungen und Produkte speichern, die mit einer Veranstaltung in Verbindung stehen. Dazu verwenden wir drei Tabellen:status , product_included und service_included .

Der status Tabelle ist ein Wörterbuch, das alle Status im Zusammenhang mit Produkten und Dienstleistungen für ein bestimmtes Ereignis verfolgt. Es enthält Flag-Variablen, die angeben, ob ein Produkt/eine Dienstleistung angeboten, akzeptiert oder abgelehnt wurde. Für jeden Datensatz in dieser Tabelle speichern wir einen eindeutigen status_name .

Die verbleibenden zwei Tabellen in diesem Abschnitt mit dem Titel product_included und service_included , ähneln sich strukturell und konzeptionell. Für jede Veranstaltung speichern wir die Liste der angebotenen Produkte und Dienstleistungen und ändern ihren Status, wenn sie akzeptiert oder abgelehnt werden. Für jeden Datensatz in diesen beiden Tabellen speichern wir die folgenden gemeinsamen Attribute:

• event_id – ein Verweis auf die zugehörige Veranstaltung.
• provides_product_id / provides_service_id – Verweise auf die Tabellen mit Produkten/Dienstleistungen, die unsere Partner im Angebot haben.
• price – vorgeschlagener Preis für das Produkt/die Dienstleistung. Dieser Preis kann von dem bei uns hinterlegten Standardpreis abweichen, wenn wir Ihnen ein Sonderangebot unterbreiten.
• current_status_id – ein Verweis auf den status Wörterbuch, das angibt, ob dieser Datensatz angeboten, akzeptiert oder abgelehnt wurde.

Abschnitt 4:Teilnehmer

Wenn Sie eine große Hochzeit organisieren, kennen Sie wahrscheinlich die meisten Gäste, die teilnehmen möchten. Natürlich werden die Gäste, die Sie einladen – seien es Ihre Freunde oder Verwandten – wahrscheinlich andere Personen mitbringen, die Sie nicht persönlich kennen, wie z. B. ihre Freunde oder Kollegen. In diesem Abschnitt speichern wir die vollständige Liste der Gäste, die zur Hochzeit eingeladen wurden, sowie ihre Rollen.

Die person Tabelle enthält eine Liste aller Personen, die Teil der Hochzeit sind. Für jede Person speichern wir ihren eindeutigen person_code und Vor- und Nachnamen. Wir können natürlich weitere Details hinzufügen, wenn wir möchten.

Als nächstes definieren wir alle möglichen Rollen, die man während einer Hochzeit annehmen könnte. Zu diesen Rollen gehören „Gast“, „Trauzeuge“, „Trauzeuge“, „Brautjungfer“, „Braut“, „Bräutigam“ und so weiter. Für jede Rolle speichern wir nur den eindeutigen role_name in dieser Tabelle. Eine Person kann nur eine Rolle für eine bestimmte Hochzeit übernehmen.

Als nächstes werden wir Hochzeiten ihren Teilnehmern zuordnen. Beachten Sie, dass der participate Tabelle enthält nur Verweise auf die Tabellen wedding , person , und role . Die Kombination aus wedding_id und person_id dient als alternativer Schlüssel für diese Tabelle.

Die Hochzeit wird aus mehreren Veranstaltungen bestehen, an denen jedoch nicht alle Teilnehmer beteiligt sind. Daher müssen wir diese Informationen separat speichern. Im in_event table speichern wir eindeutige Paare von Fremdschlüsseln, die auf das event und participate . Alle weiteren Informationen werden in den details gespeichert Text zugeordnet.

Abschnitt 5:Rechnungen

Wir sind fast fertig! Der letzte Abschnitt unseres Datenmodells ermöglicht es uns, Ausgaben im Zusammenhang mit der Hochzeit zu verfolgen. Spannend, oder?

Normalerweise erstellen wir eine invoice pro Hochzeit, aber wir könnten bei Bedarf auch mehr generieren. Hoffentlich entspricht der Gesamtbetrag, den wir dem Ehepaar in Rechnung stellen, unserem geplanten Budget, aber das muss nicht immer der Fall sein. Für jede Rechnung speichern wir die folgenden Informationen:

• wedding_id – einen Hinweis auf die Hochzeit, für die die Rechnung ausgestellt wurde.
• time_created – der Zeitstempel für die Erstellung der Rechnung.
• due_date – das Datum, bis zu dem die Rechnung bezahlt werden muss.
• invoice_amount – der zu zahlende Gesamtbetrag.
• payment_time – der Zeitstempel, wann die Zahlung tatsächlich ausgestellt wurde. Natürlich enthält dieses Attribut bis zur Zahlung den Wert NULL.
• paid – ein Flag, das angibt, ob die Rechnung bezahlt wurde. Dieses Attribut wird auf „True“ gesetzt, sobald payment_time wird aktualisiert.

Die letzte Tabelle in unserem Modell betrifft die fakturierten Artikel selbst. Wir speichern diese im invoice_item Tisch. Für jeden Datensatz speichern wir die folgenden Details:

• item_name – unser gewählter Name für den bestimmten Artikel.
• item_price – der Preis, der sich auf diesen bestimmten Artikel bezieht.
• invoice_id – die ID der zugehörigen Rechnung.
• service_included_id – die ID der Dienstleistung, auf die sich die Rechnungsposition bezieht. Dieses Attribut kann auf NULL gesetzt werden, wenn sich der betreffende Artikel nicht wirklich auf eine Dienstleistung bezieht oder wenn es sich lediglich um eine zusätzliche Gebühr handelt, die wir auf die Rechnung angewendet haben.
• product_included_id – die ID des Produkts, auf das sich die Rechnungsposition bezieht. Dieses Attribut kann auf NULL gesetzt werden, wenn sich der betreffende Artikel nicht wirklich auf ein Produkt bezieht oder wenn es sich lediglich um eine zusätzliche Gebühr handelt, die wir der Rechnung hinzugefügt haben.

Zusammenfassung

Das fasst es ziemlich genau für dieses Datenmodell zusammen! Wieder einmal sehen wir, wie nützlich die Datenmodellierung bei der Organisation der Informationen eines Unternehmens ist.

Wie wir angemerkt haben, haben wir der Einfachheit halber viele Dinge aus unserem Datenmodell weggelassen. Zum Beispiel sollte unser Modell idealerweise Angebotshistorien, Finanzdetails und mehr verfolgen.

Teilen Sie uns unten mit, wenn Sie Vorschläge haben. Wir würden gerne Ihre Meinung hören!