Discussion :

[beegees]

Bonjour,

J'ai un bd qui contient des informations de contacts de prestataires (médecin, kinés...).

Plusieurs utilisateurs vont utiliser cette BD.

J'aimerais que chaque utilisateurs puisse mettre en favoris leurs prestataires auxquels ils devront accéder souvent.

J'ai donc une table professionnels (les prestataires), une table users (les utilisateurs de l'intranet).

Un professionnel (partenaire) peut être plusieurs fois favoris et un favoris peut se retrouver chez plusieurs utilisateurs.

Je ne sais pas comment m'y prendre ?

Je devrais donc avoir une table qui reprend l'ensemble des favoris par utilisateurs.

Je ne vois pas comment m'y prendre pour les relations, avez-vous une idée svp ?

Merci d'avance.

bee

[al1_24]

Il suffit d'une simple table d'association qui reprendra uniquement l'identifiant de l’utilisateur et celui du prestataire.
Deux clés étrangères, l'une de l'identifiant de l'utilisateur vers la table des utilisateurs, l'autre de l'identifiant du prestataire vers la table des prestataires.
Une contrainte d'unicité sur le couple (identifiant de l’utilisateur, identifiant du prestataire).
Rien de plus

PS : Je n'avais pas vu ton modèle de données. Une bonne pratique conseille d'utiliser un nom pour identifier une donnée unique. Donner le nom id à tous les identifiants de toutes les tables n'est pas une bonne idée

[beegees]

Bonjour,

Merci pour ta réponse.

En effet, c'était tout simple finalement...

En fait, c'est parce que j'utilise MySQL Workbench et je ne savais pas comment faire pour ajouter des clés étrangères sans utiliser les relations (1,n 1,n).

Voici une impression d'écran qui pourra peut-être aider d'autres personnes.

Encore merci et bon W.E.
bee

[escartefigue]

Bonjour,

Puisque la question concerne la modélisation, il y a aussi d'autres points à corriger :

- user comme professionnel sont des personnes, il faudrait donc mutualiser ce qui est commun (nom, prénom, date de naissance...) dans une table personne, puis créer deux sous-types "professionnel" d'une part et "user" d'autre part (l'usage est d'utiliser des singuliers pour les noms d'entité-type), pour ce qui est spécifique.
Vous créez ensuite une relation entre les deux sous-types.
En faisant ainsi, si un user est également un professionnel, vous évitez les redondances avec les risques d'erreur inhérents.

- la codification des adresses est normée. cf. norme de la poste pour les adresses professionnels et particuliers.

- adresse et téléphone n'ont rien à faire dans la table "professionnel"; il faut modéliser ainsi :
[PERSONNE] 0,n --- (resider) --- (1,1) ou 1,1 ou 1,n [ADRESSE]
[PERSONNE] 0,n --- (telephoner) --- (1,1) ou 1,1 ou 1,n [TELEPHONE]

- sans doute certains professionnels sont ils des personnes morales, auquel cas nom et prénom par exemple n'ont pas de sens. Dans ce cas il faut encore créer deux sous-types sous l'entité-type "professionnel" pour avoir selon le cas nom, prénom, date de naissance etc... ou bien SIREN, NIC, raison sociale etc...

[CinePhil]

J'ajoute ma petite remarque concernant l'association entre categorie (au singulier !) et professionnel (au singulier !) : Selon votre schéma, un professionnel appartient à une seule catégorie (ok) et une catégorie n'est associée qu'à un seul professionnel (ko ).