Debut !

[bil bool]

Bonjour
J'essaie de faire une base de données destiné à creer un bon de commande en interne, pouvez vous m'indiquer si je suis bien parti (copie ecran attachée)
Merci

 

[chris]

Re : Debut !

Bonjour

Oui et non
Les tables Noms et prénoms m'ont l'air sans objet
Les relation doivent toujours se faire entre une clé primaire et une clé étrangère : là pas de clés primaires dans tes liens.

Une image ne suffit pas à comprendre ton cas : donc de piste à te donner pour améliorer.

 

[PascalXLD]

Re : Debut !

Bonjour

Tout à fait d'accord avec Chris (Bises au passage )

Pour moi tes tables noms et prénoms peuvent n'en faire qu'une

Ta table service il faut savoir ce qu'elle veut dire
Si la personne appartient à un service c'est plutôt entre personne et service qu'il y a un lien

Idem pour demande et catégorie de demande. J'ai l'impression que le lien est plutôt à ce niveau

Mais comme le dit Chris difficile avec une image de comprendre tout

 

[bil bool]

Re : Debut !

Merci de vos réponses,

Chris, qu'entends tu par :
''- Les tables Noms et prénoms m'ont l'air sans objet'' ?

Pour les relations qui doivent toujours se faire entre une clé primaire et une clé étrangère , j'entends bien, mais je pensais que la petite clé jaune signifiait ''clé primaire''

Une image ne suffit pas à comprendre ton cas : Ok pour l'image (cela me paraissait plus parlant)

A pascal XLD :
Pour toi les tables noms et prénoms peuvent n'en faire qu'une, en effet mais je voulais que chacun puisse choisir son prénom, ainsi ce n'est pas limité en nom et prénom, en même temps c'était juste une idée. De plus je ne saurais comment faire apparaitre nom et prénom dans deux champs différents.

Ta table service il faut savoir ce qu'elle veut dire
Si la personne appartient à un service c'est plutôt entre personne et service qu'il y a un lien. Oui c'est bien le service ou travaillent les personnes mais... il peuvent bouger.

Idem pour demande et catégorie de demande. J'ai l'impression que le lien est plutôt à ce niveau, (voir carte en PJ)

J'ai peur de ne pas être tout à fait clair...merci encore

 

[chris]

Re : Debut !

Re

Chris, qu'entends tu par :
''- Les tables Noms et prénoms m'ont l'air sans objet'' ?

Si ce sont les noms et prénoms des demandeurs, on devrait avoir une table des demandeurs (tous les demandeurs potentiels) avec des champs comme Nom, prénom, service de rattachement... donc un lien entre demande et demandeur et un autre entre demandeur et service mais pas entre commande et service, ni même entre demande et demandeur si la commande est toujours liée à une demande.
Si une personne change de service, eh bien ce n'est pas grave : on change son affectation dans la table des demandeurs.

Pour les relations qui doivent toujours se faire entre une clé primaire et une clé étrangère , j'entends bien, mais je pensais que la petite clé jaune signifiait ''clé primaire''

Oui mais ton lien est fait avec l'autre champ et non celui qui porte la clé.
De plus avoir systématiquement comme clé primaire un numéro, sans doute auto, n'est pas forcement le meilleur choix. L'intérêt d'une clé primaire est aussi d'éviter les doublons en saisie. Par exemple, le n° auto n'empêche pas de mettre 2 fois DUPONT dans la table.
Toutes les relations doivent être de 1 à n avec intégrité référentielle si tu veux que ta base soit solide et cohérente.

je voulais que chacun puisse choisir son prénom, ainsi ce n'est pas limité en nom et prénom, en même temps c'était juste une idée. De plus je ne saurais comment faire apparaitre nom et prénom dans deux champs différents.

Si on est demandeur, on a un prénom : cela fait partie de l'identité du demandeur et pas d'un choix.
Il est préférable de mettre 2 champs. Mais selon l'utilisation faite, ce n'est pas forcément obligatoire.

