Utilisateur, Client -> Contact

Bonjour,

J'ai un MCD tout simple qui me pose problème.

J'ai 2 entités : des utilisateurs et des clients.
Chaque utilisateur peut contacter plusieurs clients.
Chaque client peut être être contacté par plusieurs utilisateurs.

La représentation au niveau MCD donne donc ceci :
http://img844.imageshack.us/img844/4363/83275110.jpg

On se rend donc compte qu'un même utilisateur ne pourra jamais contacter le même client 2 fois.

On est donc obligé de créer une entité date
http://img707.imageshack.us/img707/6718/45235788.jpg

Laquelle des 2 solutions est la bonne ?

Au niveau MLD, pourrais-je gommer cette table DATE afin d'obtenir ceci :

USER (#id user, nom)
CLIENT (#id client, nom)
CONTACT (#id user, #id_client, #date, lieu)


J'ai également quelques autres questions plus ou moins en rapport :

- Si j'ajoute un attribut type au contact (ex: téléphone, fax, mail donc une petite liste figée dans le temps), est-il plus intéressant de le laisser en attribut (et au niveau MDP, faire une énumération) ou en faire une entité à part ?

- Si je souhaite enregistrer les adresse dans les entités USER et CLIENT, est-il intéressant de créer une entité ADRESSE sachant que le nombre de cas ou un utilisateur et client auront la même adresse sera très faible voire inexistant ?

- Il y a un concept que je n'ai toujours pas bien saisi, ce sont les CIF, quelqu'un pourrait-il m'expliquer de manière simple comment cela fonctionne ?:?

Merci d'avance :)

Bonjour tunsty,

Citation:

---

Envoyé par tunsty

Au niveau MLD, pourrais-je gommer cette table DATE

---

Oui. De mon côté j’ai passé bien des nuits chez mes clients, à « gommer » à la nausée cette table qui était référencée inutilement par des dizaines d’autres et qu’il fallait maintenir, sans pour autant qu’il y ait la moindre valeur ajoutée.

Certains AGL permettent d'éviter d'avoir à réaliser cette tâche bien fastidieuse consistant à commencer par supprimer les clés étrangères avant d'éliminer la table DATE.

Par exemple, dans le cas PowerAMC, à partir du MCD :

http://www.fsmwarden.com/developpez_..._Date)_MCD.png

Je lui demande de produire le MLD correspondant, mais sans table DATE :

http://www.fsmwarden.com/developpez_..._Date)_MLD.png

Ceci a été rendu possible parce que l’AGL offre la possibilité de ne pas produire de table pour une entité-type :

http://www.fsmwarden.com/developpez_...generation.png

Par contre je n’ai pas trouvé cette possibilité avec Open ModelSphere, aussi devrez-vous faire le ménage manuellement (mais j'ai peut-être mal cherché...)

Maintenant, quelles sont vos règles de gestion ?

Si on interprète les diagrammes ci-dessus :

— Le même jour un utilisateur donné peut contacter plusieurs clients ;

— Le même jour un client donné peut être contacté par plusieurs utilisateurs (au risque qu’il finisse par en être agacé :P)

Ces règles sont-elles bien les vôtres ?

Suite...

Citation:

---

Envoyé par tunsty

Si j'ajoute un attribut type au contact (ex: téléphone, fax, mail donc une petite liste figée dans le temps), est-il plus intéressant de le laisser en attribut (et au niveau MDP, faire une énumération) ou en faire une entité à part ?

---

En SQL il est possible de mettre en œuvre une énumération contrôlée, comme dans le cas de la colonne TypeContact ci-dessous, grâce à une contrainte appropriée (CONTACT_TYPE en l’occurrence) :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

CREATE TABLE CONTACT ( UtilisateurId Int Not null, ClientId Int Not null, DateContact Date Not null, Lieu Varchar(64) Not null, TypeContact Varchar(16) Not null, CONSTRAINT CONTACT_PK PRIMARY KEY (UtilisateurId, ClientId, Date), CONSTRAINT CONTACT_TYPE CHECK (TypeContact IN ('courriel', 'fax', 'téléphone')), CONSTRAINT CONTACT_UTILISATEUR_FK FOREIGN KEY (UtilisateurId) REFERENCES UTILISATEUR (UtilisateurId), CONSTRAINT CONTACT_CLIENT_FK FOREIGN KEY (ClientId) REFERENCES CLIENT (ClientId) ) ;

---

Néanmoins, la recommandation est de prévoir une entité-type au niveau conceptuel (donc une table au niveau MLD) ad-hoc.

Le code SQL devient :

TABLE TYPE_CONTACT

Code:

---

1 2 3 4 5 6

CREATE TABLE TYPE_CONTACT ( TypeContactId Int Not null, TypeContactLibelle Varchar(64) Not null, CONSTRAINT TYPE_CONTACT_PK PRIMARY KEY (TypeContactId) ) ;

---

TABLE CONTACT

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

CREATE TABLE CONTACT ( UtilisateurId Int Not null, ClientId Int Not null, DateContact Date Not null, TypeContactId Int Not null, Lieu Varchar(64) Not null, CONSTRAINT CONTACT_PK PRIMARY KEY (UtilisateurId, ClientId, Date), CONSTRAINT CONTACT_UTILISATEUR_FK FOREIGN KEY (UtilisateurId) REFERENCES UTILISATEUR, CONSTRAINT CONTACT_CLIENT_FK FOREIGN KEY (ClientId) REFERENCES CLIENT, CONSTRAINT CONTACT_TYPE_CONTACT_FK FOREIGN KEY (TypeContactId) REFERENCES TYPE_CONTACT ) ;

---

Le MLD correspondant :

http://www.fsmwarden.com/developpez_...ontact_MLD.png


Le MCD correspondant est plus problématique, car CONTACT étant une association, il faut y faire participer une entité-type TYPE_CONTACT avec une contrainte selon laquelle TYPE_CONTACT ne doit pas participer à l’identification de CONTACT :

http://www.fsmwarden.com/developpez_...ontact_MCD.png

Dans cette représentation, la flèche rouge symbolise une CIF (contrainte d’intégrité fonctionnelle) qui se lit ainsi :

UTILISATEUR X CLIENT X DATE -> TYPE_CONTACT

C'est-à-dire que pour chaque occurrence de UTILISATEUR X CLIENT X DATE il y a exactement une occurrence de TYPE_CONTACT, ce qui ne serait pas le cas si TYPE_CONTACT participait à l'identification de CONTACT (et ça serait le b...). A noter que CIF est synonyme de DF (dépendance fonctionnelle).

Pour ne pas avoir à affronter des difficultés qui sont la conséquence de la vision merisienne de l’identification des associations, le plus simple est peut-être de déguiser CONTACT en entité-type « faible » (weak entity-type)...

Version Open ModelSphere pour varier un peu :

MCD

http://www.fsmwarden.com/developpez_...ct_OMS_MCD.png

Notez l’utilisation de l’identification relative (cardinalités 1,1 soulignées) qui fait que les entités-types UTILISATEUR et CLIENT participent à l’identification de CONTACT (alors qu'en lecture rapide on pourrait se dire que seule la propriété ContactDate identifie CONTACT, ce qui serait absurde).


MLD

http://www.fsmwarden.com/developpez_...ct_OMS_MLD.png