Discussion :

[JustinCurtis]

Bonjour,

Je souhaite créer une base de données sur Access assez "simple d'utilisation", car elle sera utilisée par des personnes novices.

Pour faire simple, c'est une base pour répertorier des clients VIP.

Je vous joins un screen de où j'en suis :




Mes questions sont les suivantes :

Sachant que certains clients peuvent avoir deux organisations, ai-je bien fait de créer deux champs dans la table "clients" ? Y a-t-il un meilleur choix ?

De ce fait, j'aimerais que dans la table "organisation" il n'y ait qu'un seul champ, et non deux pour référencer les organisation et leur domaine. Comment faire ?

J'ai choisi un numéro pour chaque client, est-ce la bonne solution ?


De même, si vous voyez des améliorations, je suis preneur.
Je tiens à signaler que je suis débutant sur Access, mais ouvert à tout conseils !

Merci d'avance pour votre aide précieuse

[Michel]

Bonjour JustinCurtis
En lisant ton post en diagonale je vois quelques problèmes.
Pour moi, une relation 1 à 1n'est pas très utile et tout cela pourrait rester dans une table.
Concernant les clés primaires, pourquoi ont-elle toutes le même nom ? cela ne facilitera pas la création de requêtes.
Concernant les clients et les organisations, j'aurais créé une table qui définit chaque organisation (clé, nom, catégorie) et une table intermédiaire qui contiendrait le numéro du client et le numéro de l'organisation.
Mais ce n'est qu'une suggestion !

[JustinCurtis]

Merci pour ta réponse Michel.

En fait, j'ai créé plusieurs tables au lieu d'une seule par soucis visuel pour ne pas avoir trop d'infos sur une seule table.

Je ne vois pas comment mettre différentes clés primaires dans ce cas ?

Et pour les organisations, je veux bien suivre ton conseil mais comment attribuer deux organisations à un seul client ?

J'essaye de modifier tout ça et j'enverrai un screen à nouveau !

[Michel]

Ce sont les noms identiques qui compliquent la vie.
Dans client on N° et dans assistante également N°. Si on veut garder ces deux tables, pourquoi pas numClietnt et numAssistante à la place.

Et pour les organisations, je veux bien suivre ton conseil mais comment attribuer deux organisations à un seul client ?

La table intermédiaire contient deux champs numClient et numOrganisation et donc on peut avoir deux enregistrements avec un même numéro de client et deux numero d'organisation différents.

avoir trop d'infos sur une seule table

Aucune importance, il suffit de créer une requête qui affiche les informations utiles.

[Michel]

A la réflexion si les clients ont toujours deux organisations, on peut laisser les deux références dans la table mais chaque référence doit être liée à la table organisation.

[DJOUFOU]

bonjour

A la réflexion si les clients ont toujours deux organisations, on peut laisser les deux références dans la table mais chaque référence doit être liée à la table organisation.

je pense que pour rester dans le principe d'un programme informatique, il faut prévoir toutes les éventualités. Un client peut avoir aujourd'hui 2 organisations et après avoir une 3ème, alors je propose que le Monsieur crée une table intermédiaire entre la table "organisation" et la table "client" comme vous l'avez suggéré plus haut.

[Michel]

bonjour


je pense que pour rester dans le principe d'un programme informatique, il faut prévoir toutes les éventualités. Un client peut avoir aujourd'hui 2 organisations et après avoir une 3ème, alors je propose que le Monsieur crée une table intermédiaire entre la table "organisation" et la table "client" comme vous l'avez suggéré plus haut.

Entièrement d'accord !C'est ce que je lui ai proposé au départ mais comme cela avait l'air de lui poser problème, j'ai envisagé l'hypothèse de deux organisations systématiquement, ce qui n'est pas impossible pour son cas.
Le problème plus fondamental est qu'il n'y a pas d'analyse du problème et donc on avance à tâtons

[bertiny]

Bonjour à tous
Si on essaie d'analyser de manière simple les informations que nous disposons,
Un client dispose une ou plusieurs organisations (pour l'instant notre ami voit l'éventualité de 2 organisations. On peut donc classer cette cardinalité dans le registre "un à plusieurs")
Si on part du fait qu'une organisation appartient à un et un seul client (le président ou directeur tout dépend de vous, qui le représente, et que tous les autres quelque soit leur poste de responsable sont ses assistants), ceci étant juste une hypothèse, on aura donc deux tables:

