Discussion :

[Heledir]

Bonjour à toutes et à tous,

Je débute en modélisation de base de données. J'ai toujours travaillé directement avec ACCESS et aujourd'hui, j'aimerai professionnaliser ma démarche. Sur un projet je bloque sur les entitées CLIENT DESTINATAIRE, COMMANDE et COMMERCIAL. C'est un commercial qui prend la commande en se rendant directement chez le client. Je ne suis pas sur que le MCD joint reflète cette phrase :

CLIENT DESTINATAIRE passe COMMANDE au COMMERCIAL

Les commerciaux ont des clients atitrés, mais pour une raisons x un commercial peut passer chez les clients d'un autre.

Je suis preneur de toutes les propositions que vous voudrez bien faire pour faire évoluer mon MCD. Même si je dois tout recommencer, n'hésitez pas car, c'est en modélisant que l'on devient "modéliseron".

Merci !

[fsmrel]

Bonjour,

Les commerciaux ont des clients atitrés, mais pour une raisons x un commercial peut passer chez les clients d'un autre.

S’il s’agit de savoir si la commande a été passée auprès d'un commercial attitré ou non, il faut d’abord savoir qui est le commercial attitré du client. Cela revient à établir une relation entre Commercial et Client :

[ Client Destination ]---1,1---(R)---0,N---[ Commercial ]

c'est en modélisant que l'on devient "modéliseron"

Et c'est en sciant que Léonard devint...

[Heledir]

Merci fsmrel,

Il ne s'agit pas spécialement de s'avoir si c'est le commercial attitré qui passe la commande, mais savoir quel commercial passe la commande, même si le client à un commercial attitré. Par défaut, on propose le commercial attitré.

Je me prend surement la tête pour pas grand chose, mais je ne comprends pas. C'est le client qui commande à un commercial. Mais c'est le commercial qui passe la commande à sa société.

C'est là que je fais tilt. Je ne gère qu'une entité commande, Client destinataire et commercial. J'établis des relations :

[ Client Destination ]---1,1---(R)---1,n---[ Commercial ]

[ Client Destination ]---1,n---(R)---1,1---[ Commande ]

[ Commercial ]---1,n---(R)---1,1---[ Commande ]

Dans cette version, pour chaque commande, je connais le Client destinataire, qui a passé la commande.

Ce qui me gène, c'est comment dois-je poser mes relations au départ pour répondre au cahier des charges :

Le commercial va chez le client, il remplit un bon de commande avec le client, puis il téléphone au siège pour passer la commande.

Lorsque j'aurai compris la logique pour établir les relations, le reste ne devrait pas me poser de problème.

J'ai tenté un autre MCD, mais je ne sais toujours pas comment j'ai formuler mes relations pour faire le MCD.

Merci de ton aide !

[fsmrel]

Bonsoir,

Par défaut, on propose le commercial attitré.

Comment sait-on que le client Tartempion a pour commercial attitré Gaston ?

Quand je propose :

[ Client Destination ]---1,1---(R)---1,n---[ Commercial ]

la relation R se lit ainsi :

« Avoir pour commercial attitré ».

Sous forme d’instances :

Le client Tartempion a pour commercial attitré Gaston.

Le client M. de Mesmaeker a pour commercial attitré Fantasio.

Pour la partie prise de commande, quand vous écrivez :

Le commercial va chez le client, il remplit un bon de commande avec le client, puis il téléphone au siège pour passer la commande

S’agit-il de connaître l’état de la commande au temps T ("bon de commande rempli", "commande prise en compte au siège") ? Si tel est le cas, reste à définir un attribut Statut pour l’entité-type Commande.

Ainsi, les instances de Commande pourront être successivement les suivantes (la 2e venant en son temps remplacer la 1re) :

La commande 123 prise par Gaston et concernant le client M. de Mesmaeker a le statut "bon de commande rempli",

La commande 123 prise par Gaston et concernant le client M. de Mesmaeker a le statut "commande prise en compte au siège".

En notant que, si l’on sait que c’est Gaston qui s’est occupé de M. de Mesmaeker, le commercial attitré de Tartempion n'en demeure pas moins Fantasio.

Comme le rappelle JPhi33, le MCD est statique.
Pour aller plus loin en ce qui concerne l'aspect dynamique, il faudra peut-être en passer par le MCT.

Si vos interrogations demeurent, il faudra qu’on mette JPhi33 sur le coup...

[Heledir]

Merci fsmrel,

je crois que je commence à comprendre. Le MCD est une représentation statique du SI. Mais il faut garder à l'esprit que les choses évoluent dans le temps, ce que je ne faisais pas réellement. Une commande est prise, que devient-elle ? Plus particulièrement comment va-t-on pouvoir gérer l'évolution de celle-ci ?

L'entité statut de la commande : commande remplie, commande transmise, en préparation, en livraison puis livrée est la réponse au cahier des charges le commercial va chez le client, prend une commande et la transmet au siège…

C'est en fait le MCT qui établit cet aspect des évènements. Sur un projet très compliqué, le MCT semble obligatoire. Comme je débute, je vais essayer d’en faire un pour ne pas oublier quelque chose et je proposerai un nouveau MCD.

Encore une fois merci de votre aide.

[Heledir]

Bonjour à toutes et à tous,

me revoilà après avoir réfléchi sur le MCD et regarder sur le papier le MCT du projet. Après ces deux étapes, j’ai sorti les 11 relations issues du MCD. Comme c’est la première fois, je ne sais pas si c’est l’usage de les établir toutes. A vous de me dire.

