Discussion :

[Papy Turbo]

Bon. C'est parti.

1er point : j'aime bien un tout petit topo sommaire de qui est l'utilisateur final (même si c'est toi ) ? donc :

Etant Responsable d'un Bureau d'études, il me faut le gérer administrativement

OK, mais études de mûrissement de bananes ou études de béton pour le génie civil ?
Je ne demanderai jamais de rien révéler qui soit confidentiel, mais juste assez pour parler d'entités claires (y a quoi dans une affaire, ou une étude ?). Ça peut beaucoup changer le paysage quand on rentrera dans les détails.
Et puis, une des parties les plus intéressantes du métier de développeur, c'est d'apprendre comment fonctionnent des dizaines de métiers différents, qu'il faut qu'on comprenne pour pouvoir les "traduire en langage machine".

1 - les affaires (commandes en études),

À ce stade, je tique sur le terme commandes. Si on parle de commandes, c'est à dire des affaires non encore signées, il va falloir parler de contrat, d'une date de signature à partir de laquelle la commande devient une affaire "signée", etc.
Si, par contre, on ne s'intéresse (c'est mon impression dans ce que je lis par ailleurs) qu'au suivi de la réalisation d'affaires déjà signées, faut oublier le terme commandes.
Désolé, je pinaille, mais dans une étude, faut parfois revoir chaque mot 10 à 20 fois avant de trouver le bon, et qu'il n'y ait aucune ambigüité.
En clair, on va parler de commandes ou pas ? Si oui, on verra ensuite les détails, mais seulement : attention à chaque mot.

1 - Toutes affaires a un client, par contre elles peuvent avoir des heures allouées pour différentes sections.

Ça, désolé, c'est clairement 2 choses tout à fait distinctes :
1 - Toute affaire a un client,
2 - Toute affaire peut avoir des heures allouées pour différentes sections.
Il y a clairement 2 relations. Au moins.
Donc, faut continuer, dans le désordre :
2 - Toute affaire peut avoir des heures allouées
3 - Toute affaire peut avoir ?/ a ? différentes sections.
4 - Toute section peut avoir ?/ a ? des heures allouées ?
etc.
ou autre chose de plus représentatif... ?

Ensuite, reprenons la 1ère proposition, parce que, rien que cette petite phrase là, si tu ne vas pas jusqu'au bout, va t'entraîner dans une structure berzerk :
1 - Toute affaire a un client, (ce qui implique : ni 0, ni plusieurs)
Si tu dis ça, ça se traduira en concret, dans la base, par :
- une table Affaires,
- dans cette table, un champ pour le nom du client, et peut être d'autres champs liés : un téléphone client, adresse, nom du contact, etc.
Ce que je veux dire :
Quand une Entité1 a 1 (et 1 seule) Entité2, ça se traduit généralement par un ou des champs Entité2 dans la table Entité1.
Oh la la ! Comment j'ai pu écrire une phrase pareille ? J'ai honte.
En français, LE client est un simple attribut de l'affaire, ce qui va se traduire concrètement par un ou des champs client dans la table affaire.

Et si, au hasard balthazar, j'inversais ta proposition :
- Est-ce qu'un client a une affaire, et une seule ?
On pourrait rêver qu'après avoir superbement réalisé une étude pour un client, ce même client vous reconfie une autre affaire, non ?
Et, si ça marchait, ce serait dommage d'avoir à recopier toutes les données "client" d'une affaire vers l'autre ?
Donc, quelle est la phrase qui représente le mieux la réalité ?

Les réponses pouvant être :
- 0 (zéro) <- réponse rarement intéressante
- 1, et un seul,
- soit 0, soit 1,
- de 0 à plusieurs,
- de 1 à plusieurs.

Tu as pris la 2ème, ou la 3ème, ou la 4ème réponse ?
- une affaire a un client, et un seul ?
- une affaire a de 0 à plusieurs clients ? Il peut y avoir des "affaires" internes, sans aucun client ?
- une affaire a de 1 à plusieurs clients ?
Et, si on s'amuse à inverser :
- un client a une affaire, et une seule ?
- un client a soit 0, soit 1 affaire ?
- un client a de 0 (prospect ?) à plusieurs affaires ?
- un client a de 1 à plusieurs affaires ?

------------------------

Certains trouvent que ton cas est le pire, d'autres que ton cas est idyllique :
- tu portes à la fois la casquette de l'utilisateur : tu vas te servir de ce logiciel, c'est ton métier,
- et celle de développeur !
Aujourd'hui, tu dois mettre la casquette de l'utilisateur (=client de ce logiciel), définir ton métier, puis, casquette développeur, le traduire en clair pour Jet (le moteur de bdd d'access).
Même le jour où tu donneras du boulot à un développeur externe, tu devras répondre précisément à ces questions là.
La bonne nouvelle est :
- les questions à se poser sont ultra simples,
- suffit de les pousser jusqu'au bout.
Exactement comme le plan comptable d'une société offre une représentation abstraite de son activité économique ("un plan comptable réussi, ç'est beau comme un poème", dixit my apple), les tables doivent représenter ton boulot, tout ce que tu veux mesurer, suivre, et, plus tard, analyser.

Donc, merci pour cette première ébauche.
Et, si tu veux bien, faut la reprendre en entier, avec plus de détails, c. à d. :
- une phrase sur le boulot,
- décomposer les entités et les relations, (une relation = sujet + verbe "avoir" + [quantité] + complément),
- inverser chaque proposition, pour rigoler,
- tester chaque combinaison, dans chaque sens : 0 ou 1 ou plusieurs... ?
- attendre au strict minimum une nuit entière, que ça décante,
- revoir le tout.

[Serge57]

- une phrase sur le boulot,

A part les bananes ... Nous sommes une entreprise de conception et d'installation en équipement éléctrique (au sens large du terme) du BTP.Installation de poste de transformation (tous niveaux de tension, France et étranger, equipement HT, BT et GC), installation chaines d'assemblage, usinage (automatismes, mécanique, GC).

- décomposer les entités et les relations, (une relation = sujet + verbe "avoir" + [quantité] + complément),

1 - Une affaire ou Commande (Pour le BE une commande est déjà signée) a un client et un seul.
2 - Un client peu avoir 1 à plusieurs affaires.
3 - Toute affaire a de 0 à plusieurs sections.
4 - Une section peut avoir des heures allouées.
5 - Une section peut avoir de 0 à plusieurs personnes(personnels entreprise).
6 - Une section peut avoir de 0 à plusieurs fournisseurs (sous-traitants).
7 - Une personne peut avoir de 1 à plusieurs sections.
8 - Un fournisseur peut avoir de 1 à plusieurs sections.
9 - Le Personnel pointe sur 0 à plusieurs affaires.
10- Le fournisseur point sur 0 à plusieurs affaires.

[Papy Turbo]

D'abord, OK pour le terme Commandes. Chacun de ces termes prend un sens différent d'une entreprise à l'autre, donc, c'est important de préciser.

Si je reprends tes propositions, il y en a encore quelques unes qui n'ont pas été systématiquement "inversées". Donc, on n'a pas complètement défini les relations.
Ce sera plus clair aussi de les garder ensemble.
La 1 et la 2 sont le miroir l'une de l'autre, donc, par exemple :
1 - Un client a de 1 à plusieurs affaires.
1bis - Une affaire a un client et un seul.

------------

Après, ça se complique :
2 - Une affaire a de 0 à plusieurs sections.

Dans cette phrase, je lis la notion d'une affaire subdivisée en plusieurs sections.
Ces sections là sont bien propres à une affaire.
Elles sont différentes des sections qu'on trouve dans ta table [SectionPerFou] : ces sections là sont les mêmes, quelle que soit l'affaire.
Donc, il va falloir désigner ces 2 types de sections par des termes différents.

Ça peut être "SectionType" et "SectionParAffaire", ou tout autre terme qui correspond mieux à ton métier.
À toi de choisir.


Bref, si tu veux bien reprendre cette brève liste encore une fois.

[Serge57]

Je ne vais pas chipoter , mais si j'ai mis les propositions 1 et 2 c'est pour bien montrer qu'un client a au moins une affaire.

Ces sections là sont bien propres à une affaire

NON Les sections utilisées dans affaires, personnels, et fournisseurs sont les mêmes. Elles sont issues de la table Section (affaire)Per(sonnel)Fou(rnisseur).

[quote =Serge57]4 - Une section peut avoir des heures allouées.
5 - Une section peut avoir de 0 à plusieurs personnes(personnels entreprise).
6 - Une section peut avoir de 0 à plusieurs fournisseurs (sous-traitants).[/quote]
Ce que je veut faire ressortir de 4, 5, 6 c'est même si une affaire n'a pas d'heure allouées en "Automatismes"(travaux n'ont prévu dans l'affaire de base), je peut avoir une personne "Automatisme" qui y passe des heures.

7 - Une personne peut avoir de 1 à plusieurs sections.
8 - Un fournisseur peut avoir de 1 à plusieurs sections.

une personne (ou fournisseur) peut travailler dans différentes sections sur la même affaire.

Je n'ai pas dit que c'est simple ......

Pourquoi la différence entre la table personnels et fournisseurs ?
Plus facile de trouver une personne ou un fournisseur,
Personnel ---> Nom, Prénom, matricule, ancienneté ......
Fournisseur --> Nom, siret, adresse, compétences ......

Attention, la base en exemple n'est que le haut de l'iceberg, lors de la mise en service de cette base d'autre demande seront formulés par les utilisateurs (moi et les autres)

[Papy Turbo]

Je ne vais pas chipoter , mais si j'ai mis les propositions 1 et 2 c'est pour bien montrer qu'un client a au moins une affaire.

Moi non plus, je ne tiens pas à chipoter, mais je vais le faire quand même.
Entièrement d'accord : il fallait préciser les deux pour avoir toutes les contraintes sous la main.
Je te proposais simplement de lier ensemble la 1. et la 2. en les renumérotant 1. et 1bis., parce que l'une est le pendant (l'inverse) de l'autre.
Tu as mis :
1- Relation Affaires -> Clients
2- Relation Clients -> Affaires
Donc, je te propose :
1- Relation Affaires -> Clients
1bis- Relation Clients -> Affaires
C'est tout.
Pour moi, c'est un poil plus clair.
Et, si tu reprends toute ta liste comme ça, tu t'apercevras qu'il manque encore un bon paquet d'inversions (il faut un "bis" à chaque relation), un peu partout.

