Concepts de Base sur la Conception d’une Base de Données

Une base de données correctement conçue vous permet d’accéder à des informations à jour et précises.

Vous allez apprendre à déterminer quelles sont les informations dont vous avez besoin, comment diviser ces informations dans les tables et colonnes appropriées et comment ces tables doivent être liées entre elles.

Important : Access fournit des expériences de conception qui vous permettent de créer des applications de base de données pour le site Web. Plusieurs éléments de conception sont différents lors de la création pour le Web. Cet article n’aborde conception d’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.

Les termes à connaître

Access organise les informations en tables : listes de lignes et colonnes rappelant les livres de comptabilité ou d’une feuille de calcul. Dans une base de données simple, vous pouvez avoir une seule table. Pour la plupart des bases de données, vous devrez en avoir 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 avec les informations relatives aux clients.

Image illustrant trois tables dans des feuilles de données

Chaque ligne est plus correctement appelée un enregistrement et chaque colonne, un champ. Un enregistrement est un moyen cohérent pour combiner des informations sur un élément. Un champ est un seul élément d’information : 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 conserve un certain type d’informations relatives à ce produit, par exemple 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 des informations en double (également appelées données redondantes ou doublons) sont incorrectes, car elles consomment de l’espace et augmentent la probabilité d’erreurs et d’incohérences. Le deuxième principe est l’exactitude et l’intégralité des informations importantes. Si votre base de données contient des informations incorrectes, tous les rapports qui extraient des informations à partir de la base de données contiendra également des informations incorrectes. Par conséquent, les décisions que vous prenez basées sur ces rapports seront de mauvaises informations.

Et donc, une conception appropriée de base de données :

  • Divise les informations en tables basée sur l’objet pour réduire les données redondantes.
  • Offre un accès avec les informations nécessaires pour joindre les informations dans les tables selon vos besoins.
  • Vous aide à prendre en charge et garantir la précision et l’intégrité de vos informations.
  • Prend en charge le traitement de vos données et rapports.

Le processus de conception

Le processus de conception se compose des étapes suivantes :

  • Déterminer l’objectif de votre base de données. Cela vous permet de vous préparer pour les étapes restantes.
  • Rechercher et organiser les informations requises. Rassembler toutes les types d’informations que vous souhaiterez peut-être enregistrer dans la base de données, telles que nom et commande numéro de produit.
  • Diviser des informations dans des tables. Diviser vos éléments d’information en entités ou sujets, tels que les produits ou commandes principaux. Chaque sujet devient ensuite une table.
  • Transformer des éléments d’information en colonnes. Déterminer quelles sont les informations que vous voulez 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-être inclure des champs tels que le nom et la Date d’embauche.
  • Spécifier les clés primaires. Sélectionner la clé primaire de chaque table. La clé primaire est une colonne qui est utilisée pour identifier de façon unique chaque ligne. Un exemple peut être Réf produit ou numéro de commande.
  • Configurer les relations entre tables. Examiner chaque table et déterminer comment les données dans une table sont liées aux données dans les autres tables. Ajouter des champs dans les tables ou créer des tables pour clarifier les relations, comme bon vous semble.
  • Affiner votre structure. Analyser votre conception et réduire les erreurs. Créer des tables et ajouter plusieurs enregistrements d’exemples de données. Voir si vous pouvez obtenir les résultats souhaités de vos tables. Apporter des corrections à la conception, selon vos besoins.
  • Appliquer les règles de normalisation. Appliquer les règles de normalisation de données pour voir si vos tables sont structurées correctement. Ajuster les tables, selon vos besoins.

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

Il est recommandé de noter l’objectif de la base de données sur du papier, comment vous souhaitez l’utiliser et qui l’utiliseront. Pour une petite base de données d’entreprise par exemple, vous pouvez écrire une phrase simple telles que « la base de données client conserve une liste des informations relatives aux publipostage et rapports clients ». Si la base de données est plus complexe ou est utilisée par plusieurs personnes, l’objectif peut être facilement un paragraphe ou plus et doit inclure quand et comment chaque personne utilisera la base de données.

Recherche et organiser les informations requises

