Discussion :

[zyend]

Bonjour,

j'ai besoin d'avis sur un problème de conception classique...
Il s'agit de concevoir une base de données permettant entre autre de gérer des entreprises, ainsi que ses contacts.

Mais également une gestion optimale des adresses et des numéros de télephone. Les regles de gestion n'ont pas été clairement définies donc libre à moi de concevoir un systeme le plus optimal possible.

A savoir, les Contacts et les Entreprises ont plusieurs adresses certes, mais toujours d'un seul type d'adresse ( par exemple: Siege Social, ou Division R&D, ou Livraison etc).

De même que pour les numéros de télephone.
Je ne tiens pas à affecter plusieurs fois le même numéro à une entreprise et à un contact. Car lors des phases de modification, c'est le bordel à gérer les doublons.

Une entreprise peut ne pas avoir de numéro de telephone. Et un numero de telephone peut être utilisé à la fois par l'entreprise ET/OU par un ou plusieurs contacts.

Voilà donc pour les "règles de gestion".

J'ai commencé la conception du MCD, mais force est de reconnaitre que je n'ai pas pratiqué depuis un certain temps, et j'aimerai l'avis de personnes
mieux eclairées pour me dire si je suis sur la bonne voie...ou complètement à côté de la plaque.

Ci-joint le modele physique de données.
Je n'ai le MCD que sur papier, car la version de Power Designer qui est installée sur mon poste, ne me permet pas de créer de MCD, désolé.
J'ai fait la demande pour que ce soit corrigé mais bon...j'attends.

Merci de votre aide,

Zyend

[fsmrel]

Bonsoir Zyend,

Concernant les adresses, c’est jouable, sinon qu’il peut y avoir des problèmes de performance si des batchs lourds ont lieu (entrées/sorties non synchrones). La table entre Contact et Address ne figure pas, mais j’ai considéré qu’elle était là.

En passant, je suppose qu’une adresse peut être la même pour une compagnie et un contact.

Concernant les téléphones :

Selon votre MLD, la clé primaire de la table UsePhone est définie par le triplet {Id_Company, Id_Contact, Id_Phone}, ce qui entraîne qu’un contact soit toujours impliqué : un numéro de téléphone est nécessairement celui d’un contact (aucun composant d’une clé primaire ne peut être null).
Si vous voulez que des compagnies aient des numéros de téléphone indépendamment des contacts, Id_Contact ne doit pas figurer dans la clé primaire de la table UsePhone.

Vous vouliez peut-être éviter d’en arriver là, mais la solution propre consiste à dédoubler UsePhone en UsePhoneCompany et UsePhoneContact. Inutile de dupliquer les numéros de téléphone (effectivement, gérer les doublons c’est comme vous dites...). Disons que la règle est la suivante : l’identifiant d’un téléphone figure soit dans UsePhoneCompany soit dans UsePhoneContact, mais pas dans les deux à la fois. La compagnie peut continuer à ne pas avoir de téléphone. Si un contact a un ou plusieurs numéros en propre, pas de problème, simplement il hérite en plus de ceux de sa compagnie.

[zyend]

Bonjour fsmrel,

Et merci pour vos suggestions.

La table entre Contact et Address ne figure pas, mais j’ai considéré qu’elle était là.

oui tout à fait...il y a du avoir un problème au moment du copier/coller...mea culpa.

En passant, je suppose qu’une adresse peut être la même pour une compagnie et un contact.

Oui, en-effet.

Concernant les téléphones :

Selon votre MLD, la clé primaire de la table UsePhone est définie par le triplet {Id_Company, Id_Contact, Id_Phone}, ce qui entraîne qu’un contact soit toujours impliqué : un numéro de téléphone est nécessairement celui d’un contact (aucun composant d’une clé primaire ne peut être null).
...
...
Disons que la règle est la suivante : l’identifiant d’un téléphone figure soit dans UsePhoneCompany soit dans UsePhoneContact, mais pas dans les deux à la fois. La compagnie peut continuer à ne pas avoir de téléphone. Si un contact a un ou plusieurs numéros en propre, pas de problème, simplement il hérite en plus de ceux de sa compagnie.

Ah.
C'est une très bonne remarque effectivement...je n'avais pas pensé à ça.
J'ai toutefois une remarque à faire, qu'est-ce qui m'empeche (d'un point de vue modelisation) d'utiliser un id de telephone à la fois dans UsePhoneContact et UsePhoneCompany ?

Merci,

Zyend

[fsmrel]

Bonjour Zyend,

qu'est-ce qui m'empeche (d'un point de vue modelisation) d'utiliser un id de telephone à la fois dans UsePhoneContact et UsePhoneCompany ?

Rien !

Cf. la pièce jointe, MPD avec des liens représentés selon le mode "relationnel" :
Outils\Options du modèle\Paramètres du modèle\Notation : conceptuelle.

[zyend]

Bonjour Zyend,

Rien !

Cf. la pièce jointe, MPD avec des liens représentés selon le mode "relationnel" :
Outils\Options du modèle\Paramètres du modèle\Notation : conceptuelle.

zut, je ne trouve pas cette option sur la version de mon PowerDesigner...

Sinon c'est bien ce que je pensais, rien ne m'empêche d'insérer l"ID du telephone dans les deux tables CompUsePhone et ContactUsePhone.

Une autre solution pourrait consister à garder la forme précédente, et considérer qu'une Entreprise possède toujours au moins 1 contact, en considérant que son contact numéro 0 soit l'entreprise elle même...

Zyend

[fsmrel]

Une autre solution pourrait consister à garder la forme précédente, et considérer qu'une Entreprise possède toujours au moins 1 contact, en considérant que son contact numéro 0 soit l'entreprise elle même...

C’est de la bidouille. Appelez un chat un chat, une entreprise n’est pas un contact. Si vous vous lancez dans ce genre d’exercice, dans deux ou trois ans, vous-même ou plus embêtant, vos successeurs, commencerez à vous posez des questions : Bon sang, mais pour quelle raison tordue avoir voulu à tout prix qu’une entreprise soit un contact ? Les applications sont par exemple, truffées de dates ésotériques du genre "14/07/1789" etc. dont l’objet était de même nature, mais, les années passant, dont la raison profonde s’est évanouie...

[zyend]

C’est de la bidouille. Appelez un chat un chat, une entreprise n’est pas un contact. Si vous vous lancez dans ce genre d’exercice, dans deux ou trois ans, vous-même ou plus embêtant, vos successeurs, commencerez à vous posez des questions : Bon sang, mais pour quelle raison tordue avoir voulu à tout prix qu’une entreprise soit un contact ? Les applications sont par exemple, truffées de dates ésotériques du genre "14/07/1789" etc. dont l’objet était de même nature, mais, les années passant, dont la raison profonde s’est évanouie...

J'en conviens parfaitement
Je vais me limiter à ta première suggestion qui consiste à créer une table CompUsePhone et ContactUsePhone.
Après mures reflexions, c'est effectivement la solution la plus robuste et la plus viable.

Merci,

Zyend