Discussion :

[betauser]

Bonjour,

J’ai commencé à créer une base dont les objectifs sont les suivants :
-Créer, mettre à jour, lister les contacts (T_Contacts) par Société (T_Sociétés), la table T_Service étant réservée aux salariés de mon entreprise
-créer, mettre à jour, lister les projets (T_Projets) par société, par contact client, et suivis par nous
-créer, mettre à jour, lister les plannings des salariés chez nous pour identifier dans quelle société ils sont à une date donnée, et pour quel projet.

Les formulaires interrogent et mettent à jour les données soit par sélection d’une société, soit par sélection d’un salarié chez nous.

Cela fonctionne à peu près (il me reste qques bugs mais cela avance grâce aux forums et tutoriels).

Néanmoins, avant d’aller plus loin (il reste qques bugs, des états à faire, et à déployer la base auprès des utilisateurs), je serais plus serein si des avis pouvaient m’être donnés sur mon modèle. En effet, j’ai l’impression d’avoir mis plusieurs infos redondantes. Par ex. faut-il rappeler IDSociété et IDContact dans les tables T_Projets et T_Suivi? Si c'est inutile, comment s'en affranchir dans mes formulaires puisque j'interroge une société, puis les contacts de la société, pour créer un projet ou un suivi...
Par ailleurs, j'imagine que je pourrais supprimer T_Service et l'intégrer à T_Contacts (en intégrant ma société à T_Société). initialemement, j'avais cette démarche mais j'ai eu des soucis à créer des formulaires T_Suivi et T_Projets pour mettre le contact client et le salarié de mon entreprise, tirés tous les 2 du même champ de la même base, dans le même formulaire.

Merci par avance pour vos avis éclairés.

Cordialement,

[fsmrel]

Bonsoir,


Comme vous ne fournissez pas les règles de gestion des données, je vais essayer de les interpréter au vu de la structure de vos tables et de leurs clés primaires.

1) Vous avez fait figurer l’attribut IDContact dans la table T_Projets. Puisque {IDProjet} est clé primaire de cette table, on en déduit la dépendance fonctionnelle :

{IDProjet} → {IDContact}

(Un projet détermine un contact, autrement dit pour un projet donné il n’y a qu’un contact). Par ailleurs, un contact détermine une société :

{IDContact} → {IDSociete}

Donc {IDProjet} détermine {IDSociete} transitivement (via {IDContact}), ce qui fait que la présence de l'attribut IDSociete dans la table T_Projets provoque un viol de la 3NF (troisième forme normale) : l’attribut IDSociete doit donc dégager de la table (application du théorème de Heath). Autrement dit, la relation entre les tables T_Projets et T_Societes doit être remplacée par une relation entre les tables T_Projets et T_Contacts.


2) Vous avez fait figurer l’attribut IDProjet dans la table T_Planning. Puisque {IDRDV} est clé primaire de cette table, on en déduit la dépendance fonctionnelle

{IDRDV} → {IDProjet}

(un rendez-vous détermine un projet, autrement dit pour un rendez-vous donné il n’y a qu’un projet). Par ailleurs, un projet détermine un service :

{IDProjet} → {IDService}

donc {IDRDV} détermine {IDService} transitivement (via {IDProjet}), ce qui fait que la présence de l'attribut IDService dans la table T_Planning provoque un viol de la 3NF : l’attribut IDService doit donc dégager de la table T_Planning (application du théorème de Heath). Autrement dit, la relation entre les tables T_Planning et T_Service doit être remplacée par une relation entre les tables T_Planning et T_Projets.


3) On retrouve le même problème de transitivité concernant les relations entre les rendez-vous et les sociétés : un rendez-vous détermine un projet qui détermine un contact qui détermine une société : la relation entre les tables T_Planning et T_Societes doit être remplacée par une relation entre les tables T_Planning et T_Projets.

Le MLD correspondant est le suivant :

Par ailleurs, j'imagine que je pourrais supprimer T_Service et l'intégrer à T_Contacts

