Discussion :

[identifiant_bidon]

Bonjour à tous

J'ai un gros souci. J'ai besoin de savoir comment modéliser une fonctionnalité dans ma base de données de façon la plus efficace possible sans faire une usine à gaz. J'espère que je serai clair dans ma description.

Le principe est un peu similaire à celui de Thunderbird.

Une personne a des contacts qu'il peut ranger dans des groupes qu'il aura défini dans son contexte à lui.
Pour prendre un exemple. X est contact de Y. Chez X, Y fait parti du groupe "Collègue" alors que chez Y, X fait parti du groupe "Ami".

Comment modéliser les liens entre les contacts, entre les groupes sans faire quelque chose de trop trop lourd ??

Voila si quelqu'un a une idée (sachant qu'il peut y avoir beaucoup de X et de Y), je suis archi preneur !!

Merci

[CinePhil]

Règle de gestion :
Une personne peut avoir plusieurs personnes comme contacts et une personne peut être contact de plusieurs personnes.

MCD :
Personne -0,n----avoir----(1,1)- Contact
|---------------0,n----être------(1,1)-------|

J'ai ici en fait transformé une association en entité Contact. Les cardinalités entre parenthèses indique une identification relative.

Tables :
Personne (prs_id, prs_nom, prs_prenom...)
Contact (cnt_id_possesseur, cnt_id_contact)


Règle de gestion :
Un contact peut être rangé dans un groupe et un groupe peut contenir plusieurs contacts.

MCD :
Groupe -0,n----Contenir----0,n- Contact

Tables :
Groupe (grp_id, grp_nom)
Contenu_groupe (cgr_id_possesseur, cgr_id_contact, cgr_id_groupe)

Comme le contact est identifié relativement à son possesseur, il est facile de retrouver les contacts du groupe "amis" de Jean Dupont.

Cette modélisation suppose un certain partage d'informations entre les possesseurs des contacts. Ça peut se concevoir dans le cadre de contacts professionnels dans une entreprise mais plus difficilement dans une sphère privée.
Si je suis ami avec Jean Dupont, je peux accepter qu'il sache des informations privées (statut marital, enfants, âge...) alors que si je suis son contact professionnel, je peux trouver bizarre qu'il connaisse ces informations parce qu'il les a eues par le fait qu'un de mes amis travaille avec lui et connaisse davantage de choses sur moi que je ne lui en ai dévoilées.

[montesq]

Tables :
Groupe (grp_id, grp_nom)
Contenu_groupe (cgr_id_possesseur, cgr_id_contact, cgr_id_groupe)

Perso, j'aurais mis intuitivement:
Tables :
Groupe (grp_id, grp_nom, cgr_id_possesseur)
Contenu_groupe (cgr_id_contact, cgr_id_groupe)

Ou alors, si on veut partager des listes des contacts entre plusieurs "salariés", alors on crée les 3 tables:
Groupe, Contenu_groupe, Possesseurs_groupe

[CinePhil]

Perso, j'aurais mis intuitivement:
Tables :
Groupe (grp_id, grp_nom, cgr_id_possesseur)
Contenu_groupe (cgr_id_contact, cgr_id_groupe)

Ou alors, si on veut partager des listes des contacts entre plusieurs "salariés", alors on crée les 3 tables:
Groupe, Contenu_groupe, Possesseurs_groupe

Non parce que Toto peut être ami pour X et collègue pour Y.
Avec ta modélisation, Toto va se retrouver dans les deux groupes pour X et Y.

[identifiant_bidon]

Merci pour vos réponses en tout cas

CinePhil a raison. Cela aurait été plutôt simple si cela avait été comme tu le dis montesq.

A mon sens, le principal problème est bien le "référentiel" dans lequel tu te trouves. C'est ce qui m'a bloqué d'ailleurs. Un utilisateur peut être dans plusieurs groupes différents selon le compte dans lequel tu te trouves

[montesq]

Non parce que Toto peut être ami pour X et collègue pour Y.
Avec ta modélisation, Toto va se retrouver dans les deux groupes pour X et Y.

Modélisation n°1:

Contact
1. X
2. Y
3. Toto

Groupe
1. Ami
2. Collègue

Contenu_groupe
X - Ami - Toto
Y - Collègue - Toto

Modélisation n°2:

Contact
1. X
2. Y
3. Toto

Groupe
1. Amis - X
2. Collègues - Y

Contenu_groupe
1 (amis - X) - Toto
2 (collègues - Y) - Toto

Quel est le problème?
Après il y a peut-être une différence de compréhension de l'énoncer. Personnellement, je considère que l'utilisateur peut créer autant de groupes qu'il veut, en leur donnant le nom qu'il veut.

[CinePhil]

1) Mon modèle
Personne (prs_id, prs_nom, prs_prenom...)
1, 'Leménager', 'Philippe'
2, 'Dupont', 'Jean'
3. 'Durand', 'Jules'

