Discussion :

[MeryemDahan]

Bonjour.

J'ai réalisé un MCD et j'ai une relation d'heritage à representer en associations. Voici mon mcd. Pourriez me donner votre avis ?
Est-il correct ?

Merci d'avance !

[fsmrel]

Bonsoir MeryemDahan,

J'ai une relation d'heritage à representer en associations.

Quelles entités-types sont concernées ?

[MeryemDahan]

Bonsoir MeryemDahan,




Quelles entités-types sont concernées ?

Ce n est pas clair
L entite adherent et beneficiaire herite du l entite client.
Un client doit etre adherent pour impliquer vente . Et beneficiaire doit etre assure par un adherent pour qu il soit client et implique une vente.

[fsmrel]

Une relation d’héritage, ou plutôt de spécialisation/généralisation, se représente de la façon suivante :

Un client est un bénéficiaire ou est un adhérent : on utilise exclusivement le verbe être. Dans votre MCD, c’est en fait le verbe avoir qui se présente, même si vous l’avez déguisé en « peut être », en effet, la patte d’association connectant CLIENT et PEUT ÊTRE est porteuse d’une cardinalité maximale N alors qu’elle devrait être 1.

En fait, pour établir cette relation d’héritage, vous pouvez suivre le mode d’emploi fourni par l’éditeur.

[MeryemDahan]

Une relation d’héritage, ou plutôt de spécialisation/généralisation, se représente de la façon suivante :

Un client est un bénéficiaire ou est un adhérent : on utilise exclusivement le verbe être. Dans votre MCD, c’est en fait le verbe avoir qui se présente, même si vous l’avez déguisé en « peut être », en effet, la patte d’association connectant CLIENT et PEUT ÊTRE est porteuse d’une cardinalité maximale N alors qu’elle devrait être 1.

En fait, pour établir cette relation d’héritage, vous pouvez suivre le mode d’emploi fourni par l’éditeur.