En fait il faut passer par la généralisation/spécialisation (héritage) : on définit une table PERSONNE dans laquelle on factorise les attributs communs à CONTACT et SERVICE. L’identifiant de PERSONNE (clé primaire de la table dans votre cas) est hérité par CONTACT et SERVICE (sous le nom IDPersonne ou les noms IDContact, IDService, peu importe).

Le MLD correspondant est le suivant :




ACCESS ne montre pas les cardinalités minimales d’où ambiguïté dans la lecture de la relation entre PERSONNE ET CONTACT. On est guère plus avancé en examinant l’image ci-dessous, mais tacitement PERSONNE est la table référencée et CONTACT la table référençante.




Maintenant, si les règles de gestion des données diffèrent de celles que j'ai supposées, quelles sont-elles ?

[betauser]

Bonjour Fsmrel,

Merci pour vos commentaires. Cela confirme mes doutes: mes tables et relations n'étaient pas bien construites.

Réponse 1 et 3 : ok, j'ai compris.
Pour les réponses 2, j'ai plus de mal à saisir, mais je pense que je n'ai pas donné toutes les infos.

Dans ma base, un salarié de ma société (ex: un commercial) signe avec un contact d'une autre société (ex: un acheteur) un projet pour effectuer de 1 à plusieurs missions dans sa société. Ensuite, le même salarié ou d'autres salariés de ma société réalisent dans la société cliente, sans lien avec le contact client, des missions (ex : formation, installation logiciel, …) dans le cadre du projet, à différentes dates. Ce n'est pas forcément celui qui est responsable du projet dans ma société qui va réaliser les diverses missions du projet chez le client.

J’avoue ne pas avoir compris l’intérêt de la table Personne donc j’ai remis la table « T_Contacts 1= ma société » , qui ne serait que la table T_Contacts « filtrée » à ma société. Je vais lire la doc liée aux héritages pour mieux comprendre (j’ai vu un tutoriel sur le sujet), mais cela peut-il convenir en l’état ?

Ensuite, je pense que je ne dois pas supprimer IDService (le collaborateur de ma société) de la table T_Planning. Si je supprime cette info, je pense que je ne pourrai pas conserver la trace de qui chez nous va faire quoi chez le client. Est-ce correct?

Vos remarques m'ont également fait penser à un autre point: le projet définit la ou les types de missions qui seront réalisées. Mais un salarié réalise également une ou des missions sans projet ou sans société (ex: le commercial qui fait de la prospection remplit son planning avec des missions "prospect", "administratif", sans rattachement à un projet. Le salarié en congés remplit également son planning avec une mission "congés", sans lien avec un projet ou une société).
Donc peut-on imaginer que lorsque un salarié remplit son planning, l'IHM lui laisse le choix de remplir son planning soit en sélectionnant un projet, puis la mission, soit en sélectionnant directement la mission?

En conclusion, ci-dessous le nouveau modèle que j'ai élaboré.
Est-ce mieux ainsi?

Merci par avance.

[IMG]F:\Relations V2.JPG[/IMG]

[betauser]

Aïe, Aïe, Aïe, j'écris et je me rends compte ensuite que mon modèle ne convient pas à ce que j'écris.

En effet, si un salarié peut avoir une mission sans projet dans une société (je reprends l'exemple du commercial qui va voir un client et qui aura donc une mission "prospection" avec une société mais pas de projet), cela signifie que je dois rajouter IDSociété dans T_Planning.

Donc en remplisssant le planning, un salarié de ma société doit pouvoir:
- soit sélectionner un projet (ce qui donne automatiquement la société), puis slectionner le type de mission parmi les missions que le projet offre
- soit sélectionner une société avec un type de mission parmi toutes les missions existantes

Mon modèle devient donc le suivant.

Qu'en pensez-vous avec ectte correction (pourquoi ai-je cette impression bizarre de voir des liens partout alors que dans d'autres bases exemples, cela parait plus clair avec moins de relations "dans tous les sens" )?

Cordialement,

[fsmrel]

Bonsoir,

Laissons tomber pour le moment les histoires d’héritage.

Votre modèle n'est pas satisfaisant...

