Discussion :

[Manequin]

Bonjour/Bonsoir les développeurs, je viens d’être recruté dans une petite entreprise qui s’occupe de l’organisation des événements(Mariages, baptêmes, anniversaires, etc.)
Pour cela, elle met à la disposition des clients :
- Des salles de fêtes ;
- Le service traiteur ;
- Les décorations ;
- La sonorisation.
Pour avoir l’un des service, un client passe sa réservation en ligne et la commande est validée par un administrateur de la plateforme.
Je vous présente ici le MCD de la future base de données qui va stocker les données de la plateforme.


Merci pour vos lumières.

Cordialement

[escartefigue]

Bonsoir Manequin,

Le MCD doit être le reflet exact des règles de gestion collectées auprès de et validées par les experts du métier.
Or vous n'avez communiqué aucune règle de gestion, il faut donc commencer par la.

Sinon quelques remarques
Cardinalités mini
Si le mini est zéro, alors l'association est obligatoire.
Ainsi, d'après votre MCD, un fournisseur ne peut être créé que s'il livre au moins un produit. Est-ce ce que vous souhaitez ? Ne doit on pas pouvoir créer un fournisseur qui ne livre pas encore de produits mais qu'on souhaite référencer ? Ce sont les règles de gestion validées par les experts métiers qui pourraient le dire...
De même, pour les typologies, on applique en général une cardinalité mini de zéro coté typologie.
Par exemple, rien ne garantit que tous les états de commandes sont présents simultanément à un instant 't' dans la base, d'où un modèle le plus souvent comme suit :
COMMANDE 1,1 --- STATUER --- 0,n ETAT_COMMANDE
Même remarque concernant les catégories de produits

Client
L'adresse n'est pas un attribut, mais un groupe d'attributs, normés par la poste pour ce qui concerne les adresses françaises.
Une petite recherche sur le web vous permettra de retrouver facilement et gratuitement cette norme
Attention : positionner l'adresse au niveau du client signifie que tout client possède une et une seule adresse. Est-ce votre cas ? on n'en sait rien faute de règles de gestion...
Dans la négative, ce qui est probable (souvent il faut prévoir une adresse de facturation, une ou plusieurs adresses de livraison, une adresse du siège social...), il faut modéliser ainsi :
CLIENT 0,n --- posseder --- (1,1) ADRESSE 1,1 --- typer --- 0,n TYPE_ADRESSE
Avec 0 en cardinalité mini coté client, si, pour certains clients, l'absence d'adresse est possible, 1 sinon (encore une fois, seule la règle de gestion permettrait de le savoir)
Les parenthèses autour des cardinalités des adresses vers les client matérialisent l'identification des adresses relativement aux clients (sans client, l'adresse n'existerait pas)
Chaque adresse a un type (adresse de livraison, de facturation, de correspondance, du siège...)

