Discussion :

[darialisa]

Bonjour, je suis un novice et j’ai besoin de conseils.
Je souhaite me lancer un programme :
1) Un membre à plusieurs amis parmi des membres d"une association (liste d’amis)
2) un membre envoie un message à un ou plusieurs membres choisis parmi l’an liste d’amis
3) un membre peut s’associer à un ou plusieurs membres de l’association pour un travail (même s’il ne fait pas partie de sa liste d’amis)
4) les membres ayant reçu un message peuvent chacun noter le message qu’ils ont reçu
5) un membre peut consulter la liste des messages et voir le total des points pour chaque message

Il faudra bien sûr une Table Membre, une Table Message, mais qu’elle doivent être les rubriques, faut-il une Table I pour gérer la liste d’amis ?
Un petit schéma serait génial

Merci pour votre réponse

[escartefigue]

Bonjour,

Voici quelques réponses mais aussi pas mal de questions
Point positif : vous avez énuméré et numéroté des règles de gestion, mais il en manque beaucoup !
Il manque également des éléments de contexte, des définitions, voire des exemples pour illustrer le propos

1) Un membre à plusieurs amis parmi des membres d"une association (liste d’amis)

Il faut détailler cette règle, en l'état on pourrait penser que tous les amis doivent faire partie d'une association et de la même association
Quel est le rôle de "l'association" dans votre gestion de messages ?

2) un membre envoie un message à un ou plusieurs membres choisis parmi l’an liste d’amis

Ne peut on pas envoyer de message à une liste de personnes dont certaines ne sont pas des "ami(e)s" ?

3) un membre peut s’associer à un ou plusieurs membres de l’association pour un travail (même s’il ne fait pas partie de sa liste d’amis)

Quel est le rôle du "travail" dans votre gestion de messages ?

4) les membres ayant reçu un message peuvent chacun noter le message qu’ils ont reçu

Il faut donc créer une relation "noter" entre "MEMBRE" et "MESSAGE" et ajouter une Contrainte d'Intégrité Fonctionnelle (CIF) pour vérifier que le membre qui note le message est bien le membre qui a reçu le message (une flèche de la relation "noter" vers la relation "recevoir"). Cf mon schéma plus bas.

5) un membre peut consulter la liste des messages et voir le total des points pour chaque message

Ceci est du ressort du traitement, pas d'impact sur le modèle de données sous réserve que vous ayez prévu un attribut "note" dans la relation "noter" bien sur

Il faudra bien sûr une Table Membre, une Table Message, mais qu’elle doivent être les rubriques,

Les attributs (plutôt que les rubriques ) dépendent de vos besoins fonctionnels, c'est à vous de recenser ces besoins auprès des gens du métier (la MOA)

faut-il une Table I pour gérer la liste d’amis ?

Au niveau conceptuel, les tables n'entrent pas en jeu, il y a des types d'entité (matérialisés par des rectangles) et des relations (ovales)
Les amis doivent être modélisés par une relation réflexive des membres sur eux mêmes (autrement dit deux "pattes" allant de "MEMBRE" vers cette relation)
Une "patte" joue le rôle "avoir pour amis" l'autre joue le rôle "être ami de"
Au niveau du modèle logique, cette relation deviendra une table (sous réserve qu'un membre puisse avoir plusieurs amis et qu'un membre puisse être l'ami de plusieurs personnes (à préciser dans les règles de gestion)

Un petit schéma serait génial

C'est un peu prématuré pour un schéma complet, trop de zones d'ombre subsistent (notamment au sujet du "travail" et des "associations", cf. remarques plus haut)
Voici pour la partie qui semble acquise

Pièce jointe 396667

EDIT (1) : je vois en relisant que j'ai oublié l'attribut "note" dans la relation noter à corriger bien sur
EDIT (2) : l'usage pour identifier les relation est l'infinitif, là j'ai simplifié (être_émetteur ==> émetteur, être_destinataire ==> destinataire)

[darialisa]

1) quand je parle de l’association : il s’agit de l’ensemble des membres qui ont adhéré à une association (il n’y a qu’une seule association).

La notion de « liste d’amis » correspond à des sous-ensembles des membres de l’association. Donc, selon ses affinités chaque membre a une seule liste d’amis et potentiellement il peut donc y avoir autant de liste d’amis que de membre

NB : Dans l’absolu, on pourrait aussi avoir à gérer le cas où un membre envoie toujours des messages aux mêmes amis (en fait un sous-groupe du sous-groupe « liste d’amis »). Comment faire si on veut donner un nom à ce groupe et faire en sorte qu’il apparaisse comme un ami dans sa liste d’amis ?

