Dimensionner les champs de tables, exercice Access

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


Sujets que vous pourriez aussi aimer :


Dimensionner les champs de tables Access

Dans ce troisième exercice Acccess, nous abordons une étape cruciale dans le processus de construction de notre base de données. Nos tables sont prêtes, les champs ont été typés et les clés primaires ont été posées. Désormais, nous devons dimensionner au plus juste ces champs. L'enjeu consiste à ne pas allouer trop de ressources pour préserver les performances.

Base de données source
Pour poursuivre la conception de l'ossature de la base de données, nous devons récupérer les travaux là ou nous les avions laissés.

• Télécharger la base clients-et-commandes-dimensions.accdb en cliquant sur son lien,
• Double cliquer sur le fichier téléchargé pour l'ouvrir dans Access,
• Puis, cliquer sur le bouton Activer le contenu du bandeau jaune de sécurité,

Nous retrouvons les six tables de notre base de données. Elles sont listées dans le volet des objets Access, sur la gauche de l'écran.



Dans l'exercice précédent, nous avions importé depuis Excel, les villes et codes postaux de la région PACA dans la table Communes. A ce titre nous remarquons qu'une même ville associée à un même code postal est répétée à plusieurs reprises. Lorsque nous aborderons les requêtes Access, nous mettrons en oeuvre une solution pour purger cette table de ses doublons.

Ajuster la dimension des champs
Nous l'avons expliqué, dimensionner les champs au plus juste est primordial dans la conception d'une base de données, avant de chercher à aller plus loin. Par exemple, si un champ de type texte est destiné à recevoir des informations qui ne dépasseront jamais les 10 lettres, nous ne devons pas conserver la valeur de 255 caractères proposée par défaut. En ajustant cet attribut, Access allouera l'espace mémoire strictement nécessaire pour gérer ce champ. Ce gain est d'autant plus sensible lorsque le nombre d'enregistrements des tables devient important. Nous proposons de procéder par ordre, en prenant les tables dans la chronologie proposée par le volet Access.

• Dans le volet des objets Access, cliquer droit sur la table Clients,
• Dans le menu contextuel, choisir Mode création,

Nous basculons ainsi en conception de table. Le premier champ, le champ de la clé primaire, est sélectionné par défaut. Nous ne devons pas modifier sa taille, définie sur Entier long, dans l'onglet général, en bas de la fenêtre Access. En effet, nous devons prévoir d'ajouter autant d'enregistrements que nécessaire, au fil des années d'exploitation. Comme l'indique le support Office en ligne, un entier long accepte des valeurs jusqu'à 2 147 483 647. Ses besoins en stockage sont de quatre octets, ce qui est raisonnable. De plus, avant d'atteindre 2 Milliards de clients, nous avons de la marge. Mais au cours des années, certains sont supprimés puis réapparaissent. Les identifiants continuent de s'auto-incrémenter. Un identifiant déjà exploité, bien que supprimé, n'est plus utilisé.

• Sélectionner le champ Client_civilite,

Son type de données est défini sur Texte court. La taille qui lui est attribuée par défaut est de 255 caractères. C'est ce que mentionne son attribut Taille du champ, dans l'onglet général, en bas de la fenêtre Access. Dans ce champ, seules les mentions Madame et Monsieur doivent être inscrites. A l'avenir d'ailleurs, nous construirons une liste de choix proposant ces deux valeurs. La taille maximale attendue est donc de 8 caractères. Notre champ est largement surdimensionné.

• Dans la zone Taille du champ, saisir : 8,
• Puis, enregistrer les modifications (CTRL + S),

Comme nous sommes en train d'agir sur la structure de la table et que des données existent, une alerte apparaît. Access nous informe que la taille du champ n'est potentiellement plus adaptée. Mais nous connaissons le contenu de ce dernier.

• Valider cette alerte en cliquant sur le bouton Oui,

Si vous affichez la table en mode feuille de données, vous constatez qu'aucune perte n'est à déplorer. Si vous simulez la saisie d'un nouvel enregistrement, vous constatez qu'il n'est pas possible de taper au-delà de 8 lettres dans le champ Client_civilite. Ces réglages sont précieux. Poursuivons !

• En mode conception, sélectionner le champ Client_nom,
• Définir son attribut Taille du champ sur 50 caractères,

Nous réduisons sensiblement la capacité mais nous prévoyons large malgré tout. Certains noms composés, notamment latins, sont relativement longs.

• Sélectionner le champ Client_prenom,
• Réduire sa taille à 30 caractères,
• Sélectionner le champ Client_dep,
• Réduire sa taille à 5 caractères,

Un code postal est en effet composé de 5 chiffres, ni plus ni moins. Ce dimensionnement est donc réalisé au plus juste. Lorsque nous aborderons les masques de saisie, nous verrons comment imposer la saisie de chiffres, en empêchant l'inscription de lettres.

