Discussion :

[Wisline]

Bonjour,
J'espère avoir vos suggestions à propos d'un souci d'association ternaire
je modélise une application de gestion des formations professionnelles dans une banque
Je souhaite avoir pour chaque formation son prestataire et sa facture
donc j'ai pensé à faire une association ternaire entre l'entité formation, prestataire et l'entité facture:
R1- Une formation peut être animée par un et un seul prestataire
R2- Pour chaque formation correspond une facture
R3- Un prestataire peut animer plusieurs formations(J'ai pas encore ajouté la notion d'historisation)
R4 -Donc chaque prestataires aura des factures différentes selon la formation
R5- Une facture correspond à une formation
R6- Une facture correspond à un prestataire
puisque la facture va dépendre des deux : la formation et le prestataire comme illustré ci-dessous:

que pensez vous ?
Merci de me répondre

[fsmrel]

Bonjour Wisline,


Reprenons votre MCD. L’intention y est, mais PowerAMC a ses vapeurs quand vous le lui proposez...

Ainsi, quand on lui soumet le MCD :



Voici le MLD qu’il propose en échange :




On n'y est pas quant au respect des règles de gestion. En conséquence, il faut donc modifier manuellement ce MLD pour que les clés candidates soient les bonnes :




En SQL :


TABLE FOR_FAC_PRE

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
CREATE TABLE FOR_FAC_PRE 
(
   FormationId          INT          NOT NULL,
   FactureId            INT          NOT NULL,
   PrestataireId         INT          NOT NULL,
   CONSTRAINT FOR_FAC_PRE_PK PRIMARY KEY (FormationId),
   CONSTRAINT FOR_FAC_PRE_AK UNIQUE (FactureId),
   CONSTRAINT FOR_FAC_PRE_FORMATION_FK FOREIGN KEY (FormationId)
      REFERENCES FORMATION (FormationId),
   CONSTRAINT FOR_FAC_PRE_FACTURE_FK FOREIGN KEY (FactureId)
      REFERENCES FACTURE (FactureId),
   CONSTRAINT FOR_FAC_PRE_PRESTATAIRE_FK FOREIGN KEY (PrestataireId)
      REFERENCES PRESTATAIRE
) ;

[Wisline]

Bonjour fsmrel,
Merci pour votre réponse
mon encadrant a refusé cette modélisation puisque dans une relation ternaire en merise on ne peut avoir des pattes avec des cardinalités maximales en 1
donc j'ai pensé que puisque chaque formation a une et une seule facture
et puisque ce département n'est pas censé gérer les bons de commandes car le gestionnaire de formations
se limite à valider une formation c'est à dire permettre le paiement du prestataire
j'ai pensé à insérer le montant et le montant facturé dans l'entité formation avec un attribut nommé status c-à-d validé ou non
quel est votre avis à propos de ce changement ?

[fsmrel]

Bonjour Wisline,

mon encadrant a refusé cette modélisation puisque dans une relation ternaire en merise on ne peut avoir des pattes avec des cardinalités maximales en 1.

Une relation ternaire peut avoir des pattes à cardinalité maximum à 1. PowerAMC n’a pas rouspété quand nous avons procédé ainsi.

Il faut relire les pères de Merise, par exemple Yves Tabourier qui parle seulement du « Manque d’intérêt des cardinalités maximum à 1 pour les relations à plus de deux pattes » (voyez à la page 88 de son ouvrage de référence, De l’autre côté de Merise, aux Éditions d’Organisation, 1988).

Cela dit, il faut éviter ce genre de représentation quand c’est possible, tout en sachant que la validité de la base de données en production sera la conséquence logique de la table FOR_FAC_PRE, la seule acceptable :

j'ai pensé à insérer le montant et le montant facturé dans l'entité formation avec un attribut nommé status c-à-d validé ou non
quel est votre avis à propos de ce changement ?

Le problème est que vous injectez une redondance, or la redondance est un ennemi pervers... En production, vous risquez d’avoir des différences entre le montant figurant officiellement dans la facture et celui que vous aurez « recopié » (j'ai effectué des audits de bases de données en production où j'ai retrouvé ce genre d’anomalie...)

Sortons maintenant l’artillerie lourde, en nous appuyant sur la théorie des dépendances.

Selon le MLD ci-dessus, on dispose d’une relvar FOR_FAC_PRE d’en-tête :

FOR_FAC_PRE {FormationId, FactureId, PrestataireId} ;

A cette relvar est associé l’ensemble F de dépendances fonctionnelles (entre autres) suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
F = 
{
     FormationId -> FactureId,
     FormationId -> PrestataireId, 
     FactureId -> FormationId, 
     FactureId -> PrestataireId
}.

Par application du théorème de Heath, la relvar FOR_FAC_PRE peut être décomposée sans perte en deux relvars :

FOR_PRE {FormationId, PrestataireId} ;

FOR_FAC {FormationId, FactureId}.

Telles que leur jointure naturelle soit égale à FOR_FAC_PRE.

Par rétro-conception on aboutit à :




Mais attention, PowerAMC produira un MLD avec un cycle (conséquence d'une bijection rendant inefficace les contraintes d'intégrité référentielle) qu’il faudra supprimer manuellement. Quoi qu’il en soit, si le dernier MCD que je viens de proposer peut satisfaire un concepteur, et bien que le MLD qui en est inféré au niveau logique soit valide, il n’en demeure pas moins que c’est la table FOR_FAC_PRE qu’il faudra mettre en œuvre.

A l'occasion, n’oubliez pas de voter si une réponse vous a apporté quelque chose...

[alassanediakite]

Bonjour à vous
François, permettez moi cette question...

...Quoi qu’il en soit, si le dernier MCD que je viens de proposer peut satisfaire un concepteur, et bien que le MLD qui en est inféré au niveau logique soit valide, il n’en demeure pas moins que c’est la table FOR_FAC_PRE qu’il faudra mettre en œuvre.

Le premier modèle n'est-il pas compliqué quant à la mise en œuvre de la contrainte factureid->prestateurid et factureid->formationid? Car pour créer une facture il faut d'abord créer une ligne dans FOR_FAC_PRE hors on voie que c'est lui qui dépend de facture.
@+

[fsmrel]

Bonsoir Alassane,

on voie que c'est lui qui dépend de facture

Qui donc dépend de la facture ?

Cela dit, dans le modèle de Wisline, la formation, le prestataire et la facture devraient préexister au moment de la création d'un triplet dans FOR_FAC_PRE, je ne vois donc pas ce qui vous soucie. Pourriez-vous en dire plus , dérouler le film avec un exemple concret, on a peut-être raté quelque chose...

[alassanediakite]

Bonjour
Je veux dire que pour assurer l'intégrité "une facture est lié à une et une seule formation" on ne peut créer une facture sans passer par un trigger qui créera alors la ligne correspondante dans FOR_FAC_PRE
@+

[fsmrel]

Alassane,


Vous êtes déjà dans le « comment » en SQL, alors qu'ici on est au niveau du « quoi ». Si ensuite j'utilise un SGBD orienté D, ça ne se fera pas à coups de triggers, mais vraisemblablement par affectation multiple (multiple assignment).

[alassanediakite]

Bonjour

Quoi qu’il en soit, si le dernier MCD que je viens de proposer peut satisfaire un concepteur, et bien que le MLD qui en est inféré au niveau logique soit valide, il n’en demeure pas moins que c’est la table FOR_FAC_PRE qu’il faudra mettre en œuvre.

Quels peuvent être les avantages à utiliser la table FOR_FAC_PRE, ou les inconvénients de l'autre solution?
Merci d'avance.

[fsmrel]

Ave Bugs,


Reprenons le cartoon ^^. En fait, si l’on part du MCD :





L’AGL utilisé par Wisline, à savoir PowerAMC, produit le MLD suivant, où l'on trouve deux fois la redoutable bijection entre FORMATION et FACTURE, laquelle prend en défaut l’intégrité référentielle, voyez l’exemple ici. Quoi qu’il en soit, le MLD produit par PowerAMC est pour le moins curieux, il double la mise : la bijection est présente deux fois et quant à la production des clés candidates, son moteur d’inférence donne des signes de faiblesse :




Et je ne vous raconte pas la chose surréaliste qu’il produit au niveau (paraît-il) MPD :




