Discussion :

[BLJ.CHAUVIN]

Bonjour à tous,

j'ai un petit soucis sur un MCD que je n'arrive pas à régler et je vais m'efforcer de vous expliquer le plus clairement possible.

Comme une image vaut mieux qu'un long discours...


Donc un 'usager' (une personne physique) peut avoir 1 ou plusieurs 'contact' (cad une fiche regroupant ses différents numéros de téléphone, adresse mail, etc...) et peut travailler dans 1 ou plusieurs 'societe'. (les cardinalités sur l'image ne sont pas bonnes)

Une 'societe' peut avoir 1 ou plusieurs 'usager', et 0 ou 1 'contact' (fiche avec les numéros du standard).(les cardinalités sur l'image ne sont pas bonnes)

Jusque là tout va bien, mais du coup 'contact' peut avoir 0 ou 1 'usager' (zéro si c'est le 'contact' d'une 'societe'), et 0 ou 1 'usager' (dans le cas inverse). Or avec cette cardinalité je peux me retrouver avec un 'contact' qui soit en 0 pour les 'usager' et 0 pour les 'societe' du coup je me retrouve avec un 'contact' qui n'est lié à rien du tout.

Comment faire pour que mon entité 'contact' soit lié soit à l'un soit à l'autre? Une sorte de type boolean ou quelque chose s'en approchant?

Merci pour votre attention.

[Richard_35]

Bonjour BLJ.CHAUVIN,

Tout d'abord, sur la forme :

Comme une image vaut mieux qu'un long discours...

puis

.../... et peut travailler dans 1 ou plusieurs 'societe'. (les cardinalités sur l'image ne sont pas bonnes)

et encore

.../... et 0 ou 1 'contact' (fiche avec les numéros du standard).(les cardinalités sur l'image ne sont pas bonnes)

==> l'image en question porte plus à confusion qu'autre chose, non ?


Sur le fond :
Je trouve que le terme "Contact" est trompeur : en fait, il s'agit, si j'ai bien compris, des informations de contact pour un usager ou une société. Donc, toujours si j'ai bien compris :

Donc un 'usager' (une personne physique) peut avoir 1 ou plusieurs 'contact'

==> Usager ---1,n---[possède les info. contact]---0,1--- Contact (0 car un enregistrement de Contact peut être lié à une Société et non à un Usager)

.../... et peut travailler dans 1 ou plusieurs 'societe'

Une 'societe' peut avoir 1 ou plusieurs 'usager'

==> Usager ---1,n---[travaille]---1,n--- Société

.../... et 0 ou 1 'contact'

==> Société ---0,1---[possède les info. contact]---0,1--- Contact (0 car un enregistrement de Contact peut être lié à un Usager et non à une Société)

.../... du coup je me retrouve avec un 'contact' qui n'est lié à rien du tout.

==> dans l'absolu, oui !... puisque c'est ce que tu énonces dans tes règles de gestion.

Ensuite, tout n'est pas résoluble dans le MCD. Dans l'application, si la saisie des informations de contact n'est possible QUE via un usager ou une société, le booléen en question devient dynamique.

Mais, c'est vrai que la représentation graphique de ce cas m'est inconnue. Donc, en final, je ne répond pas à ta question... mais bon...

[fsmrel]

Bonsoir,

Comment faire pour que mon entité 'contact' soit lié soit à l'un soit à l'autre? Une sorte de type boolean ou quelque chose s'en approchant?

Non. Il est préférable de procéder à la généralisation des entités-types SOCIETE et USAGER et mettre en ainsi en œuvre une entité-type PERSONNE dont SOCIETE et USAGER deviendront des sous-types. CONTACT est alors à associer à PERSONNE (relation de composition => identification relative, cardinalités 1,1 entre parenthèses) :

[PERSONNE]--0,N---(POSSEDER)---(1,1)--[CONTACT]

[BLJ.CHAUVIN]

Bonjour,

Tout d'abord merci pour vos réponses, j'ai essayé d'en tenir compte et de corriger mes erreurs mais je ne suis pas sûr d'avoir bien compris vos conseils.

Voici un schéma (cette fois à jour) de mon mcd:


J'ai gardé le schéma proposé par fsmrel à savoir :
[ENTITE]--0,N---(a_pour_contact)---(1,1)--[CONTACT]
Je crois que cette partie est bonne, merci à vous.

Par contre avec 'heritage_entite' je trouve la répartition des clé primaires un peu étrange. Si je lis bien le schéma [ENTITE], [ENTREPRISE], [USAGER] et (employe_chez) ont tous en commun la primary key 'identite'.

Est-ce normal ou bien ai-je encore une erreur dans mon MCD?

[Richard_35]

Bonjour BLJ.CHAUVIN et Fsmrel,

... sauf que

Donc un 'usager' (une personne physique) peut avoir 1 ou plusieurs 'contact'

et

Une 'societe' peut avoir .../... 0 ou 1 'contact'

==> en passant par une entité commune, tu ne peux pas avoir deux cardinalités différentes : il te faudra donc choisir.

En fait, ton problème est d'éviter les enregistrements de "contact" sans "usager" ni "société".

Si tu restes dans tes règles de gestion initiales :
Société
- Id_Societe (PK)
...

Usager
- Id_Usager (PK)
...

Contact
- Id_Contact (PK)
- Id_Source
- Type_source (S=Société, U=Usager)
...

Relations respectant tes règles de gestion initiales
Usager ---1,n---[possède les info. contact]---0,1 ;
Société ---0,1---[possède les info. contact]---0,1--- Contact.

Il me semble donc que le seul moyen respectant tes règles de gestion initiales est :
- de ne saisir un contact QUE via un Usager ou une Société avec forçage des informations de "contact" ("S" et Id_Société ou "U" et Id_Usager) ==> sous Access, on parlerait de sous-formulaire ;
- un trigger (avant création) qui contrôlerait qu'il n'existe pas plus de 1 contact pour la société concernée (que pour les sociétés, et non pour les usagers).

[fsmrel]

Bonsoir,

J'ai gardé le schéma proposé par fsmrel à savoir :
[ENTITE]--0,N---(a_pour_contact)---(1,1)--[CONTACT]

Presque. Vous noterez que j’ai identifié CONTACT relativement à ENTITE (1,1 mis entre parenthèses) car CONTACT est une entité-type faible, c'est-à-dire une propriété multivaluée d’ENTITE.

Par contre avec 'heritage_entite' je trouve la répartition des clé primaires un peu étrange. Si je lis bien le schéma [ENTITE], [ENTREPRISE], [USAGER] et (employe_chez) ont tous en commun la primary key 'identite'.
Est-ce normal ou bien ai-je encore une erreur dans mon MCD?

C’est on ne peut plus normal et il n’y a rien d’étrange. La clé primaire {IdEntite} d’ENTITE est héritée par les sous-types ENTREPRISE et USAGER et {IdEntite} y est aussi clé étrangère.

Votre « MPD » (en fait MLD) devrait ressembler à ceci :




Une question : quel SGBD sera utilisé ?