Discussion :

[gct70]

Bonjour,

J'ai un devoir à rendre et j'ai besoin d'aide pour savoir si ce que j'ai fait est juste ou pas.

Voici l'énoncé du sujet :

Nous sommes une société gérant toutes les formalités d'abonnement à des revues pour des établissements (lycées, collèges, bibliothèques...)
Le principe est le suivant : l'établissement contacte la société en lui indiquant les différents abonnements qu'elle souhaite et celle-ci s'occupe des formalités envers les éditeurs (bons de commande, suivi des réabonnements...). L'établissement n'a alors plus qu'à régler la facture annuelle de la société.
Une revue est caractérisée par son titre, sa périodicité, son prix au numéro, son tarif d'abonnement annuel et l'éventuel pourcentage de rabais qu'elle accorde pour la souscription de plusieurs abonnements par le même établissement. Une revue est éditée par un seul éditeur.
Un éditeur est caractérisé par un nom, une adresse, un téléphone, un fax et une adresse de messagerie électronique. Il peut éditer plusieurs revues.
Un établissement possède un nom, une adresse, un téléphone ainsi que le nom du contact habituel de la société. Un établissement s'abonne à un certain nombre de revues. Pour disposer de plusieurs exemplaires de revues très utilisées par les élèves, les établissements peuvent souscrire à plusieurs abonnements pour une même revue (il faut savoir combien).

Réaliser le MCD

Bon pour la propriété rabais mise dans la relation abonner je ne suis pas sure que ce soit la bonne place. Au début je l'avais mise en tant que propriété dans l'entité ETABLISSSEMENT. Qu'en pensez-vous ?

Merci à ceux/celles qui voudront bien me répondre

[fsmrel]

Bonsoir gct70,

Une revue est caractérisée par son titre, sa périodicité, son prix au numéro, son tarif d'abonnement annuel et l'éventuel pourcentage de rabais qu'elle accorde pour la souscription de plusieurs abonnements par le même établissement.

Selon cette règle, le rabais ne dépend pas de l’établissement, sinon ça serait à la tête du client. Ce rabais doit donc être une propriété de l’entité-type REVUE. Vous pouvez faire figurer dans l'association-type ABONNER le rabais consenti à un établissement, mais il s’agit alors d’un montant résultant d’une règle de calcul qui reste à définir, c'est-à-dire dont les paramètres, outre le rabais mentionné dans l’entité-type REVUE (nombre d’abonnements en cours, âge du capitaine, vitesse du vent, etc.) devraient être pris en compte dans le MCD.

[gct70]

Bonjour fsmrel,

Merci pour ta réponse, je vais modifier en conséquence. Sinon pour le reste est-ce juste ?

[fsmrel]

Bonjour,

je vais modifier en conséquence.

Il faudrait présenter le MCD aménagé.

les établissements peuvent souscrire à plusieurs abonnements pour une même revue (il faut savoir combien).

Le nombre d’abonnements souscrits par un établissement à une revue doit figurer au bon endroit. En relation avec ce que je viens d’écrire, avez-vous corrigé le tir ?
Par ailleurs, on ne sait pas à quelle date un abonnement a été souscrit.


L’énoncé du sujet évoque les réabonnements et le suivi des abonnements : il faudrait être à même de distinguer les abonnements en cours et les abonnements terminés (notion d’historique). Pour un abonnement en cours, il faudrait connaître l’état de la commande (déclenchée, annulée, satisfaite, ...) Bref corréler les concepts d’abonnement et de commande.

L’énoncé du sujet évoque vaguement la notion de facture. A vous de voir, si vous voulez vous lancer dans la mise en œuvre d’une entité-type Facture.

[gct70]

voila j'ai fait quelques modifications suivant vos recommandations. Sont-elles justes ?
Je ne vois pas comment corréler les concepts d’abonnement et de commande. Pouvez-vous m'aiguiller un peu plus ?

[gct70]

j'ai imaginé une autre solution. Qu'en pensez-vous ?

[fsmrel]

voila j'ai fait quelques modifications suivant vos recommandations. Sont-elles justes ?

La mise en œuvre de l’entité-type DATE permet de prendre en compte l’historique des abonnements. L’attribut Date_Abonnement doit disparaître de l’entité-type ETABLISSEMENT puisque désormais le lien avec l’entité-type DATE permet de connaître chaque date d’abonnement d’un établissement à une revue.

Par ailleurs, comme un jour donné un établissement peut souscrire plusieurs abonnements à la même revue, le nombre correspondant doit figurer comme attribut porté par l’association-type ABONNER. En conséquence, l'attribut Nb_Abonnement doit migrer de l'entité-type ETABLISSEMENT vers l’association-type ABONNER pour que la finesse de la maille soit la bonne.