Commande et produit
Sauf si toutes vos commandes sont mono-produit (devinez quoi... les règles de gestion manquent encore ), il manque une entité-type "LIGNE_COMMANDE" qui permettra de rapprocher la facturation et les règlements.
Le modèle classique est le suivant
COMMANDE 1,n --- posseder --- (1,1) LIGNE_COMMANDE 1,1 --- concerner --- 0,n PRODUIT
Là encore, la ligne de commande est identifiée relativement à la commande dont elle dépend (parenthèses autour des cardinalités)
Les attributs de COMMANDE restent le numéro de commande et sa date alors que la LIGNE_COMMANDE aura pour attribut la quantité commandée (en lien bien sur avec l'article avec laquelle cette ligne est en relation)

Gestion des personnes
Toutes les personnes, clients, fournisseurs, administrateurs, tiers... partagent des attributs en commun.
Il faut donc utiliser l'héritage avec, dans le surtype, les attributs communs à toutes les personnes et, dans chaque sous-type ce qui est spécifique aux fournisseurs, aux clients, aux administrateurs...
Voir ici pour la modélisation d'un héritage

Client et Facture
Le modèle adhoc pour le règlement des factures est le suivant
CLIENT 0,n --- effectuer --- 1,1 REGLEMENT 1,n --- concerner --- 0,n FACTURE
................................................1,1│
.....................................................└---utiliser --- 0,n MOYEN_PAIEMENT
Là encore, les cardinalités dépendent des règles de gestion (une facture peut elle être réglée en plusieurs fois ?...)
Les attributs de l'entité-type REGLEMENT sont la date du règlement, la devise, le montant
Le moyen de paiement, en lien avec le règlement, permet d'identifier si le paiement est effectué en espèces, par chèque, traite, billet à ordre ou tout autre moyen


Produit
Il ne faut surtout pas répéter l'attribut "photo", la modélisation doit être la suivante
PRODUIT 0,n --- représenter ---(1,1) PHOTO
Là encore, la photo n'existe que si le produit existe, d'où l'identification relative matérialisée par les parenthèses

[Manequin]

Merci beaucoup pour votre prompte réaction et de votre brillant exposé.
je vais écrire les règles de gestion et modifier le MCD pour proposer demain.

Merci encore.

Cordialement.

[Manequin]

Bonjour les développeurs,

Règles de gestion
- Un client peut passer la réservation de location d’une salle de fête à une date donnée et durant une plage horaire donnée.
- Un client peut passer la réservation de location d’un service traiteur à une date donnée et durant une plage horaire donnée.
- Un client peut passer la réservation de location d’une décoration à une date donnée et durant une plage horaire donnée.
- Un client peut passer la réservation de location d’une sonorisation à une date donnée et durant une plage horaire donnée.
- Un client peut passer la réservation de location d’une salle de fête ,d’un service traiteur, d’une décoration et d’une sonorisation à une date donnée et durant une plage horaire donnée.
- Un client peut annulée sa réservation.
- Administrateur valide les réservations passées par les clients. Une réservation peut-être : en cours, livrée ou annulée.
- Un fournisseur peut être enregistré même s’il n’a pas de produit à livrer.
- Un produit appartient à une et une seule catégorie.
- Une ligne de commande peut concerner plusieurs produits.
- Un client peut régler sa facture par virement, par chèque, par mobile money ou par orange money.
- Plusieurs clients peuvent passer la réservation d’une même salle de fêtes ou d’un autre service le même si leur plage horaire est différente.(Exemple : un client peut passer la réservation de la salle des fêtes le 31/12/2019 de 8h à 12h. L’autre sollicite la même salle de fête de 13h à 16h).



Cordialement.

[escartefigue]

Bonjour,

Il n'y a guère de développeurs qui traînent leur guêtres dans ce secteur, mais ça n'est pas grave


Les règles de gestion pointent le bout de leur nez
Mais...
On peut il faut encore améliorer ça :

• pour chaque association, il faut à minima une règle par "patte", soit, pour une association binaire, 2 règles de gestion.
  Par exemple, pour la relation (effectuer) entre [CLIENT] et [REGLEMENT] les règles correspondant aux cardinalités du MCD sont
  - un client peut effectuer plusieurs règlements
  - un règlement est effectué par un et un seul client
  Le verbe utilisé pour nommer l'association étant repris pour décrire ces règles de gestion
• dans certains cas, des règles de gestion supplémentaires sont requises, par exemple :
  - pour décrire les dépendances entre associations (ex : seul le client qui passe la commande peut effectuer le règlement)
  - pour décrire les dépendances entre les sous-types (ex : un client peut également être un fournisseur ou encore, un administrateur ne peut être ni client ni fournisseur)
• à chaque règle de gestion, on attribue un n°, ce qui en permettra un suivi plus aisé, par exemple :
  R001 : un client peut effectuer plusieurs règlements
  R002 : un règlement est effectué par un et un seul client

Vos premières règles de gestion décrivent les différents types de prestation possibles (chacun fera l'objet d'une ligne de commande), il n'est pas nécessaire de faire une règle pour chaque type sauf si certains types ont des règles particulières ce qui ne semble pas être le cas. Est-ce que lorsqu'un client réserve plusieurs prestations (une salle, une sono, une déco...) toutes ces prestations couvrent la même période ?
Selon le cas, la période sera attribut de la commande ou de la ligne de commande.


Quelques autres remarques :
Personne
Puisque vous avez créé une relation entre la personne et le sexe, alors l'attribut sexe n'a plus sa place dans l'entité-type personne
Une autre solution pour ce genre d'attributs dont la liste de valeurs possible est très restreinte, est de ne pas modéliser d'entité-type sexe, mais de créer une contrainte de type "check".


Produit
Attention : l'attribut caractéristiques mis au pluriel laisse à penser qu'il s'agirait d'une liste de valeurs. À ne surtout pas faire.
Si nécessaire, créez un nouveau type d'entité et une nouvelle association : [PRODUIT]1,n --- (caractériser) ---0,n [CARACTERISTIQUES]
Vu que le prix est un attribut de produit, alors il est invariant quelque soit la quantité, le client, la date... ce qui est rarement le cas. À vérifier.


Symbolique utilisée
Attention : l'usage des flèches est réservé aux CIF, les pattes des associations ne doivent pas être fléchées

[fsmrel]

Bonsoir,

Il n'y a guère de développeurs qui traînent leur guêtres

Untel traîne ses guêtres dans les salles d’opération (quand il arrive à franchir les défilés des manifestants se trouvant sur sa route) et préférerait les traîner chez DVP ; en tout cas dans ce genre de situation, la bilocation est impossible...

Attention : l'usage des flèches est réservé aux CIF, les pattes des associations ne doivent pas être fléchées

Il n’y a pas franchement de norme Merise à ce sujet. L’AFCET se sert de la flèche pour les identifiants relatifs et pour sa part, Nanci (papa de WinDesign) l’utilise pour les dépendances fonctionnelles merisiennes (cf. Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), page 116, figure 7.22). La dépendance fonctionnelle merisienne n’a qu’un vague rapport avec la dépendance fonctionnelle de la théorie relationnelle (va justifier l’axiome d’augmentation chez Merise, alors qu’il est fondamental en relationnel, sans lui pas de théorie des dépendances, impossibilité de calculer les fermetures des DF, donc l’ensemble des clés, donc de vérifier la BCNF, etc...)


