Discussion :

[rad_hass]

Bonjour,

J'ai un exercice de modélisation pour lequel je voudrais avoir des avis.

Je dois modéliser des forfaits d'entretiens pour un vendeur de ce type prestations (type feu vert ...).

- Dans l'utilisation, à partir d'un modèle et d'une motorisation on propose une liste de forfait.
- Il existe des données par défaut et la possibilité que chacun des vendeurs personnalise la description et le prix.
- L'application doit gérer le multilinguisme, donc on doit pouvoir gérer plusieurs traductions des libellés et descriptions.

Voici une proposition de MCD, qu'en dites vous ?



Merci d'avance

[fsmrel]

Bonsoir,


Les cardinalités sont à l'envers.

Par exemple, vous dites qu'une occurrence de MODEL fait référence à au plus une occurrence de VEHICULE.

Vous utilisez des identifiants alternatifs (ai) : si ensuite vous utilisez SQL, celui-ci trouvera que ça manque de clés primaires : en conséquence, au niveau conceptuel, chaque entitié-type devrait avoir un identifiant primaire (pi).

Vous devriez signaler quel outil de modélisation vous utilisez (PowerAMC, ou PowerDesigner) et sa version.

Il serait bien que vous expliquiez brièvement la signification de vos entités-types et associations-types.

Sachez que les habitués de ce forum utilisent la notation Merise plutôt que la notation Entité/Relation, d'où vraisemblablement l'absence de réponses
à votre message.

[rad_hass]

Bonjour fsmrel,

Merci beaucoup pour votre réponse.

J'avoue préférer également le model merise, j'avais utilisé un peu à la hâte E/R car il y était par défaut, j'utilise Power Amc version 15.1 sinon. Voici un model Merise (E/A).



Concernant les associations, je ne sais pas si c'est un oublie de ma part, mais je ne comprends pas pourquoi on doit avoir obligatoirement des association au libellé différent.

Il y a peut être des entités qui sont en réalité des association ce qui rend l'association obligatoire futile (maintenant que j'y pense ...).

