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

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

Une base de données correctement conçue vous donne accès à des informations précises et à jour. Étant donné qu’une conception correcte est essentielle pour atteindre vos objectifs en matière d’utilisation d’une base de données, il est tout à fait logique d’investir le temps nécessaire pour découvrir les principes de bonne conception. Au final, vous avez bien plus de chances de vous retrouver avec une base de données qui répond à vos besoins et qui peut facilement s’adapter au changement.

Cet article fournit des instructions pour la planification d’une base de données de bureau. Vous découvrirez comment déterminer les informations dont vous avez besoin, comment séparer ces informations en tables et colonnes appropriées et comment ces tables sont liées les unes aux autres. Vous devez lire cet article avant de créer votre première base de données de bureau.

Important : Access fournit des expériences de conception qui vous offrent la possibilité de créer des applications de base de données pour le web. De nombreuses considérations de conception sont différentes lorsque vous concevez pour le web. Cet article ne traite pas de la conception des applications de base de données web. Pour plus d’informations, voir l’article Créer une base de données à partager sur le web.

Contenu de cet article


Certains termes de base de données à connaître

Access organise vos informations au cours de tables(listes de lignes et colonnes rappelant les comptabilité ou une feuille de calcul). Dans une base de données simple, vous n’avez peut-être qu’une seule table. Pour la plupart des bases de données, vous aurez besoin de plusieurs bases de données. Par exemple, vous pouvez avoir une table qui stocke des informations sur des produits, une autre table qui stocke des informations sur les commandes et une autre table avec des informations sur les clients.

Image illustrant trois tables dans des feuilles de données

Chaque ligne est appelée plus correctement un enregistrementet chaque colonne, un champ. Un enregistrement est un moyen cohérent et significatif de combiner des informations sur un sujet. Un champ est un élément d’information unique (type d’élément qui apparaît dans chaque enregistrement). Dans la table Produits, par exemple, chaque ligne ou enregistrement contient des informations relatives à un produit. Chaque colonne ou champ contient un certain type d’informations sur ce produit, telles que son nom ou son prix.

Haut de la page

À quoi reconnaît-on une bonne conception de base de données ?

Certains principes guident le processus de conception d’une base de données. Le premier principe est que les informations en double (également appelées données redondantes) sont mauvaises, car elles perdent de l’espace et augmentent la probabilité des erreurs et incohérences. Le deuxième principe est que la qualité et l’intégralité des informations sont importantes. Si votre base de données contient des informations incorrectes, tous les états qui en tirent des informations contiennent également des informations incorrectes. Par conséquent, toutes les décisions basées sur ces rapports seront alors mal informées.

Par conséquent, une bonne conception de base de données est une conception qui :

  • Divise vos informations en tables d’objet afin de réduire la redondance des données.

  • Fournit à Access les informations nécessaires pour joindre les informations aux tables, si nécessaire.

  • Permet de garantir l’exactitude et l’intégrité de vos informations.

  • Répondre à vos besoins en matière de traitement des données et de rapport.

Haut de la page

Processus de conception

Le processus de conception est constitué des étapes suivantes :

  • Déterminez la raison d’être de votre base de données    

    Cela vous permet de vous préparer pour les étapes restantes.

  • Recherchez et organisez les informations requises     

    Recueillez tous les types d’informations que vous souhaitez peut-être enregistrer dans la base de données, tels que le nom du produit et le numéro de commande.

  • Diviser les informations en tables    

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

  • Transformer des éléments d’informations en colonnes    

    Déterminez les informations que vous voulez stocker dans chaque table. Chaque élément devient un champ et s’affiche en tant que colonne dans la table. Par exemple, une table Employés peut inclure des champs tels que Nom et Date d’embauche.

  • Spécifier les clés primaires    

    Sélectionnez la clé primaire de chaque table. La clé primaire est une colonne qui sert à identifier chaque ligne de manière unique. Par exemple, il peut s’agit de l’ID de produit ou de la commande.

  • Configurer les relations entre les tables    

    Examiner chaque table et décider comment les données d’une table sont liées aux données d’autres tables. Ajoutez des champs aux tables ou créez des tables pour clarifier les relations, si nécessaire.

  • Améliorer votre conception    

    Analysez votre conception en cas d’erreur. Créez les tables et ajoutez des enregistrements d’exemples de données. Voyez si vous pouvez obtenir les résultats voulus à partir de vos tables. Ajustez la conception selon vos besoins.

  • Appliquer les règles de normalisation    

    Appliquez les règles de normalisation des données pour voir si vos tableaux sont structurés correctement. Ajustons les tableaux selon vos besoins.