Même avis que Pascal (bises amicales en retour) pour demande et catégorie de demande.

Tu fais du mind mapping ?

 

[bil bool]

Re : Debut !

Bon...bon...bon !
Ca fait longtemps que j'essaie Access et chaque fois je laisse tomber, il me manque ...un declic, y a un quelque chose que je ne percute pas...bref !

Re
Si ce sont les noms et prénoms des demandeurs, on devrait avoir une table des demandeurs (tous les demandeurs potentiels) avec des champs comme Nom, prénom, service de rattachement... donc un lien entre demande et demandeur et un autre entre demandeur et service mais pas entre commande et service, ni même entre demande et demandeur si la commande est toujours liée à une demande.
Si une personne change de service, eh bien ce n'est pas grave : on change son affectation dans la table des demandeurs.

Je vais essayer de mettre cela noir sur blanc.
Pour la dernière remarque c'était justement pour ne pas avoir à modifier las base mais simplement y rajouter des infos.

Re
Oui mais ton lien est fait avec l'autre champ et non celui qui porte la clé.
De plus avoir systématiquement comme clé primaire un numéro, sans doute auto, n'est pas forcement le meilleur choix. L'intérêt d'une clé primaire est aussi d'éviter les doublons en saisie. Par exemple, le n° auto n'empêche pas de mettre 2 fois DUPONT dans la table.
Toutes les relations doivent être de 1 à n avec intégrité référentielle si tu veux que ta base soit solide et cohérente.

Ça aussi je vais essayer de le mettre noir sur blanc mais la ca se complique...pire !
Donc le lien doit être fait avec le champ N° de bon de commande de la table bon de commande et le champ numéro d'une nouvelle table qui pourrait s'appeler enregistrement des numéros de bon de commande ?

Re
Si on est demandeur, on a un prénom : cela fait partie de l'identité du demandeur et pas d'un choix.
Il est préférable de mettre 2 champs. Mais selon l'utilisation faite, ce n'est pas forcément obligatoire./QUOTE]
PJ pour illustrer mon propos

Re
Tu fais du mind mapping ?

J'essaie aussi, c'est beaucoup plus parlant pour moi, mais aussi rapide

Connaissez vous quelqu'un qui donnerait des cours d'Access ?
Il me manque quelques notions académiques

Merci

 

[chris]

Re : Debut !

Bonjour

Pour la dernière remarque c'était justement pour ne pas avoir à modifier las base mais simplement y rajouter des infos.

Modifier la structure non mais les données on les modifie tout le temps : j'espère que le montant de ton salaire est de temps en temps modifié dans la base paye de ton employeur mais cela ne touche pas à la structure de la base paye.

Donc le lien doit être fait avec le champ N° de bon de commande de la table bon de commande et le champ numéro d'une nouvelle table qui pourrait s'appeler enregistrement des numéros de bon de commande ?

Non !

PJ pour illustrer mon propos

Pas de PJ

 

[bil bool]

Re : Debut !

Autant pour moi !

 

[chris]

Re : Debut !

Bonjour

Pour les demandeurs on a une table de demandeurs.
Plusieurs possibilités.
Tu as un champ nom+prenom et tu l'utilises dans ta table commande qui a donc aussi un seul champ équivalent.
Tu as deux champs.
La clé peut être Nom + prénom.
Dans ce cas tu es obligé de reporter les deux champs dans la table commande.
Mais tu peux simplifier le formulaire en affichant une liste avec les deux infos et en valorisant automatiquement le champ prénom selon le choix effectué. Pas le plus simple en débutant.
Sinon tu ajoutes un champ identifiant (matricule par exemple) dans la table des demandeurs qui devient la clé primaire.
Tu mets donc aussi un champ ID demandeur dans la table commandes (pour la relation) au lien de nom et prénom.
Mais, pour le formulaire, tu peux afficher nom et prénom pour faciliter le choix car l'Id est peu parlant, mais c'est le numéro qui alimentera le champ ID demandeur.
L'assistant formulaire permet de le faire en mode guidé.