Discussion :

[loganblack]

Bonjour,

J'essai de modéliser la relation suivant :

- PM = personne morale
- PP = personne physique
- A = activité

une PP peut exercer une ou plusieurs A.
une A est exercée dans une PM.
une PM contient une ou plusieurs PP.
une A se carctérise par un type.
le détail de chaque type est different selon le type de l'activité.

Exemple concret :
Monsieur X(PP) exerce l'activité professionnel(A) Directeur au sein de la Société 1(PM).
Monsieur X(PP) exerce l'activité Mandataire(A) au sein de l'Association 2(PM).

Dans le premier cas A est de type professionnel et fais donc appel à un détail de l'activité disons qui contiendra 3 éléments
Dans le second cas A est de type mandataire et fera appel à un détail qui en contiendra 5 mais complétement different du premier cas. Ces éléments seront propres à A (par exemple date début, date fin, qui a nommé, etc...).
Dans une autre table il y aura les éléments du mandat mais propre au mandat (nom du mandat, description, etc...).

Comment gérer le fait que les élément de détail de l'activité soit différent selon l'activité, en gardant une seul table de relation entre PM et PP ?

Dois-je créer une table de relation pour chaque type d'activté ? (ce qui me parait lourd pour l'affichage des différentes activités des membres d'un PM).

Merci pour votre aide.

[fsmrel]

Bonsoir Loganblack,

Comment gérer le fait que les élément de détail de l'activité soit différent selon l'activité, en gardant une seul table de relation entre PM et PP ?

L’objet de la modélisation n’est pas de vouloir systématiquement tout mettre dans la même boite, mais de mettre "the right thing at the right place".
Tout dépend du niveau auquel se situent les données caractérisant le détail de l’activité.
Si des données dépendent seulement du type d’activité, elles ne font pas partie de la (ou les) relation(s) liant PA et PP.
Si des données dépendent et de PA et de PP, elles font partie de la (ou les) relation(s) liant PA et PP.
Si des données dépendent uniquement de PA, elles sont directement rattachées à PA via une (ou deux) entités-types ad-hoc.
Si des données dépendent uniquement de PP, elles sont directement rattachées à PP via une (ou deux) entités-types ad-hoc.

Bref, deux points sont à vérifier :
Respecter la BCNF. Voir par exemple :
http://www.developpez.net/forums/sho...03&postcount=4
Interdire les valeurs nulles. Voir par exemple :
http://www.developpez.net/forums/sho...88&postcount=7

Vous n’en dites pas assez sur les données caractéristiques des activités : Si vous avez des doutes, merci de les faire figurer dans votre message, aves leurs relations précises (exhaustives) avec les autres attributs, afin que nous arrivions à dresser l’inventaire des dépendances fonctionnelles et ainsi faire avancer le schmilblick de façon rationnelle.
Si vous voulez à tout prix voir figurer les activités dans la même table, ne le faites pas au niveau des tables de base, mais s’une vue d’union.

[loganblack]

Bonjour,
Tout d'abord merci pour votre attention.

J'ai en effet lu les liens que vous m'avez fournis, je les avais lu avant et j'avais essayé d'appliquer ce qui était dit à mon modèle, mais en vain.

Je reviens donc avec plus de détail sur mon problème.

j'ai donc les éléments suivants :

PP :
- mail perso
- tel perso
- @ perso
- nom
- prenom
- genre

PM :
- Raison sociale
- tel
- fax
- @
- informations économiques

lorsqu'une PP exerce une activité professionnelle (par exemple DAF, DRH, PDG) au sein d'une PM, elle peut avoir :
- fonction
- titre
- rang
- mail
- tel
- @
- date début
- date fin

lorsque qu'une PP exerce une activité mandataire (représente les intérèts d'un groupe) au sein d'une PM, elle peut avoir :
- fonction
- titre
- tel
- @
- mail
- date début de son mandat
- date de fin de son mandat
- qui l'a nommé
- lien vers le détail du mandat

le détail d'un mandat :
- libelle/nom
- organisme mandataire
- durée
- mode d'accès
- responsable du mandat (différent de la PP en relation avec ce mandat)
- nombre de membre