je pense que je n'ai pas donné toutes les infos.

C’est le moins qu’on puisse dire, comme quoi une représentation graphique ne dit pas ce qu’elle est censée représenter et que l’inventaire des règles de gestion des données est indispensable pour travailler correctement.

Voilà donc ce que j’ai compris, merci de confirmer, infirmer, compléter, affiner, etc. :

Des collaborateurs de la maison (par exemple des commerciaux) prospectent des entreprises et l’on a alors besoin de savoir quels collaborateurs ont prospecté quelles entreprises, à quelles dates.

En relation avec des contacts des entreprises, des collaborateurs de la maison (par exemple des directeurs) signent des contrats pour des projets, chaque projet pouvant faire l’objet de plusieurs types de mission.

Des collaborateurs réalisent des missions en relation avec les projets signés, pour des types de mission figurant dans la liste des types de mission définis à la signature des contrats. La date d’affectation d’un collaborateur à une mission d’un projet est gérée (questions : vous intéressez-vous à la durée d’une mission d’un collaborateur ? Un collaborateur peut-il être affecté à plus d’un type de mission dans le cadre d’un projet donné ?)

Les collaborateurs tiennent à jour leur planning pour ce qui ne concerne pas les prospections et missions : cela concerne les congés, les formations et autres activités à caractère administratif.

Merci de compléter, etc.

[betauser]

Bonjour,

Ok pour le recadrage.

Je reprends les besoins :
1. créer, lister, mettre jour les contacts par société cliente (adresse, tel, mail, …).
2. mêmes besoins dans ma société (avec les mêmes données)
3. Créer, mettre à jour les comptes-rendus de réunion ou de prospects de mes salariés chez les clients.
4. Créer, mettre à jour les projets créés par ma société auprès des sociétés clientes
5. Créer, mettre à jour le planning de réalisation des missions des collaborateurs de ma société chez les clients

Des collaborateurs de la maison (par exemple des commerciaux) prospectent des entreprises et l’on a alors besoin de savoir quels collaborateurs ont prospecté quelles entreprises, à quelles dates

Oui. On a également besoin de savoir quel client a été vu au sein de la société cliente dans ce cadre. Enfin, nous avons besoin d’une synthèse de quelques lignes sur la réunion. Ceci correspond au besoin n°3. L’idéal pour terminer ce point serait d’avoir un système de relance pour assurer le suivi des prospects, mais ceci est un besoin annexe, non prioritaire.

En relation avec des contacts des entreprises, des collaborateurs de la maison (par exemple des directeurs) signent des contrats pour des projets, chaque projet pouvant faire l’objet de plusieurs types de mission.

Oui. J’ajoute que les collaborateurs qui signent peuvent être les mêmes que ceux qui prospectent.
De plus, un projet correspond parfois à un seul type de mission bien défini (ex : formation uniquement) et parfois à plusieurs types de missions différents (ex : 10 jours de formation, 3 jours d’installation, 2 jours d’analyse, …). Chaque projet créé comporte alors les infos suivantes :
-quel contact client est le représentant du projet dans la société cliente,
-quel collaborateur chez nous est responsable de ce projet,
-montant et nb de jours totaux prévisionnels,
-dates de début et de fin prévisionnels,
-les différentes missions réalisables au sein du projet (ex : formation, installation, …),
-le statut du projet (en discussion, en réalisation, abandonné, terminé).
Ceci correspond alors au besoin n° 4.

Des collaborateurs réalisent des missions en relation avec les projets signés, pour des types de mission figurant dans la liste des types de mission définis à la signature des contrats. La date d’affectation d’un collaborateur à une mission d’un projet est gérée (questions : vous intéressez-vous à la durée d’une mission d’un collaborateur ? Un collaborateur peut-il être affecté à plus d’un type de mission dans le cadre d’un projet donné ?).

Oui. Une fois le projet accepté chez le client, nous suivons les dates de réalisation.
Un collaborateur (qui peut être celui qui a prospecté, celui qui a signé, ou un autre) effectue 1 ou des missions du projet chez le client, à une ou des dates et renseigne son planning. Un collaborateur peut donc être affecté à 1 ou plusieurs projets pour 1 ou plusieurs missions.

