Un modèle de données pour les fêtes d'enfants

Organiser des fêtes d'enfants n'est pas une mince affaire :tout doit être parfaitement planifié et livré. Sinon, le chaos se produit. C'est aux adultes - plus précisément aux organisateurs de fêtes - de s'occuper de tout et de le faire correctement.

Existe-t-il une meilleure façon de procéder que de tout organiser dans une base de données ? Nous ne pensons pas !

Les fêtes d'enfants varient beaucoup. Certaines sont simples, comme les fêtes d'anniversaire qui ne comprennent que des invitations, de la nourriture (des collations, des boissons et un gâteau) et peut-être un clown ou un magicien pour divertir les enfants. D'autres partis sont beaucoup plus complexes. Ils peuvent avoir besoin d'un voyage hors de la ville, d'un logement pour dormir et de nombreuses autres activités. Plus la fête est compliquée, moins il y a de place pour les erreurs. Même si un clown qui a 10 minutes de retard n'est pas un gros problème, personne ne veut attendre avec un groupe d'enfants qui s'ennuient un bus qui a deux heures de retard !

Voyons ce qu'un modèle de données peut faire pour aider les organisateurs de fêtes à rester organisés.

De quoi avons-nous besoin dans notre modèle de données ?

Supposons que nous dirigeons une entreprise de planification de fêtes. Nous aurons une liste des services que nous offrons aux clients. Ces services pourraient être fournis par nous, ou nous pourrions utiliser des partenaires (par exemple, nous engageons le clown).

Nous combinons ces services et les proposons aux clients sous forme de forfait de fête. Chaque package a un point de départ et d'arrivée, ou un calendrier. Cela inclut non seulement la fête elle-même, mais aussi la mise en place de la fête et le nettoyage par la suite. Nous pouvons également avoir plusieurs emplacements (par exemple, une fête commence par une pizza dans un restaurant, puis se déplace vers la plage pour la baignade).

Nous devrons également relier les activités aux employés, suivre les progrès des parties et facturer nos services. Voyons comment cela se fait.

Le modèle de données des fêtes d'enfants

Notre modèle de données sur les fêtes d'enfants comprend quatre domaines :

Countries & cities
Partners & services
Employees & roles
Party

Nous présenterons chaque domaine dans le même ordre qu'il est répertorié.

Section 1 :Pays et villes

Ce domaine ne contient que deux tableaux. Ils ne sont pas spécifiques à ce modèle, mais nous les utiliserons dans d'autres domaines.

Nous pouvons nous attendre à opérer dans plusieurs villes et peut-être même dans plusieurs pays. Par conséquent, nous devrons référencer différentes villes. Cela nous aidera à savoir où se trouvent les fêtes et quels services nous offrons à chaque endroit.

Le country dictionnaire contient uniquement le country_name UNIQUE valeur. Pour chaque city , nous stockerons la combinaison UNIQUE de postal_code – city_name – country_id .

Section 2 :Partenaires et services

Ensuite, détaillons les services que nous fournirons à nos clients.

Une liste de tous les services possibles est stockée dans le service dictionnaire. Il contient uniquement le service_name UNIQUE attribut.

Dans ce modèle de données, tous les services sont fournis par des partenaires. Même lorsque notre société fournit réellement le service, nous la traiterons comme un partner service (et nous sommes le partenaire). Le dictionnaire des partenaires stockera tous les partenaires avec lesquels nous travaillons, y compris nous. Pour chaque partenaire, nous stockerons un partner_name UNIQUE . Les details L'attribut stocke tous les détails supplémentaires liés à ce partenaire en utilisant un format non structuré ou structuré (par exemple, en utilisant des paires nom-valeur séparées par un séparateur prédéfini).

Le provides table est la table finale et la plus importante de cette section. Pour chaque enregistrement, nous stockerons :

partner_id – Le partner qui fournit un service.
service_id – Le service ce partenaire fournit.
city_id – Référence la city où ce service est fourni par ce partenaire.
date_from – La date à laquelle le partenaire a commencé à proposer ce service.
date_to – La date à laquelle le partenaire a cessé d'offrir ce service. Cette valeur peut être NULL si cette relation service-partenaire est toujours en cours.
details - Tous les détails supplémentaires liés à ce service, tels que la description du service, le prix, etc. Nous pouvons nous attendre à ce que tous les détails soient dans un format textuel structuré, en utilisant des paires clé-valeur.

