Discussion :

[BEASTFlo]

Bonjour,


Je suis en train d'élaborer un MCD pour une application PHP.

La gestion en question concerne des interventions informatiques :

Une intervention concerne un client, et regroupe plusieurs prestations.

Une prestation peut concerner un ordinateur (ou non) du client.
Les libellés des prestations sont les suivants :
- Cours
- Dépannage
- Maintenance...

J'arrive donc à la relation ternaire suivante :

http://imageshack.us/photo/my-images...nprestati.png/

J'arrive donc au MPD suivant :

Comporter
-Intervention_id
-Prestation_id
-Ordinateur_id
-nombreHeures

La clé ordinateur_id ne peut pas être nulle...


Ma question est :

Étant donné qu'une prestation peut ne pas concerner d'ordinateur (cours, dépannage sur un matériel autre qu'un ordinateur...), comment puis-je gérer ce cas ?


Ma solution de rechange serait de faire un objet de paramétrage pour l'objet "Prestation" :

Prestation ; 1,1 ----------------- 0,n ; Type Prestation,
Prestation ; 0,1 ----------------- 0,n ; Ordinateur,

Mais qu'advient-il de la prestation, devient-elle unique?


Merci d'avance

[Richard_35]

Bonjour BEASTFlo,

Vite fait sans trop rentrer dans le détail de ton MCD.

Étant donné qu'une prestation peut ne pas concerner d'ordinateur (cours, dépannage sur un matériel autre qu'un ordinateur...), comment puis-je gérer ce cas ?

==> peut-être en "détachant" l'entité "Ordinateur". Donc remplacer :

Comporter(#Intervention_id, #Prestation_id, #Ordinateur_id, nombreHeures, ...)

par

Comporter(#Intervention_id, #Prestation_id, nombreHeures, ...)
Comporter_Ordinateur(#Intervention_id, #Prestation_id, #Ordinateur_id, ...)

Sinon, je pense qu'il serait bon d'écrire, en français, les règles de gestion du triptyque Prestation/Intervention/Ordinateur.

[BEASTFlo]

Bonjour Richard 35,


Merci pour votre réponse. Je n'ai pas pu répondre à votre message étant donné que j'ai du avancer dans le projet, et passer à son développement...

J'ai donc suivi cette solution :

Comporter(#Intervention_id, #Prestation_id, #Ordinateur_id, nombreHeures, ...)

Je ne comprends pas votre solution proposée. Pour moi cela revient à la même chose :

Comporter(#Intervention_id, #Prestation_id, nombreHeures, ...) ---> Ma solution sans relier l'ordinateur.
Comporter_Ordinateur(#Intervention_id, #Prestation_id, #Ordinateur_id, ...) Ma solution sans le nombre d'heures ...


Merci pour votre suivi.

[Richard_35]

Bonjour BEASTFlo,

Je ne comprends pas votre solution proposée. Pour moi cela revient à la même chose

==> eh bien, non, ce n'est pas la même chose.

Plusieurs points :

La clé ordinateur_id ne peut pas être nulle...
.../...
Étant donné qu'une prestation peut ne pas concerner d'ordinateur

==> avec :

Comporter(#Intervention_id, #Prestation_id, #Ordinateur_id, nombreHeures, ...)

#Ordinateur_id pourra être NULL ce qui est déconseillé pour une clé étrangère, a fortiori si elle fait partie d'une clé primaire.


Avec :

Comporter(#Intervention_id, #Prestation_id, nombreHeures, ...)
Comporter_Ordinateur(#Intervention_id, #Prestation_id, #Ordinateur_id, ...)

Le point d'entrée est unique (entête) : le couple Intervention_id/Prestation_id.
La liste des ordinateurs figurant dans le détail (ou pas).

[BEASTFlo]

Merci pour votre réponse.


Votre solution reviendrai à faire ce schéma (MCD) en pièce jointe?

Merci

[Richard_35]

Pas tout à fait...

Il faut lier l'association "Comporte" à "Ordinateur" avec 0,n / 0,n.

Si ton logiciel de modélisation ne te le permet pas, transformes "Comporte" en entité que tu lieras à "Comporter_Ordinateur" avec 0,n / 1,1.

[Richard_35]

Pour préciser :

Code :

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

1
2
3
4
5
6
7
8
9
Intervention -1,n---[Comporter prestation]---0,n- Prestation
                               |
                              0,n
                               |
                    [Concerner ordinateur]
                               |
                              0,n
                               |
                           Ordinateur

donnant :

Prestation(IdPrestation, Libelle, ...)
Ordinateur(IdOrdinateur, Libelle, ...)

Intervention(IdIntervention, ...)
Intervention_Comporter_Prestation(#IdIntervention, #IdPrestation, ...)
Intervention_Comporter_Prestation_Concerner_Ordinateur(#IdIntervention, #IdPrestation, #IdOrdinateur, ...)

[BEASTFlo]

Merci pour vos précieux conseils.


Cependant, cette solution est-elle bien "Merisienne" ? Car le projet doit être présenté pour un examen ..

[Richard_35]

Bonjour BEASTFlo,

cette solution est-elle bien "Merisienne" ?

==> je ne suis pas sûr qu'une association entre une association et une entité soit permise. Dans la négative, il faut transformer l'association [Comporter prestation] en entité avec les cardinalités qui vont bien : [1,n]/[0,n] => [1,n/1,1]/[0,n/1,1]. Les tables présentées en sont la traduction.

[BEASTFlo]

Bonjour Richard_35,


Dans la négative ?

En gros, il vaut mieux que j'attende d'avoir passé mes examens avant d'opter pour cette solution..


Merci

[Richard_35]

Bonjour BEASTFlo,

Dans la négative ?
En gros, il vaut mieux que j'attende d'avoir passé mes examens avant d'opter pour cette solution..

==> , pour l'ironie... Comme je te l'ai dit, je ne suis pas un spécialiste de la méthode Merise : je la trouve "puissante" car elle règle 98% des soucis de modélisation habituels.


Je pense qu'un minimum de recherche de ta part () peut répondre à la question simple :

Une association entre une association et une entité est-elle permise ?

==> si oui, le schéma devrait être OK ;
==> si non :

il faut transformer l'association [Comporter prestation] en entité avec les cardinalités qui vont bien

La structure des tables données en est l'illustration.

[BEASTFlo]

Merci encore pour votre aide.


Je vais faire quelques recherches, mais ayant lu diverses cours sur la méthode Merise, il ne me semble pas avoir rencontré ce genre de chose. De plus, en deux ans de formation en informatique de gestion (uniquement sur la méthode Merise), je n'ai pas non plus rencontré ce cas de figure.



Merci pour votre aide


Je vous tiendrai au courant si j'arrive à trouver des réponses.

[CinePhil]

Comme te le conseillait Richard, tu devrais écrire tes règles de gestion.

Une intervention concerne un client, et regroupe plusieurs prestations.

D'après ce qui précède, je les vois de la sorte :
1) Une intervention regroupe de une à plusieurs prestations et une prestation peut être regroupée dans plusieurs interventions.


2) Une intervention peut concerner plusieurs ordinateurs et un ordinateur peut être concerné par plusieurs interventions.

MCD :
ordinateur -0,n----concerner----0,n- intervention -1,n----regrouper----0,n- prestation

Si tu dois mémoriser plus précisément quelles opérations ont été effectuées sur chaque ordinateur, alors, comme le suggère le début de cette phrase, il faut découper l'intervention en "opérations".

Règles de gestion :
1) Une intervention regroupe de une à plusieurs opérations et une opération fait partie d'une seule intervention.

2) Une opération concerne une seule prestation et une prestation peut être concernée par plusieurs opérations.

3) Une opération peut concerner un ordinateur et un ordinateur peut être concerné par plusieurs opérations.

MCD :
operation -1,1----regrouper----1,n- intervention
|---------------1,1----concerner----0,n- prestation
|---------------0,1----concerner----0,n- ordinateur

Tables :
intervention (int_id, int_date...)
prestation (prt_id, prt_libelle...)
ordinateur (ord_id, ord_id_client, ord_matricule...)
operation (opr_id, opr_id_intervention, opr_description...)
opr_concerner_ord (oco_id_operation, oco_id_ordinateur)

Attention ! Il faudrait modéliser une contrainte d'inclusion pour empêcher qu'une opération ait lieu sur un ordinateur appartenant à un client autre que celui de l'intervention associée à l'opération. En BDD, cela entraîne la création d'une contrainte CHECK ou d'un trigger si le SGBD ne connaît pas ce type de contrainte (MySQL notamment).

Pour ce qui est de pointer une association sur une association, ce n'est en principe pas à faire. Il vaut mieux porter un peu plus loin sa réflexion et transformer l'association en entité-type associative.
L'exemple classique est celui de la commande de produits.
D'abord on considère qu'une commande concerne de un à plusieurs produits :
commande -1,n----concerner----0,n- produit

Puis, comme on veut gérer les livraisons et facturations partielles à partir de la commande, on devrait alors "pointer" une association sur l'association "concerner" :
commande -1,n----concerner----0,n- produit
livraison -1,1--------------|

En réfléchissant un peu plus, on se rend compte qu'en fait on peut modéliser les lignes d'une commande :
commande -1,n----comprendre----(1,1)- ligne_commande -(1,1)----concerner----0,n- produit
livraison -1,n----concerner----0,n------------------|

=> La structure des tables sera identique mais le schéma est meilleur.

[BEASTFlo]

Bonjour CinePhil,


Merci pour votre aide.


Pour l'instant, j'ai donc le MCD suivant (PJ).



Je vais donc me résoudre à écrire les règles de gestion :


Je n'avais pas intégré le terme d'"opération", ne pensant pas nécessaire d'y mettre une description détaillée pour chaque prestation. Si j'ai bien compris, l'opération sert uniquement à rendre unique une "prestation, ou intervention chez le client".


1) Un client possède un ou plusieurs ordinateurs.

2) Une intervention concerne un seul client.

3) Une intervention regroupe plusieurs prestations (cours, maintenance, dépannage, etc..).

4) Une prestation concerne un ordinateur (ou aucun : création de site, etc..) et un ordinateur peut etre concerné par plusieurs prestations0

5) Une prestation peut être inclue dans une ou aucune intervention.


Pour l'instant, l'application fonctionne, mais m'oblige à intégrer obligatoirement un ordinateur pour chaque prestation (association entre intervention, prestation et ordinateur). Je dois donc supprimer les prestations du genre "création de site", ou encore "cours".

J'ai un peu galéré au niveau du PHP avec Symfony2, pour les formulaires imbriqués, du fait de la ternaire...



Concernant la contrainte d'inclusion, je la gère du coté PHP. Mais si besoin, je mettrai une sécurité au niveau de la BDD.


Merci pour votre aide.

[CinePhil]

Ça c'est le MCD avec la ternaire qui, à mon avis, n'a pas lieu d'être.

Ce que j'ai essayé de t'expliquer est que tu n'as pas une association ternaire mais deux associations bianaires, que ce soit, comme je l'ai fait au final, en détaillant les interventions en opérations ou pas, comme dans mon premier MCD.

D'ailleurs, si tu lis ton MCD, tu as écrit, via ton association ternaire "Comporte", ceci :
1) Une intervention comporte de une à plusieurs prestations ;
2) Une intervention comporte de un à plusieurs ordinateurs ;
3) Une prestation peut être comprise dans plusieurs interventions ;
4) Une prestation peut comprendre plusieurs ordinateurs ;
5) Un ordinateur peut être compris dans plusieurs interventions ;
6) Un ordinateur peut être compris dans plusieurs prestations.

