Discussion :

[J1]

Bonsoir,

aujourd'hui, j'ai eu envie de mettre à l'épreuve mon SGBD : lui serait-il possible de gérer la mise à jour/suppression en cascade dans le cadre d'une relation réflexive ? Je m'explique :

Soit la table test constituée de 2 champs, pk et fk :

Code :

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

1
2
3
4
5
6
pk fk
-----
1  1
2  1
3  2

Je souhaite établir une relation entre le champ fk (clef étrangère) et le champ pk (clef primaire) afin que la suppression/mise à jour d'un enregistrement entraîne la suppression/mise à jour des enregistrements enfants.
En l'occurrence, la suppression de l'enregistrement 1/1 entraînerait donc celle de l'enregistrement 2/1... qui entraînerait elle-même celle de l'enregistrement 3/2.
Le but n'est pas de gérer cela avec un trigger, mais de savoir si le SGBD est en mesure de le gérer dans le cadre d'une simple relation avec cascade.

J'ai donc tenté d'exécuter l'instruction de création de table suivante sous SQL Server 2000 :

Code :

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

1
2
3
4
5
6
 
CREATE TABLE test (
pk NUMERIC,
fk NUMERIC,
CONSTRAINT c1 PRIMARY KEY (pk),
CONSTRAINT c2 FOREIGN KEY (fk) REFERENCES test (pk) ON UPDATE CASCADE ON DELETE CASCADE);

Et SQL Server 2000 de me répondre :

L'introduction d'une contrainte de clé étrangère 'c2' dans la table 'TEST' peut provoquer des cycles ou des accès en cascade multiples. Spécifiez ON DELETE NO ACTION ou ON UPDATE NO ACTION ou modifiez les autres contraintes de clés étrangères

La réponse n'est pas celle que j'espérais, mais elle a le mérite d'être claire.

Me demandant si un autre SGBD serait en mesure de gérer ce type de relation, j'ai essayé de la mettre en place sous Access. Access me laisse bien mettre en place la relation, mais lorsque j'essaie de supprimer un enregistrement parent, j'essuie le refus suivant :

Impossible de mettre à jour; actuellement verrouillé(e).

Faut-il en déduire qu'il est impossible à un SGBD de gérer nativement (sans trigger) une mise à jour/suppression en cascade dans le cadre d'une relation réflexive ?


Remarques :

• mes recherches m'ont amené à découvrir que ce thème avait déjà été abordé, sans réponse définitive, dans la discussion suivante :
  http://www.developpez.net/forums/sho...d.php?t=166443

• une KB de Microsoft décrit le message d'erreur SQL Server que j'ai cité plus haut. A noter que la KB s'attarde plus sur la question des "accès en cascade multiples" que sur celle des "cycles", sujet de la présente discussion.

• mes recherches m'ont également conduit vers un topic soulevant la question du bien fondé de la mise a jour/suppression en cascade. Il est bien évident que la discussion créée aujourd'hui n'a pas pour objet de débattre du bien fondé de cette technique mais de savoir si, oui ou non, une mise à jour/suppression en cascade est techniquement possible dans le cadre d'une relation réflexive.

[Alain Defrance]

Bonjour,