Pour rechercher et organiser les informations requises, commencez par les informations existantes. Par exemple, vous pouvez enregistrer des commandes d’achat dans un livre ou conserver des informations clients sur formulaires papier en formulaires dans un classeur. Rassemblez ces documents et la liste de chaque type d’informations affichées (par exemple, chaque zone que vous remplissez un formulaire). Si vous n’avez pas tous les formulaires existants, imaginons plutôt que vous devez concevoir un formulaire pour enregistrer les informations du client. Quelles sont les informations que vous insérez dans la feuille ? Quelles zones Fill-in vous créer ? Identifier et chacun de ces éléments de la liste. Par exemple, supposons que vous conservez actuellement la liste des clients sur des fiches. Chacun de ces peut faire apparaître que chaque carte contient clients nom, adresse, ville, état, code postal et le 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 parfait par la première. En revanche, liste de chaque élément qui vient à l’esprit. Si quelqu’un d’autre envisagez d’utiliser la base de données, demandez à leurs idées, trop. Vous pouvez affiner cette liste ultérieurement.

Ensuite, envisagez les types de rapports ou de publipostage, que vous souhaiterez peut-être produire à partir de la base de données. Par exemple, vous souhaiterez un état des ventes pour afficher les ventes par région ou un rapport de synthèse inventaire qui affiche des niveaux d’inventaire de produit. Vous souhaiterez également générer des lettres à envoyer aux clients qui annoncer un événement commercial ou vous propose une prime. Conception rapport avis et imaginer à quoi il ressemblera. Quelles sont les informations vous placer sur le rapport ? Chaque élément de liste. Procédez de même pour les lettres et pour tout autre état que vous envisagez de créer.

Une personne imaginant un état pour un stock

Le fait de réfléchir aux États et publipostage que vous souhaiterez peut-être créer vous permet d’identifier les éléments que vous aurez besoin dans votre base de données. Par exemple, supposons que vous donnez la possibilité de recevoir (ou hors de) clients mises à jour périodiques par courrier électronique et que vous voulez imprimer une liste de ceux qui ont choisi de participer. Pour enregistrer ces informations, vous ajoutez une colonne « Envoyer un courrier électronique » dans la table customer. Pour chaque client, vous pouvez définir le champ à Oui ou non.

La configuration minimale requise pour envoyer des messages électroniques à des clients qui suggère d’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 auquel vous souhaitez leur envoyer. Par conséquent, vous devez enregistrer une adresse de messagerie pour chaque client.

Il convient de créer un prototype chaque état ou listing et prendre en compte les éléments que vous devrez générer le rapport. Par exemple, lorsque vous examinez une lettre type, quelques points se poser à l’esprit. Si vous voulez inclure une salutation — par exemple, la chaîne « M. », « Madame » ou « Ms. » qui démarre un message d’accueil, vous devrez créer un élément de la formule de politesse. En outre, vous devrez donc créer une lettre « Cher M. Dupont », au lieu de « cher. M. Sylvester Dupont ». Cela signifie que généralement souhaité stocker le nom de famille séparément du prénom.

Un point clé à retenir est l’on chacune des informations en parties plus petit utiles. Dans le cas d’un nom, pour rendre le nom de famille disponibles, vous sauts de page le nom en deux parties : prénom et nom de famille. Pour trier un rapport en fonction du nom, par exemple, il est utile d’avoir le nom du client stocké séparément. En général, si vous voulez trier, rechercher, calculer ou rapport basé sur un élément d’information, vous devez placer cet élément dans son propre champ.

Pensez aux questions souhaitées pour répondre à la base de données. Par exemple, le nombre de ventes de votre produit proposée vous fermez le mois dernier ? Résident des vos meilleurs clients Qui est le fournisseur de votre produit meilleures ? Anticipant vous aide à zéro dans sur éléments supplémentaires à enregistrer.

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

Diviser les informations dans des tables

Pour diviser les informations dans des tables, sélectionnez les entités principales, ou les sujets. Par exemple, après la recherche et organiser 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 illustrées ici sont les produits, les fournisseurs, les clients et les commandes. Par conséquent, il est préférable de commencez avec ces quatre tables : pour stocker les faits relatives aux produits, une pour les fournisseurs, clients et pour stocker les faits concernant les commandes. Bien que cela ne termine la liste, il est un bon point de départ. Vous pouvez continuer à affiner cette liste jusqu’à ce que vous avez une conception qui fonctionne bien.

Lorsque vous passez en revue la liste préliminaire des éléments, vous serez peut-être tenté de les placer au sein d’une table unique, au lieu des quatre indiqué dans l’illustration précédente. Vous allez apprendre ici pourquoi qui est une mauvaise idée. Prenons un moment sur la table illustrée ici :

