Discussion :

[khyor]

Bonjour à tous,
dans le cadre de mon projet qui consiste à créer une application de gestion de ressources au sein de mon entreprise. J'aurais besoin de vos lumières sur un point.

Mon application permettra de gérer une base EMPLOYE, INTERLOCUTEUR, CLIENT, AFFAIRE, AGENCE.
Jusqu'à aujourd'hui j'envisageais de stocker les données de contact (adresse, numéro et mail) au sein même de chaque table.

Néanmoins, il est a envisager d'avoir plusieurs téléphones ou emails, voir même plusieurs adresses pour un client ou un employé.

J'ai donc décidé d'externaliser cette notion en créant un ensemble de 3 tables (voir schéma)
- la table mediaContact permettra d'identifier le média utilisé (Numéro, Adresse, Email)
- la table typeContact permettra quant à elle d'identifier le type relatif au média (Personnel, professionnel, Mobile, Fax, Autre, etc.)
- la table universContact sera donc la table de jonction

On retrouvera donc dans univers contact :
- l'id du typeContact
- l'id du médiaCOntact
- la valeur renseignée
- l'id du lieu (dans le cas d'une adresse)

Maintenant c'est là que je me pose des questions.
Quelle solution dois-je adopter pour que mes Entités PERSONNE, AGENCE, CLIENT et AFFAIRE puissent être en lien avec UNIVERCONTACT

la solution que j'envisageais était de créer un champs univers qui servirait a définir l'entité mais je ne pense pas que ce soit la meilleur solution sachant qu'il n'y a aucun lien réellement définit entre les tables.

Qu'en pensez vous et Qu'auriez vous fait ?

[CinePhil]

Il semble que ceci fasse suite à cette discussion dans laquelle, si j'ai bien suivi, tu as fini par faire un héritage de Personne vers Employe et Contact, lequel Contact semble s'être transformé en Interlocuteur dans ton nouveau schéma.

Tu dis donc ceci :

il est a envisager d'avoir plusieurs téléphones ou emails, voir même plusieurs adresses pour un client ou un employé.

Donc les adresses, téléphones et adrels doivent être associées à Personne et à Client.

J'ai donc décidé d'externaliser cette notion en créant un ensemble de 3 tables (voir schéma)
- la table mediaContact permettra d'identifier le média utilisé (Numéro, Adresse, Email)
- la table typeContact permettra quant à elle d'identifier le type relatif au média (Personnel, professionnel, Mobile, Fax, Autre, etc.)
- la table universContact sera donc la table de jonction

Ceci me semble bien compliqué !

Un numéro de téléphone, une adresse physique et une adresse électronique (que je préfère appeler en français 'adrel') sont trois choses sémantiquement bien différentes.
Je créerais donc trois entités/tables pour ces trois notions et je les associerais toutes les trois aux deux entités/tables Personne et Client.

D'ailleurs ton entité/table Client se justifie séparément de la personne si tous les clients sont des personnes morales. Si les clients peuvent aussi être des personnes physiques, tu ajoutes le client dans l'héritage de personne. Il y a eu récemment des propositions de schémas pour gérer à la fois les clients personnes morales et physiques. Une recherche avec ces mots clés dans le forum devrait t'y conduire.

Restons sur ta distinction actuelle...
Un téléphone peut alors difficilement appartenir à plus d'un client il me semble !
En principe, une adrel n'appartient qu'à une personne mais il peut arriver qu'elle serve pour un couple ou une famille. Par contre, elle n'appartiendra au maximum qu'à un seul client personne morale.

MCD :
Telephone -0,n----Appartenir----0,n- Personne
|-----------------0,n----Appartenir----0,1- Client

Adresse -0,n----Situer----0,n- Personne
|-------------0,n----Situer----0,n- Client

Adrel -0,n----Appartenir----0,n- Personne
|-------------0,n----Appartenir----0,1- Client

Tables :
Personne (p_id, p_nom...)
Client (c_id, c_nom...)
Telephone (t_id, t_numero...)
Adresse (a_id, a_rue1, a_rue2, a_code_postal, a_id_ville)
Adrel (ae_id, ae_adrel...)
Tel_Personne (tp_id_telephone, tp_id_personne)
Tel_Client (tc_id_telephone, tc_id_client)
Personne_Adresse (pa_id_personne, pa_id_adresse)
Client_Adresse (ca_id_client, ca_id_adresse)
Personne_Adrel (pae_id_personne, pae_id_adrel)
Client_Adrel (cae_id_client, cae_id_adrel)

Si on considère qu'un client peut être une personne morale ou physique et qu'on fait un héritage de Personne vers Client (si ensuite il faut aussi considérer les fournisseurs et les organismes publics, il vaut mieux faire un héritage de Personne vers Personne_Physique puis de cette dernière vers les différents types de personnes physiques), il n'y aura que trois associations de Personne vers Téléphone, Adresse et Adrel, ce qui est plus simple et réduit le nombre de tables.

Ensuite, tu veux typer ces données :

(Personnel, professionnel, Mobile, Fax, Autre, etc.)

Les types 'personnel' et 'professionnel' peuvent s'appliquer aussi bien à un téléphone qu'à une adresse ou une adrel mais 'Mobile' et 'Fax' ne s'appliquent qu'au type des téléphones ! Il ne faut peut-être pas les mélanger !

Je me rends compte que mon approche engendre aussi pas mal de tables, même si elle est sémantiquement plus claire. A toi de voir ce que tu trouves plus simple, peut-être en essayant de rédiger quelques requêtes.

[khyor]

Il semble que ceci fasse suite à cette discussion dans laquelle, si j'ai bien suivi, tu as fini par faire un héritage de Personne vers Employe et Contact, lequel Contact semble s'être transformé en Interlocuteur dans ton nouveau schéma.

Oui c'est exactement cela.

Tu dis donc ceci :

Donc les adresses, téléphones et adrels doivent être associées à Personne et à Client.


Ceci me semble bien compliqué !

Oui, mais pas seulement.

En fait, les problématiques sont :

• qu'une personne (employé ou interlocuteur) peut avoir plusieurs adresses postales.
  exemple : un employé dispose d'une adresse personnel comme tout le monde. toutefois, dans le cadre de son travail il peut être amené à séjourner pour une durée plus ou moins longue dépendant de sa mission dans un hotel ou une résidence 2ndaire.
• qu'un personne (employé ou interlocuteur) peut avoir plusieurs numéro de téléphones.
  exemple : un employé dispose de son numéro fixe à son domicile, mais dispose également de son numéro mobile personnel en plus du numéro mobile professionnelle affecté. par ailleurs il peut avoir un numéro de téléphone à l'hotel ou dans sa résidence 2ndaire.
• qu'un personne (employé ou interlocuteur) peut avoir plusieurs adrel.
  exemple : un employé comme un interlocuteur dispose de son mail perso, mais également de son mail professionnel.
• qu'un client (qui est comme tu me l'a fait remarqué une personne morale) dispose elle aussi d'une adresse postale et d'un numéro de téléphone/fax(standard)
• qu'une agence(là encore une personne morale) dispose d'une adresse postale et d'un numéro de téléphone/fax(standard)
• qu'une affaire dispose elle aussi d'une adresse postale (permettant sa géolocaliation) car dans mon cas une affaire corresponds à un chantier généralement

Un numéro de téléphone, une adresse physique et une adresse électronique (que je préfère appeler en français 'adrel') sont trois choses sémantiquement bien différentes.
Je créerais donc trois entités/tables pour ces trois notions et je les associerais toutes les trois aux deux entités/tables Personne et Client.

Oui, je suis conscient qu'il s'agit de trois choses sémantiquement différentes.
Le problème est que je ne veux pas surcharger de table la base de données, étant données que le travail actuel présenter n'est qu'une première brique sur l'ensemble des modules qui viendront s'y greffer par la suite avec la gestion des ressources.

D'ailleurs ton entité/table Client se justifie séparément de la personne si tous les clients sont des personnes morales. Si les clients peuvent aussi être des personnes physiques, tu ajoutes le client dans l'héritage de personne. Il y a eu récemment des propositions de schémas pour gérer à la fois les clients personnes morales et physiques. Une recherche avec ces mots clés dans le forum devrait t'y conduire.

Oui j'ai vu ça. J'y rejetterai un coup d'oeil, mais il me semble que dans mon cas, un client est systématiquement une personne morale. et que cette personne morale est représenter par au moins 1 ou plusieurs interlocuteurs.

Restons sur ta distinction actuelle...
Un téléphone peut alors difficilement appartenir à plus d'un client il me semble !

oui mais il peut par contre appartenir à plusieurs interlocteurs.
Exemple : nous avons chez nous des lignes directs qui sont affecté à un bureau et pas à une personne distinct, ce qui fait que 3 collaborateurs peuvent avoir le même numéro de ligne téléphonique.

En principe, une adrel n'appartient qu'à une personne mais il peut arriver qu'elle serve pour un couple ou une famille. Par contre, elle n'appartiendra au maximum qu'à un seul client personne morale.

Oui, je suis d'accord là dessus.

MCD :
Telephone -0,n----Appartenir----0,n- Personne
|-----------------0,n----Appartenir----0,1- Client

Adresse -0,n----Situer----0,n- Personne
|-------------0,n----Situer----0,n- Client

Adrel -0,n----Appartenir----0,n- Personne
|-------------0,n----Appartenir----0,1- Client

Tables :
Personne (p_id, p_nom...)
Client (c_id, c_nom...)
Telephone (t_id, t_numero...)
Adresse (a_id, a_rue1, a_rue2, a_code_postal, a_id_ville)
Adrel (ae_id, ae_adrel...)
Tel_Personne (tp_id_telephone, tp_id_personne)
Tel_Client (tc_id_telephone, tc_id_client)
Personne_Adresse (pa_id_personne, pa_id_adresse)
Client_Adresse (ca_id_client, ca_id_adresse)
Personne_Adrel (pae_id_personne, pae_id_adrel)
Client_Adrel (cae_id_client, cae_id_adrel)

Si on considère qu'un client peut être une personne morale ou physique et qu'on fait un héritage de Personne vers Client (si ensuite il faut aussi considérer les fournisseurs et les organismes publics, il vaut mieux faire un héritage de Personne vers Personne_Physique puis de cette dernière vers les différents types de personnes physiques), il n'y aura que trois associations de Personne vers Téléphone, Adresse et Adrel, ce qui est plus simple et réduit le nombre de tables.

Il est vrai que même si j'avais lu le poste à ce sujet sur le forum, je n'avais pour le moment pas envisager de pousser l'héritage à ce point.
Ce qui me ferait :
un héritage de Personne vers Personne_Physique et Personne_Morale
un héritage de Personne_Physique vers Employé et Interlocuteur
un héritage de Personne_Morale vers Agence et Client
ce qui ensuite permet d'associer comme tu l'a indiqué : Personne vers Téléphone, Adresse et Adrel.

reste a voir ou placer Affaire dans ce schéma, vu que ce n'est pas une personne morale ni physique.

Ensuite, tu veux typer ces données :

Les types 'personnel' et 'professionnel' peuvent s'appliquer aussi bien à un téléphone qu'à une adresse ou une adrel mais 'Mobile' et 'Fax' ne s'appliquent qu'au type des téléphones ! Il ne faut peut-être pas les mélanger !

Oui, j'avoue avoir basiquement copier le typage de mon googlephone sur ce coup là

Si j'adopte ta solution de créer 3 tables : adresse, téléphone et adrel ; Il pourrait être judicieux de remplacer téléphone par numéro et d'indiquer un typage (mobile, fixe, fax) dans cette table.
Car il n'y a pas d'intérêt de remonter ce typage dans la table d'association sachant qu'un numéro défini comme numéro fixe ou fax, ne pourrait pas être typé différemment. qu'en penses-tu ?

Ensuite de la même manière je peux rajouter un champ boolean dans chacune de ces tables pour indiquer si l'information est perso ou pro.

[CinePhil]

Si j'adopte ta solution de créer 3 tables : adresse, téléphone et adrel ; Il pourrait être judicieux de remplacer téléphone par numéro et d'indiquer un typage (mobile, fixe, fax) dans cette table.
Car il n'y a pas d'intérêt de remonter ce typage dans la table d'association sachant qu'un numéro défini comme numéro fixe ou fax, ne pourrait pas être typé différemment. qu'en penses-tu ?

Si tu mets le type du numéro dans la table Numero, un numéro ne pourra avoir s'un seul type. N'y a t-il pas des clients qui peuvent avoir le même numéro pour le fixe et le fax ? Un artisan par exemple ?

Ensuite de la même manière je peux rajouter un champ boolean dans chacune de ces tables pour indiquer si l'information est perso ou pro.

Là encore, tu empêcherais une adresse ou un numéro d'être à la fois perso et pro. Je mettrais donc plutôt ces infos dans les tables associatives.
Pour les numéros, il y aurait deux infos (deux colonnes) : une pour le typage fixe/mobile/fax et une pour le typage pro/perso.

À creuser encore...

[khyor]

Si tu mets le type du numéro dans la table Numero, un numéro ne pourra avoir s'un seul type. N'y a t-il pas des clients qui peuvent avoir le même numéro pour le fixe et le fax ? Un artisan par exemple ?

En effet, j'avais pas pensé à ce cas.

Là encore, tu empêcherais une adresse ou un numéro d'être à la fois perso et pro. Je mettrais donc plutôt ces infos dans les tables associatives.
Pour les numéros, il y aurait deux infos (deux colonnes) : une pour le typage fixe/mobile/fax et une pour le typage pro/perso.

À creuser encore...

C'est juste également. Le cas ne s'était pas présenter jusqu'ici, je n'y avais donc pas pensé non plus.

A voir donc pour opter pour un typage au niveau des table d'association, je vais réfléchir à tous ça.

Merci de ton aide