Il a l'air de te refuser les deux cascades simultanés, ce qui ne veux pas dire qu'un cascade sur un delete uniquement ne marchera pas.
Il est par ailleurs très rare d'avoir un on update cascade, puisque généralement cela s'applique a des identifiant (du moins je l'espère pour la personne qui utilise la base de donnée). D'autant plus qu'il n'est pas rare de voir une double identification d'occurrence, une clé pour le système qui est soumise au contrôle d'intégrité, et une pour l'utilisateur parfois composé avec des lettres et autres réjouissance.
Ceci implique que souvent (et ils est préférable) les clés ne sont même pas connu de l'utilisateur. Ainsi puisqu'il n'est pas nécessaire de changer les valeurs des identifiants (le système se débrouille très bien avec ses valeurs numérique), il n'est plus utile répercuter ces modifications qui seront inexistante.
C'est pourquoi l'abscence du ON UPDATE dans Oracle par exemple n'est pas gênant, et si on viens a avoir besoin impérativement de changer les clé, il sera toujours possible de faire un trigger pour cela, ou un procédure ponctuelle.

Je ne suis pas du tout spécialiste de SQL Serveur, mais a mon sens qu'il te refuse un ON UPDATE et un ON DELETE a la fois, n'est pas une gène puisque je travaille généralement sans ON UPDATE.

[J1]

Bonjour kazou et merci d'avoir pris le temps de me répondre.

Je ne l'avais pas précisé dans mon premier message, mais l'"erreur" que je cite se produit également lorsque j'essaie de mettre en place seulement une cascade de mise à jour ou seulement une cascade de suppression.

Ci-dessous les requêtes correspondantes :

Code :

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

1
2
3
4
5
6
 
CREATE TABLE test (
pk NUMERIC,
fk NUMERIC,
CONSTRAINT c1 PRIMARY KEY (pk),
CONSTRAINT c2 FOREIGN KEY (fk) REFERENCES test (pk) ON UPDATE CASCADE);

Code :

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

1
2
3
4
5
6
 
CREATE TABLE test (
pk NUMERIC,
fk NUMERIC,
CONSTRAINT c1 PRIMARY KEY (pk),
CONSTRAINT c2 FOREIGN KEY (fk) REFERENCES test (pk) ON DELETE CASCADE);

[Alain Defrance]

Dans ce cas c'est effectivement contraignant surtout que ton SQL a l'air ok.
Je pense qu'il va falloir attendre un expert en SQL Server

[say]

Bjr,

Je bosse sous postgreSQL et j'ai des tables avec relation réflexive, et UPDATE CASCADE.

non seulement, j'ai eu le droit de les créer mais cela fonctionne correctement.

+1 pour l'avis d'un expert SQL Server.

[fsmrel]

Bonjour J1,


Ah ! Ces SGBD staliniens....

Concernant les tables qui s’auto-référencent, avec DB2 for z/OS, depuis 1988 on peut coder :

Code :

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

1
2
3
4
5
CREATE TABLE test (
pk NUMERIC,
fk NUMERIC,
CONSTRAINT c1 PRIMARY KEY (pk),
CONSTRAINT c2 FOREIGN KEY (fk) REFERENCES test (pk) ON DELETE CASCADE);

mais il vous est fait interdiction de coder ainsi la contrainte c2 :

Code :

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

CONSTRAINT c2 FOREIGN KEY (fk) REFERENCES test (pk) ON DELETE RESTRICT);

