Discussion :

[monami01]

Bonjour,

Je suis entrain de réalisé un MCD (gestion de vent).

J'ai les entités suivants:

- CLIENT
- PRODUIT
-COMMANDE

Mon question est comment j'associe deux autre entités LIVRAISON et FACTURE avec les entités au-dessus ?

Merci d'avance

[CinePhil]

Si tu vends du vent, tu n'auras pas beaucoup de clients à gérer !

Pour ta gestion des ventes, commence déjà par associer les 3 premières entités que tu as identifiées et propose nous un schéma.
Faire le début du schéma t'aidera sans doute à faire le reste et nous incitera davantage à t'aider.

Surtout que sans spécifications sur le problème posé, c'est quasi impossible, même si ce problème semble classique.

[monami01]

D'abord merci de votre réponse et aussi la corection (Vent) lol.
maintenant je vous présent le schéma :
[CLIENT](0,n)__effectué__(1,1)[COMMANDE](1,n)__contient_(0,n)[PRODUIT]

merci pour la deuxiéme fois.

[CinePhil]

C'est un début mais à mon avis partiel.
Tu trouveras sans doute plein d'exemples sur le net qui confirmeront ce que je vais dire ci-dessous.
Généralement, on divise la Commande (ou la Facture) en deux parties :
- une partie générale appelée Commande (ou Facture) qui contient les renseignements généraux relatifs à l'ensemble de la commande (numéro de commande, adresse et délai de livraison, conditions de paiement, remise générale...)
- des lignes de commande qui contiennent chacune les renseignements relatifs à un produit commandé (référence produit, quantité, prix, remise individuelle, code TVA...)

Ton schéma devrait donc plutôt être celui-ci :
Client -0,n----Passer----1,1- Commande -1,n----Contenir----1,1- LigneCommande -1,1----Concerner----0,n- Produit

Comme tu as pu le remarquer par mes parenthèses, le principe est identique pour la facture. On peut imaginer un principe similaire pour la livraison. Dans les deux cas, il faut avoir conscience qu'une commande n'est pas forcément livrée et/ou facturée en une seule fois.
Tout dépend de ton cahier des charges.

Courage pour la suite.

[monami01]

Merci pour vous explication ca me fait le courage

[monami01]

un chose que j'ai le pris pas bien c est ligne commande . ses cardinalité avec les entités PRODUIT et COMMNADE. Et qui sont-il ses attributs?

[CinePhil]

Une ligne de commande n'est contenue que dans une seule commande et ne concerne qu'un seul produit.
Elle peut avoir pour attribut :
- idLigne, Quantité, Prix HT, TVA, Remise, Commentaires éventuellement

[monami01]

Bonjour,

j ai arrivé presque à la fin de réaliser mon MCD (getion des ventes) .Et j'aimerait bien de vous le montrer .
http://img375.imageshack.us/img375/6...sventeshy5.png


J'attends vous remarques+critiques+des choses à rajouter

d'avence.

[Metafire18]

A mon avis , un identifiant relatif entre l'entité ligneCommande et Commande ne serait pas de trop

[fsmrel]

A mon avis , un identifiant relatif entre l'entité ligneCommande et Commande ne serait pas de trop

Même principe entre Client et Commande. En effet, Commande n'est-elle pas une propriété (multivaluée) de Client ?

[Metafire18]

Une commande peut être passer par un et un seul client
Un client peut passer plusieurs commandes , il peut exister dans le système d'informations avant d'avoir passer une commande

Donc pour moi ses cardinalités entre clients et commandes sont juste

L'entité commande est autonome vis à vis du client , chaque commande concerne un client et s'identifie par son numéro. Il n'y a pas d'ambiguïté possible.

Pour l'entité ligneCommande c'est différent car on retrouve la ligne X dans plusieurs commande donc il nous faut bien le n° de commande pour identifier précisément de quelle ligne il s'agit d'où l'identifiant relatif

[CinePhil]

A mon avis , un identifiant relatif entre l'entité ligneCommande et Commande ne serait pas de trop

