Discussion :

[djsbens]

Bonjour!

Voila j'ai une petite question. J'ai concu un MCD et dedans il y a une relation ternaire. Jusque la tout va bien. Mais je me suis rendu compte que ca produisait beaucoup de lignes. Alors je me suis demandé si je pouvais faire autrement?
J'ai donc pensé à transformer ma relation ternaire en agregat mais je voulais savoir ce que vous en pensiez étant donné que ca me rajoute une table.

Parlons peu parlons bien voici les mcds...

Celui avec la ternaire :

Celui avec l'agregat :

Je précise que la ternaire devient compliquée lorsque l'on a par ex :
un père qui inscrit son FILS1 aux sessions 1 et 2
" " " " " son FILS2 aux sessions 2 et 3
et que ce père règle avec 6 chèques et 1 règlement espece.

Merci pour vos futures réponses...

Benoît

[CinePhil]

Bonjour,
Votre MCD suppose que le règlement intervient en même temps que l'inscription puisque l'identifiant qui sera issu de la relation EST_INSCRIT sera le triplet (NUM_ELEVE, NUM_SESSION, NUM_REGLEMENT).

Or vous écrivez plus loin :

Je précise que la ternaire devient compliquée lorsque l'on a par ex :
un père qui inscrit son FILS1 aux sessions 1 et 2
" " " " " son FILS2 aux sessions 2 et 3
et que ce père règle avec 6 chèques et 1 règlement espece.

Et là ça devient impossible, sauf avec votre notion de GROUPE_REGLEMENT.

Je vois aussi dans votre MCD qu'une session semble ne durer qu'un jour, d'une heure de début à une heure de fin. Ceci suppose donc qu'il y a un règlement (ou un groupe de règlements) pour chaque session de chaque élève. C'est pas un peu lourd comme truc ?

C'est dans quel cadre, cette gestion d'élèves ?

[djsbens]

Merci de votre réponse.
C'est un développement que je réalise pour une association informatique qui propose des cours à des éleves.

Sinon pour revenir au mcd. Il est vrai que mon mcd impose le reglement lors de l'inscription d'un éleve pour une session donnée. Mais en fait, dans ma table reglement ou groupe_reglement (dépend du mcd) je vais utiliser l'identifiant num1 pour dire que l'eleve n'a pas encore réglé. En fait je veux pouvoir dire l'eleve E est interessé par la session S sans pour autant qu'il paye tt de suite.
Une fois qu'il est décidé il doit payer avec 1 ou plusieurs types de réglements.

Et oui c lourd c pourquoi je viens vers vous pour avoir une autre approche voir solution

En fait ca devient lourd quand on à une personne qui règle pour plusieurs éleves qui sont inscrit a plusieurs sessions!

Que faire?

[CinePhil]

Alors ma réflexion irait plutôt dans le sens de séparer l'inscription et le(s) règlement(s) en faisant de l'inscription une entité identifiée relativement à Elève et Session.

Règles de gestion :
1) Une inscription concerne un seul élève pour une seule session ; un élève peut être inscrit à plusieurs sessions et une session peut concerner plusieurs élèves.
2) Une inscription peut faire l'objet de plusieurs règlements et un règlement peut payer plusieurs sessions.

MCD :
1)
Elève -0,n----Effectuer----(1,1)- Inscription
Session -0,n-----|

2)
Inscription -0,n----Payer----1,n- Règlement

Il découlera bien sûr de la seconde relation une table associative.

[djsbens]

Si je suis ce que tu me dis j'arrive à ca :



Mais ne serait pas une manière déguisé de faire un agrégat...?
Créer une entité à partir de deux associations relatives ne revient-il pas à créer une association porteuses de données entre eleve et sessions ?

Dans ce cas payer va se transformer comment coté mdl?
NUM_ELEVE,NUM_SESSION,NUM_REGLEMENT... ca revient a une ternaire non?
Je comprend plus!

[djsbens]

Bon en cherchant un peu sur le site j'ai trouvé ca :
http://merise.developpez.com/faq/?pa...CD_Identifiant

Maintenant je ne comprends pas son implementation . Comment cette particularité sera modelisé en mld? Dois je mettre un identifiant a inscription ? Quel est le mieux a faire pour eviter la redondance et avoir la meilleur implementation possible dans la bdd?

Merci

[CinePhil]

Dans ce cas payer va se transformer comment coté mdl?
NUM_ELEVE,NUM_SESSION,NUM_REGLEMENT... ca revient a une ternaire non?

Oui effectivement ça revient à une ternaire, sauf si on considère que INSCRIPTION est une entité avec son identifiant propre (NUM_INSCRIPTION) auquel cas on abandonne l'identification relative et on prévoira une contrainte d'unicité sur le couple (NUM_ELEVE, NUM_SESSION).

Alors la table correspondant à la relation PAYER ne reçoit comme identifiant que deux colonnes (NUM_INSCRIPTION, NUM_REGLEMENT) et non pas trois avec l'identification relative.

J'en profite pour dire qu'un identifiant sera de préférence invariant, anonyme, inconnu de l'utilisateur, établi automatiquement par le SGBD par un système d'auto-incrémentation et de type entier.

[djsbens]

Ok c gentil de me répondre!
Bon je comprends bien alors c cool

Dernières questions :

Est-il correcte d'implementer un numéro inscription si l'on veut être le plus proche possible de Merise? (d'un point de vue scolaire en fait, ce que l'on apprend en cours ...)

Comment implémenter une contrainte d'unicité sur le coupe Eleve-Session? Je ne vois que l'utilisation d'un trigger lors de l'ajout modification d'un Réglement. Est ce vraiment ca?

[CinePhil]

Est-il correcte d'implementer un numéro inscription si l'on veut être le plus proche possible de Merise? (d'un point de vue scolaire en fait, ce que l'on apprend en cours ...)

Implémenter un numéro d'inscription en tant qu'identifiant de cette inscription revient à faire de INSCRIPTION une entité du MCD.
Une entité est un groupe de données sémantiquement cohérent et indépendant pouvant faire l'objet d'une gestion séparée (Ce n'est sans doute pas une définition "officielle" mais c'est celle qui me vient à l'idée dans l'instant).

Si on se contentait de savoir que l'élève 12 est inscrit à la session 24, une relation INSCRIRE suffirait entre les deux entités ELEVE et SESSION.

Mais comme on gère les paiements de ces inscriptions et qu'à la limite le paiement pourrait être totalement indépendant de l'élève (une prise en charge par le Pôle Emploi peut-être ?) et qu'un paiement peut concerner plusieurs sessions, INSCRIPTION ressemble à mon avis davantage à une entité indépendante qu'à une relation, même si ses attributs essentiels sont l'identifiant de l'élève et l'identifiant de la session.

Comment implémenter une contrainte d'unicité sur le coupe Eleve-Session? Je ne vois que l'utilisation d'un trigger lors de l'ajout modification d'un Réglement. Est ce vraiment ca?

Un index de type UNIQUE devrait suffire. Après bien sûr il faut que l'appli gère le message d'erreur retourné par le SGBD.

[djsbens]

Merci pour vos réponses! Ca m'éclairci bien
J'opte pour un numero inscription ca sera bien plus simple a gérer. Et pour l'index je ne savais pas trop à quoi ca correspondait.
Merci de m'avoir appris et de m'avoir aider.

Continuez comme ca!

Benoît