Discussion :

[Petit Rasta]

Bonjour,

Je suis en train de faire un MLD pour une base de données.
J'utilise Power AMC, j'ai un peu galérer pour faire un schéma assez simple qui montre les différentes relations entre les tables.
J'ai toujours utilisé la notion de clé primaire et de clé étrangère pour les schémas merise mais apparemment ceci est appelé Identifiant.
J'explique un peu ce que je veux représenter :
J'ai une table Lancement qui hérite des valeur de la table affaire en fonction du numéro d'affaire sélectionnée.
La table affaire fait référence via le nom du client à la table client et avec le numéro de DAS à la table DAS.
J'ai représenté ceci de cette façon :



Merci de m'aider parce que la Merise et moi on est pas de grand amis ...

[fsmrel]

Bonjour Petit Rasta,

la Merise et moi on est pas de grand amis ...

Le Petit Rasta et la Merise ne sont pas de grands amis, mais je suppose que ce « Je t’aime moi non plus » vaut aussi pour de la modélisation des données en général.

Vous raisonnez MLD (clés primaires, étrangères) et vous utilisez un MCD où l’on traite plutôt d’identifiants et pour lequel le concept de clé étrangère n’existe pas (c'est le passage du MCD au MLD qui traduira les relations entre entités-types sous forme de clés étrangères).

Si vous êtes plus à l’aise avec les MLD, pondez un MLD et par rétro-conception vous pourrez produire le MCD.

Cela dit :

1) Qu’es-ce qu’une DAS ? Une direction des affaires sociales ? Un débit d'absorption spécifique ? L’assurance des loyers impayés ? La classe des Dinosaures Assimilés Saurischiens ?

Vous comprendrez qu’un minimum de description de vos objets est nécessaire pour que nous comprenions votre sujet (univers du discours).

2) Si une affaire concerne un client, l’attribut Type_Client n’a rien à faire dans l’entité-type AFFAIRE (ou la table dans le cas du MLD), et doit migrer dans l’entité-type CLIENT, le mieux étant encore de définir une entité-type TYPE_CLIENT.

3) Si vous utilisez l’héritage, la relation entre AFFAIRE et LANCEMENT n’est pas du genre AVOIR (posséder), mais ÊTRE : d’où la question « Un lancement est-il une affaire ? (au même titre qu’une baleine est un mammifère et ne « possède » pas un ou des mammifères).

4) « One fact one place » : les attributs de l’entité-type AFFAIRE n’ont pas à être dupliqués dans l’entité-type LANCEMENT. De même, pourquoi avoir dupliqué l’attribut Secteur (entités-types CLIENT et AFFAIRE) ?

5) Votre représentation graphique utilise la notation IE (Information Engineering) plutôt que la notation Merise (avec laquelle les relations entre entités-types sont représentées par des ovales).

6) L’entité-type AFFAIRE comporte un attribut Prix_Vente_Piece : cela suppose qu’une affaire concerne un pièce et une seule. Qu’en est-il ?

Bref, vos problèmes relationnels avec la modélisation ne concernent pas particulièrement Merise, mais la modélisation conceptuelle et logique/relationnelle en général. En outre, vous mettez la charrue avant les bœufs, autrement dit, vous devriez commencer par nous énoncer les règles de gestion des données qui ont plus ou moins pertinemment donné lieu à votre représentation graphique.

Si vous vous sentez plus à l’aise avec les MLD, n’hésitez pas à nous en proposer un.

[Petit Rasta]

Bonjour et merci pour cette réponse.

Je suis plus à l'aise avec les clés primaires, clés étrangère effectivement ...
Mais je ne connais pas cette version de Power AMC 15.1 et j'avoue être un peu pommé.
J'ai bien réalisé un MLD dans le sens ou j'ai ouvert un modèle MLD.

Explications :

Il y a quatre tables indispensables dans ce projet : la table Lancements, la table Affaires, la table DAS et la table Clients.
La table Lancements hérite des données de la table Affaire, ainsi pour une affaire on peut avoir plusieurs lancements, toutefois un lancement n’admet qu’une seule affaire.
La table Affaire est en lien avec les tables DAS et Clients, en effet une affaire est réalisée pour un client et ce client appartient à un certain DAS. Une affaire ne peut appartenir qu’à un seul client tout comme une affaire n’appartient qu’à un seul DAS.
Un Das et un Client peuvent bien évidemment appartenir à plusieurs affaires.

1) Un DAS n'est autre qu'un Domaine de Secteur d'Activité (ici représenté par un chiffre et un libellé).

2) Utiliser une entité Type_Client ne me serait pas très utile étant donné que je n'aurais que cette information dans l'entité.

3) Un Lancement n'est pas une Affaire. Un lancement appartient à une Affaire.
En somme une Affaire peut avoir plusieurs lancements ( = Ordre de lancement + ou - = ordre de production). Une affaire quant-à elle est plus du côté commercial (on pourrait résumé à un contrat).

4) J'ai fait un héritage entre la table lancements et la table affaire du coup il y a duplication des champs avec l'utilisation de Power AMC...

5) Je suis d'accord avec vous, comme je l'ai dis plus haut je ne comprend pas vraiment le fonctionnement de ce logiciel. De plus je suis contraint à cause du temps à me dépêcher

6) Pour l'histoire du prix_vente_pièce il y a effectivement une ambiguïté (je vais me renseigner là-dessus, j'avais aussi repéré quelque chose de louche) ...

Je vous joints le fichier vous pourrez voir qu'il s'agit bien d'un MLD et qu'il n'y a pas la notion de clés primaires, clés étrangères ...

[Petit Rasta]

Je me suis renseigné, pour le prix_vente_pièce c'est quelque chose d'indicatif qui n'est pas vraiment déterminé lors de la création d'un Lancement ou d'une affaire.
De par ce fait je vais le laisser dans les attributs de l'entité Affaire et il ne variera pas en fonction des lancements.

[fsmrel]

Je vous joints le fichier vous pourrez voir qu'il s'agit bien d'un MLD et qu'il n'y a pas la notion de clés primaires, clés étrangères ...

Merci de transmettre une image du MLD, car je de dispose que de PowerAMC V11 et je ne peux donc pas ouvrir votre fichier. La version 15 connaît (enfin !) le concept de MLD, qui n’existe pas avec la V11 et avec laquelle on passe directement du MCD au MPD (sic).

La table Lancements hérite des données de la table Affaire, ainsi pour une affaire on peut avoir plusieurs lancements, toutefois un lancement n’admet qu’une seule affaire.

Le verbe « hériter » est inapproprié car il ne pourrait être employé que si un lancement était une affaire, au même titre qu’une baleine est un mammifère (verbe ÊTRE exigé). Or une affaire fait l’objet d’un ou plusieurs lancements : la relation entre une affaire et ses lancements est plutôt une relation d’appartenance, tout comme une commande a des lignes de commande et c’est le verbe AVOIR qui s’impose.

J'ai fait un héritage entre la table lancements et la table affaire du coup il y a duplication des champs avec l'utilisation de Power AMC...

Comme je l’ai dit, il n’y a pas d’héritage qui tienne ici. J’ai parlé d’appartenance, disons que, plus précisément, si un lancement concerne une affaire à la vie à la mort (interdiction d’affecter un lancement d’une affaire à une autre affaire), on a une relation de composition, un lancement est la propriété ad vitam d’une affaire.

Concernant la duplication des champs, cela veut dire que vous n’avez pas coché la bonne case concernant la duplication des attributs (fenêtre « Propriétés de l’héritage » dans le cas de PowerAMC V11). Mais peu importe, puisque vous allez remplacer la relation d'héritage par une relation de composition.

Une affaire ne peut appartenir qu’à un seul client tout comme une affaire n’appartient qu’à un seul DAS. Un Das et un Client peuvent bien évidemment appartenir à plusieurs affaires.

Attention à l’usage approximatif que vous faites des verbes. Si une affaire appartient à un client, un client ne peut pas appartenir à une affaire.

Utiliser une entité Type_Client ne me serait pas très utile étant donné que je n'aurais que cette information dans l'entité.

Attention aux incohérences, l’attribut Type_Client est du type TEXTE. La liste des types de client devra au moins faire l’objet d’une clause CHECK au sein de l’instruction CREATE TABLE (CLIENT tant qu’à faire, plutôt qu’AFFAIRE).

[Petit Rasta]

Les compositions ne se font pas qu'avec les diagrammes de classes ?
Les diagrammes de classe étant orienté objet ne corresponde pas à une application Access.
J'avais l'habitude de la version 12, en 3 version ils sont arrivés à me perdre complètement !
il faudrait peut-être que fasse un modèle de données physiques ?
J'ai vue qu'avec celui-ci il y avait la notion de table et de clés primaires/étrangères.
En somme c'est de la Merise ... ce qui correspond à la représentation des bases de données.

[fsmrel]

Les compositions ne se font pas qu'avec les diagrammes de classes ?

On n’a quand même pas attendu UML pour traiter du sujet...

Les diagrammes de classe étant orienté objet ne corresponde pas à une application Access.

Que vient faire ACCESS dans cette affaire ? Ne mélangez pas les niveaux de modélisation. Que vous produisiez un MCD ou un diagramme de classes (DC), si vous voulez produire des tables, à un moment donné vous aurez à procéder à la dérivation du MCD ou du DC en MLD orienté SQL. Et quand on parle de tables, ACCESS comprend.

il faudrait peut-être que fasse un modèle de données physiques ?