Si ce que tu appelles 'identifiant relatif' signifie 'clé étrangère', nous sommes ici dans un MCD qui ne doit pas contenir ce genre d'attribut. Les clés étrangères arriveront au moment du passage au MLD.

[Metafire18]

Je parle bien ici d'un identifiant relatif

Si on fait le passage en MLD avec le MCD actuel la clef primaire de commande migrera dans la table ligneCommande en tant que clef étrangère. Toutefois celle ci ne fera pas partie de la clef primaire

Or dans ce cas si l'on veut identifier chaque ligne précisément il faut que la clef primaire de la table ligneCommande ,une fois la traduction en MLD fait , soit composé du numéro de ligne et du numéro de commande donc on utilise bien un identifiant relatif

[CinePhil]

C'est donc bien ce que je disais : ça ne doit pas figurer dans le MCD.

[Metafire18]

J'ai peur de ne pas comprendre

Comment voulez vous que la traduction en MLD soit correcte si l'on ne spécifie pas clairement par un grand R que la relation est relative?

Si on laisse le MCD comme il est , lors de la traduction en MLD , le numero de commande ne fera pas partie de la clef primaire de la table ligneCommande

[CinePhil]

Je ne vois pas pourquoi !

Prenons un autre exemple :
Dans l'association 'Passer' entre Client et Commande, la cardinalité est 1,1 du côté de la commande.
Passant au MLD, Commande va bien récupérer en clé étrangère la clé primaire du Client.

Dans l'association 'Contenir' entre Commande et LigneCommande, c'est pareil : la LigneCommande va récupérer en clé étrangère la clé primaire de la Commande grâce à la cardinalité 1,1.
Idem pour l'association 'Concerner' entre LigneCommande et Produit et pour toutes les associations présentes ici en fait.

On est dans un MCD, on ne fait pas figurer les clés étrangères.

[Metafire18]

Je ne suis toujours pas d'accord

La relation contenir entre la table commande et ligneCommande est vraiment spécifique.

Si on veut pouvoir faire des affichages de commande de la manière suivante il faudra un identifiant relatif :

Commande 13 :

ligne 1 Chausettes x3
ligne 2 Pantalon x4
ligne 3 Foulard x7

Par cet exemple on constate que pour plusieurs commandes on peut avoir une ligne numéro x. Or si a plusieurs numéros de ligne ont peut associé une quantité etc etc cela est erroné. La solution est donc bien de constitué une clef primaire avec le numéro de la commande et le numéro de la ligne. Les numéros de lignes sont donc relatifs à un numéro de commande ==> identifiant relatif

Pour reprendre l'exemple de la relation entre Client et Commande , ces 2 entités sont tout à fait autonome et ne justifie pas l'utilisation d'un identifiant relatif. Pour chaque numéro de client on obtient un et un seul client et pour chaque numéro de commande on obtient une commande.

Ensuite pour revenir au règle de passage d'un MCD à un MLD , le fait qu'un identifiant soit relatif ou non fait une grosse différence. Ce n'est pas parce qu'on fait migré une clef dans notre table grâce à une cardinalité x,1 que celle ci deviendra clef primaire. Pour qu'elle soit clef primaire lors du passage en MLD il faut déclarer la relation comme relative.

Si l'on veut adopter ta solution il faudrait que chaque numéro de ligne soit numéroté dans l'absolu. C'est à dire qu'un client va recevoir sa commande avec des numéros de ligne égaux à plusieurs milliers après un moment à tourner avec ce système

[CinePhil]

Je ne suis toujours pas d'accord

Moi non plus !

La relation contenir entre la table commande et ligneCommande est vraiment spécifique.

Bof ! Classique je dirais...

Commande 13 :

ligne 1 Chausettes x3
ligne 2 Pantalon x4
ligne 3 Foulard x7

Par cet exemple on constate que pour plusieurs commandes on peut avoir une ligne numéro x.

