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

Schéma Discussion :

Structures tables dans BDD


Sujet :

Schéma

  1. #1
    Futur Membre du Club
    Structures tables dans BDD
    Bonjour,
    Quelle peut être la structure d'une BDD MySql.
    J'ai une Table1 avec comme champs ID, Nom, Prenom, pseudo etc.., soit un enregistrement par membre d'une communauté.
    Je voudrai collecter différents avis sur chaque membre, donnés par mes lecteurs et les rajouter dans la table ou dans une autre table liée.
    Je ne vois pas trop comment procéder. Je ne peux tout de même pas créer une nouvelle table pour chaque membre dans laquelle on ajouterai un enregistrement à chaque avis donné.
    Merci par avance de votre aide.
    Bonne journée

    FD

  2. #2
    Expert éminent sénior
    Bonjour,

    La modélisation est la conséquence des règles de gestion, il faut donc commencer par les formaliser, en les écrivant et en les identifiant par un numéro.

    Par exemple, imaginons que vos règles de gestion soient les suivantes

    R001a : un membre peut être noté par des lecteurs
    R001b : un lecteur peut noter des membres
    R001c : un lecteur peut noter un même membre à plusieurs reprises

    Ces règles de gestion montrent que les avis sont facultatifs ("peut" est utilisé dans chaque règle), la cardinalité mini est donc zéro, elles montrent également que les avis peuvent être multiples dans les deux sens (un lecteur peut noter plusieurs membres et un membre peut être noté par plusieurs lecteurs)

    Le MCD est donc [MEMBRE] 0,n --- (noter) --- 0,n [LECTEUR]

    Puisque les cardinalités maxi sont n de chaque coté de l'association, cette association "noter" deviendra une table.
    Le MLD ou le MPD contiendra donc les tables qui suivent (PK soulignées, FK suffixées #)
    MB_MEMBRE(MB_id, MB_nom, MB_Prenom, MB_pseudo...)
    LC_LECTEUR(LC_id, LC_nom, LC_prenom...)
    NT_NOTER(LC_id#, MB_id#, NT_sequence, NT_dateheure...) <-- la PK de cette table est composée notamment des PK des tables constitutives de la relation + une séquence requise pour la règle R001c

    On remarque que les attributs de l'entité-type [MEMBRE] et de l'entité-type [LECTEUR] sont très similaires, voire identiques.
    Il aurait donc été judicieux de modéliser une entité-type personne pour regrouper les membres et les lecteurs, puis de procéder par spécialisation en utilisant l'héritage pour définir les membres et les lecteurs.
    A compléter si besoin