Contact (cnt_id_possesseur, cnt_id_contact)
1, 2 => Jean Dupont est l'un des contacts de Philippe Leménager
1, 3 => Jules Durand est l'un des contacts de Philippe Leménager
2, 3 => Jules Durand est l'un des contacts de Jean Dupont

Groupe (grp_id, grp_nom)
1, 'Amis'
2, 'Collègues'

Contenu_groupe (cgr_id_possesseur, cgr_id_contact, cgr_id_groupe)
1, 2, 1 => Philippe Leménager a classé Jean Dupont parmi ses amis
1, 3, 1 => Philippe Leménager a classé Jules Durand parmi ses amis
2, 3, 2 => Jean Dupont a classé Jules Durand parmi ses collègues

==> Il y a étanchéité entre les amis de Philippe Leménager et les collègues de Jean Dupont, bien que Jules Durand figure dans les deux groupes.

2) Ton modèle...
OK, je n'avais pas vu que tu avais mis un possesseur au groupe !
Ce qui correspond peut-être plus à l'énoncé de départ effectivement :

Une personne a des contacts qu'il peut ranger dans des groupes qu'il aura défini dans son contexte à lui.

Mais cela implique que plusieurs groupes peuvent avoir le même nom chez des personnes différentes. Ce n'est pas choquant en soi mais la suite de l'énoncé laissait planer une ambiguïté quant à l'unicité des noms de groupes :

Pour prendre un exemple. X est contact de Y. Chez X, Y fait parti du groupe "Collègue" alors que chez Y, X fait parti du groupe "Ami".

J'avais compris, peut-être à tort, que les groupes Collègues et Amis pouvaient être présents chez les deux sous le même identifiant.

Si un groupe n'appartient qu'à une seule personne (et on autorise alors plusieurs fois le même nom de groupe), il est en dépendance directe de la personne et doit disparaître si la personne disparaît de la BDD. Il peut-être alors judicieux de procéder à une identification relative du groupe, c'est à dire de faire participer la clé étrangère grp_id_proprietaire à la clé primaire, ce qui donne cette table :
Groupe (grp_id_possesseur, grp_numero, grp_nom)

Ce principe est celui qui peut être utilisé pour numéroter les chambres d'hôtel ou les lignes de commande ou de facture...

Dès lors, pour l'affectation des contacts aux groupes, on retrouve une structure similaire à celle de ma table :
Contenu_groupe (cgr_id_possesseur, cgr_numero_groupe, cgr_id_contact)

[JPhi33]

Bonsoir,

La modélisation est une chose, l'ensemble de contraintes imposées par les outils de modélisation en est une autre...

La modélisation correcte cette question (de la question initiale tout au moins) produit le MCD suivant :

Code :

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

1
2
3
4
5
6
7
8
9
10
     ┌--a contact--┐ 
     |             |
    0,n            |
     |             |
[ PERSONNE ]   (Contact)--1,1---( )----0,n->[ Groupe ]
     |             |
    0,n            |
     |             |
     └-est contact-┘

La transformation de l'association réflexive Contact dans le MLD donne la table :

