Discussion :

[Nimothenicefish]

Bonjour, Bonjour,

Voilà, j'effectue un stage dans le cadre de mon BTS Informatique, et durant la phase d'analyse je coince sur le MCD par rapport à une information qui ne paraît pas sur celui-ci
J'ai fourni en pièce-jointe mon MCD pour mieux le comprendre. Pour ceux qui le regarde (et je les remercie), mon problème vient du faite que un service possèdent une ou plusieurs fonctions, hors d'après mon schéma il n'est pas possible de connaître l'ensemble des fonctions d'un service.

Pour plus d'explication sur le reste du MCD : (la partie du haut, n'est pas utile pour mon soucis)

A une date donnée, un service evalue une evaluation. La même évaluation peut etre saisie par un autre service à la même date (bon ca peut paraître bizard ...)
Une évaluation concerne une seule fonction du service


ps : J'ai pensé à relier Service a fonction et ajouter une contrainte d'unicité de Service/Evaluation avec evaluation de tel sorte que pour une Evaluation donné faite par un service, cela correspond à une fonction. Cette solution utilisant la méthode merise 2 me paraît conforme, seulement le logiciel que je vais utilisé pour modélisé le schéma (Windev 12), je doute qu'il puisse employé du merise 2

Cordiallement, moi-même

[SQLpro]

Pourquoi ne pas faire une association entre service et fonction ?

A +

[Nimothenicefish]

J'y ai pensé, seulement dans ce cas précis, cela ne ferait-il pas une information redondante ?

[hed62]

Si cette information serait redondante, c'est que, par définition elle est déjà présente, donc disponible... j'en reviens donc à ton titre :p

[TheLeadingEdge]

Bonjour,

J'ai pensé à relier Service a fonction [...]

Oui.

et ajouter une contrainte d'unicité de Service/Evaluation avec evaluation de tel sorte que pour une Evaluation donné faite par un service, cela correspond à une fonction.

Si par là tu veux dire : créer une contrainte qui vérifie qu'une occurence de l'assoc. ''evaluer'' doit exister dans l'assoc. entre ''Fonction'' et ''Service'', c'est tjours oui.

cela ne ferait-il pas une information redondante

Non. La responsabilité Avoir une fonction et Evaluer une fonction n'est pas la même. Les informations obtenues sont différentes.

Cette solution utilisant la méthode merise 2 me paraît conforme,

Encore oui. Un MCD est conceptuel. Il modélise la vie réelle. Tu n'as pas à prendre en compte d'éventuelles impossibilités techniques (de ton logiciel, pas de la vie réelle) à ce niveau. Si ton logiciel ne sait pas faire, la solution sera cherchée au niveau physique.

seulement le logiciel que je vais utilisé pour modélisé le schéma (Windev 12), je doute qu'il puisse employé du merise 2

Et en ce qui concerne les contraintes d'un MCD étendu elle passe par l'écriture de triggers. D'ailleurs je crois qu'aucun AGL ne traduit les contraintes interrelation automatiquement en trigger. Il faut les faire à la main.

[Nimothenicefish]

Merci TheLeadingEdge pour tes informations précieuse , elle me seront surement fort utile ...
Cependant j'ai modifié mon MCD (fichier joint), pour tenté de le rendre moin complexe (mais j'en arrive toujours à le rendre complexe d'une certaine manière -_-). j'ai créer une agrégation. Semble t-il conforme ? et est-ce que la liaison entre la table Service et Pôle, vous semble correct vis à vis de l'agrégation ?

Merci

[TheLeadingEdge]

re,

Voici ce que je comprend de ce que tu dis dans ton 1er post.
1 pole est composé de services qui ont différentes fonctions.
1 fonction d'un service (et pas un service) est évaluée par 1 service à une date donnée.
Si j'ai bien compris, on devrait pouvoir éviter les contraintes (ou les associations d'association)


Ce qui donne le MCD suivant

Par contre j'ai un doute quand tu écris

un service evalue une evaluation.

Si ce n'est pas une faute de frappe, il faudrait plus de détail sur tes règles de gestion. On pourrait déjà rajouter une nouvelle association. (que j'ai mis en gris sur le modèle) Pas besoin de te dire pourquoi je l'ai appelée comme ça. Mais je n'ai pas trop le temps de creuser plus pour le moment.

[Nimothenicefish]

Woooow Je te remercie vraiment de t'intéressé à mon cas et de tenter de me donner ton point de vue

Bon, je crois que plus d'explication encore de ma part sont à faire :

Un Service évalue pour une fonction lui concernant, un risque à une date donnée (et non évalue une évaluation). C'est pour cette raison que j'ai modifié mon schéma (voir message 2)

(1Service+1Fonction) à une date pour un risque donne une évaluation

En faite on doit obtenir un tableau de ce type :



ps: je viens juste d'avoir eu mon prof d'analyse au tel, et il m'a dit que mon 2eme MCD était correct selon lui

[TheLeadingEdge]

Re,

Un Service évalue pour une fonction lui concernant, un risque à une date donnée (et non évalue une évaluation).

Bon on avance. On est passé de l'évaluation d'un service à celle d'un risque (en passant par la fonction).
A l'exception de la contrainte d'inclusion, ce modèle là devrait te permettre de générer un schéma

[Nimothenicefish]

ReBonjour,

Il ya une autre donnée a prendre en compte et que j'ai oublié :
A une date donnée, le risque A est présent au sein du niveau du Service ou de l'etablissement entier
On peut peut etre le definir de cette maniere là egalement je pense :
A une date donnée, l'evaluation X s'applique à un niveau (soit du service ou de l'etablissement)
>> donc on doit créer une table Niveau (car on pourrais à l'avenir ajouter un nouveau Niveau)

Par rapport à ton schéma, si j'ai bien compris la clé primaire de la table Evaluation est composé des clés primaires des tables Date, Risque, Service et fonction ??
Et tu as fait une contrainte d'inclusion pour dire qu'une Evaluation A faite par un service B, correspond à une fonction Y de se service ??

[TheLeadingEdge]

Par rapport à ton schéma, si j'ai bien compris la clé primaire de la table Evaluation est composé des clés primaires des tables Date, Risque, Service et fonction ??

Oui. C'est la raison de la forme (1,1) (lien identifiant). Comme ''evaluation'' n'est pas une assoc. les clefs ne migreront pas automatiquement.

Et tu as fait une contrainte d'inclusion pour dire qu'une Evaluation A faite par un service B, correspond à une fonction Y de se service ??

Oui. Au niveau physique il faudra vérifier que que l'on ne puisse insérer 1 couple {service,fonction} ds évaluation que s'il existe 1 occurence du même couple {service,fonction} dans l'association entre service et fonction.
D'ailleurs il faudrait peut-être faire la même chose pour ceci :

A une date donnée, le risque A est présent au sein du niveau du Service ou de l'etablissement entier

Si j'ai compris cette nvelle règle, il faudrait vérifier que l'on n'insère un couple {risque,service} que s'il existe. Comme le risque dépend du niveau c'est peut-être un peu plus compliqué à modéliser.

[Nimothenicefish]

Merci pour tes explications, cela m'aide à mieux cerner mon analyse, à le voir sous un autre point de vue.

Pour le niveau : En faite, je me suis mal expliqué >> Dans la table Evaluation, j'ai une donné qui s'apelle "Action proposé" c'est une action que propose le service pour corriger le risque qu'elle evalue.
Et pour cette action proposé, elle doit lui donné un niveau d'action : soit cette action doit etre faite au sein de son service , soit au sein de l'établissement.