Oui c'est ce que je veux representer .
je sais qu il y a un symbole pour representer l heritage mais je dois le reprensenter en associations ( .
pour la cardinalité maximale c est parce que on pet y a voir un ou plusieurs adherent .
et aucun ou plusieurs beneficaires.

[fsmrel]

Si l’on fait une lecture littérale de votre MCD :

Du fait de la cardinalité 1,N, un client est en relation avec au moins un adhérent : le nom de votre relation est à compléter : « Peut Être » doit devenir « Est en relation avec ».

Sinon, si un client est vraiment un adhérent ou un bénéficiaire, la cardinalité 1,N est un non-sens, elle est à remplacer par 0,1.

[MeryemDahan]

Si l’on fait une lecture littérale de votre MCD :

Du fait de la cardinalité 1,N, un client est en relation avec au moins un adhérent : le nom de votre relation est à compléter : « Peut Être » doit devenir « Est en relation avec ».

Sinon, si un client est vraiment un adhérent ou un bénéficiaire, la cardinalité 1,N est un non-sens, elle est à remplacer par 0,1.

J ai remplace la cardinalite entre client et adherent par (1,1) - (1,1) et remplace la cardinalite entre Client et Beneficiare par (0,1) - (1,1)

puisque pour etre client(pour impliquer vente) on doit etre adherent mais pour beneficiare on peut y n avoir aucun beneficiaire non ?

[fsmrel]

Vous avez établi une bijection entre CLIENT et ADHERENT, si donc Fernand est client il est nécessairement adhérent : d’accord.

Prenons maintenant le cas de Raoul qui est bénéficiaire : d’après votre MCD, il est aussi client, mais du fait de la bijection, il est aussi adhérent.

L’association ASSURE permet de mettre en relation Raoul et Fernand : Raoul est assuré par Fernand (et peut l’être aussi par Raoul, ce qui veut dire qu’il faudra en toute logique prévoir une contrainte pour empêcher cette réflexivité).

Attention, les bijections sont des pièges en SQL : elles rendent inefficaces les contraintes d’intégrité référentielle.

Aussi, et toujours du fait de la bijection, est-il préférable que des deux entités-types CLIENT et ADHERENT on n’en fasse qu’une.

[MeryemDahan]

Vous avez établi une bijection entre CLIENT et ADHERENT, si donc Fernand est client il est nécessairement adhérent : d’accord.

Prenons maintenant le cas de Raoul qui est bénéficiaire : d’après votre MCD, il est aussi client, mais du fait de la bijection, il est aussi adhérent.

L’association ASSURE permet de mettre en relation Raoul et Fernand : Raoul est assuré par Fernand (et peut l’être aussi par Raoul, ce qui veut dire qu’il faudra en toute logique prévoir une contrainte pour empêcher cette réflexivité).

Attention, les bijections sont des pièges en SQL : elles rendent inefficaces les contraintes d’intégrité référentielle.

Aussi, et toujours du fait de la bijection, est-il préférable que des deux entités-types CLIENT et ADHERENT on n’en fasse qu’une.

Donc je vais avoir la cardinalité (0,1) pour Client et Adherent , Client et Beneficiaire.

ça serait correct selon les conditions que j ai ?

[fsmrel]

Oui c'est correct. Et cette fois-ci vous n'aurez aucun motif pour ne pas utiliser l'héritage proposé par PowerAMC...

[MeryemDahan]

Oui c'est correct. Et cette fois-ci vous n'aurez aucun motif pour ne pas utiliser l'héritage proposé par PowerAMC...

Pardon j ai pas bien compris . Est ce que je dois encore ajouter le symbole d heritage entre ces entites sur ce mcd ?!

[fsmrel]

Est ce que je dois encore ajouter le symbole d heritage entre ces entites sur ce mcd ?!

Oui, puisqu'il correspond exactement au contexte.

[MeryemDahan]

Oui, puisu'il correspond exactement au contexte.

Oui mais c pas clair les associations entre entites?
On va y avoir une cle primaire d une entite represente cle etrangere dans l autre nn ?

[fsmrel]

Bonjour MeryemDahan,

mais c pas clair les associations entre entites?

Reprenons cette partie de votre MCD :




Vous avez nommé « PEUT ETRE » les associations entre CLIENT et ADHERENT d’une part et CLIENT et BENEFICIAIRE d’autre part. En réalité, au plan sémantique le verbe être est ici trompeur, un client, identifié par {ClientId}, peut seulement être en relation avec un adhérent, identifié par {NumDoti}, et par construction cet adhérent n’est pas un client. De même, le client identifié par {ClientId} peut seulement être en relation avec un bénéficiaire, identifié par {NumFinancier}, et par construction ce bénéficiaire n’est pas un client.


Qui plus est, vous ne serez pas déçue lors du passage au niveau SQL, car le MLD proposé par PowerAMC sera le suivant :




Et bien entendu, je vous laisse le soin d’expliquer pourquoi PowerAMC a produit — à juste titre — un tel MLD.



Passons maintenant au MCD avec héritage :




Un client peut être cette fois-ci un adhérent ou un bénéficiaire (voire les deux, merci de préciser ce point).
Un adhérent est un client.
Un bénéficiaire est un client.
Un bénéficiaire est assuré par un adhérent.


Par définition de l’héritage, l’entité-type (plus précisément sous-type) ADHERENT a pour identifiant {ClientId}, mais on définit un identifiant alternatif {NumDoti} (symbolisé par le mickey <ai>), c'est-à-dire que, si un client est un adhérent, il est aussi doté d’un NumDoti qui est nécessairement unique.

Par définition de l’héritage, l’entité-type (plus précisément sous-type) BENEFICIAIRE a pour identifiant {ClientId}, mais on définit un identifiant alternatif {NumFinancier} (symbolisé par le mickey <ai>), c'est-à-dire que, si un client est un bénéficiaire, il est aussi doté d’un NumFinancier qui est nécessairement unique.

MLD produit par PowerAMC :





{ClientId} est clé primaire de la table CLIENT, mais aussi des tables ADHERENT et BENEFICIAIRE.

La table ADHERENT est dotée d’une clé supplémentaire {NumDoti}.

La table BENEFICIAIRE est dotée d’une clé supplémentaire {NumFinancier}.

Un client bénéficiaire fait référence à (est assuré par) un seul client adhérent. Un client adhérent peut assurer plusieurs clients bénéficiaires.


Cette fois-ci ça tient la route.

[MeryemDahan]

Bonjour MeryemDahan,


Un client peut être cette fois-ci un adhérent ou un bénéficiaire (voire les deux, merci de préciser ce point).

Un client ne peut pas etre adherent et beneficiaire en méme temps
soit adahrent ou beneficaire
j ai appliquer l heritage Maientenant comme ça
mais j ai des avertissement s en bas .

et voila le MLD genere
l heritage n est pas represente :s

[fsmrel]

Bonsoir MeryemDahan,

Un client ne peut pas etre adherent et beneficiaire en même temps

Cliquez sur la demi-lune pour accéder à la fenêtre « Propriétés de l’héritage », puis passez par l’onglet « Général » et cochez « Enfants mutuellement exclusifs » (ainsi que « Complet » s’il n’y a pas d’autres types de clients) :

l’heritage n'est pas representé :s

Il l’est, mais pas de la façon qui vous convient... Cliquez sur la demi-lune pour accéder à la fenêtre « Propriétés de l’héritage », puis passez par l’onglet « Génération ». Ça devrait aller mieux en cochant les bonnes cases et en n’héritant que des attributs primaires :