En particulier, le noeud de notre problème : la, ou plutôt les relations Affaires <--> Sections
Tu as mis :
3 - Toute affaire a de 0 à plusieurs sections.
Où est la 3bis ? Une section a ... ?

À ce propos,

Papy Turbo a écrit :
Ces sections là sont bien propres à une affaire

NON Les sections utilisées dans affaires, personnels, et fournisseurs sont les mêmes. Elles sont issues de la table Section (affaire)Per(sonnel)Fou(rnisseur).

OUI : Les sections utilisées dans affaires, personnels, et fournisseurs sont les mêmes.
NON : Elles sont issues de la table Section (affaire)Per(sonnel)Fou(rnisseur).
Pour moi, elles (les sections de chaque affaire) sont liées aux sections de la table Section (affaire)Per(sonnel)Fou(rnisseur),
mais elles sont bien une entité différente.
Un schéma, même grossier, vaut mieux qu'un long discours.
Est-ce que ce que tu veux représenter correspond à peu près à ça :

sachant que :
- une affaire à de 0 à plusieurs sections
Quoique, j'ai des doutes sur une affaire qui aurait 0 section, parce qu'il n'y aurait ni heures allouées, ni heures du personnel, ni heures d'aucun fournisseur.
Je veux bien que chaque nombre d'heures puisse être zéro.
Mais, est-il possible qu'il n'y ait aucune heure, ni allouée ni réalisée par personne ?
- une section peut être liée à 0 (douteux : dans ce cas, pourquoi créer la section ?) à plusieurs affaires ?
Ce que je veux dire, c'est que je vois une différence fondamentale entre
- la section qui est une subdivision d'une affaire.
- la section qui fait partie de la liste des sections type, communes à toute les affaires.
Par exemple,
- la section Apprentis de Dugenou n'a rien à voir avec la section Apprentis de Dublanc. Chacune aura ses propres heures...
- la section Apprentis de la liste générale des sections n'a, par contre, aucune heure allouée ni passée particulière. Elle permettra, par contre, de faire un total de toutes les heures allouées ou passées de toutes les affaires. Mais c'est très différent.

Si tu continues à appeler toutes les sections par le même nom, tu vas devoir ajouter dans ta liste toutes les relations entre les affaires et les diverses heures. Elles n'y sont pas, pour l'instant.

