Discussion :

[apprenant16]

Bonjour, mon problème est relatif à comment matérialiser la relation entre la table Facture et les tables Consultation et Traitement en partant de ces règles de gestion :

1. une consultation est suivie par zéro ou une seul facture (Zéro pour les consultations gratuites parfois)
2. un traitement est suivi par zéro ou une seul facture (Zéro pour les consultations gratuites parfois)
3. une facture correspond soit à une consultation, soit à un traitement soit les deux en même temps

je vous remercie par avance pour votre aide

[fsmrel]

Bonjour apprenant16,


Je suis obligé de m'absenter, mais d'ici une paire d'heures je vous réponds.

A tout à l'heure

[apprenant16]

Bonjour fsmrel, merci de la réponse. C'est noté.

[fsmrel]

Bonjour apprenant16,


En principe une facture peut faire référence à plusieurs consultations et ou traitements, c’est plutôt la ligne de facture qui ferait référence à une consultation ou à un traitement, mais bon, restons-en à la règle qui veut qu’une facture ne fasse référence qu’à une consultation et/ou à un traitement.

Une idée est de ne mettre en relation avec la table FACTURE que les consultations et traitements payants (procédé de spécialisation), d’où la mise en oeuvre des deux tables CONSULTATION_PAYANTE et TRAITEMENT_PAYANT.

Pour éviter que deux consultations payantes fassent référence à la même facture (même principe pour les traitements payants), l’attribut factureId doit faire l’objet d’une clé alternative pour la table CONSULTATION_PAYANTE (même chose pour la table TRAITEMENT_PAYANT). Avec MySQL Workbench, ces clés alternatives passent par la déclaration d’un indes UNIQUE.

 

[apprenant16]

Bonjour fsmrel, très clair comme explication Merci

Questions :

1. sur les tables Consultations Payantes et Traitements Payants, il n'y a donc pas de Clès Primaires ?
2. s'agissant d'une consultation gratuite ou traitement gratuit, seule la table Consultation sera utilisée ?
3. pour les tables Consultations Payantes et Traitements Payants, est-ce que seuls les deux attributs ConsultationId et FactureID suffiront ?

[fsmrel]

Questions :

1. sur les tables Consultations Payantes et Traitements Payants, il n'y a donc pas de Clès Primaires ?
2. s'agissant d'une consultation gratuite ou traitement gratuit, seule la table Consultation sera utilisée ?
3. pour les tables Consultations Payantes et Traitements Payants, est-ce que seuls les deux attributs ConsultationId et FactureID suffiront ?

Concernant la 1re question : les clés primaires sont là ! Simplement elles ont viré au rouge car elles sont aussi clés étrangères (j’utilise MySQL Workbench V6.3 et il procède ainsi).

Concernant la 2e question : ici, seule la table CONSULTATION est porteuse des données concernant les consultations gratuites et seule la table TRAITEMENT est porteuse des données concernant les traitements gratuits.

Concernant la 3e question : si les consultations payantes font l’objet de données ne concernant pas les consultations gratuites, alors ces données feront l’objet d’attributs ad-hoc dans la table CONSULTATION_PAYANTE.
Si les traitements payants font l’objet de données ne concernant pas les traitements gratuits, alors ces données feront l’objet d’attributs ad-hoc dans la table TRAITEMENT_PAYANT.

Par ailleurs, si les consultations gratuites faisaient l’objet de données ne concernant pas les consultations payantes, alors ces données feraient l’objet d’attributs d’une table CONSULTATION_GRATUITE.
Si les traitements gratuits faisaient l’objet de données ne concernant pas les traitements payants, alors ces données feraient l’objet d’attributs d’une table TRAITEMENT_GRATUIT.



 

[apprenant16]

D'accord, je vais prendre en comptes toutes vos indications pour faire un modèle plus complet que je vais vous présenter. Merci

[apprenant16]

Bonjour,

1. La relation entre la table Consultation et Consultation_Payante est de type 1 à 1 ou bien 1 à plusieurs ? si oui, théoriquement cela signifie quoi ?
   
   
   
2. 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 ?
3. Et la table Intervention, sa place est-elle bonne dans le schéma ci-après :

Voici l'affichage pour ACCESS :

[fsmrel]

Bonjour apprenant16,


A propos des cardinalités des associations :

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 :

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 :

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 :

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

 

[apprenant16]

Bonsoir fsmrel, merci avec vos explications c'est plus clair.

Je vais mettre mon modèle à jour et présenter la nouvelle version.