Une base de données correctement conçue vous permet d’accéder à des informations à jour et précises. Étant donné qu’une conception correcte est essentielle pour atteindre vos objectifs dans l’utilisation d’une base de données, il est judicieux d’investir le temps nécessaire pour apprendre les principes d’une bonne conception. En fin de compte, vous êtes beaucoup plus susceptible 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 allez apprendre à déterminer les informations dont vous avez besoin, à diviser ces informations en tables et colonnes appropriées, et à déterminer 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
Access organise vos informations dans des tableaux : des listes de lignes et de colonnes rappelant le panneau d’un comptable 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 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 contenant des informations sur les clients.
Chaque ligne est plus correctement appelée 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 seul élément d’informations, 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.
À quoi reconnaît-on une bonne conception de base de données ?
Certains principes guident le processus de conception de base de données. Le premier principe est que les informations en double (également appelées données redondantes) sont incorrectes, 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é de l’information sont importantes. Si votre base de données contient des informations incorrectes, tous les rapports qui extrayent des informations de la base de données contiennent également des informations incorrectes. Par conséquent, toutes les décisions que vous prenez qui sont basées sur ces rapports seront alors mal renseignées.
Une bonne conception de base de données est donc celle qui :
-
Divise vos informations en tables basées sur l’objet pour réduire les données redondantes.
-
Fournit à Access les informations dont il a besoin pour joindre les informations des tables en fonction des besoins.
-
Permet de prendre en charge et de garantir l’exactitude et l’intégrité de vos informations.
-
S’adapter à vos besoins en matière de traitement des données et de création de rapports.
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 pour les étapes restantes.
-
Recherchez et organisez les informations requises
Rassemblez tous les types d’informations que vous souhaiterez peut-être enregistrer dans la base de données, comme 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 alors une table.
-
Transformer des éléments d’informations en colonnes
Déterminez les informations que vous souhaitez stocker dans chaque table. Chaque élément devient un champ et s’affiche sous la forme d’une colonne dans la table. Par exemple, une table Employees peut inclure des champs tels que Nom et Date d’embauche.
-
Spécifier des clés primaires
Sélectionnez la clé primaire de chaque table. La clé primaire est une colonne utilisée pour identifier chaque ligne de manière unique. Par exemple, l’ID de produit ou l’ID de commande.
-
Configurer les relations de table
Examinez chaque table et déterminez comment les données d’une table sont liées aux données des autres tables. Ajoutez des champs à des tables ou créez des tables pour clarifier les relations, si nécessaire.
-
Affiner votre conception
Analysez votre conception à la recherche d’erreurs. Créez les tables et ajoutez quelques enregistrements d’exemples de données. Vérifiez si vous pouvez obtenir les résultats souhaités à partir de vos tables. Apportez des ajustements à la conception, selon vos besoins.
-
Appliquer les règles de normalisation
Appliquez les règles de normalisation des données pour voir si vos tables sont correctement structurées. Apportez des ajustements aux tables, selon les besoins.
Détermination de l’objectif de votre base de données
Il est judicieux de noter l’objectif de la base de données sur papier : son objectif, la façon dont vous prévoyez de 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 des clients conserve une liste d’informations client 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 cela se produit souvent dans un environnement d’entreprise, l’objectif peut facilement être un paragraphe ou plus et doit indiquer quand et comment chaque personne utilisera la base de données. L’idée est d’avoir un énoncé de mission bien développé qui peut être référencé 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.
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 répertoriez chaque type d’informations affichées (par exemple, chaque zone que vous remplissez dans un formulaire). Si vous n’avez aucun formulaire existant, imaginez plutôt que vous devez concevoir un formulaire pour enregistrer les informations client. Quelle information mettez-vous sur le formulaire ? Quelles zones de remplissage créeriez-vous ? Identifiez et répertoriez chacun de ces éléments. Par exemple, supposons que vous conservez actuellement la liste des clients sur les cartes d’index. L’examen de ces cartes peut montrer que chaque carte contient un nom, 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 parfait au début. Au lieu de cela, répertoriez 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.
Ensuite, examinez les types de rapports ou de publipostages que vous souhaiterez peut-être produire à partir de la base de données. Par instance, vous pouvez avoir besoin d’un rapport sur les ventes de produits pour afficher les ventes par région, ou d’un rapport récapitulative des stocks qui indique 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. Quelle information placeriez-vous dans le rapport ? Répertorier chaque élément. Faites de même pour la lettre type et pour tout autre rapport que vous prévoyez de créer.
Réfléchir aux rapports et aux publipostages que vous souhaiterez peut-être créer vous aide à identifier les éléments dont vous aurez besoin dans votre base de données. Par exemple, supposons que vous donnez aux clients la possibilité d’accepter (ou de refuser) les mises à jour périodiques par 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 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 devez également connaître l’adresse de messagerie à laquelle les envoyer. Par conséquent, vous devez enregistrer une adresse de messagerie pour chaque client.
Il est judicieux de construire un prototype de chaque rapport ou liste de sortie et d’examiner les éléments dont vous aurez besoin pour produire le rapport. Par instance, lorsque vous examinez une lettre type, quelques éléments peuvent vous venir à l’esprit. Si vous souhaitez inclure une salutation appropriée , par exemple, la chaîne « M. », « Mme » ou « Ms. » qui démarre un message d’accueil, vous devrez créer un élément de salutation. En outre, vous pouvez généralement commencer une lettre par « Cher M. Smith », plutôt que « Cher. M. Sylvester Smith ». Cela suggère que vous souhaitez généralement stocker le nom séparément du prénom.
Un point clé à retenir est que vous devez diviser chaque élément d’information en ses plus petites parties utiles. Dans le cas d’un nom, pour rendre le nom facilement disponible, vous allez diviser le nom en deux parties : Prénom et Nom. Pour trier un rapport par nom, par exemple, il est utile que le nom du client soit stocké séparément. En général, si vous souhaitez trier, rechercher, calculer ou créer un rapport en fonction d’un élément d’informations, 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 fermé le mois dernier ? Où habitent vos meilleurs clients ? Qui est le fournisseur de votre produit le plus vendu ? L’anticipation de ces questions vous aide à revenir sur des éléments supplémentaires à enregistrer.
Après avoir collecté ces informations, vous êtes prêt à passer à l’étape suivante.
Division des informations en tables
Pour diviser les informations en tables, choisissez les entités ou les 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 se présenter comme suit :
Les principales entités présentées ici sont les produits, les fournisseurs, les clients et les commandes. Par conséquent, il est judicieux 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, il s’agit d’un bon point de départ. Vous pouvez continuer à affiner cette liste jusqu’à ce que vous ayez une conception qui fonctionne correctement.
Lorsque vous examinez pour la première fois la liste préliminaire des éléments, 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 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. Étant donné que 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. L’enregistrement des informations sur les fournisseurs une seule fois dans une table Suppliers distincte, puis la liaison de cette table à la table Products, est une bien meilleure solution.
Un deuxième problème avec cette conception se produit 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 dans 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 vous retrouvez à répéter les mêmes informations à plusieurs endroits, comme 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 souhaitez supprimer le produit, mais que vous conservez le nom et l’adresse du fournisseur. Comment supprimer l’enregistrement du produit sans perdre également les informations sur le fournisseur ? C’est impossible. Étant donné que chaque enregistrement contient des faits 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 diviser 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 faits sur le produit, et non les faits sur le fournisseur.
Une fois que vous avez choisi l’objet représenté par une table, les colonnes de cette table doivent stocker des faits uniquement sur le sujet. Par instance, la table de produits doit stocker des faits uniquement sur les produits. Étant donné que l’adresse du fournisseur est un fait concernant le fournisseur, et non un fait sur le produit, elle appartient à la table des fournisseurs.
Transformation d’éléments d’informations en colonnes
Pour déterminer les colonnes d’une table, déterminez les informations que vous devez suivre sur le sujet enregistré dans la table. Par exemple, pour la table Customers, Name, Address, City-State-Zip, Send e-mail, Salutation 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, ce qui vous permet de stocker les informations Nom, Adresse, Ville-État-Zip, Envoyer un e-mail, Salutation et Adresse de messagerie pour chaque enregistrement. Par exemple, la colonne d’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 logique de stocker le nom du client sous la forme de 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 fait de cinq composants distincts : adresse, ville, état, code postal et pays/région, et il est également judicieux 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 des informations d’état stockées dans une colonne distincte.
Vous devez également déterminer si la base de données contiendra des informations d’origine nationale uniquement, ou internationale, ainsi. Par instance, si vous envisagez de stocker des adresses internationales, il est préférable d’avoir une colonne Région au lieu de l’État, car une telle colonne peut prendre en charge 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 allez 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 sorte qu’Access effectue les calculs lorsque vous souhaitez voir le résultat. Par exemple, supposons qu’il existe un rapport Products On Order qui affiche le sous-total des unités sur commande pour chaque catégorie de produit dans la base de données. Toutefois, il n’existe aucune colonne de sous-total Units On Order dans une table. Au lieu de cela, la table Products inclut une colonne Units On Order qui stocke les unités sur 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.
-
Stocker les informations dans leurs plus petites parties logiques
Vous pouvez ê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 par la suite. 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 du produit, la catégorie et la description.
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.
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. Dans la terminologie de base de données, ces informations sont appelées clé primaire de la table. Access utilise des champs de clé primaire pour associer rapidement des données de plusieurs tables et rassembler les données pour vous.
Si vous disposez déjà d’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 utiliser cet identificateur comme clé primaire de la table, mais uniquement si les valeurs de cette colonne seront toujours différentes pour chaque enregistrement. Vous ne pouvez pas avoir de valeurs en double dans une clé primaire. Par exemple, n’utilisez pas les noms des personnes comme clé primaire, car les noms ne sont pas uniques. Vous pouvez 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 non attribué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 changera pas réduit le risque que la clé primaire ne soit pas synchronisée avec les autres tables qui la référencent.
Souvent, un nombre unique arbitraire est utilisé comme clé primaire. Par exemple, vous pouvez attribuer à chaque commande un numéro de commande unique. Le seul objectif du numéro de commande est d’identifier une commande. Une fois attribué, il ne change jamais.
Si vous n’avez pas à l’esprit une colonne ou un ensemble de colonnes susceptibles de constituer une clé primaire correcte, envisagez d’utiliser une colonne qui a le type de données NuméroAuto. Lorsque vous utilisez le type de données NuméroAuto, Access vous attribue automatiquement une valeur. Un tel identificateur est sans faits ; il ne contient aucune information factuelle décrivant la ligne qu’il représente. Les identificateurs factless sont idéaux pour une utilisation en tant que clé primaire, car ils ne changent pas. Une clé primaire qui contient des faits sur 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 elles-mêmes peuvent changer.
1. Une colonne définie sur le type de données NuméroAuto est souvent une bonne clé primaire. 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 Order Details qui stocke les éléments de ligne pour les commandes utilise 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éroAuto pour chacune des tables à utiliser comme clé primaire : ProductID pour la table Products, OrderID pour la table Orders, CustomerID pour la table Customers et SupplierID pour la table Suppliers.
Création des relations de table
Maintenant que vous avez divisé vos informations en tableaux, vous avez besoin d’un moyen de regrouper les informations de manière significative. Par exemple, le formulaire suivant contient des informations provenant de plusieurs tables.
1. Les informations de ce formulaire proviennent de la table Clients...
2. ... la table Employees...
3. ... la table Orders...
4. ... la table Products...
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 des relations de table pour rassembler les informations en fonction des besoins.
Création d’une relation un-à-plusieurs
Prenons l’exemple suivant : les tables Suppliers et Products dans la base de données des 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 Suppliers, il peut y avoir de nombreux produits représentés dans la table Products. La relation entre la table Suppliers et la table Products est donc une relation un-à-plusieurs.
Pour représenter une relation un-à-plusieurs dans votre conception de base de données, prenez la clé primaire du côté « un » de la relation et ajoutez-la en tant que colonne ou colonnes supplémentaires à la table du côté « plusieurs » de la relation. Dans ce cas, par exemple, vous ajoutez la colonne Id de fournisseur de la table Suppliers à la table Products. Access peut ensuite utiliser le numéro d’identification du fournisseur dans la table Produits pour localiser le fournisseur approprié pour chaque produit.
La colonne Id du fournisseur dans la table Products est appelée clé étrangère. Une clé étrangère est la clé primaire d’une autre table. La colonne Id du fournisseur dans la table Products est une clé étrangère, car elle est également la clé primaire de la table Suppliers.
Vous fournissez la base pour joindre des tables associées en établissant des paires de clés primaires et de clés é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écessitent effectivement une colonne partagée.
Création d’une relation plusieurs-à-plusieurs
Considérez la relation entre la table Products et la table Orders.
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 Products, il peut y avoir de nombreux enregistrements dans la table Orders. Ce type de relation est appelé relation plusieurs-à-plusieurs, car pour n’importe quel 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 Id de 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 de commande pour chaque ligne qui se rapporte à un ordre unique, ce qui entraînerait une conception inefficace qui pourrait entraîner des données inexactes. Vous rencontrez le même problème si vous placez le champ ID de commande dans la table Produits : vous auriez plusieurs enregistrements dans la table Products 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 un élément de ligne sur une commande. La clé primaire de la table Order Details se compose de deux champs : les clés étrangères des tables Orders et Products. L’utilisation du champ ID de commande seul ne fonctionne pas comme clé primaire pour cette table, car une commande peut avoir plusieurs éléments de ligne. 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 de 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 Orders et la table Products ne sont pas directement liées. Au lieu de cela, ils sont liés indirectement par le biais 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 à l’aide de deux relations un-à-plusieurs :
-
La table Orders et la table Order Details ont une relation un-à-plusieurs. Chaque commande peut avoir plusieurs articles de ligne, mais chaque élément de ligne n’est connecté qu’à une seule commande.
-
La table Products et la table Order Details ont une relation un-à-plusieurs. De nombreux éléments de ligne peuvent être associés à chaque produit, mais chaque élément de ligne fait référence à un seul produit.
À partir de 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 d’un produit particulier.
Après avoir incorporé la table Détails de la commande, la liste des tables et des champs peut ressembler à ceci :
Création d’une relation un-à-un
Un autre type de relation est la relation un-à-un. Par instance, supposons que vous devez 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 Products entraînerait un espace vide pour chaque produit auquel elle ne s’applique pas, vous les placez dans une table distincte. À l’instar de la table Products, vous utilisez productID comme clé primaire. La relation entre cette table supplémentaire et la table Product est une relation un-à-un. Pour chaque enregistrement de la table Product, 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 la nécessité d’une relation un-à-un dans votre base de données, déterminez si vous pouvez regrouper les informations des deux tables dans une même table. Si vous ne voulez pas le faire 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 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 ou l’autre) 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 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’une relation plusieurs-à-plusieurs existe, une troisième table est nécessaire pour représenter la relation.
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 suivantes : 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 pendant la phase de conception, ou vous avez peut-être une table que vous devez diviser en deux tables pour supprimer la duplication.
Vérifiez si vous pouvez utiliser la base de données pour obtenir les réponses souhaitées. Créez des brouillons approximatifs de vos formulaires et rapports et vérifiez s’ils affichent les données attendues. Recherchez une duplication inutile des données et, lorsque vous en trouvez, modifiez votre conception pour les éliminer.
Lorsque vous essayez 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 c’est le cas, les informations appartiennent-elles aux tables existantes ? S’il s’agit d’informations sur un autre élément, vous devrez peut-être créer une autre table. Créez une colonne pour chaque élément d’informations que vous devez suivre. Si les informations ne peuvent pas être calculées à partir d’autres colonnes, il est probable que vous en aurez besoin.
-
Des 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.
-
Entrez-vous à plusieurs reprises des informations en double dans l’une de vos tables ? Si c’est le cas, vous devez 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, envisagez de reconcevoir la table afin 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 un fait sur l’objet de la table ? Si une colonne ne contient pas d’informations sur l’objet 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.
Affiner la table Products
Supposons que chaque produit de la base de données des ventes de produits relève d’une catégorie générale, comme les boissons, les condiments ou les fruits de mer. La table Products 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écidez de stocker une description de la catégorie avec son nom. Si vous ajoutez un champ Description de catégorie à la table Products, vous devez répéter chaque description de catégorie pour chaque produit qui appartient à la catégorie , ce n’est pas une bonne solution.
Une meilleure solution consiste à faire des catégories un nouveau sujet pour la base de données à suivre, avec sa propre table et sa propre clé primaire. Vous pouvez ensuite ajouter la clé primaire de la table Categories à la table Products en tant que clé étrangère.
Les tables Categories et Products 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 passez en revue les structures de votre table, soyez à la recherche de groupes récurrents. Prenons l’exemple d’une table contenant les colonnes suivantes :
-
Réf produit
-
Name (Nom)
-
ID de produit1
-
Nom1
-
ID de produit2
-
Nom2
-
ID de produit3
-
Nom3
Ici, chaque produit est un groupe répétitif de colonnes qui diffère des autres uniquement en ajoutant un nombre à la fin du nom de 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, il vous oblige à 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 table, ce qui constitue une tâche administrative majeure.
Un autre problème est que les fournisseurs qui ont moins que le nombre maximal de produits gaspillent 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 de produit ou nom.
Chaque fois que vous voyez des groupes répétitifs, examinez attentivement la conception en veillant à fractionner 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 id de fournisseur.
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 de votre conception. Vous utilisez ces règles pour voir si vos tables sont correctement structurées. Le processus d’application des règles à votre conception de 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 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 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 des « formes normales ». Cinq formes normales sont largement acceptées - la première forme normale à la cinquième forme normale. Cet article s’étend sur les trois premiers, car ils sont tout ce qui est nécessaire pour la majorité des conceptions de base de données.
Première forme normale
La première forme normale indique qu’à chaque intersection de ligne et de colonne dans la table, il existe une valeur unique et jamais une liste de valeurs. Par exemple, vous ne pouvez pas avoir un champ nommé Price 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 pas seulement d’une partie de la clé. Cette règle s’applique lorsque vous avez une clé primaire composée de plusieurs colonnes. Par exemple, supposons que vous disposez d’une table contenant les colonnes suivantes, où l’ID de commande et l’ID de produit forment la clé primaire :
-
ID de commande (clé primaire)
-
ID de produit (clé primaire)
-
Nom du produit
Cette conception ne respecte pas la deuxième forme normale, 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 Product Name de la table. Il appartient à une autre table (Products).
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’une table contenant les colonnes suivantes :
-
ProductID (clé primaire)
-
Name (Nom)
-
SRP
-
taux_escompte
Supposons que la remise dépend du prix de vente au détail (SRP) suggéré. Cette table ne respecte pas 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 devez être en mesure de modifier une colonne non clé sans affecter d’autres colonnes. Si vous modifiez une valeur dans le champ SRP, la remise change en conséquence, ce qui enfreint cette règle. Dans ce cas, la remise doit être déplacée vers une autre table qui est clé sur SRP.