Ton exemple est de UNE commande et de PLUSIEURS lignes de commande alors que tu dis le contraire !
Et c'est bien comme ça que ça se passe.
Une ligne de commande se rapporte à une seule commande et concerne un seul produit pour une certaine quantité.

En fait, comme suggéré au départ de la discussion, on pourrait considérer au niveau MCD qu'il y a une association 'contenir' de type m,n entre Commande et Produit et qui est porteuse d'informations, notamment la quantité de produit commandée. Cette association se transforme ensuite au niveau MLD en une table associative qui reçoit comme clé primaire double les clés étrangères constituées des clés primaires des deux tables. On n'a alors plus besoin d'un identifiant de ligne de commande séparé.

Or si a plusieurs numéros de ligne ont peut associé une quantité etc etc cela est erroné.

Il y a une quantité associé à chaque numéro de ligne mais bien évidemment plusieurs champs (intersection ligne/colonne) 'quantité' de la table peuvent avoir la même valeur. Il n'y a aucune erreur là-dedans !

La solution est donc bien de constitué une clef primaire avec le numéro de la commande et le numéro de la ligne. Les numéros de lignes sont donc relatifs à un numéro de commande ==> identifiant relatif

Oui ! (ouf !)

Pour reprendre l'exemple de la relation entre Client et Commande , ces 2 entités sont tout à fait autonome et ne justifie pas l'utilisation d'un identifiant relatif.

Ben si : une commande est bien reliée à un et un seul client ! Donc clé étrangère client dans table commande !

Pour chaque numéro de client on obtient un et un seul client et pour chaque numéro de commande on obtient une commande.

Oui bien sûr mais ça n'empèche pas la clé étrangère.

Ensuite pour revenir au règle de passage d'un MCD à un MLD , le fait qu'un identifiant soit relatif ou non fait une grosse différence. Ce n'est pas parce qu'on fait migré une clef dans notre table grâce à une cardinalité x,1 que celle ci deviendra clef primaire.

Non bien sûr !

Pour qu'elle soit clef primaire lors du passage en MLD il faut déclarer la relation comme relative.

Jamais vu de MCD qui mentionne une identification relative. Pour moi cette notion d'identifiant relatif est du verbiage inutile !

Si l'on veut adopter ta solution il faudrait que chaque numéro de ligne soit numéroté dans l'absolu. C'est à dire qu'un client va recevoir sa commande avec des numéros de ligne égaux à plusieurs milliers après un moment à tourner avec ce système

Et alors ? On s'en fout, ce n'est qu'un identifiant que le client ne verra jamais ! Et perso je travaille actuellement sur des tables de plusieurs dizaines de millions de lignes alors quelques milliers...

[fsmrel]

Bonsoir,


J'arrive un peu tard, mais j'ai quand même quelques observations à faire.

Pour l'entité LigneCommande c'est différent car on retrouve la ligne X dans plusieurs commande donc il nous faut bien le n° de commande pour identifier précisément de quelle ligne il s'agit d'où l'identifiant relatif.

Rien n’interdit d’utiliser un identifiant absolu pour l’entité-type LigneCommande, comme l’a fait monami01 avec l’attribut IdLign. Bien entendu, comme une commande comporte plusieurs lignes de commandes, il faut être en mesure de les énumérer. Mais de là à éliminer l’attribut IdLign au bénéfice du couple {NoCommande, NoLigneCommande}, cela demande justification, et ce que vous proposez n’est pas recevable. Voyez en effet les exemples qui suivent.


Exemple 1. Selon Metafire18, au niveau logique on obtient ceci (clé primaire soulignée) :

Code :

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

1
2
3
4
5
NoCommande  NoLigneCommande  CodeProduit  Qte  
    1             1              150       10    
    1             2              220       20  
    2             1              150       15

On utilise ici un numéro de ligne de commande. La clé primaire est composée du couple {NoCommande, NoLigneCommande}, mais il existe une clé alternative {NoCommande, CodeProduit} qu’il ne faudra pas oublier de mettre en œuvre au niveau SQL. Cet exemple est valide, mais il existe d’autres solutions.