Image illustrant une table contenant des produits et des fournisseurs

Dans ce cas, chaque ligne contient des informations sur le produit et à ses fournisseurs. Étant donné que vous pouvez avoir plusieurs produits du fournisseur même, les informations de nom et l’adresse du fournisseur doit être répété autant de fois. Cela fait perdre d’espace disque. Enregistrer les informations de fournisseur qu’une seule fois dans une table de fournisseurs distincte, puis en liant cette table à la table Products, sont une bien meilleure solution.

Un deuxième problème avec ce modèle est fourni lorsque vous avez besoin de modifier les informations sur le fournisseur. Par exemple, supposons que vous devez modifier l’adresse d’un fournisseur. Parce qu’il apparaît dans de nombreux endroits, vous pouvez accidentellement modifier l’adresse en un seul endroit mais oublier de la modifier dans les autres colonnes. L’enregistrement d’adresse du fournisseur dans un seul endroit permet de résoudre le problème.

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

Enfin, ne Supposons qu’un seul produit fournie par Coho Winery, et que vous voulez supprimer le produit, mais conserver les informations de nom et l’adresse du fournisseur. Comment faire pour supprimer l’enregistrement du produit sans perdre également des informations sur les fournisseur ? Vous ne pouvez pas. Étant donné que chaque enregistrement contient des faits sur un produit, ainsi que des faits sur un fournisseur, vous ne pouvez pas supprimer un sans supprimer l’autre. Pour que ces faits distincte, vous devez diviser la table en deux : une table pour les informations sur le produit et une autre table pour les informations fournisseur. Suppression d’un enregistrement de produit doit supprimer uniquement les faits sur le produit, pas les faits concernant le fournisseur.

Une fois que vous avez choisi l’objet qui est représenté par une table, colonnes dans les tableaux doivent stocker des faits concernant uniquement ce sujet. Par exemple, la table product doit stocker des faits uniquement sur les produits. Étant donné que l’adresse d’un fournisseur est un fait concernant un fournisseur et non un fait concernant le produit, il appartient dans la table fournisseur.

Transformer les éléments d’information en colonnes

Pour déterminer les colonnes dans une table, déterminez quelles sont les informations que vous devez suivre concernant le sujet enregistrement dans la table. Par exemple, pour la table Customers, nom, adresse, ville-code postal, envoyer courrier électronique, Salutation et adresse de messagerie comprennent une bonne liste départ de colonnes. Chaque enregistrement dans la table contient le même jeu de colonnes, vous pouvez y stocker nom, adresse, ville-code postal, envoyer un courrier électronique, Salutation et adresse de messagerie d’informations pour chaque enregistrement. Par exemple, la colonne adresse contienne les adresses de clients. Chaque enregistrement contient des données sur un client et le champ adresse contient l’adresse de ce client.

Une fois que vous avez déterminé le premier jeu de colonnes pour chaque table, vous pouvez affiner davantage les colonnes. Par exemple, il est préférable d’enregistrer le nom du client dans deux colonnes distinctes : prénom et nom de famille, afin que vous puissiez trier, rechercher et index uniquement les colonnes. De même, l’adresse se compose 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 recherche, l’opération de filtrage ou de tri par état, par exemple, vous devez les informations d’état stockées dans une colonne distincte.

Vous devez également envisager si la base de données contiendra des informations qui sont d’origine intérieure uniquement ou international, ainsi que. Par exemple, si vous prévoyez de stocker des adresses internationales, il est préférable d’avoir une colonne région au lieu de l’état, car ce type de colonne peut prendre en charge les États appels nationaux et les zones d’autres pays et régions. De même, Code Postal plus judicieux que le Code postal si vous vous apprêtez à stocker des adresses internationales.

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

  • Ne pas inclure de données calculéesDans la plupart des cas, vous ne devez pas stocker le résultat de calculs dans les tables. À la place, vous pouvez avoir accès effectuer les calculs lorsque vous voulez afficher le résultat. Par exemple, un rapport de produits dans l’ordre qui affiche le sous-total des unités de commande pour chaque catégorie de produit dans la base de données. Toutefois, il n’existe aucune colonne sous-total unités commandées dans n’importe quelle table. En revanche, la table Products inclut une colonne Unités commandées qui stocke les unités de commande pour chaque produit. À l’aide de ces données, Access calcule le sous-total de chaque fois que vous imprimez le rapport. Le sous-total lui-même ne doit pas être stocké dans un tableau.
  • Stocker les informations dans sa plus petite partie logiqueVous pouvez être tenté d’avoir un seul champ des noms complets ou des noms de produits ainsi que les descriptions de produits. Si vous combinez plusieurs types d’informations figurant dans un champ, il est difficile de récupérer des éléments individuels ultérieurement. Essayer d’identifier des informations en plusieurs parties logiques ; par exemple, créer des champs distincts pour Prénom et le nom, ou description, la catégorie et nom du produit.

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

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

