CIF dépliées et compactées

Version imprimable

28/12/2020, 01h59
fsmrel

5 pièce(s) jointe(s)

CIF dépliées et compactées
Salve omnes,

A propos des CIF complètes, dépliées et compactées.

Prenons le cas d’une association ternaire, pour la quelle existe la dépendance fonctionnelle au sens Merise (voir l’ouvrage de référence de D. Nanci (RIP) et B. Espinasse Ingénierie des systèmes d'information : Merise deuxième génération (4e édition, 2001), au paragraphe "Contraintes intra–relation", page 114) :

E1 X E2 → E3

Cette dépendance fonctionnelle fait l’objet d’une CIF dépliée⁽¹⁾:

Pièce jointe 587499

Quant à la production du code SQL, je fais référence à ce qu’a écrit Paprick :

Citation:

Envoyé par Paprick

Looping se contente de retirer, dans la clé primaire de l'association, l'identifiant de la classe d'entités ciblée par la CIF.
A réfléchir donc pour les prochaines versions...:cfou:

Ainsi, avec Looping, l’association A donne lieu en SQL à la table A :

Code SQL (1)
```
CREATE TABLE A
(
   e1Id INT,
   e2Id INT,
   e3Id INT NOT NULL,
   CONSTRAINT A_PK PRIMARY KEY(e1Id, e2Id),
   CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
   CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
   CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
```
Code dans lequel la clé candidate (primaire en l’occurrence) est la paire {e1Id, e2Id} et non pas le triplet {e1Id, e2Id, e3Id}, donc tout va bien.

Supposons maintenant qu’il existe une dépendance fonctionnelle supplémentaire :

E2 X E3 → E1

Le MCD devient :

Pièce jointe 587500

Au stade SQL, tout va bien, la table A est enrichie d’une clé alternative {e2Id, e3Id} :

Code SQL (2)
```
CREATE TABLE A
(
  e1Id INT,
   e2Id INT,
   e3Id INT NOT NULL,
   CONSTRAINT A_PK PRIMARY KEY(e1Id, e2Id),
   CONSTRAINT A_AK UNIQUE(e2Id, e3Id),
   CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
   CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
   CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
```
So far, so good, en notant que la clé primaire reste ce qu’elle était, Looping ne s’est heureusement pas contenté « de retirer, dans la clé primaire de l'association, l'identifiant de la classe d'entités ciblée par la CIF », à la place de cela il a créé une clé alternative ouf ! ;)

Pour alléger le MCD, on peut se contenter d’une représentation compacte⁽²⁾, en fléchant la cible de la CIF (cf. l’ouvrage cité, Figure 7.25, page 118, ainsi que le document Afcet de 1990, où figure l’article d’Yves Tabourier, à voir pages 45 et suivantes, et en particulier la représentation des CIF, page 49). Avec Looping, pour reprendre la 1re dépendance fonctionnelle :

E1 X E2 → E3

Le MCD devient :

Pièce jointe 587501

Mais l’affaire se corse (chef-lieu Ajaccio) quand il s’agit de représenter la 2e dépendance fonctionnelle :

E2 X E3 → E1

En effet, le MCD suivant :

Pièce jointe 587502

donne lieu au code SQL :

Code SQL (3)
```
CREATE TABLE A(
   e2Id INT,
   e1Id INT NOT NULL,
   e3Id INT NOT NULL,
   CONSTRAINT A_PK PRIMARY KEY(e2Id),
   CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
   CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
   CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
```
Code qui diffère sensiblement du code SQL (2) ! 8O

Looping s’est contenté de retirer l’attribut e1Id dans la clé primaire {e1Id, e2Id} de la table (e1Id étant l'identifiant de la classe d'entités ciblée par la 2e CIF).

Cela dit, quelle que soit sa représentation, dépliée ou compacte, une CIF est une CIF, et le code SQL produit ne doit pas dépendre de sa représentation. A mon sens, dans tous les cas, seul le code SQL (2) est valide et justifié.

Autre observation :

Pour être complet, la 3e dépendance fonctionnelle

E1 X E3 → E2

est aussi exprimable au moyen d’une CIF :

Pièce jointe 587503

Et donne lieu au code SQL irréprochable :

Code SQL (4)
```
CREATE TABLE A
(
   e1Id INT,
   e2Id INT,
   e3Id INT NOT NULL,
   CONSTRAINT A_PK PRIMARY KEY(e1Id, e2Id),
   CONSTRAINT A_AK UNIQUE(e1Id, e3Id),
   CONSTRAINT A_1_AK UNIQUE(e2Id, e3Id),
   CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
   CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
   CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
); 
```
Dans sa version actuelle (3.0), Looping refuse que l’on modélise la CIF sous forme compactée. Là encore, une équivalence entre la représentation dépliée et la représentation compactée (à rendre possible) est vivement souhaitée...

D'avance, merci Paprick ! :D
__________________

⁽¹⁾ Pour modéliser une CIF avec Looping, voir par exemple ici.

⁽²⁾ Pour compacter la CIF avec Looping, cliquer sur la patte connectant l’entité-type E3 et l’association A, et une fois ouverte la fenêtre « Cardinalité », cocher la case « Entité ciblée par CIF ».
28/12/2020, 04h30
Paprick

Bonsoir François,

Comme d'habitude, ton exposé est très complet.
Il faut cependant rajouter un élément à ton analyse : Looping autorise le ciblage par une même CIF de plusieurs classes d'entités, en représentation dépliée mais aussi en version compacte ; par exemple E1 x E2 → E3, E4
Et dans ton cas du Code SQL(3), on a : E2 → E1, E3
En fait, la représentation compacte n'offre pas autant de possibilités que la version dépliée, en particulier pour les CIF à unicité incomplète.
Si tu analyses à fond la situation, tu verras que, en cas d'association n-aires avec n>3, la représentation compacte de ces CIF à unicité incomplète est impossible à formaliser sans ambiguïté, d'autant plus si on autorise, comme le fait Looping, le ciblage de plusieurs classes d'entités avec une même CIF.
En résumé, la représentation compacte ne concerne que les CIF complètes ; en cas d'unicité incomplète, et donc de clés alternatives, il va falloir déplier ! :pastaper:
28/12/2020, 04h48
fsmrel

Salve,

Citation:

Envoyé par Paprick

En résumé, la représentation compacte ne concerne que les CIF complètes ; en cas d'unicité incomplète, et donc de clés alternatives, il va falloir déplier !

On est bien d’accord, Paprick. Tu noteras que d’entrée j’ai bien pris soin de parler de CIF complètes. :wink:

Et joyeux Noël à toi !
28/12/2020, 12h08
Paprick

Citation:

Envoyé par fsmrel

On est bien d’accord, Paprick. Tu noteras que d’entrée j’ai bien pris soin de parler de CIF complètes.

Effectivement, et donc, pour être complet, je préciserai que la représentation compacte ne concerne que les associations "mono-CIF" complètes 8-).
Bonnes fêtes ! :chin:
28/12/2020, 20h59
fsmrel

