Discussion :

[Alixe80]

Bonjour,
je suis occupé à essayer de créer un MCD pour un site web et je me pose quelques questions pour lesquels je viens demander un peu d'aide
Alors voilà, j'ai des vidéos que n'importe quel visiteur du site peut noter. Je ne sais pas trop comment modéliser ça.
J'avais pensé de cette façon:


mais ceci implique que je vais avoir une table visiteur hors ce ne sera pas le cas. Je pensais juste créer une table note_video qui contiendrait une clée étrangère de la vidéo, l'ip du visiteur et la note donnée....

J'ai un peu le même souci pour modéliser un livre d'or. N'importe quel visiteur peut poster un message, du moment qu'il écrit son nom et un message.
Tout se trouve dans la même table à savoir livre d'or, mais comment modéliser ça... Je créé simplement une entité isolée "livre" sans association, rien?
D'avance merci pour le coup de main.

[Alixe80]

Mon sujet ne suscite pas bcp de réactions, pour ne pas dire aucune
J'ai fini mon MCD complet et j'espère qu'une bonne âme, passera par ici pour me donner un avis.
Il s'agit d'un site de club sportif.
Mon mcd:



Tant que j'y suis, ne principe, j'ai un CIF au niveau de staff - fonction - salle. Je suis sous POWERAMC et ne parviens pas à le représenter.
Quelqu'un sait comment on fait?

D'avance merci

[Richard_35]

Bonjour Alixe80,

Je ne connais pas le formalisme de POWERAMC, mais quelques remarques sur ton MCD :

• 1 message sur le livre d'or est écrit par 1 et 1 seul utilisateur, non ?
• la partie Video/Visiteur est OK, mais, peut-être, ajouter la date de la note ?
• la partie isolée de Image/Sponsor/Presse est incompréhensible : il faudrait que tu expliques les règles de gestion ;
• une personne habite dans 1 et 1 seule ville ;
• une ville peut héberger plusieurs salles, non ?
• une salle n'est située que dans 1 et 1 seule ville ;
• la partie Staff/Fonction/Salle est incompréhensible : il faudrait que tu expliques les règles de gestion.

[Alixe80]

Aaah merci, enfin quelqu'un qui réagit à mon post. Je commençais à désespérer.
Merci pour tes remarques.
Je vais les reprendre une par une pour te répondre:

• 1 message sur le livre d'or est écrit par 1 et 1 seul utilisateur, non ?
  
  En effet, un message n'est écrit que par un seul visiteur mais en fait, ce que j'ai représenté dans mon MCD, ce n'est pas ça. Un utilisateur, c'est quelqu'un qui a un accès "admin". Donc dans la relation utilisateur -> valider->message, c'est un admin qui valide un message poster par un visiteur. Tant que ce message n'est pas valider, il n'apparait pas sur le site.... Donc un message peut ne pas être valider, ou peut l'être par 1 utilisateur (0,1).
  Je n'ai pas représenter le visiteur dans cette relation. Je ne savais pas si je devais le faire. Je l'ai fait avec le sondage vidéo, mais la encore, je ne savais pas si je devrais....
  
• la partie Video/Visiteur est OK, mais, peut-être, ajouter la date de la note ?
  
  Oui, pourquoi pas, ça peut être intéressant.
  
• la partie isolée de Image/Sponsor/Presse est incompréhensible : il faudrait que tu expliques les règles de gestion ;
  
  C'est une relation d'héritage. Sponsors et Presse héritent de image.
  Les sponsors sont sous forme d'image uniquement. La seule donnée que j'ai en plus par rapport à la table image, c'est le nom du sponsor/donateur (j'ai ajouté depuis aussi l'url du site du sponsor).
  Même chose pour les articles de presse. Ils sont au format jpeg donc ils héritent de tous les attributs de la table image, et en plus, ils ont d'autres attributs telles que le nom de la source (le journal), la date, etc...
  
• une personne habite dans 1 et 1 seule ville ;
  
  Une personne habite effectivement dans une et une seule ville, mais il est possible que son adresse n'ait pas été communiquée. C'est pour quoi j'ai mis une relation 0,1.
• une ville peut héberger plusieurs salles, non ?
  
  Non, il n'y a qu'une salle par ville.
