[Débutants]Analyse structure base de données simple

[Serge57]

Bonjour Papy Turbo,

Et c'est révélateur, là aussi, d'une étude de la structure de la base qui n'a pas été poussée à fond avant de commencer

Aucune excuse de ma part, mais c'est l'évolution de la demande qui a créé tous ces disfonctionnement. Il faut savoir que la base 'tourne' alors que j'essayai de rajouter de 'nouvelles fonctionnalités' .

Les différentes sections, ainsi que les heures fournisseurs viennent de se rajouter d'où cette lourdeur.

[quote]- aucune intégrité référentielle. Faire un double clic sur chaque relation,dans la fenêtre des relations de la base, pour voir les options -> F1 pour étudier l'aide d'access [\quote] Vu que les tables , l'application 'sont évolutifs' (le pourquoi d'access), je n'est pas l'habitude de faire l'intégrité référentielle (peut être une grave erreur !!). J'essaye de garder l'intégrité par ' code ' et des ' interdiction ' dans mes formulaires. Pour l'instant je n'est eu de problème majeur.(Base qui à démarré en 2000 sur access 97).
Les tables étant dans un autre fichier que l'application (tables liées) et l'ancienne application alimente ces tables, est-il obligatoire de mettre à jour les relations dans le fichier tables ??

Enfin je remarques : d'un problème que je croyais "d'access", je suis en train d'apprenbre plein d'autres choses

[Papy Turbo]

Envoyé par Serge57

Les tables étant dans un autre fichier que l'application (tables liées) et l'ancienne application alimente ces tables, est-il obligatoire de mettre à jour les relations dans le fichier tables ??

Il n'y a aucun rapport entre ces 2 considérations :
- tu scindes ton application en 2 : base de données (tables) + application (formulaires...)
- tu ne mets pas d'intégrité entre tes tables, ou tu essayes de faire en code -avec des bugs + lenteur + le fait que quiconque ne passe pas par ton formulaire peut tout foutre en l'air
En 3 clics, dans la base de données (tables), tu obliges Jet à bosser pour toi, de manière infaillible : il sera impossible de créer des données incohérentes (heures sans affaire ou section mal orthographiée ou...) + tu peux ajouter des protections (impossible de supprimer une affaire qui a des heures...), ou des fonctions de nettoyage (tu supprimes une affaire : Jet supprime tous les détails, etc.
Y a vraiment pas de quoi s'en priver.

Je sais que beaucoup hésitent à refaire la structure propre d'une base en cours de production : ils vont toujours (tu vas) le payer extrêmement cher.

Dis donc, j'espère que tu ne développes pas les nouvelles fonctionalités, en restant lié aux mêmes tables que les autres utilisateurs ???
Même si c'est toi qui porte les 2 casquettes de développeur/utilisateur, tu dois absolument utiliser une copie des tables (sur ton poste), pour tout développement.
Sinon, bonjour, les dégats quand tu vas planter tout ça !

Revenons à l'intégrité :
Disons que ça te prenne une semaine de refaire tout au propre, y compris une bonne journée, à la fin, pour transférer toutes les données de la base de production sur ta nouvelle base propre (peut être même un week end, pendant que les autres sont à la pêche au gardon).
Si tu ne le fais pas, dans un mois ou 2 ou 3, tu n'auras plus un seul cheveu sur le caillou, et tu ne dormiras plus.

Tu as le choix

P.S. : dans ton cas, c'est pas seulement une question d'intégrité, c'est pire : il faut absolument revoir les relations entre les tables. La dualité Affaires <-> Sections doit être concrètement traduite en une table des "SectionsParAffaire" (ou "HeuresAllouéesParSectionParAffaire", ça marchera aussi).
Sinon, tu vois l'usine à gaz (requête mise au pont dans le zip joint + haut) rien que pour afficher un résumé non modifiable !!!!!!!
Qu'est-ce que ce sera quand tu voudras faire une mise à jour globale, ou même des statistiques !

[Serge57]

Dis donc, j'espère que tu ne développes pas les nouvelles fonctionalités, en restant lié aux mêmes tables que les autres utilisateurs ???
Même si c'est toi qui porte les 2 casquettes de développeur/utilisateur, tu dois absolument utiliser une copie des tables (sur ton poste), pour tout développement.

Aucune inquiètude, c'est des copies locales.

Revenons à l'intégrité :
Disons que ça te prenne une semaine de refaire tout au propre, y compris une bonne journée, à la fin, pour transférer toutes les données de la base de production sur ta nouvelle base propre (peut être même un week end, pendant que les autres sont à la pêche au gardon).
Si tu ne le fais pas, dans un mois ou 2 ou 3, tu n'auras plus un seul cheveu sur le caillou, et tu ne dormiras plus.

Compris la leçon, je m'y attaque dès ce week-end (et peut être d'autres week end). J'aurai d'autres questions à poser ? Mais pas tout en même temps. Je mets d'abord en route (et en pratique) tout ce que vient d'apprendre. mille fois PAPY TURBO de m'avoir accompagné.