Je vais essayer de trouver un creux pour voir le problème des recouvrements d’intervalles et des bilocations (par exemple, deux clients effectuant la même réservation de salle à T).

 

[fsmrel]

Une ligne de commande peut concerner plusieurs produits.

Il est d’usage qu’une ligne de commande concerne au moins et au plus un produit.


Une réservation est à considérer comme un produit, d’accord. Y a-t-il des produits autres, c’est-à-dire qui ne sont pas concernés par la dimension temporelle (intervalles de temps) ? (par exemple un bouquet de fleurs, un gâteau, etc.)


 

[Manequin]

Bonsoir les développeurs. Une fois de plus merci pour votre précieux temps.

Règles de gestion revues
RG 1 : Un client passe au moins une commande et peut passer plusieurs.
RG 2 : Une commande est passée par au plus un client.
RG 3 : un client effectue peut ne pas effectuer un règlement et peut effectuer plusieurs règlements.
RG 3 : un règlement est effectuer par au plus un client.
RG 4 : un règlement concerne au moins une facture.
RG 5 : un règlement utilise un et un seul moyen de payement.
RG 6 : une facture peut ne pas être concernée par un règlement et peut être réglé plusieurs fois.
RG 7 : un mode de paiement peut ne pas être utilisé et peut utiliser par un règlement.
RG 8 : une facture appartient au moins à une commande.
RG 9 : une commande appartient au moins à une facture.
RG 10 : une commande est validée par un et un seul administrateur.
RG 11 : un administrateur valide au moins un commande.
RG 12 : une commande est concernée un et un seul état.
RG 13 : Un état commande peut ne pas être concerné par une commande et peut être concernée par plusieurs commande.
RG 14 : une commande possède au moins une ligne de commande.
RG 15 : une ligne de commande est possédée par une et une seule commande.
RG 16 : une ligne de commande contient au plus un produit.
RG 17 : un produit ne pas contenir une ligne de commande et peut contenir plusieurs lignes de commande.
RG 18 : un produit appartient à une et une seule catégorie.
RG 19 : une catégorie peut pas avoir de produit et peut avoirs plusieurs produits.
RG 20 : un produit peut ne pas être représenté par une photo et peut être représenté par plusieurs photos.
RG 21 : une photo est représentée par un et un seul produit.
RG 22 : un fournisseur peut ne pas livrer un produit et peut livrer plusieurs produits.
RG 23 : un produit est livré par au moins un fournisseur.
RG 24 : seul le client qui passe la commande peut effectuer le règlement
RG 25 : un client peut également être un fournisseur.
RG 26 : un administrateur ne peut être ni client ni fournisseur.


MCD revu


Cordialement !

[escartefigue]

Bonsoir,

Puisque la règle 25 stipule :