-TableClient(id_client, nom, prenom, sexe, telephone, email,... )
-TableOrganisation(id_organisation, id_client, nom_organisation, categorie)

Le plus souvent, les "clients VIP" ont un ou plusieurs assistants. On Aura donc une autre table
-TableAssidtant(id_assistant, id_client, nom_assistant, prenon_assistant, fonction_assistant, sexe_assistant, telephone_assistant)

De manière objective voilà ma modeste contribution.

Cordialement.

[JustinCurtis]

Messieurs bonjour,

Dans un premier temps, merci d'avoir pris le temps de me répondre.

En tenant compte de vos conseils, je me retrouve avec ces tables et relations :



Qu'en pensez-vous ?

Pour vous le confirmer, un client peut avoir une ou plusieurs organisations.

Merci d'avance

[Michel]

Juste une remarque:
Évite les caractères accentués, les espaces et surtout les apostrophes dans les noms des champs. Si tu dois,un jour, écrire une requête directement en sql du verra vite pourquoi !
Pour afficher le nom en français, il suffit d'utiliser un alias dans une requête.
On peut remplacer les espaces par un trait de soulignement; c'est presque aussi lisible.

[bertiny]

je propose ceci



cordialement

[Michel]

@bertiny l'identifiant du client ne peut pas être dans la table organisation sinon pour chaque client, je doit redéfinir une organisation alors qu'une organisation est utilisée par plusieurs clients. Il faut bien une table intermédiaire qui contient id_client et id_organisation

[bertiny]

Bien sûr Michel

[Michel]

Sans vouloir chercher la petite bête, le couple id_client et id_organisation forment ensemble une clé primaire pour la table appartient et donc le champ id_appartient est inutile.

[bertiny]

Notre ami pourra bien se charger de cette modification. C'était ma modeste contribution.

Cordialement.

[marot_r]

Bonjour.

Sans vouloir chercher la petite bête, le couple id_client et id_organisation forment ensemble une clé primaire pour la table appartient et donc le champ id_appartient est inutile.

En fait il est parfois TRES utile d'avoir une clef primaire indépendante des champs qui pourarit la composer.
On pourra définir un index unique sur les morceaux de la clef (seul défaut si un des champs est nul, l'unicité prend le bord :-(, pas cool).
Il arrive souvent un moment où on a pas toutes les infos pour identfier l'enregistrement et qu'on doive quand même y accéder de manière unique.
Les champs autonum (ce sont des entiers longs en fait) sont peu demandant en temps et en espace et ils peuvent éviter bien des maux de têtes.
Accessoirement il permette aussi de savoir dans quel ordre on a entré les données.
Alors même si stricto-sensu, ils sont inutiles, je suggère de le laisser là.

A+

[bertiny]

Bonjour.



En fait il est parfois TRES utile d'avoir une clef primaire indépendante des champs qui pourarit la composer.
On pourra définir un index unique sur les morceaux de la clef (seul défaut si un des champs est nul, l'unicité prend le bord :-(, pas cool).
Il arrive souvent un moment où on a pas toutes les infos pour identfier l'enregistrement et qu'on doive quand même y accéder de manière unique.
Les champs autonum (ce sont des entiers longs en fait) sont peu demandant en temps et en espace et ils peuvent éviter bien des maux de têtes.
Accessoirement il permette aussi de savoir dans quel ordre on a entré les données.
Alors même si stricto-sensu, ils sont inutiles, je suggère de le laisser là.

A+

Merci Marot_r pour cette intervention. Sans toutefois vouloir blesser qui que ce soit, chacun a sa perception des choses. Et c'est pour ça que j'ai pris la peine de laisser à notre ami de décider.

Cordialement.

[marot_r]

Bonjour Bertiny.

Tu as parfaitement raison, c'est pour cela que j'ai terminé par une suggestion.

Belle année à toi.

A+

[Paraffine]

Bonjour JustinCurtis
Pour moi, une relation 1 à 1 n'est pas très utile et tout cela pourrait rester dans une table.

Personnellement, cela ne me choque pas tant que ça.
Car il est aussi intéressant de gérer de manière standardisée des données comme les coordonnées et les adresses, qui peuvent s'appliquer à différents objets.
Ou de réutiliser des développements faits dans d'autres contextes...

Cordialement,
Paraffine.