[fsmrel]

Je ne vois pas comment corréler les concepts d’abonnement et de commande.

Va pour l’entité-type ABONNEMENT qui peut servir pour la commande de revues. Toutefois, la cardinalité portée par la patte connectant ABONNEMENT et ABONNER est 0,N : ça ne va pas. En effet, la cardinalité minimale 0 signifie qu’un abonnement ne fait pas nécessairement référence à un établissement, ce qui ne convient pas. Par ailleurs, la cardinalité maximale N signifie qu’un abonnement peut être partagé par plusieurs établissements : un seul d'entre eux suffit.

De même, un abonnement concerne une seule revue, donc la cardinalité maximale N portée par la patte connectant ABONNEMENT et REVUE ne convient pas.

Selon les cardinalités portées par les pattes de l’association-type FACTURER, un abonnement peut faire l’objet de plusieurs factures, pourquoi pas, c’est à voir avec le service Facturation. De même, une facture peut regrouper plusieurs abonnements, pourquoi pas là aussi. Mais alors attention : chaque ligne de facture (chaque instance de l’association-type FACTURER) doit faire mention de la revue concernée, de la quantité (nb abonnements), du prix au numéro correspondant (au fil des jours, le prix porté par l’entité-type REVUE peut évoluer et ne plus correspondre à ce qu’il y a sur la facture). Et surtout, il faut veiller à ne pas adresser la facture à des établissements différents (ce que votre MCD n’interdit pas). Revoyez peut-être les cardinalités maximales à la baisse...

[gct70]

Voici les modifications apportées

[fsmrel]

Examinons votre MCD :




L’attribut RefAbonnement qui figure dans l’entité-type ABONNEMENT est inutile. En effet, l’ancienne association-type ABONNER a été graphiquement représentée sous forme d’entité-type, mais ontologiquement, rien ne change. Autrement dit, l’identifiant d’ABONNEMENT est constitué à partir des identifiants des entités-types ETABLISSEMENT et REVUE, comme c’est le cas pour les associations-types. En conséquence, pour avoir l’équivalent, il suffit de rendre identifiantes les associations-types Abonner et Commander ci-dessus. Avec Open ModelSphere, il suffit de cliquer sur l’icône de création de clé et de l’emmener sous les cardinalités 1,1 portées par les pattes connectant ABONNEMENT et Abonner d’une part, ABONNEMENT et Commander d’autre part.

On peut supposer qu’un abonnement ait le statut « commande non confirmée par l’éditeur », auquel cas on peut préférer la cardinalité 0,1 à la cardinalité 1,1 portée par la patte connectant ABONNEMENT et Facturer. Toutefois, vous avez la liberté de conserver 1,1 car la finalité d’un abonnement est quand même quelque part de faire l’objet d’une facture à adresser à l’établissement concerné.

Prudemment, vous avez choisi de n’avoir qu’une facture par abonnement. Ainsi, il n’y aura pas de problème concernant les incohérences facture / établissement.

Si l’audace vous titille, vous pouvez tenter la modélisation d’une facture portant sur plusieurs abonnements pour un établissement donné. Dans ce cas, vous définissez une ligne de facture en miroir d’un abonnement. Sachant que les prix et les rabais peuvent évoluer dans le temps, il est nécessaire de mémoriser ces données au niveau de la ligne de facture (attributs LfMontant et LfRabais ci-dessous), à moins de s’embarquer dans l’historisation des prix, mais on n’ira pas jusque là. La ligne de facture n’étant qu’une propriété (multivaluée) de la facture, on utilise l’identification relative, une fois de plus en rendant identifiante l’association-type Composer (icône de création de clé, à emmener sous la cardinalité 1,1 portée par la patte connectant LigneFacture et Composer).

Mais cette fois-ci, rien n’empêche de facturer à un établissement des abonnements qui ne le concernent pas. Pour éviter cela, il faut mettre en œuvre une contrainte dite de simultanéité entre les associations-types Souscrire et Adresser (cf. ci-dessous), dont l’objet est d’établir la contrainte suivante : « L’établissement à qui on facture des abonnements doit être celui qui les a souscrits ».

Si le passage au niveau logique vous intéresse, on pourra voir comment traduire cette contrainte. En ce sens, j’ai anticipé en rendant identifiante l’association-type Adresser, mais il n’y a là aucune obligation de votre part d’en faire autant.

[gct70]

Bonjour fsmrel,

Merci beaucoup pour toutes ces précisions. Cependant comme je suis en 1ère année de BTS IG par correspondance et que je n'ai pas encore vu l'identification des associations je pense que je vais en rester là pour cet exercice.
Encore une fois merci pour l'aide apportée

[fsmrel]

D'accord, mais n'hésitez pas si vous avez d'autres problèmes.

Bonne route