A ce stade, il n’est plus utile de savoir qui est le contact client. La durée de la mission n’est pas utile : si un collaborateur réalise plusieurs missions de plusieurs projets dans la journée, le collaborateur crée plusieurs lignes de missions/projets pour la même date. A l’inverse, si la même mission se poursuit plusieurs jours, le collaborateur « copie-colle » cette mission et ce projet sur plusieurs dates.
Un collaborateur peut être affecté à plusieurs missions sur un même projet, et à plusieurs projets. Les dates peuvent être consécutives ou pas pour la réalisation des missions d’un projet. Ceci correspond au besoin n°5.

Les collaborateurs tiennent à jour leur planning pour ce qui ne concerne pas les prospections et missions : cela concerne les congés, les formations et autres activités à caractère administratif.

Oui, les collaborateurs tiennent à jour leur planning pour ce qui ne concerne pas les prospections et missions. Mais ils tiennent aussi à jour leur planning pour les dates de réalisation des projets et missions (point précédent). Ceci correspond également au besoin n°5.

Le modèle envoyé hier (« relations V3 ») me semblait répondre aux différents besoins, excepté le besoin n° 3. Le besoin n° 3 sera créé une fois les besoins 4 et 5 terminés, si cela est possible de les séparer.

Dans mon approche, j’ai créé une table mission qui recense toutes les possibilités d’occupation d’une journée (ex : « formation, installation, support, … » qui sont des missions de projets, et « congés, administratif, trajet, … » qui sont des « missions hors projet »). Peut-être faut-il séparer ces 2 fonctionnalités (missions en lien avec un projet d'une part et occupations hors projet d'autre part) ?

A nouveau, merci pour vos commentaires à venir.

[ilank]

Bonjour,
je me permets d'intervenir.
Il semble manquer dans ta conception, la notion d'acteur. Je m'explique, tous tes collaborateurs (intervenants ou non) n'ont pas les mêmes droits vis à vis des projets, missions et donc du planning.
En reprenant, l'exemple des commerciaux, il semble qu'eux seuls peuvent créer de nouveaux projets, les autres intervenants ne pouvant saisir dans leur planning que des missions existantes.
Dans ce cas, une mission de prospection ne pose plus de problème puisqu'il faut renseigner, la société prospectée et le contact au sein de cette société et par conséquent cela donne bien la possibilité de créer un nouveau projet de type prospection, type n'admettant qu'une mission et une seule.
Quant aux congés, il s'agît plus de la disponibilité des intervenants que de projets proprement dits, reste à savoir si il est nécessaire de conserver dans la base, les périodes d'indisponibilités des collaborateurs et la raison de ces indisponibilités. Les trajets sont-ils inclus dans une mission ?
Pour les comptes-rendus de mission, il s'agît dans un premier temps d'ajouter un champ (sûrement Memo) dans la table mission. Un compte-rendu peut-il donner lieu à la création d'une nouvelle mission, d'un nouveau rendez-vous.... ?
Dernière chose, est-ce la mission qui est attribuée à un collaborateur ou juste le rendez-vous ?
En clair, il est sûrement nécessaire d''ajouter aux besoins évoqués, la nature des collaborateurs et leurs différentes actions sur le système. Comme :
Qui, quand peut créer de nouveaux contacts ?
Qui, quand peut créer de nouveaux projets ?
Qui, quand peut insérer de nouvelles missions à un projet ?
Qui, quand peut renseigner un nouveau rendez-vous dans le planning ?
etc, etc.....

[fsmrel]

@ betauser,


Au vu de vos explications, une évolution du MLD pourrait correspondre à ce qui suit, sachant que les problèmes de dates et de coûts sont à aménager. Je propose un MLD réalisé avec Power AMC, car l’outil Relation d’ACCESS me fait patiner.



A noter que la table PLANNING_ADMIN correspond uniquement aux données purement administratives (congés, formation, ...) Pour la partie réalisation (missions), le planning des réalisateurs peut être obtenu à partir de la table MISSION.