J’ai le sentiment que le résultat pourrait répondre au cahier des charges, mais si le MCD doit être amélioré, je serai content de suivre tout vos conseils pour me perfectionner.

Relations :

[ Client Destination ]---1,1---( Dépendre )---0,n---[ Payeur ]

Un CLIENT DESTINATION dépend de 1 et 1 seul CLIENT PAYEUR.
Un CLIENT PAYEUR a 0 ou plusieurs CLIENT DESTINATION.


[ Client Destination ]---1,1---( Appartenir )---0,n---[ Tournée ]

Un CLIENT DESTINATION appartient à une et une seule TOURNEE.
Une TOURNEE à 0 ou plusieurs CLIENT DESTINATION.


[ Client Destination ]--- 0,n ---( Passer )--- 1,1---[ Commande ]

Un CLIENT DESTINATION passe 0 ou plusieurs COMMANDE.
Une COMMANDE est passée par 1 et 1 seul CLIENT DESTINATION.


[ Client Destination ]--- 1,1---( Visiter )--- 0,n ---[ Commercial ]

Une CLIENT DESTINATION est visité par 1 et 1 seul COMMERCIAL.
Un COMMERCIAL visite 0 ou plusieurs CLIENT DESTINATION.


[ Commercial ]--- 1,1---( Affecter )--- 0,n ---[ Emplacement ]

Un COMMERCIAL est affecté sur 1 et 1 seul EMPLACEMENT.
Un EMPLACEMENT est affecté à 0 ou plusieurs COMMERCIAL.


[ Commande ]--- 1,1---( Gérer )--- 0,n ---[ Commercial ]

Une COMMANDE est gérée par 1 et 1 seul COMMERCIAL.
Un COMMERCIAL gère 0 ou plusieurs COMMANDE.


[ Commande ]--- 1,1---( Contenir )--- 0,n ---[ Tournée ]

Une COMMANDE contient 1 et 1 seule TOURNEE.
Une TOURNEE contient 0 ou plusieurs COMMANDE.


[ Commande ]--- 1,1---( Posséder )--- 0,n ---[ Statut ]

Une COMMANDE possède 1 et 1 seul STATUT.
Un STATUT est possédé par 0 ou plusieurs COMMANDE.


[ Commande ]--- 1,n---( Composer )--- 0,n ---[ Produit ]

Une COMMANDE est composée de 1 ou plusieurs PRODUIT.
Un PRODUIT peut composer 0 ou plusieurs COMMANDE.


[ Tournée ]--- 1,1---( Attribuer )--- 0,n ---[ Livreur ]

Une TOURNEE est attribué à 1 et 1 seul LIVREUR.
Un LIVREUR se voit attribuer 0 ou plusieurs TOURNEE.


[Produit ]--- 1,1---( Provenir )--- 0,n ---[ Famille ]

Un PRODUIT provient d’1 et 1 seule FAMILLE.
Une FAMILLE est composée de 0 ou plusieurs PRODUIT.

merci pour votre disponibilité,
Thierry

[fsmrel]

Bonsoir Heledir,


Votre MCD a tout l'air d'être satisfaisant. Quelques remarques en passant :

1) Faites figurer les attributs de chaque entité-type, à savoir les propriétés naturelles (nom du client, son Siret, adresse, la date de commande, le taux TVA, etc.) ainsi que les identifiants qui doivent être strictement artificiels, attribués par le système et donc invariants : par exemple, un numéro de Siret peut être corrigé par l’INSEE et se trouve de facto disqualifié pour identifier le client.

2) Attention à la redondance (donc aux incohérences), engendrée par le pseudo-cycle impliquant les entités-types CLIENT, COMMANDE et TOURNEE. Une commande cde1 détermine un client cli1 qui détermine une tournée tr1. Ainsi, la commande cde1 détermine transitivement la tournée tr1 : en l’état, l’association-type CONTENIR est redondante et doit disparaître (sauf si une règle de gestion énonce qu’une commande puisse faire partie d’une tournée différente de celle qui a été définie pour le client). Dans le même sens, il est important de mettre évidence la règle de gestion dont nous avons déjà débattu, à savoir que le commercial qui gère une commande peut ne pas être celui qui a démarché le client.