Et dans tous les cas de figure, que les tables s’auto-référencent ou non, DB2 interdit de coder ON UPDATE CASCADE. Je vous renvoie à ce que j’ai écrit dans Une petite couche supplémentaire (L'article étant un peu long, cherchez "Du temps où Ted Codd insistait").

[J1]

Merci à vous, say et fsmrel.
Vos retours d'expérience m'indiquent que la mise en place d'une relation réflexive avec mise à jour/suppression en cascade est possible sur certains SGBD. Voilà qui me rassure un peu, mais quel dommage tout de même : SQL Server 2000 gérant les triggers récursifs, j'aurais cru qu'il gèrerait nativement ce type de relation.
Quoi qu'il en soit, je reste bien sûr à l'affût d'autres retours d'expérience, quel que soit le SGBD.

Quant à l'anecdote relative à la v2 de DB2, fsmrel, je dois dire qu'elle est en effet assez savoureuse !

[fsmrel]

Bonsoir J1,

J’observe que vous utilisez l’auto-référence : vous fournissez en effet l'exemple suivant :

Code :

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

1
2
3
4
5
pk fk
-----
1  1
2  1
3  2

dans lequel il existe une ligne ayant la valeur <1, 1>. Autrement dit, quel que soit x, vous autorisez la valeur <x, x>.
Est-ce la sémantique de votre application qui vous conduit à procéder ainsi ? Au-delà d’une certaine crainte (sinon crainte certaine) que m’inspire l’auto-référence (je n’ai pas oublié le paradoxe du barbier et le désarroi de Frege...), cela éveille en moi de la curiosité, car je n’ai jamais eu à procéder ainsi. J’ai mis en œuvre des nomenclatures de pièces, des hiérarchies : jamais d’auto-référence. Pour l’anecdote, j’étais intervenu chez les militaires et avais fait observer au Lt Colonel H* qu’il me paraissait suspect de trouver ce même genre de valeur <1, 1> dans ses tables. Je lui fis observer que SQLment parlant, il se trouvait hiérarchiquement au même niveau que le Colonel T* dont il était le bras droit : il me répondit "Reçu 5/5 !" et donna l’ordre au Lieutenant F* de rétablir les choses (notamment au niveau du MCD).
Concernant les bases de données, je pense qu’il y a un risque à pratiquer l’auto-référence, quand par exemple on utilise la jointure récursive. Je ne chercherai même pas à tenter de le faire, je crains les boucles infinies (et que le ciel me tombe sur la tête)...

[say]

En tout logique la mise en place d'autoréférence doit s'accompagner de mise en place de contrainte interdisant la présence d'une valeur <x,x>.

non?

Je lui fis observer que SQLment parlant, il se trouvait hiérarchiquement au même niveau que le Colonel T* dont il était le bras droit : il me répondit "Reçu 5/5 !" et donna l’ordre au Lieutenant F* de rétablir les choses (notamment au niveau du MCD)

Je comprends pas cette explication (bon, on est le matin...hein, indulgence )
est-ce en rapport avec la présence possible de <x,x>?.
Quand vous dites au même niveau, c'est dans le sens dans la même table?

finalement la question n'est-elle pas : quel est l'intérêt de l'autoréférence?

[J1]

Bonjour,

Bonsoir J1,

J’observe que vous utilisez l’auto-référence : vous fournissez en effet l'exemple suivant :

Code :

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

1
2
3
4
5
pk fk
-----
1  1
2  1
3  2

dans lequel il existe une ligne ayant la valeur <1, 1>. Autrement dit, quel que soit x, vous autorisez la valeur <x, x>.
Est-ce la sémantique de votre application qui vous conduit à procéder ainsi ?

Etant donné la contrainte d'intégrité référentielle, j'ai deux solutions pour débuter une arborescence : soit des lignes qui s'autoréférencent, comme :

Code :

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

1
2
3
4
pk fk
-----
1  1

soit des lignes pour lesquelles la colonne fk n'est pas renseignée :

Code :

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

1
2
3
4
pk fk
-----
1  NULL

(dans ce cas, on définira évidemment la colonne fk comme étant nullable)

Le choix entre les 2 solutions est notamment une question de point de vue : estime-t-on que les lignes débutant une arborescence n'ont pas de parent (solution 2), ou qu'elles sont leur propre parent (solution 1)...

Concernant les bases de données, je pense qu’il y a un risque à pratiquer l’auto-référence, quand par exemple on utilise la jointure récursive. Je ne chercherai même pas à tenter de le faire, je crains les boucles infinies (et que le ciel me tombe sur la tête)...

La crainte d'une boucle infinie (nous ne parlons donc plus ici de "simple" SQL, mais de SQL procédural, permettant de réaliser des boucles) est en effet justifiée. Mais, en admettant que l'on opte effectivement pour la solution des lignes autoréférencées, on peut alors ajouter dans la condition de jointure que pk doit être différent de fk.

Est-ce la sémantique de votre application qui vous conduit à procéder ainsi ?

Concernant la question de la relation réflexive, je n'ai d'autre impératif que celui de satisfaire ma curiosité. Pas de contrainte particulière, juste l'envie d'en savoir plus sur un thème que je n'avais pas encore eu l'occasion d'approfondir.

Pour l’anecdote, j’étais intervenu chez les militaires et avais fait observer au Lt Colonel H* qu’il me paraissait suspect de trouver ce même genre de valeur <1, 1> dans ses tables. Je lui fis observer que SQLment parlant, il se trouvait hiérarchiquement au même niveau que le Colonel T* dont il était le bras droit : il me répondit "Reçu 5/5 !" et donna l’ordre au Lieutenant F* de rétablir les choses (notamment au niveau du MCD).

Savoureux, à nouveau !

Je comprends pas cette explication (bon, on est le matin...hein, indulgence )
est-ce en rapport avec la présence possible de <x,x>?.
Quand vous dites au même niveau, c'est dans le sens dans la même table?

Je pense que ce fsmrel veut dire, c'est que si l'on imagine la table Personnes suivante :

Code :

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

1
2
3
4
5
6

Nom    NomDuSuperieur
-----------
Col.T  Col.T
Col.H  Col.T

le colonel T et le colonel H sont tous deux considérés comment subordonnés du colonel T.

Pour éviter cela, l'autre solution envisageable serait donc :

Code :

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

1
2
3
4
5
6

Nom     NomDuSuperieur
-----------
Col.T   NULL
Col.H   Col.T

Si l'on transpose l'explication que je donnais tout à l'heure, cela reflète à nouveau 2 points de vue différents : le colonel T dirait-il qu'il n'a d'ordre à recevoir de personne (solution 2), ou dirait-il qu'il n'a d'autre maître que lui-même (solution 1) ?

[Alain Defrance]

fsmrel a tout a fait raison et a mis en évidence un détail que je n'avais pas remarqué.
A vrais dire dire qu'une occurrence fait référence a elle même est asses rare.
Lors qu'une jointure cela mènera a une boucle récursive infini, (c'est d'ailleurs une boucle si on représente sont graphe orienté).
Ceci couplé avec des [ ON UPDATE | ON DELETE ] CASCADE, le SGBD ne s'y retrouve plus car on lui dit, quand tu delete l'occurrence référence, tu delete l'occurrence elle même, et donc dans ce cas précis, il se trouve que la référence et la même occurrence ...

[say]

le colonel T et le colonel H sont tous deux considérés comment subordonnés du colonel T.

reçu 5/5 .

ceci dit...quant à choisir la solution 1 ou la solution 2...
dans le cas de la solution 1, ici depuis le début nous ne raisonnons que sur la racine de l'arbre hiérarchique...comment dès lors éviter qu'une classe hiérarchique inférieure s'autoréférence?
par ailleurs, cela met en effet en évidence la problématique soulignée par kazou.

j'utilise bcp de relation réflexive et il ne m'est jamais venu à l'idée qu'une entité se référence elle-même.

rétablir les choses (notamment au niveau du MCD).

c'est-à-dire? mettre de côté les relations réflexives, en omettant certaines de leurs avantages?

[J1]

fsmrel a tout a fait raison et a mis en évidence un détail que je n'avais pas remarqué.
A vrais dire dire qu'une occurrence fait référence a elle même est asses rare.
Lors qu'une jointure cela mènera a une boucle récursive infini

Comme je l'écrivais dans mon précédent message, cela dépend de la condition de jointure.

Ceci couplé avec des [ ON UPDATE | ON DELETE ] CASCADE, le SGBD ne s'y retrouve plus car on lui dit, quand tu delete l'occurrence référence, tu delete l'occurrence elle même, et donc dans ce cas précis, il se trouve que la référence et la même occurrence ...

Tout dépend de la manière dont le SGBD gère ses verrous lors de l'application de la cascade, mais en effet, la remarque est pertinente (particulièrement dans le cas d'un ON UPDATE CASCADE à mon avis). Merci kazou !