2) Un membre ne peut envoyer de message qu’à des membres de sa liste d’amis.
Quand un membre doit envoyer un message, on affiche sa liste d’amis dans laquelle il choisit un ou plusieurs destinataires ou un groupe.

3) En fait il s’agit d’un problème plus complexe et il y a des notions que j’aurais dû indiquer. On part du principe que :

- un membre peut avoir un statut public ou privé (défini à la création du compte) : je compte gérer cela avec un attribut isPublic dans la Table Member
- un message peut être privé (visible par les seuls destinataires désignés) ou public (visible par tous les membres de l’association) : je compte gérer cela avec un attribut isPublic dans la Table Message
- tous les membres ont accès à la liste de tous les comptes publics (une requête peut trier les comptes où isPublic = 1)
- un membre peut décider de « suivre » n’importe quel compte public même s’il ne fait pas partie de sa liste d’amis (et ainsi recevoir des notifications chaque fois que celui-ci envoie un message public et pouvoir lire les messages envoyés) : je compte gérer cela avec un attribut isFollowed dans la Table ???
- si un membre choisi un statut public, les autres membres ont accès à sa fiche et à la liste des derniers messages publics qu’il a envoyé

4) Un membre doit pouvoir noter un message (style J’aime ou J’aime pas) : isLiked. Quand il y a plusieurs destinataires il faut pouvoir gérer au niveau de chaque destinataire s’il aime ou pas le contenu ?

5) Au niveau d’un message, on affiche :

- le nombre total de fois qu’un membre a apprécié le contenu je compte gérer cela avec un attribut statLiked dans la Table Message

Par contre quand un membre visualise un message, il faut pouvoir retrouver si c’est un message qu’il a apprécié (Liked) et l’afficher et la réponse sera différente d’un membre à l’autre. Quelle solution ?
La difficulté vient du fait que l’on peut donner un avis sur des messages publics qui ne nous sont pas spécifiquement destinés.

Dans la fiche d’un membre, on récapitule certaines données :

- le nombre de membre qu’il suit : statFollowing dans la Table Member
- le nombre de membres qui le suivent : statFollowed dans la Table Member
- le nombre total de messages appréciés : statLiked dans la Table Message

Ces éléments doivent-ils faire l’objet d’attributs ou bien faut-il les gérer par un traitement ? Quelle est la solution optimale pour un affichage le plus rapide possible ?

J’ai vraiment du mal avec le modèle logique et donc avec les tables intermédiaires qu’il faudrait créer. Merci de votre aide.

Cordialement

[escartefigue]

1) quand je parle de l’association : il s’agit de l’ensemble des membres qui ont adhéré à une association (il n’y a qu’une seule association).

Faut il comprendre que vous gérez une messagerie interne à l'association, tous les membres sont donc des adhérents de cette association ?

La notion de « liste d’amis » correspond à des sous-ensembles des membres de l’association. Donc, selon ses affinités chaque membre a une seule liste d’amis et potentiellement il peut donc y avoir autant de liste d’amis que de membre

NB : Dans l’absolu, on pourrait aussi avoir à gérer le cas où un membre envoie toujours des messages aux mêmes amis (en fait un sous-groupe du sous-groupe « liste d’amis »). Comment faire si on veut donner un nom à ce groupe et faire en sorte qu’il apparaisse comme un ami dans sa liste d’amis ?

Il faut donc modéliser
MEMBRE 0,n --- créer ---(1,1) LISTE 1,n ---contenir --- 0,n MEMBRE
et il faudra ajouter une CIF pour vérifier que toute occurrence de la relation "contenir" concerne un membre de la relation "relier"

2) Un membre ne peut envoyer de message qu’à des membres de sa liste d’amis.

Donc une nouvelle CIF entre les relations "emettre" et "contenir"

Quand un membre doit envoyer un message, on affiche sa liste d’amis dans laquelle il choisit un ou plusieurs destinataires ou un groupe.

Ceci concerne les traitements, pas d'impact sur le MCD

- un membre peut avoir un statut public ou privé (défini à la création du compte) : je compte gérer cela avec un attribut isPublic dans la Table Member
- un message peut être privé (visible par les seuls destinataires désignés) ou public (visible par tous les membres de l’association) : je compte gérer cela avec un attribut isPublic dans la Table Message
- tous les membres ont accès à la liste de tous les comptes publics (une requête peut trier les comptes où isPublic = 1)
- un membre peut décider de « suivre » n’importe quel compte public même s’il ne fait pas partie de sa liste d’amis (et ainsi recevoir des notifications chaque fois que celui-ci envoie un message public et pouvoir lire les messages envoyés) : je compte gérer cela avec un attribut isFollowed dans la Table ???
- si un membre choisi un statut public, les autres membres ont accès à sa fiche et à la liste des derniers messages publics qu’il a envoyé

