1. Introduction

Après avoir défini les besoins pour l’application Hairbnb à travers une analyse métier rigoureuse (j’estime ou bien j’espère) et puis une modélisation systémique détaillée, il est désormais essentiel de structurer l’information de manière formelle au niveau des données.

Cette étape constitue le fondement de la persistance et de la cohérence de l’information manipulée au sein de l’application.

L’objectif principal de ce chapitre est donc de passer de la logique fonctionnelle exprimée dans les cas d’utilisation et les interactions (acteurs, scénarios, échanges) à une modélisation rigoureuse de la base de données, basée sur la méthode MERISE.

Cette approche permettra de :

  • Structurer les entités clés du domaine (clients, coiffeuses, salons, services, réservations, etc.).

  • Définir les relations logiques entre ces entités.

  • Assurer l’intégrité des données, leur non-redondance et leur accessibilité optimale.

  • Servir de passerelle vers l’implémentation physique de la base dans PostgreSQL, en lien avec le backend Django.

Ce chapitre s’articule autour des différents niveaux de modélisation MERISE :

  • Modèle Conceptuel des Données (MCD) : représentation des entités et de leurs relations, indépendamment de toute technologie.

  • Modèle Logique des Données (MLD) : traduction en tables relationnelles normalisées.

  • Modèle Physique des Données (MPD) : adaptation aux contraintes du SGBD cible (ici, PostgreSQL).

Ce travail de modélisation sera guidé par les exigences fonctionnelles déjà exposées dans les chapitres précédents.

Il garantira que chaque fonctionnalité (création de profil, réservation, gestion de profil, etc.) repose sur une structure de données robuste, évolutive et sécurisée.

Je dois avouer que cette partie de l’analyse a été l’une des plus difficiles à aborder lors du développement du projet Hairbnb.

N’étant ni un expert en modélisation de données, ni un professionnel aguerri du secteur, j’ai dû franchir un véritable cap entre la lecture initiale du cahier des charges et la version finale du schéma de base de données que j’ai pu concevoir.

Ce processus a été jalonné d’allers-retours, de remises en question et de restructurations profondes.

En effet, chaque fois qu’une anomalie apparaissait dans la structure de la base ou que l’architecture ne répondait pas aux besoins réels ou aux normes de cohérence des données, cela nécessitait de revenir en arrière et de modifier l’ensemble des couches de l’application – de la base de données au backend, jusqu’à l’interface utilisateur.

Ce cheminement, bien que complexe, m’a permis de mieux comprendre les enjeux de la cohérence et de la robustesse d’une architecture de données, et l’importance d’une analyse préalable bien conduite.

— Retour d’expérience personnel - El khyari soulaiman

2. Qu’est-ce que la méthode MERISE ?

2.1. Définition

MERISE (prononcer /mə.ʁiz/) est une méthode française d’analyse, de conception et de gestion de projet informatique développée dans les années 1970.

Elle constitue une approche systématique pour concevoir et réaliser des systèmes d’information en séparant clairement les données et les traitements.

Origine du nom : Contrairement aux idées reçues, MERISE n’est pas un acronyme.
Le nom vient de l’analogie avec le merisier "qui ne peut porter de beaux fruits que si on lui greffe une branche de cerisier : ainsi en va-t-il des méthodes informatiques bien conçues, qui ne produisent de bons résultats que si la greffe sur l’organisation réussit.

J’ai adoré cette information, et je voulais la partager.

— idée - EL khyari soulaiman

2.2. Historique et contexte

2.2.1. Origine (1970-1980)

  • Créateurs : René Colletti, Arnold Rochfeld et Hubert Tardieu.

  • Contexte : Demande du Ministère de l’Industrie français pour une méthode nationale

À une époque où les ministères jouaient pleinement leur rôle.

— Point de vue personnel - EL khyari soulaiman

  • Inspiration : Basée sur les travaux d’Edgar Frank Codd sur le modèle relationnel.

  • Objectif : Répondre aux besoins de l’informatisation massive des organisations.

2.2.2. Évolution

  • 1979 : Publication officielle par le Ministère de l’Industrie.

  • Années 1980 : Adoption massive en France, notamment dans les administrations.

  • Années 1990 : Tentatives d’adaptation (MERISE/objet, MERISE/2).

  • Aujourd’hui : Toujours utilisée, particulièrement pour les projets internes.

2.3. Principe fondamental

MERISE repose sur le principe de séparation des données et des traitements à chaque niveau d’analyse.
Cette approche permet de :

  • Clarifier la complexité des systèmes d’information.

  • Faciliter la communication entre utilisateurs et informaticiens.

  • Structurer la démarche de conception.

  • Garantir la cohérence du système final.

2.4. Les trois cycles de MERISE

La méthode MERISE s’articule autour de trois cycles complémentaires :

2.4.1. Cycle de vie

Phases successives du projet :

  • Conception : définition du système

  • Réalisation : développement et implémentation

  • Maintenance : exploitation et évolution

2.4.2. Cycle de décision

Niveaux de prise de décision :

  • Grandes décisions (GO/NO GO) : étude préalable.

  • Définition du projet : étude détaillée.

  • Petites décisions : détails de réalisation.

2.4.3. Cycle d’abstraction

Quatre niveaux d’abstraction (du plus abstrait au plus concret) :

Niveau Conceptuel

Objectif : Modéliser le métier indépendamment des contraintes Outils : MCD (Modèle Conceptuel des Données) MCT (Modèle Conceptuel des Traitements)

Niveau Organisationnel

Objectif : Définir l’organisation du travail

  • Outils :

    • MOD (Modèle Organisationnel des Données).

    • MOT (Modèle Organisationnel des Traitements).

Niveau Logique

Objectif : Préciser l’implémentation sans choix technique final

  • Outils :

    • MLD (Modèle Logique des Données).

    • MLT (Modèle Logique des Traitements).

Niveau Physique

Objectif : Définir l’implémentation technique réelle

  • Outils :

    • MPD (Modèle Physique des Données).

    • MOT (Modèle Opérationnel des Traitements).

2.5. Focus sur la modélisation des données

Pour la conception de bases de données, MERISE suit une progression logique :

Étape Description Livrable

Recensement

Inventaire des données et dépendances fonctionnelles

Dictionnaire de données

Conceptuel

Modélisation abstraite (entités, relations, cardinalités)

MCD

Logique

Transformation vers le modèle relationnel

MLD

Physique

Implémentation dans un SGBD spécifique

MPD

2.6. Avantages de la méthode MERISE

2.6.1. Points forts

  • Communication facilitée entre métier et informatique.

  • Démarche structurée et progressive.

  • Séparation claire données/traitements.

  • Traçabilité des décisions.

  • Robustesse des modèles produits.

2.6.2. Domaines d’application privilégiés

  • Projets internes aux organisations.

  • Systèmes de gestion complexes.

  • Refonte d’applications existantes.

  • Administrations et secteur public.

2.7. Limites et critiques

2.7.1. Inconvénients

  • Lourdeur de la démarche (critiquée dans les années 1990).

  • Méthode séquentielle peu adaptée aux projets agiles.

  • Spécificité française limitant l’adoption internationale.

  • Difficulté d’adaptation aux nouvelles technologies.

2.7.2. Concurrence

  • Méthodes anglo-saxonnes : SSADM, SDM/S, Axial.

  • Approches modernes : UML, méthodes agiles.

  • Progiciels avec leurs propres méthodologies.

2.8. MERISE vs autres approches

Critère MERISE UML Agile

Origine

France, années 1970

États-Unis, années 1990

États-Unis, années 2000

Approche

Séquentielle, structurée

Orientée objet, flexible

Itérative, collaborative

Focus

Données + Traitements

Objets + Interactions

Fonctionnalités + Utilisateur

Adaptation

Projets internes, SI complexes

Développement logiciel OO

Projets courts, évolutifs

2.9. Position de MERISE aujourd’hui

2.9.1. Utilisation actuelle

  • Formation : Enseignée dans les cursus informatiques français.

  • Secteur public : Encore largement utilisée.

  • Conception BD : Référence pour la modélisation des données.

  • Projets patrimoniaux : Maintenance de systèmes existants.

2.9.2. Évolution

  • Hybridation avec d’autres méthodes.

  • Outils CASE modernisés.

  • Adaptation aux architectures SOA et microservices.

MERISE reste pertinente pour la modélisation conceptuelle des données et constitue un excellent outil pédagogique pour comprendre les fondements de la conception de systèmes d’information, même si elle n’est plus la méthode de référence pour les projets agiles modernes.[1]

La seule chose que je pourrais ajouter à la définition classique de la méthode Merise, c’est la difficulté à trouver aujourd’hui des outils adaptés pour travailler efficacement avec cette méthode.
Il me semble qu’il n’existe pas vraiment d’alternatives modernes et accessibles.

Le logiciel Win’Design, historiquement associé à Merise, reste très ancien, et aucune version récente n’a vu le jour.

Cela limite parfois l’ergonomie et la compatibilité avec les environnements de développement actuels.

— Remarque personnelle sur les outils Merise - El khayri soulaiman

3. Modèle Conceptuel des Données (MCD)

3.1. Qu’est-ce que le modèle conceptuel des données (MCD) ?

3.1.1. Définition

Le Modèle Conceptuel des Données (MCD) est une représentation abstraite, visuelle et simplifiée de l’ensemble des données d’un système d’information.