RG 25 : un client peut également être un fournisseur

et que la règle 26 indique :

RG 26 : un administrateur ne peut être ni client ni fournisseur.

Alors il faut modifier l'héritage
première spécialisation (XT) : administrateur ou non administrateur
deuxième spécialisation qui concerne les non administrateurs seulement (T) client et/ou fournisseur

@Fsmrel : bon courage, ça doit pas être marrant de devoir ajouter les soucis de santé aux soucis de transport, surtout à Paris
et, quand je disais qu'il n'y avait guère de développeurs... je ne parlais pas tant du nombre de contributeurs dans cette section, mais plutôt du fait que ce sont rarement les développeurs qui participent à l'élaboration du modèle de données

@Manequin : vous n'avez pas tenu compte de mes remarques précédentes dans votre nouveau MCD. Mais bon, pour l'instant, priorité aux règles de gestion

[Manequin]

... quand je disais qu'il n'y avait guère de développeurs... je ne parlais pas tant du nombre de contributeurs dans cette section, mais plutôt du fait que ce sont rarement les développeurs qui participent à l'élaboration du modèle de données

Les employeurs ne comprennent pas ça comme ça ici à Yaoundé.

@Manequin : vous n'avez pas tenu compte de mes remarques précédentes dans votre nouveau MCD. Mais bon, pour l'instant, priorité aux règles de gestion

J'apporte les modifications demain.

Cordialement.

[Manequin]

MCD revue :



Cordialement.

[fsmrel]

Bonsoir,


On déboule manifestement sur la modélisation du lettrage (rapprochement des lignes de commande et des lignes de facture), telle qu’en parle brièvement Michel Diviné dans Parlez-vous Merise ?, pages 58,59.

La partie correspondante du MCD pourrait être celle-ci :

Le code SQL correspondant étant celui-ci (ce que produit l’AGL étant à retoucher, car n’étant pas à même de produire exactement ce code) où — grâce à la propagation systématique de l’attribut personneId par l’identification relative des entités-types — l’on sait démontrer que les lignes de commande et de facture sont bien celles d’un même client, ainsi que les règlements :

CREATE TABLE PERSONNE
(
        personneId            INTEGER           NOT NULL
      , personneNom           VARCHAR(48)       NOT NULL
      , personeAdresse        VARCHAR(48)       NOT NULL
    , CONSTRAINT PERSONNE_PK PRIMARY KEY(personneId)
);

CREATE TABLE FOURNISSEUR
(
        personneId            INTEGER           NOT NULL
      , tauxRemise            NUMERIC(4,2)      NOT NULL
    , CONSTRAINT FOURNISSEUR_PK PRIMARY KEY(personneId)
    , CONSTRAINT FOURNISSEUR_PERSONNE_FK FOREIGN KEY(personneId) 
          REFERENCES PERSONNE(personneId) 
              ON DELETE CASCADE
);

CREATE TABLE CLIENT
(
        personneId            INTEGER           NOT NULL
      , conditionsTarifaires  VARCHAR(48)       NOT NULL
    , CONSTRAINT CLIENT_PK PRIMARY KEY(personneId)
    , CONSTRAINT CLIENT_PERSONNE_FK FOREIGN KEY(personneId) 
          REFERENCES PERSONNE(personneId) 
              ON DELETE CASCADE
);

CREATE TABLE COMMANDE
(
        personneId            INTEGER           NOT NULL
      , commandeId            INTEGER           NOT NULL
      , commandeNo            CHAR(12)          NOT NULL 
      , commandeDate          DATE              NOT NULL
      , commandeMontant       INTEGER           NOT NULL
    , CONSTRAINT COMMANDE_PK PRIMARY KEY(personneId, commandeId)
    , CONSTRAINT COMMANDE_AK UNIQUE(commandeNo)
    , CONSTRAINT COMMANDE_CLIENT_FK FOREIGN KEY(personneId) 
          REFERENCES CLIENT(personneId)
);

CREATE TABLE LIGNE_COMMANDE
(
        personneId            INTEGER           NOT NULL
      , commandeId            INTEGER           NOT NULL
      , ligneCommandeId       INTEGER           NOT NULL
      , quantiteCommandee     INTEGER           NOT NULL
      , livraisonDate         DATE              NOT NULL
    , CONSTRAINT LIGNE_COMMANDE_PK PRIMARY KEY(personneId, ligneCommandeId)
    , CONSTRAINT LIGNE_COMMANDE_COMMANDE_FK FOREIGN KEY(personneId, commandeId) 
          REFERENCES COMMANDE(personneId, commandeId)
);