Tellement pertinente en fait que cela m'a donné envie d'aller consulter les options de verrouillage d'Access (Menu 'Outils' -> 'Options' -> 'Avancé'). Ce qui fait qu'au final, sous Access, je réussis à présent à mettre en oeuvre une jointure réflexive avec mise à jour/suppression en cascade !

dans le cas de la solution 1, ici depuis le début nous ne raisonnons que sur la racine de l'arbre hiérarchique...comment dès lors éviter qu'une classe hiérarchique inférieure s'autoréférence?

C'est vrai, mais si nous venons sur ce terrain, la même question se pose aussi avec la solution 2 : comment "obliger" une classe hiérarchique inférieure à indiquer sa classe parente ?
Dans les deux cas, est-ce vraiment le rôle du SGBD ? En effet, on parle ici d'une donnée erronée (mais conforme aux règles de gestion) qui serait saisie : le SGBD en est-il responsable ?

PS : merci à tous pour cette discussion, que je trouve particulièrement intéressante !

[Alain Defrance]

Dans les deux cas, est-ce vraiment le rôle du SGBD ? En effet, on parle ici d'une donnée erronée (mais conforme aux règles de gestion) qui serait saisie : le SGBD en est-il responsable ?

Je dirais que le rôle principal d'un SGBD est le contrôle d'intégrité et donc éviter les non sens.
Je pense donc que c'est du ressort du SGBD de conserver la base de donnée cohérente. Ici c'est le cas puisqu'il n'est pas logique de lier une occurrence à elle même.
Cela se traduirait par éventuellement par un trigger qui a l'insert refuserait l'ajout en cas de référence vers la même occurrence, ou bien en corrigeant en posant un marqueur NULL.

Peut-être que le modèle merisier au travers de contrainte proposent une modélisation de ce type de référence, si quelqu'un trouve une modélisation de ce type de contrainte ça peut être intéressant.

[J1]

Il me semble que say demande comment éviter qu'une classe hiérarchique inférieure s'autoréférence à partir du moment où on adopte la solution 1, c'est-à-dire lorsque l'on considère que tout en haut de l'aborescence, les classes doivent être autoréférencées.

Je lui répondais donc que ce n'était pas possible, tout comme il est impossible de forcer une classe hiérarchique inférieure à indiquer sa classe parente, à partir du moment où on adopte la solution 2.

