Publicité
+ Répondre à la discussion
Page 1 sur 2 12 DernièreDernière
Affichage des résultats 1 à 20 sur 30
  1. #1
    J1
    J1 est déconnecté
    Membre confirmé Avatar de J1
    Inscrit en
    mai 2004
    Messages
    257
    Détails du profil
    Informations forums :
    Inscription : mai 2004
    Messages : 257
    Points : 246
    Points
    246

    Par défaut Relation réflexive avec mise à jour/suppression en cascade

    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 :
    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 :
    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 :

    • 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.


  2. #2
    Expert Confirmé
    Avatar de Alain Defrance
    Homme Profil pro Alain DEFRANCE
    Project Lead
    Inscrit en
    août 2007
    Messages
    1 994
    Détails du profil
    Informations personnelles :
    Nom : Homme Alain DEFRANCE
    Âge : 26
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Project Lead

    Informations forums :
    Inscription : août 2007
    Messages : 1 994
    Points : 3 838
    Points
    3 838

    Par défaut

    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.

  3. #3
    J1
    J1 est déconnecté
    Membre confirmé Avatar de J1
    Inscrit en
    mai 2004
    Messages
    257
    Détails du profil
    Informations forums :
    Inscription : mai 2004
    Messages : 257
    Points : 246
    Points
    246

    Par défaut

    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 :
    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 :
    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);

  4. #4
    Expert Confirmé
    Avatar de Alain Defrance
    Homme Profil pro Alain DEFRANCE
    Project Lead
    Inscrit en
    août 2007
    Messages
    1 994
    Détails du profil
    Informations personnelles :
    Nom : Homme Alain DEFRANCE
    Âge : 26
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Project Lead

    Informations forums :
    Inscription : août 2007
    Messages : 1 994
    Points : 3 838
    Points
    3 838

    Par défaut

    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

  5. #5
    say
    say est déconnecté
    Membre Expert Avatar de say
    Inscrit en
    août 2002
    Messages
    1 175
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : août 2002
    Messages : 1 175
    Points : 1 181
    Points
    1 181

    Par défaut

    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.
    Ils ne savaient pas que c'était impossible alors ils l'ont fait (Mark Twain)
    _ _ _ _ _ _ _ _ _

    La planète ne nous appartient pas, elle nous a été prêtée par nos enfants
    _ _ _ _ _ _ _ _ _

    Technos : Access, C++ Builder, SQL, PostgreSQL, Crystal Reports, XML entre autres

  6. #6
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 390
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 390
    Points : 11 839
    Points
    11 839

    Par défaut Le diktat des SGBDR

    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 :
    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 :
    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").
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  7. #7
    J1
    J1 est déconnecté
    Membre confirmé Avatar de J1
    Inscrit en
    mai 2004
    Messages
    257
    Détails du profil
    Informations forums :
    Inscription : mai 2004
    Messages : 257
    Points : 246
    Points
    246

    Par défaut

    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 !

  8. #8
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 390
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 390
    Points : 11 839
    Points
    11 839

    Par défaut

    Bonsoir J1,

    J’observe que vous utilisez l’auto-référence : vous fournissez en effet l'exemple suivant :
    Code :
    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)...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

  9. #9
    say
    say est déconnecté
    Membre Expert Avatar de say
    Inscrit en
    août 2002
    Messages
    1 175
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : août 2002
    Messages : 1 175
    Points : 1 181
    Points
    1 181

    Par défaut

    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?

    Citation Envoyé par fsmrel Voir le message
    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?
    Ils ne savaient pas que c'était impossible alors ils l'ont fait (Mark Twain)
    _ _ _ _ _ _ _ _ _

    La planète ne nous appartient pas, elle nous a été prêtée par nos enfants
    _ _ _ _ _ _ _ _ _

    Technos : Access, C++ Builder, SQL, PostgreSQL, Crystal Reports, XML entre autres

  10. #10
    J1
    J1 est déconnecté
    Membre confirmé Avatar de J1
    Inscrit en
    mai 2004
    Messages
    257
    Détails du profil
    Informations forums :
    Inscription : mai 2004
    Messages : 257
    Points : 246
    Points
    246

    Par défaut

    Bonjour,

    Citation Envoyé par fsmrel Voir le message
    Bonsoir J1,

    J’observe que vous utilisez l’auto-référence : vous fournissez en effet l'exemple suivant :
    Code :
    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 :
    soit des lignes pour lesquelles la colonne fk n'est pas renseignée :
    (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)...

    Citation Envoyé par fsmrel Voir le message
    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.

    Citation Envoyé par fsmrel Voir le message
    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.

    Citation Envoyé par fsmrel Voir le message
    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 !

    Citation Envoyé par say Voir le message
    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 :
    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 :
    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) ?

  11. #11
    Expert Confirmé
    Avatar de Alain Defrance
    Homme Profil pro Alain DEFRANCE
    Project Lead
    Inscrit en
    août 2007
    Messages
    1 994
    Détails du profil
    Informations personnelles :
    Nom : Homme Alain DEFRANCE
    Âge : 26
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Project Lead

    Informations forums :
    Inscription : août 2007
    Messages : 1 994
    Points : 3 838
    Points
    3 838

    Par défaut

    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 ...

  12. #12
    say
    say est déconnecté
    Membre Expert Avatar de say
    Inscrit en
    août 2002
    Messages
    1 175
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : août 2002
    Messages : 1 175
    Points : 1 181
    Points
    1 181

    Par défaut

    Citation Envoyé par J1 Voir le message
    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.

    Citation Envoyé par fsmrel
    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?
    Ils ne savaient pas que c'était impossible alors ils l'ont fait (Mark Twain)
    _ _ _ _ _ _ _ _ _

    La planète ne nous appartient pas, elle nous a été prêtée par nos enfants
    _ _ _ _ _ _ _ _ _

    Technos : Access, C++ Builder, SQL, PostgreSQL, Crystal Reports, XML entre autres

  13. #13
    J1
    J1 est déconnecté
    Membre confirmé Avatar de J1
    Inscrit en
    mai 2004
    Messages
    257
    Détails du profil
    Informations forums :
    Inscription : mai 2004
    Messages : 257
    Points : 246
    Points
    246

    Par défaut

    Citation Envoyé par kazou Voir le message
    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.

    Citation Envoyé par kazou Voir le message
    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 !

    Citation Envoyé par say Voir le message
    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 !

  14. #14
    Expert Confirmé
    Avatar de Alain Defrance
    Homme Profil pro Alain DEFRANCE
    Project Lead
    Inscrit en
    août 2007
    Messages
    1 994
    Détails du profil
    Informations personnelles :
    Nom : Homme Alain DEFRANCE
    Âge : 26
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Project Lead

    Informations forums :
    Inscription : août 2007
    Messages : 1 994
    Points : 3 838
    Points
    3 838

    Par défaut

    Citation Envoyé par J1 Voir le message
    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.

  15. #15
    J1
    J1 est déconnecté
    Membre confirmé Avatar de J1
    Inscrit en
    mai 2004
    Messages
    257
    Détails du profil
    Informations forums :
    Inscription : mai 2004
    Messages : 257
    Points : 246
    Points
    246

    Par défaut

    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.

  16. #16
    say
    say est déconnecté
    Membre Expert Avatar de say
    Inscrit en
    août 2002
    Messages
    1 175
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : août 2002
    Messages : 1 175
    Points : 1 181
    Points
    1 181

    Par défaut

    Citation Envoyé par J1 Voir le message
    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.


    Citation Envoyé par J1 Voir le message
    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
    Ils ne savaient pas que c'était impossible alors ils l'ont fait (Mark Twain)
    _ _ _ _ _ _ _ _ _

    La planète ne nous appartient pas, elle nous a été prêtée par nos enfants
    _ _ _ _ _ _ _ _ _

    Technos : Access, C++ Builder, SQL, PostgreSQL, Crystal Reports, XML entre autres

  17. #17
    say
    say est déconnecté
    Membre Expert Avatar de say
    Inscrit en
    août 2002
    Messages
    1 175
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : août 2002
    Messages : 1 175
    Points : 1 181
    Points
    1 181

    Par défaut

    Citation Envoyé par J1 Voir le message
    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 :
    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.
    Ils ne savaient pas que c'était impossible alors ils l'ont fait (Mark Twain)
    _ _ _ _ _ _ _ _ _

    La planète ne nous appartient pas, elle nous a été prêtée par nos enfants
    _ _ _ _ _ _ _ _ _

    Technos : Access, C++ Builder, SQL, PostgreSQL, Crystal Reports, XML entre autres

  18. #18
    J1
    J1 est déconnecté
    Membre confirmé Avatar de J1
    Inscrit en
    mai 2004
    Messages
    257
    Détails du profil
    Informations forums :
    Inscription : mai 2004
    Messages : 257
    Points : 246
    Points
    246

    Par défaut

    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"

  19. #19
    say
    say est déconnecté
    Membre Expert Avatar de say
    Inscrit en
    août 2002
    Messages
    1 175
    Détails du profil
    Informations personnelles :
    Âge : 36

    Informations forums :
    Inscription : août 2002
    Messages : 1 175
    Points : 1 181
    Points
    1 181

    Par défaut

    Citation Envoyé par J1 Voir le message
    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
    Ils ne savaient pas que c'était impossible alors ils l'ont fait (Mark Twain)
    _ _ _ _ _ _ _ _ _

    La planète ne nous appartient pas, elle nous a été prêtée par nos enfants
    _ _ _ _ _ _ _ _ _

    Technos : Access, C++ Builder, SQL, PostgreSQL, Crystal Reports, XML entre autres

  20. #20
    Expert Confirmé Sénior
    Avatar de fsmrel
    Homme Profil pro François de Sainte Marie
    Spécialiste en bases de données
    Inscrit en
    septembre 2006
    Messages
    4 390
    Détails du profil
    Informations personnelles :
    Nom : Homme François de Sainte Marie
    Localisation : Autre

    Informations professionnelles :
    Activité : Spécialiste en bases de données
    Secteur : Conseil

    Informations forums :
    Inscription : septembre 2006
    Messages : 4 390
    Points : 11 839
    Points
    11 839

    Par défaut

    Attendez-moi, vous allez trop vite !


    Citation Envoyé par J1
    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...


    Citation Envoyé par J1
    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 :
    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);

    Citation Envoyé par J1
    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...



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

    Code :
    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 :
    1
    2
    3
    4
    Nom     NomDuSuperieur
    -----------
    Col.T   NULL
    Col.H   Col.T
    Certes ! Mais...


    Citation Envoyé par J1
    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)".



    Citation Envoyé par J1
    soit des lignes pour lesquelles la colonne fk n'est pas renseignée :
    (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 :
    Citation Envoyé par say
    Citation Envoyé par fsmrel
    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 :
    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...
    Faites simple, mais pas plus simple ! (A. Einstein)
    E=mc², mais si on discute un peu, on peut l’avoir pour beaucoup moins cher... (G. Lacroix, « Les Euphorismes de Grégoire »)
    => La relativité n'existerait donc que relativement aux relativistes (Jean Eisenstaedt, « Einstein et la relativité générale »)


    De grâce, pas de questions techniques par MP, ma boîte de réception explose !
    __________________________________
    Bases de données relationnelles et normalisation : de la première à la sixième forme normale (Bonne lecture !)

Liens sociaux

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •