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

Une base de données bien conçue vous donne accès à des informations précises et à jour. Une conception correcte étant essentielle pour atteindre vos objectifs en travaillant avec une base de données, il est logique d’investir le temps nécessaire pour apprendre les principes d’une bonne conception. En fin de compte, vous avez beaucoup plus de chances de vous retrouver avec une base de données qui répond à vos besoins et peut facilement s’adapter au changement.

Cet article fournit des instructions pour la planification d’une base de données de bureau. Vous apprendrez comment déterminer les informations dont vous avez besoin, comment les diviser 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.

Contenu de cet article

• Quelques termes de base de données à connaître
• À quoi reconnaît-on une bonne conception de base de données ?
• Le processus de conception
• Détermination de l’objectif de votre base de données
• Recherche et organisation des informations requises
• Division des informations en tableaux
• Transformer les informations en colonnes
• Spécification des clés primaires
• Création des relations entre tables
• Affiner la conception
• Application des règles de normalisation

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

Access organise vos informations en tableaux : listes de lignes et de colonnes rappelant un bloc-notes de comptable ou une feuille de calcul. Dans une base de données simple, vous ne pouvez avoir qu’une seule table. Pour la plupart des bases de données, vous en aurez besoin de plusieurs. Par exemple, vous pouvez avoir une table qui stocke des informations sur les produits, une autre table qui stocke des informations sur les commandes et une autre table qui contient des informations sur les clients.

Chaque ligne est plus correctement appelée un enregistrement et chaque colonne, un champ. Un enregistrement est un moyen significatif et cohérent de combiner des informations sur quelque chose. Un champ est un élément d’information unique, c’est-à-dire un 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 dupliquées (également appelées données redondantes) sont mauvaises, car elles gaspillent de l’espace et augmentent la probabilité d’erreurs et d’incohérences. Le deuxième principe est que l’exactitude et l’exhaustivité des informations sont importantes. Si votre base de données contient des informations incorrectes, les rapports qui extraient des informations de la base de données contiendront également des informations incorrectes. Par conséquent, toutes les décisions que vous prenez sur la base de ces rapports seront alors mal informées.

Une bonne conception de base de données est donc une base de données qui :

• Divise vos informations en tables thématiques afin de réduire les données redondantes.
• Fournit à Access les informations dont il a besoin pour joindre les informations des tables en fonction des besoins.
• Contribue à soutenir et à garantir l’exactitude et l’intégrité de vos informations.
• Répond à vos besoins en matière de traitement des données et de création de rapports.

Haut de la page

Le processus de conception

Le processus de conception comprend les étapes suivantes :

• Déterminez la raison d’être de votre base de données
  Cela vous permet de vous préparer aux étapes restantes.
• Recherchez et organisez les informations requises
  Rassemblez tous les types d’informations que vous souhaiteriez enregistrer dans la base de données, tels que le nom du produit et le numéro de commande.
• Diviser les informations en tableaux
  Divisez vos informations en entités ou sujets principaux, tels que Produits ou Commandes. Chaque sujet devient alors une table.
• Transformer des éléments d’information en colonnes
  Choisissez les informations que vous souhaitez stocker dans chaque table. Chaque élément devient un champ et s’affiche sous forme de colonne dans la table. Par exemple, une table Employés peut inclure des champs tels que Nom et Date d’embauche.
• Spécifier des clés primaires
  Choisissez la clé primaire de chaque table. La clé primaire est une colonne utilisée pour identifier chaque ligne de manière unique. Un exemple peut être l’ID de produit ou l’ID de commande.
• Configurer les relations entre tables
  Examinez chaque table et décidez comment les données d’une table sont liées aux données d’autres tables. Ajoutez des champs à des tables ou créez-en de nouvelles pour clarifier les relations, si nécessaire.
• Affiner votre conception
  Analysez votre conception pour détecter les erreurs. Créez les tables et ajoutez quelques enregistrements de données d’exemple. Voyez si vous pouvez obtenir les résultats souhaités à partir de vos tableaux. Apportez les modifications nécessaires à la conception.
• Appliquer les règles de normalisation
  Appliquez les règles de normalisation des données pour voir si vos tables sont structurées correctement. Apportez les modifications nécessaires aux tableaux.

Haut de la page

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