[fsmrel]

il est sûrement nécessaire d''ajouter aux besoins évoqués, la nature des collaborateurs

Dans un premier temps, il ne coûte effectivement pas cher de prévoir une table des fonctions des collaborateurs :

[ilank]

Bonjour betauser, fsmrel,
fsmrel ce n'est pas vraiment à ça que je pense, mais à plus à ajouter au Modèle Conceptuel des Données (MCD) un Modèle Conceptuel des Traitements.
Les traitements devant être modélisés selon la nature des intervenants.
Par exemple :
Est-ce que tous les collaborateurs font de la prospection ?
Est-ce que tous les collaborateurs peuvent être Gestionnaire de projet ?
Est-il possible d'affecter des rendez-vous à un collaborateur en congé ?
Est-il possible d'affecter à un autre collaborateur les rendez-vous d'un collaborateur en congé ? Si oui, comment ?
Faut-il supprimer la fiche d'un collaborateur qui a quitté l'entreprise ?
Si un contact change de société pour une autre société cliente, faut-il créer une fiche pour ce contact ? Modifier sa fiche ?
Est-ce qu'un projet est affecté à une société et à un contact ou juste à un contact ?
etc ......
Bref, le but étant de définir à la fois ce qui peut être fait, par qui, selon quelle condition; ce qui permet à terme de définir un MCD possible et cohérent, et le MCT souhaité.

[fsmrel]

Bonsoir,

En clair, il est sûrement nécessaire d''ajouter aux besoins évoqués, la nature des collaborateurs et leurs différentes actions sur le système. Comme :
Qui, quand peut créer de nouveaux contacts ?
Qui, quand peut créer de nouveaux projets ?
Qui, quand peut insérer de nouvelles missions à un projet ?
Qui, quand peut renseigner un nouveau rendez-vous dans le planning ?
etc, etc.....

Concernant l’aspect « Qui peut effectuer telle action », la base de données doit être enrichie d’un système d’habilitation. Par exemple, des droits peuvent être accordés aux collaborateurs en fonction d’un profil ad-hoc, indépendamment de leur fonction :




Comme le montre cette vue, un collaborateur peut obtenir des droits dont son profil hérite.

ce n'est pas vraiment à ça que je pense, mais à plus à ajouter au Modèle Conceptuel des Données (MCD) un Modèle Conceptuel des Traitements.

[...]Est-ce que tous les collaborateurs peuvent être Gestionnaire de projet ? [...]

Certes, mais en tenant compte de ce que l’on modélise avec le MCD, cf. ci-dessus. Quelque part, un MCT est une conséquence logique du MCC (cf. Parlez-vous Merise ?), alors que pouvoir être gestionnaire d’un projet relève du MCD et se déduit de la relation entre les tables COLLABORATEUR et PROFIL.

En descendant au niveau logique, on en arrive au stade SQL et la norme propose l’instruction CREATE ASSERTION qui permet de traiter de contraintes que l’on sous-traite complètement au SGBD, quand dans les années quatre-vingts on en était réduit à développer des programmes (par exemple empêcher la prise de rendez-vous pour des collaborateurs qui sont ou seront en congés à ce moment-là). Si le SGBD ne propose pas l’instruction CREATE ASSERTION, on se rabat sur un trigger, si le SGBD ne propose pas non plus l’instruction CREATE TRIGGER, on pleure, etc.

[betauser]

Bonjour Fsmrel et Ilank

Merci pour vos commentaires.

Ilank, d’accord sur le fait qu’il serait plus simple d’accorder un profil et un ensemble d’actions à chaque collaborateur, pour définir de façon plus restreinte les « qui fait quoi commment » et le traitement des taches. Toutefois, cela ne correspond à notre organisation, si on considère que chacun peut tenir plusieurs rôles selon les projets. L'outil informatique va donc devoir prendre en compte les particularités de notre organisation.
Donc, à nouveau, même si les remarques sont tout à fait justifiées, je préfère laisser aux divers collaborateurs plusieurs rôles ; pour mieux « coller à la réalité ».

