Les mariages sont souvent accompagnés de gaieté et de célébration, avec de nombreux invités, de la nourriture, des boissons, de la musique et de la danse. Mais tout cela ne peut se faire sans une préparation et une coordination adéquates. Examinons de plus près comment la modélisation des données peut nous aider à mieux organiser un mariage pour que tout se passe bien.
Contexte préliminaire
Bien que nous sachions tous à quoi ressemble une cérémonie de mariage typique, cela ne peut pas faire de mal d'examiner brièvement certains aspects qui pourraient potentiellement avoir un impact sur notre modèle de données.
Partenaires de mariage
Bien que la plupart des cultures traditionnelles aient des cérémonies entre un homme et une femme, les mariages homosexuels ont également lieu dans d'autres sociétés. Notre modèle de données doit être conçu de manière à s'adapter à toutes les possibilités.
Échelle et complexité
Les cérémonies de mariage varient considérablement dans leur taille, leur durée et leur complexité. Certaines sont de petites occasions modestes, mais d'autres sont de grandes célébrations. En Croatie, par exemple, vous pouvez organiser une simple cérémonie de mariage où un couple se marie à la mairie, échange ses alliances et ses vœux devant ses invités, puis assiste à un dîner après la cérémonie ou rentre chez lui. Dans d'autres pays, les mariages peuvent être assez élaborés :ils peuvent impliquer des enterrements de vie de garçon/de jeune fille, des négociations, des dîners, de multiples cérémonies, etc. Dans certains cas, ces cérémonies peuvent durer plusieurs jours et se dérouler dans quelques endroits différents ! Encore une fois, notre modèle de données doit être prêt à gérer ces situations.
Résultat final et dépenses
Dans la plupart des cas, le couple se marie après la célébration et reçoit une facture pour tous les frais (loyer, nourriture et boissons, orchestre, etc.). Ils peuvent décider de faire appel à une agence pour prendre en charge tous ces frais à leur place, ou ils peuvent choisir de tout gérer eux-mêmes. Dans tous les cas, nous devons tenir compte de ces situations.
Le modèle de données :présentation
Notre modèle de données pour cet article se compose de cinq sections :
- Lieux
- Partenaires, produits et services
- Mariages
- Participants
- Factures
Nous discuterons en détail de chacun de ces domaines dans l'ordre dans lequel ils sont énumérés ci-dessus. Pendant que nous travaillons au développement de notre modèle de données, nous assumerons le rôle de l'agence organisatrice du mariage.
Section 1 :Emplacements
Les Locations présente des tables universelles qui peuvent être utilisées dans de nombreux autres modèles de données. Comme nous l'avons noté précédemment, toute la cérémonie de mariage peut avoir lieu à un seul endroit, ou elle peut potentiellement s'étendre sur plusieurs endroits. Discutons plus en détail des tableaux de cette section.
Le country table stocke des informations sur le pays dans lequel le mariage a lieu. Dans la plupart des cas, ce pays correspondra à l'emplacement de notre agence, mais cela peut ne pas être le cas si nous opérons à l'international. Chaque pays de ce tableau est défini de manière unique par son country_name .
Ensuite, nous devons stocker la liste de toutes les villes et/ou villages où le mariage sera organisé. Ces informations seront stockées dans la city table. Pour chaque ville, nous enregistrerons son nom et son code postal, ainsi que le pays dans lequel elle se trouve.
Le dernier tableau de ce domaine est location . Les emplacements sont plus spécifiques, tels que les mairies, les églises, les parcs, etc. Pour chaque emplacement, nous stockerons son nom et une référence à l'ID de la ville dans laquelle il se trouve. La combinaison de ces deux attributs forme la clé unique de cette table.
Pour les lieux, notez que nous avons adopté une approche conservatrice ici pour éviter de couvrir les cas inhabituels dans lesquels la cérémonie se déroule, par exemple, dans un train ou un avion (auquel cas, le "lieu" peut impliquer plusieurs villes). Si nous souhaitons couvrir ces cas, nous aurions besoin d'apporter quelques modifications à notre modèle.
Section 2 :Partenaires, produits et services
Avant de passer à la partie centrale de notre modèle de données, nous devons stocker la liste de tous les partenaires avec lesquels nous travaillons, ainsi que les produits et services qu'ils proposent. Pour y parvenir, nous utiliserons cinq tables.
Tout d'abord, la liste de tous les partenaires avec lesquels nous travaillons est stockée dans le partner dictionnaire. Pour chaque partenaire, nous stockerons son partner_code unique et partner_name .
Bien sûr, nos partenaires fourniront des services liés au mariage, qui pourraient inclure la restauration, l'organisation de groupes, la mise en place d'équipements audio et vidéo, la fourniture d'un soutien au loyer, et bien plus encore. Essentiellement, tout ce à quoi vous pouvez penser peut potentiellement être lié à un mariage d'une manière ou d'une autre. Nous stockerons cette liste de services dans le service dictionnaire. Pour chaque service, nous stockerons :
service_code- une valeur que nous utiliserons en interne pour désigner de manière unique un service particulier.service_name– nom du service. Notez que différents services peuvent partager le même nom. Cela se produirait si deux de nos partenaires offraient le même service, ce qui est fort probable. Il serait même souhaitable qu'ils utilisent le même nom pour le même type de service, car cela faciliterait grandement la comparaison des prix pour les mêmes services.description– une description textuelle facultative du service.picture– un lien vers l'emplacement où l'image de service associée est stockée.price– le prix actuel de ce service. Il peut contenir la valeur NULL si le prix ne peut pas être déterminé sans évaluer au préalable divers facteurs, tels que le nombre de personnes qui prévoient d'assister à la cérémonie.
Le provides_service tableau relie les partenaires à la liste des services qu'ils fournissent. Pour chaque combinaison unique de partner_id et service_id , nous stockerons une description textuelle détaillée de la nature du service fourni par le partenaire et si le service est actuellement disponible.
Nous avons également besoin de tables pour stocker des informations sur les produits et leurs relations avec les partenaires. Le product table suit la même logique que le service table, sauf que, comme son nom l'indique, elle est spécifique aux produits. Dans ce tableau, nous stockerons tous les produits possibles qui sont essentiels à la plupart des cérémonies de mariage, tels que les bagues, les tenues, les décorations, les fleurs, les meubles, etc.
Le dernier tableau de cette section est le provides_product table. Cela fonctionne exactement comme le provides_service tableau, sauf qu'il est spécifique aux produits par opposition aux services. Il précise lequel de nos partenaires propose le produit en question.
Section 3 :Mariages
Nous sommes enfin arrivés au cœur de notre modèle de données :les Weddings section. Il contient cinq nouveaux tableaux qui font référence aux tableaux d'autres sections. Notez que les tableaux de cette section seront également référencés dans les prochaines parties de notre modèle.
Au wedding table, nous conserverons la liste complète de tous les mariages que nous sommes/avons été impliqués dans l'organisation. Chaque mariage se verra attribuer son propre wedding_code . Nous stockerons également les heures de début et de fin prévues pour l'ensemble de la cérémonie, et nous mettrons à jour les heures de début et de fin réelles chaque fois que ces informations seront disponibles. De plus, nous stockerons le budget_planned valeur afin que nous ayons au moins une estimation de combien tout cela coûtera. Tous les autres détails liés au mariage sont stockés dans d'autres zones du modèle de données, c'est donc tout ce dont nous avons vraiment besoin pour le moment.
L'idée ici est de traiter chaque mariage comme une série d'événements. Les événements seront à leur tour liés aux offres de produits/services souhaités, aux offres rejetées et acceptées, et à d'autres détails pertinents. Pour vous donner une meilleure idée de la façon dont tout cela fonctionne, nous pourrions diviser l'ensemble du mariage en les événements suivants :phase de planification, enterrements de vie de garçon/enterrement de vie de garçon, cérémonie et after-party/dîner. Bien sûr, ce ne sont là que quelques-uns des événements de mariage les plus courants. Tous les événements de mariage sont stockés dans la table des événements. Un event aura un identifiant unique.
Chaque événement est associé à un seul mariage, et il sera soit lié à un lieu, soit à aucun. Ce dernier cas se présente si l'événement est plus conceptuel , comme la phase de planification (puisqu'il n'y a pas de lieu unique où elle doit avoir lieu). Comme pour la cérémonie de mariage proprement dite, un événement aura des heures de début et de fin prévues et réelles, ainsi qu'un budget prévu. Notez que nous avons gardé les choses simples ici en ce qui concerne les emplacements. Si les événements impliquent plusieurs emplacements, nous devrons ajuster notre modèle de données.
Ensuite, nous voulons stocker tous les services et produits liés à un événement. Pour ce faire, nous utiliserons trois tables :status , product_included , et service_included .
Le status table est un dictionnaire qui garde une trace de tous les statuts liés aux produits et services pour un événement particulier. Il comprend des variables d'indicateur qui indiquent si un produit/service a été offert, accepté ou rejeté. Pour chaque enregistrement de cette table, nous stockerons un status_name unique .
Les deux tableaux restants de cette section, intitulés product_included et service_included , se ressemblent structurellement et conceptuellement. Pour chaque événement, nous stockons la liste des produits et services qui ont été offerts et changeons leurs statuts s'ils sont acceptés ou rejetés. Pour chaque enregistrement de ces deux tables, nous stockerons les attributs communs suivants :
event_id– une référence à l'événement associé.provides_product_id/provides_service_id– références aux tableaux de produits/services proposés par nos partenaires.price– prix proposé pour le produit/service. Ce prix peut différer du prix standard que nous avons au dossier si nous proposons une offre spéciale.current_status_id– une référence austatusdictionnaire indiquant si cet enregistrement a été proposé, accepté ou rejeté.
Section 4 :Participants
Si vous organisez un grand mariage, il y a de fortes chances que vous connaissiez la plupart des invités qui prévoient d'y assister. Bien sûr, les invités que vous invitez, qu'il s'agisse de vos amis ou de votre famille, amèneront probablement d'autres personnes que vous ne connaissez pas personnellement, comme leurs amis ou leurs collègues. Dans cette section, nous stockerons la liste complète des invités qui ont été invités au mariage, ainsi que leurs rôles.
La person table contient une liste de toutes les personnes qui font partie du mariage. Pour chaque individu, nous stockerons son person_code unique et noms et prénoms. Nous pouvons bien sûr ajouter plus de détails si nous le souhaitons.
Ensuite, nous définirons tous les rôles possibles que l'on pourrait assumer lors d'un mariage. Ces rôles incluent «invité», «meilleur homme», «garçon d'honneur», «demoiselle d'honneur», «mariée», «marié», etc. Pour chaque rôle, nous ne stockerons que l'unique role_name dans ce tableau. Une personne ne peut assumer qu'un seul rôle pour un mariage particulier.
Ensuite, nous relierons les mariages à leurs participants. Notez que le participate table ne contient que des références aux tables wedding , person , et role . La combinaison de wedding_id et person_id sert de clé alternative pour cette table.
Le mariage consistera en plusieurs événements, mais tous les participants ne seront pas impliqués dans ceux-ci. Par conséquent, nous devons stocker ces informations séparément. Dans le in_event table, nous stockerons des paires uniques de clés étrangères référençant les tables event et participate . Toutes les informations supplémentaires seront stockées dans les details texte attribué.
Section 5 :Factures
Nous avons presque terminé ! La dernière section de notre modèle de données nous permet de suivre les dépenses liées au mariage. Excitant, non ?
Nous générons généralement une invoice par mariage, mais nous pourrions également en générer davantage si nous en avions besoin. Espérons que le montant total que nous facturons au couple corresponde étroitement à notre budget prévu, mais ce n'est peut-être pas toujours le cas. Pour chaque facture, nous stockons les informations suivantes :
wedding_id– une référence au mariage pour lequel la facture a été émise.time_created– l'horodatage de la génération de la facture.due_date– la date à laquelle la facture doit être payée.invoice_amount– le montant total qui doit être payé.payment_time– l'horodatage de l'émission effective du paiement. Bien sûr, cet attribut contiendra une valeur NULL jusqu'à ce que le paiement soit effectué.paid– un indicateur indiquant si la facture a été payée. Cet attribut sera défini sur "True" dès que lepayment_timeest mis à jour.
Le dernier tableau de notre modèle concerne les articles facturés eux-mêmes. Nous les stockerons dans le invoice_item table. Pour chaque enregistrement, nous stockerons les détails suivants :
item_name- notre nom choisi pour l'élément spécifique.item_price– le prix lié à cet article spécifique.invoice_id– l'identifiant de la facture associée.service_included_id– l'identifiant du service auquel l'élément de facture est lié. Cet attribut peut être défini sur NULL si l'article en question n'est en fait lié à aucun service ou s'il s'agit simplement d'un supplément que nous avons appliqué à la facture.product_included_id– l'identifiant du produit auquel se rapporte l'élément de facture. Cet attribut peut être défini sur NULL si l'article en question n'est en fait lié à aucun produit ou s'il s'agit simplement d'un supplément que nous avons appliqué à la facture.
Résumé
Cela résume à peu près tout pour ce modèle de données ! Une fois de plus, nous voyons à quel point la modélisation des données est utile dans l'organisation des informations d'une entreprise.
Comme nous l'avons noté, il y a beaucoup de choses que nous avons omises de notre modèle de données par souci de simplicité. Par exemple, notre modèle devrait idéalement suivre les historiques des offres, les détails financiers, etc.
Faites-nous savoir ci-dessous si vous avez des suggestions. Nous serions ravis de connaître votre opinion !