Il y a manifestement un certain ménage à faire, 3 flèches à virer, des attributs redondants à virer eux aussi, une clé candidate à rajouter à la main, et pour ne pas violer la 2NF, une décomposition de FORMATION en FORMATION (nettoyée) et FOR_FAC_PRE, tout ça pour retrouver quelque chose de sensé (et en 5NF tant qu'à faire), à savoir ce que j’avais proposé :




D’accord, j’ai viré la bijection, mais au moins les ingrédients nécessaires et finalement suffisants sont présents dans FOR_FAC_PRE.


Je ne sais pas trop quoi vous dire d'autre...

[Wisline]

Bnsoir fsmrel,
Merci pour vos clarifications
J'ai besoin de plus de clarifications à propos de certains points que vous avez cité:

Le problème est que vous injectez une redondance, or la redondance est un ennemi pervers

Je n'ai pas compris la redondance ça sera en terme de quoi ? si vous pouvez me clarifier ce point s'il vous plait

En production, vous risquez d’avoir des différences entre le montant figurant officiellement dans la facture et celui que vous aurez « recopié » (j'ai effectué des audits de bases de données en production où j'ai retrouvé ce genre d’anomalie...)

là aussi si j'ai bien compris(je doute ) qu'il y a un risque de saisir des montants erronés , alors que même si j'ai une table facture je peux faire la même chose sachant que les montants vont être entrées manuellement ?

Concernant le MLD
le premier MLD que vous avez proposé me paraît tout à fait logique et convainquant mais j'ai une question à propos de la clé primaire et la clé candidate:
Si on suivait le premier MLD correspondant à mon premier MCD ou j'avais une relation ternaire
est-ce qu'on peut mettre idFacture comme clé primaire
idFormation comme clé candidate
puisque les règles de gestion m'informent que:
idFacture-> idFormation
&
idFacture->idPrestataire
?

[alassanediakite]

...Je ne sais pas trop quoi vous dire d'autre...

Pas de souci. Vous avez tout dit. Grand merci de votre disponibilité.
Ce sont les cardinalités de l'association "FOR_FAC" qui m'avaient échappé. Pour ma part j'éviterais ces genres de cardinalités. Dans l'impossibilité j'utiliserais la clé primaire de FORMATION dans FACTURE comme clé primaire et clé étrangère à la fois.
@+

[fsmrel]

Bonjour Wisline,

Je n'ai pas compris la redondance ça sera en terme de quoi ?

Reprenons votre proposition :


En passant au stade opérationnel, vous aurez donc d’une part dans la base de données une table, appelons-la FACTURE, contenant l'intégralité les données de l’ensemble des factures, table mise à jour par le service concerné, et vous aurez d’autre part votre propre sous-système où l’on trouvera copie des montants des factures, sans référence à celles-ci du reste. Supposons que, pour une raison X ou Y, un utilisateur modifie le montant d’une de ces factures, puis parte tranquillement en vacances, la conscience en paix : expliquez-nous comment vous synchroniserez votre table FORMATION et la table FACTURE, pour assurer l’égalité des montants, donc la redondance.

Je rappelle que ce que je dis n’est pas utopique. Une grosse société d’assurance : mise en évidence de 30% d’incohérence dans la base de données CLIENTS pour redondance non respectée ou données orphelines, une grande banque, même chose...

Est-ce qu'on peut mettre idFacture comme clé primaire idFormation comme clé candidate

Aucun problème, permutez comme bon vous plaît, du moment que les contraintes d’unicité et d’irréductibilité (minimalité) des clés soient respectées.

[Wisline]

Bonjour Wisline,





Reprenons votre proposition :


En passant au stade opérationnel, vous aurez donc d’une part dans la base de données une table, appelons-la FACTURE, contenant l'intégralité les données de l’ensemble des factures, table mise à jour par le service concerné, et vous aurez d’autre part votre propre sous-système où l’on trouvera copie des montants des factures, sans référence à celles-ci du reste. Supposons que, pour une raison X ou Y, un utilisateur modifie le montant d’une de ces factures, puis parte tranquillement en vacances, la conscience en paix : expliquez-nous comment vous synchroniserez votre table FORMATION et la table FACTURE, pour assurer l’égalité des montants, donc la redondance.

Je rappelle que ce que je dis n’est pas utopique. Une grosse société d’assurance : mise en évidence de 30% d’incohérence dans la base de données CLIENTS pour redondance non respectée ou données orphelines, une grande banque, même chose...



Aucun problème, permutez comme bon vous plaît, du moment que les contraintes d’unicité et d’irréductibilité (minimalité) des clés soient respectées.

Merci beaucoup fsmrel j'ai bien saisi vos réponses
Merci infiniment