Haut de la page

Détermination de l’objectif de votre base de données

Il peut être utile d’écrire sur papier l’objectif de la base de données , son objectif, la façon dont vous comptez l’utiliser et les personnes qui l’utiliseront. Par exemple, pour une petite base de données pour une entreprise basée à domicile, vous pouvez écrire quelque chose de simple comme « La base de données client conserve une liste d’informations client aux fins de production de publipostages et d’états ». Si la base de données est plus complexe ou est utilisée par de nombreuses personnes, comme souvent dans le cadre d’une entreprise, l’objectif peut facilement être un paragraphe ou plus, et doit inclure quand et comment chaque personne utilisera la base de données. L’idée est d’avoir une mission bien développée, à référencer tout au long du processus de conception. Le fait d’avoir une telle déclaration vous permet de vous concentrer sur vos objectifs lorsque vous prendrez des décisions.

Haut de la page

Recherche et organisation des informations requises

Pour rechercher et organiser les informations requises, commencez par vos informations existantes. Par exemple, vous pouvez enregistrer des commandes dans un registre ou conserver les informations client sur des formulaires papier dans un classeur. Rassemblez ces documents et énumérez chaque type d’informations affiché (par exemple, chaque zone que vous remplissez dans un formulaire). Si vous n’avez aucun formulaire existant, imaginez plutôt que vous devez créer un formulaire pour enregistrer les informations client. Quelles informations placeriez-vous sur le formulaire ? Quelles zones de remplissage devez-vous créer ? Identifiez et énumérez chacun de ces éléments. Par exemple, supposons que vous conservez actuellement la liste des clients sur des cartes d’indexation. L’examen de ces cartes peut montrer que chaque carte contient un nom de client, une adresse, une ville, un état, un code postal et un numéro de téléphone. Chacun de ces éléments représente une colonne potentielle dans une table.

Lorsque vous préparez cette liste, ne vous inquiétez pas de l’obtenir au premier abord. Il est donc important de lister chaque élément qui vous vient à l’esprit. Si quelqu’un d’autre utilise la base de données, demandez également ses idées. Vous pourrez affiner la liste ultérieurement.

Prenons ensuite les types d’états ou de publipostages que vous souhaitez produire à partir de la base de données. Par exemple, vous souhaitez peut-être qu’un rapport des ventes de produits affiche les ventes par région ou un état récapitulatif du stock qui affiche les niveaux de stock des produits. Vous pouvez également générer des lettres type à envoyer aux clients qui annoncent un événement de vente ou offrent une premium. Créez l’état à votre esprit, et imaginez à quoi il ressemblerait. Quelles informations placeriez-vous dans l’état ? Listez chaque élément. Faites de même pour la lettre type et pour tout autre état que vous prévoyez de créer.

Une personne imaginant un état pour un stock

Réfléchir aux états et publipostages que vous voudrez peut-être créer vous permet d’identifier les éléments dont vous aurez besoin dans votre base de données. Par exemple, supposons que vous donnez à vos clients la possibilité de s’ils souhaitent ou non prendre ou non des mises à jour périodiques du courrier électronique et que vous souhaitez imprimer une liste de ceux qui ont choisi de le faire. Pour enregistrer ces informations, vous ajoutez une colonne « Envoyer un courrier électronique » à la table Clients. Pour chaque client, vous pouvez définir le champ sur Oui ou Non.

La nécessité d’envoyer des courriers électroniques aux clients suggère un autre élément à enregistrer. Lorsque vous savez qu’un client souhaite recevoir des messages électroniques, vous devez également connaître l’adresse de messagerie à laquelle l’envoyer. Vous devez donc enregistrer une adresse de courrier pour chaque client.

Il est logique de créer un prototype de chaque rapport ou liste de sorties et de prendre en considération les éléments dont vous aurez besoin pour créer le rapport. Par exemple, lorsque vous examinez une lettre type, vous pouvez prendre quelques points à l’esprit. Si vous souhaitez inclure une salutation appropriée (par exemple, chaîne « M. », « Mme » ou « Mme » qui commence une salutation), vous devez créer un élément de salutation. En outre, vous pouvez généralement commencer une lettre par « Cher M. Dupont » au lieu de « Cher. M. Dupont Dupont ». Cela suggère que vous voudriez généralement stocker le nom séparément du prénom.