Définition 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 généralement d’un numéro d’identification unique, par exemple un numéro d’identification employé ou un numéro de série. Dans la terminologie de base de données, ces informations sont appelées la clé primaire de la table. Access utilise les champs de clé primaire pour associer des données issues de plusieurs tables rapidement et rassembler les données à votre place.

Si vous disposez déjà d’un identificateur unique pour un tableau, par exemple un numéro de produit qui identifie de façon unique chaque produit d’un catalogue, vous pouvez l’utiliser comme clé primaire de la table, mais uniquement si les valeurs de cette colonne seront toujours différentes pour chaque enregistrement. Vous ne peut pas contenir des valeurs en double dans une clé primaire. Par exemple, n’utilisez pas des noms de personnes comme clé primaire, étant donné que 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 contenir une valeur. Si la valeur d’une colonne peut devenir non attribuée ou inconnu (valeur manquante) à un moment donné, il ne peut pas être utilisé en tant que composant dans une clé primaire.

Vous devez toujours choisir une clé primaire dont la valeur est inchangée. Dans une base de données qui utilise plusieurs tables, clé primaire d’une table peut être utilisée comme une référence dans les autres tables. Si la clé primaire est modifiée, la modification doit également être appliquée tous les emplacements où que la clé est référencée. Utiliser une clé primaire ne modifie pas réduit le risque que la clé primaire ne soit pas synchronisée avec d’autres tables faisant référence à celle-ci.

Souvent, un nombre unique arbitraire est utilisé comme clé primaire. Par exemple, vous pouvez affecter chaque commande un numéro de commande unique. Objectif uniquement du numéro commande est d’identifier un ordre. Une fois qu’affecté, il se transforme jamais.

Si vous n’avez pas à l’esprit une colonne ou un ensemble de colonnes qui peuvent faire une clé primaire appropriée, envisagez d’utiliser une colonne qui comporte le type de données NuméroAuto. Lorsque vous utilisez le type de données NuméroAuto, Access affecte automatiquement une valeur à votre place. Identificateur est liées à des faits ; Il contient pas d’informations décrivant la ligne qu’elle représente. Identificateurs conviennent sont parfaits pour utiliser comme clé primaire car ils ne changent pas. Une clé primaire qui contient des éléments sur une ligne, un numéro de téléphone ou un nom de client, par exemple — est plus susceptible de changer, car ce type d’information peut-être changer.

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

1. une colonne définie sur le type de données NuméroAuto souvent constitue une clé primaire appropriée. Aucun numéro de produit n’est identiques.

Dans certains cas, il pouvez que vous souhaitez utiliser deux ou plusieurs champs qui, ensemble, fournissent la clé primaire d’une table. Par exemple, une table Détails commande qui stocke les lignes utiliseriez deux colonnes dans sa clé primaire : N° commande et ID de produit. Lorsqu’une clé primaire utilise plusieurs colonnes, il est également appelée une clé composite.

Pour la base de données de ventes de produit, vous pouvez créer une colonne NuméroAuto pour chacune des tables pour servir de clé primaire : ProductID pour la table Products, OrderID pour les commandes de tableau, CustomerID pour la table Customers et numéro de fournisseur pour la table fournisseurs.

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

Création de relations entre les tables

À présent que vous avez réparti vos informations dans des tables, vous recherchez un moyen réunir les informations de manière significative. Par exemple, sous la forme suivante inclut des informations à partir de plusieurs tables.

Le formulaire Commandes

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

2… table employés .la…

3… .la la table commandes…

4… table products .la…

5. … sont correctes la table Détails commande.

L’accès est un système de gestion de base de données relationnelle. Dans une base de données relationnel, vous divisez vos informations en tables distinctes par sujet. Vous utilisez puis relations de table pour rassembler les informations selon vos besoins.

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