Et si un membre change de statut, par exemple de public vers privé, que se passe -t- il avec les messages précédemment émis, deviennent ils privés ou restent ils visibles par tous ?
Selon le cas, il faut gérer un statut à date

4) Un membre doit pouvoir noter un message (style J’aime ou J’aime pas) : isLiked. Quand il y a plusieurs destinataires il faut pouvoir gérer au niveau de chaque destinataire s’il aime ou pas le contenu ?

Le contenu étant le même pour tous les destinataires, je ne vois pas pourquoi il pourrait y avoir une note par destinataire, mais bon c'est à vous de décider en fonction de vos besoins

5) Au niveau d’un message, on affiche [. . .] :

La suite concerne également les traitements, pas d'impact à ce stade

[darialisa]

Bonjour,
je reviens vers vous après avoir essayé d'avancer sur les conseils que vous m'avez fourni.
Je vous soumet en pièces jointes le travail que j'ai fait.
Il y a bien sur des points qui poseront problème.

Merci d'y jeter un coup d'oeil bienveillant.

[escartefigue]

Bonjour,

Vous n'avez pas répondu à toutes les questions de mon message n°4, ni rédigé toutes les règles de gestion, du coup de nombreux points restent obscurs

Quelques remarques tout de même sur votre MLD

1. Pourquoi choisir de nommer les objets (tables, colonnes) en anglais ? Si vous vous adressez à un public francophone, inutile de lui compliquer la tache, choisissez des termes en français. De plus ça limitera les risques de percussion avec des mots réservés SQL
2. Les tables issues de relations ne doivent avoir pour identifiants que les attributs identifiants des entité-type concourant à cette relation. Par exemple, dans MEMBER_CONTACT, vous ne devriez avoir pour identifiant que l'identifiant du groupe (GROUP_id) et l'identifiant du membre (MEMBER_id)
3. Le choix du type BigInt est très luxueux : le bigint permet de stocker jusqu'à 18 446 744 073 709 551 615 valeurs distinctes (2 puissance 64), je doute que votre association recueille autant d'adhésions de membres . Le type SmallInt autorise jusqu'à 65 535 valeurs, ça devrait largement suffire et vous gagnerez un petit peu de place et de performances
4. Pour éviter les erreurs conservez les mêmes noms d'attribut entre PK et FK. Par exemple, si l'identifiant PK de la table membre est MEMBRE_ID alors, dans la table message, l'identifiant du membre émetteur sera également MEMBRE_ID.
5. Hors clefs étrangères, un même nom d'attribut ne doit apparaitre qu'une seule fois. Vous avez utilisé le nom "ID" dans plusieurs tables (MEMBER, SHAPE, MESSAGE...). Pour éviter ces doublons, utilisez une nomenclature telle que "MEMBRE_ID", "MESSAGE_ID" etc...
6. Les colonnes Statxxx de la table MEMBRE doivent être supprimées : d'une part elles sont mal nommées car ce ne sont pas des statuts mais des nombres (nombre de like, nombre de followers...) et d'autre part car ce sont des données calculées. Il faudra donc les calculer par requête à chaque fois que ce sera nécessaire. Vous pourrez éventuellement créer une vue pour ce besoin.
7. Dans le document explicatif, vous mentionnez "je récupère le fichier des Contacts du smartphone de l’utilisateur. Je croise ce fichier avec la Table MEMBER avec comme critère le n° gsm"
   Or, le table MEMBER ne comporte pas d'attribut n°gsm... (ce qui semble du reste normal, dans la mesure où un membre peut à priori avoir zéro à plusieurs n°, sous réserve de complément de vos règles de gestion)
8. Qu'est-ce qu'un attribut de type GEOGRAPHY (dont le but est de stocker une géolocalisation) vient faire dans la table des messages
9. La description des tables du document joint ne correspond pas au MLD (noms des attributs différents)

Plusieurs des remarques ci-dessus tomberaient toutes seules si vous aviez commencé par un MCD plutôt qu'un MLD, les outils de modélisation corrigent tout seuls certaines de ces erreurs

[darialisa]

Bonjour et vraiment merci d'avoir pris le temps de lire mon travail.
Bcp de points à revoir.
Je crois qu'il faut que je reprenne à la base les tutoriels. J'avais pensé pouvoir sauter des étapes, mais je vois que ça n'est pas une bonne stratégie.
De toute façon je ne suis pas pris par le temps.

Merci encore pour votre gentillesse.