N’oubliez pas de décomposer chaque information en ses plus petites parties utiles. Dans la cas d’un nom, pour rendre le nom facilement disponible, vous décomposez le nom en deux parties : Prénom et Nom. Pour trier un état par nom, par exemple, il est utile que le nom du client soit stocké séparément. En règle générale, si vous voulez trier, rechercher, calculer ou établir un état sur la base d’une information, vous devez placer cet élément dans son propre champ.

Pensez aux questions auxquelles la base de données peut répondre. Par exemple, combien de ventes de votre produit en vedette avez-vous fermé le mois dernier ? Où habitent vos meilleurs clients ? Qui est le fournisseur de votre produit le plus vendu ? Le fait de leur poser des questions vous aide à n’enregistrer que les éléments supplémentaires.

Une fois que vous avez rassemblé ces informations, vous êtes prêt à passer à l’étape suivante.

Haut de la page

Division des informations en tables

Pour diviser les informations en tables, choisissez les entités ou sujets principaux. Par exemple, après avoir trouvé et organisé des informations pour une base de données de ventes de produits, la liste préliminaire peut ressembler à ceci :

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

Les principales entités représentées ici sont les produits, les fournisseurs, les clients et les commandes. Par conséquent, il est logique de commencer avec ces quatre tables : une pour les faits sur les produits, une pour les informations sur les fournisseurs, une pour les informations sur les clients et une pour les faits sur les commandes. Bien que cette liste ne soit pas complète, il s’agit d’un bon point de départ. Vous pouvez continuer à affiner cette liste jusqu’à ce que vous avez une conception qui fonctionne bien.

Lorsque vous examinez la liste préliminaire d’éléments pour la première fois, vous pouvez être tenté de les placer tous dans une seule table, au lieu des quatre présentés dans l’illustration précédente. Vous découvrirez ici pourquoi ce n’est pas une bonne idée. Prenons un moment, par exemple, le tableau ci-après :

Image illustrant une table contenant des produits et des fournisseurs

Dans ce cas, chaque ligne contient des informations sur le produit et son fournisseur. Comme vous pouvez avoir plusieurs produits 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. N’enregistrez les informations des fournisseurs qu’une seule fois dans une table Fournisseurs distincte, puis lier cette table à la table Produits est une meilleure solution.

Cette conception présente un autre problème lorsque vous avez besoin de modifier les informations sur le fournisseur. Par exemple, supposons que vous devrez 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 endroit permet de résoudre le problème.

Lorsque vous concevez votre base de données, essayez toujours d’enregistrer chaque fait une seule fois. Si vous vous retrouvez à répéter les mêmes informations dans plusieurs lieux, comme l’adresse d’un fournisseur particulier, placez ces informations dans une table distincte.

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. Comment supprimer l’enregistrement de produit sans perdre également les informations du fournisseur ? C’est impossible. Chaque enregistrement contenant des informations sur un produit, ainsi que des faits sur un fournisseur, vous ne pouvez pas supprimer l’un sans supprimer l’autre. Pour séparer ces faits, vous devez fractionner la table en deux : une table pour les informations sur les produits et une autre pour les informations sur les fournisseurs. La suppression d’un enregistrement de produit ne doit supprimer que les informations sur le produit, pas les informations sur le fournisseur.

Une fois que vous avez choisi le sujet représenté par une table, les colonnes de cette table ne doivent stocker que des informations sur le sujet. Par exemple, la table Produits ne doit stocker que des informations sur les produits. L’adresse du fournisseur étant une fait du fournisseur et non une fait du produit, elle appartient à la table Fournisseur.

Haut de la page

Transformer des éléments d’informations en colonnes

Pour déterminer les colonnes d’un tableau, déterminez les informations dont vous avez besoin pour suivre le sujet enregistré dans le tableau. Par exemple, pour la table Clients, Name, Address, City-State-Zip, Send e-mail, Salutations et E-mail address constituent une bonne liste de colonnes de départ. Chaque enregistrement de la table contient le même ensemble de colonnes, de sorte que vous pouvez stocker les informations Nom, Adresse, City-State-Zip, Envoyer un courrier électronique, Salutations et Adresse de courrier pour chaque enregistrement. Par exemple, la colonne Adresse contient les adresses des clients. Chaque enregistrement contient les données relatives à un client, et le champ Adresse contient l’adresse de ce client.

