Discussion :

[fsmrel]

Ce qui donne :

Pas d’accord, car vous représentez une contrainte d’égalité, c'est-à-dire une double inclusion :

Un post ne peut avoir été créé (par un auteur) qu’à la condition d’avoir été modifié, et un post ne peut avoir été modifié qu’à la condition d’avoir été créé... Il y a manifestement une condition de trop.

Si donc seul son auteur peut modifier un post, autant modéliser directement ainsi :


MCD



Pour mémoire : la mise entre parenthèses de la cardinalité 1,1, signifie que, dans le cas de PowerAMC, on utilise l’identification relative.


MLD




N.B. Si dans votre représentation l’attribut DateModification est du type Date, vous n’aurez droit qu’à une modification par jour, s’il est du type Timestamp, pas de problème. Par ailleurs, pourquoi un trigger ? A quoi ressemblerait-il ?

[Richard_35]

Bonjour Fsmrel,

Code :

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

1
2
3
4
5
6
7
8
9
CREATE TABLE Post
    (
        IdPost              Int         NOT NULL
      , IdUtilisateur       Int         NOT NULL
      , ...
      , DateHeureAjout      Datetime    NOT NULL
      , DateHeureModif      Datetime    NOT NULL
    , ....
    ) ;

Alors le bonhomme Null ne peut pas polluer la table : il n’y a rien à redire.

==> n'est pas valable car, quelle sera la valeur de DateHeureModif pour les posts non modifiés ?

Un numéro dans une rue ne fait pas l’objet d’opérations arithmétiques, ainsi je ne sais pas quel sens donner à l’addition : 2 BIS + 12 + 4 TER, ou à la division 130/2. Ce numéro est du type caractère, on est ramené au cas précédent.

==> l'idéal est de séparer le n° (entier) de la seconde partie (alpha-numérique : "bis", "ter", ...). Nous pourrions, dès lors, connaître le nombre de n° existant entre deux n° de rue.


2 autres sujets ont été abordés :

• la limite acceptable de la présence du bonhomme NULL ;
• la pertinence du MCD user-création/modification de post.

La limite acceptable de la présence du bonhomme NULL :
Je pense qu'il n'y a pas de vérité universelle en la matière et chacun les fixe à sa guise sachant que laisser des bonhommes NULL partout n'est pas une bonne solution. De là à n'en laisser nulle part...

Comme dit précédemment :

Personnellement, j'applique la règle du non-bonhomme-NULL uniquement pour les clés étrangères. C'est complètement arbitraire mais, de mon point de vue, il faut bien trancher quelque part !...

Votre limite acceptable se situe au niveau du type de caractère (CHAR, VARCHAR, STRING, ...) : OK, c'est noté.


La pertinence du MCD user-création/modification de post :
Désolé si la représentation graphique est erronée. Dans JMerise, je n'en ai pas trouvé d'autre.

N.B. Si dans votre représentation l’attribut DateModification est du type Date, vous n’aurez droit qu’à une modification par jour, s’il est du type Timestamp, pas de problème.

==> bien évidemment, il ne faut pas que cet attribut soit de type Date (nom : DateHeureModif, précédemment).

Votre MCD est pertinent, mais il externalise DateHeureModif (table à part entière), ce qui nous ramène à la question initiale : cela vaut-il le coup d'externaliser ce genre d'attribut ?

Par ailleurs, pourquoi un trigger ? A quoi ressemblerait-il ?

==> un ultime contrôle qui n'accepterait, avant UPDATE, que user modif=user création. Un contrôle avant la saisie (ou un blocage, comme sur DVP) serait nécessaire.

[userparis]

==> il n'y a pas de fusion :

• soit, tu modifies un message (un post) et, si tu veux le modifier, c'est que tu veux remplacer un contenu par un autre sans conserver l'ancien ;

Hello,

C'est le fonctionnement du forum developpez.net, d'ailleurs. Tu ne peux modifier que les posts (les messages) que tu as créés : dans ce cas, le contenu modifié remplace l'ancien contenu.