Oui, sans hésiter, puisque vous sous-entendez que vous êtes plus à l’aise avec ce type de modèle. Ensuite vous pourrez vous lancer dans la rétro-conception.

En somme c'est de la Merise ... ce qui correspond à la représentation des bases de données.

Non. Merise (ou la méthode Merise, mais pas « la Merise ») est une méthode d’analyse, en amont des bases de données. Vous continuez à confondre les niveaux. Voyez la FAQ Merise.

[Petit Rasta]

Bonjour,

J'ai refait deux diagrammes, l'un est un diagramme physique :


L'autre est le diagramme de classe :


Ce qui me paraît bizarre c'est que tout converge vers l'entité Affaire alors que normalement il est très rare d'avoir 4 relations sur une même entité ...
Au niveau de la liste de diffusion j'explique un peu ce que je veux représenter :
Lors de la création d'une Affaire j'ai champ "Pilote_Projet" (j'ai oublié de le représenté) ce champ n'est autre que le nom et prénom d'une personne.
Ensuite selon le type de lancement et le secteur du client je pourrais générer une liste de contacts pour la diffusion.

[fsmrel]

Bonjour,


Disposez-vous d’un dictionnaire des données décrivant les attributs peuplant les tables et leur rôle ? En effet, on se demande à quoi correspondent une UC, un nombre d’empreintes, etc.

Observations concernant la représentation tabulaire

Table CLIENT

Il est plus que très fortement recommandé d’utiliser un attribut non significatif et invariable pour définir la clé primaire d’une table.
En conséquence, définissez un attribut NumCLient de type disons INTEGER.
Si l’attribut Secteur identifie le secteur du client et si l’attribut Secteur_Client représente le libellé de ce secteur, alors cet attribut doit dégager dans une table SECTEUR. En l’occurrence, on dit qu’on normalise en troisième forme normale (3NF) :



Dans ces conditions, l’attribut Secteur de la table CLIENT donne lieu à une clé étrangère faisant référence à la clé primaire de la table SECTEUR.

Table LISTE_DIFFUSION

Comme dans le cas de la table CLIENT, il faut définir la clé primaire de la table LISTE_DIFFUSION à partir d’un attribut non significatif et invariable , appelons-le NumDiffusion, de type INTEGER.




Au vu de la présence des attributs Nom et Prénom, j’en déduis que Liste de diffusion est synonyme de Personne. Maintenant, selon votre représentation, une personne peut être concernée par plusieurs affaires, mais une affaire ne concerne qu’une seule personne. La réalité est-elle ainsi ?

Table AFFAIRE

Quelle différence existe-t-il entre les attributs NumDAS et NoDAS ?



Observations concernant le diagramme de classes

Si vous procédez à une rétro-conception du « MPD » en diagramme de classes, vous verrez que le résultat ne correspond pas à celui que vous proposez.

1) Les attributs qui servent pour les relations entre tables ne doivent figurer qu’une fois.

Par exemple, l’attribut NumAffaire (clé primaire de la table AFFAIRE), figure tout à fait légalement comme attribut de la classe AFFAIRE, mais doit disparaître de la classe LANCEMENT.

2) Vous avez inversé les « multiplicités » ⁽¹⁾. Par exemple, selon votre diagramme, une affaire concerne plusieurs DAS, et un DAS concerne une seule affaire.

3) vous avez établi une relation de composition entre LANCEMENT et AFFAIRE : très bien. Le problème est que, selon l’emplacement du losange, un lancement est composé d’affaires. A la manière de Dagobert, remettons les choses à l’endroit :

Ce qui me paraît bizarre c'est que tout converge vers l'entité Affaire alors que normalement il est très rare d'avoir 4 relations sur une même entité ...

Mais après remise à l’endroit, ça ne converge plus.


Personnes et listes de diffusion

Lors de la création d'une Affaire j'ai champ "Pilote_Projet" (j'ai oublié de le représenté) ce champ n'est autre que le nom et prénom d'une personne.
Ensuite selon le type de lancement et le secteur du client je pourrais générer une liste de contacts pour la diffusion.

Si je comprends bien, le pilote du projet et les destinataires des diffusions sont des personnes de l’entreprise. Qu’en est-il ?
S’il en est ainsi, sans doute manque-t-il une table des personnes qui récupèrerait les caractéristiques de celles-ci (Nom, prénom, adresse de courriel, etc.), tandis que se poserait plus précisément le rôle véritable de la table LISTE_DIFFUSION.


A suivre...


⁽¹⁾ Multiplicité est un terme employé de façon impropre en UML, car il signifie « très grand nombre », c’est un barbarisme. En effet, la multiplicité 1,1 signifie plutôt nombre minimal et je ne sache pas que 1 veuille dire un très grand nombre...

[Petit Rasta]

Bonjour,

Non je ne dispose pas de ce genre de dictionnaire ...
Les UC concernent le conditionnement de la production.
Le nombre d'empreinte quant à lui renseigne combien de pièce un moule peut faire à la fois. (Milieu de la plasturgie)

Observations concernant la représentation tabulaire

J'ai simplifié la table client en enlevant le champ "secteur" qui ne me servait à rien et qui m'embrouillait plus qu'autre chose ...
La table Liste_Diffusion me permet de stocker les informations sur les personnes, seules les personnes pouvant recevoir un mail sont entrées.

Ensuite en fonction du lancement crée, selon le secteur dans lequel le client appartient mais aussi selon le type_lancement je fais une requête qui récupère les e-mails de toutes les personnes ayant ces caractéristiques et qui ne sont pas des chef_projet.

Le chef_projet (= pilote_projet) est renseigné lors de la création de l'affaire donc je récupère son e-mail en fonction de son nom et prénom qui sont contenus dans le champ pilote_projet de l'entité Affaire.

Il peut y avoir plusieurs Pilote Projet remplissant les mêmes caractéristiques mais un seul est attribué à une affaire.

Je n'avais pas vu l'occurrence sous deux noms différents pour les NumDAS, il n'y avait aucune raison d'en avoir deux. J'avais du le mettre avant de faire les relations du coup il y a eu duplications lorsque j'ai crée la relation.

Observations concernant le diagramme de classes

En voici le résultat :



Encore une fois merci pour votre aide, j'en avais bien besoin !

[fsmrel]

Bonjour,

Disposez-vous d’un dictionnaire des données décrivant les attributs peuplant les tables et leur rôle ? En effet, on se demande à quoi correspondent une UC, un nombre d’empreintes, etc.

Non je ne dispose pas de ce genre de dictionnaire ...
Les UC concernent le conditionnement de la production.
Le nombre d'empreinte quant à lui renseigne combien de pièce un moule peut faire à la fois. (Milieu de la plasturgie)

Tachez à l’avenir d’être exigeant quant à la disponibilité de l’information car il peut y avoir des vices cachés, pouvant conduire à recommencer une modélisation non pertinente.

J'ai simplifié la table client en enlevant le champ "secteur" qui ne me servait à rien et qui m'embrouillait plus qu'autre chose ...

D’où la nécessité d’un dictionnaire de données bien documenté.


Table LISTE_DIFFUSION

La table Liste_Diffusion me permet de stocker les informations sur les personnes, seules les personnes pouvant recevoir un mail sont entrées.

On peut supposer qu’il existe par ailleurs dans la base de données une table des personnes (appelons-la PERSONNE).

1. Si tel est le cas, la table LISTE_DIFFUSION ne devrait pas comporter d’informations redondantes, autrement dit les attributs Nom, Prénom, Poste, etc. ne devraient pas figurer dans cette table, qui ne devrait servir qu’à établir une association entre les tables AFFAIRE et PERSONNE.
   
2. Si tel n’est pas le cas, alors seulement on conserve les attributs Nom, Prénom, Poste, etc. dans la table LISTE_DIFFUSION.

Admettons que l’on en reste à cette 2e hypothèse. Quoi qu’il en soit, dans tous les cas et toujours en vertu des principes fondamentaux de la modélisation, les informations relatives au chef de projet n’ont rien à faire dans la table AFFAIRE. Cette table doit être porteuse d’une clé étrangère (<fk4> ci-dessous) en relation avec la clé primaire de la table LISTE_DIFFUSION (ou la clé primaire de la table PERSONNE si elle existe). Par exemple (en notant que le booléen Chef_Projet disparaît pour cause de double emploi) :



On suppose ici qu’une personne peut piloter plusieurs affaires. Si une personne ne peut piloter qu’une affaire, l’attribut NumPersonnePilote devra faire l’objet d’une clé alternative. Qu’en est-il ?


Table CLIENT

Pourquoi avoir retenu le type Image pour l’attribut NumClient ????

Par ailleurs, si vous modélisiez suivant les règles, l’attribut Type_Client devrait dégager dans une table dédiée, même principe pour l’attribut Secteur_Client. En effet, en l’état, rien n’interdit que Type_Client prenne par exemple des valeurs telles que « vendeur d’enclumes à la sauvette » et « vendeurs d’enclumes à la sauvette », ce qui se traduira par des requêtes fausses. La représentation tabulaire devrait être la suivante :




Table TYPE_LANCEMENT

Il faudrait mettre en œuvre une table TYPE_LANCEMENT pour les types de lancement, sinon on retombera dans des problèmes de même nature que celui des marchands d’enclumes. Par ailleurs, quand on modélise, on ne fait figurer qu’une seule fois l’information : l’attribut Type_Lancement ne peut pas figurer à la fois dans la table LANCEMENT et dans la table LISTE_DIFFUSION, sauf quand il participe à une clé étrangère (cas de l'attribut NumTypeLancement ci-dessous) :




Diagramme de classes

Dans votre diagramme de classes, tout est encore à l’envers. Faites faire par PowerAMC une conversion du MLD/MPD en MOO et vous constaterez la différence. Par exemple, selon votre diagramme de classes, un lancement est composé d’affaires et une affaire n’entre que dans la composition d’un seul lancement...

[Petit Rasta]

Bonjour,

J'ai apporté des modifications sur la table Liste_Diffusion en la transformant en table Personne et en créant une table Pilote_Projet qui contient une clé étrangère de Personne et est référencée dans la table Affaire.
Pour le reste j'ai apporté vos modifications.




J'ai généré à partir de PowerAMC le diagramme MOO que voici :




Par contre en faisant comme cela on a plus la composition entre Affaire et Lancement.
Je l'ai donc rajouté et corrigé quelques cardinalités qui me semblaient fausses.

[fsmrel]

Bonsoir,


Ça bouge, c’est bien, les cardinalités dans le MOO sont dans le bon sens. Mais...

Un lancement est un composant d’une affaire, et le losange exprimant la composition est toujours du côté du composé, à savoir Affaire. Rappelez-vous du schéma que je vous avais fourni dans mon message du 07/05/2010, 16h18 :

Si vous demandez à PowerAMC de générer un MLD/MPD à partir du MOO, vous verrez que la structure de la clé de la table LANCEMENT n’est pas tout à fait la même que celle que vous aviez prévue. En effet, PowerAMC produit une clé primaire composée des deux colonnes NumAffaire et NumLancement. Au niveau conceptuel (Merise, Entité/Relation), on parle d’identification relative : LANCEMENT est identifié relativement à AFFAIRE. C’est une façon d’exprimer la composition, de signifier que LANCEMENT n’est après tout qu’une propriété (un composant) d’une entité-type plus forte, en l’occurrence AFFAIRE. Techniquement, tandis que NumAffaire progresse tranquillement de un en un, à l’infini, NumLancement progresse certes lui aussi de un en un, mais de façon limitée : pour chaque affaire, la renumérotation recommence à 1 :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
NumAffaire   NumLancement
----------   ------------
    1            1
    1            2
    1            3
    2            1
    2            2
   ...          ...
 123456          1
 123456          2
 123456          3
 123456          4
   ...          ...

Veuillez utiliser le type INTEGER pour tous les attributs entrant dans la composition des clés primaires (SMALLINT dans le cas de NumLancement).
Par exemple, avec DB2, le type INTEGER permet des valeurs allant jusqu’à plus de deux milliards et SMALLINT des valeurs allant jusqu'à +32767. Voyez ce qu’il en est avec votre SGBD. Je note par ailleurs que l’attribut NumAffaire de la table AFFAIRE est encore du type TEXT : refusé. Si l’utilisateur a sa propre façon de coder ses numéros d’affaires, ajoutez un attribut à cet effet et faites-en une clé alternative.

Relation entre CLIENT et AFFAIRE.

Selon vos cardinalités, un client peut être associé à plusieurs affaires : très bien. Mais une affaire est associée à au plus un client, c'est-à-dire qu’une affaire peut ne pas être associée à client : en est-il ainsi dans la réalité ?

Table PERSONNE

La table LISTE_DIFFUSION a été renommée en PERSONNE. OK. Le lien avec la table AFFAIRE a disparu. OK. Mais je répète ce que j’ai déjà dit : l’attribut Pilote_Projet (table PERSONNE) doit disparaître puisqu’il induit une redondance du fait de l’existence de la (nouvelle) table PILOTE_PROJET.

Par ailleurs, selon vos cardinalités, une affaire a toujours un et un seul responsable, OK Un pilote de projet peut être responsable de plusieurs affaires, OK. Mais, vous dites qu’un pilote de projet n’est pas toujours une personne (cardinalité 0,1), ce qui est pour le moins étonnant. Si en réalité un pilote est nécessairement une personne (avec son nom et tout ça), la modélisation devient la suivante :

MOO

Une personne peut avoir la responsabilité de plusieurs affaires, une affaire est toujours sous la responsabilité d’une personne.


MLD



A suivre...

[Petit Rasta]

J'ai un petit soucis pour la clé de l'entité Affaire (je n'avais pas formulé ce problème, je m'en excuse), il faut qu'elle soit composée de

Code :

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

SE-YY-NumIncrémenté

YY étant l'année, 10 pour 2010 par exemple.
Les numéros de lancements sont incrémentés quoi qu'il arrive et ne sont jamais remis à 1. C'est une contrainte forte qui m'est imposée.

Pour les cardinalités à 0,1 ce sont des oublis de ma part, par défaut lors de la génération du MOO PowerAMC m'avait mis des cardinalité à 0,1.
J'avais modifié mais apparemment pas partout.

MPD :



MOO :



J'ai un nouveau problème il faut que j'indique la localisation pour un client ...
(on m'a dit ça aujourd'hui ...).
J'ai donc fait une table Localisation avec comme clé primaire un numéro et le nom de la localité.
Enfait un même Client peut avoir plusieurs localisation mais en mettant deux clés primaires on retrouve les deux clés dans la table client ce qui me sert à rien.
Je ne sais pas comment faire pour éviter ce problème...

Je voulais également vous demander si vous saviez ce qu'il fallait mettre dans un rapport d'analyse ?
J'imagine qu'il faut expliciter le choix des tables, le contenu de chacune d'elle ...
Mon professeur m'a demandé l'intérêt de mettre un diagramme où il y a des cardinalités et un où il y en a pas ... et en a conclu en me disant il faut choisir entre l'un ou l'autre !
Je lui ais répondu que sur un MPD il y avait les notions de clés primaires, clés étrangères et qu'elles n'y étaient pas sur l'autre ...
Sa question me paraît pas vraiment justifiée étant donné que ces deux diagrammes n'ont pas du tout le même rôle...

En tout cas je vous remercie pour votre aide qui m'est très précieuse !

[Petit Rasta]

Finalement j'ai fait comme ceci :

MPD :



MOO :



Cela implique que je considère que chaque site correspond à un client même s'ils ont le même nom.
L'attribut Localisation sur le MPD n'est pas à prendre en compte.


[Edit] En fait cela n'ira pas non plus parce qu'il ne faut pas plusieurs clients avec le même nom.
Il faut que je mette la clé étrangère client dans le table Localisation.

[fsmrel]

Bonsoir,

J'ai un petit soucis pour la clé de l'entité Affaire (je n'avais pas formulé ce problème, je m'en excuse), il faut qu'elle soit composée de

Code :

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

SE-YY-NumIncrémentéYY

étant l'année, 10 pour 2010 par exemple.

Comme dit le grand Yves Tabourier dans son remarquable ouvrage De l’autre côté de MERISE (Les Éditions d’organisation, 1986) :

« ... la fonction d’une propriété est de décrire les objets (et les rencontres), alors que l’identifiant ne décrit rien. Son rôle fondamental est d’être sûr de distinguer deux jumeaux parfaits, malgré des descriptions identiques.
L’expérience montre d’ailleurs que l’usage des “identifiants significatifs” (ou “codes significatifs”) a pu provoquer des dégâts tellement coûteux que la sagesse est d’éviter avec le plus grand soin de construire des identifiants décrivant les objets ou, pis encore, leurs liens avec d’autres objets... »

Autrement dit, ce que vous appelez « la clé de l'entité Affaire » n’est qu’une des clés de cette entité (table). Appelons NumAffaireUtilisateur l’attribut correspondant (tout autre nom qui vous convient mieux fera l'affaire) et, en accord avec Tabourier, mettons par ailleurs en œuvre une clé non significative, à partir d'un autre attribut, appelons-le NumAffaireSysteme (ou utilisez tout autre nom qui vous convient là aussi), sans signification, inaltérable, sans odeur et sans saveur, inconnu de l’utilisateur (et disons auto-incrémenté, histoire de faire plaisir à CinePhil, mais là c'est de la cuisine SQL). C'est cet attribut qui fera l'objet de la clé primaire et servira pour les jointures entre la table AFFAIRE et les tables qui y font référence (LANCEMENT).

Le rôle de l’attribut NumAffaireUtilisateur est simplement de permettre aux utilisateurs d’accéder aux données de la table AFFAIRE. Cet attribut fera l’objet d’une clé alternative (unicité des valeurs garantie). Si quelqu’un osait émettre un veto quant à cette approche, il sera digne d’être nominé pour la palme de l’ignorance.

Le MLD doit devenir :



Avec PowerAMC, pour que NumAffaireUtilisateur fasse l’objet de cette clé alternative (alternate key, d’où le mickey <ak> qui l’accompagne) :

Cliquez sur la table AFFAIRE. Apparaît la fenêtre « Propriétés de la table - AFFAIRE »



Cliquez sur l’onglet Colonnes, renommez NumAffaire en NumAffaireSysteme (ou conservez ce nom, peu importe). Pour la suite des opérations, supposons qu'on l'a effectivement renommé ainsi. La case P affectée à la clé primaire étant cochée, NumAffaireSysteme donne lieu à la clé primaire de la table.


Cliquez ensuite sur l’onglet Clés. PowerAMC présente la liste des clés :



Identifiant_1 correspond ici à la clé primaire {NumAffaireSysteme}.

Pour définir une clé alternative, cliquez sur la ligne en dessous de Identifiant_1, ce qui donne lieu à :