Je ne veux pas encore détailler la relation entre une section (d'une affaire) et les diverses heures/personnel/fournisseurs.

Je cherche juste à mettre un nom sur les rectangles bleu foncés à fond bleu moyen, qu'on va trouver dans chaque affaire, dont les titres (libellé de la section) viendront de la liste générale des sections.

J'ai l'impression que tu restes sur l'idée que, je cite de mémoire "les heures allouées sont optionnelles... ", donc "il peut y avoir des heures travaillées sans heures allouées...", donc, j'extrapole "il faut que les heures travaillées soient indépendantes des heures allouées", etc.
OK, d'accord. Mais c'est trop tôt. La question importante, aujourd'hui, c'est
- à qui va tu attribuer toutes ces heures, quelles qu'elles soient ?
- à la section de la liste jaune ?
ou bien
- à une section (bleue) d'une affaire ?

Je n'ai pas dit que c'est simple ......

Moi non plus
Y a rien de plus compliqué que le bon sens, quand on rentre dans le détail...

[Serge57]

J'ai l'impression que tu restes sur l'idée que, je cite de mémoire "les heures allouées sont optionnelles... ", donc "il peut y avoir des heures travaillées sans heures allouées...", donc, j'extrapole "il faut que les heures travaillées soient indépendantes des heures allouées", etc.
.

C’est ce que je veux avoir.

OK, d'accord. Mais c'est trop tôt. La question importante, aujourd'hui, c'est
- à qui va tu attribuer toutes ces heures, quelles qu'elles soient ?
- à la section de la liste jaune ?
ou bien
- à une section (bleue) d'une affaire ?

Les tables affaire, personnel et fournisseur existent => les heures travaillées personnel et fournisseur existent.
Pour l’exercice, on peut rependre toute la philosophie de la base, mais il faudra m’expliquer comment faire pour récupérer les anciens enregistrements.
L’évolution de l'application est la notion de SECTION. Donc, ton graphique ne correspond pas tout à fait à ce que je veux faire.

Le centre du PB c’est les affaires, mais je ne connaîtrais toutes les sections de cette affaire que l’affaire terminée. (pas clair hein !!).

Au début, une affaire a de 0 à n sections, c’est sûr que dès qu’une personne travaille sur cette affaire, l’affaire aura la section de l’affaire (mais pas obligatoirement au début). J’ai peut-être une mauvaise approche du Problème ?? Mais ce qui est sûr lors de la création d’une affaire, je ne sais pas toujours les données (heures allouées, section) de qui fait quoi (fournisseur, personnel). C’’est lourd hein !!!

- la section Apprentis de Dugenou n'a rien à voir avec la section Apprentis de Dublanc. Chacune aura ses propres heures...
- la section Apprentis de la liste générale des sections n'a, par contre, aucune heure allouée ni passée particulière. Elle permettra, par

ceci => qu’il faut 2 tables section différentes ou NON ???. Je ne comprends pas tout. C’est vrai qu’au message #20 je n’ai pas donné les relations mais j’ai listé la demande. Actuellement, tu es en train de m’écrire que je dois prévoir toutes les sections dans les toutes les affaires au cas ou j’en aurais besoins ??.

[Papy Turbo]

Les tables affaire, personnel et fournisseur existent => les heures travaillées personnel et fournisseur existent.
Pour l’exercice, on peut rependre toute la philosophie de la base, mais il faudra m’expliquer comment faire pour récupérer les anciens enregistrements.

Je l'ai dit, je le précise :
Le but de cet exercice est de :
- répondre à ta question initiale : comment réaliser cette requête ?
- la réponse : il faut analyser la structure de "ce que tu veux faire" et
1- la traduire en une base de données (tables, relations, indexes uniques ou avec doublons, champs nuls acceptés ou pas et tous autres attributs des DONNÉES qui définissent la base de manière claire et proche de la réalité),
Commentaire : pendant cet exercice, oublies la base existante et les gens, y compris toi, qui s'en servent tous les jours. Cherche à définir ce que tu aurais pu faire, qui serait plus facile à utiliser ensuite.
2- une fois que tu auras cette base de données claire,
tu vas commencer par refaire la requête qui posait problème. Et choisir :
- soit tu gardes la base de données existante, elle te va mieux.
- soit tu veux travailler avec la nouvelle, plus simple, ou plus rapide, ...
Et, dans le 2ème cas seulement, tu te poseras les autres questions, qu'on n'a pas encore abordées :
++ Quand est-ce que j'ajoute une section à une affaire ? au moment de la création de l'affaire ? au moment ou quelqu'un travaille dessus ? au moment ou je (le responsable) lui alloue des heures ?
++ Comment je traduis ça dans la structure des formulaires / sous-formulaires / etc. Je mets des onglets ? J'automatise le processus ? ou J'ajoute un bouton ?...
Bref, on rentre dans la structure de l'application. Phase 2.
3- Je suis bien d'accord : Si tu en arrives là, tu vas te retrouver comme un c.. (comme disait Jacques Brel), avec
- d'un côté, une application qui tourne, un peu bancale, peut être, mais pleine de données précieuses : affaires réelles, heures allouées, travaillées, etc.
- de l'autre, une superbe base nickel (j'en rajoute un peu, mais c'est mon côté marketing), avec 3 affaires "Titi-Toto-Tata" dedans.
On verra. Ça, c'est un problème que tout le monde, et toi aussi, va falloir poser la question un jour ou l'autre :
- la base a évolué,
- l'application aussi, en général, pour traiter les données différemment, ou pour traiter les nouvelles tables et nouvelles données,
Faut récupérer les anciennes données en les passant au nouveau format.
C'est un de mes sujets fétiches. C'est une des bases de toute synchronisation entre 2 bases de données, qu'elles soient similaires (trop fastoche) ou différentes (plus drôle), donc, ça va très loin.
Si on en arrive là, ce sera un autre cours, séparé. Phase 3.
Tu comprends ce que je veux dire par : "c'est beaucoup trop tôt." ?
D'abord, la base.

L’évolution de l'application est la notion de SECTION. Donc, ton graphique ne correspond pas tout à fait à ce que je veux faire.

Mon graphique ne te convient pas ? Tu ne peux pas savoir comme tu me fais plaisir
Fais en un qui te convienne, en mettant des patatoïdes les uns dans les autres, ou ce que tu veux.
Feuille de papier que tu scanneras, tableau Excel où tu dessines ce que tu veux, moi, j'ai pris Paint...
J'attends ton croquis.
On va finir par se réinventer les schémas UML, et Merise...
De toute façon, c'est pas plus compliqué que ça, l'UML, ou le Merise, ou ...

Le centre du PB c’est les affaires, mais je ne connaîtrais toutes les sections de cette affaire que l’affaire terminée.

Au début, une affaire a de 0 à n sections, c’est sûr que dès qu’une personne travaille sur cette affaire, l’affaire aura la section de l’affaire (mais pas obligatoirement au début). Mais ce qui est sûr lors de la création d’une affaire, je ne sais pas toujours les données (heures allouées, section) de qui fait quoi (fournisseur, personnel).

J'ai supprimé les commentaires ("pas clair", etc.). Notre boulot est de clarifier tout cela, donc tout va bien.
Ce que je vois là dessus, et dans les messages précédents, c'est en vrac, ce que j'entends à chaque démarrage d'une nouvelle affaire, de la bouche du client, celui qui sait faire son métier, mais qui compte sur un informaticien pour le traduire en tables, données, application...
À toi de réécrire tout ça comme je te le conseille, pour y voir clair.

ceci => qu’il faut 2 tables section différentes ou NON ???. Je ne comprends pas tout. C’est vrai qu’au message #20 je n’ai pas donné les relations mais j’ai listé la demande. Actuellement, tu es en train de m’écrire que je dois prévoir toutes les sections dans les toutes les affaires au cas ou j’en aurais besoin ??.

Voir + haut, c'est trop tôt. Je ne réponds pas. C'est toi qui le dira.
Aujourd'hui, on prend la photo des données. Y a pas de notion "temps".
La seule question : qu'est-ce qu'on stocke dans les données ?, quel que soit le moment.
Si tu préfères :
- Y aura-t'il, à un moment quelconque, une affaire sans aucune section ? Oui. Donc : Une affaire peut avoir 0 sections.
- Peut-il y avoir, à un moment quelconque, une affaire avec une seule section ? Oui. Donc, Une affaire peut aussi avoir 1 section.
- Peut-il y avoir, à un moment quelconque, une affaire avec plusieurs sections ? Ben, évidemment, crétin. C'est ce qu'on dit depuis le début. D'accord. Donc, Une affaire peut aussi avoir plusieurs sections.
etc.
Jusqu'au bout de toutes les relations entre :
- clients,
- affaires,
- sections,
- heures allouées,
- heures passées,
- personnel,
- etc.
Voilà, c'est tout.

Fais un schéma. Avec les clients, tout ce que tu veux.
Ou une liste, si tu préfères (tableau dans Excel ?). Ou les 2.
Tu as déjà, en vrac, les données de ton client.
Tu dois mettre la casquette de l'analyste-programmeur, et poser tout ça à plat.

[Serge57]

Mon graphique ne te convient pas ? Tu ne peux pas savoir comme tu me fais plaisir

Je penses avoir tout expliqué dans la réponse #22.
Sauf ....
Si une personne 'Baumec' fait parti d'une section 'Automatimes'.
cette section 'Automtismes' fait parti d'une affaire 'Bèlréussit'. Est ce que 'Baumec' fait-t-il obligatoirement parti de 'Bèlréussit' ??? .

Faut-il avoir les relations
1 - 'Baumec' --> 'Automatismes'
2 - 'Automatismes' --> 'Bèlréusit'
3 - 'Baumec' --> 'Bèlréussit'

ou

les relations 1 et 2 suffisent. (3 en découle).

Dans ton graphismes, je comprend pas pourquoi les heures personnel, heures fournisseurs, heures allouées ne sont pas des entités différentes comme les entités affaire et sections.?

[Papy Turbo]

Je penses avoir tout expliqué dans la réponse #22.

Reprenons le début de ta liste, de la réponse #22, dont j'ai déjà dit qu'elle n'était encore ni complète, ni suffisamment précise :
1 - Une affaire a un client et un seul.
2 - Un client peu avoir 1 à plusieurs affaires.
OK. Sauf que ce sont les 2 faces d'une même médaille : relation Clients <-> Affaires

3 - Toute affaire a de 0 à plusieurs sections.
OK. Manque juste le verso : 3 bis - Une section participe à 0 ou plusieurs affaires

4 - Une section peut avoir des heures allouées.
Faux. Parce que trop imprécis.
Je ne t'ai jamais entendu dire que tu (responsable de projet) allais allouer des heures à la section 'Automatismes'.
Par contre, tu parles d'allouer des heures à la section 'Automatismes' de l'affaire 'Dugenou'. Ou toute autre section d'une autre affaire.

Autrement dit :
- <Automatismes> est une section.
- <Automatismes de l'affaire Dugenou> est une ? "section d'une affaire" ?
Comment veux-tu l'appeler ?, précisément pour ne pas la confondre avec la section générale 'Automatismes' qui, elle, n'est pas propre à une affaire.

Autrement encore :
Quand tu vas décrire une affaire, ou la représenter dans un état, tu vas vouloir, dans tes données, trouver/afficher la liste des sections qui concernent cette affaire. Et, pour chaque section de l'affaire, indiquer les heures...
Cette liste, qui concerne chaque affaire, est différente de la liste générale des sections, non ?

Il y a bien là une entité qui n'apparaît pas dans ta liste du #22.

Dans ton graphismes, je comprend pas pourquoi les heures personnel, heures fournisseurs, heures allouées ne sont pas des entités différentes comme les entités affaire et sections.?

Ce sont des entités différentes. Je me pose simplement la question :
- où (à quelle entité) vais-je attribuer ces heures ? (sans rentrer dans le détail de qui réalise les heures travaillées, on verra plus tard)
- à une affaire ? NON. Il faut désigner la section.
- à une section ? NON PLUS. J'ai aussi besoin d'indiquer quelle affaire est concernée.
Alors,
- à une section d'une affaire ? Pour moi, OUI. C'est là que je vais attribuer ces heures. À l'intersection entre une affaire et une section, cette intersection étant elle-même une nouvelle entité.

[Serge57]

ci-joint mon graphisme (chargée) mais qui je crois explique bien ce que veux obtenir. (schéma1.jpg) .
Ce n’est pas des relations au sens BDB, mais des directions d’où la donnée est issue.

Je reprend toute ma liste de relation sans tenir compte de ce qui existe.

Donc reprenons :
1- Une affaire a un client et un seul.
1b-Un client peu avoir 1 à plusieurs affaires.
2- Une affaire a de 0 à plusieurs sections (entité SectionAff).
2b- Une section peu avoir de 0 à plusieurs affaires.
3- Une entité SectionAff peu avoir des heures allouées.
4- Une section peu avoir de 0 à plusieurs personnels « entreprise » (entité SectionPer) .
4b- Un personnel « entreprise » peut avoir de 1 à plusieurs sections.
5- Une entité SectionPer peut passer des heures sur 1 ou plusieurs Affaires et non pas sur SectionAff puisqu’une affaire peut ne pas avoir de section de la l’ambiguïté.
6- Une section peu avoir de 0 à plusieurs Fournisseurs (entité SectionFou) .
6b- Un fournisseur peut avoir de 1 à plusieurs sections.
6- Une entité SectionFou peut passer des heures sur 1 ou plusieurs Affaires (idem 5).
(j’avance ???)

Voici la liste des résultats voulue (pour l’instant)
- La somme des heures passées (5 et 6) par affaire et par section.
- La différence entre heures allouées (si n’existe pas = 0) et heures passées.

Nota : je ne sais pas insérer une image dans le message donc je l'ai jointe.

[Papy Turbo]

Oui, on avance, pas à pas
Je me suis permis de reprendre ton schéma, sous Excel (rien de meilleur pour les croquis d'analyse ), en réalignant toutes les entités de gauche à droite.
1- c'est plus lisible que les diagrammes en "toile d'araignée", dans tous les sens,
2- notre culture nous entraîne à lire de gauche à droite, pour le texte, mais aussi pour les schémas hiérarchiques (Voir les arbres, ou 'TreeViews', qui, chez nous, s'ouvrent toujours de gauche à droite...)
3- ça va être très utile, mais plus tard

P.S. : pour insérer une image, il faut :
- copier cette image sur un site quelconque,
- cliquer sur le bouton Image (avant-avant-dernier, sur la 2ème ligne de boutons, au dessus de l'éditeur de texte),
- indiquer l'URL.

Je reprend toute ma liste de relation sans tenir compte de ce qui existe.

J'ai quelques doutes sur la 2ème partie de la phrase, parce qu'il n'y a rien de plus difficile que de faire abstraction de l'existant.
Ne t'inquiète pas, c'est normal, on est tous comme ça. Ceci dit, je ne m'appelle pas Sigmund et on n'est pas là pour analyser ce genre de phénomène. Mais il est indispensable d'en être conscient.

Donc reprenons :
1- Une affaire a un client et un seul.
1b-Un client peu avoir 1 à plusieurs affaires.

Jusque là, tout va bien, rien à redire.
C'est ce qu'on appelle une relation de UN Client à PLUSIEURS Affaires.
Tu as déjà ça dans la base existante, où ça se traduit par :
- une table Clients avec un champ [CléClient], la clé primaire,
- une table Affaires avec un champ [CléAffaire], la clé primaire, et un champ [CléClient], soit une clé étrangère,
- une relation entre les 2 tables, basée sur les 2 [Clé Client].
Il ne te manque que de transformer ta relation en une relation d'intégrité référentielle, ce qu'on fera après.

Si quoi que ce soit n'est pas clair là dedans, pour toi ou pour un des lecteurs débutants, c'est le moment de poser des questions.

2- Une affaire a de 0 à plusieurs sections (entité SectionAff).
2b- Une section peu avoir de 0 à plusieurs affaires.

D'abord, faut décider (le flou n'est pas permis) : soit, tu parles de Sections, soit de SectionAffaires, mais ne pas confondre les 2.
Je répète : elles sont distinctes.
Donc :

2- Une affaire a de 0 à plusieurs sections.
2b- Une section peu avoir de 0 à plusieurs affaires.

C'est là que tu vas comprendre à quel point je peux être vicieux.
Maintenant que tu as introduit dans ton schéma une nouvelle entité SectionAff (que, j'espère, tu me permettras de nommer SectionAffaire, parce que je suis allergique aux trigrammes qui rendent très vite l'analyse illisible. Si on se met à parler de CLIAFF, de SECFOU ou de AFFPER..., je hurle),
maintenant, donc, il n'y a plus aucune flèche (donc plus aucune relation directe) entre Affaires et Sections !
Si je relis ton diagramme, je vois :
2- Une affaire a de 0 à plusieurs SectionAffaires.
2b- Une SectionAffaire peut avoir une et une seule affaire.
3- Une section a de 0 à plusieurs SectionAffaires.
3b- Une SectionAffaire peut avoir une et une seule section.
C'est à dire, 2 relations UN à PLUSIEURS (du même type que la première ci-dessus entre Clients et Affaires).

Si je reprends ta 1ère déclaration (qui est juste) :

2- Une affaire a de 0 à plusieurs sections.
2b- Une section peu avoir de 0 à plusieurs affaires.

en termes de base de données, relation de PLUSIEURS Affaires à PLUSIEURS Sections.
Pour relier plusieurs affaires à plusieurs sections, solution classique : il faut ajouter une 3ème table, dans laquelle tu mettras, au strict minimum :
- une [CléAffaire] = clé étrangère,
- une relation entre la table Affaires et celle-là, basée sur les champs [CléAffaire],
- une [CléSection] = clé étrangère,
- une relation entre la table Sections et celle-là, basée sur les champs [CléSection].
- en option, mais bien pratique : une clé primaire.

Cette table est le moyen le plus simple de découper tes affaires en plusieurs sections, différentes d'une affaire à l'autre, permettant d'avoir de "0 sections par affaire" à "toutes les sections dans une affaire", comme tu veux et quand tu veux...

Ce qui veut dire que les 2 représentations, une seule relation de PLUSIEURS à PLUSIEURS, ou bien : 2 relations simples de UN à PLUSIEURS, sont équivalentes.
Mais la seconde méthode a l'avantage de nommer l'intersection Affaires <-> Sections, parce que ces SectionAffaires correspondent à une réalité (le découpage d'une affaire en plusieurs sections).
Cette entité va être utile, et pas seulement pour les heures allouées, mais pour tout ce qui touche à (Une affaire+une section).
De plus, nous avons scindé une relation PLUSIEURS à PLUSIEURS (complexe) en 2 relations simples, ce qui est encore un petit plus.

Qu'est-ce qu'il reste à faire, avant de concrétiser tout cela en tables/champs/relations ?
- reprendre la liste, comme j'ai commencé à le faire,
- reprendre le schéma et la liste, pour voir où tu peux simplifier ?
L'idée étant : du moment que tu veux relier "quelque chose" à la fois à une affaire et à une section, est-ce qu'il n'est pas possible d'utiliser la nouvelle SectionAffaire ?
Hint : tu es sûr d'avoir besoin de SectionPer et de SectionFou ?
Tu es sûr que de recréer à chaque fois la relation entre Affaires et Sections et Heures allouées, puis entre Affaires et Sections et Heures passées - Personel, puis entre Affaires et Sections et Heures passées - Fournisseur, ça ne peut pas se simplifier ?

[Serge57]

ci-joint mon graphisme en tenant compte de tes réflexions.
La simplification est grande. Il ne reste plus beaucoup d’entité (tables).
Le seule problème (si problème), je ne vois pas comment je pourrais articuler la saisie de la section pour une personne ou fournisseur sans avoir créé l’entité SectionAffaire. Le nombre d’entité a été simplifier mais la mise en forme du formulaire ???. (Bien sûr avec mes connaissances dans le maniement d’Access).

P.S. : pour insérer une image, il faut :
- copier cette image sur un site quelconque,
- cliquer sur le bouton Image (avant-avant-dernier, sur la 2ème ligne de boutons, au dessus de l'éditeur de texte),
- indiquer l'URL.

en cours d'essai.Mais pas réussi On verra ça plus tard. Il ne me reste plus beaucoup de place pour Uploader des fichiers. Voir ce que tu peux faire MERCI (c'est hors sujet, mais j'aimerai parvenir à la fin de " notre cours ".

[Papy Turbo]

Bon, ben, on y est.
J'espère que c'est déjà évident pour toi, à partir d'un schéma comme celui là, de concevoir une requête finale simple, pour récapituler toutes les heures, pour chaque section de chaque affaire ?
De toute façon, on ne va pas tarder à la mettre en oeuvre.
Il reste maintenant à :

- faire une copie de la base de tests, pour pouvoir comparer ensuite,

- les tables existent déjà, mais il va falloir les modifier un peu pour refléter les relations du schéma, (clés étrangères...)

- mettre de l'intégrité dans ces relations, pour être sûr qu'aucune affaire ne puisse se retrouver sans son client...

- bien entendu, tu laisses de côté les calculs (somme/différence des heures), qui ne nécessitent aucune table particulière, mais seront juste 2 champs calculés. Ceci dit, c'était parfait de l'inclure dans ton analyse, pour avoir une vision du but à atteindre.

- dans les exemples précédents (exemple en réponse #15), je n'ai utilisé que les tables :
++ AvancementEtudePersonnel, qui correspond à "Heures passées/SectionsAffaires/Personnels", dans le schéma
++ AvancementEtudeFournisseur, qui correspond à "Heures passées/SectionsAffaires/Fournisseurs"
Ce qui veut dire que j'ai ignoré les tables HeurePersonnelAffaire et HeureFournisseurAffaire, qui n'apparaissaient pas dans tes relations.
Ces tables faisaient double emploi, ou tu as besoin des deux ? (auquel cas, il serait temps que tu précises exactement les liaisons entre Personnels ou Fournisseurs et les HeuresPassées/SectionAffaire).

- enfin, on va, au moment de transformer les tables "Avancement...", devoir récupérer les clés des nouvelles SectionsAffaires : quelques requêtes qui préfigurent déjà ce qu'on va faire pour transférer les données depuis la base "de production" (celle dont tu te sers, disons la "version 1.0") dans la nouvelle base, "version 2.0".

Le seule problème (si problème), je ne vois pas comment je pourrais articuler la saisie de la section pour une personne ou fournisseur sans avoir créé l’entité SectionAffaire.

C'est bien ce que je voulais dire par "dur dur d'oublier l'existant".
1- Je l'ai dit, je le répéterai autant de fois qu'il faut : la structure de la base représente juste l'image de ce qu'on stocke. On ne se préoccupe pas ici de quand on stocke (à quel moment on ajoute tel ou tel enregistrement) : ça, c'est un problème à résoudre dans l'application.
2- Bien sûr, il faut créer une SectionAffaire dès que tu as besoin
- soit de mettre des heures allouées,
- soit des heures passées par le Personnel,
- soit des heures passées par un fournisseur.
C'est ce que tu as dit au cours de l'étude, donc c'est ce que ton ou tes formulaires/sous-formulaires devront refléter.
Et ce n'est pas compliqué.
Et rien n'empêche d'avoir une SectionAffaire sans heures allouées, mais avec des heures passées (ce qui te tracasse toujours).

Pour aller un poil + vite, je vais reprendre directement la liste des relations, d'après le schéma :
1- Une affaire a un client et un seul.
1b-Un client peut avoir 1 à plusieurs affaires.
Relation de UN Client à PLUSIEURS Affaires

2- Une affaire a de 0 à plusieurs SectionAffaires.
2b- Une SectionAffaire peut avoir une et une seule affaire.
Relation de UNE Affaire à PLUSIEURS SectionAffaires

3- Une section a de 0 à plusieurs SectionAffaires.
3b- Une SectionAffaire peut avoir une et une seule section.
Relation de UNE Section à PLUSIEURS SectionAffaires

4- Une SectionAffaire a de 0 à 1 (Nombre d')HeuresAllouées. (Attention au piège : ce ne sont pas des heures allouées par SectionAffaire, mais un seul nombre d'...)
4b- Un (Nombre d')HeuresAllouées appartient à 1 seule SectionAffaires.
Relation de UNE SectionAffaire à UN NbHeuresAllouées.
Remarque : Ne pas hésiter, non seulement pour le nommage des entités, des tables ou des champs, mais aussi pour nommer les variables dans le code, etc. à ajouter des préfixes tels que :
- "nb" (ou "nombre"), quand on stocke "le nombre de...",
- "no", avec la lettre "o", ne jamais mettre "n°" -> risque de plantage !, (ou "numero", ou l'équivalent english : "id" pour "identifier"), quand on stocke un n° d'identification unique (souvent une clé),
- "Compteur" (ou "cpt" ou "count"...), quand on calcule le nombre de...,
- "Pointeur" (ou "ptr"), quand on boucle sur chaque élément, un par un,
- etc.
pour éviter tout risque d'erreur de ce type.
Plus on est précis, moins on se plante.

5- Une SectionAffaire a 0 ou plusieurs (Nombre d')HeuresPasséesPersonnel. (Là, il y a bien un nombre d'heures passées pour chaque membre du personnel).
5b- Chaque (Nombre d')HeuresPasséesPersonnel appartient à 1 seule SectionAffaires.
Relation de UNE SectionAffaire à PLUSIEURS NbHeuresPasséesPersonnel.
Encore une petite remarque de pinailleur : Le terme "Personnel" me gêne. On ne dit pas couramment "un personnel", mais, "une personne", ou "un membre du personnel", ou "un employé"...
C'est peu de chose, mais ça ne coûte pas bien cher de choisir un nom de table qui corresponde aussi à un nom d'enregistrement, et ça facilitera toute communication :
- La table "Personnel" contient un "Membre du personnel" par enregistrement.
Je préfère :
- La table "Employés" contient un "Employé" par enregistrement.
Ou équivalent, à toi de voir.

6- Une SectionAffaire a 0 ou plusieurs (Nombre d')HeuresPasséesFournisseur. (Là, il y a bien un nombre d'heures passées pour chaque fournisseur).
5b- Chaque (Nombre d')HeuresPasséesFournisseur appartient à 1 seule SectionAffaires.
Relation de UNE SectionAffaire à PLUSIEURS NbHeuresPasséesFournisseur.

Et c'est tout, puisque le reste ne sera pas stocké dans la base, mais calculé.

[Serge57]

Avec un peu de retard.. (soleil, réflexions…) base en zip des tables et relations que je penses mettre en service suivant tes conseils.

J’ai rajouter 2 tables ( Employe-SectionAffaire, et Fournisseur-SectionAffaire) qui me serviront lors de la création d’une nouvelle affaire (s’il n’existe pas d’heures allouées, ni passées) de me permettre de stocker un estimatif du nombre heures pouvant être passées par un (ou des) employés dans différentes sections de l'affaire. Lors de la saisie réelles des 'Heures passées' pour chaque employé sur une affaire, j'utilise la table 'Employe-SectionAffaire' comme filtre au lieu de toutes la table employé.(moins de choix daonc saisie plus rapide). Idem pour les fournisseurs.

Maintenant, il me reste à réfléchir comment mettre en forme le formulaire de création d’une affaire dont voici une image de l’organisation de l’ancien. Puis à la requête pour faire le récapitulatif des heures travaillées par rapport des heures allouées sur chaque affaire en fonction des différentes sections.


---------------------
Fichiers attachés : SuiviAffaire 2006-07-05-2.zip (25,9 ko)
---------------------

[Papy Turbo]

Tout d'abord, bien sûr, ça m'embête un peu que tu rajoutes de nouvelles données/tables maintenant. Ça complique et ça nous ralentit...
En même temps, j'apprécie particulièrement, parce que c'est une démarche tellement courante avec Access : on améliore régulièrement, et on n'hésite pas à reprendre un modèle pour l'améliorer.
Il faut que l'outil fasse exactement ce dont l'utilisateur a besoin, sinon, il ne servira pas à grand chose...
En même temps, tu es manifestement conscient des impératifs de production et de mise en oeuvre : si tu passes ton temps à améliorer, tu n'arriveras jamais à mettre l'application en route, ou, simplement, ce sera trop tard = trop cher, en termes de développement, c'est à dire, en nombre d'heures de développeur.
Donc, il faut aussi finir et produire une application qui marche.

La solution consiste à découper l'évolution de l'application en plusieurs phases : il n'y a que toi qui puisse décider si une amélioration doit impérativement être incorporée immédiatement, ou si elle peut attendre la prochaine version/la prochaine livraison. Un logiciel n'est jamais parfait, il y aura toujours une nouvelle version à ton "SuiviAffaires".

J'utilise pour cela 2 listes, intitulées respectivement V+ et V++ :
- V+ : contient tout ce qui est à faire impérativement, dans la version/livraison en cours (ToDo list). Sert surtout à garder la trace de toutes les tâches que tu dois encore faire pour terminer et mettre cette version en marche,
- V++ : contient tout ce qui peut attendre la prochaine version/livraison, parce qu'on n'a pas le temps de les incorporer maintenant, mais surtout, parce qu'on peut faire "quelque chose qui marche" et le livrer, puis faire ça ensuite. Lors d'une livraison, cette liste V++ est donnée aux utilisateurs, pour qu'ils décident, affinent leurs besoins, mettrent des priorités, qu'ils voient une estimation détaillée (temps/coût), et prennent les décisions concernant la prochaine version ou la prochaine livraison...

Où mettre ces listes et ces notes :
- Access ne dispose pas, comme Visual Studio, FrontPage et d'autres outils, d'un gestionnaire de tâches ("ToDo list"). J'utilise une base Access spécialisée, qui enregistre les temps de développement et permet de noter tout cela, mais tu peux utiliser Outlook, qui ne coûtera rien puisque tu as déjà Office.
- tu peux noter ponctuellement des V+ et des V++ dans le code VBA. Un commentaire, commençant par V+ (ou "ToDo", ou "A faire"...) ou V++ : avant de livrer l'application, une recherche globale va les trouver tous, et tu vas pouvoir
--- vérifier que les V+ sont terminés, sinon, le faire.
--- réunir tous les V++ dans la liste à distribuer aux utilisateurs : même toi, tu pourras avec cette liste, y voir plus clair, en parler avec d'autres...
- le coup du V+ et V++ est très souple : tu fais passer un commentaire d'un niveau à l'autre en ajoutant/supprimant un "+". Tu peux mettre plusieurs niveaux : V+++ (ne pas abuser, ça deviendrait confus).

Pour la liste V++, un document Word en mode plan (avec des Titre1 à Titre9 pour structurer le document par sections...) est très souple et évolutif.

Pour aller + loin, faire des recherches sur les méthodes agiles et notamment, sur le développement itératif (en clair, itérations : déploiement de l'application en plusieurs livraisons, chacune donnant "quelque chose qui marche").
Voir le forum Conception et ses sous-forums, FAQs et articles...
----------------- fin d'aparté sur l'évolution du développement -------
Revenons à nos moutons :

Il reste juste un point : es tu toujours d'accord qu'il n'y a qu'un seul NbHeuresAllouees par SectionAffaire ?
Si c'est le cas, voir réponse #33, c'est une Relation de UNE SectionAffaire à UN NbHeuresAllouées.
On a beaucoup parlé (réponse #31) de relations UN à PLUSIEURS et PLUSIEURS à PLUSIEURS (qui peut se décomposer en 2 relations de UN à PLUSIEURS).
Une relation de UN à UN est encore plus simple, puisqu'elle se traduit, dans la quasi totalité des cas, par un champ dans la même table.

Il peut y avoir des cas de relations de UN à UN entre 2 tables.
Bien évidemment, une table qui aurait plus de 250 champs et doit être scindée en deux. Mais c'est rare, et souvent, une bonne analyse peut réduire considérablement ce nombre de champs ! (pas toujours).
Sinon, le seul exemple auquel je puisse penser, dans les diverses applications sur lesquelles j'ai travaillé depuis + de 20 ans, est le suivant :
- plusieurs (et ce "plusieurs" est très important) applications distinctes, pour un seul client ou pour des clients différents, utilisent le même carnet de contacts.
- ce carnet contient un ensemble de tables + des formulaires et du code (c'est une application à lui tout seul). Il est réutilisable. On va y stocker tous les gens, avec les sociétés où ils travaillent, quels que soient leurs rôles dans l'application. On a donc (il y a d'autres solutions, mais celle-ci est un choix) une table principale Contacts qui contient toutes sociétés et personnes, avec hiérarchie entre groupes/sociétés/branches/agences... et employés à tous les niveaux...
- dans chaque application, on a des rôles, ou "types de contacts", différents :
+++ toujours : les employés de la société qui utilise le logiciel, parmi lesquels on trouvera les utilisateurs de l'application, mais pas seulement...
+++ application 1 : des Clients (avec relevé bancaire R.I.B...) + des Fournisseurs (avec conditions de vente + transport + livraison...) + des intermédiaires commerciaux (avec commissions...), etc.
+++ application 2 (contrats d'assurance, par exemple) : des Clients (avec type de contrat...) + des assureurs + des courtiers + ...
+++ autant d'autres applications qu'on veut, chacune avec ses contacts et ses rôles...
Dans ce cas,
- chaque base de données incorpore les tables de Contacts "universelles",
- chaque base a une table par rôle, ou par type de contact : une table Clients (avec relevé bancaire RIB pour l'un, type de contrat pour l'autre...), une table Fournisseurs pour Application 1, une table Assureurs pour l'application 2, etc.
Les relations entre ces tables sont UN contact pour UN (Rôle).

Ça permet :
- de stocker dans le "carnet de Contacts" tous les noms, tous les n°s de téléphone, toutes les adresses (adresse de livraison, de facturation, etc.). Très pratique pour les recherches...
- chaque contact trouve ses données supplémentaires, spécifiques à l'application, dans une des tables spécifiques, dédiées à chaque rôle.
- le formulaire de base du carnet peut être personnalisé pour que des onglets spécifiques affichent les données spécifiques (RIB du client...), en fonction du rôle de chacun. Les onglets sont affichés/masqués en fonction du rôle de chaque individu ou société.
C'est très souple, mais tu vois bien que ce cas est rare (la liaison UN à UN est rare, pas l'utilisation d'un carnet d'adresses...).

Ici, ce n'est pas le cas, donc je pense que le NbHeuresAllouées a sa place, directement dans la table SectionAffaires.
Les Observations correspondantes aussi bien sûr (un champ Observations par NbHeuresAllouées, donc par SectionAffaire).

Tu n'avais probablement pas tiqué, au départ, dans la réponse #15, sur la présentation d'une table [SectionsParAffaires], suivie de la mention

D'autres simplifications apparaîtront certainement : tu pourrais très bien utiliser la table HeuresAllouées comme jointure entre les Affaires et les Sections (à la place de [SectionsParAffaires]).

Il vaut mieux qu'elle s'appelle SectionsAffaires, parce qu'elle joue ce rôle pivot entre les affaires et les sections. Mais, c'est le bon endroit pour stocker tous les champs qui concernent une section d'une affaire, dont les heures allouées.
J'espère que tu ne vas pas hurler en disant : "je veux pouvoir mettre des heures passées sans heures allouées..."
- Tant que tu ne mets rien dans ce champ, il est null -> il n'y a pas d'heures allouées.
- à tout moment, tu peux mettre des heures allouées, avant ou après avoir ajouté des heures passées, ou jamais.
On va voir cela dans la mise au point du formulaire de saisie, (qui contient nettement plus de données maintenant), juste après avoir refait la requête de départ.

Dernier conseil : c'est plus intuitif si les noms de table sont au pluriel.
- la table Affaires contient une Affaire par enregitrement,
- la table Sections contient une Section par enregistrement,
- etc.
Rappelle toi le conseil : trouver des termes, comme Employés/Employé, qui fonctionnent aussi bien au singulier et au pluriel.

[Serge57]

Tout d'abord, bien sûr, ça m'embête un peu que tu rajoutes de nouvelles données/tables maintenant. Ça complique et ça nous ralentit...
En même temps, j'apprécie particulièrement, parce que c'est une démarche tellement courante avec Access : on améliore régulièrement, et on n'hésite pas à reprendre un modèle pour l'améliorer.

Je ne penses pas que ce soit une évolution, c’est une demande des utilisateurs de la base (moi-même ) pour permettre une estimation d’heures à passer (pour déterminer la charge de chaque employé du bureau d’étude ) si lors du chiffrage de l’affaire le responsable d’affaire n’a estimé qu’une enveloppe d’heures globales.

La solution consiste à découper l'évolution de l'application en plusieurs phases :

La découpe consiste en quoi ?
Mettre les idées d’évolutions en commentaire (format texte) avec des priorités (V+, V++, …) ou commencer le développement (formulaires requêtes ..)

Il reste juste un point : es tu toujours d'accord qu'il n'y a qu'un seul NbHeuresAllouees par SectionAffaire ?

Et malheureusement NON !!
Il risque d’y avoir plusieurs NBHeuresAllouées par SectionAffaire, j’ expliques !!
Lors de travaux supplémentaires (avec chiffrage) le RA est susceptible de d’allouer de nouvelle heures allouées sur les SectionsAffaires, donc j’ai rajouté un champ date dans la tables HeuresAlloueées-SectionsAffaires.

Ci-joint fichier SuiviAffaire du 11-07-06 avec le différentes tables et champs qui je penses me seront nécessaires pour la 1ére évolution de l’application.

A toi de m’écrire ce qui te sembles pas bien ou très bien, j’ai crée toutes les relations. Une fois tout ceci fait, je penses pouvoir faire ma requête tant attendu (c'est à dire faire la différence des heures passées par rapport aux heures allouées par Sections Affaires) mais j'ai un peu de mal à voir comment je vais mettre en forme le formulaire de création de tout ça (mais c'est une autre histoire)

----------
Fichier attaché : SuiviAffaire 2006-07-11.zip (32.9 ko)
----------

[Papy Turbo]

La découpe consiste en quoi ?
Mettre les idées d’évolutions en commentaire (format texte) avec des priorités (V+, V++, …) ou commencer le développement (formulaires requêtes ..)

[Discussion sur les méthodes agiles, aussi connues sous le terme XP pour eXtreme Programming : développement par itérations]
La découpe consiste à extraire du cahier des charges, donc de la liste de ce que tu veux faire avec ton application,
1- un premier noyau, le plus simple possible, "qui marche". Par "quelque chose qui marche", on entend la base de données + l'application la plus simple possible, en supprimant tout ce qui peut être supprimé sans empêcher ce noyau de fonctionner, donc avec un minimum de tables, formulaires, fonctions... Tu dois quand même pouvoir le mettre en service, pour que les utilisateurs puissent commencer au plus tôt. Ce 1er noyau doit constituer une expérience complète de développement + tests + déploiement + beta tests avec les utilisateurs + observations des utilisateurs, etc.
2- rajouter, une par une, chaque fonctionalité supplémentaire, toujours en insérant le minimum à chaque fois : juste ce qu'il faut comme tables, formulaires, fonctions... pour qu'une nouvelle fonctionalité (au sens large, telle que vue par les utilisateurs) soit disponible.
3- etc., jusqu'à fin du projet, ou phases suivantes, tant qu'il y a des demandes supplémentaires et des sous pour les réaliser...
Le danger : on risque de rater le découpage et, lors d'une itération quelconque, d'être obligé de revenir en arrière et de modifier ce qui a été fait précédemment. Ce serait une perte de temps, donc un coût parasite, en temps et en €.
Les avantages :
- tous les problèmes de base (méthode de déploiement, machines cibles si parc hétéroclite, mise en place d'un "support technique", etc.) sont réglés dès le départ, avec une toute petite application simple (peu de bugs, même en beta). Faire la même chose, en une seule fois, avec une application complète, peut prendre un temps et des resources considérables.
- à chaque étape (itération), on se concentre sur l'essentiel : ce que doit faire la nouvelle fonctionalité, et comment le faire ?
- on a un "retour client" très tôt : ça permet de mettre en évidence des problèmes de conception, avant que toute l'application ne soit écrite, et donc "figée". S'il y a erreur de conception au départ, si cette erreur n'apparaît que quand les utilisateurs se servent de l'application, (ce qui ne contredit pas ce que je dis + haut, à propos du danger d'une découpe mal faite), on a, avec cette méthode, un minimum de points à revoir au lieu de réécrire toute l'application !
-> Économies considérables à moyen ou long terme, application souple, qui s'adapte facilement aux besoins réels, utilisateurs contents qui s'en servent efficacement...

Donc, l'idée des V+ et V++ est tout simple :
- lorsqu'une nouvelle fonctionalité (comme les heures allouées par Employé/Fournisseur) apparaît, question : est-ce que "ce que je suis en train de faire" PEUT fonctionner sans cette fonctionalité, ou pas ?
- Réponse OUI : tu notes un V++, dans ton cahier des charges ou dans le code, donc à faire dès que possible, mais après avoir mis en service ce que tu es en train de faire,
- Réponse NON : je ne pourrai pas commencer à faire tourner l'application sans cela,
ou bien : je ne pourrai pas rajouter cette fonction ultérieurement, sans modifier ce qui a été fait jusqu'à aujourd'hui,
Dans ce cas, tu le fais tout de suite, c'est à dire que
- soit tu le fais,
- soit tu ne peux pas (charge de travail), donc tu notes un V+ : à faire avant la prochaine mise en service (la fameuse "ToDo list" ou "check list").

Mode de décision : c'est généralement
- le développeur (analyste/chef de projet...) qui découpe et propose,
- le client (utilisateur) qui décide.
Ce sera l'occasion pour toi de te convoquer en réunion, de t'offrir un café, et de t'envoyer un mémo
C'est surtout une manière efficace de structurer le cahier des charges.

Et malheureusement NON !!
Il risque d’y avoir plusieurs NBHeuresAllouées par SectionAffaire, j’ expliques !!
Lors de travaux supplémentaires (avec chiffrage) le RA est susceptible de d’allouer de nouvelle heures allouées sur les SectionsAffaires, donc j’ai rajouté un champ date dans la tables HeuresAlloueées-SectionsAffaires.

OK. Il fallait le préciser, mais c'est toi le client, donc on reste comme ça.

Ci-joint fichier SuiviAffaire du 11-07-06 avec le différentes tables et champs qui je penses me seront nécessaires pour la 1ére évolution de l’application.

OK. Si c'est bon pour le client, c'est bon pour moi.

En même temps, j'ai regardé ta base et je constate juste un point, concernant l'intégrité référentielle, dont nous avons déjà parlé :
1- tu as mis de l'intégrité partout
Je rappelle juste, ce qui ne semblait pas clair au départ, que d'ajouter une contrainte d'intégrité entre 2 tables nous garantit qu'il est impossible d'avoir un enregistrement dans une table dépendante (par exemple une affaire) qui soit liée à un enregistrement "père" (par exemple un client) qui serait non valide : on ne pourra pas attribuer une affaire à un client qui n'existe pas, et on ne pourra pas supprimer un client sans supprimer aussi toutes ses affaires.
Il n'y a aucun code à écrire, juste un double clic sur la relation entre les deux tables et cocher une case : pas de bug, vite fait et très efficace pour la cohérence des données.

2- au niveau des options, tu as coché 3 fois (seulement) l'option "Mettre à jour en cascade les champs correspondants".
Par ailleurs, toutes les clés primaires de toutes les tables sont des champs AutoNumériques. Donc, toutes relations entre tables s'appuient sur ces champs.

À quoi sert l'option ?
Lorsqu'on utilise une clé alphanumérique, par exemple un [CodeClient], qui peut être le sigle de la société, en lettres, il est possible de faire une erreur. Dans ce cas, il faudra corriger ce code Client.
- si tu as coché l'option "Mettre à jour en cascade...", Jet (le moteur de la base de données) va automatiquement ajuster tous les codes clients dans les tables dépendantes : Affaires..., pour maintenir les liaisons entre enregistrements.
- si tu n'as pas coché cette option, il va t'interdire d'enregistrer la modification du code, pour préserver les liaisons. Ce qui te bloquerait !
Dans ce cas, il serait indispensable de cocher l'option.
À cause de cela, de nombreux programmeurs cochent systématiquement cette option, quel que soit le contexte. Mais ça peut ralentir ton application.
Dans le cas de clés primaires AutoNum, par contre, tu ne peux pas changer les clés (sauf cas exceptionnels, mais ça nous entraîne trop loin, et ça peut se gérer aussi). En ne cochant pas cette option, tu évites à Access, lors chaque modification d'un enregistrement, de vérifier s'il faut "mettre à jour en cascade..."
Donc, je te conseille, dans ce cas précis, de ne pas le faire.

3- tu n'as jamais coché l'option suivante "Effacer en cascade les enregistrements correspondants".
Tu fais bien d'attendre.

Que fait cette option, si elle est cochée ?
Admettons que tu coches cette option partout : lorsque tu vas supprimer un client de la base, Jet (encore lui), va supprimer, en cascade, toutes les Affaires de ce client. De là, il va supprimer toutes les SectionsAffaires de ces affaires. Puis, toutes les Heures Allouées et/ou Passées, dans les diverses tables liées aux SectionsAffaires.
Ça peut faire peur, donc : à utiliser avec prudence.
Par contre, tu voudras peut être un jour supprimer une SectionAffaire, par exemple (quelqu'un a alloué des heures par erreur, ce n'était pas la bonne section ou pas la bonne affaire...).
- Sans l'option "Effacer en cascade...", tu vas être obligé de supprimer un par un chaque enregistrement d'heures allouées/passées..., avant de pouvoir supprimer la SectionAffaire. Sinon le message d'Access sera : "impossible de supprimer l'enregistrement, parce qu'il y a des enregistrements dépendants..."
- Avec l'option cochée, lors de la suppression d'une SectionAffaire qui a des enregistrements liés, le message d'Access te dit que "Attention ! Des enregistrements dans d'autres tables vont être supprimés en cascade" et, si tu confirmes la suppression, Jet supprime tout d'un coup.
Dans certains cas, c'est donc très efficace de cocher cette option, mais le mieux est d'attendre et de voir, à l'usage, où est-ce que ça vaut le coup de cocher la suppression en cascade ?


En conclusion, à part 3 petites coches pour l'intégrité, c'est bon, tu dois pouvoir faire ta requête sachant qu'il faut :
- faire chaque somme d'heures (allouées/passées/globales/par employé/par fournisseur),
- regrouper toutes ces sommes par SectionAffaire,
- y ajouter les informations complémentaires : libellé de l'affaire, de la section, etc.

S'il y a le moindre problème, j'attends tes questions.

[Serge57]

S'il y a le moindre problème, j'attends tes questions.

Tu t’y attendais ???
Comment faire une addition de champ nulle avec d’autre ?? (dans la même requête)
J’ai trouvé un moyen (mais c’est lourd) en mettant un ‘VraiFaux’ dans les champs susceptibles d’avoir un champ nulle. Ne cherche pas j’ai tout supprimé dans la requête que j’ai envoyée (de peur de me faire tirer les oreilles). DONC Question ?? Vaudrait-il pas mieux de faire plusieurs requête ? mais comment ??

Joint ma table avec modification des relations et requête (pas complète) pour voir si je suis dans le bon chemin ?


Question à Papy Turbo: Pour faire suivre mes fichiers 'zips' je suis obligé de supprimer les anciens fichiers attachées sur le cours. Celà pose-t-il un problème pour la suite ???

--------
Fichier attaché : SuiviAffaire 2006-07-12.zip (21 ko)
--------

[Papy Turbo]

Tu t’y attendais ???

Bof, juste une vague intuition
Par contre, je ne m'attendais pas à autant de questions (explicites ou implicites), d'un coup !
Donc, il va falloir :
- faire le point sur la mise au point de la structure, qui est terminée.
- démarrer un nouveau sujet : nous ne sommes plus dans le "Merise", ou "analyse de structure d'une base de données", mais bien dans la réalisation d'une requête, avec jointures.
Même si c'était la question de départ, je préfère qu'on sépare les sujets, ce sera plus digeste pour les éventuels lecteurs.

Le point sur la structure de la base
- en ce qui me concerne, tu as nettoyé toutes les options d'intégrité, donc, la base est propre et on peut passer à la phase suivante.
- j'ai juste déplacé la table [Employes] à gauche de la table [Affaires], dans le schéma relationnel, pour des raisons de lisibilité déjà exposées dans la réponse #31... Tu verras ça dans la copie de la base liée au prochain sujet, lien ci-dessous.

En résumé, on a évoqué les divers types de liaison entre tables :
- relations de UN à UN, dans la réponse #35
- relations de UN à PLUSIEURS et de PLUSIEURS à PLUSIEURS, dans la réponse #31
- intégrité référentielle, dans la réponse #37
- bref aperçu du développement par itérations, dans les méthodes agiles, dans la même réponse #37

Pour aller + loin, voir les divers tutos présents sur la page Cours de DVP, notamment sur Merise et UML (plus avancé), et surtout la 1ère partie du cours Access - Les Bases : Introduction et Conception de Maxence Hubiche, qui ne figure pas encore sur la page de cours.
Ce tutoriel détaille étape par étape ce que nous venons de faire, avec l'avantage d'utiliser des verbes pour noter les relations, ce qui est plus clair que notre utilisation abusive du verbe "avoir".
La seule suggestion que j'aie pu faire, par rapport à la méthode Merise pure, concerne les relations de PLUSIEURS à PLUSIEURS : je conseille
- de nommer immédiatement la relation, qui correspond à une nouvelle entité, plutôt que de l'appeler d'un terme générique ("Relation" ou autre). C'est ce qui est fait, plus loin, dans le cours de Maxence.
- décomposer cette relation en 2 relations de UN à PLUSIEURS, plus simples à traiter.

Fin du [Cours pt-01][Débutants]Analyse structure base de données simple.

Suite dans le [Cours pt-02][Débutants]Requête avec plusieurs sommes


Je remercie les divers lecteurs de ne pas être intervenus pour partir dans toutes les directions, ce qui aurait rendu ce cours très incohérent.
Je rappelle, par contre, que toute question demandant des explications sur un point quelconque, sont plus que bienvenues dans le cours, même et surtout si vous vous "sentez" au niveau débutant. Le cours est fait pour cela.
Par contre, plusieurs remarques, sur le déroulement ou sur le contenu, me sont parvenues en privé. Il serait bien que ces questions soient débattues en public, d'où ouverture d'un sujet parallèle, dédié à tous vos commentaires, suggestions, opinions diverses...
J'ouvre donc un nouveau sujet, en parallèle à ce cours : [Cours papyturbo]Commentaires, remarques et suggestions

[Serge57]

Bonjour,

Les données :
1-J’ai plusieurs petites applications Access qui pointent chacune sur une base de donnée différente.
2-Je suis en cours de développement d’une nouvelle « petite application » qui elle a besoin de tables provenant de bases de données différentes.

Questions :
-Est-il préférable de regrouper les différentes tables dans une même base Access ? (ce qui l’alourdir et m’oblige à reprendre les anciennes applications) .
-Garder les tables dans des bases différentes ? ( mais l’intégrité référentielle ne fonctionne plus)….

Est ce le bon cours pour ma question, mais j'ai tellement mer.... sur les intégrités..