quelque chose m'échappe sur le forum developpez.net, on a bien tout l'historique d'un topic lors de la visualisation, il faut bien que chaque message faisant partie du fil soit stocké indépendamment et non fusionné dans un même champs ?

[Richard_35]

Bonjour Userparis,

... on a bien tout l'historique d'un topic lors de la visualisation, il faut bien que chaque message faisant partie du fil soit stocké indépendamment et non fusionné dans un même champs ?

==> évidemment, sinon il n'y aurait qu'un seul message par discussion... A noter que l'entité Message (table) comporte plusieurs attributs (champs).

En clair, sur DVP, les tables (non exhaustives) devraient avoir la structure suivante, ou approchant :

User(IdUser, ...) ;
Discussion(IdDiscussion, #IdUserDiscussion, TitreDiscussion, ..., DateHeureCreation, DateHeureModification) ==> je ne sais pas si l'on peut modifier les attributs d'une discussion, une fois celle-ci créée. Je pense que oui : modification du titre ou autre ;
Message(IdMessage, #IdDiscussion, #IdUserMessage, Texte, ..., DateHeureCreation, DateHeureModification)==> je ne sais pas si les modifications des messages sont historisées. Je ne pense pas. Du moins, elles ne sont pas visibles par les utilisateurs (nous).

[userparis]

Hello,

Considérez en effet ce MCD où l’association R est porteuse d’une propriété et où la patte connectant R et B est porteuse d’une cardinalité 1,1. Que vous le vouliez ou non, AMC vérifie ce qu’on a représenté et, si c’est bon, génère le MLD attendu :

Ce n'est pas ce que j'ai retenu de mes cours et je ne sais pas comment AMC fonctionne. Ce que j'ai retenu c'est dès que une propriété dans une association alors création d'une table pour cette association et forcemment N et N de chaque côté. Mais je n'insiste pas, et puis mes cours sont très loin...

Supposons maintenant que ces modèles aient été créés pour la maison d’édition Dubicobit, et remplaçons les termes « A » par « PERSONNE », « B » par « ARTICLE », « R » par « ECRIRE » et « S » par « CORRIGER ».

Dubicobit a imposé les règles suivantes (entre autres, bien sûr) :

— Un article est écrit par au moins et au plus une personne ;

— Un article est corrigé par au moins et au plus une personne.

Selon l’en-tête de la table B, l’article « B1 » a été écrit par la personne « A1 » et corrigé par la personne « A_A1 ». Ainsi, l’article « Légendes merisiennes » a été écrit par Raoul et corrigé par Fernand. Ça ne vous paraît pas cohérent ?

Donc cela veut dire que si un article n'est jamais corrigé, on a un champs vide en table toute la durée de vie de la BDD ? Est-ce genant ?

Après, si la règle de gestion est que un article est forcémment corrigé par une personne, alors on a un champs vide en table de l'écriture de l'article à la correction.

[Richard_35]

Bonjour Userparis,

Donc cela veut dire que si un article n'est jamais corrigé, on a un champs vide en table toute la durée de vie de la BDD ? Est-ce genant ?

==> pour moi, ce n'est pas gênant (voir le post sur le bonhomme NULL) :

User(IdUser, ...) ;
Discussion(IdDiscussion, #IdUserDiscussion, TitreDiscussion, ..., DateHeureCreation, DateHeureModification) ;
Message(IdMessage, #IdDiscussion, #IdUserMessage, Texte, ..., DateHeureCreation, DateHeureModification).

Si tu veux éviter le bonhomme NULL dans la date de modification, alors il faut l'externaliser :

User(IdUser, ...) ;
Discussion(IdDiscussion, #IdUserDiscussion, TitreDiscussion, ..., DateHeureCreation) ;
Discussion_Modification(IdDiscussion, DateHeureModification) ;
Message(IdMessage, #IdDiscussion, #IdUserMessage, Texte, ..., DateHeureCreation) ;
Message_Modification(IdMessage, DateHeureModification).