Dans les 2 cas, ça me semble impossible, parce que c'est justement l'information saisie dans la table qui détermine si une classe est ou non hiérarchiquement inférieure.

[say]

C'est vrai, mais si nous venons sur ce terrain, la même question se pose aussi avec la solution 2 : comment "obliger" une classe hiérarchique inférieure à indiquer sa classe parente ?

tout à fait! me doutais que la remarque arriverait. Après qu'est ce qui est moins logique : une classe qui ne référence pas son hierarchique..on une classe qui se référence elle-même?
contraindre l'autoréférenement, ça doit se pouvoir se faire..tandis que contraindre le référencement de la classe parente...je vois pas.

Dans les deux cas, est-ce vraiment le rôle du SGBD ? En effet, on parle ici d'une donnée erronée (mais conforme aux règles de gestion) qui serait saisie : le SGBD en est-il responsable ?

d'accord avec kazou

[say]

Il me semble que say demande comment éviter qu'une classe hiérarchique inférieure s'autoréférence à partir du moment où on adopte la solution 1, c'est-à-dire lorsque l'on considère que tout en haut de l'aborescence, les classes doivent être autoréférencées.

Je lui répondais donc que ce n'était pas possible, tout comme il est impossible de forcer une classe hiérarchique inférieure à indiquer sa classe parente, à partir du moment où on adopte la solution 2.

Dans les 2 cas, ça me semble impossible, parce que c'est justement l'information saisie dans la table qui détermine si une classe est ou non hiérarchiquement inférieure.

je pense malgré tout qu'il doit être possible de poser des contraintes supplémentaires...mais peut-etre pas sur tous les SGBD. je bosse notamment sous pgsql, et je pense que c'est faisable. je jettes un oeil

EDIT : je confirmes, ss Pgsql, j'ai

Code :

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

ONSTRAINT autoref CHECK (p_uid <> p_parent)

on doit pouvoir ajouter un appel à une PS pour vérifier des contraintes plus forte, de type hierarchie avec des données organisées de telle sorte à pouvoir appliquer tous les contrôles nécessaires.

[J1]

J'en reviens à mon message précédent : si tu veux que le SGBD oblige l'autoréférencement des classes parentes, il faudrait qu'il sache que les classes sont parentes. Hors c'est justement le fait qu'elles soient ou non autoréférencées qui détermine si elles sont ou non parentes.

A moins qu'on ne se soit pas compris.

Remarque : par "parente", j'entends "en haut de l'arborescence"

[say]

J'en reviens à mon message précédent : si tu veux que le SGBD oblige l'autoréférencement des classes parentes, il faudrait qu'il sache que les classes sont parentes. Hors c'est justement le fait qu'elles soient ou non autoréférencées qui détermine si elles sont ou non parentes.

A moins qu'on ne se soit pas compris.

Remarque : par "parente", j'entends "en haut de l'arborescence"

on est bien d'accord.
Dans le cas avec lequel je bosse, j'ai intégré une donnée supplémentaire permettant d'identifier le niveau hierarchique qui permettrait alors d'affiner les contraintes. Ce que je n'ai pas fait..car l'ergonomie côté applicatif règle le problème...
je vois déjà venir la remarque consistant à dire que ce n'est donc plus le SGBD qui applique les règles de gestion mais je pense que ce serait gérable.
Encore une fois, cela ne sera probablement pas le cas avec d'autres systèmes...genre Access

[fsmrel]

Attendez-moi, vous allez trop vite !

nous ne parlons donc plus ici de "simple" SQL, mais de SQL procédural, permettant de réaliser des boucles

Considérez-vous cet exemple comme du genre procédural ou déclaratif ?

A ce sujet, je cite Bertrand Russel :

The method of "postulating" what we want has many advantages; they are the same as the advantages of theft over honest toil.

Ce qui revient dans notre contexte à dire que la récursivité est à la programmation impérative ce que le vol est au labeur honnête...

Mais, en admettant que l'on opte effectivement pour la solution des lignes autoréférencées, on peut alors ajouter dans la condition de jointure que pk doit être différent de fk.

Quand je dis que je crains l’auto-référence, c’est parce que je suis distrait et que je pourrais oublier la condition de jointure que vous évoquez. Et même si j’y pense, certains de mes collègues moins aguerris ou vigilants pourraient tomber dans le piège.

Je cite say : "En tout logique la mise en place d'autoréférence doit s'accompagner de mise en place de contrainte interdisant la présence d'une valeur <x,x>."