Faites clic gauche sur la ligne Cle_2 pour la sélectionner. Puis cliquez sur le bouton Appliquer (situé en bas à droite), lequel devient grisé :



Faites un double clic sur Clé_2. Apparaît la fenêtre « Propriétés de la clé - Clé_2 » :



Cliquez sur l’onglet colonnes. Apparaît la fenêtre :



Cliquez sur l’icône « Ajouter des colonnes ». Apparaît la fenêtre :




Pour définir NumAffaireUtilisateur comme clé alternative, cochez la case correspondante puis faites OK :



Après avoir fait OK, apparaît la fenêtre montrant que NumAffaireUtilisateur a été retenu pour être clé alternative :



Cliquez sur le bouton Appliquer pour confirmer, puis une fois que PowerAMC a bien sélectionné la ligne NumAffaireUtilisateur, faites OK, puis OK, puis OK, ....

L’attribut NumAffaireUtilisateur doit être alors accompagné du mickey <ak> :



Quand vous procèderez à la génération du code SQL de création des tables, NumAffaireSysteme donnera lieu à la clé primaire de la table et NumAffaireUtilisateur à une clé alternative :

Code SQL :

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

1
2
3
4
5
6
7
CREATE TABLE AFFAIRE (
        NumAffaireSysteme      INT          NOT NULL
      , NumAffaireUtilisateur  VARCHAR(20)  NOT NULL
      , ........
   , PRIMARY KEY (NumAffaireSysteme)
   , UNIQUE (NumAffaireUtilisateur)
   , ... ) ;