3) Vous pouvez commencer à prendre en compte l’aspect temporel. Pour faire court, le principe est le suivant : une donnée peut être dans un certain état depuis une certaine date (c'est-à-dire à ce jour) et a pu être dans d’autres états durant des périodes antérieures connues.

Par exemple, supposons que vous souhaitiez conserver les statuts successifs des commandes. A ce jour, la commande cde1 a le statut stx, alors qu’auparavant elle a eu les statuts sty, stz, etc. (en l'occurrence, les dates de début et de fin sont connues) : le statut en cours (accompagné de sa date d’effet) peut être une propriété de l’entité-type COMMANDE, tandis que ses statuts précédents seront dégagés dans une entité-type ad-hoc, disons à caractère historique.

Bien que les traitements n’aient pas à être pris en considération dans un MCD, je n’hésite pas à vous faire cette suggestion, parce qu’en isolant les statuts passés, les requêtes portant sur les statuts (quels qu’ils soient) seront grandement simplifiées. Ceci est encore plus vrai quand plusieurs attributs d’une entité-type sont concernés par cet aspect temporel des choses. J’ai trop vu de développeurs patauger dans des bourbiers où le présent et le passé étaient mélangés, d'où ma motivation...

[Heledir]

Bonjour fsmrel,

Je pense avoir modifié le MCD suivant vos conseils.

J'ai un problème avec les cardinalités. Dans quel cas employer 0,n ou 1,n :

[ Secteur ]---1,n---(R)---1,1---[ Commercial ]


Dans ce cas, je ne pourrais pas créer de secteur sans lui affecter de commercial. Si je remplace 1,n par 0,n je peux créer un secteur sans lui attribuer de commercial.

Merci.

[fsmrel]

Bonsoir,

J'ai un problème avec les cardinalités. Dans quel cas employer 0,n ou 1,n

Avec un MCD, on modélise la fonctionnalité, le QUOI. Si de ce point de vue un secteur a au moins un commercial, alors on a bien :

[ Secteur ]---1,n---(R)---1,1---[ Commercial ]

Quant au QUAND et au COMMENT, c’est dans la transaction que l’on fera en sorte que la contrainte fonctionnelle soit respectée (ajout simultané d’un secteur et d’au moins un commercial dans la même transaction élémentaire, close par un COMMIT au sens SQL).

Je vais examiner votre MCD et vous ferai part de mes commentaires, concernant notamment la spécialisation des entités-types et l’héritage des attributs.

[fsmrel]

Bonsoir à nouveau,

Je pense avoir modifié le MCD suivant vos conseils.

Examinons donc ce MCD. Pour faciliter la discussion j’en produis un à mon tour (outil : Power AMC).

1) Mise en évidence des identifiants

Les attributs (artificiels) utilisés pour les identifiants des entités-types doivent apparaître dans la liste des attributs de ces entités-types. Exemple : l’attribut ProduitId est utilisé comme identifiant de l’entité-type PRODUIT et l’attribut FamilleId comme identifiant de l’entité-type FAMILLE (noter le mickey <pi> qui accompagne ces attributs (abréviation de primary identifier)).




2) Statut de la commande

Si je comprends bien, vous ne cherchez pas à gérer l’historique des statuts d’une commande (vision « durant »), mais seulement le statut en cours (vision « depuis » seule), autrement dit le nouveau statut de la commande « annule et remplace » le précédent (s’il existe). Il est d’usage que l’attribut DateStatut réintègre COMMANDE (même si pour ma part je le laisserais volontiers dans l’association-type).

Concernant l’entité-type STATUT, vous avez défini un attribut par valeur de statut : il faut en fait définir un attribut qui peut prendre les valeurs « commande prise », « commande transmise », etc.




3) Généralisation/spécialisation, héritage

Vous observerez que différentes entités-types ont pas mal d’attributs en commun, parce que sémantiquement parlant ce sont des variantes (entités-types spécialisées) d’entités-types plus générales (entités-types génériques). Il en va ainsi de CLIENT_PAYEUR et CLIENT_DESTINATION qui sont des variantes d’une entité-type générique que l’on peut appeler par exemple ENTREPRISE (une appellation différente peut convenir, à vous de voir).

Il en va de même pour les entités-types COMMERCIAL et LIVREUR, qui sont des variantes d’une entité-type générique INDIVIDU.

Mais à leur tour, les entités-types ENTREPRISE et INDIVIDU ont bien des points communs et peuvent elles aussi faire l’objet d’une généralisation pour donner lieu à une nouvelle entité-type PERSONNE.

L’entité-type PERSONNE est porteuse des propriétés communes à l’ensemble des entités-types spécialisées (Adresse, téléphone, adresse de courriel, etc.)
L’entité-type ENTREPRISE est porteuse des propriétés non partagées avec les individus (Siret...)

L’entité-type INDIVIDU est porteuse des propriétés non partagées avec les entreprises (Prénom...)

Reste le cas de la raison sociale des entreprises et du nom des individus. Parce que sémantiquement parlant les attributs correspondants sont d’un type distinct, je les ai séparés, mais je ne vous en voudrai pas si vous les remontez au niveau de l’entité-type PERSONNE, si vous les factorisez au moyen d’un attribut correspondant au nom de la personne, qu'elle soit physique ou morale.



Sur ce MCD, vous observerez qu’à l’intérieur des demi-lunes figure la lettre « X » : il s’agit du symbole de l’exclusion. Une entreprise ne peut pas être simultanément un individu. Un commercial ne peut pas être un livreur. Un client destinataire ne peut pas être un client payeur (à vous de rectifier le tir si je suis trop restrictif). Par ailleurs, chaque demi-lune est soulignée, ce qui marque la totalité : par exemple, PERSONNE est spécialisée obligatoirement soir en ENTREPRISE soit en INDIVIDU et il n’y a pas d’autre spécialisation possible. L’exclusion associée à la totalité représente le partitionnement.

ENTREPRISE et INDIVIDU héritent des attributs de PERSONNE, c'est-à-dire qu’en réalité, les attributs de ces sous-entités-types sont ceux de PERSONNE, plus ceux qui leur sont spécifiques. En particulier, elles héritent de l’identifiant de PERSONNE.

Même principe « à l’étage » inférieur. Ainsi, bien qu’on ne perçoive qu’une coquille vide, CLIENT_DESTINATION a pour attributs : PsnId (identifiant), Adresse1, Adresse2, Adresse3, CodePostal, Ville, Tel, Gsm, Courriel, RaisonSociale, Siret, Fax, Naf).

A noter que l’attribut Siret de l’entité-type ENTREPRISE est accompagné d’un mickey <ai> (abréviation de alternate identifier) : cela veut dire que, outre l’identifiant principal PsnId, ENTREPRISE est dotée d’un identifiant alternatif (deux entreprises ne peuvent pas avoir même Siret).