• Sélectionner enfin le champ Client_ville,
• Réduire sa taille à 50 caractères,
• Enregistrer les modifications (CTRL + S) et valider le message d'alerte par Oui,
• Afficher la table en mode feuille de données,

Aucune information n'a été perdue comme vous le constatez. Une fois encore, si vous tentez de taper au-delà de 5 caractères dans le champ Client_dep, le réglage défini bloque la saisie. Ces tailles de champs sont donc aussi l'occasion de sécuriser la saisie de certaines informations. Les codes postaux sont un très bon exemple.

• Cliquer sur la croix de l'onglet pour fermer la table Clients,
• Dans le volet des objets Access, cliquer droit sur la table Commandes,
• Dans le menu contextuel, choisir Mode création,

Tous les champs de cette table sont déjà configurés au plus juste. Le champ de la clé primaire ne doit pas être modifié pour les mêmes raisons que celles évoquées précédemment. Le champ Com_client est ce que l'on appelle une clé externe ou une clé étrangère. Il doit servir de liaison avec le champ de la clé primaire de la table Clients. Il doit donc proposer le même type et la même taille, que nous conservons sur Entier long. Le type de données du champ Com_montant est défini sur Monétaire. La taille de ce champ est implicitement gérée par ce type de données.

• Néanmoins, saisir la valeur 2 dans son attribut Décimales de l'onglet Général,

Très simplement et à toutes fins utiles, nous homogénéisons l'affichage des valeurs monétaires. 2 chiffres après la virgule suffisent en termes de précision.

Le type de données du champ Com_date est défini sur Date/Heure. Là aussi, la taille de ce champ est implicitement gérée par ce type. Néanmoins, un réglage peut s'avérer précieux sur ce champ. A chaque nouvelle inscription de commande, nous connaissons la date. Il s'agit de la date du jour, délivrée par la fonction Access Date.

• Dans l'attribut Valeur par défaut de son onglet général, taper l'expression suivante :

=Date()

• Enregistrer les modifications et afficher la table en mode feuille de données,

Comme vous le constatez, pour toute nouvelle potentielle commande, la date du jour est déjà inscrite par défaut. Il s'agit d'une inscription automatique. En conséquence, nous n'aurons pas à gérer ce champ.

• Cliquer sur la croix de l'onglet pour fermer cette table,
• Afficher désormais la table Communes en conception,

Comme toujours, le champ Commune_id de la clé primaire n'est pas à régler.

• Régler la taille du champ Commune_nom à 50 caractères,
• Régler la taille du champ Commune_dep à 5 caractères,

Il s'agit en effet d'un code postal. Comme précédemment, ce champ accueille nécessairement une suite de 5 chiffres.

• Enregistrer les modifications (CTRL + S) et valider le message d'alerte,
• Puis, afficher la table en mode feuille de données,

Là encore, aucune perte d'information n'est à déplorer. D'ailleurs, nous visualisons très rapidement la présence des doublons que nous évoquions. Là encore, la saisie d'un code postal est limitée à 5 caractères. En revanche, durant la phase d'importation, nous pouvons remarquer que les zéros en préfixe ont été perdus. Un code postal comme 06910 pour les Alpes Maritimes est transformé en : 6910. Il s'agit d'une sécurité que nous devrons ajouter grâce aux masques de saisie pour les prochains codes postaux. Pour tous ceux déjà archivés, il conviendra d'entreprendre une mise à jour avec une requête Action.

• Cliquer sur la croix de l'onglet pour fermer la table,
• Puis, afficher la table Detail_commandes en conception,

Comme nous l'avons expliqué, le champ Det_num de la clé primaire est déjà configuré. Il en va de même pour le champ de la clé externe Det_com destiné à établir la relation avec la table Commandes. Le type de données du champ Det_remise est configuré sur Monétaire. Il est donc implicitement dimensionné.

• Régler néanmoins son attribut Décimales sur 2,
• Puis, sélectionner le champ Det_ref,
• Dans son attribut Taille du champ, saisir 20,

Les références qui seront inscrites dans ce champ correspondent aux codes articles de la clé primaire dans la table Produits. Elles sont destinées à identifier les produits achetés par le client, lors de sa commande. Ces références sont codées sur une dizaine de caractères. Nous prévoyons un peu de marge mais conservons un champ correctement dimensionné.

• Sélectionner désormais le champ Det_qte,

Son type de données est nécessairement défini sur le type Numérique. De plus, une quantité est forcément un nombre entier. Mais souvenez-vous, un Entier long alloue l'espace mémoire nécessaire pour autoriser des nombres dépassant les 2 Milliards. Jamais un client n'achètera autant d'articles. Ce champ est donc surdimensionné.

