IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Schéma Discussion :

Gestion de la recursivité sur les commentaires


Sujet :

Schéma

  1. #61
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    Bonjour,

    Merci pour cette proposition qui me paraît judicieuse

    J'ai donc appliqué les modifications sur le MCD (en PJ V 3.1)

    Côté MCD, j'ai procédé à :

    • une suppression de "id_possibilite" sur choisir_poss
    • Un passage en alternative key sur "fichier_gps_avec_article"


    J'ai une différence sur le MPD après ajout de l'alternative key :



    Ensuite, lors de la génération du MLD, trois erreurs surviennent :




    Pour l'erreur sur la jointure, lorsque je supprime "id_possibilite" de "choisir-poss", le logiciel me dit que "id_possibilite" est utilisé comme jointure de référence et me demande si je souhaite la remplacer par une autre colonne. j'imagine qu'il est nécessaire d'effectuer une manipulation à ce moment. qu'en est-il ?

    Pour les deux autres erreurs, je n'ai pas d'idée.

    Ci-joint également le MPD.

    Par avance merci pour vos lumières !


  2. #62
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par heretik25 Voir le message
    Côté MCD, j'ai procédé à :
    une suppression de "id_possibilite" sur choisir_poss
    [...]
    Pour l'erreur sur la jointure, lorsque je supprime "id_possibilite" de "choisir_poss", le logiciel me dit que "id_possibilite" est utilisé comme jointure de référence et me demande si je souhaite la remplacer par une autre colonne. j'imagine qu'il est nécessaire d'effectuer une manipulation à ce moment. qu'en est-il ?
    La table SONDAGE_POSSIBILITE a pour clé primaire la paire {id_article, id_possibilite}, donc toute référence à cette table doit nécessairement comporter cette paire d’attributs, ce qui est le cas pour la table CHOISIR_POSS : en y supprimant l’attribut id_possibilite, vous ne pouvez que vous attirer les foudres de Power AMC...

    Souvenez-vous de ce que j’ai écrit ici :
    Citation Envoyé par fsmrel Voir le message
    Power AMC ne proposant rien au sujet des CIF et autres DF, j’ai dessiné à la main une contrainte d’unicité, une dépendance fonctionnelle (DF) entre l’association-type CHOISIR_POSS et l’entité-type POSSIBILITE. Cette contrainte exprime le fait que pour un utilisateur et un article, il n’y a qu’un seul choix possible. En conséquence, il faut intervenir manuellement dans le MLD, à savoir expulser l’attribut PossibiliteId de la clé primaire de la table CHOISIR_POSS.
    Il ne faut donc pas supprimer l’attribut id_possibilite de la table CHOISIR_POSS, il faut seulement l’expulser de la clé primaire :



    Citation Envoyé par heretik25 Voir le message
    J'ai une différence sur le MPD après ajout de l'alternative key
    Forcément... Souvenez-vous :
    Citation Envoyé par fsmrel Voir le message
    A noter qu’il a fallu intervenir manuellement pour rendre correct le système des clés de la table FICHIER_GPS_AVEC_ART : évacuer l’attribut ArticleId de la clé primaire et en faire une clé à part entière (clé alternative, alternate key) symbolisée par le mickey <ak>.
    Manifestement vous avez mangé la consigne. Ouvrez à nouveau la fenêtre Propriétés de la table FICHIER_GPS_AVEC_ART, onglet Clés, puis onglet Colonnes. On voit que vous avez conservé l’attribut id_article dans la clé qui doit être primaire :


    Il faut donc rattraper le coup, en éliminant cet attribut de la clé FICHIER_GPS_AVEC_ART_PK et seul doit rester dans celle-ci l’attribut id_fichier_gps :


    Ceci fait, s’assurer que la case « P » (clé primaire) est toujours bien cochée pour la clé FICHIER_GPS_AVEC_ART_PK :

    Onglet « Colonnes » :



    Citation Envoyé par heretik25 Voir le message
    Pour les deux autres erreurs, je n'ai pas d'idée.
    S’il s’agit de l’erreur « Colonne de table », il faut décocher la case « Identity » pour la colonne id_coord_gps de la table COORDONNEES_GPS. En effet, l’incrément automatique est déjà utilisé pour la colonne id_fichier_gps (table FICHIER_GPS), laquelle est référencée par la colonne id_fichier_gps de la table COORDONNEES_GPS :


    En fait, il suffit d'agir au niveau du MCD, en remplaçant le type « Séquentiel » par le type « int » pour l’attribut id_coord_gps de l’entité-type COORDONNEES_GPS.

    Même principe en ce qui concerne la colonne id_statistique (entité-type STATISTIQUES).

  3. #63
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    Bonsoir et merci pour votre patience

    Voici en PJ, le MCD, le MPD et le MLD=>en pdf ainsi que le SQL généré.


    NB : Le SQL généré passe parfaitement sur une base mysql 5.0.


  4. #64
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut
    Bonsoir à nouveau,


    Citation Envoyé par heretik25 Voir le message
    Le SQL généré passe parfaitement sur une base mysql 5.0.
    Voilà une nouvelle qu’elle est bonne !

    A noter quand même : il y a encore des attributs à NULL (cf. association-type NOTER_ARTICLE, entité-type SECTEUR).

    Concernant le métabolisme des données :

    A moins qu’une table fasse référence à la table ARTICLE et contienne une ligne qui s’y oppose formellement, quand on supprime un article, on le supprime !

    Comme vous avez codé (ou laissé Power AMC coder par défaut) :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    ALTER TABLE ARTICLE_PAGE ADD CONSTRAINT FK_COMPOSER FOREIGN KEY (ID_ARTICLE)
                REFERENCES ARTICLE (ID_ARTICLE) ON DELETE RESTRICT ON UPDATE RESTRICT ;
    Alors si un article contient des pages, il faudra d’abord supprimer celles-ci (et bien sûr tout ce qui référence aussi l'article) avant de pouvoir supprimer l’article lui-même, car la clause « ON DELETE RESTRICT » signifie ceci : « Nous les pages, refusons que l’article meure tant qu’on ne nous aura pas d’abord nommément supprimées ». Si à la place vous utilisez la clause « ON DELETE CASCADE », l’attitude des pages changera : « Nous les pages, ne sommes que d’humbles propriétés de l’article, donc si celui-ci doit mourir, quelle résistance serions-nous en droit d’opposer à sa destruction ? » On voit bien que d’un point de vue sémantique, une page est une propriété de l’article, au même titre que le libellé de l’article, la seule différence étant que le libellé est une propriété monovaluée alors que les pages constituent une propriété multivaluée. Si un article doit mourir, ses pages doivent mourir sans regimber.

    Prenons maintenant l’exemple de la table ART_PERIPLE. Ce qui est retenu actuellement :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    ALTER TABLE ART_PERIPLE ADD CONSTRAINT FK_____ FOREIGN KEY (ID_SECTEUR_PERIPLE)
          REFERENCES SECTEUR (ID_SECTEUR_PERIPLE) ON DELETE RESTRICT ON UPDATE RESTRICT ;
    Si elle n’est pas vide, la table ART_PERIPLE ne contient qu’une seule ligne et celle-ci n’a aucune raison de s’opposer à sa destruction au cas où on supprime l’article qu’elle référence. En effet, elle correspond à une propriété monovaluée de l’article, mais externalisée parce que facultative : la clause à utiliser est « ON DELETE CASCADE ».

    A titre d’exercice, je vous laisse le soin de dresser l’inventaire des tables pour lesquelles la clause « ON DELETE RESTRICT » est à remplacer « ON DELETE CASCADE ». Je vérifierai... L’exercice en vaut la peine, donc, courage !

    D’une manière générale, disons que si l’on code systématiquement « ON DELETE RESTRICT », du point de vue opératoire on a comme les pieds pris dans le béton, le système est pratiquement figé, les opérations de suppression sont très, très, très lourdes, d’où l’intérêt d’user (sans abuser !) du CASCADE.

    Vous me direz : Et « ON UPDATE » ? Comme on utilise des valeurs de clés qui sont des invariants, on n’a aucune raison de remplacer ces valeurs : en principe, on n’a jamais à coder « ON UPDATE CASCADE ». En tout cas, au cours de bien longues années, jamais je n’ai eu besoin de le faire.

    A bientôt (et n'oubliez pas de voter) !

  5. #65
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    Bonjour,

    Après réflexion je dirai que les tables suivantes sont concernées :

    • article_page
    • article_categorie
    • article_periple
    • article_balade
    • article_test
    • article_entretien
    • sondage
    • noter_article
    • commentaire
    • commentaire_article
    • commentaire_livre_or
    • commentaire_commente
    • fichier_gps
    • coordonnees_gps
    • statistiques


    J'ai des doutes concernant :


    • mot_cle => comment gérer le fait qu'un mot clé puisse-être attaché à un ou plusieurs articles ? Imaginons que je supprime un article qui était valorisé par le mot clé "vtt". Il pourrait être tentant supprimer le mot clé VTT dans la table "mot_cle" sauf que ce mot clé est sûrement attaché à un autre article. Comment faire ?
    • utilisateurs => Peut-on être en mesure de supprimer ou pas toutes les contributions d'un utilisateur si l'utilisateur est supprimé. Peut-on donner le choix ?


    ------------------------------------------

    De plus, je viens de me rendre compte que la table "categorie" ainsi que "sous_categorie" pouvaient être remplacées avantageusement si je mettais une entité-type "sous_type_article".

    Ainsi, l'article de type "Balade" peu possèder un sous type "Randonnée" ou bien encore "VTT"...

    MCD :



    Qu'en pensez-vous ?

    @bientôt

  6. #66
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par heretik25 Voir le message
    je viens de me rendre compte que la table "categorie" ainsi que "sous_categorie" pouvaient être remplacées avantageusement si je mettais une entité-type "sous_type_article".
    Ainsi, l'article de type "Balade" peu posséder un sous type "Randonnée" ou bien encore "VTT"...
    D’accord, mais dans ces conditions je suppose que l’entité-type ARTICLE est en relation avec l’entité-type SOUS_TYPE_ARTICLE et non pas TYPE_ARTICLE, sinon comment savoir que c’est une randonnée qui est relatée dans un article plutôt que quelque chose concernant le VTT ou autre ?


    Citation Envoyé par heretik25 Voir le message
    J'ai des doutes concernant :
    mot_cle => comment gérer le fait qu'un mot clé puisse-être attaché à un ou plusieurs articles ? Imaginons que je supprime un article qui était valorisé par le mot clé "vtt". Il pourrait être tentant supprimer le mot clé VTT dans la table "mot_cle" sauf que ce mot clé est sûrement attaché à un autre article. Comment faire ?
    Considérez la structure est la suivante :


    La traduction SQL est la suivante :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    ALTER TABLE ARTICLE_AVOIR_MOT_CLE ADD CONSTRAINT FK_ARTICLE_AVOIR_MOT_CLE FOREIGN KEY (ID_ARTICLE)
          REFERENCES ARTICLE (ID_ARTICLE) ON DELETE CASCADE ON UPDATE RESTRICT ;
     
    ALTER TABLE ARTICLE_AVOIR_MOT_CLE ADD CONSTRAINT FK_ARTICLE_AVOIR_MOT_CLE2 FOREIGN KEY (ID_MOT_CLE)
          REFERENCES MOT_CLE (ID_MOT_CLE) ON DELETE RESTRICT ON UPDATE RESTRICT ;

    Par définition, seules les tables qui font référence à une table T reçoivent les stimuli émis par T.

    Ainsi, la table ARTICLE_AVOIR_MOT_CLE reçoit les stimuli émis par la table ARTICLE (DELETE FROM ARTICLE) d’une part, et les stimuli émis par la table MOT_CLE (DELETE FROM MOT_CLE) d’autre part.

    Si on supprime un article, un stimulus part à destination de la table ARTICLE_AVOIR_MOT_CLE, et du fait de la clause CASCADE les lignes impliquées devront accepter de mourir, si rien par ailleurs n’empêche l’article d’être supprimé (c'est-à-dire si aucune autre table recevant un stimulus n’émet de veto). Mais, par construction, parce qu’elle ne fait pas référence à la table ARTICLE_AVOIR_MOT_CLE les stimuli ne se propagent pas jusqu’à la table MOT_CLE : le mot-clé « vtt » n’y sera donc pas supprimé.

    De l’autre côté, si on cherche à supprimer le mot-clé « vtt » directement dans la table MOT_CLE (DELETE FROM MOT_CLE WHERE mot_cle_intitule = "vtt"), la table ARTICLE_AVOIR_MOT_CLE recevra un stimulus, mais du fait de la clause RESTRICT, si au moins une ligne de la table ARTICLE_AVOIR_MOT_CLE est impliquée, la réaction sera sèche et violente, la tentative de suppression échouera. Si aucune ligne de la table ARTICLE_AVOIR_MOT_CLE n’est impliquée, l’opération réussira.

    __________________

    Passons maintenant à vos propositions de CASCADE :

    • Table ARTICLE_PAGE : D’accord.
    • Table STATISTIQUES : D’accord, mais il y a une ambiguïté car cette table référence deux tables, à savoir ARTICLE_PAGE et UTILISATEUR, il faut donc préciser pour chaque référence la clause retenue, CASCADE ou RESTRICT.
    • Table ART_CATEG : D’accord.
    • Table ART_PERIPLE : D’accord.
    • Table ART_BALADE : D’accord.
    • Table TEST : D’accord.
    • Table ENTRETIEN : D’accord.

    Mais, pour ces 5 dernières tables, il est entendu que ce « D'accord » concerne les stimuli émis par la table ARTICLE. Il est clair que les tentatives de suppression portant sur les tables ENTRETIEN_DIFFICULTE, ENTRETIEN_DUREE, CATEGORIE, DEPARTEMENT, SECTEUR, TEST_MARQUE, échoueront (du fait d’un RESTRICT tout à fait opportun).
    • Table SONDAGE : d’accord. Mais en acceptant de mourir, cette table émet à son tour un stimulus que va recevoir la table SONDAGE_POSSIBILITE parce qu'elle a une référence à SONDAGE : que choisissez-vous comme option pour cette référence ?
    • Table SONDAGE_CHOISIR_POSSIBILITE : vous n’avez rien précisé, mais ne pensez-vous pas que la suppression d’un utilisateur entraîne la suppression des lignes SONDAGE_CHOISIR_POSSIBILITE qui le référencent ?
    • Table COMMENTAIRE : d’accord.
    • Table COMMENTAIRE_LIVRE_OR : d’accord.
    • Table COMMENTAIRE_ARTICLE : d’accord, mais la clause CASCADE porte sur quelle référence ? à COMMENTAIRE ? à ARTICLE ? S’il y a CASCADE des deux côtés, il faut le prévoir.
    • Table COMMENTAIRE_COMMENTE : il y a deux références à COMMENTAIRE_ARTICLE. Question : CASCADE pour l’une ? pour les deux ?
    • Table GPS : pas d’accord, en effet elle ne référence aucune autre table...
    • Table COORDONNEES_GPS : d’accord.

    Que décidez-vous pour les tables FICHIER_GPS_AVEC_ARTICLE et FICHIER_GPS_SANS_ARTICLE ? (attention, pour chacune de ces tables, il y a deux références).


    Citation Envoyé par heretik25 Voir le message
    J'ai des doutes concernant :
    utilisateurs => Peut-on être en mesure de supprimer ou pas toutes les contributions d'un utilisateur si l'utilisateur est supprimé. Peut-on donner le choix ?
    Si je comprends bien vous souhaiteriez qu’à l’occasion de la suppression d’un utilisateur, soit on supprime tous les articles qu’il a rédigés, soit on supprime l’utilisateur, mais on conserve ses articles. C’est bien cela ? Je vais regarder ce qu’on peut faire.


    N.B. Table COMMENTAIRE_COMMENTE : pour éviter des confusions plus tard, je vous conseille de renommer l’attribut id_commentaire en id_commentant et l'attribut com_id_commentaire en id_commented (ou tous autres noms permettant d'éviter la confusion...)

    On y arrivera

  7. #67
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    Bonjour, encore merci pour ces réponses,

    D’accord, mais dans ces conditions je suppose que l’entité-type ARTICLE est en relation avec l’entité-type SOUS_TYPE_ARTICLE et non pas TYPE_ARTICLE, sinon comment savoir que c’est une randonnée qui est relatée dans un article plutôt que quelque chose concernant le VTT ou autre ?
    Pris dans ce sens là, ça pourrait-être le cas. Seulement, un type d'article n'a pas toujours un sous type. Une présentation est un article mais il n'a pas de sous type. Une balade est un type d'article est peut posséder plusieurs sous types (à pied, à vtt en kayak...). Ainsi, si je mets en relation l'entité SOUS_TYPE_ARTICLE avec ARTICLE, et que je souhaite créer un article présentation, il y aura un souci. (A moins que je me trompe, ce qui est probable )

    Si l'on passe dans le concret, on peut imaginer que le choix du type de l'article se fera via une liste déroulante et le sous-type, si le type en possède, se mettra à jour dans une seconde liste.

    Qu'en pensez-vous ?

    Ok, merci pour cette explication.

    Récapitulons les contraintes ON CASCADE à appliquer sur les différentes tables suivantes :


    • ARTICLE_AVOIR_MOT_CLE => REFERENCE de la table ARTICLE
    • ARTICLE_PAGE => REFERENCE de la table ARTICLE
    • ARTICLE_CATEG => REFERENCE de la table ARTICLE
    • ARTICLE_PERIPLE => REFERENCE de la table ARTICLE
    • ARTICLE_BALADE => REFERENCE de la table ARTICLE
    • ARTICLE_TEST => REFERENCE de la table ARTICLE
    • ARTICLE_ENTRETIEN => REFERENCE de la table ARTICLE
    • COMMENTAIRE => REFERENCE de la table UTILISATEUR
    • COMMENTAIRE_LIVRE_OR => REFERENCE de la table COMMENTAIRE
    • COORDONNEES_GPS => REFERENCE de la table FICHIER_GPS



    Cas particuliers :

    STATISTIQUES : D’accord, mais il y a une ambiguïté car cette table référence deux tables, à savoir ARTICLE_PAGE et UTILISATEUR, il faut donc préciser pour chaque référence la clause retenue, CASCADE ou RESTRICT.
    Si un article est supprimé toutes les statistiques liés à ce dernier doivent être supprimés.

    Je propose donc deux ON CASCADE :

    • STATISIQUES => REFERENCE de la table ARTICLE_PAGE
    • STATISIQUES => REFERENCE de la table UTILISATEUR



    Table SONDAGE_CHOISIR_POSSIBILITE : vous n’avez rien précisé, mais ne pensez-vous pas que la suppression d’un utilisateur entraîne la suppression des lignes SONDAGE_CHOISIR_POSSIBILITE qui le référencent ?
    Effectivement, on supprime ses possibilités via un ON CASCADE :

    • SONDAGE_CHOISIR_POSSIBILITE => REFERENCE de la table UTILISATEUR


    Table COMMENTAIRE_ARTICLE : d’accord, mais la clause CASCADE porte sur quelle référence ? à COMMENTAIRE ? à ARTICLE ? S’il y a CASCADE des deux côtés, il faut le prévoir.
    Si on supprime l'article, tous les commentaires sont supprimés.
    Si on supprime un commentaire la référence à l'ARTICLE est supprimé

    Je propose deux DELETE ON CASCADE sur :
    • COMMENTAIRE_ARTICLE => REFERENCE de la table COMMENTAIRE
    • COMMENTAIRE_ARTICLE => REFERENCE de la table ARTICLE


    Table COMMENTAIRE_COMMENTE : il y a deux références à COMMENTAIRE_ARTICLE. Question : CASCADE pour l’une ? pour les deux ?
    Si un commentaire commentant est supprimé on ne supprime pas le commentaire d'origine (le commenté),
    Si un commentaire commenté est supprimé, on supprime tous les commentaires le commentant.

    piou, pas facile !

    On a donc un RESTRICT et un CASCADE si j'ai bien compris ?

    • COMMENTAIRE_COMMENTE REFERENCE ON RESTRICT (id_commentant)
    • COMMENTAIRE_COMMENTE REFERENCE ON CASCADE (id_commented)



    Table GPS : pas d’accord, en effet elle ne référence aucune autre table...
    Si un article contenant un fichier gps est supprimé, on supprime effectivement toutes les coordonnées mais aussi toutes les données dans fichiers_gps se rapportant à l'article.

    Est-ce que la modélisation est mauvaise ?

    EN PJ, le mcd 3.3
    @bientôt

    P.S : Oui on va y arriver !

  8. #68
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut Fchier GPS et Delete
    Bonjour,

    Je ne réponds pas à toutes les questions en même temps, car je ne vais pas être totalement disponible (un pot est en route ).

    Dans un premier temps, allons-y pour la partie GPS.

    Citation Envoyé par heretik25 Voir le message
    Si un article contenant un fichier gps est supprimé, on supprime effectivement toutes les coordonnées mais aussi toutes les données dans fichiers_gps se rapportant à l'article.

    Est-ce que la modélisation est mauvaise ?
    La modélisation n’est pas mauvaise. En effet, souvenez-vous, on a remplacé la modélisation initiale :

    Par celle-ci, puisqu’un fichier GPS ne référence pas toujours un article :


    Pour être complet, en toute logique le métabolisme des données devrait être le suivant (Cascade partout) :



    Si donc, quand on supprime un article, disons de clé ArticleId = 314, il faut que soit aussi supprimé le fichier GPS qui le référence, alors il faudra procéder en deux temps :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    DELETE  FROM FICHIER_GPS
    WHERE   IdFichierGps = (SELECT IdFichierGps
                            FROM   FICHIER_GPS_AVEC_ARTICLE
                            WHERE  IdArticle = 314) ;
    DELETE  FROM ARTICLE
    WHERE   IdArticle = 314 ;

    En utilisant une vue de jointure, on pourrait n’avoir qu’un seul Delete qui s’appliquerait à cette vue, intercepté par un trigger ventilant ce Delete sur les tables, mais je crois me souvenir que les triggers et les vues ne font pas bon ménage avec MySQL...

    En tout cas, ce qui vaut pour la suppression d’un article vaut également pour la suppression d’un utilisateur, mutatis mutandis comme dit mon voisin qui en connaît un rayon sur le ménage en deux temps, trois mouvements... :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    DELETE  FROM FICHIER_GPS
    WHERE   IdFichierGps IN (SELECT IdFichierGps
                             FROM   FICHIER_GPS_SANS_ARTICLE
                             WHERE  IdUtilisateur = 123) ;
    DELETE  FROM UTILISATEUR
    WHERE   IdUtilisateur = 123 ;

    A plus pour la suite...

  9. #69
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut Commentaires et suppression récursive
    Bonsoir,


    Allons-y pour les commentaires :

    Citation Envoyé par heretik25 Voir le message
    Si un commentaire commentant est supprimé on ne supprime pas le commentaire d'origine (le commenté),
    Si un commentaire commenté est supprimé, on supprime tous les commentaires le commentant.
    piou, pas facile !
    On a donc un RESTRICT et un CASCADE si j'ai bien compris ?

    COMMENTAIRE_COMMENTE REFERENCE ON RESTRICT (id_commentant)
    COMMENTAIRE_COMMENTE REFERENCE ON CASCADE (id_commented)
    Une première chose : Reprenons l’exemple des mots-clés :


    il faut se souvenir que lorsqu’une table « parente » (par exemple ARTICLE) envoie ses stimuli, les tables « enfants » (par exemple ARTICLE_AVOIR_MOT_CLE) les reçoivent et les propagent vers leurs propres enfants, mais pas vers leurs parents : ainsi, la table MOT_CLE ne reçoit aucun stimulus à l’occasion de la suppression d’un article.

    Passons aux commentaires :


    Si on code une instruction DELETE FROM COMMENTAIRE_ARTICLE WHERE IdCommentaire = 3 ; un stimulus part à destination de la table COMMENTAIRE_COMMENTE, mais comme dans le cas des mots-clés, le stimulus ne remonte pas vers la table COMMENTAIRE_ARTICLE : un CASCADE ne permet donc pas de supprimer les commentaires faits sur le commentaire 3, seuls les liens matérialisés dans la table COMMENTAIRE_COMMENTE seront supprimés.

    Cette configuration est la bonne quand par exemple on gère la hiérarchie des personnes dans une entreprise. Si Albert est au niveau N et si Pierrot est son N+1, il est hors de question que la disparition de Pierrot laisse Albert orphelin et la structure acceptable correspond au diagramme ci-dessous : Si Albert disparaît de la table PERSONNE, il disparaît aussi de la table HIERARCHIE, sauf s’il est N+1 par rapport à quelqu’un d’autre. Même chose pour Pierrot, lequel ne pourra disparaître que lorsqu’Albert aura préalablement disparu de la hiérarchie :


    Ainsi, si on vire le PDG, il faudra d’abord le remplacer sinon tous ses N-1 seront orphelins, désemparés et ça pourrait devenir le bazar... C’est dans ce sens que j’ai interprété les commentaires : pouvoir supprimer un commentaire sauf s’il est commenté...

    Mais vous souhaitez donc pour votre part que la suppression d’un commentaire entraîne la suppression de ceux qui en dépendent, que ce soit directement ou indirectement : on est confronté à la mise en œuvre d’un traitement récursif.

    Par exemple, dans le contexte de SQL Server, on peut utilise une union récursive hébergée au sein d’une fonction. Reprenons les commentaires :


    Les tables ont les structures suivantes (notez le « ON DELETE CASCADE ») :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    CREATE TABLE COMMENTAIRE_ARTICLE (
           id_commentaire       INT                  NOT NULL
         , id_article           INT                  NOT NULL
       , CONSTRAINT COMMENTAIRE_PK PRIMARY KEY  (id_commentaire)
    ) ;
    CREATE TABLE COMMENTAIRE_COMMENTE (
           id_commentant   INT       NOT NULL         -- Rôle : commentant 
         , id_commented    INT       NOT NULL         -- Rôle : commenté
       , CONSTRAINT COMM_COMM_PK PRIMARY KEY (id_commentant)  
       , CONSTRAINT COMM_COMM_COMMENTANT_FK FOREIGN KEY (id_commentant)
                    REFERENCES COMMENTAIRE_ARTICLE (id_commentaire) ON DELETE CASCADE
       , CONSTRAINT COMM_COMM_COMMENTED_FK FOREIGN KEY (id_commented)
                    REFERENCES COMMENTAIRE_ARTICLE (id_commentaire) ON DELETE NO ACTION) ;
    Et les valeurs de ces tables sont par exemple les suivantes :

    Table COMMENTAIRE_ARTICLE :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    id_commentaire    id_article   
                 1             2
                 2             1
                 3             2
                 4             3
                 5             2
                 6             4
                 7             2
                 8             2
                 9             1
                10             2
                12             1
                13             1
                15             2
    Table COMMENTAIRE_COMMENTE :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    id_commentant    id_commented
                3               1
                5               3
                7               5
                8              15
                9               2
               10               1
               12               9
               13              12
               15               3
    La fonction (SQL Server) hébergeant l’union récursive peut ressembler à ceci :

    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
    15
    16
    17
    CREATE FUNCTION DESCENDANCE_FONCTION (@id_commentaire INT)
        RETURNS @Resultat TABLE (id_commentaire INT Not Null)
        AS 
            BEGIN
               WITH DESCENDANCE (id_commentaire) AS
                   ((SELECT   id_commentaire
                     FROM     COMMENTAIRE_ARTICLE  
                     WHERE    id_commentaire = @id_commentaire)
                     UNION ALL
                    (SELECT   x.id_commentant 
                     FROM     COMMENTAIRE_COMMENTE AS x JOIN DESCENDANCE AS y
                              ON y.id_commentaire = x.id_commented))
               INSERT INTO @Resultat 
                          SELECT id_commentaire
                          FROM   DESCENDANCE ;
               RETURN 
            END
    Pour supprimer le commentaire 3 et tous ceux qui en dépendent, on met cette fonction à profit :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    DELETE FROM  COMMENTAIRE_ARTICLE
           WHERE id_commentaire IN (SELECT  id_commentaire
                                    FROM    DESCENDANCE_FONCTION(3));
    Au résultat, voici ce qu’il reste de la table COMMENTAIRE_ARTICLE :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
        
    id_commentaire    id_article 
                 1             2 
                 2             1 
                 9             1
                10             2
                12             1
                13             1
    Et ce qu’il reste de la table COMMENTAIRE_COMMENTE :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    id_commentant    id_commented
                9             2
               10             1
               12             9
               13            12
    Le contenu de la fonction peut vous surprendre... Les lignes 5 à 12 correspondent à ce que l’on appelle une CTE (Common Table Expression), dont on peut se servir avec SQL Server, DB2, Oracle, PostgreSQL (et j’en oublie), mais pas avec MySQL si je ne m’abuse . Il vous resterait donc à pleurer, vous plonger dans les papiers de SQLpro, ou peut-être externaliseriez-vous la récursivité dans un de vos programmes. Mais, si à l’instar de DB2, MySQL vous permet la structure suivante (table auto-référençante + clause Cascade laquelle est du reste interdite avec SQL Server, ou ) :


    Alors la table COMMENTAIRE_ARTICLE absorbe la table COMMENTAIRE_COMMENTE et grâce à la clause Cascade vous sous-traitez au SGBD la récursivité des suppressions.

    Moralité : la modélisation des données peut être impactée par les possibilités qu’offrent les SGBD...
    __________________________

    J'essaie de regarder la suite...

  10. #70
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut
    Citation Envoyé par heretik25 Voir le message
    Peut-on être en mesure de supprimer ou pas toutes les contributions d'un utilisateur si l'utilisateur est supprimé. Peut-on donner le choix ?
    Je comprends ceci, en espérant ne pas être à côté de la plaque :
    — 1er cas : quand on supprime l’utilisateur Louis les articles qu’il a rédigés doivent aussi disparaître.
    — 2e cas : quand on supprime l’utilisateur Louis, on conserve les articles qu’il a rédigés.
    Si c’est bien ce que vous voulez, alors le choix est possible, mais à condition de faire évoluer la modélisation comme ci-dessous :

    Diagramme conceptuel

    Diagramme logique



    Si on veut supprimer l’utilisateur Louis ainsi que ses articles, la suppression devra se faire en deux temps :
    1) Supprimer ses articles,
    2) Supprimer l’utilisateur.
    Si l’on veut supprimer seulement l’utilisateur, on se contente d’effectuer la 2e opération, (les stimuli à destination de la table ARTICLE_UTIL ne se propagent pas jusqu’à la table ARTICLE).

    Pour être sûr de ne rien oublier au cas où l’on supprime l’utilisateur plus ses articles, on peut prévoir une procédure stockée prenant en compte les deux possibilités (variable @UtilisateurId prenant par exemple la valeur ‘tout' ou quelque chose de différent de ‘tout'). Dans le style de SQL Server :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    CREATE PROCEDURE SUPPRIMER_UTILISATEUR
              @UtilisateurId   INT 
            , @ArticleAussi    CHAR(4) 
        AS
           IF  @ArticleAussi = 'tout' 
               BEGIN 
                  DELETE  FROM ARTICLE 
                          WHERE   Id_article IN (SELECT Id_article
                                                 FROM   ARTICLE_UTIL 
                                                 WHERE  Id_utilisateur = @UtilisateurId) ;
               END
           DELETE  FROM UTILISATEUR
           WHERE   Id_utilisateur = @UtilisateurId ;
    Pour supprimer l’utilisateur Louis d’identifiant 2718, ainsi que ses articles :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    EXECUTE SUPPRIMER_UTILISATEUR 2718, 'tout' ;
    Pour supprimer Louis sans supprimer ses articles :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    EXECUTE SUPPRIMER_UTILISATEUR 2718, 'xxxx' ;

    A cette occasion on peut revenir sur la nouvelle structure concernant les fichiers GPS. En effet, j’ai précédemment parlé là aussi de procéder en deux temps :
    Citation Envoyé par fsmrel Voir le message
    Si donc, quand on supprime un article, disons de clé Id_article = 314, il faut que soit aussi supprimé le fichier GPS qui le référence, alors il faudra procéder en deux temps :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    DELETE  FROM  FICHIER_GPS
            WHERE Id_Fichier_Gps = (SELECT Id_Fichier_Gps
                                    FROM   FICHIER_GPS_AVEC_ARTICLE
                                    WHERE  Id_article = 314) ;
    DELETE  FROM ARTICLE
            WHERE Id_article = 314 ;
    Regardons maintenant la nouvelle organisation des relations entre utilisateurs et articles, augmentée de l’organisation des fichiers GPS :

    Pour automatiser la suppression de leurs fichiers GPS quand on supprime des utilisateurs, et/ou leurs articles, on peut enrichir la procédure stockée et supprimer aussi les fichiers GPS rattachés aux utilisateurs :
    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
    15
    16
    17
    CREATE PROCEDURE SUPPRIMER_UTILISATEUR
              @UtilisateurId   INT 
            , @ArticleAussi    CHAR(4)      
        AS
           IF  @ArticleAussi = 'tout' 
               BEGIN 
                  DELETE  FROM ARTICLE 
                          WHERE   Id_article IN (SELECT Id_article
                                                 FROM   ARTICLE_UTIL 
                                                 WHERE  Id_utilisateur = @UtilisateurId) ;
               END
           DELETE  FROM FICHIER_GPS
           WHERE   Id_Fichier_Gps IN (SELECT Id_Fichier_Gps
                                      FROM   FICHIER_GPS_SANS_ART 
                                      WHERE  Id_utilisateur = @UtilisateurId) ;
           DELETE  FROM UTILISATEUR
           WHERE   Id_utilisateur = @UtilisateurId ;

    En ce qui concerne les suppressions d’articles, on peut utiliser le trigger suivant (SQL Server) qui intercepte les DELETE FROM ARTICLE et complète avec la suppression des fichiers GPS :

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    CREATE TRIGGER ARTICLE_TRIGGER_DELETE ON ARTICLE INSTEAD OF DELETE AS
        DELETE  FROM FICHIER_GPS
        WHERE   Id_Fichier_Gps IN (SELECT Id_Fichier_Gps
                                   FROM   FICHIER_GPS_AVEC_ART AS x JOIN DELETED AS y
                                          ON x.Id_article = y.Id_article) ;
        DELETE  FROM ARTICLE 
        WHERE   Id_article IN (SELECT Id_article
                               FROM   DELETED)

  11. #71
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    Bonjour et merci pour ces nombreuses réponses qui ressemblent à un véritable tutoriel.

    Merci pour la précision et les exemples de requêtes à produire pour nettoyer l'ensemble des données inhérentes au fichier GPS.
    ------------------------------------------------------------


    Pour les commentaires, je ne pensais pas qu'en proposant les règles de gestion suivantes, nous allions nous retrouver face à un souci majeur.

    Ne pourrait-on pas simplifier la chose si l'on disait que dès lors qu'un commentaire à été commenté, ce dernier ne peut plus être supprimé ?

    Je comprends ceci, en espérant ne pas être à côté de la plaque :

    — 1er cas : quand on supprime l’utilisateur Louis les articles qu’il a rédigés doivent aussi disparaître.
    — 2e cas : quand on supprime l’utilisateur Louis, on conserve les articles qu’il a rédigés.

    Si c’est bien ce que vous voulez, alors le choix est possible, mais à condition de faire évoluer la modélisation comme ci-dessous :
    C'est exactement ça et j'ai modifié en conséquent le MCD.
    Pourriez-vous m'expliquer rapidement en quoi la création de l'entité-type "article_util" permet de garder ou supprimer les articles d'un utilisateur souhaitant se désinscrire ?

    EDIT : Ajout d'une capture avec les contraintes :



    Merci de me dire s'il y a un souci quelque part !

    P.S : Pouvez-vous aussi me dire en passant comment vous feriez avec les entités "type_article" et "sous_type_article" ?


    En PJ, le MCD en V 3.5 ainsi que son MPD
    @bientôt.

  12. #72
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par heretik25 Voir le message
    Pour les commentaires, je ne pensais pas qu'en proposant les règles de gestion suivantes, nous allions nous retrouver face à un souci majeur.
    Du point de vue du Modèle Relationnel de Données de Codd il n’y a pas de souci ! En revanche, les SGBD ont attaqué le problème chacun à leur façon, avec plus ou moins de bonheur, voyez la discussion qui met en cause DB2...
    Quoi qu’il en soit, il y a toujours une solution et j’ai montré que l’on pouvait franchir les obstacles inutilement mis en place dans le cas de SQL Server (SGBD dont les auteurs et développeurs feraient bien de lire la page 224 de Database Explorations, Essays on The Third Manifesto and Related Topics).


    Citation Envoyé par heretik25 Voir le message
    Ne pourrait-on pas simplifier la chose si l'on disait que dès lors qu'un commentaire à été commenté, ce dernier ne peut plus être supprimé ?
    Je complète ainsi la phrase : « [...] ce dernier ne peut pas être supprimé tant qu’au moins un autre commentaire y fait référence ».
    Cela dit, modifier une règle de gestion forte parce que le SGBD ne facilite pas la tâche pour la faire respecter n’est pas une bonne approche ; personnellement je m’y suis toujours refusé et, à moins qu’il soit vraiment impossible de faire autrement, pas de concession ! Bien que je trouve cela moyen (j’ai l’impression de retrouver l’informatique des années soixante...), vous pouvez quand même réfléchir à une astuce plus ou moins vaseuse : effectuer la suppression « logique » d’un commentaire qui est lui-même commenté. Le commentaire n’est pas supprimé (tables COMMENTAIRE, COMMENTAIRE_ARTICLE, COMMENTAIRE_COMMENTE), mais un indicateur représenté par un attribut de l’en-tête d’une des tables, valant « oui » ou « non » permettrait de faire comme si, c'est-à-dire répondre positivement ou négativement à la question : « Le commentaire 123 existe-t-il ? ». Je ne suis que moyennement d’accord avec cette solution, mais comme dit Laspalès à Chevallier « C’est vous qui voyez »...

    Citation Envoyé par heretik25 Voir le message
    Pourriez-vous m'expliquer rapidement en quoi la création de l'entité-type "article_util" permet de garder ou supprimer les articles d'un utilisateur souhaitant se désinscrire ?
    L’association-type REDIGER qui établissait un lien entre UTILISATEUR et ARTICLE permettait de savoir quels étaient les articles rédigés par l’utilisateur Louis, mais elle ne permettait pas de conserver ses articles si on supprimait Louis. Cette association-type ne répondait plus à votre nouveau besoin, lequel impose que le lien entre UTILISATEUR et ARTICLE devienne facultatif : désormais, un article n’a pas nécessairement d’auteur et s’il en a un, le lien est établi grâce à l’entité-type associative ARTICLE_UTIL. C’est ce qui se passe du reste avec les fichiers GPS : un fichier n’est pas nécessairement associé à un article.

    Si Louis qui a pour identifiant 2718 crée l’article qui a pour identifiant 45, vous insérez cet article dans la table ARTICLE, puis vous établissez le lien en insérant la paire <45, 2718> dans la table ARTICLE_UTIL.

    Je répète maintenant ce que j’ai écrit ici :

    Pour supprimer l’utilisateur Louis d’identifiant 2718, ainsi que ses articles :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    EXECUTE SUPPRIMER_UTILISATEUR 2718, 'tout' ;
    Pour supprimer Louis sans supprimer les articles qu’il a commis :
    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    EXECUTE SUPPRIMER_UTILISATEUR 2718, 'xxxx' ;
    Dans la procédure SUPPRIMER_UTILISATEUR, la suppression des articles de Louis est donc conditionnée par le fait qu’on transmette la valeur 'tout' ou autre chose. Dans tous les cas, Louis disparaît. Si on avait conservé la relation initiale, dans tous les cas les articles de Louis auraient été supprimés. On voit bien dans la procédure le rôle joué par la table ARTICLE_UTIL : récupérer toutes les valeurs d’id_article associées à l’Id_utilisateur passé par paramètre.

    Code SQL : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    CREATE PROCEDURE SUPPRIMER_UTILISATEUR
              @UtilisateurId   INT 
            , @ArticleAussi    CHAR(4) 
        AS
           IF  @ArticleAussi = 'tout' 
               BEGIN 
                  DELETE  FROM ARTICLE 
                          WHERE   Id_article IN (SELECT Id_article
                                                 FROM   ARTICLE_UTIL 
                                                 WHERE  Id_utilisateur = @UtilisateurId) ;   -- chouffe !
               END
           DELETE  FROM UTILISATEUR
           WHERE   Id_utilisateur = @UtilisateurId ;


    Citation Envoyé par heretik25 Voir le message
    Pouvez-vous aussi me dire en passant comment vous feriez avec les entités "type_article" et "sous_type_article" ?
    Je subodore que pour tel article on fait référence à TYPE_ARTICLE et que pour tel autre article on fait référence à SOUS_TYPE_ARTICLE. S’il en est ainsi, on se retrouve comme dans une situation comparable à celle du fichier GPS où un coup on fait référence à l’entité-type ARTICLE, un autre coup à l’entité-type UTILISATEUR.

    S’il en est ainsi, le diagramme conceptuel est le suivant :

    Diagramme logique :

  13. #73
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    Je complète ainsi la phrase : « [...] ce dernier ne peut pas être supprimé tant qu’au moins un autre commentaire y fait référence ».
    Cela dit, modifier une règle de gestion forte parce que le SGBD ne facilite pas la tâche pour la faire respecter n’est pas une bonne approche ; personnellement je m’y suis toujours refusé et, à moins qu’il soit vraiment impossible de faire autrement, pas de concession ! Bien que je trouve cela moyen (j’ai l’impression de retrouver l’informatique des années soixante...), vous pouvez quand même réfléchir à une astuce plus ou moins vaseuse : effectuer la suppression « logique » d’un commentaire qui est lui-même commenté. Le commentaire n’est pas supprimé (tables COMMENTAIRE, COMMENTAIRE_ARTICLE, COMMENTAIRE_COMMENTE), mais un indicateur représenté par un attribut de l’en-tête d’une des tables, valant « oui » ou « non » permettrait de faire comme si, c'est-à-dire répondre positivement ou négativement à la question : « Le commentaire 123 existe-t-il ? ». Je ne suis que moyennement d’accord avec cette solution, mais comme dit Laspalès à Chevallier « C’est vous qui voyez »...
    La modification me paraît toutefois intéressante car cela permet d'éviter l'effacement d'une réponse qui serait pertinente. Peut-on donc interdire la suppression du message si celui-ci est commenté au moins une fois ? Si c'est toujours compliqué, je vais finir par interdire toute suppression comme c'est souvent le cas un peu partout !

    L’association-type REDIGER qui établissait un lien entre UTILISATEUR et ARTICLE permettait de savoir quels étaient les articles rédigés par l’utilisateur Louis, mais elle ne permettait pas de conserver ses articles si on supprimait Louis. Cette association-type ne répondait plus à votre nouveau besoin, lequel impose que le lien entre UTILISATEUR et ARTICLE devienne facultatif : désormais, un article n’a pas nécessairement d’auteur et s’il en a un, le lien est établi grâce à l’entité-type associative ARTICLE_UTIL. C’est ce qui se passe du reste avec les fichiers GPS : un fichier n’est pas nécessairement associé à un article.

    Si Louis qui a pour identifiant 2718 crée l’article qui a pour identifiant 45, vous insérez cet article dans la table ARTICLE, puis vous établissez le lien en insérant la paire <45, 2718> dans la table ARTICLE_UTIL.
    Merci pour cette explication.

    Je subodore que pour tel article on fait référence à TYPE_ARTICLE et que pour tel autre article on fait référence à SOUS_TYPE_ARTICLE. S’il en est ainsi, on se retrouve comme dans une situation comparable à celle du fichier GPS où un coup on fait référence à l’entité-type ARTICLE, un autre coup à l’entité-type UTILISATEUR.
    La proposition semble répondre à mon besoin mais pour m'assurer de votre compréhension, regardons un exemple concret :

    Pour moi, une balade est un type d'article. Maintenant, jamais je n’écrirai d'article relatant une balade "simple". Par contre, j’écrirai une balade à pied ou une balade à vélo, mais jamais une balade seule.

    Le suffixe "à pied" et "à vélo" sont considérés comme des sous-types d'article.

    Autres exemple : Un test de matériel possédera lui aussi toujours un sous-type comme "Test d'un matériel dans le domaine du vélo", "domaine de la randonnée", "de la sécurité"...Ce qui est particulier c'est que l'on pourrait dans le cas du test de matériel parler de "catégorie de test", cependant, en considérant qu'il s'agit d'un "sous type de test", cela permet de simplifier les choses.

    Par contre, une présentation est un type d'article qui ne possède pas de sous-type. Ainsi, j'écrirai un article "présentation".

    Est-ce qu'on est bon ?

    P.S: Grâce à vous, j'ai encore appris un nouveau mot : "subodore", j'adore !

    Ci-dessous, le MPD avec les contraintes du ON DELETE :



    Et en PJ, la version 3.6 du MCD et du MPD
    Fichiers attachés Fichiers attachés

  14. #74
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut
    Bonsoir,


    Citation Envoyé par heretik25 Voir le message
    La modification me paraît toutefois intéressante car cela permet d'éviter l'effacement d'une réponse qui serait pertinente. Peut-on donc interdire la suppression du message si celui-ci est commenté au moins une fois ? Si c'est toujours compliqué, je vais finir par interdire toute suppression comme c'est souvent le cas un peu partout !
    N’ayez pas d’inquiétude. Avec CASCADE pour le commentant et RESTRICT pour le commenté, si on essaie de supprimer un commentaire à partir de la table COMMENTAIRE_ARTICLE et s'il est effectivement commenté (table COMMENTAIRE_COMMENTE), l’opération échouera.


    Illustrons.

    Table COMMENTAIRE_ARTICLE :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    id_commentaire    id_article   
                 1             2
                 2             1
                 3             2
                 4             3
                 5             2
                 6             4
                 7             2
                 8             2
                 9             1
                10             2
                12             1
                13             1
                15             2
    Table COMMENTAIRE_COMMENTE :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    id_commentant    id_commented
                3               1
                5               3
                7               5
                8              15
                9               2
               10               1
               12               9
               13              12
               15               3
    Exemples de suppression :

    DELETE FROM COMMENTAIRE_ARTICLE WHERE id_commentaire = 4 ; OK, car 4 est absent de la table COMMENTAIRE_COMMENTE.

    DELETE FROM COMMENTAIRE_ARTICLE WHERE id_commentaire = 8 ; OK, car 8 est présent dans la table COMMENTAIRE_COMMENTE mais seulement comme commentant, 8 n’est pas commenté.

    DELETE FROM COMMENTAIRE_ARTICLE WHERE id_commentaire = 1 ; KO, car 1 est présent dans la table COMMENTAIRE_COMMENTE en tant que commenté : l’opération est rejetée. Même chose pour les autres commentés : 2, 3, 5, 9, 12, 15.

    Note concernant le passage aux tables SQL :

    Pour chaque lien entre tables figurant dans le diagramme logique, n’oubliez pas de signaler votre choix à l’attention du SGBD. Exemple :

    Clic droit sur le lien :

    =>


    Citation Envoyé par heretik25 Voir le message
    Pour moi, une balade est un type d'article. Maintenant, jamais je n’écrirai d'article relatant une balade "simple". Par contre, j’écrirai une balade à pied ou une balade à vélo, mais jamais une balade seule.

    Le suffixe "à pied" et "à vélo" sont considérés comme des sous-types d'article.

    Autres exemple : Un test de matériel possédera lui aussi toujours un sous-type comme "Test d'un matériel dans le domaine du vélo", "domaine de la randonnée", "de la sécurité"...Ce qui est particulier c'est que l'on pourrait dans le cas du test de matériel parler de "catégorie de test", cependant, en considérant qu'il s'agit d'un "sous type de test", cela permet de simplifier les choses.

    Par contre, une présentation est un type d'article qui ne possède pas de sous-type. Ainsi, j'écrirai un article "présentation".

    Est-ce qu'on est bon ?
    Vous n’avez pas faux, mais le distinguo type d’article / sous-type d’article n’est-il pas un tantinet sophistiqué et superflu ? Ne serait-il pas aussi simple de dire qu’une balade à vélo ou une balade à pied font sont tout simplement l’objet chacune d’un type d’article ? Mais comme dit Laspalès...


    Keep up the good job!

  15. #75
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    N’ayez pas d’inquiétude. Avec CASCADE pour le commentant et RESTRICT pour le commenté, si on essaie de supprimer un commentaire à partir de la table COMMENTAIRE_ARTICLE et s'il est effectivement commenté (table COMMENTAIRE_COMMENTE), l’opération échouera.
    Ok, alors dans ce cas, je ferai une restriction dans ma fonction qui permettra de cacher le bouton suppression si le message est commenté.

    Effectivement, j'ai trouvé ça hier et j'ai appliqué les contraintes référentielles que j'ai affiché sur la capture d'écran. Au fait, sont-elles bonnes ?

    Vous n’avez pas faux, mais le distinguo type d’article / sous-type d’article n’est-il pas un tantinet sophistiqué et superflu ? Ne serait-il pas aussi simple de dire qu’une balade à vélo ou une balade à pied font sont tout simplement l’objet chacune d’un type d’article ? Mais comme dit Laspalès...
    Effectivement, c'est assez subtil comme distinction. Je vous explique pourquoi je voulais faire comme cela. l'idée est de pouvoir ajouter une colonne "position" dans les "sous_types" afin de pouvoir les ordonner comme bon me semble côté utilisateur.

    Si l'on regarde la page test de mon site, on remarquera que les "sous_types" de test (VTT, Randonnée....) sont classés selon un ordre particulier. Cet ordre est mis en place grâce à un champ position qui est lui même paramétrable côté administration.

    Pouvons-nous envisager un système de positionnement si l'on utilise seulement une entité-type "type_article" ?

    @bientôt et merci pour la remarque "Keep up the good job! "

  16. #76
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut
    Bonjour,


    Citation Envoyé par heretik25 Voir le message
    j'ai appliqué les contraintes référentielles que j'ai affichées sur la capture d'écran. Au fait, sont-elles bonnes ?
    Voui. Sinon je vous aurais fait les gros yeux.

    Citation Envoyé par heretik25 Voir le message
    l'idée est de pouvoir ajouter une colonne "position" dans les "sous_types" afin de pouvoir les ordonner comme bon me semble côté utilisateur.
    Vu comme ça et vu le bel écran, on garde le sous-type.

    Citation Envoyé par heretik25 Voir le message
    Pouvons-nous envisager un système de positionnement si l'on utilise seulement une entité-type "type_article" ?
    Ça doit être assez bôdélique, on évitera donc...


    Ça progresse !

  17. #77
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    Bonsoir,

    Voui. Sinon je vous aurais fait les gros yeux.
    Ok, super !

    Vu comme ça et vu le bel écran, on garde le sous-type.
    Ok par-contre quel bel écran ?

    Ça doit être assez bôdélique, on évitera donc...
    Ok, on évite alors

    Ça progresse !
    Grâce à vous et à votre patience. Par-contre, je pensais qu'on en état plus avancé que le stade du "Ça progresse"

    Vous voyez encore des corrections à apporter ? Vous faut-il le MLD ?

    @bientôt

  18. #78
    Expert éminent sénior
    Avatar de fsmrel
    Homme Profil pro
    Spécialiste en bases de données
    Inscrit en
    Septembre 2006
    Messages
    8 097
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Essonne (Île de France)

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

    Informations forums :
    Inscription : Septembre 2006
    Messages : 8 097
    Points : 31 528
    Points
    31 528
    Billets dans le blog
    16
    Par défaut
    Ave !


    Citation Envoyé par heretik25 Voir le message
    Quel bel écran ?
    Celui que vous proposâtes : test du site.

    Citation Envoyé par heretik25 Voir le message
    je pensais qu'on en état plus avancé que le stade du "Ça progresse"
    Dans le paradoxe d'Achille et de la tortue, je vous laisse le soin de distribuer les rôles...


    Citation Envoyé par heretik25 Voir le message
    Vous faut-il le MLD ?
    Certes !

  19. #79
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    Celui que vous proposâtes : test du site.
    Ah merci !

    Voici en PJ, le MCD, le MPD, le MLD, le PDF du MLD, et la base générée !

    Autre question, puis-je faire du reverse engineering avec PowerAMC afin d'accrocher le modèle à la table utilisateur de mon forum ?

    @bientôt
    Fichiers attachés Fichiers attachés

  20. #80
    Membre averti
    Homme Profil pro
    Inscrit en
    Avril 2011
    Messages
    660
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Avril 2011
    Messages : 660
    Points : 331
    Points
    331
    Par défaut
    Bonjour,

    Afin de fusionner la base de données du site à celle du forum, j'ai modifié le champ "id_utilisateur" dans l'entité-type UTILISATEUR, par "u_id".

    J'ai ensuite essayé d'appliquer le SQL généré sur la même base que mon forum en ayant au préalable enlever la création de la table utilisateur.

    Toutes les tables se créer mais une erreur survient et je pense qu'elle ne sera pas la seule :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    Erreur
    
    Requête SQL:
    
    ALTER TABLE CHOISIR_POSS ADD CONSTRAINT FK_CHOISIR_POSS2 FOREIGN KEY ( U_ID ) REFERENCES FSB2_USERS( U_ID ) ON DELETE RESTRICT ON UPDATE RESTRICT ;
    
    MySQL a répondu: Documentation
    #1005 - Ne peut créer la table 'pevtt_forum.#sql-a4_8d' (Errcode: 150)
    Pouvez-vous m'aider à corriger le problème ?

    Par avance, merci.

Discussions similaires

  1. Réponses: 3
    Dernier message: 15/09/2008, 16h37
  2. Réponses: 2
    Dernier message: 02/09/2008, 13h16
  3. petite question sur les commentaires en C
    Par jocelyn54 dans le forum Débuter
    Réponses: 2
    Dernier message: 25/01/2008, 02h08
  4. Probleme sur les commentaire XML
    Par IGFP dans le forum EDI/Outils
    Réponses: 6
    Dernier message: 27/02/2007, 08h41
  5. xpath-->test sur les commentaires
    Par yos dans le forum XSL/XSLT/XPATH
    Réponses: 4
    Dernier message: 11/07/2005, 12h14

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo