Vidéo : Prise en main des bases de données

Pour ne pas perdre de vue l’objectif de votre base de données, faites-en un résumé auquel vous vous reporterez régulièrement. Si vous cherchez à créer une petite base de données pour une activité à domicile, vous pouvez par exemple écrire : « La base de données Clients conserve les informations des clients aux fins de création de publipostages et d’états ». Pour une base de données d’entreprise, vous devrez peut-être rédiger plusieurs paragraphes pour décrire la manière dont les personnes dotées de différents rôles utiliseront la base de données et ses données. Créez un énoncé spécifique et détaillé auquel vous référer tout au long du processus de conception.

Commencez avec vos informations et méthodes de suivi existantes. Par exemple, vous conservez peut-être les bons de commande dans un registre ou les informations des clients sur des formulaires papier. Utilisez ces sources pour répertorier les informations que vous collectez actuellement (par exemple, tous les champs de vos formulaires). Pour les informations que vous ne collectez pas actuellement, pensez aux informations distinctes dont vous avez besoin. Chaque type de données individuel devient un champ dans votre base de données.

Ne vous inquiétez pas de rendre votre première liste parfaite, vous pouvez l’affiner au fil du temps. Mais prenez en compte toutes les personnes qui utilisent ces informations, et demandez leurs idées.

Déterminez ensuite les informations que vous voulez obtenir de la base de données et les types d’états ou de publipostages que vous voulez créer. Veillez à capturer les informations requises pour atteindre ces objectifs. Par exemple, si vous voulez générer un état qui affiche les ventes réalisées par région, vous devez capturer les données de ventes au niveau régional. Essayez de définir l’état dans ses grandes lignes avec les informations réelles tel que vous voudriez le voir. Répertoriez ensuite les données dont vous avez besoin pour créer l’état. Procédez de même pour les publipostages ou les autres sorties que vous voulez obtenir à partir de la base de données.

Exemple

Supposons que vous donnez aux clients la possibilité d’accepter (ou de refuser) les mises à jour périodiques par e-mail, et que vous souhaitez imprimer une liste de ceux qui ont choisi d’y participer. Vous avez besoin d’une colonne Envoyer Email dans la table Customer, avec les valeurs autorisées Oui et Non.

Pour les personnes qui souhaitent recevoir des courriers, vous avez besoin d’une adresse de courrier, ce qui nécessite également un champ. Si vous voulez inclure une salutation (par exemple, M., Mme ou Mlle), vous devez utiliser un champ Salutation. Si vous souhaitez vous adresser aux clients par leur prénom dans les courriers, ajoutez un champ Prénom.

Une fois votre liste des informations requises définie, vous devez déterminer les entités ou sujets principaux dont vous avez besoin pour organiser vos données. Évitez de dupliquer les données au sein des entités. Par exemple, la liste préliminaire d’une base de données destinée à suivre les ventes de produits peut ressembler à ceci :

Les principales entités sont : clients, fournisseurs, produits et commandes. Commencez donc par ces quatre tables : une pour les faits sur les clients, une pour les informations sur les fournisseurs, et ainsi de suite. Il ne s’agit peut-être pas de votre conception finale, mais il s’agit d’un bon point de départ.

Pour comprendre pourquoi il vaut mieux utiliser plus de tables, examinez la table ci-dessous :

Chaque ligne contient des informations sur le produit et son fournisseur. Comme plusieurs produits proviennent du même fournisseur, le nom et les informations d’adresse du fournisseur doivent être répétés autant de fois. Cela mobilise de l’espace sur le disque. Pour y remédier, enregistrez les informations du fournisseur une seule fois dans une table Fournisseurs séparée, puis liez cette table à la table Produits.

Cette conception présente un autre problème si vous êtes amené à modifier les informations sur le fournisseur. Supposons que vous deviez modifier l’adresse d’un fournisseur. Comme elle apparaît à plusieurs emplacements, vous pourriez modifier l’adresse à un emplacement mais oublier de la modifier dans les autres. L’enregistrement de l’adresse du fournisseur dans un seul emplacement permet de résoudre ce problème.

Enfin, supposons qu’un seul produit soit fourni par Coho Winery et que vous vouliez supprimer le produit, mais conserver le nom et les informations d’adresse du fournisseur. Dans cette conception, comment supprimer l’enregistrement du produit sans perdre également les informations du fournisseur ? C’est impossible. Comme chaque enregistrement contient des informations sur un produit et des informations sur un fournisseur, il est impossible de supprimer l’un sans supprimer l’autre. Pour conserver ces informations séparées, vous devez décomposer cette table en deux : une première table permettra de stocker les informations sur les produits, tandis que la seconde permettra de stocker les informations sur les fournisseurs. Par la suite, lorsque vous supprimerez un enregistrement de produit, vous ne supprimerez que les informations sur le produit, et non les informations sur le fournisseur.

Une fois que vous avez choisi le sujet d’une table de base de données, les colonnes de cette table ne doivent stocker que des informations relatives à ce sujet. Par exemple, une table Produits ne doit stocker que des informations sur les produits (et pas sur leurs fournisseurs).

Pour déterminer les informations à suivre dans la table, utilisez la liste que vous avez créée précédemment. Par exemple, la table Clients peut inclure les éléments suivants : Prénom, Nom, Adresse, Envoyer un courrier électronique, Salutations et Adresse de courrier. Chaque enregistrement (client) dans la table contient le même ensemble de colonnes, de telle sorte que vous stockez exactement les mêmes informations pour chaque client.

Créez votre première liste, puis examinez-la et affinez-la. N’oubliez pas de décomposer les informations au sein des champs les plus petits possibles. Par exemple, si votre liste initiale inclut le champ Adresse, décomposez-le en Adresse, Code postal et Ville (ou si vos clients sont disséminés à l’échelle internationale, en davantage de champs). Ainsi, vous pourrez par exemple effectuer des publipostages au format approprié ou créer des états sur les commandes selon leur statut.

Une fois que vous avez affiné les colonnes de données dans chaque table, vous êtes prêt à choisir la clé primaire de chaque table.

Vous avez besoin d’identifier les lignes individuelles de chaque table de façon unique. Vous vous rappelez l’exemple précédent dans lequel deux clients ont le même nom ? Vous avez besoin de les identifier séparément.

Chaque table doit donc inclure une colonne (ou un ensemble de colonnes) qui identifie chaque ligne de manière unique. Il s’agit souvent d’un numéro unique, tel qu’un numéro d’employé ou un numéro de série. Access utilise des clés primaires pour associer rapidement des données de plusieurs tables et rassembler les données pour vous.

La clé primaire est parfois constituée de plusieurs champs. Par exemple, une table Détails de la commande qui stocke les articles des commandes peut utiliser deux colonnes dans sa clé primaire : Réf commande et Réf produit. Lorsqu’une clé primaire utilise plusieurs colonnes, elle est également appelée clé composite.

Si vous avez déjà un identificateur unique pour les informations d’une table, tel que le numéro qui identifie chaque produit dans votre catalogue de façon unique, utilisez-le, mais seulement si les valeurs correspondent à ces règles relatives aux clés primaires :

• L’identificateur est toujours différent pour chaque enregistrement. Les valeurs en double ne sont pas autorisées dans une clé primaire.

• Il existe toujours une valeur pour l’élément. Chaque enregistrement dans la table doit avoir une clé primaire. Si vous utilisez plusieurs colonnes pour créer la clé (par exemple, Type de pièce et Numéro de référence), les deux valeurs doivent toujours être présentes.

• La clé primaire est une valeur qui ne change pas. Comme les clés sont référencées par d’autres tables, le fait de modifier une clé primaire dans une table implique de la modifier également partout ailleurs où elle est référencée. Les modifications fréquentes accroissent le risque d’erreurs.

Si vous n’avez pas d’identificateur évident, utilisez un nombre unique arbitraire comme clé primaire. Par exemple, vous pouvez attribuer un numéro unique à chaque commande dans le seul but de l’identifier.