La combinaison de partner_id – service_id – city_id – date_from forme la clé UNIQUE dans cette table. Lorsque nous entrons dans un nouvel enregistrement, nous devons vérifier qu'il ne chevauche aucun enregistrement existant.

Section 3 :Employés et rôles

Avant de passer à la partie centrale et la plus importante de notre modèle, nous devons examiner les tableaux relatifs à nos employés et à leurs rôles.

La table centrale dans ce domaine est le employee table. Pour chaque employé, nous stockerons son first_name , last_name , user_name et password . Ils utiliseront ces deux derniers attributs pour accéder à notre application.

Une liste de tous les rôles possibles est stockée dans le role dictionnaire. Chaque rôle est UNIQUEMENT défini par son role_name . Les rôles sont liés aux actions que chaque employé effectue lors d'une fête. Par conséquent, nous pouvons nous attendre à des valeurs telles que "gestionnaire de fête" ou "assistant" ici.

Les rôles peuvent être attribués aux employés au moyen du has_role table. Le employee_id – role_id paire indiquera les rôles actifs de chaque employé à ce moment.

Section 4 :Fête

La Party domaine est la partie centrale de ce modèle. Nous l'utiliserons pour relier des tableaux d'autres domaines, et nous aurons également de nouvelles informations ici.

La table centrale ici est le party table. Pour chaque fête, nous stockerons :

city_id – La city où la fête aura lieu.
client_id – Le client cette fête est organisée.
details – Une description textuelle détaillée de la fête.
start_time_planned et end_time_planned – L'heure que nous avons prévue pour cette fête, y compris l'installation et le nettoyage.
start_time_actual et end_time_actual – Les heures réelles de la fête (et de ses services associés).
price_offered – Le prix que nous avons proposé pour organiser cette fête pour ce client.
time_offered – Quand l'offre a été faite.
price_paid – Le montant réel que le client a payé pour cette fête.
time_paid – Quand le paiement a été effectué.

Chaque partie est liée à un client. Nous avons déjà référencé le client table, mais maintenant nous allons voir ce qui y est stocké. Je suis allé avec des données de base uniquement :client_name , coordonnées (address , email , phone , mobile ), et tout détail supplémentaire sous forme textuelle.

Chaque partie aura également une liste de services qui lui sont associés. Cette liste est stockée dans le service_included table. Pour chaque enregistrement, nous aurons besoin :

party_id – Fait référence à la party .
service_id – Fait référence au service inclus dans la fête.
provides_id – Référence le provider de ce service, ainsi que le service lui-même. Cet attribut peut être NULL, car nous le mettrons à jour lorsque nous sélectionnerons le fournisseur spécifique.
details – Tous les détails textuels supplémentaires liés à ce service dans cette partie.
start_time_planned et end_time_planned – Les heures prévues auxquelles le service doit être fourni pendant la fête.

Nous devrons également suivre les progrès de chaque partie. Nous utiliserons deux tables pour ce faire.

Le status listera tous les statuts possibles pouvant être attribués à une partie. Pour chaque enregistrement, nous stockerons un status_name UNIQUE et trois drapeaux :

successful - Tout s'est bien passé ? Ou y a-t-il eu des problèmes avec nos services ?
paid – La fête a-t-elle été payée ?
final – Est-ce le statut final pour cette fête ?

Nous attribuerons des statuts aux services en ajoutant de nouveaux enregistrements au party_status table. Pour chaque enregistrement, nous stockerons les références à la party et service tables et le timestamp lorsque ce statut a été attribué.

La table finale de notre modèle est la invoice table. Ce n'est pas spécifique à ce modèle, mais nous avons besoin d'une structure de base pour stocker les factures. Pour chaque facture, nous enregistrerons :

client_name – Le nom du client au moment de l'émission de la facture.
party_id – La party lié à cette facture.
client_id – L'identifiant du client en cours de facturation.
invoice_amount , discount , vat_amount , total_amount – Les détails financiers de la facture.
time_issued - Quand cette facture a été émise ou ajoutée à la base de données.
time_paid - Quand cette facture a été payée.

Que feriez-vous avec ce modèle de données ?

Ce modèle est assez simple, mais je vois plusieurs façons de l'améliorer. Quels changements proposeriez-vous ? Y a-t-il quelque chose que nous pourrions organiser différemment ? Peut-être devons-nous ajouter ou supprimer une fonctionnalité. Veuillez nous le dire dans les commentaires.