Prenons l’exemple : les tables fournisseurs et produits du produit des commandes de base de données. Un fournisseur peut fournir un nombre quelconque de produits. Il suit pour tout fournisseur représenté dans la table fournisseurs, il peut y avoir plusieurs produits 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 votre conception de base de données, appliquer à la clé primaire du côté « un » de la relation et ajoutez-la comme une colonne supplémentaire ou des colonnes à la table du côté « plusieurs » de la relation. Dans ce cas, par exemple, vous ajoutez la colonne Réf fournisseur de la table fournisseurs à la table Products. Access peut utiliser ensuite le numéro d’identification de la table produits pour trouver le fournisseur pour chaque produit.

La colonne Réf 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 Réf fournisseur dans la table Products est une clé étrangère, car il est également la clé primaire dans la table fournisseurs.

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

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

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

Considérez la relation entre la table produits et la table Orders.

Une seule commande peut inclure plusieurs produits. En revanche, un seul produit peut apparaître dans plusieurs commandes. Par conséquent, vous pouvez avoir plusieurs enregistrements dans la table produits pour chaque enregistrement dans la table Orders. Et pour chaque enregistrement dans la table produits, il peut y avoir plusieurs enregistrements dans la table Orders. Ce type de relation est appelé relation plusieurs-à-plusieurs comme pour n’importe quel produit, il peut y avoir plusieurs commandes ; et pour n’importe quel ordre, il peut y avoir plusieurs produits. Notez que pour détecter les relations plusieurs-à-plusieurs entre les tables, il est important de tenir compte des deux côtés de la relation.

Les sujets des deux tables — commandes et produits — ont une relation plusieurs-à-plusieurs. Ceci pose un problème. Pour mieux comprendre le problème, imaginons que se passe-t-il si vous avez essayé de créer la relation entre les deux tables en ajoutant le champ Réf produit à la table Orders. Pour avoir plusieurs produits par commande, vous devez plusieurs enregistrements dans la table Orders par ordre. Il vous faudra répéter informations sur la commande pour chaque ligne est liée à une commande unique, ce qui entraîne une conception inefficace peut entraîner des données inexactes. Vous rencontrez le même problème lorsque vous placez le champ N° commande dans la table produits — vous aurez plusieurs enregistrements dans la table produits pour chaque produit. Comment pour résoudre ce problème ?

La réponse consiste à créer une troisième table, souvent appelée une table de jonction, qui décompose la relation plusieurs-à-plusieurs en deux relations un-à-plusieurs. Vous insérez la clé primaire de chacune des deux tables dans la troisième table. 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 commande représente un article sur une commande. Clé primaire de la table Détails commande est constituée de deux champs — les clés étrangères des commandes et les tables de produits. Le champ N° commande seul ne fonctionne pas comme clé primaire pour cette table, car une commande peut avoir plusieurs articles. Le code de commande est répété pour chaque ligne d’une commande, afin que le champ ne contient des valeurs uniques. En utilisant le champ Réf produit seul ne pas non plus car un produit peut apparaître dans plusieurs commandes différentes. Mais ensemble, les deux champs produisent toujours une valeur unique pour chaque enregistrement.

Dans la base de données de ventes de produits, la table commandes et la table Products ne sont pas liés entre eux directement. En revanche, elles sont liées indirectement via la table Détails commande. La relation plusieurs-à-plusieurs entre les commandes et produits est représentée dans la base de données en utilisant deux relations un-à-plusieurs :

  • La table commandes et la table Détails commande ont une relation un-à-plusieurs. Chaque commande comporte plusieurs éléments de ligne, mais chaque ligne de facturation est connecté à une commande.
  • La table produits et la table Détails commande ont une relation un-à-plusieurs. Chaque produit peut avoir plusieurs lignes de facturation associés, mais chaque ligne de facturation fait référence à qu’un seul produit.

À partir de la table Détails commande, vous pouvez déterminer tous les produits dans un ordre en particulier. Vous pouvez également déterminer toutes les commandes d’un produit spécifique.

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

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

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