La généralisation permet aussi de factoriser les associations-types. Par exemple, si une personne peut avoir plusieurs adresses, la mise en œuvre d’une entité-type ADRESSE est simple :



Vous remarquerez que j’ai choisi d’utiliser l’identification relative (cardinalité 1,1 mise entre parenthèses). Ceci me permet de signifier que sans une personne en face, il n’y a pas d’adresses. On peut ainsi (en partie) exprimer le fait qu’ADRESSE est une propriété multivaluée de PERSONNE, donnant lieu à une entité-type faible (weak entity) par rapport une l’entité-type forte (regular entity).

Comme ADRESSE est une propriété multivaluée de PERSONNE, elle hérite de l’identifiant de cette dernière. L’attribut AdrId est là pour distinguer les différentes adresses d’une personne : sous le capot, l’identifiant d’ADRESSE est représenté par le couple (PsnId, AdrId).

Bonne méditation...

[Heledir]

Grand respect fsmrel,

un véritable feu d'artifice ! J'ai d'abord cru que c'était Noël : vite ouvrons les cadeaux ! Puis je me suis rendu compte que c'était plutôt ma fête !

Je ne suis plus d’accord avec Alain BASHUNG qui disait « Si tout est compliqué, ça ne colle pas, si tout est simple, ça ne suffit pas. ». Mais dans tous les cas, je n’aurai jamais cru que cela fusse si compliqué de faire plus simple. Si j’ai bien compris, plus je fais moins compliqué, moins tôt je serai couché !!!

Désolé, j’ai implosé, mais revenons à ce MCD.

Concernant l’entité-type STATUT, vous avez défini un attribut par valeur de statut :

Shame on me !

1) Mise en évidence des identifiants

Ne présumons de rien, mais je crois que c'est OK.

2) Statut de la commande

Effectivement, tout ce qui est commandé jour j sera livré j+1 même si un produit est manquant. Le reliquat n’est pas géré. Un Bon de préparation est émis qui reprend la totalité de la commande, c’est tout. Le statut ne me servira qu'a gérer si la commande a été transmise au siège, puis si le bon de préparation a été émis...

3) Généralisation/spécialisation, héritage

Magnifique. Dire que toutes ces années je suis passé à coté de cette réflexion. J’ai gérer des tables longues comme le bras…

Un grand merci pour la pédagogie.

Deux questions :

puis-je d’une part, appliquer l’identification relative aux entités-types :

[ CLIENT_PAYEUR ]---0,n---(DEPENDRE)---(1,1)---[ CLIENT_DESTINATION ]

Alors que Client_destination et Client_payeur héritent de leurs attributs.

D’autre part, dans le cas où le client n’a pas deux sites géographiques, c’est à dire que le client payeur est le client destinataire : est-ce la bonne façon de modéliser cette possibilité.

Encore une fois, merci et chapeau bas.

[fsmrel]

Bonsoir,

un véritable feu d'artifice !

En tant qu’artificier des bases de données promptes à exploser, pour un Quatorze Juillet, je ne pouvais pas faire moins...

Je ne suis plus d’accord avec Alain BASHUNG qui disait « Si tout est compliqué, ça ne colle pas, si tout est simple, ça ne suffit pas. ».

En fait, le garçon a repris ce qu’a déjà écrit Paul Valéry (cherchez avec les mots-clés « simple », « compliqué » « Paul Valéry »). Il aurait dû préciser « si tout est trop simple » ,Je suis plus en phase avec Albert quand il dit : « Everything should be made as simple as possible, but no simpler » (ce que j’ai du reste traduit à ma façon).

puis-je d’une part, appliquer l’identification relative aux entités-types :

[ CLIENT_PAYEUR ]---0,n---(DEPENDRE)---(1,1)---[ CLIENT_DESTINATION ]

Passons au niveau logique et considérons le corps des tables, dans lesquelles p1, p2 et p3 sont des clients payeurs, p4 et p5 des clients destinataires, p6 e p7 des commerciaux. La table PERSONNE ressemblera a quelque chose comme cela (clés primaires soulignées) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
PERSONNE (PsnId, Adrese1, Adresse2, Adresse3, CPostal, Ville, Tel, Gsm, Courriel)
           p1     a11      a12       a13       cp1      v1    t1   g1     co1
           p2     a21      A22       a23       cp2      v2    t2   g2     co2
           p3     a31      A32       a33       cp3      v3    t3   g3     co3
           p4     a41      A42       a43       cp4      v4    t4   g4     co4
           p5     a51      A52       a53       cp5      v5    t5   g5     co5
           p6     a61      A62       a63       cp6      v6    t6   g6     co6
           p7     a71      A72       a73       cp7      v7    t7   g7     co7
           p8     a81      A82       a83       cp8      v8    t8   g8     co8
           ...    ...      ...       ...       ...      ...   ...  ...    ...

Sans utiliser l’identification relative, les tables ENTREPRISE, PAYEUR et DESTINATAIRE ressembleront à ceci (p4 et p5 dépendent de p1) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
  
ENTREPRISE (PsnId, Siret, Naf, Fax)
             p1     s1    n1   f1
             p2     s2    n2   f2
             p3     s3    n3   f3
             p4     s4    n4   f4
             p5     s5    n5   f5

PAYEUR (PsnId)        DESTINATAIRE (PsnId, PayeurPsnId, CommercialPsnId)
         p1                          p4        p1             p6       
         p2                          p5        p1             p7
         p3