Fsmrel, merci pour votre modèle. A partir de ces éléments, j’ai construit un nouveau modèle qui parait plus en phase avec les règles de gestion d’un SGBD.

Je continue à bloquer sur l’aspect planning. Je mélange « IHM » d’une part et « tables et relations » d’autre part.
Le planning d’un collaborateur (T_PlanningRéal) se construit à partir de « plusieurs sources » :
- Les missions d’un projet déjà engagé (T_Projet_Mission).
- Les journées « sans client » (Congés, Formation, Autres)
- Les journées de prospection en clientèle (ces informations sont contenues dans la table T_Suivi).
Le collaborateur saisira dans son planning les dates de réalisation des missions sur les projets engagés, et les dates de journées « sans client ». Par contre, les dates de prospection proviennent des informations de la table T_Suivi, puisque le collborater saisit la date, le contact et le Compte-rendu de sa réunion. Inutile alors pour le collaborateur de re-saisir les informations date et type de mission (ici=prospect) dans son planning.
Dois-je faire une table qui rassemble ces différentes « sources de planning » (ou en tout cas, une table qui rassembles les différentes missions)?
A nouveau, merci encore pour vos éléments.

[ilank]

Bonjour betauser, fsmrel,
Il est bon de rendre à César ce qui lui appartient, je n'ai pas betauser proposé de créer de nouvelles tables, mais je voulais évacuer les différences entre ton discours dans lequel apparaît des types de fonctions (les commerciaux) et le modèle ne faisant mention que de collaborateurs.
Tu parles de différents types de projet ou mission, or, ces types disparaissent dans tes modèles pourquoi ?
Tu indiques à plusieurs reprises, qu'un collaborateur gère son planning mais nulle part dans le modèle, la notion d'utilisateur n'est présente permettant d'identifier un utilisateur du système avec un collaborateur. Ici, un collaborateur peut modifier le planning de n'importe quel autre collaborateur.
Voilà, pourquoi en autre je propose d'abord d'identifier ce qui doit être fait, par qui, comment, quand.....

Je continue à bloquer sur l’aspect planning. Je mélange « IHM » d’une part et « tables et relations » d’autre part.

C'est pour cette raison que je propose de réaliser aussi un modèle des traitements.

[fsmrel]

Bonjour,

Tu indiques à plusieurs reprises, qu'un collaborateur gère son planning mais nulle part dans le modèle, la notion d'utilisateur n'est présente permettant d'identifier un utilisateur du système avec un collaborateur. Ici, un collaborateur peut modifier le planning de n'importe quel autre collaborateur.

Chaque chose en son temps. Avant de traiter des habilitations, il faut déjà essayer de résoudre le problème des plannings.


betauser, je reviens sur un de vos précédents message :

quel collaborateur chez nous est responsable de ce projet

Je vous avais proposé un MLD dans lequel la table PROJET comporte deux liens avec la table COLLABORATEUR, chaque lien correspondant à un rôle précis : Signataire d’une part, Responsable d’autre part. Votre dernier MLD ne permet de représenter qu’un des deux rôles. Avec ACCESS représenter les deux rôles est possible, même si la façon de devoir procéder est plutôt débile (deux liens entre PROJET et COLLABORATEUR suffisant largement, cf. Power AMC, mais je n’ai que la version ACCESS 2003 et les choses ont-elles évolué avec les versions suivantes ? Pouvez-vous m’informer à ce sujet ?) :



Concernant votre table Mission :

Pour éviter toute ambiguïté, il serait préférable de changer le nom de cette table en Type_Mission.

Concernant votre table T_Projet_Mission :

Votre table T_Projet_Mission correspond à ma table PROJET_MISSION dans laquelle j’ai fait figurer les attributs DateDebutPrevue et Duree. En effet, un projet pouvant comporter différents types de mission, il est probable que tous ne débutent pas en même temps. Par exemple, les développements ne commencent pas en même temps que la conception et la production des dossiers correspondants... Par ailleurs l’attribut Duree correspond à la durée prévue approximativement pour un type de mission et un projet donnés. Pas la peine donc de faire figurer ces attributs si les informations correspondantes ne vous sont pas utiles, mais on risque de vous demander plus tard de les fournir, par exemple pour estimer l’écart entre la durée prévue et la durée réelle (calcul rendu possible grâce à la présence dans la table MISSION (celle que j’ai proposée précédemment) de l’attribut NbJoursConsommes).