Il est évident qu’il faut la jouer "Ceinture, bretelles et épingle à nourrice" et prendre le maximum de précautions en enrichissant la création de la table Test d’une contrainte c3, valant quel que soit le niveau de la hiérarchie :

Code :

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

1
2
3
4
5
6
CREATE TABLE test (
pk NUMERIC,
fk NUMERIC,
CONSTRAINT c1 PRIMARY KEY (pk),
CONSTRAINT c2 FOREIGN KEY (fk) REFERENCES test (pk) ON DELETE CASCADE),
Constraint c3 check (pk <> fk);

juste l'envie d'en savoir plus sur un thème que je n'avais pas encore eu l'occasion d'approfondir

Nous ferez-vous part de vos découvertes, notamment en ce qui concerne le comportement des autres SGBD ? Il y a certainement matière...

Je pense que ce fsmrel veut dire, c'est que si l'on imagine la table Personnes suivante :

Code :

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

1
2
3
4
Nom    NomDuSuperieur
-----------
Col.T  Col.T
Col.H  Col.T

le colonel T et le colonel H sont tous deux considérés comment subordonnés du colonel T.

Pour éviter cela, l'autre solution envisageable serait donc :

Code :

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

1
2
3
4
Nom     NomDuSuperieur
-----------
Col.T   NULL
Col.H   Col.T

Certes ! Mais...

le colonel T dirait-il qu'il n'a d'ordre à recevoir de personne (solution 2), ou dirait-il qu'il n'a d'autre maître que lui-même (solution 1) ?

La solution 1 engendrerait des situations intéressantes pour notre colonel, si par exemple il donnait l’instruction suivante : "Tous mes collaborateurs et leurs collaborateurs jusqu’au dernier seront d'astreinte dimanche prochain" (sous-entendu : "pendant que moi j'irai aux champignons)".

soit des lignes pour lesquelles la colonne fk n'est pas renseignée :

Code :

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

1
2
3
pk fk
-----
1  NULL

(dans ce cas, on définira évidemment la colonne fk comme étant nullable)

Fatalement, si l’on veut éviter l’auto-référence, on déboule sur l’utilisation de NULL. Or, vous savez que je suis partisan de coder "NOT NULL" pour chaque colonne de chaque table. C’est pour moi un défi et un enjeu, à savoir rester dans une logique binaire et éviter les pièges qui nous guettent dans l’emploi d’une logique ternaire inhérente à l’emploi de NULL.

Aussi, pour répondre à l’interrogation de say :

rétablir les choses (notamment au niveau du MCD).

c'est-à-dire? mettre de côté les relations réflexives, en omettant certaines de leurs avantages?

Loin de moi une telle idée !

Je vois plutôt les choses ainsi :

Considérons les deux MCD suivants (AGL Power AMC)



MCD I et MCD II vont donner lieu respectivement à MLD I et MLD II




Observations :

Dans MCD I, la cardinalité 0,1 donne lieu dans MLD I à une colonne ChefId nullable. SI l’on préfère l’auto-référence, on remplace 0,1 par 1,1.

Dans MCD II, l’association-type Hierachiser est remplacée par une entité-type Hierarchie. La cardinalité 1,1 mise entre parenthèses exprime l’identification relative, ce qui se traduit dans MLD II par le fait que PsnId est clé primaire de la table Hierarchie.

Le DDL produit par AMC est le suivant (modifier le métabolisme de la table Hierarchie comme on l’entend (Cascade) et ajouter au besoin la contrainte HieC4).

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
CREATE TABLE Personne (
  PsnId        Integer      not null
, Nom          Varchar(48)  not null    
, Fonction     Char(48)     not null   
, Constraint PsnC1 PRIMARY KEY (PsnId)
);
 
CREATE TABLE Hierarchie (
  PsnId        Integer      not null
, ChefId       Integer      not null    
, Constraint HieC1 PRIMARY KEY (PsnId)
, Constraint HieC2 Foreign key (PsnId) References Personne
, Constraint HieC3 Foreign key (ChefId) References Personne
, Constraint HieC4 check (PsnId <> ChefId)
);

Maintenant, si le directeur de projets est intransigeant et exige que la suppression d’une personne entraîne celle de ses collaborateurs, de leurs collaborateurs, jusqu’au dernier, avec MCD II il peut y avoir un léger problème d’adéquation de la programmation et du fonctionnel. Je soumets cela à votre sagacité. Rien n'est jamais acquis...