Discussion :

[Mulai]

bonjour tout le monde!

Voila dans la base sur lequel je suis en train de travailler, j'essaye de centraliser mes contacts dans une seulle table.

Mes contacts vont donc avoir plusieurs catégories; ce nombres de catégories peut être important.

J'hésite donc dans ma table contact à mettre tout les champs possibles de facon à ne pas alourdir la table pour un contact simple.

Il faudrait donc que j'ajoute grâce à mon formulaire contact des champs dans ma table en fonctions des différentes catégories du client ( qui n'est pas uniques)

Je m'explique, mon client peut travailler pour plusieurs entreprises. Dans ces mêmes entreprises, il peut avoir plusieurs fonctions.

La solution serait pour moi dans mon formulaire d'ajout/modification de contact que grace à une case à coché " entreprise" celle ci fasse apparaître une liste déroulantes " entrprise" renseigné par ma table "entreprises" ( ca c'est bon ),
que lorsque l'utilisateur selectionne une entreprise dans cette liste,

le formulaire ajoute un champ dans ma table contact avec comme nom "entreprise 1" et la valeur selectionnée,

et ensuite fasse apparaître une deuxième liste déroulante entreprise qui elle ajouterai un champ dans ma table contact "entreprise 2" avec la valeur sélectionnés, et ainsi de suite.

Ma base fonctionne sur réseau, de 5 à 15 postes suivant le lieu .

J'ai aussi peur de créer une table contact extrément lourde.

Qu'en pensez vous ?

[Oleff]

Bonjour,
Plutôt que l'alourdissement progressif, je créérais une table de jointure entreprise-contact en plusieurs à plusieurs et une table contact-fonction en plusieurs à plusieurs OU une table entreprise-contact-fonction.

[Mulai]

Ok, je vois bien dans l'idée le schéma ce que tu me propose.

Je vais donc reprendre le tutoriel pour voir comment valider ma table jointure ( a base de requête je pense ).

[Oleff]

Il faut dabord que tu analyses bien les beoins en matière de table.
Voies si une seule table de jointure (entreprise-contact-fonction) te suffit ou si tu préfères en avoir deux (entrepris-contact et contact-fonction).

Après pour l'alimentation de ta (ou tes) table(s) tu pourras utiliser un ou des sous formulaires (en interface utilisateur) ou des requêtes (mode admin)
En form principal, le contact, en sous-form le couple entreprise-fonction alimenté par zones de liste.

[Mulai]

bon donc j'en arrive à ceci:






Un contact peut :
travailler pour plusieur entreprise;
avoir plusieur fonction
avoir plusieur diffuseur local
avoir plusieur diffuseur nationnnal

Une fonction peut :
avoir plusieur contact
avoir plusieur entreprise
avoir plusieur diffuseur local
avoir plusieur diffuseur nationnal

Etc ...

Tout est en relation plusieur à plusieur...

ou alors je me suis trompé !


Edit: plus j'y réfléchis, plus je trouve que c'est une bombe mon truc ...

[Oleff]

Pour affiner ton analyse :
Qu'est-ce-qu'un diffuseur ? Une entreprise ? Autre chose ?
Les fonctions des enteprises sont-elles les mêmes que celles des contacts (à priori personnes physique) ?

Selon tes réponses, certaines tables seront peut-être inutilses et donc certaines tables de jointures.

[Mulai]

Tu tombes pile poil dans ce qui fait mal !

Mon entreprise est l'entité qui devient mon locataire ( pour la journée / semaine / mois )

Le diffuseur local s'occupe de la diffusion de cet événement dans la région

le nationnal dans la france entiere .

Un contact/ personne peut travailler pour un diffuseur et à la prochaine location pour l'entreprise,

Mais ce même contact peut avoir des fonctions différente dans les entreprises / diffuseur a chaque événement.

Un jour il sera technicien pour l'entreprise, au prochain événement il sera resp com pour le diff local, etc .

Mon soucis est que pour chaque évenement il me faudrait un recap des personnes à contacter.

Sachant que je peux avoir 90 personnes sur un événement, ca devient vite ingérable de savoir qui fait quoi pour qui !!


Edit:

Ce qui m'embete c'est que je pourrais très bien intégré dans chaque table des champs nom/prénom/tel/fax) etc... Mais pour chaque événement tout change !!
Ce qui forcerait mes jolies demoiselle de l'administration de retaper à chaque fois des données déjà rentrées précédément pour un autre événement ..

Edit 2 :

Oui je viens de m'apercevoir que là j'ai inclus les données du reste de la base, à savoir la table événement.

un événement à une entreprise, un diffuseur local, et un diff nat.

[Oleff]

Je pense que tu devrais reprendre les choses à la base.

D'après ce que tu as livré comme infos, tu devrais avoir 4 entités (sous réserve)
- Entreprise (client)
- Diffuseur
- Contact
- Evènement

Pour les relations c'est plus difficiles sans connaitre le sujet.
Quelques question que je me pose :
Est-ce-qu'un évènement est louable par plusieurs clients au même instant ?
Est-ce-qu'un contact peut travailler au même instant pour plusieurs entreprises, évènement ou diffuseur ?...
Est-ce qu'un diffuseur peut être local et national pour un évènement ?

