Salve !
Avant de traiter du COMMENT produire les clés candidates d’une table issue de la portée d’une ou plusieurs CIF, je voudrais ici traiter du QUOI.
Envoyé par
Paprick
la double CIF me pose un problème d'interprétation visuelle : en effet, ça laisse clairement penser que les clés étrangères des deux classes d'entités ciblées doivent être exclues de la clé primaire de la table d'association...
J’en reviens à cette double CIF présentée dans la figure 3 du post #53. Reprenons les CIF parties prenantes dans cette affaire :
CIF1 = {COURSE, JOCKEY} → {CHEVAL}
CIF2 = {COURSE, CHEVAL} → {JOCKEY}
En l’absence de toute CIF, la clé primaire SQL de la table PARTICIPER est le quadruplet :
K = {courseId, numero, chevalId, jockeyId}
Selon ton approche :
Du fait de CIF1, l’attribut chevalId ne doit pas être présent dans la clé K, et du fait de CIF2, l’attribut jockeyId ne doit pas non plus être présent dans K qui est réduite à :
K = {courseId, numero}
Si on tient compte aussi de CIF3 :
CIF3 = {COURSE, CHEVAL} → {NUMERO}
Alors l’attribut numero ne doit pas non plus être présent dans K qui, telle une peau de chagrin, est réduite au singleton :
K = {courseId}
Il est certain qu’au stade SQL la clé primaire K de la table PARTICIPER doit être débarrassée des attributs faisant que la règle d’irréductibilité des clés candidates serait violée. Néanmoins, point trop n’en faut ! 
Paprick, ce que je conteste c’est la méthode de réduction que tu utilises puisqu’elle conduit à ce que K soit réduite à tort à {courseId}.
De mon côté, je vois plutôt les choses ainsi :
1er exemple
Soit E l’ensemble des classes d’entités participant à l’identification de l’association PARTICIPER :
E = {COURSE, NUMERO, CHEVAL, JOCKEY}
Les identifiants respectifs des classes éléments de E sont les suivants :
I1 = courseId
I2 = numero
I3 = chevalId
I4 = jockeyId
Soit les sous-ensembles stricts suivants de E, répondant aux règles de gestion :
C1 = {COURSE, NUMERO}
C2 = {COURSE, CHEVAL}
C3 = {COURSE, JOCKEY}
Lesquels, toujours pour répondre aux règles de gestion, donnent lieu aux CIF :
CIF1 = C1 → {CHEVAL}
CIF2 = C1 → {JOCKEY}
CIF3 = C2 → {NUMERO}
CIF4 = C2 → {JOCKEY}
CIF5 = C3 → {CHEVAL}
CIF6 = C3 → {NUMERO}
Les sous-ensembles C1, C2, C3 donnent respectivement lieu au stade SQL aux clés candidates :
CK1 = {courseId, numero}
CK2 = {courseId, chevalId}
CK3 = {courseId, jockeyId}
Dans cette approche, les sous-ensembles C1, C2, C3 jouent un rôle décisif dans la détermination des clés candidates. Pour sa part, la clé primaire est choisie (par le jury 
) parmi ces candidates.
2e exemple
Ça n’est pas un problème d’ajouter une classe à connecter sur PARTICIPER. Ainsi, au démarrage d’une course, les chevaux occupent chacun une position par rapport à la corde, d’où CIF supplémentaires. Le MCD devient tellement chargé que c’en est démentiel, 
et je ne chercherai évidemment pas à le présenter. Mais de mon côté, pas de problème dans la détermination pdes clés candidates SQL de la table PARTICIPER :
L’ensemble E des classes d’entités participant à l’identification de l’association PARTICIPER devient le suivant :
E = {COURSE, NUMERO, CHEVAL, JOCKEY, CORDE}
Les identifiants respectifs des classes éléments de E sont les suivants :
I1 = courseId
I2 = numero
I3 = chevalId
I4 = jockeyId
I5 = cordeId
Soit les sous-ensembles stricts suivants de E, répondant aux règles de gestion :
C1 = {COURSE, NUMERO}
C2 = {COURSE, CHEVAL}
C3 = {COURSE, JOCKEY}
C4 = {COURSE, CORDE}
D’où les CIF
CIF1 = C1 → {CHEVAL}
CIF2 = C1 → {JOCKEY}
CIF3 = C2 → {NUMERO}
CIF4 = C2 → {JOCKEY}
CIF5 = C3 → {CHEVAL}
CIF6 = C3 → {NUMERO}
CIF7 = C1 → {CORDE}
CIF8 = C2 → {CORDE}
CIF9 = C3 → {CORDE}
CIF10 = C4 → {NUMERO}
CIF11 = C4 → {CHEVAL}
CIF12 = C4 → {JOCKEY}
Les sous-ensembles C1, C2, C3, C4 donnent respectivement lieu au stade SQL aux clés candidates
CK1 = {courseId, numero}
CK2 = {courseId, chevalId}
CK3 = {courseId, jockeyId}
CK4 = {courseId, cordeId}
Unicité complète / incomplète
Les CIF précédentes mettent en jeu 2 pattes d’association sur les 4 qui sont branchées sur PARTICIPER (unicité incomplète au sens Afcet).
Il n’y a pas de problème au cas où une CIF mettrait en jeu 3 pattes sur les 4 (unicité complète).
Le cas où la CIF ne mettrait en jeu qu’une seule patte ne présente pas d’intérêt, puisqu’on peut de préférence utiliser l’identification relative pour obtenir le bon résultat.
Une remarque
J’observe que dans sa version actuelle, la clé primaire SQL de la table PARTICIPER produite par Looping est exactement la même si par exemple on a seulement la CIF :
{COURSE, NUMERO} → {CHEVAL}
Ou bien la CIF :
{COURSE, NUMERO, JOCKEY} → {CHEVAL}
Je replonge dans la mer des CIF...
Cette écriture suivra la même option que pour PK et FK.
, et une petite ampoule s'est allumée dans ma tête la nuit dernière
!
)
Répondre avec citation
pas bien 
).
).
).
)
)... mais je pense que ça vaut la peine 
, reconnaissant par la même occasion la mauvaise génération de clés actuellement faite par Looping dans ce cas.
!
Partager