• une salle n'est située que dans 1 et 1 seule ville ;
  
  En effet. J'ai corrigé l'erreur, merci.
• la partie Staff/Fonction/Salle est incompréhensible : il faudrait que tu expliques les règles de gestion.
  
  Si une personne fait partie du staff, c'est qu'il a au moins une fonction dans salle
  Une personne du staff n'a qu'une seule fonction par salle, mais peut avoir une autre fonction dans une autre salle.
  Je crois que j'ai un cif (si j'ai bien compris ce que c'est) puisqu'une personne du staff ne peut avoir qu'une fonction que dans une salle. (mais il peut en avoir une autre dans une autre salle)

[Richard_35]

1 message sur le livre d'or est écrit par 1 et 1 seul utilisateur, non ?
En effet, un message n'est écrit que par un seul visiteur mais en fait, ce que j'ai représenté dans mon MCD, ce n'est pas ça. Un utilisateur, c'est quelqu'un qui a un accès "admin". Donc dans la relation utilisateur -> valider->message, c'est un admin qui valide un message poster par un visiteur. Tant que ce message n'est pas valider, il n'apparait pas sur le site.... Donc un message peut ne pas être valider, ou peut l'être par 1 utilisateur (0,1).

Je n'ai pas représenter le visiteur dans cette relation. Je ne savais pas si je devais le faire. Je l'ai fait avec le sondage vidéo, mais la encore, je ne savais pas si je devrais....

==> eh bien, oui, il faut représenter toutes les relations. D'autre part, un visiteur (adresse IP) ne peut-il pas créer un post ?

la partie Video/Visiteur est OK, mais, peut-être, ajouter la date de la note ?
Oui, pourquoi pas, ça peut être intéressant.

==> OK.

la partie isolée de Image/Sponsor/Presse est incompréhensible : il faudrait que tu expliques les règles de gestion ;
C'est une relation d'héritage. Sponsors et Presse héritent de image.
Les sponsors sont sous forme d'image uniquement. La seule donnée que j'ai en plus par rapport à la table image, c'est le nom du sponsor/donateur (j'ai ajouté depuis aussi l'url du site du sponsor).
Même chose pour les articles de presse. Ils sont au format jpeg donc ils héritent de tous les attributs de la table image, et en plus, ils ont d'autres attributs telles que le nom de la source (le journal), la date, etc...

==> hum... il ne s'agit pas de mêmes objets conceptuels. De mon point de vue, il faudrait créer une entité Sponsor_Donateur et une entité Journal, puis les relations avec Image qui vont bien. Il ne s'agit pas, là, d'héritage à proprement parler (mais d'un détournement d'héritage !...). En effet, dans le cas que tu présentes un même journal pourrait être représenté par plusieurs images (par exemple). Idem pour un sponsor/donateur.
En aparté, les objets hérités ne doivent pas contenir d'identifiant propre : leur identifiant est celui du parent (d'où, l'héritage).

une personne habite dans 1 et 1 seule ville ;
Une personne habite effectivement dans une et une seule ville, mais il est possible que son adresse n'ait pas été communiquée. C'est pour quoi j'ai mis une relation 0,1.

==> OK.

une ville peut héberger plusieurs salles, non ?
Non, il n'y a qu'une salle par ville.

==> OK, si c'est ta règle de gestion.

une salle n'est située que dans 1 et 1 seule ville ;
En effet. J'ai corrigé l'erreur, merci.

==> OK.

la partie Staff/Fonction/Salle est incompréhensible : il faudrait que tu expliques les règles de gestion.
Si une personne fait partie du staff, c'est qu'il a au moins une fonction dans salle
Une personne du staff n'a qu'une seule fonction par salle, mais peut avoir une autre fonction dans une autre salle.
Je crois que j'ai un cif (si j'ai bien compris ce que c'est) puisqu'une personne du staff ne peut avoir qu'une fonction que dans une salle. (mais il peut en avoir une autre dans une autre salle)

==> OK.


Suggestion (partielle) :



A noter que, dans ce MCD, l'association entre les 4 entités s'effectue au moment de l'affectation de la salle. Les triplés Personnes/Staff/Fonction sont formés "à l'arrache"... sans pré-paramétrage.

[Alixe80]