Si vous utilisez l’identification relative, il faut ajouter un attribut ad-hoc (que j’appelle par exemple SeqId) pour la table DESTINATAIRE, tandis que PsnId fait l’objet d’une clé alternative (attribut en italiques) :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
  
ENTREPRISE (PsnId, Siret, Naf, Fax)
             p1     s1    n1   f1
             p2     s2    n2   f2
             p3     s3    n3   f3
             p4     s4    n4   f4
             p5     s5    n5   f5

PAYEUR (PsnId)        DESTINATAIRE (PsnId, PayeurPsnId, SeqId, CommercialPsnId)
         p1                          p4        p1         1          p6       
         p2                          p5        p1         2          p7
         p3

Du point de vue MLD, il n’y a pas de valeur ajoutée, c’est plutôt le contraire, car maintenant il faut gérer un attribut supplémentaire, non seulement pour la table DESTINATAIRE, mais aussi pour les tables qui lui font référence (COMMANDE et APPARTENIR).

Au niveau sémantique, ça n’est pas très sain non plus, car le fait que DESTINATAIRE soit au même titre que PAYEUR une spécialisation d’ENTREPRISE est quelque chose de fort, mais très affaibli par l’identification relative, qui traduit le fait que DESTINATAIRE devient une propriété multivaluée de PAYEUR. Personnellement, je n’utiliserais pas l’identification relative.

dans le cas où le client n’a pas deux sites géographiques, c’est à dire que le client payeur est le client destinataire : est-ce la bonne façon de modéliser cette possibilité

On peut produire le MCD suivant, dans lequel DESTINATAIRE est remplacé par MIXTE et DESTINATAIRE devient une spécialisation de MIXTE. Le rôle de DESTINATAIRE est de faire référence à PAYEUR.

Au niveau du MLD, à supposer que p8 soit en même temps payeur et destinataire, le corps des tables est le suivant :

Code :

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
ENTREPRISE (PsnId, Siret, Naf, Fax)
             p1     s1    n1   f1
             p2     s2    n2   f2
             p3     s3    n3   f3
             p4     s4    n4   f4
             p5     s5    n5   f5
             p8     s8    n8   f8

PAYEUR (PsnId)        MIXTE (PsnId, CommercialPsnId)
         p1                   p4        p6       
         p2                   p5        p7
         p3                   p8        p6

                  DESTINATAIRE (PsnId, PayeurPsnId)
                                 p4       p1
                                 p5       p1

Maintenant, je vous laisse réfléchir aux conséquences du fait qu'un client à un seul site passe à deux sites et inversement.

[Heledir]

Bonjour fsmrel,

Vos conseils sont précieux ! Précieux ? Il me semble que c’est un certain Golum qui disait cela en parlant d’un truc rond. Peu importe, en attendant je rame.

Maintenant, je vous laisse réfléchir aux conséquences du fait qu'un client à un seul site passe à deux sites et inversement.

Si p8 ouvre une succursale p9. Si p5 et p6 se séparent de p1. Le corps des tables devrait se modifier comme suit :

Code :

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
17
ENTREPRISE (PsnId, Siret, Naf, Fax)
             p1     s1    n1   f1
             p2     s2    n2   f2
             p3     s3    n3   f3
             p4     s4    n4   f4
             p5     s5    n5   f5
             p8     s8    n8   f8
             p9     s9    n9   f9

PAYEUR (PsnId)        MIXTE (PsnId, CommercialPsnId)
         p2                   p1        p6
         p3                   p4        p6
         p8                   p5        p7
                              p9        p6

                  DESTINATAIRE (PsnId, PayeurPsnId)
                                 p9       p8

Etait-ce le but de votre question ?

Mais je me rend compte que quelque chose ne va pas. En effet, un client payeur doit pouvoir commander des produits, ce qui ne semble pas être le cas dans le MLD. Fort de vos conseils et surtout de ce que j’en ai compris, j’ai essayé de modéliser ce qui suit.

Toutes les ENTREPRISE peuvent commander des PRODUIT.
Toutes les ENTREPRISE sont visitées par un COMMERCIAL attitré.
Les ENTREPRISE sont :

• soit des SIEGE (Ils sont donc CLIENT_PAYEUR et CLIENT_DESTINATAIRE).

• soit des SUCCURSALE et dépendent d’un SIEGE pour le paiement.

Je me répète, mais mille merci de votre aide.

[fsmrel]

Bonsoir,

Etait-ce le but de votre question ?

Je voulais attirer votre attention sur un point qui mérite qu’on s’y arrête brièvement, ayant trait à la stabilité des entités-types que l’on spécialise. Je présente parfois sur ce forum le diagramme suivant :



Plus stable, ça n’existe pas : on sait qu’un carré ne sera jamais un cercle. De la même façon, dans votre système un individu ne peut pas se transformer en entreprise.
A l’opposé, si vous aviez voulu spécialiser une commande en commande prise, commande transmise, etc. (à un moment donné vous n’en étiez pas loin...), les darwinistes auraient tirés à vue, au nom de la stabilité et plein de raisons philosophiques.

