Bonjour apprenant16,
A propos des cardinalités des associations :

Envoyé par
apprenant16
La relation entre la table Consultation et Consultation_Payante est de type 1 à 1 ou bien 1 à plusieurs ?

La relation entre les tables Consultation et Consultation_Payante est de type 1 à 1, c’est bien ce que confirme le bouton « One-to-One » qui est activé.
C’est bien ce que veut exprimer dans mon diagramme précédent la représentation graphique (notation « patte-d’oie ») :
[CONSULTATION]—||—————————O|—[CONSULTATION_PAYANTE]
En notation UML cela donnerait :
[CONSULTATION]—1—————————0..1—[CONSULTATION_PAYANTE]
En passant : les notations patte-d’oie et UML permettent de distinguer une bijection d’une injection, mais ça n’est pas le cas de la notation ACCESS que je n’utilise donc pas (de même, la notation ACCESS ne permet pas de distinguer une surjection d’une autre application).
Sémantiquement parlant, une consultation payante est une consultation (notez l’emploi du verbe être). Si la relation était de type 1 à plusieurs, il faudrait remplacer « être » par « avoir », ce qui serait ici une erreur sur tous les plans...
Techniquement parlant, les données qui sont communes aux consultations payantes et aux consultations gratuites sont regroupées dans la table CONSULTATION, tandis que les données propres aux consultations payantes sont isolées dans la table CONSULTATION_PAYANTE. Si les consultations gratuites étaient dotées elles aussi de données en propre, alors il faudrait mettre en en oeuvre une table CONSULTATION_GRATUITE. On entre alors dans le domaine de la généralisation/spécialisation.
Au sujet de l’attribut FactureId :

Envoyé par
apprenant16
Dans les tables Consutation_Payante et Traitement_Payant, est-ce qu'il faut créer manuellement les attributs FactureId ou bien il vont découler de la relation automatiquement ?
L’attribut FactureId est automatiquement généré par MySQL Workbench dès qu’on établit la relation entre les tables, c’est-à-dire quand on clique sur CONSULTATION_PAYANTE puis sur FACTURE (même principe évidemment avec TRAITEMENT_PAYANT). Il faudra ensuite décocher « Identifying Relationship ».
Au sujet des interventions :

Envoyé par
apprenant16
Et la table Intervention, sa place est-elle bonne dans le schéma ci-après :

Oui, la table Intervention, est bien à sa place, c’est une conséquence de vos règles de gestion :

Envoyé par
apprenant16
R3a : un traitement entraîne une ou plusieurs interventions
R3b : une intervention est entraînée par un seul traitement
Partager