formateur informatique

Indexer les champs de tables, exercice Access

Accueil  >  Bureautique  >  Access  >  Access Débutant  >  Indexer les champs de tables, exercice Access
Livres à télécharger


Pour partager cette vidéo sur les réseaux sociaux, voici son url absolue :

Pour l'intégrer sur votre site internet ou blog, vous pouvez l'embarquer :

Sujets et formations similaires :


Indexation des champs de tables

Dans ce huitième exercice Access, nous parachevons la configuration des tables de notre base de données, destinée à porter une application professionnelle de facturation. Nous avons déjà typé, dimensionné et formaté les champs des tables. Nous avons de même construit des listes déroulantes pour simplifier l'intégration de certaines informations. Et puis, nous avons amélioré la sécurité grâce à des règles de validité. Désormais, nous souhaitons indexer les champs importants. L'indexation d'un champ consiste à améliorer les performances de recherche. Mais attention, ce réglage doit être réalisé avec parcimonie. Si tous les champs sont indexés, la base de données s'alourdit et ses performances sont considérablement dégradées. Le résultat obtenu est l'exact inverse des effets attendus.



Base de données source
Il s'agit dans un premier temps de réceptionner la base de données pour poursuivre les travaux où nous les avions laissés. Tout d'abord, il est important de constater que le poids actuel de cette base de données est de 624 Ko. L'indexation consiste à créer des bases de connaissance. Ces bases de connaissances ont nécessairement une influence sur le poids du fichier. Mais c'est la rançon du succès. Le gain en termes de performances est indéniable et incontournable.
  • Double cliquer sur le fichier téléchargé pour l'ouvrir dans Access,
  • Puis, cliquer sur le bouton Activer le contenu du bandeau de sécurité,
Table de base de données Access avec règles de validité sur champs

Tout d'abord et nous en avons l'habitude désormais, nous réceptionnons les 6 tables de notre base de données. Elles sont énumérées dans le volet des objets Access, sur la gauche de l'écran.
  • Dans ce volet, cliquer droit sur la table Produits,
  • Dans le menu contextuel, choisir Mode création,
  • Dans la vue en conception, sélectionner le champ produit_code,
Sur ce champ notamment, vous remarquez la présence d'une règle de validité. Seule la saisie d'un nombre entier compris entre 1 et 9 est autorisée. Il s'agit des réglages que nous avons validés lors du précédent exercice.
  • Sélectionner désormais le champ produit_ref,
Il s'agit du champ de la clé primaire. C'est lui, par ces codes articles, qui identifie chaque enregistrement de façon unique.

Champ de la clé primaire dans table Access des produits, indexé sans doublons

Si vous consultez ses propriétés en bas de la fenêtre, vous constatez que ce champ est indexé sans doublons. C'est toujours le cas pour une clé primaire. Elle interdit les redondances. De plus, il s'agit d'un champ important, l'identifiant est souvent utilisé pour accéder à l'enregistrement. C'est ainsi que sont identifiées les pages de destination sur un site Web par exemple. Le numéro suffixe généralement l'URL. En conséquence, il est primordial d'accéder rapidement aux informations de cet enregistrement par sa référence. Il est donc indexé pour améliorer les temps de réponse aux demandes.



Indexer les champs de recherche
Nous le disions, le choix des champs à indexer est crucial. L'indexation consiste à améliorer les performances des recherches. Donc, les champs concernés sont amenés à être questionnés. De plus, ils ne doivent pas proposer un trop grand nombre de redondances. La clé primaire en est l'illustration parfaite.
  • Dans le volet des objets Access, double cliquer sur la table Clients,
Nous accédons ainsi à son contenu en mode feuille de données. Le champ Client_civilite est le parfait exemple de la colonne à ne jamais indexer. Elle ne propose que des doublons. De plus, jamais une recherche ne sera entreprise sur la civilité. L'information est bien trop vague. De même, le prénom est une donnée trop peu descriptive. Et là encore, les doublons peuvent être nombreux. En revanche, il paraît pertinent d'exercer des recherches de clients par leur nom ou encore par leur ville. Les redondances existent certes. Mais elles sont limitées.
  • Dans le ruban Accueil, cliquer sur la flèche du bouton Affichage,
  • Dans la liste, choisir Mode création,
  • Dans la vue en conception, sélectionner le champ Client_nom,
  • En bas de la fenêtre, double cliquer sur la valeur non de sa propriété Indexé,
Nous la réglons ainsi sur la valeur : Oui - Avec doublons. Il n'est pas possible de choisir : Oui - Sans doublons. Ce champ présente forcément des redondances à cause des homonymes.
  • Sélectionner le champ Client_ville,
  • Régler sa propriété Indexé sur : Oui - Avec doublons,
Indexer certains champs de tables Access avec doublons pour améliorer les performances de recherches

Il est important de comprendre que les gains observés en termes de performances, sont d'autant plus importants que les données de la base Access sont volumineuses.
  • Enregistrer les modifications (CTRL + S),
  • Puis, afficher le contenu du dossier de téléchargement,
Augmentation taille fichier base de données en raison indexation des champs de tables Access