je donne maintenant des exemples concrets :
M. X est Directeur du Groupe Corp. il reçoi son courrier au siège sociale du Groupe Corp.
M. X est aussi RH d'une Filiale du Groupe Corp dont le siège sociale est à une adresse différente, il peut recevoir son courrier à l'adresse de la PM, ou alors il peut choisir de recevoir le courrier à l'adresse donnée pour cette activité.
Toujours M. X peut exercer un mandat au sein de la PM Assoce et demandais de recevoir le courrier destiné à cette activité chez lui, ou à son entreprise ou à l'adresse de Assoce.

D'ou les multiples champs d'adresse qui permette une souplesse dans le choix pour une PP de recevoir son courrier à l'adresse souhaitée.

Je vais avoir besoin d'afficher toutes les activités pour une PP. Si je sépare les relations entre les PM et les PP en trois table (une pour chaque type, professionnelle, mandat, syndicale) est-ce que la requete pour l'affichage des activités d'une PP ne va pas être trop loude ?

J'essai d'optimiser au maximum et de comprendre les automatismes à prendre lors de la mise en relation de cas complexe, merci por votre aide.

[fsmrel]

Bonjour Loganblack,

Je vais avoir besoin d'afficher toutes les activités pour une PP. Si je sépare les relations entre les PM et les PP en trois table (une pour chaque type, professionnelle, mandat, syndicale) est-ce que la requete pour l'affichage des activités d'une PP ne va pas être trop loude ?

Qu’entendez-vous par requête lourde ? La présence de quelques jointures ? Fusionner les activités professionnelles et mandataires en une seule table ne changera pas grand-chose du point de vue du nombre de tables participant aux jointures.

En revanche, si vous logez tout dans une table unique, la cardinalité de celle-ci (nombre de lignes) sera la somme des cardinalités des autres tables, et son degré (nombre de colonnes) supérieur à celui de chaque table prise isolément, d’où un risque d’obésité pouvant avoir des conséquences se répercutant jusqu’aux index (nombre de niveaux d’index plus élevé). Cette table comportera des valeurs nulles, sans objet) du fait que, par exemple, l’attribut servant à référencer un mandat n’a pas de sens concernant l’activité professionnelle, même chose concernant la référence vers la personne ayant nommé un mandataire. Et d’autres attributs n’ayant de sens que pour un type d’activité donné donneront lieu eux-aussi à valeurs nulles, concourant ainsi à l’obésité de la table, sans parler des complications et chausse-trappes inhérentes à ces valeurs nulles. Qui plus est, tous ces attributs ne sont peut-être pas tous identifiés aujourd’hui...

Réfléchissez aux conséquences sur les opérations de mise à jour.

Et surtout, avant de penser à la lourdeur des requêtes et de la performance de la base de données, commencez par modéliser correctement (les éléments que vous avez fournis paraissent satisfaisants).

Du strict point de vue de la théorie relationnelle, la structure ci-dessous est pertinente, même si elle peut être aménagée en fonction des précisions que vous apporterez :




Le graphique se lit ainsi :
Une personne physique peut exercer plusieurs activités professionnelles (inversement, une activité professionnelle est exercée par une et une seule personne physique).
Une personne physique peut exercer plusieurs activités mandataires (inversement, une activité mandataire est exercée par une et une seule personne physique).
Une personne physique peut nommer d’autres personnes physiques pour exercer des activités mandataires (inversement, une activité mandataire est décidée par une et une seule personne physique).
Dans le cadre d’une activité mandataire donnée, une personne physique est en relation avec un et un seul mandat (inversement, un mandat peut être exercé par plusieurs personnes physiques).
Une personne physique peut être responsable de plusieurs mandats (inversement, un mandat est sous la responsabilité d’une seule personne physique).
Etc.
A vous de voir, ce qui est bon et ce qui ne l’est pas, et surtout de compléter le modèle. Ce n’est qu’une fois ce travail achevé que vous pourrez commencer à prototyper les performances et effectuer les réglages physiques en fonction du top 10 des requêtes, des mises à jour, etc., etc., etc...

A vous de jouer.

[loganblack]

Merci pour votre réponse, j'ai finalement obtenu le même schéma que vous après mures réflections.
C'est celui qui me paraît le mieux convenir à mon système, et j'ai pu approfondir avce votre explication les éléments qui me paraissaient obscures.
Encore Merci.