3 pièce(s) jointe(s)
Salve,

Merci Patrick.

Citation:

Envoyé par Paprick

la représentation compacte ne concerne que les associations "mono-CIF" complètes

Dommage, donc définitivement tant pis pour les autres CIF complètes ? :(

Dans ces conditions, il faudrait empêcher la représentation de plus d’une CIF compacte.

Je rappelle que j’avais proposé le MCD (deux CIF en version dépliée) suivant :

Pièce jointe 587535

pour lequel le code SQL (2) est conforme à ce qu’on attend :
```
CREATE TABLE A
(
  e1Id INT,
   e2Id INT,
   e3Id INT NOT NULL,
   CONSTRAINT A_PK PRIMARY KEY(e1Id, e2Id),
   CONSTRAINT A_AK UNIQUE(e2Id, e3Id),
   CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
   CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
   CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
```
Tandis que le MCD en version compacte est redoutable :

Pièce jointe 587538

car, comme je l’avais signalé, il donne lieu au code SQL (3) :
```
CREATE TABLE A
(
   e2Id INT,
   e1Id INT NOT NULL,
   e3Id INT NOT NULL,
   CONSTRAINT A_PK PRIMARY KEY(e2Id),   
   CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
   CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
   CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
```
Mais le MCD dont est issu ce code SQL ne peut guère être que celui-ci :

Pièce jointe 587539

Fort éloigné de celui que j’avais proposé en version dépliée ou compacte...
28/12/2020, 22h21
Paprick

Bonsoir François,

Citation:

Envoyé par fsmrel

Dans ces conditions, il faudrait empêcher la représentation de plus d’une CIF compacte.

En fait, c'est déjà le cas : lorsque tu sélectionnes 2 "Entités ciblées par CIF" dans la fenêtre lien, tu ne crées pas 2 CIF, mais bien une seule avec 2 cibles.
Donc, on est bien dans cette limite qui consiste à n'utiliser la représentation compacte que lorsque qu'il n'y a qu'une seule CIF.
Pour te convaincre de cette nécessaire limite, reprend ton modèle de course hippique avec 4 classes d'entités autour de l'association : tu verras vite que tu ne peux pas exprimer plusieurs CIF en représentation compacte.
Et, même si on l'autorisait pour les seules CIF complètes, une même classe d'entités pourrait être émettrice et cible à la fois ce qui ne serait pas clair au niveau représentation, et surtout cela empêcherait le fait d'avoir plusieurs cibles.
Enfin, autant le représentation compacte est intéressante pour les cas de tripattes mono-CIF (très largement les plus fréquentes), autant tous les autres cas doivent, à mon avis, faire l'objet de CIF dépliées.
D'ailleurs, dans l'ouvrage de référence que tu cites, il est précisé : "Lorsque ce type de contrainte est la seule portée par la relation, nous suggérons de l'intégrer à la relation en fléchant la patte la connectant à l'entité cible".
29/12/2020, 09h25
Paprick

1 pièce(s) jointe(s)

Et pour être tout à fait complet, et bien montrer le principe d'une CIF multi-cibles, voici ce que donnerait exactement ton dernier modèle en version CIF dépliée :
Pièce jointe 587559
Le code SQL généré étant exactement le même que celui de ton modèle en représentation compacte ou celui avec décomposition de l'association et identifiant relatif.
Et il correspond bien à ce que l'on peut attendre quand on analyse visuellement le MCD.;)
Mais, dans ce cas précis, il y a moyen de faire un MCD beaucoup simple et clair en évitant la tripatte avec 2 associations 1,1---0,n partant de E2 !
29/12/2020, 18h30
fsmrel

2 pièce(s) jointe(s)
Ave Patrick,

Citation:

Envoyé par Paprick

Lorsque tu sélectionnes 2 "Entités ciblées par CIF" dans la fenêtre lien, tu ne crées pas 2 CIF, mais bien une seule avec 2 cibles.

On aurait pu envisager une autre approche...

Pour reprendre ci-dessous le MCD

Pièce jointe 587589

Si je te suis, l’association A jouerait donc à la fois le rôle de portée et de CIF si je puis dire. Je ne dispose pas de toute la littérature traitant des CIF, mais jusqu’ici j’ai toujours lu qu’à une source (mono ou multi individus (je reprends la terminologie de l’Afcet)) ne correspondait qu’une et une seule cible. Faire correspondre deux cibles à une source me fait tiquer, tout comme si une DF pouvait avoir deux dépendants, et pour le coup ça n’est pas possible (à moins peut-être d’aller folâtrer dans un univers quantique...)

Citation:

Envoyé par Paprick

Et pour être tout à fait complet, et bien montrer le principe d'une CIF multi-cibles, voici ce que donnerait exactement ton dernier modèle en version CIF dépliée

Pièce jointe 587590

Se manifeste là un problème d’ordre technique : en effet Looping ne m’autorise qu’une seule cible pour la CIF dépliée que tu as représentée. Comment arriver à avoir une CIF dépliée et deux cibles pour la source associée ?

Citation:

Envoyé par Paprick

il y a moyen de faire un MCD beaucoup simple et clair en évitant la tripatte avec 2 associations 1,1---0,n partant de E2 !

Dans ce cas particulier, tu as évidemment raison.

Cela dit j’aime bien vérifier les choses dans le contexte relationnel, lequel nous fournit les théorèmes nécessaires.

Je reprends la structure de la table A créée par Looping :
```
CREATE TABLE A
(
   e2Id INT,
   e1Id INT NOT NULL,
   e3Id INT NOT NULL,
   CONSTRAINT A_PK PRIMARY KEY(e2Id),   
   CONSTRAINT A_E2_FK FOREIGN KEY(e2Id) REFERENCES E2(e2Id),
   CONSTRAINT A_E1_FK FOREIGN KEY(e1Id) REFERENCES E1(e1Id),
   CONSTRAINT A_E3_FK FOREIGN KEY(e3Id) REFERENCES E3(e3Id)
);
```
Puisque {e2Id} est clé candidate, il existe les dépendances fonctionnelles :

{e2Id} →{e1Id}

{e2Id} →{e3Id}

Et par application du théorème de Heath, le triplet {e1Id, e2Id, e3Id} est décomposable selon les paires {e1Id, e2Id} et {e2Id, e3Id}. La décomposition est sans perte, c’est-à-dire que l’on vérifie l’égalité :

{e1Id, e2Id} JOIN {e2Id, e3Id} = {e1Id, e2Id, e3Id}

Pardonne-moi cette escapade dans le Relationland, mais c’est chez moi un réflexe...

Cela dit, mon objet initial était plutôt de chercher une équivalence entre version dépliée (plus d’une CIF) et version compacte et je reste sur ma faim...
29/12/2020, 19h37
Paprick

3 pièce(s) jointe(s)

Bonsoir François,

Citation:

Envoyé par fsmrel

Se manifeste là un problème d’ordre technique : en effet Looping ne m’autorise qu’une seule cible pour la CIF dépliée que tu as représentée. Comment arriver à avoir une CIF dépliée et deux cibles pour la source associée ?

Quand tu crées les liens entre la CIF et les classes d'entités, par défaut le premier lien est la cible et les autres sont les émettrices : il suffit alors que tu sélectionnes le lien de la 2ème cible et que tu valides la case à cocher "Lien vers l'entité ciblée par la contrainte".

Citation:

Puisque {e2Id} est clé candidate, il existe les dépendances fonctionnelles :
{e2Id} →{e1Id}
{e2Id} →{e3Id}
Et par application du théorème de Heath, le triplet {e1Id, e2Id, e3Id} est décomposable selon les paires {e1Id, e2Id} et {e2Id, e3Id}. La décomposition est sans perte, c’est-à-dire que l’on vérifie l’égalité :
{e1Id, e2Id} JOIN {e2Id, e3Id} = {e1Id, e2Id, e3Id}

On est bien d'accord :ccool:

Citation:

Cela dit, mon objet initial était plutôt de chercher une équivalence entre version dépliée (plus d’une CIF) et version compacte et je reste sur ma faim...

Pour moi, cette équivalence n'est pas toujours possible, la version compacte exprimant, en toute logique, les choses de manière plus concises et donc potentiellement moins détaillée.

Je te soumets un exemple pour lequel la version compacte version Looping fonctionne, alors que sa traduction sans la double cible est impossible en version compacte.

Version dépliée classique avec 2 CIF :
Pièce jointe 587597

Version dépliée avec une CIF et 2 classes d'entités cibles :
Pièce jointe 587599

Et la version compacte correspondante :
Pièce jointe 587601

Ces 3 modèles produisent bien sûr le même code SQL avec A=(#e1Id, #e2Id, #e3Id, #e4Id) et offre, à mon sens, une très bonne équivalence visuelle.

Qu'en penses-tu ?
30/12/2020, 02h00
fsmrel

1 pièce(s) jointe(s)

Salve Patrick,

Citation:

Envoyé par Paprick

Quand tu crées les liens entre la CIF et les classes d'entités, par défaut le premier lien est la cible et les autres sont les émettrices : il suffit alors que tu sélectionnes le lien de la 2ème cible et que tu valides la case à cocher "Lien vers l'entité ciblée par la contrainte".

On doit avoir une version un peu différente de Looping, car lorsque je fais comme tu dis, avec la version 3.0 (en date du 01/11/2020), quand je coche la case pour la 2e cible, il y a bien affichage de la nouvelle flèche mais il y a disparition de la flèche initiale, je n’ai donc toujours qu’une cible... :(

Concernant la version dépliée classique avec 2 CIF :

Cette version comporte deux CIF incomplètes, et le code SQL de la table A est correct. En effet, chaque CIF donne bien lieu à la clé candidate {e1Id, e2Id}. En termes relationnels, les dépendances de jointure contenues dans la relvar A sont toutes des conséquences de cette clé : la relvar est en 5NF.

Concernant la version dépliée avec une CIF et 2 classes d'entités cibles :

En l’occurrence Je n’ai pas d’opinion, puisque pour moi une DF (à la Nanci) à deux cibles n’est pas une DF mais quelque chose que je ne connais pas, et comme je l’ai écrit, ce qui vaut pour les DF vaut à mon sens pour les CIF : si deux cibles, alors deux CIF...

Concernant la version compacte correspondante :

Là encore tu connais ma position, s’il y a deux cibles il y a deux CIF, et elles sont complètes. Qui dit deux CIF, dit deux clés candidates :

K1 = {e1Id, e2Id, e4Id}

K2 = {e1Id, e2Id, e3Id}

Je continue donc à interpréter cette représentation compacte comme équivalente à sa version dépliée :

Pièce jointe 587609

Ne m’en veux pas, cette histoire de CIF à deux cibles me fait réagir exactement comme si en mathématiques on me disait que pour une application d’un ensemble E dans un ensemble F, à un élément de E pouvait correspondre plus d’un élément de F... :weird: :cfou:
30/12/2020, 03h00
Paprick

Citation:

Envoyé par fsmrel

On doit avoir une version un peu différente de Looping, car lorsque je fais comme tu dis, avec la version 3.0 (en date du 01/11/2020), quand je coche la case pour la 2e cible, il y a bien affichage de la nouvelle flèche mais il y a disparition de la flèche initiale, je n’ai donc toujours qu’une cible... :(

Bizarre... Cette fonction était déjà présente sur la 2.6 :weird:.
Par contre, ce que tu dis se produit dans le cas où tu choisis une 2ème cible sur la dernière émettrice restante : effectivement, Looping fait alors en sorte de conserver au moins une émettrice.
Dis-moi si c'est bien ça.

Citation:

Concernant la version dépliée classique avec 2 CIF :
Cette version comporte deux CIF incomplètes, et le code SQL de la table A est correct. En effet, chaque CIF donne bien lieu à la clé candidate {e1Id, e2Id}. En termes relationnels, les dépendances de jointure contenues dans la relvar A sont toutes des conséquences de cette clé : la relvar est en 5NF.

On est bien d'accord sur ce point. :)

Citation:

Concernant la version dépliée avec une CIF et 2 classes d'entités cibles :
En l’occurrence Je n’ai pas d’opinion, puisque pour moi une DF (à la Nanci) à deux cibles n’est pas une DF mais quelque chose que je ne connais pas, et comme je l’ai écrit, ce qui vaut pour les DF vaut à mon sens pour les CIF : si deux cibles, alors deux CIF...

Je comprends ta position, la multi-cibles étant une extension du formalisme qui peut être discutable : et, afin d'être consensuel, je vais envisager de proposer cette extension uniquement en option.

Citation:

Concernant la version compacte correspondante :
Là encore tu connais ma position, s’il y a deux cibles il y a deux CIF, et elles sont complètes. Qui dit deux CIF, dit deux clés candidates :
K1 = {e1Id, e2Id, e4Id}
K2 = {e1Id, e2Id, e3Id}
Je continue donc à interpréter cette représentation compacte comme équivalente à sa version dépliée.

Si l'option "multi-cibles" n'est pas choisie, alors je te rejoins sur le fait que chaque flèche indiquerait alors une DF, et s'il y en a plusieurs, on pourrait l'interpréter comme s'il y a avait plusieurs CIF...
Mais, peut-être serait-il plus sage alors de ne pas proposer la représentation compacte de plusieurs CIF sur une même association : ces cas de modélisation sont peu fréquents et, quand cela se produit, autant utiliser la version dépliée pour éviter toute ambiguïté dans l'interprétation du modèle.

Cela te conviendrait-il ? :cfou:
30/12/2020, 03h56
fsmrel

Citation:

Envoyé par Paprick

Bizarre... Cette fonction était déjà présente sur la 2.6 :weird:.
Par contre, ce que tu dis se produit dans le cas où tu choisis une 2ème cible sur la dernière émettrice restante : effectivement, Looping fait alors en sorte de conserver au moins une émettrice.
Dis-moi si c'est bien ça.

Je ne me souviens plus de l’ordre dans lequel j’ai fait la manip. Cette fois-ci, j’ai commencé par définir E3 comme cible, puis E1 comme émettrice, puis E2 comme émettrice. Ensuite j’ai tiré le lien entre le cercle de la CIF et E4, puis j’ai cliqué sur ce lien et coché la case "Lien vers l’entité ciblée" et cette fois-ci ça marche, j’ai bien les deux flèches...

Citation:

Envoyé par Paprick

Si l'option "multi-cibles" n'est pas choisie, alors que je te rejoindrai : chaque flèche indiquera alors une DF, et s'il y en a plusieurs, je l'interprèterai comme s'il y a avait plusieurs CIF.
Cela te conviendrait-il ? :cfou:

Tu es un sage, ton approche me convient, merci à toi.

Et maintenant, je vais pouvoir aller faire dodo paisiblement... ;)
30/12/2020, 04h09
Paprick

Mais, comme indiqué dans mon post (modifié après mure réflexion !), peut-être serait-il plus sage de ne pas proposer la représentation compacte de plusieurs CIF sur une même association : ces cas de modélisation sont peu fréquents et, quand cela se produit, autant utiliser la version dépliée pour éviter toute ambiguïté dans l'interprétation du modèle, d'autant plus qu'il serait délicat de choisir la PK et les AK parmi les clés candidates.

Ca te convient toujours ? :mrgreen:
30/12/2020, 16h46
fsmrel

Pluralitas non est ponenda sine necessitate

Ave Patrick,

Pluralitas non est ponenda sine necessitate (Ockham)

Citation:

Envoyé par Paprick

Ca te convient toujours ? :mrgreen:

Hum... :mrgreen: Pour te simplifier la tâche, je saurai faire contre mauvaise fortune bon coeur, car tu as certainement des masses de points plus importants et urgents à régler pour Looping. Disons que ce problème de la représentation compacte de plusieurs CIF sur une même association peut être mis sous le coude pour un temps (non infini !), et qu’en attendant tu bloques donc ce type de représentation, nous obligeant à nous rabattre sur la représentation dépliée, certes un peu encombrante, mais ça n’est quand même pas bien grave.

Quant à l’élection de Miss PK, peu m’en chaut, car comme je l’ai évoqué il y a un an, quand je me coiffe de mon chapeau relationnel, je n’utilise que le concept de clé (KEY), vois la relvar PARTICIPER dans le post auquel je renvoie. Mais pour ne pas traumatiser les utilisateurs de SQL (dont font partie tes étudiants :P), je remplace sans problème tel ou tel UNIQUE par PRIMARY KEY, car aujourd’hui le choix de la Miss relève plus de la psychologie que de la science...
30/12/2020, 17h41
Paprick

Salut François,

Citation:

Envoyé par fsmrel

Pluralitas non est ponenda sine necessitate (Ockham)

C'est sûr ! Et en plus, il ne faut pas qu'une même représentation puisse vouloir dire des choses différentes !

Citation:

Hum... :mrgreen: Pour te simplifier la tâche, je saurai faire contre mauvaise fortune bon coeur, car tu as certainement des masses de points plus importants et urgents à régler pour Looping. Disons que ce problème de la représentation compacte de plusieurs CIF sur une même association peut être mis sous le coude pour un temps (non infini !), et qu’en attendant tu bloques donc ce type de représentation, nous obligeant à nous rabattre sur la représentation dépliée, certes un peu encombrante, mais ça n’est quand même pas bien grave.

Le problème n'est pas technique... c'est plutôt que, si l'on autorise la multi-CIF compactée, cela signifie qu'un même schéma avec ou sans l'option "multi-cible" aurait une signification différente... et ça, ce n'est pas acceptable... :weird:
Donc, il faut faire un choix, camarade : soit la multi-CIF compactée, soit la possibilité d'offrir l'option multi-cibles. Pour ma part, je pense raisonnable de décréter que la représentation compactée ne peut concerner qu'une mono-CIF complète. En effet, considérer qu'une classe d'entité ciblée par une CIF avec une flèche est également émettrice d'une autre CIF me pose un réel problème d'interprétation visuelle du modèle.

Citation:

Quant à l’élection de Miss PK, peu m’en chaut, car comme je l’ai évoqué il y a un an, quand je me coiffe de mon chapeau relationnel, je n’utilise que le concept de clé (KEY), vois la relvar PARTICIPER dans le post auquel je renvoie. Mais pour ne pas traumatiser les utilisateurs de SQL (dont font partie tes étudiants :P), je remplace sans problème tel ou tel UNIQUE par PRIMARY KEY, car aujourd’hui le choix de la Miss relève plus de la psychologie que de la science...

L'élection de Miss PK est tout de même une affaire d'importance que Looping ne doit pas régler aléatoirement ; or, la représentation dépliée permet au concepteur de faire lui-même ce choix (ce qui règle notre problème psychologique :mouarf:). La mise sous cloche pourrait donc prendre des allures de mise aux oubliettes avec jet de la clé dans la Garonne (fleuve le plus proche de chez moi ;))...:kill: