Discussion :

[Keizone]

Bonjour camarades,



Voici ma problématique. Étant sur un projet web et ayant étudié Merise en formation, je fais un MCD. J'aurai besoin de quelques regards pour savoir si je vais dans la bonne direction. Si je poursuis sur le MPD et la génération de base avec un MCD foireux, ma bdd sera tout autant foireuse... J'ai assez de taf pour ne pas faire les mêmes choses 10 fois ^^.


Voici un topo du projet pour que vous ayez une idée générale pour mieux appréhender mon MCD.

Mon site sera un portfolio dynamique. 4 pages principales :
- présentation
- références (cv, lettre de motivation, contrôle de ref])
- book (papier, infographie)
- actualité


Pour la V1 ya que moi qui pourra poster des articles ou commentaires.
MAIS dans la V2 les gens pourront poster des articles, images, commenter et donner des notations. Pour se faire ils devront s'inscrire obligatoirement (en tant que "member") sauf pour donner des notes ("guest"). J'ai aussi prévu pour plus tard la possibilité de pouvoir nommer des co-admins ("staff").

DONC mon MCD anticipe un peu tout ça pour que je doive refaire le MCD et compagnie au passage à la V2. J'anticipe disons.

Voici ma maquette déjà intégrée :
http://www.servimg.com/image_preview...203&u=13807355

Voilà mon MCD ^^ :



Est-ce la bonne approche ? Mon MCD est-il cohérent ? Avez vous des remarques peut être ^^ ? Dites-moi tout.



Thx d'avance camarades .

[fsmrel]

Bonsoir Keizone,


Les commentaires qui suivent valent pour la 1re version de votre MCD. Je regarderai les changements apportés par la 2e version.

Je sais qu'on ne voit pas bien.

Effectivement on s’esquinte les yeux à scruter l’image... Pour ma part, avec mon vieux Windows XP je fais des captures d’écran avec la touche « Impécr » et l’antédiluvien PAINT me permet de présenter des images lisibles. Votre système serait-il donc encore plus antique ?


Selon votre MCD, l’utilisateur Raoul peut faire figurer plus d’une fois la même image dans un article donné : pas d’objection.

Raoul peut commenter plus d’une fois le même article : pas d’objection.
Raoul peut commenter ses propres articles : objection.

Raoul peut noter les articles des autres utilisateurs : pas d’objection.
Raoul peut noter plus d’une fois un article de Fernand : objection.
Raoul peut noter ses propres articles : objection.


Un utilisateur qui est administrateur pourrait faire l’objet de propriétés particulières (par exemple modérer), conduisant à spécialiser l’entité-type USER. On peut aller jusqu’à mettre en place une hiérarchie, permettant d’autoriser les différents types d’action : Tout le monde peut noter, auquel cas l’association avec l’entité-type RATE se fait avec au niveau USER. En revanche, l’association POSTER avec l’entité-type ARTICLE se fait au niveau NON_GUEST, etc.

[Keizone]

.
Bonsoir Fsmrel,




Tout d'abord merci de votre contribution, navré du retard je n'ai pas eu de notification. Je suis sous Vista, question antiquité on est bien je crois !



Je vais tenter de répondre clairement à tout ça avec mes quelques connaissances en cours d'upgrade ^^, notamment pour les "objections" ^^ :

.....- Je souhaite en effet que Raoul (disons Alfredo) puisse commenter ses propres articles, pour qu'il puisse ne serai-ce que répondre à ceux qui ont eux même commenté ......ou simplement pour apporter des précisions sur son propres article des fois que ca soit une feignasse qui ne veuille pas éditer son article.

.....- Alfredo devrait je pense avoir le droit de noter plusieurs fois un article. Soit parce qu'il s'est trompé et qu'il veut corriger sa note, soit parce qu'il a changé d'avis 1 ......mois plus tard que son "moi" a donc évolué (discutable ^^). Par contre en effet sa seconde note doit écraser la première. Je ne saurai pas dire si mon modèle prend le ......cas en compte, cela se fera j'imagine dans l'élaboration de la requête.

.....- Alfredo ne doit en effet pas avoir le droit de noter son propre article. Cela ne se gère t-il pas dans la requête issue du clic d'Alfredo ? if le user connecté est le même ......que l'auteur de l'article, alors tu as une fenêtre contextuelle disant :
..........> Vous ne pouvez pas vous noter vous même, la prétention d'un être est une valeur jaugée par autrui, non soi même ^^.



Pour la gestion des droits utilisateurs en fonction de leur rôle au niveau relationnel, j'avoue me poser la question tous les jours. Le souci c'est que j'ai tendance à toujours tout compartimenter, ranger, diviser les tables pour les catégoriser, mon premier MCD matérialisait 3 entités différentes, une ADMIN, une STAFF, une MEMBER et une GUEST, chacun avec un id auto incrémenté d'où partait des relations toujours plus nombreuses en fonction du grade. Type le Guest en gros n'a que ses yeux pour pleurer, le membre peut poster, le staff peut poster, éditer, supprimer et l'admin n'en parlons pas. Du coup ça faisait un truc monstrueux et je suis du coup partit avec une seule entité USER avec quelque chose du type:
.....- if le user connecté est staff (bollean = 1) from USER, alors il peut éditer, sinon une fenêtre contextuelle s'ouvre disant :
..........> No way tu ne peux faire ça, va falloir faire ses preuves avant ^^ (je blague mais c'est l'idée).

Je ne sais pas si c'est la bonne approche. Du coup c'est vrai que faire 2 tables en plus type GUEST et NON_GUEST permet de catégoriser un peu, mais pas trop. Puis ça m'arrange car je ne sais pas encore comment gérer techniquement les GUEST'.



Par contre je vois que vous catégoriseriez aussi les ADMIN' et les MEMBERS. Hmmm c'est pratique pour niveau relationnel (pour les notes par ex.) mais ça
sous-entend (il me semble) que les admins et membres ne sont pas des USERS. En fait je considère que tout le monde est un utilisateur (USER), disons comme un internaute au sens large, et qu'il y a des classes d'utilisateurs.

Un détail aussi mais si je me trompe pas, dans le cas où tout le monde peut noter (ce qui est le cas mais serai susceptible de changer post-prod), si on
met une relation "rate" entre USER et ARTICLE comme vous proposez, la table GUEST ne sert plus à rien non ?




Vous voyez ce que je veux dire ? Ais-je bien compris ce que vous voulez dire telle est la question .

edit => j'ai mis mon MCD en version non casseur d'oeil
.

[fsmrel]

Bonsoir Keizone,

Je souhaite en effet que Raoul (disons Alfredo) puisse commenter ses propres articles, pour qu'il puisse ne serai-ce que répondre à ceux qui ont eux même commenté ......ou simplement pour apporter des précisions sur son propres article des fois que ca soit une feignasse qui ne veuille pas éditer son article.

D’accord, objection levée.

Alfredo devrait je pense avoir le droit de noter plusieurs fois un article. Soit parce qu'il s'est trompé et qu'il veut corriger sa note, soit parce qu'il a changé d'avis 1 ......mois plus tard que son "moi" a donc évolué (discutable ^^). Par contre en effet sa seconde note doit écraser la première. Je ne saurai pas dire si mon modèle prend le ......cas en compte, cela se fera j'imagine dans l'élaboration de la requête.

Bien sûr, après avoir noté une première fois l’article de Raoul, Alberto (UserId = x) peut remplacer tant qu’il veut la valeur de la note (attribut Note de l’association NOTER ci-dessous) qu’il a attribuée à cet article, ou même supprimer cette note (au niveau SQL : DELETE FROM NOTER WHERE UserId = x). Ce que je veux dire, c’est que la cardinalité maximale portée par la patte connectant USER et ARTICLE est 1, sinon Alberto pourrait avoir N notes actives en même temps pour l’article de Raoul.

Diagramme correspondant :




Ici, seuls les membres et les admins peuvent noter. Je propose de mettre en évidence des contraintes d'inclusion et d'exclusion qui s'imposent. Au vu du sens de la flèche, la contrainte d’inclusion (I) signifie qu’un article ne peut être noté que s’il a d'abord été posté. La contrainte d’exclusion (X) signifie que personne ne peut à la fois poster un article et noter celui-ci.

Alfredo ne doit en effet pas avoir le droit de noter son propre article. Cela ne se gère t-il pas dans la requête issue du clic d'Alfredo ?

Les contraintes sont là pour ça : en Merise il s’agit de la contrainte d’exclusion figurant dans le MCD. AU niveau SQL ça sera une assertion, à moins que le SGBD ne respecte pas le standard (c’est son droit...), auquel cas ça sera un trigger. L’important est d’éviter de programmer ce genre de contrôle dans l’applicatif qui n’est pas là pour faire le travail du gendarme mais pour produire. Cette remarque vaut bien sûr pour la contrainte d’inclusion : on pourra reprendre ça en temps opportun.

ça sous-entend (il me semble) que les admins et membres ne sont pas des USERS.

Mais si ! Entre USER et GUEST il y a une relation d’héritage, même chose entre USER et NON_GUEST :

— Un utilisateur est soit un guest (invité ?) soit un non guest.
— Un guest est nécessairement un utilisateur, même règle pour le non guest.

De la même façon un non guest est soit un admin soit un membre.

On a spécialisé les gens (notez les contraintes d’exclusion dans les demi-lunes). Ainsi on peut définir les actions auxquelles ils ont droit sans monter d'usine à gaz. Pour reprendre le MCD que j’avais ébauché :




On voit que seuls les admins peuvent modérer. De même, seuls les non guests (c'est-à-dire les admins et les membres) peuvent poster et noter.

Dans le cas où tout le monde peut noter (ce qui est le cas mais serai susceptible de changer post-prod), si on met une relation "rate" entre USER et ARTICLE comme vous proposez, la table GUEST ne sert plus à rien non ?

S’il fallait rétablir l’association NOTER entre USER et ARTICLE, pas de problème, sinon qu’on ne pourrait plus cette fois-ci représenter les contraintes merisiennes d’inclusion et d’exclusion. En revanche au stade SQL pas de difficulté particulière.

Quant à l’entité-type GUEST (et non pas table car on est au niveau MCD), elle pourrait disparaître, mais dans le contexte de l’héritage et de la spécialisation des entités-types ça ne serait pas sain (conséquences notamment sur l’évolution des développements, perte des contraintes merisiennes) : appelons un chat un chat (au moins au niveau conceptuel).

edit => j'ai mis mon MCD en version non casseur d'œil

Effectivement on voit mieux ^^. Mais je suppose qu’une fois l’héritage en place, il évoluera (cas par exemple la cardinalité minimale 0 portée par la patte connectant l’entité-type ARTICLE et l’association POST).

[fsmrel]

Bonsoir Keizone,


Les contraintes merisiennes d'inclusion et d'exclusion vous ont-elles inspiré ?

[Keizone]

Re-bonjour,

Je viens à peine de voir la réponse encore, je prend le temps de lire tout ça en dehors du boulot et je vous réponds vite !!

[Keizone]

Bonsoir camarade,



Navré de l'attente fsmrel. J'ai terminé la partie en jQuery de mon site qui me chiffonnait, je ne suis plus en stage, j'en suis enfin aux BDD sur mon projet et j'ai enfin du temps à consacrer pleinement. Merci de toutes ces infos et de votre patience ^^.

Bien sûr, après avoir noté une première fois l’article de Raoul, Alberto (UserId = x) peut remplacer tant qu’il veut la valeur de la note (attribut Note de l’association NOTER ci-dessous) qu’il a attribuée à cet article, ou même supprimer cette note (au niveau SQL : DELETE FROM NOTER WHERE UserId = x). Ce que je veux dire, c’est que la cardinalité maximale portée par la patte connectant USER et ARTICLE est 1, sinon Alberto pourrait avoir N notes actives en même temps pour l’article de Raoul.

Hmm d'accord je comprends. J'ai toujours de petites difficultés avec les cardinalités. En fait concernant la relation USER-Rate-ARTICLE (cf mon MCD), voilà la chose que je me dis. Un utilisateur peut attribuer 0 ou plein de notes, soit 0/n... une note peut être attribuée à 0 ou plein d'articles. Je crois (corrigez moi) que je conceptualise la note comme une entité générale, pas comme un élément au centre d'une relation elle même générale. En gros je me dis qu'une note est soit égale à 1, 2, etc... et peut être attribuée plusieurs fois puisque une note égale à 3 peut être attribué à n articles, si vous voyez ce que je veux dire.

Je sais pas si mon approche/routine/démarche pour gérer les cardinalité est bonne du coup xD.

Donc si je comprends bien il faudrait plutôt avoir du 0/1 de chaque côté de RATE. Un utilisateur peut attribuer 0 ou 1 note spécifique... une note spécifique en tant que note unique peut être attribuée à 0 ou un seul article puisque on personnifie la note en tant que telle (Phylo quand tu nous tiens )... J'ai bon ?

Ici, seuls les membres et les admins peuvent noter. Je propose de mettre en évidence des contraintes d'inclusion et d'exclusion qui s'imposent. Au vu du sens de la flèche, la contrainte d’inclusion (I) signifie qu’un article ne peut être noté que s’il a d'abord été posté. La contrainte d’exclusion (X) signifie que personne ne peut à la fois poster un article et noter celui-ci.

Toujours sur les RATE et concernant les contraintes d'In/exclusion du coup, vous me conseillez de modifier mes flèches dans Power AMC c'est comme ça qu'elles se matérialisent ?

Mais si ! Entre USER et GUEST il y a une relation d’héritage, même chose entre USER et NON_GUEST :

— Un utilisateur est soit un guest (invité ?) soit un non guest.
— Un guest est nécessairement un utilisateur, même règle pour le non guest.

Hmmm allez je m'attèle à ce souci qui me bouffe les neurones ^^.

Alors, ma première question est celle ci. Pardonnez mon niveau car elle va surement vous paraître évidente ^^. Ne pas spécialiser les rôles utilisateurs reviendrait à avoir une usine à gaz donc. Ma question est... pourquoi xD ? Je veux dire pourquoi par la suite le fait de créer plusieurs Entités (non pas table ^^ message reçu ) selon les rôles en plus des relations induites facilitera la récupération des données ? Je voyais justement la chose dans la simplification de ceux ci, en regroupant les utilisateurs et en ayant des attributs bolléen type "invité", "membre", "admin" ou encore "demi_dieu" xD je pensais simplifier la chose, où fais-je erreur ???

Je comprends cela dit la notion d'héritage en effet, je n'y avais pas pensé, je l'ai eu étudié mais n'ai pas rencontré personnellement le cas où j'en aurais besoin, jusqu'à maintenant ^^.
Edit: je suis en train de lire ça :
http://sqlpro.developpez.com/cours/modelisation/heritage/
Mais je ne vois toujours pas comment ça pourrait mieux me servir, car quand je spécialise mes différents type d'utilisateurs je me retrouve avec des entités filles vide.

Effectivement on voit mieux ^^. Mais je suppose qu’une fois l’héritage en place, il évoluera (cas par exemple la cardinalité minimale 0 portée par la patte connectant l’entité-type ARTICLE et l’association POST).

Vous me conseillez donc de mettre 1.n à ma cardinalité ARTICLE / POST ? Sue le même principe qu'entre GALLERY/ et UPLOAD ?



Merci d'avance de vos conseils éclairés .

[Keizone]

Up .

[fsmrel]

Bonsoir Keizone,

En fait concernant la relation USER-Rate-ARTICLE (cf. mon MCD), voilà la chose que je me dis. Un utilisateur peut attribuer 0 ou plein de notes, soit 0/n...

Eh bien ! Je constate que je vous ai enduit avec de l’erreur, j’ai eu un instant de distraction, mais qu’avais-je donc bu ?

Je m’explique. Considérons le diagramme suivant, dans lequel la patte connectant NON_GUEST et NOTER est porteuse d’une cardinalité 0,N au lieu d’une malencontreuse cardinalité 0,1, signifiant en réalité qu’Alberto ne peut noter qu’un article :




Vu la cardinalité 0,N, Alberto peut noter plusieurs articles, mais chacun de ceux qu’il aura noté ne comportera qu’une note. Montrons-le au niveau de la base de données :

 
NON_GUEST (IdUser ...)           NOTER (IdUser    IdArticle    Note)        ARTICLE (IdArticle ....)
                1                            1            9       5                          9 
                1                            1           23       3                         23 
                1                            1           47       5                         47 
                2                            2            9       5    

La paire {IdUser, IdArticle} étant clé de la table NOTER, il existe par conséquent la dépendance fonctionnelle :

{IdUser, IdArticle} -> {Note}

En vertu de quoi il est impossible d’ajouter à la table NOTER une ligne <1, 9, x> (où x symbolise une valeur quelconque de note).

Par ailleurs rien n’empêche qu’Alberto remplace la valeur qu’il a donnée à une note.

Je devais être bien fatigué, me pardonnerez-vous cette distraction coupable ?

Aux attributs absents près, le MCD de départ devient celui-ci :

Toujours sur les RATE et concernant les contraintes d'In/exclusion du coup, vous me conseillez de modifier mes flèches, dans Power AMC c'est comme ça qu'elles se matérialisent ?

Ces contraintes sont représentables avec WinDesign mais pas avec PowerAMC, avec lequel je suis obligé d’en passer par PAINT pour simuler... Peu importe, car de toute façon c’est aux niveaux MLD puis SQL que la mise en œuvre de ces contraintes sera effective. Ainsi, dans la mesure où l’on sait que la base de données sera relationnelle, au stade MLD on peut utiliser le langage relationnel pour traduire les contraintes initiales :

— La contrainte d’inclusion fait appel à la projection et à l’inclusion :

NOTER {IdArticle} ⊆ ARTICLE {IdArticle}

Où NOTER {IdArticle} est la projection de la relvar (variable relationnelle) NOTER sur l’attribut IdArticle et ARTICLE {IdArticle} est la projection de la relvar ARTICLE sur l’attribut IdArticle.

En fait, cette contrainte devient une contrainte d’intégrité référentielle NOTER {IdArticle} REFERENCES ARTICLE {IdArticle}, ce que PowerAMC permet évidemment de mettre en oeuvre. La représentation graphique de la contrainte d'inclusion sur le MCD n'est là que pour attirer l'attention.

— La contrainte d’exclusion fait appel à la projection et à l’intersection :

ARTICLE {IdUserRedacteur, IdArticle} ∩ NOTER {IdUserNoteur, IdArticle} = ∅

Où ARTICLE {IdUserRedacteur, IdArticle} est la projection de la relvar ARTICLE sur les attributs IdUserRedacteur et IdArticle, tandis que NOTER {IdUserNoteur, IdArticle} est la projection de la relvar NOTER sur les attributs IdUserNoteur et IdArticle.

Avec un langage conforme à la théorie relationnelle, la contrainte d’exclusion est prise en compte de la façon suivante :

Code Tutorial D :

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

1
2
CONSTRAINT CX1 
    IS_EMPTY (ARTICLE {IdUserRedacteur, IdArticle} INTERSECT NOTER {IdUserNoteur, IdArticle}) ;

Traduction en SQL :

Code SQL :

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

1
2
3
4
5
6
7
8
9
CREATE ASSERTION CX1 CHECK
    (NOT EXISTS
        (SELECT IdUserRedacteur, IdArticle
         FROM   ARTICLE
        INTERSECT
         SELECT IdUserNoteur, IdArticle 
         FROM   NOTER
        ) AS x
    ) ;

Si le SGBD SQL ne propose pas l’instruction CREATE ASSERTION, on peut utiliser un trigger. Exemple avec MS 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
14
15
16
17
18
19
20
21
CREATE TRIGGER CX1_INSERT ON NOTER INSTEAD OF INSERT, UPDATE AS
       DECLARE @N AS INT
 
SET @N = (SELECT COUNT(*) 
          FROM      
             (SELECT IdUserRedacteur, IdArticle
              FROM   ARTICLE
             INTERSECT
             SELECT IdUserNoteur, IdArticle 
             FROM   INSERTED
            ) AS x
        )    
IF @N > 0 
    BEGIN
        RAISERROR ('Un rédacteur ne peut pas noter ses propres articles...',15,1) 
    END
ELSE
    BEGIN
        INSERT INTO NOTER SELECT * FROM INSERTED
    END
;

Avec un MLD qui suite à la dérivation du MCD est le suivant :

en regroupant les utilisateurs et en ayant des attributs booléen type "invité", "membre", "admin" ou encore "demi_dieu" xD je pensais simplifier la chose, où fais-je erreur ???

En « repliant » le MCD, vous simplifiez la représentation graphique, mais le prix est élevé, car vous vous compliquez singulièrement la vie en ayant à programmer les contraintes devant s’appliquer à la base de données...

Par exemple, il existe une règle selon laquelle un article a au moins et au plus un rédacteur : dans le MCD que j’ai proposé cette règle est assurée d’office, puisque la cardinalité portée par la patte connectant ARTICLE et POSTER est 1,1. Dans le MLD, cette règle est à nouveau garantie d’office grâce à la contrainte d’intégrité référentielle établie entre ARTICLE et NON_GUEST. Selon votre MCD, la cardinalité portée par la patte connectant ARTICLE et POST est 0,1 : la règle n’est pas automatiquement garantie, il manque la partie « au moins », un article peut exister sans faire référence à un rédacteur, vous devrez donc garantir cette règle vous-même, au moyen de triggers ou, ce qui est fortement déconseillé car fragile, à coups de code applicatif. Par ailleurs, la cardinalité 0,1 permet au bonhomme Null de s’introduire dans les bases de données, c’est le loup dans la bergerie.

Toujours selon votre MCD, un invité (guest) peut faire ce qu’il veut, rédiger, noter, modérer... Donc là encore vous devrez veiller vous-même à ce qu’il n’en soit pas ainsi.

Votre entité-type (et pas seulement entité) USER (attention c’est un mot réservé en SQL) comporte les booléens permettant de définir la typologie des acteurs et dont vous fournissez l’énumération. Le problème est qu’il faudra surveiller que pour un acteur il n’y ait qu’un seul de ces booléens qui prenne la valeur de vérité vrai.

Ainsi, notre approche de la modélisation est radicalement différente, vous « repliez », je » déplie », mais si de mon côté j’essaie de bétonner, on peut dire que de votre côté c’est la maison de Nif-Nif ou de Nouf-Nouf qui a votre faveur plutôt que celle de Naf-Naf...

Pour résumer, sur la base de votre MCD, est-ce que le SGBD garantira automatiquement les règles selon lesquelles :

— Seul un modérateur peut modérer ;

— Un invité ne peut ni poster, ni noter, ni modérer ;

— Un article a nécessairement un rédacteur ;

— Etc., etc.

La réponse est non, mais en dépliant le MCD, cela devient possible. Plus on déplie, plus on a de chances de pouvoir sous-traiter les contrôles au SGBD, ce qui est un gage de validité, de pérennité.

quand je spécialise mes différents type d'utilisateurs je me retrouve avec des entités filles vides

Malgré les apparences, les entités-types qui sont sous-types d’autres entités-types ne sont pas « vides », elles héritent des identifiants des entités-types qui en sont les surtypes.

Exemple : INDIVIDU et GUEST jouent respectivement le rôle de surtype et sous-type : GUEST hérite de l’identifiant d’INDIVIDU, même si cela n’est pas visible sur le MCD, mais ça le devient sur le MLD. De la même façon, NON_GUEST hérite de l’identifiant d’INDIVIDU et l’héritage se propage jusqu’à MEMBRE et ADMIN.

Vous me conseillez donc de mettre 1.n à ma cardinalité ARTICLE / POST ? Sue le même principe qu'entre GALLERY/ et UPLOAD ?

Certes non, je voulais dire que 0,1 deviendra 1,1 ! Un article a exactement un rédacteur (sauf si je ne suis pas à jeun, auquel cas je risque d'en voir deux...)

[Keizone]

Merci de cette mega réponse Fsmrel .

Je vais étudier votre réponse attentivement, il y a matière à étudier là ^^. Dès que j'en ai finit avec celle ci je répondrai ^^.

[Keizone]

Eh bien ! Je constate que je vous ai enduit avec de l’erreur, j’ai eu un instant de distraction, mais qu’avais-je donc bu ?

Je devais être bien fatigué, me pardonnerez-vous cette distraction coupable ?

Alors ça vous êtes le seul à le savoir xD ! Mais bien sûr que vous êtes pardonné d'office lol, comment vous en vouloir j'ai droit à un cours magistral ^^, je vais pas non plus me plaindre, quel insolent serais-je .

Petite question subsidiaire, sur que tool vous faites vos démos de MCD ?

Vu la cardinalité 0,N, Alberto peut noter plusieurs articles, mais chacun de ceux qu’il aura noté ne comportera qu’une note. Montrons-le au niveau de la base de données :

Hmmm d'accord j'ai compris tout ce paragraphe, le principe. Par contre le fait qu'il ne puisse commenter qu'une fois est géré en base j'imagine, au moment ou il reclick pour renoter, avec un "DELETE valor from RATE", puis "INSERT etc..." grosso merdo, j'ai bon ?

— La contrainte d’inclusion fait appel à la projection et à l’inclusion :

NOTER {IdArticle} ⊆ ARTICLE {IdArticle}

Où NOTER {IdArticle} est la projection de la relvar (variable relationnelle) NOTER sur l’attribut IdArticle et ARTICLE {IdArticle} est la projection de la relvar ARTICLE sur l’attribut IdArticle.

En fait, cette contrainte devient une contrainte d’intégrité référentielle NOTER {IdArticle} REFERENCES ARTICLE {IdArticle}, ce que PowerAMC permet évidemment de mettre en oeuvre. La représentation graphique de la contrainte d'inclusion sur le MCD n'est là que pour attirer l'attention.

— La contrainte d’exclusion fait appel à la projection et à l’intersection :

ARTICLE {IdUserRedacteur, IdArticle} ∩ NOTER {IdUserNoteur, IdArticle} = ∅

Où ARTICLE {IdUserRedacteur, IdArticle} est la projection de la relvar ARTICLE sur les attributs IdUserRedacteur et IdArticle, tandis que NOTER {IdUserNoteur, IdArticle} est la projection de la relvar NOTER sur les attributs IdUserNoteur et IdArticle.

Donc si je comprends bien je n'ai pas à me préoccuper des inclusions / exclusions à ce stade là de la conceptualisation. Par contre j'ai l'intention de faire mon MPD ensuite là et de générer ma BDD direct après, donc sans passer par le MLD donc si je comprends bien je ne verrai pas mes inclusions/exclusions matérialisées ^^. Est ce la bonne démarche ? J'ai appris comme ça en fait.

Votre explication concernant les variables relationnelles est très technique et complexe pour mon humble petit niveau mais je pense l'avoir assimilé. Je vais utiliser MySQL comme SGBD, j'imagine que c'est conforme à la th"orie relationnelle ?

Une chose est certaine, j'ai décidé que les auteurs pouvaient noter leurs propres articles. Une manière de s'auto évaluer disons. Je place une certaine confiance en la nature humaine et en son honnêteté en quelque sorte lool.

Les NON_GUEST pourront aussi rater les articles, cela permet de générer de l'activité même minime au cas où j'ai peu d'inscrits au départ. Un choix réfléchit disons. Faudra par contre que je gère le cas niveau BDD. Style :
"If id_user not exists from USERS blablabla INNER JOIN id_article from ARTICLE INNER JOIN valor from RATE"
(navré je suis aussi débutant en SQL qu'en Relationnel lol, j'ai pas la syntaxe des jointures par coeur en tête),
...c'est que l'utilisateur qui rate l'article n'est pas membre mais on l'accepte quand même. Si vous voyez l'idée xD. Mais peut être que je me creuse trop la tête pour rien, c'est fort possible :O !!!

Selon votre MCD, la cardinalité portée par la patte connectant ARTICLE et POST est 0,1 : la règle n’est pas automatiquement garantie, il manque la partie « au moins », un article peut exister sans faire référence à un rédacteur, vous devrez donc garantir cette règle vous-même, au moyen de triggers ou, ce qui est fortement déconseillé car fragile, à coups de code applicatif. Par ailleurs, la cardinalité 0,1 permet au bonhomme Null de s’introduire dans les bases de données, c’est le loup dans la bergerie.

En effet j'ai intégré ce point là niveau logique (uniquement niveau logique). J'ai modifié cela il y a un moment, je vous laisse découvrir la V3 de mon MCD en bas de page ^^. J'ai aussi appliqué cette règle à la cardinalité IMAGE MEMBER de mon nouveau MCD. Je pense que ça suit le même process.

...USER (attention c’est un mot réservé en SQL)

Mais pas en MySQL . J'ai vérifié, cependant je rajoute quand même un "S" par acquis de conscience. Pareil pour IMAGES, ARTICLES etc.. Disons que je vais partir du principe que chaque table recueille deS donnéeS. J'ai besoin de m'établir ce genre de logiques/routines pour me faire accepter tel ou tel choix, quel qu'il soit... Le "S" me semble donc une bonne solution. Malgré que plane le risque que "USERS" devienne dans l'avenir aussi un mot réservé xD. Mais où va le monde !? C'est à devenir fou !!

Pour résumer, sur la base de votre MCD, est-ce que le SGBD garantira automatiquement les règles selon lesquelles :
— Seul un modérateur peut modérer ;
— Un invité ne peut ni poster, ni noter, ni modérer ;
— Un article a nécessairement un rédacteur ;
— Etc., etc.
Malgré les apparences, les entités-types qui sont sous-types d’autres entités-types ne sont pas « vides », elles héritent des identifiants des entités-types qui en sont les surtypes.

Certes j'ai bien intégré le concept à présent, j'ai lu un peu de doc sur le sujet. L'héritage n'a plus de secret pour moi. Avocat à vos marques ! Près ? MCD'ez !!!

En « repliant » le MCD, vous simplifiez la représentation graphique, mais le prix est élevé, car vous vous compliquez singulièrement la vie en ayant à programmer les contraintes devant s’appliquer à la base de données...
Toujours selon votre MCD, un invité (guest) peut faire ce qu’il veut, rédiger, noter, modérer... Donc là encore vous devrez veiller vous-même à ce qu’il n’en soit pas ainsi.
Ainsi, notre approche de la modélisation est radicalement différente, vous « repliez », je » déplie », mais si de mon côté j’essaie de bétonner, on peut dire que de votre côté c’est la maison de Nif-Nif ou de Nouf-Nouf qui a votre faveur plutôt que celle de Naf-Naf...

C'est le moment qui m'a pris le plus de temps depuis notre dernière entrevue. Je suis du coup passé à la V3 de mon MCD. Sous vos conseils avisés, j'ai entrepris de décomposer mon entité USERS. Pas exactement comme votre exemple cependant. Je m'explique, le NN_GUEST me dérange un peu en fait.

Je considère tous les types d'utilisateurs en tant que tel, un peu comme des grade MCD'aire ^^. On est soit ADMIN (et inscrit), soit STAFF (et inscrit), soit MEMBER (et inscrit), soit GUEST (donc non inscrit). J'ai donc adapté votre exemple à la vision que je me faisais des rôles et de ce qu'ils signifiaient pour moi.
J'ai fais une première décomposition via MEMBERS et GUESTS qui héritent de USERS, puis une seconde spécialisation de MEMBERS qui donne son héritage à STAFF et ADMIN. De cette manière, j'imagine que ADMIN hérite des attributs de USERS qui est son Gran Pa'. Je me dis que la portée de l'héritage de USERS retombe inévitablement sur ADMIN qui récupère l'héritage de MEMBERS.

GUESTS, tout en haut (pour les non inscrits) est juste relié à "share", "like" et "rate", ce que je leur permet de faire.

Le STAFF en bas (les sous-admins que j'aurais nommé), pourront supprimer des images.

L'ADMIN (moi = God Mod xD) pourra tout faire, ainsi que modérer les articles.

J'avoue qu'entre le staff et les admins, les rôles restent un peu à définir car je ne cerne pas concrètement ce que l'admin pourrait faire de plus et le staff de moins, mais je sais au fond de moi que je dois définir ces 2 rôles distincts. Peut être pouvez vous m'éclairer .


Je vous laisse seul juge de ma progression et surtout de mes erreurs. Dites moi ce que vous en pensez :


[edit: MCD remodifié, image à jour.]

[Keizone]

Up .

Allez camarades réveillez vous bon sang !!

Il n'y a quand même pas sur ce forum qu'une seule personne qui sache me répondre innn ?

[fsmrel]

Bonsoir Keizone,

Petite question subsidiaire, sur que tool vous faites vos démos de MCD ?

J’utilise PowerAMC en surchargeant les graphiques comme je l'ai déjà mentionné :

Pour ma part, avec mon vieux Windows XP je fais des captures d’écran avec la touche « Impécr » et l’antédiluvien PAINT me permet de présenter des images lisibles.

Par contre le fait qu'il ne puisse commenter qu'une fois est géré en base j'imagine, au moment ou il reclick pour renoter, avec un "DELETE valor from RATE", puis "INSERT etc." grosso merdo, j'ai bon ?

Pour reprendre l’exemple de mon message précédent, Si x représente la note qu’Alberto (IdUser = 1) veut attribuer à l’article « Keizone s’éclate » (IdArticle = 9) :

— Soit Alberto n’a pas encore attribué de note (à ce propos, je vois que vos votes se raréfient... ), auquel cas il y aura un insert dans la table NOTER :

INSERT INTO NOTER (IdUser, IdArticle, Note) VALUES (1, 9, x) ;

— Soit Alberto a déjà voté, auquel cas (si la note change, tant qu’à faire) un UPDATE devrait suffire :

UPDATE NOTER SET Note = x WHERE IdUser = 1 AND IdArticle = 9 ;

Donc si je comprends bien je n'ai pas à me préoccuper des inclusions / exclusions à ce stade là de la conceptualisation.

Il faut au moins prendre conscience de l'existence de ces contraintes et les traduire sous forme de règles de gestion rédigées en français. Si on s’en sent capable il n’est pas inutile de les représenter dans le style Merise/2 (comme je l’ai fait à l'aide de « Magic » PAINT).

Par contre j'ai l'intention de faire mon MPD ensuite là et de générer ma BDD direct après, donc sans passer par le MLD donc si je comprends bien je ne verrai pas mes inclusions/exclusions matérialisées ^^.

He ? Une fois le MCD terminé, vous demandez à PowerAMC de produire soit un MLD, soit de sauter cette étape et de produire un MPD (au sens PowerAMC, ce qui ne veut pas dire que ce MPD ne soit pas un MLD, mais passons). Une fois ce MPD validé, vous demandez à PowerAMC de produire le code SQL de création des tables. En tout cas une chose est sûre, si vous voulez mettre en œuvre la contrainte d’exclusion, il faudra la programmer à l’aide d’un trigger, voyez par exemple ce message. Mais si vous décidez qu’un rédacteur peut s’auto-évaluer, vous n’en faites rien, c’est vous qui voyez... Quant à la contrainte d’inclusion que j’ai fait figurer dans le MCD (merci PAINT), je rappelle qu’au stade MLD elle est assurée par une contrainte référentielle.

Je vais utiliser MySQL comme SGBD, j'imagine que c'est conforme à la théorie relationnelle ?

Disons que la norme SQL elle-même n’est pas franchement conforme au Modèle relationnel de données (ou théorie relationnelle), elle ressemble moins au Prince charmant qu’à la Bête qui a un bon fond (voyez ici et un peu plus loin), par exemple, elle ne respecte pas le principe de l’information (Information Principle), parce qu’elle permet notamment l’utilisation de pointeurs et de marques NULL ; de son côté MySQL a des progrès à faire lui aussi avant d’être transformé en prince charmant (un ange passe...)

"If id_user not exists from USERS blablabla INNER JOIN id_article from ARTICLE INNER JOIN valor from RATE"

Blurps ? En français ?

Disons que je vais partir du principe que chaque table recueille deS donnéeS

Du singulier et du pluriel :

Un type d’entité (ou entité-type) est une classe d’entités ayant en commun un ensemble de propriétés. Le type d’entité USER symbolise l’utilisateur-type, lequel a pour propriétés (attributs) son nom, son prénom, son mot de passe, etc. Quant à eux, les utilisateurs proprement dits sont les entités, les instances (ou encore les occurrences) de la classe USER. Tout cela pour dire qu’un nom d’entité-type s’écrit de préférence au singulier : USER mais pas USERS. Comme vous risquez une collision avec les termes SQL (qui ne cause pas encore français ), je vous engage à remplacer « USER » par « UTILISATEUR »...

C’est comme pour les ensembles : on parle de l’ensemble N des entiers naturels (0, 1, 2, 3, ...) mais N est un nom propre donc au singulier bien qu’il contienne un nombre infini d’éléments...

C'est le moment qui m'a pris le plus de temps depuis notre dernière entrevue. Je suis du coup passé à la V3 de mon MCD. Sous vos conseils avisés, j'ai entrepris de décomposer mon entité USERS. Pas exactement comme votre exemple cependant.

Je me doute que le cerveau a dû fumer... Je ne vois pas grand-chose à redire, sinon que si vous ne sentez pas trop l’intérêt de l’entité-type zombie STAFF, vous la passez au rasoir du gars Ockham qui a dit qu’il était inutile de multiplier les entités sans nécessité : Pluralitas non est ponenda sine necessitate (principe de parcimonie). Si un jour l’existence de l’entité-type STAFF se justifiait, il ne serait pas difficile de la mettre en œuvre.

Je vous laisse seul juge de ma progression et surtout de mes erreurs. Dites moi ce que vous en pensez.

Ça progresse, petit à petit l’oiseau fait son nid. Toutefois l’oiseau aura à intérêt à bien comprendre ce qu’est une association ternaire !

Prenons l’exemple de RATE :



Traduction façon Masterchef :

Pour remplir la casserole RATE, il faut touiller ensemble au moins un article, un membre et un invité.

Sous forme prédicative :

Le membre M et l’invité G doivent conjuguer leurs efforts pour attribuer la note N à l’article A.

Exemple :

RATE (MEMBRE   GUEST        ARTICLE              NOTE)  
      Alberto  Raoul        Keizone s’éclate        5 
      Alberto  Paul         Keizone s’éclate        4 
      Alberto  Jean         Keizone s’éclate        4 
      Bernard  Raoul        Keizone s’éclate        5 

Or que je sache, un membre (ou un invité) n’a besoin de l'aide de personne pour noter un article, vous rendez dépendantes des données qui ne le sont pas ; pour les initiés il y a ce qu’on appelle un viol de quatrième forme normale (horresco referens !)...

Il faut détricoter tout ça et modéliser ainsi :

[MEMBER]----0,N----(RATE_M)----0,N----[ARTICLE]----0,N----(RATE_G)----0,N----[GUEST]

N.B. La présence dans l’association RATE de l’attribut nb_rate fait que cet attribut a le sens suivant : combien de fois Alberto a-t-il noté l’article « Keizone s’éclate » ? Normalement la réponse est : une fois (ça sent le rasoir d'Ockham)... Par contre, si on veut savoir combien de fois cet article a été noté, on utilisera l’opérateur d’agrégation COUNT :

SELECT COUNT(*) FROM RATE WHERE id_article = 9

Divers

— Les sous-types héritent de l’identifiant de leur surtype, donc les attributs id_member, id_guest, id_staff, id_admin n’ont pas lieu d’être, et doivent passer au fil du rasoir....

— Avec PowerAMC, cochez la case « O » (obligatoire) pour les attributs des entités-types, sinon le bonhomme Null viendra ficher la patouille dans la base de données :



Allez Keizone, ça avance, courage !

[Keizone]

Bonjour Mr Fsmrel,


Rares sont les occasions de se voir de jour ! Et c'est encore un plaisir que j'ai à continuer mon aventure accompagné de ces réponses non dénuées d'humour qui mettent du piment d’Espelette dans notre relationnel... Modèle relationnel bien sûr et permettent d'apprendre tout en s'amusant (ou peut être devins-je fou pour m'amuser en faisant des MCD... ou alors je devrais sortir un peu plus xD).

Je me doute que le cerveau a dû fumer... Je ne vois pas grand-chose à redire, sinon que si vous ne sentez pas trop l’intérêt de l’entité-type zombie STAFF, vous la passez au rasoir du gars Ockham qui a dit qu’il était inutile de multiplier les entités sans nécessité : Pluralitas non est ponenda sine necessitate (principe de parcimonie). Si un jour l’existence de l’entité-type STAFF se justifiait, il ne serait pas difficile de la mettre en œuvre.

J'ai trouvé dans la dernière version du MCD que j'ai posté sur mon dernier post peu de temps avant que vous répondiez. Le Staff pourra modérer les articles et supprimer des images (celles non conformes à la norme WWW bien sûr ). Le Méchant Dieu Unique nommé Admin pourra lui bannir (ou mettre au bucher, au choix...) les membres du clan un peu trop zélés au point de défier l'autorité du Maître Charte...

Ce pourquoi j'ai sur cette dernière version (que je reposte tout en bas de ce message) réutilisé la notion d'héritage. Ainsi l'entité MEMBRE lègue tout ce qu'il a (dont ce qu'il a récupéré de USERS) à STAFF qui à son tour lègue ses couteux attributs à ADMIN. ADMIN hérite donc si je ne dis pas de bétises de STAFF, de MEMBERS et de USERS.
Je sais que du coup s'adjoindra à ADMIN l'id_staff hérité, mais ça ne me semble pas gênant car dans l'absolu un admin fait disons partit du staff, puis je n'ai pas trouvé d'autres manière de simplifier la modélisation proprement. Le cerveau a fumé effectivement .

Or que je sache, un membre (ou un invité) n’a besoin de l'aide de personne pour noter un article, vous rendez dépendantes des données qui ne le sont pas ; pour les initiés il y a ce qu’on appelle un viol de quatrième forme normale (horresco referens !)...

Il faut détricoter tout ça et modéliser ainsi :

[MEMBER]----0,N----(RATE_M)----0,N----[ARTICLE]----0,N----(RATE_G)----0,N----[GUEST]

Whooo d'accord je pense comprendre. Du coup ma volonté d'autoriser les touristes à noter m'impose d'avoir une association RATE_X distincte tantôt pour mes fidèles que les passagers mystères ? Je modifie en ce cas. Est ce habituel de faire ça ? N'y a t-il pas un principe disant que 2 associations ayant le même dessein devraient joindre leurs efforts car "L'association fait la force" ?!
Et ce malgré le fameux Mr Tabourier, je cite ^^ :

""Un grand de Merise, à savoir Yves Tabourier, parle du « manque d’intérêt des cardinalités maximum à 1 pour les relations à plus de deux pattes » dans son ouvrage "De l’autre côté de MERISE (Les Éditions d’organisation, 1986)". Et il est d’usage d’éviter de genre d’associations-types.""

Du coup c'est la même sauce pour "share" et "like" j'imagine...


Accessoirement j'ai jugé bon de supprimer le leg de USERS pour GUEST car ce me semble, GUEST n'a que faire de tous les attributs de USERS puisque le guest n'est pas membre et donc absent de la BDD.

— Les sous-types héritent de l’identifiant de leur surtype, donc les attributs id_member, id_guest, id_staff, id_admin n’ont pas lieu d’être, et doivent passer au fil du rasoir....

Je pense mettre dans mon back off un bouton "Contacter le Staff" (envoyer un message à tous les gars ayant des droits). Du coup j'aurai juste à cibler tous les id_user from STAFF ?? En ce cas en effet ça sert à rien d'avoir des id spéciaux en fonction des rôles... Ockham ?!... Ahhh t'es là ^^, *Srlash!!*

— Avec PowerAMC, cochez la case « O » (obligatoire) pour les attributs des entités-types, sinon le bonhomme Null viendra ficher la patouille dans la base de données :

Dois je réellement rendre obligatoire tous les attributs de toutes mes tables ???
Mais si je fais ça je serai obligé de tout remplir pour les jeux de test et les gens pour s'inscrire devront remplir absolument tous les champs ! Il n'y aura pas de champs optionnels, je veux pas que l'inscrit soit obligé de remplir par exemple "company" ou "address". Corrigez moi si je fais erreur.

Tout cela pour dire qu’un nom d’entité-type s’écrit de préférence au singulier : USER mais pas USERS. Comme vous risquez une collision avec les termes SQL (qui ne cause pas encore français ), je vous engage à remplacer « USER » par « UTILISATEUR »...

Hahaaa ^^, j'ai pour habitude et règle de toujours tout écrire en anglais, mon code ou commentaires en dev', mes notes, certains tutos, les notices, enfin tout. Ceci afin de pouvoir dans l'avenir exporter mon travail, me faire pratiquer techniquement, puis parce que j'aime ça . C'est pour ça qu'il n'y a jamais rien en français dans mon travail en développement en général. C'est une de mes règles de travail parmi quelques autres, comme la normalisation des termes sur tous mes projets, tout ça ^^.

Bref du coup à part USERS je vois pas quoi mettre d'équivalent et logique .


Voici enfin sous vos yeux... ébahis xD la V3.3, ne boudons pas notre plaisir allons y gaiement pour les objections !




Si il n'y a plus rien à corrige de façon générale je peux éventuellement faire de plus gros plan pour aller dans le détails .
.
.
.

[fsmrel]

Bonjour Keizone,

N'y a t-il pas un principe disant que 2 associations ayant le même dessein devraient joindre leurs efforts car "L'association fait la force" ?!

J’en resterai à l’adage : « L’union fait la force ». En effet, si vous voulez savoir qui sont ceux qui ont noté des articles, qu’ils soient membres ou touristes, c’est l’opérateur UNION qui le permettra En SQL :

Code SQL :

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

1
2
3
4
5
SELECT id_user 
FROM   RATE_M
UNION
SELECT id_guest
FROM   RATE_G

Accessoirement j'ai jugé bon de supprimer le leg de USERS pour GUEST car ce me semble, GUEST n'a que faire de tous les attributs de USERS puisque le guest n'est pas membre et donc absent de la BDD.

Certes. Du coup les informations décrivant les touristes sont pour le moins parcimonieuses : il n’y a plus qu’un seul attribut dans l’en-tête de l’entité-type GUEST, à savoir id_guest.
Au stade SQL, pour un million de visiteurs anonymes, vous aurez une table GUEST d’un million de lignes avec une colonne id_guest, contenant les valeurs 1, 2, 3, ...., ce qui manque totalement d’intérêt...

On peut faire disparaître cette entité-type, au bénéfice de la représentation suivante :

MCD


Concernant l’identification relative, voyez par exemple ici.

MLD

Et ce malgré le fameux Mr Tabourier

Observez qu’il y a une énorme différence entre la ternaire RATE peccamineuse qui force les membres inscrits et les invités non inscrits à collaborer pour noter les articles, avec à la clef un viol de 4NF :



Et l’innocente ternaire qui pour Y. Tabourier manque seulement d’intérêt : elle n’en est pas moins parfaitement valide et respecte la 5NF :

Du coup c'est la même sauce pour "share" et "like" j'imagine...

Même punition, même motif, cf. ci-dessus...

Du coup j'aurai juste à cibler tous les id_user from STAFF

=>

Code SQL :

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

1
2
SELECT id_user
FROM   STAFF ;

Pour récupérer les données concernant les membres de profil STAFF :

Code SQL :

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

1
2
SELECT username, mail, ...
FROM   STAFF AS x INNER JOIN USER AS y ON x.id_user = y.id_user  ;

Dois je réellement rendre obligatoire tous les attributs de toutes mes tables ???

Oui ! Sinon, je le répète, le bonhomme Null fichera la patouille, et au lieu de raisonner sur la base d’une logique bivalente (vrai, faux), il faudra utiliser une logique ternaire (vrai, faux, peut-être).

Exemple : si la colonne C d’une table T est codée ainsi :

Code SQL :

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

1
2
3
4
CREATE TABLE T
...
C         VARCHAR (38)        NOT NULL 
...

Alors nul besoin d’un opérateur ISNULL (horresco referens !) pour surveiller la présence du bonhomme Null et éviter que les opérations donnent des résultats faux. Si dans une situation donnée C doit comporter au moins trois caractères, dans un programme on doit pouvoir se contenter très classiquement de coder :

Code en langage truc :

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

1
2
3
4
5
IF LEN(C) < 3 THEN
    Traitement de l’erreur  
ELSE
    C’est tout bon 
END IF

A défaut, si l’on n’a pas prévu « NOT NULL » dans la déclaration de la table T, le bonhomme ne manquera pas de se manifester et si l’on veut lui barrer la route, le traiter comme un délinquant, un facteur de trouble, bref, un semeur de m..., à moins de vouloir considérer Null comme ≥ 3 on sera obligé de coder :

Code en langage truc :

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

1
2
3
4
5
IF LEN(C) < 3 OR ISNULL(C) THEN
    Traitement de l’erreur  
ELSE
    C’est tout bon 
END IF

Et cela autant de fois que ce genre de situation peut se présenter, sinon gare aux résultats !

Concernant les attributs que vous mentionnez, il suffit d’utiliser la chaîne vide (rien à voir avec Null !) et la définir comme valeur par défaut par exemple :

Code SQL :

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

1
2
3
4
CREATE TABLE USER
...
Company         VARCHAR (32)       DEFAULT ''    NOT NULL 
...

[Keizone]

Bonjour Fsmrel,

Comme d'habitude je poste le MCD corrigé à la fin de ce post. Les corrections appliquées sont donc toujours celles de votre message auquel je répond.

...il n’y a plus qu’un attribut dans l’en-tête de l’entité-type GUEST, à savoir id_guest.
Au stade SQL, pour un million de visiteurs anonymes, vous aurez une table GUEST d’un million de lignes avec une colonne id_guest, ce qui manque totalement d’intérêt...

Oh mais c'est très juste ça, ça parait évident maintenant que je vous le dites...

MCD

N'ai-je pas le même résultat en ne gardant qu'une seule entité type GUEST ayant les attributs ("nb_share", "nb_like", "nb_rate" et "valor") et en faisant partir les 3 relations déjà présentes avec leur nom mais sans leurs attributs actuels ? Graphiquement et même au niveau SQL n''est ce pas plus approprié?

Ca ne pose pas de problème que votre GUEST_LIKE par exemple n'ai pas de PK (identifiant ?) ?? La doc Sybase me dit qu'une entité doit toujours avoir un identifiant.

Concernant la double cardinalité "1,1", PowerAMC me donne un avertissement sur les asso' bijectives entre 2 entités. Je laisse tomber ou ca veut dire qu'on peut améliorer ?

Oui ! Sinon, je le répète, le bonhomme Null fichera la patouille, et au lieu de raisonner sur la base d’une logique bivalente (vrai, faux), il faudra utiliser une logique ternaire (vrai, faux, peut-être).

Hmmm j'avoue que là j'ai du mal à suivre... Dans ma tete pour une valeur non obligatoire de type exemple varchar on a 2 possibilités, soit une string soit rien (donc Null). Je n'arrive pas à suivre pourquoi c'est pas bon.

Le fait de rendre obligatoire tous les attributs ne vas t-il pas aussi m'obliger à faire remplir absolument TOUS les champs à mes nouveaux inscrits ? Car si une valeur est obligatoire, si le nouveau ne remplit pas tout, l'ajout du nouveau USER ne se fera pas non ? C'est là mon inquiétude et où mon cerveau bug un peu ^^.
En fait mon objectif c'est d'avoir un champs formulaire avec les champs obligatoires et une fois inscrit, le membre peut remplir les champs facultatifs dans son profil utilisateur. Cela concorde t-il avec ce que vous me dites ?

Alors nul besoin d’un opérateur ISNULL pour surveiller la présence du bonhomme Null et éviter des résultats faux. Si dans une situation donnée C doit comporter au moins trois caractères, dans un programme on doit pouvoir se contenter de coder :

Code en langage truc :

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

1
2
3
4
5
IF LEN(C) < 3 THEN
    Traitement de l’erreur  
ELSE
    C’est tout bon 
END IF

Concernant les attributs que vous mentionnez, il suffit d’utiliser la chaîne vide (rien à voir avec Null !) et la définir comme valeur par défaut par exemple :

Code SQL :

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

1
2
3
4
CREATE TABLE USER
...
Company         VARCHAR (32)       DEFAULT ''    NOT NULL 
...

Je sens que l'explication est dans ces citations mais j'ai du mal à comprendre j'avoue. Lors de mon apprentissage des modèles relationnels, le formateur se servait souvent de NULL du coup j'ai appris comme ça, c'est pour ça que j'ai du mal...

(suite)

Une question dont on a pas parlé récemment sinon. J'ai mes attributs nb_share, nb_like etc.. Est ce vraiment utile de les garder ? Ou ne puis je pas les supprimer simplement et gérer cette donnée au niveau SQL avec un simple COUNT ? Ca changerai quoi ?

(suite)

Autre petite question. Les entités type MESSAGING (messagerie privé) et SERVER (état du serveur...) n'ont pas d'associations. J'ai lu sur la doc Sybase qu'une entité doit comporter au moins Une association. Qu'en pensez vous dois je obligatoirement créer une asso' "send" entre USERS et MESSAGING et une autre "connect" entre USERS et SERVER ?? Est ce utile ?
J'ai lu un cours où j'ai cru comprendre que les jointures se font sur des entités reliées par une asso'. Donc si pas de jointure théoriquement je ne peux pas style récupérer dynamiquement le pseudo de l' id_user:6 pour l'afficher dans le champs Expéditeur du formulaire de messagerie. Fais je erreur ?

(suite)

Avez vous noté l'héritage de MEMBERS sur STAFF et de STAFF sur MEMBERS ? C'est la bonne solution pour gérer les roles ou il y a mieux ?...



Oui je sais que je me pose énormément de questions, mais c'est parce que nous le valons bien ...


↓↓ MCCDDD ↓↓

[Keizone]

Up .

[fsmrel]

Bonsoir Keizone,

N'ai-je pas le même résultat en ne gardant qu'une seule entité type GUEST ayant les attributs ("nb_share", "nb_like", "nb_rate" et "valor") et en faisant partir les 3 relations déjà présentes avec leur nom mais sans leurs attributs actuels ? Graphiquement et même au niveau SQL n''est ce pas plus approprié?

A la manière dont j’ai procédé, je vous invite à présenter à votre tour le MCD et le MLD traduisant votre suggestion, vous serez alors sans doute surpris par le résultat obtenu...

Ca ne pose pas de problème que votre GUEST_LIKE par exemple n'ai pas de PK (identifiant ?) ?? La doc Sybase me dit qu'une entité doit toujours avoir un identifiant.

La doc Sybase a raison, mais pèche par omission. En effet, du fait de l’identification relative (symbolisée par la mise entre parenthèses de la cardinalité 1,1), l’entité-type GUEST_LIKE hérite automatiquement de l’identifiant de l’entité-type ARTICLE, sans pour autant que cet identifiant hérité ait besoin d’être mentionné pour l’héritière. Ainsi, à la production du MLD, et comme je l’ai montré dans mon message précédent, le diagramme dérivé est le suivant, où chaque table a bien sa clé en conséquence de l’héritage d’identifiant :

:

Concernant la double cardinalité "1,1", PowerAMC me donne un avertissement sur les asso' bijectives entre 2 entités. Je laisse tomber ou ca veut dire qu'on peut améliorer ?

En l’occurrence, PowerAMC génère le cycle, mais il ne devrait pas... Il existe des solutions pour gommer ce cycle.

Solution 1

Comme on le voit ci-dessous, PowerAMC a produit à tort la référence de GUEST_LIKE par ARTICLE (flèche rouge). Il suffit de supprimer cette référence.

Production de PowerAMC :




Après suppression de la référence non justifiée, tout rentre dans l’ordre (quand on supprime la référence, PowerAMC supprime aussi et à juste titre l’attribut Colonne_3 de l’en-tête de la table ARTICLE) :

En fait mon objectif c'est d'avoir un champ formulaire avec les champs obligatoires et une fois inscrit, le membre peut remplir les champs facultatifs dans son profil utilisateur. Cela concorde t-il avec ce que vous me dites ?

Oui, ça concorde. Comme je l’ai écrit dans mon message précédent, il suffit d’utiliser la chaîne vide (rien à voir avec Null ! sauf pour les utilisateurs d’Oracle dont les concepteurs se sont plantés...) et la définir comme valeur par défaut, par exemple :

Code SQL :

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

1
2
3
4
CREATE TABLE USER
...
Company         VARCHAR (32)       DEFAULT ''    NOT NULL        -- Chaîne vide par défaut 
...

Si l’utilisateur ne fournit rien pour l’attribut Company, la ligne correspondante de la table contiendra une chaîne de longueur 0, mais non marquée NULL. On reste sagement dans la logique binaire, laquelle est sans surprise.

Je vous renvoie à la dernière discussion en relation avec le sujet.

Je sens que l'explication est dans ces citations mais j'ai du mal à comprendre j'avoue.

Le sujet n’est pas simple et propre à polémiquer, j’en ai bien souvent débattu chez DVP, voyez par exemple ici. Pour le moment on va laisser reposer, sinon j’en ai pour 10 pages minimum d’explications.

Juste un mot à propos de la norme SQL 2003 qui comporte un bug sévère et certains des membres de ses comités se sont fait remonter les bretelles, car il s’agit quand même de LA référence. On y trouve donc cette perle :

The data type boolean comprises the distinct truth values True and False. Unless prohibited by a NOT NULL constraint, the boolean data type also supports the truth value Unknown as the null value. This specification does not make a distinction between the null value of the boolean data type and the truth value Unknown that is the result of an SQL <predicate>, <search condition>, or <boolean value expression>; they may be used interchangeably to mean exactly the same thing.

Je rappelle encore que si Unknown est une valeur, tel n'est pas le cas de Null qui n'est qu'un marqueur...

Lors de mon apprentissage des modèles relationnels, le formateur se servait souvent de NULL du coup j'ai appris comme ça, c'est pour ça que j'ai du mal...

Il n’y a qu’un Modèle Relationnel de Données (alias Théorie relationnelle, inventée en 1969 par Ted Codd) et le bonhomme Null y est hors-la-loi. La norme SQL légalise Null, mais SQL est l’abréviation de Sorry Query Language, c'est un langage qui a un goût de relationnel mais n'est pas relationnel. Moi aussi pendant un temps j’ai enseigné sans tenir Null à l’écart, mais sur le terrain, en modélisant chez mes clients, je me suis vite rendu compte que les avertissements de C.J. Date étaient particulièrement fondés et j'ai banni Null.

A propos de Date, je le cite et le traduis (The Relational Database Dictionary chez Apress) :

Null : Un montage, utilisé en particulier dans SQL, pour représenter l’information absente. Note : Par définition les nulls ne sont pas des valeurs (on les appelle parfois marques) ; il s’ensuit qu’un « type » qui « contient un null » n’est pas un type, un « tuple » qui « contient un null » n’est pas un tuple, une relation qui « contient un null » n’est pas une relation, qu’une relvar qui « contient un null » n’est pas une « relvar » [...]

Autre petite question. Les entités type MESSAGING (messagerie privé) et SERVER (état du serveur...) n'ont pas d'associations. J'ai lu sur la doc Sybase qu'une entité doit comporter au moins Une association.

La doc Sybase a faux. C’est une question posée depuis trente ans chez les merisiens et qui a très vite trouvé sa réponse : il est des situations où une entité-type peut ne pas avoir de relations avec les autres. Voyez par exemple le cas de la périodicité chez ecarbill. devhafid avait lui aussi des états d’âme...
Je ne vois pas a priori de relation entre un serveur et les utilisateurs si tout le monde est sur le même serveur. Ça n’aurait de sens que s’il fallait ventiler les utilisateurs sur des serveurs particuliers.

Donc si pas de jointure théoriquement je ne peux pas style récupérer dynamiquement le pseudo de l' id_user:6 pour l'afficher dans le champs Expéditeur du formulaire de messagerie.

Précisez votre pensée. A quels attributs de USERS correspondent les attributs From et To de MESSAGING ? (En passant, vous risquez des ennuis avec SQL en utilisant des mots réservés comme From...)

J'ai lu un cours où j'ai cru comprendre que les jointures se font sur des entités reliées par une asso.

Encore une légende à détruire. Exemple pris chez Georges Gardarin (Bases de données, Les systèmes et leurs langages), où l’on marie des relvars indépendantes :



En SQL :

Code SQL :

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

1
2
SELECT *
FROM   VINS-9 AS x INNER JOIN VITICULTEURS AS y ON x.Cru = y.Ville ;

Une question dont on a pas parlé récemment sinon. J'ai mes attributs nb_share, nb_like etc.. Est ce vraiment utile de les garder ? Ou ne puis je pas les supprimer simplement et gérer cette donnée au niveau SQL avec un simple COUNT ? Ca changerai quoi ?

Si vous conservez ces attributs alors qu’on peut compter avec COUNT, il faudra garantir la redondance, donc sortir l’artillerie lourde de triggers, or la redondance voilà l’ennemi, donc en l’occurrence on élimine les attributs nb_share, etc.

Avez vous noté l'héritage de MEMBERS sur STAFF et de STAFF sur MEMBERS ? C'est la bonne solution pour gérer les roles ou il y a mieux ?...

Vu les droits particuliers de plus en plus stricts que vous donnez à ces membres, c’est bon.


Je ne sais plus si j'ai évoqué ce point, en tout cas selon votre MCD, un utilisateur X peut modifier ou supprimer les articles de l’utilisateur Y. L’utilisateur X peut aussi charger des images pour l’article de Y. Est-ce voulu ?
L’association UPLOAD est porteuse d’un attribut qui redonde avec celui qui est porté par IMAGE. L’association REMOVE est porteuse d’un attribut qui n’aura pas le temps d’être valorisé puisque les images correspondantes ne seront plus là...

[Keizone]

A la manière dont j’ai procédé, je vous invite à présenter à votre tour le MCD et le MLD traduisant votre suggestion, vous serez alors sans doute surpris par le résultat obtenu...

D'accord, cf le MCD en bas . Cela créé une "Circularité formée de liens obligatoires", sorte de boucle, pas bon je présume ^^.

Comme on le voit ci-dessous, PowerAMC a produit à tort la référence de GUEST_LIKE par ARTICLE (flèche rouge). Il suffit de supprimer cette référence.

Production de PowerAMC :

Hmmm d'accord, la subtilité est intéressante. Sur le MPD en effet il y a cette fameuse flèche. Je n'ai donc qu'à supprimer le trajet de GUEST à ARTICLES.
Quels dégâts cela provoquerai si je ne le faisais pas ?

Oui, ça concorde... il suffit d’utiliser la chaîne vide (rien à voir avec Null ! sauf pour les utilisateurs d’Oracle dont les concepteurs se sont plantés...) et la définir comme valeur par défaut, par exemple :

Parfait, dommage qu'on ne puisse définir cette valeur par défaut à l'étape MCD.

Juste un mot à propos de la norme SQL 2003 qui comporte un bug sévère ...soit... cette perle :

...This specification does not make a distinction between the null value of the boolean data type and the truth value Unknown ...

Je rappelle que si Unknown est une valeur, tel n'est pas le cas de Null qui n'est qu'un marqueur...

Whooo bon ok. "Unknown" hmmm si je comprends bien est l'équivalent de la chaîne vide pour une STRING. Donc en effet le NULL qui est un marqueur vient perturber la chose. Je pense comprendre.

Ca tombe bien que vous abordiez ce point, lors de la génération de la base after the MPD, j'ai le choix entre telle ou telle version de MySQL. Je pensais choisir MySQL 5.0, c'est le bon choix ?
Dans mon second métier (Infographiste) on a souvent l'habitude de se servir d'anciennes normes pour profiter de leur stabilité, d'où mon interrogation.

La doc Sybase a faux. C’est une question posée depuis trente ans chez les merisiens... il est des situations où une entité-type peut ne pas avoir de relations avec les autres.

Voilà un parfait exemple où la théorie n'a d'égale que la pratique ^^. En ce cas je laisse.

Aparté consentez vous que l'entité SERVER ai son utilité ? Je souhaite pouvoir afficher l'état du serveur sur le site dans une partie dédiée, j'ai bien besoin d'une table n'est ce pas ? Le plus pratique disons. J'ai besoin de pouvoir faire un historique des crash serveur par exemple, car mon site sera hébergé sur le data serveur personnel d'un "ami".

Pour MESSAGING voilà à quoi je pensais à vrai dire niveau asso' (voir MCD plus bas).

Encore une légende à détruire. Exemple pris chez Georges Gardarin (Bases de données, Les systèmes et leurs langages), où l’on marie des relvars indépendantes...

Je tiens à souligner qu'après lecture de ce qui a suivit, mes neurones se sont mis en grève . Je vous serez grès de déposer un prévis la prochaine fois (je plaisante in ^^, continuez !).

Si vous conservez ces attributs alors qu’on peut compter avec COUNT, il faudra garantir la redondance, donc sortir l’artillerie lourde de triggers, or voilà l’ennemi, donc en on élimine les attributs nb_share, etc.

En fait j'ai besoin de pouvoir récupérer le nombre de "like" (facebook) par article et commentaires, le nombre de "share" (=> partage facebook) et le nombre de notes (internes au site). Du coup instinctivement je me dis que pour ça je dois les stocker en base. Ais je raison ?

Vaut-il mieux stocker ces 3 données dans ARTICLES en laissant notre table GUEST et nos relations telles qu'elles ? Où les supprimer tout court du MCD ? Du coup pour gérer les like et share de GUEST ca change tout lol.
Je suis incapable de répondre à cette question aujourd'hui. Et elle me pose beaucoup de problème, qu'il faut résoudre.

...selon votre MCD, un utilisateur X peut modifier ou supprimer les articles de l’utilisateur Y. L’utilisateur X peut aussi charger des images pour l’article de Y. Est-ce voulu ?
L’association UPLOAD est porteuse d’un attribut qui redonde avec celui porté par IMAGE. L’association REMOVE est porteuse d’un attribut qui n’aura pas le temps d’être valorisé puisque les images ne seront plus là...

Hmmm mon besoin est qu'un utilisateur X puisse modifier et uploader sur SES propres articles (ceux de X donc). Il ne doit Pas pouvoir uploader ni modifier l'article d'autrui. Je pensais juste à un truc du style :
- "si le user_id de l'auteur est le même que l'user_id de celui qui veut modifier ou uploader, alors tu peux modifier ou uploader sur l'article en question". Dites moi tout .

Pour l'asso' REMOVE. Et bien... (je vais me pendre je reviens ) vous avez raison ^^. En fait avant de commencer mon MCD j'ai fais un diagramme de Use Case, ce pour quoi j'ai eu tendance à matérialiser toutes les actions possibles sur le MCD, ce qui j'imagine est une erreur...
J'ai souhaité en fait conserver un historique des suppression d'image dans la galerie du membre en question.


↓↓↓ MCD ↓↓↓

[fsmrel]

Bonsoir Keizone,

D'accord, cf. le MCD en bas. Cela créé une "Circularité formée de liens obligatoires", sorte de boucle, pas bon je présume ^^.

Vous avez établi trois cycles entre GUEST et ARTICLE, et selon votre MCD, la base de données peut comporter un nombre quelconque d’invités. Partant de là, prenons le cas de l'association LIKE : l'invité i1 doit aimer au moins un et au plus un article, disons a1 et cet article doit être aimé par un et un seul invité, disons i2, lequel doit aimer un et un seul article, disons a2 lequel doit être aimé par un seul invité i3, etc. Vu les cardinalités 1,1, chaque invité doit aimer au moins et au plus un article, et comme on traite d’ensembles finis, à un moment donné l’invité ij devra aimer un article déjà aimé par un autre invité alors que ça ne pourra pas être possible (variante de la chaise musicale...) : comme vous présumez, ça n’est pas bon et PowerAMC vous prévient.

En fait j'ai besoin de pouvoir récupérer le nombre de "like" (facebook) par article et commentaires, le nombre de "share" (=> partage facebook) et le nombre de notes (internes au site). Du coup instinctivement je me dis que pour ça je dois les stocker en base. Ais je raison ?
Vaut-il mieux stocker ces 3 données dans ARTICLES en laissant notre table GUEST et nos relations telles qu'elles ? Où les supprimer tout court du MCD ? Du coup pour gérer les like et share de GUEST ca change tout lol.

J’ai déjà exprimé mon point de vue dans le message #15 :

MCD


MLD


La table GUEST_LIKE sert à mémoriser le nombre de LIKE pour un article, la table GUEST_SHARE sert à mémoriser le nombre de SHARE, la table GUEST_RATE sert à mémoriser le nombre de RATE et le nombre de fois ou une note a été donnée par les utilisateurs.

Sur le MPD en effet il y a cette fameuse flèche. Je n'ai donc qu'à supprimer le trajet de GUEST à ARTICLES.
Quels dégâts cela provoquerai si je ne le faisais pas ?

Les dégâts que provoquent les cycles...

Dommage qu'on ne puisse définir cette valeur par défaut à l'étape MCD.

PowerAMC permet de définir les valeurs par défaut dès le MCD. En l’occurrence il suffit d'entrer « '' » dans la case qui va bien :

"Unknown" hmmm si je comprends bien est l'équivalent de la chaîne vide pour une STRING.

Non ! La chaîne vide est une chaîne ! On la manipule dans le contexte de la logique traditionnelle, bivalente, avec ses deux valeurs de vérité vrai et faux. Si la variable A vaut '' et la variable B vaut 'abc', la concaténation de A et B vaut 'abc'.
Si la variable A est marquée unknown, la concaténation avec B donnera unknown.

C’est une conséquence de l’application des règles du jeu définies par les tables vérités de la logique trivalente (f est l’abréviation de faux, v est l’abréviation de faux, et i l’abréviation de inconnu (unknown)) :

 
NON |          OU | v i f        ET | v i f  
----|---       ---|-------       ---|-------
 v  | f         v | v v v         v | v i f
 i  | i         i | v i i         i | i i f
 f  | v         f | v i f         f | f f f 

En vertu de ces règles, la concaténation de unknown et 'abc' donne bien unknown.

j'ai le choix entre telle ou telle version de MySQL. Je pensais choisir MySQL 5.0, c'est le bon choix ?

Je suis mal placé pour conseiller un choix de version MySQL car je ne l’utilise pas. La question est à poser sur le forum MySQL.

Je souhaite pouvoir afficher l'état du serveur sur le site dans une partie dédiée, j'ai bien besoin d'une table n'est ce pas ?

Normalement, oui.

J'ai besoin de pouvoir faire un historique des crash serveur

Il faudra donc modéliser la (ou les) table(s) à cet effet.

mon besoin est qu'un utilisateur X puisse modifier et uploader sur SES propres articles (ceux de X donc). Il ne doit Pas pouvoir uploader ni modifier l'article d'autrui.

Ma question portait sur les images. Seul l’utilisateur X peut charger les images contenues dans ses articles ? Concernant les suppressions des images, seul l’utilisateur X peut supprimer les images contenues dans ses articles ?

Mais parlons de la modification d’un article : si vous utilisez l’identification relative (cardinalités 1,1 mises entre parenthèses) :

[MEMBRE]----0,N----(POST)----(1,1)----[ARTICLE]

Alors seul celui qui a créé le message pourra le modifier. En effet, la clé primaire de la table ARTICLE sera la paire {idUser, idArticle} et donc la table EDIT sera porteuse d’une clé étrangère {idUser, idArticle} dont les valeurs seront exactement des valeurs de la clé primaire de la table ARTICLE. Si l’utilisateur u1 a pondu l’article a1, la clé primaire de la table ARTICLE prendra en l’occurrence la valeur <u1, a1> et seule cette valeur sera acceptée dans la table EDIT en relation avec l’article concerné. A noter que les attributs post_date et edit_date migrent dans la table ARTICLE.

Quant à la suppression logique d’un article, l’association DELETE doit disparaître, et par contre vous pouvez par exemple définir un sous-type ARTICLE_SUPPRIMÉ hébergeant la date de suppression, ou bien établir un lien direct entre les tables MEMBRE et ARTICLE_SUPPRIMÉ et y déménager l’article au moment de sa suppression.