Il s’agit d’un outil de modélisation qui permet de décrire de façon formelle les données qui seront utilisées par le système d’information, en se concentrant sur la structure logique des informations sans entrer dans les détails techniques d’implémentation.

3.1.2. Objectifs du MCD

  • Le MCD a pour principaux objectifs de :

    • Fournir une vue globale des données du système d’information.

    • Faciliter la compréhension des relations entre les différents types de données.

    • Permettre l’échange entre informaticiens et non-informaticiens sur l’outil à informatiser.

    • Servir de base pour la conception des étapes suivantes (MLD et MPD).

    • Valider et préciser les règles métier qui s’appliqueront à la future base de données

3.1.3. Composants essentiels

Le MCD se construit sur la base de trois éléments centraux :

Entités

  • Représentent les objets ou concepts du monde réel que l’on souhaite modéliser dans le système d’information.

  • Une entité est un ensemble d’éléments de même nature.

Attributs

  • Caractéristiques ou propriétés qui décrivent les entités.

  • Chaque entité possède un ou plusieurs attributs qui la définissent.

Relations (Associations)

  • Liens logiques entre deux ou plusieurs entités, indiquant comment ces entités se rapportent ou interagissent entre elles.

  • Les relations peuvent avoir leurs propres attributs.

3.1.4. Cardinalités

Les cardinalités définissent le nombre de fois où une entité peut être impliquée dans une relation :

  • 0 : l’entité n’est jamais impliquée.

  • 1 : l’entité est impliquée une seule fois.

  • n : l’entité est impliquée plusieurs fois.

3.1.5. Place dans la méthodologie MERISE

Le MCD fait partie intégrante de la méthodologie MERISE et constitue la première étape de modélisation des données :

  • MCD (Modèle Conceptuel des Données) : niveau conceptuel, abstrait.

  • MLD (Modèle Logique des Données) : intègre les spécificités techniques.

  • MPD (Modèle Physique des Données) : implémentation physique dans un SGBD.

3.1.6. Avantages

  • Communication facilitée entre les différents acteurs du projet.

  • Réduction des risques d’erreurs et d’oublis.

  • Base solide pour la conception technique.

  • Validation des règles métier.

  • Abstraction des contraintes techniques.

Le MCD constitue une étape très importante de la modélisation.
Si cette tâche est mal réalisée, des erreurs en cascade se produiront et rejailliront sur le MLD, le MPD et sur la base de données finale.[2]

4. le modele logique des donnees (MLD)

4.1. Qu’est-ce que le modèle logique des données (MLD) ?

5. Le MCD Hairbnb

Télécharger l’analyse complète (PDF)

Étant donné la taille conséquente du Modèle Conceptuel de Données (MCD), j’ai fait le choix de le joindre sous forme de document PDF, en annexe.
Toutefois, ce MCD ne sera pas simplement cité : il fera l’objet d’une analyse détaillée dans la partie suivante, afin d’en expliquer la structure, les entités, les relations, et les choix de modélisation effectués. '''

5.1. Gestion des utilisateurs et des profils

Cette partie traite des tables relatives au profil utilisateur ainsi que des tables dérivées.

Elle met l’accent sur les éléments suivants :

  • Le rôle de chaque entité.

  • Les relations entre les entités (les tables plus tard).

  • L’explication de certains choix de conception.

  • Un aperçu final du contenu possible de chaque table.

L’objectif est de clarifier l’organisation des données utilisateurs dans le système.

mcd user
Figure 1. MCD entité user & entité dérivées

5.1.1. TblUser

L’entité TblUser représente un utilisateur générique du système, elle est héritée par les entités TblClient et TblCoiffeuse.

Nom du champ Type (supposé) Description

idTblUser

INTEGER (PK)

Identifiant unique de l’utilisateur

uuid

UUID

Identifiant universel unique

nom

VARCHAR

Nom de famille de l’utilisateur

prenom

VARCHAR

Prénom de l’utilisateur

email

VARCHAR

Adresse email

numero_telephone

VARCHAR

Numéro de téléphone

date_naissance

DATE

Date de naissance

is_active

BOOLEAN

Indique si l’utilisateur est actif

photo_profil

VARCHAR (URL)

Lien vers la photo de profil

Pourquoi nom et prenom sont en VARCHAR et non CHAR ?

Type Caractéristiques Raisons de préférer VARCHAR

CHAR(n)

Stocke exactement n caractères. Les chaînes plus courtes sont remplies avec des espaces.

Inefficace pour des champs comme les prénoms ou noms, qui varient beaucoup en longueur. Par exemple : “Lee” vs “Alexandropoulos”.

VARCHAR(n)

Stocke la chaîne exactement comme elle est, sans ajout d’espaces, jusqu’à n caractères.

Optimise l’espace, évite le gaspillage, mieux adapté aux longueurs variables des noms.
Example 1. Concretement

CHAR(20) pour le prénom "Léo" = 17 caractères d’espace inutiles.

VARCHAR(20) pour "Léo" = seulement 3 caractères stockés.

Utilisez VARCHAR lorsque la longueur des valeurs de la colonne varie considérablement.
CHAR convient mieux aux colonnes dont les valeurs ont toutes la même longueur.

— PostgreSQL Documentation - traduit depuis la version anglaise

🔗 Source : https://www.postgresql.org/docs/current/datatype-character.html

Relations
Relation Entité source Entité cible (cardinalité vue depuis la source) Explication Merise

POSSEDER

TblUser

TblRole (1,1)

Un utilisateur est associé à un seul rôle. Un même rôle peut être partagé par 0 à n utilisateurs.

CATEGORISER

TblUser

TblType (1,1)

Chaque utilisateur appartient à un seul type. Un type peut regrouper 0 à n utilisateurs.

GENERER

TblUser

TblSexe (1,1)

Chaque utilisateur est de un seul sexe. Un sexe peut être partagé par 0 à n utilisateurs.

HABITER

TblUser

TblAdresse (0,1)

Un utilisateur peut avoir une seule adresse. Une adresse est liée à 0 ou un utilisateur.

CONTENIR

TblAdresse

TblRue (1,1)

Chaque adresse contient une seule rue. Une rue peut être contenirdans 0 à n adresses.

SE TROUVER

TblRue

TblLocalite (1,1)

Chaque rue appartient à une seule localité. Une localité peut contenir 0 à n rues.

HÉRITER (spécialisation)

TblUser

TblClient ou TblCoiffeuse (0,1)

Un utilisateur est soit client, soit coiffeuse

📌 Lecture Merise : – La cardinalité affichée est celle de l’entité cible vue depuis l’entité source.

– Elle s’interprète comme : Un utilisateur est lié à combien d’occurrences de l’autre entité ?

5.2. MLD tables user & tables dérivées

mld user

  • Ces tables Contiennent les données de base de tout utilisateur, qu’il soit client ou coiffeuse.

  • Sert de super-classe dans une structure d’héritage relationnel.

Champs principaux :

  • IDTBLUSER (PK) : Identifiant unique de l’utilisateur.

  • UUID : Identifiant universel (vient de Firebase).

  • NOM, PRENOM, EMAIL, NUMERO_TELEPHONE, DATE_NAISSANCE.

  • IS_ACTIVE : Indicateur d’activité du compte.

  • PHOTO_PROFIL : URL de la photo de profil.

Clés étrangères :

  • IDTBLTYPE → TBLTYPE : Type d’utilisateur (Client, Coiffeuse).

  • IDTBLROLE → TBLROLE : Rôle fonctionnel (ex. : user, admin).

  • IDTBLADRESSE → TBLADRESSE : Adresse de résidence.

  • IDTBLSEXE → TBLSEXE : Sexe de l’utilisateur.

5.2.1. Tables associées à TBLUSER (relations n:1)

Table Description

TBLTYPE

Contient les types d’utilisateur.
Un type peut être partagé par plusieurs utilisateurs.

TBLROLE

Définit les rôles fonctionnels.
Un utilisateur est lié à un seul rôle.

TBLSEXE

Normalise l’attribut "sexe".
Un sexe peut être partagé par plusieurs utilisateurs.

TBLADRESSE

Permet de relier l’utilisateur à une adresse, elle-même liée à une rue et une localité.

5.2.2. Tables dérivées de TBLUSER (spécialisation)

La spécialisation est réalisée via des sous-tables avec une clé étrangère vers TBLUSER. Cette méthode correspond à une décomposition horizontale.

TBLCLIENT

  • Clé primaire = Clé étrangère vers TBLUSER.

  • Reprend tous les champs de TBLUSER (héritage).

  • Ne contient aucune donnée spécifique.

  • Sert à distinguer les utilisateurs "clients".

TBLCOIFFEUSE

  • Clé primaire = Clé étrangère vers TBLUSER

  • Reprend tous les champs de TBLUSER

  • Ajoute le champ NOM_COMMERCIAL spécifique à la coiffeuse

  • La spécialisation est exclusive : un utilisateur est soit client, soit coiffeuse.

  • La duplication apparente des attributs dans les tables filles est conceptuelle.

En pratique, ces données ne sont pas dupliquées si l’on applique une jointure.

  • Cette structure permet une modularité évolutive : possibilité d’ajouter d’autres spécialisations (ex : TBLADMIN, TBLPARTENAIRE, etc.).

5.3. Contenu possible de la tables user & tables dérivées

tblUser

5.4. La Composition de l’adresse

J’aimerais ouvrir une parenthèse pour expliquer la composition de la table TBLADRESSE.

C’est la première fois que j’opte pour ce type de modélisation, mais je la trouve particulièrement logique dans le contexte d’une application qu’on imagine utilisée à l’échelle de toute la Belgique.

La table TBLLOCALITE est un classique qu’on retrouve dans presque tous les modèles vus jusqu’à présent, et je ne pense pas qu’il soit nécessaire de la justifier davantage.

En revanche, pour ce qui est des rues, une problématique particulière se pose : une même rue peut exister dans plusieurs localités ou communes.

Par exemple, la rue “Avenue Louise” peut se retrouver à la fois à Bruxelles et à Uccle.

Si on ne distingue pas la localité de la rue, cette rue risquerait de figurer plusieurs fois dans la table TBLADRESSE, ce qui introduirait de la redondance — contraire à l’un des principes fondamentaux des bases de données relationnelles.

Pour éviter cela, j’ai préféré créer une table distincte TBLRUE, reliée à TBLLOCALITE, afin que l’ensemble rue + localité définisse une adresse complète et unique.

Concernant la boîte postale, j’ai rencontré quelques hésitations.

Certaines adresses en disposent, d’autres non, et vouloir gérer cela via une table ou un champ spécifique aurait complexifié inutilement le MCD, que je trouve déjà assez dense.

J’ai donc pris la décision d’incorporer la boîte postale directement dans le champ NUMERO de TBLADRESSE.

Par exemple, si une adresse comporte une boîte postale, le numéro sera stocké comme 10/1, sinon, ce sera simplement 10.

Comme ce champ est de type VARCHAR, cela ne pose aucun problème technique, et l’affichage pourra être géré proprement au niveau du front-end en séparant les valeurs si nécessaire.

Maintenant, pour ce qui est de savoir s’il faut lier TBLLOCALITE à TBLRUE, ou bien lier directement les deux à TBLADRESSE… je pense que là, on aura besoin d’une bonne discussion, ou alors il faudra réussir à me convaincre 😄

— Retour d’expérience personnel - El khyari soulaiman

5.5. Entités liérs à la table TBLCOIFFEUSE

Cette partie traite des entités en lien avec l’entité Coiffeuse, en s’intéressant à l’organisation des prestations, des disponibilités, des rendez-vous, ainsi ses interactions avec le salon.

Elle met l’accent sur les éléments suivants :

  • Le rôle de chaque entité dans la représentation de l’activité des coiffeuses.

  • Les relations existantes entre les différentes entités, qu’elles soient fonctionnelles (ex. : Avis, HoraireCoiffeuse, RendezVous) ou structurelles (ex. : Salon, Service).

  • L’explication de certains choix de modélisation visant à garantir l’intégrité des données, à éviter les redondances, et à permettre une évolution future du modèle.

  • Un aperçu des données types que chaque entité pourrait contenir dans un contexte réel d’utilisation (comme celui de l’application Hairbnb).

L’objectif est de clarifier l’architecture conceptuelle autour de l’entité Coiffeuse, de montrer comment son activité professionnelle est représentée dans le système d’information, et de justifier les principales décisions prises lors de la conception du MCD.

5.6. Entités liérs à la table TBLCOIFFEUSE

MCD coiffeuse

Afin de contourner la complexité et la taille importante du MCD (comme déjà expliqué précédemment), j’ai choisi de le découper en plusieurs parties et de traiter chaque section séparément.

Cependant, cette séparation peut parfois entraîner une perte de cohérence entre certaines entités.

En effet, isoler certaines entités de leurs relations complètes peut affecter leur représentation finale ou la construction correcte du MLD associé.

Si vous constatez une incohérence ou une anomalie (due à un oubli ou une simplification de ma part), je vous invite à vous référer à la version intégrale du MCD ou du MLD.

Cela permettra de vérifier la véritable architecture conceptuelle, qui reflète le modèle fonctionnel complet de l’application.

5.6.1. Coiffeuse

L’entité TblCoiffeuse représente toute personne proposant des services de coiffure via la plateforme.
Elle hérite de l’entité Utilisateur et est spécialisée pour les activités professionnelles.

Nom de l’attribut Type (supposé) Description

idTblCoiffeuse

Identifiant

Identifiant unique de la coiffeuse (hérité de Utilisateur)

nom_commercial

Varchar

Nom commercial utilisé dans le cadre professionnel

Remarque

–

 — 

5.6.2. Salon

L’entité TblSalon représente un lieu d’exercice professionnel pour une coiffeuse.
Une coiffeuse peut être liée à un ou plusieurs salons (en pratique, un seul salon par coiffeuse).

Nom de l’attribut Type (supposé) Description

idTblSalon

Identifiant

Identifiant du salon

nom_salon

Varchar

Nom du salon

description

Texte

Description libre du salon

adresse_salon

idTblAdresse

Adresse libre du lieu

photo_salon

Image

Lien vers une image (Logo) du salon

Remarque

–

Nous reviendrons sur cette entité car elle est impliquée dans d’autres relations avec les entités Service, Coiffeuse, etc.

5.6.3. Relation : TRAVAILLER

L’association TRAVAILLER représente une relation entre une TblCoiffeuse et un TblSalon.

Elle indique qu’une coiffeuse exerce dans un ou plusieurs salons, et qu’un salon peut employer plusieurs coiffeuses.

Cette relation porte un attribut : est_proprietaire, qui permet d’indiquer si la coiffeuse est également propriétaire du salon ou non.

Nom de l’attribut Type (supposé) Description

est_proprietaire

Booléen

Indique si la coiffeuse est aussi la propriétaire du salon

Remarque

–

Cette relation sera transformée en une entité associative lors du passage au MLD

La relation est de type n,n entre TblCoiffeuse et TblSalon indique que : Chaque coiffeuse peut travailler dans plusieurs salons, et chaque salon peut accueillir plusieurs coiffeuses.

En abordant les relations qui deviennent des entités associatives (souvent appelées tables de jonction au niveau du MLD), je souhaite partager un problème que j’ai rencontré à plusieurs reprises lors du développement de l’application.

Il s’agit de la nomenclature des relations dans le MCD, où les associations sont généralement nommées avec des verbes (ex. : TRAVAILLER, APPARAITRE).

Cela a souvent été source de confusion pour moi : chaque fois que je tombais sur une table portant un nom comme travailler dans le MPD ou MLD, je devais revenir au MCD pour comprendre quelles entités étaient réellement impliquées.

Cela devenait rapidement perturbant dans le développement pratique de l’application.

En cherchant une solution, j’ai découvert que la convention de nommage Django pour les tables de jonction est plus explicite :

elle consiste à combiner les noms des deux entités concernées.

Par exemple, une relation entre Coiffeuse et Salon pourrait devenir TblCoiffeuseSalon, ce qui est immédiatement compréhensible sans devoir consulter le schéma conceptuel à chaque fois.

— Retour d’expérience personnel - El khyari soulaiman
Convention de nommage des tables de jonction dans Django

Django crée automatiquement une table de jonction pour les relations ManyToMany en utilisant :

"the name of the many-to-many field and the name of the table for the model that contains it"

Cela donne un format du type : nom_du_modele_nom_du_champ.

Exemple : une relation entre Author et Book devient author_books.

Si le nom devient trop long, Django le tronque automatiquement et ajoute un hash unique (ex. : author_books_9cdf).

Il est également possible de personnaliser ce nom via l’option db_table du champ ManyToManyField.

🔗 Source : https://docs.djangoproject.com/en/5.2/ref/models/fields/#manytomanyfield
🔗 Autre source : https://www.webforefront.com/django/setuprelationshipsdjangomodels.html

5.6.4. Service

L’entité TblService décrit une prestation proposée par une coiffeuse. Elle peut être associée à un salon.

Nom de l’attribut Type (supposé) Description

idTblService

Identifiant

Identifiant du service

intitule

Varchar

Nom de la prestation

description

Texte

Détails sur le service

prix

Décimal

Prix affiché pour le service

temps

Entier

Durée estimée en minutes

prixFinal

Décimal

Prix après réduction s’il y a lieu

Remarque

–

Cette entité sera détaillée plus loin car elle est liée à plusieurs autres (salon, rendez-vous, promotions…)

5.6.5. RendezVous

L’entité TblRendezVous modélise une rencontre planifiée entre un client et une coiffeuse à une date et heure donnée.

Nom de l’attribut Type (supposé) Description

idTblRendezVous

Identifiant

Identifiant unique du rendez-vous

date_rdv

Date

Date de la rencontre prévue

heure_debut

Heure

Heure de début

heure_fin

Heure

Heure de fin estimée

statut

varchar

État du rendez-vous (prévu, annulé, confirmé…)

Remarque

–

Nous reviendrons sur cette entité, car elle implique des relations avec TblClient, TblCoiffeuse, et TblService

5.6.6. Relation : APPARAITRE

L’association APPARAITRE modélise le lien entre un TblService et un TblRendezVous.
Elle permet de déterminer quels services sont inclus dans un rendez-vous donné, avec des valeurs spécifiques pour le prix et la durée estimés dans ce contexte.

Nom de l’attribut Type (supposé) Description

prix_estime

Décimal

Prix estimé du/des service(s) pour ce rendez-vous

duree_estime

Entier

Durée estimée du service en minutes

Remarque

–

Cette relation deviendra une entité associative dans le MLD

La relation est de type n,n entre Service et RendezVous.
Un rendez-vous peut contenir plusieurs services, et un service peut apparaître dans plusieurs rendez-vous.

5.6.7. HoraireCoiffeuse

L’entité TblHoraireCoiffeuse permet de modéliser les créneaux récurrents de disponibilité hebdomadaire d’une coiffeuse.

Nom de l’attribut Type (supposé) Description

idTblHoraire

Identifiant

Identifiant de l’horaire

jour_semaine

int

Jour concerné (ex : lundi)

heure_debut

Heure

Début de la disponibilité

heure_fin

Heure

Fin de la disponibilité

Remarque

–

 — 

5.6.8. Indisponibilite

L’entité TblIndisponibilite permet de représenter des absences ponctuelles ou des exceptions au planning d’une coiffeuse.

Nom de l’attribut Type (supposé) Description

idTblIndisponibilite

Identifiant

Identifiant de l’indisponibilité

date_indispo

Date

Jour où la coiffeuse est indisponible

motif

Varchar

Raison ou note facultative

Remarque

–

En relation avec TblCoiffeuse pour compléter dynamiquement le planning

5.6.9. Avis

L’entité TblAvis permet à un client de donner un retour après une prestation réalisée par une coiffeuse.

Nom de l’attribut Type (supposé) Description

idTblAvis

Identifiant

Identifiant de l’avis

note

Entier

Évaluation numérique (ex. : sur 5)

commentaire

Varchar

Commentaire libre

date_avis

Date

Date de publication

Remarque

–

En relation avec les entités TblClient et TblCoiffeuse

5.6.10. Favorite

L’entité TblFavorite permet à un client d’ajouter une coiffeuse à sa liste de favoris pour un accès rapide.

Nom de l’attribut Type (supposé) Description

idFavorite

Identifiant

Identifiant de la relation de favori

Remarque

–

Représente une relation binaire entre les entités TblClient et TblCoiffeuse
Synthèse des relations entre les entités liées à TblCoiffeuse
Entité source Relation Explication

TTblSalon

PRESTATER → TblService

Une coiffeuse peut prestater plusieurs prestations.

TblCoiffeuse

TRAVAILLER → TblSalon (n,n)

  • Une coiffeuse peut travailler dans plusieurs salons, et chaque salon peut accueillir plusieurs coiffeuses.

  • Un salon peut accueillir plusieurs coiffeuses dans le cadre de la relation TRAVAILLER.

TblCoiffeuse

PLANIFIER → TblHoraireCoiffeuse

Une coiffeuse peut définir plusieurs créneaux horaires dans la semaine.

TblCoiffeuse

DEFINIR → TblIndisponibilite

Une coiffeuse peut définir des absences ponctuelles ou des exceptions à ses horaires habituels.

TblSalon

CONCERNER PAR → TblAvis

Une salon peut recevoir plusieurs avis de la part des clients.

TblService

APPARAITRE → TblRendezVous (n,n)

  • Un service peut être inclus dans plusieurs rendez-vous différents.

  • Un rendez-vous peut contenir un ou plusieurs services distincts.

5.7. MLD Entités liérs à la table TBLCOIFFEUSE

MLD coiffeuse

  • Ces tables contiennent les informations spécifiques à l’activité professionnelle des coiffeuses : salons, prestations, disponibilités, rendez-vous, évaluations et favoris.

  • Elles interagissent avec plusieurs entités via des relations directes ou des entités associatives.

Champs principaux de TBLCOIFFEUSE :

  • IDTBLUSER : Clé primaire (et étrangère) héritée de TBLUSER.

  • NOM_COMMERCIAL : Nom utilisé dans le cadre de l’activité professionnelle.

5.7.1. Tables associées à TBLCOIFFEUSE (relations 1,n ou n,n)

Table Description

TBLHORAIRECOIFFEUSE

Définit les créneaux hebdomadaires de disponibilité.
Chaque coiffeuse peut avoir plusieurs créneaux.

TBLINDISPONIBILITE

Permet de gérer des absences ponctuelles, indépendantes des horaires hebdomadaires.

TRAVAILLER alis TblCoiffeuseSalon

Entité associative entre TBLCOIFFEUSE et TBLSALON.
Permet de préciser si la coiffeuse est aussi propriétaire du salon.

TBLRENDEZVOUS

Contient les rendez-vous planifiés par des clients avec des coiffeuses.
Chaque coiffeuse peut avoir plusieurs rendez-vous.

TBLAVIS

Enregistre les avis laissés par des clients.
Un client peut évaluer une coiffeuse après un rendez-vous.

TBLFAVORITE

Permet à un client d’ajouter une coiffeuse à ses favoris.

PRESTATER alias TblSalonService

Entité associative entre TBLSALON et TBLSERVICE via les prestations proposées.

5.7.2. Tables spécialisées ou relationnelles

TRAVAILLER alias TblCoiffeuseSalon

  • Représente la relation entre une coiffeuse et un salon.

  • Contient l’attribut EST_PROPRIETAIRE pour indiquer si la coiffeuse est propriétaire du salon.

PRESTATER alias TblSalonService

  • Entité associative entre TBLSALON et TBLSERVICE.

  • Permet de relier les prestations proposées à un salon.

APPARAITRE alias TblRendezVousService

  • Entité associative entre TBLRENDEZVOUS et TBLSERVICE.

  • Permet de détailler les services réservés dans un rendez-vous (avec prix et durée estimés).

  • La structure est hautement relationnelle, avec plusieurs entités associatives nécessaires à la modélisation fine de l’activité.

  • L’utilisation de relations n,n justifie l’existence de plusieurs tables intermédiaires (ex : TRAVAILLER, PRESTATER, APPARAITRE).

  • Cette organisation permet une évolution facile du modèle (ajout de nouveaux types de services, salons multiples, etc.).

5.8. Contenu possible de chaque table

5.8.1. TBLCOIFFEUSE

coiffeuseM

5.8.2. TBLHORAIRECOIFFEUSE

Les horaires de la coiffeuse Un enregistrement dans TBLHORAIRECOIFFEUSE
Image A
Image B

5.8.3. TBLINDISPONIBILITE

Les absences des coiffeuses Un enregistrement dans TBLINDISPONIBILITE
Image A
Image B

5.8.4. TBLRENDEZVOUS

Les rendez-vous des clients Un enregistrement dans TBLRENDEZVOUS
Image A
Image B

5.8.5. TBLAVIS

Les avis des clients Un enregistrement dans TBLAVIS
Image A
Image B

5.8.6. TBLFAVORITE

Les favoris des clients Un enregistrement dans TBLFAVORITE
Image A
Image B

5.8.7. TBLSALON

Les salons Un enregistrement dans TBLSALON
Image A
Image B

5.8.8. TBLSERVICE

Les services Un enregistrement dans TBLSERVICE
Image A
Image B

5.8.9. TBLAPPARAITRE alis TblRendezvousService

Les rendez-vous des services Un enregistrement dans TBLAPPARAITRE
Image A
Image B

5.8.10. TBLTRAVAILLER alis TblCoiffeuseSalon

Les coiffeuses des salons Un enregistrement dans TBLTRAVAILLER
Image A
Image B

5.9. Les tables associées à une réservation

Cette partie traite des entités et relations en lien avec la gestion d’une réservation (TblRendezVous) dans l’application Hairbnb.

Elle couvre l’ensemble du cycle de réservation, depuis la sélection des services jusqu’au paiement final, en passant par l’implication des clients, coiffeuses et tarifs.

Elle met l’accent sur les éléments suivants :

  • Le rôle de chaque entité dans la modélisation d’un parcours de réservation cohérent et structuré.

  • Les relations entre ces entités, qu’elles soient transactionnelles (ex. : Paiement), opérationnelles (ex. : Apparaître, Figurer, CartItem), ou structurelles (ex. : Prix, Temps, Promotion).

  • L’explication de certains choix de conception destinés à assurer la clarté des interactions, la flexibilité du panier de réservation, et l’intégration avec des plateformes de paiement externes (Stripe).

  • Un aperçu des types de données que ces entités peuvent contenir dans une situation d’utilisation réelle.

L’objectif est de clarifier l’architecture conceptuelle entourant une réservation, en illustrant comment les informations liées aux prestations, aux utilisateurs, aux prix, au temps et au paiement sont articulées dans le système d’information.

MCD tables Reservation

Certaines entités déjà abordées dans les parties précédentes ne seront pas réanalysées ici, afin d’éviter les redondances.

Cependant, des exceptions sont faites pour des entités comme TblSalon et TblCoiffeuse, car l’analyse précédente ne se concentrait pas spécifiquement sur leurs rôles et relations dans le processus de réservation.

Elles seront donc reprises dans cette section pour assurer une compréhension complète du cycle de réservation.

5.9.1. TblSalon

L’entité TblSalon représente un établissement de coiffure où exercent une ou plusieurs coiffeuses.

Un salon peut proposer différents services et être associé à plusieurs images de présentation.

Nom de l’attribut

Type

Description

idTblSalon

Identifiant

Identifiant unique du salon

nom_salon

Varchar

Nom commercial du salon

slogan

Varchar

Slogan ou phrase d’accroche du salon

a_propos

Texte

Description détaillée du salon et de ses spécialités

logo_salon

Image

Logo ou image de marque du salon

numero_tva

Varchar

Numéro de TVA de l’établissement

position

Géolocalisation

Coordonnées GPS du salon

Remarque

–

Cette entité est centrale et connectée aux coiffeuses, services, adresse et images

5.9.2. TblCoiffeuseSalon (TRAVAILLER)

L’entité TblCoiffeuseSalon représente la relation de travail entre une coiffeuse et un salon.

Elle permet de gérer l’affectation des coiffeuses aux établissements.

Nom de l’attribut Type Description

idTblSalon

Référence

Salon concerné

idTblCoiffeuse

Référence

Coiffeuse travaillant dans le salon

est_proprietaire

Booléen

Indique si la coiffeuse est aussi propriétaire du salon

Remarque

–

  • La relation est de type n,n et sera transformée en table de jonction dans le MLD.

  • La coiffeuse qui cree le salon est d’office la propriétaire.

5.9.3. Relation avec l’entité Adresse

Chaque salon est localisé à une adresse spécifique, décrite dans l’entité TblAdresse.

Cette relation est de type 1,1 dans le sens TblSalon → TblAdresse.

Nom de l’attribut Type Description

adresse_salon

Référence (idTblAdresse)

L’adresse physique du salon.

Remarque

–

L’adresse complète est structurée à travers une hiérarchie : Adresse → Rue → Localité

5.9.4. Relation avec l’entité Image (via ÊTRE_ASSOCIÉ)

Un salon peut être lié à une ou plusieurs images (photos, visuels) via une entité TblSalonImage.

Nom de l’attribut Type Description

idTblSalonImage

Identifiant

Image rattachée au salon

idTblSalon

Référence

Salon concerné

image

URL

Lien vers le fichier image stocké

Remarque

–

Cette relation permet de gérer une galerie d’images ou de visuels pour chaque salon

5.9.5. TblService

L’entité TblService représente une prestation proposée par une coiffeuse, généralement au sein d’un salon.

Elle peut être liée à plusieurs éléments : tarifs, durée, promotions, catégories, et apparaître dans des rendez-vous ou des paniers.

Nom de l’attribut

Type (supposé)

Description

idTblService

Identifiant

Identifiant unique du service

intitule_service

Varchar

Nom du service (coupe, brushing, coloration…​)

description

Texte

Description détaillée de la prestation

duree_estimee

Integer

Durée moyenne en minutes

categorie

Varchar

Catégorie du service

Remarque

–

Lié aux salons via la table TblSalonService pour la tarification

Un des principes fondamentaux de l’architecture des bases de données relationnelles est d’éviter la redondance. C’est cette règle qui m’a amené à longuement réfléchir à la manière de modéliser la relation entre un salon et les services qu’il propose.

Le problème était simple : presque chaque salon va proposer un service intitulé "Coupe cheveux courts", par exemple.

Si je créais ce service pour chaque salon dans la table TblService, cela allait générer une forte redondance dans les données.

Le dilemme venait du fait que ce même service peut être facturé différemment selon le salon, ou bien durer plus ou moins longtemps.

Autrement dit, les attributs varient selon le contexte, mais l’intitulé reste identique.

La solution que j’ai retenue consiste à créer une relation Many-to-Many entre TblSalon et TblService (modélisée par l’entité PRESTATER` alias TblSalonService).

Ainsi :

  • Un salon peut proposer plusieurs services.

  • Un service peut être proposé dans plusieurs salons.

En parallèle, j’ai aussi modélisé une relation Many-to-Many entre TblService et TblPrix, et entre TblService et TblTemps.

Cela permet à un service donné d’être associé à plusieurs prix ou durées différentes selon le contexte (par exemple, selon le salon ou une promotion spécifique).

Ce choix assure une structure flexible, cohérente et sans redondance inutile, tout en respectant les principes fondamentaux de la conception relationnelle.

5.10. Relations entre les entités

Entité source

Entité cible

Type de relation

Description

TblSalon

TblCoiffeuseSalon

1:N

Un salon peut employer plusieurs coiffeuses

TblCoiffeuse

TblCoiffeuseSalon

1:N

Une coiffeuse peut travailler dans plusieurs salons

TblSalon

TblAdresse

1:1

Un salon possède une adresse unique

TblSalon

TblSalonService

1:N

Un salon propose plusieurs services

TblService

TblSalonService

1:N

Un service peut être proposé par plusieurs salons

TblSalon

TblSalonImage

1:N

Un salon peut avoir plusieurs images

5.11. MLD Pour TblSalonService et les relations qui lui sont liées

MLD salonService

Cette section analyse les tables encadrées en rouge dans le MLD.

Elles constituent le cœur du système de gestion des salons, des services et des prestations dans l’application Hairbnb.

5.11.1. TblCoiffeuse

Type

Table dérivée de TblUser (via spécialisation exclusive)

Rôle

Stocke les informations spécifiques aux coiffeuses professionnelles

Champ ajouté

nom_commercial

Relations

* Clé étrangère depuis TblUser
* Clé étrangère vers TRAVAILLER (relation avec TblSalon)

5.11.2. TblSalon

Type

Table principale représentant les salons physiques

Rôle

Lieu d’exercice des prestations proposées par les coiffeuses

Champs clés

nom_salon, a_propos, position, idTblAdresse

Relations

* FK vers TblAdresse
* FK depuis TRAVAILLER, TblSalonImage, PRESTATER

5.11.3. TblSalonImage

Type

Table média liée à un salon

Rôle

Permet d’associer plusieurs images ou visuels à un salon

Relations

FK vers TblSalon
La liste des images enregistrées Un enregistrement dans TblSalonImage
Image A
Image B

5.11.4. TRAVAILLER alias TblCoiffeuseSalon

Type

Table de jonction (n,n) entre TblSalon et TblCoiffeuse

Rôle

Indique dans quel(s) salon(s) travaille une coiffeuse

Champ spécifique

est_proprietaire : indique si la coiffeuse est propriétaire du salon
La liste des coiffeuses travaillant dans un salon La coiffeuse qui travaille dans ce salon
Image A
Image B

5.11.5. PRESTATER (TblSalonService)

Type

Table de jonction (n,n) entre TblSalon et TblService

Rôle

Liste les services disponibles dans chaque salon

Remarque

Évite la duplication des lignes dans la table TblService
La liste des services proposés par un salon Le salon proposant ce service
Image A
Image B

5.11.6. TblService

Type

Table métier centrale

Rôle

Représente une prestation offerte dans les salons

Champs

intitule_service, description, idTblCategorie

Relations

* FK depuis PRESTATER
* FK vers TblCategorie
* FK vers COUTER, DURER

5.11.7. TblPrix

Type

Table de paramétrage

Rôle

Stocke des valeurs de prix

Relation

FK depuis COUTER
La liste des prix des services Le prix d’un service
Image A
Image B

5.11.8. COUTER alias TblServicePrix

Type

Table de jonction (n,n) entre TblService et TblPrix

Rôle

Associe un ou plusieurs prix à un service
La liste des prix des services Le prix d’un service
Image A
Image B

5.11.9. TblTemps

Type

Table de paramétrage

Rôle

Stocke les durées des prestations

Relation

FK depuis DURER
La liste des durées des services La durée d’un service
Image A
Image B

5.11.10. DURER alias TblServiceTemps

Type

Table de jonction (n,n) entre TblService et TblTemps

Rôle

Associe un ou plusieurs temps estimés à un service
La liste des durées des services La durée d’un service
Image A
Image B

5.11.11. TblCategorie

Type

Table de classification

Rôle

Classe les services selon des catégories métiers (ex : coupe, soin, coloration)

Relation

FK depuis TblService

Ces tables constituent le cœur fonctionnel du système de gestion des prestations.

Elles assurent :

  • Une modélisation sans redondance,

  • Une structure flexible multi-salon/multi-service,

  • Un découpage clair entre services, prix, durée, et visibilité.

Cette organisation respecte les principes fondamentaux du MLD relationnel (selon ma compréhension).

Certaines tables ne sont pas reprises ici car elles ont déjà été traitées dans les parties précédentes.

Dans d’autres cas, seules les images ont été volontairement omises afin d’éviter les redondances visuelles et informationnelles.

5.12. Les tables associées au panier

Cette partie traite des tables en lien avec la gestion du panier (TblCart) dans l’application Hairbnb.

Elle modélise le processus de sélection des services avant réservation, dans une logique comparable à celle d’un "panier d’achat" dans un site e-commerce.

Elle met l’accent sur les éléments suivants :

  • Le rôle de chaque table dans la construction, l’enregistrement et la structuration du panier utilisateur.

  • Les relations entre les tables qui permettent d’associer un ou plusieurs services à un panier, de suivre les quantités et de préparer la phase de réservation.

  • L’explication de certains choix de conception, notamment le fait de passer par la table intermédiaire (TblCartItem) pour représenter le lien entre le panier et les services choisis.

  • Un aperçu des types de données que ces tables peuvent contenir, avec l’objectif de rendre le panier persistant, réutilisable et compatible avec un système de réservation ou de paiement.

L’objectif est de clarifier l’architecture logique du panier dans le MLD, en montrant comment les utilisateurs peuvent sélectionner des prestations, les regrouper dans un panier personnel, et ainsi préparer une réservation complète et structurée.

Certaines tables déjà abordées dans les sections précédentes ne seront pas détaillées à nouveau ici.

Seules les tables essentielles à la gestion du panier, entourées en rouge dans le diagramme, sont analysées dans ce volet.
MCD tables Panier

5.12.1. TblCart

L’entité TblCart représente le panier personnel d’un utilisateur.

Elle permet de regrouper temporairement les services sélectionnés avant la validation de la réservation.

Nom de l’attribut Type Description

idTblCart

Identifiant

Identifiant unique du panier

created_at

DateTime

Date et heure de création du panier

Remarque

–

Un utilisateur ne peut avoir qu’un seul panier actif à la fois

5.12.2. TblCartItem

L’entité TblCartItem représente un élément individuel du panier, c’est-à-dire un service sélectionné par l’utilisateur.

Elle permet également d’indiquer la quantité souhaitée du service choisi.

Nom de l’attribut Type Description

idTblCartItem

Identifiant

Identifiant de l’élément du panier

quantity

Entier

Quantité du service sélectionné

Remarque

–

-

5.13. MLD Les tables associées au panier

MLD tables Panier

5.13.1. TblCart

Type

Table principale représentant un panier utilisateur

Rôle

Permet de regrouper temporairement les services sélectionnés avant validation

Champ notable

created_at : enregistrement de la date de création du panier

Relations

* Clé étrangère vers TblUser (relation 1,1)
* Clé étrangère depuis TblCartItem (relation 1,n)
Les enregistrments de TblCart Un enregistrement dans TblCart
Image A
Image B

5.13.2. TblCartItem

Type

Table composant les éléments d’un panier (TblCart)

Rôle

Stocke les services ajoutés au panier ainsi que leur quantité

Champ notable

quantity : quantité demandée pour le service sélectionné

Relations

* Clé étrangère vers TblCart (relation 1,n)
* Clé étrangère vers TblService (chaque item correspond à un service précis)
Les enregistrments de TblCartItem Un enregistrement dans TblCartItem
Image A
Image B

5.14. Théorie du panier : fonctionnement général

Le concept du panier dans une application hairbnbrepose sur une logique simple :

Il permet à un utilisateur de sélectionner temporairement un ou plusieurs services, avant de les valider dans une commande ou une réservation.

Dans Hairbnb, cette logique est adaptée à un contexte de services de coiffure, où l’utilisateur (client) construit une sélection de prestations qu’il souhaite réserver.

5.14.1. Acteurs principaux du système de panier

  • TblCart : représente un panier personnel pour un utilisateur, il est unique, temporaire et à un utilisateur.

  • TblCartItem : contient les lignes du panier, chaque ligne correspond à un service sélectionné, avec la quantité souhaitée (ex : 2 "shampoings", 1 "brushing").

  • TblService : représente l’offre de prestations disponibles dans l’application.

5.14.2. Principe fondamental : copie contrôlée

Lorsqu’un utilisateur sélectionne un service à ajouter à son panier, on ne copie pas le contenu complet du service dans le panier.

Au lieu de cela, TblCartItem fait référence au service via une clé étrangère vers TblService.

Cela permet : * De garantir la cohérence des données (le service n’est défini qu’à un seul endroit), * D’éviter toute redondance inutile, * Et de faciliter les mises à jour (ex : changement du nom du service visible directement dans le panier).

5.14.3. Pourquoi copier certains attributs dans certains cas ?

Dans certains cas (comme ce las d’un service en promotion), il peut être pertinent de dupliquer des données volatiles dans TblCartItem comme :

  • le prix au moment de l’ajout au panier, si les prix peuvent fluctuer ensuite,
    +

  • une durée estimée, si elle dépend de conditions au moment de la réservation.

Dans Hairbnb, cette logique est généralement gérée dans la table TblRendezVousService et non TblCartItem.

Cela permet au panier de rester léger, réactif et synchronisé avec les services actifs, sans figer les conditions avant la validation.

5.14.4. Cycle de vie d’un panier

  1. L’utilisateur commence une sélection → un TblCart est créé (ou réutilisé s’il existe).

  2. À chaque ajout d’un service :

    • Un enregistrement TblCartItem est créé,

    • Il contient une quantité, et référence le service via idTblService.

  3. À la validation, le panier est converti en réservation (TblRendezVous), et le contenu du panier peut être copié ou transformé dans une autre structure TblAPPARAITRE alias (TblRendezVousService).

Le panier est une zone de transition temporaire, qui reflète les intentions du client sans encore engager de réservation ferme.
Il doit être simple, cohérent, et refléter l’état réel des services au moment de l’action.

5.15. Les tables associées à une réservation

Cette partie traite des tables impliquées dans le processus de réservation au sein de l’application Hairbnb.

Elle couvre le moment où le client valide son panier, et obtient un rendez-vous avec les services qui étét choisis.

Elle met l’accent sur les éléments suivants :

  • Le rôle de chaque table dans la gestion d’un rendez-vous.

  • La structuration des services sélectionnés dans le contexte de la réservation (TblRendezVousService).

  • L’association des informations tarifaires et temporelles spécifiques à chaque service dans le cadre d’un rendez-vous.

  • L’objectif de dissocier la réservation globale (future table TblRendezVous) du détail des services (future table APPARAITRE alias TblRendezVousService) pour garantir la flexibilité du système et éviter toute redondance.

L’architecture modélise un processus précis : un client prend rendez-vous avec une coiffeuse à une date donnée, choisit un ou plusieurs services, et chaque service est associé à un prix estimé et une durée estimée dans ce contexte particulier.

Certaines entités déjà abordées dans les sections précédentes ne seront pas redécrites ici (comme TblUser, TblClient, TblCoiffeuse), bien qu’elles soient impliquées dans le processus de réservation.

Nous nous concentrerons sur les entités spécifiques à la réservation (notamment TblRendezVous, TblRendezVousService, etc.) ainsi que les relations structurantes comme APPARAITRE.

Les entités suivantes sont directement impliquées :

  • RendezVous : entité centrale représentant une réservation.

  • Client : utilisateur qui prend le rendez-vous.

  • Coiffeuse : professionnelle réalisant la prestation.

  • Service : prestation(s) sélectionnée(s) dans le cadre de la réservation.

  • Apparaître : association n,n entre RendezVous et Service, avec des attributs spécifiques (prix et durée estimés).

  • Paiement : enregistrement du paiement de la réservation.

  • MéthodePaiement : mode utilisé (CB, Stripe, etc.).

  • PaiementStatut : état du paiement (réussi, échec, en attente…).

Certaines entités comme User sont impliquées en amont (par spécialisation en Client ou Coiffeuse), mais ne sont pas détaillées ici car déjà traitées précédemment.

Les entités en lien avec le paiement ne seront pas analysées dans cette section, car elles feront l’objet d’un traitement détaillé dans la partie suivante.
Relation (nom) Entité source Entité cible Rôle dans la réservation

PRENDRE

Client

RendezVous

Un client prend un ou plusieurs rendez-vous

FIXER

Coiffeuse

RendezVous

Une coiffeuse est affectée à un rendez-vous

APPARAITRE

Service

RendezVous

Associe un ou plusieurs services à un rendez-vous (via une entité associative)

APPARAITRE

RendezVous

Service

Permet d’ajouter un prix estimé et une durée spécifique à chaque service

PAYER

User

Paiement

L’utilisateur associé effectue un paiement

IMPLIQUER

Paiement

RendezVous

Le paiement est lié à un ou plusieurs rendez-vous

UTILISER

Paiement

MéthodePaiement

Décrit le moyen utilisé pour payer

INDIQUER

Paiement

PaiementStatut

Indique l’état ou le résultat du paiement

5.15.1. TblRendezVous

L’entité' TblRendezVous représente une réservation effectuée par un client auprès d’une coiffeuse, à une date et une heure précises.

Elle centralise les informations générales du rendez-vous (statut, date, durée totale, etc.).

Nom de l’attribut Type Description

idTblRendezVous

Identifiant

Identifiant unique du rendez-vous

idTblClient

Clé étrangère

Client ayant pris le rendez-vous

idTblCoiffeuse

Clé étrangère

Coiffeuse sélectionnée pour le rendez-vous

date_heure

Datetime

Date et heure de début du rendez-vous

statut

Varchar

Statut du rendez-vous (ex : prévu, confirmé, annulé)

prix_total

Décimal

Montant total à payer pour tous les services du rendez-vous

duree_total

Entier

Durée totale estimée du rendez-vous (en minutes)

est_archive

Booléen

Indique si le rendez-vous est archivé

Remarque

–

Contient les données globales d’une réservation, indépendamment des services choisis

5.15.2. APPARAITRE alias TblRendezVousService

La table TblRendezVousService permet d’associer plusieurs services à un même rendez-vous.
Elle stocke également les informations spécifiques à chaque service dans le contexte de ce rendez-vous (prix et durée estimés).

Nom de l’attribut Type Description

idTblRendezVousService

Identifiant

Identifiant unique de la ligne service-rendez-vous

idTblRendezVous

Clé étrangère

Rendez-vous concerné

idTblService

Clé étrangère

Service choisi pour ce rendez-vous

prix_estime

Décimal

Prix estimé du service dans le contexte du rendez-vous

duree_estime

Entier

Durée estimée du service (en minutes)

Remarque

–

Table issue de la relation APPARAITRE, permet d’enregistrer plusieurs services personnalisés par rendez-vous

5.16. MLD des tables associées à une réservation

MLD reservation

5.16.1. TblRendezVous

Type

Table principale représentant une réservation effectuée par un client

Rôle

Permet d’enregistrer un rendez-vous planifié avec une coiffeuse à une date et une heure précises

Champs notables

* date_heure : moment prévu de la prestation
* prix_total : montant cumulé des services
* duree_total : durée globale estimée du rendez-vous

Relations

* Clé étrangère vers TblClient (relation 1,1)
* Clé étrangère vers TblCoiffeuse (relation 1,1)
* Clé étrangère depuis TblRendezVousService (1,n)
* Liée au paiement (traité dans une partie distincte)
Les enregistrements de TblRendezVous Un enregistrement dans TblRendezVous
Exemple enregistrement
Exemple unique

5.16.2. TblRendezVousService

Type

Table associative entre TblRendezVous et TblService

Rôle

Permet d’enregistrer les services inclus dans un rendez-vous, avec leur prix et leur durée spécifiques

Champs notables

* prix_estime : tarif prévu du service
* duree_estime : durée anticipée (en minutes)

Relations

* Clé étrangère vers TblRendezVous
* Clé étrangère vers TblService
Les enregistrements de TblRendezVousService Un enregistrement dans TblRendezVousService
Enregistrements multiples
Enregistrement unique

5.17. Les entités associées au système de paiement

Cette partie traite des entités spécifiques à la gestion du paiement d’un rendez-vous dans le système Hairbnb.

Elle intervient après la validation du rendez-vous par le client et permet de suivre le règlement, le mode de paiement utilisé, ainsi que l’état de la transaction.

Elle met l’accent sur les éléments suivants :

  • Le rôle de chaque entité dans le traitement et le suivi d’un paiement.

  • La structuration du lien entre la réservation et le paiement.

  • L’indication du statut du paiement (réussi, en attente, annulé…) et du mode utilisé (CB, Stripe, etc.).

  • L’intégration des informations issues de l’API Stripe, comme les payment_intent_id, charge_id, etc.

L’architecture de paiement repose sur un enregistrement central (TblPaiement) qui dépend d’un rendez-vous confirmé.

Chaque paiement est associé à un utilisateur (User), une méthode (TblMethodePaiement), et un état (TblPaiementStatut).

Les entités TblRendezVous, TblClient, TblCoiffeuse et TblService ne sont pas décrites à nouveau ici, car elles ont été traitées en détail dans la section précédente consacrée à la réservation.

Les entités analysées ici sont :

  • Paiement : enregistrement du paiement lié à une réservation.

  • MethodePaiement : canal ou type de paiement (ex : Stripe, PayPal, Carte bancaire…).

  • PaiementStatut : état du paiement (réussi, échec, en cours…).

5.17.1. TblPaiement

L’entité TblPaiement représente un règlement effectué par un utilisateur dans le cadre d’un rendez-vous.
Elle stocke les métadonnées utiles pour le suivi, ainsi que les identifiants retournés par Stripe ou une autre plateforme.

Nom de l’attribut Type Description

idTblPaiement

Identifiant

Identifiant unique du paiement

idTblRendezVous

Clé étrangère

Rendez-vous concerné par le paiement

idTblUser

Clé étrangère

Utilisateur (client) ayant effectué le paiement

idTblMethodePaiement

Clé étrangère

Mode de paiement utilisé

idTblPaiementStatut

Clé étrangère

Statut du paiement

montant_paye

Décimal

Montant total réglé

stripe_payment_intent_id

Varchar

ID du payment_intent (Stripe)

stripe_charge_id

Varchar

ID de la charge (Stripe)

stripe_customer_id

Varchar

ID du client Stripe

stripe_checkout_session_id

Varchar

Session de paiement Stripe

email_client

Email

Email de confirmation du client

receipt_url

URL

Lien vers le reçu Stripe

Remarque

–

Table centrale du système de paiement. Chaque ligne correspond à un règlement unique

5.17.2. TblMethodePaiement

Nom de l’attribut Type Description

idTblMethodePaiement

Identifiant

Clé primaire de la méthode de paiement

code

Varchar

Code technique (ex : stripe, paypal)

libelle

Varchar

Nom lisible pour l’utilisateur (ex : "Carte bancaire via Stripe")

Remarque

–

Permet de gérer différents canaux de paiement sans dupliquer la logique dans TblPaiement

5.17.3. TblPaiementStatut

Nom de l’attribut Type Description

idTblPaiementStatut

Identifiant

Identifiant du statut de paiement

code

Varchar

Code interne (pending, success, failed, etc.)

libelle

Varchar

Description du statut pour affichage utilisateur

Remarque

–

Permet de suivre l’évolution du paiement sans le modifier directement dans TblPaiement

5.17.4. MLD des tables de paiement

MLD paiement

5.17.5. TblPaiement

Type

Table principale représentant un paiement d’une réservation

Rôle

Permet d’enregistrer tous les détails liés à la transaction financière d’un rendez-vous

Champs notables

* montant_paye
* stripe_payment_intent_id, receipt_url, etc.
* idTblPaiementStatut, idTblMethodePaiement : contrôle de l’état et du canal utilisé

Relations

* Clé étrangère vers TblUser
* Clé étrangère vers TblRendezVous
* Clé étrangère vers TblMethodePaiement
* Clé étrangère vers TblPaiementStatut
Les enregistrements de TblPaiement Un enregistrement dans TblPaiement
750
750

Dans le cahier des charges initial, aucune mention n’était faite de l’intégration d’un système de paiement.

Mais j’ai souhaité relever le défi jusqu’au bout, non seulement pour cette fonctionnalité, mais aussi pour d’autres que je détaillerai dans les sections à venir.

Concernant le paiement, c’était ma première expérience d’intégration dans une application.

J’ai d’abord testé plusieurs solutions, mais la plupart s’avéraient complexes à implémenter – à l’exception de PayPal, que j’ai trouvé relativement simple.

Cependant, PayPal me semblait moins populaire aujourd’hui, et un peu dépassé dans certains cas d’usage.

Sur recommandation, j’ai ensuite testé Stripe, que j’ai immédiatement trouvé adapté à mes besoins : une plateforme de paiement moderne, bien documentée, qui permet l’intégration de nombreux moyens de paiement (carte bancaire, Google Pay, Apple Pay, Bancontact, PayPal, etc.).

Son implémentation a été fluide, avec une excellente réputation en matière de sécurité.

À noter : la structure de mes tables de paiement repose principalement sur les recommandations officielles de Stripe.

La seule adaptation que j’ai apportée a été de séparer les statuts de paiement (TblPaiementStatut) et les méthodes de paiement (TblMethodePaiement) dans des entités dédiées, afin d’éviter toute redondance.

J’aborderai d’autres aspects du système de paiement sous un angle plus technique dans les prochaines sections.

— Retour d’expérience personnel – El Khyari Soulaiman

5.18. Les entités associées au système de notification par email

Cette section présente les entités responsables de l’envoi de notifications par email, qui permettent d’informer dynamiquement les utilisateurs à différentes étapes du processus de réservation.

Les notifications peuvent être déclenchées automatiquement après certains événements clés, notamment :

  • La confirmation d’un paiement (suite à une réservation validée)

  • L’annulation d’un rendez-vous (ex. : par la coiffeuse)

  • Des rappels avant la date du rendez-vous

  • Ou d’autres scénarios définis dans la logique métier

Cette architecture repose sur une entité centrale TblEmailNotification, enrichie par des tables de classification (TblEmailType, TblEmailStatut) afin de garantir la traçabilité, la personnalisation et la relisabilité des envois.

Bien que fortement lié aux processus de réservation et de paiement, le module de notification est traité ici de manière autonome, car il représente une logique transversale.

Les entités utilisateur, rendez-vous et paiement seront mentionnées, mais non redécrites.

Les entités analysées ici sont :

  • EmailNotification : enregistrement d’un email à envoyer ou déjà envoyé.

  • EmailType : type ou déclencheur de l’email (paiement réussi, annulation, rappel…).

  • EmailStatut : état de traitement (en attente, envoyé, échec…).

MCD notification

5.18.1. TblEmailNotification

L’entité TblEmailNotification permet d’enregistrer un email prévu ou déjà envoyé, à destination d’un utilisateur (TblUser).

Chaque notification est caractérisée par un sujet, un contenu, des dates (création et envoi), un nombre de tentatives, ainsi que le type d’email et son statut.

Nom de l’attribut Type Description

idTblEmailNotification

Identifiant

Clé primaire de l’enregistrement

idTblUser

Clé étrangère

Utilisateur destinataire de l’email

idTblEmailType

Clé étrangère

Type de notification (paiement, annulation…)

idTblEmailStatut

Clé étrangère

Statut de l’envoi (en cours, réussi, échec…)

sujet

Varchar

Objet de l’email

contenu

Texte

Corps du message

date_creation

DateTime

Date à laquelle l’email a été généré par le système

date_envoi

DateTime

Date à laquelle l’email a été envoyé (si applicable)

tentatives

Int

Nombre de tentatives d’envoi effectuées

Remarque

–

Chaque ligne correspond à un message email individualisé

5.18.2. TblEmailType

Cette table sert à catégoriser les notifications selon leur usage ou déclencheur.

Nom de l’attribut Type Description

idTblEmailType

Identifiant

Clé primaire de l’enregistrement

code

Varchar

Code interne (ex. : paiement_succes, annulation_rdv, rappel)

libelle

Varchar

Description lisible (ex. : Paiement validé, Rappel de rendez-vous…)

Remarque

–

Permet au système de filtrer ou regrouper les envois par logique métier

5.18.3. TblEmailStatut

Cette table décrit l’état actuel du message, pour gérer les tentatives, les erreurs, ou les suivis d’envoi.

Nom de l’attribut Type Description

idTblEmailStatut

Identifiant

Clé primaire

code

Varchar

Code technique (pending, sent, failed, etc.)

libelle

Varchar

Nom compréhensible pour les utilisateurs ou l’interface d’administration

Remarque

–

Permet une gestion fiable des files d’envoi ou des relances

5.19. MLD des tables de notifications

MLD notification

5.19.1. TblEmailNotification

Type

Table principale des notifications email

Rôle

Stocke chaque email généré automatiquement pour un utilisateur

Champs notables

* sujet, contenu, date_envoi, tentatives
* Lien vers type et statut pour gestion logicielle

Relations

* Clé étrangère vers TblUser (destinataire)
* Clé étrangère vers TblEmailType
* Clé étrangère vers TblEmailStatut
Liste de notifications Exemple d’une notification
750
750

5.19.2. TblEmailType

Type

Table de correspondance des types de notification

Rôle

Permet de classer les emails par logique fonctionnelle (paiement, annulation…)

Champs notables

* code : identifiant technique (ex. : paiement_succes)
* libelle : nom compréhensible affiché à l’utilisateur

Relations

* Clé étrangère depuis TblEmailNotification
Liste des types d’emails Exemple d’un type
750
750

5.19.3. TblEmailStatut

Type

Table de suivi du statut d’envoi des emails

Rôle

Permet de savoir si l’email a été envoyé, échoué, ou en attente

Champs notables

* code : valeur technique (pending, sent, failed, etc.)
* libelle : description lisible (En attente, Envoyé…)

Relations

* Clé étrangère depuis TblEmailNotification
Liste des statuts possibles Exemple d’un statut
750
750

5.20. Les entités associées au système de messagerie IA

Cette section décrit les entités en charge de la gestion des conversations entre l’utilisateur et l’intelligence artificielle intégrée dans l’application Hairbnb.

Ces entités permettent d’enregistrer les sessions de discussion, de suivre les messages échangés, ainsi que d’évaluer la consommation de ressources (tokens) pour chaque interaction.

Elles sont utiles pour assurer :
* La traçabilité des échanges, * L’amélioration continue des réponses, * Et la facturation éventuelle basée sur l’utilisation des tokens (Claude AI).

Cette partie se concentre uniquement sur les échanges avec l’IA.

L’es 'entité User est impliquée, mais il ne sera pas redécrite ici.

Les entités concernées sont :

  • AIConversation : session complète d’échange entre un utilisateur et l’IA.

  • AIMessage : message unique dans une session (envoyé ou reçu).

MCD ai messaging

5.20.1. TblAIConversation

L’entité TblAIConversation représente une session de discussion complète entre un utilisateur et l’intelligence artificielle.

Elle contient des métadonnées globales sur la session : date de création, cache contextuel, nombre total de tokens utilisés, etc.

Nom de l’attribut Type Description

idTblAIConversation

Identifiant

Clé primaire de la session de conversation

idTblUser

Clé étrangère

Utilisateur ayant initié la conversation

created_at

DateTime

Date de création de la session

context_cache

Texte

Stockage éventuel du contexte ou du prompt système

tokens_used

Int

Total des tokens consommés lors de cette session

Remarque

–

Une conversation peut contenir plusieurs messages IA ou utilisateur

5.20.2. TblAIMessage

L’entité TblAIMessage représente un message envoyé ou reçu dans le cadre d’une conversation IA.

Chaque message est lié à une conversation spécifique (idTblAIConversation) et contient des informations précises sur le contenu, le sens (utilisateur ou IA), et la consommation en tokens.

Nom de l’attribut Type Description

idTblAIMessage

Identifiant

Clé primaire du message

idTblAIConversation

Clé étrangère

Conversation à laquelle ce message appartient

content

Texte

Contenu du message (prompt ou réponse)

is_user

Booléen

Définit si le message est envoyé par l’utilisateur (true) ou l’IA (false)

timestamp

DateTime

Heure d’envoi du message

tokens_in

Int

Nombre de tokens d’entrée

tokens_out

Int

Nombre de tokens générés en sortie

metadata

JSON

Métadonnées techniques liées au message (score, modèle, etc.)

Remarque

–

–

5.21. MLD des tables de messagerie IA

MLD ai messaging

5.21.1. TblAIConversation

Type

Table principale des sessions de conversation IA

Rôle

Stocke chaque session d’échange entre un utilisateur et le système d’intelligence artificielle

Champs notables

* created_at : date de lancement de la session
* context_cache : données contextuelles du prompt
* tokens_used : nombre total de tokens consommés

Relations

* Clé étrangère vers TblUser (initiateur de la conversation)
* Clé étrangère depuis TblAIMessage (messages associés)
Liste des sessions IA Exemple d’une session IA
750
750

5.21.2. TblAIMessage

Type

Table des messages IA individuels

Rôle

Stocke les messages échangés entre l’utilisateur et l’IA dans le cadre d’une session

Champs notables

* content : texte du message
* is_user : booléen indiquant l’auteur (utilisateur ou IA)
* timestamp : date/heure d’envoi
* tokens_in / tokens_out : ressources utilisées
* metadata : informations supplémentaires

Relations

* Clé étrangère vers TblAIConversation (chaque message appartient à une session)
Liste des messages IA Exemple d’un message IA
750
750

Les tables liées à la messagerie IA ne sont pas de ma propre conception initiale.

Elles ont été directement inspirées des structures proposées dans la documentation officielle de Claude AI.

J’ai préféré m’appuyer sur un modèle éprouvé pour garantir une architecture stable et compatible avec les pratiques standards en matière de gestion de sessions conversationnelles.

Je reviendrai plus en détail sur cette partie – ainsi que sur les autres modules de l’application – dans les chapitres suivants, où seront abordés les aspects techniques, fonctionnels et UX liés à cette intégration.

— Retour d’expérience personnel – El Khyari Soulaiman

5.22. Conclusion de la partie Analyse Base de données

Je suis particulièrement satisfait d’être arrivé au terme de cette section, qui a été l’une des plus longues et complexes à élaborer.

Tout au long de cette analyse, j’ai rencontré certaines anomalies et incohérences dans la base de données, que j’ai progressivement corrigées au fil de l’avancement.

J’ai veillé à adopter une structure d’analyse homogène pour chaque ensemble de tables : chaque bloc représente un sous-système fonctionnel du modèle de données.

J’espère que le découpage du MCD et du MLD en plusieurs parties n’a pas altéré la cohérence globale.

Dans le cas contraire, je vous invite à consulter les versions intégrales du MCD et du MLD afin d’avoir une vision complète et fidèle de l’architecture fonctionnelle de l’application.

Cette section de rapport m’a demandé plusieurs jours de travail, et je reconnais qu’elle a été éprouvante.

Je m’excuse si la qualité perçue en fin de chapitre semble légèrement moins aboutie du début, mais j’ai tout mis en œuvre pour rester rigoureux et constant.

Certains points abordés ici peuvent certainement susciter des questions.

Je n’ai pas voulu élargir cette section au-delà de ce qui concerne strictement la base de données relationnelle, mais je reviendrai sur les aspects techniques ou les choix de développement dans les chapitres suivants.

À noter : pour la messagerie instantanée, j’ai fait le choix d’utiliser une base de données non relationnelle, à savoir Firestore de Firebase.

Ce choix fera l’objet d’une explication approfondie dans les chapitres suivants.

Le prochain chapitre sera consacré aux technologies et outils utilisés pour développer l’application Hairbnb ainsi que pour concevoir et structurer ce rapport.

J’espère qu’il apportera un regard plus léger, mais tout aussi enrichissant, que les chapitres précédents.

Merci pour votre attention et votre lecture attentive.

1. Wikipedia. (2025). Merise (informatique). https://fr.wikipedia.org/wiki/Merise_(informatique) Techno-Science. Merise (informatique) - Définition et Explications. https://www.techno-science.net/glossaire-definition/Merise-informatique.html Base de données. (2023). Merise et la conception de bases de données. https://www.base-de-donnees.com/merise/ Developpez.com. FAQ Merise et modélisation de données. https://merise.developpez.com/faq/?page=Generalites Ma Petite Encyclopédie. Méthode MERISE - Définition. https://ma-petite-encyclopedie.org/accueil?lex_item=méthode+MERISE
2. Cartelis. (2024). Qu’est-ce qu’un Modèle Conceptuel de Données (MCD) ? (définition & avantages). https://www.cartelis.com/data-engineering/modele-conceptuel-de-donnees-mcd-definition-fonctionnement/ Base de données. (2024). MCD ou Modèle Conceptuel des Données. https://www.base-de-donnees.com/mcd/ MERISE - Modèle conceptuel des données. UNSW Mathematics. https://web.maths.unsw.edu.au/~lafaye/CCM/merise/mcd.htm