Merci pour tous ces conseils. J'ai changé mon MCD:



Voilà, j'espère que cette fois, c'est bon

[Richard_35]

Bonjour Alixe80,

Les identifiants des entités "enfant" sont toujours présents.

[Alixe80]

Ah oui, je viens de le modifier
Un grand merci pour ton aide en tout cas!

[userparis]

Hello,

je suis tombé sur ton topic car je réalise actuellement un MCD avec quelques ressemblance à celui que tu décris notamment pour la partie Personne et Utilisateur.

Et j'ai remarqué quelque chose dans ton MCD qui m'a interpellé, je pense qu'il y a une incohérence entre les entités Utilisateur et Post pour les associations Ecrire et Modifier.

En fait, si je ne dis pas de betise, la représentation graphique des associations Ecrire et Modifer que tu as fait n'est pas cohérente avec les cardinalités.

Pour avoir des propriétés dans une association, il faut que l'on ai N et N pour chaque entité de l'association et dans ce cas on aboutit à la création d'une nouvelle table qui représente l'association avec les ID des tables de l'association et les propriétés de l'association.

Avec ton schéma, dans quelle table vas-tu positionner les propriétés des associations Ecrire et Modifer ?

[Richard_35]

Bonjour Userparis,

Pour avoir des propriétés dans une association, il faut que l'on ai N et N pour chaque entité de l'association

==> c'est, en partie vrai !

Je te conseille la lecture de ce billet de CinePhil qui balaye tous les cas possibles.

Pour le table Post :

