Maîtriser les Requêtes dans Microsoft Access

Ce nouveau chapitre va nous faire découvrir les requêtes. Pour développer ces exemples, nous utilisons une autre base de données, une base de données exemple qui nous est fournie par Microsoft et qui nous permet de faire des tests ou de nous entraîner au maniement d'Access. Vous la trouverez dans les fichiers de travail joints à ce tutoriel vidéo sous le nom de Access 2016 de Northwind. Northwind est le nom d'une entreprise, fictive bien sûr, qui était connue dans les versions précédentes d'Access sous le nom de Les Comptoirs.

Je vais donc ouvrir la base numéro 2 Northwind par un double clic. La base va s'ouvrir. Vous voyez qu'elle comporte un ensemble de tables et un modèle relationnel qui est déjà conçu. Je vais prendre l'onglet Outils de base de données et dans cet onglet, je clique l'icône des créations. Nous sommes sur un modèle similaire à celui de notre premier exemple. Nous devons gérer au centre des commandes. Ces commandes vont référencer des clients. Ces commandes vont aussi référencer des employés, sans doute les commerciaux qui sont à l'origine de la commande et qui auront droit plus tard à une commission.

Ces commerciaux sont listés dans une table des employés avec leur nom, leur adresse, leur date de naissance, etc. La table des commandes référencie aussi des transporteurs que Microsoft a appelés messagers. Derrière la table des commandes, nous pourrons pour chaque commande donner le détail des produits commandés. La table détails commandes va référencer un numéro de commande et une référence de produit. Chaque produit pourra chercher dans la table des produits le nom du produit, le numéro du fournisseur, le prix unitaire du produit.

La table produits référencie des fournisseurs. La table des fournisseurs nous donnera le détail du fournisseur, son nom, son adresse, etc. Chaque produit appartient aussi à une catégorie. Le produit contient un code catégorie et la table catégorie, la famille de produits, nous donne la description et éventuellement une illustration avec une photo.

Deux remarques. Vous observez que dans la table détails commandes, nous avons la mention d'un prix unitaire et dans la table des produits, nous avons aussi le prix unitaire du produit. Donc, en apparence, un doublon de champ. Ce qui, normalement, doit être absolument évité dans une base de données relationnelles. Il y a toutefois une raison à ce qui apparaît être une erreur. Le prix unitaire, il y a un doublon d'informations puisqu'on me donne le prix côté table produits, côté table détails commandes. Mais en réalité, ce n'est pas le même prix.

Dans la table des produits, le prix unitaire va varier au fil du temps. Par exemple, à partir du 1er novembre, nous aurons une augmentation de tarif et le 1er novembre, nous viendrons modifier ce prix unitaire. Alors que dans la table du détail de la commande, ce prix unitaire sera automatiquement recopié depuis la table produits lors de la passation de la commande. Mais ensuite, il ne bougera plus. Le prix unitaire sera ainsi figé à sa valeur au jour de la prise de commande. Cette recopie ne sera pas vraiment automatique. Nous devrons mettre en place une macro qui assurera de façon automatique le report du prix unitaire pour éviter à l'utilisateur le soin de le ressaisir lui-même.

Deuxième remarque. Peut-être une erreur de conception. Vous observez que la table produits comporte un numéro de fournisseur qui renvoie bien sûr à la table fournisseur. Cela signifie que pour un produit déterminé, nous ne pourrons avoir qu'un seul fournisseur. Sinon, il faudrait dans la table produits dupliquer des références produits identiques, ce qui bien sûr est impossible. Le numéro fournisseur dans la table produits est bien d'un côté multiple, mais tout simplement parce que plusieurs produits peuvent avoir le même fournisseur. Mais concrètement, nous n'avons place que pour un seul numéro de fournisseur pour chaque enregistrement. Donc, un produit n'aura qu'un seul fournisseur unique.