Par ailleurs votre table T_Projet_Mission comporte un attribut IDJob inutile, puisque la paire {IDProjet, IDMission} suffit pour être clé primaire.



Concernant les missions

Mon MLD comporte une table MISSION qui correspond plus aux jours effectivement passés sur les projets mais pas aux prévisions de type planning. Je le complète donc en ajoutant une table PLANNING_MISSION qui normalement correspond à votre table T_PlanningReal :

Je continue à bloquer sur l’aspect planning. Je mélange « IHM » d’une part et « tables et relations » d’autre part.

Les tables impliquées dans les plannings sont normalement les suivantes :




Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
SOCIETE
IDSociete   NomSociete  Etc
        1   Yadupour 
        2   Morzy  
        3   Schmill

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CONTACT
IDContact   IDSociete   NomContact   Etc
        1           1   M. Alex 
        2           1   Mlle Dupond 
        3           1   M. Toto 
        4           2   Mme Irma 
        5           2   M. Merblek

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
COLLABORATEUR
IDCollaborateur   Nom        Matricule   Etc
              1   Albert     007 
              2   Alice      458 
              3   Arsène     123 
              4   Bernard    002 
              5   Berthe     456 
              6   Bénédicte  841

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
MOTIF
IDMotif   LibelleMotif
      1   Congés
      2   RTT
      3   Formation

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
PROJET
IdProjet   IDContact   IDSignataire   IDResponsable   NomProjet        StatutProjet   DateDebut   DateFin     CoutProjet
       1           3              2               3   Platon Phase 3   non commencé   2011-02-25  2012-02-24      200000
       3           4              2               2   Magellan         en cours       2009-01-05  2011-12-31      700000

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
TYPE_MISSION
IDType_Mission   LibelleMission
             1   Formation
             2   Conception
             3   Modélisation
             4   Développement

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
PROJET_MISSION
IdProjet   IDType_Mission   DateDebutPrevue   Duree
       1                1   2011-02-25            5
       1                2   2011-03-07           40
       1                3   2011-03-07           80
       1                4   2011-06-0           200

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
PLANNING_ADMIN
IDPlanning   IDCollaborateur   DateDebut   DateFin     IDMotif   Notes
         1                 1   2010-07-01  2010-07-31        1
         2                 1   2011-02-21  2011-02-24        2
         3                 1   2011-03-21  2011-03-24        3
         4                 4   2011-01-31  2011-02-18        2

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
PLANNING_MISSION
IDPlanning   IDCollaborateur   IDProjet   IDType_Mission   DateDebut   DateFin   Notes
         1                 1          1                1   2011-02-25  2011-03-03 
         2                 4          1                2   2011-03-07  2011-04-30

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
PLANNING_CIAL
IDRDV   IDCollaborateur   IDContact   DateRDV     CompteRendu        Etc
    1                 2           5   2011-01-05  Ça sera sportif

Vous pouvez par ailleurs développez des requêtes qui permettront de faire des vues de jointure.

Concernant le planning administratif, une vue PLANNING_ADMIN_V :



Au résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
Nom      Matricule  TypePlanning  NomProjet    LibelleMotif DateDebut   DateFin      Notes  
Albert   007        Admin         Sans objet   Congés       2010-07-01  2010-07-31 
Albert   007        Admin         Sans objet   RTT          2011-02-21  2011-02-24 
Albert   007        Admin         Sans objet   Formation    2011-03-21  2011-03-24 
Bernard  002        Admin         Sans objet   RTT          2011-01-31  2011-02-18

______________________________________________

Concernant le planning commercial, une vue PLANNING_CIAL_V :