Post(IdPost, #IdUtilisateur, ..., DateHeureAjout, DateHeureModif)

ou, pour les puristes :

Post(IdPost, #IdUtilisateur, ..., DateHeureAjout)
PostModif(IdPost, DateHeureModification) ==> pour éviter le bonhomme NULL (pas nécessaire, à mon avis)

[fsmrel]

Bonjour,

Pour avoir des propriétés dans une association, il faut que l'on ai N et N pour chaque entité de l'association

En voilà une affirmation à étayer... Quelles preuves formelles, tangibles, apportez-vous ? En quoi le fait faire figurer des propriétés qui n’ont de signification qu’au sein d’une association du genre x,1/y,N serait-il non pertinent ou dangereux ? Ne serait-ce pas plutôt parce que d’autres répètent depuis si longtemps cette affirmation gratuite, que l’ai relevée il y a maintenant 25 ans ?

Démontrez l’absurdité sémantique, voire logique, mathématique, de cette représentation :

[ENTREPRISE]---0,N--------(EMBAUCHER {DateEmbauche})--------0,1----[ PERSONNE]

La date d’embauche d’une personne dans une entreprise n’aurait-elle donc de sens qu’en tant que propriété intrinsèque de la personne, au même titre que son nom et son prénom, en dehors de toute relation (si l’on vous suit) avec l’entreprise ? Que dire à propos d’une personne qui n’a jamais été embauchée de sa vie ?

[fsmrel]

pour les puristes

En réalité pour les logiciens, tenants de la logique classique selon laquelle il n’y a que deux valeurs de vérité : la vérité et la fausseté, lesquelles sont au cœur des optimiseurs des SGBDR (et de l’algèbre de Boole, soit dit en passant). Nuance...

[Richard_35]

Oui, je comprends Fsmrel, c'est le débat éternel sur le bonhomme NULL qui a fait couler beaucoup d'encre (virtuelle).

Cela vaut-il le coup de passer de :

Post(IdPost, #IdUtilisateur, ..., DateHeureAjout, DateHeureModif)

à

Post(IdPost, #IdUtilisateur, ..., DateHeureAjout)
PostModif(#IdPost, DateHeureModification)

uniquement à cause du fait que la date de modification n'est pas toujours renseignée ?

Dans ce cas, tous les attributs de type "commentaires" ou "observations" devraient être externalisés. Ainsi que que ceux représentant, par exemple, le n° de la rue d'une adresse (car une adresse ne comporte pas toujours de n° de rue).

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

[userparis]

Bonjour Fsmrel et Richard,

Quand je lis la représentaion du modele conceptuel tel que shématisé dans le post, je constate deux choses comme je l'ai dis :
- Une association qui n'aboutit pas à la création d'une table dans le modèle relationelle ne doit selon moi (et mes cours merise ...) pas comporter de propriété (ici date ajout post pour l'association ecrire et date modif post pour modifier). Je parle la de la représentation graphique (MCD). Et pour une association qui aboutit à la création d'une table on a N et N pour toutes les entités de l'association.
- Ensuite tout lien qui part d'une entité en N vers une autre entité en 1 doit envoyer sont identifiant vers l'entité 1.
Il me semble mais la c'est à vérifier que Ici on a deux liens "différent" qui vont vers la même entité, et c'est la que je dis qu'il faut vérifier mais est-ce que cela veut dire qu'on envoie deux fois l'identifiant ID_Utilisateur à l'entité POST ? ça me parait pas cohérent. Et en modèle relationnelle on aurait deux fois la même réf externe ? enfin quelque chose cloche pour moi.

Enfin pour finir, sur les cardinalité de l'association modifier si je les lis tel que décrite, un utilisateur modifie 0 ou plusieur post >> OK
mais un post est modifié par un et un seul utilisateur ?

un exemple de ce qu'on aura dans la table post :

Table Post

Id post	Id utilisateur
1	1

L'utilisateur avec l'ID 1 crée le post avec l'ID 1 >> OK
L'utilisateur avec l'ID 2 modifie le post avec l'ID 1 >> Il se passe quoi ? on vient mettre a jour la ref externe en écrasant lID utilisateur 1 par L'ID utilisateur 2 ?
On ne sait donc plus que l'utilisateur 1 a crée le post 1 ? en plus L'utilisateur 2 récupère le contenu du post qui n'est pas le sien c a d celui de l'uti 1 ?
L'utilisateur avec l'ID 3 modifie le post avec l'ID 1 >> On ne sait plus qui a crée le post ni que l'utilisateur 2 l'a modifié ?


Arretez moi si je me trompe mais je crois que quelque chose cloche.

Pour moi on a N et N de chaque coté sur l'association modifier.
ET en modele relation il faut compléter la table PostModif (résultat de l'association Modifer) proposée Richard
#ID POST, #ID UTILISATEUR et Date modif

Mais encore c'est pas suffisant ...
>> mettre la propriété Contenu ailleurs que dans l'entité Post parce qu'un post peut avoir plusieurs contenu.

Je pense qu'il faut revoir cette partie.

A +

[userparis]

Bonjour,



En voilà une affirmation à étayer... Quelles preuves formelles, tangibles, apportez-vous ? En quoi le fait faire figurer des propriétés qui n’ont de signification qu’au sein d’une association du genre x,1/y,N serait-il non pertinent ou dangereux ?

Juste mes cours Merise, pas de preuve c'est vrai

Pour moi pas pertinent car en résultat modele relationnel, une propriété d'une entité doit se retrouver dans la table résultat de l'entité.*

La on met une propriété futur de la table post pas dans l'entité post.

[Richard_35]

Bonjour Userparis,

C'est vrai que nous ne nous sommes pas intéressés à la partie :



Qui, en termes de règles de gestion, veut dire :

• 1 user peut créer 0 ou n post ;
• 1 post ne peut être créé que par 1 et 1 seul user ;
• 1 user peut modifier 0 ou n post ;
• 1 post peut ne jamais être modifié ou, alors, qu'une seule fois.

Beaucoup d'incohérence, il me semble :

• 1 user peut créer 0 ou n post ==> logique ;
• 1 post ne peut être créé que par 1 et 1 seul user ==> logique ;
• 1 user peut modifier 0 ou n post ==> logique (mais, sans doute, que les siens) ;
• 1 post peut ne jamais être modifié (==> logique) ou n'être modifié qu'une seule fois (==> j'en doute et, je pense, uniquement par celui qui a créé le post).

Bref, nous n'avons pas les règles de gestion à l'origine de ce MCD. Nous avons donc supputé... Maintenant, effectivement, en allant plus loin, toujours en supputant (ce que tu fais en évoquant une historisation des modifications des posts), nous pourrions établir les règles de gestion suivantes :

• 1 user peut créer 0 ou n post ;
• 1 post ne peut être créé que par 1 et 1 seul user ;
• 1 user peut modifier 0 ou n post, mais que ceux qu'il a créés ;
• 1 post peut ne jamais être modifié ou modifié plusieurs fois uniquement par le user qui l'a créé.

Ce qui donne :



Tables résultantes :

User(IdUser, ...) ;
Post(IdPost, ..., DateCreation, #IdUser)
PostModifier(IdPost, DateModification)
==> la contrainte devant être assurée par un trigger.

ou bien, si l'on enlève la contrainte (un post peut être modifié par d'autres users que son créateur) :

User(IdUser, ...) ;
Post(IdPost, ..., DateCreation, #IdUser)
PostModifier(IdPost, #IdUser, DateModification)

D'autre part :

Mais encore c'est pas suffisant ...
>> mettre la propriété Contenu ailleurs que dans l'entité Post parce qu'un post peut avoir plusieurs contenu.

==> dans le vocabulaire des forums, un post est un message, donc il n'a qu'un seul contenu. En revanche, un fil est une discussion composée d'un ensemble de post(s), donc d'un ensemble de message(s). Le contenu du post que je viens d'écrire est unique. La discussion avec Alixe80, Fsmrel, toi et moi, comporte plusieurs posts.


Enfin, nous voyons que, dans cette affaire, il manque le point de vue de Alixe80 qui, somme toute, a une certaine importance...

[userparis]

ou bien, si l'on enlève la contrainte (un post peut être modifié par d'autres users que son créateur) :

User(IdUser, ...) ;
Post(IdPost, ..., DateCreation, #IdUser)
PostModifier(IdPost, #IdUser, DateModification)

D'autre part :
==> dans le vocabulaire des forums, un post est un message, donc il n'a qu'un seul contenu. En revanche, un fil est une discussion composée d'un ensemble de post(s), donc d'un ensemble de message(s). Le contenu du post que je viens d'écrire est unique. La discussion avec Alixe80, Fsmrel, toi et moi, comporte plusieurs posts.


Enfin, nous voyons que, dans cette affaire, il manque le point de vue de Alixe80 qui, somme toute, a une certaine importance...

Hello, effectivement je suis passé a coté d'une règle de gestion un peu particulière, autant pour moi. Mais j'avoue ne pas trop comprendre le fonctionnement du forum à mettre en place par rapport au MCD dont on parle.

Enfin pour le contenu, a la ccréation du post on enregistre un message dans le champs contenu, et lors d'une modif (du créateur...) on fusionne les deux messages dans le même champs contenu ou ne conserve pas le 1er message ??

A +

[Richard_35]

Enfin pour le contenu, a la création du post on enregistre un message dans le champs contenu, et lors d'une modif (du créateur...) on fusionne les deux messages dans le même champs contenu ou ne conserve pas le 1er message ??

==> 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 ;
• soit, tu crées un autre message (un autre post) qui viendra alimenter le fil (la discussion).

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.


Maintenant, si la règle de gestion imposée par les utilisateurs est qu'il faut conserver les anciens contenus, c'est aussi possible. Mais, il faut le savoir, pour le prévoir.

[fsmrel]

Cela vaut-il le coup de passer de :

Post(IdPost, #IdUtilisateur, ..., DateHeureAjout, DateHeureModif)

à

Post(IdPost, #IdUtilisateur, ..., DateHeureAjout)
PostModif(#IdPost, DateHeureModification)

uniquement à cause du fait que la date de modification n'est pas toujours renseignée ?

Je répète que du point de vue de la logique du 1er ordre (ou autre), il n’y a que deux valeurs de vérité : vérité et fausseté, et ne pas en tenir compte quand on modélise et manipule les données ça peut être redoutable.

Si au stade SQL vous codez (script 1) :

Code SQL :

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.

Par contre, si vous codez (script 2) :

Code SQL :

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    
    , ....
    ) ;

Le bonhomme peut venir ficher la patouille avec sa logique à trois valeurs de vérité : vérité, fausseté, doute. Un prédicat est soit vrai soit faux, mais possiblement vrai ou faux ça n’est pas acceptable.

Indépendamment du fait que la logique et l’algèbre relationnelle sont prises en défaut (voyez le coup du biconditionnel), il se peut que pour telle ligne de la table l’absence d’information se traduise par « on ne sait pas », pour telle autre ligne par « sans objet », ou tout autre motif (exotique cette fois-ci) recensé entre autres par ceux qui font la norme SQL. Pour ma part, je reprends le vers de Boileau : « J'appelle un chat un chat, et Rollet un fripon », je mets donc en œuvre une table pour l’horodatage des modifications :

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE Post
(
        IdPost              Int         Not Null
      , IdUtilisateur       Int         Not Null
      , ...
      , DateHeureAjout      Datetime    Not Null
    , ....
) ;

Code SQL :

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

1
2
3
4
5
6
7
8
CREATE TABLE PostModif
(
        IdPost              Int         Not Null
      , DateHeureModif      Datetime    Not Null
    , CONSTRAINT PostModif_PK PRIMARY KEY (IdPost)
    , CONSTRAINT PostModif_FK FOREIGN KEY (IdPost) REFERENCES Post (IdPost)
          ON DELETE CASCADE  
) ;

Je ferai observer que la mise en œuvre d’une vue de jointure de ces deux tables fait que les programmes peuvent ne manipuler que cette vue, car c’est une table même si ça n’est pas une table de base :

Code SQL :

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

1
2
3
CREATE VIEW PostV (IdPost, IdUtilisateur, DateHeureAjout, DateHeureModif) AS
    SELECT x.IdPost, IdUtilisateur, DateHeureAjout, COALESCE(DateHeureModif, 'sans objet')
    FROM   Post AS x LEFT JOIN PostModif AS y ON x.IdPost = y.IdPost ;

Table (virtuelle) donc, mais qui, tout comme une table de base, peut être opérande pour n’importe quelle opération de l’algèbre relationnelle et peut supporter les opérations de mise à jour (INSERT, UPDATE, DELETE) : voyez à ce propos l’ouvrage de C.J. Date, View Updating and Relational Theory. Dans le cas de SQL, la norme va (timidement) dans ce sens. Du côté des SGBD SQL, certains suivent (Oracle), mais d’autres permettent seulement de mettre à jour les vues via des triggers, d’autres ne permettent même pas la mise à jour des vues par trigger (MySQL ).

N.B. Mettre en oeuvre le script 1 ne pose pas de problème dans le cadre du modèle relationnel de données, car on peut définir un type DateHeureModif pour lequel, outre les valeurs de timestamp habituelles, on peut aussi définir des valeurs comme « sans objet », « inconnu », « top secret » ^^ ou que sais-je. Le problème est, il est vrai, qu’avec nos SGBD SQL c’est mission en général impossible.

Dans ce cas, tous les attributs de type "commentaires" ou "observations" devraient être externalisés.

Non, car ces attributs sont du type caractère (CHAR, VARCHAR, STRING, ...) et sans être marqués NULL peuvent très bien être vides, sans que la logique classique en souffre.

Ainsi que ceux représentant, par exemple, le n° de la rue d'une adresse (car une adresse ne comporte pas toujours de n° de rue).

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.

Quoi qu’il en soit, à moins de vouloir entrer dans les détails sordides des escaliers, bâtiments, voies diverses, etc., pour mémoriser une adresse PTT on peut contenter d’une structure d'en-tête de table du style :

{Id, CodePostal, AdrLigne2, AdrLigne3, AdrLigne4}

[fsmrel]

Une association qui n'aboutit pas à la création d'une table dans le modèle relationelle ne doit selon moi (et mes cours merise ...) pas comporter de propriété

Ne mélangez pas les genres. La représentation graphique des MCD merisiens permet d'avoir une bonne perception sémantique, comprendre ce qu’on modélise. En relationnel (en passant, le modèle relationnel est une théorie formelle !), on se place d’abord du côté de la théorie des ensembles (structure et algèbre).

De toutes façons, un AGL comme PowerAMC vous contredit tout de suite.

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 :

Il me semble mais la c'est à vérifier que Ici on a deux liens "différent" qui vont vers la même entité, et c'est la que je dis qu'il faut vérifier mais est-ce que cela veut dire qu'on envoie deux fois l'identifiant ID_Utilisateur à l'entité POST ? ça me paraît pas cohérent. Et en modèle relationnelle on aurait deux fois la même réf externe ?

C’est vérifié depuis 40 ans !

Considérez le MCD suivant :



PowerAMC ronronne et produit le MLD :





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 ?