Donc un forfait est une offre de révision pour un couple model, motorisation (qui est représenté ici par l'entité véhicule, car ça du sens).
Model est un model de véhicule.
Motorisation est la puissance du moteur.

Les entités traduction gèrent le multilinguisme, elles devraient plutôt être des associations ?

J'espère que c'est plus claire cette fois.

En tout cas merci encore

[fsmrel]

J'avoue préférer également le model merise

Chaque notation a ses qualités et ses défauts. La notation E/R est moins dogmatique, moins contraignante que la notation merisienne, mais peu importe, l’essentiel est que vous vous sentiez plus à l’aise (c’est comme les chaussures...)

Cela dit, vous avez défini une association-type ternaire PROPOSER à laquelle participent les trois entités-types VENDEUR, FORFAIT et VENDEUR_FORFAIT_TRADUCTION. Or cette association-type est porteuse d’une propriété Prix_Vendeur, on en déduit donc que ce prix dépend non seulement du vendeur et du forfait, mais aussi de la traduction : j’ai des doutes...

J’aurais tendance à dire que VENDEUR_FORFAIT_TRADUCTION est une propriété multivaluée de PROPOSER (une proposition est libellée dans un certain nombre de langues). C’est vraisemblablement ce que vous cherchiez à exprimer avec votre premier modèle.

D’après votre association-type TRADUISER (qu’il faudrait nommer TRADUIRE, eu égard à la langue française), un forfait fait l’objet d’une traduction (et une seule), tandis qu’une traduction peut être utilisée pour plusieurs [types de] forfaits. Est-ce bien ce que l’on veut ? Même principe pour les autres traductions.

Les entités traduction gèrent le multilinguisme, elles devraient plutôt être des associations ?

Cf. ce qui précède.

Par ailleurs il faudrait aussi définir une entité-type LANGUE.


Vous n’êtes pas avare des ressources mémoire : plutôt qu’un type CARACTÈRE (1000), il faudrait utiliser le type VARCHAR.

Concernant les associations, je ne sais pas si c'est un oublie de ma part, mais je ne comprends pas pourquoi on doit avoir obligatoirement des association au libellé différent.

Entités-types et associations-types, même combat.

[rad_hass]

Chaque notation a ses qualités et ses défauts. La notation E/R est moins dogmatique, moins contraignante que la notation merisienne, mais peu importe, l’essentiel est que vous vous sentiez plus à l’aise (c’est comme les chaussures...)

Cela dit, vous avez défini une association-type ternaire PROPOSER à laquelle participent les trois entités-types VENDEUR, FORFAIT et VENDEUR_FORFAIT_TRADUCTION. Or cette association-type est porteuse d’une propriété Prix_Vendeur, on en déduit donc que ce prix dépend non seulement du vendeur et du forfait, mais aussi de la traduction : j’ai des doutes...

J’aurais tendance à dire que VENDEUR_FORFAIT_TRADUCTION est une propriété multivaluée de PROPOSER (une proposition est libellée dans un certain nombre de langues). C’est vraisemblablement ce que vous cherchiez à exprimer avec votre premier modèle.

Oui c'est juste, donc au finale ça sera traduit par une seul table dans laquelle on aura la duplication de prix ?

D’après votre association-type TRADUISER (qu’il faudrait nommer TRADUIRE, eu égard à la langue française), un forfait fait l’objet d’une traduction (et une seule), tandis qu’une traduction peut être utilisée pour plusieurs [types de] forfaits. Est-ce bien ce que l’on veut ? Même principe pour les autres traductions.

hum, j'avais pas vu ces deux énormités le traduiser et l'inversion des cardinalités, c'est bien le contraire pour un forfait il existe plusieurs traductions et une traduction appartient à un seul forfait.

J'ai pris en compte vos remarques et je les ai intégré dans mon modèle, merci encore.

[fsmrel]

Bonsoir,

au final ça sera traduit par une seule table dans laquelle on aura la duplication de prix ?

Positionnons-nous au niveau relationnel. Dans le cadre de la théorie relationnelle, l’en-tête de de la variable relationnelle PROPOSER pourrait comporter un attribut du type

RELATION VENDEUR_FORFAIT_TRADUCTION {IdVendeur, IdForfait, IdLangue, Libelle, Description}

D'où la structure de la variable relationnelle :

Code D :

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

1
2
PROPOSER {IdVendeur, IdForfait, PrixVendeur, RELATION VENDEUR_FORFAIT_TRADUCTION {IdVendeur, IdForfait, IdLangue, Libelle, Description}}

Voyez à ce sujet l’article traitant des RVA (Relation Valued Attributes).

Mais aujourd’hui, vous devrez plutôt utiliser la structure classique :

Code D :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
VENDEUR {IdVendeur, CodeVendeur, ...}
    KEY {IdVendeur} ;
FORFAIT {IdForfait, Prix, ...}
    KEY {IdForfait} ;
LANGUE {IdLangue, LibelleLangue, ...}
    KEY {IdLangue} ;
PROPOSER {IdVendeur, IdForfait, PrixVendeur}
    KEY {IdVendeur, IdForfait}
    FOREIGN KEY {IdVendeur} REFERENCES VENDEUR
    FOREIGN KEY {IdForfait} REFERENCES FORFAIT ;
VENDEUR_FORFAIT_TRADUCTION {IdVendeur, IdForfait, IdLangue, Libelle, Description}
    KEY {IdVendeur, IdForfait, IdLangue}
    FOREIGN KEY {IdVendeur, IdForfait} REFERENCES PROPOSER ;
    FOREIGN KEY {IdLangue} REFERENCES LANGUE ;

La représentation graphique correspondante est la suivante :



D’où le MCD obtenu par rétro-conception (notation Entité/Relation de PowerAMC) :



Je doute que vous puissiez produire un MCD équivalent avec la notation Merise, sauf à transformer l’association-type PROPOSER en entité-type et à utiliser l’identification relative :



N.B. L’en-tête de l’entité-type VENDEUR comporte un attribut CodeVendeur : j’ai supposé qu’il s’agissait d’un attribut alternatif.