Discussion :

[chapodos]

Bonjour,

Dans le cadre de ma formation, je suis en train de concevoir (pour le réaliser ensuite) un espace collaboratif virtuel du type communautaire mettant en relation des professionnels dans le domaine qui les intéresse.

S’agissant d’un cas d’école pour le moment j’essaye de faire simple, mais pas trop quand même pour pouvoir continuer le développement après l’école.

Pour la compréhension j’ai fait un MCD pressenti avant de continuer en UML.

Je bute sur l’entité « contact » que je ne suis pas sûr de bien présenter.

En effet, la règle que j’ai fixée pour cette partie est la suivante :

- L’ensemble des utilisateurs constitue l’annuaire du réseau.
- Un utilisateur de réseau invite un autre utilisateur à faire partie de ses contacts.
- L’utilisateur en question peut accepter ou refuser.
- A partir de moment où l’invitation est acceptée chacun fait partie de contact de l’autre.
- Ensuite c’est à chaque utilisateur de classer ses contact selon ses critères (amis, collègues, camarades de l’école,), sachant qu’un contact peut appartenir à plusieurs catégories (exemple il peut être en même temps collègue et ami).

Voici le MCD que je souhaite améliorer.

Merci d’avance

[Oishiiii]

Bonjour chapodos,

Je pense que vous n'avez pas besoin de l'entité Contact.
Vous gardez vos 2 association réfléxives.
L'association "inviter à faire partie de ses contacts" devient porteuse de données en lui ajoutant l'attibut Etat_contact.
L'association "faire partie de ses contacts" devient une association ternaire, en l'associant avec l'entité Categorie_contact.

Je vais passer au MLD pour représenter cela (MySQL Workkbench) :

Chaque ligne dans la table Contact met en relation deux utilisateurs.
La colonne Etat est un booléen pour savoir si l'utilisateur "invité" a accepté ou non d'être en contact avec l'utilisateur "inviteur".

Ensuite un utilisateur peut "affecter" une à plusieurs catégorie à un contact.

Il faudra bien veiller lors de l'insertion d'une ligne à ce que le couple (utilisateur/contact) de la table Type_Relation soit obligatoirement présent dans la table Contact.

Je vous propose une autre solution qui me semble correcte :


L'Etat décrit plus haut devient un type de contact.
Donc concrètement, en plus des "amis, collègues, camarades..", il y aura une ligne dans la table Type_Contact représentant le fait que le Contact n'est pas encore confirmé.
Ce sera la valeur par défaut de la colonne idTypeContact dans Contact

On "gagne" une table et le contrôle dû aux deux tables de la première solution disparaît.

[chapodos]

Merci beaucoup Oishiiii pour cette réponse pertinente.

C’est une communauté formidable et ça aide vraiment pour un néophyte comme moi.

Pour la première solution je n’ai pas de problème mais pour la seconde je n’ai pas bien compris. Pourtant elle a l’air d’être plus simple. J’ai attaché le fichier PDF de cette solution telle que j’ai comprise. Est-ce exact ?

Quel est l’outil que vous utilisez pour la modélisation et est-il open source ?

Moi, j’ai téléchargé la version trial de power Designer 15 (poweramc) en espérant que dans 15 jours j’aurais terminé cette partie.

Encore merci.

[Oishiiii]

Bonsoir,

J'ai utilisé MySQL Workbench, je ne sait pas s'il est Open Source, en tout cas il est gratuit.

Oui, c'est une ternaire, je le ferais comme ça.

Donc exemple :

Code :

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

1
2
3
4
Utilisateur (id, nom, prénom)
              1  DUPOND  Pierre
              2  DURAND  Paul

Code :

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

1
2
3
4
5
6
Type_De_Contact(id, titre)
                 1  En attente de confirmation
                 2  Confirmé
                 3  Amis
                 4  Collègues

Pierre demande à être un contact de Paul :

Code :

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

