Concepts de base sur la conception d'une base de données

Une base de données conçue avec précision permet d'accéder à des informations à jour et exactes. Parce qu'une conception correcte est essentielle à la réalisation de vos objectifs et à l'utilisation de la base de données, l'investissement en temps nécessaire à l'apprentissage des concepts de création est très important. Vous aurez ainsi la garantie que la base de données conçue répond à vos besoins et peut évoluer.

Cet article présente des conseils pour la planification d'une base de données. Vous apprendrez à faire le tri parmi les informations qui vous sont nécessaires, à répartir les informations entres les tables et les colonnes et à établir un lien entre les tables. Il est conseillé de lire cet article avant de commencer à créer votre première base de données.

Dans cet article


Terminologie relative aux bases de données

Microsoft Office Access 2007 organise les informations en tables : listes de lignes et de colonnes, rappelant les livres de comptabilité ou les feuilles de calcul Microsoft Office Excel 2007. Dans une base de données simple, vous pouvez avoir une seule table. Pour la plupart des bases de données, vous aurez besoin d'utiliser plusieurs tables. Par exemple, vous pouvez utiliser une table qui stocke des informations sur des produits et une autre table qui stocke des informations sur des commandes et une autre encore contenant des informations sur les clients.

Image illustrant trois tables dans des feuilles de données

Chaque ligne est également appelée « enregistrement » et chaque colonne est également appelée « champ ». Un enregistrement est un moyen cohérent de combiner des informations portant sur un élément précis. Un champ est un élément d'information unique qui figure dans chaque enregistrement. Dans la table des produits, par exemple, chaque ligne ou enregistrement contient des informations sur un produit en particulier. Chaque colonne ou champ contient un certain type d'information sur ce produit, comme son nom ou son prix.

Haut de la page Haut de la page

Critères d'une base de données bien conçue

Certains principes guident le processus de création d'une base de données. Le premier principe est celui relatif aux données dupliquées également appelées données redondantes et qui doivent être évitées car cela consomme de l'espace et augmente la probabilité de l'apparition d'erreurs et d'incohérences. Le deuxième principe concerne l'exactitude des informations. Si votre base de données contient des informations incorrectes, les états qui utilisent ces informations contiendront également des informations incorrectes. Par conséquent, toutes les décisions que vous prendrez après avoir consulté ces états seront établies sur la base d'informations erronées.

Une base de données bien conçue est une base de données qui :

  • Répartit les informations dans des tables dédiées à des sujets précis afin d'éviter la redondance des données.
  • Fournit à Access les informations nécessaires pour lier les informations dans les tables.
  • Garantit l'exactitude et l'intégrité des informations.
  • Répond à vos besoins en termes de traitement des données et de création d'états.

Haut de la page Haut de la page

Le processus de conception

Le processus de conception se compose des étapes suivantes :

  • Déterminer les objectifs de la base de données    

Cette étape vous aide à vous préparer pour les étapes restantes.

  • Rechercher et organiser les informations requises    

Rassembler tous les types d'informations que vous souhaitez stocker dans la base de données, tels que les noms de produit et les numéros de commande.

  • Répartir les informations dans des tables    

Répartissez vos éléments d'information en entités ou sujets principaux, tels que Produits ou Commandes. Chaque sujet devient ensuite une table.

  • Convertir des éléments d'information en colonnes    

Choisissez les informations que vous souhaitez stocker dans chaque table. Chaque élément d'information devient un champ et est affiché sous la forme d'une colonne dans la table. Par exemple, une table Employés peut contenir des champs du type Nom et Date d'embauche.

  • Définir des clés primaires    

Choisissez la clé primaire de chaque table. La clé primaire est une colonne qui sert à identifier de façon unique chaque ligne par exemple, une colonne Numéro de produit ou Numéro de commande.

  • Définir les relations entre tables    

Étudiez chaque table et déterminez de quelle façon les données d'une table sont liées aux données des autres tables. Ajoutez des champs aux tables ou créez de nouvelles tables pour clarifier les relations, le cas échéant.

  • Affiner la structure    

Analysez votre conception et recherchez les erreurs qu'elle peut contenir. Créez les tables et ajoutes des enregistrements contenant des données exemple. Vérifiez si vous obtenez les résultats attendus des tables créées. Apportez des modifications en conséquence.

  • Appliquer les règles de normalisation     

Appliquez les règles de normalisation des données pour vérifier si vos tables sont structurées correctement. Si nécessaire, apportez des modifications.

Haut de la page Haut de la page

Déterminer les objectifs d'utilisation de la base de données

Il est conseillé de noter par écrit l'objectif de la base de données : à quoi va-t-elle servir, comment souhaitez-vous l'utiliser et qui l'utilisera. Dans le cas d'une base de données de petite taille conçue pour une utilisation domestique, vous pouvez noter quelque chose du type : la base de données contient des informations relatives aux clients, lesquelles permettront de réaliser des publipostages et de créer des états. Si la base de données est plus complexe et si elle est utilisée par plusieurs personnes, ce qui est souvent le cas dans les entreprises, l'objectif peut facilement être exprimé dans un ou plusieurs paragraphes et il doit préciser à quel moment la base de données sera utilisée et comment chaque personne devra l'utiliser. Le but étant de fournir un exposé le plus précis possible auquel il pourra être fait référence tout au long du processus de conception. Une fois cet exposé établi, il vous est ensuite possible de vous concentrer sur les objectifs à atteindre lorsque vous devez prendre des décisions.

Haut de la page Haut de la page

Rechercher et organiser les informations requises

Pour rechercher et organiser les informations nécessaires, commencez par les informations existantes. Par exemple, si vous conservez vos bons de commande dans un registre ou si vous conservez les informations client sur des formulaires papier classés dans une armoire, rassemblez ces documents et établissez la liste de chaque type d'information (par exemple, de chaque zone à compléter dans les formulaires). Si vous ne possédez aucun formulaire, imaginez alors que vous devez en concevoir un pour enregistrer les informations client. Quelles informations envisageriez-vous de noter sur ce formulaire ? Quelles cases souhaiterez-vous créer ? Identifiez chacun de ces éléments et établissez-en la liste. Supposez par exemple que la liste de vos clients se présente actuellement sous la forme de fichez. Si vous étudiez ces fiches, vous constaterez qu'elles mentionnent toutes un nom, une adresse, une ville, un code postal et un numéro de téléphone. Chacun de ces éléments peut constituer une colonne potentielle dans une table.

Lorsque vous préparez cette liste, ne vous préoccupez pas encore de sa perfection. Préoccupez-vous plutôt d'établir la liste de chaque élément qui vous vient à l'esprit. Si d'autres personnes doivent utiliser la base de données, suggérez-leur de vous donner des idées. Vous pourrez affiner cette liste ultérieurement.

Penchez-vous ensuite sur le type d'états ou de publipostages que vous souhaitez créer à partir de la base de données. Par exemple, vous pouvez envisager de créer un état des ventes montrant les ventes par région ou un état du stock qui montre les niveaux du stock par produit. Vous pouvez également souhaiter générer des lettres à envoyer aux clients pour leur annoncer un événement commercial ou une promotion. Imaginez à quoi pourrait ressembler cet état. Quelles informations doivent y figurer ? Établissez une liste contenant chaque élément. Procédez de la même façon pour les lettres et pour tout autre état que vous envisagez de créer.

Une personne imaginant un état pour un stock

Le fait de réfléchir aux états et aux publipostages que vous souhaitez créer, vous permet d'identifier les éléments dont vous aurez besoin dans votre base de données. Supposez par exemple, que vous offrez aux clients la possibilité de recevoir ou non des mises à jour périodiques par courrier électronique et que vous souhaitez imprimer le listing des clients qui ont opté pour la réception de cette mise à jour. Pour enregistrer cette information, vous ajoutez une colonne « Envoyer courrier électronique » dans la table des clients. Pour chaque client, vous pouvez affecter la valeur Oui ou Non.

La nécessité d'envoyer des messages électroniques aux clients implique d'enregistrer un autre élément d'information. Une fois que vous avez enregistré le fait qu'un client souhaite être averti par message électronique, vous devez vous procurer son adresse de messagerie. Par conséquent, vous devez enregistrer une adresse de messagerie pour chaque client.

Il convient de créer un prototype pour chaque état ou listing et de se pencher sur les éléments d'information nécessaires pour les produire. Par exemple, lorsque vous réfléchissez à la lettre type, plusieurs choses vont vous venir à l'esprit. Vous souhaiterez certainement y faire figurer une salutation — et par exemple, une chaîne du type « M. », « Mme » ou « Melle ». Vous devrez donc créer un élément de salutation. Par ailleurs, vous souhaiterez également commencer la lettre par « Cher M. Dupont » et non par « Cher M. Jean Dupont ». Cela signifie donc que vous devrez stocker le nom de famille séparément du prénom.

Il est important de noter que les informations doivent être scindées en plusieurs parties utiles. Dans le cas d'un nom, pour faire en sorte de pouvoir utiliser uniquement le nom, vous diviserez le nom en deux parties — le prénom et le nom. Afin de trier un état par nom par exemple, il est utile de stocker le nom des clients séparément. En règle générale, si vous souhaitez trier, rechercher, calculer ou créer des états basés sur un élément d'information seulement, vous devez stocker cet élément dans un champ qui lui est propre.

Établissez la liste des questions auxquelles vous souhaitez répondre en vous aidant de la base de données. Par exemple, à quel montant s'élèvent les ventes de votre produit vedette en clôture le mois dernier ? Quel est le lieu d'habitation de vos meilleurs clients ? Qui est le fournisseur du produit qui enregistre les meilleures ventes ? En anticipant ainsi, vous pourrez réduire le nombre d'éléments à ajouter dans la base de données.

Une fois ces informations collectées, vous êtes prêt à passer à l'étape suivante.

Haut de la page Haut de la page

Répartir des informations dans des tables

Pour répartir les informations dans des tables, vous devez décider quels sont les entités et les sujets principaux. Par exemple, après avoir collecté et organisé les informations pour une base de données dans laquelle sont enregistrées les ventes de produits, la liste de départ pourrait ressembler à ce qui suit :

Notes manuscrites concernant les éléments d'informations regroupés en sujets

Les entités principales notées ici sont : les produits, les fournisseurs, les clients et les commandes. Il est par conséquent logique de commencer avec quatre tables pour stocker les faits concernant les produits, les fournisseurs, les clients et les commandes. Bien que cela ne suffise pas à créer une liste complète, c'est un point de départ. Vous pouvez continuer à affiner cette liste jusqu'à ce que vous soyez satisfait du modèle obtenu.

Lorsque vous consultez cette première liste, vous pouvez être tenté de placer tous les éléments d'informations dans une seule et même table au lieu de les stocker dans quatre tables comme le montre l'illustration précédente. Vous allez apprendre ici pourquoi cette idée est mauvaise. Penchez-vous un moment sur la table représentée ici :

Image illustrant une table contenant des produits et des fournisseurs

Dans le cas présenté ici, chaque ligne contient des informations relatives à la fois à un produit et à ses fournisseurs. Étant donné que vous pouvez avoir plusieurs produits pour un même fournisseur, le nom et l'adresse de ce fournisseur devront être répétés plusieurs fois, ce qui utilise de l'espace disque inutilement. En enregistrant les informations du fournisseur une seule fois dans une table distincte appelée Fournisseurs et en liant cette table à la table Produits, vous adoptez une bien meilleure solution.

Le deuxième problème que pose votre conception est lié à la modification des informations des fournisseurs. Supposez par exemple, que vous deviez modifier l'adresse d'un fournisseur. Cette adresse étant répétée en plusieurs endroits, vous risquez de la modifier dans une table et d'oublier de la modifier dans les autres. Ce problème est éliminé si vous enregistrez l'adresse dans une seule table.

Lorsque vous concevez votre base de données, essayez toujours d'enregistrer chaque fait une seule fois. Si vous constatez que vous répétez une même information dans plusieurs endroits, telle que l'adresse d'un fournisseur, placez cette information dans une table distincte.

Enfin, supposez qu'un seul produit soit fourni par Le Cru Coho et que vous souhaitiez supprimer le produit tout en conservant le nom et l'adresse du fournisseur. Comment pourrez-vous supprimer le produit sans perdre également les informations relatives au fournisseur ? Vous ne pourrez pas. Étant donné que chaque enregistrement contient des faits sur un produit et des faits sur un fournisseur, vous ne pouvez pas en supprimer un sans supprimer l'autre. Pour que ces faits soient séparés, vous devez diviser la table en deux : une table pour les informations produit et une table pour les informations fournisseur. La suppression d'un produit entraînera uniquement la suppression des faits concernant ce produit et non les faits concernant le fournisseur.

Une fois que vous avez choisi le sujet qu'une table doit représenter, les colonnes de cette table doivent alors stocker des faits concernant uniquement ce sujet. Par exemple, la table des produits doit stocker des faits sur des produits. Étant donné que l'adresse d'un fournisseur est un fait concernant un fournisseur et non un fait concernant un produit, elle doit être stockée dans la table des fournisseurs.

Haut de la page Haut de la page

Convertir des éléments d'information en colonnes

Afin de déterminer quelles colonnes doivent constituer une table, vous devez choisir les informations que vous souhaitez suivre concernant le sujet enregistré dans la table. Par exemple, la table Clients peut être constituée, pour commencer, des colonnes Nom, Adresse, Ville, Code postal, Envoyer courrier électronique, Salutation et Adresse de messagerie. Chaque enregistrement de la table contient le même jeu de colonnes et vous pouvez donc stocker les informations Nom, Adresse, Ville, Code postal, Envoyer courrier électronique, Salutation et Adresse de messagerie pour chaque enregistrement. Par exemple, la colonne Adresse contient les adresses du client. Chaque enregistrement contient des données sur un seul client et le champ d'adresse contient l'adresse de ce client.

Une fois que vous avez déterminé le premier jeu de colonnes pour chaque table, vous pouvez affiner davantage les colonnes. Par exemple, cela a plus de sens de stocker le nom du client dans deux colonnes distinctes : Nom et Prénom, ce qui permet d'appliquer un tri, d'effectuer des recherches ou d'indexer une colonne seulement. De la même façon, comme l'adresse se compose de quatre éléments séparés (l'adresse, la ville, le code postal et le pays), il est logique de stocker ces éléments dans des colonnes distinctes. Si vous souhaitez effectuer une recherche, appliquer un filtre ou un tri par ville par exemple, vous devrez nécessairement stocker cet élément d'information dans une colonne séparée.

Vous devez également vous demander si les informations stockées dans la base de données seront uniquement locales ou également internationales. Par exemple, si vous envisagez de stocker des adresses internationales, il est préférable de créer une colonne Zone géographique plutôt qu'une colonne Département car il vous sera ainsi possible de stocker à la fois des informations concernant les départements et les régions d'autres pays.

La liste suivante présente des conseils pour vous aider à déterminer les colonnes qui constitueront votre base de données.

  • Ne pas inclure de données calculées    

Dans la majorité des cas, il est conseillé de ne pas stocker le résultat de calculs dans les tables. Vous devez au contraire laisser Access effectuer ces calculs. Supposez par exemple, qu'un état Produits en commande affiche le sous-total des unités en commande pour chaque catégorie de produit stockée dans la base de données et qu'il n'existe cependant aucune colonne Sous-total des unités en commande dans aucune des tables, mais qu'il existe par contre dans la table Produits, une colonne Unités en commande qui stocke les unités en commande pour chaque produit. Access utilise ces données pour calculer le sous-total demandé à chaque fois que vous imprimez cet état. Le sous-total lui-même ne doit pas être stocké dans une table.

  • Stocker la plus petite partie logique d'information    

Vous pouvez être tenté de stocker dans un seul et même champ des noms complets de personnes ou des noms de produits et leurs descriptions. Si vous combinez plusieurs types d'informations dans un même champ, il sera difficile par la suite d'extraire des faits individuellement. Essayez donc de décomposer les informations en parties logiques et créez par exemple des champs séparés pour le nom et le prénom ou pour le nom du produit, sa catégorie et sa description.

Liste d'éléments d'information au cours du processus de création

Une fois que vous avez atteint un degré de précision suffisant pour les colonnes de données des tables, vous êtes prêt à choisir la clé primaire de chaque table.

Haut de la page Haut de la page

Définir des clés primaires

Chaque table contient une colonne ou un jeu de colonnes qui identifie de façon unique chaque ligne stockée dans la table. Il s'agit souvent d'un numéro d'identification unique tel qu'un numéro d'employé ou un numéro de série. Dans la terminologie des bases de données, cette information est appelée clé primaire de la table. Access utilise des champs de clés primaires pour associer rapidement des données issues de plusieurs tables et pour les rassembler pour votre usage.

Si vous utilisez déjà un identificateur unique pour une table, tel qu'un numéro de produit qui identifie de façon unique chaque produit d'un catalogue, vous pouvez l'utiliser comme clé primaire de la table — mais uniquement si les valeurs de cette colonne seront toujours différentes pour chaque enregistrement. Une clé primaire ne peut pas contenir de valeurs en double. Par exemple, n'utilisez pas des noms de personnes comme clé primaire car les noms ne sont pas uniques. Il est courant de compter dans la même table deux personnes portant le même nom.

Une clé primaire doit toujours contenir une valeur. Si la valeur d'une colonne risque à un moment donné de ne plus être attribuée ou d'être inconnue (valeur manquante), elle ne pourra pas être utilisée en tant que composant dans une clé primaire.

Il est conseillé de toujours choisir une clé primaire dont la valeur ne sera pas amenée à changer. Dans une base de données contenant plusieurs tables, la clé primaire d'une table peut être utilisée comme référence dans les autres tables. Si la clé primaire est modifiée, la modification doit être apportée dans l'ensemble des tables dans lesquelles elle est référencée. Le fait d'utiliser une clé primaire qui ne doit pas changer, réduit le risque que cette clé primaire ne soit plus synchronisée avec les autres tables dans lesquelles elle est référencée.

Les numéros uniques arbitraires sont souvent utilisés comme clé primaire. Vous pouvez par exemple, attribuer à chaque commande un numéro de commande unique, l'objectif unique de ce numéro de commande étant d'identifier une commande. Une fois attribué, ce numéro ne change jamais.

Si vous ne pensez à aucune colonne ou ensemble de colonnes en particulier pouvant être utilisé comme clé primaire, envisagez d'utiliser une colonne dont les données sont du type NuméroAuto. Lorsque vous utilisez le type de données NuméroAuto, Access attribue automatiquement une valeur à votre place. Un identificateur de ce type n'est lié à aucun fait ; il ne contient aucune information factuelle décrivant la ligne qu'il représente. Ces identificateurs conviennent parfaitement comme clé primaire car ils ne changent pas. Une clé primaire qui contient des faits relatifs à une ligne — un numéro de téléphone ou un nom de client par exemple — est plus susceptible de changer, car les informations factuelles peuvent changer.


Image illustrant la table Produits avec un champ de clé primaire

Légende 1 Une colonne dont le type de données est NuméroAuto peut souvent servir de clé primaire. Aucun numéro de produit n'est identique.

Dans certains cas, vous pourrez souhaiter utiliser plusieurs champs pour constituer la clé primaire d'une table. Par exemple, une table Détails des commandes qui stocke des articles pour des commandes pourra utiliser deux colonnes dans sa clé primaire : la colonne Numéro de commande et la colonne Numéro de produit. Lorsqu'une clé primaire se compose de plusieurs colonnes, on parle de clé composite.

Pour la base de données dans laquelle sont enregistrées les ventes de produits, vous pouvez créer une colonne NuméroAuto pour chaque table devant être utilisée comme clé primaire : Numéro de produit pour la table Produit, Numéro de commande pour la table Commande, Numéro de client pour la table Clients et Numéro de fournisseur pour la table Fournisseurs.

Image montrant des éléments d'information au cours de processus de conception

Haut de la page Haut de la page

Créer les relations entre tables

Maintenant que vous avez réparti vos informations dans des tables, vous devez trouver le moyen de les rassembler de façon cohérente. Le formulaire suivant inclut par exemple des informations issues de plusieurs tables.


Le formulaire Commandes

Légende 1 Les informations de ce formulaire proviennent de la table Clients...
Légende 2 ...de la table Employés...
Légende 3 ...de la table Commandes...
Légende 4 ...de la table Produits...
Légende 5 ...et de la table Détails des commandes.

Access est un système de gestion de base de données relationnelles. Dans une base de données relationnelles, les informations sont réparties dans des tables séparées, basées sur des sujets. Les relations entre les tables servent ensuite à rassembler les informations, selon les besoins.

Haut de la page Haut de la page

Création d'une relation un-à-plusieurs

Penchez-vous sur cet exemple : les tables Fournisseurs et Produits de la base de données des commandes de produits. Un fournisseur peut fournir n'importe quel nombre de produits. Par conséquent, pour tout fournisseur représenté dans la table Fournisseurs, il peut exister plusieurs produits représentés dans la table Produits. La relation entre la table Fournisseurs et la table Produits est donc une relation un-à-plusieurs.

Relation un-à-plusieurs

Pour représenter une relation un-à-plusieurs dans votre base de données, prenez la clé primaire du côté « un » de la relation et ajoutez-la comme colonne supplémentaire dans la table du côté « plusieurs » de la relation. Dans ce cas par exemple, vous ajouteriez la colonne Numéro de fournisseur de la table Fournisseurs dans la table Produits. Access peut ensuite utiliser le numéro d'identification de la table Produits pour trouver le fournisseur correspondant à chaque produit.

La colonne Numéro de fournisseur dans la table Produits est appelée une clé étrangère. Une clé étrangère est la clé primaire d'une autre table. La colonne Numéro de fournisseur de la table Produits est dite clé étrangère car elle est également la clé primaire dans la table Fournisseurs.

Liste d'éléments d'information au cours du processus de création

Pour joindre des tables liées, vous devez établir des paires de clés primaires et de clés étrangères. Si vous ne savez pas exactement quelles tables doivent partager une colonne commune, identifiez une relation un-à-plusieurs pour vous assurer que les deux tables concernées nécessitent en effet une colonne partagée.

Haut de la page Haut de la page

Création d'une relation plusieurs-à-plusieurs

Prenez l'exemple d'une relation entre une table Produits et une table Commandes.

Une commande peut porter sur plusieurs produits et un même produit peut figurer dans plusieurs commandes. Par conséquent, pour un enregistrement dans la table Commandes, il peut en exister plusieurs dans la table Produits et pour un enregistrement dans la table Produits, il peut en exister plusieurs dans la table Commandes. Ce type de relation est appelée une relation plusieurs-à-plusieurs car pour un produit, il peut exister plusieurs commandes et à une commande, peuvent correspondre plusieurs produits. Notez que pour déterminer la présence de relations plusieurs-à-plusieurs entre des tables, il est important d'étudier les deux côtés de la relation.

Les sujets des deux tables — commandes et produits — sont liées par une relation plusieurs-à-plusieurs. Cela pose un problème. Pour comprendre ce problème, imaginez ce qu'il se passerait si vous tentiez de créer une relation entre ces deux tables en ajoutant le champ Numéro de produit dans la table Commandes. Pour avoir plusieurs produits par commande, vous devez avoir plusieurs enregistrements par commande dans la table Commandes. Il vous faudra alors répéter les informations de la commande pour chaque ligne des commandes, ce qui aboutira à des tables inefficaces et risquera de poser des problèmes d'inexactitude des données. Le même problème se posera si vous placez le champ Numéro de commande dans la table Produits — vous aurez plusieurs enregistrements dans la table Produits pour chaque produit. Comment pourrez-vous contourner ce problème ?

La solution consiste à créer une troisième table, souvent appelée une table de jointure, qui scinde la relation plusieurs-à-plusieurs en deux relations un-à-plusieurs. Vous devez ajouter la clé primaire de chacune des deux tables dans la troisième table. La troisième table stocke ainsi chaque occurrence ou instance de la relation.

Relation plusieurs-à-plusieurs

Chaque enregistrement dans la table Détails de la commande représente un article d'une commande. La clé primaire de la table Détails de la commande compte deux champs — les clés étrangères des tables Commandes et Produits. L'utilisation du champ Numéro de commande seul, ne convient pas comme clé primaire pour cette table, car une même commande peut compter plusieurs articles. Le numéro de commande est répété pour chaque article d'une commande et le champ ne contient donc pas de valeurs uniques. L'utilisation du champ Numéro de produit seul ne convient pas non plus car un produit peut figurer dans plusieurs commandes différentes. Ensemble cependant, ces deux champs produisent toujours une valeur unique pour chaque enregistrement.

Dans la base de données dans laquelle sont enregistrées les ventes de produits, la table Commandes et la table Produits ne sont pas liées l'une à l'autre directement. Elles sont au contraire liées indirectement par l'intermédiaire de la table Détails de la commande. La relation plusieurs-à-plusieurs entre les commandes et les produits est représentée dans la base de données en utilisant deux relations un-à-plusieurs :

  • La table Commandes et la table Détails de la commande sont liées par une relation un-à-plusieurs. Chaque commande peut porter sur plusieurs articles, mais chaque article est lié à une seule commande.
  • La table Produits et la table Détails de la commande sont liées par une relation un-à-plusieurs. Chaque produit peut être associé à plusieurs articles, mais chaque article correspondant à un seul produit.

À partir de la table Détails de la commande, vous pouvez déterminer tous les produits qui doivent figurer sur une commande en particulier. Vous pouvez également déterminer toutes les commandes réalisées pour un produit en particulier.

Lorsque la table est intégrée à la table Détails de la commande, la liste des tables et des champs peut ressembler à ce qui suit :

Liste d'éléments d'information au cours du processus de création

Haut de la page Haut de la page

Création d'une relation un-à-un

Il existe un autre type de relation, la relation un-à-un. Supposez par exemple, que vous deviez enregistrer d'autres informations complémentaires très spécifiques pour un produit et que vous utiliserez rarement ces informations ou qu'elles ne concerneront que quelques produits. Étant donné que vous n'aurez pas souvent besoin de ces informations et que leur enregistrement dans la table Produits impliquerait la présence d'espaces vides pour les produits auxquels elles ne s'appliquent pas, vous placerez ces informations dans une table distincte. Tout comme pour la table Produits, vous utilisez la colonne Numéro de produit comme clé primaire. La relation entre cette table supplémentaire et la table Produits est une relation un-à-un. Pour chaque enregistrement dans la table Produits, il existe un seul enregistrement dans la table supplémentaire. Lorsque vous identifiez une relation de ce type, les deux tables doivent partager un champ commun.

Lorsque vous déterminez le besoin d'établir une relation un-à-un dans votre base de données, demandez-vous si vous pouvez placer dans une même table les informations des deux tables. Vous pouvez ne pas souhaiter procéder ainsi pour une raison quelconque par exemple, parce que cela créerait trop d'espaces vides. Voici comment vous pouvez représenter cette relation :

  • Si les deux tables possèdent le même sujet, vous pouvez probablement établir la relation en utilisant la même clé primaire dans les deux tables.
  • Si les deux tables possèdent des sujets différents avec des clés primaires différentes, choisissez l'une des tables et ajoutez sa clé primaire dans l'autre table en tant que clé étrangère.

En déterminant les relations qui existent entre des tables, vous vous assurez par là-même que vous disposez des tables et des colonnes appropriées. Lorsqu'une relation un-à-un ou un-à-plusieurs existe, les tables impliquées doivent partager une ou plusieurs colonnes en commun. Lorsqu'une relation plusieurs-à-plusieurs existe, une troisième table est nécessaire pour représenter la relation.

Haut de la page Haut de la page

Affiner la structure

Une fois que vous avez créé les tables, les champs et les relations nécessaires, vous devez remplir vos tables de données exemple pour tester leur fonctionnement : créer des requêtes, ajouter des enregistrements, etc. Ces tests permettent de mettre en évidence les éventuels problèmes — vous pourrez par exemple découvrir à cette occasion que vous devez ajouter une colonne que vous avez oubliée d'ajouter au moment de la conception ou bien que vous devez scinder une table en deux pour supprimer des doublons.

Utilisez la base de données pour vérifier si vous obtenez les réponses attendues. Créez des formulaires et des états brouillons et vérifiez s'ils contiennent les données attendues. Recherchez les doublons inutiles et si vous en trouvez, modifiez la conception de votre base de données pour les éliminer.

Lors des essais de votre première base de données, vous découvrirez certainement des occasions pour apporter des améliorations. Voici quelques éléments à vérifier :

  • N'avez-vous oublié aucune colonne ? Si oui, demandez-vous si les informations appartiennent aux tables existantes ? Si ces informations concernent d'autres sujets, vous devrez peut-être créer une autre table. Créez une colonne pour chaque élément d'information nécessaire. Si les données ne peuvent pas être calculées à partir d'autres colonnes, vous aurez très probablement besoin d'une nouvelle colonne.
  • Certaines colonnes ne sont-elles pas inutiles puisqu'elles peuvent être calculées à partir de champs existants ? Si un élément d'information peut être calculé à partir d'autres colonnes existantes — une remise calculée à partir d'un prix au détail par exemple — il est généralement préférable de le calculer au lieu de créer une nouvelle colonne.
  • Répétez-vous la saisie de données dans l'une de vos tables ? Si oui, vous avez probablement besoin de scinder votre table en deux tables liées par une relation un-à-plusieurs.
  • Possédez-vous des tables contenant plusieurs champs, un nombre limité d'enregistrements et beaucoup de champs vides dans certains enregistrements ? Si oui, envisagez de reconcevoir la table de façon à ce qu'elle contienne moins de champs et plus d'enregistrements.
  • Les éléments d'information ont-ils été divisés en petites parties logiques ? Si vous devez créer des états, effectuer des tris, des recherches ou des calculs sur un élément d'information en particulier, placez-le dans une colonne qui lui est propre.
  • Chaque colonne contient-elle un fait sur le sujet de la table ? Si une colonne ne contient pas d'informations sur le sujet de la table, cela signifie qu'elle doit appartenir à une autre table.
  • Les relations entre les tables sont-elles bien toutes représentées soit par des champs en commun, soit par une troisième table ? Les relations un-à-un et un-à-plusieurs impliquent l'existence de colonnes communes. Les relations plusieurs-à-plusieurs nécessitent une troisième table.

Affinement de la table Produits

Supposez les produits de la base de données enregistrant les ventes de produits appartiennent tous à une catégorie générale du type Boissons, Condiments ou Fruits de mer. La table Produits peut inclure un champ qui indique la catégorie de chaque produit.

Supposez qu'après avoir étudié puis affiné la conception de la base de données, vous décidez de stocker une description de la catégorie en plus de son nom. Si vous ajoutez un champ Description de la catégorie dans la table Produits, vous devrez répéter la description de la catégorie pour tous les produits qui appartiennent à cette catégorie et cette solution n'est pas idéale.

La meilleure solution consiste à définir la catégorie comme sujet de la base de données et de lui dédier sa propre table avec sa propre clé primaire. Vous pouvez ensuite ajouter la clé primaire de la table Catégories dans la table Produits, en tant que clé étrangère.

Les tables Catégories et Produits sont liées par une relation un-à-plusieurs : une catégorie peut inclure plusieurs produits, mais un produit peut appartenir à une seule catégorie.

Lorsque vous passez en revue la structure de vos tables, recherchez les groupes qui se répètent. Prenez l'exemple d'une table qui contient les colonnes suivantes :

  • Numéro de produit
  • Nom
  • Numéro de produit 1
  • Nom 1
  • Numéro de produit 2
  • Nom 2
  • Numéro de produit 3
  • Nom 3

Ici, chaque produit correspond à un groupe de colonnes qui diffère des autres uniquement par le numéro ajouté à la fin du nom de colonne. Si vous trouvez des colonnes numérotées de cette façon, vous devez modifier la conception de votre base de données.

Une conception de ce type présente plusieurs imperfections. Tout d'abord, elle oblige à définir une limite supérieure dans le nombre de produits. Dès que cette limite est dépassée, vous devez ajouter un nouveau groupe de colonnes à la structure de tables, ce qui représente une tâche administrative lourde.

Cette conception pose un autre problème car il y aura une perte d'espace pour les fournisseurs pour lesquels existe un nombre de produits maximal inférieur, puisque les colonnes supplémentaires seront vides. Le problème le plus important que pose cette conception est qu'il est difficile d'effectuer un grand nombre de tâches telles que le tri ou l'indexation de la table par numéro ou non de produit.

Dès que vous constatez que des groupes sont répétés, repassez attentivement la conception en revue et envisagez de scinder la table en deux. Dans l'exemple ci-dessus, il est préférable d'utiliser deux tables, une pour les fournisseurs et une pour les produits, liées par numéro de fournisseur.

Haut de la page Haut de la page

Appliquer les règles de normalisation

Vous pouvez ensuite appliquer des règles de normalisation des données (parfois appelées simplement « règles de normalisation »). Ces règles permettent de s'assurer que la structure des tables est correcte. Le processus qui consiste à appliquer des règles à la conception de la base de données est appelé « normalisation de la base de données » ou simplement « normalisation ».

Il est particulièrement utile d'appliquer une normalisation après avoir représenté tous les éléments d'informations et après avoir atteint une conception préliminaire. L'idée étant de s'assurer que vous avez réparti les éléments d'informations dans les tables appropriées. Ce que ne permet pas la normalisation, c'est de s'assurer que vous disposez de tous les éléments d'information nécessaires.

Les règles s'appliquent successivement, à chaque étape pour s'assurer que votre conception a bien atteint les formes connues sous le nom de « formes normales ». On reconnaît cinq formes normales. Cet article décrit les trois premières car il s'agit de celles qui sont nécessaires pour la majorité des bases de données.

Première forme normale

La première forme normale établit qu'à l'intersection entre chaque ligne et chaque colonne de la table, il existe une valeur unique et jamais une liste de valeurs. Par exemple, vous ne pouvez pas avoir un champ appelé Tarif si vous y placez plusieurs prix. Représentez-vous chaque intersection de lignes et de colonnes comme une cellule ne pouvant contenir qu'une seule valeur.

Deuxième forme normale

La deuxième forme normale est atteinte si chaque colonne non clé est entièrement dépendante de toute la clé primaire et pas uniquement d'une partie de la clé. Cette règle s'applique lorsque la clé primaire est composée de plusieurs colonnes. Par exemple, supposez que vous disposez d'une table contenant les colonnes suivantes et où les colonnes Numéro de commande et Numéro de produit forment la clé primaire :

  • Numéro de commande (clé primaire)
  • Numéro de produit (clé primaire)
  • Nom de produit

Cette conception viole la deuxième forme normale car la colonne Nom de produit est dépendante de la colonne Numéro de produit mais non de la colonne Numéro de commande et elle n'est donc pas dépendante de toute la clé primaire. Vous devez supprimer la colonne Nom de produit de la table. Elle appartient à une autre table (Produits).

Troisième forme normale

La troisième forme normale nécessite non seulement que les colonnes non clé soient dépendantes de toute la clé primaire, mais aussi qu'elles soient indépendantes les unes des autres.

Pour le formuler autrement, chaque colonne non clé doit être dépendante de la clé primaire et de rien d'autre que la clé primaire. Supposez par exemple, que vous disposiez d'une table contenant les colonnes suivantes :

  • Numéro de produit (clé primaire)
  • Nom
  • Prix de vente conseillé
  • Remise

Considérez que la colonne Remise dépend de la colonne Prix de vente conseillé. Cette table ne respecte pas la troisième forme normale car une colonne non clé, Remise, est dépendante d'une autre colonne non clé, la colonne Prix de vente conseillé. L'indépendance des colonnes implique que vous devez pouvoir modifier une colonne non clé sans incidence sur les autres colonnes. Si vous modifiez une valeur dans la colonne Prix de vente conseillé, la colonne Remise se modifie en conséquence et viole ainsi cette règle. Dans ce cas, la colonne Remise doit être déplacée dans une autre table qui est indexée à la colonne Prix de vente conseillé.

Haut de la page Haut de la page

Informations complémentaires

Pour plus d'informations sur les concepts de base sur la conception d'une table, voir l'article Création de tables dans une base de données.

Pour plus d'informations sur la conception d'une base de données, consultez les ouvrages suivants :

  • Hernandez, Michael J. Database Design for Mere Mortals: A Hands-On Guide to Relational Database Design, Second Edition. Addison-Wesley Professional. 2003.
  • Fleming, Candace C. von Halle, Barbara. Handbook of Relational Database Design. Addison-Wesley Professional. 1989.
  • Riordan, Rebecca M. Designing Effective Database Systems. Addison-Wesley Professional. 2005.

Haut de la page Haut de la page

 
 
S'applique à :
Access 2007