Je regarderai la suite de votre message demain, il y a encore des choses à dire...

[fsmrel]

Bonjour Petit Rasta,


Suite...

J'ai un nouveau problème il faut que j'indique la localisation pour un client ...
(on m'a dit ça aujourd'hui ...).
J'ai donc fait une table Localisation avec comme clé primaire un numéro et le nom de la localité.
En fait un même Client peut avoir plusieurs localisation mais en mettant deux clés primaires on retrouve les deux clés dans la table client ce qui me sert à rien.
Je ne sais pas comment faire pour éviter ce problème...

Votre modélisation n’est pas satisfaisante car quelles que soient les contorsions auxquelles vous êtes en train de vous livrez, un client ne pourra jamais être localisé qu’une seule fois.

Cela dit, votre notion de localisation est plutôt vague. Ainsi, pour developpez.com, Petit Rasta est localisé à Lyon et fsmrel dans le Relationland. Concernant les clients cette façon minimale de les localiser suffit peut-être et on va s’en contenter, en revanche s’il faut être plus précis et traiter des adresses des clients on aménagera plus tard en conséquence.

Bref, supposons que l’on se contente de la connaissance des localités où situer les clients. Supposons dans un premier temps qu’un client ne se situe que dans une localité : il suffit alors d’ajouter un attribut Localisation dans l’en-tête de la table CLIENT (telle qu’elle existait précédemment) et l’on n’en parle plus :




Mais si un client peut se situer dans plusieurs localités, au lieu d’être monovalué l’attribut Localisation devient multivalué et l’on passe à une relation de composition entre un client et ses localisations :

MOO



MLD/MPD produit par PowerAMC :




Exemple de contenu de la table LOCALISATION :

Code :

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

1
2
3
4
5
6
7
NumCLient   NumLocalisationCli   Localisation
---------   ------------------   ------------
   1               1             Lyon
   1               2             Lille
   1               3             Paris
   2               1             Relationland
   2               2             Bordeaux

La suite va venir (pilotes de projets)...

[fsmrel]

Relations entre les affaires et les personnes

Remettons les choses à plat. Différons d'abord le problème de la personne qui joue le rôle de pilote d’une affaire. Je suppose que la règle de gestion la plus raisonnable concernant les affaires et les personnes est la suivante (appelons-la RG97) :

(RG97) Une affaire concerne au moins une personne et une personne peut être concernée par plusieurs affaires.

Le diagramme de classes correspondant est le suivant :




Et le MLD généré par PowerAMC :




Par contraste, selon votre modélisation, une affaire ne concerne qu’une personne, ce qui paraît bien peu...


Traitons maintenant du pilotage des affaires.

Selon votre MLD, une personne peut être concernée par plusieurs affaires : par rapport à la règle de gestion RG97, nous sommes d’accord sur ce point. Le problème est que vous avez défini une classe Pilote_Projet qui dit simplement qu’une personne est en relation avec des pilotes de projet et qu’un pilote de projet est en relation avec exactement une personne, ce qui ne signifie pas grand-chose, car le but de la manœuvre est quand même, si je ne me trompe, de savoir quelle personne pilote quelle affaire. Il faudrait donc compléter ainsi le diagramme de classes précédent :



D'où le MLD :

[fsmrel]

Je voulais également vous demander si vous saviez ce qu'il fallait mettre dans un rapport d'analyse ?
J'imagine qu'il faut expliciter le choix des tables, le contenu de chacune d'elle ...