Exemple 2. Si l’on revient aux fondamentaux, considérons l’exemple donné par H. Tardieu, A. Rochfeld, R. Colletti, in La Méthode MERISE, Tome 1 Principes et outils. (Les Éditions d’organisation. 5ème impression, juin 1991) :





On constate qu’il n’y a pas de numéro de ligne de commande. Au niveau logique on obtient ceci, en conservant les noms des attributs de l’exemple précédent) :

Code :

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

1
2
3
4
NoCommande  CodeProduit  Qte 
    1           150       10  
    1           220       20   
    2           150       15

La clé primaire est composée du couple {NoCommande, CodeProduit}. Cette solution est plus économique et montre que dans l’absolu, le concept de numéro de ligne de commande n’est pas essentiel et qu’au nom du rasoir d’Ockham il peut disparaître (Ockham a écrit il y a près de 700 ans : pluralitas non est ponenda sine necessitate, ce que nous pouvons interpréter ici comme : Ne multipliez pas les propriétés au-delà du nécessaire.)

C’est ainsi que TheLeadingEdge attire l’attention de harbonne et Cinephil sur un exemple similaire, qui respecte le principe d’essentialité :

.
Je ne suis pas sur qu'1 entité LigneFacture se justifie.
On est au niveau MCD. L'association FACTURER est probablement de cardinalité n,n et deviendra 1 table (''LigneFacture'' si tu veux) au niveau physique.

Exemple 3. Au niveau logique, la variation monami01 est la suivante :

Code :

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

1
2
3
4
IdLign  NoCommande  CodeProduit  Qte 
    1        1          150       10     
    2        1          220       20 
    3        2          150       15

La clé primaire est composée du singleton {IdLign} mais, comme dans le cas de l’exemple 1, il existe une clé alternative {NoCommande, CodeProduit} qu’il ne faudra pas oublier de mettre en œuvre au niveau SQL. Une fois de plus cet exemple est valide, mais ne respecte pas le principe d’essentialité.

Une commande peut être passer par un et un seul client
Un client peut passer plusieurs commandes, il peut exister dans le système d'informations avant d'avoir passer une commande.
Donc pour moi ses cardinalités entre clients et commandes sont juste.

Bien sûr. Et l’exemple 1 ci-dessus n’est pas invalidé. Simplement, l’exemple 2 est conceptuellement plus satisfaisant et il n’a pas à subir un éventuel coup de rasoir d’Ockham. En revanche, il présente moins de souplesse. Supposons en l’occurrence que la base de données soir en production. Arrive un beau jour une nouvelle règle de gestion qui n’a pas grand impact sur le MCD dans le cas des exemples 1 et 3 : on doit désormais connaître le détail des engagements par ligne de commande. Autrement dit, on s’engage pour une quantité Q1 du produit P1 avec la mention "disponible en magasin", on s’engage pour une quantité Q2 du même produit P1 avec la mention "en cours d’expédition à destination du magasin", on s’engage pour une quantité Q3 du même produit P1, avec la mention "en cours de fabrication", etc.

Dans le cas de l’exemple 1, le MCD pourrait être le suivant (noter l’utilisation de l’identification relative, outil utilisé : PowerAMC).





Dans le cas de l’exemple 3, on a un aménagement analogue.
Dans le cas de l’exemple 2, ça coince si on utilise Merise : l’association-type Commander Produit doit être transformée en entité-type. Certes, finalement ça n’est pas trop compliqué, mais la sémantique en prend un coup.

L'entité commande est autonome vis à vis du client , chaque commande concerne un client et s'identifie par son numéro. Il n'y a pas d'ambiguïté possible.

L’entité-type Commande n’est pas autonome. Si elle l’était, cela voudrait dire qu’une commande pourrait changer de client, ce qui n’est pas très raisonnable. Viscéralement la relation qu’entretiennent un client et une commande est plus forte que celle qu’entretiennent par exemple une ligne de commande et un produit.