[Papy Turbo]

Pour les lecteurs qui continuent à suivre ce sujet :
- ce sujet, anciennement "Impossible de quitter Access", a été déplacé aujourd'hui, 17 juin, dans le forum Débats et Sondages,
- il s'agit d'une expérience de cours en direct,
- voir l'entête, sur la réponse #1. Merci de le lire, et de respecter ces nouvelles "règles" nécessaires au bon fonctionnement.
--------------------------------------------------------------
Bonjour, Serge57,

On ne va pas s'arrêter en chemin.
Surtout pas avec une réponse fournie toute faite (aucun intérêt didactique), et surtout aussi lourde et compliquée !

Donc, je te propose
- de repartir de l'image de la structure de la base de données actuelle, telle qu'elle est affichée dans la réponse #8,
- de réfléchir aux simples questions de base :
1- Qui a quoi ?
Le verbe "avoir" étant pris au sens très large. Ça peut être aussi bien :
- une entreprise a des fournisseurs,
ou bien
- une affaire a des heures allouées... ?

2- et combien ?
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.
Par exemple,
- chaque fournisseur a une ou des adresses ?

Je propose que tu commences par
- nous dire en quelques mots de quoi on parle (quel aspect de quel métier ?), parce qu'il est impossible d'analyser les données sans connaître le sujet,
- lister par écrit les objets, également au sens large, qui composent les données à traiter (affaires, sections, heures, etc.),
- lister par écrit les relations entre ces objets,
ce qui permettra à tous de rentrer dans le détail du métier pour lequel cette application est concue.
Ensuite, on les représentera graphiquement.
Pour l'instant, ce n'est que : analyse de la réalité, avec du bon sens.

[Serge57]

Bonjour Papi Turbo

Tout d'abord le pourquoi de cette base:
Etant Responsable d'un Bureau d'études, il me faut le gérer administrativement

Envoyé par PapyTurbo

lister par écrit les objets, également au sens large, qui composent les données à traiter (affaires, sections, heures, etc.),

1 - les affaires (commandes en études),
2 - Les clients (table non représentée dans l'image de la structure)
3 - L'imputation (heures passées) du personnel du bureau d'étude sur ces affaires(Compétence interne)
4 - Les prestations (heures passées) de fournisseurs sur ces affaires (imputation Compétence externe),
5 - Pour les imputations interne et externe, il y a différentes sections(Automaticiens, Electromécanicien, Responsable, Chef de Projet ......)
6 - Des heures allouées par affaires dans les différentes sections.

Envoyé par Papy Turbo

- lister par écrit les relations entre ces objets,

1 - Toutes affaires a un client, par contre elles peuvent avoir des heures allouées pour différentes sections.
2 - Toutes heures passées (internes ou externes) sont passées sur affaires. Lors de l'imputations de ces heures, le personnel ou fournisseur appartient à une section qui peu ou PAS avoir d'heures allouées sur cette affaire. ( un peu compliqué à expliquer )
3 - Bien sûr, il me faut un décompte des heures passées internes, externes (positif ou négatif) pour chaque affaire et chaque section.

J'espère avoir bien exposé le problème ?

[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 :

Envoyé par Serge57

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é ?

Envoyé par Papy Turbo

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]

Envoyé par Papy Turbo

- 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.

Envoyé par Papy Turbo

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.

Envoyé par Serge57

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]

Envoyé par 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.

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,

Envoyé par Serge57

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 ?

Envoyé par Serge57

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]

Envoyé par Papy Turbo

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]

Envoyé par Serge57

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.

Envoyé par Serge57

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 ...

Envoyé par Serge57

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.

Envoyé par Serge57

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]

Envoyé par Papy Turbo

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.?