CREATE TABLE FACTURE
(
        personneId            INTEGER           NOT NULL
      , factureId             INTEGER           NOT NULL
      , factureNo             CHAR(12)          NOT NULL
      , factureDate           DATE              NOT NULL
      , factureMontant        INTEGER           NOT NULL
    , CONSTRAINT FACTURE_PK PRIMARY KEY(personneId, factureId)
    , CONSTRAINT FACTURE_AK UNIQUE(factureNo)
    , CONSTRAINT FACTURE_CLIENT_FK FOREIGN KEY(personneId) 
          REFERENCES CLIENT(personneId)
);

CREATE TABLE REGLEMENT
(
        personneId            INTEGER           NOT NULL
      , reglementId           INTEGER           NOT NULL
      , reglementDate         DATE              NOT NULL
      , reglementMontant      INTEGER           NOT NULL
    , CONSTRAINT REGLEMENT_PK PRIMARY KEY (personneId, reglementId)
    , CONSTRAINT REGLEMENT_CLIENT_FK FOREIGN KEY(personneId)
          REFERENCES CLIENT(personneId)
);

CREATE TABLE LIGNE_FACTURE
(
        personneId            INTEGER           NOT NULL
      , factureId             INTEGER           NOT NULL
      , ligneFactureId        INTEGER           NOT NULL
      , reglementId           INTEGER           NOT NULL
      , quantiteFacturee      INTEGER           NOT NULL
    , CONSTRAINT LIGNE_FACTURE_PK PRIMARY KEY(personneId, ligneFactureId)
    , CONSTRAINT LIGNE_FACTURE_FACTURE_FK FOREIGN KEY(personneId, factureId) 
          REFERENCES FACTURE(personneId, factureId)
    , CONSTRAINT LIGNE_FACTURE_REGLEMENT_FK FOREIGN KEY(personneId, reglementId) 
          REFERENCES REGLEMENT(personneId, reglementId)
);

CREATE TABLE LETTRAGE
(
        personneId            INTEGER           NOT NULL
      , ligneCommandeId       INTEGER           NOT NULL
      , ligneFactureId        INTEGER           NOT NULL
    , CONSTRAINT LETTRAGE_PK PRIMARY KEY(personneId, ligneCommandeId, ligneFactureId)
    , CONSTRAINT LETTRAGE_LIGNE_COMMANDE_FK FOREIGN KEY(personneId, ligneCommandeId) 
          REFERENCES LIGNE_COMMANDE(personneId, ligneCommandeId)
    , CONSTRAINT LETTRAGE_LIGNE_FACTURE_FK FOREIGN KEY(personneId, ligneFactureId) 
          REFERENCES LIGNE_FACTURE(personneId, ligneFactureId)
);

 

[escartefigue]

Bonjour,

Au sujet des personnes et des adresses.

On a vu que les règles de gestion 25 et 26 stipulent qu'un client peut être aussi fournisseur, mais qu'un administrateur n'est ni l'un ni l'autre.
Par ailleurs, un client comme un fournisseur peuvent être des personnes physique (avec un nom, prénom, date de naissance...) ou morale (avec un SIREN, NIC, code NAF, une raison sociale...)
Il faut donc utiliser l'héritage pour distinguer les PP des PM dont les attributs sont très différents et attribuer des rôles pour lequels on contrôlera, par trigger, qu'il n'y a pas de chevauchement de période entre une période ADMINISTRATEUR et une période d'un autre rôle.
Dans la table issue de l'association EXERCER, on ajoutera la colonne EX_dtdeb comme composante de la PK (en plus de l'identifiant personne et de l'identifiant rôle)

De plus, les clients et fournisseurs de type personne morale ont le plus souvent plusieurs adresses (de livraison, de facturation, de correspondance, de gestion du contentieux...)
d'où l'intérêt d'identifier une entité-type adresse, en lien avec un type d'adresse et dans laquelle on en profite pour appliquer une norme de codification des adresses (ici celle de la poste, à adapter si contexte internationnal)

Pièce jointe 525295

Norme des adresses postales : https://www.presse-poste.laposte.fr/...s%20plis_3.pdf