En posant la question « je vous laisse réfléchir aux conséquences du fait qu'un client à un seul site passe à deux sites et inversement » , je voulais donc que vous jugiez des conséquences sémantiques d’une part et des conséquences sur la base de données d’autre part. Au plan sémantique, nous sommes un tantinet délinquants. Sur le plan de la mise à jour de la base de données, sauf si c'est p9 qui joue le rôle de payeur, il est un fait que p8 doit migrer de la table CLIENT_MIXTE vers la table CLIENT_PAYEUR et ceci n’est pas anodin, car il faudra rattacher à p9 ses commandes et le commercial visiteur. Autrement dit, je vous avais proposé une cote mal taillée, mais à un moment donné il y a des choix à faire et si les mutations sont peu fréquentes, ça reste jouable, même si les puristes poussent des cris.

Mais je me rend compte que quelque chose ne va pas. En effet, un client payeur doit pouvoir commander des produits, ce qui ne semble pas être le cas dans le MLD.

Tout à fait Thierry...

Dans votre MCD, vous avez donc tout remonté d’un cran, ce qui résout du même coup les problèmes de mixité...


N.B. Un détail. Êtes-vous bien sûr que les attributs CdeQte et CdeTrfJour sont à leur place ?

[Heledir]

Bonjour fsmrel,

N.B. Un détail. Êtes-vous bien sûr que les attributs CdeQte et CdeTrfJour sont à leur place ?

Initialement ces deux attributs étaient dans l’association-type, mais votre commentaire :

Il est d’usage que l’attribut DateStatut réintègre COMMANDE (même si pour ma part je le laisserais volontiers dans l’association-type)

m’a amené à faire de même pour ces attributs. Il y a une notion que je n’ai pas comprise ici.

Je les ai donc remis dans l'association type COMPOSER.

J’ai constaté que dans l’entité-type COMMANDE vous aviez ajouté un <ai> CdeNum. Il me semble que le <pi> CdeId suffit à lui seul à identifier une commande. Comme il n’est pas là par hasard, quel est l’intérêt d’ajouter un <ai> ?

Je vous remercie, ainsi que toute l'équipe, du temps que vous consacrez à transmettre vos connaissances.

[fsmrel]

Bonsoir,


J'envoie ce message avant l'orage qui s'annonce et avant relecture, donc vous y trouverez peut-être des coquilles et bizarreries diverses...

Au besoin, on arrangera ça.

Initialement ces deux attributs étaient dans l’association-type, mais votre commentaire :

Il est d’usage que l’attribut DateStatut réintègre COMMANDE (même si pour ma part je le laisserais volontiers dans l’association-type)

m’a amené à faire de même pour ces attributs. Il y a une notion que je n’ai pas comprise ici.

Mea culpa. Je suis pris en flagrant délit de recommandation incomplète. En effet, une commande n’a qu’un statut, d’où la manie des merisiens de faire migrer l’attribut DateStatut dans l’entité-type COMMANDE. A mon sens, cela relève d’un red herring. En effet, si on les suit, en renommant les attributs de COMMANDE ainsi : A1, A2, ..., An, comment savoir que Ai fait référence à l’entité-type STATUT ? Si cet attribut est porté par l’association-type POSSEDER, au moins on sait à quoi s’en tenir. Par ailleurs, si votre MCD devait évoluer et qu’une commande puisse désormais avoir plusieurs statuts, les merisiens vous demanderaient de replacer l’attribut DateStatut à sa place naturelle, c'est-à-dire au sein de l’association-type POSSEDER.

Mais je crois qu’il est temps d’observer la structure tabulaire dans le contexte du MLD, on y verra plus clair.

Partant du MCD, un outil comme Power AMC sait produire un MLD (qu’il incorpore au MPD et mélange donc les niveaux, celui de la logique formelle et du fer à souder, mais on fera avec). Voici un extrait du MLD, dans lequel j’ai renommé les attributs correspondant au client (ClientPsnId) qui passe la commande et au commercial qui la gère (CialPsnId), en notant que l’association-type GERER est passée à la trappe dans votre MCD (je suppose que ça n’est pas voulu) :



Le mickey <pi> du MCD est devenu <pk>, abréviation de primary key pour clé primaire. Ainsi, l’attribut StatutId de la table STATUT est flanqué de ce mickey, pour rappeler que le sous-ensemble {StatutId} de l’ensemble {StatutId, SatutLibelle} constitué par les attributs de la table STATUT a la propriété qu’un élément (une valeur) appartenant à {StatutId} ne peut pas figurer deux fois dans la table STATUT : on a mis en œuvre une contrainte d’unicité, faisant qu’il n’y a qu’un seul statut pouvant prendre la valeur st1, un seul statut pouvant prendre la valeur st2, etc. (on utilise normalement des nombres entiers pour identifier (cf. ci-dessous), et dans st1 et st2, il ne faut voir que des symboles plus parlants).

Toutes choses égales par ailleurs, il en va de même pour la table COMMANDE et l’attribut CdeId : il n’y a qu’une seule commande pouvant prendre la valeur cd1, une seule commande pouvant prendre la valeur cd2, etc.

En passant, je réponds à votre interrogation au sujet de l’attribut CdeNo. Il est recommandé que les clés primaires soient composées d’attributs strictement artificiels (cf. mon message du 13 juillet à propos de l’invariance et qui va dans ces sens). CdeNo est un attribut correspondant à une propriété naturelle de COMMANDE et par prudence, il est préférable de ne pas en faire une clé primaire (même si un numéro de commande est a priori invariant, mais allez savoir...), mais plutôt une clé dite alternative (alternate key, d’où le mickey <ak> qui l’accompagne), ce qui nous permet de garantir l’unicité des numéros de commande. Mais pourquoi avoir des clés invariantes ? Ceci est à prendre en considération dans le cadre des relations qui unissent es tables. Si vous remplacez la valeur stx par la valeur sty pour l’attribut StatutId de dans la table STATUT, pour des raisons évidentes de cohérence, il faudra en faire autant pour la table COMMANDE. Du point de vue théorique, ceci est tout à fait légal et peut être effectué automatiquement par le SGBD. Dans cet exemple il n’y aura guère de problème, disons de coût de l’opération, mais imaginez que vous jouiez à cela au niveau de la table PERSONNE : la modification doit être répercutée en cascade dans un certain nombre de tables. Un truc à se faire taper sur les doigts, car le système va être sérieusement ralenti le temps de l’opération et les utilisateurs n’aimeront pas voir le sablier s’afficher sur leur écran...