Un autre type de relation est la relation. Par exemple, supposons que vous avez besoin d’enregistrer des informations de produit supplémentaires spécial dont vous aurez besoin rarement ou qui s’applique uniquement à quelques produits. Vous n’avez pas besoin les informations souvent, et parce que stocker les informations dans la table Products entraînerait dans un espace vide pour chaque produit auquel il ne s’applique pas, placez-le dans une table distincte. À la table produits, vous utilisez l’ID de produit comme clé primaire. La relation entre cette table supplémentaire et la table Product est une relation. Pour chaque enregistrement dans la table Product, il existe un seul enregistrement dans la table supplémentaire. Lorsque vous identifiez une telle relation, les deux tables doivent partager un champ commun.

Lorsque vous détectez la nécessité d’une relation dans votre base de données, tenez compte si vous pouvez intégrer les informations des deux tables dans une table. Si vous ne voulez pas le faire pour une raison quelconque, par exemple, car il entraînerait un grand nombre d’espace vide, la liste suivante présente comment vous souhaitez représenter la relation dans votre conception :

  • Si les deux tables ont le même objet, vous pouvez probablement configurer la relation à l’aide de la même clé primaire dans les deux tables.
  • Si les deux tables possèdent des sujets différents avec des clés primaires différentes, choisissez une des tables (soit un) et insérez sa clé primaire dans l’autre table comme clé étrangère.

Déterminer les relations entre tables vous permet de garantir que vous avez droit tables et des colonnes. Il existe une relation un à un ou un-à-plusieurs, les tables concernées doivent partager une ou plusieurs colonnes courantes. S’il existe une relation plusieurs-à-plusieurs, une troisième table est nécessaire pour représenter la relation.

Affinage de la conception

Une fois que 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 essayez d’utiliser les informations : création de requêtes, ajouter des enregistrements et ainsi de suite. Cela permet de mettre en évidence les problèmes potentiels de pratique — par exemple, vous devrez peut-être ajouter une colonne que vous avez oublié d’insérer votre phase de conception, ou vous devrez peut-être que vous devez scinder une table en deux tables pour supprimer des doublons.

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

Lorsque vous essayez de votre base de données initiale, vous découvrirez probablement salle pour d’amélioration du produit. Voici quelques points à vérifier :

  • Vous avez oublié toutes les colonnes ? Si c’est le cas, les informations appartient dans les tables existantes ? S’il s’agit des informations complémentaires sur un autre, vous devrez peut-être créer une autre table. Créer une colonne pour chaque élément d’information que vous avez besoin pour effectuer le suivi. Si les informations ne peut pas être calculées à partir d’autres colonnes, il est probable que vous aurez besoin d’une nouvelle colonne pour qu’elle.
  • Sont toutes les colonnes inutiles, car ils peuvent être calculés à partir des champs existants ? Si un élément d’information peut être calculé à partir d’autres colonnes existantes — un emprunt à intérêt simple prix calculé prix de vente, par exemple, il est recommandé uniquement cette opération et créer une nouvelle colonne.
  • Sont à plusieurs reprises entrer des informations en double dans un de vos tables ? Si c’est le cas, vous devrez probablement diviser la table en deux tables ayant une relation un-à-plusieurs.
  • Vous disposez de tableaux comportant beaucoup de champs vides dans les enregistrements individuels, un nombre limité d’enregistrements et de champs ? Si c’est le cas, pensez à la nouvelle conception de la table de sorte qu’elle possède moins de champs et les autres enregistrements.
  • Les éléments d’information a été divisé en ses parties plus petit utiles ? Si vous avez besoin 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 concernant un sujet de la table ? Si une colonne ne contient pas d’informations sur le sujet de la table, elle appartient dans une autre table.
  • Sont toutes les relations entre les tables représentées, soit par des champs communs, soit par une troisième table ? Relations un à un et un-à-plusieurs nécessitent des colonnes communes. Relations plusieurs-à-plusieurs nécessitent une troisième table.

Affiner la table produits

Supposons que chaque produit dans la base de données de ventes de produits se situe une catégorie générale, tels que des boissons, condiments ou mer. La table produits peut inclure un champ qui indique la catégorie de chaque produit.

Supposons qu’après avoir étudié puis affiné la conception de la base de données, vous décidez de stocker une description de la catégorie ainsi que son nom. Si vous ajoutez un champ Description de la catégorie à la table Products, vous devrez répéter la description de la catégorie pour chaque produit qui se trouve sous la catégorie, ce n’est pas une bonne solution.

Une meilleure solution consiste à autoriser les catégories comme sujet de la base de données pour effectuer le suivi, avec sa propre tableau et sa propre clé primaire. Vous pouvez ensuite ajouter la clé primaire de la table catégories à la table Products comme clé étrangère.