Une fois que vous avez déterminé l’ensemble initial de colonnes pour chaque table, vous pouvez affiner davantage les colonnes. Par exemple, il est logique de stocker le nom du client sous deux colonnes distinctes : prénom et nom afin de pouvoir trier, rechercher et indexer uniquement sur ces colonnes. De même, l’adresse se compose en réalité de cinq composants distincts (adresse, ville, état, code postal et pays/région), et il est également logique de les stocker dans des colonnes distinctes. Si vous souhaitez effectuer une recherche, un filtrage ou un tri par état, par exemple, vous avez besoin des informations d’état stockées dans une colonne distincte.

Vous devez également déterminer si la base de données contient des informations d’origine nationale uniquement ou internationales. Par exemple, si vous envisagez de stocker des adresses internationales, il est préférable d’avoir une colonne Région au lieu de État, car cette colonne peut prendre en charge à la fois les États nationaux et les régions d’autres pays/régions. De même, le code postal a plus de sens que le code postal si vous comptez stocker des adresses internationales.

La liste suivante présente quelques conseils pour déterminer vos colonnes.

  • N’incluez pas de données calculées    

    Dans la plupart des cas, vous ne devez pas stocker le résultat des calculs dans des tables. Au lieu de cela, vous pouvez faire en effet en votre possible pour qu’Access effectue les calculs lorsque vous voulez voir le résultat. Par exemple, supposons qu’il existe un rapport Produits sur commande qui affiche le sous-totaux des unités sur commande pour chaque catégorie de produit dans la base de données. Il n’existe toutefois aucune colonne de sous-totaux Unités sur commande dans une table. Au lieu de cela, la table Produits inclut une colonne Unités sur commande qui stocke les unités sur commande pour chaque produit. À l’aide de ces données, Access calcule le sous-totaux chaque fois que vous imprimez l’état. Le sous-totaux proprement dit ne doit pas être stocké dans une table.

  • Stocker des informations dans leurs plus petits composants logiques    

    Vous pouvez être tenté d’avoir un seul champ pour les noms complets ou pour les noms de produits ainsi que des descriptions de produits. Si vous combinez plusieurs types d’informations dans un champ, il est difficile de récupérer des faits individuels ultérieurement. Essayez de décomposer les informations en parties logiques . Par exemple, créez des champs distincts pour le prénom et le nom, ou pour le nom, la catégorie et la description du produit.

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

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.

Haut de la page

Spécification des clés primaires

Chaque table doit inclure une colonne ou un ensemble 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’identification d’employé ou un numéro de série. En termes de terminologie de base de données, ces informations sont appelées clés primaires de la table. Access utilise des champs de clé primaire pour associer rapidement les données de plusieurs tables et les rassembler pour vous.

Si vous avez déjà un identificateur unique pour une table, tel qu’un numéro de produit qui identifie de façon unique chaque produit dans votre catalogue, vous pouvez utiliser cet identificateur comme clé primaire de la table, mais uniquement si les valeurs dans cette colonne sont toujours différentes pour chaque enregistrement. Vous ne pouvez pas avoir de valeurs en double dans une clé primaire. Par exemple, n’utilisez pas le nom des personnes comme clé primaire, car les noms ne sont pas uniques. Vous pouvez facilement avoir deux personnes ayant le même nom dans la même table.

Une clé primaire doit toujours avoir une valeur. Si la valeur d’une colonne peut devenir à un moment non insérez ou inconnue (valeur manquante), elle ne peut pas être utilisée comme composant dans une clé primaire.

Vous devez toujours choisir une clé primaire dont la valeur ne changera pas. Dans une base de données qui utilise plusieurs tables, la clé primaire d’une table peut être utilisée comme référence dans d’autres tables. Si la clé primaire change, elle doit également être appliquée partout où la clé est référencé. L’utilisation d’une clé primaire qui ne changera pas réduit le risque qu’elle ne soit plus synchronisée avec d’autres tables qui la référencent.

Souvent, un nombre unique arbitraire est utilisé comme clé primaire. Par exemple, vous pouvez attribuer un numéro unique à chaque commande. Le seul objectif du numéro de commande est d’identifier une commande. Une fois affecté, il ne change jamais.

Si vous n’avez pas à l’esprit une colonne ou un ensemble de colonnes qui peuvent faire une bonne clé primaire, envisagez d’utiliser une colonne dont le type de données est Numéro Automatique. Lorsque vous utilisez le type de données Numéro Automatique, Access affecte automatiquement une valeur à votre place. Un tel identificateur est factless ; il ne contient aucune information concrète décrivant la ligne qu’elle représente. Les identificateurs factless sont parfaits pour une utilisation en tant que clé primaire, car ils ne changent pas. Une clé primaire contenant des faits sur une ligne (numéro de téléphone ou un nom de client, par exemple) est plus susceptible de changer, car les informations concrètes elles-mêmes peuvent changer.

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

1. Une colonne dont le type de données est Numéro Automatique constitue souvent une clé primaire essentielle. Deux ID de produit sont identiques.

Dans certains cas, vous pouvez utiliser deux champs ou plus qui, ensemble, fournissent la clé primaire d’une table. Par exemple, une table Détails de la commande qui stocke les articles des commandes utiliserait deux colonnes dans sa clé primaire : ID de commande et ID de produit. Lorsqu’une clé primaire utilise plusieurs colonnes, elle est également appelée clé composite.

Pour la base de données des ventes de produits, vous pouvez créer une colonne Numéro Automatique pour chacune des tables comme clé primaire : ProductID pour la table Produits, OrderID pour la table Commandes, CustomerID pour la table Clients et SupplierID pour la table Fournisseurs.

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


Haut de page

Création des relations entre les tables

À présent que vous avez divisé vos informations en tables, vous avez besoin d’un moyen de les rassembler de manière significative. Par exemple, le formulaire suivant inclut des informations issues de plusieurs tables.

Le formulaire Commandes

1. Les informations de ce formulaire proviennent de la table Clients...

2. ... table Employés...

3. ... la table Commandes...

4. ... la table Produits...

5. ... et la table Détails de la commande.

Access est un système de gestion de base de données relationnelle. Dans une base de données relationnelle, vous divisez vos informations en tables distinctes basées sur l’objet. Vous utilisez ensuite les relations entre les tables pour rassembler les informations, si nécessaire.

Haut de la page

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

Prenons l’exemple suivant : tables Fournisseurs et Produits dans la base de données commandes de produits. Un fournisseur peut fournir n’importe quel nombre de produits. De ce fait, pour n’importe quel fournisseur représenté dans la table Fournisseurs, plusieurs produits peuvent être représentés dans la table Produits. Par conséquent, la relation entre la table Fournisseurs et la table Produits est une relation un-à-plusieurs.

Relation un-à-plusieurs

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

La colonne ID fournisseur de la table Produits est appelée clé étrangère. Une clé étrangère est la clé primaire d’une autre table. La colonne ID fournisseur dans la table Produits est une clé étrangère, car il s’agit également de la clé primaire dans la table Fournisseurs.

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

Vous fournissez la base pour joindre des tables liées en établissant des paires de clés primaires et de clés étrangères. Si vous n’êtes pas certain que les tables doivent partager une colonne commune, l’identification d’une relation un-à-plusieurs garantit que les deux tables concernées nécessitent en effet une colonne partagée.

Haut de la page

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

Prenez en compte la relation entre la table Produits et la table Commandes.

Une même commande peut porter sur plusieurs produits. D’un autre côté, un même produit peut figurer sur plusieurs commandes. Ainsi, vous pouvez avoir plusieurs enregistrements dans la table Produits pour chaque enregistrement de la table Commandes. Il peut y avoir plusieurs enregistrements dans la table Commandes pour chaque enregistrement de la table Produits. Ce type de relation est appelé relation plusieurs-à-plusieurs car pour n’importe quel produit, il peut y avoir plusieurs commandes ; et pour n’importe quelle commande, il peut y avoir de nombreux produits. Notez que pour détecter les relations plusieurs-à-plusieurs entre vos tables, il est important de prendre en compte les deux côtés de la relation.

Les sujets des deux tables ( commandes et produits) ont une relation plusieurs-à-plusieurs. Cela pose problème. Pour comprendre le problème, imaginez ce qui se passerait si vous essayiez de créer la relation entre les deux tables en ajoutant le champ ID de produit à la table Commandes. Pour avoir plusieurs produits par commande, vous avez besoin de plusieurs dossiers dans la table Commandes par commande. Vous répétiez les informations de commande pour chaque ligne liée à une seule commande, ce qui provoquerait un projet inefficace qui pourrait entraîner des données incorrectes. Vous devez vous poser le même problème si vous insériez le champ ID de commande dans la table Produits : vous avez plusieurs enregistrement dans la table Produits pour chaque produit. Comment résoudre ce problème ?

La réponse consiste à créer une troisième table, souvent appelée table de jonction, qui décompose la relation plusieurs-à-plusieurs en deux relations un-à-plusieurs. Vous devez insérer la clé primaire de chacune des deux tables dans la troisième. Par conséquent, la troisième table enregistre chaque occurrence ou instance de la relation.

Relation plusieurs-à-plusieurs

Chaque enregistrement dans la table Détails de la commande représente un élément de ligne sur une commande. La clé primaire de la table Détails de la commande se compose de deux champs : les clés étrangères des tables Commandes et Produits. L’utilisation du seul champ ID de commande ne peut pas servir de clé primaire pour cette table, car une commande peut avoir de nombreux articles. L’ID de commande est répété pour chaque ligne d’une commande, de sorte que le champ ne contient pas de valeurs uniques. L’utilisation du champ ID de produit à elle seule ne fonctionne pas non plus, car un produit peut apparaître sur plusieurs commandes différentes. Mais ensemble, les deux champs produisent toujours une valeur unique pour chaque enregistrement.

Dans la base de données des ventes de produits, la table Commandes et la table Produits ne sont pas liées entre elles directement. Elles sont plutôt liées indirectement par le biais de la table Détails commande. La relation plusieurs-à-plusieurs entre commandes et produits est représentée dans la base de données à l’aide de deux relations un-à-plusieurs :

  • La table Commandes et la table Détails de la commande ont une relation un-à-plusieurs. Chaque commande peut avoir plusieurs articles, mais chaque article n’est connecté qu’à une seule commande.

  • La table Produits et la table Détails de la commande ont une relation un-à-plusieurs. Un grand nombre d’articles peuvent être associés à chaque produit, mais chaque article ne fait référence qu’à un seul produit.

Dans la table Détails de la commande, vous pouvez déterminer tous les produits d’une commande particulière. Vous pouvez également déterminer toutes les commandes pour un produit particulier.

Après avoir incorporé la table Détails de la commande, la liste des tables et des champs peut ressembler à ceci :

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


Haut de page

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

Un autre type de relation est la relation un-à-un. Par exemple, supposons que vous devrez enregistrer des informations supplémentaires supplémentaires sur les produits dont vous aurez besoin rarement ou qui ne s’appliquent qu’à quelques produits. Étant donné que vous n’avez pas besoin souvent des informations et que le stockage des informations dans la table Produits produit entraînerait un espace vide pour chaque produit auquel elle ne s’applique pas, vous les placez dans une table distincte. Comme dans la table Produits, vous utilisez ProductID comme clé primaire. La relation entre cette table supplémentaire et la table Produit est une relation un-à-un. Pour chaque enregistrement de la table Produit, il existe un seul enregistrement correspondant dans la table supplémentaire. Lorsque vous identifiez une relation de ce type, les deux tables doivent partager un champ commun.

Lorsque vous détectez le besoin d’une relation un-à-un dans votre base de données, vous pouvez décider si vous pouvez rassembler les informations des deux tables dans une seule table. Si vous ne souhaitez pas le faire pour une raison quelconque, peut-être parce que cela créerait beaucoup d’espace vide, la liste suivante montre comment représenter la relation dans votre conception :

  • Si les deux tables ont le même objet, vous pouvez probablement configurer la relation en utilisant la même clé primaire dans les deux tables.

  • Si les deux tables ont des sujets différents avec des clés primaires différentes, choisissez l’une des tables (l’une) et insérez sa clé primaire dans l’autre table en tant que clé étrangère.

La détermination des relations entre les tables vous permet de vous assurer que vous avez les tables et colonnes qui s’y rapportent. Lorsqu’une relation un-à-un ou un-à-plusieurs existe, les tables concernées doivent partager une ou plusieurs colonnes communes. Lorsqu’une relation plusieurs-à-plusieurs existe, une troisième table est nécessaire pour représenter la relation.

Haut de la page

Affinage de la conception

Une fois que vous avez les tables, les champs et les relations dont vous avez besoin, vous devez créer et remplir vos tables avec des exemples de données et essayer d’travailler avec les informations : création de requêtes, ajout d’enregistrements, etc. Cela permet de mettre en évidence les problèmes potentiels ( par exemple, vous devrez peut-être ajouter une colonne que vous avez oublié d’insérer lors de votre phase de conception, ou vous devriez fractionner un tableau en deux tableaux pour supprimer les doublons).

Voyez si vous pouvez utiliser la base de données pour obtenir les réponses que vous souhaitez. Créez des brouillons de formulaires et d’états, et voyez s’ils montrent les données que vous attendez. Recherchez les doublons inutiles de données et, lorsque vous en trouvez, modifiez votre conception pour les éliminer.

Lorsque vous essayerez votre base de données initiale, il est probable que vous devrons vous améliorer. Voici quelques points à vérifier :

  • Avez-vous oublié des colonnes ? Si c’est le cas, les informations appartiennent-elles aux tables existantes ? S’il s’agit d’informations sur d’autres informations, vous devrez peut-être créer une autre table. Créez une colonne pour chaque élément d’information dont vous devez suivre le suivi. Si les informations ne peuvent pas être calculées à partir d’autres colonnes, il est probable que vous aurez besoin d’une nouvelle colonne pour elle.

  • Les colonnes sont-elles inutiles, car elles peuvent être calculées à partir de champs existants ? Si un élément d’information peut être calculé à partir d’autres colonnes existantes (un prix réduit calculé à partir du prix au détail, par exemple), il est généralement préférable de faire simplement cela et d’éviter de créer une nouvelle colonne.

  • Vous entrez régulièrement des informations en double dans l’une de vos tables ? Si c’est le cas, vous devrez probablement diviser la table en deux tables qui ont une relation un-à-plusieurs.

  • Avez-vous des tables avec de nombreux champs, un nombre limité d’enregistrements et de nombreux champs vides dans des enregistrements individuels ? Si c’est le cas, réfléchissez à la refonte de la table pour qu’elle ait moins de champs et plus d’enregistrements.

  • Chaque élément d’information a-t-il été divisé en ses plus petites parties utiles ? Si vous devez signaler, trier, rechercher ou calculer sur un élément d’informations, placez cet élément dans sa propre colonne.

  • Chaque colonne contient-elle une fait sur le sujet de la table ? Si une colonne ne contient pas d’informations sur le sujet de la table, elle appartient à une autre table.

  • Toutes les relations entre les tables sont-elles représentées, soit par des champs communs, soit par une troisième table ? Les relations un-à-un et un-à-plusieurs nécessitent des colonnes communes. Les relations plusieurs-à-plusieurs nécessitent une troisième table.

Affinage de la table Produits

Supposons que chaque produit de la base de données de ventes de produits relève d’une catégorie générale, comme les boissons, les commercial ou les fruits de mer. La table Produits peut inclure un champ qui affiche la catégorie de chaque produit.

Supposons qu’après avoir examiné et affiné la conception de la base de données, vous décidiez de stocker une description de la catégorie ainsi que son nom. Si vous ajoutez un champ Description de catégorie à la table Produits, vous devez répéter chaque description de catégorie pour chaque produit qui tombe dans la catégorie ; ce n’est pas une bonne solution.

Une meilleure solution consiste à faire des catégories un nouveau sujet à suivre pour la base de données, avec sa propre table et sa propre clé primaire. Vous pouvez ensuite ajouter la clé primaire de la table Catégories à la table Produits en tant que clé étrangère.

Les tables Catégories et Produits ont une relation un-à-plusieurs : une catégorie peut inclure plusieurs produits, mais un produit ne peut appartenir qu’à une seule catégorie.

Lorsque vous examinez les structures de votre table, soyez à la recherche de groupes périodiques. Par exemple, envisagez une table contenant les colonnes suivantes :

  • Réf produit

  • Name (Nom)

  • Product ID1

  • Nom1

  • ID de produit2

  • Nom2

  • ID3 du produit

  • Name3 (Nom3)

Ici, chaque produit est un groupe répété de colonnes qui diffère des autres uniquement en ajoutant un nombre à la fin du nom de colonne. Lorsque les colonnes sont numéroées de cette façon, vous devez revisiter votre conception.

Une telle conception a plusieurs défauts. Pour commencer, il force à placer une limite supérieure sur le nombre de produits. Dès que vous dépassez cette limite, vous devez ajouter un nouveau groupe de colonnes à la structure de la table, qui est une tâche d’administration majeure.

Un autre problème est que les fournisseurs dont le nombre de produits est inférieur au nombre maximal de produits perdront de l’espace, étant donné que les colonnes supplémentaires sont vides. La plus sérieuse en ce sens qu’une telle conception rend de nombreuses tâches difficiles à effectuer, telles que le tri ou l’indexation de la table par ID de produit ou par nom.

Chaque fois que vous voyez des groupes périodiques examiner la conception étroitement avec un œil sur le fractionnement du tableau 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 ID de fournisseur.

Haut de la page

Application des règles de normalisation

Vous pouvez appliquer les règles de normalisation des données (parfois simplement appelées règles de normalisation) comme étape suivante dans votre conception. Vous utilisez ces règles pour voir si vos tableaux sont structurés correctement. Le processus d’application des règles à la conception de votre base de données est appelé « normalisation » de la base de données, ou simplement « normalisation ».

La normalisation est particulièrement utile lorsque vous avez représenté tous les éléments d’information et que vous êtes arrivé à une conception préliminaire. L’idée est de vous aider à vous assurer que vous avez divisé vos éléments d’informations dans les tables appropriées. Ce que la normalisation ne peut pas faire, c’est vous assurer que vous avez tous les éléments de données corrects avec qui commencer.

Vous appliquez les règles l’un après l’autre, à chaque étape, en veillant à ce que votre conception arrive à l’un des « formulaires normaux ». Cinq formulaires normaux sont largement acceptés : le premier formulaire normal et la cinquième forme normale. Cet article s’étend sur les trois premiers, car tous sont requis pour la plupart des conceptions de bases de données.

Premier formulaire normal

Le premier formulaire normal indique qu’à chaque intersection de lignes et de colonnes dans la table, existe une seule valeur et jamais une liste de valeurs. Par exemple, vous ne pouvez pas avoir de champ nommé Prix dans lequel vous placez plusieurs prix. Si vous pensez que chaque intersection de lignes et de colonnes est une cellule, chaque cellule ne peut contenir qu’une seule valeur.

Second normal form

Une deuxième forme normale nécessite que chaque colonne autre qu’une clé dépende entièrement de la clé primaire, et non seulement d’une partie de celle-ci. Cette règle s’applique lorsque vous avez une clé primaire composée de plusieurs colonnes. Par exemple, supposons que vous avez une table contenant les colonnes suivantes, dans laquelle les ID de commande et d’ID de produit constituent la clé primaire :

  • ID de commande (clé primaire)

  • ID de produit (clé primaire)

  • Nom du produit

Cette conception enfreint le deuxième formulaire normal, car le nom du produit dépend de l’ID de produit, mais pas de l’ID de commande, il n’est donc pas dépendant de la clé primaire entière. Vous devez supprimer le nom du produit de la table. Elle appartient à une autre table (Produits).

Troisième formulaire normal

Un troisième formulaire normal nécessite non seulement que chaque colonne non clé soit dépendante de la clé primaire entière, mais que ces colonnes non clés soient indépendantes les unes des autres.

Une autre façon de dire cela est que chaque colonne non clé doit être dépendante de la clé primaire et rien d’autre que la clé primaire. Par exemple, supposons que vous avez une table contenant les colonnes suivantes :

  • ProductID (clé primaire)

  • Name (Nom)

  • SRP

  • taux_escompte

Supposons que la réduction dépend du prix de vente suggéré. Cette table enfreint la troisième forme normale, car une colonne non clé Discount dépend d’une autre colonne non clé (SRP). L’indépendance de colonne signifie que vous devriez être en mesure de modifier une colonne non clé sans affecter d’autre colonne. Si vous modifiez une valeur dans le champ SRP, la réduction change en conséquence, ce qui enfreindrait cette règle. Dans ce cas, Discount doit être déplacé vers une autre table qui est clé dans SRP.

Haut de la page

Besoin d’aide ?

Développez vos compétences dans Office
Découvrez des formations
Accédez aux nouvelles fonctionnalités en avant-première
Rejoignez le programme Office Insider

Ces informations vous ont-elles été utiles ?

×