Sur le reste de ton MCD...

1) Association "Concerne"
Elle suppose que la facture soit créée en même temps que l'intervention, auquel cas les propriétés de la facture peuvent carrément faire partie de l'entité type Intervention.
Mais comme il y a une date de facture et une date d'intervention, on peut supposer logiquement que celles-ci sont potentiellement différentes et ce sont en fait tes cardinalités qui sont fausses.

2) Association "Appliquer tarif déplacement"
Ce nom d'association trop long me laisse à penser qu'il devrait y avoir une entité type "tarif_deplacement" et qui n'est pas modélisé ici.

[BEASTFlo]

1) J'ai corrigé les cardinalités entre la facture et l'intervention.

2) L'intervention "possède" une voiture de fonction, les frais de déplacements sont donc calculés en programmation, avec la distance en km du membre, et le prix du carburant et la conso/100Km de la voiture.


Concernant le reste, j'ai fais le MCD suivant (PJ).

Cependant, je ne vois pas l'intérêt de cette table là :

opr_concerner_ord (oco_id_operation, oco_id_ordinateur)

Et surtout d'où elle vient (par rapport au MCD)?


En effet, le MCD ne correspondait pas vraiment à mes règles de gestion.


Merci beaucoup.

[CinePhil]

Cependant, je ne vois pas l'intérêt de cette table là :