Jamais vu de MCD qui mentionne une identification relative. Pour moi cette notion d'identifiant relatif est du verbiage inutile !

L’identification relative est disponible avec des outils tels que Win’Design, PowerAMC, ou avec les poids lourds orientés IEF (Information Engineering Facility) tels que CA Gen (anciennement Composer, COOL:Gen, etc.) L’identification relative permet de mieux rendre compte de la sémantique des objets, de leur poids relatif : une ligne de commande est identifiée relativement à la commande pour montrer qu’elle n’en est qu’une propriété. De même, un engagement sur ligne de commande est identifié relativement à la ligne de commande pour montrer qu’à son tour elle n’est qu’une propriété de cette dernière, etc.

Il y a pas mal de choses à dire concernant l'identification relative, quant aux retombées bienfaisantes qu'on peut en tirer au niveau non plus conceptuel, mais opératoire.

Par exemple, identifions la commande relativement au client (ce qui sémantiquement est parfaitement légitime), la ligne de commande relativement à la commande et l'engagement relativement à la ligne de commande.

A quoi peut alors ressembler la requête SQL permettant de poser la question suivante et quelles conséquences peut on en attendre au plan de la performance :

Pour le client Albert, quels sont les commandes pour lesquelles les engagements vérifient l'état : "disponible en magasin" ?

(Autrement dit, combien de tables participent nécessairement aux jointures ?)

[CinePhil]

Le lien vers la présente discussion figurant dans ce message de f-leb m'a remis en mémoire que j'y avais appris la notion d'identification relative qui m'était inconnue il y a un an.

Je présente donc mes excuse avec retard pour avoir dit que c'était du "verbiage inutile" puisque depuis j'ai préconisé dans d'autres messages l'utilisation de l'identification relative, notamment en cas d'héritage de tables.

Mais ce qui me fait réveiller cette vieille discussion est la dernière question de fsmrel :

Il y a pas mal de choses à dire concernant l'identification relative, quant aux retombées bienfaisantes qu'on peut en tirer au niveau non plus conceptuel, mais opératoire.

Par exemple, identifions la commande relativement au client (ce qui sémantiquement est parfaitement légitime), la ligne de commande relativement à la commande et l'engagement relativement à la ligne de commande.

A quoi peut alors ressembler la requête SQL permettant de poser la question suivante et quelles conséquences peut on en attendre au plan de la performance :

Pour le client Albert, quels sont les commandes pour lesquelles les engagements vérifient l'état : "disponible en magasin" ?

(Autrement dit, combien de tables participent nécessairement aux jointures ?)

La réponse est que comme l'identifiant du client et de la commande sont propagés par identification relative jusqu'à la table des engagments, il suffit de joindre cette dernière directement à la table des clients, sans passer par des jointures avec LigneCommande et Commande :

Code SQL :

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

1
2
3
4
5
SELECT DISTINCT e.CommandeID
FROM EngagementLigneCommande AS e
INNER JOIN Client AS c ON e.ClientId = c.ClientId
WHERE c.NomClient = 'Albert'
  AND e.EtatEngagement = 'Disponible en magasin'

Il n'y a donc que deux tables qui entrent en jeu, avec toutefois un léger bémol : cette requête donnera les commandes d'Albert sur lesquelles on peut effectuer une livraison à partir du magasin mais ne dit pas quels produits pourront être livrés et en quelle quantité.

L'identification relative fera que :
- La clé primaire de la table Commande aura 2 colonnes (ClientId, CommandeId).
- Celle de la table LigneCommande en aura trois (ClientId, CommandeId, LigneCommandeId).
- Celle de la table EngagementLigneCommande en aura 4 (ClientId, CommandeId, LigneCommandeId, EngagementLigneCommandeId).

J'ai lu récemment, chez SQLPro je crois, que les clés primaires composées, jusqu'à deux voire trois colonnes ça va encore mais au delà ça craint (complexité au moins, performances peut-être ?).

Qu'en est-il d'après vos expériences expertes ?