1
2
Est_en_Realtion(inviteur#, invité#, type_de_contact#)
                   1            2           1

Lors d'une "invitation" le type_de_contact est toujours à 1 (En attente de confirmation).
Paul confirme :

Code :

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

1
2
Est_en_Realtion(inviteur#, invité#, type_de_contact#)
                    1           2           2

Pour Pierre, Paul est un amis et collègue :

Code :

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

1
2
3
Est_en_Realtion(inviteur#, invité#, type_de_contact#)
                    1           2           3
                    1           2           4

Pour Paul, Pierre n'est qu'un collègue :

Code :

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

1
2
Est_en_Realtion(inviteur#, invité#, type_de_contact#)
                    2           1           4

Je ne sait pas si c'est la meilleur solution, mais ça me semble correct.

[chapodos]

Bonsoir,

Merci beaucoup. C'est très clair maintenant.

Bravo pour votre explication pédagogique.

Bonne soirée


Not: Je viens de télécharger MySQL Workbench 5.2.2 alpha pour tester.

[chapodos]

Bonjour,

En poussant un peu plus loin, J’ai kmême un problème.

Je disais :

« C’est a chaque utilisateur de classer ses contact selon ses critères (amis, collègues, camarades de l’école,) »

Si en plus, cette catégorie est spécifique à un utilisateur (= non visible par les autres, chacun a la sienne), les solutions précédentes ne fonctionnent plus.

Exemple :

Catégorie ( id, propriétaire, titre )
1 Pierre Amis
2 Pierre Collègues
3 Paul Amis
4 Paul Camarades

Comment peut-on présenter le modèle conceptuel des données dans ce cas?
Merci d’avance.

[Oishiiii]

Bonjour,

Si un utilisateur peut utiliser (posséder) plusieurs catégories (Type_Contact).
Et qu'inversement, une même catégorie peut-être utilisée par plusieurs utilisateurs, il faut créer une "table jointure".

Comme ceci :


Une seule table avec les catégories, donc sans doublons.
Si plusieurs utilisateurs veulent utiliser la catégorie "Partenaire Judo", il n'y aura qu'une ligne dans la table Type_Contact.

Ainsi au lieu d'avoir :

Code :

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

1
2
3
4
5
6
Catégorie ( id, propriétaire, titre )
             1 Pierre         Amis
             2 Pierre         Collègues
             3 Paul           Amis
             4 Paul           Camarades

Vous aurez :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Utilisateur (id, prenom)
             1   Pierre
             2   Paul

Type_Contact (idTypeContact, titre)
                  1          Amis
                  2          Collègues
                  3          Camarades

Possede (idUtilisateur, idTypeContact)
               1           1
               1           2
               2           1
               2           3

Il faudra bien faire attention à ce que le couple (inviteur/idTypeContact) dans la table Contact soit bien présent dans la table Possede avant d'insérer une ligne.

Code :

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

1
2
3
4
Contact (inviteur, invite, idTypeContact)
             1        2       1  -- Pour Pierre, Paul est un Amis
             2        1       2  -- Erreur: Pour Paul, Pierre ne peut pas être un Collègues

Edit:
Au final, je placerai les contraintes d'intégrité référentielles (clé étrangères) comme ceci :

- idTypeContact dans Possede fait référence à idTypeContact dans Type_Contact.
- idUtilisateur dans Possede fait référence à idUtilisateur dans Utilisateur.
- Le couple (inviteur/idTypeContact) dans Contact fait référence au couple (idUtilisateur/idTypeContact) dans Possede.
- invite dans Contact fait référence à idUtilisateur dans Utilisateur.

Je pense que c'est correct.

[chapodos]

Bonsoir,
Vous êtes formidable merci beaucoup

Je vais cogiter! Mais Il me semble que les catégories doivent être complètement spécifiques à un utilisateur. Paul ne doit pas connaitre (ni voir) les catégories de Pierre et il ne doit pas voir non plus comment Pierre le catégorisé.

J’ai une solution dessiné en MCD Merise que je suis en train de vérifier. Je n’ai sais pas par contre encore présenter le MLD avec MySQL Workkbench. Je vais l’essayer ce weekend. En plus la BDD sera sur SQL server 2008.

Ma solution ressemble à votre première solution, mais sans la table « possède » et j’ai ajouté dans la table « Type_contact » le propriétaire de type.




Merci encore

[Oishiiii]

Bonjour,

Mais Il me semble que les catégories doivent être complètement spécifiques à un utilisateur. Paul ne doit pas connaitre (ni voir) les catégories de Pierre et il ne doit pas voir non plus comment Pierre le catégorisé.

Oui, et c'est bien ce que j'ai représenté dans le MLD précédent.

Paul ne "voit" pas les catégories de Pierre, et inversement.

En SQL, pour trouver toutes les catégories de Pierre :

Code SQL :

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

1
2
3
4
SELECT idTypeContact, titre
FROM Type_Contact
    NATURAL JOIN Possede
WHERE idUtilisateur=1

Ma solution ressemble à votre première solution, mais sans la table « possède » et j’ai ajouté dans la table « Type_contact » le propriétaire de type.

L'identifiant de l'utilisateur dans la table Catégorie ne va pas, car si 200 utilisateurs utilisent la catégorie "Amis", vous aurez 200 lignes dans la table Catégorie, c'est à éviter.

Dans mon message précédent j'ai distingué les catégories définies par un utilisateur et la liste des contacts (auquel sont associés une catégorie) d'un utilisateur.

En revenant au niveau du MCD, il y a deux notions:
- Un utilisateur peut posséder plusieurs catégories.

- Un utilisateur peut être en contact avec plusieurs autre utilisateurs, et leur affecter à chacun une ou plusieurs Catégories.


Une fois les deux notions associées, il me semble qu'il y a une contrainte d'association (inclusion). Je ne suis pas certain de ma représentation.

Pour que Paul ai Pierre comme Amis, il faut au préalable qu'il Possède la catégorie Amis. Ce qui se traduit par les clé étrangères au niveau du MLD comme on l'a déjà vu.

Donc, soit vous utilisez les tables de mon message du 05/09/2009 à 15h08, et alors, à chaque Contact est affecté une catégorie, ni plus ni moins.
Soit vous utilisez les tables de mon message d'Hier à 13h50, ce qui permet en plus aux utilisateur de définir/posséder des catégories qui ne sont pas obligatoirement affectées à un Contact.

[chapodos]

Bonjour Oishiiii,

Vos remarques m’aident beaucoup. Mais je suis en phase d’apprentissage et néophyte en matière de BDD. Donc je mets beaucoup de temps pour comprendre et réagir.

J’avais envisagé aussi cette solution :

Le MCD :



LE MLD devient :

Utilisateur: (Id prénom)
100 Pierre
101 Paul
102 Dupont

Pierre invite Paul

Contact : Id utilisateur (inviteur), Uti id utilisateur (invité) , statut
100 101 en attente

Paul accepte

100 101 confirmé
101 100 confirmé

Pierre et Paul créent leur type de contact :

Type contact (Id type contact Id propriétaire, titre)

1 100 amis
2 100 collègues
3 101 amis francophone …

Pierre classe Paul comme ami
Paul classe Pierre comme ami francophone

Classement contact : (Id contact classé id type contact)

101 1
100 3

Dupont ne peut rien faire pour l’instant il n’a pas de contact et en plus il n’a pas crée de type de contact

Cette solution me parait plus simple, mais est-ce qu’elle est valable ?

[Oishiiii]

Bonjour,

Pierre invite Paul

Code :

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

1
2
Contact : Id utilisateur (inviteur), Uti id utilisateur (invité) , statut
100 101 en attente

A ce niveau, je faisait du "status" un Type contact. Ce qui simplifie un peu les choses.
Si vous voulez que la notion de "status" soit indépendante du Type de contact, il faudra quand même créer une table Status.

Paul accepte
100 101 confirmé
101 100 confirmé

Ici, je ne créerai pas 2 lignes.
Chaque ligne de la table Contact représente la mise en contact de deux utilisateur.
Il n'y a pas besoin de créer ces deux lignes. Il n'y aura pas de problèmes par la suite pour les manipulations en SQL.

Au niveau de votre MCD.
Il y a un problème avec la cardinatilité 1.1 entre l'association Posséder et l'entité Type contact.
Un même Type de contact peut être possédé par plusieurs utilisateurs (exemple : Amis), et c'est très important.

Je crois que le MCD dans mon message du 11/09/2009 10h07 et le MLD (message du 10/09/2009 13h50) correspondent mieux à ce qu'il faudrait faire.

Si quelqu'un d'autre passe par là, tout avis est bienvenu.

[chapodos]

Bonjour,
...
Au niveau de votre MCD.
Il y a un problème avec la cardinatilité 1.1 entre l'association Posséder et l'entité Type contact.
Un même Type de contact peut être possédé par plusieurs utilisateurs (exemple : Amis), et c'est très important..

Justement ce que je ne comprenais pas avec votre solution. En effet, je ne veux pas que le Type de contact soit possédé par plusieurs utilisateurs.

D'accord avec votre remarque relative à "status.

Oui. si quelqu'un d'autre passe par là, tout avis est bienvenu.

[Oishiiii]

Bonjour,

Les Types de contact, ont est bien d'accord sont "Amis", "Collègue de travail", "Camarade d'école", etc...

Il faut créer une seule table, contenant ces Types.
Le Type "Amis" ne doit être présent qu'une seule fois dans la table, même si des milliers d'utilisateurs "possèdent"/"Classent leur Contact" avec ce Type.
Sinon, vous allez créer de la redondance et vos tables seront inutilement obèses.

Le Type "Amis" peut être utilisé, possédé par plusieurs personnes, cela ne veux pas dire qu'elles sont automatiquement mises en Contact (cf. MLD du 10/09/2009 13h50).

Concrètement, lorsqu'un utilisateur voudra ajouter/créer un nouveau Type pour gérer ses Contact (je suppose que cela sera comme ça dans votre application), si celui-ci existe déjà, vous n'ajouter par de ligne dans la table, et vous utiliser la ligne déjà présente, sinon vous l'insérez.

Je suis plus clair ?

[chapodos]

Bonjour,

Le Type "Amis" peut être utilisé, possédé par plusieurs personnes, cela ne veux pas dire qu'elles sont automatiquement mises en Contact (cf. MLD du 10/09/2009 13h50).

Cela veut dire par contre (ou bien je me trompe) que tous les types sont visibles par toutes les personnes.

Je pose comme condition préalable que le type de contact est personnel. Je préfère que l’utilisateur choisisse parmi les types qu’il a crées au lieu de choisir parmi les 10000 types qui sont crées par les autres.

[Oishiiii]

Bonjour,

Cela veut dire par contre (ou bien je me trompe) que tous les types sont visibles par toutes les personnes.

Non.
Si vous le voulez, tous les utilisateurs peuvent regarder le contenu de la table Type, c'est un fait valable pour n'importe quel table d'une base de donnée.
Mais si vous le voulez, chaque utilisateur ne verra que les Types qu'il possède (table Possède).

Je pose comme condition préalable que le type de contact est personnel.

Oui, je l'ai bien pris en compte à partir du message du 10/09/2009, 13h50.

Je préfère que l’utilisateur choisisse parmi les types qu’il a crées au lieu de choisir parmi les 10000 types qui sont crées par les autres.

Regardez mes message précédents.
http://www.developpez.net/forums/m4635879-9/

Je fait bien la distinction entre le fait de posséder/créer les Types, et le fait d'être en contact avec un utilisateur (en lui affectant un certain type).

Par rapport au MLD :
http://www.developpez.net/forums/m4633860-7/

La table Type_Contact contient tous les Types (Amis, Collègues, etc..) sans doublons.
La table Possède contient les Types que possède un Membre, c'est les seuls qu'il peut voir, ceux qu'il a créer/choisis. Cf. la requête SQL.
La table Contact, contient tous les contacts d'un utilisateurs avec les catégories (ou Types) qui sont affectées au Contact.

[chapodos]

Merci de votre patience avec moi,

Vous avez probablement raison. Je vais créer quelques tables pour mieux comprendre le mécanisme (et aussi pour digérer les différentes solutions).