Cela dit, vous observerez que l’attribut StatutId figure dans les deux tables STATUT et COMMANDE. Pourquoi après tout ?

Quand il a inventé la théorie relationnelle, Ted Codd, a énoncé en préambule :

« Toute l’information contenue dans une base de données relationnelle doit être explicitement représentée, et ce uniquement au moyen de valeurs dans des tables »

Autrement dit, sont de facto bannis tous les éléments qui se trouveraient sous le capot, tels que des pointeurs et autres adresses utilisés par exemple dans les SGBD pré-relationnels et plus généralement dans les langages de programmation traditionnels.

D’où la présence de l’attribut StatutId dans les deux tables. La cohérence entre les tables est établie en précisant au SGBD quel attribut de la table COMMANDE fait référence à l’attribut StatutId de la table STATUT. Quand on demande à Power AMC de produire le MLD, il définit cet attribut en se basant sur l’association-type POSSEDER du MCD. Il le fait participer à ce qu’on appelle une clé étrangère (foreign key, d’où le mickey <fk3>). Cette appellation n’est pas très heureuse, mais on fera avec. Quoi qu’il en soit, cela veut dire que chaque valeur prise par l’attribut StatutId de la table COMMANDE doit nécessairement être d’abord une valeur prise par l’attribut StatutId de la table STATUT. De la même façon, chaque valeur prise par l’attribut ClientPsnId de la table COMMANDE doit nécessairement être d’abord une valeur prise par l’attribut PsnId de la table ENTREPRISE (d’où le mickey <fk2>, et chaque valeur prise par l’attribut CialPsnId de la table COMMANDE doit nécessairement être d’abord une valeur prise par l’attribut PsnId de la table COMMERCIAL (d’où le mickey <fk1>.

Au niveau SQL, une clé étrangère est déclarée au sein d’une contrainte dite d’intégrité référentielle :

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
 CREATE TABLE COMMANDE (
      CdeId           Integer  Not Null,
      StatutId        Integer  Not Null,
      ClientPsnId     Integer  Not Null,
      CialPsnId       Integer  Not Null,
      CdeNo           Integer  Not Null,
      CdeDate         Date     Not Null,
      CdeStatutDate   Date     Not Null,
   Constraint Cde_PK Primary Key  (CdeId),           
   Constraint Cde_AK1 Unique (CdeNo)
   Constraint Cde_Statut Foreign Key (StatutId)
              References STATUT (StatutId)
   Constraint Cde_Ent Foreign Key (ClientPsnId)
              References ENTREPRISE (PsnId) ) ;

Cde_Statut, Cde_Ent sont des noms de contraintes d’intégrité référentielle que le SGBD se chargera de garantir. Vous noterez par ailleurs les contraintes d’unicité Cde_PK (clé primaire) et Cde_AK1 (clé alternative).

Passons à l’association-type COMPOSER. Une commande peut être composée de plusieurs produits et un produit peut entrer dans la composition de plusieurs commandes : en conséquence, lors du passage au MLD, Power AMC met en œuvre une table COMPOSER :



Ainsi, pour chaque paire {ProduitId, CdeId} de la table COMPOSER, on sait quelle quantité de quel produit fait partie de quelle commande. Si vous déplacez les attributs Quantite et Tarif dans COMMANDE, on aura plus que du mal à savoir à quoi tout cela correspond et votre désarroi serait bien compréhensible.

Pour résumer, lors de la dérivation d’un MCD en MLD, Power AMC traduit chaque relation de un à plusieurs par une clé étrangère (cf. associations-types PASSER, POSSEDER, ...), tandis que chaque relation de plusieurs à plusieurs (COMPOSER) fait l’objet d’une table. Contrainte d’unicité oblige, la clé primaire de cette table est évidemment composée des attributs issus des identifiants des entités-types connectées et l’intégrité référentielle est assurée par les clés étrangères qui vont bien :

Code SQL :

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

1
2
3
4
5
6
7
8
9
10
Create Table COMPOSER (
      ProduitId        Integer          Not null,
      CdeId            Integer          Not null,
      Quantite         Integer          Not null,
      Tarif            Integer          Not null,
   Constraint COMPOSER_PK Primary Key  (ProduitId, CdeId),
   Constraint COMPOSER_PRODUIT_FK Foreign Key (ProduitId)
      References Produit (ProduitId),
   Constraint COMPOSER_COMMANDE_FK Foreign Key (CdeId)
      References Commande (CdeId));

[Heledir]

Bonjour fsmrel,

Désolé pour le retour tardif, mais un imprévu m’a obligé à revoir mes priorités.

Concernant le MCD, ce n’est pas un orage, mais une tempête dans ce qui reste de mon cerveau ! Naïvement, au départ je m’étais dit que ça allait être une promenade de santé. Mais je ne regrette pas le temps passé, il est investi !

Malgré le fait que vos explications soient simples et efficaces, mon esprit embrumé (l'alcool ??? les herbes de Provence ??? Allez savoir !) ne me permet pas de tout comprendre du premier coup.

en notant que l’association-type GERER est passée à la trappe dans votre MCD (je suppose que ça n’est pas voulu)

Effectivement, elle était passée à la trappe. Et surtout, j’ai oublié de joindre le MCD modifié !

Si j'ai bien compris, comme une commande ne peut avoir qu'un statut, il n'est pas nécessaire de laisser l’attribut dans l’association type. A contrario, on laisse les attributs dans l’association-type COMPOSER car :

Une commande peut être composée de plusieurs produits et un produit peut entrer dans la composition de plusieurs commandes

Alors là, respect ! On travaille dans son coin en se regardant le nombril et… des choses comme celle-ci vous remettent les pieds sur terre. Ca m’amuse beaucoup.

CdeNo est un attribut correspondant à une propriété naturelle de COMMANDE et par prudence, il est préférable de ne pas en faire une clé primaire

J'ai joins (encore les herbes de Provence ???) le MCD que j'espère pas très loin d’être finalisé. Bien entendu, toutes les suggestions afin de corriger mes maladresses (erreurs ?) de débutant seront les bienvenues.

Encore une fois, merci beaucoup de votre aide.

[fsmrel]

Bonsoir Heledir,

On travaille dans son coin en se regardant le nombril et… des choses comme celle-ci vous remettent les pieds sur terre. Ca m’amuse beaucoup.

Rien de tel que de travailler dans la joie et la bonne humeur. Ce MCD me paraît désormais bel et bon, il est vraisemblablement asymptotique à une part de vérité, et comme disat Pierre Dac :

« Si tous ceux qui croient avoir raison n'avaient pas tort, la vérité ne serait pas loin. »

En vertu de quoi, il n’y a manifestement plus qu’à passer au MLD.

Histoire d’élever le débat et en guise de conclusion, je me permettrai de citer à nouveau Pierre Dac qui fut en pensée avec nous tout au long de cet échange :

« Gloire à ceux qui ont forgé silencieusement mais efficacement le fier levain qui, demain ou après-demain au plus tard, fera germer le grain fécond du ciment victorieux, au sein duquel, enfin, sera ficelée, entre les deux mamelles de l'harmonie universelle, la prestigieuse clef de voûte qui ouvrira à deux battants la porte cochère d'un avenir meilleur sur le péristyle d'un monde nouveau ! »

Mais j'avoue ne pas savoir si la clef de voûte est candidate, primaire, ou autre, à vous de trancher.

Bon courage,

fsmrel

[Heledir]

Bonjour fsmrel,

Pour accompagner Pierre DAC, merci à Coluche qui rappelait :

« Ce n’est pas parce qu’ils sont nombreux à avoir tord qu’ils ont raison ! »

Enfin pour le plaisir, n’est ce pas Pierre DAC qui disait :

« S’il est vrai que ceux qui n’ont rien à dire gagnent à ce taire, ceux qui l’ouvrent alors qu’ils feraient mieux de la fermer ont-ils quelque chose à perdre ? »

Peut être avait-il tord, mais il n'était certainement pas loin d'avoir raison.


Alors action, en route vers de nouvelles aventures : passage au MLD.

Onglet Outils, commande "Générer un modèle physique de données".

Après que vous ayez cliqué et avant déclenchement de l'opération, AMC vous propose de générer un nouveau mpd et à cette occasion de choisir le SGBD cible.

Arrivé à ce point, le modèle physique de données me semble : disons, humm, surprenant pour un oeil neuf !

Est-ce que des modifications du MPD seront nécessaires pour passer à la génération des tables. Auquel cas, j’ouvrirai un autre post.

Je suis resté "un certain temps" (merci Fernand) devant mon clavier (Attention hein, pas une statue de l’artiste, faux pas pousser) à me demander comment vous dire merci, puis je me suis dit : fais simple. Alors merci.

« La simplicité n’est-elle pas ce qu’il y a de plus beau ? » Zhang CHAO

[fsmrel]

Bonsoir Heledir,

Arrivé à ce point, le modèle physique de données me semble : disons, humm, surprenant pour un oeil neuf !

Raison de plus pour nous présenter ce MLD (qui n’est heureusement pas encore un MPD). Je suppose que la partie héritage peut vous surprendre, car il y a plusieurs scénarios de génération à proposer à l’AGL. En tout cas, la simplicité et l’élégance doivent être au rendez-vous.

Est-ce que des modifications du MPD seront nécessaires pour passer à la génération des tables. Auquel cas, j’ouvrirai un autre post.

Si le plumage est conforme à celui attendu, je ne vois pas a priori de modifications nécessaires. Et de toutes façons, s’il y en avait, ça peut intéresser tout le monde, auquel cas vous pourriez poster dans le forum Power AMC une invitation à venir voir ce qui se passe ici...

A propos de beauté, souvenons-nous de ces mots de G.H. Hardy :

“The mathematician’s patterns, like the painter’s or the poet’s must be beautiful; the ideas, like the colours or the words must fit together in a harmonious way. Beauty is the first test: there is no permanent place in this world for ugly mathematics.”

Autrement dit :

« Les schémas du mathématicien, comme ceux du peintre ou du poète, doivent être beaux ; les idées, comme les couleurs ou les mots, doivent s'assembler de façon harmonieuse. La beauté est le premier test : il n'y a pas de place durable en ce monde pour des mathématiques laides. »