Discussion :

[je viens du sud]

bonjour



sur cette figure, la relation est plusieurs à plusieur car un article peut avoir plusieurs composants et un composant peut appartenir à plusieur articles suivant une quantité.
ce que je comprend pas est que si on prend un composant dont le code = 10 par exemple, est ce qu'on va le trouver dans plusieur article comme le montre la figure ?
normalement la réponse est non car ce composant de code 10ne peut pas se trouver sur 2 articles ou plus au méme temps. est ce que alors la multiplicité est fausse ?

[escartefigue]

Il ne faut pas confondre le type d'entité Merise ou classe d'entité UML (le composant) et l'occurrence d'entité (non matérialisé au niveau conceptuel, mais qui fera l'objet d'une ligne dans la table de la base de données).

Prenons un exemple :

Pour fabriquer un gâteau "quatre quarts", j'ai besoin de farine, de sucre, d'oeufs et de beurre, je vous laisse deviner dans quelles proportions

Pour fabriquer une pâte brisée, j'ai également besoin de farine et de beurre

Il va sans dire que la farine et le beurre que j'ai utilisés pour le quatre quarts ne serviront pas à fabriquer la pâte, mais c'est bien la même farine et le même beurre, au sens "les mêmes composants" qui serviront.

Cela étant dit, la pâte brisée ainsi fabriquée (c'est donc un article qui comprend des composants) est elle même le composant d'autres recettes : tarte aux pommes, tarte aux abricots...

C'est pourquoi il ne faut pas modéliser deux types d'entité distincts [article] et [composant] mais un seul type d'entité, qu'on appelera au choix [article] ou [composant] et une association reflexive.

Ce qui donne, selon la modélisation Merise :



Et selon la modélisation UML :



Et donc le script DDL suivant (ici décliné pour SQL server) :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
CREATE TABLE AR_article(
   AR_ident INT IDENTITY,
   AR_reference CHAR(8) NOT NULL,
   AR_designation VARCHAR(50) NOT NULL,
   PRIMARY KEY(AR_ident),
   UNIQUE(AR_reference)
);
 
CREATE TABLE CO_composer(
   AR_ident_compose INT,
   AR_ident_composant INT,
   CO_quantite DECIMAL(15,2) NOT NULL,
   PRIMARY KEY(AR_ident_compose, AR_ident_composant),
   FOREIGN KEY(AR_ident_compose) REFERENCES AR_article(AR_ident),
   FOREIGN KEY(AR_ident_composant) REFERENCES AR_article(AR_ident)
);

[je viens du sud]

merci pour votre réponse,
est ce que je peux modéliser ce modéle par une relation refléxive ?

[escartefigue]

Pour des vêtements, je ne pense pas qu'une association réflexive soit le bon modèle : il n'y a pas de récursivité.
Selon les attributs communs ou spécifiques aux pantalons, jupes, pulls et autres vêtements, on créera soit une entité-type unique, soit des sous-types.
Pour les matériaux (tissus, fil, boutons...) on aura probablement une entité-type unique, avec des attributs tels que l'unité de mesure de la quantité (mètre linéaire pour le fil, mètre carré pour les tissus, centaine pour les boutons, pièce pour les fermetures éclair...) associée à un typage (type de matériau)

[je viens du sud]

Pour des vêtements, je ne pense pas qu'une association réflexive soit le bon modèle : il n'y a pas de récursivité.
Selon les attributs communs ou spécifiques aux pantalons, jupes, pulls et autres vêtements, on créera soit une entité-type unique, soit des sous-types.
Pour les matériaux (tissus, fil, boutons...) on aura probablement une entité-type unique, avec des attributs tels que l'unité de mesure de la quantité (mètre linéaire pour le fil, mètre carré pour les tissus, centaine pour les boutons, pièce pour les fermetures éclair...) associée à un typage (type de matériau)

bonjour et merci pour votre réponse,
pouvez vous m'aider avec un shcéma pour que ca soit plus clair pour moi
merci

[escartefigue]

Les étapes préalables à la modélisation sont la définition du dictionnaire de données puis la rédaction des règles de gestion.
Le tout devant être validé par la maîtrise d'ouvrage.

Comme vous n'avez rien communiqué de cet ordre, partons sur un exemple

Dictionnaire de données
MODELE : article commercialisé par l'entreprise et possédant une référence unique.
TAILLE : dimensions d'un modèle. Un modèle peut être décliné en plusieurs tailles
COULEUR : couleurs proposées pour une taille d'un modèle. Il peut y avoir plusieurs couleurs, et, facultativement, une couleur dominante.
Etc.
Dans la vraie vie, le dictionnaire de données contient tous les attributs (qui deviendront les colonnes des tables) avec leurs caractéristiques (type, longueur, nombre de décimales, exemples de contenu...)

Règles de gestion
R001 : un modèle se décline en au moins une taille et une taille est la déclinaison d'un et un seul modèle
R002 : une taille d'un modèle est proposée en au moins une couleur et une couleur peut être proposée pour plusieurs tailles
R003 : etc.

À partir de là, on peut établir le modèle conceptuel, ici j'ai utilisé l'excellent Looping, très complet, facile d'utilisation et, ce qui ne gâche rien, gratuit.

Ce qui donne le MCD suivant :