opr_concerner_ord (oco_id_operation, oco_id_ordinateur)

Elle vient de cette règle de gestion :

3) Une opération peut concerner un ordinateur et un ordinateur peut être concerné par plusieurs opérations.

Et de ce morceau de MCD :
operation -0,1----concerner----0,n- ordinateur

Car avec les cardinalités (0,1 - 0,n), il faut une table associative.

La petite erreur que j'ai faite par rapport à mon schéma, c'est que la clé primaire de cette table devrait être seulement l'identifiant de l'ordinateur puisque j'ai considéré que l'opération ne pouvait concerner qu'un seul ordinateur.

[BEASTFlo]

Avec les cardinalités (0,1 - 0,n), il faut une table associative ?

Ce n'est pas plutôt avec 0,n - 0,n ?

Justement, cette règle traduit bien le "..,1" :

Une opération peut concerner un ordinateur et un ordinateur peut être concerné par plusieurs opérations.

Sinon, le MCD vous semble-t-il correct ? (Pour que je puisse commencer à faire les modifications sur l'application..)


Est-il possible de remplacer le terme "opération" par prestation qui fais plus professionnel, et de rattacher à la prestation un "type prestation" qui contiendra les types suivants : cours, maintenance, dépannage, création de site, etc.


Merci.

[CinePhil]

Avec les cardinalités (0,1 - 0,n), il faut une table associative ?

Ce n'est pas plutôt avec 0,n - 0,n ?

Toi, tu n'es pas allé lire mon billet de blog dont j'ai donné le lien dans mon message précédent !

Justement, cette règle traduit bien le "..,1" :

0,1oui.
Donc 0 d'un côté de l'association et 0 de l'autre => table associative pour ne pas avoir de clé étrangère nulle.

Sinon, le MCD vous semble-t-il correct ? (Pour que je puisse commencer à faire les modifications sur l'application..)

Ça me semble mieux en effet.

Juste un truc : le prix du carburant change au fil du temps. Tu devrais modéliser ça pour ne pas retrouver une vieille intervention avec un prix de déplacement calculé sur le prix actuel.


Est-il possible de remplacer le terme "opération" par prestation qui fais plus professionnel, et de rattacher à la prestation un "type prestation" qui contiendra les types suivants : cours, maintenance, dépannage, création de site, etc.


Merci.[/QUOTE]

[BEASTFlo]

Ça me semble mieux en effet.

Juste un truc : le prix du carburant change au fil du temps. Tu devrais modéliser ça pour ne pas retrouver une vieille intervention avec un prix de déplacement calculé sur le prix actuel.


Est-il possible de remplacer le terme "opération" par prestation qui fais plus professionnel, et de rattacher à la prestation un "type prestation" qui contiendra les types suivants : cours, maintenance, dépannage, création de site, etc.


Merci.

Oubli de fin de message ?


Je réitère donc ma question :
Est-il possible de remplacer le terme "opération" par prestation qui fais plus professionnel, et de rattacher à la prestation un "type prestation" qui contiendra les types suivants : cours, maintenance, dépannage, création de site, etc ?


Concernant le nombre d'heures de chaque opération, je le met dans l'entité "opération"/"prestation, qui remplace l'opération" ?


Je suis d'accord avec votre principe, seulement ce n'est pas vraiment ce que l'on m'a appris en 2ans, et je n'avais jamais lu cela dans différents cours.


Pour le prix du carburant, je ne sais pas, à cet instant, comment modéliser cela..


Merci beaucoup !