Discussion :

[gestrad]

Bonjour,

J'ai un TP à réaliser. Il s'agit de modéliser une gestion de prestations... pour un prestataire de services.

Le début de l'énoncé me paraît simple :
- Un client possède un ou plusieurs site(s).
- Les prestations peuvent concerner un site ou le client (en fait l'ensemble de ses sites)

J'ai modélisé le MCD suivant



C'est pour la suite que ça se gâte :
- Les prestations sont de différents types
. service (hébergement, messagerie, ...)
. liaison (adsl, sdsl)
- les liaisons sont définis par une adresse ip, un masque, un débit, …
. une liaison adsl possède un débit max, ...
. une liaison sdsl une interface, ...
- un hébergement possède une capacité, une adresse ftp, ...
- une messagerie possède un nombre de comptes, ...

Je ne vois pas comment faire le lien entre prestation, type de prestation, liasion, adsl, sdsl, hebergement, ...

D'avance merci pour vos lumières

[fsmrel]

Bonsoir,


Vous pouvez réfléchir à la mise en oeuvre de la spécialisation :

Le type de prestation se spécialisant en hébergement, messagerie, liaison, cette dernière se spécialisant à son tour en liaison adsl et liaison sdsl.

Maintenant, je ne me souviens pas qu'AnalyseSI permette de modéliser la généralisation/spécialisation (héritage).


Par ailleurs, j'attire votre attention sur le fait que selon votre diagramme, une prestation peut être souscrite par un client c1 et concerner les sites de clients, c2, c3, etc. Pour empêcher cela, il faudrait utiliser l'identification relative, de manière à ce qu'au niveau logique l'attribut id_client se propage jusqu'à CONCERNE par les deux chemins (possède et souscrit).

Mais je ne me souviens pas que l'identification relative soit possible avec AnalyseSI.

[gestrad]

Merci bien pour l'aiguillage sur la notion d'héritage. Je ne maîtrise pas trop et j'avais carrément zappé cet aspect.

Sinon je suis allé à la "pèche aux informations" :
- Les prestations peuvent concerner un client sans lien vers un site ( et non pas tous les sites comme indiqué dans le premier post )

[fsmrel]

Bonjour gestrad,

Merci bien pour l'aiguillage sur la notion d'héritage. Je ne maîtrise pas trop et j'avais carrément zappé cet aspect.

La maîtrise de la généralisation/spécialisation (vous êtes sur le bon chemin) est essentielle pour bien modéliser et je ne puis que vous engager vivement à approfondir ce sujet très intéressant au demeurant. Épluchez par exemple la discussion avec Heledir "Modélisation gestion commerciale", discussion dans laquelle le thème est abordé à partir du message #10.

Avec votre dernier MCD, la spécialisation répond à la suggestion que j’avais faite. Quelques remarques quand même :

La spécialisation que vous proposez porte directement sur la prestation :

Une prestation est soit une prestation de messagerie, soit une prestation d’hébergement, soit une prestation de liaison.

On en déduit que, pour reprendre le sous-type Messagerie, l’attribut nb_compte (une incidente : évitez de laisser un blanc entre nb et compte, les SGBD n’aiment pas ça) prend des valeurs qui ne dépendent pas du type de prestation, mais seulement de la prestation.

De même, pour l’attribut capacite du sous-type Hebergement, etc.

Pour résumer, existe-t-il des propriétés qui relèvent du type de prestation et d’autres de la prestation (adresse ip par exemple dans ce dernier cas) ?

A supposer que, comme le laisse supposer votre MCD, l’ensemble des propriétés relève seulement de la prestation, et si l’entité-type TypePrestation prend seulement les valeurs "Messagerie", "Hébergement, "Liaison", elle n’apporte rien sinon de la redondance et elle peut disparaître avec un bon coup de rasoir d’Ockham.


Je note que l’attribut code_client de l’entité-type Client est vraisemblablement sujet à une contrainte d’unicité (deux clients ne peuvent pas avoir le même code). Si tel est le cas, il faudra définir un identifiant alternatif (fenêtre « Propriétés de l’entité - CLIENT » / onglet Identifiants). Même principe pour l’attribut code_prestation de l’entité-type Prestation.

Les prestations peuvent concerner un client sans lien vers un site (et non pas tous les sites comme indiqué dans le premier post)

Soit, mais rien n’empêche qu’une prestation souscrite par le client c1 concerne un site du client c2. Pour empêcher ce genre de facétie, le diagramme logique (pour cette partie) devra ressembler à ceci :




A suivre...

[gestrad]

Le retour...

Je comprend tout à fait le soucis le problème que vous soulevez concernant l'attribution d'une prestation pour un site n'appartenant pas au bon client.

J'ai bataillé avec le logiciel de conception ( PowerDesigner 15 ) afin d'arriver sur votre modèle logique sans succès.
J'étais parti sur ce modèle logique:

[Client]---1,n---(possède)---(1,1)---[Site]
[Client]---0,n---(souscrit)---(1,1)---[Prestation]
[Prestation]---0,1---(R1)---(1,1)---[Concerne]
[Site]---0,n---(R2)---(1,1)---[Concerne]

Mais je n'obtiend pas le transport de prestation_id dans concerne


J'ai donc effectué un reverse engineering de votre modèle, et obtenu le résultat suivant :
[Client]---0,n---(possède)---(1,1)---[Site]
[Client]---0,n---(souscrit)---(1,1)---[Prestation]
[Prestation]---0,1---(R1)---(1,1)---[Concerne]
[Site]---0,n---(R2)---1,1---[Concerne]

Dans ce cas le peut ne pas posséder de site, hors il doit un posséder au moins un.



Concernant l'entité "TypePrestation" : je la voyait comme une table de paramètrage, servant à stoker un code et une désignation.
Cette partie à évoluée je reviendrai dessus ultérieurement.

[fsmrel]

Bonsoir le revenant,

J'ai donc effectué un reverse engineering de votre modèle, et obtenu le résultat suivant :

[Client]---0,n---(possède)---(1,1)---[Site]
[Client]---0,n---(souscrit)---(1,1)---[Prestation]
[Prestation]---0,1---(R1)---(1,1)---[Concerne]
[Site]---0,n---(R2)---1,1---[Concerne]

Dans ce cas le [Client] peut ne pas posséder de site, or il doit un posséder au moins un.

C'est normal qu'au lieu d'une cardinalité 1,N vous obteniez une cardinalité 0,N, car en l'occurrence, au niveau logique (MLD) les AGL n'ont pas la notion de cardinalité minimale : ils forcent donc celle-ci à 0 au niveau conceptuel (MCD) lors d'une rétro-conception.

J'ai bataillé avec le logiciel de conception ( PowerDesigner 15 ) afin d'arriver sur votre modèle logique sans succès.
J'étais parti sur ce modèle logique:

[Client]---1,n---(possède)---(1,1)---[Site]
[Client]---0,n---(souscrit)---(1,1)---[Prestation]
[Prestation]---0,1---(R1)---(1,1)---[Concerne]
[Site]---0,n---(R2)---(1,1)---[Concerne]
Mais je n'obtiend pas le transport de prestation_id dans concerne

Je suppose que vous voulez dire que vous êtes parti sur le modèle conceptuel. Mais c’est l’occasion de réaliser un petit exercice car le problème de l’affectation des prestations d’un client à des sites d’autres clients est le genre de problème qui revient assez régulièrement.

Considérons donc le MCD suivant (j’utilise la notation E/R plutôt que la notation Merise particulièrement pénible avec Power AMC dans la dérivation dès qu’il y a des cardinalités 0,1 : production de cycles) :




Ce qu’on voudrait, c’est obtenir par dérivation le MLD que j’ai fait figurer dans mon premier message :




Mais comme l’AGL ne propose pas la mise en œuvre de contraintes permettant de signifier que le client qui a souscrit une prestation est le même que celui qui possède le site auquel la prestation fait référence, le MLD produit montre bien qu’il est malheureusement possible d’associer les prestations d’un client aux sites d’un autre client :




En l’absence de contrainte, l’AGL produit donc pour la table CONCERNE deux attributs faisant référence à des clients qui peuvent être différents, PRE_Id_Client et Id_Client. Le couple {PRE_Id_Client, Id_Prestation} est clé primaire de la table CONCERNE et en même temps clé étrangère par rapport à la clé primaire {Id_Client, Id_Prestation} de la table PRESTATION. La paire {Id_Client, Id_Site} de la table CONCERNE est simplement clé étrangère par rapport à la clé primaire de la table SITE.

On est obligé de modifier ce MLD : il faut faire comprendre à l’AGL que ce n’est pas l’attribut PRE_Id_Client mais l’attribut Id_Client qui participe à la clé primaire de la table CONCERNE ainsi qu'à la clé étrangère référençant la clé primaire {Id_Client, Id_Prestation} de la table PRESTATION. Ceci fait, l’attribut PRE_Id_Client pourra disparaître (on aurait pu conserver celui-ci et faire disparaître Id_Client, mais pour être complet, je souhaite monter que l’ordre des attributs dans une clé étrangère doit être le même que celui de la clé primaire cible, celle de la table PRESTATION dans l’exemple).

Je rappelle que dans ce qui suit j’utilise Power AMC (V11), mais on peut supposer que les manipulations avec Power Designer doivent être voisines (vous me direz ). Quoi qu’il en soit je détaille pour que cela rende service à ceux qui connaîtraient le même problème.

Pour commencer le travail de modification, il faut cliquer sur le lien connectant les tables PRESTATION et CONCERNE. Il y a alors ouverture de la fenêtre « Propriétés de la référence » et l’on clique sur l’onglet « Jointures ». S’affiche alors :




Dans la colonne « Colonne de la table enfant » on remplace l’attribut PRE_Id_Client par l’attribut Id_Client :



=>




Il faut aussi remplacer la clé primaire {PRE_Id_Client, Id_Prestation} de la table CONCERNE par le couple {Id_Client, Id_Prestation}.

Situation initiale :



Après les clics qui vont bien dans les cases à cocher :




A ce stade, l’attribut PRE_Id_Client ne participe plus à rien et on peut le supprimer. LE MLD devient le suivant :




La clé primaire de la table CONCERNE doit être cette fois-ci le couple {Id_Client, Id_Prestation} et non pas {Id_Prestation, Id_Client}, aussi s’en assure-t-on en ouvrant (comme ci-dessus) la fenêtre « Propriétés de la table » et en cliquant cette fois-ci sur l’onglet « Clés» :




On double-clique sur la ligne Identifiant_1
=>





On clique sur l’onglet Colonnes
=>




L’ordre des colonnes est effectivement à inverser (c'est le petit piège évoqué) :




Et, bien que ça ne soit pas strictement nécessaire, on permute aussi l’ordre des colonnes dans l’en-tête de la table CONCERNE :




Et voilà.

[gestrad]

Merci beaucoup pour cette explication très détaillée.
Comme ne l'a pas dit Bourvil "Ah ben forcément il va beaucoup mieux marcher maintenant"

j’utilise la notation E/R plutôt que la notation Merise particulièrement pénible avec Power AMC dans la dérivation dès qu’il y a des cardinalités 0,1 : production de cycles

J'avais remarqué en effet que pour les mêmes cardinalités le MLD généré pouvait varier.

Le but de cette première partie était d'observer les interprétations différentes sur un énoncé volontairement flou...

Je vais tagger "Résolu" ce post et reviendrai vers vous pour une validation du prochain modèle, où comme vous l'aviez présagé, le type de prestation aura un rôle plus à sa mesure...