• Dans la zone Taille du champ, Remplacer Entier long par Entier avec la liste déroulante,

Chaque client peut désormais commander jusqu'à 32 767 articles d'une même référence. La capacité est donc plus que suffisante. Nous aurions pu régler la taille sur Octet. Mais cette dernière n'autorise aucune saisie au-delà de 255. Il peut arriver qu'une société passe une grosse commande sur un produit spécifique et que ce nombre soit dépassé. En conséquence, le champ Det_qte est désormais correctement dimensionné.

• Enregistrer les modifications et cliquer sur la croix de l'onglet pour fermer la table,
• Puis, afficher la table Produits en mode création,

Il s'agit de la table offrant le plus grand nombre de champs. Le champ produit_ref est le champ de la clé primaire. Mais cette fois, il ne s'agit pas d'un champ auto-incrémenté. Son type de données est fort logiquement défini sur Texte court. Comme nous le disions précédemment, il doit établir la liaison avec le champ Det_ref de la table Detail_commandes.

• En conséquence, régler la taille du champ sur 20 caractères,
• Sélectionner le champ produit_nom et limiter sa taille à 70,

Il s'agit de la désignation du produit. Nous prévoyons donc suffisamment de longueur pour une mini description.

• Sélectionner ensuite le champ produit_prix,

Fort logiquement, il s'agit d'un champ numérique. Sa taille est réglée sur Réel double. Par définition, un réel double est constitué d'un maximum de 15 chiffres significatifs. C'est beaucoup trop. De plus, un autre type de données est beaucoup plus approprié pour ces informations numériques.

• Dans la colonne Type de données, choisir le type monétaire,
• Dans l'onglet Général, régler son attribut Décimales sur 2,
• Sélectionner le champ produit_poids,
• Dans la zone Taille du champ, remplacer Réel double par Entier,

Le poids est défini en grammes. Il s'agit nécessairement d'un nombre entier. Le type Entier coûte 2 octets de stockage au lieu de 8 pour le Réel double. Une fois encore donc, nous dimensionnons au plus juste pour optimiser les ressources et performances de la base de données.

• Sélectionner le champ produit_vues,
• Remplacer sa taille Réel double par Entier long,

Dans l'optique d'un site internet, ce champ est destiné à comptabiliser toutes les visites sur la fiche article. Ce compteur est donc forcément un nombre entier. Cependant la taille maximale de 32 767 autorisée par un entier classique s'avère rapidement insuffisante. Donc la taille Entier long est la plus adaptée. Rappelez-vous, un entier long coûte 4 octets au lieu des 8 alloués à l'origine.

• Sélectionner le champ produit_stock,
• Remplacer sa taille Réel double par Entier,

Les 255 unités permises par un Octet, soit un entier court, sont effectivement insuffisantes. Le meilleur dimensionnement consiste évidemment à régler la taille de ce champ sur Entier.

• Sélectionner le champ produit_code,

Comme vous le remarquez, sa taille est déjà calibrée en Octet. Ce champ est donc déjà parfaitement ajusté. Il est en effet destiné à accueillir un code promotion. Ces derniers varient entre 1 et 10.

• Enregistrer les modifications et valider le message d'alerte,
• Ensuite, afficher la table en mode feuille de données,

Là encore, aucune perte d'information n'est à déplorer. Nous retrouvons les 244 enregistrements d'origine. Le champ produit_code est vide. Il sera implémenté au gré des opérations commerciales. Nous le verrons quand nous aurons appris à piloter les requêtes Access.

• Cliquer sur la croix de l'onglet pour fermer la table Produits,
• Enfin, afficher la table Remises en mode création,

Le champ Remise_id est celui de la clé primaire. Sa taille peut être modifiée en changeant le type de données, puisque toutes les informations sont désormais inscrites. Nous n'avons donc plus besoin du fonctionnement du numéro auto-incrémenté. Plus aucune remise ne sera ajoutée. En effet, la taille Entier long est bien trop gourmande pour un champ dont les valeurs sont bornées et définies.

• Dans sa colonne Type de données, choisir Numérique,
• Puis, régler son attribut Taille du champ sur Octet,
• Sélectionner le champ Remise_taux,

Celui-ci est déjà parfaitement typé et dimensionné. Il s'agit d'un taux de remise en pourcentage. Ce nombre propose donc des décimales que nous gérons avec la taille Réel simple.

• Enregistrer les modifications et fermer la table Remises,

Nous en avons terminé avec ce travail essentiel dans la construction d'une base de données. Dans le prochain exercice, nous exploiterons toutes les ficelles offertes par le formatage des champs. Là encore, il s'agit de paramétrages précieux à réaliser en amont, avec les tables donc. Nous constaterons les bienfaits ergonomiques qu'ils procurent lorsque nous progresserons dans l'apprentissage du gestionnaire de bases de données Access.