Ein Kinderparty-Datenmodell

Kinderfeste zu organisieren ist keine leichte Aufgabe:Alles muss perfekt geplant und durchgeführt werden. Sonst passiert Chaos. Es liegt an den Erwachsenen – genauer gesagt den Partyplanern – sich um alles zu kümmern und es richtig zu machen.

Gibt es einen besseren Weg, dies zu tun, als alles in einer Datenbank zu organisieren? Das glauben wir nicht!

Kinderfeste sind sehr unterschiedlich. Einige sind einfach, wie Geburtstagsfeiern, die nur Einladungen, Essen (Snacks, Getränke und Kuchen) und vielleicht einen Clown oder einen Zauberer beinhalten, um die Kinder zu unterhalten. Andere Parteien sind viel komplexer. Sie benötigen möglicherweise einen Ausflug aus der Stadt, Schlafgelegenheiten und viele andere Aktivitäten. Je komplizierter die Party, desto weniger Raum für Fehler. Während ein Clown mit 10 Minuten Verspätung keine große Sache ist, möchte niemand mit einer Gruppe gelangweilter Kinder auf einen Bus warten, der zwei Stunden Verspätung hat!

Mal sehen, was ein Datenmodell tun kann, um Partyplanern zu helfen, organisiert zu bleiben.

Was brauchen wir in unserem Datenmodell?

Nehmen wir an, wir betreiben ein Partyplanungsunternehmen. Wir haben eine Liste der Dienstleistungen, die wir unseren Kunden anbieten. Diese Dienste können von uns bereitgestellt werden oder wir könnten Partner verwenden (z. B. wir engagieren den Clown).

Wir bündeln diese Leistungen und bieten sie Kunden als Partypaket an. Jedes Paket hat einen Start- und Endpunkt oder Zeitplan. Dazu gehört nicht nur die Party selbst, sondern auch der Aufbau der Party und das anschließende Aufräumen. Wir können auch mehrere Standorte haben (z. B. eine Party beginnt mit Pizza in einem Restaurant und zieht dann zum Schwimmen an den Strand).

Wir müssen auch Aktivitäten mit Mitarbeitern in Beziehung setzen, den Fortschritt der Parteien verfolgen und unsere Dienstleistungen in Rechnung stellen. Mal sehen, wie das gemacht wird.

Das Kinderparty-Datenmodell

Unser Kinderfest-Datenmodell besteht aus vier Themenbereichen:

• Countries & cities
• Partners & services
• Employees & roles
• Party

Wir stellen jeden Themenbereich in der gleichen Reihenfolge vor, in der er aufgelistet ist.

Abschnitt 1:Länder und Städte

Dieser Themenbereich enthält nur zwei Tabellen. Sie sind nicht spezifisch für dieses Modell, aber wir werden sie in anderen Themenbereichen verwenden.

Wir können damit rechnen, in mehreren Städten und vielleicht sogar in mehreren Ländern tätig zu sein. Daher müssen wir auf verschiedene Städte verweisen. Dies hilft uns zu verfolgen, wo sich die Parteien befinden und welche Dienstleistungen wir an jedem Standort anbieten.

Das country Wörterbuch enthält nur den EINZIGARTIGEN country_name Wert. Für jede city speichern wir die EINZIGARTIGE Kombination von postal_code – city_name – country_id .

Abschnitt 2:Partner und Dienste

Lassen Sie uns als Nächstes die Dienstleistungen beschreiben, die wir unseren Kunden anbieten.

Eine Liste aller möglichen Dienste ist im service Wörterbuch. Es enthält nur den EINZIGARTIGEN service_name Attribut.

In diesem Datenmodell werden alle Dienste von Partnern bereitgestellt. Selbst wenn unser Unternehmen den Service tatsächlich bereitstellt, behandeln wir es als partner Service (und wir sind der Partner). Das Partnerwörterbuch speichert alle Partner, mit denen wir zusammenarbeiten, einschließlich uns. Für jeden Partner speichern wir einen EINZIGARTIGEN partner_name . Die details Das Attribut speichert alle zusätzlichen Details zu diesem Partner in einem unstrukturierten oder strukturierten Format (z. B. unter Verwendung von Name-Wert-Paaren, die durch ein vordefiniertes Trennzeichen getrennt sind).

Der provides Tabelle ist die letzte und wichtigste Tabelle in diesem Abschnitt. Für jeden Datensatz speichern wir:

• partner_id – Der partner die einen Dienst bereitstellt.
• service_id – Der service dieser Partner bietet.
• city_id – Verweist auf city wo dieser Service von diesem Partner bereitgestellt wird.
• date_from – Das Datum, an dem der Partner begonnen hat, diesen Service anzubieten.
• date_to – Das Datum, an dem der Partner diesen Dienst nicht mehr anbietet. Dieser Wert könnte NULL sein, wenn diese Service-Partner-Beziehung noch andauert.
• details – Alle zusätzlichen Details zu diesem Service, wie z. B. Servicebeschreibung, Preis usw. Wir können davon ausgehen, dass alle Details in einem strukturierten Textformat unter Verwendung von Schlüssel-Wert-Paaren vorliegen.

Die Kombination aus partner_id – service_id – city_id – date_from bildet in dieser Tabelle den UNIQUE-Schlüssel. Wenn wir einen neuen Datensatz eingeben, sollten wir prüfen, dass er sich nicht mit bestehenden Datensätzen überschneidet.

Abschnitt 3:Mitarbeiter und Rollen

Bevor wir zum zentralen und wichtigsten Teil unseres Modells übergehen, müssen wir uns die Tabellen ansehen, die sich auf unsere Mitarbeiter und ihre Rollen beziehen.

Die zentrale Tabelle in diesem Themenbereich ist der employee Tisch. Für jeden Mitarbeiter speichern wir seinen first_name , last_name , user_name und password . Sie verwenden diese letzten beiden Attribute, um auf unsere Anwendung zuzugreifen.

Eine Liste aller möglichen Rollen ist im role Wörterbuch. Jede Rolle wird EINZIGARTIG durch ihren role_name definiert . Rollen beziehen sich auf Aktionen, die jeder Mitarbeiter während einer Party ausführt. Daher können wir hier Werte wie „Partymanager“ oder „Assistent“ erwarten.

Rollen können Mitarbeitern über den has_role Tisch. Die employee_id – role_id Paar bezeichnet die aktiven Rollen, die jeder Mitarbeiter zu diesem Zeitpunkt hat.

Abschnitt 4:Partei

Die Party Fachgebiet ist der zentrale Teil dieses Modells. Wir werden es verwenden, um Tabellen aus anderen Themenbereichen zu verknüpfen, und wir werden auch hier einige neue Informationen haben.

Der zentrale Tisch hier ist die Party Tisch. Für jede Party speichern wir:

• city_id – Die city wo die Party stattfinden wird.
• client_id – Der client diese Party wird organisiert für.
• details – Eine ausführliche Textbeschreibung der Party.
• start_time_planned und end_time_planned – Die Zeit, die wir für diese Party geplant haben, einschließlich Aufbau und Reinigung.
• start_time_actual und end_time_actual – Die tatsächlichen Zeiten, zu denen die Party (und die damit verbundenen Dienste) stattfanden.
• price_offered – Der Preis, den wir angeboten haben, um diese Party für diesen Kunden zu organisieren.
• time_offered – Wann das Angebot gemacht wurde.
• price_paid – Der tatsächliche Betrag, den der Kunde für diese Partei bezahlt hat.
• time_paid – Wann die Zahlung erfolgt ist.

Jede Partei ist mit einem Kunden verbunden. Wir haben bereits auf client Tabelle, aber jetzt werden wir sehen, was dort gespeichert ist. Ich habe nur grundlegende Daten verwendet:client_name , Kontaktdaten (address , email , phone , mobile ) und alle zusätzlichen Details im Textformat.

Jede Partei wird auch eine Liste von Diensten haben, die ihr zugeordnet sind. Diese Liste wird in service_included Tisch. Für jeden Datensatz benötigen wir:

• party_id – Verweist auf die zugehörige Party .
• service_id – Verweist auf den service in die Partei aufgenommen.
• provides_id bereit – Verweist auf den provider dieses Dienstes sowie den Dienst selbst. Dieses Attribut kann NULL sein, da wir es aktualisieren, wenn wir den spezifischen Anbieter auswählen.
• details – Alle zusätzlichen Textdetails in Bezug auf diesen Dienst in dieser Partei.
• start_time_planned und end_time_planned – Die geplanten Zeiten, zu denen der Service während der Party erbracht werden soll.

Wir müssen auch den Fortschritt jeder Partei verfolgen. Dazu verwenden wir zwei Tabellen.

Der status listet alle möglichen Status auf, die einer Partei zugeordnet werden können. Für jeden Datensatz speichern wir einen EINZIGARTIGEN status_name und drei Flags:

• successful – Hat alles geklappt? Oder gab es Probleme mit unseren Services?
• paid – Ist die Party bezahlt?
• final – Ist dies der endgültige Status für diese Partei?

Wir weisen Diensten Status zu, indem wir neue Datensätze zum party_status Tisch. Für jeden Datensatz speichern wir Verweise auf die Party und service Tabellen und den timestamp wann dieser Status zugewiesen wurde.

Die letzte Tabelle in unserem Modell ist die invoice Tisch. Es ist nicht spezifisch für dieses Modell, aber wir brauchen eine grundlegende Struktur, um Rechnungen zu speichern. Für jede Rechnung erfassen wir:

• client_name – Name des Kunden zum Zeitpunkt der Rechnungsstellung.
• party_id – Die Party im Zusammenhang mit dieser Rechnung.
• client_id – Die ID des client in Rechnung gestellt.
• invoice_amount , discount , vat_amount , total_amount – Die finanziellen Details der Rechnung.
• time_issued - Wann diese Rechnung ausgestellt oder in die Datenbank aufgenommen wurde.
• time_paid - Wann diese Rechnung bezahlt wurde.

Was würden Sie mit diesem Datenmodell machen?

Dieses Modell ist ziemlich einfach, aber ich sehe mehrere Möglichkeiten, wie wir es verbessern können. Welche Änderungen würden Sie vorschlagen? Gibt es etwas, das wir anders organisieren könnten? Vielleicht müssen wir eine Funktion hinzufügen oder entfernen. Bitte teilen Sie uns dies in den Kommentaren mit.