Il est judicieux d’écrire l’objectif de la base de données sur papier - son objectif, comment vous prévoyez l’utiliser et qui l’utilisera. Pour une petite base de données pour une entreprise à domicile, par exemple, vous pouvez écrire quelque chose de simple comme « La base de données clients conserve une liste d’informations sur les clients dans le but de produire des publipostages et des rapports ». Si la base de données est plus complexe ou est utilisée par de nombreuses personnes, comme c’est souvent le cas dans le cadre d’une entreprise, l’objectif pourrait facilement être un paragraphe ou plus et devrait inclure quand et comment chaque personne utilisera la base de données. L’idée est d’avoir un énoncé de mission bien élaboré qui peut être consulté tout au long du processus de conception. Avoir une telle déclaration vous aide à vous concentrer sur vos objectifs lorsque vous prenez des décisions.

Haut de la page

Recherche et organisation des informations requises

Pour rechercher et organiser les informations requises, commencez par les informations existantes. Par exemple, vous pouvez enregistrer des bons de commande dans un grand livre ou conserver des informations sur les clients sur des formulaires papier dans un classeur. Rassemblez ces documents et répertoriez chaque type d’informations affichées (par exemple, chaque case que vous remplissez dans un formulaire). Si vous n’avez pas de formulaires existants, imaginez plutôt que vous deviez concevoir un formulaire pour enregistrer les informations client. Quelles informations mettriez-vous sur le formulaire ? Quelles boîtes à remplir créeriez-vous ? Identifiez et répertoriez chacun de ces éléments. Par exemple, supposons que vous conserviez actuellement la liste des clients dans les fiches. L’examen de ces cartes peut montrer que chaque carte contient le nom, l’adresse, la ville, l’état, le code postal et le numéro de téléphone du client. Chacun de ces éléments représente une colonne potentielle dans un tableau.

Lorsque vous préparez cette liste, ne vous inquiétez pas d’être parfait au début. Énumérez plutôt chaque élément qui vous vient à l’esprit. Si quelqu’un d’autre utilise la base de données, demandez-lui également son avis. Vous pourrez affiner la liste ultérieurement.

Ensuite, réfléchissez aux types de rapports ou de publipostage que vous pourriez vouloir produire à partir de la base de données. Par instance, vous souhaiterez peut-être un rapport de ventes de produits affichant les ventes par région ou un rapport de synthèse des stocks affichant les niveaux d’inventaire des produits. Vous pouvez également générer des lettres types à envoyer aux clients qui annoncent un événement de vente ou offrent une prime. Concevez le rapport dans votre esprit et imaginez à quoi il ressemblerait. Quelles informations placeriez-vous sur le rapport ? Répertoriez chaque élément. Faites de même pour la lettre type et pour tout autre rapport que vous prévoyez de créer.

En réfléchissant aux rapports et aux envois que vous pourriez vouloir créer, vous pouvez identifier les éléments dont vous aurez besoin dans votre base de données. Par exemple, supposons que vous donniez aux clients la possibilité de s’inscrire (ou non) à des mises à jour régulières par courrier électronique et que vous souhaitiez imprimer une liste de ceux qui ont choisi de le faire. Pour enregistrer ces informations, vous ajoutez une colonne « Envoyer un e-mail » à la table client. Pour chaque client, vous pouvez définir le champ sur Oui ou Non.

L’obligation d’envoyer des messages électroniques aux clients suggère un autre élément à enregistrer. Une fois que vous savez qu’un client souhaite recevoir des messages électroniques, vous devrez également connaître l’adresse électronique à laquelle l’envoyer. Par conséquent, vous devez enregistrer une adresse e-mail pour chaque client.

Il est judicieux de construire un prototype de chaque rapport ou liste de résultats et de considérer les éléments dont vous aurez besoin pour produire le rapport. Par instance, lorsque vous examinez une lettre type, certaines choses peuvent vous venir à l’esprit. Si vous souhaitez inclure une formule de salutation appropriée, par exemple, la chaîne « Monsieur », « Madame » ou « Madame » qui commence une formule de salutation, vous devez créer un élément de salutation. De plus, vous pouvez généralement commencer une lettre par « Cher M. Smith », plutôt que « Cher ». M. Sylvester Smith". Cela suggère que vous souhaiterez généralement stocker le nom séparément du prénom.

Un point clé à retenir est que vous devez décomposer chaque élément d’information en ses plus petites parties utiles. Dans le cas d’un nom, pour rendre le nom de famille facilement accessible, vous diviserez le nom en deux parties : le prénom et le nom. Pour trier un rapport par nom de famille, par exemple, il est utile que le nom du client soit stocké séparément. En règle générale, si vous voulez effectuer un tri, une recherche, un calcul ou un rapport sur la base d’une information, vous devez placer cet élément dans son propre champ.

Réfléchissez aux questions auxquelles vous souhaiterez peut-être que la base de données réponde. Par instance, combien de ventes de votre produit vedette avez-vous conclues le mois dernier ? Où vivent vos meilleurs clients ? Qui est le fournisseur de votre produit le plus vendu ? L’anticipation de ces questions vous aide à vous concentrer sur les éléments supplémentaires à enregistrer.

Après avoir collecté ces informations, vous êtes prêt pour l’étape suivante.

Haut de la page

Division des informations en tableaux

Pour répartir les informations en tableaux, sélectionnez les principales entités ou sujets. Par exemple, après avoir recherché et organisé les informations d’une base de données de ventes de produits, la liste préliminaire peut ressembler à ceci :

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

Lorsque vous examinez pour la première fois la liste préliminaire d’éléments, vous pourriez être tenté de les placer tous dans une seule table, au lieu des quatre présentées dans l’illustration précédente. Vous apprendrez ici pourquoi c’est une mauvaise idée. Considérez un instant le tableau présenté ici :

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 l’adresse du fournisseur doivent être répétés plusieurs fois. Cela mobilise de l’espace sur le disque. Il est préférable d’enregistrer les informations relatives aux fournisseurs une seule fois dans une table Fournisseurs distincte, puis de lier cette table à la table Produits.

Un deuxième problème avec cette conception survient lorsque vous devez modifier les informations sur le fournisseur. Par exemple, 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 en un seul endroit résout le problème.

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

Enfin, supposons qu’il n’y ait qu’un seul produit fourni par Coho Winery et que vous souhaitiez supprimer le produit, mais conserver le nom et les informations d’adresse du fournisseur. Comment supprimeriez-vous l’enregistrement du produit sans perdre également les informations sur le fournisseur ? C’est impossible. Étant donné que chaque enregistrement contient des faits concernant un produit, ainsi que des faits concernant 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 table pour les informations sur les fournisseurs. La suppression d’un enregistrement de produit ne doit supprimer que les faits concernant le produit, et non ceux concernant le fournisseur.

Une fois que vous avez choisi le sujet représenté par un tableau, les colonnes de ce tableau ne doivent stocker que les faits concernant le sujet. Par instance, la table des produits ne doit stocker que les faits sur les produits. Étant donné que l’adresse du fournisseur est un fait concernant le fournisseur et non un fait concernant le produit, elle appartient à la table des fournisseurs.

Haut de la page

Transformer les informations en colonnes

Pour déterminer les colonnes d’une table, déterminez les informations dont vous avez besoin pour effectuer le suivi concernant le sujet enregistré dans la table. Par exemple, pour la table Clients, Nom, Adresse, Ville-État-Zip, Envoyer un e-mail, Formule de salutation et Adresse e-mail constituent une bonne liste de départ de colonnes. Chaque enregistrement de la table contient le même ensemble de colonnes, ce qui vous permet de stocker les informations sur le nom, l’adresse, la ville-état-code postal, l’envoi d’un e-mail, la formule de politesse et l’adresse e-mail pour chaque enregistrement. Par exemple, la colonne adresse contient les adresses des clients. Chaque enregistrement contient des données sur un client et le champ d’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 judicieux de stocker le nom du client sur deux colonnes distinctes : prénom et nom, de sorte que vous puissiez effectuer un tri, une recherche et un indexation uniquement sur ces colonnes. De même, l’adresse se compose en fait 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 opération de recherche, de filtrage ou de tri par état, par exemple, vous avez besoin de stocker les informations d’état dans une colonne distincte.

Vous devez également déterminer si la base de données contiendra des informations d’origine nationale uniquement ou internationale. Par instance, si vous prévoyez de stocker des adresses internationales, il est préférable d’avoir une colonne Région au lieu d’État, car une telle colonne peut accueillir à la fois les états nationaux et les régions d’autres pays/régions. De même, Code postal a plus de sens que Code postal si vous allez stocker des adresses internationales.

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

• Ne pas inclure les données calculées
  Dans la plupart des cas, vous ne devez pas stocker le résultat des calculs dans des tables. Vous pouvez laisser Access effectuer les calculs lorsque vous voulez voir le résultat. Par exemple, supposons qu’il existe un état Produits en commande qui affiche le sous-total des unités en commande pour chaque catégorie de produit dans la base de données. Toutefois, il n’existe aucune colonne de sous-total Unités en commande dans aucune table. Au lieu de cela, la table Produits inclut une colonne Unités en commande qui stocke les unités en commande pour chaque produit. À l’aide de ces données, Access calcule le sous-total chaque fois que vous imprimez le rapport. Le sous-total lui-même ne doit pas être stocké dans une table.
• Stockez les informations dans leurs plus petites parties logiques
  Vous pourriez être tenté d’avoir un seul champ pour les noms complets, ou pour les noms de produits avec les descriptions des 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.

Une fois que vous avez affiné les colonnes de données de 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 identifiant de manière 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. Dans la terminologie des bases de données, ces informations sont appelées la clé primaire de la table. Access utilise les 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 manière unique chaque produit dans votre catalogue, vous pouvez l’utiliser comme clé primaire de la table, mais uniquement si les valeurs de cette colonne sont toujours différentes pour chaque enregistrement. Une clé primaire ne peut pas contenir des valeurs en double. Par exemple, n’utilisez pas le nom des personnes comme clé primaire, car les noms ne sont pas uniques. Vous pourriez facilement avoir deux personnes portant 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 inassignée ou inconnue (valeur manquante) à un moment donné, 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, la modification doit également être appliquée partout où la clé est référencée. L’utilisation d’une clé primaire qui ne change pas réduit le risque que la clé primaire 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 de commande unique à chaque commande. Le numéro de commande a pour seul but d’identifier une commande. Une fois attribué, il ne change jamais.

Si vous n’avez pas en tête une colonne ou un ensemble de colonnes pouvant constituer une clé primaire, envisagez d’utiliser une colonne dont le type de données est NuméroAuto. Lorsque vous utilisez le type de données NuméroAuto, Access vous attribue automatiquement une valeur. Un tel identifiant est sans faits ; Il ne contient aucune information factuelle décrivant la ligne qu’il représente. Les identificateurs sans faits sont idéaux pour une utilisation comme clé primaire car ils ne changent pas. Une clé primaire qui contient des faits sur une ligne (numéro de téléphone ou nom de client, par exemple) est plus susceptible de changer, car les informations factuelles elles-mêmes peuvent changer.

1. Une colonne définie sur le type de données NuméroAuto constitue souvent une clé primaire appropriée. Il n’y a pas deux ID de produit identiques.

Dans certains cas, vous pouvez utiliser au moins deux champs qui, ensemble, fournissent la clé primaire d’une table. Par exemple, une table Détails de la commande qui stocke les articles des commandes utilisera 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.

Pour la base de données des ventes de produits, vous pouvez créer une colonne NuméroAuto pour chacune des tables afin qu’elle serve de clé primaire : ProductID pour la table Produits, OrderID pour la table Commandes, CustomerID pour la table Clients et SupplierID pour la table Fournisseurs.

Haut de la page

Création des relations entre tables

Maintenant que vous avez divisé vos informations en tableaux, vous devez trouver un moyen de les rassembler de manière significative. Par exemple, le formulaire suivant contient des informations issues de plusieurs tables.

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

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

3. ... la table Commandes...

4. ... la table Produits...

5. ... et le tableau 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 dans des tables distinctes basées sur des sujets. Vous utilisez ensuite des relations de table pour rassembler les informations en fonction des besoins.

Haut de la page

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

Prenons l’exemple suivant : les tables Fournisseurs et Produits de la base de données Commandes de produits. Un fournisseur peut fournir n’importe quel nombre de produits. Il s’ensuit que pour tout fournisseur représenté dans la table Fournisseurs, de nombreux produits peuvent être représentés dans la table Produits. La relation entre la table Fournisseurs et la table Produits est donc une 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 en tant que 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 du fournisseur dans la table Produits pour rechercher le bon fournisseur 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 de la table Produits est une clé étrangère, car il s’agit également de la clé primaire de la table Fournisseurs.

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

Haut de la page

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

Examinez 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. Et pour chaque enregistrement de la table Produits, il peut y avoir de nombreux enregistrements dans la table Commandes. Ce type de relation est appelé relation plusieurs-à-plusieurs car, pour tout produit, il peut y avoir de nombreuses commandes ; Et pour toute 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 un 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 Réf produit à la table Commandes. Pour avoir plusieurs produits par commande, vous avez besoin de plusieurs enregistrements dans la table Commandes par commande. Vous répéteriez les informations d’ordre pour chaque ligne qui se rapporte à un seul ordre, ce qui entraînerait une conception inefficace qui pourrait conduire à des données inexactes. Vous rencontrez le même problème si vous placez le champ Réf commande dans la table Produits : vous auriez plusieurs enregistrements 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.

Chaque enregistrement de la table Détails de la commande représente une ligne d’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 champ Réf commande ne fonctionne pas comme clé primaire pour cette table, car une commande peut comporter plusieurs postes. L’ID de commande est répété pour chaque élément de ligne d’une commande, de sorte que le champ ne contient pas de valeurs uniques. L’utilisation du champ ID produit seul ne fonctionne pas non plus, car un produit peut apparaître sur de nombreuses 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 directement liées l’une à l’autre. Au lieu de cela, ils sont liés indirectement via 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 à l’aide de deux relations un-à-plusieurs :

• La table Commandes et la table Détails commandes ont une relation un-à-plusieurs. Chaque commande peut comporter plusieurs campagnes, mais chaque campagne n’est associée qu’à une seule commande.
• La table Produits et la table Détails commande ont une relation un-à-plusieurs. Chaque produit peut être associé à de nombreuses campagnes, mais chaque ligne fait référence à 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 :

Haut de la page

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

Un autre type de relation est la relation un-à-un. Par instance, supposons que vous deviez enregistrer des informations supplémentaires spéciales sur les produits dont vous aurez rarement besoin ou qui ne s’appliquent qu’à quelques produits. Étant donné que vous n’avez pas souvent besoin des informations et que le stockage des informations dans la table Produits générerait un espace vide pour chaque produit auquel elles ne s’appliquent pas, vous les placez dans une table distincte. Comme pour la table Products, 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 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 la nécessité d’une relation un-à-un dans votre base de données, demandez-vous si vous pouvez regrouper les informations des deux tables dans une seule table. Si vous ne souhaitez pas effectuer cette opération pour une raison quelconque, peut-être parce que cela entraînerait beaucoup d’espace vide, la liste suivante montre comment vous représenteriez la relation dans votre conception :

• Si les deux tables ont le même sujet, 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 ou l’autre) et insérez sa clé primaire dans l’autre table en tant que clé étrangère.

Déterminer les relations entre les tables vous permet de vous assurer que vous disposez des tables et colonnes appropriées. Lorsqu’une relation un-à-un ou un-à-plusieurs existe, les tables impliquées doivent partager une ou plusieurs colonnes communes. Lorsqu’il existe une relation plusieurs-à-plusieurs, une troisième table est nécessaire pour représenter la relation.

Haut de la page

Affiner la conception

Une fois que vous disposez des tables, des champs et des relations dont vous avez besoin, vous devez créer et remplir vos tables avec des exemples de données et essayer d’utiliser les informations : création de requêtes, ajout de nouveaux 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 pouvez avoir une table que vous devez fractionner en deux tables pour supprimer les doublons.

Voyez si vous pouvez utiliser la base de données pour obtenir les réponses souhaitées. Créez des brouillons de vos formulaires et états et vérifiez s’ils affichent les données que vous attendez. Recherchez les doublons inutiles de données et, si vous en trouvez, modifiez votre conception pour l’éliminer.

En testant votre base de données initiale, vous découvrirez probablement des possibilités d’amélioration. Voici quelques éléments à case activée :

• Avez-vous oublié des colonnes ? Si oui, les informations ont-elles leur place dans les tables existantes ? S’il s’agit d’informations concernant autre chose, vous devrez peut-être créer une autre table. Créez une colonne pour chaque élément d’information dont vous avez besoin faire 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 cela.
• Certaines 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 de détail, par exemple), il est généralement préférable de le faire et d’éviter de créer une colonne.
• Vous entrez régulièrement des informations en double dans l’un de vos tableaux ? Si tel est le cas, vous devez probablement diviser la table en deux tables ayant 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 tel est le cas, nous vous conseillons de repenser la table afin qu’elle contienne 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 créer, trier, rechercher ou calculer un élément d’information, placez cet élément dans sa propre colonne.
• Chaque colonne contient-elle un fait sur l’objet du tableau ? Si une colonne ne contient pas d’informations sur l’objet du tableau, elle appartient à une autre table.
• Toutes les relations entre 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, telle que les boissons, les condiments ou les fruits de mer. La table Produits peut inclure un champ indiquant la catégorie de chaque produit.

Supposons qu’après avoir examiné et affiné la structure de la base de données, vous décidiez d’enregistrer une description de la catégorie avec son nom. Si vous ajoutez un champ Description de la catégorie à la table Produits, vous devez répéter chaque description de catégorie pour chaque produit appartenant à la catégorie. Ce n’est pas une bonne solution.

Une meilleure solution consiste à faire des catégories un nouveau sujet de suivi par 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 vos tables, soyez à l’affût des groupes répétitifs. Prenons l’exemple d’un tableau contenant les colonnes suivantes :

• Réf produit
• Name (Nom)
• ID produit1
• Nom1
• ID produit2
• Nom2
• ID produit3
• Nom3

Ici, chaque produit est un groupe répétitif de colonnes qui ne diffère des autres que par l’ajout d’un nombre à la fin du nom de la colonne. Lorsque vous voyez des colonnes numérotées de cette façon, vous devez revoir votre conception.

Une telle conception présente plusieurs défauts. Pour commencer, cela vous oblige à placer une limite supérieure au nombre de produits. Dès que vous dépassez cette limite, vous devez ajouter un nouveau groupe de colonnes à la structure du tableau, ce qui représente une tâche administrative importante.

Un autre problème est que les fournisseurs qui ont moins de produits que le nombre maximum perdront de l’espace, car les colonnes supplémentaires seront vides. Le défaut le plus grave d’une telle conception est qu’elle rend de nombreuses tâches difficiles à effectuer, telles que le tri ou l’indexation de la table par ID ou nom de produit.

Chaque fois que vous voyez des groupes répétitifs, examinez attentivement la conception en gardant un œil sur la division de la table en deux. Dans l’exemple ci-dessus, il est préférable d’utiliser deux tables, l’une pour les fournisseurs et l’autre pour les produits, liées par l’ID 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) à l’étape suivante de votre conception. Utilisez ces règles pour voir si vos tables sont structurées 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 une fois que vous avez représenté tous les éléments d’information et que vous êtes parvenu à une conception préliminaire. L’idée est de vous aider à vous assurer que vous avez divisé vos éléments d’information dans les tableaux appropriés. Ce que la normalisation ne peut pas faire, c’est s’assurer que vous disposez de tous les éléments de données corrects pour commencer.

Vous appliquez les règles successivement, à chaque étape en veillant à ce que votre conception arrive à l’une de ce que l’on appelle les « formes normales ». Cinq formes normales sont largement acceptées - de la première forme normale à la cinquième forme normale. Cet article développe les trois premières, car elles sont tout ce qui est nécessaire pour la majorité des conceptions de bases de données.

Première forme normale

La première forme normale stipule qu’à chaque intersection de lignes et de colonnes de la table, il existe une valeur unique, et jamais une liste de valeurs. Par exemple, vous ne pouvez pas avoir un champ intitulé Prix dans lequel vous placez plusieurs prix. Si vous considérez chaque intersection de lignes et de colonnes comme une cellule, chaque cellule ne peut contenir qu’une seule valeur.

Deuxième forme normale

La deuxième forme normale exige que chaque colonne non clé dépende entièrement de la clé primaire entière, et non d’une partie seulement de la clé. Cette règle s’applique lorsque vous avez une clé primaire composée de plusieurs colonnes. Supposons, par exemple, que vous ayez une table contenant les colonnes suivantes, où l’ID de commande et l’ID de produit forment la clé primaire :

• Order ID (clé primaire)
• ID produit (clé primaire)
• Nom du produit

Cette conception viole la deuxième forme normale, car le nom du produit dépend de l’ID de produit, mais pas de l’ID de commande, de sorte qu’il ne dépend pas de la clé primaire entière. Vous devez supprimer le nom du produit de la table. Elle appartient à une autre table (Produits).

Troisième forme normale

La troisième forme normale exige que non seulement chaque colonne non clé dépende de la clé primaire entière, mais que les colonnes non clés soient indépendantes les unes des autres.

Une autre façon de le dire est que chaque colonne non clé doit dépendre de la clé primaire et rien d’autre que de la clé primaire. Par exemple, supposons que vous disposez d’un tableau contenant les colonnes suivantes :

• ProductID (clé primaire)
• Name (Nom)
• SRP
• taux_escompte

Supposons que la remise dépend du prix de vente conseillé (PDS). Cette table enfreint la troisième forme normale car une colonne non clé, Remise, dépend d’une autre colonne non clé, SRP. L’indépendance des colonnes signifie que vous devriez être en mesure de modifier n’importe quelle colonne non clé sans affecter les autres colonnes. Si vous modifiez une valeur dans le champ PDS, la remise sera modifiée en conséquence, enfreignant ainsi cette règle. Dans ce cas, la remise doit être déplacée vers une autre table dont la clé est SRP.

Haut de la page