Selon les réponses on y verra plus clair.

[Mulai]

On reprends tout !


Pour un événement, j'ai une entreprise ( qui est mon locataire) un diffuseur nationnal, et un diffuseur local.

Pour ce même évenement, l'entreprise et les diffuseur peuvent être les mêmes.

pour cette partie là, vu qu'il n'y a que 3 réponses, une table "client" pourrait être faite regroupant toutes mes entitées " entreprise" " diff local" et "diff nat" avec des cases à cochées. Comme cà dans mon form évenement, je fais des listes déroulantes ou je vérifie la valeur des case à cocher.

Ca c'est simple.

Ensuite pour un événement, j'ai une liste de personne ( "contact" ). Ces contacts peuvent avoir plusieur fonctions au sein d'une entité pour le même événement.

Dans un événement donc, un contact peut travailler pour l'entreprise en tant que DGA et chef de projet; pour le diff local en tant que chef Technicien implantation et enfin pour le diff nat en tant que régisseur.

C'est donc a priori dans la table événement que je dois classer aussi ces infos.

Mais, ( y'a toujours un mais ) vu que la liste contact est volumineuse, il faudrait que chaque contact puissent être classé suivant ses fonctions. Afin de ne pas lister tout les contacts pour chaques entreprises /diff et événement .

Je fais un schéma...

Edit :

bon j'arrive pas à faire le schéma ... comme quoi y'à bien un problème de conceptions...

[Oleff]

Je verrai bien trois tables de base :
Evènements{cléNumEv, Nom, autres infos toujours bonnes}
Entreprises{Raison sociale, siret, tel_standard}
Contacts{cleNumContact, Prénom, Nom, date_naissance...}

Une table de jointure Evènement-Entreprise{cléNumEV, siretClient, siretDifNat, SiretDifReg}
Une table de jointure Evènement-Entreprise-Contact{cléNumEV, siretEntr, cleNumContact, cleFonction...}

Edit :
J'ai oublié une table fonction qui n'est pas obligatoire mais peut quand même être utile

[Mulai]

Hum, je ne comprends pas pourquoi dans ce cas il faudrait 2 tables de jointures, on ne repete pas les infos entre les 2 tables de jointure là ?

[Oleff]

Je ne pense pas.

La première table de jointure porte les infos locataire, diffuseur nat, diffuseur reg.
La deuxième porte les infos fonction d'un contact pour une entreprise et un évènement.

Par curiosité, tu gères des intermittents du spectacle ?

[Mulai]

Exactement !! Vive les intermittents !

Mais y me donnent du boulot

Ok je comprends l'intéret des 2 tables. Je vais donc me baser la dessus.

Merci du coup de main.

Je valide ce post, reste en ligne la conception complète prendra encore beaucoup de temps! tu viens juste de me solutionner le problème des contacts, d'autres vont apparaître.

Bonne journée.

[Oleff]

Bon courage pour la suite et @ bientôt...

[Mulai]

Donc ca donne ceci :



Tu valide ?

hum non en fait, j'enlève le résolu et je vais chercher un tuto sur les relations

[Oleff]

Le modèle me semble à peu près bon à un point prêt.

Tu dois multiplier la table entreprise par trois et établir une relation de chaque vers ta clé étrangère.

Autre point, il me semble que certaines infos de contact devraient être dans la table de jointure (gsm de prod...)

[Mulai]

Bonjour Oleff

Multipliés par 3 la table entreprise ( entité ) ? ou la table join-evenement -entité ?

Je t'avoue que j'ai du mal avec ces tables dites de jointures

Ce que j'en avais compris c'est que pour un événement grace a ces tables j'allais pouvoir afficher dans mon form événement, un sous form contenant les infos de join événement-entités, dans par exemple un tableau et que ca me permettait d'avoir plusieurs enregistremlent de la table join-evenment-entite pour 1 Evenment .


Aurais je mal compris ?

[Oleff]

Tu as tout à fait bien compris. : )

C'est pour tes relations que tu dois afficher trois fois la table entreprise, une pour chaque rôle possible de l'entreprise.

Pour les form-sous-form, il t'en faudra peut-être sur deux niveaux.
L'évènement au niveau du form, un sous form entreprise-diffuseurs et un sous-sous-form contact.
Tu peux aussi faire un form évènement, un sous form entreprise et un deuxième sous form de même niveau pour tous les contact liés à un évènement.
Dans tous les cas ton modèle devrait répondre aux besoins que tu as exprimé.

[Mulai]

ok donc ssuite à ta remarque ca donnerai ca :



Ca me parait bizard, je dois vraiment pas avoir la logique table de jointure dans la tête

Edit: pour m'en faire une idée je suis entrain de le mettre en form, mais ce principe de sous-form me donne mal à la tête, j'ai pourtant l'impression que c'est un des système important d'Acces !

=> go Bouton rechercher pour trouver des exemple ^^

[Oleff]

Le principe formulaire sous-formulaire est en effet très interressant.
Le formualire va afficher les données d'une table ou d'une requête, le sous formulaire va afficher les données d'une autre table ou requête dépendantes de la première source.

Dans ton cas le formulaire évènement va te permettre d'afficher dans un formulaire les données de ton évènement et dans un sous-formulaire tous les contacts attachés à cet évènement.