Je dirais que, dans votre cas, vous devez définir l’univers du discours, c'est-à-dire ce que vous modélisez, par exemple le suivi du lancement des affaires par les personnes concernées.

Vous devez ensuite fournir la liste des objets « forts », ceux qui jouent les premiers rôles dans cet univers :

AFFAIRE, LANCEMENT, PERSONNE, CLIENT, DAS, SECTEUR,

Ainsi que les objets « faibles », ceux qui n'on aucune autonomie, c'est-à-dire ceux dont l’existence dépend d'autres objets :

LANCEMENT, LOCALISATION,

Ainsi que les seconds rôles, tels que les typologies :

TYPE_LANCEMENT, TYPE_CLIENT.

Pour chaque objet, vous fournirez la liste de ses attributs avec pour chaque attribut, sa définition, le rôle qu’il joue. Attention, ne mentionnez que les attributs qui figureront dans les classes (ou dans les entités-types si vous préférez la notation Merise).

Vous devez ensuite fournir la liste des règles de gestion permettant de définir les associations qui unissent ces objets et qui permettent d’établir l’ensemble des cardinalités (multiplicités) portées par ces associations :

(RG1) Une affaire peut faire l’objet de plusieurs lancements.
(RG2) Un lancement concerne exactement une affaire.
Etc.

Ensuite, vous fournissez le diagramme de classes (ou le MCD selon votre convenance).

Puis ça sera le tour du MLD, mais généré par PowerAMC. Ne le construisez pas à la main, il y aura forcément des différences (voyez vos MLD précédents...) et chaque différence correspondra quatre-vingt-dix-neuf fois sur cent à une erreur de votre part....

Mon professeur m'a demandé l'intérêt de mettre un diagramme où il y a des cardinalités et un où il y en a pas ... et en a conclu en me disant il faut choisir entre l'un ou l'autre !
Je lui ais répondu que sur un MPD il y avait les notions de clés primaires, clés étrangères et qu'elles n'y étaient pas sur l'autre ...

Mette un diagramme de quoi ? Je ne saisis pas la question censée avoir été posée par votre professeur. Si vous produisez un diagramme de classes ou un MCD, il y a forcément des cardinalités, à moins que vous ne dessiniez tout vous-même avec Paint...

S’il s’agit d’un MLD, les Français ont l’habitude depuis trente ou quarante ans d’utiliser une représentation sous forme de graphe (héritage CODASYL, Bachman et compagnie), ce que PowerAMC appelle la notation relationnelle :




Exemple :




Mais rien ne vous interdit d’utiliser la notation conceptuelle pour votre MLD, notation qui en dit un peu plus sur les cardinalités :




Exemple :

Sa question me paraît pas vraiment justifiée étant donné que ces deux diagrammes n'ont pas du tout le même rôle...

A supposer (ce que je ne crois pas) que votre professeur vous demande de choisir entre un diagramme conceptuel (diagramme de classes ou MCD) et un MLD, vous devez choisir le diagramme conceptuel, car le MLD généré n’en est qu’une traduction triviale. Si vous optez pour le MLD, par rétro-conception vous pourrez produire un diagramme conceptuel, mais généralement incomplet quant aux cardinalités minimales 1,N qui sont traduites par les AGL par des cardinalités 0,N sauf si on sait signifier la cardinalité minimale 0 au niveau MLD, ce qui est heureusement le cas avec PowerAMC. Il y a d'autres problèmes dans la rétro-conception, mais cela déborde du sujet qui vous concerne.

[Petit Rasta]

Bonjour,

J'ai eu des problèmes avec ma connexion internet du coup je n'ai pas pu vous répondre plus tôt
J'ai repris vos messages et j'ai modifié mes deux diagrammes en fonction de vos remarques.
J'ai juste eu un peu de mal pour la dernière partie qui concerne les Affaire et les Personnes et je ne suis pas sûr que mon MLD soit juste ...

Au niveau de la localisation il faut que je récupère l'information au niveau d'une affaire.
Parce que là, lorsque je consulterai une affaire, j'aurai le nom du client mais pas sa localité et il me sera impossible de la récupérer comme sont fait les choses.
Si je crée une référence entre affaire et localisation ça ne serait pas très correct si ?


MLD :



MOO :



Voila pour mes deux diagrammes modifiés.

En ce qui concerne le rapport d'analyse :

J'ai compris pour la première partie.
Ensuite je fournis mon MOO puis grâce à mon MOO je génère le MLD et je le mets à la suite.
Faut-il fournir des explications supplémentaires après l'ajout de ces diagrammes ?
Je pense garder le forme originelle des diagramme (notation relationnelle) ce qui me paraît plus claire.
Serait-ce possible de vous montrer mon rapport d'analyse une fois que je l'aurais bien avancé ?

Encore une fois je vous remercie grandement !
Bonne journée !