Au résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Nom       Matricule  TypePlanning  NomSociete  NomContact  DateRDV     CompteRendu
Alice     458        Commercial    Morzy       M. Merblek  2011-01-05  Ça sera sportif

Concernant le planning mission, une vue PLANNING_MISSION_V :



Au résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
Nom      Matricule  TypePlanning  NomSociete NomProjet       LibelleMission DateDebut   DateFin      Notes
Albert   007        Clientèle     Yadupour   Platon Phase 3  Formation      2011-02-25  2011-03-03 
Bernard  002        Clientèle     Yadupour   Platon Phase 3  Conception     2011-03-07  2011-04-30

Et pour afficher le tout, une vue Planning_Admin_Mission_Cial_V :

Code SQL :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
SELECT Nom, Matricule, 'Clientèle' AS Planning, NomSociete, NomProjet, LibelleMission AS Mission, Datedebut, DateFin, Notes
FROM   PLANNING_MISSION_V
 
UNION ALL 
 
SELECT Nom, Matricule, 'Admin', 'Sans objet', 'Sans objet', LibelleMotif, DateDebut, DateFin, Notes
FROM   PLANNING_ADMIN_V
 
UNION ALL 
 
SELECT Nom, Matricule, 'Commercial', NomSociete, 'Sans objet', 'Prospection', DateRDV, 'Sans objet', CompteRendu
FROM   PLANNING_CIAL_V
 
ORDER BY Matricule ;

Au résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
Nom       Matricule  Planning   NomSociete  NomProjet       Mission     DateDebut   DateFin       Notes
Bernard   002        Admin      Sans objet  Sans objet      RTT         2011-01-31  2011-02-18 
Bernard   002        Clientèle  Yadupour    Platon Phase 3  Conception  2011-03-07  2011-04-30 
Albert    007        Admin      Sans objet  Sans objet      Formation   2011-03-21  2011-03-24 
Albert    007        Admin      Sans objet  Sans objet      RTT         2011-02-21  2011-02-24 
Albert    007        Admin      Sans objet  Sans objet      Congés      2010-07-01  2010-07-31 
Albert    007        Clientèle  Yadupour    Platon Phase 3  Formation   2011-02-25  2011-03-03 
Alice     458        Commercial Morzy       Sans objet      Prospection 2011-01-05  Sans objet   Ça sera sportif

Commençons-nous à être en phase ? Si tel n'est pas le cas, merci de préciser plus finement votre problème.

[f-leb]

un peu tardivement (dommage qu'on n'ait pas le retour de betauser d'ailleurs étant donné le boulot) mais ceci dit:

Avec ACCESS représenter les deux rôles est possible, même si la façon de devoir procéder est plutôt débile (deux liens entre PROJET et COLLABORATEUR suffisant largement, cf. Power AMC, mais je n’ai que la version ACCESS 2003 et les choses ont-elles évolué avec les versions suivantes ? Pouvez-vous m’informer à ce sujet ?) :

Pas d'évolution là-dessus, même avec Access 2010

[fsmrel]

Merci valeureux Fabien,

Modéliser n’est manifestement pas une activité digne d’intérêt pour la firme de Redmond...

Amicalement,

François

[betauser]

Bonjour à Tous,

Avant tout, désolé pour mon retour tardif suite à vos commentaires. Merci beaucoup pour vos contributions, mais je n'ai pas eu de temps pour poster depuis plusieurs semaines...

Depuis la dernière fois, j'ai repris le modèle de Fsmrel ci-dessous, pour supprimer des relations ou des tables mal construites. J'ai aussi travaillé sur les interfaces (je continue encore à avoir du mal à distinguer la création des tables et leur utilisation dans des interfaces).

J'en suis donc à cette étape où les sociétés, les contacts, les projets peuvent être créés et interrogés. C'est déjà super d'en être là...

Concernant les plannings, j'arrive à créer la requête "union" expliquée par fsmrel pour visualiser les plannings.
Mais je tourne en rond pour créer un formulaire qui reprendrait le résultat de requête et qui permettrait également l'ajout de nouvelles dates sur une ligne en -dessous.

Cordialement,

Bonne réception.