Comme vous le remarquez, bien qu'aucune donnée n'ait été ajoutée dans cette base de données, son poids a déjà pris plus de 50 Ko. Access construit ses bases de connaissances sur les champs indexés. A l'issue des opérations, nous compacterons la base. Nous verrons s'il est possible de rejoindre la taille d'origine.
  • Revenir sur la base de données Access,
  • Fermer la table Clients en cliquant sur la croix de son onglet,
La table Commandes est forcément indexée sur le champ Com_num de sa clé primaire. Aucun autre de ses champs n'est pertinent pour engager des recherches. La remarque est identique pour la table qui est amenée à lui être liée. Elle se nomme Detail_commandes.
  • Dans le volet des objets Access, cliquer droit sur la table Detail_commandes,
  • Dans le menu contextuel, choisir Mode création,
Fort logiquement, le champ Det_num de la clé primaire est indexé sans doublons. C'est lui qui identifie de façon unique chaque nouveau détail d'une commande. Il n'est pas envisageable d'indexer les champs de la quantité et de la remise. Le champ Det_ref est celui des références articles achetées. Il pourrait paraître intéressant pour les recherches. Mais ces recherches doivent être réalisées dans la table où ils sont tous référencés, soit la table Produits. Donc, il n'est pas question non plus d'indexer ce champ. Le champ Det_com est celui de la clé externe qui va servir de lien avec la clé primaire Com_num de la table parente. Nous pourrions être tentés de l'indexer afin de consolider plus rapidement tous les détails d'une commande. Mais nous le verrons, par le jeu des relations, lorsque nous chercherons un client par son identifiant indexé, nous obtiendrons en cascade toutes ses commandes et pour chacune, tous les détails.
  • Fermer la table Detail_commandes en cliquant sur la croix de son onglet,
  • Dans le volet sur la gauche, double cliquer sur la table Communes pour afficher son contenu,
Voici une table particulière. Tous ses champs méritent d'être indexés. Tout d'abord, le champ Commune_id de sa clé primaire l'est par défaut. Ensuite, il est précieux de pouvoir retrouver des clients par recherche de la ville ou encore d'un code postal. Certes, ces deux champs présentent des redondances, mais elles sont limitées.

Table Access des communes pour indexer champs de recherche sur ville et code postal



Il est donc important d'améliorer les performances de recherche pour accéder rapidement à l'information, à plus forte raison quand les données se cumuleront.
  • Dans le ruban Accueil, cliquer sur la flèche du bouton Affichage,
  • Dans la liste, choisir Mode création,
  • Dans la vue en conception, sélectionner tout d'abord le champ Commune_nom,
  • Régler sa propriété Indexé sur Oui - Avec doublons,
  • Sélectionner ensuite le champ Commune_dep,
  • Régler sa propriété Indexé sur Oui - Avec doublons,
  • Puis, enregistrer les modifications (CTRL + S),
  • Cliquer sur la croix de son onglet pour fermer la table Communes,
Si vous consultez le poids du fichier à la racine du dossier de téléchargement, vous constatez que la base de données a encore pris une cinquantaine de kilos octets. Une fois encore, nous n'avons ajouté aucun enregistrement. Access continue de construire ses bases de connaissance en fonction des champs que nous choisissons d'indexer.
  • Dans le volet des objets Access, cliquer droit sur la table Produits,
  • Dans le menu contextuel, choisir Mode création,
  • Dans la vue en conception, sélectionner le champ produit_ref,
Il s'agit du champ de la clé primaire et c'est un choix judicieux. Une référence article est forcément unique. Elle identifie donc chaque enregistrement. De fait, elle est indexée sans doublons. Il est important de pouvoir retrouver un article et son détail par recherche sur son code.

Tous les autres champs ne présentent aucun intérêt à l'indexation. Le champ produit_nom de la désignation est potentiellement trop volumineux. Si nous souhaitions réaliser des recherches sur des mots clés, nous devrions prévoir un champ à cet effet. C'est d'ailleurs l'astuce que démontre la formation du moteur de recherche en Php, pour optimiser les performances de recherche en base de données MySql.
  • Fermer la table Produits,
Comme nous avons engagé d'importants paramétrages de structure sur cette base de données, il est intéressant de la compacter. Cette fonctionnalité permet certes d'optimiser le poids du fichier, mais pas seulement. En regroupant les données, elle améliore les performances globales de la base.
  • En haut de la fenêtre Access, cliquer sur l'onglet Fichier,
  • Au centre de la fenêtre, cliquer sur le bouton Compacter et réparer la base de données,
Compacter une base de données Access pour optimiser le poids et améliorer les performances

La base de données se ferme puis se rouvre. Si vous consultez son poids à la racine du dossier de téléchargement, vous remarquez qu'il est optimisé. Nous avons gagné près de 70 Ko par rapport au précédent. Néanmoins, notre fichier est désormais plus volumineux d'une cinquantaine de kilos par rapport au poids réceptionné en début de formation. Ce phénomène est donc tout à fait logique, en raison des bases de connaissance construites par indexation des champs.

Dans le prochain exercice, nous traiterons le point fondamental d'un gestionnaire de bases de données relationnelles. Nous établirons les relations entre les tables.

 
Sur Facebook
Sur G+
Sur Youtube
Les livres
Contact
Mentions légales



Partager la formation
Partager sur Facebook
Partager sur Google+
Partager sur Twitter
Partager sur LinkedIn