Contact(id_personne_p, id_personne_c, id_groupe#)

Illustration avec l'exemple d'origine :

X est contact de Y. Chez X, Y fait parti du groupe "Collègue" alors que chez Y, X fait parti du groupe "Ami".

Code :

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

1
2
3
4
5
id_personne_p id_personne_c id_groupe

      X             Y           2     --> Groupe "Collègue"
      Y             X           1     --> Groupe "Ami"

Si, et seulement si, un outil de modélisation est utilisé au niveau conceptuel (MCD), il faudra se résoudre à adopter la proposition de CinePhil :

Personne -0,n----avoir----(1,1)- Contact
|---------------0,n----être------(1,1)-------|

J'ai ici en fait transformé une association en entité Contact. Les cardinalités entre parenthèses indique une identification relative.

car les outils ne savent pas associer une CIF ou une association à une autre association.

[fsmrel]

Bonsoir,

Si, et seulement si, un outil de modélisation est utilisé au niveau conceptuel (MCD), il faudra se résoudre à adopter la proposition de CinePhil.

Une petite nuance : si pour le MCD on utilise une notation du genre IE (Information Engineering), l’outil de modélisation permet de considérer que PERSONNE est une entité-type régulière (cf. Chen, Kernel de Codd), et CONTACT une entité-type associative (Codd). Le problème évoqué ne concerne que la notation Merise.

Par exemple, en cochant l'option Entité/Relation de l'outil Power AMC :

[JPhi33]

Bonsoir à tous,

Une petite nuance : si pour le MCD on utilise une notation du genre IE (Information Engineering), l’outil de modélisation permet de considérer que PERSONNE est une entité-type régulière (cf. Chen, Kernel de Codd), et CONTACT une entité-type associative (Codd). Le problème évoqué ne concerne que la notation Merise.

Effectivement, j'ai omis de préciser que je me place dans le cadre d'une notation Merise (bien qu'ayant utilisé le terme MCD qui, à mon sens, est suffisant pour spécifier ce contexte de notation).

[CinePhil]

Effectivement, j'ai omis de préciser que je me place dans le cadre d'une notation Merise (bien qu'ayant utilisé le terme MCD qui, à mon sens, est suffisant pour spécifier ce contexte de notation).

Moi aussi, quand je dis MCD, ce sont des entités (rectangles) reliées à des associations (ellipsoïdes).
Ton dernier schéma François ressemble à celui généré par MySQL Workbench et que ce logiciel nomme "EER Diagram". Comme il modélise directement les futures tables de la BDD et matérialise les clés étrangères, il se rapproche davantage du MLD de Merise.

Et j'ai toujours trouvé un peu dangereux de se lancer directement sur MySQL Workbench sans avoir fait un MCD au préalable justement parce qu'on peut, dans MySQL Workbench relier des tables associatives, c'est à dire en fait des associations du MCD entre elles, ce que n'autorise pas, à juste raison à mon avis,le formalisme du MCD.

[fsmrel]

Bonsoir,

Ton dernier schéma François ressemble à celui généré par MySQL Workbench et que ce logiciel nomme "EER Diagram". Comme il modélise directement les futures tables de la BDD et matérialise les clés étrangères, il se rapproche davantage du MLD de Merise.

Que MySQL Workbench prétende faire dans le EER (Enhanced Entity/Relationship), c’est son problème (ça fait moins ringard que ER), même si ses entités-types n’en sont pas (présence des clés étrangères) et — au moins dans la version (5.2.29 CE) dont je dispose — il n’a rien de plus (pas de notion d’héritage par exemple). Disons qu’avec cet outil, je confirme qu'on est déjà au niveau logique, en ayant omis l’étape conceptuelle.

Que mon schéma conceptuel ressemble à un schéma Workbench :

• Oui quant à la représentation graphique (rectangles au lieu d’ellipses, tout comme dans un diagramme de classes ULM), ce qui n’est pas essentiel : Power AMC pourrait être aménagé sans difficulté pour qu’on puisse dessiner un rond au lieu d’un carré, voire même un « carrond ».
  
• La ressemblance s'arrête là, car dans mon schéma il n'y a pas de clés étrangères et donc la règle de non redondance des propriétés chère à Merise est respectée, contrairement à ce qui se passe avec Workbench (ou avec tout MLD du reste, par construction).

Au passage, voici un diagramme de classes (DC) parfaitement équivalent au schéma conceptuel que j’ai proposé, et je ne sache pas qu'un DC se situe au niveau logique :




Maintenant, si je dérive mon schéma conceptuel (ou le diagramme de classes équivalent) en schéma logique, alors d’accord, je produis un MLD qui ressemble furieusement à son homologue Workbench :



Avec Workbench :




Quant au débat (ellipse vs rectangle), je m’appuie sur le bon sens de Ted Codd, pour qui il y a une typologie des entités-types : les entités-types fortes (kernel entity types), les entités-types faibles (characteristic entity types) et les entités-types associatives (associative entity types), sans oublier l’héritage de type : une entité-type sous-type d’un kernel est un kernel, une entité-type sous-type d’une characteristic est une characteristic et une entité-type sous-type d’une entité-type associative est une entité-type associative, tout ceci est fort logique. Et quelque soit sa nature, toute d’entité-type peut être en relation avec toute autre entité-type, ce qui relève du principe d’orthogonalité (orthogonalité veut dire indépendance). Je vous renvoie à son article de 1979.

Et j'ai toujours trouvé un peu dangereux de se lancer directement sur MySQL Workbench sans avoir fait un MCD au préalable justement parce qu'on peut, dans MySQL Workbench relier des tables associatives, c'est à dire en fait des associations du MCD entre elles, ce que n'autorise pas, à juste raison à mon avis,le formalisme du MCD.

Pour le fun, je rappelle que depuis près de 20 ans, avec OOM (Orientation Objet dans Merise), les associations d’associations sont légitimes (le principe d’orthogonalité cher à Ted Codd est respecté...) et c'est plutôt leur interdiction qui est arbitraire comme il l'est dit dans cet extrait de l’ouvrage Les OBJETS, de Mokrane Bouzeghoub, Georges Gardarin, Patrick Valduriez (trois poids lourds) :




Notons qu’Arnold Rochfeld José Morejon et Pascal Negros ont étudié le concept d’associations d’associations au début des années quatre-vingt-dix (Inter-Relationship Links in the E-R Model).

Je crois me souvenir aussi que JPhi33 avait parlé de cette histoire d'associations d'associations et cité Morejon dans un de ses messages à ce sujet.

En tout cas, pour ne pas être embêté avec cette histoire de ronds et de carrés, je me sers de ce qui me convient, qui de Merise, qui de l'E/R, en utilisant les deux à la fois avec Power AMC. Ainsi, je ne suis pas empoisonné avec les CIF, l'entité-type DATE et autres joyeusetés et impedimenta...