Navigation

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

  1. #1
    Candidat au Club
    Inscrit en
    mai 2010
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : mai 2010
    Messages : 5
    Points : 2
    Points
    2

    Par défaut Gestion d'une association

    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

  2. #2
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 917
    Points : 8 956
    Points
    8 956
    Billets dans le blog
    1

    Par défaut

    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

    Citation Envoyé par darialisa Voir le message
    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 ?

    Citation Envoyé par darialisa Voir le message
    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" ?

    Citation Envoyé par darialisa Voir le message
    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 ?

    Citation Envoyé par darialisa Voir le message
    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.

    Citation Envoyé par darialisa Voir le message
    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

    Citation Envoyé par darialisa Voir le message
    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)

    Citation Envoyé par darialisa Voir le message
    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)

    Citation Envoyé par darialisa Voir le message
    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

    Nom : MCD1.png
Affichages : 97
Taille : 8,0 Ko

    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)

  3. #3
    Candidat au Club
    Inscrit en
    mai 2010
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : mai 2010
    Messages : 5
    Points : 2
    Points
    2

    Par défaut

    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

  4. #4
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 917
    Points : 8 956
    Points
    8 956
    Billets dans le blog
    1

    Par défaut

    Citation Envoyé par darialisa Voir le message
    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 ?

    Citation Envoyé par darialisa Voir le message
    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"

    Citation Envoyé par darialisa Voir le message
    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"


    Citation Envoyé par darialisa Voir le message
    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

    Citation Envoyé par darialisa Voir le message
    - 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


    Citation Envoyé par darialisa Voir le message
    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

    Citation Envoyé par darialisa Voir le message
    5) Au niveau d’un message, on affiche [. . .] :
    La suite concerne également les traitements, pas d'impact à ce stade

  5. #5
    Candidat au Club
    Inscrit en
    mai 2010
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : mai 2010
    Messages : 5
    Points : 2
    Points
    2

    Par défaut

    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.
    Fichiers attachés Fichiers attachés

  6. #6
    Expert éminent

    Homme Profil pro
    bourreau
    Inscrit en
    mars 2010
    Messages
    3 917
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Loir et Cher (Centre)

    Informations professionnelles :
    Activité : bourreau
    Secteur : Finance

    Informations forums :
    Inscription : mars 2010
    Messages : 3 917
    Points : 8 956
    Points
    8 956
    Billets dans le blog
    1

    Par défaut

    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

  7. #7
    Candidat au Club
    Inscrit en
    mai 2010
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : mai 2010
    Messages : 5
    Points : 2
    Points
    2

    Par défaut

    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.

Discussions similaires

  1. [Conception] Connexion à une base de données
    Par delmimi dans le forum PHP & Base de données
    Réponses: 16
    Dernier message: 14/02/2007, 14h15
  2. Conception d'une base de données
    Par yousron dans le forum Modélisation
    Réponses: 7
    Dernier message: 22/11/2006, 13h06
  3. [Conception] Connexion à une base de données AS400
    Par mirc00 dans le forum PHP & Base de données
    Réponses: 4
    Dernier message: 21/07/2006, 23h27
  4. Conception d'une base de données
    Par petitloup71 dans le forum Modélisation
    Réponses: 6
    Dernier message: 07/07/2006, 18h08
  5. [Conception] Modifier une base de données
    Par fabrice88 dans le forum PHP & Base de données
    Réponses: 12
    Dernier message: 09/06/2006, 10h21

Partager

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