Les tables catégories et produits ont une relation un-à-plusieurs : une catégorie peut inclure plusieurs produits, mais un produit peut appartenir à une catégorie.

Lorsque vous passez en revue les structures de votre table, soyez à l’affût pour les groupes extensibles. Par exemple, prenez une table contenant les colonnes suivantes :

  • Réf produit
  • Name (Nom)
  • Numéro de produit 1
  • Nom1
  • Numéro de produit 2
  • Nom 2
  • Numéro de produit 3
  • Name3

Ici, chaque produit est un groupe de colonnes qui est différente de celle des autres uniquement en ajoutant un numéro à la fin du nom de colonne. Lorsque vous trouvez des colonnes numérotées de cette façon, vous devez modifier la conception de votre.

Ce type de conception comporte plusieurs défauts. Pour commencer, il vous oblige à définir une limite supérieure du nombre de produits. Dès que vous dépassez cette limite, vous devez ajouter un nouveau groupe de colonnes à la structure de table, qui est une tâche d’administration principale.

Un autre problème est que ces fournisseurs qui ont moins le nombre maximal de produits seront perte d’espace, étant donné que les autres colonnes sera vides. Le plus important que pose ce type de conception est qu’elle rend de nombreuses tâches difficiles à exécuter, telles que le tri ou l’indexation de la table par nom ou ID de produit.

Chaque fois que vous voyez extensible groupes passez en revue la conception en étroite collaboration avec un œil sur le fractionnement de la table en deux. Dans l’exemple ci-dessus, qu’il est préférable d’utiliser deux tables, une pour les fournisseurs et l’autre pour les produits, liées par numéro de fournisseur.

Appliquer les règles de normalisation

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

Normalisation est particulièrement utile après avoir représenté tous les éléments d’informations et avez été redirigé vers une version préliminaire. L’idée consiste à vous aider à garantir que vous avez réparti les éléments d’informations dans les tables appropriées. Quels normalisation ne peut pas faire est Assurez-vous d’avoir tous les éléments de données appropriés dans un premier temps.

Vous appliquez les règles successivement, à chaque étape pour s’assurer que votre conception atteint ce qui est appelé « formes normales ». Cinq formes sont largement acceptées, la première forme normale par le biais normales. Cet article s’étend sur les trois premières, car ils sont tout ce qui est requis pour la plupart des bases de données.

La 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 peut pas contenir un champ nommé prix dans laquelle vous placez plusieurs prix. Si vous pensez que chaque intersection de lignes et de colonnes comme une cellule, chaque cellule peut contenir qu’une seule valeur.

Deuxième forme normale

Deuxième forme normale nécessite que chaque colonne non clé est entièrement dépendante de toute la clé primaire, et non sur seulement une partie de la clé. Cette règle s’applique lorsque vous avez une clé primaire est constituée de plusieurs colonnes. Par exemple, supposons que vous disposez d’une table contenant les colonnes suivantes, où N° commande et Réf produit forment la clé primaire :

  • N° commande (clé primaire)
  • ID de produit (clé primaire)
  • Nom du produit

Cette conception enfreint la deuxième forme normale, étant donné que nom du produit est dépendant de l’ID de produit, mais pas sur N° commande, il n’est pas dépendant de toute la clé primaire. Vous devez supprimer le nom du produit de la table. Il appartient dans une autre table (produits).

Troisième forme normale

Troisième forme normale nécessite non seulement chaque colonne non clé dépendre de toute la clé primaire, mais que les colonnes non clés être indépendants entre eux.

Un autre moyen d’ingénieurs expliquent cela est que chaque colonne non clé doit être dépendant de la clé primaire et rien d’autre que la clé primaire. Par exemple, supposons que vous disposez d’une table contenant les colonnes suivantes :

  • ID de produit (clé primaire)
  • Name (Nom)
  • SRP
  • Remise

Part du principe que remise dépend le prix de vente suggéré (SRP). Ce tableau enfreint la troisième forme normale car une colonne non clé, remise, dépend d’une autre colonne non clé, SRP. Indépendance des colonnes implique que vous devriez pouvoir modifier n’importe quelle colonne non clé sans toucher aux toute autre colonne. Si vous modifiez une valeur dans le champ SRP, la remise se modifie en conséquence, et donc violation de cette règle. Dans ce cas remise doit être déplacée vers une autre table est indexée sur SRP.